4.1 업무 주제 정하기 원문 기반 심화 분석

핵심 요약

4.1의 핵심은 첫 LLM위키 주제를 회사 업무 전체, 마케팅 지식 전체, 개발 문서 전체 같은 넓은 관심사가 아니라 작게 검증할 수 있는 업무 질문으로 바꾸는 것이다. 큰 주제는 자료 수집과 질문 설계를 흐리게 만들고, 첫 실습의 성공 여부를 판단하기 어렵게 한다.

첫 주제는 다음 주에 실제로 쓸 업무, 3-5개 원천 자료로 시작 가능한 범위, 사람이 확인할 수 있는 산출물을 동시에 만족해야 한다. 이 조건은 첫 위키를 지식 창고가 아니라 반복 질문을 짧고 정확하게 만드는 작은 작업 공간으로 제한한다.

자료 선택은 양보다 성격이 중요하다. 최근 회의록, 고객 문의 목록, 공식 문서 일부, 반복 보고서 양식은 적합한 후보지만 오래된 대화 전체, 기억에 의존한 요약, 민감 정보가 그대로 있는 문서는 보류하거나 익명화해야 한다.

성공 기준은 문서 수가 아니라 다음 업무가 쉬워졌는지로 잡는다. 예를 들어 회의록 3개를 넣었다보다 다음 회의 준비 때 실행 항목의 담당자, 기한, 확인 방법을 빠르게 찾을 수 있다는 기준이 더 좋다.

원문 구조와 실무 의미

상세 분석

1. 실습 환경을 실제 업무 질문으로 바꾸는 절

3.3까지는 raw, wiki, output, index.md, log.md, AGENTS.md 또는 CLAUDE.md 같은 실습 환경의 책임을 고정한다. 4.1은 그 환경에 아무 자료나 넣지 않도록 첫 업무 주제를 제한한다. LLM위키는 원천 자료를 보존하고, LLM이 읽기 쉬운 위키 문서로 정리하며, 출처와 점검 기준을 남기는 패턴이므로 첫 주제도 많이 아는 분야가 아니라 작게 검증 가능한 분야여야 한다.

주제가 넓으면 자료가 많아지고, 자료가 많아지면 raw와 wiki의 경계가 흐려지고, 질문이 넓어지면 output은 일반론으로 흐른다. 반대로 주제가 작으면 원천 자료, 첫 질문, 성공 기준, 실패 신호가 한 번에 연결된다.

2. 작다는 말은 사소하다는 뜻이 아니다

작은 주제는 나중에 확장할 수 있다. 처음부터 전사 지식베이스를 만들지 않아도 회의록 실행 항목 정리 위키가 안정화되면 보고서 작성 기준, 고객 문의 분류 기준, 릴리스 노트 작성 기준으로 확장할 수 있다. 이 확장은 8.3 주제가 늘어날 때 관리하기의 주제 분리 기준으로 다시 판단해야 한다.

3. 세 가지 질문은 주제 축소 게이트다

예를 들어 AI로 업무 효율화하기는 너무 크다. 이를 주간 회의록에서 할 일과 담당자를 정리하기로 줄이면 최근 회의록 3개가 원천 자료가 되고, 실행 항목에 담당자, 기한, 확인 방법이 있는지로 결과를 검증할 수 있다.

4. 첫 자료는 raw의 신뢰 경계를 만든다

첫 자료가 부적합하다는 말은 영원히 쓸 수 없다는 뜻이 아니다. 처음에는 짧고 확인 가능한 자료로 raw/wiki 경계를 익히고, 민감하거나 넓은 자료는 5.1 자료를 넣기 전에 정할 기준과 8장의 감사 루틴을 갖춘 뒤 다뤄야 한다.

5. 민감 정보 처리는 실습용 복사본 분리다

6. 성공 기준은 자료 선택과 첫 질문을 역산하게 한다

흔한 실패와 수정 방향

실무 적용 절차

