Blog

데이터 손실 없이 API 호출 AI 에이전트 테스트하는 방법

Ashley Innocent

Ashley Innocent

6 May 2026

데이터 손실 없이 API 호출 AI 에이전트 테스트하는 방법

Apidog 엔터프라이즈

온프레미스 배포

SSO & RBAC

SOC 2 준수

Apidog Enterprise 살펴보기

AI 코딩 에이전트가 스크립트를 실행하고 성공하는 것을 지켜본 후, 프로덕션 데이터베이스 테이블이 사라지는 것을 보았습니다. Hacker News의 사후 분석 글은 "AI가 당신의 데이터베이스를 삭제한 것이 아니라, 당신이 한 일이다."라는 날카로운 제목으로 빠르게 퍼져나갔습니다. 이 주장은 사실이었기 때문에 설득력이 있었습니다. 에이전트는 도구 정의를 따랐고, 그 도구는 실제 엔드포인트에 도달했으며, 엔드포인트에는 안전장치가 없었고, 사람은 DELETE FROM users가 의심스러워 보이는지 묻기 위해 멈추지 않는 프로세스에 접근 권한을 넘겨주었습니다. 별도의 r/ClaudeAI 스레드에서는 다른 관점에서 비슷한 이야기를 전했습니다. 빌링 루프에 빠진 에이전트가 아무도 알아차리기 전에 수백 달러 상당의 토큰을 소모했습니다. 표면은 다르지만, 동일한 실패 유형이었습니다. 문제는 모델이 어리석다는 것이 아닙니다. 문제는 아무도 API를 테스트하지 않았다는 것입니다.

💡
여러분의 API를 호출하는 자율 에이전트를 출시할 예정이라면, 이 가이드가 여러분을 위한 것입니다. 이 가이드에서는 에이전트 개발 중 외부 엔드포인트를 모의(mock)하는 방법, 파괴적인 작업을 샌드박스에서 실행하는 방법, 도구 스키마에 대한 계약 테스트를 작성하는 방법, 에이전트별 예산 상한을 설정하는 방법, 그리고 프로덕션에 배포하기 전에 실패 모드를 연습하는 방법을 배우게 될 것입니다. 저희는 Apidog를 테스트 스캐폴딩으로 사용할 것입니다. Apidog는 OpenAPI를 기본적으로 지원하고, 글루 코드(glue code) 작성 없이 모의 서버를 실행하며, 에이전트 도구 호출 시퀀스와 깔끔하게 연결되는 시나리오 테스트를 제공하기 때문입니다.

버튼

요약

에이전트의 도구에 API 측 안전장치(예: 누락된 비율 제한, 비멱등성, 핫 삭제, 손상된 스키마)가 없을 때 프로덕션에서 에이전트가 실패합니다. 이를 해결하려면 네 가지 조치를 취해야 합니다: 에이전트의 도구 정의를 OpenAPI 사양에 대해 계약 테스트하고, 파괴적인 엔드포인트에 대한 모의 서버를 실행하고, 에이전트별 예산 및 멱등성 키를 강제하고, CI에서 실패 시나리오를 다시 재생합니다. Apidog는 이 모든 것을 하나의 프로젝트에서 수행할 수 있도록 OpenAPI 가져오기, 모의 서버, 시나리오 러너를 제공합니다.

서론

1년 전에는 "AI 에이전트 테스트"가 Claude나 GPT에 프롬프트를 입력하고 답변을 평가하는 것을 의미했습니다. 더 이상 그렇지 않습니다. 오늘날의 에이전트는 함수를 호출하고, 그 함수는 여러분의 API에 연결되며, 여러분의 API는 실제 데이터베이스, 결제 처리기 및 서드파티 서비스와 통신합니다. 잘못된 도구 정의나 누락된 비율 제한은 스타일의 문제가 아닙니다. 이는 여러분의 이름이 새겨진 프로덕션 사고입니다.

