에러가 발생했을 때 클라이언트가 원인을 파악하기 어려운가? → 영역 2: 응답 구조와 에러 처리
목록 API에서 데이터를 가져오는 방식이 통일되지 않았는가? → 영역 3: 페이지네이션과 필터링
인증/인가 관련 응답이 제각각인가? → 영역 4: 인증과 보안 헤더
API 변경 시 기존 클라이언트가 깨지는 일이 잦은가? → 영역 5: 버전 관리와 문서화
각 항목의 형식:
☐ 체크 항목 — 점검할 내용
✅ 통과 조건 — 이 상태여야 통과
❌ 실패 예시 — 실무에서 자주 보이는 안티패턴
팀 위키나 PR 템플릿에 복사해서 API 리뷰 체크리스트로 쓸 수 있도록 구성했다.
REST API 설계 점검의 5개 핵심 영역 (출처: 자체 구성)
영역 1 — 엔드포인트 네이밍 (7항목)
URL은 API의 첫인상이다. 네이밍이 일관되지 않으면, 클라이언트 개발자는 매 요청마다 문서를 열어야 한다. 이 영역은 URL 설계의 일관성을 점검한다.
항목 4번이 실무에서 가장 많은 논쟁을 일으킨다. /users/123/orders/456/items처럼 3단계 이상 중첩되면 URL이 길어지고, 권한 체크 로직도 복잡해진다. 이 경우 /order-items?orderId=456으로 평탄화(flatten)하는 것이 유지보수에 유리하다.
엔드포인트 네이밍 — 좋은 예와 나쁜 예 비교
# ✅ 좋은 패턴
GET /api/v1/users # 목록 조회
GET /api/v1/users/123 # 단건 조회
POST /api/v1/users # 생성
PATCH /api/v1/users/123 # 부분 수정
DELETE /api/v1/users/123 # 삭제
POST /api/v1/users/123/deactivate # 커스텀 액션
# ❌ 나쁜 패턴
GET /api/v1/getUsers
POST /api/v1/user/create
POST /api/v1/deactivateUser?id=123
GET /api/v1/User/123 # 대문자
영역 2 — 응답 구조와 에러 처리 (8항목)
API 응답 포맷이 일관되지 않으면 클라이언트 코드에 조건 분기가 쌓인다. 특히 에러 응답은 디버깅 시간을 결정하는 핵심 요소다. 이 영역은 응답 본문과 HTTP 상태 코드의 일관성을 점검한다.
항목 10번(에러 응답 포맷)은 API 설계 초기에 확정하지 않으면 나중에 통일하기가 극도로 어렵다. RFC 9457(Problem Details for HTTP APIs)이 2023년에 표준화됐으므로, 새 프로젝트라면 이 형식을 따르는 것을 권장한다.
HTTP 상태 코드 선택 가이드 — 상황별 올바른 코드 매핑 (출처: RFC 9110 기반 재구성)
영역 3 — 페이지네이션과 필터링 (7항목)
목록 API는 단순해 보이지만, 페이지네이션과 필터링 방식이 통일되지 않으면 클라이언트 코드의 복잡도가 급격히 올라간다. 특히 커서 기반 vs 오프셋 기반 선택은 데이터 특성에 따라 달라진다.
항목 21번은 선택이 아니라 의도적 결정이다. 오프셋 기반(?page=5&limit=20)은 구현이 쉽지만, 데이터가 추가/삭제되면 페이지 간 중복이나 누락이 생긴다. 커서 기반(?cursor=eyJ...&limit=20)은 이 문제를 해결하지만, 특정 페이지로 바로 점프할 수 없다.
API는 한 번 공개하면 변경하기 어렵다. 버전 관리 전략과 문서화 수준이 API의 수명을 결정한다. 이 영역은 API 변경 시 기존 클라이언트를 보호하는 장치가 있는지 점검한다.
항목 35번(Idempotency Key)은 결제, 주문, 송금처럼 중복 실행이 치명적인 API에 필수다. Stripe, PayPal 등 결제 API는 모두 이 패턴을 사용한다. 클라이언트가 같은 Idempotency-Key로 재요청하면, 서버는 이전 응답을 그대로 반환한다.
Idempotency Key — 결제 API 요청 예시
# 첫 번째 요청
curl -X POST https://api.example.com/v1/payments \
-H "Authorization: Bearer sk_live_..." \
-H "Idempotency-Key: order-abc-123-attempt-1" \
-H "Content-Type: application/json" \
-d '{"amount": 50000, "currency": "KRW", "method": "card"}'
# 네트워크 타임아웃으로 같은 요청 재시도 — 중복 결제 안 됨
curl -X POST https://api.example.com/v1/payments \
-H "Authorization: Bearer sk_live_..." \
-H "Idempotency-Key: order-abc-123-attempt-1" \
-H "Content-Type: application/json" \
-d '{"amount": 50000, "currency": "KRW", "method": "card"}'
# → 서버는 첫 번째 요청의 응답을 그대로 반환 (201, 같은 payment_id)
이 체크리스트를 팀에 도입하는 3가지 방법
체크리스트가 개인 참고 자료로 끝나면 효과가 없다. 팀 프로세스에 녹여야 한다.
PR 템플릿에 삽입 — API 관련 PR에 "엔드포인트 네이밍 ☐ / 응답 구조 ☐ / 에러 처리 ☐" 체크박스를 추가한다. 리뷰어가 형식적으로라도 확인하게 된다.
OpenAPI 스펙 린터로 자동화 — spectral(Stoplight) 같은 도구로 네이밍 규칙, 응답 구조, 상태 코드 사용을 CI에서 자동 검사한다.
API 설계 리뷰 미팅 — 새 API를 구현하기 전에 15분 설계 리뷰를 한다. 엔드포인트 URL, 요청/응답 JSON, 에러 케이스를 화이트보드에 그리고 이 체크리스트로 점검한다.
2번 방법(OpenAPI 린터)을 도입하면 체크리스트 항목 중 약 40%를 자동화할 수 있다. 아래는 Spectral 룰셋 예시다.