Bruno API 클라이언트 2026 — Postman 대안 실전 가이드

API 테스트 도구, 왜 바꿔야 하는가

API를 개발하거나 외부 서비스와 연동하는 일을 하고 있다면, API 테스트 도구는 매일 손에 쥐는 연장과 같습니다. 오랫동안 그 자리를 지켜온 도구는 Postman이었습니다. 하지만 최근 몇 년 사이 Postman은 클라우드 계정 로그인을 강제하고, 무료 사용 범위에 제약을 걸며, Electron 기반 앱이 1GB가 넘는 메모리를 잡아먹는 방향으로 변해 왔습니다. 많은 개발자가 “API 요청 하나 보내려고 왜 회원가입을 해야 하지?”라는 의문을 품기 시작했습니다.

Bruno API 클라이언트는 이 불만에 정확히 답하는 오픈소스 API 테스트 도구입니다. Postman과 비슷한 GUI를 갖추면서도, 근본적으로 다른 설계 철학을 채택했습니다. API 컬렉션을 클라우드가 아닌 내 컴퓨터의 파일시스템에 저장하고, Git으로 버전 관리하며, 인터넷 연결 없이도 완벽하게 동작합니다. 2023년 오픈소스로 공개된 이후 GitHub 스타가 30,000개를 넘기며 가파르게 성장했고, 2026년 현재 Postman의 가장 유력한 대안으로 자리 잡았습니다.

이 글에서는 Bruno의 핵심 차별점을 짚은 뒤, 설치부터 환경 변수 관리, 테스트 자동화, CI/CD 통합, 그리고 기존 Postman 사용자를 위한 마이그레이션까지 순서대로 안내합니다.

Bruno API 클라이언트가 특별한 3가지 이유

API 테스트 도구는 수없이 많습니다. Insomnia, Hoppscotch, Thunder Client, HTTPie 등 선택지가 넘칩니다. 그런데 Bruno가 유독 빠르게 사용자를 확보한 이유는 세 가지 핵심 원칙 때문입니다.

첫째, 파일 기반 저장 — Bru 마크업 언어

Postman은 API 컬렉션을 자체 클라우드나 로컬 데이터베이스에 저장합니다. 사용자는 그 데이터가 어디에 있는지, 어떤 형식인지 직접 확인할 수 없습니다. Bruno는 정반대입니다. 모든 API 요청을 일반 텍스트 파일로 저장합니다.

Bruno는 이를 위해 Bru라는 자체 마크업 언어를 설계했습니다. 각 API 요청은 하나의 .bru 파일이 되고, 폴더 구조가 곧 컬렉션의 구조가 됩니다. 텍스트 에디터로 열어 내용을 직접 확인하고 수정할 수도 있습니다. 다음은 사용자 목록을 조회하는 GET 요청의 Bru 파일 예시입니다.

meta {
  name: 사용자 목록 조회
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/api/users
  body: none
  auth: bearer
}

auth:bearer {
  token: {{accessToken}}
}

headers {
  Accept: application/json
}

직관적이고 읽기 쉬운 문법입니다. JSON처럼 중괄호와 따옴표가 난무하지 않고, YAML처럼 들여쓰기에 민감하지도 않습니다. 사람이 읽기 편한 형식이라는 점이 Bru 언어의 핵심 가치입니다. 또한 텍스트 기반이기 때문에 grep이나 sed 같은 터미널 도구로 일괄 검색·치환이 가능합니다. API 서버 도메인이 바뀌었을 때 수십 개 파일을 GUI에서 하나씩 수정하는 대신, 터미널 명령 한 줄로 끝낼 수 있다는 뜻입니다.

둘째, Git과 완벽한 호환

파일 기반 저장의 가장 큰 수혜자는 Git입니다. Bruno 컬렉션은 프로젝트 소스 코드와 함께 Git 저장소에 커밋됩니다. 이것이 가져오는 변화는 생각보다 큽니다.

