Chapter 3 · The Spectrum of LLM Adaptation for Agents: RAG to Fine-tuning

얕게 고칠 것인가,
깊게 고칠 것인가

『Agentic Architectural Patterns for Building Multi-Agent Systems』 3장 — Ali Arsanjani, Juan Pablo Bustos, Thomas Kurian

1장이 지도였고 2장이 엔진이었다면, 3장은 조율이다. 사전학습된 LLM은 설계상 제너럴리스트다. 그러나 기업의 에이전트는 스페셜리스트여야 한다. 금융, 의료, 법률에는 저마다의 어휘와 워크플로와 사유(私有) 데이터가 있고, 범용 모델은 그것을 상자에서 꺼낸 그대로 이해하지 못한다. 이 간극을 메우는 방법이 네 가지 있다. 그리고 그 넷은 깊이가 다르다.

1

From generic LLMs to specialized agents

제너럴리스트에서 스페셜리스트로

생성형 AI의 첫 물결은 거대한 단일 프런티어 모델에 집중했다. 그러나 지형은 지능적 에이전트들의 분산된 사회로 옮겨가고 있다. 사업 가치를 끌어내려면 이 에이전트들이 특정 기업 맥락 안에서 정확하고 신뢰할 만하며 최적으로 작동해야 한다. 그러려면 상당한 적응이 필요하다.

또 하나의 변화가 있다. 단일 중앙 LLM에 의존하던 방식에서 벗어나는 것이다. 여러 에이전트로 구성된 분산 시스템이 늘고 있고, 각 에이전트는 저마다의 “뇌”를 가질 수 있다. 내부 모델은 비용, 성능, 지연, 품질에 따라 달라지고, 역할에 따라 양상이나 아키텍처가 다를 수도 있다. 업계에서 Router-ExecutorPlanner-Worker라 부르는 관행이 그것이다. 이 책은 5장에서 Tool RoutingSupervisor Architecture 패턴으로 이 개념을 정식화한다.

특화가 가져오는 네 가지

01 · Accuracy

정확성과 관련성

에이전트가 자기 도메인의 언어를 말하게 된다. 용어와 문맥이 맞아떨어진다.

02 · Reliability

신뢰성

모델을 접지시켜 환각의 위험을 줄인다. 믿을 수 있는 출력이 나온다.

03 · Efficiency

효율

작고 집중된 모델이 특정 과업에서 더 낮은 지연과 비용으로 더 나은 성능을 낸다.

04 · Alignment

목표 정렬

에이전트의 행동을 운영 목표와 제약에 정확히 맞춘다.

그런데 여기서 흔한 오해 하나를 짚어야 한다. 적응은 하나의 방법을 고르는 문제가 아니다. 에이전트의 요구와 맥락, 가용 자원, 필요한 맞춤화의 정도에 맞춰 여러 전략을 사려 깊게 조합하는 문제다. RAG 하나로 될 일도 있고, 파인튜닝까지 가야 할 일도 있고, 셋을 다 써야 할 일도 있다.

2

The agentic AI maturity model

에이전틱 AI 성숙도 여섯 단계 — 1장 모델의 확대경

1장의 GenAI 성숙도 모델에서 마지막 두 단계는 단일 에이전트와 멀티 에이전트였다. 여기서는 그 둘을 확대해 여섯 단계의 에이전틱 AI 성숙도 모델로 펼친다. 단순하고 중앙집중적인 모델에서 복잡하고 분산된 협업 네트워크에 이르는 여정이다. 이 스펙트럼은 왜 시스템이 복잡해지고 자율성이 커질수록 Multi-Agent Planning, Consensus, Resource Allocation, Trust Modeling 같은 패턴이 필수가 되는지를 설명한다.

성숙도 단계설명확장성 관점규제 준수 관점핵심 패턴
1 · 기본 에이전틱 시스템 단일 에이전트가 명확히 정의된 과업을 반자율적으로 처리한다. 단순한 사전 정의 워크플로와 외부 API·도구 함수 호출을 쓴다. 적응은 되지만 경직돼 있다. 워크플로가 비교적 고정이라 혁신의 여지가 제한된다. 과업이 잘 정의돼 있어 관리가 간단하다. 정책 위반 위험이 최소화된다. 단일 에이전트·단일 LLM이 함수 호출로 도구를 부른다
2 · 동적 단일 에이전트 워크플로 단일 에이전트가 사전 선정된 여러 도구·API 중에서 문제에 따라 동적으로 고른다. 더 유연한 문제 해결이 가능하다. 더 다재다능하고 효율적이다. 적절한 도구를 골라 더 복잡한 문제를 다룬다. 승인된 도구를 미리 선별하므로 관리 가능하다. 다만 자율성이 커지는 만큼 행동 감시가 필요하다. 동적 도구 선택을 하는 기본 에이전틱 시스템
3 · ReAct와 Reflexion의 내성 패턴 단일 에이전트가 ReAct와 Reflexion 패턴으로 단계적 추론과 자기 성찰을 한다. 피드백 루프로 행동에서 배우고 스스로 교정한다. 피드백과 자기수정의 도입으로 더 복잡한 과업을 다루고 시간이 갈수록 개선된다. 확장의 길이 열린다. 실시간 감시와 시정 기제가 필수가 된다. 학습하는 동안에도 정책에 부합해야 하기 때문이다. ReAct, Reflexion
4 · 멀티 에이전트 시스템 여러 전문 에이전트가 협업해 복잡한 과업을 다룬다. 각자 겹치지 않는 기능에 집중하고, 조율을 통해 병렬 처리가 가능해진다. 대규모 환경에 이상적이다. 과업을 여러 에이전트에 분산해 복잡한 워크플로를 효율적으로 병렬 처리한다. 관리가 더 복잡하다. 반자율 에이전트들이 규제에 맞게 협업하는지 확인할 감시 체계가 필요하다. 멀티 에이전트 시스템
5 · 메타 에이전트를 둔 고급 조율 다른 에이전트들을 감독하고 조율하는 메타 에이전트가 등장한다. 동적 과업 재배정과 실시간 계획 조정이 가능해진다. 적응력이 향상된다. 메타 에이전트의 최적화된 과업 분배 덕에 변화하는 환경에서도 효과적으로 확장된다. 메타 에이전트가 감독자 역할을 한다. 워크플로를 조정하고 과업을 재분배해 정책 준수를 유지하도록 돕는다. 메타 에이전트 정책 준수, 고급 조율, 충돌 해소
6 · 자기수정 에이전트 복잡한 다중 턴 피드백 루프를 쓴다. 에이전트들이 서로의 출력을 비평하고 교정하고 다듬기를 반복해 지속적 프로세스 개선을 이룬다. 지속적 개선이 내장돼 확장성이 매우 높다. 실시간으로 진화하므로 동적 과업에 극히 효율적이다. 가장 복잡하다. 자동화된 준수 점검과 자기수정 행동이 필요하다. 적응하면서도 정책에 계속 부합해야 한다. 멀티 에이전트 학습 시스템

