Build a multi-agent music production pipeline on Amazon Bedrock AgentCore Runtime Instances

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore Runtime Instances의 GPU·공유 파일시스템·최대 14일 세션을 활용해 작곡·딜리버리·컴플라이언스 에이전트가 실제 음원을 생성하고 처리·검증하는 음악 제작 파이프라인을 구축한다.

📌 핵심 요약

• Amazon Bedrock AgentCore는 서버리스 MicroVM과 AWS 관리형 EC2 기반 Runtime Instances를 제공한다. MicroVM은 최대 8시간 세션과 에이전트 1:1 배치를 지원하며, Runtime Instances는 최대 14일 세션, 여러 에이전트의 공동 배치, 지원 인스턴스 계열의 GPU, Amazon EBS 영구 저장소를 제공한다.
• 서로 다른 에이전트 런타임이 같은 capacity provider에서 동일한 runtimeSessionId로 호출되면 같은 EC2 인스턴스와 공유 볼륨을 사용한다. 세션을 밤사이 중단했다가 다음 호출로 재개할 수 있고, 각 팀은 다른 에이전트를 변경하지 않고 자체 아티팩트를 배포할 수 있다.
• 작곡 에이전트는 Claude Sonnet 4.6으로 음악 브리프를 만들고 인스턴스 GPU에서 ACE-Step으로 음원을 생성한다. 원문은 NVIDIA L4에서 20초 분량의 48 kHz 스테레오를 약 9초에 렌더링한다고 설명하며, 모델과 의존성은 영구 볼륨에 구축해 세션 내 호출에서 재사용한다.
• 딜리버리 에이전트는 공유 파일의 측정값을 Claude Sonnet 4.6에 전달해 EQ·압축·리미팅 처리를 결정하고, 실제 DSP 적용 후 다시 측정한다. 컴플라이언스 에이전트는 결과를 독립적으로 재측정하고 딜리버리 목표 및 스튜디오 자체 백카탈로그와의 화성적 유사성을 검사하며, 유사성이 감지되면 작곡 에이전트에 대체 음원 생성을 요청하고 재검사한다.
• 예제는 Strands Agents 기반 Python 애플리케이션이며, 작곡·딜리버리는 Amazon ECR 컨테이너, 컴플라이언스는 Amazon S3 zip 파일로 배포한다. 준비 조건에는 Claude Sonnet 4.6 모델 접근, Python 3.10+, boto3 ≥ 1.36.0 또는 botocore ≥ 1.43.72 등이 포함되며, 핸들러의 context 매개변수명과 요청별 Agent 생성이 주요 구현 제약이다.

🧩 주요 포인트

1. 최대 14일 세션·Amazon EBS·공유 runtimeSessionId → 여러 날에 걸친 제작 과정에서 에이전트가 같은 파일과 이전 작업 맥락을 이어서 활용할 수 있다.
2. Claude Sonnet 4.6의 처리 계획과 실제 DSP·독립 재측정의 결합 → 생성된 계획의 적합성을 출력 음원의 측정 결과로 확인하는 구조다.
3. Amazon ECR 컨테이너와 Amazon S3 zip의 공존·요청별 Agent 생성 → 팀별 배포 자율성을 확보하면서 공유 Agent의 동시 요청 충돌을 피하는 구현이 필요하다.

🧠 상세 정리

1. 단일 에이전트에서 장기 협업 워크플로로

원문은 단일 목적 에이전트에서 여러 에이전트가 협업하는 시스템으로 발전하면 필요한 인프라도 달라진다는 문제의식에서 출발한다. 고객 문의를 처리하는 하나의 에이전트는 짧은 세션을 사용하는 서버리스 환경에서 실행할 수 있지만, 여러 날 동안 맥락을 공유하고 서로의 결과물을 이어받는 세 에이전트의 창작 작업에는 몇 시간으로 제한된 세션이 충분하지 않다고 설명한다. 이를 보여주는 예제로 한 에이전트가 인스턴스 GPU에서 음악을 생성하고 나머지 두 에이전트가 공유 볼륨의 .wav 파일을 열어 처리하는 음악 제작 파이프라인을 제시한다. 예제의 결과물은 재생 가능한 트랙이며, 학습 범위에는 capacity provider 생성, 서로 다른 아티팩트 유형의 배포, 공유 세션을 통한 에이전트 간 협업, 여러 날에 걸친 워크플로 유지가 포함된다.