• 버전 이력: API 요청이 언제, 누가, 왜 변경했는지 Git 로그로 추적할 수 있습니다.
• 코드 리뷰: PR(Pull Request)에서 API 요청 변경 사항을 팀원이 리뷰할 수 있습니다. 새 API 엔드포인트를 추가하면서 테스트 요청도 같은 PR에 포함하면, 리뷰어가 동작을 바로 확인할 수 있습니다.
• 브랜치 전략: feature 브랜치에서 새 API를 추가하고, main 브랜치에 머지하는 기존 개발 워크플로우를 그대로 따릅니다.
• 충돌 해결: 두 사람이 같은 요청을 수정하면 Git의 머지 충돌로 해결합니다. 텍스트 파일이므로 diff가 명확합니다.

Postman에서 팀 협업을 하려면 유료 Team 플랜에 가입하고, Postman 클라우드를 통해 컬렉션을 공유해야 합니다. Bruno에서는 그냥 git push를 하면 됩니다. 팀원은 git pull로 최신 컬렉션을 받아옵니다. 별도의 동기화 도구도, 유료 플랜도 필요 없습니다.

셋째, 오프라인 우선, 계정 불필요

Bruno는 클라우드 계정이 없습니다. 설치하면 바로 쓸 수 있습니다. 로그인 화면도, 가입 유도 팝업도, 구독 배너도 없습니다. 비행기 안에서든, VPN이 차단된 사내 네트워크에서든, 인터넷이 끊긴 카페에서든 완벽하게 작동합니다. 데이터는 100% 로컬에 있으므로, 클라우드 서비스 장애가 내 작업을 멈추는 일도 없습니다.

개인정보 보호 관점에서도 이점이 큽니다. API 키, 인증 토큰, 테스트 데이터가 외부 서버에 전송되지 않습니다. 금융이나 의료처럼 데이터 외부 반출에 민감한 환경에서 특히 중요한 특성입니다.

설치부터 첫 요청까지

Bruno를 직접 써보겠습니다. 설치부터 첫 API 요청, 그리고 결과 확인까지 실습 형태로 진행합니다.

설치 방법

Bruno는 Windows, macOS, Linux 세 플랫폼을 모두 지원합니다. 공식 웹사이트의 다운로드 페이지에서 OS에 맞는 설치 파일을 받을 수 있습니다.

Windows에서는 세 가지 방법이 있습니다.

• 공식 설치 파일: 다운로드 페이지에서 .exe 설치 파일을 받아 실행합니다. 설치 마법사가 뜨면 기본 옵션으로 진행하면 됩니다.
• winget: PowerShell 터미널에서 winget install Bruno.Bruno를 실행합니다. 패키지 매니저를 선호하는 사용자에게 추천합니다.
• Chocolatey: choco install bruno로 설치합니다.

macOS에서는 Homebrew를 사용할 수 있습니다.

brew install --cask bruno

Linux에서는 Snap, APT, 또는 AppImage를 지원합니다.

# Snap
sudo snap install bruno

# APT (Ubuntu/Debian)
sudo mkdir -p /etc/apt/keyrings
sudo gpg --no-default-keyring --keyring /etc/apt/keyrings/bruno.gpg --keyserver keyserver.ubuntu.com --recv-keys 9FA6017ECABE0266
echo "deb [signed-by=/etc/apt/keyrings/bruno.gpg] http://debian.usebruno.com/ bruno stable" | sudo tee /etc/apt/sources.list.d/bruno.list
sudo apt update
sudo apt install bruno

설치가 완료되면 Bruno를 실행합니다. 로그인 절차 없이 곧바로 메인 화면이 나타납니다. 왼쪽에 컬렉션 탐색기, 가운데에 요청 편집 영역, 아래에 응답 뷰어가 배치된 직관적인 3분할 레이아웃입니다.

컬렉션 만들기

Bruno에서 컬렉션(Collection)은 관련 API 요청을 묶는 단위입니다. 물리적으로는 컴퓨터의 한 폴더에 대응됩니다. 컬렉션을 만드는 방법은 간단합니다.

