Chap 9. 세계를 어떻게 구현할 것인가? – Agentic AI와 Physical AI
레거시 AI 개발 방식과 모던 AI 개발 방법론을 비교하고, 최신 도구를 이용하여 사례를 분석합니다.
여는 질문 — 토대 위에서 무엇을, 어떻게 만들 것인가
7장과 8장은 두 가지를 우리 손에 쥐어 주었다. 7장은 거대한 모델을, 8장은 그 모델을 빌려 쓸 수 있는 토대(클라우드·반도체 인프라)를. 재료와 부엌이 모두 갖춰진 셈이다. 그렇다면 이제 남은 질문은 단순하다. 이 토대 위에서 우리는 무엇을, 어떻게 직접 만들 것인가?
그런데 7장은 동시에 한 가지 한계를 남겼다 — 텍스트는 세계의 그림자다. “컵을 밀면 떨어진다”를 문장으로 외운 모델은, 정작 컵을 잡을 손도, 떨어지는 컵을 막을 몸도 없다. 그래서 이 장의 질문은 두 겹이다. 하나는 토대 위에서 어떻게 직접 만드나(개발 방식의 문제)이고, 다른 하나는 언어를 넘어 어떻게 물리 세계로 확장하나(그림자를 벗어나는 문제)이다.
이 두 질문에는 공통의 줄기가 흐른다. 말하는 AI에서 행동하는 AI로. 답을 제안만 하던 AI가 직접 코드를 실행하고(전반부), 더 나아가 물리 세계에서 몸을 움직이는(후반부) 쪽으로 옮겨 가는 이야기다. 레거시 개발 방식의 한계에서 출발해 보자.
레거시의 풍경 — APM 스택에서 출발하기
2000년대의 웹 서비스는 단순했다. APM 스택(Apache-PHP-MySQL) — 웹 서버가 요청을 받고, PHP가 로직을 처리하고, MySQL이 데이터를 저장한다. 이를 일반화한 것이 Web-WAS-DB 3계층 모놀리식 아키텍처다. 하나의 거대한 덩어리(monolith)가 모든 기능을 담당한다.
모놀리스는 시작과 이해가 쉽다. 문제는 성장이다. 기능 하나를 고치려면 전체를 재배포해야 하고, 주문 모듈의 장애가 로그인까지 마비시키고, 팀이 커질수록 코드베이스가 충돌의 전장이 된다. 그래서 진화의 계열이 이어졌다:
- MSA(마이크로서비스): 기능별 독립 배포되는 작은 서비스들로 분해
- CI/CD: 코드 변경을 자동으로 테스트·배포하는 파이프라인 — 2장의 피드백 루프가 개발 프로세스에 적용된 것
- Agile: 거대한 사전 계획 대신 짧은 반복과 잦은 피드백
- 클라우드 네이티브: 서버를 소유하지 않고 필요한 만큼 빌려 쓰는 탄력 인프라(8장)
- MLOps/LLMOps: 코드만이 아니라 데이터와 모델도 버전 관리하고, 배포 후 성능 드리프트를 감시 — 모델은 코드와 달리 ‘조용히 틀리기’ 때문이다
세미나는 이 추상적 진화를 실제 구축 사례의 변천으로 보여준다. 2018년의 한 데이터 분석 시스템은 ① 크롤링 수집(Java/배치) → ② 하둡 기반 데이터 레이크 → ③ 비정형 분석(WEX) → ④ 데이터 마트(Hive/Impala) → ⑤ Python/R/TensorFlow 모델링 → ⑥ Web/WAS 시각화로 이어지는, 여전히 배치 중심·온프레미스(GPU 서버: Tesla P100 2장)의 구조였다. 그러던 것이 2021년 금융권 AICC(AI 컨택센터, STT/TTS/NLU/NLG/MRC 결합)를 거쳐, 2024년에는 AI Cloud Manager — Ansible 기반 설치 자동화와 컨테이너 이미지로 GPU 클라우드 인프라를 통합 관리하고 데이터 과학자가 개발 환경을 골라 배포하는 — 클라우드 네이티브·MLOps 형태로 옮겨갔다. 한 줄로 줄이면, ‘소유한 서버에 배치로 돌리던 모놀리스’에서 ‘빌려 쓰는 인프라 위의 컨테이너·파이프라인’으로의 이동이다.
챗봇 vs 에이전트, 채팅 vs CLI
챗봇은 질문에 답한다. **에이전트(Agent)**는 목표를 받아 스스로 작업을 끝까지 수행한다. 슬라이드의 정의를 그대로 옮기면 — “주변 환경을 인지하고 학습하며 능동적으로 문제를 해결하기 위해 스스로 목표를 설정하고, 계획을 세우고, 실행하는 능력을 가진 인공지능.” 이를 떠받치는 두 기둥이 도구(Tool)와 추론(Reasoning)이다. 도구는 외부 환경·애플리케이션과 상호작용하는 행동(Action)이고(메모리·캐시 포함), 추론은 “Let’s think step-by-step”의 단계적 사고(Chain-of-Thought)다. 이 둘을 한 루프로 엮은 것이 ReAct(Reasoning + Acting) — 생각하고, 도구로 행동하고, 결과를 관찰해 다시 생각하는 순환이며, 여러 에이전트가 협업하는 멀티에이전트로 확장된다. 차이는 세 가지 능력이다.
| 능력 | 내용 | 뿌리 |
|---|---|---|
| 도구 사용 | 검색, 코드 실행, 파일 읽기·쓰기, API 호출 | — |
| 다단계 계획 | 목표를 하위 작업으로 분해하고 순서 결정 | 3장의 탐색 |
| 자기 수정 | 실행 결과를 관찰해 다음 행동 조정 | 6장의 에이전트-환경 루프 |
채팅과 CLI의 차이가 이 전환을 가른다. 채팅창의 AI는 텍스트를 제안할 뿐이지만, CLI(명령줄)에서 작동하는 에이전트는 사용자의 컴퓨터에서 파일을 읽고, 프로그램을 실행하고, 결과를 확인한다. 말하는 AI에서 행동하는 AI로.
| 비교 | 일반 채팅 (Web/App) | CLI 에이전트 |
|---|---|---|
| 작동 위치 | 클라우드 서버 (고립) | 사용자 로컬 환경 |
| 파일 수정 | 불가 (복사·붙여넣기) | 직접 생성·수정·저장 |
| 프로그램 실행 | 불가 | 빌드·테스트·배포 자동화 |
| 도구 확장 | 제한적 플러그인 | MCP로 무제한 연동 |
직접 만들기 ①: 바이브 코딩 — 자연어가 프로그래밍 언어가 되다
소프트웨어의 역사는 추상화의 사다리였다: 기계어 → 어셈블리 → C → Python → 그리고 자연어. 2025년 카르파시가 이름 붙인 바이브 코딩(Vibe Coding): 원하는 것을 말로 설명하면 AI 에이전트가 코드를 작성·실행·수정하는 개발 방식이다.
사례 1 — 모닝 브리핑 에이전트. 출발점은 한 문장이었다:
“매일 아침 6시에 금융/과학 뉴스와 AI 기사/논문을 수집해서 Slack과 메일로 보내주는 에이전트를 만들어줘”
이 한 문장에서 30분 만에 MVP가 나왔고, 이후 대화로 오류 수정과 기능 추가를 반복해 — RSS 30개+API 8개를 병렬 수집하고, 키워드 스코어링과 중복 제거(1장의 Jaccard 유사도가 여기서 실전 투입된다)를 거쳐, 매일 아침 자동 발송되는 시스템이 완성됐다. 운영 비용 0원(무료 API + GitHub Actions).
사례 2 — 이 책과 이 위키. 논문 PDF를 주고 “레퍼런스에 추가해줘”라고 말하면, 에이전트가 요약을 만들고, 위키 페이지를 생성하고, 목차를 갱신하고, GitHub에 커밋·푸시한다. 69편의 논문 레퍼런스와 10개 챕터 초안이 이 방식으로 만들어졌다.
두 사례의 공통 교훈: 핵심 역량은 코드 작성이 아니라, 원하는 바를 정확히 기술하고 결과를 검증하는 능력이다.
직접 만들기 ②: MCP — 에이전트에 도구를 연결하기
**MCP(Model Context Protocol)**는 에이전트와 외부 도구·데이터(DB, 사내 시스템, 금융 API…)를 잇는 표준 규격 — “AI 시대의 USB 포트”다. 연결은 설정 파일 몇 줄이다:
{
"mcpServers": {
"kis-trading-mcp": {
"command": "uv",
"args": ["--directory", "C:/path/to/Kis Trading MCP",
"run", "server.py", "--stdio"]
}
}
}이렇게 증권사 API의 MCP 서버를 연동하면, 자연어가 곧 인터페이스가 된다:
“전체 계좌에 대한 실현수익률과 평가수익률을 계산해줘” “삼성전자 현재가가 34만원이 되면, 일반주식 계좌에서 50주 매도해줘”
에이전트는 자연어 조건부 주문을 종목코드·수량·트리거 조건의 정밀한 페이로드로 번역하고, 실행 전 승인 팝업(인간의 확인)을 거친다 — 행동하는 AI에는 차단기(circuit breaker)가 함께 설계되어야 한다는 원칙(10장)의 실물이다.
MCP의 구조는 세 역할로 나뉜다(슬라이드 기준): MCP Host는 연결을 관리하는 LLM 애플리케이션(예: Cursor), MCP Client는 서버와 1:1 연결을 유지하는 부분, MCP Server는 LLM에게 도구(tools)·문맥(context)·기능(capabilities)을 제공하는 쪽이다. 핵심 발상은 “기존의 API를 에이전트가 이해할 수 있는 형식(Context Schema)으로 변환”하는 것 — REST API가 사람이 읽는 명세였다면, MCP는 에이전트가 곧장 집어 쓰도록 도구의 기능과 데이터를 표준화한 인터페이스다. A2A는 한 발 더 나아가 에이전트들 사이의 통신 규약이다 — 에이전트 공동체의 표준어가 만들어지고 있는 것이다.
언어모델에서 월드모델로
7장에서 본 LLM 비판의 핵심: 텍스트는 세계의 그림자다. “컵을 밀면 떨어진다”를 문장으로 아는 것과 물리적 인과로 아는 것은 다르다.
르쿤의 「A Path Towards Autonomous Machine Intelligence」(2022)는 대안 청사진이다 — 픽셀을 예측하지 말고, 추상 표현 공간에서 세계의 다음 상태를 예측하라(JEPA). 그가 드는 이유는 분명하다: “Generative 모델은 세상의 모든 세부 사항을 예측해야 하는데, 세상은 부분적으로만 예측 가능하기 때문”에 이미지·영상 같은 고차원 연속 데이터에는 맞지 않는다. 그래서 현재 시점(t)의 정보로 다음 시점(t+1)의 세계 상태의 **표현(representation)**을 예측한다. 슬라이드의 표현으로 JEPA는 “기존 LLM의 토큰 단위 Low-Level 학습의 비효율성을, 블록 단위 임베딩(Context Embedding / Target Embedding) 방식으로 추상화”한 것이다. 아기가 말을 배우기 전에 중력과 사물의 영속성을 배우듯, 관찰로부터 세계의 동역학을 학습한다. 디테일(나뭇잎의 흔들림)은 버리고 예측 가능한 구조(공의 궤적)만 잠재 공간에 남긴다 — 5장의 오토인코더가 “압축이 곧 이해”였다면, JEPA는 “예측 가능한 것만 압축하라”다. 르쿤의 주장은 단호하다: “자기회귀 LLM을 키우는 것으로는 인간 수준 AI에 도달하지 못한다(Scaling up auto-regressive LLMs will not take us there). 기계가 세계가 작동하는 방식을 배우게 해야 한다.” 그는 AGI라는 단일 목표 자체를 부정하며(“지능은 다차원적이다”), 인간 수준 AI 이전에 고양이 수준·개 수준 AI를 먼저 보게 될 것이라 말한다.
이 노선은 브룩스의 「Intelligence Without Representation」(1991, 6장) — “세계 자체가 최고의 모델” — 의 현대적 부활이기도 하다. VLA(Vision-Language-Action) 모델은 실용판이다: 보고(V), 지시를 이해하고(L), 로봇 팔을 움직인다(A). 멀티모달 파운데이션 모델이 몸을 얻는 것이다. **공간 지능(Spatial Intelligence)**은 페이페이 리(ImageNet의 창시자, World Labs 설립자)가 이끄는 같은 방향의 흐름 — “언어는 인간이 상호작용하는 소통 방식의 하나일 뿐, 인간은 시각·청각·촉각 등으로 물리적 공간과 상호작용한다”는 문제의식에서 출발해, 3차원 공간의 구조와 물리를 이해하는 **거대세계모델(Large World Model, LWM)**을 목표로 한다.
이 흐름 전체의 밑바탕에는 모라벡의 역설이 깔려 있다 — 인간에게 쉬운 것이 AI에게 어렵고 그 반대도 마찬가지다. 슬라이드는 이를 감각 대역폭의 숫자로 보여준다: 인간이 평생(하루 11시간 깨어 있다고 가정) 듣는 단어는 약 7.5조 개로, 청각 신경(달팽이관 신경섬유 3만 개)이 받아들이는 총 정보량(약 1,152조)에 비하면 극히 일부다. 텍스트로 들어오는 정보는 세계가 우리 감각에 쏟아붓는 정보의 빙산의 일각이라는 것 — 언어모델이 놓치는 것의 크기를 가늠하게 하는 수치다.
Physical AI / On-Device AI
Physical AI는 디지털 지능을 물리 세계로 확장하는 흐름의 총칭이다: 자율주행, 휴머노이드, AI 글래스, AI PC, 스마트 가전. 엔비디아는 이 흐름을 위한 풀스택을 깔고 있다 — Cosmos(월드 파운데이션 모델 플랫폼), Isaac(CUDA 가속 로봇 개발 플랫폼, ROS 연동), Omniverse/OVX(물리적으로 정확한 디지털 트윈 시뮬레이션, OpenUSD 기반), 차량용 중앙집중 컴퓨터 Drive Thor(Blackwell 아키텍처에 트랜스포머·LLM 워크로드 통합)가 그것이다. 시뮬레이션이 핵심인 이유는 분명하다 — 로봇·자율주행 인식 모델을 현실에서 직접 부딪혀 학습시키는 대신, 고충실도 센서 시뮬레이션과 폐쇄 루프 테스트로 안전하게 검증할 수 있기 때문이다. 테슬라(FSD/Optimus), 삼성전자(두뇌 Exynos/ASIC – 시각 ISOCELL Vizion – 촉각 센서의 휴머노이드 수직 계열화)도 같은 판에 들어와 있다.
온디바이스 AI는 8장의 인프라 문제와 직결된다. 모든 추론을 데이터센터로 보내면 지연·프라이버시·에너지 문제가 생긴다. NPU를 단 기기에서 작은 모델을 직접 돌리는 것 — 7장의 양자화·LoRA·MoE가 여기서 실용 기술이 된다. 엔비디아 Project DIGITS(2025, $3,000 예상)는 이 방향의 상징적 제품이다: GB10 슈퍼칩(FP4에서 최대 1페타플롭)에 128GB 통합 메모리를 얹어, 책상 위 표준 콘센트만으로 최대 2,000억 파라미터(두 대 연결 시 4,050억) 모델을 돌린다. 추론 병목이 커지면서 학습용 프로세서가 추론에 동원되고, 전성비 높은 ASIC/NPU와 HBM4·CXL·PIM 메모리 수요가 함께 늘고 있다.
약속과 현실의 간극도 정직하게 봐야 한다. 시연 영상의 백덤블링과, 공장에서 8시간 동안 같은 작업을 안정적으로 수행하는 것 사이에는 깊은 골이 있다. 카르파시는 자율주행이 그토록 오래 걸린 이유로 **“데모와 제품 사이의 매우 큰 격차(demo-to-product gap)“**와 경제성을 든다 — 게다가 “원격 조작 센터”는 사람을 제거한 것이 아니라 보이지 않는 곳으로 옮겨 놓은 것일 뿐이라고 꼬집는다(철도·통신 버블의 재연). 멀티모달 LLM은 시계 읽기(CLOCKBENCH)나 도형 인식(Forgotten Polygons — “도형맹”)처럼 인간에게 쉬운 시각 과제에서 여전히 인간에게 진다. 모라벡의 역설은 여전히 유효하다 — 체스는 쉽고, 컵 잡기는 어렵다. 6장의 예쁜꼬마선충(뉴런 302개)의 유연한 적응력조차 아직 완전히 재현하지 못한다.
참고 논문
- lecun-2022-a-path-towards-autonomous-machine — 자율 기계 지능을 위한 JEPA 청사진
- maes-2026-leworldmodel-stable-end-to-end-joint-embedding-predictive — 안정적 종단간 세계 모델 구현 연구
- brooks-1991-intelligence-without-representation — 표상 없는 체화 지능, Physical AI의 사상적 선조
논쟁거리
바이브 코딩과 Physical AI의 한계는 무엇일까요? 코드의 추상화가 자연어 단계까지 도달했을 때, 소프트웨어 엔지니어의 역할과 ‘코딩’의 정의는 어떻게 달라질까요?
바이브 코딩의 한계는 역설적으로 그 강점에서 나온다. 자연어는 모호해서 인간에게 편하고, 모호해서 명세(specification)로는 위험하다. “결제 기능 만들어줘” 한 문장 뒤에는 동시성, 보안, 규제 준수 같은 수백 개의 암묵적 요구가 숨어 있다. 에이전트는 그럴듯하지만 틀린 코드를 자신 있게 만들고(7장의 환각), 검증 없는 바이브 코딩은 기술 부채를 광속으로 쌓는다. “빨리 만드는 능력”과 “옳게 만들었는지 아는 능력”의 격차 — 이것이 새로운 디지털 격차다.
엔지니어의 역할은 ‘코드 작성자’에서 ‘명세자·검증자·아키텍트’로 이동할 가능성이 높다. 컴파일러가 어셈블리 프로그래머를 없앤 것이 아니라 더 높은 추상화 수준의 프로그래머를 만들었듯이.
Physical AI의 한계는 더 물질적이다. 소프트웨어는 복제 비용이 0이지만 로봇은 한 대씩 만들어야 하고, 시뮬레이션과 현실의 간극(sim-to-real gap)은 좁혀질 뿐 사라지지 않으며, 물리 세계의 실패는 되돌릴 수 없다 — 6장의 토론(시뮬레이션과 생명체의 차이)이 공학 문제로 돌아온 것이다.
이 모든 한계는 하나의 새로운 모순으로 수렴한다. 우리는 토대 위에서 직접 만드는 법을 익혔고(바이브 코딩), 언어의 그림자를 벗어나 물리 세계로 나아가는 길도 보았다(월드모델·VLA·Physical AI). 그런데 그 답을 얻는 순간 더 무거운 질문이 따라온다. 자연어 명세는 모호하고, 환각은 검증 없는 코드로 기술 부채를 쌓으며, 행동하는 AI일수록 — 코드를 실행하고 주문을 넣고 몸을 움직일수록 — 실패의 대가가 커진다. 말을 잘하는 AI의 위험은 말이지만, 행동하는 AI의 위험은 결과다. 그래서 더 똑똑한 AI가 아니라, 멈출 줄 아는 AI가 필요해진다. MCP의 승인 팝업이 작은 차단기(circuit breaker)였다면, 이제 필요한 것은 책임 자체를 설계 원리로 끌어올리는 일이다. 행동하는 AI일수록 차단기(통제)와 책임 설계가 절실해진다. 그 종합적 성찰로 — 다음 장(10장, 책임 있는 AI)으로 넘어간다.