Agents for Amazon Bedrock 정식 출시 – 간소화된 생성 및 구성 환경 기능 추가

오늘 부터 생성형 AI을 사용하여 여러 시스템과 데이터 소스에서 작업을 실행하는 애플리케이션을 만들 수 있는 Agents for Amazon Bedrock를 정식 출시합니다.

다음과 같은 새로운 기능들을 추가했습니다.

• 에이전트의 빠른 생성 – 이제 에이전트를 빠르게 생성하고 필요할 경우 향후에 지침과 작업 그룹을 추가할 수 있으므로 개발 프로세스에 유연성과 민첩성을 확보할 수 있습니다.
• 에이전트 빌더 – 콘솔의 새 에이전트 빌더 섹션에서 모든 에이전트 구성을 조작할 수 있습니다.
• 간소화된 구성 – 작업 그룹이 API 스키마를 제공하지 않고도 함수와 파라미터만 나열하는 간단한 스키마를 사용할 수 있습니다.
• 제어 권한 반환 – AWS Lambda 함수를 사용하는 과정을 건너뛰고 에이전트를 호출하는 애플리케이션에 제어 권한을 반환할 수 있습니다. 따라서, 필요한 네트워킹 및 보안 구성을 Lambda 함수에 통합할 필요 없이 애플리케이션이 AWS 외부 시스템과 직접 통합하거나 Amazon Virtual Private Cloud(VPC)에 호스팅된 내부 엔드포인트를 직접 호출할 수 있습니다.
• 코드형 인프라 – AWS CloudFormation을 사용하여 간소화된 새로운 구성으로 에이전트를 배포하고 관리할 수 있어서 생성형 AI 애플리케이션을 위한 환경 전반에 걸쳐 일관성과 재현성을 확보할 수 있습니다.

이 같은 개선 사항들이 실제로 어떻게 작동하는지 살펴보겠습니다.

간소화된 새 콘솔을 사용하여 에이전트 만들기
저는 새로운 환경을 테스트하기 위해, 고객 피드백 내용이 포함된 이메일에 답장을 하는 데 도움을 줄 수 있는 에이전트를 만들고 싶습니다. 생성형 AI를 사용해도 되지만 저는 다른 시스템들과 상호 작용을 해야 하기 때문에 파운데이션 모델(FM)을 한 번 간접 호출하는 것으로는 충분하지가 않습니다. 이를 위해, 저는 에이전트를 사용합니다.

Amazon Bedrock 콘솔에서, 탐색 창에서 Agents(에이전트)를 선택한 후 Create Agent(에이전트 생성)을 선택합니다. 에이전트의 이름(customer-feedback)을 입력하고 설명을 입력합니다. 새 인터페이스를 사용하고 있으므로, 이 단계에서는 새 추가 정보를 제공하지 않고 계속해서 에이전트를 생성합니다.

이제 에이전트의 전체적인 구성에 액세스하여 편집을 할 수 있는 공간인 Agent builder(에이전트 빌더)가 표시됩니다. Agent resource role(에이전트 리소스 역할)에서, 에이전트가 맡은 AWS Identity and Access Management(IAM) 역할이 나를 위해 자동으로 생성되도록 기본 설정을 Create and use a new service role(새 서비스 역할 생성 및 사용)으로 남겨둡니다. 모델의 경우, Anthropic과 Claude 3 Sonnet를 선택합니다.

Instructions for the Agent(에이전트를 위한 지침)에서, 에이전트가 수행해야 하는 작업에 대해 명확하고 구체적인 지침을 제시합니다. 여기서, 에이전트가 답장을 할 때 사용할 문체와 어조도 지정할 수 있습니다. 제 사용 사례에서 저는 다음과 같이 입력합니다.

고객 계정 설정에 맞는 솔루션을 통해 고객 피드백 이메일에 회신할 수 있도록 도와줍니다.

에이전트가 응답에 필요한 정보가 충분하지 않을 때 추가 세부 정보를 요청할 수 있도록 Additional settings(추가 설정)에서, User input(사용자 입력)에 Enabled(사용함)을 선택합니다. 그 다음, Save(저장)을 선택하여 에이전트 구성을 업데이트합니다.

이제 Action groups(작업 그룹) 섹션에서 Add(추가)를 선택합니다. 작업 그룹은 에이전트가 추가 정보를 수집하거나 작업을 수행하기 위해 외부 시스템과 상호 작용할 수 있는 방법입니다. 작업 그룹의 이름(retrieve-customer-settings)과 설명을 입력합니다.

고객 ID를 비롯한 고객 설정을 검색합니다.

설명은 선택 사항이지만 설명을 제시하면 이 작업 그룹을 언제 사용해야 할지를 선택하는 데 도움이 되도록 이 설명이 모델로 전달됩니다.

