프롤로그 — "Postman을 더 못 쓰겠다"는 말이 늘었다

2025년 어느 회사 슬랙에서 본 글: "Postman 새 버전에서 로그인 강제됐는데, 우리 컬렉션이 클라우드에 자동 동기화돼서 시큐리티 팀이 막아버렸어요. 다른 거 추천 받습니다."

그 아래 답글이 50개 넘게 달렸다. Bruno, Hoppscotch, Insomnia(구버전), Yaak, Apidog. 대안은 차고 넘쳤다. 5년 전이라면 "Postman 말고 뭐 있어?" 같은 질문 자체가 어색했지만, 2026년 현재는 정반대다. **Postman을 안 쓰는 게 기본값**이 된 팀이 늘었다.

이게 단순히 한 회사의 정책 변화 때문만은 아니다. API 도구 시장 자체가 **재편**됐다. Postman → Insomnia → Bruno로 이어진 "탈클라우드, 탈계정, 탈 lock-in" 흐름. OpenAPI 뷰어가 Swagger UI에서 Redoc, Scalar로 세대교체된 흐름. 문서는 ReadMe·Mintlify가 OpenAPI 스펙 한 줄에서 SaaS 사이트를 뽑아내는 흐름. gRPC는 Buf가 사실상 표준 툴체인이 된 흐름. 그리고 모든 것에 AI가 끼어든다 — Postbot, Insomnia AI는 자연어로 요청을 생성하고 응답을 설명한다.

이 글은 2026년 5월 현재 API 설계·테스트 도구의 지도를 그린다. 클라이언트, 문서, 디자인, 모킹, gRPC — 4분류로 나눠 정리하고, "당신 팀에 맞는 건 무엇인가"라는 마지막 질문까지.

1장 · 2026년 API 도구 지도 — 4분류로 보는 풍경

먼저 큰 그림. API 도구는 보통 한 카테고리에만 깔끔히 들어가지 않지만, 핵심 가치 제안으로 분류하면 네 덩어리다.

| 분류 | 도구 | 용도 |

| --- | --- | --- |

| 클라이언트 (요청 보내기) | Postman, Insomnia, Bruno, Hoppscotch, Yaak, Apidog | curl 대체, 컬렉션 관리, 자동화 |

| 문서 / 뷰어 | Swagger UI, Redoc, Scalar, RapiDoc | OpenAPI 스펙을 사람이 읽을 사이트로 |

| 디자인 / 명세 | Stoplight Studio, Bruno (디자인 모드), Apidog | API를 코드보다 먼저 설계, mock 생성 |

| 문서 SaaS | ReadMe, Mintlify, Bump.sh, Redocly | 호스팅된 개발자 포털, changelog, 검색 |

| gRPC / Protobuf | Buf, gRPCurl, Kreya, BloomRPC(deprecated), Postman gRPC | Protobuf 디자인, gRPC 호출 |

| 마켓플레이스 | RapidAPI, Postman Public API Network | 외부 API 발견, 게이트웨이 |

| AI 어시스트 | Postbot, Insomnia AI, Apidog AI | 자연어로 요청 생성, 응답 설명 |

분류가 깔끔하지 않은 이유는 도구들이 서로 겹치기 때문이다. Postman은 클라이언트+모킹+문서+gRPC+AI를 다 한다. Bruno는 클라이언트+간단 디자인+컬렉션 동기화(git)에 집중한다. Apidog는 디자인+클라이언트+문서+모킹을 한 곳에서 한다.

그래서 도구를 고를 때 두 가지를 본다.

1. **핵심 가치**가 어디인가 (요청 보내기? 명세 디자인? 문서?)

2. **데이터 소유권**이 어디 있나 (로컬 파일? 클라우드? git?)

2번이 2026년의 핵심 갈림길이다. Postman 사태가 부른 "내 데이터는 내 파일 시스템에" 운동이 Bruno, Yaak, file-based Insomnia 옵션을 만들었다. 클라우드 의존이 줄어드는 게 시장의 분명한 방향이다.

2장 · Bruno — file-based의 승자

가장 빠르게 성장한 도구. 2021년에 시작했고 2024년 Series A를 받았다. 한 줄 요약: **모든 컬렉션이 그냥 파일이고, git에 그대로 넣는다.**

왜 빠르게 자리잡았나

핵심 차별화 한 가지: **컬렉션 = 파일 트리**. Postman은 컬렉션을 JSON 한 덩어리로 묶고, 그 JSON은 클라우드에 동기화된다. Bruno는 컬렉션을 디렉토리로, 각 요청을 `.bru` 파일로 저장한다.

