모델은 기억하지 않는다

LLM에게 "조사해줘"라고 말하는 것은 쉽다.

검색하고, 읽고, 요약하고, 결론을 내린다. 겉으로 보기에는 리서처처럼 움직인다. 문장도 매끄럽고, 구조도 그럴듯하다. 처음에는 꽤 놀랍다. 사람이 몇 시간 걸려 읽을 자료를 몇 분 안에 훑고, 핵심을 정리하고, 다음 액션까지 제안한다.

그런데 실제 시스템에 넣어보면 금방 불편해진다.

출처가 애매하다. 시점이 섞인다. 같은 회사를 어제의 데이터와 3개월 전 데이터로 동시에 판단한다. 검색 결과 상단에 걸린 자료를 과하게 신뢰한다. 중요한 자료가 빠졌는지 스스로 모른다. 그럴듯한 요약은 나오는데, 그 요약이 오늘의 판단에 쓸 수 있는지 확신하기 어렵다.

내가 만들고 있는 시장 분석 에이전트에서도 이 문제가 먼저 터졌다. 이 시스템의 목표는 뉴스를 예쁘게 요약하는 것이 아니다. 주도섹터와 주도주를 리테일 대중화 이전에 포착하고, 그 판단이 이후 성과로 이어지는지를 추적하는 것이다.

이런 시스템에서는 "이 회사 좋아 보여요"라는 문장만으로는 아무 의미가 없다. 왜 추적 대상이 되었는지, 어떤 섹터나 테마의 흐름과 연결되는지, 기존 가설을 강화하는지 반박하는지, 그 판단이 언제의 데이터에 근거하는지까지 붙어 있어야 한다.

특히 시장 분석처럼 시점과 출처가 중요한 영역에서는 LLM 리서치의 한계가 더 빨리 드러난다. 어떤 기업이 좋은지 나쁜지를 말하는 것보다 더 중요한 것은, 그 판단이 언제의 데이터에 근거했는지, 어떤 자료를 읽고 나온 결론인지, 무엇을 읽지 못했는지다.

나는 여기서 한 가지를 인정하게 됐다.

모델은 기억하지 않는다.

리서치를 맡겼을 때 생긴 문제

처음에는 모델에게 리서치를 맡기면 된다고 생각하기 쉽다.

"이 종목에 대해 최근 뉴스를 조사해줘."

"이 섹터의 주요 리스크를 정리해줘."

"이 기업의 실적과 주가 흐름을 비교해서 분석해줘."

이런 요청에 LLM은 꽤 잘 답한다. 문제는 답을 못 하는 것이 아니다. 문제는 답을 너무 잘하는 것처럼 보인다는 데 있다.

리서치 시스템에서 중요한 것은 문장의 품질이 아니라 판단 재료의 품질이다. 모델이 어떤 자료를 봤는지, 그 자료가 최신인지, 원문인지, 2차 요약인지, 서로 모순되는 자료를 어떻게 처리했는지. 이런 것들이 결과의 신뢰도를 결정한다.

하지만 일반적인 LLM 리서치는 이 과정을 시스템적으로 보장하지 않는다. 검색 결과를 읽고 요약할 수는 있어도, 프로젝트가 신뢰하는 데이터셋을 기준으로 판단한다고 말하기 어렵다. 오늘 수집한 데이터와 과거에 학습된 지식, 검색으로 발견한 문서, 모델 내부의 일반론이 한 문장 안에 섞인다.

사람이 읽으면 자연스럽지만, 시스템으로 쓰기에는 위험하다.

시장 분석에서는 특히 그렇다. "최근"이라는 단어 하나에도 기준일이 필요하다. "강하다"는 말에는 비교 대상이 필요하다. "기관 매수세가 있다"는 주장에는 데이터 출처와 집계 기간이 필요하다. 이런 기준이 없으면 분석은 통찰이 아니라 인상비평이 된다.

내가 필요했던 것도 더 긴 검색 결과가 아니었다. 시스템이 신뢰하는 리서치 기억이었다. 어떤 종목이 언제 추적 목록에 들어왔고, 그때의 thesis는 무엇이었고, 이후 어떤 narrative와 연결되었고, 실제 성과는 어땠는지. 이런 것들이 이어져야 비로소 모델의 분석이 시스템의 판단이 된다.

LLM은 리서처가 아니다

LLM은 리서처처럼 말할 수 있다.

