이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 REST API를 처음 설계했을 때, 처음엔 URL 구조 없이 임의로 엔드포인트를 만들다가 팀원 간 혼선이 생겼습니다. 그 이후로 리소스 중심으로 URL을 설계하고 HTTP 메서드가 행위를 표현하게 맞추는 것과 응답 상태 코드를 의미에 맞게 구분하는 것을 원칙으로 정했습니다.
OpenAPI 스펙으로 먼저 API를 정의하고 팀원과 합의한 뒤 구현에 들어갔더니, 인터페이스 변경이 생겨도 스펙이 기준이 돼서 커뮤니케이션 비용이 줄었습니다. API 설계는 구현 편의보다 호출자 관점에서 명확성을 우선해야 한다는 걸 이 경험에서 배웠습니다. 지금도 API를 짜기 전에 호출 시나리오를 먼저 적어보는 습관을 유지하고 있습니다.
팀 프로젝트에서 백엔드 팀원마다 API 응답 구조를 다르게 만들어서, 클라이언트 코드가 엔드포인트마다 다른 응답 처리 로직을 갖게 됐습니다. 어떤 API는 {data: ...}, 다른 API는 {result: ...}, 또 다른 API는 오류 시 HTTP 상태 코드만 반환하는 식이었습니다. 클라이언트 팀원이 처리 로직을 세 가지 방식으로 따로 짜야 해서 혼란스럽다는 피드백이 왔습니다. 이후 {success, data, error} 구조의 공통 응답 래퍼를 만들어 모든 API가 같은 형식을 따르도록 했습니다. 이미 만들어진 API를 수정하는 작업이 이틀이 걸렸는데, 처음부터 합의했다면 필요 없는 수고였다는 걸 돌아봤습니다. API 설계는 팀 내 사전 합의가 먼저라는 걸 이 경험으로 배웠습니다.
인턴 프로젝트에서 API 응답 필드명을 수정했는데, 배포 후 기존 모바일 클라이언트에서 파싱 오류가 발생했습니다. API 버전 관리가 없는 상태에서 필드를 변경하면 기존 클라이언트가 깨진다는 걸 배포 전에 충분히 고려하지 못했습니다. 긴급하게 이전 필드명을 추가로 함께 반환하는 임시 방편을 썼는데, 응답 구조가 지저분해졌습니다. 이후 /api/v1/과 /api/v2/ 경로를 분리해 기존 클라이언트는 v1을 유지하고, 새 기능은 v2에서 시작하는 구조로 재정비했습니다. v1은 3개월 유지 후 deprecated 처리 일정을 명시했습니다.
하위 호환성을 배포 전에 먼저 검토하지 않으면 클라이언트 장애로 직결된다는 걸 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.