가이드 · AI

AI 에이전트를 만들며 세 번 버린 것

2026. 07. 11 · 6분 읽기

제품을 만드는 AI 팀을 슬랙에 두고 있습니다. 이 팀이 코드를 쓰고, 버그를 찾고, 자기 코드를 고쳐서 배포합니다.

만들면서 같은 실수를 세 번 했습니다. 매번 다른 얼굴로 왔지만 병은 하나였습니다. LLM이 판단해야 하는 자리에 규칙(키워드·정규식)을 박은 것입니다.

첫 번째: 중단 명령

작업을 멈추라는 지시를 감지하려고 "그만 / 멈춰 / 하지마 / stop"을 정규식으로 잡았습니다.

사고가 났습니다. "이거 어때?" 같은 평범한 질문이 오탐에 걸려 진행 중이던 작업을 죽였습니다. 패치를 7번 쌓다가 결국 전부 버리고 LLM 판단으로 넘겼습니다.

"분석만 하고 실행하지 마"를 구분하려고 동사 목록을 만들었습니다. 분석 동사와 실행 동사를 나눠서 매칭했습니다.

이번엔 "맞아?" 같은 일반 질문이 분석 의도로 잡혔습니다. 그리고 차단 메시지에 내부 용어가 그대로 실려 사용자에게 노출됐습니다. 또 버렸습니다.

여기서 "이번엔 다르다"고 확신했습니다. 키워드가 아니라 결정론적 신호를 쓰기로 했으니까요 — 글자 수 250자 이상, 번호 목록 3개 이상, 특정 단어 포함. 규칙이 아니라 수치니까 안전하다고 봤습니다.

아니었습니다. 사용자가 채용 공고를 붙여넣자 그 안의 "1. 2. 3." 번호와 "기획"이라는 단어가 조건을 채웠습니다. 단순한 글쓰기 요청이 중장비 분해 작업으로 오발동했고, 결과는 빈손이었습니다.

여기서 진짜 원인을 알았습니다. 사용자가 붙여넣는 자료가 신호를 오염시킵니다. 우리는 "사용자의 의도"를 센 게 아니라 "붙여넣은 자료"를 센 거였습니다.

세 번 겪고 정리한 결론입니다.

지금은 이 기준으로 나눕니다.

순수하게 기계적인 판단(경로가 존재하나, 깊이 제한, DB 잠금) → 규칙으로 해도 됩니다.
자연어의 의미를 판단 → 무조건 LLM에게 맡깁니다. 규칙은 프롬프트에 넣습니다.
예외: 걸려도 손해가 0인 자리 → 규칙 OK. 예를 들어 "○○씨 있어요?" 같은 순수 호출을 정규식으로 잡아 인사만 하는 건, 틀려도 인사 한 마디라 무해합니다.

판별 기준은 하나입니다. 오발동했을 때 파괴적인가. 작업을 죽이거나, 차단하거나, 빈손으로 만든다면 — 거기엔 규칙을 넣지 마세요.

당선율을 가른 건 디자인이 아니라 '언제 냈느냐'였습니다. 마감 임박 56건의 당선은 0건이었습니다.

돈을 받을 이유가 없는 건 그냥 드립니다. 대신 받을 이유가 있는 걸 만듭니다.