부족한 개발지식과 면접에 대한 부담감

처음 몇번의 면접을 탈락할 때에는 내가 기술적으로 많이 부족하다고 느꼈다. 면접에 떨어진 이유는 내가 면접질문에 대해 명확히 답하지 못했거나, 오답을 말했기 때문에 떨어졌다고 생각했다. 그렇기 때문에 예상질문을 준비하고 답변을 외웠다. 접속사 하나, 조사 하나까지 모두 외웠지만 실제 면접에서는 항상 예상하지 못한 문제들이 나왔고, 예상치 못한 문제를 맞닥뜨릴때면 머릿속이 하얘졌다. 그렇게 면접을 탈락할 때 마다 더 많은 질문과 답변을 외웠다. 흔히들 면접은 소개팅과 같다고 하지만, 내게 면접은 그저 취업을 위한 주관식 문제였다. 그것도 정답을 알려주지 않는.

ChatGPT(Monday): "와. 너 진짜 AI같다."

이랬던 나를 바꿔준건 아이러니하게도 AI였다. 나는 평소 AI와 모의면접을 자주 진행했었다. 아마 나랑 가장 많은 이야기를 나눈 대화상대이지 않을까 싶다. 그러던 중 가볍게 '먼데이' 라는 AI 모델과 모의면접을 하는데, 먼데이가 지겹게 하던 말이 있었다. "와 너 진짜 AI 같다. 그 정제된 말투, 감정 0%" 처음에는 그냥 퉁명스럽게 말하나보다 싶었다. 그러나 가끔 머리를 비우고 대충 답변할 때 마다 이제야 감정이 생겼다며 비꼬는 먼데이를 보고, 그동안 내 답변 방식에 문제가 있었던 건 아닐까 싶었다. 밑져야 본전으로, AI에게 감정을 배워 대본을 외우지 않고 누군가에게 설명하듯 모의면접에 임했다. 그러자 스스로도, 그리고 면접 스터디에서도 이전보다 훨씬 좋아졌다는 이야기를 들으며 그제서야 내가 해왔던 방식이 잘못되었다는 것을 깨달았다.

더욱 신기한 것은 그제서야 암기과목 같았던 이론들이 컴퓨터 기술의 설명서처럼 느껴졌다. 클로저란 무엇인가요? 라는 질문이 <클로저의 정의를 쓰시오> 라는 문제가 아니라, "클로저가 뭐에요?" 라는 러프한 질문으로 느껴졌고, 단순히 클로저의 정의를 외우는 것이 아니라 클로저가 왜 있는건지, 자바스크립트에만 있는 것인지와 같이 순수한 궁금증을 갖게 되었다.

후후... 그 녀석은 우리중 최약체였지

이제는 왠만한 기술질문은 마스터했다고 느꼈다. 서류만 붙어봐라, 기술면접 만점으로 당당히 면접장을 나서리라. 그러나 지금까지 들었던 질문들은 2차 질문을 시작하기 전 가벼운 인사였다는 것을 알게 되었다. "컴포넌트 명이 다르고 키가 같으면 리액트는 같은 컴포넌트로 인식하나요?", "useCallback은 어떻게 리렌더링을 방지하는 건가요?" 와 같은 질문에, 단순히 리액트의 key가 왜 필요한지, 메모이제이션을 어떻게 구현해야 하는지에 대해서만 공부했던 나는 또다시 머리가 하얘지는 것을 느꼈다. 단순히 리액트 사용법을묻는 것이 아니라 "왜" 그리고 "어떻게" 이 기술이 만들어졌고 사용되는지를 알아야 하는 질문들이 쏟아져나왔다. "이런것까지 어떻게 알아!" 라고 울부짖고 싶지만 아쉬운건 언제나 나였고, 어떻게든 해야만 했다.

내가 선택한 방식은 포스팅이었다. 제대로 답변하지 못했던 기술질문을 딥다이브 하면서 꼬리에 꼬리를 무는 궁금증들을 찾아보고 정리했다. 가볍게 쓰려던 포스팅도, "왜 이게 꼭 필요한거지?", "이거 정말 맞는 말이야?"와 같은 궁금증을 낳았고, 하나씩 해결하다보니 포스팅 하나를 쓰는데 3일이 걸리기도 했다. 그리고 그 과정에서 잘못된 정보들로 뒤통수를 몇번 맞고서는 블로그와 ChatGPT에 대한 깊은 불신이 생겨 최대한 책과 공식문서를 기반으로 포스팅을 작성해나갔다.

기술만 잘 알면 되는 줄 알았지...

그럼 이제 합격만 남았을까? 익숙한 클리셰답게 세상은 역시나 호락호락하지 않았다. 힘겹게 서류전형을 뚫고 나니, 연달아 기술질문은 묻지 않는 면접을 하게 되었다. 이전 회사에서의 경력을 집중적으로 묻는 면접, 어떤 개발이 해왔는지를 묻는 면접 등 내가 어떤 사람인지 보여주는 경험질문 위주의 면접을 보게 되었고, 결과는 전부 불합이었다.

예상했던 해결방안으로 문제가 해결되지 않으면, 다른 원인을 찾고 그에 맞는 해결방안을 적용한다. 나는 개발에서도, 현실에서도 문제를 해결하기 위해 항상 이 흐름대로 문제를 해결해왔다. 하지만 스스로 찾아왔던 원인과 해결방안으로는 더이상 문제가 해결되지 않았고, 이를 해결하기 위해 현업자의 힘을 빌렸다.

유료 모의면접 멘토링을 받기도 했었고, 면접 과정에서 "혹시 제가 떨어지게 된다면 어떤 이유일까요?" 라고 직접적으로 묻기도 했으며, 아예 탈락한 면접에 대해서 피드백을 부탁드리는 메일을 보내기도 했다. 피드백은 정말 다양했으며, 아래 내용은 조금 각색해서 작성했다.

• 이번 채용에서는 대규모 서비스를 경험한 개발자를 찾고 있기 때문에 모시기 어렵게 됐습니다.
• 답변을 할 때 자신감을 갖고 답변하시면 좋을 것 같습니다. 맞고 틀리고는 면접관이 결정할 문제입니다. 자신감이 부족해보여요.
• 경력 과정에서 이룬 기술적 성취가 잘 드러나지 않았습니다. 이를 드러내기 위해 경험한 문제와 이를 해결한 방식에 대해 자세히 설명해주시면 좋을 것 같습니다.

"드러내지 못했다" 라는 말이 가장 와닿았다. 결국 면접은 내가 얼마나 회사에 도움이 되는 인재인지를 어필해야한다는 것을 다시금 인지하게 됐다. 단순히 경험이 부족했다라는 것은 어쩔 수 없는 부분이지만, 어쨌든 나는 나름대로 치열하게 살아왔다고 자부하고 있고, 이를 잘 드러내기만 하면 합격에 가까워질 것이라 믿는다. 그래야만 하고.

우리는 답을 찾을 것이다. 늘 그랬듯이

개발자 시장은 얼어붙고 있고, 유례없는 한파가 지속되고 있다. 더 무서운건 오늘이 가장 따뜻한 날이라는 것이다. 하지만 그럼에도 누군가는 취업을 하고 이직을 한다. 경쟁사회의 부조리함을 외치고 싶지만, 한편으로는 나까지만 이라도 취업시켜줬으면 좋겠다. 그러기 위해서는 오늘도, 내일도, 취업을 위해 조금씩 나아가야 한다. 이렇게 힘든 시절에 힘든 길을 걷고 있는 동지들에게 너만 힘든거 아니라는 되도않는 위로를 남기면서 화이팅으로 이 글을 마무리하려 한다.

이벤트루프

Stack이 비어있을 때 Microtask Queue를 먼저 확인하고 그 안의 작업을 모두 처리합니다. 이후 Macrotask Queue에서 하나의 작업을 꺼내 Stack으로 올려 실행합니다. 이 순서를 런타임 동안 계속 반복하기 때문에 이벤트루프라고 칭합니다.

Macrotask Queue

일반적인 비동기 작업이 들어가는 큐입니다. 대표적인 예로는 setTimeout, setInterval, setImmediate(Node.js)와 같은 타이머 함수나, 브라우저의 I/O 작업이 있습니다.

Microtask Queue

우선순위가 높은 비동기 작업을 위한 큐입니다. Promise.then, catch, finally, MutationObserver, queueMicrotask 등이 해당되며, Macrotask Queue보다 우선순위가 높습니다.

📝 자바스크립트 퀴즈

console.log('A');

new Promise((resolve) => {
    console.log('B');
    resolve('C');
}).then((value) => console.log(value));

setTimeout(() => console.log('D'), 0);

Promise.resolve('E').then((res) => {
    console.log('F');
    setTimeout(console.log, 0, res);
});

console.log('G');

동작 과정을 보기 전에 먼저 풀어보세요!

동기 코드 실행 (Call Stack)

1. console.log('A') 는 동기 코드이기 때문에 Call Stack에 쌓인 후 바로 실행 됩니다.
2. Promise의 (resolve) ⇒ { … }) 함수가 Call Stack에 쌓이고 해당 함수는 동기 코드이기 때문에 바로 실행됩니다.
   1. 이때 동기코드인 console.log('B') 는 바로 실행 됩니다.
   2. resolve('C') 는 Promise 비동기 코드로, 마이크로 태스크큐에 추가됩니다.
3. setTimeout(() => console.log('D'), 0); 이 매크로 태스크큐에 추가됩니다.
4. Promise.resolve('E') 가 마이크로 태스크큐에 추가됩니다.
5. console.log('G') 는 동기 코드이기 때문에 Call Stack에 쌓인 후 바로 실행 됩니다.

비동기 코드 실행 (Microtask Queue)

1. Call Stack이 비어있기 때문에 이벤트 루프는 Microtask Queue의 resolve('C') 의 콜백인 (value) => console.log(value) 를 Call Stack에 추가하고, C를 출력합니다.
2. 이후 Microtask Queue의Promise.resolve('E') 의 콜백이 Call Stack에서 실행됩니다.
   1. console.log('F') 가 실행되어 F가 출력됩니다.
   2. 이후 setTimeout(console.log, 0, res); 가 실행되어 console.log('E') 가 매크로 태스크큐에 등록됩니다.

비동기 코드 실행 (Macrotask Queue)

1. Microtask Queue가 비었기 때문에 Macrotask Queue가 실행되어 D가 콜스택에 쌓이고 실행됩니다.
2. Call Stack에 setTimeout(console.log, 0, res) 의 콜백인 console.log('E'); 가 추가되고 E가 출력됩니다.
3. A - B - G - C - F - D - E 순으로 모든 코드가 출력됩니다.

본 코드의 동작 과정은 https://www.jsv9000.app 에서 스텝별로 자세히 확인해 볼 수 있습니다.

현재 리액트는 16버전에 도입된 Fiber 아키텍처를 기반으로 가상돔을 실제 DOM과 동기화하는 재조정(Reconciliation)과정을 진행합니다. 그리고 이 Fiber 덕분에 startTransition과 같은 업데이트 우선순위 기능을 구현 할 수 있는 것인데요. 이번 포스팅에서는 Fiber란 무엇인지, 어떻게 재조정 과정을 진행하는 것인지 살펴보겠습니다.

Fiber란?

Fiber는 React가 “어떻게 컴포넌트를 렌더링할지, 언제 DOM을 업데이트할지”를 결정하는 핵심 데이터 구조입니다. JSX으로 작성된 코드는 리액트에서 React.createElement를 통해 리액트 엘리먼트 트리로 만듭니다. 이때 리액트는 추가정보를 포함하기 위해 리액트 엘리먼트 트리를 기반으로 Fiber 트리를 만들어 내는데요. 리액트 엘리먼트를 createFiberFromTypeAndProps 함수를 통해 파이버 노드를 반환합니다. Fiber 노드에는 다양한 정보가 포함되어 있지만, 간단히 리액트 엘리먼트와의 차이를 말하자면 Fiber는 상태를 저장하고 수명이 긴 반면, 리액트는 임시적이고 상태가 없다는 점이 있습니다. 그밖의 Fiber 노드에 포함된 정보는 다음과 같습니다.

Fiber 아키텍처의 등장 배경

Fiber 아키텍처는 기존의 Stack 기반의 재조정자의 문제를 해결하기 위해 등장했습니다. 16버전 이전의 재조정자는 스택 기반의 알고리즘을 통해 재조정을 진행하였는데요. 때문에 상태변경에 대한 우선순위를 조정할 수가 없었을 뿐만 아니라, 렌더링 작업을 쪼개서 처리하는 타임 슬라이싱이 불가능했습니다. 때문에 이미지와 같은 상황에서 자동완성 리스트를 업데이트하느라 타이핑이나 스크롤이 지연되어 좋지 않은 UX가 발생할 수 있었습니다.

그리고 리액트는 이러한 문제를 해결하기 위해 2년 넘게 연구하여 React Fiber 라는 핵심 알고리즘을 만들어냅니다. React Fiber로 인해서 리액트는 점진적 렌더링(렌더링 작업 분산처리) 뿐만 아니라 다음과 같은 기능을 구현할 수 있게 됩니다.

• 작업 도중 일시 중지, 중단, 재사용 가능
• 업데이트 유형에 따라 우선순위 부여 가능(startTransition, useDeferredValue)
• 새로운 동시성(concurrency) 기능 제공

Fiber 아키텍처 기반의 재조정 과정

💡 재조정(Reconciliation)이란, 상태나 props가 변경되어 컴포넌트가 다시 렌더링될 때, 이전의 가상 DOM 트리와 새롭게 생성된 가상 DOM 트리를 비교하여 실제 DOM에 최소한의 변경만 적용하는 과정을 말합니다.

파이버 재조정 과정은 크게 렌더링 단계와 커밋 단계로 이뤄지는데요. 렌더링 단계에서는 사용자에게 보여줄 변경된 DOM을 준비하며, 커밋 단계는 준비된 DOM을 사용자에게 보여주는 것입니다. 이렇게 나눠진 단계를 바탕으로 커밋단계 이전에 언제든 렌더링 된 작업을 폐기할 수 있기 때문에 작업을 중단하거나 재사용할 수 있는 것입니다. 아래에서는 렌더링 단계와 커밋 단계를 더 자세히 설명하며 재조정 과정을 소개하겠습니다.

렌더링 단계

렌더링 단계는 현재 트리에서 상태 변경 이벤트가 발생하면 시작됩니다. 루트 파이버 노드에서부터 트리를 내려가면서 업데이트가 필요한 경우 dirty로 표시하고, 트리의 끝에 도달하면 다시 반대로 순회하면서 DOM 트리와 분리된 새로운 DOM 트리를 생성합니다. 이때 위에서 아래로 이동하는 과정을 beginWork, 아래에서 위로 이동하는 과정을 completeWork 으로 구분합니다.

beginWork

beginWork의 argument에는 현재 트리의 파이버 노드의 참조를 뜻하는 current, dirty 로 표시되어 반환되는 노드인 workInProgress, 그리고 리액트의 업데이트가 처리되는 레인(lane)을 나타내는 renderLanes가 존재하는데, renderLanes는 우선순위를 지정할 뿐 아니라 어떤 업데이트를 먼저 처리할지, 미룰지를 결정합니다.

completeWork

