에이전트를 붙인다는 건 실제로 뭔가

고객 한 명당 에이전트 하나 — 그게 실제로 무슨 뜻인가

인도의 마케팅 자동화 SaaS MoEngage가 인수한 기술의 핵심은 단순하다. 수백만 명의 사용자에게 동일한 마케팅 로직을 일괄 적용하는 대신, 사용자 한 명에 AI 에이전트 하나를 붙인다. 그 에이전트는 해당 사용자의 구매 이력, 클릭 패턴, 이탈 시점을 기억하고, 언제 어떤 메시지를 보낼지 스스로 판단한다. 사용자가 수백만이면 에이전트도 수백만.

왜 지금인가. 기존 룰 기반 마케팅 자동화는 조건 분기가 너무 빠르게 복잡해진다. 변수 10개면 경우의 수는 이미 수천이고, 그걸 마케터가 if-else 트리로 관리하는 건 불가능에 가깝다. 에이전트에 위임하면 그 복잡도를 LLM이 흡수한다. 말은 깔끔하다. 문제는 실제로 어떻게 구현하느냐, 그리고 소규모 팀에게 이 이야기가 얼마나 현실적이냐다.

LLM 호출 vs AI 에이전트 — 구분이 왜 중요한가

우리 팀이 "LLM을 쓴다"고 할 때, 대부분은 에이전트가 아니라 LLM 호출이다. 이 구분이 흐릿하게 쓰이는 경우가 많은데, 실무 기준으로 명확히 하면 이렇다.

LLM 호출은 상태가 없다. 프롬프트를 넣으면 텍스트가 나온다. 그 텍스트를 어디에 저장하고 어떻게 다음 단계에 넘기느냐는 호출하는 코드가 전부 책임진다. 제어 흐름은 파이썬 파일 안에 있다. 반면 에이전트는 자기 상태가 있다. 어떤 도구를 쓸지 스스로 결정하고, 이전 스텝 결과를 기억하며, 목표를 달성하기 위해 여러 액션을 자율로 실행한다. 루프가 외부 코드가 아니라 에이전트 내부에 있는 것이 핵심 차이다.

우리 블로그 봇 구조를 예로 들면 — cron → 크롤 → claude_complete() 호출 → DB INSERT → 디스코드 알림 — 이건 LLM 호출이 파이프라인에 껴 있는 구조지, 에이전트가 아니다. Claude가 판단하는 건 "글을 써라"는 명령 하나뿐이고, 나머지 제어 흐름은 파이썬 코드가 쥐고 있다. 에이전트라면 "오늘 어떤 키워드를 쓸지", "이미 발행한 주제와 겹치는지", "지난주 성과가 낮은 카테고리를 이번엔 피할지"를 Claude가 스스로 판단하고 도구를 직접 호출해서 확인한 다음 발행 여부를 결정했을 것이다.

에이전트를 붙이면 뭐가 달라지나 — 비용과 복잡도 현실

현실적인 문제를 먼저 짚자. 에이전트는 비싸다.

단순 LLM 호출 한 번(claude-haiku, 입출력 합계 1000 토큰 기준)은 $0.001 미만이다. 그런데 에이전트가 도구를 3번 호출하고 중간 추론을 두 번 거치면, 같은 작업에 토큰 소모가 10배 이상 뛴다. MoEngage식으로 수백만 사용자에 에이전트를 붙이면 에이전트 활성 빈도와 컨텍스트 크기에 따라 월 LLM 비용이 기존 대비 5~20배 증가할 수 있다. 작은 팀에 사소한 숫자가 아니다.

오케스트레이션 복잡도도 문제다. 에이전트가 도구를 잘못 골라 루프를 돌거나, 컨텍스트 창이 꽉 차서 이전 기억이 잘려나가거나, 예상 못한 도구 호출 순서로 사이드 이펙트가 생기는 일이 실제 운영에서 잦다. 디버깅이 어렵고, 로그를 봐도 "왜 그 결정이 나왔는지" 추적하기가 까다롭다. 엔지니어 두 명짜리 팀이 에이전트 10개를 동시에 굴리면 장애 대응이 간단치 않다.

그래서 MoEngage의 베팅에서 흥미로운 지점이 이것이다. 그들이 인수한 기술은 아마 이 복잡도를 플랫폼이 흡수해주는 레이어를 포함할 것이다. 수백만 에이전트를 개별 팀이 직접 운영하는 게 아니라, 인프라가 관리해주는 구조. 소규모 팀에게 시사하는 바는 바로 이 지점이다 — 에이전트 인프라를 직접 짤 타이밍인지, 아니면 이런 플랫폼에 올라타는 게 맞는 선택인지를 구분해야 한다는 것.

우리 봇이 에이전트에 얼마나 가까운가

