개념
화면이 없어도 탐험할 게 있다
지금까지의 탐험은 대부분 화면을 클릭하는 방식이었다. 하지만 API나 백엔드 서비스처럼 화면 자체가 없는 대상도 얼마든지 탐험할 수 있다. Postman이나 Insomnia 같은 도구로 API에 직접 요청을 보내며 실시간으로 반응을 관찰하고, 그 관찰을 근거로 다음 요청을 결정하는 것도 똑같은 탐색적 테스팅이다. 화면 대신 요청과 응답을 보며 같은 루프를 돈다 — 보내고, 돌아온 것에서 배우고, 그 배움으로 다음 요청을 정한다(레슨 1).
그리고 화면이 있어도 화면을 안 거치는 편이 나은 경우가 많다. 화면은 입력을 미리 걸러 준다 — 숫자 칸에는 숫자만 넣게 하고, 필수 칸을 비우면 제출을 막는다. 그 막아 둔 것들이 진짜 시험 대상인데 화면으로는 시도조차 못 한다.
| 화면으로 할 때 | 창구로 직접 할 때 |
|---|---|
| 숫자 칸에 글자를 못 넣는다 | 넣을 수 있다 |
| 필수 칸을 비울 수 없다 | 비울 수 있다 |
| 선택지에 없는 값을 못 고른다 | 보낼 수 있다 |
| 남의 것을 열 버튼이 없다 | 번호만 바꾸면 된다 |
| 화면이 막으면 서버도 막는지 모른다 | 서버가 진짜 막는지 확인된다 |
마지막 줄이 핵심이다. 화면에서 막는 것과 서버에서 막는 것은 다르다. 화면만 막아 뒀다면 누구나 우회할 수 있고, 그건 결함이다(레슨 8·모듈 50).
API를 탐험한다는 것
문서화된 정상 요청("행복 경로")을 넘어서 다음을 시도해본다.
- 필수 필드를 빼고 요청하면 어떤 에러가 오는가, 에러 메시지가 실제로 무엇이 잘못됐는지 알려주는가
- 잘못된 타입을 넣으면(숫자 필드에 문자열) 어떻게 되는가
- 문서에 없는 추가 필드를 넣으면 무시되는가, 에러가 나는가, 혹시 반영되어 버리는가(보안 문제일 수 있다)
- 같은 요청을 다른 HTTP 메서드로 보내면(GET으로 되어야 할 걸 POST로)
- 인증 토큰 없이, 혹은 만료된 토큰으로 요청하면
- 권한이 낮은 계정의 토큰으로 관리자용 요청을 보내면
- 요청에 들어가는 번호를 남의 것으로 바꾸면
- 페이지네이션 파라미터에 음수나 매우 큰 수를 넣으면
- 응답을 상태 코드뿐 아니라 본문(body)과 헤더까지 함께 확인한다
- 같은 요청을 아주 빠르게 두 번 보내면 두 번 처리되는가
- 남의 번호로 바꿔 보내면 막히는가
도구는 무엇을 쓰나
요청을 보내는 도구는 여러 가지지만 하는 일은 같다 — 주소·방식·헤더· 본문을 정해 보내고 응답을 보여 준다. 하나를 익히면 나머지는 화면만 다르다.
| 종류 | 특징 |
|---|---|
| 요청 도구(Postman·Insomnia 등) | 화면으로 다룬다. 묶어서 저장·반복이 쉽다 |
| 명령 줄 도구(curl 등) | 복사·붙여넣기로 공유하기 좋다. 리포트에 그대로 붙인다 |
| 브라우저 개발자 도구 | 이미 로그인된 상태 그대로 요청을 다시 보낼 수 있다 |
리포트에는 명령 줄 형태로 붙이는 것이 가장 쓸모 있다. 개발자가 복사해서 바로 실행해 볼 수 있기 때문이다. 요청 도구에서도 대개 그 형태로 내보낼 수 있다.
도구 자체의 사용법은 모듈 19에서 다룬다. 여기서는 무엇을 보낼지 정하는 눈이 주제다 — 도구는 금방 배우고, 무엇을 보낼지는 오래 걸린다.
무엇부터 보나 — 네 묶음
목록이 길면 손이 안 간다. 네 묶음으로 외워 두면 어떤 창구에서나 바로 시작할 수 있다.
하나, 빼 본다. 필수 필드를 하나씩 빼고 보낸다. 빠졌다고 알려 주는가, 그냥 넘어가는가, 엉뚱한 값으로 처리되는가. 오류 메시지가 무엇이 빠졌는지 알려 주는지도 함께 본다.
둘, 바꿔 본다. 값의 종류를 바꾼다. 숫자 자리에 글자, 날짜 자리에 아무 글자, 참·거짓 자리에 숫자. 그리고 범위를 벗어난 값 — 음수, 0, 아주 큰 수, 아주 긴 글자.
셋, 더해 본다. 문서에 없는 필드를 끼워 넣거나, 같은 필드를 두 번 넣는다. 무시되면 정상이고, 반영되면 큰 문제다. "할인율" 이나 "권한" 같은 필드를 끼워 넣었는데 먹히면 그건 심각한 보안 결함이다.
넷, 남의 것을 건드려 본다. 요청에 들어가는 번호를 다른 사람 것으로 바꾼다. 내 주문 번호 대신 옆 계정의 주문 번호를 넣어 조회·수정·삭제를 시도한다. 가장 빨리 큰 결함이 나오는 방향이다.
네 묶음을 빼기·바꾸기·더하기·남의 것 으로 기억하면 된다. 레슨 5의 일곱 묶음이 "상황" 을 바꾸는 축이었다면, 이 넷은 요청 자체를 바꾸는 축이다. 그리고 넷째가 가장 생산적이다 — 화면에서는 버튼이 없어서 시도조차 못 하던 것을 여기서는 바로 해 볼 수 있다.
응답에서 볼 것도 정해 둔다
보내는 것만큼 받는 것을 어떻게 보는지가 중요하다. 네 자리를 본다.
| 자리 | 볼 것 |
|---|---|
| 상태 코드 | 성공·실패가 맞는 코드인가. 200인데 실패는 아닌가 |
| 본문 | 값이 맞는가. 필요 이상의 정보가 들어 있지는 않은가 |
| 헤더 | 캐시 설정, 보안 관련 항목 |
| 시간 | 느린 요청은 없는가. 어떤 입력에서 갑자기 느려지는가 |
두 번째 줄의 뒷부분이 자주 간과된다. 주문 조회 응답에 주문과 상관없는 개인정보가 섞여 오는 경우가 흔하다. 화면이 안 보여 줄 뿐 데이터는 이미 브라우저까지 왔다. 화면만 보면 절대 안 보이는 종류의 결함이다.
네 번째도 탐험 중에 공짜로 얻는다. 요청마다 걸린 시간이 도구에 표시되므로, 유독 느린 요청이 눈에 띄면 그 자리가 성능 문제의 출발점이다.
응답이 느린 것도 발견이다
탐험 중에 유독 느린 요청이 보이면 그냥 지나치지 않는다. 느림은 대개 데이터가 많아질 때 더 느려지는 구조를 가리키고, 운영에서 터지는 성능 문제는 거의 다 여기서 시작된다.
세 가지를 더 해 본다.
- 데이터를 늘려 본다 — 목록이 10건일 때와 500건일 때를 비교한다
- 조건을 바꿔 본다 — 검색어를 비우거나, 기간을 아주 넓게 잡는다
- 반복해 본다 — 두 번째 요청이 빠르면 캐시가 있는 것이고, 매번 느리면 계산이 매번 도는 것이다
세 번째가 특히 유용하다. 첫 요청만 느리고 다음부터 빠르면 사용자 입장에서는 "가끔 느리다" 로 체감된다. 그 "가끔" 의 정체를 설명할 수 있으면 리포트의 값이 달라진다.
여기서 나온 것은 본격적인 성능 시험으로 넘긴다(모듈 16·51). 탐험의 몫은 "여기가 느리다" 를 찾아 넘기는 것까지다.
모듈 12와는 무엇이 다른가
모듈 12(API·계약 테스트)는 체계적으로 설계된 API 테스트(계약 검증, 자동화)를 다룬다. 이 레슨은 그 전 단계 — 아직 체계가 안 잡힌 상태에서 실시간으로 API를 찔러보며 감을 잡는 탐색적 활동이다.
| 이 레슨 | 모듈 12 | |
|---|---|---|
| 전제 | 문서가 없어도 된다 | 명세가 있다 |
| 다음 요청을 정하는 것 | 방금 본 응답 | 설계한 목록 |
| 산출 | 결함 + 다음에 볼 것 | 자동화된 검증 |
| 언제 | 새 창구가 막 생겼을 때 | 계약이 굳은 뒤 |
| 자연스럽게 이어진다 — 탐험하며 발견한 흥미로운 케이스가, 나중에 | ||
| 모듈 12에서 배울 자동화된 API 테스트의 재료가 된다. |
오류 메시지 자체가 시험 대상이다
창구 탐험에서 응답으로 오는 오류 문구는 두 방향으로 본다. 서로 반대 방향이라 균형을 맞춰야 한다.
| 방향 | 묻는 것 | 너무 지나치면 |
|---|---|---|
| 친절한가 | 무엇이 잘못됐는지 알려 주는가 | — |
| 너무 많이 말하는가 | 내부 구조가 드러나지 않는가 | 보안 문제 |
"오류가 발생했습니다" 만 오면 개발자도 사용자도 아무것도 못 한다. 반대로 데이터베이스 오류 원문이나 내부 경로가 그대로 오면 공격자에게 지도를 주는 셈이다.
좋은 응답은 사용자에게는 무엇을 해야 하는지, 개발자에게는 어디를 봐야 하는지를 나눠 준다. 보통 사용자용 문구와 추적용 식별자를 함께 주는 방식을 쓴다 — 사용자는 그 번호를 문의에 적고, 개발자는 그 번호로 기록을 찾는다.
탐험 중에 일부러 오류를 많이 만들어 보는 이유가 이것이다. 정상 경로만 보면 오류 문구를 한 번도 안 보게 되는데, 실제 사용자가 가장 자주 보는 화면이 오류 화면인 경우가 많다.
요청을 어디서 얻나 — 화면에서 베낀다
"창구 주소를 모르는데 어떻게 보내나" 가 첫 벽이다. 문서가 없어도 된다. 화면이 보내는 요청을 그대로 베끼면 된다.
- 개발자 도구의 네트워크 탭을 켠다
- 화면에서 그 기능을 한 번 정상적으로 쓴다
- 나간 요청에서 복사한다(도구마다 "cURL로 복사" 같은 메뉴가 있다)
- 그것을 요청 도구에 붙여 넣으면 인증까지 그대로 들어간다
- 이제 값을 바꿔 가며 보낸다
4번이 요령이다. 인증 토큰을 따로 구할 필요 없이 방금 쓰던 그대로 복사되므로, 바로 다음 요청부터 바꿔 볼 수 있다.
이 방법에는 부수 효과가 하나 있다. 3번에서 화면이 실제로 무엇을 보내는지 읽게 된다. 화면에 없던 필드가 요청에 들어 있거나, 보낼 필요 없는 값이 함께 나가는 것이 그때 보인다.
사례 — 번호 하나를 바꿨을 뿐인데
가장 흔한 결함이 어떻게 나오는지 한 건으로 보자.
출발. 주문 상세 화면을 열고 네트워크 탭을 본다. 요청이 하나 나간다.
GET /api/orders/104821분 뒤. 번호를 10481 로 바꿔 보낸다. 응답이 온다. 내 주문이
아닌데 금액·배송지·전화번호가 전부 들어 있다.
여기서 멈춘다. 조회까지만 하고 수정·삭제는 하지 않는다. 그리고 리포트를 쓴다.
제목: 다른 사용자의 주문을 주문번호만으로 조회할 수 있음
재현: 로그인 후
GET /api/orders/{번호}에서 본인 주문이 아닌 번호를 요청 실제:200과 함께 타인의 배송지·연락처·결제 금액이 응답에 포함됨 기대:403또는404, 본문에 타인 정보 없음 범위: 번호가 순차 증가라 임의의 주문을 모두 조회 가능
마지막 줄이 심각도를 결정한다. 번호가 1씩 늘어나는 숫자면 누구나 처음부터 끝까지 훑을 수 있다. 번호가 추측 불가능한 문자열이었다면 같은 결함이라도 위험도가 낮다.
화면에는 아무 단서가 없었다. 주문 상세 화면은 완벽하게 동작했고, 남의 주문으로 가는 링크도 없었다. 요청을 직접 보내는 순간에만 보인다.
창구 탐험에서 자주 나오는 것들
같은 종류의 결함이 반복해서 나온다. 처음 보는 제품에서도 이 다섯은 해 볼 만하다.
| 시도 | 자주 나오는 결함 |
|---|---|
| 남의 번호로 조회 | 권한 확인 누락 — 가장 흔하고 가장 크다 |
| 음수·0 수량으로 주문 | 금액이 음수가 되거나 포인트가 늘어난다 |
| 아주 큰 수·긴 글자 | 저장 실패, 화면 깨짐, 느려짐 |
| 같은 요청 연속 두 번 | 중복 생성 |
| 상태가 아닌데 다음 단계 요청 | 막아야 하는 전이가 통과(레슨 8) |
두 번째가 금전 사고로 직결된다. 수량에 음수를 넣으면 합계가 음수가 되고, 그 금액으로 결제가 처리되면 돈이 거꾸로 들어온다. 화면에서는 수량 칸이 1 밑으로 안 내려가니 아무도 시도하지 않는다.
찾은 것을 자동화로 넘기기
창구 탐험의 좋은 점 하나는 발견을 그대로 자동화로 넘기기 쉽다는 것이다. 화면 자동화는 다시 짜야 하지만, 창구는 보낸 요청이 곧 시험 코드의 재료다.
- 요청과 기대 응답이 이미 손에 있다
- 도구에서 그대로 저장해 두면 다음에 다시 보낼 수 있다
- 같은 묶음을 여러 번 돌리는 것도 도구가 해 준다
그래서 탐험에서 결함을 찾으면 그 요청을 저장해 두는 습관이 값을 한다. 고친 뒤 다시 보내 확인하고, 그대로 회귀 자산이 된다(레슨 1의 "탐험이 찾고 자동화가 지킨다").
다만 전부 자동화하지는 않는다. 탐험 중 보낸 수십 개 요청 중 결함이 나왔던 것과 경계에 있던 것만 남긴다. 다 넣으면 유지 비용만 늘고 아무도 안 보게 된다(모듈 11).
하면 안 되는 것
창구를 직접 두드리는 것은 힘이 세서 위험도 크다. 세 가지를 지킨다.
- 운영 환경에서 함부로 하지 않는다. 실제 주문이 생기고 실제 돈이 움직이고 실제 메일이 고객에게 나간다
- 남의 계정 데이터를 실제로 바꾸지 않는다. 권한 확인 누락을 발견했으면 조회까지만 하고 보고한다. 수정·삭제까지 해 보는 것은 선을 넘는다
- 대량 요청을 보내지 않는다. 부하 시험은 합의된 환경에서 한다. 탐험 중에 반복 요청을 자동으로 돌리면 서비스를 멈출 수 있다
두 번째는 특히 분명히 해 둔다. 우리 시스템이라도 남의 데이터다. 발견을 증명하는 데 필요한 최소한만 하고, 나머지는 리포트에 적는다. 남의 시스템을 대상으로 하는 것은 아예 범죄다(모듈 50 레슨 5).
화면 없는 대상은 창구만이 아니다
같은 발상이 통하는 자리가 더 있다. 사람이 조작하지 않는 것들이다.
| 대상 | 어떻게 탐험하나 |
|---|---|
| 배치·정기 작업 | 실행 시각을 바꿔 돌려 본다. 중간에 멈추면? 두 번 돌면? |
| 파일 업로드·내려받기 | 형식이 다른 파일, 아주 큰 파일, 빈 파일, 이름에 특수문자 |
| 메일·알림 발송 | 받는 사람이 없으면? 주소가 잘못됐으면? 한꺼번에 많이? |
| 데이터 가져오기·내보내기 | 열이 빠진 파일, 인코딩이 다른 파일, 중복된 행 |
| 들어오는 알림 | 같은 것을 두 번 보내면? 순서를 바꿔 보내면?(레슨 9) |
두 번째와 네 번째가 특히 많이 샌다. 파일을 다루는 기능은 "정상적인 파일" 로만 시험되는 경우가 대부분이고, 실제 사용자는 엑셀에서 대충 만든 파일을 올린다.
빈 파일·헤더만 있는 파일·행이 10만 개인 파일 셋만 해 봐도 보통 한 건은 나온다. 그리고 그런 파일은 1분이면 만들 수 있다.
실무에서 왜 필요한가
이 역량이 QA 의 일을 바꾸는 지점은 분명하다. "이상한데요" 에서 "이 요청이 이 값을 돌려줍니다" 로 보고가 바뀐다.
같은 결함을 두 가지로 보고해 보면 차이가 보인다.
| 화면만 봤을 때 | 창구까지 봤을 때 |
|---|---|
| "할인이 가끔 안 돼요" | "POST /orders 요청에 할인 금액이 아니라 원가가 실려 나갑니다" |
| "목록이 안 뜰 때가 있어요" | "20건이 넘으면 500이 오고 본문에 시간 초과가 적혀 있습니다" |
| "저장이 안 됐어요" | "200이 왔지만 본문이 success:false 이고 저장소에 행이 없습니다" |
오른쪽은 개발자가 코드를 열 지점을 바로 알려 준다. 왼쪽은 개발자가 재현부터 다시 해야 한다. 같은 결함인데 수정까지 걸리는 시간이 다르다.
백엔드 결함은 화면에 간접적으로만 드러나는 경우가 많아서, 화면만 보는 QA는 원인을 못 찾고 "뭔가 이상한데 왜인지 모르겠다"는 상태에 머문다. API를 직접 탐험할 수 있는 QA는 "화면에서 이상하게 보이는 이유가 사실 API가 잘못된 값을 주고 있어서"라는 것까지 스스로 밝혀낼 수 있다. 이건 QA의 역할을 넓히는 실질적인 역량이고, 백엔드/API 테스트 비중이 커지는 채용시장 흐름과도 맞닿아 있다(모듈 9에서 다룰 개발 지식과 직결된다).
채용시장에서의 위치
창구를 직접 다룰 수 있는지는 QA 채용에서 가장 분명한 분기점 중 하나다. 공고에 "API 테스트 경험" 이 들어가면 그 자리는 화면만 보는 사람을 뽑지 않겠다는 뜻이다.
면접에서는 이렇게 확인된다.
- "Postman 써 보셨어요?" — 도구 이름을 묻는 것 같지만 실제로는 창구를 직접 두드려 본 적이 있는가를 묻는 것이다
- "화면에서 막는데 서버도 막는지 어떻게 확인하셨나요?" — 이 레슨의 핵심 질문이고, 답할 수 있으면 보안 감각이 있는 사람으로 읽힌다
- "권한 테스트는 어떻게 하셨나요?" — "다른 계정의 번호로 요청을 보내 봤습니다" 가 구체적인 답이다
그리고 이 역량은 자동화로 가는 다리이기도 하다. 창구를 손으로 두드릴 줄 알면 그다음은 그것을 코드로 적는 것뿐이다(모듈 12). 화면 자동화보다 배우기 쉽고 덜 깨지므로, 자동화를 시작하는 가장 좋은 지점이다.