Step 02 / 06 · The Brain

AI 두뇌
Models & Agents

판단하고 행동하는 부분. 모델 본체부터, 그 모델을 "비서"로 만들어 도구를 쓰게 하는
에이전트 프레임워크 / 프로토콜 / 아키텍처까지 한 묶음.

이 단계에서 다루는 5개 영역
왜 "두뇌"인가

모델 = 똑똑한 신입사원. 에이전트 = 그 신입에게 도구함과 업무권한을 쥐어준 상태.

LLM은 갓 졸업한 천재 신입에 가깝습니다. 일반 상식은 압도적이지만, 우리 회사 메일을 보낼 줄도, DB를 뒤질 줄도 모릅니다. "에이전트화"란 이 신입에게 (1) 도구함·(2) 회사 매뉴얼·(3) 다른 동료와 협업하는 규약을 쥐어주는 작업입니다.

이번 Summit에서 두뇌 카테고리의 95%는 결국 이 세 가지를 어떻게 표준화·관리형 서비스로 제공하느냐의 이야기입니다. David의 5-Agent 파이프라인이 정확히 이 층의 산물입니다.

A · FOUNDATION MODELS

파운데이션 모델 — 뇌 자체

학습이 끝난 거대 신경망 본체. 우리는 보통 이걸 "빌려쓰는" 형태로 만남.

Foundation Model (FM)
개념

파운데이션 모델 — 천재 신입사원

쉬운말
대용량 데이터로 사전학습된 범용 거대모델. "일반 상식은 다 아는 신입" 상태. GPT-4, Claude, Gemini, Nova가 전부 FM.
전문어
광범위한 코퍼스로 self-supervised 사전학습된 대형 신경망. 한 번 학습 → 수많은 downstream task에 재활용(transfer). 그래서 "Foundation".
현장 발화
"이 기능을 FM 위에 얹을지, 우리가 모델을 직접 fine-tune할지부터 정합시다."
David 관점
너의 v2가 OpenAI·Anthropic·Gemini를 BYOK로 갈아끼울 수 있는 건, 셋 다 같은 "FM API 호출" 추상 위에 있어서임. 모델별 차이는 가격·품질·컨텍스트 길이뿐.
Amazon Bedrock
서비스

베드락 — 모델 뷔페

쉬운말
여러 회사의 FM을 단일 메뉴판으로 골라쓰는 AWS의 서비스. Claude도 Llama도 Nova도 같은 API로 호출 가능.
전문어
서버리스 FM 게이트웨이. 모델 호스팅·인증·로깅·가드레일·평가·RAG·에이전트까지 통합 제공. 모델별 SDK를 따로 안 깔아도 됨.
현장 발화
"Bedrock 통해서 Claude 쓰면 회사 IAM 정책으로 거버넌스가 잡힙니다."
David 관점
너의 BYOK 구조가 provider="anthropic"로 분기하는 부분 — Samsung 사내에서 정식화하면 그 자리에 Bedrock 호출이 들어감. API 키 관리 부담을 회사 IAM으로 위임하는 효과.
Amazon Nova · Nova 2
모델 패밀리

노바 — AWS가 직접 키운 자체 모델

쉬운말
AWS가 자기 칩(Trainium)으로 직접 만든 FM 패밀리. 텍스트 / 이미지 / 멀티모달 / 추론 모델까지. Nova 2는 그 차세대로 이번 Summit의 주력 발표.
전문어
first-party FM 패밀리. Anthropic·Meta 같은 외부 모델 대비 인프라 결합도가 높아 비용·지연이 유리한 게 셀링 포인트. Bedrock에서 1st-party 옵션으로 노출.
현장 발화
"Nova 2 프로덕션 적용 여정" — Track1·15:30 세션 제목. "외부 모델 의존도를 줄이고 비용 잡았다"는 사례 발표가 다수.
David 관점
너의 v3에서 한국어 품질·비용 두 마리를 잡고 싶다면, Bedrock-Nova 2를 BYOK 선택지에 추가해보는 게 시험 가치 있음. 단, 한국어 마케팅 카피 품질은 Claude가 우위일 가능성 — A/B 테스트 필요.
Anthropic Claude
외부 모델

앤트로픽 클로드 — Bedrock에 들어오는 손님 중 가장 인기있는

