이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
서버 개발 외에도 프론트엔드와 인프라 양쪽에서 기초적인 경험을 쌓았습니다. 프론트엔드는 학부 팀 프로젝트에서 React를 사용해 간단한 대시보드 화면을 담당했고, 서버에서 API 응답을 받아 컴포넌트에 데이터를 연결하는 흐름을 직접 경험했습니다. 서버를 직접 만들어보고 클라이언트 개발을 하니까 API 설계가 왜 중요한지 양쪽 관점에서 이해하게 됐습니다.
Docker로 컨테이너를 구성하고 환경 변수를 분리하는 방식으로 배포 환경을 관리했고, 로컬과 서버 환경 불일치 문제를 줄이는 경험을 했습니다. 인프라 작업을 직접 해본 덕분에 서버 설정이나 배포 실패 시 원인을 스스로 파악할 수 있게 됐습니다. 풀스택 전문가는 아니지만 여러 영역의 기본 흐름을 이해하는 것이 협업에서 강점이 된다고 생각합니다.
인프라 작업에서 가장 많은 시간을 뺏겼던 것은 환경 불일치 문제였습니다. 로컬에서는 잘 동작하는데 서버에서 배포하면 다르게 동작하는 케이스가 반복됐습니다. Node 버전이 달라 패키지 동작이 달라지거나, 환경 변수 설정이 누락된 경우가 많았습니다. Dockerfile을 작성하고 런타임 환경을 코드로 고정했더니 로컬과 서버에서 동일한 환경으로 실행되는 것이 확인됐습니다.
docker-compose로 DB·백엔드·프런트엔드를 함께 띄우는 방식으로 신규 팀원이 환경 설정 없이 바로 개발 시작할 수 있게 됐습니다. 환경 설정은 코드로 남겨야 누가 봐도 재현 가능한 결이 된다는 것을 이 경험에서 배웠습니다. 인프라 작업은 어렵지만 한 번 잘 만들면 팀 전체가 혜택을 보는 결이 있었습니다.
서버 개발만 하다가 React로 직접 API를 소비하는 입장이 되어보니 API 설계가 달라 보였습니다. 제가 만든 API가 프런트엔드에서 사용하기 불편한 구조라는 것을 직접 느꼈습니다. 중첩이 깊어서 원하는 데이터를 꺼내려면 여러 단계를 거쳐야 했고, 한 화면에 필요한 데이터를 얻기 위해 여러 번 API를 호출해야 했습니다. 서버 쪽으로 돌아와서 API 구조를 클라이언트 사용 패턴 기준으로 다시 설계했습니다.
한 화면에서 필요한 데이터를 한 번의 요청으로 가져올 수 있도록 응답 구조를 바꿨습니다. 이 경험에서 API는 서버 편의가 아니라 클라이언트 소비 패턴 중심으로 설계해야 한다는 결을 배웠습니다. 여러 영역을 직접 경험해보는 것이 하나의 영역을 더 잘 만드는 데 도움이 되는 결이 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.