Second Brain Template

배경

회의가 끝나면 노션이나 메모에 정리해 두었지만, 며칠만 지나도 헷갈렸습니다. 몇 주에서 몇 달이 지나면 "그때 어떻게 하자고 했었지?"를 다시 묻게 됐습니다. 코드에도 "무엇을 하는지"는 남지만 "왜 그렇게 정했는지"는 남지 않아, AI 에이전트도 코드만 보고는 결정의 이유를 답하지 못합니다.

Second Brain Template은 회의·문서·이슈·결정을 프로젝트 안의 마크다운 볼트에 쌓고, 에이전트가 작업 전에 먼저 찾아보게 하는 템플릿입니다. 2026년 7월부터 혼자 만들고 있고, 세 프로젝트에 적용해 쓰고 있습니다.

만든 것

• 설치 한 줄 — npx github:EM-H20/second-brain-template. 다시 실행하면 노트는 두고 규칙·스킬만 갱신
• 스킬 15개 — 기록하기, 꺼내 쓰기, 점검·정리를 나눠 맡는 워크플로
• 의존성 0 — API 키·임베딩 없이 마크다운과 규칙만 사용. Claude Code·Codex·Gemini 지원

흐름

회의록·문서·이슈를 볼트에 쌓아 두고, 작업할 때 필요한 결정만 꺼내 쓰는 구조입니다.

• 기록하기 — /ingest-meeting은 회의록에서 결정을 뽑아 정리하고, 기존 결정과 부딪히는지 확인합니다. 문서는 /ingest-doc, 이슈와 완료 보고는 /ingest-issue로 넣습니다.
• 꺼내 쓰기 — /recall이 주제와 관련된 결정·이슈·교훈을 브리프로 모으고, /build는 그 브리프를 바탕으로 구현을 시작합니다. 작업 중 생긴 규칙은 /capture로 다시 볼트에 넣습니다.
• 점검·정리 — /check-conflict는 새 의견을 기존 결정과 대조하고, /maintain은 볼트를 다시 묶고 교훈을 모읍니다. /report는 볼트를 근거로 보고서를 만듭니다.

명령어를 외우지 않아도 됩니다. 각 작업이 규칙 파일(SECOND-BRAIN.md)에 의도 단위로 정의돼 있어, "이 회의록 볼트에 넣어 줘"처럼 말해도 같은 흐름이 실행됩니다. Claude Code와 Gemini에서는 세션이 시작될 때 훅이 볼트의 주제 목록을 에이전트에게 자동으로 넣어 줍니다.

쌓인 볼트

적용한 프로젝트 세 곳의 볼트를 Obsidian 그래프 뷰로 열어 본 모습입니다. 점은 노트 하나, 선은 노트 사이의 링크입니다.

벤치마크

볼트가 실제로 답을 정확하게 만드는지 확인하려고, 2026년 9월 경찰과도둑 프로젝트로 1차 벤치마크를 만들었습니다.

세 조건을 비교했습니다. 모두 같은 코드 저장소를 갖고, 볼트와 도구만 다릅니다.

• A — 볼트 + 스킬 + 규칙 파일
• B — 볼트만
• C — 코드만

문항은 31개입니다. 결정 이유, 폐기된 결정 함정, 기록이 없어 "모름"이 정답인 문제, 코드 위치, 과거 이슈 재발, 볼트와 코드가 어긋난 경우, 작은 구현 과제로 구성했습니다. 문항마다 들어가야 할 정답 사실과 하면 안 되는 답을 미리 적었습니다.

채점은 두 가지로 했습니다. 인용한 파일 경로가 실제로 있는지는 스크립트로 확인하고, 정답을 맞혔는지는 다른 모델(Sonnet)이 판정했습니다. 조건마다 31회씩 모두 93회 실행했습니다.

결과

• 정확도는 볼트가 있으면 0.97, 코드만 있으면 0.71이었습니다.
• "왜 이렇게 정했나" 질문은 1.0 대 0.0이었습니다. 코드만 있는 조건은 지어내지 않고 "기록이 없다"고 답했습니다.
• 없는 경로를 인용한 비율은 8.3%에서 0.8%로 줄었습니다.
• 코드 위치 문항은 세 조건이 모두 1.0이었습니다. 볼트가 필요 없는 대조군이 동률이라, 위의 차이는 볼트에서 나왔다고 볼 수 있습니다.

예상과 다른 결과도 있었습니다. 자연어 질문 31개에서 스킬은 한 번도 자동으로 실행되지 않았습니다. 에이전트가 볼트를 찾아본 것은 규칙 파일을 따랐기 때문이었고, 토큰은 볼트만 있는 B가 가장 적게 썼습니다.

한계

• 문항당 1회만 실행해, 한두 문항 차이는 우연일 수 있습니다.
• 정답표를 사람이 다시 검수하지 않았고, 구현 과제에는 컴파일 검사가 없습니다.
• 다음에는 3회 반복 실행과, 스킬을 직접 호출하는 조건을 추가할 계획입니다.

