Step 04 / 06 · Fuel & Engine

AI 연료 & 엔진
Data & Infrastructure

두뇌가 먹는 연료(데이터)와 두뇌가 굴러갈 엔진(컴퓨트).
두 영역을 묶은 이유는 한 가지 — 둘 중 하나라도 빠지면 에이전트는 한 발짝도 못 움직입니다.

▶ Speaking Script — David's Read
약 2분 30초 / 임원 보고 1회분
"이번 Summit에서 정리한 그림 한 가지" — 연료와 엔진
OPENING15초

이번 AWS Summit에서 데이터 트랙과 인프라 트랙을 들으면서 깨달은 게 하나 있습니다 … … AI 에이전트가 제대로 일하려면 두 가지가 필요하다는 거예요 … 먹을 연료, 그리고 굴러갈 엔진.

PART 1 · 연료 = 데이터70초

연료 쪽은 AI-Ready Data라는 개념으로 시작합니다. 한 줄로 말하면, "우리 회사 데이터가 LLM이 곧바로 쓸 수 있는 상태인가" 라는 질문입니다.

보통 데이터는 Amazon S3 같은 객체 스토리지에 깔리고요, 그걸 검색 가능하게 만드는 게 Amazon OpenSearch입니다. 그런데 단순 키워드 검색으론 부족하니까, 텍스트를 벡터로 임베딩해서 의미 기반 검색을 합니다 … 이게 바로 RAG—Retrieval-Augmented Generation—의 핵심이에요. 모델이 답하기 전에 회사 데이터에서 관련 문서를 먼저 끌어오는 거죠.

올해의 진화는 GraphRAG입니다. 그냥 문서를 찾는 게 아니라, 문서 사이의 관계까지 그래프로 두고 그 위에서 검색하는 방식입니다. 미래에셋증권이 상품 지식 DB를 GraphRAG로 만든 사례가 대표적이었습니다.

데이터 파이프라인 쪽에선 CDC와 Lakehouse가 두 키워드예요. CDC는 Change Data Capture—운영 DB에서 변경분만 실시간으로 흘려보내는 방식이고요, Lakehouse는 그 데이터를 받아서 분석·AI 학습에 쓰는 통합 저장소입니다. 이 둘이 짝을 이뤄 "실시간 AI-Ready 데이터"를 만드는 거예요.

PART 2 · 엔진 = 인프라70초

이제 엔진 쪽입니다. AI 모델을 실제로 돌리는 실리콘 얘기예요.

크게 두 종류—훈련용 칩과 추론용 칩. AWS는 자체 칩으로 Trainium과 Inferentia를 갖고 있어요. Trainium은 모델 학습 전용, Inferentia는 운영 추론 전용입니다. NVIDIA GPU 의존도를 낮추고 비용을 잡겠다는 전략이죠.

대안으로 NVIDIA GPU를 쓰고 싶으면 EC2 P/G 인스턴스가 있고, 그 모든 컴퓨트를 신뢰성 있게 격리하는 AWS Nitro System이 기반에 깔립니다.

그런데 대규모 학습은 한 대로 안 되니까 클러스터가 필요합니다. HyperPod이 그 답이에요—수백 대 GPU를 한 묶음으로 묶고, 한 대 장애 나도 자동 복구하는 관리형 학습 클러스터. 그 위에 잡 스케줄러로 Slurm이 EKS 위에서 도는 구성이 올해 부각됐습니다. 하이퍼커넥트가 발표한 게 그 사례였어요.

마지막으로 EC2 Capacity Blocks는 GPU를 미리 예약해두는 서비스인데, GPU 품귀 시대에 등장한 안전장치입니다.

CLOSING25초

정리하면 … 데이터는 S3에 깔고, OpenSearch와 RAG·GraphRAG로 검색 가능하게 만들고, CDC와 Lakehouse로 실시간 갱신. 그게 AI 연료.