〈표 3.1〉 에이전트와 LLM의 성숙도 스펙트럼

에이전트의 입도(粒度)

더 진보한 시스템으로 갈수록 설계상의 질문 하나가 떠오른다. 에이전트는 얼마나 커야 하는가. 하나의 에이전트가 업무 프로세스 전체를 감싸야 하는가, 아니면 더 큰 AI 오케스트레이션의 일부로서 단순하고 원자적인 과업에 집중해야 하는가.

정답은 하나가 아니다. 최적의 입도는 문제에 달렸다. 에이전트는 세밀한 원자 단위일 수도 있고 — 재고 수준만 확인하는 에이전트처럼 — 거친 복합 시스템일 수도 있다 — 주문 이행 전 과정을 조율하는 에이전트처럼. 다음에 볼 아키텍처가 이 서로 다른 입도가 어떻게 공존하고 협업하는지를 보여주는 실용적 모형이다.

3

A hierarchical agentic architecture

계층적 아키텍처 — 잘 굴러가는 조직을 닮은 생태계

평평한 도구 목록을 뒤지는 단일 에이전트. 단순한 자동화에는 작동하지만 프로세스가 복잡해지면 확장도 안 되고 명료함도 잃는다. 대안은 잘 운영되는 조직을 닮은, 구조화되고 관찰 가능한 생태계다. 모듈성과 회복력을 위해 설계된 구조다.

꼭대기에는 거친 입도의 오케스트레이터 에이전트가 있다. 이들은 AI 지휘자처럼 기능한다. 모든 작은 단계를 직접 실행하는 것이 아니라, 업무 프로세스 전체를 이해하고 전문 에이전트들의 협업을 설계하고 감독하는 것이 임무다.

오케스트레이터 에이전트 NewCustomerOnboarding_Agent 워크플로 조율 1 · KYC 점검 위임 AgentTool 호출: KYC_Agent 전문 서브에이전트 2 · 신용 평가 위임 AgentTool 호출: CreditCheck_Agent 전문 서브에이전트 3 · 환영 이메일 발송 Tool 호출: send_email_tool 단순·세밀 함수 프로세스 종료

〈그림 3.3〉 오케스트레이터 에이전트 아키텍처. 금색 점선은 위임, 보라 실선은 프로세스 흐름이다.

그림에서 NewCustomerOnboarding_Agent가 오케스트레이터, 곧 AI 지휘자다. 복잡한 KYC 점검은 KYC_Agent에, 신용 평가는 CreditCheck_Agent에 위임한다. 환영 이메일 발송처럼 단순한 원자적 과업은 세밀한 send_email_tool을 직접 호출한다. 각 서브에이전트나 도구가 어떻게 작동하는지 시시콜콜 알 필요 없이 전체 프로세스 흐름에만 집중할 수 있다는 것이 이 구조의 핵심이다.

3.1능력의 스펙트럼 — Tool과 AgentTool

Fine-grained function

Tool — 도구

행동의 가장 기본 단위. 하나의 함수나 API 엔드포인트를 감싼 직접적이고 무상태인 래퍼다. 특정한 원자적 행동 하나를 수행하도록 설계된다. 에이전트가 환경과 상호작용할 때 쓰는 근본적인 동사다.

send_email, query_database, calculate_amortization

쓸 때 — 복잡한 추론이나 다단계 과정이 필요 없는 단순하고 결정론적인 과업에 가장 적합하다. 에이전트가 취할 수 있는 단순하고 믿을 만한 행동이다.

Sophisticated compound agent

AgentTool — 에이전트 도구

훨씬 정교한 능력이다. 결정적으로, AgentTool은 완결적이고 자족적인 세밀 에이전트(서브에이전트)를 도구로 포장해 노출한 것이다. 자체 내부 상태와 다단계 워크플로와 전용 도구 집합을 가질 수 있는 강력한 추상이다.

— 원시 텍스트를 받아 내부적으로 여러 NLP 도구를 써서 처리한 뒤 구조화된 감성 점수를 돌려주는 CustomerSentimentAnalyzer. 데이터셋을 받아 내부 통계 도구로 전체 분석을 수행하고 종합 프로파일을 반환하는 DataProfiler

쓸 때 — 오케스트레이터가 복잡한 다단계 하위 과업을 위임할 때 호출한다. 하위 과업이 어떻게 수행되는지 세부를 몰라도 워크플로를 관리할 수 있다.

3.2계층 구조 — 오케스트레이터와 전문가

