7장. 위키에서 업무 산출물 만들기

원문과 확인 범위

이 페이지는 장 랜딩 페이지와 세 하위 절을 함께 읽어 장 수준으로 재구성한 HTML 산출물이다. 장 랜딩은 하위 절 목록 중심의 짧은 입구이므로, 실제 방법론은 7.1의 목적 정의, 7.2의 주장-근거 보고서화, 7.3의 실행 항목과 후속 반영 루프를 결합해야 완성된다.

장 원문: 7장. 위키에서 업무 산출물 만들기
원천 도서: LLM위키 완벽 가이드
하위 원문: 7.1 산출물의 목적 정하기, 7.2 업무 보고서 만들기, 7.3 다음 행동으로 연결하기
참고 자료: Andrej Karpathy LLM Wiki Gist, nvk/llm-wiki, nvk/llm-wiki Releases, OpenAI Codex AGENTS.md 문서, Anthropic Claude Code memory 문서, WiCER

장 수준 핵심 흐름은

목적 정의 → 주장과 근거 연결 → 검토 가능한 보고서 작성 → 실행 항목 추출 → 회의와 결정 반영 → output과 wiki 연결 유지

다.

원문 구조

원문	역할	핵심	다음 단계 산출물
7장 랜딩	산출물 장의 입구	7.1, 7.2, 7.3으로 구성됨을 안내한다.	세부 절을 순서대로 읽어 목적, 보고서, 실행 루프를 만든다.
7.1 산출물의 목적 정하기	목적과 독자 고정	요약, 보고서, 실행 계획의 차이와 `output/` 분리를 다룬다.	산출물 목적 한 줄 정의, 독자별 틀, 파일명과 근거 기준
7.2 업무 보고서 만들기	주장-근거 보고서화	핵심 주장, 근거 문서, 원천 자료, 확인 날짜, 확신도를 연결한다.	주장-근거 매트릭스, 보고서 뼈대, 검토 질문, 후속 과제
7.3 다음 행동으로 연결하기	실행 항목과 회의 루프	보고서를 담당자, 기한, 완료 기준, 근거가 있는 실행 항목으로 바꾼다.	실행 항목 표, 회의 준비 자료, 문서 정보 블록, 최신성 상태

세 절은 순서가 중요하다. 7.1 없이 산출물을 만들면 위키 내용을 모두 넣은 긴 문서가 되기 쉽다. 7.2 없이 보고서를 만들면 결론과 근거와 추정이 섞인다. 7.3 없이 제출하면 결정과 실행 결과가 다시 위키에 남지 않아 같은 맥락을 반복하게 된다.

장 수준 합성

1. 산출물은 위키 내용을 많이 보여 주는 문서가 아니다

7.1은 산출물의 이름보다 목적을 먼저 묻는다. 요약은 빠른 이해를 돕고, 보고서는 판단을 돕고, 실행 계획은 행동을 만든다. 같은 위키라도 임원에게는 리스크와 결정 요청이 앞에 있는 보고서가, 팀장에게는 실행 계획이, 실무자에게는 체크리스트가 필요할 수 있다.

항목	작성할 내용	실패 신호
산출물 목적	빠른 이해, 판단과 승인, 실행 중 무엇인지	보고서라고 부르지만 실제로는 할 일 목록이 필요하다.
읽는 사람	임원, 팀장, 실무자, 리뷰어, 외부 협력사 등	내부 작업 로그를 임원 보고서처럼 길게 넣는다.
읽은 뒤 행동	승인, 보류, 담당자 지정, 작업 수행, 검토 의견 제공	읽은 뒤 무엇을 해야 하는지 알 수 없다.
포함/제외 항목	목표, 범위, 근거, 리스크, 일정, 성공 기준을 고르고 불필요한 배경을 뺀다.	위키에 있는 모든 내용을 넣는다.
저장 위치	`output/YYYY-MM-DD-purpose.md`처럼 날짜와 목적을 드러낸다.	산출물이 `wiki/` 정리 문서와 섞인다.

2. `output/`은 결과물 분리, 이력, 검토를 위한 작업 공간이다

raw/는 원천 자료, wiki/는 파생 지식, output/은 공유하거나 실행에 쓰는 결과물이다. 이 세 공간이 섞이면 원본, 정리본, 초안, 최종본, 결정 기록이 뒤엉킨다. output 문서는 나중에 참고 대상이 될 수 있지만 원본은 아니며, 산출물에서 새 결정이 생기면 별도 결정 문서나 관련 위키 문서에 근거와 날짜를 붙여 반영해야 한다.