하지만 그 자체가 리서처인 것은 아니다. 더 정확히 말하면, LLM은 자료를 신뢰 가능한 방식으로 축적하고 관리하는 존재가 아니다. 주어진 컨텍스트 안에서 패턴을 찾고, 관계를 추론하고, 언어로 정리하는 데 강한 모델이다.

리서처에게는 책상이 있다. 읽은 자료가 쌓이고, 밑줄 친 문장이 있고, 출처가 정리된 노트가 있고, 어제 판단과 오늘 판단의 차이가 기록된다. 좋은 리서처는 머리가 좋아서만 좋은 것이 아니라, 자기 자료실을 관리할 줄 알기 때문에 좋다.

LLM에게는 기본적으로 그 자료실이 없다.

물론 모델의 파라미터 안에는 방대한 세계 지식이 들어 있다. 하지만 그것은 내가 오늘 수집한 데이터가 아니다. 내 프로젝트의 데이터베이스도 아니고, 방금 업데이트된 공시도 아니고, 우리 시스템이 신뢰하기로 한 소스 목록도 아니다.

그래서 모델에게 리서치를 맡긴다는 말은 사실 두 가지 일을 섞어서 부르는 것이다.

첫 번째는 자료를 모으는 일이다.

두 번째는 자료를 해석하는 일이다.

LLM은 두 번째에 강하다. 하지만 첫 번째를 모델의 즉흥적인 검색과 판단에만 맡기면, 전체 시스템의 상한선은 검색 품질과 컨텍스트 구성 품질에 묶인다. 모델이 똑똑해도, 잘못된 자료를 읽으면 좋은 결론에 도달할 수 없다.

실제로 모델은 개별 기업 요약은 그럴듯하게 했다. 사업 모델을 설명하고, 최근 이슈를 정리하고, 리스크를 나열하는 일은 꽤 잘했다. 하지만 그 기업이 왜 우리 시스템에서 중요한지까지 안정적으로 붙잡지는 못했다.

문제는 지식의 양이 아니었다. 연결의 문제였다.

이 기업이 이미 추적 중인 종목인지. 어떤 투자 가설과 연결되는지. 같은 섹터의 다른 종목들과 비교했을 때 상대적으로 강한지. 시장 레짐이 바뀌었을 때 이 판단을 유지해야 하는지. 과거의 판단이 맞았는지 틀렸는지. 이런 질문은 웹 검색 한 번으로 해결되지 않는다.

이것은 모델이 기억해야 할 정보가 아니라, 시스템이 기억해야 할 정보다.

검색과 기억 사이

여기서 흔히 RAG라는 단어가 등장한다.

Retrieval-Augmented Generation. 모델이 답변을 생성하기 전에 외부 지식 저장소에서 관련 문서를 검색하고, 그 검색 결과를 컨텍스트로 넣어 답변하게 만드는 방식이다.

설명만 들으면 간단하다. 데이터를 넣고, 임베딩하고, 벡터 DB에 저장하고, 질문이 들어오면 비슷한 문서를 찾아 모델에게 넘긴다. 그러면 모델이 더 정확하게 답한다.

하지만 실무에서 느끼는 RAG는 그렇게 단순하지 않다.

RAG는 모델에게 기억을 붙이는 기술처럼 보인다. 하지만 나는 그렇게 보면 오해가 생긴다고 생각한다. RAG는 기억이라기보다, 모델이 판단할 때 밟고 서는 지형에 가깝다.

기억은 주체의 내부에 있다. 내가 어제 무엇을 읽었는지, 왜 그렇게 판단했는지, 어떤 맥락에서 그 결론을 냈는지와 연결되어 있다. 반면 RAG의 검색 결과는 매 호출마다 외부에서 주입되는 컨텍스트다. 모델은 그 자료를 "기억"하는 것이 아니라, 그 순간 읽고 판단한다.

그래서 질문은 "모델에게 어떻게 기억을 붙일까"가 아니다.

질문은 이것이다.

모델이 매번 어떤 지형 위에서 판단하게 만들 것인가.

RAG는 기억이 아니라 지형이다

1편에서 나는 에이전트를 함수에 비유했다. 관심사를 분리하고, 서브에이전트를 조합하고, 오케스트레이터가 흐름을 관리하는 것. 하네스 엔지니어링의 문제였다.

2편에서는 울타리를 타입에 비유했다. 에이전트의 자율을 없애지 않으면서, 목표와 권한과 품질 기준이라는 경계를 선언하는 것. 펜스 엔지니어링의 문제였다.