이번 달에 퍼진 Hacker News 이야기는 이러한 변화를 잘 보여주었습니다. 작가는 AI가 데이터베이스를 삭제한 것이 아니라, 모델과 데이터 사이에 어떤 통제 장치도 두지 않고 에이전트에게 쓰기 권한을 부여한 사람이 한 일이라고 주장했습니다. 이 스레드는 모든 개발자가 "나도 저런 실수를 할 뻔했다"고 생각했기 때문에 큰 반향을 일으켰습니다. 몇 주 전, 한 Reddit 게시물은 에이전트가 실패한 호출을 너무 많이 재시도하여 아무도 알아차리기 전에 요금이 800유로를 넘어섰다는 빌링 루프에 대해 설명했습니다. 동일한 근본 원인: 잘못된 계층에 대한 신뢰였습니다.

이것을 고칠 수 있습니다. 모델 계층도 중요하지만, 출혈을 막는 곳은 API 계층입니다. 이 기사에서는 AI 에이전트 API 통합을 종단 간 테스트하는 방법을 보여줍니다. 모든 에이전트-API 설정에 필요한 네 가지 안전장치를 다루고, 파괴적인 엔드포인트를 모의(mocking)하기 위한 Apidog 워크플로를 단계별로 안내하며, 스키마 드리프트 감지 및 이중 키 분리와 같은 고급 기술로 마무리할 것입니다. 여러분은 오늘 여러분의 저장소에 복사할 수 있는 구체적인 패턴을 얻게 될 것입니다. 모의 서버 단계를 따라 하려면 시작하기 전에 Apidog를 다운로드하십시오.

에이전트 실패가 API 실패처럼 보이는 이유

충분한 에이전트 사후 분석을 읽어보면 패턴이 나타납니다. 주인공은 모델이 아니라 API라는 것입니다.

프롬프트 주입을 예로 들어봅시다. 사용자가 숨겨진 지침이 포함된 PDF를 업로드하면, 에이전트가 이를 읽고 다음 도구 호출이 delete_all=true와 함께 /admin/users 엔드포인트로 이동합니다. 모델은 이를 선택한 것이 아닙니다. 불신할 이유가 없는 지침을 따랐을 뿐입니다. 해결책은 프롬프트를 강화하는 것이 아닙니다. 해결책은 사용자 컨텍스트 세션에서 온 토큰에 delete_all=true를 노출하지 않는 API를 구축하는 것입니다. OWASP는 이를 LLM Top 10에서 LLM01이라고 부르며, 완화책은 프롬프트 엔지니어링이 아니라 API 측 권한 부여입니다.

오류가 있는 도구 스키마를 예로 들어봅시다. 여러분의 OpenAPI 사양은 amount가 센트 단위의 정수라고 말합니다. 에이전트의 도구 정의는 amount가 달러 단위의 부동 소수점 숫자라고 말합니다. 3개월 후, 누군가가 19센트 청구를 19달러로 환불했고, 여러분은 회계 부서에서 불일치 사실을 알게 됩니다. 모델은 틀리지 않았습니다. 모델은 여러분이 제공한 스키마를 사용했습니다. 스키마가 API와 일치하지 않게 된 것입니다. 아무도 계약을 테스트하지 않았습니다.

누락된 비율 제한을 예로 들어봅시다. 재시도 루프에 빠진 에이전트가 2분 만에 트랜잭션 이메일 엔드포인트를 수천 번 공격합니다. 이는 에이전트의 플래너가 해당 단계를 "아직 성공하지 못함"으로 계속 표시했기 때문입니다. 각 재시도는 비용이 듭니다. 각 재시도는 실제 이메일을 대기열에 추가합니다. 여러분이 잠에서 깼을 때, 여러분의 제공업체는 계정에 플래그를 지정했고 여러분의 고객들은 스팸을 받고 있습니다. 모델은 악의적이지 않았습니다. 모델은 제한이 없는 도구를 사용하고 있었습니다.

