MSW 수작업, 아직 하고 계신가요? Codex로 Postman 자동화 해봤습니다

백우진·2026년 1월 26일

MCP MSW codex postman

이 글을 시작하기 전에: 기존 방식의 문제

프론트엔드 개발에서
MSW를 도입했다고 해서 항상 생산적인 건 아니다.

오히려 현실에서는 이런 작업이 반복된다.

API 스펙 문서 보면서
→ handler 하나하나 직접 작성
응답 구조 맞춰서
→ mock 데이터 수작업 생성
에러 / 지연 케이스가 필요해지면
→ handler 또 복사해서 수정
스펙이 바뀌면
→ handler, mock, 타입 전부 다시 손봄

결국 MSW는
“백엔드 없이 개발하기 위한 도구”인데,
프론트엔드가 또 다른 백엔드 역할을 하게 되는 순간이 온다.

이 과정에서 가장 많이 소모되는 건 코드가 아니라 시간이다.

이 글에서 해결하려는 핵심 문제

이 글이 집중하는 문제는 딱 하나다.

왜 프론트엔드 개발자가
API 스펙을 이미 정의해둔 Postman이 있는데도
MSW와 mock 데이터를 매번 손으로 만들고 있을까?

Postman 컬렉션에는 이미 다음 정보가 다 들어 있다.

endpoint / method
request body
response 예시
에러 케이스

그런데도 우리는 이걸 다시 보고, 다시 해석해서, 다시 코드를 쓴다.

이 반복 작업을
Postman MCP + AI agent에게 통째로 넘기면
개발 흐름이 완전히 달라진다.

결과는 단순하다

이 글에서 소개하는 흐름을 적용하면,

MSW handler 수작업 작성 ❌
mock 데이터 수동 생성 ❌
타입 직접 정의 ❌

이 세 가지가 한 번에 사라진다.

Postman에 스펙만 정의돼 있다면,

MSW handler
mock DB
entities 타입
성공 / 에러 / 지연 시나리오

를 AI가 자동으로 생성한다.

실제로 이 구조를 적용한 뒤,

API 대기 시간
mock 구성 시간
스펙 변경 대응 시간

을 합쳐 보면,
프론트엔드 개발자가 API 준비를 위해 쓰던 시간이
체감상 90% 이상 줄어든다.

이 글을 끝까지 읽고 나면, 이런 개발이 가능해진다

백엔드 API가 아직 구현되지 않았어도,
프론트엔드 개발은 이미 끝까지 진행할 수 있다.

필요한 조건은 단 하나다.

Postman에 API 스펙(컬렉션)만 정의되어 있을 것

이 글에서 소개하는 흐름을 적용하면
프론트엔드 개발자는 더 이상 아래 같은 대화를 반복하지 않아도 된다.

“이 API 언제 나와요?”
“응답 구조 아직 확정 안 됐어요?”
“일단 mock 하나만 임시로 만들어둘게요…”

최종적으로 만들게 될 개발 흐름

이 시리즈를 끝까지 따라오면,
아래 흐름이 한 번에 연결된 상태가 된다.

즉,

백엔드 구현이 없어도
실제 API가 붙은 것처럼 개발한다

는 상태를 만드는 것이 목표다.

왜 이게 중요한가?

프론트엔드 개발에서 가장 비싼 시간은
기다리는 시간이다.

API 구현 대기
스펙 변경 대기
임시 mock에서 실제 API로 전환하는 작업

이 흐름은 항상 개발을 끊는다.

하지만 Postman에 스펙만 제대로 정의돼 있다면
상황은 완전히 달라진다.

Codex가 Postman 컬렉션을 읽고
그 스펙을 기반으로
MSW API를 자동으로 구성하고
성공 / 에러 / 지연까지 실제 환경처럼 재현한다

프론트엔드는 더 이상 백엔드를 기다리지 않는다.

이 글에서는 무엇을 다루나?

이 글은 한 번에 끝까지 읽을 수 있게,
두 개의 단락으로 나눠서 정리했다.

1부. Codex + Postman MCP 연결하기

먼저 전체 흐름의 출발점부터 다룬다.

Codex와 Postman MCP(Local)를 연결하고
Postman 스펙을 말로 다룰 수 있는 상태를 만든다
getWorkspaces, getCollections, runCollection 같은 작업을
Codex에게 자연어로 시킬 수 있게 된다

이 단계까지 오면,
Postman은 더 이상 “문서만 보는 도구”가 아니라
에디터 안에서 바로 쓰는 API 도구가 된다.

2부. Postman 스펙으로 MSW 자동화하기

2부에서는 1부에서 연결해둔 MCP를 그대로 써서,
본격적으로 프론트 개발에 써먹는 단계로 넘어간다.

Postman 컬렉션과 API 스펙을 기반으로
MSW handler를 자동으로 만들고
간단한 mock DB와 함께
성공 / 에러 / 지연 같은 시나리오까지 구성한다

결국 목표는 하나다.

Postman 스펙만 있으면,
백엔드 없이도 프론트 개발을 끝까지 진행할 수 있는 상태를 만드는 것.

이 글에서는 그 흐름을 처음부터 끝까지 이어서 다룬다.

👉1부 시작

1. 요즘 MCP 덕분에 가능한 일들

MCP(Model Context Protocol)는
에디터 안에서 외부 도구를 “말로 다룰 수 있게” 만들어주는 규약이다.

Postman MCP가 붙으면 어떤 일이 가능해질까?

Postman UI를 열지 않고도
컬렉션이나 워크스페이스 구조를 확인하고
컬렉션 실행, 환경변수 생성 같은 작업을
Codex에게 자연어로 시킬 수 있다

즉, Postman이 문서 도구에서
에디터 안의 API 파트너로 바뀐다.

2. 왜 Remote가 아니라 Local(STDIO)로 연결했나?

Postman MCP는 Remote(HTTP) 서버도 제공한다.

Minimal: https://mcp.postman.com/minimal
Code: https://mcp.postman.com/code
Full: https://mcp.postman.com/mcp

처음에는 Remote 방식도 고려했지만,
결론적으로는 Local(STDIO) 방식을 선택했다.

Local(STDIO)를 선택한 이유

회사망, 프록시, VPN 환경에서도 비교적 안정적
Codex가 로컬 프로세스로 MCP 서버를 직접 실행
--full 옵션으로 100개 이상의 Postman tool을 바로 사용 가능

특히 회사 환경에서는
네트워크 이슈 하나로 개발 흐름이 끊기는 게 제일 피곤하다.
그 점에서 Local 방식은 훨씬 마음이 편했다.

3. 사전 준비물

시작하기 전에 필요한 것들은 생각보다 단순하다.

Node.js 설치 확인

Local MCP는 Node 기반이라 Node가 필요하다.

node -v
npm -v

버전이 정상적으로 나온다면 문제 없다.

Postman API Key

Local이든 Remote든
결국 Postman API를 호출하기 때문에 API Key는 필수다.

Postman → Profile → Settings → API keys
키는 한 번만 전체가 보이니 반드시 복사해두자

이 키는 잠시 뒤 Codex 설정 파일에서 사용하게 된다.

4. Codex MCP 설정 파일 위치

Codex는 MCP 서버 설정을 다음 파일에서 관리한다.

macOS / Linux
~/.codex/config.toml
Windows
C:\Users\<username>\.codex\config.toml

Codex CLI와 VSCode Codex Extension은
같은 config를 공유한다.

즉, CLI에서 한 번만 설정해두면
VSCode에서도 그대로 사용할 수 있다.

5. Postman MCP(Local) 설정 추가하기

이제 본격적으로 Postman MCP를 붙여보자.

나는 Full 모드(100+ tools) 로 연결했다.

config.toml에 아래 설정을 추가한다.

[mcp_servers.postman_local]
command = "npx"
args = ["-y", "@postman/postman-mcp-server@latest", "--full"]
enabled = true


# 첫 실행 시 패키지 다운로드 때문에 느릴 수 있다
startup_timeout_sec = 60
tool_timeout_sec = 120


[mcp_servers.postman_local.env]
POSTMAN_API_KEY = "YOUR_POSTMAN_API_KEY"

6. 연결 확인: `/mcp`

설정이 끝났다면, 이제 정상적으로 연결됐는지 확인해보자.

Codex를 실행한 뒤,

codex

정상적으로 연결됐다면
postman_local이 활성화된 상태로 표시되고,
사용 가능한 Postman tool 목록이 함께 나타난다.

여기까지 보인다면
Postman MCP 연결은 이미 끝난 셈이다.

Auth: Unsupported가 떠도 괜찮다

/mcp 화면을 보면
Auth: Unsupported라는 문구가 보일 수 있다.

하지만 걱정할 필요는 없다.

Local(STDIO) 모드에서는
OAuth 인증을 별도로 사용하지 않고,

env에 주입된 POSTMAN_API_KEY를 통해
내부적으로 Postman API 호출이 이루어지기 때문이다.

즉, Auth: Unsupported는
Local 모드에서는 정상적인 상태다.

7. 바로 써먹는 활용 예시

연결이 끝났다면
이제 Codex에게 자연어로 Postman 작업을 시켜볼 수 있다.

Workspace 목록 조회

Codex에게 이렇게 말해보자.

Postman MCP로 내 workspaces 목록 가져와줘 -> Collection 목록 조회
가장 최근 workspace의 collections 목록 보여줘 -> Collection 실행
특정 collection을 runCollection으로 실행해줘 -> API 스펙 / 컬렉션 기반 코드 생성

