
Reflow를 공부하는 과정에서 예상과 다른 동작을 발견하게 되었고, 이를 검증하기 위해 직접 테스트를 진행해 보았다. 그러나 테스트 결과는 내가 기대했던 것과 달랐고, 이를 통해 Reflow에 대해 충분히 이해하지 못하고 있다는 사실을 깨달았다. 이후 관련 자료를 심층적으로 조사하면서, 그동안 Reflow에 대해 단편적으로만 알고 있었다는 점을 명확히 인식하게 되었다. 이번 아티클에서는 Reflow의 개념을 자세히 파헤치고, 공부 과정에서 생긴 의문과 예상과 다른 결과의 원인을 체계적으로 분석해 보려 한다.

## Reflow

우선 용어를 정리하자면, Reflow는 Firefox에서 주로 사용되는 용어이며, Chrome과 Safari에서는 Layout이라는 표현을 사용한다. 이러한 차이는 브라우저 개발자 도구를 통해 쉽게 확인할 수 있다. 즉 Reflow, Layout 같은 말이다. 여기서는 Reflow라고 말을 하겠다. Reflow란 **렌더 트리를 기준으로 요소의 레이아웃(크기, 위치, 관계)을 다시 계산하는 과정**을 의미한다. 특히 현대 웹 개발에서 자바스크립트를 사용해 DOM을 조작할 때 Reflow에 신경 써야 한다. Reflow는 `성능 저하`와 `병목 현상`을 초래할 수 있기 때문이다.

> Reflow가 아니더라도 브라우저 렌더링 과정에 대한 것들은 모두 신경써야 한다.

## 우리가 알고있는 Reflow는 생각보다 다르다.

Reflow에 대한 기본적인 지식을 배웠으니, 다음 코드는 Reflow가 몇번 발생하는지 생각해보자.

```ts
const button = document.querySelector("button")! as HTMLButtonElement
const paragraph = document.querySelector("p")! as HTMLParagraphElement

button.addEventListener("click", (event) => {
  for (let i = 1; i <= 10_000; i++) {
    paragraph.innerHTML = String(i)
  }
})
```

대부분의 사람들은(실제 주변 동료들에게 질문한 결과) "반복 횟수만큼 Reflow가 발생한다"라고 답변했다. 하지만 실제로는 Reflow는 한 번만 발생하고 있었다. 위 코드를 Performance로 분석한 결과는 다음과 같다.

![성능 분석 결과](/posts/JavaScript/reflow/no-optimization.png)

지금은 innerHTML을 추가한 것이지만, 위 코드에서 `createElement`를 사용해 `appendChild`로 DOM 추가를 하더라도 Reflow는 한 번만 발생하게 된다. 이러한 이유를 알려면, Asynchronous Reflow와 Synchronous Reflow를 알아야 한다.

### Asynchronous Reflow(비동기식 리플로우)

Asynchronous Reflow란 브라우저가 DOM 변경에 따른 레이아웃 재계산 작업을 지연하거나 최적화하는 과정을 말한다. 비동기식 Reflow는 페인트가 일어나기 전에 실행된다. 위에 이미지를 보면 pre-paint 이전에 Layout이 일어나는 것을 볼 수 있다. 마치 React의 batch와 같이 DOM 업데이트를 모아서 처리한다고 볼 수 있다. 따라서 위 코드와 같이 반복적으로 DOM 업데이트를 시도한다고해서 매번 Reflow가 발생하는건 아니다.

### Synchronous Reflow(동기식, 강제 리플로우)

Synchronous Reflow는 Forced Reflow 라고도 부른다. 이 개념은 우리가 알고있는 Reflow와 같다. 위 코드에서 `paragraph.innerHTML = String(i)`밑에서 `console.log(Reflow를_일으키는_속성_및_메서드)`를 사용하면 이 때 Forced Reflow가 일어나게 된다. 이 과정을 Performance로 분석하면 다음과 같다.

![동기식 Reflow](/posts/JavaScript/reflow/force-reflow.png)

위 그림에서 보라색으로 표시된 부분이 Layout, 즉 Reflow를 의미한다. Reflow는 브라우저가 DOM의 레이아웃을 다시 계산하는 과정으로, 이 작업은 매우 계산 비용이 크다. 특히, 매번 Reflow를 계산하게 되면 병목 현상이 발생하여 성능이 크게 저하되는 모습을 볼 수 있다. 이렇게 단일 작업 및 프레임에서 Reflow가 여러번 발생하는 것을 `레이아웃 쓰레싱(Layout Thrashing)`이라고 한다.

따라서, Forced Reflow는 최대한 사용하지 않는 것이 중요하다. DOM이나 스타일 변경 작업을 효율적으로 설계하고, Reflow를 최소화하는 방법을 고려해야 한다. 예를 들어, 레이아웃 정보를 읽고 쓰는 작업을 분리하거나, `requestAnimationFrame`을 활용하여 렌더링 타이밍에 맞춰 작업을 수행하는 것이 성능 최적화에 도움을 줄 수 있다.

### 레이아웃 쓰레싱의 의문

브라우저는 HTML 파일을 파싱하여 DOM 트리를 생성하고, link 태그를 만나면 CSSOM을 생성한다. 자바스크립트가 DOM을 조작하면, 브라우저는 DOM 트리 생성을 중단하고 자바스크립트 실행을 완료한 후 DOM 트리 생성을 재개한다. 이후, DOM과 CSSOM을 결합하여 Render Tree를 만든다.

이 과정을 살펴보면, `레이아웃 쓰레싱이 어떻게 발생하는지 이해하기 어렵다`. 왜냐하면 Render Tree가 생성된 이후에야 레이아웃 계산(Reflow)이 일어나기 때문이다.

하지만 Render Tree가 완성되기 이전에도 레이아웃 쓰레싱이 발생할 수 있는 이유는 자바스크립트 실행 중에 Forced Reflow가 발생하기 때문이다. Forced Reflow가 발생하면 브라우저는 Recalculate Style 단계를 실행하여 DOM과 CSSOM을 기반으로 Render Tree를 업데이트한다.

따라서, Render Tree는 자바스크립트가 실행되는 동안에도 동적으로 생성되거나 갱신될 수 있으며, 이 과정에서 반복적인 DOM 읽기/쓰기 작업이 강제 Reflow를 유발하면 레이아웃 쓰레싱이 발생할 수 있다.

![Recalculate style](/posts/JavaScript/reflow/layout-thrashing.png)

### 동기식 Reflow에서는 매번 Rendering이 진행될까?

브라우저 렌더링 과정에서 Reflow가 발생하면 Paint, Compositing 단계를 거쳐 DOM에 Commit 된다는 것은 모두 알고 있을 것이다. 하지만 동기식 Reflow에서는 Paint, Commit 단계를 진행하지 않는다. 이러한 점을 보았을 때 Reflow가 된다고해서 반드시 DOM에 Commit되지 않는다는 것을 알 수 있다. 만약 Commit 단계까지 갔다면, 숫자가 카운트되면서 올라가는 애니메이션이 진행되어야하는데, 실제로는 그렇지 않다는것을 알 수 있다.

추가적으로, 자바스크립트가 실행 중일 때 브라우저는 렌더링 작업이 차단된다. 즉, 반복문에서 Reflow를 유발하더라도 자바스크립트 실행이 끝나기 전까지 브라우저는 화면을 렌더링하지 않는다. 이는 브라우저가 싱글 스레드로 동작하며, 자바스크립트와 렌더링 작업을 병렬로 처리하지 않기 때문이다. 따라서, Reflow가 발생하더라도 실제 렌더링은 자바스크립트 실행이 완료된 후에 이루어진다.

만약 자바스크립트가 렌더링을 차단하지 않도록 하기 위해 긴 작업을 작은 단위로 나누고, `setTimeout`이나 `requestAnimationFrame`을 사용해 비동기적으로 작업을 분리하면 브라우저가 렌더링과 자바스크립트 실행을 병행할 수 있다. 이러한 방법은 React에서 긴 동기 작업으로 인해 UI가 멈추는 문제를 해결하기 위해 비동기적으로 동작하는것과 비슷하다.

### 그렇다면 Reflow 최적화를 할 필요가 없을까?

성능 최적화에 관심이 많은 분들은 위 코드(비동기 Reflow)를 최적화하기 위해 다음과 같은 방식을 사용하는 경우를 볼 수 있다

```ts
let text = ""

button.addEventListener("click", () => {
  for (let i = 1; i <= 10000; i++) {
    text = String(i)
  }

  paragraph.innerHTML = text
})
```

비동기식 Reflow를 활용한 코드에서도 Reflow는 한 번만 발생하고, 위 코드에서도 Reflow는 한 번만 발생한다. 따라서 Reflow 측면에서는 결과가 동일하다.

그러나 DOM을 한 번만 업데이트하는 것과 여러 번 업데이트하는 것은 성능에서 매우 큰 차이를 가져온다. 이는 브라우저가 DOM 변경 작업을 처리하는 방식 때문으로, Performance 탭을 통해 분석한 결과에서도 이러한 차이가 명확히 드러난다.

#### 여러번의 DOM 업데이트

![여러번의 DOM 업데이트](/posts/JavaScript/reflow/dom-update.png)

여러 번의 DOM 업데이트가 수행된 Performance 결과를 보면, 파란색 막대가 매우 촘촘하게 나타나는 것을 확인할 수 있다. 이 파란색 막대는 parseHTML 과정을 나타내며, 브라우저가 HTML 문자열을 파싱하여 DOM 트리를 생성하는 작업을 의미한다.

DOM을 반복적으로 업데이트하면 브라우저가 계속해서 DOM 트리를 재생성해야 하므로, 긴 태스크 작업 경고창이 표시되었다(위 빨간색 막대) 이 특정 작업에서는 154.47ms의 시간이 소요되었으며, 병목 현상으로 이어지고 있다.

#### DOM 업데이트 최적화

![DOM 업데이트 최적화](/posts/JavaScript/reflow/dom-update-optimization.png)

최적화된 DOM 업데이트의 Performance 결과를 보면, DOM 트리를 생성하는 파란색 막대(parseHTML)가 보이지 않는 것을 확인할 수 있다. 이는 DOM 업데이트 작업이 효율적으로 수행되어 브라우저가 불필요한 parseHTML 작업을 최소화했음을 의미한다. 또한, 태스크 작업 속도가 1.29ms로 매우 짧게 측정되었으며, 이는 성능이 크게 개선되었음을 보여준다. (비록 위 이미지에는 표시되지 않았지만, 작업이 최적화된 결과 29ms밖에 걸리지 않는다는 점이 결정적인 차이로 나타난다.)

#### 결론

즉, Reflow가 한 번만 발생한다고 해서 성능 최적화를 하지 않아도 된다는 뜻은 아니다. 위 예시에서 살펴본 것처럼, 최적화를 수행하지 않으면 DOM 트리를 생성하는 과정에서 병목 현상이 발생할 수 있다.

따라서, 최적화를 진행할 때는 단순히 Reflow 관점에서만 보지 말고, Performance 분석 도구를 활용하여 병목의 원인을 찾아야 한다. 이렇게 하면 문제를 더 직관적이고 명확하게 이해할 수 있으며, 최적화를 더욱 효과적으로 수행할 수 있다.

## 마무리

Reflow에 대해 학습하면서 몇 가지 의문이 들었다. 이를 해결하기 위해 다양한 자료를 찾아보고, 브라우저의 렌더링 과정과 Performance 탭을 활용하여 더욱 깊이 있게 분석해보았다.

- `Reflow 관련 메서드나 프로퍼티를 사용하면 항상 Reflow가 발생하는가?`,
- `Render Tree가 만들어지기 이전에 어떻게 Reflow가 발생하는가?`,
- `Reflow가 발생하면 DOM에 Commit까지 이어지는가?`

이러한 의문과 고민이 없었다면, 다른 사람들에게 잘못된 정보를 전달했을지도 모른다. 이를 통해, 무엇인가를 배울 때는 항상 검증하는 과정이 필요하다는 것을 다시금 느꼈다. 검증을 통해 내용을 확실히 이해할 수 있을 뿐만 아니라, 더 오래 기억에 남게 된다.


Performance 분석을 통한 Reflow Deep Dive

Reflow 딥다이브 (feat. Performance 분석)


올해에는 여러 가지를 해왔지만, 뚜렷하게 이뤄낸 것이 없어 보인다는 생각이 든다. 아마도 취업에 성공하지 못한 것이 그런 기분을 들게 한 것 같다. 남들 못지않게 공부하고 고민도 많이 했지만, 채용시장에서의 나는 아직 부족함이 있는 것 같다.

하지만 이상하게도 내년에는 취업이 잘 될 것 같은 근거 없는 자신감이 있다. 이유는 분명하지 않지만, 원래 사람이 성공을 이루기 위해서는 자신감이 중요하다고 믿는다. 이 자신감을 동력 삼아, 내년에는 더 큰 성과를 이루어낼 수 있을 것이라 확신한다! 💪

## 나는 이번년도에 무엇을 했을까?

