Step 03 / 06 · The Factory

AI 공장
Development & Operations

모델·에이전트를 매일 찍어내는 생산라인.
AI가 코드를 쓰고 AI가 운영을 감시하기 시작한 순간, "개발"이라는 단어의 정의가 바뀌었습니다.

이 단계의 4개 영역
왜 "공장"인가

2026년의 개발은 "한 명이 IDE에서 코드 짜는 행위"가 아니라,
"여러 에이전트가 24시간 코드를 갱신하는 공정"이 됐습니다.

"공장"이라는 비유가 과장이 아닙니다. AWS Summit의 거의 모든 트랙이 "사람 1명 → 에이전트 N명" 전환을 전제로 깔고 있습니다. 그래서 개발 사이클(A) · 도구(B) · 자동화 파이프라인(C) · 운영 방식(D) 네 가지가 동시에 재설계 중입니다.

사람이 코드를 쓴다 → 사람이 리뷰한다 → 사람이 배포한다 → 사람이 모니터링한다
→
Spec을 쓴다 → 에이전트가 코드 생성 → 사람이 검수 → 파이프라인이 자동배포 → AIOps가 자가복구
A · NEW PARADIGM

새로운 개발 사고방식 — "무엇을 자동화할지"가 바뀜

도구 얘기 전에, 일하는 방식 자체가 어떻게 달라졌는지 한 번에 정리.

AI Native Development
사고방식

AI Native 개발 — AI를 손님이 아니라 동료로

쉬운말
"AI가 코드를 같이 짠다"를 도와주는 기능이 아니라 기본 전제로 깔고 개발 워크플로우를 처음부터 다시 짜는 방식.
전문어
개발 라이프사이클의 모든 단계(요구→설계→코딩→테스트→배포)에 AI를 1차 작업자로 두는 접근. Cloud Native가 "클라우드를 전제로 설계"였다면, AI Native는 "AI를 전제로 설계".
설명 한 줄
우리는 AI Native 방식으로 갑니다. 즉, AI가 1차 코드를 쓰고 사람이 검수·결정하는 구조를 디폴트로 잡습니다.
헷갈리는 것
AI-Assisted
기존 워크플로우에 AI를 추가로 붙임. 예: GitHub Copilot 보조 정도.
AI Native
워크플로우 자체를 처음부터 AI 중심으로 재설계.
David 관점
너는 이미 AI Native 사용자임. Antigravity·Claude CLI·Codex CLI 깔고, prompt.txt를 SSOT로 두고, 에이전트가 코드를 쓰게 한 상태. 이걸 "그냥 AI 좀 써본다"가 아니라 "AI Native 워크플로우를 실험한다"로 표현할 수 있어야 함.
Spec-driven Development
방법론

Spec-driven — 요구사항을 코드처럼 관리

쉬운말
"코드부터 짜자"가 아니라 "요구사항(spec)을 정확히 글로 적자. 코드는 거기서 자동 생성된다"는 접근.
전문어
Spec 문서를 1급 시민(first-class citizen)으로 둔 개발 방법론. Spec ↔ Code 양방향 동기화. AWS Kiro가 이 패러다임의 대표 구현체.
설명 한 줄
Spec을 먼저 정확히 쓰면, 에이전트가 그 spec을 보고 코드를 생성하고, spec이 바뀌면 코드가 따라옵니다.
헷갈리는 것
기존 문서화
코드가 완성된 뒤 사람이 "사후"로 정리. 자주 어긋남.
Spec-driven
spec이 먼저이고 정답. 코드는 거기서 파생되는 산물.
David 관점
너의 prompt.txt SSOT + TODO.md 구조가 정확히 mini-Spec-driven. 마커 기반 추출 시스템은 spec-as-data 응용. 이걸 "Spec-driven 변형 적용 사례"라고 명명할 수 있어야 함.
AI-DLC — AI-driven Development Lifecycle
사이클

AI-DLC — 새 SDLC

