REST API 면접 질문과 답변 (2026): 메서드, 상태 코드, 설계

REST API 질문은 다른 사람들이 놀라지 않고 사용할 수 있는 인터페이스를 설계할 수 있는지 테스트합니다. 아래에는 기본 개념부터 백엔드 및 풀스택 면접에서 나오는 설계 세부 사항까지, 답변과 함께 20개의 질문이 있습니다. HTTP 메서드 규칙은 RFC 9110의 정의를 따랐습니다.

기본 개념

1. REST란 무엇인가요?

REST는 URL로 식별되는 리소스를 중심으로 구축된 네트워크 시스템의 아키텍처 스타일로, 소수의 표준 연산으로 조작하고 JSON과 같은 표현으로 설명합니다. REST API는 무상태(stateless)입니다. 각 요청이 서버가 처리하는 데 필요한 정보를 담고 있으므로, 어떤 서버든 어떤 요청이든 처리할 수 있습니다.

2. 실제로 API를 "RESTful"하게 만드는 것은 무엇인가요?

• /getOrder 같은 동사가 아닌 /orders/42처럼 URL에 리소스 명사를 사용
• 동작에는 표준 HTTP 메서드 사용
• 의미 있는 상태 코드
• 무상태 요청
• 일관된 표현과 에러 형태

면접에서는 실제 API 중 모든 REST 제약을 따르는 것은 거의 없으며, 예측 가능한 동작을 목표로 한다고 말하세요.

3. 주요 HTTP 메서드는 무엇에 사용되나요?

"안전(Safe)"은 요청이 서버 상태를 변경하지 않는다는 뜻입니다. "멱등(Idempotent)"은 여러 번 보내도 한 번 보낸 것과 같은 효과를 낸다는 뜻입니다.

4. 멱등이란 무엇이며, 왜 중요한가요?

요청을 반복해도 최종 상태는 한 번 요청한 후와 같습니다. 네트워크는 실패하기 마련이기 때문에 중요합니다. 클라이언트가 PUT에서 타임아웃되면 두려움 없이 재시도할 수 있습니다. 주문을 생성하는 POST는 두 개를 만들 수 있으므로, API는 종종 멱등성 키(idempotency key)를 받습니다. 클라이언트가 고유 키를 보내면, 서버는 같은 키를 다시 보았을 때 저장된 결과를 반환합니다.

5. PUT인가요, PATCH인가요?

PUT은 보낸 본문으로 전체 리소스를 교체하며, 빠뜨린 필드는 지워지거나 초기화됩니다. PATCH는 보낸 필드만 변경합니다. 작은 업데이트에는 PATCH를, 클라이언트가 전체 표현을 가지고 있을 때는 PUT을 사용하세요.

상태 코드와 에러

6. 어떤 상태 코드를 언제 사용하나요?

자주 나오는 후속 질문은 401과 403의 차이입니다. 401은 "당신이 누구인지 모르겠다"는 뜻이고, 403은 "당신이 누구인지 알지만, 이건 할 수 없다"는 뜻입니다.

7. API는 에러를 어떻게 반환해야 하나요?

올바른 상태 코드와 일관된 본문을 사용하세요. 좋은 에러 본문에는 안정적인 기계 판독 가능 코드, 사람이 읽을 메시지, 그리고 검증 오류의 경우 어떤 필드가 실패했는지가 담깁니다. 스택 트레이스나 내부 세부 사항을 클라이언트에 노출하지 마세요.

8. 검증은 어떻게 처리하나요?

클라이언트도 검증하더라도 서버에서 검증하세요. 가능하면 모든 문제를 한 번에 반환하여 사용자가 하나씩 고치지 않도록 하고, 400 또는 422를 일관되게 사용하세요.

설계

9. 관계를 위한 URL은 어떻게 설계하나요?

자식 리소스가 부모 아래에서만 의미가 있을 때 중첩합니다. 예를 들어 /users/7/orders처럼요. 중첩은 얕게 유지하세요. 한두 단계를 넘어가면 자식 리소스를 /orders/42처럼 직접 노출하고, /orders?userId=7처럼 쿼리 파라미터로 필터링합니다.

10. 목록은 어떻게 페이지네이션하나요?

커서 페이지네이션은 크거나 빠르게 변하는 데이터에 대한 일반적인 답입니다. 다음 커서와 결과가 더 있는지에 대한 힌트를 반환하세요.

11. 필터링과 정렬은 어떻게 하나요?

