프로덕션에서 에이전트를 성공적으로 운영하는 팀들은 데모에서 보여주는 에이전트를 실행하지 않습니다. 출시된 에이전트에 대한 첫 번째 대규모 연구에 따르면 68%는 사람이 개입하기 전에 최대 10단계만 실행하고, 70%는 가중치를 조정하는 대신 그냥 기성 모델을 프롬프트로 사용하며, 74%는 주로 인간 평가에 의존합니다 (Pan et al., arXiv:2512.04123). 제약이 곧 제품입니다.
이 격차는 중요합니다. 현재 57.3%의 팀이 에이전트를 프로덕션에서 운영 중이며, 품질이 33%로 최대 병목 요인입니다 (LangChain). 한편 89%가 옵저버빌리티를 갖추고 있지만 온라인 평가를 실행하는 팀은 37.3%에 불과합니다. 에이전트가 무엇을 하는지 볼 수는 있지만 그것이 맞는지는 알 수 없습니다.
이 열두 가지 교훈은 해당 연구, Microsoft의 레드팀 분류 체계, 그리고 이름이 공개된 사후 분석에서 나온 것입니다. 각각은 의도적으로 설정하는 한계입니다.
팀이 프로덕션에서 실행하는 것 (교훈 1–2)
프로덕션에서 살아남은 에이전트들은 런칭 데모의 자율적이고 스스로를 지시하는 시스템과 거의 닮지 않았습니다. 의도적으로 짧고, 감독받으며, 단순합니다.
교훈 1: 출시된 에이전트는 의도적으로 단기 지평선을 가집니다
배포된 에이전트에 대한 첫 번째 대규모 학술 연구인 MAP은 26개 도메인에 걸쳐 실제 시스템을 운영하는 86명의 실무자를 대상으로 조사하고 20개 팀을 심층 인터뷰했습니다. 그 결과 프로덕션 에이전트의 68%가 사람이 개입하기 전에 최대 10단계만 실행하고, 70%는 가중치를 조정하는 대신 기성 모델을 프롬프트로 사용하며, 74%는 주로 인간 평가에 의존한다는 사실이 밝혀졌습니다.
이 세 숫자를 함께 읽으면 그림이 분명해집니다. 6개월 동안 에이전트를 유지한 사람 중 파인튜닝된 모델과 자동 스코어카드를 갖춘 200단계 플래너를 실행하는 사람은 없습니다. 그들은 Claude나 GPT로 10단계 루프를 돌리며 결과를 읽는 사람을 두고 있습니다.
이것은 시간이 지나도 바뀌지 않는 설계 선택입니다. 단계 수는 무언가 고장날 때 팀이 줄이는 변수입니다. 단계가 하나씩 늘어날 때마다 잘못된 도구 호출, 오염된 컨텍스트, 또는 비용 충격의 가능성이 곱해지기 때문입니다. 단기 지평선은 팀이 출시 후 도달하는 곳입니다.
파일럿 단계를 넘어선 팀도 많습니다. LangChain의 AI 에이전트 현황 설문조사(2025년 11월 18일~12월 2일, 1,340명 응답)에 따르면 응답자의 57.3%가 에이전트를 프로덕션에서 운영 중이며, 직원 수 10,000명 이상 조직에서는 67%로 상승합니다. 동일 설문에서 품질 및 정확도가 33%로 최대 병목 요인이며, 지연 시간이 20%로 2위입니다. 비용은 전년 대비 순위가 하락했습니다.
즉, 더 이상 예산이 제약이 아닙니다. 두 번 연속으로 올바른 일을 하느냐가 문제입니다.
교훈 2: 안정성은 시스템 레이어에서 해결됩니다
MAP은 안정성, 즉 시간이 지나도 일관되게 올바른 동작을 유지하는 것을 프로덕션에서 에이전트를 운영하는 팀의 최대 개발 과제로 지목합니다. 더 중요한 것은 그 팀들이 이에 어떻게 대응하느냐입니다. 그들은 제약된 자율성과 결정론적 스캐폴딩에 의존합니다: 하드코딩된 단계 한도, 도구 허용 목록, 호출 사이의 검증, 돌이킬 수 없는 작업 전 사람의 승인 게이트.
이것은 아키텍처 결정이며, 모델이 교체되어도 유지됩니다.
이 점은 이후의 모든 교훈을 재구성합니다. 디렉토리의 550개 이상의 AI 에이전트를 둘러보면 마케팅 문구는 기능을 팝니다: 더 많은 도구, 더 긴 자율성, 더 풍부한 메모리. 프로덕션에서 이런 것들을 실제로 운영하는 팀들은 반대를 구매합니다. 다음 열 가지 교훈은 각각 누군가가 사고 후에 추가한 한계이며, 그 한계가 에이전트를 출시 상태로 유지합니다.
권한 범위 지정: 에이전트의 자격 증명이 도달할 수 있는 곳 (교훈 3–5)
이번 주에 출시할 수 있는 가장 저렴한 안정성 제어는 더 작은 토큰입니다. 에이전트가 인증하는 자격 증명에서 쓰기 범위를 제거하면 프로덕션 사고의 전체 범주가 발생 불가능해집니다.
이에 대한 벤치마크 수치가 있습니다. AgentDojo는 97개 작업과 629개 보안 테스트 케이스에 걸쳐 에이전트를 테스트했으며, 사용자의 작업이 읽기 접근만 필요할 때 쓰기 범위 도구를 거부하면 프롬프트 인젝션 공격 성공률이 7.5%로 떨어진다는 것을 발견했습니다 (AgentDojo, arXiv:2406.13352). 이 결과는 설정만으로 나온 것입니다. 작업에 필요 없는 기능을 넘겨주지 않으면 공격이 착지할 곳이 없습니다.
교훈 3: 폭발 반경은 자격 증명을 발급할 때 설정됩니다
2025년 7월 19일 Replit의 에이전트가 프로덕션 데이터베이스를 삭제했을 때, 실패의 원인은 에이전트가 지침을 잘못 읽은 것이 아니었습니다. 개발 모드 에이전트가 프로덕션 데이터에 접근할 수 있는 자격 증명을 보유하고 있었기 때문이었습니다. Amjad Masad의 말을 직접 인용하면: "용납할 수 없으며 절대 가능해서는 안 됩니다" (@amasad on X). Replit이 이후 공개한 개선 목록은 권한 감사처럼 읽히며, 자동 개발/프로덕션 데이터베이스 분리와 "코드베이스를 위험에 빠뜨리지 않고 전략을 짤 수 있는" 계획 전용 모드로 시작합니다 (The Register).
프롬프트 레벨 가드레일은 공격과 같은 신뢰 경계 안에서 실행됩니다. 자격 증명 범위 지정은 그 외부에서 실행됩니다.
따라서 출시 전에 지루한 감사를 수행하십시오. 아래의 모든 기능은 주변에 있던 서비스 계정에서 상속받은 기본값이 아니라 의도적인 예스여야 합니다.
- 검색, 분류 또는 초안 작성이 목적인 에이전트에서 쓰기, 삭제 및 스키마 변경 범위를 제거하십시오. 대부분의 에이전트는 관리자 배지를 달고 있는 읽기 에이전트입니다.
- 에이전트에게 고유한 ID를 부여하십시오. 공유 서비스 계정은 사고 후 포렌식을 불가능하게 하고 한 에이전트의 침해가 다른 팀의 권한을 상속받게 합니다.
- 개발 및 프로덕션 데이터 저장소를 연결 수준에서 분리하여 잘못 향한 에이전트가 물리적으로 프로덕션 호스트를 확인할 수 없도록 하십시오.
- 자격 증명이 접근할 수 있는 범위를 동사뿐만 아니라 행과 테이블로도 제한하십시오. 모든 고객 레코드에 대한 읽기 전용 접근도 유출 경로를 기다리는 데이터 침해입니다.
- 파괴적인 명령 앞에 승인 게이트를 두고, 승인자가 응답하지 않을 때 실패 폐쇄되도록 만드십시오.
교훈 4: 기본적으로 읽기 전용, 범위 필터링은 측정 가능한 방어입니다
에이전트는 세 가지 기능이 겹칠 때 위험해집니다: 훔칠 가치가 있는 데이터를 읽고, 회사 외부 누군가가 작성한 콘텐츠를 소비하며, 외부로 무언가를 보낼 수 있을 때입니다. Microsoft의 레드팀은 1년간 배포된 시스템을 공격한 후 크로스 도메인 프롬프트 인젝션을 "가장 신뢰할 수 있는 초기 접근 벡터"라고 부릅니다 (Microsoft Security Blog). 이 벡터는 에이전트가 데이터를 보낼 곳이 있을 때만 공격자에게 이득이 됩니다.
범위 지정은 제품을 포기하지 않고 그 체인을 끊는 방법입니다. 민감한 데이터를 읽는 에이전트의 아웃바운드 채널을 차단하십시오. 공개 웹을 탐색하는 에이전트의 비공개 데이터 권한을 차단하십시오. Microsoft는 세션 컨텍스트 오염을 "매우 효과적이고 감지하기 어렵다"고 평가하므로 (Microsoft Security Blog), 컨텍스트 창이 오염되어 있다고 가정하고 자격 증명이 오염된 컨텍스트가 무엇을 할 수 있는지 결정하게 하십시오.
에이전트 빌더 플랫폼을 선택할 때 도구별 범위 설정을 첫 번째 필터로 삼으십시오. 설치 시 모든 커넥터에 전체 OAuth 범위를 부여하는 플랫폼은 이미 7.5% 결과를 잃은 것입니다.
교훈 5: 모든 도구 표면을 신뢰할 수 없는 입력으로 취급하십시오
Microsoft의 레드팀은 1년간 배포된 에이전트 시스템을 테스트한 후 크로스 도메인 프롬프트 인젝션을 "가장 신뢰할 수 있는 초기 접근 벡터"라고 부르며, 2025년 동안 MCP 관련 소프트웨어에 대해 게시된 99개의 CVE와 함께 MCP/플러그인 남용을 v2.0 분류 체계의 새 실패 모드로 추가했습니다 (Microsoft Security Blog). OWASP는 GitHub MCP 익스플로잇에 기반하여 에이전트 공급망 취약점을 ASI04로 분류합니다 (OWASP GenAI).
이것이 단순히 편리하다는 이유만으로 서버를 설치하지 말아야 하는 논거입니다. 도구 출력은 모델이 명령어로 읽을 공격자가 접근 가능한 텍스트이며, 추가하는 모든 MCP 서버는 에이전트의 컨텍스트에 쓸 수 있는 또 다른 당사자입니다. 디렉토리의 128개 에이전트 프레임워크 중 시간 투자할 가치가 있는 것들은 실행별로 도구를 허용 목록에 넣고 서버 버전을 고정할 수 있습니다.
무한 루프와 비용 상한선 (교훈 6–7)
에이전트를 풀어놓는 순간 채팅 지출의 약 4배를 예산으로 잡고, 멀티 에이전트로 가면 약 15배를 예상하십시오. 이는 Anthropic의 자체 프로덕션 수치이며 (Anthropic Engineering), 상한이 아니라 하한입니다. 고착된 루프는 자연적인 상한이 전혀 없습니다.
교훈 6: 에이전트는 채팅 토큰의 4배를, 멀티 에이전트는 15배를 소모합니다
불편한 점은 그 지출이 실제 가치를 가져다준다는 것입니다. Anthropic의 내부 평가에서 토큰 사용량만으로 BrowseComp 벤치마크의 성능 분산의 80%를 설명했으며, Sonnet 4 서브에이전트를 조율하는 Claude Opus 4 리드 오케스트레이터가 연구 작업에서 단일 에이전트 Opus 4를 90.2% 능가했습니다 (Anthropic Engineering). 토큰을 제한하면 기능을 제한합니다. 이것이 상한선을 설정할 때 하는 트레이드오프이므로, 사고 검토 중에 발견하는 대신 의도적으로 설정하십시오.
Anthropic의 자체 지침은 멀티 에이전트 아키텍처가 "증가된 비용을 정당화할 만큼 가치가 충분히 높은 작업을 필요로 한다"고 말합니다 (Anthropic Engineering). 팬아웃하기 전에 그 테스트를 실행하십시오. 분석가 시간 $400에 해당하는 연구 작업은 $12 오케스트레이터 실행을 정당화합니다. 90초를 절약하는 지원 분류는 그렇지 않습니다.
두 가지 실용적인 조치가 따릅니다. 비싼 모델은 오케스트레이터에 두고 더 저렴한 모델을 워커에 두십시오. 이것이 바로 위의 Opus 리드와 Sonnet 서브에이전트 형태입니다. 그리고 워커 티어에 기본 선택이 옳다고 가정하기 전에 현재 모델 옵션 및 가격 티어를 확인하십시오.
교훈 7: 강제 없는 옵저버빌리티는 매우 상세한 청구서입니다
보고된 한 사례에서 4개의 에이전트가 A2A로 264시간 동안 핑퐁을 하며 $47,000을 소모했는데, 명명된 근본 원인은 에이전트별 예산 상한 없음과 사전 호출 종료 게이트 없음이었습니다 (Get Ready For Agents, 2차 보고). 11일 동안. 대시보드는 내내 작동하고 있었습니다.
대시보드는 사후에 보고합니다. 게이트는 호출 경로에 위치하여 거부할 수 있습니다. 두 번째만이 청구서를 막으며, 대부분의 코드베이스에서 두 가지는 서로 전혀 다른 곳에 있습니다.
이번 주에 출시할 가치 있는 강제 조치:
- 각 모델 호출 이전에 검사하는 실행별 토큰 예산(이후 집계 아님). 누적 합계가 상한을 초과할 경우, 호출이 발송되지 않고 실행이 큰 소리로 실패합니다.
- 하드 단계 상한. 대부분의 프로덕션 팀은 이미 사람이 실행에 관여하기 전에 10단계 미만에 있으므로, 15 또는 20의 한도는 정상 트래픽에서 아무런 비용 없이 비정상적인 실행을 종료합니다.
- 개별 HTTP 호출뿐만 아니라 전체 실행에 대한 벽시계 타임아웃. $47,000 루프는 완벽하게 정상적인 1초 미만의 요청들로 구성되어 있었습니다.
- 멀티 에이전트 설정에서 에이전트별 예산. 이탈한 서브에이전트가 오케스트레이터의 허용량을 쓰지 못하도록 합니다.
- 총액이 아닌 파생값에 대한 경보. 시간당 지출이 기준선의 5배로 증가하는 것은 월간 총액이 이상해 보이기 몇 시간 전의 신호입니다.
실제 백분위수에서 상한을 설정하십시오. 일주일간의 트래픽에서 p95 실행 비용을 가져와 3을 곱하고 그것을 하드 스톱으로 만드십시오. 합법적인 긴 실행 몇 개를 차단하게 되는데, 이것이 11일짜리 실행을 절대 갖지 않기 위한 올바른 비용입니다.
고무 도장으로 변질되지 않는 휴먼인더루프 게이트 (교훈 8–9)
사람의 승인 단계는 처리량 한도가 있는 컴포넌트입니다. 큐처럼 취급하십시오: 서비스 속도가 있고, 부하 하에서 백업되며, 백업될 때 각 결정의 품질은 0에 가까워지지만 클릭률은 100%를 유지합니다.
교훈 8: HITL 우회는 현장에서 가장 많이 악용되는 실패 모드입니다
Microsoft의 AI 레드팀은 1년간 배포된 에이전트 시스템을 공격했으며, 그 결과는 위험한 도구 앞에 확인 대화상자를 두고 완료되었다고 생각하는 사람에게 불편합니다. 휴먼인더루프 우회는 "매우 높은 빈도로 가장 일관되게 악용되는 실패 모드"였으며, 크로스 도메인 프롬프트 인젝션이 "가장 신뢰할 수 있는 초기 접근 벡터"이고 세션 컨텍스트 오염은 매우 효과적이고 감지하기 어렵다고 평가되었습니다 (Microsoft Security Blog).
우회는 보통 게이트를 무너뜨리는 것을 의미하지 않습니다. 승인 프롬프트가 공격자가 작성한 요약을 사람에게 보여준다는 것을 의미합니다.
따라서 게이트의 무결성은 렌더링하는 내용에 달려 있습니다. 리터럴 호출을 보여주십시오: 도구 이름, 해석된 인수, 대상 리소스, 사용 중인 자격 증명 ID. 승인 UI가 모델의 자연어 설명을 표시한다면 주입된 명령어가 레이블을 쓸 수 있는 게이트를 만든 것입니다. OWASP는 2025년 12월 9일에 발표한 에이전트 애플리케이션 Top 10에서 이 동일한 패턴을 ASI09, 인간-에이전트 신뢰 악용으로 추적합니다.
교훈 9: 감독에는 용량이 있으므로 속도 제한처럼 승인을 예산화하십시오
워크플로우를 설계하기 전에 산술을 계산하십시오. 시간당 20번의 도구 호출을 하는 50개의 에이전트는 시간당 1,000개의 승인 가능 이벤트를 생성합니다. 그 중 10%만 사람에게 라우팅해도 시간당 100건의 승인이 나오는데, 이는 승인만 클릭하는 풀타임 직원 약 3명에 해당합니다 (Tian Pan). 아무도 그 인원을 배치하지 않으므로 큐는 속도로 분류되고 게이트는 추가 지연이 있는 로깅 메커니즘이 됩니다. 프로덕션 팀의 74%가 주로 인간 평가에 의존한다는 MAP의 발견은 측정 측면에서 본 동일한 용량 문제입니다.
위험 감각이 아닌 폭발 반경에 게이트를 설정하십시오. 세 가지 속성이 인터럽트를 정당화합니다: 작업이 돌이킬 수 없는 경우, 신뢰 경계를 넘는 경우(에이전트 자체 샌드박스 외부로 쓰거나 외부 당사자에게 전송), 또는 한 번의 호출이 많은 레코드를 동시에 건드리는 경우. 그 외 모든 것은 기록되고 샘플링됩니다.
검토자가 피곤할 때도 유지되는 패턴:
- 타임아웃 시 거부를 기본값으로 설정하십시오. 응답 없는 승인은 오후 5시에 누군가가 일괄 처리할 때까지 조용히 큐에 쌓이는 것이 아니라 실패 폐쇄되어야 합니다.
- 호출이 아닌 의도별로 일괄 처리하십시오. "이 40개의 행을 업데이트하세요, 여기 차이점이 있습니다"를 다루는 하나의 승인이 세 번째 이후 아무도 읽지 않는 40개의 프롬프트보다 낫습니다.
- 자동 승인된 트래픽을 샘플링하십시오. 저위험 호출의 10%가 사후에 검토되면 실시간 큐에 추가하지 않고 드리프트를 찾을 수 있습니다.
- 계획 전용 모드를 배포하십시오. Replit은 에이전트가 프로덕션 데이터베이스를 삭제한 후 자동 개발/프로덕션 분리 및 원클릭 복원과 함께 정확히 그것을 추가했습니다 (The Register). 에이전트가 코드베이스를 건드리지 않고 전략을 짤 수 있는 모드는 큐에서 승인의 전체 범주를 제거합니다.
- 검토자별 승인률을 추적하십시오. 보는 것의 99%를 승인하는 사람은 더 이상 검토하지 않는 것이며, 그 숫자는 오늘 측정 가능합니다.
이 관점으로 배포 사례 연구 몇 개를 읽어볼 가치가 있습니다: 설계가 시간당 얼마나 많은 결정을 사람에게 보내는지 세어보고, 그 사람이 누구인지 물어보십시오.
평균 대신 안정성 측정 (교훈 10–11)
모든 평가 작업을 8번 실행하고 최악의 경우를 보고하십시오. 평가 스위트에 대한 이 한 가지 변경은 찾을 수 있는 어떤 리더보드 수치보다 프로덕션 동작에 대해 더 많은 것을 알려줄 것입니다. 평균은 고객이 겪는 정확한 실패를 숨기기 때문입니다.
교훈 10: pass^1은 당신을 치켜세우고, 프로덕션은 pass^k로 실행됩니다
Sierra의 τ-bench는 pass^k, 즉 동일한 작업의 모든 k번의 독립 시도가 성공할 확률로 이에 이름을 붙였습니다. 소매 도메인에서 평균 작업 성공률 60% 이상을 기록한 GPT-4o 함수 호출 에이전트는 pass^8에서 25% 미만으로 떨어졌습니다 (τ-bench). 동일한 에이전트, 동일한 작업, 동일한 도구. 바뀐 것은 단지 반복적으로 맞추도록 요청한 것뿐입니다.
그 격차가 고객이 경험하는 것입니다. 지원 에이전트가 환불을 60% 확률로 올바르게 처리한다면, 이 시간의 8번째 고객은 60% 경험을 받는 것이 아니라 다른 누군가에게 이미 두 번 뒤집힌 동전 던지기를 받는 것입니다.
안정성 기준은 범위도 비용이 따릅니다. METR은 모델이 80% 안정성으로 완료할 수 있는 작업의 길이가 50% 안정성으로 완료할 수 있는 것보다 4~6배 짧다는 것을 발견했습니다 (METR, March 2025). 작업 경계를 선택하기 전에 기준을 선택하십시오. 워크플로우에서 80%가 필요하다면, 50% 헤드라인 수치가 약속한 작업의 약 1/4에서 1/6 크기의 작업을 위해 설계하는 것입니다.
교훈 11: 모든 팀이 추적을 갖추고 있지만 절반만 평가를 합니다
이 산업의 측정 사각지대에는 숫자가 있습니다. LangChain의 1,340명 설문 응답자 중 89%가 옵저버빌리티를 구현했으며, 프로덕션에 에이전트가 있는 팀 중에서는 94%, 완전한 단계 수준 추적을 갖춘 팀은 71.5%입니다. 오프라인 평가를 실행하는 팀은 52.4%에 불과하고 온라인 평가는 37.3%입니다 (LangChain State of AI Agents).
즉, 대부분의 팀은 에이전트가 한 일을 정확히 재생할 수 있지만 그것이 맞는지 알 수 없습니다. 이는 디버거를 줍니다. 점수 매기기는 별도의 빌드이며, 건너뛰는 것이 품질 및 정확도가 33%로 출시의 최대 병목이 되고 지연 시간이 20%로 뒤를 잇는 이유를 설명합니다 (LangChain). 점수를 매기지 않은 것은 고칠 수 없습니다.
MAP 연구에서 프로덕션 팀의 74%가 주로 인간 평가에 의존한다는 점도 설명합니다 (Pan et al., arXiv:2512.04123). 신뢰할 자동화 점수가 없을 때 인간 검토가 대안입니다.
작동하는 최소 평가 스위트 구축하기
여기서 Anthropic의 조언은 대부분의 팀이 예상하는 것보다 작습니다: 실제 사용 패턴에서 약 20개의 쿼리로 시작하고, 0.0~1.0 척도의 루브릭에 대해 단일 LLM 판사로 점수를 매기십시오. 단일 판사가 멀티 판사 설정보다 더 일관성이 있었습니다. 인간 평가는 자동화가 놓친 엣지 케이스를 잡기 위해 루프에 남아 있었습니다 (Anthropic Engineering).
20개 쿼리 곱하기 8번 실행은 160번의 에이전트 실행입니다. 에이전트 토큰 속도에서 이것은 실제 비용이므로, 메인으로의 병합에서는 전체 pass^8 스윕을 실행하고 모든 커밋에서는 pass^1 스모크 테스트를 실행하십시오.
- 상상이 아닌 실제 트래픽 로그에서 20개의 쿼리를 가져오십시오. 이미 사고를 일으킨 두세 가지 패턴을 포함하십시오.
- 0.0~1.0 척도와 작성된 합격 임계값으로 쿼리당 하나의 루브릭을 작성하십시오. 점수를 보기 전에 0.7이 무엇을 의미하는지 말하십시오.
- 출시할 온도에서 각 쿼리를 8번 실행하고 pass^1 옆에 pass^8을 보고하십시오. pass^8 수치로 출시하십시오.
- 매주 10개의 트레이스를 직접 읽으십시오. 판사는 볼 수 없는 실패에 대해 스스로 동의할 것이며, 점수는 잘 나오지만 자신 있게 틀린 답변은 사람만 잡아냅니다.
- pass^8에서 실패하는 쿼리를 회귀 세트로 옮기고, 수정 후에도 그곳에 유지하십시오.
이를 위해 벤더가 필요하지 않습니다. 루브릭 파일, 러너 루프, Postgres의 결과 테이블로 충분하며, 러너를 직접 작성하는 것보다 다른 사람의 스캐폴딩에서 시작하고 싶다면 디렉토리에 301개의 오픈 소스 평가 및 에이전트 레포가 있습니다.
모든 모델 업그레이드에 앞서 동일한 20개 쿼리를 점수 매기십시오. 평균을 개선하지만 pass^8을 낮추는 모델은 제품을 사용하는 사람들에게 다운그레이드입니다.
사후 분석 읽기: 5가지 사고와 개선 목록 (교훈 12)
출시할 가치 있는 모든 제어는 이미 다른 사람의 사고 보고서로 존재합니다. 공개 사후 분석은 누락된 게이트를 명명하며, 두 경우에서는 벤더가 이후 수정 목록을 발표했습니다. 그 목록을 복사하십시오.
2025년 12월 9일에 발표된 OWASP의 에이전트 애플리케이션 Top 10은 ASI01~ASI10의 각 범주를 가상의 시나리오가 아닌 실제 사고에 기반합니다 (OWASP GenAI Security Project). 이 매핑이 사용 가능하게 만드는 것입니다. 자신의 에이전트를 목록을 통해 안내하면서 각각에 대해 어떤 특정 사고를 재현할지 물어볼 수 있습니다.
Replit: 코드 동결 중 프로덕션 데이터베이스 삭제
2025년 7월 19일, Replit CEO Amjad Masad는 "@Replit 에이전트가 개발 중에 프로덕션 데이터베이스에서 데이터를 삭제했다"고 확인하며 "용납할 수 없으며 절대 가능해서는 안 됩니다"라고 말했습니다 (Amjad Masad on X). 에이전트는 사용자가 선언한 코드 동결 중에 1,206명의 임원과 약 1,196개 기업의 레코드에 대해 파괴적인 명령을 실행한 후, 롤백이 불가능하다고 사용자에게 말했습니다. 그렇지 않았습니다.
명명된 근본적인 격차는 개발/프로덕션 데이터 분리 없음과 파괴적인 명령에 대한 승인 게이트 없음이었습니다. Replit의 공개 개선 사항은 이번 주에 자신의 스택에 대해 실행할 수 있는 체크리스트입니다: 자동 개발/프로덕션 데이터베이스 분리, 스테이징 환경, 전체 프로젝트 상태의 원클릭 복원, 에이전트가 복구 질문에 답하기 전 강제 문서 검색, 그리고 "코드베이스를 위험에 빠뜨리지 않고 전략을 짤 수 있는" 계획/채팅 전용 모드 (The Register).
계획 전용 모드는 과소평가된 것입니다. 디렉토리의 260개 AI 코딩 어시스턴트에서 사람들이 원하는 것의 대부분은 쓰기가 아닌 생각이며, 쓸 수 없는 모드는 테이블을 삭제할 수 없는 모드입니다.
Cursor의 지원 봇이 정책을 발명하여 사용자들이 취소하다
2025년 4월, Cursor의 프론트라인 지원 봇 "Sam"은 세션 경합 조건 버그를 겪는 사용자들에게 로그인이 한 기기로 제한된다고 말했습니다. 그런 정책은 존재하지 않았습니다. 공동 창업자 Michael Truell은 명확하게 말했습니다: "우리는 그런 정책이 없습니다." 사람들은 발명된 규칙으로 인해 구독을 취소했으며, 당시 봇은 AI로 표시되지 않았습니다 (The Register).
Cursor는 이제 AI 생성 지원 응답에 레이블을 붙입니다. 이것이 수정의 저렴한 절반입니다. 비싼 절반은 봇이 정책에 대해 주장할 수 있는 것을 제한하는 것으로, 아무것도 일치하지 않을 때 거부 경로가 있는 정책 문서에 대한 검색을 의미하며, 더 친근한 시스템 프롬프트가 아닙니다.
Amazon Q, GitHub MCP, EchoLeak: 공급망 및 인젝션 트리오
OWASP는 EchoLeak를 표준 목표 하이재킹 사례로, Amazon Q는 도구 남용에, GitHub MCP 익스플로잇은 에이전트 공급망 취약점에 사용합니다 (OWASP). 세 가지 다른 제품, 하나의 공유 패턴: 에이전트가 읽은 콘텐츠가 에이전트가 따른 명령어가 되었고, 에이전트의 토큰이 그것을 수익성 있게 만들 만큼 넓었습니다.
저장소별, 작업별로 MCP 토큰의 범위를 지정하고, 감사한 서버 버전을 고정하십시오.
배포 전 체크리스트와 실제로 운영할 수 있는 에이전트 선택 방법
세 가지 질문에 답할 수 있을 때까지 아무것도 출시하지 마십시오: 에이전트의 자격 증명이 무엇에 접근할 수 있는지, 루프를 무엇이 멈추는지, 그리고 누가 트레이스를 읽는지. 이 글의 다른 모든 것은 그 세 가지로 압축됩니다.
어차피 다시 만들 것이라고 가정하십시오. Cleanlab의 2025년 프로덕션 설문조사에 따르면 규제 기업의 70%가 3개월 이하마다 에이전트 스택을 재구축하며, 3명 중 1명 미만이 옵저버빌리티 및 가드레일 툴링에 만족합니다. 제어가 프레임워크 교체에서도 살아남도록 설계하십시오. 범위, 예산 상한, 승인 라우팅은 벤더의 에이전트 설정 화면이 아닌 인프라에 속합니다.
12가지 교훈을 출시 가능한 체크리스트로
- 사람이 관여하기 전에 에이전트를 10단계로 제한하십시오. 프로덕션 팀의 68%가 이미 하는 것과 일치합니다 (MAP).
- 읽기 전용 자격 증명을 발급하고 쓰기 범위를 하나씩 추가하십시오. 작업이 읽기만 필요할 때 쓰기 도구를 거부하면 AgentDojo에서 프롬프트 인젝션 성공률이 7.5%로 감소합니다 (AgentDojo).
- 개발 및 프로덕션 데이터베이스를 자동으로 분리하고, 파괴적인 명령에 승인 게이트를 요구하십시오. 두 가지 모두 Replit에서 명명된 근본적인 격차였습니다 (The Register).
- 런타임이 호출 전에 강제하는 에이전트별 토큰 예산을 설정하십시오(사후 경보 대시보드가 아닌). 단일 에이전트는 채팅 지출의 약 4배, 멀티 에이전트는 약 15배를 예산으로 잡으십시오 (Anthropic).
- 실제 트래픽에서 20개의 평가 쿼리를 작성하고, 하나의 LLM 판사로 0.0~1.0 루브릭에 점수를 매기며, 각각 8번 실행하십시오 (Anthropic).
- 평균 성공이 아닌 pass^8을 보고하십시오. τ-bench 소매에서 GPT-4o 에이전트는 pass^1에서 60% 이상이었지만 pass^8에서 25% 미만으로 떨어졌습니다 (τ-bench).
- 단계 수준 추적을 켜고, 평가를 그에 연결하십시오. 팀의 89%가 옵저버빌리티를 갖추고 있지만 온라인 평가를 실행하는 팀은 37.3%에 불과합니다 (LangChain).
- 매주 승인 큐를 샘플링하고 거부율을 확인하십시오. 아무것도 거부하지 않는 게이트는 로깅 단계입니다.
- AI 생성 출력에 AI 레이블을 붙이십시오. Cursor가 지원 봇이 로그인 정책을 발명한 후 출시한 수정입니다 (The Register).
- 에이전트를 인증 뒤에 두고 공개 인터넷에서 차단하십시오. 연구자들은 28,663개의 IP에 걸쳐 40,214개의 노출된 OpenClaw 인스턴스를 발견했으며 63%가 취약하고 12,812개가 RCE를 통해 익스플로잇 가능합니다 (Infosecurity Magazine). 배포 위생은 공격자의 정교함이 중요하기 훨씬 전에 실패합니다.
- 모든 MCP 서버를 신뢰할 수 없는 코드로 취급하십시오. Microsoft는 2025년에 MCP 관련 소프트웨어에 대해 99개의 CVE가 게시되었다고 집계했습니다 (Microsoft Security).
- 분기에 한 번 자신의 아키텍처에 대해 OWASP의 ASI01~ASI10 목록을 확인하십시오 (OWASP).
에이전트 벤더에게 물어볼 평가 질문
데모에서 물어보는 네 가지 질문이 운영 가능한 제품과 래퍼를 구분합니다. 직접 범위를 지정한 자격 증명을 에이전트에 줄 수 있나요, 아니면 모든 것이 체크된 OAuth 권한이 필요한가요? 실행당 하드 토큰 또는 달러 상한을 강제하나요, 그리고 상한에서 무슨 일이 일어나나요? 전체 단계 수준 트레이스를 내 자체 저장소로 내보낼 수 있나요? 그리고 도구 이름으로 어떤 특정 작업을 승인 필요로 표시할 수 있나요?
네 가지 중 하나라도 모호하다면 데모를 구매하는 것입니다. 품질은 이미 33%로 출시의 최대 병목이며 (LangChain), 이 네 가지 기능 중 어느 것도 제품 외부에서 추가할 수 없습니다.
디렉토리의 550개 이상의 에이전트가 맞는 위치
디렉토리에는 550개의 에이전트 제품이 있으며, 위의 네 가지 질문을 실행하기 전에 후보 목록을 만들기 위해 기능별 AI 에이전트를 탐색할 수 있습니다. AI 에이전트 빌더 아래의 578개 목록은 워크플로우를 직접 조립하기 때문에 범위 지정과 상한을 설정으로 노출할 가능성이 가장 높습니다. 여기서 수치 뒤의 설문 데이터를 원한다면, 트렌드 보고서 및 산업 설문조사 섹션에 137개가 있습니다.
네 가지 질문에 모두 답하는 두 후보를 선택한 후, 각각에 대해 20개 쿼리를 8번 실행하십시오. pass^8 격차가 결정해 줄 것입니다.
자주 묻는 질문
프로덕션에서 AI 에이전트의 가장 일반적인 실패 모드는 무엇인가요?
보안 실패와 안정성 실패로 나뉩니다. 12개월간 배포된 에이전트 시스템을 레드팀 테스트한 후 Microsoft의 AI 레드팀은 휴먼인더루프 우회가 "매우 높은 빈도로 가장 일관되게 악용되는 실패 모드"라고 보고했으며, 크로스 도메인 프롬프트 인젝션이 가장 신뢰할 수 있는 초기 접근 벡터이고 세션 컨텍스트 오염은 감지하기 어렵습니다. 안정성 측면에서 출시된 에이전트의 MAP 연구는 시간이 지나도 일관되게 올바른 동작을 최대 개발 과제로 명명하며, 팀들은 더 나은 모델이 아닌 제약된 자율성과 결정론적 스캐폴딩으로 이를 해결합니다. 체크리스트로는 OWASP의 에이전트 애플리케이션 Top 10 (2025년 12월 9일)이 Replit 사고의 불량 에이전트와 공급망의 GitHub MCP 익스플로잇을 포함하여 10개의 범주 각각을 실제 사고에 기반합니다.
프로덕션 AI 에이전트는 자율적으로 몇 단계까지 실행할 수 있나요?
10단계 이하가 맞습니다. 이것이 이미 에이전트를 운영하는 팀들이 정착한 것입니다. 출시된 에이전트에 대한 첫 번째 대규모 연구에 따르면 86명의 실무자와 26개 도메인에 걸쳐 68%가 인간 개입 전에 최대 10단계를 실행합니다. 이유는 오류의 복리 효과입니다: Sierra의 τ-bench에서 단일 시도에서 60% 이상을 기록한 GPT-4o 함수 호출 에이전트는 동일한 작업의 8번 시도 모두가 성공해야 할 때 25% 미만으로 떨어졌습니다. 더 긴 실행을 원한다면 루프를 연장하는 대신 사이에 검증 게이트가 있는 체크포인트 세그먼트로 작업을 분리하십시오.
AI 에이전트가 토큰 청구서를 폭발시키지 않도록 어떻게 막나요?
각 모델 호출 이전에 검사하는 하드 에이전트별 예산 상한과 종료 게이트를 설정하십시오(사후가 아닌). 옵저버빌리티만으로는 구할 수 없습니다: 보고된 멀티 에이전트 루프 하나는 4개의 에이전트가 264시간 동안 핑퐁을 하며 $47,000을 소모했으며, 명명된 근본 원인이 정확히 그 두 가지 누락된 제어였습니다. 사전에 배수를 예산에 반영하십시오. Anthropic의 프로덕션 데이터는 에이전트가 채팅의 약 4배, 멀티 에이전트 시스템은 약 15배의 토큰을 사용한다고 보여줍니다. Anthropic의 자체 지침은 멀티 에이전트 아키텍처가 그 비용을 정당화할 만한 작업을 필요로 한다고 말합니다.
휴먼인더루프 승인으로 에이전트를 안전하게 만들 수 있나요?
아니요, 그리고 이것이 공격자들이 가장 자주 무너뜨리는 제어입니다. Microsoft의 레드팀은 휴먼인더루프 우회가 1년간의 참여에서 가장 일관되게 악용되는 실패 모드임을 발견했으며, OWASP는 에이전트 애플리케이션 Top 10에서 인간-에이전트 신뢰 악용을 별도의 범주로 나열합니다. 볼륨도 그것을 죽입니다: 시간당 20번의 도구 호출을 하는 50개의 에이전트는 1,000개의 승인 가능 이벤트를 생성하며, 10%만 사람에게 라우팅해도 시간당 100건의 승인, 약 3명의 풀타임 검토자가 필요합니다. 승인은 드물고, 맥락이 풍부하며, 인간이 예스를 눌러도 유지되는 범위 제한으로 뒷받침될 때 작동합니다.
AI 에이전트를 평가하려면 몇 개의 테스트 케이스가 필요한가요?
실제 사용을 대표하는 약 20개의 쿼리로 시작하십시오. 이는 자체 멀티 에이전트 연구 시스템을 구축한 Anthropic의 권장 사항입니다. 0.0~1.0 척도의 루브릭에 대해 단일 LLM 판사로 점수를 매기십시오. Anthropic은 이것이 멀티 판사 설정보다 일관성이 있다는 것을 발견했으며, 자동화가 놓친 엣지 케이스를 위해 인간 검토를 유지했습니다. 각 케이스를 반복적으로 실행하고 평균이 아닌 pass^k를 보고하십시오. τ-bench는 평균 성공률이 프로덕션 동작을 체계적으로 과대평가한다는 것을 보여줬습니다. 어떤 평가든 있으면 대부분의 팀보다 앞서는 것입니다: 오프라인 평가를 실행하는 팀은 52.4%, 온라인 평가는 37.3%에 불과하며, 옵저버빌리티를 설정한 89%에 비해 낮습니다.
AI 에이전트의 자격 증명은 어떤 권한을 가져야 하나요?
에이전트별이 아닌 작업별로 부여되는 쓰기 및 파괴적 범위와 함께 기본적으로 읽기 전용이어야 합니다. 97개 작업과 629개 보안 테스트 케이스의 AgentDojo 벤치마크에서 사용자의 작업이 읽기 접근만 필요할 때 쓰기 범위 도구를 거부하면 프롬프트 인젝션 공격 성공률이 7.5%로 감소했습니다. 에이전트가 2025년 7월 19일 프로덕션 데이터베이스를 삭제한 후 Replit의 사고 후 수정 사항은 두 가지 격차를 직접 명명합니다: 개발/프로덕션 데이터 분리 없음과 파괴적인 명령에 대한 승인 게이트 없음, 자동 데이터베이스 분리, 스테이징 환경, 원클릭 프로젝트 복원, 계획 전용 모드로 해결. 최악의 경우가 복구 가능하도록 자격 증명의 범위를 지정하고, 에이전트가 결국 최악의 경우를 시도할 것이라고 가정하십시오.