Source path: data/runtime/write-agents/LLM wiki reference analyses/md/wikidocs/pages/03-02-tool-selection.md
HTML counterpart: data/runtime/write-agents/LLM wiki reference analyses/html/wikidocs/pages/03-02-tool-selection.html
3.2 도구를 고를 때 확인할 것 원문 기반 심화 분석
원문 메타
- 원문 URL: 3.2 도구를 고를 때 확인할 것
- 원천 도서: LLM위키 완벽 가이드
- 상위 문서: 3장. 내게 맞는 LLM위키 방식 고르기
- 확인일: 2026-06-06 KST
- 원문 기준 마지막 편집일시: 2026년 5월 16일 1:06 오후
- 내비게이션: 이전: 3.1 시작 방식 비교하기 · 상위: 3장 · 다음: 3.3 실습 환경
핵심 요약
3.2의 핵심은 LLM위키 도구를 기능 목록으로 고르지 말고, 이번 주에 작은 자료 하나를 넣어 보고 다음 업무에서 다시 믿고 쓸 수 있는지로 판단하라는 것이다. 도구 선택의 첫 기준은 많은 기능이 아니라 지속 관리 가능성이다.
LLM위키는 단일 표준 제품보다 지식 관리 패턴에 가깝다. 구현체마다 설치법, 저장 위치, 지원 자료 형식, 명령 이름, 지침 파일, 권한 모델이 다르므로 특정 명령이나 플러그인을 모든 환경의 기본 기능처럼 단정하면 안 된다.
첫 도구의 최소 조건은 세 가지다. 원천 자료와 정리된 wiki 문서를 분리해 저장할 수 있어야 하고, 생성된 문서를 사람이 직접 열어 고칠 수 있어야 하며, 공식 문서와 변경 이력을 확인할 수 있어야 한다.
자료 형식 지원은 단순 업로드 가능 여부가 아니다. Markdown, 웹 문서, PDF, 코드 작업 기록, 이미지 등을 다루더라도 원천 위치, 확인일, 수집 이유, 변경 이력이 남아야 답변 검증과 감사가 가능하다.
원문 구조와 실무 의미
| 원문 절 | 핵심 내용 | 실무 의미 |
|---|---|---|
| 도입부 | 기능 목록보다 작은 자료 하나를 넣고 위키 문서 하나를 만든 뒤 다음 작업에서 다시 쓸 수 있는지가 중요하다. | 도구 선택은 기능 비교가 아니라 운영 가능성 검증이다. |
| 설치 난이도와 유지보수 부담 | 플러그인, API 키, Python/Node.js 버전, 업그레이드 변경을 확인한다. | 설치 성공보다 지속 운영 비용과 실패 복구 가능성을 먼저 본다. |
| 첫 도구의 최소 조건 | 원천과 위키 분리, 사람이 고칠 수 있는 문서, 공식 문서와 변경 이력. | 좋은 도구의 합격선을 기능 수가 아니라 신뢰 경계와 수정 가능성으로 둔다. |
| 30분 검증용 위키 만들기 | raw, wiki, output 분리와 읽을 수 있는 Markdown 파일 생성을 확인한다. | 도구 기능 검증 전 최소 구조의 기대 결과를 눈으로 확인한다. |
| 자료 형식과 지원 범위 | Markdown, 웹, PDF, 회의록, 코드 기록, 이미지가 섞일 수 있다. | 자료 지원은 가져오기보다 출처와 검증 가능성까지 포함한다. |
| 도구별 지원 범위 읽기 | 구현체별 목표와 사용 장면이 다르다. | 구현체 차이는 우열이 아니라 업무 맥락 차이다. |
| 버전 변화와 문서 확인 방법 | README, Releases, 설치 전제, 저장 위치, 도움말, 샘플 실행을 순서대로 확인한다. | 오래된 명령과 현재 도구 동작을 분리한다. |
| Codex와 Claude Code 문서를 나눠 보기 | Codex는 AGENTS.md, Claude Code는 CLAUDE.md 기준으로 확인한다. | 지침 파일명과 로드 방식은 도구별 공식 문서 기준으로 판단한다. |
상세 분석
1. 도구 선택의 질문은 기능 수가 아니다
많은 형식, 그래프, 자동 수집, 플러그인 명령이 있어도 이번 주에 실제 자료 하나를 넣고, 위키 문서 하나를 만들고, 다음 작업에서 믿고 다시 쓸 수 없다면 첫 도구로는 위험하다. 약한 질문은 이 도구가 기능이 많은가이고, 3.2 기준의 질문은 30분 안에 샘플 자료 하나로 raw와 wiki를 분리할 수 있는가이다.
| 약한 질문 | 3.2 기준의 질문 | 판단 이유 |
|---|---|---|
| 기능이 많은가? | 30분 안에 샘플 자료 하나로 raw와 wiki를 분리할 수 있는가? | 첫 실패 비용을 낮춘다. |
| PDF, 웹, 이미지까지 다 되는가? | 내 첫 업무 자료 3-5개를 출처와 확인일이 남는 방식으로 처리하는가? | 지원 형식보다 검증 가능성이 중요하다. |
| 유명한 플러그인인가? | README, Releases, 권한, 저장 위치, 도움말을 확인할 수 있는가? | 버전 변화와 권한 위험을 줄인다. |
| 자동화가 강한가? | 사람이 생성된 위키 문서를 열어 고칠 수 있는가? | LLM 오류를 운영 지식으로 굳히지 않는다. |
2. 설치보다 유지보수 부담이 오래 간다
LLM위키는 파일 시스템, LLM 호출, 웹 접근, 플러그인 권한, API 키, 런타임 버전이 함께 움직인다. 설치 후에도 업그레이드, 명령 변경, 저장 위치 변경, 권한 변경, 도움말 차이를 계속 확인해야 한다.
| 방식 | 시작 부담 | 유지보수 부담 | 먼저 확인할 것 |
|---|---|---|---|
| 수동 Markdown | 낮음 | 낮음 | 원본과 위키 문서를 분리할 수 있는가 |
| Codex/Claude Code 기반 에이전트 | 중간 | 중간 | 지침 파일, 플러그인 권한, 저장 위치 |
| CLI 도구 | 중간에서 높음 | 중간에서 높음 | Python/Node.js 버전, API 키, 릴리스 노트 |
| 데스크톱 앱 | 낮음에서 중간 | 낮음에서 중간 | 내보내기, 백업, 원본 보존 |
| 연구·실험 구현체 | 높음 | 높음 | 문서 최신성, 한계, 변경 이력 |
3. 첫 도구의 최소 조건
첫째, 원천 자료와 정리된 위키 문서를 구분해 저장해야 한다. 둘째, 생성된 위키 문서를 사람이 직접 열어 고칠 수 있어야 한다. 셋째, 공식 문서와 변경 이력을 확인할 수 있어야 한다. 이 조건은 2장의 raw, wiki, rules 신뢰 경계와 직접 연결된다.
| 최소 조건 | 통과 기준 | 실패 신호 | 후속 조치 |
|---|---|---|---|
| 원천과 위키 분리 | raw 원본과 wiki 정리본이 별도 위치나 상태로 남는다. | LLM 요약이 원본을 대체하거나 원본 위치가 사라진다. | 수동 Markdown 구조로 되돌려 기준선을 만든다. |
| 사람이 수정 가능 | Markdown, 텍스트, 일반 파일처럼 열고 고칠 수 있다. | 도구 내부 DB에만 있고 export나 수정 방법이 불명확하다. | export, 백업, 편집 가능 여부를 확인한다. |
| 공식 문서와 변경 이력 | README, Releases, Changelog, 설치된 도움말을 볼 수 있다. | 블로그 예제나 오래된 README만 보고 설치한다. | 현재 공식 문서를 먼저 확인한다. |
4. 30분 검증은 기대 구조 확인이다
- 학습용 폴더를 만들고 실제 고객 정보나 내부 기밀과 분리한다.
- 짧은 회의록 샘플을
raw에 둔다. - 회의록에서 실행 항목 자동화 후보를
wiki문서로 만든다. - 파일 목록을 확인하고 원본과 정리본의 내용이 섞였는지 점검한다.
- 같은 구조를 도구 후보로 재현할 수 있는지 본다.
샘플에서도 원본이 덮어써지거나 근거가 사라지거나 저장 위치를 모르겠다면 실제 업무 자료를 넣으면 안 된다.
5. 자료 형식 지원은 출처 회귀 능력까지 포함한다
| 자료 유형 | 필요한 기능 | 낮은 위험의 시작 방식 | 검증 질문 |
|---|---|---|---|
| 짧은 업무 메모 | Markdown 저장, 수동 편집, 확인일 표시 | 수동 Markdown | 메모가 raw로 남고 wiki가 파생 문서로 남는가? |
| 회의록 텍스트 | 결정/논의/실행 항목 분리, 출처 표시 | 수동 Markdown 또는 에이전트 | 회의 날짜와 확인 필요가 남는가? |
| 공개 웹 문서 | URL, 확인 날짜, 발행자, 수집 이유 | 에이전트 또는 CLI | 최신성 확인과 URL 재접근 경로가 있는가? |
| PDF 보고서 | 긴 문서 처리, 페이지 또는 범위 근거, 잘림 표시 | PDF 지원 도구 확인 필요 | 긴 문서가 잘렸는지, 페이지 근거가 남는지 확인했는가? |
| 코드 작업 기록 | 세션 기록 수집, 변경 파일 연결, 결정 로그 | 세션 ingest 지원 확인 필요 | 코드 변경과 대화 요약이 원본처럼 섞이지 않는가? |
| 이미지 캡처 | 멀티모달 해석, 설명 생성, 원본 보존 | 멀티모달 지원 확인 필요 | 이미지 해석이 추정임을 표시하는가? |
6. 구현체 차이는 우열이 아니라 사용 장면 차이다
nvk/llm-wiki는 에이전트 도구의 플러그인 흐름에 가깝고, atomicstrata/llm-wiki-compiler는 CLI 컴파일러 방식에 가깝다. OpenKB는 여러 문서 형식 지원을 설명하지만 LLM API 키와 설정이 필요하고, nashsu/llm_wiki는 데스크톱 앱 방식과 문서 가져오기, 그래프 탐색을 강조한다. 이 비교는 특정 도구 추천이 아니라 운영 장면의 차이를 읽기 위한 것이다.
7. 버전 변화는 선택 기준 자체다
- 도구 후보를 찾는다.
- 공식 저장소 README를 확인한다.
- 최신 Releases 또는 Changelog를 확인한다.
- OS, Python, Node.js, API 키, 호스트 앱 같은 설치 전제를 적는다.
- 기본 위키 폴더, 설정 파일 위치, export와 백업 가능성을 확인한다.
- 웹 접근, 로컬 파일 접근, LLM 호출, 플러그인 권한을 확인한다.
- 설치된 도구의 도움말을 확인한다.
- 작은 샘플로 실행한다.
- 원본과 위키 문서가 분리되면 업무 자료로 확장한다.
- 분리되지 않거나 명령이 다르면 문서와 버전 차이를 다시 확인한다.
8. Codex와 Claude Code의 지침 파일은 같은 것으로 취급하지 않는다
| 도구 | 기준 파일 | 확인 방법 | 주의점 |
|---|---|---|---|
| Codex | AGENTS.md | 프로젝트 루트에서 현재 지침 요약을 요청한다. | 작업 디렉터리, 파일 크기 제한, override 파일 여부를 확인한다. |
| Claude Code | CLAUDE.md | /memory 또는 공식 메모리 확인 흐름을 따른다. | AGENTS.md를 자동으로 읽는다고 단정하지 않는다. |
| 일반 에이전트 도구 | 도구마다 다름 | instruction, memory, rules 항목을 공식 문서에서 확인한다. | 파일명과 우선순위를 추정하지 않는다. |
9. 최종 선택은 하나의 표로 남긴다
| 기준 | 낮은 위험의 답 | 내 후보 점검 |
|---|---|---|
| 설치 | 오늘 30분 안에 샘플을 실행할 수 있다. | |
| 유지보수 | 업그레이드 방법과 릴리스 노트를 찾을 수 있다. | |
| 저장 구조 | 원천 자료와 위키 문서가 분리된다. | |
| 수정 가능성 | 생성된 위키를 사람이 직접 고칠 수 있다. | |
| 자료 형식 | 내 업무 자료의 대부분을 처리할 수 있다. | |
| 출처 | 답변에서 원천 자료로 돌아갈 수 있다. | |
| 권한 | 웹 접근, 파일 접근, API 키 사용 범위를 이해했다. | |
| 이동성 | 나중에 다른 도구로 옮길 수 있는 개방 형식이다. |
실무 적용 절차
- 첫 LLM위키의 실제 업무 자료 3-5개를 적고 자료 유형을 표시한다.
- 자료의 민감도를 표시하고 고객 정보, 계약 정보, 개인정보, 비공개 코드, 내부 정책 원문은 더미 자료로 대체한다.
- 3.1에서 고른 시작 방식 후보를 적는다.
- 각 후보의 설치 전제를 확인한다.
- 공식 README와 Releases 또는 Changelog를 확인하고 확인일을 기록한다.
- raw 원본, wiki 문서, output, 설정 파일, 로그, 캐시, export 위치를 구분한다.
- 권한과 네트워크 호출 범위를 확인한다.
- 더미 회의록 하나로 30분 검증용 샘플을 만든다.
- 샘플 wiki 문서에 한 문장 요약, 근거, 확인 필요가 남는지 확인한다.
- 사람이 직접 파일을 열어 고칠 수 있는지 확인한다.
- 가장 위험한 자료 형식을 더미 자료로 추가 테스트한다.
- Codex는
AGENTS.md, Claude Code는CLAUDE.md기준으로 지침 파일 로드 여부를 확인한다. - 도구 선택표를 채운다.
- 선택 이유와 보류 이유를
log.md에 남긴다. - 3.3의 실습 환경 문서에 선택한 도구, 보류한 도구, 확인 필요, 민감 자료 기준을 반영한다.
실무 템플릿
도구 후보 검토 카드
| 항목 | 작성 내용 | 확인 기준 |
|---|---|---|
| 도구 후보 | 공식 이름과 저장소 또는 배포 위치를 쓴다. | |
| 사용할 방식 | 수동 Markdown / 에이전트 / CLI / 데스크톱 / 플러그인 | 3.1의 시작 방식과 연결한다. |
| 확인일 | README와 Releases를 본 날짜를 남긴다. | |
| 설치 전제 | OS, Python, Node.js, API 키, 호스트 앱을 적는다. | |
| 저장 위치 | raw, wiki, output, 설정, 로그가 어디 남는지 적는다. | |
| 지원 자료 | Markdown, 웹, PDF, 코드 기록, 이미지 중 실제 업무 자료와 맞춘다. | |
| 출처 처리 | URL, raw 경로, 확인일, 변경 이력이 남는지 본다. | |
| 권한 | 웹 접근, 로컬 파일 접근, LLM 호출, 플러그인 권한을 적는다. | |
| 사람이 수정 가능 | 생성 문서를 직접 열어 고칠 수 있는지 확인한다. | |
| 이동성 | Markdown/export/백업 가능 여부를 적는다. | |
| 보류 이유 | 지금 도입하지 않는다면 이유를 남긴다. |
30분 검증 기록표
| 점검 항목 | 통과 기준 | 결과 |
|---|---|---|
| 샘플 생성 | 더미 회의록 또는 공개 자료 하나를 사용했다. | |
| raw 보존 | 원본이 raw 역할 위치에 남았다. | |
| wiki 생성 | 정리 문서가 별도로 생겼다. | |
| 근거 표시 | wiki 문서에 raw 경로 또는 URL과 확인일이 있다. | |
| 확인 필요 | 원천에서 확정할 수 없는 내용이 분리되어 있다. | |
| output 연결 | 산출물이 생긴 경우 wiki/raw 근거로 돌아갈 수 있다. | |
| 직접 수정 | 사람이 wiki 문서를 열어 고칠 수 있다. | |
| log 후보 | 검증 결과를 log.md에 남길 수 있다. |
지침 파일 검증 프롬프트
현재 프로젝트에서 읽은 작업 지침을 요약해 주세요.
특히 raw 원본 보존, wiki 문서의 근거 표시, 확인 필요 표시, log 갱신, 민감 정보 제한 규칙이 있는지 나누어 말해 주세요.
지침 파일을 읽지 못했거나 규칙이 없으면 없다고 말해 주세요.검증 체크리스트
설치와 유지보수
- 오늘 30분 안에 공개 또는 더미 샘플로 실행할 수 있다.
- 설치 전제인 OS, 런타임, API 키, 호스트 앱을 설명할 수 있다.
- 공식 README를 확인했다.
- Releases 또는 Changelog를 확인했다.
- 설치된 도구의 도움말을 확인했다.
- 책, 블로그, 예전 예제 명령을 현재 동작처럼 단정하지 않았다.
저장 구조와 수정 가능성
- 원천 자료와 정리된 wiki 문서가 분리된다.
raw원본을 요약문으로 덮어쓰지 않는다.- 생성된 위키 문서를 사람이 직접 열어 고칠 수 있다.
- output 산출물이 raw와 wiki 근거로 돌아갈 수 있다.
- export, 백업, 삭제 방법을 확인했다.
자료 형식
- 내 첫 업무 자료의 대부분이 어떤 형식인지 적었다.
- 웹 URL을 수집할 때 URL, 확인일, 수집 이유가 남는다.
- PDF나 긴 문서는 크기 제한, 잘림 표시, 페이지 또는 범위 근거를 확인했다.
- 코드 작업 기록은 세션 원문과 정리 문서가 섞이지 않는다.
- 이미지나 캡처 해석은 추정과 확인 필요를 분리한다.
권한과 보안
- 웹 접근이 언제 발생하는지 설명할 수 있다.
- 로컬 파일 접근 범위와 저장 위치를 확인했다.
- LLM API 호출과 제공자 인증 정보 사용 범위를 확인했다.
- 플러그인이나 데스크톱 앱의 외부 서비스 호출 여부를 확인했다.
- 민감 자료를 첫 샘플에 넣지 않았다.
좋은 질문과 검증 질문
- 이 도구 후보를 LLM위키 첫 도구로 써도 되는지 설치 전제, 저장 구조, raw/wiki 분리, 사람이 수정 가능성, 공식 문서, Releases, 권한, 이동성 기준으로 점검해 달라고 요청한다.
- README 요약과 Releases 정보를 기준으로 현재 실습에 쓸 수 있는 명령만 뽑고, 확인되지 않는 명령은 확인 필요로 표시하게 한다.
- 샘플 결과가 raw 원본 보존, wiki 근거, 확인 필요, 직접 수정 가능성, log 기록 가능성을 만족하는지 평가하게 한다.
- 업무 자료 목록을 보고 Markdown, 웹, PDF, 코드 작업 기록, 이미지별 더미 테스트 필요 여부를 판단하게 한다.
흔한 실패와 수정 방향
| 실패 사례 | 왜 문제인가 | 수정 방향 |
|---|---|---|
| 기능이 가장 많은 도구를 첫 도구로 고른다. | 설치와 유지보수 부담 때문에 첫 샘플도 끝내지 못할 수 있다. | 30분 샘플과 최소 조건으로 다시 평가한다. |
| raw와 wiki가 섞이는 도구를 그대로 쓴다. | 근거 확인과 감사가 어렵다. | 원천과 정리본을 분리할 수 있는 구조나 수동 Markdown으로 시작한다. |
| 생성 문서를 사람이 고칠 수 없다. | LLM 오류와 누락을 바로잡기 어렵다. | Markdown, export, 직접 편집 가능 여부를 확인한다. |
| README만 보고 최신 동작을 단정한다. | Releases에서 명령, 저장 위치, 기본 맥락이 바뀌었을 수 있다. | README, Releases, 설치된 도움말, 샘플 실행을 순서대로 확인한다. |
| PDF 지원이라는 문구만 믿는다. | 긴 문서 잘림, 페이지 근거 누락, 표 추출 오류가 생길 수 있다. | 공개 PDF 샘플로 잘림 표시와 페이지 근거를 테스트한다. |
AGENTS.md와 CLAUDE.md를 동일하게 본다. | 도구가 지침 파일을 읽지 못해 raw 보호 규칙이 적용되지 않을 수 있다. | 도구별 공식 문서와 로드 확인 절차를 따른다. |
| 권한 확인 전에 실제 고객 자료를 넣는다. | 외부 호출, 로컬 저장, 플러그인 접근으로 보안 사고가 날 수 있다. | 더미 자료로 먼저 검증하고 조직 기준을 확인한다. |
관련 문서
- 3장. 내게 맞는 LLM위키 방식 고르기
- 3.1 시작 방식 비교하기
- 3.3 이 책의 실습 환경 정하기
- 2.1 지식이 쌓이는 세 층
- 2.2 좋은 폴더 구조 이해하기
- 2.3 좋은 위키 문서의 조건
- 5.1 자료를 넣기 전에 정할 기준
- 5.2 자료 수집하기
- 6.2 답변의 근거 확인하기
- 8.2 정리와 감사 흐름 만들기
한계와 확인 필요
- 이 문서는 2026-06-06 KST에 WikiDocs 원문을 직접 열람해 작성된 Markdown 분석을 HTML로 변환한 것이다.
- 원문이 언급한 외부 구현체와 공식 문서는 원문 확인일인 2026-05-16 기준이므로 실제 도입 전 현재 README, Releases, Changelog, 설치된 도움말을 다시 확인해야 한다.
- 도구가 Markdown, PDF, 웹 URL, 이미지, 코드 기록을 지원한다고 해도 결과가 곧 검증된 지식은 아니다. 출처, 확인일, 잘림 여부, 추정 표시, 사람 검토가 남아야 한다.
- 도구 선택은 한 번의 영구 결정이 아니다. 업무 자료 형식, 팀 권한, 반복 작업량, 도구 릴리스가 바뀌면 선택표와
log.md를 갱신해야 한다.
이 절의 완료 기준
- 첫 도구 후보의 설치 전제와 유지보수 부담을 설명할 수 있다.
- 원천 자료와 위키 문서가 어디에 저장되는지 확인했다.
- 생성된 wiki 문서를 사람이 직접 열어 고칠 수 있는지 확인했다.
- 내 업무 자료 형식이 도구 지원 범위에 들어가는지 작은 샘플로 확인했다.
- 공식 README, Releases 또는 Changelog, 설치된 도움말을 확인했다.
- 오래된 블로그나 예제 명령을 현재 동작으로 단정하지 않았다.
- Codex와 Claude Code의 지침 파일 차이를 구분하고 로드 여부를 확인할 수 있다.
- 민감 자료를 넣기 전에 권한과 네트워크 호출 범위를 확인했다.
- 도구 선택표에 선택 이유와 보류 이유를 남겼다.
- 3.3의 실습 환경 문서로 넘어갈 준비가 되어 있다.