06참가자 AWS 배포/예상 약 35분, 별도 일정

AgentCore 작업 플래너 배포

모델 계획 API를 독립된 Runtime에 배포하고 권한·응답 형식을 검증합니다.

참가자 AWS 배포 · 별도 트랙아직 읽지 않음

참가자 AWS 배포 트랙, 예상 약 35분입니다. 05장의 Foundation과 검사된 이미지 manifest가 필요합니다.

이 프로젝트에서 AgentCore는 한국어 명령을 제한된 작업 계획으로 바꾸는 Python 플래너의 실행 환경입니다. 실제 집기·놓기 계산은 Fargate의 MuJoCo가 담당합니다. 이 장에서는 Runtime 하나와 전용 실행 역할을 배포합니다.

1. 직접 호출과 Runtime 경로 구분

설정 호출 경로 확인할 provider
Runtime ARN 없음, MODEL_ID 있음 Node API → Bedrock Converse bedrock
AGENTCORE_RUNTIME_ARN 있음 Node API → AgentCore Runtime → Bedrock Converse agentcore
둘 다 없음 명시적으로 표시한 규칙 기반 계획 rules

이 심화 배포는 global.openai.gpt-5.6-sol과 agentcore 모드를 사용합니다. 모델 ID는 배포된 플래너가 쓰는 Bedrock 설정이며 AI 코딩 CLI의 모델 설정과 별개입니다. 실제 접근 가능 여부는 본인 계정의 호출로 확인합니다.

Runtime을 분리하면 플래너 코드·의존성·권한·로그를 웹/물리 엔진과 독립적으로 관리할 수 있습니다. 이 구현에는 AgentCore Gateway나 Memory가 없습니다. Runtime 세션 재사용을 장기 메모리로 설명하지 않습니다. 오류가 나면 API가 오류를 반환하며 직접 Bedrock이나 규칙 모드로 자동 전환하지 않습니다.

2. 배포할 계약 확인

터미널bash
VSCode Server 터미널에서 실행
set -euo pipefail
cd "$ROBOT_LAB"
test -f infra/workshop-binding.json
export ROBOT_RELEASE="$(cat .local/evidence/release.txt)"
export ROBOT_ARTIFACTS="$ROBOT_LAB/infra/.state/releases/$ROBOT_RELEASE.json"
uv pip install --python .venv/bin/python -r agent/requirements.txt
.venv/bin/python -m unittest discover -s agent/tests -v
python3 -B scripts/deploy.py scan --artifacts "$ROBOT_ARTIFACTS"

agent/main.py의 /invocations 입력은 prompt, scenario입니다. agent/planner.py는 다음 형태를 검증합니다.

파일 내용json
{
  "scenario": "transfer",
  "summary": "빨간 상자를 트레이로 옮깁니다.",
  "actions": [{"objectId": "red", "target": "tray"}]
}

객체는 red·blue·orange, 작업은 transfer·stack·sort입니다. 중복 객체, 잘못된 목적지, 좌표·토크·코드·URL 같은 추가 필드는 허용하지 않습니다. Node API도 응답을 다시 검증하고 본인 세션에 묶인 plan ID를 발급합니다.

3. Runtime 변경 세트 검토·적용

터미널bash
VSCode Server 터미널에서 실행
python3 -B scripts/deploy.py plan agentcore --artifacts "$ROBOT_ARTIFACTS"

infra/.state/plans/agentcore.json에서 본인 Runtime 하나와 IAM 역할을 확인합니다. 역할은 선택한 모델/추론 프로파일, 본인 ECR 이미지 읽기와 Runtime 로그에 필요한 권한을 가집니다. S3 실행 기록이나 MuJoCo를 조작하는 역할이 아닙니다.

Runtime은 이 템플릿에서 IAM 인증을 사용하는 관리형 PUBLIC 네트워크입니다. 다음 장의 Private Fargate 배치와 구분합니다. PUBLIC을 익명 호출 허용으로 해석하지 않습니다.

터미널bash
VSCode Server 터미널에서 실행
python3 -B scripts/deploy.py apply agentcore
python3 -B scripts/deploy.py status --stack agentcore \
  > .local/evidence/agentcore-status.json
