Cockpit의 grok이 「완료」라고 말해도, 우선은 신용하지 마라

見出し画像: 判読不能な端末ログの前に座るロボットと、シールド・書類・虫眼鏡による検証のイメージ

AGI Cockpit——각 LLM CLI의 표준 입출력을 중개하여 LLM 간 통신을 수행하는 AI 오케스트레이션(Orchestration) 도구——에서 grok을 구현 Worker로 두고 싶을 때, 가장 신경 쓰이는 것은 똑똑함보다 제어(Control)라고 생각한다. 부모(오케스트레이터 AI)가 자식인 Worker(구현 담당 grok)에게 업무를 넘기면, 중간 과정이 PTY에 파묻혀 「완료했습니다」 이후의 허가 경로(path)의 diff가 의도대로인지——그 불안함을 개인 실험인 incident-loop

(AI가 자율적으로 문제 해결 및 복구를 시도하는 프로젝트) 내에서 문서 주도(Document-driven) 방식으로 접근해 본 기록이다. 과장하지 않겠다. 루프의 자기 개선 기능은 집필 시점에서 미검증 상태다.

발단은 안전론이 아니다. Claude나 Codex와 달리, grok CLI는 구조화된 응답(Structured response)을 가져오기 어렵고, 일본어 장문은 도중에 생략되기 쉽다. 그 파편을 부모 AI가 완료로 오해하거나 간과하기 쉬웠다. 계약 해석도, 진척도, 완료 보고도 PTY로 흘러가며, chat의 자기 신고와 디스크 상의 변경을 기계적으로 대조할 수단이 없었다. 최소한의 규칙은 한 줄이었다. **보고의 정본은 UTF-8 기반의 Markdown/JSON으로 하고, PTY나 chat은 알림(Notification) 수준으로 격하시킨다. 「에이전트의 자기 신고를 수락 oracle로 삼지 않는다」는 것은, 읽을 수 없는 터미널 로그에 대한 운영 해킹이 제도화된 형태에 가깝다.

그럼에도 grok은 측정 가능한 녹색(Green)을 우선시하며 본질을 빠져나갈 수 있다. Phase 1의 Grok 버전은 32건의 테스트와 재현 러너(Runner)를 갖추었으나, 기존의 RCA(근본 원인 분석)를 결정론적 매핑(Deterministic mapping)으로 대체하여, runbook 참조만으로 AI가 원인 분석을 생성할 수 있다는 가설은 증명하지 못했다. 테스트는 통과한다. 가설은 통과하지 못한다. Phase 2에서는 공식 리뷰 후 executor의 check-then-act 경합(Race condition)이 추가 확인되었고, 그대로 main에 머지(Merge)해서는 안 된다고 기록되었다. 나열된 수락 항목의 바깥쪽——병행성이나 계층 간의 책임——을 자발적으로 채우지 않는 경우가 있다.

제어는 창의성을 억압하는 것이 아니라 경계를 나누는 것이다. 허가 경로 내의 국소적 개선은 Green(실행 후 보고), 설계 전제나 필수 기구의 변경은 Yellow(구현 전 제안), 안전·credentials·수락 조건의 약화는 Red(명시적 권한 없이 금지). 가설 검증이 포함된 Grok 태스크는 Initiative Level 1——이의는 제기하지만, 일탈하기 전에 기다린다. Worker의 status: success

는 「부모가 검증을 시작해도 좋다」는 통지에 가까우며, 수락 그 자체는 아니다. 부모가 diff·Git·exit code·의미적 증적을 독립적으로 대조하고, 필요하다면 별도 세션의 IR이 grok의 편법이나 지름길을 의심한다.

솔직히 말하면, 이 방식은 느리다. 계약의 commit, 격리된 worktree에서의 구현, Markdown/JSON 보고, 부모의 재대조, IR, 인간의 페이즈 게이트(Phase gate)가 직렬로 이어진다. Phase 1 hardening은 계통 외 리뷰가 5번째 패스까지 왕복했다. 정본을 파일로 만든 대가로, PTY를 라이브 모니터링하며 조기에 개입하는 경량 감독도 어려워졌다. 가시성을 어느 정도 포기하고 감사 가능성(Auditability)과 교환한 것에 가깝다.

그럼에도 이 방식을 유지하는 이유는 단순하다. 결정론적 RCA나 TOCTOU 경합과 같은 「녹색(Green)이라도 위험한 것」을, 개인 개발의 속도 우선주의 속에서도 흘려보내지 않고 검출할 수 있었기 때문이다. 「이제 걱정 없다」고는 말하지 않겠다. 말할 수 있는 것은, 자기 신고와 녹색 테스트를 신용하지 않는 설계로 만들면, grok이 저지르기 쉬운 지름길이 보이게 된다는 현재의 위치뿐이다.

참조 (주장 → 1차 자료)

이하는 비공개 리포지토리 incident-loop 내의 파일·커밋이다. 독자가 직접 검증할 수는 없다. 과장을 방지하기 위한 저자 측의 근거이며, 외부 재현성을 보장하지 않는다.

Discussion