AI 기피 워크숍이 흥행할 때 에이전트를 실제로 붙이는 법

도서관에 'AI 기피' 강좌를 열었더니 선착순이 동났다

미국 전역 도서관에서 "AI 피하는 법" 워크숍을 개설하자 자리가 꽉 찼다. TechCrunch가 보도한 이 장면은 단순한 기술 불안이 아니다. 생성 AI가 쏟아낸 콘텐츠 슬롭, 잘못된 정보, "이게 사람이 쓴 건지 기계가 쓴 건지" 구분 못 하는 피로감이 임계점을 넘은 것이다.

우리는 정반대 방향으로 달리고 있다. 블로그 봇, 리뷰 감시 에이전트, 콘텐츠 생성 파이프라인 — LLM을 실제 운영 시스템에 붙인 지 꽤 됐다. 그런데 이 역설적 뉴스가 오히려 실전 배포팀에게 중요한 신호를 준다.

"AI를 피하는 사람이 저렇게 많다는 건, AI가 잘못 작동한 경험을 한 사람이 그만큼 많다는 뜻이다."

이 교훈을 "조심하자"는 식으로 끝내면 아무 쓸모가 없다. 실제로 에이전트를 붙일 때 어디서 무너지고, 어떻게 버티는지 — 경험을 바탕으로 정리한다. 단, 아래에서 소개하는 구조를 그대로 복붙하면 안 되는 이유가 하나 있다. 우리가 가드레일을 만든 건 사고가 터진 이후였다.

대중이 AI를 거부하는 불만, 엔지니어 언어로 번역하면

워크숍 참가자들이 공통적으로 호소하는 불만은 세 가지다. 내가 원하지 않는 정보를 AI가 자신 있게 만들어낸다. 인간 판단이 빠진 자동화가 나를 대체한다는 공포. 빅테크 플랫폼에 데이터와 습관이 종속된다는 감각.

엔지니어 관점으로 다시 읽으면 전부 공학 문제다. 첫 번째는 출력 검증 부재, 두 번째는 자동화 범위 설계 오류, 세 번째는 의존성 관리 문제다. 추상적 공포처럼 느껴지지만, 사실 우리도 이 세 가지를 전부 경험했다.

2026년 6월, kpopdex 봇이 실존하지 않는 아이돌 컴백 정보를 발행하는 사고가 났다. LLM이 위키피디아 요약부에 없는 앨범을 "창작"해서 뉴스로 올린 것이다. 실존 인물 관련 허위 정보는 AdSense 정지와 명예훼손 사이 어딘가에 있는 문제다. 가드레일이 없었던 탓이고, 결국 news_guard.py와 외부 API 교차검증 구조를 추가했다.

창원여성인력개발센터 같은 직업 훈련 기관에서 AI 활용 교육 수요가 급증하는 것도 같은 맥락에서 읽힌다. 사람들이 AI 자체를 거부하는 게 아니다. AI가 잘못 작동할 때 어떻게 대응해야 하는지 아무도 안 가르쳐줬던 것이다. 피하는 법을 배우러 도서관에 가는 건, 사용법을 모른다는 신호이기도 하다.

에이전트를 붙이기 전에 먼저 계산하는 것

우리가 새 작업에 LLM을 붙이기 전에 제일 먼저 묻는 질문이 있다. "이 출력이 틀렸을 때 손해가 얼마인가?"

블로그 콘텐츠는 틀려도 수정이 가능하다. 1500자 미만이면 재생성하면 되고, 내용이 이상하면 아카이브하면 된다. 반면 실존 인물 정보 — 아이돌 소속사, 버튜버 채널 정보 — 가 틀리면 수정 전에 이미 구글이 인덱싱하고, 사용자가 퍼 나른다. 롤백 비용이 비대칭적으로 크다.

그래서 파이프라인을 작업 유형에 따라 다르게 설계했다.