작년 12월 말에 부트캠프를 시작하며 프론트엔드 공부를 시작했다. 부트캠프를 하면서 나만의 학습 방법을 찾았고, 지금까지도 연락하는 동료, 좋은 멘토님을 만나게 되었다. 또한, 글또라는 커뮤니티에 들어와 다른 사람들의 아티클과 고민도 엿볼 수 있는 기회가 생기기도 했다. 이번년도에는 대부분의 시간이 공부와 시장에 대한 나의 평가였던 것 같다. 암울하지만 결과적으로 보면 실패한 24년도인 것 같다.

## 정말 실패한 24년도일까 ?

취준생으로써 취업을 못했으니 결과적으로 본다면 실패다. 하지만 실패했다고해서 인생이 크게 망하거나 하진 않는다. 오히려 이러한 실패가 나에게 굉장한 기회라고 생각한다.

### 좋은 동료

채용 시장에서 평가가 좋지 않아 주변 사람들에게 고민을 털어놓았다. 대부분 나처럼 취업을 준비하는 사람들이었다. 하지만 "열심히 하자"는 한마디가 서로에게 큰 힘이 되었고, 덕분에 부정적인 마음을 긍정적으로 바꿀 수 있었다. 만약 혼자였다면, 나는 아마 부정적인 생각에 깊이 빠졌을지도 모른다. 나는 스스로를 채찍질하는 성향이 강하기 때문이다. 그러나 앞으로 훌륭한 개발자가 될 사람들과 함께 긍정적인 말을 주고받으며, 좋은 인간관계를 형성할 수 있었다.

### 좋은 멘토님

부트캠프 이후에 알게 된 멘토님과 친하게 지내고 있으며, 가끔씩 대면으로 만나 뵙고 있다. 이 멘토님 덕분에 혼자 공부하는 방법에 대해 큰 영향을 받았고, 내가 전혀 생각하지 못했던 관점과 아이디어를 들으며 "이래서 멘토링을 받는구나"라는 깨달음을 얻었다.

개발적으로도 다양한 인사이트를 얻었고, 멘토링 프로그램에 대해서도 소개받아 곧 참여할 예정인데, 정말 기대가 된다. 나중에 내가 취업하게 되면 꼭 이 멘토님께 킹크랩🦀을 대접하며 감사의 마음을 전하고 싶다!

### 이력서 멘토링

인프런에서 이력서 멘토링을 약 5번 정도 받았다. 그중 많은 멘토님들께서 "전반적으로 좋은데요?"라고 긍정적인 피드백을 주셨다. 그 말에 힘이 나기도 했지만, 결과적으로 채용에서는 좋은 성과를 내지 못했다.

멘토링을 받으면서 느낀 점은 **"아무리 잘하는 사람이라도 자기 PR을 잘 못하면 소용없구나"**라는 사실이었다. 각 멘토님들이 내 이력서를 바라보는 시각이 조금씩 달랐고, 이를 통해 내 이력서가 누군가에게는 좋아 보일 수 있지만 다른 사람에게는 그렇지 않을 수 있다는 것을 깨달았다.

이러한 갭을 줄이는 것이 좋은 이력서를 만드는 핵심이라는 생각이 들었다. 지금은 자기 PR을 어떻게 더 효과적으로 할 수 있을지에 대해 깊이 고민하고 있다. (참고로, 이력서 멘토링을 고민하는 분들께는 강력히 추천드리고 싶다!)

### 글또 합류

올해 9월 말에 글또에 합류하면서, 다른 사람들의 아티클과 고민들을 접할 기회가 많아졌다. 글또에 합류하기 전에도 글을 작성해왔지만, 다양한 사람들의 아티클을 보며 글쓰기 실력과 표현 방식에서 큰 도움을 받을 수 있었다.

글또에서의 나의 목표는 프론트엔드 부문 큐레이션에 선정되는 것이었는데, 최근에 실제로 큐레이션에 올라 정말 기분이 좋았다. 심지어 DM으로 연락을 주시는 분들도 있었고, 그분 덕분에 다른 회사에서 내 이력서를 평가받을 기회도 생겼다. (정말 감사드립니다!)

생각보다 빠르게 원하는 목표를 이루었지만, 여기서 멈추지 않고 꾸준히 글을 작성하며 더 많은 큐레이션에 오르는 것을 새로운 목표로 삼고 있다. 앞으로도 계속 성장하며 나아갈 계획이다!

### 채용 결과

나는 올해 약 30개의 이력서를 제출했고, 그중 3곳에서 서류 합격 통보를 받았다. 슈퍼브에이아이, 올라핀테크, 그리고 토스 플레이스였다. 올라핀테크를 제외하고는 모두 인턴십에 지원했고, 과제 평가까지 진행했지만 아쉽게도 과제에서 탈락하고 말았다. 결과는 기대에 못 미쳤지만, 이를 통해 내 부족한 점을 명확히 파악할 수 있었다. 다음번에는 더 나은 성과를 낼 수 있을 것 같다.

내가 최종적으로 목표하는 회사는 토스의 UX 엔지니어가 되는 것이다. 앞으로 2년 안에 목표를 이루기 위해 더 열심히 노력해야겠다 :)

### 오픈소스 탐구

개발 실력은 앞서 언급했던 좋은 멘토님 덕분에 많이 성장할 수 있었다. 특히, 오픈소스를 탐구하는 일이 큰 도움이 되었다. 나는 다음과 같은 오픈소스들을 탐구하고 직접 구현해 보면서, 다양한 라이브러리가 문제를 해결하는 방식을 배울 수 있었다. 이를 통해 가독성, 확장성, 로직 설계, 그리고 타입 활용과 같은 중요한 개발 요소들을 깊이 이해할 수 있었다.

- React Core
- Redux, Zustand
- Radix UI
- React Hook Form

오픈소스를 탐구하는 과정에서, 기존에 내가 알고 있던 방식만을 고집하지 않고, 한 번 더 깊이 고민하게 되었다. 단순히 구현에 그치지 않고, 더 나은 설계와 로직을 어떻게 처리할지에 대한 고민은 내 성장에 있어 매우 중요한 요소가 되었다.

캡틴 판교님의 "저 사수 없이 공부했어요. 제 사수는 오픈소스 라이브러리에요."라는 말이 정말로 와닿았다. 실제로 상태 관리를 직접 만들어보면서, "Zustand는 리액트에서 Provider 없이 어떻게 전역 상태로 동작하는 거지? 어떻게 상태를 변경하지?"라는 궁금증이 생겼다. 답은 모두 소스코드 안에 있었다. 이러한 궁금증을 해결하며 얻는 깨달음은 나를 정말 행복하게 했다.

## 현재의 삶

지금은 암울한 이야기지만, 현재 돈이 부족하고 갚아야 할 빚이 있어 물류센터에서 일용직으로 일하고 있다. 일을 하면서 시간의 소중함을 절실히 깨닫게 되었다. 앞으로는 공부할 시간이 부족하겠지만, 그만큼 시간의 가치를 되새기며 더 효율적이고 알차게 공부해야겠다고 다짐했다.

한동안 돈 걱정에 사로잡혀 아무것도 하지 못했던 나 자신을 돌아보며, 이제는 그런 상황을 인정하고 앞으로 나아갈 때라고 생각한다. 지금의 어려움이 오히려 나를 더 단단하게 만들어줄 것이라고 믿고, 더 열심히 노력해야겠다.

## 끝으로

2024년은 결과적으로 실패한 한 해로 보일 수도 있지만, 공부라는 카테고리 안에서는 생각보다 많은 것을 이루고 성장할 수 있었다. 이러한 경험들은 내가 발전하는 데 중요한 밑거름이 되었고, 곧 시작할 멘토링을 떠올리며 내년에는 정말 취업에 성공할 수 있을 것 같은 자신감이 생긴다! 2025년에는 더 큰 성과를 이루기 위해 계속해서 노력할거다.

2024년 저에게 도움을 주신 모든 분들께 진심으로 감사드립니다🙏 취준생 파이팅!


올해에는 여러 가지를 해왔지만, 뚜렷하게 이뤄낸 것이 없어 보인다는 생각이 든다. 아마도 취업에 성공하지 못한 것이 그런 기분을 들게 한 것 같다. 남들 못지않게 공부하고 고민도 많이 했지만, 채용시장에서의 나는 아직 부족함이 있는 것 같다.

2024년 마지막 회고

상태 관리를 통해 React Hook Form과 유사한 인터페이스의 훅 만들기 🚀

React Hook Form과 유사한 인터페이스 만들기


드롭다운 메뉴는 웹 애플리케이션에서 흔히 볼 수 있는 UI다. 누구나 한 번쯤 만들어 본 경험이 있을 것이다. 만드는 것도 크게 어렵지 않다. 내가 부트캠프를 하면서 사용했던 드롭다운 메뉴는 재사용성과 확장성이 떨어져, 남의 코드에 if문이 덕지덕지 붙거나 다시 만든 경험이 있었다. 프론트엔드를 배운 대부분의 사람은 이를 구현할 수 있다. 하지만 구현에만 초점을 둔 것과 확장성과 유연성을 고려한 것과는 시간이 지남에 따라 큰 차이가 나타난다. 왜냐하면 처음부터 완벽한게 만들 수 없기 때문에 기능을 수정하거나 추가할 때 구조가 제 역할을 하지 못할 가능성이 커진다. 결국 복잡성이 증가하면서 코드를 이해하고 해석하는 데 더 많은 시간이 소요되게 된다. 따라서, 구현에만 초점을 둔 초안을 바탕으로 점진적으로 어떻게 개선하는지에 대한 나의 방법을 공유하겠다.

## 알아두면 좋은 것.

우선, 만들기 전에 용어 정리를 할 필요가 있다. 바로 Dropdown Menu와 Select의 차이다. 둘 다 비슷한 UI지만 서로 다른 성격을 띤다. 우리는 디자이너와 소통도 해야 하고, 명칭을 제대로 알아야 올바른 요구사항을 만들 수 있다.

- **Dropdown Menu**: 메뉴의 항목을 클릭했을 때 특정 동작(페이지 이동, 특정 기능)을 수행하거나 중첩된 하위 메뉴들을 보여주는 특징이 있다.
- **Select**: HTML의 select 태그를 생각하면 된다. 즉, Form에서 사용자에게 입력 받기 위해 여러 옵션을 제공하여 선택하게 하는 하나의 입력 요소를 말한다.

즉, 서로 비슷한 UI이지만, 달성하려는 목적이 다르기 때문에 요구사항 또한 다르다. 실제로 나도 드롭다운 메뉴와 셀렉트를 동시에 사용하려다 보니 코드가 많이 지저분해졌던 경험이 있었다.

## 드롭다운 만들기

### 요구사항 정의하기

드롭다운 메뉴를 닫힌 상태와 열린 상태로 정의해 보았다.

#### 메뉴가 닫혀있는 상태

- Dropdown 버튼을 클릭하면 메뉴가 나타난다.

#### 메뉴가 열려있는 상태

- Dropdown 버튼을 클릭하면 메뉴를 닫을 수 있다.
- 하위 메뉴를 클릭하면 특정 동작이 수행되고, 메뉴는 닫혀야 한다.
- Dropdown 바깥을 클릭했을 때 메뉴는 닫혀야 한다.
- 중첩된 메뉴를 가진 하위 메뉴에 마우스를 올리면 중첩된 메뉴가 보여야 한다.

### 일반적으로 구현하는 드롭다운의 형태

구현에 집중하다 보면 다음과 같은 형태로 만들곤 한다. 구글에 검색해보면 비슷한 방식으로 만든 포스트들이 있다.

```tsx
import { FaAngleDown } from "react-icons/fa6"
import useToggle from "../hooks/useToggle"
import useOutSideClick from "../hooks/useOutSideClick"

export default function Dropdown() {
  const { handleToggle, handleCloseToggle, isToggle } = useToggle()
  const dropdownRef = useOutSideClick<HTMLDivElement>({ onCloseToggle: handleCloseToggle })

  return (
    <div className="relative text-white" ref={dropdownRef}>
      <button
        className="px-3 py-3 bg-gray-800 rounded-lg flex justify-between items-center gap-6"
        onClick={handleToggle}
      >
        드롭다운
        <div>
          <FaAngleDown className={isToggle ? `rotate-180` : `rotate-0`} />
        </div>
      </button>
      {isToggle && (
        <ul className="absolute top-full translate-y-1 bg-gray-800 rounded-lg text-sm w-full p-1 gap-1.5">
          <li className="dropdown-menu-item">
            <button className="w-full p-2">특정 기능</button>
          </li>
          <li className="hover:bg-gray-700 rounded-md relative group">
            <div className="w-full p-2">중첩 메뉴 기능</div>
            <ul className="hidden absolute w-[150px] group-hover:block bg-gray-800 rounded-lg translate-x-full top-0 right-4 p-1 gap-1.5">
              <li className="dropdown-menu-item">
                <button className="w-full p-2">중첩 메뉴 1</button>
              </li>
              <li className="dropdown-menu-item">
                <button className="w-full p-2">중첩 메뉴 2</button>
              </li>
              <li className="dropdown-menu-item">
                <button className="w-full p-2">중첩 메뉴 3</button>
              </li>
            </ul>
          </li>
          <li className="dropdown-menu-item">
            <button className="w-full p-2">페이지 이동 기능</button>
          </li>
        </ul>
      )}
    </div>
  )
}
```

### 문제점

