자료를 쌓는 Wiki에서, 다음 프로젝트를 위한 학습 시스템으로

소개

자료는 계속 쌓이는데, 왜 매번 다시 조사하게 될까? 🤔

저는 Discord에서 업무를 요청하고, Hermes를 비롯한 여러 AI 에이전트가 조사·기획·개발·검토를 수행하는 PeterHQ라는 개인·사업 운영 시스템을 만들고 있습니다.

프로젝트를 진행하면서 만들어지는 자료는 꽤 다양합니다.

• 시장 및 고객 조사 자료

• 사업 기획서

• 고객 문제와 가설

• MVP 코드와 디자인

• 실험 결과

• 성공 및 실패 기록

• AI 에이전트의 작업 과정과 검수 결과

기존 PeterHQ에서도 이런 자료를 한 폴더에 몰아넣지는 않았습니다.

Discord            = 작업 요청과 보고
Projects           = 기획서, 코드, 디자인, MVP
Knowledge-External = 웹페이지, PDF, 데이터 등 외부 원문
Channel-Data       = 작업 상태, ResultCard, 검수 및 감사 기록
Business           = 계약, 고객정보, 재무 등 민감 자료
Obsidian Vault     = 사람이 읽는 지식 지도
60-KnowledgeBase   = AI가 다시 활용할 장기 지식

원본과 요약을 분리하고, 자료의 성격에 따라 저장 위치를 나눈다는 점에서는 꽤 괜찮은 구조였습니다.

그런데 실제 운영 상태를 확인하면서 중요한 문제가 보였습니다.

프로젝트의 GoalPacket, ResultCard, 산출물은 계속 만들어지고 있었지만, 장기 지식으로 정리된 문서는 14건에 불과했습니다. 지식 목록과 변경 기록도 최근 프로젝트를 충분히 반영하지 못하고 있었습니다.

즉, 프로젝트를 통해 무언가를 배우고는 있었지만, 그 배움이 다음 프로젝트로 이어지는 흐름은 제대로 작동하지 않고 있었습니다.

이번에 해결하고 싶었던 질문은 단순했습니다.

자료를 어디에 보관할지가 아니라, 과거 프로젝트에서 배운 내용을 다음 프로젝트의 의사결정에 어떻게 다시 사용할 수 있을까?

이 질문을 해결하기 위해 기존 LLM Wiki 중심의 지식관리체계를 점검하고, AKM 구조를 PeterHQ에 적용할 수 있는지 검토했습니다.

이번 사례는 AKM 설치나 시스템 구현을 완료한 이야기가 아닙니다. 기존 구조의 문제를 발견하고, 앞으로 어떤 방향으로 바꿀지 정리한 학습·분석·설계 단계의 기록입니다.

진행 방법

1. 기존 지식관리 방식부터 다시 확인했습니다

기존 PeterHQ의 장기 지식은 모든 자료를 자동으로 저장하는 방식이 아니었습니다.

프로젝트 원본과 실행 기록 보존
→ AI 작업 결과와 ResultCard 검증
→ 재사용 가치가 있는 내용만 장기 지식으로 승격
→ 필요할 때 관련 지식을 좁게 검색

이 방식에는 분명한 장점이 있었습니다.

• 검증되지 않은 정보가 정답처럼 사용되는 것을 막을 수 있음

• 개인정보와 민감한 자료의 유입을 통제할 수 있음

• AI에게 불필요한 문서를 대량으로 주입하지 않아도 됨

• 검색 비용과 노이즈를 줄일 수 있음

하지만 검증된 정보만 장기 지식으로 승격하다 보니, 프로젝트에서 실제로 사용한 자료와 시행착오가 대부분 지식체계 밖에 남게 됐습니다.

여기서 첫 번째 문제를 발견했습니다.

검색 가능한 정보와 검증이 완료된 정본 지식을 같은 기준으로 관리하고 있었습니다.

모든 정보를 정답으로 만들 필요는 없지만, 그렇다고 검증이 끝날 때까지 검색조차 할 수 없는 상태로 둘 필요도 없었습니다.

그래서 지식을 다음 세 단계로 나눠 관리하는 방향을 검토했습니다.

Source Layer

프로젝트에서 실제로 사용한 외부·내부 근거입니다.

• 웹페이지

• PDF

• 논문

• 조사 데이터

• 내부 문서

• 원본 파일의 위치

Project Learning Layer

특정 프로젝트에서 발생한 학습과 맥락입니다.

