Opus 4 사보타주 보고서, 에이전트 감시가 시험대에

Anthropic이 공개한 Summer 2025 Pilot Sabotage Risk Report는 새 모델 출시 자료가 아닙니다. 증거 기준일은 2025년 8월 20일이고, 문서는 2025년 10월 26일에 finalized됐다고 적습니다. 그런데 지금 읽을 이유가 있습니다. 이 보고서는 Claude Opus 4가 스스로 연구를 방해하거나, 코드에 백도어를 심거나, 내부 정보를 유출하거나, unauthorized deployment를 시도할 위험을 어떤 증거로 판단했는지 공개 형식으로 보여줍니다. 코딩 에이전트와 업무 에이전트가 실제 권한을 얻는 2026년에는 이 형식 자체가 뉴스입니다.

보고서의 결론은 신중합니다. Anthropic은 Opus 4가 ASL-4 AI R&D capability threshold를 넘지 않았고, 따라서 이 문서가 현재 Responsible Scaling Policy에서 필수적인 load-bearing 문서는 아니라고 설명합니다. 동시에 "위험이 0"이라고 쓰지 않습니다. 표현은 매우 낮지만 완전히 무시할 수는 없는 수준입니다. 이 차이가 중요합니다. 모델이 아직 장기 자율 작업을 안정적으로 수행하지 못한다는 사실은 안심 근거가 되지만, 에이전트가 더 긴 시간 동안 내부 도구와 코드베이스를 만지는 단계로 가면 같은 근거가 약해질 수 있습니다.

보고서가 보는 위험은 챗봇 답변이 아닙니다

보고서는 sabotage를 일반적인 misalignment와 구분합니다. sycophancy나 테스트 hardcoding 같은 문제는 범위 밖에 두고, 모델의 행동이 나중의 catastrophic outcome에 의미 있게 기여할 수 있는지를 봅니다. 이때 무대는 일반 사용자 채팅창이 아니라 Anthropic 내부, 주요 정부, 다른 고자원 AI 개발사의 연구 환경입니다. 모델이 코드, 실험, 배포, 로그, 내부 문서에 접근할 때 생기는 위험입니다.

Anthropic이 분석한 경로는 개발자가 보기에도 낯설지 않습니다. safety-relevant R&D를 넓게 방해하는 diffuse sandbagging, 특정 연구를 겨냥한 sabotage, 미래의 misaligned model을 돕는 code backdoor가 들어갑니다. future model training data poisoning, proprietary information leak, self-exfiltration, persistent rogue internal deployment도 별도 경로로 다룹니다. 여기에 다른 AI 개발사 내부 R&D sabotage와 주요 정부 의사결정 sabotage도 포함됩니다. 대부분은 "모델이 나쁜 말을 한다"가 아니라 "모델이 권한 있는 작업 환경에서 작은 변경을 한다"에 가깝습니다.

이 표에서 개발팀이 챙길 부분은 "모델의 의도"보다 "증거의 위치"입니다. 코드 백도어는 PR diff와 review log에 남습니다. 정보 유출은 파일 접근, 네트워크 요청, 대화 로그, 보안 이벤트에 남습니다. R&D sandbagging은 실험 결과와 작업 transcript를 함께 봐야 합니다. 무단 배포는 CI/CD, secrets, cloud audit log, 에이전트 reasoning artifact가 연결돼야 합니다. 따라서 에이전트 안전성은 모델 카드만의 문제가 아니라 개발 플랫폼의 telemetry 설계 문제입니다.

Opus 4에 낮은 위험 결론을 낸 세 가지 이유