위 코드는 다음과 같은 문제가 있다.

- 재사용이 불가능하고, 유지보수 측면에서 UI가 변경될 때마다 모든 파일을 수정해야 한다.
- 기존 코드에서 수정을 해야 하므로 확장성이 떨어진다. OCP(개방 폐쇄 원칙) 위반
- 일관성이 깨지고, 코드를 해석하는 데 시간이 많이 소요된다.
- 사용할 때마다 필요한 훅을 매번 불러와야 한다.

구현에만 집중할 경우 위와 같이 만드는 경우가 생각보다 흔하며, 훅으로 로직을 분리하지 않는 경우도 많다. 재사용성이 떨어지면 중복된 코드가 많아질 확률이 높아진다. 즉 클라이언트 리소스가 그만큼 소모된다는 말이다. 또한, 확장에 열려있어야하고 수정에 대해서는 폐쇄적이여야 한다는 OCP 원칙에 위반되기도 한다.

이 문제를 해결하기 위해 드롭다운 메뉴를 컴포넌트로 분리하고, 리스트를 props로 전달받는 경우도 있다.(추상화가 어떻게 되냐에 따라 좋은 접근이 될 수 있다) 하지만 드롭다운 메뉴는 버튼만으로 동작하는 것이 아니다. `<Link />` 컴포넌트로도 동작할 수 있다. 물론 Router 메서드를 사용할 수 있지만, map을 사용해 렌더링할 때 분기 처리가 필요하기 때문에 가독성 면에서 좋지 않다고 느낀다.

### 어떻게 개선할 수 있을까 ?

개선을 하기 전에 컴포넌트 설계를 다시 해봐야 한다. 경험이 부족하다면 코드를 개선하는 것이 쉽지 않기 때문에, 구현에 앞서 충분한 구상과 다양한 방법을 시도하는 것이 중요하다. 이 문제는 다음과 같은 방식으로 해결할 수 있다.

- 재사용성을 높이기 위해 단일 책임 원칙을 지키고, 컴포넌트를 세부적으로 쪼갠다.
- 세부적으로 쪼갠 컴포넌트를 합성해서 사용하면 재사용성, 확장성, 그리고 유연성을 향상시킬 수 있다.
- 반복해서 호출해야 하는 훅들은 Context API를 사용해 지역적으로 관리할 수 있다.

드롭다운 메뉴, 드롭다운 메뉴 버튼, 드롭다운 메뉴 리스트, 드롭다운 메뉴 리스트 아이템 등으로 컴포넌트를 분리하면 각 컴포넌트가 단일 책임 원칙을 따르며 하나의 역할만 수행하게 되어, 재사용성이 크게 향상된다. 반복적으로 호출되는 훅을 Context API 대신 React.cloneElement를 사용해 children props를 병합할 수 있다. 그러나 드롭다운 메뉴의 개수가 고정되지 않고, 특정 기능이 props로 전달되어 사용될 수 있기 때문에 복잡성이 증가할 수 있다.

### 라이브러리 분석을 해야하는 이유

스스로 문제를 해결하는 것도 중요하지만, 이미 이러한 문제를 경험한 개발자들이 많다는 점을 기억해야 한다. 바로 라이브러리를 만든 사람들이다. 라이브러리를 만든 사람들은 다양한 요구사항에 대응하며 작업한다. 유명한 라이브러리는 사용하기 쉽고 유연하며 확장성이 뛰어나다. 즉, 우리는 라이브러리의 소스 코드를 분석함으로써 많은 통찰을 얻을 수 있다. Radix UI의 DropdownMenu 소스 코드를 살펴보자.

```tsx
<DropdownMenu.Root>
  <DropdownMenu.Trigger>
    <Button variant="soft">
      Options
      <DropdownMenu.TriggerIcon />
    </Button>
  </DropdownMenu.Trigger>
  <DropdownMenu.Content>
    <DropdownMenu.Item shortcut="⌘ E">Edit</DropdownMenu.Item>
    <DropdownMenu.Item shortcut="⌘ D">Duplicate</DropdownMenu.Item>
    <DropdownMenu.Separator />
    <DropdownMenu.Item shortcut="⌘ N">Archive</DropdownMenu.Item>

    <DropdownMenu.Sub>
      <DropdownMenu.SubTrigger>More</DropdownMenu.SubTrigger>
      <DropdownMenu.SubContent>
        <DropdownMenu.Item>Move to project…</DropdownMenu.Item>
        <DropdownMenu.Item>Move to folder…</DropdownMenu.Item>
        <DropdownMenu.Separator />
        <DropdownMenu.Item>Advanced options…</DropdownMenu.Item>
      </DropdownMenu.SubContent>
    </DropdownMenu.Sub>

    <DropdownMenu.Separator />
    <DropdownMenu.Item>Share</DropdownMenu.Item>
    <DropdownMenu.Item>Add to favorites</DropdownMenu.Item>
    <DropdownMenu.Separator />
    <DropdownMenu.Item shortcut="⌘ ⌫" color="red">
      Delete
    </DropdownMenu.Item>
  </DropdownMenu.Content>
</DropdownMenu.Root>
```

코드를 보면 합성 컴포넌트(Compound Pattern)을 사용한 것을 확인할 수 있다. 합성 컴포넌트를 사용하면 다음과 같은 이점이 있다.

- 유연한 UI 구조
- 재사용성
- 관심사 분리(상태와 UI 분리)

위 코드는 훅을 별도로 호출하지 않는다. 내부적으로 상태를 공유하고 있어, 드롭다운 기능이 하나의 일관된 단위처럼 느껴진다. 합성 컴포넌트를 사용하면 props를 효율적으로 분산시킬 수 있으며, 각 컴포넌트가 본연의 역할만 수행하게 되어 재사용성과 유연성이 높아지고, 확장성 또한 향상된다.

현재 우리가 만든 코드를 합성 컴포넌트를 사용해 만든다면, 재사용 가능하고 유연한 컴포넌트를 구현할 수 있게 된다. 똑같진 않지만 유사한 방식으로 만들어보자.

### 초안을 Compound Pattern으로 바꿔보자.

기존에 만들었던 초안을 바탕으로 Compound Pattern을 적용하면 Radix UI처럼 유사하게 만들 수 있다. 네이밍은 Radix UI를 그대로 따랐으며, 내부 상태 관리는 Context API를 사용했다.

