## 📝 한 줄 요약
지식관리 스터디에서 본 AKM 관점을 회사 보고서 작성 업무에 적용했다. 책, 영상, 메모를 폭넓게 모으는 범용 지식관리가 아니라, 보고서의 원문·작성 방식·근거·판단·검토 절차를 관리하고 다음 보고서에 다시 쓰는 특정 분야 지식관리 시스템을 만들었다.
이 글에서 AKM은 Agentic Knowledge Management를 뜻한다. AI가 노트를 검색하는 데 그치지 않고, 지식의 생성, 사용, 검증, 환류까지 운영하는 방식이다. 프라이드는 이 시스템을 실행하는 업무 AI의 이름이며, 이 글의 주제는 프라이드 자체가 아니라 회사 보고서 작성을 위한 도메인 특화 업무지식 관리다.
바쁘시면 이것만 읽어도 됩니다.
- 범용 지식관리가 관심사 전반의 자료를 연결한다면, 이 시스템은 회사 보고서 작성에 필요한 지식만 책임별로 나눈다.
- 보고서 원문, 작성 템플릿, 사실·분석·판단, 현재 작업 맥락, 검토 기준을 서로 다른 계층에서 관리한다.
- 최종 산출물을 끝점으로 두지 않고, 실제 작성 과정에서 확정된 판단과 변경 근거를 다음 보고서의 지식으로 돌려보낸다.
- AI가 만든 해석은 사용자 지식으로 자동 승격하지 않는다. 후보로 남기고 승인을 거친다.
- 새 지식에는 출처, 적용 범위, 확인 시점, 사용 이력을 남긴다.
- 목표는 자료를 많이 기억하는 AI가 아니라, 근거를 추적하며 회사 보고서를 작성하는 AI를 만드는 것이었다.
## 🎯 이런 분들께 도움이 됩니다
- 범용 지식관리 시스템은 있지만 실제 업무 산출물로 연결되지 않는 분
- 회사 보고서를 쓸 때마다 자료 조사와 양식 맞추기를 반복하는 분
- AI에게 같은 배경과 작성 기준을 매번 설명하는 분
- 사용자 작성 방식과 외부 참고자료가 섞여 결과가 들쭉날쭉한 분
- 보고서 작성 결과를 다음 보고서의 지식으로 축적하고 싶은 분
## 🔎 범용 지식관리와 무엇이 달랐나
대부분의 지식관리는 책, 기사, 영상, 아이디어, 회의 메모처럼 여러 주제의 자료를 한곳에 모으고 연결하는 데서 시작한다. 이런 범용 지식관리는 생각을 확장하고 필요한 정보를 다시 찾는 데 유용하다.
회사 보고서 작성은 요구사항이 더 좁고 엄격했다. 자료를 찾는 것만으로는 부족했다. 어떤 문장이 원문인지, 어떤 내용이 검증된 사실인지, 어떤 판단이 실제로 승인됐는지, 어떤 작성 방식이 사용자 고유의 패턴인지까지 구분해야 했다. 최종 결과도 검색 답변이 아니라 제출 가능한 보고서여야 했다.
| 구분 | 범용 지식관리 | 회사 보고서 업무지식 관리 |
|---|---|---|
| 관리 범위 | 관심사와 자료 전반 | 회사 보고서 작성에 필요한 원문·근거·판단·양식 |
| 지식 단위 | 클리핑, 메모, 개념, 아이디어 | 보고서 원문, 템플릿, 사실, 분석, 판단, 검토 기준 |
| 사용 목적 | 검색, 요약, 아이디어 연결 | 목차 설계, 근거 배치, 문장 작성, 검토, 최종본 생성 |
| 현재 맥락 | 질문과 관련 태그 | 보고 목적, 독자, 문서 유형, 분량, 승인 상태 |
| 품질 기준 | 출처와 연결성 | 원문 보존, 사실 검증, 작성 방식, 승인 추적, 제출 가능성 |
| 환류 방식 | 새 노트와 링크 추가 | 최종 보고서의 새 판단·수정 이유를 Wiki·템플릿·절차로 환류 |
즉, 범용 지식관리가 "무엇을 알고 있는가"를 넓히는 시스템이라면, 이 시스템은 "회사 보고서를 쓰기 위해 어떤 지식을 어떤 순서와 기준으로 사용할 것인가"를 관리한다.
## 😫 자료는 쌓이는데, 보고서는 매번 처음부터 시작했다
제가 관리하려는 대상은 관심사 전반의 지식이 아니라 회사 보고서 작성에 필요한 지식이었다. 보고서 원문, 외부 참고자료, 사용자 작성 방식, 사실과 판단, 검토 기준을 정리해 두면 다음 보고서를 더 잘 쓸 수 있을 것이라고 생각했다. 이 시스템을 실행하는 업무 AI에 프라이드라는 이름을 붙였다.
초기 업무지식 관리 시스템에도 원문을 정제하고, 보고서를 분석하고, 재사용 지식을 만드는 흐름은 있었다.
```text
원본 문서
→ 구조를 보존한 보고서
→ 의미 분석
→ 재사용 지식
→ 새 보고서 작성
→ 최종 산출물
```
문제는 마지막이었다. 최종 산출물이 만들어지면 작업이 끝났다. 그 과정에서 새로 확인한 사실, 실제로 채택한 판단, 기존 지식을 수정한 이유가 다음 작업을 위한 지식으로 돌아가는 공식 절차가 없었다.
세 가지 빈틈이 보였다.
1. 위키에 있는 정보가 지금도 유효한지 알기 어려웠다.
2. AI가 만든 해석과 사용자가 승인한 판단의 경계가 약했다.
3. 최종 문장의 근거를 원문까지 거꾸로 따라가는 연결이 충분하지 않았다.
자료가 부족한 문제가 아니었다. 지식이 들어오고, 쓰이고, 수정되고, 다시 돌아가는 길이 끊겨 있었다.
업무 AI에게는 다음처럼 요청했다.
```text
범용 지식관리와 구분해 회사 보고서 작성을 위한 업무지식 관리 시스템을 설명하고,
지식관리 스터디에서 배운 AKM 관점으로 개선한 점을 사례글로 정리해 줘.
개인이나 조직을 식별할 수 있는 내용은 모두 제외해 줘.
```
## 🧭 지식관리 스터디에서 가져온 네 가지 관점
스터디를 들으며 AKM을 거대한 지식 저장소로 이해하지 않았다. AI가 지식을 읽고 업무에 사용한 뒤, 결과와 변경 근거를 다시 지식으로 돌려놓는 운영 방식에 가까웠다.
### 1. 원본과 해석을 분리한다
원문, 요약, AI 해석을 한곳에 놓으면 출처가 흐려진다. 원본은 원본대로 보존하고, 해석은 별도 계층에서 만들며, 재사용 지식은 출처를 거슬러 올라갈 수 있어야 한다.
### 2. 지식의 복리는 노트 수가 아니라 재사용과 변경 이력에서 생긴다
노트가 늘어나는 것만으로는 지식이 쌓였다고 보기 어렵다. 이전 판단을 다시 사용하고, 새 근거가 들어왔을 때 무엇이 왜 바뀌었는지 남아야 한다.
### 3. Procedure에는 순서뿐 아니라 정지 조건이 필요하다
AI에게 할 일만 알려주면 계속 진행한다. 어떤 입력이 필요한지, 어디서 사람 승인을 받아야 하는지, 어떤 오류가 나오면 멈춰야 하는지까지 절차에 들어가야 한다.
### 4. AI가 만든 사용자 관점은 아직 사용자 관점이 아니다
AI가 기존 자료 를 읽고 그럴듯한 판단을 만들 수는 있다. 하지만 사용자가 확인하지 않은 해석을 장기 지식으로 저장하면, 다음 작업에서 그 해석이 사실이나 확정 판단처럼 재사용될 수 있다. 그래서 생성과 승격 사이에 승인 단계를 뒀다.
## 🧱 회사 보고서 업무지식은 어떻게 관리하는가
이 특정 분야 지식관리 시스템은 폴더를 주제별 보관함이 아니라 보고서 작성 단계별 책임 계층으로 사용한다. 정본 흐름은 다음과 같다.
```text
10_report
→ 20_Templates
→ 30_Extracts
→ 40_Wiki
→ 50_workplace
→ 60_Evaluation
→ 70_Output
→ 80_Archive
→ 90_settings
```
- 10_report에는 문장, 표, 부호, 붙임 구조를 보존한 정제 원문을 둔다.
- 20_Templates에는 공통 형식, 문서 유형별 구조, 사용자 작성 방식을 나눠 저장한다.
- 30_Extracts에서는 보고서 전체를 읽고 개념, 개체, 분석, 사실, 판단으로 의미를 분해한다.
- 40_Wiki에는 여러 작업에서 다시 쓸 수 있는 지식카드만 올린다.
- 50_workplace에는 현재 작업의 목적, 조사, 목차, 초안, 검토, 승인 상태를 둔다. 최종 확정 뒤 개정 이력도 이 작업 공간 안에서 관리한다.
- 60_Evaluation에는 사용자가 별도로 요청한 평가 결과만 둔다. 일반 작성 과정과 자동으로 섞지 않는다.
- 70_Output에는 검증을 통과한 최신 산출물만 둔다.
- 80_Archive에는 처리가 끝난 원본을 보존한다.
- 90_settings에는 설계문서, 스키마, 스킬, 품질 기준을 둔다.
이 구조를 AKM 역할로 다시 보면 더 명확해진다.
| AKM 역할 | 업무지식 시스템의 대응 영역 | AI가 얻는 것 |
|---|---|---|
| Source | 정제 원문과 원본 보관 | 문장, 표, 수치, 출처 |
| Knowledge | 템플릿, Extract, Wiki | 작성 방식, 개념, 사실, 분석, 판단 |
| Context | 현재 작업 공간 | 이번 문서의 목적, 독자, 범위, 진행 상태 |
| Procedure | 설정 문서와 Custom Skills | 읽는 순서, 승인 지점, 중단 조건 |
| Action | 작성, 개정, 변환 절차 | 초안 작성, 승인 수정, 배포본 생성 |
| Evaluation | 품질 게이트와 별도 평가 | 원문 보존, 팩트체크, 구조, 근거 검증 |
### 사용자 작성본과 외부 참고본도 분리했다
같은 보고서라도 사용 목적이 다르다.
- 사용자 작성본은 문장 길이, 부호 위계, 결론 배치 같은 작성 방식의 근거다.
- 외부 참고본은 사실, 제도, 논리 구조를 확인하는 근거다.
외부 자료의 내용은 활용하되, 외부 문체가 사용자 작성 방식의 정답이 되지 않도록 권한을 나눴다. AI에게 단순히 "내 스타일로 써 줘"라고 말하는 대신, 어떤 자료를 문체에 쓰고 어떤 자료를 내용에 쓸지 지정한 셈이다.
## 🔧 이번 지식관리 스터디에서 실제로 개선한 점
개선 방향도 범용 자료 수집이나 검색 기능 확대가 아니었다. 회사 보고서를 작성할 때 근거와 판단을 정확히 사용하고, 최종본에서 확인된 지식을 다 음 보고서로 되돌리는 데 초점을 맞췄다.
### 1. 최종 산출물 뒤에 지식 환류 단계를 붙였다
가장 큰 변화다. 이전에는 70_Output이 끝이었다. 이제 최종 산출물 뒤에 Knowledge Return 문서를 만든다.
이 문서에는 다음 항목을 나눠 적는다.
- 이번 작업에서 재사용한 기존 지식
- 새로 확인한 사실, 분석, 판단 후보
- 기존 지식과 달라진 내용과 변경 이유
- 작성 방식, 스킬, 절차에 되돌려야 할 개선점
- 이번 문서에서만 필요한 일회성 수정
다만 Knowledge Return은 위키의 직접 출처가 아니다. 공식 경로는 의도적으로 길게 뒀다.
```text
최종 산출물 확정
→ 지식 환류 후보 작성
→ 사용자 승인
→ 승인된 원문 정제
→ 의미 분석과 검수
→ 충돌 검사
→ Wiki 반영
```
AI가 그럴듯하게 정리했다는 이유만으로 장기 지식이 되지 않는다. 사용자 승인을 받은 내용만 정식 지식 파이프라인으로 돌아간다.
### 2. 주장과 근거를 Claim Ledger로 연결했다
새 문서를 쓸 때 위키 검색 결과를 바로 본문에 넣지 않는다. 조사 단계에서 주장과 근거를 장부로 관리한다.
| 기록 항목 | 확인 내용 |
|---|---|
| Claim | 최종 문서에서 사용할 주장 |
| Wiki card | 참고한 재사용 지식 |
| Source | 원천 Extract 또는 1차 자료 |
| Applicability | 이 판단이 적용되는 범위와 조건 |
| Freshness | 확인 기준일과 재검증 여부 |
| Final use | 실제 반영 위치 또는 제외 이유 |
최종 문서에는 내부 Claim ID를 남기지 않는다. 대신 작업 공간에서 최종 문장의 근거를 원문까지 역추적할 수 있다.
### 3. 최신 수정일과 최신 검증일을 구분했다
파일의 updated 날짜가 최근이라고 해서 내용이 지금도 유효한 것은 아니다. 그래서 새로 만들거나 실제로 다시 쓰는 지식부터 다음 정보를 점진적으로 추가했다.
- as_of: 사실의 기준 시점
- last_verified: 마지막으로 근거를 확인한 시점
- used_in: 어느 산출물의 어느 부분에 사용했는지
- applicability: 적용 가능한 업무와 조건
- supersedes: 어떤 이전 판단을 대체하는지
- change_reason: 판단을 바꾼 이유
기존 지식 전체를 한꺼번에 고치지는 않았다. 새로 생성하거나, 다시 사용하거나, 의미가 바뀐 카드부터 적용했다. 모양을 빨리 통일하는 것보다 과거 의미를 보존하는 편을 택했다.
### 4. 새 노트에는 기계가 읽을 수 있는 신분표를 붙였다
AI가 만든 Markdown 파일이 많아지면 이름만 보고 역할을 판단하기 어렵다. 신규 일반 노트에는 최소한 스키마 버전, 문서 유형, 생성일을 요구했다.
다른 문서에서 파생하거나 복사한 파일에는 출처 종류, 원천 참조, 당시 원문의 해시를 추가한다. 원문이 바뀌면 감사기가 파생 문서를 오래된 상태로 표시한다. 출처가 끊겼거나 해시가 다르면 자동으로 현재 지식처럼 취급하지 않는다.
새 파일은 임시 초안을 검사한 뒤 발행한다. 기존 파일을 덮어쓰지 않고, 필수 메타데이터가 없으면 발행을 중단한다.
### 5. 여러 AI 실행환경이 같은 정본을 읽게 했다
AI를 한 환경에서만 쓰지 않으면 규칙이 조금씩 달라질 수 있다. 한쪽은 최신 폴더를 읽고, 다른 쪽은 예전 경로나 폐기된 절차를 읽는 식이다.
이를 막기 위해 역할, 정본 경로, 보안 경계, 금지 행동을 중앙 정본에 두고 각 실행환경에는 짧은 연결 문서만 배치했다. 정본이 바뀌면 연결 상태와 해시를 검사한다.
이 변화는 화려하지 않지만 중요했다. AI의 기억을 늘리기 전에, 여러 AI가 같은 업무 지도를 읽게 만든 것이다.
### 6. 지식 자동화의 기본값을 실행이 아니라 검토로 바꿨다
새 지식 인제스트와 최종본 승격은 기본적으로 dry-run으로 동작한다. 무엇을 만들고, 어떤 기존 지식과 충돌하며, 어떤 파일이 최종본 후보인지 먼저 보여 준다. 실제 반영은 별도 승인이 있어야 한다.
또 다음 조건에서는 자동화가 멈춘다.
- 원천 출처를 찾을 수 없음
- 검수 상태가 맞지 않음
- 같은 제목의 지식이 이미 있으나 의미가 다를 수 있음
- 기존 판단을 바꾸는 데 필요한 승인 기록이 없음
- 적용 중 일부 파일만 바뀔 위험이 있음
검사에 실패하면 새 카드, 색인, 로그를 함께 되돌린다. 좋은 지식관리 자 동화는 많이 저장하는 시스템이 아니라, 애매할 때 저장을 거절할 수 있는 시스템이어야 했다.
## ✅ 달라진 점
이번 개선은 시간을 얼마나 줄였는지 측정하는 작업이 아니었다. 지식이 만들어지고 사용되고 갱신되는 경계를 분명히 하는 작업이었다.
| 항목 | 이전 | 개선 후 |
|---|---|---|
| 업무의 끝 | 최종 산출물 생성 | 최종 산출물과 지식 환류를 별도 상태로 관리 |
| 근거 관리 | Wiki 카드 참고 | Claim에서 원문까지 역추적 |
| 지식 최신성 | 파일 수정일 중심 | 기준 시점과 마지막 검증일 분리 |
| AI 해석 | 장기 지식과 섞일 위험 | 후보로 보관하고 사용자 승인 후 승격 |
| 변경 이력 | 최신 내용 위주 | 대체한 판단과 변경 이유 기록 |
| 신규 노트 | 자유 형식 생성 가능 | 메타데이터 검사 뒤 발행 |
| 여러 AI 환경 | 환경별 지시가 달라질 수 있음 | 중앙 정본과 연결 문서로 통일 |
| 자동 반영 | 실행 뒤 문제 발견 | dry-run, lint, 충돌 차단, rollback |
아직 모든 과거 지식이 새 메타데이터를 가진 것은 아니다. 오래된 카드도 일괄 수정하지 않았다. 지식 환류 역시 사용자 승인이 없으면 적용되지 않는다. 불편함이 조금 남더라도 출처와 판단을 지키는 쪽이 낫다고 봤다.
## 💬 이번에 배운 것
### 폴더보다 경계가 중요했다
폴더를 잘게 나누는 것만으로 AKM이 되지는 않았다. 원본과 해석, 지식과 현재 맥락, 생성과 승인, 최신 수정과 최신 검증의 경계를 정해야 했다.
### 지식은 결과물 뒤에서 가장 많이 생겼다
업무를 시작하기 전에 모아 둔 자료만 지식이 아니었다. 실제 문서를 만들며 채택한 판단, 제외한 근거, 수정한 절차가 다음 작업에 더 직접적으로 쓰였다. 그래서 지식 환류는 인박스만큼 중요했다.
### AI의 해석과 사용자의 판단을 섞으면 안 됐다
AI가 사용자처럼 말한다고 해서 사용자의 생각이 되는 것은 아니다. 장기 지식에는 승인 주체와 변경 근거가 필요했다.
### 좋은 자동화는 멈출 줄 알아야 했다
충돌이 있는데 아무것도 반영하지 않은 결과는 실패가 아니다. 지식 시스템에서는 애매한 내용을 저장하는 것보다 중단하고 확인을 요청하는 편이 낫다.
## 🌍 작은 시스템으로 시작한다면
처음부터 큰 폴더 체계를 만들 필요는 없다. 공개 가능한 회사 보고서 샘플 한 건으로 네 문서만 만들어도 된다.
1. 원본 노트: 출처와 원문 구조를 보존한다.
2. 해석 노트: 주장, 근거, 사실, 분석을 분리한다.
3. 프로젝트 노트: 이번 작업의 목적, 범위, 결정, 검증 기준을 적는다.
4. 지식 환류 노트: 무엇을 재사용했고, 무엇이 바뀌었으며, 다음 작업에 무엇을 남길지 적는다.
그리고 다음 네 가지 질문에 답해 본다.
- 이 내용은 어디에서 왔는가?
- 지금도 유효한가?
- 누가 승인한 판단인가?
- 다음 작업에서 어떻게 다시 쓸 것인가?
이 질문에 답할 수 없다면, 지식으로 승격하기보다 후보로 남겨 두는 편이 안전하다.
## 📋 재사용 가능한 점검 프롬프트
> 내가 운영 중인 회사 보고서 업무지식 관리 시스템을 범용 지식관리와 구분해 감사해 줘.
>
> 1. 원본, 해석, 현재 작업 맥락, 실행 절차, 최종 산출물, 평가 기준이 섞여 있는지 확인한다.
> 2. 사용자 작성본과 외부 참고자료가 각각 문체, 내용, 근거, 구조 중 어디에 사용되는지 구분한다.
> 3. 최종 산출물에서 새로 생긴 사실, 분석, 판단이 다음 작업으로 돌아가는 환류 절차가 있는지 확인한다.
> 4. AI가 만든 해석이 사용자 승인 없이 장기 지식으로 승격되는 경로를 찾는다.
> 5. 각 지식의 원천, 적용 범위, 기준 시점, 마지막 검증일, 사용 이력, 변경 이유를 추적할 수 있는지 점검한다.
> 6. 실제 변경 전에 dry-run으로 영향을 확인하고, 충돌이나 출처 누락이 있으면 멈추는 조건을 제안한다.
> 7. 기존 자료를 일괄 수정하지 말고 공개 샘플 한 건으로 시작할 최소 개선안을 제시한다.
>
> 결과는 현재 구조 → 맥락 오염 위험 → 최소 개선안 → 승인 지점 → 검증 방법 순서로 작성해 줘.
## 마무리
지식관리 스터디를 듣기 전에는 이 시스템을 보고서 자료를 잘 정리하고 다시 꺼내 쓰는 구조로 봤다. 지금은 정의가 조금 달라졌다.
이제는 회사 보고서 작성이라는 특정 업무를 중심으로 원본을 보존하고, 보고서를 해석하고, 현재 작업에 맞는 지식을 골라 쓰며, 결과에서 새로 생긴 판단을 승인 후 다시 지식으로 돌려놓는다. 프라이드는 이 구조를 실행하는 AI의 이름일 뿐이다.
> 회사 보고서를 위한 지식관리 AI는 많이 기억하는 AI가 아니다. 무엇이 원본이고 무엇이 해석인지, 어떤 판단이 승인됐고 언제 다시 확인됐는지 설명하며 다음 보고서에 적용할 수 있는 AI다.
