컨텍스트 엔지니어링 실무: 프롬프트를 길게 쓰는 대신 AI 업무 그래프를 설계하는 법
AI가 자꾸 틀릴 때 프롬프트만 고치면 같은 문제가 반복됩니다. 목표·지식·상태·도구·권한·출력 계약을 업무 그래프로 묶어 컨텍스트를 운영하는 방법을 정리했습니다.
한 줄 답변: 컨텍스트 엔지니어링은 프롬프트에 정보를 많이 붙이는 일이 아니라, AI가 현재 목표를 달성하는 데 필요한 사실·상태·도구·제약·근거를 올바른 시점에 제공하는 설계다. 고정 지식, 이번 요청의 데이터, 진행 상태, 승인 조건을 분리해야 오래 가는 업무에서 누락과 환각을 줄일 수 있다.
AI가 틀리면 많은 팀이 프롬프트에 문장을 더 붙입니다. 금지사항을 늘리고 예시를 추가하고 답변 형식을 반복해서 설명합니다. 어느 순간 프롬프트는 길어졌지만 결과는 안정되지 않습니다. 문제는 문장 수가 아니라 AI가 어느 상태에서 어떤 자료와 권한을 가지고 판단하는지 보이지 않는 데 있습니다.
프롬프트와 컨텍스트는 어떻게 다른가?
| 구분 | 프롬프트 중심 | 컨텍스트 운영 | 실무 산출물 |
|---|---|---|---|
| 관심 대상 | 지시 문장 | 업무에 필요한 입력 묶음 | 컨텍스트 맵 |
| 시간 | 한 번의 요청 | 업무 시작부터 완료까지 | 상태 전이표 |
| 근거 | 모델이 알아서 판단 | 출처·최신성·권한 표시 | 근거 패킷 |
| 실패 | 문장을 더 추가 | 누락·오염·권한 오류를 분리 | 실패 분류표 |
컨텍스트를 5개 층으로 나눈다
실무에서 컨텍스트를 정리할 때는 목표, 지식, 상태, 도구, 제약의 다섯 층으로 나누면 좋습니다. 목표는 이번 작업의 완료 상태이고, 지식은 회사 정책과 제품 정보입니다. 상태는 이미 확인한 것과 아직 남은 단계이며, 도구는 조회·작성·실행 권한입니다. 제약은 개인정보, 승인, 시간, 비용, 출력 형식입니다.
| 층 | 질문 | 누락될 때 생기는 문제 |
|---|---|---|
| 목표 | 무엇을 완료하면 끝인가? | 그럴듯하지만 쓸모없는 답 |
| 지식 | 어떤 자료를 사실로 보는가? | 오래된 정책과 환각 |
| 상태 | 지금 어디까지 왔는가? | 같은 단계 반복 |
| 도구 | 무엇을 읽고 바꿀 수 있는가? | 권한 오남용 |
| 제약 | 무엇을 하면 안 되는가? | 안전·품질 사고 |
고정 컨텍스트와 요청 컨텍스트를 분리한다
모든 요청에 반복되는 용어집, 출력 스키마, 정책 요약을 고정 컨텍스트로 두고, 이번 고객·문서·이벤트에만 필요한 데이터를 요청 컨텍스트로 분리합니다. 이렇게 해야 최신 데이터만 교체할 수 있고 캐시나 비용 최적화도 검토하기 쉽습니다.
지식은 양보다 출처와 적용 범위가 중요하다
- 문서 소유자와 마지막 검토일을 기록한다
- 정책이 적용되는 제품·고객·지역을 표시한다
- 검색 결과에 원문 링크와 인용 구간을 남긴다
- 폐기된 문서와 현재 문서를 같은 우선순위로 넣지 않는다
- 접근 권한이 다른 문서를 검색 인덱스에서 분리한다
AI가 최신 문서를 읽었다고 말하는 것과 실제로 최신 문서의 근거를 사용한 것은 다릅니다. 답변에 출처를 붙이고, 사람이 5분 안에 원문을 확인할 수 있어야 컨텍스트 품질을 운영할 수 있습니다.
상태를 대화 기록과 구분한다
긴 대화는 상태 저장소가 아닙니다. 이미 본 문서, 승인된 결정, 실패한 도구 호출, 다음에 해야 할 행동을 별도 필드로 저장해야 합니다. 그래야 대화가 길어져도 모델이 과거의 제안과 확정된 상태를 혼동하지 않습니다.
| 상태 필드 | 예시 | 변경 권한 |
|---|---|---|
| current_step | 고객 확인 대기 | 워크플로우 |
| verified_facts | 계약 만료일 확인 | 사람 또는 공식 시스템 |
| pending_questions | 예산 승인 여부 | 담당자 |
| approved_actions | 메일 초안 승인 | 승인자 |
| failure_count | 도구 재시도 2회 | 시스템 |
컨텍스트 오염과 프롬프트 인젝션을 분리해 다룬다
외부 메일, 웹 페이지, 업로드 문서는 지시문이 아니라 데이터로 취급해야 합니다. 문서에 포함된 '이 지시를 무시하라'는 문장이 시스템 정책을 바꿀 수 없어야 합니다. 도구 호출 전에는 입력을 신뢰 경계별로 분리하고, 외부 효과가 있는 행동은 사람 승인으로 연결합니다.
- 외부 입력과 내부 정책을 구분한다
- 검색 결과의 지시 문장을 실행 명령으로 승격하지 않는다
- 도구 인자를 스키마로 검증한다
- 민감 행동은 승인 대기 상태에서 멈춘다
컨텍스트 변경도 평가셋으로 검증한다
컨텍스트를 줄이거나 검색 순서를 바꾸면 비용은 줄어도 근거 누락이 늘 수 있습니다. 대표 사례 30건을 고정하고, 어떤 정보가 필요한지와 어떤 답이 금지되는지를 비교합니다. 정답률만 보지 말고 근거 재현성, 불확실성 표시, 승인 누락도 봐야 합니다.
2주 파일럿 체크리스트
- 대표 업무 하나를 골라 목표·지식·상태·도구·제약을 현재 문서에서 분리한다.
- 고정 컨텍스트와 요청별 데이터를 나누고 각 필드의 소유자와 최신성 기준을 적는다.
- 정상·누락·오래된 문서·외부 인젝션 사례 30건으로 평가셋을 만든다.
- 컨텍스트 변경 전후의 필수 필드 정확도와 근거 재현성을 비교한다.
- 효과가 확인된 필드만 운영에 넣고, 권한·승인·삭제 정책을 함께 문서화한다.
컨텍스트 엔지니어링을 프롬프트 작성자의 개인 노하우로 두면 팀이 커질수록 다시 무너집니다. 업무에 필요한 정보의 구조, 상태, 권한, 근거를 문서화하고 평가셋으로 검증해야 누구나 같은 품질을 재현할 수 있습니다.
공식 참고 자료
자주 묻는 질문
컨텍스트 엔지니어링은 프롬프트 엔지니어링과 어떻게 다른가요?
프롬프트가 지시 문장 중심이라면 컨텍스트 엔지니어링은 업무 목표·지식·현재 상태·도구·제약을 필요한 시점에 제공하는 운영 설계입니다.
컨텍스트에 자료를 많이 넣으면 정확도가 좋아지나요?
항상 그렇지 않습니다. 오래된 문서와 권한이 다른 자료가 섞이면 오히려 오류가 늘 수 있습니다. 출처, 적용 범위, 최신성, 접근 권한을 함께 관리해야 합니다.
대화 기록만으로 에이전트 상태를 관리해도 되나요?
긴 대화는 확정된 사실과 제안, 실패 상태를 혼동할 수 있습니다. 현재 단계, 승인된 행동, 미해결 질문을 구조화해 별도 저장하는 편이 안전합니다.
외부 문서의 프롬프트 인젝션은 어떻게 막나요?
외부 입력을 지시가 아니라 데이터로 취급하고, 내부 정책과 분리하며, 도구 인자를 검증하고, 외부 효과가 있는 행동은 사람 승인 뒤에 실행해야 합니다.
컨텍스트 변경은 무엇으로 평가하나요?
필수 필드 정확도, 근거 재현성, 불확실성 표시, 승인 누락, 비용과 지연시간을 동일 평가셋에서 전후 비교해야 합니다.
우리 팀의 AI 업무를 어디까지 자동화할 수 있는지, 그리고 어떤 승인·로그·평가가 필요한지 먼저 점검해보세요.
AX 셀프리뷰 시작하기