원문과 확인 범위
이 HTML은 장 랜딩과 하위 원문 2.1, 2.2, 2.3을 함께 반영해 장 수준 절차와 판단 기준으로 재구성한 문서다. 확인일은 2026-06-06 KST이며, 장 랜딩과 세 하위 절의 마지막 편집일시는 2026년 5월 16일 1:06 오후로 기록되어 있다.
핵심 요지
1장이 대화 기록과 업무 지식의 차이를 문제로 제기했다면, 2장은 그 문제를 파일과 문서 책임으로 해결한다. 핵심은 폴더명을 보기 좋게 정하는 것이 아니라 원본은 보존되고, 해석은 분리되며, 근거는 추적 가능하고, 출력물은 다시 원천으로 돌아갈 수 있게 만드는 것이다.
장 랜딩은 2.1, 2.2, 2.3 세 절로 구성된다는 짧은 입구다. 실질 내용은 하위 절에서 완성된다. 2.1은 raw/, wiki/, AGENTS.md 또는 CLAUDE.md의 신뢰 경계를 나누고, 2.2는 이 경계를 주제 폴더와 index.md, log.md, output/으로 배치하며, 2.3은 개별 문서가 다시 질문과 산출물에 쓰일 수 있는 조건을 정한다.
원문 구조
| 절 | 역할 | 핵심 | 장 안에서의 기능 | 다음 장으로 넘기는 산출물 |
|---|---|---|---|---|
| 2장 랜딩 | 구조 장의 입구 | 2.1, 2.2, 2.3으로 구성됨을 안내한다. | 1장의 최소 결과물을 실제 구조 원칙으로 전환한다. | 세 절을 순서대로 읽는 탐색 경로 |
| 2.1 지식이 쌓이는 세 층 | 인식론적 분리 | raw/, wiki/, rules의 역할을 나눈다. | 원본, 해석, 작업 기준이 섞이는 위험을 막는다. | raw/wiki/rules 역할표, 원천 메타데이터, 최소 규칙 파일 |
| 2.2 좋은 폴더 구조 이해하기 | 물리적 배치 | 주제별 폴더, index.md, log.md, output/의 책임을 정한다. | 질문 범위를 좁히고 자료 흐름과 이력을 추적하게 한다. | 주제 폴더 구조, index/log/output 운영 기준 |
| 2.3 좋은 위키 문서의 조건 | 문서 품질 계약 | 출처, 재사용성, 링크, 확인 필요, 다음 질문을 요구한다. | 위키 문서를 단순 요약이 아니라 다시 질문 가능한 지식으로 만든다. | 출처 블록, 한 문장 요약, 근거, 확인 필요, 관련 링크 템플릿 |
세 절은 독립 체크리스트가 아니라 순차 절차다. 2.1에서 원천과 해석의 경계를 세우고, 2.2에서 그 경계를 파일 구조로 고정한 뒤, 2.3에서 개별 문서가 그 구조를 실제로 지키는지 검증한다.
장 수준 합성
1. 세 층은 파일 분류가 아니라 신뢰 경계다
raw/, wiki/, rules를 나누는 이유는 원본, LLM 요약, 사람의 판단이 한 공간에 섞일 때 나중에 무엇이 실제 근거이고 무엇이 추정인지 찾기 어려워지기 때문이다. 검색 기능은 파일을 찾아 줄 수 있지만 문장의 신뢰 등급까지 자동으로 분리해 주지는 않는다.
raw/는 돌아갈 수 있는 근거를 보존하는 공간이다. 회의록 원문, 웹 문서 저장본, PDF 추출문, 업무 메모는 raw 후보가 될 수 있다. 반대로 LLM 요약문이나 개인 해석은 보통 raw에 두지 않는 편이 안전하다. raw 파일에는 제목, 출처, 확인 날짜, 자료 성격 같은 최소 메타데이터가 필요하다.
wiki/는 raw보다 자주 읽히는 파생 지식 공간이다. raw를 그대로 반복하지 않고 여러 원천에서 반복되는 개념, 결정, 절차, 확인 필요를 주제별로 묶어야 한다. 핵심 주장 옆에는 근거 위치가 있어야 6장에서 답변 문장을 검증할 때 raw까지 되돌아갈 수 있다.
rules 파일은 LLM에게 이 구조를 어떻게 다뤄야 하는지 알려 주는 작업 기준이다. Codex 환경에서는 AGENTS.md, Claude Code 환경에서는 CLAUDE.md가 기준 파일로 설명된다. 다만 이 파일은 보안 강제 장치가 아니라 작업 지침이므로 결과물이 실제로 raw 보존, 출처 표기, 확인 필요 표시, 민감 정보 처리 기준을 지켰는지 검토해야 한다.
2. 좋은 폴더 구조는 질문의 범위를 좁힌다
2.2는 폴더 구조를 예쁜 분류 체계가 아니라 질문 경계로 본다. 모든 자료를 한 폴더에 넣으면 만들기는 쉽지만 LLM이 관련 없는 자료까지 섞어 답할 위험이 커진다. 주제 폴더는 자료 종류가 아니라 같은 업무 질문에 함께 쓰일 수 있는지로 나눠야 한다.
최소 주제 폴더는 index.md, log.md, raw/, wiki/, output/이다. index.md는 핵심 질문, 먼저 읽을 문서, 최근 산출물, 아직 없는 자료를 알려 주는 길잡이다. log.md는 자료 추가, 문서 생성, 검증 결과, 확인 필요를 추적하는 작업 이력이다. output/은 보고서, 실행 계획, 공유용 요약처럼 업무에 바로 쓰는 산출물을 다듬는 작업 공간이다.
중요한 흐름은 raw -> wiki -> output이며, 주요 변화는 log.md에 남아야 한다. output 문서가 원본의 유일한 사본이 되면 안 되고, 보고서나 실행 계획은 wiki와 raw를 근거로 만들어진 산출물이어야 한다.
3. 좋은 위키 문서는 출처, 재사용성, 링크를 함께 가진다
2.3은 좋은 위키 문서를 길이보다 재사용성으로 판단한다. 출처만 있고 질문에 쓰기 어려우면 자료 목록에 머물고, 질문에는 좋아 보이지만 출처가 없으면 위험하다. 링크가 없으면 다른 문서와 합쳐지지 못한다.
최소 출처 블록에는 원천 자료, 확인 날짜, 자료 성격, 확인 필요, 관련 문서가 들어가야 한다. 이 블록은 장식이 아니라 검증 장치다. 예를 들어 회의록 자동화 후보를 정리한다면 어떤 raw 회의록을 근거로 했는지, 현재 확인된 내용은 무엇인지, 아직 측정하지 않은 시간 절감률이나 민감 정보 기준은 무엇인지 나눠야 한다.
질문에 다시 쓰기 쉬운 문서는 한 문장 요약, 적용 조건, 판단 기준, 한계, 다시 물어볼 질문을 가진다. 문서 안에 판단 기준과 한계가 있으면 LLM에게 단순 요약이 아니라 비교표, 실험 계획, 보고서 초안을 요구할 수 있다.
4. 2장은 이후 장들의 품질 기준을 미리 고정한다
3장에서 도구를 고를 때도 raw와 wiki를 분리하고 사람이 열어 고칠 수 있는지 확인해야 한다. 4장에서 첫 위키를 만들 때도 index, log, rules가 있어야 한다. 5장에서 자료를 넣을 때도 원천 카드와 요약문이 섞이면 안 된다. 6장에서 답변을 검증하려면 문장별 근거가 raw와 wiki로 추적되어야 한다. 7장에서 산출물을 만들려면 output이 wiki와 raw로 돌아갈 수 있어야 한다. 8장에서 장기 운영을 하려면 log와 링크가 감사 대상이 된다.
근거 위치 요약
| 핵심 주장 | 근거 위치 | 적용 판단 |
|---|---|---|
| 원본과 요약이 섞이면 근거와 추정을 구분하기 어려워진다. | 2.1 세 층이 필요한 이유, 2.2 원본과 요약을 섞지 않는 원칙 | raw와 wiki를 물리적으로 분리한다. |
| raw는 검증 근거를 보존하는 층이다. | 2.1 원본을 보관하는 raw, raw 파일의 최소 형식 | 제목, 출처, 확인 날짜, 자료 성격을 남긴다. |
| wiki는 질문과 산출물에 쓰기 좋은 파생 지식이다. | 2.1 읽고 활용하는 wiki, 2.3 질문에 다시 쓰기 쉬운 문서 | 요약, 근거, 확인된 내용, 확인 필요, 다음 질문을 둔다. |
| rules 파일은 LLM 작업 기준이다. | 2.1 작업 규칙을 담는 AGENTS.md 또는 CLAUDE.md | 규칙 파일을 만들되 결과 검토를 생략하지 않는다. |
| 좋은 주제 폴더는 하나의 업무 질문으로 설명된다. | 2.2 주제별 폴더를 나누는 이유, 좋은 주제 폴더의 조건 | 자료 형식이 아니라 질문, 독자, 갱신 주기 기준으로 나눈다. |
| index, log, output은 각각 안내, 이력, 산출물 책임을 가진다. | 2.2 index, log, output의 역할 | index는 짧게 안내하고, log는 변경 흔적을 남기며, output은 근거 링크를 유지한다. |
| 좋은 위키 문서는 출처, 재사용성, 링크를 함께 갖춘다. | 2.3 출처가 남는 문서, 질문에 다시 쓰기 쉬운 문서, 링크로 이어지는 문서 | 문서 품질을 길이가 아니라 다시 질문 가능한 구조로 평가한다. |
실무 적용 절차
- 주제 폴더를 만들기 전에 이 위키가 답할 한 문장 질문을 쓴다.
- 같은 질문에 함께 쓰일 자료만 첫 주제 폴더에 둔다. 독자, 보안 기준, 산출물 형식, 갱신 주기가 다르면 분리 후보로 둔다.
- 기본 책임이 분리된
raw/,wiki/,output/,index.md,log.md, rules 파일을 만든다. raw/에는 원천 자료만 두고 제목, 출처, 확인 날짜, 자료 성격, 필요하면 버전이나 회의 날짜를 남긴다.- LLM 요약문, 개인 해석, 비교표, 결정 사항은
wiki/로 보낸다. raw 원문을 편집해 요약문처럼 만들지 않는다. wiki/문서에는 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다시 물어볼 질문, 관련 문서 링크를 둔다.- rules 파일에는 폴더 의미, raw 수정 금지, 핵심 주장 근거 표기, 확인 필요 표시, 충돌 자료 처리, 민감 정보 제한, log 갱신 기준을 적는다.
index.md에는 핵심 질문, 먼저 읽을 문서, 주요 raw 또는 wiki, 최근 output, 아직 없는 자료를 짧게 둔다.log.md에는 구조 생성, raw 추가, wiki 작성, output 생성, 검증 결과, 보류 이유를 남긴다.output/에는 보고서, 실행 계획, 공유용 요약을 두고 최소한 어떤 wiki와 raw에서 왔는지 근거 링크를 남긴다.- 첫 문서가 만들어지면 출처 없는 단정문을 찾아 근거가 없으면 확인 필요로 내리거나 후속 자료 요청으로 바꾼다.
- 문서 제목과 파일명이 질문을 돕는지 확인한다.
summary.md,notes.md처럼 모호하면 주제와 용도를 드러내는 이름으로 바꾼다. - 상위 개념, 원천 자료, 비슷한 후보, 위험 기준, output 중 실제 다음 확인에 필요한 링크만 붙인다.
- 첫 output을 만든 뒤 raw와 wiki로 다시 돌아갈 수 있는지 점검한다.
- 3장으로 넘어가기 전에 이 구조를 수동으로 설명할 수 있는지 확인한다.
예시와 체크리스트
최소 구조 역할표
| 위치 | 책임 | 반드시 남길 것 | 실패 신호 |
|---|---|---|---|
raw/ | 원천 자료 보존 | 제목, 출처, 확인 날짜, 자료 성격 | LLM 요약이 원본을 덮어쓰거나 개인 판단이 회의록처럼 섞인다. |
wiki/ | 원천 기반 재사용 지식 | 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다음 질문 | 출처 없는 단정문만 있고 raw로 돌아갈 길이 없다. |
| rules 파일 | LLM과 사람의 작업 기준 | raw 수정 금지, 출처 표기, 확인 필요, 충돌 처리, 민감 정보 기준 | 요청마다 처리 방식이 바뀌고 결과 검토 기준이 없다. |
index.md | 탐색 시작점 | 핵심 질문, 먼저 읽을 문서, 최근 산출물, 부족한 자료 | 긴 본문을 모두 넣어 길을 안내하지 못한다. |
log.md | 변경과 판단 이력 | 날짜, 작업, 결과, 확인 필요, 바뀐 문서 | 언제 자료가 들어왔고 왜 바뀌었는지 추적할 수 없다. |
output/ | 업무 산출물 작업 공간 | 보고서, 실행 계획, 공유용 요약, 근거 링크 | 산출물이 원본의 유일한 사본이 되거나 근거 링크가 없다. |
좋은 위키 문서 최소 조건
- 원천 자료, URL, 확인 날짜 중 하나 이상이 있다.
- 한 문장 요약이 문서의 업무 용도를 드러낸다.
- 확인된 내용과 확인 필요가 분리되어 있다.
- 판단 기준이나 적용 조건이 있어 다음 질문을 좁힐 수 있다.
- 원천 자료, 관련 개념, 위험 기준, 산출물 중 필요한 링크가 있다.
- 변할 수 있는 주장은 확인 날짜나 재확인 기준을 가진다.
3장으로 넘길 준비물
- 이 위키가 답할 한 문장 질문
- 원천 자료 최소 메타데이터와 보존 기준
- 요약, 근거, 확인된 내용, 확인 필요, 다음 질문을 가진 wiki 템플릿
- LLM 작업 금지 사항과 결과 검토 기준을 담은 rules 초안
- 탐색 안내와 작업 이력을 위한 index/log 초안
- 산출물이 wiki와 raw로 돌아가는 근거 기준
검증 질문
- 이 주제 폴더는 하나의 업무 질문으로 설명되는가?
raw/에 들어간 자료는 원본 상태와 출처, 확인 날짜를 유지하는가?- LLM이 만든 요약이나 사람의 해석이 raw 안에 섞이지 않았는가?
wiki/문서는 raw를 반복하는 문서가 아니라 질문과 산출물에 다시 쓰기 쉬운 문서인가?- 핵심 주장마다 근거 위치가 있거나, 없으면 확인 필요로 내려져 있는가?
AGENTS.md또는CLAUDE.md같은 rules 파일에 raw 수정 금지, 출처 표시, 확인 필요 표시, 민감 정보 기준이 있는가?- rules 파일이 있다고 해서 결과 검토를 생략하고 있지 않은가?
index.md만 보고도 위키의 핵심 질문, 먼저 읽을 문서, 최근 산출물을 찾을 수 있는가?log.md에 자료 추가와 주요 변경, 보류 사유가 남는가?- output 문서가 단독으로 읽히면서도 wiki와 raw 근거로 돌아갈 수 있는가?
- 문서 제목과 파일명이 어떤 질문에 쓰일지 드러내는가?
- 관련 링크가 탐색을 돕는가, 아니면 관계없는 문서를 많이 붙여 혼란을 만드는가?
- 시간이 지나면 틀릴 수 있는 주장이 확인 날짜 없이 현재 사실처럼 쓰이지 않았는가?
- 보안, 개인정보, 비용, 법률, 제품 기능처럼 위험한 주장을 근거 없이 단정하지 않았는가?
- 이 구조를 바탕으로 3장에서 도구 후보를 10-30분 샘플로 검증할 수 있는가?
누락 또는 주의사항
- 장 랜딩 원문은 세 하위 절 목록 중심의 짧은 페이지다. 이 문서는 장 랜딩만이 아니라 2.1-2.3 세부 원문을 함께 반영해 장 수준으로 재구성했다.
- 원문에는 Bash/Zsh 기반 실습 명령과 예제 파일 내용이 나온다. 이 장 개요 문서는 명령을 장문 복제하지 않고 실습의 성공 기준과 구조 원칙을 절차와 체크리스트로 요약했다.
AGENTS.md와CLAUDE.md는 작업 기준을 전달하는 파일이지 보안 정책을 강제하는 장치가 아니다. 결과물이 실제로 raw 보존, 출처 표기, 확인 필요, log 갱신을 지켰는지 별도로 확인해야 한다.- 외부 구현체, 릴리스, 명령어, 도구별 파일명은 2026-05-16 KST 확인 자료 기준이다. 실제 도입 전에는 현재 공식 문서, 릴리스, 설치된 도움말, 조직 보안 기준을 다시 확인해야 한다.
- WiCER는 원문에서 제한된 근거로 언급된 2026년 5월 arXiv 프리프린트다. 연구 결과나 제품 기능을 현재 업무 기준으로 단정하지 말고 무검증 컴파일의 위험을 설명하는 참고로만 사용한다.
- 첫 구조를 만들 때부터 실제 고객 정보, 계약 정보, 개인정보, 비공개 코드를 넣지 않는 편이 안전하다. 필요한 경우 익명화, 접근 권한, 외부 전송 경로, 보관 정책을 먼저 확인해야 한다.