교차 계정 데이터 접근을 위한 IAM 권한 제약

Amazon Bedrock Knowledge Bases(지식 베이스)를 사용하여 서로 다른 AWS 계정에 위치한 Amazon Redshift Serverless(서버리스 데이터 웨어하우스) 데이터를 조회할 때, RetrieveAndGenerate API는 직접적인 교차 계정 리소스 정책을 지원하지 않는다는 기술적 제약이 존재한다. 이로 인해 에이전트가 별도 계정의 데이터를 호출하여 답변을 생성하려면, IAM(Identity and Access Management) 역할을 위임받아 권한을 확보하는 우회 패턴을 반드시 구현해야 한다. Amazon Bedrock Knowledge Bases는 기본적으로 Retrieve(데이터 검색) 및 GetDocumentContent(문서 내용 가져오기) 작업에 대한 교차 계정 접근은 허용하지만, 검색과 답변 생성을 동시에 수행하는 RetrieveAndGenerate API 호출 시에는 리소스 정책만으로 권한을 승인할 수 없다.

이 문제를 해결하기 위해 에이전트는 지식 베이스가 위치한 대상 계정의 IAM 역할을 AWS STS(Security Token Service, 임시 보안 자격 증명을 생성하는 서비스)를 통해 위임받는 방식을 사용한다. 모델이 제어하는 도구는 해당 IAM 역할을 assumeRole하여 권한을 획득한 뒤, RetrieveAndGenerate API를 호출하고 생성된 답변과 인용 정보를 오케스트레이션 계층으로 반환한다. 이때 데이터 접근 권한은 최소 권한 원칙(Least-privilege)에 따라 해당 IAM 역할에 정의된 범위 내로 엄격히 제한된다. 이러한 구현은 Strands 에이전트(코드 기반 런타임)와 선언형 Harness(관리형 오케스트레이션 모델) 두 가지 방식 모두에서 동일하게 적용되는 데이터 접근 경계이다.

(구현 경로 비교)

이 과정에서 개발자는 에이전트가 지식 베이스 계정의 자원을 안전하게 호출할 수 있도록 AWS STS를 활용한 역할 위임 로직을 구성해야 한다. RetrieveAndGenerate API 호출 시 필요한 자격 증명은 하드코딩하지 않으며, 에이전트가 실행되는 런타임 환경에서 동적으로 위임받은 역할을 사용하여 API를 호출하는 흐름을 따른다. 이는 교차 계정 환경에서도 데이터 보안을 유지하면서 에이전트가 지식 베이스의 정보를 참조하여 답변을 생성할 수 있게 하는 핵심적인 아키텍처 설계다. 각 구현체인 Strands 에이전트와 선언형 Harness는 에이전트 루프의 소유권과 도구 호스팅 방식에서 차이를 보이지만, 교차 계정 데이터 접근을 위한 이 IAM 역할 위임 패턴은 동일한 기술적 기반을 공유한다. 따라서 사용자는 자신의 운영 환경과 제어 필요성에 맞춰 적절한 오케스트레이션 모델을 선택하되, 권한 위임에 필요한 IAM 역할 설정은 공통적으로 준수해야 한다.

Strands 에이전트와 선언형 Harness의 동작 원리

Strands 에이전트는 사용자가 직접 런타임 환경을 제어하고 루프를 관리하는 코드 기반의 구현 경로를 따른다. 이 방식은 에이전트의 실행 제어권이 사용자에게 완전히 귀속되어 있어, 복잡한 비즈니스 로직을 세밀하게 조정해야 하는 환경에 적합하다. 사용자는 에이전트의 동작을 정의하는 코드를 직접 작성하고 배포하며, 이를 통해 실행 과정의 각 단계를 프로그래밍 방식으로 조율한다. 는 이러한 Strands 에이전트의 아키텍처를 보여주며, 코드 수준의 유연한 제어가 어떻게 구성되는지 나타낸다.

(Strands 아키텍처)

선언형 Harness는 관리형 오케스트레이션 루프를 기반으로 하는 구성 중심의 모델이다. 이 모델은 사용자가 직접 루프를 구현하는 대신, 시스템이 제공하는 관리형 환경에 구성을 입력하여 동작을 정의한다. Harness는 운영 편의성을 극대화하며, 표준화된 오케스트레이션 루프를 활용하여 에이전트를 배포한다. 은 선언형 Harness의 아키텍처를 나타내며, 구성 요소들이 어떻게 시스템 내에서 정렬되는지 설명한다.

(Harness 아키텍처)

