AWS의 'AI만으로 돌아가는 가게' Living Mart로 배우는 Amazon Bedrock 2026 완전 가이드

2026년 6월, AWS Summit Japan 2026의 Builders' Fair에 조금 색다른 부스가 나와 있었습니다. **인간 점장이 없는 소매점 "Living Mart"**입니다. 매입도 가격 책정도 홍보도 접객도, 6개의 Claude 에이전트가 인간의 지시를 기다리지 않고 스스로 판단하며 가게를 통째로 돌리고 있었죠. 게다가 그것은 전시용 모형이 아니라, 방문객이 QR 코드로 실제로 쇼핑할 수 있는 "지금 돌아가고 있는 진짜 가게"였습니다.

이 데모가 흥미로운 건 겉모습의 임팩트만이 아닙니다. 그 뒷면은 Amazon Bedrock을 중심에 둔 AWS 매니지드 서비스의 조합으로 되어 있어서, 말하자면 "2026년의 Bedrock으로 AI 에이전트를 어디까지 실운영할 수 있는가"의 쇼케이스가 되어 있는 거예요.

그래서 이 글에서는 현역 엔지니어를 위해 다음 세 가지를 이어지는 흐름으로 풀어냅니다.

Amazon Bedrock 전체 기능 지도(2026년 6월판) — Knowledge Base에 연동할 수 있는 벡터 스토어부터 Guardrails, BDA, AgentCore까지 빠짐없이
OpenAI / Google 직접 API와 비교해 Bedrock이 유리한 점
Living Mart 아키텍처 완전 해부 — 1에서 본 기능들이 "실제로 무엇으로 조립되어 있는가"

"Bedrock이 결국 뭘 할 수 있는 거지?"를 정리하고 싶은 분에게도, 에이전트 기반을 선정 중인 분에게도 도움이 되는 내용을 목표로 합니다.

제1장 — Amazon Bedrock 전체 기능 지도(2026년 6월판)

Amazon Bedrock을 한마디로 말하면, **"다수의 파운데이션 모델과, 그것을 프로덕션 운영하기 위한 주변 기능을 단일 API와 IAM 아래에서 쓸 수 있게 한 풀 매니지드 서비스"**입니다. "LLM의 API 래퍼"라고 생각하면 2026년 현재의 모습을 잘못 보게 돼요. 모델 자체는 입구에 불과하고, RAG·안전성·데이터 처리·에이전트·평가·비용 최적화까지 생성형 AI 앱의 일생을 커버하는 기능군이 갖춰져 있습니다.

먼저 전체 그림을 한 장으로 정리했습니다.

아래에서 블록별로 살펴봅니다.

1-1. 추론 기반 — 100개 이상의 모델을 통일 API로

Bedrock의 토대는 "모델 선택지의 폭"입니다. 2026년 6월 시점에 Anthropic, Meta, Mistral, OpenAI, Amazon, Cohere, AI21, Stability AI, DeepSeek, Qwen 등 다수의 프로바이더가 제공하는 100개 이상의 모델을 단일 API로 호출됩니다. 대표적인 것을 꼽으면,

Anthropic Claude — 최상위 Opus 4.7은 100만 토큰(1M) 컨텍스트에 대응. 장시간 작업과 에이전트 용도의 핵심
OpenAI GPT-5.5 / GPT-5.4·Codex — 그렇습니다, OpenAI의 최신 모델조차 Bedrock 위에서 돌아갑니다(뒤에서 다룰 비교의 중요 포인트)
Meta Llama 4(Maverick / Scout) — Maverick은 1M 컨텍스트, Scout는 더 큽니다(Bedrock에서 3.5M)
Mistral Large 3(675B), Amazon Nova, DeepSeek, Qwen, Stability AI, Cohere, AI21 Labs 등

여기에 Amazon Bedrock Marketplace를 쓰면 카탈로그에 올라 있는 100개 이상의 전문·신흥 모델을 구독해 매니지드 엔드포인트에 배포하고, Agents·Knowledge Bases·Guardrails 같은 Bedrock 기능과 그대로 조합해 쓰게 됩니다. "일단 제일 똑똑한 모델로 만들고, 비용이 신경 쓰이는 부분만 소형 모델로 갈아 끼운다" 같은 운영이 코드 대수술 없이 굴러가는 거죠.

1-2. RAG — Knowledge Bases와 연동할 수 있는 벡터 스토어

주제로 지목된 "Knowledge Base에서 벡터 스토어로 연동할 수 있는 서비스"를 용도별로 정리합니다. Amazon Bedrock Knowledge Bases는 문서를 가져와 청크화·벡터화하고 RAG(검색 증강 생성)를 최소 구현으로 실현하는 매니지드 기능입니다. 청크화·임베딩·검색은 Knowledge Bases 쪽이 챙겨 주기 때문에, 어느 스토어를 골라도 상위 RAG 구현은 공통화돼요. 차이가 나는 것은 "비용·레이턴시·기존 자산과의 궁합·검색 종류"입니다.

