에이전트는 정보가 없으면 행동할 수 없고, 정보가 넘치면 중요한 것을 놓친다. Sierra의 컨텍스트 엔지니어링은 이 두 가지 실패를 모두 피하는 방법론으로, 핵심 개념인 프로그레시브 디스클로저(Progressive Disclosure)와 조건(Conditions)을 통해 에이전트에게 정확히 필요한 정보를 정확한 시점에 제공한다.
고객 인터랙션의 세 가지 시대
컨텍스트 엔지니어링이 왜 필요한지 이해하려면 AI 에이전트가 어떻게 진화해 왔는지 살펴봐야 한다.
1세대: IVR(대화형 음성 응답). 생각하거나 추론할 수 없다. 오직 메뉴만 있다. “청구는 1번, 반품은 2번.” 고객의 문제가 메뉴에 없으면 막힌다.
2세대: 플로우(Flow). 많은 AI 에이전트가 여전히 미리 정해진 경로를 따른다—플로우차트, 의사결정 트리, 디지털화된 표준 운영 절차(SOP). 고객이 자연어로 말할 수 있지만 시스템은 여전히 “이러면 저렇게”로 동작한다. 문제가 플로우 밖에 있으면 에스컬레이션된다. SOP가 늘어날수록 시스템은 복잡해지고 오류 위험이 높아진다.
3세대: 컨텍스트 엔지니어링. 가장 정교한 에이전트는 이런 경직된 플로우에 의존하지 않는다. 목표와 가드레일로 안내된다. 기반 모델이 대화를 이끌고, 에이전트의 행동은 학습한 것을 바탕으로 실시간 적응한다. Sierra의 역할은 적절한 컨텍스트를 적절한 시점에 전달해 에이전트가 효과적으로 추론하고 올바르게 행동하게 하는 것이다.
프로그레시브 디스클로저
컨텍스트 창에 토큰(텍스트 조각)이 늘어날수록 모델이 해당 정보를 정확하게 회상하고 활용하는 능력은 떨어진다. 관련 없는 모든 토큰이 실제로 중요한 토큰의 주의를 분산시킨다.
컨텍스트 엔지니어링은 프로그레시브 디스클로저로 이 문제를 해결한다: 대화의 매 순간마다 최소한의, 가장 관련성 높은 정보만 제공하는 것이다.
예를 들어, 고객이 유럽 국제 배송에 대해 문의하면 에이전트는 처음부터 모든 국가별 규칙을 알 필요가 없다. 목적지를 알게 된 이후에야 그 정보가 관련성을 가진다. 배송지가 독일이라면 독일 특화 가이드가 필요하다. 그 전까지는 노이즈일 뿐이다.
조건(Conditions): 연결 조직
조건은 프로그레시브 디스클로저를 작동하게 하는 핵심이다. “어떤 상황에서 이 정보가 관련성을 가지는가?”에 대한 답변이다.
조건은 두 종류로 나뉜다:
- 상태 기반: 도구가 특정 데이터를 반환했을 때, 고객이 인증되었을 때, 구독이 로드되었을 때
- 관찰 기반: 고객이 특정 주제를 언급했을 때, 해지 의사를 표현했을 때, 특정 제품에 대해 질문했을 때
조건이 충족되면 정보가 에이전트에 제공된다. 이 레이어링으로 대화는 최소한으로 시작—기본 도구, 일반 정책, 브랜드 보이스—하지만 길고 복잡한 고객 인터랙션도 처리할 수 있다.
대화가 진행될수록:
- 고객이 인증되면 계정 특화 도구와 정책이 사용 가능해진다
- 청구 관련 질문이 나오면 분쟁 워크플로, 정책, 조사 도구가 제공된다
- 각 단계가 다음 단계에 정확히 필요한 것을 열어준다
컨텍스트의 유형
Sierra 플랫폼은 컨텍스트를 다음과 같은 관리 가능한 컴포넌트로 구조화한다:
| 블록 | 목적 |
|---|---|
| Journey | 에이전트가 추구하는 목표: 청구 분쟁, 클레임 제출, 항공편 예약. 각 Journey는 트리거와 결과를 가진다. |
| Tool | 외부 시스템과 상호작용하는 방법: 여행 일정 조회, 보장 확인, 환불 처리. |
| Rule / Policy | 자연어로 표현된 가드레일과 비즈니스 로직 (예: “프리미엄 카드 소지자는 해외 결제 수수료 면제”). |
| Workflow | 규제 접수나 다단계 인증처럼 특정 순서가 필요한 상황을 위한 단계별 가이드. |
| Knowledge | 에이전트가 온디맨드로 접근하는 헬프 센터 아티클, 제품 문서, FAQ, 내부 정책. |
| Memory | 고객 이력: 과거 대화, 선호도, 이전 이슈. |
| Glossary | 비즈니스 전용 용어: 제품명, 플랜 등급, 내부 전문 용어. |
| Response phrasing | 브랜드 보이스와 톤. |
워크플로에 대한 주목할 점: 경직된 플로우의 한계를 논했지만, 고도로 규제된 접수 프로세스처럼 일부 상황은 실제로 워크플로가 필요하다. 차이는 워크플로가 전체 시스템의 조직 패러다임이 아니라, 조건이 충족될 때 제공되는 하나의 컨텍스트 조각이 된다는 점이다.
왜 컨텍스트 엔지니어링이 중요한가
하나의 태스크와 몇 가지 도구로는 현대적인 에이전트가 자연스럽고 신뢰성 있게 동작한다. 하지만 수십 가지 지원 유즈케이스, 다중 시스템, 세그먼트별 정책이 있는 프로덕션 규모에서는 성능과 복잡도의 현실이 드러난다.
5개의 Journey를 처리하는 에이전트는 느슨한 컨텍스트 관리로도 버틸 수 있다. 50개를 처리하는 에이전트는 모든 컨텍스트가 정확한 순간에 도달해야 한다. 그 훈련이 없으면 모델은 압도되고 경험은 저하된다.
컨텍스트 엔지니어링은 이를 아키텍처 레벨에서 해결한다:
- 고관련성 토큰만 전송 → 환각 감소, 자연스러움 향상, 성능 향상
- 토큰 낭비 제거 → 단순한 항공편 재예약 중에 1,000토큰의 수하물 정책을 처리하지 않아도 됨
- 미래 대비: 로직을 하드코딩하면 모델을 제약한다—정해진 경로만큼만 유능해진다. 컨텍스트 엔지니어링으로 에이전트는 더 자유롭게 추론할 수 있고, 더 유능한 모델이 출시될 때 그 이점을 자동으로 상속받는다
더 스마트한 모델도 컨텍스트 엔지니어링의 필요성을 대체하지 않는다. 아무리 스마트한 사람도 모르는 것은 알 수 없다. 하지만 올바르게 할 때의 보상을 증폭시킨다.
참고 자료
- Context engineering: the key to great agents — Neil Rahilly / X (Sierra) (2026-05-08)