검색 문제를 고친다고 파인튜닝부터 하지 마라 — Anant Srivastava

메타데이터

• 원문 제목: Stop Fine-Tuning to Fix Retrieval Problems — Anant Srivastava
• URL: https://www.youtube.com/watch?v=qflLT3SoVbw
• 날짜: 2026-10-04
• 채널: aiDotEngineer
• 영상 길이: 20분 11초
• 주제: 프롬프트(prompt), 메모리·검색(memory/retrieval), 모델 가중치(model weights)의 역할 분리와 파인튜닝(fine-tuning) 진단

---

📌 핵심 질문 / 다루는 핵심 논점

==기업용 AI 시스템에서 틀린 답이 나올 때 프롬프트·검색·파인튜닝을 사다리의 다음 단계처럼 차례로 올리는 대신, 지식과 행동과 추론 능력을 각각 올바른 장소에 배치해야 한다.==

• 프롬프트는 작고 안정적이며 쉽게 바꿀 수 있는 행동(behavior)을 담아야 한다.
• 메모리(memory)는 크고 자주 바뀌며 출처를 가리킬 수 있는 사실과 지식(knowledge)을 담아야 한다.
• 모델 가중치(model weights)는 합의가 끝난 안정적인 패턴과 추론·형식화 능력을 담아야 하며, 검색 실패를 대신 해결하는 창고가 아니다.

모델은 토큰을 입력받고 토큰을 출력할 뿐이고, 실제 기업 지식은 파일·데이터베이스·API에 존재한다. 따라서 가장 중요한 엔지니어링 문제는 모델 자체가 아니라 그 지식을 추론(inference)에 어떤 경로로 전달하고, 시간이 지나며 어느 저장소로 이동시킬지 설계하는 일이다.

1. 지식을 어디에 둘지 결정하는 일이 AI 아키텍처다

1.1. 기업용 AI의 핵심은 모델 주변의 정보 흐름이다

1. 모델과 지식의 위치는 다르다

   1. 모델의 역할: 모델은 토큰을 소비하고 토큰을 생성한다. 모델이 기업의 모든 사실을 영구적으로 알고 있다고 가정할 수 없다.
   2. 지식의 실제 위치: 제품 문서와 정책은 파일에 있고, 운영 데이터는 데이터베이스에 있으며, 최신 상태와 동작은 API에 있다.
   3. 핵심 설계 질문: 파일·DB·API의 지식을 프롬프트나 컨텍스트(context)로 직접 넣을지, 검색·메모리 계층을 거칠지, 모델 적응(model adaptation)이나 파인튜닝으로 옮길지를 의식적으로 결정해야 한다.

2. 세 가지 수단은 상하위 사다리가 아니다

   1. 프롬프트(prompt): 모델이 어떻게 행동할지를 지정하는 수단이다.
   2. 메모리·검색(memory/retrieval): 모델이 무엇을 알아야 하는지에 해당하는 외부 지식 접근 수단이다.
   3. 파인튜닝과 가중치(fine-tuning and weights): 안정된 패턴을 모델이 반사적으로 수행하게 만드는 모델 적응 수단이다.
   4. 핵심 교정: 검색이 안 된다고 더 높은 단계인 파인튜닝으로 올라가는 식의 단계적 사고는 세 수단의 목적을 혼동한다. 서로 다른 문제를 해결하는 서로 다른 도구로 판단해야 한다.

1.2. 팀이 잘못된 선택을 누적하는 두 가지 메커니즘

1. 점진적으로 수위를 올리는 습관

   1. 첫 번째 반응: 모델이 정답을 내지 않으면 가장 손쉬운 조치인 프롬프트 수정을 먼저 한다.
   2. 두 번째 반응: 프롬프트를 고쳐도 틀리면 메모리 시스템이나 검색 시스템을 살핀다.
   3. 세 번째 반응: 그래도 틀리면 드물지만 모델을 재학습(retraining)한다.
   4. 문제의 본질: 이 과정은 진단에 따른 선택이 아니라 어려움이 커질수록 더 강한 도구로 올라가는 사다리처럼 굳어진다.