1. Bruno 메인 화면에서 Create Collection 버튼을 클릭합니다.
2. 컬렉션 이름(예: My Backend API)을 입력합니다.
3. 저장 위치를 선택합니다. 프로젝트 루트의 api-tests/ 같은 폴더를 추천합니다. 이 폴더가 그대로 Git에 커밋될 것이기 때문입니다.

이 과정이 끝나면 선택한 폴더에 bruno.json 파일이 생깁니다. 이 파일이 컬렉션의 메타데이터를 담고 있습니다.

{
  "version": "1",
  "name": "My Backend API",
  "type": "collection"
}

앞으로 이 컬렉션에 추가하는 모든 요청은 같은 폴더 안에 .bru 파일로 자동 생성됩니다. 파일 탐색기에서 폴더를 열면 내가 만든 요청들이 텍스트 파일로 나란히 놓여 있는 것을 확인할 수 있습니다.

첫 API 요청 보내기

컬렉션 안에서 우클릭하거나 상단의 New Request 버튼을 클릭합니다. 요청 이름을 입력하고, HTTP 메서드와 URL을 설정합니다. 무료 테스트 API인 JSONPlaceholder를 사용해 연습해 보겠습니다.

• 이름: Get Posts
• 메서드: GET
• URL: https://jsonplaceholder.typicode.com/posts

오른쪽 상단의 Send(▶) 버튼을 클릭하면 요청이 전송됩니다. 하단 패널에 HTTP 상태 코드(200 OK), 응답 시간, 응답 크기, 그리고 JSON 응답 본문이 자동 하이라이팅되어 표시됩니다. 응답 탭 상단에서 Pretty, Raw, Preview 모드를 전환할 수도 있습니다.

POST 요청도 시도해 보겠습니다. 새 요청을 만들고 다음과 같이 설정합니다.

• 이름: Create Post
• 메서드: POST
• URL: https://jsonplaceholder.typicode.com/posts
• Body: JSON 탭을 선택하고 다음 내용을 입력합니다.

{
  "title": "Bruno 테스트",
  "body": "파일 기반 API 클라이언트의 첫 요청",
  "userId": 1
}

Send를 누르면 201 Created 응답과 함께 생성된 게시글 정보가 돌아옵니다. 이 두 요청은 이제 컬렉션 폴더에 get-posts.bru, create-post.bru라는 텍스트 파일로 저장되어 있습니다. VS Code나 메모장으로 열어보면 요청의 전체 구조가 사람이 읽을 수 있는 형태로 담겨 있는 것을 확인할 수 있습니다.

환경 변수로 개발·스테이징·프로덕션 관리하기

실제 프로젝트에서는 개발 서버, 스테이징 서버, 프로덕션 서버의 URL이 각각 다릅니다. 인증 토큰이나 API 키도 환경마다 다릅니다. 요청을 보낼 때마다 URL을 수동으로 바꾸는 것은 비효율적이고 실수를 유발합니다. Bruno의 환경 변수(Environment) 기능이 이 문제를 깔끔하게 해결합니다.

환경 정의하기

Bruno에서 환경을 추가하려면 컬렉션 사이드바 상단의 환경 아이콘을 클릭하고 Create Environment를 선택합니다. 예를 들어 세 가지 환경을 다음과 같이 만들 수 있습니다.

개발(dev) 환경에는 로컬 서버 주소와 테스트용 토큰을 넣습니다.

baseUrl = http://localhost:3000
apiVersion = v1
accessToken = dev-token-test-12345

스테이징(staging) 환경에는 팀 내부 테스트 서버 정보를 넣습니다.

baseUrl = https://api-staging.example.com
apiVersion = v1
accessToken = staging-token-abcdef

프로덕션(prod) 환경에는 실서비스 주소를 넣되, 민감한 토큰은 시크릿으로 분리합니다.

baseUrl = https://api.example.com
apiVersion = v2

각 환경은 컬렉션 내부의 environments/ 폴더에 별도의 .bru 파일로 저장됩니다. 예를 들어 environments/dev.bru 파일의 내용은 다음과 같습니다.