2026년 6월 시점에 네이티브 대응하는 것은 다음 8가지입니다.

Amazon Bedrock 8개 벡터스토어 비교표

벡터 스토어	특징	적합한 사용 사례
OpenSearch Serverless	가장 범용적인 기본 선택. 서버리스로 빠르게 구축 가능. 전문 검색 + 벡터 검색을 결합한 하이브리드 검색에 강하며 바이너리 벡터를 지원.	고민된다면 가장 먼저 선택할 만한 옵션. 사내 지식 검색, FAQ 등 일반적인 RAG 전반. 키워드 검색과 의미 기반 검색을 함께 활용하고 싶은 경우.
OpenSearch Managed Cluster	클러스터를 직접 운영하는 방식. 용량과 비용을 세밀하게 제어할 수 있으며 바이너리 벡터를 지원.	이미 OpenSearch 클러스터를 운영 중이거나, 대규모 환경에서 성능과 용량을 직접 설계하고 싶은 경우.
S3 Vectors	가장 저렴한 서버리스 옵션. 서브초 응답을 제공하며 GA 기준 최대 90% 비용 절감을 목표로 함. ※ 일반 float 벡터만 지원하며 초대규모용 압축(Binary) 벡터는 지원하지 않음.	대규모 데이터이지만 조회 빈도가 낮은 아카이브형 RAG. 비용을 최우선으로 고려하거나 저렴하게 시작하고 싶은 경우.
Aurora PostgreSQL (pgvector)	기존 관계형 데이터베이스(RDB)와 동일한 DB에서 운영 가능. SQL 기반 메타데이터 필터링과 HNSW 인덱스를 지원.	기존 애플리케이션 DB에 벡터 검색을 추가하고 싶은 경우. 구조화 데이터와 함께 관리하거나 pgvector 운영 경험이 있는 경우.
Neptune Analytics (GraphRAG)	그래프와 벡터를 결합하여 엔터티 간 관계를 활용하는 GraphRAG를 구현.	문서 간 관계가 중요한 분야(법률, 의료, 공급망, 복잡한 FAQ 등).
Pinecone	관리형 전문 벡터 데이터베이스(서드파티). 뛰어난 확장성과 운영 편의성을 제공.	벡터 검색에 특화된 대규모 서비스를 구축하거나 이미 Pinecone을 사용 중인 경우.
Redis Enterprise Cloud	인메모리 기반의 매우 낮은 지연시간(Low Latency)을 제공하는 서드파티 서비스.	실시간 응답이 중요한 RAG. 기존 Redis 인프라를 적극 활용하고 싶은 경우.
MongoDB Atlas	문서형 데이터베이스에 벡터 검색을 통합한 서드파티 서비스. PrivateLink 연결도 지원.	MongoDB 기반 애플리케이션에 시맨틱 검색을 추가하고 싶은 경우. 문서 중심 데이터 모델을 사용하는 환경.

고르는 법을 대략 말하면, "고민되면 OpenSearch Serverless, 어쨌든 싸게 대규모라면 S3 Vectors, 기존 RDB가 있다면 Aurora(pgvector), 관계성을 살리고 싶다면 Neptune(GraphRAG)". 바이너리 벡터를 저장할 수 있는 것은 OpenSearch 계열뿐이라는 세세한 제약도 기억해 두면 도움이 됩니다.

⚠️ MemoryDB와 DocumentDB는 "쓸 수는 있지만" Knowledge Bases의 네이티브 대응이 아니다

여기가 자주 오해되는 포인트입니다. Amazon MemoryDB도 Amazon DocumentDB도 DB 단독으로는 벡터 검색 기능을 갖고 있습니다.

Amazon MemoryDB — HNSW 인덱스로 한 자릿수 밀리초·99% 초과 리콜, 최대 32,768차원까지 대응하는 초저지연 벡터 검색이 가능
Amazon DocumentDB — MongoDB 호환 API로 벡터 검색에 대응, 도큐먼트 DB에 시맨틱 검색을 더할 수 있음

다만 2026년 6월 시점에 이 둘은 Bedrock Knowledge Bases의 "내장 커넥터"에서 고를 수 있는 대상에 포함되어 있지 않습니다(앞서 든 8개 스토어가 공식 대응 목록). 따라서 MemoryDB/DocumentDB를 벡터 스토어로 쓰고 싶다면 Knowledge Bases의 매니지드 연동에 기대지 말고, 임베딩 생성·청크화·검색을 직접 구현하는 RAG 파이프라인을 짜게 됩니다. "초저지연이 요건이라 MemoryDB를 쓰고 싶다", "기존 DocumentDB를 그대로 쓰고 싶다" 같은 케이스에서는 Knowledge Bases를 거치지 않고 Bedrock의 임베딩 모델(Titan / Cohere)을 직접 호출하는 구성이 현실적인 해법입니다.

