API 테스트 도구 실전

학습 목표

이 모듈 한 줄 요약 — "화면을 거치지 않고 창구를 직접 두드려 본다". 사람이 버튼을 누르는 대신, 프로그램이 주고받는 창구(API)에 직접 요청을 보내 보는 도구들을 다룬다. 화면이 멀쩡해도 창구가 틀린 값을 주면 결함이고, 화면이 아직 없어도 창구만 있으면 시험을 시작할 수 있다. 도구마다 생김새는 달라도 하는 일은 같으니, 하나를 익히면 나머지는 금방 읽힌다.

이 모듈을 마치면 모듈 12에서 배운 Postman·SoapUI 외에, 실무에서 자주 언급되는 API 테스트 도구들을 직접 설치하고 첫 요청을 만들 수 있다. 도구마다 문법은 다르지만, 모듈 12에서 배운 핵심 개념(요청 구성, 어서션, 환경 변수)이 그대로 적용된다는 것을 반복해서 확인한다. 나아가 요청을 만들어 보내는 도구를 넘어, 실제로 오가는 트래픽을 가로채고 조작하고 진단하는 도구 — 프록시(Charles·mitmproxy)와 패킷 분석기(Wireshark·tcpdump) — 까지 다룬다.

마지막 세 레슨은 현장에서 가장 먼저 마주치는 화면인 Swagger UI 를 다룬다. Try it out으로 API를 직접 실행하고, 로그인이 필요한 API에 토큰을 걸고, Postman과 역할을 갈라 쓰는 실무 흐름을 익힌 뒤, 우리 프로젝트에 문서를 붙이고 품질을 점검하는 데까지 간다.

완료 후 할 수 있는 것

• Insomnia로 API 요청을 만들고 응답을 검증할 수 있다
• Hoppscotch·Thunder Client로 설치 없이(또는 에디터 안에서) 빠르게 API를 테스트할 수 있다
• Apidog으로 API 설계·테스트·문서화가 하나로 연결되는 흐름을 경험할 수 있다
• 각 도구의 차별점을 이해하고, 팀 상황에 맞는 도구를 추천할 수 있다
• 프록시로 모바일 앱 트래픽을 가로채고, 브레이크포인트·Map Local·Rewrite로 서버 수정 없이 예외 상황을 만들어낼 수 있다
• 프록시로 안 되는 문제(연결 실패·인증서 오류·간헐적 끊김)를 패킷 레벨에서 좁혀 담당 팀에 넘길 수 있다
• Swagger UI에서 Try it out으로 API를 실행하고, Authorize로 토큰을 걸어 인증이 필요한 API까지 테스트할 수 있다
• Swagger와 Postman의 역할을 구분하고, 스펙을 컬렉션으로 가져와 회귀 테스트·CI 실행까지 연결할 수 있다
• API 문서의 품질을 점검표로 리뷰하고, 운영 환경에 문서가 노출됐는지 확인할 수 있다

채용시장에서의 위치

채용공고에 "Postman 경험"은 거의 필수로 등장하지만, 실제 입사 후엔 팀마다 이미 다른 도구(Insomnia, Apidog 등)를 쓰고 있는 경우가 드물지 않다. 이 모듈의 목적은 도구 하나를 완벽히 마스터하는 게 아니라, "API 테스트 도구는 결국 같은 개념을 다른 화면으로 표현한 것" 이라는 감각을 길러 어떤 도구를 마주쳐도 빠르게 적응하는 것이다.

여기에 프록시와 패킷 분석이 더해지면 범위가 한 단계 넓어진다. 특히 모바일 앱 QA에서 프록시는 사실상 필수 다 — 앱에는 개발자도구가 없으므로, "이 화면이 어떤 API를 부르는지"조차 프록시 없이는 알 수 없다. 그리고 "네트워크 계층 문제로 보입니다"까지 말할 수 있는 QA는 여전히 드물다.