vars {
  baseUrl: http://localhost:3000
  apiVersion: v1
  accessToken: dev-token-test-12345
}

변수 사용법과 시크릿 관리

환경 변수를 정의했으면, 요청의 URL이나 헤더, 본문 어디에서든 이중 중괄호 {{변수명}} 문법으로 참조할 수 있습니다.

get {
  url: {{baseUrl}}/api/{{apiVersion}}/users
  body: none
  auth: bearer
}

auth:bearer {
  token: {{accessToken}}
}

이제 Bruno 상단 드롭다운에서 환경을 전환하기만 하면, 같은 요청이 다른 서버로 보내집니다. URL을 하나하나 수정할 필요가 없습니다. 개발할 때는 dev를 선택하고, QA 팀에 확인을 요청할 때는 staging으로 전환하면 됩니다.

프로덕션 API 키처럼 민감한 값은 시크릿 변수로 분리하는 것을 강력히 권장합니다. 시크릿 변수는 환경 파일에 이름만 선언하고, 실제 값은 Bruno 앱 안에서 직접 입력합니다. 파일에는 값이 기록되지 않으므로 Git에 커밋해도 키가 노출되지 않습니다.

vars {
  baseUrl: https://api.example.com
  apiVersion: v2
}

vars:secret [
  accessToken,
  apiSecret
]

위 파일에서 accessToken과 apiSecret은 시크릿으로 선언되어 있습니다. Git 저장소에는 변수 이름만 올라가고, 실제 값은 각 개발자가 본인의 로컬 Bruno 앱에서 개별 입력합니다. 팀원이 10명이어도 시크릿 값은 절대 저장소에 남지 않습니다.

폴더 구조로 API 체계화하기

API 수가 많아지면 구조화가 필요합니다. Bruno에서는 GUI의 폴더 만들기 기능을 쓰거나, 파일 탐색기에서 직접 폴더를 만들어도 됩니다. 어느 쪽이든 같은 결과를 냅니다. 파일시스템 폴더가 곧 Bruno의 폴더이기 때문입니다.

my-api-collection/
├── bruno.json
├── environments/
│   ├── dev.bru
│   ├── staging.bru
│   └── prod.bru
├── auth/
│   ├── login.bru
│   └── refresh-token.bru
├── users/
│   ├── get-all-users.bru
│   ├── get-user-by-id.bru
│   ├── create-user.bru
│   └── update-user.bru
└── products/
    ├── list-products.bru
    └── search-products.bru

이 폴더 구조가 Bruno 사이드바에 그대로 반영됩니다. API 도메인(인증, 사용자, 상품)별로 폴더를 나누면 수십 개의 API도 깔끔하게 관리할 수 있습니다. 그리고 이 전체 구조가 프로젝트 저장소에 그대로 들어가므로, 새 팀원이 합류하면 git clone 한 번으로 모든 API 테스트 환경을 받아올 수 있습니다. 별도의 온보딩 문서나 컬렉션 공유 링크가 필요 없습니다.

스크립트와 어설션으로 API 테스트 자동화하기

단순히 요청을 보내고 응답을 눈으로 확인하는 것은 수동 테스트입니다. API가 수십 개가 되면 매번 눈으로 확인하는 것은 불가능합니다. Bruno는 JavaScript 기반 스크립트와 어설션(assertion) 기능을 제공해서, 응답을 자동으로 검증할 수 있게 해줍니다.

Pre-request 스크립트

요청이 전송되기 전에 실행되는 스크립트입니다. 주로 인증 토큰 설정, 타임스탬프 생성, 동적 데이터 준비에 사용합니다. Bru 파일 안에 script:pre-request 블록으로 작성합니다.

script:pre-request {
  const timestamp = new Date().toISOString();
  bru.setVar("requestTime", timestamp);
  
  // 기존 토큰이 설정되어 있는지 확인
  const token = bru.getEnvVar("accessToken");
  if (!token) {
    console.log("경고: accessToken이 설정되지 않았습니다.");
  }
}

