## 📝 한줄 요약
LLM Wiki·AKM 관점으로 제가 운영하던 회사 보고서 작성 시스템을 다시 들여다봤습니다. 결론은 단순했습니다. AI에게 자료를 많이 읽히는 것보다, 원본·해석·현재 맥락·실행 절차·평가 기준을 분리해 주는 일이 먼저였습니다.
바쁘시면 이것만 읽어도 됩니다.
- 자료가 부족한 것이 아니라, 서로 다른 역할의 자료가 섞이는 맥락 오염이 문제였습니다.
- 보고서 원문, 개인 문체, 외부 지식, 작업 맥락, 실행 절차, 평가 기준을 서로 다른 계층으로 분리했습니다.
- 폴더만 나눈 것이 아니라, 단계 사이를 스킬형 품질 게이트로 연결했습니다.
- 실패는 세션 기록으로 묻지 않고 다음 작업에서 읽을 절차와 통과 기준으로 바꿨습니다.
- 그 결과 보고서 문장·문체·근거가 어디에서 왔고 어떤 검토를 거쳤는지 역추적할 수 있게 됐습니다.
> 자료 더 넣기가 아니라 Source → Knowledge → Context → Procedure → Action → Evaluation의 품질 게이트를 통과하는 보고서 파이프라인
## 🎯 이런 분들께 도움이 됩니다
- Obsidian·Notion에 자료는 많은데 AI가 제대로 활용하지 못한다고 느끼는 분
- AI에게 같은 배경과 작성 기준을 매번 다시 설명하는 분
- 개인 문체와 외부 참고자료가 섞여 결과가 들쭉날쭉한 분
- 단발성 프롬프트가 아니라 자기 분야의 업무 에이전트를 만들고 싶은 분
## 😫 문제 상황: 자료가 많아질수록 AI가 더 헷갈렸다
처음에는 기존 보고서와 참고자료를 AI가 모두 읽을 수 있게 하면, 자연스럽게 제 업무를 이해할 것이라고 생각했습니다. 하지만 자료가 늘수록 세 가지 문제가 반복됐습니다.
1. 보고서를 쓸 때마다 자료 조사와 양식 맞추기를 처음부터 반복했습니다.
2. 좋은 프롬프트와 교정 내용이 대화 세션 속에 묻혀 다음 작업에 이어지지 않았습니다.
3. 제가 쓴 보고서와 외부 참고 보고서가 섞이면서, 외부 문체가 제 보고서에 들어왔습니다.
세 문제의 공통 원인은 맥락 오염이었습니다.
원본과 요약본, 현재 결정과 폐기된 절차, 내 문체와 외부 문체, 검증된 사실과 AI의 해석이 같은 지식처럼 놓여 있었습니다. 이 상태에서는 모델이 좋아져도 무엇을 우선해야 하는지 알기 어렵습니다.
스터디 노트에서 특히 와닿았던 문장은 다음 취지였습니다.
> AI가 답변에 참고하는 지식과, AI가 운영되기 위해 필요한 정보를 분리해야 한다.
그래서 기존 시스템을 단순한 ‘보고서 자료 폴더’가 아니라, 에이전트가 읽고 실행하고 검증하는 업무 지식 시스템으로 다시 해석해 보기로 했습니다.
## 🛠️ 사용한 도구
- Hermes Agent의 프라이드: 회사 보고서·제안서·SOP를 담당하는 텔레그램 AI 에이전트
- Obsidian·Markdown: 원본, 해석, 지식카드, 절차, 평가기준을 보관하는 지식 기반
- Pride Notes: 회사 보고서를 위한 폴더형 지식 파이프라인
- Custom Skills: 인제스트·분석·작성·검토·변환 절차를 실행하는 품질 게이트
## 🔧 작업 과정
### 1. 폴더를 주제별 보관함이 아니라 ‘책임 계층’으로 바꿨다
LLM Wiki·AKM 관점에서 중요한 것은 폴더 이름 자체가 아니었습니다. 각 계층이 어떤 종류의 정보를 책임지고, 다음 계층으로 넘길 때 무엇을 검증하는가가 핵심이었습니다.
제가 설계한 보고서 시스템의 기준 흐름은 다음과 같습니다.
```text
10_report
→ 20_Templates
→ 30_Extracts
→ 40_Wiki
→ 50_workplace
→ 60_Revisions
→ 70_Output
→ 80_Archive
→ 90_settings
```
- `10_report` — 원문 정제본: 문장·표·부호·붙임 구조를 보존한 신뢰 가능한 원천
- `20_Templates` — 작성 기준: 회사공통·부서별·문서종별·개인 문체와 하이라키 규칙
- `30_Extracts` — 보고서별 해석: 문서 전체를 읽고 주장·근거·사실·분석·판단으로 해부한 층
- `40_Wiki` — 재사용 지식: 여러 보고서 작성에 다시 쓸 수 있도록 정규화한 개념·개체·분석·사실·판단 카드
- `50_workplace` — 프로젝트 맥락: 브리프, 조사, 목차, 상세본, 압축본, 검토 결과가 쌓이는 작업 공간
- `60_Revisions` — 개정 이력: 최종본 이후 수정 사유와 변경 내역
- `70_Output` — 최종 산출물: 검토를 통과한 최신본
- `80_Archive` — 원본 보관: 처리 완료된 원본과 추적 경로
- `90_settings` — 운영 규칙: 설계문서, 스키마, 품질 기준, 명명 규칙
이 구조의 목적은 자료를 예쁘게 정리하는 것이 아닙니다. 원본과 파생물, 작업 중 문서와 최종본, 지식과 절차를 AI가 혼동하지 않게 하는 것입니다.
### 2. Source·Knowledge와 운영 지식을 분리했다
스터디에서 제시한 구분을 제 시스템에 대응시키면 다음과 같습니다.
| AKM 역할 | 보고서 시스템의 대응 계층 | AI가 여기서 얻는 것 |
|---|---|---|
| Source | 10_report, 80_Archive | 원문, 표, 수치, 출처 |
| Knowledge | 20_Templates, 30_Extracts, 40_Wiki | 문체·구조·개념·사실·분석·판단 |
| Context | 50_workplace | 이번 보고서의 목적·독자·범위·현재 상태 |
| Procedure | 90_settings, Custom Skills | 읽는 순서, 작업 절차, 중단 조건 |
| Action | 작성·개정·변환 스킬, 70_Output | 초안 작성, 승인 수정, 배포본 생성 |
| Evaluation | 단계별 Quality Gate, 별도 평가 체계 | 원문 보존, 팩트체크, 문체, 결재 가능성 판정 |
실제 폴더 하나가 두 역할의 경계에 걸치는 경우는 있습니다. 그래서 중요한 것은 완벽한 분류가 아니라 주 책임과 참조 순서를 문서로 고정하는 것이었습니다.
> 왼쪽에는 답변 재료: Source·Knowledge, 오른쪽에는 운영 지식: Context·Procedure·Action·Evaluation, 가운데에는 프라이드 에이전트를 배치한 2영역 구조
### 3. 내 보고서와 외부 참고 보고서를 분리했다
가장 큰 ‘아하 모먼트’는 10_report 안에서도 원천을 다시 나눈 것이었습니다.
- My Reports: 제가 직접 쓴 보고서. 개인 문체·문장 길이·부호 위계·결론 배치의 학습 원천
- Reference Reports: 정부·공공기관·타 부서·외부 기관 보고서. 사실·제도·정책 논리·문서 구조의 참고 원천
이 둘을 섞으면 외부 보고서의 문체가 제 문체처럼 학습됩니다. 그래서 개인 양식 계층은 My Reports만 반영하는 문체 보호 구역으로 잠갔습니다. 외부 문서는 내용과 구조를 참고할 수 있지만, 개인 문체의 정답으로는 사용하지 않습니다.
이 설계 덕분에 AI에게 “내 스타일로 써줘”라고 모호하게 말하는 대신, 어떤 자료는 내용에만 쓰고 어떤 자료는 문체에만 쓸지 권한을 나눌 수 있었습니다.
> My Reports → 개인 문체 템플릿과 Reference Reports → 사실·정책논리를 분리하고, 외부 문체가 개인 양식으로 넘어가지 못하게 막는 구조
### 4. 폴더 사이를 스킬형 품질 게이트로 연결했다
폴더 구조만 만들어서는 에이전트가 일하지 못했습니다. 그래서 각 단계의 이동 조건을 Custom Skill로 만들었습니다.
| 스킬 | 담당 게이트 | 통과하지 못하면 |
|---|---|---|
| pride-inbox | 원문 구조·표·부호·작성 주체 검수 | 원문 정제본으로 승격하지 않음 |
| pride-template | 회사·부서·문서종·개인 양식 책임 분리 | 외부 문체가 개인 양식에 섞이면 중단 |
| pride-extract | 문서 전체 독해와 의미 분해 | 키워드·상투적 요약이면 재작성 |
| pride-ingest | 출처가 연결된 재사용 지식으로 정규화 | 출처 불명·중복·저품질 카드는 보류 |
| pride-report-writing | 의도 합의 →조사→목차→상세본→압축→검토→최종화 | 승인 전 다음 단계로 넘어가지 않음 |
| pride-report-conversion | 승인된 Markdown의 배포 파일 변환 | 미승인 초안이나 검증 불가 형식은 최종본 처리하지 않음 |
이때 스킬은 ‘자동화 기능’이 아니라 다음 단계로 넘겨도 되는지 판단하는 게이트입니다. 자동화가 빨라도 품질 기준을 통과하지 못하면 멈추도록 설계했습니다.
### 5. 실패를 기록하는 데서 끝내지 않고 Procedure와 Evaluation을 바꿨다
가장 뚜렷한 실패는 1페이지 보고서를 만드는 과정에서 나왔습니다.
처음에는 초안을 바로 압축하면 빠르게 1페이지 보고서를 만들 수 있다고 생각했습니다. 결과는 짧아졌지만 좋아지지 않았습니다. 근거와 판단이 빠졌고, 문장은 압축됐지만 정보밀도와 프레이밍은 개선되지 않았습니다.
이 실패 이후 작성 절차를 다음과 같이 분리했습니다.
```text
상세본 작성
→ 상세본 검토
→ 압축 전용 지시문 작성
→ 압축본 작성
→ 팩트체크·결재자 관점 검토
→ 승인된 지적만 최종본에 반영
```
그리고 압축본의 통과 기준도 추가했습니다.
- 정보밀도
- 문장밀도
- 프레이밍
세 항목 중 최소 두 가지가 상세본보다 개선되지 않으면, 단순히 짧아졌다는 이유로 통과시키지 않습니다.
이 경험은 AKM에서 말하는 실패 환류를 이해하는 데 도움이 됐습니다. 실패 로그를 저장하는 것만으로는 부족했습니다. 다음 실행 전에 AI가 읽을 Procedure와, 결과를 판정할 Evaluation이 실제로 바뀌어야 같은 실패가 줄어 듭니다.
> 📷 이미지 추천 4 — 실패 환류 루프
> 빠른 압축 → 정보 손실 → 원인 진단 → Procedure 수정 → Evaluation 추가 → 같은 입력 재검증 순환도
## ✅ 결과: 이제 결과물의 출처를 거꾸로 따라갈 수 있다
가장 큰 변화는 단순한 작성 속도가 아니라 추적 가능성이었습니다.
새 보고서의 한 문장이나 표를 보며 다음 질문에 답할 수 있게 됐습니다.
- 이 내용은 어느 원문 보고서에서 왔는가?
- 이 문체는 내 보고서에서 학습한 것인가, 외부 참고자료에서 온 것인가?
- 이것은 검증 가능한 사실인가, 여러 자료를 종합한 분석인가, 승인된 판단인가?
- 어떤 브리프와 목차, 검토 기준을 거쳐 최종본이 됐는가?
작성 당시 로컬 시스템에는 10_report 32개, 30_Extracts 32개, 40_Wiki 957개 Markdown 문서가 있었습니다. 하지만 이 숫자를 성과지표로 보지는 않습니다. 카드가 많아도 출처와 용도가 불분명하면 다시 맥락 오염이 시작되기 때문입니다.
| 항목 | Before | After |
|---|---|---|
| 자료 제공 | 관련 폴더를 통째로 읽힘 | 역할별 계층과 인덱스로 필요한 자료만 참조 |
| 원본·해석 | 같은 지식처럼 혼재 | Source·Extract·Wiki로 분리 |
| 개인·외부 문체 | 참고자료 문체가 섞임 | My Reports와 Reference Reports 권한 분리 |
| 작업 절차 | 세션마다 다시 설명 | Skill과 설정 문서로 재사 용 |
| 실패 처리 | 대화 속 교정으로 종료 | Procedure·Evaluation 수정 후 재검증 |
| 최종본 근거 | 결과만 남음 | 원문·지식카드·작업 맥락·검토 이력 추적 |
아직 완성된 시스템이라고 보기는 어렵습니다. 특히 40_Wiki의 카드가 실제 새 보고서에 어떻게 호출됐고, 최종 문장의 어느 근거로 사용됐는지까지 더 촘촘히 연결해야 합니다.
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. 폴더를 주제가 아니라 책임으로 나누기
‘마케팅·영업·기획’보다 ‘원본·해석·절차·평가’가 에이전트 운영에는 더 중요한 구분일 수 있습니다.
2. 내 자료와 외부 자료의 사용 권한을 다르게 주기
모든 자료를 같은 비중으로 학습시키지 말고, 내용·문체·근거·구조 중 어디에 사용할지 정해야 합니다.
3. 스킬에 성공 절차뿐 아니라 중단 조건 넣기
AI가 무엇을 해야 하는지만 쓰면 계속 진행합니다. 무엇이 깨지면 승격하지 말아야 하는지도 함께 적어야 합니다.
4. 실패를 다음 실행 규칙으로 승격하기
반복되는 교정은 프롬프트 문장이 아니라 Procedure와 Evaluation의 후보입니다.
### 이렇게 하면 안 됩니다
1. 기존 볼트 전체를 곧바로 AI 컨텍스트에 넣기
2. 원본과 요약본, 현재 규칙과 과거 절차를 한 문서에 합치기
3. 외부 참고자료를 개인 문체 학습 데이터로 그대로 사용하기
4. 생성된 문서 수를 지식 시스템의 품질로 착각하기
5. AI 초안을 검토 없 이 최종 산출물로 승격하기
## 🌍 내 자료에 적용한다면: 세 노트로 작게 시작하기
기존 Obsidian·Notion을 전면 개편할 필요는 없습니다. 공개된 샘플 문서 한 건으로 다음 세 종류만 먼저 분리해 보는 것을 권합니다.
1. 원본 노트: 링크·전사·표·출처를 보존하고 임의 해석을 넣지 않습니다.
2. 해석 노트: 핵심 주장·근거·사실·분석을 재사용 가능한 형태로 정리합니다.
3. 프로젝트 적용 노트: 이번 작업의 목적, 적용 범위, 선택한 판단, 실행 절차와 검증 기준을 적습니다.
그다음 에이전트에게 다음 순서를 알려 줍니다.
```text
원본을 먼저 확인한다.
→ 해석 노트에서 재사용할 지식을 찾는다.
→ 프로젝트 적용 노트의 현재 목적과 제한을 따른다.
→ 통과 기준을 충족하지 못하면 결과를 승격하지 않는다.
```
중요한 것은 거대한 폴더 체계를 복제하는 일이 아닙니다. 원본·해석·적용의 책임을 섞지 않는 작은 성공 경험을 만드는 것이 먼저입니다.
## 🚀 앞으로의 계획
다음 단계는 40_Wiki의 지식카드와 새 보고서 최종본 사이의 추적성을 강화하는 것입니다.
- 어떤 카드가 조사 단계에서 호출됐는지
- 카드의 어떤 원문 출처가 팩트체크에 사용됐는지
- 어떤 문장이나 표에 반영됐는지
- 반영하지 않은 카드와 그 이유는 무엇인지
이 연결이 완성되면 단순히 “AI가 내부 지식을 참고했다”가 아니라, 어떤 지식이 어떤 판단을 거쳐 결과물에 들어갔 는지 설명할 수 있는 에이전트에 가까워질 수 있습니다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: 기존 볼트를 AKM 관점으로 감사하기
> 내 Obsidian·Notion 구조를 바로 개편하지 말고 먼저 감사해 줘.
> 각 문서를 Source, Knowledge, Context, Procedure, Action, Evaluation 관점으로 분류하되, 억지로 하나에 넣지 말고 주 책임과 보조 책임을 구분해 줘.
> 특히 원본과 파생 문서, 현재 규칙과 폐기된 절차, 개인 작성물과 외부 참고자료가 섞인 지점을 찾아 ‘맥락 오염 리스크’로 정리해 줘.
> 마지막에는 전면 이관안이 아니라 공개 샘플 1건으로 시작할 최소 실험안을 제안해 줘.
### 프롬프트 2: 원본·해석·적용 3노트 만들기
> 이 자료 한 건을 세 노트로 분리해 줘.
> 1) 원본 노트에는 출처와 원문 구조만 보존하고,
> 2) 해석 노트에는 핵심 주장·근거·사실·분석을 재사용 가능한 단위로 정리하고,
> 3) 프로젝트 적용 노트에는 이번 작업의 목적·사용 범위·결정·절차·검증 기준을 적어 줘.
> 세 노트 사이에는 출처 링크를 남기고, 확인되지 않은 내용은 사실처럼 승격하지 마.
### 프롬프트 3: 반복 실패를 스킬형 품질 게이트로 바꾸기
> 아래 실패 사례를 단순 회고가 아니라 다음 실행 규칙으로 바꿔 줘.
> ‘발생 조건 → 놓친 제약 → 수정할 Procedure → 통과/실패 Evaluation → 같은 입력 재검증 방법’ 순서로 작성해 줘.
> AI가 계속 진행하면 안 되는 중단 조건과, 사용자 승인이 필요한 지점을 반드시 포함해 줘.
---
LLM Wiki·AKM 관점에서 제가 얻은 결론은 하나입니다.
> 좋은 업무 에이전트는 자료를 많이 가진 AI가 아니라, 무엇이 원본이고 무엇이 해석이며 어떤 절차와 평가 기준을 따라야 하는지 아는 AI다.
이 글의 AKM 역할 구분은 스터디에서 배운 관점을 개인 업무 시스템에 적용해 재구성한 사례입니다. 폴더명 자체를 표준으로 제안하기보다, 원본성·책임 분리·라우팅·검증·실패 환류라는 설계 원리를 공유하는 데 목적이 있습니다.
시도하고자 했던 것과 그 이유를 알려주세요.
(내용 입력)
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
(내용 입력)
결과와 배운 점
배운 점과 나만의 꿀팁을 알려주세요.
과정 중에 어떤 시행착오를 겪었나요?
도움이 필요한 부분이 있나요?
앞으로의 계획이 있다면 들려주세요.
(내용 입력)
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
(내용 입력)