2. 각 변경이 보이지 않는 아키텍처 결정을 만든다

   1. 프롬프트 편집: 매번의 프롬프트 편집은 특정 행동을 시스템에 심는다.
   2. 문서 인덱싱: 인덱스에 넣는 문서 하나하나가 메모리에 저장될 지식을 결정한다.
   3. 학습 데이터 추가: 정의한 학습 예제 하나하나가 모델 가중치에 무언가를 굳힌다.
   4. 이름 붙이지 않은 아키텍처: 모두 아키텍처 결정이지만, 팀은 이를 정식 설계가 아니라 당장의 수정 작업으로 부른다.

2. 지원 어시스턴트 사례가 보여주는 우연한 아키텍처

2.1. 출시 뒤 이어지는 작은 수정이 책임 경계를 흐린다

1. 내부 지원 어시스턴트의 초기 출시

   1. 내부 지원 어시스턴트가 출시되고 몇 주가 지난다.
   2. 제품 관리자는 어시스턴트의 말투를 고치기 위해 프롬프트를 수정한다.
   3. 말투처럼 사용자 질의와 무관하게 유지되어야 하는 행동 규칙은 프롬프트에 두는 것이 자연스럽다.

2. 환불 정책과 제품 카탈로그의 유입

   1. 몇 주 뒤 지원팀은 환불 정책 문서를 검색·메모리 시스템에 추가한다. 여기서 메모리는 에이전트 내부 기억뿐 아니라 외부 검색 계층까지 넓은 의미로 사용된다.
   2. 에이전트가 여전히 올바른 답을 하지 않자 엔지니어는 제품 카탈로그를 프롬프트에 욱여넣는다.
   3. 다시 몇 주 뒤 머신러닝 팀은 최근 6개월의 지원 티켓으로 모델을 학습하거나 재학습한다.
   4. 각각의 조치는 그 순간에는 그럴듯하고 받아들일 만해 보이지만, 무엇을 어디에 둬야 하는지 결정한 사람은 없다.

2.2. 새 카탈로그 출시가 숨은 가중치 오염을 드러낸다

1. 겉보기에는 단순한 업데이트

   1. 새로운 제품 카탈로그가 출시되면 엔지니어는 프롬프트에 새 카탈로그를 넣으면 된다고 생각한다.
   2. 그런데 새 카탈로그를 넣은 뒤에도 모델이나 에이전트가 존재하지 않는 제품명을 계속 말한다.

2. 오래된 사실이 모델 가중치에 남은 이유

   1. 과거 카탈로그가 지원 티켓과 함께 재학습 데이터에 섞였다.
   2. 그 카탈로그의 사실이 모델 가중치로 새어 들어가면서, 프롬프트에 최신 카탈로그를 넣어도 낡은 제품명이 출력된다.
   3. 이는 하나의 잘못된 수정이 아니라 지난 6개월 동안 모델·검색·프롬프트에 사실을 누적한 결과다.
   4. 아키텍처가 설계된 것이 아니라 우연히 축적되었고, 모두가 일부를 소유했지만 전체를 책임지는 사람은 없었다.

3. 먼저 물었어야 할 진단 질문

   1. 이 정보는 행동인가, 사실인가, 추론 능력인가?
   2. 이 정보는 어디에 살아야 하는가?
   3. 얼마나 자주 바뀌며, 누가 접근할 수 있는가?
   4. 이런 질문을 하지 않은 채 일상적인 수정만 6개월 동안 반복한 것이 잘못된 제품명 문제를 만들었다.

3. 프롬프트는 행동을 저장한다

3.1. 프롬프트에 어울리는 정보

