핵심 요약
6.2의 핵심은 LLM위키 답변을 그대로 믿지 말고 문장 단위로 근거, 확실성, 최신성을 검토하라는 것이다. LLM위키의 wiki 문서는 원본이 아니라 raw 원천 자료를 바탕으로 만든 파생 지식이다. 따라서 답변이 빨리 나왔는지가 아니라 무엇을 근거로 했는지, 어디까지 확실한지, 지금도 유효한지를 확인해야 한다.
답변 문장은 같은 답변 안에서도 신뢰 수준이 다르다. 원천 자료 경로, URL, 회의록 날짜, 공식 문서명이 붙은 문장은 상대적으로 강하지만, wiki에만 있고 raw 연결이 약한 문장은 위키 정리 기준으로 제한해야 한다. 출처 없는 문장과 예상 효과 문장은 보고서 단정문으로 쓰지 않고 확인 필요 또는 추정으로 낮춘다.
출처가 있다는 사실만으로 업무 결정에 충분한 것은 아니다. 회의록에 반복 문의가 언급되어도 실제 문의량 증가율이나 자동화 효과는 별도 통계가 필요할 수 있다. 원문은 답변을 확인됨, 제한적 확인, 추정, 확인 필요 정도로 나누면 충분하다고 설명한다.
최신성이 필요한 주장은 별도 표시가 필요하다. 설치 명령, 플러그인 기능, 릴리스 번호, 가격, API 동작, 보안·권한 정책, 성능 개선 효과는 시간이 지나면 바뀌거나 환경에 따라 달라진다. 이런 문장에는 확인 날짜, 기준 자료, 기준 버전 또는 공식 문서 재확인 항목이 붙어야 한다.
원문 구조
| 원문 절 | 핵심 내용 | 실무 의미 |
|---|---|---|
| 도입부 | LLM위키 답변을 업무에 쓰기 전 근거, 확실성, 최신성을 확인해야 한다. | 답변은 최종 결론이 아니라 검토 대상이다. |
| 출처가 있는 답과 없는 답 구분하기 | 원천 자료 근거, wiki 근거, 출처 없음, 추정 답을 나눈다. | 답변 전체가 아니라 문장별 근거 깊이를 본다. |
| 답변에 근거 라벨 붙이기 실습 | 고객 문의 자동화 예시 답변을 문장별로 라벨링한다. | 효과 주장처럼 그럴듯하지만 근거 없는 문장을 찾아낸다. |
| 출처 요청 프롬프트 | 결론, 근거, 출처 있는 문장, 출처 없는 문장, 확인 필요, 다음 질문을 요구한다. | 처음부터 검토 가능한 형식으로 답변을 받는다. |
| 확실한 내용과 추정 구분하기 | 원천에 직접 있는 내용과 해석 또는 예상 결과를 분리한다. | 출처가 있어도 업무 결정에는 근거 범위 확인이 필요하다. |
| 확실성 등급 붙이기 | 확인됨, 제한적 확인, 추정, 확인 필요로 문장을 나눈다. | 단정 강도를 문장별로 조절한다. |
| 최신성이 필요한 주장 표시하기 | 도구 명령, 플러그인 기능, 릴리스, 정책, 성능 효과 같은 변동성 높은 주장을 표시한다. | 실행 실패와 보안 사고를 줄인다. |
| 6.2의 검증 포인트 | 출처, 출처 없음 표시, 추정 분리, 최신성 표시, 업무 결정 가능성을 점검한다. | 6.3 반영 전에 통과해야 할 게이트다. |
상세 분석
1. 6.2는 LLM위키 답변의 lint 단계다
6.1에서 좋은 질문을 만들었다고 해도 답변이 곧바로 업무 지식이 되는 것은 아니다. 6.2는 질문 이후의 검토 단계를 다룬다. 답변이 어떤 원천에 기대는지, 추정이 어디에 섞였는지, 시간이 지나도 맞는지 확인해야 한다.
| 검토 질문 | 답해야 하는 이유 | 실패하면 생기는 문제 |
|---|---|---|
| 이 문장의 출처는 무엇인가? | raw, URL, 회의록, 공식 문서로 돌아가야 검증할 수 있다. | 위키에 있으니 사실이라는 착각이 생긴다. |
| 이 문장은 확인된 내용인가, 추정인가? | 같은 원천을 보고도 해석과 예상은 별도 검증이 필요하다. | 효과, 우선순위, 일정이 확정처럼 보인다. |
| 이 문장은 지금도 유효한가? | 도구 명령, 정책, 가격, API 동작, 보안 기준은 바뀔 수 있다. | 오래된 정보가 실행 실패나 보안 위험으로 이어진다. |
2. 근거 상태는 문장마다 다르다
LLM위키 답변 안에는 여러 종류의 문장이 섞인다. 어떤 문장은 원천 자료 경로와 회의 날짜를 갖고, 어떤 문장은 wiki 문서에는 있지만 원본 연결이 약하며, 어떤 문장은 LLM이 문맥상 보충한 내용이다.
| 라벨 | 판단 기준 | 업무 문서에서의 표현 | 처리 |
|---|---|---|---|
| 원천 근거 있음 | raw 경로, URL, 회의록 날짜, 공식 문서명이 있다. | 확인일과 근거 범위를 붙여 비교적 단정 가능 | 보고서 후보로 사용하되 원천 범위를 함께 쓴다. |
| wiki 근거만 있음 | wiki/ 문서에는 있지만 raw 연결이 약하다. | 현재 위키 정리 기준으로 제한 | 원천 보강 또는 확인 필요를 남긴다. |
| 출처 없음 | 답변에는 있으나 근거 파일이나 링크가 없다. | 단정 금지 | 삭제, 보류, 확인 필요, 다음 수집 후보 중 하나로 처리한다. |
| 추정 | 가능성, 예상 효과, 보통의 경향처럼 해석이 섞인다. | 추정 또는 가설로 표시 | 실험 계획이나 추가 질문으로 전환한다. |
| 위키 상태 확인 | 현재 위키에 자료가 없음 같은 범위 진술 | 현재 위키 범위 안에서만 유효 | 빠진 자료 목록으로 바꾼다. |
| 실행 제안 | 앞의 근거와 한계를 바탕으로 제안하는 행동 | 조건부 제안으로 표현 | 담당자, 기한, 완료 기준은 7.3에서 보강한다. |
고객 문의 자동화 예시로 보면 특정 회의에서 반복 문의 유형이 언급되었다는 문장은 날짜 근거가 있어 강하지만, 자동 분류를 도입하면 응답 시간이 크게 줄어든다는 문장은 정량 자료가 없으면 출처 없는 효과 주장이다.
3. 처음부터 출처가 보이는 답변 형식을 요청한다
LLM위키에 질문할 때 결론만 받지 말고 결론의 근거, 출처 있는 문장, 출처 없는 문장, 확인 필요, 다음 확인 질문을 함께 요구해야 한다. 목적은 답을 길게 만드는 것이 아니라 받은 즉시 라벨링과 반영 절차로 이어갈 수 있게 하는 것이다.
| 답변 형식 요소 | 필요한 이유 | 후속 연결 |
|---|---|---|
| 결론 | 사용자가 빠르게 방향을 본다. | 7장 output 후보가 된다. |
| 결론의 근거 | 결론이 어떤 자료에서 나왔는지 본다. | 6.2 근거 검증으로 이어진다. |
| 근거가 있는 문장과 출처 | 보고서에 쓸 수 있는 문장 후보를 찾는다. | 7.2 주장-근거 매트릭스 입력이 된다. |
| 출처가 없는 문장 | 삭제하거나 낮춰야 할 문장을 드러낸다. | 확인 필요 또는 자료 보강 목록이 된다. |
| 확인이 필요한 내용 | 다음 수집과 검증을 만든다. | 5.1, 5.2, 8.2로 연결된다. |
| 다음 확인 질문 | 후속 질문을 좁힌다. | 6.1 질문 설계로 되돌아간다. |
4. 출처가 있어도 확실성 등급은 따로 본다
출처가 있다고 해서 모든 문장이 같은 수준으로 확실하지 않다. 회의록에 고객 문의가 늘었다는 발언이 있어도 실제 증가율은 통계가 필요하고, 공식 문서에 기능이 있어도 내가 쓰는 버전에서 동작하는지는 다시 확인해야 한다.
| 등급 | 의미 | 안전한 표현 | 업무 사용 기준 |
|---|---|---|---|
| 확인됨 | 원천 자료에 직접 근거가 있다. | 원천 자료 기준으로 확인됨 | 근거와 확인일을 붙여 사용한다. |
| 제한적 확인 | 근거는 있으나 범위가 좁다. | 현재 자료 기준으로는 확인됨 | 표본, 기간, 자료 범위를 함께 쓴다. |
| 추정 | 직접 근거 없이 가능성이나 예상 효과를 말한다. | 가능성이 있음, 후보로 검토 가능 | 실험 계획이나 추가 수집으로 전환한다. |
| 확인 필요 | 근거가 없거나 최신 확인이 필요하다. | 확인 필요, 현재 자료로는 단정 불가 | 보고서 단정문으로 쓰지 않는다. |
자동화가 효과적이다라는 강한 문장은 회의록 기준 반복 문의가 확인되므로 자동화 후보로 검토할 수 있다처럼 낮출 수 있다. 이 등급은 문장을 조심스럽게 만드는 장치다.
5. 추정은 숨기지 않을 때 쓸 수 있다
업무에서는 제한된 자료로 가설을 세우고 다음 행동을 정해야 한다. 문제는 추정을 확인된 사실처럼 쓰는 것이다. 확인된 내용, 추정, 확인 필요를 분리하면 회의와 실험 계획에서 논쟁 대상을 분명히 할 수 있다.
| 구역 | 넣을 내용 | 실무 의미 |
|---|---|---|
| 확인된 내용 | 원천에 직접 있는 사실, 현재 위키에 자료가 없다는 상태, 검토된 결정 | 회의와 보고서의 합의 출발점 |
| 추정 | 반복 문의 자동화 효과 가능성, 우선순위 후보, 예상 리스크 | 실험 계획과 추가 질문의 입력 |
| 확인 필요 | 문의량 통계, 처리 시간, 재검토 비율, 정확도 목표, 승인 기준 | 5장 수집과 8장 감사의 대상 |
6. 최신성 라벨은 실행 실패를 줄인다
LLM위키의 raw/wiki 분리 원칙은 비교적 안정적이지만, 설치 명령, 플러그인 호출 방식, 릴리스 번호, API 동작, 가격, 보안·권한 정책, 성능 개선 효과는 변동성이 높다. 이런 정보는 현재 사실로 단정하지 말고 기준 날짜와 확인 자료를 붙인다.
| 주장 유형 | 최신성 필요도 | 문서에 남길 것 | 검증 방식 |
|---|---|---|---|
| 개념 정의 | 낮음 | 원문 URL과 확인일 | 원문 변경 시 재확인 |
| 폴더 구조 원칙 | 낮음에서 중간 | 구현체별 예외 조건 | 현재 도구의 저장 구조 확인 |
| 설치 명령 | 높음 | 확인 날짜, 도구명, 버전, README 기준 | 현재 README와 설치된 도움말 확인 |
| 플러그인 기능 | 높음 | 구현체 문서 기준이라는 제한 | 현재 플러그인 문서 확인 |
| 릴리스 번호 | 높음 | 확인일 기준 최신 여부 | Releases 재확인 |
| 보안·권한 정책 | 높음 | 공식 문서와 조직 정책 확인 필요 | 운영 적용 전 보안 기준 확인 |
| 성능 개선 효과 | 높음 | 측정 환경과 데이터 범위 | 내부 데이터와 실험 결과 확인 |
7. 검증 결과는 6.3 반영 전의 선별 작업이다
6.2의 검증은 답변을 고치고 끝나는 일이 아니다. 확인된 문장만 관련 wiki 문서나 결정 로그에 반영하고, 출처 없는 문장은 확인 필요로 남기며, 최신성 확인이 필요한 문장은 기준 자료와 재확인 조건을 붙인다.
| 검증 결과 | 처리 위치 | 처리 기준 |
|---|---|---|
| 원천 근거가 있는 확인된 내용 | 관련 wiki 문서, 결정 로그 | 근거 위치와 확인일을 붙인다. |
| 제한적 확인 | wiki의 조건부 문장, 확인 필요 섹션 | 표본과 기간과 범위를 명시한다. |
| 출처 없음 | 확인 필요, 자료 보강 목록, 삭제 후보 | 업무 결정 근거로 쓰지 않는다. |
| 추정 | 실험 계획, 다음 질문, log.md | 가능성으로 표현하고 측정 기준을 붙인다. |
| 최신성 확인 필요 | 최신성 블록, 감사 로그 | 공식 문서와 현재 버전 재확인 조건을 남긴다. |
| 업무 결정에 쓰기 어려움 | output 보류, 추가 자료 요청 | 5장 수집으로 되돌린다. |
실무 적용 절차
- 6.1에서 만든 질문과 답변을 함께 보관한다. 질문의 자료 범위와 출력 형식이 답변 검증의 기준이 된다.
- 답변을 문장 단위로 나눈다. 긴 문단은 주장, 근거, 제안, 조건, 수치, 최신성 문장으로 쪼갠다.
- 각 문장에 원천 근거가 있는지 확인한다.
raw경로, URL, 회의록 날짜, 공식 문서명, 내부 정책 문서가 있는지 본다. wiki문서에만 있는 내용인지 확인한다. 원천 연결이 약하면wiki 근거만 있음또는제한적 확인으로 둔다.- 출처가 없는 문장을 표시한다. 삭제하지 않더라도 업무 결정 근거로 쓰지 않는다.
- 추정 문장을 찾는다. 가능성, 예상 효과, 우선순위, 일반적인 경향 같은 표현을 확인한다.
- 확실성 등급을 붙인다. 최소 등급은
확인됨,제한적 확인,추정,확인 필요다. - 최신성이 필요한 문장을 찾는다. 명령, 설치법, 릴리스, 가격, 정책, API, 보안 설정, 성능 효과가 포함되면 표시한다.
- 최신성 문장에는 확인 날짜, 기준 자료, 기준 버전 또는 재확인할 공식 문서를 붙인다.
- 강한 문장을 검토용 문장으로 낮춘다. 근거는 있는지, 무엇이 부족한지, 어떤 범위에서만 말할 수 있는지 보이게 고친다.
- 확인된 내용과 추정과 확인 필요를 별도 섹션으로 나눈다.
- 출처 없는 문장에서 필요한 자료를 역산한다. 통계, 작업 기록, 검토 코멘트, 공식 문서, 릴리스 노트, 내부 정책 중 무엇이 필요한지 적는다.
- 업무 보고서에 넣을 문장은 7.2의 주장-근거 매트릭스로 옮긴다.
- 실행 항목으로 옮길 문장은 7.3 기준으로 담당자, 기한, 완료 기준, 근거를 붙인다.
- 검증 결과를
log.md에 남긴다. 답변 검토일, 주요 확인 내용, 보류한 추정, 다음 자료 요청을 기록한다. - 관련
wiki문서에 반영할 문장과 보류할 문장을 나눈다. 6.3에서 전체 답변이 아니라 검증된 내용만 반영한다. - 최신성 확인 필요 문장은 8.2 감사 목록에 넣는다.
- 답변 검증 후 다음 질문을 만든다. 다음 질문은 출처 없는 문장이나 제한적 확인 문장을 직접 겨냥해야 한다.
실무 템플릿
답변 문장 근거 라벨표
| 번호 | 답변 문장 요약 | 근거 라벨 | 근거 위치 | 확실성 등급 | 처리 |
|---|---|---|---|---|---|
| 1 | 원천 근거 있음 / wiki 근거만 있음 / 출처 없음 / 추정 / 위키 상태 확인 | raw/..., URL, 회의록 날짜, 공식 문서명 | 확인됨 / 제한적 확인 / 추정 / 확인 필요 | 사용 / 낮춤 / 보류 / 자료 수집 / 삭제 |
확실성 등급 카드
| 등급 | 판단 질문 | 허용 표현 | 금지 표현 |
|---|---|---|---|
| 확인됨 | 원천 자료에 직접 있는가? | 원천 자료 기준으로 확인됨 | 모든 상황에서 확정 |
| 제한적 확인 | 근거는 있으나 범위가 좁은가? | 현재 자료 기준, 회의록 기준, 샘플 기준 | 전체 고객, 전체 기간, 항상 |
| 추정 | 근거를 바탕으로 예상하는가? | 가능성, 후보, 가설, 검토 대상 | 효과가 입증됨, 반드시 필요 |
| 확인 필요 | 근거가 없거나 최신 확인이 필요한가? | 확인 필요, 현재 자료로는 단정 불가 | 확정, 검증 완료 |
출처 요청 프롬프트
다음 질문에 답하세요. 질문: [업무 질문] 답변 형식: - 결론 - 결론의 근거 - 근거가 있는 문장과 출처 - 출처가 없는 문장 - 확인이 필요한 내용 - 다음 확인 질문 주의: 출처가 없는 내용은 단정하지 말고 확인 필요로 표시하세요. 원천 자료가 있는 문장도 확인 날짜와 근거 범위를 함께 표시하세요. 최신성이 필요한 주장은 기준 자료와 재확인할 공식 문서를 적어 주세요.
답변을 검토용 문장으로 낮추는 규칙
| 원래 문장 유형 | 위험 | 검토용 표현 방향 |
|---|---|---|
| 자동화하면 시간이 크게 줄어든다 | 정량 근거 없는 효과 주장 | 현재 위키에는 시간 절감 정량 근거가 없으나 자동화 후보로 검토 가능 |
| 고객 문의가 많다 | 기간과 수량이 없음 | 회의록 기준 반복 문의가 언급되었으나 최근 통계 확인 필요 |
| 이 도구는 Codex에서 바로 쓸 수 있다 | 구현체와 버전 의존 | 특정 구현체 문서 기준이며 현재 설치 환경 확인 필요 |
| 보안상 안전하다 | 정책과 권한 확인 없음 | 보안 기준과 외부 호출 범위 확인 전 단정 불가 |
| 최신 버전은 특정 릴리스다 | 릴리스 변동 | 확인일 기준으로 제한하고 Releases 재확인 필요 |
최신성 라벨 블록
## 최신성 - 상태: 확인됨 / 확인 필요 / 최신성 확인 필요 / 제한된 근거 / 추정 - 확인 날짜: - 기준 자료: - 기준 버전 또는 범위: - 다시 확인할 시점: - 확인하지 못하면 사용할 표현:
검증 결과 log 항목
| 날짜 | 작업 | 답변 또는 문서 | 확인된 내용 | 보류한 내용 | 다음 행동 |
|---|---|---|---|---|---|
| YYYY-MM-DD | answer-evidence-review | 질문 또는 답변 링크 | 원천 근거가 있는 문장 | 출처 없음, 추정, 최신성 확인 필요 | 자료 수집, 문서 갱신, 다음 질문 |
검증 체크리스트
문장별 근거 체크리스트
- 답변을 문장 단위로 나눴다.
- 각 문장에
raw경로, URL, 회의록 날짜, 공식 문서명 중 하나가 있는지 확인했다. wiki문서에만 있고 원천 연결이 약한 문장을 별도로 표시했다.- 출처 없는 문장을 확인 필요 또는 보류로 낮췄다.
- 답변 안의 제안과 근거를 분리했다.
- 현재 위키에 자료가 없다는 문장을 현재 위키 범위 안에서만 유효한 상태 진술로 다뤘다.
확실성 체크리스트
- 원천에 직접 있는 내용과 해석을 구분했다.
확인됨,제한적 확인,추정,확인 필요등급을 붙였다.- 제한적 확인 문장에는 자료 범위, 기간, 표본, 회의록 기준을 함께 썼다.
- 추정 문장을 보고서 단정문으로 쓰지 않았다.
- 확인 필요 항목은 필요한 자료와 다음 질문으로 바꿨다.
- 검토용 문장은 덜 화려해도 근거와 한계가 보이게 고쳤다.
최신성 체크리스트
- 설치 명령, 플러그인 기능, 릴리스 번호, 가격, 정책, API 동작, 보안 설정, 성능 효과를 찾았다.
- 최신성이 필요한 문장에 확인 날짜를 붙였다.
- 기준 자료와 공식 재확인 위치를 남겼다.
- 특정 구현체 명령을 OpenAI나 Anthropic의 기본 내장 기능처럼 단정하지 않았다.
- 확인하지 못한 최신 정보는 현재 사실이 아니라 확인 필요로 표시했다.
- 최신성 확인 필요 문장을 8.2 감사 목록에 넘길 수 있다.
업무 산출물 전환 체크리스트
- 보고서에 넣을 문장마다 근거 위치가 있다.
- 확신도 낮은 주장은 조건부 표현으로 바꿨다.
- 실행 제안에는 담당자, 기한, 완료 기준, 근거가 필요함을 표시했다.
- 근거 없는 효과 주장이나 성능 수치를 output에 넣지 않았다.
- 산출물에서 사용한 결정과 새 기준을 6.3 반영 후보로 분리했다.
- 출처 없음과 추정 문장을
wiki에 그대로 복사하지 않았다.
좋은 질문과 검증 질문
LLM에게 던질 좋은 질문
- 아래 답변을 문장 단위로 나누고, 각 문장에 원천 근거 있음, wiki 근거만 있음, 출처 없음, 추정, 위키 상태 확인 라벨을 붙여 주세요. 근거 위치와 처리 방안도 함께 표로 정리해 주세요.
- 이 답변에서 보고서에 바로 넣어도 되는 문장과 조건부 표현으로 낮춰야 하는 문장을 나눠 주세요. 낮춰야 하는 문장은 안전한 검토용 표현으로 바꿔 주세요.
- 아래 문장 중 최신성 확인이 필요한 문장만 골라 주세요. 이유, 확인해야 할 공식 자료, 확인하지 못했을 때의 안전한 표현을 적어 주세요.
- 이 답변의 확인 필요 항목을 다음 자료 수집 목록으로 바꿔 주세요. 필요한 자료, 저장 위치, 우선순위, 민감 정보 여부를 표로 정리해 주세요.
- 이 답변을 6.3에서 위키에 반영해도 되는지 검토해 주세요. 반영할 내용, 보류할 추정,
log.md에 남길 항목, 다음 질문을 나눠 주세요.
사람이 확인할 검증 질문
- 이 문장은 원천 자료에 직접 있는가, 위키 정리문에만 있는가, LLM의 추정인가?
- 출처가 있는 문장이라도 현재 업무 결정에 충분한 범위의 근거인가?
- 원문에 있는 사실과 내가 기대하는 효과가 한 문장으로 붙어 있지 않은가?
- 출처 없는 문장이 자연스럽고 설득력 있다는 이유로 보고서에 들어가고 있지 않은가?
- 최신성이 필요한 도구 명령, 정책, 가격, 버전, 보안 설정을 현재 사실처럼 쓰고 있지 않은가?
- 확인 필요를 삭제해 답변을 깔끔하게 만들고 있지 않은가?
- 이 답변을 반영하면 다음 질문이 쉬워지는가, 아니면 추정이 위키에 더 쌓이는가?
- 검증 결과가
log.md, 관련wiki, 다음 자료 수집 목록으로 이어지는가?
흔한 실패와 수정 방향
| 실패 사례 | 왜 위험한가 | 수정 방향 |
|---|---|---|
| 답변 전체를 좋은 답으로 평가한다. | 같은 답변 안에서도 확인됨, 추정, 출처 없음이 섞인다. | 문장 단위 라벨링을 한다. |
| 출처가 하나라도 있으면 결론 전체를 믿는다. | 일부 근거가 전체 효과나 우선순위를 보장하지 않는다. | 원천 근거와 해석과 실행 제안을 분리한다. |
| 효과 주장을 그대로 보고서에 넣는다. | 정량 근거 없는 예상이 확정 성과처럼 보인다. | 현재 자료 기준과 부족한 근거가 보이는 문장으로 낮춘다. |
| 추정을 모두 삭제한다. | 업무 가설과 다음 실험 기회를 잃는다. | 추정은 별도 섹션에 두고 확인 필요와 연결한다. |
| 최신성 필요한 명령을 현재 사실로 단정한다. | 실행 실패, 보안 위험, 버전 불일치가 생긴다. | 확인 날짜, 기준 자료, 공식 재확인 위치를 붙인다. |
| 특정 구현체 명령을 기본 기능처럼 설명한다. | 다른 환경에서 재현되지 않고 책임 경계가 흐려진다. | 구현체 문서 기준으로 제한하고 현재 도움말을 확인한다. |
| 확인 필요가 있는 답변을 그대로 위키에 반영한다. | 불확실성이 장기 지식으로 굳어진다. | 확인된 내용만 반영하고 나머지는 log.md와 자료 보강 목록에 둔다. |
AGENTS.md나 CLAUDE.md가 있으니 검증을 생략한다. | 지침 파일은 결과 품질을 강제하지 않는다. | 결과 문장에서 실제 근거와 라벨을 확인한다. |
관련 문서
- 6장. 위키에 질문하고 답을 검증하기: 6.1-6.3의 질문, 검증, 반영 흐름 전체를 묶는다.
- 6.1 좋은 질문 만들기: 처음부터 자료 범위, 결정 목적, 출력 형식, 검증 요청이 들어간 질문을 설계한다.
- 6.3 답변을 다시 위키에 반영하기: 6.2에서 검증한 내용만 결정 로그와 관련 위키에 반영한다.
- 2.1 지식이 쌓이는 세 층:
raw,wiki, rules의 신뢰 경계를 설명한다. - 2.3 좋은 위키 문서의 조건: 출처, 재사용성, 링크가 좋은 위키 문서의 조건인 이유를 설명한다.
- 4.3 첫 질문으로 방향 잡기: 첫 답변을 확인된 내용, 제한된 추정, 추가 자료로 나누는 전 단계 원칙을 제공한다.
- 5.1 자료를 넣기 전에 정할 기준: 확인 필요 문장을 어떤 raw 자료와 신뢰도 기준으로 보강할지 정한다.
- 5.2 자료 수집하기: 답변에서 발견한 부족한 근거를 수집으로 연결한다.
- 5.3 위키 문서로 정리하기: 보강 자료를 질문 기준의 wiki 문서로 나누고 중복과 모순을 처리한다.
- 7.1 산출물의 목적 정하기: 검증된 답변을 요약, 보고서, 실행 계획 중 어떤 output으로 바꿀지 정한다.
- 7.2 업무 보고서 만들기: 확인된 문장을 주장-근거 매트릭스로 옮겨 보고서 문장으로 만든다.
- 7.3 다음 행동으로 연결하기: 실행 제안을 담당자, 기한, 완료 기준, 근거가 있는 행동으로 바꾼다.
- 8.1 위키에도 점검이 필요한 이유: 그럴듯한 요약이 시간이 지나며 출처와 조건을 잃는 위험을 설명한다.
- 8.2 정리와 감사 흐름 만들기: 최신성 확인 필요와 출처 없음 항목을 주기 감사 루틴으로 연결한다.
한계와 완료 기준
이 HTML은 2026-06-06 KST에 작성된 로컬 Markdown 분석 파일을 근거로 변환했다. WikiDocs 원문 자체의 최신 수정 여부와 세부 표현은 원문에서 다시 확인해야 한다.
원문이 언급한 Karpathy LLM Wiki Gist, nvk/llm-wiki, OpenAI Codex 문서, Claude Code memory 문서, WiCER 프리프린트는 원문 확인일 기준의 참고 근거다. 이 페이지는 해당 외부 자료의 현재 상태를 별도로 검증하지 않았다.
- LLM위키 답변을 문장 단위로 나눴다.
- 각 문장에 원천 근거 있음, wiki 근거만 있음, 출처 없음, 추정, 위키 상태 확인 같은 근거 라벨을 붙였다.
- 확실성 등급을 확인됨, 제한적 확인, 추정, 확인 필요로 구분했다.
- 출처 없는 문장과 추정 문장을 보고서 단정문으로 쓰지 않았다.
- 최신성이 필요한 주장에 확인 날짜, 기준 자료, 재확인 위치를 붙였다.
- 강한 효과 주장과 도구 명령을 검토 가능한 조건부 문장으로 낮출 수 있다.
- 확인 필요 항목을 필요한 자료, 저장 위치, 다음 질문으로 바꿨다.
- 검증 결과를 6.3의 결정 로그, wiki 반영,
log.md갱신으로 넘길 준비가 됐다. - 7장의 output 작성 전 주장-근거 매트릭스에 넣을 문장과 보류할 문장을 나눴다.
- 8장의 감사 루틴으로 넘길 최신성 확인 필요 항목을 표시했다.