AI 에이전트를 웹 서비스로 공개하려면 브라우저와 에이전트 런타임 사이에 한 계층이 더 필요합니다. 브라우저에는 AWS 자격 증명을 둘 수 없고, 사용자 대화를 런타임 세션과 이어 주며 에이전트의 토큰 스트림을 끊김 없이 전달할 곳도 있어야 합니다. 이 계층을 BFF(Backend for Frontend, 프런트엔드 전용 백엔드)라고 부릅니다.
1부에서는 AWS Lambda Web Functions를 소개했습니다. Web Functions는 표준 HTTP 서버를 그대로 배포하고, 실행 환경 하나가 최대 128개 요청을 동시에 처리하며, CPU는 실제로 연산한 시간만 과금합니다. 1부의 비용 비교에서는 처리 시간이 활성 CPU의 약 5~6배를 넘으면 512 MB Event Functions보다 Web Functions가 저렴해진다는 기준을 얻었습니다.
2부에서는 Web Functions로 BFF를 만들고 Amazon Bedrock AgentCore Runtime V2에 배포한 에이전트를 호출합니다(AgentCore Runtime V2는 2026년 10월 26일 기준 서울 리전 미지원). 에이전트는 Strands Agents와 Claude Agent SDK 두 가지로 만들어 비교합니다. 모든 구성은 아시아 태평양(도쿄) 리전 기준이며 모델은 Claude Sonnet 5.5를 글로벌 교차 리전 추론(Global cross-Region inference)으로 호출합니다.
1. 에이전트 앞단에 BFF가 필요한 이유
AgentCore Runtime의 InvokeAgentRuntime API는 기본적으로 IAM(SigV4) 서명을 요구합니다. 브라우저가 직접 호출하려면 자격 증명과 런타임 ARN을 클라이언트에 두어야 하므로 서비스 내부 구조가 그대로 노출됩니다. 세션 관리도 서버가 맡는 것이 안전합니다. runtimeSessionId는 33자 이상이어야 하고 같은 ID로 들어온 요청은 같은 세션의 마이크로 VM(MicroVM)으로 전달됩니다. 사용자 대화 하나를 세션 하나에 안정적으로 연결하는 일은 BFF의 몫입니다.
입력 검증도 BFF에서 한 번 더 합니다. 에이전트는 요청 본문을 파싱된 JSON으로 받으므로 prompt가 문자열이 아닐 수 있습니다. AgentCore 개발자 가이드는 문자열이 아닌 입력이 프레임워크에 그대로 전달되면 모델과 가드레일을 거치지 않고 도구가 실행될 수 있다고 경고합니다. BFF가 먼저 걸러 내면 잘못된 요청이 런타임 세션을 만들기 전에 차단됩니다.
계층
담당 역할
Amazon
CloudFront
사용자 지정 도메인, TLS 종료, AWS WAF, 정적 자산 캐시, OAC 서명
Web Functions
BFF
사용자 인증 결과 확인, 입력 검증, 대화와 runtimeSessionId 매핑, 런타임 선택, SSE 중계와 하트비트, 완료 이벤트, 재시도(AWS SDK 기본 재시도)
AgentCore
Runtime V2
세션별 마이크로 VM 격리, 에이전트 루프 실행, 모델과 도구 호출, 응답 스트리밍
Amazon
Bedrock
모델 추론(Claude Sonnet 5.5, 글로벌 교차 리전 추론 프로파일)
표 1. 구성 요소별 역할 분담
Web Functions는 이런 BFF에 잘 맞습니다. BFF는 요청 시간 대부분을 에이전트 응답을 기다리며 보냅니다. 도쿄 리전 시험에서 BFF가 요청 하나에 사용한 활성 CPU는 30~51 ms였습니다. 응답이 10초 동안 스트리밍되어도 CPU가 일하는 시간은 그 200분의 1 수준이므로 1부의 손익분기 기준을 크게 넘습니다. 스트림 수십 개가 실행 환경 하나를 함께 사용하고, 기다리는 시간은 CPU 요금에 거의 반영되지 않습니다.
2. 전체 아키텍처
2.1 도쿄 리