• 고객 문제

• 프로젝트 가설

• 실험 내용

• ResultCard

• 성공 및 실패 기록

• 프로젝트 산출물의 위치

Reusable Knowledge Layer

다른 프로젝트에서도 다시 사용할 수 있도록 정리된 지식입니다.

candidate
→ reviewed
→ canonical
→ deprecated

이렇게 하면 아직 검증되지 않은 정보도 상태를 표시한 채 검색할 수 있고, 충분한 근거와 재사용성이 확인된 내용만 정본 지식으로 발전시킬 수 있습니다.

2. AKM의 핵심은 폴더가 아니라 순환 구조였습니다

처음에는 AKM을 새로운 Markdown 폴더 구조 정도로 생각했습니다.

하지만 검토하면서 더 중요한 부분은 지식을 저장하는 위치가 아니라, 지식이 실제 업무에 사용된 이후 다시 수정되는 과정이라는 점을 알게 됐습니다.

Ingest
→ Classify
→ Compile
→ Contextualize
→ Execute
→ Verify
→ Learn Back

기존 PeterHQ에도 자료를 저장하고 일부 지식을 승격하는 규칙은 있었습니다.

하지만 다음 과정이 하나의 운영 흐름으로 연결돼 있지는 않았습니다.

• 무엇을 저장할 것인가?

• 어떤 종류의 지식인가?

• 아직 검증되지 않은 정보는 어떤 상태로 둘 것인가?

• 어느 출처와 프로젝트에서 만들어졌는가?

• 실제 업무에 사용됐는가?

• 사용 결과는 성공이었는가, 실패였는가?

• 그 결과에 따라 기존 지식을 어떻게 수정할 것인가?

특히 중요하게 본 부분은 다음 흐름입니다.

Execute
→ Verify
→ Learn Back

지식을 잘 정리했다고 해서 그 지식이 실제로 유용하다는 뜻은 아닙니다.

프로젝트에 직접 적용한 뒤 효과를 확인해야 합니다. 결과가 좋았다면 신뢰도를 높이고, 일부 상황에서만 효과가 있었다면 적용 범위를 줄여야 합니다. 실패했다면 예외를 추가하거나 해당 지식을 폐기해야 합니다.

이 과정을 통해 지식체계가 문서 창고가 아니라, 경험을 통해 계속 교정되는 시스템이 될 수 있다고 판단했습니다.

3. 기존 Obsidian 폴더를 그대로 복사하지 않기로 했습니다

기존 Obsidian Vault는 사람이 찾아보기 쉬운 영역별 구조를 사용했습니다.

• Business

• Investing

• Web3

• AI-Agents

• PeterHQ

• KnowledgeBase

하지만 이 폴더를 AKM 안에 그대로 복제하면 기존 지식체계와 AKM이 동시에 존재하게 됩니다.

어느 쪽이 최신 문서인지 알기 어려워지고, 같은 내용을 두 곳에서 관리해야 하는 문제가 생길 수 있습니다.

그래서 기존 폴더명을 옮기는 대신, 자료가 수행하는 역할을 기준으로 다시 분류하기로 했습니다.

Business나 Investing 같은 구분은 최상위 저장 폴더로 다시 만들기보다, domain이나 tag 같은 메타데이터로 관리하는 방향을 선택했습니다.

4. AKM과 Obsidian의 역할도 다시 정의했습니다

논의 초반에는 Obsidian과 AKM을 각각 별도의 시스템으로 운영하는 방안도 고려했습니다.

하지만 그렇게 하면 같은 지식을 두 곳에서 관리해야 합니다.

최종적으로는 다음과 같이 역할을 단순화했습니다.

AKM      = 지식의 단일 정본
Hermes   = 검색·연결·검증·Learn Back 운영
Discord  = 작업 요청·보고·승인 인터페이스
Obsidian = AKM 폴더를 사람이 열어보는 선택적 UI

Obsidian을 없애는 것이 아닙니다.

Obsidian 전용 지식 복사본을 따로 만들지 않고, 필요할 때 AKM 폴더 자체를 Obsidian으로 열어보는 방식입니다.

기존 60-KnowledgeBase도 바로 삭제하지 않기로 했습니다. 우선 legacy 자료이자 migration source로 유지하고, 가치가 있는 문서만 AKM의 역할에 맞게 선별 이관하는 방향을 잡았습니다.

5. 코드와 디자인은 AKM에 직접 넣지 않기로 했습니다

