이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
RESTful API 설계는 학부 웹 개발 프로젝트에서 처음 직접 해봤습니다. 리소스를 명사로 표현하고 HTTP 메서드로 동작을 구분하는 원칙을 지키면서, /users/{id} 형식의 URL 구조가 API를 직관적으로 이해하게 해준다는 것을 배웠습니다.
상태 코드를 올바르게 반환하는 것이 클라이언트에서 오류를 처리하는 방식에 영향을 주기 때문에, 404와 400의 의미 차이를 명확히 구분해 사용했습니다. API 명세를 미리 문서화해두면 프론트엔드와 백엔드가 병렬로 개발할 수 있어 개발 속도가 빨라졌습니다.
응답 구조의 일관성이 클라이언트 코드 복잡도를 줄이는 데 중요하다는 것도 경험으로 배웠습니다. RESTful API 설계는 기술 구현보다 약속을 만드는 작업이라는 것을 이 경험에서 이해했습니다.
RESTful API를 처음 설계할 때 멱등성(Idempotency) 개념을 제대로 이해하지 못해 문제가 생겼습니다. POST /orders를 네트워크 오류로 클라이언트가 재시도했을 때 주문이 중복 생성되는 상황이었습니다. 당시에는 클라이언트가 중복을 막아야 한다고 생각했는데, API 설계 자체가 멱등하지 않은 것이 근본 원인이었습니다. 이후 Idempotency-Key 헤더를 도입해 서버 측에서 중복 요청을 감지하는 방식으로 개선했습니다. 또 하나의 막힘은 API 버전 관리였는데, URL에 버전을 명시하지 않았다가 스펙을 변경할 때 기존 클라이언트가 깨지는 문제가 생겼습니다. 이 두 경험으로 API는 한번 열리면 쉽게 바꿀 수 없는 계약이라는 것을 실감했고, 처음 설계 단계에서 더 신중하게 접근하는 습관이 생겼습니다.
졸업 프로젝트에서 백엔드 API 설계를 맡아 OpenAPI 스펙을 먼저 작성하고 프론트엔드와 합의한 뒤 개발을 시작했습니다. 막상 개발이 시작되자 프론트엔드 팀이 Mock 서버로 병렬 개발을 진행할 수 있었고 통합 시점에 충돌이 거의 없었습니다. 인증은 JWT를 적용했는데, 토큰 만료 처리와 리프레시 토큰 갱신 흐름을 처음 구현할 때 클라이언트와 서버 사이의 상태 관리가 생각보다 까다로웠습니다. Stateless 원칙을 지키면서도 보안을 유지하는 균형이 단순히 토큰을 발급하는 것과는 다른 설계라는 것을 실감했습니다.
다음에는 Rate Limiting과 API Gateway 수준의 인증을 배워 더 견고한 구조를 만들고 싶습니다. 이 경험이 API 설계를 기능 구현이 아닌 계약 설계로 바라보는 시작점이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 세나클소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.