SpaceX AI 기기가 드러낸 에이전트 설계의 진짜 문제

기기 얘기가 아니다

SpaceX가 상장 전 투자자들에게 "핸드셋처럼 생긴" AI 기기 프로토타입을 공개했다. TechCrunch가 7월 1일 보도한 내용인데, 공식 발표도 없고 스펙도 베일에 싸여 있다. 기기인지 아닌지조차 아직 불분명하다.

그런데 이 모호한 소식이 흥미로운 건 따로 있다. Starlink 위성 통신망 위에서 항상 연결된 상태로 동작하는 AI 기기 — 이 구도에서 SpaceX가 그리는 게 "폰에 챗GPT를 올린 것"이 아니라는 점이다. 사용자 요청을 중개하는 앱이 아니라, 요청을 직접 처리하고 결과를 실행하는 에이전트가 기기의 핵심이다. 껍데기 안에 에이전트가 있는 게 아니라, 에이전트를 위한 껍데기가 기기다.

이 구분이 작은 팀에게 중요한 이유가 있다. 지금 LLM을 업무에 붙이는 방식이 "챗GPT 활용 분야 확장"이나 "자동화 스크립트에 API 추가" 수준에 머물러 있다면, 에이전트의 실제 효용은 아직 꺼내지 못한 것이다. 솔직히 말해, 대부분의 작은 팀이 그 경계 바로 앞에 있다. 뒤에 설명할 함정들을 모르고 경계를 넘으면 조용히 깨진다.

LLM 호출과 에이전트는 다르다

챗GPT 활용 분야를 크게 나눠보면 단발성과 연속성으로 갈린다. "초안 작성", "번역", "요약" — 이건 단발 LLM 호출이다. 입력 → 출력, 거기서 끝. 상태가 없고, 연속성이 없고, 외부 시스템과의 연동도 없다.

에이전트는 다르다. 목표를 받고, 상태를 유지하면서, 조건에 따라 다음 행동을 결정한다. 중간에 실패하면 재시도하고, 외부 시스템에 결과를 쓰고, 그 결과를 보고 다음 단계를 트리거한다. 단발과 에이전트의 경계는 흐릿해 보이지만 만들어본 팀은 안다 — 단계 사이의 "대기 구간"이 모든 걸 복잡하게 만든다는 것을.

우리 팀이 운영하는 콘텐츠 봇들이 딱 그 경계에 있다. 크론이 발화하면 크롤링 → LLM 생성 → 검수 → 발행. 단발 호출이 아니라 여러 단계가 연결된 파이프라인이다. 그런데 이걸 진정한 에이전트라고 부르기엔 아직 부족하다. 각 단계 사이의 의사결정 로직이 얼마나 촘촘한지, 실패 시 어떻게 복구하는지가 관건이다.

실전에서 에이전트가 깨지는 곳

가장 흔하게 깨지는 구간은 대기 구간이다. LLM 호출에 수 초에서 수십 초가 걸리고, 여러 호출이 연달아 이어지면 그 사이 외부 연결이 죽는다.

2026년 6월 29일, kpopdex discover_groups 봇이 LLM 호출 사이에 MySQL 연결이 idle timeout으로 끊기면서 (2013, 'Lost connection') 에러로 멈췄다. 관리형 MySQL의 wait_timeout이 300초 — LLM 여러 번 호출하면서 5분을 넘기면 DB가 조용히 연결을 잘라버린다. 봇은 이를 모른 채 다음 쿼리를 날리고, 그 순간 폭사한다. 발행이 멈추고, 경보도 없고, 로그만 남는다.

해결은 단순했다. DB 연결을 헬퍼로 감싸서 cursor를 열기 직전마다 ping(reconnect=True)를 치게 했다. 코드 10줄 남짓. 그런데 이 10줄을 배우기까지 실제 운영 장애가 필요했다는 게 포인트다.

