Insomnia로 API 테스트 시작하기: Postman과 비교하며 익히기

개념

Postman을 배웠다면 이미 90%는 안다

모듈 12(레슨 2)에서 Postman으로 요청을 만들고, 어서션을 쓰고, 컬렉션으로 묶는 법을 배웠다. Insomnia는 그 개념을 그대로 가진 다른 화면 이다. 요청 하나는 여전히 메서드·URL·헤더·본문으로 구성되고, 환경(Environment)에 변수를 정의해 재사용하며, 응답을 검증하는 테스트를 붙일 수 있다.

그래서 이 레슨의 목표는 "새 도구를 배우는 것"이 아니라, 모듈 12의 개념이 도구를 갈아타도 살아남는다는 것을 직접 확인하는 것이다.

요청 만들기 — Postman 예시를 그대로 옮기면

모듈 12(레슨 2)에서 만들었던 주문 생성 요청을 Insomnia에서 만들면 이렇게 된다.

메서드: POST
URL: https://api.example.com/orders
헤더: Authorization: Bearer {{ _.token }}
본문(JSON):
{
  "productId": "P001",
  "quantity": 2,
  "couponCode": "SAVE10"
}

거의 똑같다. 다른 건 변수 표기 하나뿐이다 — Postman이 {{token}} 이라고 쓰는 자리를 Insomnia는 {{ _.token }}으로 쓴다. 환경에 token 값을 정의해두고 개발·스테이징 환경을 전환하며 같은 요청을 재사용하는 방식은 동일하다.

응답 검증도 자바스크립트로 작성한다는 점이 같다.

// Insomnia의 After-response 스크립트
const body = insomnia.response.json();
 
insomnia.test("상태 코드는 201이다", () => {
  insomnia.expect(insomnia.response.code).to.equal(201);
});
 
insomnia.test("응답에 주문 ID가 포함된다", () => {
  insomnia.expect(body).to.have.property("orderId");
});

pm. 이 insomnia. 으로 바뀐 것 말고는 구조가 같다. 모듈 10(레슨 1)의 AAA 패턴 중 Assert 단계를 표현한 코드라는 사실도 변하지 않는다.

그럼 무엇이 다른가

GraphQL — Insomnia가 먼저 잘했던 영역

모듈 12(레슨 6)에서 GraphQL은 하나의 엔드포인트로 원하는 필드만 골라 받는 구조라고 배웠다. Insomnia는 요청 타입을 GraphQL로 선택하면 서버 스키마를 자동으로 읽어와 쿼리를 쓰는 동안 필드를 자동완성 해준다. 존재하지 않는 필드를 요청하면 보내기 전에 표시해주므로, "오타 때문에 실패한 것인지 서버가 잘못된 것인지"를 구분하는 시간이 줄어든다.

Design 탭 — OpenAPI 스펙이 곧 화면이 된다

모듈 12(레슨 4)에서 OpenAPI 스펙과 실제 동작이 일치하는지 검증하는 계약 테스트를 배웠다. Insomnia의 Design 탭은 그 스펙(YAML)을 편집기에 붙여넣으면 왼쪽에 스펙, 오른쪽에 사람이 읽는 문서 형태로 보여주고, 문법 오류(린트)도 즉시 잡아준다. 그 스펙에서 요청 묶음을 곧바로 생성할 수도 있다.

즉 "스펙 작성 → 문서 확인 → 요청 실행"이 한 창 안에서 이어진다. 계약 테스트를 배운 사람에게는 스펙이 종이 문서가 아니라 실행 가능한 출발점이라는 감각을 익히기 좋은 화면이다.

무료로 어디까지 되는가

Postman 무료 플랜은 협업(팀원 수, 컬렉션 실행 횟수) 쪽에 제한이 걸린다. 반면 Insomnia는 코어가 오픈소스라 혼자 또는 소규모 팀이 로컬에서 쓰는 범위에서는 사실상 제한 없이 쓸 수 있다. 학습용이나 개인 사이드 프로젝트에서는 이 점이 실질적인 장점이 된다.