디스코드 브레인 봇

• 상황경찰과도둑 팀에 볼트를 도입했습니다. 팀원 7명 중에는 개발자가 아닌 사람도 있었습니다.
• 문제비개발자 팀원은 볼트를 쓰기 어려웠습니다. 볼트는 Claude Code와 Obsidian으로 여는 저장소라, 개발 도구를 쓰지 않으면 열어 볼 방법이 없었습니다. 행사 현장처럼 밖에 있을 때는 개발자도 바로 확인할 수 없었습니다.
• 결정2026년 10월 17일, 팀 디스코드에서 말로 물으면 볼트를 찾아 답하는 봇을 만들었습니다. 예전에 게임 길드 디스코드에서 만들어 운영한 봇 플래닝의 경험을 참고했고, 특히 플래닝이 매주 공지사항 링크를 자동으로 보내던 기능이 아래 아침 소식의 바탕이 됐습니다. 답에는 근거 노트 id(예: DEC-0092)를 붙이고, 찾지 못하면 찾지 못했다고 말합니다. "사업자등록증 줘"처럼 말하면 원본 파일을 첨부합니다.
• 구조discord.js 봇이 질문마다 Claude(Sonnet) 도구 루프를 한 번 돌려, 서버에 받아 둔 볼트를 검색하고 노트 본문을 읽은 뒤 답합니다. 도구 호출은 질문당 8회로 묶었고, 볼트는 5분마다 GitHub에서 받아 옵니다. 테스트 146개가 있습니다.
• 읽기만 하는 봇: "지식화 남겨"라고 하면 볼트를 직접 고치지 않고 GitHub 이슈로 접수만 합니다. 반영은 담당자가 Claude Code에서 해서, 원본 보존·무결성 검사 같은 볼트 규칙을 사람이 확인한 경로로만 지킵니다.
• 아침 소식: 월·수·금 아침마다 창업 지원사업·공모전·행사 공고를 웹에서 모아 카드 한 장으로 올립니다. 이번 실행에서 실제로 열어 본 링크와, 공고에서 읽은 마감일만 코드가 다시 걸러 통과시킵니다.
• 결과만든 직후 시험 사용에서 질문 17건을 받아 11건에 답하고 4건을 이슈로 접수했고, 평균 응답은 9초였습니다. 월 $100 API 크레딧 안에서 운영합니다. 실제 팀 사용 지표는 아직 쌓이는 중입니다.

접수 이슈를 디스코드 없이 읽히게

• 문제처음에는 스레드의 사용자 메시지만 이어 붙여 이슈를 만들어서, 봇의 답이 빠졌습니다. 담당자는 디스코드를 열어야 무엇을 남기라는 건지 알 수 있었습니다. 이슈 생성이 실패하면 요청이 어디에도 남지 않았는데, 봇은 저장했다고 안내했습니다.
• 해결실패하면 원문을 서버에 남기고 담당자에게 알리게 했습니다. 이슈에는 디스코드 원문 대신, 봇이 대화 맥락을 정리한 "지식화할 내용"을 꼭 넣게 했습니다. 담당자가 Claude Code의 /capture에 바로 넣는 형태입니다.
• 결과바뀐 형식으로 처음 들어온 접수는 배경·관련 노트·확인할 점이 정리된 채 왔고, 그대로 볼트 노트(DOC-0083)가 됐습니다.

아침 소식은 시험 실행으로 프롬프트 조정

• 문제마감일은 직접 열어 본 공고 페이지에서 읽은 것만 카드에 실리는데, 시험 실행에서 봇은 페이지 열기 한도 10번 중 4번만 쓰고 끝냈습니다. 또 연구성과·보유기술이 있어야 하는 공고, 특정 학교·기관 소속만 지원할 수 있는 공고처럼 우리 팀이 지원할 수 있는지 알 수 없는 공고가 "확인 필요"라는 표시를 달고 올라왔습니다.
• 해결남은 열기 한도는 맞아 보이는 공고의 상세 페이지를 여는 데 끝까지 쓰게 했습니다. 사이트 첫 화면이나 목록 페이지는 열지 않게 했습니다. "확인 필요"라고 적어야 할 공고는 아예 빼도록 프롬프트를 고쳤습니다.
• 결과다시 돌리니 열람이 8번으로 늘었고, "확인 필요" 공고는 더 올라오지 않았습니다.

배운 점

• 기대와 측정은 다릅니다. 볼트의 효과는 숫자로 확인됐지만, 스킬이 알아서 실행된다는 전제는 틀렸습니다.
• 대조군이 있어야 차이를 믿을 수 있습니다. 코드 위치 문항이 동률이었기 때문에 다른 차이를 볼트의 효과로 읽을 수 있었습니다.