LabHub

블로그

API 설계 & 테스트 도구 2026 — Bruno / Insomnia / Postman / Hoppscotch / Scalar / Mintlify / Buf 심층 비교

2026-05-16 · 35 분 읽기 · #api-design#api-testing#bruno#insomnia#postman#hoppscotch#stoplight#scalar#redoc#swagger-ui#mintlify#buf#grpc#protobuf#openapi#deep-dive

한국어English日本語

프롤로그 — "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, Apidogcurl 대체, 컬렉션 관리, 자동화
문서 / 뷰어Swagger UI, Redoc, Scalar, RapiDocOpenAPI 스펙을 사람이 읽을 사이트로
디자인 / 명세Stoplight Studio, Bruno (디자인 모드), ApidogAPI를 코드보다 먼저 설계, mock 생성
문서 SaaSReadMe, Mintlify, Bump.sh, Redocly호스팅된 개발자 포털, changelog, 검색
gRPC / ProtobufBuf, gRPCurl, Kreya, BloomRPC(deprecated), Postman gRPCProtobuf 디자인, 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의 진짜 가치다.

기능

약점

누가 쓰면 좋나

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은 이후:

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

2026년 현재 평가

누가 쓰면 좋나

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

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

2023년의 신뢰 위기

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

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

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

Postbot — AI 기능의 진심

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

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

기능 폭은 여전히 최고

약점

누가 쓰면 좋나

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

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

차별화

  1. PWA / 웹 우선 — 브라우저에서 즉시 사용 (hoppscotch.io). 설치 불필요.
  2. Apache 2.0 오픈소스 — 코어가 진짜로 오픈됨, 셀프호스트 가능
  3. Docker 한 줄로 셀프호스트 — 엔터프라이즈가 자체 인프라에 올림
  4. 빠르다 — Vue 기반, 가볍다
  5. 로컬 저장 — 기본은 브라우저 IndexedDB

기능

약점

누가 쓰면 좋나

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:

누가 쓰면 좋나

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 예시
import { apiReference } from '@scalar/hono-api-reference'

app.get(
  '/reference',
  apiReference({
    spec: { url: '/openapi.json' },
  })
)

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

Scalar vs Redoc vs Swagger UI

항목Swagger UIRedocScalar
디자인2014년스러움깔끔하지만 정적모던
Live 요청OX (Redocly에 유료 기능)O
다크 모드부분적OO
통합 한 줄OOO
자체 호스팅OO (CLI 별도)O
검색약함좋음매우 좋음
기본 라이센스Apache 2.0MITMIT

누가 쓰면 좋나

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

특징

누가 쓰면 좋나

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

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

왜 아직 쓰이나

약점

누가 쓰면 좋나

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

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

Mintlify

ReadMe.com

Mintlify vs ReadMe

항목MintlifyReadMe
디자인모던/미니멀더 풍부, 약간 무거움
MDX 친화성매우 좋음OK
AI 검색강력강력
외부 개발자 dashboard약함강함
API metrics약함강함
가격스타트업 친화엔터프라이즈 친화

누가 쓰면 좋나

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

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

Buf가 한 일

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

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 클라이언트가 깔끔하다.

누가 쓰면 좋나

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 클라이언트. 단순 호출뿐 아니라:

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

Postman / Insomnia / Bruno의 gRPC 지원

누가 쓰면 좋나

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

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

Apidog (중국 발)

Yaak (Rust 기반)

Bambda

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 사용 조직에서는 강력.

한계

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

토스 (Korean)

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

기술 블로그 toss.tech에 API 디자인 관련 글이 자주 올라온다.

Mercari (Japan)

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

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

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

마지막으로 정리.

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

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

큰 조직 / 엔터프라이즈

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

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

오픈소스 절대주의자

마무리

5년 사이의 변화 요약

안티패턴 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

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-api-design-testing-tools-2026-bruno-insomnia-postman-hoppscotch-scalar-mintlify-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다