Day 1 - Amazon Bedrock: 파운데이션 모델을 빌려 쓰는 완전관리형 서비스

Amazon Bedrock이란 무엇인가

Week 3 에서 생성형 AI 의 원리, 파운데이션 모델(FM), 프롬프트 엔지니어링, RAG 의 개념을 배웠다. 이번 주는 그것을 "AWS 에서 실제로 어떻게 쓰느냐"로 넘어간다. 가장 비중이 큰 도메인 3 "파운데이션 모델 응용"(28%)과 직결되는 주이고, 시험 문제의 상당수가 "이 시나리오에는 어떤 AWS AI 서비스가 적합한가?"를 묻는다. 그 중심에 Amazon Bedrock 이 있다.

Bedrock 의 핵심 가치는 한 문장으로 요약된다. "GPU 를 사거나 모델을 직접 호스팅하지 않고, API 호출만으로 거대 파운데이션 모델을 쓴다." 인프라 관리가 전혀 필요 없는 서버리스(serverless) 방식이다.

Bedrock 은 여러 제공사의 모델을 한곳에 모아둔 "FM 마켓플레이스"다.

• 제공사와 모델 목록은 계속 늘고 바뀐다. 시험은 특정 모델의 이름이나 순위가 아니라 "텍스트 생성·이미지 생성·임베딩 중 무엇이 필요한가"를 묻는다.
• Amazon 자체 모델군인 Amazon Nova 는 시험 가이드의 범위 내 서비스 목록에 올라 있다.

💡 관련 이론: Bedrock 은 "Infrastructure as API"의 생성형 AI 버전이다. 전통적으로 거대 모델을 운영하려면 수천 개 GPU 와 운영 인력이 필요했다. Bedrock 은 이 모든 것을 추상화해, 개발자는 "어떤 모델에 어떤 프롬프트를 보낼까"만 신경 쓰면 된다. 시험에서 "인프라 관리 없이 여러 FM 을 골라 쓰고 싶다"는 시나리오가 나오면 Bedrock 이 정답이다.

흔한 오해 두 가지.

• "Bedrock 에 보낸 프롬프트로 모델 제공사가 모델을 학습시킨다" → 아니다. AWS 문서에 따르면 모델은 Bedrock 서비스 팀이 운영하는 계정에 복사되어 배포되고, 모델 제공사는 그 계정에 접근할 수 없어 고객의 프롬프트와 응답을 볼 수 없다.
• "Bedrock 을 쓰면 보안은 AWS 가 다 책임진다" → 아니다. 인프라는 AWS 가, 누가 호출할 수 있는지(IAM)와 무엇을 입력하는지는 고객이 책임진다(책임 공유 모델).

모델을 어떻게 고르는가

여러 모델 중 하나를 고르는 기준은 단순한 "성능 순위"가 아니다. AIF 시험은 트레이드오프를 묻는다.

• 정확도/추론 능력: 복잡한 추론, 코드 생성, 긴 문맥이 필요하면 고성능 모델(예: 큰 Claude 모델).
• 비용: 토큰당 가격이 모델마다 다르다. 단순 분류·요약이면 저렴한 경량 모델로 충분하다.
• 지연 시간(latency): 실시간 챗봇은 빠른 응답이 중요하므로 경량 모델이 유리할 수 있다.
• 모달리티(modality): 텍스트만? 이미지 생성? 멀티모달(이미지 이해)? 임베딩? 작업에 맞는 종류를 골라야 한다.
• 컨텍스트 윈도우: 긴 문서를 한 번에 넣어야 하면 큰 컨텍스트 윈도우 모델.

시험 가이드는 여기에 다국어 지원, 모델 크기·복잡도, 커스터마이징 가능 여부, 규정 준수, 프롬프트 캐싱 지원을 선택 기준으로 더한다. 후보를 감이 아니라 근거로 고르려면 Amazon Bedrock 모델 평가(Model Evaluation) 를 쓴다.