Action group type(작업 그룹 유형)에서, 함수와 그 파라미터만 지정하면 되도록 Define with function details(함수 세부 정보를 사용하여 정의)를 선택합니다. 여기에 있는 또 다른 옵션(Define with API schemas(API 스키마로 정의))은 API 스키마를 사용하여 작업 그룹을 구성하는 과거의 방법에 해당합니다.

작업 그룹 함수는 Lambda 함수 호출과 연결하거나 사용자나 에이전트를 호출하는 애플리케이션에 제어 권한을 반환하여 함수에 대한 응답을 제공할 수 있도록 구성할 수 있습니다. 제어 권한 반환 옵션은 다음과 같은 네 가지 주요 사용 사례의 경우에 유용합니다.

• API에서 요구하는 적절한 인증 및 네트워크 구성으로 새 Lambda 함수를 구축하는 것보다 기존 애플리케이션(예: 에이전트를 호출하는 애플리케이션)에서 API를 호출하는 것이 더 쉬운 경우
• 작업 시간이 Lambda 함수의 최대 제한 시간인 15분을 초과할 때 컨테이너나 가상 서버에서 실행되는 애플리케이션으로 작업을 처리하거나 AWS Step Functions와 같은 워크플로 오케스트레이션을 사용할 수 있는 경우
• 제어 권한을 반환하면 에이전트가 작업이 완료될 때까지 기다리지 않고 다음 단계로 넘어가고 호출 애플리케이션이 에이전트의 오케스트레이션 흐름이 계속되는 동안 백그라운드에서 작업들을 비동기적으로 실행할 수 있기 때문에 작업에 시간이 많이 걸리는 경우
• 에이전트를 개발하고 테스트하는 동안 API와 상호 작용하는 것처럼 모의할 수 있는 빠른 방법이 필요한 경우

Action group invocation(작업 그룹 호출)에서는 오케스트레이션 중에 모델이 이 작업 그룹을 식별할 경우에 간접 호출될 Lambda 함수를 지정할 수 있습니다. 새 Lambda 함수를 신속하게 생성하거나 기존 Lambda 함수를 선택하거나 사용자나 에이전트를 호출하는 애플리케이션이 응답을 생성하는 데 필요한 세부 정보를 요청하도록 제어 권한을 반환할 것을 콘솔에 요청할 수 있습니다. 이것이 콘솔에서 어떻게 작동하는지 보여주기 위해 Return Control(제어 권한 반환)을 선택하겠습니다.

작업 그룹의 첫 번째 함수를 구성합니다. 함수의 이름(retrieve-customer-settings-from-crm)과 아래와 같은 설명을 입력합니다.

고객 이메일의 발신자/보낸 사람 필드에 있는 고객 ID 등 CRM에서 고객 설정 정보를 검색합니다.

Parameters(파라미터)에서, 설명에 Customer email(고객 이메일)이라고 적어서 email(이메일)을 추가합니다. 이것은 String 유형의 파라미터로, 이 함수에 필요합니다. Add(추가)를 선택하여 작업 그룹의 생성을 마칩니다.

저의 사용 사례에서는 많은 고객들이 로그인할 때 문제를 겪을 것으로 예상되기 때문에 다음과 같은 설명과 함께 또 다른 작업 그룹(이름: check-login-status)을 추가합니다.

고객 로그인 상태를 점검합니다.

이번에는 이러한 요청을 코드로 처리할 수 있도록 새 Lambda 함수를 생성하는 옵션을 선택합니다.

이 작업 그룹의 경우, 다음과 같은 설명과 함께 함수(이름: check-customer-login-status-in-login-system)를 구성합니다.

설정 정보에 있는 고객 ID를 사용하여 로그인 시스템 내 고객 로그인 상태를 확인합니다.

Parameters(파라미터)에서, String 유형의 또 다른 필수 파라미터인 customer_id를 추가합니다. 그 다음, Add(추가)를 선택하여 두 번째 작업 그룹의 생성을 완료합니다.

이 작업 그룹의 구성을 열면 내 계정에 생성된 Lambda 함수의 이름이 보입니다. 여기서 View(보기)를 선택하여 콘솔에서 Lambda 함수를 엽니다.

Lambda 콘솔에서, 제공된 시작 코드를 다음과 같이 편집하여 나의 비즈니스 사례를 구현합니다.

import json

