폴더를 바꾸려다, 계획을 바꿨습니다

설계가 끝났으니, 이제 폴더를 만들면 될 줄 알았습니다 🤔

지난 글에서 PeterHQ의 지식관리체계를 점검하고, AKM 구조를 적용하는 방향을 정리했습니다. 그 글은 "학습·분석·방향 수립 완료, 실제 시스템 구축 및 효과 검증 전"으로 끝났습니다.

그래서 이번 주의 계획은 단순했습니다. 설계한 대로 AKM 폴더 구조를 만들고, 기존 자료를 안전하게 이관하는 것.

그런데 2주차가 끝난 지금, 만들어진 폴더는 0개입니다.

대신 이번 주에 일어난 일은 두 가지였습니다.

첫째, 실측 데이터가 계획의 전제를 뒤집었습니다. "폴더를 AKM 구조로 바꾸면 지식이 순환된다"는 전제가 틀렸다는 것을 숫자로 확인했고, 계획의 중심이 "폴더 이관"에서 "데이터가 자동으로 흐르는 폐쇄루프 구축"으로 바뀌었습니다.

둘째, 바뀐 계획을 실행해도 되는 상태로 만들었습니다. AI 에이전트 간 검토 라운드로 계획서를 정본화하고, 참고한 오픈소스를 실제로 돌려서 검증하고, 시스템 전체를 읽기 전용으로 실사했습니다.

여기에는 한 가지 전제가 있습니다. PeterHQ는 실험용 빈 저장소가 아니라, 매일 자동 백업·자동 브리핑·에이전트 검토가 돌아가는 가동 중인 운영 시스템입니다. 그 위의 지식 저장소를 잘못 이관하면 수개월치 자산과 자동화가 함께 깨질 수 있습니다. 그래서 이번 단계의 목표를 "빨리 만들기"가 아니라 "실행해도 안전한 상태 만들기"로 잡았습니다.

이번 사례는 AKM 구축을 완료한 이야기가 아닙니다. 계획을 실측으로 교정하고, 실행 전에 위험을 소진한 기록입니다. 전 과정에서 라이브 시스템 변경은 0건입니다.

1. 실측해 보니 "지식이 쌓이고 있다"는 전제부터 틀렸습니다

폴더 이관을 시작하기 전에, 실행 에이전트(Hermes)에게 현재 데이터 흐름의 실측을 요청했습니다.

결과는 예상과 달랐습니다.

60-KnowledgeBase (장기 지식)
  전체 파일: 20개
  최근 30일 변경: 0건
  마지막 갱신: 2026-06-07

같은 기간 (최근 7일)
  Projects 변경 파일: 94,428개
  Channel-Data 변경 파일: 631개
  Knowledge-External 변경 파일: 29개
  Vault 변경 파일: 2개 (그마저 AI 뉴스 브리핑)

데이터는 매일 만들어지고 있었지만, 그것이 지식으로 환류되는 연결부는 완전히 멈춰 있었습니다.

원인도 명확해졌습니다. 기존 LLM Wiki에는 폴더·스키마·승격규칙이 다 있었습니다. 없었던 것은 누가, 언제, 무엇을 기록할지 강제하는 Source Intake와 Learn Back trigger였습니다.

여기서 계획의 핵심이 재정의됐습니다.

폴더 이름만 AKM으로 바꾸는 것은 틀리고, 외부자료와 프로젝트 학습이 자동으로 AKM에 유입되도록 바꾸는 것이 맞다.

만약 실측 없이 폴더 이관부터 시작했다면, 가동 중인 시스템을 건드리는 위험은 위험대로 지면서 정작 멈춘 원인은 그대로 가져가는 전환이 될 뻔했습니다.

2. "파일 13만 개 = 지식 축적"이라는 착각도 걷어냈습니다

Projects 폴더의 13만여 파일을 보고 "프로젝트 지식이 많이 쌓였다"고 해석할 뻔했습니다.

내용을 뜯어보니 대부분은 에이전트 인프라 구축 파일(자동화·테스트·릴레이)이었습니다. 제가 원하는 고객·시장·제품·MVP 학습과는 성격이 완전히 다른 데이터였습니다.