output 문서에는 문서 목적, 생성 날짜, 근거 위키, 원천 자료, 확인 필요, 후속 반영 위치를 최소 정보로 남긴다.

3. 보고서는 주장-근거 매트릭스에서 시작한다

7.2의 보고서는 그럴듯한 글이 아니라 검토자가 판단할 수 있는 문서다. 첫 품질 기준은 문체가 아니라 “왜 그렇게 말할 수 있는가”에 답할 수 있는지다. 핵심 주장 후보마다 근거 문서, 원천 자료, 확인 날짜, 확신도, 보고서 표현을 붙이고, 확신도가 낮은 내용은 조건부 표현이나 확인 필요로 내려야 한다.

주장 후보	근거 위치	확신도	보고서 표현	처리
특정 문의 유형이 1차 실험 후보다	`wiki/automation-priority.md`, 회의 raw	중간	현재 자료 기준으로 1차 검토 후보로 제안한다.	결론 후보
자동 답변은 위험이 크다	`wiki/automation-risk.md`	중간	검수 기준이 정리될 때까지 보류한다.	쟁점과 위험
비용 절감 효과가 크다	현재 원천 없음	낮음	비용 효과는 별도 측정이 필요하다.	확인 필요
2주 파일럿을 진행할 수 있다	회의 메모와 실행 조건	중간	범위를 좁히면 실행 가능성이 있다.	다음 행동 후보

4. 검토자 흐름은 결론, 근거, 쟁점, 요청 순서로 설계한다

보고 목적: 왜 이 문서를 읽어야 하는가.
핵심 결론: 현재 자료 기준으로 무엇을 제안하거나 보류하는가.
근거 요약: raw와 wiki에서 확인한 내용은 무엇인가.
쟁점과 위험: 무엇을 단정하면 안 되는가.
제안하는 다음 행동: 승인, 보류, 파일럿, 추가 조사 중 무엇을 요청하는가.
확인 필요: 수치, 최신성, 정책, 책임 범위, 담당자 미정 항목은 무엇인가.
근거: 위키 문서와 원천 자료의 경로 또는 URL은 무엇인가.

5. 초안은 제출 문서가 아니라 검토 가능한 상태로 다듬는 재료다

초안에는 LLM 표현, 근거 있는 내용, 추정, 확인 필요가 섞여 있을 수 있다. 검토용 문서로 다듬을 때는 문장을 화려하게 만드는 것보다 결정할 일, 판단의 근거, 아직 확인하지 못한 내용을 보이게 해야 한다. 검토 후 최종 보고서는 output/에 남기고, 결정 사항은 wiki/decisions/ 같은 결정 문서로, 추가 확인 과제는 질문 목록이나 관련 주제 문서로 보낸다.

6. 실행 항목은 담당자, 기한, 완료 기준, 근거가 있어야 한다

“우선순위를 높일 필요가 있다”는 방향일 뿐 행동이 아니다. 실행 항목은 누가, 무엇을, 언제까지, 어떤 완료 기준으로, 어떤 근거를 보고 끝낼지 보여야 한다. 담당자와 기한이 근거에 없으면 임의로 단정하지 않고 미정 또는 회의 결정 항목으로 남긴다.

상태	실행 항목	담당자	기한	완료 기준	처리 기준
실행 후보	근거가 있고 바로 계획할 수 있는 일	이름 또는 미정	날짜 또는 미정	결과물의 모양이 분명하다	회의에서 담당자와 기한 확정
확인 필요	근거가 약하거나 최신성이 필요한 일	미정 가능	미정 가능	확인할 문서나 담당 부서가 분명하다	실행하지 말고 자료 확인
검토 요청	다른 팀의 판단이 필요한 일	담당 부서	요청 기한	가능/불가와 조건이 기록된다	요청 문서 또는 회의 안건으로 전환

7. 회의 준비 자료는 요약이 아니라 결정을 좁히는 문서다

회의 준비 자료의 목적은 “무슨 일이 있었는가”를 길게 설명하는 것이 아니라 “무엇을 결정해야 하는가”를 좁히는 것이다. 회의 목적, 참석자, 사전 읽기 자료, 결정할 것, 확인 필요, 예상 질문, 회의 후 위키 반영 위치를 포함해야 하며 결정할 항목은 가능하면 3개 이하로 줄인다.

