내 'AI 비서'와, 테슬라 '자율주행 AI' 평행이론

'잠자는 클라우드'를 깨워, 나만의 'AI 요새(VM)'를 짓기까지

by SunnyPark

1. 갑자기 웬 테슬라?

요즘 한국 IT 뉴스는 온통 테슬라의 자율주행, FSD(Full Self-Driving) 이야기로 뜨겁습니다. "드디어 한국에도 1억 넘는 모델 S, X부터 FSD가 풀린다", "아니다, 아직 멀었다" 등등 왈가왈부 말들이 많죠.


AI 에이전트를 개발하고 있는 저로서도 이 이슈를 그냥 지나칠 수 없었습니다. 도대체 저 자동차의 AI는 어떻게 작동하길래 저렇게 난리일까? 호기심에 FSD의 작동 원리를 깊이 파고들던 저는, 제 모니터 속 AI 비서와 테슬라 자율주행 사이에 존재하는 소름 돋는 평행이론을 발견했습니다.


이번 글은 지난주 야심 차게 도입했던 클라우드 최신 기술 '서버리스(Serverless)'를 과감히 버리고, 투박하지만 든든한 클라우드 '가상머신(VM)'으로 회귀하게 된 결정적인 이유. 그리고 그 과정에서 얻은 '테슬라 FSD'에 대한 통찰을 나누려 합니다.


2. 백과사전(LLM) vs. 카레이서(Physical AI)

내 AI 비서와 테슬라 FSD의 평행이론을 이야기하기 앞서, 먼저 두 AI의 차이점을 짚고 넘어가야 했습니다. 둘 다 '인공지능'이라 불리지만, 사실 이들은 완전히 다른 종족입니다.

나의 AI (LLM) = 백과사전: 텍스트를 이해하고 '다음 말'을 예측하는, 지식 노동을 위한 거대 언어 모델입니다. 세상의 모든 지식을 머릿속에 담고, 인터넷이라는 무한한 바다를 항해하는 '거대 언어 모델'이죠.

테슬라 AI (Physical AI) = 카레이서: 카메라 영상을 보고 '다음 행동(조향, 가속)'을 예측하는, '엔드투엔드 뉴럴 네트워크(End-to-End Neural Network)' 기반의 물리 AI입니다. 이를 '거대 행동 모델(Large Action Model)' 혹은 세상을 이해하는 '월드 모델(World Model)'이라 칭하더군요.

하나는 '말'을 잘하고, 하나는 '행동'을 잘합니다. 하지만 '작동 방식의 진화'를 들여다보면 둘은 놀랍도록 닮아있습니다.


3. 규칙(Rule)을 버리고 '직관'을 얻다

테슬라 FSD v12의 혁신은 30만 줄이 넘는 코드(규칙)를 걷어내고, 그 자리를 거대 신경망 하나로 채운 것입니다. "빨간불이면 멈춰"라는 명령(Code) 대신, "사람들은 저기서 멈추네?"라는 학습(Learning)을 통한 판단을 하는 것이죠.

[표 1] 테슬라 자율주행의 진화: 규칙에서 학습으로

놀랍게도, 제 방구석 연구실에서도 똑같은 변화가 일어났습니다. 초기에는 저도 "일정이라고 말하면 캘린더를 켜"라고 일일이 코딩했습니다. 하지만 지금 제가 구축한 MCP(AI Agent) 시스템은 다릅니다. 저는 더 이상 순서를 정해주지 않습니다. 그저 '도구 상자(Tool Box)'만 던져주면, AI가 스스로 판단해서 도구를 꺼내 씁니다.

[표 2] AI 개발 방식의 변화: 명령에서 자율로


4. 우리의 오랜 로망, '전격 Z작전'의 키트

나의 AI (LLM) 와 테슬라 AI(FSD) 이 두 가지를 보면서 제 머릿속을 스치는 추억의 미드가 하나 있었습니다.