이 아키텍처는 의도적으로 평평하지 않다. 통제와 특화의 위계이며, 효과적인 조직 구조를 본떴다. 그래서 모듈성과 감독과 확장성이 커진다.

  • 서브에이전트(세밀한 전문가) — 시스템의 전문 작업자이자 도메인 전문가다. 각자 특정 복합 과업이나 좁은 도메인의 전문가가 되도록 설계되고 적응된 LLMAgent 인스턴스다. AgentTool로 포장되어 전체 시스템에 자기 전문성을 제공한다. 예 — KnowYourCustomer_Agent는 KYC 점검만을 목적으로 하며, 자체 워크플로와 query_identity_database·check_sanctions_list·verify_address_api 같은 단순 도구를 갖는다.
  • 오케스트레이터 에이전트(거친 조율자) — 아키텍처의 관리자이자 프로세스 조정자다. 저수준 과업을 직접 하는 것이 아니라 서브에이전트들을 조율해 종단 간 업무 프로세스를 완성하는 것이 주 책임이다. 그 워크플로는 상위 사업 목표를 직접 반영하도록 설계된다.
  • 도구상자 구성 — 오케스트레이터의 도구상자는 주로 자신이 관리하는 특화 서브에이전트, 곧 AgentTool로 이뤄진다. 최종 알림 발송이나 완료 로깅 같은 단순 과업을 위해 자체 도구를 몇 개 가질 수도 있다.

Separation of concerns

무엇을·언제 / 어떻게 / 무엇으로

오케스트레이터무엇을 언제 — 상위 프로세스 흐름과 조율을 소유한다.
서브에이전트어떻게 — 특화된 복잡한 과업의 전문적 실행을 소유한다.
도구는 어떤 에이전트든 환경과 상호작용할 때 쓰는 가장 기본적이고 원자적인 능력이다.

3.3콜백을 통한 거버넌스와 관찰 가능성

정교한 멀티 에이전트 아키텍처는 우리가 그것을 관리하고 이해할 수 있는 만큼만 좋다. 시스템이 불투명한 블랙박스가 되는 것을 막으려면 견고한 관찰 체계가 필요하다. 예를 들어 고위험 거래 중에 에이전트가 잘못된 매개변수로 도구 호출을 환각하는, 곧 적응이 실패하는 상황을 생각해 보자. 세밀한 추적이 없으면 이것은 조용한 실패로 끝난다. 콜백을 구현하면 그런 이상을 즉시 감지할 가시성을 얻는다.

on_model_start / on_model_end

인지 중추 감시

에이전트의 “뇌”가 LLM을 질의할 때마다 발동해 사고 과정을 들여다보는 창을 준다. 모델에 보낸 정확한 프롬프트, 중간 추론 단계, 최종 응답, 토큰 수와 지연 같은 성능 지표를 기록한다.

규제 준수를 위한 결정 감사, 사용된 맥락을 검사한 환각 진단, 운영 비용 관리에 필수다. 진정한 설명 가능성의 토대가 된다.

on_tool_start / on_tool_end

행동과 상호작용 추적

도구나 AgentTool이 호출될 때마다 발동해 에이전트가 환경에 가한 모든 행동을 기록한다. 어떤 에이전트가 어떤 도구를 불렀는지, 정확한 입력 인자, 반환된 데이터, 발생한 오류를 담은 불변의 감사 추적을 만든다.

보안과 디버깅에 중요하다. 결함이 에이전트의 추론에 있는지 도구 실행에 있는지 짚어낸다. 멀티 에이전트에서는 오케스트레이터에서 서브에이전트로 이어지는 위임의 사슬을 선명히 보여준다.

on_agent_start / on_agent_end

상위 프로세스 감독

개별 에이전트 실행의 생애주기를 처음부터 끝까지 추적한다. 에이전트의 초기 목표, 최종 결과(성공 또는 실패), 총 소요 시간을 기록한다.

이 데이터는 업무 프로세스 모니터링(BPM) 대시보드로 직결되고, 서비스 수준 협약(SLA) 추적과 집행에 필수다. 기술적 성능을 사업 가치에 직접 잇는다.

통합된 콜백 체계가 이 구조의 마지막 조각이다. 멀티 에이전트 생태계를 강력할 뿐 아니라 투명하고 통치 가능하며 진정으로 운영에 준비된 것으로 만든다. 이것은 2장에서 다룬 AgentOps와 거버넌스 원칙을 워크플로에 실제로 계측해 넣는 일이다.

4

The spectrum of adaptation

적응의 스펙트럼 — 네 가지 방법, 네 가지 깊이

이 장의 나머지는 네 가지 기법을 다룬다. 그런데 이 넷을 나란히 늘어놓고 보면 하나의 축이 드러난다. 모델의 가중치를 얼마나 깊이 건드리는가. 그 깊이가 지속성과 비용과 데이터 요구를 함께 결정한다.

← 얕다 · 가역적 · 즉각적 깊다 · 지속적 · 값비싸다 → ICL 문맥 내 학습 IN-CONTEXT LEARNING RAG 검색증강생성 RETRIEVAL-AUGMENTED PEFT 매개변수 효율 미세조정 LoRA · ADAPTER · PREFIX FFT 전체 미세조정 FULL FINE-TUNING 가중치 변경 없음 없음 일부만 전체 지속성 그 프롬프트 한정 추론 시점마다 영구 영구 계산 비용 데이터 요구 예시 몇 개 지식베이스 소~중 규모 대규모 라벨 데이터 그라운딩 — 어느 방법을 쓰든 이것 없이는 신뢰가 서지 않는다

〈도해〉 적응의 스펙트럼. 넷은 배타적이지 않고, 조합해서 쓰는 것이 보통이다.

이제 왼쪽부터가 아니라 실무에서 가장 먼저 손대는 순서로 보자. RAG, 파인튜닝, ICL, 그리고 그 전부를 떠받치는 그라운딩이다.

5

Contextual enhancement with RAG

RAG — 세 개의 대조 실험

1장에서 못 박은 맥락이 왕이다라는 원칙은 에이전트에 이르면 더욱 무거워진다. 에이전트는 잘 알고 결정하고 정확히 행동해야 하는데, 그 능력은 현재적이고 관련성 있고 정확한 정보에 대한 접근에 전적으로 달려 있다.

RAG는 에이전트의 LLM 중추에 필요한 맥락을 필요한 바로 그 시점, 곧 추론 시점에 동적으로 공급하는 기법이다. 정적인 사전학습 지식에만 의존하는 대신, 지정된 외부의 최신 지식원에서 적절한 정보를 능동적으로 가져온다.

