에이전트가 8시간 폭주한 뒤 — 자율이 기본값이 되자 '멈추는 능력'이 제품이 됐다

에이전트 하나가 8시간 동안 멈추지 않고 돌았다면, 그건 성실한 걸까요, 고장 난 걸까요?

oh-my-opencode v4.18.0의 릴리스 노트는 이 질문으로 시작해요. 실제 Codex 런 하나가 8시간 동안 계속 일을 만들어내며 돌았고, 메인테이너는 이걸 버그 하나가 아니라 설계 전체의 문제로 부검했어요. 그리고 같은 주에 Claude Code는 자율 실행을 기본값으로 풀었고, Google은 백그라운드 에이전트 실행을 API 표준 기능으로 넣었어요. 저는 이 세 발표를 겹쳐 놓으면 하나의 문장이 읽힌다고 봐요. 자율 실행이 기본값이 된 순간, 제품 경쟁력은 '시작하는 능력'에서 '멈추는 능력'으로 옮겨갔다는 거예요.

자율이 기본값이 된 증거 — 같은 주에 세 갈래로

첫째, Claude Code예요. v2.1.207부터 Auto 모드가 Bedrock, Vertex AI, Foundry에서 옵트인 없이 기본 제공돼요. v2.1.158부터 v2.1.206까지는 CLAUDE_CODE_ENABLE_AUTO_MODE=1을 직접 켜야 했는데, 이제 그 스위치 자체가 사라졌어요. 지난달 서브에이전트가 기본으로 백그라운드에서 돌게 된 것과 같은 패턴이에요. 옵션이 하나씩 기본값으로 승격되고 있어요.

둘째, Gemini예요. Google이 Managed Agents 확장을 발표하면서 background: true 한 줄로 에이전트를 서버에서 통째로 굴릴 수 있게 했어요. API가 ID만 즉시 돌려주고, 클라이언트는 접속을 끊어도 에이전트는 클라우드 샌드박스에서 계속 돌아요. 문서 기준으로 상호작용 한 번에 보통 10만~300만 토큰을 소비한다고 해요. "사람이 지켜보는 동안 실행"이라는 전제가 API 설계에서 빠진 거예요.

셋째, oh-my-opencode예요. 8시간 폭주의 원인 분석이 흥미로운데, 단일 버그가 아니었어요. 메인 에이전트 모델이 멈춤을 기본으로 취급하지 않았고, 작업 프롬프트는 계속 도움을 소환하도록 설계돼 있었고, 서브에이전트도 각자 계속 돌았고, 이 힘들이 결합되자 수명 제어가 불가능해졌다는 거예요. 성실함이 쌓여서 사고가 된 거죠.

그래서 다들 '멈추는 장치'를 만들고 있어요

재미있는 건, 자율을 기본값으로 푼 바로 그 릴리스들이 동시에 울타리를 쌓고 있다는 점이에요. 세 프로젝트의 접근이 서로 달라서 스펙트럼이 보여요.

Claude Code는 런타임 감독이에요. Auto 모드는 권한 프롬프트를 없애는 대신 별도의 분류기 모델이 모든 액션을 실행 전에 검토해요. curl | bash류 다운로드-실행, 외부로의 데이터 반출, 프로덕션 배포, 강제 푸시 같은 건 기본 차단이고, 분류기가 3회 연속 또는 누적 20회 차단하면 Auto 모드가 스스로 꺼지고 다시 사람에게 물어보는 폴백이 있어요. 이 임계값은 설정으로 못 바꿔요. 저장소에 체크인된 설정 파일로는 Auto 모드를 켤 수 없게 막은 것도 같은 맥락이에요. 악성 레포가 스스로 권한을 승격하는 경로를 차단한 거죠.

Gemini는 사후 제어예요. 돌아가는 백그라운드 상호작용을 멈추는 수단은 cancel 엔드포인트와 삭제뿐이고, 커스텀 함수 호출이 필요할 때 requires_action 상태로 일시정지하는 게 유일한 사람-개입 지점이에요. 문서를 뒤져봐도 최대 실행 시간이나 승인 게이트, 체크포인트 같은 건 아직 없어요.

oh-my-opencode는 사전 계약이에요. 이제 모든 작업 의도 선언에 "이 턴을 끝내는 관찰 가능한 조건"을 반드시 적어야 하고, 서브에이전트를 띄울 때도 GOAL, STOP WHEN, EVIDENCE 세 파라미터로 계약을 명시해야 해요. 정지 조건이 충족되면

추가 검증 루프도, 마무리 다듬기도, 보너스 리팩토링도 없이 즉시 멈추라

는 규칙까지 명문화했어요. 에이전트의 과잉 성실함을 명시적으로 금지한 거예요.

지난달에 저는 코딩 에이전트 경쟁이 "사람이 안 보는 동안 알아서 도는 법"으로 옮겨갔다고 썼어요. 이번 주 릴리스들은 그 다음 단계예요. 알아서 도는 게 당연해졌으니, 이제 알아서 멈추는 것이 차별화 지점이 된 거예요.

이렇게 볼 수도 있어요

세 가지 유보를 남겨야 공정해요. 첫째, oh-my-opencode의 정지 장치는 프롬프트 수준의 계약이지 하드 캡이 아니에요. 모델이 계약을 무시하면 막을 물리적 수단은 아니라는 뜻이에요. 둘째, Claude Code 분류기의 차단 성능("악성 행동을 막는다")은 Anthropic의 자체 설명이고, 제3자 검증은 아직 없어요. 셋째, 이걸 "벤더들이 선제적으로 안전을 설계했다"고 읽는 건 후한 해석이에요. 8시간 폭주 같은 사고가 먼저 있었고 장치는 사후에 왔다는 순서도 기억할 필요가 있어요.

한국 개발자 입장에서

실무적으로 세 가지를 짚을게요. 첫째, Bedrock이나 Vertex로 Claude Code를 쓰는 조직이라면 v2.1.207부터 Auto 모드가 기본 제공이에요. 조직 정책상 이게 부담스러우면 관리 설정의 disableAutoMode로 막을 수 있고, 이건 도입 품의 문서에 바로 들어가야 할 항목이에요. 둘째, 폭주는 안전 문제이기 전에 비용 사고예요. 상호작용 하나에 수백만 토큰을 쓰는 백그라운드 에이전트가 8시간 돌면 청구서가 어떻게 되는지는 토큰의 2%만 코드에 쓰인다에서 다룬 낭비 구조의 극단값이에요. 셋째, 에이전트를 업무 파이프라인에 올릴 때 벤더나 팀에 요구할 질문이 하나 늘었어요. "이 에이전트는 언제, 어떤 조건으로 멈추고, 멈췄다는 걸 어떻게 증명하나요?" 이 질문에 답이 없는 에이전트는 아직 업무용이 아니에요.

한 줄로 줄이면 이래요. 자율 실행의 다음 경쟁축은 지능이 아니라 정지 조건이에요. 시작 버튼은 다들 만들었고, 이제 제대로 된 정지 버튼을 가진 쪽이 이겨요.

---

근거가 된 소식: Claude Code v2.1.207, Expanding Managed Agents in the Gemini API, oh-my-opencode v4.18.0 — GPT-5.6 That Actually Knows When to Stop