개념
왜 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 레벨에서 가장 빠르게 실천하는 방법이다 — 화면이 다 만들어지기 전에 이미 결함을 잡을 수 있다.