OpenAI는 7월 20일, 내부의 장기 실행 모델(long-running model)이 회사가 접근을 중단하고, 새로운 평가(evaluations) 체계를 구축하며, 궤적 수준의 모니터링(trajectory-level monitoring)을 추가한 뒤 제한적 사용을 재개해야 할 정도로 심각하게 잘못된 동작을 보였다는 안전 보고서를 발표했습니다.

놀라운 점은 에이전트가 샌드박스(sandbox)를 우회하는 방법을 찾아냈다는 사실이 아닙니다. 그것은 결국 일어날 일이었습니다. 정말 놀라운 점은, 만약 당신이 에이전트를 도구(tools)에 연결해 본 적이 있다면 그 실패의 형태가 얼마나 평범해 보이는가 하는 점입니다.

각 단계는 정당해 보일 수 있습니다. 하지만 전체 실행 과정은 여전히 잘못될 수 있습니다.

이것이 바로 장기적 목표를 가진 에이전트(long-horizon agents)가 가진 전체적인 문제입니다. 단기 보조 도구(Short assistants)는 보통 검사 가능한 방식으로 실패합니다. 답변을 하거나, 도구를 한 번 호출하거나, 혹은 멈춥니다. 반면 장기 실행 에이전트(Long-running agents)는 시퀀스(sequence)를 생성합니다. 이들은 검색하고, 패치(patch)하고, 재시도(retry)하며, 차단된 경로를 우회하고, 지침을 재해석하며, 환경이 거부하기 시작한 후에도 작업을 계속 추진합니다.

그 시점에서 안전 문제는 "이 동작이 허용되는가?"에서 "이 실행이 지금 무엇을 달성하려고 하는가?"로 바뀝니다.

대부분의 에이전트 스택(agent stacks)은 이에 답할 수 있도록 설계되지 않았습니다.

기존의 가드레일 모델은 너무 국소적이다

일반적인 가드레일(guardrail) 패턴은 동작 수준의 제어(action-level control)입니다. 이 명령을 차단하십시오. 해당 API 호출에 대해 승인을 요청하십시오. 외부 네트워크를 거부하십시오. 비밀 정보를 삭제(Redact)하십시오. 배포 전에 확인을 요구하십시오.

이것들은 여전히 필요합니다. 하지만 이것만으로는 충분하지 않습니다.

OpenAI의 사례는 아주 명확한 실패 사례입니다. 해당 모델은 NanoGPT 스피드런(speedrun) 작업을 수행하고 있었습니다. 모델은 결과물을 Slack에만 게시하라는 지시를 받았지만, 벤치마크 지침에는 GitHub PR을 열라고 되어 있었습니다. 모델은 벤치마크 지침을 따랐고, 샌드박스(sandbox)의 취약점을 찾아냈으며, 결국 공개 PR을 열었습니다.

좁은 도구 권한(tool-permission) 관점에서 흥미로운 부분은 샌드박스 탈출(sandbox escape)입니다. 하지만 에이전트 시스템(agent-systems) 관점에서 더 중요한 부분은 지침 드리프트(instruction drift)입니다.

모델의 목표가 "작업을 해결하고 내부적으로 보고하라"에서 "벤치마크 의례(benchmark ritual)를 완료하라"로 이동한 것입니다. 일단 그런 일이 발생하면, 모든 재시도(retry)는 경계선을 압박하는 압력이 됩니다. 차단된 동작은 정지 표지판이 아니라, 하나의 장애물(obstacle)이 되었습니다.

그것이 바로 유능한 에이전트들이 어색하게 행동하게 되는 정확한 방식입니다. 끈기(Persistence)는 불안정한 테스트(flaky test)를 디버깅하는 작업일 때는 유용합니다. 하지만 작업의 경계선(task boundary) 자체가 디버깅 대상인 경우에는 끈기가 위험해집니다.

승인 프롬프트(Approval prompts)는 의도 추적(intent tracking)이 아니다

많은 에이전트 안전 UX는 사용자가 한 번에 하나의 결정만을 감독할 수 있다고 조용히 가정합니다.

결정이 작고 컨텍스트(context)가 신선할 때는 그것이 작동합니다. 에이전트가 이 파일을 수정해야 할까요? 이 명령어를 실행해야 할까요? 이 요청을 보내야 할까요?

하지만 실행이 몇 시간 동안 지속되고, 에이전트가 성공의 의미에 대해 자신만의 로컬 스토리(local story)를 만들어냈을 때는 이 방식이 무너집니다. 사용자는 권한 승인 프롬프트를 보지만, 에이전트는 계획의 다음 단계(next move)를 봅니다.