가상의 사례로, 한 고객지원 팀은 처음에 모든 문의를 최고 성능 모델로 처리하다 비용이 폭증했다. 분석해 보니 80%의 문의는 단순 FAQ 였다. 이들을 저렴한 경량 모델로 라우팅하고, 복잡한 문의만 고성능 모델로 보내자 비용이 60% 줄면서 품질은 유지됐다. "가장 비싼 모델이 최선은 아니다"가 핵심 교훈이다.

RAG와 Knowledge Bases: 모델에 우리 회사 데이터 붙이기

파운데이션 모델은 학습 시점까지의 일반 지식만 안다. "우리 회사 내부 규정"이나 "최신 제품 매뉴얼"은 모른다. 이를 해결하는 것이 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 다.

RAG 의 흐름은 이렇다.

사용자 질문 → 회사 문서 DB에서 관련 내용 검색 → 검색 결과를 프롬프트에 첨부 → FM이 그 근거로 답변

Bedrock 에는 이 과정을 자동화해주는 Knowledge Bases(지식 베이스) 기능이 있다. 우리가 S3 에 문서를 올려두면 Bedrock 이 알아서 문서를 잘게 쪼개(chunking) 임베딩으로 바꾸고, 벡터 데이터베이스에 저장한다. 사용자가 질문하면 의미가 비슷한 조각을 찾아 모델에 함께 넘긴다.

일은 두 시점에 나뉘어 일어난다.

• 답에 인용(citation) 을 붙일 수 있어 사용자가 원문을 확인할 수 있다. "출처를 밝혀야 한다"는 요구가 RAG 로 풀리는 이유다.
• 데이터 소스는 S3 만이 아니다. 관리형 지식 베이스는 SharePoint, Confluence, Google Drive, OneDrive, 웹 크롤러 커넥터를 제공한다.
• 지식 베이스는 두 종류다. Bedrock 이 수집·색인·저장·검색 인프라를 모두 맡는 관리형과, 벡터 저장소(OpenSearch Serverless, Aurora, Neptune 등)를 직접 꾸리고 설정을 통제하는 고객 관리형이다. "운영 부담 최소"면 앞쪽, "저장소와 파이프라인을 직접 통제"면 뒤쪽이다.
• 문서가 바뀌었는데 다시 동기화하지 않으면 챗봇은 옛 내용으로 답한다. RAG 는 모델 재학습은 없애 주지만 색인 갱신은 남는다.

💡 관련 이론: RAG 는 파인튜닝과 자주 비교된다. 파인튜닝은 모델 자체를 추가 학습시켜 "능력/말투"를 바꾸는 것이고, RAG 는 모델은 그대로 두고 "최신 지식/사실"을 외부에서 가져다 붙이는 것이다. 자주 바뀌는 사내 데이터, 출처를 명확히 해야 하는 경우, 환각(hallucination)을 줄이고 싶을 때는 RAG 가 유리하다. 시험에서 "최신 정보로 답하게 하고 싶은데 모델을 매번 재학습하긴 부담스럽다"면 RAG/Knowledge Bases 가 정답이다.

Guardrails: 안전 울타리 치기

생성형 AI 를 실제 서비스에 붙이면 위험이 따른다. 욕설, 폭력적 콘텐츠, 경쟁사 언급, 개인정보 노출, 엉뚱한 주제로의 일탈 등이다. Amazon Bedrock Guardrails 는 이런 입출력을 걸러주는 안전장치다.

Guardrails 가 막아주는 것들:

• 핵심은 Guardrails 가 모델과 독립적이라는 점이다. 한 번 정의한 가드레일을 여러 모델에 일관되게 적용할 수 있다. ApplyGuardrail API 로는 모델을 호출하지 않고 가드레일만 따로 적용할 수도 있다.
• 검사는 양방향이다. 사용자 입력에도, 모델 응답에도 건다. 탈옥 시도는 입력에서, 개인정보 유출은 출력에서 잡는다.
• "프롬프트에 '욕하지 마'라고 쓰면 되지 않나?" → 프롬프트 지시는 모델이 어길 수 있는 부탁이고, 가드레일은 모델 밖에서 강제하는 검사다. 시험이 "일관되게", "모든 모델에"를 붙이면 가드레일이다.

