60개 이상의 Claude Code 메모리 항목을 통해 배운 1인 운영(Solo Ops)에 관한 교훈

저는 유료 인프라 서비스를 운영하고 있습니다. 혼자서 말이죠. 공동 창업자도, 온콜(on-call) 순번도, 문제를 에스컬레이션(escalate)할 시니어 엔지니어도 없습니다. 저의 유일한 협업자는 Claude Code이며, 약 1년이 지난 지금 저의 지속성 메모리(persistent memory)는 60개 이상의 항목으로 늘어났습니다.

이 항목들은 제가 작성한 그 어떤 런북(runbook)보다 더 가치 있는 존재가 되었습니다. 또한 이 과정에서 메모리 아키텍처(memory architecture)가 어떻게 작동하는지, 그리고 무엇이 그것을 조용히 실패하게 만드는지를 고통스럽게 배웠습니다.

만약 여러분이 AI 에이전트(AI agent)와 함께 무언가를 혼자 운영하고 있다면, 제가 첫날에 머릿속에 새겨두었으면 좋았을 다섯 가지 교훈을 공유합니다.

1. '무엇(what)'이 아니라 '왜(why)'를 작성하라

지속성 메모리(persistent memory)를 사용하기 시작할 때 가장 먼저 드는 본능은 자신이 무엇을 했는지 기록하는 것입니다. "서비스 X를 도구 A에서 도구 B로 마이그레이션(Migrated)함." "프로토콜을 X에서 Y로 전환함."

6개월 후, 무언가 고장 났을 때 그런 정보는 가치가 없습니다. 여러분은 무엇을 했는지 알 필요가 없습니다. git log와 git blame이 이미 그것을 알려주기 때문입니다. 여러분에게 필요한 것은 왜 그런 선택을 했는지(why)입니다. 어떤 제약 조건이 그것을 강제했는지, 어떤 대안을 제외했는지 알아야 합니다.

실제 사례입니다. 제가 예전에 작성했던 좋지 않은 버전의 항목입니다:

워커 풀(worker pool)을 호스트의 Docker 컨테이너에서 systemd 유닛으로 전환함.

이것은 제 git 히스토리가 알려주지 못하는 것을 전혀 알려주지 않습니다. 다시 작성한 버전은 다음과 같습니다:

이 VPS 제공업체에서 Docker 컨테이너 대신 호스트의 systemd 유닛 사용. 이유(Why): 해당 제공업체는 테넌트(tenant) 전반에 걸쳐 공격적인 커널 수준의 OOM 스코어링(OOM scoring)을 실행함; 컨테이너들은 다른 고객의 워크로드에 의해 트리거된 oom-killer에 의해 제거되고 있었음. systemd 프로세스는 시스템 프로세스로 점수화되기 때문에 생존함. 적용 방법(How to apply): dmesg | grep -i oom 명령어가 인식할 수 없는 PID로부터의 킬(kill)을 보여주는 모든 VPS — 그곳에서는 컨테이너를 실행하지 말고 systemd를 실행할 것.

이 단 하나의 항목이 세 번의 재구축(rebuild)을 막아주었습니다. 다음에

약 6개월이 지났을 때, 저는 메모리 감사(audit)를 수행했습니다. 60개의 항목 중 14개가 더 이상 존재하지 않는 것들을 참조하고 있었습니다. 이름이 변경된 파일 경로, 삭제된 함수, 그리고 그 이후에 교체된 아키텍처(architecture) 등이 있었습니다.

그 비용은 단순히 무관한 컨텍스트(context)를 제공하는 데 그치지 않았습니다. 그것은 적극적으로 오도하는(misleading) 컨텍스트였습니다. 에이전트(agent)가 특정 파일 경로를 가리키는 메모리 항목을 불러왔는데 해당 파일이 존재하지 않으면, 에이전트는 막다른 길에 다다르거나 내용을 꾸며내곤 했습니다.

정기적인 감사를 시도해 보았습니다. 효과가 없었습니다. 결국 건너뛰게 되더군요. 효과가 있었던 방법은 다음과 같습니다: 작업 도중 메모리 항목을 읽을 때마다 즉각적인 결정을 내리는 것입니다. — 아직 유효한가? 맞다면 그대로 둔다. 아니라면 그 즉시 수정하거나 삭제한다.

메모리는 백업이 아닙니다. 그것은 살아있는 의존성(dependency)입니다. 운영 루프(operations loop) 안에 유지하거나, 아니면 그것은 그저 전설(lore)이 되어버릴 뿐입니다.

3. 피드백 메모리가 가장 레버리지가 높다. 그리고 쓰기 가장 어렵다.

저의 가장 훌륭한 메모리 항목들은 시스템을 설명하지 않습니다. 그것들은 무엇을 _하지 말아야 하는지_를 설명합니다.

"Y에서 X를 실행하지 마세요." "이 접근 방식은 지난 분기에 시도했다가 사흘 밤 동안 디버깅(debugging)을 해야 했으므로 피하세요." "이 UI 단축키는 빨라 보이지만 조건 Z 하에서는 작동하지 않습니다."

