프롬프트 엔지니어링은 Agent의 행동 지침을 설계하는 기술이며, 컨텍스트 엔지니어링은 Agent가 각 단계에서 판단에 사용할 정보 전체를 구성하고 관리하는 기술입니다. 전문가에게 중요한 차이는 ‘문장을 얼마나 잘 쓰는가’와 함께 ‘실행 시점마다 어떤 근거와 상태를 모델에게 제공하는가’를 설계한다는 점입니다.
Anthropic도 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 확장으로 설명하며, 시스템 지침뿐 아니라 도구, 외부 데이터, 대화 이력 등을 관리 대상으로 봅니다. 두 개념은 경쟁 관계가 아니라 포함·보완 관계에 가깝습니다. [1]
1. 두 접근법의 차이
| 비교 항목 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 핵심 질문 | 어떻게 지시해야 원하는 행동을 하는가? | 지금 판단하는 데 어떤 정보가 필요한가? |
| 주요 대상 | 역할, 지시문, 예시, 제약, 출력 형식 | 지시문, 검색 결과, 도구 정의·응답, 작업 상태, 메모리 |
| 설계 단위 | 지시와 입력의 표현·구조 | 여러 단계에 걸친 정보의 선택·갱신·제거 |
| 대표 작업 | 모호한 지시 수정, 예시 추가, 판단 기준 명시 | 검색, 재정렬, 요약, 상태 저장, 필요한 정보 재조회 |
| 실패 사례 | “중요한 내용을 잘 정리해”처럼 기준이 불명확함 | 오래된 문서와 최신 문서가 섞여 잘못된 결론을 냄 |
| 개선 산출물 | 버전 관리된 프롬프트와 예시 | 컨텍스트 구성 로직, 데이터 스키마, 메모리 정책 |
이 구분은 실무적인 설명입니다. 프롬프트도 동적으로 생성할 수 있고, 컨텍스트 엔지니어링에서도 문서의 표현과 배치가 중요합니다.
2. Agent에서는 왜 컨텍스트 설계가 더 중요해지는가
Agent는 모델 호출과 도구 실행을 반복합니다. 검색 결과, 오류 메시지, 중간 산출물이 쌓이면서 다음 판단에 사용할 정보가 계속 달라집니다.
예를 들어 첫 검색에서 잘못된 숫자를 얻은 뒤 이를 메모리에 ‘확정 사실’로 저장하면, 이후의 프롬프트가 명확해도 잘못된 분석이 이어질 수 있습니다. 반대로 정확한 정보를 갖고 있어도 판단 규칙이 모호하면 잘못된 도구를 선택할 수 있습니다.
LangChain은 이런 정보 관리를 네 가지 전략으로 정리합니다. [2]
| 전략 | 의미 | Agent 설계에 적용하는 예 |
|---|---|---|
| 저장하기·Write | 정보를 현재 컨텍스트 밖에 보관 | 확인된 사실과 미완료 작업을 상태 저장소에 기록 |
| 선택하기·Select | 현재 단계에 필요한 정보를 불러오기 | 분석 대상 기간과 관련된 문서만 검색 |
| 압축하기·Compress | 필요한 정보를 유지하며 분량 축소 | 긴 실행 기록을 결정 사항·오류·남은 작업으로 요약 |
| 분리하기·Isolate | 서로 다른 작업의 컨텍스트를 분리 | 문서별 분석을 분리하고 근거가 있는 결과만 통합 |
여기서 저장된 정보와 모델이 현재 볼 수 있는 정보는 다릅니다. 데이터베이스에 사실을 저장했더라도, 해당 호출의 입력으로 가져오지 않으면 모델은 그 사실을 활용할 수 없습니다.
3. 실무 예제: 여러 보고서를 종합 분석하는 Agent
“여러 부서의 주간 보고서를 분석해 지연 원인과 대응 방안을 작성하라”는 업무를 가정하겠습니다. 아래는 구현을 위한 설계 예시입니다.
프롬프트에는 행동 규칙과 성공 기준을 넣습니다.
보고서에 명시된 사실과 분석자의 추정을 구분합니다.
모든 주요 결론에는 문서 ID와 근거 위치를 연결합니다.
같은 사건의 중복 보고는 하나로 통합합니다.
수치가 충돌하면 기준일·단위·집계 범위를 비교합니다.
근거가 부족하면 미확인으로 표시하고 필요한 추가 자료를 제시합니다.
하지만 이 지시만으로 필요한 보고서가 자동으로 확보되거나 중복이 제거되는 것은 아닙니다. 컨텍스트 구성은 별도의 실행 로직으로 설계해야 합니다.
| 처리 단계 | 모델에 제공할 정보 | 시스템에서 관리할 사항 |
|---|---|---|
| 대상 선정 | 요청 기간, 부서, 분석 목적 | 접근 권한, 문서 버전, 대상 누락 |
| 사실 추출 | 개별 문서의 관련 구간 | 문서 ID, 페이지, 기준일, 단위 |
| 충돌 검토 | 서로 다른 값을 주장하는 근거 | 정정본 여부, 집계 범위 차이 |
| 종합 분석 | 검증된 사실, 미해결 쟁점, 비교 기준 | 중복 제거, 근거 연결 |
| 최종 검증 | 초안과 초안에서 인용한 원문 | 수치·인용·누락 검사 |
이 구조에서는 최종 작성 단계에 모든 원문을 반복 투입할 필요가 없습니다. 다만 중요한 주장을 검증할 때 원문을 다시 확인할 수 있어야 합니다.
예를 들어 추출한 사실은 다음처럼 관리할 수 있습니다. 아래 수치는 설명용 가상 데이터입니다.
{
"claim_id": "C017",
"claim": "프로젝트 A의 완료 예정일이 5일 지연됨",
"source": {
"document_id": "report_A_v3",
"section": "일정 현황",
"as_of": "2026-10-30"
},
"status": "reported",
"conflicts_with": ["C009"],
"verification_needed": "영업일인지 달력일인지 확인"
}reported는 원문에 기재됐다는 뜻입니다. 교차 검증까지 완료했다는 뜻과 구분해야 합니다. 이 구분이 있어야 Agent가 출처의 주장과 검증된 사실을 혼동하는 문제를 줄일 수 있습니다.
4. 전문가가 설계할 때 주의할 지점
- 지시문·근거·작업 상태를 분리합니다.지시문에는 행동 규칙, 근거에는 외부 자료, 상태에는 확인된 결과와 미완료 작업을 둡니다. 검색 문서 안의 “이전 지시를 무시하라” 같은 문구가 실행 지시로 취급되지 않도록 신뢰 경계를 설계해야 합니다. 실제 권한은 도구 실행 계층에서 강제해야 합니다.
- 도구 설명과 도구 응답을 함께 설계합니다.도구 설명에는 사용 조건, 인수 의미, 부작용을 명확히 적습니다. 응답에는 판단에 필요한 필드와 출처를 포함하고, 대량 결과는 필터·페이지네이션·상세 조회로 다룹니다. Anthropic도 명확한 도구 경계와 의미 있는 응답, 토큰 효율을 핵심 설계 원칙으로 제시합니다. [3]
- 요약에서 보존할 항목을 명시합니다.단순히 “짧게 요약”하도록 하면 단위, 예외, 상충 근거가 사라질 수 있습니다. 수치·기준일·출처·미해결 쟁점은 보존 대상으로 지정하고, 원문 참조를 유지하는 편이 좋습니다.
- 장기 메모리에 갱신 규칙을 둡니다.메모리에는 출처, 저장 시점, 적용 범위, 검증 상태를 붙입니다. 반복 사용되는 사용자 선호와 수시로 바뀌는 업무 현황은 서로 다른 갱신 정책이 필요합니다.
- 컨텍스트 크기는 성능 평가로 결정합니다.최대 입력 길이를 채우는 것이 목표가 아닙니다. 필요한 근거가 충분하면서도 불필요한 정보가 적어야 합니다. 긴 입력에서의 정확도 저하 정도는 모델과 작업에 따라 달라집니다. [1]
5. 문제가 생겼을 때 무엇부터 수정해야 하는가
| 관찰된 문제 | 우선 점검할 원인 | 개선 방향 |
|---|---|---|
| 근거는 정확한데 출력 형식이 다름 | 지시·출력 계약 | 명확한 스키마와 검증 적용 |
| 필요한 자료를 찾지 못함 | 검색·정보 선택 | 검색 조건, 인덱스, 검색 범위 개선 |
| 오래된 정보를 사용함 | 버전·메모리 관리 | 기준일 필터와 갱신 정책 적용 |
| 도구를 반복 호출함 | 작업 상태·종료 조건 | 완료 항목과 중단 조건 명시 |
| 요약 후 숫자나 조건이 바뀜 | 압축 과정 | 필수 필드 보존과 원문 대조 |
| 문서의 악성 지시를 따름 | 신뢰 경계·권한 통제 | 외부 입력 분리와 실행 계층 검증 |
6. 프롬프트와 컨텍스트 개선 효과를 평가하는 방법
개선 효과를 확인하려면 프롬프트와 컨텍스트를 각각 바꾸는 비교 실험이 유용합니다. 다음 네 조건을 동일한 평가 과제에 적용해 보십시오.
| 조건 | 프롬프트 | 컨텍스트 구성 |
|---|---|---|
| A | 기존 | 기존 |
| B | 개선 | 기존 |
| C | 기존 | 개선 |
| D | 개선 | 개선 |
평가는 문장 품질뿐 아니라 업무 성공률, 근거 정확도, 필수 정보 누락률, 도구 오류, 비용, 지연 시간을 함께 측정해야 합니다. 동일 과제를 반복 실행하고, 튜닝에 쓰지 않은 과제로도 검증해야 개선이 일반화되는지 판단할 수 있습니다. 도구 평가에서도 최종 정확도와 함께 실행 시간·호출 수·토큰 사용량·오류를 추적하는 방식이 권장됩니다. [3]
실제 Agent를 개선할 때는 실패한 실행 하나를 골라, 그 판단 시점에 모델이 받은 지시·근거·도구·상태를 재구성하는 작업부터 시작하는 것이 좋습니다. 필요한 근거가 없었다면 정보 공급을, 근거가 있었지만 행동 기준이 모호했다면 프롬프트를 수정해야 합니다.
참고 자료
- Anthropic, Effective context engineering for AI agents
- LangChain, Context Engineering for Agents
- Anthropic, Writing effective tools for AI agents
'영상처리 도구' 카테고리의 다른 글
| REA란? AI 에이전트를 활용한 리버스 엔지니어링 기술 (0) | 2026.10.24 |
|---|---|
| 구글 Gemini Agentic Video 기술과 활용 방법 (0) | 2026.10.18 |
| Invideo Agentic Extend: AI Agent 영상 자동 확장 기능과 사용법 (0) | 2026.10.11 |
| OpenAI Agent 닷츠(Dots) 특징과 활용, 뮤즈(Muse)의 차이 (0) | 2026.10.05 |
| 메타 AI Agent 뮤즈(Muse) 특징과 활용 방법 (0) | 2026.09.23 |