에이전트 데모와 프로덕션 에이전트를 구분하는 세 가지 체크
Source: Dev.to
에이전트 데모를 배포하는 데는 오후만 하면 된다. 하지만 프로덕션에서 한 분기 동안 살아남는 에이전트를 배포하는 일은 전혀 다른 작업이며, 그 차이는 거의 모델 때문이 아니다. 보통 빠진 세 가지 지루한 요소가 있다.
나는 MIT 라이선스로 공개된 Agentic Product Standard 를 유지하고 있으며, v2.0은 그 세 가지를 조언이 아니라 실행 가능한 코드로 바꾸는 데 초점을 맞췄다. 실제 코드를 포함해 소개한다.
보안은 구조적인 것이지 필터가 아니다
가장 흔한 실수는 안전성을 가드레일, 즉 가장자리에서 동작하는 입출력 필터로 생각하는 것이다. 필터에는 한계가 있다. 최고의 콘텐츠 분류기는 약 97% 정확도를 보이는데, 이는 설계상 약 3%의 프롬프트 인젝션 시도가 통과한다는 뜻이다. 이는 조정해서 없앨 수 있는 버그가 아니라 필터링 자체의 본질이다.
진정한 안전은 아키텍처에서 나온다. 내가 가장 먼저 확인하는 체크리스트는 Simon Willison이 제시한 치명적인 삼중고이다: 에이전트가 다음 세 가지를 모두 갖추면 즉시 데이터 탈취 도구가 된다.
- 개인 데이터에 대한 접근,
- 신뢰할 수 없는 콘텐츠에 대한 노출,
- 외부와 통신할 수 있는 능력.
하나만 갖추어도 괜찮다. 세 가지가 모두 갖춰지면, 검색된 문서에 숨겨진 페이로드를 위한 데이터 탈취 채널이 완성된다. 해결책은 “더 나은 필터”가 아니라 다리를 끊는 것이다: 외부 통신 차단, 신뢰할 수 없는 입력 격리, 혹은 데이터 범위 제한 중 하나를 적용한다.
아래는 CI 단계에서 적용할 수 있는 게이트 예시다. 에이전트가 접근할 수 있는 항목을 선언하고, 삼중고가 완화되지 않으면 빌드가 실패한다.
// agent-capabilities.json
{
"name": "support-agent",
"private_data": true,
"untrusted_content": true,
"external_comms": true,
"mitigations": [
{
"leg": "external_comms",
"control": "egress allow-list + approval"
}
]
}LEGS = ("private_data", "untrusted_content", "external_comms")
def evaluate(spec):
present = [l for l in LEGS if spec.get(l) is True]
if len(present) < 2:
return True # 안전
# 삼중고가 모두 존재하면 빌드 실패
raise RuntimeError("Triple threat detected")# CI 스크립트 예시
if ! python -c "import json, sys; evaluate(json.load(open('agent-capabilities.json')))" ; then
echo "::error::Triple threat detected – build aborted"
exit 1
fi비용은 대시보드가 아니라 서킷 브레이커다
에이전트는 토큰을 채팅보다 훨씬 빠르게 소모한다 — Anthropic에 따르면 멀티에이전트 시스템은 한 번의 채팅 인터랙션당 약 15배의 토큰을 사용한다. 대부분의 공개 멀티에이전트 아키텍처는 비용 상한을 두지 않아, 비용이 무제한으로 폭증할 위험이 있다.
v2.0은 비용을 강제 제어 로 만든다:
- 실행당 토큰/비용 상한을 코드에 직접 구현(각 모델 호출 전 체크하는 서킷 브레이커)
- 안정적인 프리픽스(시스템 프롬프트, 툴 스키마)에 대한 프롬프트/KV 캐싱
- 모델 라우팅 — 분류는 작은 모델, 추론은 고성능 모델 사용
- 경제적 규칙: 멀티에이전트가 15배 비용을 초과하는 경우, 작업 가치가 그 비용을 정당화할 때만 사용
즉, “비용”이 코드에서 강제되고 트레이스에 작업당 기록될 때 더 이상 놀라움이 아니다.
스스로 만든 스캐폴딩을 삭제하라
가장 많이 생각하는 부분이다. 모델의 약점을 보완하기 위해 만든 규칙은 그 약점이 사라지는 순간 죽은 무게가 된다. 게다가 모델의 주의를 분산시켜 아직 유효한 규칙까지 약화시킨다.
그래서 표준에는 유지보수 원칙(Daniel Miessler의 PAI에서 영감을 얻음)을 추가했다. 모든 규칙을 주기적으로 다음 질문 하나로 감사한다.
더 똑똑한 모델이라면 이 규칙이 필요 없을까?
예, 라면 그 규칙은 스캐폴딩이며 아키텍처가 아니다 — 삭제한다. 규칙을 안티프래질(평가 세트, 검증 하니스, 툴 계약, 실제 실패 포인트 등)과 프래질(체인‑오브‑쓰 thought 오케스트레이터, 출력 파서, 재시도 체인 등)로 태깅한다. 프래질한 규칙은 삭제하거나 다음 모델 업그레이드 시 재검증한다. 계속해서 성장만 하는 표준은 결국 부패한다.
검증 가능하게 만들기
원칙은 동의하기는 쉽지만 감사하기는 불가능하다. 그래서 v2.0은 자체 평가 점수표를 제공한다 — 이진 Yes/No 성숙도 체크리스트( M0 Prototype → M1 Shippable → M2 Production → M3 Autonomous‑ready )를 자율성 단계와 매핑한다. 현재 레벨은 모든 게이트를 통과한 가장 높은 밴드이며, 첫 번째 “No”가 다음 과제가 된다. “프로덕션 준비가 되었는가?”는 느낌이 아니라 체크리스트가 된다.
함께 제공되는 내용:
- 위에서 소개한 레드팀 키트
- 평가 통과율이 떨어지면 머지를 차단하는 CI 워크플로 템플릿
- 2026년 최신화 (MCP + OAuth 2.1, Linux Foundation의 A2A, OpenTelemetry GenAI 트레이싱, trajectory + pass^k 평가 메트릭)
모든 것을 관통하는 한 가지 규칙
모델은 변수이고, 하니스는 상수다. 비례적으로 투자하라.
…그리고 v2.0의 트위스트: 하니스는 영원히 쌓아두는 것이 아니다. 큐레이션한다 — 복합 효과를 내는 부분은 성장시키고, 약한 모델을 겨우 버티게 만든 부분은 삭제한다.
이 표준은 MIT 라이선스이며 벤더 중립적이다(프레임워크가 아니라 의도적으로 설계). 선택적으로 Claude Code 스킬셋을 포함한다. 나는 별점을 모으기보다 무엇이 잘못됐는지 알려주는 것이 더 좋다 — 아직 확신이 서지 않는 부분은 보류 리스트에 남겨두었다.
Repo: https://github.com/Moai-Team-LLC/agentic-product-standard