my-api/

bruno.json

environments/

dev.bru

prod.bru

users/

list-users.bru

create-user.bru

orders/

get-order.bru

각 `.bru` 파일은 사람이 읽을 수 있는 텍스트.

meta {

name: List Users

type: http

seq: 1

}

get {

url: {{baseUrl}}/users

body: none

auth: bearer

}

auth:bearer {

token: {{authToken}}

}

이게 왜 중요하냐. **git diff가 의미 있어진다**. PR 리뷰에서 "이 요청에 헤더가 하나 추가됐네"가 한눈에 보인다. Postman JSON에서 같은 변경을 보려면 JSON 한 덩어리의 diff를 봐야 한다. 코드 변경처럼 API 컬렉션 변경도 리뷰가 된다.

부수 효과: 브랜치를 따고 머지할 수 있다. PR로 컬렉션 변경을 받을 수 있다. CI에서 컬렉션 일관성을 검사할 수 있다. 이게 file-based의 진짜 가치다.

기능

- HTTP/REST 클라이언트 (Postman/Insomnia와 동급)

- gRPC 클라이언트 (2024 추가)

- GraphQL

- WebSocket / SSE

- 스크립트 (pre-request·post-response, JavaScript)

- 환경 변수 (per-environment `.bru` 파일)

- 시크릿 관리 (`.env.local`, git ignore)

- CLI (`bru run`) — CI에서 컬렉션 실행

- OpenAPI import / export

약점

- 팀 공유 기능이 git에 묶여 있다 — git을 안 쓰면 매력이 절반

- gRPC는 아직 Postman/Kreya만 못함

- 디자인 모드(스펙 우선 설계)는 약함 — Stoplight/Apidog 영역

- 클라우드 동기화가 필요한 팀에는 별도 유료 옵션이 필요

누가 쓰면 좋나

- git 기반 워크플로가 자리잡은 엔지니어링 팀

- API 컬렉션을 코드처럼 PR로 리뷰하고 싶은 팀

- 데이터 외부 클라우드 노출이 컴플라이언스 이슈인 회사

- 1인 개발자가 가볍게 쓰기에도 충분

> Bruno의 메시지: **"컬렉션은 코드다. git이 있는데 왜 별도 SaaS가 필요한가."**

3장 · Insomnia (Kong) — 두 번의 신뢰 위기

Insomnia는 한때 Postman 대안으로 사랑받았다. 가볍고, 깔끔하고, 로컬에서 잘 돌았다. 2019년 Kong에 인수됐고, 그 후의 행보가 갈렸다.

2023년의 위기 — Insomnia 8 로그인 강제

2023년 8월 Insomnia 8 릴리스가 큰 논란을 불렀다. 새 버전이 **로그인을 사실상 강제**했고, 로컬 데이터를 새로운 cloud 동기화 모델로 마이그레이트하려 했다. 일부 사용자는 동의 없이 데이터가 클라우드에 올라간 것처럼 보였다.

커뮤니티가 폭발했다. GitHub 이슈에는 수백 개 댓글이 달렸고, 많은 사용자가 Insomnia 7.x로 다운그레이드하거나 Bruno로 옮겼다. Kong은 사과하고, Scratch Pad 모드(계정 없이 사용)를 추가하고, 데이터 마이그레이션 방식을 바꾸겠다고 발표했다.

2024–2025년의 회복 시도

Kong은 이후:

- Local Vault 모드 — 로컬에 모든 데이터 보관

- Open source 라이센스 유지 (Apache 2.0)

- gRPC, GraphQL, WebSocket 강화

- Insomnia AI — Postbot에 대응

여전히 강한 도구다. 특히 Kong Konnect 게이트웨이와의 통합은 다른 클라이언트가 못 따라간다. 하지만 한 번 잃은 신뢰는 천천히 돌아왔다.

2026년 현재 평가

- 단일 도구로서의 완성도는 여전히 높음

- Kong Gateway / Konnect를 쓰는 팀에는 자연스러운 선택

- 하지만 file-based git 워크플로는 Bruno보다 약함

- "다시 강제로 cloud 갈까?" 라는 우려가 완전히 사라지지는 않음

누가 쓰면 좋나

- Kong Konnect / Kong Gateway 사용 팀

- Postman은 무거운데 Bruno의 git-only 모델은 부담스러운 1인 개발자

- 여러 프로토콜(REST + gRPC + GraphQL + WebSocket)을 한 도구로 다루고 싶은 팀

4장 · Postman — 거인의 그늘과 AI 베팅

