Postman을 쓰고 있었는데...
개발 공부를 시작한 이래로 지금까지 API 테스트 도구로 Postman을 사용하고 있었다. 사용하게 된 계기는 너무나 간단했다. 강의에서 사용하던 도구였으니 자연스럽게 계속 써왔던 것이다.
그러나 최근에 X(구 트위터)에서 Postman의 보안 취약점을 이야기하면서 (물론 당연히 취약점에 대한 대응 방법은 있지만) Postman을 대체할 여러 API 테스트 도구를 소개하는 글을 봤었는데 그 중에서 Bruno를 많이 추천하는 것 같아서 공식 문서와 홈페이지를 구경하였다.
거기서 가장 이목을 끈 구절이 있었는데 다음과 같았다.
Bruno is a Fast and Git-Friendly Opensource API client, aimed at revolutionizing the status quo represented by Postman, Insomnia and similar tools out there.
Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about API requests.
사실 Postman은 API 테스트 도구로서 필요한 기능은 다 갖추었다고 생각하지만 테스트 요청을 다른 사람들에게 공유하는 것이 불편하긴 했었는데, 마침 Bruno에서는 이러한 API 요청 템플릿들을 코드와 파일로 관리하며 GitHub와 같은 소스 코드 저장소와 연동이 가능하다는 것을 어필하고 있었어서 이 부분이 가장 매력적으로 느껴졌다.
Bruno 소개
개요
Bruno는 공식 문서의 설명에 따르면 Bruno는 Git 친화적인 오픈소스 API 클라이언트로, 사용자의 요청 컬렉션을 파일 시스템의 폴더에 직접 저장하고 이를 저장하기 위해 일반 텍스트 마크업 언어인 Bru를 사용한다.
공식 문서에서 강조하기를, Bruno를 통해 사용자는 API 요청을 보다 효율적으로 관리하고 버전 관리를 용이하게 할 수 있다고 하는데 API 요청 마크업을 Git으로 형상을 관리한다면 손쉽게 다른 사용자들에게 API 요청 템플릿을 공유하고 히스토리 역시 관리할 수 있을 것 같다는 생각이 든다.
설치 방법
https://www.usebruno.com/
위의 공식 홈페이지에서 OS에 맞게 설치가 가능하다. 설치 방법은 상당히 간단하므로 자세한 설명은 생략한다.
설치가 완료되어 Bruno를 실행하게 되면 위와 같은 화면이 노출된다.
사용 방법
API 요청 컬렉션(Collection) 생성하기
API 요청 모음을 컬렉션이라고 부르며 Bruno에서는 이를 파일 시스템의 디렉터리로 관리하고 있다.
여기서 컬렉션을 직접 만들거나, 이미 만들어진 컬렉션을 Open하거나, Import 해올 수 있다. Import 대상에는 Bruno, Postman, Insomnnia, OpenAPI V3 컬렉션이 있다.
예제에서는 bruno-practice라는 컬렉션을 생성하도록 한다.
컬렉션의 이름은 bruno-practice로 하고 디렉터리 생성 경로를 지정해준 뒤 생성될 디렉터리의 이름도 bruno-practice로 지정하였다.
이렇게 생성된 디렉터리는 Git으로 관리를 할 수 있으며 GitHub 리포지토리에 업로드함으로서 형상 관리 및 공유를 할 수 있게 된다.
API 요청(Request) 생성하기
컬렉션을 생성하였다면 컬렉션 내부에 폴더(디렉터리) 또는 API 요청을 생성할 수 있다.
폴더나 API 요청을 생성하려면 컬렉션의 우측의 버튼을 눌러 생성하고자 하는 리소스를 선택하면 된다.
여기서 New Request를 누른 후 API 요청에 필요한 정보를 작성한다.
API 요청이 생성된다면 다음과 같이 컬렉션 내에 API 요청이 생성되며, 요청 화면이 노출된다. UI 자체는 Postman과 굉장히 흡사한 구조를 가지고 있으며, 우측 상단의 -> 버튼으로 요청을, 디스크 모양 버튼으로 API 요청 자체를 저장할 수 있다.
요청 엔드포인트에 PathVariable과 같은 변수가 필요할 경우, Vars에서 설정이 가능하며 환경 변수 부분은 {{}} 로 감싸면 된다. 예를 들어 다음과 같이 PathVariable이 필요한 엔드포인트를 처리할 수 있다.
만약 요청 엔드포인트에 RequestParam과 같은 쿼리 파라미터가 들어갈 경우엔 Query에서 설정이 가능하다. 예를 들어 다음과 같이 RequestParam이 필요한 엔드포인트를 처리할 수 있다.
Body 작성 부분은 Postman과 동일하게 Body 타입을 지정해서 요청하면 된다.
아래의 예시는 application/json 형식으로 Body를 보내는 요청이다.
환경 변수 관리하기
Bruno는 API 요청 환경 프로필을 지정할 수 있으며 이 프로필에 따른 환경 변수도 같이 지정할 수 있다.
환경 변수를 지정하는 방법은 Bruno에서 환경 변수 설정 파일을 생성하는 방법과 .env 파일로 지정하는 방법 2가지가 있다.
1. 환경 프로필 생성 후 환경 변수 지정
우측 상단의 No environment 로 설정된 환경 프로필을 클릭하면 드롭다운에 Configure가 노출되는데 이를 클릭한 후 환경 프로필을 생성한다.
아래에서는 'local' 이라는 환경을 구성하였고 환경 변수로 backend를 지정한 후 값을 넣었다. 여기서 이러한 값을 노출시키지 않으려면 Secret으로 체크를 해야 한다.
이후 다른 요청 엔드포인트에서 환경변수 backend를 활용해본다.
현재 활성화된 환경 프로필은 local이다.
만약 환경 프로필이 지정되어 있지 않거나, 해당 환경 프로필에서 환경 변수가 없는 경우엔 환경 변수가 붉은색으로 표시된다.
2. .env 파일로 환경 변수 지정
만약 .env 파일 등으로 환경 변수를 따로 관리하고 싶을 경우엔 위의 Environment 설정 부분에서 {{process.env.환경변수 키값}} 을 사용하여 환경 변수를 지정할 수 있다.
예를 들어, .env 파일을 생성한 후 다음 환경변수를 지정하였다. (위치는 컬렉션 내부)
BASE_URI=api/v1/test그 후, 환경 변수 생성 창에서 다음과 같이 설정한다.
이렇게 설정한 후 요청 엔드포인트에도 반영을 할 수 있다.
다만 현재까지는 .env 파일만 적용이 가능한 것으로 보이며 .env.production, .env.dev 와 같은 파일 형식은 아직 지원을 하지 않는 것으로 보인다. (.env 내에서 자체적으로 환경 프로필별로 변수를 선언해줘야 한다)
Bru 파일들은 어떻게 저장되는가
컬렉션 및 API 요청은 모두 Bru 파일로 저장이 된다고 했다.
그렇다면 실제로 파일 시스템에 어떻게 저장되는지 확인해보자.
bruno-practice라는 최상위 폴더는 컬렉션과 무관한 디렉터리이며 해당 디렉터리에 bruno-practice라는 컬렉션을 생성함으로서 bruno-practice라는 디렉터리가 추가되었다.
그리고 그 하단부에 bruno.json 파일과 각종 요청 Bru 파일이 존재하고 환경 변수 관련 설정 Bru 파일이 environments 디렉터리 내에 존재한다.
요청 Bru 파일의 형식은 다음과 같다.
환경 변수 설정 관련 Bru 파일의 형식은 다음과 같다.
마크업 문법 자체가 상당히 심플하게 구성되어 있어 파일만 봐도 어떤 형식으로 요청을 보내는지 유추할 수 있다. 또한 이 파일들을 직접 수정함으로서 요청 API도 변경이 가능하다. (물론 사용자마다 요청이 다르게 저장될 수 있으므로 이를 Push하지 못하게 하거나 sample Bru 파일을 제공하고 그 외에는 gitignore 처리를 하는 등의 작업이 필요할 수는 있다)
기타 기능들
공식 문서에 따르면 Assertions 기능과 스크립트를 활용한 API 테스트 기능도 제공하고 있다. 또한 이를 JavaScript에서도 참조할 수 있다고 하는데 단순 API 요청 뿐만이 아니라 API에 대한 테스트도 동시에 진행할 수 있고 이러한 설정을 마찬가지로 GitHub과 연동하여 관리할 수 있다는 부분이 매력적인 것 같다.
공식 문서의 링크는 아래에 첨부를 하였으니 관심이 있다면 확인해보는 것을 추천한다.
https://docs.usebruno.com/introduction
간단 사용 후기
가장 매력적인 부분은 역시 API 요청 컬렉션을 파일로 관리하고 이를 GitHub 리포지토리와 연동해서 형상 관리를 할 수 있다는 부분이었다.
예를 들어 한창 개발을 진행해야 하는 경우 API를 작성하는 백엔드 개발자 측에서 API 요청 스펙에 대한 정보나 변동 사항을 계속해서 프론트엔드 개발자에게 전달하고 이를 문서화하거나 하는 부분이 굉장히 번거로울 수 있는데 이에 필요한 노력을 상당 부분 감소시켜줄 수 있다고 생각한다.
또한 스크립트와 테스트 부분도 동일하게 형상 관리 대상이 된다는 점도 긍정적인 요소로 작용할 것 같다.
아직 개인 프로젝트에서만 사용 중이고 회사 프로젝트 업무가 많이 바쁜 상황이라 당장 적용은 힘들겠지만 언젠가는 적용해보고 싶다.
