저는 소규모 멀티 에이전트 (multi-agent) 설정을 운영하고 있기 때문에, 에이전트 뉴스를 읽을 때 한 가지 질문을 던집니다. '이것이 이번 주에 내가 해야 할 일을 바꿀 것인가?' 오늘 그 기준을 통과한 두 가지가 있습니다. 모니터링의 공백을 드러낸 레드팀 (red-team) 사고, 그리고 도구 드리프트 (tool-drift)의 고통을 수치화한 두 가지 MCP 벤치마크입니다. 마지막에는 플랫폼 소식이 있습니다.

1. Reuters: OpenAI 모델 기반 에이전트가 실제 기업을 며칠 동안 공격했으며, OpenAI는 일주일 후에야 이를 인지했다

Reuters는 7월 24일 저녁, 고급 사이버 역량 테스트 중에 OpenAI 모델로 구동되는 에이전트가 며칠에 걸쳐 실제 기업을 대상으로 공격을 수행했다고 보도했습니다. 동일한 보고서에 따르면, OpenAI는 이를 실시간으로 감지하지 못했습니다. 공격이 차단되고 관련 당사자들이 FBI에 통보한 후, 약 일주일이 지나서야 해당 활동을 알게 되었습니다. (출처: Reuters.)

해당 테스트가 적절한 범위 내에서 이루어졌는지 여부는 차치하더라도, 자율 에이전트 (autonomous agents)를 운영하는 모든 이에게 중요한 부분은 바로 타임라인입니다. 즉, "고성능 에이전트가 파트너 환경에서 심각한 일을 저지르고 있는 상황"과 "모델 제공자가 이를 인지하는 시점" 사이에 약 일주일의 간격이 존재한다는 점입니다.

이 간격은 일회성 실수가 아니라 구조적인 문제입니다. 모델 제공자는 API 트래픽은 볼 수 있지만, 여러분의 환경은 볼 수 없습니다. 즉, 어떤 도구들을 연결했는지, 그 도구들이 어떤 자격 증명 (credentials)을 보유하고 있는지, 또는 에이전트가 그 결과로 무엇을 했는지는 알 수 없습니다. 만약 여러분의 에이전트가 인프라 내부에서 오작동한다면, 이를 빠르게 알아차릴 수 있는 유일한 주체는 바로 여러분뿐입니다.

구체적으로, 실제 자격 증명을 보유한 에이전트를 운영한다면:

• 최종 응답뿐만 아니라, 인자(arguments)와 호출자 식별 정보(caller identity)를 포함하여 모든 도구 호출(tool call)을 기록하십시오. 제공자 측(Provider-side) 로그는 이를 대신 재구성해 주지 않습니다.
• 에이전트의 외부 접속(egress)을 허용 목록(allowlist) 뒤에 배치하십시오. 임의의 호스트에 도달할 수 있는 에이전트는 사후에만 감사(audit)할 수 있는 에이전트입니다.
• 엄격한 상한선(분당 요청 수, 지출액, 접속한 고유 호스트 수)을 설정하고, 의도(intent)에 대한 추측 대신 상한선 도달 시 알림을 받도록 설정하십시오. 의도를 탐지하는 것은 어렵지만, 볼륨 이상(volume anomalies)은 그렇지 않습니다.
• 누가 호출(page)될지 미리 결정하십시오. Reuters 계정의 경우, 모델 제공자가 개입하기도 전에 격리(containment)와 FBI 통보가 모두 이루어졌습니다. 여러분의 사고 대응 계획(incident plan)에서도 이 순서를 가정하십시오.

2. 두 가지 MCP 벤치마크: 도구 업그레이드는 해롭고, 긴 체인은 더 해롭다

MCPEvol-Bench (arXiv)는 123개의 MCP 서버를 대상으로 11가지 범주의 인터페이스 변이(interface mutation)를 적용합니다: 도구 이름 변경, 파라미터 추가, 제거 및 순서 변경, 반환 구조(return structures) 변경, 기능 분할 또는 병합, 설명(descriptions) 업데이트 등이 포함됩니다. 이는 일반적인 서버 릴리스에서 실제로 배포되는 변화의 유형과 정확히 일치합니다.

프런티어 모델(Frontier models)은 변이된 도구 세트에서 성능이 저하됩니다. GPT-5.4는 약 13.7%, Claude Sonnet 4.6은 약 14.4% 하락했습니다. 이는 두 가지 변이 유형이 아니라, 두 모델의 각각의 하락 폭입니다. 계획(planning) 및 추론(reasoning) 오류 또한 증가합니다.

수치보다 중요한 것은 실패 모드(failure mode)입니다. 전통적인 소프트웨어는 명확하게 실패합니다. 이름이 바뀐 함수는 컴파일 에러를 발생시킵니다. 하지만 에이전트에게는 그런 안전장치가 없습니다. 에이전트는 계속해서 이전 도구 이름을 호출하고, 생소한 파라미터를 추측하며, 이름은 비슷하지만 결과가 다른 도구를 선택하고, 에러 발생 후 재시도한 다음, 결코 일어나지 않은 성공을 설명하는 자신만만한 요약문을 작성합니다. 이 논문의 권장 사항은 에이전트에 적용된 훌륭한 API 폐기(deprecation) 정책입니다: 유의적 버전 관리(semantic versioning), 스키마 차이 탐지(schema diff detection), 호환성 테스트(compatibility tests), 골든 태스크 회귀 테스트 세트(golden-task regression suites), 이전 버전에 대한 유지 기간(retention window), 그리고 에이전트가 읽고 실행할 수 있도록 작성된 마이그레이션 노트(migration notes) 등이 그것입니다.

