AI CEO 백악관 만찬이 에이전트 실무자에게 던지는 신호

Dario Amodei가 트럼프 대통령과 단독 만찬 테이블에 앉는다는 소식을 "AI 정치 기사"로 흘려보내기 쉽다. 그런데 잠깐 각도를 바꿔 읽으면 다른 그림이 보인다.

AI 회사 CEO가 규제 방어를 위해 방문한 게 아니라, 국가 수반 쪽에서 AI 개발 속도를 의제로 먼저 불렀다는 것. 그 주체의 역전이 이 만찬의 무게를 결정한다. 기술이 정책 대화의 객체에서 주체로 올라섰다는 신호다.

우리 같은 작은 팀 입장에서 이건 타이밍 신호다. AI 에이전트가 "검토해볼 만한 기술"에서 "이미 쓰고 있는 인프라"로 넘어가는 변곡점이 바로 지금이라는 것. 그 창이 빠르게 좁아진다는 것.

단, 이 얘기를 "지금 당장 AI 써야 한다"는 식으로 끝내면 뜬구름이 된다. 실제로 붙여보면 생각보다 마찰이 많다. 그 마찰이 어디서 오는지, 어떻게 설계해야 하는지가 이 글의 본론이다.

뉴스를 신호로 읽는 방법

이번 만찬의 의제가 "AI 개발 속도"라는 점은 실무자에게 두 가지 방향으로 해석된다.

첫째, 모델 진화 속도가 앞으로도 빠를 것이다. 규제보다 개발이 앞서는 환경이 유지된다는 의미다. 지금 우리가 Haiku에 맡기지 못하는 작업들을 6개월 뒤엔 Haiku급 비용으로 처리할 수 있는 날이 올 수 있다.

둘째, 그 속도가 빠를수록 특정 모델에 단단히 묶인 설계는 수명이 짧아진다. 지금 정교하게 짜놓은 프롬프트가 3개월 뒤 새 모델에서는 그냥 "이렇게 해줘" 한 줄로 같은 결과가 나올 수도 있다. 프롬프트보다 파이프라인 구조와 품질 게이트에 투자해야 하는 이유가 여기 있다.

대형 팀들도 같은 모델을 쓴다. 모델 성능과 그걸 조직 안에서 운영하는 역량은 다른 곳에서 자란다. 지금 에이전트 파이프라인 설계 경험을 쌓지 않으면, 모델이 아무리 좋아져도 따라잡을 수 없다.

직접 붙여보면 생기는 마찰들

처음 블로그 발행 봇을 만들 때, 가장 큰 착각은 "LLM에 시키면 알아서 잘 쓰겠지"였다. 실제로는 달랐다.

가장 큰 병목은 모델 성능이 아니라 프롬프트 유지보수였다. "1200자에서 2000자 사이로 써줘"라고 프롬프트에 넣으면 모델은 그냥 800자짜리를 내놓기도 한다. 처음엔 그냥 발행했다. 결과는 AdSense 저가치 판정. 그래서 코드 레벨에서 게이트를 박았다. 본문 공백 제외 1500자 미만이면 1회 재생성, 그래도 안 되면 발행 스킵. 프롬프트에 "길게 써줘"라고 부탁하는 것과 코드로 강제하는 것의 신뢰도 차이는 생각보다 훨씬 크다.

이게 에이전트 설계의 핵심 레슨이었다. LLM의 출력을 신뢰하는 게 아니라, 출력의 품질 조건을 코드로 검증하는 것. LLM은 생성자고, 판단은 별도 레이어에서 한다. 이 분리를 처음부터 설계에 넣느냐 아니냐가 파이프라인 안정성을 결정한다.

어디까지 자동화하고 어디서 사람을 남길 것인가

자동화 범위를 설계할 때 가장 중요한 질문은 하나다. "이 단계에서 실수가 나오면 비용이 얼마인가."

비용이 작으면 자동화해도 된다. 비용이 크면 사람을 남겨야 한다. 우리 팀의 발행 파이프라인을 예로 들면, Claude Sonnet이 발행 후보를 5초마다 폴링해서 OK/REJECT/WARN 판정을 내린다. OK면 유지, REJECT면 자동 ARCHIVED, WARN이면 Discord 채널에 플래그가 뜬다. 사람이 직접 판단해야 하는 건 WARN만이다. "모든 발행을 사람이 검토"하는 것과 "모든 걸 자동 발행"하는 것 사이의 트레이드오프를 이 구조로 다룬다.