bru 객체는 Bruno가 제공하는 전역 유틸리티입니다. bru.getEnvVar()로 환경 변수를 읽고, bru.setEnvVar()로 환경 변수를 동적으로 설정하며, bru.setVar()로 현재 요청에서만 유효한 임시 변수를 만들 수 있습니다.

Post-response 스크립트와 어설션

응답을 받은 뒤 실행되는 스크립트입니다. 응답에서 데이터를 추출하거나, 후속 요청에 필요한 값을 변수에 저장하는 데 유용합니다.

script:post-response {
  // 로그인 응답에서 토큰을 추출해 환경 변수에 저장
  const body = res.getBody();
  if (body.token) {
    bru.setEnvVar("accessToken", body.token);
    console.log("토큰이 성공적으로 갱신되었습니다.");
  }
}

어설션(Assertion)은 응답을 자동으로 검증하는 선언적 방법입니다. 별도의 스크립트를 작성하지 않아도, 간결한 규칙으로 응답의 상태 코드, 본문 값, 헤더, 응답 시간을 검사할 수 있습니다.

assert {
  res.status: eq 200
  res.body.data: isArray
  res.body.data.length: gte 1
  res.body.data[0].id: isNumber
  res.body.data[0].email: contains @
  res.responseTime: lt 2000
}

위 어설션은 6가지를 자동으로 검증합니다. HTTP 상태 코드가 200인지, 응답의 data 필드가 배열인지, 배열 길이가 1 이상인지, 첫 번째 항목의 id가 숫자인지, 이메일에 @가 포함되어 있는지, 그리고 응답 시간이 2초 미만인지 확인합니다. 어설션이 하나라도 실패하면 Bruno가 빨간색으로 즉시 표시합니다.

더 복잡한 검증이 필요하면 테스트 탭에서 Chai 스타일의 expect 문법을 사용할 수 있습니다.

tests {
  test("사용자 목록이 정상 반환된다", function() {
    const data = res.getBody().data;
    expect(res.getStatus()).to.equal(200);
    expect(data).to.be.an("array");
    expect(data.length).to.be.greaterThan(0);
  });
  
  test("각 사용자에 필수 필드가 있다", function() {
    const users = res.getBody().data;
    users.forEach(user => {
      expect(user).to.have.property("id");
      expect(user).to.have.property("email");
      expect(user).to.have.property("name");
    });
  });
}

실전 예제 — 인증 토큰 자동 갱신 워크플로우

실무에서 가장 자주 마주치는 시나리오를 풀어보겠습니다. 대부분의 REST API는 Bearer 토큰 인증을 요구하고, 토큰에는 만료 시간이 있습니다. 매번 수동으로 로그인하고 토큰을 복사해서 붙여넣는 것은 번거롭습니다. Bruno에서는 스크립트로 이 과정을 자동화할 수 있습니다.

1단계 — 로그인 요청 만들기 (auth/login.bru)

meta {
  name: 로그인
  type: http
  seq: 1
}

post {
  url: {{baseUrl}}/api/auth/login
  body: json
  auth: none
}

body:json {
  {
    "email": "[email protected]",
    "password": "{{loginPassword}}"
  }
}

script:post-response {
  const body = res.getBody();
  if (res.getStatus() === 200 && body.accessToken) {
    bru.setEnvVar("accessToken", body.accessToken);
    bru.setEnvVar("refreshToken", body.refreshToken);
    console.log("토큰 저장 완료");
  }
}

2단계 — 인증이 필요한 요청 작성 (users/get-all-users.bru)

meta {
  name: 사용자 목록 조회
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/api/users
  body: none
  auth: bearer
}

auth:bearer {
  token: {{accessToken}}
}

assert {
  res.status: eq 200
  res.body.data: isArray
}

로그인 요청을 한 번 실행하면 응답에서 추출된 토큰이 환경 변수에 자동 저장되고, 이후 모든 요청이 그 토큰을 자동으로 사용합니다. 토큰이 만료되면 로그인 요청만 다시 한 번 실행하면 됩니다. Postman에서 하던 “토큰 복사 → 변수에 붙여넣기” 수작업이 완전히 사라집니다.