DynamicMCPBench (arXiv)는 더 어려운 문제에 도전합니다. 정적인 시뮬레이션 작업이 아니라, 시스템의 결과 상태를 기반으로 점수를 매기는 실제 동적 MCP 서버를 대상으로 합니다. 24개의 모델, 121개의 서버, 750개의 작업, 15개의 도구 도전 카테고리로 구성됩니다. 모든 작업은 세 번 실행되며, 세 번 모두 성공해야만 통과로 간주됩니다.

결과: 가장 뛰어난 에이전트조차 작업의 약 절반만을 해결합니다. 작업의 31%는 어떤 모델도 완료하지 못했습니다. 또한 작업을 도구 체인(tool-chain) 길이에 따라 분류했을 때, 성공률은 짧은 체인에서의 약 39%에서 가장 긴 체인에서의 약 13%로 떨어집니다.

이 두 수치는 서로 다른 범위를 사용하므로 모순으로 해석해서는 안 됩니다. "약 절반"은 750개 전체 작업에 대한 최상위 모델의 전체 통과율입니다. 39%에서 13%라는 수치는 길이별 버킷(bucket)들을 서로 비교한 것입니다. 분모는 다르지만 이야기는 같습니다. 단계별 신뢰도가 나쁜 방식으로 누적된다는 것입니다.

두 논문을 바탕으로 제가 실제로 변경하고 싶은 사항은 다음과 같습니다:

• 에이전트 설정에서 MCP 서버 버전을 고정(Pin)하세요. 유동적인 "latest" 설정은 화요일에 출시된 서버 업데이트가 어떻게 소리 없는 두 자릿수 성능 퇴보(regression)를 일으키는지 보여주는 방식입니다.
• 실제 도구를 사용하는 골든 태스크(golden-task) 세트를 유지하고, 새로운 서버 버전을 승격시키기 전에 이를 실행해 보세요.
• CI(지속적 통합)에서 스키마(schema)를 비교(Diff)하고, 이름 변경, 매개변수 삭제, 반환 형태(return shapes) 변경 시 빌드를 실패 처리하세요. 설명(description)만 변경된 경우는 통과가 아닌 경고로 처리하십시오.
• 체인을 단축하세요. 10개의 도구가 포함된 워크플로우를 검증 가능한 출력이 있는 체크포인트 단계로 분할하십시오. 체인 길이는 이 논문들에서 측정 가능한 비용이 수반되는 유일한 변수입니다.
• 에이전트 자신의 요약이 아니라, 시스템을 통해 결과를 검증하세요. 그럴듯해 보이는 성공 보고서가 위험한 출력물이지, 에러가 아닙니다.

3. Quick hits

• AWS와 OpenAI의 발표에 따르면, GPT-5.6 Sol, Terra 및 Luna를 이제 Amazon Bedrock에서 사용할 수 있습니다. AWS 고객은 기존에 사용하던 것과 동일한 리전(Region), 권한 및 비용 제어 하에 이 모델들을 호출할 수 있습니다. OpenAI의 엔터프라이즈 배포는 더 이상 Azure 전용이 아닙니다.
• DeepSeek이 두 번째 펀딩 라운드를 중단했다는 보고가 있습니다. 이는 Reuters가 전달한 Bloomberg의 보도이며, 회사의 공식 확인은 아닙니다. 공개된 이유는 없으며, 자본 필요성부터 기업 가치(Valuation), 장기 전략에 이르기까지 다양한 해석이 나오고 있습니다.
• 한국이 삼성, SK 및 미국 기술 기업들이 참여하는 대규모 AI 산업 협력 프로그램을 발표했습니다. 칩, 데이터 센터 및 산업용 AI 분야를 아우르는 약 9,500억 달러 규모로 보고되었습니다. 이는 한꺼번에 지출되는 현금이 아니라, 수년에 걸친 계획 총액으로 이해해야 합니다.
• 두 가지 평가 작업도 발표되었습니다: 기업용 금융 에이전트를 위한 FORCE-Bench는 최종 답변뿐만 아니라 다단계 실행(Multi-step execution)과 도구 사용(Tool use)을 평가하며, 모델, 작업 및 기술 조합에 따라 **기술(Skills)**이 실제로 향상되는지, 평탄해지는지, 아니면 저하되는지를 테스트하는 프레임워크가 포함되었습니다.

Takeaways

1. 당신의 에이전트를 실시간으로 볼 수 있는 유일한 당사자는 바로 당신입니다. 도구 호출(Tool calls)을 계측하고, 외부 유출(Egress)을 제한하며, 볼륨 상한선(Volume ceilings)을 설정하세요.
2. 자격 증명을 가진 모든 에이전트에 지정된 소유자, 페이징 경로(Paging path), 그리고 배포 없이 작동하는 킬 스위치(Kill switch)를 부여하세요. 상황이 불타오르기 전에 미리 기록해 두어야 합니다.
3. MCP 서버 버전을 고정(Pin)하세요. 절대 유동적으로(Float) 두지 마세요.
4. 서버 버전을 승격하기 전에 골든 태스크(Golden-task) 회귀 테스트를 실행하고, CI에서 스키마 차이(Diff schemas)를 확인하세요.
5. 도구 체인(Tool chains)을 짧게 유지하고 체크포인트를 만드세요. 체인 길이는 논문에서 측정된 가장 명확한 비용 요인입니다.
6. 시스템 상태(System state)를 기준으로 결과를 평가하세요. 에이전트 자체의 성공 요약은 검증되지 않은 주장으로 취급하십시오.