completeWork는 업데이트된 상태를 나타내는 실제 DOM 트리를 새롭게 생성합니다만, 아직 실제 DOM을 업데이트 하지는 않습니다. 만약 우선순위가 더 높은 업데이트가 예약되면 만들었던 UI를 버리고 높은 우선순위를 처리하게 됩니다. 그리고 이 과정이 우선순위를 부여할 수 있는 파이버 재조정자 기능의 핵심입니다.

커밋 단계

렌더링 단계가 완료되면 리액트는 commitRoot 함수를 호출하여 FiberRootNode의 포인터를 현재 트리에서 작업용 트리로 전환하고, 작업용 트리를 새로운 현재 트리로 만듭니다.

이러한 과정을 거치는 이유는 React Fiber가 렌더링 과정에서 기존 화면이 영향 받지 않도록 이중 버퍼링을 사용하기 때문입니다. 즉, React는 화면을 업데이트할 때 두 개의 트리를 번갈아 가며 사용하며, 하나는 현재 실제 화면에 적용된 트리, 그리고 하나는 렌더링 단계에서 새롭게 계산된 트리입니다.

이 시점부터는 향후 모든 업데이트는 새로운 현재 트리를 기반으로 이루어지며, 이러한 과정을 통해 Fiber 재조정자에 의한 리액트의 재조정이 이뤄지게 되는 것입니다.

참고

전문가를 위한 리액트 https://d2.naver.com/helloworld/2690975 https://github.com/acdlite/react-fiber-architecture https://ko.legacy.reactjs.org/docs/faq-internals.html#what-is-react-fiber https://youngju-js.tistory.com/76 https://github.com/facebook/react/blob/bfaeb4a46175fa0f4edf2eba58349d5029e5e86e/packages/react-reconciler/src/ReactFiber.js#L552

Axios 파헤치기

XHR과 http 기반의 Axios

먼저 Axios의 공식 홈페이지를 찾아보면 다음과 같이 나와있습니다.

Axios란?
Axios는 node.js와 브라우저를 위한 Promise 기반 HTTP 클라이언트 입니다. 그것은 동형 입니다(동일한 코드베이스로 브라우저와 node.js에서 실행할 수 있습니다). 서버 사이드에서는 네이티브 node.js의 http 모듈을 사용하고, 클라이언트(브라우저)에서는 XMLHttpRequests를 사용합니다.

이 말을 풀어서 말씀드리면, 브라우저와 node.js에서 동일한 라이브러리(코드베이스)를 사용할 수 있다는 뜻인데요. Fetch API가 등장하기 전까지 브라우저는 XMLHttpRequest(XHR), node.js에서는 http 모듈을 사용해야 했습니다. 즉, Axios는 Fetch API가 아닌 XHR 혹은 http 모듈에 기반한 라이브러리이고, 노드와 브라우저 두 환경 모두에서 사용할 수 있다는 뜻입니다.

Adapter 패턴으로 구현된 Axios

그런데 어떻게 같은 코드로 Node와 브라우저에서 동작할 수 있을까요?
Axios의 구현부를 살펴보면 adapter 방식을 사용해서 구현한 것을 볼 수 있습니다. lib/adapters에서 Axios가 요청을 어떻게 보낼지를 결정하기 때문에 각각의 환경에 맞춰 동작할 수 있는 것입니다. 브라우저, 노드뿐만 아니라 Axios v1.7부터는 Next.js에서 사용하는 fetch의 캐싱 기능을 fetch adapter를 통해서 사용할 수도 있게 되었습니다.

Axios를 사용하는 이유

Axios를 사용하는 이유에 대해서는 다양합니다. 하지만 가장 큰 이유는 API 요청을 쉽고 편하게 하기 위해서인데요. XHR 혹은 http 모듈을 사용하여 API를 요청하는 일은 Axios에 비하면 꽤나 불편하고 번거로운 일이었습니다. Fetch API가 자리잡기 전까지, 이러한 번거로움을 해결하기 위해 많은 사람들은 Axios를 사용했습니다. Fetch API는 브라우저에서는 2015년(ES6), Node.js에서는 2023년(v20)에 정식으로 도입된 비교적 최신 기술이었거든요.

Fetch API vs Axios

Fetch API가 있음에도 왜 사람들은 Axios를 사용하는 걸까요? 먼저 Fetch API의 등장배경에 대해 알아보도록 하겠습니다.

Fetch API의 등장배경

Fetch API는 ES6에서 Promise가 도입된 후 얼마 지나지 않아 등장했는데요. 기존의 복잡한 콜백을 사용해야 하는 XMLHttpRequest(XHR)과 달리, Promise에 기반한 Fetch API는 편리하게 API 요청을 구현할 수 있었습니다.
즉, Fetch API가 등장하게 된 이유는 2000년대 초반에 등장했던 오래되고 불편한 XHR을 대체하고, 앞으로의 기술 트렌드인 Promise를 사용하여 개발 생태계의 기준점을 잡으려 한 것이죠.

그런데 왜 Axios는 fetch가 아닌 XHR을 기반으로 동작할까요?

이미 예측하신 분들도 있겠지만, 최신 기술이 받아들여지기까지는 시간이 걸립니다. 현재까지도 구형 브라우저(익스플로러 등)에서는 Fetch API가 지원되지 않았고, 2015년보다 오래전에 작성되어 동작하는 코드도 매우 많습니다. 따라서 안정성을 위해 fetch가 아닌 XHR을 기반으로 동작하는 것입니다.

Fetch API가 아닌 Axios를 써야하는 이유

근데 왜 최근에 만들어진 코드에서도 Fetch API가 아닌 Axios를 쓰고 있을까요? 이 글의 초반부에서 말씀드린 것처럼, 역시나 Axios의 편의성 덕분이지 않을까 싶습니다. Response.json()와 같은 메서드를 거쳐서 응답을 다뤄야 한다던가, Response.ok를 거쳐서 에러를 반환해야 하는 작업들은 추상화된 Axios에 비하면 꽤나 번거로운 일입니다. 뿐만 아니라 XHR에서 기본적으로 지원하는 timeout이나 progress(다운로드 진행률)도 직접 구현해야 합니다.

왜 Fetch API는 사용성을 고려하지 않았나?

timeout과 같은 기능들은 흔히 사용되는 기능인데 왜 Fetch API에서는 기본적으로 지원하지 않았을까요?
이 부분은 개발자 사이에서도 뜨거운 논쟁을 일으켰습니다. 그럼에도 Fetch API가 Axios만큼의 사용성을 추가하지 않은 이유는, Fetch API의 설계 의도가 사용성보다는 확장성과 안정성에 초점이 맞춰져있기 때문입니다. 옵션을 추가하여 사용성을 향상시키고 강제하는 것보다, 사용자가 필요에 맞춰 확장하고 활용할 수 있도록 한 것입니다.

더욱이 현재의 timeout은 요청 자체를 중지하는 것이 아니라, 요청 후에 응답이 반환되고 있더라도 단순히 응답을 거부하는 방식인데요. 때문에 timeout은 아직까지 불완전한 기능으로 볼 수 있고, 아직까지 Promise에는 취소 가능한 표준이 없기 때문에 timeout이 기본적으로 지원되지 않는 것입니다. timeout 추가에 대한 Fetch API 개발자의 답변

그래서 Fetch와 Axios, 어떤 걸 사용해야 하나요?

어쩌면 이 글에서 가장 궁금했던 점이 아닐까 싶은데요. 아쉽게도 뻔하고 재미없는 답변을 드려야 할 것 같습니다.

Axios는 현재 매우 높은 사용률을 보이고 있고, 추상화뿐만이 아니라 인스턴스를 포함한 편리한 기능들을 제공하고 있습니다. 때문에 안정적인 라이브러리라고 할 수 있으며, 개발 효율성을 높여주는 최고의 API 라이브러리 중 하나입니다.

다만 라이브러리를 사용한다는 것 자체가 Axios에 의존성을 가진다는 점과, Promise로 표준화된 앞으로의 개발 생태계를 생각하면 Fetch API를 사용하는 것이 최적의 선택일지도 모르겠습니다.

또한, Next.js에서 캐싱 기능을 사용하기 위해서는 Axios의 adapter를 사용할 수도 있지만, 아직까지 Axios의 버전 변경점을 보면 fetch adapter에 대한 버그 수정의 내용이 많기도 하고, Next.js 역시 지속적으로 변화하고 있기 때문에 안정성 측면에서 조심스러운 선택이기도 합니다.

즉, 여느 vs 포스팅의 결론처럼 Fetch API와 Axios는 상황에 맞춰서 선택해야 한다고 말씀드리고 싶습니다. 😅

참고

• https://Axios-http.com/kr/docs/intro
• https://developer.mozilla.org/ko/docs/Web/API/XMLHttpRequest
• https://developer.mozilla.org/ko/docs/Web/API/Fetch_API
• https://javascript.info/promise-basics
• the xhr history lesson you never wanted
• https://nextjs.org/docs/app/api-reference/functions/fetch
• https://github.com/whatwg/fetch/issues/951
• https://github.com/whatwg/fetch/issues/20

개발자도구의 네트워크 탭을 보다보면 disk cache와 memory cache에서 가져오는 데이터가 꽤 많은 것을 볼 수 있습니다. 브라우저는 어떤 기준으로, 어떻게 이 데이터들을 저장하고 가져오고 있는 걸까요?

Memory Cache vs Disk Cache

먼저 Memory Cache와 Disk Cache를 구분하면 다음과 같습니다.

memory cache

• 페이지 로딩 중 같은 리소스를 여러 번 사용할 때
• SPA(Single Page Application)처럼 빠른 내부 이동이 있을 때
• 새로고침(F5 말고 페이지 네비게이션) 없이 다시 로딩할 때
• 아이콘, 로고와 같은 작은 사이즈의 이미지

disk cache

• 브라우저를 껐다 켜도 다시 써야 하는 리소스일 때
• 리소스 크기가 크고 오래 저장할 필요가 있을 때
• CSS, JS, Google Fonts, 큰 사이즈의 이미지 등
• 웹앱에 필요한 대형 리소스 파일

그럼 언제 캐시를 가져오는 건가요? 🤔

브라우저는 위 사진(출처: HTTP 완벽가이드)과 같은 절차를 거쳐 캐시를 저장하고 가져옵니다. HTTP 캐시 정책에 따라 응답을 어떻게 저장하고 가져오는지를 결정하는데요. 주로 Nginx와 같은 웹서버나 서버 코드, CDN 등에서 어떤 정책을 사용할지 지정할 수 있어요. 이때 주로 사용되는 HTTP Cache-Control 헤더의 캐시 지시자는 다음과 같습니다.

주요 Cache-Control 지시자

• Cache-Control: no-store : 캐시가 응답을 저장하는 것을 금지
• Cache-Control: no-cache: 재검사(변경 여부 확인) 없이 캐시 사용 금지
• Cache-Control: max-age: 지정된 시간까지 캐시 사용 가능

위 정책 등을 바탕으로 HTTP에서 저장된 캐시가 신선한 값이라고 판단한 경우, memory cache 혹은 disk cache에서 가져오게 됩니다.

HTTP 재검사(Revalidation)와 304 Not Modified

위 정책을 바탕으로 만약 캐시가 신선하지 않다고 판별한 경우, HTTP는 재검사(Revalidation)을 통해 해당 캐시가 신선한지 작은 재검사 요청을 통해 확인합니다. 이 방법은 캐시를 바로 가져오는 것보다는 느리지만,캐시가 변하지 않았다면 데이터를 받아올 필요가 없기 때문에 새로 요청하는 것보다는 빠르다는 장점이 있습니다. 이때, 캐시 재검사를 위해서 사용하는 조건부 요청은 주로 If-Modified-Since 혹은 If-None-Match 헤더를 사용합니다.

If-Modified-Since

If-Modified-Since(IMS)는 리소스의 마지막 수정 날짜를 바탕으로 캐시가 신선하다고 판단할 경우 body없이 304응답(HTTP 304 Not Modified)을 보내고 캐시의 마지막 수정날짜를 업데이트합니다.

If-None-Match

If-None-Match는 ETag(Entity Tag)를 바탕으로 재검사 하는데, ETag(Entity Tag)는 리소스의 버전 식별자로써, 보통 데이터의 수정시간이나 크기를 바탕으로 만들어집니다. 때문에 상황에 따라 ETag를 유지하거나 변경함으로써 캐시 정책을 수정할 수 있어요.

If-None-Match를 사용한 인터페이스 과정은 다음과 같습니다.

1. 서버에서 ETag를 포함한 응답을 보내면 브라우저는 서버와의 통신 과정에서 ETag를 브라우저 캐시 스토리지에 자동으로 저장한다.
2. 이후 서버에 API를 요청할 때 저장한 ETag를 함께 전송한다.
3. 이때 해당 ETag가 서버에서 응답할 ETag와 같다면 서버는 body없이 304응답(HTTP 304 Not Modified)을 보낸다.

요약

간단히 요약하자면, 브라우저는 웹서버나 서버코드 등에서 설정한 HTTP 캐시 정책에 따라 리소스를 memory cache 혹은 disk cache에 저장합니다. 그리고 재 요청 시 설정된 HTTP 캐시 정책에 따라 캐시가 신선한지를 판단합니다. 캐시가 신선하다면 빠르게 로딩할 수 있고, 만약 신선하지 않다면 ETag나 수정 시간 등을 이용해 재검사(Revalidation) 를 요청합니다.

➡️ 따라서 데이터의 크기와 성격, 그리고 서비스의 종류에 따른 적절한 캐시정책 설정이 필요합니다.

출처: HTTP 완벽가이드 https://toss.tech/article/smart-web-service-cache https://dev.to/csjcode/ultimate-caching-guide-3-browserchrome-37h1

앞서 리액트 19에서의 변경사항을 간단히 요약하자면, 서버 컴포넌트를 위한 변경사항과 편의성을 위한 hook이 추가되었습니다.

⚠️ 해당 글에서는 주요 변경사항을 담았으며, 모든 변경사항을 담지는 않았음을 알려드립니다.

새롭게 추가된 hook

useActionState

// Using <form> Actions and useActionState
function ChangeName({ name, setName }) {
  const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      const error = await updateName(formData.get("name"));
      if (error) {
        return error;
      }
      redirect("/path");
      return null;
    },
    null,
  );

  return (
    <form action={submitAction}>
      <input type="text" name="name" />
      <button type="submit" disabled={isPending}>Update</button>
      {error && <p>{error}</p>}
    </form>
  );
}

관례에 따라 비동기 트랜지션을 사용하는 함수를 Action이라 칭하며, useActionState를 사용하면 서버 컴포넌트에서도 Hydration 과정 없이도 즉각적으로 form을 사용할 수 있습니다. RSC를 사용하지 않는다면 일반적인 state와 동일하게 동작합니다.

useFormStatus

import {useFormStatus} from 'react-dom';

function DesignButton() {
  const {pending} = useFormStatus();
  return <button type="submit" disabled={pending} />
}

useFormStatus는 하위 컴포넌트에서도 상위 컴포넌트의 form을 읽을 수 있게 해줍니다.

useOptimistic

