인프라는 빅테크가 깐다, 에이전트는 우리가 짠다

2백만 장이 보내는 신호

아마존이 엔비디아 GPU를 200만 장 추가 발주했다. 기존 주문의 세 배. 단순 조달 뉴스로 읽으면 절반만 본 거다.

추론 수요가 폭발하면 반드시 따라오는 게 있다. 경쟁과 규모의 경제. AWS, Azure, GCP가 동시에 인프라를 늘리면 클라우드 API 가격은 결국 내려간다. Claude Haiku 3는 출시 초기 대비 지금 토큰당 단가가 절반 이하로 떨어졌다. 200만 장의 GPU가 추가로 깔리면 그 흐름은 더 빨라진다.

작은 팀에게 이 뉴스의 의미는 하나다. "쓸 수 있는 추론 용량이 늘고, 비용은 내려간다." 에이전트를 짜기 좋은 시절이 빠르게 오고 있다는 신호다. 단 — 이걸 그대로 실행에 옮길 때 가장 많이 삽질하는 지점은 compute 부족이 아니라 설계 실수라는 것도 함께 알고 가야 한다.

병목은 GPU 가격이 아니다

AI안경 특이점 왔농이라는 말이 돌 만큼 요즘 AI 기기·서비스가 쏟아진다. 그런데 실제로 에이전트를 짜보면 전혀 다른 벽을 만난다. GPU가 없어서 못 하는 게 아니다. 어디에 LLM을 붙여야 하고, 어디는 붙이면 안 되는지 판단이 안 서서 허비하는 시간이 훨씬 길다.

우리 팀은 현재 15개 이상의 봇을 운영한다. 처음엔 모든 봇에 LLM을 붙이면 더 스마트해질 거라고 생각했다. 직접 해보니 고정 템플릿이 더 안정적인 케이스가 훨씬 많았다. 소셜 포스팅 봇은 DB 실데이터 + 고정 포맷으로 돌린다. 환각이 끼어들 여지가 없고, 실행 속도는 빠르고, LLM 비용은 0이다. 반면 콘텐츠 검수 루프는 사람 수준의 판단이 필요한 지점이라 LLM 없이는 구조 자체가 성립 안 된다.

에이전트 설계의 첫 번째 원칙은 결국 "LLM이 판단을 대체할 때만 투입한다"는 것이다.

Haiku와 Sonnet 사이의 경계선

우리 봇은 LLM을 두 계층으로 쓴다. 콘텐츠 생성에는 Claude Haiku, 검수·판단에는 Claude Sonnet. 처음엔 비용 때문에 이 구분을 뒀는데, 지금은 역할 때문에 유지한다.

수치를 보면 직관적이다. Haiku는 Sonnet 대비 토큰당 가격이 약 20분의 1 수준이다. 하루 15개 봇이 각자 수천 토큰짜리 본문을 생성하면 이 차이는 월 단위로 눈에 보인다. 그런데 생성은 Haiku로 해도, 검수만큼은 절대 Haiku에게 맡기면 안 된다는 걸 직접 확인했다.

검수 루프는 5초마다 폴링해서 새 발행 후보를 잡고, Sonnet이 PUBLISHED/REJECT/WARN 셋 중 하나를 판정한다. REJECT가 나오면 자동으로 ARCHIVED 처리된다. 이 루프를 도입하기 전에는 허위성이 높은 콘텐츠가 실제로 발행되는 사고가 있었다. 멤버 포토카드 버전이나 가짜 컴백 데이터가 뉴스로 올라간 케이스가 대표적이다. 그 이후로 Haiku로 생성하고 Sonnet으로 판단하는 구조를 코드 레벨에서 강제했다. 비용과 품질의 트레이드오프를 모델 선택 자체로 구현하는 방식이다.

에이전트는 LLM 호출이 아니라 상태 기계다

에이전트를 처음 짜는 팀이 자주 하는 실수가 있다. "LLM을 호출하는 것"이 곧 에이전트라고 생각하는 것. LLM 호출은 부품 하나일 뿐이고, 진짜 설계는 그 주변 상태 기계에 있다.

우리 검수 루프를 예로 들면 구조가 보인다. 새 글 감지 → LLM 호출 → 결과 파싱 → 상태 전이(PUBLISHED/ARCHIVED/WARN) → 디스코드 알림 발송. LLM은 이 중 한 스텝만 담당한다. 나머지는 DB 상태 관리, 재시도 로직, 알림 라우팅이다. 에이전트가 프로덕션에서 죽는 지점은 대부분 LLM 호출 품질 문제가 아니라 그 주변 인프라다.

실제로 가장 골치 아팠던 버그는 LLM 응답이 이상해서가 아니었다. MySQL 연결이 LLM 호출 대기 중에 idle timeout으로 끊기는 문제였다. LLM 응답에 수 분이 걸릴 수 있는데, MySQL wait_timeout이 300초라 그 사이 연결이 끊겨버린다. (2013, 'Lost connection') 에러로 봇이 폭사하는 패턴. 해결책은 LLM 프롬프트를 더 영리하게 쓰는 게 아니라, DB 연결을 ping(reconnect=True)로 감싸는 것이었다. 에이전트 설계의 실질적 복잡도가 어디 있는지를 보여주는 사례다.

"어떤 프롬프트를 쓸까"보다 "LLM 응답 전후에 시스템이 어떤 상태여야 하는가"가 훨씬 어려운 문제다.

지금 바로 적용 가능한 에이전트 패턴 세 가지

아마존이 GPU를 쌓는 동안 설계 원칙을 잡아두면 된다.

판단이 반복적으로 필요한 지점을 먼저 찾아라. 매일 같은 기준으로 무언가를 걸러내거나, 분류하거나, 승인하는 업무가 있다면 에이전트 후보다. 그 판단을 사람이 매일 하고 있다면, 비용 대비 투자 가치가 가장 높은 자리다.

LLM 호출 1개짜리 미니 에이전트부터 시작해라. 입력을 받아 분류만 하는 단순한 것부터. 프롬프트 작성과 응답 파싱 패턴이 안정화되면 거기에 상태 관리와 액션을 붙이는 게 훨씬 쉽다. 처음부터 멀티스텝 에이전트를 짜면 어디서 깨지는지 파악이 안 된다. 우리도 검수 루프를 처음에 단순 분류기로 시작해서 점진적으로 확장했다.

생성 모델과 판단 모델을 반드시 분리해라. 본문 생성처럼 속도와 비용이 중요한 태스크는 경량 모델로, 품질 판단·검수처럼 정확도가 임계값인 태스크는 더 강한 모델로. 이 구분만 해도 비용은 10배 이상 아끼면서 품질을 유지할 수 있다. 모든 스텝에 Sonnet을 붙이는 건 GPU가 싸져도 낭비다.

추론 비용이 내려가면 에이전트 도입의 경제적 허들이 낮아진다. 그 타이밍에 설계 원칙 없이 뛰어들면 싼 API로 비싼 실수를 한다. GPU가 쌓이는 속도보다 에이전트를 잘 짜는 팀이 더 드물다 — 그게 지금 진짜 희소 자원이다.

원문: AI News & Artificial Intelligence | TechCrunch