프라이빗 에이전트, 데이터로 길러진 taste — Bridgewater AIA + Drewgent 아키텍처

프론티어 LLM 앞에 금융 문서 필터링을 시켰다. 결과는 50% — 동전 던지기였다.

2026년 6월 30일, Bridgewater AIA Labs와 Thinking Machines Lab이 공동 연구를 발표했다. 제목은 “Learning to Replicate Expert Judgment in Financial Tasks.”¹ 내용은 간단하다. 투자 전문가의 일상적 판단 — 문서 필터링, 관련성 분류, 중요도 평가 — 를 AI에 가르치는 방법에 대한 연구다.

결론은 충격적이면서도, 나에게는 익숙했다.

“An explicit prompt can only convey the intuition an expert is able to put into words, while the judgments that matter most are often the hardest to articulate.”

프롬프트는 설명 가능한 taste만 전달한다. 설명 불가능한 판단은 데이터로만 주입할 수 있다. 이 연구는 내가 Drewgent의 knowledge.db를 구축하면서 느꼈던 직관을, 학술적으로 증명해냈다.

금융 전문가의 50% 벽

연구진은 6가지 금융 정보 필터링 과제를 LLM에 던졌다. 문서가 투자 결정에 관련 있는가, 중앙은행 문서가 금리 방향을 시사하는가, 이메일에서 본문과 서식을 구분하라 — 투자자에겐 trivial한 과제들이다.

Gemini 3.1 Pro, Claude Opus 4.6/4.8, GPT 5.2/5.4/5.5 — 모든 프론티어 모델이 평균 50% 정확도에서 출발했다. 동전 던지기와 같았다.

전문가가 직접 프롬프트를 작성하고, 자동 프롬프트 최적화까지 적용했다. 결과는 78%. 더 이상 오르지 않았다. 프롬프트 엔지니어링의 한계는 벽이었다. 모델이 커져도 (GPT 5.4→5.5) 성능은 제자리였다. 비용만 43% 올랐다.

해결책은 간단했다. 고품질 인간 레이블링 데이터로 파인튜닝하자, 84.7% — 프롬프트 대비 29.8% 더 적은 오류, 13.8배 저렴한 비용. 프롬프트는 설명할 수 있는 것까지만 알려준다. 데이터는 설명할 수 없는 것까지 가르친다.

Differentiated Intelligence — 프라이빗 taste의 공식

연구진은 이 결과를 “differentiated intelligence”라고命名했다. 조직의 고유한 데이터로 fine-tune된 모델이, 일반 목적 프론티어 모델을 능가하는 현상.

이 개념은 Drewgent가 지난 6개월간 추구해온 방향과 정확히 일치한다. gbrain에서 knowledge.db로 전환한 결정은 단순한 기술 마이그레이션이 아니었다. taste의 저장 매체를 프롬프트에서 데이터로 옮기는 아키텍처 결정이었다.

놓치지 말아야 할 지점: Bridgewater는 50년간의 투자 데이터, 수백만 건의 레이블링된 판단, 전문가 피드백 루프를 보유한 세계 최대 헤지펀드다. 개인 개발자가 이 규모를 따라잡을 수는 없다. 하지만 개인에게는 개인만의 데이터가 있다.

세션 로그 — 수천 번의 에이전트-인간 상호작용 기록
의사결정 기록 — 어떤 선택을 했고, 왜 했는가
코드 리뷰 이력 — “이건 좋다”, “이건 아니다”의 패턴
에디팅 이력 — 글을 쓰고 고치는 수백 번의 판단

이 데이터들은 프롬프트에 담을 수 없는 개인 taste의 저장소다.

프롬프트가 설명할 수 없는 것

Bridgewater AIA의 연구가 증명한 핵심은 단순하다. 전문가조차 자신의 판단 기준을 전부 말로 표현할 수 없다. 제일 중요한 판단일수록 더 그렇다.

“이 기사가 C레벨 투자자에게 관련 있는가?”라는 질문에 전문가는 즉시 답한다. “왜?”라고 물으면 설명하기 시작한다. 하지만 설명은 판단의 일부일 뿐이다. 나머지는 수천 번의 유사 판단에서 길러진 직관, 즉 데이터에 체화된 taste다.

Drewgent의 knowledge.db는 이 통찰의 엔지니어링 구현체다:

