AI 에이전트가 느릴수록 청구서는 먼저 불어난다

에이전트가 느릴수록 토큰 청구서가 먼저 불어난다

저커버그가 사내 미팅에서 인정했다. AI 에이전트 개발이 기대만큼 빠르게 진행되지 않고 있다고. 메타는 2025년 AI 인프라에만 600억~650억 달러를 쏟아붓기로 했다. 그 규모로도 에이전트는 느리다.

이 고백을 인프라 비용의 시각으로 읽으면 다른 문제가 보인다. 에이전트는 실패할수록 토큰을 더 소비하는 구조다. 메타처럼 무제한 재시도를 쏟아부을 수 있는 팀이 아니라면, 그 실패 비용은 고스란히 API 청구서로 돌아온다.

단, 이걸 "에이전트는 작은 팀엔 아직 멀었다"는 결론으로 읽으면 절반만 맞다. 진짜 교훈은 반대쪽에 있다 — 처음부터 한계를 설계하면 오히려 안정적으로 작동한다. 다만 그 설계를 잘못 짜면 비용이 의도치 않게 폭주하는 지점이 있는데, 그게 어디인지 구체적으로 짚겠다.

LLM 호출 한 번에 실제로 얼마가 나가나

먼저 숫자를 보자. Claude Haiku로 블로그 글 한 편을 생성하면 입출력 합산 약 1,5002,000토큰. 현재 요금 기준으로 편당 $0.0030.005, 한화로 4~7원 수준이다.

하루 10편, 12개 사이트를 운영하면 하루 120편, 한 달 3,600편. 여기까지는 월 1만~2만 원 선으로 충분히 관리된다.

문제는 에이전트를 붙일 때다. "계획 → 초안 생성 → 품질 판단 → 수정 → 재검토"처럼 멀티스텝으로 구성하면 글 한 편에 LLM 호출이 48회로 늘어난다. 재시도가 발생하면 더 늘어난다. 같은 글 한 편이 $0.020.05가 된다. 단순 생성 대비 10배 이상 뛰는 것이다.

월 3,600편 기준으로 다시 계산하면 — 단순 haiku 생성은 월 2만 원이지만, 멀티스텝 에이전트는 월 20~30만 원이다. 사이트 수가 늘고 발행 빈도가 높아지면 선형으로 올라간다.

저커버그가 말한 "기대보다 느리다"는 것은 이 비용 구조와 분리되지 않는다. 에이전트가 태스크를 한 번에 완수하지 못하면 재시도하고, 재시도마다 토큰이 나간다. 메타 규모에서는 허용 가능한 실험 비용이지만, 연간 수익이 수억 원인 팀에서는 다른 이야기다.

범위가 좁으면 비용이 예측 가능해진다

저커버그가 목표한 에이전트와 우리가 실제로 쓰는 에이전트는 범위가 다르다. 그 차이가 중요하다.

글을 생성하고, 길이 기준을 판단하고, 미달이면 재생성하고, 검수 모델이 품질을 평가하는 구조 — 이건 이미 에이전트다. 단지 범위가 좁고, 각 단계의 상한이 코드로 박혀 있을 뿐이다.

이게 핵심이다. 범위가 좁으면 비용이 예측 가능하다. "글 한 편당 최대 haiku 2회, sonnet 1회"처럼 상한을 코드로 강제하면 토큰 비용이 폭주하지 않는다.

1,500자 미달 시 재생성 1회 제한 로직이 그 구체적인 사례다. 재시도를 무제한 허용하지 않고 한 번으로 잘랐다. 재시도 발생률이 15%라면 전체 토큰 비용이 15%만 증가한다. "무한 재시도 후 스킵" 패턴과 비교하면 비용 예측성에서 완전히 다른 레벨이다. 메타의 에이전트가 막히는 이유 중 하나는 상한 없는 자율성을 목표로 했기 때문이고, 우리는 그 실수를 처음부터 피할 수 있다.

AI 개발용 PC, 온프레미스가 실제로 의미 있는 경우

AI 인프라 비용 얘기가 나오면 요즘 빠지지 않는 주제가 로컬 추론이다. RTX 4090 탑재 AI 개발용 PC 한 대로 Llama 3.3 70B, Mistral, Phi-4 같은 오픈소스 모델을 API 없이 돌리는 것.