쉬운말
Anthropic이 만든 FM. 추론·코딩·긴 문서 처리에 강하고, 안전성 설계가 깐깐한 걸로 알려짐. Bedrock에서 단골 메뉴.
전문어
Constitutional AI 학습 방식 + 긴 컨텍스트(수십만 토큰) 지원. MCP 프로토콜의 원작자이기도 함(이 단계 D섹션 참조).
현장 발화
"바비톡의 AX여정: 에이전틱 AI로 K-beauty를 바꾸다" Sponsored by Anthropic. — 한국 기업이 Claude 기반으로 에이전트 만든 사례.
David 관점
너의 v2 Copy Consult(Mode2) 품질 튜닝(P7-B)이 어려운 이유 중 일부는 모델 선택과도 무관하지 않음. Claude Sonnet 계열이 카피라이팅 결에서 유리한 경우가 많음.
Nova Forge · Bedrock RFT
커스터마이징

노바 포지 / RFT — 신입을 우리 회사 일에 재교육

쉬운말
범용 FM을 우리 도메인(예: Samsung SmartThings 시나리오)에 맞게 다시 학습시키는 도구. Nova Forge는 노바 전용, RFT는 강화학습 기반 미세조정.
전문어
Fine-tuning의 변종. RFT(Reinforcement Fine-Tuning)는 "좋은 답 / 나쁜 답" 보상 신호로 모델을 조정. 일반 SFT보다 행동 교정에 강함.
현장 발화
"Nova Forge와 Bedrock RFT로 모델 성능 극대화" — Track1·13:50. 보통 "프롬프트 한계 → 파인튜닝" 전환점에서 등장하는 화제.
David 관점
너의 27-시나리오 JSON DB가 충분히 쌓이면, 이걸 RFT 보상 데이터로 써서 "Samsung 시나리오 스타일"에 특화된 모델을 만들 수 있음. v4 단계 고민거리.
B · MANAGED ML PLATFORM

관리형 ML 플랫폼 — 모델을 만들고 운영하는 통합 작업장

FM을 쓰는 것보다 한 단계 깊은 영역. 데이터 → 학습 → 배포 → 운영을 한 자리에서.

Managed Service
개념

관리형 서비스 — "서버 관리는 우리가 할 테니 너는 일만 해"

쉬운말
서버 설치·패치·확장·백업을 클라우드가 다 해주고, 사용자는 "쓰기"에만 집중하는 형태. SageMaker·Bedrock·OpenSearch 다 그래.
전문어
Self-managed의 반대. 운영부담 위임 모델. 비용은 비싸지지만 인력 부담 / SLA / 보안 측면에서 이득. 엔터프라이즈가 선호.
현장 발화
"Managed Service를 통해 인프라 관리 부담 없이 엔터프라이즈급 AI 모델을 개발할 수 있습니다." — Track1 키노트.
David 관점
너의 v2가 Cloudflare Workers 위에 얹혀 있는 것도 같은 발상. "서버를 직접 운영하지 않고 함수 단위로 호출" = Workers의 관리형 모델.
Amazon SageMaker
통합 플랫폼

세이지메이커 — ML 작업장 전체

쉬운말
데이터 준비부터 모델 학습·배포·모니터링까지 ML 전 과정을 한 자리에서 하는 AWS의 핵심 플랫폼.
전문어
엔드투엔드 ML 플랫폼. Notebook·Training Job·Endpoint·Pipeline·Model Registry·Feature Store 등이 한 묶음. Bedrock과의 차이: Bedrock은 "이미 만들어진 FM API", SageMaker는 "내가 직접 만들고 굴리는 영역".
현장 발화
"SageMaker AI MLOps, Nova 2 기반 멀티 에이전트로 한 단계 업그레이드" — Track1·14:30.
David 관점
너는 지금 SageMaker가 필요한 단계가 아님. 시나리오 JSON DB 양이 임계치를 넘고, "한국어 마케팅 카피 평가 모델"을 직접 만들고 싶어질 때부터 등장. 마음에 새기고 넘기면 됨.
SageMaker Unified Studio
IDE

유니파이드 스튜디오 — ML 작업자용 통합 IDE

쉬운말
데이터 사이언티스트·엔지니어가 한 화면에서 데이터 탐색·노트북·파이프라인 다 다루는 IDE.
전문어
기존에 흩어져 있던 SageMaker Studio + Data Wrangler + Glue Studio 등을 단일 워크스페이스로 통합. Bedrock·OpenSearch도 같은 콘솔에서 호출 가능.
현장 발화
"Amazon SageMaker Unified Studio, S3, OpenSearch를 효과적으로 관리하고 활용하는 방법" — Track2 키노트.
David 관점
너의 Antigravity와 같은 결의 도구. 다만 SageMaker Unified Studio는 "AWS 생태계 안에 들어왔을 때"의 선택지. Samsung이 SageMaker 도입하면 합류 가능성 있는 환경.
SageMaker Catalog
자산 관리

