Bedrock Agents 완벽 입문 가이드

AWS Bedrock Agents의 기본 개념부터 실전 활용까지 초급 개발자를 위한 완벽 가이드입니다. AI 에이전트의 아키텍처와 구성 요소를 쉬운 비유로 이해하고, 실무에서 바로 활용할 수 있는 방법을 배웁니다.

1. AI 에이전트란 무엇인가

스타트업에서 일하는 김개발 씨는 CEO로부터 흥미로운 프로젝트를 맡았습니다. "고객 문의를 자동으로 처리하는 AI 시스템을 만들어주세요." 단순히 질문에 답하는 챗봇이 아니라, 데이터베이스를 조회하고 주문도 처리할 수 있는 똑똑한 시스템이 필요했습니다.

AI 에이전트는 단순히 질문에 답하는 것을 넘어서 실제 작업을 수행하는 지능형 시스템입니다. 마치 비서가 상사의 지시를 듣고 여러 부서에 연락해서 일을 처리하는 것처럼, AI 에이전트도 사용자의 요청을 이해하고 필요한 도구를 사용해 목표를 달성합니다.

AWS Bedrock Agents는 이런 에이전트를 쉽게 만들 수 있게 해주는 관리형 서비스입니다.

다음 코드를 살펴봅시다.

import boto3

# Bedrock Agent 클라이언트 생성
bedrock_agent = boto3.client('bedrock-agent-runtime')

# 에이전트에게 작업 요청
response = bedrock_agent.invoke_agent(
    agentId='ABCD1234',
    agentAliasId='PROD',
    sessionId='session-123',
    # 사용자의 자연어 요청
    inputText='지난달 매출 데이터를 조회하고 보고서를 작성해줘'
)

# 응답 스트림 처리
for event in response['completion']:
    print(event['chunk']['bytes'].decode())

김개발 씨는 지금까지 챗봇을 만들어본 경험이 있습니다. 하지만 그 챗봇은 정해진 시나리오대로만 대답할 수 있었습니다.

"주문 조회는 1번, 환불은 2번을 누르세요" 같은 식이었죠. 하지만 CEO가 원하는 것은 달랐습니다.

"오늘 배송 예정인 주문 중에 강남구로 가는 건 몇 개야?"라는 복잡한 질문에도 대답할 수 있어야 했습니다. 단순한 챗봇으로는 불가능한 일이었습니다.

AI 에이전트란 무엇일까요? 쉽게 비유하자면, AI 에이전트는 마치 유능한 비서와 같습니다. 상사가 "이번 분기 실적을 정리해서 보고서 만들어줘"라고 말하면, 비서는 이렇게 일합니다.

먼저 회계팀에 가서 매출 데이터를 받아옵니다. 그다음 영업팀에서 고객 정보를 확인합니다.

마지막으로 파워포인트를 열어서 보고서를 작성합니다. AI 에이전트도 정확히 이렇게 작동합니다.

사용자의 요청을 듣고, 어떤 도구를 사용해야 할지 판단하고, 필요한 작업을 순서대로 실행합니다. 전통적인 챗봇과의 차이점 예전 방식의 챗봇은 미리 정해진 규칙대로만 움직였습니다.

"A라는 질문이 들어오면 B라고 대답한다"는 식으로 모든 경우의 수를 프로그래머가 직접 작성해야 했습니다. 고객이 조금만 다르게 질문해도 제대로 응답하지 못했습니다.

더 큰 문제는 실제 작업을 수행할 수 없다는 점이었습니다. 데이터베이스를 조회하거나 API를 호출하는 것은 별도의 복잡한 코드가 필요했습니다.

챗봇과 업무 시스템을 연결하는 것이 매우 어려웠습니다. AI 에이전트의 등장 바로 이런 문제를 해결하기 위해 AI 에이전트가 등장했습니다.

AI 에이전트는 대규모 언어 모델(LLM)의 추론 능력을 활용합니다. 사용자의 자연어 요청을 이해하고, 스스로 계획을 세우고, 필요한 도구를 선택해서 사용합니다.

마치 사람처럼 생각하면서 일을 처리하는 것입니다. AWS Bedrock Agents란? AWS에서 제공하는 Bedrock Agents는 이런 AI 에이전트를 쉽게 만들 수 있게 해주는 관리형 서비스입니다.

직접 LLM을 호출하고, 프롬프트를 관리하고, 도구 실행 로직을 구현할 필요가 없습니다. Bedrock Agents가 이 모든 복잡한 과정을 자동으로 처리해줍니다.

개발자는 비즈니스 로직에만 집중할 수 있습니다. 코드 분석 위의 코드를 살펴보겠습니다.

먼저 boto3를 사용해서 Bedrock Agent Runtime 클라이언트를 생성합니다. 이것은 에이전트와 통신하기 위한 창구입니다.

invoke_agent 함수를 호출할 때 agentId와 agentAliasId를 지정합니다. 이것은 어떤 에이전트를 사용할지 알려주는 식별자입니다.

가장 중요한 부분은 inputText입니다. 여기에 자연어로 된 사용자 요청을 그대로 전달합니다.

"지난달 매출 데이터를 조회하고 보고서를 작성해줘"라는 복잡한 요청을 그대로 넣으면, 에이전트가 알아서 처리합니다. 응답은 스트리밍 방식으로 돌아옵니다.

에이전트가 작업을 수행하면서 중간 결과를 실시간으로 받아볼 수 있습니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

예를 들어 전자상거래 회사를 운영한다고 가정해봅시다. 고객 센터에 하루에 수백 건의 문의가 들어옵니다.

"내 주문 어디까지 왔어?", "반품하고 싶은데 어떻게 해?", "이 제품 재입고 언제 돼?" 같은 질문들입니다. Bedrock Agent를 활용하면 이런 문의를 자동으로 처리할 수 있습니다.

에이전트가 주문 데이터베이스를 조회하고, 배송 추적 시스템과 연동하고, 재고 관리 시스템을 확인합니다. 사람 상담원은 정말 복잡한 문제에만 집중할 수 있습니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 AI 에이전트를 만능으로 생각하는 것입니다.

에이전트도 결국 LLM을 기반으로 하기 때문에, 학습 데이터에 없는 전문 지식은 알지 못합니다. 또한 복잡한 수학 계산이나 정확한 논리 연산은 여전히 어려울 수 있습니다.

따라서 에이전트에게 적합한 작업과 그렇지 않은 작업을 구분해야 합니다. 자연어 이해가 필요하고, 여러 시스템을 오케스트레이션하는 작업에 강점이 있습니다.

정리 김개발 씨는 이제 AI 에이전트의 개념을 이해했습니다. 단순한 챗봇이 아니라, 실제로 일을 처리할 수 있는 지능형 시스템이라는 것을 알게 되었습니다.

Bedrock Agents를 사용하면 복잡한 인프라 구축 없이도 강력한 AI 에이전트를 만들 수 있습니다. 다음 섹션에서는 Bedrock Agents의 아키텍처를 자세히 살펴보겠습니다.

실전 팁

💡 - AI 에이전트는 자연어 이해와 여러 시스템 연동이 필요한 작업에 적합합니다

Bedrock Agents를 사용하면 복잡한 LLM 오케스트레이션 로직을 직접 구현하지 않아도 됩니다

2. Bedrock Agents 아키텍처

김개발 씨는 이제 Bedrock Agent를 본격적으로 만들기로 했습니다. 하지만 AWS 콘솔을 열어보니 낯선 용어들이 가득했습니다.

"Foundation Model", "Action Group", "Knowledge Base"... 도대체 이것들이 어떻게 연결되는 걸까요?

Bedrock Agents 아키텍처는 크게 세 가지 핵심 요소로 구성됩니다. Foundation Model은 두뇌 역할을 하고, Action Groups는 손발이 되어 실제 작업을 수행하며, Knowledge Base는 기억 저장소 역할을 합니다.

이 세 가지가 유기적으로 연결되어 지능형 에이전트가 작동합니다.

다음 코드를 살펴봅시다.

import boto3

bedrock = boto3.client('bedrock-agent')

# 에이전트 생성 - 아키텍처의 핵심 정의
agent = bedrock.create_agent(
    agentName='customer-service-agent',
    # 두뇌: Foundation Model 선택
    foundationModel='anthropic.claude-3-sonnet-20240229-v1:0',
    instruction='당신은 친절한 고객 센터 상담원입니다.',
    # 세션 타임아웃 설정
    idleSessionTTLInSeconds=600,
    # 에이전트 역할 (AWS IAM)
    agentResourceRoleArn='arn:aws:iam::123456789012:role/BedrockAgentRole'
)

agent_id = agent['agent']['agentId']
print(f"에이전트 생성 완료: {agent_id}")

김개발 씨는 박시니어 개발자에게 물었습니다. "선배님, 이 아키텍처가 너무 복잡해 보이는데 어떻게 이해하면 좋을까요?" 박시니어 씨가 화이트보드를 들고 왔습니다.

"이렇게 생각해보세요. 에이전트를 사람에 비유하면 쉬워요." 사람에 비유한 아키�ecture 사람은 세 가지 능력이 필요합니다.

먼저 두뇌가 있어야 생각할 수 있습니다. 그다음 손발이 있어야 실제 행동을 할 수 있습니다.

마지막으로 기억이 있어야 과거 경험을 활용할 수 있습니다. Bedrock Agent도 정확히 이런 구조입니다.

Foundation Model이 두뇌, Action Groups가 손발, Knowledge Base가 기억에 해당합니다. Foundation Model: 에이전트의 두뇌 Foundation Model은 에이전트의 사고를 담당합니다.

사용자의 요청을 받으면 "이 요청을 어떻게 처리해야 할까?"를 고민합니다. 여러 가지 선택지 중에서 최선의 방법을 선택합니다.

작업 결과를 보고 다음에 무엇을 할지 계획합니다. AWS Bedrock에서는 Claude, Jurassic, Titan 같은 여러 Foundation Model 중에서 선택할 수 있습니다.

각 모델마다 특징이 다릅니다. Claude는 긴 문맥을 잘 이해하고, Titan은 비용 효율적입니다.

Action Groups: 에이전트의 손발 Action Groups는 실제 작업을 수행하는 도구입니다. 예를 들어 "데이터베이스 조회", "이메일 발송", "API 호출" 같은 구체적인 동작들입니다.

에이전트는 상황에 맞게 필요한 Action을 선택해서 실행합니다. 마치 비서에게 "전화기", "팩스기", "컴퓨터" 같은 도구를 제공하는 것과 같습니다.

비서는 상황에 맞게 적절한 도구를 선택해서 사용합니다. Knowledge Base: 에이전트의 기억 Knowledge Base는 에이전트가 참고할 수 있는 지식 저장소입니다.

회사의 매뉴얼, 제품 정보, FAQ 문서 같은 것들을 저장해둡니다. 에이전트는 사용자 질문에 답하기 전에 Knowledge Base를 검색해서 정확한 정보를 찾아냅니다.

이것은 마치 사람이 업무 매뉴얼을 참고하는 것과 같습니다. 모든 것을 외울 수는 없지만, 필요할 때 찾아볼 수 있습니다.

아키텍처의 작동 흐름 전체적인 흐름을 살펴보겠습니다. 사용자가 "이번 달 매출이 얼마야?"라고 물어봅니다.

먼저 Foundation Model이 이 요청을 분석합니다. "매출 데이터를 조회해야겠군." 그다음 적절한 Action Group을 선택합니다.

"데이터베이스 조회 액션을 실행해야지." 만약 추가 정보가 필요하면 Knowledge Base를 검색합니다. "매출 계산 방식은 뭐더라?" 이 모든 과정이 자동으로 연결되어 실행됩니다.

개발자는 각 구성 요소만 정의해주면 됩니다. 코드 분석 위의 코드를 자세히 살펴보겠습니다.

create_agent 함수가 에이전트의 기본 골격을 만듭니다. agentName은 에이전트의 이름입니다.

가장 중요한 것은 foundationModel 파라미터입니다. 여기서 어떤 AI 모델을 두뇌로 사용할지 결정합니다.

instruction은 에이전트의 기본 성격과 역할을 정의합니다. 이것은 시스템 프롬프트로 작동해서 모든 대화에 영향을 줍니다.

agentResourceRoleArn은 에이전트가 AWS 리소스에 접근할 때 사용할 IAM 역할입니다. 생성이 완료되면 agent_id가 반환됩니다.

이 ID로 나중에 Action Groups와 Knowledge Base를 연결할 수 있습니다. 실무 활용 사례 실제 프로젝트에서는 어떻게 설계할까요?

