Bedrock Agents란 무엇인가
Amazon Bedrock Agents는 대형 언어 모델(LLM)이 단순히 텍스트를 생성하는 것을 넘어, 외부 시스템을 실제로 호출하고, 여러 단계에 걸쳐 복잡한 목표를 달성하도록 하는 완전 관리형 에이전트 런타임입니다. 일반적인 LLM 추론은 의 단일 패스이지만, Bedrock Agents는 이라는 반복 루프를 실행합니다.
이 에이전트가 실제로 외부 세계와 상호작용하는 방법이 바로 Action Groups와 도구 통합(tool use)입니다. Lambda 함수, OpenAPI 스키마로 정의된 REST API, 또는 Bedrock에 내장된 기본 도구(Code Interpreter, 파일 처리)를 통해 에이전트는 데이터베이스를 조회하고, 예약 시스템을 변경하고, 코드를 실행하고, 외부 서비스에 알림을 보낼 수 있습니다.
AIP-C01 시험에서 Bedrock Agents는 도메인 3(AI Solutions with Foundation Models)에서 중요하게 다뤄집니다. 단순한 기능 목록 암기가 아니라, 어떤 시나리오에서 에이전트가 필요하고 어떻게 아키텍처를 설계하는지를 이해하는 것이 핵심입니다.
Bedrock Agents 아키텍처와 동작 원리
에이전트를 생성할 때 핵심 구성 요소는 세 가지입니다.
첫째, 기반 모델(Foundation Model) 선택입니다. Claude 3.5 Sonnet, Claude 3 Haiku, Amazon Titan, Llama 등 Bedrock에서 제공하는 모델 중 하나를 에이전트의 두뇌로 지정합니다. 복잡한 멀티스텝 추론에는 Claude 3.5 Sonnet, 응답 속도가 중요한 고객 서비스 봇에는 Claude 3 Haiku가 적합합니다.
둘째, 에이전트 지시사항(Instructions)입니다. 에이전트의 역할, 행동 원칙, 금지 사항을 자연어로 정의합니다. "당신은 고객 주문 시스템 에이전트입니다. 재고 조회와 주문 취소를 도와줍니다. 개인정보 관련 질문은 절대 답변하지 마세요."와 같이 구체적으로 작성할수록 신뢰할 수 있는 동작이 보장됩니다.
셋째, Action Groups와 Knowledge Bases 연결입니다. 에이전트가 실제로 호출할 수 있는 도구(Action Groups)와 참조할 수 있는 지식(Knowledge Bases)을 여기서 설정합니다.
에이전트가 사용자 메시지를 받으면 내부적으로 다음 사이클이 실행됩니다. 모델이 목표를 분석하고 어떤 도구를 호출할지 결정합니다. 도구를 호출하고 결과를 관찰합니다. 목표가 달성되지 않았으면 다시 계획을 세워 다음 도구를 호출합니다. 최종 목표가 달성되면 사용자에게 답변을 반환합니다. 이 과정에서 Bedrock은 모든 단계의 추론 로그(trace)를 자동으로 기록합니다.
Action Groups 설계: OpenAPI 스키마와 Lambda 연동
Action Group은 에이전트가 호출할 수 있는 기능 묶음을 정의합니다. 내부적으로는 OpenAPI 스키마로 기능 목록과 파라미터를 명세하고, 실제 실행은 Lambda 함수가 담당합니다.
OpenAPI 스키마 설계 시 중요한 점이 있습니다. 함수명과 description은 모델이 어떤 상황에서 이 도구를 쓸지 결정하는 데 사용됩니다. 이름이 모호하거나 설명이 부실하면 모델이 잘못된 도구를 선택하거나 필요한 도구를 쓰지 않습니다. 파라미터에도 을 반드시 작성하고, required 여부를 명확히 합니다.
예를 들어 주문 조회 기능의 스키마는 다음처럼 작성합니다.
Lambda 함수는 Bedrock Agents로부터 , , , , 가 포함된 이벤트를 받습니다. 함수는 비즈니스 로직을 실행하고 형식으로 응답합니다.
Lambda 함수 설계 시 실무 고려사항은 다음과 같습니다.
타임아웃: Bedrock Agents는 Lambda 응답을 최대 60초 기다립니다. 오래 걸리는 작업은 비동기 패턴을 고려하세요. 권한 분리: Lambda 실행 역할에 필요한 최소 권한만 부여합니다. RDS 접근, DynamoDB 쓰기 등 실제 권한을 신중하게 설계하세요. 입력 검증: 에이전트가 전달하는 파라미터 값을 그대로 신뢰하지 말고 Lambda 내에서 반드시 검증하세요. 오류 처리: Lambda가 예외를 던지면 에이전트는 이를 관찰하고 재시도하거나 사용자에게 실패 메시지를 전달합니다.
도구 사용(Tool Use / Function Calling) 패턴
Bedrock의 와 모두 tool use(function calling)를 지원합니다. 에이전트를 사용하지 않고 직접 모델 API를 호출하더라도 도구 정의를 함께 전달하면 모델이 어떤 도구를 어떤 파라미터로 호출할지 결정하고, 애플리케이션이 직접 도구를 실행하여 결과를 모델에게 다시 전달하는 패턴이 가능합니다.
Converse API에서 tool use의 흐름은 다음과 같습니다.
클라이언트가 에 도구 목록과 스키마를 포함하여 요청 모델이 특정 도구를 호출하기로 결정하면 블록을 포함한 응답 반환 클라이언트가 도구를 실행하고 결과를 블록으로 대화에 추가 모델이 도구 결과를 바탕으로 최종 답변 생성
Bedrock Agents를 사용하면 이 오케스트레이션 루프를 AWS가 대신 처리해 줍니다. 자체 오케스트레이션 루프를 구현하고 싶다면 LangChain, LlamaIndex, 또는 직접 구현한 ReAct 루프와 Converse API를 조합할 수 있습니다.
멀티스텝 오케스트레이션과 ReAct 패턴
Bedrock Agents의 내부 오케스트레이션 전략은 ReAct(Reasoning + Acting) 패턴을 기반으로 합니다. ReAct는 "생각 → 행동 → 관찰"을 반복하는 에이전트 추론 프레임워크입니다. 에이전트 trace를 보면 이 과정이 명확하게 드러납니다.
이처럼 단일 사용자 메시지에 여러 도구 호출이 자동으로 체이닝되는 것이 Bedrock Agents의 핵심 가치입니다. 개발자가 이 오케스트레이션 루프를 직접 코딩할 필요가 없습니다.
멀티스텝 오케스트레이션 설계 시 주의사항이 있습니다. 최대 반복 횟수를 설정하여 무한 루프를 방지합니다. 민감한 작업(주문 취소, 결제 등)은 에이전트가 실행 전 사용자에게 확인을 요청하는 흐름을 설계합니다. 각 Action Group 함수가 멱등성(idempotent)을 유지하도록 설계합니다. 에이전트가 동일한 작업을 두 번 호출하더라도 중복 처리가 발생하지 않아야 합니다.
!Bedrock Agents의 ReAct 추론 루프
에이전트 메모리와 세션 관리
기본적으로 각 에이전트 대화는 세션(session) 단위로 관리됩니다. 동일 를 사용하면 같은 대화 내에서 컨텍스트가 유지됩니다. 사용자가 "아까 말한 그 주문"이라고 하면 에이전트가 세션 내 이전 대화를 참조하여 어떤 주문인지 파악합니다.
Bedrock Agents는 세션 메모리(Session Memory)도 지원합니다. 메모리를 활성화하면 에이전트가 여러 세션에 걸쳐 사용자 선호나 중요 정보를 기억할 수 있습니다. 예를 들어 고객 서비스 에이전트가 이전 대화에서 파악한 사용자의 배송 주소나 선호 결제 방법을 다음 대화에서 활용합니다. 메모리는 S3에 저장되며, 보존 기간과 요약 방식을 설정할 수 있습니다.
세션 관리에서 실무적으로 중요한 점은 를 애플리케이션에서 적절히 관리해야 한다는 것입니다. 같은 사용자의 연속된 메시지에는 동일한 를, 새 대화 시작 시에는 새 를 사용합니다. 세션 타임아웃은 기본 30분이며 설정에서 조정할 수 있습니다.
멀티에이전트 협업 설계
복잡한 비즈니스 프로세스는 단일 에이전트가 모든 것을 처리하는 것보다 여러 전문화된 에이전트가 협업하는 구조가 더 유지보수하기 좋고 신뢰할 수 있습니다. Bedrock Agents는 멀티에이전트 협업(Multi-Agent Collaboration)을 네이티브로 지원합니다.
슈퍼바이저(Supervisor) 에이전트가 상위 목표를 받으면, 필요에 따라 서브에이전트(Sub-agent)를 호출하여 세부 작업을 위임합니다. 슈퍼바이저 에이전트의 Action Group에 다른 에이전트를 호출하는 Lambda를 등록하거나, Bedrock의 네이티브 에이전트 협업 기능을 사용합니다.
예를 들어 여행 예약 시스템을 구축한다면 다음처럼 역할을 분리합니다.
| 에이전트 | 역할 | 연결 시스템 | |---------|------|----------| | 여행 코디네이터 (슈퍼바이저) | 전체 여행 계획 조율 | — | | 항공편 에이전트 | 항공편 검색 및 예약 | 항공사 API | | 호텔 에이전트 | 숙박 검색 및 예약 | 호텔 예약 시스템 | | 렌터카 에이전트 | 차량 임대 처리 | 렌터카 API | | 결제 에이전트 | 결제 처리 및 영수증 발송 | 결제 게이트웨이 |
이 구조에서 사용자는 "서울에서 제주도로 4월 10일~12일 여행을 예약해줘"라는 단일 메시지만 보내면 됩니다. 코디네이터 에이전트가 하위 에이전트들을 병렬 또는 순차로 호출하여 전체 예약을 완료합니다.
멀티에이전트 설계의 트레이드오프도 있습니다. 에이전트 간 통신 비용(지연 시간, API 호출 비용)이 증가합니다. 오류 전파와 롤백 처리가 복잡해집니다. 반면 각 에이전트의 책임 범위가 명확해지고, 독립적으로 테스트하고 개선할 수 있는 장점이 있습니다.
자율적 의사결정과 오류 처리
에이전트가 자율적으로 동작할수록 예기치 않은 상황에 대한 오류 처리가 중요합니다. Bedrock Agents에서 오류 처리를 설계할 때 고려할 패턴들이 있습니다.
Lambda 함수에서 예외가 발생하면 에이전트는 이를 관찰하고 재시도하거나 사용자에게 실패를 알립니다. Lambda 응답에 필드를 포함하여 에이전트에게 오류 원인을 전달하면, 에이전트가 상황에 맞는 대처를 할 수 있습니다. 예를 들어 재고 조회 API가 타임아웃으로 실패했을 때 에이전트가 "잠시 후 다시 확인해 드리겠습니다"라고 응답하도록 유도할 수 있습니다.
인간 개입(Human-in-the-loop) 패턴도 중요합니다. 에이전트가 불확실하거나 위험한 작업을 수행하기 전에 사용자에게 확인을 요청하도록 Instructions에 명시적으로 지시합니다. "100만 원 이상의 환불 처리는 사용자에게 재확인 후 진행하세요"처럼 구체적인 임계값을 포함하면 효과적입니다.
에이전트의 동작을 예측 가능하게 유지하기 위해 Guardrails를 함께 사용하는 것을 권장합니다. Guardrails는 에이전트의 입출력을 검사하여 민감 정보 누출, 욕설, 주제 이탈 등을 자동으로 차단합니다.
에이전트 디버깅과 추적 (Trace 로그)
Bedrock Agents의 가장 강력한 운영 도구 중 하나가 trace 로그입니다. API 호출 시 를 설정하면 에이전트의 추론 단계, 도구 호출 파라미터, 도구 응답, 최종 답변 생성 과정이 모두 trace 이벤트로 반환됩니다.
trace는 다음 유형으로 구성됩니다.
: 에이전트의 추론(Reasoning) 내용, 선택한 Action : 사용자 입력 전처리 결과 (입력 유효성 여부) : 최종 답변 후처리 결과 : 오류 발생 시 원인 정보
프로덕션 환경에서 trace를 CloudWatch Logs로 전달하면 에이전트 동작 이상을 모니터링하고 디버깅할 수 있습니다. CloudWatch Logs Insights로 특정 패턴(예: 도구 호출 실패율, 재시도 횟수)을 쿼리하여 에이전트 품질을 지속적으로 개선하는 파이프라인을 구축할 수 있습니다.
실무 활용 시나리오
Bedrock Agents가 실제로 어떻게 활용되는지 두 가지 시나리오를 살펴봅니다.