말로 하면 추상적이다. 그래서 이 장은 같은 상황을 RAG 없이 한 번, RAG로 한 번 돌려 보이는 대조 실험을 세 번 반복한다. 그 셋을 차례로 보자.

5.1고객지원 에이전트 — 어젯밤의 펌웨어

사용자가 이렇게 말한다.

"어젯밤 업데이트한 뒤로 내 ProWidget X에 Error E404가 떠요."

Without RAG

일반론자의 실패

  1. 사용자 질의 접수
  2. LLM이 사전학습 지식에 접근한다. 흔한 오류 코드나 일반적 문제 해결 절차는 알 수 있다. 그러나 ProWidget XError E404가 새롭거나 최근 업데이트 관련이라면 학습 데이터에 없다.
"Error E404가 발생해 유감입니다. ProWidget X를 재시작해 보세요. 그래도 안 되면 인터넷 연결이 안정적인지 확인해 주세요."

결과 — 알려진 펌웨어 버그가 원인이므로 이 답은 쓸모없다. 사용자는 답답하고, 해결 시간은 늘어나고, 에이전트는 무능하고 뒤떨어져 보인다.

With RAG

전문가의 성공

  1. LLM이 “ProWidget X”, “Error E404”, “업데이트 후”를 특정 정보가 필요한 핵심 개체로 인식한다. RAG가 촉발된다.
  2. 검색 — 제품 매뉴얼과 최근 서비스 공지가 담긴 벡터 DB에 search("ProWidget X Error E404 firmware update June 2025")를 던진다.
  3. 보강 — 서비스 공지 #SB2025-06-26: “6월 25일 펌웨어(v1.2.2) 배포 후 ProWidget X에서 Error E404 발생. 원인: 서버 인증과의 펌웨어 불일치. 해결: v1.2.3 패치로 즉시 업데이트 또는 KB #FW789의 롤백 절차 안내.”
  4. 생성 — 검색된 권위 있는 정보를 종합한다.
"최근 업데이트 후 ProWidget X에 Error E404가 표시되는 상황이시군요. 새 펌웨어와 관련된 알려진 문제입니다. 권장 해결책은 설정 > 업데이트에서 v1.2.3 패치로 업데이트하는 것입니다. 제가 안내해 드릴까요, 아니면 지식베이스에 있는 펌웨어 롤백을 시도해 보시겠습니까?"

결과 — 최신 정보에 근거한 정확하고 실행 가능한 해법을 준다. 해결이 훨씬 빨라지고 만족도가 오르며, 지식베이스 문서를 참조할 수 있다는 사실이 신뢰를 더 쌓는다.

핵심 측면RAG 없는 에이전트RAG 있는 에이전트
지식원정적인 사전학습 데이터동적인 외부 지식베이스(서비스 공지)
에이전트의 통찰특정 오류나 업데이트에 대한 맥락 없음알려진 최근 이슈이며 문서화된 해결책이 있음을 이해
생성 응답일반적 문제 해결(“기기를 재시작하세요”)구체적이고 실행 가능한 해법(“v1.2.3 패치로 업데이트”)
사업적 결과사용자 불만, 지원 시간 증가빠른 해결, 높은 만족도, 신뢰 상승

〈표 3.2〉 에이전틱 경험에서 RAG의 영향

5.2금융 분석 에이전트 — 어제의 실적발표

금융시장에서는 시의성이 극단적으로 중요하다. 시장 심리는 새 정보에 따라 몇 분 만에 뒤집히고, 몇 달 전 학습 데이터에 의존하는 LLM은 심각하게 불리하다. 실적 발표 하나가 회사의 전망과 시장 인식을 하룻밤 사이에 바꿔 놓는다.

"어제 있었던 1분기 실적 발표 이후 CompanyCorp(SMCP)에 대한 현재 시장 심리를 간결하게 요약하라."

Without RAG

시대에 뒤진 일반론자

LLM의 CompanyCorp 지식은 마지막 학습 시점, 어쩌면 몇 달 전에 멈춰 있다. 어제의 실적 수치도, 실시간 시장 반응도, 이후의 애널리스트 논평도 모른다.

"CompanyCorp는 클라우드 솔루션에 주력하는 선도 기술 기업입니다. 역사적으로 실적은 꾸준한 성장을 보여 왔습니다…"

결과 — 현재 시장 심리를 파악하는 데 아무 쓸모가 없다. 시의적절한 투자 판단에 가치를 주지 못하고, 낡은 데이터에 근거한 중대한 전략적 오류로 이어질 수 있다.

With RAG

실시간 전문가

검색 — 여러 연결된 데이터 소스에 질의를 조율한다.

  • 금융 뉴스 API(Bloomberg, Reuters)에 search("CompanyCorp OR SMCP earnings Q1 2025" since:yesterday)
  • 보도자료 DB에서 SMCP의 공식 1분기 실적 발표
  • 주식시장 데이터 API에서 어제 종가 이후의 가격 변동과 거래량

보강 — Reuters: “SMCP 1분기 EPS $1.25로 예상치 $1.10 상회. 매출 전년 대비 15% 증가. 시간외 7% 급등.” / 실적 발표: “순이익 5억 달러, AI 서비스 부문 25% 성장이 견인.” / 시장 데이터: “현재가 $150.00 (+$10.50, 전일 종가 대비 +7.5%).”

"어제 6월 26일 CompanyCorp(SMCP)의 1분기 실적 발표 이후 시장 심리는 강하게 긍정적입니다. EPS $1.25로 애널리스트 예상을 상회했고, 매출은 전년 대비 15% 증가했으며, AI 서비스 부문의 25% 성장이 주로 견인했습니다. 주가는 우호적으로 반응해 전일 종가 대비 7.5% 오른 $150.00에 거래 중입니다."

결과 — 최신 재무 보고와 시장 반응에 명시적으로 접지된, 시의적절하고 실행 가능한 요약을 낸다.