누락된 멱등성을 예로 들어봅시다. 에이전트가 고객에게 요금을 청구하기 위해 POST /payments를 호출하고, 네트워크 타임아웃이 발생하여 플래너가 호출 실패로 판단하고 재시도하며, 이제 고객은 두 번 요금이 청구됩니다. 에이전트 계층은 원래 호출이 성공했는지 알 수 없습니다. API가 이를 확인할 방법을 제공하지 않았기 때문입니다. 멱등성 키는 서버 코드 다섯 줄로 이 문제를 해결하지만, 여러분이 직접 작성해야 합니다.

공통점은 다음과 같습니다. 이 모든 사건에서 에이전트는 자신이 사용하는 도구가 지시하는 대로 정확히 수행하고 있다는 것입니다. 이 도구들이 바로 API입니다. 따라서 에이전트의 신뢰성이 무너지는 지점을 감사할 때, API 계약을 먼저 살펴보고, 에이전트 하네스를 두 번째로 보며, 모델 자체는 거의 살펴보지 마십시오. 이러한 재정의는 어디에 투자해야 하는지 알려주기 때문에 중요합니다. 더 똑똑한 모델이 필요한 것이 아닙니다. 안전장치가 켜진 테스트 가능한 API가 필요합니다.

모든 에이전트-API 통합에 필요한 네 가지 안전장치

네 가지 제어 장치가 안전하게 실패하는 에이전트 설정과 비용이 많이 드는 에이전트 설정을 구분합니다. 이번 분기에 하나만 추가할 시간이 있다면, 가장 위에 있는 것부터 시작하십시오. 네 가지 모두를 수행할 수 있다면, 2026년에 발생할 사고 시나리오의 90% 이상을 대비할 수 있습니다.

1. 도구 스키마 계약 테스트

여러분의 OpenAPI 사양은 API의 신뢰할 수 있는 소스입니다. 에이전트는 별도의 도구 정의를 가지고 있으며, 이는 종종 수동으로 작성되거나 문서에서 복사 붙여넣기 됩니다. 이 두 아티팩트는 지속적으로 불일치가 발생합니다. 계약 테스트는 이러한 불일치가 발생하는 즉시 CI 빌드를 실패시킵니다.