2. MicroVM과 Runtime Instances의 차이

Amazon Bedrock AgentCore의 MicroVM과 Runtime Instances는 같은 런타임 API를 사용하고, CrewAI·LangGraph·LlamaIndex·Strands Agents 같은 사용자 선택 프레임워크와 기반 모델, MCP 및 A2A 통합을 지원한다. MicroVM은 빠른 콜드 스타트, 세션 격리, 사용량 기반 과금을 제공하는 서버리스 방식이며, 세션은 최대 8시간이고 하나의 MicroVM 런타임이 하나의 에이전트를 호스팅한다. Runtime Instances는 AWS가 관리하는 EC2 인프라를 사용하며, 최대 14일 세션과 인스턴스당 여러 에이전트 배치, 지원 인스턴스 계열의 GPU 접근, Amazon EBS 기반 영구 저장소를 제공한다. 두 방식 모두 컨테이너 이미지와 Amazon S3 소스 아티팩트를 지원하지만, MicroVM은 요청에 따라 확장되고 Runtime Instances의 확장은 capacity provider가 관리한다. Runtime Instances의 EC2는 사용자 계정에서 실행되므로 AWS Savings Plans와 On-Demand Capacity Reservations를 활용할 수 있다고 설명한다.

3. 공유 세션과 독립 배포가 협업을 연결하는 방식

Runtime Instances에서 에이전트는 세션 안에서 실행되는 워크로드이며, 하나의 세션에 여러 에이전트를 함께 배치할 수 있다. 두 에이전트 런타임이 같은 capacity provider를 사용하고 동일한 runtimeSessionId로 호출되면 AgentCore는 두 에이전트를 같은 EC2 인스턴스에 배치하고 같은 볼륨을 연결한다. 이 공유 파일시스템을 통해 에이전트는 다른 에이전트가 기록한 음원과 결과물을 직접 읽고 동일한 작업을 이어갈 수 있다. 원문은 월요일에 작곡한 뒤 밤사이 세션을 중단하고 화요일에 딜리버리를 재개하는 사례를 들며, 인스턴스가 자동으로 유휴 상태에 들어갔다가 다음 호출에서 재개한다고 설명한다. 각 에이전트는 별도 런타임과 아티팩트를 가지므로 Audio AI 팀이 작곡 이미지를 갱신해도 다른 두 팀의 에이전트는 그대로 실행될 수 있고, ECR 컨테이너와 S3 코드 패키지도 같은 capacity provider에서 공존한다.

4. 세 에이전트의 역할과 결과물

음악 제작 시스템은 Audio AI 팀의 작곡 에이전트, Audio Engineering 팀의 딜리버리 에이전트, Release Engineering 팀의 컴플라이언스 에이전트로 구성된다. 프로듀서가 제작 요청을 보내면 작곡 에이전트가 음악 브리프를 작성하고 GPU에서 실제 음원을 생성하며, 딜리버리 에이전트는 그 파일을 측정한 뒤 측정값에 근거해 처리 체인을 적용하고 결과를 다시 측정한다. 컴플라이언스 에이전트는 완성된 딜리버리 음원을 독립적으로 재측정해 딜리버리 에이전트가 제시한 목표와 대조하고, 스튜디오 자체 백카탈로그와의 화성적 유사성을 검사한다. 유사성 검사에서 일치가 의심되면 작곡 에이전트로 다시 요청을 보내 대체 음원을 생성하고 재검사하는 흐름으로 돌아간다. 원문이 제시하는 최종 결과는 재생 가능한 .wav 파일과 각 에이전트의 판단을 설명하는 세 개의 보고서이며, 작곡·딜리버리는 ECR 컨테이너, 컴플라이언스는 S3 zip 파일로 제공된다.

5. 실습 준비 조건과 안내된 구축 순서