예를 들어 인사 관리 시스템을 만든다고 가정해봅시다. 직원들이 "내 연차 며칠 남았어?", "급여 명세서 보여줘", "회의실 예약하고 싶어" 같은 요청을 합니다.

이럴 때 Foundation Model은 Claude 3 Sonnet을 선택합니다. 복잡한 요청도 잘 이해하기 때문입니다.

Action Groups는 "연차조회", "급여조회", "회의실예약" 같은 기능으로 구성합니다. Knowledge Base에는 인사 규정, 복지 제도 안내서를 넣어둡니다.

주의사항 아키텍처를 설계할 때 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 너무 많은 Action을 한 번에 추가하는 것입니다.

Action이 많아질수록 에이전트가 혼란스러워질 수 있습니다. 처음에는 핵심 기능 3-5개로 시작하고, 점진적으로 확장하는 것이 좋습니다.

또한 Foundation Model 선택도 중요합니다. 복잡한 추론이 필요하면 Claude 3 Opus를, 빠른 응답이 필요하면 Claude 3 Haiku를 선택해야 합니다.

정리 김개발 씨는 이제 아키텍처를 이해했습니다. "아, 결국 사람처럼 두뇌, 손발, 기억을 갖춘 시스템이네요!" Bedrock Agents의 아키텍처는 복잡해 보이지만, 각 구성 요소의 역할을 이해하면 명확합니다.

다음 섹션에서는 각 구성 요소를 더 자세히 살펴보겠습니다.

실전 팁

💡 - Foundation Model 선택은 작업의 복잡도와 응답 속도 요구사항을 고려하세요

Action Groups는 처음에는 적게 시작하고 점진적으로 확장하는 것이 좋습니다

3. 에이전트 구성 요소

김개발 씨는 이제 실제로 에이전트를 구성하기 시작했습니다. 하지만 콘솔에서 설정할 항목들이 너무 많았습니다.

"Instruction", "Session Timeout", "IAM Role"... 각각 무슨 역할을 하는 걸까요?

잘못 설정하면 어떤 문제가 생길까요?

에이전트 구성 요소는 Instruction(행동 지침), Session State(대화 상태 관리), IAM Role(권한 관리), Guardrails(안전장치)로 이루어집니다. Instruction은 에이전트의 성격과 역할을 정의하고, Session State는 대화 맥락을 유지하며, IAM Role은 보안을 담당하고, Guardrails는 부적절한 응답을 방지합니다.

다음 코드를 살펴봅시다.

import boto3

bedrock = boto3.client('bedrock-agent')

# 에이전트 상세 구성
agent = bedrock.create_agent(
    agentName='hr-assistant',
    foundationModel='anthropic.claude-3-sonnet-20240229-v1:0',
    # Instruction: 에이전트의 역할과 행동 지침
    instruction='''당신은 회사 인사팀 도우미입니다.
직원의 연차, 급여, 복지 문의를 도와줍니다.
항상 정중하고 정확하게 답변하세요.
개인정보는 절대 유출하지 마세요.''',
    # 세션 타임아웃 (초)
    idleSessionTTLInSeconds=1800,
    # IAM Role ARN
    agentResourceRoleArn='arn:aws:iam::123456789012:role/HRAgentRole',
    # Guardrails ID (옵션)
    guardrailConfiguration={
        'guardrailIdentifier': 'abc123xyz',
        'guardrailVersion': '1'
    }
)

박시니어 개발자가 김개발 씨의 화면을 보더니 말했습니다. "이 설정들이 다 중요해요.

하나씩 제대로 이해하고 설정해야 합니다." 김개발 씨는 노트북을 꺼내 들었습니다. "하나씩 알려주세요!" Instruction: 에이전트의 정체성 Instruction은 에이전트에게 주는 근본적인 지침서입니다.

마치 신입사원에게 주는 업무 매뉴얼과 같습니다. "당신의 역할은 무엇이고, 어떤 원칙으로 일해야 하는가"를 명확하게 알려줍니다.

이것은 모든 대화에서 기본 전제로 작동합니다. 좋은 Instruction은 구체적이고 명확해야 합니다.

"친절하게 답변하세요"보다는 "항상 존댓말을 사용하고, 이해하기 쉬운 용어로 설명하며, 답변 끝에 추가 질문 여부를 물어보세요"가 훨씬 좋습니다. 반대로 너무 제약이 많으면 에이전트가 경직될 수 있습니다.

"절대 이것은 하지 마세요, 저것도 하지 마세요"라고 하면 오히려 도움이 안 되는 답변만 하게 됩니다. 균형이 중요합니다.

Instruction 작성 팁 실무에서는 이렇게 작성합니다. 첫 번째 문단에서 역할을 명확히 합니다.

"당신은 고객 서비스 담당자입니다." 두 번째 문단에서 주요 업무 범위를 설명합니다. "주문 조회, 반품 처리, 배송 추적을 도와줍니다." 세 번째 문단에서 응대 원칙을 정의합니다.

"항상 정중하고 공감하는 태도를 유지하세요." 마지막으로 금지 사항을 명시합니다. "개인정보를 요구하지 마세요", "의료 조언을 하지 마세요" 같은 것들입니다.

Session State: 대화 맥락 관리 Session State는 대화의 연속성을 유지하는 메커니즘입니다. 사람과 대화할 때를 생각해보세요.

"어제 말한 그 건 어떻게 됐어?"라고 물으면, 상대방은 어제 대화를 기억하고 있어야 답할 수 있습니다. 에이전트도 마찬가지입니다.

Bedrock Agents는 각 사용자별로 Session ID를 부여합니다. 같은 Session ID로 들어오는 요청들은 이전 대화 기록을 공유합니다.

사용자가 "그거 다시 설명해줘"라고 하면, 에이전트는 바로 전 대화를 참고해서 답합니다. Session Timeout 설정 idleSessionTTLInSeconds는 세션이 만료되는 시간입니다.

예를 들어 1800초(30분)로 설정하면, 사용자가 30분 동안 아무 말도 하지 않으면 세션이 종료됩니다. 다음에 다시 대화를 시작하면 새로운 세션이 생성되고, 이전 대화 기록은 참조되지 않습니다.

이 값을 너무 길게 설정하면 메모리 비용이 증가합니다. 너무 짧게 설정하면 사용자 경험이 나빠집니다.

보통 10-30분 사이가 적당합니다. IAM Role: 권한 관리 IAM Role은 에이전트가 AWS 리소스에 접근할 때 사용하는 신분증입니다.

에이전트가 Lambda를 호출하거나, S3에서 파일을 읽거나, DynamoDB를 조회할 때 권한이 필요합니다. 이때 agentResourceRoleArn에 지정된 IAM Role을 사용합니다.

보안을 위해 최소 권한 원칙을 따라야 합니다. 에이전트가 꼭 필요한 리소스에만 접근할 수 있도록 권한을 제한합니다.

예를 들어 읽기만 필요하면 쓰기 권한은 주지 않습니다. IAM Policy 예시 HR 에이전트라면 직원 데이터베이스 조회 권한만 주고, 수정 권한은 주지 않습니다.

Lambda 함수 중에서도 "get-employee-info" 같은 특정 함수만 호출할 수 있게 제한합니다. 이렇게 세밀하게 권한을 관리하면, 만약 에이전트가 예상치 못한 동작을 하더라도 피해를 최소화할 수 있습니다.

Guardrails: 안전장치 Guardrails는 에이전트가 부적절한 응답을 하지 않도록 막는 안전장치입니다. 예를 들어 사용자가 욕설을 하거나, 민감한 주제를 물어보거나, 시스템을 악용하려고 할 때 이것을 감지하고 차단합니다.

또한 에이전트가 개인정보나 기밀정보를 유출하지 않도록 필터링합니다. Bedrock Guardrails를 사용하면 콘텐츠 필터, 민감정보 탐지, 주제 제한 같은 기능을 쉽게 적용할 수 있습니다.

코드 분석 위의 코드를 다시 보겠습니다. instruction 파라미터에 여러 줄의 지침을 작성했습니다.

역할, 업무 범위, 원칙, 금지사항을 모두 포함했습니다. idleSessionTTLInSeconds는 1800초로 설정했습니다.

30분 동안 대화가 없으면 세션이 종료됩니다. agentResourceRoleArn에는 미리 만들어둔 IAM Role의 ARN을 지정했습니다.

guardrailConfiguration에는 Guardrails ID와 버전을 넣었습니다. 실무 활용 사례 실제 서비스에서는 이렇게 구성합니다.

금융 서비스 챗봇을 만든다면 Instruction에 "투자 조언을 하지 마세요", "법률 자문을 하지 마세요" 같은 명확한 금지 사항을 넣습니다. Session Timeout은 보안을 위해 짧게(5-10분) 설정합니다.

IAM Role은 계좌 조회 API만 호출할 수 있게 제한하고, 송금 API는 접근할 수 없게 합니다. Guardrails에는 금융 규제 관련 필터를 적용합니다.

주의사항 구성 요소 설정 시 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 Instruction을 너무 모호하게 작성하는 것입니다.

"잘 대답하세요"보다는 구체적인 행동 지침을 주어야 합니다. 또한 IAM Role에 과도한 권한을 주는 것도 위험합니다.

테스트 환경에서는 느슨하게 설정하더라도, 프로덕션에서는 엄격하게 적용해야 합니다. 정리 김개발 씨는 각 구성 요소의 역할을 정확히 이해했습니다.

"Instruction은 매뉴얼, Session은 기억력, IAM은 출입증, Guardrails는 안전벨트네요!" 에이전트 구성 요소를 제대로 설정하면 안정적이고 안전한 서비스를 만들 수 있습니다. 다음 섹션에서는 Action Groups에 대해 자세히 알아보겠습니다.

실전 팁

💡 - Instruction은 구체적이고 명확하게 작성하되, 너무 제약적이지 않게 균형을 맞추세요

IAM Role은 최소 권한 원칙을 따라 꼭 필요한 권한만 부여하세요
프로덕션 환경에서는 반드시 Guardrails를 적용하세요

4. Action Groups 개념

에이전트의 기본 구조를 만든 김개발 씨는 이제 실제 기능을 추가하려고 합니다. "연차 조회", "급여 확인" 같은 실제 작업을 수행하려면 어떻게 해야 할까요?

박시니어 개발자가 말했습니다. "Action Groups를 만들어야 해요."

Action Groups는 에이전트가 실제로 수행할 수 있는 작업의 묶음입니다. 각 Action은 Lambda 함수나 API로 구현되며, OpenAPI 스키마로 정의됩니다.

에이전트는 사용자 요청을 분석해서 적절한 Action을 선택하고 실행합니다. 마치 도구 상자에서 필요한 도구를 꺼내 쓰는 것과 같습니다.

다음 코드를 살펴봅시다.

import boto3
import json

bedrock = boto3.client('bedrock-agent')

# OpenAPI 스키마 정의
api_schema = {
    "openapi": "3.0.0",
    "info": {"title": "HR API", "version": "1.0.0"},
    "paths": {
        "/getVacationDays": {
            "get": {
                "description": "직원의 남은 연차 일수를 조회합니다",
                "parameters": [{
                    "name": "employeeId",
                    "in": "query",
                    "required": True,
                    "schema": {"type": "string"}
                }],
                "responses": {"200": {"description": "성공"}}
            }
        }
    }
}

# Action Group 생성
action_group = bedrock.create_agent_action_group(
    agentId='ABC123',
    agentVersion='DRAFT',
    actionGroupName='hr-actions',
    actionGroupExecutor={
        'lambda': 'arn:aws:lambda:us-east-1:123456789012:function:hr-handler'
    },
    apiSchema={'payload': json.dumps(api_schema)}
)

김개발 씨가 물었습니다. "선배님, Action Groups가 정확히 뭔가요?

그냥 Lambda 함수 연결하는 거 아닌가요?" 박시니어 개발자가 웃으며 대답했습니다. "비슷하지만 훨씬 더 똑똑해요.

에이전트가 언제 어떤 Action을 써야 할지 스스로 판단하거든요." Action Groups란 무엇인가 Action Groups는 에이전트의 능력을 확장하는 도구 세트입니다. 쉽게 비유하자면, 수리공이 가지고 다니는 공구함과 같습니다.

드라이버, 렌치, 망치 같은 다양한 도구가 들어있습니다. 수리공은 상황을 보고 적절한 도구를 선택해서 사용합니다.

에이전트도 마찬가지입니다. 여러 Action들을 가지고 있다가, 사용자 요청에 맞는 Action을 선택해서 실행합니다.

중요한 것은 개발자가 "이 상황에는 이 함수를 써라"고 직접 지정하지 않는다는 점입니다. 에이전트가 스스로 판단합니다.