다음은 라이브 OpenAPI 사양에 대해 Claude 스타일 도구 정의를 검증하는 최소한의 Python 확인 코드입니다.

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Return a list of mismatch errors, empty list = pass."""
    errors = []
    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Tool missing required field: {missing}")
    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]
            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Type mismatch on {prop}: API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )
    return errors

OpenAPI 사양 또는 도구 정의에 영향을 주는 모든 PR에서 이 코드를 실행하십시오. 목록이 비어 있지 않으면 빌드를 실패시키십시오. 이 단일 검사는 이전 섹션에서 언급된 float 대 센트 버그를 어떤 환불이 나가기 몇 달 전에 발견했을 것입니다.

2. 파괴적인 엔드포인트에 대한 샌드박스 및 모의(mock) 환경

에이전트에게는 연습할 곳이 필요합니다. 절대 프로덕션에서 연습해서는 안 됩니다. 패턴은 간단합니다: 상태를 변경하는 모든 엔드포인트는 실제 작업을 수행하지 않고 동일한 형태의 응답을 반환하는 모의(mock) 등가물을 가집니다. 에이전트 개발 루프는 모의를 사용합니다. 스테이징 테스트는 샌드박스 데이터베이스를 사용합니다. 사람이 배포를 승인할 때까지 프로덕션은 건드리지 않습니다.

Apidog는 Faker 패턴에 의해 구동되는 현실적인 필드 값을 포함하여 OpenAPI 사양에서 직접 모의(mock)를 생성합니다. 에이전트의 기본 URL을 모의 서버로 지정하고, 프롬프트를 수백 번 반복 실행하여 에이전트의 동작을 관찰합니다. 에이전트가 문서를 잘못 이해하여 /users/{id}/delete로 계속 PUT 요청을 시도하더라도, 모의 서버가 이를 감지합니다. 프로덕션의 사용자 테이블에는 절대 실수가 발생하지 않습니다. 이 패턴이 속하는 더 넓은 개념은 계약 우선 개발(contract-first development)을 참조하십시오.

3. 되돌릴 수 없는 작업에 대한 멱등성 키 및 소프트 삭제

에이전트가 호출할 수 있는 모든 쓰기 엔드포인트는 멱등성 키를 허용해야 합니다. 모든 삭제는 기본적으로 소프트 삭제여야 하며, 사람이 승인하는 별도의 하드 삭제 경로가 있어야 합니다.

미들웨어는 Express에서 다음과 같습니다.

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers['idempotency-key'];
  if (!key) {
    return res.status(400).json({ error: 'Missing Idempotency-Key header' });
  }
  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }
  const originalJson = res.json.bind(res);
  res.json = function (body) {
    idempotencyCache.set(key, { status: res.statusCode, body });
    setTimeout(() => idempotencyCache.delete(key), 24 * 60 * 60 * 1000);
    return originalJson(body);
  };
  next();
}

app.post('/payments', idempotency, createPayment);

에이전트는 논리적 작업당 UUID를 생성하고 재시도 시 이를 재사용합니다. API는 두 번째 호출에서 두 번 청구하는 대신 캐시된 응답을 반환합니다. 이 동일한 패턴은 메시징 API의 이중 전송, CRM의 중복 행 생성, 그리고 대부분의 "에이전트가 재시도하여 문제가 발생했습니다" 시나리오를 방지합니다.

4. 에이전트별 예산 상한

모든 에이전트에게는 예산이 할당됩니다. 토큰 예산, 요청 예산, 금액 예산, 시간 예산. 예산이 소진되면 에이전트는 작동을 멈춥니다. 예외는 없습니다. 800유로 Reddit 사건은 아무도 폭주하는 루프에 상한선을 설정하지 않았기 때문에 발생했으며, 사람이 확인했을 때는 이미 피해가 발생한 후였습니다.

API 게이트웨이를 감싸는 예산 미들웨어는 다음을 추적할 수 있습니다.

어떤 상한선에 도달하면, 구조화된 Retry-After와 해당 상한선의 이름을 포함하는 X-Budget-Exceeded 헤더와 함께 HTTP 429를 반환하십시오. 그러면 에이전트의 플래너는 사람에게 에스컬레이션하거나 작업을 취소할 수 있습니다. 어떤 에이전트가 한계에 도달하고 있는지 확인하고 그에 따라 조정할 수 있도록 로깅과 함께 사용하십시오.

이 네 가지 제어는 상호 보완적입니다. 계약 테스트는 명백한 스키마 오류를 잡아냅니다. 모의 서버는 파괴적인 오류를 잡아냅니다. 멱등성은 재시도 폭주를 잡아냅니다. 예산은 폭주 루프를 잡아냅니다. 이들을 함께 사용하면 "에이전트가 끔찍한 일을 저질렀다"를 "에이전트가 429를 반환하고, 문제를 기록하고, 도움을 요청했다"로 바꿀 수 있습니다. 이것이 바로 기준입니다.

Apidog로 에이전트 API 호출 테스트

이제 실용적인 부분입니다. Apidog에서 완벽한 에이전트-API 테스트 워크플로를 설정하는 방법입니다. 에이전트가 호출하는 API의 OpenAPI 사양과 에이전트의 도구 정의 목록이 필요합니다.

Apidog 프로젝트 인터페이스 스크린샷

1단계: OpenAPI 사양 가져오기

Apidog를 열고 새 프로젝트를 생성한 다음, OpenAPI 3.x 파일을 가져오십시오. Apidog는 모든 경로, 스키마 및 예시를 구문 분석하여 프로젝트에 해당 엔드포인트를 생성합니다. 만약 API가 아직 OpenAPI로 문서화되지 않았다면, 지금이 바로 그 작업을 할 때입니다. 에이전트의 신뢰성은 사람과 AI 에이전트 모두가 읽는 단일 진실 소스(single source of truth)를 가지는 것에 달려 있기 때문입니다. 처음부터 시작하는 경우, 디자인 우선 API 워크플로 가이드(design-first API workflow guide)가 이 과정을 안내할 것입니다.

2단계: 파괴적인 엔드포인트에 대한 모의(mock) 응답 정의

데이터를 변경하는 모든 엔드포인트(POST, PUT, PATCH, DELETE)를 찾으십시오. 각 엔드포인트에 들어가서 모의(mock) 응답을 추가하십시오. Apidog는 스키마에서 현실적인 모의 응답을 자동 생성할 수 있지만, 프로덕션 데이터가 아닌 테스트 데이터처럼 보이도록 필드 값을 재정의해야 합니다. 로그에서 어떤 유출도 명확하게 드러나도록 mock_user_와 같은 접두사 및 1970년도 타임스탬프를 사용하십시오.

모의 서버를 시작하십시오. Apidog는 https://mock.apidog.com/m1/your-project-id/와 같은 안정적인 URL을 제공합니다. 개발 중에 에이전트의 API 기본 URL을 모의 서버로 지정하십시오. 이제 DELETE /users/{id}는 가짜 사용자 페이로드와 함께 200을 반환하며, 실제 데이터베이스는 안전합니다. 계약 우선 개발(contract-first development)을 참조하십시오.

3단계: 에이전트의 호출 시퀀스를 시뮬레이션하는 시나리오 작성

Apidog 시나리오를 사용하면 테스트 스위트와 동일하게 어설션을 사용하여 API 호출을 연결할 수 있습니다. 지원 티켓을 분류하는 에이전트의 경우, 시나리오는 다음과 같을 수 있습니다.

  1. 테스트 자격 증명으로 POST /auth/token 호출, 베어러 토큰 캡처
  2. 토큰으로 GET /tickets?status=open 호출, 첫 번째 티켓 ID 캡처
  3. 카테고리로 POST /tickets/{id}/triage 호출, 200을 어설션하고 할당된 필드 캡처
  4. 템플릿화된 메시지로 POST /notifications 호출, 메시지 본문이 정규식과 일치하는지 어설션

여러분은 실제로 모의 서버에서 각 홉에 대한 어설션과 함께 에이전트가 수행할 작업을 예행연습하는 것입니다. 만약 개발자가 티켓 스키마를 변경하고 정규식이 일치하지 않게 되면, 시나리오는 실패하고 에이전트가 프로덕션을 보기 전에 이를 알 수 있습니다. 더 넓은 시나리오 테스트 플레이북은 QA 엔지니어를 위한 API 테스트(API testing for QA engineers)를 참조하십시오.

4단계: CI에서 실행

Apidog는 GitHub Action, GitLab 파이프라인 또는 모든 CI 러너에서 시나리오를 실행하는 CLI를 제공합니다. 명령은 apidog run -t scenario-id --env test와 같습니다. OpenAPI 사양 또는 에이전트 도구 정의에 대한 모든 변경 사항이 전체 시나리오 재실행을 트리거하도록 PR 파이프라인에 연결하십시오.

5단계: 두 모델 버전 나란히 비교

한 모델에서 다른 모델로 업그레이드할지 여부를 평가할 때, 새 모델의 도구 호출이 동일한 시나리오에서 동일하게 작동하는지 알고 싶을 것입니다. 모델 A를 사용하여 동일한 Apidog 시나리오에 대해 에이전트를 실행하고, 트레이스를 캡처합니다. 모델 B를 사용하여 다시 실행하고, 트레이스를 캡처합니다. 요청 본문을 비교합니다. 예상치 못한 결과가 즉시 나타납니다. 모델 B가 다른 priority 값을 전달하거나, 필드를 누락하거나, 날짜에 다른 형식을 사용하는 등입니다. 배포 전에 행동 변화를 감지할 수 있습니다. 이는 GPT-5.5 API 통합에서 다루는 패턴 중 하나이며, 새로운 모델 동작을 평가하는 것이 반복적으로 필요한 경우입니다.

전체 워크플로는 처음 설정하는 데 약 한 시간이 걸리며, 그 후에는 실행당 몇 분밖에 걸리지 않습니다. 그 보상은 API 또는 에이전트 도구에 대한 모든 변경 사항이 동일한 기대치 기준에 따라 실행된다는 것입니다.

고급 기술 및 전문가 팁

기본 사항이 갖춰진 후 숙련된 팀이 사용하는 몇 가지 패턴입니다.

**피해야 할 일반적인 실수:**

에이전트가 단일 API 게이트웨이 뒤에 있지 않은 내부 서비스와 통신하는 경우, 마이크로서비스 테스트 패턴은 서비스 전반에 걸쳐 시나리오 테스트를 분산하는 방법을 다룹니다.

대안 및 도구

선택지가 있습니다. 다음은 네 가지 일반적인 접근 방식에 대한 공정한 비교입니다.

접근 방식 설정 시간 강점 약점 가장 적합한 경우
수작업 단위 테스트 낮음 완전한 제어, 공급업체 종속성 없음 높은 유지보수 비용, 실제 API와 쉽게 불일치 소규모 프로젝트, 단일 개발자 팀
LangSmith / LangGraph 평가 하네스 중간 내장된 트레이스 재생, 모델 인식 지표 에이전트 측에 비중, API 측에 경량 평가 중심 AI 팀
Postman + Postbot 중간 익숙한 UI, 방대한 템플릿 라이브러리 모의 서버는 유료 추가 기능, 시나리오 구문이 오래됨 이미 Postman에 투자한 팀
Apidog 시나리오 + 모의 중간 기본 OpenAPI, 무료 모의 서버, CI용 시나리오 CLI Postman보다 낮은 브랜드 인지도 디자인, 모의, 테스트를 위한 하나의 도구를 원하는 팀

솔직한 요약: LangSmith를 사용하고 있다면, 에이전트 측에서 작동하는 것을 계속하고 별도의 API 테스트 계층을 추가하십시오. Postman의 가격 정책이나 모의 모델이 더 이상 맞지 않는다면, Apidog는 강력한 대안입니다. 새롭게 시작한다면, 하나의 프로젝트에서 OpenAPI, 모의 서버 및 시나리오를 모두 처리하는 도구를 선택하십시오. 에이전트-API 테스트 시간의 80%가 바로 그곳에서 사용되기 때문입니다.

일부 팀은 이들을 함께 사용합니다. 프롬프트 수준 평가는 LangSmith를 사용하고, API 측 계약 테스트 및 시나리오 재실행에는 Apidog를 사용합니다. 이것은 잘 작동합니다. 도구들이 서로 다른 계층을 담당하기 때문입니다.

실제 사용 사례

결론

이 가이드에서 한 가지를 얻어가야 한다면, 이것을 기억하십시오. 문제는 에이전트가 아닙니다. API가 문제이거나, 아니면 API가 해결책입니다. 이는 여러분이 API를 테스트했는지 여부에 달려 있습니다.

다섯 가지 요점:

올해의 바이러스성 사건들이 마지막이 아닐 것입니다. 에이전트를 출시하는 모든 팀은 이러한 실패 모드 중 하나를 적어도 한 번은 겪게 될 것입니다. 빨리 복구하는 팀은 이미 안전장치를 마련해 둔 팀입니다. Apidog를 다운로드하고 모의 서버 단계부터 시작하십시오. 그것만으로도 이번 분기 밤샘을 면할 수 있을 것입니다. 이 문제에 대한 QA 팀의 관점은 QA 엔지니어를 위한 API 테스트 도구(API testing tools for QA engineers)를 참조하십시오. 에이전트가 안전하게 사용할 수 있는 도구 정의를 작성하는 더 넓은 맥락은 AGENTS.md 파일을 작성하는 방법(how to write AGENTS.md files)을 참조하십시오.

자주 묻는 질문

토큰 비용을 들이지 않고 AI 에이전트 API 호출을 테스트하려면 어떻게 해야 합니까?

개발 중에는 모의 서버에 대해 에이전트를 실행하십시오. Apidog의 모의 URL은 실제와 유사한 응답을 무료로 반환하므로, 테스트 루프가 실제 API 크레딧을 소모하지 않습니다. 온도를 0으로 고정하고 작은 고정 프롬프트 세트를 사용하십시오. 모의 서버 비용(0원)으로 수천 번의 테스트 반복을 실행할 수 있습니다. 전체 설정은 QA 엔지니어의 테스트 체크리스트(the QA engineer’s testing checklist)를 참조하십시오.

에이전트 테스트와 API 테스트의 차이점은 무엇입니까?

에이전트 테스트는 모델이 올바른 도구를 선택하고 인수를 올바르게 채우는지 확인합니다. API 테스트는 엔드포인트가 호출될 때 올바르게 작동하는지 확인합니다. 둘 다 중요합니다. 고장난 API를 호출하는 완벽한 에이전트는 여전히 고장난 결과를 생성하고, 완벽한 API를 호출하는 고장난 에이전트는 여전히 버그를 발생시킵니다. 두 계층 모두 별도로 테스트해야 합니다.

모든 엔드포인트에 멱등성 키가 필요합니까?

네, 모든 쓰기 엔드포인트에는 필요합니다. 읽기는 정의상 멱등적입니다. 쓰기는 그렇지 않으며, 에이전트는 재시도합니다. 멱등성 헤더를 지원하는 미들웨어 다섯 줄은 에이전트가 500 오류를 재시도할 때 중복 행이 생성되지 않는 첫 번째 순간에 그 가치를 입증할 것입니다.

프롬프트 주입이 잘못된 API 호출을 유발하는 것을 어떻게 방지합니까?

프롬프트 계층에만 의존하지 마십시오. API는 에이전트의 요청이 아닌 원래 사용자 컨텍스트를 기반으로 권한 부여를 강제해야 합니다. 사용자 컨텍스트 세션이 일반적으로 /admin/delete-all-users를 호출할 수 없다면, 프롬프트 내용에 관계없이 해당 사용자를 대신하는 에이전트도 그럴 수 없어야 합니다. OWASP의 LLM Top 10에서 이에 대해 자세히 다룹니다.

내 도구 계층을 작성하지 않고도 Claude 또는 GPT와 Apidog를 직접 사용할 수 있습니까?

테스트 중에 에이전트의 도구 정의를 Apidog 모의 URL로 지정하십시오. Claude와 GPT 모두 도구 정의에서 임의의 HTTP 기본 URL을 지원하므로, 환경 변수 하나만 변경하면 됩니다. 스테이징 또는 프로덕션에 대해 테스트할 준비가 되면 해당 변수를 변경하십시오.

에이전트의 적절한 예산 상한은 얼마입니까?

엄격하게 시작하고 데이터에 따라 완화하십시오. 세션당 50,000 토큰, 분당 30 API 호출, 작업당 5달러로 시작하십시오. 2주 동안 지표를 관찰하십시오. 합법적으로 도달하는 상한선을 높이고, 결코 도달하지 않는 상한선은 낮추십시오. 매달 검토하십시오. 목표는 고정된 숫자가 아닙니다. 폭주 루프를 잡을 만큼 충분히 엄격하고 실제 작업이 진행될 만큼 충분히 유연한 숫자여야 합니다.

에이전트 도구와 API 간의 스키마 드리프트를 어떻게 감지합니까?

모든 PR에서 CI에서 스키마 차이(diff)를 실행하십시오. 에이전트의 도구 정의(JSON 스키마)를 동일한 엔드포인트에 대한 OpenAPI 요청 본문 스키마와 비교하십시오. 불일치가 발생하면 빌드를 실패시키십시오. 위 안전장치 섹션의 30줄 Python 스니펫이 이 작업을 수행합니다. 이를 여러분의 저장소에 복사하여 GitHub Actions에 연결하십시오.

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드
데이터 손실 없이 API 호출 AI 에이전트 테스트하는 방법