1. 프롬프트의 직무

   1. 프롬프트는 행동(behavior)을 지정한다.
   2. 말투(tone), 에이전트의 페르소나(persona), 답변 절차와 같은 작고 안정적인 규칙이 핵심이다.
   3. 쉽게 편집하고 즉시 시험할 수 있어야 하며, 질의마다 변하지 않는 운영 원칙을 표현한다.

2. SaaS 지원 에이전트의 안정적 행동

   1. 전문적인 말투를 사용한다.
   2. 세 번 실패하면 사람에게 연결하거나 사람에게 전환하도록 제안한다.
   3. 사용자가 다음에 해야 할 구체적인 단계를 제공한다.
   4. 위 행동은 특정 질의나 사용자에 따라 바뀌지 않으므로 프롬프트에 잘 맞는다.

3. 프롬프트의 범위

   1. 프롬프트는 시스템 프롬프트(system prompt)만 뜻하지 않는다.
   2. 작성자가 모델에 주는 지시(author instructions)도 포함한다.
   3. MD 파일이나 다른 설정 파일에서 읽어오는 지시 역시 이 넓은 의미의 프롬프트에 들어간다.

3.2. 프롬프트에 사실을 넣으면 생기는 비용

1. 제품 카탈로그는 프롬프트의 일이 아니다

   1. 제품 카탈로그를 프롬프트에 넣는 것은 모델에 사실을 전달하는 일이지 행동을 지정하는 일이 아니다.
   2. 카탈로그가 바뀔 때마다 프롬프트를 갱신해야 하고, 매 요청마다 큰 컨텍스트를 지불해야 한다.
   3. 모든 내용을 컨텍스트에 넣으면 모델이 실제로 필요한 정보를 구분하기 어려워진다.

2. ‘중간에서 잊기(lost in the middle)’ 문제

   1. 토큰이 지나치게 많아지면 모델은 컨텍스트 중간에 있는 중요한 정보를 잘 활용하지 못할 수 있다.
   2. 따라서 프롬프트 진단은 “무엇을 알아야 하는가?”보다 “어떻게 행동해야 하는가?”를 물어야 한다.
   3. 작고 안정적인 행동 규칙이 아니라 크고 변하는 사실이 프롬프트에 있다면 저장 위치가 틀린 것이다.

4. 메모리와 검색은 변화하는 사실을 보관한다

4.1. 외부 메모리의 세 가지 진단 기준

1. 관련되고 큰 지식

   1. 메모리는 모델이나 에이전트를 현재 질의와 관련된 지식으로 고정(anchor)한다.
   2. 지식이 너무 커서 요청의 컨텍스트 창에 통째로 넣을 수 없다면 외부 메모리에 둔다.

2. 현재성(current)

   1. 학습으로 따라잡을 수 있는 속도보다 더 빠르게 바뀌는 정보는 가중치가 아니라 메모리에 둔다.
   2. 환불 정책, 제품 목록, 내부 절차처럼 운영 중 바뀌는 사실을 재학습하는 동안 이미 낡게 만들면 안 된다.

3. 참조 가능성(linkable)

   1. 운영 AI 시스템은 지식의 출처를 가리킬 수 있어야 한다.
   2. 검색된 문서나 DB 레코드와 연결해 근거를 제시해야 하는 정보는 외부 메모리에 두는 편이 맞다.

4.2. 에이전트 메모리와 기업 메모리

1. 두 종류의 메모리

   1. 에이전트 메모리는 에이전트와 상호작용하는 사람에 관해 얻은 지식처럼 개인별 맥락을 담는다.
   2. 기업 메모리는 환불 정책처럼 조직이 관리하는 외부 애플리케이션의 지식을 담는다.
   3. RAG(retrieval-augmented generation)로 추출하는 외부 문서와 기타 검색 계층도 넓은 의미의 메모리에 포함된다.