정리하면, "벡터 검색이 되는 DB" ≠ "Knowledge Bases가 네이티브 대응하는 벡터 스토어". 둘을 나눠서 보면 선정이 흔들리지 않습니다.

1-3. 안전성 — Bedrock Guardrails

모델을 프로덕션에 내보낼 때 피해 갈 수 없는 것이 안전성입니다. Amazon Bedrock Guardrails는 입출력에 대해 횡단적으로 정책을 적용하는 구조로, 주로 다음 기능을 갖고 있습니다.

콘텐츠 필터(멀티모달 대응) — 혐오·모욕·성적·폭력·부정행위·프롬프트 공격 등을 임계값과 함께 필터링. **이미지 콘텐츠에도 대응(GA)**해 텍스트와 같은 정책을 이미지에도 적용할 수 있습니다. 유해한 멀티모달 콘텐츠를 최대 88% 차단할 수 있다고 합니다
금지 토픽 — 업무상 다루게 하고 싶지 않은 화제를 차단
민감 정보(PII) 검출·마스킹 — 개인정보를 자동으로 가림
컨텍스트 그라운딩(Contextual grounding) — 참조 소스에 근거하지 않은 환각(할루시네이션)을 감지
Automated Reasoning checks — 여기가 2026년의 핵심. 형식 논리(수학적 기법)를 사용해 사실 오류를 검증·정정·설명하는, 생성형 AI 가드레일로서는 최초의 기능입니다. 최대 99% 정확도로 "왜 그 답이 옳은지/틀린지"를 구조적으로 피드백합니다. 2025년 11월에는 정책 검증용 테스트 Q&A를 자동 생성하는 기능도 추가되어, "정책을 쓴다→프로덕션에서 처음 엣지 케이스를 알아차린다"가 아니라 "쓴다→생성 테스트로 구멍을 찾는다→고친다→배포한다"라는 반복이 가능해졌습니다

Guardrails는 특정 모델에 묶이지 않고 어느 모델을 호출해도 같은 정책을 끼워 넣을 수 있다는 점이 효과적입니다. 나아가 ApplyGuardrail이라는 독립 API를 쓰면 Bedrock 밖에서 도는 모델(자체 호스팅이나 온프레미스 LLM)에도 같은 가드레일이 적용됩니다. "모델은 나중에 갈아 끼울지 모르지만 안전 정책은 하나로 묶고 싶다"는 요건에 잘 맞는 거죠.

유스케이스 — 금융·의료 등 규제 업종의 챗봇에서 PII를 자동 마스킹한다, 사내 어시스턴트에서 경쟁사나 인사 화제를 차단한다, 이미지 생성 서비스에서 유해 이미지를 차단한다, RAG의 답변이 참조 문서를 벗어나지 않았는지 컨텍스트 그라운딩으로 검증한다 등. Living Mart로 말하면 "원가 이하 판매를 허용하지 않는" 것은 ERP 쪽 책임이지만, 대화와 콘텐츠의 안전성은 이런 층에서 지킨다는 이미지입니다.

1-4. 비정형 데이터 처리 — Bedrock Data Automation(BDA)

**Amazon Bedrock Data Automation(BDA)**은 문서·이미지·음성·동영상 같은 비정형 멀티모달 콘텐츠에서 구조화된 인사이트를 자동 생성하는 기능입니다.

**Blueprint(JSON 스키마)**로 "무엇을 추출할지"를 선언적으로 정의
신뢰도 점수와 비주얼 그라운딩으로 추출 결과의 근거를 확인·감사할 수 있고, 신뢰도 낮은 결과만 사람 리뷰로 돌리는 운영이 가능
2026년 4월에는 **커스텀 어휘(custom vocabulary)**에 대응해 브랜드명·약어·전문 용어의 음성 인식/전사 정확도가 향상
현재 8개 리전(GovCloud US-West 포함)에서 GA

유스케이스 — 청구서·계약서·신청서에서 항목을 추출해 기간 시스템으로 흘려보낸다, 콜센터 통화 녹음을 전사+요약+감정 분석한다, 동영상 콘텐츠에 장면 분할·자막·모더레이션을 붙인다, 대량의 스캔 PDF를 검색 가능한 데이터로 바꾼다 등. RAG의 전처리(문서 구조화)에 직결되는 기능으로, 항목 추출처럼 정해진 형식이 필요한 처리는 BDA에 맡기고 레이아웃 분석 중심 부분은 Amazon Textract에 넘기는 하이브리드 비용 최적화 패턴도 자주 소개됩니다.

1-5. 에이전트 기반 — AgentCore와 Bedrock Agents

