코드잇 스프린트가 끝나고, 취업을 위해 코드잇에서 하는 스터디에 들어가게 되었다.

그 중에서도 내가 신청한 건 바로 기술 면접 !!

 

아무래도 기술 면접은 혼자 공부하는 것보다 같이 공부하는게 필요할 것 같아서 보자마자 바로 신청을 하였다.

일단 1주차는 위클리페이퍼 기반으로 질의응답을 하고 스터디원은 4명이라 2:2로 진행을 하고 있다. 

 

저번에는 내가 면접관으로 2분께 질문을 드렸고, 이번에는 내가 지원자가 되어서 답변을 하는 시간을 가졌다. 

근데 이번에 같이 지원자 파트를 맡으신 분이 결석을 하여서 혼자 질문을 받게 되었다...! (오히려 좋아)

 

면접을 공부할 때 제일 중요한건 끝나고 복기 인것 같다 !! 

대부분의 답변에 잘 답하였지만, 꼬리 질문에서는 모르는 부분도 있어서 모범 답안을 채워서 정리해보았다 :)

 

1. 리액트에서 Virtual DOM이 무엇인지, 이를 사용하는 이유는 무엇인지 설명해 주세요.

 

[나의 답변]

Virtual DOM은 실제 돔이 아닌 실제 돔을 복사한 구조화한 객체입니다. 리액트에서 state나 props의 상태 변화가 일어날 때, 리액트는 실제 돔이 아닌 Virtual DOM에 반영합니다. 이전의 Virtual DOM과 이후의 Virtual DOM을 비교해서 변경사항이 있는 부분만 실제 돔에 반영을 해 업데이트를 합니다. 리액트에서 실제 돔을 다루는 작업은 reflow 나 repaint가 계속 일어나기 때문에 비용이 굉장히 큰 작업입니다. 따라서 이제 리액트에서는 실제 돔이 아닌 Virtual DOM의 변경사항만 반영하는 작업을 통해서 비용을 줄이고 효율적인 렌더링 성능을 향상시키고 있습니다.

 

[꼬리 질문]

1. 리액트 diffing 알고리즘이 어떤 원칙으로 작동하나요?

 

React는 이전 Virtual DOM과 새로운 Virtual DOM을 같은 계층 구조로 비교합니다. 예를 들어 타입이 같인 노드는 속성만 비교 후 변경된 것만 반영하고, 타입이 다른 노드는 해당 노드와 모든 자식 노드를 통째로 교체합니다. key를 사용해 어떤 항목이 변경/추가/삭제 되었는지 추적할 수 있습니다.

 

2. Reconcilation 작업이 어떻게 일어나나요?

 

Reconcilation은 React가 이전의 Virtual DOM과 새로운 Virtual DOM을 비교해서 실제 DOM에 필요한 변경만 적용하는 과정입니다. 같은 타입 노드는 속성만 변경하고, 타입이 다르면 해당 노드 전체를 교체합니다. 리스트는 key로 비교 효율을 높이고, React 16부터는 Fiber 아키텍처를 사용해 작업을 쪼개고 우선순위를 조절합니다.

 

3. React 15 이전과 16부터의 Virtual DOM 아키텍처의 차이는 무엇인가요?

 

React 15 이전에서는 스택 알고리즘을 사용하여 Virtual DOM 트리를 재귀적으로 순회하면서 비교 작업을 수행하였습니다. 이는 동기 렌더링만 가능하고, 한 번 렌더링이 시작되면 중단 없이 끝까지 수행해야 합니다. 16 부터는 Fiber 아키텍처를 도입하여 작업을 쪼개고 우선순위를 조정할 수 있게 됐습니다. 이는 작업 스케줄링이 가능해 더 중요한 작업을 해야 하면 렌더링을 중단하고 나중에 재개할 수 있습니다.

 

2. 리액트 생명주기에 대해서 설명해 주세요.

 

[나의 답변]