const [optimisticState, toggleOptimisticIsLike] = useOptimistic<State, Value>(
  state,
  (currentState: State, optimisticValue: Value): State => {
    return {
      isLike: optimisticValue,
      count: optimisticValue ? currentState.count + 1 : currentState.count - 1
    }
  })

  const handleClick = () => {
  startTransition(async () => {
    const nextIsLike = !optimisticState.isLike

    // 낙관적 업데이트
    toggleOptimisticIsLike(nextIsLike)

    try {
      const response = nextIsLike ? await addLike() : await removeLike()

      // 서버 응답 결과로 UI를 업데이트
      setState(response)
      setError('')
    } catch (error) {
      if (error instanceof Error) {
        setError(error.message)
      }
    }
  })
}
// 출처: <https://seungwoo.dev/posts/react-use-optimistic>

낙관적 업데이트를 쉽게 해줍니다.

리액트 18에서 추가된 useTransition에서도 비동기 함수를 지원할 수 있도록 변경되면서, 동일하게 낙관적 업데이트를 쉽게 다룰 수 있게 되었습니다.

// useTransition
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      const error = await updateName(name);
      if (error) {
        setError(error);
        return;
      }
      redirect("/path");
    })
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

use

import {use} from 'react';

function Comments({commentsPromise}) {
  // `use` 는 promise가 완료될 때 까지 suspend 상태입니다.
  const comments = use(commentsPromise);
  return comments.map(comment => <p key={comment.id}>{comment}</p>);
}

function Page({commentsPromise}) {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  )
}

use는 가장 상위의 컨텍스트 제공자를 찾아 읽을 수 있습니다. 최상위에서 호출할 필요가 없으며 조건문에서도 사용이 가능합니다.

import {use} from 'react';
import ThemeContext from './ThemeContext'

function Heading({children}) {
  if (children == null) { // <- 조건문
    return null;
  }

  // useContext를 사용할 때에는 할 수 없던 조건문 내 context 사용
  const theme = use(ThemeContext);
  return (
    <h1 style={{color: theme.color}}>
      {children}
    </h1>
  );
}

SSG를 위한 정적 API

• prerender
• prerenderToNodeStream

import { prerender } from 'react-dom/static';

async function handler(request) {
  const {prelude} = await prerender(<App />, {
    bootstrapScripts: ['/main.js']
  });
  return new Response(prelude, {
    headers: { 'content-type': 'text/html' },
  });
}

정적 HTML 생성을 위해 데이터를 로드하는 과정을 기다린 후 결과를 반환하며, 기존의 renderToString보다 향상된 기능을 제공합니다. 특히, Node.js 스트림이나 Web Streams와 같은 스트리밍 환경에서 동작하도록 설계되었습니다.

서버컴포넌트에서 사용할 수 있는 API

cache

const getUser = cache(async (userId: string) => {
  return db.getUser(userId);
});

cache() API는 데이터 페칭이나 연산 결과를 렌더링할 때마다 캐싱할 수 있게 할 수 있도록 합니다.

meta

정적 컴포넌트 혹은 정적 렌더링 환경에서 meta 태그를 사용 가능합니다.

function BlogPost({post}) {
  return (
    <article>
      <h1>{post.title}</h1>
      <title>{post.title}</title>
      <meta name="author" content="Josh" />
      <link rel="author" href="<https://twitter.com/joshcstory/>" />
      <meta name="keywords" content={post.keywords} />
      <p>
        Eee equals em-see-squared...
      </p>
    </article>
  );
}

이전 버전에서 업그레이드 시 주의할점

코드 자동 변환 (Codemods)

업그레이드를 돕기 위해, codemod.com 팀과 협력하여 리액트 19의 새로운 API와 패턴으로 코드를 자동으로 업데이트할 수 있는 codemod(AST를 분석해서 코드구조를 바꿈)를 배포했습니다. codemod 명령어를 사용하여 코드 마이그레이션을 할 수 있습니다.

더이상 사용할 수 없는 API들

• propTypes, defaultProps (2017년 4월 v15.5.0 지원중단)
  • 더이상 지원하지 않으며 타입스크립트를 사용해야함
• contextTypes와 getChildContext를 사용하는 레거시 Context (2018년 10월 v16.6.0 지원중단)
• 클래스 컴포넌트의 문자열 refs (2018년 3월 v16.3.0 지원중단)
• React.createFactory (2020년 2월 v16.13.0 지원중단)
• react-test-renderer/shallow 대신 react-shallow-renderer 사용
  • Shallow rendering은 내부동작에 의존하기 때문에 @testing-library/react를 권장합니다.
• ReactDOM.render 대신 ReactDom.createRoot 사용
  • ReactDOM.hydrate 대신 ReactDOM.hydrateRoot 사용
  • unmountComponentAtNode(document.getElementById("root")) 대신 root.unmount() 사용

더이상 사용할 수 없는 기능

• element.ref 이 아닌 element.props.ref 사용 (리액트 19는 ref를 prop으로 제공 )
• react-test-renderer 지원 중단
• script 태그로 모듈을 불러올 때 사용하는 UMD 빌드 제공 중단 (ESM 대체 사용)

그 외 변경사항

Suspense 개선사항

이전 버전에서는 컴포넌트가 suspense 상태가 되면, 일시 중단된 형제 컴포넌트(같은 레벨의 컴포넌트)들이 먼저 렌더링된 후에 fallback UI가 적용되었습니다. 리액트 19에서는 컴포넌트가 suspense 상태가 되면, 먼저 fallback UI가 적용되고 그 후에 일시 중단된 형제 컴포넌트들이 렌더링됩니다.

useRef 변경사항

ref를 property로 전달 가능

ref를 기본적으로 forwardRef는 삭제될 예정입니다. forwardRef는 더 이상 권장되지 않지만 리액트 19에서는 호환성을 위해 계속 동작합니다.

타입스크립트 useRef 사용시 인자 필요

useRef(); -> 타입스크립트 에러발생, useRef(undefined); -> 통과

const ref = useRef<number>(null);
// 'current'는 읽기 전용 속성이므로 할당할 수 없음
ref.current = 1; // undefiend를 넣을 수 있기 때문에 더이상 이런 문제가 발생하지 않음

• 타입스크립트의 전역 JSX 네임스페이스를 React.JSX로 대체
  • 다른 JSX 라이브러리와의 충돌 방지

참고: https://react.dev/blog/2024/12/05/react-19 https://react.dev/reference/react/cache https://www.intelligencelabs.tech/062b17fe-7b82-4bae-ba7f-0c17baca1bab#a520a537-7c18-49fe-8730-a200274514f8https://velog.io/@eunbinn/react-19-upgrade-guide https://velog.io/@eunbinn/react-compiler-soon#리액트-19는-리액트-컴파일러가-아닙니다 https://siosio3103.medium.com/번역-리액트-19-forwardref-지원-중단-앞으로-ref를-전달하기-위한-표준-가이드-13c02855efd8

퍼즐을 해결할 수 있는 가장 최소한의 난이도를 찾는 문제 문제 해결 방법은 단순하지만 이진탐색을 사용하지 않으면 시간초과가 발생하는 전형적인 이진탐색 문제이다.

첫번째 풀이 ❌ (시간초과)

function badSolution(diffs, times, limit) {
    let answer = 1;
    let curr = 0;

    for(let i=0; i<diffs.length; i++){
        if(diffs[i] > answer){
            curr += (times[i-1] + (times[i] || 0)) * (diffs[i] - answer) + times[i];
        } else {
            curr += times[i];
        }

        if(limit < curr) {
            i=-1;
            answer++;
            curr = 0;
            continue;
        }
    }

    return answer
}

단순하게 해결될 때까지 레벨을 1씩 증가시키면서 풀이를 진행한다. 테스트 15, 16, 17, 18, 21 에서 실패(시간 초과)가 발생한다.

두번째 풀이 ❌ (런타임에러)

function solution(diffs, times, limit) {
    let min = 1;
    let max = Math.max(...diffs);
    let answer = max;

    while (min <= max) {
        let mid = Math.floor((min + max) / 2);
        if (canSolve(mid)) {
            answer = mid;
            max = mid - 1;
        } else {
            min = mid + 1;
        }
    }

    function canSolve(level){
        let curr = 0;
        for(let i=0; i<diffs.length; i++){
            if(diffs[i] > level) {
                curr += (times[i-1] + (times[i] || 0)) * (diffs[i] - level) + times[i];
            } else curr += times[i];
            if(limit < curr) return false
        }
        return true
    }

    return answer
}

위의 풀이를 canSolve라는 함수선언문으로 변경하여고, 가장 어려운 난이도를 max로 설정하면서 이진탐색으로 풀어내었다. 하지만 문제 15번부터 런타임에러가 발생한다.

스프레드 연산자로 인해 발생하는 런타임에러

함수 인자 값으로 스프레드 연산자를 사용하면 그 인자들을 스택에 올려서 함수에 전달하게 된다. 때문에 Math.max(...hugeArray)와 같이 함수인자로 길이가 매우 긴 배열을 넘기게 되면 RangeError: Maximum call stack size exceeded 가 발생하게 된다.

위 풀이에서는 Math.max(...diffs)을 통해 이진탐색의 max 값을 설정하려 하였는데, 문제의 제한사항에서 diffs와 times 배열의 길이를 0 < n ≤ 300,000 이었기 때문에, 프로그래머스 상에서 런타임 에러가 발생하게 된 것이다.

세번째 풀이 ⭕️

function solution(diffs, times, limit) {
    let min = 1;
    let max = 0;
    diffs.forEach((v) => max = Math.max(v, max))

    let answer = max;
    while (min <= max) {
        let mid = Math.floor((min + max) / 2);
        if (canSolve(mid)) {
            answer = mid;
            max = mid - 1;
        } else {
            min = mid + 1;
        }
    }

    function canSolve(level){
        let curr = 0;
        for(let i=0; i<diffs.length; i++){
            if(diffs[i] > level) {
                curr += (times[i-1] + (times[i] || 0)) * (diffs[i] - level) + times[i];
            } else curr += times[i];
            if(limit < curr) return false
        }
        return true
    }

    return answer
}

diffs.forEach((v) => max = Math.max(v, max))를 통해 max값을 지정하였다. 다른 사람들의 풀이를 보니, diffs.reduce((acc, cur) => Math.max(acc, cur), 1)와 같이 바로 최대값을 선언할 수도 있었다. 또한, sumT = 2n; 과 같이 BigInt 타입을 사용해서 이진탐색과 같이 매우 큰 값을 다루는 문제에서 더욱 안전하게 풀이를 진행할 수 있었다.

ECMAScript 2022에서는 at() 이라는 기능이 추가되었는데요. 이제 더이상 배열의 마지막 요소를 찾기 위해 arr[arr.length-1]과 같이 작성하지 않아도 됩니다. arr.at(-1)과 같이 작성하면 마지막 요소를 찾을 수 있어요! 그런데, 이런 자바스크립트의 최신 문법은 어떻게, 어떤 기준으로 추가되는 것일까요?

ECMAScript의 표준을 관리하는 TC39

자바스크립트는 TC39에서 JS의 공식 명세서를 관리하는데요. TC39는 자바스크립트의 표준 사양을 만드는 기술 위원회로써, 애플, 구글, 삼성을 포함한 다양한 회사의 브라우저 및 엔진 개발자들이 모여 자바스크립트의 명세 변경 안건을 투표하고, 합의된 변경 사항을 국제 표준화 기구인 ECMA에 제출하는 일을 합니다. 우리가 흔히 알고 있는 ECMAScript(ES6, ES7 ...)도 TC39에서 개발한 자바스크립트 표준 사양입니다.

이러한 일을 하는 이유는 각기 다른 브라우저 엔진끼리 호환되는 자바스크립트를 사용하기 위해서인데요. 자바스크립트 엔진은 크롬은 V8, 애플은 JavaScriptCore, 파이어폭스는 SpiderMonkey 와 같이 제조사나 브라우저별로 각기 다른 엔진을 사용하고 있습니다. 뿐만 아니라, 자바스크립트는 서버나 키오스크, 심지어 전구에서도 실행되는 언어인데요. 각자의 명세를 바탕으로 개발한다면 아이폰에서는 볼 수 있는 웹페이지가 갤럭시에서는 읽을 수 없게 될지도 몰라요. 때문에 표준화 기구를 통해 모든 영역에서 하나의 자바스크립트를 사용할 수 있도록 하는 것입니다. 하나의 명세서에 맞춰 개발을 하기 때문에 모두 동일한 코드를 사용하고 읽을 수 있는 것이죠.

자바스크립트의 하위 호환성과 상위 호환성

이렇게 발전해온 자바스크립트는 하위 호환성을 강하게 지켜왔는데요. 자바스크립트의 하위 호환성을 말씀드리기 앞서, 하위 호환성과 상위 호환성이라는 용어가 낯설 수 있기 때문에 해당 용어에 대해 먼저 소개해 드리도록 하겠습니다.

하위 호환성과 상위 호환성

하위 호환성은 오래전에 만든 기술을 현재 환경에서 동작할 수 있도록 하는 것이고, 상위 호환성은 오래된 환경에서도 현재 만든 기술을 동작할 수 있도록 하는 것입니다. 쉽게 말하자면, 새로운 기술을 만들 때 과거를 지원하는 것은 하위 호환성, 미래를 대비하는 것은 상위 호환성입니다.

상위 호환성과 하위 호환성이라는 명칭 때문에 두 개념이 공존할 수 없는 것이라 생각할 수 있지만, 둘 다 지원할 수도, 지원하지 않을 수도 있습니다.

iOS 18.1과 인텔리전스의 상위 호환성

예를 들어 소개해드리겠습니다. 애플 인텔리전스는 아이폰 16의 출시와 함께 나왔지만, 아이폰 15pro에서도 사용할 수 있습니다. 이는 애플 인텔리전스가 구형기기인 아이폰 15 pro에 대해 상위 호환성을 유지한다고 볼 수 있습니다.

하지만 아이폰 15와 이전 모델에서는 애플 인텔리전스를 사용할 수 없기 때문에 상위 호환성을 보장하지 않는다고 볼 수 있습니다. 다만 애플 인텔리전스가 포함된 iOS 18.1은 아이폰 11에서도 설치할 수 있기 때문에 아이폰 11에 대한 하위 호환성을 보장합니다.

이처럼, 미래를 대비하는 상위 호환성보다는 하위 호환성을 보장하는 것이 상대적으로 쉽기 때문에 상위 호환성보다는 하위 호환성을 지원하는 사례가 훨씬 많습니다.

하위 호환성을 보장하는 자바스크립트

그럼 다시 자바스크립트로 돌아가서, TC39의 명세를 기반한 자바스크립트는 하위 호환성을 강하게 지키고 있는 언어인데요. 그 이유는 하위 호환성을 지키지 않으면 오래된 웹사이트를 최신 브라우저에서 읽지 못하는 문제가 발생할 수 있기 때문입니다. 덕분에 1995년에 만들어진 코드를 지금도 동작할 수 있는 것인데요. IT 분야에서 이 정도 하위 호환성을 지키면서 무언가를 유지 보수해온 사례는 거의 없습니다. 물론 TC39에서도 하위 호환성을 깨는 결정을 하기도 했는데요. 이로 인한 부정적인 부수효과가 작다고 판단될 때 예외적으로 하위 호환성을 깨기도 했습니다.

하위 호환성 보장으로 인해 발생하는 예외적인 상황들

