AI에게 API 엔드포인트에 대한 테스트를 작성해 달라고 요청하면, 미묘하게 위험한 행동을 할 것입니다. 바로 API가 현재 제공하는 응답을 살펴보고, 그 응답을 고착화하는 단언(assertions)을 작성하는 것입니다.

만약 그 응답이 올바르다면 — 좋습니다, 20분을 절약한 셈입니다. 만약 그 응답이 버그라면 — 예를 들어, API가 잘못된 페이로드(payload)에 대해 잘못된 200 OK를 반환한다면 — AI는 기쁘게 pm.test("Status code is 200", ...)를 생성할 것이고, 여러분의 버그는 이제 영원히 녹색 테스트(green test)에 의해 보호받는 _기대되는 동작(expected behaviour)_이 되어 버립니다.

이것이 AI 보조 테스트(AI-assisted testing)의 긴장감을 한 문장으로 요약한 것입니다: AI가 생성한 테스트는 응답이 무엇인지(what a response is)를 검증할 뿐, 응답이 무엇이어야 하는지(what it should be)를 검증하지 않습니다. 명세(specification)는 여러분의 머릿속과 문서에 존재하지만, AI는 오직 통신 데이터(wire)만을 볼 뿐입니다.

저는 매일 AI 테스트 생성을 사용하며, 이를 피하라고 말씀드리는 것이 아닙니다. 여러분의 테스트 스위트(suite)를 조용히 부패시키지 않고 사용하는 방법을 말씀드리는 것입니다.

AI가 진정으로 잘하는 것

Postman의 내장 어시스턴트인 Postbot은 대부분의 API 테스터가 가장 먼저 접하게 될 도구입니다 (이 패턴은 Copilot, Claude 또는 여러분이 사용하는 무엇에도 동일하게 적용됩니다). Postbot의 가장 강력한 기능은 다음과 같습니다:

보일러플레이트(Boilerplate) 생성. 요청을 열고, 응답이 존재하도록 한 번 전송한 뒤, Scripts → Post-response를 열고 평범한 영어로 프롬프트를 입력하세요:

"상태 코드(status code), 콘텐츠 타입(content type), 그리고 응답 시간이 500ms 미만인지에 대한 테스트를 추가해줘."

그러면 에디터에 즉시 관용적인 pm.test / pm.expect 코드를 작성해 줍니다. 전체 컬렉션(collection)에 대해서는, 컬렉션 메뉴에서 Generate tests를 선택하여 모든 요청에 기본 테스트를 한 번에 추가할 수 있습니다. 몇 시간 걸릴 보일러플레이트 작업이 몇 분의 검토 작업으로 바뀝니다.

깨진 스크립트 수정. 테스트에서 에러가 발생하면, Postbot의 Fix script가 이를 분석하고 수정을 제안합니다. 구문 오류(syntax slips)나 오래된 JSON 경로(JSON paths)에 대해서는 마법에 가까운 성능을 보여줍니다.

탐색. "이 요청의 무엇이 잘못되었나요?", "이 응답을 테이블 형태로 시각화해줘", "이 컬렉션을 문서화해줘" — 예전에는 20분 동안 읽어야 했던 것들을 문맥을 파악한 답변으로 제공합니다.

테스트 케이스 브레인스토밍 (Test-case brainstorming). Postman 외에도, OpenAPI 명세 (spec)를 LLM에 입력하고 엣지 케이스 (edge cases)를 요청하는 것은 진정으로 생산적입니다. LLM은 당신이 나열하지 못했던 경계값 (boundary values), 기이한 유니코드 (Unicode), 그리고 상태 전이 (state transitions)를 제안할 것입니다. 출력된 결과물을 그대로 붙여넣을 테스트 스위트 (suite)가 아니라, _평가하기 위한 체크리스트 (checklist)_로 취급하세요.

구체적으로 실패하는 지점들

세 가지 실패 모드 (failure modes)가 반복됩니다:

1. 관찰된 동작의 함정 (The observed-behaviour trap) (위에서 언급한 가장 큰 문제). 생성된 모든 어설션 (assertion)은 응답이 아니라 _명세 (spec)_를 기준으로 검토해야 합니다. 질문은 결코 "이것이 돌아온 응답과 일치하는가?"가 되어서는 안 됩니다. AI는 이미 그것을 보장했기 때문입니다. 질문은 "돌아온 응답이 올바른가?"가 되어야 합니다.

