{intro}
<Spacing size="lg" />
## 들어가기 전에
 
<PostImage src="https://image.aladin.co.kr/product/23618/61/cover500/k932638523_1.jpg" alt="리팩토링 2판 표지" width={500/1.5} height={615/1.5}/>
 
자바스크립트로 예시가 작성된 리팩토링 2판의 내용을 정리했습니다.
 
## 리팩토링과 테스트코드의 상관관계
 
리팩토링과 테스트코드, 도대체 어떤 관계가 있길래 한 챕터에서 테스트코드에 대한 이야기만 할까요? 일단 리팩토링의 정의에 대해 알아보겠습니다.
 
### 리팩토링이란?
 
리팩터링이란 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법입니다.
 
여기서 중요한 포인트는 겉보기 동작은 그대로 유지한다는 점입니다. 특히 버그가 보여도 리팩터링을 할 때에는 일단 무시하고 코드의 내부 구조만 변경해야 한다고 합니다. (하지만 아무도 발견하지 못한 버그라면 살짝 고쳐도 된다고 합니다🤭) 리팩토링을 하면서 기능이 변경되거나 코드가 깨지면 그것은 리팩터링이 아닌 것이죠.
 
### 리팩토링을 할 때 테스트코드의 역할
 
이때 테스트코드는 내부 구조가 변경되어도 기능이 문제 없이 동작한다는 것을 보장합니다. 작업을 하면서 수시로 테스트를 돌려 기능이 깨지는 시점을 빠르게 캐치하고 수정할 수 있으며 최종적으로 변경된 코드에 문제가 없음을 보장할 수 있게 됩니다.
 
혹시 코드를 수정하다 뒤늦게 기존 동작이 깨지는 경험을 해본 적이 있으신가요? 저는 그런 경험이 있는데요. 꽤 작업이 진행된 후라 언제부터 기능이 깨졌는지, 어느 부분이 문제인지 디버깅하느라 시간을 허비하게 되었습니다. 만약 테스트코드가 있었다면 문제가 발생할 당시에 바로 알아차려 수정할 수 있었을 것입니다.
 
이처럼 내부 구조를 손보는 리팩토링 작업을 할 때 테스트코드를 통해 불가피하게 저지르는 실수를 바로잡을 수 있습니다.
 
## 테스트코드 작성 시 중요 포인트
 
1. **모든 테스트를 자동화하고 자주 테스트하자**

책에서는 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고 적어도 하루에 한 번은 전체 테스트할 것을 권장합니다. 추가한 코드에 문제가 없는지, 리팩터링을 하면서 실수한 것은 없는지 수시로 확인하며 디버깅 시간을 줄이고 코드의 안정성을 보장할 수 있기 때문입니다.
 
2. **코드를 성격에 따라 분리하자**

비즈니스 로직과 UI가 결합해 있다면 테스트코드도 자연히 복잡해질 것입니다. 이를 방지하기 위해 비즈니스 로직과 UI를 분리하는 등 성격에 따른 코드 분리가 필요합니다. 이렇게 테스트코드 작성을 위해 자연스럽게 좋은 코드를 작성하게 될 수 있다는 장점도 있습니다.
 
3. **실패해야 할 상황에서는 반드시 실패하게 만들자**

테스트코드를 작성하다 보면 테스트가 통과되는 기쁨에 취해 이 테스트코드가 정말로 요구사항을 잘 검증하고 있는지 놓칠 때가 있습니다. 때문에 일부러 테스트가 실패하는 모습을 확인하여 정말로 유의미한 테스트코드인지 확인해보는 과정이 필요합니다.
 
4. **테스트는 위험 요소를 중심으로 작성하자**

테스트코드를 도입하지 않은 경우 막막함에 아예 테스트코드 작성을 포기할 수도 있습니다. 하지만 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성하는 것이 낫다고 마틴 파울러는 이야기합니다. 모든 버그를 잡아낼 수 없다고 생각하여 테스트를 작성하지 않는다면 대다수의 버그를 잡을 기회를 날리는 것이라고 하면서 말이죠.
 
5. **문제가 생길 가능성이 있는 경계 조건 검사하기**

요구사항을 충족할 수 있도록 테스트코드를 작성하는 것도 중요하지만 문제가 생길만한 경계 조건을 검사해보아야 합니다. 예외나 실패가 존재하지 않은 happy path 상황에만 집중하면 다양한 예외 케이스에 대응할 수 없기 때문입니다. 함수에 인자를 넘기지 않는다거나 고객 수요 최솟값이 음수가 되는 등 범위를 벗어나는 경계 지점에서 문제가 생기면 어떤 일이 벌어지는지 확인하는 테스트코드를 작성하다보면 예외 상황을 어떻게 처리할지 고민할 수 있습니다. (마틴 파울러는 의식적으로 프로그램을 망가뜨리는 방법을 모색하며 생산성과 재미를 끌어올렸다고 합니다. 이런 게 바로 진짜 광기...?👻)
 
6. **버그 리포트를 받으면 그 버그를 드러내는 단위 테스트부터 작성하자**

충분한 테스트를 갖추었는지 판단하는 기준은 주관적입니다. 테스트 커버리지가 높다고 해서 안정적인 테스트 환경을 갖추었다고 확신할 수 없습니다. 그렇기에 '누군가 결함을 심으면 테스트가 발견할 수 있다는 믿음'을 가질 정도로 테스트코드를 구축해 둔 것 만으로도 테스트코드의 목적은 달성되었다고 할 수 있습니다.
 
## 포스팅을 마무리하며
 
이렇게 리팩토링 2판 챕터 4 ⌜테스트코드 구축하기⌟를 살펴보며 리팩토링에 있어 테스트코드가 왜 중요한 요소인지, 테스트코드 작성 시 중요하다고 생각되는 포인트들을 정리해 보았습니다. 테스트코드가 없는 환경에서 코드를 수정하며 디버깅에 애를 먹은 경험이 있기에 더욱 공감이 가는 내용이었던 것 같습니다. 이제 막 테스트코드를 공부하기 시작한 입장에서 그 필요성을 다시금 느끼게 된 계기도 되었고요. 이 외에도 좋은 코드를 작성하기 위한 꿀팁을 알고 싶으시다면 리팩토링 책을 읽어보시는 것을 추천합니다👍

리팩토링 2판 정리 - 테스트코드 구축하기

{intro}
<Spacing size="lg" />
## CI/CD란?
 
### CI (Continuous Integration)
 
CI는 지속적 통합을 의미하며 기능 추가, 버그 수정 등 코드가 수정된 후에 빌드, 테스트를 통해 운영 브랜치에 통합되는 것을 의미합니다. 이 때 빌드, 테스트와 같은 프로세스를 자동화하여 변경된 코드에 문제가 있는 경우 빠르게 파악하고 수정할 수 있습니다. 이로 인해 효율적이고 안정적인 환경 속에서 개발에 집중할 수 있게 됩니다.
 
### CD (Continuous Delivery or Continuous Deployment)
 
CD는 지속적 제공 혹은 지속적 배포를 의미합니다. 두 용어 모두 변경된 코드가 배포되는 것을 의미하며 지속적 제공은 수동 배포, 지속적 배포는 자동 배포를 뜻합니다.
 
그리고 CI/CD가 물 흐르듯 자동으로 진행될 수 있도록 하는 프로세스를 CI/CD 파이프라인이라고 합니다.
 
## 핵심은 자동화
 
CI/CD 파이프라인의 핵심 목적은 자동화입니다. 개발자가 수정한 코드가 배포되는 일련의 과정이 자동화되어 효율적인 개발 환경을 구축하는데 그 목적이 있습니다.
 
만약 코드가 변경될 때마다 수동으로 테스트하고 배포해야 한다면 어떻게 될까요?
 
<PostImage src="https://drive.google.com/uc?export=view&id=1uv2koS3sOj2suDAEhbb4Lnyn3A991ypH" alt="파일질라 화면" width={937/1.5} height={747/1.5} caption="파일질라 화면, 변경된 파일을 직접 옮겨 배포"/>
 
실제로 제가 처음 퍼블리싱을 배웠을 때와 회사에 아직 CI/CD 파이프라인이 구축되지 않았을 때는 파일질라를 사용하여 배포했습니다. 
(회사에서는 배포 권한이 없었습니다😅) 
 
개발자가 변경된 파일을 수동으로 배포하는 작업은 비효율적이며 휴먼 에러가 발생하기도 쉽습니다. CI/CD 파이프라인을 구축해 둔다면 개발 외의 불필요한 작업으로 시간이 소모되는 것을 막을 수 있고 안정적으로 프로젝트를 운영해 나갈 수 있게 됩니다.
 
## 무엇으로 CI/CD 파이프라인을 구축할까?
 
제가 CI/CD 파이프라인을 구축하기 위해 사용한 도구는 Github Actions입니다. Github을 사용하고 있다면 추가적인 설치 작업 없이 Github에서 발생하는 이벤트(PR, push, issue 등)를 기반으로 작업을 트리거 할 수 있으며 마켓 플레이스에서 공유되는 액션을 사용할 수 있다는 장점이 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=18owx0IULSn6Ijo9Id9-Dwh-wUqB9mYSt" alt="jet brain 2024 가장 많이 사용하는 ci 도구 설문 조사 결과 1위는 jenkins, 새롭게 떠오르는 1위는 github actions" width="699" height="654" caption="Jet Brain 설문 결과, 전체적으로는 Jenkins가 1위이지만 Github Actions가 새로운 1위로 떠오르고 있음"/>
 
