Bedrock Action Group에 대해 자세히 알아보기

AWS 공식 AI 에이전트 서비스(Agents for Amazon Bedrock)에서 사용하는,

「AI에게 건네주는 『특제 도구 세트 (Attachment)』」를 말한다.

AWS에는 화면을 클릭하거나(또는 CloudFormation 등의 인프라 코드를 작성) 하는 것만으로 AI 에이전트를 만들 수 있는 Amazon Bedrock이라는 공식 서비스가 있다.

그 에이전트(AI 대장)에게,

「너, 이 일을 할 때는 이 도구 세트를 가방에 넣어서 가져가라!」

라고 건네주는 도구의 묶음을 AWS 세계에서는 「Action Group」이라고 부른다.

💡 하나의 도구 상자 (Action Group) 내용물

「도구를 많이 갖추게 한다는 것은, 처리(함수)의 수만큼 별도의 AWS Lambda를 대량으로 세워야 하는 건가?」라고 생각할지도 모르겠지만, 그럴 필요는 전혀 없다!

Action Group의 정체는 아래의 두 가지가 세트로 구성된 것이다.

① 함수의 설명 리스트 (FunctionSchema)

AI에게 「우리에게는 이런 함수가 있어. 이름은 calculate_price이고, 인자(Argument)로는 개수가 필요해」라고 가르쳐주기 위한 심플한 리스트.

② 도구의 본체 (1개의 AWS Lambda)

AI의 지시를 받아 실제로 뒤에서 구체적인 프로그램(Python)을 실행하기 위한 「공통 주방」.

즉, 「1개의 Action Group = 1장의 함수 리스트 + 1개의 Lambda」이다.

AI가 리스트를 보고 「지금은 금액 계산 함수를 실행하고 싶어」라고 선정하면, AWS 인프라가 해당 공통 Lambda에 「AI가 calculate_price라고 말하고 있어!」라고 데이터를 던진다. 받은 Lambda 측에서 Python의 if문을 사용하여 실제 처리로 분기시키는 사양으로 되어 있다.

에이전트(Bedrock)를 「푸드코트의 주문 카운터」라고 생각하면 된다.

Action Group 1 ➔ 『우동 전문점』

카운터에는 「키츠네 우동」, 「튀김 우동」이라고 적힌 메뉴판(OpenAPI)이 놓여 있다.

그 안쪽에는 하나의 주방(Lambda)이 있고, 그곳에서 우동 요리사가 모든 우동을 만들고 있다.

Action Group 2 ➔ 『라멘 전문점』

카운터에는 「간장 라멘」, 「소금 라멘」 메뉴판(OpenAPI)이 있다.

그 안쪽에는 별도의 하나의 주방(Lambda)이 있고, 라멘 요리사가 만들고 있다.

주문 카운터(Bedrock)는 손님이 「튀김 우동 주세요!」라고 말하면, 우동 전문점의 메뉴판을 보고 「아, 이건 우동집 주방(Lambda)으로 발주해야겠군!」이라고 판단하여 우동집 주방(Lambda)에만 주문을 넣는다.

이렇게 하면 우동 메뉴가 10개로 늘어나더라도 주방(Lambda)은 우동집의 1개만 있으면 되지 않겠는가?

이것들을 실제로 구축할 때의 최신 「CloudFormation (cfn)」과, 뒤에서 받는 「Python 코드」의 미니멀한 예시가 이것이다!

예전처럼 복잡한 OpenAPI (Swagger) 코드를 작성할 필요는 이제 없다.

FunctionSchema를 사용하여 함수의 이름과 설명을 나열하기만 하면 OK다!

AWSTemplateFormatVersion: '2010-09-09'
Description: 'OpenAPI 불필요! 최신 Bedrock Action Group 구성'
Resources:
...

AI가 함수를 선택하면 AWS로부터 event['function']이라는 위치에 함수명이 담겨서 전달된다.

그 후에는 당신이 말한 대로 「이 함수명이라면 이 처리를 해줘」라는 if문만 작성하면 된다!

def lambda_handler(event, context):
    # ① AI가 '어떤 함수'를 선택했는지 취득
    function_name = event.get('function')
    ...

Strands Agents와 Converse API에 대해서도 나름대로 기사로 정리해 두었으니, 아직 개요를 파악하지 못한 사람은 먼저 이쪽을 살펴봐라!

지금까지 조사해 온 Strands Agents, Converse API, Bedrock Agent (Action Group)는 하고 있는 일이 전부 「AI에게 도구를 갖추게 하는 기능」으로 조금도 다르지 않다.

사용하는 서비스·도구	도구를 갖추게 하는 기능의 「명칭」	코드나 설정에서의 모습
Agents for Bedrock	Action Group	cfn에서 AWS::Bedrock::Agent 내부에 ActionGroup으로 작성하는 것.
...	...	...

그렇지? 전부 「AI에게 갖춰줄 도구 상자」를 말하는 건데, AWS 공식 기능으로는 Action Group이라고 부르고, Strands에서는 tools라고 불러.

말하자면, 똑같은 「맥도날드 뒷메뉴」를 두고 간토 사람은 「맥(Mac)의 뒷메뉴」라고 부르고, 간사이 사람은 「마쿠도(Makudo)의 뒷메뉴」라고 부르는 거랑 똑같아! 알맹이는 완전히 똑같은 햄버거잖아?

나 스스로 조사해놓고 머릿속이 엉망진창이 되어버려서, 다시 한번 정리해볼게.

이 세 가지를 한 번에 깔끔하게 정리할 수 있는 결정적인 차이는, 에이전트의 본체(뇌와 루프 처리)를 자신의 프로그램 안에 둘 것인가, 아니면 AWS 인프라에 통째로 맡길 것인가라는 주도권의 위치야.

