공급망 (Supply Chain) 시나리오 상에서, Bedrock AgentCore를 사용한 멀티 에이전트 (Multi-agent)를 수정해 나가는 핸즈온 시험이다. 이론 선택식이 아니라, 이미 고장 나 있는 공급망 챗봇을 콘솔 상에서 수정하는 형식이며, 범위는 Bedrock AgentCore (Runtime/Gateway/Memory), Cognito, VPC, OpenSearch, Lambda 등이다. 체감 난이도는 중상급~상급 정도이며, 서버리스 계열의 시험보다 개념 레이어 (Concept layer)가 두껍다. 멀티 에이전트 (Multi-agent)・RAG・MCP・VPC를 한꺼번에 직접 다뤄보고 싶은 사람, 콘솔 기반의 핸즈온을 좋아하는 사람에게 추천할 수 있다.

시험을 한마디로 요약하면 「문서를 읽고, 콘솔에서 올바른 리소스를 올바른 값으로 연결할 수 있는가」를 묻는 것이다. 큰 흐름은 다음과 같다.

에이전트 Runtime을 VPC 안에 넣고, PrivateLink로 서비스를 연결하는 것부터 시작한다. 이어서 Cognito로 머신 간 (M2M) OAuth를 맞추어 Chat Lambda와 Orchestrator를 접속하고, AgentCore Gateway로 툴 (Tool, 물류·품질 등)의 라우팅 (Routing)을 수정한다. 그다음 Knowledge Base와 KB Specialist 에이전트를 생성하여 Orchestrator에 A2A로 접속하고, AgentCore Memory로 대화가 지속되도록 설정한다. 과제가 계속될 경우 마지막으로 Bedrock Guardrails로 콘텐츠 안전 대책을 추가한다.

사용자에게 보이는 화면은 Chat (CloudFront) 하나뿐이지만, 뒷단에서는 Runtime, Gateway, Cognito, OpenSearch, Lambda, VPC Endpoint가 하나의 선으로 연결되어 있다. 그 때문에 한 곳의 설정만 틀려도 검증 메시지가 전혀 다른 레이어를 가리키는 것처럼 보일 때가 있다.

실무 감각이 살아있는 시험이다. 에이전트를 하나 배포하는 것이 아니라, 인증·네트워크·툴·RAG·메모리가 동시에 요구된다. 검증이 동작 기반이므로, 설정만 맞으면 Chat UI에서 결과를 즉시 체감할 수 있다. AgentCore 콘솔은 처음에는 익숙하지 않더라도 패턴 (Runtime 환경 변수 설정 → READY 대기 → Chat 테스트)을 파악하면 이후 속도가 올라간다.

콘솔 UI가 비슷한 옵션을 여러 개 보여준다. 예를 들어 Managed Knowledge Base와 Unstructured Vector Store KB는 혼동하기 쉽고, Cognito에서도 사용자 인증 플로우와 OAuth client_credentials (M2M) 플로우가 헷갈릴 수 있다. 에러 메시지는 정직하지만, 실제 원인이 있는 장소와는 동떨어져 보이는 경우가 많다. 예를 들어 「M2M 클라이언트를 찾을 수 없다」는 메시지가 나와도, 실제 문제는 커스텀 스코프 (Custom scope) 설정인 경우가 있다. Runtime의 업데이트, KB Sync, Memory 추출은 모두 비동기 처리이기 때문에, 즉시 검증하면 실패하기 쉽다.

체감 난이도는 중상급~상급이다. 서버리스 계열의 시험보다 개념 레이어는 두껍지만, 그 대신 「단번에 막히는 퀴즈」보다는 「연결 실수」로 시간을 허비하는 경우가 더 많다. 미리 함정을 알고 있다면 체감 난이도는 크게 낮아진다.

Public Runtime을 VPC로 옮기고, Gateway / AgentCore Data Plane / Bedrock Runtime / Logs용 Interface Endpoint를 구성한다. Cognito처럼 엔드포인트가 없는 서비스는 NAT를 경유하여 외부로 나가야 한다. Orchestrator만 있고 KB Specialist Runtime이 아직 존재하지 않는 상태일 때가 있는데, 검증에서 「KB Specialist Runtime을 찾을 수 없다」고 나오면, VPC 설정 문제가 아니라 리소스 자체가 아직 생성되지 않은 경우가 많다.

손상된 App Client를 수정하고, Gateway와 Runtime JWT의 allowedClients, Chat Lambda의 환경 변수를 서로 일치시킨다. App type은 반드시 Machine-to-machine이어야 하며, OAuth 흐름은 client_credentials와 Client Secret의 조합이어야 한다. Scope는 실습(Lab)에서 요구하는 supplychain 관련 read/write 스코프여야 하며, 기본으로 생성되는 default-m2m 스코프만 남겨두면 검증이 실패한다. COGNITO_DOMAIN 값에 https://가 누락되면 「unknown url type … oauth2/token」과 같은 오류가 발생하며, JWT Audience에는 토큰 URL을 넣어서는 안 된다.

