혹시 현대카드 앱 써보셨나요? 현대카드 앱의 검색창을 보면 포커스됐을 때 라인이 펼쳐지는 인터랙션을 볼 수 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741233295/23.focus-within/f0abcmc7y62fp6qqwkry.gif" alt="현대카드 검색창 포커스 인터랙션" width={1080*0.4
} height={588*0.4}/>
 
꽤나 쿨한 인터랙션이라고 생각하고 있던 차에 새롭게 진행한 프로젝트에 적용해 보면 좋겠다는 생각이 들었습니다. 이번 포스트에서는 :focus-within 선택자를 사용하여 해당 인터랙션을 구현한 이야기를 해보겠습니다.
<Spacing size="lg" />
## 어떻게 구현할까?
 
간단하게 input이 포커스 됐을 때 after 가상 요소의 scaleX를 조정해 구현하면 될 것 같았습니다. 그러나 안타깝게도 input 태그는 닫힌 태그라 가상 요소를 사용할 수 없었습니다. input 태그가 포커스될 때마다 부모 요소에 class를 붙여주는 식으로 구현해야하나 고민하던 차에 CSS만으로 해당 인터랙션을 구현할 수 있는 방법을 알게 되었습니다.
 
## :focus-within
 
:focus-within 선택자는 포커스된 요소 또는 자손 요소가 포커스 되었을 때 스타일을 적용할 수 있는 선택자입니다. 
이를 사용하여 input이 포커스 되었을 때 부모 div 태그에 스타일을 적용하여 쉽게 인터랙션을 구현할 수 있습니다.
 
## 최종 코드
 
최종 코드는 이렇게 됩니다.
 
```html
<div class="field">
 <input type="text"/>
</div>
```
 
```css
.field {
 position: relative;
 padding: 4px 0;
 border-bottom: 1px solid #c7c3bc; 
}

.field::after {
 content: "";
 position: absolute;
 left: 50%;
 bottom: 0;
 width: 100%;
 height: 1px;
 background-color: #605d56; 
 transform: translateX(-50%) scaleX(0);
 transition: transform 200ms ease-in-out;
}

.field:focus-within::after {
 transform: translateX(-50%) scaleX(100%);
}

```
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741234005/23.focus-within/cjdkbx3uvx8x9uyll6ml.gif" alt="현대카드 검색창 포커스 인터랙션" width={480
} height={180}/>
 
## 포스팅을 마치며
 
:focus-within 선택자를 사용해 쉽게 인터랙션을 구현할 수 있었습니다. form이나 input 관련한 스타일 작업을 하기에 굉장히 유용해서 앞으로 다른 프로젝트에서도 잘 사용할 것 같습니다. 그럼 여기서 글을 마치도록 하겠습니다 👋👋👋
 
## 참고 자료
 
- [MDN :focus-within](https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within)

focus-within 선택자로 폼 필드에 인터랙션 추가하기

프로젝트를 진행하던 중 버튼이 화면 오른쪽 끝에 배치되는 레이아웃을 구현하게 됐습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741078154/22.margin-auto/o0f5pzvvdmxao65b5fz5.png" width={1264*0.4} height={774*0.4} alt="스타일 적용 전 이미지, 버튼이 왼쪽에 있음" caption="초록색 버튼이 오른쪽 끝으로 가야 함" />
 
버튼을 오른쪽으로 밀기 위해 margin-left : auto를 적용했지만?
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741227468/22.margin-auto/r6m3mr1vuks5hoyujovr.jpg" width={1264*0.4} height={774*0.4} alt="스타일 적용 후 이미지, 버튼이 왼쪽에 있음" />
아무 일도 일어나지 않았습니다!
 
자, 이럴 때는 당황하지 않고 침착하게 구글 창을 켜서 마법의 키워드 **not working**으로 검색해 줍니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741078832/22.margin-auto/eq7kw3xzu8s0y2i6byem.gif" alt="구글 창에 마법의 키워드 not working을 입력해 보세요" width={480} height={180}/>
 
<Spacing size="lg" />

## margin auto 적용 조건
 
