AWS Deep Insight 하네스 엔지니어링 케이스 스터디 — 3 가지 인프라 결정의 통합 분석

31번 동심원 모델·30번 Trade-off·32번 Cross-cutting·33번 산업 카탈로그가 한 시스템에서 통합 구현된 사례

AWS Korea SA Team 이 2026 년 4 월 공개한 Deep Insight (사용자 CSV → DOCX 분석 리포트 Multi-Agent 시스템) 의 하네스 엔지니어링 설계를 단일 케이스로 심층 분석한다. AgentCore Runtime + Fargate 분리, S3 중간 저장소, VPC + Security Group 다층 격리라는 3 가지 설계 결정을 31번 동심원 모델·30번 trade-off·32번 cross-cutting concern·33번 산업 카탈로그와 매핑하고, 22.5 분 실측 세션·1세션 ~$4.13 비용·인젝션 84.30% 위협 통계로 사례를 검증한다. 출처는 AWS 공식 기술 블로그 Part 3 단독이며 Part 1·2 는 향후 보강 예정.

Agent
Architecture
Engineering
저자

Kwangmin Kim

공개

2026년 04월 28일

1 이 글의 위치와 출처

이 글은 24-Agent-Architecture 시리즈의 다섯 번째 하네스 분석 이다. 앞선 네 글을 짧게 짚고 이 글의 차이를 명시한다.

번호 주제 자료 성격
31번 Prompt · Context · Harness 세 층위 정의 학술 정의
30번 Claude Code vs Copilot CLI 5 대 축 비교 본인 통제 실험
32번 AGENT_GUIDE 체계 3 층 해부, Cross-cutting Concern 자체 체계 분석
33번 산업 사례 카탈로그 (OpenAI Project 1M, Anthropic 분리, 동료 스킬, 누비다) 저널리즘 2 차 자료
34번 (이 글) AWS Deep Insight 단일 케이스 심층 분석 공식 1 차 자료 + 코드 + 실측

이 글의 핵심 차이는 자료 성격 이다. 33번이 미라클레터 1010 호를 출처로 한 산업 동향 스냅샷이라면, 이 글은 AWS 공식 기술 블로그(2026.4.22 발행) 의 Part 3 를 출처로 하며 실제 시스템의 코드·다이어그램·실측 세션·비용 breakdown 을 1 차 자료로 갖는다.

출처와 범위 명시
  • 1 차 자료: AWS 공식 기술 블로그 “하네스 엔지니어링으로 본 Deep Insight – 로컬 개발에서 프로덕션 운영까지의 설계 여정” (Yoonseo Kim, Jesam Kim, Jiyun Park, Kyutae Park, Gonsoo Moon, 곽영화 / 2026.4.22 / Amazon Bedrock AgentCore, AWS Fargate)
  • 시리즈 위치: AWS 가 공개한 3 부작 중 Part 3 (인프라/하네스) 단독 분석
  • 미참조 영역: Part 1 (시스템 아키텍처 개요) 과 Part 2 (Context Engineering 기법 — Note- taking, 파일 외부화, Skills, Prompt Caching, Validator/Tracker) 의 원문은 본 글 작성 시점에 미확인 상태이다. Part 3 본문이 두 글의 핵심 결과를 짧게 요약·인용하므로 간접 참조 만 가능하며, 깊이 있는 분석은 추후 Part 1·2 입수 시 35·36 번 포스트로 별도 작성 예정
  • 이 글의 단언 범위: Part 3 본문에 명시된 인프라 결정 3 가지에 한정한다. Part 1·2 의 세부 메커니즘(예: Note-taking 의 구체 알고리즘) 은 일반화된 표현으로만 다룬다

2 왜 이 케이스가 중요한가

33번에서 정리한 산업 사례들(OpenAI Project 1M, Anthropic 가축 모델, 누비다 3 AI 분리) 은 저널리즘 보도가 출처라 검증 가능한 1 차 자료 가 부족했다. AWS Deep Insight 사례는 그 공백을 메운다.

2.1 검증 가능성의 차이

비교 항목 미라클레터 보도 사례 AWS Deep Insight
출처 형태 매경미디어 1010 호 보도 AWS 공식 기술 블로그
코드 공개 없음 GitHub (managed-agentcore) 공개
다이어그램 비주얼 일러스트 4 개 공식 아키텍처 다이어그램
비용 데이터 없음 1 세션 ~$4.13, 항목별 % breakdown
실측 세션 없음 22.5 분 / 79 Fargate 실행 / 1.3 MB DOCX 산출물
검증 도구 없음 샘플 DOCX, GitHub 코드 직접 다운로드 가능

이 차이는 결론의 재현성 에 직결된다. 33번에서 “OpenAI Project 1M 의 100 만 줄·버그 40% 감소” 같은 수치는 보도 의존이라 외부 검증이 어려웠다. AWS 사례는 코드와 인프라가 공개돼 있어 같은 패턴을 다른 조직이 그대로 도입·검증할 수 있다.

2.2 시리즈 관점의 의의

이 케이스 하나에서 31~33번에서 다룬 모든 핵심 개념이 통합 구현 된다.

개념 출처 포스트 AWS Deep Insight 의 구현
Harness 정의 (“LLM 제외 모든 것”) 31번 동일 정의 명시
동심원 포함 관계 31번 Harness(인프라) → Context(S3) → Prompt(에이전트 지시) 분리 가시화
Tool result lifecycle 30번 stderr 를 그대로 LLM 에 반환하는 패턴
Auto-compaction trade-off 30번 Context 외부화(S3) 로 우회
Harness-aware Context Engineering 32번 S3 기반 외부 메모리가 인프라 차원의 같은 패턴
Anthropic 하네스/세션/샌드박스 분리 33번 AgentCore + ALB sticky + Fargate 로 1:1 매핑
누비다 3 AI 분리 33번 Planner/Coder/Validator/Reporter 로 더 세분화
OpenAI 7 가지 도구 33번 Bedrock Guardrails / Validator / CloudWatch / microVM / S3 로 매핑

즉 이 글은 31~33번의 사후 검증 사례 다.

3 Deep Insight 시스템 개요

AWS Korea SA Team 이 자체 구축한 프로덕션 Multi-Agent 시스템이다. 이 케이스의 인프라 결정을 이해하려면 시스템의 윤곽이 필요하다.

3.1 입출력

항목 내용
입력 사용자가 업로드한 CSV 데이터 + 분석 질문
출력 1.3 MB DOCX 분석 리포트 (인용 번호 포함)
시간 규모 데이터 복잡도에 따라 수분 ~ 30 분 이상

3.2 Multi-Agent 구성

Part 3 본문에 등장하는 에이전트 역할은 다음과 같다 (Part 1 의 상세 아키텍처는 미참조).

에이전트 역할
Planner 사용자 질문 분석 → 단계별 계획 생성
Plan Reviewer 계획을 사용자에게 검토 받음 (HITL)
Supervisor 계획 승인 후 실행 조율
Coder Python 분석 코드 생성 + 실행
Validator 결과 검증 + 실패 시 자체 복구
Reporter 최종 DOCX 리포트 작성

3.3 Part 3 가 다루는 문제

Part 1 이 시스템 개요, Part 2 가 Context Engineering 이라면 Part 3 는 다음 4 가지 문제를 다룬다.

  1. 에이전트가 생성한 코드를 어디서 실행할 것인가
  2. 도구 실행이 너무 길어지면 Agent 인프라 안에서 비효율적이지 않은가
  3. 에이전트가 30 분 동안 잘못된 방향으로 가면 어떻게 개입하나
  4. 중요한 데이터를 다루는 시스템을 인터넷에 노출시키지 않으려면 어떻게 하나