쉬운말
기존 SDLC(소프트웨어 개발 사이클)를 AI 시대에 맞춰 다시 그린 것. "기획→코딩→테스트→배포"의 각 단계에 AI가 1차 담당자로 들어감.
전문어
AWS가 이번 Summit에서 부각시킨 라이프사이클 명명. Spec → AI 코드생성 → AI 테스트 → CI/CD → AIOps 운영의 전체 루프. AI Native 사상의 사이클화·표준화.
설명 한 줄
기존 SDLC가 인간 개발자 중심이었다면, AI-DLC는 에이전트가 1차 작성하고 사람이 검토·결정하는 새 사이클입니다.
현장
Industry Day 웅진씽크빅 세션: "웅진씽크빅의 AI-DLC를 활용한 교육용 AI 에이전트 구축기" — 교육 콘텐츠 회사가 자기 AI-DLC를 어떻게 셋업했는지 사례 발표.
David 관점
너의 v1→v2 마이그레이션 과정 전체가 작은 AI-DLC 한 바퀴. "27 시나리오 추출 → 5-Agent 코드생성 → BYOK 테스트 → Cloudflare 배포 → TODO.md 회고" — 이걸 "내 AI-DLC 1회차"라고 부를 수 있어야 함.
B · AI CODING ASSISTANTS

AI 코딩 어시스턴트 — 4개 도구의 분담

전부 "AI가 코드 짠다"는 같은 카테고리지만 목적이 다름. 헷갈리지 않는 게 핵심.

AWS Kiro
Spec → Code

Kiro — 스펙 받으면 코드 짜는 AWS 에이전트

쉬운말
"이 기능 만들어줘"를 말이 아니라 spec 파일로 주면, Kiro가 코드 짜고 테스트 짜고 PR까지 만드는 AWS의 IDE/에이전트.
전문어
Spec-driven coding agent. 두 모드 — Spec mode(요구사항 → 전체 구현), Vibe mode(자연어 대화형 코딩). AWS 생태계 통합이 가장 강점.
설명 한 줄
Kiro는 spec을 입력으로 받아 코드·테스트·PR까지 한 번에 만들어주는 AWS의 코딩 에이전트입니다.
현장
Track5 키노트 단골 — "누구나 손쉽게 개발효율 200% 향상시키는 Kiro 활용법". 신입~중급 개발자 대상 메시징.
David 관점
너의 Antigravity 워크플로우와 비교 가능한 도구. 다만 Kiro는 AWS 결합도가 높아서 — Samsung이 AWS 생태계로 더 들어가면 자연스럽게 마주칠 후보.
Claude Code
CLI 에이전트

Claude Code — 터미널에 사는 코딩 에이전트

쉬운말
Anthropic이 만든 CLI 형태의 코딩 에이전트. IDE 없이 터미널에서 "이 버그 잡아줘 / 이 기능 추가해줘"라고 시키면 파일을 직접 읽고 고침.
전문어
Terminal-based agentic coding assistant. Sub-agent 시스템으로 작업을 위임·병렬화. Claude 모델 직결.
설명 한 줄
Claude Code는 IDE 없이 터미널에서 작동하는 코딩 에이전트라, CI/CD 안에 그대로 끼워넣을 수 있는 게 강점입니다.
현장
Industry Day Track3 빗썸 세션 — "빗썸은 생성형 AI를 어떻게 안전하게 운영하는가: Claude Code on Amazon Bedrock". 금융권에서도 CLI 기반이 채택되는 신호.
David 관점
너가 이미 Claude CLI를 깔아본 적 있음. v2 리팩토링이나 P7-B 같은 작업은 Claude Code의 sub-agent 패턴으로 분리하면 효율 ↑. 단, 회사 데이터 외부 노출 정책 확인 필수.
AWS DevOps Agent
운영 에이전트

DevOps Agent — 빌드·배포·장애대응 담당

쉬운말
코드는 안 짜고, "배포·롤백·장애조사" 같은 운영 작업을 자동화하는 AWS의 전용 에이전트.
전문어
CI/CD·CloudWatch·CodePipeline 등 AWS 운영 도구와 연동되는 도메인 특화 에이전트. Kiro가 코드 작성이라면 DevOps Agent는 운영 실행.
설명 한 줄
DevOps Agent는 코드를 짜는 게 아니라 운영 작업—배포·롤백·장애조사—을 자동화하는 AWS 전용 에이전트입니다.
David 관점
너가 PAT 토큰으로 직접 git push하고 Cloudflare 콘솔에서 수동 배포하는 부분 — 이게 DevOps Agent가 들어갈 자리. 단 회사 정식 도입 전엔 일반화 어려움.
AWS Transform
레거시 현대화

