2025-01-13(면접카타)

Q. 브라우저의 렌더링 과정에 대해 설명해주세요.

브라우저 렌더링은 HTML,CSS,Javascript 등의 웹 페이지 자원을 브라우저가 화면에 그리는 과정입니다.

렌더링 과정은 다음과 같습니다.

1. DOM 생성 : 브라우저는 HTML을 파싱하여 DOM 트리를 생성

2. CSSOM 생성 : css를 파싱하여 CSSOM 트리를 생성

3. 렌더 트리 생성 : DOM과 CSSOM을 결합하여 실제 화면에 표시될 요소만 포함된 렌더 트리를 생성

4. 레이아웃 : 렌더 트리를 기반으로 각 요소의 크기와 위치를 계산

5. 페인팅 : 레이아웃 정보를 바탕으로 화면에 요소의 배경, 테두리, 글자 등을 그림

위에 과정들이 완료되면 최종적으로 화면에 웹 페이지가 표시됨

 

꼬리질문. 렌더 트리 생성시 어떤 요소들이 제외되나요?

화면에 표시되지 않는 요소들은 제외됩니다. 예를 들어, display: none, visibility: hidden등이 렌더 트리에 포함되지 않습니다.

 

꼬리질문. 브라우저 렌더링 성능을 최적하기 위한 방법은 무엇이 있을까요?

불필요한 css 규칙을 제거하여 스타일 최적화를 하고, 이미지를 최적화하는 방법도 있습니다.

 

Q. 프로덕트의 퀄리티를 올리자니 데드라인을 지키지 못할 것 같고, 데드라인을 지키자니 프로덕트의 퀄리티가 떨어지는 상황일 때, 어떤 부분에 좀 더 중요도를 둘 것인가요? (프로덕트 퀄리티 vs 데드라인)

프로덕트의 퀄리티와 데드라인 사이에서 균형을 맞추는 것이 중요하다고 생각합니다. 고객사에 양해를 구한뒤, MVP의 우선순위을 팀원들과 의논해서 정합니다. 그리고 높은 우선순위를 구현할 때는 퀄리티를 최대한 유지하면서 데드라인에 맞춰 진행하겠습니다. 이후에는 리팩토링을 통해 프로덕트의 퀄리티를 더욱 높이는 작업을 진행할 것입니다. 이렇게하면, 최대한 퀄리티를 유지하면서 데드라인에 맞출 수 있다고 생각합니다.

 

Q. 기능구현할 때 특정 기술스택을 선택해야 했던 경험이 있다면 어떤 과정을 통해 기술스택을 선택했는 지 설명해 주세요.

현재 진행중인 프로젝트에서 청년 정책 api를 호출하는 로직을 구현할 때, 기본 fetch 방식으로는 매번 데이터를 새로 요청하고, 캐싱이나 상태 관리에 어려움이 있었습니다.

이는 불필요한 API호출로 서버 부하를 증가시키고, 사용자 경험에도 영향을 미쳤습니다.

이 문제를 해결하기 위해 tanstack query를 선택했습니다. tanstack query는 데이터 캐싱, 자동 리페치, 페이지네이션등 여러 기능을 내장하고 있어, 이미 불러온 데이터를 재요청 없이 빠르게 제공하고, API 호출 횟수를 줄일 수 있습니다. 이를 통해 성능과 사용자 경험을 개선할 수 있다고 생각되어 tanstack query를 선택하게 되었습니다.

 

Q. 제어컴포넌트와 비제어컴포넌트의 장단점에 대해 설명해주세요.

제어 컴포넌트는 리액트의 상태와 UI를 완전히 동기화하여 DOM을 제어 할 수 있지만, 폼의 모든 필드를 개별적으로 관리해야 할때 로직이 복잡해질 수 있으며, 상태 업데이트로 인해 불필요한 재렌더링이 발생해 성능 이슈가 있을 수 있습니다.

비제어 컴포넌트는 상태를 관리할 필요가 없어 로직이 간단하고, 재렌더링이 발생하지 않으므로 성능상 이점이 있지만, 상태 관리나 제어가 어려워 실시간 검증이나 동적인 로직을 구현하기 어렵다는 단점이 있습니다.

 

꼬리질문.  비제어 컴포넌트는 특정 시나리오에서 어떤 상황에 유리할까요?

비제어 컴포넌트는 상태를 관리할 필요가 없고, 폼 데이터가 크게 변화하지 않는 경우나, 외부 라이브러리와 연동이 필요한 경우 유리합니다. 예를 들어, 대량의 데이터를 빠르게 처리해야 하거나, 폼에서 간단한 입력만 필요할 때 성능상의 이점을 얻을 수 있습니다.