def lambda_handler(event, context):
    print(event)
    
    agent = event['agent']
    actionGroup = event['actionGroup']
    function = event['function']
    parameters = event.get('parameters', [])

    # 여기서 귀하의 비즈니스 로직을 실행합니다. 자세한 내용은
    # 참조: https://docs.thinkwithwp.com/bedrock/latest/userguide/agents-lambda.html
    if actionGroup == 'check-login-status' and function == 'check-customer-login-status-in-login-system':
        response = {
            "status": "unknown"
        }
        for p in parameters:
            if p['name'] == 'customer_id' and p['type'] == 'string' and p['value'] == '12345':
                response = {
                    "상태": "확인되지 않음",
                    “이유”: “이메일 주소가 확인되지 않았습니다”,
                    “해결 방법”: “귀하의 이메일 주소를 확인하세요”
                }
    else:
        response = {
            “오류”: “알 수 없는 작업 그룹 {} 또는 함수 {}”.format(actionGroup, function)
        }
    
    responseBody =  {
        "TEXT": {
            "body": json.dumps(response)
        }
    }

    action_response = {
        'actionGroup': actionGroup,
        'function': function,
        'functionResponse': {
            'responseBody': responseBody
        }

    }

    dummy_function_response = {'response': action_response, 'messageVersion': event['messageVersion']}
    print("Response: {}".format(dummy_function_response))

    return dummy_function_response

Lambda 콘솔에서 Deploy(배포)를 선택합니다. 이 함수는 Amazon Bedrock이 이 함수를 간접 호출하도록 허용하는 리소스 기반 정책으로 구성되어 있습니다. 따라서 에이전트가 사용하는 IAM 역할을 업데이트할 필요가 없습니다.

이제 이 에이전트를 테스트할 준비가 되었습니다. 에이전트를 선택한 상태에서 Amazon Bedrock 콘솔로 돌아가서 Test Agent(에이전트 테스트) 섹션을 찾습니다. 여기서, 에이전트를 준비하고 최신 변경 사항을 적용하여 테스트하기 위해 Prepare(준비)를 선택합니다.

에이전트에 대한 입력으로, 다음 샘플 이메일을 제공합니다.

보낸 사람: danilop@example.com

제목: 로그인 문제

안녕하세요, 제 계정에 로그인하려고 하는데 오류가 발생해서 더 이상 진행할 수가 없습니다. 확인해 주실 수 있나요? 고마워요, Danilo 드림.

첫 번째 단계로, 에이전트 오케스트레이션은 첫 번째 작업 그룹(retrieve-customer-settings)과 함수(retrieve-customer-settings-from-crm)를 사용하기로 결정합니다. 이 함수는 제어 권한을 반환하도록 구성되어 있으며, 작업 그룹 함수의 출력을 제공하라는 메시지가 콘솔에 표시됩니다. 입력 파라미터로 고객 이메일 주소가 제공됩니다.

애플리케이션과의 상호 작용을 시뮬레이션하기 위해 저는 JSON 구문으로 응답한 후 Submit(제출)을 선택합니다.

{ "customer id": 12345 }

다음 단계로, 에이전트는 두 번째 작업 그룹(check-login-status)과 함수(check-customer-login-status-in-login-system)를 사용하는 데 필요한 정보로 Lambda 함수를 직접 호출합니다. 그 결과, Lambda 함수는 다음과 같은 JSON 페이로드를 제공합니다.

{
  "상태": "확인되지 않음",
  “이유”: “이메일 주소가 확인되지 않았습니다”,
  “해결 방법”: “귀하의 이메일 주소를 확인하세요”
}

에이전트는 이 내용을 사용하여 작업을 완료하고 이 고객에게 적합한 솔루션을 제안할 수 있습니다.

저는 이 결과에 만족하지만 내부적으로 어떤 일이 있었는지 더 자세히 알고 싶습니다. 에이전트 오케스트레이션의 각 단계에 대한 세부 정보를 볼 수 있는 Show trace(추적 보기)를 선택합니다. 이렇게 하면 에이전트가 결정한 내용을 이해하고 에이전트 그룹이 내가 예상한 대로 사용되지 않을 경우 그 구성을 수정하는 데 도움이 됩니다.

알아야 할 사항
미국 동부(버지니아 북부)와 미국 서부(오레곤) AWS 리전에서 간소화된 새로운 환경을 사용하여 Agents for Amazon Bedrock을 생성하고 관리할 수 있습니다.

이제 API 스키마를 지정하거나 작업 그룹에 Lambda 함수를 제공하지 않고도 에이전트를 생성할 수 있습니다. 작업 그룹에 필요한 파라미터를 나열하기만 하면 됩니다. 에이전트를 호출할 때 기존 애플리케이션에서 작업을 처리할 수 있도록, 또는 작업 시간이 Lambda 함수의 최대 제한 시간보다 긴 경우, 수행할 작업의 세부 정보와 함께 제어 권한을 반환하기로 선택할 수 있습니다.

Agents for Amazon Bedrock을 위한 CloudFormation 지원이 최근에 출시되었는데, 이제는 이것이 단순화된 새 구문을 지원하도록 업데이트될 것입니다.

자세히 알아보기

• 사용 설명서의 Agents for Amazon Bedrock 섹션을 참조하세요.
• community.aws 사이트를 방문하여 심층적인 기술 콘텐츠를 찾아보고 다른 사람들이 각자의 솔루션에서 Amazon Bedrock을 어떻게 사용하고 있는지 알아보세요.

– Danilo