로그인 후 이용해주세요.
옥스턴님의 면접 결과
60
총점
3
질문 수
0
좋아요
10
조회수
종합 평가
전반적으로 React 생태계의 상태 관리에 대한 이해도가 높고, 각 기술의 장단점을 실무 관점에서 잘 파악하고 계십니다. 특히 Props Drilling 문제를 useContext, Redux, Zustand로 이어지는 해결책의 진화 과정을 체계적으로 설명하신 점과, Zustand의 pub/sub 패턴 기반 동작 원리를 정확히 이해하고 계신 점이 인상적입니다. 다만 Flux 아키텍처 설명에서 Dispatcher의 역할을 단순히 "데이터를 뿌려주는" 것으로 표현하신 부분은 아쉬우며, Action Creator와 Store 간의 관계, 그리고 View에서 다시 Action으로 이어지는 순환 구조에 대한 설명이 보완되면 좋겠습니다. 앞으로는 아키텍처 패턴의 각 컴포넌트가 갖는 구체적인 책임과 상호작용 방식을 더 깊이 학습하시고, 실제 코드 레벨에서 이러한 패턴들이 어떻게 구현되는지 직접 구현해보시길 권합니다.
질문별 상세 분석
프롭스 드릴링이 무엇이고, 이를 해결하기 위해선 어떻게 해야 할까요?
응답 내용
Props drilling이란 자식 컴포넌트로 props가 계속 전달되는 상황입니다. 조산 컴포넌트에 선언된 props를 자손 컴포넌트에서 사용하고자 할 때 부모 컴포넌트는 자식 컴포넌트에게 props를 전달해야 합니다. 하지만 자식 뿐 아니라 자손 컴포넌트에서도 해당 props가 사용되어야 할 때 깊이가 여러단계일 수 있습니다. 이렇게 되면 자식 컴포넌트에게 반복적으로 props를 전달해야 되는데 이를 props drilling이라고 합니다. React는 이런 문제를 해결하기 위해 useContext라는 훅을 재공합니다. 컨텍스트는 전역적으로 어떤 컴포넌트에서도 접근이 가능한 공간입니다. 그래서 부모 컴포넌트는 컨텍스트에 props를 저장하고, 자식은 컨텍스트에서 바로 해당 데이터를 꺼내 쓸 수 있기 때문에 props drilling이 발생하지 않습니다. 하지만 useContext는 프로젝트 규모가 커지면 상태관리 및 추적이 어려워지고, 하나가 바뀌면 관련 없는 모든 컴포넌트들이 리렌더링 되는 등 대규모 프로젝트와 맞지 않습니다. 그래서 나온것이 Redux 입니다. Redux는 메타가 발표한 Flux 아키텍처의 구현체 입니다. 상태관리 및 추적이 원활하고 미들웨어를 사용해서 api 호출이 완료된 후 상태를 업데이트 하기에 용이했습니다. 하지만 사용법이 너무 어려워서 최근에는 서버상태는 tanstack query로, 클라이언트 상태는 Zustand와 같은 가벼운 도구를 사용하는 추세입니다.
AI 피드백
Props drilling의 개념과 Context API를 통한 해결 방법을 정확히 설명해주셨고, Redux와 Flux 아키텍처, 그리고 최신 상태관리 라이브러리들까지 폭넓게 다뤄주신 점이 매우 좋았습니다. 다만 Redux에 대한 설명에서 작은 오류가 있는데, Redux는 Meta(Facebook)가 아닌 Dan Abramov가 개발한 Flux 아키텍처의 구현체입니다. Context API의 단점으로 언급하신 "관련 없는 모든 컴포넌트들이 리렌더링 되는 문제"는 Context를 적절히 분리하거나 React.memo를 활용하면 해결할 수 있으니, 이런 최적화 기법들도 함께 학습해보시면 더욱 완성도 높은 답변이 될 것 같습니다. 전반적으로 실무 경험이 잘 녹아든 훌륭한 답변이었습니다.
Flux 아키텍처의 핵심 동작 원리는 무엇인가요?
응답 내용
Flux 아키텍처는 데이터가 한 방향으로 흐른다는 핵심 원칙을 고수 합니다. Action, dispatcher, store, view 순으로 이동 되는데, action에는 type과 payload가 들어갑니다. Dispatcher는 type을 보고 적절한 store로 데이터를 뿌려줍니다. Store는 action을 받아서 payload의 내용에 따라 상태를 업데이트 합니다. 그리고 최종 결과를 view에 반영하는데 이 view가 리액트에서는 컴포넌트라고 보면 됩니다.
AI 피드백
Flux 아키텍처의 단방향 데이터 플로우 원칙과 Action → Dispatcher → Store → View의 흐름을 정확하게 설명해주셨고, 각 구성 요소의 역할도 명확하게 이해하고 계시는 것 같습니다. Action의 type과 payload 구조, 그리고 View가 React 컴포넌트에 해당한다는 설명도 적절했습니다. 다만 Dispatcher의 역할을 좀 더 구체적으로 설명하면 더 좋을 것 같은데, Dispatcher는 단순히 데이터를 뿌려주는 것이 아니라 모든 Action을 받아서 등록된 모든 Store에게 순차적으로 전달하는 중앙 허브 역할을 한다는 점을 추가하시면 좋겠습니다. 또한 Store에서 상태가 변경되면 View에 변경 사실을 알리는 이벤트 발생 과정이나, View에서 사용자 상호작용으로 다시 Action이 생성되는 순환 구조에 대해서도 언급하시면 더 완성도 높은 답변이 될 것 같습니다.
Zustand의 상태 관리 방식은 어떤 원리로 동작하나요?
응답 내용
Zustand는 리액트 컴포넌트의 라이프사이클에서 벗어나 순수 자바스크립트 객체로 상태를 관리합니다. 변경은 pub/sub 구조를 활용합니다. 스토어를 생성하면 독립적인 스토어 객체가 생성되고, 컴포넌트에서 useStore를 하면 해당 컴포넌트가 구독 상태가 됩니다. 상태를 업데이트 하면 구독중인 컴포넌트들에 알림을 보냅니다. 해당 컴포넌트들은 상태변화에 따른 렌더링이 필요할 경우 렌더링하고, 필요치 않을 땐 그냥 넘어갑니다.
AI 피드백
Zustand의 핵심 동작 원리를 pub/sub 패턴과 순수 자바스크립트 객체를 통한 상태 관리로 정확하게 설명하셨고, 컴포넌트 라이프사이클과 독립적으로 동작한다는 중요한 특징도 잘 언급해주셨습니다. 다만 답변을 더욱 완성도 있게 만들려면 Zustand가 어떻게 불필요한 리렌더링을 방지하는지에 대한 구체적인 메커니즘(selector를 통한 선택적 구독, shallow comparison 등)을 추가로 설명해주시면 좋겠습니다. 또한 실제 코드 예시나 다른 상태 관리 라이브러리와의 차별점(boilerplate 코드 최소화, 미들웨어 불필요 등)을 함께 언급하시면 답변이 더욱 풍부해질 것 같습니다. 전반적으로 핵심 개념을 잘 이해하고 계시니, 좀 더 구체적인 구현 세부사항들을 학습해보시길 권합니다.
커뮤니티 공유 안내
• 이 결과는 AI가 분석한 내용이며, 학습 목적으로 커뮤니티에 공유됩니다.
• 좋아요를 눌러 유용한 답변에 반응을 남겨보세요.
• 개인정보는 포함되지 않으며, 면접 연습 개선을 위한 참고 자료로 활용됩니다.