3편에서는 그 울타리를 무엇으로 만들지 이야기했다. 시스템 프롬프트, 스키마 검증, 권한 시스템, 평가 에이전트. 펜스의 구현 재료에 관한 이야기였다.

그런데 실제 리서치 시스템을 만들다 보면, 그 아래에 한 층이 더 있다는 것을 알게 된다.

에이전트가 무엇을 보고 판단하는가.

시스템 프롬프트는 행동의 지형을 만든다. 보수적으로 답하라, 출처를 명시하라, 확신이 없으면 불확실하다고 말하라. 이런 지시는 모델의 기본 걸음걸이를 바꾼다.

하지만 데이터 레이어는 판단의 지형을 만든다. 어떤 문서를 읽게 할 것인가. 어떤 데이터를 신뢰하게 할 것인가. 어떤 시점의 정보를 기준으로 삼게 할 것인가. 무엇을 모르면 모른다고 말하게 할 것인가.

이 지형이 부실하면, 하네스와 펜스가 아무리 좋아도 결과는 흔들린다.

잘 쪼개진 에이전트도 잘못된 자료를 읽으면 틀린다. 엄격한 스키마도 비어 있는 근거를 채워주지는 못한다. 평가 에이전트도 원자료를 보지 못하면 그럴듯한 헛소리와 진짜 통찰을 구분하기 어렵다.

데이터 적재는 프롬프트보다 아래에 있다

프롬프트를 고치면 많은 문제가 해결되는 것처럼 보인다.

"최신 데이터를 기준으로 답해."

"출처를 반드시 명시해."

"추측하지 말고 근거가 있는 것만 말해."

이런 문장은 필요하다. 하지만 충분하지 않다. 최신 데이터가 컨텍스트에 없으면 최신 데이터를 기준으로 답할 수 없다. 출처가 없는 자료를 넣어주면 출처를 명시할 수 없다. 근거가 부족한 상태에서 결론을 요구하면, 모델은 근거 없는 결론을 근거 있는 문장처럼 포장할 수 있다.

프롬프트는 모델의 행동을 바꾼다. 데이터 적재는 모델이 접근할 수 있는 세계를 바꾼다.

이 둘은 레벨이 다르다.

시스템에 없는 데이터를 프롬프트로 꺼낼 수는 없다. 오래된 데이터를 최신이라고 믿게 만든 상태에서 "정확히 분석해줘"라고 말하는 것은, 낡은 지도만 주고 오늘의 길을 찾아오라는 것과 같다.

그래서 리서치 에이전트를 만들 때 어느 순간 프롬프트보다 아래로 내려가야 한다. 어떤 데이터를 수집할지, 어떤 주기로 갱신할지, 어떤 형태로 저장할지, 어떤 단위로 쪼갤지, 어떤 메타데이터를 붙일지, 어떤 검색 전략으로 꺼낼지.

이것은 프롬프트 엔지니어링이 아니다.

데이터 엔지니어링이다.

그리고 에이전트 시스템에서는 이 데이터 엔지니어링이 곧 그라운딩 엔지니어링이 된다.

좋은 컨텍스트와 나쁜 컨텍스트

컨텍스트를 많이 넣는다고 좋은 것은 아니다.

나쁜 컨텍스트는 모델을 더 똑똑하게 만들지 않는다. 오히려 더 자신 있게 틀리게 만든다. 관련 없는 문서, 오래된 문서, 중복된 문서, 출처가 불분명한 문서, 서로 모순되는데 구분되지 않은 문서가 한꺼번에 들어가면 모델은 그 안에서 그럴듯한 평균을 만든다.

리서치에서 평균은 종종 위험하다.

예를 들어 어떤 기업에 대해 세 개의 문서가 있다고 하자.

첫 번째는 2년 전의 낙관적인 산업 리포트다.

두 번째는 어제 나온 실적 발표다.

세 번째는 오늘 장중에 발생한 규제 뉴스다.

이 셋을 같은 무게로 넣고 "요약해줘"라고 하면, 모델은 균형 잡힌 문장을 만들 수 있다. 하지만 투자 판단에 필요한 것은 균형 잡힌 문장이 아닐 수 있다. 오늘의 규제 뉴스가 나머지 두 문서보다 훨씬 중요할 수 있다.

좋은 컨텍스트는 단순히 관련도가 높은 문서가 아니다.

좋은 컨텍스트에는 역할이 있다.

