AWS Summit Hamburg 2026: 에이전틱 AI (Agentic AI)가 기대감을 넘어 실제 생산 단계로 넘어간 해

Hamburg 2026은 제가 직접 참석한 첫 번째 AWS Summit이었습니다. 이전에는 녹화 영상으로만 지켜봤었죠. AI 세션의 변화는 즉각적이었습니다. 작년의 강연들은 대부분 로드맵 위주였습니다. 아직 구축 중인 시스템을 위한 아키텍처 다이어그램(architecture diagrams), 그리고 "우리는 탐색 중입니다"라거나 "우리는 잠재력에 대해 기대하고 있습니다"와 같은 문구들이 주를 이루었습니다. 하지만 올해는 자동차 제조부터 에너지, 이커머스(e-commerce), 음식 배달에 이르기까지 여러 주요 기업들이 각각 결과물을 제시하며 포문을 열었습니다.

에이전틱 AI (Agentic AI)를 위한 인프라는 이제 실재합니다. 여전히 남아있는 질문은 역량이 아니라 안전성에 관한 것입니다.

Strands Agents: 모델이 스스로 결정하게 하기

저는 Strands Agents 강연으로 하루를 시작했습니다. 이미 직장에서 Strands를 사용하고 있었기에 대부분 익숙한 내용일 것이라 예상했습니다. 실제로 새로웠던 점은, 개발자들이 수동으로 수행하던 오케스트레이션 (orchestration) 결정권을 모델이 넘겨받는 수준까지 그들이 얼마나 멀리 나아갔는가 하는 점이었습니다.

이러한 변화는 작게 들릴 수 있지만 모든 것을 바꿉니다. 언제 어떤 에이전트를 호출할지 정의할 필요가 없습니다. 오케스트레이터 (orchestrator)가 이를 파악합니다. 모델이 작업을 읽고, 필요한 역량이 무엇인지 결정하며, 스스로 경로를 지정(routing)합니다. 이는 에이전트 그래프 (agent graph)에서 취약한 연결(brittle wiring)을 줄이고, 런타임 (runtime)에 예외 상황(edge cases)이 발생했을 때 더 많은 유연성을 제공한다는 것을 의미합니다.

세 가지 역량이 눈에 띄었습니다:

자기 확장성 (Self-extending): 에이전트가 실행 중에 직접 Python 도구를 작성합니다. 프레임워크가 런타임(runtime)에 도구를 다시 로드할 수 있기 때문에, 에이전트는 누락된 기능을 인식하고, 이를 위한 코드를 작성하여 저장한 뒤, 재시작 없이 즉시 해당 새로운 도구를 실행할 수 있습니다.

자기 지시성 (Self-directing): 에이전트가 상호작용을 바탕으로 자신의 시스템 프롬프트(system prompt)를 업데이트하고, 이러한 업데이트를 영구 메모리(persistent memory)에 저장합니다. Amazon Bedrock AgentCore와 함께 배포될 때, 이들은 Amazon Bedrock Knowledge Bases를 사용하여 과거 세션을 검색하므로 대화 전반에 걸쳐 문맥(context)이 축적됩니다.

메타 에이전트 (Meta-agents): 기본 오케스트레이터(primary orchestrator)가 작업에 따라 하위 에이전트(sub-agents)를 생성합니다. 세 가지 패턴이 있습니다: 스웜 (Swarm, 하위 에이전트들이 문맥 공간을 공유하며 문제의 일부를 병렬로 처리), 그래프 (Graph, 전문화된 에이전트들 간의 순차적인 지시적 인계), 그리고 씽크 (Think, 에이전트가 답변하기 전 추론을 심화하기 위해 자신의 인스턴스를 재귀적으로 생성).

AWS re:Invent 2025의 유사한 강연: Strands Agents deep-dive.

기업용 HR 플랫폼이 스스로 작동할 때

한 글로벌 에너지 기업의 HR 팀은 기존의 레거시 데이터 배포 시스템을 보유하고 있었습니다. 이는 데이터 형식과 소스가 자주 바뀌지 않던 시대에 맞춰 구축된, 비용이 많이 들고 경직된 시스템이었습니다. 그들은 이를 Amazon Bedrock Agents 및 Amazon Bedrock AgentCore로 구동되는 AWS 기반의 서버리스(serverless) 플랫폼으로 교체했습니다.