python3 -m json.tool .local/evidence/agentcore-status.json

스택 완료와 AgentRuntimeArn, AgentRuntimeId, PlannerRoleArn을 확인합니다. 이어서 관리 API로 Runtime의 READY를 확인합니다.

터미널bash
VSCode Server 터미널에서 실행
python3 - <<'PY'
import json, sys
from pathlib import Path
sys.path.insert(0, "infra")
from deployment import Cloud, read_config
cloud = Cloud(read_config(Path("infra/config.json")))
outputs = cloud.outputs("agentcore")
runtime = cloud.client("bedrock-agentcore-control").get_agent_runtime(
    agentRuntimeId=outputs["AgentRuntimeId"])
print(json.dumps({"runtimeId": outputs["AgentRuntimeId"], "status": runtime["status"]}))
assert runtime["status"] == "READY"
PY

READY는 실제 모델 계획 성공과 다른 근거입니다.

4. 실제 모델 호출 한 건 확인

다음 명령은 본인 Runtime과 Bedrock을 실제 호출하며 이용량이 발생합니다. 호출자는 그 Runtime의 InvokeAgentRuntime 권한이 필요합니다. Runtime의 모델 호출 권한과 호출자의 Runtime 접근 권한을 구별합니다.

터미널bash
VSCode Server 터미널에서 실행
cd "$ROBOT_LAB"
.venv/bin/python - <<'PY'
import json, sys, time, uuid
from pathlib import Path
sys.path.insert(0, "infra")
from deployment import Cloud, read_config
from agent.planner import validate_candidate

cloud = Cloud(read_config(Path("infra/config.json")))
arn = cloud.outputs("agentcore")["AgentRuntimeArn"]
started = time.perf_counter()
response = cloud.client("bedrock-agentcore").invoke_agent_runtime(
    agentRuntimeArn=arn, qualifier="DEFAULT", runtimeSessionId=str(uuid.uuid4()),
    contentType="application/json", accept="application/json",
    payload=json.dumps({
        "prompt": "파란 상자, 빨간 상자, 주황 상자 순서로 쌓아줘",
        "scenario": "stack",
    }, ensure_ascii=False).encode())
assert response.get("statusCode", 200) == 200
assert response["contentType"].lower().startswith("application/json")
raw = response["response"].read(16385)
assert len(raw) <= 16384, "Runtime response exceeded the contract"
candidate = validate_candidate(json.loads(raw))
assert candidate["scenario"] == "stack"
assert [a["objectId"] for a in candidate["actions"]] == ["blue", "red", "orange"]
assert all(a["target"] == "tower" for a in candidate["actions"])
evidence = {
    "runtimeArn": arn, "model": cloud.config["modelId"],
    "actions": candidate["actions"], "passed": True,
    "seconds": round(time.perf_counter() - started, 3),
    "scope": "Runtime + Bedrock + network; no physical run",
}
Path(".local/evidence/runtime-invocation.json").write_text(
    json.dumps(evidence, ensure_ascii=False, indent=2) + "\n")
print(json.dumps(evidence, ensure_ascii=False, indent=2))
PY

python3 -B scripts/deploy.py configure-logs

HTTP 200이어도 JSON이 error이거나 계획 계약을 어기면 실패입니다. 위 검사는 응답을 독립적으로 검증하며 원문 프롬프트·세션 ID·비밀키를 기록하지 않습니다.

configure-logs는 본인 Runtime ID 아래의 로그 보존 기간을 적용합니다. 첫 호출 전에는 로그 그룹이 없을 수 있으므로 실제 호출 후 실행합니다.

응답 지연을 해석하는 방법

Runtime을 추가하면 네트워크 이동과 실행 환경 준비가 더해질 수 있습니다. 반대로 이미 준비된 세션에서는 준비 비용이 달라질 수 있습니다. 이 장의 한 번 측정으로 더 빠르거나 느리다고 일반화하지 않습니다.

비교 실험은 같은 모델·프롬프트·출력 제한을 사용하고, 직접 Bedrock과 AgentCore 각각의 첫 요청·반복 요청을 여러 번 측정합니다. 모델 추론과 네트워크를 포함한 전체 시간, 성공/실패 수, 중앙값·p95를 함께 기록합니다. Runtime의 추가 지연만 분리한 측정이라고 부르지 않습니다. 반복 요청은 모델 비용과 할당량을 사용하므로 횟수를 먼저 정합니다.