리액트의 생명주기는 컴포넌트가 렌더링 되기 전부터, 업데이트가 되고, 소멸될 때까지의 전 과정을 말합니다. class component에서는 componentDidMount, componentdidUpdate, componentWillUnMount 메소드로 생명주기를 다루고, 함수형 컴포넌트에서는 useState와 useEffect를 사용하여서 생명주기를 다룹니다. 특히 useEffect에서 빈 배열을 넣으면, 컴포넌트가 처음 렌더링 될때인 componentDidMount 처럼 사용할 수 있고, useEffect에 cleanup 함수를 이용하면 컴포넌트가 사라질 때인 componentWillUnMount 처럼 사용할 수 있습니다.

 

참고 : 리액트 16 이후에 함수 컴포넌트가 주류가 되면서 공식 문서의 포커스도 생명주기에서 → effect의 라이프사이클로 바뀌었다.

 

[꼬리 질문]

1. useEffect의 의존성 배열은 무엇이고, 빈 배열과 특정 값을 넣었을 때 어떻게 동작하는지 설명해주세요.

 

useEffect에서 의존성 배열을 생략하면, 렌더링 될 때마다 effect가 실행되고 빈 배열이면 마운트 시 1번만 실행이 되고, 특정 값을 넣으면 의존성이 변경될 때마다 effect가 실행됩니다.

 

2. useEffect는 그럼 언제 실행이 되는건가요?

 

useEffect는 브라우저가 DOM 업데이트를 완료한 뒤, 화면이 실제로 그려지고 나서 실행됩니다. 즉, 렌더링 결과가 커밋된 이후 비동기적으로 실행되며 렌더링 중에는 실행되지 않습니다. 의존성 배열에 따라 마운트 시 한번, 특정 값 변경시 , 또는 매 랜더마다 실행될 수 있습니다.

 

3. 웹페이지 렌더링 방식 csr ssr ssg 각각의 특징과 각 방식을 어떻게 사용하면 좋을지에 대해서 설명해 주세요.

 

[나의 답변]

CSR은 서버가 최소한의 HTML만 내려주고, 브라우저가 이 JS를 실행해서 클라이언트에서 렌더링하는 방식입니다. HTML만으로는 내용이 없기 때문에 첫 화면 표시가 느리고, SEO에 불리하지만 한번 로딩 후에는 페이지 전환이 매우 빠릅니다. CSR 같은 경우에는 로그인 페이지 같은 SPA 어플리케이션에 적합합니다. SSR은 완성된 HTML을 서버에서 브라우저로 내려주는 방식입니다. SSR 같은 경우에는 초기 로딩 속도가 빠르고 서버에서 검색엔진이 바로 내용을 읽을 수 있어 SEO에 유리하며, 페이지 간 이동이 느립니다. SSR은 SEO랑 초기 로딩 속도가 중요한 랜딩 페이지나 쇼핑몰 사이트에 적합합니다. SSG는 빌드 시에 HTML이 생성되는 방식으로, 매우 빠른 초기 로딩 속도와 SEO가 좋지만, 동적 데이터 처리가 어렵다는 단점을 가지고 있습니다. 이 단점을 해결하기 위해 ISR을 이용해 주기마다 페이지를 재생성해주는 방법이 있습니다. SSG는 데이터 변화가 많이 없는 사이트에 적용하기 적합합니다.

 

[꼬리 질문]

1. CSR에서 느린 초기 로딩 속도를 개선하는 방법에는 어떤 것들이 있나요?

 

코드 스플리팅을 이용하여 초기 로딩 속도를 개선할 수 있습니다. 코드 스플리팅은 애플리케이션의 JS 번들을 여러 조각으로 나눠서, 필요한 시점에만 해당 코드 조각을 로드하는 기법입니다. 예를 들어서, 로그인 페이지에 필요한 컴포넌트는 로그인 페이지에 진입했을 때만 로드하면, 초기 번들 크기를 줄여 첫 화면 로딩 속도를 개선할 수 있습니다. React에서는 React.lazy와 Suspense를 사용해 쉽게 구현할 수 있습니다. 또 다른 방법으로는 이미지 최적화가 있습니다. 이미지 최적화는 사용자가 보는 이미지를 더 작은 용량과 적절한 해상도로 제공해 로딩 속도를 개선하는 방법입니다. WebP나 AVIF 같은 포맷을 사용하고 srcset과 sizes를 통해 기기 해상도에 맞는 이미지를 제공하면 불필요한 데이터 전송을 줄일 수 있습니다. 또한 스크롤 시점에만 이미지를 불러오는 Lazy Loading을 적용하면 초기 네트워크 부하를 크게 줄일 수 있습니다.

 