흥미로운 점은 단순한 마이그레이션이 아니었습니다. 그 위에 구축된 기능들이었습니다. 이 플랫폼은 자기 문서화(self-documenting), 자기 수정(self-modifying), 그리고 자기 치유(self-healing)가 가능합니다. 새로운 데이터 소스가 나타나면 시스템이 스스로 인제스션(ingestion)을 위한 Lambda와 Step Functions를 구축합니다. 변환(transformation) 작업이 실패하면, 시스템이 실패 원인을 진단하고, 수정 코드를 작성하며, 이를 배포합니다. 엔지니어는 자연어로 플랫폼에 질문을 던져 플랫폼 내부 구조에 대한 답변을 얻을 수 있습니다.

결과적으로: 연간 80만 달러의 라이선스 비용을 절감했으며, 일상적인 변경 사항에 대해 엔지니어의 개입 없이도 대부분 스스로 작동하는 데이터 전달 플랫폼을 구축했습니다.

그것이 바로 아래에서 설명할 성숙도 레벨 3 (Level 3 maturity)입니다. 대부분의 팀은 아직 그 단계에 도달하지 못했습니다. 하지만 이 정도 규모의 기업에서 그것이 실제 운영 환경 (production)에서 작동하는 것을 보는 것은, 이것이 아직 몇 년이나 더 남았다는 주장을 무색하게 만듭니다.

에이전트를 활용한 공급망 계획 (Supply chain planning)

한 글로벌 자동차 제조사는 수년 동안 AWS에서 머신러닝 (ML) 기반의 예측 및 계획을 실행해 왔습니다. 그들이 추가한 에이전틱 레이어 (agentic layer)는 기존 인프라를 대체하는 것이 아니라, 그 위에 구축된 추론 레이어 (reasoning layer)로, 현재 인간이 수동으로 해결해야 하는 문제들을 처리할 수 있습니다.

제 기억에 남는 구체적인 사례는 다음과 같습니다: "내 타이어는 어디에 있고 언제 도착하는가?" 간단해 보이지만, 이에 답하기 위해서는 생산 일정, 용량 제약 (capacity constraints), 유통 경로, 그리고 운송 네트워크를 동시에 조회한 다음, 그 답변들을 실행 가능한 정보로 조정해야 합니다. 에이전틱 AI (agentic AI) 이전에는 이 작업에 몇 시간이 걸렸습니다. 이제는 5분밖에 걸리지 않습니다.

이 아키텍처는 생산 차단 요소와 용량 제약을 병렬로 조사한 다음, 그 조사 결과를 비즈니스 친화적인 설명으로 합성하는 특화된 에이전트들을 사용합니다. 마지막 부분이 중요한데, 해당 팀은 블랙박스 최적화 (black-box optimization)에서 투명한 의사결정 (transparent decision-making)으로의 전환을 특별히 강조했습니다. 공급망 계획 담당자들에게는 시스템이 무엇을 권장하는지뿐만 아니라, 왜 그런 권장 사항을 내놓았는지에 대한 이해가 필요했습니다. 자신의 추론 과정을 설명할 수 있는 에이전트만이 실제로 채택될 수 있는 유일한 버전입니다.

프라이버시 우선, 그 다음 배포

실제 운영 환경으로 가는 경로가 어떤 모습인지에 대해 솔직하게 밝힌 한 강연이 눈에 띄었습니다. 유럽의 한 이커머스 (e-commerce) 플랫폼 팀은 멀티 에이전트 아키텍처 (multi-agent architecture)로 시작하지 않았습니다. 그들은 의도 분류 (intent classification)를 위한 단일 Bedrock API 호출과 사전 정의된 응답 템플릿으로 시작하여, 첫날부터 데이터 프라이버시 준수 (data privacy compliance)를 구축한 다음, 그 지점부터 단계적으로 발전시켜 나갔습니다: 프롬프트 엔지니어링 (prompt engineering), Bedrock Agents, 멀티 에이전트 오케스트레이션 (multi-agent orchestration), 그리고 마지막으로 Amazon Bedrock AgentCore에 이르기까지 말입니다. 각 단계에는 더 단순한 접근 방식이 더 이상 충분하지 않게 되는 한계점이 존재했습니다.

