390만 토큰짜리 리포트를 40배 싸게 만든 건 모델 교체가 아니었다

에이전트가 느리고 비쌀 때 던질 첫 질문은 "어느 모델로 바꿀까"가 아니다. "지금 모델에게 산수를 시키고 있지 않나" 다.

LangChain이 자사 광고 운영 에이전트를 공개했는데, 거기서 가장 쓸모 있는 숫자는 성과가 아니라 1차 버전의 실패 수치였다. 리포트 하나에 입력 토큰 390만 개, 1,112초, $3. 고친 방법은 모델 교체가 아니라 계산을 코드로 옮긴 것이고, 그 결과가 40배 싸고 13배 빨라졌다.

출처: langchain.com/blog/paid-media-agent

확인된 것

원문에서 확인한 것만 적는다.

• 광고 플랫폼 데이터와 사내 웨어하우스의 리드·파이프라인을 붙여 주간 리포트를 슬랙에 올리고, 후속 질문을 받고, 키워드·타기팅·광고 문구·캠페인 변경을 사람 승인용으로 제안한다.

• 구조는 역할 분담이 명확하다. 코드가 calculations, comparisons, and hard rules를 맡고, 모델은 the work that requires judgment에 집중한다. 광고 플랫폼별로 서브에이전트를 따로 둬서 컨텍스트가 섞이지 않게 한다.

• 1차 버전: 리포트당 입력 토큰 3.9M, 1,112초, $3. 계산을 코드로 옮긴 뒤 40배 저렴, 13배 빠름(18분 → 85초).

• 승인 절차가 승인에서 끝나지 않는다.

  Code then applies the approved change and checks the ad platform to confirm it succeeded.

• 데이터가 안 맞을 때의 원칙도 명시돼 있다. 구글 동영상 캠페인에서 지출이 약 10% 어긋났는데, 그 상태를 그대로 뒀다.

  When data cannot be joined reliably, the agent does not try to fill in the gaps.

• 성과로 제시된 수치: 유료 광고가 6개월 만에 마케팅 파이프라인의 0% → 20%, 6~8월 CPL 30% 감소, LinkedIn CPL은 1월 대비 40% 낮음, 대행사 비용 제거로 월 약 $5,000 절감. 같은 기간 지출은 60% 증가.

판단

1. 토큰 390만 개는 모델 문제가 아니라 설계 문제다

리포트 한 장에 390만 토큰이 들어갔다는 건, 모델이 표를 통째로 읽고 머릿속에서 합계와 증감률을 계산하고 있었다는 뜻이다. 그 작업에 지능은 필요 없다.

그래서 고친 방향이 중요하다. 더 큰 모델도, 더 싼 모델도 아니고 계산을 코드로 내린 것이다. 40배와 13배는 거기서 나왔다.

→ 실행 항목: 내 에이전트의 프롬프트에 들어가는 데이터를 열어보고, 모델이 받아서 계산하는 값과 계산된 뒤에 받는 값을 구분해라. 합계·비교·증감률·임계 판정은 전부 앞쪽에 있으면 안 된다. 비용도 비용이지만, 모델이 하는 산수는 틀릴 수 있고 틀려도 표는 멀쩡해 보인다.

코드 리뷰 비교 실험을 쓰면서 "모델에 묻지 말고 경로로 갈라라"고 적었던 것과 같은 얘기다. 결정론으로 되는 일을 확률에 맡기지 않는 것.

2. 승인에서 끝나면 절반만 만든 것이다

대부분의 "사람이 승인하는 에이전트"는 승인 버튼에서 끝난다. 승인했으니 됐다고 친다.

여기는 한 단계가 더 있다. 승인 후 코드가 변경을 적용하고, 광고 플랫폼에 다시 가서 실제로 반영됐는지 확인한다. 승인한 값과 적용된 값이 같은지 보는 것이다.