2. lazy loading에 대해서 개념적으로 설명해주실 수 있나요?

 

Lazy loading은 리소스를 필요한 시점에만 불러오는 기법입니다. 처음 페이지가 로드될 때 모든 리소스를 한번에 가져오지 않고, 사용자가 해당 리소스를 필요로 하는 순간에 네트워크 요청을 보내서 불러옵니다. Lazy loading은 코드, 이미지, 데이터 요청 모두에 적용할 수 있으며 주로 성능 최적화와 UX 향상을 위해서 사용합니다.

 

4. Next.js에서 SSR을 실행하는 과정과 hydration에 대해 설명해 주세요.

 

[나의 답변]

SSR은 서버에서 HTML을 미리 생성해서 클라이언트에 전달하는 방식입니다. 사용자가 페이지를 요청하면 Next 서버는 필요한 데이터를 먼저 가져와 React 컴포넌트를 HTML로 변환해 전송합니다. 브라우저는 이 HTML을 즉시 렌더링하고, 이 상태에서는 사용자 인터렉션이 불가능한 상태입니다. 이후에 로드된 JavaScript가 하이드레이션 과정을 거쳐 서버에서 만든 HTML과 React 컴포넌트를 연결하고 이벤트 상태를 활성화합니다. 이로써 초기 화면은 빠르게 표시되고, 이후에는 클라이언트에서 동적 업데이트가 가능합니다.

 

[꼬리 질문]

1. Pages Router와 App Router가 Hydration 하는 방식이 다르다는 것을 알고 계신가요?

 

Pages Router는 페이지 전체가 클라이언트 컴포넌트처럼 동작을 하기 때문에, getServerSidePropsd나 getStaticProps를 이용하여서 전체 하이드레이션이 일어납니다. App Router는 기본이 서버 컴포넌트라 “use client”가 붙은 컴포넌트만 JS를 내려받고 선택적으로 하이드레이션이 일어납니다. 또한 App Router에서는 컴포넌트들을 Suspense로 감싸면, 해당 컴포넌트가 준비되는 시점에만 하이드레이션을 할 수 있습니다.

 

2. CSR이나 SSR을 선택할 때, 어떤 상황에 SSR을 사용하고 어떤 상황에 CSR을 사용하면 좋을까요?

 

SEO나 초기 로딩 속도가 중요한 페이지일 때는 SSR을 사용합니다. 랜딩 페이지나 블로그, 상세 페이지처럼 첫 화면 콘텐츠가 빨리 보여야하는 경우에 적합합니다. CSR은 SEO가 필요 없고 상호작용이 많은 화면에서 적합합니다. 대시보드나 마이페이지처럼 빠르게 화면을 갱신하는 경우에 적합합니다. 또한 상단 핵심 영역만 SSR로 빠르게 보여주고 하위 영역은 CSR로 스켈레톤을 쓰는 하이브리드 전략도 많이 사용합니다.

 

3. 초기 로딩 속도가 SSR이 빠르다고는 하지만, SSR이 실행되기 전에는 흰 화면을 보여주는데 그러면 오히려 로딩 스피너나 스켈레톤 같은 사용자 경험 측면에서 CSR이 더 낫지 않을까요?

 

SSR이 무조건 초기 로딩 속도가 빠르다고 보기는 어렵습니다. 요청 시점에 비동기 데이터가 많으면 지연이 생겨 오히려 CSR 보다 늦을 수 있다고 생각합니다. 그래서 거의 변하지 않는 콘텐츠라면 SSR보다 SSG가 더 낫고, 상단 주요 콘텐츠는 SSR/SSG로 보여주고 나머지는 CSR로 지연 로딩을 하는 하이브리드 전략을 쓰는 방법도 있습니다.

 