8. 산출물과 위키의 연결은 최신성 관리까지 포함한다

산출물은 특정 시점의 결과물이므로 시간이 지나면 더 조심해야 한다. 정책, 일정, 담당자, 제품 상태, 회계 기준, 보안 기준은 바뀔 수 있다. 따라서 작성일, 마지막 검토일, 다음 검토 필요일, 최신성 주의 항목을 남기고 8장의 감사 루틴으로 재검토해야 한다.

AGENTS.md나 CLAUDE.md에 산출물 규칙을 둘 수 있지만, 이 파일들은 결과 품질이나 보안을 자동으로 강제하지 않는다. 산출물이 raw 보존, 근거 표시, 확인 필요, 후속 반영, 최신성 상태를 지켰는지는 사람이 검토해야 한다.

근거 위치 요약

핵심 주장	근거 위치	적용 판단
산출물은 위키 내용을 그대로 복사하는 것이 아니라 독자의 행동에 맞게 재배열해야 한다.	7.1 요약/보고서/실행 계획의 차이, 산출물 선택 흐름	목적, 독자, 읽은 뒤 행동을 먼저 정한다.
`output/`은 산출물 분리와 이력 관리를 위한 공간이다.	7.1 output 폴더를 쓰는 이유	공유/실행 문서는 output에 두고 raw/wiki와 섞지 않는다.
보고서는 주장마다 근거 문서, 원천 자료, 확인 날짜, 확신도를 가져야 한다.	7.2 핵심 주장과 근거 연결하기	보고서 작성 전 주장-근거 매트릭스를 만든다.
초안은 검토용 문서로 다듬어야 하며 검토 결과는 다시 위키에 남겨야 한다.	7.2 초안을 검토용 문서로 다듬기	최종 보고서, 결정 사항, 추가 확인 과제를 각각 분리한다.
실행 항목은 담당자, 기한, 완료 기준, 근거가 있어야 한다.	7.3 보고서에서 할 일 뽑기	근거가 약한 항목은 실행 후보가 아니라 확인 필요로 둔다.
회의 준비 자료는 요약이 아니라 결정 항목을 좁히는 문서다.	7.3 회의 자료는 결정 중심으로 구성하기	결정할 항목을 줄이고 후속 반영 위치를 남긴다.
산출물은 특정 시점의 결론이므로 최신성 상태를 남겨야 한다.	7.3 산출물과 위키의 연결 유지하기	작성일, 검토일, 다음 검토일, 최신성 주의를 표시한다.

실무 적용 절차

6장에서 검증한 답변이나 위키 문서 중 산출물로 바꿀 범위를 고른다.
산출물 목적을 빠른 이해, 판단과 승인, 실행 중 하나로 고른다.
읽는 사람과 읽은 뒤 행동을 한 문장으로 쓴다.
포함할 항목과 제외할 항목을 나눈다.
산출물 파일 위치와 이름을 output/YYYY-MM-DD-topic-purpose.md처럼 정한다.
사용할 wiki/ 문서와 raw/ 원천 자료를 지정한다.
보고서형 산출물이라면 주장 후보를 뽑고 근거 위치, 근거 성격, 확인 날짜, 확신도, 보고서 표현을 붙인다.
근거가 약한 주장, 출처 없는 수치, 최신 정책, 책임 범위는 확인 필요로 내린다.
보고 목적, 핵심 결론, 근거 요약, 쟁점과 위험, 다음 행동, 확인 필요, 근거 순서로 재배치한다.
초안을 검토용 문서로 다듬고 근거 표시, 확인 필요 분리, 검토 질문, 결정 요청을 추가한다.
실행 항목 후보마다 담당자, 기한, 완료 기준, 근거를 붙인다.
담당자와 기한이 근거에 없으면 임의로 만들지 말고 미정 또는 회의 결정 항목으로 표시한다.
회의가 필요하면 목적, 사전 읽기 자료, 결정할 것, 확인 필요, 예상 질문, 회의 후 위키 반영을 넣는다.
검토나 회의 후 최종 보고서는 output에 두고, 결정 사항은 결정 문서에, 추가 확인은 질문 목록 또는 관련 위키 문서에 반영한다.
오래된 산출물에는 마지막 검토일과 다음 검토 필요일을 붙이고 8장 감사 루틴에 넣는다.

