AI에게 단순히 “잘 해봐”라고 시키는 것과, AI가 스스로 만들고 평가하고 개선하는 Agentic 시스템을 설계하는 건 완전히 다른 결과물을 만들어냅니다. AWS Korea SA Team은 Agentic AI 시스템을 개발할 때 마주하는 다양한 기술적 챌린지들을 직접 풀기 위해 ‘Deep Insight’, 사용자가 업로드한 CSV 데이터와 분석 질문을 받아 최종 DOCX 리포트를 생성하는 프로덕션 Multi-Agent 시스템을 개발했고, 세 편의 블로그 […] ||
AI에게 단순히 “잘 해봐”라고 시키는 것과, AI가 스스로 만들고 평가하고 개선하는 Agentic 시스템을 설계하는 건 완전히 다른 결과물을 만들어냅니다. AWS Korea SA Team은 Agentic AI 시스템을 개발할 때 마주하는 다양한 기술적 챌린지들을 직접 풀기 위해 ‘Deep Insight’, 사용자가 업로드한 CSV 데이터와 분석 질문을 받아 최종 DOCX 리포트를 생성하는 프로덕션 Multi-Agent 시스템을 개발했고, 세 편의 블로그 시리즈를 연재하며 Deep Insight 개발 여정에서 직접 경험하고 해결한 내용을 공유하고 있습니다.
앞선 Part 2에서 소개한 Context Engineering 기법으로 에이전트 로직을 효율적으로 구현하는 데 성공했다면, 이제 이 에이전트가 장기간동안 안정적으로 작업할 수 있는 환경을 만들어야 합니다. 이번 블로그에서는 Deep Insight가 이러한 문제들을 해결하기 위해 하네스 엔지니어링 (Harness Engineering) 관점에서 어떤 설계 결정을 내렸는지, 그리고 로컬 개발 환경에서 시작해 AWS 프로덕션 인프라로 전환하기까지의 여정을 공유합니다.
[시리즈 블로그 보기]
Part 1: Deep Insight란 무엇인가? – 프로덕션급 Multi-Agent 시스템의 필요성과 아키텍처
Part 2: Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법
Part 3: 하네스 엔지니어링으로 본 Deep Insight – 로컬 개발에서 프로덕션 운영까지의 설계 여정
시작하며
하네스 엔지니어링이 무엇이고 Deep Insight가 이를 어떻게 구현했는지를 설명하기 전에, 이러한 개념이 등장한 배경을 되짚어보겠습니다.
2024년 하반기부터 2026년 상반기까지는 AI 에이전트가 PoC 단계를 넘어 프로덕션 배포의 현실적 과제와 정면으로 마주한 시기입니다. Gartner는 2028년까지 기업용 소프트웨어의 33%가 Agentic AI를 포함하고, 일상 업무 의사결정의 15%가 에이전트에 의해 자율적으로 이루어질 것으로 전망했습니다. 학계와 산업계의 논의도 빠르게 축적되었습니다. Anthropic의 ‘Building Effective Agents‘가 7가지 설계 패턴을 제시했고, Model Context Protocol (MCP) 및 Agent-to-Agent (A2A)와 같은 상호운용성 표준도 이 시기에 자리잡았습니다. 그러나 이러한 논의의 초점은 대부분 에이전트의 추론과 오케스트레이션에 머물렀고, 에이전트가 프로덕션에서 안정적으로 동작하기 위한 인프라 설계와 운영 엔지니어링은 상대적으로 공백으로 남아 있었습니다.
하네스 (Harness)라는 용어 자체는 소프트웨어 테스팅 분야에서 오랫동안 사용되어 왔습니다. 기존 개념에서의 하네스는 컴포넌트 실행을 제어하고 결과를 검증하는 프레임워크를 지칭했지만, AI 에이전트 시대에 들어서면서 하네스가 다뤄야 할 범위가 크게 넓어졌습니다. 에이전트는 매번 다른 경로로 추론하고 (즉 “비결정론적”이고), 한 번에 수십 분씩 장기 세션으로 실행되며, 자율적으로 외부 도구를 호출하고, 여러 사용자의 작업을 동시에 격리하여 처리해야 합니다. 기존 소프트웨어와는 질적으로 다른 이 요구사항들 때문에, 하네스 엔지니어링은 2026년에 들어서야 독립적인 엔지니어링 분야로 비로소 조명받기 시작했습니다. 이러한 배경에서, 학계에서도 관련 연구가 이어지고 있습니다