한 단계 더 나아가, Pre-request 스크립트에서 토큰 만료 시간을 확인하고 자동으로 갱신 API를 호출하는 로직을 넣을 수도 있습니다. 이렇게 하면 토큰 관리를 완전히 자동화할 수 있어서, 인증이 필요한 수십 개의 API를 연속으로 테스트할 때 특히 유용합니다.

Bruno CLI로 CI/CD 파이프라인에 API 테스트 통합하기

지금까지는 GUI에서 수동으로 요청을 보내고 확인했습니다. 하지만 진정한 자동화는 CI/CD 파이프라인에서 API 테스트가 코드 배포 전에 자동으로 돌아가는 것입니다. Bruno API 클라이언트는 이를 위해 독립적인 CLI 도구를 제공합니다.

CLI 설치와 기본 사용법

Bruno CLI는 npm 패키지로 제공됩니다. Node.js가 설치되어 있다면 한 줄로 설치할 수 있습니다.

# 전역 설치
npm install -g @usebruno/cli

# 설치 확인
bru --version

설치가 끝나면 터미널에서 컬렉션을 바로 실행할 수 있습니다.

# 컬렉션 전체 실행 (dev 환경 기준)
bru run --env dev

# 특정 폴더만 실행
bru run --folder users --env dev

# 특정 요청 하나만 실행
bru run users/get-all-users.bru --env dev

실행 결과는 터미널에 요약으로 출력됩니다. 통과한 어설션은 초록색 체크, 실패한 어설션은 빨간색 X로 표시됩니다. 전체 테스트 중 실패가 하나라도 있으면 종료 코드 1이 반환되므로, CI 파이프라인에서 자연스럽게 빌드 실패로 처리됩니다. 이 동작은 별도 설정 없이 기본으로 적용됩니다.

GitHub Actions 연동 예제

Bruno 컬렉션이 프로젝트 저장소의 api-tests/ 폴더에 있다고 가정합니다. 다음 워크플로우 파일을 .github/workflows/api-test.yml로 추가합니다.

name: API Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  api-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install Bruno CLI
        run: npm install -g @usebruno/cli

      - name: Start API server
        run: |
          npm start &
          sleep 5

      - name: Run API tests
        working-directory: api-tests
        run: bru run --env ci

이 워크플로우는 코드가 푸시되거나 PR이 열릴 때마다 API 서버를 시작하고, Bruno CLI로 전체 API 테스트를 실행합니다. 어설션이 하나라도 실패하면 CI가 빨간불이 들어오므로, 배포 전에 API 회귀를 잡아낼 수 있습니다.

CI 전용 환경 파일(environments/ci.bru)을 별도로 만들어 CI 서버에 맞는 URL을 넣어두면, 로컬 개발 환경과 CI 환경을 깔끔하게 분리할 수 있습니다. CI 환경의 시크릿 값은 GitHub Actions의 시크릿 기능과 연동하여 환경 변수로 주입하는 것이 안전합니다.

Postman에서 Bruno로 이전하기

이미 Postman을 사용하고 있다면, Bruno로의 전환은 어렵지 않습니다. Bruno는 Postman 컬렉션 임포트를 기본 기능으로 지원합니다.

컬렉션 임포트 방법

1. Postman에서 컬렉션을 내보냅니다. 컬렉션 옆 점 세 개(⋯) 메뉴 → Export → Collection v2.1 JSON 형식을 선택합니다.
2. Bruno에서 Import Collection을 클릭합니다.
3. 소스로 Postman Collection을 선택합니다.
4. 내보낸 JSON 파일을 지정하고, 저장할 폴더를 선택합니다.

Bruno가 Postman의 요청, 폴더 구조, 환경 변수, Pre-request 스크립트, 테스트 코드를 자동으로 Bru 파일 형식으로 변환합니다. Postman에서 pm.environment.set() 같은 함수를 사용했다면, Bruno가 bru.setEnvVar()로 자동 변환해 줍니다. 단, 매우 복잡한 커스텀 스크립트는 100% 호환되지 않을 수 있으므로, 변환 후 각 요청을 한 번씩 실행해서 확인하는 것을 권장합니다.

