개념
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에 통합한다"처럼 구체적인 방향을 제시할 수 있다.