
Oracle AI Database를 활용한 자가 개선형 세컨드 브레인 구축하기
요약
Oracle AI Database를 활용하여 데이터, 임베딩, 에이전트 메모리를 통합 관리하는 자가 개선형 세컨드 브레인 구축 가이드를 제공합니다. MCP를 통해 다양한 AI 클라이언트와 연결하여 컨텍스트를 공유하고 데이터 락인을 방지할 수 있습니다.
핵심 포인트
- Oracle AI Database를 통합 메모리 및 검색 레이어로 활용
- MCP를 통해 Claude, ChatGPT 등 다양한 AI 도구와 연결 가능
- 데이터, 임베딩, 에이전트 메모리를 단일 DB에서 통합 관리
- 새로운 데이터 수집을 통해 시스템이 스스로 개선되는 구조
- 개인정보 보호를 위한 보안 설계 및 인간의 승인 프로세스 강조
단계별 구축 가이드: 당신이 만든 모든 것을 위한 자신만의 세컨드 브레인(second brain)을 만들어 보세요. 의미 기반 검색이 가능하며, MCP를 통해 사용하는 모든 AI 채팅에 연결할 수 있고, 그 위에 자가 개선형 에이전트(self-improving agents)가 구축됩니다. 데이터, 임베딩(embeddings), 그리고 에이전트의 메모리(memory)가 모두 하나의 데이터베이스에 저장됩니다.
컴패니언 노트북(Companion notebook): https://github.com/oracle-devrel/oracle-ai-developer-hub/tree/main/apps/second-brain
핵심 요약 (Key takeaways)
- 이 블로그는 Oracle AI Database 상에 개인용 "세컨드 브레인"을 구축하는 방법을 보여줍니다. 콘텐츠, 임베딩(embeddings), 합성된 위키 페이지, 그리고 에이전트 메모리(agent memory)를 하나의 데이터베이스에 저장하여 서로 다른 AI 클라이언트와 에이전트가 동일한 컨텍스트(context)를 공유할 수 있도록 합니다.
- MCP는 AI 도구 간에 브레인을 이동 가능하게 만듭니다. 시스템이 Model Context Protocol (MCP) 서버를 통해 브레인을 노출하기 때문에, 사용자는 데이터를 이동시키지 않고도 Claude, ChatGPT 또는 오픈 소스 클라이언트에 연결할 수 있습니다.
- Oracle AI Database는 통합 메모리 및 검색 레이어로 사용됩니다. 이 구축 과정에서는 관계형 데이터(relational data), JSON Relational Duality, AI Vector Search, 데이터베이스 내 MiniLM 임베딩(embeddings), 하이브리드 검색(hybrid search), 그리고 에이전트 메모리 테이블(agent memory tables)을 하나의 엔진에서 사용합니다.
- 시스템은 시간이 지남에 따라 개선됩니다. 새로운 콘텐츠가 수집, 임베딩(embedded), 분류되어 위키에 추가되고 메모리를 업데이트하는 데 사용되므로, 사용자가 더 많은 자료를 추가할수록 리서치 에이전트(research agent)와 향후 에이전트들이 더욱 유용해집니다.
- 설계의 중심에는 개인정보 보호와 보안이 있습니다. 이 블로그는 가시성 범위 지정(visibility scoping), 검색 및 메모리 통합 시 개인 데이터 제외, 비밀번호 스캐닝(secret scanning), 최소 권한 데이터베이스 액세스(least-privilege database access), 인증된 MCP 호스팅, 그리고 쓰기 도구에 대한 인간의 승인(human approval)을 강조합니다.
만약 당신이 매일 AI와 함께 작업한다면, 아마 이 두 가지 문제점을 모두 느껴본 적이 있을 것입니다.
첫 번째는 **메모리 (memory)**입니다. 채팅은 아주 조금만 기억하고 많은 것을 잊어버리며, 에이전트 (agents)는 당신이 연결해 준 컨텍스트 (context) 내에서만 작동합니다. 이러한 도구들이 가진 메모리는 각 앱 내부에 존재하기 때문에 공유되지 않습니다. 즉, 각 도구는 당신의 파편화된 단면만을 보유하고 있으며, 결국 당신은 이미 알고 있는 내용을 다시 설명해야 하는 상황에 처하게 됩니다. 해결책은 더 큰 컨텍스트 윈도우 (context window)를 갖는 것이 아니라, 당신의 컨텍스트가 실제로 '살아있는' 단 하나의 장소를 만드는 것입니다.
두 번째는 **락인 (lock-in)**입니다. 오늘은 Claude가 당신의 주력 도구일 수 있지만, 내일은 ChatGPT가 당신이 원하는 기능을 출시하거나, 어떤 오픈 소스 (open-source) 클라이언트가 프로젝트에 더 적합할 수도 있습니다. 기술의 발전은 멈추지 않으며, 도구를 전환하는 것은 '이전 (migration)'이 아닌 '선택'이어야 합니다. 하지만 그 도구들이 당신과 당신의 업무에 대해 필요로 하는 정보들은 여기저기 흩어져 있습니다. 영상은 여기에, 포스트는 저기에, 노트와 문서는 또 다른 곳에 있으며, 실제 사고가 이루어졌던 긴 AI 채팅 기록들은 다른 곳에 머물러 있습니다.
그것이 바로 제가 **세컨드 브레인 (second brain)**을 구축한 이유이며, 우리가 여기서 함께 만들어갈 것입니다. 이것은 당신이 만든 모든 것을 담고 있으며, '의미 (meaning)'로 검색이 가능하고, 당신이 사용하는 모든 AI 도구가 공유할 수 있는 단 하나의 장소입니다. 이것은 당신이 더 많은 것을 만들수록 함께 성장하고, 당신과 함께 진화합니다. 이 시스템은 **MCP (Model Context Protocol)**를 지원하기 때문에, 당신은 채팅을 자유롭게 교체할 수 있으며 정보를 절대 잃어버리지 않습니다. 동일한 브레인이 Claude, ChatGPT, 그리고 오픈 소스 클라이언트 모두에 똑같이 연결됩니다. 그리고 그 위에 구축된 에이전트들은 아무것도 모르는 상태로 시작하는 대신 실제 메모리를 갖게 되므로, 일반적인 어시스턴트는 답할 수 없는 질문들을 던질 수 있습니다:
- "내가 X라는 아이디어를 구체화했던 그 대화를 찾아줘."
- "[게스트]와의 대화를 준비해줘: 내가 보통 어떻게 인터뷰하는지, 이전에 그와 어떤 내용을 다뤘는지, 그리고 그들의 분야/회사에서 새로 나온 소식은 무엇인지."
- "내 시리즈의 다음 포스트를 위한 캡션을 초안 작성해줘. 내가 이미 다뤘던 내용을 바탕으로, 나의 말투(tone)를 살려서."
왜 데이터베이스가 중심인가요? 이런 시스템에서 가장 어려운 문제 중 하나는 콘텐츠를 저장하는 것이 아닙니다. 모든 계층(검색, 지식, 메모리, 개인정보 보호)에 일관된 하나의 홈을 제공하는 것입니다. 이것이 우리가 Oracle AI Database를 기반으로 구축하려는 이유입니다. 하나의 엔진이 관계형 데이터 (Relational Data)와 JSON 문서를 모두 처리하며, JSON Relational Duality를 통해 _동일한 행(row)에서 두 가지 형태를 모두 제공_합니다. 따라서 에이전트(Agent)는 친숙한 문서 형태로 읽고, 엔진은 내부적으로 정규화된 진실(Normalized Truth)을 유지합니다. 여기에 AI Vector Search와 데이터베이스 내부에서 실행되는 임베딩 모델 (Embedding Model)을 추가하면, 데이터와 그 의미, 그리고 에이전트의 메모리가 모두 함께 거주하게 되어 글루 코드 (Glue Code)를 줄일 수 있습니다.
또한, 원하는 곳 어디에서나 실행할 수 있습니다. 동일한 코드가 노트북의 무료 컨테이너와 Oracle Cloud의 Always Free Autonomous AI Database에서 모두 작동합니다. 여기서 '무료'는 유별나게 실질적입니다. Always Free 계층에는 두 개의 Autonomous AI Database(각각 1 Oracle CPU 및 20GB 제공, 개인용 브레인으로 충분한 용량)가 포함되며, MCP 서버를 호스팅할 수 있는 Always Free 컴퓨팅 VM과 월 10TB의 아웃바운드 전송량이 제공됩니다. 또한 시간 제한이 없습니다. 12개월 체험판도 아니고, 다 써버리면 끝나는 크레딧 방식도 아닙니다. 이 가이드는 모든 구성 요소가 작동하는 것을 직접 볼 수 있도록 로컬에서 시작하여, 마지막에 클라우드로 확장합니다. 저의 시스템은 클라우드에 상주하며, 덕분에 언제 어디서든 제 휴대폰으로 접속할 수 있습니다.
소스(Sources)는 여러분이 선택합니다: 마크다운 보관함(Markdown Vault), 소셜 미디어(YouTube, Instagram, LinkedIn), Notion, AI 채팅 내역, 문서, 북마크, 그리고 여러분의 사용 사례에 중요한 모든 것(콘텐츠, 연구, 업무 지식, 개인 위키 등)이 대상이 됩니다. 우리는 전체 과정을 처음부터 끝까지 구축할 것이며, 먼저 **공개 샘플 (Public Sample)**로 시작하여 전체 작동 과정을 지켜본 뒤, 여러분의 개인 콘텐츠로 연결할 것입니다. 그 위에 구축될 우리의 첫 번째 에이전트는 학습한 내용을 기억하며, 사용할 때마다 점점 더 정교해지는 리서치 에이전트입니다.
뇌가 결과물입니다. MCP는 모든 것이 뇌에 도달하는 방식입니다. 에이전트(Agents)는 여러분이 계속해서 구축해 나갈 대상입니다.