Postman은 여전히 가장 큰 회사다. 2,500만 명 이상의 사용자, Series E 후 평가액 56억 달러(2021년 시점). 하지만 시장 분위기는 분명히 바뀌었다.

2023년의 신뢰 위기

2023년 5월 Postman v10에서 Scratch Pad의 향후 폐지 계획이 알려졌다 — 즉, 계정 없이 쓸 수 있는 모드를 단계적으로 줄이려 했다. 추가로 컬렉션은 기본적으로 Postman 클라우드에 저장된다는 점이 다시 부각됐다.

엔터프라이즈 보안팀이 "고객 API 키와 페이로드가 외부 SaaS에 저장된다"는 이유로 사용 금지를 내렸고, 많은 팀이 대안을 찾았다. 그 결과:

- Bruno 사용자 폭증

- Insomnia 회귀

- Hoppscotch 셀프호스트

- Yaak·Apidog 신규 진입

Postman은 결국 Scratch Pad를 유지하기로 했고, 로컬 컬렉션 옵션을 다시 강화했다. 하지만 "기본값이 클라우드"라는 인상은 남았다.

Postbot — AI 기능의 진심

Postman이 빠르게 베팅한 영역이 AI다. **Postbot**:

- 자연어로 요청 생성 ("GitHub API에서 내 repo 목록 가져와")

- 테스트 자동 생성 (응답 보고 assert 문 작성)

- 응답 설명 ("이 JSON은 뭘 의미해?")

- 디버깅 보조 (왜 401이 나왔는지)

GPT-5/Claude 4.x 시대에 AI 기능은 차별점이라기보다 기본값이지만, Postman은 **컬렉션·history·환경**이라는 거대한 context를 가지고 있어서 응답 품질이 다른 도구의 stand-alone AI보다 한 수 위다.

기능 폭은 여전히 최고

- REST·GraphQL·gRPC·WebSocket·SOAP

- Mock 서버

- Public API Network (마켓플레이스)

- Monitor (스케줄된 컬렉션 실행)

- Newman CLI (CI에서 컬렉션 실행)

- Postman Flows (visual 워크플로)

- Postman Live Collaboration (실시간 협업)

- Postman Insights (organization-wide API 분석)

약점

- 데스크탑 앱이 무겁다 (Electron, 가끔 GB 단위 RAM)

- 클라우드 default와 컬렉션 동기화가 컴플라이언스 마찰

- 가격 — 팀 가격이 다른 도구 대비 비싸다

- git diff 친화성이 약하다

누가 쓰면 좋나

- 가장 폭넓은 기능이 필요한 큰 팀 (REST+gRPC+Mock+Monitor를 한 곳에)

- Public API Network에 자기 API를 게시하고 싶은 회사

- Postman을 이미 표준으로 쓰고 있어서 마이그레이션 비용이 큰 조직

5장 · Hoppscotch — 완전 오픈소스, 셀프호스트 친화

Hoppscotch는 인도에서 시작된 오픈소스 API 클라이언트. 2019년 시작 (당시 이름 Postwoman, 상표 이슈로 이름 바꿈). 핵심: **완전히 오픈소스**, **웹에서 즉시 실행**, **셀프호스트 가능**.

차별화

1. **PWA / 웹 우선** — 브라우저에서 즉시 사용 (hoppscotch.io). 설치 불필요.

2. **Apache 2.0 오픈소스** — 코어가 진짜로 오픈됨, 셀프호스트 가능

3. **Docker 한 줄로 셀프호스트** — 엔터프라이즈가 자체 인프라에 올림

4. **빠르다** — Vue 기반, 가볍다

5. **로컬 저장** — 기본은 브라우저 IndexedDB

기능

- REST, GraphQL, WebSocket, SSE, MQTT, gRPC

- 환경 변수, 컬렉션

- pre-request / test 스크립트

- 팀 동기화 (Hoppscotch Cloud 또는 셀프호스트)

- Hoppscotch Agent (CORS 우회용 데스크탑 에이전트)

약점

- 기능 폭이 Postman/Insomnia보다 좁다

- 데스크탑 앱은 있지만 웹 우선 설계라 종종 어색

- 팀 협업은 클라우드/셀프호스트 인프라가 필요

- gRPC는 비교적 최근에 추가, 안정성 차이

누가 쓰면 좋나

- 오픈소스 절대주의자, 셀프호스트가 정책인 조직

- 가벼운 클라이언트 하나 빠르게 쓰고 싶은 1인 개발자

