Blog

NotebookLM과 Obsidian을 묶자 메모가 운영이 됐다
▲ NotebookLM과 Obsidian을 MCP로 묶으며 정리한 지식관리 메모

NotebookLM과 Obsidian을 묶자 메모가 운영이 됐다

노트 툴은 늘 많이 써 왔지만, 솔직히 쌓아 두기만 하고 제대로 연결하지 못한 적도 많았다. Obsidian은 구조화에는 강하지만 관리 난도가 있고, NotebookLM은 읽고 요약하는 흐름이 편하지만 작업 공간 전체와 붙이는 데는 별도 고민이 필요하다. 저도 한동안 두 세계를 따로따로 썼다. 그러다 MCP로 연결하는 흐름을 만들기 시작하니 그제야 ‘메모’가 아니라 ‘지식 운영’에 가까운 감각이 생기기 시작했다.

특히 인상적이었던 건 설치 자체보다 관리 규칙을 먼저 만드는 편이 훨씬 중요하다는 점이었다. 버전 확인, 종속성 점검, 백업, 기존 서버 보존, 설정 파일 경로 관리 같은 것들을 먼저 정리해 두니 이후 흐름이 안정됐다. 그전까지는 툴을 더 붙이는 데 집중했는데, 지금은 MCP를 다루는 방법 자체를 워크플로로 관리하는 일이 훨씬 중요하게 보인다.

“지식관리 도구를 잘 고르는 것보다, 그 도구들을 안전하게 연결하고 유지하는 습관이 훨씬 오래 남는다.”

– NotebookLM MCP와 Obsidian MCP를 다시 엮으면서 가장 크게 남은 실감이다.

메모 연결보다 먼저 설치와 유지보수 흐름을 정리해야 했다

MCP를 하나 설치하는 건 생각보다 어렵지 않다. 문제는 여러 개가 쌓이기 시작할 때다. 버전이 엇갈리고, 종속성이 꼬이고, 기존 설정이 덮어써지고, 어느 순간 무엇이 왜 안 되는지 파악하기 어려워진다. 그래서 저는 MCP 인스톨러 성격의 서브 에이전트를 따로 두는 방식이 꽤 유효하다고 느꼈다. 설치 자체를 자동화하는 것보다, 설치 규칙을 명문화하는 편이 훨씬 안정적이었다.

NotebookLM과 Obsidian의 성격 차이가 오히려 보완 관계로 느껴졌다

NotebookLM은 읽고 정리하고 대화하는 데 강하고, Obsidian은 연결하고 축적하는 데 강하다. 따로 쓰면 장점이 분리돼 있지만, MCP로 묶으면 둘이 생각보다 잘 맞는다. 읽으며 생긴 통찰이 다시 노트 체계로 흘러가고, 정리된 노트가 다시 대화의 맥락으로 들어오면서 지식이 왕복하기 시작한다. 이 흐름이 생기니 ‘메모를 잘 남겼다’보다 ‘지식이 실제로 순환한다’는 느낌이 훨씬 강했다.

좋은 지식관리는 화려한 기능보다 사고를 덜 끊기게 만드는 데 있었다

처음에는 새로운 차원의 지식관리라는 표현이 조금 과장처럼 들릴 수도 있다. 그런데 실제로 써 보면 그 말이 전혀 빈말만은 아니다. 자료를 찾고, 정리하고, 다시 인용하고, 연결하는 과정에서 손이 덜 끊기기 때문이다. 결국 좋은 지식관리의 핵심은 더 많은 노트를 만드는 데 있지 않고, 생각의 흐름을 자주 잃지 않게 만드는 데 있다는 걸 다시 확인했다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: MCP를 붙인 지식관리는 저장 도구의 문제가 아니라 유지보수 가능한 워크플로를 먼저 만드는 문제였다.

실제로 좋아진 부분: NotebookLM의 읽기 흐름과 Obsidian의 축적 구조가 연결되자 지식이 한 방향으로만 쌓이지 않고 순환하기 시작했다.

한 줄 결론: 좋은 지식관리 시스템은 화려한 기능보다 생각이 덜 끊기게 만드는 연결 흐름에서 힘이 나온다.
요즘은 메모 툴 자체보다 메모가 어떤 경로로 흘러가고 다시 돌아오는지를 더 중요하게 보게 된다. 연결만 잘되면 정보는 자산이 되지만, 유지 규칙이 없으면 금방 피곤한 시스템이 된다. 그래서 저한테 이번 구성은 새로운 툴을 하나 더 아는 경험보다, 지식관리도 결국 운영 설계의 문제라는 걸 다시 확인한 사건에 가까웠다.
March 2, 2026
Moltbot으로 원격 에이전트를 굴려 본 기록
▲ Moltbot으로 원격 에이전트 환경을 붙이며 정리한 메모

