콕핏(Cockpit)의 다음 병목 구간은 「기억」이었다

콕핏(Cockpit, 하코)이 구축되고, 통신(Protocol)이 이루어지면서 하루에도 수십 개의 PR이 흐르게 되었습니다. 그러자 다음 문제가 보이기 시작했습니다.

다음 날 아침, 모든 것이 사라져 있다.

worktree는 공양(폐기)되고, 작업자 에이전트(Agent)의 세션은 파기되며, 사령탑의 컨텍스트(Context)도 다음 세션에서는 백지상태가 됩니다. 하루 동안의 운용에서 빠졌던 함정, 내렸던 설계 판단, 작업자가 보고해 온 「깨달음」 —— 이들은 어디로 가는 것일까요?

방치하면, 어디로도 가지 않습니다. 똑같은 함정에 다시 빠지고, 똑같은 논의를 다시 반복합니다. 에이전트의 가동 시간은 늘릴 수 있어도, 학습의 복리가 작용하지 않습니다. 이것이 콕핏의 세 번째 병목 구간이었습니다.

대책으로서 만든 것은, 방향이 다른 **2개의 환류로(Return Path)**입니다.

인간으로 치면, 전자는 「몸으로 익히는」 절차 기억(Procedural Memory), 후자는 「일기에 써서 되돌아보는」 일화 기억(Episodic Memory)입니다. 목적지도, 갱신 규칙도 완전히 별개로 설계해야 했습니다. 순서대로 살펴보겠습니다.

1. 절차의 기억: SOP의 자기 갱신 프로토콜

슬래시 명령어는 「절차서」로 진화하고 있었다

통신 편에 등장했던 /wt

(worktree 생성 ~ 에이전트 위임 명령어)는 운용을 거듭하면서 단순한 명령어 정의가 아니게 되었습니다. 그 내용은 절차·제약·트러블 대응의 집합체 —— 인간 조직으로 치면, 이것은 **SOP (Standard Operating Procedure: 표준 작업 절차서)**입니다.

「에이전트에 대한 지시는 프롬프트(Prompt)가 아니라 SOP로서 작성한다」는 사고방식에는 선행 구현 사례가 있습니다: strands-agents/agent-sop.

AWS에서 시작된 오픈 소스 에이전트 프레임워크인 Strands Agents 에코시스템의 일부로, 「자연어로 작성된 워크플로우(Workflow)를 통해 에이전트가 복잡한 멀티 스텝 태스크(Multi-step Task)를 일관되게 실행하도록 하는」 SOP 형식을 정의하고 있는 프로젝트입니다.

SOP는 다음과 같은 구조의 Markdown으로 구성됩니다.

• Overview —— 목적과 사용 시점
• Parameters —— 입력 정의 (필수/옵션). 단발성 프롬프트와 달리 파라미터화되어 있어 문맥을 바꾸어 재사용 가능
• Steps —— 단계적인 절차. 제약 사항은 RFC 2119의 키워드 (MUST / SHOULD / MAY)로 작성
• Examples —— 구체적인 실행 예시
• Troubleshooting —— 자주 발생하는 문제와 대처법

설계 사상의 핵심은 「엄격한 스크립팅(Scripting) 없이, 정밀한 제약으로 에이전트의 행동을 제어한다」는 입장입니다. 코드로 묶는 것도 아니고, 그렇다고 산문 형태의 프롬프트로 바라는 것도 아닙니다. RFC 2119라는 「인터넷 표준 사양서를 작성하기 위한 어휘」를 빌림으로써, 자연어 상태 그대로 제약의 강도 —— 절대(MUST)・권장(SHOULD)・임의(MAY) —— 를 기계적으로 구별할 수 있습니다. 에이전트가 읽는 문서에서 가독성과 구속력을 양립시키는 발명입니다.

이 형식을 /wt와 /wtclean에 적용한 결과, 산문에 녹아있던 규칙들이 /wt만으로 제약 사항 35개로 현상화되었습니다.