- 브라우저에서 즉시 동료에게 링크로 공유하고 싶을 때

- 인도/동남아 회사 (커뮤니티가 두텁다)

6장 · Stoplight Studio (SmartBear) — 디자인-퍼스트 진영의 정체

Stoplight Studio는 한때 **API 디자인-퍼스트**(코드보다 OpenAPI 스펙 먼저)의 대표 주자였다. 비주얼 에디터로 OpenAPI 스펙을 만들고, mock 서버를 자동 생성하고, 문서를 호스팅했다. 2023년 SmartBear에 인수됐다.

인수 후의 정체

SmartBear는 Swagger UI(원조), SoapUI, ReadyAPI 같은 API 도구 포트폴리오를 가진 회사다. Stoplight 인수는 자연스러웠지만, 인수 후 Stoplight Studio의 개발 속도가 눈에 띄게 줄었다. 커뮤니티는 "Stoplight도 결국 SmartBear의 enterprise sales 도구가 되는가?"라는 우려를 표했다.

2026년 현재 Stoplight Studio:

- 여전히 OpenAPI 디자인을 위한 가장 완성도 높은 비주얼 에디터 중 하나

- Spectral (OpenAPI linter)는 여전히 사실상 표준 — Redocly, Bruno, GitHub Action 등 어디서나 쓰임

- Prism (mock 서버)도 여전히 표준

- 하지만 새 기능 페이스는 Scalar/Apidog 같은 신예에 밀림

누가 쓰면 좋나

- 비개발자 PM/디자이너가 OpenAPI 스펙을 함께 편집해야 하는 팀

- 엔터프라이즈 SmartBear 라이센스가 이미 있는 조직

- Spectral / Prism은 도구와 무관하게 거의 모든 팀에 추천

7장 · Scalar — 모던 OpenAPI 뷰어의 떠오르는 별

Scalar는 2023년에 등장해서 OpenAPI 뷰어 시장을 흔든 신예다. 2024년 시드를 받았고, 2025년에 더 큰 라운드. 핵심: **Swagger UI는 너무 못생겼고 Redoc은 너무 정적이다. 우리가 다시 만든다.**

왜 빠르게 자리잡았나

1. **디자인 품질** — 2026년 디자인 트렌드에 맞는 깔끔한 UI

2. **다크 모드, 키보드 단축키, 검색** — Postman 수준의 UX

3. **Live 요청 — 문서에서 바로 API 호출 가능**

4. **Vue/React/Hono/Express 통합** — 코드에 한 줄 추가하면 자동 마운트

5. **Open source (MIT)** — 자체 호스팅 친화

사용 패턴

// Hono 예시

app.get(

'/reference',

apiReference({

spec: { url: '/openapi.json' },

})

)

이게 끝이다. 백엔드에 한 줄 추가하면 `/reference`에서 Scalar UI로 OpenAPI를 본다.

Scalar vs Redoc vs Swagger UI

| 항목 | Swagger UI | Redoc | Scalar |

| --- | --- | --- | --- |

| 디자인 | 2014년스러움 | 깔끔하지만 정적 | 모던 |

| Live 요청 | O | X (Redocly에 유료 기능) | O |

| 다크 모드 | 부분적 | O | O |

| 통합 한 줄 | O | O | O |

| 자체 호스팅 | O | O (CLI 별도) | O |

| 검색 | 약함 | 좋음 | 매우 좋음 |

| 기본 라이센스 | Apache 2.0 | MIT | MIT |

누가 쓰면 좋나

- 새 API의 공개 문서를 깔끔하게 만들고 싶은 팀

- Swagger UI의 디자인이 답답한 팀

- 문서에서 바로 API를 호출해보게 하고 싶은 팀

8장 · Redoc / Redocly — 오픈소스 뷰어 + 상용 CLI

Redoc은 오랫동안 가장 깔끔한 OpenAPI 뷰어로 인정받았다. 2024년 이후 Redocly(상용 회사)는 CLI·linter·portal 같은 유료 도구를 강화했다.

두 갈래

1. **Redoc (open source, MIT)** — 단일 페이지 OpenAPI 뷰어

2. **Redocly CLI (상용)** — multi-spec portal, linter, bundle, OAS-to-website

특징

- 3-패널 레이아웃이 OpenAPI 문서의 사실상 표준이 됨

- 큰 스펙(100+ endpoint)도 잘 견딘다

- Stripe, Docker, Twilio 같은 대형 API 문서가 Redoc 또는 Redoc 파생을 씀

- 무료 Redoc은 Live 요청을 안 지원 (Redocly 유료에서만)

