---
title: interview-prep / post-implementation-knowledge-capture
source_type: interview-prep
status: raw
related_branches: [feature-architecture-enforcement-rules]
related_projects: [ca-skeleton]
tags: [interview-prep, ca-skeleton, workflow, documentation, agent-workflow, llm-wiki]
created: 2026-05-28
status_label: collecting
---

# interview-prep: post-implementation-knowledge-capture

> Layer: `raw/interviews/` — 면접 질문 원본 수집·연구 노트. 다듬어진 답변은 `/interviewize` 후 `wiki/interview/` 에 별도 작성.

## Parent / 부모

- [[raw/branch-notes/feature-architecture-enforcement-rules]] — 작업 종료 조건에 LLM Wiki capture 를 _명시적으로_ 포함시킨 결정 (`결정 사항 2026-05-28: non-trivial 구현 종료 조건에 LLM Wiki capture를 포함한다`).
- [[raw/project-notes/ca-skeleton-operational-contract]] — ca-tmpl skeleton 의 workflow 운영 계약 맥락.

## 질문 / Question

- 질문 원문: 구현이 끝난 뒤 _지식 베이스 기록_ 을 누락하지 않도록 어떤 워크플로우를 설계했나요? 단순 "문서도 작성합니다" 가 아니라 _누락을 막는 메커니즘_ 측면에서.
- 출처: 예상 질문.
- 받은 날짜·맥락: 2026-05-28 ca-tmpl workflow rule 반영 중 도출.

## 질문 의도 추론 / Why this question

- 핵심 평가 대상:
  - 작업 산출물을 _코드에만 남기지 않고_ 지식 자산으로 연결하는 _습관_.
  - "문서화" 를 _후행 작업_ 이 아니라 _완료 조건의 일부_ 로 옮긴 evidence-based 판단.
  - workflow automation 에 대한 감각 (CI 강제 vs documented rule vs agent prompt 의 _trade-off_).
  - 자기 한계 인식 — "자동화" 를 과장하지 않는 정직함.
- 함정 / 흔히 빠지는 답변 패턴:
  - "문서도 작성합니다" 처럼 _구체적인 trigger, template, link rule_ 없이 말하는 것.
  - "CI 로 자동 강제합니다" 같이 _실제로 안 한 자동화_ 를 말하는 것.
  - canonical wiki / blog / portfolio 와 raw 캡처를 _혼동_ 하는 것 (raw 가 먼저, canonical 은 명시 요청 시).
- 따라올 만한 후속 질문:
  - 어떤 문서를 raw 에 남기고 어떤 문서를 canonical wiki 로 _승급_ 하나요? 승급 기준은 무엇인가요?
  - 캡처를 4갈래 (branch / errors / interviews / blog-topics) 로 _분리_ 한 이유는 무엇인가요?
  - 자동 강제 장치 (CI / git hook) 없이도 누락을 막을 수 있나요?
  - 본 워크플로우가 _실제로_ 누락을 줄였다는 증거는 무엇인가요? 몇 사례에 적용해 봤나요?

## 답변 재료 / Raw answer material

- 사실 1 (근거: `feature-architecture-enforcement-rules.md` §결정 사항 2026-05-28 마지막 항목): ca-tmpl repo 의 _4 위치_ 에 capture rule — `AGENTS.md` (프로젝트 authority), 루트 `CLAUDE.md` (always-loaded 요약), `.agents/plugins/ca-superpowers/rules/llm-wiki-capture.md` (rule 본문), `.claude/skills/ca-superpowers-workflow/SKILL.md` (skill 진입점). 각 위치는 트리거가 다름 (대화 시작, 모듈 작업, 비-자명 구현 종료, skill 호출).
- 사실 2 (근거: `llm-wiki-capture.md` §Required Capture Sequence): 캡처 단위 4갈래 — `raw/branch-notes/<branch>.md` (필수), `raw/errors/` (실 에러 발생 시), `raw/interviews/` (면접 질문 도출 시), `raw/blog-topics/` (블로그 글감 도출 시).
- 사실 3 (근거: `llm-wiki-capture.md` §"canonical 추출 요청이 없는 한"): canonical 문서 (`wiki/blog/`, `wiki/interview/`, `wiki/portfolio/`, `wiki/concepts/`, `wiki/projects/`) 는 _사용자가 명시 요청해야_ 생성. raw 가 먼저, canonical 은 _별도 정제 단계_.
- 사실 4 (근거: `llm-wiki-capture.md` 4번 항목): _양방향 nav_ 강제 — 모든 derived note 는 `## Parent` 에서 branch-note 로 upward link, branch-note 는 `## Cluster` 에서 derived note 로 downward link.
- 사실 5 (근거: `llm-wiki-capture.md` §When No Derived Note Is Needed): 파생 문서가 _없을 때_ 도 cluster section 에 "없음" 또는 "추출할 별도 글감 없음" 명시 — _빈 cluster_ 가 "검토 후 없음" 의 증거.
- 사실 6 (근거: `llm-wiki-capture.md` §Final Response Requirement): 종료 응답에 `Wiki capture` 라인 — 갱신된 노트 / 의도적 미생성 / `BLOCKED` 중 하나를 _가시화_.
- 사실 7 (근거: `feature-application-port-usecase-contract.md` §완료 후 정리 + §Cluster): 본 워크플로우의 _첫 적용 사례_ — branch-note 갱신 + 3 derived notes (error, interview, blog-topic) + 종료 응답의 `Wiki capture` 라인.
- 내가 직접 한 경험:
  - 본 결정을 _다른 코드 결정과 대등한 격_ 으로 branch-note 의 §결정 사항 마지막 한 줄로 추가. 대안 (a) 사용자 수동 요청 (누락 위험), (b) Wiki vault 내부 규칙만 (ca-tmpl 작업자 인식 못함), (c) ca-tmpl repo-local rule (채택) 까지 명시.
  - workflow 문서 패치 도중 도구 자동 승인 검토가 차단 → 사용자 명시 승인 후 재개 — [[raw/errors/apply-patch-auto-approval-rejected-2026-05-28]]. _차단 사례 자체를 error-note 로 남긴_ 메타 사례.
  - `feature-application-port-usecase-contract` branch 에서 _첫 적용_ — Wiki capture 라인에 branch-note 갱신 + error / interview / blog-topic 3 derived note 생성을 보고.