GATEWAY_URL은 Target 이름이 아니라, Gateway 상단의 MCP endpoint(.../mcp) 주소이다. Logistics Target ARN을 수정하고, Quality Target을 스키마와 함께 새로 생성한다. Tool schema는 반드시 S3 URI 형식이어야 하며, HTTPS Object URL을 넣으면 동작하지 않는다.

가장 시간을 많이 소비하기 쉬운 구간이다. Managed KB(Quick create) 방식을 선택하면, 기존의 OpenSearch를 사용한다는 요구 사항과 충돌할 수 있다. Unstructured Vector Store KB를 선택한 후 기존의 벡터 스토어(OpenSearch Serverless)로 들어가 Collection ARN, Index, 실제 필드 이름을 정확하게 지정해야 한다. Field mapping은 추측하지 말고, OpenSearch Index 화면에서 knn_vector 필드 이름을 직접 확인한 후 입력해야 한다. 그럴듯한 이름(예: bedrock-knowledge-base-default-vector)을 적당히 입력하면 즉시 오류가 발생한다. Collection ARN을 KMS 암호화 입력란에 넣으면 정규 표현식(Regular Expression) 오류가 발생하는데, 해당 칸은 KMS Key ARN 전용이다. KB를 생성한 후에는 반드시 Data source Sync를 실행해야 하며, 실행하지 않으면 검증이 실패한다. KB Specialist에는 JWT Authorizer와 KNOWLEDGE_BASE_ID, MODEL_ID 환경 변수가 필요하며, Orchestrator에는 KB_SPECIALIST_RUNTIME_ARN이 필요하다.

Memory 리소스와 Semantic / Preferences / Summarization 전략, Namespace를 맞춘 후, Orchestrator에 MEMORY_ID를 넣는다. 설정이 모두 맞더라도 Observability 지표가 0으로 보인다면, 대부분 설정 실수가 아니라 Chat 메시지를 아직 보내지 않았거나 처리에 필요한 대기 시간(약 60초)을 채우지 않은 경우이다.

Word filter, PII/Regex 필터, Content filter(HIGH)를 생성하고, Orchestrator에 GUARDRAIL_ID를 연결한다. GUARDRAIL_VERSION=DRAFT가 이미 준비되어 있는 경우가 많다.

체감상 가장 시간이 오래 걸린 구간은 단연 Knowledge Base였다. 타입 선택, field mapping, Sync, JWT 설정까지 여러 단계가 겹치기 때문이다. VPC, OAuth, Gateway 구성은 세세한 함정에만 주의하면 비교적 직관적으로 진행할 수 있었다. Memory는 설정 자체는 짧지만, 대기 시간과 테스트 공정을 잊으면 실패하기 쉬운 구간이었다.

시험이 시작되면 VPC, Subnet, Security Group, Cognito, S3, ARN, OpenSearch Collection과 같은 값들을 미리 표로 정리하여 복사해 두는 습관이 도움이 된다. User Pool ID의 i와 l 같은 오타나, https:// 누락으로 인해 1시간을 허비하기 쉽기 때문이다.

선택지가 두 개 이상 보일 때, 콘솔이 권장(Recommended)이라고 표시하는 쪽이 항상 정답은 아니라는 점을 기억해야 한다. 이 시험에서는 기존의 OpenSearch, M2M client_credentials, Unstructured KB와 같이 상대적으로 불편한 쪽이 정답인 경우가 종종 있었다.

Runtime (런타임)을 저장한 후에는 반드시 READY 상태가 될 때까지 기다려야 한다. 검증 과정은 UPDATING 상태에 대해 관대하지 않으며, KB Specialist와 Orchestrator 각각에 어떤 환경 변수 (Environment Variable)를 넣어야 하는지 혼동하지 않도록 주의해야 한다.

검증 실패 메시지는 말 그대로 믿는 것이 좋다. "M2M 클라이언트를 찾을 수 없습니다"라는 메시지는 Cognito App Client의 타입, OAuth 플로우, 스코프 (Scope) 설정을 먼저 확인해야 한다는 신호다. "unknown url type … oauth2/token" 에러는 COGNITO_DOMAIN에 https://가 누락되었다는 의미이다. 예상한 S3 버킷의 KB가 없다는 메시지는 Data source URI, Sync (동기화) 여부, KB 타입을 재확인해야 한다는 의미이며, knn_vector type 에러는 OpenSearch Index의 실제 vector 필드명을 확인하라는 신호이다. JWT Authorizer가 없다는 메시지는 KB Specialist의 Inbound Auth 설정을 확인해야 한다는 의미이고, 메모리 레코드 (Memory record)가 없다는 메시지는 Chat을 한 번 전송하고 60초를 기다렸는지 확인하라는 의미이다. KB Specialist Runtime이 없다는 메시지는 우선 실제로 Runtime 목록에 해당 리소스가 존재하는지부터 확인해야 한다.

