지난 2년 동안 프로덕션 AI 스택은 점점 더 높아지며 성장했습니다. 6개월마다 새로운 레이어(layer)가 그 위에 쌓였습니다. 벡터 데이터베이스 (Vector databases), 오케스트레이션 프레임워크 (Orchestration frameworks), 그다음은 에이전트 (agents), 그다음은 평가 (evaluation)였습니다. 유행하는 모든 아키텍처 다이어그램에서 그 탑이 높아지는 것을 지켜볼 수 있었습니다.

그러다 멈췄습니다.

2026년 5월판 스택 맵은 새로운 층을 추가하지 않았습니다. 대신 형태를 바꾸었습니다. 예전에는 하단 근처에 박스 형태로 놓여 있던 관측성 (Observability)과 거버넌스 (governance)가 옆으로 누웠습니다. 그것들은 최상단의 모델 호출 (model call)부터 최하단의 감사 로그 (audit log)까지 모든 레이어를 관통하는 수직 레일 (vertical rails)이 되었습니다. 이것이 제가 살펴보고자 하는 변화의 핵심입니다. 왜냐하면 이는 단순히 그림을 그리는 방식이 아니라, AWS 위에서 구축하는 방식 자체를 바꾸기 때문입니다.

제가 참고하고 있는 지도는 6개월마다 프로덕션 AI 스택을 다시 그려서 게시하는 @codewithbrij의 것입니다. 2026년 5월판(좋아요 649개, 좋아요의 가치가 무엇이든 간에)은 명확한 전후 차이를 보여주었습니다. 저는 이 지도의 공로를 가로채려는 것이 아닙니다. 지도가 생략한 부분, 즉 모든 노드 (node)를 해당 위치를 실제로 커버하는 AWS 서비스로 교체하고, 제가 만든 매핑을 신뢰하기 전에 테스트를 실행해보고 싶은 두 가지 지점을 짚어내기 위해 이 글을 씁니다.

중요하기 때문에 미리 면책 조항을 하나 밝힙니다. 이것은 저의 해석적 매핑이며, AWS 공식 문서가 아닙니다. 스택의 형태는 @codewithbrij의 소유입니다. AWS 서비스 선정은 저의 몫이며, 확신이 덜 드는 부분은 별도로 표시하겠습니다. 여기서의 가치는 권위에 대한 주장이라기보다 큐레이션 (curation)과 판단에 있습니다.

지난 리드로잉과 이번 리드로잉 사이의 변화

2026년 5월판에서는 다섯 가지가 움직였으며, 각각은 업계의 논쟁이 어디서 멈췄는지를 알려줍니다.

MCP가 커스텀 통합 (custom integrations)을 대체했습니다. 도구당 하나씩 존재하던 독점적 어댑터 (proprietary adapters) 더미는 이제 단일 프로토콜이 되었습니다. 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 에이전트가 도구와 통신하는

벡터 데이터베이스 (Vector databases)가 Postgres에 흡수되었습니다. 모두가 별도의 서비스로 구축했던 특화된 벡터 DB 계층은 대부분 pgvector로 사라졌습니다. AWS에서는 이는 Aurora PostgreSQL이 과거에 다이어그램 상에 별도의 박스를 추가해야만 했던 케이스를 이제 커버한다는 것을 의미합니다.

프레임워크들은 통합되었고, 일부는 사라졌습니다. AutoGen은 중단되어 사라졌습니다. LangChain과 LlamaIndex는 모두 상당한 압박을 받고 있습니다. 이것이 여러분이 무엇을 채택해야 하는지에 어떤 의미를 갖는지에 대해서는 나중에 다시 다루겠습니다. 왜냐하면 "프레임워크가 압박을 받고 있다"는 것이 "내일 당장 뽑아내라"는 것과 같은 의미는 아니기 때문입니다.