- 트레이드오프:
  - **자동 강제 (CI / git hook) vs documented rule + agent prompt**: 전자는 누락 0 보장이지만 _과한 marshalling_ 비용 (모든 작업에 적용되면 작은 변경에도 derived note 강제). 후자는 누락 위험이 있지만 _경량_ 이고 _작업 가까이에_ 트리거를 둠. ca-tmpl 은 후자를 _의도적 선택_.
  - **canonical 먼저 vs raw 먼저**: canonical 먼저 가면 _premature publishing_ (불완전한 결정을 wiki 로 굳힘) 위험. raw 먼저 가면 _정제 단계_ 가 추가되지만 정직함이 보장 — ca-tmpl 의 `llm-wiki-capture.md` 5번 항목이 raw-first 명시.
  - **4갈래 분리 vs 단일 branch-note 통합**: 4갈래는 _분실 방지_ 와 _검색 가능성_ 의 이득, 단일은 _작성 비용_ 낮음. ca-tmpl 은 _다음 세션 검색 가능성_ 을 우선해 4갈래 채택.
- 한계 / "이건 안 해봤다":
  - CI / git hook 으로 자동 강제하지 _않음_. 현재는 _agent workflow rule_ 수준 (`documented-only` 등급).
  - 본 워크플로우의 _장기 효과_ 측정 안 함 — 1 사례 (`feature-application-port-usecase-contract`) 적용 검증만 있음.
  - agent runtime 이 본 rule 파일들을 _실제로_ 자동 로드하는지는 _plugin/skill 구현 의존_. ca-tmpl repo 외부 의존성.

## Sources / 근거

- [[raw/branch-notes/feature-architecture-enforcement-rules]] — workflow 반영 결정 + 진행 중 메모.
- [[raw/branch-notes/feature-application-port-usecase-contract]] — 본 워크플로우의 첫 적용 사례 (branch-note 갱신 + 3 derived notes + `Wiki capture` 라인).
- [[raw/errors/apply-patch-auto-approval-rejected-2026-05-28]] — workflow 문서 패치 중 도구 차단 사례.
- repo file: `ca-tmpl/.agents/plugins/ca-superpowers/rules/llm-wiki-capture.md` — Authority + Required Capture Sequence + When No Derived Note Is Needed + Final Response Requirement.
- repo file: `ca-tmpl/AGENTS.md` §LLM Wiki 캡처 워크플로우.
- repo file: `ca-tmpl/CLAUDE.md` §LLM Wiki capture.

## 미해결 / Unknown

- 모르는 것: 문서 규칙 _만_ 으로 _장기적으로_ agent session 누락이 줄어드는지. 현재 1 사례 검증.
- 모르는 것: 자동 강제 장치 (git hook / CI step) 가 _필요한지_, 아니면 documented rule 로 충분한지.
- 모르는 것: 다른 agent runtime (Claude Code / Codex / Gemini CLI) 이 본 rule 파일을 _자동 로드_ 하는지의 일반화.
- 확인 방법: 이후 2~3개 non-trivial branch 작업 종료 시 derived note 가 _자동으로_ 생성되는지 반복 관찰. 자동 강제 추가 비용 / 효과 PoC.

## 답변 경계 / Answer boundary

- 자신 있게 말할 수 있는 범위:
  - ca-tmpl repo 의 4 위치에 capture rule 을 _직접 반영_ 한 범위 (AGENTS / CLAUDE / llm-wiki-capture / skill).
  - 첫 적용 사례 (`feature-application-port-usecase-contract`) 의 종료 응답 `Wiki capture` 라인이 실제로 _branch-note 갱신 + 3 derived note 생성_ 을 가시화한 사실.
  - 4갈래 raw 구조 (`branch / errors / interviews / blog-topics`) 의 분리 _이유_ 와 _양방향 nav_ 강제.
- "이 부분은 공식 문서를 다시 보고 답변드리겠습니다" 라고 해야 하는 부분:
  - 특정 agent runtime 이 본 rule 파일을 _자동 로드_ 하는지 (plugin/skill 구현 의존).
  - CI / git hook 자동 강제의 구체 구현 (안 해봄).
  - 다른 팀 / 조직 의 knowledge-capture 표준 (`Engineering blog post → ADR → wiki` 류).
- **절대 과장하지 말 것**:
  - "자동으로 캡처된다" 표현 금지 — _현재 `documented-only` 등급_, CI 강제 없음.
  - "운영에서 검증됐다" 표현 금지 — 1 사례 적용 검증.
  - "어떤 runtime 에서도 동작한다" 같은 일반화 금지 — agent plugin / skill 구현 의존.

## Related / 관련

- 관련 면접 질문 (선행/후속): [[raw/interviews/clean-architecture-boundary-enforcement]] (자매 — 같은 branch 의 다른 결정).
- 영감을 받은 채용공고: (없음).
- 관련 블로그 글감: [[raw/blog-topics/post-implementation-knowledge-capture-workflow-2026-05-28]] (같은 결정의 글감).
- 답변 derive 후 위치: 생성 전. 후보 `wiki/interview/workflow/post-implementation-knowledge-capture.md`.