카탈로그 — 회사 안 모델·데이터셋의 도서관

쉬운말
"우리 회사에 어떤 모델이 있고 누가 만들었고 어떻게 쓰는지"를 검색·등록·평가하는 카탈로그.
전문어
Data & Model Discovery 레이어. 사내 자산을 거버넌스·메타데이터·계보(lineage)와 함께 관리. 같은 모델을 부서별로 중복 만드는 낭비를 차단.
현장 발화
"밑줄 쫙! AI성공 네비게이터 SageMaker Catalog" — Track2·14:30.
David 관점
Samsung 사내에서 "Scenario Agent v2가 어떤 모델·프롬프트·데이터로 돌아가는지" 검색되게 만들어야 할 때, 그 자리에 들어가는 도구. 지금 너의 prompt.txt SSOT 컨셉을 회사 단위로 확장한 게 Catalog.
C · AGENT FRAMEWORKS

에이전트 프레임워크 — 모델을 "비서"로 만드는 도구

모델 자체는 그냥 똑똑한 답변기. 여기에 "계획·도구사용·기억"을 붙여야 에이전트가 됨.

Agent · Agentic AI
개념

에이전트 — LLM + 도구사용 + 자율판단

쉬운말
단순히 답만 주는 챗봇이 아니라, "목표를 받으면 스스로 계획 세우고 도구 골라쓰고 결과 검증까지 하는 AI". 그래서 Agentic(자율적인).
전문어
"Plan → Tool-use → Observe → Reflect → Act" 루프를 도는 LLM 시스템. 단발성 응답이 아니라 다단계 의사결정을 함. Chatbot ≠ Agent.
현장 발화
"에이전틱 AI로 완전히 달라지는 소프트웨어와 개발 방법" — 이번 Summit에서 가장 많이 반복된 슬로건.
David 관점
너의 SmartThings Scenario Agent는 이미 에이전트야. 다만 "도구사용"이 아직 약한 단계 — Activator가 실제로 SmartThings API를 호출해서 시나리오를 등록하면 진짜 Agentic으로 한 단계 도약.
Amazon Bedrock AgentCore
런타임

에이전트코어 — 에이전트가 일하는 관리형 사무실

쉬운말
에이전트를 "실행"시키는 AWS의 관리형 런타임. 메모리·도구연결·로그·세션을 다 알아서 관리.
전문어
서버리스 Agent Runtime + Memory + Identity + Gateway 묶음. 너가 직접 EC2 돌리고 세션 상태 관리하는 부담을 AWS가 가져감.
현장 발화
"Strands Agents와 함께 스스로 진화하는 AI 에이전트 / AI 에이전트, AgentCore로 프로덕션까지" — Track3·Track4 단골 주제.
David 관점
너가 지금 Workers로 5-Agent 파이프라인을 직접 코딩한 부분 — AWS 정식 도입 시 그 자리에 AgentCore가 들어옴. "세션 상태·메모리·로그"가 무료 부수효과.
Strands Agent SDK
개발 키트

스트랜즈 SDK — 에이전트를 손쉽게 짜는 파이썬 키트

쉬운말
AWS가 만든 오픈소스 Python SDK. pip install로 에이전트 코드 몇 줄로 시작 가능. AgentCore에 올리면 그대로 프로덕션.
전문어
Lightweight agent framework. LangChain/LangGraph 계열 경쟁자 위치. Bedrock·Anthropic·OpenAI 모두 지원해서 BYOK 친화적.
현장 발화
"Nova Act & Strands Agent 실전: AI 에이전트로 개발 워크플로 자동화하기" — Track5·16:10.
David 관점
파이썬 기초 학습 중인 너에게 매우 적합한 진입점. v3 학습 단계로 "5-Agent 파이프라인을 Strands SDK로 재작성"이 좋은 연습거리. LangGraph는 학습곡선이 가팔라서 Strands가 한결 수월.
D · AGENT PROTOCOLS

통신 프로토콜 — 에이전트가 외부와 대화하는 약속

똑똑한 비서끼리도 "어떻게 말 걸지" 정해놔야 협업이 됨. USB-C가 되기 직전의 단계.

