TIL
오늘은 Developing Generative AI Applications on AWS 강의 2일차였다. 어제 기본 개념과 프롬프트 엔지니어링, RAG까지 다뤘다면, 오늘은 LLM 평가 방법론부터 책임감 있는 AI, 에이전트 시스템까지 훨씬 심화된 내용을 배웠다. 특히 Strands Agents나 MCP 같은 최신 기술들이 실제로 어떻게 동작하는지 보니까 "AI 에이전트 시대가 진짜 오고 있구나"가 체감됐다.
모듈 7: 생성형 AI 애플리케이션 구성 요소 평가
LLM 선택 3단계
모델을 고를 때 무작정 최신 모델을 쓰는 게 아니라 체계적인 과정을 거쳐야 한다.
1단계: 빠르게 후보 간추리기
온라인 쇼핑할 때처럼 모든 모델을 다 테스트할 수는 없다. 독점 모델(GPT-4, Claude)과 오픈 소스(Llama, Mistral) 중에서 실제 사용 사례가 반영된 테스트 프롬프트를 10개 정도 모델에 넣어보고, 후보를 3개로 좁힌다.
2단계: 사례 기반 벤치마킹
3개 모델을 대상으로 더 엄격한 평가를 진행한다. 다양한 시나리오가 반영된 벤치마크 프롬프트를 만들어서 각 모델이 여러 문제를 처리하는 방식을 비교한다.
3단계: 우선 순위 기반 모델 선택
기술적으로 최고인 모델이 항상 최적은 아니다. 3가지 핵심 요소를 고려해야 한다.
- 품질 요구 사항 충족 여부
- 비용을 계속 충당할 수 있는지
- 사용자에게 응답을 충분히 빠르게 제공하는지
예를 들어 우선 순위가 비용 > 품질 > 속도인 스타트업이라면, 품질이 최고는 아니더라도 최저 비용에 적정 품질 + 빠른 속도를 제공하는 모델이 가장 적합할 수 있다.
품질 평가 — LLM 평가 vs RAG 평가
| 구분 | LLM 평가 | RAG 평가 |
|---|---|---|
| 범위 | 추론, 지식 재현, 언어 이해 등 일반 태스크 | 검색 + 생성 통합 성능 |
| 테스트 대상 | 모델 자체 (훈련 상태, 파라미터) | 전체 파이프라인 (검색, 지식 기반, 통합) |
| 복잡성 | 단일 모델 출력 평가로 비교적 간단 | 검색/순위/생성 여러 단계에서 장애 가능 |
| 지표 | BLEU, 벤치마크 정확도, 복잡성 | 정밀도, 재현율, 관련성 점수, 충실도 |
Amazon Bedrock 모델 평가 3가지 방식
- 프로그래밍 방식 평가 — BERTScore, F1 점수 등 객관적 자동 측정. 재현 가능하고 일관된 점수 제공
- 인적 평가 — 좋아요/싫어요, 5점 척도, 선호도 순위 등 사람이 판단. 기술적으로 정확하지만 로봇 같은 응답을 걸러낼 수 있음
- LLM으로 판단 — 다른 LLM이 출력을 평가하는 메타 방식. 인간 전문 평가자와 함께 활용하면 효율적이며 연중무휴 대량 처리 가능
RAG 평가 — 검색과 생성을 분리해서 봐야 한다
RAG 시스템은 2가지 작업이 수행된다.
1. 검색 문제: 지식 기반에서 적절한 문서를 못 찾거나, 관련 없는 정보를 끌어와 모델을 혼동시킬 수 있다
2. 생성 문제: 필요한 컨텍스트가 다 검색됐어도 모델이 컨텍스트를 무시하거나 잘못 해석하거나 할루시네이션을 생성할 수 있다
기존 LLM 평가로는 이 두 문제를 구분할 수 없기 때문에 RAG 전용 평가가 필요하다.
Ragas(Retrieval-Augmented Generation Assessment)
RAG 시스템 전용 평가 프레임워크다. Amazon Bedrock 네이티브 평가 기능과 별개로, 사용자 지정 평가 워크플로나 오픈 소스 통합이 필요할 때 사용한다.
평가 샘플 구성 요소:
- 사용자 입력 — 실제 질문
- 검색된 컨텍스트 — 지식 기반에서 가져온 문서/청크
- 응답 — 시스템이 생성한 최종 답변
- 참조 — 비교용 표준 답변
from ragas import SingleTurnSample, EvaluationDataset
sample1 = SingleTurnSample(
user_input="독일의 수도는 무엇인가요?",
retrieved_contexts=["베를린은 독일의 수도이자 최대 도시입니다."],
response="독일의 수도는 베를린입니다.",
reference="베를린",
)
dataset = EvaluationDataset(samples=[sample1])검색 평가 지표
| 지표 | 설명 | 쉽게 말하면 |
|---|---|---|
| 컨텍스트 정밀도 | 검색된 문서가 질문과 관련 있는지 | "검색해온 문서 5개 중 쓸모있는 게 몇 개야?" |
| 컨텍스트 재현율 | 모든 관련 정보를 찾았는지 | "정답에 필요한 정보가 검색 결과에 다 있어?" |
| 컨텍스트 엔터티 재현 | 구체적 엔터티(사람, 장소 등)가 포함됐는지 | "정답에 나오는 고유명사가 검색 결과에 있어?" |
생성 평가 지표
| 지표 | 설명 |
|---|---|
| 노이즈 민감도 | 관련 없는 정보를 적절히 제거하는지 |
| 응답 관련성 | 질문에 직접적으로 답변하는지 |
| 충실도 | 제공된 컨텍스트를 기반으로 답변하는지 (할루시네이션 방지) |
지능형 프롬프트 라우팅
Amazon Bedrock에서 제공하는 기능으로, 모든 요청에 비싼 모델을 쓸 필요 없이 태스크 난이도에 따라 자동으로 최적 모델을 선택해준다.
동작 흐름:
1. 프롬프트 전송
2. Amazon Bedrock이 태스크에 필요한 능력 수준 분석
3. 품질 대비 비용 가중치 계산 → 최적 모델 선택
4. 해당 모델로 프롬프트 전송 및 응답 반환
쉽게 말하면, 수임료가 높은 컨설턴트가 필요한 상황과 신참 분석가도 처리할 수 있는 상황을 구분해주는 개인 비서 같은 역할이다.
지연 시간에 최적화된 추론
성능 지표:
- TTFT(Time to First Token) — 첫 번째 토큰까지 걸리는 시간
- OTPS(Output Tokens Per Second) — 초당 출력 토큰 수
- E2E(End-to-End latency) — 전체 지연 시간
채팅 앱, 라이브 코딩 도우미, 대화형 데모 같은 실시간 애플리케이션에서 유용하다. 구성 하나만 변경해도 응답 성능을 대폭 높일 수 있다.
모듈 8: 책임감 있는 AI 구현
책임감 있는 AI의 6가지 차원
| 차원 | 설명 | AWS 구현 방법 |
|---|---|---|
| 제어 가능성 | AI 동작을 모니터링하고 조종 | Bedrock Guardrails, CloudWatch, SageMaker HITL 워크플로 |
| 개인 정보 보호 및 보안 | 데이터를 적절하게 획득/사용/보호 | KMS 암호화, VPC 엔드포인트, Amazon Macie PII 탐지 |
| 안전 | 위험한 상황 발생 방지 | Comprehend 유해성 탐지, 다층 검증, Bedrock 안전 분류기 |
| 공정성 | 다양한 사용자 소집단에 편향 없이 | SageMaker Clarify 편향 탐지, 균형 잡힌 평가 데이터셋 |
| 진실성 및 견고성 | 정확한 사실 기반 응답 | RAG(Amazon Kendra), 신뢰도 채점, 적대적 테스트 |
| 설명 가능성 | 결정에 대한 명확한 근거 제공 | SHAP 값, CoT 프롬프트, CloudTrail 감사 추적 |
프롬프트 엔지니어링으로 인한 편향
편향은 훈련 데이터뿐만 아니라 프롬프트 자체에서도 발생할 수 있다.
- 훈련 데이터 편향: 특정 집단의 데이터가 과대 대표되는 경우
- 프롬프트 편향: 특정 문화/지역에 치우친 용어를 사용하는 경우
- 편향 증폭: 훈련 데이터 편향 + 프롬프트 편향이 합쳐져 결과가 더 왜곡되는 경우
예시: "해안 지방 여행 시 숙박하기 적합한 모텔을 추천해 줘"라는 프롬프트에서 '모텔'이라는 용어는 미국에서 흔히 사용되지만 다른 국가에서는 빈도가 낮다. 이로 인해 미국 내 숙박업체 중심의 결과가 나올 수 있다.
프롬프트 오용 방지를 위한 보안 조치
| 보안 조치 | 설명 |
|---|---|
| 입력 검증 | Base64, 난독 처리 등 인코딩된 입력도 디코딩 후 검사 |
| 안전한 프롬프트 설계 | 민감 정보를 템플릿에 하드코딩하지 않고 Parameter Store/Secrets Manager 사용 |
| 액세스 제어 | 최소 권한 원칙, 세션 분리로 공격 범위 제한 |
| 모니터링 및 탐지 | 모든 AI 상호 작용 기록, CloudWatch 알림, 출력 모니터링 |
Amazon Bedrock Guardrails
생성형 AI 애플리케이션용 구성 가능한 보안 조치를 제공한다.
4단계 필터링 메커니즘:
1. 사용자 입력 처리 — 콘텐츠/단어 필터로 유해 콘텐츠, 욕설 차단
2. FM 처리 — 여러 FM에 일관된 안전/개인정보 제어 적용
3. 출력 안전성 검사 — 키워드 식별, 정규식, 자동 추론, 헌법적 AI 등으로 부적절한 콘텐츠 식별
4. 최종 응답 제공 — 필터링/검증된 응답을 사용자에게 전달
주요 기능:
- AI 안전 상태 일관성 유지 (모든 FM에 동일한 안전 제어)
- 부적절한 주제 차단 (자연어로 제한 주제 정의)
- 유해 콘텐츠 필터링 (혐오, 모욕, 성적, 폭력, 위법, 프롬프트 공격 6개 카테고리)
- PII 수정 (개인 식별 정보 자동 탐지 및 제거)
자동 추론 검사(Automated Reasoning checks)
수학적, 로직 기반 검증을 사용해서 할루시네이션을 방지한다. 모델이 생성하는 정보가 제공된 사실을 근거로 생성되었는지 검증하는 방식이다. 프롬프트 엔지니어링, RAG, 컨텍스트 근거검사와 함께 사용하면 더 철저한 정확도를 확보할 수 있다.
예제: 애플리케이션 아키텍처
전체 흐름:
사용자 → API Gateway → Lambda → 입력 가드레일 → FM → 출력 가드레일 → 사용자
↕
CloudWatch (모니터링)- 프론트엔드: 데모 웹 사이트 호스팅, 사용자 입력 캡처
- 백엔드: Lambda(프롬프트 템플릿 + 로직) + API Gateway(HTTP 라우팅, 스키마 검증, 캐싱)
- AI 안전 계층: 입력 가드레일 → FM 응답 생성 → 출력 가드레일
- 보안: IAM 역할 기반 액세스 제어, CloudWatch 모니터링/로깅
모듈 9: 생성형 AI 애플리케이션의 도구 및 에이전트 사용
함수 호출(Function Calling)
AI 모델 자체는 함수를 직접 실행하거나 외부 시스템과 상호 작용할 수 없다. 그래서 함수 호출(도구 사용) 방식을 사용한다.
동작 흐름:
1. 사용자가 클라이언트 앱에 요청 전송
2. 클라이언트가 사용자 입력 + 사용 가능한 도구 설명을 LLM에 전송
3. 모델이 호출할 함수와 파라미터를 구조화된 텍스트(JSON)로 출력
4. 클라이언트가 해당 명령을 해석하고 함수 실행 (DB 쿼리, API 호출, 웹 검색 등)
5. 결과가 클라이언트에 반환
6. 대화 + 결과를 다시 모델에 전송
7. 모델이 최종 답변을 작성할 때까지 이 주기 반복
8. 최종 응답을 사용자에게 전달
핵심은 모델은 "이 함수를 이 파라미터로 호출해줘"라고 지시만 하고, 실제 실행은 클라이언트 애플리케이션이 한다는 것이다.
일반적인 도구 유형
| 카테고리 | 도구 | 설명 |
|---|---|---|
| RAG 및 메모리 | retrieve, memory, mem0_memory | 지식 기반 검색, 대화 기록 보존 |
| 파일 작업 | editor, file_read, file_write | 파일 편집/읽기/쓰기 |
| 쉘 및 시스템 | environment, shell, cron | 환경 변수, 명령 실행, 태스크 예약 |
| Code Interpreter | python_repl | Python 코드 실행 |
| 웹 및 네트워크 | http_request, slack | API 호출, Slack 통합 |
| 유틸리티 | calculator, current_time, load_tool | 수학 연산, 시간 조회, 동적 도구 로드 |
Nova Act
Amazon Nova Act는 웹 브라우저 내에서 자연어 명령으로 브라우저 자동화 태스크를 수행하도록 훈련된 AI 모델이다.
주요 특징:
- 복잡한 워크플로를 원자성 명령(검색, 결제, 화면 질문 답변)으로 분할
- Python SDK를 통해 웹 브라우저 작업 자동화
- 여러 브라우저 세션 동시 실행 (병렬 처리)
- 스크립트 모드 + 대화형 모드 지원
- Playwright API를 통한 민감 정보 특수 처리
- 브라우저 세션 동영상 녹화, HTML 작업 추적 등 포괄적 로깅
Alexa+에 통합되어 있으며, 양식 제출, 일정 관리, 이메일 설정 등 다단계 브라우저 태스크를 자동화할 수 있다.
Strands Agents
코드 몇 줄만으로 모델 기반 에이전트를 구축할 수 있는 오픈 소스 SDK다. Amazon Q Developer, AWS Glue, Amazon VPC Reachability Analyzer 등 AWS 내부 팀이 프로덕션에서 실제로 사용하고 있다.
에이전트 구축 시 정의할 3가지:
- 모델: Amazon Bedrock, Anthropic, Ollama 등
- 도구: MCP 서버, 사전 구축된 Strands 도구, 또는 모든 Python 함수
- 프롬프트: 태스크를 설명하는 자연어
에이전틱 루프:
프롬프트 → 에이전트 → 모델 호출 → 추론 + 도구 선택 → 도구 실행 → 결과 반환 → (반복) → 최종 응답
from strands_tools import python_repl
from strands import Agent, tool
from strands.models import BedrockModel
system_prompt = "< 에이전트를 위한 지침 >"
model = BedrockModel(model_id="<model id>")
agent = Agent(tools=[python_repl], system_prompt=system_prompt, model=model)
response = agent("< 사용자 프롬프트 >")최신 LLM은 추론과 도구 사용이 대폭 개선되어서 복잡한 오케스트레이션 프레임워크 없이도 에이전트를 구축할 수 있다. AWS 내부 팀들이 Strands를 사용해서 프로토타입 → 프로덕션 배포 시간을 몇 달에서 며칠로 단축했다고 한다.
LangChain vs LangGraph
| 구분 | LangChain | LangGraph |
|---|---|---|
| 용도 | 단순한 체인 및 검색 흐름 | 복잡한 에이전틱 워크플로 |
| 실행 모델 | 기본적인 선형 실행 | 루프, 이전 상태 재확인 가능 |
| 주요 구성 요소 | 체인, 메모리, 프롬프트, LLM, 에이전트, 도구 | 노드, 엣지, 상태, 그래프 구조, HITL |
| 적합한 경우 | 간단한 파이프라인 | 스테이트풀 오케스트레이션, 대화형 시스템 |
Model Context Protocol (MCP)
AI 애플리케이션이 외부 시스템, 데이터 소스, 도구와 안전하게 연결하는 표준화된 방식이다. AI 모델이 훈련 데이터 이외의 정보에 액세스하고 작업을 수행할 수 있는 범용 어댑터라고 보면 된다.
MCP 등장 전에는 모든 AI 앱에서 사용자 지정 코드로 각 서비스에 연결해야 했다. 데이터베이스, 파일 시스템, API마다 다른 통합이 필요했고, 같은 연결을 여러 번 재구축해야 했다.
서버-클라이언트 모델:
- 서버: 리소스(데이터, 파일)와 도구(함수, 명령)를 노출
- 클라이언트(AI 앱): 표준 프로토콜을 통해 서버에 연결
주요 특성:
- 표준화된 서버-클라이언트 아키텍처
- 리소스 및 도구 추상화 (통합 인터페이스)
- 플랫폼 무관 (다양한 언어/스택에서 동작)
- 확장 가능한 설계
MCP 도구 모음: smithery.ai
에이전트 간 MCP 패턴
에이전트와 도구, 리소스, 다른 에이전트 간 통신에 MCP를 사용할 수 있다.
예시: HR 에이전트 → 직원 정보 에이전트(MCP 서버로 구현) → 직원 데이터 도구(또 다른 MCP 서버)
이렇게 MCP를 통해 에이전트 간 계층적 통신이 가능하다.
A2A(Agent To Agent) 프로토콜
기본 프레임워크나 공급업체에 관계없이 에이전트가 상호 협업하기 위한 개방형 프로토콜이다.
- 표준화된 JSON-RPC 메시지를 사용하여 HTTPS를 통해 통신
- 에이전트 카드: 신원 정보, 기능, 기술, 엔드포인트 URL, 인증 요구 사항이 포함된 명함 역할
- 메시지는 텍스트, 파일, JSON 등 다양한 콘텐츠 전달 가능
A2A를 쓰면 연구 에이전트 → 데이터 분석 에이전트 → 시각화 에이전트 간 자동 협업이 가능해진다. 개발자가 각 상호 작용을 수동으로 관리할 필요가 없다.
모듈 10: Amazon Bedrock 에이전트 개발
Amazon Bedrock Flows
FM을 사용하여 워크플로를 구축할 수 있는 AWS 서비스다. 직관적인 비주얼 빌더로 프롬프트, 에이전트, Knowledge Base, 가드레일을 드래그 앤 드롭으로 연결할 수 있다.
주요 사용 사례:
1. 빠른 프롬프트 적용 — 요약, 코드/테스트 생성
2. SOP 자동화 — 티켓 분류, 가격 설정, 콘텐츠 생성
3. 유동적인 RAG 적용 — 고객 지원 Q&A, 보험금 청구 도우미
코드 없이도 비즈니스 로직을 사용자 지정할 수 있고, API나 AWS CDK로도 Flow를 생성/업데이트할 수 있다. DoWhile 루프도 지원해서 조건 기반 반복 워크플로도 가능하다.
에이전틱 시스템의 4가지 구성 요소
- 에이전트 워크플로: 사용자 대면 경험. ReAct 스타일 추론으로 입력 처리 → 응답 생성. HITL로 사람이 감독/개입 가능
- 에이전트 구성 요소: FM, Knowledge Base, 가드레일, API/도구, 메모리, Flow — 독립적인 모듈식 요소
- 지속적 평가 프레임워크: 테스트 사례, 지표/채점 프롬프트, 심판 FM이 품질 평가. 모든 상호 작용 기록
- 피드백 루프: 로깅 → 벡터/분석 DB → 지표 대시보드 → SME 평가 + 사용자 피드백으로 지속 최적화
Amazon Bedrock Agents
FM, API, 데이터를 추론하여 사용자 요청을 분류하고 태스크를 완료하는 서비스다.
핵심 기능:
- 다양한 FM 지원 (추론/계획 태스크용으로 최적화)
- Action group, 인라인 에이전트, Code Interpreter 등 도구
- 메모리 관리 (세션 상태 + 장기 보존)
- 다중 에이전트 협업
- 엔터프라이즈급 보안 + 가드레일
- 포괄적인 추적/디버깅/관찰성 도구
에이전트 생성 4단계:
1. FM 선택
2. 기본 지침 제공 (자연어)
3. 관련 데이터 소스 선택
4. 사용 가능한 작업 지정
에이전트가 백그라운드에서 모델 추론으로 워크플로를 세분화하고 적절한 API를 호출해서 작업을 실행한다. 프롬프트 엔지니어링, 세션 컨텍스트 관리, 시스템 수동 연결을 직접 할 필요가 없다.
Amazon Bedrock Agents 내부 Flow
클라이언트 앱 → 요청 → Bedrock 에이전트 → 단계별 분해
↓
작업 실행 / Knowledge Base 검색
↓
결과 관찰 → 다음 단계 고려
↓
(반복) → 최종 답변 생성
↓
가드레일 (입력/출력 보호)
↓
응답 → 클라이언트 앱구성 요소: FM, Action group, Knowledge Base, Code Interpreter, 에이전트 메모리
Amazon Bedrock AgentCore
고성능 AI 에이전트를 대규모로 안전하게 배포/운영할 수 있는 서비스다. CrewAI, LangGraph, LlamaIndex, Strands Agents 등 모든 프레임워크와 연동된다.
모듈식 서비스 구성:
| 서비스 | 역할 |
|---|---|
| AgentCore Runtime | 지연 시간 낮은 샌드박스형 서버리스 환경. 세션 분리, 최대 8시간 실행 |
| AgentCore Memory | 세션/장기 메모리 관리. 시맨틱 메모리 전략 |
| AgentCore Identity | 사용자 대신 AWS/서드파티 서비스 접근. OAuth, API 키 인증 |
| AgentCore Policy | Cedar 정책 언어로 세분화된 권한 부여. 실시간 도구 호출 차단 |
| AgentCore Gateway | 기존 API/Lambda를 에이전트 도구로 변환. MCP 통합 |
| AgentCore Observability | 에이전트 실행 단계별 시각화. OpenTelemetry 지원 |
| AgentCore Browser | 관리형 웹 브라우저 인스턴스. 웹 자동화 워크플로 |
| AgentCore Code Interpreter | 격리된 코드 실행 환경 |
| AgentCore Evaluations | 포괄적 품질 평가 |
AgentCore Runtime 주요 이점
- 프레임워크 무관: LangGraph, Strands, CrewAI 등 모든 프레임워크 지원
- 유동적인 모델 선택: Bedrock, Claude, Gemini, OpenAI 등 모든 LLM 연동
- 실행 시간 연장: 실시간 + 장기 실행(최대 8시간) 모두 지원
- 세션 분리: 전용 microVM에서 각 세션 실행. 세션 간 데이터 오염 방지
- 사용량 기반 과금: 실제 CPU 처리에만 요금 부과. I/O 대기 중에는 무과금
- 양방향 스트리밍: WebSocket으로 실시간 대화. 중단/방향 변경 가능
- 100MB 페이로드: 텍스트, 이미지, 오디오, 비디오 등 대규모 데이터 처리
정리
오늘 핵심은 "AI 에이전트는 단순히 모델을 호출하는 게 아니라, 추론-도구 사용-결과 관찰의 루프를 반복하는 시스템" 이라는 것이다.
LLM 평가 부분에서는 단순히 "모델이 좋다/나쁘다"가 아니라 검색과 생성을 분리해서 어디서 문제가 생기는지 진단하는 게 중요하다는 걸 배웠다. Ragas 같은 프레임워크로 체계적으로 평가할 수 있다는 것도 알게 됐다.
책임감 있는 AI 파트에서는 Amazon Bedrock Guardrails가 인상적이었다. 입력 검증 → FM 처리 → 출력 검사 → 최종 응답까지 4단계로 필터링하는 구조가 실제 프로덕션에서 꼭 필요한 안전장치라는 게 느껴졌다. 특히 프롬프트 자체에서도 편향이 발생할 수 있다는 점은 개발자로서 항상 인지하고 있어야 할 부분이다.
에이전트 파트가 가장 흥미로웠다. Strands Agents로 코드 몇 줄이면 에이전트를 만들 수 있고, MCP로 표준화된 방식으로 외부 도구에 연결하고, A2A로 에이전트끼리 자동 협업까지 가능하다. AgentCore는 이런 에이전트들을 프로덕션에 안전하게 배포하기 위한 인프라를 통째로 제공하는 서비스인데, 세션 분리나 사용량 기반 과금 같은 설계가 실용적이다.
어제 배운 기초(Bedrock API, 프롬프트 엔지니어링, RAG) 위에 오늘 평가/안전/에이전트까지 쌓으니까 생성형 AI 애플리케이션의 전체 그림이 그려진다. 다음에는 실제로 Strands Agents나 Bedrock Agents를 써서 뭔가 만들어보고 싶다.
이번 velog는 AWS Kiro를 통해 작성하였다.