17,614개 지식 항목 — FTS5로 인덱싱, Ollama nomic-embed-text로 벡터화 (768차원)
375개 엔티티 + 1,063개 관계 — 그래프 RCA 층
세션 당 150ms 임베딩, 50ms 검색 — SQLite 파일 하나로

핵심은 규모가 아니라 경로다. 프롬프트라는 좁은 파이프 대신, 데이터를 통해 taste가 에이전트에 도달하는 경로를 만들었다. “이런 결정을 했었다”는 사실 하나가 프롬프트 100줄보다 더 정확하게 다음 결정을 가이드한다.

프라이빗 에이전트의 구조

Bridgewater 연구와 Drewgent 아키텍처가 공유하는 원칙을 세 가지로 압축할 수 있다:

1. 데이터가 프롬프트를 대체한다

프론티어 LLM의 plateau는 구조적이다. 프롬프트는 명시적 지식만 전달한다. 암묵지(tacit knowledge)는 데이터를 통해 모델에 체화되어야 한다. Bridgewater는 파인튜닝을, 나는 검색 증강 생성을 선택했지만 원리는 같다. taste의 저장소는 프롬프트가 아니라 데이터베이스다.

2. 프라이빗 데이터가 차별화를 만든다

모든 사람이 같은 프론티어 모델을 쓴다. 차별화는 공유 모델에 무엇을 더하느냐가 아니라, 내 데이터로 무엇을 가르치느냐에서 나온다. Bridgewater의 84.7%는 공유 모델(Qwen-235B) + 독점 데이터의 조합이었다. Drewgent의 knowledge.db도 같은 패턴이다: 공유 모델(deepseek-v4-flash) + 개인 세션 데이터.

3. 데이터는 쌓일수록 좋아진다

Bridgewater의 AIA Forecaster는 “learning through deployment”를 원칙으로 내세운다. 실제 자본을 운용하며 얻는 피드백이 시스템을 개선한다. Drewgent의 knowledge.db도 같다. recall()을 호출할 때마다, remember()로 저장할 때마다, taste 데이터는 축적된다. 6개월 전보다 오늘의 에이전트가 “나”를 더 잘 이해하는 이유다.

건축: 데이터 taste 흐름

┌─────────────────────────────────────────────────────────────┐
│                  개인 taste 데이터 저장소                     │
│                                                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │세션 로그 │  │판단 기록 │  │결정 로그 │  │피드백   │   │
│  │(P2)      │  │(knowledge│  │(decisions│  │(에디팅, │   │
│  │          │  │ .db)     │  │ .md)     │  │리뷰)   │   │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘   │
│       └──────────┬──┘─────────────┘──────────────┘         │
│                  ▼                                          │
│         ┌────────────────┐                                  │
│         │  Taste Layer   │ ← FTS5 + Ollama embeddings      │
│         │  (knowledge    │ ← Hybrid search (RRF fusion)    │
│         │   .db)         │ ← GraphRCA (entity relations)   │
│         └────────┬───────┘                                  │
│                  │ query / retrieve                         │
│                  ▼                                          │
│         ┌────────────────┐                                  │
│         │ Agent Context  │ ← recall() + graph-explore()     │
│         │ Injection      │ ← 세션 시작 시 자동 로드        │
│         └────────┬───────┘                                  │
│                  │                                          │
└──────────────────┼──────────────────────────────────────────┘
                   │
                   ▼
          ┌────────────────────┐
          │   프론티어 LLM     │ ← 필요할 때만 (라우팅)
          │   + 내 taste       │
          └────────────────────┘

이 구조가 중요한 이유: 프롬프트에 taste를 밀어넣으려고 발버둥칠 필요가 없다. 데이터가 알아서 taste를 전달한다. recall(“recent decisions”) 한 줄이 프롬프트 50줄보다 더 정확한 맥락을 제공한다.

왜 개인에게 더 중요한가

Bridgewater는 50년 데이터 + 전담 리서치 팀 + 수백만 달러 인프라를 가졌다. 개인 개발자는 그럴 수 없다. 하지만 개인에게는 더 섬세한 데이터가 있다.

내 하루 세션 로그에는 “왜 이 선택을 했는가”에 대한 암묵적 힌트가 수십 개 들어있다. 파일을 고치는 순서, 검색어 선택, 되돌리기 패턴, “이건 아니다” 하고 지우는 순간. 이 모든 것이 taste 데이터다. 프롬프트에 적을 수는 없지만, knowledge.db에 쌓이고 있다.

