Deciflow Notes
일 읽기노트 · 2026년 6월 12일

세컨 브레인은 노트앱이 아니라, AI가 참조할 나의 운영체제다

요즘IT 글 「나만의 세컨 브레인: 옵시디언 기반 LLM 위키 구축기」를 읽고

여러 AI 도구를 쓸수록 매번 맥락을 다시 설명해야 하는 문제를, 옵시디언·깃허브·Claude Code 기반 LLM 위키라는 개인 컨텍스트 운영체제로 바라본다.

처음 걸린 생각

AI를 많이 쓰게 되면 생산성이 올라갈 것 같지만, 어느 순간 반대의 피로가 생긴다. 클로드에는 프로젝트 맥락을 설명하고, 챗GPT에는 다시 내 상황을 설명하고, 코드 에이전트에는 또 폴더 구조와 의사결정 기록을 알려줘야 한다. 도구는 똑똑해졌는데, 사용자는 계속 자기소개를 반복한다.

요즘IT의 「나만의 세컨 브레인: 옵시디언 기반 LLM 위키 구축기」는 이 피로를 “프롬프트를 더 잘 쓰자”가 아니라 “나를 데이터로 다루는 시스템을 만들자”는 방향으로 푼다. 옵시디언에 개인 자료를 모으고, 깃허브 Private Repo로 동기화하고, Claude Code가 인입·질의·점검을 돕는 구조다.

내게는 이 글이 노트앱 사용기가 아니라, 앞으로 개인과 조직이 AI와 일하기 위해 필요한 “맥락 운영체제”의 초안처럼 읽혔다.

문제는 AI가 모르는 것이 아니라, 매번 새로 알려줘야 한다는 것

글의 출발점은 단순하다. AI 도구가 늘어날수록 같은 설명을 반복하게 된다.

“사용하는 AI 도구가 늘어날수록 우리는 늘 컨텍스트를 새로 전달해야 하는 번거로움을 겪게 됩니다.”

이 문장은 지금의 AI 활용에서 꽤 중요한 병목을 짚는다. 많은 사람은 더 좋은 모델, 더 긴 컨텍스트, 더 멋진 프롬프트를 찾지만, 실제 업무에서는 “내가 어떤 일을 해왔고, 무엇을 중요하게 보고, 지금 어떤 프로젝트가 걸려 있는가”가 계속 빠진다.

그래서 AI 답변은 자주 일반론이 된다. 틀린 말은 아닌데, 내 상황에 딱 붙지 않는다. 회의록, 메모, 프로젝트 문서, 의사결정 기록, 관계자 정보, 개인의 판단 기준이 흩어져 있으면 AI도 매번 빈손으로 시작한다.

이 글의 핵심은 그 흩어진 맥락을 하나의 볼트에 모아, AI가 반복해서 참조할 수 있게 만드는 데 있다. 세컨 브레인이 사람만 읽는 창고가 아니라, AI가 읽고 작업하는 기반이 되는 것이다.

옵시디언은 예쁜 노트앱이 아니라, 파일 기반 맥락 저장소다

글쓴이는 여러 도구를 시험한 끝에 옵시디언을 선택한다. 이유는 빠른 속도, 안정적인 동기화, 그리고 자기 워크플로우와의 적합성이다. 여기서 중요한 점은 옵시디언 자체의 유행이 아니라, 파일 기반 지식 관리가 AI 작업과 잘 맞는다는 점이다.

옵시디언 볼트는 결국 로컬 폴더 안의 마크다운 파일 묶음이다. 사람은 그래프 뷰와 링크로 읽고, AI 에이전트는 파일 시스템으로 읽고 수정한다. 노션처럼 닫힌 UI 안에 갇힌 문서보다, CLI 에이전트가 접근하기 쉽다.

글에 나온 구성은 꽤 현실적이다.

이 조합을 보면 세컨 브레인의 중심은 “잘 정리된 폴더”가 아니라 “계속 들어오고, 합쳐지고, 점검되는 흐름”에 있다. 자료를 쌓는 것보다 더 중요한 것은 자료가 위키 안에서 제자리를 찾고, 오래된 링크와 민감 정보가 주기적으로 점검되는 일이다.

CLAUDE.md는 개인 위키의 운영규정이 된다

흥미로웠던 부분은 CLAUDE.md의 역할이다. 글쓴이는 옵시디언 볼트의 루트에 CLAUDE.md를 두고, 새 세션마다 운영 규칙이 시스템 컨텍스트처럼 주입되도록 한다.

“CLAUDE.md가 사실상 위키 운영 매뉴얼로서 AI 작업의 일관성을 확보하는 역할을 하게 됩니다.”

이건 개인 위키뿐 아니라 조직 지식관리에도 그대로 적용할 수 있는 패턴이다. 지식 저장소가 커질수록 문제는 “무엇을 저장할까”보다 “어떤 방식으로 저장하고 고칠까”가 된다. 파일명 규칙, 링크 방식, 민감정보 처리, 임시 자료의 위치, 확정본과 초안의 구분이 없으면 AI는 매번 다른 방식으로 정리한다.