> [Compound Pattern에 대해 알고싶다면 여기를 클릭하세요!](https://d5ng-blog.vercel.app/React/compound-pattern)

```tsx
// ui/DropdownMenu.tsx
import { createContext, ReactNode, useContext } from "react"
import { FaAngleDown } from "react-icons/fa6"
import useToggle from "../hooks/useToggle"
import useOutSideClick from "../hooks/useOutSideClick"

export interface ChildrenProps {
  children: ReactNode
}

export type DropdownMenuContextType = {
  isOpen: boolean
  toggle: () => void
  close: () => void
}

export const DropdownMenuContext = createContext<DropdownMenuContextType>({
  isOpen: false,
  toggle: () => {},
  close: () => {},
})

function useDropdownMenu() {
  const ctx = useContext(DropdownMenuContext)
  if (!ctx) throw new Error("Dropdown Menu에서 사용해주세요.")
  return ctx
}

export default function DropdownMenu({ children }: ChildrenProps) {
  const toggleState = useToggle()
  const dropdownRef = useOutSideClick<HTMLDivElement>({ callback: toggleState.close })

  return (
    <DropdownMenuContext.Provider value={toggleState}>
      <div className="relative text-white" ref={dropdownRef}>
        {children}
      </div>
    </DropdownMenuContext.Provider>
  )
}

function DropdownMenuTrigger({ children }: ChildrenProps) {
  const { toggle } = useDropdownMenu()
  return (
    <button className="px-3 py-3 bg-gray-800 rounded-lg flex justify-between items-center gap-6" onClick={toggle}>
      {children}
    </button>
  )
}

function DropdownMenuTriggerIcon() {
  const { isOpen } = useDropdownMenu()
  return (
    <div>
      <FaAngleDown className={isOpen ? `rotate-180` : `rotate-0`} />
    </div>
  )
}

function DropdownMenuContent({ children }: ChildrenProps) {
  const { isOpen } = useDropdownMenu()
  if (!isOpen) return null
  return (
    <ul className="absolute top-full translate-y-1 bg-gray-800 rounded-lg text-sm w-full p-1 gap-1.5">{children}</ul>
  )
}

function DropdownMenuItem({ children }: ChildrenProps) {
  return <li className="dropdown-menu-item w-full p-2">{children}</li>
}

function DropdownMenuSub({ children }: ChildrenProps) {
  return <li className="hover:bg-gray-700 rounded-md relative group">{children}</li>
}

function DropdownMenuSubTrigger({ children }: ChildrenProps) {
  return <div className="w-full p-2">{children}</div>
}

function DropdownMenuSubContent({ children }: ChildrenProps) {
  return (
    <ul className="hidden absolute w-[150px] group-hover:block bg-gray-800 rounded-lg translate-x-full top-0 right-4 p-1 gap-1.5">
      {children}
    </ul>
  )
}

DropdownMenu.Root = DropdownMenu
DropdownMenu.Trigger = DropdownMenuTrigger
DropdownMenu.Content = DropdownMenuContent
DropdownMenu.Item = DropdownMenuItem
DropdownMenu.TriggerIcon = DropdownMenuTriggerIcon
// Sub
DropdownMenu.Sub = DropdownMenuSub
DropdownMenu.SubTrigger = DropdownMenuSubTrigger
DropdownMenu.SubContent = DropdownMenuSubContent
```

```tsx
// components/Dropdown.tsx
import DropdownMenu from "@/ui/DropdownMenu.tsx"
export default function Dropdown() {
  return (
    <DropdownMenu.Root>
      <DropdownMenu.Trigger>
        드롭다운
        <DropdownMenu.TriggerIcon />
      </DropdownMenu.Trigger>
      <DropdownMenu.Content>
        <DropdownMenu.Item>특정 기능</DropdownMenu.Item>
        <DropdownMenu.Sub>
          <DropdownMenu.SubTrigger>중첩 메뉴 기능</DropdownMenu.SubTrigger>
          <DropdownMenu.SubContent>
            <DropdownMenu.Item>중첩 메뉴 기능1</DropdownMenu.Item>
            <DropdownMenu.Item>중첩 메뉴 기능2</DropdownMenu.Item>
            <DropdownMenu.Item>중첩 메뉴 기능3</DropdownMenu.Item>
          </DropdownMenu.SubContent>
        </DropdownMenu.Sub>
        <DropdownMenu.Item>페이지 이동 기능</DropdownMenu.Item>
      </DropdownMenu.Content>
    </DropdownMenu.Root>
  )
}
```

각 컴포넌트를 세분화하여 단일 책임 원칙을 적용한 덕분에 재사용성이 크게 향상되었고, 중복을 줄여 DRY 원칙을 지키게 되었다. 또한, 새로운 요구사항이 들어와도 기존 컴포넌트를 수정하지 않고 추가할 수 있어 확장성이 보장되며, 요구사항이 변화할 때도 쉽게 수정할 수 있어 유연성도 확보되었다. 초안에 비해 훨씬 안정적인 컴포넌트로 개선되었다.

### Compound Pattern을 사용할 때 주의할 점

현재 코드에서는 모든 컴포넌트를 한 번에 import하는 방식으로, 사용하지 않는 드롭다운 컴포넌트들도 함께 불러오는 문제가 있다. Radix UI를 기반으로 한 Shadcn UI는 필요한 컴포넌트만 개별적으로 import하여 불필요한 코드가 포함되지 않으며, 이로 인해 성능이 더욱 유리하게 최적화되어 있다. 따라서 현재 코드를 각 컴포넌트별로 import할 수 있도록 수정하면, 필요한 컴포넌트만 불러와 파일 크기를 줄이고 성능을 개선할 수 있다.

### 오해하면 안되는 부분

여기서 오해하지 말아야 할 점이 있다. 위 코드는 컴포넌트의 형태를 UI 라이브러리와 비슷하게 구현한 것이지, Radix UI처럼 완전히 구현한 것은 아니다. 개선된 코드를 살펴보면, `<DropdownMenuTrigger />` 컴포넌트 내부에 버튼이 포함되어 있다. 하지만 버튼은 중첩될 수 없기 때문에, 버튼 태그를 포함한 컴포넌트를 사용할 수 없는 문제가 발생한다. Radix UI는 **Render Delegation** 기법을 사용해 이 문제를 해결하고 있다.

```tsx
// Radix UI의 특징
// Trigger에는 button이 내장되어 있지만 asChild를 사용하여 아래 버튼과 병합하고. Trigger에 기본 상태인 드롭다운의 메뉴를 열고, 닫는 상태들을 포함하고 있다.
<DropdownMenuTrigger asChild>
  <Button variant="outline">Open</Button>
</DropdownMenuTrigger>
```

> Render Delegation은 컴포넌트가 자신이 직접 UI를 렌더링하는 대신, 렌더링을 다른 컴포넌트나 함수로 위임하는 패턴입니다. 이 패턴은 코드의 재사용성을 높이고, 컴포넌트의 책임을 분리함으로써 유지보수성을 향상시키는 데 도움을 줍니다.

## 마치며

일반적인 방식으로 만든 드롭다운의 문제점을 파악하고, 합성 컴포넌트를 사용해 단일 책임 원칙을 지키며 중복 코드를 방지해 DRY 원칙을 준수함으로써 개선 과정을 보여주었다. 그러나 합성 컴포넌트가 항상 최선의 선택은 아닐 수 있으므로, 상황에 따라 더 적합한 방법이 있을 수 있음을 염두에 두자.

또한, UI 컴포넌트를 만들 때 무의식적으로 간단하게 구현하려는 경향이 있다. 하지만 자신이 만든 컴포넌트가 진정으로 좋은지 한 번 더 고민해볼 필요가 있다. 다양한 라이브러리에서 컴포넌트의 네이밍과 구현 방식을 살펴보며 분석하는 과정은 더 나은 컴포넌트를 설계하는 데 큰 도움이 된다.

이 글에서는 Radix UI의 특징인 `Render Delegation`까지 적용해 보여 드리고 싶었지만, 라이브러리의 소스 코드를 그대로 사용하면 되기에 생략하겠다. 관심 있는 분들은 아래의 링크를 참고하면 좋을 것이다.

## 레퍼런스

- [Radix UI Dropdown](https://github.com/radix-ui/primitives/blob/main/packages/react/dropdown-menu/src/DropdownMenu.tsx)
- [Render Delegation](https://www.radix-ui.com/primitives/docs/utilities/slot)


당신의 드롭다운 메뉴는 재사용성과 확장성을 고려하고 있나요?

점진적으로 드롭다운 메뉴 개선하기


## 어린시절의 "나"

저는 어렸을 때부터 공부를 못했어요. 초등학생 때부터 중학교 2학년까지 공부를 했음에도 성적이 잘 안 나왔어요. 사람마다 노력이라는 기준은 다르겠지만, 그때의 나는 남들보다 공부하는 시간도 더 많았어요. 항상 이루고 싶었던 것이 "평균 80점은 넘기자" 였어요. 초등학생 때에는 웬만한 사람들이 평균 80점은 넘겼다고 하더라고요. 제 친구들도 다 그랬죠. 하지만 저는 공부를 해도 평균 80점을 못 넘겼고 초등학교 6학년 때 성적이 안 나오니 엄마 품에 안겨 울었던 기억이 생생하네요.

그렇게 평균 80점이라는 목표에 실패하고 중학생이 되었어요. 중학교 1학년 때에는 방황을 하면서 놀았어요. "나는 원래 공부 못하는 사람이다." 라고 생각하며 포기했어요. 그 이후로 중학교 2학년이 되었을 때 TV에서 "공부의 신" 이라는 드라마를 보고 공부가 너무 하고 싶다는 생각이 들었어요. 제가 초등학생 때 못 이뤘던 평균 80점을 넘기자는 목표로 다시 시작했어요. 결과적으로는 280등을 하던 제가 77등까지 올랐고 처음으로 상까지 받았어요. 하지만 평균 79점이 나왔고, 공부를 포기하기로 했어요. 이유는 그 이상으로 공부할 자신이 없었고 남들보다 많이 노력하지만, 결과가 좋지 않았고 스스로한테 상당한 스트레스였어요.

그렇게 공부를 포기하고 고등학교 2학년 때 음악이 하고 싶어 음악 학원에 다녔어요. 저는 노래가 하고 싶었어요. 보통은 가수가 꿈이지만 저는 실용음악과 교수가 꿈이었어요. 노래는 못했고 그냥 열정만 가득한 학생이었어요. 이때는 학교에 가지도 않고 맨날 연습실 가서 발성연습과 노래연습만 했었어요. 재밌었거든요. 이때부터 사람들이 저에게 "노력의 천재" 라는 말을 자주 했었어요. 음악도 공부와 마찬가지로 성적이 잘 나오지 않았어요. 연습은 아침 9시부터 새벽 3시까지 했었는데 말이죠. 좋은 대학을 가고 싶었지만 모두 실패했어요. 그렇게 3수까지 하면서 실력도 많이 늘었고 좋은 성적도 나왔지만 노력한 만큼의 결과가 나오지 않았고 음악은 나중에 취미로 하기로 마음먹고 입대를 하게 되었어요.

## 개발자로의 도전

전역 후에는 돈을 벌어야 해서 공장과 배달 아르바이트를 하면서 지냈어요. 하지만 좋아하는 일이 아니어서 오래 못할 거라는 생각이 들었고 해커가 되고 싶다는 생각에 컴퓨터 학원을 찾아다니며 상담받았어요. 학원 원장님이 웹 해킹이 있고, 이것을 하려면 웹 사이트도 만들 줄 알아야 한다고 했어요. 그렇게 국비과정인 웹 퍼블리셔 과정을 듣게 되었고 수업에 따라가기 위해선 하루 9시간은 공부해야 했어요. 해킹은 당연히 포기했어요. 수업 따라가기에도 벅찼거든요. 이때에도 제가 제일 못하는 사람이었어요. 하지만 포기하지 않고 끝까지 노력하니 학원에서 상도 받았고 제일 먼저 취업하게 되었어요. 기분은 좋았지만, 여전히 많은 노력을 해야 남들과 비슷해지는 것이 너무 싫었어요.

퍼블리셔로 일하면서 자바스크립트를 너무 못해 힘들기도 했지만 재밌었어요. 특히 애플 사이트처럼 인터랙션 부분에 관심이 많았었어요. 이런 쪽으로 공부를 많이 했었고, 회사에 다니면서 "GDWeb (Good Design Web)"에서 수상하는 것을 목표로 하고 있었어요. 그렇게 매일 공부를 하며 지내다 보니 1년 이후에 운이 좋게도 수상을 하게 되었어요. 노력한 만큼의 결과는 주진 않더라도 배신은 하지 않아 좋았어요. 퍼블리셔로 2년 9개월을 다니며 총 2번의 수상과 과외활동을 통해 이직 제안도 받았던 좋은 경험이었어요. 자바스크립트가 조금은 익숙해지다 보니 프론트엔드 개발자로 가고 싶다는 생각이 들었고 다니던 회사를 퇴사하고 부트캠프를 다녔어요. 부트캠프를 하면서 공부 방법에 대해 연구를 정말 많이 했던 것 같아요. 같은 노력이지만 성장 곡선이 다를 수 있다는 것을 깨닫게 되었어요. 지금껏 살아오면서 정말 열심히만 해왔던 것 같아요. 이런 깨달음을 진작에 알았더라면, 지금 나는 어떤 삶을 살고 있을까?"라는 생각을 가끔씩 합니다. 현재는 프론트엔드 취업을 준비하며 여러 스터디와 프로젝트에 참여하며 매일 열심히 살아가고 있어요.

## 나를 되돌아보는 시간

제 인생에는 항상 많은 노력을 했던 것 같아요. 남들보다 잘 못했었기에 그만큼 잘하고 싶다는 의지도 강했던 것 같기도 해요. 글을 작성하는 지금도 "어떻게 해야 더 잘할까"라는 고민은 끝없이 하고 있어요. 회고를 왜 하나 싶었었는데 글들을 작성해보니 이유를 알겠더라고요. 지금까지 노력한 만큼 결과가 나오지 않았던 이유는 뒤를 돌아보지도 않고 직진한 이유가 컸던 것 같아요. 뒤를 돌아보면서 무엇이 문제였는지 어떻게 개선할지에 대한 방법들을 찾아보고 기록했으면 좋았을 텐데 라는 아쉬움이 많이 남아있어요. 블로그를 몇 개월 전에 시작했지만 글또에 참여해서 여러 사람과 소통하며 더 나은 글이 되었으면 하는 바람이고 지금보다 더 성장하는 기회라고 생각해요. 앞으로의 여정이 더 힘들 수 있겠지만 원하는 목표를 이룰 때까지 도전해보려고 합니다.

---

글또 10기에 참여가 확정났습니다 🎉 열심히 글 작성하도록 해보겠습니다 :)


지금의 내가 되기까지의 이야기..

삶의 지도 [글또 10기]


## 계기

코드잇 부트캠프를 수료한 후 벌써 3달이라는 시간이 지났다. 처음 한 달 동안은 방황을 많이 했다. 간혹 부트캠프를 여러 번 수강하는 사람도 있다고 들었는데, 그 마음을 간접적으로 알 것 같았다. 부트캠프를 할 때에는 강제로 공부해야 하지만, 부트캠프가 끝나면 본인의 의지로 해야 한다. 여기서 환경이 중요하다는 것을 많이 느꼈다.

나는 대출받아 생활하고 있으며, 이제 더 이상 대출도 받지 못하는 상황이다. 공부해서 좋은 곳에 취업하려고 시간과 돈을 썼는데, 이렇게 하다가는 경쟁력 없는 사람이 될 것 같았다. 어떻게든 공부해야 한다는 다짐을 하며 "주 70시간 공부하자"라는 막연한 목표를 세우게 되었다.

## 과정

나는 배움에 늘 갈증이 있었기 때문에 주도적으로 "클린 코드 스터디"를 하나 개설했고, 아티클을 읽고 공유하는 스터디, 2주에 한 번씩 블로그를 작성하는 스터디, 면접 스터디까지 총 4개의 스터디를 하고 있다. 스터디를 많이 하다 보니 약속은 당연히 잡을 수 없고, 개발에 몰두할 수 있는 환경을 만들었다.

다양한 스터디를 하면서 관련된 공부를 하다 보니 이론적으로나 실력적으로 많은 도움이 되었고, 혼자서가 아닌 여러 사람들과 함께하다 보니 다른 사람들의 의견을 통해 생각의 폭도 넓어졌다. 취준생인 나에게는 동기부여가 되어 좋았다.

하루 10시간 동안 스터디 관련 공부만 하는 것은 아니기 때문에 개인 프로젝트도 같이 진행하고 있다. 나는 라이브러리 없이 만드는 것을 선호하기 때문에 데이터 패칭 라이브러리를 제외하고는 거의 사용하지 않았다. React Hook Form과 UI 라이브러리들을 분석하며 비슷하게 만드는 과정이 너무 오래 걸렸다. 하루 10시간이 부족하다고 느껴졌고, 대부분의 시간이 고민하는 시간이었다. 그러다 보니 글을 작성하는 지금도 프로젝트를 끝내지 못했고, 계속 반복하며 열심히 살고 있는 중이다. 😂😂😂

## 느낀 것.

주 70시간을 공부하면서 계획했던 것들이 빨리 끝날 줄 알았지만, 현실은 그렇지 않았다. 내 완벽주의 성향 때문일까 싶기도 하다. 간단해 보이는 기능도 여러 가지를 고민하다 보면 시간이 두 배 이상 걸리기도 한다. 가끔은 "과연 이 시간이 얼마나 의미 있을까?"라는 생각이 들기도 한다. 과정 자체가 무의미한 것은 아니지만, 경제적인 여유가 없다 보니 조급함을 느끼는 것도 사실이다.

고민하는 시간을 어떻게 줄일 수 있을지 더 고민해 봐야겠다. 경험이 부족해서 그런지, 조금만 더 생각하면 답이 나올 것 같다는 생각이 든다. 다음 회고에서는 지금보다 더 밝고 긍정적인 글을 작성했으면 하는 바람이다.


2개월간 주 70시간씩 공부한 과정과 그 결과에 대한 회고.

주 70시간 공부하기 [회고]


## Compound Pattern이란

Compound Pattern은 여러개의 작은 컴포넌트들을 합성해 만든 디자인 패턴입니다. 여러 개의 작은 컴포넌트란 어떤 말일까요? HTML의 `select` 태그를 봐봅시다.

```html
<select>
  <option value="js">JavaScript</option>
  <option value="ts">TypeScript</option>
</select>
```

select 태그와 option 태그를 사용해 하나의 기능이 완성되는 것 처럼 요소들을 세분화하고 합성해서 사용하는 것을 말합니다. Compound Pattern은 UI 라이브러리(Radix UI, MUI)에서 많이 볼 수 있습니다. UI 라이브러리에서 이 패턴을 사용한다는 건 많은 이점이 있기 때문에 사용한다고 볼 수 있습니다.
Compound Pattern을 사용하면 어떤 이점이 있는지 알아보겠습니다

## Compound Pattern의 장점

- 유연한 UI 구조
- 가독성 및 일관성 있는 코드
- props 관리
- prop drilling
- 관심사 분리

Compound Pattern을 사용하면 장점은 크게 4가지로 구분됩니다. 우선 코드 예시를 봐보겠습니다. 다음은 제가 실제로 작업하면서 만들었던 코드입니다.

```tsx
<FormControl type="form" id="email" hasError={hasError}>
  <FormControl.Label>이메일</FormControl.Label>
  <FormControl.Input type="text" placeholder="이메일을 입력해주세요" {...register("email")} {...props} />
  <FormControl.ErrorMessage />
</FormControl>
```

저는 각 Form에 해당하는 Field들을 Compound Pattern을 적용 했습니다. 먼저 왜 유연한 UI 구조인지에 대해 알아볼게요.

### 왜 유연한 UI 구조인가?

위 코드를 보시면 Atomic Pattern처럼 여러 개의 작은 컴포넌트들을 조합해 사용하고 있습니다. 즉 아래와 같이 하나의 컴포넌트가 여러 가지의 일들을 내장하고 있는 게 아니라 조합해서 사용하기 때문에 유연하다는 특징이 있습니다.

조금 더 설명하자면 아래 예시는 컴포넌트 이름이 잘못되었을 수 있지만, **어떠한 이름을 지어도 저 컴포넌트 안에 어떠한 요소들이 있는지 파악**하기 힘들거나 **이름부터 하는일이 많아진다고 느껴 거부감**이 들게됩니다. 만약 새로운 요구사항이 들어와 `Label`이 없는 FormField를 만든다면 어떻게 해야할까요 ??? 아마 Compound Pattern을 사용하지 않는다면 새로운 컴포넌트를 만들거나 또는 props로 전달해 내부 로직에 추가가 될거에요.

```tsx
<FormControl /> // 안에 구성요소를 보기위해 팀원들은 무조건 내부로직을 봐야합니다.
<FormFieldWithLabel /> // 괜찮지만 이게 정말 명확한 이름일까요 ? 에러메세지가 없다면요 !?
<FormFieldWithLabelWithMessage /> // 음.. 해석하기 싫어지는 이름입니다...
```

### props 관리

요구사항에 맞춰 작업하기 위해 props를 추가적으로 전달하게 된다면 props는 끝날 줄 모르게 늘어나게 됩니다. 즉 컴포넌트의 props가 3개를 초과하게 됩니다. 다음은 제가 협업하면서 팀원이 작성했던 코드를 가져와 볼게요.

```tsx
<InputField
  label="이메일"
  id="email"
  type="email"
  value={email.value}
  autoComplete="email"
  onChange={(e) => setEmail(e.target.value)}
  onBlur={validateEmail}
  placeholder="이메일을 입력해 주세요"
  error={email.error}
  ref={focusRef}
/>
```

위에 Compound Pattern을 사용할 때를 비교해보시면 어떤 느낌이 드시나요? ＂이건 좀 아니지 않나＂ 또는 ＂나쁘지 않은데?＂ 라는 생각이 들 수 있지만, 이 컴포넌트를 사용하는 팀원 입장에서도 생각해보면 좋을 것 같습니다. 본인이 혼자 만들고 사용하는 건 전혀 문제가 되지 않습니다. 처음부터 만들었으니까요. 하지만 사용하는 팀원들은 이해하는데 시간을 꽤 투자할 거에요.

실제로 협업할 때 저희 팀원은 Label이 없는 상황일 때 새로운 컴포넌트를 만들었습니다. 결국 재사용성 부분도 문제가 있습니다. 컴포넌트도 마찬가지로 전달해야하는 **props를 웬만하면 3개를 초과**하지 않는게 사용하는 개발자 입장에서 더 좋을 것 같습니다. 사소하지만 이러한 DX들이 중요하다는 생각이 듭니다.

### prop drilling

Compound Pattern은 Context API를 사용하기 때문에 부모 컴포넌트에서 자식 컴포넌트로 전달할 때 직접 전달할 수 있다는 장점이 있습니다. 따라서 Props Drilling에 대한 걱정이 없고 작은 단위로 Context API를 사용하기 때문에 리 렌더링 문제도 크게 걱정하지 않아도 됩니다.

### 가독성 및 일관성 있는 코드

가독성이 높을 수밖에 없는 이유는 여러 가지의 요소들로 구성되어있기 때문입니다. 추가적으로 이름의 통일성이 있어 가독성이 높아진 것도 한몫합니다. 추가 요구사항에도 대응할 수 있기 때문에 재사용성도 높아지니 일관성 있는 코드라고도 부를 수 있을 것 같네요.

### 관심사 분리

핵심적인 로직은 부모 컴포넌트가 담당하고 있습니다. 따라서 자식 컴포넌트들은 본연의 역할만 수행하게 됩니다. Atomic Pattern처럼 컴포넌트들을 세분화했기 때문에 수정해야 할 요소를 쉽게 파악할 수 있고 컴포넌트 내부만 보아도 간단하여서 파악하거나 수정할 때 유리합니다. 즉 **재사용성을 높이는 방법**이라고 볼 수 있습니다.

## Compound Pattern의 단점

단점으로는 JSX 코드가 많이 길어지는 부분과 레이아웃 순서대로 배치되기 때문에 간혹 이상하게 나오는 경우도 있습니다. 너무 좋은 장점 때문에 일어난 단점이기에 팀원들과 상의하면 충분히 해결할 수 있는 문제라고 봅니다.

## Compound Pattern 구현해보기

정말 간단한 형태인 카운트를 예제로 Context API를 사용해 만들어보겠습니다. 항상 무엇인가를 만들 때 필요한 요소가 무엇인지를 알아야 하고, 상태를 어떻게 관리할 건지에 대해서도 고민해보면 좋을 것 같습니다.

- 카운트된 숫자를 보여줄 컴포넌트
- +1 증가하는 버튼 컴포넌트
- -1 감소하는 버튼 컴포넌트

### 구현부

```tsx
import { createContext, ButtonHTMLAttributes, ReactNode, useContext } from "react"

interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
  children: ReactNode
}

type CountContextType = {
  count: number
  onIncrease: () => void
  onDecrease: () => void
}

interface CountProps extends CountContextType {
  children: ReactNode
}

const CountContext = createContext<CountContextType>({
  count: 0,
  onIncrease: () => {},
  onDecrease: () => {},
})

// CountProvider에서 사용안하는 경우를 대비한 코드입니다.
function useCountContext() {
  const context = useContext(CountContext)
  if (!context) throw new Error("CountContext에서 사용해주세요.")
  return context
}

export default function Count({ children, ...countStates }: CountProps) {
  return <CountContext.Provider value={{ ...countStates }}>{children}</CountContext.Provider>
}

function Score() {
  const { count } = useCountContext()
  return <span>{count}</span>
}

function IncreaseButton(props: ButtonProps) {
  const { onIncrease } = useCountContext()
  return <button onClick={onIncrease}>{props.children}</button>
}

function DescreaseButton(props: ButtonProps) {
  const { onDecrease } = useCountContext()
  return <button onClick={onDecrease}>{props.children}</button>
}

Count.Score = Score
Count.IncreaseButton = IncreaseButton
Count.DescreaseButton = DescreaseButton
```

### 사용부

```tsx
// 사용부
export default function Usage() {
  const [count, setCount] = useState(0)
  const onIncrease = () => setCount((count) => count + 1)
  const onDecrease = () => setCount((count) => count - 1)

  return (
    {/* customHook을 사용하면 {...countState}로 더 깔끔하게도 가능합니다! */}
    <Count count={count} onIncrease={onIncrease} onDecrease={onDecrease}>
      <Count.Score />
      <Count.IncreaseButton>+1</Count.IncreaseButton>
      <Count.DescreaseButton>-1</Count.DescreaseButton>
    </Count>
  )
}
```

## 마치며

상태가 부모 컴포넌트에서만 관리된다면 로직을 부모 컴포넌트(Count)에서 관리해도 상관없습니다. 만약 부모 컴포넌트에서 로직을 관리한다면 props 전달은 필요 없겠네요. 이러한 부분에서 `Popover`와 같은 컴포넌트에서 매우 유용할 것 같습니다.

저는 부모 컴포넌트에서 로직을 지정하지 않고 사용하는 측 컴포넌트에서 작성해 전달해주도록 했습니다. 컴포넌트 만들 때 재사용성을 고려한다면 이처럼 Compound Pattern을 적극 사용해보는 걸 추천합니다.


합성 컴포넌트를 사용해 유연한 UI, 재사용성 향상, 가독성 높은 코드를 만들어보자. 👀

Compound Pattern을 사용해 재사용 극대화하기


자바스크립트는 싱글 스레드 언어다. 하지만 웹에서 일어나는 일들을 보면 동시에 작업을 하는 것처럼 보인다. 이러한 이유는 이벤트 루프 덕분에 가능하다. 이벤트 루프를 알기 전에 다음과 같은 내용들을 알고 있어야 이해하기 쉽다.

- 자바스크립트 특징
- 자바스크립트 엔진
- 자바스크립트의 런타임 환경
- 동기와 비동기

## 자바스크립트의 특징

자바스크립트는 한 번에 한 가지의 일만 처리할 수 있는데, 이것을 `싱글 스레드`라고 부른다. 자바스크립트 엔진은 하나의 콜 스택으로 이루어져 있기 때문에 동시에 처리할 수 있는 능력이 없다.

> 스레드(thread)는 어떠한 프로그램 내에서, 특히 프로세스 내에서 실행되는 흐름의 단위를 말한다. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있지만, 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있다. 이러한 실행 방식을 멀티스레드(multithread)라고 한다.
> [위키백과](<https://ko.wikipedia.org/wiki/%EC%8A%A4%EB%A0%88%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)>)

## 자바스크립트 엔진과 런타임 환경

자바스크립트는 ECMAScript를 기반으로 만들어진 프로그래밍 언어다. 자바스크립트 엔진은 ECMAScript 엔진이라고 말하는 게 더 정확하지만 일반적으로는 자바스크립트 엔진이라고 말을 한다. 즉 자바스크립트 엔진은 ECMAScript를 구현한 것을 말한다. 자바스크립트 런타임 환경은 자바스크립트가 어느 환경에서 실행되는지에 따라 달라진다. `fetch`, `DOM API`들은 브라우저에서 제공받는다. 따라서 자바스크립트는 ECMAScript + 호스트 객체(자바스크립트가 실행되는 환경에서 제공받는 객체)라고 볼 수 있다.

즉 우리가 말하는 자바스크립트가 런타임 환경을 말하는 것인지 ECMAScript인지 명확하게 구분할 필요가 있다. 앞으로 나올 이벤트 루프는 ECMASCript에 정의되어 있지 않은 내용이다. 자바스크립트 엔진이 아닌 자바스크립트 런타임 환경에서 사용되는 개념이다. 따라서 개념의 혼동이 오면 안 된다.

## 동기와 비동기

![Image](/posts/JavaScript/event-loop/snyc-async.png)
자바스크립트는 한 번에 한 가지의 일만 처리할 수 있기 때문에 요청한 작업에 완료 여부를 따져 순차적으로 처리를 한다. 이것을 동기라고 부른다. 동기는 순서가 보장되지만 요청한 작업이 끝날 때까지 블로킹 된다는 단점이 있다. 비동기는 요청한 작업에 완료 여부랑 상관없이 처리하는 것을 말한다. 즉 순서를 예측할 수 없지만, 작업이 끝날 때까지 기다리지 않고 다음 작업을 이어가기 때문에 동기보다 더 많은 일을 할 수 있다.

## 이벤트 루프

![Image](/posts/JavaScript/event-loop/event-loop.jpg)
자바스크립트는 싱글 스레드 언어이지만, 웹 어플리케이션에서는 많은 일이 동시에 일어나는 것처럼 보인다. 자바스크립트 엔진은 단일 호출 스택(CallStack)을 사용하며 요청이 들어올 때마다 해당 요청을 순차적으로 Call Stack에 담아 처리할 뿐이다. 위 그림에서 볼 수 있듯이 `fetch`, `setTimeout`등 비동기 함수들은 자바스크립트 엔진이 아닌 외부에 있는 Web API에서 처리를 하게 된다. 또한, Event Loop, Callback Queue도 마찬가지로 자바스크립트 엔진 외부에 구현되어 있다.

![Image](/posts/JavaScript/event-loop/nodejs-environment.jpg)

위 그림에서도 브라우저 환경과 비슷한 구조를 볼 수 있다. Node.js는 비동기 IO를 지원하기 위해 `libuv` 라이브러리를 사용하며, 이 라이브러리가 이벤트 루프를 제공한다. 자바스크립트 엔진은 비동기 작업을 위해 Node.js의 API를 호출하며 이때 넘겨진 콜백은 libuv의 이벤트 루프를 통해 스케쥴되고 실행된다.

자바스크립트가 싱글 스레드 기반의 언어라는 말은 ＂자바스크립트 엔진이 하나의 콜 스택을 사용한다＂는 관점에서만 사실이다. 실제 자바스크립트가 실행되는 환경인 브라우저, Node.js에서는 주로 여러 개의 스레드(멀티스레드)를 사용되며, 이러한 실행 환경이 하나의 Call Stack을 사용하는 자바스크립트 엔진과 상호 연동하기 위해 사용하는 장치가 바로 `이벤트 루프`인 것이다.

### CallStack

Call Stack은 자바스크립트 엔진 안에 있고, 함수를 호출하면 새로운 실행 컨텍스트가 생성되어 Call Stack에 추가된다. Call Stack은 먼저 들어온 게 나중에 나가는 FILO의 스택이다. 함수가 값을 반환하면 Call Stack에서 제거된다.

![Image](/posts/JavaScript/event-loop/callstack.gif)

위 gif와 같이 자바스크립트는 한 번에 하나의 작업만 처리할 수 있다. 만약 오래 걸리는 작업을 처리한다고 하면, 다른 작업은 처리할 수 없는 블로킹이 발생하게 된다.

### Web API

![Image](/posts/JavaScript/event-loop/web-api.gif)
Web APIs는 브라우저에서 제공하는 API 모음이라고 볼 수 있다. Web APIs의 일부분은 비동기적으로 실행되는 작업들을 처리한다. 대표적으로 `setTimeout`, `fetch`등이 있고, 콜백 함수 방식과 Promise 기반의 방식을 사용한다.

> 여기서 중요한 건 Web APIs가 모든 것을 비동기적으로 처리하지 않는다. `document.querySelector()` 또는 `console.log()`와 같은 메서드들은 동기적으로 처리된다.

### Callback Queue (Task Queue)

![Image](/posts/JavaScript/event-loop/callback-queue.gif)
`Callback Queue`는 Web APIs에서 처리된 콜백 함수를 대기하는 공간이고, 먼저 들어온 게 먼저 나가는 FIFO 구조다. Callback Queue에는 Task Queue와 Micro task Queue가 있다. 둘의 차이점은 우선순위에 따라 처리되는 순서가 달라진다는 점이다. 위 gif에서는 Geo location API를 다루고 있지만, Web APIs에서 처리된 콜백 함수들은 Callback Queue라는 공간에 대기한다고 볼 수 있다.

### Event Loop

![Image](/posts/JavaScript/event-loop/event-loop.gif)

Event Loop은 Call Stack이 비어있는 상태인지 지속해서 확인하고 비어있는 상태라면 Callback Queue에 있는 함수를 Call Stack으로 옮기고 실행시키는 역할을 한다.

위 gif에서는 `setTimeout`에 대한 예제다. 동작 과정을 설명해보자면 다음과 같다.

1. `setTimeout(() => console.log('2000ms'), 2000)`이 호출되면 CallStack에 푸시된다.
2. setTimeout의 콜백 함수는 Web APIs로 이동해 타이머를 시작한다. 이 때 CallStack에 남아있는 setTimeout 함수는 제거된다.
3. 비동기이기 때문에 바로 다음 함수인`setTimeout(() => console.log('100ms'), 100)`을 호출하고 CallStack에 푸시된다.
4. 2번과 마찬가지로 콜백 함수는 Web APIs로 이동해 타이머를 시작하고 CallStack에 남아있는 setTiemout 함수는 제거된다
5. `console.log('End of Script!')`가 실행되고 콘솔에 출력한다. (동기)
6. 100ms가 지나면 `() => console.log('100ms')` 콜백 함수가 Callback Queue 대기열에 추가된다.
7. 이벤트 루프가 CallStack이 비어있는 상태라는걸 감지한 후 `() => console.log('100ms')`함수를 CallStack에 옮기고 실행한다. console.log("100ms")가 출력된다.
8. 2000ms가 지나면 `() => console.log('2000ms')`콜백 함수가 Callback Queue 대기열에 추가된다.
9. CallStack이 비어있어, Callback Queue에 대기중인 `() => console.log('2000ms')` 콜백 함수를 CallStack에 옮기고 실행해 console.log("200ms")가 출력된다.

자바스크립트가 싱글 스레드 언어임에도 동시에 실행하는 것처럼 보였던 이유는 자바스크립트 엔진과 런타임 환경의 Web APIs와 Callback Queue 이 3가지를 이벤트 루프가 관리를 하고 있기 때문이다.

## Reference

- [자바스크립트와 이벤트 루프](https://meetup.nhncloud.com/posts/89)
- [Event Loop와 비동기](https://pozafly.github.io/javascript/event-loop-and-async/)
- [JavaScript Visualized: Event Loop, Web APIs, (Micro)task Queue](https://www.lydiahallie.com/blog/event-loop)

| 2024-08-10 Promise 내용은 추후에 추가됩니다.


자바스크립트는 한 번에 하나의 작업만 처리하는데, 동시에 처리되는 것처럼 보이는 이유는 무엇일까?

이벤트 루프


`props.children`을 사용하면 의도치 않은 동작으로 렌더링이 트리거되거나, 안되는 문제가 발생한다. 또한, 렌더링이 트리거되면 useMemo를 사용해 렌더링을 방지하려고 했지만 이 역시 제대로 동작하지 않는다. 이러한 문제가 왜 발생하는지 알아보자.

1. props.children이란 ?
2. JSX와 React Element
3. 부모 컴포넌트 렌더링시 자식 컴포넌트가 렌더링 안되는 이유.
4. 부모 컴포넌트 렌더링시 자식 컴포넌트가 렌더링 되는 이유.
5. render function으로 전달했을 때 렌더링 되는 이유.
6. 부모 컴포넌트 렌더링시 자식 컴포넌트도 렌더링되어 useMemo로 최적화 했지만 그럼에도 렌더링 되는 이유.

## props.children이란

`props.children`이라는 특수한 prop을 사용해 자식 컴포넌트나 요소들을 부모 컴포넌트에 전달할 수 있다. 즉 부모 컴포넌트와 자식 컴포넌트(요소) 사이에 포함관계를 설정할 수 있다. 부모 - 자식 관계가 설정되면 부모 컴포넌트에서 `props.children`으로 자식 컴포넌트에 대한 정보에 접근할 수 있다.

즉 `props.children`을 통해 요소 또는 컴포넌트를 합성해서 사용할 수 있고, 어떠한 요소나, 복잡한 컴포넌트가 와도 상관이 없어서 매우 유연하다는 특징이 있다. 따라서 애플리케이션의 여러 부분에서 코드의 재사용성을 향상할 수 있고 모듈화된 코드를 작성할 수 있다.

> props가 동일하다면 리 렌더링이 일어나지 않는다.

```tsx
    <Parent>
        <Child>
    </Parent>
```

## JSX와 React Element

JSX란 JavaScript에 XML을 추가하여 확장한 문법이다. HTML에 태그를 작성하듯 사용할 수 있도록 도와준다. Babel은 JSX를 `React.Element(type, props, children)` 메서드로 호출해 컴파일하고 `React Element`를 생성한다.

`React Element`는 일반 객체면서도 불변성을 가진다. React Element를 생성한 이후에는 해당 element의 자식이나 속성을 변경할 수 없다. 즉 Re-rendering이 된다는 건 `React Element`를 새롭게 만든다고 할 수 있다.

## 근본적인 문제 찾기.

사전지식을 습득했으니 이제 위에 설명했던 렌더링 문제를 설명할 수 있다. 부모 컴포넌트 렌더링 시 자식 컴포넌트가 렌더링 안되는 이유를 찾아보자. 다음은 버튼을 누르면 상태가 변경되어 렌더링을 일으킨 코드다.

```tsx
export default function App() {
  return (
    <Parent>
      <Child />
    </Parent>
  )
}

function Parent(props: PropsWithChildren) {
  const [isToggle, setIsToggle] = useState(false)
  const handleToggle = () => setIsToggle((prevState) => !prevState)
  console.log("Parent Rendering")
  return (
    <>
      {props.children}
      <button onClick={handleToggle}>Click Me</button>
    </>
  )
}

function Child() {
  console.log("Child Rendering")
  return <div>Child</div>
}
```

실행결과
![실행결과](/posts/react/children/result.png)

위에 예제는 Child 컴포넌트가 렌더링 트리거되지 않는 문제다. 실행 결과를 보면 `Parent Rendering`이 콘솔에 여러 번 찍히는 것을 볼 수 있다. 흔히들 상태 변경이 되면 상태가 일어난 컴포넌트부터 하위 컴포넌트까지 렌더링이 트리거 된다고 알고 있지만, 이 예제에서는 그렇지 않다.

`props.children`은 `React Element`를 생성하고 불변성 객체라고 말했다. App 컴포넌트가 렌더링 될 때 Child 객체가 만들어진다. 객체의 생성 시점은 App 컴포넌트라는 것이다. 객체를 만든 시점은 App이지만 렌더링은 Parent에서 트리거된다는 것이다. 따라서 Parent 컴포넌트가 트리거 되어도 Child 컴포넌트는 동일한 props이기 때문에 리 렌더링이 트리거 되지 않는다. 즉 Child 컴포넌트가 렌더링이 되려면 Child의 생성 시점인 App에서 렌더링이 트리거 돼야 한다는 것이다.

이것을 실행 컨텍스트 관점으로 생각해보자. 여기에서는 전역 실행 컨텍스트와 App 컴포넌트는 제외하겠다.

1. [ Parent 컴포넌트 ] 함수 호출
2. [ Parent 컴포넌트 ] [ Child 컴포넌트 ] 함수 호출
3. [ Parent 컴포넌트 ] [ Child 컴포넌트 ] 함수 반환
4. [ Parent 컴포넌트 ]
5. [ ]

실행 컨텍스트로 보면 위와 같다. 먼저 호출 단계를 봐보자. Parent 컴포넌트가 호출하고 스택에 쌓인다. 그런 다음 Child 컴포넌트를 호출하면서 스택에 쌓인다. Child 컴포넌트를 호출한다는건 아직 값을 반환하기 전이다. 즉 렌더링 전 단계이다. 이제 렌더링 완료 단계를 봐보자. Child 컴포넌트가 반환되어 스택에서 제거되고, Parent 컴포넌트가 반환되어 스택에서 제거된다. 여기서 중요한건 Child 컴포넌트가 반환된 값은 props가 동일한 객체라서 리 렌더링이 트리거 되진 않는다. 렌더링 자체는 Parent에서 할 뿐이다.

이제 render function을 사용했을 때 리 렌더링이 되는 경우를 봐보자. 코드는 다음과 같다.

```tsx
export default function App() {
  return <Parent>{() => <Child text="hello" />}</Parent>
}

function Parent(props: { children: () => React.ReactNode }) {
  const [isToggle, setIsToggle] = useState(false)
  const handleToggle = () => setIsToggle((prevState) => !prevState)
  console.log("Parent Rendering")

  return (
    <>
      {props.children()}
      <button onClick={handleToggle}>Click Me</button>
    </>
  )
}

function Child({ text }: { text: string }) {
  console.log("Child Rendering")
  return <div>{text}</div>
}
```

객체가 생성되는 시점은 App 컴포넌트이고 props.children을 함수로 전달한 케이스다. 이 예제에서는 Parent에 상태가 변경되었을 때 Child 컴포넌트가 리 렌더링이 트리거 된다. 리 렌더링이 트리거 되는 이유는 props.children에서 함수로 호출하기 때문에 그렇다. 즉 함수는 객체타입이다. 함수를 호출할 때마다 다른 참조 값이기에 props가 다르다고 인식해 리 렌더링이 트리거 되는 것이다. 이건 리액트가 아니라 자바스크립트의 개념이다. 따라서 원시타입과 객체타입에 대해 알아야 할 필요가 있다.

마지막으로 React.memo를 사용해 최적화했을 때 적용 안 되는 이유에 대해서 알아보자. 이러한 경우는 다음 코드와 같다.

```tsx
export default function App() {
  const [isToggle, setIsToggle] = useState(false)
  const handleToggle = () => setIsToggle((prevState) => !prevState)
  console.log("App")
  return (
    <>
      <ParentMemo>
        <Child />
      </ParentMemo>
      <button onClick={handleToggle}>Click Me</button>
    </>
  )
}

const ParentMemo = React.memo(Parent)

function Parent(props: PropsWithChildren) {
  console.log("Parent Rendering")
  return <div>{props.children}</div>
}

function Child() {
  console.log("Child Rendering")
  return <div>Child</div>
}
```

실행결과
![실행결과](/posts/react/children/result2.png)

위 코드는 App에서 버튼을 클릭하면 상태가 변화하기 때문에 리 렌더링이 발생한다. 하지만 `React.memo`를 사용했음에도 여전히 하위 컴포넌트에서는 리 렌더링이 발생한다. 이것도 쉽게 답을 찾을 수 있다. 우리는 JSX를 통해 새로운 `React Element`를 만든다는 것을 알고 있다. 즉 App 컴포넌트가 리 렌더링 되면서 `props.children`을 새로운 객체로 만든다. 따라서 `React.memo`는 새로운 props라고 인식하기 때문에 리 렌더링이 일어나는 것이다.

> 여기서 `React.memo`란 컴포넌트를 Memoization 해서 props가 변경되지 않았다면 리 렌더링 방지하는 것을 말한다.

여기서 한 가지 중요한 건 `props.children`은 컴포넌트 props의 children이라는 속성으로 전달해도 똑같이 동작한다. 즉 다음과 같다는 말이다.

```tsx
<Parent children={<Child />} />
```

```tsx
<Parent>
    <Child>
</Parent>
```

## 결론

props.children에 렌더링은 부모 컴포넌트에서 한다. 하지만 props.children 자체는 부모 컴포넌트를 호출한 컴포넌트에서 객체를 생성하기 때문에 이러한 문제가 발생했다. 또한 render function같은 경우엔 함수를 사용했기 때문에 반환된 값은 같은 객체여도 함수로 인해 참조값이 달라져 리 렌더링이 트리거 되는 이유다. 이제 어느 정도 이해를 했다면 props.children을 통해 렌더링 최적화도 해보면 좋을 것 같고 추가로 react-router-dom에서 사용하는 패턴인 `Render Props Pattern`도 알아보면 좋을 것 같다.

마지막으로 이러한 의도치않은 렌더링 문제로 인해 useCallback이나 useMemo를 사용하는 경우가 있는데 렌더링이 된다고 무작정 Memoization 사용하는 것보단 최소한 "왜 렌더링이 되는가"에 대해서 생각해보면 좋을 것 같다.

## Reference

- [children props에 대한 고찰](https://velog.io/@2ast/React-children-prop%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0feat.-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%B5%9C%EC%A0%81%ED%99%94#reactmemo%EB%A5%BC-%EB%AC%B4%ED%9A%A8%ED%99%94%ED%95%98%EB%8A%94-children-prop)
- [The mystery of React Element, children, parents and re-renders](https://www.developerway.com/posts/react-elements-children-parents)


props.children을 사용할 때 렌더링 문제를 겪었던 적이 있나요?

props.children 깊게 공부하기


<a href="https://kr.freepik.com/free-vector/3d-hyogwawa-junglyeog-gihahagjeog-dohyeong_5229952.htm#fromView=search&page=1&position=47&uuid=5ac311bc-708e-41ec-88bf-fc5f67745a0e">
  작가 pikisuperstar 출처 Freepik
</a>

**이 글을 읽으면 배울 수 있는 것**

- React에서 렌더링의 의미
- React가 컴포넌트를 언제, 왜 렌더링 하는지
- 화면에 컴포넌트를 표시하는 단계
- 렌더링이 항상 DOM 업데이트를 하지 않는 이유

---

## 렌더링 프로세스

React에서 렌더링이란 컴포넌트가 props와 state를 통해 UI를 어떻게 구성할지 컴포넌트에게 요청하는 작업을 말한다. 일반적으로 말하는 렌더링은, 화면에 바로 나타나는 것처럼 표현되고, React에서는 화면에 나타내기전 어떤 과정을 시작하는 듯한 어조이다. 따라서, 주의해야 할 점은 React에서 렌더링은 DOM 업데이트가 아니다. 즉, **렌더링은 실질적 화면 업데이트가 아니라는 점**이다.

[React가 컴포넌트를 화면에 표시하는 과정](https://ko.react.dev/learn/render-and-commit)은 총 3단계가 있다.

1. Rendering Trigger
2. Component Rendering
3. 리액트가 DOM에 Commit

### Rendering Trigger

Trigger가 되는 조건은 컴포넌트의 state가 `Object.is()` 메서드를 사용해 state 값이 불변을 지켜 변경되었을 때다. state가 변경이되면 리 렌더링이 일어나는데, 리 렌더링은 상태 값에 의존해 새로운 데이터로 새로운 화면을 그린다. 따라서 React가 데이터가 변경되었다는 것을 알아야 하며 그 과정이 Trigger 과정이다. 반드시 상태 값을 Set 함수로 업데이트해야 하는 이유다. React가 렌더링 될 것인지 되지 않을 것인지 판단하기 위해서다.

다음은 컴포넌트가 리렌더링 되는 조건이다.

- 부모 컴포넌트가 리렌더링 되었을 때
- state 값이 변경되었을 때
- context API의 state 변경되었을 때

set State의 함수는 Queue에 순차적으로 등록된다. 이 과정은 Rendering 과정에서 다시 활용된다.

### Component Rendering

렌더링을 Trigger 한 후 React는 컴포넌트를 호출하여 화면에 표시할 내용을 파악한다. 이 단계에서 Reconciliation(재조정)이 일어난다.

- 초기 렌더링에서 React는 루트 컴포넌트를 호출한다.
- 이후 렌더링에서 React는 state 업데이트가 일어나 렌더링을 Trigger 한 컴포넌트를 호출한다.

#### Reconciliation

Reconciliation(재조정)이란 렌더링 프로세스에서 컴포넌트를 실행해 앞으로 그려질 DOM과 그려지기 전 DOM을 비교해 달라진 부분을 찾아 변경이 필요한 컴포넌트를 체크하는 단계다. 여기서 사용하는 알고리즘이 diffing 알고리즘이다.
다음과 같이 세 가지 중 하나라도 변경된 것이 있으면 변경이 필요한 컴포넌트로 체크해둔다.

- type
- props
- key

처음 렌더링할 경우 React는 가상 DOM을 그려놓는다. 그리고 Trigger가 발생하면, 새롭게 가상 DOM을 그린다. 그리고 Diffing 알고리즘을 통해 위 과정을 거쳐 어떤 부분을 업데이트할지 결정하는 것이다. 왜 이런 과정을 거칠까? 굳이 리 렌더링 되지 않아도 되는 부분은 제외하고 변경되어야 하는 부분만 변경하기 위해서이다. 즉, 효율성을 위함이다.

web 혹은 native 환경에서의 DOM 조작은 비용이 비싸다. 하지만, 가상 DOM을 비교하거나 조작하는 일은 실제 DOM을 조작하는 것에 비해 가격이 저렴하다. 가상 DOM은 JavaScript로 조작할 수 있는 가벼운 메모리이기 때문이다. 또한, 모든 DOM을 새로 그리게 될 경우 focus가 없어질 수 있고, select 요소에서 선택했던 option 값이 사라졌을 수도 있으며 스크롤 정보도 없어질 수 있다.

#### Batching

Batching(일괄 처리)은 리액트가 더 나은 성능울 위해 여러 상태 업데이트를 단일 리 렌더링으로 그룹화하는 것을 말한다. Trigger 단계에서 set State의 함수는 Queue에 순차적으로 들어간다고 했다. 이제 Diffing 알고리즘으로 어떤 DOM이 변경되어야 하는지 알았기 때문에, 변경되어야 할 DOM의 state 값을 Queue에 들어갔던 함수를 실행하면서 계산한다.

브라우저의 렌더링은 reflow와 repaint 과정의 비용이 비싸다. 하지만 리액트는 Batching을 통해서 단일 리랜더링으로 그룹화했기 때문에 state가 업데이트될 때마다 리랜더링이 되지 않는다는 성능적 이점이 있다. 즉 단일 리 렌더링으로 그룹화했기 때문에 reflow, repaint를 한 번만 일어나도록 했다.

React 18 버전부터는 Promise, setTimeout, EventHandler 등도 함께 일괄 처리된다. [Automatic batching for fewer renders in React 18](https://github.com/reactwg/react-18/discussions/21)에서 확인할 수 있다. 이 과정을 통해 리렌더링은 setState가 호출될 때마다 실행되는 것이 아니라, 마지막에 한번만 실행 되도록 했다.

### Commit

커밋 단계를 거쳐서 DOM을 업데이트하고 나면, React는 요청된 DOM 노드와 컴포넌트 인스턴스를 가리키도록 모든 변경사항들을 업데이트한다. 그리고나서 componentDidMount 와 componentDidUpdate 클래스 생명주기 메소드 또는 useLayoutEffect 훅을 동기적으로 실행한다. 여기서도 DOM에 마운트 된다는 뜻이지 paint 된다는 뜻이 아니다. 이 단계는 항상 일관적 화면 업데이트를 위해 동기적으로 실행된다. 동기적으로 실행된다는 것은 콜 스택을 비우지 않고, DOM 조작을 Batching 처리 한다는 뜻이다. Commit 단계가 끝나면 브라우저의 렌더링이 발생한다.

여기서 알 수 있는 중요한 사실은 리액트의 렌더링이 일어난다고 해서 무조건 DOM 업데이트가 일어나는 것은 아니라는 것이다. 렌더링을 수행했으나 커밋 단계까지 갈 필요가 없다면, 즉 변경 사항을 계산했는데 아무런 변경 사항이 감지되지 않는다면 이 커밋 단계는 생략될 수 있다. 리액트의 렌더링은 꼭 가시적인 변경이 일어나지 않아도 발생할 수 있다.

React가 상태를 기반으로 효율적으로 화면을 그려내기 위한 동작은 아래와 같다.

- setState의 Object.is() 메서드로 상태 값 비교
- Reconciliation의 가상 DOM으로 부분 리렌더링
- Batching(일괄 처리)를 통해 여러 번이 아닌 한 번만 리렌더링

## Reference

- [React 렌더링과정으로 알아보는 선언적이라는 의미](https://pozafly.github.io/react/declarative-meaning-of-react-rendering-process/)
- [리액트 렌더링 동작의 (거의) 완벽한 가이드](https://velog.io/@arthur/%EB%B2%88%EC%97%AD-%EB%A6%AC%EC%95%A1%ED%8A%B8-%EB%A0%8C%EB%8D%94%EB%A7%81-%EB%8F%99%EC%9E%91%EC%9D%98-%EA%B1%B0%EC%9D%98-%EC%99%84%EB%B2%BD%ED%95%9C-%EA%B0%80%EC%9D%B4%EB%93%9C-A-Mostly-Complete-Guide-to-React-Rendering-Behavior#%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%ED%83%80%EC%9E%85%EA%B3%BC-%EC%9E%AC%EC%A1%B0%EC%A0%95-reconciliation)
- [React Deep Dive 도서]


당신이 알고 있는 렌더링은 무엇인가요? 이번에 제대로 공부하는 시간을 가져봅시다.

리액트 렌더링 과정에 대해 어디까지 알고 있나요?


## 울적한 나의 속마음.

짧다면 짧고 길다면 긴 6개월 부트캠프가 끝이 났다. 실감나지 않는다. 부트캠프 수료 이후 3일이 지났지만 마음이 좋지가 않다. 부트캠프라는 울타리가 있었다가 사라진게 큰 이유이지 않을까 싶고, 마지막 프로젝트때 현타가 쌔게와서 더 그런거 같기도하다. 이제는 본격적인 취준이라 더 열심히 해야하지만, 그러지 못하고 있는게 좀 싫다. ~~그래도 공부는 매일한다~~ 이런거보면 마음가짐이 중요하다고 다시한번 느끼게 된다.

## 내가 부트캠프 들어온 이유.

내가 부트캠프에 들어오게 된 이유는 크게 두가지가 있다. (부트캠프에 들어오기 전에 2년 10개월동안 퍼블리셔일을 했었다.)

1. 첫번째로는 부트캠프 들어오기 전에 몇번의 커리어 멘토링을 받았었는데 "퍼블리셔 치고는 자바스크립트를 꽤 한다. 하지만 중견 이상으로 바라본다면 조금 더 공부가 필요하다"라는 얘기를 들었었고, 부트캠프를 다녀보는것도 좋다고 말해주셨다.
2. 두번째로는 부트캠프 출신의 개발 블로그들을 보면 생각보다 잘하는 사람이 너무 많았다. (넘사벽이다) 그래서 기대가 엄청나게 컸다. 나는 물어보는것을 굉장히 잘하기 때문에 부트캠프에 가면 잘하는 사람들한테 많이 배울 것을 기대했다.

정리를 하자면, 인생 한번 사는거 이왕이면 공부를 더 해서 좋은곳을 가자라는 마인드로 부트캠프에 들어왔다.

## 내가 부트캠프에서 느낀 것.

나는 6개월이라는 시간이 길다고 생각한다. 시간이 길다고 생각해서 그런지 모르겠지만 "내가 정말 열심히 했나" 라는 의문은 든다. 퍼블리셔를 하면서 2년여간 강의를 보면서 공부를 쭉 해왔기에 어느정도 사전지식도 있었다. 배운건 분명 있지만 내가 원하는 목표에 가려면 한참 부족하다고 생각한다. 항상 그렇듯 끝나고 나면 후회를 한다.

### 초심의 중요성.

당연한 말이고 가장 지키기 어려운게 "**초심을 잃지말자**" 라는 말인것 같다. 모든사람이 그렇듯 처음엔 열심히 하다가 시간이 지나면서 여유를 부리게되고, "**이정도 공부했으면 이제 놀아도 돼**" 라는 생각이 머릿속을 지배한다. 코드잇에서는 부트캠프 수강생들을 스프린터라고 부른다. 지금와서 생각해보면 내가 했던건 스프린트가 아니였다. 한달에 31만원씩 돈을 받으면서 공부를 하는 유일한 시기였는데 스스로에게 실망을 많이 했다.

### 소통의 중요성.

3번의 프로젝트들을 하면서 소통의 중요성을 깨달은건 바로 파트3인 두번째 프로젝트였다. 잘한다라는 사람들만 모아놓은 팀이였기에 나는 많은 기대를 했었다. 각자의 능력치는 좋아서 처음 사용하는 기술 스택을 적용해도 별 문제는 없었지만 프로젝트 자체가 팀 실력에 비해 많이 아쉬웠다. 개발을 잘하는거랑 상관없이 서로 "**어디까지 작업이 되어있는지**", "**어디를 어떻게 개선하면 좋을지**", "**어떤 문제가 발생했는데 어떻게 해결을 해야할지**" 등등 소통을 안했던것이 너무 컸다. 그래서 프로젝트 발표날 3일 이전까지 위워크에서 팀원들과 밤을 샜다. 이 때는 많이 늦었지만 소통하면서 같이 작업하니 재밌었고 잘 마무리했다. 전 팀에서는 코어타임을 안가져도 알아서 디스코드 대화방으로 모여서 새벽까지 재밌게 코딩을 했던 기억이 있어서 이번에도 필요없을 줄 알았는데 그게 아니였다. 소통이 얼마나 중요한지 많이 깨닫게 된 두번째 프로젝트 였다.

### 검수와 일정의 중요성.

마지막 프로젝트에서는 검수와 일정의 중요성을 많이 느꼈다. 일정이 한번 지켜지지 않으면 와르르 무너진다는것도 이번에 깨달았다. 물론 머리로는 알았지만 디테일한 작업들은 예상보다 오래걸린다라는것도 이번에야 깨달았다. 또 이렇게 일정이 어긋나니 검수할 시간이 부족해졌다. 우리 프로젝트에서는 사용자가 어플리케이션에 잘 적응할 수 있도록 단계별로 작성해야하는 온보딩 페이지가 있는데 여기에 페이지 전환 애니메이션으로 힘을 줬지만, 프로덕션 모드에서는 적용이 안되는 문제가 있었다.
애초에 발표 5시간전에 배포를한게 문제였지만 그 전에 일정이 어긋나다보니 모든게 미뤄지는 현상이 문제였다. Next에서 Framer Motion의 일부 기능이 프로덕션 모드에서는 안된다라는 깃헙 이슈를 발견했지만 너무 늦게 발견했고, 이미 이것을 고치려고 시간투자도 많이했었다. 이 외에도 다른 자잘한 문제들이 많았다. 발표 전날에 16시간동안 작업을 했지만 디테일한 작업들을 못끝내서 아쉬움만 많이 남았다. 결과는 목표치만큼 좋지 않았지만 그래도 프로젝트를 하면서 많은것들을 배웠다.

### R&R (Roles And Responsibilities)

나는 코드잇에서 진행하는 총 파트4개 중에서 모두 팀장을 맡아서 했다. 팀은 파트마다 바뀌고 팀장도 바뀐다. 억지로 팀장을 한적은 없고, 파트가 바뀌면 먼저 내가 한다고 얘기를 했다. 그래서 R&R에 대한 나의 실패 경험을 얘기하려고 한다.

#### 파트2 R&R의 실패.

**결과는 너무나도 성공적이였고 우리팀이 가장 잘했다라는 생각과 나만 좋았다** 라는 느낌을 받았다. 이 때 나는 이기적으로 프로젝트에서 어려운 부분들, 욕심나는 부분들을 맡았다. 프로젝트 막바지에 팀원중 한 분이 "**자기도 그 기능을 하고싶었다**" 라고 얘기를 했었다.

수료식 때 그분은 그냥 한 말이라고 했지만 그 때 나는 "**내가 너무 이기적으로 했나**" 라는 생각을 많이했다. 역할을 보니 확실히 내가 한게 더 많긴했었다... 다 같이 팀으로 프로젝트를 하는건데 내가 한 방법이 결과는 좋더라도 이게 옳은 방향은 아니라고 생각했다.

#### 파트3 R&R의 실패.

위에서 얘기를 했지만, 잘한다라는 사람들만 모아놓은 팀이였고 기대를 받는 팀이기도 했지만 R&R의 실패도 소통과 비슷한 비율을 차지할정도로 문제가 컸다. 이번에는 팀원들한테 선택권을 주고 나는 남는걸 하기로 했다.

그러다보니 내가 해야할건 간단한 랜딩 페이지 하나와 프로젝트의 핵심중 작은 한 부분을 맡게되었다. 프로젝트 기간은 총 15일이였는데, 내 파트는 1주일만의 끝이 나버렸다. 할게 없었다... 그래서 팀원들한테 어렵거나, 도움이 필요한 부분있으면 말해달라고 했다. 하지만 크게 연락은 없었고, 프로젝트 발표 3일전에 위워크로 발표자료를 만들러 갔다.

하지만 거기서 문제는 터졌다. 잘되고 있던 프로젝트인줄 알았는데 잘되고 있던것이 아니였다. 기능이 되기는하는데 자잘한 버그가 굉장히 많았다. 이 때 정말 위워크에서 밤새서 작업하고 집이 멀어 찜질방에서 5시간자고 다시와서 작업을 했었다. 여기서 책임감 강한 팀원 한 분이랑 얘기를 했던게 **"어렵거나 핵심인 부분들을 우리가 맡았어야했다"** 라는 얘기를 들었다.

이 때는 그래도 소통의 문제였겠지 싶었다. 그렇게 3일동안 모든걸 다 고치고 나름 잘한 프로젝트로 끝이났고 지금 생각해보면 내가 맡은게 너무 없었던 R&R의 문제라고 생각한다. 그리고 팀원들 말만 들을게 아니라 내가 직접 확인 해봐야한다. (그 때 당시에 멘토님은 R&R에 있어 이기적으로 하라고 했었다.)

#### 파트4 R&R의 실패.

마지막 프로젝트에서는 소통은 열심히 했다. 전에는 R&R 문제는 아니라고 생각을 했기 때문에 이번에도 마찬가지로 팀원들한테 먼저 선택권을 주었다. 마찬가지로 내가 맡은부분은 크게 어려운게 없었다. 이것 역시 1주일만에 끝이 나버렸고, 중간에 팀원들이 도와달라고 얘길해줘서 같이 해결도 하고 붕뜨는 시간이 아까워서 지금 보고있는 이 블로그를 만들고있었다.

하지만 그 이후에 정해진 일정이 맞춰지지 않다보니 한번 더 얘기를 했었다. 저번처럼 실수하지 않으려고 팀원들한테 테스트 및 특정기능 잘되는지 얘기도 하고 확인도 받았다. 그렇게 시간은 지나면서 미처 생각지못한 페이지가 아에 만들어지지 않은것을 뒤늦게 알아버렸다.. 담당 팀원한테 얘기를 했지만 팀원도 깜빡잊었다고 얘기를 했었다. 내가 작업한다고 얘기하고, 생각보다 페이지 작업 시간이 꽤 걸려 팀원들한테 요청을해서 빠르게 끝을 냈지만 이 때는 이미 너무 늦은 시기였다.

16시간을 투자했지만 크게 나아진건 없었고 더미 데이터도 없었다. 발표 순서가 첫번째라서 더 작업을 해보려고 했지만, 결국 문제가 많은 프로젝트를 가지고 발표를 하고 끝을 내게되었다.

#### 왜 R&R이 잘못되었다라고 생각하는가?

다른 팀들의 프로젝트 발표들을 보면서 많이 느꼈던것이 굉장히 잘했던 팀들이 몇몇 있었다. 정말 잘했다. 그런걸 보니 내 프로젝트가 너무 초라한것같아서 현타가 엄청쌔게 왔다. 내가 이 블로그를 만드는게 문제였다 라는생각이 엄청 들었다. 할게 없었으면 팀원이 **어떤 기능을 빼먹은건 없는지**, **기능이 잘 돌아가는지** 확인을 했어야 했다.

이건 내가 잘못한게 맞다. 여태껏 그랬듯 파트2를 제외하고나서는 팀원들의 얘기만 듣고 내가 따로 확인을 해본적은 없었다. 확인을 하더라도 뒤늦게 했다. 잘한 팀들을 보면 누구 한명이 다른 팀원들에 비해 커밋이 압도적이게 높았다. 내가 너무 이상적으로 생각을 했던건지 무엇인지 아직 정답을 찾지 못했다.

글을쓰는 지금 나의 문제는 팀원들이 알아서 잘 해주겠지 라는 안일한 생각이 컸던것 같다. 팀원들이 못했다는게 아니라 나도 같이 검수를 해야했다. 중간점검 같은 형태로 했으면 더 좋았을 것 같다.

그리고 같이 공부하면서 어려운걸 극복하는 스프린터인데 실력을 따져서 **누구는 못하니까 쉬운거 하고, 누구는 잘하니까 어려운거 하라는 식**은 아니라고도 생각한다. 같이 주도적으로 하자는 마인드였었는데 세번의 실패를 한거보면 R&R의 문제도 크다고 생각한다.

### "팀장이 참 어렵구나..""

나를 만난 팀원들도 많이 답답했을것 같고 미안한 감정도 든다. "팀장 역할을 잘해줬다"라고 얘기하는 팀원들이 고마웠다. 돌아보면 모든 이유는 팀장인 내가 못해서라는 생각도 많이 든다. **팀장 참 어렵다...** 그래도 좋은 경험을 했지만 아쉬움이 많이 남는다. 그렇지만 나중에 어떤 곳이든 팀장과 비슷한 책임감 있는 역할을 맡게된다면 전보다 더 잘 할 자신감이 생겼다.

### "그래도 나 많이 배웠어🙂"

나는 `JavaScript`, `React`, `TypeScript`를 어느정도 다룰줄 알았던 상태에서 부트캠프 과정에 참여했다. 기술 스택으로 보면 별로 배운게 없지만 "**어떻게 해야 더 잘 활용할 수 있을까**"에 대한 고민을 많이 했었다. 늘 해왔던 방식대로 코드를 짜면 이건 숙련도가 높아지는거지 공부를한건 아니라고 생각을 한다. 별거 아닌거여도 생각을 먼저 해야 좋은 아키텍쳐와 코드가 나온다라고 생각을 한다. 의도적인 연습들을 하다보니 내가 성능적인 부분도 챙길 수 있었던 것 같다. (렌더링 성능 최적화, 재사용성에 대한 고민, FCP, LCP, CLS, 초기 로딩속도 개선 등등) 기술 스택적으로 보면 배운건 Next와 Tanstack Query밖에 없지만, 배움의 깊이를 보면 마리아나 해구를 향해가고 있다

### 마지막 한마디.

이런 기회를 얻을 수 있는 부트캠프라서 너무 만족한다. 내가 부트캠프를 가기 전에는 부정적으로 평가했는데 모든건 본인 하기 나름이다. 부트캠프에서 세번의 프로젝트를 하면서 정말 많은것들을 배웠다. 사실 프로젝트가 아니더라도 다른사람들의 얘기를 들으면서도 많이 배운다. 다양한 사람이 있는 만큼 다양한 관점으로 바라보니 너무 좋았다. 나랑 같은 팀이였던 팀원분들, 4기분들 모두 잘되어서 나중에 현업에서 만나면 좋겠습니다 🙂


짧다면 짧고 길다면 긴 6개월 부트캠프.. 내가 생각했던 것과 다르게 끝이났고 실감이 나지 않는다. "안녕 코드잇"

안녕 코드잇


## 안녕하세요 🎉

앞으로 FrontEnd 개발자가 될 **이동현** 이라고 합니다 👏👏👏  
최근에 다른사람들의 이력서를 보면서 현타가 쌔게 왔었고, **근거 기반**으로 작성하는 이력서들을 많이 봤어요.  
그런분들의 특징이 다 개발 블로그를 운영하고 있다는 거였습니다. (대단한 사람들이에요...)

"이러면 안되겠다" 싶어서 나만의 강점인 인터랙션을 살려서 블로그를 만들자는 기획을 하게 되었습니다. 이 블로그를 만들면서 컨셉은 **미술관을 연상케하는 고급진 갤러리 형태**가 컨셉이였습니다. 뭐든 그렇지만 항상 표현에 있어 전달력이 가장 어려운것 같아요.

그리고 개발적으로 좋은 아티클이 많이있는 [미디엄](https://medium.com/, "google link")을 참고해 만들었어요. 디자인 같은 경우에는 grid layout 이라고 검색을해서 선으로 이루어진 디자인으로 한번 해봤습니다. (예전에 웹 디자인 트렌드였어요.)

이미지가 이상하게 보일텐데, 그 이유는 Three.JS를 사용해 이미지가 왜곡되게 해보았습니다.  
좀 많이 꿀렁거리죠? 속이 조금 안좋아지는것같기도 합니다. 그래서 인터랙션에 대해서는 고민입니다..😂 추후에 변경될 가능성이 있을것 같네요.

## 블로그를 만든 이유 🚀

- 👋 Next JS를 배우면 블로그를 만들 수 있다라는 내용을 본적이 있었고, **내 손으로 직접 만들고 싶었어요.**
- 🎨 다른 블로그를 사용해본적 있었지만 **나의 색깔이 나타나지 않았어요.** (저는 디자인을 중요시합니다.)
- 🤔 만드는 방법은 구글에 검색하면 잘 나와있지만 **어떻게 만들어지는지 과정이 궁금했어요.**
- 👍 <b>"잘 만든다면 이것도 포트폴리오가 되지 않을까"</b> 라고 생각했어요.

이유는 이정도가 될것 같고, 가장 중요한건 "**나의 색깔이 나타나지 않았다**" 라는게 컸던것 같습니다.
앞으로 TIL(Today I learned)과 남들이 포스팅 하지 않는 글들을 적어보려고 합니다.

~~> ❗️ 현재는 TOC(Table of Contents)기능이 없어요. 곧 만들어질 예정이랍니다.~~

앞으로 어마어마하게 성장할 계획(?)이에요. 그러니 즐겨찾기나 Github에서 Star를 눌러주시면 따끈따끈한 신상 포스트들을 볼 수 가 있습니다. 이 사이트가 어떻게 만들어진지 궁금하다면 `Github` 가셔서 `Fork`를 뜨셔도 좋아요 :) 궁금한것이 있다면 댓글을 남겨주시면 관련내용을 업데이트 해보도록 하겠습니다.


최근에 이력서 레퍼런스를 찾아보다가, 포트폴리오겸 나의 강점을 살린 인터랙션으로 블로그를 만들면 어떨까? 하면서 만들어봤어요. 이건 실제 서비스가 아니니 내 마음대로 해도 괜찮잖아요!?

D5ng