제가 찾은 [스택오버플로우](https://stackoverflow.com/questions/9226151/margin-left-auto-and-margin-right-auto-not-working-on-input) 글에 따르면 margin-left auto를 적용하기 위해서는 두 가지 조건이 필요했습니다.
 
1. block 요소일 것
2. 요소의 width 값이 고정되어 있을 것
 
생각해 보면 당연합니다. margin auto는 남는 여백을 자동으로 분배합니다. 따라서 width를 가지지 않는 inline 요소 혹은 width가 지정되지 않아 부모의 너비를 여백 없이 꽉 채운 block 요소에는 margin auto가 적용될 수 없습니다.
 
margin auto가 적용이 안 되는 이유를 알아냈으니 이제 display block과 width 값을 지정해 주면 문제는 쉽게 해결됩니다.
 
## 요소의 콘텐츠에 따라 너비 지정하기
 
그런데 여기서 한 가지 고민이 추가됩니다.
요소의 width를 고정값으로 정하고 싶지 않은 것이죠. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741228996/22.margin-auto/iaoa3ybglqiue5iwlxcw.png" alt="버튼에 고정값을 적용한다면?" width={618*0.5} height={214*0.5}/>
 
고정값을 사용하면 콘텐츠 내용이 달라졌을 때 UI가 쉽게 깨지게 됩니다.
고민하던 차에 다행히 요소 안에 포함된 콘텐츠를 기준으로 width를 정할 수 있는 CSS 속성값을 알게 되었습니다.
 
### max-content
 
```css
.button {
 width: max-content;
}
```
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741230782/22.margin-auto/jplbik9w7irghqrgduxz.png" alt="max-content" width={838* 0.5} height={150 * 0.5}/>

 
max-content는 콘텐츠가 가지는 최대 크기를 지정합니다. 이때 부모 요소의 너비를 초과하더라도 줄 바꿈이 되지 않습니다.
 
### min-content
 
```css
.button {
 width: min-content;
}
```
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741230781/22.margin-auto/qj8fp7ofyys4guvrazy9.png" alt="min-content" width={798* 0.5} height={198 * 0.5}/>

 
min-content는 콘텐츠에 포함된 가장 긴 단어를 기준으로 크기를 지정하고 그 크기를 초과하면 줄 바꿈 됩니다.
 
### fit-content
 
```css
.button {
 width: fit-content;
}
```
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741230784/22.margin-auto/ekfw0issf7mhrnacxckv.png" alt="fit-content" width={828* 0.5} height={246 * 0.5}/>

 
fit-content는 max-content와 마찬가지로 콘텐츠가 가지는 최대 크기를 지정하지만 부모 요소의 너비를 초과하게 되면 줄 바꿈 됩니다.
 
## 최종 코드
 
버튼에 margin-left auto를 적용하기 위한 최종 스타일입니다. 저는 콘텐츠가 가지는 최대 크기만큼 너비를 지정하지만 오버플로우가 발생하지 않도록 fit-content 값을 사용했습니다.
 
```css
.button {
 display: block;
 margin-left: auto;
 width: fit-content;
}
```
 
위 코드를 적용하면 버튼이 오른쪽으로 잘 밀리는 것을 볼 수 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741230785/22.margin-auto/gxhzbt3znekqdtxsdged.jpg" alt="최종 화면" width={632*0.7} height={387*0.7}/>
 
## 호환성 이슈
 
다만 Can I Use를 보면 IE에서는 max-content, min-content, fit-content를 지원하지 않는 것을 확인할 수 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741231283/22.margin-auto/pacj4yatq3vfzkr5anwr.jpg" alt="can i use" width={685} height={624}/>
 
만약 IE까지 고려해야 한다면 div 태그로 버튼을 한 번 감싸고 flex를 사용해서 오른쪽으로 밀어버리는 방법이 정신 건강에 이로울 것 같습니다 🙄
 
## 포스팅을 마치며
 
사실 디자인이 변경되면서 해당 코드는 제거하게 되었습니다. 그렇지만 앞으로 프론트 작업을 하며 또 이런 상황을 마주칠 것 같아 이번에 알게 된 내용을 정리해 보았습니다. CSS 작업을 할 때 어려운 점은 어떤 부분이 문제라고 에러를 던져주지 않는다는 점인 것 같습니다. 따라서 각 속성의 특성을 정확하게 알아두는 게 중요한 것 같습니다. 그럼 이번 포스트는 여기서 마무리하도록 하겠습니다 👋👋

margin-left : auto 적용하기

{intro}

<Spacing size="lg" />
## 발단 - 서버 사이드에서 인증 로직 구현하기
 
사건의 발단은 서버 사이드에서 인증 로직을 구현하면서 시작되었습니다. 프로젝트를 마무리하며 코드를 살펴보았을 때 데이터를 클라이언트에서 불러오는 경우가 많았기에 SSR을 위해 서버 사이드에서 데이터를 불러오도록 코드 수정 작업을 시작했습니다. 원래 인증 로직은 보안을 위해 서버에서 HttpOnly 쿠키로 토큰을 세팅하고 클라이언트에서 요청을 보낼 때 credentials : "include" 옵션을 주어 자동으로 쿠키가 전달될 수 있게 처리해 두었습니다. 그러나 넥스트 서버에서는 브라우저에 저장된 쿠키에 접근할 수 없었기 때문에 요청 헤더에 포함된 쿠키에 접근하여 토큰 값을 가져오는 방향으로 작업을 진행했습니다.
 
```tsx
// util/auth.ts
import { cookies } from "next/headers";

export const getToken = async () => {
 const cookie = await cookies();
 return cookie.get("token")?.value ?? null;
};

```
 
넥스트 요청 헤더에 포함된 쿠키에서 토큰을 가져온 후
 
```tsx
// AuthGuard
import { redirect } from "next/navigation";
import path from "@/constants/path";
import { getAuthServer } from "@/api/server/auth";
import { getToken } from "@/util/auth";

const AuthGuard = async ({ children }: { children: React.ReactNode }) => {
 try {
 const token = await getToken();
 await getAuthServer({
 headers: { Authorization: `Bearer ${token}` },
 });
 return <>{children}</>;
 } catch (error) {
 if (error instanceof Error) {
 console.error(error);
 redirect(path.login);
 }
 }
};

export default AuthGuard;
```
 
토큰을 Authorization 헤더에 추가하여 사용자 인증 정보를 불러옵니다.
이때 사용자 인증 정보가 없다면 로그인 페이지로 리다이렉션 시킵니다.
 
## 전개 - 토큰을 찾을 수 없음
 
작업을 완료한 후 코드를 배포하니 큰 문제가 생겼습니다. 로그인 해도 계속 로그인 페이지로 리다이렉트되는 문제였습니다. 로컬에서는 로그인 후 쿠키에 저장된 토큰을 통해 유저 정보를 가져오는 것이 정상적으로 처리되었기에 의문이었습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741223110/25.accessing-cookies-on-the-next-server/jc39whldxenpx6xwwhc3.jpg" alt="쿠키가 저장되어 있음" width="585" height="45" caption="쿠키는 저장되어 있는데 어째서...?"/>
 
분명 브라우저에 토큰이 저장되어 있는데 토큰이 존재하지 않는다는 에러가 계속 발생했습니다.
 
이 과정에서 온갖 키워드로 구글링하고 챗지피티한테 호통치고 (~~미래를 위한 호감작 실패~~ 🥲) 로컬 환경과 배포 환경을 비교해 보며 결국 에러의 원인을 찾아냈습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/tfkxmdshotnsi5hmsoqd.jpg" alt="로컬에서의 요청" width="672" height="336" caption="로컬에서 요청이 갈 때는 토큰이 포함됨"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/gpekxbffzz1axlq9gml1.jpg" alt="배포 도메인에서의 요청" width="697" height="292" caption="뭐야, 내 쿠키 돌려줘요"/>
 
배포 환경에서는 넥스트 서버로 요청이 갈 때 리퀘스트 헤더에 쿠키가 포함되지 않았던 것입니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/hvtbfuxz5x1eyoiaxfhq.jpg" alt="배포 환경의 쿠키 도메인" width="585" height="57" caption="쿠키의 도메인이 서버 도메인으로 지정되어 있음"/>
 
이유는 쿠키의 도메인 때문이었습니다. 도메인은 쿠키를 전달받을 서버를 지정하는 속성으로 따로 지정하지 않으면 쿠키를 세팅한 서버의 도메인이 자동으로 지정됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741222939/25.accessing-cookies-on-the-next-server/ik52gcgdldqjfqudaaja.jpg" alt="로컬 쿠키 도메인" width="585" height="62" caption="로컬은 넥스트 서버와 API 서버가 동일한 도메인을 가짐"/>
 
로컬 환경에서는 넥스트 서버와 API 서버가 동일한 localhost 도메인이기 때문에 넥스트 서버로 API 서버에서 세팅한 쿠키가 전달될 수 있었지만
배포 환경에서는 넥스트 서버와 API 서버의 도메인이 다르다 보니 넥스트 서버 요청에 쿠키가 같이 전달되지 않았던 것이죠 🥲
 
## 위기 - 도메인 세팅 실패
 
원인을 알았으니 쉽게 해결할 수 있을거라고 생각했습니다. 

"도메인을 넥스트 서버 도메인으로 하면 해결되겠다!"라고 생각했던 것이죠.
바로 API 서버에서 쿠키를 세팅할 때 도메인에 넥스트 서버 도메인을 지정하고 배포를 진행했습니다.
 
```ts
export const setToken = (res: Response, token: string) => {
 const options = {
 maxAge: Number(env.jwt.expiredSec) * 1000,
 httpOnly: true,
 sameSite: "none" as "none",
 secure: true,
 domain: env.client.host, // 도메인 설정
 };
 res.cookie("token", token, options);
};
```
 
그리고 로그인을 진행하니 이제는 토큰 쿠키조차 세팅되지 않는 이슈가 발생했습니다 😱 서브 도메인이 아닌 완전히 다른 도메인을 설정하는 것은 보안상의 이유로 허용되지 않기 때문이었습니다. 이때쯤부터 "이거 내가 해결 가능한 이슈인가?" 하는 불안감이 엄습했습니다.
 
## 절정 - 쿠키 세팅을 넥스트에 위임
 
SSR을 포기하고 클라이언트에서 인증 로직을 구현할지, 아니면 도메인을 구입해서 넥스트 서버와 백엔드 서버 도메인을 일치시킬지 고민하던 차에 해결 방법을 찾게 되었습니다.
 
- [Next.js x Express: Using HTTP-Only Cookie, JWT, and Refresh Token for API Secure Authentication and Protect Next Route Pages.](https://medium.com/@adimuhamadfirmansyah/next-js-x-express-using-http-only-cookie-jwt-and-refresh-token-for-api-secure-authentication-and-b7ee46ac4da3)
- [서로 다른 도메인에서 쿠키 사용하기](https://velog.io/@jojeon4515/%EC%84%9C%EB%A1%9C-%EB%8B%A4%EB%A5%B8-%EB%8F%84%EB%A9%94%EC%9D%B8%EC%97%90%EC%84%9C-%EC%BF%A0%ED%82%A4-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-React-Express#-express-%EC%BF%A0%ED%82%A4-%EC%98%B5%EC%85%98-domain)
 
구글 망령이 되어 돌아다니던 중 만나게 된 귀인들의 블로그.. 
 
 바로 API 서버에서 토큰을 생성하여 전달하면 넥스트 서버에서 쿠키를 세팅하는 방법이었습니다. 이러면 쿠키 도메인이 넥스트 도메인으로 지정되어 넥스트 서버에서 쿠키에 접근이 가능해집니다! 다만 클라이언트에서 API 서버로 요청을 보내는 경우 쿠키가 포함되지 않는 이슈가 발생하니 클라이언트에서 요청을 보낼 때 넥스트 서버를 거치게 한 후 미들웨어에서 토큰을 추출하여 Authorization 헤더에 토큰을 추가해 API 서버로 보내는 방법으로 문제를 해결하게 되었습니다. 
 
- [미들웨어 코드](https://github.com/ysisys0202/chak_client/blob/main/src/middleware.ts)
- [로그인 후 쿠키 세팅 코드](https://github.com/ysisys0202/chak_client/tree/main/src/app/api/auth/login)
 
## 결말 - 이슈 해결 🎉 거기에 찝찝함을 곁들인..
 
위 방법을 적용하니 배포 환경에서도 인증 처리가 정상적으로 동작했습니다. 
일단 문제가 해결되어 한숨 돌렸지만 넥스트 API에서 쿠키를 세팅하게 되면서 클라이언트 로직과 API 로직의 경계가 흐려진 것 같아 살짝 찝찝한 마음이 듭니다. 게다가 모든 API 요청이 넥스트를 한 번 거치게 되어 성능에 영향을 미치지 않을지 우려되기도 합니다.
 
## 포스팅을 마무리하며
 
이번 포스트에서는 API 서버와 도메인이 다른 넥스트 서버에서 쿠키에 접근하는 방법에 대해 알아보았습니다. 이번 에러를 해결하며 네트워크 지식의 부족함을 많이 느꼈고 공부의 필요성을 절실히 느끼게 된 것 같습니다. 올해 목표에 네트워크 공부를 슬쩍 추가하며 이번 포스트를 마무리하겠습니다 👋👋👋 
 
## 참고 자료
- [Next.js x Express: Using HTTP-Only Cookie, JWT, and Refresh Token for API Secure Authentication and Protect Next Route Pages.](https://medium.com/@adimuhamadfirmansyah/next-js-x-express-using-http-only-cookie-jwt-and-refresh-token-for-api-secure-authentication-and-b7ee46ac4da3)
- [서로 다른 도메인에서 쿠키 사용하기](https://velog.io/@jojeon4515/%EC%84%9C%EB%A1%9C-%EB%8B%A4%EB%A5%B8-%EB%8F%84%EB%A9%94%EC%9D%B8%EC%97%90%EC%84%9C-%EC%BF%A0%ED%82%A4-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-React-Express#-express-%EC%BF%A0%ED%82%A4-%EC%98%B5%EC%85%98-domain)

넥스트 서버 사이드에서 쿠키에 접근하기

{intro}
<Spacing size="lg" />
## 문제 발생
 
새로 작업한 프로젝트를 배포하고 보니 라우팅 반응 속도가 느려지는 현상이 발견되었습니다. 이는 이동할 페이지를 생성하기 위해 데이터를 불러오고 HTML을 렌더링하는 만큼 시간이 소요되기 때문이었습니다. 이를 개선하기 위해 넥스트에서 지원하는 스트리밍을 적용하게 되었습니다.
 
## 넥스트 SSR의 한계
 
넥스트의 스트리밍을 알아보기에 앞서 라우팅 반응 속도가 느려진 이유에 대해 알아보겠습니다.
 
넥스트의 SSR(Server Side Rendering)은 다음과 같은 단계로 진행됩니다.
 
1. API 서버로부터 페이지를 구성하는 데 필요한 모든 데이터를 가져옵니다.
2. 넥스트 서버는 가져온 데이터로 HTML을 렌더링합니다.
3. 만들어진 HTML과 CSS, 자바스크립트를 클라이언트에 전송합니다.
4. 클라이언트는 전달받은 HTML과 CSS로 화면을 렌더링합니다. 이때는 아직 자바스크립트가 적용되지 않아 상호 작용이 되지 않는 정적 UI입니다.
5. 마지막으로 React가 정적 UI에 자바스크립트를 연결하는 하이드레이션 과정을 거쳐 마침내 상호 작용이 가능한 UI가 됩니다.
 
이때 넥스트는 페이지를 렌더링하는 데 필요한 모든 데이터를 받아오고 HTML이 모두 준비되어야 페이지가 이동시키게 됩니다. 즉 링크를 클릭해도 페이지가 렌더링 되는 시간만큼 반응에 딜레이가 생기게 됩니다. 이는 사용자 경험을 크게 저하시키는 요인으로 이를 해결하기 위해 넥스트의 스트리밍을 적용할 수 있습니다.
 
## 스트리밍이란?
 
일단 스트리밍이라는 단어에 대해 알아보겠습니다. 일상적으로 많이 사용하는 용어지만 막상 그 뜻을 온전히 알고 쓰진 않았던 것 같습니다.
스트리밍은 큰 데이터를 작은 조각으로 나누어 물이 흐르듯 순서대로 전달하고 처리하는 과정을 의미합니다. 흔히 유튜브나 음원 사이트에서 비디오나 오디오 데이터를 작은 단위로 나누어 제공할 때 사용하곤 합니다. 그렇다면 넥스트의 스트리밍은 무엇일까요? (드디어 본론!)
 
## 넥스트의 스트리밍
 
넥스트의 스트리밍은 페이지의 HTML을 작은 조각으로 나누어 준비되는 순서대로 클라이언트에 전송하는 것을 의미합니다. 따라서 스트리밍을 적용하면 앞서 언급한 라우팅 속도가 느려지는 현상을 개선할 수 있습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741144198/24.next-streaming/sbaoxao6netonmlby3oz.avif" alt="넥스트의 스트리밍" width={1600*0.4} height={785 *0.4} caption="넥스트의 스트리밍, 페이지를 구성하는 HTML 작은 조각 나누어 클라이언트에 전송"/>
 
링크를 클릭했을 때 아무런 반응도 없다가 몇초후에 화면이 이동하는 것이 아니라 일단 페이지가 이동하고 먼저 준비된 UI을 보여줄 수 있으니 페이지 초기 로드 속도가 단축되고 사용자 경험도 개선할 수 있게 됩니다.
 
## 넥스트에서 스트리밍 적용하기
 
넥스트에서 스트리밍을 적용하기 위해서는 클라이언트에서 요청이 발생할 때 동적으로 생성되는 페이지여야 합니다. 이미 정적으로 빌드된 페이지라면 스트리밍이 필요하지 않을 테니까요.
 
그럼 이제 넥스트에서 스트리밍을 적용하는 두 가지 방법에 대하여 알아보겠습니다.
 
### 1. loading 페이지 추가하기
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741144198/24.next-streaming/fh58byejiay7zihrbjqs.avif" alt="loading 페이지" width={1600*0.4} height={785 *0.4} caption="Suspense 컴포넌트 적용."/>
 
첫 번째로는 loading 페이지를 추가하는 것입니다. 스트리밍을 적용할 페이지 파일과 동일한 경로에 loading.tsx 파일을 생성하고 해당 파일 내에서 로딩 시에 보여줄 fallback 컴포넌트를 내보내면 됩니다.
 
### 2. Suspense 컴포넌트 사용하기
 
페이지 단위가 아닌 컴포넌트 단위로 로딩 UI를 보여주고 싶다면 리액트에서 제공하는 Suspense 컴포넌트를 사용하면 됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1741144198/24.next-streaming/ss5ildcma1wunkxmzwqj.avif" alt="loading 페이지" width={1600*0.4} height={785 *0.4} caption="Suspense 컴포넌트 적용."/>
 
데이터를 페칭하는 컴포넌트를 Suspense로 감싸고 로딩 시 보여줄 fallback 컴포넌트를 전달하면 됩니다. Suspense는 페이지 단위의 로딩 UI보다 디테일하게 로딩 UI를 제공할 수 있다는 장점이 있습니다. 보통 스켈레톤 UI를 제공하여 어떤 UI가 렌더링 될지 사용자에게 예측할 수 있게 합니다. 
 
```tsx
<Suspense fallback={<Loading />}> 
 <SomeComponent />
</Suspense>
```
 
이렇게 SomeComponent를 감싸면 SomeComponent가 렌더링 될 동안 Loading UI가 노출됩니다.
 
#### (개선) HOC로 재사용성 높이기
 
이때 저는 부모 컴포넌트에서 Suspense로 감싸기보다 Suspense로 감싸질 컴포넌트 파일 안에서 로딩 UI를 같이 관리하고 싶었습니다.
따라서 Suspense를 적용할 컴포넌트 파일에서 withSuspense HOC를 내보내도록 작업했습니다.
HOC는 High Order Component의 약자로 컴포넌트를 인자로 받아 새로운 컴포넌트를 반환하는 함수입니다. 각각의 컴포넌트에 공통 로직을 적용할 때 유용하게 사용할 수 있습니다. 더 자세한 내용이 알고 싶으시다면 [이 포스트](/posts/React/HOC-사용해서-재사용성-높이기)를 확인해 주세요.
 
```tsx
// withSuspense HOC
import { ComponentType, ReactNode, Suspense } from "react";

const withSuspense = <Props extends object>(
 Component: ComponentType<Props>,
 fallback: ReactNode
) => {
 const ContainerComponent: React.FC<Props> = ({
 suspenseKey,
 ...props
 }) => (
 <Suspense fallback={fallback}>
 <Component {...(props as Props)} />
 </Suspense>
 );

 ContainerComponent.displayName = `withSuspense(${
 Component.displayName || Component.name || "Component"
 })`;

 return ContainerComponent;
};

export default withSuspense;

```
 
```tsx
// SomeComponent
const SomeLoading = () => {
 return <div>loading...</div>
}

const SomeComponent = () => {
 return <div>some...</div>
}

export default withSuspense(SomeComponent, <SomeLoading />);
```
 
#### (최종) 쿼리 파라미터로 데이터를 새로 불러오는 경우 대응하기
 
Suspense 컴포넌트는 기본적으로 데이터를 한 번 불러온 후에는 로딩 완료 상태를 유지합니다. 이때 문제가 되는 점은 필터나 페이징같이 쿼리 파라미터를 사용하여 API 호출을 하는 경우 Suspense가 로딩 완료 상태를 유지하고 있기 때문에 fallback UI를 노출하지 않는다는 점입니다. 따라서 처음과 똑같이 상호 작용 속도 이슈가 발생합니다. 이 문제를 해결하기 위해서 새로 데이터를 불러올 때 Suspense에 키값을 변경하여 강제로 리렌더링해주야 합니다.
 
키값을 전달하기 위해 withSuspense를 수정해 주었습니다.
 
```tsx
import { ComponentType, ReactNode, Suspense } from "react";

const withSuspense = <Props extends object>(
 Component: ComponentType<Props>,
 fallback: ReactNode
) => {
 const ContainerComponent: React.FC<Props & { suspenseKey?: string }> = ({
 suspenseKey, // Props 타입에 suspenseKey 추가
 ...props
 }) => (
 <Suspense key={suspenseKey} fallback={fallback}> 
 {/* suspenseKey 전달*/}
 <Component {...(props as Props)} />
 </Suspense>
 );

 ContainerComponent.displayName = `withSuspense(${
 Component.displayName || Component.name || "Component"
 })`;

 return ContainerComponent;
};

export default withSuspense;

```
 
```tsx
const SomeLoading = () => {
 return <div>loading...</div>
}

const SomeComponent = () => {
 return <div>some...</div>
}

export default withSuspense(
 SomeComponent,
 <SomeLoading />
);
```
 
```tsx
const ParentComponent = ()=>{
 return <SomeComponent suspenseKey={queryParams.id}/>
}

```
 
## 포스팅을 마무리하며
 
이번 포스트에서 넥스트 SSR의 한계점과 이를 개선하기 위한 스트리밍에 대해 알아보았습니다. HTML이 모두 렌더링 되기 전에 로딩 UI를 먼저 노출시켜 사용자 경험을 향상 시킬 수 있었던 것 같습니다. 그럼 이번 포스트는 여기서 마무리하겠습니다 👋👋
 
## 참고 자료
 
- [넥스트 스트리밍 공식 문서](https://nextjs.org/docs/app/getting-started/fetching-data#streaming).
- [리액트 Suspense 공식 문서](https://ko.react.dev/reference/react/Suspense#resetting-suspense-boundaries-on-navigation)

스트리밍 적용해서 라우팅 속도 개선하기

{intro}
<Spacing size="lg" />
## 개발 동기
 
올해 들어 사이드 프로젝트를 하기로 마음먹었습니다. 그런데 본격적으로 프로젝트를 하기에 앞서 사이드 프로젝트용 리액트 UI 라이브러리를 만들어보면 어떨까 싶더라고요. 버튼이나 타이포그래피처럼 공통적으로 사용되는 컴포넌트를 미리 만들어두면 이후 프로젝트에서는 서비스 로직에만 집중할 수 있을 거라고 생각했습니다. 사실 예전이었으면 라이브러리를 만들 생각은 못했을 텐데 작년에 패스트캠퍼스에서 UI 라이브러리 만들기 강의를 들었기 때문에 '꼭 이걸 내 프로젝트에 활용해야겠다'라는 생각을 했고 이번 기회에 직접 저만의 UI 라이브러리를 만들어보게 되었습니다.
 
참고로 패키지 이름은 앞으로 진행할 프로젝트인 독서 기록 플랫폼 chak(책 + check)와 레고 블록을 조립해서 멋진 결과물을 만들듯이 컴포넌트 블록을 조립하여 서비스를 만들 수 있다는 의미에서 chak-blocks라고 지어보았습니다.
 
## 고려할 부분
 
구현 사항은 간단합니다. 리액트 컴포넌트 만들기! 그런데 이걸 패키지로 배포하려면 고려해야 할 부분이 있습니다.
 
- **ESM, CJS 모듈 시스템을 모두 지원할 것**
 이 부분은 강의를 듣지 않았다면 생각하지 못했을 부분이었습니다. 패키지를 사용하는 곳에서 어떤 방식의 모듈 시스템을 사용할지 모르니 범용성 있게 ESM, CJS 모두 지원해 주는 것이 좋다고 합니다.
- **서버 컴포넌트를 지원할 것**
 사이드 프로젝트를 넥스트 앱 라우터로 만들 생각이었기 때문에 서버 컴포넌트를 지원해야 했습니다. 서버 컴포넌트는 브라우저에서 실행되는 자바스크립트 번들의 크기를 줄이기 위해 리액트에서 제공하는 컴포넌트로, 서버에서만 실행되고 자바스크립트 번들에서는 제외되기 때문에 브라우저에서는 실행되지 않습니다. 즉 CSS in JS 방식의 스타일 라이브러리와 브라우저에서 실행되는 리액트 훅 사용에 제약이 걸리게 되는 것이죠. 뒤에서 이야기하겠지만 이것 때문에 꽤 골머리 앓았습니다 🥲
- **사용자는 나**
 작업을 하다 보면 '어디까지 기능을 지원해야 하지?'하는 애매한 부분이 생깁니다. 이때 너무 많은 경우의 수를 고려하여 코드의 복잡성을 높이지 않기 위해 주 사용자를 저 자신으로 설정하고 작업했습니다. 당장 저에게 필요한 컴포넌트, 기능 구현에 집중했고 나중에 필요해지는 것들은 추후 보완하고자 했습니다.
 
## 번들러 설정하기
 
본격적으로 컴포넌트를 만들기에 앞서 번들러 세팅을 해주었습니다. 번들러는 모듈화된 파일들을 하나로 묶어주는 역할을 합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738672323/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/mklnummqi29scrzpl0ja.png" alt="웹팩 메인 이미지" width={1095*0.7} height={414*0.7} caption="웹팩 메인 화면, 번들러의 역할이 잘 표현되어 있음"/>
 
이번 라이브러리 프로젝트에서 사용한 번들러는 [esbuild](https://esbuild.github.io/)입니다. esbuild는 다음과 같은 특징을 갖습니다.
 
- **번들링 속도가 빠름.**
 esbuild는 메인 화면에서도 빠른 빌드 속도를 강점으로 내세우고 있습니다. 웹팩 같은 기존의 번들러와 비교하면 10-100배 정도 빠르다고 합니다.
- **추가적인 플러그인 없이 자바스크립트, CSS, 타입스크립트, JSX을 번들링할 수 있음**
 (다만 타입 체크는 지원하지 않기 때문에 tsc로 따로 타입 체크를 해주었습니다.)
- **ESM, CJS 번들링 지원** 
 
즉, 제가 고려한 사항들을 모두 충족하면서도 가장 빠른 속도의 번들러이기 때문에 esbuild가 이번 프로젝트에 가장 적합하다고 판단했습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668086/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/vfng2f9vtwfv0d2aemer.png" alt="번들링" width={1026 *0.7} height={380 *0.7}/>
 
src 폴더에 있는 파일들을 번들링하면 여러 컴포넌트 코드가 index.js 파일 하나에 모두 들어가 있는 것을 확인할 수 있습니다.
 
그런데 컴포넌트 작업을 마무리하고 넥스트 앱 라우터 프로젝트에서 패키지를 사용해보니 에러가 발생하더라고요.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668086/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/xj4lzbsmlpqumuiko5fn.png" alt="TypeError: (0, react_WEBPACK_IMPORTED_MODULE_® createContext) is not a function" width={943} height={178} caption="TypeError: (0, react_WEBPACK_IMPORTED_MODULE_® createContext) is not a function"/>
 
일부 컴포넌트에서 Context API를 사용하고 있어 발생한 에러였습니다. 타이포그래피나 태그 등 동적 기능이 없는 컴포넌트들도 Context API를 사용하는 컴포넌트들과 한 파일에 번들링되어 있다보니 서버 컴포넌트로 사용하기에 제약이 걸렸습니다. 어떻게 이 문제를 해결할 수 있을까 고민하던 차에 떠오른 방법은 바로...
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668920/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/cu1jcoayh1yz0wh6b2lu.jpg" alt="깨달음" width={319*0.7} height={360*0.7} />
<HighlightText textColor="red">"코드를 분리해 버리자!"</HighlightText>
 
 
Context API 사용 여부를 기준으로 번들된 결과물을 나누면 문제가 해결될 것이라고 생각했습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738668086/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/eezclvbgl27xnzofqjvm.png" alt="번들링" width={1010*0.7} height={476*0.7}/>
 
그리고 실제로 적용해 보니 잘 동작하는 것을 알 수 있었습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738673821/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/urxmrzdktwpnhoykoodg.png" alt="plain 컴포넌트 렌더링" width={724} height={248} caption="plain 컴포넌트 렌더링 화면"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738673821/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/jctez3mqpveaungewaln.png" alt="context 컴포넌트 렌더링" width={724} height={361} caption="context 컴포넌트 렌더링 화면"/>

 
다만 사용하는 곳에서 context 컴포넌트와 plain 컴포넌트를 구분해서 import 해야 하기 때문에 사용법이 복잡해진 점은 아쉽습니다.
 
## 컴포넌트 만들기
 
리액트 UI 라이브러리니까 컴포넌트도 만들어줘야 합니다. 모든 프로젝트에서 기본적으로 사용되는 타이포그래피, 버튼, 태그, 아코디언 등을 만들었습니다.
 
### 재사용성 고려하기
 
컴포넌트를 만들 때 중요한 점은 재사용성을 고려해야 한다는 점입니다. 저는 아래와 같은 방법으로 재사용성을 높여보았습니다.
 
- **HTML Element Attributes 모두 지원하기**
 저는 공통 컴포넌트를 만들 때 '스타일이 입혀진 HTML 요소'처럼 쓸 수 있도록 하는 것을 좋아합니다.
컴포넌트는 스타일만 가지고 있고 컴포넌트가 처리할 로직이나 속성 등은 props로 전달받을 수 있게 말이죠. 
 예를 들어 버튼 컴포넌트를 만든다고 했을 때, 스타일이 입혀진 버튼 요소처럼 쓸 수 있도록 버튼 요소가 가진 속성을 모두 지원합니다. 버튼이 처리할 클릭 로직은 onClick prop으로 전달받으며, type, disable, 그리고 data attribute까지 컴포넌트를 사용하는 곳에서 자유롭게 사용할 수 있도록 HTML Element Attributes를 props로 전달받을 수 있게 컴포넌트를 구성했습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738674874/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/orf082znq0hlnb59ouj7.png" alt="버튼 컴포넌트 props" width={922*0.7} height={240*0.7} caption="버튼 요소의 모든 attributes를 props로 지원"/>
 
- **컴파운드 패턴 적용하기**
 아코디언같이 여러 컴포넌트를 조합하여 컴포넌트를 만드는 경우, 부모 컴포넌트 내부에 자식 컴포넌트를 포함하고 있으면 요구사항이 조금 달라졌을 때 대응하기 쉽지 않습니다. props로 분기 처리하는 등 코드가 점점 복잡해지기 마련입니다. 이런 복잡성을 방지하고 유연하게 컴포넌트를 사용하기 위해 컴파운드 패턴으로 컴포넌트를 설계했습니다. 컴파운드 패턴을 사용하면 Context API를 통해 서로 상태는 공유하지만, 컴포넌트 자체는 독립적으로 존재하기 때문에 상황에 맞게 컴포넌트를 조립할 수 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738674777/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/uzcjuro058cw2htho8qn.png" alt="컴파운드 패턴으로 구현된 아코디언 컴포넌트" width={1062*0.7} height={988*0.7} caption="컴포넌트가 독립적으로 사용되어 자유롭게 커스텀 가능"/>
 
### 스타일링
 
컴포넌트 스타일링은 [vanilla extract](https://vanilla-extract.style/)를 사용했습니다. vanilla extract는 CSS in TS 방식의 스타일 라이브러리로, 이름처럼 빌드 타임에 순수한 CSS를 추출합니다. 
 
<Callout title="바닐라의 의미">
잠깐 딴 길로 새자면 바닐라 자바스크립트도 그렇고 왜 바닐라가 순수하다는 의미인지 궁금해져서 찾아보았는데 바닐라 아이스크림이 가장 기본적이 맛이라서 그렇다고 하네요 🍦😋
</Callout>
 
순수한 CSS를 제공한다는 것에는 두 가지 장점이 있습니다.
 
- **서버 컴포넌트에서 사용하기에 적합함**
 런타임 환경에서 동적으로 스타일이 결정되는 것이 아니기 때문에 서버 컴포넌트를 스타일링하기 적합하다고 생각했습니다.
- **패키지를 사용하는 곳에서 스타일 라이브러리에 의존성을 갖지 않음**
 빌드된 패키지에는 순수한 CSS만 포함되기 때문에, 패키지를 사용하는 곳에서 CSS 라이브러리에 대한 의존성이 필요하지 않을 것이라 생각했습니다. 그러나 편의성과 동적 스타일링을 위해 vanilla-extract/dynamic과 vanilla-extract/recipes를 추가로 사용하게 되면서, 결국 패키지를 사용하는 곳에서 이 라이브러리들을 설치해주어야 합니다 😞
 
### 스토리북
 
작업 중 컴포넌트 확인은 스토리북을 사용했습니다. 컴포넌트 비주얼 테스트와 동시에 사용자들에게 제공할 문서까지 만들 수 있으니, 일석이조라고 생각했습니다. 그러나 스토리북 개발 서버 구동과 번들링을 위한 vite 설치가 불가피해졌습니다. '하나의 프로젝트에 번들러가 2개여도 되나...?'하는 의문이 생겼지만 일단 스토리북을 사용하기 위해 vite를 추가로 설치해 주었습니다.
 
## package.json 설정하기
 
패키지를 배포하기 위해서 package.json을 설정해 주어야 합니다.
평소에는 스크립트를 추가하거나 의존성 명세서 정도로 사용했는데 패키지로 배포하려고 하니까 여러모로 신경 쓸 게 있더라고요.
 
- **name** & **version** 
 name은 배포될 패키지의 이름이고 version은 패키지의 현재 버전입니다. [npm Docs](https://docs.npmjs.com/cli/v11/configuring-npm/package-json)에 따르면 패키지를 배포할 때 name과 version은 고유해야 한다고 합니다. 때문에 패키지에 변경 사항이 발생하여 새로 배포될 때마다 버전을 업데이트해 주어야 합니다.
- **files**
 패키지를 설치할 때 포함할 항목을 명시하는 필드입니다. 기본값은 ["*"]로 모든 파일을 포함하지만 저는 번들링 된 파일만 내보내기 위해 ['dist']로 명시해 주었습니다.
- **export** 
 패키지 진입점을 정의하는 필드입니다. 
 
```json
 "exports": {
 ".": {
 "types": "./dist/index.d.ts"
 },
 "./plain": {
 "import": "./dist/plain/index.js",
 "require": "./dist/plain/index.cjs",
 "types": "./dist/components/plain/index.d.ts"
 },
 "./context": {
 "import": "./dist/context/index.js",
 "require": "./dist/context/index.cjs",
 "types": "./dist/components/context/index.d.ts"
 },
 "./plain/style.css": "./dist/plain/index.css",
 "./context/style.css": "./dist/context/index.css"
 }
```
 
context 컴포넌트와 plain 컴포넌트의 진입점을 구분하고 ESM과 CJS의 모듈 시스템과 type, style 파일 경로를 명시해 주었습니다. 
 
자세한 내용은 [Node.js 공식 문서](https://nodejs.org/api/packages.html#package-entry-points)에서 확인해 볼 수 있습니다.
 
## 문서화
 
아무래도 npm에 올라갈 패키지다 보니 문서화 작업에도 신경을 쓰게 되었습니다. 설치 방법, 컴포넌트 사용 방법 등을 되도록 상세히 리드미에 작성해 주었습니다. 이때 마크다운 테이블 반복 작업이 상당히 귀찮은데요. 이 부분은 Chat GPT 도움을 많이 받았습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738671670/21.chak-blocks-%EC%A0%9C%EC%9E%91%EA%B8%B0/f0djxze7vxohbichjoa5.png" alt="개떡같이 말해도 찰떡같이 알아듣는 Chat GPT" width={719} height={296} caption="개떡같이 말해도 찰떡같이 테이블 만들어주는 Chat GPT"/>
 
[chak-blocks 리드미 보러 가기](https://github.com/ysisys0202/chak-blocks)
 
## publish 하기
 
npm 배포는 간단합니다. npm 사이트에서 회원가입을 한 후, 배포하고자 하는 프로젝트에서 npm publish 명령어를 입력하면 됩니다.
 
[chak-blocks 패키지 보러 가기](https://www.npmjs.com/package/chak-blocks)
 
## 포스트를 마무리하며
 
이렇게 UI 라이브러리를 만들고 npm에 배포까지 해보았습니다. 늘 익숙하게 해왔던 컴포넌트 작업에 더해, 번들러를 직접 세팅해 보며 개발 환경에 대한 이해도를 높이고, 패키지 배포용 package.json을 구성하며 패키지는 만드는 방법에 대해서도 알 수 있었습니다. 여러모로 아쉬움이 남는 부분도 있지만 점차 개선할 수 있으리라 믿고 첫 패키지 배포 후기는 여기서 마치도록 하겠습니다 👋👋

UI 라이브러리 제작기

2024 연말결산

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

## 주요 렌더링 경로란?
 
주요 렌더링 경로(CRP, Critical Rendering Path)는 브라우저가 HTML, CSS, 자바스크립트를 픽셀 데이터로 변경하여 화면을 그려내는 일련의 단계, 즉 **브라우저가 서버로부터 전달받은 데이터를 화면에 그려내는 과정**을 의미합니다.
 
참고로 MDN은 중요 렌더링 경로로 번역되어 있는데, 다른 책들을 보면 주요 렌더링 경로라고 하더라고요. 주요 렌더링 경로가 더 적절한 표현이라고 생각되어 저도 주요 렌더링 경로라고 하겠습니다.
 
## 주요 렌더링 경로 알아보기
 
그럼 주요 렌더링 경로 단계를 자세히 살펴보겠습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486631/19.CRP/sz9pygr42p7ozroisjsh.png" alt="주요 렌더링 경로 Tree" caption="주요 렌더링 경로 단계" width="1097" height="80"/>
 
브라우저가 화면을 렌더링 할 때 요청/응답, 로딩, 스크립팅, 렌더링, 레이아웃, 페인팅 단계를 거칩니다.
 
### 1. 요청 / 응답 (Request / Response)
 
브라우저가 요청을 보내면 서버가 HTML 데이터를 응답합니다.
 
### 2. 로딩 (Loading)
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486642/19.CRP/mwh4jpcgw3bxndfkm3sw.jpg" alt="DOM Tree" caption="HTML을 파싱하여 생성된 DOM Tree \n 이미지 출처 : https://developer.mozilla.org/ko/docs/Web/Performance/How_browsers_work" width="754" height="689"/>
 
- 브라우저가 HTML을 파싱하여 DOM Tree를 생성합니다. 이때 파싱은 HTML과 같은 데이터를 브라우저가 이해할 수 있는 객체(DOM)로 변환하는 작업을 의미합니다.
- HTML 파싱 중에 발견된 CSS, 자바스크립트, 이미지 등 외부 자원을 요청합니다.
- CSS 파일을 파싱하면서 DOM과 CSS를 결합한 CSSOM(CSS Object Model)을 생성합니다.
- 이 때 CSS, 자바스크립트를 파싱하기 위해 HTML 파일 파싱이 중단됩니다. CSS, 자바스크립트 파싱이 완료된 후 HTML 파싱이 재개됩니다.
 
### 3. 스크립팅 (Scripting)
 
자바스크립트를 파싱하는 단계로, 자바스크립트가 DOM과 스타일을 변경할 수 있기 때문에 자바스크립트 파싱과 실행이 완료되기 전까지 HTML 파싱이 중단됩니다.
 
### 4. 렌더링 (Rendering)
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738489533/19.CRP/gumwiwtfwlps4hd65mlv.jpg" alt="Render Tree" caption="DOM과 CSSOM이 결합하여 생성된 Render Tree \n 이미지 출처 : https://web.dev/articles/critical-rendering-path/render-tree-construction?hl=ko" width="1150" height="537"/>
 
DOM과 CSSOM을 결합하여 화면에 렌더링 될 Render Tree를 생성합니다. 이때 Render Tree는 **최종적으로 화면에 보이는 요소만을 포함**합니다. HTML의 HEAD 태그, CSS에서 display:none이 적용된 요소와 같이 화면에 보이지 않는 요소는 Render Tree에 포함되지 않습니다.
 
### 5. 레이아웃 (Layout)
 
Render Tree의 요소들이 페이지에서 배치되는 위치와 크기, 그리고 서로 관련된 위치를 결정합니다. 이때 레이아웃 성능은 DOM의 영향을 받습니다. DOM 요소의 수가 많아질수록 레이아웃 단계에서 소요되는 시간이 길어지게 됩니다.
 
### 6. 페인팅
 
6-1. 페인트(Paint) 단계 : Render Tree를 분석한 후 **요소들을 그룹 지어 레이어로 나눕니다.** 그 후 각각의 레이어는 픽셀 데이터로 변환됩니다. 이때 각 레이어는 독립적으로 렌더링 되며 이는 브라우저의 렌더링 성능을 향상 하는데 도움을 줍니다. 레이어는 CSS 속성 (z-index, position, transform, will-change 등)과 canvas, video 태그 등을 기준으로 분리됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486630/19.CRP/aehimnnckg4lzqirpte3.png" alt="개발자 도구에서 Layer 확인하기" caption="개발자 도구의 오른쪽 점 세 개 버튼 -> 도구 더 보기 -> 레이어 클릭 시 열리는 레이어 탭에서 레이어를 직접 확인해 볼 수 있습니다." width="778" height="448"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486646/19.CRP/armbgfxsbwjeved8cakz.png" alt="개발자 도구에서 블로그 메인 Layer 확인" caption="블로그 메인 화면 레이어" width="812" height="419"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486633/19.CRP/wkwqaqg2ca6dbnomlxia.png" alt="개발자 도구에서 블로그 PostCard의 image에 will-change 속성을 주었을 때" caption="PostCard의 Image에 will-change 속성을 적용하면 이미지마다 레이어가 생성됨" width="812" height="419"/>
 
시각적으로 레이어를 확인할 수 있으니 더 이해하기 쉽습니다 👍
 
<Callout icon="🤔" title="will-change는 항상 성능에 유리할까요?" >
CSS 속성 중 브라우저에 미리 변경될 CSS를 알려주는 will-change가 있습니다. HTML 요소에 will-change가 적용돼 있다면 브라우저는 해당 요소를 독립적인 레이어로 분리하여 렌더링 최적화를 준비합니다. 하지만 will-change를 남발하여 너무 많은 레이어가 생성된다면 오히려 성능 저하의 원인이 됩니다. 따라서 정말 필요한 경우에만 사용하는 것을 권장합니다. 
</Callout>
 
6-2. 컴포지트 (Composite) 단계: 페인트 단계에서 생성된 레이어를 결합하여 최종적으로 화면에 표시합니다.
 
## 브라우저 렌더링 최적화
 
브라우저는 위와 같은 과정을 통해 HTML 파일을 화면에 렌더링합니다.
그럼, 브라우저에서 렌더링을 최적화하기 위한 방법은 무엇이 있을까요?
 
### 1. 과도한 DOM 요소 사용을 지양할 것
 
지나치게 깊은 DOM Tree나 복잡한 DOM 요소 구조는 렌더링 성능을 저하시킬 수 있으므로 불필요한 div 태그를 사용하는 등 과도한 DOM 요소 사용은 지양하는 것이 좋습니다.
 
### 2. 리플로우와 리페인팅 최소화
 
포스트 초반에 인터랙션을 구현할 때 transform이 width, position 보다 성능상 유리하다는 이야기를 했습니다. 바로 CSS 속성에 따라 거치는 렌더링 단계가 달라지기 때문입니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486627/19.CRP/yhjtzvlsf0xnmckfrpbs.jpg" alt="Reflow" caption="DOM 요소, CSS 변경 등으로 레이아웃 과정이 다시 발생" width="1097" height="80"/>
 
**리플로우(Reflow)** 는 렌더링 과정에서 레이아웃 과정이 다시 일어나는 것을 의미합니다. DOM 요소를 추가, 제거하거나 width, position, margin 등의 CSS 속성 변경으로 인해 HTML 요소들이 재배치되어야 할 때 브라우저는 각 요소의 위치와 크기를 새로 계산하는 리플로우 과정을 거치게 됩니다. 화면 배치를 다시 계산하기 때문에 렌더링 성능 저하를 유발합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486636/19.CRP/wqfohmpkoyaasn0df33w.jpg" alt="Repainting" caption="레이아웃 변경 없이 CSS가 변경될 때 발생" width="1097" height="80"/>
 
**리페인팅(Repainting)** 은 렌더링 과정에서 페인팅 과정이 다시 일어나는 것을 의미합니다. 레이아웃 변화 없이 CSS가 변경될 때 리페인팅 과정을 거치게 됩니다. 리페인팅의 경우 리플로우보다는 덜 하지만 여전히 성능을 저하시키는 요인입니다. 따라서 인터랙션을 구현할 때 리플로우보다는 리페인팅을, 그 중에서도 특히 컴포지트만 발생시키는 CSS 속성을 사용하는 것이 중요합니다.
 
[CSS Triggers](https://www.lmame-geek.com/css-triggers/)에 들어가 보면 스타일 변경 시 레이아웃, 페인트, 컴포지트를 트리거하는 CSS 속성이 잘 정리되어 있습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738799737/19.CRP/vxwqklfyo3brmwk1fmb9.png" alt="트리거 속성" width={526*0.6} height={86*0.6}/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486625/19.CRP/thtjzavhschn9qsp6h9o.png" alt="css triggers transform" width="808" height="57"/>
transform은 컴포지트만 트리거합니다 👍
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486638/19.CRP/yr7kunuligohgemlmo0e.png" alt="css triggers width" width="1097" height="80"/>
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486623/19.CRP/qj2bp4atuhsffbngmh9m.png" alt="css triggers position" width="1097" height="80"/>
 
하지만 width와 position은 레이아웃을 트리거, 즉 리플로우 단계를 거치는 것을 확인할 수 있습니다. 즉 width, position을 빈번하게 변경시키는 인터랙션이 있다면 그만큼 화면을 계산하는 일이 많아져 브라우저 렌더링 성능이 떨어지며 브라우저 화면 프레임이 뚝뚝 끊길 수도 있습니다. 그렇기에 인터랙션을 구현할 때 리플로우보다는 리페인팅을, 그중에서도 컴포지트만 발생하는 CSS 속성을 사용하는 것이 좋습니다.
 
<Callout title="레이아웃 쉬프트 (Layout Shift)">
혹시 웹사이트가 로딩되며 클릭하려던 요소가 아래로 밀리는 바람에 의도하지 않은 버튼을 눌러 불쾌했던 경험 있으신가요?
그러한 현상을 레이아웃 쉬프트라고 합니다. 말그대로 레이아웃이 이동하는 현상이죠.
레이아웃 쉬프트도 리플로우를 유발하기 때문에 브라우저 렌더링 성능에 좋지 않습니다. 게다가 사용자 경험에도 좋지 않기 때문에 스켈레톤 UI를 사용하여 이를 방지하는 것이 중요합니다.
</Callout>
 
## 포스팅을 마치며
 
오늘은 브라우저의 렌더링 과정 중에서도 HTML 파일이 화면에 그려지게 되는 과정인 주요 렌더링 경로에 대하여 알아보았습니다. 예전에 공부했었지만 시간이 오래되어 자세한 내용은 기억이 살짝 흐릿한 상태였는데 이번에 포스트를 작성하며 해당 내용을 다시 정리할 수 있어 좋았습니다. 처음 주요 렌더링 경로를 알게 되었을 때 '이런 과정을 거쳐 화면이 렌더링 되는 거구나', '이래서 인터랙션 구현할 때 transform을 써야 하는구나' 하고 시야가 넓어진 기분이 들었던 기억이 납니다. 바로 이런 재미에 공부를 하게 되는 것 같습니다 😋 그럼 이번 포스트는 여기서 마무리해 보겠습니다 👋👋

주요 렌더링 경로 알아보기

{intro}
<Spacing size="lg" />
## ErrorBoundary란?
 
ErrorBoundary란 UI 일부분에 존재하는 자바스크립트 에러가 전체 애플리케이션을 중단하는 문제를 해결하기 위해 도입된 컴포넌트입니다.
이때 ErrorBoundary의 역할은 아래와 같습니다.
 
1. 컴포넌트에서 발생한 에러를 기록
2. 에러가 발생하여 깨진 UI를 대신할 Fallback UI를 렌더링
 
## ErrorBoundary 컴포넌트 만들기
 
ErrorBoundary 컴포넌트를 만들 때는 에러 처리와 관련된 라이프 사이클 메서드를 대신할 hook이 없기 때문에 클래스형 컴포넌트로 만들어야 한다고 합니다. (~~잊고 지내던 클래스형 컴포넌트가 나와 당황스러운 사람~~)
 
클래스형 컴포넌트에는 익숙하지 않아서 <HighlightText type="background" backgroundColor="#e5e5e5">getDerivedStateFromError</HighlightText >와 <HighlightText type="background" backgroundColor="#e5e5e5">componentDidCatch</HighlightText>에 대해서 먼저 알아보겠습니다.
 
- **getDerivedStateFromError** : 정적 메서드로 리액트가 렌더링하는 중 자식 컴포넌트에서 에러가 발생할 때 호출됩니다. **에러 발생 시 상태를 업데이트하여 UI를 렌더링**합니다. 또한 순수 함수이기 때문에 사이트 이펙트 작업(ex:에러 리포팅)은 componentDidCatch를 사용해야 한다고 합니다.
- **componentDidCatch** : 리액트가 렌더링할 때 자식 컴포넌트에서 에러가 발생하면 호출됩니다. 에러 리포팅 등 **사이드 이펙트 작업을 처리**합니다.
 
에러와 관련된 라이프 사이클 메서드도 알아보았으니 이제 ErrorBoundary 컴포넌트 코드를 만들어보겠습니다. 리액트 공식 문서에서 제공하는 코드에 타입을 추가해보았습니다.
 
```tsx
import React, { ReactNode } from "react";

type ErrorBoundaryProps = {
 children: ReactNode;
 fallbackComponent?: ReactNode;
};
type ErrorBoundaryState = {
 hasError: boolean;
};

class ErrorBoundary extends React.Component<
 ErrorBoundaryProps,
 ErrorBoundaryState
> {
 constructor(props: ErrorBoundaryProps) {
 super(props);
 this.state = { hasError: false };
 }
 static getDerivedStateFromError(error: Error): ErrorBoundaryState {
 return { hasError: true };
 }

 componentDidCatch(error: Error, errorInfo: React.ErrorInfo): void {
 // Sentry와 같은 에러 리포팅 서비스를 사용하여 에러 로그를 남길 수도 있음
 console.error("ErrorBoundary에서 에러가 감지되었습니다.", {
 error,
 errorInfo,
 });
 }

 render() {
 if (!this.state.hasError) {
 return this.props.children;
 }
 if (this.props.fallbackComponent) {
 return this.props.fallbackComponent;
 }
 return (
 <div>
 <h2>Oops, there is an error!</h2>
 <button
 type="button"
 onClick={() => this.setState({ hasError: false })}
 >
 Try again?
 </button>
 </div>
 );
 }
}
export default ErrorBoundary;

```
 
1. ErrorBoundary는 에러를 핸들링할 컴포넌트와 에러 발생 시 보여줄 fallbackComponent를 props로 받습니다.
2. ErrorBoundary 내에서는 hasError state를 사용해 에러 발생 여부를 판단합니다.
3. getDerivedStateFromError 메서드를 사용하여 에러 발생 시 hasError 상태를 true로 변경합니다.
4. componentDidCatch 메서드를 사용하여 에러 발생 시 처리 로직을 구현합니다. 이때 Sentry와 같은 에러 리포팅 시스템을 사용할 수도 있습니다.
5. render 함수에서는 hasError 상태에 따라 UI를 렌더링합니다. 에러가 발생하지 않았다면 child 컴포넌트를 그대로 그려주며, 에러가 발생하였다면 fallback UI를 그려줍니다. 이때 저는 props로 전달받은 fallbackComponent가 있다면 fallbackComponent를, 전달받은 fallbackComponent가 없다면 기본 fallback UI가 그려지도록 해주었습니다.
 
## ErrorBoundary 사용하기
 
이렇게 완성된 ErrorBoundary 컴포넌트를 사용해 보겠습니다.
 
```tsx
<ErrorBoundary fallbackComponent={Something went wrong}>
 <Profile />
</ErrorBoundary>

```
이렇게 Profile 컴포넌트를 ErrorBoundary로 감싸면 Profile 컴포넌트에서 에러가 발생했을 때 fallback UI가 노출되며 해당 에러를 캐치하여 애플리케이션 전체에 영향을 주지 않도록 경계를 만들 수 있습니다.
그렇다면 모든 컴포넌트를 ErrorBoundary로 감싸야 할까요? 리액트 공식 문서는 에러 메시지를 표시하는 것이 합리적인 곳을 고려하라고 합니다. props를 전달받아 화면을 그리는 역할만 한다면 굳이 ErrorBoundary로 감싸지 않아도 됩니다.
 
## 포스팅을 마무리하며
 
이번 포스트에서는 라이프 사이클 메서드를 사용하여 에러를 관리하는 ErrorBoundary 컴포넌트에 대해 알아보았습니다. ErrorBoundary를 통해 일부 컴포넌트에서 발생한 에러가 애플리케이션 전체에 영향을 미치지 않도록 처리할 수 있었습니다. 조금 더 우아한 에러 처리와 fallback UI 제공 등 애플리케이션의 안정성과 사용성을 높이기 위한 방안으로 ErrorBoundary를 사용해 보시는 것을 추천해 드리며 포스트를 마무리하겠습니다 👋👋

ErrorBoundary로 에러 핸들링하기

{intro}
<Spacing size="lg" />
## HOC란?
 
HOC(Higher Order Component, 고차 컴포넌트)란 컴포넌트를 인자로 받아 새로운 컴포넌트를 반환하는 함수를 의미합니다. 공통으로 적용돼야 하는 로직이 있을 때 컴포넌트 각각에 로직을 추가하는 것이 아니라 공통된 로직을 처리하는 HOC를 통해 코드 재사용성을 높일 수 있습니다. HOC는 함수명이 with로 시작하는 것이 관례입니다.
 
## HOC 만들기
 
로딩 상태에 따라 컴포넌트를 렌더링하는 withLoading HOC를 만들어보겠습니다.
 
```tsx
import { ComponentType, ReactNode } from "react";

const withLoading = <Props extends object>(
 WrappedComponent: ComponentType<Props>
) => {
 const ContainerComponent: React.FC<Props & { isLoading: boolean }> = ({isLoading,...props}) => (
 if (isLoading) {
 return <LoadingComponent/>
 }
 return <WrappedComponent {...props as Props} />
 );

 ContainerComponent.displayName = `withLoading(${
 WrappedComponent.displayName || WrappedComponent.name || "Component"
 })`;

 return ContainerComponent;
};

export default withLoading;
```
 
1. HOC에 감싸질 WrappedComponent를 인자로 받습니다.
2. ContainerComponent는 props를 WrappedComponent에 전달하고 isLoading 값에 따라 컴포넌트를 리턴하는 렌더링 함수입니다.
3. 컴포넌트 식별을 위한 displayName을 설정해 줍니다.
4. ContainerComponent를 반환합니다.
 
이렇게 로딩 상태에 따라 컴포넌트를 렌더링하는 withLaoding HOC를 만들어보았습니다. 앞으로 로딩 관련 처리가 달라지더라도 withLoading 함수만 수정하면 되니 코드 유지보수성도 좋아집니다.
## HOC 사용하기
 
withLoading을 만들었으니 적용해 볼까요?
 

```tsx
//Profile.tsx

const Profile = () => {
 return profile
}

export default withLoading(Profile);
```
 
로딩 처리를 해주고자 하는 컴포넌트를 withLoading의 인자로 넘겨준 후 내보내기 해주면 됩니다 🎉
 
## 포스팅을 마무리하며
 
오늘은 공통된 로직을 재사용할 수 있게 도와주는 HOC에 대해서 알아보았습니다. 공통 로직을 컴포넌트마다 가지고 있을 필요 없이 HOC를 통해 관리하면 코드의 재사용성과 유지보수성 모두 높아지는 것을 알 수 있었습니다.

HOC 사용해서 재사용성 높이기

{intro}
<Spacing size="lg" />
## 🚨 에러 메시지
 
아래 에러를 해결한 포스트입니다.
 
- (로컬에서 Jest 실행 시) Cannot find module 'public/icons/icon.svg' from ...
- (CI 환경에서 Jest 실행 시) Cannot find module 'public/icons/icon.svg' or its corresponding type declarations.
 
## SVGR 모킹하기
 
로컬 환경에서 Jest를 실행하면 Cannot find module 에러가 발생했습니다. [SVGR 공식 사이트](https://react-svgr.com/docs/jest/)을 보며 svg 모킹 작업을 해 줍니다.
 
### 1. 목업 파일 생성하기
 
루트 폴더에 모킹을 위한 __ mocks __/svg.js 파일을 생성해 줍니다. 
(mocks 앞, 뒤 언더스코어는 붙여서 써주세요)
 
```javascript
export default 'SvgrURL'
export const ReactComponent = 'div'
```
 
### 2. Jest 설정하기
 
```javascript
// jest.config.ts
module.exports = {
 moduleNameMapper: {
 '\\.svg$': '<rootDir>/__mocks__/svg.js',
 },
}
```
 
jest.config.ts에서 .svg 파일이 1번에서 생성한 svg 모킹 파일로 매핑될 수 있도록 설정해 줍니다. 
그럼 로컬에서는 테스트가 잘 통과하는 모습을 볼 수 있습니다 👏👏👏
 
## SVG 타입 지정하기
 
Cannot find module 'public/icons/icon.svg' or its corresponding type declarations.
 
기쁜 마음으로 코드를 push 했지만, 테스트를 통과하지 못합니다 🥲 
아무래도 타입 문제인 것 같습니다.
 
### global.d.ts 파일에 svg 타입 선언하기
 
```typescript
declare module "*.svg" {
 export const ReactComponent: React.FC<React.SVGProps<SVGSVGElement>>;
 export default ReactComponent;
}
```
 
루트 폴더에 global.d.ts를 만들고
.svg 파일을 React 컴포넌트처럼 사용할 수 있도록 타입을 선언해 줍니다.
그럼, CI 환경에서도 테스트가 잘 돌아가게 됩니다 🎉
 
## 포스팅을 마무리하며
 
오늘은 Jest 환경에서 SVGR를 사용할 시 발생하는 에러 해결 방법을 간단히 살펴보았습니다. 
혹시 Jest 세팅에 고생하는 분들이 계신다면 도움이 되면 좋겠습니다 👍

Jest에서 SVGR 테스트하기

{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://res.cloudinary.com/yun-log/image/upload/v1738486560/13.cicd_scenario/kfdsukz8ymagv71uxukn.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486566/13.cicd_scenario/sm6is5zltigudsytugvd.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486562/13.cicd_scenario/hxtuoifo9pjnxedftwhb.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486578/14.branch_%20strategy/s6q4caubadozjsbay0ki.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738486573/14.branch_%20strategy/lco2hyknfmathmtxt8uo.webp" 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://res.cloudinary.com/yun-log/image/upload/v1738486575/14.branch_%20strategy/mgfxxhdstdnbwgvyc5yc.webp" 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://res.cloudinary.com/yun-log/image/upload/v1738486571/14.branch_%20strategy/hvnrod4txop6v8i0nhmj.webp" 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://res.cloudinary.com/yun-log/image/upload/v1738486528/11.throttle_debounce/icpqufhzf19bzibv8xdo.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486530/11.throttle_debounce/jocptsnejjnn9ixpqaij.gif" alt="쓰로틀 적용 전" width="802" height="342"/>
 
쓰로틀을 사용하지 않으면 함수 호출이 짧은 시간에 120회 가까이 일어납니다😱 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486532/11.throttle_debounce/bppolcpiaz1xvml4ohfg.gif" 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://res.cloudinary.com/yun-log/image/upload/v1738486534/11.throttle_debounce/wwarnhe4nvyyb0vug9yq.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486539/11.throttle_debounce/x2sqwfeqz7psevl38vhw.gif" alt="쓰로틀 적용 전" width="802" height="342" caption="강조되고 반복되는 이벤트는 개발자를 불안하게 해요!!"/>
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486538/11.throttle_debounce/dergjzdnvcjerglistp7.gif" alt="쓰로틀 적용 후" width="802" height="342"/>
 
만약 디바운스를 적용하지 않아 값이 입력될 때 마다 api를 호출했다면 짧은 시간 안에 수십번이나 호출되었겠죠.
디바운스를 적용하면 단 두번만 호출됩니다. delayTime은 사용성을 저하하지 않는 수준으로 맞춰보면 좋을 것 같습니다😄
 
## 포스팅을 마무리하며
 
오늘은 DOM 이벤트를 최적화하는 쓰로틀과 디바운스에 대해 알아보고 구현해보았습니다. 간단하게 구현 가능하지만 효과는 엄청났습니다. 더이상 반복되는 이벤트에 불안해마시고 쓰로틀과 디바운스로 최적화해보시기를 바라며 글을 마치도록 하겠습니다👋👋

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

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

## 들어가기 전에
 
- 실행 컨텍스트을 먼저 알아보시는 것을 추천합니다.
 
## 클로저란?
 
일단 클로저란 단어의 뜻을 알아보겠습니다. 클로저는 폐쇄라는 뜻이라고 합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486518/10.closure/w49fszse2q41kkxzrbe3.png" 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)는 함수와 그 함수가 참조하는 주변 상태(렉시컬 환경)가 함께 묶인 조합입니다.** 즉, **클로저는 함수에 외부 스코프에 접근할 수 있는 능력을 제공**합니다. 
> 
>다시 말해, 클로저는 함수가 정의된 위치의 스코프(외부 환경)를 기억하고, 그 함수가 실행될 때도 그 스코프에 접근할 수 있게 해줍니다. 자바스크립트에서 클로저는 함수가 생성될 때마다 자동으로 만들어집니다.

 
설명을 읽어도 이해하기 쉽지 않습니다. 천천히 정리해보겠습니다. 클로저란 **함수 안에 선언된 내부 함수를 통해 함수의 환경(변수, 함수)에 접근하는 것**입니다. 클로저를 통해 외부에서 직접적으로 함수 내부 환경에 접근하는 것을 막고 반환된 내부 함수를 통해서만 내부 환경에 접근할 수 있게 됩니다. 이는 렉시컬 환경의 특성과 관련이 깊습니다.
 
<Callout title="렉시컬 환경(Lexical Environment)이란?">
렉시컬 환경은 함수가 실행될 때의 식별자 정보와 외부 환경 참조를 가지고 있습니다. 이를 통해 식별자에 접근할 수 있는 스코프가 형성되어 외부에서 함수 내부 환경에 접근할 수 없게 됩니다. 또한 렉시컬 환경은 선언 당시의 위치에 따라 결정되기 때문에 함수의 실행이 종료되었어도 내부 함수가 선언 당시의 외부 환경(함수의 렉시컬 환경)을 기억하고 참조할 수 있게 됩니다. 
</Callout>
 
 말은 어렵지만 코드를 통해 쉽게 이해할 수 있습니다.
 
```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://res.cloudinary.com/yun-log/image/upload/v1738486523/10.closure/rnaeifh0gyi9ewzckj6r.gif" 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://res.cloudinary.com/yun-log/image/upload/v1738486520/10.closure/rdfkgryfocsddxz1ngdf.gif" alt="로그가 무수히 찍히는 중" width="698" height="546"/>
 
scroll 이벤트가 발생할 때 마다 timer 값이 undefined로 초기화되며 연속적으로 logScroll 함수가 실행됩니다😓
 
때문에 timer 변수는 인자로 받아오는 콜백함수가 일정한 주기로 호출될 수 있게 timeoutID 값을 유지하고 있어야 합니다. 이와 같이 함수가 호출될 때 마다 변수가 초기화 되지 않고 상태가 유지되어야 할 때 클로저가 아주 유용하게 사용됩니다👍
 
덧붙이자면 클로저는 잘 모를때는 timer 변수를 전역에 선언하기도 했습니다. 그렇게 사용해도 코드는 의도대로 동작하지만 실제로 timer 변수가 필요한 곳과 너무 동떨어져 있어 코드 가독성이 안좋아지기 때문에 클로저를 사용하는 것을 적극 권장합니다. 
 
## 포스팅을 마무리하며
 
오늘은 자바스크립트의 클로저에 대하여 알아보았습니다. 사실 클로저는 자바스크립트에서만 사용되는 것은 아니고 함수를 인자로 전달 받거나 함수를 리턴하는 고차함수를 사용하는 언어에서 통용되는 개념이라고 합니다. 클로저의 설명만 봐서는 무슨 내용인지 이해하기 어려워서 어려운 개념인가? 싶지만 실제로 코드를 작성해보면 재밌고 유용하다는 것을 알 수 있습니다. 게다가 이미 종료된 함수의 식별자를 기억해서 사용한다니...? 낭만적이기까지 합니다.
 
그런데 아쉬운 점은 제가 실제로 클로저를 사용해본 것은 예시로 들었던 쓰로틀과 디바운스 함수를 작성할 때 뿐이었다는 것입니다. 혹시 클로저를 사용해보셨다면 어떤 상황에서 사용하셨는지 경험을 공유해주시면 너무 좋을 것 같습니다. 그럼 여기까지 글 읽어주셔서 감사드리고 이만 마무리해보도록 하겠습니다👋👋

클로저 알아보기

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

## 자바스크립트 엔진과 런타임 환경
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486502/09.event_loop/oferio6vo4lrltq3phbj.jpg" alt="자바스크립트 런타임 환경" width="992" height="584"/>
 
**자바스크립트 엔진**은 자바스크립트 코드를 해석하고 실행하는 프로그램입니다. 자바스크립트 엔진은 싱글 스레드로 동작하며 **한 번에 하나의 일만 처리**할 수 있습니다. 이는 함수의 실행을 관리하는 **콜 스택이 하나**라는 의미이기도 합니다. 대표적으로 크롬과 Node.js에서 사용하는 V8엔진이 있습니다.
 
**자바스크립트 런타임 환경**은 자바스크립트가 실행되는 환경, 즉 크롬 같은 **브라우저(혹은 Node.js)** 입니다. 브라우저에서 제공하는 Web API들(fetch, setTimeout, EventListener...)을 통해 **비동기 작업**이 가능하며 이벤트 루프를 통해 비동기 작업의 우선 순위를 정하고 처리합니다.
 
### 콜 스택 (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의 콜백 함수와 MutationObserver의 콜백 함수 등을 관리하는 큐(Queue) 자료구조입니다. **태스크 큐 보다 높은 우선 순위**를 가지며 콜 스택이 비워졌을 때 먼저 들어온 작업부터 하나씩 콜 스택으로 이동시켜 실행시킵니다. 태스크 큐와 마이크로태스크 큐가 나누어진 이유는 작업 처리에 우선 순위를 두어 **태스크 큐에 있는 작업에 영향을 받지 않고 마이크로태스크를 동일한 환경에서 처리할 수 있기 때문**이라고 합니다.
 
## 이벤트 루프 (Event Loop)란?
 
**이벤트 루프**는 브라우저에 내장된 **비동기 작업을 처리하는 매커니즘**입니다. 말 그대로 계속 루프를 돌며 콜 스택과 태스크 큐, 마이크로태스크 큐를 관찰하며 처리할 작업(함수)이 있다면 순서대로 처리합니다. 
 
## 이벤트루프를 통한 비동기 작업 순서
 
앞서 본 이미지를 보며 비동기 작업이 어떤 순서로 진행되는지 알아보겠습니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486502/09.event_loop/oferio6vo4lrltq3phbj.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738486505/09.event_loop/bshbzgai8ffxfpqwegkt.png" 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://res.cloudinary.com/yun-log/image/upload/v1738489141/09.event_loop/rqb1lruixpyqqtyfpcqo.gif" alt="3초 후 실행" width="498" height="86" />
 
3초 동안 반복문이 실행되고 전역 코드가 모두 종료되어 전역 컨텍스트가 제거된 후 setTimeOut의 콜백함수가 실행됩니다.😱
이렇게 되면 성능에도 좋지 않고 사용자가 화면을 클릭 했을 때 등록된 이벤트 리스너 콜백이 바로 실행되지 않는 등 사용성이 굉장히 떨어질 수 밖에 없습니다.
따라서 setTimeOut(()=>{},0)을 사용하여 복잡한 코드를 나누어 태스크 큐에 넣어두는 방식으로 작업을 관리할 수 있습니다. (저는...그렇게까지 코드 관리해 본 적은 없지만요...)
 
그리고 브라우저는 성능 최적화와 안정적인 사용자 환경을 위해 콜 스택에 있는 함수가 모두 실행된 후 화면의 변경을 업데이트합니다. 보통의 경우에는 60fps (약 16ms) 주기로 업데이트 되지만 콜 스택에서 굉장히 오랫동안 실행되는 코드가 있다면 정상젹으로 UI가 업데이트 되지 않는 이슈가 발생할 수 있기 때문에 역시 너무 크고 복잡한 작업을 나누어 관리하는 것이 중요합니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738489144/09.event_loop/b91l2i2fbn8cettfwdpo.gif" 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://res.cloudinary.com/yun-log/image/upload/v1738486474/8.next-sitemap/jcmj2mej2rxrvyfykgl9.png" alt="vercel 배포 로그 - 사이트맵 생성 확인" width="905" height="254"/>
 
역시나... 처음 배포 시에는 잘 생성되고 있었습니다. 그럼 언제부터 postbuild가 안됐던걸까 고민하던 차에 눈에 보였던 것이 yarn 버전이었습니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486467/8.next-sitemap/tyrelzkkx6zg6zxfsuvl.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486477/8.next-sitemap/v4w1chdgmj5tj3ydydnm.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486464/8.next-sitemap/s639ydv9t8ignggl0xg6.png" alt="블로그 사이트맵" width="847" height="222" caption="not 어쩌구 하면 일단 심장 뛰는 사람... XML 파일에 스타일 정보가 없어 문서의 내용만 트리 형태로 보여준다고 합니다."/>
 
사이트맵이 잘 나온다면 성공적으로 생성이 된 것입니다.🥳
 
## 구글 서치 콘솔
 
구글 서치 콘솔은 웹 사이트의 검색 결과를 파악하고 모니터링하여 검색 결과를 개선시킬 수 있게 도와주는 도구입니다. (회사에서는 마케팅팀이 주로 사용하시는 것 같습니다.)
사용하지 않아도 구글 검색 결과에 노출되지만 새로운 페이지가 생성되거나 페이지의 내용이 업데이트 될 때 사이트맵을 새로 제출하면 페이지 색인을 다시 생성하도록 요청할 수 있기 때문에 구글 서치 콘솔에 사이트맵을 제출해보도록 하겠습니다.
 
### 도메인 연결
 
[구글 서치 콘솔 페이지](https://search.google.com/search-console/about?hl=ko)에 들어가봅시다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486475/8.next-sitemap/ss3nrgio3vs4kxhm1bu5.png" alt="구글 서치 콘솔 시작하기" width="853" height="718"/>
 
로그인 후 시작하기 페이지로 넘어가면 이런 화면이 나옵니다.
사이트 도메인을 입력하고 [계속] 버튼을 클릭합니다. 
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486465/8.next-sitemap/xwrgksaz65ua3rhdcbve.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486465/8.next-sitemap/xwrgksaz65ua3rhdcbve.png" alt="구글 서치 콘솔 대시보드" width="902" height="462"/>
 
### 사이트맵 제출
 
왼쪽 사이드 메뉴에서 sitemaps 탭에 들어가 사이트맵을 제출해줍시다. <HighlightText type="background" fontWeight={700}>domain/sitemap.xml</HighlightText>을 입력해주면 됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486470/8.next-sitemap/plyy1ugpeztdhnkyckmf.png" alt="구글 서치 콘솔 대시보드" width="842" height="456"/>
 
### 검색 결과 확인
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738486472/8.next-sitemap/pfhcir7manvhsodr8bux.png" 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://res.cloudinary.com/yun-log/image/upload/v1738486347/05.execution_context/akv9afdmkejzqcpcvaeh.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738486347/05.execution_context/qpyyemkgml35q3vzl9zb.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738485965/03.proto_type/oqnpaymcr3pimlmek74q.png" 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://res.cloudinary.com/yun-log/image/upload/v1738485964/03.proto_type/d0km1gr35h4fu1poryuq.png" 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://res.cloudinary.com/yun-log/image/upload/v1738485966/03.proto_type/sf8wemcazvnlfe9p4zvw.png" 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://res.cloudinary.com/yun-log/image/upload/v1738487613/02.data_type/dghdxetosq1vrtwxvmpn.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738487616/02.data_type/x5efurrt6053t3rqbqou.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738487610/02.data_type/s28ibvdvj1hxkvlcwxyo.png" alt="스택오버플로우" width="440" height="177"/>

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

원시형과 객체형

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

## 프로그래밍에서 변수란?
 
프로그래밍에서 변수란 **하나의 값을 저장하기 위해 이름이 붙은 메모리 공간**을 뜻합니다.
 
```javascript 
var password = 123456; 
```
 
위와 같이 변수를 선언하고 값을 할당하면 3단계에 걸쳐 변수에 값이 저장됩니다.
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738485949/01.variables/wnz6aiqagp25atzigv2g.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738485945/01.variables/k84zbeddysycmxm5ytko.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738485945/01.variables/whunmujpitodlhvaihy9.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738485946/01.variables/ct0un2vi2rtujkhy93mk.jpg" 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://res.cloudinary.com/yun-log/image/upload/v1738485947/01.variables/cdbnoxwf3aefpssqdmcw.jpg" alt="const의 호이스팅" width="728" height="373"/>
 
> 1. 변수 선언이 끌어올려진 후 초기화 되지 않아 접근할 수 없음 (ReferenceError: Cannot access 'password' before initialization)
> 2. 값을 재할당 할 수 없는 상수(constant)이기에 초기화와 동시에 할당
> 3. 할당된 값 123456 출력

 
#### let의 호이스팅
 
<PostImage src="https://res.cloudinary.com/yun-log/image/upload/v1738485947/01.variables/gkfj35bde6zrbfeu1vkz.jpg" 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가 나온 이후에 개발을 시작한 것이 얼마나 큰 행복인지도요🥹