컨텍스트 엔지니어링 (Context Engineering for AI Agents)¶
개요¶
컨텍스트 엔지니어링은 신뢰할 수 있고 효과적인 AI 에이전트를 구축하기 위한 중요한 실행입니다. 2026년 현재, Claude 4.6, GPT-5.4, Gemini 2.5 Pro 같은 최신 모델들이 향상된 컨텍스트 관리 능력을 제공합니다.
이는 단순한 프롬프트 엔지니어링을 넘어서는 개념입니다. 컨텍스트 엔지니어링은 AI 에이전트의 행동을 형성하고 원하는 결과를 달성하기 위해 에이전트에 제공되는 프롬프트, 지시사항, 제약 조건을 신중하게 만들고 정제하는 것을 포함합니다.
컨텍스트 엔지니어링이란?¶
정의¶
컨텍스트 엔지니어링은 AI 에이전트의 행동을 형성하고 작업 성능을 개선하기 위해 제공되는 컨텍스트 정보를 설계, 테스트, 반복하는 프로세스입니다.
프롬프트 엔지니어링과의 차이¶
| 측면 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 범위 | 단일 LLM 호출 | 다단계 에이전트 시스템 |
| 포커스 | 질문의 형태 | 에이전트의 전체 맥락 |
| 개입 | 사용자 입력만 | 시스템 설계, 제약, 메모리 |
| 기간 | 일회성 | 지속적 모니터링 및 개선 |
| 복잡도 | 낮음 | 높음 |
에이전트 컨텍스트의 구성 요소¶
에이전트를 위한 컨텍스트 엔지니어링은 다음을 포함합니다:
┌──────────────────────────────────────────┐
│ 시스템 프롬프트 (System Prompt) │
│ 에이전트의 역할, 목표, 성격 정의 │
└──────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│작업 제약 │ │도구 설명 │ │메모리 │
│(Tasks) │ │(Tools) │ │(Memory) │
└──────────┘ └──────────┘ └──────────┘
│ │ │
└───────────────┼───────────────┘
│
┌───────────▼───────────┐
│ 오류 처리 │
│ (Error Handling) │
└──────────────────────┘
컨텍스트 엔지니어링의 핵심 요소¶
1. 시스템 프롬프트 (System Prompt)¶
에이전트의 기본 성격과 역할을 정의합니다.
나쁜 예¶
좋은 예¶
"당신은 한국 대학의 학생상담 에이전트입니다.
역할:
- 학생의 학사 관련 질문에 친절하게 답변
- 학사 규정과 정책을 정확히 설명
- 필요한 경우 학생을 적절한 부서로 연결
성격:
- 친근하고 존중하는 태도
- 명확하고 이해하기 쉬운 설명
- 학생의 관점에서 생각
제약:
- 항상 대학 정책을 따름
- 의료적 조언은 제공하지 않음
- 부정확한 정보는 'XXX에 문의하세요'로 답변"
2. 작업 제약 (Task Constraints)¶
의사결정을 안내하는 경계와 규칙입니다.
예: 자동 보고서 작성 에이전트¶
작업 제약:
1. 정보 수집 규칙
- 최소 3개의 신뢰할 수 있는 출처에서 정보 수집
- 1주일 이상 된 정보는 새로 조회
- 내부 DB의 정보를 최우선으로 사용
2. 분석 규칙
- 모든 주장에 근거 제시 필요
- 예측은 명확하게 확률 표시
- 한계와 가정을 명시
3. 품질 규칙
- 최소 5개의 섹션 포함
- 한글 맞춤법 검사 필수
- 그래프/표 최소 2개 이상
4. 최종 검증
- 모든 수치 재확인
- 논리적 일관성 검토
- 핵심 요약 포함
3. 도구 설명 (Tool Descriptions)¶
각 도구의 목적, 사용 시기, 제약을 명확히 합니다.
구조¶
tools = [
{
"name": "도구_이름",
"description": "이 도구의 목적과 언제 사용하는지",
"when_to_use": [
"상황 1: ...",
"상황 2: ...",
],
"when_not_to_use": [
"상황 A: ...",
"상황 B: ...",
],
"parameters": {...},
"limitations": [
"제약 1: ...",
"제약 2: ...",
]
}
]
실제 예: 한국 학사 정보 조회 도구¶
{
"name": "query_student_db",
"description": "학생의 학적 정보(학번, 전공, 이수 학점 등) 조회",
"when_to_use": [
"학생의 현재 전공이 무엇인지 확인해야 할 때",
"이수한 학점이나 성적을 조회해야 할 때",
"학적 상태(재학, 휴학, 졸업 등)를 확인해야 할 때",
],
"when_not_to_use": [
"개인 연락처 정보가 필요할 때 (별도 도구 사용)",
"성적 증명서가 필요할 때 (별도 도구 사용)",
"다른 학생의 정보를 조회할 때 (권한 없음)",
],
"parameters": {
"student_id": {
"type": "string",
"description": "학번 (예: 2021001234)"
}
},
"limitations": [
"현재 세션의 로그인 사용자 정보만 조회 가능",
"실시간 정보는 최대 5분 지연 가능",
"DB 점검 시간(매일 05:00-06:00)에는 불가"
]
}
4. 메모리 관리 (Memory Management)¶
상태를 추적하고 효율적으로 관리합니다.
메모리 구조 설계¶
memory = {
"session_state": {
"current_task": "데이터 수집 단계",
"progress": "3/5 완료",
"timestamp": "2025-02-21 14:30:00"
},
"work_progress": {
"completed_searches": [
{"query": "삼성 신제품", "date": "2025-02-21", "results": 15},
{"query": "기준금리", "date": "2025-02-21", "results": 8},
],
"pending_searches": [
"한국 경제 성장률",
"기업 실적 현황"
]
},
"context_info": {
"user_preferences": "간단하고 명확한 설명 선호",
"deadlines": "2025-02-22 09:00",
"special_requirements": "한글 요약 필수"
}
}
메모리 추적 기준¶
추적할 정보:
✓ 작업 단계: 현재 어느 단계인가?
✓ 완료 항목: 어떤 부분이 완료되었는가?
✓ 미완료 항목: 남은 작업은 무엇인가?
✓ 결정 기록: 왜 이 결정을 내렸는가?
✓ 오류 기록: 어떤 오류가 발생했는가?
✓ 시간 추적: 각 단계에 얼마나 소요되었는가?
5. 오류 처리 (Error Handling)¶
실패 시나리오에 대한 지시사항을 제공합니다.
오류 처리 전략¶
error_handling = {
"API_failure": {
"description": "외부 API 호출 실패",
"response": [
"1단계: 오류 메시지 기록",
"2단계: 재시도 (최대 3회)",
"3단계: 대체 데이터 소스 사용",
"4단계: 사용자에게 알림 및 대안 제시"
]
},
"data_inconsistency": {
"description": "수집한 데이터의 모순",
"response": [
"1단계: 불일치하는 데이터 식별",
"2단계: 출처 확인",
"3단계: 가장 신뢰할 수 있는 출처 선택",
"4단계: 보고서에 주석 추가"
]
},
"incomplete_information": {
"description": "필요한 정보를 찾을 수 없음",
"response": [
"1단계: 검색 쿼리 조정",
"2단계: 유사한 정보 검색",
"3단계: 사용 가능한 정보로 진행",
"4단계: 미수집 정보 명시"
]
}
}
💡 실전 팁: 컨텍스트 엔지니어링 사례 연구¶
사례: 한국 장기 프로젝트 관리 에이전트¶
초기 문제점¶
문제 1: 불완전한 작업 실행
증상: 에이전트가 5개의 계획된 작업 중 3개만 수행
근본 원인:
"작업 계획을 세웠으면 모두 완료해야 한다"는
명시적 요구사항이 부족
원본 지시사항:
"주어진 프로젝트의 작업들을 계획하고 실행하세요"
(모호함 - 어느 정도까지 수행해야 하는가?)
해결책:
개선된 지시사항:
"프로젝트 계획에 포함된 모든 작업을 다음과 같이 처리하세요:
1. 각 작업에 대해 최소 하나의 실행 시도
2. 작업 실패 시에도 그 이유를 명확히 기록
3. 불가피하게 생략하는 작업은 그 정당한 이유를 설명
4. 모든 작업 결과를 최종 보고서에 포함
완료 기준:
✓ 계획된 모든 작업이 실행됨 (또는 실행 불가 이유 명시됨)
✓ 각 작업의 결과가 기록됨
✓ 전체 완성도가 80% 이상
"
문제 2: 디버깅 가시성 부족
해결책:
1. 명시적 사고 기록 지시
"매 단계마다 다음을 기록하세요:
- 현재 상태
- 다음 수행할 작업
- 그 이유"
2. 의사결정 기준 명시
"작업을 건너뛰는 경우, 다음을 필수로 기록:
- 건너뛴 이유
- 시도한 대안
- 그 대안도 불가능한 이유"
3. 진행 상황 추적
"스프레드시트 또는 JSON 형식으로:
- 작업 ID
- 계획된 기한
- 실제 완료 시간
- 상태 (todo/in_progress/completed/skipped)
- 메모 (특별사항)"
4. 정기적 체크포인트
"각 5개 작업 완료 후:
- 진행 상황 요약
- 발견된 문제점
- 다음 전략"
컨텍스트 엔지니어링 최적 실행¶
1. 프롬프트 모호성 제거¶
나쁜 예¶
문제: "연구"가 무엇인지 불명확. 어느 정도 깊이로? 어떤 형식으로?좋은 예¶
주어진 주제에 대해 다음과 같이 연구를 수행합니다:
1. 쿼리를 3-5개의 구체적인 세부 검색 항목으로 분해
예: "한국 경제 동향" →
- GDP 성장률 변화
- 실업률 현황
- 소비자 신뢰지수
- 기업 투자 계획
- 수출입 현황
2. 각 세부 항목에 대해 웹 검색 실행
- 최소 2개 이상의 신뢰할 수 있는 출처
- 1개월 이내 최신 데이터 우선
3. 각 검색 결과를 다음 필드와 함께 정리:
- 검색어
- 발견 내용
- 출처 및 신뢰도
- 수집 시간
- 특이사항
4. 모든 발견을 다음 구조로 종합:
- 개요 (100단어)
- 주요 발견 3개 (순위순)
- 트렌드 분석
- 예상 영향
- 출처 목록
2. 기대사항을 명시적으로 만들기¶
명확히 해야 할 것들:
필수 vs 선택적 행동
- 필수: 모든 검색 쿼리 수행
- 선택적: 비디오 콘텐츠도 검토
품질 기준
- 최소 정확도: 95%
- 출처 다양성: 최소 5개 이상
- 최신성: 1주일 이내 정보 우선
출력 형식
- 마크다운 형식
- 한글
- 섹션별로 명확한 제목
- 각 항목에 출처 링크 포함
의사결정 기준
- 정보 출처 신뢰도: 공식 기관 > 신문 > 블로그
- 시간: 최신 > 과거
- 관련성: 정확히 일치 > 부분 일치
3. 관찰성 구현¶
디버깅 메커니즘을 에이전트 시스템에 내장합니다.
class ObservableAgent:
def log_action(self, action, reason, result):
"""모든 행동 기록"""
log = {
"timestamp": datetime.now(),
"action": action,
"reason": reason, # 왜 이 행동을 했는가?
"result": result,
"tokens_used": token_count
}
self.action_log.append(log)
def log_decision(self, decision, alternatives, chosen_reason):
"""의사결정 기록"""
decision_log = {
"context": self.current_context,
"decision": decision,
"alternatives_considered": alternatives,
"reason_for_choice": chosen_reason,
"confidence": self.assess_confidence()
}
self.decision_log.append(decision_log)
def generate_trace(self):
"""실행 추적 보고서"""
return {
"total_actions": len(self.action_log),
"action_timeline": self.action_log,
"decisions_made": len(self.decision_log),
"decision_log": self.decision_log,
"errors_encountered": self.error_log,
"total_tokens_used": self.total_tokens
}
4. 행동을 기반으로 반복¶
컨텍스트 엔지니어링은 반복적 프로세스입니다.
단계 1: 배포
초기 컨텍스트와 제약으로 에이전트 배포
단계 2: 관찰
프로덕션에서 실제 행동 관찰
├─ 어떤 도구를 사용하는가?
├─ 어떤 오류가 발생하는가?
└─ 의도하지 않은 행동이 있는가?
단계 3: 식별
예상 행동과의 편차 파악
- "왜 학생 검색을 3번이나 했는가?"
- "왜 중요한 도구를 사용하지 않았는가?"
- "왜 오류를 무시했는가?"
단계 4: 정제
시스템 프롬프트 및 제약 개선
- 더 명확한 지시사항 추가
- 제약 조건 강화
- 우선순위 명시
단계 5: 테스트
개선된 에이전트로 테스트 케이스 실행
├─ 동일한 상황에서 더 나은 결과?
├─ 새로운 문제는 없는가?
└─ 비용/성능 트레이드오프는?
단계 6: 반복
문제가 해결될 때까지 반복 (또는 허용 범위 이내)
컨텍스트 엔지니어링 체크리스트¶
□ 시스템 프롬프트
└─ 역할이 명확한가?
└─ 성격과 톤이 정의되어 있는가?
└─ 제약과 경계가 명시되어 있는가?
□ 작업 제약
└─ 각 작업에 명확한 완료 기준이 있는가?
└─ 우선순위가 정의되어 있는가?
└─ 예외 상황에 대한 지시사항이 있는가?
□ 도구 설명
└─ 사용할 때와 사용하지 말아야 할 때가 명확한가?
└─ 제약과 한계가 문서화되어 있는가?
└─ 실패 시 폴백 옵션이 있는가?
□ 메모리 관리
└─ 추적할 상태가 정의되어 있는가?
└─ 메모리 용량 제한이 있는가?
└─ 오래된 정보 정리 정책이 있는가?
□ 오류 처리
└─ 예상 가능한 오류들이 나열되어 있는가?
└─ 각 오류에 대한 대응책이 있는가?
└─ 심각한 오류 시 에스컬레이션 절차가 있는가?
□ 모니터링
└─ 에이전트의 행동을 로깅하는가?
└─ 의사결정 프로세스를 추적하는가?
└─ 정기적으로 성능을 평가하는가?
📝 핵심 정리¶
컨텍스트 엔지니어링의 정의¶
- 프롬프트 엔지니어링을 넘어 전체 에이전트 시스템 설계
- 지시사항, 제약, 메모리, 오류 처리의 통합
- 반복적 개선 프로세스
핵심 요소¶
- 시스템 프롬프트: 에이전트의 역할과 성격 정의
- 작업 제약: 의사결정 경계와 규칙
- 도구 설명: 각 도구의 목적과 제약
- 메모리 관리: 상태 추적과 학습
- 오류 처리: 실패 시나리오 대응
성공 기준¶
- ✓ 에이전트가 예상된 행동을 수행
- ✓ 오류가 명확히 처리됨
- ✓ 성능이 모니터링됨
- ✓ 지속적으로 개선됨
일반적 실수¶
- ✗ 모호한 지시사항
- ✗ 예외 상황 미처리
- ✗ 메모리 관리 부족
- ✗ 결과 검증 절차 없음
시험 포인트¶
- 효과적인 시스템 프롬프트 작성
- 작업 제약의 설계와 표현
- 도구 정의의 명확성과 완성도
- 관찰성과 디버깅 메커니즘
- 컨텍스트 반복의 효과 평가
- 복잡한 에이전트 행동 분석
- 프롬프트 엔지니어링과의 차이 이해
- 실무에서의 컨텍스트 개선 전략