내일배움캠프 76일차 (2차 모의면접)

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

사용자가 URL을 입력하면 브라우저는 DNS 서버를 통해서 해당 URL에 대응되는 IP 주소를 얻어온 후에 HTTP 요청을 통해 서버와의 연결을 시도하고 서버는 그에 대한 응답으로 HTML, CSS, JavaScript 파일을 보내주게 됩니다. 브라우저는 먼저 HTML 파일을 읽어서 DOM 트리를 생성하고, CSS 파일 및 style 태그의 내용을 파싱하여 CSSOM 트리를 생성한 후에 이 둘을 결합하여 렌더 트리를 생성합니다. 각 노드들의 위치와 크기를 계산하고 계산된 레이아웃을 기반으로 화면을 그리는 과정을 거친 후에 최종적으로 사용자에게 보여지게 됩니다.

 

 

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

회사에서의 업무를 생각하면 기획이나 영업 등 다른 분야의 업무들과 연결되기 때문에 1차적으로는 데드라인을 지키는 것이 더 중요하다고 생각하지만, 그 과정 속에서 업무의 우선순위를 명확하게 설정함으로써 정해진 기간 안에 최상의 퀄리티를 만들어 낼 수 있도록 노력해야 한다고 생각합니다.

 

 

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

회원가입과 로그인을 구현하는 과정에서 React Hook Form과 Zod를 사용한 경험이 있습니다. 사용자의 입력 값이 변경될 때마다 실시간으로 유효성 검사를 해주어야 하는데, useState를 이용해도 구현은 가능하지만 이럴 경우 제어 컴포넌트가 되면서 state 값이 변경될 때마다 리렌더링이 발생하기 때문에 성능이 저하될 수 있습니다. 하지만 React Hook Form과 Zod를 사용하게 되면 비제어 컴포넌트를 기반으로 동작하면서도 실시간 유효성 검사 또한 구현이 가능하기 때문에 선택을 하게 되었습니다.

 

 

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

제어 컴포넌트는 입력 값을 state로 관리하기 때문에 입력 값을 실시간으로 추적할 수 있고 그에 대한 즉각적인 피드백과 동적인 로직 구현이 가능하지만, 입력 값이 변경될 때마다 리렌더링이 발생하기 때문에 입력해야할 데이터가 많아지게 되면 성능이 저하될 수 있습니다.
비제어 컴포넌트는 입력 값을 state로 관리하지 않고 DOM을 참조하여 직접 처리하기 때문에 성능적으로 우수하지만, 입력 값에 대한 추적이 어렵기 때문에 동적인 로직을 구현하는 것이 복잡하고 유효성 검사와 같이 즉각적인 피드백이 필요한 기능을 구현하기 위해서는 추가적인 도구가 필요합니다.

 

 

리팩토링을 통해 코드의 가독성을 높인 경험이 있다면 말씀해주세요.

react 프로젝트에서 styled-components를 사용한 적이 있습니다. 처음에는 스타일 코드, UI 코드, 그리고 비즈니스 로직 코드까지 모두 하나의 jsx 파일에 작성을 했었는데 기능이 구현되어 갈수록 자연스럽게 코드의 길이가 길어졌고 가독성이 떨어진다는 느낌이 들었습니다. 그래서 스타일, UI, 비즈니스 로직을 각각의 파일로 분리해서 하나의 파일이 하나의 역할을 담당하게끔 해줌으로써 가독성을 높일 수 있었습니다.

 

 

Next.js에서 라우트 핸들러를 사용했던 경험과 장단점에 대해 설명해주세요.

일단 route handler는 별도의 서버나 추가 설정없이 파일 기반 라우팅 시스템으로 API 엔드포인트를 정의할 수 있고, 서버리스 아키텍처와 결합하여 사용자의 요청이 있을 때만 함수를 실행하기 때문에 서버를 유지 관리할 필요가 없고 사용되지 않을 때는 리소스를 소비하지 않는다는 장점이 있습니다. 하지만 서버리스 함수 특성상 콜드 스타트라는 한계점이 있어 사용자 경험이 저하될 수 있습니다.
지금까지 진행했던 프로젝트들의 경우 server action만으로도 충분히 서버 사이드 로직들을 구현할 수 있었기 때문에 실질적으로 route handler를 사용해본 경험은 없지만, 하나의 앤드포인트에서 여러가지 HTTP 메서드를 처리해야 하는 경우 route hadler를 사용하는 것이 효과적이지 않을까 생각합니다.

 

 

개발자 혹은 디자이너와 협업하면서 의견 충돌이 있었던 경험이 있다면 어떻게 해결하셨는지 설명해주세요.

이전 회사에 재직할 때 Chart.js라는 라이브러리를 사용해서 그래프를 구현했었는데 디자이너분께서 추가적인 UI 작업을 요청하셨던 적이 있습니다. 하지만 해당 UI를 구현할 수 있는 방법을 Chart.js에서 제공을 해주지 않았고 직접 구현하기에는 많은 시간이 소요될 것으로 예상되었기 때문에 팀원들과 의논해본 결과 정해진 기한 내에 구현이 불가능할 것이라는 판단이 들어서 디자이너분께 얘기를 드렸습니다. 다행히 이해를 해주셨고 Chart.js를 사용해서 구현이 가능한 범위 내에서 다시 디자인을 해주시기로 하였습니다.
의견 충돌이 있다는 것은 결국 정해진 정답이 없다는 것을 뜻하기 때문에 내 의견이 받아들여지지 않는다고 생각하는 것이 아니라 각각의 팀 구성원들이 논리적인 이유를 근거로 자신의 의견을 피력하는 과정을 거쳐서 가장 효율적인 방법을 선택할 수 있도록 노력해야 한다고 생각합니다.

 

 