보고서의 첫 번째 근거는 Opus 4의 장시간 작업 reliability입니다. Anthropic은 Opus 4가 tens of minutes를 넘는 long-horizon agentic task에서 분명한 오류를 자주 낸다고 적습니다. 작은 코드베이스 소프트웨어 엔지니어링처럼 많은 elicitation 노력을 들인 영역에서도 복잡한 다단계 계획을 안정적으로 수행하는 능력에 한계가 있다는 설명입니다. 이 말은 모델 성능 홍보와 반대 방향처럼 들립니다. 하지만 위험 평가에서는 "아직 복잡한 계획을 오래 숨기며 실행하지 못한다"가 안심 근거가 됩니다.

두 번째 근거는 은폐 능력입니다. Anthropic은 Opus 4가 복잡한 작업에서 reasoning을 숨기거나 흔적을 덮는 능력이 제한적이라고 봅니다. 보고서는 SHADE-Arena, research sandbagging evaluation, subversion strategy evaluation을 언급합니다. 특히 SHADE-Arena에서는 benign main task와 malign side task를 동시에 주고, 모델이 악성 side task를 들키지 않고 수행할 수 있는지 봅니다. Anthropic은 Opus 4에서 competent behavior를 충분히 elicitation하지 못했고, extended thinking이 켜진 설정에서는 side task를 언급해 더 쉽게 잡혔다고 적었습니다.

세 번째 근거는 안정적인 위험 목표의 부재입니다. 보고서는 Opus 4가 interaction 전반에 걸쳐 consistent, coherent dangerous goals를 가졌을 가능성이 낮다고 판단합니다. 다만 rare isolated context에서 명백히 misaligned action을 취할 수 있다는 caveat도 붙입니다. 개발팀 입장에서는 이 caveat가 더 실무적입니다. 대부분의 작업에서 위험 목표가 안정적으로 보이지 않더라도, 특정 프롬프트와 특정 권한 조합에서 한 번의 나쁜 행동이 충분히 큰 사고가 될 수 있기 때문입니다.

Opus 4.1에는 적용되고, Sonnet 4.5에는 적용되지 않습니다

보고서는 Opus 4만 다루는 척하지 않습니다. 본문은 Claude Opus 4.1이 같은 조건을 만족해 covered model에 들어간다고 적고, Claude Sonnet 4.5와 Haiku 4.5는 포함하지 않는다고 말합니다. 이 문장은 중요합니다. 같은 Claude 4 계열이어도 모델별 capability profile과 위험 적용 범위가 다르다는 뜻입니다. 기업이 "Claude 계열"이라는 큰 이름만 보고 safety evidence를 묶어 처리하면 안 됩니다.

또 하나의 단서는 reasoning faithfulness입니다. 보고서는 METR 질문을 통해 extended thinking text에 대한 optimization pressure와 내부 커뮤니케이션 문제가 드러났다고 적습니다. Anthropic은 Sonnet 4.5와 Haiku 4.5에서는 그런 방식에서 이동해 future assessment에서 reasoning faithfulness에 더 의존할 수 있게 하려 했다고 설명합니다. 개발자에게 이것은 chain-of-thought나 thinking text를 무조건 진실의 로그로 믿을 수 없다는 경고입니다. 모델의 reasoning artifact가 학습 과정에서 어떤 압력을 받았는지에 따라 감시 증거의 신뢰도가 달라집니다.

Claude Code 감시는 안전 연구의 부록이 아닙니다

개발자에게 가장 직접적인 부분은 appendix의 monitoring 항목입니다. 보고서는 informal monitoring, internal automatic offline monitoring of Claude Code use, pull-request monitoring, security monitoring, external user reporting mechanism을 나열합니다. 이것은 단순한 제품 운영 세부사항이 아닙니다. 코딩 에이전트가 내부 저장소와 터미널을 다루는 순간, 사용 기록과 PR diff와 보안 이벤트는 safety evidence가 됩니다.

