donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
511b6bb022af3aec410d3fc71dd4a14a82bc608f
llm-wiki/raw/interviews/post-implementation-knowledge-capture.md
T

9.4 KiB
Raw Blame History

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

interview-prep: post-implementation-knowledge-capture

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

Parent / 부모

질문 / 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 / 근거

미해결 / 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 / 관련

Reference in New Issue View Git Blame Copy Permalink