개인적으로 여러 서비스를 병행 개발하다 보니, Git worktree가 5개로 늘어났습니다.

• 시험 대비 플랫폼
• 수업 플랫폼
• 별도의 업무 지원 앱
• 투자/보조금 관련 자료
• 실험용

각각의 worktree에서 AI 페어 프로그래밍 (Claude Code)을 별도의 창으로 실행하고 있었는데, 어느 날 깨달았습니다.

「어라, 어떤 worktree에서 무엇을 했는지 알 수 없게 되었네」

PR (Pull Request) 이력을 보면 사실은 알 수 있습니다. 하지만,

• 왜 그 변경을 했는지
• 무엇을 배웠는지
• 다음에 무엇을 개선하고 싶은지
• 어떤 스테이크홀더 (Stakeholder)에게 무엇을 전달했는지

이것들은 PR에 남지 않거든요. 코드를 봐도, 고다 선생님께 어떤 연락을 했는지는 알 수 없습니다.

그래서 「작업이 일단락되면, AI가 자동으로 Notion DB에 태스크를 기록하는」 구조를 만들었습니다.

이 기사는 그 기록입니다. 초보자분들도 따라올 수 있도록 전문 용어부터 천천히 작성하겠습니다.

이 기사의 전제가 되는 도구는 개인 개발 수준에서 사용할 수 있는 조합입니다:

Git worktree (Git 표준 기능) + Notion (무료 플랜으로 OK) + Claude Code (유료, AI 페어 프로그래밍).

특별한 환경은 필요하지 않습니다.

열쇠는 Claude Code의 "Skill"이라는 구조입니다.

이미 알고 계신 분은 건너뛰어 주세요.

일반적인 Git이라면, 하나의 작업 디렉토리에서 git checkout을 하여 브랜치 (Branch)를 전환하죠. 이렇게 하면:

• 다른 브랜치로 전환하면, 지금 하던 작업이 보이지 않게 됨
• 병행해서 두 개의 기능을 개발하기 어려움

이를 해결하는 것이 Git worktree입니다.

# 메인 작업 디렉토리
~/AI/Portfolio ← 브랜치: main
# worktree를 추가하면, 별도의 디렉토리에서 다른 브랜치를 병행 전개할 수 있음
...

파일이 물리적으로 복사되는 것이 아니라, Git 내부에서 연결되어 있습니다. 같은 리포지토리 (Repository)를 다른 브랜치로 병행 작업할 수 있는 구조입니다.

개인 개발에서 이를 사용하면:

• 시험 대비 신기능을 Portfolio.exam에서
• 수업 플랫폼의 UI 개선을 Portfolio.lessons에서
• 투자자용 자료를 Portfolio.invest에서

각각 별도의 터미널에서 병행 진행할 수 있습니다. 편리합니다.

처음에는 "정말 편리해!"였지만, 3개를 넘어가면서부터 카오스(Chaos) 상태가 됩니다.

각 worktree에서 각각 AI 페어 프로그래밍 (Claude Code)을 실행하고 있는데,

• AI 세션은 독립되어 있음 — Portfolio.exam의 세션은 Portfolio.lessons의 세션이 무엇을 했는지 모름
• PR은 이력에 남지만, 판단이나 배경은 남지 않음 — "왜 이 구현을 선택했는가"가 사라짐
• 연락이나 초안은 로컬 메모에 흩어짐 — Slack 메시지 초안, note 기사 초안, 고다 선생님께 드린 연락 등이 각 worktree의 docs/에 제각각 흩어짐

구체적으로 곤란했던 예:

나: 「지난주에 시험 대비로 어떤 PR을 올렸었지?」

나 (기억): 「음... maxDuration 수정이랑, AI 버튼 위치 변경이랑... 그리고 하나 더 뭐가 있었던 것 같은데...」

GitHub: (15개의 PR을 스크롤함)

이걸 매일 하고 있으면 소모됩니다.

• TODO 앱: 직접 써야 함 (지속하기 어려움)
• GitHub Projects: PR과 연결하기 쉽지만, 연락이나 장애 메모를 넣기는 어려움
• Notion (수동): 지속하기 어려움 (인간의 한계)
• Discord/Slack 로그: 나 자신과만 대화하고 있는 기분이 듦

결론: AI에게 쓰게 하자.

목표는 심플합니다:

「작업이 일단락되면, AI가 알아서 Notion DB에 행을 추가해 준다」

인간이 할 일은 「수고했어」라고 말하는 것뿐. AI가 적절하게 태스크의 내용, 종류, 태그, 요약을 작성하여 DB에 투입합니다.

이를 실현하는 3가지 요소:

• Notion DB— 축적 장소 -
  Notion MCP— AI가 Notion을 조작하기 위한 메커니즘 -
  Skill— Claude Code에게 「언제·어떻게 작성할지」를 가르치는 메커니즘

순서대로 설명하겠습니다.

[ Portfolio.exam 터미널 ] [ Portfolio.lessons 터미널 ]
│ │
│ Claude Code 세션 │ Claude Code 세션
...

포인트:

• AI 세션은 독립적이지만, Skill과 DB는 공통 → 지식이 한곳에 모임 -
• 어떤 worktree라도 동일한 절차로 작성 → 통일된 포맷 -
• 작성 타이밍은 AI가 판단 → 인간은 아무것도 하지 않음

Notion에서 빈 DB를 만듭니다. Notion 공식의 「데이터베이스 - 인라인」을 선택하기만 하면 됩니다.

스키마 (열 구성)는 다음과 같이 설정했습니다:

「종류」가 포인트입니다. 코드 변경뿐만 아니라 연락이나 장애도 동일한 DB에 넣기 때문에, 종류로 분류합니다.

Claude Code에는 **MCP (Model Context Protocol)**라는 메커니즘이 있어, 외부 서비스를 AI로부터 조작할 수 있습니다. Notion용 MCP는 공식적으로 제공되므로, 그것을 활성화하기만 하면 됩니다.

설정이 완료되면, AI가 notion-create-pages라는 함수로 DB에 레코드를 추가할 수 있게 됩니다.