SOP화의 직접적인 동기는 사실 사고였습니다. 사령탑이 작업자에게 내린 「일회용 윈도우에서 검증하고, 끝나면 닫으라」는 산문 형태의 지시가 후술할 기존 윈도우의 오작동(誤kill) 사고를 초래했습니다. 「끝나면 닫으라」는 제약으로서 너무 모호했던 것입니다.

산문을 SOP로 변환하면 다음과 같이 변합니다.

• MUST: 기동 시 $!로 PID를 포착할 것
• MUST NOT: 이름 매칭(pgrep)으로 대상을 특정하여 kill 하지 말 것

이와 같은 검증 가능한 제약으로 바뀝니다.

또한 변환 작업에도 규칙을 두었습니다.

포맷 변환과 내용 변경은 PR을 분리한다 (동작을 바꾸지 않는 리팩토링과 기능 추가를 분리하는 것과 동일한 유형), 변환 PR에서는 기존 규칙의 소실·약화·강화를 모두 금지한다.

SOP는 이후 모든 에이전트의 행동 규범이 되기 때문에, 변환 과정의 혼란으로 인해 제약이 변질되는 것이 가장 두렵기 때문입니다.

SOP가 된 순간, 흥미로운 질문이 생깁니다. "절차서는 운영 중에 빠진 함정을 먹으며 성장할 수 있지 않을까?"

환류(Recirculation)의 입력은 3가지 경로

/wt에 「절차 7: 자기 업데이트 (Self-update)」라는 단계를 추가했습니다. 입력은 세 가지입니다.

• 작업자로부터의 깨달음 보고 —— 통신 편에서 설계한 「깨달음 (필수)」란. 지시 외의 함정이나 회피책은 해결되었더라도 보고할 의무가 있음
• 공양 (供養) —— /wtclean (worktree 정리 명령)이 머지(merge)된 태스크를 정리할 때, 남은 지견을 Issue 후보로 추출함
• 사령탑 자신의 운영 실수 —— pane-id 대상 오류, 로컬 main 업데이트 누락 등

에이전트 운영에서 발생하는 배움의 발생원을 거의 이 세 가지로 포착할 수 있습니다.

필터: 전부 기억하지 않는다

하지만 입력을 전부 SOP에 적으면 절차서가 비대해져서 죽고 맙니다. 그래서 필터를 제약 사항으로 명시했습니다.

MUST: 사령탑은 필터를 적용한다. 「재발 가능성」이 있고 「태스크를 가로지르는 (cross-task)」 지견만을 대상으로 하며, 단발성 또는 특정 태스크에 국한된 지견은 대상에서 제외한다 (과적합 (overfitting)에 의한 SOP 비대화 방지)

머신러닝 (Machine Learning)의 정규화 (Regularization) [3]와 같은 발상입니다. 단발성 사건에 절차서를 맞추려 하면, 과적합 (Overfitting) [4]되어 일반화 성능 (Generalization performance) [5]이 떨어집니다.

실제로 이 메커니즘의 설계 판단은 머신러닝의 기초 개념과 그대로 대응합니다 [6].

SOP의 비대화는 과적합, 환류 필터는 정규화, 「재발 가능성 × 태스크를 가로지르는」이라는 채택 기준은 일반화 성능의 확보, 그리고 다음에 서술할 인간 리뷰 게이트는 학습률 (Learning rate)의 안전밸브 [7]입니다.

「학습이 복리로 작용하는 계통을 어떻게 발산시키지 않고 키울 것인가」라는 질문은, 모델의 훈련에서도 에이전트의 조직에서도 같은 형태를 띠고 있습니다.

그렇기에 설계 판단은 모두 머신러닝의 어휘로 치환하여 검산할 수 있습니다.

그것이 이 메커니즘의 품질 보증 (Quality Assurance) 이기도 합니다.

안전밸브: 자기 기안은 하되, 자기 머지는 하지 않는다

필터를 통과한 지견은 해당 SOP에 대한 diff 안으로서 Issue화 → 작업자에게 위임 → PR → **인간 리뷰 및 머지 (Human review & merge)**라는 통상적인 개발 플로우를 탑니다. 여기서 가장 중요한 제약이 이것입니다.

