WikiDocs LLM위키 완벽 가이드 · 2장 기본 구조

2.2 좋은 폴더 구조 이해하기 원문 기반 심화 분석

핵심 요약

이 절의 결론은 LLM위키의 폴더 구조를 보기 좋은 정리법이 아니라 답변 품질과 검증 가능성을 지키는 운영 경계로 보라는 것이다. 최소 구조는 raw/, wiki/, output/, index.md, log.md이며, 각 위치는 원본 보존, 해석 정리, 업무 산출물, 탐색 출발점, 처리 이력이라는 서로 다른 책임을 가진다.

주제별 폴더는 파일 형식이 아니라 질문 범위로 나눈다. PDF, 회의록, 웹 문서처럼 형식이 달라도 같은 업무 질문에 답하면 같은 주제에 둘 수 있지만, 보안 범위, 독자, 산출물 목적, 갱신 주기가 다르면 분리해야 한다.

가장 중요한 원칙은 원본과 요약을 섞지 않는 것이다. 회의록 원문은 raw/, LLM이나 사람이 해석한 정리 문서는 wiki/, 실행 계획과 보고서 초안은 output/에 둔다. 이 구분이 무너지면 요약 오류, 원문 오류, LLM 추정을 나중에 구분하기 어렵다.

원문 구조와 실무 의미

원문 절핵심 내용실무 의미
도입부와 최소 구조LLM위키를 다시 찾고, 근거를 확인하고, 산출물로 바꾸는 작업 공간으로 설명한다.구조는 취향이 아니라 사람과 LLM이 같은 기준으로 자료를 찾기 위한 신뢰 경계다.
주제별 폴더를 나누는 이유질문, 독자, 보안 범위, 갱신 주기가 다른 자료를 한곳에 넣으면 답변이 넓고 흐릿해진다.첫 폴더는 하나의 업무 질문으로 설명되어야 한다.
기본 파일과 폴더의 역할index.md, log.md, raw/, wiki/, output/의 책임을 구분한다.탐색, 감사, 원본, 해석, 공유 문서를 섞지 않는다.
문서가 흐르는 방향원본이 정리 문서로, 정리 문서가 색인과 산출물로, 주요 작업이 로그로 이어진다.output/은 raw/를 대체하지 않고 근거로 돌아갈 수 있어야 한다.
실습과 검증 포인트작은 주제 폴더를 만들고, 원본과 요약을 분리 저장하며, 산출물에 근거를 연결한다.완료 기준은 파일 존재가 아니라 검증 가능성이다.

폴더 구조는 답변 범위를 제한하는 장치

자료가 많아도 위치와 역할이 흐트러지면 원본, 요약, 산출물, 판단 이력이 섞인다. 그러면 LLM은 관련 없는 자료까지 함께 사용해 그럴듯하지만 검증하기 어려운 답변을 만들 수 있다. 2.2의 폴더 구조는 이 위험을 줄이는 기본 방어선이다.

위험구조가 없을 때2.2의 대응확인 질문
질문 범위 확장업무 자동화 자료와 기술 선정 자료가 한 질문에 섞인다.주제별 폴더를 하나의 중심 질문 기준으로 나눈다.이 폴더는 한 문장 질문으로 설명되는가?
근거 회귀 실패산출물 문장을 보고 원본 자료를 찾지 못한다.output/ 문서에 wiki/와 raw/ 근거를 남긴다.보고서에서 원천 자료로 돌아갈 수 있는가?
추정의 사실화LLM 요약과 원문이 같은 공간에 있어 해석이 원본처럼 보인다.원본은 raw/, 해석은 wiki/, 공유 산출물은 output/에 둔다.이 문장은 원문인가, 정리인가, 산출물 표현인가?

이 관점은 2.1 지식이 쌓이는 세 층과 연결된다. 2.1이 raw, wiki, rules의 층을 설명했다면, 2.2는 그 층을 실제 주제 폴더 안에 배치하고 index.md, log.md, output/의 역할을 더한다.

주제 폴더의 기준은 파일 형식이 아니라 질문

좋은 LLM위키는 모든 자료를 한곳에 넣지 않는다. 회의록에서 실행 항목 뽑기와 주간 보고서 초안 만들기는 반복 업무 자동화라는 같은 질문에 속할 수 있지만, 고객 문의 개인정보 처리 기준은 보안과 법무 검토가 필요해 분리하는 편이 안전하다. 프런트엔드 프레임워크 조사는 기술 선정 리서치에 가깝기 때문에 또 다른 주제다.

