AWS, AgentCore Runtime 세션 안의 웹 앱 실시간 미리 보기 소개… 허용 포트와 요청별 인증 필요

Published 2026-10-30 · AI Daily — AI-assisted deep research, methodology & disclosure

AWS는 2026년 10월 30일 Amazon Bedrock AgentCore runtime 세션에서 코딩 에이전트가 웹 앱을 수정하는 동안 변경 내용을 실시간으로 미리 보는 과정을 소개했다. 예제는 Vite 개발 서버와 에이전트를 같은 세션에서 실행하고, 로컬 화면 왼쪽에는 채팅을, 오른쪽에는 실제 사이트를 표시한다. 파일을 저장하면 사이트도 바뀐다. 이는 개발과 검토를 위한 절차이며 세션 URL을 공개 서비스의 운영 호스팅 주소로 쓸 수 있다는 발표가 아니다. 제목의 preview는 미리 보기 동작을 뜻하며 서비스 출시 단계에 대한 선언이 아니다.

Session endpoint는 하나의 runtime 세션에 묶인다. runtime을 만들 때 개발자는 단일 포트 또는 범위로 이루어진 허용 포트 항목을 1~5개 지정한다. 예제에서 8090은 Vite, 8081은 에이전트 상태 경로다. 에이전트 호출 서버는 8080에서 듣지만 이 포트는 Session endpoint 허용 목록에 없다. 프롬프트는 별도의 InvokeAgentRuntime API로 전달된다. 이 API의 응답 헤더에서 Session endpoint URL을 받는다. 외부 클라이언트는 HTTPS 443으로 연결하고 호스트명 접두부로 내부 포트를 선택한다. HTTP/1.1, HTTP/2, SSE, gRPC, WebSocket을 전달할 수 있다.

Session endpoint의 모든 요청에는 인증이 필요하다. IAM 설정에는 SigV4 서명을, 인바운드 JWT 승인자 설정에는 bearer token을 사용한다. 브라우저 페이지는 각 리소스 요청과 WebSocket 핸드셰이크에 자체적으로 이런 자격 정보를 모두 붙일 수 없다. 따라서 예제는 SDK 클라이언트로 localhost:8088에 로컬 전달 지점을 열고 개발자의 인증을 추가해 원격 8090으로 보낸다. 미리 보기 화면 자체는 localhost:8087에서 제공된다. 두 로컬 포트의 역할은 다르며 세션을 인증 없는 공개 사이트로 바꾸지 않는다.

튜토리얼에는 지원되는 AWS 리전의 계정, IAM 역할과 S3 및 runtime을 만들 권한, Python 3.10 이상과 지정된 AgentCore·boto3 버전, Node.js 22 이상, Bedrock의 Claude Haiku 5.5 이용 권한이 필요하다고 쓰였다. 배포 스크립트는 Node 에이전트와 사이트를 zip으로 묶어 S3에 올리고 직접 코드 배포로 runtime을 만든다. Vite는 세션 안에서 0.0.0.0을 수신해 Session endpoint가 접근할 수 있게 한다. Notebook은 InvokeAgentRuntime으로 세션을 시작하고 응답 URL을 읽어 로컬 전달과 미리 보기 화면을 연다.

사용자의 변경 지시는 웹 포트 전달이 아니라 InvokeAgentRuntime을 거친다. 예제의 파일 도구는 읽기와 쓰기를 사이트 폴더 안으로 제한한다. 에이전트가 파일을 저장하면 Vite가 WebSocket으로 변경을 밀어 보내 인증된 Session endpoint와 로컬 전달을 통해 열린 화면을 갱신한다. 허용된 8081 포트로 상태 경로에도 접근할 수 있다. 허용하지 않은 포트는 403, 인증 누락은 403 또는 401, 허용 포트에 실행 중인 서버가 없으면 502, 끝난 세션은 404를 반환한다. 이는 앱 자체 오류와 구분되는 runtime의 응답이다.

Session endpoint와 기존 runtime endpoint도 구분해야 한다. 전자는 허용한 세션 내부 서비스 포트에 접근할 수 있게 하지만, 에이전트에게 작업을 시키는 InvokeAgentRuntime 호출을 대체하지 않는다. 예제에서 외부 접속은 모두 HTTPS 443을 쓰고 호스트명 접두부가 내부 포트를 고른다. 포트가 허용되지 않으면 403, 자격 증명이 없으면 403 또는 401, 허용 포트에 서버가 없으면 502, 끝난 세션이면 404가 나온다. 이런 상태는 웹 앱 자체의 오류와 별개다. 로컬 전달 지점은 브라우저 대신 요청마다 자격 증명을 붙이며 원격 세션의 인증을 없애지 않는다. 웹사이트와 에이전트가 같은 계산 환경을 공유하는 만큼 권한을 최소화하고 편집 내용을 보존하려면 영구 저장소를 검토해야 한다.

AWS는 전달 전에 자체 인증 헤더를 제거하고 CloudTrail 데이터 이벤트로 InvokeAgentRuntimeProxy를 기록할 수 있다고 설명한다. 다만 데이터 이벤트는 기본적으로 기록되지 않고 Event history에도 나타나지 않는다. 기록하려면 trail 또는 event data store를 만들고 AWS::BedrockAgentCore::Runtime에 대한 advanced event selector를 설정해야 한다. 그러나 사이트와 에이전트는 같은 세션을 공유하므로 서로 분리된 권한 영역이 아니다. 실행 역할에는 필요한 최소 권한만 주어야 한다. 세션의 계산 자원이 교체되면 연결이 끊기고 영구 저장소가 없으면 파일 변경도 사라질 수 있다. URL은 해당 세션 동안만 유효하고 매 요청에 인증이 필요하다. 최종 사용자에게 앱을 제공하려면 별도 배포해야 하며, 예제가 만든 runtime·업로드 코드·IAM 역할은 사용 후 지워 지속 과금을 피한다.

Sources

FAQ

예제에서 8080, 8081, 8090과 로컬 8087, 8088은 각각 무슨 역할인가요?

8080은 별도 InvokeAgentRuntime API로 호출하는 에이전트 포트로 Session endpoint 허용 목록에 없다. 세션 안의 8090은 Vite 사이트, 8081은 상태 경로다. 로컬 8088은 SDK의 인증 전달 지점이고 8087은 채팅과 사이트를 보여 주는 미리 보기 화면이다. 외부 Session endpoint 연결에는 여전히 HTTPS 443을 사용한다.

변경 지시와 Vite 핫 업데이트는 각각 어떤 경로로 이동하나요?

사용자의 요청은 InvokeAgentRuntime을 통해 에이전트에 전달되고 에이전트가 사이트 폴더의 파일을 수정한다. Vite는 저장을 감지해 WebSocket 핫 업데이트를 인증된 Session endpoint와 로컬 8088 전달 지점을 거쳐 8087의 미리 보기로 보낸다. 에이전트 호출과 웹 표시의 경로는 서로 다르다.

Session endpoint를 공개 운영 사이트로 바로 쓸 수 있나요? 접근 및 지속성 한계는 무엇인가요?

공개 운영 사이트로 바로 쓸 수 없다. 한 세션 동안만 유효하며 매 요청마다 인증하고 접근 가능한 포트를 제한한다. 허용하지 않은 포트는 403, 수신 프로세스가 없는 허용 포트는 502, 끝난 세션은 404를 돌려준다. 세션 계산 자원이 바뀌면 연결이 끊기고 영구 저장소 없이는 편집이 사라질 수 있어 최종 사용자용 앱은 별도 배포해야 한다.