AWS Transform — 레거시 코드 자동 현대화 에이전트

쉬운말
오래된 .NET·메인프레임·Java 6 같은 코드를 AI가 분석해서 최신 클라우드 네이티브 형태로 자동 변환·재작성.
전문어
Legacy-to-modern migration agent. 코드 변환·테스트 작성·문서화까지 일괄. "이전 못해 묶여있던 시스템"의 마이그레이션 비용을 1/10로 만드는 게 셀링.
설명 한 줄
AWS Transform은 오래된 코드를 AI가 분석해서 최신 형태로 자동 변환하는 마이그레이션 에이전트입니다.
헷갈리는 것
Kiro
새 코드 생성. 0 → 1.
Transform
기존 코드 변환. 1(레거시) → 1.5(현대).
DevOps Agent
코드는 그대로, 운영 자동화.
David 관점
너의 일과는 무관하지만, Samsung 사내 레거시 시스템(예: 오래된 사내 마케팅 툴) 현대화 얘기 나올 때 정확히 이걸 가리킬 수 있어야 함.
C · AUTOMATION PIPELINE

자동화 파이프라인 — 코드를 실제 가동까지 옮기는 컨베이어

AI가 코드를 만들었으면, 그게 사용자에게 닿아야 함. 그 사이의 자동 컨베이어 3종.

Infrastructure as Code (IaC)
인프라 자동화

IaC — 인프라를 코드로 적기

쉬운말
서버·DB·네트워크를 콘솔에서 클릭이 아니라 코드 파일로 정의. 그 파일을 실행하면 인프라가 자동으로 만들어짐.
전문어
Declarative infrastructure provisioning. Terraform·CloudFormation·CDK·Pulumi가 대표. "같은 인프라를 재현 가능·버전관리 가능"하게 만드는 사상.
설명 한 줄
IaC는 인프라 구성을 코드로 적어두는 방식이라, 같은 환경을 어디서든 똑같이 재현할 수 있다는 게 본질입니다.
현장
Industry Day Track9 LG유플러스 사례 — "AWS Kiro로 가속하는 IaC 혁신과 레거시 전환". AI 코딩 에이전트가 IaC 코드도 자동 생성.
David 관점
너의 Cloudflare Workers 배포는 wrangler.toml이라는 mini-IaC. "내 v2도 작게나마 IaC 사용 중"이라고 설명 가능.
CI/CD — Continuous Integration / Delivery
자동 배포

CI/CD — 코드 푸시 → 자동 빌드·테스트·배포

쉬운말
CI: 누가 코드 올리면 자동으로 빌드·테스트. CD: 통과하면 자동으로 운영 환경에 배포. 사람의 손이 빠지는 라인.
전문어
DevOps 핵심 실천. GitHub Actions·GitLab CI·AWS CodePipeline 등이 대표 도구. AI 시대에는 "AI가 코드 + AI가 PR 리뷰 + 자동 머지"까지 자동화 폭이 확장.
설명 한 줄
CI/CD는 코드를 올리는 순간 자동으로 빌드·테스트·배포되는 컨베이어 벨트입니다.
헷갈리는 것
IaC
"인프라"를 코드로 (서버·DB 설정).
CI/CD
"코드 변경"을 자동 배포 (애플리케이션).
관계
CI/CD 파이프라인이 IaC 코드를 실행해서 인프라 갱신. 보통 함께 씀.
David 관점
너의 git push https://[PAT]@github.com/...는 수동. 진짜 CI/CD 가려면 — push만 하면 Cloudflare가 자동 배포. wrangler-publish GitHub Action 등으로 가능. v3 단계 후보.
API Management
접점 관리

API 관리 — 외부·내부 호출을 통제하는 게이트