이게 없으면 어긋남이 조용히 쌓인다. API가 부분 실패했거나, 플랫폼이 값을 반올림했거나, 정책 때문에 거부했는데 에러가 삼켜졌을 때 — 슬랙에는 "승인 완료"만 남는다.

→ 돈이나 외부 상태를 건드리는 에이전트의 최소 구성은 승인 · 실행 · 검증 세 단계다. 둘만 있으면 신뢰가 아니라 착각이다. 며칠 전 브라우저 자동화 글에서 본 "비밀값을 모델에 넘기지 않는다"와 같은 계열의 해법이다 — 잘 하기를 기대하는 대신 구조로 막는 쪽.

3. 못 붙인 데이터를 그대로 두는 것이 성과 수치보다 믿을 만하다

지출의 10%가 안 맞는 걸 알면서 비워뒀다고 쓴다. 리포트는 그만큼 덜 예뻐진다.

이 선택이 중요한 이유는 LLM의 기본 성향이 반대이기 때문이다. 빈칸을 주면 그럴듯한 값을 채우는 쪽으로 기운다. 그리고 한 번 채워진 추정치는 다음 주 리포트에서 실제값과 구분되지 않는다.

→ 내 파이프라인에 넣을 기본값: 조인 실패는 공백으로 남기고 눈에 띄게 표시한다. 이걸 프롬프트로 막으려 하면 안 된다. 데이터를 합치는 단계가 코드여야 하고, 그 코드가 못 붙인 행을 따로 세어 보여줘야 한다.

4. 성과 수치는 에이전트의 것으로 분리되지 않는다

0% → 20%, CPL 30% 감소는 인상적이지만, 같은 문단에 지출 60% 증가가 함께 적혀 있다. 예산을 60% 늘리면 파이프라인 기여도가 오르는 건 에이전트가 없어도 일어난다. CPL 감소분도 에이전트의 판단 덕인지, 채널이 학습된 덕인지, 예산이 커져 최적화 여지가 생긴 덕인지 이 글로는 가르지 못한다.

게다가 자사 프레임워크로 만든 자사 사례다. 성과 수치는 그 전제 위에서 읽어야 한다.

→ 그래도 남는 게 있다. 구조는 성과와 별개로 검증 가능하다. 계산을 코드로 내린 뒤 40배 싸졌다는 건 내 환경에서도 재봤을 때 비슷하게 나오거나 안 나오거나 둘 중 하나고, 승인·실행·검증 3단계는 내 에이전트에 그대로 붙일 수 있다. 사례에서 가져갈 것은 숫자가 아니라 배치다.

그리고 이 배치가 맞는 작업에는 공통 조건이 있다 — 매주 같은 분석을 하고, 결론이 소수의 정해진 조치로 이어진다. 클라우드 비용 모니터링, 재고·가격 조정, 이탈 지표 추적이 그렇다. 그 조건에 안 맞는 일에 이 구조를 베끼면 승인 카드만 늘어난다.

모르는 것

• 직접 만들어보지 않았다. 위 내용은 공개된 글을 읽은 결과다.
• 40배·13배의 측정 조건을 모른다. 같은 리포트인지, 같은 데이터 범위인지, 어느 모델을 썼는지 글에서 확인하지 못했다.
• 승인 거부율이나 제안의 정확도 수치가 없다. 에이전트가 제안한 것 중 몇 퍼센트가 승인됐는지가 실질적으로 가장 궁금한 숫자인데 나와 있지 않다.
• 팀 규모와 구축 기간이 명시되지 않았다. 1인 개발자가 같은 걸 얼마 만에 만들 수 있는지 가늠할 근거가 없다.
• Pipeboard 200여 개 도구에 의존하는 구조라, 그 계층이 없으면 무엇이 달라지는지 모른다.
• 실패 사례가 10% 지출 불일치 하나만 적혀 있다. 승인 절차가 걸러낸 잘못된 제안이 있었는지, 있었다면 어떤 종류였는지 궁금한데 없다.