실습에는 인프라를 생성할 수 있는 보안 주체의 자격 증명을 갖춘 AWS 계정과 설치·설정된 AWS CLI, 최소 하나의 서브넷과 보안 그룹을 갖춘 VPC가 필요하다. 예제는 IAM 역할, S3 버킷, ECR 리포지토리, AgentCore capacity provider와 런타임을 생성하므로 해당 인프라 생성 권한이 준비 조건에 포함된다. Amazon Bedrock 콘솔에서 Anthropic Claude Sonnet 4.6 모델 접근을 활성화하고, 로컬에 Finch 또는 다른 OCI 호환 컨테이너 도구와 Python 3.10+도 설치해야 한다. SDK 조건은 boto3 ≥ 1.36.0 또는 botocore ≥ 1.43.72이며, 원문은 이전 버전에 create_capacity_provider가 없어 deploy.py가 실패한다고 명시한다. 안내된 순서는 에이전트 정의, GPU 인스턴스와 영구 볼륨을 마련하는 capacity provider 생성, 개별 런타임 배포, 공유 세션 호출, 다른 팀을 방해하지 않는 개별 에이전트 갱신이며, 전체 코드는 AgentCore samples GitHub repository에 있다고 설명한다.

6. 세션 전달과 요청별 Agent 생성의 구현 제약

예제의 각 에이전트는 Strands Agents로 작성한 Python 애플리케이션이며, 원문은 혼동하기 쉬운 두 가지 구현 오류를 먼저 짚는다. 첫째, @app.entrypoint 핸들러의 두 번째 매개변수 이름은 반드시 context여야 하는데, SDK가 params[1] == "context"를 검사해 해당 이름을 기준으로 디스패치하기 때문이다. 에이전트는 context에서 세션 ID를 읽어 서로의 파일을 찾고 다른 에이전트를 호출하며, 예제는 세션 ID가 없을 때 local-session을 사용한다. 둘째, Agent는 모듈 전역이 아니라 핸들러 안에서 생성해야 하며, 모듈 수준에서 공유하면 동시 요청 시 Strands가 재진입 호출을 거부하고 "Agent is already processing a request" 오류를 낸다. 대화 이력은 세션 ID와 에이전트 이름을 결합한 FileSessionManager를 통해 트랙별 볼륨 경로에 저장되므로, 요청마다 Agent를 생성하면서도 며칠 뒤 재개한 세션에서 이전 결정을 기억할 수 있다.

7. 작곡 에이전트의 브리프 작성과 GPU 렌더링

작곡 에이전트는 프로듀서의 프롬프트를 Claude Sonnet 4.6에 전달해 CompositionBrief 형식의 음악 브리프를 얻은 뒤, 음악 생성용 오픈소스 기반 모델 ACE-Step으로 실제 오디오를 렌더링한다. 제시된 핸들러는 트랙 디렉터리를 준비하고 composition.wav를 생성하며, 브리프와 렌더링 정보를 composition.md로 기록한 뒤 결과와 아티팩트를 반환한다. mode=prepare 호출은 영구 볼륨에 CUDA PyTorch와 ACE-Step을 포함한 가상환경을 구축하고, 실제 렌더링은 해당 볼륨의 Python 인터프리터를 사용하는 서브프로세스로 실행된다. 원문은 NVIDIA L4에서 20초 분량의 48 kHz 스테레오 음원을 약 9초에 생성한다고 설명하지만, 제시된 핸들러에서 duration_s를 생략할 때의 기본값은 30초다. 모델과 의존성은 세션을 위해 한 번 구축한 뒤 이후 호출에서 재사용되며, 밤사이 중단한 뒤 재개하는 경우에도 영구 볼륨을 활용한다.

8. 딜리버리 에이전트의 측정 기반 처리와 검증