1. 큰 업무 영역을 하나 적는다. 예: 고객 지원 개선, 회의 운영 개선, 주간 보고 자동화, 개발 온보딩 정리.
2. 그 영역에서 다음 주 안에 실제로 쓸 업무를 하나 고른다. 실제 일정이나 반복 주기가 없으면 나중 후보로 보류한다.
3. 업무를 한 번의 질문으로 바꾼다. 질문에는 자료 범위, 결과물 목적, 출력 형식이 들어가야 한다.
4. 원천 자료 후보를 3-5개로 제한한다. 회의록, 문의 목록, 공식 문서, 기존 양식, 업무 메모 중 다시 확인 가능한 자료를 고른다.
5. 각 자료에 날짜, 출처, 자료 성격, 사용 이유, 주의할 점을 붙인다.
6. 자료 후보 중 민감 정보가 있는 항목을 표시한다. 고객명, 이메일, 계약 조건, 내부 금액, 비공개 코드가 있으면 첫 실습에서 제외하거나 익명화한다.
7. 기억에 의존한 메모와 LLM 답변은 확정 raw가 아니라 확인 필요 자료로 둔다.
8. 첫 성공 기준을 문서 수가 아니라 업무 행동으로 쓴다.
9. 실패 신호를 함께 쓴다. 예: 출처 없는 실행 항목, 논의 중인 내용을 결정 사항처럼 쓰기, 담당자 없는 일을 완료 가능한 항목으로 쓰기.
10. 주제, 원천 자료 후보, 첫 질문, 성공 기준, 실패 신호를 한 장 카드로 만든다.
11. 이 카드가 4.2의 폴더 초기화에 필요한 이름, index.md 핵심 질문, AGENTS.md 작업 규칙을 제공하는지 확인한다.
12. 첫 질문이 4.3 기준을 만족하는지 본다. 사용할 자료 범위, 결정 목적, 출력 형식, 근거 요청, 확인 필요 표시가 있어야 한다.
13. 자료가 부족하면 주제를 더 줄이거나 첫 자료를 다시 고른다. 좋은 질문만으로 자료 부족을 해결하려 하지 않는다.
14. 실제 업무 자료를 넣기 전 실습용 복사본과 운영 원본을 구분한다.
15. 주제 선택 결과를 log.md에 남길 문장으로 정리한다.

실무 템플릿

첫 위키 주제 축소 카드

원천 자료 후보표

첫 질문 템플릿

현재 위키의 원천 자료 후보 [자료 1], [자료 2], [자료 3]만 기준으로,
[첫 위키 주제]에 필요한 [산출물 형식]을 만들어 주세요.
각 핵심 항목에는 근거 자료 위치를 붙이고,
자료에서 확인되지 않는 내용은 확인 필요로 표시해 주세요.
결과는 [표/목록/보고서 초안/실행 항목] 형식으로 작성해 주세요.

첫 위키 성공 기준 카드

검증 체크리스트

좋은 질문과 사람이 확인할 질문

LLM에게 던질 좋은 질문

• 아래 큰 업무 영역을 첫 LLM위키 주제로 줄여 주세요. 다음 주 실제 사용 여부, 원천 자료 3-5개 가능 여부, 결과 검증 가능 여부를 기준으로 후보 3개와 보류 이유를 표로 작성해 주세요.
• 아래 자료 후보 목록을 첫 위키 자료로 평가해 주세요. 각 자료를 raw 후보, 익명화 후 사용, 발췌 필요, 보류로 나누고 이유와 확인 필요를 표시해 주세요.
• 이 첫 위키 주제의 성공 기준을 문서 수가 아니라 업무 행동 기준으로 바꿔 주세요. 통과 기준과 실패 신호를 함께 제안해 주세요.
• 아래 첫 질문이 너무 넓은지 점검해 주세요. 자료 범위, 출력 형식, 근거 요청, 확인 필요 표시가 빠졌는지 알려 주세요.
• 이 주제 선택 카드가 4.2의 index.md, log.md, AGENTS.md 초기화에 충분한지 확인하고 부족한 항목을 표시해 주세요.

사람이 확인할 검증 질문

• 이 주제는 내가 관심 있는 분야인가, 다음 주에 실제로 쓸 업무인가?
• 이 질문에 답하려면 지금 가진 자료 3-5개로 충분한가?
• 산출물이 나오면 잘됐는지 사람이 직접 확인할 수 있는가?
• 성공 기준이 담당자, 기한, 유형, 근거, 확인 방법처럼 관찰 가능한가?
• 자료에 민감 정보가 있는가, 있다면 실습용 복사본과 운영 원본을 분리했는가?
• 원천 자료와 LLM이 만든 정리 문서를 같은 위치에 섞으려 하고 있지 않은가?
• 첫 답변을 받은 뒤 어떤 문장을 위키에 반영하고 어떤 문장을 확인 필요로 남길지 계획이 있는가?

