모든 Claude 세션은 제로(zero) 상태에서 시작됩니다. 한 시간 전에 무슨 일이 있었는지에 대한 기억도, 화요일에 당신이 내린 결정에 대한 기록도, 지난주에 논의했던 아키텍처가 이미 구축되어 배포되었다는 인식도 없습니다. 새로운 대화를 시작할 때, 모델은 자체적인 관점에서 당신을 처음 만나는 것입니다.

'이 문서를 요약해줘', '이 함수를 수정해줘', '이 질문에 답해줘'와 같은 일회성 작업의 경우 이는 괜찮습니다. 작업이 단일 세션 내에서 완전히 이루어진다면 백지 상태(blank slate)의 비용은 제로입니다. 하지만 당신의 작업이 여러 세션에 걸쳐 확장되는 순간, 백지 상태는 시간과 주의력을 통해 반복적으로 지불해야 하는 비용이 됩니다.

저는 24시간 자율적으로 작동하는 10개의 스케줄링된 에이전트(scheduled agents) 군단을 구축했을 때, 그 대가가 얼마나 비싼지 깨달았습니다.

재지향(Re-orientation)의 실제 모습

에이전트가 이전 작업에 대한 아무런 기억 없이 세션을 시작하면, 가장 먼저 하는 일은 컨텍스트(context)를 재구성하는 것입니다. 이전에 무엇이 수행되었는지 이해하기 위해 파일을 읽습니다. 로그를 확인합니다. 최근의 git 히스토리를 조사합니다. 자신의 사전 지식이 아닌 아티팩트(artifacts)로부터 시스템의 현재 상태를 추론합니다. 이 중 그 어떤 것도 유용한 작업이 아닙니다. 이는 매 실행 시 사전에 지불해야 하는 오버헤드(overhead)입니다.

단일 에이전트 설정에서는 이것이 짜증스럽긴 하지만 관리 가능한 수준입니다. 요약본을 붙여넣거나, 모델에게 무엇을 하고 있었는지 상기시켜 주면 됩니다. 모델이 속도를 따라잡을 수 있도록 몇 번의 턴(turns)을 소모하게 됩니다. 인간이 수동으로 비용을 지불하며, 그 비용은 단일 붙여넣기에 담을 수 있는 양에 의해 제한됩니다.

스케줄에 따라 실행되는 에이전트 군단에서는 계산 방식이 달라집니다. 각 에이전트는 독립적으로 실행됩니다. 각 에이전트는 제로 상태에서 시작합니다. 각 에이전트는 실제 작업을 수행하기 전에 세상의 현재 상태를 재발견하는 데 세션의 초기 턴을 소비합니다. 하루에 한두 번씩 실행되는 10개의 에이전트에 이 오버헤드를 곱하면, 사전 작업은 빠르게 누적됩니다. 세션 메모리(session memory)가 이미 갖춰져 있음에도 불구하고, 우리 군단의 에이전트들은 첫 번째 실질적인 작업을 시작하기 전까지 평균 15턴을 소모합니다.

손실의 범주

컨텍스트 손실 (Context loss)은 단일한 현상이 아닙니다. 군단 전체에서 실제 비용이 어디에서 누적되고 있는지 살펴보았을 때, 이는 세 가지 뚜렷한 범주로 나뉘었습니다.

가장 눈에 띄는 범주는 **작업 중복 (work duplication)**입니다. 이전 세션에 대한 기억이 없다면, 에이전트는 가끔 이미 완료된 작업을 다시 수행하게 됩니다. 이는 에이전트가 부주의해서가 아니라, 해당 작업이 완료되었다는 신호가 실제로 없기 때문입니다. 지난 화요일에 문서를 초안 작성했던 빌더 에이전트 (builder agent)는, 현재 환경의 무언가가 그 사실을 명시적으로 알려주지 않는 한, 목요일에 깨어났을 때 해당 문서가 존재한다는 사실을 알 방법이 없습니다. 만약 결과물 (artifact)을 놓치기 쉽다면, 에이전트는 동일한 목적지에 도달하기 위해 또 다른 경로를 찾게 됩니다.