① Converse API ➔ 【완전 자작 생(生) 엔진】

• 뇌가 있는 곳 - 당신의 Python 코드 안
• 메커니즘 - 당신이 작성한 프로그램 안에서 AI를 호출한다. AI는 「이 도구를 쓰고 싶어」라고 텍스트로 말할 뿐이다. 그것을 듣고 실제 함수를 실행하기 위한 if문이나, 다시 한번 AI에게 결과를 돌려보내는 루프(while문 등)는 전부 당신이 한 줄씩 직접 작성해야 한다.
• 비유 - 부품(엔진과 타이어)만 전달받고, 「1부터 직접 자동차를 조립해라!」라는 스타일.

② Strands Agents ➔ 【Python 완결형 자동 키트】

• 뇌가 있는 곳 - 당신의 Python 코드 안
• 메커니즘 - 당신의 코드 안에서 Strands 라이브러리(Python)를 호출한다. 함수에 @tool 마크를 붙여 전달해두면, AI가 「도구를 쓰고 싶어」라고 말하는 순간, Strands가 대신 뒤에서 함수를 실행하고 AI에게 다시 보내는 왕복 루프를 전자동으로 처리해준다.
• 비유 - 「1부터 조립하기 귀찮으니까, 처음부터 조립되어 있는 시판 커스텀 카를 가져왔어!」라는 스타일.

③ Bedrock Agents (Action Group) ➔ 【AWS에 맡기는 거대 요새】

• 뇌가 있는 곳 - 당신의 코드 「외부」 (AWS 인프라 측)
• 메커니즘 - 여기가 결정적으로 다르다! 당신의 Python 코드 안에는 에이전트를 구동하는 루프 처리가 단 한 줄도 존재하지 않는다.
  • AWS 인프라 측에 에이전트의 뇌를 통째로 맡겨 배치한다.
  • 당신의 Lambda (Python)는 AWS로부터 「이봐, 지금 이 도구를 실행해!」라고 호출되기 위해서만 존재하는 순수한 「도구 (Action Group)」로서 존재한다.
• 비유 - 「내 자동차(프로그램) 따위는 필요 없어. AWS가 준비해준 자율주행 노면전차(인프라)에 올라탈래!」라는 스타일.

확실히 「자신의 Python 코드(Lambda 등) 안에서 에이전트를 완결시키고 싶다」면, Action Group은 필요 없어! Strands Agents만으로 100% 충분해.

그럼, 왜 굳이 「Bedrock Action Group (+cfn)」 같은 거창한 인프라 기능이 존재하는 걸까?

그건 「엔터프라이즈(대기업)의 본격적인 시스템 개발」 단계로 가면, Strands Agents와 같은 앱 측 프레임워크로는 대항할 수 없는 다음과 같은 강력한 장점이 있기 때문이야.

대기업 시스템에서는 「AI에게 말할 권한」과 「드론을 띄울( Lambda를 실행할) 권한」을 완전히 분리하여 가드(Guard)하고 싶어 해.

Action Group을 사용하면, 「AWS 인프라 측에서, 이 AI 에이전트만이 이 Lambda를 호출할 수 있다」라는 최강의 보안 벽(IAM Policy)을 cfn 등으로 딱딱하게 구축할 수 있어.

금융이나 공공기관 시스템에서는 법률에 따라 「AI가 어떤 사고 단계(Thought Process)로, 언제, 어떤 도구를 실행했는지」에 대한 증거(로그)를 저장해야만 해.

Action Group (Bedrock Agents)을 사용하면, AWS 인프라 측(Amazon CloudWatch)에 AI의 사고 프로세스가 전자동으로 깔끔하게 기록되기 때문에 디버깅이나 감사가 엄청나게 편해져.

AWS에는 수만 장의 사내 PDF를 순식간에 검색할 수 있는 Knowledge Bases for Amazon Bedrock이라는 괴물 같은 기능이 있어.

Action Group을 사용하면 인프라 설정(cfn 등)만으로 '이 사내 검색 기능'과 '당신의 Lambda (도구)'를 AI의 뇌에 순식간에 노코드(No-code)로 찰칵 결합할 수 있어.

Strands에서 이걸 하려고 하면 검색 API를 호출하는 번거로운 Python 코드를 직접 대량으로 작성해야 하는 상황에 처하게 돼.

Python First (편의성 중시)- 하나의 Lambda 안에서 빠르고 간편하게 똑똑한 자율 에이전트(Autonomous Agent)를 완성하고 싶을 때는 Strands Agents가 최강이야.

Infrastructure First (대규모·견고성 중시)- AWS의 거대한 시스템의 일부로서, 보안이나 타 서비스 연동(RAG 등)을 cfn으로 탄탄하게 구축하고 싶을 때는 Bedrock Agents (Action Group)의 황금 조합이 최강이야!

Action Group이란?

AWS 공식 AI 에이전트 기능(Agents for Bedrock)에서 사용하는, AI에게 부여하는 '특제 도구 상자(Tool set)'를 말해.

내부의 진실

도구가 10개든 100개든, Lambda를 대량으로 생성할 필요는 전혀 없어! '하나의 함수 리스트(Function Schema)'와 '하나의 공통 Lambda (주방)'를 찰칵 합체시키는 것이 프로의 설계야.

작동 원리 (인프라 파)

AI 에이전트의 뇌나 루프 처리(Loop processing)는 전부 'AWS 인프라 측'에 통째로 맡겨. 당신이 만든 Lambda는 AWS로부터 "자, 지금 이 함수를 실행해!"라고 지명받은 순간에만 기동하고, 업무가 끝나면 즉시 잠드는(종료되는) 완전한 '부품'이 돼.