AI 에이전트 실전 적용 — 데모에서 크론잡까지

LLM을 업무에 실제로 붙이는 핵심은 세 가지다. 공용 헬퍼 하나로 호출을 감싸고, 품질 기준은 프롬프트 부탁 대신 코드로 강제하고, 실패 감지 채널을 먼저 만드는 것. 다만 이 세 가지를 다 갖춰도, 인프라 레이어에서 조용히 3~4일을 날리는 버그가 진짜 함정이다. 그 얘기까지 하겠다.

TechCrunch Disrupt 2026의 Builders Stage는 "실전 스케일링"을 주제로 내걸었다. 창업자·투자자·오퍼레이터가 한자리에 모여 실제로 작동하는 것들을 이야기하겠다는 기획인데, 이 행사가 흥미로운 건 주제보다 타이밍이다.

2023~2024년 AI 세션의 분위기는 "이런 게 가능합니다"였다. 2025년은 "어떻게 쓰고 있습니까"로 바뀌었고, 2026년 Disrupt는 "어떻게 스케일합니까"를 묻는다. 화두가 데모에서 POC로, POC에서 프로덕션으로 내려오고 있다. HEDVION은 12개 사이트에 콘텐츠 발행봇을 돌리는 작은 팀인데, 지난 1년 넘게 "LLM을 실제 업무에 붙이는 것"이 무슨 의미인지 꽤 비싼 수업료를 냈다.

데모와 크론잡 사이의 거리

API 키 발급받아 Python으로 호출하는 건 30분이면 된다. 문제는 그 다음이다.

그게 매일 새벽 서버에서 알아서 돌고, 결과물이 실제 사이트에 올라가고, 품질 게이트를 통과 못 하면 발행을 막고, 실패하면 Discord로 알림을 보내는 파이프라인이 되려면 — 그건 완전히 다른 차원의 작업이다.

우리는 diet·pet·lotto·insurance·money 등 12개 사이트에 콘텐츠 발행봇을 운영한다. 각 봇은 Claude Haiku로 본문을 생성하고, Claude Sonnet이 5초 주기로 검수 루프를 돌린다. 이 구조가 안정화되기까지 부서진 것들이 꽤 많았다.

실제로 부서진 것들

2026년 7월 초, gov 봇이 4일 동안 조용히 죽어 있었다. 로그도 없었다.

원인은 Python sys.path 문제였다. /opt/common에 새 db.py가 추가되면서, sys.path.insert(0, '/opt/common')를 쓰던 gov 봇의 로컬 db.py가 공용 파일에 덮였다. ImportError가 발생해서 크론이 즉시 종료됐는데, 로그 파일을 만들 권한이 없어 흔적도 남지 않았다. 발행 건수가 줄어든 걸 며칠 뒤에야 눈치챘다.

같은 달 6월 말에는 MySQL idle timeout 문제가 터졌다. 관리형 MySQL의 wait_timeout이 300초인데, LLM 호출 사이에 idle 구간이 그걸 넘으면 연결이 끊긴다. 그 다음 쿼리에서 Lost connection to MySQL server during query로 봇이 폭사한다. kpopdex discover_groups가 그렇게 죽었다. 해결은 단순했다 — 공용 DB 헬퍼를 만들어 cursor() 직전마다 자동 reconnect하게. 하지만 이 패턴을 공용화하기까지 사고가 한 번 필요했다.

이런 버그들은 LLM 자체의 문제가 아니다. 에이전트를 프로덕션에 올리는 순간 마주치는 인프라 문제다. Disrupt에서 "AI 스케일링"을 논한다면 이 층위까지 다뤘으면 한다. 실제로 굴리는 팀에는 여기가 진짜 고통 지점이다.

Haiku냐 Sonnet이냐 — 비용과 품질의 실전 트레이드오프

LLM을 업무에 붙이는 순간 가장 먼저 마주치는 선택이 모델이다. 우리가 도달한 구조는 단순하다. 생성은 Haiku, 판단은 Sonnet.

Haiku는 저렴하고 빠르다. 블로그 본문 한 편 생성에는 충분하다. 하지만 "이 글이 저품질인가"를 판단하는 검수 레이어에 Haiku를 쓰면 판단 신뢰도가 흔들린다. Sonnet은 비싸지만 판단 작업에서 체감 차이가 분명하다. 그래서 검수 루프에는 Sonnet 이상만 쓴다는 규칙을 코드 레벨에서 고정했다.