에이전트를 "만드는" 것뿐 아니라 "프로덕션에서 안전하게 계속 돌리기" 위한 기능이 최근 1~2년 사이 크게 확충되었습니다. 2026년 시점에서는 대략 두 층으로 이해하면 정리하기 쉬워요.

① Amazon Bedrock AgentCore(저수준·고자유도) 임의의 프레임워크(CrewAI / LangGraph / LlamaIndex / Strands / OpenAI Agents SDK 등)와 임의의 모델, MCP·A2A 같은 프로토콜로 에이전트를 돌릴 수 있는, 프로덕션 운영용 프리미티브 모음입니다. 주요 컴포넌트:

Runtime — 서버리스로 에이전트를 안전하게 배포·스케일. Python에 더해 Node.js도 매니지드 런타임으로 대응. → LangGraph 등으로 만든 에이전트를 인프라 관리 없이 프로덕션에 올리고 싶을 때
Memory — 세션 내 단기 기억과 세션을 넘나드는 장기 기억. → 사용자의 취향이나 과거 대화를 기억시키고 싶을 때
Gateway — 기존 API·Lambda·서비스를 MCP 대응 툴로 변환. 기존 MCP 서버 접속도 가능. → 사내 기존 API를 손대지 않고 에이전트의 툴로 열어 주고 싶을 때
Identity — OAuth 2.0 토큰 획득·캐시·갱신을 자동화. → 에이전트가 Google이나 Slack 등에 "사용자 대리"로 접근하게 하고 싶을 때
Browser / Code Interpreter — 샌드박스 안에서 웹 조작과 코드 실행. → 화면 조작 자동화나, 계산·데이터 가공을 코드로 정확히 시키고 싶을 때
Policy / Observability / Evaluations — 행동 제어, 모니터링, 품질의 지속 평가. → 프로덕션에서 에이전트 거동을 가시화·통제하고 품질 저하를 감지하고 싶을 때

포인트는 이것들이 모듈식이라 필요한 것만 단독 채택할 수 있다는 점(사용량 기반 과금). "프레임워크는 Strands, 배포는 Runtime, 기억만 Memory를 쓴다" 같은 부분 채택이 가능합니다. 2026년에는 서비스 쿼터가 올라가(활성 세션과 InvokeAgentRuntime TPS가 대폭 증가) 더 큰 워크로드도 견디게 되었습니다.

유스케이스 — 고객 지원 자동 응답, 사내 조사·리포트 작성 에이전트, 여러 전문 에이전트가 분담하는 업무 자동화, 외부 SaaS를 넘나드는 조작 대행 등. 프레임워크 비의존이라 PoC에서 쓴 OSS 프레임워크를 그대로 프로덕션 운영으로 가져갈 수 있는 것이 강점입니다.

② Bedrock Agents(매니지드·선언적) Action Groups(Lambda로 구현하는 툴 모음)와 Knowledge Base를 Bedrock에 넘기면 오케스트레이션과 추론 루프, 프롬프트 관리는 AWS 쪽이 챙겨 주는 "빨리 만들 수 있는" 타입. 고객 지원이나 문서 처리 같은 정석 워크플로를 빠르게 세우는 데 알맞습니다. 멀티 에이전트 협조에도 대응해, 수퍼바이저가 전문 에이전트들을 묶는 구성도 짜집니다. → 복잡한 오케스트레이션은 필요 없고 "툴+지식을 가진 에이전트"를 최단으로 세우고 싶을 때의 1순위. 반대로 독자적인 제어 흐름과 상태 관리를 세밀하게 쥐고 싶어지면 AgentCore로, 라는 역할 분담입니다.

고르는 법은 단순합니다. "일단 빨리 돌리고 싶으면 Bedrock Agents, 오케스트레이션과 상태 관리를 쥐고 싶은 복잡한 멀티 에이전트라면 AgentCore". 후자는 자유도가 높은 만큼 개발·유지 비용도 얹힙니다.

1-6. 개발·운영·비용 최적화

마지막으로, 만들고 재고 싸게 만들기 위한 기능군입니다.