Moltbot으로 원격 에이전트를 굴려 본 기록

AI 도구를 진지하게 쓰기 시작하면 이상하게 컴퓨터가 쉬는 꼴을 보기 어렵다. 아이디어가 떠오르는데 책상 앞이 아니거나, 이동 중인데 작업을 밀어 두기 아까운 순간이 자주 생기기 때문이다. 저도 그런 이유로 ‘내가 자리를 비운 동안에도 로컬 환경이 계속 일할 수 있을까’를 오래 궁금해했다. 그러다 메시저와 연결되는 에이전트 구조를 직접 붙여 보니, 단순한 편의 기능이 아니라 일하는 방식 자체를 바꿀 수 있겠다는 생각이 들었다.

다만 원격 에이전트는 편리함만 보고 덤빌 수 있는 영역도 아니었다. 바깥에서 명령을 넣는 구조인 만큼 보안과 워크스페이스 경계가 훨씬 중요해진다. 그래서 실제로 만져 보며 제일 먼저 한 건 기능 확장보다 격리였다. Moltbot을 별도 워크스페이스에 두고, 그 안에서만 돌게 만들고, 로그인 방식과 API 방식의 차이를 구분해 두자 비로소 이 구조가 현실적인 도구로 보이기 시작했다.

“원격 에이전트의 핵심은 자유도가 아니라 통제 가능한 범위를 먼저 정해 두는 데 있었다.”

– Moltbot을 붙여 보며 가장 먼저 확인하게 된 원칙이다.

메신저 연결은 곧바로 생산성보다 작업 지속성으로 체감됐다

디스코드나 텔레그램 같은 메신저와 연결한다는 말은 처음엔 조금 장난감처럼 들릴 수 있다. 하지만 실제로는 ‘내가 자리를 비운 동안 작업 흐름이 끊기지 않는다’는 의미가 더 크다. 이동 중에 요청을 던지고, 집에 있는 로컬 머신이 그걸 받아 처리하는 구조는 생각보다 강력했다. 특히 장시간 걸리는 작업이나 반복적인 수정 지시를 계속 이어 갈 수 있다는 점이 꽤 실용적으로 다가왔다.

API 키보다 워크스페이스 격리가 먼저라는 생각이 들었다

원격으로 명령을 넣는 구조는 그만큼 잘못된 방향으로도 빨리 움직일 수 있다. 그래서 어떤 모델을 붙일지보다 어느 폴더까지 접근시키고 어떤 범위 안에서만 움직이게 할지가 더 중요했다. 저는 별도 워크스페이스를 만들고 그 안에서만 설치와 실행이 이뤄지게 하는 쪽이 훨씬 안심됐다. 원격 자동화는 기능이 많을수록 좋다는 식으로 접근하면 오히려 부담이 커질 수 있다.

로그인 기반과 API 기반을 구분해 두는 태도도 중요했다

실무적으로는 이미 구독 중인 로그인 환경을 쓸지, 별도 API 키로 운영할지에 따라 관리 방식이 달라진다. 이 차이를 모호하게 두면 비용과 권한 관리가 같이 흐려진다. Moltbot을 만지면서 저는 원격 에이전트 환경도 결국 하나의 운영 시스템이라는 점을 다시 느꼈다. 편리함은 분명 크지만, 그 편리함을 계속 유지하려면 처음부터 인증, 범위, 워크스페이스 경계를 분명하게 잡아야 한다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 원격 에이전트의 매력은 어디서나 명령할 수 있다는 점보다 작업 흐름을 끊기지 않게 만드는 데 있었다.

먼저 챙겨야 할 부분: 메신저 연결보다 워크스페이스 격리, 인증 방식, 접근 범위를 먼저 정해 두는 편이 훨씬 중요했다.

한 줄 결론: Moltbot 같은 원격 에이전트는 자유도 높은 장난감이 아니라, 통제 가능한 범위를 설계해야 비로소 쓸 만한 시스템이 된다.
밖에서도 에이전트를 계속 일하게 만들 수 있다는 건 분명 매력적이다. 하지만 그 자유도는 설계가 받쳐줄 때만 장점으로 남는다. 저는 그래서 원격 자동화를 볼 때마다 기능보다 경계를 먼저 본다. 일을 더 많이 시키는 것보다, 어디까지 시켜도 안전한지를 먼저 정하는 편이 결국 오래 간다.
March 2, 2026
에이전트 회사는 온톨로지에서 시작됐다
▲ 온톨로지에서 스킬과 MCP까지 이어지는 회사 구조 메모

