원문과 확인 범위
핵심 요지
좋은 질문은 긴 프롬프트가 아니라 현재 위키의 어떤 자료를 기준으로, 어떤 업무 결정을 위해, 어떤 형식의 답변을 받아야 하는지 분명히 하는 요청이다. 6.1은 단순 검색 질문과 업무 질문을 구분하고, 시간 범위, 자료 범위, 판단 기준, 제외 범위, 출력 형식, 검증 조건을 질문 안에 넣는 방법을 다룬다.
6.2는 답변을 그대로 믿지 말라고 한다. 위키 문서는 원본이 아니라 원천 자료를 바탕으로 만든 파생 지식이므로 답변 문장은 원천 근거, 위키 근거, 제한적 확인, 추정, 출처 없음, 최신성 확인 필요 같은 상태로 나누어야 한다. 핵심은 답변 전체를 좋다 또는 나쁘다로 평가하는 것이 아니라, 문장 단위로 어디까지 쓸 수 있는지 판정하는 것이다.
6.3은 검증한 답변을 다시 위키에 반영하는 방법을 다룬다. 좋은 답변 전체를 붙여 넣는 것은 LLM위키 운영이 아니다. 실제로 채택한 결론은 결정 로그로, 새로 확인한 지식은 주제 문서로, 반복될 질문은 템플릿으로, 보류할 내용은 확인 필요로 남겨야 한다. 그리고 index.md와 log.md를 갱신해야 다음 질문이 더 짧고 정확해진다.
원문 구조
| 원문 | 역할 | 핵심 내용 | 다음 단계 산출물 |
|---|---|---|---|
| 6장 랜딩 | 질문/검증 장의 입구 | 6.1, 6.2, 6.3으로 구성됨을 안내한다. | 세 절을 순서대로 읽는 탐색 경로 |
| 6.1 좋은 질문 만들기 | 질문 설계 | 단순 검색 질문과 업무 질문을 구분하고 자료 범위, 목적, 출력 형식을 넣는다. | 업무 질문 템플릿, 질문 경계, 답변 형식 |
| 6.2 답변의 근거 확인하기 | 답변 검증 | 답변 문장별 근거 상태, 확실성, 최신성 필요 여부를 라벨링한다. | 문장별 근거 라벨, 확실성 등급, 확인 필요 목록 |
| 6.3 답변을 다시 위키에 반영하기 | 검증 후 갱신 | 채택한 결정, 새 지식, 반복 질문 템플릿, index/log 갱신을 나눈다. | 결정 로그, 주제 문서 갱신, 템플릿, 반영 이력 |
세 절은 순서가 중요하다. 6.1 없이 질문하면 답변이 넓고 일반적으로 흐른다. 6.2 없이 답변을 쓰면 추정과 사실이 섞인다. 6.3 없이 검증을 끝내면 좋은 답변도 다음 작업의 기준으로 남지 않는다.
장 수준 합성
1. 6장은 질의응답 기술이 아니라 위키 운영의 품질 게이트다
6.1-6.3을 합치면 6장은 질문을 잘 쓰는 법만 다루지 않는다. 이 장은 LLM위키에서 지식이 순환하는 품질 게이트다. 5장에서 자료를 넣고 정리했더라도 질문이 넓으면 LLM은 위키 밖 일반론을 섞을 수 있다. 답변이 그럴듯해도 문장별 근거가 없으면 보고서와 실행 계획의 근거가 약해진다. 검증한 내용을 다시 위키에 반영하지 않으면 다음에도 같은 배경 설명을 반복하게 된다.
- 질문 전에 사용할
wiki/문서와raw/자료를 지정한다. - 보고, 결정, 실행, 검토 중 답변 목적을 정한다.
- 출력 형식과 검증 조건을 먼저 정한다.
- 답변을 문장 단위로 나눈다.
- 근거가 약한 문장은 확인 필요, 제한된 근거, 추정으로 낮춘다.
- 채택한 결정과 새 지식과 반복 질문을 서로 다른 위치에 반영한다.
index.md와log.md를 갱신해 다음 질문의 출발점을 만든다.
2. 좋은 질문은 검색어가 아니라 업무 요청이다
6.1은 질문을 정보 검색과 업무 판단으로 나눈다. 단순 검색 질문은 개념 설명이나 요약을 얻는 데 쓸 수 있지만 업무에서는 보통 그 다음이 필요하다. 사용자는 보고해야 하고, 결정해야 하고, 실행 항목을 만들어야 한다. 따라서 위키 질문은 무엇인가보다 어떤 자료를 기준으로 무엇을 결정할 것인가에 가까워야 한다.
| 구성 요소 | 질문에 넣을 내용 | 실패 신호 |
|---|---|---|
| 자료 범위 | 사용할 wiki/ 문서와 raw/ 자료 | 전체적으로, 알아서처럼 근거 범위가 없다. |
| 시간 범위 | 지난 2주, 2026년 5월 회의록 등 | 오래된 자료와 최신 자료가 같은 무게로 섞인다. |
| 업무 목적 | 회의 결정, 보고서 초안, 실행 계획, 위험 검토 | 답변이 읽을거리로 끝나고 다음 행동이 없다. |
| 판단 기준 | 반복 빈도, 고객 영향, 실행 난이도, 비용 등 | 무엇이 중요한지 LLM이 임의로 정한다. |
| 출력 형식 | 표, 목록, 1페이지 보고서, 실행 계획 | 결과를 다시 업무 문서로 옮기기 어렵다. |
| 검증 조건 | 근거 표시, 확인 필요 분리, 출처 없는 단정 금지 | 추정과 사실이 한 문단에 섞인다. |
3. 답변 검증은 문장 단위로 해야 한다
한 답변 안에는 원천 자료에서 직접 확인되는 문장, 위키 문서의 해석에 기대는 문장, LLM이 문맥상 보충한 문장, 최신성 때문에 다시 확인해야 하는 문장이 함께 있을 수 있다. 그래서 답변 전체에 합격 또는 불합격을 붙이는 대신 문장별로 업무 사용 가능 상태를 표시해야 한다.
| 라벨 | 의미 | 보고서나 결정에 쓸 때 |
|---|---|---|
| 원천 근거 | raw/ 자료, 회의록 날짜, 공식 URL, 문서명으로 직접 확인 가능 | 조건과 확인일을 붙여 사용할 수 있다. |
| 위키 근거 | wiki/ 문서에는 있으나 원천 연결이 약함 | 현재 위키 기준으로 제한한다. |
| 제한적 확인 | 일부 자료에는 근거가 있지만 표본, 기간, 범위가 좁음 | 조건부 표현으로 낮추고 추가 자료를 요청한다. |
| 추정 | 효과, 우선순위, 원인, 미래 결과를 예상함 | 실험 가설이나 확인 필요로 둔다. |
| 출처 없음 | 답변에는 있으나 근거 위치가 없음 | 단정문과 결정 근거로 쓰지 않는다. |
| 최신성 확인 필요 | 도구, 버전, 가격, 정책, 보안, 성능처럼 변할 수 있음 | 확인 날짜와 기준 자료를 붙이고 최신 공식 자료를 재확인한다. |
4. 확실성 등급은 표현을 바꾸는 도구다
확실성 등급의 목적은 라벨을 붙이는 데서 끝나지 않는다. 보고서 문장이 바뀌어야 한다. 예를 들어 자동화하면 응답 시간이 줄어든다는 문장은 강한 단정이다. 위키에 반복 문의 회의록은 있지만 응답 시간 통계가 없다면 자동화 후보로 검토할 수 있으나 정량 효과는 확인 필요로 낮춰야 한다.
| 답변 문장 상태 | 위험한 표현 | 검토용 표현 | 필요한 다음 자료 |
|---|---|---|---|
| 원천에 직접 있음 | 무조건 일반화 | 해당 자료와 기간 기준으로 확인됨 | 다른 기간에도 같은지 확인 |
| 소수 회의록만 있음 | 전체 업무 기준으로 단정 | 회의록 기준으로 제한적 확인 | 추가 회의록, 통계, 담당자 검토 |
| 효과를 예상함 | 효과가 있다 | 효과 가능성이 있으나 측정 필요 | 기준 지표, 전후 비교, 실험 계획 |
| 도구 기능을 말함 | 현재도 동작한다 | 확인일과 기준 문서 기준으로 설명 | 현재 README, 릴리스, 설치 도움말 |
| 출처가 없음 | 사실처럼 서술 | 확인 필요 또는 삭제 | 원천 자료 요청 |
5. 검증 후 반영은 세 갈래로 나눈다
답변은 길고 친절할 수 있지만 위키에 필요한 것은 구조화된 결정과 재사용 가능한 지식과 반복 가능한 질문이다. 채택한 결론은 결정 로그로, 새로 확인한 지식은 관련 주제 문서로, 반복될 질문은 템플릿으로, 근거 약한 제안은 확인 필요 목록으로 보내야 한다.
| 답변에서 나온 것 | 보낼 위치 | 남길 내용 |
|---|---|---|
| 실제로 채택한 결론 | wiki/decisions.md 또는 결정 로그 | 결정, 이유, 근거, 확인 날짜, 남은 의문, 다음 행동 |
| 새로 확인한 지식 | 관련 wiki/ 주제 문서 | 한 문장 요약, 확인된 내용, 근거, 확인 필요, 다시 물어볼 질문 |
| 반복될 질문 | templates/ 또는 질문 템플릿 문서 | 작업 목적, 입력 자료, 참고 문서, 출력 형식, 검증 기준 |
| 근거 약한 제안 | 확인 필요 목록, 다음 자료 목록 | 왜 약한지, 어떤 원천이 필요한지 |
| 단순 대화 흐름 | 보존하지 않거나 원천 대화로만 둠 | 필요한 경우 원천 경로만 남김 |
6. index와 log 갱신은 루프의 종료 조건이다
index.md는 다음 사용자가 어디서 시작해야 하는지 알려 주고, log.md는 왜 이런 결정과 문서가 생겼는지 설명한다. 둘 다 없으면 위키는 문서 수만 늘고 탐색성과 감사 가능성은 떨어진다. 6장의 완료 조건은 답변을 잘 받은 것이 아니라 다음 질문이 더 쉬워졌는지다.
실무 적용 절차
- 질문하려는 업무 목적을 먼저 적는다. 보고, 결정, 실행, 검토 중 무엇을 위한 답인지 정한다.
- 사용할 자료 범위를 고른다.
wiki/문서,raw/자료, 기간, 제외할 자료를 명시한다. - 판단 기준을 2-4개로 제한한다. 반복 빈도, 고객 영향, 실행 난이도, 보안 위험처럼 답변 선택 기준을 미리 준다.
- 출력 형식을 먼저 정한다. 표, 보고서 초안, 실행 계획, 확인 필요 목록 중 하나를 고른다.
- 질문 끝에 검증 조건을 넣는다. 근거 위치, 확인 필요, 추정, 최신성 확인 필요를 분리해 달라고 요청한다.
- 답변을 받은 뒤 결론부터 복사하지 않는다. 핵심 문장을 한 줄씩 분리한다.
- 각 문장에 원천 근거, 위키 근거, 제한적 확인, 추정, 출처 없음, 최신성 확인 필요 라벨을 붙인다.
- 원천 근거가 있는 문장은 실제
raw/자료나 원문 URL로 돌아가 날짜와 범위를 확인한다. - 위키 근거만 있는 문장은 원천 연결이 필요한지 확인하고, 연결이 약하면 제한 표현으로 낮춘다.
- 추정 문장은 실험 가설이나 다음 확인 질문으로 바꾼다.
- 출처 없는 문장은 결정 로그나 보고서 단정문에 넣지 않는다.
- 최신성이 필요한 문장은 확인일, 기준 자료, 재확인 대상 문서를 남긴다.
- 채택한 결론만 결정 로그에 기록한다. 결정, 이유, 근거, 확인 날짜, 남은 의문, 다음 행동을 포함한다.
- 새로 확인한 지식은 관련
wiki/문서에 반영한다. 원본을 덮어쓰지 않고 근거와 확인 필요를 남긴다. - 반복될 질문은 템플릿으로 만든다. 입력 자료, 참고 문서, 출력 형식, 검증 기준을 포함한다.
index.md에 새 문서와 템플릿을 연결하고,log.md에 반영 이력을 남긴다.- 다음 질문을 다시 작성해 본다. 이전보다 짧고 근거 범위가 분명해졌다면 6장 루프가 작동한 것이다.
예시 체크리스트
업무 질문 설계표
| 항목 | 작성 예시 | 통과 기준 |
|---|---|---|
| 업무 목적 | 다음 주 회의에서 실험 승인 여부를 결정한다. | 답변을 읽은 사람이 무엇을 해야 하는지 보인다. |
| 자료 범위 | wiki/customer-inquiry-labeling.md, raw/meeting-notes/2026-05-*.md | 근거 없는 일반론을 줄인다. |
| 시간 범위 | 2026년 5월 첫째 주와 둘째 주 회의록 | 오래된 자료와 최신 자료가 섞이지 않는다. |
| 판단 기준 | 반복 빈도, 고객 영향, 실행 난이도 | 우선순위 기준을 LLM에게 맡기지 않는다. |
| 출력 형식 | 후보, 근거, 기대 효과, 난이도, 확인 필요 표 | 검토자가 빈칸과 근거 부족을 볼 수 있다. |
| 검증 조건 | 자료에서 확인되지 않은 내용은 확인 필요로 표시 | 추정이 사실처럼 섞이지 않는다. |
답변 문장 검증표
| 문장 번호 | 문장 요약 | 라벨 | 처리 | 다음 행동 |
|---|---|---|---|---|
| 1 | 반복 문의가 많다 | 제한적 확인 | 회의록 기준으로만 표현 | 문의량 통계 확인 |
| 2 | 특정 문의 유형이 회의에서 언급됐다 | 원천 근거 | 회의록 날짜와 함께 사용 | 원천 링크 유지 |
| 3 | 자동화하면 응답 시간이 줄어든다 | 추정 또는 출처 없음 | 단정 금지 | 처리 시간, 실험 지표 수집 |
| 4 | 최근 3개월 통계가 없다 | 위키 상태 확인 | 현재 위키 범위로 제한 | raw 자료 보강 여부 결정 |
| 5 | 먼저 건수를 확인하자 | 실행 제안 | 다음 행동 후보로 사용 | 담당자와 기한 지정 |
6장 완료 산출물
| 산출물 | 작성 내용 | 합격 기준 |
|---|---|---|
| 업무 질문 템플릿 | 자료 범위, 목적, 판단 기준, 출력 형식, 검증 조건 | 질문이 단순 요약 요청에 머물지 않는다. |
| 답변 근거 라벨표 | 문장별 원천 근거, 위키 근거, 추정, 출처 없음, 최신성 확인 필요 | 검토자가 믿을 문장과 다시 확인할 문장을 구분할 수 있다. |
| 확실성/최신성 목록 | 확인됨, 제한적 확인, 추정, 확인 필요, 최신성 확인 필요 | 도구, 정책, 성능 주장이 확인일 없이 단정되지 않는다. |
| 결정 로그 | 채택한 결론, 이유, 근거, 확인 날짜, 남은 의문, 다음 행동 | 결정과 단순 답변이 분리된다. |
| 새 지식 반영 문서 | 확인된 내용, 근거, 확인 필요, 다시 물어볼 질문 | 원본과 파생 지식이 섞이지 않는다. |
| 반복 질문 템플릿 | 입력 자료와 참고 문서와 검증 기준이 있는 재사용 질문 | 다음 질문이 짧아지고 결과 형식이 안정된다. |
| index/log 갱신 | 새 문서와 템플릿 링크, 반영 이력 | 나중에 왜 바뀌었는지 추적할 수 있다. |
검증 질문
- 질문이 검색어 나열이나 요약 요청에 머물지 않는가?
- 질문에 사용할
wiki/문서와raw/자료가 명시되어 있는가? - 시간 범위, 판단 기준, 제외 범위가 필요한 경우 빠지지 않았는가?
- 답변 형식이 다음 업무 산출물에 바로 쓸 수 있는가?
- 질문 안에 근거 부족, 확인 필요, 추정 표시 요구가 있는가?
- 답변을 문장 단위로 나누었는가?
- 핵심 문장마다 원천 근거, 위키 근거, 제한적 확인, 추정, 출처 없음, 최신성 확인 필요 중 하나를 붙였는가?
- 출처가 있는 문장도 현재 업무 결정에 충분한 범위와 날짜를 갖는지 확인했는가?
- 최신성이 필요한 도구, 정책, 보안, 가격, 버전, 성능 주장을 확인일 없이 단정하지 않았는가?
- 추정 문장을 보고서나 결정 로그의 단정문으로 올리지 않았는가?
- 채택한 결정과 단순 답변과 제안을 분리했는가?
- 새로 확인한 지식이 관련
wiki/문서에 근거와 확인 필요와 함께 반영되었는가? - 반복될 질문이 템플릿으로 남았는가?
index.md에서 새 문서와 템플릿을 찾을 수 있는가?log.md에 언제 어떤 답변을 검증했고 무엇을 반영했는지 남았는가?- 다음 질문이 이전보다 짧고 근거 범위가 분명해졌는가?
관련 문서 연결
- 통합 루트: 책 전체를
raw-wiki-question-evidence-output-audit흐름으로 통합한 안내 문서다. - 5장. 자료를 넣고 다시 쓰기 좋은 지식으로 바꾸기: 6장에서 질문하고 검증할 수 있도록 자료를 원천 카드와 주제 문서로 정리한다.
- 5.3 위키 문서로 정리하기: 질문 기준으로 문서를 나누고 중복과 모순을 처리한다.
- 6.1 좋은 질문 만들기: 단순 검색 질문을 업무 질문으로 바꾸고 질문 경계를 넣는다.
- 6.2 답변의 근거 확인하기: 답변 문장별 근거 라벨과 확실성, 최신성 확인 기준을 다룬다.
- 6.3 답변을 다시 위키에 반영하기: 검증된 답변을 결정 로그, 주제 문서, 템플릿, index/log에 나누어 반영한다.
- 7장. 위키에서 업무 산출물 만들기: 6장에서 검증한 답변을 요약, 보고서, 실행 계획으로 바꾼다.
- 7.2 업무 보고서 만들기: 검증된 문장을 주장-근거 매트릭스로 옮긴다.
- 8장. 오래 믿고 쓰는 LLM위키 운영법: 6장의 근거 라벨과 최신성 표시를 장기 감사 루틴으로 확장한다.
- 8.1 위키에도 점검이 필요한 이유: 그럴듯한 요약, 출처 누락, 오래된 주장 위험을 다시 점검한다.
누락 또는 주의사항
- 장 랜딩 원문은 세 하위 절 목록 중심의 짧은 페이지다. 이 페이지는 장 랜딩만이 아니라 6.1-6.3 세부 원문을 함께 반영해 장 수준으로 재구성했다.
- 원문에는 여러 실습용 명령, 예시 파일, 표, 프롬프트 구조가 포함되어 있다. 이 장 개요는 명령과 예시 문장을 장문 복제하지 않고 실무 절차와 판단 기준과 체크리스트로 재구성했다.
AGENTS.md,CLAUDE.md, 플러그인, 구현체 호출 방식, 릴리스, 설치 명령은 원문 확인일 기준의 참고 자료다. 실제 도입 전에는 현재 공식 문서, 설치된 도움말, 조직 보안 기준, 외부 전송 경로를 다시 확인해야 한다.- WiCER는 원문에서 제한된 근거로 언급된 arXiv 프리프린트다. 무검증 컴파일의 위험을 설명하는 참고로만 사용하고 조직 운영 정책이나 제품 기능의 확정 근거로 단정하지 않는다.
- 근거 라벨은 형식주의가 아니다. 라벨이 너무 복잡해 실제 질문과 검증을 방해하면 확인됨, 제한적 확인, 추정, 확인 필요, 최신성 확인 필요 정도로 줄여 운영한다.
- LLM 답변은 원본이 아니다. 답변에서 확인한 내용은 관련 원천과 확인일을 붙여
wiki/에 반영하고, 원천 자료는raw/에서 보존해야 한다. - 민감 정보, 고객 개인정보, 계약 조건, 내부 정책, 비공개 코드는 질문과 답변과 반영 단계 모두에서 별도 기준이 필요하다. 출처를 남긴다는 이유로 민감 원문을 그대로 외부 LLM이나 공개 위키에 넣어서는 안 된다.