실패 시 재개

증상 먼저 확인할 경계
Runtime 생성 실패 ARM64 digest, 이미지 읽기 권한, 역할 신뢰 정책, 스택 이벤트
호출자 AccessDenied 선택한 AWS 프로파일과 본인 Runtime의 호출 권한
bedrock_unavailable Runtime의 모델 ID, IAM·SCP, 추론 프로파일의 대상 리전 접근
invalid_output 모델의 구조화 출력 지원과 Python/Node 계약
시간 초과 호출자 제한, Runtime/모델 상태, 첫 요청과 반복 요청의 차이
로그 보존 검사 실패 실제 호출 후 configure-logs 재실행

완료 체크리스트

  • Runtime 하나와 전용 역할의 소유 스택을 확인했습니다.
  • READY 상태와 실제 모델 호출 성공을 각각 확인했습니다.
  • 파랑→빨강→주황, tower 목적지의 계획을 검증했습니다.
  • Runtime 호출이 물리 실행을 하지 않았음을 구분했습니다.
  • 측정 범위와 로그 보존 설정을 기록했습니다.

AI CLI 카드: 06. AgentCore · 다음: 07. Fargate

AI CLI 프롬프트 카드

아래 프롬프트를 복사해 실습 EC2에서 선택한 Codex, Kiro CLI, Claude Code의 대화 입력창에 붙여넣습니다. Markdown 카드 다운로드

Codex프롬프트 입력

선택한 AI CLI의 대화 입력창에 붙여넣으세요. 세 도구가 같은 프롬프트를 사용합니다.

Robot Atlas 워크숍 06장을 진행하세요.
ROBOT_LAB의 참가자 바인딩과 05장에서 검사한 release manifest를 먼저 확인하세요.
교재는 ROBOT_REPO/workshop/chapters/06-agentcore.md입니다.

목표:
- agent/main.py, planner.py, toolkit.json과 Node 계획 검증을 읽습니다.
- AgentCore Runtime 하나와 전용 IAM 역할의 변경 세트를 검토하고 요청된 배포를 진행합니다.
- global.openai.gpt-5.6-sol 설정, ARM64 ECR digest, Runtime READY를 확인합니다.
- 교재의 실제 호출로 파랑→빨강→주황 tower 계획을 검증합니다.
- 호출 결과의 HTTP 상태뿐 아니라 error payload·추가 필드·중복 객체·목적지도 확인합니다.
- 본인 Runtime 로그 보존 기간과 메타데이터만 기록합니다.

구분할 것:
- AgentCore Runtime은 플래너 실행 환경입니다. Gateway와 Memory는 이 프로젝트에 없습니다.
- Runtime의 관리형 PUBLIC/IAM 구성과 Private Fargate 배치는 다른 설정입니다.
- Node→Bedrock 직접 경로의 provider는 bedrock, Runtime 경로는 agentcore입니다.
- Runtime READY, 실제 모델 호출 성공, 실제 물리 실행 성공은 별도 근거입니다.
- 측정 시간에는 모델 추론과 네트워크가 포함됩니다. Runtime만의 추가 지연으로 부르지 마세요.

경계:
모든 실제 배포는 ROBOT_LAB/scripts/deploy.py를 사용하세요.
계정·소유 태그·바인딩 가드를 유지하고, 공유 자원이나 루트 운영 배포를 변경하지 마세요.
오류를 숨기기 위해 규칙 모드나 직접 Bedrock으로 자동 전환하지 마세요.
자격 증명, 쿠키, CSRF, Secret 값, 원문 모델 대화를 로그·보고서에 넣지 마세요.
승인된 모델 호출 횟수와 참가자 배포 범위 안에서 진행하세요.

변경 파일·명령·종료 상태·Runtime/계획 검증 근거·호출 시간 범위·남은 항목을 보고하세요.

읽기 기록

읽음 표시는 이 브라우저에만 저장됩니다.
실제 실습 결과는 터미널에서 확인하세요.