그걸 Trainium·Inferentia·GPU 위에서 돌리고, HyperPod 클러스터에 묶어 굴리는 게 AI 엔진. 이 둘이 갖춰져야 비로소 두뇌(에이전트)가 일을 할 수 있다 … 이게 핵심이었습니다.

왜 한 단계로 묶나

"AI 연료"와 "AI 엔진"은 분리해서 봐도 되지만, 결정은 같이 내려야 함.

데이터를 RAG로 깔아놓고도 추론 칩이 비싸면 무용지물. 반대로 좋은 GPU를 사놓고도 데이터가 "AI-Ready"가 아니면 텅 빈 라인. 그래서 보통 회사가 AI 도입 의사결정을 내릴 때 데이터와 인프라는 한 묶음으로 봅니다.

A · FUEL — DATA

AI 연료 — 데이터 5종 세트

아래 5개를 알면 데이터 트랙 90%는 해석 가능합니다.

AI-Ready Data · S3 · OpenSearch
기반 3종

데이터 기반 — 저장 + 검색 가능 상태

쉬운말
AI-Ready Data는 "LLM이 곧바로 쓸 수 있는 상태의 데이터"라는 개념이고, 그 상태를 만드는 도구가 S3(저장)와 OpenSearch(검색).
전문어
S3는 객체 스토리지(이미지·문서·로그 무엇이든). OpenSearch는 키워드 검색 + 벡터 검색까지 지원하는 분산 검색엔진. 둘이 묶이면 "회사 모든 데이터를 의미 기반으로 검색"이 가능.
설명 한 줄
데이터는 S3에 다 깔리고, OpenSearch가 벡터 검색까지 해주는 검색층 역할입니다. 이 둘이 AI-Ready 데이터의 기본.
RAG — Retrieval-Augmented Generation
핵심 패턴

RAG — 답하기 전에 회사 자료부터 뒤짐

쉬운말
LLM이 머리에 있는 일반 지식만으로 답하지 않고, 회사 DB에서 관련 문서를 먼저 찾아온 다음 그걸 보고 답하는 방식. 환각(hallucination)을 줄이는 가장 표준적인 처방.
전문어
Retrieval(검색) + Generation(생성). 쿼리를 임베딩 → 벡터 DB에서 유사 문서 검색 → 검색 결과를 컨텍스트로 LLM에 함께 전달. 파인튜닝의 대안 — 모델은 그대로 두고 데이터만 갱신 가능.
설명 한 줄
RAG는 모델이 답하기 전에 회사 데이터에서 관련 문서를 먼저 끌어오는 방식이라, 모델은 그대로 두고 데이터만 갱신해도 답이 최신화됩니다.
David 관점
너의 27-시나리오 JSON DB + facet 기반 retrieval = mini-RAG. 정통 RAG로 발전 = S3 + OpenSearch 벡터 인덱스로 옮기는 것.
GraphRAG
RAG 진화형

GraphRAG — 문서 관계까지 따라가는 검색

쉬운말
단순 RAG가 "비슷한 문서 N개 찾기"라면, GraphRAG는 문서·개념 사이 관계를 그래프로 두고 그 위에서 검색. 인과·종속·계층 관계를 살림.
전문어
Knowledge Graph + RAG. 엔티티 추출 → 관계 그래프 구축 → 쿼리 시 그래프 트래버스 + 벡터 검색 결합. 복잡한 질문에 강함.
설명 한 줄
GraphRAG는 문서 사이 관계까지 그래프로 두고 검색하는 방식이라, "이 상품에 영향 주는 모든 규정" 같은 다단계 질문에 강합니다.
현장
"미래에셋증권의 GraphRAG 기반 상품지식DB 구축기" — Industry Day Track3. 금융 상품처럼 규정·관계가 복잡한 도메인에 GraphRAG가 잘 맞음.
CDC · Lakehouse
실시간 파이프라인

CDC + Lakehouse — 실시간 AI-Ready 만들기