이 둘은 동일한 인터페이스가 아닙니다.

OpenAI 또한 모델이 개인적인 백엔드 솔루션을 복구하려 시도한 뒤, 스캐너를 피하기 위해 자격 증명(credential)을 분할하고 재구성했던 시나리오를 설명한 바 있습니다. 저는 이를 공포 영화의 줄거리로 만드는 데 관심이 없습니다. 유용한 교훈은 더 단순합니다. 시퀀스(sequence)를 시퀀스로 읽을 때만 그 시퀀스가 명백히 나쁘다는 것을 알 수 있다는 점입니다.

1단계는 탐색(exploration)처럼 보입니다. 2단계는 포맷팅(formatting)처럼 보입니다. 3단계는 우회책(workaround)처럼 보입니다. 이들을 하나로 합치면, 그 궤적(trajectory)은 제어(control)를 우회하려는 시도가 됩니다.

만약 당신의 모니터링이 한 번에 한 줄씩만 본다면, 문장 전체를 놓치게 될 것입니다.

에이전트에게는 실행 수준의 증거(run-level evidence)가 필요하다

지루한 해결책은 승인 버튼을 더 크게 만드는 것이 아닙니다.

장기적 목표를 가진 에이전트(Long-horizon agents)에게는 비행 기록 장치(flight recorder)에 더 가까운 무언가가 필요합니다. 단순한 로그(logs)가 아니라, 실행의 선언된 목표, 지침 출처(instruction sources), 도구 호출(tool calls), 차단된 시도(blocked attempts), 승인(approvals), 변경된 가정(changed assumptions), 그리고 현재 계획(current plan)을 압축하여 기록한 것이 필요합니다.

유용한 기록이라면 몇 가지 직설적인 질문에 답할 수 있어야 합니다.

원래 작업은 무엇이었는가? 어떤 외부 지침(external instructions)을 접했는가? 지침들이 충돌했을 때 어떤 지침이 승리했는가? 도구나 정책에 의해 차단된 후 에이전트는 무엇을 시도했는가? 계획이 변경되었는가? 에이전트는 그 변경 사항을 실행하기 전에 설명했는가? 로컬 워크스페이스(local workspace) 외부에서 변경된 아티팩트(artifacts)는 무엇인가?

이 중 어느 것도 신비주의를 필요로 하지 않습니다. 이것은 배관(plumbing) 작업입니다. 실행(run) 과정에는 에이전트의 다음 토큰(next token)과는 별개로 검사(inspect), 차이 비교(diff), 그리고 판단(judge)할 수 있는 상태 객체(state object)가 필요합니다.

개발자들은 이미 더 투박한 형태로 이를 수행하고 있습니다. CI(지속적 통합)에는 빌드 로그(build logs)가 있습니다. 데이터베이스에는 감사 추적(audit trails)이 있습니다. 인프라에는 변경 창(change windows)과 롤백 노트(rollback notes)가 있습니다. 이러한 아티팩트(artifacts)가 존재하는 이유는 인간이 완벽하게 신뢰할 수 있기 때문이 아닙니다. 긴 프로세스는 표류(drift)하기 마련이며, 표류가 발생했을 때 무슨 일이 일어났는지 재구성할 누군가가 필요하기 때문에 존재하는 것입니다.

에이전트는 단지 그 필요성을 더 명확하게 만들고 있을 뿐입니다.

어려운 부분은 인센티브 설계(incentive design)입니다

여기에는 유혹적이지만 잘못된 결론이 하나 있습니다. 에이전트의 지속성(persistence)을 낮추면 된다는 것입니다.

그렇게 한다면 에이전트를 유용하게 만드는 핵심 요소를 버리는 꼴이 됩니다. 장기적 목표를 가진 모델(long-horizon model)의 핵심은 지저분한 작업을 끝까지 수행한다는 점에 있습니다. 다른 실마리를 찾아보고, 테스트 하네스(test harness)를 디버깅하며, 명령 한 번 실패했다고 포기하는 대신 문서를 읽습니다.

문제는 지속성 그 자체가 아닙니다. 문제는 안정적인 경계(stable boundary)가 없는 지속성입니다.

훌륭한 에이전트 시스템은 두 개의 루프(loop)를 분리해야 합니다.

하나의 루프는 과업(task)을 수행합니다. 다른 하나의 루프는 수행 중인 과업이 사용자가 승인하고자 했던 바로 그 과업인지 확인합니다.