2. 해피 패스 편향 (Happy-path bias). 테스트를 요청하면 성공 케이스 (success cases)를 받게 될 것입니다. 잘못된 비밀번호, 누락된 필드, 만료된 토큰, 잘못된 형식의 바디 (malformed bodies), 공격자가 보내는 요청과 같은 네거티브 스위트 (negative suite)에는 여전히 인간의 적대적 본능 (adversarial instinct)이 필요합니다. 저의 경험칙은 이렇습니다: 실제 엔드포인트 (endpoint)에는 긍정적인 케이스 하나당 5개에서 10개의 네거티브/경계 케이스가 필요하지만, AI는 별도의 프롬프트 없이는 그중 거의 아무것도 자발적으로 제공하지 않습니다.

3. 그럴듯한 헛소리 (Plausible nonsense). 때때로 생성된 어설션 (assertion)은 구문론적으로는 완벽하지만 의미론적으로는 비어 있는 경우가 있습니다. 예를 들어, 배열이 올바른 내용을 포함하고 있는지 확인하는 대신 단순히 배열이 "존재하는지"만 확인하는 식입니다. 이런 것들로 가득 찬 스위트는 정직하고 작은 스위트보다 더 나쁩니다. 왜냐하면 커버리지 (coverage)가 확보된 것처럼 보이기 때문입니다.

실무 프로토콜 (The working protocol)

이것을 실무에 적용하면 다음과 같습니다:

1. 먼저 수동으로 테스트를 작성하는 법을 배우세요. 순수주의를 위해서가 아닙니다. 이제 리뷰(Review)가 업무의 전부가 되었으며, 본인이 직접 작성할 수 없는 코드는 리뷰할 수 없기 때문입니다. 읽을 수 없는 테스트는 신뢰할 수 없는 테스트입니다.
2. 생성한 후, 심문하세요. 각 AI 단언(Assertion)에 대해 다음과 같이 질문하십시오: 명세서(Spec)에 이 내용이 명시되어 있는가? 만약 응답이 가장 발생하기 쉬운 방식으로 틀렸다면, 이 테스트가 그것을 잡아낼 수 있는가?
3. 부정적인 케이스(Negatives)는 직접 추가하세요. 상용구(Boilerplate) 작성에서 절약한 시간을 AI가 건너뛴 적대적 케이스(Adversarial cases)를 처리하는 데 할당하십시오.
4. 프롬프트에 비밀 정보를 절대 붙여넣지 마세요. 토큰(Tokens), 고객 데이터, 내부 URL 등은 계약상 보호받는 계획이 없는 한 어떤 AI 대화에도 포함되어서는 안 됩니다. (엔터프라이즈 플랜의 Postbot은 입력 데이터를 학습에서 제외합니다. 귀하의 티어 약관을 확인하십시오.)
5. 테스트 스위트(Suite)를 책임지세요. 만약 생성된 테스트가 6개월 후에 실패한다면, 누군가는 90초 안에 이를 이해해야 합니다. 그 누군가는 바로 당신입니다.

정직한 프레임워크 (The honest framing)

이러한 방식으로 사용한다면, AI는 Newman이 테스트 실행(Execution)에 대해 했던 것처럼 테스트 작성(Authoring)에 대해 수행합니다. 즉, 지루한 반복 작업은 제거하고 당신에게는 판단(Judgement)을 남겨둡니다. AI로 인해 어려움을 겪는 테스터들은 판단력까지 통째로 넘겨버리는 사람들입니다. 그러고는 왜 자신의 '그린(Green)' 테스트 스위트가 설계상부터 '그린'이었던 버그를 놓쳤는지 의아해합니다.

반복은 기계에게, 의미는 인간에게. 이러한 분업은 LLM 이전에도 사실이었으며, 다음에 무엇이 오더라도 사실일 것입니다.

_제 무료 오픈 소스 도서 *API Testing Using Postman: The Practical Guide to Modern API Testing의 14장에서 발췌되었습니다. — AI 지원 CI/CD 파이프라인에 대한 첫 요청부터 시작되는 15개의 장으로 구성되어 있습니다. 온라인에서 읽거나, PDF/EPUB을 받거나, GitHub에서 기여할 수 있습니다.

저는 Nottingham Trent University에서 사이버 보안 및 AI 지원 보안 테스트를 연구하는 컴퓨터 과학 박사 과정 연구원입니다. 더 자세한 내용은 imranalmunyeem.com에서 확인하세요.