실존 인물이 등장하는 콘텐츠는 자동화 범위를 다르게 잡는다. 허위 한 줄이 명예훼손이 되는 도메인에서는 외부 소스와의 교차검증을 코드로 강제한다. "AI가 못 믿겠어서"가 아니라 그 실수의 비용이 비싸기 때문이다. 같은 모델, 다른 자동화 범위. 이 구분이 실무에서 매우 중요하다.

에이전트를 처음 붙이는 팀에게 하고 싶은 말이 있다면, 자동화 범위를 확장하기 전에 "이 단계 실수 비용"을 먼저 글로 써보라는 것이다. 정량적으로 못 쓰겠으면 아직 그 단계를 자동화할 준비가 안 된 것이다.

비용 설계: Haiku와 Sonnet을 어떻게 나눌 것인가

에이전트 파이프라인에서 비용 구조를 무시하면 규모가 붙으면서 반드시 터진다.

우리 팀은 콘텐츠 생성 단계는 Claude Haiku, 검수와 판단 단계는 Sonnet 이상을 쓰는 구조로 운영한다. 두 모델의 호출 비용은 적게는 수 배, 많게는 10배 이상 차이 난다. 발행 봇이 하루에 수십 건을 처리할 때, 전 단계를 Sonnet으로 돌리면 비용이 선형으로 불어난다. 반대로 전 단계를 Haiku로 돌리면 판단 품질이 떨어져서 다른 곳에서 비용이 발생한다.

이 분리 자체가 주기적으로 재조정된다. 6개월 전에 Haiku로는 믿기 어렵다고 생각했던 판단을, 지금 Haiku 최신 버전이 충분히 처리하기도 한다. 그래서 "어떤 모델을 쓰느냐"를 고정하기보다 "어느 단계에 어느 수준의 모델을 붙이느냐"를 파이프라인 구조로 관리하는 게 더 낫다. 모델은 바뀌지만 구조는 유지된다.

모니터링 없는 에이전트는 블랙박스다

에이전트 파이프라인을 운영하면서 가장 시간을 잡아먹는 건 디버깅이 아니다. 모니터링이다.

어떤 단계에서 출력이 이상한지, 어떤 조건에서 품질 게이트가 과차단을 하는지는 결과 로그가 쌓여야 보인다. 처음 설계할 때는 보이지 않는 것들이다. Discord 채널 하나에 봇 결과를 뿌리는 구조라도 만들어두면, 나중에 파이프라인을 개선할 때 근거가 생긴다. 개선 결정은 감이 아니라 데이터에서 나와야 한다.

구체적으로 어떤 걸 모니터링해야 하는가. 발행 성공/스킵 비율, 품질 게이트 통과율, 재생성이 실제로 품질을 얼마나 올렸는지, 모델 호출 비용의 단계별 분포. 이 네 가지만 있어도 파이프라인의 어디가 약한지 빠르게 보인다.

지금 당장 시작하는 팀을 위한 설계 원칙

첫 에이전트를 붙이는 가장 현실적인 출발점은 "지금 사람이 반복하는 작업 중 실수 비용이 중간 정도인 것"이다. 너무 중요해서 실수가 용납 안 되는 것(계약 검토, 고객 응대)과 너무 사소해서 자동화 설계 비용이 더 큰 것을 제외하면 중간 지대가 남는다. 콘텐츠 초안 생성, 내부 리포트 요약, 이메일 분류 같은 작업이 거기 있다.

첫 단계에서 에이전트 출력을 최종 결과물로 바로 쓰지 말고, 사람의 작업을 가속하는 드래프트로 설계하라. 80% 완성도의 초안을 주고 사람이 20%를 고치는 구조. 신뢰가 쌓이면 사람 개입 비율을 줄이면 된다. 이 순서가 바뀌면 실수 비용이 예상보다 빠르게 누적된다.

마지막으로 하나만 더. 에이전트를 LLM에 의존하는 시스템으로 만들지 말고, LLM이 교체될 수 있는 시스템으로 만들어라. 프롬프트와 파이프라인 구조를 분리해두면, 6개월 뒤 더 나은 모델이 나왔을 때 그 모델로 갈아끼우는 비용이 최소화된다.

Amodei가 저녁을 먹으러 간 동안, 우리는 지금 돌고 있는 파이프라인 로그를 보고 있을 것이다. 그게 현실이고, 그게 맞는 순서다.

원문: AI News & Artificial Intelligence | TechCrunch