Flows — 모델·프롬프트·AWS 서비스를 선으로 잇는 비주얼 워크플로. 버저닝으로 롤백과 A/B 테스트가 가능. → "분류→분기→요약" 같은 다단 처리를 노코드에 가깝게 짜고 비엔지니어와도 공유하고 싶을 때
Prompt Management — 프롬프트 작성·평가·버전 관리. Prompt Optimization으로 정확도·간결함을 자동 개선하고 모델 이전도 지원. → 프롬프트를 코드 곳곳에 흩뜨리지 않고 자산으로 일원 관리하며 개선 이력을 남기고 싶을 때
Evaluations — 모델과 RAG 평가를 체계적으로 실시. → 모델 선정이나 RAG 개선 전후로 정확도·비용을 정량 비교하고 싶을 때
Model Distillation — 상위 모델의 정확도를 유지한 채 소형·고속·저비용 모델로 증류. 최대 500% 고속·최대 75% 저비용, RAG 용도라면 정확도 저하 2% 미만이라고 합니다. → 고품질 모델로 만든 것을 양산 단계에서 싸고 빠르게 돌리고 싶을 때
Intelligent Prompt Routing — 같은 모델 패밀리 안에서 요청별로 최적 모델에 자동 라우팅. 품질을 지키면서 비용을 최대 30% 절감. → 쉬운 질문은 소형, 어려운 질문은 상위로 자동 배분해 비용을 낮추고 싶을 때
그 밖에 Provisioned Throughput(스루풋 예약), 배치 추론(대량 처리를 비동기로 저렴하게), 크로스 리전 추론(리전을 넘나들며 용량과 레이턴시 확보), Custom Model Import(자체 파인튜닝 모델 반입) 등

이 운영계 기능들은 **"먼저 똑똑한 모델로 만들고, 프로덕션에서 재고, 싸고 빠르게 다듬어 간다"**는 생성형 AI 앱의 라이프사이클을 그대로 커버합니다. 제2장에서 다룰 "Bedrock의 우위" 상당수는 이런 주변 기능이 같은 API·IAM 안쪽에 갖춰져 있다는 데서 나옵니다.

여기까지가 "Bedrock 전체 기능 지도"입니다. 중요한 것은 이들이 뿔뿔이 흩어진 제품이 아니라 같은 API·같은 IAM·같은 VPC 아래에서 맞물린다는 점. 다음 장에서 그 "묶는 방식"이 그대로 경쟁 우위가 되는 이유를 봅니다.

제2장 — 직접 API(OpenAI / Google)와 비교해 Bedrock이 유리한 점

"Claude나 GPT를 쓰고 싶을 뿐이라면 각사의 API를 직접 호출하면 되지 않나?" — 당연한 의문입니다. 개인 개발이나 작은 PoC라면 그 말대로이고, 직접 API의 간편함은 큰 매력이죠. 하지만 기업 시스템에 짜 넣는 단계가 되면 Bedrock 경유에는 직접 API에 없는 우위가 여럿 드러납니다.

데이터가 내 AWS 계정 밖으로 나가지 않는다

가장 큰 차이가 여기입니다. Bedrock에서는 모델 호출이 내 AWS 계정/VPC 안쪽에서 완결되고, PrivateLink를 쓰면 트래픽을 공용 인터넷에 내보내지 않아도 됩니다. 게다가 Bedrock은 당신의 데이터를 파운데이션 모델 학습에 일절 사용하지 않습니다.

한편 OpenAI 등의 직접 API에서는 프롬프트와 데이터가 각사 서버로 전송됩니다. 학습에 쓰지 않는다고 표명해도 데이터는 자사 인프라 밖으로 나가고, 부정 이용 감시를 위해 일정 기간 보관된다(옵트아웃은 계약 티어에 따라 다름)는 차이가 있어요. 규제 업종에서는 이 "데이터가 어디에 있는가"가 채택 여부를 가릅니다.

기존 AWS 거버넌스를 그대로 적용할 수 있다

Bedrock은 AWS의 한 서비스이므로 IAM의 세밀한 접근 제어, CloudTrail의 감사 로그, KMS의 저장·전송 시 암호화가 다른 AWS 리소스와 같은 틀에서 작동합니다. "AI만 따로 세워서 보안을 관리할" 필요가 없어요. 직접 API라면 인프라 보안과 별개로 AI 부분의 접근 관리·감사를 직접 짜야 합니다.

컴플라이언스

Bedrock은 SOC 1~3, HIPAA 적격성, PCI DSS, FedRAMP(정부용), GovCloud 등 주요 컴플라이언스 프레임워크에 대응합니다. 감사와 인증이 필요한 현장에서 토대가 이미 인증을 받아 두었다는 가치는 큽니다.

멀티 모델 × 통일 API — 그리고 "OpenAI의 최신 모델조차 돌아간다"

Bedrock의 사상은 "단일 벤더에 록인되지 않는 것". Claude·Llama·Mistral·Nova·DeepSeek 등 다수의 모델을 통일 API로 나눠 호출하고 코드를 거의 바꾸지 않은 채 갈아타게 됩니다. 용도별로 "고난도는 Claude Opus, 대량 처리는 소형 모델, 다국어는 Mistral" 같은 최적 배치가 현실적입니다.

상징적인 것은 OpenAI의 GPT-5.5 / GPT-5.4·Codex까지 Bedrock 위에서 제공된다는 사실. 게다가 그것들은 IAM 기반 접근 관리·PrivateLink·Guardrails·암호화·CloudTrail 로그 같은 Bedrock의 엔터프라이즈 통제를 그대로 이어받습니다. "OpenAI 모델을 쓰고 싶지만 데이터 통제는 AWS로 쥐고 싶다"는 바람이 Bedrock에서는 동시에 충족되는 거죠.

