핵심 요약
이 문서의 중심 문제는 “LLM이 답을 못한다”가 아니라 “좋은 답을 만들기 위해 매번 설명한 업무 기준이 다음 작업에 남지 않는다”는 데 있다. 보고서 톤, 제외 정보, 판단 기준, 팀 용어, 출력 형식이 대화창 안에서만 소비되면 사용자는 다음 요청에서 같은 배경을 다시 써야 한다.
따라서 1.1의 첫 행동은 도구 설치가 아니다. 최근 LLM 요청에서 반복된 맥락을 찾아, 다음에도 필요한 업무 기준인지 판정하고, 작은 첫 위키 후보로 표시하는 것이다. 대화 기록은 버릴 자료가 아니라 raw 후보지만, 확인된 기준과 예외 규칙으로 재구성되기 전에는 wiki 지식이 아니다.
첫 후보는 작아야 한다. 회사 전체 지식베이스가 아니라 “주간 회의록 실행 항목 정리 기준”, “월간 보고서 작성 규칙”, “고객 문의 분류 기준”처럼 반복성과 기준성이 확인된 업무 하나가 적합하다.
원문 구조와 실무 의미
| 원문 절 | 핵심 내용 | 실무 의미 |
|---|---|---|
| 도입부 | 비슷한 보고서를 다시 만들 때 배경과 기준을 다시 입력하는 상황을 제시한다. | LLM 사용량이 늘어도 기준 문서가 없으면 업무 지식은 축적되지 않는다. |
| 매번 다시 설명하는 업무 맥락 | 회의록 정리 예시로 실행 항목 형식, 결정과 논의 분리, 민감 정보 제외, 문체, 후속 질문이 반복 기준임을 보여 준다. | 반복되는 프롬프트 요소를 업무 기준 후보로 추출한다. |
| 반복 설명 후보 표 | 출력 형식, 판단 기준, 금지 사항, 문체 기준, 참고 자료를 위키 후보로 정리한다. | 첫 위키 후보를 감이 아니라 반복 기준 목록으로 고른다. |
| 대화 기록과 업무 지식의 차이 | 대화 기록은 시간순 흔적이고 업무 지식은 주제별로 정리된 확인 사실, 기준, 결정, 근거라고 구분한다. | 대화 로그를 raw 후보로 두고 wiki 문서로 다시 컴파일한다. |
| 첫 위키 후보 고르기 | 작고 반복되는 업무를 첫 주제로 고르고 세 가지 이상 조건에 맞으면 후보로 표시한다. | 4장에서 실제 주제 위키로 이어질 범위를 정한다. |
상세 분석
1. 지식이 남지 않는 이유는 기준 미분리다
좋은 답변을 받았더라도 그 답변을 가능하게 한 출력 형식, 금지 사항, 판단 기준, 독자, 문체가 대화창 안에만 있으면 다음 업무에서 재사용하기 어렵다. 이때 프롬프트를 더 길게 쓰는 것은 근본 해결이 아니다. 반복 기준을 wiki 문서로 옮기고, 다음 질문에서 문서화된 기준을 참조하게 해야 한다.
| 증상 | 실제 모습 | 1.1 기준의 해석 | 대응 |
|---|---|---|---|
| 같은 배경 설명 반복 | 매주 회의록 정리 때 같은 표 구조와 제외 정보를 다시 쓴다. | 업무 기준이 프롬프트 안에서 소비되고 있다. | 기준 문서를 wiki/ 후보로 만든다. |
| 답변 품질 흔들림 | 배경을 길게 쓴 날과 짧게 쓴 날의 결과가 다르다. | LLM이 안정적으로 참조할 문서화된 기준이 없다. | 출력 형식과 판단 기준을 분리한다. |
| 과거 결정 재논의 | 이미 정한 예외 규칙을 다시 물어본다. | 결정 이력이 기준 문서나 로그로 남지 않았다. | 결정, 이유, 근거, 확인 필요를 기록한다. |
2. 반복 맥락은 위키 후보 판정 신호다
회의록 정리 요청에 따라붙는 실행 항목 열, 결정과 논의의 구분, 민감 정보 제외, 공유 대상에 맞는 문체, 다음 회의 질문 같은 기준은 좋은 프롬프트의 재료다. 그러나 반복해서 쓰이면 프롬프트 조각이 아니라 위키 후보가 된다.
| 반복 맥락 | 위키 문서에 남길 내용 | 검증 질문 |
|---|---|---|
| 출력 형식 | 필수 섹션, 표 열, 정렬 기준, 예시 출력 | 이 형식을 다음 작업에서도 그대로 써야 하는가? |
| 판단 기준 | 우선순위, 분류 규칙, 예외 처리, 승인 기준 | 좋은 답과 나쁜 답을 가르는 기준이 명확한가? |
| 금지 사항 | 개인정보, 계약 금액, 내부 명칭, 금지 표현 | 산출물에 들어가면 안 되는 정보가 문서화되어 있는가? |
| 문체 기준 | 독자, 톤, 결론 우선 여부, 상세도 | 독자가 바뀌면 같은 위키에서 다른 output을 만들어야 하는가? |
| 참고 자료 | 원천 파일, URL, 보고서, 확인일 | 답변 근거로 돌아갈 수 있는가? |
| 결정 이력 | 결정일, 검토 범위, 보류 이유 | 같은 결정을 반복해서 논의하지 않게 하는가? |
3. 대화 기록은 raw, 업무 기준은 wiki다
대화 기록은 무엇을 물었고 어떤 기준을 수정했는지 보여 주는 원천 자료가 될 수 있다. 다만 시간순 대화에는 임시 답변, 잘못된 가정, 사용자의 교정, 최종 기준이 섞인다. 그러므로 그대로 업무 지식으로 쓰지 말고 채택 여부, 확인일, 상태, 예외 규칙, 출력 형식, 확인 필요를 분리해야 한다.
| 대화 안의 요소 | 보존 위치 | 재구성 방식 |
|---|---|---|
| 원래 질문과 업무 배경 | raw/ 또는 source note | 질문 맥락과 날짜를 남긴다. |
| LLM의 중간 답변 | raw/ 후보 | 채택 여부를 표시하기 전에는 기준으로 쓰지 않는다. |
| 사용자의 수정 요청 | wiki/의 예외 규칙 또는 확인 필요 | 수정 이유와 적용 범위를 분리한다. |
| 채택된 기준 | wiki/의 확인된 내용 | 근거와 확인일을 붙인다. |
| 남은 불확실성 | wiki/의 확인 필요, log.md | 담당자 검토, 최신성 확인, 운영 기준 확인으로 남긴다. |
| 산출물 초안 | output/ | 목적, 독자, 근거 링크를 붙인다. |
4. 첫 위키 후보는 세 가지 이상의 신호가 있을 때 고른다
위키는 대화 보관함이 아니라 지식을 구조화하는 장치다. 모든 반복 대화를 위키로 만들면 문서가 빠르게 커지고 질문 범위가 흐려진다. 반복 질문이 업무 절차, 판단 기준, 출력 형식, 금지 사항, 근거 자료, 결정 이력에서 생기는지 확인하고, 세 가지 이상 신호가 맞을 때 첫 후보로 둔다.
- 자주 묻는 업무가 있는지 확인한다.
- 같은 배경 설명이 반복되는지 본다.
- 판단 기준이나 출력 형식이 있는지 확인한다.
- 출처나 확인일이 중요한지 확인한다.
- 단순 반복이면 프롬프트 템플릿, 기준이 있는 반복이면 작은 업무 규칙 문서, 기준과 출처가 함께 중요하면 LLM위키 후보로 둔다.
실무 적용 절차
- 최근 1주일 동안 LLM에게 요청한 업무 3개를 실제 대화 제목, 날짜, 결과물 유형과 함께 적는다.
- 각 요청에서 다시 설명한 맥락을 출력 형식, 판단 기준, 금지 사항, 문체 기준, 참고 자료, 결정 이력으로 분류한다.
- 각 맥락이 다음에도 필요한지 낮음, 중간, 높음으로 표시한다.
- 반복 맥락이 단순 말투인지 업무 기준인지 나눈다.
- 대화 기록이 있으면
raw후보로 보존하고, 대화 기록 자체를 확정 업무 지식으로 부르지 않는다. - 대화에서 채택한 기준, 버린 제안, 남은 확인 필요를 분리한다.
- 한 문장 요약, 근거, 확인된 기준, 예외 규칙, 출력 형식, 확인 필요, 다음 질문을 가진 위키 문서 후보 초안을 만든다.
- 첫 후보를 하나만 고르고, 반복성, 배경 설명 의존, 합의 기준, 출처와 확인일 중요성, 다음 달 재사용 가능성 중 세 가지 이상에 해당하는지 본다.
- 후보가 너무 크면 “업무 자동화 전체”가 아니라 “주간 회의록 실행 항목 정리 기준”처럼 줄인다.
- 민감 정보가 포함된 경우 원문을 그대로 옮기지 않고 고객명, 계약 금액, 개인 연락처, 내부 금액은 제외 또는 익명화 기준을 먼저 둔다.
index.md에 첫 후보와 핵심 질문을 남기고,log.md에 후보를 고른 이유와 확인 필요를 기록한다.- 다음 절로 넘어가기 전에 이 후보가 왜 LLM위키 후보인지 한 문장으로 설명한다.
실무 템플릿
반복 맥락 탐지표
| 업무 | 다시 설명한 맥락 | 유형 | 다음에도 필요한가 | 처리 |
|---|---|---|---|---|
| 주간 회의록 정리 | 실행 항목은 담당자, 기한, 확인 방법으로 분리 | 출력 형식 | 높음 | wiki 후보 |
| 임원 보고서 초안 | 결론을 먼저 쓰고 근거는 뒤에 둔다 | 문체 기준 | 높음 | wiki 후보 |
| 문장 자연스럽게 고치기 | 부드러운 표현으로 바꾼다 | 말투 | 중간 | 프롬프트 템플릿 후보 |
첫 위키 후보 판정표
| 판정 기준 | 예/아니오 | 확인 메모 |
|---|---|---|
| 같은 설명을 두 번 이상 했다. | ||
| 답변 품질이 배경 설명의 양에 크게 달라졌다. | ||
| 팀, 고객, 제품, 보안과 합의한 기준이 들어간다. | ||
| 출처나 확인일이 중요하다. | ||
| 다음 달에도 같은 방식으로 다시 쓸 가능성이 있다. | ||
| 주제가 작고 첫 자료 3-5개로 시작할 수 있다. |
대화 기록을 업무 지식으로 바꾸는 문서 골격
# 업무 기준 문서 제목 ## 원천 - 원천 대화 또는 자료: - 확인일: - 상태: 초안 / 검토 중 / 운영 기준 / 폐기 ## 한 문장 요약 - 이 문서는 어떤 반복 업무 기준을 다루는가. ## 확인된 기준 - 원천에서 확인된 기준만 적는다. ## 예외 규칙 - 자주 빠지는 조건과 예외를 적는다. ## 출력 형식 - 다음 요청에서 그대로 참고할 형식을 적는다. ## 제외할 정보 - 개인정보, 고객명, 계약 금액, 내부 금액, 비공개 코드를 적는다. ## 확인 필요 - 담당자 검토, 최신 기준, 실제 운영 적용 여부를 적는다. ## 다음 질문 - 이 문서를 읽힌 뒤 던질 수 있는 다음 업무 질문을 적는다.
검증 체크리스트
- 최근 LLM 요청 3개에서 반복된 업무 맥락을 뽑았다.
- 반복 맥락을 출력 형식, 판단 기준, 금지 사항, 문체 기준, 참고 자료, 결정 이력으로 분류했다.
- 대화 기록과 업무 지식을 구분했다.
- 대화 기록은
raw후보로 두고, 확인된 기준은wiki문서 후보로 분리했다. - 확인일, 상태, 원천 위치, 남은 확인 필요를 남겼다.
- 고객명, 계약 금액, 개인 연락처, 내부 금액 같은 제외 정보가 문서에 명시되어 있다.
- 첫 후보가 회사 전체 지식베이스처럼 크지 않다.
- 단순 말투 취향이나 일회성 요청을 과하게 위키 후보로 승격하지 않았다.
- 위키 후보를 고른 이유가 반복성, 기준성, 출처 필요성과 연결된다.
좋은 질문과 사람 검증 질문
LLM에게 던질 질문
- 최근 LLM 요청 3개를 기준으로 반복 설명한 업무 맥락을 출력 형식, 판단 기준, 금지 사항, 문체 기준, 참고 자료로 나누어 주세요.
- 아래 대화 기록에서 업무 지식으로 남길 기준만 뽑아 주세요. 채택한 기준, 버린 제안, 예외 규칙, 확인 필요, 다음 질문을 분리해 주세요.
- 이 후보가 LLM위키 후보인지 반복 설명, 판단 기준, 출력 형식, 출처 필요성, 다음 달 재사용 가능성으로 평가해 주세요.
사람이 확인할 질문
- 이 문서는 대화 기록을 그대로 요약한 것인가, 업무 기준으로 재구성한 것인가?
- 어떤 문장이 원천 대화, 회의록, 보고서, 공식 문서에서 확인되는가?
- 이 기준을 다음 요청에서 참고시키면 배경 설명이 실제로 줄어드는가?
- 민감 정보가 들어간 대화를 원천 후보로 둘 때 저장 위치와 접근 권한이 안전한가?