MCP — Model Context Protocol
표준

MCP — AI의 USB-C

쉬운말
모델 ↔ 외부 도구/데이터 연결의 표준 규격. Anthropic이 만들고 OpenAI·Google·AWS가 채택. "모델별로 도구 연동 코드를 따로 짤 필요 없음"이 핵심 효익.
전문어
JSON-RPC 기반 클라이언트-서버 프로토콜. MCP 서버는 "도구·리소스·프롬프트"를 노출, 어느 LLM 클라이언트든 호환. 사실상 "LLM의 USB-C"로 자리잡는 중.
현장 발화
"Model Context Protocol(MCP), Agent-to-Agent(A2A) 통신" — Track3 키노트. 이번 Summit에서 사실상 표준화 선언.
David 관점
SmartThings API · 시나리오 JSON DB · prompt.txt를 각각 MCP 서버로 노출하면, 어떤 모델을 쓰든 동일한 도구를 호출 가능. v3에서 가장 임팩트 큰 리팩토링 후보.
A2A — Agent-to-Agent
표준

A2A — 에이전트끼리의 사내 메신저 규약

쉬운말
서로 다른 회사·프레임워크가 만든 에이전트들이 한 작업을 협업할 때 쓰는 통신 약속. 구글이 주도, AWS·Anthropic 등이 합류.
전문어
Agent-to-Agent interoperability protocol. MCP가 "모델 ↔ 도구" 라면, A2A는 "에이전트 ↔ 에이전트". 작업 위임·진행상황 공유·결과 회수가 표준 메시지로.
현장 발화
"AI 에이전트 개발을 위한 핵심 기술 스택과 프레임워크 — Agent-to-Agent(A2A) 통신" — Track3 키노트.
David 관점
너의 5-Agent는 지금 한 코드베이스 안에서 함수 호출로 연결됨 — 진짜 A2A가 아니라 모놀리식 파이프라인. Curator가 별도 서비스가 되고, Localizer가 다른 팀의 에이전트가 되는 순간 A2A가 의미 있어짐.
E · AGENT ARCHITECTURE

에이전트 아키텍처 — "몇 명을 어떻게 묶을 것인가"

한 명의 슈퍼 에이전트보다, 전문가 여러 명을 잘 묶는 게 보통 더 잘 됨. 그 묶는 방식의 분류.

Multi-Agent · Sub-agent · Pipeline · Orchestrator
아키텍처 패턴

멀티 에이전트 패턴 — 1인 만능 ✕ , 전문가 팀 ◯

쉬운말
에이전트 여러 명을 역할별로 나누고 협업시키는 설계. 대표적인 4가지 패턴 — 단일 / 파이프라인 / 오케스트레이터 / 자율협업.
전문어
Single-agent: 모든 일을 한 에이전트가. 간단하지만 한계.
Pipeline: 컨베이어 벨트 — A→B→C 순차. David의 v2 패턴.
Orchestrator + Sub-agents: 팀장 에이전트가 부하 에이전트에게 분담. Claude Code의 sub-agent 구조가 대표.
Autonomous Multi-Agent: 에이전트들이 자율적으로 협상·합의. 가장 어려움, 가장 강력.
현장 발화
"Multi-Agent로 AIOps를 혁신하다: 야놀자의 Bedrock AgentCore 구축 사례" — Industry Day Track4·16:10.
David 관점
너의 v2 = 전형적인 Pipeline pattern. 다음 진화 후보 두 가지: (1) Curator를 Orchestrator로 승격 — 시나리오 복잡도에 따라 Localizer를 건너뛰거나 두 번 부르거나. (2) Story Chat을 별도 Sub-agent로 분리 — 자료 발견된 모듈을 정식 패턴으로.
F · BIG PICTURE

5개 영역의 레이어 구조

두뇌 안에서 각 용어가 어디 층에 있는지 한 장에. 위에서 아래로 갈수록 추상화 수준이 높음.

AI 두뇌의 5층 스택

"사용자 요청 한 줄"이 닿는 순서대로 위 → 아래
5층 · 아키텍처
Multi-Agent / Pipeline / Orchestrator — "몇 명을 어떻게 묶을지" 설계 결정
4층 · 프로토콜
MCP / A2A — 에이전트가 외부·서로 대화하는 표준 약속
3층 · 프레임워크
AgentCore / Strands SDK — 모델을 "도구 쓰는 비서"로 만드는 코드 키트와 런타임
2층 · 모델 API
Bedrock / OpenAI / Anthropic 등 — FM을 호출하는 단일 API 추상화
1층 · 모델 본체
Nova / Claude / Llama / Gemini — 사전학습된 거대 신경망 (Foundation Model)
Your v2 mapped to the brain stack