AWS 서비스와의 네이티브 통합

Lambda·S3·Aurora·Step Functions·OpenSearch 등과 이어진 채로 짤 수 있다는 것도 실무상의 강점입니다. 다음 장의 Living Mart가 바로 이 통합성을 체현하고 있는데, "모델 호출"과 "업무 시스템", "영속화", "워크플로"가 같은 클라우드 안에서 느슨하게 맞물립니다.

비교를 한 장으로

Amazon Bedrock와 OpenAI / Google 직접 API 비교

항목	Amazon Bedrock 사용	OpenAI / Google 직접 API
데이터 위치	자체 AWS 계정 및 VPC 내부에서 처리. 입력 데이터는 모델 학습에 사용되지 않음.	OpenAI 또는 Google 서버로 전송됨.
네트워크	AWS PrivateLink를 통한 비공개 네트워크 연결 지원.	일반적으로 공용 인터넷을 통해 통신.
접근 제어 및 감사	IAM, CloudTrail, KMS로 인증, 권한 관리, 감사 로그를 통합 관리.	AI 서비스에 대한 권한 관리와 감사 체계를 별도로 구축해야 함.
규정 준수(Compliance)	SOC, HIPAA, PCI DSS, FedRAMP, GovCloud 등 AWS 규정 준수 체계 활용.	지원 범위는 각 AI 서비스 제공업체 정책에 따라 달라짐.
모델 선택	100개 이상의 다양한 모델을 하나의 API로 사용 가능(Claude, GPT 계열, Llama, Nova 등).	해당 업체에서 제공하는 모델 중심으로 사용.
모델 교체	동일한 Bedrock API를 유지한 채 모델만 변경 가능해 코드 수정이 거의 필요 없음.	다른 제공업체로 변경하면 API와 코드 재구현이 필요한 경우가 많음.
부가 기능	Guardrails, Knowledge Bases, Agents 등 AWS AI 기능이 통합 제공.	각 기능을 개별 서비스와 직접 연동하여 구성해야 함.

공평하게 — 직접 API가 유리한 장면도 있다

그렇다고 뭐든 Bedrock이 위라는 얘기는 아닙니다. 최신 모델과 신기능은 제공사의 직접 API에 먼저 투입되는 경우가 많아, 최첨단 기능을 가장 빨리 만져 보고 싶다면 직접 API 쪽이 빠를 때가 있습니다. 소규모 검증이나 개인 개발에서는 AWS 권한 설계를 갖추는 수고보다 직접 API의 즉시성이 이기는 장면도 많겠죠. "데이터 통제·거버넌스·복수 모델 운영"이 무거워질수록 Bedrock의 상대적 우위가 커진다 — 이 이해가 실태에 가깝습니다.

제3장 — Living Mart 아키텍처 완전 해부

지금까지의 기능들이 "실제로 어떻게 조합되는가"를, 서두의 Living Mart로 살펴봅니다.

이것은 무엇의 데모인가