두 구현 방식은 모두 Amazon Bedrock Knowledge Bases(기업 데이터에 기반한 검색 증강 생성 서비스를 제공하는 관리형 서비스)를 활용할 때 동일한 교차 계정 데이터 접근 경계를 공유한다. 이는 멀티 계정 아키텍처를 운영하는 기업이 에이전트 구현 방식을 선택할 때 반드시 고려해야 할 제약 사항이다. 은 이 두 경로의 차이점을 요약한 비교표이며, 사용자는 자신의 워크로드가 커스텀 제어를 필요로 하는지 혹은 관리형 오케스트레이션을 선호하는지에 따라 적절한 모델을 선택해야 한다.

(구현 경로 비교)

구현 방식을 결정하기 전, 해당 워크로드가 실제로 에이전트를 필요로 하는지 먼저 검토해야 한다. 이는 설계의 복잡도를 요구되는 동작 수준에 비례하도록 유지하기 위함이다. 커스텀 제어가 필요한 경우에는 코드 기반의 Strands 에이전트를 채택하고, 관리형 운영을 선호하는 경우에는 구성 중심의 선언형 Harness를 선택하는 것이 효율적이다. 동일한 질문과 지식 베이스 ID, 모델, 검색 횟수 및 세션 유지 조건을 설정해야만 두 방식 간의 정확한 비교가 가능하다. 이러한 선택은 인프라의 설계 방향과 운영 효율성에 직접적인 영향을 미치며, 각 방식의 동작 원리를 이해하는 것이 성공적인 배포의 핵심이다.

구현 방식 선택을 위한 비교 기준

Amazon Bedrock AgentCore를 활용한 에이전트 구축 시, 개발 팀은 코드 기반의 Strands 에이전트와 구성 중심의 선언형 Harness 모델 중 하나를 선택해야 한다. 두 방식 모두 교차 계정 데이터 접근이라는 동일한 제약 조건을 공유하며, 최소 권한 원칙(Least-privilege)에 따라 데이터 계정 내 IAM 역할을 통해 접근 권한을 관리한다. 기술적 요구사항과 운영 선호도에 따라 적절한 아키텍처를 결정하는 것이 시스템 효율성의 핵심이다. 은 이러한 두 가지 구현 경로의 차이를 보여준다.

단순한 정보 검색이나 답변 생성 작업이 목적이라면 에이전트를 별도로 구성하기보다 네이티브 Retrieve 또는 직접 RetrieveAndGenerate API를 호출하는 방식이 권장된다. 하지만 모델이 제어하는 도구를 사용하거나 복잡한 대화형 오케스트레이션이 필요한 경우에는 Strands 에이전트를 선택해야 한다. Strands는 코드 기반의 런타임을 제공하여 사용자가 직접 루프 제어권을 행사할 수 있게 한다. 반면, 관리형 오케스트레이션 루프를 선호하고 구성 중심의 운영 모델을 지향하는 팀이라면 선언형 Harness를 사용하는 것이 적합하다. 상세한 아키텍처 구조는 와 에서 확인할 수 있다.

구현 방식을 비교 검증할 때는 동일한 질문, 지식 베이스 ID, 모델, 검색 횟수, 그리고 세션 상태를 유지해야 정확한 결과를 얻을 수 있다. 프롬프트 계약(Prompt contract)에 따라 두 에이전트 모두 사용자의 질문을 도구로 정확히 전달하도록 설계되었으나, RetrieveAndGenerate는 기본적으로 생성형 모델의 특성을 유지한다. 특히 행 단위의 데이터를 조회하는 질문을 할 때는 결과 처리 제한을 초과하지 않도록 행 수, 날짜 범위, 정렬 순서를 명확히 지정해야 한다. 정의되지 않은 SQL 쿼리가 생성될 경우 시스템의 처리 한계를 넘어서는 오류가 발생할 수 있기 때문이다.

비즈니스 사실 관계를 검증할 때는 직접적인 도구 응답과 기반이 되는 구조화된 데이터를 대조하는 과정을 거쳐야 한다. 이러한 운영 방식은 와 에서 확인할 수 있는 Streamlit 모드 선택 및 쿼리 결과 분석 과정과 맥을 같이 한다. 두 방식 모두 일반적으로 사용 가능한(Generally available) 경로이며, 팀의 운영 숙련도와 제어 필요 수준에 따라 선택하면 된다. Amazon Bedrock AgentCore에 대한 자세한 정보와 코드 샘플은 다음 공식 문서에서 확인할 수 있다. https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html

실무 환경에서의 배포 및 검증 가이드

Streamlit을 이용한 인터페이스 환경에서는 로컬(Local), 에이전트코어(AgentCore), 그리고 하네스(Harness)라는 세 가지 모드를 선택하여 배포된 에이전트의 동작을 검증할 수 있다. Streamlit은 파이썬(Python) 기반의 데이터 앱 구축용 오픈소스 라이브러리로, 별도의 프론트엔드 개발 없이도 에이전트의 응답을 시각화하고 쿼리 결과를 대조하는 데 활용된다. 와 같이 사이드바에서 모드를 선택하면 각 방식이 사용하는 오케스트레이션 루프의 제어권과 데이터 호출 경로가 즉시 전환되어 실시간으로 결과를 비교할 수 있다. 에이전트코어는 대규모 환경에서 에이전트를 구축하고 최적화하는 플랫폼이며, 하네스는 관리형 오케스트레이션 루프를 통해 에이전트의 동작을 선언적으로 제어하는 방식이다.

