AWS 천조 베팅과 우리 팀의 에이전트 실전 도입기

지금 당장 작은 팀도 LLM 에이전트를 업무에 붙일 수 있다. 생성엔 저렴한 모델, 판단엔 고성능 모델을 쓰는 구조만 잡으면 비용도 통제된다. 단, "LLM에게 부탁"과 "코드로 강제"를 혼동하는 순간 에이전트가 조용히 잘못된 결과를 내보낸다. 이 구분 하나가 아래 전부를 가른다.

AWS 천문학적 투자가 작은 팀에게 보내는 신호

앤디 재시(Andy Jassy)의 발언 요지는 간단하다. AWS는 1조 달러 사업이 될 것이고, 그 전에 막대한 자본 지출을 아끼지 않겠다. 2026년 현재 AWS의 분기별 capex는 200억 달러를 넘어선다. 연간 1000억 달러 규모다.

이 숫자가 소규모 팀과 무슨 관계인가 싶겠지만, 인프라 투자가 이렇게 집중될 때마다 같은 일이 반복된다. 컴퓨트 단가가 내려간다. GPT-4급 성능의 토큰 단가는 2023년 대비 2026년 현재 10분의 1 이하로 줄었다. Jassy의 발언은 이 흐름을 더 빠르게 밀겠다는 신호다.

하이퍼스케일러들이 AI 인프라에 수천억을 쏟아부으며 개발된 컴퓨트 자원은 결국 API를 통해 시장에 풀린다. 소규모 팀 입장에서 지금은 진입 비용이 낮아지는 구간이다. 적기를 따지자면, 지금이다.

"에이전트를 붙인다"의 실제 정의

마케팅 자료에서 보이는 에이전트와 cron에 걸어두고 새벽에 혼자 돌아가는 에이전트는 완전히 다른 물건이다. "AI 에이전트"라는 단어가 너무 넓어진 탓에 정의부터 잡지 않으면 이야기가 흐릿해진다.

우리 팀이 실용적으로 쓰는 정의는 간단하다. LLM 결과가 다른 시스템 동작을 트리거하거나, 다음 LLM 호출의 입력이 되는 워크플로우. 단일 LLM 호출 하나로 끝나면 그냥 API 래퍼다. 에이전트가 아니다.

지금 운영하는 블로그 봇이 이 기준을 충족한다. 크롤러가 뉴스를 수집하면 Haiku가 본문을 생성하고, Sonnet이 결과물을 검수해 OK/REJECT/WARN으로 판정한다. REJECT면 ARCHIVED 처리, WARN이면 Discord에 사람 검토 요청이 올라간다. 매일 04:00에 이전 발행 피드백을 정리해 다음 생성 프롬프트에 주입한다.

복잡해 보이지만, 처음 만들 때는 "크롤러 → 본문 생성 → 발행"이라는 단순한 선형 흐름이었다. 검수와 피드백 루프는 문제가 생긴 뒤에 추가됐다. 에이전트는 한 번에 완성하는 게 아니라 쌓아가는 것이다.

두 모델의 역할 분리 — 수치로 보는 이유

처음엔 고성능 모델 하나로 전부 처리하려 했다. 비싼 모델이면 검수도 필요 없을 거라고 생각했다. 직접 써보니 완전히 다른 결론이 나왔다.

생성 작업과 판단 작업은 요구하는 능력 자체가 다르다. 블로그 본문을 만들어내는 건 Haiku로도 충분하다. 그 본문이 AdSense 정책을 위반하는지, 사실 오류가 있는지 판단하는 건 Sonnet이 명확히 낫다. 이 둘을 분리하는 순간 비용 구조가 바뀐다.

2026년 현재 공개 API 기준으로 Haiku와 Sonnet의 토큰 단가 차이는 입력·출력 합산 기준 대략 5~10배 수준이다. 하루 30건 발행 기준으로 전 단계를 Sonnet으로 돌릴 때 대비, 생성을 Haiku로 내리고 검수만 Sonnet을 쓰면 전체 LLM 비용이 60% 이상 줄어든다. 품질 차이는? 생성 단계에서는 체감이 거의 없다. 판단 단계에서만 Sonnet이 확실히 낫다.

이 원칙은 다른 업무에도 그대로 통한다. 생성·변환·정형화는 저렴한 모델로, 검증·분류·판단은 비싼 모델로. 파이프라인 전체를 고성능 모델로 채우는 건 낭비다.

