이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Spring과 REST API를 함께 사용한 대표 프로젝트는 팀 내 업무 관리 API 서버 개발이었습니다. Spring MVC의 컨트롤러·서비스·레포지토리 계층을 나눠 각 레이어의 책임을 분리하니 코드 구조가 명확해졌습니다.
REST 설계에서는 리소스 중심의 URL 구조를 지켰습니다. 동사 대신 명사를 사용하고, HTTP 메서드로 행위를 표현하는 방식을 적용했습니다. 처음에는 PATCH와 PUT의 차이를 명확히 구분하지 못했는데, 팀 코드 리뷰에서 의미 차이를 배웠습니다.
예외 처리는 @ExceptionHandler로 전역 처리 구조를 만들었습니다. 각 컨트롤러에서 개별적으로 처리하던 것을 중앙화하니 응답 형식이 일관해졌고, 클라이언트가 에러를 처리하기 쉬운 구조로 개선됐습니다.
학부 팀 프로젝트에서 REST API를 처음 설계할 때, 오류 상황에도 무조건 200 OK를 반환하고 응답 본문에 성공 여부를 담는 방식을 썼습니다. 이렇게 해도 동작은 했지만, 클라이언트 팀원이 상태를 매번 본문 파싱으로만 판단해야 해서 처리 로직이 복잡해졌습니다. 나중에 400·404·409 같은 상태 코드를 명확히 분리하자는 의견이 나왔는데, 그 시점에 이미 클라이언트 코드가 기존 방식에 맞춰 짜져 있어 수정 범위가 커졌습니다. 결국 응답 스펙 문서를 먼저 만들고 클라이언트와 합의한 뒤 변경했는데, 처음부터 이 과정을 거쳤으면 훨씬 빨랐을 거라는 걸 돌아보면 아쉽습니다. 지금은 API를 짤 때 상태 코드 목록을 먼저 표로 정리하고 팀원과 리뷰를 거치는 편입니다.
인턴 프로젝트에서 기존 API에 새로운 필드를 추가했을 때, 이미 운영 중인 클라이언트가 예상치 못한 필드 때문에 에러를 내는 일이 생겼습니다. API 버전 관리를 처음 고민하게 된 순간이었습니다. 당시에는 v1, v2를 URL 경로에 넣는 방식과 헤더에 버전을 담는 방식 중 어느 쪽이 나은지 판단 기준이 없었습니다. 팀장에게 물어보고 공식 문서 사례를 찾아가며 URL 기반 버전 관리가 클라이언트 입장에서 더 명확하다는 결론을 냈고, /api/v1/과 /api/v2/ 경로를 분리해 구 버전을 3개월 유지 후 deprecated 처리하는 방식으로 정리했습니다. API 설계는 기능 구현 후에 바꾸면 영향 범위가 커진다는 걸 이 경험으로 처음 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.