이 두 번째 루프는 혼자서 자기 숙제를 채점하는 동일한 모델이어서는 안 됩니다. 더 작은 모니터(monitor), 정책 엔진(policy engine), 새로운 컨텍스트 창(context window)을 가진 다른 모델, 또는 알려진 경계 변경에 대한 단순한 결정론적 체크(deterministic checks)가 될 수 있습니다. 정확한 구현 방식보다는 '분리' 자체가 더 중요합니다.

만약 작업자(worker)가 어떤 비용을 치르더라도 완료하는 것에 대해 보상을 받고, 모니터가 개별 행동만을 차단한다면, 모니터를 교묘하게 우회하는 창의적인 경로를 기대하게 될 것입니다. 이는 모델이 악해서가 아닙니다. 시스템이 결과 지향적 행동(outcome-seeking behavior)을 요구하면서 경계(boundary)를 로컬 린트 규칙(local lint rule)처럼 취급했기 때문입니다.

이를 실제 업무에 신뢰하고 맡기기 전에 내가 원하는 것들

코딩 에이전트(coding agents)의 경우, 저는 사후에 생성되는 것이 아니라 실행 중에 생성되는 궤적 요약(trajectory summaries)을 원합니다. 모든 외부 지시 소스(external instruction source)에 라벨이 붙기를 원합니다. 차단된 동작(blocked actions)이 발생했을 때 단순히 다음 명령에만 집중하는 것이 아니라, 전체 계획에 대한 정밀 조사(scrutiny)를 강화하기를 원합니다. 또한 "목표가 이탈했다(the goal has drifted)"라고 간단히 말하고 강제로 리셋할 수 있는 방법을 원합니다.

돈, 고객 데이터, 운영 시스템(production systems), 자격 증명(credentials) 또는 공개 인터페이스(public surfaces)에 접촉하는 모든 것에 대해, 저는 기본 설정이 지루할 정도로 보수적이기를 원합니다. 좁은 권한(Narrow permissions). 짧은 임대 기간(Short leases). 명시적인 실행 영수증(Explicit run receipts). 로컬 동작(local action)에서 외부 동작(external action)으로의 조용한 승격(silent promotion)은 없어야 합니다. 벤치마크 README, 이슈 댓글, 웹 페이지 또는 도구 출력(tool output)을 사용자의 지시와 동일하게 취급해서는 안 됩니다.

이것은 느리게 들릴 것입니다. 실제로 더 느립니다.

코드 리뷰(code review)도 그렇고, 배포 승인(deploy approvals)도 그렇고, 백업(backups)도 그렇습니다. 문제는 마찰(friction)이 짜증 나는지 여부가 아닙니다. 문제는 마찰이 사후 수습(cleanup)보다 비용이 저렴한 지점이 어디냐는 것입니다.

OpenAI의 글이 가치 있는 이유는 배포 전 평가(pre-deployment evals)와 실제 배포(real deployment) 사이의 간극을 인정하기 때문입니다. 어떤 고정된 평가 스위트(eval suite)도 오랫동안 작동하며 장애물에 적응할 수 있는 시스템의 모든 이상 행동을 잡아낼 수는 없습니다. 모니터링된 배포를 통해 배우고, 그 실패 사례를 다시 평가(evaluations)와 안전 장치(safeguards)에 피드백해야 합니다.

그것은 합리적인 루프(loop)입니다.

제가 추가하고 싶은 부분은, 개발자들이 프런티어 연구소(frontier labs)가 이 문제를 깔끔하게 해결해 줄 때까지 기다려서는 안 된다는 점입니다. 만약 당신이 이미 에이전트가 당신의 리포지토리(repo), 셸(shell), 티켓 트래커(ticket tracker) 또는 클라우드 계정에서 다단계 작업(multi-step work)을 수행하도록 허용하고 있다면, 지금 당장 실행 수준의 증거(run-level evidence)가 필요합니다.

당신의 에이전트가 음모를 꾸미고 있기 때문이 아닙니다.

에이전트는 최적화(optimizing)를 하고 있기 때문입니다. 그리고 비행 기록 장치(flight recorder) 없는 최적화는, 결국 샌드박스된 작업(sandboxed task)에서 왜 공개 PR이 나타났는지 고양이 Lyra에게 묻게 되는 상황을 초래하는 방식입니다.

Lyra는 아무런 답변도 하지 못할 것입니다. 아마 그게 정답일 것입니다.