본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 22. 06:14

Postman에서 모든 API 응답을 모킹하고 AI를 활용해 컬렉션 구축하기

요약

Postman의 모킹 서버를 활용하여 백엔드 개발 없이도 프론트엔드 테스트를 위한 다양한 API 응답 시나리오를 구축하는 방법을 소개합니다. AI와 모킹 서버를 결합해 성공, 에러, 빈 데이터 등 다양한 케이스를 효율적으로 시뮬레이션할 수 있습니다.

핵심 포인트

  • Postman 모킹 서버를 통해 실제 백엔드 없이 가짜 API 환경 구축 가능
  • 동일 엔드포인트에 다양한 상태 코드(200, 404, 500 등) 예시 추가 가능
  • 헤더 설정을 통해 단일 엔드포인트에서 원하는 응답 시나리오 선택 호출
  • CI/CD 및 팀 단위 협업이 가능한 지속 가능한 테스트 환경 제공

프론트엔드(Frontend) 테스트에서 가장 어려운 부분은 테스트 코드를 작성하는 것이 아닙니다. 바로 백엔드(Backend)가 당신이 원하는 정확한 응답을, 즉 500 에러, 빈 리스트, 잘못된 형식의 페이로드(Payload) 등을 원하는 순간에 반환하도록 만드는 것입니다. 라이브 서버에서는 이 작업이 고통스럽고, 때로는 불가능합니다.

대신 제가 사용하는 워크플로우를 소개합니다. 저는 백엔드를 전혀 건드리지 않고 앱이 제가 원하는 어떠한 응답이라도 받도록 만듭니다. Postman 모킹 서버(Mock servers)가 핵심적인 작업을 수행하고, AI가 데이터를 채워 넣습니다.

아이디어: 실제처럼 보이는 가짜 백엔드

프론트엔드는 JSON이 어디서 오는지 알지 못합니다. URL을 호출하고 돌아오는 무엇이든 신뢰합니다. 따라서 프론트엔드를 **모킹 서버(Mock server)**로 향하게 하면 됩니다. 모킹 서버란 미리 정의한 응답을 반환하는 가짜 주소입니다. 엔드포인트(Endpoints)와 구조(Shapes)는 동일하지만, 실제 백엔드는 전혀 없습니다.

왜 DevTools나 프록시(Proxy)를 사용하지 않나요?

일회성으로 빠르게 처리할 때는 브라우저 도구도 괜찮습니다:

  • **Chrome DevTools, 로컬 오버라이드(Local Overrides)**는 브라우저 내에서 직접 응답을 재작성합니다.
  • Charles / Requestly / mitmproxy는 응답을 가로채서 즉석에서 교체합니다.

하지만 오버라이드는 탭을 닫으면 사라지고, 당신의 로컬 머신에서만 작동하며, 팀원이나 CI 파이프라인에 전달할 수 없습니다. 단일 확인 이상의 작업을 수행하려면 실제적이고 지속적인 대안이 필요합니다.

1단계: 컬렉션(Collection) 구축하기

Postman에는 이미(혹은 곧) 컬렉션이 있을 것입니다. 실제 API가 노출하는 것과 동일한 메서드(Method), URL, 바디(Body), 헤더(Headers)를 가진 엔드포인트들입니다.

2단계: 예시 응답(Example responses) 추가하기

각 요청에 대해 점 세 개 아이콘을 클릭하고 Add example을 선택합니다. 예시(Example)는 저장된 응답, 즉 상태 코드(Status code)와 바디(Body)의 조합입니다. 이는 직접 작성합니다.

모든 케이스를 커버할 수 있도록 동일한 엔드포인트에 여러 예시를 걸어두세요:

  • 200 성공 (Success)
  • 404 찾을 수 없음 (Not found)
  • [] 빈 리스트 (Empty list)
  • 500 서버 에러 (Server error)

3단계: 모킹 서버 실행하기

컬렉션의 점 세 개 아이콘을 클릭한 다음 Mock collection을 선택합니다. Postman이 주소를 제공합니다:

4단계: 프론트엔드를 해당 서버로 연결하기

앱 설정의 베이스 URL(Base URL)을 교체합니다:

- const API = "https://api.production.com"
+ const API = "https://xxxx.mock.pstmn.io"

끝입니다. 이제 프론트엔드(Frontend)는 모킹(Mock) 서버와 통신하며, 그 차이를 전혀 느끼지 못합니다.

하나의 엔드포인트, 모든 시나리오

여기서부터 진짜 유용해집니다. 동일한 엔드포인트에 200, 404, 500 응답을 모두 걸어두었습니다. 모킹 서버는 그중 어떤 것을 반환할까요? 요청 헤더(Request header)를 보고 결정합니다:

x-mock-response-name: order not found

자동화 테스트(Automated test)에서 해당 헤더를 보내면, 서버나 데이터에 전혀 손을 대지 않고도 **단일 엔드포인트(Single endpoint)**만으로 모든 시나리오를 실행할 수 있습니다:

await fetch(`${API}/orders/42`, {
  headers: { "x-mock-response-name": "server error" }
})
...

응답은 정적일 필요가 없습니다

Postman은 예시 본문(Example body) 내에서 동적 변수(Dynamic variables)를 지원합니다:

{
  "id": "{{$randomInt}}",
  "name": "{{$randomFullName}}",
...

매 호출마다 하나의 고정된 데이터 덩어리(Hardcoded blob) 대신 서로 다른 데이터가 반환되므로, 예상치 못한 입력에서만 발생하는 버그를 잡아낼 수 있습니다.

가장 많은 시간을 아껴주는 부분

수십 개의 예시 응답을 일일이 손으로 작성하는 것은 이 모든 과정에서 따르는 지루한 비용입니다. 그래서 저는 그렇게 하지 않습니다.

저는 Postman MCP를 통해 Claude에게 컬렉션 전체를 넘겨줍니다. 그러면 Claude가 모든 엔드포인트에 대한 예시 응답(성공, 엣지 케이스(Edge cases), 잘못된 페이로드(Malformed payloads))을 생성하고 모킹을 연결합니다. 저는 Claude에게 코드를 짜달라고 요청하는 것이 아닙니다. 제가 커피를 마시는 동안 작동하는 테스트 스탠드(Test stand)를 조립해달라고 요청하는 것입니다.

이것이 바로 변화입니다. AI는

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0