이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 쇼핑몰 주문 관리 API를 설계할 때, 처음엔 바로 테이블 구조부터 잡으려 했습니다. 나중에 '교환·반품 처리는요?'라는 질문이 나오면서 초반 설계가 전부 바뀌는 상황이 됐습니다.
그 이후로 코드 전에 '주문이 가질 수 있는 모든 상태를 나열하고, 각 상태 전이 조건을 팀과 함께 정리'하는 단계를 먼저 밟게 됐습니다. 상태 다이어그램을 그리고 나서 테이블을 설계하니 이후 변경이 거의 없었습니다.
API 설계도 비슷하게 접근했습니다. 리소스 관점으로 먼저 정의하고, 각 리소스에 필요한 액션을 HTTP 메서드로 매핑했습니다. '클라이언트가 어떤 화면에서 이 데이터를 쓰는가'를 먼저 물으면 불필요한 필드를 줄이는 데도 도움이 됐습니다. 요건 이해가 설계보다 앞서야 한다는 걸 그때 배웠습니다.
인턴 때 모바일 앱과 연동하는 API를 설계했는데, 클라이언트 팀과 충분한 협의 없이 응답 필드 이름을 바꿨다가 앱이 업데이트 없이도 동작해야 하는 사용자들의 화면이 깨지는 사고가 났습니다.
그 이후로 API 변경 시 어떤 상황에서도 기존 필드는 유지하고 새 필드를 추가하는 원칙을 팀에서 세웠습니다. 필드를 제거해야 할 때는 deprecated 표시를 먼저 하고 2주 유예를 두기로 했습니다.
필드 이름 하나를 바꾼 것이 그렇게 큰 사고로 이어질 줄 몰랐습니다. API는 만들면 끝이 아니라 소비하는 클라이언트가 모두 대응할 때까지 책임이 따라온다는 걸 그때 처음 실감했습니다. 지금도 API 설계 시 '이 변경이 클라이언트에 어떤 영향을 주는가'를 먼저 묻게 됩니다.
사이드 프로젝트에서 배달 주문 서비스 API를 설계할 때, '주문 완료'가 결제 완료인지 배달 완료인지 팀 내 해석이 달랐습니다. 각자 다른 기준으로 코드를 짜다가 주문 상태값이 서비스마다 달라지는 문제가 생겼습니다.
용어 정의 세션을 한 번 진행해 '결제완료 / 조리중 / 배달중 / 수령완료'로 상태를 명확히 나누고 문서화했습니다. 이걸 기준으로 DB 컬럼명도 통일했습니다. 30분 세션이 이후 2주간의 혼란을 막았다는 게 인상적이었습니다.
비즈니스 요건을 이해할 때 용어 통일이 기술 설계보다 선행되어야 한다는 걸 그때 배웠습니다. 데이터 모델과 API는 그 용어를 코드로 옮기는 작업이라는 것이 지금도 제 접근 방식입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.