AI 에이전트를 실전에 붙이는 법

Flock이 직원들에게 자진 퇴직 패키지를 제안했다. 거절하면 강제 해고가 "거의 확실하다"는 조건이다. 미국 테크 씬에서 이런 뉴스는 이제 낯설지 않다. 하지만 이 소식이 흥미로운 건 규모 때문이 아니다.

Flock이 어떤 역할을 먼저 줄이는지, 그리고 그 공백을 무엇으로 채울 계획인지가 진짜 질문이다. 그 답이 우리 같은 작은 팀에게 직접적인 신호를 보낸다.

다만 이 신호를 그대로 따라 했다가 더 나쁜 결과를 얻는 팀도 있다. 왜 그런지는 아래에서.

감원 뉴스의 진짜 신호

테크 기업이 자진 퇴직 유인책을 돌린다는 건, 내부에서 "이 역할은 자동화 가능하다"는 리스트가 이미 만들어졌다는 뜻이다. 경영진이 단순히 비용을 줄이고 싶다면 그냥 레이오프를 한다. 패키지를 제안하며 자발적 이탈을 유도하는 건, 특정 포지션을 AI로 대체하기 전에 법적·문화적 리스크를 관리하는 방식이다.

큰 회사는 "해고 후 AI로 메운다"는 선택지가 있다. 작은 팀에게 이 뉴스가 중요한 건 역설적으로 다른 이유에서다. 우리는 애초에 인력을 많이 못 뽑는다. 그렇다면 처음 설계 단계부터 "에이전트 없이는 돌아가지 않는" 구조를 만들어야 한다는 말인데, 막상 해보면 생각보다 훨씬 까다롭다.

에이전트를 '붙인다'는 것과 에이전트가 '실제로 동작한다'는 것 사이에는 넓은 골짜기가 있다.

AI 슬롭의 함정

요즘 인터넷에서 '한국인의 심장이 반응하는 AI슬롭'이라는 말이 돈다. 감성적인 썸네일, 반응을 유도하는 제목, 읽으면 그럴듯한데 실제로는 비어있는 콘텐츠. LLM을 파이프라인에 그냥 연결하면 이 함정에 가장 먼저 빠진다.

우리 팀이 블로그 봇을 처음 운영할 때가 딱 그랬다. LLM에 "1,200~2,000자로 써줘"라는 프롬프트만 걸어뒀는데, 어떤 날은 500자짜리 글이 그대로 발행됐다. 어드센스 심사에서 "저가치 콘텐츠"로 반려됐고, 그때서야 프롬프트 부탁으로는 품질을 강제할 수 없다는 걸 깨달았다. LLM은 시키는 대로 하는 게 아니라, 시킨 것처럼 보이게 하는 쪽으로 최적화된다.

Flock이 인원을 줄이고 AI로 채우려 할 때, 이 함정에 빠진 팀은 사람이 하던 것보다 못한 아웃풋을 더 빠르게 쌓아낸다. 속도는 올라가는데 결과물 품질은 무너지는 역설.

검증 레이어가 전부다

그 이후로 구조를 완전히 바꿨다. 본문 공백을 제거한 순수 텍스트가 1,500자 미만이면 코드 레벨에서 재생성 트리거가 자동으로 걸린다. 재생성 후에도 기준을 못 넘으면 발행 자체를 스킵한다. 글 수가 줄어도 슬롭을 내보내는 것보다는 낫다.

이걸 "프롬프트 품질 관리"가 아니라 "코드 게이트"로 만든 게 핵심이다. LLM에 부탁하는 게 아니라, LLM의 출력을 코드로 검증한다. 이 차이가 전부다.

한 가지 트레이드오프는 있다. 재생성이 트리거되면 LLM 비용이 두 배 가까이 나간다. 그런데 저가치 글 하나가 어드센스 계정 전체에 주는 리스크를 생각하면 그게 훨씬 싼 선택이다. 단기 비용과 장기 리스크를 같은 단위로 놓고 비교해야 한다.

AI 에이전트를 실전에 붙이는 첫 번째 원칙은 여기서 나온다. 에이전트를 신뢰하지 말고, 에이전트의 출력을 검증하는 레이어를 별도로 설계하라.

실전 파이프라인: 구체적 구조와 숫자

현재 HEDVION 콘텐츠 파이프라인은 이렇게 생겼다. 크롤러가 뉴스나 키워드를 가져온다. Claude Haiku가 초안을 생성한다. 코드 레벨 게이트(글자수, 필수 키워드 포함 여부)를 통과하면 DB에 INSERT된다. 직후 Discord로 노티가 가고, 별도 서비스가 Claude Sonnet으로 자동 검수를 돌린다. OK면 유지, REJECT면 아카이브, WARN이면 사람이 직접 확인하는 채널로 올라온다.

