원문 메타
이 HTML은 원문 절 이름과 실습 의도를 기준으로 분석, 절차, 판단표, 검증 질문을 재구성한 페이지다. 도구 명령과 외부 구현체 정보는 원문 확인 기준을 반영하지만, 실제 실행 전에는 현재 공식 README, Releases, Changelog, 설치된 도움말을 다시 확인해야 한다.
핵심 요약
첫 선택은 표준화가 아니다
3.1의 핵심은 기능이 가장 많은 도구를 찾는 것이 아니라 이번 주 안에 작은 자료 하나를 넣고, 위키 문서 하나를 만들고, 그 문서로 질문까지 해 보는 낮은 비용의 실험을 고르는 것이다.
수동 Markdown이 기준선이다
raw, wiki, output, index.md, log.md, AGENTS.md 또는 CLAUDE.md의 책임을 직접 확인하면 이후 에이전트, CLI, 데스크톱 선택의 품질 기준이 생긴다.
에이전트는 지침 로드가 게이트다
Codex나 Claude Code를 이미 쓴다면 에이전트 방식이 자연스럽지만, 지침 파일이 실제로 읽히고 raw 보존, 근거 표시, 확인 필요, 색인 갱신 규칙을 설명할 수 있는지 먼저 확인해야 한다.
CLI와 데스크톱은 확장 선택지다
CLI는 반복성과 재현성이 필요할 때, 데스크톱은 파일 트리와 그래프를 눈으로 검토해야 할 때 유용하다. 둘 다 원본 보존, export, 권한, 외부 호출 범위 검증을 대신하지 않는다.
원문 구조와 실무 의미
| 원문 절 | 핵심 내용 | 실무 의미 |
|---|---|---|
| 도입부 | 기능 많은 도구보다 작은 end-to-end 흐름을 우선한다. | 도구 구매나 표준화가 아니라 낮은 위험의 검증 실험으로 시작한다. |
| 학습자료: 시작 방식 선택 흐름 | 수동 Markdown, 에이전트, CLI, 데스크톱 중 현재 조건에 맞는 방식을 좁힌다. | 자료 수, 기술 전제, 검토 방식, 민감도를 선택 이유로 남긴다. |
| 방식별 비교표 | 잘 맞는 상황, 장점, 부담을 함께 비교한다. | 유지보수, 색인, 로그, 권한, 버전 확인 부담까지 본다. |
| 수동 Markdown 방식 | raw, wiki, output, 지침 파일 구조를 직접 만든다. | 자동화 없이도 원천과 정리본의 신뢰 경계를 학습한다. |
| 회의록 최소 위키 실습 | 회의 메모를 원천으로 보관하고 위키 문서, 근거, 색인, 확인 필요를 남긴다. | 문서 생성보다 원본 보존과 검증 가능성을 확인한다. |
| Claude Code와 OpenAI Codex 기반 방식 | 에이전트가 파일을 읽고 쓰며 위키를 갱신한다. | Codex는 AGENTS.md, Claude Code는 CLAUDE.md 계열 로드 여부를 확인한다. |
| 플러그인 흐름 읽기 | 주제 생성, 자료 입력, 질의가 별도 단계로 나뉜다. | /wiki, @wiki를 모든 환경의 공통 내장 기능으로 단정하지 않는다. |
| CLI와 데스크톱 도구 방식 | CLI는 반복성, 데스크톱은 가시성이 강하다. | 반복 자동화나 화면 중심 관리가 실제 필요해졌을 때 확장한다. |
| 3.1의 검증 포인트 | 선택 이유, 원천/위키 분리, 작업 기준, 예상 결과, 명령 출처, 민감 자료 기준을 확인한다. | 3.2의 도구 선택표로 넘어가기 전 게이트로 쓴다. |
상세 분석
1. 첫 방식 선택은 위험 제한 장치다
큰 자료 묶음이나 실제 고객 정보를 처음부터 넣으면 실패 원인이 자료 범위인지, 지침 파일인지, 도구 버전인지 분리하기 어렵다. 그래서 원문은 작은 자료 하나로 위키 생성과 질의까지 검증하는 방식을 권한다.
| 현재 조건 | 낮은 위험의 첫 방식 | 이유 | 보류할 선택 |
|---|---|---|---|
| 자료가 1-5개이고 구조 학습이 우선 | 수동 Markdown | 원본과 정리본의 위치가 눈에 보인다. | CLI 자동화, 대형 플러그인 |
| Codex나 Claude Code로 파일을 다룸 | 에이전트 기반 | 기존 파일 편집 흐름에 위키 규칙을 붙일 수 있다. | 지침 로드 확인 없는 플러그인 |
| 같은 ingest, compile, query, audit 반복 | CLI | 명령 기록과 재현성이 좋다. | 런타임과 API 키 전제를 모르는 상태의 CLI |
| 문서 연결과 그래프를 화면으로 봐야 함 | 데스크톱 | 파일 트리, 미리보기, 그래프 검토가 쉽다. | export와 원본 보존이 불명확한 앱 의존 |
| 조직 보안 기준이 불명확 | 수동 또는 가상 자료 실습 | 외부 호출, 웹 접근, 저장 위치 위험을 줄인다. | 실제 고객 자료나 비공개 코드 투입 |
2. 수동 Markdown은 모든 방식의 품질 기준선이다
수동 방식은 초보자용 임시방편이 아니라 LLM위키의 신뢰 경계를 배우는 기준선이다. raw에는 원천, wiki에는 근거 기반 정리, output에는 보고서와 실행 계획, AGENTS.md에는 작업 규칙을 둔다.
| 항목 | 좋은 상태 | 실패 신호 | 수정 방향 |
|---|---|---|---|
raw | 회의 메모, 웹 문서, 기존 양식 같은 원천이 보존된다. | LLM 요약문이나 해석이 원본처럼 섞인다. | 원본과 파생 문서를 물리적으로 분리한다. |
wiki | 확인된 내용, 확인 필요, 다음 질문이 근거와 함께 있다. | 자연스러운 요약문만 있고 근거 경로가 없다. | 문장마다 raw 또는 URL 근거를 붙인다. |
output | 보고서와 실행 계획이 wiki와 raw 근거로 돌아갈 수 있다. | output이 원천의 유일한 사본처럼 쓰인다. | 관련 wiki와 raw 링크를 남긴다. |
AGENTS.md | raw 수정 금지, 근거 표시, 확인 필요, index/log 갱신 기준이 있다. | 작업마다 LLM 처리 방식이 달라진다. | 규칙을 짧고 검증 가능한 문장으로 고친다. |
index.md, log.md | 문서 위치와 작업 이력을 안내한다. | 새 문서가 생겨도 찾을 경로와 이유가 없다. | 새 문서 링크, 한 줄 설명, 처리 이력을 남긴다. |
3. 최소 실습의 성공 기준은 검증 가능성이다
회의록 하나로 최소 위키를 만들 때는 raw 보존, wiki 문서 생성, 근거 표시, 색인 갱신, 확인 필요 표시, 민감 정보 배제를 확인해야 한다. 좋은 답변을 받았다는 느낌보다 다음 작업자가 근거로 돌아갈 수 있는지가 중요하다.
| 검증 항목 | 통과 기준 | 실패 시 먼저 볼 것 |
|---|---|---|
| 원본 보존 | raw 파일 내용이 작업 전후로 같거나 승인된 수정이 log에 있다. | 작업 규칙, 에이전트 권한, 요청 문장 |
| 정리 문서 생성 | wiki 아래 새 문서가 생기고 목적이 보인다. | 출력 경로, 파일명 규칙, 폴더 권한 |
| 근거 표시 | 핵심 주장 옆에 raw 경로, URL, 확인일 중 하나 이상이 있다. | 출처 요구의 구체성, 위키 템플릿 |
| 색인 갱신 | index.md에 새 문서 링크와 한 줄 설명이 있다. | 요청에 색인 갱신 포함 여부 |
| 불확실성 표시 | 메모에 없는 효과, 담당자, 일정, 성능 수치는 확인 필요로 남는다. | LLM 과잉 일반화, 검증 질문 누락 |
| 보안 | 첫 샘플에 고객명, 계약 정보, 개인정보, 비공개 코드가 없다. | 샘플 자료 선정, 익명화 기준 |
4. 에이전트 방식은 지침 파일 로드 여부가 첫 게이트다
에이전트 방식의 장점은 기존 파일 작업 흐름에 LLM위키를 붙일 수 있다는 점이다. 하지만 지침 파일이 실제로 읽히는지 확인하지 않으면 raw와 wiki의 경계, 근거 표시, 확인 필요, index/log 갱신 기준이 작업마다 흔들린다.
| 항목 | OpenAI Codex 기준 | Claude Code 기준 | 실무 주의 |
|---|---|---|---|
| 대표 지침 파일 | AGENTS.md | CLAUDE.md 또는 .claude/CLAUDE.md | 같은 파일을 모든 도구가 자동으로 읽는다고 가정하지 않는다. |
| 확인 방법 | 현재 지침 요약을 요청하거나 Codex 문서의 로드 규칙을 확인한다. | /memory, /init, 현재 메모리 요약 등을 확인한다. | 요약이 실제 규칙과 맞는지 사람이 대조한다. |
| 최소 규칙 | raw 수정 금지, wiki 근거 표시, 확인 필요, index/log 갱신 | 같은 규칙을 Claude Code가 읽는 위치에 둔다. | 지침은 품질 보장이 아니므로 결과물을 다시 검토한다. |
5. 플러그인, CLI, 데스크톱은 흐름과 권한을 읽어야 한다
/wiki나 @wiki 같은 명령은 특정 구현체 문서의 진입점이지 모든 Codex나 Claude Code 환경의 공통 내장 기능이 아니다. 플러그인은 설치 권한, 네트워크 접근, 저장 위치, 명령 최신성, 근거 회귀, 민감 정보 처리를 확인해야 한다. CLI는 Node.js 또는 Python 버전, API 키, 단계 분리, 저장 구조, 재현성을 확인해야 한다. 데스크톱은 원본 보존, export, 백업, 삭제, 모델 설정, 외부 호출 범위를 확인해야 한다.
주의: 화면 그래프나 미리보기는 근거 검증을 대신하지 않는다. 시각화가 보여 주는 연결이 실제 출처 관계인지, 단순 유사도 연결인지 별도로 확인해야 한다.
6. 3.1의 완료 기준은 선택 메모와 샘플 증거다
3.1을 읽고 남겨야 할 산출물은 시작 방식 선택 메모, 최소 샘플 결과, 지침 파일 확인 메모, 보류 사유 목록이다. 이 네 가지가 있어야 3.2에서 설치, 유지보수, 저장 구조, 자료 형식, 권한, 이동성을 구체적으로 평가할 수 있다.
| 산출물 | 내용 | 합격 기준 |
|---|---|---|
| 시작 방식 선택 메모 | 수동, 에이전트, CLI, 데스크톱 중 첫 선택과 이유 | 선택 이유가 자료 수, 기술 전제, 민감도, 검토 방식과 연결된다. |
| 최소 샘플 결과 | 더미 raw, wiki 문서, index 또는 log 갱신, 확인 필요 | 원본과 정리본이 섞이지 않고 근거가 남는다. |
| 지침 파일 확인 메모 | AGENTS.md 또는 CLAUDE.md 로드 확인 기록 | 에이전트가 raw 보존과 근거 표시 규칙을 요약할 수 있다. |
| 보류 사유 목록 | CLI, 데스크톱, 플러그인을 지금 쓰지 않는 이유 | 보류 이유가 막연한 불안이 아니라 확인 전제 부족으로 정리된다. |
실무 적용 절차
- 첫 LLM위키 후보의 자료 수를 센다. 자료가 1-5개이고 구조 학습이 우선이면 수동 Markdown을 기본값으로 둔다.
- 자료의 민감도를 표시한다. 고객명, 계약 정보, 개인정보, 비공개 코드, 내부 정책 원문은 첫 실험에서 제외하거나 익명화한다.
- 현재 이미 쓰는 도구를 적는다. Codex나 Claude Code를 매일 쓴다면 에이전트 방식 후보로 둔다.
- 반복 작업 요구와 화면 중심 검토 요구를 분리해서 적는다. 반복성이 높으면 CLI, 화면 검토가 높으면 데스크톱 후보를 검토한다.
- 첫 선택 이유를 한 문장으로 쓴다. 예: 자료가 적고 raw와 wiki 경계를 먼저 익혀야 하므로 수동 Markdown으로 시작한다.
- 더미 회의록이나 익명화 메모 하나를 준비하고
raw,wiki,output, 지침 파일 구조를 만든다. - 작업 규칙에 raw 수정 금지, 근거 표시, 확인 필요 표시, index와 log 갱신 기준을 적는다.
- LLM에게 raw를 읽고 wiki 문서 하나를 만들게 하되 자료 범위, 출력 경로, 근거 파일명, raw 수정 금지, 색인 갱신을 명시한다.
- 처리 후 raw 보존, wiki 문서 생성, 근거 표시, 확인 필요, index 또는 log 갱신을 확인한다.
- 에이전트 방식이면 현재 지침 요약을 요청하고, 플러그인 또는 CLI 방식이면 README, Releases, 설치된 도움말을 확인한다.
- 데스크톱 방식이면 export, 백업, 삭제, 원본 보존, 모델 설정, 외부 호출 범위를 확인한다.
- 실패가 나면 도구를 바로 바꾸지 말고 작업 규칙, 요청 문장, 저장 위치, 버전, 권한, 자료 범위를 분리해서 원인을 본다.
- 3.2로 넘어가기 전 시작 방식 선택 메모, 샘플 검증표, 지침 파일 확인 메모, 보류 사유를 남긴다.
실무 템플릿
시작 방식 선택 카드
| 항목 | 작성 내용 | 판단 기준 |
|---|---|---|
| 첫 업무 주제 | 예: 회의록 실행 항목 정리 | 4.1에서 더 좁힐 수 있어야 한다. |
| 첫 자료 수 | 예: 회의록 1개, 기존 양식 1개 | 1-5개면 수동 방식이 안전하다. |
| 민감 정보 | 없음, 익명화 필요, 보류 | 민감하면 실제 자료 대신 더미 자료로 시작한다. |
| 현재 쓰는 도구 | Codex, Claude Code, 웹 LLM, 없음 | 이미 쓰는 도구가 있으면 에이전트 후보가 된다. |
| 반복성 | 낮음, 중간, 높음 | 높으면 CLI 자동화 후보가 된다. |
| 화면 검토 필요 | 낮음, 중간, 높음 | 높으면 데스크톱 후보가 된다. |
| 첫 선택 | 수동 Markdown, 에이전트, CLI, 데스크톱 | 선택 이유를 한 문장으로 쓴다. |
| 보류한 방식 | 지금 쓰지 않을 방식과 이유 | 보류도 기록해야 나중에 재검토할 수 있다. |
최소 샘플 검증표
| 검증 항목 | 확인 결과 | 증거 위치 | 후속 조치 |
|---|---|---|---|
| raw 원본이 보존됐다. | raw/... | 변경됐다면 규칙과 권한을 수정한다. | |
| wiki 문서가 생성됐다. | wiki/... | 없으면 출력 경로와 요청을 수정한다. | |
| 근거가 남았다. | raw 경로, URL, 확인일 | 없으면 출처 블록을 요구한다. | |
| 확인 필요가 남았다. | wiki의 확인 필요 섹션 | 없으면 추정 문장을 낮춘다. | |
| index 또는 log가 갱신됐다. | index.md, log.md | 없으면 작업 요청에 갱신을 포함한다. | |
| 민감 정보가 없다. | 샘플 자료, output | 있으면 삭제 또는 익명화하고 log에 남긴다. |
검증 체크리스트
시작 방식
- 첫 선택의 이유를 한 문장으로 썼다.
- 선택 이유가 자료 수, 민감도, 현재 도구, 반복성, 화면 검토 필요와 연결된다.
- 원천 자료와 위키 문서가 분리된다.
- 첫 선택을 최종 표준으로 단정하지 않았다.
수동 Markdown 샘플
- 더미 또는 익명화 회의록 하나를 raw에 넣었다.
- wiki 문서에는 요약, 근거, 확인된 내용, 확인 필요, 다음 질문이 있다.
- raw 파일이 LLM 작업 후 바뀌지 않았다.
- 새 wiki 문서 링크가 index에 추가됐다.
에이전트와 플러그인
- Codex의
AGENTS.md또는 Claude Code의CLAUDE.md로드 여부를 확인했다. - 에이전트가 raw 보존, 근거 표시, 확인 필요 규칙을 요약할 수 있다.
- 플러그인 설치 권한, 네트워크 접근, 저장 위치, LLM 호출 범위를 확인했다.
CLI와 데스크톱
- CLI 런타임 버전과 API 키 처리 방식을 확인했다.
- ingest, compile, query, lint 또는 audit 단계가 분리된다.
- 데스크톱 앱의 원본 보존, export, 백업, 삭제, 모델 설정을 확인했다.
보안과 최신성
- 첫 실험에 고객명, 계약 조건, 개인정보, 비공개 코드, 내부 정책 원문을 넣지 않았다.
- 외부 웹 접근, URL 수집, 플러그인 호출, LLM API 호출 범위를 확인했다.
- 책의 명령 예시를 현재 명령으로 단정하지 않고 README, Releases, 설치된 도움말을 다시 확인했다.
좋은 질문과 검증 질문
LLM에게 던질 좋은 질문
- 아래 첫 업무 후보를 기준으로 자료 수, 민감 정보, 현재 사용하는 도구, 반복성, 화면 검토 필요를 따져 수동 Markdown, 에이전트, CLI, 데스크톱 중 하나를 추천해 주세요.
- 이 더미 raw 메모를 기준으로
wiki문서 하나를 만들어 주세요. raw는 수정하지 말고 확인된 내용, 근거 파일명, 확인 필요, 다음 질문을 분리해 주세요. - 현재
AGENTS.md또는CLAUDE.md규칙을 요약하고 raw 보존, 근거 표시, 확인 필요, index/log 갱신 기준이 빠졌는지 점검해 주세요. - 이 도구 후보의 README와 Releases 확인 결과를 기준으로 실행 전 보류해야 할 항목을 설치, 저장 위치, 권한, 자료 형식, 보안 기준으로 나눠 주세요.
사람이 확인할 검증 질문
- 이 방식은 이번 주에 작은 자료 하나로 끝까지 검증 가능한가?
- 내가 고른 이유가 도구 선호가 아니라 자료 수, 검증 비용, 보안 기준과 연결되는가?
- raw 원본과 wiki 정리본의 위치를 다른 사람에게 설명할 수 있는가?
- LLM이 만든 문서에서 어느 문장이 원천 근거를 갖고 어느 문장이 확인 필요인지 보이는가?
- 지침 파일이 실제로 읽혔는지 확인했는가?
- 실제 고객 정보나 비공개 자료를 넣기 전에 조직 보안 기준과 외부 호출 범위를 확인했는가?
흔한 실패와 수정 방향
| 실패 사례 | 왜 문제인가 | 수정 방향 |
|---|---|---|
| 기능이 많은 도구부터 고른다. | 작은 자료 하나의 end-to-end 검증 없이 도구 부담만 커진다. | 이번 주 샘플 하나로 검증 가능한 방식부터 고른다. |
| 수동 Markdown을 임시방편으로 본다. | 원본과 정리본의 경계를 배우지 못한 채 자동화 결과를 믿게 된다. | 수동 방식을 품질 기준선으로 삼는다. |
| raw와 wiki를 한 문서에 섞는다. | 원천, 해석, 추정, output의 신뢰 등급이 흐려진다. | raw, wiki, output 역할을 분리한다. |
| 지침 파일 읽힘 여부를 확인하지 않는다. | 에이전트가 실제 작업 기준을 모른 채 파일을 고칠 수 있다. | 현재 지침 요약을 요청하고 원문 규칙과 대조한다. |
/wiki나 @wiki를 모든 환경의 공식 기능으로 설명한다. | 구현체가 없는 환경에서 재현이 안 되고 책임 경계가 흐려진다. | 특정 구현체 README와 설치된 도움말 기준이라고 표시한다. |
| CLI 예제에 실제 API 키나 업무 파일을 바로 넣는다. | 비밀값 유출과 외부 전송 위험이 생긴다. | 더미 자료와 안전한 비밀 관리 방식으로 먼저 검증한다. |
| 데스크톱 그래프를 근거 검증으로 착각한다. | 시각화는 연결을 보여 줄 뿐 문장별 출처를 보장하지 않는다. | 원본 보존, 출처, export, backup을 별도로 확인한다. |
| 첫 선택을 영구 표준으로 고정한다. | 작은 실험에서 배운 한계를 반영하지 못한다. | 선택 메모와 보류 사유를 남기고 3.2에서 다시 평가한다. |
관련 문서
- 3장. 내게 맞는 LLM위키 방식 고르기: 3.1의 시작 방식 비교를 장 전체 선택 절차 안에 배치한다.
- 2.1 지식이 쌓이는 세 층: 시작 방식과 무관하게
raw,wiki, rules의 신뢰 경계를 먼저 이해한다. - 2.2 좋은 폴더 구조 이해하기: 수동 Markdown 기준선의
index.md,log.md,output역할을 구체화한다. - 2.3 좋은 위키 문서의 조건: 어떤 방식으로 시작하든 wiki 문서가 출처, 재사용성, 링크를 갖춰야 한다.
- 3.2 도구를 고를 때 확인할 것: 3.1에서 고른 후보를 설치, 유지보수, 저장 구조, 자료 형식, 권한 기준으로 검증한다.
- 3.3 이 책의 실습 환경 정하기: 선택한 시작 방식을 실제 미니 위키 환경 문서로 고정한다.
- 4.1 업무 주제 정하기: 첫 방식으로 다룰 업무 주제를 작고 검증 가능하게 줄인다.
- 5.1 자료를 넣기 전에 정할 기준: 실제 raw 자료를 넣기 전 포함, 제외, 민감 정보 기준을 세운다.
- 6.2 답변의 근거 확인하기: 에이전트나 도구가 만든 답변을 문장 단위 근거 라벨로 검증한다.
- 8.2 정리와 감사 흐름 만들기: 출처, 최신성, 중복, 링크를 주기적으로 감사한다.
한계와 확인 필요
- 이 문서는 2026-06-06 KST에 WikiDocs 원문을 직접 열람해 작성한 Markdown 분석을 HTML로 변환한 것이다.
- OpenAI Codex의
AGENTS.md, Claude Code의CLAUDE.md, 여러 LLM위키 구현체의 현재 동작은 이 페이지에서 별도 최신 검증하지 않았다. - 지침 파일은 작업 기준을 전달하는 파일이지 결과 품질이나 보안을 강제하는 장치가 아니다. raw 보존, 근거 표시, 확인 필요, index/log 갱신은 결과물에서 직접 확인해야 한다.
- 플러그인이나 CLI가 로컬 파일을 사용하더라도 URL 수집, 웹 검색, LLM 호출, API 키 사용, telemetry, 외부 저장이 발생할 수 있다.
- 첫 선택은 실험이다. 3.2의 도구 선택 기준과 3.3의 실습 환경 문서로 다시 좁혀야 한다.
이 절의 완료 기준
- 수동 Markdown, 에이전트, CLI, 데스크톱 방식의 차이를 현재 업무 조건으로 설명할 수 있다.
- 첫 선택 이유를 자료 수, 민감도, 현재 도구, 반복성, 검토 방식 중 최소 두 가지와 연결해 한 문장으로 썼다.
- 더미 또는 익명화 자료 하나로 raw 원본, wiki 정리 문서, output 공간, 작업 규칙 파일의 최소 구조를 확인했다.
- raw 원본 보존, 근거 표시, 확인 필요, index 또는 log 갱신 중 최소 네 가지를 샘플 결과에서 확인했다.
- Codex와 Claude Code의 지침 파일 차이를 알고 현재 도구가 실제로 어떤 규칙 파일을 읽는지 확인할 수 있다.
- 플러그인과 CLI 명령은 구현체 문서와 현재 설치된 도움말 기준으로 재확인해야 함을 문서화했다.
- 실제 고객 정보, 계약 정보, 개인정보, 비공개 코드, 내부 정책 원문을 첫 샘플에 넣지 않았다.
- 3.2에서 도구 후보를 설치, 유지보수, 저장 구조, 자료 형식, 출처, 권한, 이동성 기준으로 평가할 준비가 됐다.