판단 기준같은 폴더 신호분리 신호
중심 질문같은 업무 질문에 답한다.새 질문을 연다.
독자같은 팀이나 같은 의사결정자가 읽는다.법무, 보안, 경영진, 외부 공유처럼 독자가 달라진다.
자료 민감도접근 권한이 같다.개인정보, 계약, 보안 검토가 필요하다.
산출물 목적같은 보고서, 후보표, 실행 계획으로 이어진다.원고, 기술 리서치, 정책 검토처럼 결과물이 다르다.
갱신 주기비슷한 주기로 갱신된다.매주 갱신 자료와 일회성 보고서 자료가 섞인다.

형식이 달라도 같은 질문에 필요한 자료라면 같은 주제 폴더에 둘 수 있다. 반대로 같은 Markdown 파일이라도 질문과 보안 범위가 다르면 분리해야 한다.

좋은 주제 폴더의 조건

작은 시작

첫 자료는 3-10개 수준으로 제한한다. 수백 개 파일을 한 번에 넣으면 어떤 자료가 답변 품질을 바꾸었는지 추적하기 어렵다.

중심 질문

폴더는 하나의 질문으로 설명되어야 한다. work-automation/은 범위가 드러나지만 everything/, misc/, notes/는 실패 신호다.

명확한 산출물

첫 output은 후보 목록, 보고서 초안, 실행 계획처럼 평가 가능한 형태여야 한다. 산출물이 불분명하면 폴더 범위도 흐려진다.

되돌릴 수 있음

자료를 잘못 넣었을 때 분리하거나 보류할 수 있어야 한다. 보안과 접근 권한도 한 번에 설명 가능해야 한다.

기본 위치별 책임

위치넣을 것넣지 말 것이유
raw/회의록 원문, 웹 문서 저장본, 메모 원문, 출처와 확인일LLM이 다시 쓴 요약, 사람의 해석, output 초안최종 근거 위치이므로 원천성을 보존해야 한다.
wiki/요약, 비교, 결정 사항, 확인 필요, 근거 링크출처 없는 단정, raw 전체 복제, 산출물 최종본질문 가능한 지식으로 정리하되 파생 문서임을 드러낸다.
output/보고서, 실행 계획, 공유용 요약, 근거 문서 링크원본 자료의 유일한 사본, 검증 전 정책 결정업무에 쓰되 근거 회귀가 가능해야 한다.
index.md핵심 질문, 먼저 읽을 문서, 최근 산출물, 확인 필요긴 원문 전체, 보고서 본문, 무관 링크탐색 출발점 역할을 유지해야 한다.
log.md자료 추가, 문서 생성, 검증 결과, 보류 이유최종 보고서 본문, 대화 전문, 무관 작업변경과 판단의 흔적만 남긴다.

index.md, log.md, output/ 운영법

index.md는 탐색 출발점

index.md에는 모든 내용을 자세히 쓰지 않는다. 핵심 질문, 먼저 읽을 문서, 최근 산출물, 원천 자료 위치, 확인 필요를 짧게 적어 사람과 LLM이 시작 위치를 찾게 한다. 길어지면 위키 본문과 충돌하므로 긴 원문, 보고서 본문, 출처 없는 주장은 다른 위치로 보내야 한다.

log.md는 최소 처리 이력

로그는 완벽한 감사장이 아니라 원인 추적을 위한 최소 기록이다. 날짜, 작업, 변경 파일, 결과, 확인 필요를 남기면 이상한 답변이나 오래된 판단이 나왔을 때 어떤 자료가 원인이었는지 되짚을 수 있다.

output/은 근거 있는 산출물 작업 공간

output/은 최종본 보관함만이 아니다. 초안, 검토본, 공유본이 모두 생기는 실무에서는 외부에 보여 줄 형태로 문서를 다듬는 작업 공간이다. 단, output은 단독으로 읽을 수 있어야 하고 동시에 wiki/와 raw/ 근거로 돌아갈 수 있어야 한다.

