루틴 메모리는 APC가 아닌 APX에 있어야 합니다

예약된 루틴(scheduled routine)은 때때로 메모리가 필요합니다.

프로젝트 메모리(project memory)도 아니고, 에이전트 메모리(agent memory)도 아닙니다. 자기 자신에게 다시 붙여넣은 거대한 프롬프트(prompt)도 아닙니다.

그저 다음 실행이 마지막 실행 지점부터 계속될 수 있도록 돕는 작고 지속 가능한 노트일 뿐입니다.

이것이 바로 루틴 메모리가 APC가 아닌 APX 런타임 상태(runtime state)에 존재해야 하는 정확한 이유입니다.

APC는 휴대 가능한 컨텍스트 계층(portable context layer)입니다. APC는 에이전트 정의(agent definitions), 규칙(rules), MCP 기대 사항(MCP expectations), 그리고 클론(clone) 후에 다른 호환 가능한 도구가 안전하게 읽을 수 있는 리포지토리 소유 파일(repo-owned files)과 같은 프로젝트 계약(project contract)을 담고 있어야 합니다.

APX는 일상적인 사용을 위한 런타임 및 툴링 계층(runtime and tooling layer)입니다. APX는 스케줄러(scheduler)를 실행하고, 루틴을 수행하며, 타임스탬프(timestamps)를 추적하고, 메시지를 로그(logs)로 남기며, 로컬 운영 상태(local operational state)를 저장합니다.

루틴 메모리는 운영 상태(operational state)입니다.

APX에는 이미 분리가 존재합니다

APX는 이미 루틴 정의(routine definition)와 루틴 메모리(routine memory)를 서로 다른 두 가지로 취급합니다.

루틴 정의는 리포지토리(repo)에 존재합니다. 데몬 문서(daemon docs)는 스케줄러 흐름을 명확하게 설명합니다: 루틴이 실행될 때, APX는 .apc/routines.json에서 정의를 읽고, 핸들러(handler)를 해결하며, 사전 및 사후 명령(pre and post commands)을 실행하고, 업데이트된 타임스탬프를 기록합니다.

하지만 루틴 메모리 파일은 .apc/ 내부가 아닌 APX 런타임 스토리지(runtime storage) 아래에 저장됩니다.

코드에서 src/core/stores/routine-memory.js는 경로를 다음과 같이 정의합니다:

<projectStoragePath>/routines/<routineId>/memory.md

그리고 APX 프로젝트 레이아웃(project layout) 문서는 projectStoragePath가 실제로 무엇을 의미하는지 설명합니다: 런타임 상태는 ~/.apx/projects/<apxId>/ 아래에 존재합니다.

따라서 실제 분리는 의도적인 것입니다:

• .apc/routines.json은 무엇이 실행되어야 하는지를 말합니다.
• ~/.apx/projects/<apxId>/routines/<routineId>/memory.md는 무엇이 일어났는지와 다음 실행이 무엇을 기억해야 하는지를 저장합니다.

이러한 경계는 건강합니다.

왜 APC가 잘못된 장소인가

루틴 메모리 파일은 작아 보이지만, 런타임 잔여물(runtime residue)처럼 동작합니다.

이는 실행 후에 변경됩니다. 여기에는 일시적인 관찰 사항(temporary observations), 마지막 실행 사실(last-run facts), 부분적인 진행 상황(partial progress), 또는 특정 시점의 특정 머신에서만 유용한 노트가 포함될 수 있습니다.

만약 이를 APC에 커밋한다면, 다음과 같은 여러 문제들이 빠르게 나타납니다:

• 루틴 실행(routine runs)이 노이즈가 섞인 git diff를 생성하기 시작함
• 팀원들이 머신 로컬(machine-local) 또는 시간 로컬(time-local) 잔여물을 상속받음
• CI와 로컬 실행이 동일한 메모리 파일을 두고 충돌할 수 있음
• 리포지토리가 의도(intent)를 기술하는 대신 실행 잔여물(execution leftovers)을 저장하기 시작함

이는 APC가 세션(sessions), 메시지 로그(message logs), 캐시(caches) 또는 데몬 상태(daemon state)를 보유해서는 안 되는 것과 동일한 이유입니다.

이식 가능한 컨텍스트(Portable context)는 다른 런타임(runtime)에게 프로젝트를 어떻게 이해해야 하는지를 알려주어야 합니다.
어제의 루틴 연습장(routine scratchpad)을 재생(replay)해서는 안 됩니다.

왜 APX가 적절한 장소인가

APX가 스케줄러(scheduler)를 소유하므로, APX가 스케줄러의 메모리도 소유해야 합니다.

그래야 생명주기(lifecycle)가 일관되게 유지됩니다.

루틴의 실행 시기를 결정하는 동일한 런타임이 루틴의 노트(notes)를 해당 실행(runs), 이력(history), 메시지(messages) 및 로컬 아티팩트(local artifacts)와 가깝게 유지할 수 있습니다. 이는 디버깅을 더 단순하게 만들고 리포지토리를 깨끗하게 유지합니다.

또한 APX는 해당 메모리의 제한된 슬라이스(bounded slice)를 루틴 프롬프트(routine prompt)에 다시 주입합니다. routine-memory.js에서 readRoutineMemoryForPrompt()는 콘텐츠를 다듬고 프롬프트에 들어가는 양을 제한합니다. 그런 다음 루틴 러너(routine runner)는 super_agent 루틴이 실행될 때 해당 슬라이스를 channelMeta.routineMemory를 통해 전달합니다.

이러한 세부 사항이 중요합니다.

목표는 메모리를 두 번째 프로젝트 명세(project spec)로 만드는 것이 아닙니다. 목표는 루틴이 다음 실행 시 잘 동작할 수 있도록 딱 적당한 수준의 로컬 연속성(local continuity)을 제공하는 것입니다.

실질적인 예시

아침 스탠드업(morning standup) 루틴을 상상해 보십시오.

정의(definition)는 APC에 속해야 합니다. 프로젝트가 스케줄과 프롬프트를 소유해야 하기 때문입니다:

{
  "routines": [
    {
...

하지만 루틴 메모리는 APX에 로컬로 남아 있어야 합니다:

# Routine memory - morning-standup

## 2026-07-25
...

첫 번째 파일은 이식 가능한 계약(portable contract)입니다.
두 번째 파일은 런타임 연속성(runtime continuity)입니다.

이들은 동일한 범주의 데이터가 아니므로, 같은 레이어(layer)에 존재해서는 안 됩니다.

작은 규칙, 더 깨끗한 시스템

APC가 리포지토리 소유의 계약 레이어(contract layer)라면, 루틴 정의를 그곳에 두십시오.
APX가 런타임 레이어(runtime layer)라면, 루틴 메모리를 그곳에 두십시오.

이는 더 깔끔한 저장소 (repository), 더 안전한 자동화 (automation), 그리고 동일한 프로젝트가 노트북, 팀원, 또는 호환 가능한 런타임 (runtimes) 사이를 이동할 때 발생하는 잘못된 가정 (false assumptions)을 줄여줍니다.

루틴 정의 (Routine definitions)는 이동해야 합니다.
루틴 메모리 (Routine memory)는 그 자격을 얻은 런타임 (runtime)과 함께 머물러야 합니다.