2. 메모리에 넣지 말아야 할 것

   1. 행동 규칙을 메모리에 밀어 넣고 그때그때 검색하게 만들면 안정적인 운영 원칙이 흔들린다.
   2. 메모리 자체에 복잡한 추론 방법을 저장하려 해서도 안 된다.
   3. Graph RAG가 에이전트의 추론을 보조할 수는 있지만, 검색 구조가 모델의 추론 능력을 대신하지는 않는다.

3. 컨텍스트를 늘리는 것만으로 추론은 생기지 않는다

   1. 모델이 문서 두세 개 또는 다섯 개를 놓고 추론하지 못한다면 문서 50개를 제공해도 해결되지 않는다.
   2. 더 많은 컨텍스트는 충분한 추론 능력이 있을 때만 도움이 된다.
   3. 검색 품질과 모델 능력을 분리해서 진단해야 하며, 검색 결과를 무작정 늘리는 방식은 답이 아니다.

4.3. 코드 어시스턴트와 접근 제어

1. 코드베이스는 재학습 대상이 아니다

   1. 조직의 모든 저장소에 접근하는 코드 어시스턴트가 코드 지식을 갖게 하려고 모델을 재학습할 이유는 없다.
   2. 코드베이스는 계속 바뀌므로 최신 코드라는 사실을 학습시키는 동안 이미 낡는다.
   3. 모델 재학습은 사실(facts)이 아니라 기술(skill)을 익히게 할 때 고려한다.
   4. 전체 코드베이스를 질의에 넣는 것도 옳지 않으며, 현재 작업에 필요한 코드 조각만 컨텍스트에 넣어야 한다.

2. RAG의 청킹과 구조 인식

   1. 코드는 일반 텍스트처럼 무작위 길이로 자르면 의미 단위가 깨진다.
   2. AST(Abstract Syntax Tree)를 사용해 함수·클래스·모듈 같은 구조를 이해한 뒤 적절히 청킹(chunking)하는 방법이 필요하다.

3. 필터링과 비정규화(denormalization)

   1. 검색 데이터에는 코드가 어느 저장소에 속하는지 나타내는 메타데이터를 함께 만들어야 한다.
   2. 어떤 사용자가 커밋 권한을 갖는지, 어떤 사용자가 읽을 수 있는지 같은 권한 정보도 메타데이터에 담아야 한다.
   3. 저장소·사용자·권한을 기준으로 먼저 필터링하면 현재 사용자가 볼 수 있는 정확한 데이터만 가져올 수 있다.
   4. 권한과 출처를 고려하지 않은 RAG는 DB의 조각을 마구 섞어 반환하는 ‘RAG-mash’가 되고, 모델을 혼란스럽게 한다.

4. 외부 메모리의 최종 진단표

   1. 정보가 너무 큰가?
   2. 모델을 재학습하는 속도보다 빠르게 바뀌는가?
   3. 사용자·저장소·조직 단위의 접근 범위가 있는가?
   4. 하나라도 해당하면 애플리케이션 DB 같은 외부 저장소나 에이전트 저장소를 우선 검토한다.

5. 모델 가중치와 파인튜닝은 안정된 패턴을 저장한다

5.1. 변화 속도가 가중치 배치의 기준이다

1. 멈춘 변화만 가중치에 포착한다

   1. 더 이상 바뀌지 않는 정보와 합의된 패턴은 모델 가중치에 포착할 후보가 된다.
   2. 핵심 파라미터는 정보의 변화 속도다.
   3. 어떤 경계가 아직 변하는 중이라면 먼저 그 경계를 동결(freeze)하지 말고 외부 메모리에 남겨야 한다.

2. 파인튜닝은 자동으로 선택하는 다음 단계가 아니다

   1. 정보가 안정되었다고 해서 즉시 재학습해야 한다는 뜻은 아니다.
   2. 파인튜닝에는 분명한 이유와 충분한 검증이 필요하며, 일상적인 오류 수정 수단으로 사용하면 안 된다.
   3. 가격표를 모델에 외우게 하려고 파인튜닝하는 팀은 거의 없지만, 문서와 절차를 학습시키는 순간 같은 실수가 더 미묘하게 발생한다.