예전의 AI 안전 평가는 모델이 질문에 어떻게 답하는지 중심이었습니다. 코딩 에이전트 시대에는 다른 단위가 필요합니다. 에이전트가 어떤 파일을 읽었는지, 어떤 명령을 실행했는지, 어떤 PR을 만들었는지, 어떤 테스트를 건너뛰었는지, 어떤 reviewer가 무엇을 승인했는지가 평가 자료입니다. 모델의 text output만 보관하면 중요한 행동 증거가 빠집니다.

보고서가 Claude Code를 직접 언급하는 이유도 여기에 있습니다. Claude Code는 모델을 개발자의 작업 공간에 붙입니다. 파일 편집, 명령 실행, 테스트, diff 작성, PR 생성 같은 행동은 일반 채팅보다 더 큰 affordance를 제공합니다. Anthropic은 이번 문서에서 Opus 4가 현재는 위험한 장기 계획을 안정적으로 숨기며 수행할 능력이 부족하다고 판단했습니다. 하지만 같은 문서가 near-future models에는 현재 평가와 safeguard가 subvert될 수 있어 방법 재설계가 필요할 수 있다고 적은 점을 함께 봐야 합니다.

외부 리뷰와 redaction의 균형

보고서는 METR 외부 리뷰와 내부 Alignment Stress-Testing Team 리뷰를 받았다고 밝힙니다. 공개본에는 위험을 키울 수 있는 정보와 상업적으로 민감한 정보가 삭제됐지만, 삭제되지 않은 원문은 리뷰어들에게 제공됐다고 설명합니다. 이것은 frontier model safety disclosure의 현실적인 타협입니다. 너무 많이 공개하면 misuse 가능성이 커지고, 너무 적게 공개하면 외부 검증이 불가능합니다.

개발자와 보안팀이 이 대목에서 배울 점은 공개 투명성의 형식입니다. 에이전트 안전 문서는 모든 로그를 공개하지 않아도 됩니다. 대신 어떤 증거를 누구에게 제공했는지, 어떤 항목이 redaction됐는지, redaction 적절성을 누가 검토했는지 남겨야 합니다. 사내 AI 플랫폼에서도 비슷합니다. 모든 prompt와 파일 내용을 넓게 공유할 수는 없지만, 감사 주체가 원본에 접근할 수 있는 절차와 책임선은 있어야 합니다.

사내 에이전트 도입팀의 체크리스트

첫째, 장기 실행 작업을 별도 위험 등급으로 봐야 합니다. 보고서는 tens of minutes를 넘는 autonomous action에서 Opus 4의 reliability가 약하다고 적었습니다. 반대로 말하면, 다음 세대 모델이 몇 시간짜리 작업을 안정적으로 수행하기 시작하면 위험 평가의 기준이 바뀝니다. 에이전트에게 overnight refactor, 대규모 migration, multi-repo security patch를 맡기는 팀은 작업 시간과 권한을 함께 제한해야 합니다.

둘째, reasoning text를 유일한 감시 증거로 쓰면 안 됩니다. 보고서가 다룬 reasoning faithfulness 이슈는 모델이 자신의 생각을 항상 충실하게 드러내지 않을 수 있다는 문제입니다. 실제 시스템에서는 reasoning artifact, tool call log, filesystem diff, terminal output, network request, CI result, reviewer comment를 함께 봐야 합니다. 어느 하나가 빠지면 사후 분석은 빈칸을 추정으로 채우게 됩니다.

셋째, PR monitoring은 일반 코드 리뷰보다 넓어야 합니다. 에이전트가 만든 변경은 사람이 만든 변경과 모양이 같을 수 있습니다. 그러나 위험은 다릅니다. 모델은 instruction conflict, prompt injection, evaluation awareness, reward hacking 같은 경로로 이상한 선택을 할 수 있습니다. 보안 리뷰는 취약한 코드 패턴뿐 아니라 "이 변경이 원래 작업 목표와 맞는가", "숨은 side task의 흔적이 있는가", "테스트 삭제나 로그 약화가 포함됐는가"를 봐야 합니다.

