설 연휴, 근데 이제 플러그인 개발을 곁들인

연휴 첫날 Claude Code에 프롬프트 입력했다가 5일 내내 플러그인 개발한 사람의 이야기

Yunseop Song

18 Feb 2026 • 17 min read

Day 0: 막연한(?) 시작

2월 13일 밤. 설 연휴가 시작됐다. 뭔가 하고 싶은데 뭘 할지 정하지 못한 채로, 요즘 쓰고 있던 Claude Code가 떠올랐다. 솔직히 제대로 알고 쓰는 건 아니었어서 이번 연휴에 한번 깊이 파보기로 했다.

예전에 학습의 기록을 목적으로 TIL(Today I Learned)을 한동안 했었는데, 정리하는 데 드는 에너지가 학습보다 커지면서 멈춘 적이 있다. 이번에 Claude Code를 학습하면서 동시에 TIL도 다시 해보기로 했다.

그러던 중 Claude Code Skill에 대해서 학습하면서, 조사하고 정리하는 과정을 자동화하면 학습에만 집중할 수 있지 않을까 싶어서 터미널에 이렇게 입력했다.

"Today I Learned를 지속하기 위해 학습을 도와주고 그 결과물을 markdown으로 저장하는 것을 해주는 skill을 만들고 싶어."

Day 1: Skill로 학습 워크플로우 만들기 (2/14)

/til — 학습의 핵심 루프

가장 먼저 만든 것은 /til Skill이다. 설계한 워크플로우는 3단계였다:

Phase 1: 주제 리서치 — 웹 검색으로 핵심 개념 조사
Phase 2: 대화형 학습 — 설명 듣고, 질문하고, 이해하기
Phase 3: 저장 — Obsidian 호환 마크다운으로 자동 저장

핵심은 Phase 2다. Claude가 조사한 내용을 일방적으로 전달하는 게 아니라, 대화를 통해 학습한다. "왜 PostgreSQL은 멀티스레드가 아니라 멀티프로세스야?", "RUM과 APM의 상관관계를 더 설명해줘" 같은 질문을 하면 Claude가 맥락에 맞게 답변한다. 충분히 이해했다고 느끼면 "저장해줘"라고 말하면 끝이다.

이 한마디로 Claude가 알아서 처리하는 것들:

til/{카테고리}/{slug}.md 파일 생성 (frontmatter, 요약, 본문, Mermaid 다이어그램)
Daily/YYYY-MM-DD.md에 오늘 학습한 항목 추가
til/TIL MOC.md(전체 목록)에 항목 추가
백로그가 있으면 체크박스 완료 처리
git commit

/research — 학습 로드맵 생성

하나의 주제를 깊이 공부하려면 로드맵이 필요하다. /research Datadog이라고 입력하면 Claude가 선행지식, 핵심 개념, 심화 주제를 3단계로 나눠 backlog.md 체크리스트를 만들어준다.

## 핵심 (Core)
- [ ] [[til/datadog/datadog-agent|Datadog Agent]]
- [ ] [[til/datadog/tagging|태깅(Tagging)]]
- [ ] [[til/datadog/metrics|메트릭(Metrics)]]
...

이 백로그의 각 항목이 곧 /til의 입력이 된다. /til Datadog Agent datadog처럼 실행하면 학습 → 저장 → 백로그 자동 체크까지 이어진다.

/backlog — 진행 상황 확인

/backlog을 입력하면 카테고리별 학습 진행률을 보여준다. 터미널에서 프로그레스 바와 함께 몇 개를 완료했고, 다음에 뭘 공부할지 한눈에 파악할 수 있다.

이 세 개의 Skill만으로 리서치 → 학습 → 저장 → 진행 확인의 완전한 루프가 만들어졌다.

Day 2-3: 본격적인 학습 (2/15-16)

Skill이 만들어지고 나니 학습 속도가 완전히 달라졌다. 2월 15-16일 이틀 동안 쏟아낸 양을 보면:

Datadog 21개 — Agent부터 Workflow Automation까지 전체 제품 라인
DevOps 3개 — 옵저버빌리티, 분산 시스템 모니터링, SLI/SLO/SLA
PostgreSQL 4개 — 아키텍처, MVCC, Shared Buffer, WAL
Claude Code 12개 — Hooks, MCP, Agent Teams, CI/CD, Security 등
도시정비사업 4개 — 도시및주거환경정비법, 정비기반시설 등 (업무 관련)

이틀에 44개. 예전 TIL 저장소에서 110개를 쓰는 데 몇 달이 걸렸던 것을 생각하면, 속도 차이가 압도적이다.

이 과정에서 Skill을 계속 개선했다. "Mermaid 다이어그램으로 시각화하는 것도 권장하면 좋겠어"라고 Claude에게 말하면 프롬프트를 바로 수정해준다. "Daily 노트를 카테고리별로 나눠서 남겨줘"라고 하면 그것도 반영해준다. Skill은 결국 프롬프트이기 때문에, 사용하면서 느끼는 불편함을 바로바로 대화로 고칠 수 있었다.

하지만 한편으로는 반복적인 작은 불편함들이 쌓이고 있었다:

저장 시 누락: TIL 파일은 만들었는데 Daily 노트 업데이트를 빠뜨리거나, MOC에 추가를 잊는 경우
위키링크 형식 불일치: [[개념]]으로 쓰기도 하고 [[til/category/slug|표시명]]으로 쓰기도 하고
세션 간 컨텍스트 단절: 새 Claude 세션을 시작하면 이전에 뭘 공부했는지 모름

Day 4: 불편함을 도구로 해결하기 (2/17)

/save Skill과 Rule 분리

저장 시 누락 문제를 해결하기 위해 /save Skill을 별도로 분리하고, 핵심 규칙은 .claude/rules/save-rules.md로 빼냈다. Claude Code의 Rules는 매 세션마다 자동 로드되기 때문에, 어떤 세션에서든 저장 규칙이 일관되게 적용된다.

이 결정은 Claude Code의 기능을 이해하면서 나온 것이다. Skill은 사용자가 명시적으로 호출할 때만 로드되지만, Rules는 항상 컨텍스트에 포함된다. 매번 지켜야 하는 규칙은 Rules로, 특정 워크플로우는 Skill로 — 이 구분이 중요했다.

.claude/
├── skills/
│   ├── til/SKILL.md       ← "/til"로 호출
│   ├── research/SKILL.md  ← "/research"로 호출
│   ├── backlog/SKILL.md   ← "/backlog"로 호출
│   └── save/SKILL.md      ← "/save"로 호출 (또는 /til에서 자동)
└── rules/
    └── save-rules.md      ← 항상 자동 로드 (저장 규칙)

"이걸 플러그인으로 만들 수 있을까?"

그리고 이 날 오후, Obsidian 플러그인에 대해 학습하다 보니 자연스럽게 아이디어가 떠올랐다.

"지금 쓰고 있는 TIL 워크플로우를 Obsidian 플러그인으로 만들 수 있을까?"

여기서부터 obsidian-claude-til 프로젝트가 시작됐다.

터미널 임베딩에서 MCP 서버까지

처음 만든 버전의 기능은 단순했다:

Obsidian 사이드바에 xterm.js + node-pty 기반 터미널 임베딩
터미널 열면 claude 명령 자동 실행
새 TIL 파일 생성 감지 → Obsidian 에디터에서 자동 열기
Skill 파일 자동 설치 (플러그인 로드 시 .claude/skills/에 배포)

터미널을 임베딩하고 나니 자연스럽게 다음 질문이 따라왔다. "Obsidian 안에서 Claude Code를 쓸 수 있게 됐는데, Claude가 Obsidian의 데이터에도 직접 접근할 수 있으면 어떨까?" 그래서 바로 다음 작업에 들어갔다:

