Agent 설계 패턴
Prompt 엔지니어링에서 컨텍스트 엔지니어링으로
단일 대화에서 멀티스텝 Agent로 전환할 때, Prompt 최적화만으로는 충분하지 않습니다. 진짜 과제는 매 추론 단계마다 모델에 전달하는 모든 Token을 어떻게 큐레이션하느냐입니다.
개념의 진화
과거
Prompt Engineering
프롬프트 작성 방식 최적화: 표현, 구조, Few-shot 예제
현재
Context Engineering
매 추론 단계마다 모델에 전달하는 모든 Token 큐레이션: System Prompt, 도구 정의, MCP 설명, 대화 이력, 외부 검색 데이터...
Prompt 엔지니어링은 지시문 작성 방식에 집중하지만, 컨텍스트 엔지니어링은 더 큰 질문을 다룹니다: 모델의 입력 창에 무엇을, 어떻게, 얼마나 넣을 것인가. 시스템에 System Prompt, 도구 설명, 이전 메시지, RAG 검색 결과, 사용자 선호도가 모두 있다면, 이 모든 것이 컨텍스트 창의 절반 이상을 차지할 수 있습니다. 이러한 Token들을 어떻게 관리하느냐가 바로 컨텍스트 엔지니어링입니다.
컨텍스트 창 안에는 무엇이 있나
System Prompt — 역할 정의, 규칙, 제약
Tool Definitions — 도구 이름, 파라미터, 설명
Conversation History — 멀티턴 대화 이력
Retrieved Data — RAG 검색 결과, 파일 내용
User State — 사용자 선호도, 세션 상태, 환경 정보
이 모든 것의 합 = 모델이 매 추론 단계에서 보는 전체 정보
컨텍스트 엔지니어링이 중요한 이유
Context Rot
컨텍스트가 길어질수록 모델의 정보 검색 정확도가 낮아집니다. 핵심 정보가 방대한 Token 속에 묻혀버립니다.
제한된 어텐션 예산
모든 Token이 모델의 어텐션 예산을 소모합니다. 불필요한 Token 점유 = 유용한 정보의 희석.
n-squared 복잡도
n개의 Token은 n×n개의 어텐션 관계를 만듭니다. 컨텍스트가 두 배가 되면 계산량은 네 배로 늘어납니다.
직접 체험: Context Rot 시뮬레이터
1K Token — 짧은 대화
어텐션 집중, 검색 정확
검색 정확도
어텐션 밀도
높은 어텐션 낮은 어텐션
어텐션 비용 이해하기
Transformer 자기 어텐션 메커니즘에서 각 Token은 다른 모든 Token과 연관도를 계산해야 합니다:
Attention Complexity = O(n^2)
즉: 컨텍스트를 50K에서 100K Token으로 늘리면 어텐션 계산량이 4배로 늘어납니다. 단순 두 배가 아닙니다. 컨텍스트는 공짜가 아닙니다: 불필요한 Token을 하나 추가할 때마다 다른 Token이 받을 수 있는 어텐션을 낭비하는 것입니다.
효율적인 컨텍스트의 세 가지 원칙
System Prompt의 적절한 높이
너무 모호하면 ("당신은 유용한 어시스턴트입니다") = 모델이 방향을 잃고 일반적인 출력을 냅니다.
너무 구체적이면 (50가지 엣지 케이스 나열) = 모델이 과도하게 제약되어 새로운 상황에 유연하게 대응하지 못합니다.
모범 사례: 명확한 역할과 핵심 원칙(5~10개)을 제시하고, 그 틀 안에서 모델이 스스로 판단하도록 신뢰합니다. 좋은 관리자처럼 방향을 주되 세세한 지시는 하지 않습니다.
너무 구체적이면 (50가지 엣지 케이스 나열) = 모델이 과도하게 제약되어 새로운 상황에 유연하게 대응하지 못합니다.
모범 사례: 명확한 역할과 핵심 원칙(5~10개)을 제시하고, 그 틀 안에서 모델이 스스로 판단하도록 신뢰합니다. 좋은 관리자처럼 방향을 주되 세세한 지시는 하지 않습니다.
System Prompt의 높이에서 중간의 스위트스팟을 찾아야 합니다
도구셋은 간결하게
현장에서 검증된 원칙: 사람이 어떤 도구를 써야 할지 모른다면, AI도 모릅니다.
Agent에게 기능이 비슷하지만 설명이 모호한 도구 10개를 주는 것보다, 역할이 명확하고 이름이 정확한 도구 5개가 훨씬 낫습니다. 각 도구의 description은 좋은 API 문서처럼 작성해야 합니다 — 호출자(모델)가 언제, 어떻게 쓰는지 한눈에 알아야 합니다.
Agent에게 기능이 비슷하지만 설명이 모호한 도구 10개를 주는 것보다, 역할이 명확하고 이름이 정확한 도구 5개가 훨씬 낫습니다. 각 도구의 description은 좋은 API 문서처럼 작성해야 합니다 — 호출자(모델)가 언제, 어떻게 쓰는지 한눈에 알아야 합니다.
Few-shot 예제는 엄선하고 쌓지 말 것
Few-shot 예제는 컨텍스트에서 ROI가 가장 높은 부분이지만, 올바른 것을 선택했을 때만 그렇습니다.
올바른 방법: 목표 행동을 가장 잘 나타내는 2~3개의 전형적인 예제를 엄선하여 가장 흔한 입력 패턴을 커버합니다.
잘못된 방법: 엣지 케이스 예제 10개 이상을 쌓으면 Token을 낭비할 뿐 아니라, 모델이 주요 흐름을 무시하고 예외 상황에 과도하게 집중하게 됩니다.
올바른 방법: 목표 행동을 가장 잘 나타내는 2~3개의 전형적인 예제를 엄선하여 가장 흔한 입력 패턴을 커버합니다.
잘못된 방법: 엣지 케이스 예제 10개 이상을 쌓으면 Token을 낭비할 뿐 아니라, 모델이 주요 흐름을 무시하고 예외 상황에 과도하게 집중하게 됩니다.
컨텍스트는 희소 자원입니다. 목표는 최소한의 고신호 Token 집합을 찾는 것입니다. 모든 Token은 모델의 추론에 기여해야 합니다 — "넣을 수 있는 건 다 넣자"는 생각은 통하지 않습니다. 편집자가 글을 다듬듯 컨텍스트를 다듬으세요: 불필요한 단어 하나하나가 잡음입니다.