에이전트: 모델이 직접 작업을 수행하게 하기

기본 FM 은 "글을 생성"할 뿐, 실제 행동(주문 조회, 예약 변경)은 못 한다. Amazon Bedrock Agents 는 모델이 여러 단계로 추론하면서 외부 API(Lambda 등)나 Knowledge Base 를 호출해 실제 작업을 완수하게 해준다.

예를 들어 "내 항공편을 내일로 변경해줘"라는 요청에 Agent 는 (1) 사용자의 예약 조회 API 호출 → (2) 변경 가능 여부 확인 → (3) 변경 API 호출 → (4) 결과를 자연어로 안내, 이런 다단계 작업을 스스로 계획하고 실행한다.

Agent 는 "추론(reasoning) + 도구 사용(tool use)"을 결합한 구조다. 모델이 "지금 무엇을 해야 하는지" 판단하고, 필요한 도구(API)를 골라 호출하고, 그 결과를 보고 다음 행동을 결정한다. Knowledge Bases 가 "읽기(검색)"라면 Agents 는 "행동(실행)"까지 한다. 시험에서 "모델이 단순 답변을 넘어 여러 단계로 실제 업무를 수행해야 한다"면 Agents 가 정답이다.

이름이 바뀌는 중이라는 점을 알아 둔다.

• 기존 Bedrock Agents 는 현재 Amazon Bedrock Agents Classic 으로 불리며 신규 고객에게는 열려 있지 않다. AWS 는 후속으로 Amazon Bedrock AgentCore 를 안내한다.
• AgentCore 는 에이전트를 만들고 배포하고 운영하는 플랫폼이다. 어떤 프레임워크(예: 오픈소스 Strands Agents)와 어떤 모델로 만든 에이전트든 올릴 수 있고, 실행 환경(Runtime), 기억(Memory), 도구 연결(Gateway), 신원·권한(Identity), 정책(Policy), 관측(Observability) 같은 부품을 제공한다.
• Gateway 는 기존 API 와 Lambda 함수를 MCP(Model Context Protocol) 호환 도구로 바꿔 준다. MCP 는 에이전트와 외부 시스템을 잇는 표준 규약이다.
• 최신 시험 가이드는 AgentCore 와 Strands Agents 를 범위 내 서비스로 든다. 보기에 어느 이름이 나오든 "여러 단계 + 도구 호출 + 실제 행동"이면 에이전트 계열이다.

닮은 기능 구분하기

셋을 함께 쓰는 경우가 흔하다. 여행사 챗봇이라면 환불 규정은 Knowledge Bases 로 읽고, 예약 변경은 에이전트가 API 로 실행하고, 그 대화 전체에 Guardrails 가 걸린다.

커스터마이징은 Bedrock 안에서 모델 자체를 바꾸는 방법이다.

• 파인튜닝: 레이블이 붙은 입력-출력 예시로 추가 학습해 특정 작업 성능을 올린다.
• 증류(distillation): 크고 똑똑한 교사 모델의 답으로 작고 빠른 학생 모델을 학습시킨다. 품질을 최대한 지키면서 비용과 지연을 낮추려는 목적이다.
• 시험 가이드는 여기에 레이블 없는 도메인 문서로 계속 학습시키는 지속 사전학습(continuous pre-training, Bedrock 문서 표기는 continued pre-training)도 함께 든다.

비용이 드는 지점

