Query: 위키에 질문하는 법

질문은 검색어가 아니라 작업 지시다

LLM Wiki를 만들었다면 다음 단계는 질문하는 법이다. 많은 사람이 위키를 만들어두고도 다시 예전 방식으로 돌아간다. 파일명으로 검색하고, 관련 문서를 열어보고, 필요한 문장을 복사해 새 문서를 만든다. 물론 이것도 유용하다. 하지만 LLM Wiki의 장점은 여기서 시작되지 않는다.

LLM Wiki에서 질문은 단순 검색어가 아니다. 질문은 AI 지식관리자에게 내리는 작업 지시다. "무엇을 찾아줘"에서 끝나지 않고, "어떤 문서를 먼저 보고, 어떤 기준으로 판단하고, 답변을 어떤 형태로 남길지"까지 포함해야 한다.

일반적인 ChatGPT 질문은 대화창 안에서 끝난다. 반면 LLM Wiki의 Query는 위키를 읽고, 연결하고, 판단하고, 다시 위키를 갱신하는 루프의 시작점이다.

핵심은 간단하다.

좋은 질문은 좋은 답변을 만들고, 좋은 답변은 다시 위키의 자산이 된다.

질문을 잘한다는 것은 말을 멋지게 쓰는 일이 아니다. AI가 참고해야 할 범위, 답변 형식, 판단 기준, 저장 방식을 명확히 정하는 일이다.

질문의 다섯 가지 유형

LLM Wiki에서 자주 쓰는 질문은 크게 다섯 가지로 나눌 수 있다. 질문 유형을 구분하면 답변의 품질이 올라간다. AI도 지금 해야 할 일이 검색인지, 비교인지, 판단인지 더 분명히 이해한다.

1. 단순 검색 질문

단순 검색 질문은 위키 안에서 특정 개념, 인물, 프로젝트, 결정, 자료를 찾는 질문이다.

예를 들면 다음과 같다.

index.md를 먼저 읽고, 우리 위키에서 "고객 온보딩"과 관련된 페이지를 찾아줘.
각 페이지의 핵심 내용과 연결된 raw 출처를 함께 정리해줘.

이 질문의 목적은 답을 바로 얻는 것보다 관련 지식의 위치를 찾는 데 있다. 좋은 단순 검색 질문은 "찾아줘"에서 끝나지 않는다. 관련 페이지, 핵심 요약, 연결 관계를 함께 요구한다.

나쁜 질문은 이렇게 묻는다.

고객 온보딩에 대해 알려줘.

이렇게 물으면 AI는 일반 지식을 섞어 답할 수 있다. LLM Wiki에서는 "우리 위키에서", "index.md를 먼저 읽고", "관련 페이지를 선별한 뒤" 같은 지시가 중요하다.

2. 요약 질문

요약 질문은 여러 문서에 흩어진 내용을 하나의 관점으로 압축할 때 쓴다.

최근 3개월 고객 인터뷰 페이지를 읽고,
반복해서 등장한 불만, 구매 이유, 이탈 이유를 요약해줘.
각 항목마다 근거가 되는 [[고객 인터뷰]] 페이지와 raw 출처를 붙여줘.

요약 질문에서 중요한 것은 범위와 축이다. "요약해줘"라고만 하면 문서별 요약이 나온다. 하지만 "불만, 구매 이유, 이탈 이유"처럼 축을 지정하면 의사결정에 쓸 수 있는 요약이 나온다.

요약은 짧게 만드는 일이 아니다. 판단 가능한 구조로 다시 배열하는 일이다.

3. 비교 질문

비교 질문은 두 개 이상의 선택지를 놓고 차이를 보고 싶을 때 쓴다. 제품 기능, 경쟁사, 학습법, 책의 주장, 기술 스택을 비교할 때 특히 유용하다.

[[경쟁사 A]]와 [[경쟁사 B]]를 비교해줘.
비교 기준은 타깃 고객, 핵심 기능, 가격 전략, 온보딩 방식, 우리가 배울 점으로 해줘.
위키에 근거가 부족한 항목은 "근거 부족"이라고 표시해줘.

좋은 비교 질문에는 비교 기준이 들어간다. 기준이 없으면 AI는 보기 좋은 표를 만들지만, 실제 판단에는 약한 답을 내놓는다.

비교 질문을 할 때는 "우리가 배울 점", "우리 전략에 주는 의미" 같은 항목을 추가하는 것이 좋다. 단순 정보 비교에서 실행 가능한 판단으로 넘어가기 위해서다.

4. 전략 질문

전략 질문은 위키에 쌓인 정보를 바탕으로 방향을 제안하게 만드는 질문이다. 이때 AI에게 최종 결정을 맡기면 안 된다. AI의 역할은 판단 후보를 정리하고, 근거와 리스크를 드러내는 것이다.