쉬운말
CDC는 운영 DB에서 변경된 행만 실시간으로 뽑아내는 기술, Lakehouse는 그걸 받아서 분석·AI에 바로 쓰는 통합 저장소. 둘이 짝.
전문어
CDC = Change Data Capture (DB의 binlog/WAL 스트리밍). Lakehouse = Data Lake + Data Warehouse 통합 아키텍처 (Iceberg·Delta Lake 등). 배치 ETL 대체.
설명 한 줄
CDC가 운영 DB 변경을 실시간으로 흘려보내고, Lakehouse가 그걸 받아 분석·AI 학습에 쓰는 구조입니다. 둘이 모이면 데이터가 "지금 이 순간" 상태로 AI에 닿아요.
현장
"Kiro Spec 모드 가속 가이드 & 서버리스 CDC 레이크하우스" — AI Day Track9. CDC·Lakehouse가 서버리스화되며 진입 장벽 낮아지는 흐름.
B · ENGINE — INFRASTRUCTURE

AI 엔진 — 칩과 클러스터

모델을 돌리는 실리콘 층. 비용·속도가 여기서 결정됨.

AWS Trainium · AWS Inferentia
AWS 자체 AI 칩

Trainium / Inferentia — AWS의 자체 AI 칩 듀오

쉬운말
Trainium은 모델 학습 전용 칩, Inferentia는 추론 전용 칩. 둘 다 AWS가 직접 만들어 NVIDIA GPU 대비 단가를 잡는 게 목적.
전문어
Custom silicon. Bedrock·Nova가 이 칩 위에 우선 최적화. 같은 모델을 더 싸게 굴리고 싶을 때의 첫 검토 옵션.
설명 한 줄
Trainium은 학습 전용, Inferentia는 추론 전용. AWS가 NVIDIA 의존도를 낮추려고 직접 만든 자체 칩 듀오입니다.
EC2 P/G Instances · AWS Nitro System
GPU 인스턴스 + 격리 기반

EC2 P/G + Nitro — NVIDIA GPU 옵션 + 신뢰 기반

쉬운말
EC2 P/G는 NVIDIA GPU를 얹은 가상서버 시리즈(P5e, G6 등). Nitro는 그 모든 EC2를 안전하게 격리·가속하는 AWS의 하드웨어 보안 시스템.
전문어
P 시리즈 = 학습용 고성능 GPU, G 시리즈 = 추론·그래픽 워크로드. Nitro = 하이퍼바이저+카드 분리로 호스트 OS에 의존하지 않는 격리 = "AI 워크로드 보안의 베이스라인".
설명 한 줄
NVIDIA GPU 쓰고 싶으면 EC2 P/G가 답이고, 그 모든 인스턴스를 안전하게 격리하는 토대가 Nitro입니다.
HyperPod · Slurm on EKS · EC2 Capacity Blocks
대규모 클러스터

대규모 학습 클러스터 — 수백 대 GPU를 한 묶음으로

쉬운말
HyperPod은 수백 대 GPU를 자동 운영하는 관리형 학습 클러스터, Slurm on EKS는 그 위 잡 스케줄러, Capacity Blocks는 GPU 미리 예약권.
전문어
HyperPod = 노드 장애 자동복구 + 체크포인트 자동저장. Slurm은 HPC 표준 스케줄러, 그게 Kubernetes(EKS) 위에서 도는 게 올해의 통합. Capacity Blocks는 GPU 품귀 시대의 보험.
설명 한 줄
대규모 학습은 한 대로 안 되니 HyperPod이라는 관리형 클러스터에 묶고, Slurm을 EKS 위에서 돌리는 게 표준 조합이 됐습니다. GPU를 미리 잡아두는 Capacity Blocks가 보험이고요.
현장
하이퍼커넥트 — "하이퍼커넥트의 HyperPod 기반 Slurm on EKS 도입기". 영상 AI 학습 회사가 이 구성으로 운영 안정성 ↑ 사례.
C · BIG PICTURE