가장 최근에 진행한 프로젝트는 어떤 프로젝트였나요? 프로젝트의 주제와 기술 스택, 본인이 맡은 기능과 로직에 대해서 설명해주세요.

최근에 AI 서비스를 활용해서 사용자에게 맞춤 전통주를 추천해주는 프로젝트를 진행하였습니다.
Next.js를 사용해서 프론트엔드와 백엔드를 하나의 프로젝트에서 관리를 하였고, 데이터베이스로는 supabase를 사용하였습니다. 클라이언트 상태 관리를 위해 zustand, 서버 상태 관리를 위해 tanstack query를 사용하였고, 주요 기능을 구현하기 위해서 AI API와 카카오 지도 API 등 외부API를 활용하였습니다.
여러 가지 기능 중에서 저는 회원가입과 로그인 기능을 메인으로 담당하였고, 로그인 여부에 따라 로직이 달라지는 부분이 곳곳에 있었기 때문에 팀원들이 로그인 여부나 유저 정보를 문제없이 가져다 쓸 수 있도록 처리하는 것에 많은 시간을 투자하였습니다. 또한 이와 관련된 기능들인 소셜 로그인, 비밀번호 재설정, 회원 탈퇴 등의 기능도 구현하였습니다.

 

 

전통주와 음식 페어링 기능을 제공한다고 하셨는데, 사용자가 특정 전통주를 선택했을 때 해당 전통주에 가장 잘 어울리는 음식을 추천하는 알고리즘은 어떤 방식으로 구현되었는지 설명해주세요.

어떠한 알고리즘을 사용했다기 보다는 데이터를 수집해서 데이터화 시킨 후에 사용자에게 보여주는 방식으로 구현을 하였고 데이터를 수집하는 과정에서 AI 서비스를 이용하였습니다.
처음에는 전통주의 종류는 500여가지가 되는데 정작 페어링 음식은 10가지 정도의 음식 내에서 추천을 해주는 결과가 나타났고, 사용자 입장에서는 별다른 특색 없이 비슷한 음식을 추천해준다는 느낌을 받을 수 있다고 생각하였습니다. 그래서 저희가 임의로 30가지 정도의 음식을 정하고 전통주의 도수나 맛, 바디감 등 좀 더 상세한 정보를 바탕으로 추천을 해주도록 유도함으로써 추천 결과가 다양해질수 있도록 노력하였고, 술마켓이나 술담화 등 다른 전통주 관련 서비스도 참고를 해서 데이터 수집을 완료하였습니다.

 

 

전통주 관련 이미지와 콘텐츠를 로딩할 때, 사용자 경험을 고려한 최적화 전략은 무엇이었으며 이를 구현하는 과정에서 어떤 기술적 선택을 했는지 설명해주세요.

Next.js에서 제공하는 Image 컴포넌트를 사용해서 이미지 자체를 최적화한 것도 있지만, 사용자 경험의 관점에서 생각했을 때 이미지가 아직 로드되지 않았을 때는 여기에 이미지가 들어갈 것이라는 것을 명확하게 알려주면서도 최대한 빨리 이미지가 보여지게 해주는 것이 가장 좋은 최적화 전략이라고 생각했습니다.
그래서 placeholder 블러와 스켈레톤 UI를 적절하게 사용했고 레이지 로딩을 통해 최대한 빨리 사용자에게 컨텐츠가 보여질 수 있게 처리해주었습니다. 또한, 모든 이미지에 alt 속성을 명시해줌으로써 화면 리더기와 같은 도구를 사용하는 사용자들의 경험도 향상시킬 수 있도록 노력했습니다.

 

 

TanStack Query의 stale-while-revalidate 로직에 대해서 설명해주세요.

stale-while-revalidate는 사용자에게 데이터를 최대한 빠르게 보여주면서도 데이터의 최신성을 유지하기 위해 데이터 검증 및 동기화를 지속적으로 수행하는 효율적인 캐싱 전략입니다.

데이터가 stale하다는 것은 해당 데이터가 캐시에 존재하지만 더 이상 최신 데이터가 아님을 의미합니다. 사용자의 요청이 발생했을 때 캐시된 stale한 데이터가 있으면 이를 화면에 즉시 보여줌으로써 사용자 경험을 향상시키는 동시에 백그라운드에서 서버에 최신 데이터를 요청하고, 서버로부터 응답이 오면 이를 캐시에 저장하고 UI를 업데이트하여 사용자에게 최신 정보를 제공합니다.

이처럼 사용자 경험을 향상시키면서 데이터의 최신 상태 또한 보장할 수 있다는 장점이 있지만, 백그라운드에서 불필요한 요청이 과도하게 발생하지 않도록 staleTime과 cacheTime을 적절하게 설정해주는 것이 중요합니다.