AI 에이전트를 더 똑똑하게 만드는 Context Engineering 프레임워크
한줄 요약
LLM 에이전트가 실수하는 패턴을 과거 기록에서 배워서, 실행 중에 “더 나은 힌트”를 프롬프트로 넣어주는 시스템.
배경: 왜 이 연구가 필요한가?
기업용 AI 에이전트의 현실
ChatGPT 같은 LLM을 기업 업무에 투입하면, 생각보다 잘 안 된다. 왜일까?
| 문제 | 비유 |
|---|---|
| 데이터가 적다 | 요리책 없이 레시피를 만들어야 하는 셰프 |
| 업무가 복잡하다 | 한 번에 답이 아니라 여러 단계를 거쳐야 함 |
| 연습이 어렵다 | 실제 서버를 고장내면서 연습할 수 없음 |
| 점수를 매기기 어렵다 | ”이 진단이 얼마나 좋았는지” 자동으로 판단하기 어려움 |
기존 해결책의 한계
보통 AI를 개선하려면 파인튜닝(fine-tuning) — 모델 자체를 재훈련 — 을 한다. 하지만 기업 환경에서는:
- 훈련 데이터가 부족하고
- 모델을 직접 수정할 권한이 없을 수도 있고 (API로만 접근)
- 재훈련 비용이 크다
용어 정리
- LLM (Large Language Model): ChatGPT, Gemini 같은 거대 언어 모델
- 파인튜닝 (Fine-tuning): 이미 만들어진 AI 모델을 특정 업무에 맞게 추가 훈련하는 것
- 프롬프트 (Prompt): AI에게 주는 입력 텍스트. “질문”뿐 아니라 배경 정보, 지시사항 등 모든 입력을 포함
이 논문의 핵심 발상
모델을 바꾸지 말고, 모델에게 주는 정보를 바꾸자.
비유하면: 시험을 못 보는 학생이 있을 때,
- 파인튜닝 = 학생의 뇌를 업그레이드 (비싸고 어려움)
- Context Engineering = 더 좋은 참고자료를 시험지 옆에 놓아주기 ← 이 논문의 접근
그런데 “어떤 참고자료를 언제 보여줄지”를 사람이 일일이 정하면 한계가 있으니, 과거 시험 기록을 분석해서 자동으로 최적의 참고자료를 골라주는 시스템을 만든 것이다.
방법론: 세 가지 핵심 구성요소
이 프레임워크는 세 단계를 거친다:
flowchart LR subgraph 1단계["1단계: 지도 그리기"] A["과거 작업 기록<br/>(trajectory)"] --> B["단순화된 게임판<br/>(DT-MDP)"] end subgraph 2단계["2단계: 점수 매기기"] B --> C["좋은 행동 vs 나쁜 행동<br/>점수 학습 (IRL)"] C --> D["최적 전략 학습<br/>(RL Policy)"] end subgraph 3단계["3단계: 실전 도우미"] D --> E["프롬프트에<br/>힌트 삽입 (CE)"] E --> F["AI 에이전트<br/>성능 향상!"] end style 1단계 fill:#e8f4f8,stroke:#2196F3 style 2단계 fill:#fff3e0,stroke:#FF9800 style 3단계 fill:#e8f5e9,stroke:#4CAF50
1단계: Digital-Twin MDP — “복잡한 현실을 게임판으로 바꾸기”
문제
LLM 에이전트가 IT 시스템 장애를 진단할 때, 매 순간 할 수 있는 선택지가 사실상 무한하다 (어떤 서버를 볼지, 어떤 명령어를 실행할지, 어떤 로그를 확인할지…). 이 상태로는 “어떤 전략이 좋은지” 수학적으로 분석하기 어렵다.
해결: 추상화
현실의 복잡한 상황을 핵심만 남긴 단순한 게임판으로 변환한다.
비유: 실제 서울 지하철 노선도 vs 간략화된 노선 지도
| 실제 (POMDP) | 추상화된 게임판 (DT-MDP) |
|---|---|
| AI가 보는 텍스트 전체 | 핵심 정보만 추출한 벡터 |
| 무한한 행동 가능성 | 유한한 선택지로 정리 |
| 숨겨진 정보가 많음 | 보이는 것만으로 판단 |
구체적으로, 두 가지 변환 함수를 사용한다:
- ω⁻¹: 관찰(observation) → 상태(state)로 변환. “AI가 지금까지 본 모든 텍스트”를 “현재 상황 요약”으로 압축
- θ⁻¹: 생각(thought) → 행동(action)으로 변환. “AI의 긴 추론 텍스트”를 “어떤 서버를 조사하기로 했는지”로 압축
용어 정리
- MDP (Markov Decision Process): 순차적 의사결정을 수학적으로 모델링하는 프레임워크. “상태→행동→보상→다음 상태”의 반복
- POMDP: 상태가 완전히 보이지 않는 MDP. 현실 세계의 대부분의 문제가 이에 해당
- Digital Twin (디지털 트윈): 현실 시스템의 가상 복제본. 여기서는 LLM 에이전트의 추론 과정을 모방한 단순화된 모델을 의미
- Trajectory (궤적): AI 에이전트가 문제를 풀면서 거친 “상태→행동→결과”의 전체 기록
세 가지 상태 표현 방식
같은 상황을 얼마나 자세히 게임판에 담을지에 따라 세 가지 버전을 실험했다:
| 표현 방식 | 설명 | 비유 |
|---|---|---|
| Name | 서버 이름만 기록 | 사람 이름만 아는 것 |
| Name-type | 서버 이름 + 유형(DB, 웹서버 등) | 이름 + 직업을 아는 것 |
| Topology | 서버 간 연결 관계(거리) | 조직도까지 아는 것 |
결과적으로 Topology가 가장 좋았고, Name만으로는 부족했다.
2단계: Contrastive IRL — “좋은 행동에 점수 매기기”
문제
AI가 과거에 장애를 진단한 기록이 있는데, 어떤 건 성공했고 어떤 건 실패했다. 그런데 “매 순간의 행동이 얼마나 좋았는지”에 대한 점수가 없다. 최종 성공/실패만 알 뿐이다.
해결: T-REX (비교 학습)
“이 진단 과정이 저 진단 과정보다 낫다”는 순위 비교만으로 보상 함수(reward function)를 학습한다.
비유: 와인 소믈리에 훈련
- ❌ “이 와인은 정확히 87.3점이다” (절대 점수가 필요 없음)
- ✅ “이 와인이 저 와인보다 낫다” (상대 비교만으로 학습)
좋은 진단 기록 ≻ 나쁜 진단 기록
↓
신경망이 "왜 좋았는지"의 패턴을 학습
↓
매 순간 행동에 점수를 매길 수 있게 됨
학습된 보상 함수로 CQL (Conservative Q-Learning) 이라는 오프라인 RL 알고리즘을 적용해서 최적 전략(policy)을 학습한다.
용어 정리
- IRL (Inverse Reinforcement Learning, 역강화학습): 보상 함수를 직접 설계하는 대신, 행동 기록에서 역으로 “이 행동이 왜 좋았는지”를 추론하는 기법
- Contrastive (대조적): “좋은 것 vs 나쁜 것”을 비교하며 학습하는 방식
- T-REX: Trajectory-ranked Reward EXtrapolation. 궤적들의 순위만으로 보상 함수를 학습하는 알고리즘
- CQL: 실제로 해보지 않은 행동에 대해 지나치게 낙관적으로 평가하지 않도록 보수적으로 학습하는 RL 알고리즘
- OPE (Off-Policy Evaluation): 학습한 전략을 실제 실행 없이 과거 데이터로 평가하는 방법
3단계: Context Engineering — “실전에서 AI에게 힌트 주기”
학습된 RL 정책이 “지금 이 상황에서 어떤 행동이 좋은지” 알고 있으니, 이를 프롬프트 수정으로 AI에게 전달한다. 세 가지 전략이 있다:
| 전략 | 이름 | 비유 | 작동 방식 |
|---|---|---|---|
| I | Suggesting | 선생님이 “이것도 봐봐” 힌트 주기 | RL이 높은 점수를 준 행동을 프롬프트에 추천으로 추가 |
| II | Pruning | 오답 선택지 지우기 | RL이 낮은 점수를 준 행동을 후보에서 제거 |
| III | Prioritizing | 중요한 순서대로 배열해주기 | 후보 행동들을 RL 점수 순으로 재정렬 |
비유로 이해하기: 객관식 시험을 보는 학생(LLM)에게
| 전략 | 학생에게 하는 행동 |
|---|---|
| Suggesting | ”3번도 한번 고려해봐” |
| Pruning | ”1번은 확실히 아니야” (선택지 삭제) |
| Prioritizing | 선택지를 유망한 순서대로 재배열 |
용어 정리
- Context Engineering: AI에게 주는 입력(context)을 체계적으로 설계·최적화하는 기법. 프롬프트 엔지니어링의 확장 개념
- Inference-time intervention: 모델을 재훈련하지 않고, 실행 시점에 입력만 조작해서 성능을 개선하는 접근
사례 연구: SRE 진단
SRE가 뭔가요?
SRE (Site Reliability Engineering) = 웹서비스가 잘 돌아가도록 관리하는 엔지니어. 서버가 고장 나면 원인을 찾아 고치는 사람이다.
비유: 대형 병원의 응급실 의사
- 환자(서버)가 들어오면 증상을 확인하고
- 여러 검사를 순서대로 진행하며
- 근본 원인(root cause)을 찾아 치료한다
이 논문은 “AI가 SRE 역할을 할 때” DT-MDP-CE로 성능을 높일 수 있는지 실험했다.
적용된 AI 에이전트 2종
| 에이전트 | 특징 | 비유 |
|---|---|---|
| EoG (Explanations over Graphs) | SRE 전용 설계, 시스템 구조(topology) 활용 | 전문의 — 해당 분야 전문 도구 사용 |
| ReACT | 범용 추론 에이전트, 생각→행동 반복 | 일반의 — 범용적으로 문제 해결 |
용어 정리
- ITBench: IBM이 만든 IT 자동화 벤치마크. 실제 기업 환경과 유사한 장애 시나리오 제공
- Root Cause (근본 원인): 장애를 일으킨 최초의 원인. 증상이 아니라 원인을 찾는 것이 SRE의 핵심
실험 결과
핵심 결과 요약
flowchart TD R1["결과 1: DT-MDP-CE가 모든 설정에서<br/>기본 에이전트보다 성능 향상"] R2["결과 2: Topology ≈ Name-type > Name<br/>(관계 정보가 중요!)"] R3["결과 3: IRL로 학습한 보상 > 단순 성공/실패 보상<br/>(세밀한 피드백이 더 효과적)"] R4["결과 4: Strategy III (Prioritizing)이<br/>단독으로 가장 효과적"] R5["결과 5: 중간 크기 모델에서<br/>가장 큰 개선 효과"] R1 --- R2 --- R3 --- R4 --- R5 style R1 fill:#e8f5e9,stroke:#4CAF50 style R2 fill:#e3f2fd,stroke:#2196F3 style R3 fill:#fff3e0,stroke:#FF9800 style R4 fill:#fce4ec,stroke:#E91E63 style R5 fill:#f3e5f5,stroke:#9C27B0
상세 해석
1. 모든 설정에서 기본보다 우수
6개 온라인 시나리오에서 DT-MDP-CE를 적용한 에이전트가 적용하지 않은 에이전트보다 일관되게 높은 성능을 보였다. 평가 지표는 Pass@3 Recall (3번 시도 중 정답을 찾은 비율)과 Pass@3 F1.
2. 상태 표현이 중요하다
- Name만으로는 부족: 서버 이름만 알면 새로운 서버가 나타났을 때 대응 불가
- Topology/Name-type이 비슷하게 좋음: 흥미롭게도, 서버 유형 정보만 추가해도 구조 정보를 쓴 것과 비슷한 성능. 이는 EoG 에이전트가 유형 정보에서 구조를 어느 정도 유추할 수 있기 때문
3. IRL의 가치
| 보상 학습 방법 | 성능 | 설명 |
|---|---|---|
| RL-IRL (대조 학습) | 🥇 최고 | 매 단계별 세밀한 보상 |
| RL-Sparse (성공/실패만) | 🥈 | 최종 결과만으로 학습 |
| BC (행동 복제) | 🥉 | 좋은 행동을 그대로 따라하기 |
→ “좋은 행동이 왜 좋은지”를 이해하는 것(IRL)이 단순히 따라하는 것(BC)보다 효과적
4. 모델 크기별 효과
| 모델 크기 | 개선 효과 | 이유 |
|---|---|---|
| Small | 작음 | 힌트를 활용할 능력 자체가 부족 |
| Medium | 최대 | 능력은 있지만 방향이 필요한 단계 |
| Large | 보통 | 이미 스스로 잘 해서 힌트의 추가 가치가 적음 |
비유: 운전 내비게이션의 효과
- 초보 운전자 → 내비를 봐도 조작 자체가 서툴러서 효과 제한적
- 중급 운전자 → 내비가 있으면 훨씬 효율적으로 이동 ← 최대 효과
- 베테랑 운전자 → 이미 길을 잘 알아서 내비 효과가 작음
용어 정리
- Pass@3: 3번 시도 중 1번이라도 정답을 맞히면 성공으로 치는 평가 방식
- F1 Score: 정밀도(precision)와 재현율(recall)의 조화평균. “맞다고 한 것 중 진짜 맞은 비율”과 “맞는 것 중 찾아낸 비율”의 균형
- Behavior Cloning (BC): 전문가의 행동을 그대로 모방하는 가장 단순한 모방 학습
관련 연구 & 결론
이 연구의 위치
flowchart TD subgraph 기존접근["기존 접근법들"] FT["파인튜닝<br/>(모델 수정)"] PE["프롬프트 엔지니어링<br/>(수동 설계)"] RL_direct["RL 직접 적용<br/>(텍스트 공간에서)"] end subgraph 이논문["이 논문의 위치"] CE["DT-MDP-CE<br/>추상 공간에서 RL 학습 →<br/>프롬프트로 전달"] end FT -->|"모델 수정 불가 시<br/>사용 불가"| CE PE -->|"자동화하고 싶다"| CE RL_direct -->|"텍스트 공간이<br/>너무 크다"| CE style 이논문 fill:#e8f5e9,stroke:#4CAF50 style 기존접근 fill:#f5f5f5,stroke:#9E9E9E
핵심 차별점
- 파인튜닝과 달리 모델 자체를 수정하지 않음 → API로만 접근 가능한 모델에도 적용 가능
- 수동 프롬프트 엔지니어링과 달리 데이터 기반으로 자동화
- 직접 RL과 달리 추상화된 작은 공간에서 학습 → 적은 데이터로도 가능
논문의 결론
- Context Engineering을 RL로 자동화하는 것이 실용적으로 유효함
- 에이전트 종류(EoG, ReACT)에 관계없이 적용 가능한 범용 프레임워크
- 향후 SRE 외의 기업 업무(헬스케어, 금융 등)로 확장 가능성 제시
전체 흐름 한눈에 보기
flowchart TB subgraph offline["🔧 오프라인 학습 단계 (한 번만 수행)"] direction TB T["과거 AI 에이전트의<br/>작업 기록 수집<br/>(성공+실패 모두)"] T --> ABS["DT-MDP로 추상화<br/>'복잡한 현실 → 단순한 게임판'"] ABS --> RANK["궤적 품질 순위 매기기<br/>(LLM judge 활용)"] RANK --> IRL["Contrastive IRL<br/>'왜 좋았는지' 보상 함수 학습"] IRL --> RL["CQL로 최적 전략 학습<br/>'이 상황에서 뭘 해야 하는지'"] RL --> OPE["OPE로 최고 정책 선별<br/>'실행 없이 시뮬레이션 평가'"] end subgraph online["🚀 온라인 실행 단계 (매번 수행)"] direction TB STATE["현재 상황을 추상 상태로 변환"] STATE --> SCORE["RL 정책이 각 행동에 점수 부여"] SCORE --> CE["Context Engineering 전략 적용<br/>• 추천 (Suggesting)<br/>• 제거 (Pruning)<br/>• 재정렬 (Prioritizing)"] CE --> PROMPT["수정된 프롬프트를<br/>LLM 에이전트에 전달"] PROMPT --> BETTER["향상된 의사결정!"] end offline --> online style offline fill:#fff8e1,stroke:#FFC107 style online fill:#e8f5e9,stroke:#4CAF50
요약 테이블
| 항목 | 내용 |
|---|---|
| 무엇을 | LLM 에이전트의 실행 중 성능 개선 |
| 어떻게 | 과거 기록 → 추상화(DT-MDP) → 보상 학습(IRL) → 전략 학습(RL) → 프롬프트 개입(CE) |
| 왜 | 모델 재훈련 없이, 적은 데이터로, API 모델에도 적용 가능한 방법이 필요 |
| 어디서 | IT 장애 진단(SRE) 사례로 검증 |
| 결과 | 모든 설정에서 기본 에이전트 대비 성능 향상, 특히 중간 크기 모델에서 효과 극대화 |
| 한계 | 실험 규모가 작고(6개 시나리오), 다른 최신 기법(DSPy, ACE)과 비교 부재 |
더 깊이 알고 싶다면
- 비판적 리뷰: Review-DT-MDP-CE — 4명의 전문 리뷰어 관점에서의 상세 평가
- 원문:
pdfs/A Context Engineering Framework for Improving Enterprise AI Agents based on Digital-Twin MDP.pdf