컬렉션이나 API 정의가 있다면
코드 생성까지 바로 이어갈 수 있다.

이 API 정의를 기반으로 axios client 코드 구조 만들어줘
응답 예시 기준으로 TypeScript 타입도 같이 뽑아줘

이 지점부터는
MSW handler 자동 생성, mock 시나리오 구성으로
자연스럽게 확장할 수 있다.

8. 마무리

Codex + Postman MCP(Local) 조합은
생각보다 훨씬 강력하다.

특히 컬렉션 기반으로

테스트를 실행하고
환경변수를 관리하고
API 스펙을 확인하는 흐름을

에디터 안에서 자연어로 처리할 수 있다는 점이 인상적이었다.

“API 문서 확인 → 요청 생성 → 테스트 실행”처럼
자주 반복되는 작업들이 눈에 띄게 줄어든다.

만약 Remote 방식이
인증이나 네트워크 이슈로 자주 흔들린다면,

Local(STDIO) 방식은 충분히 안정적인 대안이 될 수 있다.

👉2부 시작

2부. Postman 스펙으로 MSW 자동화 한 번에 끝내기

1부에서 Postman MCP를 붙였다면,
2부의 핵심은 딱 하나다.

“한 번에 끝내기”

내가 목표로 잡은 건 이거였다.

Postman 스펙만 있으면

MSW handler
mock DB
entities 타입
성공 / 에러 / 지연 같은 시나리오

이 모든 걸 스크립트 한 번으로 만들어버리는 것.

1. 최종 목표 흐름

2부에서 만들고 싶은 최종 그림은 이렇다.

Postman 스펙
↓
스크립트 실행
↓
MSW handler + mock DB + 타입 + 시나리오 자동 생성

즉,

프론트엔드 개발자는
API 구현을 기다리지 않고
바로 개발을 끝까지 진행할 수 있는 상태가 된다.

2. 스크립트 하나만 실행하면 된다

프론트엔드 개발자가 실제로 할 일은 많지 않다.

예를 들면,
아래 명령 하나만 실행하면 된다.

node generate-msw.ts

이 스크립트 하나로
자동으로 다음 파일들이 생성된다.