5.2. 문서 검색 실패를 파인튜닝으로 덮은 사례

1. 내부 문서 어시스턴트의 잘못된 처방

   1. 내부 문서 어시스턴트가 올바른 답을 주지 않자 팀은 도메인을 이해시키기 위해 모델을 재학습하자고 결정한다.
   2. 팀은 회사의 모든 문서 또는 지시사항과 절차 문서만 골라 모델에 학습시키려 한다.
   3. 겉으로는 회사 지식을 모델에 넣는 합리적인 방법처럼 보인다.

2. 실제 문제는 데이터 검색이었다

   1. 모델이 틀린 답을 낸 이유는 필요한 문서 조각을 받지 못했기 때문일 수 있다.
   2. 필요한 것은 정확한 절차와 문서의 올바른 fragment를 검색하는 일이었다.
   3. 검색 문제를 해결하지 않고 모델을 파인튜닝하면 현재 문서 대신 과거 학습 데이터에 있던 낡은 정보를 답하게 된다.
   4. 지시사항과 절차는 사실이므로 에이전트 가중치가 아니라 외부 메모리에 있어야 한다.

3. 실전 규칙

   1. 모델이 올바른 답을 하지 않으면 우선 데이터 검색 문제를 고친다.
   2. 필요한 문서가 검색되었는지, 올바른 조각으로 나뉘었는지, 권한 필터를 통과했는지, 모델이 그 조각을 읽고 추론했는지를 순서대로 확인한다.
   3. 파인튜닝을 먼저 실행하면 검색 결함과 낡은 지식이 가중치 안에 굳어져 나중에 원인을 추적하기가 더 어려워진다.

5.3. 파인튜닝에 적합한 복잡하고 모호한 업무

1. 사람의 수정에서 안정된 패턴을 찾기

   1. 콘텐츠 조정(content moderation)이나 보험 청구 처리(insurance claims processing)처럼 복잡하고 모호한 업무는 초기부터 완전한 규칙으로 표현하기 어렵다.
   2. 처음에는 강력한 모델이 권고안을 만들고 사람이 그 결과를 수정한다.
   3. 사람의 수정이 처음에는 항상 일관되지는 않지만 시간이 지나면 반복되는 패턴이 나타난다.

2. 안정된 중심과 논쟁적인 경계

   1. 반복 패턴의 중심부(center)는 비교적 고정되고 안정된다.
   2. 중심과 달리 논쟁적인 경계(disputed border)는 여전히 사람의 판단이 필요하다.
   3. 일정 시점 이후 사람의 개입 수준이 안정되면, 중심부를 모델에 더 학습시키고 애매한 경계는 사람에게 남기는 구조가 가능하다.

3. 드리프트(deviation) 감시

   1. 파인튜닝 뒤에는 안정됐다고 생각한 중심부가 다시 흔들리는지 확인해야 한다.
   2. 중심부에서 벗어나는 편차가 생기면 모델이 합의된 패턴까지 잘못 적용하고 있다는 신호다.
   3. 파인튜닝은 경계를 없애는 작업이 아니라, 안정된 중심과 사람에게 남길 경계를 분리하는 작업이다.

5.4. 의료 청구 코딩과 ICD-10 사례

1. 고정된 형식의 실제 사례

   1. 의료 청구 코딩은 의사의 기록을 보험 등의 목적에 맞는 코드로 연결한다.
   2. ICD-10(International Classification of Diseases, 10th Revision)처럼 정해진 코드 체계가 사용된다.
   3. Mount Sinai와 IMO Health가 이 업무의 사례로 언급된다.
   4. 코드 수가 약 7만 개에 달해도, 이 코드를 모델에 통째로 암기시키는 것은 적절하지 않다.