Bridgewater 연구의 교훈은 이것이다: AI 시스템의 차별화는 더 큰 모델이 아니라, 더 개인적인 데이터에서 온다.

시작하는 법

만약 개인 에이전트에 taste를 주입하고 싶다면, 3단계로 시작할 수 있다:

데이터 수집 파이프라인을 만들어라. 세션 로그를 저장하고, 결정 기록을 남기고, 수정 이력을 보존하라. 지금 당장 0줄의 코드로 시작할 수 있다 — history 명령어 하나면 충분하다.
검색 가능하게 만들어라. FTS5든, 벡터 DB든, 심지어 grep이든 좋다. 데이터가 있지만 찾을 수 없으면 없는 것과 같다. SQLite + FTS5는 5분이면 설치된다.
에이전트가 자동으로 참조하게 만들어라. 세션 시작 시 과거 결정을 검색하고, 모든 결정을 저장하고, 질문에 답하기 전 데이터를 먼저 확인하게 하라. 프롬프트에 “네 기록을 먼저 확인해봐” 한 줄이면 된다.

이 3단계가, 프롬프트 1,000줄을 쓰는 것보다 taste를 더 정확하게 전달한다. Bridgewater AIA가 증명했다.

핵심 설계 결정

┌──────────────────────────────────────────────────────────────────┐
│ 결정                    │ 대안                      │ 선택 이유 │
├──────────────────────────┼───────────────────────────┼──────────┤
│ knowledge.db (SQLite)   │ gbrain (Postgres+Haiku)   │ $0 비용, │
│                          │                           │ 50ms 검색 │
├──────────────────────────┼───────────────────────────┼──────────┤
│ Hybrid search (RRF)     │ Pure vector               │ query    │
│                          │                           │ expansion │
├──────────────────────────┼───────────────────────────┼──────────┤
│ Entity graph 추출       │ No graph                  │ RCA 가능 │
├──────────────────────────┼───────────────────────────┼──────────┤
│ Ollama local embeddings │ API embeddings            │ $0,      │
│                          │                           │ privacy  │
├──────────────────────────┼───────────────────────────┼──────────┤
│ Prompt vs Data 중 Data   │ Prompt engineering 우선   │ 연구 검증 │
└──────────────────────────────────────────────────────────────────┘

열린 질문

이 방향이 맞다는 증거는 있다. 하지만 질문이 남는다:

개인 데이터의 규모가 어느 정도가 되어야 taste가 의미 있게 전달되는가? 17,614개면 충분한가, 10만 개가 필요한가?
파인튜닝(RAG의 대안)이 개인 수준에서 실용적일까? Bridgewater는 Qwen-235B를 fine-tune했지만, 개인이 7B 모델을 fine-tune하는 건 현실적이다.
데이터가 모델을 오히려 편향시킬 위험은? 개인의 나쁜 습관도 데이터에 체화될 수 있다.

이 질문들에 대한 답은 아직 없다. 하지만 방향은 명확하다. 프라이빗 에이전트의 미래는 프롬프트 엔지니어링이 아니라, 데이터로 길러진 taste에 달려 있다.

읽어보기

↑ Su et al. (Bridgewater AIA Labs + Thinking Machines Lab), “Learning to Replicate Expert Judgment in Financial Tasks,” June 30, 2026. thinkingmachines.ai/news/learning-to-replicate-expert-judgment-in-financial-tasks/

맺음말

6개월 전, 나는 gbrain을 지우고 SQLite 파일 하나로 지식 시스템을 교체했다. Postgres를 버리고, Haiku API 호출을 버리고, 555MB의 로컬 파일을 선택했다. 당시에는 “더 싸고 빠르니까”라는 실용적 이유였다.

Bridgewater AIA의 연구는 그 결정이 실용적일 뿐만 아니라 철학적으로 옳았다는 것을 증명했다. taste는 데이터를 통해 전달되어야 한다. 프롬프트는 그 빈틈을 메우는 보조 도구일 뿐이다.

프롬프트 100줄을 더 쓰기보다, 세션 로그 하나를 더 저장해라. 그 로그가 에이전트에게 가르치는 것이 더 많다.

읽어줘서 고맙다.