왜 Action Groups가 필요한가 전통적인 방식에서는 모든 분기 처리를 개발자가 코딩해야 했습니다. "사용자가 A라고 하면 함수1을 호출하고, B라고 하면 함수2를 호출한다"는 식으로 if-else 문을 잔뜩 작성했습니다.

사용자가 조금만 다르게 표현해도 제대로 작동하지 않았습니다. 더 큰 문제는 새로운 기능을 추가할 때마다 기존 코드를 수정해야 한다는 점이었습니다.

코드가 점점 복잡해지고 유지보수가 어려워졌습니다. Action Groups의 작동 원리 Action Groups를 사용하면 이 문제가 해결됩니다.

개발자는 각 Action의 설명과 파라미터만 정의합니다. 예를 들어 "getVacationDays: 직원의 남은 연차 일수를 조회합니다.

파라미터는 employeeId입니다." 이렇게요. 그러면 에이전트가 사용자 요청을 보고 "아, 연차를 물어보는구나.

getVacationDays를 실행해야겠다"고 스스로 판단합니다. 사용자가 "연차 며칠 남았어?", "휴가 가능한 날짜 알려줘", "올해 쓸 수 있는 휴가는?" 어떻게 표현하든 같은 Action을 실행합니다.

OpenAPI 스키마의 역할 Action Groups는 OpenAPI 스키마로 정의됩니다. OpenAPI는 REST API를 설명하는 표준 형식입니다.

어떤 엔드포인트가 있고, 어떤 파라미터를 받고, 어떤 응답을 돌려주는지 명세합니다. 에이전트는 이 스키마를 읽고 "아, 이 Action은 이런 일을 하는구나.

이런 정보가 필요하구나"를 이해합니다. 그래서 사용자에게 부족한 정보를 물어보거나, 여러 Action을 조합해서 사용할 수도 있습니다.

코드 분석 위의 코드를 자세히 살펴보겠습니다. 먼저 OpenAPI 스키마를 정의합니다.

paths 안에 "/getVacationDays"라는 엔드포인트를 만들었습니다. description에 "직원의 남은 연차 일수를 조회합니다"라고 명확하게 설명했습니다.

이 설명이 매우 중요합니다. 에이전트가 이것을 읽고 언제 이 Action을 써야 할지 판단합니다.

parameters에는 employeeId가 필요하다고 명시했습니다. type은 string입니다.

required는 True로 설정했습니다. create_agent_action_group 함수로 Action Group을 생성합니다.

actionGroupExecutor에 Lambda 함수의 ARN을 지정합니다. 이 Lambda가 실제 작업을 수행합니다.

Lambda 함수 구현 Action Group이 호출하는 Lambda 함수는 이렇게 생겼습니다. 에이전트가 요청을 보내면, Lambda는 event 파라미터로 받습니다.

여기에는 어떤 Action인지, 어떤 파라미터가 전달됐는지 정보가 들어있습니다. Lambda는 비즈니스 로직을 실행하고, 결과를 JSON으로 반환합니다.

중요한 것은 Lambda가 에이전트의 형식에 맞춰 응답해야 한다는 점입니다. 단순히 데이터만 보내는 게 아니라, 에이전트가 이해할 수 있는 구조로 포장해야 합니다.

실무 활용 사례 실제 프로젝트에서는 어떻게 설계할까요? 예를 들어 전자상거래 고객 센터를 만든다면 이런 Action Groups를 구성할 수 있습니다.

"주문조회", "배송추적", "반품신청", "재고확인" 같은 Action들입니다. 각 Action은 백엔드 API나 데이터베이스와 연동됩니다.

에이전트는 고객의 질문을 듣고 적절한 Action을 선택합니다. "내 주문 어디까지 왔어?"라고 하면 "배송추적" Action을 실행합니다.

여러 Action 조합하기 에이전트의 진짜 강점은 여러 Action을 조합할 수 있다는 것입니다. 사용자가 "지난 3개월 동안 산 상품 중에 가장 비싼 거 뭐야?"라고 물어봤다고 가정해봅시다.

이것은 단일 Action으로 처리할 수 없습니다. 에이전트는 이렇게 계획을 세웁니다.

첫째, "주문조회" Action으로 지난 3개월 주문을 가져옵니다. 둘째, "상품상세" Action으로 각 상품의 가격을 확인합니다.

셋째, 가격을 비교해서 가장 비싼 것을 찾습니다. 마지막으로 결과를 사용자에게 알려줍니다.

주의사항 Action Groups를 만들 때 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 Action 설명을 모호하게 쓰는 것입니다.

"데이터를 가져옵니다"보다는 "직원 ID를 받아서 해당 직원의 남은 연차 일수를 조회합니다"처럼 구체적으로 써야 합니다. 또한 한 Action에 너무 많은 기능을 넣지 마세요.

각 Action은 하나의 명확한 목적만 가져야 합니다. 이것이 Single Responsibility Principle입니다.

정리 김개발 씨는 이제 Action Groups의 개념을 완전히 이해했습니다. "에이전트에게 도구를 주는 거네요.

그러면 에이전트가 알아서 골라 쓰는 거고요!" Action Groups를 잘 설계하면 에이전트의 능력을 무한대로 확장할 수 있습니다. 다음 섹션에서는 Knowledge Base 연동에 대해 알아보겠습니다.

실전 팁

💡 - Action 설명은 최대한 구체적으로 작성하세요. 에이전트가 언제 사용해야 할지 명확하게 알 수 있어야 합니다

각 Action은 단일 책임 원칙을 따라 하나의 명확한 기능만 수행해야 합니다
OpenAPI 스키마의 description 필드가 에이전트의 판단에 가장 중요한 역할을 합니다

5. Knowledge Base 연동

김개발 씨의 HR 에이전트는 점점 똑똑해지고 있었습니다. 하지만 문제가 생겼습니다.

직원이 "육아휴직 신청 방법이 뭐예요?"라고 물어보자 에이전트가 제대로 답하지 못했습니다. 회사의 복잡한 규정은 LLM이 학습한 데이터에 없었기 때문입니다.

박시니어 개발자가 조언했습니다. "Knowledge Base를 연동해야 해요."

Knowledge Base는 에이전트가 참고할 수 있는 문서 저장소입니다. 회사 매뉴얼, FAQ, 제품 정보 같은 지식을 저장하면 에이전트가 벡터 검색으로 관련 정보를 찾아 정확하게 답변합니다.

RAG(Retrieval Augmented Generation) 기술을 활용해서 LLM의 한계를 극복할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

bedrock = boto3.client('bedrock-agent')

# Knowledge Base를 에이전트에 연결
kb_association = bedrock.associate_agent_knowledge_base(
    agentId='ABC123',
    agentVersion='DRAFT',
    description='회사 인사 규정 및 복지 제도 안내서',
    knowledgeBaseId='KB456XYZ',
    # Knowledge Base 사용 방법 지정
    knowledgeBaseState='ENABLED'
)

# 에이전트 Instruction 업데이트
bedrock.update_agent(
    agentId='ABC123',
    agentName='hr-assistant',
    instruction='''당신은 회사 인사팀 도우미입니다.
질문에 답변할 때 반드시 Knowledge Base를 먼저 검색하세요.
정확한 규정과 절차를 안내해야 합니다.
Knowledge Base에 없는 정보는 "확인이 필요합니다"라고 답하세요.''',
    foundationModel='anthropic.claude-3-sonnet-20240229-v1:0'
)

print("Knowledge Base 연동 완료")

김개발 씨가 고개를 갸우뚱했습니다. "선배님, Knowledge Base가 뭔가요?

그냥 파일 저장소인가요?" 박시니어 개발자가 화이트보드에 그림을 그리기 시작했습니다. "단순한 저장소가 아니에요.

지능형 검색 시스템이죠." Knowledge Base란 무엇인가 Knowledge Base는 에이전트가 참고할 수 있는 지식 저장소입니다. 쉽게 비유하자면, 회사 도서관과 같습니다.

직원이 궁금한 게 있으면 도서관에 가서 관련 책을 찾아봅니다. 에이전트도 마찬가지입니다.

사용자 질문을 받으면 Knowledge Base를 검색해서 관련 정보를 찾아냅니다. 중요한 것은 단순히 키워드로 찾는 것이 아니라 의미 기반 검색을 한다는 점입니다.

사용자가 "육아휴직"이라고 하면, "출산휴가", "양육 지원" 같은 관련 문서도 함께 찾아줍니다. LLM의 한계와 RAG LLM은 학습 데이터에만 의존합니다.

예를 들어 Claude는 2024년 초까지의 데이터로 학습했습니다. 여러분 회사의 2024년 인사 규정 개정안은 당연히 모릅니다.

또한 학습 데이터에 없는 전문적이고 구체적인 내용은 답할 수 없습니다. 더 큰 문제는 환각(hallucination)입니다.

LLM은 모르는 것도 그럴듯하게 지어내는 경향이 있습니다. 인사 규정을 물어봤는데 잘못된 정보를 알려주면 큰일입니다.

RAG로 이 문제를 해결합니다 RAG(Retrieval Augmented Generation)는 검색과 생성을 결합한 기술입니다. 작동 원리는 간단합니다.

사용자가 질문하면, 먼저 Knowledge Base에서 관련 문서를 검색합니다. 그다음 검색된 문서를 LLM에게 보여주면서 "이 정보를 바탕으로 답변해줘"라고 요청합니다.

이렇게 하면 LLM이 실제 문서에 기반해서 답변하므로 정확성이 크게 향상됩니다. 또한 출처를 명시할 수도 있습니다.

"인사규정 3.2조에 따르면..."처럼요. Knowledge Base의 구조 Bedrock Knowledge Base는 이렇게 구성됩니다.

먼저 문서를 S3 버킷에 업로드합니다. PDF, Word, TXT 같은 다양한 형식을 지원합니다.

그다음 문서를 작은 청크(chunk)로 나눕니다. 한 문단이나 몇 문장씩 쪼개는 것입니다.

각 청크를 임베딩 모델로 벡터화합니다. 문장의 의미를 숫자 배열로 변환하는 것입니다.

이 벡터들을 벡터 데이터베이스에 저장합니다. Bedrock은 OpenSearch Serverless나 Aurora PostgreSQL을 사용합니다.

벡터 검색의 작동 원리 사용자가 질문하면 그 질문도 벡터로 변환됩니다. 그다음 벡터 데이터베이스에서 질문 벡터와 가장 가까운 문서 벡터들을 찾습니다.

이것이 의미상 가장 관련 있는 문서입니다. 수학적으로는 코사인 유사도를 계산합니다.

예를 들어 "육아휴직 기간은?"이라고 물어보면, "육아휴직", "출산휴가", "양육 지원" 관련 청크들이 높은 점수로 검색됩니다. 키워드가 정확히 일치하지 않아도 의미가 비슷하면 찾아냅니다.

코드 분석 위의 코드를 살펴보겠습니다. associate_agent_knowledge_base 함수로 Knowledge Base를 에이전트에 연결합니다.

knowledgeBaseId는 미리 만들어둔 Knowledge Base의 ID입니다. knowledgeBaseState를 ENABLED로 설정하면 에이전트가 이 Knowledge Base를 사용할 수 있습니다.

중요한 부분은 instruction 업데이트입니다. "반드시 Knowledge Base를 먼저 검색하세요"라고 명시했습니다.

이렇게 하면 에이전트가 추측으로 답하지 않고 문서를 참고합니다. "Knowledge Base에 없는 정보는 '확인이 필요합니다'라고 답하세요"도 중요합니다.

모르는 것을 지어내지 않도록 방지합니다. 실무 활용 사례 실제 프로젝트에서는 어떻게 활용할까요?

기술 지원 챗봇을 만든다면 제품 매뉴얼, 문제 해결 가이드, FAQ를 Knowledge Base에 넣습니다. 고객이 "와이파이 설정이 안 돼요"라고 하면, 에이전트가 설정 가이드를 검색해서 단계별로 안내합니다.

법률 상담 에이전트라면 판례, 법령, 계약서 양식을 저장합니다. 사용자가 "근로계약서에 뭐가 들어가야 해?"라고 물으면, 근로기준법을 검색해서 필수 항목을 알려줍니다.

Knowledge Base 최적화 문서를 효과적으로 구성하는 방법이 있습니다. 첫째, 문서를 논리적 단위로 잘 나누어야 합니다.

하나의 긴 문서보다는 주제별로 분리된 여러 문서가 검색에 유리합니다. 둘째, 메타데이터를 활용하세요.

문서에 태그를 달아서 필터링할 수 있습니다. 셋째, 정기적으로 업데이트하세요.