기억하시나요? 주인공 마이클과 함께 악당을 물리치던 검은색 슈퍼카, '키트(K.I.T.T.)'를요.

키트는 혼자서 운전도 기가 막히게 했지만(Tesla FSD/Physical AI), 주인공과 농담도 주고받고 상황을 분석해 주는 최고의 파트너(LLM)이기도 했습니다.

"그래, 내가 만들고 싶은 건 바로 저건가?"

테슬라가 '운전하는 몸(Physical AI)'을 완성해가고 있다면, 저는 그 안에 들어갈 '생각하고 대화하는 두뇌(LLM)'를 만들고 있는 셈입니다. 이 두 가지가 합쳐져야 비로소 진정한 의미의 '키트'가 탄생할 테니까요.


5. 위기: 똑똑한 뇌, 기억상실증에 걸린 몸

나의 LLM AI Agent (소프트웨어)는 이렇게 '자율적이고 연속적인 지능'으로 진화했는데, 정작 이를 담고 있는 그릇(인프라)이 문제였습니다.


지난주 제가 적용했던 '서버리스(Serverless)' 기술은 이론적으로 완벽해 보였습니다. "평소에는 꺼져 있다가, 제가 부르면 0.1초 만에 켜져서 일을 처리한다." 비용도 아끼고 효율적인, 마치 '필요할 때만 출근하는 스마트한 아르바이트생' 같았죠.


하지만 현실은 달랐습니다. 제가 "이메일 좀 찾아줘"라고 말을 걸면, AI는 바로 대답하지 못하고 3초, 5초... 멍하니 침묵했습니다. 전문 용어로 '콜드 스타트(Cold Start)'라고 부르는 현상입니다. 깊이 잠들어 있던 서버가 눈을 비비고 일어나 부팅하는 데 걸리는 시간이었죠.


사실 '느리다(Cold Start)'는 참을 수 있었습니다. 하지만 제가 서버리스(Cloud Run)를 포기하고 VM으로 돌아선 진짜 이유는 따로 있었습니다. 바로 '연결의 불연속성', 쉽게 말해 '치매' 현상 때문입니다.


일반적인 웹사이트는 괜찮습니다. 제가 웹사이트 뉴스를 클릭할 때, 서버 A가 응답하든 B가 응답하든 상관없으니까요. (Stateless)

하지만 AI 에이전트(MCP)는 다릅니다. Client/Server구조의 우리는 계속해서 대화를 주고받아야 합니다. (Stateful)

[그림 A] 서버리스의 혼란 (The Chaos of Serverless)

[문제의 발생 과정] 제가 겪은 서버리스 아키텍처의 문제는 이렇습니다. (위 그림 A 참고)

1.제가 Claude에게 "내 일정 확인해 줘"라고 요청을 보냅니다.

2.구글의 로드 밸런서(Load Balancer)가 이 요청을 받아 '인스턴스 1번'에게 연결해 줍니다. 통신이 시작됩니다.

3. 잠시 후, "그 일정 취소해 줘"라고 두 번째 요청을 보냅니다.

4. 그런데 로드 밸런서는 효율성을 따지며 이 요청을 뜬금없이 '인스턴스 2번'으로 보내버립니다.

5. 인스턴스 2번: "네? 무슨 일정이요? 전 처음 듣는 얘기인데요?"

6. 결과: 세션(Session) 불일치 오류 발생. 대화는 끊기고, 에이전트는 바보가 됩니다.


물론 저도 이 문제를 그냥 두고 보지만은 않았습니다. 클라우드에서 추천하는 '세션 어피니티(Session Affinity)' 기능을 활성화해 보았습니다.

쉽게 말해, 로드 밸런서에게 "방금 통화한 그 상담원(인스턴스 1번)에게 계속 연결해 줘"라고 '지정'하는 기능입니다. 이론상으로는 문제가 해결되어야 했습니다.