에이전트 회사는 온톨로지에서 시작됐다

AI를 조직 단위로 붙인다는 말을 처음 들을 때는 대개 에이전트 숫자나 자동화 수준을 먼저 떠올리게 된다. 하지만 실제로 구조를 그려 보면, 에이전트는 맨 위가 아니라 오히려 중간쯤에 위치하는 경우가 많다. 그보다 먼저 와야 하는 건 회사가 어떤 철학과 기준을 갖고 있는지, 어떤 데이터와 노하우를 자산으로 보는지, 어떤 방식으로 일하는지에 대한 설명이다. 저는 이 층을 무시한 채 에이전트만 올리는 방식이 오래가긴 어렵다고 느낀다.

그래서 요즘은 ‘에이전트 회사’라는 말을 들으면 먼저 온톨로지와 토폴로지를 떠올리게 된다. 회사의 DNA와 철학, 영업 방식, 제품 감각, 판단 기준이 온톨로지로 담기고, 그 위에 프로세스 설계가 토폴로지처럼 얹히고, 그 아래에서 랭그래프와 에이전트와 스킬과 MCP가 각자 역할을 맡는 구조 말이다. 이렇게 보니 에이전트 회사는 자동화를 많이 돌리는 조직이 아니라, 자기 일하는 방식을 계층적으로 설명할 수 있는 조직에 더 가까웠다.

“에이전트 조직의 핵심은 AI를 많이 두는 데 있지 않고, 회사의 판단 구조를 어디까지 시스템으로 옮겼는가에 있었다.”

– 온톨로지부터 스킬과 MCP까지 연결된 구조를 그려 보며 가장 선명하게 남은 생각이다.

온톨로지는 회사의 취향과 철학까지 담는 층이어야 했다

회사 운영에서 중요한 것은 매뉴얼만이 아니다. 어떤 미감을 추구하는지, 어떤 고객을 상대하는지, 무엇을 품질로 여기는지 같은 암묵지가 생각보다 크다. 저는 이 부분이 빠지면 AI 시스템도 겉만 그럴듯한 상태에 머무르기 쉽다고 본다. 온톨로지는 단순한 데이터 저장소가 아니라, 조직의 정체성과 기준을 구조로 적어 두는 자리여야 한다.

토폴로지와 워크플로가 붙어야 에이전트가 어디서 일해야 할지 보인다

철학만 있어서는 움직이지 않는다. 영업은 어떤 순서로 진행되는지, 디자인은 어떤 기준과 레퍼런스를 쓰는지, 제품 개발은 어떤 승인 단계를 거치는지 같은 프로세스 설계가 그 위에 얹혀야 한다. 이 토폴로지 층이 있어야 랭그래프와 서브 에이전트가 어디에 들어가야 할지가 자연스럽게 정해진다. 결국 에이전트는 맥락 없는 능력자가 아니라, 구조 안에서 역할을 맡는 실행자에 더 가깝다.

스킬과 MCP는 마지막 장식이 아니라 조직 노하우의 실행 포맷이었다

많은 경우 스킬과 MCP를 편의 기능처럼 보게 되는데, 저는 오히려 조직 지식을 실행 가능한 형태로 굳히는 단계라고 느낀다. 자주 쓰는 판단 패턴은 스킬로, 특정 외부 도구와 연결되는 반복 흐름은 MCP로 정리하면 회사 노하우가 개인 기억에만 머물지 않는다. 이 지점에서 비로소 에이전트 회사라는 말이 현실감을 얻는다. 사람의 감각이 시스템으로 이식되기 시작하기 때문이다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 에이전트 조직은 자동화가 많은 조직이 아니라, 회사의 철학과 프로세스를 계층적으로 설명할 수 있는 조직에 더 가까웠다.

핵심 구조: 온톨로지로 기준을 담고, 토폴로지로 흐름을 설계하고, 그 아래에서 에이전트·스킬·MCP가 실행을 맡는 방식이 훨씬 자연스러웠다.

한 줄 결론: Agentic Company의 본질은 AI를 붙이는 데 있지 않고, 조직의 DNA를 시스템으로 옮기는 데 있다.
앞으로 에이전트 회사라는 말은 점점 흔해질 것이다. 하지만 실제로 차이를 만드는 건 몇 개의 봇을 돌리는지가 아니라, 그 조직이 자기 일을 얼마나 깊게 구조화해 두었는가일 가능성이 크다. 그래서 저한테 이 개념은 미래의 화려한 비전보다, 지금 당장 우리 조직의 판단 구조를 얼마나 설명할 수 있는지 되돌아보게 만드는 질문에 더 가깝다.
March 2, 2026