이러한 항목들은 동일한 함정을 다시 발견하는 것을 방지해주기 때문에 가장 많은 시간을 아껴줍니다. 하지만 동시에 제가 스스로를 채찍질하며 써 내려가야 하는 항목들이기도 합니다. 무언가를 디버깅하느라 4시간을 보낸 직후에는, '고쳤으니 끝났다, 배포하자(ship it)'라는 충동이 들기 때문입니다. '여기 5분만 더 앉아서 내가 거의 놓칠 뻔했던 것을 기록하자'라는 생각은 들지 않습니다.

이제 저는 좌절스러운 디버깅 세션이 끝날 때마다 스스로에게 묻습니다: 방금 내가 과거의 내가 알고 싶어 했을 만한 무언가를 배웠는가? 만약 그렇다면 — 기록합니다. 단 두 줄이라도 말이죠.

이것들은 작성된 글자 수 대비 가장 높은 절약 효과를 내는 항목들입니다. 또한 가장 건너뛰기 쉬운 항목들이기도 합니다.

4. 검색(retrieval)을 결정하는 것은 파일이 아니라 인덱스 항목이다.

저는 인덱스 역할을 하는 MEMORY.md 파일을 유지합니다. 각 메모리 파일의 제목과 한 줄짜리 훅(hook)이 포함되어 있습니다. 수십 개의 항목을 작성한 후, 저는 불편한 사실 하나를 깨달았습니다:

인덱스 항목이 파일 내용보다 더 중요하다.

왜냐하면 인덱스가 AI가 가장 먼저 보는 것이기 때문입니다. 파일 본문은 에이전트가 읽기로 결정할 때만 로드됩니다. 그리고 그 에이전트의 결정은 전적으로 인덱스 설명에 기반합니다.

만약 webhook_replay.md가 "웹훅 관련 내용"으로 설명되어 있다면, AI는 절대 그것을 열지 않습니다. 하지만 다음과 같이 설명된다면:

Stripe 웹훅 리플레이: idempotency-key 충돌 대 event_id 재사용; 부분적인 DB 장애로 워커가 알 수 없는 상태에 남았을 때 무엇을 해야 하는지; 다시 실행해도 안전한지 알려주는 단 하나의 쿼리

— AI는 정확히 필요한 순간에 그것을 열게 됩니다.

메모리 파일은 500단어일 수 있습니다. 인덱스 항목은 100자입니다. 이 100자가 모든 검색 작업을 수행합니다.

제가 지금 새로운 메모리 항목을 작성할 때, 파일 본문에 쓰는 시간보다 인덱스 라인에 더 많은 시간을 할애합니다. 이것은 역행하는 느낌이 들지만, 그렇지 않습니다.

5. 인덱스는 컨텍스트 예산(context budget)을 가집니다

이것은 제가 힘든 경험을 통해 배운 것입니다. 제 에이전트는 특정 라인 수 이후에 MEMORY.md를 잘라냅니다(truncate). 저에게는 200라인 이후의 내용은 컨텍스트에서 조용히 사라집니다. 마치 존재하지 않는 것과 같습니다.

이는 MEMORY.md가 단순한 인덱스가 아니라 — 레이아웃 문제라는 것을 의미합니다. 어떤 200줄이 모든 대화에 살아남을 자격이 있을까요? 어떤 항목들은 디스크에 보관하기에는 충분히 좋지만, 매번 로드할 만큼 중요하지는 않을까요?

가지치기(Pruning)는 단지 잘못된 것이 된 것을 삭제하는 것만이 아닙니다. 그것은 무엇이 컨텍스트를 얻을 자격이 있는지를 결정하는 것입니다.

제 현재 규칙은 이렇습니다: 만약 제가 두 달 동안 메모리 항목을 읽거나 사용하지 않았고, 그것이 핵심적인(load-bearing) 내용이 아니라면, 인덱스 라인을 아래로 내리거나 제거합니다. 파일 자체는 고고학적 목적으로 디스크에 남겨둡니다. 하지만 인덱스 라인은 신성한 자산입니다.

제가 이것들을 가지고 하는 일

저는 제가 수렴시킨 스키마 — 메모리 템플릿, MEMORY.md 레이아웃, 고신호(high-signal) 쓰기를 유발하는 데 사용하는 프롬프트, 감사 의식(audit rituals) — 를 Claude Code를 사용하는 솔로 오퍼레이터들을 위한 키트로 패키징하고 있습니다.

이것은 제가 첫날부터 가지고 있었으면 좋았을 키트입니다. solosre.dev에서 확인할 수 있습니다.

만약 이러한 실패 모드(failure modes) 중 익숙하게 느껴지는 것이 있다면 — 즉, 당신의 AI 메모리(AI memory)가 표류하거나, 잘못된 정보를 제공하거나, 혹은 조용히 제 역할을 다하지 못하기 시작했다면 — 이를 해결할 수 있는 구조적인 방법이 있습니다. 저처럼 60개의 항목을 통해 이 과정을 직접 학습할 필요는 없습니다.

만약 당신이 Claude Code(또는 지속적인 메모리(persistent memory)를 가진 모든 에이전트)를 사용하여 1인 운영(solo)을 하고 있다면, 무엇이 효과적이었고 무엇이 문제였는지 댓글로 들려주세요. 아무도 말해주지 않는 교훈이야말로 대개 가장 큰 고통을 줄여주는 법입니다.