AI 게이트웨이 (AI gateways)는 첫 번째 실질적인 보안 국면을 맞이했습니다. 2026년 5월, AI 게이트웨이 취약점이 CISA의 알려진 취약점 (Known Exploited Vulnerabilities) 카탈로그에 등재되었습니다. 이는 특정 카테고리가 편의의 영역을 벗어나 보안 요구 사항이 되는 경계선입니다. 어떤 제품이었는지를 포함하여 이에 대한 자세한 내용은 아래에서 다루겠습니다.

그리고 가장 중요한 변화입니다. 관측성 (Observability)과 거버넌스 (Governance)는 더 이상 계층 (layers)이 아니었습니다. 그것들은 레일 (rails)이 되었습니다. @codewithbrij는 이를 하나의 규칙으로 제시했습니다: 100일째가 아니라, 1일째부터 적용되어야 한다고 말입니다.

지도: 모든 계층과 이를 커버하는 AWS 서비스

핵심부터 시작하겠습니다. 스택의 고전적인 수평 계층들과, 각 계층에서 제가 선택할 AWS 서비스입니다.

The 2026 production AI stack as nine horizontal layers, each mapped to an AWS service, with Observability and Governance running as vertical rails through all of them

스택은 더 높게 성장하는 것을 멈췄습니다. 이제 레일은 위에서 아래로 흐릅니다.

모델 계층(model layer)에서의 Bedrock은 시간이 흐를수록 그 가치가 가장 빛나는 선택입니다. 2026년 스택의 핵심은 더 이상 단일 모델 제공자에게 도박을 하지 않는다는 점입니다. OpenAI와 Google 모델을 포함하여 단일 엔드포인트(endpoint) 뒤에 약 100개의 모델이 존재함에 따라, 추론 계층(inference layer)은 벤더 종속(vendor lock-in)이 아닌 라우팅(routing) 결정의 영역이 됩니다. 이것이 바로 "단일 엔드포인트"의 실체입니다. 아키텍처를 변경하는 것이 아니라, 파라미터(parameter)에서 anthropic.claude를 amazon.nova로 교체하기만 하면 됩니다.

메모리 계층(memory layer)은 이 지도가 왜 "더 높이 쌓는 대신 레일을 선택한다"는 논지를 갖게 되었는지를 가장 명확하게 보여주는 지점입니다. 2년 전이라면 전용 벡터 데이터베이스(vector database)를 구축했을 것입니다. 하지만 이제 대부분의 팀에게 정직한 해답은 pgvector를 사용하는 Aurora입니다. 특화된 계층(specialized layer)이 더 좋아진 것이 아니라, 흡수된 것입니다. 벡터 워크로드(vector workload)가 매우 크거나, 전용 엔진을 사용할 만큼 지연 시간(latency)에 민감한 경우에는 여전히 OpenSearch Serverless가 올바른 선택이지만, 이는 이제 기본값이 아닌 예외 사항입니다.

오케스트레이션(Orchestration)은 이 지도를 절대적인 진리로 받아들이는 것에 대해 제가 이의를 제기하고 싶은 유일한 부분입니다. "오케스트레이션"은 다이어그램 상에서는 하나의 노드이지만, 실제로는 매우 다른 두 가지 작업입니다. 만약 워크플로우가 결정론적(deterministic)이고, 분기(branching)를 포함하여 그릴 수 있는 고정된 단계의 시퀀스라면, 그것은 Step Functions의 영역이며, 여기서 에이전트(agent)를 사용하는 것은 비용과 비결정론(nondeterminism)만을 추가할 뿐입니다. 만약 워크플로우가 다음에 무엇이 일어날지를 모델이 직접 결정해야 한다면, 그것은 AgentCore 프레임워크(harness)의 영역입니다. 지도상에서는 같은 박스이지만, 도구는 정반대입니다.

주의 깊게 살펴볼 명칭 관련 사항이 하나 있습니다. 과거에는 이곳의 명확한 선택지였던 Bedrock Agents는 이제 Bedrock Agents Classic으로 명칭이 변경되었으며, 2026년 7월 30일에 신규 고객 유치를 중단합니다. 새로운 프로젝트를 시작한다면, AgentCore는 AWS가 마이그레이션(migration)을 유도하고 있는 방향이지, 단순한 선택지가 아닙니다.