하네스 모드를 선택하여 쿼리를 수행할 때는 결과 처리 제한을 초과하지 않도록 구성하는 것이 필수적이다. Amazon Bedrock AgentCore 문서(https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html)에서 권장하는 바와 같이, 대규모 데이터셋을 다룰 때는 쿼리 결과의 행 수, 특정 날짜 범위, 그리고 정렬 순서를 명확히 지정하여 응답의 가독성과 시스템 안정성을 확보해야 한다. 는 하네스 모드를 통해 도출된 쿼리 결과 화면을 나타내며, 개발자는 이 단계에서 비즈니스 팩트와 도구 응답 간의 구조화된 데이터 대조를 수행한다. 특히 교차 계정 환경에서는 데이터 복제 없이 지식 베이스에 접근하므로, IAM(Identity and Access Management, AWS 리소스 접근 권한 제어 서비스) 역할이 최소 권한 원칙에 따라 정확히 설정되었는지 확인하는 과정이 검증의 핵심이다.

검증 과정에서 Strands 에이전트와 하네스 모델 간의 차이를 명확히 인지하는 것이 중요하다. Strands는 코드 기반의 런타임을 제공하여 개발자가 직접 루프 제어권을 행사할 수 있는 반면, 하네스는 관리형 환경에서 정의된 구성을 바탕으로 에이전트의 루프를 자동으로 처리한다. 동일한 질문과 지식 베이스 ID, 모델, 검색 횟수를 설정한 상태에서 두 모드의 응답을 나란히 배치하여 비교하면, 각 방식이 교차 계정 데이터 접근 경계 내에서 어떻게 응답을 생성하는지 파악할 수 있다. 실무자는 이 과정을 통해 에이전트의 응답 정확도를 보장하고, 실제 운영 환경에서의 배포 적합성을 판단하게 된다. 구현 세부 사항은 깃허브(GitHub) 저장소(https://github.com/owner/repo)에 포함된 샘플 코드를 통해 확인할 수 있으며, 로컬 환경에서부터 관리형 에이전트 루프까지 일관된 검증 절차를 거치는 것을 권장한다.

한국 실무 환경을 위한 배포 및 정리 절차

에이전트 배포와 운영을 마친 후 리소스를 정리할 때는 배포의 역순을 따르는 것이 시스템 안정성에 유리하다. 모든 예제는 us-west-2 리전 기준으로 작성되었으며, 로컬 프로필 별칭은 사용자의 환경에 맞춰 수정해야 한다. 코드 기반 런타임과 선언형 Harness(구성 중심의 관리형 오케스트레이션 모델)를 모두 배포한 경우, Harness를 먼저 정리해야 한다. 이 순서를 지켜야 Harness가 공유 지식 베이스 접근 역할에 부여했던 AWS Lambda 실행 역할의 신뢰 권한(Trust Grant)을 안전하게 제거할 수 있다. 이후 코드 기반 런타임과 공유 IAM 리소스를 순차적으로 삭제하는 절차를 밟는다.

정리 과정에서 주의할 점은 제공된 스크립트가 모든 리소스를 일괄 삭제하지 않는다는 사실이다. AgentCore 메모리, 지식 베이스, 그리고 Redshift Serverless(서버리스 데이터 웨어하우스) 리소스는 스크립트의 자동 삭제 범위에 포함되지 않는다. 따라서 해당 리소스들은 프로젝트 종료 시 사용자가 직접 콘솔이나 명령어를 통해 수동으로 삭제해야 한다. 이러한 리소스 관리 방식은 불필요한 비용 발생을 방지하고 계정 내 자원 점유 상태를 명확히 유지하기 위한 필수 단계다. 상세한 정리 명령어와 절차는 다음 저장소에서 확인할 수 있다.

https://github.com/aws-samples/amazon-bedrock-agentcore-cross-account-samples

운영 모델의 선택은 팀의 기술적 요구사항과 관리 편의성에 따라 결정된다. 커스텀 제어가 핵심인 환경에서는 코드 기반의 Strands 에이전트를, 관리형 오케스트레이션의 효율을 우선시한다면 선언형 Harness 모델을 선택하는 것이 적합하다. 두 방식 모두 동일한 교차 계정 데이터 접근 경계를 공유하므로, 배포된 리소스의 생명주기를 관리하는 운영 정책을 사전에 수립하는 것이 시스템 유지보수의 핵심 기준이 된다.