예시 답변 1
팀 프로젝트에서 URL 설계 실패를 교정한 경험 결
팀 프로젝트로 4명이 독서 기록 공유 서비스를 만들 때 처음으로 REST API 설계를 맡았습니다. 처음에는 URL 구조를 동사 중심으로 만들었는데(/getBook, /deleteBook), 프론트엔드 담당자가 "어디까지가 자원이고 어디서부터가 행위인지 헷갈린다"고 했습니다. 그제야 리소스 중심 설계가 왜 중요한지를 실감했습니다.
그 이후에는 HTTP 메서드(GET·POST·PUT·DELETE)로 행위를 표현하고 URL은 명사형 자원으로만 구성하는 규칙을 팀과 합의했습니다. HTTP 상태 코드도 5가지 케이스(200·201·400·401·404)를 명확히 정의했고, 에러 응답 형식을 통일했더니 프론트가 예외 처리하기 훨씬 편해졌다는 피드백을 받았습니다.
가장 아쉬웠던 건 페이지네이션 방식을 오프셋 기반으로 먼저 만들었다가, 중간에 커서 기반으로 바꾸면서 프론트 코드를 두 번 고친 일입니다. 처음 설계 단계에서 데이터 증가를 좀 더 고려했으면 좋았을 것 같습니다.
이 결의 특징
약점을 인정하고 개선 방법을 찾는 과정이 구체적으로 드러난 결입니다. 완벽함을 추구하기보다 현실적 한계를 마주하고 그에 맞는 대응을 짜나가는 움직임이 구체적으로 관찰됩니다.
이 결이 통하는 자리
팀 내에서 피드백을 받아들이고 빠르게 개선해야 하는 자리에서 이 자세가 강점으로 작동합니다. 실수 지적을 수용하고 구체적 움직임으로 옮기는 팀 문화에서 신뢰받습니다.