누가 쓰면 좋나

- 큰 OpenAPI 스펙(수백 endpoint)의 정적 문서가 필요한 팀

- Stripe 스타일의 클래식한 3-패널 레이아웃을 원하는 팀

- 상용 Redocly CLI로 multi-spec dev portal을 만들고 싶은 회사

9장 · Swagger UI — 클래식, 아직 살아있다

원조. 2011년 시작, SmartBear가 인수하고 OpenAPI Initiative로 기증. 거의 모든 백엔드 프레임워크가 한 줄로 Swagger UI를 마운트할 수 있게 한다 (FastAPI, Spring, NestJS, Express, ...).

왜 아직 쓰이나

- **개발 환경 default** — FastAPI의 `/docs`, NestJS의 `@nestjs/swagger` 등

- **try-it-out** 버튼이 가장 친숙

- **모든 백엔드 프레임워크가 알아서 마운트**

- **Apache 2.0**

약점

- 2014년 디자인 그대로

- 큰 스펙에서 느려진다

- 검색이 약함

- 모바일/태블릿 친화성 낮음

누가 쓰면 좋나

- 내부 개발/디버깅용 문서 (Scalar로 갈아탈 만큼의 이득이 없을 때)

- 프레임워크가 default로 깔아준 걸 그대로 쓰는 팀

10장 · Mintlify / ReadMe.com — 문서 SaaS의 두 강자

이 카테고리는 "OpenAPI 스펙 한 줄에서 풀-스택 개발자 포털을 뽑아낸다"는 약속이다.

Mintlify

- 2022년 시작, 2024년 빠르게 성장

- MDX 기반 문서

- OpenAPI 자동 import, 자동 API 페이지 생성

- 풀텍스트 검색 (AI 기반 챗 UI 포함)

- GitHub 연동 — repo의 markdown/MDX 변경이 자동 반영

- 가격은 유료 (스타트업/엔터프라이즈 플랜)

- Stripe, OpenAI, Anthropic 등이 사용

ReadMe.com

- 더 오래된 강자 (2014년 시작)

- API reference, guides, changelog, 검색을 한 곳에

- Try-it 콘솔이 강력

- Metrics — 어떤 endpoint가 자주 호출되는지 추적

- Developer Dashboard — 외부 개발자별 키 관리

- API 사용 분석 — 대시보드에서 호출량 추이

Mintlify vs ReadMe

| 항목 | Mintlify | ReadMe |

| --- | --- | --- |

| 디자인 | 모던/미니멀 | 더 풍부, 약간 무거움 |

| MDX 친화성 | 매우 좋음 | OK |

| AI 검색 | 강력 | 강력 |

| 외부 개발자 dashboard | 약함 | 강함 |

| API metrics | 약함 | 강함 |

| 가격 | 스타트업 친화 | 엔터프라이즈 친화 |

누가 쓰면 좋나

- 외부 개발자가 쓰는 공개 API가 있는 회사

- 문서를 GitHub PR로 관리하고 싶은 팀 (Mintlify)

- 외부 개발자별 API 키/사용량을 dashboard로 관리하고 싶은 팀 (ReadMe)

11장 · Buf — Protobuf/gRPC 생태계의 표준

REST 진영이 흔들리는 동안 gRPC/Protobuf 진영에는 사실상 표준이 자리잡았다. **Buf**.

Buf가 한 일

Protobuf은 강력하지만 도구가 흩어져 있었다 — `protoc`는 어려웠고, 의존성 관리가 없었으며, 린팅이 없었다. Buf는 다음을 한 곳에 모았다.

- **`buf build`** — `.proto`를 빠르게 컴파일

- **`buf lint`** — Protobuf 스타일/Best practice 검사

- **`buf breaking`** — 스키마 호환성 깨짐 자동 감지 (CI 필수)

- **`buf format`** — `.proto` 포맷터

- **`buf generate`** — `protoc-gen-*` 플러그인을 yaml 설정으로 실행

- **Buf Schema Registry (BSR)** — Protobuf의 npm/pypi 같은 것

CI에서 가장 쓸모 있는 것

.github/workflows/proto.yml

- run: buf lint

- run: buf breaking --against '.git#branch=main'

이 두 줄로 "스타일 위반"과 "기존 클라이언트를 깨는 변경"을 PR에서 자동 차단한다. Protobuf을 운영 환경에서 쓰는 모든 팀이 켜야 하는 안전망.

Buf Connect

