API 테스트 도구가 도움이 되려면 먼저 뭘 테스트할지 알아야 한다
Postman, Insomnia, Bruno, Hoppscotch: 둘 중 아무거나 써도 된다. 무료로 스펙을 생성하고(가입 없음), 도구에 실제 엔드포인트를 줘야 한다.
API 테스트는 가장 흔한 API 작업이다
API 테스트 도구가 정말 잘 하는 일들
엔드포인트를 빠르게 찌르기
요청 보내고 응답 읽고 헤더 수정. 일회성 스크립트 짜는 것보다 훨씬 빠르다.
흐름을 저장했다 다시 실행하기
인증 호출, 그 다음 실제 요청, 그 다음 정리. 한 번 저장하면 API가 바뀔 때마다 다시 실행하면 된다.
배포 전에 버그를 사용자보다 먼저 잡기
배포 전에 저장된 컬렉션을 실행하면 깬 엔드포인트가 드러난다. 매번 기억해야 할 필요가 없다.
아직 안 만들어진 백엔드 흉내내기
프론트엔드가 기대하는 응답 형태를 정의하고, 그걸 상대로 개발하고, 실제 API가 완성되면 바꾼다.
실제로 쓸 인증 흐름 테스트하기
OAuth 리다이렉트, 리프레시 토큰, 만료되는 키: 앱 코드에 묻히지 말고 밖에서 테스트할 만한 가치가 있다.
작동하는 예제를 누군가한테 넘겨주기
공유된 컬렉션은 API 문서보다 낫다. 실제로 작동하니까.
다섯 가지 실제 트레이드오프, 정답은 없다
팀 규모와 토큰을 어디에 저장할지로 선택하자. 유명한 이름 때문에 선택하지 말고.
| 기능 | Postman | Insomnia | Bruno | Hoppscotch |
|---|---|---|---|---|
| 컬렉션 저장 위치 | 기본값으로 클라우드 동기화 | 로컬에 저장, 선택적으로 클라우드 동기화 | 코드 옆 평문으로, git 친화적 | 계정 또는 자체 호스팅 인스턴스 |
| 무료 티어 | 클라우드 동기화와 협력자 제한 | 로컬 단독 사용에 관대함 | 완전 오픈소스, 제한 없음 | 오픈소스, 제한 없음 |
| CI에서 실행 | Newman | Inso CLI | Bruno CLI | hoppscotch-cli |
| 최적 사용처 | 한 워크스페이스를 공유하는 팀 | 로컬 우선 앱을 원하는 솔로 개발자 | API 컬렉션을 git으로 관리하고 싶은 개발자 | 브라우저 안에 머물고 싶은 개발자 |
도구를 고르기 전에 API를 먼저 정의하자
흔한 실패는 도구를 잘못 고르는 게 아니라, 제대로 정의되지 않은 API를 상대로 도구를 여는 것이다. 세 개의 실제 엔드포인트, 인증 모델, 전체 기능이 의존하는 하나의 흐름을 이름 붙여서 말할 수 없다면, 아무 테스트 도구도 너를 구하지 못한다: 아직 설계하지 않은 뭔가를 테스트하는 것뿐이니까. whatshouldibuildnext.com의 생성기는 대충 쓴 프로젝트 아이디어를 엔드포인트 이름과 스택 제안이 있는 스펙으로 2분 만에 바꿔준다. 그 다음에 Postman이든 Insomnia든 Bruno든 실제 요청을 열 수 있다.
- 무료, 클라이언트 사이드, 가입 없음
- 실제로 테스트해야 할 엔드포인트를 이름 붙여줌
- 먼저 흉내낼 만한 통합을 표시해줌
진짜 질문은 토큰을 어디에 저장할 건가다
어떤 도구를 쓸지 간에 항상 두 가지로 줄어든다: 협력이 정말 필요한가, 그리고 시크릿이 어디에 살 건가. Postman의 클라우드 동기화는 컬렉션을 클라이언트나 팀원과 나누기가 쉽고, 대신 스테이징 API 키가 저장소 밖 어딘가에 산다. Bruno와 Hoppscotch의 로컬 우선이나 자체 호스팅 옵션은 컬렉션을 코드 옆 평문으로 두지만 기능 세트가 좀 더 단순하다. 어느 쪽이든 키와 토큰은 환경 변수로: 저장된 요청에 그냥 붙여넣지 말자. 나중에 공유하거나 동기화할 때 산 인증서를 새지 않으려고.
오후 한 번에 API 테스트하기
-
1
먼저 엔드포인트를 정의하자
뭘 정말 만드는지 이름 붙여: 3-5개 라우트, 중요한 하나의 흐름, 지금은 안 할 것.
-
2
Happy path를 손으로 테스트하자
엔드포인트당 요청 하나, 실제 페이로드, 응답을 읽어. 대부분의 도구가 여기서 빛난다.
-
3
컬렉션으로 저장하자
요청들을 그룹화하고, 인증 단계를 넣고, 서로 의존하는 것들을 연결해.
-
4
실패해야 할 요청들을 넣자
잘못된 토큰, 빠진 필드, 레이트 리미트. Happy path만 처리하는 API는 첫 주에 누군가 다른 사람이 쓰면 깨진다.
-
5
중요해지면 CI에 연결하자
첫날은 아니고, API가 실제 사용자를 가지면 매 푸시마다 컬렉션을 실행해서 깬 엔드포인트가 빌드를 실패시키게 하자. 누군가의 오후가 아니라.
자주 묻는 질문
전담 API 테스트 도구가 필요한가, curl이면 충분한가?
사이드 프로젝트용으로는 어떤 API 테스트 도구를 고르면 되나?
API 키를 테스트 도구의 저장된 요청에 넣어도 안전한가?
API 테스트 도구가 자동화된 테스트를 대체할 수 있나?
괜찮은 API 테스트 도구는 얼마나 비싼가?
그럼 뭘 먼저 테스트해야 하나?
실제로 뭘 만들어서 이걸 연습해야 하나?
API를 먼저 정의하고 도구를 고르자
무료 스펙 생성기, 클라이언트 사이드, 가입 없음. 엔드포인트와 추천 스택을 얻고 이미 쓰는 도구를 열자.