?status=open&sort=-created_at처럼 쿼리 파라미터를 사용합니다. 허용할 필드를 화이트리스트로 지정해서 인덱스가 없는 컬럼이나 민감한 컬럼이 노출되지 않도록 하고 쿼리를 빠르게 유지하세요.

12. API 버전은 어떻게 관리하나요?

무엇을 선택하든 한 버전 안에서 호환성을 깨는 변경은 피하세요. 필드를 추가하는 것은 보통 안전하고, 필드를 제거하거나 이름을 바꾸는 것은 안전하지 않습니다.

13. HATEOAS란 무엇인가요?

응답에 관련 동작에 대한 링크가 포함되어, 클라이언트가 URL을 하드코딩하는 대신 다음에 무엇을 할 수 있는지 발견할 수 있습니다. REST 정의의 일부이지만 이를 완전히 구현하는 API는 거의 없습니다. 알고 있다고 말하고, 대부분의 팀은 문서와 OpenAPI 명세를 대신 사용한다고 언급하세요.

보안과 성능

14. API 인증은 어떻게 하나요?

일반적인 선택지는 단순한 서버 간 통신을 위한 API 키, JSON Web Token 같은 베어러 토큰, 그리고 사용자가 앱에 자신의 데이터 접근을 허용할 때 쓰는 OAuth 2.0입니다. 항상 HTTPS를 사용하세요. URL은 로그에 남으므로 시크릿을 URL에 넣지 마세요.

15. 인증과 인가의 차이는 무엇인가요?

인증은 당신이 누구인지 증명하는 것입니다. 인가는 당신이 무엇을 할 수 있는지 결정하는 것입니다. 실패 방식도 다릅니다. 토큰이 없거나 유효하지 않으면 401이고, 유효한 토큰이지만 권한이 없으면 403입니다.

16. API를 남용으로부터 어떻게 보호하나요?

키별 또는 IP별 속도 제한, 요청 크기 제한, 입력 검증, 타임아웃, 비정상 트래픽 모니터링을 사용합니다. 클라이언트가 언제 다시 시도해야 하는지 알 수 있도록 Retry-After 헤더와 함께 429를 반환하세요.

17. API에서 HTTP 캐싱은 어떻게 작동하나요?

응답은 응답을 얼마나 오래 재사용할 수 있는지 알려주는 Cache-Control 헤더를 포함할 수 있습니다. ETag는 응답의 버전을 식별합니다. 클라이언트는 이를 If-None-Match로 다시 보내고, 변경된 것이 없으면 서버는 본문 없이 304 Not Modified로 응답합니다. 대역폭과 부하를 절약합니다.

18. CORS란 무엇인가요?

서버가 허용하지 않으면 브라우저는 웹 페이지가 다른 오리진의 응답을 읽지 못하게 막습니다. 서버는 어떤 오리진이 응답을 읽을 수 있는지 알려주기 위해 Access-Control-Allow-Origin 같은 헤더를 보냅니다. 이는 서버가 아니라 브라우저에 의해 강제되므로, 브라우저가 아닌 클라이언트로부터 API를 보호하지는 않습니다.

실전

19. REST, GraphQL, gRPC 중 무엇인가요?

가장 좋은 답은 승자를 정하는 것이 아니라 상황을 제시하는 것입니다.

20. API는 어떻게 문서화하고 테스트하나요?

OpenAPI 명세로 설명하세요. 그러면 문서와 클라이언트 코드를 생성할 수 있습니다. 세 가지 수준에서 테스트하세요. 로직에 대한 단위 테스트, 실제 데이터베이스에 대한 통합 테스트, 호환성을 깨는 변경을 잡아내는 계약 테스트입니다. 잘못된 입력이나 만료된 토큰 같은 실패 케이스도 시도해 보세요.

준비 방법

1. 화이트보드에서 할 일 목록이나 주문 시스템 같은 작은 API를 URL, 메서드, 상태 코드, 하나의 에러 응답까지 포함해 설계할 수 있어야 합니다.
2. 멱등성과 페이지네이션은 확실히 알아두세요. 가장 자주 나오는 주제입니다.
3. 직접 만들거나 사용한 API에 대한 이야기와, 다음에는 피하고 싶은 실수 하나를 준비하세요.

관련 연습은 Spring Boot 면접 질문, Node.js 면접 질문, 시스템 디자인 면접 질문, 컴퓨터 네트워킹 면접 질문 가이드를 참고하세요.

소리 내어 자신의 말로 연습하세요. 나중에 녹취록을 보면 어디서 횡설수설했는지, 핵심을 놓쳤는지 알 수 있습니다. 실시간 면접이나 평가에서 AI 도구 사용에 관한 고용주의 규칙을 따르세요.