쉬운말
우리 서비스의 API를 누가 얼마나 호출했는지, 인증·요금·트래픽을 한 자리에서 관리하는 게이트웨이.
전문어
API Gateway · Rate Limiting · Auth · Throttling · Versioning. AI 시대에는 에이전트 외부 도구 호출의 단일 통제점이 됨.
설명 한 줄
API 관리는 누가 우리 API를 얼마나 쓰는지 인증·요금·트래픽을 통제하는 게이트인데, 에이전트 시대엔 "에이전트가 외부 도구 호출하는 단일 진입점" 역할이 추가됐습니다.
현장
Track5 Notion 세션 — "Notion: API를 넘어 플랫폼으로". API가 "기능 노출"에서 "에이전트 사용 가능 도구 노출"로 의미 확장 중.
David 관점
너의 5-Agent가 BYOK로 외부 LLM API 호출하는 모든 경로 — Samsung 정식화 시 사내 API Gateway를 한 번 거치는 구조로 바뀜. "누가 무엇을 호출했나" 감사 로그가 그때 확보됨.
D · AI ERA OPERATIONS

AI 시대의 운영 — "Ops" 3형제

MLOps·AIOps·DevSecOps. 셋 다 "Ops"라 헷갈리지만 대상이 완전히 다름. 이걸 정확히 구분하는 게 이 단계 최고의 가치.

MLOps — Machine Learning Operations
대상: 모델

MLOps — 모델의 라이프 관리

쉬운말
"모델"을 데이터 → 학습 → 배포 → 모니터링 → 재학습까지 자동 라이프사이클로 굴리는 운영.
전문어
DevOps의 ML 버전. 모델 버전관리·실험추적·A/B 테스트·드리프트 감지가 추가. SageMaker AI MLOps가 대표 도구.
설명 한 줄
MLOps는 모델 자체의 운영입니다. 데이터부터 학습·배포·재학습까지 모델의 일생을 자동으로 굴리는 라이프사이클이요.
David 관점
너는 모델을 직접 학습시키지 않으니 MLOps 본격 도입은 먼 얘기. 단, "FM에 RFT 돌리기 시작하면 MLOps가 필요해진다"는 임계점 인식 정도면 충분.
AIOps — AI for IT Operations
대상: 시스템 운영

AIOps — 운영실에 AI 분석가 한 명 두기

쉬운말
서버·로그·알람의 산더미 데이터를 AI가 분석해서 "이 장애의 원인은 X" / "이거 곧 터질 것 같음"을 자동 진단. 야간당직을 AI가 보조.
전문어
Anomaly detection·Root cause analysis·자동 인시던트 처리. Datadog·Splunk·Dynatrace 등이 대표. 2026년엔 "Agentic AIOps"로 진화 — AI가 진단만 아니라 복구 행동까지.
설명 한 줄
AIOps는 IT 운영 데이터—로그·메트릭·알람—를 AI가 분석해서 장애 원인을 자동 진단하고, 최근엔 복구까지 자율적으로 시도하는 영역입니다.
현장
Industry Day Track4 야놀자 사례 — "Multi-Agent로 AIOps를 혁신하다". AIOps가 단일 AI에서 멀티 에이전트로 진화 중.
David 관점
너의 v2가 Cloudflare에서 돌면서 에러가 났을 때 — 지금은 너가 수동으로 보지만, AIOps 도구가 들어오면 "최근 30분 P95 지연 ↑ + Anthropic 호출 4xx 증가" 같은 자동 진단을 받게 됨.
DevSecOps
대상: 보안 통합

DevSecOps — 보안을 사이클 안으로

쉬운말
보안을 출시 직전 한 번 검사하는 게 아니라, 코딩·빌드·배포·운영 모든 단계에 자동 보안 검사를 끼워넣는 방식.
전문어
"Shift Left Security". SAST·DAST·SBOM·시크릿 스캔이 CI/CD 안에 자동 삽입. AI 시대에는 "프롬프트 인젝션 검사"·"에이전트 행동 가드레일"이 신규 영역.
설명 한 줄
DevSecOps는 보안을 출시 직전이 아니라 개발 사이클 전 단계에 자동으로 끼워넣는 접근입니다. AI 시대엔 프롬프트 인젝션 검사도 여기 포함됩니다.
헷갈리는 것
MLOps
대상 = 모델. "모델이 잘 작동하나"
AIOps
대상 = 시스템 운영. "장애·로그를 AI가 분석"
DevSecOps
대상 = 보안. "취약점을 사이클에 통합"
David 관점
너의 PAT 토큰 즉시 폐기 습관 — 이게 DevSecOps의 시크릿 관리 베이비 버전. 사내 정식화하면 git push 시 토큰 노출 자동 차단 + 사내 KMS 자동 발급으로 진화.
E · BIG PICTURE

