AI 에이전트를 프로덕션 수준으로 개발하는 것과 단순 데모를 만드는 것은 전혀 다른 문제입니다. 간단한 질의응답은 잘 작동하지만, 데이터 분석 후 리포트를 생성하는 것처럼 여러 단계를 거치는 실제 업무는 Context Window 한계, 성능 저하, 비용 증가 등의 벽에 부딪힙니다. 이러한 문제를 해결할 수 있는 방법으로 다양한 Context Engineering 기법들이 제안되고 있지만, 실제로 어떻게 적용해야 하는지는 여전히 […] ||
AI 에이전트를 프로덕션 수준으로 개발하는 것과 단순 데모를 만드는 것은 전혀 다른 문제입니다. 간단한 질의응답은 잘 작동하지만, 데이터 분석 후 리포트를 생성하는 것처럼 여러 단계를 거치는 실제 업무는 Context Window 한계, 성능 저하, 비용 증가 등의 벽에 부딪힙니다. 이러한 문제를 해결할 수 있는 방법으로 다양한 Context Engineering 기법들이 제안되고 있지만, 실제로 어떻게 적용해야 하는지는 여전히 많은 개발자들의 고민거리입니다.
AWS Korea SA Team은 이러한 과제를 직접 풀기 위해 ‘Deep Insight‘라는 프로덕션급 Multi-Agent 시스템을 개발했습니다. 이번 블로그 시리즈에서는 AWS Korea SA Team이 Deep Insight를 개발하며 직접 경험하고 해결한 내용을 3회에 걸쳐 공유합니다. Multi-Agent Architecturing, Structured Note-Taking 등 Anthropic이 제안한 Context Engineering 기법들을 실제 프로덕션 환경에 어떻게 적용했는지, 어떤 trade-off가 있었는지 코드와 함께 살펴보고, 이 에이전트를 AWS에 배포하고 운영하며 얻은 인사이트까지 실전에서 검증된 방법들을 상세히 다룹니다.
[시리즈 블로그 보기]
Part 1: 프로덕션 Multi-Agent 시스템이 해결해야 할 5가지 문제 – Deep Insight 아키텍처로 배우는 실전 설계
Part 2: Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법
Part 3: 개발에서 운영까지 – Deep Insight 에이전트를 AWS에 안전하게 배포하는 방법 (발행 예정)
첫 번째 블로그에서는 프로덕션 Multi-Agent 시스템이 해결해야 할 5가지 핵심 문제를 정의하고, Strands Agents SDK, Amazon Bedrock 및 Bedrock AgentCore, 그리고 AWS Fargate가 각각 어떤 계층의 문제를 해결하는지를 코드와 함께 소개했습니다. 이번 두 번째 블로그에서는 이 아키텍처 위에서 Context Window 한계를 극복하기 위한 4가지 계층의 핵심 기법과 구체적인 구현 방법을 다룹니다. 마지막 세 번째 블로그에서는 로컬 개발 환경에서 나아가 AWS VPC 상에 보안을 갖춘 Private 네트워크 구조로 에이전트를 배포하고 운영하기까지, 실제 운영에 필요한 모든 과정을 안내합니다.
Context Engineering이란?
Context Engineering은 LLM의 제한된 Context window 내에서 에이전트가 최고 성능을 낼 수 있도록 정보를 최적화하는 기술입니다.
Claude Sonnet 4.5 모델은 200k Context window를 제공하지만, 실제 프로덕션 환경의 복잡한 작업은 이 한계를 쉽게 초과합니다. 예를 들어 “판매 데이터를 분석해서 DOCX 리포트를 만들어줘” 라는 단순해 보이는 요청도 실제로는 데이터 로드와 탐색(5분) -> 카테고리별 매출 분석(3분) -> 시계열 분석 및 차트 5개 생성(10분) -> 통계 검사 검증(3분) -> 최종 리포트 생성(5분)으로 이어질 수 있으며, 총 15분 동안 150K 토큰 이상을 소비할 수 있습니다. 이런 작업을 단일 Context에서 처리하면 여러 문제가 발생합니다. Context window가 초과되어 중간에 실패하거나, 오래된 Context로 인해 성능이