레일(The rails): 너무 늦기 전까지는 아무도 추가하지 않는 부분

이것이 실제 논지이므로, 표가 아닌 산문 형식으로 설명하겠습니다.

관측성 (Observability)과 거버넌스 (Governance)가 단순한 선택 사항(boxes)에서 레일(rails)로 변한 이유는 AI 시스템이 일반적인 서비스와는 다르게 실패하기 때문입니다. REST 엔드포인트가 깨지면 스택 트레이스 (stack trace)가 보통 문제 지점을 가리킵니다. 하지만 에이전트 (agent)가 잘못된 답변을 내놓을 때는 아무것도 충돌(crash)하지 않습니다. 모델은 토큰 (tokens)을 반환했고, 도구 (tool)는 실행되었습니다. 출력값은 확신에 차 있었지만 틀렸을 뿐입니다. 잡아낼 예외 (exception)가 없습니다. 무슨 일이 일어났는지 알 수 있는 유일한 방법은 어떤 프롬프트 (prompt), 어떤 모델 (model), 어떤 도구 호출 (tool call), 어떤 검색된 문서 (retrieved document), 어떤 가드레일 (guardrail) 결정이 있었는지 전체 경로를 이미 기록하고 있는 경우뿐입니다.

그렇기 때문에 이 규칙은 100일째가 아닌 1일째부터 적용되어야 합니다. 프로덕션 환경에서 무언가 잘못된 후에 트레이싱 (tracing)을 추가한다면, 당신은 기록조차 남아있지 않은 실패를 디버깅하고 있는 셈입니다. 문제를 인지한 사람 앞에서 실시간으로 재현해야 하는 상황에 직면하게 될 것입니다.

AWS에서 관측성 레일은 세 가지 요소로 구성됩니다. X-Ray는 트리거부터 모델 호출, 도구 실행을 거쳐 출력에 이르기까지 엔드 투 엔드 (end-to-end) 분산 트레이스 (distributed trace)를 제공합니다. CloudWatch는 시스템이 완전히 망가지기 전, 성능이 저하되고 있음을 알려주는 지표 (metrics)를 전달합니다: 지연 시간 (latency), 토큰 사용량 (token usage), 컴포넌트별 에러율 (error rate) 등이 이에 해당합니다. 그리고 AWS Distro for OpenTelemetry는 제가 가장 강력하게 주장하고 싶은 부분인데, 그 이유는 텔레메트리 (telemetry)의 이식성을 유지해주기 때문입니다. CloudWatch로 직접 보내는 대신 OTel (OpenTelemetry)로 계측 (instrument)한다면, AWS가 아닌 다른 컴포넌트를 추가하는 날에 관측성 체계를 처음부터 다시 구축할 필요가 없습니다. 표준 (standard)은 벤더 (vendor)의 선택보다 오래 지속됩니다.

거버넌스 레일은 컴플라이언스 (compliance)를 허둥지둥 대응하는 작업에서 쿼리 (query) 한 번으로 해결되는 작업으로 바꿔줍니다. CloudTrail은 모든 모델 호출을 기록하며, 이는 누군가 "이 날짜에 시스템이 무엇을 했는가?"라고 물었을 때 감사 (audit)에 답변할 수 있게 해주는 핵심 요소입니다. AWS Config는 설정 드리프트 (configuration drift)를 포착하여, 지난달에 켜두었던 가드레일이 조용히 꺼지는 일을 방지합니다. IAM 조건 (conditions)은 "무엇이 무엇을 호출할 수 있는가"에 대한 세밀한 제어를 수행하며, 이는 에이전트 환경에서 보안 태세 (security posture)의 대부분을 차지합니다. 마지막으로 Security Hub는 네 개의 대시보드 대신 전체 그림을 한곳으로 모아줍니다.

