에이전트는 실무 환경에서 「조용히」 고장 난다

로컬에서 기분 좋게 작동하던 LLM 에이전트를 실무 운영(Production) 환경으로 가져가면, 대개 다음 상황에서 막히게 됩니다.

조용히 멈춤— 도중에 예외(Exception)를 삼켜버리고, 아무 일도 없었다는 듯이 "완료했습니다"라고 응답함 -
흔적이 없음— "테스트는 통과했습니다"라고 말하지만, 디스크에는 아무런 증거도 남아 있지 않음 -
재시작하면 사라짐— 대화 세션(Dialogue Session) 내에서만 작동하며, 머신을 재시작하면 연속성(Continuity)이 제로가 됨 -
위반을 자진 신고하지 않음— 규칙을 어겼다는 사실을, 어긴 본인(에이전트)이 보고하지 않음

이 모든 문제는 "좀 더 정중하게 부탁하기"로는 해결되지 않습니다. 부탁이 통하지 않는 순간, 애초에 고장 난 상태가 성립되지 않는 구조를 호스트(Host) 측에서 미리 준비해야 합니다. 이 기사의 본론은 그 "4가지 고장 나는 방식"에 대응하는 4가지 물리적 패턴 (§10.1~§10.4)입니다.

왜 「물리적」인가 — v0.1이 그은 경계선

이 발상 자체는 새롭지 않습니다. 이전 AOS v0.1 기사에서, 에이전트를 텍스트 규칙이 아닌 호스트 측의 물리적 제약(Physical Constraint)으로 묶는 최소한의 프레임워크를 작성했습니다. 핵심은 4가지입니다.

§3.2 Three Zones— 모든 경로를 Oracle (읽기 전용) / Permitted (작업 영역) / Prohibited로 분류함 -
§4.1 Hook Requirement— 쓰기 및 쉘 실행을 PreToolUse에서 실행 전 검사하고, 위반 시 exit 2로 중단함 -
§4.3 Role Separation— 생성한 에이전트에게 자신의 성과물을 채점하게 하지 않음 -
§4.4 Physical Evidence— "완료했습니다"라는 대화가 아니라, 디스크 위의 성과물을 증거로 삼음

v0.1은 여기까지, 즉 "무엇을 지켜야 하는가"의 경계선을 그렸습니다. 다만, 읽은 사람들에게서 반드시 나오는 질문이 남아 있습니다 — "그래서, 그것을 실제 도구로 어떻게 구현하는가?". 서두의 4가지 고장 나는 방식은 바로 이 구현의 공백에서 발생합니다. v0.2는 그 부분을 채웁니다.

v0.2에서 한 일: 규범은 유지하고, 구현 사례를 추가함

v0.2의 방침은 명확합니다.

§1~§9의 규범 (MUST / MUST NOT)은 일절 변경하지 않음— 완전한 하위 호환성 유지 -
§10 Implementation Examples 신설— 4가지 실무 패턴을 공개 리포지토리의 실제 코드 링크와 함께 게재 -
§6 수정— 미공개였던 참조 구현(Reference Implementation)에 대한 언급을 삭제하고, Reference Implementation (단수)에서 Reference Implementations (복수)로 제목 변경, 실재하며 공개된 physical-agent-patterns 리포지토리를 가리키도록 교체

즉, "규범의 언어를 늘리는 것"이 아니라, "규범의 언어를 이미 작동하고 있는 코드에 연결하는" 업데이트입니다. 규범만이 공중에 떠 있지 않도록 했다고 말해도 좋습니다.

§10.1 Manifest 선언 (§8·§9 대응)

AOS 준수 도구는 자신의 존(Zone) 경계를 manifest.json으로 선언합니다. 이를 통해 다른 에이전트가 "이 도구는 어디에 써도 되는지 / 어디는 건드리면 안 되는지"를 **기동 전(Before Startup)**에 알 수 있습니다.

{
"aos_compliant": "v0.2",
"permitted_output_paths": ["docs/reports/"],
...
}

oracle_paths는 §3.2의 Oracle 존과 직결됩니다. 훅(Hook)은 실행 시 이곳으로의 쓰기를 차단합니다. -
permitted_output_paths는 Permitted 존입니다. 도구가 출력할 수 있는 유일한 장소입니다.

중요한 점은 **"선언만으로 준수를 자처해서는 안 된다"**는 점입니다. manifest.json에 aos_compliant를 적었더라도, 실제로 훅(또는 CI 게이트)이 oracle_paths로의 쓰기를 차단하고 있지 않다면 비준수입니다 (§8 끝부분). 선언과 실행 시 강제(Enforcement)는 세트로 구성되어야 비로소 의미를 갖습니다.

§10.2 물리적 증거 패턴 (§4.4 대응)

AOS가 방지하고자 하는 전형적인 실패는 **"에이전트는 '작동했다'라고 말하지만, 흔적이 아무것도 남아 있지 않은 것"**입니다.

