API 테스트란 무엇인가: 피라미드에서의 위치와 장점

개념

화면 없이 서버와 직접 대화한다

모듈 9(레슨 2)에서 배운 HTTP 요청·응답 구조를 떠올려보자. 사용자가 버튼을 클릭하면 브라우저가 서버에 요청을 보낸다 — API 테스트는 이 요청을 브라우저 화면을 거치지 않고 직접 서버에 보내서 응답을 검증하는 방식이다.

UI 테스트:  화면 클릭 → 브라우저가 요청 생성 → 서버 응답 → 화면에 반영 → 확인
API 테스트: 요청을 직접 생성 → 서버 응답 → 응답 자체를 확인

자동화 피라미드에서 API 테스트의 위치

모듈 11(레슨 1)에서 배운 피라미드를 떠올리면, API 테스트는 보통 통합 테스트 계층에 해당한다 — 여러 컴포넌트(서버 로직, 데이터베이스)가 맞물려 동작하는지 확인하되, 화면 렌더링이라는 가장 불안정하고 느린 요소는 건너뛴다.

        ▲
       /E2E\
      /-----\
     /  API  \       ← API 테스트가 주로 여기
    /---------\
   / 단위 테스트 \
  /---------------\

API 테스트가 UI 테스트보다 유리한 이유

1. 빠르다 — 화면 렌더링, 애니메이션, 리소스 로딩을 기다릴 필요가 없다. 요청을 보내고 응답만 받으면 끝이다.

2. 안정적이다 — 모듈 7(레슨 3)에서 배운 플래키 테스트의 흔한 원인(요소를 못 찾음, 타이밍 문제)이 UI 테스트에는 있지만 API 테스트에는 훨씬 적다.

3. 원인 파악이 쉽다 — 실패했을 때, "화면의 어느 요소가 문제였는지" 추적할 필요 없이 응답 자체(상태 코드, 응답 본문)를 보면 바로 원인을 알 수 있다.

4. 백엔드 로직을 UI 없이도 검증할 수 있다 — 프런트엔드 개발이 아직 안 끝났어도, API가 준비되면 바로 테스트를 시작할 수 있다.

API 테스트로는 확인할 수 없는 것

API 테스트는 서버 로직의 정확성을 확인하지만, 사용자가 실제로 보는 화면은 확인하지 못한다. "API 응답은 맞는데 화면에 잘못 표시된다"는 프런트엔드 버그는 API 테스트로 절대 못 잡는다 — 이건 모듈 10(레슨 6)의 컴포넌트 테스트나 E2E 테스트의 영역이다. API 테스트는 피라미드의 한 계층일 뿐, 전체를 대체하지 않는다.

API 테스트가 검증하는 것들

상태 코드 — 모듈 9(레슨 2)에서 배운 2xx/4xx/5xx가 예상대로 나오는가
응답 본문 구조와 값 — 필요한 필드가 있는가, 값이 정확한가
응답 시간 — 너무 느리지는 않은가(성능 관점, 모듈 16과 연결)
에러 처리 — 잘못된 요청에 적절한 에러 응답을 주는가

실무에서 왜 필요한가

프런트엔드가 아직 완성되지 않았어도 백엔드 API가 준비되면 QA가 바로 테스트를 시작할 수 있다는 것은, 모듈 4(레슨 4)에서 배운 일정 산정에 큰 영향을 준다 — 병렬로 검증을 진행할 수 있어 전체 일정이 단축된다. 또한 API 테스트가 안정적으로 자리 잡으면, UI 자동화(모듈 13)는 정말 "화면 자체의 문제"만 잡는 데 집중할 수 있어 피라미드가 건강해진다.

실습 과제

과제 1 — UI 테스트 vs API 테스트 판단하기 (10분)

다음 두 검증을 API 테스트와 UI 테스트 중 어느 것으로 하는 게 더 적절할지 판단하고 이유를 적는다.

"주문 생성 API가 재고를 정확히 차감하는지"
"장바구니에 담긴 상품 이미지가 화면에 깨지지 않고 표시되는지"

과제 2 — API 테스트로 검증할 항목 나열하기 (10분)

"회원가입 API"를 API 테스트로 검증한다면, 상태 코드·응답 본문· 에러 처리 관점에서 각각 무엇을 확인해야 할지 3가지 이상 나열한다.

자가 체크리스트

API 테스트가 UI 테스트와 어떻게 다른 방식으로 검증하는지 설명할 수 있다
API 테스트가 자동화 피라미드의 어느 계층에 해당하는지 설명할 수 있다
API 테스트가 UI 테스트보다 빠르고 안정적인 이유를 설명할 수 있다
API 테스트로 확인할 수 없는 것이 무엇인지 설명할 수 있다

흔한 실수

API 테스트만으로 모든 검증이 끝났다고 생각한다. 화면에 실제로 잘 표시되는지는 별도로 확인해야 한다.
프런트엔드가 완성될 때까지 테스트를 시작하지 않는다. API가 준비되면 그전에 병렬로 API 테스트를 시작할 수 있다.
API 테스트 실패를 항상 UI 문제로 오해한다. API 테스트는 화면을 거치지 않으므로, 실패는 서버·로직 쪽 문제일 가능성이 높다.

참고 자료

ISTQB Glossary — API Testing — API 테스트의 공식 정의
Postman Learning Center — API 테스트 개요 — API 테스트의 실무적 소개