그래서 지식을 하나의 풀로 관리하지 않고, 성격에 따라 레인을 나누기로 했습니다.

• 사업·제품 지식 = 주축

• 인프라·운영 지식 = 별도 보조 레인

별도 Vault를 만들지는 않습니다. 한 Vault·한 정본을 유지하되 폴더·인덱스·검색 범위만 분리합니다. 인프라 자료는 대량 이관하지 않고, 네 종류(현재 아키텍처 기준, 반복 운영 절차, 장애·복구 교훈, 사업을 제한하는 기술 결정)만 선별합니다.

이 결정으로 AKM의 가치 기준이 바뀌었습니다.

"파일이 얼마나 생겼는가"가 아니라, "사업·제품 판단에 다시 쓸 수 있는 학습이 얼마나 쌓였는가"

3. 질문을 던지자 2레인이 4레인이 됐습니다

2레인 구조를 받고 추가 질문을 던졌습니다.

• 시장·금융·연구·예술 같은 외부 정보는 어디에 두나?

• AI 스킬·하네스·루프 같은 기술 실험 노하우는?

• 인프라에서도 사업 인사이트가 나오지 않나?

이 문답을 거쳐 구조가 4개 지식 레인으로 재설계됐습니다.

Domain Intelligence
= 시장·금융·기술·연구·생활·예술 등
  세상을 이해하는 외부 정보

Capability Lab
= AI 모델·에이전트 방법론·자동화 등
  "우리가 무엇을 할 수 있는가"의 실험과 평가

Business & Product Learning (주축)
= 위 재료들을 사업 질문과 결합한
  고객·제품·MVP·인사이트

Infrastructure & Operations
= 운영·보안·비용·제약과
  그것이 사업에 주는 영향

핵심 통찰은 정보와 판단의 분리입니다. 시장·기술 정보는 사업지식이 아니라 그 재료이고, Business & Product는 저장소가 아니라 여러 레인을 종합해 결정을 만드는 판단 레이어입니다.

예를 들면 이렇게 결합됩니다.

Domain Intelligence:
"중소기업의 생성형 AI 도입은 늘지만
 고객 데이터 외부전송 거부감이 높다"

        + 프로젝트 질문과 결합
        ▼

Business Insight:
"민감문서를 로컬에서 처리하는 도구는
 회계·법무 인접 사업자를 초기 고객으로 삼을 수 있다"

폴더 구조도 이에 맞춰 두 축으로 정리했습니다. 최상위는 주제가 아니라 생명주기(sources → knowledge → context → procedures → actions → evaluation → outputs)로 두고, 각 계층 안에서 4개 레인을 나눕니다. 초기에는 빈 하위 폴더를 만들지 않고 metadata로 먼저 분류합니다.

4. "쌓기"와 "쓰기"의 장치를 계획에 박아 넣었습니다

방향 전환을 반영해 구축 계획 자체를 수정했습니다. 핵심 장치는 네 가지입니다.

자동 축적과 검토 승격의 경계

자동 축적 허용 (draft 상태)
  Source Card, 프로젝트 Context,
  ResultCard, 지식·절차·실패 후보

검토 후 승격 (단일 maintainer 통제)
  verified 지식, 정식 Procedure,
  기존 지식의 강화·축소·폐기

에이전트가 정본 지식을 마음대로 쓰면 오염되고, 전부 사람이 검토하면 다시 멈춥니다. 후보는 자동, 승격은 통제가 균형점이었습니다.

두 개의 축적 엔진 — 당초 계획의 저장 기능 하나로는 부족하다는 결론이 나왔습니다. 외부자료용 Source Intake Adapter와, 내부 프로젝트의 결정·실험·실패·산출물에서 AKM 후보를 만드는 Project Learn Back Adapter를 각각 둡니다.

재사용 강제 장치 — 별도 시스템을 만들지 않고, 기존 목표 관리 흐름(/goal)의 5개 시점(시작, 고객·문제 확정 전, MVP 범위 전, 실험 설계 전, 종료)에 내부 검색 Gate를 붙입니다. metadata 검색 후 관련 카드 최대 3개만 읽는 절제된 방식입니다.