에이전트를 설계할 때 정상 흐름만 그리면 안 된다. 각 단계 사이 대기 구간에서 외부 시스템이 어떻게 죽는지, 그걸 어떻게 탐지하고 복구하는지가 먼저다. SpaceX의 AI 기기도 결국 같은 문제를 다른 규모에서 마주한다. 위성 핸드오버 중에 요청이 날아가면, Starlink가 잠깐 끊기면 — 에이전트는 어떻게 복구하는가. "항상 켜있는 에이전트"가 어려운 이유는 AI 알고리즘이 아니라 이 복구 로직에 있다.

우리 팀이라면 어떻게 설계할까

현재 봇 파이프라인을 에이전트답게 만들려면 세 방향이 보인다.

상태 추적을 코드 밖에서 해야 한다. 지금은 각 봇이 한 번 실행되면 끝이다. 실패해도 다음 크론까지 기억이 없다. 에이전트라면 "이 주제로 이미 2번 재시도했고, 두 번 다 품질 미달이었다"는 정보를 외부 저장소에 남겨야 한다. 사실 우리의 발행 게이트가 이미 비슷한 개념을 구현하고 있다 — 본문 1500자 미달이면 1회 재생성, 그래도 미달이면 발행 스킵. 이 패턴을 더 많은 판단 포인트로 확장하면 진짜 에이전트 루프가 된다.

LLM 판단 위임의 범위도 확장할 수 있다. 지금 review_loop에서 Claude Sonnet이 "OK/REJECT/WARN" 판단을 한다. 이 패턴을 더 앞 단계로 당길 수 있는데, 트레이드오프가 명확하다. Haiku로 판단하면 저렴하지만 오판 확률이 올라가고, Sonnet으로 올리면 정확하지만 비용이 뛴다. 생성은 Haiku, 검수는 Sonnet 이상으로 나누는 현재 구조가 실용적인 타협점이고, 더 정교하게 가려면 판단 종류별로 모델을 달리 쓰는 라우팅이 필요하다. 단순 규칙 위반 체크는 Haiku에 맡기고, 뉘앙스가 필요한 사실 검증만 Sonnet으로 올리는 방식이다.

봇 간 신호 공유도 언젠가는 다뤄야 할 구조 문제다. 지금 봇들은 각자 독립적으로 돈다. kpopdex 봇이 새 컴백을 발견해도 blog 봇은 모른다. 에이전트 시스템이 성숙해지면 이 발견이 공유 큐나 이벤트 스트림으로 흘러서, 하나의 에이전트 결과가 다른 에이전트의 행동을 트리거하게 된다. 당장 구현할 이야기가 아니지만, 지금부터 데이터 구조를 공유 가능하게 설계해두면 나중에 붙이는 비용이 확연히 달라진다.

지금 당장 써먹을 수 있는 것

SpaceX 기기가 언제 나올지는 아무도 모른다. 그게 요점도 아니다.

LLM 호출 사이의 대기 구간을 지금 당장 목록으로 뽑아라. DB 연결, 외부 API 콜, 파일 I/O — 이 중 어느 것이 타임아웃에 취약한지 파악하는 게 먼저다. 재연결·재시도 로직 없이 에이전트를 장기 운용하면 어느 시점에 반드시 조용히 죽는다. 경보도 없이.

판단 포인트를 코드로 강제해라. "LLM이 알아서 해줄 것"을 믿지 말고, 어떤 조건이면 재시도하고 어떤 조건이면 스킵하고 어떤 조건이면 알림을 보낼지를 코드로 명시해라. 프롬프트로 부탁하는 건 까먹을 수 있고, 코드로 박는 건 안 까먹는다. 1500자 게이트가 그 방식이다.

마지막으로, 실패 신호를 쌓아라. 에이전트가 재시도한 횟수, 스킵한 횟수, 판단이 뒤집힌 횟수를 Discord든 DB든 어딘가에 축적해라. 이 숫자가 에이전트를 개선할 유일한 재료가 된다. SpaceX가 프로토타입을 투자자에게 먼저 보여준 것도 결국 같은 이유다 — 실제 피드백 없이 설계만으로는 에이전트를 단련할 수 없다.

원문: AI News & Artificial Intelligence | TechCrunch