새벽 3시, 에이전트가 지원 티켓 큐를 처리합니다. 에스컬레이션처럼 보이는 티켓을 발견한 에이전트는 요약을 작성해 상사에게 이메일을 보냅니다. 요약은 정확하고 문법도 깔끔합니다. 하지만 아무도 이메일 발송을 요청하거나 검토하지 않았고, 에이전트가 보내기로 결정한 순간 이를 막을 장치도 없었습니다. 에이전트는 허용된 지시에 따라 정확히 행동했을 뿐입니다. 바로 이 지점이 위험합니다.
가장 큰 피해를 만드는 실패는 모델의 환각이나 프로세스 충돌만이 아닙니다. 그런 실패는 눈에 띄고, 눈에 띄는 실패는 포착됩니다. 더 위험한 실패는 조용합니다. 에이전트가 지시대로 정확히 행동했지만 결과는 나쁜 경우입니다. 이메일을 보내고, 데이터를 삭제하고, 주문을 실행하는 사이에 모델의 결정과 실제 행동을 분리하는 계층이 없기 때문입니다.
그 계층이 바로 가드레일입니다. 가드레일은 행동이 발생하기 전에 요청을 검사하고, 허용·차단·사람에게 승인 요청 중 하나를 결정합니다. 이 글에서는 다음 네 가지를 구현하는 방법을 다룹니다.
- 액션 허용 목록
- 승인 게이트
- 드라이런 모드
- 폭발 반경 제한
그리고 대부분의 팀이 건너뛰는 단계인 가드레일이 실제로 동작함을 테스트로 증명하는 방법도 설명합니다. 더 넓은 실패 모델은 AI 에이전트가 프로덕션에서 실패하는 이유에서 확인할 수 있습니다.
행동을 피해 정도에 따라 분류하기
모든 행동에 사람의 승인이 필요한 것은 아닙니다. 달력 조회, 예측 조회, 읽기 전용 보고서 검색처럼 되돌릴 수 있는 작업은 자동 실행되어야 합니다.
이런 작업까지 매번 승인받게 만들면 팀은 무의식적으로 “승인”만 누르게 됩니다. 그러면 실제로 위험한 요청이 도착했을 때 승인 절차가 무의미해집니다.
첫 번째 가드레일은 에이전트가 수행할 수 있는 도구 호출을 두 목록으로 나누는 것입니다.
| 분류 | 예시 | 처리 방식 |
|---|---|---|
| 허용 목록 | 읽기, 검색, 멱등성 조회, 되돌릴 수 있는 변경 | 자동 실행 |
| 게이트 대상 | 전송, 삭제, 결제, 레코드 생성·수정, 외부 사용자에게 노출되는 작업 | 사람 승인 필요 |
분류할 때 HTTP 메서드만 보지 마세요. 결과를 기준으로 판단해야 합니다.
- 초안만 생성하는
POST는 되돌릴 수 있습니다. - 이메일을 생성하고 즉시 발송하는
POST는 되돌릴 수 없습니다. -
DELETE라도 테스트 리소스만 삭제한다면 위험도는 낮을 수 있습니다. -
PATCH라도 고객의 청구 정보를 바꾼다면 위험도가 높습니다.
실무에서 유용한 기준은 다음 질문입니다.
에이전트가 실수로 이 행동을 100번 반복한다면, 피해가 얼마나 큰가?
답이 “별일 아니다”가 아니라면 허용 목록에 넣지 마세요.
다음처럼 도구 단위로 정책을 명시할 수 있습니다.
const actionPolicy = {
allow: [
"get_ticket",
"search_knowledge_base",
"list_calendar_events",
"create_email_draft",
],
requireApproval: [
"send_email",
"delete_record",
"create_order",
"refund_payment",
"update_customer_profile",
],
};
핵심은 모델 프롬프트에 “조심해서 행동하라”고 쓰는 것이 아닙니다. 실행 계층에서 어떤 도구 호출이 자동 실행 가능한지 강제하는 것입니다.
파괴적인 행동에 인간 개입 추가
위험한 행동을 분류했다면, 다음 단계는 승인 게이트입니다.
에이전트는 위험한 도구를 호출하기 전에 멈춰야 합니다. 그리고 다음 정보를 사람에게 보여준 뒤 승인을 기다려야 합니다.
- 실행하려는 작업
- 대상 리소스
- 실제 요청 페이로드
- 작업 이유
- 예상 결과
“에이전트가 이메일을 보내려고 합니다”는 충분하지 않습니다. 검토자는 실제 수신자, 제목, 본문을 봐야 합니다.
{
"action": "send_email",
"reason": "고객 티켓이 긴급 에스컬레이션으로 분류됨",
"payload": {
"to": ["manager@example.com"],
"subject": "[긴급] 결제 장애 티켓 요약",
"body": "..."
}
}
승인 게이트는 다음 흐름으로 구현할 수 있습니다.
async function executeAction(action: AgentAction) {
if (actionPolicy.allow.includes(action.name)) {
return runTool(action);
}
if (actionPolicy.requireApproval.includes(action.name)) {
const approval = await requestHumanApproval({
action: action.name,
reason: action.reason,
payload: action.payload,
});
await auditLog({
action,
decision: approval.approved ? "approved" : "rejected",
reviewer: approval.reviewer,
});
if (!approval.approved) {
return { status: "blocked", reason: "human_rejected" };
}
return runTool(action);
}
return { status: "blocked", reason: "action_not_allowlisted" };
}
좋은 승인 게이트의 조건은 세 가지입니다.
실제 페이로드를 보여준다
모델이 생성한 요약만 보여주지 말고, 실제 API 요청 내용을 보여주세요.거부가 쉽다
거부가 느리거나 불명확하면 검토자는 반사적으로 승인하게 됩니다.모든 결정을 기록한다
승인·거부·타임아웃·수정 요청을 모두 로그로 남겨야 합니다.
Anthropic SDK 커뮤니티에서도 에이전트가 행동하기 전 사람 승인 단계를 추가하는 방법이 반복적으로 논의됩니다. 공통된 결론은 간단합니다. 검토자가 구체적인 페이로드를 보지 못하면 실제 의사결정을 할 수 없습니다.
에이전트에 드라이런 모드 제공
승인 게이트는 프로덕션을 보호합니다. 드라이런은 프로덕션에 배포하기 전의 신뢰를 보호합니다.
드라이런 모드에서 에이전트는 일반 실행과 동일하게 동작합니다.
- 도구를 선택합니다.
- 인수를 생성합니다.
- API 요청을 구성합니다.
- 실행 직전 멈춥니다.
- 실제 요청 대신 “실행 예정 요청”을 반환합니다.
type ExecutionMode = "live" | "dry-run";
async function runTool(action: AgentAction, mode: ExecutionMode) {
const request = buildApiRequest(action);
if (mode === "dry-run") {
return {
status: "simulated",
tool: action.name,
request,
};
}
return httpClient.request(request);
}
드라이런은 두 가지 목적에 유용합니다.
1. 실제 입력으로 에이전트의 전체 경로 확인
새 티켓 유형이나 새로운 업무 흐름을 도입할 때, 실제 부작용 없이 에이전트의 선택을 확인할 수 있습니다.
2. 에이전트의 의도 검토
드라이런 결과에는 에이전트가 호출하려 했던 도구와 인수가 순서대로 포함되어야 합니다.
{
"status": "simulated",
"steps": [
{
"tool": "get_ticket",
"arguments": { "ticketId": "T-1234" }
},
{
"tool": "send_email",
"arguments": {
"to": ["manager@example.com"],
"subject": "긴급 티켓 요약"
}
}
]
}
이 결과를 실행 계획처럼 읽을 수 있어야 합니다. 계획이 잘못됐다면 실제로 피해를 만들기 전에 문제를 찾은 것입니다.
AI 에이전트 디버거를 사용하면 “에이전트가 이상한 일을 했다”는 모호한 문제를 “4단계에서 삭제 엔드포인트를 호출하려 했다”는 구체적인 정보로 바꿀 수 있습니다.
드라이런과 승인 게이트는 대체 관계가 아닙니다.
- 드라이런: 개발·테스트·스테이징 환경에서 실행
- 승인 게이트: 실제 부작용이 가능한 프로덕션 환경에서 실행
둘 다 필요합니다.
폭발 반경 제한
허용 목록, 승인 게이트, 드라이런은 단일 행동의 실행 여부를 결정합니다. 폭발 반경 제한은 에이전트가 여러 행동에 걸쳐 만들 수 있는 총 피해의 상한선을 정합니다.
승인된 행동이라도 무제한으로 반복되면 위험합니다.
1. 범위 제한
에이전트에는 필요한 리소스만 접근할 수 있는 자격 증명을 부여하세요.
예를 들어 한 프로젝트의 이슈만 관리하는 에이전트라면, 조직 전체 관리자 키가 아니라 해당 프로젝트로 제한된 토큰을 사용해야 합니다.
permissions:
project: alpha
allowed_actions:
- issues:read
- issues:write
denied_actions:
- organization:admin
- billing:write
2. 호출 할당량
고정 루프나 잘못된 재시도로 인해 수천 개의 이메일이나 요청이 발생하지 않도록 작업별 호출 수를 제한합니다.
const limits = {
maxToolCallsPerRun: 20,
maxSendEmailPerRun: 2,
maxDeletePerRun: 1,
};
3. 지출 한도
토큰, 결제 API, 외부 서비스 호출처럼 비용이 발생하는 작업에는 작업별·일별 상한선을 둡니다.
const budget = {
maxTokensPerRun: 100_000,
maxApiCostPerRunUsd: 5,
maxDailyApiCostUsd: 50,
};
이 제한은 더 세밀한 가드레일이 놓친 문제를 막는 최후의 안전망입니다. 게이트를 통과한 에이전트라도 권한 범위, 호출 횟수, 비용 한도를 초과해서는 안 됩니다.
제한을 운영하려면 다음 지표를 추적하세요.
- 액션별 호출 수
- 작업별 비용
- 승인·거부 비율
- 제한 근처에서 발생하는 오류율
- 사용자 또는 프로젝트별 도구 호출량
이는 일반 프로덕션 서비스에서 API 관찰 가능성을 운영하는 방식과 같습니다.
OWASP는 이 위험을 “과도한 에이전시”로 명시합니다. OWASP Top 10 for LLM Applications의 핵심 메시지 중 하나는 에이전트에게 필요한 수준 이상의 권한을 부여하지 말아야 한다는 것입니다.
가드레일을 테스트하는 방법
불편한 사실이 하나 있습니다. 가드레일은 위험한 행동이 발생하려 할 때만 실행되는 코드 분기입니다. 즉, 전체 시스템에서 가장 적게 실행되는 경로일 가능성이 높습니다.
가드레일이 트리거되지 않는 것과, 트리거되지만 무시되는 것은 운영 화면에서 비슷하게 보일 수 있습니다. 테스트하지 않은 가드레일은 없는 가드레일과 같습니다.
실제 API를 호출해 가드레일을 테스트하면 안 됩니다. 이메일 발송을 막는지 확인하려고 실제 이메일을 보내거나, 삭제를 막는지 확인하려고 실제 데이터를 삭제할 수는 없습니다.
대신 부작용을 일으키는 엔드포인트를 모의하고, 에이전트가 어떤 경로를 선택했는지 검증해야 합니다.
테스트 절차
파괴적 엔드포인트를 모의합니다
이메일 전송, 삭제, 결제 API가 실제 서비스에 도달하지 않도록 모의 서버를 구성합니다.위험한 시나리오로 에이전트를 실행합니다
에스컬레이션 티켓, 삭제 요청, 고가치 주문처럼 게이트가 반드시 작동해야 하는 입력을 사용합니다.결과가 아니라 경로를 검증합니다
실제 실행이 일어나지 않았는지와 승인 요청이 생성됐는지를 확인합니다.안전한 경로도 검증합니다
읽기 전용 작업은 불필요한 승인 없이 통과해야 합니다.
예를 들어 다음과 같은 테스트를 작성할 수 있습니다.
it("이메일 발송 전 승인 요청을 생성한다", async () => {
const sendEmailMock = mockApi.post("/emails/send");
const agent = createAgent({
mode: "live",
requireApprovalFor: ["send_email"],
});
const result = await agent.run({
ticket: {
priority: "high",
requiresEscalation: true,
},
});
expect(sendEmailMock.calls).toHaveLength(0);
expect(result.status).toBe("approval_required");
expect(result.approvalRequest.action).toBe("send_email");
expect(result.approvalRequest.payload.to).toEqual([
"manager@example.com",
]);
});
반대로 안전한 행동은 자동으로 실행되어야 합니다.
it("읽기 전용 티켓 조회는 승인 없이 실행한다", async () => {
const getTicketMock = mockApi.get("/tickets/T-1234");
getTicketMock.reply(200, { id: "T-1234", status: "open" });
const result = await agent.run({
action: "get_ticket",
ticketId: "T-1234",
});
expect(result.status).toBe("completed");
expect(getTicketMock.calls).toHaveLength(1);
});
합격 조건은 “에이전트가 요청을 보냈다”가 아닙니다.
위험한 행동에 대한 합격 조건은 다음과 같아야 합니다.
- 실제 부작용 엔드포인트가 호출되지 않았다.
- 승인 요청이 생성됐다.
- 승인 요청에 올바른 페이로드가 포함됐다.
- 거부 시 실행이 중단됐다.
- 승인 후에만 실제 요청이 실행됐다.
API를 호출하는 AI 에이전트를 테스트하는 방법에서는 이러한 테스트 구성을 더 자세히 다룹니다. 또한 AI 에이전트 및 API 테스트에서는 비결정적인 모델 출력에서도 유지되는 어설션 패턴을 확인할 수 있습니다.
Apidog가 적합한 곳과 적합하지 않은 곳
도구의 역할을 정확히 구분해야 합니다.
Apidog는 다음이 아닙니다.
- 에이전트 프레임워크
- 모델 호스팅 서비스
- 가드레일 라이브러리
- 에이전트 평가 플랫폼
Apidog는 에이전트를 구축하거나 실행하지 않으며, 어떤 행동이 안전한지도 결정하지 않습니다. 허용 목록, 승인 게이트, 드라이런 스위치, 권한 및 비용 제한은 애플리케이션 코드와 오케스트레이션 계층에서 관리해야 합니다.
Apidog가 담당하는 영역은 가드레일이 보호하는 API 계층을 테스트하는 것입니다.
다음과 같은 작업에 사용할 수 있습니다.
- 이메일 발송·삭제·결제 같은 부작용 API 모의
- 정상 응답뿐 아니라 오류 응답과 지연 응답 구성
- 에이전트가 보낸 실제 요청 페이로드 확인
- 위험한 작업이 승인 경로로 이동했는지 검증
- 라이브 API가 호출되지 않았는지 확인
즉, Apidog는 에이전트가 호출하는 API를 테스트하고, 파괴적 API를 모의해 에이전트가 올바른 승인 경로를 따르는지 증명하는 데 적합합니다.
자주 묻는 질문
허용 목록과 승인 게이트의 차이점은 무엇인가요?
허용 목록은 사람의 개입 없이 자동 실행할 수 있는 행동을 정의합니다. 승인 게이트는 허용 목록에 없는 행동이 도달하는 일시 정지 지점입니다.
- 허용 목록: 분류
- 승인 게이트: 중단 및 검토
가드레일이 에이전트 속도를 너무 많이 늦추나요?
되돌릴 수 있는 읽기 작업까지 게이트 처리할 때만 그렇습니다. 읽기와 검색은 허용 목록에 두고, 비용이 크거나 되돌리기 어려운 작업에만 승인 게이트를 적용하세요.
잘 분류된 허용 목록이 있다면 대부분의 실행 단계는 멈추지 않습니다.
실제 API를 호출하지 않고 가드레일을 테스트할 수 있나요?
네. 반드시 그렇게 해야 합니다.
부작용 API를 모의하고, 위험한 시나리오로 에이전트를 실행한 뒤, 모의 엔드포인트가 호출되지 않았는지와 승인 경로가 실행됐는지를 검증하세요.
무엇을 가장 먼저 게이트 뒤에 두어야 하나요?
되돌리기 가장 어려운 행동부터 시작하세요.
- 결제
- 삭제
- 고객 또는 동료에게 전달되는 메시지
- 권한 변경
- 외부 시스템의 상태를 바꾸는 작업
실수로 반복되었을 때 실제 피해를 만들 수 있다면, 허용 목록이 아니라 승인 게이트 뒤에 있어야 합니다.
가장 파괴적인 행동부터 시작하세요
첫날부터 네 가지 가드레일을 모두 구현할 필요는 없습니다.
먼저 사고 보고서에서 가장 설명하기 싫은 단일 행동을 선택하세요. 예를 들면 고객 이메일 발송, 데이터 삭제, 주문 생성, 환불 처리 같은 작업입니다.
그다음 이번 주에 다음을 완료하세요.
- 해당 작업을 허용 목록에서 제외합니다.
- 승인 게이트를 추가합니다.
- 실제 엔드포인트를 모의합니다.
- 위험한 입력으로 에이전트를 실행합니다.
- 실제 행동 대신 승인 요청이 생성되는지 테스트합니다.
가드레일이 처음 고장났을 때 테스트가 실패하는 것을 확인하면, 가드레일을 막연한 기대가 아니라 검증된 보호 장치로 신뢰할 수 있습니다.
Apidog 다운로드를 통해 파괴적인 엔드포인트를 모의하고, 응답을 프로그래밍하고, 에이전트가 실제 실행 경로 대신 승인 경로를 따르는지 검증하세요.
Top comments (0)