6.1 좋은 질문 만들기 원문 기반 심화 분석

핵심 요약

6.1의 핵심은 LLM위키에 던지는 질문을 단순 검색어가 아니라 검증 가능한 업무 요청으로 바꾸는 것이다. 위키는 자료를 모아 둔 장소이고, 질문은 그 자료를 업무 결과로 꺼내는 방식이다. 같은 위키라도 “요약해 줘”와 “다음 회의 의사결정을 위해 근거와 확인 필요를 나눠 정리해 줘”는 전혀 다른 답변을 만든다.

좋은 질문은 확인할 주제, 사용할 자료 범위, 원하는 결과물 형태를 함께 담는다. 실무에서는 여기에 업무 목적, 판단 기준, 제외 범위, 검증 조건, 다음 행동까지 붙이면 답변이 안정된다. 질문의 맥락은 넓게 열어 두기보다 시간 범위, 자료 범위, 판단 기준, 제외 범위로 의도적으로 좁혀야 한다.

좋은 질문의 마지막 단계는 답변을 바로 실행 가능한 산출물로 요청하는 것이다. 독자, 목적, 출력 형식, 실행 순서, 확인할 항목, 근거와 한계 표시를 지정하면 답변은 설명문이 아니라 보고서 초안, 실행 계획, 검증 가능한 표가 된다. 첫 답변 뒤에는 근거가 약한 항목과 위험한 가정을 후속 질문으로 분리해 6.2의 근거 검증으로 넘겨야 한다.

원문 구조와 실무 의미

상세 분석

1. 질문은 위키의 지식을 꺼내는 실행 인터페이스다

LLM위키를 만들었다고 좋은 답이 자동으로 나오지는 않는다. raw 원천 자료와 wiki 정리 문서가 있어도 질문이 막연하면 LLM은 자료를 업무 맥락에 맞게 재구성하지 못한다. 질문은 어떤 근거를 어떤 업무 목적에 쓸지 정하고, 답변은 보고서, 실행 계획, 결정 후보, 확인 필요 목록으로 나온다.

2. 단순 검색 질문은 업무 질문으로 확장해야 한다

무엇인지, 어디에 있는지, 간단히 요약해 달라는 질문은 필요하다. 그러나 업무에서는 정보 탐색 뒤에 보고, 결정, 실행이 이어진다. 따라서 질문에는 답변을 보고 사람이 무엇을 할지 드러나야 한다.

3. 질문에는 범위, 목적, 결과물 형태가 함께 있어야 한다

좋은 질문은 확인할 주제, 사용할 자료 범위, 원하는 결과물 형태를 담는다. 실무에서는 업무 목적, 판단 기준, 제외 범위, 검증 조건까지 포함해야 위키 밖 일반론과 근거 있는 지식을 구분할 수 있다.

4. 맥락을 좁히면 판단이 선명해진다

넓은 질문은 LLM에게 넓은 일반론을 허용한다. 시간 범위, 자료 범위, 판단 기준, 제외 범위를 정하면 답변은 현재 위키 근거에 가까워진다. 업무에서는 창의적인 일반론보다 재현 가능한 제한 답변이 더 유용한 경우가 많다.

5. 흐린 표현은 기준과 형식으로 바꾼다

“알아서”, “전체적으로”, “좋게”, “중요한 것 위주로” 같은 표현은 편하지만 판단 기준을 LLM에게 위임한다. 이런 표현을 쓸 때는 반드시 기준과 출력 형식을 같이 적어야 한다.

6. 답변 형식을 먼저 정하면 빈칸과 근거 부족이 보인다

답변 형식은 미관이 아니라 검증 장치다. 실행 계획 표에 할 일, 담당자 후보, 기한, 필요한 자료, 근거, 확인 필요 열을 두면 무엇이 비어 있는지 바로 보인다. 담당자와 기한이 자료에서 확인되지 않았으면 확인 필요로 남기고, 근거 열이 비어 있으면 6.2에서 검증해야 한다.

7. 후속 질문은 6.2 검증으로 넘어가는 다리다

첫 답변을 받은 뒤에는 근거가 약한 항목, 위험한 가정, 확인 필요를 다시 물어야 한다. 후속 질문을 통해 첫 답변은 최종 산출물이 아니라 검증과 갱신의 재료가 된다.

실무 적용 절차