딜리버리 에이전트는 공유 파일시스템에서 작곡 음원을 열고 ITU-R BS.1770-4에 따라 측정한 뒤, 오디오 자체가 아니라 측정 결과를 Claude Sonnet 4.6에 전달한다. 모델은 지정된 플랫폼의 딜리버리를 위한 DeliveryPlan을 작성하면서 EQ 대역, 압축기 설정, 그대로 둘 요소를 결정한다. 이후 실제 DSP 코드가 계획에 따라 EQ 필터와 활성화된 압축기를 적용하고, 목표 LUFS로 음량을 정규화한 다음 목표 트루피크 상한에 맞춰 리미팅한다. 처리된 음원은 PCM_24 형식으로 기록되고 다시 측정되므로, 모델이 제안한 계획이 목표를 달성했는지를 결과 파일로 확인하는 구조다. 원문은 처리 계획을 그대로 신뢰하는 대신 적용 이후의 측정으로 확인한다는 원칙을 강조하며, 제시된 발췌에는 특정 플랫폼의 LUFS나 트루피크 목표 수치가 명시되어 있지 않다.

9. 컴플라이언스의 독립 검사와 제공 자료의 범위

컴플라이언스 에이전트는 딜리버리 에이전트의 측정 결과에만 의존하지 않고 완성된 음원을 독립적으로 재측정하며, 딜리버리 에이전트가 주장한 목표를 충족하는지 확인한다. 이어 스튜디오 자체 백카탈로그와의 화성적 유사성을 검사하고, 유사성이 발견되면 플래그를 올린 뒤 작곡 에이전트에 수정을 위한 대체 생성 요청을 보낸다. 앞선 솔루션 설명에는 대체 음원을 다시 검사하는 반복 흐름이 제시되어 있지만, 실제 유사성 판정 기준이나 임계값은 제공된 본문에 나타나지 않는다. 마지막 코드 발췌는 bedrock-agentcore 클라이언트에 읽기 제한 시간 600초와 표준 모드의 max_attempts 3을 설정한 뒤 invoke_agent_runtime을 호출하기 시작하는 부분에서 끊긴다. 따라서 capacity provider 생성, 전체 배포·호출 코드, 개별 에이전트 갱신은 실습의 예정 단계로 소개되지만, 제공된 source_body만으로 그 세부 구현 전체를 확인할 수는 없다.

🧾 핵심 주장 / 시사점

• Runtime Instances의 핵심은 GPU 제공과 함께 장기 세션·공유 파일·영구 이력을 연결한다는 점이며, 생성된 음원을 여러 에이전트가 순차적으로 처리하는 작업에 직접 활용된다.
• 딜리버리 에이전트의 처리 후 측정과 컴플라이언스 에이전트의 독립 재측정은 서로 다른 확인 단계다. 모델의 계획, 실제 DSP 결과, 별도 에이전트의 검사를 연결하는 방식이 파이프라인의 주요 검증 구조다.
• 공유 인스턴스를 사용해도 에이전트별 런타임과 배포 아티팩트는 분리된다. 이에 따라 파일을 통한 협업과 팀별 독립 갱신을 함께 지원하지만, 세션 식별과 요청별 Agent 생성은 정확히 구현해야 한다.

✅ 액션 아이템

• 최대 14일 세션·GPU·Amazon EBS·공유 runtimeSessionId가 필요한 음악 제작 흐름을 기준으로 Runtime Instances의 적용 적합성을 검토한다.
• Claude Sonnet 4.6 모델 접근, Python 3.10+, boto3 ≥ 1.36.0 또는 botocore ≥ 1.43.72와 context 매개변수명·요청별 Agent 생성 조건을 확인한다.
• 딜리버리 에이전트의 DSP 후 재측정과 컴플라이언스 에이전트의 독립 재측정·백카탈로그 유사성 검사를 연결해 결과를 검증한다.

❓ 열린 질문

• 음악 제작 흐름에 필요한 세션 지속 시간과 GPU·공유 파일시스템 요구는 MicroVM의 최대 8시간 세션보다 Runtime Instances의 최대 14일 세션에 더 적합한가?
• 딜리버리 에이전트의 DSP 후 측정과 컴플라이언스 에이전트의 독립 재측정에서 확인할 딜리버리 목표는 무엇인가?
• 스튜디오 자체 백카탈로그와의 화성적 유사성 검사에서 어떤 결과를 작곡 에이전트의 대체 음원 생성과 재검사로 연결할 것인가?