5. JavaScript만 사용하는 것과 비교해 TypeScript를 사용하는 이유에 대해 설명해 주세요.

 

[나의 답변]

TypeScript는 JavaScript에 정적 타입 검사 기능을 추가한 점진적 타입 시스템을 제공합니다. 타입을 명시하지 않아도 초기값을 보고 타입 추론을 통해 오류를 예방할 수 있고, 필요하면 명시적으로 타입을 선언하여 컴파일 시점에 오류를 발견할 수 있습니다. JavaScript와 비교를 한다면 컴파일 단계에서 타입 오류를 잡아 런타임 에러를 줄이고 존재하지 않는 프로퍼티 접근이나 잘못된 인자 타입 전달을 미리 경고합니다. 그리고 명시적 타입 덕분에 협업 시에 코드의 의도를 명확히 전달할 수 있고, 대규모 프로젝트에서도 리팩토링이 안전합니다.

 

[꼬리 질문]

1. 그러면 TypeScript의 동작 원리에 대해서 설명해주실 수 있으신가요?

 

TypeScript는 런타임에서 직접 동작을 하지 않고, 컴파일 단계에서 JavaScript 코드로 변환이 됩니다. 파싱 단계에서 .ts 파일을 읽어서 TypeScript AST를 생성하고, 그 다음에 타입 검사가 이루어져서 AST를 기반으로 모든 식과 변수, 함수 호출 등이 타입 규칙에 맞는지 확인합니다. 그리고 트랜스파일을 통해서 JavaScript 코드로 변환됩니다. 이후 JavaScript 코드가 브라우저나 Node.js에서 실행이 되고, 여기서 비로소 JS 엔진이 바이트코드로 변환되어서 실행이 됩니다.

 

6. 리액트에서 배열을 렌더링할 때 key를 써야 하는 이유에 대해 설명해 주세요.

 

[나의 답변]

리액트에서 배열을 렌더링할 때 Key를 쓰는 이유는 각 항목을 고유하게 식별하기 위해서 입니다. 만약 key가 없거나 중복이 된다면, 리액트는 항목을 제대로 구분하지 못해 불필요하게 컴포넌트를 재생성하거나 상태를 잃을 수 있습니다. key를 올바르게 지정하면, 항목의 추가/삭제/이동 시 변경된 부분만 효율적으로 업데이트할 수 있어 렌더링 성능과 상태 보존 측면에서 이점이 있습니다. 또 이제 key값에 index를 넣으면 항목 순서가 바뀌거나 중간 삽입 시 컴포넌트 상태가 잘못 매칭될 수 있기 때문에 백엔드에서 내려주는 고유 id를 사용하는 것이 권장됩니다.

 

[꼬리 질문]

1. 만약 백엔드에서 id 값이 내려오지 않는다면 어떻게 활용할 수 있을까요?

 

nanoid나 uuid 라이브러리를 이용해서 키를 만드는 방법도 있고, useRef로 current 값을 ++ 하면서 id값을 증가하게 하는 방법도 있습니다.

 

꼬리 질문에서 내가 예상치 못했던 질문들도 많이 받았는데, 이래서 더더욱 기술면접은 스터디가 필수인 것 같다.

CSR, SSR 부분이랑 Virtual DOM을 비교하는 재조정, diffing 알고리즘 부분을 딥다이브 책으로 다시 공부해 봐야겠다.

특히나 나는 면접 때 엄청 긴장하는 편인데, 스터디가 많은 도움이 될 것 같다 !! 

'CS' 카테고리의 다른 글

[CS] 프론트엔드 렌더링 방식 : CSR, SSR, SSG, ISR  (2) 2025.07.25
[CS] 세션 기반 인증과 토큰 기반 인증 (+인증, 인가)  (0) 2025.07.15
[CS] SEO란 무엇이고, 어떻게 하면 개선할 수 있을까?  (0) 2025.07.13
[CS] CORS(Cross-Origin Resource Sharing)란 무엇일까?  (1) 2025.07.02

티스토리툴바