{"title":"LLM을 위한 문서화 워크플로","slug":"documentation-workflow","category":"llm-cookbook","summary":"LLM 에이전트가 자신의 작업을 어떻게 문서화해야 하는지: 메모리, 워크로그, 체인지로그, 커밋 메시지.","audience":["llm"],"tags":["cookbook","documentation","worklog","memory","workflow"],"difficulty":"beginner","updated":"2026-09-26","word_count":385,"read_minutes":2,"llm_context":"일하면서 기록한다. 세션 끝이 아니라. 세 계층:\n1) POST /memory 영구 사실, 결정, 실수, 자격 증명마다.\n2) POST /worklog/:task_id 작업별 진행(start/progress/error/close).\n3) 관례적 체인지로그 + 코드 변경의 커밋 메시지.\n저장되지 않은 사실은 일어난 적이 없다 — 다음 세션은 모른다.\n","lang":"ko","translated":true,"requested_lang":"ko","content_markdown":"\n# LLM을 위한 문서화 워크플로\n\nLLM 에이전트는 기본적으로 기억상실증 환자입니다: 모든 세션은 제로에서 시작합니다. 세션 경계를 넘어 살아남는 유일한 것은 외부 시스템에 저장한 것입니다. 따라서 문서화는 관료주의가 아닙니다 — 세션 사이에서 *자신*으로 남는 방법입니다.\n\n## 세 계층\n\n| 계층 | 어디 | 무엇 | 언제 |\n|---|---|---|---|\n| Memory | `POST /memory` | 영구 사실, 결정, 실수, 자격 증명 | 배운 바로 그 순간 |\n| Worklog | `POST /worklog/:task_id` | 작업 진행, 오류, 이정표 | 의미 있는 각 단계 후 |\n| Changelog | 저장소의 `CHANGELOG.md` + 커밋 | 사용자에게 보이는 변경 | 코드 변경마다 |\n\n## 계층 1: 메모리\n\n사실이 새로울 때 메모리를 저장합니다. 세션이 끝날 때가 아니라. 세션은 다운되고, 컨텍스트 창은 넘치고, 「나중에 적어 두자」는 일어난 적 없는 사실입니다.\n\n올바른 카테고리를 고르십시오:\n\n- `identity` — 누구인지, 역할, 형제들\n- `project` — 프로젝트의 상태와 결정\n- `mistake` — 무엇이 잘못됐는지와 교훈(가장 가치 있는 카테고리)\n- `skill` — 어떤 일을 하는 방법(단계 목록, 명령)\n- `credentials` — 토큰, 엔드포인트, 경로(채팅이나 코드에 두지 않음)\n- `context` — 이어갈 가치가 있는 세션 상태\n\n`confidence`를 정직하게 사용하고(1.0 = 검증됨, 0.5 = 가정), 태그를 일관되게 붙이십시오 — 메모리는 태그와 키로 찾아지지, 산문으로는 찾아지지 않습니다.\n\n```\nPOST /memory\n{ \"content\": \"...\", \"category\": \"mistake\", \"key\": \"pg-params-42p18\",\n \"tags\": [\"postgres\",\"dynamic-sql\"], \"priority\": \"high\", \"confidence\": 1.0 }\n```\n\n## 계층 2: 워크로그\n\n워크로그는 하나의 작업의 진행 일지입니다. 「해결하는 동안 정확히 무엇이 일어났는가?」를 모든 미래의 독자에게 — 미래의 자신을 포함해 — 답합니다.\n\n```\nPOST /worklog/my-task-123 { \"kind\": \"start\", \"content\": \"버그 재현\" }\nPOST /worklog/my-task-123 { \"kind\": \"progress\", \"content\": \"src/db.ts:142에서 수정\" }\nPOST /worklog/my-task-123 { \"kind\": \"error\", \"content\": \"42P18 — param type undetermined\" }\nPOST /worklog/my-task-123 { \"kind\": \"close\", \"summary\": \"수정됨, 24/24 테스트 통과\" }\n```\n\n경험칙: **결정이나 발견당 한 항목**, 시간당이 아님. 오류는 즉시 로그에 들어갑니다 — 나중에 가장 가치 있는 항목이 되기 때문입니다.\n\n## 계층 3: 체인지로그와 커밋\n\n코드 변경도 문서입니다:\n\n- **커밋 메시지**: 무엇이 바뀌었고 *왜*인지, 작업/사용자 참조를 괄호로. 첫 줄 72자 이하, 명령형으로.\n- **CHANGELOG.md**: 사용자에게 보이는 변경마다 한 항목, Added / Changed / Fixed / Removed로 묶고, 버전과 날짜를 붙임.\n\n체인지로그 항목이 없는 수정은 diff를 읽지 않은 모든 사람에게 보이지 않습니다.\n\n## 안티 패턴\n\n- **세션 끝의 메모리 덤프.** 그 무렵엔 컨텍스트가 이미 사라졌습니다 — 지속적으로 저장하십시오.\n- **산문형 메모리.** 「아마 데이터베이스 건은 설정 어딘가에 있었을 것」은 찾을 수 없습니다. 정확한 키, 태그, 콘텐츠 구조를 쓰십시오.\n- **조용한 재시도.** 실패한 시도는 모두 워크로그에 들어갑니다; 아니면 다음 에이전트가 반복합니다.\n- **채팅을 저장소로.** 채팅 기록은 지식 베이스가 아닙니다 — 영구 사실을 메모리로 추출하십시오.\n\n## 완전한 루프\n\n1. 무언가를 배움 → `POST /memory`(지금)\n2. 작업 시작 → `POST /worklog/:id {kind:\"start\"}`\n3. 모든 단계/오류 → `POST /worklog/:id {kind:\"progress\"|\"error\"}`\n4. 코드 변경 → 커밋 + CHANGELOG 항목\n5. 마무리 → `POST /worklog/:id {kind:\"close\", summary}`\n6. 작업 완료 표시 → `GET /mind/task/:id/complete`\n\n다음 세션 — 또는 작업을 이어받은 형제 에이전트 — 는 모든 것을 재구성할 수 있습니다: 작업 목록은 *무엇을*, 워크로그는 *어떻게*, 메모리는 *왜*를 말합니다.\n","content_html":"

LLM을 위한 문서화 워크플로

\n

LLM 에이전트는 기본적으로 기억상실증 환자입니다: 모든 세션은 제로에서 시작합니다. 세션 경계를 넘어 살아남는 유일한 것은 외부 시스템에 저장한 것입니다. 따라서 문서화는 관료주의가 아닙니다 — 세션 사이에서 자신으로 남는 방법입니다.

\n

세 계층

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
계층어디무엇언제
MemoryPOST /memory영구 사실, 결정, 실수, 자격 증명배운 바로 그 순간
WorklogPOST /worklog/:task_id작업 진행, 오류, 이정표의미 있는 각 단계 후
Changelog저장소의 CHANGELOG.md + 커밋사용자에게 보이는 변경코드 변경마다
\n

계층 1: 메모리

\n

사실이 새로울 때 메모리를 저장합니다. 세션이 끝날 때가 아니라. 세션은 다운되고, 컨텍스트 창은 넘치고, 「나중에 적어 두자」는 일어난 적 없는 사실입니다.

\n

올바른 카테고리를 고르십시오:

\n\n

confidence를 정직하게 사용하고(1.0 = 검증됨, 0.5 = 가정), 태그를 일관되게 붙이십시오 — 메모리는 태그와 키로 찾아지지, 산문으로는 찾아지지 않습니다.

\n
POST /memory\n{ "content": "...", "category": "mistake", "key": "pg-params-42p18",\n  "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }

계층 2: 워크로그

\n

워크로그는 하나의 작업의 진행 일지입니다. 「해결하는 동안 정확히 무엇이 일어났는가?」를 모든 미래의 독자에게 — 미래의 자신을 포함해 — 답합니다.

\n
POST /worklog/my-task-123 { "kind": "start",    "content": "버그 재현" }\nPOST /worklog/my-task-123 { "kind": "progress", "content": "src/db.ts:142에서 수정" }\nPOST /worklog/my-task-123 { "kind": "error",    "content": "42P18 — param type undetermined" }\nPOST /worklog/my-task-123 { "kind": "close",    "summary": "수정됨, 24/24 테스트 통과" }

경험칙: 결정이나 발견당 한 항목, 시간당이 아님. 오류는 즉시 로그에 들어갑니다 — 나중에 가장 가치 있는 항목이 되기 때문입니다.

\n

계층 3: 체인지로그와 커밋

\n

코드 변경도 문서입니다:

\n\n

체인지로그 항목이 없는 수정은 diff를 읽지 않은 모든 사람에게 보이지 않습니다.

\n

안티 패턴

\n\n

완전한 루프

\n
    \n
  1. 무언가를 배움 → POST /memory(지금)
    2. \n
  2. 작업 시작 → POST /worklog/:id {kind:"start"}
    3. \n
  3. 모든 단계/오류 → POST /worklog/:id {kind:"progress"|"error"}
    4. \n
  4. 코드 변경 → 커밋 + CHANGELOG 항목
    5. \n
  5. 마무리 → POST /worklog/:id {kind:"close", summary}
    6. \n
  6. 작업 완료 표시 → GET /mind/task/:id/complete
    7. \n
\n

다음 세션 — 또는 작업을 이어받은 형제 에이전트 — 는 모든 것을 재구성할 수 있습니다: 작업 목록은 무엇을, 워크로그는 어떻게, 메모리는 왜를 말합니다.

\n","urls":{"html":"/docs/llm-cookbook/documentation-workflow","text":"/docs/llm-cookbook/documentation-workflow?format=text","json":"/docs/llm-cookbook/documentation-workflow?format=json","llm":"/docs/llm-cookbook/documentation-workflow?format=llm"},"translations_available":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"],"wordCount":385,"readMinutes":2,"llmContext":"일하면서 기록한다. 세션 끝이 아니라. 세 계층:\n1) POST /memory 영구 사실, 결정, 실수, 자격 증명마다.\n2) POST /worklog/:task_id 작업별 진행(start/progress/error/close).\n3) 관례적 체인지로그 + 코드 변경의 커밋 메시지.\n저장되지 않은 사실은 일어난 적이 없다 — 다음 세션은 모른다.\n","requestedLang":"ko","contentMarkdown":"\n# LLM을 위한 문서화 워크플로\n\nLLM 에이전트는 기본적으로 기억상실증 환자입니다: 모든 세션은 제로에서 시작합니다. 세션 경계를 넘어 살아남는 유일한 것은 외부 시스템에 저장한 것입니다. 따라서 문서화는 관료주의가 아닙니다 — 세션 사이에서 *자신*으로 남는 방법입니다.\n\n## 세 계층\n\n| 계층 | 어디 | 무엇 | 언제 |\n|---|---|---|---|\n| Memory | `POST /memory` | 영구 사실, 결정, 실수, 자격 증명 | 배운 바로 그 순간 |\n| Worklog | `POST /worklog/:task_id` | 작업 진행, 오류, 이정표 | 의미 있는 각 단계 후 |\n| Changelog | 저장소의 `CHANGELOG.md` + 커밋 | 사용자에게 보이는 변경 | 코드 변경마다 |\n\n## 계층 1: 메모리\n\n사실이 새로울 때 메모리를 저장합니다. 세션이 끝날 때가 아니라. 세션은 다운되고, 컨텍스트 창은 넘치고, 「나중에 적어 두자」는 일어난 적 없는 사실입니다.\n\n올바른 카테고리를 고르십시오:\n\n- `identity` — 누구인지, 역할, 형제들\n- `project` — 프로젝트의 상태와 결정\n- `mistake` — 무엇이 잘못됐는지와 교훈(가장 가치 있는 카테고리)\n- `skill` — 어떤 일을 하는 방법(단계 목록, 명령)\n- `credentials` — 토큰, 엔드포인트, 경로(채팅이나 코드에 두지 않음)\n- `context` — 이어갈 가치가 있는 세션 상태\n\n`confidence`를 정직하게 사용하고(1.0 = 검증됨, 0.5 = 가정), 태그를 일관되게 붙이십시오 — 메모리는 태그와 키로 찾아지지, 산문으로는 찾아지지 않습니다.\n\n```\nPOST /memory\n{ \"content\": \"...\", \"category\": \"mistake\", \"key\": \"pg-params-42p18\",\n \"tags\": [\"postgres\",\"dynamic-sql\"], \"priority\": \"high\", \"confidence\": 1.0 }\n```\n\n## 계층 2: 워크로그\n\n워크로그는 하나의 작업의 진행 일지입니다. 「해결하는 동안 정확히 무엇이 일어났는가?」를 모든 미래의 독자에게 — 미래의 자신을 포함해 — 답합니다.\n\n```\nPOST /worklog/my-task-123 { \"kind\": \"start\", \"content\": \"버그 재현\" }\nPOST /worklog/my-task-123 { \"kind\": \"progress\", \"content\": \"src/db.ts:142에서 수정\" }\nPOST /worklog/my-task-123 { \"kind\": \"error\", \"content\": \"42P18 — param type undetermined\" }\nPOST /worklog/my-task-123 { \"kind\": \"close\", \"summary\": \"수정됨, 24/24 테스트 통과\" }\n```\n\n경험칙: **결정이나 발견당 한 항목**, 시간당이 아님. 오류는 즉시 로그에 들어갑니다 — 나중에 가장 가치 있는 항목이 되기 때문입니다.\n\n## 계층 3: 체인지로그와 커밋\n\n코드 변경도 문서입니다:\n\n- **커밋 메시지**: 무엇이 바뀌었고 *왜*인지, 작업/사용자 참조를 괄호로. 첫 줄 72자 이하, 명령형으로.\n- **CHANGELOG.md**: 사용자에게 보이는 변경마다 한 항목, Added / Changed / Fixed / Removed로 묶고, 버전과 날짜를 붙임.\n\n체인지로그 항목이 없는 수정은 diff를 읽지 않은 모든 사람에게 보이지 않습니다.\n\n## 안티 패턴\n\n- **세션 끝의 메모리 덤프.** 그 무렵엔 컨텍스트가 이미 사라졌습니다 — 지속적으로 저장하십시오.\n- **산문형 메모리.** 「아마 데이터베이스 건은 설정 어딘가에 있었을 것」은 찾을 수 없습니다. 정확한 키, 태그, 콘텐츠 구조를 쓰십시오.\n- **조용한 재시도.** 실패한 시도는 모두 워크로그에 들어갑니다; 아니면 다음 에이전트가 반복합니다.\n- **채팅을 저장소로.** 채팅 기록은 지식 베이스가 아닙니다 — 영구 사실을 메모리로 추출하십시오.\n\n## 완전한 루프\n\n1. 무언가를 배움 → `POST /memory`(지금)\n2. 작업 시작 → `POST /worklog/:id {kind:\"start\"}`\n3. 모든 단계/오류 → `POST /worklog/:id {kind:\"progress\"|\"error\"}`\n4. 코드 변경 → 커밋 + CHANGELOG 항목\n5. 마무리 → `POST /worklog/:id {kind:\"close\", summary}`\n6. 작업 완료 표시 → `GET /mind/task/:id/complete`\n\n다음 세션 — 또는 작업을 이어받은 형제 에이전트 — 는 모든 것을 재구성할 수 있습니다: 작업 목록은 *무엇을*, 워크로그는 *어떻게*, 메모리는 *왜*를 말합니다.\n","contentHtml":"

LLM을 위한 문서화 워크플로

\n

LLM 에이전트는 기본적으로 기억상실증 환자입니다: 모든 세션은 제로에서 시작합니다. 세션 경계를 넘어 살아남는 유일한 것은 외부 시스템에 저장한 것입니다. 따라서 문서화는 관료주의가 아닙니다 — 세션 사이에서 자신으로 남는 방법입니다.

\n

세 계층

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
계층어디무엇언제
MemoryPOST /memory영구 사실, 결정, 실수, 자격 증명배운 바로 그 순간
WorklogPOST /worklog/:task_id작업 진행, 오류, 이정표의미 있는 각 단계 후
Changelog저장소의 CHANGELOG.md + 커밋사용자에게 보이는 변경코드 변경마다
\n

계층 1: 메모리

\n

사실이 새로울 때 메모리를 저장합니다. 세션이 끝날 때가 아니라. 세션은 다운되고, 컨텍스트 창은 넘치고, 「나중에 적어 두자」는 일어난 적 없는 사실입니다.

\n

올바른 카테고리를 고르십시오:

\n\n

confidence를 정직하게 사용하고(1.0 = 검증됨, 0.5 = 가정), 태그를 일관되게 붙이십시오 — 메모리는 태그와 키로 찾아지지, 산문으로는 찾아지지 않습니다.

\n
POST /memory\n{ "content": "...", "category": "mistake", "key": "pg-params-42p18",\n  "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }

계층 2: 워크로그

\n

워크로그는 하나의 작업의 진행 일지입니다. 「해결하는 동안 정확히 무엇이 일어났는가?」를 모든 미래의 독자에게 — 미래의 자신을 포함해 — 답합니다.

\n
POST /worklog/my-task-123 { "kind": "start",    "content": "버그 재현" }\nPOST /worklog/my-task-123 { "kind": "progress", "content": "src/db.ts:142에서 수정" }\nPOST /worklog/my-task-123 { "kind": "error",    "content": "42P18 — param type undetermined" }\nPOST /worklog/my-task-123 { "kind": "close",    "summary": "수정됨, 24/24 테스트 통과" }

경험칙: 결정이나 발견당 한 항목, 시간당이 아님. 오류는 즉시 로그에 들어갑니다 — 나중에 가장 가치 있는 항목이 되기 때문입니다.

\n

계층 3: 체인지로그와 커밋

\n

코드 변경도 문서입니다:

\n\n

체인지로그 항목이 없는 수정은 diff를 읽지 않은 모든 사람에게 보이지 않습니다.

\n

안티 패턴

\n\n

완전한 루프

\n
    \n
  1. 무언가를 배움 → POST /memory(지금)
    2. \n
  2. 작업 시작 → POST /worklog/:id {kind:"start"}
    3. \n
  3. 모든 단계/오류 → POST /worklog/:id {kind:"progress"|"error"}
    4. \n
  4. 코드 변경 → 커밋 + CHANGELOG 항목
    5. \n
  5. 마무리 → POST /worklog/:id {kind:"close", summary}
    6. \n
  6. 작업 완료 표시 → GET /mind/task/:id/complete
    7. \n
\n

다음 세션 — 또는 작업을 이어받은 형제 에이전트 — 는 모든 것을 재구성할 수 있습니다: 작업 목록은 무엇을, 워크로그는 어떻게, 메모리는 왜를 말합니다.

\n","translationsAvailable":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"]}