개념
왜 Postman으로 시작하는가
Postman은 코드를 짜지 않고도 GUI로 API 요청을 만들고 테스트할 수 있는 도구다. 모듈 9(레슨 2)에서 배운 HTTP 메서드·상태 코드·헤더 개념을 화면으로 직접 조작하며 확인할 수 있어서, API 테스트에 처음 입문하기에 가장 접근성이 좋다.
요청 만들기
Postman에서 요청 하나는 메서드, URL, 헤더, 본문(있다면)으로 구성된다 — 모듈 9(레슨 2)에서 배운 HTTP 요청 구조 그대로다.
메서드: POST
URL: https://api.example.com/orders
헤더: Authorization: Bearer {{token}}
본문(JSON):
{
"productId": "P001",
"quantity": 2,
"couponCode": "SAVE10"
}{{token}}처럼 중괄호로 감싼 부분은 변수다 — 매번 값을 직접
바꿔 쓰지 않고, 환경(Environment)에 정의해둔 값을 재사용한다.
모듈 7(레슨 3)에서 배운 개발·스테이징·운영 환경마다 다른 URL이나
인증 정보를 변수로 관리하면, 환경을 바꿔가며 같은 요청을 재사용할
수 있다.
어서션 — 응답이 맞는지 확인하는 테스트 스크립트
요청을 보내는 것만으로는 테스트가 아니다. 응답이 기대한 대로 왔는지 확인하는 코드(모듈 10 레슨 1의 AAA 패턴 중 Assert 단계)가 있어야 진짜 테스트가 된다. Postman은 요청마다 자바스크립트로 이 확인 로직을 작성할 수 있다.
pm.test("상태 코드는 201이다", function () {
pm.response.to.have.status(201);
});
pm.test("응답에 주문 ID가 포함된다", function () {
const body = pm.response.json();
pm.expect(body).to.have.property("orderId");
});
pm.test("할인이 정확히 적용됐다", function () {
const body = pm.response.json();
pm.expect(body.totalPrice).to.equal(9000); // 10,000원 상품에 10% 할인
});이 구조는 레슨 1에서 배운 "API 테스트가 검증하는 것들"(상태 코드, 응답 본문, 값)을 그대로 코드로 표현한 것이다.
컬렉션 — 여러 요청을 묶어 관리하기
관련된 요청들을 하나의 **컬렉션(Collection)**으로 묶으면, 회원가입 → 로그인 → 주문 생성처럼 여러 API를 순서대로 실행하는 시나리오를 구성할 수 있다. 이전 요청의 응답값(예: 로그인 후 받은 토큰)을 다음 요청에서 변수로 재사용하는 것도 가능하다 — 실제 사용자 흐름을 API 레벨에서 재현하는 방식이다.
Postman의 한계를 미리 느껴보기
컬렉션이 커지고 요청 사이의 로직(조건 분기, 반복)이 복잡해지면, GUI로 관리하기가 점점 버거워진다. 이 한계가 레슨 3에서 다룰 "코드 기반 자동화로의 전환"으로 이어지는 자연스러운 동기가 된다.
실무에서 왜 필요한가
개발자가 새 API를 만들면, QA가 Postman으로 가장 먼저 그 API를 직접 두드려보며 명세와 실제 동작이 일치하는지 확인하는 경우가 많다. 이건 모듈 2(레슨 6)에서 배운 "요구사항 단계에서 질문하는 QA"의 역할을 API 레벨에서 가장 빠르게 실천하는 방법이다 — 화면이 다 만들어지기 전에 이미 결함을 잡을 수 있다.
실습 과제
과제 1 — 어서션 작성하기 (15분)
"상품 목록 조회 API"(GET 요청, 응답이 상품 배열)에 대해 다음 세 가지를 확인하는 Postman 테스트 스크립트를 작성한다.
- 상태 코드가 200인가
- 응답이 배열 형태인가
- 배열이 비어있지 않은가(최소 1개 이상의 상품)
과제 2 — 시나리오 설계하기 (10분)
"로그인 → 장바구니에 상품 추가 → 주문 생성"이라는 흐름을 컬렉션으로 구성한다면, 어떤 요청 순서로 만들고 어떤 값(토큰, 상품 ID 등)을 요청 간에 변수로 넘겨야 할지 설계한다.
자가 체크리스트
- Postman에서 요청의 구성 요소(메서드·URL·헤더·본문)를 만들 수 있다
-
pm.test로 상태 코드와 응답 본문을 검증하는 어서션을 작성할 수 있다 - 변수를 이용해 환경별로 요청을 재사용하는 방법을 설명할 수 있다
- 컬렉션으로 여러 요청을 순서대로 묶어 시나리오를 구성할 수 있다
흔한 실수
- 요청만 보내고 어서션 없이 응답을 눈으로만 확인한다. 이러면
매번 사람이 직접 봐야 해서 자동화의 의미가 없다 — 반드시
pm.test로 검증을 코드화해야 한다. - 환경마다 URL이나 토큰을 하드코딩해서 요청을 여러 벌 만든다. 변수와 환경 기능을 쓰면 하나의 요청을 여러 환경에서 재사용할 수 있다.
- 컬렉션이 복잡해지는데도 계속 GUI로만 관리하려 한다. 일정 복잡도를 넘으면 레슨 3의 코드 기반 자동화로 전환을 고려해야 한다.
참고 자료
- Postman Learning Center — Writing Tests — 어서션 작성법의 공식 가이드
- Postman Learning Center — Collections — 컬렉션 구성의 공식 가이드