이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
스케일러블한 플랫폼 로드맵을 설정할 때 가장 먼저 보는 것은 현재 어디서 병목이 생기는가입니다. 트래픽이 증가했을 때 먼저 무너지는 지점이 어디인지를 파악하면 우선순위가 나옵니다. 학교 프로젝트에서 서비스 배포 후 동시 접속자가 늘면서 DB 커넥션 풀이 먼저 소진되는 것을 경험했는데, 이것을 기반으로 로드맵을 DB 레이어 개선 → 캐시 레이어 추가 → 애플리케이션 수평 확장 순서로 설정했습니다. 로드맵 설계에서 중요한 것은 기술 결정과 비즈니스 일정을 연결하는 것입니다. 모든 것을 한 번에 확장 가능하게 만들 수 없으므로, 지금 당장의 트래픽을 감당하는 것과 미래를 준비하는 것 사이의 균형을 단계별로 설계합니다. 또한 각 단계의 검증 지표를 미리 정해두면 로드맵이 방향성을 잃지 않습니다.
확장성은 처음부터 완벽하게 설계하는 것이 아니라, 병목이 생길 것으로 예상되는 곳을 순서대로 개선하는 과정이라고 생각합니다.
팀 프로젝트에서 로드맵을 처음 잡을 때 가장 어려웠던 것은 '어디까지 해야 하는가'를 합의하는 것이었습니다. 기능 목록이 계속 늘어나면 방향을 잃는다는 걸 경험했기 때문에, 먼저 '이 서비스가 감당해야 할 트래픽 수준과 응답 기대치'를 숫자로 정해두는 것을 우선했습니다.
비기능 요구사항을 명확히 해두면 기술 결정이 훨씬 빨라집니다. 팀원들과 합의할 때는 각자의 구현 방식에서 시작하지 않고 '어떤 상황에서 서비스가 실패하면 안 되는가' 를 먼저 공유했습니다. 그 기준에 맞춰 단계를 나누니 우선순위 다툼이 줄었습니다. 성과 측정에는 배포 후 응답 시간과 오류율을 기준으로 단계가 성공인지 판단했습니다. 수치로 정해두지 않으면 '다음 단계로 가도 되는가'라는 판단을 계속 미루게 된다는 것도 그때 알게 됐습니다.
합의된 기준이 없으면 로드맵은 계획이 아니라 희망 목록이 된다는 생각입니다.
스케일러블한 서비스를 설계할 때 처음부터 완전한 확장성을 구현하려는 것이 오히려 더 큰 리스크라는 걸 배웠습니다. 인턴 기간에 참여한 프로젝트에서 초기 아키텍처를 너무 복잡하게 잡은 탓에 개발 일정이 두 배 가까이 늘어난 경험이 있었기 때문입니다. 그 이후로는 현재 부하를 감당하는 단순한 구조에서 시작해, 확장이 필요한 시점에 순서대로 개선하는 방향으로 로드맵을 잡습니다. 단계별 목표에는 응답 시간, 에러율, 동시 처리 수 처럼 측정 가능한 지표를 붙입니다.
지표가 없으면 언제 다음 단계로 넘어가야 하는지를 판단할 기준이 없습니다. 팀워크 면에서는 각 단계의 기술 결정을 팀원들과 사전에 공유해두면, 나중에 예상치 못한 리팩터링을 최소화할 수 있었습니다. 로드맵은 완성이 아니라 의사결정의 순서를 합의하는 과정이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.