도구 호출과 추론 오케스트레이션만으로는 Agentic AI를 프로덕션에 올리기 어렵습니다. 이 글에서는 멀티 에이전트 시스템 Deep Insight 사례를 통해 **하네스 엔지니어링(harness engineering)**이 무엇이고, 격리·보안·운영성을 어떻게 설계하며, 그 과정에서 피하기 어려운 AWS 벤더락인 트레이드오프를 어떻게 바라봐야 하는지 정리합니다.
하네스 엔지니어링이란: “에이전트의 행동을 제어·검증·안전 실행”하는 프로덕션 장치
에이전트 시스템을 만들 때 보통은 프롬프트, 플래너, 툴 선택, 멀티 에이전트 협업 같은 “지능”에 집중합니다. 그런데 프로덕션에서는 더 큰 문제가 생깁니다.
- 누가 어떤 데이터에 접근할 수 있는가?
- 세션이 길게 유지될 때 다른 테넌트와 어떻게 격리되는가?
- 어떤 실행이 언제/누구에 의해 발생했는지 감사(audit) 가능한가?
- 실패/타임아웃/재시도는 어떻게 제어되는가?
- 비용은 예측 가능한가?
여기서 말하는 **하네스(harness)**는 이런 문제를 해결하기 위한 규칙과 환경의 묶음입니다. 즉, 에이전트가 도구를 마음대로 휘두르지 못하도록 **권한·컨텍스트·실행환경·관측성(로그/메트릭/트레이스)**을 통해 행동을 “안전하게” 제한하고 검증하는 장치입니다. 같은 모델을 써도 하네스 설계에 따라 성능(정확도보다도 성공률/재현성), 안정성, 보안 수준이 크게 갈립니다.
Deep Insight 사례: CSV 질문 → DOCX 리포트를 만드는 멀티 에이전트
원문 사례의 Deep Insight는 다음과 같은 “현실적인” 요구조건을 가진 시스템입니다.
- 사용자가 CSV 기반으로 분석 질문을 던지면,
- 여러 에이전트가 분석/요약/리포트 작성 작업을 분담하고,
- 최종 결과물을 DOCX 리포트로 생성합니다.
이때 프로덕션에서 특히 문제가 되는 조건이 같이 붙습니다.
- 장기 실행(long-running): 작업이 길어질 수 있음
- 멀티테넌트(multi-tenant): 여러 고객/조직이 동시에 사용
- 민감 데이터(sensitive data): 네트워크/격리/감사가 중요
이런 조건에서는 “모델이 잘 맞히는가?”만큼이나 “세션과 데이터가 안전하게 분리되고, 운영/감사 가능한가?”가 핵심이 됩니다.
Deep Insight가 강조하는 프로덕션 하네스의 핵심: 격리·세션·비용·네트워크
Deep Insight는 이런 요구를 만족하기 위해 Amazon Bedrock AgentCore Runtime을 선택하면서, 설계 근거를 비교적 명확하게 제시합니다.
1) microVM 기반 세션 격리
멀티테넌트 환경에서는 “컨테이너 하나로 여러 세션을 처리”하는 순간부터 테넌트 간 격리가 난제가 됩니다. Deep Insight는 microVM 기반 격리를 전면에 둡니다.
- 장점: 강한 격리 경계(“옆 테넌트가 내 프로세스/메모리에 영향을 줄 수 있나?” 같은 질문에 더 단단한 답)
- 의미: 하네스가 단순히 소프트웨어 레벨 정책이 아니라, 실행 경계 자체를 포함한다는 점
2) 최대 8시간 세션 같은 장기 실행 지원
리포트 생성/분석 파이프라인은 길게 늘어지기 쉽습니다. 세션이 짧으면 중간 상태 관리(체크포인트/재개) 비용이 급증합니다.
- 장점: 장기 실행을 런타임이 자연스럽게 수용 → 애플리케이션 복잡도 감소
- 주의: 이런 “세션 모델”은 특정 런타임 특성에 의존하기 쉬움(이식성 이슈로 연결)
3) Active CPU 과금 + 오토스케일
에이전트 워크로드는 트래픽이 들쭉날쭉하고, 사용자별 작업 시간이 크게 다릅니다. Deep Insight는 Active CPU 기반 과금과 오토스케일을 근거로 듭니다.
- 장점: 유휴 시간 비용을 줄이고(적어도 의도는), 운영 부담을 낮춤
- 관점: 비용 모델도 하네스 설계의 일부입니다. “싸게 돌리는 법”이 아니라 “예측 가능한 비용 경계”를 만드는 문제입니다.
4) VPC 모드 + PrivateLink 기반 네트워크 격리
민감 데이터가 오가면 네트워크 경로가 곧 컴플라이언스 이슈가 됩니다. Deep Insight는 VPC 모드와 PrivateLink로 네트워크를 격리합니다.
- 장점: 퍼블릭 인터넷을 피하고 사설 경로로 통신 경계를 설계
- 의미: 하네스는 “에이전트가 무엇을 할 수 있는지”뿐 아니라 “어디로 나갈 수 있는지(egress)”도 통제해야 합니다.
벤더락인 질문에 대한 결론: “AWS 의존이 없나?”가 아니라 “무엇에 락인되나?”를 쪼개야 합니다
대화에서 가장 현실적인 우려는 벤더락인이었습니다. 제 경험상 이 질문은 “AWS를 쓰면 락인” 같은 단순 결론보다, 의존을 두 층으로 나누는 순간 해법이 보입니다.
(1) 모델/에이전트 API 락인 (상대적으로 완화 가능)
- Bedrock/AgentCore 같은 API에 애플리케이션이 강하게 결합되면 교체가 어렵습니다.
- 다만 이 층은 보통 추상화로 완화 여지가 있습니다(예:
LLMClient,ToolExecutor같은 내부 인터페이스로 감싸기).
(2) 런타임/보안 경계/운영 특성 락인 (완화가 훨씬 어려움)
- microVM 격리, PrivateLink, 세션 모델, 과금/오토스케일 같은 특성은 “유사 구현”은 가능해도 동일한 운영 경험을 복제하기 어렵습니다.
- 즉, 문제는 “코드 이식성”이 아니라 운영 설계의 재구축 비용입니다.
“둘 다 오픈소스로 대체”는 가능하지만, 컴플라이언스·비용 우려라면 역설이 생깁니다
대화에서 “모델도, 런타임도 오픈소스로 바꾸고 싶다”는 요구가 나왔고, 동시에 “컴플라이언스와 비용이 가장 걱정”이라는 조건이 붙었습니다. 여기서 역설이 생깁니다.
- 오픈소스로 갈수록 비용은 라이선스가 아니라 **GPU 상시 점유, SRE/보안 인력, 감사 증적 구축(접근통제/키관리/로그 보존)**으로 이동합니다.
- 컴플라이언스도 관리형 경계를 벗어나면 통제 설계와 증빙 책임이 팀으로 넘어옵니다.
그래서 현실적인 접근은 보통 “전면 탈출”이 아니라 교체 지점(escape hatch)을 아키텍처에 남기는 것입니다. 예를 들어:
- 모델 레이어부터 교체 가능하게(상대적으로 쉬움)
- 네트워크/키관리/감사 로그는 표준 인터페이스로 감싸고(하지만 운영 책임은 커짐)
- 런타임 격리는 “정말 필요한 수준”을 컴플라이언스 요구사항으로부터 역산해서 결정
인사이트: 프로덕션 Agentic AI의 1순위는 “추론 성능 vs 격리/보안/운영성”이 아니라 “감사 가능한 통제”입니다
처음 열린 질문은 “추론 성능과 격리·보안·운영성 중 무엇이 우선인가?”였는데, Deep Insight 같은 사례를 보면 실제 1순위는 대개 이렇습니다.
- 컴플라이언스/감사에서 요구하는 통제 항목을 만족하는가
- 데이터 경로(네트워크), 접근 제어, 암호화/키관리, 로그/보존, 테넌트 격리, 운영 변경 이력 등
이 통제 항목을 만족시키는 방식이
- 관리형(AWS)로 빠르게 확보되는지,
- 오픈소스로 직접 구축 가능한지,
- 그리고 그때의 비용이 “클라우드 비용”에서 “인력/운영비”로 얼마나 이동하는지
이게 설계의 핵심 축이 됩니다. 저는 벤더락인을 무조건 피하기보다, “언젠가 나갈 수 있는 구조(인터페이스/데이터/관측성의 표준화)”를 남기되, 당장 컴플라이언스를 만족시키는 경계는 관리형으로 가져가는 전략이 가장 현실적인 출발점인 경우를 자주 봤습니다.
마무리
Deep Insight 사례가 말해주는 메시지는 간단합니다. Agentic AI를 프로덕션에 올리는 경쟁력은 “추론을 잘한다”보다 “하네스로 안전하게 운영된다”에서 갈리는 경우가 많습니다. 특히 컴플라이언스와 비용이 걱정이라면, 오픈소스 전환은 만능 해법이 아니라 책임과 비용의 형태가 바뀌는 선택이라는 점부터 명확히 하고 접근하는 게 좋습니다.