index.md를 먼저 읽고, 제품 비전, 고객 피드백, 최근 의사결정 로그를 참고해줘.
현재 우리 팀이 다음 분기에 집중할 만한 제품 우선순위 3가지를 제안해줘.
각 제안에 대해 근거, 기대 효과, 리스크, 추가로 확인해야 할 질문을 정리해줘.

전략 질문에는 반드시 판단 기준이 있어야 한다. 예를 들어 매출, 고객 만족, 개발 난이도, 브랜드 포지션, 학습 가치 같은 기준이다.

전략 질문의 답변은 정답이 아니라 회의 자료에 가깝다. 좋은 답변은 "이렇게 하세요"가 아니라 "이 선택지는 이런 근거가 있고, 이런 위험이 있으며, 아직 모르는 것은 이것입니다"라고 말한다.

5. 모순 탐지 질문

LLM Wiki가 커질수록 가장 중요한 질문 중 하나가 모순 탐지다. 오래된 문서와 최신 문서가 서로 다른 말을 할 수 있다. 한 페이지에서는 "초기 사용자는 개발자"라고 쓰고, 다른 페이지에서는 "핵심 고객은 비개발자 기획자"라고 쓸 수 있다. 둘 다 작성 당시에는 맞았을 수 있다.

고객 타깃과 제품 포지셔닝에 관한 페이지를 검토해줘.
서로 충돌하거나 시점에 따라 달라진 주장을 찾아줘.
각 모순에 대해 관련 [[위키링크]], raw 출처, 마지막 업데이트 날짜를 정리하고,
해결 방법을 제안해줘.

모순 탐지는 위키의 건강검진이다. 모순이 발견되었다고 해서 곧바로 나쁜 것은 아니다. 오히려 지식이 변하고 있다는 신호일 수 있다. 중요한 것은 모순을 숨기지 않고 표시하는 것이다.

기본 Query 프롬프트 구조

LLM Wiki에서 가장 많이 쓰게 될 기본 Query 프롬프트는 다음 구조를 따르면 된다.

너는 이 저장소의 LLM Wiki 관리자다.

작업 순서:
1. 먼저 index.md를 읽고 전체 구조를 파악한다.
2. 질문과 관련된 wiki 페이지 후보를 선별한다.
3. 필요한 경우에만 raw 원문을 확인한다.
4. 답변에는 반드시 관련 [[위키링크]]를 포함한다.
5. 근거가 되는 raw 출처가 있으면 함께 표시한다.
6. 위키에 근거가 부족한 내용은 추측하지 말고 "근거 부족"이라고 쓴다.
7. 답변 끝에 새로 만들거나 업데이트하면 좋을 페이지를 제안한다.

질문:
{여기에 질문을 쓴다}

답변 형식:
- 결론
- 근거가 되는 위키 페이지
- raw 출처
- 불확실한 점
- 다음 업데이트 제안

이 프롬프트의 핵심은 "index.md를 먼저 읽는다"는 지시다. index.md는 위키의 지도다. AI가 무작정 파일 전체를 훑게 만들기보다, 먼저 지도를 보고 관련 문서를 고르게 해야 한다.

또 하나 중요한 지시는 "필요한 경우에만 raw 원문을 확인한다"는 문장이다. 모든 질문마다 raw 전체를 다시 읽으면 느리고 비효율적이다. 기본 답변은 wiki 지식층에서 만들고, 근거 확인이 필요한 경우 raw로 내려가게 만드는 것이 좋다.

답변에 링크와 출처를 남겨라

LLM Wiki의 답변은 추적 가능해야 한다. 답변이 그럴듯해도 어디에서 나온 말인지 알 수 없다면 지식 자산으로 쓰기 어렵다.

그래서 답변에는 두 종류의 연결이 필요하다.

첫째, 위키 내부 링크다.

이번 결론은 [[고객 온보딩 문제]], [[2026-Q2 제품 우선순위]], [[경쟁사 A 분석]]과 관련이 있다.

둘째, raw 출처다.

근거 raw:
- raw/meetings/2026-04-12-customer-interview.md
- raw/articles/competitor-a-pricing.md

위키링크는 생각의 연결을 보여준다. raw 출처는 증거의 위치를 보여준다. 이 둘이 함께 있어야 나중에 사람이 검토할 수 있다.

특히 팀 위키에서는 출처가 중요하다. "누가 그런 말을 했는가", "어떤 회의에서 결정했는가", "어떤 고객 인터뷰에서 나왔는가"를 추적할 수 있어야 한다. 출처 없는 답변은 회의에서 설득력이 떨어진다.

Query 결과를 저장하는 루프

많은 사람이 LLM에게 좋은 답변을 받고도 그대로 버린다. 이것이 가장 큰 손실이다. Query의 목적은 답변을 한 번 소비하는 것이 아니다. 좋은 답변을 위키에 다시 저장해 다음 질문의 기반으로 만드는 것이다.