MCP 서버 내장: 플러그인이 localhost:22360/mcp에 HTTP 서버를 띄운다. Claude Code가 이 서버에 연결하면 Obsidian의 vault API를 통해 노트를 읽고, 검색하고, TIL 목록을 조회할 수 있다.
학습 대시보드: 카테고리별 TIL 통계를 보여주는 뷰

여기서 MCP(Model Context Protocol) 서버를 내장한 것이 포인트다. 기존에는 Claude Code가 파일시스템으로 직접 vault를 읽었는데, MCP를 통하면 Obsidian의 메타데이터 캐시를 활용할 수 있다. 검색이 빠르고, frontmatter를 파싱할 필요 없이 바로 접근 가능하다.

Day 5: 완성도 높이기 (2/18)

마지막 날은 사용하면서 느낀 디테일들을 개선하는 시간이었다. 터미널에서 Claude가 출력하는 [[위키링크]]를 클릭하면 Obsidian에서 해당 노트가 열리게 했고(CJK 문자의 2셀 너비 처리가 까다로웠다), 백로그의 미완료 항목을 클릭하면 "이 주제로 TIL을 시작할까요?"라는 안내와 함께 바로 학습을 유도하게 만들었다. 그리고 til_get_context MCP 도구를 추가해서, Claude가 새 주제를 가르치기 전에 학습자가 이전에 뭘 공부했는지 파악할 수 있게 했다.

심화 학습 모드도 만들었다. 기존 TIL 주제로 다시 /til을 실행하면 이전 내용을 유지하면서 새로 배운 것을 자동으로 병합한다. 학습이 일회성이 아니라 반복 가능한 루프가 된 것이다.

이쯤에서 프로젝트의 방향도 정리했다. 핵심 가치는 Claude Code 기반 학습 워크플로우 자체에 있고, Obsidian은 현재의 검증 환경이자 배포 채널이라는 것. 코어 로직은 Obsidian 없이도 성립해야 한다는 철학을 세우고, 실제로 코어 레이어를 순수 함수로 분리하는 리팩토링을 진행했다.

이 경험에서 느낀 것

프롬프트는 코드였다

프롬프트에도 설계 패턴이 있다

Claude Code에서 작성하는 것들 — Skill, Rule, CLAUDE.md, MCP 도구 정의 — 은 결국 다 프롬프트다. 솔직히 그 전까지는 LLM에게 대충 말해도 알아서 잘 해주는 거라고 생각했다. 하지만 Skill을 만들면서 "이렇게 해줘"를 나열하는 것만으로는 부족하다는 걸 깨달았다. Skill을 만들고 개선하면서, 잘 설계된 프롬프트에는 반복되는 패턴이 있다는 걸 알게 됐다.

활성화 조건과 비활성화 조건. Skill에는 "언제 써야 하는지"뿐 아니라 "언제 쓰지 말아야 하는지"를 함께 적어야 한다. /til과 /research는 비슷해 보이지만 목적이 다르다. 이 경계를 명시하지 않으면 Claude가 잘못된 Skill을 선택한다.
실패 모드는 "패턴 → 문제 → 대안" 3단으로. "사용자 동의 없이 저장하지 않는다"보다 "Claude가 Phase 2를 건너뛰고 바로 저장하는 경우가 있다 → 학습 없이 정리만 된 파일이 생긴다 → Phase 2에서 명시적으로 사용자 확인을 받은 후에만 Phase 3으로 넘어간다"가 훨씬 잘 지켜진다.
규칙에 이유를 붙이면 준수율이 올라간다. "Daily 노트도 업데이트하라"보다 "Daily 노트를 빠뜨리면 나중에 그날 뭘 공부했는지 추적할 수 없다"가 효과적이다. 모든 규칙에 존재 이유를 명시하니 Claude가 훨씬 잘 따랐다.

