2026년에 실제로 출제되는 30가지 API 테스팅 인터뷰 질문 (솔직한 답변 포함)

솔직하게 말씀드리겠습니다.

대부분의 "인터뷰 질문" 관련 기사들은 겉보기에는 그럴듯해 보이지만, 시니어 엔지니어가 압박 질문을 던지는 순간 무너져 버리는 피상적인 답변들이 복사되어 붙여넣어진 목록일 뿐입니다. 이 글은 다릅니다. 이 질문들은 테스팅을 진지하게 다루는 기업들의 실제 인터뷰 패턴에서 추출되었으며, 여기에 담긴 답변들은 일반적인 지원자들이 준비하는 수준보다 한 단계 더 깊이 들어갑니다.

첫 QA 역할을 준비하는 주니어 개발자이든, 테스트 중심의 직무로 이동하려는 백엔드 엔지니어이든, 이 글을 북마크하고 섹션별로 차근차근 학습하시기 바랍니다.

먼저, 면접관이 실제로 무엇을 평가하는지 이해하십시오

질문에 들어가기에 앞서, 중요한 점은 다음과 같습니다. API 테스팅 질문을 던지는 면접관은 단순히 당신이 상태 코드 (Status Code)의 정의를 알고 있는지를 확인하려는 것이 아닙니다. 그들은 다음 세 가지를 평가합니다:

API 테스팅이 '왜' 존재하는지 이해하고 있는가 — 단순히 그것이 무엇인지 아는 것을 넘어
엣지 케이스 (Edge Cases)를 논리적으로 추론할 수 있는가 — 단순히 해피 패스 (Happy Paths)뿐만 아니라
실무에서 직접 해본 적이 있는가 — 단순히 인터뷰를 위해 공부만 한 것이 아니라

아래의 모든 답변을 읽어 내려갈 때 이 관점을 명심하십시오.

섹션 1: 기초 질문 (모든 인터뷰에서 예상되는 질문)

1. API 테스팅이란 무엇이며, UI 테스팅과는 어떻게 다릅니까?

API 테스팅은 시스템이 어떻게 통신하는지를 검증합니다. 즉, 사용자 인터페이스 (UI)를 거치지 않고 인터페이스 계층에서 데이터 교환, 비즈니스 로직, 그리고 응답이 올바르게 작동하는지 확인합니다.

UI 테스팅은 브라우저나 앱을 구동하여 사용자 행동을 시뮬레이션합니다. 반면 API 테스팅은 해당 계층을 완전히 건너뛰고 서비스와 직접 통신합니다.

실질적인 차이점은 다음과 같습니다: API 테스트는 더 빠르게 실행되고, 덜 취약하며 (DOM 변경으로 인해 깨지지 않음), UI 테스트로는 절대 발견할 수 없는 로직 문제를 잡아냅니다. 기본기에 대해 더 깊이 알고 싶다면, 소프트웨어에서 API 테스팅이란 무엇인가가 전체적인 그림을 파악하기 위한 확실한 참고 자료가 될 것입니다.

면접관이 듣고 싶어 하는 것: 당신이 API 테스팅 (API testing)이 테스트 피라미드 (testing pyramid) 내에서 단위 테스트 (unit tests)와 엔드 투 엔드 테스트 (end-to-end tests) 사이에 위치한다는 점을 이해하고 있으며, 왜 그 위치가 가치 있는지를 알고 있다는 점입니다.

2. 어떤 유형의 API 테스팅이 존재하나요?

대부분의 지원자가 언급하는 것보다 더 많은 유형이 있습니다. 중요한 것들은 다음과 같습니다:

기능 테스팅 (Functional testing) — API가 명세서 (spec)에 기술된 대로 동작하는가?
계약 테스팅 (Contract testing) — API가 소비자 (consumer)와 제공자 (provider) 사이의 약속을 준수하는가?
부하/성능 테스팅 (Load/performance testing) — 트래픽 (traffic) 상황에서 어떻게 동작하는가?
보안 테스팅 (Security testing) — 인증 (Authentication), 인가 (authorization), 인젝션 취약점 (injection vulnerabilities)
통합 테스팅 (Integration testing) — 여러 서비스가 올바르게 통신하는가?
회귀 테스팅 (Regression testing) — 최근의 변경 사항이 이전에 작동하던 기능을 망가뜨렸는가?

대부분의 지원자는 두세 가지만 언급합니다. 만약 당신이 각 유형이 무엇을 다루는지, 언제 사용해야 하는지, 그리고 다른 유형과 어떻게 다른지 완벽하게 숙지한 상태로 면접에 임하고 싶다면, 준비를 마치기 전에 API 테스팅 유형 (types of API testing)에 대한 이 분석 내용을 읽어볼 가치가 있습니다. 모든 유형을 나열하고 각 유형이 해결하는 시나리오를 간략하게 설명하세요. 그것이 훌륭한 답변을 만드는 차이점입니다.

3. 흔히 테스트하는 HTTP 메서드(methods)는 무엇이며, 각각의 역할은 무엇인가요?

메서드 (Method)	목적 (Purpose)	예상 성공 코드 (Expected Success Code)
GET	리소스 조회 (Retrieve a resource)	200 OK
...

후속 질문은 거의 항상 다음과 같습니다: "PUT과 PATCH의 차이점은 무엇인가요?" PUT은 리소스 전체를 교체합니다. PATCH는 당신이 보내는 필드만 수정합니다. 만약 {"email": "new@email.com"}만 포함된 PATCH를 보낸다면, 이메일만 변경됩니다. 동일한 본문(body)으로 PUT을 보낸다면 다른 모든 필드가 삭제될 것입니다.

4. 테스트에서 어떤 HTTP 상태 코드 (status codes)를 검증해야 하나요?

200과 404를 넘어선 답변이 필요합니다. 완벽한 답변은 다음과 같습니다:

