Claude는 추론 능력이 믿기지 않을 정도로 뛰어납니다.

하지만 추론은 사용 가능한 컨텍스트(Context)가 있는 만큼만 유용합니다.

당신의 아키텍처는 GitHub에 있을 수 있습니다. 당신의 노트는 Obsidian에 있을 수 있습니다. 당신의 결정 사항은 Slack에 묻혀 있을 수 있습니다. 당신의 연구 자료는 PDF에 있을 수 있습니다. 당신의 프로젝트 이력은 수백 개의 대화 속에 존재할 수 있습니다.

정보는 존재합니다.

문제는 당신의 AI가 이를 이해할 수 있는 통합된 방법을 가지고 있지 않다는 것입니다.

그래서 저는 다음과 같은 생각을 하기 시작했습니다:

만약 Claude에게 지속적인 세컨드 브레인(Second Brain)이 있다면 어떨까?

또 다른 챗봇이 아닙니다. 또 다른 벡터 데이터베이스(Vector Database)도 아닙니다.

Claude가 쿼리(Query)하고, 학습하며, 다시 쓸 수 있는 지식 계층(Knowledge Layer)입니다.

세컨드 브레인(Second Brain)이란 무엇인가?

세컨드 브레인은 당신의 생물학적 기억력 외부에 정보를 캡처, 정리, 연결 및 검색할 수 있도록 돕는 개인 지식 관리 시스템입니다.

Obsidian과 같은 도구들이 이 아이디어를 강력하게 만들었습니다.

당신은 간단한 Markdown 노트를 작성하고 이들을 연결할 수 있습니다:

InsightTrack
    │
    ├── [[DuckDB]]
...

그러면 Obsidian은 이러한 관계의 시각적 그래프(Graph)를 생성합니다.

하지만 한계가 있습니다:

Obsidian은 당신이 명시적으로 생성한 관계만을 알고 있습니다.

AI는 이를 훨씬 더 멀리 확장할 수 있습니다.

다음과 같은 상황을 상상해 보세요:

architecture.md
      │
      └── DuckDB를 언급함
...

사람은 이 네 가지를 모두 수동으로 연결하지 못할 수도 있습니다.

하지만 AI 네이티브 지식 시스템은 이러한 관계를 자동으로 발견할 수 있습니다.

세컨드 브레인에서 AI 브레인으로

전통적인 세컨드 브레인은 주로 다음과 같은 질문에 답합니다:

"이걸 어디에 저장했지?"

AI 네이티브 세컨드 브레인은 다음과 같이 답해야 합니다:

"우리가 이것에 대해 무엇을 알고 있는가? 이것은 어디에서 왔으며, 다른 모든 것과 어떻게 연결되어 있는가?"

이를 위해서는 벡터 검색(Vector Search) 이상의 것이 필요합니다.

여러 검색 전략(Retrieval Strategies)이 함께 작동해야 합니다.

왜 전통적인 RAG만으로는 충분하지 않은가

전형적인 RAG 아키텍처는 다음과 같습니다:

Documents (문서)
    ↓
Chunking (청킹)
...

이 방식은 의미론적 유사성(Semantic Similarity) 측면에서 매우 잘 작동합니다.

질문해 보세요:

"우리 분석 아키텍처의 이면에 있었던 추론은 무엇이었나?"

벡터 검색 (Vector search)은 정확한 표현이 다르더라도 관련 있는 논의를 찾아낼 수 있습니다.

하지만 이제 이렇게 질문해 보세요:

"SYNC_BATCH_SIZE는 어디에 정의되어 있는가?"

이것은 정확한 식별자 (identifier)입니다.

이런 경우에는 키워드 검색 (Keyword search)이 더 낫습니다.

또는 이렇게 질문할 수도 있습니다:

"어떤 서비스들이 PostgreSQL에 의존하는가?"

이것은 관계 (relationship)에 관한 질문입니다.

이런 경우에는 지식 그래프 (knowledge graph)가 더 낫습니다.

이것이 바로 제가 진정한 AI 세컨드 브레인 (Second Brain)에는 Multi-RAG가 필요하다고 생각하는 이유입니다.

Multi-RAG: 질문의 유형에 따라 다른 검색 방식이 필요합니다

단 하나의 검색 기술에만 의존하는 대신:

Semantic Search (의미론적 검색)
       +
Full-Text Search (전체 텍스트 검색)
...

각 방법은 서로 다른 문제를 해결합니다.

Semantic RAG (의미론적 RAG)

개념을 이해하는 데 유용합니다.

"왜 우리가 DuckDB를 선택했는가?"

Keyword RAG (키워드 RAG)

정확한 정보를 찾는 데 유용합니다.

"SYNC_BATCH_SIZE에 대한 참조를 찾아줘."

Graph RAG (그래프 RAG)

관계(relationships)를 파악하는 데 유용합니다.