한번 명세서에 작성된 내용을 변경하면 기존 프로그램들이 동작하지 않을 수 있습니다. 때문에 하위 호환성을 위해 여전히 발생하고 있는 자바스크립트 버그들이 있는데요. 당장 typeof null 를 실행해보면 null 이 아닌 undefined가 출력됩니다.

이는 오래전에 발생한 자바스크립트 버그 때문인데요. 자바스크립트가 처음 만들어질 때는(1995년) 내부적으로 데이터 타입을 구분할 때 비트 패턴을 기반으로 구분하였습니다. 이때 null의 데이터 타입을 표현하는 비트 패턴이 객체를 나타내는 비트 패턴과 같아 객체처럼 인식되는 버그가 발생했습니다. 하지만 이를 수정하게 되면 기존의 프로그램에서 문제가 발생할 수 있기 때문에 지금까지 이 버그를 수정하지 못한 것입니다.

최근에 수정된 사항에도 비슷한 점이 있습니다.

if(false) {
    function ask() {
        console.log(＂HERE＂)
    }
}
ask()

위와 같은 코드를 실행하면 어떤 현상이 벌어질까요? if 문의 ask()를 참조하지 못해 Reference Error가 발생하는 것이 일반적으로 기대하는 동작입니다. 하지만 Reference Error가 아닌 Type Error 가 발생하는데요. 이는 ES6 이전에서는 블록 스코프라는 개념이 없었고, 모두 함수 스코프였기 때문이에요. 따라서 ES6 이전과 이후의 동작이 달라졌지만, 하위 호환성을 위해 Type Error가 발생하도록 둔 것입니다.

상위 호환성을 보장하지 않는 자바스크립트

하위 호환성을 보장하는 것과 달리, 자바스크립트는 상위 호환성을 보장하고 있지 않은데요. 오랜 시간 동안 브라우저의 발전에는 너무나 다양하고 많은 발전이 있어왔고, 이를 충족시키는 상위 호환성을 지키기에는 어려움이 많기 때문입니다. 그럼 최신 문법을 사용했을 때 오래된 환경(브라우저)에서는 실행하지 못할까요? 우리는 본능적으로 그렇지 않다라는 것을 알고 있습니다.

폴리필을 통한 상위 호환성 보장

자바스크립트는 상위 호환성을 지키지 않지만, 개발 과정에서 폴리필(polyfill)이나 트랜스파일러(transpiler)인 Babel을 통해 최신 문법으로 작성된 코드를 오래된 브라우저에서도 동작할 수 있도록 이전 버전의 코드로 변환시켜줍니다. 물론 그럼에도 놓칠 수 있는 부분이 있기 때문에 지원해야 하는 범위에 따라 개발자의 주의가 필요합니다.

폴리필 사용 시 주의할 점

예를 들어 바벨을 통해 0.1%의 사용률을 가지는 구형 브라우저까지 지원하도록 설정하더라도, 갤럭시 S8에서는 Object.fromEntires를 사용할 수 없습니다. 갤럭시 S8은 2019년 이후 삼성 브라우저 업데이트를 지원받지 못하고, 2019년까지의 삼성 브라우저는 사용률이 0.09% 이기 때문이죠.

HTML과 CSS의 상위 호환성

상위 호환성을 보장하지 않는 자바스크립트와 달리, HTML과 CSS는 상위 호환성을 보장하고 있는데요. 어떻게 가능한 것일까요? HTML과 CSS는 최신 문법과 같이 읽지 못하는 속성이나 값을 발견하게 되면 에러를 발생시키는 것이 아니라, 건너뛰고 계속해서 읽는 방식으로 코드를 읽습니다. 때문에 오래된 브라우저에서 현대 문법의 코드를 실행할 수 있는 것인데요. 하지만 실행할 수 있는 것이지, 현대 문법을 동작할 수 있는 것은 아닙니다.

예를들어 flexbox는 비교적 최근(2020년경)부터 지원되는 속성인데요. 때문에 오래된 브라우저에서 gap을 읽지 못하는 현상이 있어서 오래된 브라우저에서는 gap이 아닌 margin을 쓰는 것이 안전합니다.

정리

오래된 브라우저를 지원하기 위해 폴리필을 한다는 개념은 많이들 알고 계셨을텐데요. 그럼에도 생소한 상위 호환성과 하위 호환성을 설명하려다 보니 글이 길어졌네요. 정리하자면, 자바스크립트는 TC39와 ECMAScript와 같은 표준화 기구로 인해 하위 호환성을 강하게 지키고 있다고 말씀드리고 싶습니다. 하지만 상위 호환성은 보장하지 않기 때문에 상위 호환성을 위해서 폴리필(polyfill)이나 트랜스파일러(transpiler)인 Babel을 사용해야 합니다.

이 글 덕분에 상위 호환성과 하위 호환성, 그리고 ECMA Script와 TS39에 대해 조금 친해질 수 있었다면 좋겠네요 😊

참고: You Don’t Know JS Yet, 하위 호환성과 상위 호환성 헷갈리지 말아요

클로저란 외부 함수가 종료된 후에도, 내부 함수가 외부 함수의 지역 변수에 접근할 수 있는 함수를 의미한다. 함수가 실행되어 종료된 이후에도 종료된 외부 함수의 변수를 사용할 수 있기 때문에 상태유지, 데이터 은닉, 비동기 처리 등을 목적으로 사용할 수 있어, 많은 프로그래밍 언어에서 사용하고 있다.

상태유지와 데이터 은닉