2. 왜 코드도 무작정 학습하지 않는가

   1. 코드는 자주 변하지 않지만 때때로 변경된다.
   2. 사실과 지식은 여전히 출처를 확인하고 갱신할 수 있는 메모리에 두는 편이 안전하다.
   3. 파인튜닝을 하려면 학습용·검증용 데이터가 매우 많이 필요하다.
   4. 무엇을 학습시키는지, 입력 형식을 이해하는지, 여러 형식 중 어떤 것이 맞는지 선택할 수 있는지를 먼저 정의해야 한다.

6. 파인튜닝 여부를 가르는 진단 프리즘

6.1. 안정성·합의·목적을 동시에 확인한다

1. 안정성 질문

   1. 이 정보의 변화가 멈췄는가?
   2. 최신 상태를 검색으로 계속 제공해야 하는 사실인가?
   3. 사람과 조직이 해당 판단에 합의했는가?

2. 능력과 비용이라는 두 가지 정당한 이유

   1. 파인튜닝의 이유는 모델이 충분히 능력 있지 않아서인가?
   2. 아니면 명확한 작업 템플릿을 작은 모델에 심어 비용을 줄이려는 것인가?
   3. 최신 고성능 모델은 대체로 강력하므로 실제 현장에서는 능력 부족보다 비용 절감이 동기가 되는 경우가 많다.
   4. 안정된 템플릿을 작은 모델에 파인튜닝하면 대량의 데이터를 저렴하게 처리할 수 있다.

3. 한 문장 규칙

   1. 변화가 멈췄고 사람들의 판단이 합의됐으며, 능력 향상이나 비용 절감이라는 명확한 목적이 있을 때만 파인튜닝을 검토한다.
   2. 검색해야 하는 최신 사실을 모델 가중치에 넣는 것은 이 규칙을 어기는 일이다.

6.2. 세 저장소를 빠르게 대조하는 표

저장 위치	주된 질문	적합한 내용	피해야 할 내용
프롬프트·컨텍스트(prompt/context)	어떻게 행동해야 하는가?	말투, 페르소나, 안정된 운영 지시, 즉시 바꿀 행동	큰 제품 카탈로그, 변하는 정책, 대규모 사실 저장소
메모리·검색(memory/retrieval)	무엇을 알아야 하는가?	크고 현재적이며 출처를 가리킬 수 있는 사실, 사용자·권한별 데이터	안정된 행동 규칙, 모델의 기본 추론 능력 자체
모델 가중치·파인튜닝(weights/fine-tuning)	어떻게 추론하고 패턴을 수행할 것인가?	합의된 형식, 안정된 작업 패턴, 비용 절감을 위한 작은 모델의 능력	최신 가격·정책·카탈로그, 검색 실패를 덮는 문서 암기

이 표는 예외가 전혀 없다는 법칙이 아니라 현재 시스템을 빠르게 진단하는 프리즘이다. 특수한 예외가 있더라도 먼저 “행동인가, 지식인가, 안정된 추론 패턴인가?”를 물으면 임의적인 저장 위치를 줄일 수 있다.

7. 정보는 세 저장소 사이를 순환한다

7.1. 컨텍스트에서 메모리로 흐르는 신호

1. 요청이 신호를 만든다

   1. 질의 또는 컨텍스트 창에는 현재 작업에 필요한 정보가 들어간다.
   2. 작업을 수행하는 동안 일부 정보가 반복적으로 중요하다는 신호를 만든다.
   3. 그 신호 중 일부는 장기 메모리(long-term memory)가 된다.

2. 새 세션에서 메모리가 되돌아온다

   1. 새 세션이 시작되면 관련 장기 메모리가 메모리 계층에서 질의·컨텍스트 창으로 끌려온다.
   2. 이 흐름은 컨텍스트에서 메모리로, 다시 메모리에서 컨텍스트로 이어진다.
   3. 개인화된 에이전트와 기업 지식 시스템 모두 이 양방향 흐름을 설계해야 한다.