AI 공장의 한 바퀴

13개 용어가 한 바퀴 안에서 어느 위치에 있는지. 이걸 머릿속에 그릴 수 있으면 임원 설명 가능 상태.

한 번의 기능 추가가 도는 길

왼쪽 → 오른쪽 시간 흐름. 각 칸은 "그 단계의 도구/용어".
① 사고방식NEW PARADIGM
AI Native
+
Spec-driven
+
AI-DLC
② 코드 작성CODING TOOLS
Kiro
/
Claude Code
+
AWS Transform
(레거시 시)
③ 배포 라인AUTOMATION
IaC
→
CI/CD
→
API Gateway
→
DevOps Agent
④ 운영OPS
MLOps
(모델)
AIOps
(시스템)
DevSecOps
(보안)
F · SPEAKING TEMPLATES

임원 설명 30초 템플릿 — 여러 용어를 한 호흡에

이 단계의 진짜 목적. 용어 1개씩 외우는 게 아니라, 여러 개를 한 문장으로 묶어 쓸 수 있는지가 시험대.

▸ 상황 1 — 임원이 "AWS Summit 뭐가 핵심이었냐"고 물을 때
"한 줄로 정리하면, AI Native 사고방식이 사이클 단위로 굳어진 게 핵심입니다. Spec-driven으로 요구사항을 적고, Kiro·Claude Code 같은 에이전트가 코드를 1차로 짜고, 그 결과가 CI/CD 위에서 자동 배포되고, 운영은 AIOps·DevSecOps가 받습니다. 이걸 묶은 사이클을 AI-DLC라고 부르더라고요."
AI NativeSpec-driven KiroClaude Code CI/CDAIOps DevSecOpsAI-DLC
▸ 상황 2 — "우리도 AI 코딩 도구 도입하자"는 말이 나올 때
"도구가 한 종류로 묶이는 게 아니라 역할이 셋입니다. Kiro는 spec 받아서 새 코드를 짜는 쪽, Claude Code는 터미널에서 기존 코드 수정·디버깅 쪽, AWS Transform은 레거시 .NET이나 메인프레임 같은 걸 현대화하는 쪽이에요. 신규 개발이 많은 팀엔 Kiro, 운영 부담이 큰 팀엔 Claude Code, 사내 레거시 정리엔 AWS Transform — 이렇게 3축으로 검토하면 됩니다."
KiroClaude Code AWS Transform신규 vs 수정 vs 마이그레이션
▸ 상황 3 — "MLOps랑 AIOps랑 뭐가 다른 건데"가 나올 때
"셋 다 'Ops'지만 대상이 달라요. MLOps는 모델 자체의 운영—학습·배포·재학습—이고, AIOps는 시스템 운영에 AI를 쓰는 거예요. 로그·알람을 AI가 분석해서 장애 원인을 찾는 식. DevSecOps는 보안을 개발 사이클 전 단계에 자동으로 끼워넣는 접근이고요. 야놀자처럼 멀티 에이전트로 AIOps를 짜는 사례가 이번 Summit에서 인상적이었습니다."
MLOpsAIOps DevSecOpsMulti-Agent
Your real workflow mapped to the factory

너가 이미 쓰고 있는 도구들이 사실은 어디인가

"AI 공장"이 추상이 아닌 이유 — 너는 이미 그 안에서 일하고 있음. 명명만 바뀌면 곧장 임원 보고용 어휘가 됨.