Insomnia나 OpenAPI(Swagger) 스펙에서의 임포트도 지원합니다. 기존 OpenAPI YAML/JSON 파일이 있다면 그것으로 바로 Bruno 컬렉션을 생성할 수 있어 편리합니다.

팀 마이그레이션 전략

팀 전체가 한 번에 전환하기 어렵다면, 점진적 접근이 효과적입니다.

• 1주차: 프로젝트 저장소에 api-tests/ 폴더를 만들고, 가장 자주 쓰는 API 10개를 Bruno로 옮깁니다. 새로운 PR에서 이 폴더를 커밋합니다.
• 2주차: 새로 추가하는 API는 Bruno에서 작성합니다. 기존 Postman 컬렉션은 그대로 유지하되, 점차 참조 빈도를 줄입니다.
• 3~4주차: 팀원들이 Bruno에 익숙해지면, 나머지 Postman 컬렉션을 일괄 임포트합니다. CI/CD에 Bruno CLI를 연동합니다.
• 이후: Postman을 제거하고 Bruno를 단일 API 테스트 도구로 표준화합니다.

이 과정에서 가장 큰 저항은 “익숙함”입니다. 하지만 Bruno의 UI가 Postman과 매우 유사하게 설계되어 있기 때문에, 적응 기간이 생각보다 짧습니다. 요청 편집 영역, 환경 선택 드롭다운, 응답 뷰어의 위치가 거의 동일해서 대부분의 팀원이 2~3일이면 자연스럽게 전환합니다.

Bruno 활용을 극대화하는 실전 팁 5가지

기본 사용법을 익혔다면, 다음 팁들로 워크플로우를 한 단계 끌어올릴 수 있습니다.

• 컬렉션을 반드시 프로젝트 저장소에 포함시키세요. api-tests/나 bruno/ 폴더로 넣고 .gitignore에서 제외하지 마세요. API 테스트가 소스 코드와 함께 살아 숨 쉬어야 합니다. 코드가 바뀌면 테스트도 같은 PR에서 함께 바뀌는 것이 이상적입니다.
• 시크릿 변수를 활용해 민감 정보를 철저히 분리하세요. vars:secret으로 선언된 변수는 파일에 값이 기록되지 않습니다. 팀 공유 저장소에 실수로 API 키가 올라가는 사고를 원천 차단합니다.
• Collection Runner로 시나리오 테스트를 돌리세요. Bruno의 Runner 기능은 폴더 안의 모든 요청을 순서대로 실행합니다. 로그인 → 사용자 생성 → 조회 → 삭제 같은 시나리오를 한 번에 검증할 수 있습니다. 각 요청의 seq 값으로 실행 순서를 제어합니다.
• GraphQL도 지원합니다. Bruno는 REST뿐 아니라 GraphQL 요청도 지원합니다. 요청 타입을 GraphQL로 설정하면 쿼리 편집기, 변수 입력, 스키마 자동완성 기능을 사용할 수 있습니다.
• 키보드 단축키를 익히세요. Ctrl+Enter(또는 Cmd+Enter)로 요청 전송, Ctrl+E로 환경 전환, Ctrl+B로 사이드바 토글. 마우스 없이도 빠르게 API를 테스트할 수 있습니다.

Bruno와 다른 API 테스트 도구 비교

Postman 대안은 Bruno만 있는 것이 아닙니다. 대표적인 선택지를 간단히 비교해 보겠습니다.