체크리스트와 템플릿

산출물 목적 한 줄

위키 주제, 산출물 형식, 읽는 사람, 읽은 뒤 행동, 포함할 항목, 제외할 항목, 저장 위치를 한 표에 적는다. 이 표만 보고 LLM에게 초안을 요청할 수 있어야 한다.

주장-근거 매트릭스

핵심 주장은 3-5개 이하로 좁히고, 각 주장에 wiki 근거와 가능한 raw 근거를 붙인다. 확신도가 낮은 주장은 조건부 표현이나 확인 필요로 낮춘다.

보고서 기본 뼈대

보고 목적, 핵심 결론, 근거 요약, 쟁점과 위험, 제안하는 다음 행동, 확인 필요, 근거를 포함한다.

회의 준비 자료

회의 목적, 참석자, 사전 읽기 자료, 결정할 것, 확인 필요, 예상 질문, 회의 후 위키 반영 위치를 정한다.

문서 정보 항목	적을 내용	주의
문서 목적	어떤 결정이나 실행을 위한 문서인가	목적이 없으면 산출물 형식이 흐려진다.
생성 날짜	언제 만든 판단인가	날짜 없이는 최신성 판단이 어렵다.
작성 기준	회의록, 위키 문서, 원문 URL	근거가 없으면 단정문으로 쓰지 않는다.
상태	초안, 검토용, 공유본, 보관본	검토용 문서를 최종본처럼 쓰지 않는다.
근거와 원천	`wiki/...`, `raw/...`, 원문 URL	핵심 주장은 원천으로 돌아갈 수 있어야 한다.
확인 필요	최신 정책, 수치, 담당자, 승인 범위	본문 결론과 섞지 않는다.
후속 반영 위치	갱신할 위키, 결정 로그, action plan	회의 후 어디를 바꿀지 미리 정한다.

검증 질문

이 산출물은 요약, 보고서, 실행 계획, 회의 준비 자료 중 무엇인가?
읽는 사람이 누구이며, 읽은 뒤 무엇을 해야 하는가?
포함할 항목과 제외할 항목이 독자의 행동 기준으로 정해졌는가?
핵심 주장마다 wiki/ 문서와 raw/ 원천 자료로 돌아갈 수 있는가?
확인되지 않은 수치, 효과, 최신 정책, 책임 범위를 보고서 결론처럼 쓰지 않았는가?
보고서에 보고 목적, 핵심 결론, 근거 요약, 쟁점과 위험, 다음 행동, 확인 필요, 근거가 있는가?
실행 항목에 담당자, 기한, 완료 기준, 근거가 있는가?
근거가 약한 항목을 실행 항목에 섞지 않고 확인 필요나 검토 요청으로 분리했는가?
회의 준비 자료가 단순 요약이 아니라 결정할 항목을 좁히는 문서인가?
회의 후 어떤 위키 문서, 결정 로그, output 문서를 갱신할지 정했는가?
오래된 산출물에 작성일, 마지막 검토일, 다음 검토 필요일, 최신성 주의가 남아 있는가?

누락 또는 주의사항

장 랜딩 원문은 세 하위 절 목록 중심의 짧은 페이지다. 이 HTML은 장 랜딩만이 아니라 7.1-7.3 세부 원문을 함께 반영해 장 수준으로 재구성했다.
원문에는 Bash/Python 예제, 표, 요청문, 보고서 예시가 나오지만, 이 페이지는 명령과 예시 문장을 장문 복제하지 않고 실습 의도를 목적 정의, 주장-근거 매트릭스, 보고서 흐름, 실행 항목 표, 회의 준비, 후속 반영 루틴으로 정리했다.
외부 자료와 도구 문서는 원문 확인일 기준의 참고 근거다. 실제 도입 전에는 현재 공식 문서, 릴리스, 설치된 도움말, 조직 보안 기준을 다시 확인해야 한다.
산출물은 원천 자료가 아니라 특정 시점의 파생 결과다. 오래된 보고서나 실행 계획은 현재 정책, 담당자, 일정, 제품 상태, 회계 기준, 보안 기준과 다를 수 있으므로 최신성 상태를 남기고 감사 루틴으로 재검토해야 한다.