실무 적용 절차

  1. 첫 주제 후보를 한 문장 질문으로 적는다.
  2. 이 질문에 직접 답하지 않는 자료를 제외한다.
  3. work-automation처럼 질문 범위가 드러나는 폴더 이름을 정한다.
  4. 초기 자료 수를 3-10개 수준으로 제한한다.
  5. 최소 구성인 raw/, wiki/, output/, index.md, log.md를 만든다.
  6. index.md에는 핵심 질문, 먼저 읽을 문서, 최근 산출물, 확인 필요를 짧게 적는다.
  7. log.md에는 구조 생성, 자료 추가, 위키 문서 생성, output 생성, 검증 결과, 보류 이유를 날짜와 함께 남긴다.
  8. raw 자료에는 출처, 확인일, 자료 성격을 붙인다.
  9. wiki 문서는 raw를 읽고 다시 질문하기 좋은 구조로 만든다.
  10. output 문서에는 사용한 wiki/와 raw/ 근거를 명시한다.
  11. LLM에게 작업을 맡길 때는 raw 수정 금지, wiki 근거 표시, output 근거 연결, log 갱신을 요청한다.
  12. 작업 후 파일 목록 확인만 하지 말고 각 위치의 내용이 해당 책임에 맞는지 확인한다.
  13. 새 자료가 들어오면 중심 질문, 독자, 민감도, 산출물, 갱신 주기로 같은 폴더 여부를 판단한다.
  14. output에서 새 결정이 나오면 관련 wiki 문서와 log.md에 반영한다.
  15. 정기 점검 때 출처 없는 wiki 문장, 근거 없는 output 주장, 오래된 log 미반영 항목을 찾는다.

실무 템플릿

주제 폴더 설계 카드

항목작성 내용확인 질문
폴더 이름범위가 드러나는 짧은 이름범위가 드러나는가?
중심 질문이 위키가 답하려는 업무 질문 한 문장한 문장으로 설명되는가?
첫 자료초기 raw 후보3-10개 안에서 시작하는가?
제외할 자료다른 질문, 다른 독자, 다른 보안 범위의 자료분리하거나 보류해야 하는가?
예상 output보고서, 실행 계획, 공유 요약 등평가 가능한 결과물인가?

index.md 최소 골격

# 주제 위키 이름

## 핵심 질문
- 이 위키가 답하려는 업무 질문 한 문장

## 먼저 읽을 문서
1. wiki/...
2. wiki/...

## 최근 산출물
- output/...

## 원천 자료 위치
- raw/...

## 확인 필요
- 아직 자료가 없거나 검토가 필요한 항목

log.md 최소 골격

# 처리 이력

| 날짜 | 작업 | 변경 파일 | 결과 | 확인 필요 |
| --- | --- | --- | --- | --- |
| 2026-06-06 | 위키 초기 구조 생성 | index.md, log.md, raw/, wiki/, output/ | 기본 위치 분리 | 첫 raw 자료 선정 |

output 근거 블록

## 근거 문서

- wiki/...
- raw/...

## 확인 필요

- 이 산출물에서 아직 원천 확인이 필요한 주장
- 담당자, 기한, 승인 기준이 정해지지 않은 실행 항목

검증 체크리스트

구조

  • 주제 폴더가 하나의 업무 질문으로 설명된다.
  • 폴더 이름이 everything, misc, notes처럼 범위가 흐리지 않다.
  • 첫 자료 수가 3-10개 정도로 제한되어 있다.
  • 질문, 독자, 보안 범위, 산출물 목적, 갱신 주기가 다른 자료를 분리했다.
  • raw/, wiki/, output/, index.md, log.md가 같은 주제 폴더 아래 있다.
  • index.md가 핵심 질문과 먼저 읽을 문서를 안내한다.
  • log.md가 자료 추가, 위키 문서 생성, output 생성, 검증 결과를 남긴다.

원본/요약 분리

  • 원본 회의록, 웹 문서 저장본, 메모 원문은 raw/에 있다.
  • LLM이나 사람이 정리한 요약, 비교, 결정 사항은 wiki/에 있다.
  • raw/ 문서에 LLM 요약이나 사람의 판단이 섞이지 않았다.
  • wiki/ 문서에는 근거 raw/... 또는 원문 URL과 확인일이 있다.
  • 확인되지 않은 내용은 확인 필요로 분리되어 있다.
  • 요약 문장이 원문보다 강한 단정으로 바뀌지 않았다.