관련 문서

• 4장. 첫 번째 주제 위키 만들기: 4.1의 주제 선택을 장 전체 실습 흐름에 배치한다.
• 3.3 이 책의 실습 환경 정하기: 실습 폴더, 도구, 규칙 파일, 보안 기준을 먼저 고정한다.
• 4.2 위키 초기화하기: 4.1에서 고른 주제를 raw/, wiki/, output/, index.md, log.md, AGENTS.md 구조로 만든다.
• 4.3 첫 질문으로 방향 잡기: 주제, 자료 범위, 성공 기준을 첫 위키 질문으로 변환한다.
• 2.2 좋은 폴더 구조 이해하기: 주제 폴더를 중심 질문, 독자, 보안 범위, 산출물 목적 기준으로 나누는 근거를 제공한다.
• 2.3 좋은 위키 문서의 조건: 첫 주제에서 만들 wiki 문서가 출처, 재사용성, 링크를 갖춰야 하는 이유를 설명한다.
• 5.1 자료를 넣기 전에 정할 기준: 4.1의 자료 후보를 실제 수집 기준 카드로 확장한다.
• 5.2 자료 수집하기: 웹 문서, 회의록, 업무 메모를 원천 카드로 만드는 절차를 제공한다.
• 6.1 좋은 질문 만들기: 첫 질문이 검색 질문이 아니라 업무 질문이 되도록 경계를 넣는다.
• 6.2 답변의 근거 확인하기: 첫 답변을 문장별 근거와 확실성 등급으로 검증한다.
• 7.3 다음 행동으로 연결하기: 성공 기준을 담당자, 기한, 완료 기준이 있는 실행 항목으로 연결한다.
• 8.3 주제가 늘어날 때 관리하기: 첫 주제 이후 새 주제를 기존 위키에 넣을지 분리할지 판단한다.

한계와 확인 필요

• 이 문서는 2026-06-06 KST에 WikiDocs 원문을 직접 열람해 작성된 Markdown 분석을 HTML로 변환한 것이다. 원문 자체의 최신 수정 여부와 세부 표현은 WikiDocs 원문에서 다시 확인해야 한다.
• 원문이 제시한 외부 참고 자료인 Karpathy LLM Wiki Gist, nvk/llm-wiki, OpenAI Codex AGENTS.md, Anthropic Claude Code memory 문서는 원문 확인일 기준이다. 실제 도구 사용 전 현재 README, Releases, 공식 문서, 설치된 도움말을 다시 확인해야 한다.
• 4.1의 예시는 학습용이다. 실제 고객 문의, 회의록, 계약 자료, 코드 작업 기록에는 조직별 보안 정책, 접근 권한, 외부 LLM 전송 기준이 적용될 수 있다.
• 작게 시작한다는 원칙은 자료를 대충 보라는 뜻이 아니다. 첫 자료가 적어도 날짜, 출처, 자료 성격, 사용 이유, 주의할 점은 남겨야 한다.
• 성공 기준은 첫 주제의 가설이다. 첫 답변과 근거 검증 결과에 따라 성공 기준 자체를 log.md에 기록하고 수정할 수 있어야 한다.

이 절의 완료 기준

1. 큰 업무 영역을 첫 위키 주제로 바로 쓰지 않고, 한 번의 업무 질문으로 줄였다.
2. 첫 원천 자료 후보를 3-5개로 제한하고 각 자료의 날짜, 출처, 성격, 사용 이유, 주의할 점을 적었다.
3. 민감 정보가 있는 자료를 익명화, 발췌, 보류 중 하나로 처리했다.
4. 첫 질문에 자료 범위, 산출물 목적, 출력 형식, 근거 요청, 확인 필요 표시가 들어간다.
5. 성공 기준이 문서 수가 아니라 다음 업무 행동으로 쓰였다.
6. 실패 신호를 미리 적어 첫 답변을 검증할 수 있게 했다.
7. 4.2에서 초기화할 폴더 이름과 index.md, log.md, AGENTS.md의 초기 내용을 이 주제 카드에서 뽑을 수 있다.
8. 4.3 첫 질문과 6.2 근거 검증으로 이어질 준비가 되어 있다.