코드 기반 자동화로 전환하기: Postman의 한계를 넘어서

개념

Postman이 한계에 부딪히는 순간

레슨 2 끝에서 언급한 한계가 실제로 나타나는 신호들이 있다.

버전 관리가 어렵다 — GUI로 만든 컬렉션은 Git으로 변경 이력을 추적하고 리뷰(모듈 9 레슨 7의 PR)하기가 코드보다 번거롭다
복잡한 로직을 표현하기 어렵다 — 조건 분기, 반복, 여러 API의 응답을 조합하는 로직은 GUI보다 코드로 표현하는 게 훨씬 명확하다
CI 파이프라인과의 통합이 상대적으로 무겁다 — 모듈 14에서 다룰 자동 배포 파이프라인에 매끄럽게 끼워 넣으려면 코드 형태가 유리하다
개발자와 테스트 코드를 공유하기 어렵다 — 개발자는 이미 모듈 10에서 배운 xUnit 계열 프레임워크(Jest, pytest 등)에 익숙하다

코드 기반 API 테스트의 모습

Postman의 어서션 스크립트가 코드 기반 프레임워크로 옮겨가면 이런 형태가 된다(예시는 JavaScript 기준).

test("주문 생성 API는 할인을 정확히 계산한다", async () => {
  const response = await request(app)
    .post("/orders")
    .send({ productId: "P001", quantity: 2, couponCode: "SAVE10" })
 
  expect(response.status).toBe(201)
  expect(response.body.totalPrice).toBe(9000)
})

레슨 2의 Postman 스크립트와 비교하면, 검증하는 내용은 똑같지만 (상태 코드, 응답 값), 표현 방식이 모듈 10에서 배운 xUnit 계열 구조(AAA 패턴, expect)로 통일되어 있다. 개발자가 짜는 단위·통합 테스트와 같은 언어, 같은 프레임워크를 쓰면 코드베이스 안에서 함께 관리하기 쉬워진다.

Postman을 완전히 버리는 것은 아니다

코드 기반 자동화로 전환한다고 Postman이 무의미해지는 건 아니다. 새 API가 만들어졌을 때 빠르게 손으로 두드려보며 탐색하는 용도로는 Postman이 여전히 빠르고 편하다 — 이건 모듈 5에서 배운 탐색적 테스팅과 비슷한 관계다. Postman은 탐색(빠른 확인)에, 코드 기반 자동화는 회귀(반복 검증)에 강점이 있다.

전환 시 고려할 점

점진적으로 전환한다 — 기존 Postman 컬렉션을 한꺼번에 버리기보다, 새로 추가하는 테스트부터 코드 기반으로 시작하는 것이 현실적이다
팀의 기존 기술 스택을 따른다 — 백엔드가 Python이면 pytest, Node.js면 Jest처럼, 모듈 10(레슨 2)에서 배운 프레임워크 중 팀에 익숙한 것을 고른다
테스트 데이터 관리(모듈 7 레슨 2)를 함께 고려한다 — 코드 기반 테스트는 CI에서 매번 새로 실행되므로, 시딩·리셋 전략이 더 중요해진다

실무에서 왜 필요한가

"Postman 컬렉션이 300개인데 아무도 관리 안 해요"는 실무에서 흔히 듣는 하소연이다. 언제, 왜 코드 기반으로 전환해야 하는지 아는 QA는 모듈 11(레슨 5)에서 배운 자동화 전략에 "Postman은 API 탐색용으로 유지하고, 회귀 테스트는 코드 기반으로 CI에 통합한다"처럼 구체적인 방향을 제시할 수 있다.

실습 과제

과제 1 — 전환 신호 진단하기 (10분)

다음 상황이 코드 기반 자동화로 전환할 신호에 해당하는지 판단하고 이유를 적는다.

"Postman 컬렉션에 요청이 200개 넘게 있는데, 이전 요청의 응답에 따라 다음 요청을 다르게 보내야 하는 로직이 늘어나면서 GUI 안의 스크립트가 점점 길고 복잡해지고 있다."

과제 2 — Postman과 코드 기반의 역할 나누기 (10분)

한 팀의 자동화 전략에서 Postman과 코드 기반 API 테스트를 각각 어떤 목적으로 쓸지, 이 레슨에서 배운 "탐색 vs 회귀" 구분을 참고해 역할을 나눠 적는다.

자가 체크리스트

Postman이 규모가 커지면 한계에 부딪히는 이유를 설명할 수 있다
코드 기반 API 테스트가 xUnit 계열 프레임워크(모듈 10)와 어떻게 연결되는지 설명할 수 있다
Postman과 코드 기반 자동화가 각각 어떤 목적에 더 적합한지 구분할 수 있다
전환 시 고려해야 할 점들을 설명할 수 있다

흔한 실수

Postman을 완전히 버려야 한다고 생각한다. 탐색 용도로는 여전히 유용하다 — 역할을 나누는 것이 핵심이다.
팀의 기존 기술 스택과 무관한 프레임워크를 선택한다. 개발자와 테스트 코드를 함께 관리하려면 익숙한 언어·프레임워크를 따르는 것이 유리하다.
전환을 한 번에 몰아서 하려 한다. 기존 컬렉션을 점진적으로 옮기는 것이 리스크가 적다.

참고 자료

Supertest (Node.js) GitHub — 코드 기반 API 테스트 라이브러리 예시
REST Assured (Java) 공식 문서 — 코드 기반 API 테스트 라이브러리 예시