TechFeedTechFeed
Backend

REST API 설계 체크리스트 2026 — 엔드포인트 네이밍부터 에러 응답까지 실무 35항목

REST API를 설계할 때 빠뜨리기 쉬운 35개 항목을 5개 영역으로 정리한 체크리스트. 엔드포인트 네이밍, 응답 구조, 페이지네이션, 인증 헤더, 버전 관리까지 PR 리뷰에 바로 쓸 수 있다.

"API 만들었는데 프론트엔드 개발자가 욕한다" — 대부분 설계 단계에서 놓친 항목 때문이다.

엔드포인트 네이밍이 들쭉날쭉하고, 에러 응답 포맷이 제각각이고, 페이지네이션 방식이 API마다 다르면 — 클라이언트 개발자는 매번 문서를 뒤져야 한다. 이 체크리스트는 그 문제를 사전에 차단한다.

이 글은 REST API를 설계할 때 빠뜨리기 쉬운 항목을 5개 영역, 35개 체크 항목으로 정리했다. 신규 API를 처음 설계하는 경우뿐 아니라, 기존 API의 일관성을 점검하는 데도 사용할 수 있다. 각 항목에는 통과/실패 판단 기준과 구체적인 예시를 포함했다.

이 체크리스트가 필요한 경우
  • 새 프로젝트에서 REST API 컨벤션을 잡아야 하는 백엔드 팀
  • 기존 API의 일관성이 무너져서 정리가 필요한 경우
  • 프론트엔드/모바일 팀에서 "API가 쓰기 불편하다"는 피드백이 반복되는 경우
  • API 리뷰 기준이 사람마다 달라서 명문화가 필요한 경우

※ 이 글은 2026년 3월 기준, HTTP/1.1 RFC 9110 및 JSON:API, Google API Design Guide를 참고하여 작성됐습니다.

체크리스트 사용법과 우선순위 판단

35개 항목을 한 번에 모두 적용할 필요는 없다. 아래 의사결정 플로우로 현재 팀에 가장 급한 영역부터 시작하면 된다.

우선순위 판단 플로우

  1. URL 패턴이 API마다 다른가? (복수형/단수형 혼재, 동사 포함) → 영역 1: 엔드포인트 네이밍
  2. 에러가 발생했을 때 클라이언트가 원인을 파악하기 어려운가? → 영역 2: 응답 구조와 에러 처리
  3. 목록 API에서 데이터를 가져오는 방식이 통일되지 않았는가? → 영역 3: 페이지네이션과 필터링
  4. 인증/인가 관련 응답이 제각각인가? → 영역 4: 인증과 보안 헤더
  5. API 변경 시 기존 클라이언트가 깨지는 일이 잦은가? → 영역 5: 버전 관리와 문서화

각 항목의 형식:

  • ☐ 체크 항목 — 점검할 내용
  • ✅ 통과 조건 — 이 상태여야 통과
  • ❌ 실패 예시 — 실무에서 자주 보이는 안티패턴

팀 위키나 PR 템플릿에 복사해서 API 리뷰 체크리스트로 쓸 수 있도록 구성했다.

REST API 설계 체크리스트 5개 영역 — 엔드포인트 네이밍, 응답 구조, 페이지네이션, 인증, 버전 관리를 보여주는 도표
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년에 표준화됐으므로, 새 프로젝트라면 이 형식을 따르는 것을 권장한다.

에러 응답 — RFC 9457 Problem Details 기반 구조 예시
// 유효성 에러 (422) { "type": "https://api.example.com/errors/validation", "title": "Validation Error", "status": 422, "detail": "요청 본문에 유효하지 않은 필드가 있습니다.", "errors": [ { "field": "email", "message": "이메일 형식이 올바르지 않습니다" }, { "field": "age", "message": "0 이상의 정수여야 합니다" } ] } // 리소스 없음 (404) { "type": "https://api.example.com/errors/not-found", "title": "Not Found", "status": 404, "detail": "ID 456에 해당하는 주문을 찾을 수 없습니다." }
HTTP 상태 코드 의사결정 트리 — 2xx, 4xx, 5xx 분류와 각 상태 코드의 올바른 사용 시나리오를 보여주는 플로우차트
HTTP 상태 코드 선택 가이드 — 상황별 올바른 코드 매핑 (출처: RFC 9110 기반 재구성)

영역 3 — 페이지네이션과 필터링 (7항목)

목록 API는 단순해 보이지만, 페이지네이션과 필터링 방식이 통일되지 않으면 클라이언트 코드의 복잡도가 급격히 올라간다. 특히 커서 기반 vs 오프셋 기반 선택은 데이터 특성에 따라 달라진다.

항목 21번은 선택이 아니라 의도적 결정이다. 오프셋 기반(?page=5&limit=20)은 구현이 쉽지만, 데이터가 추가/삭제되면 페이지 간 중복이나 누락이 생긴다. 커서 기반(?cursor=eyJ...&limit=20)은 이 문제를 해결하지만, 특정 페이지로 바로 점프할 수 없다.