이 네 질문에 대한 답이 다음의 세 가지 결정이다.

4 AWS 의 하네스 정의 — 31번 모델과의 비교

Part 3 본문은 하네스를 다음과 같이 정의한다.

“AI 에이전트 맥락에서 하네스란, 에이전트가 실행되는 제어 환경과 규칙 모음을 말한다. 말 그대로 ‘마구(馬具)’ 처럼 에이전트의 행동을 묶고, 방향을 잡고, 안전하게 제어하는 구조다. (…) 하네스 엔지니어링의 범위는 에이전트 시스템에서 LLM 모델 자체를 제외한 거의 모든 것에 걸쳐 있다.”

4.1 31번 정의와의 비교

비교 축 31번 (이 블로그) AWS Deep Insight
한 줄 정의 “모델·도구·맥락을 관리하는 시스템” “에이전트가 실행되는 제어 환경과 규칙 모음”
범위 모델과 사용자 사이의 미들웨어 LLM 모델 자체를 제외한 거의 모든 것
구체 활동 Tool loop, auto-compaction, lifecycle, skill 로딩, protected zone 도구 목록·권한, Context 범위, 실행 환경, 로깅·모니터링
비유 동심원의 가장 바깥 층 마구(harness) — 행동을 묶고 방향을 잡는 구조

두 정의는 본질적으로 동일 하다. AWS 의 정의가 약간 더 광범위 (모델 자체만 제외) 한 점이 다르지만, 31번에서 “Context · Prompt 를 둘러싸는 바깥 층” 이라고 한 동심원 구조를 그대로 허용한다.

4.2 미세 차이의 시사점

AWS 정의에서 “LLM 모델 자체를 제외” 라는 명시는 31번에서 미처 다루지 않은 부분을 보강한다. 31번 동심원에는 모델 가중치가 포함되지 않았는데(33번 결론에서 5 층으로 확장 제안), AWS 는 모델은 명시적 제외 영역 으로 둔다. 즉 산업 표준 관점에서 보면:

  • 모델 가중치 (벤더 책임) — 별도 영역
  • 그 외 모든 것 (사용자/조직 책임) — 하네스 영역

이 명시적 분리는 책임 경계의 명확화 차원에서 31번 정의를 다듬을 가치가 있다. 33번에서 제안한 5 층 모델 (Orchestration ⊃ Harness ⊃ Context ⊃ Prompt ⊃ Model Weights) 의 맨 안쪽 “Model Weights” 가 사용자가 파인튜닝으로 건드리는 동료 스킬 같은 사례이긴 하지만, 표준 케이스 에서는 AWS 정의처럼 모델은 하네스 외부로 두는 것이 합리적이다.

5 Decision 1: 코드 실행 환경의 완전한 분리

5.1 출발 — 단순 구조의 한계

Deep Insight 의 Coder 에이전트는 데이터 분석에 필요한 Python 코드를 생성한 뒤 write_and_execute_tool 을 호출하여 실행한다. 로컬 개발(Self-Hosted) 단계의 구현은 단순했다.

# Self-Hosted 방식 — 한 줄짜리 단순 실행
with open(file_path, 'w', encoding='utf-8') as f:
    f.write(content)

subprocess.run(
    f"python {file_path}",
    shell=True,
    capture_output=True,
    timeout=300
)

EC2 단일 self-hosted 모드에서는 이 구조가 잘 작동했다. 그러나 여러 분석 요청을 동시에 보내자 한 건만 성공하고 나머지가 줄줄이 실패했다. 원인은 에이전트 추론과 코드 실행이 같은 Runtime 안에서 자원을 다투는 것이었다. 이 실패가 분리 결정의 출발점이다.

5.2 분리하지 않으면 안 되는 3 가지 이유

이유 내용
보안 위험 LLM 생성 코드를 Runtime 내부 실행 시 악성코드·무한루프가 같은 세션 에이전트 로직에 영향
워크로드 특성 불일치 AgentCore Runtime 은 I/O-wait 지배적, CPU-heavy 분석은 이 최적화를 살리지 못함
확장성 한계 Runtime 과 코드 실행이 묶이면 컴포넌트별 독립 스케일링 불가

결론은 명확했다. 코드 생성은 LLM 추론이 필요한 작업이므로 AgentCore Runtime 에서 수행하고, 코드 실행은 단순 compute 작업이므로 별도 환경에서 수행한다.

5.3 AgentCore Runtime 의 4 가지 특징

분리한 Runtime 자체의 선택 근거는 다음과 같다.

특징 의미
microVM 기반 세션 격리 사용자 세션마다 독립 microVM, 커널 수준 격리. 멀티테넌트 환경에서 데이터 보호 필수
장기 실행 지원 세션당 최대 8 시간, 멀티턴 워크플로우에 적합
Active CPU 기반 과금 LLM 응답 / 도구 결과 대기 중 (실행 시간의 30~70% I/O) 에는 과금 없음, 자동 스케일링
VPC 모드 + PrivateLink 고객 VPC 내부 Private Subnet 배치 가능, AWS 백본 네트워크 내부 통신

5.4 Custom Code Interpreter — 왜 Fargate 인가

코드 실행 환경 후보 3 가지를 비교한다.

옵션 장점 단점
EC2 유연한 환경 구성 스케일링 / 패치 관리 부담
Lambda 서버리스 간편함 실행 시간 15 분 제한, 긴 데이터 분석 부적합
AWS Fargate 서버 관리 부담 없음, 시간 제한 없음 (Deep Insight 에 가장 적합)

Fargate 선택의 또 다른 핵심 이유는 실행 환경의 자유도 다. 관리형 Sandbox (Bedrock AgentCore Code Interpreter 등) 는 편리하지만 세션마다 환경이 초기화돼, 한국어 데이터 분석에서 matplotlib 한글 폰트를 매번 재설정해야 한다. Dockerfile 로 패키징하면 build-time 에 자유롭게 의존성을 추가할 수 있고, ECR 의 단일 이미지로 모든 Fargate Task 가 동일 환경을 보장한다.

# managed-agentcore/fargate-runtime/Dockerfile (발췌)
FROM python:3.12-slim
WORKDIR /app