핵심 측면RAG 없는 에이전트RAG 있는 에이전트
지식원정적이고 낡은 학습 데이터실시간 금융 뉴스 API, 보도자료, 시장 데이터 피드
에이전트의 통찰최근 사건을 전혀 모름어제의 실적 수치, 시장 반응, 뉴스를 종합
생성 응답일반적이고 무관한 회사 소개데이터가 풍부하고 시의적절하며 실행 가능한 시장 요약
사업적 결과잘못된 정보에 근거한 결정, 잠재적 금융 손실정보에 근거한 전략 수립과 시의적절한 투자 판단

〈표 3.3〉 금융 분석 에이전트에 대한 RAG의 영향

5.3컴플라이언스 에이전트 — 7만 5천 달러 송금

금융기관에서 컴플라이언스 에이전트의 역할은 결정적이다. 불법 활동을 막고 복잡하게 진화하는 규제 준수를 확보하기 위해 거래를 면밀히 검토한다. 판돈이 매우 크다. 위반은 중대한 제재와 금전 손실과 평판 훼손으로 이어진다. 관할별로 다른 자금세탁방지(AML) 규정, 공개 규제보다 엄격할 수 있는 은행 내부 정책, 끊임없이 갱신되는 국제 제재 목록을 헤쳐 나가야 한다. 이런 일에 범용 LLM의 기본 지식만 믿는 것은 용납할 수 없는 위험이다.

A국의 계좌에서 B국의 John Doe 씨 개인 계좌로 7만 5천 달러 송금.

Without RAG

위험한 일반론자

LLM은 AML 원칙 일반은 알 수 있으나, A국과 B국의 현행 규정, 은행 내부 정책의 세부 뉘앙스, John Doe가 최근 제재 목록에 올랐는지 여부는 알 길이 없다.

"거래 금액이 큽니다($75,000). 수동 검토로 플래그 처리합니다."

결과 — 무해한 거래까지 과도하게 플래그해 비효율을 낳거나, 더 심각하게는 새로 시행된 규정을 놓쳐 규제 위반을 저지른다. 기관을 상당한 법적·금전적 위험에 노출시킨다. “조심해서 나쁠 것 없다”는 태도가 운영 병목을 만들고, 모델이 알지 못하는 규제 위반에 취약한 상태로 남겨 둔다.

With RAG

정밀한 문지기

검색 — 통합된 전문 데이터 소스에 질의한다. 정기 갱신되는 규제 인텔리전스 DB, 은행의 버전 관리되는 정책 문서 저장소, 실시간 제재 스크리닝 API.

보강 — 규제(2025.6.1 시행): “A국발 5만 달러 초과 개인 수취인 대상 해외 송금 중 FATF 비회원국행은 Form XYZ 제출과 강화된 실사 필요.” / 내부 정책(v3.1.2): “B국 개인 계좌로의 2만 5천 달러 초과 송금은 목적 증빙과 2단계 관리자 검토 자동 발동.” / 제재 조회: “John Doe, 1980-01-15, B국 — 활성 제재 일치 없음.”

거래 검토: A국 → B국 John Doe, $75,000 · 제재: 통과. 일치 항목 없음. · 외부 규제: 위반. A국 $50,000 기준 초과 → Form XYZ 및 강화 실사(EDD) 필요. · 내부 정책: 위반. B국 개인 계좌 $25,000 기준 초과 → 목적 증빙 및 2단계 관리자 검토 필수. · 권고: 거래 보류. EDD 착수, Form XYZ 요청, 목적 증빙 확보 후 2단계 검토 큐로 라우팅.

결과 — 정확하고 규정에 부합하며 위험을 인지한 권고를 낸다. 서로 다른 출처에서 온 겹겹의 요건을 식별하고, 올바른 처리와 감사 가능한 결정 이력을 만든다.

핵심 측면RAG 없는 에이전트RAG 있는 에이전트
지식원AML 원칙에 대한 일반적이고 낡은 지식실시간 규제 DB, 버전 관리되는 내부 정책, 제재 스크리닝 API
에이전트의 통찰거래 맥락에 맞는 구체적·현행 규정을 적용하지 못함서로 다른 출처의 겹겹의 준수 의무를 식별하고 교차 참조
생성 응답단순한 조치(검토 플래그)상세하고 다단계이며 감사 가능한 권고
사업적 결과규제 위반과 제재의 높은 위험준수 위험 최소화, 감사 가능한 절차, 운영 효율

〈표 3.4〉 컴플라이언스 에이전트에 대한 RAG의 영향

세 사례가 말하는 것은 하나다. RAG는 더 많은 데이터에 접근하는 문제가 아니다. 에이전트에게 올바른 데이터를 올바른 시점에 주는 문제다.

5.4RAG의 세 층위와 성숙도 모델

RAG 층위설명대응하는 성숙도 단계
바닐라 RAG단일 지식원에서 기본적인 맥락 보강을 하는 단순한 접근Level 2 · 맥락 보강 — RAG의 기초적 적용. 단일 지식베이스의 외부 맥락으로 모델의 기본 한계를 넘는 데 초점
어드밴스드 RAG검색된 맥락의 품질·관련성·신뢰도를 높이는 더 정교한 방법. 흔히 복수의 출처를 쓴다Level 4 · 그라운딩과 평가 — 재순위화, 융합, 출처 인용에 대한 초점이 신뢰할 수 있고 검증 가능하며 잘 접지된 출력의 요구와 정확히 맞는다
에이전틱 RAG자율 에이전트가 검색 과정 자체를 관리하고 조율하는 신흥 패턴. 흔히 협업을 수반한다Level 5–6 · 단일·멀티 에이전트 — 성숙한 에이전틱 아키텍처의 표징. 전문 에이전트들이 협업해 정교한 정보 검색이라는 복잡한 과업을 수행한다

〈표 3.5〉 RAG 스펙트럼과 GenAI 성숙도 모델의 대응

6

Fine-tuning for agentic capabilities

파인튜닝 — 모델 자체를 고쳐 쓴다

파인튜닝은 더 깊고 지속적인 적응 방법이다. 특화 데이터셋으로 추가 학습을 시켜 모델의 내부 매개변수, 곧 가중치를 직접 수정한다. 사용 시점에 외부 정보로 모델을 보강하는 RAG와 달리, 파인튜닝은 모델의 내재적 지식 기반과 기본 응답 성향 자체를 바꾼다. 그래서 특정 과업이나 도메인에 본질적으로 더 능한 모델이 된다.

Objective 01

도메인 특화

법률 조사 에이전트에는 판례 파일, 진단 보조 에이전트에는 의학 저널, 컴플라이언스 에이전트에는 금융 규제 문서. 도메인 특화 말뭉치로 학습하면 용어에 훨씬 유창해지고, 핵심 개체와 그 관계를 더 잘 이해하며, 그 분야에 맞는 출력을 낸다. 에이전트가 자기 운영 환경의 언어를 진짜로 말하게 된다.

Objective 02

과업 특화 기술

특정 언어의 코드 생성, 긴 보고서를 정해진 구조로 요약, 비정형 텍스트에서 개체명 추출, 특정 유형의 대화. 이런 과업의 예시가 다수 담긴 데이터셋으로 학습하면 숙련도와 신뢰성이 크게 오른다.

예컨대 "사용자 요청" → "올바른 API tool_call_json" 쌍으로 학습시키면 외부 도구를 정확한 매개변수로 안정적으로 호출하는 능력이 극적으로 개선된다.

Objective 03

행동 정렬

원하는 대화 스타일을 따르게 한다. 고객 서비스 에이전트는 일관되게 공감적이어야 하고, 기술 지원 에이전트는 극도로 간결하고 직설적이어야 할 수 있다. 복잡한 다단계 지시를 더 충실히 따르게 만들 수도 있다.

기반 모델에 충분히 배어 있지 않은 윤리 지침이나 안전 프로토콜의 준수를 강화하는 데도 쓴다. 예컨대 되돌릴 수 없는 행동을 실행하기 전에는 반드시 명시적 확인을 구하도록 튜닝할 수 있다.

6.1FFT와 PEFT

FFT(전체 미세조정)는 LLM 매개변수의 전부 또는 상당 부분을 갱신한다. PEFT는 LoRA, 어댑터 튜닝, 프롬프트 튜닝처럼 기존 매개변수의 아주 작은 부분집합만 수정하거나 소수의 새 학습 가능 매개변수를 더하고, 원본 모델의 대부분은 얼려 둔다.

에이전트 개발에서는 PEFT가 대체로 유리하다. 계산 효율이 훨씬 높고 작은 데이터셋으로도 좋은 결과를 얻는 경우가 많다. 파국적 망각의 위험을 크게 줄이고, 하나의 기반 LLM에서 여러 특화 에이전트 “인격”이나 기술 집합을 만들고 관리하는 일을 훨씬 실용적으로 만든다.

대가도 있다. 극도로 복잡해 가장 깊은 특화가 필요한 과업이라면 PEFT가 FFT의 절대 성능 상한에는 못 미칠 수 있고, 행동 변화의 폭이 더 제한될 수 있다.

비교 항목FFTPEFT
특화의 깊이높음. 특정 도메인·과업·행동에 깊은 적응이 가능하다.중간~높음. 많은 특화 요구에 효과적이지만, 극히 복잡하거나 새로운 과업에서는 FFT보다 얕을 수 있다.
계산 비용(학습)매우 높음. 상당한 GPU/TPU 자원과 시간이 든다.낮음~중간. FFT보다 훨씬 덜 자원 집약적이다.
데이터셋 규모큼. 대체로 대량의 고품질 과업별 라벨 데이터가 필요하다.작음~중간. 작은 데이터셋으로도 좋은 결과를 내는 경우가 많다.
파국적 망각 위험더 높음. 모든 가중치를 갱신하면 일반 능력의 일부를 잃을 수 있다.더 낮음. 기반 모델 매개변수 대부분을 얼려 두므로 일반 지식이 보존된다.
다중 에이전트 시 자원 부담높음. 완전 미세조정된 대형 모델을 여럿 저장하고 서빙하는 일은 비싸고 복잡하다.낮음. 여러 PEFT 적응(예: LoRA 층)이 같은 기반 모델을 공유할 수 있어 부담이 급감한다.
기반 가중치에 대한 영향전부 또는 대부분이 수정된다.가중치의 아주 작은 일부만 수정되거나, 어댑터·LoRA 행렬 같은 소수의 새 매개변수 집합만 학습된다.
구현·반복 용이성반복과 실험이 더 복잡하고 오래 걸린다.자원 요구가 낮아 다양한 적응을 더 빠르고 쉽게 실험할 수 있다.
에이전트의 전형적 용례PEFT가 효과적으로 담아내지 못하는, 깊은 도메인 전문성이나 고도로 특화된 행동 특성이 필요한 에이전트공통 기반 LLM에서 다양한 특화 에이전트(기술·역할·소통 방식이 다른)를 만드는 경우. 자원 제약 환경의 에이전트
주된 이점주어진 과업·도메인에서 최대 성능과 가장 깊은 특화의 가능성효율, 다중 특화의 확장성, 일반 능력의 보존
주된 단점높은 비용, 자원 집약적, 일반 지식 상실 위험일부 까다롭거나 미묘한 특화에서 FFT의 최고 성능에 도달하지 못할 수 있음
대표 기법해당 없음(대부분·전체 층을 재학습)LoRA, 어댑터 튜닝, 접두 튜닝, 프롬프트 튜닝

〈표 3.6〉 에이전트 준비된 LLM을 위한 FFT와 PEFT 비교

6.2학습 데이터의 두 성격

Unsupervised

비지도 미세조정 — 도메인 적응 사전학습

대상 도메인의 라벨 없는 대규모 말뭉치로 모델의 사전학습 단계를 이어간다. 그 도메인의 어휘, 문체적 뉘앙스, 일반적 배경지식을 철저히 익히게 한다. 에이전트로서는 자기 전문 운영 환경 안의 정보를 더 잘 이해하고 처리하게 된다는 뜻이다.

Supervised

지도 미세조정(SFT)

