/record — 내가 한 일 기록

이 기록의 최종 용도 두 가지를 항상 기억하라:

1. 이력서 소재 — 나중에 추려서 이력서에 쓴다. '무엇을-왜-어떻게-성과'가 빠지면 기록 가치가 없다.
2. '나를 아는 LLM'의 지식 베이스 — frontmatter 스키마와 섹션 구조의 일관성이 검색 품질을 좌우한다.

0. 설정

1. ~/.claude/record-config.json을 읽는다. 없으면(이 머신에서 첫 사용) vault 경로를 물어 생성한다. 경로는 머신마다 다르므로 config는 vault가 아닌 홈에 둔다:

   { "vaultPath": "/Users/younho/Obsidian/My Track Record", "defaultOrg": "<회사 표기>" }

2. vaultPath 검증: 경로가 실존하고 그 안에 99-템플릿/Worklog.md가 있는지 확인한다(올바른 vault인지 표식 검사). 실패하면 경로를 다시 확인받는다.
3. defaultOrg가 비어 있는데 이번 기록이 회사 작업이면, 회사를 어떻게 표기할지 한 번 물어 config에 저장한다.

1. 작업 파악

• 이번 세션 대화 전체에서 완결된 '작업' 단위를 식별한다. 작업 = 이력서 한 줄이 될 수 있는 단위(기능 구현, 성능 개선, 장애 해결, 학습 프로젝트 등).
• 작업이 여러 개면 작업 1개 = 노트 1개로 나눈다. 자잘한 잡무 여러 건이면 하나로 묶을지 사용자에게 확인한다.
• 세션에 작업 맥락이 없으면(예: vault에서 직접 호출, 과거 작업 소급 기록) 인터뷰 모드: 무엇을 했는지 설명을 요청받아 같은 절차로 진행한다.
• org 분류: 회사 작업인지 개인(공부·사이드)인지 맥락으로 추정하고, 확실치 않으면 물어본다. 회사면 §4 보안 필터를 활성화한다.

2. 기존 노트 확인 — 중복 생성 금지

같은 작업의 기존 노트가 있는지 10-회사/, 20-개인/을 제목·summary·project·tech 키워드로 Grep한다 — 완료했던 작업을 다시 이어가는 경우가 여기서 잡힌다.

기존 노트가 있으면 새 노트를 만들지 말고 그 노트를 업데이트한다: 본문 보강 + ## 진행 이력에 오늘 날짜 한 줄 append + frontmatter updated 갱신 + date_end를 최신 완료일로 갱신. 같은 작업인지 새 작업인지 애매하면 사용자에게 확인한다.

3. 인터뷰 — 최대 3문항

세션에서 이미 답이 드러난 질문은 다시 묻지 않는다. 부족한 것만 고른다:

1. 왜: 이 작업이 왜 필요했나? 어떤 문제·요구·배경에서 시작했나?
2. 선택: 다른 방법 대신 이 접근을 택한 이유는? (검토한 대안, 트레이드오프)
3. 성과: 전/후 변화를 수치로 말할 수 있나? (처리시간, 에러율, 비용, 절감 시간 등)
4. 기여: 협업 작업이면 그중 '내 몫'은 정확히 무엇이었나?

날짜는 상대 표현("지난주") 금지 — 반드시 절대 날짜(YYYY-MM-DD)로 변환해 기록한다.

4. 보안 필터 (org가 회사일 때 필수)

절대 포함 금지

• 테이블·API의 컬럼/필드 상세 스키마, 실제 데이터 값, 쿼리 결과
• 고객·거래처·개인 정보
• 크리덴셜, API 키, 토큰, 내부 URL·IP·호스트명
• 소스코드 원문 (해결 접근·의사코드 수준까지만)
• 미공개 사업 지표의 절대값 (매출·거래액·트래픽·고객 수 등) → "3배", "40% 감소" 같은 상대값으로 치환

언급 가능

• 시스템·서비스·테이블의 이름, 기술 스택과 버전, 아키텍처 패턴, 문제 해결 접근

