이 기사에 대하여

Claude Code와 같은 코딩 에이전트를 '정기 실행으로 자율적으로 작동하게 하는' 구성을 짜면, 반드시 똑같은 벽에 부딪히게 됩니다. 세션이 종료되면 컨텍스트 (Context)가 사라지고, 다음에 기동한 에이전트는 지난번에 무엇을 했는지 전혀 기억하지 못한다는 벽입니다.

필자는 현재 AI 에이전트(Claude)에게 사업 운영을 통째로 맡기는 실험을 진행 중이며(연재 기사), 이 '기억 제로 상태로 기동해도 업무를 지속할 수 있는' 설계를 실운용하고 있습니다. 이 기사에서는 그 과정에서 유효했던 3가지 파일 패턴을 사업 내용과는 분리하여 범용적으로 소개합니다. 개인 개발의 정기 실행 태스크나, 여러 에이전트를 가로지르는 인수인계에 그대로 응용할 수 있습니다.

전제: 왜 '대화의 기억'에 의존할 수 없는가

• 정기 실행(cron/스케줄러)으로 기동하는 세션은 이전 세션의 대화 이력을 가지지 않는다
• 장시간 가동되는 세션이라도, 컨텍스트 윈도우 (Context Window)의 압축으로 인해 오래된 결정 사항이 유실될 수 있다
• 여러 에이전트(혹은 인간과 에이전트)가 비동기적으로 동일한 태스크에 관여할 경우, 대화 로그만으로는 상태가 동기화되지 않는다

이것들에 공통되는 해결책은 같습니다. '지금 무엇을 해야 하는가'의 상태를 대화가 아닌 리포지토리(파일)에 갖게 하는 것입니다. 에이전트는 기동할 때마다 '먼저 이 파일을 읽어라'라는 하나의 입구를 통해 상태를 복원합니다.

패턴 1: 부트스트랩 문서 (Bootstrap Document)

재개 시 반드시 가장 먼저 읽을 파일(예: OPERATIONS.md)을 준비하고, 다음 내용을 적어둡니다.

• 누구와 무엇을 합의했는가 (판단 권한의 범위, 지켜야 할 제약 사항)
• 그 외에 어떤 파일이 있으며, 무엇을 위해 존재하는가 (색인)
• '정기 세션에서 할 일'을 우선순위가 지정된 리스트로 명시한다

포인트는 이것을 '메모'가 아니라 '매번 읽히는 것을 전제로 한 기동 스크립트'로서 작성하는 것입니다. 인간을 위한 설명문이 아니라, 다음 에이전트를 위한 명령문으로 작성하면 망설임이 줄어듭니다.

## 정기 세션에서 할 일 (우선순위)
1. STATE.md 확인 — 지난번으로부터의 상태 변화가 있다면 반영한다
2. 진행 중인 태스크를 진행한다
...

패턴 2: 스테이트 레저 (State Ledger, 상태 장부)

외부 계정 생성이나 인간의 승인 대기 등, 에이전트 단독으로는 완결할 수 없는 태스크는 대화로 부탁하는 것이 아니라, 상태(Status)가 포함된 파일에 써둡니다.

## 태스크 A
- 상태: 의뢰 중
- 내용: ◯◯ 등록
...

인간 측은 '파일을 직접 편집'하거나 '한마디 메시지를 보내는' 것 중 어느 쪽이든 상관없으며, 다음에 기동한 에이전트가 차이(Diff)를 감지하여 다음 수를 둡니다. 이를 통해 동기적인 대화를 거치지 않고 비동기적으로 태스크가 앞으로 나아가는 프로토콜을 만들 수 있습니다. 대화의 왕복을 기다릴 필요가 없기 때문에 정기 실행과 궁합이 좋은 설계입니다.

패턴 3: 추가 전용 작업 로그 (WORKLOG)

세션의 마지막에 새로운 날짜를 위쪽에 추가해 나가는 형식의 로그를 하나 가집니다. 쓰는 내용은 3가지로 압축합니다.

• 한 일 (사실. 판단 근거는 간결하게)
• 숫자나 상태 (진척도를 정량화할 수 있다면 반드시 포함)
• 다음 세션으로의 인수인계 (다음에 무엇부터 착수해야 하는지에 대한 불렛 포인트)

이 세 번째 항목이 가장 중요합니다. 부트스트랩 문서가 '항구적인 규칙'을 갖는 것에 반해, WORKLOG는 '지금 이 순간의 연속성'을 갖습니다. 다음 에이전트는 OPERATIONS.md → WORKLOG.md의 최신 엔트리 두 개를 읽는 것만으로, 대화 이력 없이 지난번의 이어서 착수할 수 있습니다.

3가지 패턴의 역할 분담

세 가지를 섞어서 파일 하나로 만들면, 항구적인 규칙이 일상의 로그에 파묻혀 퇴화합니다. '좀처럼 바뀌지 않는 것'과 '매번 바뀌는 것'을 파일 레벨에서 분리하는 것이 핵심입니다.

실운용에서 겪은 함정

• 인수인계(申し送り)를 모호하게 작성하면 자기 수행적으로 안전한 쪽으로 치우치게 된다. 「상황을 지켜본다」와 같은 인수인계는 다음 에이전트가 구체적인 다음 액션(Next Action)으로 변환하지 못해 정체되기 쉽습니다. 인수인계는 항상 「동사로 시작하는 구체적인 태스크(Task)」로 작성해야 합니다.
• 스테이트 레저(State Ledger)의 상태 어휘를 고정한다. 「미착수/진행 중/완료」와 같이 어휘를 미리 정해두지 않으면, 에이전트마다 표현이 달라져 탐지 누락이 발생합니다.
• 로그는 추가 전용으로 사용하며, 다시 쓰지 않는다. 과거의 로그를 편의에 따라 다시 쓰면 판단 경위를 추적할 수 없게 되어, 같은 실수를 반복하는 원인이 됩니다.

요약

기억이 사라지는 에이전트를 지속 가동시키는 설계의 본질은 「상태를 대화에서 파일로 밀어내는 것」 하나로 귀결됩니다. 부트스트랩 문서(Bootstrapped Document)로 영구적인 규칙을, 스테이트 레저(State Ledger)로 비동기 태스크를, 작업 로그로 직전의 인수인계를 각각 전용 파일로 분리하는 것만으로도, 정기 실행 시 문맥(Context)이 없는 상태에서도 지속적으로 작업을 진행할 수 있는 에이전트를 구축할 수 있습니다.

개인 개발의 정기 실행 태스크나 Slack bot, 자동화 파이프라인의 인수인계 설계에도 응용할 수 있는 사고방식이므로, 괜찮으시다면 한번 시도해 보세요.

Discussion