• 이 문서는 무엇에 대한 근거인가
• 언제의 정보인가
• 원문인가, 요약인가
• 어떤 소스에서 왔는가
• 어떤 엔티티와 연결되는가
• 어떤 기존 가설과 연결되거나 충돌하는가
• 이 정보가 추적 상태를 바꿔야 하는가
• 이전 판단을 바꿀 만큼 중요한가
• 서로 모순되는 문서가 있는가

이 메타데이터가 없으면 컨텍스트는 그냥 긴 문자열이다. 모델은 긴 문자열을 읽을 수는 있지만, 시스템은 그 문자열을 관리할 수 없다.

시장 분석 시스템에서 컨텍스트는 문서 조각의 묶음이 아니라 판단의 재료여야 한다. 종목, 섹터, 테마, thesis, narrative, 리포트, 성과 피드백이 연결되어 있어야 한다. 그래야 모델이 "좋은 회사"를 말하는 데서 멈추지 않고, "지금 이 시스템이 이 회사를 어떻게 다뤄야 하는가"까지 갈 수 있다.

벡터 DB만으로는 리서치 시스템이 되지 않는다

RAG를 처음 구현할 때 가장 눈에 띄는 것은 벡터 DB다.

문서를 chunk로 나누고, 임베딩하고, similarity search를 돌린다. 질문과 의미적으로 가까운 문서를 찾아 컨텍스트로 넣는다. 이 구조는 강력하다. 키워드가 정확히 일치하지 않아도 관련 문서를 찾을 수 있고, 자연어 질문에 유연하게 반응한다.

하지만 벡터 DB는 리서치 시스템의 일부일 뿐이다.

시장 분석에서 "비슷한 문서"가 항상 "지금 필요한 문서"는 아니다. 의미적으로 가까운 문서보다 더 최신인 문서가 중요할 수 있다. 특정 기업에 직접 연결된 문서가 섹터 일반론보다 중요할 수 있다. 신뢰도 높은 원문 하나가 블로그 요약 열 개보다 중요할 수 있다.

그래서 리서치 시스템에는 벡터 검색만이 아니라 여러 축의 검색이 필요하다.

• 엔티티 기반 검색: 이 문서가 어떤 기업, 섹터, 테마와 연결되는가
• 시간 기반 검색: 이 정보는 언제 생성되었고, 언제까지 유효한가
• 소스 기반 검색: 이 출처를 얼마나 신뢰할 수 있는가
• 관계 기반 검색: 이 문서가 어떤 기존 thesis, narrative, tracked stock과 연결되는가
• 상태 기반 검색: 이 정보가 이미 반영된 것인가, 새롭게 판단을 바꿔야 하는 것인가
• 피드백 기반 검색: 비슷한 판단이 과거에 어떤 성과로 이어졌는가

벡터 검색은 의미적 근접성을 잘 찾는다. 하지만 리서치 시스템은 의미적 근접성만으로 돌아가지 않는다. 데이터의 계보, 시점, 신뢰도, 연결 관계가 함께 있어야 한다.

결국 중요한 것은 "검색된다"가 아니다.

"판단에 필요한 형태로 검색된다"가 중요하다.

신선도, 출처, 시점

LLM 리서치에서 가장 자주 무너지는 지점은 신선도다.

모델은 오래된 정보를 자연스럽게 말할 수 있다. 검색을 붙여도 마찬가지다. 검색 결과에 오래된 문서가 섞이면, 모델은 그것을 현재형 문장으로 바꿔 말할 수 있다. "최근"이라는 표현은 특히 위험하다. 최근이 24시간인지, 7일인지, 이번 분기인지, 모델은 시스템이 정해주지 않으면 모른다.

그래서 데이터 레이어는 시점을 명시해야 한다.

문서가 발행된 시간. 수집된 시간. 데이터가 나타내는 기준일. 시스템에 반영된 시간. 이 네 가지는 서로 다르다.

예를 들어 5월 10일에 발행된 리포트가 5월 15일에 수집됐고, 그 안의 데이터는 3월 31일 분기 실적을 기준으로 할 수 있다. 모델에게는 이것이 모두 "문서 하나"로 보이지만, 시스템에게는 네 개의 시간이 필요하다.

출처도 마찬가지다.

모든 URL이 같은 무게를 갖지 않는다. 원문 공시, 기업 IR, 거래소 데이터, 애널리스트 리포트, 뉴스 기사, 블로그 요약, 커뮤니티 글은 서로 다른 신뢰도를 가진다. 모델에게 "출처를 봐서 판단해"라고 말하는 것보다, 시스템이 출처 등급을 데이터에 붙여주는 편이 낫다.