하지만 '야생'과 같은 서버리스 환경에서는 이마저도 원활하게 작동하지 않았습니다. 서버리스의 특성상 사용자가 조금만 뜸을 들이면 인스턴스가 멋대로 사라지거나(Scale In), 트래픽이 몰리면 새로운 인스턴스가 갑자기 튀어나오는(Scale Out) 등 변화가 너무 심했기 때문입니다.

결국 '지정된 상담원'이 예고도 없이 자꾸 퇴근해버리는 상황 앞에서, 세션 어피니티(Session Affinity)도 무용지물이었습니다.

[그림 B] VM의 안정성 (The Stability of VM)

그래서 저는 결단을 내렸습니다. 수많은 상담원(Container Instance)이 번갈아 응대하는 서버리스 시스템을 버리고, 오직 나만을 위해 24시간 대기하는 단 한 명의 비서, '가상머신(VM)'을 채용하기로 했습니다. (위 그림 B 참고)


VM(Compute Engine) 구조의 핵심:

단일 인스턴스 (Single Instance): 로드 밸런서의 변덕 없이, 내 PC와 서버가 1:1로 직접 연결됩니다.

세션 유지 (Session Persistence): 한번 연결되면 내가 끊을 때까지 그 연결은 유지됩니다. 10분 전에 말한 내용도, 1시간 전에 시킨 일도 '같은 서버'가 기억하고 처리합니다.


참고로, 테슬라 자동차는 인터넷이 끊겨도, 터널 속에서도 자율주행이 가능합니다. 왜일까요? 그들은 판단을 내리는 거대한 'AI 두뇌(칩)'를 클라우드 서버에 두지 않고, 자동차 안에 직접 심어두었기 때문입니다. 테슬라의 AI는 제한된 감각을 가집니다. 차에 달린 카메라가 보내주는 영상 정보로 외부의 도움 없이(인터넷이 끊겨도) 독자적으로 생존해야 하기 때문입니다. 만약 테슬라가 제가 썼던 '서버리스' 방식을 썼다면 어땠을까요? "앞에 사람이 나타났습니다. 멈출까요?" 라고 묻고, 서버가 잠에서 깨어나 "어, 멈춰!"라고 답을 보낼 때쯤이면 이미 사고가 났을 겁니다.

여기에서 테슬라에게 배웠습니다. 진정한 지능형 에이전트(Agent)란, 단순히 똑똑한 것을 넘어 '언제든 즉각 반응할 준비(Always-on)'가 되어 있어야 한다는 것을요.

물론 결정적인 차이점은 있습니다. 제가 만드는 AI 에이전트는 무한한 지식과 연결을 추구하고, 단순히 아는 것에서 그치지 않고 네트워크를 통해 Gmail, 캘린더, 슬랙, 세일즈포스 같은 외부 도구(API)를 다루고 처리해야 하는 개인용 비서 또는 엔터프라이즈 솔루션이기 때문에, 네트워크에 연결되면서도 즉시 반응을 할수 있어야 하겠죠.


6. 마치며: '전격 Z작전'의 키트

이제 클라우드의 불안정한 단기 전세집(서버리스)을 떠나, 튼튼한 '요새(VM)'에 입주를 마쳤습니다.

이곳은 Client/Server 모델에 최적화되어 있으며, 다양한 툴들을 효율적으로 연결하는 MCP 서버가 24시간 깨어있는 공간입니다. 이제 이 안정적인 기반 위에서, 그동안 파편화되어 있던 영업 비서, 일정 비서, IT 헬프데스크등을 하나로 통합하는 일입니다.


AI 공부를 하고 실행을 해 보면 예상치 못한 기술적 난관에 부딪히지만, 기존 기술과 새로운 기술을 조합해 해법을 찾아가는 그 과정 자체를 즐기려 합니다. 단순히 이론만 설계만 하는 것이 아니라, 직접 부딪히며 하나하나 만들어가는(Learning by Building) 이 치열한 기록에 여러분도 계속 동참해 주시기 바랍니다.


이전 05화실험실AI 두뇌, 클라우드라는 '새 몸'을 얻다