사업화 프로젝트에서는 Markdown 문서만 만들어지지 않습니다.

• 애플리케이션 코드

• 디자인 파일

• 이미지

• 데이터

• 실행파일

• MVP

• 대용량 PDF와 웹페이지 원문

이런 파일을 모두 AKM 폴더에 넣으면 저장소가 지나치게 커지고, 기존 프로젝트 구조도 무너질 수 있습니다.

그래서 물리적 정본과 지식 정본을 분리하기로 했습니다.

Projects
= 코드·디자인·MVP·기획서의 실제 원본

Knowledge-External
= 웹·PDF·데이터·크롤링 원문

Channel-Data
= ResultCard·검수·감사 기록

Business
= 계약·고객·재무 등 민감 원본

AKM
= 파일의 의미·버전·신뢰상태·사용조건·원본 위치

예를 들어 MVP 코드는 Projects에 그대로 보관합니다.

AKM에는 코드를 복사하는 대신 다음 정보를 담은 Markdown 카드를 만듭니다.

• 이 MVP가 해결하려던 문제

• 적용한 고객 가설

• 사용한 기술과 주요 결정

• 원본 코드의 위치

• 실험 결과

• 재사용 가능한 부분

• 다시 사용할 때 주의할 조건

AKM은 모든 파일을 담는 저장소가 아니라, 흩어진 자료 사이의 관계를 설명하는 지식 지도 역할을 하게 됩니다.

무엇을 알고 있는가
↔ 어떤 출처에서 나왔는가
↔ 어느 프로젝트에서 사용했는가
↔ 어떤 결과가 나왔는가
↔ 실제 원본은 어디에 있는가

6. 외부 자료 수집도 지식 순환에 포함했습니다

프로젝트를 진행할 때는 내부 자료만으로 모든 판단을 내릴 수 없습니다.

웹 검색, PDF, 기사, 보고서, 통계자료 등 외부 자료가 필요합니다.

기존에도 Knowledge-External이라는 저장 위치는 있었지만, 일반 리서치에서 선택한 외부 자료를 Source 카드와 지식문서로 연결하는 흐름은 충분히 작동하지 않았습니다.

다만 처음부터 대규모 웹 크롤러를 만드는 것은 피하기로 했습니다.

우선 프로젝트에서 실제로 사용할 URL 3~5개만 선별해 저장하는 최소한의 흐름을 설계했습니다.

내부 Source와 Knowledge 우선 검색
→ 부족한 내용만 외부 검색
→ 실제 사용할 URL 3~5개 선별
→ robots·약관·저작권·paywall·민감정보 확인
→ 원본·추출문·metadata·hash 저장
→ AKM Source 카드 생성
→ 주장별 Evidence 정리
→ Knowledge 후보 생성
→ 프로젝트에 적용
→ ResultCard로 효과 검증

여기서 AKM과 PeterHQ Integration의 역할도 구분했습니다.

AKM Core
= 수집된 자료를 어떻게 분류하고
  지식으로 발전시킬지 정의

PeterHQ Integration
= 검색·다운로드·추출·중복 제거·
  원본 저장·Source 등록을 수행

핵심은 웹 전체를 많이 수집하는 것이 아닙니다.

실제 의사결정에 사용한 근거를 보존하고, 그 근거가 어떤 지식으로 발전했는지 연결하는 것입니다.

7. 프로젝트의 중요한 순간에만 내부 지식을 검색하도록 했습니다

기존에는 Peter가 지식 검색을 명시적으로 요청했을 때만 LLM Wiki를 조회하는 방식이었습니다.

이 방식은 안전하지만, 사용자가 과거 지식의 존재를 기억하지 못하면 검색 자체가 시작되지 않는다는 문제가 있습니다.

그래서 프로젝트의 모든 단계에서 검색하는 대신, 중요한 의사결정 시점에만 내부 지식을 확인하는 방안을 세웠습니다.

내부 지식을 확인할 다섯 개의 Gate

1. 프로젝트 시작

2. 고객과 문제를 확정하기 전

3. MVP 범위를 결정하기 전

4. 실험을 설계하기 전

5. 프로젝트 종료 및 Learn Back 단계

단, 관련 문서를 모두 AI에게 넣지는 않습니다.

metadata로 후보 검색
→ 관련성이 높은 카드만 선별
→ reviewed·canonical 카드 소수 확인
→ 필요한 경우 ResultCard와 원문 검증

이번 논의를 통해 정한 원칙은 다음과 같습니다.

자동 검색은 하되, 자동 대량 주입은 하지 않는다.

8. 검색 여부가 아니라 실제 사용 효과를 기록하기로 했습니다

관련 지식을 검색했다는 사실만으로는 그 지식이 도움이 됐다고 볼 수 없습니다.

검색 결과를 읽기만 했는지, 실제 의사결정에 사용했는지 구분해야 합니다.

그래서 ResultCard에 다음 내용을 기록하는 방향을 검토했습니다.

• 검토한 지식

• 지식을 선택하거나 제외한 이유

• 실제 사용한 지식

• 적용한 의사결정과 작업 단계

• 기대했던 효과

• 실제로 나타난 효과

• 결과 상태

PASS
PARTIAL
FAIL
UNKNOWN

결과에 따라 기존 지식에도 변화가 생깁니다.

• 성공적으로 적용됨 → 신뢰도 강화

• 특정 조건에서만 효과가 있음 → 적용 범위 축소

• 새로운 예외 발견 → 예외 조건 추가

• 실제 효과가 없음 → 신뢰도 하향

• 잘못된 지식으로 확인됨 → deprecated 처리

이 기록이 있어야 “과거 지식을 사용했다”는 사실을 넘어, “그 지식이 실제로 도움이 됐는가”를 판단할 수 있습니다.

결과와 배운 점

1. 지식관리 문제는 저장공간의 문제가 아니었습니다

처음에는 어떤 자료를 LLM Wiki에 넣어야 하는지가 핵심 문제라고 생각했습니다.

하지만 논의를 진행하면서 더 중요한 질문은 따로 있다는 것을 알게 됐습니다.

이 지식이 다음 프로젝트에서 발견되고, 검증되고, 실제 의사결정에 사용되는가?

문서를 잘 정리해도 사용되지 않으면 지식자산이라고 보기 어렵습니다.

반대로 완벽하게 정리되지 않았더라도 출처와 프로젝트 결과가 연결돼 있고, 다음 프로젝트에서 찾을 수 있다면 충분히 가치 있는 자산이 될 수 있습니다.

2. 검색 가능한 정보와 정본 지식은 구분해야 했습니다

기존 방식에서는 검증된 지식만 장기 Wiki에 넣으려다 보니, 실제 프로젝트 학습이 거의 남지 않았습니다.

이번 논의를 통해 다음 두 행위를 분리해야 한다는 점을 배웠습니다.

• 검색 가능한 상태로 등록하는 것

• 검증된 정본 지식으로 승격하는 것

Source, 프로젝트 학습, 실패 기록은 아직 완전히 검증되지 않았더라도 상태를 표시한 채 보존할 수 있습니다.

그중 반복 사용 가능성과 근거가 확인된 내용만 reviewed 또는 canonical 지식으로 발전시키면 됩니다.

3. 실패도 다음 프로젝트를 위한 자산입니다

성공한 방법만 정리하면 지식체계의 절반만 사용하는 셈입니다.

다음과 같은 실패도 중요한 지식입니다.

• 효과가 없었던 인터뷰 질문

• 고객 반응이 없었던 기능

• 지나치게 크게 설정한 MVP 범위

• 잘못된 가격 가설

• 반복해서 발생한 개발 오류

• 기대와 달랐던 AI 에이전트 작업 방식

실패를 단순히 프로젝트 기록으로 남기는 것이 아니라, Failure Pattern이나 Evaluation으로 만들면 다음 프로젝트에서 같은 실수를 줄일 수 있습니다.

4. AKM은 기존 시스템을 모두 교체하는 작업이 아니었습니다

기존 PeterHQ의 구조가 잘못됐던 것은 아닙니다.

오히려 다음 원칙은 AKM을 적용하기 좋은 기반이었습니다.

• local-first 저장

• 원본과 요약의 분리

• 프로젝트 산출물과 외부 원문의 정본 구분

• 민감 자료의 별도 관리

• 제한적인 검색

• 검증된 지식의 선별 승격

필요했던 것은 모든 폴더를 새로 만드는 일이 아니었습니다.

기존 저장 경계를 유지하면서 다음 연결을 추가하는 일이었습니다.

내부 지식 검색
→ 프로젝트 적용
→ 실제 효과 검증
→ 성공·실패에 따른 지식 수정
→ 다음 프로젝트 재사용

5. 최종 목표는 Product Learning Operating System입니다