오래된 정보는 삭제하거나 수정해야 합니다. 넷째, 테스트를 자주 하세요.

실제 사용자 질문으로 검색이 잘 되는지 확인해야 합니다. 주의사항 Knowledge Base 사용 시 주의할 점이 있습니다.

초보자들이 자주 하는 실수는 너무 많은 문서를 한꺼번에 넣는 것입니다. 검색 정확도가 떨어질 수 있습니다.

핵심적이고 신뢰할 수 있는 문서만 선별해서 넣으세요. 또한 문서의 품질이 중요합니다.

오타가 많거나 구조가 엉망인 문서는 검색이 잘 안 됩니다. 정제된 문서를 사용하세요.

출처 표시 에이전트가 답변할 때 출처를 명시하도록 설정할 수 있습니다. instruction에 "답변 끝에 참고한 문서명을 알려주세요"라고 추가하면 됩니다.

그러면 "인사규정.pdf 12페이지에 따르면..."처럼 출처를 밝힙니다. 사용자가 신뢰할 수 있고, 나중에 확인도 가능합니다.

정리 김개발 씨는 이제 Knowledge Base의 중요성을 깨달았습니다. "아, LLM은 똑똑하지만 우리 회사 정보는 모르니까, 문서를 검색할 수 있게 해주는 거네요!" Knowledge Base를 잘 구축하면 에이전트의 답변 품질이 비약적으로 향상됩니다.

다음 섹션에서는 실제 활용 시나리오를 살펴보겠습니다.

실전 팁

💡 - Knowledge Base 문서는 주제별로 잘 구조화해서 저장하세요

instruction에 "반드시 Knowledge Base를 먼저 검색하라"고 명시해서 환각을 방지하세요
정기적으로 문서를 업데이트하고 테스트해서 검색 정확도를 유지하세요

6. 에이전트 활용 시나리오

김개발 씨는 이제 Bedrock Agents의 모든 구성 요소를 이해했습니다. 하지만 궁금한 게 생겼습니다.

"이론은 알겠는데, 실제로 어떤 상황에서 사용하면 좋을까요?" 박시니어 개발자가 노트북을 열었습니다. "실제 사례를 보여드릴게요."

Bedrock Agents는 고객 서비스, 내부 업무 자동화, 개인 비서, 데이터 분석 등 다양한 시나리오에 활용됩니다. 자연어로 복잡한 요청을 처리하고, 여러 시스템을 오케스트레이션하며, 사용자에게 자연스러운 대화 경험을 제공합니다.

반복적이고 규칙 기반 작업을 자동화하는 데 특히 효과적입니다.

다음 코드를 살펴봅시다.

import boto3
import json

# 전자상거래 고객 서비스 에이전트 예시
def create_ecommerce_agent():
    bedrock = boto3.client('bedrock-agent')

    # 에이전트 생성
    agent = bedrock.create_agent(
        agentName='ecommerce-customer-service',
        foundationModel='anthropic.claude-3-sonnet-20240229-v1:0',
        instruction='''당신은 온라인 쇼핑몰 고객 센터 상담원입니다.
주문 조회, 배송 추적, 반품 처리, 제품 추천을 도와줍니다.
항상 친절하고 공감하는 태도로 응대하세요.
고객의 문제를 신속하게 해결하는 것이 최우선입니다.''',
        agentResourceRoleArn='arn:aws:iam::123456789012:role/EcommerceAgentRole'
    )

    # Action Groups 추가
    # 1. 주문 관리
    # 2. 배송 추적
    # 3. 반품 처리
    # 4. 재고 확인

    # Knowledge Base 연결
    # - 제품 카탈로그
    # - 배송 정책
    # - 반품 규정

    return agent['agent']['agentId']

박시니어 개발자가 화면을 공유하며 말했습니다. "실제로 우리 회사에서 사용하는 몇 가지 사례를 보여드릴게요." 김개발 씨는 눈을 반짝이며 화면을 바라봤습니다.

시나리오 1: 고객 서비스 자동화 가장 흔한 활용 사례는 고객 서비스입니다. 전자상거래 회사를 생각해보세요.

하루에 수백 건의 고객 문의가 들어옵니다. "주문이 언제 도착해?", "반품하고 싶어요", "이 제품 재입고 언제 돼요?" 같은 질문들입니다.

전통적인 챗봇으로는 한계가 있었습니다. 미리 정해진 시나리오대로만 대답할 수 있었기 때문입니다.

하지만 Bedrock Agent를 사용하면 훨씬 자연스럽고 유연하게 대응할 수 있습니다. 고객 서비스 에이전트의 구성 이런 에이전트는 어떻게 만들까요?

먼저 여러 Action Groups를 만듭니다. "주문조회", "배송추적", "반품신청", "재고확인" 같은 기능들입니다.

각 Action은 백엔드 API나 데이터베이스와 연동됩니다. 그다음 Knowledge Base를 구축합니다.

제품 정보, 배송 정책, 반품 규정, 자주 묻는 질문을 저장합니다. 에이전트가 정확한 정보를 참고해서 답변할 수 있습니다.

마지막으로 instruction을 잘 작성합니다. "항상 친절하게", "고객의 감정에 공감하기", "문제를 신속하게 해결하기" 같은 원칙을 명시합니다.

실제 대화 예시 고객이 이렇게 말합니다. "지난주에 주문한 운동화가 아직 안 왔는데, 어떻게 된 거예요?

내일 신고 나가야 하는데..." 에이전트는 이렇게 처리합니다. 먼저 "주문조회" Action을 실행해서 고객의 최근 주문을 찾습니다.

그다음 "배송추적" Action으로 현재 배송 상태를 확인합니다. 물류센터에서 지연되고 있다는 것을 발견합니다.

그러면 에이전트가 이렇게 답합니다. "고객님, 불편을 드려 죄송합니다.

확인 결과 물류센터에서 지연이 발생했습니다. 현재 출고 대기 중이며, 내일 오전 중 도착 예정입니다.

혹시 더 급하시다면 가까운 매장에서 당일 수령도 가능합니다. 어떻게 해드릴까요?" 시나리오 2: 내부 업무 자동화 Bedrock Agents는 대외 서비스뿐 아니라 사내 업무에도 활용됩니다.

HR 부서를 예로 들어보겠습니다. 직원들이 매일 인사팀에 질문합니다.

"연차 며칠 남았어?", "건강검진 예약 어떻게 해?", "경조사비 신청 방법이 뭐야?" 같은 것들입니다. 인사 담당자가 이런 반복적인 질문에 일일이 답하느라 시간을 뺏깁니다.

정작 중요한 전략적 업무는 못 하게 됩니다. HR 에이전트 구축 이럴 때 HR 에이전트를 만들면 효과적입니다.

Action Groups로 "연차조회", "급여명세서", "건강검진예약", "경조사비신청" 같은 기능을 만듭니다. 각 Action은 인사 시스템 API와 연동됩니다.

Knowledge Base에는 인사 규정, 복지 제도 안내서, 각종 신청 양식 작성법을 넣습니다. 에이전트가 정확하게 안내할 수 있습니다.

직원들은 슬랙이나 팀즈에서 에이전트에게 편하게 물어봅니다. 에이전트가 즉시 답하거나 처리해줍니다.

인사 담당자는 복잡한 케이스에만 집중할 수 있습니다. 시나리오 3: 데이터 분석 비서 경영진이나 데이터 분석가를 위한 에이전트도 유용합니다.

CEO가 이렇게 물어봅니다. "이번 분기 매출이 작년 동기 대비 어떻게 변했어?

그리고 어떤 제품이 가장 잘 팔렸어?" 전통적으로는 데이터 분석가에게 요청하고, 분석가가 SQL을 작성하고, 결과를 정리해서 보고서를 만들어야 했습니다. 시간이 오래 걸립니다.

데이터 분석 에이전트 Bedrock Agent는 이 과정을 자동화할 수 있습니다. Action Groups로 "데이터베이스_쿼리", "차트_생성", "보고서_작성" 같은 기능을 만듭니다.

"데이터베이스_쿼리" Action은 자연어를 SQL로 변환해서 실행합니다. CEO의 질문을 받으면, 에이전트가 먼저 필요한 데이터를 파악합니다.

그다음 SQL을 생성해서 데이터베이스를 조회합니다. 결과를 분석해서 "이번 분기 매출은 전년 대비 15% 증가했습니다.

가장 많이 팔린 제품은 A입니다" 같은 답을 줍니다. 필요하면 차트를 생성해서 시각화할 수도 있습니다.

시나리오 4: 개인 비서 개인 생산성 도구로도 활용할 수 있습니다. "오늘 일정 알려줘", "내일 회의 전에 자료 준비해야 하는데 알림 설정해줘", "지난주에 읽은 이메일 중에 계약 관련된 거 찾아줘" 같은 요청을 처리합니다.

Action Groups로 "캘린더_조회", "이메일_검색", "리마인더_설정", "문서_요약" 같은 기능을 구현합니다. Knowledge Base에는 개인 메모, 회의록, 참고 자료를 넣습니다.

시나리오 5: 기술 지원 에이전트 소프트웨어 회사의 기술 지원팀을 위한 에이전트입니다. 고객이 "API 인증이 안 돼요", "데이터베이스 연결 에러가 나요" 같은 기술적 문제를 문의합니다.

에이전트가 문제를 진단하고 해결 방법을 안내합니다. Action Groups로 "로그_조회", "시스템_상태_확인", "설정_검증" 같은 진단 도구를 만듭니다.

Knowledge Base에는 문제 해결 가이드, API 문서, 에러 코드 설명을 저장합니다. 에이전트가 먼저 자동 진단을 수행합니다.

간단한 문제는 바로 해결 방법을 알려줍니다. 복잡한 문제는 엔지니어에게 에스컬레이션하되, 이미 수집한 진단 정보를 함께 전달합니다.

코드 분석 위의 코드는 전자상거래 에이전트의 기본 골격입니다. create_agent로 에이전트를 만들고, instruction에 고객 서비스 원칙을 명시했습니다.

실제로는 여기에 Action Groups를 추가하고, Knowledge Base를 연결하고, 테스트를 거쳐야 합니다. 각 비즈니스 도메인에 맞게 커스터마이징하면 됩니다.

핵심 패턴은 동일합니다. 자연어 이해 + 작업 수행 + 지식 참조입니다.

선택 기준 어떤 작업을 에이전트로 만들면 좋을까요? 첫째, 반복적이고 규칙 기반인 작업이 적합합니다.

매번 같은 절차를 따르는 업무입니다. 둘째, 여러 시스템을 오케스트레이션해야 하는 작업입니다.

데이터를 여기저기서 모아서 처리하는 경우입니다. 셋째, 자연어 인터페이스가 유용한 작업입니다.

사용자가 복잡한 UI를 배우기 어려운 경우입니다. 넷째, 24/7 가용성이 필요한 작업입니다.

사람은 쉬어야 하지만 에이전트는 항상 깨어있습니다. 주의사항 모든 작업이 에이전트에 적합한 것은 아닙니다.

창의적이고 전략적인 의사결정은 여전히 사람이 해야 합니다. 복잡한 협상이나 감정적 공감이 중요한 상황도 마찬가지입니다.

법적 책임이 큰 의사결정도 신중해야 합니다. 에이전트는 사람을 대체하는 것이 아니라 보조하는 도구입니다.

반복적이고 시간이 오래 걸리는 작업을 자동화해서, 사람이 더 가치 있는 일에 집중할 수 있게 합니다. 정리 김개발 씨는 이제 확신을 가지게 되었습니다.

"우리 회사에도 적용할 수 있는 게 정말 많네요!" Bedrock Agents는 고객 서비스부터 내부 업무 자동화까지 폭넓게 활용됩니다. 여러분의 비즈니스에 맞는 시나리오를 찾아서 구현해보세요.

실전 팁

💡 - 반복적이고 규칙 기반인 업무부터 시작하세요. 성공 확률이 높습니다

파일럿 프로젝트로 작게 시작해서 점진적으로 확장하세요
사용자 피드백을 지속적으로 수집해서 에이전트를 개선하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#BedrockAgents#AIAgent#ActionGroups#KnowledgeBase

Bedrock Agents 완벽 입문 가이드