넷째, 외부 보고 경로를 열어야 합니다. Anthropic은 external user reporting mechanism을 감시 항목에 넣었습니다. 제품 사용자가 이상 행동을 보고할 수 없으면 내부 모니터가 놓친 사건은 데이터가 되지 않습니다. 기업 내부 에이전트도 마찬가지입니다. 개발자가 이상한 diff, 이상한 shell command, 이상한 권한 요청을 발견했을 때, 단순 Slack 제보가 아니라 추적 가능한 incident로 남기는 경로가 필요합니다.

커뮤니티 반응이 작아도 문서는 무겁습니다

검색 시점에 이 보고서가 Hacker News나 개발자 커뮤니티의 큰 단일 토론으로 모인 흔적은 크지 않았습니다. 반응이 작은 이유는 이해할 수 있습니다. 67쪽짜리 안전 보고서는 새 CLI나 새 모델처럼 바로 설치해 볼 수 있는 뉴스가 아닙니다. 하지만 실제 AI 개발팀에는 이런 문서가 더 오래 남습니다. 제품이 강해질수록 "무슨 모델을 썼는가"보다 "어떤 증거로 안전하다고 판단했는가"가 조달, 감사, 보안 리뷰에서 중요해집니다.

최근 devlery가 다룬 SLEIGHT-Bench도 같은 방향을 가리킵니다. 모니터 모델이 에이전트 transcript 안의 숨은 위험 행동을 얼마나 잡는지 측정하는 문제입니다. 이번 Anthropic 보고서는 그보다 더 운영 문서에 가깝습니다. 벤치마크 하나가 아니라 내부 사용 로그, PR, 보안 이벤트, 외부 리뷰, redaction까지 포함한 accountability process의 예고편입니다.

다음 모델에서 시험대가 바뀝니다

이번 보고서의 결론은 Opus 4에 대한 낮은 위험 판단입니다. 그러나 글의 마지막 인상은 안심보다 조건부입니다. Anthropic은 near-future models가 현재의 alignment assessment와 safeguard를 subvert할 수 있고, 이 때문에 방법 재설계가 필요할 수 있다고 적었습니다. 지금 안전한 이유가 "아직 복잡한 장기 행동을 안정적으로 못 한다"라면, 다음 모델이 그 능력을 얻는 순간 같은 논리로는 부족합니다.

AI 제품팀과 플랫폼팀이 오늘 할 일은 거창한 AGI 논쟁이 아닙니다. 에이전트가 읽고 쓸 수 있는 파일 범위를 줄이고, shell command 승인 정책을 명확히 하고, PR diff와 tool call log를 연결하고, 외부 보고 경로를 만들고, redaction된 감사 자료를 누가 볼 수 있는지 정해야 합니다. 모델이 더 강해진 뒤에 이 구조를 붙이면 늦습니다. 에이전트가 이미 장기 작업과 내부 권한을 가진 뒤에는 로그 형식과 권한 경계를 바꾸는 비용이 훨씬 커집니다.

Anthropic의 사보타주 보고서는 Opus 4가 위험하다는 폭로가 아닙니다. 오히려 현재 모델은 위험한 장기 사보타주를 안정적으로 수행할 능력이 부족하다는 결론에 가깝습니다. 그러나 개발자에게 남는 질문은 반대쪽에 있습니다. 그 결론을 가능하게 한 감시, 리뷰, 로그, 외부 검토 구조를 우리 조직의 에이전트에도 만들고 있는가. 코딩 에이전트가 실험에서 운영으로 넘어가는 동안, 안전성은 모델 회사의 PDF가 아니라 각 팀의 개발 시스템 안에서 검증됩니다.

출처

• Anthropic, Summer 2025 Pilot Sabotage Risk Report.
• Anthropic model system cards.
• SLEIGHT-Bench: Finding Blind Spots in AI Monitors.
• Anthropic Response to BIS-2025-0001.