그러한 반복(iteration)의 결과로, 현재 1차 지원 티켓의 50% 이상이 AI에 의해 처리되고 있으며, 해결 시간은 60% 감소했습니다.

개인정보 보호(Privacy)는 사후 고려 사항이 아니라, 전 과정에 걸친 첫 번째 설계 제약 조건이었습니다. 티켓 내용이 LLM(대규모 언어 모델)에 도달하기 전, 패턴 매칭과 규칙을 사용하여 PII(개인 식별 정보)를 제거하는 익명화 계층(anonymization layer)을 거칩니다. 오직 익명화된 콘텐츠만이 전달됩니다. 게이트 파이프라인(gate pipeline)은 다음과 같습니다:

flowchart LR
    A[티켓 도착] --> B[PII 익명화]
    B --> C[팀으로 라우팅]
...

이전에 고려하지 못했던 세부 사항이 하나 있었습니다. 그들은 티켓 제출 5초 후에 AI 응답을 보내려고 시도했습니다. 그러자 고객 만족도가 떨어졌습니다. 사람들은 그 속도가 비인간적이라고 느꼈고 답변을 신뢰하지 않았습니다. 이제 그들은 인위적인 지연(artificial delay)을 추가합니다. 콘텐츠는 바뀌지 않았고 타이밍만 바뀌었을 뿐인데, 만족도가 다시 올라갔습니다.

시스템은 B2C와 B2B를 별도의 에이전트 체인(agent chains)으로 분리합니다. B2B 티켓은 더 많은 기업 특화 컨텍스트(context)를 포함하며 더 전문적인 처리를 요구하기 때문입니다. 관찰 가능성(Observability)은 처음부터 내장되어 있습니다. 모든 응답은 추적(trace)되며, 검색 성공률과 모델 사용량이 추적되고, 품질 점수가 시스템에 피드백됩니다. 이러한 관찰 가능성은 팀의 디버깅 방식 또한 변화시켰습니다. 질문이 "모델이 무엇이라고 답변했는가?"에서 "워크플로우가 왜 이렇게 동작했는가?"로 바뀌었습니다. 이는 어떤 도구가 호출되었는지, 무엇이 검색되었고 얼마나 관련성이 있었는지, 지연 시간(latency)이 어디서 발생했는지, 그리고 CSAT(고객 만족도) 점수와 티켓 재오픈율이 특정 워크플로우 경로에 대해 무엇을 말해주는지를 추적하는 것을 의미합니다.

flowchart LR
    A[정규화된 지원 요청] --> B[라우터 에이전트]

...

멀티 에이전트(Multi-agent)가 모든 구성원이 서로 대화한다는 것을 의미하지는 않습니다.

제한된 전문화(Bounded specialization)는 의도치 않은 상호 간섭(cross-talk)을 줄이고 핸드오프(handoff) 동작을 더 쉽게 추론할 수 있게 합니다. 이를 실제로 작동하게 만드는 몇 가지 아키텍처 결정 사항은 다음과 같습니다:

**라우터 에이전트 (Router Agent)**가 어떤 전문 에이전트가 요청을 처리할지 결정하며, 그 외의 다른 요소는 라우팅을 수행하지 않습니다.
전문 에이전트들은 책임 범위에 따라 격리되어 있으며, 서로를 직접 호출하지 않습니다.
오직 **티켓 업데이트 컴포저 (Ticket Update Composer)**만이 외부 시스템(티켓 시스템)에 데이터를 다시 기록합니다.
인간 에스컬레이션 (Human escalation)은 명시적인 경로이며, 새벽 2시에 갑자기 발견하게 되는 폴백 (fallback)이 아닙니다.
도구 권한 (Tool permissions)과 핸드오프 계약 (handoff contracts)은 런타임 (runtime)에 협상되는 것이 아니라 사전에 정의됩니다.

이러한 아키텍처는 이것을 프로덕션 등급 (production-grade)으로 만드는 요소의 일부일 뿐입니다. 에이전트는 제품 자체의 일부가 된 운영상의 고려 사항들을 불러왔습니다:

IaC 및 재현성 (reproducibility): 에이전트, 협업자 (collaborators), 역할 (roles), Lambda 함수, API Gateway, 그리고 지식 베이스 (knowledge base) 설정 모두 재현 가능한 배포가 필요합니다. 환경 간의 드리프트 (Drift)는 실제적인 장애 모드 (failure mode)입니다.
별칭 (Aliases) 및 버전 관리 (versioning): 테스트된 버전을 명시적으로 승격시키십시오. 프로덕션 환경에서 초안 에이전트 (draft agent)의 동작에 의존하지 마십시오.
지연 시간 예산 (Latency budgets): 멀티 도구 워크플로 (multi-tool workflows)는 웹훅 (webhook) 타임아웃을 초과할 수 있습니다. 지연 시간은 사후 모니터링 대상이 아니라 설계 제약 사항입니다.
구조화된 트레이스 (Structured traces): 의도 (intent), 검색 (retrieval), 도구 입력, API 오류, 그리고 응답 페이로드 (response payloads)를 로그로 남기십시오. 트레이스 없이 에이전틱 워크플로 (agentic workflow)를 디버깅하는 것은 추측에 의존하는 것과 같습니다.
인간 QA 샘플링 (Human QA sampling): 낮은 CSAT 점수, 티켓 재오픈율, 그리고 에스컬레이션 사유를 정기적인 주기로 검토하십시오.
비용 가드레일 (Cost guardrails): 에이전트 단계, 재시도 (retries), 토큰 예산, 그리고 검색 깊이 (retrieval depth)를 제한하십시오. 경계가 없는 에이전트는 곧 발생할 청구 사고 (billing incident)와 같습니다.

고객은 결과(answer)를 봅니다. 엔지니어링은 라우팅, 정책, 트레이스, 그리고 피드백 루프 (feedback loop)를 책임집니다.

적절한 에이전트 복잡도 수준을 선택하는 것 자체가 하나의 결정 사항입니다. 모든 것에 완전한 멀티 에이전트 (multi-agent) 설정이 필요한 것은 아닙니다:

유스케이스 (Use case)	직접적인 Bedrock 호출 (Direct Bedrock call)	Bedrock Agent	AgentCore
단일 결정, 알려진 출력값	가장 적합함	과잉 (Overkill)	과잉 (Overkill)
...
"가장 에이전트다운 것"을 위해 최적화하지 마십시오. 수용 가능한 운영 리스크 내에서 고객의 문제를 해결할 수 있는 최소한의 자율성 (autonomy)을 위해 최적화하십시오.

이 과정을 시작하는 모든 이들을 위한 그들의 교훈은 다음과 같습니다: 에이전트 코드를 첫 줄이라도 작성하기 전에 데이터 보안 및 프라이버시 팀을 참여시키십시오. 그들이 요구할 설계 결정 사항들은 나중에 소급 적용 (retrofit)할 수 없는 것들입니다.

AgentCore: 서비스로서의 멀티 테넌트 (multi-tenant) AI 구축

저는 또한 Amazon Bedrock AgentCore를 사용하여 멀티 테넌트 SaaS 에이전트를 구축하는 전문가 수준의 세션에도 참석했습니다. 만약 여러 고객이 각자의 AI 에이전트를 갖게 되는 플랫폼을 구축하고 있다면, 격리 (isolation) 문제는 보기보다 까다롭습니다.

에이전트 시스템에서의 테넌트 격리는 다섯 가지 차원에 걸쳐 이루어집니다: 신원 (identity, 각 테넌트의 에이전트가 제한된 권한의 자격 증명으로 동작), 메모리 (memory, 한 테넌트의 대화 기록이 다른 테넌트의 컨텍스트로 유출되지 않음), 게이트웨이 (gateway, 테넌트별 라우팅 및 속도 제한), 관찰 가능성 (observability, 다른 고객의 데이터를 보지 않고도 디버깅할 수 있도록 테넌트 범위로 지정된 트레이스 (traces)), 그리고 런타임 (runtime, 한 테넌트에서 폭주하는 에이전트가 다른 테넌트에 영향을 주지 않도록 하는 컴퓨팅 격리). 세션에서는 각 항목에 대한 실제 작동 예시를 살펴보았습니다.

그들이 사용한 "서비스로서의 지능 (intelligence as a service)"이라는 프레임워크는 기억할 가치가 있습니다. 만약 다른 팀이나 고객이 소비하는 AI 기능을 구축하고 있다면, 온보딩 (onboarding), 격리, 그리고 신원 전파 (identity propagation)와 같은 SaaS 구조는 당신이 구축하는 다른 어떤 서비스와 마찬가지로 동일하게 적용됩니다. AgentCore의 프리미티브 (primitives)는 빌딩 블록을 제공하지만, 이를 의도적으로 서로 연결하는 것은 여전히 당신의 몫입니다.

유사한 세션 녹화 영상: Building Multi-Tenant SaaS Agents with Amazon Bedrock AgentCore.

AgentCore가 규제가 엄격한 실제 도메인에서 작동하는 모습을 보여주는 한 가지 공개 사례가 있습니다. 바로 제약 마케팅 주장(pharmaceutical marketing claims)을 임상 참고 문헌, PubMed, OpenFDA, 그리고 ClinicalTrials.gov와 교차 검증하는 오픈 소스 의료 콘텐츠 검토 애플리케이션입니다. 이 애플리케이션에 적용된 몇 가지 아키텍처 결정은 여러분의 도메인과 관계없이 연구할 가치가 있습니다. 첫째, 검토 서브 에이전트(reviewer sub-agents)는 발견한 내용을 S3에 저장하고 오케스트레이터(orchestrator)에는 S3 URI만 반환합니다. 이를 통해 30페이지 분량의 문서에서 나온 수백 개의 발견 사항이 오케스트레이터의 컨텍스트 윈도우(context window)를 통과하지 않도록 하여, 요약 과정에서 발견 사항이 누락되는 문제를 방지합니다. 둘째, 사용자 신원(user identity)은 요청 페이로드(request payload)가 아닌 JWT의 sub 클레임(claim)으로부터 서버 측에서 추출됩니다. 이는 프롬프트 인젝션(prompt injection)을 통한 사칭(impersonation) 벡터를 직접적으로 차단합니다. 두 패턴 모두 재사용이 가능합니다. 전체 상세 내용 및 오픈 소스 저장소: Accelerate Medical Content Review with Amazon Bedrock AgentCore.

성숙도 사다리 (The maturity ladder)

여러 강연을 통해 기업들이 에이전틱 AI (Agentic AI)의 성숙도를 어떻게 생각하고 있는지에 대한 대략적인 프레임워크가 도출되었습니다.

**레벨 1 (Level 1)**은 규칙 기반 AI (rules-based AI)입니다. 시스템은 정의된 정책을 따르며, 사람이 모든 결정 경로를 정의하고 AI는 특정 공백을 채우는 역할을 합니다.

**레벨 2 (Level 2)**는 자율 작업 AI (autonomous task AI)입니다. 시스템이 셀프 문서화(self-documentation), 품질 모니터링(quality monitoring), 작업 라우팅(task routing)과 같은 전체 워크플로(workflow)를 처리합니다. 사람은 개별 단계가 아닌 결과물을 감독합니다.

**레벨 3 (Level 3)**은 자가 모니터링 시스템 (self-monitoring systems)입니다. 시스템이 스스로 실패를 진단하고 이전에는 없던 역량을 구축합니다. 사람의 감독은 일상적인 업무가 아닌 예외적인 상황에 기반하여 이루어집니다.

발표한 기업 대부분은 레벨 1(Level 1)에서 레벨 2(Level 2)로 넘어가는 과도기에 있었습니다. 에너지 기업의 HR 플랫폼이 실제 운영 환경(production)에서 작동 중인 레벨 3(Level 3)의 유일한 사례였습니다. 계획을 세우기 전에 이 격차를 파악해 두는 것이 중요한데, 그 이유는 레벨 2는 레벨 1과 다른 아키텍처 결정(architecture decisions)을 요구하며, 레벨 3은 레벨 2와 다른 신뢰 결정(trust decisions)을 요구하기 때문입니다.