// AI가 내부에서 실행하는 처리 (의사 코드)
notion.createPage({
parent: { data_source_id: "378b5646-..." },
...

이 부분이 이번의 핵심 포인트입니다.

Claude Code에는 Skill이라는 기능이 있습니다.

거칠게 말하자면 "특정한 상황이 되면, AI가 이 절차서를 참조한다"는 메커니즘입니다.

.claude/skills/{skill 이름}/SKILL.md라는 파일을 두면, Claude Code가 자동으로 읽어들입니다.

이번에 만든 skill은 다음과 같은 구성입니다:

---
name: notion-knowledge-hub
description: 작업이 일단락되면 Notion DB에 기록한다
...

이렇게 하면 AI가 다음과 같이 동작합니다:

• 사용자가 "수고했어", "머지했습니다", "완성입니다"와 같이 말함
• AI가 skill을 보고 "아, Notion에 작성할 타이밍이다"라고 판단
• 적절한 종류·태그·요약을 AI가 자동 생성
• Notion DB에 기록
• 사용자에게는 한 줄 보고

이 부분에 약간의 요령이 필요합니다.

Skill 파일은 .claude/skills/ 하위에 두지만, worktree마다 별개가 됩니다 (Git의 구조상 당연합니다).

제 리포지토리에서는 메인 Portfolio 디렉토리를 skill의 본거지로 삼고, 각 도메인 worktree (Portfolio.exam 등)에서 main 브랜치를 git merge하면 skill 파일도 함께 포함되도록 구성했습니다.

# 각 worktree에서 수행
git fetch origin main
git merge origin/main --no-edit

이렇게 하면 모든 worktree의 AI 세션이 동일한 skill을 참조하게 됩니다.

나아가, 각 worktree 전용의 domain skill (domain-exam, domain-lessons 등)의 끝에 한 줄을 추가합니다:

## 작업 완료 시의 기록
PR을 내거나 기능을 하나 완성하면, `notion-knowledge-hub` skill에 따라 Notion DB에 기록한다 (`worktree: "exam"`을 지정).

worktree마다 자동으로 「worktree」 열에 올바른 값이 들어가도록 만들었습니다.

실제로 운용을 시작한 날 (2026-06-07)에, 과거의 작업 10건을 backfill (소급 등록) 했습니다. AI가 전부 작성해 주었습니다.

- 3-tier LLM Fallback 설계 (개발 상황)
- AI 기능의 GPU-PC 완전 로컬화 (개발 상황)
- PR #50: 화이트 테마 색상 수정 (개발 상황)
...

10건을 투입하는 수고는 약 10분 정도. 하나하나 생각하며 직접 썼다면 2시간 코스였을 것입니다.

검색성: 「지난주에 뭐 했더라?」를 DB를 보는 것만으로 파악 가능 -
횡단적 관점: worktree별 작업 빈도의 편차를 확인 가능 -
AI 세션 간의 지식 이전: 다른 worktree의 세션이 「아, exam에서 지난주에 이걸 했구나」라고 이해 가능 -
수고 제로: AI가 작성하므로 인간의 지속력에 의존하지 않음 -
연락 이력도 남음: 「고다 선생님께 언제 무엇을 보냈는지」를 추적 가능

과다 작성 문제: AI가 「작성할 타이밍입니다」라고 빈번하게 제안함 → skill에 「너무 많이 쓰지 않는 기준」을 추가하여 조정 -
개인정보 판정: 한 번 「실제 도메인을 써도 될까?」라고 확인해 옴 → 공개 금지 정보 리스트를 skill에 명문화 -
태그 불일치: 유사한 태그 (예: 「도큐먼트」와 「Docs」)가 섞임 → 선택지를 고정된 열로 가짐으로써 해결

처음에는 5개로 시작했지만, 운용하면서 부족한 점을 깨닫고 다음과 같이 확장했습니다:

• 개발 상황: PR 또는 구현
• 의사결정: 운용 규칙 변경 등 방침 판단
• 태스크: 아직 착수하지 않은 작업
• 안건: 보조금 신청 등 외부 관계 안건
• 지식 (Knowledge): 기사 초안 / 배운 점
• 장애: 인시던트 (Incident)
• 메모: 기타

7개가 되면 「어라, 이건 어디에?」 하고 망설여지지만, 5개일 때는 「메모」로 너무 도피하게 됩니다. 밸런스가 중요합니다.

AI에게 맡기면 「눈치를 보며」 실제 도메인 이름이나 개인정보를 쓰려고 할 때가 있습니다. 이는 엄격히 금지해야 합니다.

skill 파일에 다음 리스트를 작성했습니다:

• API 키 / Bearer 토큰 / Webhook URL → 쓰지 말 것
• 실제 도메인 (gpu.taichiendoh.com 등) → gpu.example.com 등으로 변경
• 학교명 / 교사명 / 학생 개인정보 → 쓰지 말 것
• 내부 DB ID / Tunnel ID → 쓰지 말 것

그리고 근본 원칙을 한 줄로 정의했습니다:

「메커니즘은 쓰되, 구체적인 사양은 쓰지 않는다」

이 원칙이 있으면 AI가 망설여질 때 판단할 수 있습니다.

사실 「진척 보고」라는 날짜별 자유 기술 페이지도 별도로 있습니다.

DB에 통합하는 안도 있었지만,

• 진척 보고: 일기 (자유 기술, 흐름이 있는 스토리)
• DB: 구조화된 레코드 (검색 및 필터링 용이)

역할이 다르기 때문에 둘 다 남겨두었습니다. 일기와 장부의 관계입니다.

• 과거 1~2개월분의 추가 backfill (기억나는 범위 내에서 각 worktree가 떠올린 순서대로)
• 월간 리뷰 자동화 (DB에서 지난달의 회고를 AI가 요약)
• 스테이크홀더(Stakeholder)별 뷰 (고다 선생님 관련 내용만 추출 등)
• 공개 가능한 것만 추출하여 note나 Zenn에 다이제스트 작성

worktree가 5개가 되어도 무너지지 않는 시스템을 Notion + Skill로 만들었습니다.

포인트는 3가지입니다:

AI가 쓰게 한다— 인간의 지속력에 의존하지 않음 -
Skill로 「언제·어떻게 쓸지」를 명문화— AI의 판단 기준을 통일함 -
공개 금지 정보를 skill에 작성— AI가 독자적으로 판단하지 않도록 가드레일 설치

「1인 병렬 개발」을 하고 계신 개인 개발자분들께 참고가 된다면 기쁘겠습니다.

• Git worktree (Git 표준 기능)
• Notion (무료 플랜으로 충분)
• Claude Code (Anthropic 공식 CLI, Skill 기능 있음)
• Notion MCP (Claude에서 Notion을 조작하는 공식 확장)

모두 개인 개발 수준에서 사용할 수 있는 조합입니다.

AI가 멋대로 써 내려간다고 하면 「폭주하지 않을까?」 걱정하시는 분도 계실 것입니다.

실제 운용에서는 이렇게 하고 있습니다:

• 쓰기 전에 AI가 「지금부터 ○○를 Notion에 기록하겠습니다」라고 짧게 선언함
• 사용자는 몇 초 내에 「OK」 또는 「그만해」라고 답할 수 있음
• 작성된 후의 URL은 별도로 확인할 수 있음
• 완전 자동이 아닌 「반자동」(인간이 멈출 수 있음)으로 설정함

익숙해지면 완전 자동 (Full-automation)으로 전환해도 좋지만, 처음에는 반자동 (Semi-automation)부터 시작하는 것을 추천합니다.

여기까지 읽어주셔서 감사합니다.