준비물: Homebrew가 설치된 Mac, Python 3.12, 그리고 약 20분의 시간. 사전 Oracle 경험은 필요하지 않습니다. 모든 단계는 복사해서 붙여넣기만 하면 됩니다. 오류가 발생하면 AI 어시스턴트(Claude, ChatGPT, 그리고 곧 여러분이 구축할 바로 그 뇌에 의해 구동될 도구)에 붙여넣고 계속 진행하세요. 많은 사람들이 정확히 이런 방식으로 첫 번째 실제 시스템을 구축합니다. 1~7단계는 로컬 및 헤드리스(Locally and headless) 방식으로 실행됩니다(시작하는 데 Docker Desktop이나 클라우드 계정이 필요하지 않습니다). 8단계는 여러분이 상시 가동(Always-on)을 원할 때 동일한 코드를 Oracle Cloud로 올리는 과정입니다.
여기서 따라 하고, 전체 코드는 저기서 가져오세요. 이 기사는 독립적입니다. 이 단계들을 통해 바로 구축할 수 있습니다. 실행 가능한 전체 프로젝트(모든 로더, 에이전트, MCP 서버)는 Github에 있습니다.
우리가 구축할 것: 하나의 뇌, 그리고 이를 사용하는 두 가지 방법.
뇌, 세 개의 레이어, 하나의 데이터베이스:
- 콘텐츠 (Content): 여러분이 만든 모든 것, JSON 문서로 다시 읽을 수 있는 행(Rows) 형태입니다.
- 컴파일된 위키 (A compiled wiki): 해당 콘텐츠를 바탕으로 합성된 주제 페이지(자기 유지형).
- 에이전트 메모리 (Agent memory): 에이전트가 학습하는 내용, 네 가지 유형으로 제공됩니다.
그 외 추가적인 요소:
- MCP 서버 (An MCP server): Claude, ChatGPT 및 오픈 소스 클라이언트(open-source clients)를 포함한 모든 AI 클라이언트를 위한 도구로서의 브레인입니다. 채팅 앱을 언제든지 바꾸더라도 브레인은 이동하지 않습니다.
- 에이전트 (Agents): 자가 개선형(self-improving) 리서치 에이전트를 시작으로 합니다. 추가되는 모든 에이전트는 동일한 브레인을 공유합니다.
다음 단계들을 위한 지도인 전체 시스템의 모습은 다음과 같습니다:

콘텐츠 수집(Content ingestion), 검색(retrieval), 메모리(memory) 및 MCP 액세스가 단일 Oracle AI Database 아키텍처로 통합됩니다.
이제 한 단계씩 차근차근 살펴보겠습니다.
데이터베이스가 필요한 이유 (이미 마크다운 보관소(markdown vault)를 사용 중이라면)
많은 훌륭한 세컨드 브레인 설정은 마크다운(markdown) 파일 폴더로 시작하며, 이번 빌드는 마크다운을 핵심(core)으로 유지합니다. sources/ 폴더는 콘텐츠를 일반 마크다운과 프론트매터(frontmatter) 형태로 보관합니다. 이는 휴대 가능하고 사람이 읽을 수 있는 표준 사본(canonical copy) 역할을 합니다.
여기서 변화하는 점은 그 주변의 계층(layer)입니다. 이번 빌드의 네 가지 목표는 본질적으로 **데이터베이스 요구 사항(database requirements)**입니다.
- 의미 기반 검색(Search by meaning). 의미론적 검색(Semantic search)은 임베딩(embeddings)을 필요로 하며, 임베딩은 저장되고 쿼리될 인덱싱된 스토어(indexed store)가 필요합니다. 이것이 파일 기반 설정에서 일반적으로 노트와 함께 벡터 데이터베이스(vector database)를 확장하는 이유입니다. 이 빌드는 이를 단순화하여 텍스트, 그 벡터, 그리고 임베딩 모델 자체가 하나의 엔진에서 실행되도록 합니다.
- 기억되는 것이 아니라 강제되는 프라이버시(Privacy that's enforced, not remembered). 파일의 경우, 민감한 자료를 파이프라인에서 제외하는 것은 모든 사람(그리고 모든 스크립트)이 폴더 규칙을 준수하는 것에 의존합니다.
visibility열은 이러한 의도를 엔진이 모든 읽기 경로(read path): 검색, 위키 컴파일러, 메모리 통합, MCP 도구에 적용하는 **제약 조건(constraint)**으로 바꿉니다. 이는 시스템이 주기적으로 스스로 업데이트할 때 가장 중요해집니다. - 문서 같은 느낌을 유지하면서 문서의 노후화는 방지(The document feel, without the document rot). 마크다운(markdown)이 적절하게 느껴지는 이유는 노트가 _하나의 문서_이기 때문입니다. 즉, 위에서 아래로 읽고 어디든 휴대할 수 있는 단일체라는 의미입니다. 하지만 지식 기반이 결국 부담을 느끼는 이유는 그것이 비밀리에 _그래프(graph)_이기 때문입니다. 페이지들은 출처를 인용하고 다른 페이지와 연결되는데, 정적 파일에서는 이러한 연결이 콘텐츠가 이동하고 변경됨에 따라 구식이 되는 단순한 텍스트일 뿐입니다. Oracle은 바로 이 긴장감에 대한 기능을 만들었습니다: JSON 관계형 이중성(JSON Relational Duality). 사용자는 정규화된 테이블이 어떻게 문서로 구성되는지 한 번 선언하고, 데이터베이스는 같은 행에 대해 두 가지 형태를 모두 제공합니다: 앱과 에이전트가 위키 페이지를 인용된 JSON 문서 하나(파일의
Recall(회상)은 벡터 검색 (vector search)이며, consolidation(통합)은 사실 관계를 트랜잭션 (transactionally) 방식으로 재작성합니다. 또한 MCP 서버, 일일 동기화 (daily sync), 그리고 여러 에이전트 (agents)가 동시에 동일한 브레인에 읽기 및 쓰기를 수행할 수 있습니다.

따라서 프레임워크의 설정은 _마크다운 (markdown)이냐 데이터베이스 (database)냐_의 문제가 아닙니다. 그것은 마크다운이 빛을 발하는 부분(저작, 휴대성)과 작업이 이루어지는 부분(검색, 관계, 메모리, 거버넌스)으로서의 데이터베이스입니다. 당신의 노트는 브레인에 정보를 공급하며, 데이터베이스는 그 브레인이 사고할 수 있게 만드는 핵심 요소입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기