1. 현재 질문이 단순 검색인지 업무 질문인지 분류한다.
2. 답변을 보고 할 일을 한 문장으로 쓴다. 보고, 결정, 실행, 검증, 자료 보강 중 무엇을 원하는지 정한다.
3. 사용할 자료 범위를 지정한다. wiki/ 문서명, raw/ 폴더, 회의록 날짜, 웹 문서 URL, 확인일을 가능한 한 명시한다.
4. 시간 범위를 정한다. 지난 2주, 특정 월, 특정 회의, 최신 릴리스 기준처럼 경계를 둔다.
5. 판단 기준을 정한다. 비용, 반복 빈도, 고객 영향, 실행 난이도, 보안 위험, 최신성 중 필요한 것만 고른다.
6. 제외 범위를 쓴다. 미검토 자료, 추측, 오래된 정책, 민감 정보 원문, 위키 밖 일반론을 어떻게 다룰지 정한다.
7. 답변 형식을 먼저 정한다. 표, 보고서 초안, 실행 계획, 비교표, 체크리스트 중 하나를 선택한다.
8. 검증 조건을 넣는다. 근거 위치, 확인 필요, 제한된 추정, 출처 없음 표시를 요청한다.
9. 첫 답변을 받으면 바로 쓰지 않고 근거 약점, 위험한 가정, 확인 필요를 후속 질문으로 다시 묻는다.
10. 확인된 내용과 보류할 추정을 분리한다. 확인된 내용은 6.3의 위키 반영 후보가 되고, 추정은 확인 필요나 log.md로 간다.

실무 템플릿

업무 질문 설계 카드

검색 질문을 업무 질문으로 바꾸는 템플릿

[막연한 질문]을 다음 업무 질문으로 바꾼다.

현재 위키의 [wiki 문서]와 [raw 원천 자료]만 기준으로,
[업무 목적]을 위해 [확인할 주제]를 정리해 주세요.
판단 기준은 [기준 1], [기준 2], [기준 3]입니다.
결과는 [출력 형식]으로 작성해 주세요.
각 핵심 항목에는 근거 문서 또는 원천 자료를 표시해 주세요.
자료에서 확인되지 않는 내용은 단정하지 말고 확인 필요로 표시해 주세요.

바로 실행 가능한 답변 요청 템플릿

[wiki 문서]와 [raw 자료]를 기준으로 [업무 주제]에 대한 [산출물]을 작성해 주세요.

대상 독자는 [독자]이고, 목적은 [회의 승인 / 실행 계획 수립 / 보고 / 검토]입니다.

다음 형식으로 작성해 주세요.
1. 한 문장 결론
2. 핵심 근거
3. 선택지 또는 실행 항목
4. 필요한 담당자와 입력 자료
5. 성공 기준 또는 완료 기준
6. 근거가 있는 항목
7. 확인 필요한 항목

자료에서 확인되지 않는 담당자, 일정, 효과 수치, 정책 기준은 임의로 만들지 말고 확인 필요로 표시해 주세요.

답변 후 후속 질문 묶음

1. 방금 답변에서 근거가 약한 항목만 골라 주세요.
   각 항목마다 왜 근거가 약한지, 추가로 확인해야 할 원천 자료가 무엇인지 적어 주세요.

2. 위 답변을 실행 계획으로 쓰기 전에 위험한 가정을 찾아 주세요.
   자료에서 확인된 사실, 자료에서 추정한 내용, 확인되지 않은 내용을 나누어 주세요.

3. 팀장에게 보낼 1페이지 요약으로 줄여 주세요.
   단, 확인 필요 항목은 삭제하지 말고 별도 섹션으로 유지해 주세요.

4. 이 답변에서 wiki에 반영할 수 있는 확인된 내용과 log에 남길 확인 필요를 나누어 주세요.

검증 체크리스트

질문 작성 전

• 질문이 단순 검색어나 요약 요청에 머물지 않는다.
• 답변을 보고 할 업무 목적이 있다.
• 사용할 wiki/ 문서와 raw/ 자료 범위가 명시되어 있다.
• 시간 범위가 필요한 경우 기간 또는 확인일이 들어 있다.
• 판단 기준과 제외 범위가 있다.
• 출력 형식이 표, 목록, 보고서 초안, 실행 계획처럼 명확하다.
• 근거 위치와 확인 필요 표시를 요청했다.
• 위키 밖 일반론을 확인된 내용으로 섞지 말라고 제한했다.