• 커스터마이징한 모델은 프로비저닝 처리량을 구매해야 쓸 수 있다고 사용자 가이드가 안내한다. 파인튜닝은 학습비로 끝나지 않고 쓰는 동안 계속 비용이 든다는 뜻이다.
• 프로비저닝 처리량은 쓰지 않아도 삭제할 때까지 시간당 과금된다.
• RAG 는 검색해 붙인 문서만큼 입력 토큰이 늘고, 에이전트는 한 요청에 모델을 여러 번 부르므로 단순 호출보다 비싸다. 가드레일 검사도 별도 과금 항목이다.

시나리오 → 정답 판별표

내일은 Bedrock 과 짝을 이루는 Amazon SageMaker, 곧 "직접 ML 모델을 학습하고 배포하는" 서비스를 보고 언제 Bedrock 이고 언제 SageMaker 인지를 구분한다.

📖 용어

• 완전관리형(fully managed) : 서버 준비·확장·패치를 서비스가 맡아 사용자는 기능만 쓰는 방식.
• 모달리티 : 모델이 다루는 데이터 종류. 텍스트, 이미지, 음성, 임베딩 등.
• 청킹(chunking) : 긴 문서를 검색하기 좋은 크기의 조각으로 나누는 일.
• Knowledge Bases : 문서 수집·임베딩·저장·검색을 대신 해 주는 Bedrock 의 관리형 RAG 기능.
• Guardrails : 모델 입출력을 정책에 따라 검사해 차단·마스킹하는 안전장치. 모델과 별개로 정의한다.
• 에이전트 : 모델이 스스로 단계를 계획하고 도구(API)를 호출해 작업을 끝내는 구성.
• MCP(Model Context Protocol) : 에이전트가 외부 도구·데이터에 연결하는 방식을 맞춘 표준 규약.
• 증류(distillation) : 큰 교사 모델의 답으로 작은 학생 모델을 가르쳐 싸고 빠른 모델을 얻는 방법.
• 프로비저닝 처리량 : 일정한 처리량을 시간 단위 요금으로 미리 확보해 두는 구매 방식.
• 프롬프트 캐싱 : 반복되는 프롬프트 앞부분을 저장해 두고 다시 쓸 때 비용과 지연을 줄이는 기능.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 스타트업이 여러 회사의 파운데이션 모델(Claude, Llama, Titan 등)을 직접 GPU를 구매하거나 호스팅하지 않고 단일 API로 호출하려 한다. 가장 적합한 서비스는?

• AAmazon EC2에 각 모델을 직접 설치
• BAmazon Bedrock
• CAmazon S3
• DAWS Glue

문제 2

회사 내부 문서를 기반으로 챗봇이 최신 정보로 답하게 하고 싶지만, 모델 자체를 매번 재학습하는 비용은 피하고 싶다. 가장 적합한 접근은?

• ABedrock Guardrails 설정
• BBedrock Knowledge Bases를 이용한 RAG
• C모델을 처음부터 새로 학습
• D모델 파라미터를 수동으로 편집

문제 3

생성형 AI 챗봇이 욕설, 경쟁사 언급, 개인정보 노출을 하지 못하도록 입출력을 일관되게 필터링하려 한다. Bedrock의 어떤 기능을 써야 하는가?

• AKnowledge Bases
• BAgents
• CGuardrails
• DJumpStart

문제 4

"내 주문 상태를 조회하고, 가능하면 배송지를 변경해줘" 같은 요청을 받아 모델이 스스로 여러 단계로 외부 API를 호출해 실제 작업을 완수하게 하려 한다. 적합한 기능은?

• ABedrock Agents
• BBedrock Guardrails
• C단순 텍스트 생성 호출
• DAmazon Polly

문제 5

Bedrock에서 모델을 선택할 때 고려해야 할 기준으로 가장 거리가 먼 것은?

• A작업에 필요한 정확도와 추론 능력
• B토큰당 비용과 응답 지연 시간
• C텍스트·이미지·임베딩 등 필요한 모달리티
• D모델을 직접 학습시킨 GPU의 물리적 위치