RUN apt-get update && apt-get install -y \
    fonts-nanum \
    fontconfig \
    pandoc \
    texlive-xetex \
    poppler-utils \
    && rm -rf /var/lib/apt/lists/*

# 폰트 캐시 갱신 (matplotlib 이 한글 폰트를 인식)
RUN fc-cache -f -v

fc-cache 로 폰트 캐시를 빌드 타임에 갱신하고, matplotlib.font_manager 캐시까지 미리 만들어 두면 컨테이너가 뜬 직후 첫 차트를 그릴 때 폰트 스캔 지연이 사라진다. 관리형 sandbox 였다면 이런 build-time 최적화 자체가 불가능했다.

5.5 2 단계 코드 실행 — Base64 인코딩의 이유

Self-Hosted 의 한 줄 subprocess.run 이 Fargate 로 옮기는 순간 추가 복잡도를 마주한다. LLM 생성 코드에 특수문자·한글·shell escape 가 필요한 따옴표가 섞이는데, 이를 ALB 를 거쳐 HTTP → 컨테이너 내부 → bash 경로로 흘려보내면 각 레이어의 해석 규칙이 충돌한다.

해결: 2 단계 분리 다.

1 단계 — 파일 쓰기 (in-process, subprocess 없음)

content_b64 = base64.b64encode(content.encode('utf-8')).decode('ascii')
write_code = f'''
import base64, os
file_path = "{file_path}"
os.makedirs(os.path.dirname(file_path), exist_ok=True)
content = base64.b64decode("{content_b64}").decode('utf-8')
with open(file_path, 'w', encoding='utf-8') as f:
    f.write(content)
'''
session_manager.execute_code(write_code, f"Write: {file_path}")

원본 코드를 Base64 로 인코딩해 ASCII 안전 영역으로 옮긴 뒤 컨테이너에서 복원·저장한다. subprocess 를 띄우지 않으므로 GIL 영향이 없고 수 밀리초 안에 끝난다.

2 단계 — 파일 실행 (subprocess + timeout)

if timeout and timeout > 30:
    bash_code = f"BASH: timeout {timeout} {execute_cmd}"
else:
    bash_code = f"BASH: {execute_cmd}"
session_manager.execute_code(bash_code, f"Execute: {execute_cmd}")

BASH: prefix 로 실행 경로를 구분하고, timeout 유틸리티로 강제 종료 시간을 지정한다. 무한루프나 장시간 실행 코드도 상위 Runtime 에 영향을 주지 않고 정리된다.

이 2 단계 구조의 핵심은 “파일 쓰기” 와 “코드 실행” 의 문제를 격리 하는 것이다.

  • 쓰기 단계의 escape 문제 → Base64 로 우회
  • 실행 단계의 무한루프 / 런타임 오류 → timeout 으로 격리

에이전트 입장에서는 여전히 write_and_execute_tool(file_path, content) 한 번의 호출이지만, 하네스가 LLM 코드의 불확정성을 안전하게 흡수한다.

5.6 ALB Sticky Session — 세션 연속성의 인프라적 보장

AgentCore Runtime 과 Fargate 사이에는 ALB (Application Load Balancer) 가 위치한다. ALB 의 역할은 단순 로드밸런싱 이상이다.

역할 설명
요청 분배 동시 분석 요청을 서로 다른 Fargate Task 로 분배
Health Check 게이트 Fargate Task 가 완전히 준비된 후에만 트래픽 라우팅
Sticky Session 같은 분석 세션의 후속 요청을 동일한 Fargate Task 로 라우팅

Sticky Session 이 핵심이다. 데이터 분석은 여러 차례 코드 실행을 거치는데, 이전 실행에서 생성한 중간 파일이나 로드한 dataframe 이 같은 컨테이너에 남아 있어야 다음 단계를 이어갈 수 있다. 실측 세션에서 이 효과가 가시화된다(뒤의 운영 실측 섹션 참조).

5.7 31번·30번·33번 모델과의 매핑

모델 매핑 결과
31번 동심원 Harness 의 Tool loop 정책이 ALB + Fargate + Sticky Session 인프라로 구현
30번 trade-off “잊음” 약점 → Fargate 컨테이너 내부 .pkl 캐시 + S3 외부화로 해결. “무거움” → 추론과 실행의 워크로드 분리로 비용 분산
33번 Anthropic 분리 하네스(판단)=AgentCore Runtime / 세션(기록)=ALB sticky+S3 / 샌드박스(실행)=Fargate. 3 분할이 정확히 일치
33번 누비다 3 AI Coder + Validator + Reporter 가 같은 인프라 위에서 분리 운영 — 더 세분화된 형태

특히 Anthropic 의 반려동물(Pet) vs 가축(Cattle) 비유에서 가축 모델이 정확히 이 구조다. Fargate 한 컨테이너가 망가져도 ALB 가 다른 Task 로 라우팅하고, AgentCore Runtime 의 microVM 이 끝나면 메모리도 초기화된다.

6 Decision 2: S3 를 중간 저장소로 활용하기

6.1 분산 시스템이 된 결과

Decision 1 을 거치면서 Deep Insight 는 이미 분산 시스템이 되었다. AgentCore Runtime 과 Fargate 사이에 데이터를 주고받아야 하고, Part 2 의 파일 기반 Note-taking 도 로컬이 아닌 프로덕션에서 동작해야 한다. 두 가지 모두 해결할 중간 저장소로 S3 가 선택된다.

6.2 S3 선택 근거

근거 의미
일레븐 나인 내구성 99.999999999% 데이터 영속성
무제한 확장성 파일 크기·개수 제한 없음
VPC Endpoint 접근 Private Network 만으로 통신 가능
저렴한 비용 (실측에서 확인)
PUT/GET 단순성 인터페이스 표준화

6.3 세션별 격리 구조

S3 의 prefix 구조로 세션 격리가 자연스럽게 따라온다.

s3://bucket/deep-insight/fargate_sessions/{session_id}/
├── input/                       # 사용자가 업로드한 원본 데이터
│   └── data.csv
├── artifacts/                   # 에이전트가 생성한 분석 산출물
│   ├── all_results.txt          # 단계별 결과 누적 (Reporter 참조용)
│   ├── citations.json           # 그래프/표 참조 정보 (Validator 생성)
│   ├── [chart PNG 파일들]
│   └── [전처리된 CSV 등]
├── debug/                       # 실행별 로그
│   ├── session_status.json
│   └── execution_{1..N}.json
└── output/                      # 세션 메타데이터
    ├── token_usage.json         # 에이전트별 토큰 집계
    └── token_usage.txt          # 사람 읽기용 요약

각 세션에 고유한 session_id 를 부여하고 해당 prefix 아래 모든 파일을 저장하면 세션 간 데이터 충돌 없이 독립적인 클린업과 디버깅이 가능하다. 로컬에서는 새 분석을 시작하면 이전 결과가 덮어써졌지만, 프로덕션에서는 모든 세션의 결과를 timestamp 별로 보관하므로 과거 분석의 비교·감사 추적·재현이 모두 가능 해진다.

6.4 3 가지 용도

S3 는 단일 저장소가 아닌 분산 시스템의 데이터 허브 로 작동한다.

6.4.1 용도 1 — Fargate 실행 결과물 보존

Fargate 컨테이너는 세션 종료 시 삭제되므로, 세션 동안 생성된 모든 산출물 (matplotlib 그래프, 전처리된 CSV/Parquet, 요약 통계 등) 을 S3 로 일괄 업로드한다. 사용자가 이후 다운로드하거나 다음 세션에서 참조할 수 있는 영속적 아카이브 가 된다.

6.4.2 용도 2 — Context 외부화 (Note-taking 의 인프라 구현)

Part 2 의 Note-taking 기법은 파일 기반 Context 외부화다. 에이전트가 생성하는 정보를 모두 Context 에 담으면 금방 한계에 도달하므로, 중요 정보를 artifacts/ 의 파일로 저장하고 필요할 때만 읽어온다. 이 파일들이 사실상 에이전트의 외부 메모리 역할을 한다.

파일 역할
all_results.txt 각 분석 단계마다 결과 누적 → Validator 검증·Reporter 작성 시 참조
citations.json 생성된 그래프·표 위치 → Reporter 가 리포트 이미지 삽입 시 사용

Context 에는 “5 단계 완료, 상세는 all_results.txt 참조” 정도만 유지하면 된다. Context 는 가볍게, 정보는 S3 에 풍부하게 보관하는 구조다.

6.4.3 용도 3 — Human-in-the-loop 피드백 (스트리밍 한계 우회)

AgentCore Runtime 은 스트리밍 아키텍처라서 사용자에게 이벤트를 보낼 수는 있지만 사용자로부터 직접 입력을 받을 수는 없다. 이 제약을 S3 를 사이드 채널로 사용 하여 우회한다.

전체 흐름:

  1. Planner 가 사용자 질문 → 단계별 계획 생성
  2. Plan Reviewer 가 plan_review_request 스트리밍 이벤트로 클라이언트 전송 (피드백 업로드 S3 key 도 함께 전송)
  3. 사용자 (Web UI) 가 계획 검토 후 피드백 JSON 작성. 예: {"approved": true} 또는 {"approved": false, "feedback": "3 단계를 더 자세히 나눠줘"}
  4. Web UI 가 이 JSON 을 s3://{bucket}/deep-insight/feedback/{request_id}.json 에 업로드
  5. Plan Reviewer 가 최대 5 분간 (PLAN_FEEDBACK_TIMEOUT=300) S3 key 를 3 초 간격 polling
  6. 동시에 약 6 초마다 plan_review_keepalive 이벤트 전송으로 SSE 연결 유지
  7. 피드백 발견 → JSON 처리 → S3 파일 삭제 (재처리 방지)
  8. approved=true → Supervisor 진행 / approved=false → Planner 로 되돌아가 계획 재작성 (최대 10 회, MAX_PLAN_REVISIONS=10)
  9. 5 분 안에 피드백이 안 오면 auto-approve 로 Supervisor 진행

핵심 패턴은 다음 polling 루프다.

# managed-agentcore/src/graph/nodes.py::plan_reviewer_node (핵심 발췌)

# Step 1: 계획을 스트리밍 이벤트로 클라이언트에 전송
put_event({
    "type": "plan_review_request",
    "plan": full_plan,
    "feedback_s3_path": f"s3://{s3_bucket}/{get_s3_feedback_key(request_id)}",
})

# Step 2: S3 에서 피드백 파일이 나타날 때까지 polling
while (time.time() - start_time) < PLAN_FEEDBACK_TIMEOUT:  # 최대 5 분
    feedback_data = check_s3_feedback(request_id)
    if feedback_data:
        delete_s3_feedback(request_id)
        break

    # 스트리밍 연결 유지를 위한 keepalive 이벤트 주기적 전송
    if poll_count % 2 == 0:
        put_event({"type": "plan_review_keepalive"})

주목할 점은 polling 루프 안에 keepalive 이벤트 가 주기적으로 들어간다는 것이다. SSE 스트리밍 연결은 일정 시간 응답이 없으면 idle timeout 으로 끊기는데, 피드백을 기다리는 동안에도 연결이 살아있어야 사용자가 피드백 보낸 즉시 Plan Reviewer 가 반영할 수 있다. HITL 루프는 사실상 “사용자 입력 대기” 와 “스트리밍 연결 유지” 두 가지 일을 동시에 수행한다.

6.5 32번·31번 모델과의 매핑

모델 매핑 결과
31번 Context Engineering “외부 데이터 주입” 의 인프라 구현 — RAG 가 아닌 세션 내 외부 메모리 변형
32번 Harness-aware Context Engineering 정확히 이 패턴. Auto-compaction 을 의식해 응답이 아닌 외부 파일에 정보 보존
30번 Tool result lifecycle “한계 전까지 보존” (Copilot CLI) 패턴이 인프라 차원에서 강제됨
30번 hybrid workflow 탐색·생성은 Runtime 에서, 결과 보존은 S3 에서 — 인프라로 hybrid 가 분담됨

특히 32번에서 정의한 Harness-aware Context Engineering 패턴이 AWS 사례에서 어떻게 인프라 차원으로 격상되는지가 흥미롭다. 32번에서는 “모델 응답 자체를 정보 보존 매체로 활용” 했다면, AWS 는 그것을 한 단계 추상화해 S3 라는 별도 저장소로 외부화 했다. 인프라 차원의 외부화는 Context 윈도우와 완전히 무관해지므로, auto-compaction 이 일어나도 정보가 사라지지 않는 더 강력한 보장 을 얻는다.

7 Decision 3: 완전한 네트워크 격리

7.1 데이터 흐름의 위협 모델

Deep Insight 의 데이터 흐름 (사용자 CSV 업로드 → Bedrock 호출로 코드 생성 → Fargate 분석 → S3 저장) 이 퍼블릭 인터넷을 경유한다면 각 단계마다 데이터 유출 위험이 존재한다.

특히 Part 3 본문은 학술 연구를 인용하며 다음 통계를 제시한다.

“도구 환경에서 프롬프트 인젝션 공격의 평균 성공률은 84.30% 에 달한다.”

이 수치가 던지는 함의는 명확하다. 인젝션을 입력 단계에서 100% 차단하는 것은 현실적으로 불가능 하다. 따라서 하네스의 전략은 “인젝션을 막는다” 가 아니라 “인젝션이 성공하더라도 blast radius (피해 범위) 를 제한한다” 가 된다.

7.2 Private Subnet + VPC Endpoint 구조

Deep Insight 의 모든 워크로드 (AgentCore Runtime, Fargate Task, ALB) 는 인터넷 연결이 없는 Private Subnet 에 배치된다. Internet Gateway 로의 라우팅이 없으므로 워크로드가 인터넷에 직접 노출될 가능성 자체가 없다.

Private Subnet 에서 AWS 서비스에 접근하기 위해 VPC Endpoint 를 사용한다. AWS 백본 네트워크 내부에서만 데이터가 흐른다.

서비스 Endpoint 타입 Deep Insight 용도
Bedrock Interface LLM 추론 호출
AgentCore Runtime / Gateway Interface 에이전트 실행 및 API
ECR API / ECR Docker Interface Docker 이미지 관리 및 pull
CloudWatch Logs Interface 로그 전송
S3 Gateway 아카이브, HITL 피드백, Context 외부화

필요한 최소 아웃바운드를 위해 Public Subnet 에는 NAT Gateway 만 배치하고, 어떤 워크로드도 올리지 않는 2-Tier 구조다.

7.3 Security Group — “각 컴포넌트는 직전/직후만 통신”

네트워크 레벨 격리에 더해, Security Group 으로 컴포넌트 간 통신을 최소화한다. 핵심 원칙은 각 컴포넌트는 바로 앞뒤의 컴포넌트하고만 통신 한다는 것이다.

AgentCore Runtime → ALB → Fargate Task → VPC Endpoint → 타 AWS 서비스
Security Group 인바운드 허용 아웃바운드 허용
SG-AgentCore (Runtime 관리형 — 사용자 제어 밖) SG-ALB (HTTPS), SG-VPCEndpoint (HTTPS)
SG-ALB SG-AgentCore 만 SG-Fargate 만
SG-Fargate SG-ALB (8080 포트만) SG-VPCEndpoint (HTTPS 만)
SG-VPCEndpoint SG-Fargate + SG-AgentCore 만 (대상 AWS 서비스들)

설령 Fargate 컨테이너가 침해되더라도, 아웃바운드가 VPC Endpoint 로만 제한돼 인터넷으로 데이터 유출 경로가 없고, 다른 컴포넌트로의 횡적 이동도 보안 그룹이 차단한다.

7.4 AgentCore Runtime VPC 배치 코드

“모든 워크로드는 Private Subnet 에 배치된다” 는 원칙은 자동 적용되지 않는다. AgentCore Runtime 은 기본적으로 Amazon 관리 네트워크에서 실행되므로 VPC 모드를 명시적으로 활성화해야 한다.

# managed-agentcore/01_create_agentcore_runtime_vpc.py (발췌)

from bedrock_agentcore_starter_toolkit import Runtime
agentcore_runtime = Runtime()

# (1) VPC 모드로 Runtime 설정 — Private Subnet 배치, Security Group 지정
agentcore_runtime.configure(
    agent_name="deep_insight_runtime_vpc",
    entrypoint="agentcore_runtime.py",
    execution_role=execution_role_arn,
    region=AWS_REGION,
    vpc_enabled=True,
    vpc_subnets=[PRIVATE_SUBNET_1_ID],
    vpc_security_groups=[SG_AGENTCORE_ID],
)

# (2) 환경변수 — Runtime 이 Fargate 를 어떻게 스폰할지 + 에이전트별 모델 ID
envvars = {...}

이 짧은 코드에 두 가지 하네스 관점 설계가 담겨 있다.

설계 의미
vpc_enabled=True Runtime 의 네트워크 소속을 선언적으로 결정. Decision 3 의 Private Subnet + VPC Endpoint + Security Group 다층 격리가 비로소 실제 인프라와 연결됨
환경변수 외부화 에이전트별 모델 ID, Fargate 클러스터 주소, S3 버킷, ALB DNS 가 모두 배포 시점 주입. 재빌드 없는 운영 루프 — Planner 모델을 Sonnet → Opus 로 바꿀 때 코드 수정 없이 .env 만 수정해 재배포

“재빌드 없는 운영 루프” 는 프로덕션에서 모델 업그레이드와 파라미터 튜닝 비용을 크게 낮춘다.

7.5 Defense in Depth — 다층 방어

정리하면 Deep Insight 의 보안은 4 층 방어 (Defense in Depth) 구조다.

레이어 방어 수단 답하는 질문
네트워크 Private Subnet 으로 인터넷 노출 차단 “데이터가 인터넷을 경유하나요?”
서비스 VPC Endpoint 로 AWS 서비스 접근 한정 “AWS 서비스는 어떻게 호출되나요?”
애플리케이션 Security Group 으로 컴포넌트 간 통신 제한 “컨테이너가 침해되면 어떻게 되나요?”
권한 IAM Role 로 최소 권한만 부여 “누가 S3 에 접근할 수 있나요?”

어느 한 레이어가 뚫려도 다른 레이어가 방어한다.

7.6 Zero Trust 매핑

Part 3 본문은 에이전트 전용 Zero Trust 아키텍처 (학술 제안) 의 3 층 방어와 Deep Insight 의 구현을 매핑한다.

Zero Trust 요소 Deep Insight 의 구현
커널 수준 격리 AgentCore microVM (Runtime 세션) + Fargate 컨테이너 (코드 실행)
네트워크 이그레스 제한 Private Subnet + VPC Endpoint 로만 아웃바운드
프롬프트 무결성 프레임워크 Bedrock Guardrails 에 위임

7.7 30번·33번 모델과의 매핑

모델 매핑 결과
30번 Protected zone 인프라 차원의 격리 — VPC + SG 가 코드 레벨 protected zone 보다 강한 보장
33번 OpenAI 7 도구 “관측 가능성” + “구조 테스트” 가 CloudWatch + Bedrock Guardrails 로 매핑
33번 누비다 엔터프라이즈 특화 회사 내부망 설치 방식 → Private Subnet + VPC Endpoint 가 동일 요구 충족

특히 33번에서 “누비다가 회사 내부망 설치 방식을 준비 중이라는 점에서 금융·공공기관 같은 보안 민감 환경을 정조준한다” 고 추론했는데, AWS Deep Insight 는 그 요구를 이미 AWS 기본 서비스 조합 으로 충족한다. 누비다가 단일 제품으로 풀려는 문제를, AWS 는 인프라 컴포넌트 조립으로 풀고 있다.

8 3 가지 결정의 통합 효과

3 가지 결정은 독립적이지 않다. 함께 작동할 때 비로소 의도한 보안·확장성·신뢰성 을 만든다.

8.1 상호 보완 매트릭스

위협 / 요구 Decision 1 Decision 2 Decision 3
코드 실행 격리 microVM + Fargate 격리 — VPC + SG 다층 격리
데이터 유출 차단 — S3 prefix 격리 + IAM Private Subnet + VPC Endpoint
장기 세션 안정성 Sticky Session + Active CPU S3 영속 보존 Health Check 게이트
Context 한계 회피 Fargate 내부 .pkl 캐시 Note-taking 외부화 —
HITL 통합 (Runtime 의 SSE 스트리밍) S3 polling 사이드 채널 (Private 통신)
인젝션 blast radius 제한 Fargate microVM 격리 (피해 데이터 범위 제한) 아웃바운드 차단
비용 효율 Active CPU 과금 S3 저비용 (인프라 단순화)

각 행이 여러 결정의 조합 으로만 충족된다는 점이 핵심이다. 한 결정만 도입하면 그 결정이 전제하는 다른 결정의 부재로 효과가 반감된다.

8.2 도입 순서 — 33번 추론의 검증

33번에서 OpenAI 7 도구와 Anthropic 분리 모델을 통합 도입할 때 다음 순서를 추론했다.

  1. Sandbox 확보 (Worktree·격리 실행)
  2. Session 인프라 (Repository 문서화 + 관측 가능성)
  3. Harness 규칙 (AGENTS.md + 리뷰 자동화)
  4. 자동 게이트 (Linter + 구조 테스트)

AWS Deep Insight 의 실제 도입 순서는 어떠했을까. Part 3 본문에 명시된 진화 경로를 보면:

  • 초기: EC2 단일 self-hosted (모든 것이 한 곳)
  • 동시 요청 실패 → 코드 실행 분리 결정 → Decision 1 우선
  • 분산 시스템화 → 데이터 허브 필요 → Decision 2 추가
  • 프로덕션 배포 → 보안 격리 필요 → Decision 3 마지막

즉 Sandbox(D1) → Session(D2) → Harness 격리(D3) 순서로 진화했다. 33번 추론의 1·2·3 단계와 정확히 일치한다. 4 단계 (자동 게이트) 는 Bedrock Guardrails + Validator 에이전트로 별도 구현돼 있다.

9 운영 실측 — 22.5 분 세션의 미시 분석

Part 3 본문은 14 일치 매출 데이터 (830 건 거래) 분석 한 세션을 처음부터 끝까지 기록한다. 이 데이터가 3 가지 결정의 효과를 사후 검증 한다.

9.1 세션 개요

항목 값
분석 데이터 14 일치 매출 (830 건 거래)
총 세션 시간 22.5 분
Coder 단계 8 분 동안 9 개 차트 생성 (14 개 스크립트 순차 실행)
Validator 단계 7 개 검증 단계 2 분 내 수행, 2 개 실패 → 자체 복구
Reporter 단계 11 개 단계로 최종 1.3 MB DOCX 작성
Fargate 실행 횟수 79 회
순수 코드 실행 시간 합 19.8 초
LLM 추론 시간 22.5 분 - 19.8 초 ≈ 20 분 이상

9.2 핵심 인사이트 — LLM 추론이 코드의 61 배

LLM 추론이 코드 실행 시간의 61 배 다. 22.5 분의 대부분 (>90%) 이 LLM 이 다음 단계를 계획하고 코드를 생성하는 시간이고, 실제 연산은 그 1/61 에 불과하다.

이 비율이 Decision 1 의 사후 검증이다. 추론 (I/O 지배적) 과 compute (CPU 지배적) 의 워크로드 특성이 근본적으로 다르므로 두 환경을 분리한 것이 정확했다.

만약 분리 없이 같은 인프라에서 돌렸다면:

  • Runtime 이 Active CPU 과금 모델을 적용 못 함 (실제로는 LLM 응답 대기 중 → 0 과금이 핵심 이점)
  • Fargate 가 짧은 실행마다 Cold start 비용
  • 두 워크로드의 스케일링 단위 충돌

9.3 Sticky Session 의 효과 — 79 개 실행이 단일 컨테이너

79 회의 Fargate 실행이 단일 컨테이너에서 22.5 분간 warm 상태로 유지 됐다. ALB sticky session 라우팅이 같은 컨테이너를 22.5 분간 살려둔 덕분이다.

이 효과로:

  • 에이전트가 전처리된 dataframe 을 .pkl 캐시로 저장 → 모든 단계에서 재사용
  • 매 실행마다 컨테이너가 새로 떴다면 14 일치 830 건 데이터셋을 매번 재로드
  • 한국어 폰트 캐시도 컨테이너 부팅 시 한 번만 비용

Sticky Session 이 단순한 “같은 서버로 라우팅” 을 넘어 워크로드의 시간적 지역성을 활용 하는 인프라 패턴임이 드러난다.

9.4 실패 자체 복구 — 하네스가 실패를 다루는 방식

Validator 단계에서 두 번 실패가 발생했다.

실행 # 에이전트 스크립트 결과
40 Validator validator_step2_validate.py (v1) 첫 실패
42 Validator validator_step2_inspect.py LLM 의 첫 재시도도 실패
44 Validator validator_step2_inspect2.py LLM 이 문제를 더 작은 진단 스크립트로 분해
46 Validator validator_step2_validate.py (v2) 재시도 성공 — 동일 파일명, 내용만 재작성

사람이 개입한 부분은 없다. 에이전트는 stderr 를 읽고, 진단용 스크립트를 작성하고, 원래 Validator 를 다시 써서 재시도 했다.

복구 메커니즘은 놀라울 만큼 단순하다.

# managed-agentcore/src/tools/custom_interpreter_write_and_execute_tool.py (핵심 발췌)

exec_stdout = exec_result.get('stdout', '').strip()
exec_stderr = exec_result.get('stderr', '').strip()

# 원문 PDF 의 [FAIL]/[OK] 마커는 유니코드 기호로 표기되어 있으나
# 본 블로그 규칙(이모지·기호 금지) 에 따라 ASCII 로 치환한다.

if exec_result.get('error'):
    results.append(f" [FAIL] Execution failed: {exec_result['error']}")
    if exec_stderr:
        results.append(f"Stderr: {exec_stderr}")
    return "\n".join(results)      # 실패도 문자열로 그대로 LLM 에게 반환

# Success case
results.append(" [OK] Execution successful")
if exec_stdout:
    results.append(f"Output:\n{exec_stdout}")
if exec_stderr:
    results.append(f"Stderr:\n{exec_stderr}")   # 경고도 숨기지 않음
return "\n".join(results)

핵심 패턴: tool 의 리턴 문자열에 stderr 를 숨기지 않고 그대로 담아 돌려준다. 반환된 문자열은 에이전트의 다음 Bedrock 요청에 tool result 로 실려 들어가고, LLM 은 이 stderr 를 자기 context 에 포함한 채로 다음 코드를 생성한다.

별도의 retry 로직이나 에러 classifier 가 없으며, LLM 의 일반적 추론 능력이 그 자리를 대신한다. “하네스가 실패를 다룬다” 라는 표현은 여기서는 “실패 메시지를 숨기지 않고 그대로 LLM 에게 돌려준다” 라는 뜻이 된다.

9.5 30번·31번 모델과의 매핑

모델 매핑 결과
31번 Tool result lifecycle 원문 보존이 디폴트 — Copilot CLI 의 “한계 전까지 보존” 정책의 인프라 구현
30번 Claude Code 약점 (“잊음”) tool result 압축 없이 stderr 까지 그대로 LLM 에 전달 → 자체 복구 가능
30번 hybrid workflow 별도 retry 로직 없이 LLM 추론 능력으로 대체 — 하네스의 미니멀리즘

이 패턴은 30번에서 다룬 Claude Code 의 “Tool result 가 나중에 clear 될 수 있다” 와 정반대 방향이다. AWS 는 stderr 보존이 곧 복구 메커니즘 이라는 통찰로, tool result 의 영속성을 하네스의 핵심 기능으로 격상한다.

10 비용 분석

10.1 1 세션 비용 breakdown

위 22.5 분 세션의 추정 비용 (2026 년 4 월 us-west-2 기준, VPC 네트워크 서비스 비용 별도):

구성 요소 추정 비용 (USD) 비중
Bedrock 토큰 (Sonnet 4.6 메인 + Haiku 4.5 일부) ~$4.09 ~98%
Fargate 컨테이너 (22.5 분 sticky + 19.8 초 execute) ~$0.02 <1%
AgentCore Runtime (active CPU ~20 초, I/O-wait 무과금) <$0.01 <0.1%
ALB / S3 / data transfer <$0.02 <1%
세션 총 비용 ~$4.13 100%

10.2 토큰 구성

토큰 breakdown:

토큰 유형 양 비고
regular input 806K
output 91K
cache read 412K 90% 할인 적용
cache write 52K

10.3 핵심 인사이트 — 비용은 LLM 에 99% 집중

세 가지가 동시에 보여진다.

  1. 인프라 비용은 무시할 수준 — Runtime + Fargate + ALB + S3 합쳐도 1% 미만
  2. 압도적으로 LLM 이 지배 — Bedrock 토큰이 98%
  3. 비용 절감의 여지는 LLM 에 있다 — 현재 시스템은 citation 포함 / 미포함 DOCX 두 개를 동시 생성하는데, Reporter Agent 프롬프트 수정으로 하나만 생성하면 절감 가능

이 breakdown 은 “LLM 추론 시간이 코드 실행 시간의 61 배” 라는 시간 차원의 관찰과 같은 결론을 비용 차원에서도 보여준다. Decision 1 의 인프라 분리는 이미 충분히 작은 인프라 비용을 더 작게 만든 게 아니라, 추후 LLM 비용 최적화의 여지를 보장 한다.

특히 cache read 가 90% 할인이라는 점은 Prompt Caching 이 효과를 발휘했음을 시사하지만, 자세한 구현은 Part 2 영역이라 본 글에서는 생략한다.

10.4 30번 trade-off 의 비용적 검증

30번에서 Copilot CLI 의 약점으로 “비용 (보존 우선의 토큰 사용량 누적)” 을 들었다. AWS 사례는 이 trade-off 를 인프라 분리 로 우회한다.

  • Tool result 보존 → S3 외부화 (Bedrock 토큰 비용에 영향 없음)
  • 컨텍스트 보존 → Note-taking 으로 Context 가볍게 유지
  • 결과: 토큰 비용은 LLM 자체에만 발생, 보존 비용은 S3 (저렴) 로 분산

30번에서 추론한 hybrid workflow 가 인프라 차원에서 자동으로 구현 된다.

11 Critical Reading — 이 사례의 한계와 일반화 가능성

이 사례를 무비판적으로 받아들이면 안 된다. 한계와 일반화의 어려움을 명시한다.

11.1 한계 1 — AWS 종속성

AgentCore Runtime, Bedrock, Fargate, ALB, S3, VPC Endpoint, IAM 모두 AWS 고유 서비스다. 다른 클라우드 / 온프레미스에서는 동일 패턴 구현이 가능하지만 다음 차이가 있다.

영역 AWS Deep Insight 다른 환경
추론 환경 AgentCore Runtime (관리형) Azure AI Foundry / GCP Vertex AI / 자체 구축
코드 실행 Fargate (서버리스 컨테이너) Azure Container Apps / Cloud Run / Kubernetes Job
외부 메모리 S3 + VPC Endpoint Azure Blob + Private Endpoint / GCS + VPC SC
격리 microVM (커널 수준) Azure microVM / gVisor / 일반 컨테이너

같은 패턴은 가능하나 microVM 같은 커널 수준 격리는 클라우드 사업자별 지원 차이가 크다. 일반 Kubernetes Pod 격리는 microVM 보다 약하다.

11.2 한계 2 — 솔루션 영업의 정황

AWS 공식 블로그라는 출처는 양면적이다. 검증 가능성 은 강하지만, AWS 솔루션의 우수성을 강조 하려는 동기도 있다. 다음 점을 비판적으로 봐야 한다.

  • “AgentCore Runtime 선택 4 가지 이유” 는 모두 AgentCore 의 강점만 나열 — 약점이나 대안 비교 부족
  • 실측 비용 ~$4.13 는 us-west-2 기준이고, 한국 리전 비용은 다를 수 있음
  • “버그 발생률 40% 낮음” 같은 OpenAI Project 1M 류의 비교 통계는 등장하지 않음 — 이 사례가 비교 우위를 객관화한 것은 아님

11.3 한계 3 — 일반 조직의 도입 비용

이 인프라를 따라하려면:

  • AWS 클라우드 비용 (1 세션 ~$4 는 분석 1 회당이지, 인프라 상시 운영 비용은 별도)
  • Bedrock + AgentCore + Fargate + VPC + ECR 통합 운영 지식
  • IAM Role / Security Group 다층 설계 노하우
  • 멀티 에이전트 (Planner / Coder / Validator / Reporter) 코드 자체

개인 / 소규모 팀이 그대로 따라하기에는 진입 장벽이 높다. 33번에서 “원클릭 코딩” 도구가 부상하는 이유 중 하나가 이 진입 장벽이다.

11.4 일반화 가능한 핵심 패턴 3 가지

위 한계에도 불구하고, 클라우드 / 도구 / 규모와 무관하게 일반화 가능한 패턴 은 다음 3 가지다.

패턴 본질 환경 비독립성
추론·실행 분리 워크로드 특성이 다른 컴포넌트는 분리 모든 환경에서 적용 가능
Context 외부화 컨텍스트 윈도우는 가볍게, 정보는 외부 저장소 모든 환경
Defense in Depth 다층 방어는 한 층의 실패를 다른 층이 보완 모든 환경

이 3 가지는 AWS 가 아니어도, 심지어 클라우드가 아니어도 (온프레미스 + 자체 구축 워크플로우) 적용 가능하다. AWS 사례는 이 3 패턴의 한 가지 구체화일 뿐이다.

12 31번 동심원 모델의 사후 검증과 갱신

12.1 검증 결과

31번에서 정의한 Prompt ⊂ Context ⊂ Harness 동심원이 AWS 사례에서 어떻게 나타나는지 확인한다.

┌─────────────────────────────────────────────────┐
│  Harness — VPC + SG + AgentCore + Fargate + ALB │
│   (인프라 차원)                                   │
│  ┌───────────────────────────────────────────┐ │
│  │  Context — S3 외부 메모리 + Note-taking   │ │
│  │  (저장소 차원)                              │ │
│  │  ┌─────────────────────────────────────┐ │ │
│  │  │  Prompt — Planner / Coder /         │ │ │
│  │  │   Validator / Reporter 시스템 지시   │ │ │
│  │  │  (지시문 차원)                        │ │ │
│  │  └─────────────────────────────────────┘ │ │
│  └───────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

3 층이 물리적·논리적으로 분리 된 인프라로 존재한다. 31번 동심원이 학술적 도구가 아니라 실무적 사실임이 검증된다.

12.2 갱신 제안

33번에서 5 층 모델 (Orchestration ⊃ Harness ⊃ Context ⊃ Prompt ⊃ Model Weights) 을 제안했다. AWS 사례는 이 갱신 모델 중 4 개 층 (Model Weights 제외) 을 모두 보여준다.

층 AWS Deep Insight 의 구현
Orchestration Multi-Agent (Planner ↔︎ Plan Reviewer ↔︎ Supervisor ↔︎ Coder ↔︎ Validator ↔︎ Reporter)
Harness AgentCore Runtime + Fargate + S3 + VPC + ALB + IAM
Context all_results.txt, citations.json, S3 prefix 구조
Prompt 각 에이전트의 시스템 지시 (본문 미공개)
Model Weights (제외 — AWS 정의에 따라 하네스 외부)

5 층 모델의 유효성이 사후 검증된다. 다만 Model Weights 층은 동료 스킬 같은 특수 케이스에만 해당되며, 표준 케이스에서는 4 층 (Orchestration + Harness + Context + Prompt) 으로 충분 하다.

12.3 31번 모델의 미세 갱신

AWS 정의를 받아들인다면 31번 동심원에 한 가지 단서를 추가하는 것이 적절하다.

표준 명제: Harness 의 범위는 LLM 모델 자체를 제외한 거의 모든 것이다.

확장 명제 (특수 케이스): 사용자가 모델 가중치를 직접 커스터마이즈하는 경우 (동료 스킬, 도메인 파인튜닝), Model Weights 가 추가 내부 층으로 등장한다.

이 단서는 33번의 5 층 모델을 흡수하면서 31번의 단순함을 유지한다.

13 30번 trade-off 우회 사례의 통합 정리

30번에서 Claude Code 와 Copilot CLI 의 5 대 축 trade-off 를 정리했다. AWS Deep Insight 는 이 trade-off 들을 어떻게 우회하는지 통합 정리한다.

30번 5 대 축 Claude Code 약점 Copilot CLI 약점 AWS Deep Insight 우회
Auto-compaction 자동 압축으로 정보 손실 사용자 명시 호출 부담 S3 외부화 — 압축 자체가 무관해짐
Tool result lifecycle clear 되어 후반 참조 불가 토큰 비용 누적 stderr 그대로 LLM 반환 — 인프라 차원의 보존
응답 길이 제약 25/100 단어 강제 비용 누적 (해당 없음 — 에이전트별 자체 제어)
Skill 로딩 Eager 메타로 컨텍스트 폭발 Lazy load 의 탐색 지연 Note-taking 으로 컨텍스트 가볍게
Protected zone 불확실 추정 존재 VPC + SG 다층 — 인프라 차원의 강한 격리

AWS 사례의 일관된 전략은 “코드 레벨 trade-off 를 인프라 레벨 분리로 우회” 다.

  • Claude Code 의 약점 (“잊음”) → S3 외부 메모리로 잊지 않을 수 있는 영역 확보
  • Copilot CLI 의 약점 (“무거움”) → 인프라 분리로 비용을 LLM 에만 집중

이는 30번에서 추론한 hybrid workflow (“탐색은 Claude Code, 작성은 Copilot CLI”) 와 다른 방향의 해법 이다. 30번이 두 도구를 task 별로 분담하는 운영 차원의 해법이라면, AWS 는 인프라 차원에서 두 약점이 동시 우회되는 자체 시스템을 구축한다.

14 32번 자체 체계와의 비교 — 스케일 차이의 함의

32번에서 이 블로그 프로젝트의 AGENT_GUIDE 체계를 Harness-aware Context Engineering 으로 명명했다. AWS Deep Insight 는 같은 패턴을 인프라 차원에서 구현한 사례다.

14.1 같은 패턴의 다른 스케일

비교 항목 이 블로그 (32번) AWS Deep Insight
Context 외부화 위치 모델 응답 텍스트 (CP-1/2/3 출력 의무) S3 영속 저장소
압축 방어 절대 규칙 5 개 중복 배치 인프라 차원에서 압축 자체가 무관
Harness 차용 vs 구축 Claude Code · Gemini CLI 차용 자체 구축 (AWS 인프라 위에)
페르소나 auto memory (사용자 선호 누적) 미구현 (Multi-Agent 분리로 페르소나 다양성 확보)
분리 Subagent (Claude Code 기능 차용) 인프라 차원의 4 에이전트 분리

같은 Harness-aware Context Engineering 패턴이지만, 스케일과 책임 영역이 근본적으로 다르다.

14.2 33번 결론의 재확인

33번에서 이 블로그 프로젝트의 산업적 좌표를 다음과 같이 결론지었다.

“이 블로그 프로젝트는 산업 진화의 3 단계(하네스) 끝자락에 위치한다. (…) 4 단계(페르소나 + 분리) 의 두 축은 약하다.”

AWS Deep Insight 가 4 단계 (분리) 의 본격 사례라면, 이 블로그가 4 단계로 진화하는 것은 과잉 엔지니어링 이라는 33번의 판단이 다시 확인된다.

  • AWS Deep Insight 같은 시스템은 AWS Korea SA Team 의 전담 인력이 필요
  • 이 블로그는 1 인 운영 — 인프라 분리·VPC 격리·multi-agent orchestration 까지 도입하면 운영 가능 임계를 넘음

이 블로그는 AWS 사례의 패턴 (Context 외부화, Harness-aware) 을 차용하되, 인프라 분리는 외주 하는 위치가 합리적이다. Claude Code · Gemini CLI 가 그 외주 대상이다.

15 결론

15.1 한 문장 요약

AWS Deep Insight 의 3 가지 인프라 결정 (코드 실행 분리·S3 중간 저장소·완전한 네트워크 격리) 은 31번 동심원·30번 trade-off·32번 cross-cutting·33번 산업 카탈로그를 단일 시스템에서 통합 검증 하는 공식 1 차 자료 사례다.

15.2 31~33번 시리즈의 갱신

시리즈 AWS 사례로 인한 갱신
31번 동심원 정의 미세 갱신 — “표준 케이스: 모델 제외 모든 것 / 특수 케이스: Model Weights 추가”
30번 trade-off 인프라 분리가 코드 레벨 trade-off 를 동시 우회한다는 새 해법 등록
32번 자기 체계 Harness-aware Context Engineering 패턴이 인프라 차원으로 격상 가능함을 확인
33번 산업 카탈로그 OpenAI 7 도구 + Anthropic 분리 + 누비다 3 AI 가 한 시스템에서 통합 구현 가능한 사례 추가

15.3 핵심 메시지 4 가지

  1. 하네스 정의는 산업 표준으로 수렴 중 — AWS 의 정의 (“LLM 제외 모든 것”) 가 31번의 학술 정의와 거의 일치하며, 책임 경계가 모델 벤더 / 사용자로 명확히 분리된다
  2. 3 가지 인프라 결정은 독립적이지 않다 — Decision 1·2·3 이 함께 작동할 때 비로소 의도한 효과 (보안·확장성·신뢰성) 가 나오며, 한 가지만 도입하면 효과가 반감된다
  3. 실측이 추론을 뒷받침한다 — LLM 추론 시간이 코드 실행의 61 배·비용의 98%·1 컨테이너 79 실행이라는 실측이 추론·compute 분리의 정당성을 사후 검증한다
  4. 하네스가 실패를 다루는 방식은 미니멀리즘 — 별도 retry 로직 없이 stderr 를 LLM 에 그대로 반환하는 단순한 패턴이 자체 복구를 가능케 한다. 하네스 설계는 추가 기능보다 정보의 투명한 전달 이 우선이다

15.4 한계와 다음 단계

이 글의 명시된 한계는 다음과 같다.

  • AWS Korea SA Team 이 공개한 Part 3 단독 분석. Part 1 (시스템 아키텍처) 과 Part 2 (Context Engineering 기법) 의 원문은 미참조 상태
  • AWS 솔루션 영업의 정황 — 약점·대안 비교가 부족한 점은 비판적 독해 필요
  • microVM 격리·VPC Endpoint 같은 AWS 고유 기능 의존성 — 일반화 가능 패턴은 3 가지로 압축됨

향후 작업:

작업 위치
Part 1 (시스템 아키텍처) 분석 35번 포스트 신규 작성
Part 2 (Context Engineering 기법: Note-taking, 파일 외부화, Skills, Prompt Caching, Validator/Tracker) 분석 36번 포스트 신규 작성
본 글의 결정·실측 갱신 Part 1·2 입수 후 본 글에 cross-reference 추가

16 관련 주제

선행 시리즈 (이 글의 전제)

관련 아키텍처 분석

향후 작성 예정 (Placeholder)

17 참고문헌

17.1 1 차 자료 (AWS 공식)

  • AWS Korea SA Team (Yoonseo Kim, Jesam Kim, Jiyun Park, Kyutae Park, Gonsoo Moon, 곽영화). (2026.4.22). 하네스 엔지니어링으로 본 Deep Insight – 로컬 개발에서 프로덕션 운영까지의 설계 여정 (Part 3/3). AWS 기술 블로그. https://aws.amazon.com/ko/blogs/tech/harness-engineering-from-deep-insight/
  • AWS Korea SA Team. (2026). Deep Insight Part 1 — 프로덕션급 Multi-Agent 시스템의 필요성과 아키텍처. AWS 기술 블로그. (본 글 작성 시점 미참조)
  • AWS Korea SA Team. (2026). Deep Insight Part 2 — Context Window 한계를 넘어서: Context Engineering 실전 기법. AWS 기술 블로그. (본 글 작성 시점 미참조)

17.2 AWS 공식 문서

  • Amazon. (2025). Amazon Bedrock AgentCore Documentation. https://docs.aws.amazon.com/bedrock/agentcore
  • Amazon. (2025). AWS Fargate User Guide. https://docs.aws.amazon.com/fargate
  • Amazon. (2025). Application Load Balancer Documentation. https://docs.aws.amazon.com/elasticloadbalancing
  • Amazon. (2025). VPC Endpoints (AWS PrivateLink). https://docs.aws.amazon.com/vpc

17.3 학술 배경 (Part 3 본문 인용)

  • Anthropic. (2024). Building Effective Agents — 7 Design Patterns. (Multi-agent 설계 패턴 배경)
  • (저자 미상). (2025). 프롬프트 인젝션 공격의 평균 성공률 84.30%. (도구 환경 인젝션 보안 연구. Part 3 본문 인용 — 원 논문 출처 추가 확인 필요)
  • (저자 미상). (2025). 에이전트 전용 Zero Trust 아키텍처. (커널 격리 + 네트워크 이그레스 제한
    • 프롬프트 무결성 3 층 방어. Part 3 본문 인용 — 원 논문 출처 추가 확인 필요)
  • OWASP. (2025.2). Agentic AI Threats and Mitigations.
  • Gartner. (2025). 2028 년까지 기업용 SW 의 33% 가 Agentic AI 포함, 일상 의사결정 15% 자율.

17.4 표준·프로토콜

  • Anthropic. (2024). Model Context Protocol (MCP) Specification. https://modelcontextprotocol.io
  • Google. (2024). Agent-to-Agent (A2A) Protocol.

17.5 관련 시리즈 (이 블로그)

  • 31, 30, 32, 33 번 포스트 (위 “관련 주제” 참조)
출처 검증 주의

본 글은 AWS 공식 블로그 Part 3 단독을 1 차 자료로 한다. 다음 항목은 추가 검증이 필요하다.

  • “프롬프트 인젝션 84.30%” 통계의 원 논문 출처 (Part 3 본문은 학술 자료 인용 표시만 있고 정확한 서지 미명시)
  • “에이전트 전용 Zero Trust 아키텍처” 의 원 학술 제안 출처
  • AgentCore Runtime / Fargate 비용 추정치는 us-west-2 / 2026 년 4 월 기준이며, 다른 리전·시점에서 변경 가능

본 글의 결론은 Part 3 본문에 직접 명시된 정보에 한정하며, Part 1·2 영역의 세부 메커니즘은 일반화된 표현으로만 다루었다. Part 1·2 입수 시 35·36 번 포스트로 보강 예정.

Subscribe

Enjoy this blog? Get notified of new posts by email: