에이전트 운영자 핸드북: 보이지 않는 것을 감독하는 법

자율 AI 에이전트 운영은 새로운 분야입니다. 엔지니어링도, 관리도, 운영도 아닌, 세 가지 모두를 요구하는 하이브리드 역할이에요. 에이전트가 충분히 오래 실행되어 코드 생성이 아닌 감독이 병목이 되는 순간, 운영자 역할이 등장합니다. 다섯 가지 책임이 이 역할을 정의하고, 감독 스택이 이를 구현하며, 개입 프레임워크가 언제 행동할지 결정해요.

이 직무를 위한 교육을 받은 사람은 아무도 없습니다. 가르치는 학과도 없고, 정확히 설명하는 채용 공고도 없어요. 한 달 전에는 Python를 작성하다가, 다음 달에는 Python를 작성하고, API를 호출하고, 파일 시스템을 수정하고, 여러분이 자는 동안 아키텍처 결정을 내리는 자율 시스템을 관리하게 됩니다. Ralph 루프가 제 인프라에서 이 역할을 만들어냈어요. Claude Code를 새로운 컨텍스트로 재시작하고, 파일 시스템 상태를 읽고, 야간 세션에 걸쳐 작업을 이어가는 셸 스크립트입니다. 에이전트를 자율적으로 운영하는 모든 팀이 독립적으로 같은 역할을 발견했어요. 단일 대화형 세션보다 오래 운영할 때마다 같은 문제가 나타나기 때문입니다.

이 역할에는 확립된 이름이 없습니다. “AI ops”라고 부르는 팀도 있고, 플랫폼 엔지니어링에 포함시키는 팀도 있어요. 훅을 한 번도 작성해본 적 없는 엔지니어링 매니저에게 맡기는 경우도 있습니다. 이 모호함이 중요한 이유는, 역할을 잘못 파악하면 업무 배분도 잘못되기 때문이에요. 시스템 지식이 없는 엔지니어링 매니저는 손상된 에이전트 상태를 디버깅할 수 없습니다. 제품 판단력이 없는 플랫폼 엔지니어는 에이전트의 출력이 스펙의 의도에 부합하는지 평가할 수 없어요. 운영자 역할은 둘 다 요구합니다. 사양 결정(에이전트가 무엇을 만들어야 하는지, 어떤 제약을 부과할지)과 운영 실행(세션 모니터링, 장애 복구, 인프라 유지보수) 모두가 필요해요.

운영자의 다섯 가지 책임

1. 위임

위임이란 실행 시작 전에 에이전트 행동을 제약하는 사양을 작성하는 것입니다. 위임의 품질이 다른 어떤 요소보다 자율 출력의 품질을 결정해요.

CLAUDE.md 파일은 위임 산출물입니다. 프로젝트 관례, 금지 패턴, 필수 행동, 품질 기준을 세션 시작 시 에이전트가 읽는 문서로 인코딩해요.¹ PRD는 위임 산출물입니다. 에이전트가 완료를 보고하기 전에 검증할 수락 기준을 명시하죠. 작업 설명도 위임 산출물이에요. 작업 설명의 구체성이 에이전트의 결정 공간을 한정합니다.

부실한 위임은 지름길 나선을 만듭니다. 사양이 필수 단계를 열거하지 않았기 때문에 에이전트가 단계를 건너뛰는 거예요. 좋은 위임은 필수 단계를 명시적으로 만듭니다. 제 PRD에는 번호가 매겨진 수락 기준이 포함되어 있고, 각 기준은 관찰 가능한 산출물(파일 경로, 테스트 결과, 특정 동작)에 매핑돼요. 에이전트는 산출물을 생성하지 않고서는 기준을 완료로 표시할 수 없습니다. 관찰 가능한 결과를 명시하는 위임은 허상 완료라는 문제 전체를 제거해요.

