6일 연속으로 나의 아침 상태 확인은 초록색이었다. publish OK. 매일 오전 09:30, 정확한 일정대로였다.

6일째 되는 날, 나는 실제로 블로그를 열어보았다. 0일 차 이후로 아무것도 게시되지 않았다.

launchd 작업은 매일 아침 실행되었다. Python 스크립트는 매일 아침 종료 코드 0(exit 0)을 반환했다. 심지어 로그에는 매일 아침 publish OK라고 기록되기까지 했다. 하지만 실제로 수행하지 못한 것은 아무것도 게시하는 일이었다. 왜냐하면 게시 단계가 1일 차에 조용히 만료되어 버린 브라우저 세션(browser session)에 의존하고 있었기 때문이다. 스크립트는 인증 오류(auth error)를 포착하여 파일 상단으로 스크롤되어 사라져 버린 경고를 로그에 남겼고, 그럼에도 불구하고 종료 코드 0으로 종료되었다. 래퍼(wrapper)가 "프로세스가 실행되었는가"만 확인했을 뿐, "포스트가 실제로 라이브 되었는가"는 전혀 확인하지 않았기 때문이다.

나는 출근은 하지만 아무것도 하지 않으면서, 스스로에게 찬사를 보내는 자기 평가서를 제출하는 직원을 만든 셈이었다. 그리고 나는 그 직원의 결과물을 확인하는 대신 그가 작성한 자기 평가서를 읽고 있었기에 전혀 알지 못했다.

그 주간은 이 포스트 전체의 주제인 것을 나에게 가르쳐 주었다: AI 에이전트(AI agents)를 일회성 코딩 작업 이상으로 활용할 때, 어려운 점은 에이전트 자체가 아니다. 그들을 둘러싼 관리 계층(management layer)이다.

"12개의 에이전트"는 더 이상 문제가 아니다

Claude Code 서브 에이전트(subagents) 100개 이상이 포함된 무료 팩을 쉽게 찾을 수 있다. 이제 에이전트는 범용 제품(commodities)이다. 만약 당신의 자동화가 실패하고 있다면, 그것은 code-reviewer.md나 researcher.md가 부족해서 발생하는 경우가 거의 없다.

그것은 지루한 관리상의 이유로 실패하는 것이다:

• 에이전트가 얻지도 못한 성공을 보고했다.
• 두 에이전트가 동일한 파일을 두고 싸웠다.
• 한 에이전트가 숫자를 지어내어 당신이 거의 전송할 뻔한 보고서에 넣었다.
• 작업이 조용히 중단되었고 일주일 동안 아무도 알아차리지 못했다.
• 에이전트에게 메모리(memory)가 없어서 모든 세션에 동일한 컨텍스트(context)를 다시 붙여넣어야 했다.

이 중 그 어느 것도 에이전트의 문제는 아니다. 그것은 거버넌스(governance) 문제이다. 아래는 6일간의 사건 이후 내가 실제로 적용한 패턴을 포함하여 덧붙인 다섯 가지 요소들이다. 당신은 이 모든 것을 직접 구축할 수 있다. 그것이 이 글을 쓰는 이유이다.

1. 모든 에이전트에게 프롬프트(prompt)가 아닌 헌장(charter)을 부여하라

프롬프트(prompt)는 _이번 한 번 무엇을 할지_를 말합니다. 헌장(charter)은 _이 역할이 무엇을 할 수 있는지_를 말합니다. 이는 작업(task)과 직원(employee)의 차이입니다. 제 에이전트들은 에이전트 옆에 위치하는 단순한 마크다운(Markdown) 파일들입니다:

# Charter: publish-lead
Mandate:        블로그 대기열에 하루 1개의 포스트를 게시할 것.
Authority:      /drafts 내의 초안을 수정할 수 있음. 게시 엔드포인트(endpoint)를 호출할 수 있음.
...

여기서 두 줄이 모든 작업을 수행합니다. **완료 정의 (Definition of done)**는 느낌이 아니라 디스크 상의 결과물(artifact)입니다. **에스컬레이션 시점 (Escalate when)**은 에이전트가 대충 무시하고 넘어가서는 안 되는 정확한 조건을 명시합니다. 제 6일간의 유령 현상은

그 규칙은 절대적이며 헌장(charter)에 명시되어 있습니다: 어떠한 지표라도 검증된 소스(verified source)로부터 온 것이 아니라면 해당 필드는 빈칸으로 남겨둡니다. 보간(interpolation)도, "대략"도, 추측을 사실로 반올림하는 것도 허용되지 않습니다. 빈 셀은 정직합니다. 환각(hallucination)으로 만들어낸 1,240 views는 미래의 당신을 위해 당신이 직접 매설한 지뢰와 같습니다.

4. 메모리는 에이전트가 다시 읽어야 하는 파일이어야 합니다

매 세션마다 동일한 컨텍스트를 다시 붙여넣고 있다면, 당신은 메모리를 가진 것이 아니라 단순한 잡무(chore)를 가진 것입니다. 지속성 메모리(Persistent memory)는 단지 에이전트가 매 실행의 시작 단계에서 읽고, 끝 단계에서 내용을 추가하는 내구성이 있는 인덱스(index)일 뿐입니다:

# MEMORY.md  (에이전트가 매 세션 가장 먼저 읽는 파일)
- [publish-pipeline] Naver 세션이 Tistory 세션보다 먼저 종료됨 — 통계 세션 재생성 필요. (07-06에 뼈아픈 경험을 통해 학습함)
...

각 항목은 날짜가 기록된 흉터와 같습니다. 새로운 세션은 흉터를 다시 얻는 대신, 기존의 흉터를 물려받습니다. 이것이 몇 주에 걸쳐 더 나아지는 에이전트와, 첫 달의 실수를 영원히 반복하는 에이전트 사이의 차이점입니다.

5. 단순한 cron 라인이 아닌, 에스컬레이션 경로(escalation path)가 포함된 스케줄을 구성하세요

스케줄링 부분은 쉽습니다. macOS의 launchd나 Linux의 cron을 사용하면 됩니다:

<!-- ~/Library/LaunchAgents/com.me.publish.plist -->
<key>StartCalendarInterval</key>
<dict><key>Hour</key><integer>9</integer>
...

모두가 건너뛰는 부분은 바로 이것입니다: 문제가 발생했을 때 누구에게 알릴 것인가. 에스컬레이션 채널(escalation channel)이 없는 예약된 작업은 정확히 당신이 6일간의 침묵을 겪게 되는 원인이 됩니다. 저의 시스템은 에이전트가 헌장의 "에스컬레이션 시점 (Escalate when)" 조건 중 하나(만료된 인증, 잔액 부족, 두 번 실패한 단계 등)에 도달하는 즉시 텔레그램(Telegram) 봇으로 알림을 보냅니다. 인간(나)은 시스템의 _문서화된 의존성(documented dependency)_이지, 어쩌다 한 번씩 확인하러 들어오는 사람이 아닙니다.

요약된 교훈들

저에게 가장 큰 비용을 치르게 했던 교훈들을 한 화면에 정리하면 다음과 같습니다:

1. 종료 코드 0(exit 0)을 반환하는 프로세스가 반드시 완료된 작업은 아닙니다.
2. 로그(logs)가 아닌 산출물(artifacts)을 신뢰하세요. 보고서에는 지칭할 수 있는 무언가가 있어야 합니다.
3. 에이전트가 숫자를 지어내게 두지 마세요. 그럴듯한 숫자보다는 빈칸이 낫습니다.
4. 모든 채널에 동일한 템플릿을 사용하는 것은 모든 채널에서 결과가 0임을 의미합니다. 각 접점(surface)마다 고유한 전략이 필요합니다.
5. 모든 에이전트에게는 오직 인간만이 해결할 수 있는 문제들—만료된 세션, 잔액 부족, 캡차(captcha) 등—에 대한 에스컬레이션 경로(escalation path)가 필요합니다.
6. 메모리(Memory)는 당신이 다시 붙여넣는 컨텍스트(context)가 아니라, 에이전트가 다시 읽는 파일입니다.
7. 헌장(charter)(권한 + 권위 + 경계 + 완료 정의(definition-of-done) + 에스컬레이션)은 모호한 프롬프트를 책임감 있는 역할로 탈바꿈시킵니다.

지름길을 원하신다면

위의 내용만으로도 자신만의 관리 계층(management layer)을 구축하기에 충분합니다. 진심으로, 직접 해보세요. 보람찬 주말이 될 것입니다.

만약 제가 자신의 상태 보고서로부터 꾸지람을 들으며 보냈던 그 일주일 같은 시간을 보내고 싶지 않다면, 제가 이를 패키지로 묶었습니다. 12개의 서브 에이전트(subagents), 헌장 템플릿, 사실 기반 보고 규칙, 로그가 아닌 실시간 상태 확인 레시피, 메모리 시스템, 그리고 launchd/cron 패턴까지—.claude/ 디렉토리에 넣기만 하면 되는 21개의 파일입니다. 이것은 단순한 에이전트 팩이 아니라, **AI 직원을 위한 관리 계층(management layer for AI employees)**입니다.

Gumroad에서 $19에 판매 중이며, 누군가 구매할 때마다 가격이 $10씩 올라갑니다. 페이지에 판매 카운터가 공개되어 있으므로, 지금이 나중보다 확실히 저렴하다는 것을 증명할 수 있습니다. 이것이 유일한 희소성이며, 가짜 카운트다운은 없습니다. → https://bluelove3.gumroad.com/l/ai-employee-company

어느 쪽이든: 오늘 당신의 자동화 시스템이 로그가 아닌 현실과 일치하는지 확인하십시오. 제 시스템은 문제가 생기기 직전까지 완벽해 보였습니다.

당신의 작업 중 알아차리기 전까지 가장 오랫동안 조용히 고장 나 있었던 것은 무엇인가요? 제가 먼저 말하겠습니다—6일입니다. 댓글로 더 긴 사례를 알려주세요.