이 중 흥미로운 것은 아무것도 없습니다. 바로 그것이 핵심입니다. 거버넌스(Governance)는 감사관이 나타나거나 사고가 발생하여 그것이 방 안의 유일한 화두가 되기 전까지는 지루한 일이며, 그때가 되면 로그(logs)가 있거나 없거나 둘 중 하나일 뿐입니다.

보안의 순간 (The security moment)

2026년 5월의 CISA KEV 목록은 깊이 있게 살펴볼 가치가 있습니다. 왜냐하면 바로 이 순간이 AI 게이트웨이(AI gateway)가 선택 사항이 아니게 된 시점이기 때문입니다.

KEV는 "알려진 취약점 (Known Exploited Vulnerabilities)"을 의미합니다. 이는 이론적인 CVE 목록이 아닙니다. 지금 이 순간 실제로 악용되고 있는 항목들의 목록이며, 이것이 바로 미국 연방 기관들이 KEV 항목에 대해 정해진 기한 내에 패치(patch)를 수행해야 하는 이유입니다. 특정 카테고리가 그곳에 등장하면 대화의 성격이 바뀝니다. AI 게이트웨이는 단순히 속도 제한(throttling)을 제공하는 편리한 도구에서, 반드시 갖추어야 할 보안 통제(security control)로 격상되었습니다.

AWS에서는, 배관 역할을 하는 API Gateway를 통해 인증(auth), 속도 제한(rate limiting), 스로틀링(throttling)을 처리하는 게이트웨이 레일(gateway rail)을 구축하고, 그 앞단에 AWS WAF를 배치하여 프롬프트 인젝션(prompt-injection) 패턴을 포함한 LLM 특화 공격 표면(attack surface)을 방어합니다. 엔터프라이즈 측면에서는 Bedrock Guardrails와 AgentCore Policy를 통해, 단순한 게이트웨이가 제공하지 못하는 콘텐츠 필터링(content filtering) 및 에이전트-도구 간 제어(agent-to-tool control) 기능을 제공합니다.

이제 맵(map)에 명시되지 않은 부분입니다. 해당 목록에 오른 것은 BerriAI의 LiteLLM으로, 하나의 인터페이스를 통해 100개 이상의 LLM 제공업체를 호출하는 데 사용되는 오픈 소스 AI 게이트웨이입니다. CISA는 2026년 5월 8일에 이를 CVE-2026-42208 (CVSS 9.3)로 KEV 카탈로그에 추가했습니다. 이는 프록시의 API 키 검증 과정에서 발생하는 SQL 인젝션(SQL injection) 취약점으로, 조작된 권한 부여 헤더(Authorization header)를 통해 인증되지 않은 호출자가 데이터베이스 데이터를 읽고 수정할 수 있는 문제입니다. 여기서 제가 스스로 수정할 부분이 하나 있습니다. 이 사건은 제가 처음에 생각했던 4월이 아니라 5월에 발생했습니다. 잘못된 날짜를 그대로 두기보다는 직접 바로잡고 싶습니다.

채택하지 말아야 할 것 (프레임워크 통합)

스택 맵(stack map)이 제공하는 또 다른 유용한 기능은 어디에 시간을 쓰지 말아야 할지를 알려주는 것입니다. 2026년 5월은 프레임워크 계층(framework layer)에 있어 매우 힘든 시기였습니다.

"압박을 받고 있다"는 말이 "월요일에 바로 삭제하라"는 뜻은 아닙니다. 만약 LangChain이 프로덕션 환경에서 잘 작동하고 있다면, 이 표를 마이그레이션 명령이 아닌 신규 프로젝트 (greenfield) 결정을 위한 가이드로 읽으십시오. 2026년 중반에 새로운 것을 시작할 때, 네이티브 Bedrock 경로가 충분히 발전했기 때문에 무거운 프레임워크를 찾는 것은 기본 설정이 아니라 정당화해야 하는 선택이 되었습니다. AutoGen은 유일하게 명확한 사례입니다. 그것은 사라졌으므로, 그 위에 새로 구축하는 것은 죽은 의존성 (dependency) 위에 구축하는 것과 같습니다.

