이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 REST API 서버를 Node.js와 PostgreSQL로 구현했습니다. 라우팅·인증·DB 레이어를 분리하는 구조로 설계했고, 팀원들이 각 레이어를 독립적으로 개발할 수 있도록 인터페이스를 먼저 정의했습니다. 문제 해결 사례로는 동시 요청이 몰릴 때 DB 커넥션 풀이 고갈되는 현상이 있었는데, 커넥션 풀 크기 조정과 쿼리 최적화로 응답 지연을 절반 이하로 줄였습니다. 기술 스택 선택 기준은 팀원 숙련도와 배포 환경을 먼저 고려했고, 완벽한 기술 스택보다 팀이 유지보수할 수 있는 구조가 더 중요하다는 걸 그때 배웠습니다. 이 경험으로 완벽한 기술 선택보다 팀이 유지보수할 수 있는 구조가 더 중요하다는 걸 배웠고, 설계의 기준이 기술 스택이 아니라 팀 역량이어야 한다는 것도 이해했습니다.
백엔드 아키텍처를 설계할 때 처음 부딪힌 건 어떤 기술 스택을 선택할 것인가였습니다. Django와 FastAPI 두 옵션을 팀 숙련도, 비동기 지원, 초기 설정 비용 세 기준으로 비교했습니다. Django는 인증·관리 기능이 기본 제공되어 초기 구현 속도가 빠른 반면, 비동기를 기본으로 지원하지 않아 외부 API 응답을 기다리는 구간이 병목이 될 수 있었습니다. FastAPI는 초기 설정이 직접 해야 할 것들이 많았지만, 비동기 처리와 타입 힌트 기반 문서 자동화가 장점이었습니다. 팀원 한 명이 이미 사용 경험이 있어 FastAPI를 선택했고, 라우터·서비스·레포지토리 레이어를 먼저 정의한 뒤 구현하는 방식으로 진행했습니다. 인터페이스를 먼저 잡아두니 팀원들이 충돌 없이 병렬로 작업할 수 있었고, 테스트 작성도 레이어별로 분리되어 훨씬 수월했습니다.
백엔드 구조를 처음 잡았을 때 가장 많이 틀렸던 부분은 너무 이른 확장성 고려였습니다. 팀원이 세 명인 소규모 프로젝트에서 처음부터 마이크로서비스 구조를 시도했는데, 서비스 간 통신 설정과 배포 파이프라인을 맞추는 데 전체 개발 시간의 절반 가까이 소비했습니다. 결국 중반에 모노리스로 돌아왔고, 그때부터 기능 구현 속도가 빨라졌습니다. 이후 Node.js와 PostgreSQL로 단일 서버 구조를 먼저 완성했고, 병목이 실제로 측정됐을 때 분리하는 방식으로 접근했습니다. 그 결과 불필요한 설계 비용 없이 서비스를 완성할 수 있었고, 아키텍처 결정은 현재 팀 규모와 서비스 단계에 맞게 내려야 한다는 기준이 생겼습니다. 완성된 구조가 아니라 지금 풀어야 할 문제에 맞는 구조를 선택하는 것이 먼저라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.