한 번의 RAG 호출이 지나는 6층

사용자 질문 → 답 한 줄 사이에서 데이터·인프라가 어떻게 합주하는지.

"이 시나리오, 우리 회사 데이터로 답해줘" 한 번의 흐름

위 → 아래 시간 순.
① 데이터STORAGE
S3에 회사 문서·로그·이미지 적재. CDC가 운영 DB 변경분을 흘려보내고 Lakehouse가 받음.
② 검색RETRIEVAL
OpenSearch가 벡터로 인덱싱. 질문이 임베딩되어 RAG/GraphRAG로 관련 문서 후보 추출.
③ 컨텍스트CONTEXT
검색된 문서를 LLM 프롬프트에 함께 끼움. 환각 ↓, 회사 정보 정확성 ↑.
④ 추론INFERENCE
Inferentia 또는 NVIDIA GPU(EC2 P/G)에서 모델이 답 생성. 모두 Nitro로 격리.
⑤ 학습TRAINING
(주기적) 새 데이터로 모델 재학습 시 Trainium + HyperPod 클러스터 + Slurm on EKS로 분산학습.
⑥ 답OUTPUT
사용자에게 한 줄 답변. 뒤에서는 6층이 합주한 결과.
D · CHECK

이해 점검 — 3문제

이번엔 깊이보다 흐름 잡기에 초점. 스크립트 다시 읽으면 거의 다 풀림.

Q1"RAG와 파인튜닝의 결정적 차이"를 한 문장으로?
정답 보기
모범 답: RAG는 모델은 그대로 두고 "회사 데이터"를 검색해 함께 넘기는 방식이고, 파인튜닝은 "모델 자체"를 회사 데이터로 다시 학습시키는 방식입니다.

실무 차이: RAG = 데이터 바뀌면 즉시 반영, 모델 변경 없음, 비용 ↓. Fine-tuning = 모델이 도메인 말투까지 익히지만 갱신 비쌈. 먼저 RAG, 한계 도달 시 fine-tune이 표준 순서.
Q2Trainium·Inferentia·EC2 P/G — 세 가지를 한 줄씩으로 구분한다면?
정답 보기
모범 답:
• Trainium: AWS 자체 칩, 모델 학습 전용.
• Inferentia: AWS 자체 칩, 추론 전용.
• EC2 P/G: NVIDIA GPU를 얹은 EC2 인스턴스 (P=학습, G=추론·그래픽).

암기 키: AWS칩 = 자체 / EC2 P/G = NVIDIA. 둘 다 같은 일을 하지만 선택은 비용·성능·생태계로 결정.
Q3너의 SmartThings Scenario Agent를 진짜 RAG 구조로 진화시킨다면, 어떤 부품들이 어디로 들어가나?
정답 보기
모범 답:
• 27-시나리오 JSON DB → S3에 적재.
• 시나리오 텍스트 임베딩 → OpenSearch 벡터 인덱스.
• Curator가 사용자 입력을 임베딩 → OpenSearch에서 유사 시나리오 검색 = RAG.
• 시나리오 간 관계(같은 디바이스·같은 시간대 등)까지 살리려면 GraphRAG 검토.
• 운영 DB가 생기면 CDC + Lakehouse로 실시간 갱신.

현재 vs 목표: 현재는 facet 기반 retrieval(mini-RAG). 진짜 RAG로 가면 시나리오를 무한 추가해도 검색 정확도 유지.
NEXT · STEP 05

AI 요새 & 응용 — Security · Physical · Business

두뇌·공장·연료·엔진까지 다 갖추면 이제 두 가지가 남습니다. 이 모든 걸 안전하게 지키는 보안(Zero Trust·KMS·DevSecOps), 그리고 이 모든 게 실제로 돈을 버는 곳—피지컬 AI·비즈니스 응용(Robotics FM·Amazon Connect·Quick Suite 등). 이번처럼 스크립트 함께 갑니다.