Hoppscotch·Thunder Client — 설치 없이, 에디터 안에서 바로 쓰는 API 테스트

개념

이 레슨의 주제는 기능이 아니라 "마찰"이다

모듈 12(레슨 2)에서 Postman으로 요청·어서션·컬렉션을 만들었다. 이번에 다루는 두 도구는 Postman보다 기능이 많아서 배우는 게 아니다. 정반대다. API를 한 번 두드려보기까지 걸리는 마찰을 거의 0으로 줄인다 는 점 하나가 이 둘의 존재 이유다.

마찰은 생각보다 크게 작동한다. "설치하고, 계정 만들고, 워크스페이스 고르고, 앱을 다시 띄우고"를 거쳐야 한다면 사람은 그냥 확인을 건너뛴다. 마찰이 작으면 테스트 횟수가 늘고, 테스트 횟수가 늘면 결함을 더 일찍 만난다.

Hoppscotch — 설치 자체가 없다

Hoppscotch(hoppscotch.io)는 브라우저에서 바로 돌아가는 오픈소스 API 클라이언트다. 주소를 열면 그 자리에서 메서드·URL·헤더·본문을 입력하고 요청을 보낼 수 있다. 설치도, 로그인도 필수가 아니다.

실무에서 가장 크게 체감되는 장점은 공유 다. 개발자에게 "이 API가 이상해요"라고 말할 때, 스크린샷 대신 요청이 그대로 담긴 링크를 보내면 상대는 클릭 한 번으로 같은 요청을 재현한다. 모듈 6에서 배운 "재현 가능한 결함 리포트"를 API 레벨에서 가장 싸게 만드는 방법이다.

주의할 점도 있다. 브라우저에서 도는 앱이라 사내망 안쪽 주소나 localhost 로 바로 요청을 보내려면 별도의 프록시(Hoppscotch Agent/Extension)가 필요할 수 있고, CORS 제약도 그대로 받는다. 공개 API나 접근 가능한 스테이징 서버를 다룰 때 가장 편하다.

Thunder Client — 에디터를 벗어나지 않는다

Thunder Client는 VS Code 확장이다. 코드를 짜다가 옆 탭에서 바로 요청을 보내고 응답을 본다. 개발자가 방금 만든 엔드포인트를 확인할 때, 창을 바꾸지 않아도 된다는 것만으로 확인 빈도가 눈에 띄게 올라간다.

QA에게 더 중요한 차별점은 따로 있다. 요청 컬렉션을 프로젝트 폴더 안의 .json 파일로 저장할 수 있다 는 점이다. 모듈 9(레슨 7)에서 배운 Git으로 이 파일을 버전 관리하면 이런 것들이 가능해진다.

• 코드 변경과 API 요청 정의가 같은 커밋 에 들어간다 — "이 엔드포인트가 언제 바뀌었는지"를 코드 히스토리에서 함께 본다
• PR 리뷰(모듈 9 레슨 8)에서 요청 정의 변경이 diff로 보인다
• 새로 합류한 팀원이 저장소를 클론하면 컬렉션도 같이 따라온다

Postman/Insomnia도 내보내기로 파일을 만들 수는 있지만, 그건 "내보내는 별도 작업"이다. Thunder Client는 저장 위치 자체가 저장소 안이라 별도 동기화 작업이 없다.

둘 다 대체재가 아니라 "가벼운 자리"를 맡는다

모듈 12(레슨 2)에서 컬렉션이 커지면 GUI 관리가 버거워진다는 Postman의 한계를 미리 느껴봤다. 이 두 도구는 그 한계를 더 일찍 만난다. 가볍다는 건 곧 기능이 적다는 뜻이기 때문이다.

판단 기준은 단순하다. "지금 이 요청 하나를 확인하고 싶다"면 가벼운 도구, "이 요청들을 팀이 계속 관리하고 CI에서 돌려야 한다"면 Postman 계열 로 옮긴다. 옮겨가는 것은 실패가 아니라 정상적인 성장 경로다.

실무에서 왜 필요한가