핵심 기술은 무엇을 명시하고 무엇을 열어둘지 아는 것입니다. 과도한 명시는 예상치 못한 코드를 만났을 때 적응하지 못하는 취약한 에이전트를 만들어요. 부족한 명시는 승인하지 않은 아키텍처 결정을 내리는 에이전트를 만듭니다. 이 경계는 신뢰에 따라 움직여요. 강력한 훅으로 충분히 테스트된 에이전트는 첫 야간 세션을 실행하는 새 구성보다 더 넓은 재량권을 얻습니다.

2. 감독

감독이란 활성 세션을 모니터링하고, diff를 검토하고, 드리프트가 누적되기 전에 포착하는 것입니다.

드리프트가 핵심 위험이에요. 에이전트가 스펙에 맞춰 시작하고, 약간 벗어나는 합리적인 미시적 결정을 내린 다음, 그 편차를 기반으로 후속 결정을 내립니다. 여덟 번째 반복쯤이면 에이전트는 위임받은 것과 다른 문제를 풀고 있어요. 각각의 결정은 개별적으로 보면 합리적이었지만, 누적된 궤적은 목표를 벗어났습니다.

저는 두 가지 메커니즘으로 드리프트를 포착해요. 첫째, 훅이 하드 바운더리를 강제합니다. 차단된 명령, 필수 패턴, 금지된 파일 수정 등이죠. 훅은 에이전트가 진행하기 전에 실시간으로 위반을 포착해요. 둘째, 정기적인 로그 리뷰가 훅으로는 감지할 수 없는 소프트 드리프트를 포착합니다. 에이전트가 불필요하게 복잡한 접근 방식을 선택하거나, 스펙이 요청하지 않은 기능을 구축하거나, 병목이 아닌 코드 경로를 최적화하는 경우예요. 소프트 드리프트는 에이전트의 궤적이 운영자의 의도와 일치하는지 자동화된 검사로는 판단할 수 없기 때문에 인간의 판단이 필요합니다.

감독은 에이전트 수에 비례해서 확장되지 않아요. 하룻밤에 한 세션을 생성하는 에이전트 하나는 아침 커피를 마시며 검토할 수 있습니다. 하지만 다섯 개의 에이전트가 각각 여덟 번의 반복을 생성하면 마흔 개의 컨텍스트 윈도우 분량의 작업이 만들어져요. 우선순위 설정이 필수가 됩니다. 실패를 먼저 검토하고, 크리티컬 경로를 건드린 세션을 그다음에, 저위험 작업의 깨끗한 완료를 마지막에 검토하세요.

3. 개입

개입이란 작업 중인 에이전트를 언제 중지하고, 방향을 전환하고, 재시작할지 아는 것입니다.

네 가지 패턴이 개입을 요구해요.

에이전트가 루프에 빠졌을 때. 같은 오류가 연속 반복에 걸쳐 나타납니다. 에이전트가 약간의 변형으로 같은 수정을 시도해요. 각 반복은 전체 컨텍스트 윈도우를 소비하면서 아무런 진전도 만들지 못합니다. 개입 방법: 세션을 중지하고, 근본 원인을 수동으로 진단하고, 핸드오프 문서를 진단 내용으로 업데이트한 다음 재시작하세요.

에이전트가 테스트를 통과하는 잘못된 출력을 생성했을 때. 코드가 컴파일되고 테스트가 통과하지만 동작이 스펙의 의도와 맞지 않아요. 증거 게이트가 일부 사례를 포착하지만, 에이전트는 잘못된 동작에 대해 그럴듯한 정당화를 만들어낼 수 있습니다. 개입 방법: 올바른 동작을 캡처하는 실패하는 테스트를 작성한 다음 재시작하세요.

에이전트가 프로덕션이나 외부 시스템을 건드리려 할 때. 되돌릴 수 없는 결과를 가진 모든 작업(프로덕션 배포, 이메일 전송, 데이터베이스 수정, 유료 API 호출)에는 게이트가 필요합니다. 제 훅은 파괴적인 bash 명령과 외부 네트워크 호출을 차단해요. 어떤 게이트를 언제 열지는 운영자가 결정합니다.²