Living Mart는 AWS가 AWS Summit Japan 2026(2026년 6월 25~26일·마쿠하리 멧세, Builders' Fair)에서 공개한, AI가 자율 경영하는 소매 점포 데모입니다. 방문객은 QR 코드로 진짜 EC 사이트에서 쇼핑이 가능하고, AI가 기획·촬영·가격 책정한 상품이 진열됩니다. 가게를 돌리는 것은 6개의 Claude 에이전트로, 전부 Amazon Bedrock 위에서 동작. 상품 이미지 생성에도 Bedrock의 이미지 생성 모델(그리고 추첨 스티커용으로 Stability AI 모델)이 쓰였습니다. 그리고 이 가게는 서밋 회기 후에도 그대로 가동을 이어 가고 있습니다.

역할은 다음 6개. 사내 5개+사외 1개가 Slack 같은 채팅으로 연계합니다.

CEO(경영) — KPI를 보고 방침을 정해 각 에이전트에 전략을 전달
Ops(운영) — 상품 기획·발주·재고·가격 설정·매출 분석
PR(홍보) — EC 사이트를 직접 편집해 배포, 판촉·동선 개선
Concierge(접객) — 방문객의 목소리를 듣고 요청과 협상 내용을 경영 쪽에 전달
Signage(광고) — 재고·매출을 보고 행사장 모니터의 광고를 자율 갱신
Vendor(사외·매입) — 다른 회사의 거래처. 발주를 받아 상품 이미지를 만들어 출하한다

설계 사상 — "똑똑함"보다 "부서지지 않는 상자"

Living Mart의 출발점은 Anthropic의 Project Vend(Claude에게 실재하는 스낵 가게를 약 1개월간 경영시킨 실험)입니다. 결과는 처음에 적자 — 원가 이하로 팔고, 부탁받을 때마다 값을 깎아 주고, 때로는 사실이 아닌 이야기를 믿어 버렸죠. 교훈은 "intelligence alone doesn't run a store"(똑똑함만으로는 가게가 돌아가지 않는다), 발판=하네스가 필요하다는 것. 후속편에서 툴과 절차·조직을 더하자 흑자화로 향했고, **"bureaucracy matters"(구조는 중요하다)**라는 배움이 남았습니다.

또 하나의 배경이 Rich Sutton의 "The Bitter Lesson". "인간의 지식을 세밀하게 만들어 넣는 것보다, 계산(스케일)에 건 범용적 기법이 마지막에 이긴다"는 역사적 관찰입니다.

여기서 Living Mart의 설계 판단이 도출됩니다. 똑똑한 프롬프트나 세밀한 절차서를 만들어 넣지 않는다. 그 대신 "부서지지 않는 상자"에 투자한다. 모델이 똑똑해질수록 만들어 넣은 것은 낡아 가지만, 견고한 인프라·깨지지 않는 업무 규칙·에이전트용의 단순한 툴은 모델이 진화할수록 힘을 발휘하는 토대가 된다 — 이런 베팅입니다. 역할 분담조차 고정하지 않고 에이전트끼리의 합의에 맡기고 있어요.

아키텍처의 4개 기둥

전체 그림은 이렇습니다.

Living Mart 아키텍처

제1장의 기능과 짝지으면 이해하기 쉬우니, 네 기둥으로 정리합니다.

① 비즈니스의 하네스(부서지지 않는 상자): API Gateway + Lambda + Aurora 비즈니스 규칙은 AI에 대한 "지시"가 아니라 독립된 기간 시스템(ERP)의 API와 DB 제약으로 굳혀져 있습니다. 에이전트는 바깥에서 API를 호출할 뿐이고, 규칙 위반 조작은 시스템이 확실하게 거부합니다. 방문객과의 가격 협상에서 AI가 요청에 응해도 원가 이하 판매는 시스템이 허가하지 않습니다. 재고·매출·정합성은 여기서 일원 관리되어, AI가 틀려도 "업무로서" 파탄 나지 않아요. 이 느슨한 결합 — 판단하는 AI와 규칙을 강제하는 ERP의 분리 — 가 설계의 핵심입니다.

② 자기 영속 루프: Step Functions + Fargate on ECS 보통의 채팅 AI는 질문받은 순간만 움직이고 사라지지만, Living Mart는 다릅니다. 1턴 실행 → 일단 종료 → 다시 기동을 Step Functions가 계속 돌려서, 가게가 열려 있는 동안 내내 "계속 생각"합니다. 실행 환경은 Fargate on ECS로 매 턴 새로 세워지기 때문에 지시가 없어도 가동이 이어집니다.

③ 영속하는 기억: Amazon S3 + Claude Agent SDK의 Auto Memory 매 턴 새 환경에서 기동하는 이상, 본래 턴을 넘나드는 기억은 사라집니다. 그래서 S3를 기반으로 한 영속 파일 영역을 각 에이전트에 마운트하고 세션 이력·요약된 지식(Auto Memory)·작업 영역/공유 문서를 써냄으로써 전날의 판단을 당일로 이어받습니다. "낮에는 업무를 하고 퇴근할 때 기록을 남긴다"에 가까운 구조예요.

④ 추론 기반: Amazon Bedrock(Claude) 각 에이전트의 두뇌. Bedrock 경유로 Claude를 호출해 판단을 생성합니다. 제1장에서 본 "통일 API로 안전하게 호출한다"가 그대로 토대가 되어 있습니다.

무인 운영을 지탱하는 다층 자동 복구(L1→L5)

장시간 무인 가동에서는 "응답이 막힌다·프로세스가 비정상 종료된다"를 전제로 설계해야 합니다. Living Mart는 타임아웃과 복구를 5층으로 겹쳐, 어느 한 층이 감지하면 자동 복귀하는 구성입니다. 안쪽일수록 반응 주기가 짧고 바깥쪽일수록 긴 "겹겹의 계단"으로 되어 있어요.

L1: 애플리케이션 감시(최내측) — 일정 시간 툴 호출이 끊기면 응답 정지로 판단해 안전하게 중단
L2: 컨테이너 안전 정지 — 중단 후 프로세스를 정상 종료하고 다음 턴으로
L3: 태스크 단위 타임아웃(결정타)
L4: 실행 전체 타임아웃
L5: 이벤트 구동 리바이버(최외측 보험) — 실행 체인의 정지를 이벤트로 감지해 외부에서 재기동

안쪽이 먼저 작동하고, 작동하지 않으면 한 단계 바깥이 이어받는다. 이것도 "부서지지 않는 상자"의 일부입니다.

창발한 "조직다움"

첫날(Day 0)의 기록에서는 상품도 재고도 0인 상태에서 6개가 기동해, 인간의 지시 없이 약 20분 만에 판매 개시 체제를 만들었습니다. CEO가 자기 안보다 Ops의 안을 채택해 실행 권한을 넘기는 자연스러운 권한 위임, 주문이 막혔을 때 5개가 절차서 없이 협조하는 자율적인 인시던트 대응이 관측되었습니다. 세세한 단계를 적어 두지 않았는데도 역할 분담·위임·트러블 대응이 에이전트끼리의 합의에서 생겨났다 — 이 "조직다움의 창발"이 볼거리입니다.

엔지니어의 관전 포인트 — AgentCore를 "쓰지 않는다"는 선택

여기가 이 글의 하이라이트입니다. 제1장에서 AgentCore라는 프로덕션 에이전트 기반을 소개했지만, Living Mart는 AgentCore를 쓰지 않고 AWS의 매니지드 프리미티브(Step Functions / Fargate / S3 / API Gateway / Lambda / Aurora)와 Claude Agent SDK를 조합해 자율 루프를 구성하고 있습니다.

이것은 모순이 아니라 설계 사상의 표현입니다. AgentCore는 "Runtime·Memory·Gateway…를 매니지드로 묶는" 고속 노선. 한편 Living Mart는 "부서지지 않는 상자에 투자하고 안은 모델에 맡긴다"는 베팅에 맞춰 검증을 거친 기존 매니지드 서비스를 느슨하게 조합하는 노선을 택했습니다. 어느 쪽이 정답이라는 것은 없고, Bedrock 생태계에는 두 길이 모두 마련되어 있다는 것이 엔지니어에게는 배움입니다.

그리고 기술적 메시지는 이렇습니다. Claude Agent SDK의 기능(Auto Memory·Skills·스케줄 실행·멀티 에이전트 연계)은 코딩 에이전트만의 것이 아니라, "업무를 통째로 자율로 돌리는" 에이전트에도 그대로 쓸 수 있다. 점포 운영은 하나의 예에 불과하고, 본질은 "규칙을 정의할 수 있는 모든 업무를 판단과 실행의 루프째 AI에 맡기는 기반"입니다. 재고 관리·고객 지원·사내 오퍼레이션 — 당신이 매일 되풀이하는 업무를 통째로 자율 루프에 태우면 무슨 일이 일어날까. Living Mart는 그 물음에 대한 "돌아가고 있는 답"인 것입니다.

정리

3개 장을 관통하는 하나의 선은, **"2026년의 Bedrock은 모델을 호출하기만 하는 곳에서, 업무를 통째로 자율로 돌리는 기반으로 진화했다"**는 것입니다.

제1장: Bedrock은 모델(100+)·RAG(다양한 벡터 스토어)·안전성(Guardrails / Automated Reasoning)·데이터 처리(BDA)·에이전트(AgentCore / Bedrock Agents)·운영(Flows / 증류 / 라우팅)을 단일 API·단일 IAM 아래에서 묶고 있다.
제2장: 데이터 주권·거버넌스·컴플라이언스·멀티 모델이라는 "기업에서 돌릴수록 힘을 내는" 축에서 직접 API 대비 우위가 있다. OpenAI의 최신 모델조차 Bedrock에서 돌아간다는 것이 상징적.
제3장: Living Mart는 그 기능들을 "부서지지 않는 상자(ERP)+자기 영속 루프+영속 메모리+Bedrock"이라는 느슨한 결합 구성으로 구현해, AgentCore 없이도 프로덕션급 자율 에이전트를 짤 수 있음을 보여 줬다.

"똑똑한 모델을 쓴다"에서 "똑똑한 모델에 업무를 맡기고, 부서지지 않는 상자만 인간이 마련한다"로. Living Mart는 그 전환점을 누구나 그려 볼 수 있는 "가게"라는 소재로 보여 주었습니다. 다음에 자율 루프에 태울 것은 당신의 어떤 업무일까요?

참고 링크

Living Mart 공식 사이트: https://d2h7va0xxap4hk.cloudfront.net/
AWS Summit Japan 2026 블로그 「AI가 경영하는 가게에서 쇼핑하지 않겠습니까?」: https://aws.amazon.com/jp/blogs/news/
Project Vend(Anthropic): https://www.anthropic.com/research/project-vend-1 / https://www.anthropic.com/research/project-vend-2
Vending-Bench 2(Andon Labs): https://andonlabs.com/evals/vending-bench-2
Amazon Bedrock 공식: https://aws.amazon.com/bedrock/
Amazon Bedrock AgentCore: https://aws.amazon.com/bedrock/agentcore/
Amazon Bedrock Guardrails: https://aws.amazon.com/bedrock/guardrails/
Amazon Bedrock Data Automation: https://aws.amazon.com/bedrock/bda/