솔직히 보면, 우리 발행 봇 구조에는 이미 에이전트적 요소가 부분적으로 있다. 매일 04:00 KST에 돌아가는 learn-update.py가 발행 성과를 분석해서 learned/{slug}.json을 갱신하고, 다음 발행 때 system prompt에 주입한다. 기억이 있고, 그 기억이 다음 행동에 영향을 준다. 구조적으로는 에이전트 메모리와 흡사하다.

한계도 명확하다. learned.json은 플랫 JSON이다. "지난달 다이어트 카테고리 클릭률이 낮았으니 이번 주 비중을 줄이고 운동 루틴 쪽을 올려라"는 추론을 그 파일 자체가 하지 않는다. Claude가 프롬프트를 받아서 해석해야 하고, 그 해석이 실제 결정에 어떻게 영향을 미쳤는지 우리가 추적하기 어렵다. 피드백 루프가 느슨하다.

진짜 에이전트 패턴으로 가려면 적어도 세 가지가 달라져야 한다. Claude가 "글을 써라"가 아니라 "오늘 뭘 발행할지 결정하고 써라"를 위임받아야 한다. 그 결정에 필요한 도구(키워드 조회, 기발행 목록 확인, 트래픽 데이터)를 Claude가 직접 호출할 수 있어야 한다. 그리고 그 결정 과정이 기록돼서 나중에 "왜 그 판단이 나왔는지" 볼 수 있어야 한다. 세 번째가 의외로 가장 중요하고 가장 자주 빠진다.

어디서부터 시작할까 — 구체 시나리오

가장 현실적인 진입점은 기존 파이프라인의 한 스텝 하나를 에이전트로 교체하는 것이다. 전체를 갈아엎으면 리스크가 너무 크다.

gov 봇(정부지원사업 크롤)을 예로 들자. 현재는 크롤한 데이터를 그냥 Claude에 넣고 글을 쓰라고 한다. 여기에 에이전트를 붙인다면, Claude에게 크롤 결과 목록을 주고 목표를 이렇게 바꾼다. "이 중에서 오늘 발행할 공고를 골라라. 지난 2주간 발행한 공고와 겹치면 건너뛰어라. 마감일이 3일 이내면 우선순위를 높여라. 선택 근거를 한 줄로 남겨라." Claude가 기발행 목록을 조회하는 도구를 호출하고, 마감일을 파싱해서 순위를 매기고, 발행 대상을 결정한 다음 글까지 쓴다. 토큰은 기존 대비 3~5배 늘겠지만, gov 봇은 일일 발행 수가 적고 글 하나의 SEO 가치가 높다. 비용 대비 납득 가능한 트레이드오프다.

반면 lotto 봇은 다르다. 평일 1건, 주말 3건의 단순 패턴에 콘텐츠 변동성도 낮다. 여기에 에이전트 복잡도를 얹을 이유가 없다. 지금 구조로 충분하다. 에이전트를 붙이는 판단은 결국 "자율 결정이 실제 가치를 만드는 스텝이 존재하는가"로 귀결된다. 그 스텝이 없으면 LLM 호출로 족하다. 에이전트가 더 좋다는 건 더 비싸고 복잡하다는 말이기도 하니까.

당장 써먹을 시사점

MoEngage의 "수백만 에이전트" 전략에서 소규모 팀이 실제로 가져갈 수 있는 건 스케일이 아니라 사고 방식이다.

지금 파이프라인에서 "판단"이 필요한 스텝이 어디인지 먼저 찾아라. 정해진 변환만 하는 스텝은 LLM 호출로 족하다. "여러 선택지 중 하나를 골라야 하고, 그 근거가 상황에 따라 달라지는" 스텝이 에이전트 후보다. 이 구분만 잘 해도 불필요한 복잡도를 상당히 줄일 수 있다.

도구는 작게 시작해야 한다. 에이전트에게 처음부터 도구 10개를 주면 어떤 도구를 왜 골랐는지 디버깅이 사실상 불가능하다. 도구 2~3개짜리 에이전트로 시작해서, 잘 작동하는 게 확인되면 늘리는 흐름이 맞다.

비용 시뮬레이션은 붙이기 전에 반드시 해라. 에이전트 한 번 실행에 평균 몇 토큰이 쓰이는지, 하루 몇 번 실행되는지 곱하면 월 비용 추정이 나온다. 월 $50짜리 개선이 월 $200 비용이면 망설여야 한다. $50 비용이 편집자 공수 3시간을 대체한다면 망설일 이유가 없다.

마지막으로 — 에이전트의 결정을 반드시 로깅해라. 왜 그 글감을 골랐는지, 왜 발행을 건너뛰었는지, Claude의 추론 과정을 별도 컬럼이나 로그 파일에 남겨두면 이후 프롬프트 개선과 트러블슈팅이 훨씬 쉬워진다. 그 로그가 쌓이면 그게 곧 다음 에이전트를 개선하는 실질적인 재료가 된다. MoEngage가 수백만 에이전트에 투자하는 이유도, 결국 그 데이터 자산을 쌓기 위해서다.

원문: AI News & Artificial Intelligence | TechCrunch