일부 알림(예: s3files:ListFileSystems 관련)은 실습(Lab)에서 무시하도록 명시되어 있는 경우가 많으므로, 권한·비용 관련 노이즈와 실제 검증 실패 메시지를 구분할 필요가 있다. 자동 검증만 돌리지 말고, Chat UI를 수시로 열어 Gateway 도구, KB에 대한 질문, Memory의 선호 문구, Guardrail의 차단 동작을 직접 확인하는 습관이 원인 파악에 도움이 된다.

시간 배분 측면에서는 VPC, OAuth, Gateway 구간은 세세한 함정에만 주의하면 비교적 원활하게 진행되므로, Knowledge Base에는 여유 있게 시간을 남겨두는 것이 안전하다. Memory는 설정 자체보다 대기 및 테스트를 잊지 않는 것이 중요하다.

시험 전에 콘솔에서 미리 다뤄보면 좋은 항목으로는 Cognito App Client의 M2M / client_credentials / custom scopes 설정, VPC Interface Endpoint와 Private DNS, 기존 OpenSearch Serverless와 연결하는 Bedrock Knowledge Base, OpenSearch Serverless Index의 vector field 확인, Lambda 및 AgentCore Runtime의 환경 변수 수정과 배포 상태 (READY) 확인 등이 있다. AgentCore 자체는 익숙하지 않더라도 IAM, VPC, Cognito, S3, Lambda의 기초가 뒷받침되지 않으면 원활하게 진행할 수 없다.

경험상 자주 발생하는 실수는 다음과 같다. Managed KB (Quick create)로 생성하여 "기존의 OpenSearch"를 사용해야 하는 요구사항을 맞추지 못하는 경우, Collection ARN을 KMS Key 입력란에 넣는 경우, Vector field 이름을 추측해서 넣는 경우, KB Sync를 수행하지 않는 경우, Cognito를 M2M으로 만들었다고 생각하지만 실제로는 기본 스코프만 남아 있는 경우, COGNITO_DOMAIN에 https://가 누락된 경우, JWT Audience에 /oauth2/token URL을 넣는 경우, GATEWAY_URL에 Target path를 넣는 경우, Agent의 소스에서 "S3에 업로드"를 선택해야 하는데 이미 S3에 있는 zip 파일을 찾으려고 하는 경우, 그리고 Memory 설정만 마치고 Chat 전송과 60초 대기 없이 검증을 진행하는 경우이다.

멀티 에이전트 (Multi-agent), RAG, MCP, VPC를 한 번에 직접 다뤄보고 싶은 사람, 콘솔 기반의 핸즈온 (Hands-on)을 선호하는 사람, 에러 메시지를 읽고 수정하는 작업에 익숙한 사람에게 추천한다. 반대로 Cognito, VPC, IAM의 기초가 거의 없는 상태이거나, AgentCore 콘솔을 처음 여는 당일에 갑자기 시험을 치르려고 하는 경우, 혹은 "권장 옵션만 누르면 된다"라고 생각하는 경우에는 사전 준비를 더 철저히 한 후에 응시하는 것이 좋다.

이 시험은 화려한 프롬프트 엔지니어링 (Prompt Engineering)을 묻는 시험이 아니라, 에이전트 (Agent)가 실제로 작동하도록 만드는 인프라 (Infrastructure)와 연결 (Connection)을 묻는 시험이다. 막혔을 때는 복잡한 아키텍처 (Architecture)를 다시 그리기보다, 평소에 다음 네 가지 중 하나를 의심하면 된다. 값의 오타나 잘못된 필드에 붙여넣은 ARN, 유사한 UI 옵션을 잘못 선택한 경우, READY/Sync/60초 대기를 건너뛴 경우, 그리고 오케스트레이터 (Orchestrator)와 스페셜리스트 (Specialist)를 혼동한 경우이다.

준비할 때는 정답을 암기하기보다 "에러 메시지 (Error Message) → 어느 계층 (Layer)의 문제인가"를 연습해 두는 것이 당일 멘탈 관리에 큰 도움이 된다. 서버리스 (Serverless) 계열의 시험을 먼저 경험해 보았다면 환경 변수 (Environment Variable)와 콘솔 (Console) 연결에 대한 감각은 그대로 활용할 수 있으며, 다른 점은 그 위에 AI 에이전트 스택 (AI Agent Stack: AgentCore, Gateway, KB, Memory)이 올라가 있다는 것이다. 다음에 응시할 분들은 특히 Knowledge Base와 Cognito M2M 구간에서 시간을 절약하시길 바란다.