실무 판단 기준

  • 오프셋 기반: 관리자 패널, 검색 결과 (페이지 점프 필요, 데이터 변동 적음)
  • 커서 기반: 타임라인, 피드, 알림, 채팅 (실시간 데이터 추가, 무한 스크롤)
  • 키셋 기반: 대용량 테이블 (수백만 행, WHERE id > ? LIMIT 20 패턴)
커서 기반 페이지네이션 응답 구조 예시
// GET /api/v1/notifications?cursor=eyJpZCI6MTAwfQ&limit=20 { "data": [ { "id": 101, "message": "새 댓글", "createdAt": "2026-03-27T09:00:00Z" }, { "id": 102, "message": "좋아요", "createdAt": "2026-03-27T09:01:00Z" } ], "meta": { "nextCursor": "eyJpZCI6MTIwfQ", "hasNext": true, "limit": 20 } }

영역 4 — 인증과 보안 헤더 (6항목)

인증/인가 관련 API 설계는 별도의 보안 체크리스트(이 사이트의 API 보안 체크리스트 2026)에서 심층적으로 다루지만, REST API 설계 단계에서 반드시 확인해야 할 항목은 아래 6개다.

항목 24번(401 vs 403)은 간단해 보이지만, 실무에서 가장 많이 혼동되는 상태 코드다. 정리하면:

  • 401 Unauthorized: "너 누군지 모르겠다" — 토큰이 없거나, 만료됐거나, 유효하지 않음
  • 403 Forbidden: "너 누군지는 알겠는데, 이건 안 돼" — 인증은 됐지만 해당 리소스에 대한 권한이 없음

401을 받은 클라이언트는 재로그인을 시도하고, 403을 받은 클라이언트는 권한 요청 UI를 보여준다. 이 차이가 UX를 결정한다.

API Rate Limiting 동작 원리 — 토큰 버킷 알고리즘과 Rate Limit 헤더의 관계를 보여주는 다이어그램
Rate Limiting 토큰 버킷 알고리즘과 응답 헤더 매핑 (출처: IETF RFC 6585 기반 재구성)

영역 5 — 버전 관리와 문서화 (7항목)

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가지 방법

체크리스트가 개인 참고 자료로 끝나면 효과가 없다. 팀 프로세스에 녹여야 한다.

  1. PR 템플릿에 삽입 — API 관련 PR에 "엔드포인트 네이밍 ☐ / 응답 구조 ☐ / 에러 처리 ☐" 체크박스를 추가한다. 리뷰어가 형식적으로라도 확인하게 된다.
  2. OpenAPI 스펙 린터로 자동화spectral(Stoplight) 같은 도구로 네이밍 규칙, 응답 구조, 상태 코드 사용을 CI에서 자동 검사한다.
  3. API 설계 리뷰 미팅 — 새 API를 구현하기 전에 15분 설계 리뷰를 한다. 엔드포인트 URL, 요청/응답 JSON, 에러 케이스를 화이트보드에 그리고 이 체크리스트로 점검한다.

2번 방법(OpenAPI 린터)을 도입하면 체크리스트 항목 중 약 40%를 자동화할 수 있다. 아래는 Spectral 룰셋 예시다.

Spectral — OpenAPI 린터 룰셋 예시 (.spectral.yml)
extends: spectral:oas rules: paths-kebab-case: description: URL 경로는 kebab-case given: $.paths[*]~ then: function: pattern functionOptions: match: "^(/[a-z0-9-]+|/{[a-zA-Z]+})+$" operation-error-response: description: 모든 엔드포인트에 400, 500 에러 응답 정의 필수 given: $.paths[*][get,post,put,patch,delete].responses then: - field: "400" function: truthy - field: "500" function: truthy pagination-meta: description: 목록 API 응답에 meta 필드 필수 given: $.paths[*].get.responses.200.content.application/json.schema then: field: properties.meta function: truthy

Spectral을 GitHub Actions에 통합하면 PR마다 자동으로 API 스펙을 검사한다. 설치와 실행은 한 줄이다.

Spectral CLI 실행 명령어
npm install -g @stoplight/spectral-cli spectral lint openapi.yaml --ruleset .spectral.yml
REST APIAPI설계체크리스트HTTP엔드포인트에러처리페이지네이션OpenAPI

관련 포스트

NestJS 실전 튜토리얼 — 모듈 설계부터 JWT 인증, Swagger 문서화까지2026-04-04PostgreSQL 커넥션 풀 고갈로 서비스가 멈춘 새벽 3시 — PgBouncer 도입과 연결 관리 재설계 실전 기록2026-04-21pgvector vs Pinecone vs Qdrant — 벡터 데이터베이스 실전 비교 20262026-04-17PostgreSQL 성능 튜닝 실전 가이드2026-02-20