기본 루프는 다음과 같다.

1. 질문한다.

2. AI가 index.md와 관련 페이지를 읽는다.

3. 답변을 받는다.

4. 답변 중 재사용 가치가 있는 내용을 고른다.

5. 새 페이지를 만들거나 기존 페이지를 업데이트한다.

6. log.md에 변경 사항을 남긴다.

이 루프를 프롬프트로 만들면 다음과 같다.

방금 답변 중 장기적으로 재사용할 가치가 있는 내용을 위키에 반영해줘.

규칙:
- 기존 페이지에 들어갈 내용은 기존 페이지 업데이트로 처리한다.
- 독립 주제로 관리할 만한 내용은 새 페이지를 만든다.
- 새 페이지에는 관련 [[위키링크]]와 raw 출처를 포함한다.
- 확실하지 않은 내용은 "검토 필요"로 표시한다.
- 변경 사항을 log.md에 기록한다.
- index.md에 새 페이지 링크가 필요하면 추가한다.

이 지시를 통해 대화는 위키 업데이트로 이어진다. 질문 하나가 답변 하나로 끝나지 않고, 지식 구조를 조금씩 개선한다.

새 페이지로 저장할지, 기존 페이지에 붙일지

Query 결과를 저장할 때는 판단이 필요하다. 모든 답변을 새 페이지로 만들면 위키가 금방 어지러워진다. 반대로 모든 내용을 기존 페이지에 붙이면 페이지가 너무 커지고 핵심이 흐려진다.

간단한 기준은 다음과 같다.

새 페이지로 만들기 좋은 경우:

• 반복해서 다시 물어볼 주제다.

• 독립적인 개념이나 결정으로 관리할 가치가 있다.

• 여러 페이지에서 링크될 가능성이 높다.

• 현재 위키에 없는 새로운 관점이다.

기존 페이지에 업데이트하기 좋은 경우:

• 기존 개념의 보충 설명이다.

• 특정 프로젝트의 진행 상황이다.

• 이미 있는 주장에 근거를 추가하는 내용이다.

• 오래된 내용을 최신 상태로 바꾸는 수정이다.

예를 들어 "고객 온보딩에서 반복되는 세 가지 실패 패턴"이라는 답변이 나왔다면 새 개념 페이지로 만들 수 있다. 반면 "4월 인터뷰에서 온보딩 문제가 2건 추가로 확인됨"은 기존 [[고객 온보딩 문제]] 페이지에 업데이트하는 편이 낫다.

좋은 질문은 범위를 좁힌다

LLM Wiki에서 가장 흔한 실패는 질문이 너무 넓은 것이다.

우리 사업 전략을 알려줘.

이 질문은 너무 크다. AI는 그럴듯한 말을 할 수 있지만, 실제 위키 기반 답변이 되기 어렵다. 더 나은 질문은 이렇게 바꿀 수 있다.

index.md를 읽고, 제품 비전 페이지와 최근 2개월 고객 피드백, 의사결정 로그를 참고해줘.
현재 유료 전환율을 높이기 위해 검토할 수 있는 전략 3가지를 제안해줘.
각 전략은 근거, 실행 난이도, 예상 리스크, 추가 확인 질문으로 정리해줘.

차이는 명확하다. 좋은 질문은 범위, 자료, 목적, 출력 형식을 지정한다.

질문을 만들 때 다음 네 가지를 확인하자.

• 범위: 어떤 기간, 어떤 프로젝트, 어떤 페이지를 볼 것인가?

• 목적: 찾기, 요약, 비교, 판단, 모순 탐지 중 무엇인가?

• 기준: 어떤 관점으로 평가할 것인가?

• 결과: 답변만 받을 것인가, 위키 업데이트까지 할 것인가?

이 네 가지가 있으면 답변 품질이 크게 달라진다.

Query는 위키를 성장시키는 대화다

LLM Wiki의 진짜 힘은 질문을 반복할수록 커진다. 처음에는 위키가 빈약하기 때문에 답변도 얕다. 하지만 질문하고, 답변을 저장하고, 다시 질문하는 과정을 반복하면 위키는 점점 더 나은 대답을 할 수 있는 구조가 된다.

중요한 것은 대화 기록을 그대로 쌓는 것이 아니다. 대화에서 나온 가치 있는 판단, 요약, 비교, 모순, 결정만 위키에 편입하는 것이다. 대화는 원재료이고, 위키는 정제된 지식층이다.

질문은 소비가 아니라 운영이다. 오늘 던진 좋은 질문 하나가 내일의 페이지가 되고, 다음 달의 의사결정 근거가 될 수 있다.

AI에게 매번 처음부터 설명하는 사람은 매번 같은 출발선에 선다. 반면 위키에 질문하고 답변을 저장하는 사람은 이전 질문 위에서 다음 질문을 시작한다. 이것이 LLM Wiki가 만드는 지식의 복리다.