7.2. 메모리에서 가중치로 이동하는 과정

1. 반복 사용이 검색 패턴을 만든다

   1. 에이전트 시스템을 오랜 기간 운영하면 어떤 정보를 검색해야 하는지에 관한 검색 패턴이 쌓인다.
   2. 모델이 매번 예시를 보지 않아도 알아야 하는 출력 형식도 나타난다.
   3. 이런 안정된 패턴과 형식이 외부 메모리에서 파인튜닝 데이터로 이동할 수 있다.

2. 파인튜닝 뒤 달라지는 컨텍스트

   1. 노트 형식이나 ICD 코드 형식을 모델이 학습하면 매번 외부 저장소에서 형식 예시를 꺼내 보여줄 필요가 줄어든다.
   2. “이것이 한 형식이고 저것이 다른 형식이다”라고 반복해서 설명하지 않아도 모델이 형식을 자동으로 적용한다.
   3. 그 결과 외부 메모리에서 가중치로 이동한 패턴과, 가중치에서 다시 메모리로 내려보낼 예외·최신 정보가 구분된다.

3. 순환하는 아키텍처

   1. 에이전트가 일을 수행할수록 중요한 경험은 메모리에 남고, 충분히 안정된 경험은 모델 가중치에 반영된다.
   2. 가중치에 굳어진 패턴은 매 요청마다 예시를 가져오는 비용을 줄인다.
   3. 정책과 사실이 다시 바뀌면 최신 정보는 외부 메모리에서 가져오고, 가중치에는 안정된 중심만 남겨야 한다.
   4. 이 순환이 모델과 정보 저장소를 함께 성장시키는 기업 AI 아키텍처다.

주요 발언 모음

“대부분의 기업 팀은 이 결정을 우연히 내린다.”

“이것들은 당신이 올라가는 사다리의 단계가 아니라, 서로 다른 작업을 위한 세 가지 다른 도구다.”

“모델이 두세 개 또는 다섯 개의 문서로 추론하지 못한다면, 50개를 줘도 추론하지 못한다.”

“모델이 올바른 답을 주지 않는다면 데이터 검색 문제를 고쳐라. 곧바로 모델을 학습시키려 하지 마라.”

“모델은 가장 쉬운 부분이다. 올바른 정보를 올바른 장소에 두고 그 사이를 순환시키는 모델 주변의 프레임워크가 핵심 아키텍처다.”

핵심 데이터 & 수치

• 6개월: 지원 티켓을 최근 6개월치 재학습에 사용하면서 과거 제품 카탈로그가 모델 가중치에 섞인 사례가 제시된다.
• 3회 실패: SaaS 지원 에이전트가 세 번 실패하면 사람에게 전환을 제안하도록 하는 안정된 프롬프트 행동의 예다.
• 2·3·5개 대 50개 문서: 적은 문서로도 추론하지 못하는 모델에 더 많은 검색 결과를 주는 것이 해결책이 아님을 보여주는 비교다.
• 약 70,000개: 의료 청구 코딩에서 언급된 ICD-10 코드 규모다.
• 두 가지 파인튜닝 목적: 모델 능력 부족을 보완하거나, 명확한 작업 템플릿을 작은 모델에 넣어 비용을 낮추는 경우다.
• 세 가지 저장 위치: 프롬프트·컨텍스트는 행동, 메모리·검색은 사실과 지식, 모델 가중치는 안정된 추론 패턴을 담당한다.

결론 및 시사점