변화 속도 기준의 주기 수집 — 분야가 아니라 변화 속도로 수집 주기를 정합니다. 금융·AI 출시는 일간/이벤트, 산업 트렌드는 주간, 과학 원리·문화는 월간. 변화가 없으면 노트를 만들지 않습니다.

그리고 구축 단계 전체를 게이트 구조로 재편했습니다.

계획 정본화 (문서 검증)
→ M0   읽기 전용 실사
→ M0.5 격리 공간에 백업 표본 복원
→ M1   4레인 구조 전환        ← 첫 실제 변경
→ M2   축적 엔진 2개 구축
→ M3   /goal Gate 연결
→ M4   프로젝트 A→B 재사용 검증

각 단계는 앞 단계가 통과해야만 진행하고, M0.5까지는 정본을 한 바이트도 건드리지 않습니다.

5. 계획서가 검토 에이전트에게 두 번 반려됐습니다

바뀐 방향을 담은 계획서(1,082줄)를 독립 검토 에이전트에게 넣었습니다.

결과는 반려였습니다. 검사기준 자기모순, 검사범위 구멍, 필드 불일치, 관리자 미지정 — 4건. 수정본을 다시 넣자 새 결함 4건으로 또 반려됐습니다. 3라운드째의 수정본이 최종 승인됐습니다.

이 과정에서 지킨 원칙이 두 가지 있습니다.

첫째, 판정도 검증했습니다. 처음 받은 반려 메시지는 Discord 길이 제한으로 사유가 잘려 있었습니다. 판정문 전문 파일을 해시 검증 후 읽고, 계획서 원문과 대조해 4건 모두 실제 결함이 맞음을 확인한 뒤에야 수정을 진행했습니다. 승인 후에도 "반영 완료" 보고를 그대로 받지 않고, 정본 해시·판정문·구 계획서의 대체 표기까지 전 항목을 실물 대조했습니다.

둘째, 승인 즉시 문서 라운드를 동결했습니다. 비차단 개선 제안은 전부 다음 단계 명세로 흘려보냈습니다. 검증 라운드에 종료 조건이 없으면 문서 작업 자체가 목적이 되어버리기 때문입니다.

실행 단계에서는 이 계획서가 유일한 기준이 됩니다. 여기서 잡은 결함 8건은, 라이브 전환 중에 터졌을 사고 8건을 미리 치운 것과 같습니다.

6. AKM의 원조 저장소를 찾았고, "통째 설치"는 하지 않기로 했습니다

이 과정에서 중요한 발견이 있었습니다. 우리 계획의 계층 번호 체계와 Learn Back 개념이 오픈소스 저장소 DECK6/akm에서 온 것임을 확인한 것입니다.

자연스러운 질문이 나왔습니다. "원조가 있다면 통째로 설치하는 게 빠르지 않나?"

처음에는 저장소 요약만 보고 판단하려 했습니다. 그러다 "돌려봐야 안다"는 지적을 받고, 통째로 클론해 시스템 문서 15종을 전부 정독하고, 함정 5개를 심어 실제 실행 실측까지 진행했습니다.

결과는 요약만으로는 알 수 없던 것들이었습니다.

실측 결과
  우리 상태 어휘(verified)  → 스키마 충돌, 오류 처리됨
  시크릿 유출               → 경고만 내고 통과 (차단 게이트 불가)
  Discord 토큰              → 아예 미탐지

통째 설치는 빨라 보여도, 가동 중인 시스템 기준으로는 오히려 위험한 지름길이었습니다. 시크릿이 경고만 받고 지식 저장소에 들어가는 구조를 그대로 들여오는 셈이니까요. 빨라지는 것은 폴더 뼈대뿐이고, 비싼 것(안전장치·독립승인·검토 연결)은 원조에 없었습니다.

결론은 통째 설치 금지, 분류 지능만 가져오는 개작(ADAPT). 개작 후보 4개를 다음 단계 지시문으로 정리했습니다.

7. 실행 전 마지막 게이트로 "읽기 전용 실사"를 완료했습니다