답변 수신 후

• 답변의 핵심 항목마다 근거 문서 또는 원천 자료가 있다.
• 근거가 없는 문장이 자연스러운 단정문으로 남지 않았다.
• 담당자, 기한, 효과 수치가 자료에서 확인되지 않으면 확인 필요로 표시됐다.
• 답변 형식이 요청한 output 형식과 맞는다.
• 근거가 약한 항목을 후속 질문으로 다시 물었다.
• 위험한 가정과 확인되지 않은 내용을 분리했다.
• 확인 필요 항목을 삭제하지 않고 다음 자료 수집이나 검증 대상으로 남겼다.

위키 반영 전

• 첫 답변 전체를 wiki에 복사하지 않았다.
• 확인된 내용만 관련 wiki 문서 반영 후보로 분리했다.
• 제한된 추정은 확인 필요 또는 log.md로 낮췄다.
• 반복적으로 쓸 질문은 템플릿으로 저장했다.
• 다음 절인 6.2에서 문장별 근거 라벨을 붙일 준비가 됐다.

관련 문서

• 6장. 위키에 질문하고 답을 검증하기: 6.1-6.3의 질문, 검증, 반영 흐름을 장 전체로 연결한다.
• 4.3 첫 질문으로 방향 잡기: 첫 위키 질문에 자료 기준, 결정 목적, 답변 형식, 검증 요청을 넣는 방법.
• 5.1 자료를 넣기 전에 정할 기준: 질문에 사용할 자료 범위, 제외 범위, 신뢰도, 최신성 기준.
• 5.2 자료 수집하기: 질문에서 드러난 자료 부족을 수집 카드로 바꾸는 방법.
• 5.3 위키 문서로 정리하기: 질문 기준으로 raw 자료를 wiki 문서에 연결하는 방법.
• 6.2 답변의 근거 확인하기: 6.1에서 받은 답변을 문장별 근거 라벨과 확실성 등급으로 검증한다.
• 6.3 답변을 다시 위키에 반영하기: 확인된 내용만 결정 로그, 관련 wiki, index, log에 반영한다.
• 7.1 산출물의 목적 정하기, 7.2 업무 보고서 만들기, 7.3 다음 행동으로 연결하기: 질문으로 받은 답변을 output과 실행 항목으로 전환한다.
• 8.1 위키에도 점검이 필요한 이유, 8.2 정리와 감사 흐름 만들기: 질문 템플릿, output, log가 오래된 근거와 중복을 만들지 않게 감사한다.

한계와 확인 필요

• 원문이 제시한 외부 참고 자료의 현재 상태는 이 HTML 생성 과정에서 별도 검증하지 않았다.
• 질문에 자료 범위와 검증 조건을 넣어도 LLM 답변의 정확성이 자동 보장되지는 않는다. 6.2의 문장별 근거 확인과 6.3의 검증 후 반영 절차가 필요하다.
• 좋은 질문은 자료 부족을 해결하지 않는다. 질문을 좁혔는데도 답변이 약하면 5.1과 5.2로 돌아가 원천 자료를 보강해야 한다.
• 확인 필요는 문서 결함이 아니라 후속 검증 항목이다. 보기 좋은 output을 만들기 위해 확인 필요를 삭제하면 위키의 신뢰 경계가 무너진다.

이 절의 완료 기준

1. 단순 검색 질문과 업무 질문의 차이를 설명할 수 있다.
2. 질문에 확인할 주제, 사용할 자료 범위, 원하는 결과물 형태를 넣을 수 있다.
3. 시간 범위, 자료 범위, 판단 기준, 제외 범위로 질문의 맥락을 좁힐 수 있다.
4. 흐린 표현을 구체적인 기준과 출력 형식으로 바꿀 수 있다.
5. 답변을 요약문이 아니라 보고서 초안, 실행 계획, 검토표 같은 업무 산출물로 요청할 수 있다.
6. 근거 문서, 확인 필요, 제한된 추정을 표시하라고 요구할 수 있다.
7. 첫 답변 뒤 근거 약점, 위험한 가정, 확인 필요를 묻는 후속 질문을 만들 수 있다.
8. 답변을 바로 위키에 복사하지 않고 6.2의 근거 검증과 6.3의 반영 절차로 넘길 수 있다.