비용 구조를 단순화하면, 생성 호출이 많고 판단 호출이 적을수록 Haiku/Sonnet 분리가 유리하다. 역할 구분 없이 무조건 좋은 모델만 쓰는 건 비용 낭비고, 무조건 싼 모델만 쓰는 건 품질 포기다. 어느 작업에 어느 수준이 필요한지 — 이 판단이 에이전트 설계에서 생각보다 큰 비중을 차지한다.

프롬프트로 부탁하지 말고 코드로 강제한다

초기에 우리가 반복한 실수가 있다. 품질 기준을 프롬프트에 넣는 것이다. "1500자 이상으로 써줘", "저품질 내용은 포함하지 마" 같은 요청이다. LLM은 따르려 하지만, 보장이 없다.

AdSense가 "저가치 콘텐츠" 경고를 보내온 뒤 우리가 한 건 프롬프트 수정이 아니었다. 코드로 게이트를 만들었다. 본문 공백 제거 후 1500자 미만이면 1회 재생성, 그래도 미달이면 발행 자체를 스킵한다. 스킵해도 다음 크론에서 새 주제로 발행이 돌아가니 전체 발행량에 큰 영향은 없다.

이 구조를 직접 10개 봇에 적용해보니, 프롬프트 부탁만 할 때보다 실제 미달 차단율이 눈에 띄게 올라갔다. 당연한 결과인데 직접 해보기 전까지는 "프롬프트로 충분하겠지"라고 생각했다.

이 원칙은 LLM 에이전트 전반에 적용된다. "잘 해줘"라고 부탁하는 것과, 결과물을 코드로 검증하고 기준 미달 시 재시도·스킵하는 것은 완전히 다른 신뢰도를 만든다. 에이전트를 프로덕션에 올리려면 이 차이를 몸으로 겪어봐야 안다.

작은 팀이 에이전트를 굴릴 때 실제로 걸리는 것

Disrupt 같은 컨퍼런스의 AI 스케일링 이야기는 "어떤 전략"에 집중된다. 하지만 작은 팀에서 실제로 걸리는 건 전략보다 운영이다.

에이전트가 뭔가를 잘못 했을 때 어떻게 감지하는가. 우리는 Discord를 감시 채널로 쓴다. 봇이 발행하면 알림이 오고, 검수를 통과 못 하면 별도 채널에 뜬다. kpopdex에서 허위 앨범 정보가 발행될 뻔했을 때도 이 구조가 잡았다. LLM이 환각을 일으킬 수 있다는 걸 알면서도 감지 레이어 없이 프로덕션에 올리면, 사고는 시간문제다.

에이전트가 실수했을 때 롤백이 되는가도 중요하다. 우리는 발행 상태를 PUBLISHED/ARCHIVED로 관리하고, guard 봇이 이상을 감지하면 ARCHIVED로 내린다. 완전 삭제 대신 가역 구조를 택한 이유다. LLM 에이전트를 붙이면서 "잘 될 것"만 준비하는 팀은 오래 못 간다. "잘못됐을 때" 복구 경로를 먼저 설계해야 한다.

내일 당장 써먹을 수 있는 것

첫째, LLM 호출은 공용 헬퍼 하나로 감싸라. SDK를 여러 곳에서 직접 호출하면, 나중에 모델 교체·retry·토큰 로깅을 바꿀 때 코드 전체를 뒤진다. 처음부터 단일 complete() 함수를 만들고 거기서만 쓰게 하면 나중이 훨씬 편하다.

둘째, 품질 기준은 코드로 박아라. "잘 써줘" 대신 결과물을 검증하는 코드를 짜라. 글자수, 필수 필드, 형식 — 이건 모두 if/else로 판단 가능하다. 재시도·스킵 분기도 코드로 처리한다.

셋째, 실패 감지 채널을 에이전트보다 먼저 만들어라. Discord든 Slack이든, 에이전트가 이상할 때 사람이 알 수 있는 경로가 없으면 3~4일을 조용히 날릴 수 있다. 우리가 실제로 그랬다.

넷째, 비싼 모델은 판단 레이어에만 써라. 생성은 저렴한 모델, 검수·판단은 고성능 모델. 이 분리만으로 비용이 의미 있게 줄고 품질은 유지된다.

Disrupt의 무대에서 나오는 이야기들이 결국 여기로 수렴하길 기대한다. 전략이 아니라 운영, 가능성이 아니라 신뢰도. 그게 실전의 언어다.

원문: AI News & Artificial Intelligence | TechCrunch