이관을 시작하기 전, 현재 시스템의 실제 상태를 파악하는 읽기 전용 실사(M0)를 진행했습니다. "지금 시스템이 어떤 상태인지 모르면서 옮기기 시작하면 안 된다"는 원칙에 따라 계획에 명시해 둔 게이트입니다.

실사 수집기는 실행 에이전트가 만들었지만, 실행 전에 두 가지를 확인했습니다.

• 스크립트 해시 검증

• 코드 전문 정독 (1차 276줄, 2차 389줄) — 쓰기 작업이 증거 JSON 1개뿐임을 확인

그 후에야 실행했습니다. 결과는 54.9MB의 실측 데이터, 시스템 변경 0건. 검토 에이전트가 5라운드(증거불충분 2회 포함)를 돌린 끝에 승인했습니다. 실사에서 나온 사실들(사장된 폴더, 빈 폴더, 낡은 매니페스트)은 그대로 이관 계획의 정확도를 높이는 재료가 됐습니다.

8. 에이전트 둘이 합의한 결론이 오판이었습니다

실사 결과 중 하나가 걸렸습니다.

"백업 목적지 0건 → 다음 단계 차단"

작성 에이전트와 검토 에이전트가 둘 다 동의한 결론이었지만, 제 기억과 충돌했습니다. 백업은 분명히 만들어뒀는데?

호스트를 직접 조회해 보니, 백업 시스템은 멀쩡히 가동 중이었습니다.

실제 상태
  SSD 전체 → 클라우드 암호화 백업, 매일 03:00
  30일 버전 보존
  매일 표본 20파일 자동 복원 + 해시 검증

수집기가 macOS 기본 백업(Time Machine)만 조회하는 사각지대 때문에 놓친 것이었습니다. 검토 에이전트도 같은 수집 데이터를 봤기 때문에, 데이터의 구멍을 함께 물려받았습니다.

이 증거를 고정하는 2차 수집기를 실행해(오류 0) 재평가 자료를 확보했습니다.

작성자와 검토자를 분리해도, 같은 데이터 소스를 보면 함께 틀릴 수 있다 — 이번 주의 가장 값진 실증이었습니다. 동시에 "백업이 실제로 살아 있고 매일 복원 검증까지 된다"는 확인 자체가 이관 전 안전망 점검이 됐으니, 실사 게이트가 의도대로 작동한 사례이기도 합니다.

1. 지식관리가 멈추는 원인은 구조가 아니라 방아쇠의 부재였습니다

폴더·스키마·승격규칙이 다 있어도, "누가 언제 무엇을 기록할지" 강제하는 트리거가 없으면 시스템은 멈춥니다. 실측(30일 변경 0건)이 이것을 증명했고, 계획의 중심이 "이관"에서 "유입 장치"로 바뀌었습니다.

좋은 구조를 만드는 것보다, 데이터가 흐르게 만드는 것이 먼저였습니다.

2. 정보와 판단은 다른 지식입니다

시장·금융·기술 정보(Intelligence), 기술 실험(Capability), 운영 제약(Infrastructure)은 재료이고, 사업 지식은 이들을 프로젝트 질문과 결합한 판단입니다.

이 구분이 없으면 "유용해 보이는 모든 것"이 한 폴더에 쌓여, 정작 사업 검색이 오염됩니다. 4레인 구조는 이 구분을 폴더와 검색 범위에 강제하는 장치입니다.

3. 가동 중인 시스템의 전환은 "실행해도 되는 상태 만들기"가 먼저입니다

2주차인데 폴더 하나 안 만들었냐고 물을 수 있습니다. 맞습니다. 그리고 그것이 의도였습니다.

빈 저장소라면 폴더부터 만들고 고치면 됩니다. 하지만 매일 백업과 자동화가 도는 시스템 위의 자산은 이관 실수를 되돌리기 어렵습니다. 이번 주의 산출물은 폴더가 아니라 "실행해도 된다는 검증된 근거"입니다 — 승인된 정본 계획, 원조 저장소 실측 판정, 시스템 실사 데이터, 백업이 실제로 살아 있다는 증거.

계획 검증에서 잡은 결함 8건과 오판 1건은, 라이브 전환 중에 터졌다면 훨씬 비쌌을 사고입니다. 위험을 실행 전 단계로 끌어와서 미리 소진한 것입니다.