1. 틀린 답을 고칠 때 프롬프트 수정, 검색 개선, 파인튜닝을 강도 순으로 선택하지 말고 정보의 성격을 먼저 진단한다.
2. 말투·페르소나·고정된 운영 절차처럼 작고 안정적인 행동은 프롬프트에 둔다.
3. 제품 카탈로그·환불 정책·내부 문서·코드베이스처럼 크고 변하며 출처와 권한이 필요한 사실은 외부 메모리와 검색에 둔다.
4. RAG에서 올바른 청킹, AST 기반 코드 구조 인식, 저장소·사용자·권한 메타데이터 필터링을 구현해 RAG-mash를 막는다.
5. 모델이 검색 결과를 읽고 추론하지 못하는 문제를 문서 수를 늘리거나 파인튜닝하는 방식으로 숨기지 않는다.
6. 파인튜닝은 변화가 멈추고 사람의 판단이 합의된 안정된 중심 패턴에만 적용한다.
7. 파인튜닝 목적은 모델 능력 향상 또는 명확한 템플릿을 작은 모델에 넣어 비용을 줄이는 일 중 하나여야 한다.
8. 메모리에서 반복되는 검색 패턴과 형식이 충분히 안정되면 가중치로 이동시키고, 최신 사실과 논쟁적 경계는 계속 외부에 둔다.
9. 컨텍스트·메모리·가중치는 단방향 저장소가 아니라 신호와 경험이 오가는 순환 구조로 설계한다.
10. 모델 자체보다 올바른 정보를 올바른 장소에 배치하고 저장소 사이에서 흐르게 하는 프레임워크가 기업 AI의 핵심 아키텍처다.

핵심 요약 (20줄)

기업용 AI의 가장 중요한 설계 문제는 모델보다 기업 지식을 추론에 전달하는 경로다. 프롬프트·메모리·모델 가중치는 상하위 사다리가 아니라 서로 다른 문제를 해결하는 도구다. 프롬프트는 모델이 무엇을 알아야 하는지가 아니라 어떻게 행동해야 하는지를 지정한다. 말투·페르소나·세 번 실패하면 사람에게 연결하는 규칙은 프롬프트에 적합하다. 제품 카탈로그를 프롬프트에 넣으면 컨텍스트 비용이 커지고 중간 정보가 묻힐 수 있다. 메모리는 크고 자주 바뀌며 출처와 접근 권한을 관리해야 하는 사실을 보관한다. 에이전트의 개인 기억과 RAG로 조회하는 기업 문서는 모두 넓은 의미의 메모리다. 모델이 적은 문서로 추론하지 못한다면 검색 결과를 50개로 늘려도 근본 문제는 해결되지 않는다. 코드 어시스턴트는 변하는 코드베이스를 재학습하지 말고 필요한 코드 조각을 권한에 맞게 검색해야 한다. AST 기반 청킹과 저장소·사용자·권한 메타데이터가 정확한 코드 검색을 돕는다. 검색 실패를 파인튜닝으로 덮으면 낡은 문서와 잘못된 사실이 모델 가중치에 굳어진다. 지원 티켓에 섞인 과거 제품 카탈로그가 새 카탈로그 이후에도 존재하지 않는 제품명을 만든다. 파인튜닝은 정보의 변화가 멈추고 사람들의 판단이 합의됐을 때만 검토해야 한다. 복잡한 콘텐츠 조정과 보험 청구 처리는 사람의 수정에서 안정된 중심 패턴을 찾을 수 있는 사례다. 논쟁적인 경계는 사람에게 남기고 안정된 중심만 가중치에 넣어야 한다. ICD-10 코드가 약 7만 개여도 사실과 지식이라는 이유만으로 모델에 암기시켜서는 안 된다. 현대 모델이 충분히 강력하다면 파인튜닝의 실용적 동기는 능력보다 비용 절감인 경우가 많다. 안정된 작업 템플릿을 작은 모델에 파인튜닝하면 대량 처리를 더 저렴하게 수행할 수 있다. 컨텍스트에서 메모리로, 메모리에서 가중치로 이동하는 정보 흐름은 다시 외부 메모리로 돌아오는 순환 구조다. 기업 AI의 핵심은 모델 자체가 아니라 올바른 정보를 올바른 장소에 두고 순환시키는 프레임워크다.