너의 SmartThings Scenario Agent v2를 5층 스택 위에 올려보면

현재 (v2):
Curator
→
Localizer
→
Personalizer
→
Expander
→
Activator

1층(모델): BYOK로 OpenAI / Anthropic / Gemini 선택 가능 ✅
2층(API): 각 provider SDK 직호출 — Bedrock 통합 시 표준화 가능
3층(프레임워크): 직접 구현된 5-Agent 파이프라인 — Strands SDK로 재작성 시 코드량 ↓
4층(프로토콜): 아직 없음 — 27-시나리오 JSON DB를 MCP 서버화가 가장 큰 도약 후보
5층(아키텍처): Pipeline 패턴 — Orchestrator 패턴으로 진화 시 시나리오별 동적 분기 가능

G · CHECK

이해 점검 — 4문제

3개 이상 맞으면 다음 단계로. 아니면 헷갈리는 카드만 다시 봐주세요.

Q1"Foundation Model" 과 "Agent"의 결정적 차이를 한 문장으로 설명한다면?
정답 보기
모범 답: FM은 "답을 주는 모델", Agent는 "FM + 도구사용 + 다단계 판단"이 결합된 시스템.

풀이: FM은 입력을 받아 한 번에 답을 내는 부품. Agent는 그 FM을 두뇌로 두고, 외부 도구(API·DB·검색)를 골라쓰며, 결과를 보고 다음 행동을 정하는 루프 구조. Chatbot ≠ Agent 라는 표현도 같은 의미.
Q2"Bedrock과 SageMaker의 차이"를 임원에게 30초로 설명한다면?
정답 보기
모범 답: Bedrock은 "이미 만들어진 FM을 API로 빌려쓰는 서비스", SageMaker는 "내가 데이터부터 가지고 모델을 직접 만들고 운영하는 작업장".

풀이: 비즈니스 임팩트 관점에서는 — Bedrock = 속도와 가성비, SageMaker = 차별화와 깊은 도메인 특화. 대부분 회사는 Bedrock으로 시작해 필요한 부분만 SageMaker로 깊게 들어감.
Q3MCP와 A2A의 차이는?(a) MCP는 모델↔도구, A2A는 에이전트↔에이전트
(b) MCP는 AWS 표준, A2A는 Google 표준
(c) MCP는 보안용, A2A는 성능용
(d) 둘 다 같은 개념의 다른 이름
정답 보기
정답: (a)

풀이: 결합도 차이가 결정적. MCP는 모델 ↔ 외부 도구·데이터 표준(Anthropic 주도), A2A는 에이전트 ↔ 에이전트 협업 표준(Google 주도). (b)도 부분적으로는 맞지만, 본질 차이가 아닌 출신만 짚은 답이라 (a)가 정답. 비유: MCP = USB-C / A2A = 사내 메신저 규약.
Q4너의 v2 5-Agent 파이프라인을 "에이전트 아키텍처 패턴"으로 분류하면? 그리고 다음 진화 후보 한 가지는?
정답 보기
정답: 현재 = Pipeline pattern (순차 컨베이어). 진화 후보 = Orchestrator pattern.

풀이: Curator → Localizer → Personalizer → Expander → Activator는 고정 순서로 흐르므로 정의상 Pipeline.

Orchestrator로 진화시키면 — Curator가 시나리오 복잡도/언어/디바이스 조합을 보고 "이 건은 Localizer 두 번 호출, Expander 생략" 같은 동적 분기가 가능. Story Chat 모듈을 Sub-agent로 정식 등록하는 것도 같은 방향. 대안으로 MCP 서버화(시나리오 DB를 표준 도구로 노출)도 큰 도약이지만, 그건 4층 프로토콜 영역.
NEXT · STEP 03

AI 공장 — Development & Operations

모델·에이전트를 만들었으면, 이제 그걸 매일 갱신하고 안전하게 배포하는 "생산라인" 차례. Kiro · AI-DLC · Spec-driven · IaC · CI/CD · MLOps · AIOps · DevSecOps · AWS Transform. David의 Antigravity 워크플로우가 이 그림 어디에 있는지도 같이 봅니다.