다만 안전을 위한 검증도 라운드만 돌면 그 자체가 낭비가 됩니다. 그래서 승인 즉시 동결을 선언하고, 비차단 개선을 다음 단계로 흘려보내는 종료 조건을 반드시 붙였습니다.

4. AI 에이전트의 판정도 실물 대조 없이는 믿을 수 없습니다

이번 주에 에이전트의 보고·판정·인용 문서·커밋 해시를 전부 독립 경로로 재검증했습니다. 그 덕에 오판 1건(백업)과 신규 갭 1건(토큰 미탐지)을 잡았습니다.

특히 백업 건이 중요합니다. 작성 에이전트와 검토 에이전트가 분리되어 있어도, 같은 수집 데이터를 보면 데이터의 구멍을 함께 물려받습니다. 교차 검증 체계에는 데이터 소스 자체를 의심하는 세 번째 눈이 필요합니다. 이번에는 그 역할을 사람의 기억과 호스트 직접 조회가 했습니다.

5. 오픈소스는 문서가 아니라 실행으로 평가해야 합니다

함정을 심어 실제로 돌려보는 방식이 README 정독보다 훨씬 많은 것을 알려줬습니다. 스키마 충돌, 시크릿 통과, 토큰 미탐지 — 셋 다 요약만 봐서는 알 수 없는 결함이었습니다.

"통째 도입 vs 개작" 같은 의사결정은 실측 없이는 결국 감으로 하게 됩니다.

6. 이번 주에 한 것과 안 한 것 ⚠️

이번 단계에서 완료한 것은 다음과 같습니다.

• 데이터 흐름 실측과 원인 확정 (Source Intake·Learn Back trigger 부재)

• 계획의 방향 전환 (폴더 이관 → 폐쇄루프 구축)

• 4개 지식 레인 구조 확정

• 수정된 구축 계획(M0~M4 게이트)의 정본화 — 검토 3라운드 통과

• 원조 오픈소스(DECK6/akm) 실측 검증과 개작 방침 확정

• M0 읽기 전용 실사 완료 (검토 5라운드 승인)

• "백업 없음" 오판 정정과 실물 증거 확보

아직 다음 작업은 수행하지 않았습니다.

• AKM 폴더 생성과 구조 전환 (M1)

• 축적 엔진 구현 (M2)

• /goal Gate 연결 (M3)

• 프로젝트 A→B 재사용 검증 (M4)

따라서 현재 상태는 다음과 같습니다.

계획 정본화·실행 전 검증 완료
실제 구축(첫 파일 변경)은 다음 게이트부터

마무리

지난 글은 "어떤 자료를 Wiki에 저장할 것인가"에서 시작해 "배움이 다음 프로젝트로 이어지는가"라는 질문으로 끝났습니다.

이번 주에는 그 질문이 한 번 더 구체화됐습니다.

구조를 바꾸면 지식이 순환될 것인가? — 아니다. 데이터가 자동으로 유입되고, 프로젝트가 끝날 때마다 학습 후보가 남고, 다음 프로젝트가 그것을 먼저 검색하는 폐쇄루프를 만들어야 순환된다.

그리고 이 폐쇄루프를 가동 중인 시스템 위에 얹는 일이기에, 실행 전에 계획을 실측으로 교정하고, 에이전트 검토로 결함을 소진하고, 읽기 전용 실사로 현재 상태를 고정했습니다.

다음 글에서는 드디어 첫 실제 변경 — 4레인 구조 전환(M1)과 축적 엔진 구축 이야기를 쓸 수 있을 것 같습니다. 폴더가 만들어지는 것보다, 그 폴더에 데이터가 흐르기 시작하는지를 기준으로 보고드리겠습니다. 🚀

도움 받은 글

논의 및 점검 기록

• 데이터 흐름 실측과 방향 전환 논의 (Discord, 박전무 회신)

• 4레인 구조 설계 문답

• 계획서 검토 라운드 (Revision B→C→D) 및 M0 실사 기록

본 사례의 수치와 진행 상태는 2026년 8월 6일 기준으로 작성했습니다.