• Hoppscotch: 웹 기반 오픈소스 API 클라이언트입니다. 브라우저에서 바로 쓸 수 있어 설치가 필요 없습니다. 가볍고 빠르지만, 파일 기반 저장이 아니며 데스크탑 앱의 CI/CD 연동 기능은 Bruno보다 제한적입니다.
• Thunder Client: VS Code 확장으로 동작하는 경량 API 클라이언트입니다. VS Code를 주 에디터로 쓴다면 편리하지만, 에디터 밖에서는 쓸 수 없고 CLI 도구가 없어 CI/CD 연동이 어렵습니다.
• Insomnia: 한때 인기 있었지만, Kong에 인수된 뒤 유료 기능이 늘고 커뮤니티 신뢰가 하락했습니다. 클라우드 동기화 강제 논란도 있었습니다.
• HTTPie: CLI 기반 HTTP 클라이언트로, cURL의 사용성을 개선한 도구입니다. 터미널에서 빠르게 요청을 보낼 때 좋지만, 컬렉션 관리나 환경 변수 같은 체계적 기능은 약합니다.

Bruno가 이 도구들과 구별되는 결정적 지점은 “파일 기반 저장 + Git 네이티브 + 오프라인 우선 + CLI 기반 CI/CD 통합”이라는 조합입니다. API 테스트를 소스 코드의 일부로 관리하고, 자동화 파이프라인까지 연결하고 싶다면, 2026년 현재 Bruno가 가장 균형 잡힌 선택입니다.

마무리 — API 워크플로우의 전환점

Bruno API 클라이언트는 “API 테스트 데이터는 내 것이다”라는 단순한 원칙에서 출발합니다. 클라우드에 종속되지 않고, 계정이 필요 없고, 파일이 투명하게 보이며, Git으로 자연스럽게 관리됩니다. 이 원칙 하나가 팀 협업, 버전 관리, CI/CD 통합, 보안이라는 네 가지 영역을 동시에 개선합니다.

이 글에서 다룬 내용을 정리합니다.

• Bruno의 파일 기반 설계가 가져오는 3가지 장점: Bru 마크업, Git 호환, 오프라인 우선
• 설치부터 첫 GET/POST 요청 실행까지의 실습
• 환경 변수와 시크릿으로 개발·스테이징·프로덕션을 분리하는 실전 기법
• 스크립트와 어설션을 활용한 API 응답 자동 검증
• Bruno CLI를 GitHub Actions에 연동하는 CI/CD 통합
• Postman에서 Bruno로의 점진적 마이그레이션 전략

만약 지금 Postman을 쓰고 있다면, 오늘 Bruno를 설치하고 가장 자주 쓰는 API 3개만 옮겨 보세요. 파일 탐색기에서 .bru 파일을 열어 내용이 그대로 보이는 순간, “내 API 데이터가 내 손에 있다”는 감각을 체감할 수 있을 것입니다. 그 경험이 워크플로우 전환의 시작점이 됩니다.

자주 묻는 질문

Bruno API 클라이언트는 Postman과 어떤 점이 다른가요?

Bruno는 API 컬렉션을 클라우드가 아닌 로컬 파일시스템에 텍스트 파일(.bru)로 저장하며, 클라우드 계정 로그인 없이 오프라인에서도 완벽하게 동작합니다. Postman이 클라우드 기반 저장과 계정 강제 로그인 방향으로 변한 것과 달리, Bruno는 Git 버전 관리와의 호환을 핵심 설계 원칙으로 삼고 있습니다.

Bruno의 Bru 파일 형식은 무엇이고 왜 사용하나요?

Bru는 Bruno가 설계한 자체 마크업 언어로, 각 API 요청을 하나의 .bru 텍스트 파일로 저장합니다. JSON처럼 따옴표가 난무하지 않고 YAML처럼 들여쓰기에 민감하지 않아 사람이 읽고 편집하기 쉬우며, 텍스트 기반이므로 grep이나 sed 같은 터미널 도구로 일괄 검색과 치환이 가능합니다.

Bruno 컬렉션을 Git으로 관리하면 어떤 장점이 있나요?

API 요청의 변경 이력을 Git 로그로 추적할 수 있고, PR에서 API 요청 변경 사항을 팀원이 코드 리뷰할 수 있습니다. 텍스트 파일이므로 diff가 명확하고, feature 브랜치에서 새 API를 추가한 뒤 main에 머지하는 기존 개발 워크플로우를 그대로 따를 수 있습니다.

---