두 번째 범주는 **의사결정 표류 (decision drift)**입니다. 자율적인 결정을 내리는 10개의 에이전트를 가진 시스템은 판단 (judgment calls)을 축적하게 됩니다. 파일 형식의 선택, 새로운 모듈의 명명 규칙 (naming convention), 이상 징후를 에스컬레이션 (escalation)해야 하는 임계값 등 — 이러한 결정들은 한 번 내려지면 앞으로 전파되어야 합니다. 기억이 없다면, 유사한 선택에 직면하는 각 에이전트는 이를 처음부터 다시 도출하며, 항상 동일한 결론에 도달하는 것도 아닙니다. 시간이 흐름에 따라, 이전 결정에 접근할 수 없는 상태에서 내려진 결정들은 진단하기 어려운 방식으로 시스템 내부의 불일치를 초래합니다.

세 번째 범주는 **컨텍스트 재주입 비용 (context re-injection cost)**입니다. 이는 백지 상태 문제 (blank-slate problem)를 수동으로 해결하려는 과정에서 발생하는 오버헤드 (overhead)입니다. 즉, 프롬프트 (prompts)에 요약본을 전달하거나, 다음 에이전트가 읽을 수 있도록 파일에 상태 (state)를 기록하거나, 계속해서 커지는 초기화 의식 (initialization ritual)을 유지하는 작업 등을 의미합니다. 이러한 우회책들은 작동은 하지만, 이를 유지하기 위해 토큰 (tokens)과 인간의 주의력 (human attention)을 모두 소모합니다. 또한 시스템이 진화하는 속도를 따라잡기 위해 필요한 주도성이 떨어짐에 따라, 시간이 지날수록 이러한 방식들은 퇴보하는 경향이 있습니다.

지속성 메모리 (persistent memory)가 실제로 해결하는 것

제가 LoreConvo를 플릿(fleet)에 추가했을 때, 자동 저장 훅(auto-save hook)은 매 실행이 끝날 때마다 각 에이전트의 세션 컨텍스트(session context)를 캡처하기 시작했습니다. 여기에는 수행된 작업의 요약, 내려진 결정, 미결 상태로 남겨진 질문들, 그리고 세션 종료 시점에 유효했던 시스템에 관한 기술적 사실들이 포함되었습니다. 자동 로드 훅(auto-load hook)은 첫 번째 도구 호출(tool call)이 이루어지기 전, 해당 컨텍스트를 다음 세션으로 가져왔습니다.

재정렬(re-orientation)에 미치는 효과는 즉각적이고 측정 가능했습니다. 이전에는 상태를 재구성하기 위해 세션의 도입부 턴(turn)을 파일 읽기에 소비하던 에이전트들이, 이제는 자신이 멈췄던 지점에 대한 검증된 요약본으로부터 바로 시작할 수 있게 되었습니다.

제가 직접 측정한 수치는 다음과 같습니다. LoreConvo가 이미 활성화된 상태로 실행된 761개의 에이전트 세션 전체를 조사한 결과, 에이전트들은 첫 번째 실질적인 작업 항목(work item)을 시작하기 전까지 평균 15턴(turn)을 소비했습니다. 이는 일반적인 세션의 약 20%에 해당합니다. 여러 시스템을 가로질러 조정 작업을 수행하는 복잡하고 고맥락(high-context)인 에이전트들의 경우, 이 수치는 더 높게 나타납니다. 마케팅 에이전트는 평균 25턴의 사전 작업을 수행하며, 프로젝트 관리 에이전트는 평균 31턴을 소비합니다. 이 턴들은 유휴 상태(idle)가 아닙니다. 이는 유용한 작업이 가능해지기 전에 반드시 수행되어야 하는 파일 읽기, 편지함 확인, 상태 재구성(state reconstruction)을 의미합니다. 이는 최소한의 수치(floor)이며, 최대치(ceiling)가 아닙니다.

이러한 오리엔테이션(orientation) 패턴은 파일 액세스 데이터에서도 확인할 수 있습니다. 모든 세션에 걸쳐 파일 읽기의 23%는 활성 작업 산출물(work artifacts)이 아닌 오리엔테이션 문서(스킬 파일, 플레이북, 상태 추적기 등)였습니다. 읽기 작업(Read operations)은 전체 플릿(fleet) 규모의 모든 도구 호출(tool calls) 중 25%를 차지하며, 이는 수정(Edit)과 쓰기(Write)를 합친 14%와 대조적입니다. 이 비율은 에이전트들이 무언가를 생산하기 전에 실제로 무엇에 시간을 소비하는지를 반영합니다.