Buf가 만든 RPC 프로토콜. gRPC, gRPC-Web, Connect protocol을 한 코드베이스에서 지원. 브라우저에서 fetch로 gRPC를 부를 수 있다. TypeScript/Go/Kotlin 클라이언트가 깔끔하다.

누가 쓰면 좋나

- Protobuf/gRPC를 production에서 쓰는 모든 팀 — 사실상 필수

- 스키마를 여러 팀이 공유하는 회사 (BSR로 의존성 관리)

12장 · gRPCurl / Kreya — gRPC 클라이언트

gRPC 호출 자체는 별도 도구가 필요하다 (HTTP의 curl처럼).

gRPCurl — CLI

grpcurl -d '{"name": "world"}' localhost:50051 helloworld.Greeter/SayHello

`curl`의 gRPC 버전. 서버 reflection을 켜면 스키마를 자동으로 가져온다. CI 스크립트, 디버깅, ad-hoc 호출에 쓴다. 공식 grpc 프로젝트가 아닌 fullstorydev에서 메인테인.

Kreya

GUI gRPC 클라이언트. 단순 호출뿐 아니라:

- 스트리밍 (server-side, client-side, bidirectional)

- Protobuf import (BSR/local)

- 환경 변수, 컬렉션, 스크립트

- REST/GraphQL도 지원 (모든 프로토콜 한 곳에)

Postman/Insomnia가 gRPC를 지원하긴 하지만, gRPC 전용 도구의 정밀도가 필요하면 Kreya가 일반적으로 더 매끄럽다.

Postman / Insomnia / Bruno의 gRPC 지원

- Postman gRPC — reflection, .proto import, streaming 다 됨, 가장 폭넓음

- Insomnia gRPC — Kong이 강화한 영역, 잘 작동

- Bruno gRPC — 2024년 추가, 기본은 되지만 streaming UX가 아직 거칠다

누가 쓰면 좋나

- gRPCurl — 디버깅·CI 스크립트·ad-hoc 호출

- Kreya — gRPC를 매일 다루는 백엔드 개발자

- Postman/Insomnia — gRPC와 REST를 한 도구로 묶고 싶은 팀

13장 · Apidog / Yaak / Bambda — 신예 3종

지난 2년에 등장한 새 도구들. 셋 다 "Postman의 무게 vs Bruno의 git-only" 사이를 노린다.

Apidog (중국 발)

- 한 도구에서 디자인 + 클라이언트 + Mock + 문서 + 자동화

- Stoplight + Postman + Mintlify를 합친 야망

- 무료 티어가 관대

- AI 기능 (자연어로 endpoint 디자인)

- 단점: UI가 약간 어수선, 일부 번역이 매끄럽지 않음

- 누구: 한 도구로 끝내고 싶고 Postman 가격이 부담인 팀

Yaak (Rust 기반)

- Bruno와 비슷한 file-based 철학

- Rust + Tauri로 만들어서 Electron보다 가벼움

- 한 명이 풀타임으로 만들고 있는 인디 도구

- 깔끔한 UI, 빠른 시작

- 단점: 기능 폭이 아직 좁다

- 누구: Bruno도 무겁다고 느끼는 1인 개발자, Rust 생태계 팬

Bambda

- 자바스크립트 기반 API 클라이언트

- WebSocket·SSE·gRPC 다 됨

- AI 기능 강조

- 아직 사용자 베이스가 작음

- 누구: 새로 시작하는 작은 팀이 실험적으로 써볼 만함

14장 · AI 통합 — Postbot, Insomnia AI

2026년 거의 모든 도구가 AI 기능을 단다. 진짜 가치는 어디 있나.

잘하는 영역

1. **요청 생성** — "GitHub API에서 organization의 repo 목록 가져와" → 요청이 자동 작성

2. **응답 설명** — 응답 JSON 보고 각 필드가 뭘 의미하는지 설명

3. **테스트 자동 작성** — 응답 보고 assert 문 생성 (status code, schema 등)

4. **OpenAPI 디자인 보조** — 자연어 description에서 schema 초안

5. **에러 디버깅** — 401/403/500 보고 가능성 있는 원인 나열

Postbot의 강점

Postman은 거대한 컬렉션 + history + 환경 변수를 context로 가진다. AI가 "당신의 컬렉션에 있는 다른 요청처럼" 새 요청을 만들 수 있다. 다른 도구의 stand-alone AI는 이런 회사 내부 context가 없어서 일반적인 응답을 한다.

Insomnia AI의 강점

Kong Konnect와 통합 — Kong이 알고 있는 API 카탈로그와 정책을 AI가 이해한다. Konnect 사용 조직에서는 강력.