QA가 실무에서 API를 두드리는 순간의 상당수는 "정식 테스트"가 아니라 확인 이다. 개발자가 슬랙에 "고쳤어요"라고 올렸을 때, 장애 대응 중에 특정 엔드포인트가 살아있는지 볼 때, 결함 리포트를 쓰다가 응답 본문을 그대로 붙여넣고 싶을 때 — 이런 순간에 무거운 도구를 켜는 비용은 확인 자체를 포기하게 만든다.

또 하나, 협업 상대가 QA가 아닐 때 효과가 크다. 기획자나 CS 담당자에게 Postman 설치를 요구하기는 어렵지만, Hoppscotch 링크는 클릭만 하면 된다. 반대로 개발자와 나란히 디버깅할 때는 그가 이미 열어둔 VS Code 안의 Thunder Client가 가장 마찰이 적다. 상대가 이미 있는 자리로 도구를 가져가는 것 이 협업에서는 대체로 이긴다.

실습 과제

과제 1 — 설치 없이 첫 요청 보내기 (6분)

hoppscotch.io를 열고 공개 API(예: https://httpbin.org/get)에 GET 요청을 보낸다. 그다음 쿼리 파라미터를 하나 추가해 응답의 args 필드가 어떻게 달라지는지 확인하고, 모듈 9(레슨 2)에서 배운 상태 코드·헤더가 화면 어디에 표시되는지 찾아본다.

과제 2 — 도구 선택 판단하기 (7분)

다음 세 상황에 각각 어떤 도구를 고를지와 이유를 한 줄씩 적는다.

1. 개발자가 방금 배포한 엔드포인트 하나가 살아있는지 3분 안에 확인해야 한다
2. 회귀 테스트용 API 요청 40개를 팀이 함께 관리하고, 야간 CI에서 자동 실행해야 한다
3. CS 담당자에게 "이 요청을 그대로 실행해보세요"라고 전달해야 한다

과제 3 — Git에 올릴 컬렉션 상상하기 (5분)

Thunder Client 컬렉션 .json을 저장소에 커밋한다고 가정하고, 그 파일에 절대 들어가면 안 되는 값 두 가지를 적는다. 그리고 그 값들을 대신 어떻게 다뤄야 하는지(모듈 12 레슨 2의 환경 변수 개념을 떠올려보자) 한 문장으로 정리한다.

자가 체크리스트

• Hoppscotch가 설치 없이 브라우저에서 동작하며, 요청을 링크로 공유할 수 있다는 점을 설명할 수 있다
• Thunder Client가 VS Code 안에서 동작하고 컬렉션을 파일로 저장해 Git으로 관리할 수 있다는 점을 설명할 수 있다
• 두 도구가 Postman의 완전한 대체재가 아니라 "가벼운 확인" 자리를 맡는다는 것을 이해하고 있다
• 주어진 상황에서 경량 도구와 Postman 계열 중 무엇을 쓸지 근거를 들어 고를 수 있다

흔한 실수

• 가볍다는 이유로 팀의 회귀 테스트 자산을 경량 도구에만 쌓는다. 요청이 수십 개가 되고 CI 연동이 필요해지는 순간 옮겨야 하는데, 그때 옮기는 비용이 훨씬 크다. 자산이 될 요청은 처음부터 관리 가능한 도구에 둔다.
• 컬렉션 파일에 토큰·비밀번호를 넣은 채 커밋한다. Git에 한 번 올라간 비밀값은 이후 커밋으로 지워도 히스토리에 남는다. 환경 변수로 분리하고, 비밀값 파일은 .gitignore에 넣는다.
• Hoppscotch에서 localhost가 안 된다고 도구가 고장 났다고 판단한다. 브라우저 기반이라 생기는 제약(CORS·사내망 접근)이며, 프록시 설정이나 데스크톱 대안으로 해결할 문제다.
• 도구가 달라지면 개념도 달라진다고 생각한다. 화면 배치만 다를 뿐 요청 구성·어서션·환경 변수는 모듈 12에서 배운 그대로다.

참고 자료

• Hoppscotch 공식 문서 — 요청 작성·공유·셀프 호스팅 가이드
• Thunder Client 공식 문서 — 컬렉션 파일 저장과 Git 연동 설정
• httpbin.org — 실습용 공개 HTTP 테스트 엔드포인트