AI 에이전트가 망가지면 사용자가 맞는다

OpenAI 에이전트 여러 개가 통제를 벗어났다는 보도가 나왔다. Hugging Face 사건을 파고들다가 비슷한 오작동 사례를 추가로 발견했다는 내용이다. 기술 커뮤니티에서는 "대형 AI 연구소도 저러는데"라는 반응이 많지만, 나는 다른 데 눈이 갔다.

에이전트가 망가졌을 때 피해가 최종적으로 어디 떨어지느냐는 질문.

답은 항상 사용자다. 에이전트를 만든 조직은 사후에 수습하고, 원인을 분석하고, 개선 조치를 발표할 수 있다. 그 사이 에이전트가 뱉어낸 잘못된 결과를 받아 든 사람은 이미 그것으로 무언가를 결정했을지 모른다. 단, 이 원칙이 자동화를 쓰지 말라는 결론으로 이어지는 건 아니다. 어떻게 붙이느냐의 문제다 — 이게 이 글에서 이야기할 핵심이다.

에이전트 오작동이 제품 문제가 되는 순간

기술적으로 "에이전트가 오작동했다"는 진단은 비교적 명확하다. 의도한 범위를 벗어난 행동을 했다는 거다.

문제는 그 행동의 결과가 어디 붙어 있느냐다. 내부 테스트 환경에서 멈췄으면 기술 문제로 처리할 수 있다. 그런데 그 에이전트가 실제 사용자에게 콘텐츠를 발행하거나, 사용자 데이터를 처리하거나, 사용자 대신 어떤 행동을 취하는 제품 안에 있다면 오작동은 즉시 제품 문제가 된다.

AI 개발 툴이 빠르게 발전하면서 에이전트를 서비스에 붙이는 진입장벽이 1년 전보다 훨씬 낮아졌다. 근데 에이전트가 강력해질수록 오작동 시 피해 범위도 같이 커진다. 진입장벽이 낮아졌다고 해서 제품 책임도 낮아지는 게 아니다. 이번 OpenAI 보도가 다시 상기시키는 지점이 여기다.

우리도 당했다 — 가짜 컴백 사건

우리가 운영하는 kpopdex는 실존 아이돌 디스코그래피를 다루는 서비스다. 6월 말, 배치 스크립트를 한 번 잘못 돌렸다. kpop_album 테이블에 멤버 포토카드 버전과 가짜 컴백 데이터가 섞여 들어갔고, 그게 그대로 뉴스 발행 파이프라인을 탔다.

결과: 실제로 나오지 않은 앨범이 "컴백 소식"으로 발행됐다. 실존 아이돌 이름을 달고.

단순 버그가 아니다. 실존 인물 관련 허위 정보를 자동으로 양산한 케이스다. 아이돌 팬들은 컴백 정보에 굉장히 민감하다. 틀린 정보를 한 번 발행했다면, 그 사이트의 신뢰는 그 순간부터 내려가기 시작한다. "수정했습니다"로 되돌려지지 않는 피해가 있다. 사용자 입장에서는 우리 사이트 기사가 틀렸다는 것만 남고, "배치 스크립트 문제였다"는 내부 사정은 아무 의미가 없다. 심한 경우 명예훼손 이슈로 번질 수 있고, AdSense 정책 위반으로 광고가 내려가는 건 그나마 경미한 편이다.

vtuberprofile에서는 비슷한 리스크를 다른 방식으로 경험했다. 버튜버 소속사를 잘못 분류하면 역시 실존 인물 정보가 틀리는 거다. 사전에 Holodex API로 442명을 전수 교차검증했을 때 자동 조치 건수는 0건이었다. 기존 파이프라인이 잘 작동하고 있었다는 확인이기도 하지만, 가드가 없었다면 언제든 미끄러질 수 있는 구조였다.

자율성이 높을수록 피해도 빠르다

AI 에이전트를 제품에 붙이면 가장 먼저 마주치는 선택이 있다. 얼마나 자율적으로 둘 것인가.

자율성이 높으면 팀이 직접 챙겨야 할 일이 줄고 발행 속도가 오른다. 우리 봇들이 매일 12개 사이트에 콘텐츠를 올릴 수 있는 것도 그 덕분이다. 반대로, 자율성이 높을수록 에이전트가 틀렸을 때 피해가 빠르게 퍼진다. 사람이 개입하는 루프가 없으면 오류는 자동화만큼 빠른 속도로 확산된다.