수치를 냉정하게 따져보자. RTX 4090 조립 PC 한 대에 300~350만 원, 전기세 포함 월 유지비 3만 원 안팎이다. 앞서 계산한 단순 생성 비용이 월 2만 원이라면, 이 PC는 API를 완전히 대체해도 손익분기점에 15년이 걸린다. 단순 생성 비용 절감 목적으로는 경제성이 없다.

다만 다른 용도가 있다. 로컬 추론이 빛나는 건 고반복·저품질 요구 작업이다. 크롤 데이터 카테고리 분류, 키워드 클러스터링, 중복 탐지, 이미지 캡션 생성 — 이런 작업은 Claude Sonnet급 품질이 필요 없다. 8B짜리 로컬 모델로 충분히 처리된다. 이 작업을 클라우드 API로 처리하면 건당 단가는 낮아도 건수가 수만 건을 넘어서면 누적 비용이 나온다. 새 사이트 초기 콘텐츠 배치 생성, 대규모 크롤 데이터 정제 — 이런 구간에 AI 개발용 PC를 붙이면 ROI가 달라진다.

함정도 있다. 로컬 모델은 프롬프트 엔지니어링 민감도가 높다. 클라우드 대형 모델은 다소 모호한 지시도 알아서 해석하지만, 7B~13B 모델은 지시가 조금만 불명확하면 결과가 흔들린다. 유지 관리 오버헤드가 생긴다. 팀 인원이 적을수록 이 오버헤드가 예상보다 크다. "서버 한 대 더"는 관리해야 할 서버 한 대 더다.

우리 팀이라면 지금 이렇게 비용 구조를 짠다

현재 구조를 다시 보면 — haiku로 본문 생성, sonnet으로 검수, REJECT가 나오면 게시 취소다. 단순하고 비용 예측이 쉽다.

여기서 한 단계 더 최적화한다면 sonnet 검수 전에 규칙 기반 사전 필터를 넣는다. 길이, 금지어 포함 여부, 최소 섹션 수, 마크다운 구조 깨짐 — 이런 건 LLM 없이 코드로 잡힌다. REJECT 사유의 3040%가 이런 기계적 오류라면, 그만큼 sonnet 호출 횟수가 줄어든다. sonnet은 haiku보다 약 1215배 비싸다. 검수 10회를 7회로 줄이는 것만으로도 누적 비용이 의미 있게 달라진다.

에이전트 영역을 확장하고 싶을 때도 같은 원리다. "에이전트 도입" = "LLM이 알아서 다 결정한다"가 아니라, "각 결정 지점마다 최소 비용 모델을 배치하고, 상한 호출 횟수를 코드로 박는다"로 읽어야 한다.

AI 개발용 PC는 이 흐름에서 특정 구간에만 투입한다. 새 사이트를 추가할 때 초기 콘텐츠 배치 생성이나 대규모 크롤 데이터 정제처럼 건수는 많고 품질 요구는 낮은 작업. 그 구간에 로컬 추론을 붙이면 ROI 계산이 실제로 나온다. 범용 대체가 아니라 구간 선택이 핵심이다.

지금 바로 써먹을 수 있는 시사점

토큰 예산을 코드로 강제하라. 에이전트 로직을 짤 때 "최대 N회 LLM 호출" 상한을 프롬프트 지시가 아니라 if문으로 박는다. 재시도 루프에 카운터를 넣는 것, 간단하지만 비용 폭주를 막는 가장 확실한 방법이다.

sonnet은 진짜 판단이 필요할 때만 쓴다. 구조·형식·길이 검증은 코드로, 주제·품질·논리 판단만 sonnet으로 분리한다. sonnet 호출 횟수를 로그로 찍고 한 달에 한 번 리뷰하는 것만으로도 최적화 지점이 눈에 보인다.

AI 개발용 PC는 생성이 아닌 전처리에 배치하라. 단가 낮고 건수 많은 분류·정제 작업이 있다면, 그게 로컬 추론의 경제성이 나오는 구간이다. 처음부터 API 비용과 PC 유지비를 비교한 스프레드시트를 만들어두면 판단이 빠르다.

저커버그의 고백을 비용 경보로 읽어라. 에이전트가 아직 기대 이하라는 것은, 에이전트 인프라에 먼저 투자한 팀들이 지금 기대 이하의 ROI를 보고 있다는 뜻이기도 하다. 지금 시점에서 가장 현실적인 전략은 검증된 구간부터 조금씩 확장하는 것 — 규모가 작을수록 이 판단이 오히려 더 정확하다.

원문: AI News & Artificial Intelligence | TechCrunch