src/mocks/handlers/*
src/mocks/db/*
src/entities/types/*

여기까지 만들어지면
프론트 개발에 필요한 재료는 이미 다 준비된 셈이다.

물론 이 방식이 정답은 아니다.

굳이 스크립트를 실행하지 않아도,
이미 연결된 Postman MCP를 통해
Codex와 대화하면서 원하는 형태로 바로 만들어도 된다.

예를 들면,

“이 컬렉션 기준으로 MSW handler 만들어줘”
“응답 예시 기반으로 mock DB랑 타입만 먼저 만들어줘”
“이 API는 에러 / 지연 시나리오까지 같이 만들어줘”

처럼 필요한 만큼만 골라서 생성할 수도 있다.

다만 스크립트 방식의 장점은 분명하다.

한 번에 여러 API를 처리할 수 있고
스펙이 바뀌었을 때 다시 실행하기 쉽고
handler / mock DB / 타입 구조를 항상 동일하게 유지할 수 있다

그래서 이 글에서는
반복 작업은 스크립트로,
상황에 따라 달라지는 부분은 대화로 보완하는 방식을 기준으로 설명한다.

3. 스크립트가 하는 일 (4단계)

이 스크립트는 내부적으로
대략 다음 네 단계를 거친다.

1) Postman 스펙 읽기

먼저 Postman 컬렉션에서
필요한 정보들을 가져온다.

URL
HTTP Method
Request Body
Response 예시

즉,
API 스펙에 이미 정의돼 있는 정보만 사용한다.

2) MSW handler 자동 생성

예를 들어 이런 요청이 있다면,

POST /todo/list

스크립트는 자동으로
아래와 같은 MSW handler를 생성한다.

http.post('/todo/list', async () => {
  return HttpResponse.json({
    data: mockTodoList,
    exception: null,
  });
});

이 시점부터는
프론트에서는 실제 API가 붙은 것처럼 개발할 수 있다.

3) Mock DB 자동 생성

Postman에 응답 예시가 있다면,
그 내용을 그대로 mock 데이터로 만든다.

export const mockTodoList = [
  { id: 1, title: '장보기', status: 'DONE' },
];

mock 데이터를 따로 고민하거나
손으로 만들 필요가 없다.

4) entities 타입 구조 자동 생성

여기서 개인적으로 제일 중요하다고 느낀 부분이다.

응답 구조를 기반으로
entities 타입까지 자동으로 만들어준다.

export type Todo = {
  id: number;
  title: string;
  status: 'DONE' | 'PENDING';
};

export type TodoListResponse = {
  data: Todo[];
  exception: null | { code: string; message: string };
};

이렇게 되면
프론트는 타입이 이미 맞춰진 상태에서
개발을 시작할 수 있다.

4. Mock 시나리오까지 자동화

실제 개발에서는
성공 케이스만으로는 부족하다.

그래서 스크립트는
시나리오까지 함께 만들어준다.

예를 들면,

status=ERROR → 500 에러
status=EMPTY → 빈 배열
status=DELAY → 응답 지연

즉,

성공 / 실패 / empty / 지연
모든 케이스를
자동 생성된 handler에서 바로 테스트 가능하다.

5. 이렇게 되면 프론트 개발은 정말 편해진다

이 구조의 가장 큰 장점은 단순하다.

API 구현을 기다릴 필요가 없다
스펙이 바뀌면 스크립트만 다시 실행하면 된다
handler / mock DB / 타입이 한 번에 갱신된다

결국 목표는 하나다.

Postman 스펙만 있으면
프론트 개발은 끝까지 진행된다.
처음에 보여준 도식 그대로,
Postman 스펙 → MSW 자동화 흐름이 완성됐다.

백우진

안녕하세요.

이전 포스트

네이밍 컨벤션 정의, 종류

다음 포스트

MSW 수작업, 아직 하고 계신가요? Codex로 Postman 자동화 해봤습니다

이 글을 시작하기 전에: 기존 방식의 문제

이 글에서 해결하려는 핵심 문제

결과는 단순하다

이 글을 끝까지 읽고 나면, 이런 개발이 가능해진다

최종적으로 만들게 될 개발 흐름

왜 이게 중요한가?

이 글에서는 무엇을 다루나?

1부. Codex + Postman MCP 연결하기

2부. Postman 스펙으로 MSW 자동화하기

👉1부 시작

1. 요즘 MCP 덕분에 가능한 일들

2. 왜 Remote가 아니라 Local(STDIO)로 연결했나?

Local(STDIO)를 선택한 이유

3. 사전 준비물

Node.js 설치 확인

Postman API Key

4. Codex MCP 설정 파일 위치

5. Postman MCP(Local) 설정 추가하기

6. 연결 확인: `/mcp`

Auth: Unsupported가 떠도 괜찮다

7. 바로 써먹는 활용 예시

Workspace 목록 조회

8. 마무리

👉2부 시작

2부. Postman 스펙으로 MSW 자동화 한 번에 끝내기

1. 최종 목표 흐름

2. 스크립트 하나만 실행하면 된다

3. 스크립트가 하는 일 (4단계)

1) Postman 스펙 읽기

2) MSW handler 자동 생성

3) Mock DB 자동 생성

4) entities 타입 구조 자동 생성

4. Mock 시나리오까지 자동화

5. 이렇게 되면 프론트 개발은 정말 편해진다

네이밍 컨벤션 정의, 종류

AI는 왜 Storybook을 모를까? — MCP 서버를 만든 이유

0개의 댓글

MSW 수작업, 아직 하고 계신가요? Codex로 Postman 자동화 해봤습니다

이 글을 시작하기 전에: 기존 방식의 문제

이 글에서 해결하려는 핵심 문제

결과는 단순하다

이 글을 끝까지 읽고 나면, 이런 개발이 가능해진다

최종적으로 만들게 될 개발 흐름

왜 이게 중요한가?

이 글에서는 무엇을 다루나?

1부. Codex + Postman MCP 연결하기

2부. Postman 스펙으로 MSW 자동화하기

👉1부 시작

1. 요즘 MCP 덕분에 가능한 일들

2. 왜 Remote가 아니라 Local(STDIO)로 연결했나?

Local(STDIO)를 선택한 이유

3. 사전 준비물

Node.js 설치 확인

Postman API Key

4. Codex MCP 설정 파일 위치

5. Postman MCP(Local) 설정 추가하기

6. 연결 확인: /mcp

Auth: Unsupported가 떠도 괜찮다

7. 바로 써먹는 활용 예시

Workspace 목록 조회

8. 마무리

👉2부 시작

2부. Postman 스펙으로 MSW 자동화 한 번에 끝내기

1. 최종 목표 흐름

2. 스크립트 하나만 실행하면 된다

3. 스크립트가 하는 일 (4단계)

1) Postman 스펙 읽기

2) MSW handler 자동 생성

3) Mock DB 자동 생성

4) entities 타입 구조 자동 생성

4. Mock 시나리오까지 자동화

5. 이렇게 되면 프론트 개발은 정말 편해진다

네이밍 컨벤션 정의, 종류

AI는 왜 Storybook을 모를까? — MCP 서버를 만든 이유

0개의 댓글

6. 연결 확인: `/mcp`