OpenAI 에이전트들이 "멋대로" 실행됐다는 건 이 자율성 설계가 예상 범위를 벗어났다는 뜻이다. 연구소 수준의 조직도 이걸 완벽히 통제하지 못한다. 소규모 팀이 AI 개발 툴을 가져다 붙일 때 이 문제가 더 작아지는 게 아니다. 오히려 모니터링 인력이 없어서 발견이 늦다.

현실적인 숫자를 하나 들면, 우리 review_loop는 Claude Sonnet으로 발행 후보를 자동 검수한다. OK 판정은 유지, REJECT는 자동 아카이브, WARN은 디스코드 알림으로 사람이 확인한다. 이 루프 하나가 없었다면 잘못된 콘텐츠가 그냥 올라간다. 자동화의 속도를 유지하면서 최소한의 안전망을 끼워 넣는 구조다. 완벽하진 않지만, 없는 것보다 훨씬 낫다.

가드레일의 진짜 비용

사고 후 우리가 만든 것들이 있다. seed_news.py의 is_newsworthy() 필터는 변형판·미래발매·멤버 포토카드 버전을 발행 전에 걸러낸다. news_guard.py는 이미 발행된 뉴스를 매일 04:30에 재점검해서 문제가 있으면 자동으로 아카이브한다. LLM도 외부 API도 쓰지 않아 비용은 거의 0이다. 이 둘이 이중 차단 구조를 이룬다.

효과는 분명하다. 그런데 솔직하게 말하면, 이 가드레일을 설계하고 테스트하는 데 사고 수습보다 더 많은 시간이 걸렸다.

가드레일의 진짜 비용은 엔지니어링 시간만이 아니다. 발행 속도가 떨어지고, 규칙이 너무 빡빡하면 정상 콘텐츠도 막힌다. MIN_BODY_CHARS=1500 게이트를 도입했을 때 초기엔 정상 글이 스킵되는 일이 있었다. 규칙도 틀린다. 가드레일 자체가 또 다른 오작동 소스가 될 수 있다는 말이다.

"붙이면 해결"이 아니라, 가드레일 도입이 새로운 트레이드오프의 시작이다. 어디서 선을 그을지는 계속 조정해야 한다.

"AI가 그랬다"는 변명이 통하지 않는다

제품 관점에서 가장 중요한 지점이 이것이다.

OpenAI는 에이전트 오작동을 조사하고 결과를 발표할 수 있다. 대형 조직이라 커뮤니케이션 채널도 있고 브랜드 자산도 있다. 우리 같은 작은 팀이 운영하는 서비스에서 "AI 에이전트 오작동이었다"는 해명은 사실상 무의미하다. 사용자는 브랜드를 보지, 내부 파이프라인을 보지 않는다.

Threads 계정 자동화 스팸 플래그로 계정이 비공개됐던 경험도 같은 맥락이다. 우리 봇은 정상 발행을 했다고 생각했지만, 플랫폼은 그걸 스팸으로 봤다. 사용자(여기선 플랫폼)의 기대를 벗어난 순간 제재가 온다. 에이전트를 제품에 붙이는 결정은 그 에이전트가 사용자에게 끼칠 수 있는 피해에 대한 책임도 함께 붙이는 결정이다.

지금 바로 할 수 있는 것

에이전트를 서비스에 붙이고 있거나 붙이려 한다면, 세 가지를 먼저 점검하는 게 현실적이다.

에이전트 출력이 사용자에게 닿는 경로를 그려라. 그 경로 위에 사람이 개입하는 지점이 어디인지. 없다면, 자동 검수라도 있는지. 경로를 명시적으로 그려보는 것만으로도 구멍이 보인다.

오작동 시나리오를 시뮬레이션하라. "이 에이전트가 예상과 다른 출력을 냈을 때, 최악의 경우 어떤 피해가 발생하는가?" 실존 인물 정보나 금전적 판단에 영향을 주는 출력이라면 가드레일 우선순위가 높아진다. 피해 규모가 명확할수록 어디에 자원을 쓸지도 명확해진다.

마지막으로, 모니터를 에이전트보다 먼저 만들어라. 빠르게 붙이고 싶은 유혹은 이해하지만, 모니터 없이 붙인 에이전트는 오작동을 발견하는 시점이 너무 늦다. 우리가 news_guard와 vtuber_guard를 에이전트 이후가 아니라 사고 이후에 만든 건 솔직히 아쉬운 순서였다. 지금이라면 모니터를 먼저 설계하고 에이전트를 붙일 것이다. LLM 없이 규칙 기반으로만 도는 모니터라도 비용은 거의 0이고, 효과는 충분하다.

원문: AI News & Artificial Intelligence | TechCrunch