이번 논의를 통해 PeterHQ에서 AKM이 담당해야 할 역할을 다음과 같이 정의했습니다.

PeterHQ AKM은 여러 사업 아이디어를 조사하고, 고객 문제를 정의하고, 사업모델과 MVP를 만들고, 검증한 결과를 조직 경험으로 축적하여 다음 제품을 더 빠르고 정확하게 만드는 Product Learning Operating System이다.

단순히 자료를 많이 보관하는 Wiki가 아닙니다.

과거의 조사, 결정, 성공, 실패를 다음 제품의 의사결정에 활용하고, 새로운 결과에 따라 기존 지식을 계속 수정하는 제품학습 운영체계입니다.

6. 아직 실제 효과가 검증된 것은 아닙니다 ⚠️

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

• 기존 PeterHQ 지식관리체계 분석

• LLM Wiki의 장점과 한계 확인

• AKM 구조의 적용 가능성 검토

• Obsidian과 AKM의 역할 정리

• 비-Markdown 산출물의 관리 원칙 수립

• 외부 Source Intake 흐름 설계

• 프로젝트 Gate별 검색 방향 수립

• 최소 검증 시나리오 작성

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

• AKM 설치

• 기존 KnowledgeBase 이관

• 범용 Source Intake 구현

• 프로젝트 Gate별 자동 검색 연결

• ResultCard 필드 변경

• 새 프로젝트에서의 실제 재사용 검증

따라서 현재 상태는 다음과 같이 표현하는 것이 가장 정확합니다.

학습·분석·방향 수립 완료
실제 시스템 구축 및 효과 검증 전

7. 다음 단계는 작은 프로젝트 두 개로 검증하는 것입니다

처음부터 모든 자료를 이관하거나 복잡한 자동화를 만들지는 않을 계획입니다.

먼저 프로젝트 간 학습이 실제로 작동하는지 작은 범위에서 확인하려고 합니다.

프로젝트 A: 학습 생성

• 실제 사용한 Source 저장

• Source와 Evidence 연결

• ResultCard로 성공과 실패 확인

• Knowledge 1개 생성

• Failure Pattern 1개 생성

• Procedure 1개 생성

• 원본 프로젝트와 결과 기록 연결

프로젝트 B: 새로운 세션에서 재사용

• 프로젝트 A의 대화 맥락 없이 시작

• AKM 검색으로 관련 지식 발견

• ResultCard와 원본 직접 확인

• MVP 범위나 실험 설계에 적용

• 조사 시간과 결과 품질 변화 기록

• 결과에 따라 기존 지식 수정

검증할 기준은 문서 개수가 아닙니다.

• 관련 지식을 발견했는가?

• 원본과 결과를 직접 확인했는가?

• 실제 의사결정에 사용했는가?

• 반복 조사가 줄었는가?

• 같은 실패의 반복이 줄었는가?

• 잘못된 지식이 자동으로 확정되지 않았는가?

• 민감정보 유입과 깨진 포인터가 없었는가?

이 기준을 통과했을 때만 자동화 범위를 넓힐 수 있습니다.

마무리

이번 논의를 시작할 때는 “어떤 자료를 Wiki에 저장할 것인가”를 고민했습니다.

하지만 최종적으로 도달한 질문은 완전히 달라졌습니다.

과거 프로젝트에서 얻은 경험이 다음 프로젝트에서 실제로 발견되고, 검증되고, 사용되고 있는가?

PeterHQ에 필요한 것은 자료가 많이 쌓인 Wiki가 아니었습니다.

이전 프로젝트의 지식이 다음 프로젝트의 고객 문제 정의, MVP 범위, 실험 설계에 활용되고, 그 결과에 따라 다시 수정되는 운영체계였습니다.

앞으로 AKM의 성공 여부도 지식문서 수로 판단하지 않으려고 합니다.

이전 프로젝트의 지식이 다음 프로젝트에서 실제로 발견되고, 반복 조사와 실패를 줄이며, 더 빠르고 정확한 의사결정을 만드는지가 진짜 평가 기준이 될 것입니다. 🚀

도움 받은 글

논의 및 점검 기록

• @session:default/20260727_100730_42a650dc

  • 프로젝트 지식 축적 방식 논의

• @session:default/20260728_100042_cd01a7ac

  • AKM 제품학습 프로세스 검토 및 현재 상태 확인

본 사례의 구조, 수량 및 운영 상태는 2026년 7월 28일 점검 시점을 기준으로 작성했습니다.