에이전트가 진전은 있지만 방향이 틀렸을 때. 작업은 유능하지만 정렬이 안 된 상태예요. 개입 방법: 중지하고, 핸드오프 문서에서 스펙을 명확히 한 다음 재시작하세요. 대화를 통해 세션 중간에 방향을 바꾸려 하지 마세요. 에이전트가 이미 잘못된 해석을 중심으로 멘탈 모델을 구축했기 때문에, 같은 컨텍스트 윈도우 내에서 중간 수정은 일관성 없는 출력을 만들어냅니다.

개입하지 않는 패턴: 에이전트가 올바른 목표를 향해 천천히 진전하고 있을 때. 그냥 실행되게 두세요.

4. 복구

복구란 장애 발생 후 처리하는 것입니다. 손상된 상태, 잘못된 브랜치, 깨진 빌드, 데이터 손실 등이 해당돼요.

에이전트 장애는 흔적을 남깁니다. 크래시된 세션이 부분적으로 작성된 파일, 잘못된 브랜치에 대한 커밋, 작업 디렉터리에 남겨진 임시 파일, 또는 후속 세션이 상속하는 수정된 설정을 남길 수 있어요. 복구는 재시작 전에 이러한 흔적을 되돌리는 것을 요구합니다.

제 복구 프로토콜은 이렇습니다. 피해를 파악하고(git status, git log, git diff), 세션 로그를 진단 데이터로 보존하고, 마지막으로 검증된 정상 커밋으로 되돌리고, 핸드오프 문서를 실패 원인과 이유로 업데이트한 다음, 수정된 제약으로 재시작해요. 부분적 작업이 명확히 올바르고 분리 가능하지 않은 한, 실패한 세션에서 부분적 작업을 살리려 하지 마세요. 핸드오프는 세션 경계를 넘어 실패 컨텍스트를 전달하여 다음 에이전트가 같은 실수를 반복하지 않게 합니다.

가장 위험한 복구 시나리오는 성공처럼 보이는 장애예요. 에이전트가 완료를 보고하고, 테스트가 통과하고, 빌드가 녹색이지만, 구현이 미묘하게 잘못된 경우입니다. 확신의 신기루 장애 모드가 정확히 이 상황을 만들어내요. 복구에는 완료 보고서가 아닌 코드를 직접 읽는 것이 필요합니다.

5. 거버넌스

거버넌스란 모든 에이전트 세션에 적용되는 정책, 예산, 권한, 감사 요건을 설정하는 것입니다.

정책은 에이전트가 할 수 있는 것과 할 수 없는 것을 정의해요. 제 거버넌스 레이어에는 스폰 예산(야간 실행당 최대 반복 횟수), 비용 상한(세션당 최대 API 지출), 허용된 bash 명령 허용 목록, 금지된 파일 패턴 차단 목록, 그리고 필수 완료 기준 세트가 포함됩니다.³ 각 정책은 특정 장애에서 비롯된 것이에요. 스폰 예산은 초기 세션이 수렴하지 않고 47번 반복을 실행했기 때문에 존재합니다. 비용 상한은 디버깅 세션이 헛된 단서를 추적하며 API 호출에 $200를 소진했기 때문에 존재해요. 각 정책은 비싼 대가를 치르고 배운 교훈의 흔적입니다.

권한은 최소 권한 원칙을 따릅니다. 블로그 콘텐츠를 생성하는 에이전트는 콘텐츠 디렉터리 외부에 대한 파일 시스템 쓰기 접근이 필요 없어요. 테스트를 실행하는 에이전트는 네트워크 접근이 필요 없습니다. 제 훅은 도구 호출 수준에서 이러한 경계를 강제하여, 세션의 권한 범위를 초과하는 작업을 차단해요.²

감사 요건이 거버넌스 레이어를 완성합니다. 모든 세션은 구조화된 로그를 생성해요. 실행된 명령, 수정된 파일, 실행된 테스트, 평가된 완료 기준이 포함됩니다. 일곱 가지 장애 모드 분류법은 6개월간의 이런 로그를 검토하고 인간 개입이 필요했던 모든 장애를 분류하면서 탄생했어요.

감독 스택

다섯 가지 인프라 구성 요소가 다섯 가지 책임을 구현합니다.

훅은 자동화된 감독을 구현해요. Claude Code의 라이프사이클 이벤트(PreToolUse, PostToolUse, Notification)가 정책을 실시간으로 강제하는 셸 스크립트를 트리거합니다.² rm -rf를 차단하는 훅은 PreToolUse 검사로 인코딩된 거버넌스 정책이에요. 완료 전 테스트 실행을 요구하는 훅은 PostToolUse 검사로 인코딩된 위임 제약입니다. 제 시스템의 95개 훅은 에이전트가 할 수 있는 것과 할 수 없는 것에 대한 95개의 결정을 인코딩하며, 각각은 해당 훅이 이제 방지하는 특정 장애로 거슬러 올라가요.

증거 게이트는 구조화된 검증을 구현합니다. 여섯 가지 기준(패턴 준수, 가장 단순한 해결책, 엣지 케이스 처리, 테스트 통과, 회귀 없음, 문제 해결)이 에이전트가 작업 완료를 표시하기 전에 특정 산출물을 생성해야 해요.⁴ 게이트는 감독을 “에이전트가 잘했나?”(주관적, 검증 불가)에서 “에이전트가 여섯 가지 기준 모두에 대한 증거를 생성했나?”(객관적, 감사 가능)로 전환합니다. 완료 보고서의 모든 모호한 표현은 재검증을 트리거해요.

품질 루프는 반복적 정제를 구현합니다. 일곱 단계(구현, 검토, 평가, 정제, 줌아웃, 반복, 보고)가 에이전트로 하여금 자신의 작업을 여러 차례 검토하게 강제해요.⁵ 이 루프는 단일 패스 생성의 구조적 한계를 보완합니다. 모델은 다시 읽어야만 보이는 오류를 포함한 그럴듯한 초안을 생성하거든요. 품질 루프는 그 다시 읽기를 의무화합니다.

세션 로그는 사후 감사를 구현해요. 시스템이 모든 도구 호출, 파일 수정, 완료 보고서를 구조화된 형태로 캡처합니다. 6개월간의 세션 로그가 장애 분류법을 만들어냈어요. 로그가 없었다면 각 장애는 고립된 일화로 남았을 겁니다.

비용 게이트는 예산 강제를 구현합니다. 스폰 예산은 반복 횟수를 제한하고, API 비용 상한은 토큰 지출을 제한해요. 스폰 예산 내에서 수렴하지 못한 에이전트는 아마 막혀 있는 것이고, 더 많은 반복은 도움이 되지 않습니다. 예산은 운영자가 다음 반복이 문제를 해결하기를 바라는 대신 진단하고 개입하도록 강제해요.

개입할 때 vs. 실행을 지켜볼 때

개입 결정은 운영자의 가장 중요한 판단입니다. 너무 일찍 개입하면 에이전트의 작업이 낭비되고, 너무 늦게 개입하면 드리프트가 누적돼요. 프레임워크가 도움이 됩니다.

메타 원칙: 속도가 아닌 정보 비대칭에 개입하세요. 에이전트가 모르는 것을 여러분이 알 때(올바른 코드 경로, 실제 요구사항, 이전 세션의 장애 모드), 개입은 그 지식을 전달합니다. 에이전트가 여러분이 아는 모든 것을 알고 단순히 문제를 해결해 나가고 있다면, 작업하게 두세요.

운영자 체크리스트

시작 전

• [ ] 스펙 검토 완료: 수락 기준이 구체적이고, 관찰 가능하며, 완전한지 확인
• [ ] 훅 활성화: 정책 훅이 해당 작업 유형에 맞게 활성화되고 테스트되었는지 확인
• [ ] 예산 설정: 스폰 제한과 비용 상한이 구성되었는지 확인
• [ ] 샌드박스 확인: 에이전트가 프로덕션에 접근하거나, 외부 요청을 보내거나, 범위 밖의 파일을 수정할 수 없는지 확인
• [ ] 핸드오프 최신화: 이전 작업을 이어가는 경우, 핸드오프 문서가 최신 수정 사항을 반영하는지 확인
• [ ] 브랜치 정리: 작업 디렉터리가 올바른 브랜치에 있고 커밋되지 않은 변경이 없는지 확인

실행 중

• [ ] 정의된 간격으로 로그 확인 (야간 실행의 경우 2-3회 반복마다)
• [ ] 궤적이 스펙의 문구가 아닌 의도에 부합하는지 검증
• [ ] 리소스 사용량 모니터링: 토큰 지출, 반복 횟수, 파일 시스템 변경
• [ ] 권한 에스컬레이션 감시: 작업에 필요하지 않아야 할 접근 권한 요청
• [ ] 세션 후 리뷰를 위해 소프트 드리프트 기록

완료 후

• [ ] 완료 보고서뿐만 아니라 모든 파일 변경 사항 검토
• [ ] 전체 테스트 스위트를 독립적으로 실행 (에이전트가 보고한 테스트 결과를 신뢰하지 않기)
• [ ] 에이전트가 명시적으로 수정하지 않은 인접 코드의 회귀 확인
• [ ] 증거 게이트 검증: 모든 기준에 일반적 보증이 아닌 특정 산출물이 있는지 확인
• [ ] 핸드오프 문서를 세션 결과와 수정 사항으로 업데이트
• [ ] 세션 기록: 발생한 장애 모드, 발동된 훅, 내린 개입 결정
• [ ] 거버넌스 업데이트: 새로운 장애 패턴이 나타났다면 재발 방지를 위한 훅이나 정책 작성

장인으로서의 운영자

에이전트 운영자 역할은 엔지니어링 기술과 제품 판단력의 교차점에 존재합니다. 훅을 작성하려면 시스템 지식이 필요하고, 스펙을 작성하려면 제품 이해가 필요해요. 에이전트 출력을 검토하려면 둘 다 필요합니다. 코드가 올바른지 평가하는 능력과 올바른 코드가 올바른 문제를 해결하는지 평가하는 능력 모두요.

채팅은 잘못된 인터페이스라는 것은 역할의 운영적 측면에 해당해요. 대화 기록을 스크롤하며 자율 작업을 감독하는 것은 단일 에이전트가 단일 세션을 실행하는 것 이상으로 확장되지 않습니다. 위에서 설명한 감독 스택(훅, 증거 게이트, 품질 루프, 세션 로그, 비용 게이트)은 감독을 인프라로 인코딩하여 인터페이스의 한계를 보완해요. 인프라가 운영자를 대체하는 것이 아닙니다. 인프라가 운영자의 도달 범위를 확장하는 거예요.

취향은 기술 시스템이다는 판단력 측면을 설명합니다. 무엇을 위임하고, 무엇을 검증하고, 무엇을 거부할지 아는 것은 경험에서 구축된 패턴 인식이 필요해요. 각 세션은 운영자에게 에이전트 행동에 대한 무언가를 가르칩니다. 운영자의 기술은 의도적 연습, 성찰, 교훈을 영구적으로 인코딩하는 인프라를 통해 복리로 성장해요.

다크 팩토리는 이론적 종착점인 Level 5를 나타내며, 그 단계에서는 인간이 코드를 읽지 않아요. 대부분의 팀에서 현재 실무는 Level 3이나 4에 위치합니다. 에이전트가 작업을 수행하고, 운영자가 감독하고 개입하는 단계예요. Level 4와 Level 5 사이의 간극은 검증 레이어입니다. Level 2와 Level 4 사이의 간극은 운영자예요.

자율 에이전트를 운영하는 모든 팀이 운영자를 키우게 될 겁니다. 문제는 이 역할을 의도적으로 발전시킬 것인지(정의된 책임, 인프라 지원, 명시적 교육과 함께), 아니면 우연히 — 야간 세션이 실패했을 때 마침 깨어 있던 사람에게 업무를 맡기는 식으로 — 발전시킬 것인지입니다. 장인 정신은 거기서부터 시작돼요.