Antigravity IDE + Claude CLI + Codex CLI
≈
AI Native Development 환경. Kiro와 같은 카테고리.
prompt.txt SSOT + TODO.md + 마커 추출
≈
소규모 Spec-driven Development. 정식 도구 도입 시 Kiro Spec mode로 합류.
v1 실패 → v2 재설계 → TODO.md 회고
≈
1회차 AI-DLC 사이클.
wrangler.toml + Cloudflare Workers 배포
≈
mini IaC.
PAT 즉시 폐기 습관
≈
개인 단위 DevSecOps 시크릿 관리. 사내 KMS 연동 시 정식화.
git push 후 수동 Cloudflare 콘솔
✗
아직 없는 영역 — CI/CD 자동화로 다음 단계 후보.
장애 시 너가 직접 로그 봄
✗
아직 없는 영역 — AIOps로 다음 단계 후보.
G · CHECK

이해 점검 — "설명할 수 있나" 시험

이번엔 다 서술형. 머릿속으로 답을 한 문장 만든 다음 정답 펼치기. 3개 이상 비슷하면 다음 단계 OK.

Q1임원이 "AI Native와 AI-Assisted, 그게 그거 아니냐"고 물으면?
정답 보기
모범 답: 다릅니다. AI-Assisted는 기존 워크플로우에 AI를 보조로 붙인 거고, AI Native는 워크플로우 자체를 처음부터 AI 중심으로 다시 설계한 거예요. Copilot이 옆에 있는 것과, Spec을 쓰면 에이전트가 코드·테스트·PR을 짜고 사람은 검수만 하는 것의 차이입니다.

핵심 차이: 워크플로우의 "기본값"이 사람인지(보조) AI인지(전제). 이 한 줄이 가장 강력.
Q2Kiro·Claude Code·AWS Transform 세 가지의 역할을 한 문장씩으로 구분한다면?
정답 보기
모범 답:
• Kiro: spec 주면 새 코드를 0에서 1로 짜주는 AWS 코딩 에이전트.
• Claude Code: 터미널 기반으로 기존 코드 수정·디버깅을 시키는 Anthropic의 에이전트.
• AWS Transform: 레거시 코드를 최신 형태로 자동 변환하는 마이그레이션 전용 에이전트.

암기 키: Kiro = 신규 / Claude Code = 수정 / Transform = 현대화
Q3"우린 MLOps 도입 검토 중"이라고 들었을 때, 그게 정확히 어떤 영역을 자동화하겠다는 건지 한 문장으로?
정답 보기
모범 답: MLOps는 모델 자체의 운영—데이터부터 학습·배포·모니터링·재학습까지의 라이프사이클—을 자동화하겠다는 뜻입니다. 시스템 운영이나 보안이 아니라 "모델의 일생" 관리가 대상이에요.

한방 구분법: 대상이 다름.
MLOps = 모델 / AIOps = 시스템 / DevSecOps = 보안
이 세 줄을 외워두면 어떤 자리에서든 휘둘리지 않음.
Q4너의 SmartThings Scenario Agent v2가 "AI 공장" 사이클에서 아직 갖추지 못한 영역 2개를 짚어보면?
정답 보기
모범 답:
(1) CI/CD 자동화 부재 — git push 후 Cloudflare 콘솔에서 수동으로 배포하는 단계가 남아 있음. wrangler-publish GitHub Action 등을 끼우면 자동화 가능.

(2) AIOps 부재 — 장애 시 너가 직접 로그를 봄. Datadog·Cloudflare Analytics 같은 도구를 붙여 자동 진단을 받을 수 있는 단계가 비어 있음.

보너스 답: DevSecOps도 PAT 즉시 폐기로 개인 단위만 챙긴 상태 — Samsung 사내 KMS 연동 시 정식화 가능.
NEXT · STEP 04

AI 연료 & 엔진 — Data & Infrastructure

두뇌(2)와 공장(3)을 갖췄으면, 이젠 그게 먹는 연료와 도는 엔진. RAG · GraphRAG · S3 · OpenSearch · CDC · Lakehouse · Trainium · Inferentia · EC2 P/G · HyperPod · Slurm on EKS · Nitro. 데이터 + 컴퓨트가 한 번에 들어가서 분량이 가장 무거운 단계. 다음 단계 전에 잠깐 쉬어가는 옵션도 같이 드릴게요.