AI VIDEO BRIEFING
AI 리서치 OS 구축법: 옵시디언 노트를 에이전트 메모리로 만드는 3계층 시스템
흩어진 1만여 개의 노트를 AI 에이전트가 활용하는 개인 리서치 시스템으로 바꾸는 법. 벡터DB 없이 마크다운 파일과 인덱스만으로 만든 3계층 위키 구조를 소개한다.

핵심 메시지
쉽게 이해하기
발표자인 폴 유시틴(Decoding AI 창업자)과 루이-프랑수아 부샤르(Towards AI 공동창업자)는 각각 수천 개에서 수백 개의 노트를 옵시디언·리드와이즈·노션 등에 쌓아두고 있었다. 문제는 양이 아니라, 글을 쓰거나 새 프로젝트를 시작할 때 정작 '신호가 강한' 노트를 제때 떠올려 활용하지 못한다는 점이었다. 두 사람은 이를 해결하기 위해 자신들의 '세컨드 브레인'과 AI 에이전트 사이에 끼워 넣는 개인용 리서치 운영체제(AI Research OS)를 직접 만들었다.
이들은 먼저 도구 선택 기준을 정리한다. 단순한 질문은 구글이나 챗봇으로 충분하지만, 맥락이 길고 반복적으로 파고들어야 하는 작업은 다르다. 노트북LM 같은 도구는 강력하지만 '소유할 수 없고' 개인화가 어렵다는 한계가 있다. 제품 수준에서는 벡터DB 기반 RAG가 유효하나, 매일 가볍게 쓰기엔 사람이 직접 들여다보고 수정하기 불편하다. 그래서 이들은 데이터베이스 없이 파일과 참조만으로 동작하는 가벼운 시스템을 택했다.
시스템은 세 번의 버전을 거치며 발전했다. V1은 직접 고른 '골든 링크'를 씨앗으로 공개 웹을 대상으로 딥리서치를 돌려 정적인 research.md 파일 하나를 만드는 구조였다. 오케스트레이터 에이전트가 여러 질문을 생성하고, 각 하위 에이전트가 검색·요약한 뒤 결과를 다시 모아 압축하는 고전적 딥리서치 루프를 3라운드 돌려 약 40~50개 링크를 모으고, 랭킹으로 신호가 높은 상위 자료만 전체 수집했다.
V2는 그 딥리서치 루프의 대상을 공개 웹에서 자신의 세컨드 브레인(옵시디언·리드와이즈·노션·깃허브 등)으로 돌렸다. 골든 링크를 일일이 고를 필요 없이 토픽만 입력하면, 평소 필터링해 모아둔 개인 자료에서 핵심을 끌어오게 된다. 하지만 결과물인 research.md는 여전히 정적이라, 추가 질문이 생기거나 정보가 낡으면 토큰과 시간을 많이 쓰는 전체 과정을 처음부터 다시 돌려야 하는 한계가 남았다.
V3는 그 위에 'LLM 지식 베이스(위키 계층)'를 얹어 해결한다. 원본 파일은 손대지 않는 불변(raw) 폴더에 두고, index.yaml이 모든 소스의 요약·메타데이터를 담은 카탈로그 겸 진입점이 된다. 위키 폴더에는 LLM이 만든 개념·엔티티·비교·노트 같은 파생물이 쌓인다. 에이전트는 인덱스 → 소스 요약 → 파생 위키 → (그래도 없으면) 원본 순으로 점진적으로 파고들어 토큰을 아낀다. 무엇보다 질문 하나하나가 위키에 흔적을 남겨, 새 개념·비교 파일이 생기며 시스템이 계속 진화한다.
주요 인사이트
- 에이전트 시대의 진짜 병목은 '얼마나 많은 정보를 넣느냐'가 아니라 '미래에 그 정보를 어떻게 다시 활용하느냐'다. 컨텍스트 창은 곧 데이터베이스이자 메모리인데, 대화가 끝나면 모두 사라지기 때문이다.
- 개인용 시스템에는 벡터DB·지식그래프·시맨틱 검색이 오히려 과한 복잡도를 더한다. 컴퓨터의 동작 방식에 뿌리내린 '파일 + 참조' 구조가 가볍고, 사람이 직접 들여다보고 고치기에도 좋다.
- 위키를 세컨드 브레인 전체 위에 두지 않고, 프로젝트 단위로 좁혀 참조하는 것이 핵심이다. 발표자는 PARA 방식으로 정리한 옵시디언 원본을 LLM이 절대 건드리지 않는 '불변 스냅샷'으로 두고, 작업할 때만 딥리서치로 끌어다 쓴다.
- 위키는 데이터를 새로 넣을 때만이 아니라 사용자가 질문을 던질 때마다 진화한다. 이렇게 남는 질문 로그는 '내가 무엇을 아직 이해하지 못했는가'를 비추는 거울이 된다.
- 이 프로젝트의 목표는 완성된 제품이 아니라 메모리·컨텍스트 관리 기법을 가르치는 것이다. 그래서 화려한 UI 대신 클로드 코드·코덱스 터미널 워크플로로 남겨두고, 커넥터 추가 같은 확장은 사용자의 몫으로 열어두었다.
자주 묻는 질문
왜 노트북LM이나 ChatGPT를 그대로 쓰지 않고 별도 시스템을 만들었나요?
노트북LM은 강력하지만 소유·개인화가 어렵고 에이전트 친화적이지 않으며 코딩 작업에 약합니다. ChatGPT 같은 에이전트는 대화가 끝나면 맥락을 잃어, 매번 같은 자료를 다시 붙여 넣어야 합니다. 발표자들은 자신의 노트와 에이전트 사이에서 정보가 시간이 지나도 남아 재활용되는 중간 계층이 필요했습니다.
이 리서치 OS는 어떤 3계층으로 이루어져 있나요?
손대지 않는 원본(raw) 파일, 모든 소스의 요약과 메타데이터를 담아 진입점 역할을 하는 index.yaml, 그리고 LLM이 개념·엔티티·비교·노트 등 파생물을 만들어 쌓는 위키(wiki) 계층입니다. 에이전트는 인덱스부터 시작해 필요한 만큼만 더 깊은 계층을 읽어 토큰을 절약합니다.
벡터 데이터베이스가 꼭 필요하지 않은 이유는 무엇인가요?
발표자는 매일 가볍게 쓰는 개인용 위키에는 벡터DB·지식그래프가 복잡도만 키운다고 봅니다. 대신 마크다운 파일과 참조 기반 인덱스만으로 구성하면 사람이 손으로 들여다보고 수정하기 쉽고, 컴퓨터 파일 시스템의 작동 방식과도 잘 맞습니다. 벡터DB는 대규모 제품 환경에서 더 적합하다고 설명합니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