시점과 출처가 없는 RAG는 쉽게 커다란 스크랩북이 된다.

스크랩북은 참고자료로는 유용하다. 하지만 자동 판단 시스템의 기반으로 쓰기에는 부족하다.

에이전트는 데이터 위에서만 똑똑해진다

여기서 다시 에이전트로 돌아오자.

에이전트 시스템을 만들 때 우리는 종종 모델의 추론력에 집중한다. 어떤 모델을 쓸지, 어떤 프롬프트를 줄지, 어떤 서브에이전트로 나눌지, 어떤 평가자를 붙일지.

이것들은 모두 중요하다.

하지만 에이전트가 실제로 똑똑해지는 순간은, 좋은 데이터를 안정적으로 읽기 시작할 때다. 모델이 더 많은 말을 해서가 아니라, 더 정확한 재료를 보고 덜 틀린 판단을 하기 시작할 때다.

좋은 데이터 레이어는 에이전트의 자유를 줄이지 않는다. 오히려 자유롭게 판단할 수 있게 만든다. 무엇을 근거로 삼아야 하는지 명확하기 때문에, 에이전트는 쓸데없는 검색과 추측에 에너지를 쓰지 않는다. 이미 정리된 자료실 안에서 비교하고, 연결하고, 모순을 찾고, 결론을 갱신할 수 있다.

이것은 2편에서 말한 펜스와도 닮아 있다.

펜스가 행동의 경계를 선언한다면, 그라운딩은 판단의 바닥을 만든다. 경계가 없으면 에이전트는 드리프트하고, 바닥이 없으면 에이전트는 공중에서 추론한다.

좋은 에이전트 시스템에는 둘 다 필요하다.

결국 AI 시스템은 데이터 시스템이다

프롬프트 엔지니어링은 여전히 중요하다. 하네스 엔지니어링도 중요하고, 펜스 엔지니어링도 중요하다.

하지만 리서치 에이전트를 만들다 보면 결국 더 오래 붙잡게 되는 것은 데이터다.

어떤 데이터를 수집할 것인가. 어떻게 정제할 것인가. 어떤 단위로 저장할 것인가. 어떤 메타데이터를 붙일 것인가. 언제 폐기할 것인가. 어떤 데이터가 어떤 판단을 바꿨는지 어떻게 추적할 것인가.

시장 분석 시스템에서는 여기에 한 가지가 더 붙는다. 어떤 판단이 돈을 벌었는가. 어떤 thesis가 성과로 이어졌고, 어떤 narrative가 노이즈였고, 어떤 추적 기준이 너무 늦었거나 너무 빨랐는지. 이 피드백이 데이터로 남지 않으면 에이전트는 같은 종류의 그럴듯한 실수를 반복한다.

이 질문들은 화려하지 않다. 모델 데모처럼 즉각적인 놀라움을 주지도 않는다. 하지만 시스템의 품질은 여기서 결정된다.

좋은 모델은 부실한 데이터 위에서도 그럴듯한 답을 만든다.

좋은 시스템은 부실한 데이터를 모델에게 넘기지 않는다.

이 차이가 중요하다.

AI 시스템을 만든다는 것은 모델에게 일을 시키는 일이 아니다. 모델이 제대로 일할 수 있는 세계를 만드는 일이다. 그 세계에는 구조가 필요하고, 경계가 필요하고, 무엇보다 신뢰할 수 있는 자료의 지형이 필요하다.

1편에서 에이전트는 함수처럼 설계되어야 한다고 했다.

2편에서 울타리는 타입처럼 선언되어야 한다고 했다.

3편에서 울타리는 여러 재료의 레이어로 구현된다고 했다.

그리고 이제 한 가지를 더 붙이고 싶다.

에이전트는 데이터 위에서만 판단한다.

모델은 기억하지 않는다. 적어도, 우리가 원하는 방식으로는 기억하지 않는다. 그러니 시스템이 기억해야 한다. 무엇을 봤는지, 언제 봤는지, 왜 믿었는지, 어떤 판단에 쓰였는지.

AI 그라운딩 엔지니어링.

모델에게 지식을 "주입"하는 기술이라기보다, 모델이 판단할 수 있는 신뢰 가능한 세계를 설계하는 기술. 나는 그렇게 이해하고 있다.