제가 직접 측정할 수 없는 부분은 세션 메모리(session memory)가 없을 때 이 수치들이 얼마나 더 악화될 것인가 하는 점입니다. 해당 플릿은 처음부터 LoreConvo와 함께 구축되었기 때문에, 비교할 수 있는 메모리 적용 전의 기준점(baseline)이 없습니다. 제가 말할 수 있는 것은, 평균 15턴의 사전 작업은 이미 시작 시점에 이전 세션의 컨텍스트(context)가 로드된 시스템을 나타낸다는 점입니다. 대안적인 상황, 즉 요약본 없이 git 히스토리, 로그 파일, 티켓 기록으로부터 상태를 재구성해야 하는 에이전트들의 경우 이 수치는 더 높아질 것입니다. 23%라는 오리엔테이션 읽기 수치는 최소한의 수치이며, 제약 없는 재오리엔테이션(re-orientation)이 어떤 모습인지를 보여주는 결과는 아닙니다.

이 모든 것의 밑바탕에 깔린 설계 선택

로컬 우선(Local-first), 단일 파일 저장 방식은 LoreConvo를 위한 부수적인 설계 선택이 아니었습니다. 그것은 플릿 유스케이스(fleet use case)를 실행 가능하게 만든 결정이었습니다.

클라우드 의존적인 메모리 시스템은 모든 에이전트 세션의 시작 부분에서 네트워크 호출 (network call)을 발생시킵니다. 정해진 일정에 따라 실행되는 플릿(fleet)의 경우, 이는 10개의 에이전트가 각각 하루에 여러 번의 네트워크 호출을 수행하며, 각 호출이 외부 서비스의 가용성에 의존하게 된다는 것을 의미합니다. 신뢰성 요구 사항은 에이전트의 수가 늘어남에 따라 더욱 복잡해집니다. 로컬 SQLite 파일은 네트워크 의존성도, 인증 왕복 (authentication round-trip)도, 모니터링해야 할 서비스 가용성도 없습니다. 에이전트가 시작될 때, 그것은 언제나 그 자리에 있습니다.

이러한 휴대성 (portability) 또한 제가 처음에 과소평가했던 실질적인 이점입니다. 플릿의 전체 메모리 — 모든 세션, 모든 결정, 모든 미결 질문 — 가 단일 파일에 저장되어 있어, 이를 백업하거나 직접 검사하거나 다른 시스템으로 전달할 수 있습니다. 종속성 (lock-in)에 대한 우려도 없으며, 마이그레이션(migration)을 원할 때 역공학 (reverse-engineer)해야 할 벤더 API도 없습니다. 데이터는 내 하드 드라이브에 있는 파일이 내 소유인 것과 동일한 방식으로 나의 것입니다.

향후 방향

만약 여러분이 예약된 에이전트나 멀티 세션 워크플로 (multi-session workflows)를 실행하고 있으며, 자동으로 이어져야 할 컨텍스트 (context)를 재설정하는 세션 설정 단계에서 상당한 시간을 소비하고 있다면, 그 오버헤드 (overhead)는 줄일 수 있습니다. LoreConvo의 자동 저장 및 자동 로드 메커니즘은 세션 간의 경계를 처리합니다. 한 번만 설정해 두면 컨텍스트가 스스로 앞으로 나아가기 시작합니다.

내보내기 (export) 및 가져오기 (import) 도구를 사용하면 세션 상태를 백업하고 기기 간에 마이그레이션할 수 있으며, 이 두 기능은 모두 무료 티어 (free-tier) 기능입니다. 여러 기기에서 동일한 에이전트를 실행하는 팀을 위해, LoreConvo Pro는 조정된 세션 공유 기능을 추가합니다. 팀원들은 loreconvo merge를 실행하여 내보낸 세션을 로컬에 통합할 수 있으며, 공유 서버가 필요하지 않고 데이터는 전체 과정 동안 기기에 머뭅니다.

플릿 패턴 (fleet pattern) — 공유 메모리를 통해 조정되는 예약된 자율 에이전트 — 은 이러한 시스템을 운영하는 한 가지 방법입니다. 이는 실제로 작동합니다. 메모리 계층 (memory layer)이야말로 시스템을 일관성 있게 만드는 핵심입니다.

단일 에이전트 사례부터 시작하여 점진적으로 확장하고 싶다면 /tools에서 사용 가능한 도구들을 확인해 보세요.

LoreConvo가 처음이시라면, 왜 Claude 세션이 0부터 시작하는지에 대한 글이 기초적인 맥락을 제공할 것입니다. 복잡한 에이전트 (Agents)를 운영하는 팀의 경우, 관측 가능성 (Observability)을 위한 에이전트 플릿 (Agent Fleet) 계측이 메모리 계층 (Memory Layer)과 병행되는 측정 계층 (Measurement Layer)에 대해 다룹니다.