당신의 제2의 뇌는 당신에게 거짓말을 하고 있습니다 (그리고 AI는 이를 더 악화시키고 있습니다)

지난 화요일, 저는 47개의 브라우저 탭을 열어두고 있었고, 6주 동안 손도 대지 않은 3개의 Notion 데이터베이스가 있었으며, 효과적으로 검색할 수 없는 800개의 노트가 담긴 Obsidian 보관함(vault)과, 휴대폰에는 "그 일에 대해 후속 조치할 것"이라고 적힌 음성 메모가 있었습니다. 저는 AI 보조 지식 작업(AI-assisted knowledge work)에 대해 진지하게 생각하는 사람이어야 합니다. 그 아이러니를 저는 잘 알고 있었습니다. 문제는 도구가 부족한 것이 아닙니다. 도구가 너무 많으며, 각 도구는 자신이 당신이 필요로 할 마지막 도구가 될 것이라고 약속합니다. 진짜 문제는 "노트 테이킹을 위한 AI (AI for note-taking)"가 데모에서는 강력해 보이지만 일상적인 사용에서는 증발해 버리는 기능들로 가득 찬 카테고리가 되었다는 점입니다. 실제로 어떤 일이 일어나고 있는지, 무엇이 고장 났는지, 그리고 진정한 솔루션 아키텍처(solution architecture)는 어떤 모습인지 설명하겠습니다.

캡처의 환상 (The Capture Illusion)

모든 제2의 뇌(second-brain) 시스템은 캡처(capture)에서 시작됩니다. 적어두세요. 음성 메모를 하세요. 클립(clip)하세요. 스크린샷을 찍으세요. AI의 약속은 캡처가 마찰 없이(frictionless) 이루어진다는 것입니다. 그냥 모든 것을 쏟아부으면 기계가 알아서 정리해 줄 것이라는 뜻입니다.

하지만 실제로는 그렇지 않습니다. 실제로 일어나는 일은 검색(retrieval) 기능은 여전히 고장 난 상태인데, 캡처하는 영역(surface area)만 폭발적으로 늘어난다는 것입니다. AI가 당신의 음성 메모를 즉시 전사(transcribe)해 주는 것은 맞습니다. 하지만 이제 당신에게는 의미론적으로는 검색 가능하지만 맥락적으로는 고립된(contextually orphaned) 200개의 전사된 음성 메모가 생겼을 뿐입니다. 그것들은 원래 목적이었던 프로젝트와 연결되지 않습니다. 그 뒤에 이어진 결정과도 연결되지 않습니다. 그것들은 그저... 데이터베이스를 떠다니는 인덱싱된 텍스트일 뿐입니다.

캡처의 환상은 마찰 없는 입력이 더 유용한 출력으로 이어진다는 것입니다. 그렇지 않습니다. 라벨이 붙지 않은 상자로 가득 찬 창고는 지식 베이스(knowledge base)가 아닙니다. AI는 그 창고를 채우는 것을 그 어느 때보다 쉽게 만들었습니다. 하지만 그 안에 실제로 무엇이 들어 있는지, 혹은 그중 무엇이 왜 중요한지를 알 수 있도록 돕는 데는 거의 아무런 역할도 하지 못했습니다.

이 문제를 해결한 빌더(builders)들은 캡처(capture)를 단순한 덤프 작업(dump operation)이 아닌, 타입이 지정된 이벤트(typed event)로 취급하는 사람들입니다. 캡처를 할 때, 당신은 단순히 기록하는 것이 아니라 맥락(context)에 대한 주장을 하는 것입니다. 즉, '이것은 프로젝트 X에 속한다', '이것은 고려 중인 결정 사항이다', '이것은 Y를 수행할 때 필요한 참조 자료이다'라고 정의하는 것입니다. AI는 이러한 맥락 태깅(context-tagging)을 실시간으로 도울 수 있지만, 이는 당신의 도구가 단순히 가공되지 않은 입력(raw input)을 받아들이는 것이 아니라, 이를 유도하도록 설계되었을 때만 가능합니다.

검색(Retrieval)은 AI 문제로 위장된 UX 문제이다

벡터 검색(Vector search)은 모든 것을 바꾸었지만, 동시에 아무것도 바꾸지 못했습니다. 맞습니다, 이제는 정확한 키워드가 아닌 의미론적 의미(semantic meaning)를 통해 노트를 찾을 수 있습니다. 그것은 실제적인 변화이며 중요합니다. 하지만 대부분의 구현체는 실제 UX 문제를 해결하지 못한 채 기술만을 출시했습니다. 즉, 당신은 그것을 찾기 전까지는 당신이 무엇을 찾고 있는지조차 모른다는 점입니다.