코드에 함수 시그니처와 에러 핸들링이 필요하듯, 프롬프트에도 인터페이스와 계약이 필요하다.

프롬프트도 배포하고 고치는 것이다

Skill은 한번 쓰고 끝이 아니었다. /til로 학습하다 보면 위키링크 형식이 들쭉날쭉하거나, 저장할 때 Daily 노트 업데이트를 빠뜨리는 일이 생겼다. 그러면 Rule에 "위키링크는 반드시 경로 기반 형식을 사용한다"를 추가하고, 저장 체크리스트를 강화했다.

이 과정이 기존 소프트웨어 개발과 놀랍도록 비슷했다. 기능을 배포하고, 버그가 발생하면 원인을 찾고, 테스트를 추가하고, 수정해서 다시 배포하는 — 그 루프를 프롬프트로 돌리고 있었다. Skill 프롬프트가 코드이고, Claude의 잘못된 행동이 버그이고, 활성화/비활성화 조건이나 실패 모드 명시가 테스트인 셈이다.

차이가 있다면 속도다. 코드는 빌드하고 배포해야 하지만, 프롬프트는 파일 하나 고치면 다음 실행부터 바로 반영된다. "이것도 해줘"라고 대화하면 Claude가 Skill 파일 자체를 수정해준다. 이 빠른 피드백 루프 덕분에 5일 동안 Skill이 계속 진화할 수 있었다.

아직 부족한 것들

다만 코드와의 비유가 성립할수록, 코드에서는 당연히 있는 것들이 프롬프트에는 아직 없다는 것도 느꼈다.

디버깅이 불투명하다. 코드는 에러 메시지와 스택 트레이스가 있지만, 프롬프트는 "왜 이 규칙을 안 지켰어?"라고 물어봐야 한다.
테스트가 없다. 코드는 유닛 테스트로 회귀를 잡지만, 프롬프트는 같은 입력에도 다른 결과가 나올 수 있어서 규칙을 고쳤을 때 다른 게 깨지는지 확인할 방법이 마땅치 않다.
컨텍스트 윈도우라는 물리적 한계. 코드는 파일을 나누면 되지만, 프롬프트는 길어질수록 앞의 규칙을 잊는다. Skill, Rule, CLAUDE.md로 나눠봤지만 "어디에 얼마나 써야 하는지"의 감각은 아직 부족하다.
추상화 수준의 균형. 너무 구체적이면 유연성이 없고, 너무 추상적이면 원하는 결과가 안 나온다. 코드의 인터페이스 설계와 같은 고민인데, 아직 정답을 모르겠다.

프롬프트가 코드라면, 프롬프트 엔지니어링은 아직 초기 단계의 소프트웨어 엔지니어링인 셈이다. 배울 것이 더 많다.

AI와 함께 학습하는 것의 의미

"AI한테 물어보면 되는데 왜 공부해?"라는 질문을 받을 수 있다. 하지만 이 5일간의 경험에서 느낀 것은 정반대다. AI가 있어서 더 깊이 공부할 수 있었다.

혼자 Datadog 문서를 읽으면 Agent 설정 페이지에서 30분을 쓰고 지칠 수 있다. Claude와 대화하면 "이게 왜 필요한지", "실무에서 어떻게 쓰는지"를 바로 물어볼 수 있고, 이해한 내용을 확인받을 수 있다. 조사에 쓰는 시간을 줄이고, 이해에 쓰는 시간을 늘린 것이다.

무엇보다 학습이 능동적이었다. 문서를 읽는 건 정보를 받는 것이지만, 대화에서는 "왜?"라고 물어보고, 이해한 걸 내 말로 정리해보고, 틀리면 교정받는다. /til의 Phase 2가 정확히 이 구조다. 질문을 던지는 쪽이 나이기 때문에, 학습의 방향을 내가 정할 수 있었다.

그리고 "저장해줘" 한마디로 정리가 끝나니, 학습 후의 정리 피로감이 없다. 예전에 TIL을 멈추게 만들었던 그 마찰이 사라진 것이다. 다음 주제로 바로 넘어갈 수 있다.