결국 LLM 위키에는 두 종류의 지식이 필요하다.

첫째, 내용으로서의 지식. 내가 누구인지, 어떤 프로젝트를 하는지, 어떤 생각과 기준을 갖고 있는지에 대한 기록이다.

둘째, 운영 방식으로서의 지식. 이 위키는 어떻게 읽고, 어디에 쓰고, 무엇을 삭제하지 말아야 하며, 어떤 정보는 마스킹해야 하는지에 대한 규칙이다.

AI 에이전트와 함께 쓰는 위키에서는 두 번째가 특히 중요하다. 사람은 맥락을 눈치로 보완하지만, 에이전트는 규칙이 없으면 과감하게 잘못 정리할 수 있기 때문이다.

좋은 LLM 위키는 ‘수집함’보다 ‘정합성 점검’이 중요하다

글에서 가장 현실적인 부분은 한계에 대한 이야기였다. 이미지 기반 자료를 AI가 잘못 읽어 사실관계가 어긋났고, 민감정보 마스킹도 완벽히 믿기 어려웠다고 한다. GitHub Private Repo를 써도 계정 탈취 위험은 남고, 개인 위키와 팀 위키를 분리해야 하는 문제도 있다.

이 대목이 좋았다. LLM 위키는 자동화의 낭만만으로 굴러가지 않는다. 오히려 자동화할수록 검수와 보안이 더 중요해진다.

특히 개인 컨텍스트는 정보의 밀도가 높다. 일정, 가족, 자산, 관계, 건강, 프로젝트, 비밀번호 힌트, 결제 정보가 섞일 수 있다. AI가 잘 쓰면 강력한 개인 비서가 되지만, 잘못 다루면 위험한 단일 장애점이 된다.

그래서 “모든 것을 넣자”보다 먼저 정해야 할 질문이 있다.

세컨 브레인의 성숙도는 수집량이 아니라 정합성에서 갈릴 것 같다. 많이 넣는 사람보다, 오래 믿고 다시 꺼내 쓸 수 있게 관리하는 사람이 이득을 본다.

내 쪽으로 가져오면

Deciflow Notes 관점에서 이 글은 꽤 직접적인 작업 질문을 남긴다. 이미 개인 메모, 프로젝트 문서, 회의 기록, 웹 글 정리, 전사 파일, Power BI 분석 기록이 여러 층으로 쌓이고 있다. 문제는 “어디에 저장했나”가 아니라, “AI가 다음 작업에서 바로 참조할 수 있는 구조인가”다.

내 쪽으로 가져오면 작은 실험은 이렇게 잡을 수 있다.

첫째, 수집함과 확정 지식을 분리한다. 웹에서 가져온 글, 캡처, 임시 메모는 곧바로 ‘지식’이 아니라 ‘수집물’이다. AI가 이를 확정 사실처럼 쓰지 않도록 상태를 분리해야 한다.

둘째, 프로젝트마다 운영 문서를 둔다. 어떤 파일을 원본으로 보고, 어떤 산출물을 최종본으로 보며, 어떤 명명 규칙을 쓸지 적어둔다. 사람을 위한 README이면서 AI를 위한 작업 규칙이어야 한다.

셋째, ingest보다 lint를 먼저 설계한다. 새 자료를 넣는 자동화는 신나지만, 잘못 들어간 지식은 오래 남는다. 깨진 링크, 중복 노트, 민감정보, 오래된 주장, 출처 없는 요약을 잡는 점검 루틴이 먼저 필요하다.

넷째, 개인 위키와 공개 노트를 분리한다. 공개 가능한 생각은 Notes로 나가고, 사적인 맥락과 업무 내부 자료는 별도 위키에 남아야 한다. 둘은 연결될 수는 있어도 같은 저장소가 되면 안 된다.

오늘의 결론

이 글을 읽고 남은 결론은 간단하다. AI를 잘 쓰는 사람은 앞으로 프롬프트를 잘 쓰는 사람에서, AI가 참조할 자기 맥락을 잘 운영하는 사람으로 이동할 가능성이 크다.

세컨 브레인은 더 이상 “나중에 내가 다시 읽을 노트”에만 머물지 않는다. AI가 나를 대신해 검색하고, 정리하고, 질문에 답하고, 다음 행동을 제안하려면 그 AI가 믿고 읽을 수 있는 맥락 저장소가 필요하다.

다만 그 저장소는 한 번에 완성되는 구조물이 아니다. 글쓴이의 마지막 조언처럼 처음부터 완벽한 카테고리와 자동화를 만들려고 하면 오히려 멈추게 된다. 작게 시작하고, 자주 정리하고, 민감정보를 조심하고, AI가 읽어도 되는 운영 규칙을 남기는 것. 그 정도가 지금 당장 시작할 수 있는 현실적인 세컨 브레인 구축법에 가깝다.

원문

원문 글: 나만의 세컨 브레인: 옵시디언 기반 LLM 위키 구축기 · 요즘IT · 곰씨네 IT 블로그