"어떤 서비스들이 PostgreSQL에 의존하는가?"

Memory Retrieval (메모리 검색)

의사 결정 및 지속적인 문맥 (context)을 파악하는 데 유용합니다.

"분석 아키텍처에 대해 우리가 결정한 것은 무엇인가?"

이러한 방식들을 결합하면 벡터 검색 (vector search)만 사용할 때보다 훨씬 더 풍부한 문맥을 제공할 수 있습니다.

아키텍처 (The Architecture)

[IMG:1]

중요한 아이디어는 개별 구성 요소 그 자체가 아닙니다.

구성 요소들이 어떻게 함께 작동하느냐 하는 것입니다.

Obsidian / Documents / External Sources
                │
                ▼
...

Obsidian은 인간을 위한 인터페이스입니다

저는 Obsidian을 세컨드 브레인 전체라고 보지 않습니다.

저는 이를 가장 뛰어난 인간 중심의 지식 인터페이스 (human-facing knowledge interfaces) 중 하나로 봅니다.

여러분은 자연스럽게 글쓰기를 계속할 수 있습니다:

# Analytics Architecture

InsightTrack은 분석 쿼리를 위해 [[DuckDB]]를 사용합니다.
...

Obsidian은 인간이 읽을 수 있는 노트와 네이티브 그래프 (native graph)를 제공합니다.

AI 시스템은 그 위에 또 다른 레이어를 추가하는 것입니다.

두 개의 그래프, 두 개의 목적

이 아키텍처는 두 가지 서로 다른 그래프를 유지할 수 있습니다.

Obsidian 그래프

명시적인 링크 (explicit links)를 통해 생성됩니다:

[[InsightTrack]]
       │
       ▼
...

이것은 주로 **인간의 탐색 (human navigation)**을 위해 유용합니다.

시스템 엔티티 그래프 (System Entity Graph)

사용 가능한 모든 지식으로부터 자동으로 추출됩니다:

InsightTrack
      │
     USES
...

Pulse PostgreSQL

시스템 그래프는 다음 항목들로부터 구축될 수 있습니다:

• Markdown
• 소스 코드 (Source code)
• Git 커밋 (Git commits)
• 풀 리퀘스트 (Pull requests)
• 데이터베이스 스키마 (Database schemas)
• 문서 (Documentation)
• 대화 (Conversations)
• 회의록 (Meeting notes)

이 그래프는 단순히 시각화만을 위한 것이 아닙니다.

이는 검색 (Retrieval)의 일부가 됩니다.

지식 공학 (Knowledge Engineering) + 그래프 공학 (Graph Engineering)

이 지점에서 아키텍처는 일반적인 RAG 애플리케이션보다 더 흥미로워집니다.

**지식 공학 (Knowledge Engineering)**은 가공되지 않은 정보 (Raw information)를 구조화된 지식으로 변환합니다.

회의 녹취록 (Meeting Transcript)
        ↓
     요약 (Summary)
...

**그래프 공학 (Graph Engineering)**은 결과물인 엔티티 (Entities)들을 연결합니다.

프로젝트 (Project)
   ↓
리포지토리 (Repository)
...

그 결과는 단순한 문서의 집합이 아닙니다.

연결된 지식 모델 (Connected knowledge model)입니다.

검색 엔진 (The Retrieval Engine)

검색 엔진은 단연코 가장 중요한 부분입니다.

만약 당신이 다음과 같이 질문한다고 가정해 봅시다:

왜 분석 쿼리를 PostgreSQL에서 DuckDB로 옮겼나요?

시스템은 다음과 같은 것들을 검색할 수 있습니다:

GitHub PR
      +
아키텍처 노트 (Architecture Note)
...

그 다음 결과들을 재순위화 (Rerank)하고 결합합니다.

Claude에게 수천 개의 청크 (Chunks)를 전달하는 대신, 시스템은 집중된 컨텍스트 (Focused context)를 구축합니다:

결정 사항 (Decision):
분석 워크로드에는 DuckDB를 사용함.

...

이제 Claude는 **증거 (Evidence) + 관계 (Relationships) + 메모리 (Memory)**를 바탕으로 추론합니다.

장기 메모리 (Long-Term Memory)

세컨드 브레인 (Second Brain)이 모든 것을 기억해서는 안 됩니다.

그렇지 않으면, 그것은 또 다른 거대한 데이터베이스가 되어버릴 것입니다.

중요한 것을 기억해야 합니다.

예를 들어:

결정 사항 (Decision)
────────────────────
PostgreSQL이 신뢰할 수 있는 원천 (Source of truth)으로 유지됨.
...

이는 수천 개의 가공되지 않은 대화 (Raw conversations)를 저장하는 것보다 훨씬 더 가치 있습니다.

시스템은 다음과 같은 것들을 구분해야 합니다:

가공되지 않은 데이터 (Raw Data)
   ↓