저위험 작업은 LLM 생성 → 글자수 검증(1500자 미만 재생성) → 발행으로 끝난다. 다이어트 팁, 보험 가이드처럼 사실 오류 허용 범위가 비교적 넓은 영역이다. 속도와 비용이 우선이다.

고위험 작업은 단계가 더 많다. LLM 생성 → Sonnet 모델로 2차 검수 → 외부 API 교차검증(Holodex, iTunes) → 발행. vtuberprofile은 발행 후에도 매일 06:40 vtuber_guard.py가 돌면서 소속사 정보를 실시간 재점검한다. 비용은 높지만, 허위 정보가 48시간 노출되는 것보다 훨씬 낫다.

직접 운영해보니 가장 위험한 시점은 "처음 잘 되는 것처럼 보일 때"였다. 에이전트가 일주일 동안 문제없이 돌아가면 감시를 늦추게 된다. 그 틈에 조용히 이상한 출력이 끼어든다.

수치로 보는 트레이드오프

현재 우리 파이프라인은 12개 사이트에 각각 일 발행 목표가 있고, LLM 비용 측면에서 생성 단계의 Haiku와 검수 단계의 Sonnet은 토큰 비용이 약 5~8배 차이 난다.

그래서 2단계 구조를 쓴다. 생성은 Haiku(빠르고 싸다), 판단이 필요한 지점만 Sonnet(정확하고 비싸다). kpopdex review_loop 기준으로 자동 검수 통과율은 대략 8590%다. 나머지 1015%는 Discord 알림으로 사람이 최종 판단한다.

완전 자동화를 포기하고 "10~15%는 사람이 본다"는 설계를 의도적으로 유지하는 이유가 있다. 에이전트가 확신을 갖고 틀리는 구간은 반드시 존재한다. 그 구간을 사전에 모두 예측할 수 없으니, 인간 검토 루프를 닫지 않는 편이 낫다는 결론이다. Discord 알림 하나로 사람이 10분 보는 게, 허위 정보 한 건 수습하는 것보다 압도적으로 효율적이다.

도서관 AI 기피 워크숍이 보여주는 것도 결국 이것이다. 인간 판단이 완전히 빠진 자동화에 대한 거부다.

실제로 바로 쓸 수 있는 네 가지 원칙

에이전트를 업무에 붙이려는 소규모 팀이라면, 우리가 사고 이후 실제로 박은 구조를 참고하면 시간을 아낄 수 있다.

작업을 "틀렸을 때 손해" 기준으로 먼저 분류하라. 고위험(실존 인물, 법령, 숫자)과 저위험(일반 정보, 아이디어, 요약)으로 나눈다. 고위험 작업에 에이전트를 먼저 붙이고 싶은 충동을 억제해야 한다. 거기서 사고가 난다.

출력 검증은 프롬프트가 아니라 코드로 강제하라. "정확하게 써달라"고 부탁하는 건 검증이 아니다. 글자수 미달이면 재생성, 특정 패턴이 감지되면 차단 — 이걸 조건문으로 박아야 LLM이 짧게 뱉거나 이상한 형식으로 나와도 막힌다. 우리가 1500자 게이트를 코드로 구현한 이유다.

인간 검토 루프를 의도적으로 하나 남겨라. 전체 자동화가 목표처럼 보이지만, "95% 자동 + 5% 사람"이 "100% 자동 + 사후 수습"보다 실제로 더 싸다. 그 5%의 이상한 케이스가 가장 비싼 사고를 막는다.

LLM 판단을 외부 데이터로 교차검증하는 구조를 만들어라. LLM이 "이 버튜버의 소속사는 A다"라고 말해도, 실제 Holodex API가 B를 반환하면 B가 맞다. 외부 데이터 교차검증 없이는 에이전트가 자신 있게 틀리는 상황을 원천 차단할 방법이 없다.

대중이 도서관으로 달려가 "AI 피하는 법"을 배우는 동안, 우리가 할 일은 AI가 잘못 작동할 때 어떻게 막을지를 설계하는 것이다. 그게 실전 적용이다.

원문: AI News & Artificial Intelligence | TechCrunch