# Bedrock Agents 완벽 입문 가이드 AWS Bedrock Agents의 기본 개념부터 실전 활용까지 초급 개발자를 위한 완벽 가이드입니다. AI 에이전트의 아키텍처와 구성 요소를 쉬운 비유로 이해하고, 실무에서 바로 활용할 수 있는 방법을 배웁니다. --- ## 목차 1. [AI_에이전트란_무엇인가](#ai-에이전트란-무엇인가) 2. [Bedrock_Agents_아키텍처](#bedrock-agents-아키텍처) 3. [에이전트_구성_요소](#에이전트-구성-요소) 4. [Action_Groups_개념](#action-groups-개념) 5. [Knowledge_Base_연동](#knowledge-base-연동) 6. [에이전트_활용_시나리오](#에이전트-활용-시나리오) --- ## 1. AI_에이전트란_무엇인가 스타트업에서 일하는 김개발 씨는 CEO로부터 흥미로운 프로젝트를 맡았습니다. "고객 문의를 자동으로 처리하는 AI 시스템을 만들어주세요." 단순히 질문에 답하는 챗봇이 아니라, 데이터베이스를 조회하고 주문도 처리할 수 있는 똑똑한 시스템이 필요했습니다. **AI 에이전트**는 단순히 질문에 답하는 것을 넘어서 실제 작업을 수행하는 지능형 시스템입니다. 마치 비서가 상사의 지시를 듣고 여러 부서에 연락해서 일을 처리하는 것처럼, AI 에이전트도 사용자의 요청을 이해하고 필요한 도구를 사용해 목표를 달성합니다. AWS Bedrock Agents는 이런 에이전트를 쉽게 만들 수 있게 해주는 관리형 서비스입니다. 다음 코드를 살펴봅시다. ```python import boto3 # Bedrock Agent 클라이언트 생성 bedrock_agent = boto3.client('bedrock-agent-runtime') # 에이전트에게 작업 요청 response = bedrock_agent.invoke_agent( agentId='ABCD1234', agentAliasId='PROD', sessionId='session-123', # 사용자의 자연어 요청 inputText='지난달 매출 데이터를 조회하고 보고서를 작성해줘' ) # 응답 스트림 처리 for event in response['completion']: print(event['chunk']['bytes'].decode()) ``` 김개발 씨는 지금까지 챗봇을 만들어본 경험이 있습니다. 하지만 그 챗봇은 정해진 시나리오대로만 대답할 수 있었습니다. "주문 조회는 1번, 환불은 2번을 누르세요" 같은 식이었죠. 하지만 CEO가 원하는 것은 달랐습니다. "오늘 배송 예정인 주문 중에 강남구로 가는 건 몇 개야?"라는 복잡한 질문에도 대답할 수 있어야 했습니다. 단순한 챗봇으로는 불가능한 일이었습니다. **AI 에이전트란 무엇일까요?** 쉽게 비유하자면, AI 에이전트는 마치 유능한 비서와 같습니다. 상사가 "이번 분기 실적을 정리해서 보고서 만들어줘"라고 말하면, 비서는 이렇게 일합니다. 먼저 회계팀에 가서 매출 데이터를 받아옵니다. 그다음 영업팀에서 고객 정보를 확인합니다. 마지막으로 파워포인트를 열어서 보고서를 작성합니다. AI 에이전트도 정확히 이렇게 작동합니다. 사용자의 요청을 듣고, 어떤 도구를 사용해야 할지 판단하고, 필요한 작업을 순서대로 실행합니다. **전통적인 챗봇과의 차이점** 예전 방식의 챗봇은 미리 정해진 규칙대로만 움직였습니다. "A라는 질문이 들어오면 B라고 대답한다"는 식으로 모든 경우의 수를 프로그래머가 직접 작성해야 했습니다. 고객이 조금만 다르게 질문해도 제대로 응답하지 못했습니다. 더 큰 문제는 실제 작업을 수행할 수 없다는 점이었습니다. 데이터베이스를 조회하거나 API를 호출하는 것은 별도의 복잡한 코드가 필요했습니다. 챗봇과 업무 시스템을 연결하는 것이 매우 어려웠습니다. **AI 에이전트의 등장** 바로 이런 문제를 해결하기 위해 **AI 에이전트**가 등장했습니다. AI 에이전트는 **대규모 언어 모델**(LLM)의 추론 능력을 활용합니다. 사용자의 자연어 요청을 이해하고, 스스로 계획을 세우고, 필요한 도구를 선택해서 사용합니다. 마치 사람처럼 생각하면서 일을 처리하는 것입니다. **AWS Bedrock Agents란?** AWS에서 제공하는 **Bedrock Agents**는 이런 AI 에이전트를 쉽게 만들 수 있게 해주는 관리형 서비스입니다. 직접 LLM을 호출하고, 프롬프트를 관리하고, 도구 실행 로직을 구현할 필요가 없습니다. Bedrock Agents가 이 모든 복잡한 과정을 자동으로 처리해줍니다. 개발자는 비즈니스 로직에만 집중할 수 있습니다. **코드 분석** 위의 코드를 살펴보겠습니다. 먼저 boto3를 사용해서 Bedrock Agent Runtime 클라이언트를 생성합니다. 이것은 에이전트와 통신하기 위한 창구입니다. invoke_agent 함수를 호출할 때 agentId와 agentAliasId를 지정합니다. 이것은 어떤 에이전트를 사용할지 알려주는 식별자입니다. 가장 중요한 부분은 inputText입니다. 여기에 자연어로 된 사용자 요청을 그대로 전달합니다. "지난달 매출 데이터를 조회하고 보고서를 작성해줘"라는 복잡한 요청을 그대로 넣으면, 에이전트가 알아서 처리합니다. 응답은 스트리밍 방식으로 돌아옵니다. 에이전트가 작업을 수행하면서 중간 결과를 실시간으로 받아볼 수 있습니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 회사를 운영한다고 가정해봅시다. 고객 센터에 하루에 수백 건의 문의가 들어옵니다. "내 주문 어디까지 왔어?", "반품하고 싶은데 어떻게 해?", "이 제품 재입고 언제 돼?" 같은 질문들입니다. Bedrock Agent를 활용하면 이런 문의를 자동으로 처리할 수 있습니다. 에이전트가 주문 데이터베이스를 조회하고, 배송 추적 시스템과 연동하고, 재고 관리 시스템을 확인합니다. 사람 상담원은 정말 복잡한 문제에만 집중할 수 있습니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 AI 에이전트를 만능으로 생각하는 것입니다. 에이전트도 결국 LLM을 기반으로 하기 때문에, 학습 데이터에 없는 전문 지식은 알지 못합니다. 또한 복잡한 수학 계산이나 정확한 논리 연산은 여전히 어려울 수 있습니다. 따라서 에이전트에게 적합한 작업과 그렇지 않은 작업을 구분해야 합니다. 자연어 이해가 필요하고, 여러 시스템을 오케스트레이션하는 작업에 강점이 있습니다. **정리** 김개발 씨는 이제 AI 에이전트의 개념을 이해했습니다. 단순한 챗봇이 아니라, 실제로 일을 처리할 수 있는 지능형 시스템이라는 것을 알게 되었습니다. Bedrock Agents를 사용하면 복잡한 인프라 구축 없이도 강력한 AI 에이전트를 만들 수 있습니다. 다음 섹션에서는 Bedrock Agents의 아키텍처를 자세히 살펴보겠습니다. **실전 팁** 💡 - AI 에이전트는 자연어 이해와 여러 시스템 연동이 필요한 작업에 적합합니다 - Bedrock Agents를 사용하면 복잡한 LLM 오케스트레이션 로직을 직접 구현하지 않아도 됩니다 --- ## 2. Bedrock_Agents_아키텍처 김개발 씨는 이제 Bedrock Agent를 본격적으로 만들기로 했습니다. 하지만 AWS 콘솔을 열어보니 낯선 용어들이 가득했습니다. "Foundation Model", "Action Group", "Knowledge Base"... 도대체 이것들이 어떻게 연결되는 걸까요? **Bedrock Agents 아키텍처**는 크게 세 가지 핵심 요소로 구성됩니다. **Foundation Model**은 두뇌 역할을 하고, **Action Groups**는 손발이 되어 실제 작업을 수행하며, **Knowledge Base**는 기억 저장소 역할을 합니다. 이 세 가지가 유기적으로 연결되어 지능형 에이전트가 작동합니다. 다음 코드를 살펴봅시다. ```python import boto3 bedrock = boto3.client('bedrock-agent') # 에이전트 생성 - 아키텍처의 핵심 정의 agent = bedrock.create_agent( agentName='customer-service-agent', # 두뇌: Foundation Model 선택 foundationModel='anthropic.claude-3-sonnet-20240229-v1:0', instruction='당신은 친절한 고객 센터 상담원입니다.', # 세션 타임아웃 설정 idleSessionTTLInSeconds=600, # 에이전트 역할 (AWS IAM) agentResourceRoleArn='arn:aws:iam::123456789012:role/BedrockAgentRole' ) agent_id = agent['agent']['agentId'] print(f"에이전트 생성 완료: {agent_id}") ``` 김개발 씨는 박시니어 개발자에게 물었습니다. "선배님, 이 아키텍처가 너무 복잡해 보이는데 어떻게 이해하면 좋을까요?" 박시니어 씨가 화이트보드를 들고 왔습니다. "이렇게 생각해보세요. 에이전트를 사람에 비유하면 쉬워요." **사람에 비유한 아키�ecture** 사람은 세 가지 능력이 필요합니다. 먼저 **두뇌**가 있어야 생각할 수 있습니다. 그다음 **손발**이 있어야 실제 행동을 할 수 있습니다. 마지막으로 **기억**이 있어야 과거 경험을 활용할 수 있습니다. Bedrock Agent도 정확히 이런 구조입니다. **Foundation Model**이 두뇌, **Action Groups**가 손발, **Knowledge Base**가 기억에 해당합니다. **Foundation Model: 에이전트의 두뇌** Foundation Model은 에이전트의 사고를 담당합니다. 사용자의 요청을 받으면 "이 요청을 어떻게 처리해야 할까?"를 고민합니다. 여러 가지 선택지 중에서 최선의 방법을 선택합니다. 작업 결과를 보고 다음에 무엇을 할지 계획합니다. AWS Bedrock에서는 Claude, Jurassic, Titan 같은 여러 Foundation Model 중에서 선택할 수 있습니다. 각 모델마다 특징이 다릅니다. Claude는 긴 문맥을 잘 이해하고, Titan은 비용 효율적입니다. **Action Groups: 에이전트의 손발** Action Groups는 실제 작업을 수행하는 도구입니다. 예를 들어 "데이터베이스 조회", "이메일 발송", "API 호출" 같은 구체적인 동작들입니다. 에이전트는 상황에 맞게 필요한 Action을 선택해서 실행합니다. 마치 비서에게 "전화기", "팩스기", "컴퓨터" 같은 도구를 제공하는 것과 같습니다. 비서는 상황에 맞게 적절한 도구를 선택해서 사용합니다. **Knowledge Base: 에이전트의 기억** Knowledge Base는 에이전트가 참고할 수 있는 지식 저장소입니다. 회사의 매뉴얼, 제품 정보, FAQ 문서 같은 것들을 저장해둡니다. 에이전트는 사용자 질문에 답하기 전에 Knowledge Base를 검색해서 정확한 정보를 찾아냅니다. 이것은 마치 사람이 업무 매뉴얼을 참고하는 것과 같습니다. 모든 것을 외울 수는 없지만, 필요할 때 찾아볼 수 있습니다. **아키텍처의 작동 흐름** 전체적인 흐름을 살펴보겠습니다. 사용자가 "이번 달 매출이 얼마야?"라고 물어봅니다. 먼저 **Foundation Model**이 이 요청을 분석합니다. "매출 데이터를 조회해야겠군." 그다음 적절한 **Action Group**을 선택합니다. "데이터베이스 조회 액션을 실행해야지." 만약 추가 정보가 필요하면 **Knowledge Base**를 검색합니다. "매출 계산 방식은 뭐더라?" 이 모든 과정이 자동으로 연결되어 실행됩니다. 개발자는 각 구성 요소만 정의해주면 됩니다. **코드 분석** 위의 코드를 자세히 살펴보겠습니다. create_agent 함수가 에이전트의 기본 골격을 만듭니다. agentName은 에이전트의 이름입니다. 가장 중요한 것은 foundationModel 파라미터입니다. 여기서 어떤 AI 모델을 두뇌로 사용할지 결정합니다. instruction은 에이전트의 기본 성격과 역할을 정의합니다. 이것은 시스템 프롬프트로 작동해서 모든 대화에 영향을 줍니다. agentResourceRoleArn은 에이전트가 AWS 리소스에 접근할 때 사용할 IAM 역할입니다. 생성이 완료되면 agent_id가 반환됩니다. 이 ID로 나중에 Action Groups와 Knowledge Base를 연결할 수 있습니다. **실무 활용 사례** 실제 프로젝트에서는 어떻게 설계할까요? 예를 들어 인사 관리 시스템을 만든다고 가정해봅시다. 직원들이 "내 연차 며칠 남았어?", "급여 명세서 보여줘", "회의실 예약하고 싶어" 같은 요청을 합니다. 이럴 때 Foundation Model은 Claude 3 Sonnet을 선택합니다. 복잡한 요청도 잘 이해하기 때문입니다. Action Groups는 "연차조회", "급여조회", "회의실예약" 같은 기능으로 구성합니다. Knowledge Base에는 인사 규정, 복지 제도 안내서를 넣어둡니다. **주의사항** 아키텍처를 설계할 때 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 너무 많은 Action을 한 번에 추가하는 것입니다. Action이 많아질수록 에이전트가 혼란스러워질 수 있습니다. 처음에는 핵심 기능 3-5개로 시작하고, 점진적으로 확장하는 것이 좋습니다. 또한 Foundation Model 선택도 중요합니다. 복잡한 추론이 필요하면 Claude 3 Opus를, 빠른 응답이 필요하면 Claude 3 Haiku를 선택해야 합니다. **정리** 김개발 씨는 이제 아키텍처를 이해했습니다. "아, 결국 사람처럼 두뇌, 손발, 기억을 갖춘 시스템이네요!" Bedrock Agents의 아키텍처는 복잡해 보이지만, 각 구성 요소의 역할을 이해하면 명확합니다. 다음 섹션에서는 각 구성 요소를 더 자세히 살펴보겠습니다. **실전 팁** 💡 - Foundation Model 선택은 작업의 복잡도와 응답 속도 요구사항을 고려하세요 - Action Groups는 처음에는 적게 시작하고 점진적으로 확장하는 것이 좋습니다 --- ## 3. 에이전트_구성_요소 김개발 씨는 이제 실제로 에이전트를 구성하기 시작했습니다. 하지만 콘솔에서 설정할 항목들이 너무 많았습니다. "Instruction", "Session Timeout", "IAM Role"... 각각 무슨 역할을 하는 걸까요? 잘못 설정하면 어떤 문제가 생길까요? 에이전트 구성 요소는 **Instruction**(행동 지침), **Session State**(대화 상태 관리), **IAM Role**(권한 관리), **Guardrails**(안전장치)로 이루어집니다. Instruction은 에이전트의 성격과 역할을 정의하고, Session State는 대화 맥락을 유지하며, IAM Role은 보안을 담당하고, Guardrails는 부적절한 응답을 방지합니다. 다음 코드를 살펴봅시다. ```python import boto3 bedrock = boto3.client('bedrock-agent') # 에이전트 상세 구성 agent = bedrock.create_agent( agentName='hr-assistant', foundationModel='anthropic.claude-3-sonnet-20240229-v1:0', # Instruction: 에이전트의 역할과 행동 지침 instruction='''당신은 회사 인사팀 도우미입니다. 직원의 연차, 급여, 복지 문의를 도와줍니다. 항상 정중하고 정확하게 답변하세요. 개인정보는 절대 유출하지 마세요.''', # 세션 타임아웃 (초) idleSessionTTLInSeconds=1800, # IAM Role ARN agentResourceRoleArn='arn:aws:iam::123456789012:role/HRAgentRole', # Guardrails ID (옵션) guardrailConfiguration={ 'guardrailIdentifier': 'abc123xyz', 'guardrailVersion': '1' } ) ``` 박시니어 개발자가 김개발 씨의 화면을 보더니 말했습니다. "이 설정들이 다 중요해요. 하나씩 제대로 이해하고 설정해야 합니다." 김개발 씨는 노트북을 꺼내 들었습니다. "하나씩 알려주세요!" **Instruction: 에이전트의 정체성** **Instruction**은 에이전트에게 주는 근본적인 지침서입니다. 마치 신입사원에게 주는 업무 매뉴얼과 같습니다. "당신의 역할은 무엇이고, 어떤 원칙으로 일해야 하는가"를 명확하게 알려줍니다. 이것은 모든 대화에서 기본 전제로 작동합니다. 좋은 Instruction은 구체적이고 명확해야 합니다. "친절하게 답변하세요"보다는 "항상 존댓말을 사용하고, 이해하기 쉬운 용어로 설명하며, 답변 끝에 추가 질문 여부를 물어보세요"가 훨씬 좋습니다. 반대로 너무 제약이 많으면 에이전트가 경직될 수 있습니다. "절대 이것은 하지 마세요, 저것도 하지 마세요"라고 하면 오히려 도움이 안 되는 답변만 하게 됩니다. 균형이 중요합니다. **Instruction 작성 팁** 실무에서는 이렇게 작성합니다. 첫 번째 문단에서 역할을 명확히 합니다. "당신은 고객 서비스 담당자입니다." 두 번째 문단에서 주요 업무 범위를 설명합니다. "주문 조회, 반품 처리, 배송 추적을 도와줍니다." 세 번째 문단에서 응대 원칙을 정의합니다. "항상 정중하고 공감하는 태도를 유지하세요." 마지막으로 금지 사항을 명시합니다. "개인정보를 요구하지 마세요", "의료 조언을 하지 마세요" 같은 것들입니다. **Session State: 대화 맥락 관리** **Session State**는 대화의 연속성을 유지하는 메커니즘입니다. 사람과 대화할 때를 생각해보세요. "어제 말한 그 건 어떻게 됐어?"라고 물으면, 상대방은 어제 대화를 기억하고 있어야 답할 수 있습니다. 에이전트도 마찬가지입니다. Bedrock Agents는 각 사용자별로 Session ID를 부여합니다. 같은 Session ID로 들어오는 요청들은 이전 대화 기록을 공유합니다. 사용자가 "그거 다시 설명해줘"라고 하면, 에이전트는 바로 전 대화를 참고해서 답합니다. **Session Timeout 설정** idleSessionTTLInSeconds는 세션이 만료되는 시간입니다. 예를 들어 1800초(30분)로 설정하면, 사용자가 30분 동안 아무 말도 하지 않으면 세션이 종료됩니다. 다음에 다시 대화를 시작하면 새로운 세션이 생성되고, 이전 대화 기록은 참조되지 않습니다. 이 값을 너무 길게 설정하면 메모리 비용이 증가합니다. 너무 짧게 설정하면 사용자 경험이 나빠집니다. 보통 10-30분 사이가 적당합니다. **IAM Role: 권한 관리** **IAM Role**은 에이전트가 AWS 리소스에 접근할 때 사용하는 신분증입니다. 에이전트가 Lambda를 호출하거나, S3에서 파일을 읽거나, DynamoDB를 조회할 때 권한이 필요합니다. 이때 agentResourceRoleArn에 지정된 IAM Role을 사용합니다. 보안을 위해 최소 권한 원칙을 따라야 합니다. 에이전트가 꼭 필요한 리소스에만 접근할 수 있도록 권한을 제한합니다. 예를 들어 읽기만 필요하면 쓰기 권한은 주지 않습니다. **IAM Policy 예시** HR 에이전트라면 직원 데이터베이스 조회 권한만 주고, 수정 권한은 주지 않습니다. Lambda 함수 중에서도 "get-employee-info" 같은 특정 함수만 호출할 수 있게 제한합니다. 이렇게 세밀하게 권한을 관리하면, 만약 에이전트가 예상치 못한 동작을 하더라도 피해를 최소화할 수 있습니다. **Guardrails: 안전장치** **Guardrails**는 에이전트가 부적절한 응답을 하지 않도록 막는 안전장치입니다. 예를 들어 사용자가 욕설을 하거나, 민감한 주제를 물어보거나, 시스템을 악용하려고 할 때 이것을 감지하고 차단합니다. 또한 에이전트가 개인정보나 기밀정보를 유출하지 않도록 필터링합니다. Bedrock Guardrails를 사용하면 콘텐츠 필터, 민감정보 탐지, 주제 제한 같은 기능을 쉽게 적용할 수 있습니다. **코드 분석** 위의 코드를 다시 보겠습니다. instruction 파라미터에 여러 줄의 지침을 작성했습니다. 역할, 업무 범위, 원칙, 금지사항을 모두 포함했습니다. idleSessionTTLInSeconds는 1800초로 설정했습니다. 30분 동안 대화가 없으면 세션이 종료됩니다. agentResourceRoleArn에는 미리 만들어둔 IAM Role의 ARN을 지정했습니다. guardrailConfiguration에는 Guardrails ID와 버전을 넣었습니다. **실무 활용 사례** 실제 서비스에서는 이렇게 구성합니다. 금융 서비스 챗봇을 만든다면 Instruction에 "투자 조언을 하지 마세요", "법률 자문을 하지 마세요" 같은 명확한 금지 사항을 넣습니다. Session Timeout은 보안을 위해 짧게(5-10분) 설정합니다. IAM Role은 계좌 조회 API만 호출할 수 있게 제한하고, 송금 API는 접근할 수 없게 합니다. Guardrails에는 금융 규제 관련 필터를 적용합니다. **주의사항** 구성 요소 설정 시 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 Instruction을 너무 모호하게 작성하는 것입니다. "잘 대답하세요"보다는 구체적인 행동 지침을 주어야 합니다. 또한 IAM Role에 과도한 권한을 주는 것도 위험합니다. 테스트 환경에서는 느슨하게 설정하더라도, 프로덕션에서는 엄격하게 적용해야 합니다. **정리** 김개발 씨는 각 구성 요소의 역할을 정확히 이해했습니다. "Instruction은 매뉴얼, Session은 기억력, IAM은 출입증, Guardrails는 안전벨트네요!" 에이전트 구성 요소를 제대로 설정하면 안정적이고 안전한 서비스를 만들 수 있습니다. 다음 섹션에서는 Action Groups에 대해 자세히 알아보겠습니다. **실전 팁** 💡 - Instruction은 구체적이고 명확하게 작성하되, 너무 제약적이지 않게 균형을 맞추세요 - IAM Role은 최소 권한 원칙을 따라 꼭 필요한 권한만 부여하세요 - 프로덕션 환경에서는 반드시 Guardrails를 적용하세요 --- ## 4. Action_Groups_개념 에이전트의 기본 구조를 만든 김개발 씨는 이제 실제 기능을 추가하려고 합니다. "연차 조회", "급여 확인" 같은 실제 작업을 수행하려면 어떻게 해야 할까요? 박시니어 개발자가 말했습니다. "Action Groups를 만들어야 해요." **Action Groups**는 에이전트가 실제로 수행할 수 있는 작업의 묶음입니다. 각 Action은 Lambda 함수나 API로 구현되며, **OpenAPI 스키마**로 정의됩니다. 에이전트는 사용자 요청을 분석해서 적절한 Action을 선택하고 실행합니다. 마치 도구 상자에서 필요한 도구를 꺼내 쓰는 것과 같습니다. 다음 코드를 살펴봅시다. ```python import boto3 import json bedrock = boto3.client('bedrock-agent') # OpenAPI 스키마 정의 api_schema = { "openapi": "3.0.0", "info": {"title": "HR API", "version": "1.0.0"}, "paths": { "/getVacationDays": { "get": { "description": "직원의 남은 연차 일수를 조회합니다", "parameters": [{ "name": "employeeId", "in": "query", "required": True, "schema": {"type": "string"} }], "responses": {"200": {"description": "성공"}} } } } } # Action Group 생성 action_group = bedrock.create_agent_action_group( agentId='ABC123', agentVersion='DRAFT', actionGroupName='hr-actions', actionGroupExecutor={ 'lambda': 'arn:aws:lambda:us-east-1:123456789012:function:hr-handler' }, apiSchema={'payload': json.dumps(api_schema)} ) ``` 김개발 씨가 물었습니다. "선배님, Action Groups가 정확히 뭔가요? 그냥 Lambda 함수 연결하는 거 아닌가요?" 박시니어 개발자가 웃으며 대답했습니다. "비슷하지만 훨씬 더 똑똑해요. 에이전트가 언제 어떤 Action을 써야 할지 스스로 판단하거든요." **Action Groups란 무엇인가** **Action Groups**는 에이전트의 능력을 확장하는 도구 세트입니다. 쉽게 비유하자면, 수리공이 가지고 다니는 공구함과 같습니다. 드라이버, 렌치, 망치 같은 다양한 도구가 들어있습니다. 수리공은 상황을 보고 적절한 도구를 선택해서 사용합니다. 에이전트도 마찬가지입니다. 여러 Action들을 가지고 있다가, 사용자 요청에 맞는 Action을 선택해서 실행합니다. 중요한 것은 개발자가 "이 상황에는 이 함수를 써라"고 직접 지정하지 않는다는 점입니다. 에이전트가 스스로 판단합니다. **왜 Action Groups가 필요한가** 전통적인 방식에서는 모든 분기 처리를 개발자가 코딩해야 했습니다. "사용자가 A라고 하면 함수1을 호출하고, B라고 하면 함수2를 호출한다"는 식으로 if-else 문을 잔뜩 작성했습니다. 사용자가 조금만 다르게 표현해도 제대로 작동하지 않았습니다. 더 큰 문제는 새로운 기능을 추가할 때마다 기존 코드를 수정해야 한다는 점이었습니다. 코드가 점점 복잡해지고 유지보수가 어려워졌습니다. **Action Groups의 작동 원리** Action Groups를 사용하면 이 문제가 해결됩니다. 개발자는 각 Action의 **설명**과 **파라미터**만 정의합니다. 예를 들어 "getVacationDays: 직원의 남은 연차 일수를 조회합니다. 파라미터는 employeeId입니다." 이렇게요. 그러면 에이전트가 사용자 요청을 보고 "아, 연차를 물어보는구나. getVacationDays를 실행해야겠다"고 스스로 판단합니다. 사용자가 "연차 며칠 남았어?", "휴가 가능한 날짜 알려줘", "올해 쓸 수 있는 휴가는?" 어떻게 표현하든 같은 Action을 실행합니다. **OpenAPI 스키마의 역할** Action Groups는 **OpenAPI 스키마**로 정의됩니다. OpenAPI는 REST API를 설명하는 표준 형식입니다. 어떤 엔드포인트가 있고, 어떤 파라미터를 받고, 어떤 응답을 돌려주는지 명세합니다. 에이전트는 이 스키마를 읽고 "아, 이 Action은 이런 일을 하는구나. 이런 정보가 필요하구나"를 이해합니다. 그래서 사용자에게 부족한 정보를 물어보거나, 여러 Action을 조합해서 사용할 수도 있습니다. **코드 분석** 위의 코드를 자세히 살펴보겠습니다. 먼저 OpenAPI 스키마를 정의합니다. paths 안에 "/getVacationDays"라는 엔드포인트를 만들었습니다. description에 "직원의 남은 연차 일수를 조회합니다"라고 명확하게 설명했습니다. 이 설명이 매우 중요합니다. 에이전트가 이것을 읽고 언제 이 Action을 써야 할지 판단합니다. parameters에는 employeeId가 필요하다고 명시했습니다. type은 string입니다. required는 True로 설정했습니다. create_agent_action_group 함수로 Action Group을 생성합니다. actionGroupExecutor에 Lambda 함수의 ARN을 지정합니다. 이 Lambda가 실제 작업을 수행합니다. **Lambda 함수 구현** Action Group이 호출하는 Lambda 함수는 이렇게 생겼습니다. 에이전트가 요청을 보내면, Lambda는 event 파라미터로 받습니다. 여기에는 어떤 Action인지, 어떤 파라미터가 전달됐는지 정보가 들어있습니다. Lambda는 비즈니스 로직을 실행하고, 결과를 JSON으로 반환합니다. 중요한 것은 Lambda가 에이전트의 형식에 맞춰 응답해야 한다는 점입니다. 단순히 데이터만 보내는 게 아니라, 에이전트가 이해할 수 있는 구조로 포장해야 합니다. **실무 활용 사례** 실제 프로젝트에서는 어떻게 설계할까요? 예를 들어 전자상거래 고객 센터를 만든다면 이런 Action Groups를 구성할 수 있습니다. "주문조회", "배송추적", "반품신청", "재고확인" 같은 Action들입니다. 각 Action은 백엔드 API나 데이터베이스와 연동됩니다. 에이전트는 고객의 질문을 듣고 적절한 Action을 선택합니다. "내 주문 어디까지 왔어?"라고 하면 "배송추적" Action을 실행합니다. **여러 Action 조합하기** 에이전트의 진짜 강점은 여러 Action을 조합할 수 있다는 것입니다. 사용자가 "지난 3개월 동안 산 상품 중에 가장 비싼 거 뭐야?"라고 물어봤다고 가정해봅시다. 이것은 단일 Action으로 처리할 수 없습니다. 에이전트는 이렇게 계획을 세웁니다. 첫째, "주문조회" Action으로 지난 3개월 주문을 가져옵니다. 둘째, "상품상세" Action으로 각 상품의 가격을 확인합니다. 셋째, 가격을 비교해서 가장 비싼 것을 찾습니다. 마지막으로 결과를 사용자에게 알려줍니다. **주의사항** Action Groups를 만들 때 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 Action 설명을 모호하게 쓰는 것입니다. "데이터를 가져옵니다"보다는 "직원 ID를 받아서 해당 직원의 남은 연차 일수를 조회합니다"처럼 구체적으로 써야 합니다. 또한 한 Action에 너무 많은 기능을 넣지 마세요. 각 Action은 하나의 명확한 목적만 가져야 합니다. 이것이 Single Responsibility Principle입니다. **정리** 김개발 씨는 이제 Action Groups의 개념을 완전히 이해했습니다. "에이전트에게 도구를 주는 거네요. 그러면 에이전트가 알아서 골라 쓰는 거고요!" Action Groups를 잘 설계하면 에이전트의 능력을 무한대로 확장할 수 있습니다. 다음 섹션에서는 Knowledge Base 연동에 대해 알아보겠습니다. **실전 팁** 💡 - Action 설명은 최대한 구체적으로 작성하세요. 에이전트가 언제 사용해야 할지 명확하게 알 수 있어야 합니다 - 각 Action은 단일 책임 원칙을 따라 하나의 명확한 기능만 수행해야 합니다 - OpenAPI 스키마의 description 필드가 에이전트의 판단에 가장 중요한 역할을 합니다 --- ## 5. Knowledge_Base_연동 김개발 씨의 HR 에이전트는 점점 똑똑해지고 있었습니다. 하지만 문제가 생겼습니다. 직원이 "육아휴직 신청 방법이 뭐예요?"라고 물어보자 에이전트가 제대로 답하지 못했습니다. 회사의 복잡한 규정은 LLM이 학습한 데이터에 없었기 때문입니다. 박시니어 개발자가 조언했습니다. "Knowledge Base를 연동해야 해요." **Knowledge Base**는 에이전트가 참고할 수 있는 문서 저장소입니다. 회사 매뉴얼, FAQ, 제품 정보 같은 지식을 저장하면 에이전트가 **벡터 검색**으로 관련 정보를 찾아 정확하게 답변합니다. **RAG**(Retrieval Augmented Generation) 기술을 활용해서 LLM의 한계를 극복할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 bedrock = boto3.client('bedrock-agent') # Knowledge Base를 에이전트에 연결 kb_association = bedrock.associate_agent_knowledge_base( agentId='ABC123', agentVersion='DRAFT', description='회사 인사 규정 및 복지 제도 안내서', knowledgeBaseId='KB456XYZ', # Knowledge Base 사용 방법 지정 knowledgeBaseState='ENABLED' ) # 에이전트 Instruction 업데이트 bedrock.update_agent( agentId='ABC123', agentName='hr-assistant', instruction='''당신은 회사 인사팀 도우미입니다. 질문에 답변할 때 반드시 Knowledge Base를 먼저 검색하세요. 정확한 규정과 절차를 안내해야 합니다. Knowledge Base에 없는 정보는 "확인이 필요합니다"라고 답하세요.''', foundationModel='anthropic.claude-3-sonnet-20240229-v1:0' ) print("Knowledge Base 연동 완료") ``` 김개발 씨가 고개를 갸우뚱했습니다. "선배님, Knowledge Base가 뭔가요? 그냥 파일 저장소인가요?" 박시니어 개발자가 화이트보드에 그림을 그리기 시작했습니다. "단순한 저장소가 아니에요. 지능형 검색 시스템이죠." **Knowledge Base란 무엇인가** **Knowledge Base**는 에이전트가 참고할 수 있는 지식 저장소입니다. 쉽게 비유하자면, 회사 도서관과 같습니다. 직원이 궁금한 게 있으면 도서관에 가서 관련 책을 찾아봅니다. 에이전트도 마찬가지입니다. 사용자 질문을 받으면 Knowledge Base를 검색해서 관련 정보를 찾아냅니다. 중요한 것은 단순히 키워드로 찾는 것이 아니라 **의미 기반 검색**을 한다는 점입니다. 사용자가 "육아휴직"이라고 하면, "출산휴가", "양육 지원" 같은 관련 문서도 함께 찾아줍니다. **LLM의 한계와 RAG** LLM은 학습 데이터에만 의존합니다. 예를 들어 Claude는 2024년 초까지의 데이터로 학습했습니다. 여러분 회사의 2024년 인사 규정 개정안은 당연히 모릅니다. 또한 학습 데이터에 없는 전문적이고 구체적인 내용은 답할 수 없습니다. 더 큰 문제는 **환각**(hallucination)입니다. LLM은 모르는 것도 그럴듯하게 지어내는 경향이 있습니다. 인사 규정을 물어봤는데 잘못된 정보를 알려주면 큰일입니다. **RAG로 이 문제를 해결합니다** **RAG**(Retrieval Augmented Generation)는 검색과 생성을 결합한 기술입니다. 작동 원리는 간단합니다. 사용자가 질문하면, 먼저 Knowledge Base에서 관련 문서를 검색합니다. 그다음 검색된 문서를 LLM에게 보여주면서 "이 정보를 바탕으로 답변해줘"라고 요청합니다. 이렇게 하면 LLM이 실제 문서에 기반해서 답변하므로 정확성이 크게 향상됩니다. 또한 출처를 명시할 수도 있습니다. "인사규정 3.2조에 따르면..."처럼요. **Knowledge Base의 구조** Bedrock Knowledge Base는 이렇게 구성됩니다. 먼저 문서를 **S3 버킷**에 업로드합니다. PDF, Word, TXT 같은 다양한 형식을 지원합니다. 그다음 문서를 작은 **청크**(chunk)로 나눕니다. 한 문단이나 몇 문장씩 쪼개는 것입니다. 각 청크를 **임베딩 모델**로 벡터화합니다. 문장의 의미를 숫자 배열로 변환하는 것입니다. 이 벡터들을 **벡터 데이터베이스**에 저장합니다. Bedrock은 OpenSearch Serverless나 Aurora PostgreSQL을 사용합니다. **벡터 검색의 작동 원리** 사용자가 질문하면 그 질문도 벡터로 변환됩니다. 그다음 벡터 데이터베이스에서 질문 벡터와 **가장 가까운** 문서 벡터들을 찾습니다. 이것이 의미상 가장 관련 있는 문서입니다. 수학적으로는 코사인 유사도를 계산합니다. 예를 들어 "육아휴직 기간은?"이라고 물어보면, "육아휴직", "출산휴가", "양육 지원" 관련 청크들이 높은 점수로 검색됩니다. 키워드가 정확히 일치하지 않아도 의미가 비슷하면 찾아냅니다. **코드 분석** 위의 코드를 살펴보겠습니다. associate_agent_knowledge_base 함수로 Knowledge Base를 에이전트에 연결합니다. knowledgeBaseId는 미리 만들어둔 Knowledge Base의 ID입니다. knowledgeBaseState를 ENABLED로 설정하면 에이전트가 이 Knowledge Base를 사용할 수 있습니다. 중요한 부분은 instruction 업데이트입니다. "반드시 Knowledge Base를 먼저 검색하세요"라고 명시했습니다. 이렇게 하면 에이전트가 추측으로 답하지 않고 문서를 참고합니다. "Knowledge Base에 없는 정보는 '확인이 필요합니다'라고 답하세요"도 중요합니다. 모르는 것을 지어내지 않도록 방지합니다. **실무 활용 사례** 실제 프로젝트에서는 어떻게 활용할까요? 기술 지원 챗봇을 만든다면 제품 매뉴얼, 문제 해결 가이드, FAQ를 Knowledge Base에 넣습니다. 고객이 "와이파이 설정이 안 돼요"라고 하면, 에이전트가 설정 가이드를 검색해서 단계별로 안내합니다. 법률 상담 에이전트라면 판례, 법령, 계약서 양식을 저장합니다. 사용자가 "근로계약서에 뭐가 들어가야 해?"라고 물으면, 근로기준법을 검색해서 필수 항목을 알려줍니다. **Knowledge Base 최적화** 문서를 효과적으로 구성하는 방법이 있습니다. 첫째, 문서를 논리적 단위로 잘 나누어야 합니다. 하나의 긴 문서보다는 주제별로 분리된 여러 문서가 검색에 유리합니다. 둘째, 메타데이터를 활용하세요. 문서에 태그를 달아서 필터링할 수 있습니다. 셋째, 정기적으로 업데이트하세요. 오래된 정보는 삭제하거나 수정해야 합니다. 넷째, 테스트를 자주 하세요. 실제 사용자 질문으로 검색이 잘 되는지 확인해야 합니다. **주의사항** Knowledge Base 사용 시 주의할 점이 있습니다. 초보자들이 자주 하는 실수는 너무 많은 문서를 한꺼번에 넣는 것입니다. 검색 정확도가 떨어질 수 있습니다. 핵심적이고 신뢰할 수 있는 문서만 선별해서 넣으세요. 또한 문서의 품질이 중요합니다. 오타가 많거나 구조가 엉망인 문서는 검색이 잘 안 됩니다. 정제된 문서를 사용하세요. **출처 표시** 에이전트가 답변할 때 출처를 명시하도록 설정할 수 있습니다. instruction에 "답변 끝에 참고한 문서명을 알려주세요"라고 추가하면 됩니다. 그러면 "인사규정.pdf 12페이지에 따르면..."처럼 출처를 밝힙니다. 사용자가 신뢰할 수 있고, 나중에 확인도 가능합니다. **정리** 김개발 씨는 이제 Knowledge Base의 중요성을 깨달았습니다. "아, LLM은 똑똑하지만 우리 회사 정보는 모르니까, 문서를 검색할 수 있게 해주는 거네요!" Knowledge Base를 잘 구축하면 에이전트의 답변 품질이 비약적으로 향상됩니다. 다음 섹션에서는 실제 활용 시나리오를 살펴보겠습니다. **실전 팁** 💡 - Knowledge Base 문서는 주제별로 잘 구조화해서 저장하세요 - instruction에 "반드시 Knowledge Base를 먼저 검색하라"고 명시해서 환각을 방지하세요 - 정기적으로 문서를 업데이트하고 테스트해서 검색 정확도를 유지하세요 --- ## 6. 에이전트_활용_시나리오 김개발 씨는 이제 Bedrock Agents의 모든 구성 요소를 이해했습니다. 하지만 궁금한 게 생겼습니다. "이론은 알겠는데, 실제로 어떤 상황에서 사용하면 좋을까요?" 박시니어 개발자가 노트북을 열었습니다. "실제 사례를 보여드릴게요." Bedrock Agents는 **고객 서비스**, **내부 업무 자동화**, **개인 비서**, **데이터 분석** 등 다양한 시나리오에 활용됩니다. 자연어로 복잡한 요청을 처리하고, 여러 시스템을 오케스트레이션하며, 사용자에게 자연스러운 대화 경험을 제공합니다. 반복적이고 규칙 기반 작업을 자동화하는 데 특히 효과적입니다. 다음 코드를 살펴봅시다. ```python import boto3 import json # 전자상거래 고객 서비스 에이전트 예시 def create_ecommerce_agent(): bedrock = boto3.client('bedrock-agent') # 에이전트 생성 agent = bedrock.create_agent( agentName='ecommerce-customer-service', foundationModel='anthropic.claude-3-sonnet-20240229-v1:0', instruction='''당신은 온라인 쇼핑몰 고객 센터 상담원입니다. 주문 조회, 배송 추적, 반품 처리, 제품 추천을 도와줍니다. 항상 친절하고 공감하는 태도로 응대하세요. 고객의 문제를 신속하게 해결하는 것이 최우선입니다.''', agentResourceRoleArn='arn:aws:iam::123456789012:role/EcommerceAgentRole' ) # Action Groups 추가 # 1. 주문 관리 # 2. 배송 추적 # 3. 반품 처리 # 4. 재고 확인 # Knowledge Base 연결 # - 제품 카탈로그 # - 배송 정책 # - 반품 규정 return agent['agent']['agentId'] ``` 박시니어 개발자가 화면을 공유하며 말했습니다. "실제로 우리 회사에서 사용하는 몇 가지 사례를 보여드릴게요." 김개발 씨는 눈을 반짝이며 화면을 바라봤습니다. **시나리오 1: 고객 서비스 자동화** 가장 흔한 활용 사례는 고객 서비스입니다. 전자상거래 회사를 생각해보세요. 하루에 수백 건의 고객 문의가 들어옵니다. "주문이 언제 도착해?", "반품하고 싶어요", "이 제품 재입고 언제 돼요?" 같은 질문들입니다. 전통적인 챗봇으로는 한계가 있었습니다. 미리 정해진 시나리오대로만 대답할 수 있었기 때문입니다. 하지만 Bedrock Agent를 사용하면 훨씬 자연스럽고 유연하게 대응할 수 있습니다. **고객 서비스 에이전트의 구성** 이런 에이전트는 어떻게 만들까요? 먼저 여러 **Action Groups**를 만듭니다. "주문조회", "배송추적", "반품신청", "재고확인" 같은 기능들입니다. 각 Action은 백엔드 API나 데이터베이스와 연동됩니다. 그다음 **Knowledge Base**를 구축합니다. 제품 정보, 배송 정책, 반품 규정, 자주 묻는 질문을 저장합니다. 에이전트가 정확한 정보를 참고해서 답변할 수 있습니다. 마지막으로 **instruction**을 잘 작성합니다. "항상 친절하게", "고객의 감정에 공감하기", "문제를 신속하게 해결하기" 같은 원칙을 명시합니다. **실제 대화 예시** 고객이 이렇게 말합니다. "지난주에 주문한 운동화가 아직 안 왔는데, 어떻게 된 거예요? 내일 신고 나가야 하는데..." 에이전트는 이렇게 처리합니다. 먼저 "주문조회" Action을 실행해서 고객의 최근 주문을 찾습니다. 그다음 "배송추적" Action으로 현재 배송 상태를 확인합니다. 물류센터에서 지연되고 있다는 것을 발견합니다. 그러면 에이전트가 이렇게 답합니다. "고객님, 불편을 드려 죄송합니다. 확인 결과 물류센터에서 지연이 발생했습니다. 현재 출고 대기 중이며, 내일 오전 중 도착 예정입니다. 혹시 더 급하시다면 가까운 매장에서 당일 수령도 가능합니다. 어떻게 해드릴까요?" **시나리오 2: 내부 업무 자동화** Bedrock Agents는 대외 서비스뿐 아니라 사내 업무에도 활용됩니다. HR 부서를 예로 들어보겠습니다. 직원들이 매일 인사팀에 질문합니다. "연차 며칠 남았어?", "건강검진 예약 어떻게 해?", "경조사비 신청 방법이 뭐야?" 같은 것들입니다. 인사 담당자가 이런 반복적인 질문에 일일이 답하느라 시간을 뺏깁니다. 정작 중요한 전략적 업무는 못 하게 됩니다. **HR 에이전트 구축** 이럴 때 HR 에이전트를 만들면 효과적입니다. Action Groups로 "연차조회", "급여명세서", "건강검진예약", "경조사비신청" 같은 기능을 만듭니다. 각 Action은 인사 시스템 API와 연동됩니다. Knowledge Base에는 인사 규정, 복지 제도 안내서, 각종 신청 양식 작성법을 넣습니다. 에이전트가 정확하게 안내할 수 있습니다. 직원들은 슬랙이나 팀즈에서 에이전트에게 편하게 물어봅니다. 에이전트가 즉시 답하거나 처리해줍니다. 인사 담당자는 복잡한 케이스에만 집중할 수 있습니다. **시나리오 3: 데이터 분석 비서** 경영진이나 데이터 분석가를 위한 에이전트도 유용합니다. CEO가 이렇게 물어봅니다. "이번 분기 매출이 작년 동기 대비 어떻게 변했어? 그리고 어떤 제품이 가장 잘 팔렸어?" 전통적으로는 데이터 분석가에게 요청하고, 분석가가 SQL을 작성하고, 결과를 정리해서 보고서를 만들어야 했습니다. 시간이 오래 걸립니다. **데이터 분석 에이전트** Bedrock Agent는 이 과정을 자동화할 수 있습니다. Action Groups로 "데이터베이스_쿼리", "차트_생성", "보고서_작성" 같은 기능을 만듭니다. "데이터베이스_쿼리" Action은 자연어를 SQL로 변환해서 실행합니다. CEO의 질문을 받으면, 에이전트가 먼저 필요한 데이터를 파악합니다. 그다음 SQL을 생성해서 데이터베이스를 조회합니다. 결과를 분석해서 "이번 분기 매출은 전년 대비 15% 증가했습니다. 가장 많이 팔린 제품은 A입니다" 같은 답을 줍니다. 필요하면 차트를 생성해서 시각화할 수도 있습니다. **시나리오 4: 개인 비서** 개인 생산성 도구로도 활용할 수 있습니다. "오늘 일정 알려줘", "내일 회의 전에 자료 준비해야 하는데 알림 설정해줘", "지난주에 읽은 이메일 중에 계약 관련된 거 찾아줘" 같은 요청을 처리합니다. Action Groups로 "캘린더_조회", "이메일_검색", "리마인더_설정", "문서_요약" 같은 기능을 구현합니다. Knowledge Base에는 개인 메모, 회의록, 참고 자료를 넣습니다. **시나리오 5: 기술 지원 에이전트** 소프트웨어 회사의 기술 지원팀을 위한 에이전트입니다. 고객이 "API 인증이 안 돼요", "데이터베이스 연결 에러가 나요" 같은 기술적 문제를 문의합니다. 에이전트가 문제를 진단하고 해결 방법을 안내합니다. Action Groups로 "로그_조회", "시스템_상태_확인", "설정_검증" 같은 진단 도구를 만듭니다. Knowledge Base에는 문제 해결 가이드, API 문서, 에러 코드 설명을 저장합니다. 에이전트가 먼저 자동 진단을 수행합니다. 간단한 문제는 바로 해결 방법을 알려줍니다. 복잡한 문제는 엔지니어에게 에스컬레이션하되, 이미 수집한 진단 정보를 함께 전달합니다. **코드 분석** 위의 코드는 전자상거래 에이전트의 기본 골격입니다. create_agent로 에이전트를 만들고, instruction에 고객 서비스 원칙을 명시했습니다. 실제로는 여기에 Action Groups를 추가하고, Knowledge Base를 연결하고, 테스트를 거쳐야 합니다. 각 비즈니스 도메인에 맞게 커스터마이징하면 됩니다. 핵심 패턴은 동일합니다. 자연어 이해 + 작업 수행 + 지식 참조입니다. **선택 기준** 어떤 작업을 에이전트로 만들면 좋을까요? 첫째, 반복적이고 규칙 기반인 작업이 적합합니다. 매번 같은 절차를 따르는 업무입니다. 둘째, 여러 시스템을 오케스트레이션해야 하는 작업입니다. 데이터를 여기저기서 모아서 처리하는 경우입니다. 셋째, 자연어 인터페이스가 유용한 작업입니다. 사용자가 복잡한 UI를 배우기 어려운 경우입니다. 넷째, 24/7 가용성이 필요한 작업입니다. 사람은 쉬어야 하지만 에이전트는 항상 깨어있습니다. **주의사항** 모든 작업이 에이전트에 적합한 것은 아닙니다. 창의적이고 전략적인 의사결정은 여전히 사람이 해야 합니다. 복잡한 협상이나 감정적 공감이 중요한 상황도 마찬가지입니다. 법적 책임이 큰 의사결정도 신중해야 합니다. 에이전트는 사람을 대체하는 것이 아니라 보조하는 도구입니다. 반복적이고 시간이 오래 걸리는 작업을 자동화해서, 사람이 더 가치 있는 일에 집중할 수 있게 합니다. **정리** 김개발 씨는 이제 확신을 가지게 되었습니다. "우리 회사에도 적용할 수 있는 게 정말 많네요!" Bedrock Agents는 고객 서비스부터 내부 업무 자동화까지 폭넓게 활용됩니다. 여러분의 비즈니스에 맞는 시나리오를 찾아서 구현해보세요. **실전 팁** 💡 - 반복적이고 규칙 기반인 업무부터 시작하세요. 성공 확률이 높습니다 - 파일럿 프로젝트로 작게 시작해서 점진적으로 확장하세요 - 사용자 피드백을 지속적으로 수집해서 에이전트를 개선하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, BedrockAgents, AIAgent, ActionGroups, KnowledgeBase

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

Bedrock Agents 완벽 입문 가이드

목차

1. AI 에이전트란 무엇인가

2. Bedrock Agents 아키텍처

3. 에이전트 구성 요소

4. Action Groups 개념

5. Knowledge Base 연동

6. 에이전트 활용 시나리오

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드