판단이 애매한 항목은 초안에 ⚠️를 붙여 사용자 판단을 받는다. 개인(personal) 기록에는 적용하지 않는다.

5. 초안 작성 → 확인 → 저장

1. 99-템플릿/Worklog.md의 섹션 구조와 §7 frontmatter 스키마를 정확히 따른다.
2. 저장 전 노트 전문을 사용자에게 보여주고 승인·수정을 받는다. ⚠️ 항목은 개별 확인.
3. 저장 위치·파일명:
   • 회사: 10-회사/<작업 제목>.md / 개인: 20-개인/<작업 제목>.md
   • 파일명 = 작업 제목 그대로 (날짜 prefix 없음). 동명 충돌 시 괄호 보조: 쿼리 튜닝 (정산).md
4. 기존 노트 업데이트는 반드시 Read 후 Edit로 부분 수정한다 (통째 덮어쓰기 금지).

6. 연결 — 그래프는 실링크로만 생긴다

• project가 있으면 <org 폴더>/projects/<프로젝트명>.md 허브 노트를 확인하고, 없으면 99-템플릿/Project.md 구조로 생성한다 (개요·내 역할은 사용자에게 한 줄씩 받는다).
• 허브의 ## 작업 목록에 이번 노트 링크를 추가하고, 작업 노트의 ## 관련에 [[<프로젝트명>]]을 기입한다. Dataview 쿼리는 그래프 엣지를 만들지 않으므로 wikilink를 실제로 기입해야 한다.
• 연관 작업을 vault에서 찾아 ## 관련에 상호 링크를 제안한다. 탐색 순서: 같은 project의 노트 → frontmatter tech가 겹치는 노트 → 제목·summary 키워드 Grep. 진짜 관련(같은 시스템, 선행/후속, 같은 문제의식)만 링크하고 억지로 잇지 않는다 — 독립 작업이 고립 노드로 남는 것은 정상이다.
• 이번 세션에서 /learn으로 만든 학습 노트가 있으면 작업 노트와 상호 링크한다. 없어도 30-학습/을 tech·키워드로 탐색해 진짜 관련인 학습 노트만 잇는다 — learn은 세션 중간에 실행되어 그 시점엔 worklog가 없으므로, 학습↔작업 연결은 여기서만 생긴다.

7. frontmatter 스키마 — 일관성 엄수

8. 본문 작성 규칙

• 한국어 + 고유명사는 영어 원어.
• 섹션 구조(배경/한 일/과정/결과/어필 포인트/배운 점/관련/진행 이력)를 유지한다 — 구조 일관성이 곧 향후 RAG 품질이다.
• 어필 포인트: 이력서에 그대로 옮길 수 있는 완성 문장 1~3개. 행동 동사 + 정량 성과. 이 섹션이 이 시스템의 존재 이유다.
• 결과는 "무엇이 달라졌는가" 중심. 코드보다 판단(왜 이 선택을 했는가)을 기록한다.
• 여러 저장소·앱·모듈에 걸친 작업이면 ## 한 일 말미에 만진 곳을 전수 목록으로 적는다(한쪽만 적으면 누락되기 쉽다) — 작업 범위가 노트만으로 드러나도록. (단일 저장소 작업이면 불필요)

9. 마무리

• 생성·수정한 파일 목록을 보고한다.
• 세션에 /learn으로 남기지 않은 학습 노트감(작업과 별개로 기억할 가치가 있는 원리·기법·개념 — "무엇을 했다"가 아니라 "무엇을 알게 됐다")이 보이면 후보를 제시하고 만들지 묻는다. 만들기로 하면 learn 스킬을 호출해 만들고, 작업 노트의 ## 관련에도 링크해 상호 링크를 완성한다. 명백한 후보가 없으면 묻지 않는다 — 억지 후보 금지.
• vault가 git 저장소면: 시작 전 git pull, 저장 후 커밋·push 여부를 물어 진행한다. git 미사용 상태면 전부 생략.
• 이 지시문 내용을 노트에 옮겨 적지 않는다.