엄선된 라벨 있는 예시로 학습한다. 대개 지시와 원하는 응답, 질문과 정답 같은 입출력 쌍이다. 특정 과업, 다양한 지시를 정확히 따르는 법, 정확한 형식으로 출력하는 법을 가르치는 데 결정적이다. 에이전트가 특정 행동을 올바르게 수행하거나 설계된 페르소나에 맞게 소통하도록 가르치는 열쇠다.

많은 에이전틱 응용에서, 특히 여러 특화 에이전트를 개발하거나 막대한 재학습 비용 없이 진화하는 과업에 적응시켜야 할 때 PEFT는 특화와 효율의 설득력 있는 균형점이다. 그러나 절대적으로 가장 높은 수준의 특화가 필요하고 그 비용이 정당화된다면 FFT도 여전히 유효한 선택지다.

7

In-context learning

ICL — 가중치를 건드리지 않고 배우게 하는 법

파인튜닝이 깊고 지속적인 특화를 준다면, ICL은 즉각적인 적응을 준다. 현재 프롬프트나 대화 안에 주어진 정보와 예시만으로 새 과업을 배우거나 응답을 바꾸게 하는 것이다. 결정적으로 모델의 가중치나 매개변수는 전혀 바뀌지 않는다.

기본 기제는 단순하다. 프롬프트 안에 예시를 직접 보여준다. 몇 개만 넣는 few-shot일 수도 있고, 컨텍스트 창이 큰 모델이라면 아주 많이 넣는 many-shot일 수도 있다. LLM은 이 맥락 단서에서 밑에 깔린 패턴을 추론해, 새로 마주하는 비슷한 입력에 적용한다.

// 에이전트의 제어 로직이 동적으로 구성하는 프롬프트의 개념 구조 System: You are a specialized assistant for [Task Domain] Example 1 input: 특정 유형의 사용자 질의 또는 환경 데이터 Example 1 output: 그 입력에 대해 에이전트가 내야 할 응답 또는 행동 Example 2 input: 또 다른 유형의 질의 또는 데이터 Example 2 output: 그에 대한 응답 또는 행동 Current situation input: 에이전트가 지금 처리해야 할 새 질의 또는 환경 데이터 Agent's LLM output: 주어진 예시와 일관된 응답·행동을 생성하려 시도
용례·이점상황ICL을 쓴 접근에이전트의 내적 “사고”
임시 요구에 대한 과업 시연 미세조정된 적 없는 새로운 임시 형식으로 출력해야 한다(예: 비정형 텍스트에서 3단 구성 보고서). 원하는 입력→출력 변환을 보여주는 예시 몇 개를 포함한 프롬프트를 구성한다. “이 요청은 새로운 출력 형식을 요구한다. 이번 건에 대해 LLM의 생성을 안내할 예시를 넣어 프롬프트를 구성하겠다.”
동적 문체 적응 대화 단서에서 사용자의 불만을 감지하고, 표준적인 사실 위주 어조가 상황을 악화시킬 수 있다고 판단한다. 공감적이거나 안심시키는 응답의 예시를 LLM의 맥락에 동적으로 덧붙여 대화의 어조를 이끈다. “사용자의 감정이 부정적이다. 소통 방식을 조정해야 한다. 다음 답을 생성하기 전에 공감적 응답 예시를 맥락에 추가하겠다.”
예상 밖 상황의 도구 사용 명확화 드물거나 복잡한 매개변수 조합으로 도구·API를 호출해야 해 형식 오류 위험이 크다. 유사한 복잡 도구 호출의 성공 사례 하나를 완전한 형태로 프롬프트에 넣은 뒤 새 호출의 형식을 만들게 한다. “이 호출은 복잡하고 선택 매개변수가 여럿이다. 비슷한 성공 사례를 가져와 프롬프트에 넣어 LLM이 이번 요청을 정확히 구성하도록 하겠다.”

〈표 3.7〉 동적 에이전트 적응을 위한 ICL의 실용적 적용

7.1ICL이 특히 강한 세 가지 상황

01

새롭고 변화하는 과업

전혀 새롭거나 빠르게 바뀌는 과업 앞에서 ICL은 빠르고 자원 효율적인 안내 수단이다. 일시적이거나 일회적일 수 있는 상황에 재학습의 지연과 비용을 치르지 않아도 된다. 문서가 거의 없는 새 기능이 출시됐을 때, 기능 노트와 질의응답 예시 두어 개를 프롬프트에 직접 넣어 초기 문의를 처리하는 식이다.

02

세션 중 선호 변화

여행을 계획하던 개인 비서 에이전트가 처음에는 다구간 상세 일정을 제안했다고 하자. 사용자가 “이번 여행은 그냥 후보 목적지 목록과 각각의 대표 명소 하나씩만, 이런 식으로”라며 짧은 예시를 주면, 에이전트는 그 맥락 예시를 써서 같은 대화 안에서 즉시 출력 스타일을 바꾼다.

03

고도로 조건부인 행동

최적 행동이 빠르게 변하는 다수의 변수에 달려 있을 때, 관련성 높은 현재 예시 몇 개를 프롬프트에 주는 편이 모든 경우를 상정해 미세조정하려는 시도보다 민첩하다. 장소와 인원에 따라 허용 활동과 수용 한도가 달라지는 행사 기획 자문 에이전트가 그런 예다.

7.2종단 예시 — AstroZoom 망원경 리뷰

전자상거래 제품 리뷰를 분석하는 에이전트를 보자. 핵심 과업은 리뷰 전체의 감성이 아니라 개별 기능별 감성을 뽑아내는 것이다. 제품 개발팀에는 이 세밀한 피드백이 대단히 값지다. 새 리뷰가 들어왔다.

"AstroZoom의 배율은 놀랍습니다. 토성 고리가 선명하게 보여요! 그런데 삼각대는 좀 흔들리고 싸구려 느낌이 납니다."

Step 1 · Without ICL

쓸 만하지만 쓸 수 없는 출력

전체 감성: 혼합. 배율과 토성 관측에 대한 긍정적 언급. 흔들리고 싸구려 같은 삼각대에 대한 부정적 언급.