코드 게이트와 프롬프트 부탁은 다르다

에이전트 설계에서 가장 자주 보이는 실수다. LLM에게 조건을 "부탁하는 것"과 코드에서 조건을 "강제하는 것"을 같다고 착각한다.

"1500자 이상으로 써줘"는 프롬프트 지시다. LLM은 대체로 따르지만, 가끔 무시한다. 반면 코드에서 len(re.sub(r"\s+","",body)) < 1500 이면 발행을 건너뛰는 건 강제다. 확률이 아니라 보장이다.

우리가 이 방식으로 전환한 계기가 있다. 블로그 봇이 짧은 글을 계속 발행하면서 AdSense 저가치 콘텐츠 반려를 받았다. 프롬프트에 "최소 1500자"라고 써뒀는데 소용이 없었다. MIN_BODY_CHARS = 1500 게이트를 코드에 박고, 미달이면 재생성, 재생성도 미달이면 발행 자체를 스킵하는 구조로 바꿨더니 문제가 사라졌다.

에이전트 안의 조건을 구분하는 방법은 이렇다. 판단 기준이 맥락 의존적이고 복잡하면 LLM에 위임한다. 조건이 이진(binary)이고 명확하면 코드에 넣는다. 이 선 하나가 에이전트 안정성을 크게 결정한다.

새 에이전트를 붙이기 전에 확인할 세 가지

신규 업무에 에이전트를 붙이려 할 때마다 우리는 같은 세 가지를 확인한다.

첫째, 주 3회 이상 반복되는 작업인가. 반복성이 없으면 자동화 투자가 회수되지 않는다. 둘째, 실패 비용이 얼마인가. 잘못된 결과물이 나왔을 때 사람이 바로 수정하면 되는 수준인지, 아니면 외부에 노출되어 손해가 생기는 수준인지. 후자라면 검수 레이어는 비용이 아니라 보험이다.

셋째가 가장 숨어 있는 함정이다. LLM 호출과 DB 쿼리가 같은 워크플로우 안에 섞이면, LLM 응답을 기다리는 수십 초 사이에 DB 커넥션이 끊긴다. 실제로 2026년 6월에 이 문제로 하루 발행이 통째로 멈췄다. MySQL의 idle timeout이 300초인데, LLM 호출 대기 시간이 그보다 길었다. 다음 쿼리에서 Lost connection 에러가 터진 것이다. 지금은 커넥션에 자동 ping/reconnect를 넣은 공용 헬퍼를 쓴다. 설계 단계에서 이 함정을 먼저 고려해두면 나중에 디버깅에 하루를 날리지 않아도 된다.

지금 바로 적용할 수 있는 실행 포인트

첫 에이전트는 새로운 워크플로우를 만들 필요가 없다. 팀에서 지금 주 3회 이상 손으로 하는 반복 작업 하나를 골라서 LLM 호출 하나로 대체하는 것이 가장 빠른 시작이다. 완성된 에이전트를 처음부터 설계하려 하면 한 달이 걸린다.

모델 선택은 처음부터 역할을 나눠라. 생성·변환엔 Haiku급, 판단·검수엔 Sonnet 이상. 나중에 모델을 바꾸는 건 쉽다. 구조를 바꾸는 건 코드 전체를 뒤집는 일이다. 처음 설계에서 이 분리를 잡아두면 비용이 처음부터 통제 가능하다.

이진 조건은 코드에 박아라. 길이 하한선, 금지 패턴 필터, API 응답 유효성 검사 같은 명확한 조건은 LLM에게 부탁하지 말고 코드로 강제해라. LLM에게만 맡기면 99%는 맞고 1%에서 조용히 뚫린다.

마지막으로, 실패 경로를 에이전트 자체보다 먼저 설계해라. 이상한 결과를 감지하는 모니터링이 없으면 에이전트가 며칠 동안 조용히 오작동해도 알 방법이 없다. 모니터링 봇을 먼저 만들고 에이전트를 붙여도 순서가 늦지 않다.

AWS가 수천억 달러 인프라를 깔아주는 동안, 그 위에서 에이전트 하나를 먼저 돌리는 팀이 가장 빠르게 움직인다.

원문: AI News & Artificial Intelligence | TechCrunch