또한 [Jet Brain에서 2024년 가장 많이 사용하는 CI 도구를 설문한 결과](https://blog.jetbrains.com/teamcity/2023/07/best-ci-tools/). Github Actions가 새로운 1위로 떠오르고 있으며 개인 프로젝트에서 가장 인기 있는 도구라고 합니다. (~~1위는 못 참지~~)
 
위와 같은 이유로 저는 Github Actions를 선택하게 되었습니다. 추후에 Github Actions에서 사용하는 워크플로우 파일 구성에 대해서도 포스트를 작성해 보겠습니다.
 
## CI/CD 시나리오
 
<PostImage src="https://drive.google.com/uc?export=view&id=1zjeU7_hBsAIpXb9zu76f_GaNRyMOih6E" alt="CI/CD 시나리오" width="1072" height="830"/>
 
Github Actions를 도입하며 구성한 CI/CD 시나리오는 위와 같습니다. 
(참고로 저는 브랜치 관리 전략으로 GitLab Flow를 사용하고 있습니다. [브랜치 전략 포스트 보러 가기](/posts/Process/브랜치-전략-바꾸기))
 
**1. PR 생성 및 업데이트**

feature 브랜치에서 코드 변경이 마무리되어 PR이 생성되고 업데이트 될 때 자동으로 테스트가 실행됩니다.
사실 혼자 작업하고 있기에 PR의 필요성에 대해 고민하기도 했지만 코드 변경 사항을 기록하고 테스트를 통과한 커밋한 배포 브랜치에 통합 될 수 있도록 PR 생성 및 업데이트 상황을 시나리오에 추가하였습니다.
 
**2. main, production 브랜치에 push**

main, production 브랜치에 커밋이 push되면 테스트 ➡️ 배포 ➡️ 슬랙 알림 작업이 일어납니다. main 브랜치에서는 Vercel에서 제공하는 preview 환경에 배포하여 QA를 진행할 수 있게 하였고 QA가 완료된 후 production 브랜치에 merge되면 production 환경으로 배포됩니다. 이 때 각 환경에서는 배포 성공, 실패 유무에 관계 없이 슬랙 알림이 오도록 시나리오를 구성했습니다. 

이미 테스트를 통과한 커밋만 배포 브랜치에 merge되는데 또 다시 테스트를 실행하는 것이 중복 작업이라는 생각이 들었지만 혹여나 배포 브랜치에 바로 커밋을 push하여 테스트를 통과하지 않은 코드가 배포되는 상황을 방지하기 위해 테스트 단계를 추가하였습니다.
 
## 포스팅을 마무리하며
 
사실 CI/CD에 대한 이야기를 많이 들어왔지만 막연한 개념으로 느껴졌습니다. 하지만 코드 변경, 테스트, 배포까지의 시나리오를 구성하고 Github Actions로 자동화 해보며 "아, 이런 게 CI/CD구나" 라고 감을 잡을 수 있었습니다. 업무의 효율을 높이는 방법을 이야기 할 때 항상 빠지지 않는 것이 바로 자동화인데요. 불필요한 수동 작업에서 벗어나 집중해야 할 부분에 더 집중할 수 있도록 CI/CD 파이프라인을 구축해 보면 좋을 것 같습니다👍

CI/CD 시나리오 구성하기

{intro}
<Spacing size="lg" />
## 브랜치 전략이란?
 
브랜치 전략이란 Git을 사용할 때 브랜치의 역할에 따라 코드를 관리하는 방법론입니다. 프로젝트의 요구사항에 따라 브랜치를 사용하는 규칙과 구조를 정의하여 일관성 있게 코드를 관리합니다.
 
그렇다면 브랜치 전략을 사용하는 이유는 무엇일까요? 하나의 브랜치에서 여러 명의 개발자가 개발한다고 가정해 보겠습니다. 각각의 개발자가 작업을 한 후에 하나의 브랜치에 커밋하게 되면 같은 파일을 수정한 경우 머지 충돌이 발생할 것입니다. 이를 해결하느라 불필요한 시간을 소모하게 되며 작업의 효율성이 떨어지게 됩니다. 또한 어느 커밋을 기준으로 QA, 배포할지 혼란스러우며 프로젝트 히스토리 관리도 어려울 것입니다. 따라서 기능 개발, 버그 수정, QA, 배포 등 브랜치의 역할을 나누어 코드를 관리하는 브랜치 전략을 도입하여 프로젝트의 운영의 효율성과 안정성을 높이는 것이 중요합니다.
 
## 혼자 작업 하는데도 브랜치 전략이 필요할까?
 
사실 배포 전에는 따로 브랜치를 생성하지 않고 main 브랜치에 push를 하곤 했습니다. 하지만 배포를 한 이후에는 Vervel을 통해 push가 발생하면 자동으로 배포되도록 세팅해두었기 때문에 브랜치 전략이 필요해졌습니다. tag가 push 되었을 때 배포하는 방법도 있지만 저는 배포 브랜치를 정해두고 해당 브랜치에 push가 발생할 때 배포되는 것이 직관적이라 생각되어 개인 프로젝트에도 브랜치 전략을 도입하였습니다. 각자의 필요에 따라 다르겠지만 프로젝트가 배포되고 있다면 브랜치를 나누어 작업하는 것이 안정적이라고 생각됩니다.
 
## 어떤 브랜치 전략을 도입할까
 
결론부터 말하자면 저는 GitLab flow를 선택했습니다. 
이유는 Git flow보다는 단순하고 Github flow보다는 브랜치의 역할 분담이 잘 되어 있기 때문입니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1G-r8Hs7QcS6rTYj1zrZW5YlyJ78-9nWA" alt="질문 : 왜 6점이에요? 대답 : 7점은 너무 많은 것 같고 5점은 좀 적은 것 같아서요." width="800" height="491" caption="🤔 : 왜 GitLab flow 쓰세요? 🤓 :Git flow는 너무 복잡하고 Github flow는 좀 단순한 것 같아서요..."/>
 
사실 처음에는 원래 알고 있던 Git flow 방식을 관성적으로 사용했습니다. 그러나 작업을 하다 보니 개인 프로젝트에서는 Git flow 전략이 다소 복잡하다는 생각이 들었고 대안을 찾기 위해 다른 브랜치 전략을 조사하게 되었습니다. 그럼 많이 사용되는 3가지 브랜치 전략을 살펴보겠습니다.
 
### Git flow
Git flow는 main, develop, feature, release, hotfix와 같은 5가지 브랜치를 사용합니다. 소개하는 3가지 전략 중 가장 복잡하지만 브랜치의 역할을 명확히 나누어서 안정적으로 코드 관리를 해나갈 수 있습니다. 다수의 인원이 모인 팀에서 사용하기 적절합니다. 저도 회사에 다니며 사용하였던 브랜치 전략이지만 개인 프로젝트에 적용하기에는 다소 번거롭다는 단점이 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1_kZ7zkC3_JWAeD_LVp7G4yAB6PIlguJ3" alt="git flow" width="720" height="462" caption="이미지 출처 : https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423"/>
 
브랜치 역할
 
- main (master) : 테스트, QA 등 모든 검증이 완료된 프로덕션 배포용 브랜치. release, hotfix 등 배포 후 develop 브랜치와 동기화 필요.
- develop : 개발용 브랜치. develop 브랜치를 기준으로 기능 개발.
- feature : 기능 개발용 브랜치로 develop 브랜치에서 분기 후 병합.
- release : 배포 준비를 위한 브랜치로 QA 및 수정 작업이 진행. 배포 준비가 완료되면 main 브랜치에 병합.
- hotfix : 긴급한 에러를 수정하기 위한 브랜치로 main 브랜치에서 분기 후 병합.
 
### GitLab flow
 
GitLab flow는 GitLab에서 제안하는 브랜치 전략입니다. 항상 유지되는 main 브랜치가 있으며 필요에 따라 환경 브랜치(production, pre-production 등)를 추가할 수 있습니다. 배포할 준비가 코드가 포함된 main 브랜치가 있으나 해당 브랜치에서 배포를 진행하지 않습니다. 배포를 위해 production 브랜치를 생성하며 배포 전 QA 과정이 필요하다면 pre-production 브랜치를 생성할 수도 있습니다.
[GitLab에서 제안하는 GitLab flow의 모범 사례](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/)를 보면 기능 개발 시에 main 브랜치를 기준으로 feature 브랜치를 생성할 것을 권장하고 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1slnud3rMJmuUEC71M6YpoF_Tbbr216vV" alt="gitlab flow" width="720" height="410" caption="이미지 출처 : https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423"/>
 
브랜치 역할
 
- main : 배포할 준비가 된 브랜치.
- production : 프로덕션 배포용 브랜치.
- pre-production : 배포 전 QA를 진행하는 브랜치
- feature : 기능 개발용 브랜치. main에서 분기 후 병합
 
### Github flow
 
main 브랜치와 feature 브랜치를 사용하는 브랜치 전략입니다. 소개하는 3가지 전략 중 가장 단순한 구조입니다. feature 브랜치에서 작업을 완료하고 바로 main 브랜치에 병합하는 방식으로 빠르게 기능을 개발하고 배포할 수 있다는 장점이 있습니다. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1NSigwt741nKEsFXxq8VVx0rFj4FiQzI3" alt="github flow" width="720" height="357" caption="이미지 출처 : https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423"/>
 
브랜치 역할
 
- main : 프로덕션 배포용 브랜치.
- feature : 기능 개발을 위한 브랜치, main 브랜치에서 분기 후 병합.
 
 
앞서 언급했듯이 저는 GitLab flow 방식의 브랜치 전략을 사용하고 있습니다. 개인 프로젝트이다 보니 Git flow의 main과 develop 브랜치를 동기화하는 작업이 번거롭게 느껴졌고 간단한 QA는 Vercel에서 제공하는 preview 배포 기능을 통해 develop 브랜치에서 진행하고 있었기에 release 브랜치의 필요성을 느끼지 못했습니다. 하지만 Github flow처럼 feature 브랜치에서 바로 main 브랜치로 merge하는 것은 안정성이 떨어진다고 생각하였기에 GitLab flow 방식을 최종적으로 선택하였습니다. 환경에 따라 브랜치를 유연하게 추가할 수 있다는 점도 큰 매력 포인트였습니다.
 
## 포스팅을 마무리하며
 
오늘은 프로젝트에 맞게 브랜치 전략을 바꾸기 위해 3가지 브랜치 전략의 특징에 대해 알아보았습니다. 해당 포스트에서 소개한 3가지 외에도 다양한 브랜치 전략이 존재합니다. 각자 프로젝트의 성격에 따라 적합한 브랜치 전략을 도입해보면 좋을 것 같습니다 👍

브랜치 전략 바꾸기

{intro}
<Spacing size="lg" />
## 9월동안 무슨 일이 있었을까
 
### 1.블로그 배포
첫번째로 기념비적인 블로그 배포가 있었습니다. 배포 전에는 이런 저런 고민이 많았지만 막상 배포하고나니 속이 후련했습니다. 다만 배포 후 미뤄둔 공부를 하느라 생각보다 포스트를 많이 작성하지 못해 아쉬운 마음이 듭니다. 10월 달은 포스팅 작성에 힘써보겠습니다💪
 
### 2.테스트 코드 공부, 근데 이제 CI/CD를 곁들인
블로그 배포 후 가장 먼저 테스트코드 공부를 진행했습니다. 요즘 채용공고를 보면 테스트코드가 필수인 것 같습니다. 이전 회사에서는 테스트코드 작성 문화가 없었어서 많이 쓰인다는 걸 알면서도 좀 미뤄뒀었는데 더이상 미룰 수 없을 것 같아 강의를 들었습니다. 이번에 블로그에도 테스트코드를 작성해보려 했는데 블로그 기능이 단순하기도 하고 아직 어떤 부분을 테스트해야 할지 감이 잡히질 않습니다. 이 부분은 시간을 들여 더 공부를 해봐야 할 것 같습니다. 그리고 cypress로 테스트 자동화를 해보며 엉겁결에 github action으로 CI/CD 세팅도 해보았습니다. 처음 해보는 거라 많이 헤맸지만 자동화를 직접 세팅해 볼 수 있어 즐거웠습니다. 본격적으로 공부해서 제대로 된 시나리오를 적용해보고 싶습니다.
 
### 3.리액트 쿼리 (React Query) 공부
리액트 쿼리는 원래 사용하던 라이브러리였지만 늘 사용하는 기능만 반복적으로 사용해왔어서 깊게 공부하고자 예전에 유데미에서 구매해둔 강의를 보며 전체적인 사용법을 익혔습니다. staleTime과 gcTime의 차이, isFetching과 isLoading의 차이 등 개발하며 크게 신경쓰지 못한 개념들에 대해 다시 정리할 수 있어서 좋았습니다. 에러를 한번에 관리하거나 쿼리를 모두 불러왔는지 확인할 수 있는 등 몰랐던 부분에 대해서도 알게 되어 그저 관성적으로 늘 쓰는 것만 사용해왔구나 싶어서 반성하기도 했습니다. 이번에 배운 내용들도 블로그에 잘 정리해두려합니다.
 
### 4.리액트와 넥스트 최적화 공부
요즘 많이 드는 생각이 내가 과연 2년차의 실력을 가지고 있는가? 입니다. 구현은 어떻게든 할 수 있지만 코드의 최적화까지 고려하며 기간 내에 작업을 할 수 있는가? 라고 스스로에게 물어본다면 자신이 없습니다. 물론 좋은 코드를 작성하기 위해 노력하지만 때론 시간이 부족하다는 이유로, 혹은 지식 부족으로 놓치는 부분도 많은 듯 하여 최적화 관련하여 강의를 들었습니다. 트리쉐이킹, 레이아웃 쉬프트 방지, 병목 코드 제거 하는 방법, 대용량 리스트 다루는 방법 등 몰랐던 부분이나 알고 있지만 잘 적용하지 못했던 부분들을 다시 공부하며 블로그에도 적용해 둘 예정입니다. 
 
## 10월에는 무슨 일을 할까
 
### 해야 하는 것
 
- **최적화 공부 마무리** : 지금 듣고 있는 최적화 강의를 모두 듣고 블로그에 적용해두는 것 까지 마무리 해보려합니다.
- **타입스크립트** : 타입스크립트도 늘 사용하는 것만 사용한다는 생각이 들어 시간 여유가 많을 때 다시 한번 정리해보려 합니다.
- **Node.js** : 최근 유튜브에서 요즘 같은 시대에 개발자는 사이트는 처음부터 끝까지 만들 줄 알아야 한다는 내용의 영상을 보았습니다. 최근 블로그를 만들며 했던 포스팅 데이터와 이미지를 어떻게 관리할 것인가에 대한 고민과도 맞물리기도 하고 백엔드 지식이 있어야 백엔드 개발자분들과 소통을 원활히 할 수 있겠다는 생각이 들어 Node.js로 백엔드의 세계에 살짝 발 담가보려 합니다.
 
### 하고 싶은 것
 
- **웹에 3D 모델 렌더링하기** : 어워드 사이트 [awwwards](https://www.awwwards.com/)를 보면 3D 모델로 멋지게 만들어둔 사이트가 많아 언젠간 꼭 해봐야지 싶었습니다. 만약 포트폴리오 사이트를 만든다면 꼭 3D 모델을 활용해서 만들어보고 싶습니다.
- **CI/CD 공부** : 최근에 CI/CD를 잠깐 맛봤는데 이게 참 재밌더라고요. 지금은 그냥 테스트 자동화만 된 수준이여서 제대로 된 시나리오 적용해서 파이프라인을 구축해보고 싶다는 생각이 들었습니다.
 
## 포스팅을 마무리하며
 
9월은 정말 폐관수련하듯 노트북 붙들고 블로그 만들고 배포하고 글 쓰고, 사놓고 안들었던 강의들과 미뤄왔던 공부하며 열심히 달려온 것 같습니다. 정말 한달이 길게 느껴졌습니다. 그럼에도 여전히 배워야 할 것들과 배우고 싶은 것들이 넘쳐나서 벅차기도 하고 즐겁기도 합니다. 다만 이번에는 강의를 듣는 것에 많이 집중했기 때문에 10월 달에는 그 내용들을 다시 정리하고 적용해보는 시간을 주로 가져보려 합니다. 날이 선선해진 만큼 밖에도 좀 돌아다녀보고요. 그럼 10월도 화이팅해보겠습니다💪

9월 회고

{intro}
<Spacing size="lg" />

## 이벤트 최적화 하기
 
### 쓰로틀(throttle)
 
#### 쓰로틀 정의
 
사전에서 쓰로틀을 찾아보면 다음과 같은 의미를 가지고 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1EAdQ4Sgn21ZZGOSo_Jw1pnVQilePn3X-" alt="쓰로틀의 의미" width="482" height="223"/>
 
엔진의 속도를 조절하는 조절판, 즉 속도를 조절한다는 의미를 가지고 있습니다. 최적화 기법에서의 쓰로틀은 연속적으로 이벤트가 발생할 때 지정한 시간 주기로 함수를 호출을 조절하는 방식을 의미합니다. scroll, mouse move, resize 이벤트 같이 연속적으로 무수히 많이 발생할 때 특정 주기로 함수 호출해도 되는 경우 최적화하기 유리합니다.
예를 들어 무한 스크롤을 구현한다고 가정해보곘습니다. 리스트의 가장 아래 부분이 화면에 노출될 때 새로운 데이터를 요청하여 화면에 그려주려고 합니다. 이 때 리스트의 가장 아래 도달했는지 확인하기 위해서 스크롤이 발생할 때마다 매번 함수를 호출할 필요는 없을 것입니다. 따라서 쓰로틀을 적용하여 사용성을 해치지 않을 주기마다 함수가 호출되게 최적화하는 것이 좋습니다. 
(element가 화면에 보여질 때를 감지하는 InterSectionObserver를 사용하는 것도 좋은 선택입니다.)
 
#### 쓰로틀 구현
 
그럼 이제 쓰로틀 함수를 구현해보도록 하겠습니다.
 
```javascript
//thtottle.js
const throttle = (callbackFn, delayTime) => {
 let timer = null;
 
 return (...args) => {
 if (timer) {
 return;
 }
 
 callbackFn(...args);
 
 timer = setTimeout(() => {
 timer = null;
 }, delayTime);
 };
};

const log = () => {
 console.log("함수 호출");
};

window.addEventListener("scroll", throttle(log, 600));
```
 
위 코드와 같이 쓰로틀 함수를 구현해보았습니다.
 
>1. throttle 함수는 인자로 특정 주기마다 실행할 callbackFn과 주기를 결정하는 delayTime을 인자로 받습니다.
>2. throttle 함수는 현재 delayTime에 걸려있는지를 알기 위한 timer 변수가 있으며 초기값은 null입니다.
>3. throttle 함수는 익명의 화살표 함수를 리턴합니다.(클로저를 사용하기 위함) 편의상 리턴 함수라고 부르겠습니다. 이 때 리턴 함수는 매개변수 값을 전달 받을 수 있습니다.
>4. 리턴 함수는 throttle 함수의 timer에 접근해 timer 값에 따라 함수 호출 여부를 결정합니다.
> 1. timer에 값이 있다면 아무일도 하지 않고 함수를 종료합니다.
> 2. timer에 값이 있다면 callbackFn을 실행시키고 timer에 setTimeout의 리턴 값이 timeoutId를 할당합니다.
>5. 지정한 delayTime이 지나면 setTimeout의 callback 함수가 실행되며 timer 값이 null이 됩니다.
 
이와 같은 과정을 통해 delayTime마다 callbackFn을 실행시키는 throttle 함수가 구현되었습니다.
이때 클로저를 사용하여 함수가 실행될 때 마다 timer 값이 초기화 되지 않도록 하였습니다. 이에 대해 자세히 알고 싶으시다면 [클로저 포스트](/posts/Javascript/클로저-알아보기)를 참고해주세요.
 
#### 쓰로틀 적용 전 vs 적용 후
 
자 그럼 이제 쓰로틀을 사용하지 않았을 때와 사용했을 때의 차이를 확인해보겠습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1Rwp0BybjWHPH61sTgDi6VfqAPAtgVWkb" alt="쓰로틀 적용 전" width="802" height="342"/>
 
쓰로틀을 사용하지 않으면 함수 호출이 짧은 시간에 120회 가까이 일어납니다😱 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1PFU-_9yXqIzvGO9tVC_A0dI5tsdXRlI-" alt="쓰로틀 적용 후" width="802" height="342"/>
 
그리고 쓰로틀을 적용한 결과 함수 호출이 1/30 수준으로 줄어들었습니다☺️ 
이렇게 쓰로틀을 통해 연속적으로 일어나는 함수 호출을 최적화 해보았습니다.
 
그리고 혹시 아래 두 코드의 차이를 아시나요?
 
```javascript
//code 1
 window.addEventListener("scroll", throttle(log, 600));
```
 
```javascript
//code2
 window.addEventListener("scroll", throttle);
```
 
제가 처음 코드를 배울 때 헷갈렸던 부분이여서 첨언하자면, code1의 경우는 throttle 함수가 실행되어 throttle 함수가 반환하는 리턴함수가 이벤트리스너의 콜백함수로 전달된 것이고
code2의 경우에는 throttle 함수 자체가 이벤트리스너의 콜백함수로 넘겨진 것입니다.
따라서 code2의 경우 제대로 실행되지 않습니다.
 
```javascript
//code3
const handleScroll = throttle(log,600)

 window.addEventListener("scroll", handleScroll );
```
 
위와 같이 handleScroll에 throttle의 리턴함수를 할당하여 사용할 수도 있습니다. throttle 함수는 초기에 실행되어 종료되고 리턴함수가 throttle 함수의 timer 변수에 접근하여 callbackFn 실행 여부를 결정한다고 이해하시면 좋을 것 같습니다👍
 
### 디바운스(debounce)
 
#### 디바운스 정의
 
디바운스의 사전적 의미는 다음과 같습니다. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1VuDX22-YYo9LhbliEj73tFjCyVOKZEM7" alt="디바운스의 의미" width="487" height="183" caption="bounce 하지 않는 것, 그것이 debounce니까 끄덕"/>
 
연속적을 발생하는 바운스를 보정한다는 의미를 가지고 있습니다. 최적화 기법에서의 디바운스는 연속적인 이벤트가 발생하고 지정한 시간이 지난 후에 함수를 호출하는 방식입니다. input, change와 같이 연속적으로 이벤트가 발생하지만 이벤트가 종료된 후 함수를 호출해도 되는 경우 최적화하기 유리합니다. 검색창의 자동 완성 기능처럼 input에 값이 입력될 때 마다 api를 요청하면 단 시간에 엄청나게 많은 요청이 발생하게 됩니다. 이를 방지하기 위해 사용자가 input 창에 검색어를 입력하고 특정 시간이 지난 후 함수를 호출하게 하여 최적화할 수 있습니다.
 
#### 디바운스 구현
 
그럼 디바운스도 구현해보겠습니다.
 
```javascript
//html 코드 생략
const input = document.querySelector("#input");

const debounce = (callbackFn, delayTime) => {
 let timer = null;
 return (...args) => {
 if (timer) {
 clearTimeout(timer);
 }
 timer = setTimeout(() => {
 callbackFn(...args);
 }, delayTime);
 };
};

const logMessage = (event) => {
 console.log(event.target.value);
};
 
input.addEventListener(
 "input",
 debounce((event) => logMessage(event),200)
);

```
 
>1. debounce 함수는 인자로 이벤트가 종료되고 특정 시간 뒤에 실행할 callbackFn과 이벤트 종료 후 시간을 결정하는 delayTime을 인자로 받습니다.
>2. debounce 함수는 현재 delayTime에 걸려있는지를 알기 위한 timer 변수가 있으며 초기값은 null입니다.
>3. debounce 함수는 익명의 화살표 함수를 리턴합니다.(클로저를 사용하기 위함) 편의상 리턴 함수라고 부르겠습니다. 이 때 리턴 함수는 매개변수 값을 전달 받을 수 있습니다.
>4. 리턴 함수는 debounce 함수의 timer에 접근해 timer 값에 따라 setTimeout의 타이머를 취소할 지 결정합니다.
> 1. timer에 값이 있다면 timeoutId 값이 할당된 것이므로 clearTimeout을 통해 해당 timeoutId를 가진 타이머를 취소하여 callbackFn이 실행되지 않도록 합니다.
>5. timer에 setTimeout 타이머의 timeoutId를 할당합니다. 이때 setTimeout의 콜백함수에서 callbackFn이 호출될 수 있게 합니다.
>6. 이벤트가 발생하고 delayTime 동안 이벤트가 발생하지 않으면 callbackFn이 실행됩니다.
 

#### 디바운스 적용 전 vs 적용 후
그럼 이제 디바운스를 적용하지 않았을 때와 적용했을 때를 비교해보겠습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1yOInFW8xaXE-HUL0_0cIK1Gh-kYjDpzX" alt="쓰로틀 적용 전" width="802" height="342" caption="강조되고 반복되는 이벤트는 개발자를 불안하게 해요!!"/>
 
<PostImage src="https://drive.google.com/uc?export=view&id=1M1ePp99TMqSKtySE1-zyZE0wDRIjqpNH" alt="쓰로틀 적용 후" width="802" height="342"/>
 
만약 디바운스를 적용하지 않아 값이 입력될 때 마다 api를 호출했다면 짧은 시간 안에 수십번이나 호출되었겠죠.
디바운스를 적용하면 단 두번만 호출됩니다. delayTime은 사용성을 저하하지 않는 수준으로 맞춰보면 좋을 것 같습니다😄
 
## 포스팅을 마무리하며
 
오늘은 DOM 이벤트를 최적화하는 쓰로틀과 디바운스에 대해 알아보고 구현해보았습니다. 간단하게 구현 가능하지만 효과는 엄청났습니다. 더이상 반복되는 이벤트에 불안해마시고 쓰로틀과 디바운스로 최적화해보시기를 바라며 글을 마치도록 하겠습니다👋👋

쓰로틀과 디바운스로 이벤트 최적화하기

{intro}
<Spacing size="lg" />

## 들어가기 전에
 
- 실행 컨텍스트을 먼저 알아보시는 것을 추천합니다.
 
## 클로저란?
 
일단 클로저란 단어의 뜻을 알아보겠습니다. 클로저는 폐쇄라는 뜻이라고 합니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1WS11Sx5ebdS5RqddZqEZxHwmVsvj7fox" alt="클로저는 폐쇄라는 뜻" width="647" height="242"/>
 
무엇을 폐쇄하는 것일까요? [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures)에서는 자바스크립트의 클로저에 대해 아래와 같이 설명하고 있습니다.
 
> **A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment).** 
> In other words, a closure gives a function access to its outer scope. In JavaScript, closures are created every time a function is created, at function creation time.

 
(Chat GPT가) 번역하자면
 
> **클로저(closure)는 함수와 그 함수가 참조하는 주변 상태(렉시컬 환경)가 함께 묶인 조합입니다.** 즉, **클로저는 함수에 외부 스코프에 접근할 수 있는 능력을 제공**합니다. 
> 
>다시 말해, 클로저는 함수가 정의된 위치의 스코프(외부 환경)를 기억하고, 그 함수가 실행될 때도 그 스코프에 접근할 수 있게 해줍니다. 자바스크립트에서 클로저는 함수가 생성될 때마다 자동으로 만들어집니다.

 
설명을 읽어도 이해하기 쉽지 않습니다. 천천히 정리해보겠습니다. 클로저(폐쇄)란 함수의 스코프가 형성되어 외부에서 접근할 수 없는 상황(폐쇄된 상황)에서 **스코프 안에 선언된 내부 함수를 통해 폐쇄된 함수의 렉시컬 환경을 기억하고 접근할 수 있도록 하는 것**입니다. 여기서 렉시컬 환경에 대해 잠시 이야기하고 넘어가겠습니다. 렉시컬 환경은 실행 컨텍스트에서 함수에 선언된 식별자 정보와 외부 환경에 참조 정보를 가지고 있으며 이를 통해 식별자에 참조할 수 있는 유효범위인 스코프를 형성하게 됩니다. 또한 렉시컬 환경은 선언될 당시의 위치에 따라 결정됩니다. 즉 클로저를 통해 **외부에서 직접적으로 식별자에 접근하는 것을 막고 함수 안에 선언된 내부 함수를 통해서만 식별자에 접근할 수 있게 됩니다. 말로 풀어 설명하려니 어쩐지 미궁에 빠진 것 같습니다😅 코드를 보면 오히려 쉽게 이해할 수 있습니다.
 
```javascript
const outerFunc = () => {
 const number = 0;
 const innerFunc = () => {
 console.log(number);
 };
 return innerFunc;
}

const logNumber = outerFunc();

logNumber(); // 0
```
 
outerFunc는 변수 number와 함수 innerFunc가 선언되어 있고 innerFunc를 리턴하는 함수입니다. 
innerFunc는 outerFunc에 선언된 number 변수를 참조하여 출력합니다.
 
이제 위 코드의 흐름을 살펴보겠습니다.
 
>1. outerFunc가 호출되며 실행 컨텍스트가 콜스택에 추가됩니다. 이때 내부에 선언된 변수 number와 함수 innerFunc는 outerFunc의 렉시컬 환경에 의해 형성된 스코프에 의해 외부에서 직접적으로 참조할 수 없게 폐쇄됩니다. 그리고 현시점에서 innerFunc가 실행되지는 않지만 렉시컬 환경은 선언된 시점에 결정되기 때문에 innerFunc는 자신이 선언된 위치의 렉시컬 환경을 기억하게 됩니다. 
>2. outerFunc가 종료되며 반환한 innerFunc는 logNumber에 할당되고, outerFunc의 실행 컨텍스트는 콜스택에서 제거됩니다.
>3. logNumber(innerFunc)가 호출되며 innerFunc의 실행 컨텍스트가 생성됩니다. 앞서 언급했듯 렉시컬 환경은 선언 시점에 결정되기 때문에 innerFunc의 외부 환경 참조는 outerFunc의 렉시컬 환경이 되며 outerFunc의 렉시컬 환경에 참조할 수 있게 됩니다. 
 
이처럼 클로저는 스코프에 의해 폐쇄된 환경에서 함수(outerFunc)의 실행이 끝난 후에도 내부함수(innerFunc)가 선언된 당시의 렉시컬 환경을 기억하여 함수(outerFunc)의 식별자를 참조할 수 있는 현상을 의미합니다.
 
## 어떤 상황에서 사용할까?
 
이제 클로저가 무엇인지 알아보았으니 어떤 상황에서 사용하는지도 알아보겠습니다.
 
### 1. 데이터 은닉하여 캡슐화를 해야할 때
 
앞서 이야기한대로 외부에서 직접 변수에 접근할 수 없도록 막을 수 있습니다. 이를 데이터를 은닉하여 캡슐화 한다고 하며 이때 캡슐화는 데이터를 외부에서 직접 접근하지 못하도록 보호하는 것을 의미합니다.
 
```javascript
const makeCounter = function () {
 let privateCounter = 0;
 function changeBy(val) {
 privateCounter += val;
 }
 return {
 increment() {
 changeBy(1);
 },

 decrement() {
 changeBy(-1);
 },

 value() {
 return privateCounter;
 },
 };
};

const counter = makeCounter();

counter.increment();
console.log(counter.value()); // 1 

counter.decrement();
console.log(counter.value()); // 0
```
 
MDN에서 가져온 예시코드입니다.
makeCounter라는 함수는 내부에 privateCounter라는 변수를 가지고 privateCounter를 증가시키는 increment 함수, 감소시키는 decrement 함수와 privateCounter을 리턴하는 value 함수가 포함된 객체를 리턴합니다. 
외부에서 직접적으로 privateCounter에 접근할 수 없으며 makeCounter가 리턴하는 함수를 통해서만 privateCounter에 접근할 수 있게 됩니다. 즉 privateCounter 변수를 은닉하여 캡슐화한 것입니다.
 
### 2. 변수의 상태를 유지해야 할 때
 
클로저를 통해 함수가 호출될 때마다 변수가 초기화되지 않고 상태를 유지할 수 있습니다. 함수가 실행될 때 마다 초기화 되지 않고 상태를 유지해야하는 변수가 있다면 외부함수에 선언하고 내부함수에서 접근하는 방식을 통해 변수의 상태를 유지할 수 있습니다. 
지금 바로 생각나는 예제는 쓰로틀 함수입니다. 쓰로틀은 자바스크립트 이벤트 최적화 기법 중 하나로 브라우저의 스크롤 이벤트 같이 연속적으로 무수히 많은 이벤트가 발생할 때 특정 주기에만 함수가 실행되도록 합니다.
쓰로틀에 대해 더 자세히 알아보고 싶으시다면 [쓰로틀 & 디바운스 포스트](/posts/Javascript/쓰로틀과-디바운스로%20-이벤트-최적화-하기)를 참고해주세요.
 
```javascript
 const simpleThrottle = (callbackFn) => {
 let timer;
 const innerFunc(){
 if (timer) {
 return;
 }
 callbackFn();
 timer = setTimeout(() => {
 timer = null;
 }, 1000);
 }
 return innerFunc;
 };
 const logScroll = () => {
 console.log("y :", window.scrollY);
 console.log("time :", new Date().toLocaleTimeString());
 };

 window.addEventListener("scroll", simpleThrottle(logScroll));
```
 
위 코드는 인자로 받은 콜백함수를 1000ms 주기로 호출하는 간단한 쓰로틀 함수입니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1QePamgiolCJRK8782fya6l-GjIh9HYMZ" alt="1초 간격으로 로그가 찍히는 중" width="698" height="546"/>
 
스크롤 이벤트가 발생할 때 1000ms 간격으로 logScroll 함수가 실행되는 걸 확인할 수 있습니다.
 
코드를 자세히 살펴보겠습니다.
 
>1. simpleThrottle 함수(외부함수)가 호출되며 addEventListener의 콜백함수로 simpleThrottle이 반환하는 innerFunc(내부함수)가 전달 된 후 simpleThrottle는 종료됩니다.
>2. 스크롤 이벤트가 일어날 때마다 innerFunc가 호출됩니다. innerFunc는 simpleThrottle의 timer 변수에 접근합니다.(클로저) timer 변수에 값이 있으면 innerFunc를 종료시킵니다.
timer 변수에 값이 없으면 simpleThrottle이 인자로 전달받은 logScroll 함수를 호출하고 timer 변수에 setTimeout 함수의 타이머 식별 값인 timeoutID를 할당합니다.
>3. 스크롤 이벤트는 연속적으로 일어나고 있지만 timer 변수에 timeoutID가 할당되어 있으므로 logScroll를 호출하지 않습니다.
>4. 1000ms 후에 setTimeout의 콜백함수가 실행되며 timer의 값이 null로 재할당됩니다. timer의 값이 falshy하니 다시 logScroll를 호출하고 timer에 timeoutID를 할당합니다.
 
이렇게 스크롤 이벤트가 일어날 때 마다 1000ms 주기로 함수를 실행시킬 수 있게 되었습니다. 
 
만약 클로저를 사용하지 않고 timer 변수를 사용하면 어떻게 될까요?
 
```javascript
const simpleThrottle = (callbackFn) => {
 let timer;
 if (timer) {
 return;
 }
 callbackFn();
 timer = setTimeout(() => {
 timer = null;
 }, 1000);
};

const logScroll = () => {
 console.log("y :", window.scrollY);
 console.log("time :", new Date().toLocaleTimeString());
 }

window.addEventListener("scroll", () => {
 simpleThrottle(logScroll);
});
```
 
<PostImage src="https://drive.google.com/uc?export=view&id=1I7Eb1wgtCD2xdbqIa7UJifyS4afRj3Bs" alt="로그가 무수히 찍히는 중" width="698" height="546"/>
 
scroll 이벤트가 발생할 때 마다 timer 값이 undefined로 초기화되며 연속적으로 logScroll 함수가 실행됩니다😓
 
때문에 timer 변수는 인자로 받아오는 콜백함수가 일정한 주기로 호출될 수 있게 timeoutID 값을 유지하고 있어야 합니다. 이와 같이 함수가 호출될 때 마다 변수가 초기화 되지 않고 상태가 유지되어야 할 때 클로저가 아주 유용하게 사용됩니다👍
 
덧붙이자면 클로저는 잘 모를때는 timer 변수를 전역에 선언하기도 했습니다. 그렇게 사용해도 코드는 의도대로 동작하지만 실제로 timer 변수가 필요한 곳과 너무 동떨어져 있어 코드 가독성이 안좋아지기 때문에 클로저를 사용하는 것을 적극 권장합니다. 
 
## 포스팅을 마무리하며
 
오늘은 자바스크립트의 클로저에 대하여 알아보았습니다. 사실 클로저는 자바스크립트에서만 사용되는 것은 아니고 함수를 인자로 전달 받거나 함수를 리턴하는 고차함수를 사용하는 언어에서 통용되는 개념이라고 합니다. 클로저의 설명만 봐서는 무슨 내용인지 이해하기 어려워서 어려운 개념인가? 싶지만 실제로 코드를 작성해보면 재밌고 유용하다는 것을 알 수 있습니다. 게다가 이미 종료된 함수의 식별자를 기억해서 사용한다니...? 낭만적이기까지 합니다.
 
그런데 아쉬운 점은 제가 실제로 클로저를 사용해본 것은 예시로 들었던 쓰로틀과 디바운스 함수를 작성할 때 뿐이었다는 것입니다. 혹시 클로저를 사용해보셨다면 어떤 상황에서 사용하셨는지 경험을 공유해주시면 너무 좋을 것 같습니다. 그럼 여기까지 글 읽어주셔서 감사드리고 이만 마무리해보도록 하겠습니다👋👋

클로저 알아보기

{intro}
<Spacing size="lg" />

## 자바스크립트 엔진과 런타임 환경
 
<PostImage src="https://drive.google.com/uc?export=view&id=1GWut_okKW71WPVL7UY066r99i0-t_Ysh" alt="자바스크립트 런타임 환경" width="992" height="584"/>
 
**자바스크립트 엔진**은 자바스크립트 코드를 해석하고 실행하는 프로그램입니다. 자바스크립트가 싱글 스레드 언어이기 때문에 자바스크립트 엔진은 **한 번에 하나의 일만 수행 가능**하며 이는 함수의 실행을 관리하는 **콜 스택이 하나**라는 의미이기도 합니다. 대표적으로 크롬과 Node.js에서 사용하는 V8엔진이 있습니다.
 
**자바스크립트 런타임 환경**은 자바스크립트가 실행되는 환경, 즉 크롬과 같은 **브라우저(혹은 Node.js)** 입니다. 브라우저에서 제공하는 Web API들(fetch, setTimeOut, eventListner...)을 통해 **비동기 작업을 지원**하며 이벤트 루프를 통해 비동기 작업의 우선 순위를 정하고 처리합니다.
 
### 콜 스택 (Call Stack)
 
**콜 스택**은 자바스크립트 엔진이 **함수의 실행 순서를 관리하기 위해 사용하는 스택(Stack) 자료구조**입니다. 함수가 호출되며 생성된 실행 컨텍스트가 콜 스택에 차곡차곡 쌓이게 되며 가장 나중에 호출된 함수가 가장 먼저 실행되는**LIFO(Last In First Out)** 구조입니다.
 
### 태스크 큐 (Task Queue)
 
**태스크 큐**는 **브라우저에서 태스크(작업)를 관리하는 큐(Queue) 자료구조**입니다. 비동기적으로 처리되는 작업들(event listner의 콜백함수, setTimeOut 함수의 콜백함수 등)을 관리하는 일종의 **대기소 역할**을 합니다. setTimeOut에서 지정한 시간이 됐거나 click 이벤트가 발생한 시점에 작업(콜백함수)을 태스크 큐에 넣어두어 대기시킨 후 콜 스택이 비워졌을 때 가장 먼저 들어온 작업부터 하나씩 콜 스택으로 이동하는 **FIFO(First In First Out)** 구조입니다.
 
### 마이크로태스크 큐 (Microtask Queue)
 
**마이크로태스크 큐**는 브라우저에서 promise의 콜백함수 즉, then, catch, finally와 mutation observer의 콜백함수 등을 관리하는 큐(Queue) 자료구조입니다. **태스크 큐 보다 높은 우선 순위**를 가지며 콜 스택이 비워졌을 때 먼저 들어온 작업부터 하나씩 콜 스택으로 이동시켜 실행시킵니다. 태스크 큐와 마이크로태스크 큐가 나누어진 이유는 작업 처리에 우선 순위를 두어 **태스크 큐에 있는 작업에 영향을 받지 않고 마이크로태스크를 동일한 환경에서 처리할 수 있기 때문**이라고 합니다.
 
## 이벤트 루프 (Event Loop)란?
 
**이벤트 루프**는 브라우저에 내장된 **비동기 작업을 처리하는 매커니즘**입니다. 말 그대로 계속 루프를 돌며 콜 스택과 태스크 큐, 마이크로태스크 큐를 관찰하며 처리할 작업(콜백함수)이 있다면 순서대로 처리합니다. 
 
## 이벤트루프를 통한 비동기 작업 순서
 
앞서 본 이미지를 보며 비동기 작업이 어떤 순서로 진행되는지 알아보겠습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1GWut_okKW71WPVL7UY066r99i0-t_Ysh" alt="자바스크립트 런타임 환경" width="992" height="584"/>
 
1. 이벤트 루프는 콜 스택이 비워져 있는지 확인합니다.
2. 콜 스택이 비워져 있지 않다면 작업을 콜 스택으로 이동시키지 않습니다. 
3. 콜 스택이 비워져 있다면 마이크로태스크 큐에 있는 작업들을 들어온 순서대로 하나씩 콜 스택으로 이동시킵니다. 앞서 언급했듯 마이크로태스크 큐는 태스크 큐보다 높은 우선 순위를 갖습니다. 
- 콜 스택으로 이동한 콜백함수가 실행, 종료 된 후 콜 스택이 비워지게 되면 다시 마이크로태스크 큐에 있는 작업을 콜 스택으로 이동시킵니다. 이 과정은 마이크로태스크 큐에 있는 모든 작업이 비워질 때까지 반복됩니다. 만일 콜 스택에서 함수가 실행되고 있는 중간에 마이크로태스크 큐에 작업이 추가된다면 해당 작업마저 모두 실행된 후 마이크로태스크 큐가 비워져야 합니다.
4. 콜 스택이 비워져 있고 마이크로태스크 큐에 들어가 있는 작업이 없다면 태스트 큐에 들어있는 작업을 하나씩 들어온 순서대로 처리합니다. 태스크 큐에 있는 모든 작업이 비워질 때 까지 1~4를 반복합니다.
 
이벤트 루프는 위와 같은 과정을 통해 비동기 작업을 처리합니다. 
 
실제로 코드를 통해 이벤트 루프 동작을 살펴볼 겸 한가지 재밌는 실험을 해볼까요?
setTimeOut(()=>{}, 0)이 정말 0ms 후에 실행되는지 알아보겠습니다.
 
```javascript
const runAfterZero = () => {
 const runTime = performance.now();
 console.log("시작!"); // 1번 
 setTimeout(() => {
 const afterTime = performance.now();
 console.log(`실행하는데 걸린 시간 : ${afterTime - runTime}ms`); //2번
 }, 0);
 console.log("끝!"); //3번
 };
runAfterZero();
```
 
<PostImage src="https://drive.google.com/uc?export=view&id=1uuDOMCraKrFf4VQTGAR87CVDNPxOcjZ0" alt="이벤트 루트 동작 확인" width="982" height="162" caption="setTimeOut 0는 0ms 뒤에 실행 되지...않았습니다...!"/>
 
>1. 전역 컨텍스트가 생성되어 콜 스택에 쌓입니다.
>2. runAfterZero 함수가 호출되며 콜 스택에 runAfterZero 함수의 실행 컨텍스트가 쌓입니다.
>3. 1번 로그가 찍힙니다.
>4. setTimeOut이 호출되며 0ms 후에 태스크 큐에 콜백함수가 들어가게 됩니다.
>5. 2번 로그가 찍힙니다.
>6. 함수의 실행 모두 종료된 후 함수 컨텍스트가 콜 스택에서 제거됩니다.
>7. 전역의 코드가 모두 종료된 후 전역 컨텍스트가 콜 스택에서 제거됩니다.
>8. 콜 스택이 모두 비워진 후 태스크 큐에 있는 setTimeOut의 콜백함수가 실행되며 3번 로그가 찍힙니다. 실행되는데 걸린 시간은 0.5ms이네요.🤓

 
여기서 주목해야 할 점은 콜 스택이 비워져 있어야 남아있는 작업을 처리할 수 있다는 것입니다. 만약 실행되는데 아주 오래 걸리는 코드가 있다면 어떨까요? 그 시간동안 마이크로태스크 큐, 태스크 큐에 등록된 작업들은 그저 대기하고 있을 수 밖에 없습니다. 
 
```javascript
const runAfterZero = () => {
 const runTime = performance.now();
 console.log("시작!"); // 1번 코드
 setTimeout(() => {
 const afterTime = performance.now();
 console.log(`실행하는데 걸린 시간 : ${afterTime - runTime}ms`); //2번 코드
 }, 0);
 console.log("끝!"); //3번 코드
 };
runAfterZero();

const start = Date.now();
const duration = 3000;
while (Date.now() - start < duration) {
 const elapsed = Date.now() - start;
}
```
 
아까와 같은 코드이지만 전역에 3초 동안 실행되는 반복문을 추가해보았습니다. 어떨게 될까요? 두근두근
 

<PostImage
 src="https://drive.google.com/uc?export=view&id=1c6camld3ESi41yDJXZKSflvEm6MLzFMv" alt="3초 후 실행" width="498" height="86" />
 
3초 동안 반복문이 실행되고 전역 코드가 모두 종료되어 전역 컨텍스트가 제거된 후 setTimeOut의 콜백함수가 실행됩니다.😱
이렇게 되면 성능에도 좋지 않고 사용자가 화면을 클릭 했을 때 등록된 이벤트 리스너 콜백이 바로 실행되지 않는 등 사용성이 굉장히 떨어질 수 밖에 없습니다.
따라서 setTimeOut(()=>{},0)을 사용하여 복잡한 코드를 나누어 태스크 큐에 넣어두는 방식으로 작업을 관리할 수 있습니다. (저는...그렇게까지 코드 관리해 본 적은 없지만요...)
 
그리고 브라우저는 성능 최적화와 안정적인 사용자 환경을 위해 콜 스택에 있는 함수가 모두 실행된 후 화면의 변경을 업데이트합니다. 보통의 경우에는 60fps (약 16ms) 주기로 업데이트 되지만 콜 스택에서 굉장히 오랫동안 실행되는 코드가 있다면 정상젹으로 UI가 업데이트 되지 않는 이슈가 발생할 수 있기 때문에 역시 너무 크고 복잡한 작업을 나누어 관리하는 것이 중요합니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1iJg8OtBfWQJJYKAhPlLN70GPzxOxyI4a" alt="UI 업데이트 테스트" width="792" height="144" caption="콜 스택에서 함수가 실행될 동안 mouse hover로 인한 UI 업데이트가 되지 않음" />
 

## 포스팅을 마치며
 
오늘은 자바스크립트 런타임 환경에서의 이벤트 루프에 대해 알아보았습니다. 코드를 한줄 한줄 읽어서 실행하는 인터프리어 언어..(하지만 호이스팅!), 싱글 스레드를 가진 동기식 언어..(자, setTimeOut에 코드를 비동기로 싸서 드셔보세요😋) 자바스크립트 당신은 도대체...? 종잡을 수 없지만 알고 보면 다 나름의 이유가 있기 때문에 자바스크립트를 열심히 공부하는 것이 중요하다고 생각됩니다.
 
특히 이번에 이벤트 루프를 정리하며 제가 전역 컨텍스트에 대해서 오해하고 있다는 걸 알게 되었습니다. 저는 전역 컨텍스트가 앱이 실행되는 동안에 계속 콜 스택에 남아 있다고 생각했습니다. 그래서 전역 컨텍스트가 있는데 어떻게 콜 스택이 비워질 수 있지? 하고 고뇌했는데 알고보니 코드 실행이 종료되면 전역 컨텍스트도 사라지게 되는거였습니다. (급하게 실행 컨텍스트 포스트를 수정하러 가는 중 🏃‍♀️🏃‍♀️🏃‍♀️) 이렇게 글로 정리해보며 기존에 잘못 알고 있던 것들도 바로 잡을 수 있어서 블로그를 운영하는 목적을 잘 달성하고 있는 것 같아서 기분이 좋습니다. (하지만 피그마 실력은 도통 나아지질 않습니다... 괴롭...) 
 
뜬금 없지만 내일이 바로 추석입니다. 이 글을 읽으신 분들 모두 즐거운 추석 보내시길(혹은 보내셨길) 바라며 글을 마치겠습니다.🌝👋👋

이벤트루프 알아보기

{intro}
<Spacing size="lg" />

## 사이트맵이란?
 
사이트맵은 사이트에 있는 페이지, 동영상 및 기타 파일과 각 관계에 관한 정보를 제공하는 파일입니다. 사이트맵으로 정보를 제공하여 검색 엔진이 효율적으로 사이트를 크롤링할 수 있게 합니다.
 
```xml
< ?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" 
 xmlns:news="http://www.google.com/schemas/sitemap-news/0.9" 
 xmlns:xhtml="http://www.w3.org/1999/xhtml" 
 xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0" 
 xmlns:image="http://www.google.com/schemas/sitemap-image/1.1" 
 xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
 <url>
 <loc>http://www.yun-log.com</loc>
 <lastmod>2024-09-08T19:17:50.815Z</lastmod>
 <changefreq>daily</changefreq>
 <priority>0.7</priority>
 </url>
 <url>
 <loc>http://www.yun-log.com/posts</loc>
 <lastmod>2024-09-08T19:17:50.815Z</lastmod>
 <changefreq>daily</changefreq>
 <priority>0.7</priority>
 </url>
 </urlset>
```
 
블로그의 사이트맵의 일부를 가져와보았습니다.
사이트맵에서는 검색엔진에 노출되어야 하는 페이지 정보들이 있습니다. 각 파일의 위치(loc), 페이지가 마지막으로 수정된 날짜(lastmod), 페이지의 변경 빈도(changefreq), 페이지 우선순위(priority)등의 정보가 담깁니다. 
 
## next-sitemap 사용하기
 
사이트맵에 페이지 정보를 손수 입력할 수도 있겠지만(😅) 콘텐츠 상세 페이지의 경우에는 동적 라우팅을 하기 때문에 하나하나 입력해주는 것이 어렵겠죠? 이 때 next-sitemap을 사용해서 쉽게 사이트맵을 생성할 수 있습니다. [next-sitemap 공식문서](https://github.com/iamvishnusankar/next-sitemap#readme)를 보며 세팅해보겠습니다.
 
### 설치
 
```terminal
yarn add next-sitemap
```
 
### 설정
 
next-sitemap.config.js 파일을 루트 폴더에 만들어줍니다.
 
```javascript
// next-sitemap.config.js
module.exports = {
 siteUrl: process.env.SITE_URL, //url
 generateRobotsTxt: true, 
}
```
 
package.json scripts에 postbuild 스크립트를 추가해줍니다. 
 
```json
// package.json
{
 "build": "next build",
 "postbuild": "next-sitemap"
}
```
 
```terminal
yarn build
```
 
자 이제 빌드해봅시다. 빌드가 성공적으로 끝나면 사이트맵이 생성됩니다.
파일은 기본적으로 public 폴더에 생성됩니다. <HighlightText type="background" fontWeight={700}>domain/sitemap.xml</HighlightText>로 접근할 수 있어야 하기 때문에 그렇게 설정되어 있는 것 같습니다. (필요에 따라 config 파일에서 outDir를 설정해줘도 됩니다.)
배포 할 때 마다 프로젝트가 빌드되며 사이트맵이 새로 생성될 것이기 때문에 지금 생성한 사이트맵 파일들은 삭제해줍시다.
 
#### 🚨사이트맵 생성 에러 발생 (24.09.10)
 
포스트 작성 후 배포한 뒤 사이트맵이 잘 업데이트되었나 확인했습니다. 그런데 전혀 업데이트되어 있지 않았습니다. 미처 삭제하지 않은 public 폴더 내의 사이트맵 파일 때문인가 싶어 삭제 후 다시 배포했지만, 이번엔 아예 사이트맵이 생성되지 않았습니다😨 
터미널에서 yarn build를 실행해보니 빌드 후 postbuild가 실행되지 않았습니다. 의문인 점은 npm run build 명령어로는 postbuild가 실행되어 사이트맵이 잘 생성된다는 점이었습니다.
분명 처음 세팅할 때 yarn build로도 잘 되는 것을 확인했던 것 같은데 말이죠...
 
```json
// package.json
{
 "build": "next build && next-sitemap",
}
```
 
바로 원인을 찾아 해결할 수가 없어 일단 급하게 build 스크립트를 수정하는 것으로 사이트맵을 생성할 수 있게 해두었습니다.
이 부분에 대해서 추가적로 알게 되는 게 있다면 바로 업데이트해 두겠습니다.
 
**24.09.10 - yarn berry는 lifecycle script를 모두 지원하지 않는다**.
 
분명 처음에 사이트맵이 잘 생성되었던 기억이 있었기 때문에 vercel 배포 로그를 살펴봐야겠다는 생각이 들었습니다. (꼭 자려고 누웠을 때 이런 생각이 들더라고요 😫)
 
<PostImage src="https://drive.google.com/uc?export=view&id=1fm0ly9EGgEC5my4TyHFpAN6pTaY8yX8S" alt="vercel 배포 로그 - 사이트맵 생성 확인" width="905" height="254"/>
 
역시나... 처음 배포 시에는 잘 생성되고 있었습니다. 그럼 언제부터 postbuild가 안됐던걸까 고민하던 차에 눈에 보였던 것이 yarn 버전이었습니다. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1YDeF46BcfJ5mX9aghch5Sl_bRsXJ_kcz" alt="vercel 배포 로그 - yarn 버전 확인" width="674" height="190"/>
 
1.22.19버전...?
그제서야 최근 스토리북을 세팅한 일이 떠올랐습니다. yarn 1버전인 yarn classic을 사용하면 스토리북이 정상적으로 동작하지 않아 yarn berry (4.4.1버전)로 변경했었던 것이죠.
다시 yarn 버전을 1.22.19 버전으로 바꾸고 build 해보니 사이트맵이 잘 생성되었습니다.
그럼 왜 yarn berry에서는 postbuild가 안될까 구글링 하던 차에 yarn berry에서 npm에 존재하는 lifecycle script를 모두 지원하지 않는다는 내용을 찾게 되었습니다.
[yarn 4 버전 life cycle 관련 문서](https://yarnpkg.com/advanced/lifecycle-scripts)
<PostImage src="https://drive.google.com/uc?export=view&id=1Rr4sHoeDunUuEtdsPdOGMmYEgTzfgngw" alt="vercel 배포 로그 - yarn 버전 확인" width="948" height="418"/>
 
위 문서는 yarn 4 버전 이상을 다루고 있다고 하여 yarn 3 버전으로도 시도해 보았지만 마찬가지로 postbuild는 실행되지 않았습니다.
해결 방법이 있나 구글링해도 저와 같은 문제를 겪고 있는 분들의 글을 찾기가 힘들었습니다. (yarn berry랑 next-sitemap 사용하는 사람이 저만 있는 것도 아닐텐데 어째서..?)
yarn classic을 사용하자니 스토리북이 울고, yarn berry를 쓰자니 next-sitemap이 울고 아, 어쩌란 말이냐~ 고민하던 차에 yarn berry + build 스크립트에 next-sitemap을 추가한 현재 방식을 유지하는 것으로 결론 지었습니다.
뭔가 다른 방법을 알고 계시다면 부디 댓글로 가르침을 하사해주세요🥹
 
### 확인
 
<HighlightText type="background" fontWeight={700}>domain/sitemap.xml</HighlightText>에 접속해봅시다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1FOvn2rcsIT2wYeBtUf1vaeMp7JSa5jnN" alt="블로그 사이트맵" width="847" height="222" caption="not 어쩌구 하면 일단 심장 뛰는 사람... XML 파일에 스타일 정보가 없어 문서의 내용만 트리 형태로 보여준다고 합니다."/>
 
사이트맵이 잘 나온다면 성공적으로 생성이 된 것입니다.🥳
 
## 구글 서치 콘솔
 
구글 서치 콘솔은 웹 사이트의 검색 결과를 파악하고 모니터링하여 검색 결과를 개선시킬 수 있게 도와주는 도구입니다. (회사에서는 마케팅팀이 주로 사용하시는 것 같습니다.)
사용하지 않아도 구글 검색 결과에 노출되지만 새로운 페이지가 생성되거나 페이지의 내용이 업데이트 될 때 사이트맵을 새로 제출하면 페이지 색인을 다시 생성하도록 요청할 수 있기 때문에 구글 서치 콘솔에 사이트맵을 제출해보도록 하겠습니다.
 
### 도메인 연결
 
[구글 서치 콘솔 페이지](https://search.google.com/search-console/about?hl=ko)에 들어가봅시다. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1Bx9d7VH5ThjB4FfJqrty9aGDU8KDaq8H" alt="구글 서치 콘솔 시작하기" width="853" height="718"/>
 
로그인 후 시작하기 페이지로 넘어가면 이런 화면이 나옵니다.
사이트 도메인을 입력하고 [계속] 버튼을 클릭합니다. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=117Cx4BBViLt2O_NhsjSo1p1a-WyRn5_j" alt="DNS 설정" width="760" height="706"/>
 
도메인 소유권 인증을 위해 TXT 레코드를 DNS 설정에 추가해줍시다.
 
<Callout icon="❓" title="DNS와 레코드">
**DNS**는 Domain Name System의 약자로 **도메인을 IP 주소로 변환하는 시스템을 의미**합니다.
브라우저 주소창에 yun-log.com 도메인을 입력하면 DNS 서버에 해당 도메인의 IP 주소를 요청하게 됩니다. DNS 서버는 해당 도메인의 IP를 반환하고 브라우저는 반환받은 IP 주소(00.000.000.00의 형태)로 웹 서버에 요청을 보내게 됩니다. 웹 서버는 브라우저의 요청을 받아 해당 페이지의 데이터를 브라우저에 전달하게 되고 그 데이터를 통해 브라우저에 화면이 렌더링 되게 됩니다. 
**레코드**는 데이터를 저장하는 하나의 단위를 의미합니다.
DNS에서의 레코드는 **도메인 이름과 연결된 정보가 기록된 데이터**입니다.
[cloud flare 문서](https://www.cloudflare.com/ko-kr/learning/dns/dns-records/)에 DNS 레코드 유형이 잘 정리되어 있어서 일부 내용을 소개합니다. 
**일반적인 DNS 레코드 유형** 
**A 레코드** : 도메인의 IP 주소를 갖고 있는 레코드.
**CNAME 레코드** : 하나의 도메인이나 하위 도메인을 다른 도메인으로 전달하며, IP 주소를 제공하지는 않습니다.
**TXT 레코드** : 관리자가 레코드에 텍스트 메모를 저장할 수 있습니다. 이 레코드는 종종 이메일 보안에 사용됩니다. 
ᄂ이번 구글 서치 콘솔을 세팅할 때 사용한 TXT 레코드는 도메인 소유권 인증, 보안과 관련 있다고 합니다. 
사실 DNS는 이번에 블로그 도메인을 구매하고 설정해보며 알게 되었습니다. 앞으로는 네트워크 공부도 틈틈히 해두어야겠습니다. 
(공부할 게 너무 많아 즐거운 사람🤥)
</Callout>
 
설정을 완료하면 사이트의 구글 서치 콘솔 대시보드가 나옵니다. 클릭 수 0회... 앞으로 좀 더 힘내보겠습니다(광클 시작🔥)
 
<PostImage src="https://drive.google.com/uc?export=view&id=1pTYOrXq6Nbydbb3mNDa6mm1-pzHGlTyM" alt="구글 서치 콘솔 대시보드" width="902" height="462"/>
 
### 사이트맵 제출
 
왼쪽 사이드 메뉴에서 sitemaps 탭에 들어가 사이트맵을 제출해줍시다. <HighlightText type="background" fontWeight={700}>domain/sitemap.xml</HighlightText>을 입력해주면 됩니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1PYCSL8BlhX4kY5EGrXu-abw-fXFmDOpP" alt="구글 서치 콘솔 대시보드" width="842" height="456"/>
 
### 검색 결과 확인
 
<PostImage src="https://drive.google.com/uc?export=view&id=1fMNAxlMf6jxV_rsFOZ1Aq0QO2b_krtnH" alt="검색 결과" width="842" height="277" />
 
사이트맵을 제출하고 하루 뒤 사이트가 구글 검색 결과에 잘 노출되는 것을 확인할 수 있었습니다🎉 
배포하고 2~3일은 노출되지 않아서 전전긍긍했는데 서치 콘솔에 제출하고 하루 뒤에 바로 노출되었습니다. (단순히 시간이 지나서 노출됐을 가능성이 클 것 같긴 합니다.)
 
## 포스팅을 마무리하며
 
SEO를 위해 next-sitemap을 사용하여 사이트을 만들고 구글 서치 콘솔에 제출까지 해보았습니다. 사실 규모가 작거나 모든 페이지가 사이트에 링크로 잘 연결되어 있는 경우에는 굳이 사이트맵이 필요하지 않다고 합니다. 그래도 이런 세팅 뭔가 재밌으니까..! 해서 나쁠 건 없으니까..! 하는 마음으로 적용해보았습니다. (구글 검색 상위 노출 가보자고 🏃‍♀️🏃‍♀️🏃‍♀️) 그럼 오늘은 이만 글을 마치도록 하겠습니다. 여기까지 글 읽어 주셔서 감사드리고 다음엔 구글 검색 결과 맨 위에서 뵙겠습니다👋👋

next-sitemap으로 사이트맵 만들기

framer motion으로 스크롤 애니메이션 적용하기

{intro}
<Spacing size="lg" />
## 새로운 도전을 앞두고
 
개발 블로그를 해야겠다는 생각은 몇 년 전부터 계속 하고 있었습니다. 다만 생각만 할 뿐 실천은 못하고 있는 상태였습니다. 그러다 작년 Next.js를 공부하며 만든 블로그를 실제로 운영해보기로 결심했지만 내가 개발 블로그를 할 수 있을까 싶은 망설임과 바빠서 시간이 나지 않는다는 핑계로 블로그는 점점 뒷전이 되었습니다. (블로그 : Remember Me🥹)
 
올해 4월 디즈니 애니메이션 '코코'를 보았습니다. 눈물 버튼으로 유명한 영화여서 '절대 안울어야지' 다짐 했지만 결국 눈물을 흘리며 영화관에서 나와버렸습니다.
코코는 음악이 하고 싶은 소년 미구엘(~~기타치는 검은 머리 소년이 코코죠?~~)과 음악을 극도로 싫어하는 가족들과의 갈등을 풀어나가는 내용으로 당연하게도 미구엘과 가족들을 중심으로 이야기가 진행됩니다. 
 
그런데 영화를 보고나서 가장 기억에 남은 인물은 따로 있었습니다.
 
<YoutubePlayer videoId="ZCwXys58lgs" elementId="youtube" start={271}/>
***"내가 너의 첫번째 청중이 될게."***
 
바로 미구엘이 구두를 닦아주던 악사 아저씨입니다. 광장에서 개최되는 음악 페스티벌에 나갈지 말지 고민하던 미구엘에게 기회를 포착하라는 응원과 함께 자신의 기타를 내어주는 장면이 굉장히 인상 깊었습니다. 위 예고편에 나온 분량이 거의 다일 정도록 짧게 스쳐지나가는 조연 캐릭터가 계속 생각 났던 것은 어쩌면 미구엘처럼 새로운 도전을 망설이는 제가 듣고 싶었던 말을 해주었기 때문일지도 모르겠습니다. 그리고 언젠가는 저도 도전을 시작하는 사람에게 용기를 복돋아 주는 사람이 되고 싶다는 생각이 들었습니다. (하지만 모르는 꼬마 개발자한테 맥북 건네주기는 좀 어려울지도요?👩‍🦲)
어쨌든 지금은 망설이기보단 도전할 때라고 생각합니다.
 
## 창피하지만, 일단 배포합니다.
 
블로그를 만들기 시작하면서 정말 여러 고비가 있었습니다. 특히 블로그 디자인이 꽤나 고역이었습니다. 늘 디자인을 받아서 구현하기만 했지 스스로 디자인 했던 경험은 퍼블리싱을 처음 시작하며 포트폴리오를 만들 때 뿐이었습니다. 어찌저찌 완성했지만 기대를 충족하지 못하는 퀄리티에 명색이 프론트엔드 개발자의 블로그인데 이게 맞나..? 싶었습니다. 그 후 두 세번 정도 갈아엎은 결과물이 현재의 화면입니다. (블로그 화면에 대해 피드백 해주신 분들께 정말 무한 감사를 드리고 싶습니다. 피드백을 통해 블로그가 어떻게 발전했는지 과정도 포스팅할 계획에 있습니다😉) 
그리고 디자인만큼 힘들었던 것이 글쓰기였습니다. 블로그를 하기로 마음 먹으면서 생각해둔 포스팅 주제들이 있었고 그 중 제가 가장 잘 알고 있다고 생각한 '변수'에 대한 글부터 쓰기 시작했습니다. 그러나 머리 속에서 알고 있는 것을 글로 풀어내는 것이 생각보다 쉽진 않았습니다. '이 용어가 맞나?', '이 말은 애매모호한데?', '문장이 어색한 것 같아.', '이미지 자료는 어떻게 만들어야하지?' 정말 글을 한줄 한줄 쓸때마다 온갖 고민과 고뇌가 머리속을 스쳤습니다. '내가 안다고 생각했던 게 사실은 아니었나?', '글 하나 쓰는데 이렇게 시간이 오래 걸리는데 어쩌지.', '이런 글이 도움이 될까?', '누가 보고 비웃으면 어떡하지.' 하는 생각이 들어 자신감도 점점 떨어졌습니다. 
그러다 최근 인프런 CTO이신 향로님께서 블로그에 '창피하지만, 일단 해봅니다'라는 책을 소개하신 걸 보고 바로 도서관에서 책을 빌려왔습니다.
책을 읽으면서 창피함을 느낄까봐 망설이며 실천하지 못한 것이 나만의 경험이 아니었구나 싶었습니다. 가끔은 그저 비슷한 경험을 한 사람의 이야기를 듣는 것 만으로도 용기를 얻게 되는 것 같습니다.
 
>실천하기도 전에 "아직 준비가 덜 되어서"라고 말하는 사람이 있다. 우리 인생에서 '준비가 충분히 된 순간'은 영원히 오지 않는다. 시작하기 전에 '준비는 완벽하다'고 생각할지라도 정말 필요한 것은 대부분 나중에 떠오르는 법이다. **해보지 않은 사람의 준비는 당연히 불충분할 수밖에 없다.**

 
특히 위 구절이 인상 깊었는데요. 저도 '블로그의 디자인이 완벽하지 않아서', '기능 구현이 완벽하지 않아서', '다른 사람이 읽을만한 퀄리티의 글이 아니라서' 라며 완벽한 상태가 아니니 아직 배포할 수 없다고 미루고 있었기 때문에 뜨끔하면서도 '그래, 일단 배포하고 보자.'라는 용기가 생겼습니다. 웹은 배포 후에도 언제든지 수정하고 개선할 수 있으니까요. 게다가 다양한 분들의 피드백을 받을 수 있는 기회가 생기는 것이니 '오히려 좋아'입니다.
그렇기에 지금은 완벽하지 않아도, 창피해도 일단 배포해보려 합니다. 
 
## 어떤 이야기를 해나갈까?
 
블로그를 시작하려 마음 먹은 가장 큰 이유는 배운 지식을 다시 정리하기 위함입니다. 포스트를 작성하며 절실히 느끼게 된 것은 강의를 듣거나 문서를 읽는 것 만으로는 온전한 나의 지식이 되지 않는다는 것입니다. 얼렁 뚱땅 알고 있는 부분도 있고 생각을 글로 풀어내려니 막막하게 느껴지기도 합니다. 아마 완전히 제 것으로 소화하는 과정을 거치지 않았기 때문이겠죠. 지식을 정리하기 위해서 혼자만의 공간에 글을 쓰는 것도 좋지만 블로그를 통해 다른 개발자분들과 함께 소통하고 싶은 마음이 컸습니다. (포스트에 오류나 부족한 내용이 있다면 언제든지 피드백 부탁드려요.) 또 지금은 자바스크립트와 관련된 내용을 정리하는데 집중하고 있지만 추후에는 제가 실제로 프로젝트를 진행하며 겪었던 문제점과 해결 방안을 공유할 예정입니다. 제가 개발을 하며 많은 블로그에 도움을 받아왔던 것 처럼 다른 개발자분들께 도움이 된다면 정말 더할나위 없이 기쁠 것 같습니다.🥰 
 
## 쉬엄 쉬엄 그러나 꾸준히
 
회사에서 일을 할 때 가장 크게 느꼈던 것은 배포는 끝이 아니라 시작이라는 것이였습니다. 개발 완료 후 배포까지 마무리되면 후련한 마음이 들기 마련입니다. (아니면 핫픽스로 인한 두근거림?!🫣) 특히 개발하는 과정에서 큰 고통을 겪었던 프로젝트라면 한동안은 쳐다보고 싶지 않기도 합니다. 하지만 사실은 배포 후 서비스가 사용자들에게 선보여진 그 순간부터가 진짜 시작입니다. 실제로 사용하는 과정에서 이슈는 없는지, 우리가 원하는 대로 사용자가 해당 기능을 잘 사용하고 있는지, 배포 이전과 비교하여 불편함을 겪고 있지 않은지 꾸준히 관찰하고 대응해야 하는 것이 필요합니다. 그리고 개발 영역을 떠나서 서비스가 생명력을 가질 수 있도록 꾸준한 컨텐츠 업데이트도 필수겠죠. 컨텐츠가 업데이트 되지 않는다면 사용자들은 서비스에 대한 흥미를 금방 잃을테니까요.
 
지금 배포하려고 하는 블로그 또한 아직 완전하지 않은 상태로 여전히 개선하고 싶은 부분이 많습니다.
현재는 금전적 비용과 시간이 최대한 들지 않는 방향으로 작업하고 있지만 GA를 통해 사용자 추이를 지켜본 후 클라우드 플랫폼 도입도 고려해 볼 예정입니다.
그 외에 멀티 태그 기능, 검색 기능, 포스트를 시리즈 물로 발행하는 기능 등 타 블로그에서 많이 보이는 기능도 구현하고 싶습니다.
그리고 무엇보다 중요한 것은 꾸준히 포스트를 업로드 하는 것일테죠.
지금은 페이지네이션이 필요 없을 정도로 포스트의 수가 적지만 하루 빨리 페이지네이션이 필요할 날이 오면 좋겠네요. 
 
'전진하다'하다 할 때 進 (나아갈 진)자는 辶(쉬엄 쉬엄 갈 착)자와 隹(작은 새 추)자의 조합으로 만들어진 문자입니다. 제멋대로 해석하자면 나아간다는 것은 '작은 새의 발걸음만큼 쉬엄 쉬엄 걸어가는 것'이 아닐까 싶습니다. 제 블로그도 쉬엄 쉬엄 그러나 꾸준히 업데이트 될 예정이니 많은 관심 부탁드립니다.
 
## 포스팅을 마무리하며
 
블로그 배포 기념 회고를 하려 했는데 꽤나 두서없이 이야기를 늘어놓게 되었습니다.😅 요즘 부쩍 생각이 많아져서 그런 것 같습니다. 여기까지 긴 글 읽어주신 분들의 손발을 펴드리며 이만 마치도록 하겠습니다.👋👋

블로그를 배포하며

{intro}
<Spacing size="lg" />
## 실행 컨텍스트란?
 
실행 컨텍스트란 코드를 실행할 때 필요한 문맥을 의미합니다. 글을 읽을 때 문맥을 파악하라는 말을 자주 하죠? 어휘의 의미와 문장의 앞 뒤 상황을 이해하여 글의 흐름을 파악하라는 말인데요. 실행 컨텍스트도 이와 비슷합니다. **실행 컨텍스트는 코드의 실행과 관련된 환경 정보**입니다. 이를 통해 현재 실행되는 코드 내의 식별자 정보와 외부 환경 참조, 함수 실행 순서 등을 관리하게 되는 것이죠.
 
## 실행 컨텍스트의 생성/제거 시점
 
실행 컨텍스트는 코드가 실행되기 전 생성되며, 코드 실행이 완료되면 제거됩니다. 
자바스크립트 소스 코드 타입에 따른 실행 컨텍스트가 생성/제거 시점은 다음과 같습니다
 
### - 전역 코드
함수, 코드 블럭 외부의 코드로 코드가 처음 실행될 때 컨텍스트가 생성되고 코드가 모두 실행되면 제거됩니다.
 
### - 함수 코드
함수 내부에 존재하는 코드로 함수가 호출 될 때 컨텍스트가 생성되고 함수가 종료되는 시점에서 컨텍스트가 제거됩니다. if문, for문과 같은 문(statement)에서는 실행 컨텍스트가 생성되지 않습니다.
 
### - eval 코드
 문자열로 표현된 코드를 실행할 수 있게 해주는 **eval** 함수에 인수로 전달되어 실행되는 코드입니다. eval 함수가 호출될 때 컨텍스트가 생성되고, **eval** 함수가 실행한 코드가 종료되는 시점에 컨텍스트가 종료됩니다.
 
<Callout icon="🚨">
eval은 문자열로 입력받은 코드가 악의적인 내용을 포함하는 등 보안상 위험이 생길 수 있기에 사용을 지양하고 있습니다.
</Callout>
 
### - module 코드
자바스크립트 module 내부에 존재하는 코드로 module이 import 되는 순간 컨텍스트가 생성되며 해당 모듈 코드가 종료될 때 컨텍스트가 제거됩니다.
 
## 콜 스택을 통한 함수 실행 순서 관리
 
일단 콜 스택에 대해 알아보기 전에, 스택에 대해 알고 계시나요? 스택이란 후입선출(LIFO, Last In First Out) 방식의 자료구조를 의미합니다. 즉, **마지막에 들어온 데이터가 가장 먼저 나가게 되는 것**이죠.
 
<PostImage src="https://drive.google.com/uc?export=view&id=14L-2EurAc37t_OeTgtjXLR3eDdOuTTSe" alt="스택" width="375" height="439"/>
 
콜 스택은 자바스크립트에서 함수 호출 시 생성되는 실행 컨텍스트를 관리하는 스택 자료구조입니다. 함수가 호출될 때 마다 콜 스택에 호출된 함수의 실행 컨텍스트가 차곡차곡 쌓이게 됩니다. 이때 가장 위에 쌓인 실행 컨텍스트를 가진 함수가 가장 먼저 실행됩니다. 즉 가장 니중에 호출된 함수가 가장 먼저 실행되는 것이죠. 
 
함수 실행이 완료되면, 그 함수의 실행 컨텍스트는 콜 스택에서 제거되고 그 다음으로 쌓인 실행 컨텍스트의 함수가 실행됩니다. 이렇게 콜 스택을 통해 함수의 실행 순서를 보장하게 되는 것이죠.
 
```javascript

console.log("1. 전역 컨텍스트");

function outerFunc () {
	console.log("1. outerFunc 컨텍스트");
	
	function innerFunc () {
		console.log("2. innerFunc 컨텍스트");
	}
	
	innerFunc();
}

outerFunc();

console.log("4. 함수 실행 컨텍스트가 모두 제거 된 후 전역 컨텍스트만 call stack에 남음");
```
 
위와 같은 코드가 있을 때 콜 스택에 컨텍스트가 쌓이는 과정을 보겠습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1Fce2nPOfLqWtHkuYP-4kPc6vDcyZosRs" alt="실행 컨텍스트가 call stack에 쌓이는 과정" width="688" height="523"/>
 
> 1. 전역 컨텍스트 생성 -> 콜 스택에 쌓임 -> 'console.log("1. 전역 컨텍스트")' 실행 
> 2. outerFunc 호출 -> outerFunc 실행 컨텍스트 생성 -> 콜 스택에 쌓임 -> 'console.log("2. outerFunc 컨텍스트");' 실행
> 3. innerFunc 호출 -> innerFunc 실행 컨텍스트 생성 -> 콜 스택에 쌓임 -> 'console.log("3. innerFunc 컨텍스트")' 실행
> 4. innerFunc 함수 종료 -> 콜 스택에서 제거.
> 5. outerFunc로 복귀 -> outerFunc 함수 종료 -> 콜 스택에서 제거.
> 6. 전역 컨텍스트로 복귀 -> console.log("4. 함수 실행 컨텍스트가 모두 제거 된 후 전역 컨텍스트만 call stack에 남음"); 실행, 코드가 모두 실행된 후 콜 스택에서 제거.
 
이와 같이 코드가 실행되다가 함수가 호출되면 해당 함수의 실행 컨텍스트가 콜스택에 쌓이게 되고 해당 함수가 실행됩니다. 함수가 종료되고 콜스택에서 제거되면 이전 컨텍스트의 함수가 이어서 실행되게 됩니다. 
 
## 실행 컨텍스트에 담긴 정보
 
그럼 이제 실행 컨텍스트에 어떤 정보가 담겨있을지 알아보도록 하겠습니다.
 
### - VariableEnvironment (변수 환경)
 
VariableEnvironment는 컨텍스트 생성 시의 식별자 정보와 외부 환경 참조 정보를 가지고 있습니다. 컨텍스트 생성 될 때 컨텍스트의 내의 식별자를 수집합니다. var의 경우 수집과 동시에 undefined로 초기화됩니다. 컨텍스트 생성 당시의 상태를 기억하며 코드 진행 중에 값이 변경되지 않습니다. LexicalEnvironment와 동일한 구조를 가지기 때문에 자세한 구조에 대해선 LexicalEnvironment에서 이야기 해보겠습니다. 
 
### - LexicalEnvironment (어휘적 환경)
 
LexicalEnvironment 역시 식별자 정보와 외부 환경 참조 정보를 가지고 있습니다. 컨텍스트가 생성 될 시점에는 VariableEnvironment를 복사하기 때문에 값이 동일하지만 코드가 실행됨에 따라 식별자 정보를 업데이트 합니다. (const, let으로 선언한 변수의 초기화, 변수 값 할당, 재할당 등) 실제로 코드가 실행되는 동안에는 LexicalEnvironment를 통해 식별자 정보가 관리됩니다.
 
#### - environmentRecord (환경 기록)
컨텍스트 내에서 수집된 식별자 정보가 있습니다.
 
#### - outerEnvironmentReference (외부 환경 참조)
현재 실행 컨텍스트의 외부 환경을 참조하는 정보입니다. 현재 컨텍스트에 식별자가 존재하지 않을 경우 외부 스코프에서 식별자를 검색합니다. 이를 통해 상위 스코프의 식별자에 접근할 수 있는 것을 스코프체인이라고 합니다. 내부 함수에서는 외부 함수의 식별자를 참조할 수 있지만 외부 함수에서 내부 함수에 참조할 수 없는 이유이기도 합니다.
 
<Callout title="호이스팅">
코드가 실행되기 전 식별자를 수집하는 과정에서 식별자가 코드의 상단으로 끌어올려진 것처럼 동작하는 호이스팅 현상이 발생하게 됩니다. 즉, 실제로 식별자가 코드 위로 끌어올려진 것이 아니라 **environmentRecord**에 수집된 식별자를 컨텍스트 내에서 접근할 수 있게 되는 것이죠. 이로인해 var를 사용한 변수 선언, 함수 선언문에 도달하지 않아도 해당 식별자에 접근할 수 있게 됩니다.
</Callout>
 
<Callout title="var와 const, let의 차이">
var는 변수 선언이 수집됨과 동시에 undefined로 초기화 되기 때문에 변수 선언문 전에 해당 변수에 접근이 가능했습니다. 이런 예기치 못한 동작을 보완하기 위해 나온 const, let은 선언문 이전에 변수가 초기화 되지 않는데요. 코드가 실행됨에 따라 변수 선언문에 도달했을 때 비로소 변수가 초기화되고 LexicalEnvironment가 업데이트 됩니다. 따라서 세 가지 키워드로 선언된 변수 모두 호이스팅 현상이 발생하지만 const, let은 변수 수집 후 초기화 되기 이전 영역인 TMZ(일시적 사각지대)에서는 변수에 접근할 수 없기 때문에 변수 선언문 이전에 접근할 수 없게 되는 것이죠.
</Callout>
 
<Callout icon="🤔" title="블록은 어떻게 스코프를 생성할까?">
실행 컨텍스트는 함수 호출 시에 생성된다고 이야기 했습니다. 그렇다면 블록에서는 어떻게 스코프가 만들어질까요? 바로 블록 코드가 실행될 때 LexicalEnvironment가 생성되기 떄문입니다. 이를 통해 블록 내부 식별자를 관리하고 스코프 체인을 통해 외부 환경의 식별자에도 접근할 수 있게 됩니다. 그리고 블록 내의 코드가 모두 종료 되었을 때 LexicalEnvironment가 제거됩니다.
</Callout>
 
### - ThisBinding(This 바인딩)
 
**This Binding**은 **this**의 값을 결정하는 정보로, 함수 호출 시 **this**가 참조할 객체를 결정합니다.
 
## 포스팅을 마무리하며
 
이렇게 자바스크립트 코드가 실행될 때의 환경 정보인 실행 컨텍스트에 대해서 알아보았습니다. 이를 통해 호이스팅, 스코프 체이닝, this 바인딩 등 자바스크립트에서 발생하는 다양한 현상들에 대해 이해할 수 있었습니다. 이번 포스팅을 통해 원래 그런 것, 그냥 그런 것은 없다는 사실도 다시끔 느끼게 되었네요. 
 
사실 실행 컨텍스트는 블로그를 시작하며 언젠가 꼭 다뤄야지 했던 주제입니다. 처음 변수 포스팅을 할 때도 '아 이걸 설명하려면 실행 컨텍스트 이야기를 해야하는데' 하면서 어디부터 어디까지 이야기해야하나 참 고민이 많았는데 이렇게 포스팅할 수 있게 되어서 숙제를 덜어낸 기분입니다. 그럼 후련한 마음으로 글을 마무리 하도록 하겠습니다. 여기까지 긴 글 읽어주셔서 감사합니다.😊

실행 컨텍스트 알아보기

this 바인딩 알아보기

{intro}
<Spacing size="lg" />

## 프로토타입이란?
 
 사전적 의미의 프로토타입은 원래의 형태 또는 전형적인 예, 기초 또는 표준입니다. 원래의 형태, 즉 원형에 주목하여 자바스크립트에서의 프로토타입을 정의하면 **특정 객체의 원형이 되는 부모 객체**라고 할 수 있습니다. 자바스크립트에서 대부분의 객체는 원형 객체, 즉 프로토타입을 가지게 되며 프로토타입에 있는 프로퍼티와 메서드를 상속 받아 사용할 수 있게 됩니다.
 
```javascript
const obj = {};

console.log(obj)

console.log(obj.[[Prototype]]);
// SyntaxError: Unexpected token '['
console.log(Object.getPrototypeOf(obj))
```
 
<PostImage src="https://drive.google.com/uc?export=view&id=1rxr4x95OyzOjQky0mx6QH4HSLJt6xDR6" alt="obj의 프로토타입" width="400" height="263" />
 
객체 리터럴을 통해 빈 객체 obj를 만들고 콘솔을 통해 확인해보면 [[prototype]]에 Object 프로토타입이 존재하는 것을 확인할 수 있습니다. 또한 프로토타입에 정의된 메서드를 사용할 수도 있죠.
 
다만 직접 프로토타입에 접근하려고 할 때 obj.[[Prototype]]으로는 접근할 수 없고 Object.getPrototypeOf() 메서드를 사용하여 객체의 프로토타입에 접근할 수 있습니다. 
 

 
## 프로토타입을 사용하는 이유
 
**자바스크립트는 객체 지향 프로그래밍 언어**입니다. 객체 지향 프로그래밍이란 데이터를 객체 단위로 묶고, 객체 간의 상호작용을 통해 프로그램을 구성하는 방식을 말하는데요. 
객체 지향 프로그래밍의 특징으로는 **각 객체 간의 공통된 속성(프로퍼티)과 기능(메서드)을 추려 정의**하는 <HighlightText type="background" fontWeight={700}>추상화</HighlightText>가 있습니다.
 
아이돌 그룹 에스파를 예로 들어볼까요? (사심 1000%)
 
에스파 각 멤버들의 공통된 속성을 떠올려봅시다. 멤버들은 이름, 포지션(메인보컬, 메인 댄서…)과 같은 속성(프로퍼티)을 가지고 있을 것이고 랩, 댄스, 노래와 같은 공통된 기능(메서드)을 수행합니다. 이렇게 공통된 특징을 추리고 정의하는 것을 추상화라고 합니다. 
 
```javascript
function Idol(name, role) { 
// 각 멤버들의 공통된 속성과 기능을 정의 (추상화)
	this.name = name;
 this.role = role;
 this.rap = () => {
		console.log(`${this.name}이(가) 랩을 한다.`);
 };
 this.dance = () => {
	 console.log(`${this.name}이(가) 춤을 춘다.`);
 };
 this.sing = () => {
	 console.log(`${this.name}이(가) 노래를 한다.`);
 };
}

// Idol 생성자 함수를 통해 멤버(instance) 생성
const karina = new Idol("카리나", "메인 댄서"); 
const winter = new Idol("윈터", "메인 보컬");
const ningning = new Idol("닝닝", "리드 보컬");
const giselle = new Idol("지젤", "메인 랩퍼");

console.log(karina);
console.log(winter);
console.log(ningning);
console.log(giselle);

```
 
<PostImage src="https://drive.google.com/uc?export=view&id=15Y3Ftl1Ka_r0jI3BEx7tEThXU107Yhmk" alt="프로토타입 체이닝" width="400" height="449"/>
 
이렇게 각 멤버들의 공통된 프로퍼티와 메서드를 추상화하여 Idol 생성자 함수를 만들고 생성자 함수를 통해 멤버(인스턴스)들을 만들 수 있게 되었습니다. 
 
그런데 name과 role처럼 인스턴스마다 고유한 값을 가지는 경우가 아닌 항상 동일한 기능을 수행하는 rap, dance, sing을 살펴봅시다. 완전히 같은 기능을 수행하는 메서드가 각 인스턴스 마다 포함되어 있는데요. 이렇게 되면 생성자 함수를 통해 만들어진 인스턴스의 수만큼 같은 코드가 중복으로 생성되게 됩니다. 실제로 각 메서드는 완전히 동일하지만 각각 중복으로 메모리에 저장되어있기 때문에 값을 비교하면 false가 나오게 되는 것을 알 수 있습니다.
 
 ```javascript
console.log(karina.dance === winter.dance); // false
```
 
이처럼 인스턴스가 생성될 때마다 같은 코드가 중복으로 생성되어 메모리에 저장된다면 프로그램의 성능이 저하될 수 있겠죠.
 
이런 불필요한 중복 방지를 위해 필요한 것이 바로 <HighlightText type="background" fontWeight={700}>상속</HighlightText>입니다. 상속이란 **특정 객체의 속성이나 프로퍼티를 다른 객체가 그대로 이어받아 사용할 수 있는 것**을 말합니다. 그리고 자바스크립트는 바로 프로토타입을 사용하여 상속을 구현합니다.
 
```javascript
function Idol(name, role) {
	this.name = name;
 this.role = role;
}

Idol.prototype.rap = () => {
 console.log(`${this.name}이(가) 랩을 한다.`);
};
Idol.prototype.dance = () => {
	console.log(`${this.name}이(가) 춤을 춘다.`);
};
Idol.prototype.sing = () => {
	console.log(`${this.name}이(가) 노래를 한다.`);
};

const karina = new Idol("카리나", "메인 댄서"); 
const winter = new Idol("윈터", "메인 보컬");

console.log(karina.dance === winter.dance); //true
```
 
생성자 함수를 통해 생성된 인스턴스는 해당 생성자 함수의 prototype 프로퍼티를 프로토타입으로 가지는데요.
(저는 예전에 karina의 프로토타입이 Idol이라고 착각한 적이 있는데 Idol은 생성자함수인 것이고 Idol.prototype이 karina의 프로토타입이 됩니다.)
 
위와 같이 Idol.prototype을 통해 공통된 메서드를 정의하게 된다면 이제 모든 인스턴스들은 프로토타입에 정의된 메서드를 상속받아 사용할 수 있게 되고 더이상 여러번의 불필요한 코드 중복을 발생시키지 않게 됩니다. karina.dance와 winter.dance를 비교해도 true가 나오는 것을 알 수가 있습니다.
 
이처럼 프로토타입은 자바스크립트의 객체 지향 프로그래밍에서 상속을 구현할 수 있게 하며 자바스크립트가 프로토타입 기반의 객체 지향 언어라고 불리는 이유이기도 합니다.
 
## 상속 구현하기
 
이제 우리는 프로토타입이 무엇인지 프로토타입을 왜 사용하는지에 대해 알게 되었습니다. 
그럼 이제 프로토타입을 이용하여 상속을 구현해봅시다.
 
```javascript
function Singer(name){
	this.name = name;
}
 
Singer.prototype.sing = function () {
	console.log(`${this.name}이(가) 노래를 한다.`);
};

function Idol(name, role) {
 Singer.call(this, name); // Singer 생성자 함수를 호출
	this.role = role;
}

Idol.prototype = Object.create(Singer.prototype); // prototype 연결

Idol.prototype.rap = function () {
	console.log(`${this.name}이(가) 랩을 한다.`);
};

Idol.prototype.dance = function () {
	console.log(`${this.name}이(가) 춤을 춘다.`);
};

const karina = new Idol("카리나", "메인 댄서");

karina.dance();

```
 
1. Object.create('Signer.prototype') 을 사용하여 새 객체를 생성합니다. 이때 첫번째 인자에 들어가는 값이 생성되는 객체의 프로토타입이 됩니다. 
즉 Idol.prototype은 Singer.prototype을 프로토타입으로 갖게 됩니다. (프로토타입탈트 붕괴..)
2. Idol 생성자 함수에서 Singer 함수를 호출합니다. 이때 call 메서드를 사용하여 this와 인자값을 전달합니다.
 
이제 Singer.prototype을 상속받아 karina.sing()를 호출할 수 있습니다!
 
## 프로토타입 체이닝
 
위 예제에서 karina 객체 내부에 dance 메서드가 없어도 실행시킬 수 있었는데요. 이는 객체에서 프로퍼티를 찾을 때 객체 내부에 해당 프로퍼티가 없다면 그 객체의 프로토타입을 확인하며 계속 위로 올라가면서 찾는 과정인 프로토타입 체이닝이 있기 때문입니다. 이를 통해 자바스크립트는 상속을 구현하게 됩니다. 그리고 프로토타입 체이닝의 끝에는 최상위 프로토타입인 Object.prototype이 있습니다. 즉 거의 모든 자바스크립트 객체는 Object.prototype를 상속 받게 됩니다.
(맨 처음 프로토타입을 정의할 때 예시코드에서도 빈 객체인 user에 Object 프로토타입이 있었죠?)
 
## 상속 확인 하기
 
이렇게 상속이 이어지다 보면 특정 인스턴스가 어떤 생성자 함수를 통해 만들어졌는지 헷갈릴 수도 있을텐데요. 이럴때는 instandeOf 연산자를 사용하여 확인하면 됩니다. 인스턴스 instanceof 생성자 생성자 함수를 통해 생성된 인스턴스이면 true, 아니라면 false를 리턴합니다.
 
```javascript
console.log(karina instanceof Singer)// true;
console.log(karina instanceof Idol) //true;
console.log(karina instanceof Actor) //false
```
 
## 오버라이딩
 
같은 프로토타입을 공유하고 있는 객체 중 하나의 객체에서만 프로퍼티나 메서드를 수정하고 싶을 땐 어떻게 해야할까요? 이를 위해 프로토타입에 정의된 메서드를 하위 객체에서 재정의하는 오버라이딩에 대해 알아봅시다.
 
에스파의 메인보컬인 닝닝은 주로 고음을 담당합니다. 닝닝의 sing 메서드를 수정해봅시다.
 
```javascript
ningning.sing = ()=>{
	console.log(`${this.name}은(는) 고음을 부른다.`);
}

ningning.sing(); //닝닝은(는) 고음을 부른다.
giselle.sing(); //지젤이(가) 노래를 부른다.

```
 
ningning.sing을 재정의하여 ningning.sing이 오버라이딩 되었습니다. 하지만 giselle.sing은 기존의 메서드를 유지하고 있죠. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1Tn8U4kWBrZno1r4QlFeG00n1z1m68DEc" alt="Idol의 instance" width="400" height="177"/>
 
이것은 ningning.sing을 오버라이딩 할 때 프로토타입의 메서드를 수정한 것이 아니라 ningning 인스턴스에 메서드로 추가된 것이기 때문입니다. 이처럼 인스턴스 프로퍼티(프로퍼티와 메서드를 모두 포함)에 의해 프로토타입 프로퍼티가 가려지는 현상을 프로퍼티 섀도잉이라고 합니다.
 
## 포스팅을 마치며
 
여기까지 프로토타입의 의미, 왜 프로토타입이 사용되는지, 프로토타입을 통한 상속 구현에 대해 알아보았습니다. (더 상세한 내용을 알고 싶으시다면 자바스크립트 딥다이브 책을 추천드려요. 무려 50 페이지에 걸친 방대한 내용이 여러분을 기다리고 있습니다.) 
 
사실 요즘에는 Class 문법을 사용하는 추세지만 그래도 그 근간에는 프로토타입이 있기 때문에 자바스크립트를 사용하는 개발자라면 프로토타입에 대해 알아두는 것이 중요할 것 같습니다.
 
포스팅 시작 전에 말했듯 프로토타입에 대해 어렴풋이 알고 있었지만 말로 설명하기가 어려웠는데요. 일단 프로토타입에 대해 완전히 이해하지 못한 상태였고 또 너무 방대한 내용이여서 어디부터 어디까지 이야기 해야할지 몰랐던 것 같기도 합니다. 하지만 이번 기회를 통해 프로토타입에 대해 명확히 알 수 있었고 자바스크립트 상속 매커니즘을 엿볼 수 있어서 재밌었습니다. 가끔 인스턴스, 프로토타입탈트 붕괴 현상이 찾아오긴 했지만.. 글을 읽으시는 분들도 많이 헷갈리실 것 같아서 걱정이 듭니다. 긴 글 읽어주셔서 감..사건은 다가와 Oh Eh 👻

프로토타입(ProtoType) 알아보기

{intro}
<Spacing size="lg" />

## 원시 타입 (Primitive Type)
 
- 원시타입에는 총 6가지의 데이터 타입이 있습니다. (아래 표 참고)
- 변수에 **실제 값이 직접 저장**되는 데이터 타입입니다.
- **불변한(immutable)** 값이며 재할당 시 기존 메모리 공간을 덮어 쓰는 것이 아니라 새로운 메모리 공간에 값을 저장하고 식별자는 새로운 메모리 주소를 가리키게 됩니다.
- 원시 값을 갖는 변수를 다른 변수에 복사하면 원본의 **값 자체가 복사**됩니다.
 
| 데이터 타입 | 예시 값 | 부연 설명 |
| --- | --- | --- |
| 문자열 (string) 타입 | ‘가나다’, ‘1234’ | |
| 숫자 (number) 타입 | 123, -123, infinite, NaN (Not a Number) | |
| boolean 타입 | 논리 값, 참 (true)과 거짓 (false) | |
| undefined 타입 | undefined (변수에 값이 할당되지 않았을 때 초기 값) | |
| null 타입 | null (’값이 없음’을 명시할 때 사용) | typeof 사용 시 object가 나옴 |
| symbol 타입 | 변경 불가능한 원시타입 값 | |
 
<PostImage src="https://drive.google.com/uc?export=view&id=1SeVPcTnmDHVUgCGwWAcncEzvDP-kJsBt" alt="원시형 데이터" width="660" height="795"/>
> 1. 실제 값 123456가 password 변수에 저장됩니다.
> 2. password를 복사한 copyPassword는 password의 값 123456을 복사합니다.
> 3. password에 654321로 값을 재할당하면 기존의 123456 값을 수정하는 것이 아니라 새로운 메모리 공간에 저장되며 password 식별자는 새로운 값이 담긴 메모리 주소를 가르킵니다.

 
<Callout title="데이터 타입을 확인하고 싶을땐?">
typeof 연산자를 사용하면 데이터 타입을 문자열로 반환합니다.
</Callout> 
 
```javascript
console.log(typeof true); // boolean
console.log(typeof "true") //string
```
 
## 객체 타입 (Object Type)
 
- 원시형 데이터가 아닌 모든 데이터 타입이 객체 타입 데이터입니다. (객체, 배열, 함수 등)
- 객체 데이터는 **크기가 동적으로 바뀔 수 있기에 힙 메모리에 저장**되며 변수에는 **데이터의 메모리 주소가 저장**됩니다.
- **변경 가능(mutable)**한 값이며 객체의 프로퍼티를 바꾸는 것이 가능합니다.
- 객체 타입 변수를 다른 변수에 복사하면 원본의 **메모리 주소 값이 복사**됩니다.
- 같은 주소를 바라보고 있기 때문에 **복사한 객체를 수정하면 원본 객체도 같이 수정됩니다.**
 
<PostImage src="https://drive.google.com/uc?export=view&id=1PlT7EDKxpr3AAoqW9WGBHwYvJO8Ymkr3" alt="" width="660" height="972"/>
 
> 1. userInfo는 객체가 저장된 주소를 저장합니다.
> 2. copyUserInfo는 userInfo 객체가 저장된 주소 값을 복사합니다.
> 3. 객체 타입 데이터는 변경 가능한 값이므로 프로퍼티를 바꾸는 것이 가능합니다. userInfo.name이 '김유저'에서 '이유저'로 변경
> 4. userInfo와 copyUserInfo는 같은 객체를 참조하고 있기 때문에 userInfo.name도 '이유저'가 됩니다. 

 
<Callout title="배열은 무슨 타입일까?">
array는 배열이지만 데이터 타입은 **object**로 나오는 걸 볼 수 있습니다. 객체형 데이터 중 function만 예외적으로 **function** 타입을 반환합니다.
Array.isArray() 메서드를 사용하여 배열인지 아닌지 확인할 수 있습니다.
</Callout>

 
```javascript
const array = [];
const func = function (){}

console.log(typeof func) //function
console.log(typeof array); // object
console.log(Array.isArray(array)) //true

```
 
## 🚨객체형 데이터를 다룰 때 주의해야 할 점
 
```javascript
const userInfo = {
	id: 1,
	name: "김유저",
};

const copyUserInfo = userInfo;

copyUserInfo.name = "이유저"; // 복사한 객체에서 데이터 수정

console.log(userInfo.name) // "이유저", 복사한 객체를 수정하였지만 원본 객체도 수정되었다!
```
 
위 코드 처럼 copyUserInfo를 수정하면 원본인 userInfo도 수정됩니다. **두 변수가 같은 메모리 주소를 바라보고 있기 때문입니다.** 원본을 수정하려고 의도한 것이 아니었다면 예기치 못한 에러가 날 수도 있겠죠. 때문에 객체형 데이터를 복사할 때는 원본 데이터에 영향을 미치지 않도록 **불변성을 유지하는 것이 중요합니다.**
 
## 불변성을 유지하며 객체 타입 복사하기
 
객체의 복사는 얕은 복사와 깊은 복사가 있습니다. <HighlightText type="background" fontWeight={700}>얕은 복사</HighlightText>란 **복사 데이터의 속성이 원본 데이터와 같은 참조를 공유하는 경우**이고 <HighlightText type="background" fontWeight={700}>깊은 복사</HighlightText>는 **원본 데이터와 공유하는 참조값이 없는 복사**로 원본 데이터의 불변성을 유지할 수 있습니다.
 
### 얕은 복사(Shallow Copy)
 
#### 1. spread 연산자 
객체와 배열을 쉽게 복사할 수 있는 방법으로 spread 연산자(...)가 있습니다. spread 연산자를 사용하면 배열이나 객체를 펼쳐서 개별 요소로 분리할 수 있습니다. 사용하기도 쉽고 보기에도 간결하기 때문에 저는 많은 경우 spread 연산자를 사용하여 객체 데이터를 복사합니다.
 
```javascript
const user = {
	id:123456,
	address: "우리 집",
};
const copyUser = {...user};

console.log(user === copyUser) //false


const colors = ["빨강", "주황", "노랑"];
const copyColors = [...colors];

console.log(colors === copyColors) //false
```
 
user와 colors를 spread 연산자로 분리한 후 새로운 객체와 배열로 만들었습니다. 원본 데이터와 비교해보면 false가 나오는 걸 볼 수 있습니다.
이제 복사 데이터를 변경해도 원본 데이터에 영향이 가지 않습니다.
 
```javascript
const userList = [
 {
 id: 1,
 name: "김유저",
 },
 {
 id: 2,
 name: "이유저",
 },
 {
 id: 3,
 name: "박유저",
 },
];

const copyUserList = [...userList];
console.log(userList === copyUserList);// false
console.log(userList[0] === copyUserList[0]); 
//true, 같은 메모리 주소를 가지고 있음, 불변성 보장 ❌
```
 
다만 spread 연산자는 얕은 복사를 하기 때문에 최상위 속성만 복사하며 중첩된 객체, 배열의 불변성을 보장하지 않습니다.
 
#### 2. Object.asign()
Object.assign()는 첫 번째 인자인 대상 객체에 두 번째 이후의 인자인 소스 객체들의 속성을 대상 객체에 복사하고 병합한 후 대상 객체를 반환하는 메서드입니다.
이또한 얕은 복사이기에 중첩 객체 데이터의 불변성은 보장되지 않습니다.
 
```javascript
const targetObj = {
 a : 1,
 b : 2
}
const sourceObj = {
 c : 3,
 d : 4
}

const assignedObj = Object.assign(targetObj,sourceObj); 
// targetObj에 sourceObj의 속성을 복사하고 병합한 후 targetObj가 반환
console.log(assignedObj);
// {
// a : 1,
// b : 2,
// c : 3,
// d : 4
// }
console.log(targetObj ===assignedObj) // true
```
 
targetObj에 sourceObj의 속성을 복사한 후 병합할 수 있습니다.
 
```javascript 
const userInfo = { 
 id : 1,
 name : "김유저"
};
const copyUserInfo = Object.assign({},userInfo); 
//대상 객체 {}에 userInfo 객체의 속성을 복사하고 병합하여 대상 객체를 반환

console.log(userInfo === copyUserInfo); // false
```
 
이런 식으로 얕은 복사를 할 수 있게 됩니다.
 
#### 3. Array.from()
 
Array.from()은 원본 배열을 얕게 복사한 새로운 배열을 반환합니다.
```javascript
const userList = [
 {
 id: 1,
 name: "김유저",
 },
 {
 id: 2,
 name: "이유저",
 },
 {
 id: 3,
 name: "박유저",
 },
];
const copyUserList = Array.from(userList);
console.log(userList===copyUserList);//false

```
 
#### 4. 새로운 배열을 리턴하는 배열 메서드
 
배열의 경우 map, filter, slice, concat, reduce 등 **새로운 배열을 리턴하는 배열 메서드**를 사용하여 얕은 복사가 가능합니다.
대표적으로 많이 쓰이는 map의 경우를 살펴보겠습니다.
 
```javascript
const userList = [
 {
 id: 1,
 name: "김유저",
 },
 {
 id: 2,
 name: "이유저",
 },
 {
 id: 3,
 name: "박유저",
 },
];
const copyUserList = userList.map((userItem)=>({...userItem}));
console.log(userList===copyUserList);//false
console.log(userList[0] ===copyUserList[0])//false

```
 
배열 메서드도 얕은 복사를 하지만 callback 함수 안에서 userList의 원소인 userItem을 다시 한번 복사하는 것이 가능합니다.
 

### 깊은 복사(Deep Copy)
깊은 복사를 하기 위해서는 재귀함수를 사용하여 deepCopy 함수를 구현하거나 deepCopy 기능을 제공하는 라이브러리를 사용하시면 됩니다.
(라고 Chat GPT가 알려줬습니다. 저는 프로젝트에서 깊은 복사를 해본 경험은 없네요😥) 
프로젝트에 따라 직접 구현 또는 관련 라이브러리 도입을 고민해보면 될 것 같습니다. 저는 공부 목적으로 깊은 복사를 직접 구현해보겠습니다.
 
#### 1. deepCopy 함수 구현하기
 
> **목표 : 데이터를 돌면서 프로퍼티 혹은 원소가 object 타입이 아닐때까지 재귀적으로 값을 얕은 복사하여 결과적으로 원본 데이터와의 참조 값을 완전히 끊어낸다.**
> 
> 1. base case : 인자로 받아온 data의 타입을 체크한 한 후 object 타입이 아니라면 data를 리턴.
> 2. data가 배열인 경우 : map을 사용하며 원소를 재귀적으로 복사 후 리턴.
> 3. data가 object인 경우 : for in 반복문을 사용하여 속성을 재귀적으로 복사 후 result에 추가, result 리턴

 
```javascript
const deepCopy = (data) => {
 // null의 type이 object이므로 주의해서 조건에 추가.
 if (data === null || typeof data !== "object") {
 return data;
 }
 if (Array.isArray(data)) {
 return data.map((item) => deepCopy(item));
 }
 const result = {};
 for (key in data) {
 result[key] = deepCopy(data[key]);
 }
 return result;
};

const userList = [
 {
 name: "김유저",
 address: {
 country: "한국",
 city: "서울",
 coordinates: [126.978, 37.5665],
 },
 hobbies: ["달리기", "책 읽기"],
 },
 {
 name: "이유저",
 address: {
 country: "미국",
 city: "워싱턴 DC",
 coordinates: [74.006, 40.7128],
 },
 hobbies: ["게임하기", "등산"],
 },
 {
 name: "박유저",
 address: {
 country: "일본",
 city: "도쿄",
 coordinates: [35.6828, 139.7595],
 },
 hobbies: ["영화보기", "테니스"],
 },
];

const copiedUserList = deepCopy(userList);
console.log(
 userList[1].address.country[0] === copiedUserList[1].address.coordinates[0]
 ); //false
```
재귀적으로 데이터를 얕은 복사하는 deepCopy 함수를 쓰니 배열안의 객체안의 배열의 값을 비교해도 false가 나옵니다 🎉
 
(딴소리지만 재귀함수를 사용할 때는 재귀함수 종료 조건인 base case를 잘 설정해줍시다. 
조건을 data === null <HighlightText type="background">&&</HighlightText> typeof data !== "object"로 넣었다가 눈물이 찔끔 나왔버렸습니다.)
<PostImage src="https://drive.google.com/uc?export=view&id=1WC-1hkUU_hwYWNap9E6gD7F4FByIEtX-" alt="스택오버플로우" width="440" height="177"/>

 
## 포스팅을 마치며
 
오늘은 원시형 데이터와 객체형 데이터의 특징과 데이터의 불변성을 유지하는 방법에 대해 알아보았습니다. 처음 포스팅을 시작할 때도 이야기했듯이 자바스크립트를 처음 배울 때는 원시형 데이터와 객체형 데이터를 나누는 큰 특징보다는 원시형 데이터에 더 집중해서 공부했었습니다. 그러다 리액트를 접하게 되고 객체형 데이터의 특성을 이해하는 것이 중요하다는 것을 알게 되었습니다. 리액트는 state의 변화에 따라 화면을 리렌더링 하기 때문에 객체를 변경해도 주소 값이 같다면 리렌더링이 안 되는 이슈가 발생할 수 있었기 때문이죠. 따라서 원본 객체와 다른 주소 값을 가지는 새로운 객체를 만들어 원본 객체의 불변성을 유지할 필요가 있었습니다. (물론 리액트를 사용하지 않더라도 복사된 데이터에 의해 원본 데이터가 수정되지 않도록 불변성을 유지하는 것은 중요한 일입니다.) 이때 다시 한 번 느끼게 된 것은 어떤 라이브러리를 사용하더라도 자바스크립트의 특성을 알고 있는 것이 중요하다는 것이었습니다. 만약 객체형 데이터의 특성을 모른다면 리렌더링 이슈가 발생했을 때 왜 이런 이슈가 발생하는지 파악하기 힘들 테니까요. 그리고 빠르게 변화하는 프론트엔드 생태계 특성상 언제 어떤 라이브러리가 리액트의 자리를 대신하게 될지 모르지만 자바스크립트 지식이 탄탄하게 깔려 있다면 쉽게 적응할 수 있다고 생각합니다. 저도 아직 많이 배우는 단계이기에 그런 경지에 오르기 위해 많이 공부하고 노력해야될 것 같습니다. 여기까지 긴 글 읽어주셔서 감사드리고 앞으로도 꾸준히 공부하며 기록하도록 하겠습니다.🤓

원시형과 객체형

{intro}
<Spacing size="lg" />

## 프로그래밍에서 변수란?
 
프로그래밍에서 변수란 **하나의 값을 저장하기 위해 이름이 붙은 메모리 공간**을 뜻합니다.
 
```javascript 
var password = 123456; 
```
 
위와 같이 변수를 선언하고 값을 할당하면 3단계에 걸쳐 변수에 값이 저장됩니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1WtfApWevV7lzHhaKIx6mF-KktJy5wZBo" alt="변수 선언 과정" width="580" height="392"/>
 
> 1. 선언 : 자바스크립트 엔진이 **변수의 식별자를 인식하는 단계**입니다. 식별자만 인식할 뿐 값이 저장되지는 않습니다.
> 2. 초기화 : 변수 식별자가 인식된 후, **메모리 공간을 확보하고 초기값을 설정하는 단계**입니다. 이 때 식별자는 확보된 메모리 공간의 주소값을 가르킵니다. 초기 값이 명시되어 있지 않은 경우 undefined로 초기화 됩니다.
> 3. 할당 : 식별자가 가르키고 있는 주소의 **메모리 공간에 값을 저장하는 단계**입니다.
 
## var와 const, let의 차이
 
이제 자바스크립트에서 변수를 선언할 때 사용하는 세가지 키워드 var와 const,let의 차이점에 대해 알아봅시다.
 
### 1. 재선언 , 재할당 가능 여부
 
#### 재선언과 재할당이란?
 
**재선언** : 이미 선언된 변수 식별자를 다시 사용하여 변수를 선언하는 것을 의미합니다.
 
```javascript 
var password = 123456; 
var password = 654321; // 이미 사용된 password 식별자를 사용하여 변수를 재선언

console.log(654321); // 재선언 시 할당된 654321이 출력된다.
```
 
**재할당** : 변수에 값을 다시 할당하는 것을 의미합니다.
 
```javascript 
var password = 123456; 
password = 654321; // password 값에 값을 재할당

console.log(654321); // 재할당 된 654321 값이 출력된다.
```
 
var와 const, let의 재선언, 재할당 여부는 아래와 같습니다.
 
| 변수 선언 키워드| 재선언 | 재할당 |
| ----------- | ------ | ------ |
| var | O | O |
| const (ES6) | X | X |
| let (ES6) | X | O |
 
1. **var** : 재선언과 재할당 **모두 가능**합니다.
2. **const** : 재선언과 재할당 **모두 불가능**합니다. 값이 변하지 않으니, 선언과 동시에 값이 할당되어야 합니다. 재할당이 허용되지 않으므로 상수(constance)라고도 합니다.
3. **let** : **재할당만 가능**하고 재선언은 허용되지 않습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=14fhjKXNkr4VFS8JnRq4UDa8c052BeEp9" alt="챗지피티한테 let의 의미를 물어보았다." width="558" height="266" caption="그래서 let이 무슨 뜻이냐고요..."/>
 
#### 재선언의 위험성 🚨
 
```javascript 
var password = 123456; 

// 1000 lines later ...🐌

var password = 654321; 
// 코드가 너무 길어져 실수로 위에 선언된 password를 덮어쓴다면?!😱
```
 
위와 같이 코드가 길어지거나 다른 개발자와 협업하여 일하는 경우 기존에 변수가 재선언되어 덮어써진다면 생각지 못한 에러가 발생하겠죠? 이런 상황을 미연에 방지하기 위해 **재선언을 허용하지 않는 키워드인 const와 let을 사용하는 것이 좋습니다.**
 
#### 어떤 상황에서 const를 쓰고 let을 써야할까요?🤔
 
 **변수에 값을 재할당해야 할 이유가 없는 모든 경우에 const를 쓰는 것이 바람직합니다.** const는 재할당조차 허용하지 않는 가장 엄격한 키워드이기 때문에 의도치 않게 값을 변경시키는 일이 발생하지 않기 때문입니다.
 
```javascript
const password = 123456; 

password = 654321; 
// TypeError: Assignment to constant variable
```
 
 부득이하게 값이 재할당 되어야 할 때는 let을 사용하면 됩니다. 저는 주로 if문, switch문 같은 조건문에서 조건에 따라 값을 다르게 할당해야하는 경우에 사용했습니다. 
 (~~만약문이라고 쓰고 5초간 뭐가 이상한지 몰랐던 사람이 바로 저예요~~)
 
### 2. 스코프 (scope)
 
#### 스코프란?
 
스코프(scope)는 **변수에 접근할 수 있는 유효 범위**를 뜻합니다. 
 
**전역 스코프 (Global Scope)** : 함수나 블럭 바깥의 최상위 공간입니다. 전역 스코프에 선언된 변수는 어디서나 접근 가능하며 이를 전역 변수라고 합니다.
**지역 스코프 (Local Scope)** : 함수나 블럭 내부를 뜻합니다. 지역 스코프에 선언된 변수는 해당 스코프 내에서만 접근 가능하여 이를 지역 변수라고 합니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1ZAsj37PaM6f7rCxrv65DjyHeVz4BMqy_" alt="스코프" width="558" height="266"/>
 
>1. 전역 스코프에 선언된 변수는 어디서나 접근 가능합니다.
>2. 지역 스코프에 선언된 변수는 전역 스코프에서 접근할 수 없습니다.
 (전역 스코프에서 outerFunction에 선언된 outerVar에 접근할 수 없음)
>3. 함수가 중첩된 경우 하위 함수에서는 상위 함수에 선언된 변수에 접근할 수 있지만 외부 함수에서 내부 함수에 선언된 변수에 접근할 수 없습니다.
 (outerFunction에서 innerFunction에 선언된 innerVar에 접근할 수 없음)
>4. 변수에 접근할 때 함수 내부에 선언되지 않았다면 상위 스코프로 올라가서 찾습니다. (스코프 체인)
 (innerFunction은 outerFunction, 전역 스코프에 있는 변수에 모두 접근이 가능)

 
#### var와 const, let의 스코프 차이
 
- **var의 스코프** : **함수 레벨** (function level)
- **const, let의 스코프** : **블럭 레벨** (block level)
 
#### 함수 스코프의 단점
 
함수 선언 시에 블럭이 사용되니 둘이 비슷한 것이 아닌가? 라는 생각이 들수도 있지만 함수 레벨의 유효 범위에서는 if문, for문처럼 함수가 아닌 문(statement) 안에서 선언한 변수가 전역변수가 되어 코드 여기저기서 참조할 수 있게 될뿐더러 다른 변수와 충돌할 가능성이 있습니다. 때문에 **안정적이고 예측 가능한 변수 사용을 위해 블록 스코프인 const와 let을 사용하는 것이 좋습니다.**
 
```javascript
for (var i = 0; i < 10; i++) {
 var a = "a";
}
console.log(i); // 10 => 루프 헤더에 선언된 i에 접근 가능
console.log(a); // 'a' => for문 안에 선언된 a에도 접근 가능

if (false) {
 var b = "b";
}

console.log(b); 
// undefined => if문의 조건이 거짓이므로 값을 할당되지 않았지만 전역변수이기에 접근은 가능하다🙄
``` 
 
### 3. 호이스팅 (Hoisting) 현상
 
<Callout>
자바스크립트는 런타임 환경에서 코드를 한 줄 한 줄 읽어내려가는 인터프리터 언어이다.
</Callout>
 
자바스트립트를 공부하면 제일 처음 배우게 되는 자바스크립트의 특징입니다. ~~(근데 이제 공부할 수록 가장 큰 혼란을 주는)~~
위의 자바스크립트의 특징을 잘 기억해둔 후 아래 코드를 살펴봅시다.
 
```javascript
console.log(password); //undefined

var password = 123456;
```
 
위 코드는 에러가 나야할 것 같지만 undefined가 출력될 뿐 에러 없이 코드가 돌아갑니다. (~~어째서..~~ 🤦)
 
이는 “끌어올리다”라는 뜻을 가진 <HighlightText type="background" fontWeight={700}>호이스팅</HighlightText>으로 인해 나타나는 현상으로 자바스크립트 엔진이 코드를 실행 하기 전에 **코드의 변수, 함수, 클래스의 선언부를 스코프의 최상단으로 끌어올리는 것처럼 동작하는 현상**을 말합니다. 
(함수 선언문 위에서 함수 실행이 가능한 이유도 호이스팅 때문이죠.)
 
var의 경우 호이스팅 시 **선언과 동시에 undefined로 초기화**되기 때문에 변수 선언문 이전에 변수를 참조해도 에러 없이 undefined 값을 얻을 수 있게 됩니다.
 
#### var의 호이스팅
 
<PostImage src="https://drive.google.com/uc?export=view&id=1Fp1-ZFQeIhvim7xyAgEHu-O6iagpDqjA" alt="var의 호이스팅" width="728" height="445"/>
 
> 1. 초기화 된 undefined 출력 😱
> 2. 선언 후 값을 할당하지 않았으므로 undefined로 초기화
> 3. undefined 출력
> 4. 123456 할당
> 5. 123456 출력

 
그럼 const와 let은 어떨까요?
 
<Callout icon="🚨">
 <HighlightText textColor="red">ReferenceError: Cannot access 'userName' before initialization</HighlightText >
</Callout>
 
‘userName’이 초기화되기 전에 접근할 수 없다는 참조 에러가 뜨게 됩니다. 
해당 코드 라인이 실행되는 시점에서 선언하지 않는 변수에 접근할 수 없는 게 우리가 예측할 수 있는 동작이므로 안심이 됩니다.
그런데 한 가지 의문인 점은 왜 ReferenceError: userName is not defined가 아닌 걸까요?
그 이유는 const와 let 또한 호이스팅 현상이 발생하기 때문입니다. 다만 var와의 차이점은 **const와 let은 호이스팅과 동시에 변수가 초기화 되지 않는다는 것**입니다. 
<HighlightText type="background" fontWeight={700}>TDZ(Temporal Dead Zone)</HighlightText>, 일시적 사각지대라고 하여 **변수 선언이 인식된 후 변수가 초기화 되기 전까지의 구간에서 const와 let 키워드로 선언한 변수에 접근하면 참조 에러가 발생**하게 됩니다.

const와 let으로 선언한 변수는 자바스크립트 엔진이 변수 선언문에 도달했을 때 초기화되고 접근이 가능해집니다. 이때 **const는 재할당이 불가능하기 때문에 초기화와 동시에 값이 할당**되어야 합니다. let은 할당 값이 없다면 undefined로 초기화됩니다.
 
#### const의 호이스팅
 
<PostImage src="https://drive.google.com/uc?export=view&id=1e6ONONIaXB_0jj3nXJUnFdZbrImqp5EH" alt="const의 호이스팅" width="728" height="373"/>
 
> 1. 변수 선언이 끌어올려진 후 초기화 되지 않아 접근할 수 없음 (ReferenceError: Cannot access 'password' before initialization)
> 2. 값을 재할당 할 수 없는 상수(constant)이기에 초기화와 동시에 할당
> 3. 할당된 값 123456 출력

 
#### let의 호이스팅
 
<PostImage src="https://drive.google.com/uc?export=view&id=1IwziOv60kqGAzwjJjoAO8oqOFbVeNE-v" alt="let의 호이스팅" width="728" height="445"/>
 
> 1. 변수 선언이 끌어올려진 후 초기화 되지 않아 접근할 수 없음 (ReferenceError: Cannot access 'password' before initialization)
> 2. 선언 후 값을 할당하지 않으면 undefined로 초기화 
> 3. 초기화 된 undefined 출력
> 4. 값 123456 할당
> 5. 할당된 123456 출력

 
## var를 지양해야 하는 이유
 
 - 재선언이 가능해 기존 선언을 덮어 쓸 수 있는 위험이 있습니다.
 - 호이스팅으로 인하여 변수 선언문 이전에 변수에 접근 가능한 예기치 못한 동작이 발생합니다.
 - 함수 스코프이기 때문에 if문, for문 등 문에서 쓰인 변수가 전역 변수가 되어 코드 여기 저기서 접근이 가능하고 변수 간 충돌이 발생할 수 위험이 있습니다.
 
=> 따라서 코드의 예측 가능성과 안정성을 저하시키는 var를 지양하고 이를 보완하기 위해 나온 const와 let을 사용하는 것을 적극 권장합니다👍
 
## 포스팅을 마치며
 
이렇게 var의 특징과 그 특징으로부터 발생하는 위험성에 대해 알아보았습니다. var를 사용하면 코드가 일단 돌아는가지만 왜 돌아가는지 혼란스럽고, 왜 여기서 내가 예상한 동작과 다른 버그가 발생하는지 파악하는 데 시간을 허비하게 될 가능성이 크겠죠. 그렇기 때문에 요즘에는 var를 사용하지 않는 추세입니다. 다만 사용하지 않으니 알아두지 않는 것이 아니라 어떤 특징을 가지고 있었는지, 그 특징으로부터 어떤 불편함이 발생했는지, 불편을 해소하기 위해 어떻게 해야 하는지 알아두는 것이 중요하다고 생각합니다. 그리고 ES6가 나온 이후에 개발을 시작한 것이 얼마나 큰 행복인지도요🥹

.css-y59011{position:relative;}.css-y59011::after{content:"";position:absolute;right:0;bottom:0;width:0;height:2px;background-color:var(--color-secondary);-webkit-transition:width 200ms ease-in-out;transition:width 200ms ease-in-out;} 리팩토링 2판 정리 - 테스트코드 구축하기