완전히 틀린 것은 아니다. 그러나 데이터 집계에 쓸 만큼 구조화되어 있지 않고, 기계가 읽을 수 있는 형태로 기능과 그에 대한 감성을 분리하지 못한다. 제품팀이 알아야 할 것은 어떤 기능이 어떤 감성이었는가다.

Step 2 · With ICL

예시 세 개를 넣은 뒤

에이전트의 제어 로직이 few-shot 예시를 담은 프롬프트를 동적으로 조립한다. 시스템 지시로 “리뷰에서 핵심 제품 기능과 각 기능에 대한 감성을 식별해 feature·sentiment 키를 가진 JSON 객체 목록으로 출력하라”고 명시하고, 스마트워치·휴대폰·전자책 리더 리뷰의 입출력 예시를 붙인다.

[ {"feature": "magnification (AstroZoom)", "sentiment": "Positive"}, {"feature": "clarity (seeing Saturn's rings)", "sentiment": "Positive"}, {"feature": "tripod (wobbliness)", "sentiment": "Negative"}, {"feature": "tripod (feel/build quality)", "sentiment": "Negative"} ]

결과 — 가중치를 전혀 바꾸지 않고도 미묘한 분석을 수행해 구조화된 유용한 출력을 냈다. 이 상호작용에 한해 에이전트는 예시에서 과업을 “배웠다”. 제품팀은 이 JSON을 그대로 DB에 넣어 기능별 피드백을 추적할 수 있다.

ICL의 효능은 사용하는 LLM의 고유 능력, 특히 적은 예시에서 일반화하는 능력과 컨텍스트 창의 크기에 크게 좌우된다. 창이 클수록 더 포괄적이고 많은 예시를 담을 수 있고, 대체로 더 견고하고 정확한 학습이 된다.

ICL은 파인튜닝이 주는 깊고 지속적인 특화를 주지는 못한다. 그러나 에이전트에게 유연성과 즉각적 대응이라는 결정적 층위를 더한다. RAG와 파인튜닝 양쪽을 보완하는 가치 있는 수단이다.

8

Grounding the model output

그라운딩 — 어느 방법을 쓰든 마지막에 남는 문제

RAG로 적응시키든, 파인튜닝으로 적응시키든, ICL로 적응시키든 마지막에 반드시 남는 실무가 하나 있다. 그라운딩이다. 모델의 출력을 검증 가능한 정보원에 체계적으로 연결하는 과정이다.

에이전트에게 이것은 모범 사례를 넘어선 필수 요건이다. 에이전트의 출력은 흔히 실제 세계의 행동을 촉발하거나 고위험 결정에 근거를 제공하기 때문이다. 사실 정확성의 실패는 사용자의 불만에서 운영적·금전적 파장까지 중대한 결과로 이어진다.

그라운딩 기법설명과 목적에이전트 적용 예
출처 인용과 귀속 제시하는 정보, 특히 RAG로 검색한 정보에 대해 원자료로 되돌아가는 명확한 참조를 제공한다. 투명성을 높이고, 사용자나 감사자가 정보를 검증할 수 있게 하며, 신뢰와 책임성을 세운다. 인사 에이전트가 육아휴직 정책 문의에 답한 뒤, 참조한 사내 정책 문서의 해당 절로 가는 직접 링크를 제공한다.
사실 검증과 교차 참조 중요한 정보, 특히 검색된 출처를 그대로 인용한 것이 아니라 LLM이 내부적으로 생성한 것이라면, 행동하거나 제시하기 전에 신뢰할 수 있는 지식베이스·데이터베이스·권위 있는 출처와 프로그램적으로 교차 대조한다. 일부 아키텍처는 전용 사실 확인 도구나 서브에이전트를 둔다. 영업 보조 에이전트가 LLM이 제안한 복잡한 주문 구성을 확정하기 전에, 내부 제품 DB와 대조해 부품 호환성을 교차 검증한다.
신뢰도 점수 활용 LLM이 자기 주장이나 예측에 대해 제공하는 신뢰도 점수를 해석하고 그에 따라 행동한다. 점수에 따라 그대로 진행하거나, 불확실성을 표명하거나, 다른 출처에서 추가 검증을 구하거나, 사람 전문가에게 에스컬레이션한다. 기술 분야 진단 보조 에이전트가 LLM 중추의 결함 진단 신뢰도가 낮으면(예: 70% 미만) 그 진단을 선임 기술자의 필수 검토 대상으로 플래그한다.
선제적 모호성 해소 응답을 생성하거나 계획을 세우기 전에, 사용자 질의·지시·환경 상태에 대한 자기 이해가 정확하고 모호하지 않은지 확인한다. 입력이 애매하거나 여러 해석이 가능하면 명료화 질문을 한다. 여행 계획 에이전트가 “곧 스프링필드행 항공편을 예약해 줘”라는 말에 “어느 스프링필드를 말씀하시는지, 그리고 ‘곧’은 어느 날짜를 고려하시는지 알려 주시겠습니까?”라고 되묻고 진행한다.

〈표 3.8〉 에이전틱 시스템을 위한 핵심 그라운딩 기법

Why it matters

선제적 모호성 해소가 특히 중요하다

자기 해석을 먼저 접지시키는 이 일은 오해한 전제 위에서 행동할 때 줄줄이 따라오는 하류 오류의 연쇄를 막아 준다. 틀린 답을 고치는 것보다 틀린 질문을 바로잡는 편이 언제나 싸다.

그라운딩은 기술적 절차이기 이전에 책임 있고 신뢰할 만한 AI 에이전트를 짓는 주춧돌이다. 에이전트가 자율적이 될수록 그 행동과 소통이 검증 가능한 현실에 뿌리내리도록 붙잡아 준다. RAG는 출력을 검색 문서에 연결함으로써 본래적으로 그라운딩을 지원하고, 파인튜닝도 특정 도메인 안에서 모델이 더 사실을 의식하도록 학습시켜 기여할 수 있다. 그리고 이것이 1장 성숙도 모델의 Level 4 — 그라운딩과 평가 단계의 근거다.