이 지도를 신뢰하기 전에 재확인해야 할 사항

이 정보의 핵심 가치는 신뢰할 수 있는 큐레이션에 있으므로, 저는 제 매핑에 프로덕션 결정을 걸기 전에 테스트를 거치고 싶을 것입니다.

"GA (General Availability)"와 "귀하의 리전에서의 GA"는 서로 다른 사실이며, 저는 이 격차로 인해 이전에 고생한 적이 있습니다. 따라서 이것이 실제 발자취입니다. AgentCore Evaluations는 버지니아 북부, 오하이오, 오리건, 뭄바이, 싱가포르, 시드니, 도쿄, 프랑크푸르트, 아일랜드 등 9개 리전에서 실행됩니다. AgentCore의 정책 (Policy)은 서울, 런던, 파리, 스톡홀름을 추가하여 총 13개 리전을 커버합니다. 귀하의 계정이 다른 곳에서 실행 중이라면, 둘 중 하나를 기준으로 설계하기 전에 리전 표를 확인하십시오. 또한 프레임워크 통합에 관한 판단은 유효 기간이 6개월인 스냅샷으로 취급하겠습니다. 이 지도는 11월에 다시 그려질 것입니다. 5월에 확정된 것처럼 보이는 것 중 일부는 그렇지 않을 것입니다.

이것이 지도입니다. 9개의 수평 계층(horizontal layers)이 있으며 각각 이를 커버하는 AWS 서비스가 있고, 관측성 (observability)과 거버넌스 (governance)라는 두 개의 수직 레일 (vertical rails)이 있습니다. 최고의 팀들은 첫날부터 이 레일들을 연결하지만, 다른 모든 팀은 무언가 고장 난 후 100일째 되는 날에야 이를 추가합니다. 스택이 더 높게 성장하는 것을 멈춘 이유는 어려운 문제가 이동했기 때문입니다. 이제 문제는 "어떤 계층을 추가할 것인가"가 아닙니다. "시스템 전체가 실패했을 때 우리에게 진실을 말해주는가"입니다.

만약 여러분이 이 중 어떤 부분이라도 AWS 위에서 구축하고 있다면, 이를 한 단계 더 발전시킬 세 가지 방법이 있습니다. 여러분의 실천 수준을 선택하세요.

낮음 (Low): 이 표를 저장해 두세요. 그리고 다음에 누군가 AI 스택 (AI stack) 다이어그램을 보여준다면, 관측성 레일 (observability rail)이 어디에 있는지 물어보세요. 만약 그것이 레일이 아닌 단순한 박스 형태라면, 여러분은 그 간극을 찾아낸 것입니다.

중간 (Medium): 하나의 레일을 선택하여 다음 기능을 구현하기 전에 미리 연결해 두세요. ADOT를 통한 OpenTelemetry (OpenTelemetry) 도입은 단일 항목 중 가장 높은 수익률을 보장하는 움직임입니다.

높음 (High): 제가 제안한 AWS 선택 사항에 동의하지 않는 계층이 하나 있다면, 두 가지 방식을 모두 구축해 보고 어떤 것이 승리했는지, 그리고 그 이유는 무엇인지 저에게 알려주세요. 공로를 명시하여 지도를 업데이트하겠습니다.

저는 이것들을 공개적으로 매핑하며 때로는 틀리기도 합니다. 하지만 그것이 바로 공개적으로 진행하는 핵심적인 이유입니다. 만약 여러분이 노드 (node)를 다르게 매핑하고 싶다면, 댓글 창이 가장 좋은 소통 창구가 될 것입니다.

구축하라 (Build). 문서화하라 (Document). 공유하라 (Share). 반복하라 (Repeat).