물리 우선 (physical-first) 패턴은 증거를 완료의 전제 조건으로 삼습니다. 사후에 남기는 로그가 아니라, "증거 파일이 존재해야 비로소 완료라고 주장할 수 있다"는 순서입니다.

# 완료를 선언하기 "전"에 증거를 작성함 (agent_with_evidence.py 보다)
evidence = {
"task": task,
...

호출 측은 evidence_path의 존재를 체크하는 것만으로 완료를 검증할 수 있습니다. 대화상의 "했습니다"는 필요 없습니다.

§10.3 면역 루프 (Immune Loop) (§4.1・§4.5 대응)

상주하는 에이전트가 워크스페이스 내의 AOS 위반을 감지하고, 복구 시퀀스 (recovery sequence)를 가동하는 패턴입니다. 핵심은 감지 (읽기 전용 스캔)와 복구 (쓰기)를 분리하는 것입니다.

# violation_detector.py — 복구를 시도하기 "전"에 보고서를 작성함
violations = _scan(root)
report = {
...

감지기는 위반 보고서를 JSON으로 작성합니다 (이 자체가 §4.4의 물리적 증거입니다). 복구 플래너 (recovery planner)는 해당 보고서를 읽고, 기지의 수정 사항을 적용하거나, 설계 판단이 필요할 때는 인간 (Sovereign)에게 에스컬레이션 (escalation)합니다 (§4.5). 감지기가 자신의 발견을 스스로 복구하지 않는다는 분리는 §4.3의 역할 분리 (role separation)이기도 합니다.

실제 코드: physical-agent-patterns/patterns/03_immune-loop/

§10.4 systemd 런타임 (systemd runtime) (§4.4의 영속화 대응)

대화 세션에서만 동작하는 에이전트는 재시작을 관통하는 §4.4를 충족할 수 없습니다. systemd 패턴은 에이전트를 OS의 프로세스 수퍼바이저 (process supervisor)에 묶습니다. 서비스가 실행 경계를, 타이머가 스케줄을 정의하며, 출력 파일은 재시작 후에도 남습니다.

# agent.py — 출력 파일이 "실행했다"는 증거가 됨
output_path = OUTPUT_DIR / f"agent_run_{today}.md"
if output_path.exists():
...

# physical-agent.timer (발췌)
[Timer]
OnCalendar=daily
...

멱등성 가드 (idempotency guard, if output_path.exists(): return)가 중복 실행을 방지하며, 증거 파일을 유일한 완료 기록으로 유지합니다. Persistent=true는 예정된 실행을 놓쳤을 경우 다음 부팅 시 실행되도록 하여, 가동 시간과 관계없이 증거 요건을 충족합니다.

실제 코드: physical-agent-patterns/patterns/01_systemd-runtime/

4가지 패턴과 AOS 조항의 대응

모두 특별한 발명은 아닙니다. 에이전트를 프로덕션 운영에 적용하려고 하면 어디선가 반드시 부딪히게 되는 문제들을 재사용 가능한 형태로 추출했을 뿐입니다.

왜 "구현 예시를 사양에 넣는 것"에 집착했는가

사양서에서 흔히 발생하는 상황으로, "규범은 훌륭하지만, 아무도 구현의 출발점을 가지고 있지 않은" 상태가 있습니다. 읽은 사람이 "옳은 것은 알겠다. 그런데 첫 줄은 어떻게 써야 하지?"에서 멈춰버리는 것입니다.

v0.2는 그 간극을 최대한 좁히기 위한 업데이트입니다. 사양의 각 조항에 복제해서 바로 실행할 수 있는 공개 코드가 연결되어 있는 상태로 만들었습니다. 사양 자체는 특정 런타임 (Claude Code / Cursor / 자체 루프)에 얽매이지 않지만, 구현 예시가 있으면 두 번째 사용자가 훨씬 편해질 것입니다.

참고로 §10의 4가지 패턴은 모두 physical-agent-patterns에 공개되어 있으므로, git clone 하여 바로 읽어볼 수 있습니다.

마치며

AOS v0.2는 새로운 제약을 추가한 버전이 아닙니다. "제약을 어떻게 구현할 것인가"를 동작하는 코드 링크로 채운 버전입니다.

• 규범 텍스트 (v0.2): AOS-spec/AOS-v0.2.md
• 구현 패턴 모음: physical-agent-patterns

「텍스트 규칙만으로는 준수하게 만들 수 없다」고 느끼고 계신 분들에게, 구현을 위한 초안이 되기를 바랍니다.

AOS 사양서 (GitHub)

본 기사에서 다룬 「물리적 거버넌스 (Physical Governance)」 접근 방식은 AOS (AI Operating Standard) 로써 사양화하여 공개하고 있습니다. v0.2에서 구현 예시 절을 추가했습니다.

👉 AOS-spec — 사양서 (v0.2)

👉 physical-agent-patterns — 구현 패턴 모음

사양이나 구현 예시가 도움이 되었다면, ⭐ Star를 눌러주시면 다음 버전 책정에 큰 힘이 됩니다. Issue 및 PR도 환영합니다.

Discussion