에이전트가 검증을 잊을 수 없게 만들었습니다: 브리지워터 PAT의 설계
2026년 7월 LangChain 행사에서 브리지워터 어소시에이츠가 사내 도구 하나의 내부를 열어 보였습니다. 이름은 PAT, Pocket Analyst Tool입니다. 발표자는 세 명이었습니다. 응용 AI 팀 리드 브렌던 맥매너스, 투자자 리드 마이클 랜, 기술 리드 산티 웨이트. 투자자와 기술자가 한 무대에 함께 선 구성 자체가 이 프로젝트의 성격을 말해 줍니다.
PAT은 프로토타입이 아닙니다. 몇 달 전 사내 배포됐고 수백 명의 투자자가 매일 씁니다. 사람 애널리스트가 며칠 걸리던 탐색적 리서치를 분 단위로 줄이는 것이 목표입니다.
이 글은 25분 발표의 자막 전문을 읽고 논지를 다시 묶은 것입니다. 그리고 후반부에서는 이 설계를 제가 매일 쓰는 시스템과 나란히 놓고, 어디가 같고 어디가 비어 있는지 셌습니다.
전제: 에이전트를 위해 다시 적을 필요가 없었습니다
발표는 1980년에 노란 리걸패드에 손으로 쓴 채권 시스템 사진에서 시작합니다.
발상은 단순했습니다. 거래를 할 때마다 왜 그 거래가 말이 되는지 규칙을 적어 둡니다. 정확한 인과 논리를 적습니다. 그러면 다른 투자자가 그것을 읽고 어디가 틀렸는지 짚어 줄 수 있습니다. 새로 배우면 규칙 하나를 지우고 새 규칙을 씁니다.
이 과정을 50년간 복리로 쌓아, 사람과 기계가 모두 읽을 수 있는 전문가 시스템으로 코드화했습니다. 그리고 발표의 전제가 되는 문장이 나옵니다.
"우리는 에이전트를 위해 되돌아가서 전부 다시 적을 필요가 없었습니다. 이미 거기 있었습니다."
이 한 줄이 이 발표에서 가장 옮기기 어려운 부분입니다. 나머지는 다 기술이고, 이건 50년입니다.
PAT이 맡은 것은 리서치 순환의 한 구간입니다
브리지워터는 인간 투자자의 일을 하나의 순환으로 봅니다. 바깥 세계를 지각하고, 무엇이 참이고 무엇을 놓치고 있는지 질문을 만들고, 답하기 위해 분석적 조사를 하고, 발견을 종합하고, 배운 것을 축적된 이해로 되돌립니다.
마지막 단계가 핵심입니다. 학습이 공유 메모리로 돌아가고 사람이 다시 꺼내 씁니다.
인공 투자자를 만들겠다면 이 순환의 각 구간마다 별도의 서브에이전트가 필요합니다. 그것이 브리지워터의 로드맵이고, PAT은 그중 조사 구간 하나입니다. 발표자도 선을 긋습니다. PAT은 어떻게 거래하는지에 대한 도구가 아니라, 예전에는 대역폭이 없어 추적하지 못하던 질문을 좇는 심층 탐색 도구입니다.
사람마다 다른 PAT을 갖습니다
기술 설계로 들어가기 전에 나온 보안 이야기가 흥미롭습니다.
PAT이 진짜 도움이 되려면 투자자가 리서치할 때 접근하는 모든 정보에 접근해야 합니다. 그런데 브리지워터에서는 투자자마다 볼 수 있는 것이 다릅니다. 전 시장 포지션을 아는 사람의 PAT은 그것을 알아야 하고, 그 정보에 노출되면 안 되는 애널리스트의 PAT으로는 새면 안 됩니다.
그래서 모두가 같은 시스템 프롬프트와 같은 도구를 쓰는 하네스와 달리, 각자가 자기 권한에 맞춰진 고유한 PAT을 갖습니다. 발표자의 정리가 담백합니다. 이 고유성은 결국 각자의 PAT이 가진 컨텍스트와 도구의 함수일 뿐입니다.
권한 분리를 별도 시스템으로 짓지 않고 컨텍스트와 도구 목록의 차이로 환원한 것. 이건 그대로 옮겨 쓸 수 있는 설계입니다.
검색: 사람처럼 의심하는 층을 얹었더니 50에서 90으로
PAT이 처음 하는 일은 웹과 사내 비정형 자료를 뒤져 지금 세계에서 무슨 일이 벌어지는지 파악하는 것입니다.
웹 검색은 이제 기본값입니다. 차별화는 구독 중인 비정형 콘텐츠의 폭입니다. 브로커 자료, 실적 콜 전사, 내부 메일을 포함해 수백만 문서가 있고 매일 수천 건이 들어옵니다.
그다음이 시계열 데이터베이스입니다. 50년간 내부에서 모델링한 수천만 개 시리즈가 들어 있고, 유가 같은 외부 데이터와 12개월 후 인플레이션 전망 같은 내부 파생 개념이 함께 있습니다.
검색 에이전트는 RAG와 리랭킹 같은 전통 기법을 씁니다. 그런데 결정적 차이를 만든 것은 따로 있었습니다.
"사람 연구자가 데이터를 찾을 때는 시계열의 이름에만 매달리지 않습니다. 빈도를 보고, 통화 단위를 보고, 무엇보다 그 값이 자기 사전 믿음과 맞는지를 봅니다."
이 검토 습관을 검색 에이전트에 심었더니 정확도가 대략 50퍼센트에서 90퍼센트로 올라갔습니다.
검색 품질을 올린 것이 임베딩 교체나 청킹 튜닝이 아니라 사람이 자료를 의심하는 방식의 이식이었다는 점을 기억할 만합니다.
계획이 곧 분석입니다
PAT은 데이터를 모은 뒤 곧바로 실행하지 않고 사용자에게 명확화 질문을 돌려줍니다. 챗봇이 되묻는 것 자체는 흔합니다. 이들이 공들인 것은 그 질문의 내용이었습니다. 무엇이 좋은 리서치 질문이고 무엇이 나쁜 질문인지를 가르쳤고, 이 주고받음이 계획에 과소투자하는 인간의 습관을 보정합니다.
개발 중 얻은 관점이 이 문장으로 압축됩니다.
"계획이 곧 분석입니다."
고품질의 상세한 계획을 만들 수 있으면, 그 계획을 일관되게 실행해 원하는 산출을 낼 수 있다는 확신입니다.
그래서 계획 단계에서 하는 일이 구체적입니다. 분석에서 만들어질 모든 데이터프레임을 열거하고, 각각의 스키마를 정하고, 그것들이 서로 어떻게 연결되는지를 정합니다. 시간이 많이 드는 단계지만 실행 단계에서 얻는 것 때문에 의도적으로 지불하는 비용입니다.
계획은 태스크로 쪼개지고, 태스크 하나는 데이터프레임 하나를 계산하는 파이썬 함수 하나에 대략 대응합니다. 태스크 스키마에는 이름, 무엇을 계산할지에 대한 서술, 나올 데이터프레임의 구조적·의미적 정보가 들어갑니다.
그리고 기대치가 강합니다. 모든 태스크는 LLM을 통해 결정론적으로 코드로 컴파일됩니다. 같은 태스크를 받은 두 LLM이 만든 코드는 실행하면 값이 정확히 같아야 합니다.
"그래서 우리의 분석 계획은 클로드 코드에서 보는 것 같은 할 일 목록이 아닙니다. 우리는 그것을 자연어로 쓴 파이썬 프로젝트로 생각합니다."
계획이 이만큼 상세하면 코드를 병렬로 생성할 수 있습니다. 계획 마지막에 있는 시각화 태스크가, 아직 생성되지도 않은 데이터 로딩 코드로부터 무엇을 받을지 이미 알고 있기 때문입니다. 같은 컨텍스트와 같은 계획에서 코드 생성이 평균 4배 빨랐고, 태스크 3개짜리 계획과 20개짜리 계획이 같은 시간에 끝나는 스케일링이 나옵니다.
정확성을 아키텍처에 강제합니다
여기가 이 발표의 중심입니다.
기술 리드의 배경이 컴파일러 이론과 프로그래밍 언어 설계입니다. 그가 보기에 컴파일러와 코딩 에이전트는 요구사항의 모양이 비슷합니다. 컴파일러는 완전히 결정론적이고 정확하고 신뢰할 수 있어야 합니다. 비행기를 띄우는데 오프바이원 오류가 있을 수는 없습니다. 컴파일러가 사용자 코드를 자바스크립트로 컴파일한다면, 코딩 에이전트는 사용자 프롬프트나 계획을 파이썬으로 컴파일합니다.
헤지펀드에서 수십억 달러를 거래하는데 감으로 짠 분석이 근거가 될 수는 없다는 것이 출발점입니다.
그래서 코드가 생성되면 이렇게 처리합니다. 계획에서 온 태스크와 그로부터 생성된 코드를 함께 놓고, 코드를 실행하고, 태스크와 대조해 맞는지 보고, 틀리면 고치고, 끝날 때까지 반복합니다. 먼저 정적 분석으로 의존 그래프를 파악한 뒤 검증 에이전트를 병렬로 돌립니다. 태스크 5개 계획은 3개 층, 20개 계획은 4~5개 층이 됩니다.
그리고 이 대목에서 발표의 핵심 문장이 나옵니다.
"우리는 정확성을 아키텍처에 강제합니다. 다시 말하지만 에이전틱 오케스트레이션이 없습니다. 이건 그냥 일반 파이썬 코드라서 가드레일이 아주 단단하고, 에이전트는 검증을 잊을 수가 없습니다. 검증하도록 강제됩니다."
결과가 숫자로 나옵니다. 임의의 계획에 테스트 스위트를 돌리면 95퍼센트 확률로 서로 다른 두 에이전트가 정확히 같은 코드를 냅니다. 사실상 결정론적 코딩 에이전트입니다.
그리고 이 재현성이 다음 것을 가능하게 합니다. 스케일링하고 힐클라이밍하고 평가할 때, 감이나 LLM 심판보다 훨씬 의존할 만한 기준을 갖게 됩니다.
코드를 LLM이 돌리지 않습니다
보통 코딩 에이전트는 자기가 만든 코드를 자기가 터미널로 호출합니다. 툴 콜 지연이 크고, 다들 겪어 봤듯 중간에 길을 잃기도 합니다.
PAT은 시스템이 LLM을 대신해 코드를 실행합니다. 고전적인 정적 분석 파이프라인으로 파이썬 코드에 캐싱 어노테이션을 주입해 재실행을 피하고, 자체 프레임워크로 돌립니다.
데이터를 두 번 로드하거나 중간 결과를 두 번 계산하지 않으니 첫 실행부터 빠릅니다. 그런데 진짜 이득은 두 번째입니다. 계획의 마지막 차트 이름만 바꾸는 벤치마크에서, 일반 코딩 에이전트는 코드 전체를 다시 돌립니다. PAT은 두 번째 라운드가 사실상 즉시 끝납니다.
이 차이가 제품에서 뜻하는 바가 분명합니다. 투자자가 자기 분석에 작은 수정을 반복해도 매번 처음부터 다시 도는 비용이 붙지 않습니다.
산출물이 입력 데이터베이스로 돌아갑니다
실행이 끝나면 PAT은 주니어 애널리스트가 자기 작업을 다시 확인하듯 스스로 점검합니다. 계산된 데이터와 만들어진 시각화를 보고 숫자가 말이 되는지, 차트가 깔끔한지 확인합니다. 뭔가 이상하면 물러나 원인을 진단하고 분석을 다듬은 뒤 만족한 상태로 돌아옵니다.
결과는 인터랙티브 리포트이며, 브리지워터 투자자들이 원래 만들던 것과 똑같이 생겼습니다. 사내 차팅 라이브러리와 수십 년간 개발한 텍스트 스택을 그대로 쓰기 때문입니다.
그런데 발표에서 지나가듯 말한 설계 하나가 가장 중요합니다.
분석의 시계열 산출물이 입력을 끌어온 바로 그 데이터베이스에 저장됩니다. 두 가지 의미가 있습니다. 하나, PAT의 산출물은 사람이 수년간 올려온 시리즈와 구분되지 않습니다. 둘, 한 분석의 산출이 다음 분석의 입력이 됩니다.
사람과 에이전트가 서로의 작업 위에 복리로 쌓는 환경이 이렇게 만들어집니다. 리포트를 예쁘게 만드는 것과 산출물이 다시 자산이 되는 것은 완전히 다른 이야기입니다.
Teach 버튼: 상호작용을 벤치마크로 바꿉니다
PAT이 나아지는 경로는 둘입니다.
첫째는 자율 경로입니다. 백그라운드 에이전트가 완료된 대화를 계속 훑으며 PAT이 어디서 틀렸는지 찾고, 사람이 감사한 벤치마크를 만들고, 컨텍스트와 하네스를 바꿉니다. 한 명이 아니라 전원에 대해 개선됩니다.
둘째가 명시 경로이고, 발표에서 데모로 보여 준 쪽입니다.
사용자가 다른 시각화를 요청합니다. 여기서 사용자는 뭔가 틀렸다고 말하지 않았습니다. 질문에 답하는 데 중요하다고 생각한 다른 관점을 원했을 뿐입니다. 만약 PAT이 처음부터 이 시각화를 내놓거나 제안했어야 한다고 판단하면, 사용자는 Teach 버튼을 누릅니다.
그러면 에이전트가 대화를 훑으며 세 가지를 찾습니다. 행동상의 실수, 컨텍스트의 공백, 그리고 미리 앞질러 처리할 수 있었던 사용자 조종입니다.
사용자가 제출하면 백엔드에서 벌어지는 순서가 이렇습니다.
- 먼저 실패할 것으로 기대되는 벤치마크를 만듭니다. 그 나쁜 행동을 재현할 수 있음을 보이는 것입니다.
- 그다음 컨텍스트 저장소나 하네스 자체를 그 벤치마크가 통과할 때까지 고칩니다.
- 통과시키면서 나머지 스위트를 깨뜨리지 않았는지 확인합니다.
- 변경안을 담은 풀 리퀘스트를 슬랙 메시지로 보냅니다.
다음에 누군가 비슷한 질문을 들고 오면 더 나은 버전의 PAT을 처음부터 만나게 됩니다.
이 루프가 중요한 이유는 사용자의 불만을 수집한다는 데 있지 않습니다. 불만을 재현 가능한 실패 테스트로 바꾸고, 그 테스트를 통과시키는 것을 하네스 수정의 완료 조건으로 삼는다는 데 있습니다. 개선했다는 주장에 증거를 붙이는 방법입니다.
조직 설계도 함께 나왔습니다
50년 된 헤지펀드가 어떻게 이런 걸 만드느냐는 질문에 대한 답이 두 가지였습니다.
하나, PAT 팀은 회사 안에서 인큐베이팅된 사내 응용 AI 스타트업이었습니다. 회사의 자원을 끌어 쓰면서 아주 유연하고 빠르게 움직일 수 있었습니다.
둘, 다중 원형 팀입니다. 투자자와 기술자와 과학자가 나란히 앉아 함께 만듭니다. 투자자는 맥락과 도메인 전문성을, 기술자는 아키텍처 역량을, 과학자는 엄밀성을 가져옵니다. 전문가 사용자를 위한 AI 시스템을 지으려면 이 조합이 필요하다는 것이 이들의 결론입니다.
여기에 컨텍스트에 대한 태도 하나가 붙습니다.
"당신의 사용자가 아마 당신보다 컨텍스트를 더 잘 씁니다. 그러니 자아를 낮추고 그들이 직접 기여하게 하는 것이 이기는 방법입니다."
투자자가 코드베이스의 개발자처럼 컨텍스트에 직접 기여합니다. 그리고 컨텍스트만 잔뜩 주면 정보량은 많아도 워크플로 느낌이 나지 않기 때문에, 특정 유형의 분석을 어떻게 다루는지 단계별 가이드를 함께 줍니다. 그러면 훨씬 제품처럼 느껴집니다.
마지막 교훈 두 개
발표는 두 문장으로 끝납니다.
첫째, 에이전트를 특화하라. 범용의 강력한 에이전트는 멋진 데모를 만들지만 매일 의존할 수 있는 워크플로로 만들기는 아주 어렵습니다. 좁은 워크플로를 잡아 무겁게 벤치마킹하고 그 벤치마크를 힐클라이밍합니다. 나중에 에이전트들을 합칠 수는 있어도 반대 방향은 더 어렵습니다.
둘째, 에이전틱 코딩을 컴파일러 문제로 생각하라. 컴파일러는 수십 년간 코드를 더 신뢰성 있고 정확하고 결정론적으로 생성하는 기법을 쌓아 왔습니다.
제 시스템과 나란히 놓아 봤습니다
저는 상장투자와 벤처투자 판단을 돕는 로컬 에이전트 시스템을 몇 달째 직접 운영하고 있습니다. 역할이 다른 에이전트 다섯이 각각 사실 수집, 상장 판단, 비상장 딜, 개인 맥락, 시스템 관리를 맡고, 볼트에 사실과 근거와 테시스와 행동 게이트를 객체로 쌓습니다. 그래서 이 발표를 보는 내내 제 것과 대조하게 됐습니다.
이미 같은 방향으로 가 있던 것이 넷 있었습니다.
계산과 신선도 판정과 라우팅과 중복 제거를 언어모델이 아니라 코드가 먼저 처리한다는 원칙은 처음부터 세워 뒀습니다. PAT의 "에이전틱 오케스트레이션 없음"과 같은 발상입니다.
판단의 단위를 보고서가 아니라 사실·근거·테시스·행동 게이트·결과라는 객체로 잡은 것도 같습니다. 브리지워터의 인과 규칙 축적과 목적이 겹칩니다.
에이전트마다 권한과 컨텍스트를 분리한 것도 같습니다. 개인 맥락을 다루는 에이전트가 투자 판단 채널을 침범하지 않고, 각자 볼 수 있는 볼트 영역이 다릅니다. PAT이 사람마다 컨텍스트와 도구를 다르게 준 것과 같은 구조입니다.
산출물이 다시 입력이 되는 경로도 있습니다. 대화와 리서치에서 나온 것이 테시스 갱신 후보 큐로 들어가고, 검토를 거쳐 장기 기억으로 올라갑니다.
그런데 비어 있는 것이 넷이었고, 이쪽이 훨씬 중요했습니다.
첫째, 재현성 숫자가 없습니다. 브리지워터는 "두 에이전트가 95퍼센트 확률로 같은 코드를 낸다"고 말할 수 있습니다. 제 시스템은 반복 작업이 계약대로 실행되는지는 기록하지만, 같은 입력에 같은 판단이 나오는지를 재는 지표가 없습니다. 계측은 있는데 재현성 측정이 없는 상태입니다. 그리고 재현성이 없으면 "지난달보다 나아졌다"는 말에 증거를 붙일 수 없습니다.
둘째, Teach 버튼에 해당하는 것이 없습니다. 제 시스템에도 갱신 후보 큐가 있지만 거기까지입니다. 후보가 쌓이고 사람이 검토합니다. 그런데 PAT은 한 번의 불만족을 실패하는 벤치마크로 만들고, 그 벤치마크를 통과시키는 것을 하네스 수정의 완료 조건으로 삼고, 나머지 스위트가 안 깨졌는지까지 확인한 뒤 변경 제안을 올립니다. 후보 큐와 회귀 테스트 사이의 거리가 제 시스템에서 가장 크게 벌어진 빈칸입니다.
셋째, 계획이 스키마 계약이 아닙니다. 제게도 반복 업무를 바로 실행하는 빠른 경로가 있습니다. 그런데 그건 진입점이지 산출물의 구조를 미리 못박은 계약이 아닙니다. PAT처럼 어떤 표가 나오고 그 표들이 어떻게 연결되는지를 실행 전에 확정하면, 병렬화도 검증도 그 뒤에 자동으로 따라옵니다. 순서가 반대였습니다.
넷째, 찾았다는 사실과 판단이 바뀌었다는 사실이 연결되어 있지 않습니다. 제 볼트의 검색 품질 자체는 좋습니다. 그런데 어떤 문서를 찾은 것이 실제로 어떤 판단을 바꿨고 그 판단의 결과가 어땠는지를 잇는 기록이 거의 없습니다. PAT은 산출물이 입력 데이터베이스로 돌아가면서 이 연결이 구조적으로 강제됩니다. 저는 그 강제가 없어서, 검색은 잘 되는데 그게 판단을 개선했는지는 모르는 상태로 남아 있습니다.
정리하면 이렇습니다. 제 시스템의 다음 과제는 더 좋은 모델도, 더 많은 수집도 아닙니다. 개선했다는 주장에 증거를 붙이는 장치입니다. 그게 재현성 지표이고, 실패 벤치마크 루프이고, 검색에서 판단까지의 연결입니다.
VC의 눈으로 다시 읽으면
이 발표는 투자 판단에 쓸 만한 재료를 몇 개 남깁니다.
하나, 해자는 모델이 아니라 하네스에 쌓입니다. 브리지워터가 만든 것은 컨텍스트 저장소, 검증 아키텍처, 실행 캐시, 벤치마크 생성 루프입니다. 모델은 누구나 씁니다. AI 네이티브와 AI 도입을 가르는 실제 구현 증거가 여기 있습니다.
둘, 사전 문서화 자산의 값이 드러났습니다. 50년간 인과 논리를 기계가 읽을 수 있게 적어 온 조직만 이 속도로 에이전트를 붙일 수 있었습니다. 실사 질문으로 옮기면 이렇게 됩니다. 이 회사는 자기 판단 규칙을 에이전트가 읽을 수 있는 형태로 이미 쓰고 있습니까. 아니면 지금부터 써야 합니까. 후자라면 도입 기간을 훨씬 길게 잡아야 합니다.
셋, 평가 루프의 자동화가 진짜 제품입니다. 저는 회사와 사람을 볼 때 자기만의 비공개 산출물과 평가 기준이 있고 그것으로 자기만의 언덕 오르기 기계를 돌리는지를 묻습니다. Teach 버튼은 그 질문에 대한 교과서적인 답입니다. 사용자 상호작용을 학습 자산으로 바꾸는 폐루프가 실제로 어떻게 생겼는지 볼 수 있는 드문 사례입니다.
넷, 결정론에 대한 요구가 도메인 진입장벽을 만듭니다. 95퍼센트 재현성은 데모와 프로덕션을 가르는 경계선입니다. 금융, 의료, 법률처럼 틀리면 책임이 따르는 버티컬에 투자할 때 물어야 할 숫자가 하나 늘었습니다. 당신들의 에이전트는 같은 입력에 같은 답을 몇 퍼센트나 냅니까.
맺으며
가장 오래 남는 문장은 검증에 대한 것이었습니다.
에이전트가 검증을 잊을 수 없게 만들었다는 말. 성실한 에이전트를 기대하는 대신, 검증을 건너뛸 방법이 아예 없는 구조를 지었다는 말입니다.
에이전트를 어떻게 더 똑똑하게 만들까를 묻는 동안, 이들은 에이전트가 실수할 수 있는 경로를 어떻게 없앨까를 물었습니다. 질문이 다르면 도착하는 곳도 다릅니다.
출처 노트: LangChain, "How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes" (2026-07-24, 25분 44초) 자막 전문. 발표자는 Brendan McManus, Michael Ran, Santi Weight입니다. 인용문은 자막 기준으로 옮기며 우리말로 다듬었습니다. 브리지워터의 프로세스 서술은 모두 발표자 발언 기준이며 회사 공식 문서로 확인된 내용이 아닙니다. 후반부의 제 시스템 대조는 설계 수준의 비교이며 내부 수치나 운영 자료는 포함하지 않았습니다.