이것이 바로 재발견(rediscovery)의 문제입니다. 제2의 뇌가 할 수 있는 가장 가치 있는 일은, 당신이 알고 있었다는 사실조차 잊어버린 무언가를 그것이 관련성이 생기는 바로 그 순간에 표면 위로 끌어올려 주는 것입니다. 이것은 검색(search)의 문제가 아닙니다. 이것은 선제적 추론(proactive inference)의 문제입니다. 그리고 이를 위해서는 시스템이 당신이 지금까지 쓴 모든 것의 말뭉치(corpus)를 가지고 있는 것뿐만 아니라, 당신이 현재 무엇을 작업하고 있는지에 대한 모델을 가지고 있어야 합니다.

저는 지난 8개월 동안 네 가지 주요 AI 노트 도구들을 테스트해 보았습니다. 그들 모두 시맨틱 검색(semantic search) 기능을 갖추고 있었습니다. 하지만 그들 중 누구도 선제적 관련성(proactive relevance)을 제공하지는 못했습니다. 그들은 당신이 질문하기를 기다릴 뿐입니다. 하지만 제2의 뇌의 핵심은 당신의 제1의 뇌가 놓친 것들을 알고 있다는 데 있습니다. 만약 시스템이 당신이 무엇을 물어볼지 기억할 때까지 기다린다면, 당신은 이미 루프(loop)를 놓친 것입니다.

이 분야에서 앞서나가는 개발자들은 앰비언트 컨텍스트 엔진(ambient context engines)을 구축하는 사람들입니다. 이는 당신의 현재 작업 화면을 관찰하다가, 요청받지 않아도

노트 테이킹 (note-taking) AI 담론에서 거의 아무도 솔직하게 다루지 않는 사실이 하나 있습니다. 바로 당신의 노트는 기본적으로 훌륭한 프롬프트 컨텍스트 (prompt context)가 아니라는 점입니다.

LLM (대규모 언어 모델)에는 컨텍스트 윈도우 (context windows)가 있습니다. 200k 토큰이 있다 하더라도, 모든 쿼리 (query)에 당신의 지식 베이스 전체를 밀어 넣을 수는 없습니다. 따라서 모든 AI 노트 도구는 검색 증강 생성 (RAG, retrieval-augmented generation)에 대해 결정을 내려야 합니다. 즉, 당신이 질문을 던졌을 때 당신의 노트 중 어떤 청크 (chunks)를 컨텍스트로 가져올 것인가의 문제입니다. 이는 연구 측면에서는 해결된 문제이지만, 제품 측면에서는 아직 해결되지 않은 문제입니다.

대부분의 도구는 단순한 Top-K 검색 (top-K retrieval)을 수행합니다. 의미론적으로 가장 유사한 5개의 청크를 가져와서 쑤셔 넣는 방식입니다. 이는 단순한 사실 회상에는 효과적입니다. 하지만 "지난 2년 동안 내가 쓴 모든 내용을 바탕으로, 마이크로서비스 (microservices)에 대해 실제로 어떻게 생각하고 있는가?"와 같은 종합적인 질문에는 완전히 실패합니다. 왜냐하면 관련 신호 (signal)가 수십 개의 노트에 흩어져 있으며, 그중 어떤 것도 개별적으로는 충분히 높은 순위를 차지하지 못하기 때문입니다.

개인 지식을 위한 훌륭한 RAG는 문서 유형 (이것이 미완성된 생각인가, 아니면 결론 내려진 결정인가?), 시간적 가중치 (당신의 사고가 어떻게 진화해 왔는가?), 그리고 프로젝트 범위 필터링 (이 이니셔티브에 태그된 노트에서만 가져오기)을 이해하는 파이프라인 (pipeline)을 필요로 합니다. 그러한 파이프라인을 구축하는 것은 실제 엔지니어링 작업입니다. 대부분의 소비자용 도구들은 이를 해내지 못했습니다.

워크플로 통합의 격차 (The Workflow Integration Gap)

자체 앱 안에서만 살아있는 제2의 뇌는 인프라가 아니라 취미에 불과합니다. Roam과 Obsidian이 개발자들 사이에서 열광적인 팬덤을 보유한 이유는 이들이 로컬 우선 (local-first) 방식이며 API 접근이 가능하기 때문입니다. 즉, 실제 워크플로 (workflows)에 연결될 수 있습니다.

하지만 이들을 연결하는 과정은 여전히 수동적이고 취약합니다. 스탠드업 (standup) 노트를 작업 관리자에 동기화하기 위해 스크립트를 작성합니다. 그러다 API가 변경됩니다. 당신의 스크립트는 망가집니다. 당신은 실제 업무를 하는 대신 주말 내내 그것을 고치는 데 시간을 보냅니다.

누락된 계층은 당신의 지식 저장소(knowledge store)와 워크플로 도구(workflow tools) 사이의 안정적인 추상화(abstraction)입니다. 다음과 같은 일을 수행하는 무언가가 필요합니다: 노트가 '결정(decision)'으로 태그되면 관련 프로젝트 채널로 요약을 전송합니다. 회의 녹취록(meeting transcript)이 처리되면 실행 항목(action items)을 추출하여 적절한 담당자에게 전달합니다. 연구 노트가 '결론(conclusion)' 상태에 도달하면 소스 자료를 아카이브(archive)하고 적절한 맥락(context)에 결론을 노출합니다.

