에이전트가 테스트를 작성했습니다. Cursor는 미처 생각하지 못했던 세 가지 엣지 케이스를 제안했습니다. Copilot은 요청 본문을 채웠고, Claude는 전체를 한 번 실행하여 성공(초록색)으로 보고했습니다. 그렇다면 자연스럽게 이런 질문이 나옵니다. 에이전트가 이 모든 일을 한다면, AI가 API 테스트를 완전히 대체할 수 있을까요?
아니요. AI는 API 테스트를 완전히 대체할 수 없지만, 테스트 작성 작업의 상당 부분을 대체할 수 있습니다. 에이전트는 테스트 케이스 초안을 만들고, 엣지 케이스를 제안하며, 요청 본문을 생성하는 데 강합니다. 반면 모든 실행에서 동일하게 테스트 스위트를 수행하고, 통과·실패 결과로 병합을 차단하며, 계약 자체가 올바른지 결정하는 일은 결정론적인 도구와 사람이 맡아야 합니다.
이 글은 더 큰 질문, 즉 AI 에이전트 시대에도 API 도구가 필요한가의 테스트 관점에 집중합니다. 핵심은 AI가 맡을 수 있는 작업과 맡아서는 안 되는 작업의 경계를 명확히 하는 것입니다.
이 경계를 모르면 두 가지 실수를 하기 쉽습니다.
- 에이전트의 판단을 병합 게이트로 신뢰한다.
- 에이전트가 잘하는 테스트 작성 작업까지 쓸모없다고 판단한다.
이 글이 사용법 안내와 다른 점
에이전트를 API 테스트에 연결하는 구체적인 방법이 필요하다면 API 테스트에 AI 에이전트 사용하기를 참고하세요. 해당 가이드는 에이전트를 엔드포인트와 연결하고 테스트 초안을 받는 방법을 다룹니다.
이 글은 다른 질문에 답합니다.
AI에게 어디까지 맡기고, 어디부터는 결정론적인 도구로 검증해야 하는가?
에이전트 지원 테스트 흐름을 구축 중이라면 두 글을 함께 보세요. 하나는 방법을, 다른 하나는 경계를 다룹니다.
현재 AI가 테스트에서 정말 잘하는 것
AI 에이전트는 테스트를 작성하는 작업에서 특히 유용합니다. 빈 테스트 파일에서 시작하는 대신, 검토 가능한 초안에서 시작할 수 있기 때문입니다.
1. 사양 또는 예제에서 테스트 케이스 초안 작성
엔드포인트 정의와 샘플 응답을 제공하면 에이전트는 몇 초 안에 기본 스위트를 만들 수 있습니다.
일반적으로 다음과 같은 검사가 포함됩니다.
- 상태 코드 검사
- 필수 응답 필드 검사
- 해피 패스 요청 본문 생성
- 기본 오류 응답 검토
예를 들어 다음과 같은 응답 예제가 있다면:
{
"id": "usr_123",
"email": "developer@example.com",
"status": "active"
}
에이전트는 다음과 같은 초안 어설션을 제안할 수 있습니다.
expect(response.status).toBe(200);
expect(response.body.id).toBeDefined();
expect(response.body.email).toContain("@");
expect(response.body.status).toBe("active");
이 코드는 최종본이 아닙니다. 하지만 빈 편집기보다 훨씬 빠른 출발점입니다.
2. 놓치기 쉬운 엣지 케이스 제안
에이전트는 “이 엔드포인트를 무엇이 망가뜨릴 수 있는가?”라는 질문에 유용한 후보를 제시합니다.
대표적인 예시는 다음과 같습니다.
- 빈 배열
- 필수 필드의
null - 누락된 필수 필드
- 만료된 인증 토큰
- 잘못된 날짜 형식
- 시간대 경계
- 중복 요청
- 페이지네이션의 마지막 페이지
- 예상보다 큰 요청 본문
모든 문제를 찾아내지는 못합니다. 하지만 사람이 반복적으로 작성하는 해피 패스 테스트만으로는 놓치기 쉬운 경우를 빠르게 확장할 수 있습니다.
3. 요청 본문과 픽스처 생성
필드가 많은 요청 본문이나 대량의 테스트 데이터는 작성 비용이 큽니다. 에이전트는 스키마를 기반으로 유효한 페이로드와 픽스처를 빠르게 생성할 수 있습니다.
예를 들어 다음과 같은 입력 스키마가 있다면:
{
"name": "string",
"email": "string",
"role": "admin | member",
"timezone": "string"
}
에이전트는 다음과 같은 테스트용 본문을 초안으로 만들 수 있습니다.
{
"name": "Kim Dev",
"email": "kim.dev@example.com",
"role": "member",
"timezone": "Asia/Seoul"
}
Model Context Protocol을 통해 실제 사양을 연결하면, 에이전트가 추측한 필드가 아니라 실제 API 정의에 맞춰 요청 본문을 생성하게 할 수 있습니다.
4. 초안 어설션 작성
“응답이 유효한 사용자인지 확인” 같은 요구사항을 구체적인 검사로 바꾸는 작업도 에이전트가 잘합니다.
expect(response.body).toMatchObject({
id: expect.any(String),
email: expect.stringMatching(/@/),
status: expect.any(String)
});
다만 이 단계의 결과물은 반드시 검토해야 합니다. 에이전트는 어설션을 작성할 수 있지만, 어떤 값이 제품 계약상 반드시 보장되어야 하는지 최종 결정하지는 못합니다.
요약하면, AI 에이전트는 테스트 아티팩트 생성에 강합니다.
여전히 결정론적인 도구가 필요한 것
다음 작업은 같은 입력에 대해 항상 같은 결과가 나와야 합니다. 즉, 테스트 작성이 아니라 검증과 실행의 영역입니다.
1. 모든 커밋에서 스위트를 동일하게 실행
병합 게이트의 기본 조건은 단순합니다.
같은 커밋은 매번 같은 통과 또는 실패 결과를 만들어야 한다.
에이전트가 테스트를 실행하고 요약할 수는 있습니다. 하지만 같은 요청을 두 번 했을 때 서로 다른 요약이나 판단이 나올 수 있습니다. 탐색과 조사에는 괜찮지만, 병합을 차단하는 기준으로는 적합하지 않습니다.
2. 실제 통과·실패 결과로 CI 게이팅
CI는 자연어 요약이 아니라 종료 코드로 동작합니다.
# 성공: exit code 0
# 실패: non-zero exit code
“좋아 보입니다”라는 채팅 응답은 CI가 처리할 수 있는 신호가 아닙니다. 반면 헤드리스 테스트 러너는 실제 실행 결과와 종료 코드를 반환하므로, 병합 규칙에서 사용할 수 있습니다.
3. 계약과 스키마 형태 어설션
다음 질문은 모델의 의견을 묻는 일이 아닙니다.
이 응답은 소비자가 의존하는 OpenAPI 계약을 여전히 만족하는가?
이것은 고정된 사양에 대한 고정된 검사입니다. 필수가 된 필드가 빠졌거나, 타입이 바뀌었거나, 응답 구조가 달라졌다면 같은 방식으로 실패해야 합니다.
계약의 기준점은 OpenAPI Specification과 같은 명시적인 정의입니다.
4. 실패한 호출을 정확히 재현
문제가 발생하면 에이전트의 요약이 아니라 실제 요청과 응답이 필요합니다.
확인해야 할 정보는 다음과 같습니다.
- 요청 URL과 메서드
- 요청 헤더
- 요청 본문
- 응답 상태 코드
- 응답 헤더와 본문
- 호출 순서
- 인증 토큰과 만료 상태
에이전트가 “유효한 토큰을 보냈다”고 설명해도, 실제 클라이언트가 만료된 토큰을 전송했다면 결과는 다릅니다. 디버깅에서는 설명보다 관측 가능한 실제 데이터가 중요합니다.
2026년의 구분: AI가 잘하는 것 vs 결정론적인 도구가 필요한 것
| 테스트 작업 | 오늘날의 AI 에이전트 | 이유 |
|---|---|---|
| 첫 테스트 스위트 초안 작성 | 잘함 | 사양과 예제에서 패턴을 생성하는 작업임 |
| 엣지 케이스 제안 | 잘함 | 사람이 놓치기 쉬운 후보를 폭넓게 제안함 |
| 요청 본문 및 픽스처 생성 | 잘함 | 빠르며, 사양이 연결되면 실제 필드에 맞출 수 있음 |
| 초안 어설션 작성 | 수행 가능, 검토 필요 | 좋은 출발점이지만 최종 계약 판단은 아님 |
| 모든 커밋에서 스위트를 동일하게 실행 | 결정론적인 러너 필요 | 모델 출력은 실행마다 달라질 수 있음 |
| 통과·실패 기준으로 CI 게이팅 | 결정론적인 러너 필요 | 병합 규칙은 실제 종료 코드를 필요로 함 |
| 계약 및 스키마 형태 어설션 | 결정론적인 도구 필요 | 고정된 사양에 대한 고정된 검사임 |
| 실패한 호출을 정확히 재현 | 검사 가능한 클라이언트 필요 | 요약은 실제 전송 데이터가 아님 |
| 계약이 올바른지 결정 | 인간 필요 | 테스트가 아니라 제품 결정임 |
상위 네 가지는 에이전트에 맡기기 좋습니다. 하위 다섯 가지는 “AI가 API 테스트를 대체한다”는 말만으로는 해결할 수 없는 영역입니다.
모델이 병합 게이트가 될 수 없는 이유
문제는 모델의 품질이 아니라 동작 방식입니다.
LLM은 출력을 샘플링합니다. 온도, 샘플링 설정, 모델 내부의 비결정적 경로에 따라 같은 프롬프트도 다른 텍스트를 만들 수 있습니다. 글쓰기와 브레인스토밍에서는 장점이지만, 병합 게이트에서는 원하지 않는 특성입니다.
좋은 게이트는 지루할 만큼 반복 가능해야 합니다.
- 초록색은 매번 같은 이유로 초록색이어야 합니다.
- 빨간색은 매번 같은 계약 위반을 가리켜야 합니다.
- 실패 결과는 사람이 다시 확인할 수 있어야 합니다.
따라서 역할을 분리하세요.
- 모델이 테스트를 초안으로 작성합니다.
- 사람이 계약과 어설션을 검토합니다.
- 결정론적인 러너가 CI에서 동일하게 실행합니다.
- 종료 코드가 병합 규칙을 통과하거나 차단합니다.
이 경계를 건너뛸 때 발생하는 운영 문제는 AI 에이전트가 프로덕션에서 고장나는 이유에서도 확인할 수 있습니다.
Apidog의 역할: 검사 후 검증
Apidog는 에이전트 프레임워크가 아니라 검증 레이어에 속합니다.
즉, Apidog는 에이전트를 작성하거나 실행하지 않으며, 에이전트를 대신해 제품 결정을 내리지 않습니다. 오픈 소스 도구도 아닙니다. 대신 모델이 담당하기 어려운 두 영역을 지원합니다.
검사: AI 에이전트 디버거
2026년 5월에 출시된 Apidog AI 에이전트 디버거는 에이전트 실행을 검사하는 표면입니다.
다음 정보를 시각화할 수 있습니다.
- LLM 호출
- MCP 도구 호출
- 다중 턴 교환
- API 레이어에서 실제로 전송된 요청
호출이 실패했을 때 중요한 것은 “에이전트가 무엇을 의도했는가”가 아니라 “API에 무엇을 보냈는가”입니다. 이 도구는 런타임이 아니라 디버거입니다. 에이전트를 구축하거나 실행하지는 않지만, 실제 호출을 확인할 수 있게 합니다.
검증: Apidog CLI
Apidog CLI는 저장된 테스트 케이스를 헤드리스 방식으로 실행하는 결정론적인 러너입니다.
CI에 연결할 때 필요한 특성은 다음과 같습니다.
- 저장된 테스트 케이스 실행
- 실제 종료 코드 반환
- 손상된 계약에 대한 빌드 실패
- 반복 가능한 실행
- 로그인 없이 실행 가능
에이전트가 만든 초안을 CI가 신뢰할 수 있는 게이트로 바꾸는 역할이 여기에 있습니다.
사양을 에이전트에 연결하기
사양은 에이전트와 검증 도구를 연결하는 중심점입니다.
npx apidog-mcp-server
이 명령으로 OpenAPI 정의를 Cursor, Copilot 또는 Claude Code에 제공하면, 에이전트가 가상의 엔드포인트가 아니라 실제 정의를 기준으로 테스트 초안을 작성할 수 있습니다.
Apidog MCP 서버는 계정 없이도 사용해 볼 수 있습니다.
또한 Apidog의 스마트 목(mock)을 사용하면 요청에 따라 429, 500, 타임아웃을 반환해 복구 경로를 테스트할 수 있습니다. 에이전트 코드가 정상 응답뿐 아니라 실패 조건에서도 올바르게 동작하는지 확인할 때 유용합니다.
시작하려면 Apidog를 다운로드하세요. 무료 티어는 이 기능들을 포함합니다.
정리하면 다음과 같습니다.
- 에이전트는 테스트를 초안으로 작성합니다.
- AI 에이전트 디버거는 에이전트가 실제로 수행한 호출을 보여줍니다.
- CLI는 테스트 결과를 결정론적으로 검증합니다.
AI와 스크립트만으로 충분할 때
항상 별도의 검증 레이어가 필요한 것은 아닙니다. 다음 상황에서는 에이전트와 curl 호출만으로도 충분할 수 있습니다.
- 일회용 스크립트를 테스트하고 있으며, 한 번의 요청으로 필요한 정보를 얻을 수 있을 때
- 혼자 프로토타입을 만들고 있고, 대상이 두세 개 엔드포인트에 불과할 때
- 다른 팀이나 소비자가 해당 계약에 의존하지 않을 때
- 배포 결과가 다른 사람의 코드 또는 프로덕션 경로로 연결되지 않을 때
이런 경우에는 에이전트가 작성한 검사와 수동 확인만으로도 충분할 수 있습니다.
하지만 다음 조건이 생기면 결정론적인 검증 레이어가 필요합니다.
- 다른 사람에게 배포한다.
- CI에서 자동 검증한다.
- 다른 팀이 API 계약을 기반으로 개발한다.
- 잘못된 응답이 비용, 장애 또는 고객 영향으로 이어진다.
대부분의 프로덕션 API 작업은 이 범주에 속합니다.
자주 묻는 질문
AI가 API 테스트를 완전히 대체할 수 있나요?
아니요. 에이전트는 테스트 초안 작성, 엣지 케이스 제안, 요청 본문 생성에 강합니다. 하지만 모든 커밋에서 동일한 방식으로 스위트를 실행하고, 결과에 따라 병합을 게이트하며, 계약이 올바른지 결정하는 일에는 결정론적인 도구와 사람이 필요합니다.
오늘날 AI 에이전트가 API 테스트에서 잘하는 것은 무엇인가요?
다음 네 가지입니다.
- 사양에서 첫 테스트 스위트 초안 작성
- 사람이 놓칠 수 있는 엣지 케이스 제안
- 유효한 요청 본문과 픽스처 생성
- 검토할 수 있는 초안 어설션 작성
모두 테스트를 작성하는 작업입니다.
왜 에이전트가 CI 게이트가 될 수 없나요?
CI 게이트는 같은 입력에 대해 같은 결과를 반환해야 합니다. LLM은 출력을 샘플링하므로 실행마다 응답과 판단이 달라질 수 있습니다. 병합 규칙은 자연어 요약이 아니라 결정론적인 러너가 반환하는 실제 종료 코드를 사용해야 합니다.
이 글은 AI 에이전트로 API 테스트를 만드는 방법을 다루나요?
아니요. 사용법 안내는 에이전트에서 테스트를 얻는 단계를 설명합니다. 이 글은 AI가 API 테스트 작업을 어디까지 대체할 수 있는지, 그리고 그 경계가 어디에 있는지를 다룹니다.
Apidog AI 에이전트 디버거가 에이전트를 실행하나요?
아니요. 에이전트 실행을 검사합니다. LLM 호출, MCP 도구 호출, 다중 턴 교환을 확인해 API 레이어에서 어떤 일이 발생했는지 디버깅할 수 있습니다. 에이전트 런타임이 아니라 검사 표면입니다.
CI에서 테스트를 실행하려면 로그인해야 하나요?
아니요. Apidog CLI는 계정 없이 저장된 테스트 케이스를 헤드리스 방식으로 실행하고, 실제 종료 코드를 반환하며, 손상된 계약에 대해 빌드를 실패시킬 수 있습니다.
진정한 경계
“AI가 API 테스트를 대체할 수 있는가?”는 실제로 두 개의 질문입니다.
AI가 테스트를 작성할 수 있는가?
점점 더 그렇습니다.AI가 매번 같은 방식으로 테스트를 실행하고, 병합을 게이트하며, 계약을 유지할 수 있는가?
아니요. 그리고 그 역할은 의도적으로 결정론적인 도구가 맡아야 합니다.
실무에서는 둘 다 사용하세요.
- 에이전트에게 테스트 스위트 초안 작성, 엣지 케이스 제안, 요청 본문 생성을 맡기세요.
- 결정론적인 도구에게 테스트 실행, 계약 어설션, 실패한 호출의 재현을 맡기세요.
- 사람이 제품 계약의 최종 기준을 결정하세요.
npx apidog-mcp-server와 Apidog CLI로 시작하거나, Apidog를 무료로 사용해 보세요.
Top comments (0)