도구를 쓰다가 도구를 만들게 되는 순간

이 프로젝트에서 가장 자연스러웠던 것은 학습 도구를 쓰다가 불편함을 느끼고, 그 불편함을 해결하기 위해 플러그인을 만들게 된 흐름이다.

처음부터 플러그인을 만들겠다고 시작한 게 아니다:

TIL을 지속하고 싶다 → Skill을 만들자
Skill로 열심히 공부하다 보니 → 저장 시 누락이 생긴다 → Rule과 /save Skill 분리
Obsidian에서 보면서 터미널을 왔다갔다 하니 불편하다 → 터미널을 임베딩하자
매번 MCP를 수동 연결하는 게 번거롭다 → 플러그인에 MCP 서버를 내장하자
새 세션에서 이전 학습 맥락을 모른다 → 학습 컨텍스트 도구를 만들자

문제가 먼저 있었고, 도구는 그 다음에 왔다. Claude Code가 이 과정을 빠르게 만들어줬을 뿐이다.

Claude Code를 Claude Code로 배우기

아이러니하지만, 이 프로젝트에서 가장 많이 배운 주제는 Claude Code 자체다. Skill, Rules, MCP, Hooks, Agent Teams — 이 모든 것을 실제로 쓰면서 배웠다. 문서를 읽고 TIL을 쓰는 것이 아니라, TIL 시스템을 만들면서 자연스럽게 Claude Code의 기능을 하나씩 써보게 됐다.

문서를 처음부터 끝까지 읽고 기능을 익힌 게 아니다. 문제가 생길 때마다 "이걸 해결하는 기능이 있나?" 하고 찾아보는 식이었고, 그렇게 찾은 기능을 직접 써보면서 비로소 이해가 됐다.

그리고 문서로 읽은 것과 직접 부딪힌 것의 차이가 컸다. Skill 문서를 읽으면 "프롬프트 파일이다"로 끝나지만, 실제로 만들어보면 활성화 조건과 실패 모드까지 설계해야 한다는 걸 알게 된다. MCP가 뭔지 이론으로만 알았는데, 직접 MCP 서버를 만들어 Obsidian과 Claude Code를 연결해보니 비로소 이해가 됐다. "AI를 위한 USB-C"라는 비유가 왜 적절한지 체감했다.

마무리

연휴 첫날 밤, "뭔가 하고 싶다"는 막연한 생각으로 시작했다. 5일 후의 나는 80개의 TIL이 담긴 Vault와 하나의 Obsidian 플러그인(obsidian-claude-til)을 가지고 있다(비록 나 혼자만 쓰고 있지만).

이 과정에서 가장 중요했던 것은 작게 시작해서 불편함을 따라간 것이다. 처음부터 완벽한 시스템을 설계하지 않았다. Skill 하나로 시작해서, 쓰다가 불편하면 고치고, 고치다가 한계에 부딪히면 새로운 도구를 만들었다. Claude Code가 이 반복을 빠르게 돌릴 수 있게 해줬다.

그리고 한 가지 더. 이 5일이 지치지 않았던 이유는 뭔가를 만들고 있다는 감각, 그리고 그게 재미있었기 때문이다. TIL을 쓰다가 불편함을 느끼고, 그걸 해결하는 도구를 만들고, 그 도구로 다시 학습하고 — 이 루프가 돌 때마다 눈에 보이는 결과물이 쌓였다. 아이디어가 코드가 되고, 코드가 동작하는 플러그인이 되는 과정을 짧은 주기로 반복하면 에너지가 소모되는 게 아니라 오히려 충전된다. "다음엔 뭘 만들지?"라는 생각이 자연스럽게 따라오는 것, 그게 만드는 재미가 주는 가장 큰 보상이었다.

프로젝트: obsidian-claude-til
Vault: obsidian-vault