MUST NOT: 사령탑이나 작업자가 스스로 머지하지 않는다. 자기 업데이트는 「자기 기안」이지 「자기 머지」가 아니다 (자신의 행동 규범을 스스로 다시 쓰는 루프는, 잘못된 교훈의 일반화가 이후의 모든 에이전트에게 복리로 작용하기 때문에, 인간 게이트를 안전밸브로서 유지한다)

SOP는 모든 후속 에이전트가 읽는 「행동 규범」이므로, 여기에 잘못된 교훈이 혼입되면 이후의 모든 태스크에 복리로 영향을 미치게 됩니다. 학습의 복리를 원해서 만든 메커니즘이기에, 오학습 (Mislearning) 또한 복리로 작용한다는 점을 잊어서는 안 된다는 설계 판단입니다.

실록: 자기 업데이트 루프의 첫 실행

이 프로토콜을 구현한 PR (dotfiles #360)의 본문에는 이렇게 적혀 있습니다.

이 PR 자체가 자기 업데이트 루프의 첫 실행이다 (함정에 빠짐 → 깨달음 보고 → 공양 → Issue화 → 작업자 위임 → 이 PR, 이라는 일련의 흐름의 실례)

파일럿으로서 각인된 교훈은 3건입니다. 작업자가 사용자의 기존 윈도우를 실수로 kill한 사고 (#354), mergeStateStatus: BLOCKED를 「CI 대기 중」으로 오독하여 모니터링이 90분간 대기한 건 (#355), worktree 생성 전 로컬 main 업데이트 누락 (#356). 3건 모두 그날 안에 SOP의 제약 사항과 Troubleshooting 섹션으로 반영되었습니다.

3일 후에는 환류 3건을 한꺼번에 반영하는 PR (#387)이 이어집니다. 문서 대전환 시의 기계적 diff 체크 의무, squash merge 운영 시 발생하는 git branch -d 경고의 올바른 읽기법, Nerd Font의 PUA 글리프가 툴 쓰기 작업 중 바이트가 소실되는 함정에 대한 안전 절차 —— 이 모두 실제 운영 중에 실제로 겪은 것들뿐입니다.

현재 /wt의 Troubleshooting 섹션은 날짜와 Issue/PR 번호가 붙은 실패 사례 카탈로그가 되어 있습니다. 에이전트는 매번 이를 읽고 나서 작업에 들어가므로, 같은 구멍에 빠지지 않습니다. 절차의 기억은 이렇게 복리가 되었습니다.

2. 지식의 기억: 세션을 Zettelkasten으로 증류하기

SOP에 적을 수 없는 배움이 있다

그런데 SOP 환류(SOP circulation)의 필터에서 걸러지는 쪽 —— 「왜 그런 설계를 했는가」, 「어떤 질문을 다시 던졌는가」와 같은 사고의 과정은 절차서에 적을 수 없습니다. 하지만 이것이야말로 몇 달 후의 내가 가장 필요로 하는 정보이기도 합니다.

이들의 목적지는 Obsidian에서 운용 중인 Zettelkasten입니다. /session-log라는 스킬(처음에는 슬래시 커맨드(slash command)로, 나중에는 스킬로 승격)이 이 역할을 담당합니다.

생(Raw) 로그의 전사(Transcription)가 아닌, 판단의 엄선된 기록

/session-log가 하는 일은 세션의 의사결정·통찰·성과물을 ResearchNotes/ClaudeCodeSession-YYYYMMDD-<TopicSlug>.md라는 하나의 노트에 엄선하여 써 내려가는 것입니다. 스킬 정의의 첫 번째 줄에 그 성격이 나타나 있습니다.

생 로그의 전사가 아니라, 대화에서 태어난 판단·설계·배움의 엄선된 기록입니다.

노트의 구조는 「계기·문제의식 → 주요 통찰(2~5개) → 결정 사항·성과물 → 다음 단계·숙제 → 관련 링크」로 구성됩니다. frontmatter에는 출처도 기록됩니다. vault는 모든 머신이 공유(Obsidian Sync)되므로, uname -r에 microsoft가 포함되어 있는지에 따라 업무용 기기(WSL)인지 개인용 기기(Arch native)인지 자동 판정하여, context: work / personal, machine: wsl / arch-native를 기록합니다. 어떤 문맥에서 태어난 지식인가는 나중에 증류(distillation)할 때 매우 중요한 메타데이터가 됩니다.

명명 규칙이 「뷰(View)의 계약」이 된다

작성된 노트는 Obsidian의 Bases로 만든 ClaudeCodeSessions.base라는 뷰(view)에 자동으로 모입니다. 장치는 단순합니다. 파일명 접두사(prefix)인 ClaudeCodeSession- 자체가 뷰의 필터 조건 그 자체입니다. 스킬 측에는 「명명 규칙을 깨뜨리지 말 것」이라는 제약 사항으로 명시되어 있습니다. 명명 규칙이 스킬과 뷰 사이의 인터페이스 계약(interface contract) 역할을 하는 셈입니다.

이 뷰의 이름은 「미증류의 산(Un-distilled mountain)」입니다. 즉, 여기에 쌓여 있는 것은 완성품이 아니라 중간 생성물이라는 선언입니다.

2층 증류: AI가 1층, 인간이 2층

왜 「미증류」일까요? 이 파이프라인은 2개의 층으로 나뉘어 있기 때문입니다.

그리고 2층에는 이 vault 운용에서 가장 일관성 있는 규칙이 있습니다. 운용 원칙에서 인용한 내용입니다.

LLM 생성 콘텐츠는 Research Notes 층에 머물게 한다. Permanent Notes는 자신의 언어로만 작성한다.

AI의 출력을 그대로 지식 베이스의 최심부에 흘려보내면, 「읽은 것 같은 기분만 들 뿐, 자신의 혈육이 되지 않은 지식」으로 오염됩니다. 따라서 LLM 생성물은 ResearchNotes 층에서 **검역(quarantine)**하고, Permanent Notes로의 승격은 인간이 자신의 언어로 다시 쓸 때만 허용합니다. /session-log의 스킬 정의에도 「2층은 사용자 자신이 주간 리뷰를 통해 수행하므로, 이 스킬은 관여하지 않는다」라고 명시되어 있어, AI의 관할 밖임을 분명히 하고 있습니다.

증류를 촉진하는 장치도 있습니다. 데일리 노트(daily note)에는 Distillation > Permanent Notes Candidates라는 섹션이 있으며, /session-log는 승격될 가능성이 있는 지식을 「질문」의 형태로 한 줄씩 남겨둡니다 (예: 「폴더는 보관의 구조, 액세스는 선언한다 —— 일반화할 수 있는가?」). 이는 주간의 자신에게 보내는 AI의 인수인계입니다.

축적의 실적

이 시스템을 통해 ResearchNotes에는 ClaudeCodeSession- 노트가 81개 축적되어 있습니다 (2026-07-27 기준). 밀도가 높았던 날은 하루에 7개씩 쌓였습니다. vault 재정리, Hyprland [8]의 3층 워크스페이스 설계, WezTerm으로의 피보트(pivot) 검토 —— 콕핏(cockpit)에서 돌렸던 나날의 사고가 그대로 검색 가능한 자산이 되어 있습니다.

3. 두 개의 환류로는 사실 연결되어 있다

이 두 가지는 독립된 메커니즘이 아닙니다. 실제 노트를 통해 보여드리겠습니다.

ClaudeCodeSession-20260705-HyprlandThreeLayerAndSopSelfUpdate.md

라는 노트에는 작업자의 실수로 인한 kill 사고(#354)에 대해, 작업자의 보고 원문 인용과 다음과 같은 분석이 남아 있습니다.

원인의 구조: "자신이 실행한 프로세스"의 식별을 실행 시점의 PID 포착($!)이 아닌, 사후 이름 매칭(pgrep)으로 수행함 + 실행이 확인되지 않는 시점에서 중단했어야 함에도 추측으로 계속 진행함. 근본 원인은 사령탑(자신)의 지시가 산문적(prose)이었다는 점: "일회용 윈도우에서 검증하고, 끝나면 닫는다"는 제약 조건(constraint)으로서 모호함 → SOP(표준 작업 절차)화의 직접적인 동기가 됨

즉, 이 노트는 SOP 환류가 일어난 이유 그 자체를 저장하고 있습니다. 역할 분담은 다음과 같습니다.

• SOP가 저장하는 것은 "무엇을 해야 하는가" —— 실행 시 $!로 PID를 포착할 것, 이름 기반의 pgrep으로 kill 하지 말 것
• Zettelkasten이 저장하는 것은 "왜 그렇게 되었는가" —— 어떤 사고가 있었고, 무엇이 근본 원인이었으며, 어떤 논의를 거쳐 그 제약에 도달했는가

SOP만 있다면, 반년 뒤에 제약의 이유를 알 수 없게 되어 "이 제약, 이제 필요 없지 않아?"라며 실수로 삭제할 리스크가 있습니다. 노트만 있다면, 다음 에이전트의 행동은 변하지 않습니다. 절차의 기억과 지식의 기억은 서로의 약점을 보완하도록 설계되어 있습니다.

또 다른 연결점은 진실의 단일 원천(SSOT, Single Source of Truth)입니다. vault 측의 운영 규칙은 MOC-ObsidianWorkflow.md의 "액세스 패턴 선언"이 정답이며, /session-log 스킬에는 "본 스킬의 기재 내용과 상충할 경우 그것을 우선하며, 차이점을 보고한다"라는 제약이 포함되어 있습니다. dotfiles 측의 스킬과 vault 측의 선언이 어긋났을 때, 묵묵히 어느 한쪽을 따르는 것이 아니라 차이점을 보고하게 만든다 —— 드리프트 탐지(drift detection)까지 프로토콜에 포함되어 있다는 점이 핵심입니다.

4. 인간의 업무는 "게이트"로 집약된다

요약하자면, 두 개의 환류로는 모두 같은 형태를 띠고 있습니다.

AI는 기안까지, 확정은 인간이 합니다. 코크핏(Cockpit) 편에서 일관되게 인간의 업무는 "쓰는 것"에서 "승인하는 것"으로 이동해 왔으며, 기억 관리에서도 동일한 일이 일어났습니다. per-launch 서명(통신 편)이 에이전트의 행동에 대한 게이트였다면, 이번의 두 가지는 조직의 기억에 대한 게이트입니다. 행동보다 기억이 더 오래 영향을 미치는 만큼, 게이트 설계는 더욱 신중해야 합니다. —— 자기 병합(self-merge) 금지와 "자신의 언어로만 작성"은 이를 위한 안전장치였습니다.

이 형태, 낯설지 않을 것입니다. 통신 편의 레이어 0 —— "권한의 자기 확장(self-expansion)은 반드시 인간 레인(human lane)으로 떨어진다".

에이전트가 자신의 허용 목록(allowlist)을 스스로 확장할 수 없는 것과 마찬가지로, 자신의 행동 규범(SOP)도 스스로 병합할 수 없습니다. 하네스(Harness)가 쥐고 있던 불변 조건은 조직의 기억에도 그대로 적용됩니다. 레이어 0의 행동 버전이자 기억 버전인 셈입니다.

세션은 오늘도 일회용입니다. 하지만 절차는 SOP에 새겨지고, 판단은 Zettelkasten에 쌓여갑니다. 사라지는 것은 컨텍스트이지, 배움이 아닙니다. 코크핏은 마침내 어제보다 오늘 더 현명한 관제탑이 되었습니다.

마지막으로 하나.

이미 눈치채신 분도 계실지 모르겠습니다.

네, 이 기사 자체가 Zettelkasten에서 증류(distill)한 지식으로 쓰였습니다.

본문에서 인용한 사고 보고 원문도, 설계 판단의 경위도, 날짜나 PR 번호도, 출처는 모두 ResearchNotes에 쌓인 세션 로그입니다. 그것을 작성한 세션은 이미 사라졌음에도 판단은 남아 있었습니다.

두 개의 환류로가 제대로 기능하고 있다는 무엇보다 확실한 증거를, 당신은 방금 막 다 읽었습니다.

지금까지의 기사보다 훨씬 더 머리를 짜내어 이 연재의 구성을 생각했습니다. 즐겁게 읽어주셨다면, 필자는 지금쯤 화면 너머에서 아무 걱정 없이 환하게 웃고 있을 것입니다.

다음 편,

"dotfiles 운영, CI 지옥 편 —— Nix + GitHub Actions 캐시와의 전쟁"

을 기대해 주세요!!

(통신 편에서 예고한 연방제 편과, 다중 모델 합의 quorum 편도 준비 중입니다)

• 로컬 Markdown 파일로 노트를 관리하는 지식 베이스 (Knowledge Base) 앱. 양방향 링크와 그래프 뷰가 특징. 실체가 단순한 Markdown 파일이기에, 본 기사처럼 CLI 에이전트에서 직접 읽고 쓸 수 있다는 점이 결정적인 강점으로 작용한다. ↩︎

• 사회학자 니클라스 루만 (Niklas Luhmann)의 실천으로 알려진 노트법. '1노트 1아이디어'로 작성하고, 노트끼리 링크로 연결하여 지식의 네트워크를 키워나간다. 루만은 이 방법으로 약 9만 장의 카드를 축적하여 70권 이상의 저서를 남겼다고 알려져 있다. 본 기사의 'Research Notes → Permanent Notes'라는 2층 구조도, 제텔카스텐 (Zettelkasten)의 '문헌 노트 (Literature Notes) → 영구 노트 (Permanent Notes)' 구분을 기초로 하고 있다. ↩︎

• 손실 함수 (Loss Function)에 '파라미터를 무분별하게 늘리거나 크게 만들면 벌금을 부과한다'는 항 (L1/L2 노름 (Norm) 등)을 추가하여, 모델이 지나치게 복잡해지는 것을 억제하는 기법. SOP 관점에서 말하자면 '제약 조건을 하나 추가할 때마다 비용을 지불한다'고 생각하면 적당하다. ↩︎

• 훈련 데이터에 과하게 맞춰져서, 처음 보는 데이터에서 계속 틀리는 상태. 매뉴얼이 '그날의 그 사고' 형태에 너무 특화되어 있으면, 다음의 미묘하게 다른 상황에서는 도움이 되지 않는다. —— 오히려 방해가 된다. 그것과 같다. ↩︎

• 훈련에 사용하지 않은 미지의 데이터에 대한 성능. 매뉴얼의 가치 또한 '이미 겪은 함정'이 아니라 '아직 겪지 않은, 다음의 유사한 함정'을 방지할 수 있느냐에 따라 결정된다. ↩︎

• 왜 매뉴얼 이야기에서 갑자기 머신러닝 (Machine Learning) 이야기가 나오나? 라고 생각한 분들을 위해 —— 필자의 출신이 머신러닝 엔지니어이기 때문입니다. 최근에는 주로 k8s와 놀고 있지만, 머릿속은 지금도 이 어휘들로 움직이고 있습니다. ↩︎

• 정확히는 학습률 (Learning Rate)이라기보다 PPO나 GRPO의 clip · KL 페널티 (KL Penalty) 같은 것. 이 부분은 상사분이 귀신같이 잘 아시니 조만간 스터디를 열고 싶다. 1회의 업데이트로 정책 (Policy)이 너무 크게 튀지 않도록 업데이트 폭을 제한하는 장치로, 여기서는 '잘못된 교훈 1건으로 인해 SOP (=모든 후속 에이전트의 행동 규범)가 망가지는 것'을 인간 리뷰 (Human Review)로 막고 있다는 대응이다. ↩︎

• Linux (Wayland)용 타일형 컴포지터 (Tiling Compositor). 창을 마우스로 배치하는 대신, 키보드 조작으로 화면에 채워 나가는 파의 데스크톱 환경이다. 필자의 개인 PC는 Arch Linux + Hyprland 구성이며, 이 문장 하나로 독자 대다수를 소외시키고 있다는 자각은 있다. 다만, 터미널 안에 콕핏 (Cockpit)을 구축하는 듯한 인간이 데스크톱만큼은 기성품으로 만족할 수 있을 리 없다. 실물은 필자의 dotfiles에 공개되어 있으며, 3층의 설계 사상은 window-rules.conf의 주석에 그대로 적혀 있다. 자세한 이야기는 이것 또한 별도의 기사에서. ↩︎

Discussion