사람이 직접 글을 쓰는 단계는 0이다. 하지만 사람이 설계한 검증 포인트는 다섯 군데다.

Haiku와 Sonnet을 나눠 쓰는 게 포인트다. 생성은 빠르고 저렴한 Haiku, 검수는 더 정교한 Sonnet. 가격 차이가 대략 10배 이상이라, 생성 전 단계에 Sonnet을 쓰면 비용이 폭발한다. 반면 검수는 이미 완성된 텍스트를 짧게 판단하는 거라 Sonnet이어도 토큰이 많이 나가지 않는다. 이 조합이 품질과 비용의 실제 균형점이다.

생성 모델을 뭘 쓰느냐보다, 어느 단계에서 어느 모델을 쓰느냐가 훨씬 중요하다. 초안엔 싼 모델, 최종 판단엔 비싼 모델 — 이 원칙 하나로 같은 품질을 훨씬 낮은 비용에 달성할 수 있다.

사람 냄새를 내는 자동화

자동화를 잘못 설계하면 플랫폼에 찍힌다. Threads 계정을 새로 개설했을 때, API로 연속 발행을 수십 분 안에 십수 건 했다가 자동화 스팸으로 플래그됐다. 재고 요청까지 갔다. 그 이후로 소셜 발행 봇은 완전히 다르게 설계했다.

하루 최대 2건, 발행 시각은 오전 9시~~밤 11시 사이에서 0~~40분 랜덤 지연, 사이트당 연속 발행 간격은 3~6시간 랜덤. 사람처럼 보이게 하려는 게 목적이 아니다. 플랫폼 알고리즘이 "자연스러운 행동 패턴"으로 신뢰를 부여하기 때문에, 그 기준에 맞추는 거다.

Flock이 인원을 줄이고 AI 자동화 비율을 갑자기 높이면 같은 문제에 직면한다. 갑작스러운 패턴 변화는 플랫폼이든, 고객이든, 내부 프로세스든 어딘가에서 이상 신호를 만든다. 에이전트가 일을 한다는 게 티 나는 순간 신뢰가 빠진다.

실전 에이전트 설계의 두 번째 원칙은 이거다. 속도보다 패턴이다. 빠르게가 아니라 자연스럽게 설계해야 한다.

내일 바로 쓸 수 있는 시사점

에이전트를 업무에 붙이고 싶다면, 이 순서로 접근하는 게 가장 덜 실패한다.

먼저 반복 작업 하나를 고른다. "결과물을 보면 잘됐는지 아닌지 즉시 판단할 수 있는" 작업이어야 한다. 판단 기준이 모호한 작업부터 자동화하면 검증 레이어를 설계할 수 없어서 슬롭만 쌓인다. "기준이 명확한 것"을 먼저 잡아야 한다.

다음으로 LLM 호출과 검증 로직을 처음부터 분리된 코드 블록으로 만든다. 생성 → 검증 → 발행의 세 단계를 하나의 함수에 때려 넣으면, 프롬프트를 바꿀 때마다 검증 기준도 같이 흔들린다. 모듈을 쪼개둬야 나중에 검증 기준만 조용히 바꿀 수 있다.

모델 선택은 처음부터 결정해둔다. 초안 생성은 Haiku급, 판단이 필요한 검수 단계만 Sonnet급. 이 구분을 나중에 바꾸려면 비용 구조 전체를 다시 짜야 해서 초반에 정하는 게 훨씬 싸다.

마지막으로 첫 일주일은 모든 출력을 사람이 직접 본다. 자동 검수가 있어도 마찬가지다. 어디서 환각이 나오는지, 어떤 프롬프트 패턴이 슬롭을 만드는지를 눈으로 봐야 검증 기준을 제대로 코딩할 수 있다. 직접 보지 않고 만든 검증 로직은 처음 만난 엣지 케이스에서 무너진다.

Flock이 자진 퇴직 패키지를 돌리는 동안, 남은 팀원들은 그 공백을 AI 에이전트로 메워야 한다. 제대로 설계된 에이전트라면 가능한 일이다. 하지만 프롬프트 한 줄에 기대어 시작하면, 줄어든 팀보다 더 나쁜 결과물을 더 빠르게 쌓게 된다.

원문: AI News & Artificial Intelligence | TechCrunch