실무에서 왜 필요한가

입사한 팀이 이미 Insomnia를 쓰고 있는 경우는 드물지 않다. 그때 "저는 Postman만 써봤는데요"라고 멈추지 않고, 하루 안에 적응해 요청을 만들 수 있어야 한다. 도구가 바뀌어도 검증해야 할 것(상태 코드, 응답 본문, 값)은 그대로이기 때문에, 실제로 새로 익힐 것은 화면 위치와 변수 문법 정도다.

또 사내 API 문서가 OpenAPI 스펙으로만 관리되는 팀이라면, Design 탭에서 스펙을 열어보는 것만으로 QA가 명세를 빠르게 파악할 수 있다.

실습 과제

과제 1 — Postman 어서션을 Insomnia로 옮기기 (10분)

모듈 12(레슨 2) 과제 1에서 작성했던 "상품 목록 조회 API" 어서션 세 가지(상태 코드 200, 응답이 배열, 배열이 비어있지 않음)를 Insomnia 문법으로 다시 작성한다.

const body = insomnia.response.json();
 
insomnia.test("상태 코드는 200이다", () => {
  insomnia.expect(insomnia.response.code).to.equal(200);
});
 
insomnia.test("응답은 배열이다", () => {
  insomnia.expect(body).to.be.an("array");
});
 
insomnia.test("상품이 최소 1개 이상이다", () => {
  insomnia.expect(body.length).to.be.above(0);
});

과제 2 — 도구 추천하기 (8분)

다음 두 팀에 Postman과 Insomnia 중 어느 쪽을 추천할지 고르고, 이 레슨의 비교 표를 근거로 두 문장씩 이유를 적는다.

1. 20명 규모의 QA·개발 조직. 컬렉션을 팀 전체가 공유하고 실행 이력을 관리해야 한다.
2. GraphQL API를 쓰는 3인 스타트업. 예산이 없고 각자 로컬에서 테스트한다.

자가 체크리스트

• Insomnia에서 요청을 만들고 환경 변수({{ _.변수명 }})를 사용할 수 있다
• Postman의 pm.test 어서션을 Insomnia 문법으로 옮겨 쓸 수 있다
• Insomnia의 GraphQL 지원이 어떤 이점을 주는지 설명할 수 있다
• Design 탭이 모듈 12(레슨 4)의 OpenAPI 계약 테스트와 어떻게 연결되는지 설명할 수 있다
• 팀 상황에 따라 Postman과 Insomnia 중 무엇을 추천할지 판단할 수 있다

흔한 실수

• 도구를 바꿨으니 처음부터 다시 배워야 한다고 생각한다. 요청 구성·어서션·환경 변수는 모듈 12에서 이미 배운 그대로다. 달라진 것은 화면 배치와 변수 표기법 정도다.
• Postman 문법(pm.)을 그대로 붙여넣고 왜 안 되는지 헤맨다. Insomnia는 insomnia. 네임스페이스를 쓴다. 어서션이 통째로 실행되지 않는다면 이 부분을 먼저 확인한다.
• 가볍다는 이유만으로 팀 도구를 갈아타자고 제안한다. 협업 기능이 중요한 조직에서는 무게감보다 공유·권한 관리가 더 큰 판단 기준이다.
• Design 탭을 단순한 텍스트 편집기로만 쓴다. 린트 경고와 스펙에서 요청을 생성하는 기능까지 써야 계약 테스트의 출발점으로 의미가 있다.

참고 자료

• Insomnia 공식 문서 — 설치부터 요청·환경 구성까지의 공식 가이드
• Insomnia — After-response scripts — 어서션 작성 문법 레퍼런스
• Insomnia — Design 문서 — OpenAPI 스펙 편집·린트 기능 안내