한계

- 자연어가 모호하면 AI가 잘못 추측 — 결국 사람이 수정

- 응답 설명은 도움이 되지만 보안 정보를 외부 모델에 보낼 위험 (엔터프라이즈는 self-hosted 옵션 필요)

- 테스트 생성은 시작점은 좋지만 도메인 로직은 사람이 보강

15장 · 한국 / 일본 — 토스, Mercari

토스 (Korean)

토스는 API 디자인을 굉장히 진지하게 다룬다고 알려진 회사다. 외부 공개 API는 [docs.tosspayments.com](https://docs.tosspayments.com)에서 볼 수 있고, 자체 문서 시스템은 깔끔한 디자인과 일관된 어휘로 유명. 내부적으로는:

- API 디자인 review 문화 (PR로 OpenAPI 변경을 받음)

- 한국어/영어 이중 문서

- changelog와 deprecation 정책이 명시적

- SDK가 여러 언어로 자동 생성 (OpenAPI generator 변형)

기술 블로그 [toss.tech](https://toss.tech)에 API 디자인 관련 글이 자주 올라온다.

Mercari (Japan)

Mercari는 일본의 대형 마켓플레이스. 내부적으로 gRPC를 광범위하게 쓰고, Protobuf 스키마 거버넌스 시스템을 자체 구축한 사례로 유명. [engineering.mercari.com](https://engineering.mercari.com) 블로그에 Buf 도입, Connect protocol 채택 같은 글이 있다. 외부 공개 API는 작은 편이지만, 내부 마이크로서비스 통신을 위한 도구 채택이 빠르다.

또 다른 일본 사례: LINE은 자체 API 도구 ecosystem(LY corp.)을 가지고, SmartBear ReadyAPI를 광범위하게 쓰는 엔터프라이즈도 많다.

16장 · 누가 무엇을 골라야 하나

마지막으로 정리.

1인 개발자 / 작은 사이드 프로젝트

- **클라이언트**: Bruno (git 친화) 또는 Hoppscotch (브라우저에서 즉시)

- **문서**: Scalar (예쁘다) 또는 framework default Swagger UI

- **gRPC**: gRPCurl

- **AI**: 없어도 됨 (혹은 ChatGPT/Claude desktop)

작은 엔지니어링 팀 (5~20명)

- **클라이언트**: Bruno + git (PR 리뷰), 보조로 Hoppscotch

- **디자인**: OpenAPI 직접 작성 + Spectral lint (Bruno에 같이 넣어둠)

- **문서**: Scalar 자체 호스팅 또는 Mintlify (외부 공개 시)

- **gRPC**: Buf + Kreya 또는 Postman gRPC

- **AI**: ChatGPT/Claude로 보조 (도구 내장은 선택)

큰 조직 / 엔터프라이즈

- **클라이언트**: Postman (가장 완성도 높음) 또는 Insomnia (Kong 사용 시)

- **디자인**: Stoplight Studio (PM/디자이너 협업) 또는 Apidog

- **문서**: ReadMe (외부 개발자 dashboard 필요 시) 또는 Mintlify (모던 UX)

- **gRPC**: Buf BSR + Postman gRPC

- **AI**: Postbot 또는 Insomnia AI (조직 context 활용)

- **컴플라이언스**: 셀프호스트 옵션(Hoppscotch, Insomnia Local Vault, Bruno) 검토

API 우선 회사 (제품이 API인 곳, Stripe·Twilio급)

- **디자인**: OpenAPI/Protobuf를 git에서 source of truth로

- **클라이언트**: 내부적으로 Bruno + 외부 공개 try-it은 Scalar/Redoc

- **문서**: 자체 도메인에 호스팅 (Redocly enterprise, Mintlify enterprise, 또는 자체 구축)

- **gRPC**: Buf + Connect (브라우저 호환)

- **마켓플레이스**: 자체 dev portal + RapidAPI (확장 시)

폐쇄형 (모든 API가 사내용)

- **클라이언트**: Bruno + git (가장 자연스러움)

- **디자인**: OpenAPI를 코드 옆에 두기 (`openapi.yaml` 같은 파일)

- **문서**: Scalar 셀프 호스트 또는 framework default

- **gRPC**: Buf + Kreya/gRPCurl

- **AI**: 사내 LLM 정책에 따름

오픈소스 절대주의자

- **클라이언트**: Hoppscotch (셀프호스트) 또는 Bruno

- **문서**: Redoc + Spectral + Prism

- **gRPC**: Buf (Apache 2.0) + gRPCurl

- **마켓플레이스**: 별도 dev portal 직접 운영

마무리

5년 사이의 변화 요약

- **클라이언트**: Postman 독점 → Bruno/Insomnia/Hoppscotch 다극화

- **데이터 소유**: 클라우드 default → 로컬/git 옵션이 다시 중요

- **문서**: Swagger UI 독점 → Scalar/Redoc/Mintlify가 세대교체

- **gRPC**: 도구 혼란 → Buf가 사실상 표준

- **AI**: 부가 기능 → 거의 모든 도구의 기본값

- **컴플라이언스**: 무신경 → 셀프호스트/로컬 모드가 selection criteria

안티패턴 10가지

1. "큰 도구가 안전하다"고 Postman을 무조건 채택 — 컴플라이언스 마찰을 늦게 발견

2. 데이터 소유 정책 없이 SaaS API 클라이언트를 표준화 — 시큐리티 팀에 막힘

3. 컬렉션을 git에 안 올림 — PR 리뷰가 불가능

4. OpenAPI 스펙 없이 코드만 — 문서는 항상 코드와 어긋남

5. Spectral / Buf breaking 없이 운영 — 호환성 깨짐을 사람이 발견

6. Swagger UI 그대로 외부 공개 — 디자인이 회사 인상을 깎아먹음

7. AI 응답을 그대로 신뢰 — assert 문이 잘못 생성됨

8. gRPC를 Postman 안에만 — gRPC 전용 도구의 정밀도가 필요할 때 못 따라감

9. mock 서버 없이 frontend 시작 — backend 대기로 sprint 지연

10. 문서를 사람이 손으로 작성 — 일주일 후 코드와 어긋남

다음 글 예고

다음 글 후보: **OpenAPI 3.1 깊이 파기 — JSON Schema 통합과 webhook**, **Connect protocol vs gRPC vs REST — 2026년의 선택**, **API mocking 도구 비교 — Prism, MSW, WireMock**.

> "API 도구는 코드의 도구가 아니라, **API를 만드는 사람들 간의 합의의 도구**다. 합의가 깔끔하면 도구도 가볍다."

— API 설계 & 테스트 도구 2026, 끝.

참고 / References

- [Bruno — Opensource API client](https://www.usebruno.com/)

- [Bruno GitHub — usebruno/bruno](https://github.com/usebruno/bruno)

- [Bruno Series A announcement (2024)](https://www.usebruno.com/blog/series-a)

- [Insomnia — Kong](https://insomnia.rest/)

- [Insomnia 8 controversy — GitHub issues](https://github.com/Kong/insomnia/issues/6440)

- [Postman](https://www.postman.com/)

- [Postman Scratch Pad announcement](https://blog.postman.com/scratch-pad-postman-v10/)

- [Postbot — AI in Postman](https://www.postman.com/postbot/)

- [Hoppscotch](https://hoppscotch.io/)

- [Hoppscotch GitHub — hoppscotch/hoppscotch](https://github.com/hoppscotch/hoppscotch)

- [Stoplight](https://stoplight.io/)

- [SmartBear acquires Stoplight](https://smartbear.com/news/2023/smartbear-acquires-stoplight/)

- [Spectral — OpenAPI linter](https://stoplight.io/open-source/spectral)

- [Prism — mock server](https://stoplight.io/open-source/prism)

- [Scalar](https://scalar.com/)

- [Scalar GitHub — scalar/scalar](https://github.com/scalar/scalar)

- [Redoc GitHub — Redocly/redoc](https://github.com/Redocly/redoc)

- [Redocly](https://redocly.com/)

- [Swagger UI](https://swagger.io/tools/swagger-ui/)

- [Mintlify](https://mintlify.com/)

- [ReadMe.com](https://readme.com/)

- [Buf](https://buf.build/)

- [Buf Schema Registry](https://buf.build/explore)

- [Buf Connect](https://connectrpc.com/)

- [gRPCurl — fullstorydev/grpcurl](https://github.com/fullstorydev/grpcurl)

- [Kreya](https://kreya.app/)

- [Apidog](https://apidog.com/)

- [Yaak](https://yaak.app/)

- [RapidAPI Hub](https://rapidapi.com/hub)

- [Kong Konnect](https://konghq.com/products/kong-konnect)

- [TossPayments API Docs](https://docs.tosspayments.com/)

- [Toss Tech blog](https://toss.tech/)

- [Mercari Engineering blog](https://engineering.mercari.com/)

- [OpenAPI Initiative](https://www.openapis.org/)

- [JSON Schema](https://json-schema.org/)