function createCounter() {
    let count = 0;
    return function() {
        count++;
        return count;
    };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

위 예제에서는 createCounter는 실행과 동시에 종료되었으며, 반환된 함수는 counter라는 변수명에 저장되었다. 때문에 count에는 임의로 접근할 수 없으며, counter 함수의 클로저를 통해서만 수정할 수 있기 때문에 데이터 수정을 제한할 수 있다. 또한, count라는 변수를 전역에서 선언하지 않고도 상태를 유지할 수 있는 장점이 있다.

비동기 처리에서의 클로저

for (var i = 1; i <= 3; i++) {
  setTimeout(() => {
      console.log(`Counter: ${i}`);
  }, i * 1000);
}

자바스크립트의 비동기 처리를 묻기 위해 자주 사용되는 예제이다. 간단하게 코드의 진행방식을 살펴보면,

1. for문이 동작하면서 3번 setTimeout 함수를 콜스택에서 실행하며, 비동기 함수인 setTimeout은 이벤트루프에 의해 Web API에서 처리된다.
2. setTimeout이 비동기처리 되는 동안 i는 3번의 for문을 거쳐 4가 된다.
3. Web API에서 처리된 setTimeout은 이벤트루프에 의해 매크로 테스크큐를 거쳐 콜스택에서 실행된다.
4. 이때의 i는 var로 선언되어 함수레벨 스코프를 가지기 때문에 setTimeout의 콜백함수 내부에서 참조하는 i는 var로 선언한 i 이며, 이미 i가 4가 되었기 때문에 Counter: 4 가 출력된다.

뭔가 이상한 이 코드의 해결방법은 콜백함수 별로 개별적인 i를 가지도록 하여 해결할 수 있다. 첫번째 방법은 블록레벨 스코프를 사용하여 for문이 실행될 때 마다 개별적인 스코프를 가지는 i를 선언하는 방법, 그리고 두번째 방법은 즉시실행함수와 클로저를 이용하여 렉시컬 스코프에 개별적인 i 를 저장하는 방법이 있다.

본 포스팅은 클로저를 중심으로 다루기 때문에, 클로저를 통해 해결하는 방법을 알아보자면 다음과 같다.

for (var i = 1; i <= 3; i++) {
  ((argument) => {
      setTimeout(() => {
          console.log(`Counter: ${argument}`);
      }, argument * 1000);
  })(i);
}

앞서 설명한 비동기 처리 과정을 제외하고 이 코드의 진행방식을 살펴보면,

1. for 루프가 실행될 때마다 즉시 실행 함수 (argument) => { ... }가 호출되며, i 값이 argument에 전달된다.
2. 즉시 실행 함수가 실행되면서 setTimeout의 콜백함수가 생성되고, 이때 콜백함수는 상위함수인 즉시실행함수의 argument를 참조하는 렉시컬 환경을 가진다.
3. 이후 setTimeout의 콜백함수가 실행되면서 argument를 참조하는데, 즉시실행함수의 변수 argmunet는 이미 종료되었지만 렉시컬 환경에서 참조하고 있기 때문에 접근할 수 있다. (클로저를 통한 접근)
4. console.log()가 실행될 때 실행하는 argument는 4가 된 var = i를 참조하는 것이 아니라 콜백함수 (()=> console.log(...))의 렉시컬 환경인 argument 값을 참조하기 때문에 Counter: 1, 2, 3이 출력된다.

즉, setTimeout의 콜백함수가 실행될 때 참조하는 argument는 이미 종료된 즉시실행함수 ((argument) => { ...})(i)의 i를 참조하기 때문에 각각 개별적인 i를 갖는 것이고, 4가 된 i 변수와는 무관한 것이다.

리액트 setState에서의 클로저?

블로그를 보다보면 흔히들 React에서 useState를 사용할 때 클로저를 사용한다고 한다. 리액트 컴포넌트가 다시 실행될 때 기존 값은 사라지게 되는데, 클로저가 이를 기억하고 가져올 수 있다고 한다. 내 생각에는 이 부분은 useState를 자바스크립트로 간단하게 구현할 때 클로저를 사용할 수 있다는 것에서 발생한 오해라고 생각한다.

리액트에서 setState와 같은 매커니즘을 통해 UI를 변경하게 되면, 가상 DOM의 변경사항에 맞춰 실제 DOM을 업데이트하는 재조정(reconciliation)과정을 거쳐 반영된다. 따라서 상태가 변경될 때 이전 값이 사라지는 것이 아니라 상태가 변경된 이후에 이전 값이 사라지는 것이며, 리액트는 클로저를 통해 사라진 이전 값을 불러올 필요가 없다.

클로저는 자바스크립트만의 개념일까?

이처럼 활용도가 높은 클로저는 자바스크립트만의 고유 개념이 아니며, 현재 대부분의 언어에서 사용된다. 클로저를 사용하는 언어이자, 사용할 수 있는 언어는 다음과 같은 특징을 가진다.

1. 렉시컬 스코프를 사용한다.
2. 함수가 일급 객체이다.

렉시컬 스코프

렉시컬 스코프(정적 스코프)는 함수가 어디서 "선언"되었는지에 따라 변수의 유효 범위가 결정되는 방식을 말한다. 렉시컬 스코프와 반대되는 개념인, 다이나믹 스코프(동적 스코프)는 함수가 어디서 "호출"되었는지에 따라 변수의 유효범위가 결정된다. 그리고 현재 대부분의 언어는예측 가능성과 성능 최적화 등의 이유로 렉시컬 스코프를 채택하고 있다.

클로저와 렉시컬 스코프에 대해 이해했다면 왜 클로저를 사용하려면 렉시컬 스코프를 사용해야 하는지 알 수 있다. 더 쉽게 말하자면, 다이나믹 스코프에서는 클로저가 필요하지 않는 이유를 알 수 있다.

렉시컬 스코프는 선언된 위치에서 변수의 유효 범위가 결정되기 때문에 자신이 선언된 환경을 저장하며(렉시컬 환경), 이 개념을 기반으로 클로저가 사용된다. 반면에 다이나믹 스코프는 호출될 때 변수의 유효범위가 결정되므로 렉시컬 환경이 필요 없는 것이고, 자연스럽게 클로저도 사용할 필요가 없는 것이다.

일급 객체

프로그래밍 언어를 공부했다면 일급 객체라는 말을 무조건 들어봤을 것이다. 처음 일급 객체라는 단어를 봤을 때, 진짜 1급 객체를 말하는 것인가? 애니메이션 속 레벨을 지칭하는 것과 같은 유치한 네이밍은 어디서 왔을까 라는 의구심이 들었다.

결론으로 말하자면 일급 객체의 일은 1이 맞으며, 영문표현은 First-Class이다. 일급 객체는 1966년의 프로그래밍 언어의 설계에서 중요한 개념을 정의하며 사용된 단어로써, 특정 요소에 따라 1급, 2급, 3급으로 나누었다. 이때 할당, 전달, 반환이 모두 가능한 요소를 일급 객체라고 칭하였으며, 일부만 가능한 것은 이급, 매우 제한된 요소는 삼급으로 나누었다.

그럼 다시 클로저로 돌아가서, 왜 함수가 일급 객체여야 클로저를 사용할 수 있을까?

함수가 일급객체인 자바스크립트

function createCounter() {
    let count = 0;
    return function() {
        count++;
        return count;
    };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

앞서 소개한 전형적인 클로저의 예시이다. 클로저의 정의를 다시 살펴보면, 클로저란 외부 함수가 종료된 후에도, 내부 함수가 외부 함수의 지역 변수에 접근할 수 있는 함수를 의미한다.

위 예시에서는 createCounter 라는 함수를 counter 라는 변수에 저장했으며, createCounter(외부함수)는 종료되었지만 createCounter함수에서 반환된 함수(내부함수) function(){ ... return count; }가 createCounter의 변수인 count(외부함수의 지역 변수)를 참조하고 있기 때문에 count가 유지되며 접근할 수 있는 것이다.

이처럼 함수가 클로저가 되려면, 함수가 반환된 이후에도 렉시컬 환경을 유지할 수 있어야 한다. 이를 위해 함수를 변수에 저장하거나 반환할 수 있어야 하며, 이는 함수가 일급 객체일 때 가능하다. 따라서 함수가 일급 객체여야만 클로저가 성립할 수 있다.

함수가 일급객체가 아닌 C언어

#include <stdio.h>

void outer() {
    int count = 0;

    void inner() {  // C는 함수가 일급 객체가 아니므로 내부 함수를 반환할 수 없음
        count++;
        printf("%d\n", count);
    }

    inner();
}

int main() {
    outer();
    outer();  // 새로 호출될 때마다 count 값이 초기화됨
    return 0;
}

자바스크립트는 사용자 입력, 네트워크 요청과 같이 실행 중 동적으로 변화하는 환경(브라우저)에서 동작해야 했기 때문에, 함수를 런타임에서 생성하거나 반환할 수 있도록 설계되었으며, 함수의 메모리 저장 방식도 동적으로 변경될 수 있도록 힙(Heap) 메모리에 할당되도록 설계되었다.

반면, C언어는 하드웨어와 친화적인 정적환경에서 실행되도록 설계된 언어이기 때문에, 런타임에서의 동적 처리를 최소화하여 최적화하였다. 따라서, 실행 중에 새로운 함수를 동적으로 생성하거나 반환할 필요가 없었으며, 모든 함수는 컴파일 시점에 고정된 메모리 주소에 저장되었다.

때문에 C언어의 예시에서는 자바스크립트의 예시처럼 클로저를 사용한 상태유지가 불가능한 것이다.

참고: You Don’t Know JS Yet, https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js

state나 props가 갱신되어 render()가 실행되면서 리액트가 렌더링되면, 리액트는 실제 DOM 구조를 가벼운 자바스크립트 객체로 표현한 가상 DOM(리액트 엘리먼트 트리)을 생성합니다. 그리고 diffing 알고리즘을 통해 변경사항을 O(n)의 복잡도로 파악할 수 있습니다.

알고리즘의 동작원리는 다음과 같습니다.

• 서로 다른 타입의 두 엘리먼트는 서로 다른 트리를 만들어낸다.
• 개발자가 key prop을 통해, 여러 렌더링 사이에서 어떤 자식 엘리먼트가 변경되지 않아야 할지 표시해 줄 수 있다.

두 트리를 비교할 때, 루트부터 비교하며 어떤 변경사항이 있는지를 확인합니다. 이때 만약 루트 노드가 다르면 해당 하위 트리를 모두 새로 렌더링합니다.

노드를 비교할 때에는 타입(이름)과 속성, key를 비교합니다. 엘리먼트의 타입(이름)이 다르다면 완전히 새로운 트리를 구축합니다. <a>에서 <img>로, 혹은<Article>에서 <Comment>로 바뀌는 것 모두 트리 전체를 재구축하는 경우입니다.

두 노드의 타입이 같으면 속성과 자식 요소를 비교합니다. 이때 동일한 내역은 유지하고 변경된 속성들만 갱신합니다. 노드의 비교과정이 끝나면 해당 노드의 자식들을 재귀적으로 탐색하며 처리합니다.

리액트에서 배열의 변경사항을 감지하고 렌더링하는 방식

리액트에서 배열을 사용해서 컴포넌트를 렌더링한다면 리액트는 배열을 순회하면서 요소를 생성하고 반환합니다.

이때 배열에 변경사항이 생겼을 때 리액트는 Virtual DOM과 현재의 배열을 비교하며 변경사항을 확인합니다. 예를 들어 [1,2,3,4,5] 라는 배열이 있을 때, 3을 삭제한다면 리액트는 [1,2,4,5]배열을 순회하면서 비교하게 되는데, [1,2]까지는 기존의 첫번째 두번째 요소와 같지만 [4,5]는 네번째 [3,4]와 다르기 때문에 재조정 과정을 진행합니다.

만약 첫번째 값이 삭제되었다면 배열의 모든 요소를 리렌더링 해야 하는데, 배열 내 모든 요소를 리렌더링하는 것은 효율적이지 않으며, 배열 내부의 값을 비교하기 위해 배열의 모든 값을 확인하면서 변경사항을 체크하는 것도 효율적이지 않습니다.

때문에 리액트는 key를 통해서 배열 내에 어떤 요소가 변경되었는지를 판단하는데, key값이 존재하지 않으면 자동으로 배열의 index를 key값으로 설정합니다.

index를 key값으로 사용할 때의 문제점

이때 배열의 index를 key값으로 사용할 때의 문제점이 발생하는데, 배열의 순서가 바뀌거나 값이 추가/삭제되는 경우 index가 변경될 수 있습니다. 예를 들어 [1,2,3,4,5] 라는 배열이 있을 때, 3을 삭제한다면 리액트는 index가 [0,1,3,4]가 아닌 [0,1,2,3]으로 변경되어 5가 변경되었다고 판단하게 됩니다.

Math.random()을 key값으로 사용할 때의 문제점

또한 key값을 Math.random() 과 같이 매번 변경되는 것을 사용하면 안되는 이유도 이와 같은데, 키를 확인하는 과정에서 key가 매번 변경되기 때문에 배열의 모든 요소가 변경되었다고 판단하여 모든 요소를 재생성하는 효율적이지 않는 동작을 하게 됩니다.

https://ko.react.dev/learn/rendering-lists#why-does-react-need-keys https://ko.legacy.reactjs.org/docs/reconciliation.html#the-diffing-algorithm

자바스크립트 개발을 하다 보면 가끔씩 require문을 사용하는 코드들을 볼 수 있습니다. 프론트엔드가 아닌 백엔드를 개발하시는 분이라면 어쩌면 import보다 require에 익숙하실 수도 있습니다. 웹개발을 시작한지 오래되지 않은 프론트엔드 개발자로서, ESMdoules이 다른 파일의 코드를 가져오는 당연한 방식이라고 생각할 때도 있었는데요. ES Module은 어떻게 등장하게 되었는지, 왜 옛 코드에는 아직도 require가 남아있고, 왜 아직도 ES Module이 아닌 CommonJS를 쓰려 하는지에 대해 포스팅하였습니다.

ES Module과 모듈 시스템의 역사

먼저 ES Modules이란 무엇인가에 대해 설명드려야 할 것 같습니다. ES Modules은 2015년에 ECMAScript6에서 자바스크립트 모듈 시스템으로 정식으로 추가된 기능인데요. ES Modules가 등장하기 전, CommonJS, AMD 등 브라우저 환경에서 혼재되어 사용되던 모듈시스템을 통합하기 위해 표준으로 지정되었습니다. ES Modules은 이제는 너무나 익숙한 방식이지만 사실 타입스크립트는 4.7버전, NextJS는 12버전부터 ES Module을 지원하기 시작했을만큼 얼마되지 않은 모듈 시스템입니다.

그런데 왜 지금도 많이 사용되는 CommonJS를 표준으로 지정하지 않고 새로운 모듈 시스템을 만든걸까요?

CommonJS의 등장과 브라우저에서의 단점

초창기 자바스크립트의 모듈시스템 문제를 해결하기 위해 등장한 CommonJS는 사실 ServerJS라는 이름의 프로젝트를 시작했을 만큼 서버를 위한 모듈시스템이었습니다. (서버 사이드 자바스크립트에 필요한 것)

ES Module과 CommonJS의 가장 큰 차이점은 비동기적으로 동작하는 ES Module과는 달리, CommonJS는 동기적으로 동작한다는 점인데요. 서버에서는 파일시스템으로 빠르게 모듈을 불러올 수 있었기 때문에 안정성을 위해 실행 전에 모든 의존성을 불러오고 있었습니다. 때문에 동기적으로 동작하는 CommonJS는 서버에서는 문제가 없었지만 브라우저에서 사용할 때 문제점이 발생하게 됩니다. 로컬 디스크에 모든 디펜더시를 가지고 파일시스템 I/O를 통해 빠르게 필요한 모듈을 호출하는 서버와는 달리, 브라우저는 네트워크를 통해 필요한 모듈을 다운로드 하고 나서야 사용할 수 있었습니다. 그리고 이때 발생하는 동기적인 로딩이 성능과 사용자의 경험에 치명적인 영향을 끼치게 됩니다.

브라우저의 동기 문제를 해결하기 위한 AMD 등장

이 문제를 해결하기 위해 브라우저 환경을 위한 AMD(Asynchronous Module Definition) 라는 모듈 시스템이 등장했는데요. 비동기적 모듈 선언이란 뜻처럼, 비동기 방식을 사용하는 모듈 시스템입니다. 모듈과 의존성을 정의하고 콜백함수를 통해 필요한 모듈을 병렬적으로 불러오는 방식이었습니다. 덕분에 비동기 문제를 해결하고 더 쉬운 디버깅 환경을 만드는 등의 장점이 있었습니다. 하지만 AMD는 CommonJS와 완벽히 호환되지 않았고, 이런 환경 속에서 두 모듈을 호환할 수 있는 UMD 패턴이 등장하기도 하였습니다.

ES Module의 등장과 ES Module의 장점

그리고 이런 여러가지 모듈 시스템이 혼재되어 있는 상황을 해결하기 위해, ESCMAScript 6에서 ES Module이 표준 모듈 시스템으로 명세되었습니다. ES Module은 import/export라는 직관적인 구문과 정적구조를 통해 사용성과 성능 향상을 이끌어냈는데요.

모듈이 런타임 시점에서 동적으로 할당되는 CommonJS와 달리, ES Module은 정적 분석을 통해 런타임 이전에 의존성 그래프를 만들어주었습니다. 덕분에 별도로 모듈의 의존성이나 불러오는 순서를 정의하지 않아도 되었을 뿐만 아니라, 이 시점에서 사용되지 않는 코드를 정리해주는 트리쉐이킹이나 코드스플리팅을 진행할 수 있다는 장점이 있었습니다.

그럼 왜 아직 CommonJS를 사용하는 건가요?

이미 만들어진 CommonJS 기반의 모듈들

기존에 사용되던 대부분의 라이브러리가 CommonJS를 기반으로 만들어졌습니다. 프로젝트에서 중요한 역할을 하는 모듈을 포함하여 npm에 게시된 수백만 개의 모듈이 이미 CommonJS를 사용하고 있습니다. ES Module을 지원하는 라이브러리가 많아지고 있지만, 이 많은 패키지가 모두 그렇게 될 수는 없습니다.

서버 환경에 특화된 CommonJS

ES Module은 브라우저를 위해 비동기로 구현된 반면, 앞서 이야기했던 것 처럼 CommonJS는 서버 환경을 중점적으로 설계되었습니다. ES Module은 정적 분석 과정을 거치며 import를 export에 바인딩되는데요. 브라우저 환경에서는 트리쉐이킹 등으로 인해 네트워크로 불러와야 할 용량이 줄어들어 높은 성능 향상을 이끌어내지만, 파일 입출력으로 코드를 불러오는 서버사이드 환경에서는 상대적으로 성능 향상이 크지 않습니다. 오히려 이 과정으로 인해 설계상 CommonJS보다 느릴 수 밖에 없기 때문에, 대규모 애플리케이션 환경에서는 더 느린 성능을 보여주게 됩니다.

출처: 자바스크립트의 표준 정의 : CommonJS vs ES Module JavaScript 번들러로 본 조선시대 붕당의 이해 코어자바스크립트 모듈 commonjs vs esm JavaScript Module System(2) - UMD와 ESM TOAST UI 의존성 관리 [번역] CommonJS는 사라지지 않습니다 [번역] CommonJS가 자바스크립트를 해치고 있습니다 JavaScript 표준을 위한 움직임: CommonJS와 AMD 번들러 파헤치기 1 - 모듈 시스템의 발전과 역사 (commonJS, AMD, UMD, ESM-ES Module) CommonJS와 ESM에 모두 대응하는 라이브러리 개발하기: exports field Why AMD? why CommonJS (and its async incarnation, AMD) were not adopted by browsers? CommonJS에서 ESM으로 전환하기

롤케이크 자르기는 1~10,000 중 무작위 수가 담긴 1,000,000 이하의 length를 갖는 배열이 있을 때, 배열을 길이와 상관없이 2등분 하였을 때 총 개수와 상관없이 A와 B의 값이 다른 숫자의 수(Unique Value)가 일치하는 경우의 수를 묻는 문제이다.

O(n²) 시간복잡도 풀이 (시간초과)

function solution(topping) {
    let answer = 0;
    const n = topping.length;
    if(n === 1) return 0;
    for(let i=1; i<n; i++){
        if(new Set(topping.slice(0,i)).size
           === new Set(topping.slice(i)).size) {
            answer++;
        }
    }
    return answer;
}

처음에는 slice를 사용하여 배열을 분할한 뒤 Set을 통해 Unique Value를 파악하였지만 시간초과로 실패하였다. O(n)의 시간복잡도를 갖는 for문과 slice가 중첩되어 O(n²)의 시간복잡도를 가진다.

O(n)시간복잡도 풀이

function solution(topping) {
    let answer = 0;
    const n = topping.length;
    if(n === 1) return 0;

    const A = new Map();
    const B = new Map();
    for(let x of topping){
        B.set(x, (B.get(x) || 0) + 1);
    }

    for(let i=0; i<n-1; i++){
        const top = topping[i];
        A.set(top, 1);
        if(B.get(top) === 1) B.delete(top);
        if(B.get(top)) B.set(top, B.get(top)-1);
        if(A.size === B.size) answer++;
    }
    return answer;
}

코드의 흐름은 다음과 같다.

1. B의 토핑 정보를 B 라는 Map 객체에 담는다. → O(n)
2. for문을 사용하여 토핑의 정보를 A에 담고, B에서는 덜어낸다. → O(n)
3. 만약 B의 토핑이 0이라면 delete를 사용하여 토핑의 종류를 감소시킨다. → O(1)
4. Map.size를 통해 A와 B를 비교하여 값이 같다면 answer(경우의 수)를 +1 한다. → O(1)

Object를 사용하여 토핑의 정보를 담으면 종류(Unique Value)를 파악하기 위해 Object.keys()를 사용해야 하는데, 이때 O(n)의 시간복잡도가 걸리기 때문에 O(1)의 시간복잡도를 갖는 Map.size를 사용하기 위해 Map을 선택했다.

또한 아주 약간이지만 Map은 Object보다 메모리를 조금 더 사용하는 대신, 값을 바꿀 때에는 조금 더 좋은 성능을 가지기도 한다.

다른 사람의 풀이

function solution(topping) {
    const a = new Set()
    const b = {}

    let answer = 0;
    let check = 0

    for (let i = 0; i < topping.length; i++) {        
        if (b[topping[i]]) {
            b[topping[i]]++
        } else {
            b[topping[i]] = 1
            check++            
        }
    }

    for (let i = 0; i < topping.length; i++) {
        a.add(topping[i])
        b[topping[i]]--

        if (!b[topping[i]]) check--
        if (a.size === check) answer++
    }

    return answer;
}

가장 많은 좋아요를 받은 jgjgill 님의 풀이이다. Map을 사용하지는 않았지만, 토핑의 종류(Unique Value)를 check라는 별도의 변수를 두고 계산하였다.

기본적인 흐름은 비슷하지만, Map 보다는 Object가 다루기 쉽고 가독성이 좋다는 점에서 좋은 코드라고 생각한다.

기본적인 웹사이트의 렌더링 과정은 다음과 같다.

1. 클라이언트에서 HTTP를 통해 서버로 데이터를 요청한다.
2. 서버는 요청에 따라 데이터를 처리하여 HTTP로 응답한다.
3. 클라이언트는 응답받은 리소스를 파싱하여 인터페이스를 렌더링한다.

하지만 NextJS는 서버사이드렌더링에 좀 더 최적화된 렌더링을 가지고 있는데, NextJS에서는 클라이언트 컴포넌트와 서버 컴포넌트의 경계를 나누어 각각 다른 렌더링 과정을 거친다. 이번 포스팅에서는 서버 컴포넌트와 클라이언트 컴포넌트의 렌더링 과정에 대해 공식문서를 바탕으로 정리하였다.

⚙️ NextJS의 렌더링 과정

🏢 서버 컴포넌트 렌더링 과정

Server Componets는 경로(route)와 서스펜스 Boundary에 따라 청크로 분할되는데, 분할된 각각의 청크는 다음의 두가지 단계를 거쳐 렌더링된다.

1. 리액트에서 Server Components를 RSC 으로 렌더링한다.
2. Next.js에서 RSC와 클라이언트 컴포넌트의 JavaScript를 통해 서버에서 HTML을 렌더링한다.

✅ RSC(React Sever Components Payload)란? 렌더링된 React Server Components 트리의 이진표현으로 다음과 같은 정보가 담겨있다.

1. 서버 컴포넌트의 렌더링 결과
2. 클라이언트 컴포넌트가 렌더링 될 곳의 Placeholder와 자바스크립트 파일의 참조
3. 서버 컴포넌트에서 클라이언트 컴포넌트로 전달할 모든 데이터

이후 클라이언트 환경에서 다음과 같은 작업을 거친다.

1. 초기 페이지를 불러오는 상황(Full page load)이라면 상호작용할 수 없는 미리보기를 즉시 보여준다. (React가 직접 제어하지는 않는 HTML)
2. RSC로 클라이언트와 서버 컴포넌트 트리를 조정하고 DOM을 업데이트 하여 보여준다.
3. 이후 JavaScript를 사용하여 hydrate를 통해 앱(Application)을 상호작용할 수 있도록 만든다.

서버 컴포넌트 렌더링 전략

서버 컴포넌트를 렌더링 할 때에는 다음과 같은 전략을 선택할 수 있다.

정적 렌더링(Default)

정적 렌더링은 빌드될 때 혹은 revalidation 시 백그라운드에서 실행된다. 이는 블로그나 제품 페이지 같이 공통적인 데이터를 보여주고 자주 변경되지 않는 페이지에서 유용하다.

동적 렌더링

동적 렌더링은 각 사용자별로 요청할 때 마다 렌더링된다. 따라서 사용자 맞춤형 데이터나 검색결과 같이 요청에 맞춰 데이터를 보여줘야 할 때 유용하다.

웹사이트는 한가지 전략만을 사용하기보다는 대부분 두가지를 동시에 사용한다. 동적인 정보가 필요한 곳에는 동적 렌더링을, 그렇지 않은 곳은 정적 렌더링을 적절히 혼합하여 사용한다.

동적 API(Dynamic APIs)

요청 시에만 알 수 있는 정보에 의존하는 API들을 사용하면 전체 경로를 동적 렌더링으로 전환할 수 있다. 동적 API 로는 cookies, headers, connection, draftMode, searchParams props, unstable_noStore가 있다.

스트리밍(Streaming)

스트리밍은 기본적으로 Next.js App router에 내장되어 있으며, 스트리밍을 사용하면 전체 콘텐츠가 렌더링되기 전에 일부를 보여줄 수 있다.

🖥️ 클라이언트 컴포넌트 렌더링 과정

클라이언트 컴포넌트는 첫 방문이거나 새로고침으로 전체 페이지를 로드한 것인지(Full page load), 아니면 방문한 페이지에서 탐색을 한 것인지(Subsequent Navigations)에 따라 다르게 렌더링된다.

Full page load(전체 페이지 로드)

NextJS는 초기 페이지 로드 최적화를 위해 React의 API를 사용하여 클라이언트 컴포넌트와 서버 컴포넌트 모두를 서버에서 정적 HTML 미리보기(Static HTML preview)로 렌더링한다. 따라서 첫 방문시에는 정적 HTML 미리보기(Static HTML preview)를 사용해 즉시 페이지를 볼 수 있다.

Subsequent Navigations(후속 네비게이션)

만약 Full page load가 아니라면 클라이언트 컴포넌트는 전적으로 클라이언트에서 렌더링된다. 즉, 클라이언트 컴포넌트의 자바스크립트 번들이 다운되고 준비된 이후, RSC를 사용하여 클라이언트와 서버 컴포넌트 트리를 조정하고 DOM을 업데이트하는 과정을 거친다.

(번외)어떻게 작성된 HTML 콘텐츠에 리액트 컴포넌트를 렌더링할 수 있을까?

리액트 18버전 기준으로, 리액트는 Client React DOM APIs를 사용하여 클라이언트(브라우저)에서 React 컴포넌트를 렌더링 한다. 이때 일반적인 CSR 방식으로 리액트를 실행하면 createRoot()를 사용하여 React 루트를 생성하고, root.render를 호출하여 React 컴포넌트를 표시한다. 그런데 root.render를 처음 호출한다면 React 루트 내부의 모든 HTML 콘텐츠를 지우고 클라이언트에서 렌더링 된 컴포넌트로 교체하는데, 서버에서 렌더링한 HTML 콘텐츠가 있다면 이 과정에서 사라지게 된다. 그럼 어떻게 리액트에서 SSR을 구현할 수 있는 것일까?

그 이유는 HTML 콘텐츠가 담긴 DOM을 바탕으로 리액트를 사용한다면 createRoot()가 아닌 hydrateRoot()를 사용하여 렌더링하기 때문이다. hydrateRoot()를 사용하여 Hydrate를 완료한 후에 root.render를 호출하게 되는데, 그렇다면 기존 HTML을 없애지 않고 HTML 콘텐츠가 담긴 DOM 노드 안에 React 컴포넌트를 넣을 수 있게 된다. 물론 이 작업들은 NextJS에서 호출하고 있기 때문에 별도로 사용하지 않아도 된다.

출처: https://nextjs.org/docs/app/building-your-application/rendering, https://react.dev/reference/react-dom/client

state나 props가 갱신되어 render()가 실행되면서 리액트가 렌더링되면, 리액트는 실제 DOM 구조를 가벼운 자바스크립트 객체로 표현한 가상 DOM(리액트 엘리먼트 트리)을 생성합니다. 그리고 diffing 알고리즘을 통해 변경사항을 O(n)의 복잡도로 파악할 수 있습니다.

알고리즘의 동작원리는 다음과 같습니다.

• 서로 다른 타입의 두 엘리먼트는 서로 다른 트리를 만들어낸다.
• 개발자가 key prop을 통해, 여러 렌더링 사이에서 어떤 자식 엘리먼트가 변경되지 않아야 할지 표시해 줄 수 있다.

두 트리를 비교할 때, 루트부터 비교하며 어떤 변경사항이 있는지를 확인합니다. 이때 만약 루트 노드가 다르면 해당 하위 트리를 모두 새로 렌더링합니다.

노드를 비교할 때에는 타입(이름)과 속성, key를 비교합니다. 엘리먼트의 타입(이름)이 다르다면 완전히 새로운 트리를 구축합니다. <a>에서 <img>로, 혹은<Article>에서 <Comment>로 바뀌는 것 모두 트리 전체를 재구축하는 경우입니다.

두 노드의 타입이 같으면 속성과 자식 요소를 비교합니다. 이때 동일한 내역은 유지하고 변경된 속성들만 갱신합니다. 노드의 비교과정이 끝나면 해당 노드의 자식들을 재귀적으로 탐색하며 처리합니다.

리액트에서 배열의 변경사항을 감지하고 렌더링하는 방식

리액트에서 배열을 사용해서 컴포넌트를 렌더링한다면 리액트는 배열을 순회하면서 요소를 생성하고 반환합니다.

이때 배열에 변경사항이 생겼을 때 리액트는 Virtual DOM과 현재의 배열을 비교하며 변경사항을 확인합니다. 예를 들어 [1,2,3,4,5] 라는 배열이 있을 때, 3을 삭제한다면 리액트는 [1,2,4,5]배열을 순회하면서 비교하게 되는데, [1,2]까지는 기존의 첫번째 두번째 요소와 같지만 [4,5]는 네번째 [3,4]와 다르기 때문에 재조정 과정을 진행합니다.

만약 첫번째 값이 삭제되었다면 배열의 모든 요소를 리렌더링 해야 하는데, 배열 내 모든 요소를 리렌더링하는 것은 효율적이지 않으며, 배열 내부의 값을 비교하기 위해 배열의 모든 값을 확인하면서 변경사항을 체크하는 것도 효율적이지 않습니다.

때문에 리액트는 key를 통해서 배열 내에 어떤 요소가 변경되었는지를 판단하는데, key값이 존재하지 않으면 자동으로 배열의 index를 key값으로 설정합니다.

index를 key값으로 사용할 때의 문제점

이때 배열의 index를 key값으로 사용할 때의 문제점이 발생하는데, 배열의 순서가 바뀌거나 값이 추가/삭제되는 경우 index가 변경될 수 있습니다. 예를 들어 [1,2,3,4,5] 라는 배열이 있을 때, 3을 삭제한다면 리액트는 index가 [0,1,3,4]가 아닌 [0,1,2,3]으로 변경되어 5가 변경되었다고 판단하게 됩니다.

Math.random()을 key값으로 사용할 때의 문제점

또한 key값을 Math.random() 과 같이 매번 변경되는 것을 사용하면 안되는 이유도 이와 같은데, 키를 확인하는 과정에서 key가 매번 변경되기 때문에 배열의 모든 요소가 변경되었다고 판단하여 모든 요소를 재생성하는 효율적이지 않는 동작을 하게 됩니다.

https://ko.react.dev/learn/rendering-lists#why-does-react-need-keys https://ko.legacy.reactjs.org/docs/reconciliation.html#the-diffing-algorithm

사용자가 클릭과 같은 이벤트를 발생해서 UI가 바뀌었다면, 바뀐 UI를 보여주기 위해 DOM이 리렌더링되어야 합니다. 이때 브라우저는 변경된 부분의 DOM 트리를 수정하고 리페인팅과 리플로우 과정을 거쳐 리렌더링 하게 됩니다. 이러한 과정은 많은 비용이 소모되기 때문에 DOM 변경을 최소화하여야 하는데요. 리액트는 Virtual DOM이라는 개념을 사용하여 이러한 과정을 최적화합니다.

리액트는 변경된 DOM이 반영된 자바스크립트로 된 Virtual DOM을 만들고 기존 DOM과 차이점을 비교하여 실제로 바뀐 부분만 교체합니다. 이때 만약 여러 번 DOM을 수정해야 한다면 React Fiber 엔진을 사용해서 한 번에 처리할 수 있도록 최적화를 진행합니다.

SolidJS나 스벨트는 Vitrual DOM을 안 쓰는데 더 빠른데요?

Virtual DOM이 무조건 빠른 것은 아닙니다.

"리액트는 Virtual DOM을 사용하기 때문에 빠르다" 라는 말은 맞기도 하지만 틀리기도 합니다. Virtual DOM을 생성하고 비교하는 과정을 거치기 때문에 직접 DOM을 수정하는 것보다 빠를 수는 없습니다. 다만 Virtual DOM이 빠른 이유는 최적화를 통해 DOM 접근을 최소화하며, 필요한 부분만 DOM을 수정하기 때문입니다.

실제로 DOM 구조가 단순하고 변경 사항이 적은 경우, Virtual DOM의 Diffing 과정이 오히려 성능 부담이 될 수 있습니다. 브라우저 기본 렌더링만으로 충분히 효율적입니다.

스벨트나 SolidJS가 빠른 이유는 Virtual DOM을 사용하지 않는 대신에 컴파일 단계에서 최적화를 하기 때문입니다. 컴파일 단계에서 각 컴포넌트를 분석하여 정적 분석을 수행하고, 필요한 DOM 조작만 수행하도록 최적화해서 리액트보다 빠른 성능을 보여줄 수 있는 것이에요.

Vue.js도 Virtual DOM을 사용하고 있지만, 컴파일 과정에서 Virtual DOM의 최적화를 진행하는 하이브리드 접근 방식(Compiler-Informed Virtual DOM)을 사용하여 더 빠른 성능을 이끌어 냅니다.

그럼 리액트도 컴파일 단계에서 최적화를 하면 되는 거 아닌가요?

컴파일 단계에서 최적화하는 방식에도 단점이 있습니다. 컴파일 단계에서 코드가 변경되기 때문에 코드를 예측하기 힘들 뿐 아니라, 런타임에서 실행되는 코드에 대해서는 최적화를 할 수 없다는 단점이 있습니다. 또한 대부분의 라이브러리가 리액트를 포함한 Virtual DOM을 사용하는 주류 생태계에 맞춰져 있기 때문에 상대적으로 컴파일 단계의 최적화는 라이브러리 호환성이 떨어지게 됩니다.

<자료 출처> https://yozm.wishket.com/magazine/detail/1176/ https://svelte.dev/blog/virtual-dom-is-pure-overhead https://old.million.dev/blog/virtual-dom https://ui.toast.com/posts/ko_20220331 https://itchallenger.tistory.com/822

근속 2년 차 회고를 작성하던 중에 구조조정 통보를 받아 어떻게 회고를 완성해야 하나 고민했지만, 퇴사 과정에서 느낀 많은 것들을 기억하기 위해 해고 회고를 별도로 작성했다. 조금은 아이러니한 상황이지만 나름의 해프닝으로 재밌게 받아들이려 한다.

최근 스타트업 뿐만 아니라 대기업에서도 심심치 않게 구조조정 이야기가 들려왔다. 그럼에도 나는 자사 서비스의 대부분을 담당하고 있었기 때문에 나와는 거리가 먼 얘기라고 생각하고 있었다. 3일 전, 회사에서 모든 사람들을 모아 불가피하게 구조조정을 실시한다고 할 때까지만 해도 나는 아니라고 생각했다. 하지만 당장 매출을 낼 수 없는 자사 서비스는 중단하고 새로운 수익모델과 과제에 집중한다는 이야기를 들었을 때, 그제서야 내가 구조조정 대상자라는 것을 알았다.

그리고 대부분의 직원들은 그날 출근까지만 해도 생각지 못한 퇴사를 해야만 했다. 모두가 입모아 했던 말은 '그동안 너무 안일했다'. 사실 모두가 알고 있었던 듯하다. 회사의 수익모델은 흐릿해져 가고 있었고, 준비중이었던 과제는 명확한 진행사항을 아는 주니어가 없을 정도로 쉬쉬하는 분위기였다. 당장 사인을 하고 퇴사를 해야 한다는 말에 나는 어떻게든 다른 방법을 찾으려 했지만, 이내 단념하고 권고사직을 받아들이기로 했다.

해고 통보를 받은 날, 커피 타임만 연거푸 4번을 가졌다. 함께 회사를 떠나는 사람들과 커피를 마시며 불만과 걱정을 이야기하고, 회사에 남는 사람들과는 그동안 고생했다는 이야기를 했다. 이야기를 마치고 자리에 돌아오면 또다른 사람들이 커피를 마시러 가자고 했다. 그리고 나는 퇴사를 조율하려는 과정에서 당일이 아닌 다음날 권고사직서에 서명을 해야 했는데, 그 다음 날 역시 짧은 시간 동안 수많은 커피를 마셨다.

사실 이 회고에서 적고 싶은 것은 앞으로의 걱정이나 회사에 대한 비난이 아니다. 이틀간 수없이 이뤄진 커피 타임과 식사자리에서 들었던 이야기를 기억하고 싶었다. 퇴사를 명분으로 그동안 낯간지러워하지 못했던 이야기를 주고받았는데, 이것이 나의 퇴사에 대한 기억을 꽤나 아름답게 꾸며주었다.

입사 초기에 뺀질거리던 녀석이, 이제는 제 몫을 하는 사람이 되었다. 어디 가든 잘할 사람이니 걱정하지 않는다. 친해지고 싶은 일잘러였는데, 앞으로 못 보게 되어 아쉽다. 함께 일하는 동안 즐거웠다. 그동안 많은 도움을 주셔서 감사하다. ...

울컥할 정도로 너무나 좋은 말들을 많이 들을 수 있었는데, 무엇보다 내가 회사생활을 꽤 나쁘지 않게 했구나 라는 생각이 들었던 것은 사람들의 아쉬움이 가득 담긴 눈빛이었다.

그리고 이번 퇴사과정에서 들었던 좋은 말들로 인해 새로운 발견을 하기도 했다. 나는 사실 남들의 언행과 행실을 관찰하는 다소 관음적인 취미가 있는데, 그중에서도 능력 있는 사람들을 관찰하며 그 능력의 원천을 탐구하려는 버릇이 있다. 그리고 나는 어떤 능력을 갖고 있을까를 항상 궁금해하며, 나 스스로의 능력을 정의하곤 했었다. 하지만 이번 퇴사 덕분에 사람들이 나를 바라보는 평가를 한꺼번에 들을 수 있었는데, 수많은 평가가 모이는 한 지점에서 이것이 내가 가진 특별한 능력이구나 싶었다.

차분하면서도 적극적으로 의견을 내는 사람, 부드러운 리더십을 가진 사람, 항상 이해하기 쉽게 알려주는 사람, 텍스트에도 따뜻함이 묻어나는 사람.

나는 목소리가 엄청 낮은 편이라, 어렸을 적부터 무엇을 말하든 진중해 보인다는 이야기를 들었다. 가벼운 말을 해도 모두가 진지하게 받아들이는 터라, 어쩔 수 없이 가벼운 언사를 삼가는 사람이 되었다. 또, 나는 누군가를 돕는 것을 좋아했다. 무리지어서 어딘가로 향할 때에는 항상 맨 뒤에 서서 소외된 사람의 옆으로 향했다. 그리고 아무도 소외된 사람이 없을 때에는 하늘이나 거리를 보며 여유를 즐기곤 했다.

내심 기대했던 나의 능력은 개발과 관련된 것이었으면 했다. 남들보다 더 잘하기 위해 꾸준히 개발을 공부하고 노력했는데, 결국 더 도드라지는 능력은 내 성향과 태생에 관한 것이라니. 이 역시 아이러니하지만 동시에 나답기도 하다.

퇴사를 당장 생각해본 적이 없었기 때문에, 내가 회사생활을 잘했는가? 라고 자문할 시간이 없었다. 그럼에도 과분한 평가를 내려주신 동료분들 덕에 기분 좋게 새 시작을 준비할 수 있을 것 같다. 나 역시 이처럼 훌륭한 동료들을 앞으로 만날 수 있을까 싶을 정도로 내게는 과분한 사람들이라 생각한다. 언제 있을지 모를 앞으로의 마무리를 위해서라도, 계속해서 따뜻한 사람이 되도록 노력하려 한다. 물론 나의 이상향을 향한 개발도 놓지 않고.

얼마 전 회식자리에서, 팀장님이 제 칭찬을 하시면서 팀장 회의에서 프로젝트 리드를 맡긴다고 했을 때, 아무도 우려를 표하지 않을만큼 신임받는 사람이라고 말해주셨습니다. 문제가 생기면 가장 먼저 의심받던 MZ 신입사원이었는데, 이제는 내가 많이 변했구나 싶은 생각이 들었습니다.

입사 초반을 돌이켜보면 함께 일했던 분들에게 죄송하다는 말씀을 드리고 싶어요. 책임감없는 태도로 불만만 가득했던 제 모습이 지금도 부끄럽습니다. 지금은 개발실력이 늘었다기 보다는, 어느샌가 사람들을 대하는 태도가 변했고 이전에 비해 성숙해진 모습이 되었다고 느껴져요. 그리고 지금, 취업한지 2년이 좀 넘은 시점에서 그동안의 회사생활에 대한 회고를 해보려고 합니다.

제가 다니는 회사는 자체 서비스를 운영하고 있고, 40명 정도 되는 인원을 가진 작은 스타트업입니다. 입사 초기에는 개발을 잘하고 싶었어요. 개발자는 개발로써 인정을 받는다고 생각했고, 좋은 시니어 밑에서 코드리뷰를 받으면서 성장하고 싶었어요. 그렇지만 제가 입사한 곳의 팀장님은 리액트를 전혀 모르시는 시니어 개발자셨고, 팀의 관리를 위해 임명된 분이었어요. 또, 프론트엔드 팀원은 저 같은 신입 개발자로만 이루어진 신생팀이었습니다. '이런 곳은 성장할 수 없는 회사야!' 라고 생각하면서, 딱 3개월만 일하고 퇴사하자 라면서 첫 직장생활을 시작했어요.

서론이 길었네요. 지금부터는 3개월만 일하고 퇴사한다는 신입사원이 적는 2년 근속 회고입니다.

최고의 복지는 동료

그렇게 책임감 없던 제가 회사를 계속해서 다니게 된건 두가지 이유가 있었어요. 첫번째로는 이직에 성공하지 못한 것입니다. 당연한 일이겠죠. 그동안 계속 불합격만 받던 비전공 신입 개발자가 회사와 병행하면서 준비한다고 성공할 수 있을까요. 그리고 두번째는 지금도 함께하고 있고, 감사드리는 프론트팀을 포함한 동료들 덕분이었습니다. 그 당시에는 '왜 이런 회사에..?' 라고 느껴질만큼 잘한다고 생각했고, 지금도 한명한명 엄청난 능력이 있다고 생각해요. 주니어 개발자로서 함께 성장해나가면서 코드와 지식을 공유하는 경험은 너무나 즐거웠고 도움되는 일이었어요. 과연 앞으로도 이런 팀을 만날 수 있을까? 라는 생각이 들 정도로 제게는 완벽한 팀이었습니다.

특히나 프론트엔드팀은 제가 애정을 갖고 있는데요. 제가 좋아하는 영화인 엑스맨처럼, 저희 팀원들은 모두 특별한 능력을 갖고 있었어요. 기술 트렌드에 밝아 이런저런 기술을 시도해보면서 지식을 공유해주는 분도 있고, 기술 자체에 대한 관심으로 자바스크립트나 브라우저의 동작방식이나 개념을 상세하게 아시는 분도 있었죠. 어떤 분은 정말 다른 레벨의 수준으로 문서작성을 하시고, 심지어 문서 쓰는 것을 즐겼어요. 한번은 그분의 작업들을 인수인계 받게 된 적이 있는데, 문서만 봐도 프로젝트의 흐름과 진행과정을 알 수 있어서 감탄하기도 했어요. 마지막 한분은 모든 사람이 좋아하는 사람이었어요. 그분이 활짝 웃으며 커뮤니케이션하는 모습을 보고 있으면 이것도 다른 레벨이겠구나 싶었어요.

그리고 저는 항상 저희 팀원분들을 유심히 지켜보면서 그 능력들을 가지려 했어요. 팀원 분들이 멋진 히어로라면, 전 마치 원피스의 검은수염 티치 같네요. 기술 트렌드를 컨퍼런스 영상이나 특정 아티클에서 얻는 것을 보고 유명 컨퍼런스들을 챙겨보고, 오프라인 컨퍼런스에 참석해보기도 했어요. 자바스크립트를 포함한 소위 기본기에 대해 잘 알고 계신 분께는 특히 질문을 많이 드렸는데요. 개발 도중 문제가 발생할 때, 동작원리와 흐름에 의거해서 문제를 찾아내는 모습을 보면서 개인적으로 많이 배울 수 있었습니다.

팀원분들의 이런 모습들을 보면서 나는 무슨 능력을 가지고 있을까? 하는 생각도 정말 많이했는데요. 퇴사하는 날, 여러 사람들과 여러번의 식사와 커피타임을 가지면서 제 능력이 무엇인지 알려주셨어요. 이 능력들은 퇴사 회고에 마저 적도록 하겠습니다.

시니어에 대한 존경

좋은 동료들과 회사를 다니게 되면서 크게 느낀점이 또 하나 있는데요. 바로 존경심입니다. 높은 DAU와 화려한 아키텍처, 최신 기술이 좋은 서비스 회사의 지표라고 생각했던 어린 날에는 '이 회사는 배울 것이 없는 곳이야!' 라고 생각했어요. 하지만 알고보니 저같은 MZ 신입사원을 사람구실할 수 있게 만들어줄 만큼 정말 존경스러운 사람들이 모여있는 곳이었습니다.

20년이 훌쩍 넘는 시간동안에도 꾸준히 개발을 공부하시는 시니어분들도 있었고, 마흔이 넘는 나이에도 해외 취업을 위해 영어를 공부하시는 시니어분도 계셨어요. 주니어 분들의 커리어를 위해 진지하게 고민하고 도와주는 모습이나, 감정을 조절하지 못한 채 격앙된 모습을 하는 주니어에게 부드럽게 왜 이렇게 개발이 진행되고 있는지를 알려주는 시니어분들의 모습을 보면 개발자라는 타이틀을 넘어 정말 존경스러운 사람이라고 생각되었어요.

사회 생활에서 배운 얕은 지혜

그리고 짧게나마 사회생활을 하면서 얕게나마 알게된 것도 있습니다. 싫은 사람이 생기면 내가 손해다. 그리고 사람은 누구나 입체적이다. 저는 누군가가 싫어지면 그사람의 행동 하나하나에 신경쓰게 되고, 혼자서 스트레스 받게 되는 것 같아요. 그래서 애초에 누군가를 싫어하지 않는 것이 그 사람을 싫어하는 것보다 좋은 선택임을 알았어요. 사람을 싫어하지 않는다는 것이 말이 안된다싶지만, 사람은 누구나 입체적이라고 생각하니 크게 어렵지는 않았어요. 모두가 좋아하는 사람은 없듯이, 모두가 싫어하는 사람은 없으니까요. 누군가의 단점이 보이기 시작하면, 이 사람의 단점보다 장점을 보려 노력하려고 합니다.

또, 절대 남을 비난하지 말자. 비난에 굳이 동조하지 말자 라는 것도 마음에 새겼는데요. 회사 생활을 하다보면 앞에서든 뒤에서든 남을 비난하는 모습을 종종 볼 수 있죠. 하지만 그럴 때 마다 비난하는 대상보다는 비난하는 사람이 좋지 않게 보이더라구요. 내가 누군가를 비난하면 남들도 나를 그렇게 보겠구나 라고 생각하니, 남을 비난하지 않도록 다짐하게 되었어요. 혹여나 누군가 남을 비난하는 모습을 보더라도, 그 분위기에 휩쓸려서 굳이 비난할 필요도 없는 것 같아요. 그런 상황에서는 대부분 제가 동조하지 않아도 말을 내뱉는 것만으로도 충분히 만족하는 것 같아요.

지금 생각하는 잘하는 개발이란?

개발자끼리 이야기를 하다보면 잘하는 개발은 무엇인가? 라는 주제가 자주 등장하곤 하는데요. 저는 항상 가독성 좋은 코드를 짜는 것이 잘하는 개발이라고 했었는데, 어떻게 해야 가독성 좋은 코드이냐 라고 묻는다면 자세히 답하기가 어려웠습니다. 지금 생각하는 잘하는 개발은 그것과 같은 궤를 하고 있지만, 조금 더 구체적으로 말할 수 있습니다.

회사에서 하는 개발은 지금의 동료 뿐만이 아니라, 과거와 미래의 동료 혹은 자신과 협업을 해야 할 수도 있습니다. 그리고 그 과정에서 쉽게 적응하고 개발하기 좋았던 코드들은 높은 응집도와 낮은 의존성을 가지고 있었습니다. SOLID 원칙처럼 너무 흔하고 당연한 점이지만, 직접 겪어보니 더 크게 와닿더군요. 이미 개발되어 있는 기능과 비슷한 기능을 개발할 때, 낮은 의존성을 가진 컴포넌트를 재조합 하다보면 정말 몇 배로 빠른 개발이 가능했습니다. 앞선 개발자에 대한 존경은 덤이구요. 또, 기존 기능을 수정하거나 유지보수 할 때에면 높은 응집도가 빛을 발했습니다. 어떤 문제가 생겼을 때, 해당 기능의 이름을 가진 폴더 혹은 파일을 찾으면 끝이었으니까요. 수정이 필요한 기능들은 대체로 같은 폴더에 놓여져 있기 때문에 사이드이펙트를 검증할 때에도 큰 어려움이 없었습니다.

불편한 코드를 짜는 것도 잘하는 개발이구나 라고 느끼기도 했는데요. 제가 본 잘하는 개발자분들은 협업을 위해서 일부러 불편한 코드를 짜기도 했었어요. enum이나 zod같은 기능을 사용하기도 하고, 특정 키값들을 constant로 설정하여 한 파일에서 관리하도록 하도록 강제하면서 협업을 하는 사람이 실수하지 못하도록 강제하는 것이죠. 멋있는 말로는 휴먼 에러를 줄이는 것이라고 하더군요.

또, 실무에서 말하는 잘하는 개발에는 코드 만큼이나 중요한 것이 있다고 생각하는데요. 바로 일정에 맞추는 개발입니다. 개발을 할 때마다 협업 과정에서 병목현상이 생기거나 CS(Consumer Service)를 우선적으로 처리해야 하는 일들이 빈번했는데요. 단순히 기능 개발에 필요한 기술이나 분량로는 책정할 수 없는 일정들을 겪으면서 이런 것 까지 맞출 수 있는 개발자가 진짜 잘하는 개발자가 아닐까 싶었어요.

꾸준히 공부하는 방법

2년 간 회사생활을 하면서 제가 자부하고 싶은 점이 하나 있습니다. 바로 꾸준히 공부해왔다는 점인데요. 물론 이런저런 사정으로 짧게는 일주일, 길게는 한달까지 쉴 때도 있었지만, 대체로 개발을 손에서 놓지 않았다고 생각합니다. 제가 이럴 수 있었던 건 함께 공부했기 때문이 아닐까 싶은데요. 저는 매주 일요일마다 봉천역에 있는 청년공간에서 개발 스터디를 하고 있는데요. 그냥 개발자끼리 모여서 각자 하고 싶은 개발을 하는 것입니다. 그리고 그 과정에서 꾸준히 나오는 사람들을 보면서 서로 동기부여를 받기도 하고, 네트워킹도 하다보니, 매주 일요일마다 나가는 것이 어렵지 않게 느껴졌어요.

하지만 각자 공부하다보니 어느순간 내가 재밌어하는 개발만 하게 되었고, 이직이나 회사에서 원하는 지식들과는 거리가 먼 공부를 하게 되더라구요. 때문에 신기술 사용과 같이 내가 재미를 느끼는 개발은 평일에 하고, CS 공부와 같이 필요한 공부는 주말에 하는 것으로 정하기도 했어요.

그리고 이것은 실패에서 배운 경험이기도 한데요. 저는 어떤 목표를 정할 때 너무 큰 목표를 세우는 것보다 작은 목표 여러개를 두는 것이 좋았어요. 사이드 프로젝트 같은 경우를 예를들면 사이드 프로젝트 완성! 을 목표로 세우는 것은 목표를 달성할 때 까지 오랜 시간이 걸리다보니, 보상을 받지 못하는 느낌이 들고, 흥미도 떨어지더라구요. 때문에 언제까지 특정 기능 개발! 과 같이 조금 더 짧은 기간의 구체적인 목표를 세우는 것이 동기부여에도 좋은 기능을 했어요. 작은 목표를 이뤘을 때에도 기분좋게 쉴 수 있기도 했구요.

함께 일하고 싶은 사람이 되자

2년이라는 시간동안 저는 스스로 꽤 많이 성장했다고 생각하는데요. 막상 회고를 적어보니 생각보다 훨씬 더 하고 싶은 말이 많아서 엄청 길어졌네요. 그리고 아직도 다 못다한 이야기가 많은데, 이는 퇴사회고에서 다시 다뤄볼까 합니다. 그래도 이 기나긴 회고를 한 문장으로 요약하라 한다면, *"함께 일하고 싶은 사람이 되자"* 로 정하고 싶어요. 결국 개발을 잘하는 사람이나, 일을 잘하는 사람, 그리고 존경받는 사람들은 결국 함께 일하고 싶은 사람이니까요. 회고라는 것은 사실 다른 사람이 보는 것보다, 미래의 내가 보라고 쓰는 글이라고 생각하는데요. 2년이 지날 무렵의 나는 이런 생각을 하고 있었는데, 3년 혹은 더 이후의 미래의 저는 어떤 생각을 하는지도 문득 궁금해지네요. 그때의 저는 더욱 함께 일하고 싶은 사람이었으면 좋겠습니다.

알고리즘 풀이 시 어느정도 외워두면 편한 패턴들이 있다. 코딩테스트 합격자 되기 도서를 참고하여 작성하였으며, 자바스크립트로 코딩테스트를 준비하는 분들이라면 해당 도서를 한번 쯤 읽어 봄직하다.

스택

• 선입후출(FILO)
• 최근에 삽입한 데이터를 대상으로 연산해야 한다면 스택을 떠올리는 것이 좋다.
• 가장 가까운(최근)이라는 키워드를 보면 스택을 떠올려 봐야 한다.

큐

• 선입선출(FIFO)
• 여러 이벤트가 발생했을 때 발생한 순서대로 처리할 때 큐가 활용된다.
• 성능이 중요한 문제라면 큐를 직접 구현하거나 연결리스트를 직접 구현하여 푸는 것이 좋으나, 난이도가 높지 않다면 굳이 구현하지 않아도 통과할 수는 있다.

// 연결리스트
class Node {
  constructor(data) {
    this.data = data; // 요소의 값
    this.next = null; // 다음 요소를 참조
  }
}
class Queue {
  constructor() {
    this.head = null; // 첫 번째 요소 참조
    this.tail = null; // 마지막 요소 참조
    this.size = 0; // 큐의 길이
  }
  push(data) {
    // 새로운 요소를 생성
    const newNode = new Node(data);
    if (!this.head) {
      // 큐가 비어 있다면 head와 tail을 모두 새로 생성한 요소로 설정
      this.head = newNode;
      this.tail = newNode;
      //  아니면 현재 tail의 next 속성을 새로운 요소로 설정 후 tail이 새로운 요소를 참조하도      록 변경
    } else {
      this.tail.next = newNode;
      this.tail = newNode;
    }
    this.size++; // 큐 길이 증가
  }
  pop() {
    // head가 null이라면 비어 있다는 뜻
    if (!this.head) {
      return null;
    }
    // 두 번째 요소를 head의 참조로 변경하면
    // 자연스럽게 첫 번째 요소가 사라짐
    const removeNode = this.head;
    this.head = this.head.next;
    // 만약 두 번째 요소가 없었다면
    // 큐가 비어 있다는 뜻이니 tail도 null로 설정
    if (!this.head) {
      this.tail = null;
    }
    this.size--; // 큐 길이 감소
    // 삭제된 요소의 값을 반환
    return removeNode.data;
  }

  isEmpty() {
    return this.size === 0;
  }
}

해시

• 해시 함수를 통해 키와 값으로 저장하여 빠른 데이터 탐색이 가능한 자료구조
• 단방향으로 동작하기 때문에 키를 통해 값을 찾을 수는 있지만 값을 통해 키를 찾을 수는 없다.
• 해시를 비교하는 함수도 O(n)이기 때문에 해시를 사용할 때라면 크게 문제가 되지 않는다.

이진 탐색

• 정렬된 배열은 이진탐색을 통해 시간복잡도를 O(logN)으로 낮출 수 있다.
• 배열의 절반을 나누어 중위 값이 목표값보다 크고 작은지를 비교하여 탐색한다.

function binarySearch(sortedArray, target) {
    let left = 0;
    let right = sortedArray.length - 1;

    while (left <= right) {
        let mid = Math.floor((left + right) / 2);

        if (sortedArray[mid] === target) {
            return mid; // 찾은 경우 해당 인덱스 반환
        } else if (sortedArray[mid] < target) {
            left = mid + 1; // 왼쪽 포인터를 오른쪽으로 이동
        } else {
            right = mid - 1; // 오른쪽 포인터를 왼쪽으로 이동
        }
    }

    return -1; // 찾지 못한 경우 -1 반환
}

// 사용 예제
const sortedArray = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
const target = 7;
const result = binarySearch(sortedArray, target);

if (result !== -1) {
    console.log(`타겟 값 ${target}은(는) 인덱스 ${result}에 있습니다.`);
} else {
    console.log("타겟 값을 찾지 못했습니다.");
}

그래프

DFS

깊이 탐색한 다음 되돌아오는 깊이 우선 탐색으로, 하나의 경로를 끝까지 시도해봐야 하는 문제에서 주로 사용된다. DFS에서 시간초과가 발생한다면 BFS를, BFS에서 메모리 초과가 발생한다면 DFS를 시도해보는 것이 좋다.

function solution(graph, start) {
  const result = []
  const list = {};
  const visited = new Set();
  for (const [a, b] of graph) {
    list[a] = list[a] ? list[a].concat(b) : [b];
  }
  function dfs(node, visited, result) {
    visited.add(node); 
    result.push(node); 
    (list[node] || []).forEach((neighbor) => { 
    if (!visited.has(neighbor)) { 
      dfs(neighbor, visited, result);
    }
    });
  }
  dfs(start, visited, result);
  return result; 
}

BFS

넓게 탐색하며 진행하는 너비 우선 탐색으로, 최단거리를 찾아야 하는 문제에서 주로 사용된다.

/** 넓이 우선탐색 */
function solution(graph, start) {
  const result = [start]
  const list = {};
  const visited = new Set();
  for (const [a, b] of graph) {
    list[a] = list[a] ? list[a].concat(b) : [b];
  }

  const queue = [];
  queue.push(start);
  visited.add(start);
  while (queue.length) {
    const node = queue.shift();
    for (const target of list[node] || []) {
      if (!visited.has(target)) { 
        queue.push(target);
        visited.add(target);
        result.push(target);
        }
    }
  }

  console.log(result)
  return result;
}

현재 CRA를 기반으로 만들어진 패키지로 웹뷰 서비스를 배포하고 있는데요. 기존까지는 큰 문제가 없었지만, 클라우드 서버 내에서 빌드를 하게 되면서 빌드시간이 2~3배 증가하는 문제가 생겼습니다. 때문에 빌드시간 단축을 위해 CRA의 Webpack v5에서 Vite 로 Migration을 시도했는데요. CRA에서 Vite로 변경했을 때의 빌드시간과 함께 이때 발생한 문제점에 대해 공유드리려 합니다.

왜 Vite를 사용하나요? Vite는 사전빌드를 거친 후 Native ESM을 사용하여 배포하는데, 개발단계에서는 Go로 작성된 Esbuild를 사용해서 Webpack, Parcel과 같은 기존의 번들러 대비 10-100배 빠른 속도를 제공합니다. 다만, 확장성과 안정성을 위해 배포시에는 Rollup을 기반으로한 사전 빌드를 거칩니다. ⠀ CommonJS를 통하여 빌드할 뿐만 아니라 필요하지 않은 설정까지 포함된 CRA에 비해 Vite는 더 가볍고 빠르기 때문에 최근 CRA보다 Vite를 사용하는 추세입니다.

Vite를 사용하여 빌드한 결과

기존 CRA의 환경변수와 플러그인을 Vite로 변경하고, Vite Migration을 위해 몇가지 수정을 거친 후 테스트를 진행하였습니다.

그 결과 꽤 극적인 결과가 나타났습니다.

• 기존 CRA의 Webpack을 사용한 빌드시간
  • 1 min 35 sec total from scheduled to completion.
• Vite 변경 후 빌드시간 (기존 대비 약 67% 빠름)
  • 31 sec total from scheduled to completion. ⠀
• 기존 CRA의 Webpack을 사용한 클라우드 서버 빌드시간
  • 4 min 8 sec total from scheduled to completion.
• Vite 변경 후 클라우드 서버 빌드시간 (기존 대비 약 57% 빠름)
  • 1 min 47 sec total from scheduled to completion.

구형 브라우저 지원이 필수적인 웹뷰 환경

그러나 여기에는 한가지 간과한 부분이 있었습니다. Vite v5는 네이티브 ES 모듈, 네이티브 ESM의 동적 Import, 그리고 import.meta 을 지원하는 브라우저를 타깃으로 하고 있습니다. (Vite 브라우저 지원 현황)

하지만 웹뷰 특성상 여러 기기에서 사용하기 때문에 오래된 브라우저에 대한 지원이 필수적입니다. 실제로 간혹 Object.fromEntries 와 css gap 속성을 사용하지 못하는 기기로 인해 문제가 생기기도 했습니다.

때문에 @vitejs/plugin-legacy 를 사용하여 오래된 브라우저를 위해 폴리필 해줘야만 하는데요. last 2 versions and not dead, > 0.3% 으로 폴리필 한 결과 다음과 같은 결과가 나타났습니다.

• Vite 구형 브라우저 폴리필 지원 후 빌드시간 (기존 대비 약 24% 빠름)
  • 1 min 12 sec total from scheduled to completion.
• Vite 구형 브라우저 폴리필 지원 후 클라우드 서버 빌드시간 (기존 대비 약 79% 느림)
  • 7 min 24 sec total from scheduled to completion.

클라우드 서버에서 좋지 않은 결과를 보여주는 이유는?

Native ESM를 사용하는 Vite와는 달리, CRA의 Webpack은 CommonJS를 사용하고 있기 때문에 구형 브라우저에 대한 지원율이 높습니다. 하지만 Vite의 경우 더 많은 폴리필을 지원해야 하기 때문에 같은 커버리지를 지원하면서도 상대적으로 빌드 시간이 더 오래 걸리게 되는 것인데요.

그럼에도 로컬 빌드 시 조금 더 빠른 성능을 보여주는 이유는 Vite의 배포 빌드 시 사용하는 Rollup은 Rust로 쓰여진 SWC를 파서로 사용하고 있기 때문에(https://github.com/rollup/rollup/pull/5073)  성능이 좋은 멀티코어 환경에서는 조금 더 빠른 성능을 보여주지만, 성능이 좋지않은 클라우드 서버 환경에서는 매우 느린 결과를 보여주고 있다고 추측합니다.

결론

구형 브라우저까지 지원할 필요가 없는 환경이거나,  멀티코어 성능이 좋은 환경에서 빌드를 해야 한다면 Vite는 좋은 선택이 될 것 입니다. 다만 웹뷰와 같이 많은 사용자에 대한 지원이 필요한 환경이라면 빌드속도를 위해 Vite를 선택하는 것은 그리 효과적이지 않을 수 있습니다.

"프로토타입은 기존 객체를 복제하여 새로운 객체를 생성하는 디자인 패턴으로, 사전에 클래스를 정의해야 하는 클래스 디자인패턴에 비해 객체 생성과정을 단순화 할 수 있다는 장점이 있다." 이처럼 프로토타입 디자인패턴에 대한 설명으로 간단히 이야기할 수도 있다. 자바스크립트의 렉시컬스코프, 클로저, 호이스팅이 어떻게 생겨났는지를 프로토타입 철학을 기반으로 분석한 포스팅을 보고, 좀 더 쉽게 각색하여 서양철학부터 context까지를 간략히 정리하였다.

클래스와 인스턴스로 세상을 구분했던 19세기 이전 서양철학

객체지향 프로그래밍의 주요 개념인 클래스와 인스턴스의 최초의 구분은 플라톤에 의해 제시되었는데, 플라톤은 클래스과 인스턴스를 이분법적으로 명확히 구분했다. 눈앞에 실제로 존재하는 사물(인스턴스)이 있다면 반드시 그것의 본질(클래스)이 존재한다는 것이 플라톤의 주장이었다. 그리고 이러한 본질 세계를 이데아(Idea) 라고 칭하며 현실의 사물은 모두 이데아의 본질을 모방한 것이라 주장했다. 의자로 예를 들자면, 의자 라는 클래스가 있을 때 바퀴달린 의자는 의자 라는 클래스를 모방한(상속받은) 바퀴달린 의자라는 것이다.

그리고 이러한 철학을 물려받은 플라톤의 제자 아리스토텔레스는 세상에는 하나의 보편적인 분류가 있다고 말하며, 이를 통해 세상을 분류하려 하였다. 이때 속성을 가지고 세상을 분류하였는데, 이때문에 돌고래는 어류가 아닌 포유류로 분류되었다. 허파로 숨을 쉬고, 새끼를 낳아 기르기 때문이었다.

이분법적인 서양철학을 반박하는 비트겐슈타인과 prototype

하지만 우리의 일반적인 시각으로는 돌고래는 물에서 살고 헤엄을 치기 때문에 어류가 맞다고 생각할 수 있다. 이처럼 분류의 기준은 문맥에 따라서 달라질 수 있음을 주장하며 나온 것이 프로토타입의 기반이 되는 비트겐슈타인의 의미사용이론이다. 의미사용이론은 '벽돌!' 이라고 하는 말의 의미는 벽돌이 필요할 때에는 '벽돌을 달라!', 벽돌이 떨어질 때는 '벽돌을 조심해!' 와 같이 문맥에 따라 의미가 달라진다는 것이다.

또한 공통된 정의 특성이 없더라도 다양한 방식으로 닮아있을 수 있다는 “가족 유사성”이라는 개념을 정의했는데, 가족 구성원은 다양한 방식으로 서로 닮아 있는 것 처럼, 분류에는 '포유류는 젖을 먹고 허파로 숨을 쉬어야 한다.' 와 같은 공통된 속성이 필요하지 않다는 것이다.

이러한 비트겐슈타인의 의미사용이론, 가족 유사성은 1970년경 철학자 엘렌 로쉬 에 의해 프로토타입 이론(Prototype theory)으로 정리된다.

프로토타입 이론의 주요 특징 CONTEXT

엘렌 로쉬가 정리한 프로토타입 이론은

• 같은 단어라도 어떤 상황(context)에서 접했냐에 따라 달라진다
• 정의로 부터 분류되는 것이 아니라 가장 좋은 보기로부터 범주화 된다. 라는 특징을 가진다.

위 특징은 자바스크립트의 동작원리와 밀접한 관계를 가지는데, 자바스크립트의 특징인 스코프체인, 호이스팅, this, closure이 자바스크립트의 실행 컨텍스트(context)에서 비롯되기 때문이다.

즉, 자바스크립트가 이러한 실행컨텍스트를 가지는 이유는 문맥에서 비롯되는 객체의 의미를 정의하기 위해서이며, 프로토타입 기반의 언어인 자바스크립트가 가지는 특징이 되는 것이다.

3줄요약

1. 프로토타입은 한가지의 보편적인 분류로 의미를 나누는 class와 반대되는 개념이다.
2. 프로토타입 이론은 의미가 문맥(context)에 따라 달라질 수 있음을 주장하는 철학이다.
3. 자바스크립트 프로토타입의 호이스팅, 클로저, 스코프체인 등은 이러한 프로토타입의 문맥(context)을 이해하기 위한 수단이다.

참고자료: 자바스크립트는 왜 프로토타입을 선택했을까 JavaScript : 프로토타입(prototype) 이해 ECMAScript 명세 이해, 1부 [JS] 📚 자바스크립트 실행 컨텍스트 원리