이것은 단순한 기능(feature)이 아닙니다. 통합 아키텍처(integration architecture)입니다. 그리고 이는 단순히 또 다른 노트 작성 인터페이스(note-taking surface)가 아니라, 연결 조직(connective tissue)을 구축할 누군가를 필요로 합니다.

AI 노트 시스템 평가를 위한 프레임워크

어떤 AI 지원 지식 도구라도 도입하기 전에, 다음 다섯 가지 점검 사항을 통해 검증하십시오:

• 캡처 시 맥락 태깅 (Context tagging at capture) — 도구가 정보를 캡처할 때 프로젝트, 유형, 의도를 명시하도록 강제하거나 강력하게 권장합니까? 아니면 단순히 가공되지 않은 입력(raw input)을 받아들인 뒤 나중에 알아서 파악하겠다고 약속만 합니까?
• 선제적 노출 (Proactive surfacing) — 당신이 요청하지 않아도 현재 작업 중인 내용을 바탕으로 관련 있는 과거 노트를 노출합니까? 만약 대답이 '아니오'라면, 그것은 제2의 뇌가 아니라 검색 도구일 뿐입니다.
• RAG 파이프라인 투명성 (RAG pipeline transparency) — AI 쿼리를 위해 맥락을 어떻게 검색하는지 이해하거나 설정할 수 있습니까? 단순한 Top-K 방식은 위험 신호(red flag)입니다.
• 워크플로 훅 (Workflow hooks) — 구조화된 출력(결정, 실행 항목, 결론)을 다운스트림(downstream) 도구로 라우팅할 수 있도록 안정적인 웹훅(webhooks)이나 API를 제공합니까?
• 쇠퇴 및 큐레이션 모델 (Decay and curation model) — 노트의 생애주기(lifecycle)에 대한 개념이 있습니까? 아카이브(archiving)나 가지치기(pruning) 로직이 없는 시스템은 결국 쓰레기 매립지가 될 것입니다.

만약 어떤 도구가 이 중 세 가지 이상을 충족하지 못한다면, 그 AI 기능들은 겉치레에 불과합니다. 당신은 그저 더 나은 Evernote를 위해 비용을 지불하고 있는 것입니다.

AI Handler가 이 문제에 접근하는 방식

제가 AI Handler를 구축해 온 이유는 제가 사용하는 모든 AI 워크플로 도구에서 동일한 아키텍처적 격차(architectural gap)를 계속 발견했기 때문입니다. 그들은 단일 인터페이스(노트, 채팅, 작업)에 최적화되어 있으며, 통합(integration)을 다른 누군가의 문제로 취급합니다.

AI Handler는 AI 보조 지식 작업(AI-assisted knowledge work)이 기능(feature)의 문제가 아니라 파이프라인(pipeline)의 문제라는 전제를 바탕으로 설계되었습니다. 아키텍처는 구조화된 캡처(structured capture)에서 시작됩니다. 모든 입력값은 유입되는 과정에서 유형화(typed)되고 맥락화(contextualized)되며, 단순히 데이터를 쏟아붓는 것을 수용하기보다 맥락을 요청하는 AI 보조 기능이 작동합니다. 검색(Retrieval)은 의미론적 유사도 순위(semantic similarity ranking)를 매기기 전에 최신성, 문서 유형, 그리고 활성 프로젝트 범위(active project scope)에 가중치를 두는 계층형 RAG 파이프라인을 기반으로 구축되었습니다. 그리고 통합(integration) 레이어는 사후 고려 사항이 아닌 일급 시민(first-class)으로 취급됩니다. 워크플로우 훅(workflow hooks)은 직접 구축해야 하는 제3자 자동화 레이어가 아니라 핵심 스키마(core schema)의 일부입니다.

이 프로젝트를 공개적으로 구축하며(build-in-public) 솔직하게 말씀드리자면, 아직 완성되지 않았습니다. 선제적 표면화 엔진(proactive surfacing engine)이 가장 어려운 부분이며 여전히 거친 상태입니다. 하지만 핵심 파이프라인인 유형화된 캡처(typed capture), 계층형 검색(layered retrieval), 워크플로우 라우팅(workflow routing)은 작동하고 있으며, 저는 엔지니어링 결정부터 콘텐츠 계획에 이르기까지 모든 것을 관리하기 위해 이를 매일 사용하고 있습니다.

목표는 개발자와 AI 파워 유저들이 단순히 새로움이 사라지면 6주 만에 버리게 될 또 다른 앱이 아니라, 인프라로서 실제로 신뢰할 수 있는 도구를 만드는 것입니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로우 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.