산출물과 LLM 작업

  • output/ 문서가 보고서, 실행 계획, 공유용 요약처럼 업무 목적을 가진다.
  • output 문서 안에 사용한 wiki/와 raw/ 근거가 명시되어 있다.
  • output 문서가 원천 자료의 유일한 사본이 되지 않는다.
  • output에서 새로 나온 결정, 보류, 확인 필요가 log.md에 남았다.
  • LLM에게 raw 원본을 임의로 수정하지 말고, wiki와 output에 근거를 남기며, 작업 후 index와 log를 갱신하라고 요청했다.

좋은 질문과 사람의 검증 질문

LLM에게 던질 질문

  • 현재 주제 폴더가 하나의 업무 질문으로 설명되는지 점검해 주세요.
  • 파일 목록을 raw, wiki, output, index.md, log.md 역할 기준으로 검토해 주세요.
  • output 초안의 핵심 주장마다 사용한 wiki/와 raw/ 근거를 붙여 주세요.
  • 새 자료가 기존 주제에 들어갈지 별도 주제로 분리할지 중심 질문, 독자, 민감도, 산출물 목적, 갱신 주기로 판단해 주세요.
  • index.md와 log.md를 짧게 갱신해 주세요.

사람이 확인할 질문

  • 이 폴더는 정말 하나의 업무 질문에 답하는가?
  • 같은 폴더에 넣은 자료들의 독자와 보안 범위가 같은가?
  • 원본 자료는 raw/에 있고 요약과 판단은 wiki/에 있는가?
  • index.md만 보고 처음 읽을 위치와 최근 output을 찾을 수 있는가?
  • output 문서를 보고 관련 wiki와 raw 근거로 돌아갈 수 있는가?
  • 오래된 output이 현재 기준처럼 사용되고 있지 않은가?

흔한 실패와 수정 방향

실패 사례왜 문제인가수정 방향
everything/에 모든 자료를 넣는다.질문 범위가 흐려지고 관련 없는 근거가 섞인다.중심 질문이 다른 자료는 별도 주제로 분리한다.
raw/에 LLM 요약문을 저장한다.나중에 원문과 해석을 구분할 수 없다.원본은 raw, 요약과 결정은 wiki에 둔다.
index.md에 긴 원문과 보고서 본문을 넣는다.안내판 역할을 잃고 본문과 충돌한다.핵심 질문, 먼저 읽을 문서, 최근 산출물, 확인 필요만 둔다.
log.md를 비워 둔다.이상한 답변이나 오래된 판단의 원인을 추적하기 어렵다.자료 추가, 문서 생성, 검증 결과, 보류 이유를 최소 표로 남긴다.
output 보고서가 근거 링크 없이 남는다.보고서 수정 때 원문을 다시 찾기 어렵고 산출물이 사실의 유일한 사본처럼 된다.output 안에 wiki/와 raw/ 근거 블록을 둔다.
보안 검토가 필요한 자료를 같은 주제에 섞는다.접근 권한과 검토 기준이 달라져 사고 위험이 커진다.개인정보, 계약, 법무 검토 자료는 별도 주제 또는 보류 위치로 둔다.

관련 문서

한계와 완료 기준

이 분석은 2026-06-06 KST에 확인된 WikiDocs 원문과 로컬 Markdown 분석 문서를 바탕으로 재구성한 것이다. 원문 표현, 예시 명령, 마지막 편집 여부는 WikiDocs 원문에서 다시 확인해야 한다.
  1. 첫 주제 폴더가 하나의 중심 질문으로 설명된다.
  2. raw/, wiki/, output/, index.md, log.md의 역할이 분리되어 있다.
  3. 원본 자료와 LLM 또는 사람의 요약이 같은 위치에 섞이지 않는다.
  4. index.md는 탐색 출발점, log.md는 처리 이력, output/은 근거 있는 업무 산출물 공간으로 작동한다.
  5. output 문서에서 관련 wiki/와 raw/ 근거로 돌아갈 수 있다.
  6. 새 자료를 같은 폴더에 둘지 분리할지 중심 질문, 독자, 민감도, 산출물 목적, 갱신 주기로 판단할 수 있다.
  7. 작업 결과와 확인 필요가 log.md에 남아 다음 감사와 갱신으로 이어진다.