정보 (Information)
...

이것이 AI 메모리를 유용하게 만드는 중요한 부분입니다.

MCP는 세컨드 브레인을 Claude에 연결합니다

이 지점에서 아키텍처는 AI 네이티브 (AI-native)가 됩니다.

Claude에 직접 커스텀 통합 (Custom integration)을 구축하는 대신, MCP를 통해 세컨드 브레인을 노출하십시오.

예를 들어:

search()
retrieve()
remember()
...

Claude는 다음과 같이 요청할 수 있습니다:

search(
  "Why did we choose DuckDB?"
)

세컨드 브레인(Second Brain)이 이러한 복잡성을 처리합니다.

Claude는 답변이 다음 중 어디에서 왔는지 알 필요가 없습니다:

PostgreSQL
pgvector
Search Index
...

Claude는 그저 유용한 컨텍스트 (Context)를 전달받을 뿐입니다.

Claude는 다시 쓸 수 있습니다 (Claude Can Write Back)

이 지점에서 이 시스템은 전통적인 RAG (Retrieval-Augmented Generation) 그 이상이 됩니다.

흐름이 단순히 다음과 같지 않기 때문입니다:

지식 (Knowledge) → AI

대신 다음과 같이 변합니다:

지식 (Knowledge) ↔ AI

예를 들어:

"우리가 PostgreSQL을 신뢰할 수 있는 단일 원천 (Source of Truth)으로 유지하기로 결정했다는 점을 기억해 둬."

Claude는 다음과 같이 호출합니다:

remember(...)

그러면 시스템은 다음과 같은 작업을 수행할 수 있습니다:

엔티티 추출 (Extract Entities)
       ↓
관계 추출 (Extract Relationships)
...

지식 베이스 (Knowledge Base)는 점진적으로 더욱 풍부해집니다.

모델은 지식을 소유하지 않습니다

이것은 가장 중요한 아이디어 중 하나입니다.

현재는 다음과 같습니다:

Claude
   ↓
Claude 메모리 (Claude Memory)

다른 AI는:

GPT
   ↓
GPT 메모리 (GPT Memory)

또 다른 AI는:

Gemini
   ↓
Gemini 메모리 (Gemini Memory)

모든 것이 격리되어 있습니다.

대신 다음과 같이 구성됩니다:

             Claude
                │
               GPT
...

모델은 바뀔 수 있습니다.

하지만 지식은 그대로 남습니다.

더 큰 아이디어

저는 미래가 단순히 다음과 같을 것이라고 생각하지 않습니다:

"Claude에게 더 많은 컨텍스트를 제공하라."

제가 생각하는 미래는 다음과 같습니다:

모든 AI가 사용할 수 있는 지속 가능한 지식 계층 (Persistent Knowledge Layer)을 구축하라.

Obsidian은 인간을 위한 지식 인터페이스로 남을 수 있습니다.

GitHub는 소스 코드 시스템으로 남을 수 있습니다.

Slack은 커뮤니케이션 시스템으로 남을 수 있습니다.

데이터베이스는 데이터 시스템으로 남을 수 있습니다.

AI 어시스턴트는 추론 시스템 (Reasoning Systems)으로 남을 수 있습니다.

Knowledge OS가 이 모든 것을 연결합니다.

세컨드 브레인을 넘어

전통적인 세컨드 브레인은 당신이 기억하는 것을 돕습니다.

AI 네이티브 세컨드 브레인은 AI가 이해하는 것을 돕습니다.

이 시스템은 다음을 결합합니다:

• 지식 공학 (Knowledge Engineering) — 가공되지 않은 정보를 구조화된 지식으로 변환
• 그래프 공학 (Graph Engineering) — 엔티티 (Entities)와 관계 (Relationships) 발견
• 하이브리드 검색 (Hybrid Retrieval) — 의미론적 (Semantic), 키워드 (Keyword), 그래프 검색의 결합
• 장기 메모리 (Long-Term Memory) — 결정 사항 및 중요한 컨텍스트 보존
• MCP (Model Context Protocol) — AI 에이전트와 어시스턴트가 지식에 접근할 수 있도록 구현

그 결과물은 단순한 노트 테이킹 애플리케이션이나 벡터 데이터베이스 (Vector Database) 그 이상의 무언가가 됩니다.

지식 공학 (Knowledge Engineering), 그래프 공학 (Graph Engineering), 하이브리드 검색 (Hybrid Retrieval), 그리고 장기 기억 (Long-Term Memory)을 결합하여 MCP 및 API를 통해 접근 가능한 통합 플랫폼으로 구현된 AI 네이티브 지식 운영체제 (Knowledge Operating System).

LLM은 추론 (Reasoning)을 제공합니다.

지식 운영체제 (Knowledge OS)는 기억 (Memory)을 제공합니다.

그리고 MCP는 그 둘 사이를 잇는 가교가 됩니다.