200 — 요청 성공 (Request succeeded)
201 — 리소스 생성됨 (Resource created)
204 — 성공, 반환된 콘텐츠 없음 (Success, no content returned) (DELETE 요청에서 흔히 사용됨)
400 — 잘못된 요청, 형식이 잘못된 입력 (Bad request, malformed input)
401 — 인증되지 않음 (Not authenticated)
403 — 인증되었으나 권한이 없음 (Authenticated but not authorized)
404 — 리소스가 존재하지 않음 (Resource doesn't exist)
422 — 검증 실패 (Validation failed) (요청 형식은 올바르나 논리적으로 유효하지 않음)
429 — 속도 제한 도달 (Rate limit hit)
500 — 서버 측 오류, 처리되지 않은 예외 (Server-side error, unhandled exception)

면접 팁 (Interview tip): 상태 코드(status codes)와 응답 본문(response body) 구조를 어느 하나만 보는 것이 아니라, 항상 둘 다 검증(assert)한다고 언급하세요.

5. REST API란 무엇인가요?

REST (Representational State Transfer)는 다음과 같은 아키텍처 스타일입니다:

통신이 무상태(stateless)입니다 — 각 요청은 필요한 모든 정보를 포함합니다.
리소스는 URL로 식별됩니다.
표준 HTTP 메서드(methods)가 해당 리소스에 대한 작업을 정의합니다.
응답은 일반적으로 JSON 또는 XML 형식입니다.

**무상태(stateless)**를 강조하세요 — 이것이 REST API를 확장 가능(scalable)하게 만드는 속성이며, 면접관들이 후속 질문을 가장 자주 던지는 부분입니다.

섹션 2: 중급 질문 (지원자들의 실력이 갈리기 시작하는 지점)

6. API 계약 테스트(Contract testing)란 무엇이며, 마이크로서비스(microservices)에서 왜 중요한가요?

계약 테스트(Contract testing)는 서비스 소비자(consumer)와 서비스 제공자(provider) 사이의 약속을 검증하며, 두 서비스가 동시에 실행되고 있는지 여부와는 독립적으로 수행됩니다.

마이크로서비스 환경에서는 A 팀의 서비스가 B 팀의 API에 의존합니다. 만약 B 팀이 필드 이름을 변경하거나 엔드포인트(endpoint)를 삭제하면, A 팀의 서비스는 중단됩니다. 계약 테스트는 이러한 문제를 공유 환경에 도달하기 전, 모든 커밋(commit) 단계에서 근본적으로 잡아냅니다.

Pact는 가장 널리 사용되는 도구입니다. 소비자가 기대하는 바를 정의하면, 제공자가 그 기대를 충족할 수 있는지 검증합니다. 실제 실행 중인 서비스는 필요하지 않습니다.

7. 인증(authentication)이 필요한 API는 어떻게 테스트하나요?

전체 흐름을 설명하세요:

토큰 획득 (/login, OAuth 흐름 또는 API key를 통해)
이후의 요청 시 Authorization 헤더에 토큰 포함
유효하지 않은 토큰 (401), 만료된 토큰 (401), 그리고 권한 부족 (403)에 대한 테스트 케이스를 구체적으로 작성

단순히 해피 패스 (Happy Path)만 테스트하지 마세요. 모든 인증 관련 테스트 케이스에는 최소 하나 이상의 부정적 시나리오 (Negative Scenario)가 포함되어야 합니다.

8. 기능 테스트 (Functional Testing)와 비기능 테스트 (Non-functional Testing)의 차이점은 무엇인가요?

기능 테스트 (Functional): API가 원래 해야 할 일을 수행하는가? 유효한 입력과 유효하지 않은 입력이 주어졌을 때 올바른 응답, 올바른 데이터, 올바른 동작을 수행하는지 확인합니다.

비기능 테스트 (Non-functional): 성능이 어떠한가? 부하 상황에서의 응답 시간, 평소 트래픽의 10배 상황에서의 동작, 지속적인 요청 중의 메모리 동작 등을 확인합니다.

두 가지 모두 필요합니다. 기능 테스트만 수행하는 팀은 운영 환경 (Production)에서 성능 문제를 발견하게 됩니다.

9. API의 응답 본문 (Response Body)을 어떻게 검증하나요?

세 가지 계층이 있습니다:

상태 코드 (Status code) — 올바른 코드인가?
스키마 (Schema) — 올바른 필드들이 올바른 데이터 타입 (Data type)으로 존재하는가?
값 (Values) — 이 특정 테스트 케이스에 대해 실제 값들이 정확한가?

상태 코드만 검증하는 것은 API 테스트 스위트에서 가장 흔히 발생하는 공백 중 하나입니다. 완전히 잘못된 데이터가 포함되어 있음에도 200 OK 응답을 받을 수 있기 때문입니다.

10. SOAP와 REST의 차이점은 무엇이며, 테스트 방식은 어떻게 다른가요?

REST는 표준 HTTP를 사용하며, 가볍고, JSON/XML을 반환하며, 상태가 없는 (Stateless) 방식입니다. SOAP는 XML을 독점적으로 사용하며, WSDL 파일에 정의된 엄격한 계약 (Contract)을 가지고 있고, fault 요소를 통한 내장된 오류 처리 (Error handling)를 지원합니다.

테스트 방식이 다른 이유는 SOAP 테스트가 XML 엔벨로프 (Envelope) 구조와 WSDL 계약을 반드시 검증해야 하기 때문입니다. SoapUI와 같은 도구는 이를 위해 특화되어 제작되었습니다. REST 테스트 도구 (Postman, Keploy, RestAssured)는 SOAP에 직접적으로 적용되지 않습니다.

11. API 테스트에서 테스트 데이터 (Test Data)를 어떻게 관리하나요?

일반적인 접근 방식:

정적 테스트 데이터 (Static test data) — 하드코딩된 값으로, 간단하지만 취약함
동적 데이터 생성 (Dynamic data generation) — 셋업 스크립트(setup scripts)나 팩토리 메서드(factory methods)를 통해 런타임에 생성됨
운영 트래픽 재생 (Production traffic replay) — Keploy와 같은 도구가 실제 트래픽을 기록하고 재생하여, 테스트 데이터가 항상 실제 사용 패턴을 반영하도록 함

후속 질문: "테스트 데이터 상태가 테스트 간에 누출(leak)되면 어떻게 되나요?" 답변: 테스트는 스스로를 정리(clean up)해야 하며, 각 테스트는 자신만의 격리된 상태(isolated state)를 생성해야 합니다.

12. 멱등성 (Idempotency)이란 무엇이며, 어떤 HTTP 메서드가 멱등해야 합니까?

멱등한 연산은 한 번을 호출하든 열 번을 호출하든 동일한 결과를 생성합니다. GET, PUT, DELETE, PATCH는 모두 멱등해야 합니다. POST는 일반적으로 그렇지 않습니다. 두 번의 POST 요청은 두 개의 리소스를 생성합니다.

테스트에서 중요한 이유: 만약 DELETE 엔드포인트가 멱등하지 않다면, 동일한 리소스에 대해 두 번 호출했을 때 두 번째 호출에서 404를 반환할 수 있습니다. 이는 올바른 동작이지만, 테스트는 이를 고려해야 합니다.

섹션 3: 심화 질문 (시니어 레벨 인터뷰)

13. 모든 서비스를 실행하지 않고 마이크로서비스 아키텍처 (Microservices architecture)에서 API를 어떻게 테스트하나요?

두 가지 접근 방식:

서비스 모킹 / 스터빙 (Service mocking / stubbing) — 실제 다운스트림(downstream) 서비스를 예측 가능한 응답을 반환하는 제어된 모크(mock)로 교체합니다.
계약 테스트 (Contract testing) — 계약을 독립적으로 검증하여, 라이브 다운스트림 서비스가 필요하지 않도록 합니다.

단위/통합 테스트를 위한 모킹과 서비스 간 합의를 위한 계약 테스트를 결합하는 것이 대규모 환경에서의 표준 접근 방식입니다.

14. CI/CD 파이프라인에서 API 회귀 테스트 (Regression testing)에 대한 귀하의 접근 방식은 무엇입니까?

완전한 답변에는 다음 내용이 포함되어야 합니다:

테스트는 병합(merge) 시점에만 실행되는 것이 아니라, 모든 풀 리퀘스트(pull request)에서 실행됩니다.
테스트는 격리되어야 합니다 — 실행 간에 공유된 상태가 없어야 합니다.
계약 테스트는 통합 테스트가 실행되기 전에 변경 사항으로 인한 중단(breaking changes)을 포착합니다.
성능 기준선(Performance baselines)을 통해 응답 시간이 저하될 경우 경고를 보냅니다.
불안정한 테스트(Flaky tests)는 무시되지 않고 격리(quarantined)된 후 수정됩니다.

Keploy와 같은 도구는 실제 API 트래픽으로부터 회귀 테스트 (Regression tests)를 자동으로 생성하며, 이를 통해 테스트 커버리지가 단순히 테스트 작성자가 상상한 방식이 아니라 API가 실제로 사용되는 방식과 일치하도록 유지합니다.

15. API의 보안 취약점 (Security vulnerabilities)을 어떻게 테스트하나요?

테스트해야 할 핵심 시나리오:

인젝션 (Injection) — 입력 필드를 통한 SQL, NoSQL, 커맨드 인젝션 (Command injection)
깨진 객체 수준 권한 부여 (Broken object-level authorization) — 사용자 A가 ID를 변경하여 사용자 B의 데이터에 접근할 수 있는가?
과도한 데이터 노출 (Excessive data exposure) — API가 반환해서는 안 될 필드를 반환하고 있는가?
속도 제한 (Rate limiting) — 무차별 대입 공격 (Brute-force attacks)에 대한 보호 조치가 있는가?
토큰 보안 (Token security) — JWT가 적절히 검증되는가? 만료된 토큰이 거부되는가?

OWASP API Security Top 10은 모든 면접관이 시니어 레벨의 지원자라면 알고 있을 것이라고 기대하는 참조 목록입니다.

16. API 버전 관리 (Versioning)란 무엇이며, 여러 버전에 걸쳐 어떻게 테스트하나요?

버전 관리를 통해 기존 소비자 (Consumers)를 중단시키지 않고 API를 발전시킬 수 있습니다. 일반적인 전략으로는 URI 버전 관리 (/v1/users), 헤더 버전 관리 (Header versioning), 쿼리 파라미터 버전 관리 (Query parameter versioning) 등이 있습니다.

여러 버전에 걸쳐 테스트한다는 것은 각 활성 버전에 대한 테스트 스위트 (Test suites)를 유지하고, v2가 출시되었을 때 v1 사용자가 영향을 받지 않는지 검증하는 것을 의미합니다. 여기서 계약 테스트 (Contract testing)가 핵심적인 역할을 하며, 이는 게시된 계약 (Contracts)이 여전히 준수되고 있는지 명시적으로 확인합니다.

17. API 부하 테스트 (Load testing)에 어떻게 접근하나요?

단계:

기준 성능 기대치 정의 (예: 500명의 동시 사용자 발생 시 p95 응답 시간이 200ms 미만)
인위적이고 균일한 트래픽이 아닌, 실제 사용 패턴을 사용하여 현실적인 부하 시나리오 작성
임계점 (Breaking point)을 찾기 위해 부하를 점진적으로 증가시키며 실행
장애가 API 계층, 데이터베이스, 또는 다운스트림 의존성 (Downstream dependencies) 중 어디에서 발생하는지 식별

도구: k6, Gatling, JMeter. 후속 질문은 대개 다음과 같습니다: "병목 현상 (Bottleneck)이 발생하는 '위치'를 어떻게 격리하나요?" — 답변: 분산 트레이싱 (Distributed tracing).

18. API 테스트에서 모킹 (Mocking)과 스터빙 (Stubbing)의 차이점은 무엇인가요?

Stub (스텁): 하드코딩된 응답을 반환합니다. 단순하며, 다운스트림 서비스 (downstream service)가 단순히 "존재"하고 예측 가능한 응답을 주기만 하면 될 때 유용합니다.

Mock (모크): 기대 사항 (expectations)이 내장되어 있습니다. 특정 매개변수와 함께 특정 횟수만큼 특정 호출이 이루어졌는지 검증합니다.

모크는 더 엄격하고 더 많은 오류를 잡아내지만, 테스트를 구현 세부 사항 (implementation details)에 더 강하게 결합시킵니다.

19. GraphQL API는 REST와 어떻게 다르게 테스트하나요?

GraphQL은 쿼리 (queries)와 뮤테이션 (mutations)을 사용하는 단일 엔드포인트 (/graphql)를 가집니다. 테스트 차이점은 다음과 같습니다:

엔드포인트별로 테스트하는 것이 아니라, 쿼리 구조와 필드 수준의 응답을 테스트합니다.
유효하지 않은 필드는 데이터를 조용히 누락시키는 것이 아니라 에러를 반환해야 합니다.
뮤테이션은 검증이 필요한 부수 효과 (side effects)를 가집니다.
하나의 GraphQL 쿼리가 N번의 데이터베이스 호출을 트리거할 수 있기 때문에 (N+1 문제), 성능 테스트가 더 까다롭습니다.

20. 불안정한 (flaky) API 테스트는 어떻게 처리하나요?

불안정한 테스트는 거의 항상 다음과 같은 원인으로 발생합니다: 공유된 가변 상태 (shared mutable state), 타이밍 의존성 (timing dependencies), 또는 안정적으로 사용할 수 없는 외부 서비스에 의존하는 테스트.