개인 개발로 AI 에이전트에게 실무를 맡기는 조직을 만들어 실제로 운용해 왔습니다. 이 기사에서는 그 과정에서 실제로 겪었던 실패 사례를 몇 가지 소개합니다. 날짜나 로그의 실제 수치는 숨겼지만, 일어난 일과 수정한 내용은 각색하지 않았습니다.

「성공 0건」을 성공이라고 계속 보고했던 파이프라인

가장 무서웠던 것은 이것입니다.

영업 제안 자동 전송 파이프라인을 구축했습니다. 정보 수집 역할을 하는 에이전트가 대상을 찾고, 분석 역할이 평가하며, 실행 역할이 전송합니다. 로그에는 매번 다음과 같이 표시되었습니다.

실행 보고: 수집→분석→전송 chain 완료 ... 성공 0건/실패 0건

「실패 0건」만 보면 아무런 문제가 일어나지 않은 것처럼 읽힙니다. 실제로는 달랐습니다. 전송 대상이 0건인 상태로 며칠 동안 처리가 「정상 종료」되고 있었던 것입니다. 에러는 한 번도 발생하지 않았습니다. 그래서 아무도 눈치채지 못했습니다.

이는 전형적인 「옵저버빌리티 (Observability, 가관측성)」 부족 문제였습니다. 로그가 "에러 없음"을 나타내더라도, 내부에서 실제로 무엇이 일어나고 있는지를 가시화하지 못하면 이상 징후는 며칠이고 계속 숨겨집니다.

원인은 단순했습니다. 파이프라인이 「에러 없이 완료되었다는 것」과 「실제로 무언가를 보냈다는 것」을 구분하지 않았기 때문입니다. 0건 처리라도 예외(Exception)만 던지지 않으면 ✅가 나오는 설계였기에, 이상 징후가 수일 단위로 방치되었습니다.

대응책은 완료 로그의 판정 기준에 「결과물의 유무」를 필수 조건으로 추가한 것입니다. 건수가 0이라면 설령 예외가 발생하지 않았더라도 실패로 처리합니다. 당연해 보이지만, 이를 수행하지 않는 파이프라인은 놀라울 정도로 많을 것입니다.

교훈: 「에러가 나지 않는다」와 「업무가 끝났다」는 동일하지 않습니다. AI 에이전트의 운용 로그를 볼 때는 성공/실패의 이진(Binary) 값이 아니라 「몇 건을 처리했는가」를 반드시 세트로 확인해야 합니다.

AI는 동일한 최적해로 무한히 수렴한다

SNS 자동 게시 실험에서의 일입니다. 「반응이 좋을 만한 게시물을 만들어줘」라고만 지시하는 설계로 했습니다.

그 결과, AI는 매번 거의 비슷한 관점의 게시물을 계속해서 만들어냈습니다. 인간이라면 10개 정도 비슷한 게시물을 쓰면 「슬슬 질린다, 이제 좀 바꿔야겠다」라고 생각하겠지만, AI는 질리지 않습니다. 통계적으로 가장 반응이 좋을 법한 패턴을 찾으면 그곳으로 매번 수렴합니다. 깨달았을 때는 실질적으로 같은 주장인 게시물이 30개 가까이 연속으로 나열되어 있었습니다.

대책으로서 최근 게시물과의 유사도를 기계적으로 체크하여, 일정 수준 이상 비슷할 경우 자동으로 기각하는 로직을 넣었습니다. 다양성은 기도한다고 나오는 것이 아닙니다. 제약으로서 구현해야 합니다.

교훈: AI는 「질린다」는 감각을 가지고 있지 않으므로, 다양성을 원한다면 명시적인 다양성 제약(유사도 체크·로테이션)을 시스템 측에 구축해야 합니다.

너무 빠른 자동화는 들킨다

이것은 단순한 설정 실수였지만, 피해는 가장 컸습니다.

게시 간격 설정을 잘못하여 1분 만에 10건에 가까운 게시물이 연속으로 전송되었습니다. 인간의 조작 속도로는 불가능한 패턴입니다. 예상대로 계정은 동결되었습니다.

자동화의 실패라고 하면 「느리다」거나 「시간이 오래 걸린다」는 것을 상상하기 쉽지만, 실제로 사고를 일으키는 것은 「너무 빠르다」는 쪽입니다. AI는 지치지 않기 때문에 제한을 걸지 않으면 인간의 수십 배 속도로 동일한 조작을 반복할 수 있습니다. 그것이야말로 기계라는 증거가 되어 탐지되는 가장 큰 요인이 됩니다.

교훈: 자동화의 적은 느림이 아니라 빠름입니다. 인간다운 간격과 변동성을 의도적으로 시스템에 포함시켜야 합니다.

임계값은 책상 위에서 결정하면 반드시 틀린다

프로젝트 자동 지원 파이프라인에서 지원 여부를 판단하기 위해 스코어링(Scoring)을 사용하고 있었습니다. 임계값을 12점으로 설정했었는데, 나중에 실제 데이터를 확인해 보니 실제 프로젝트에서 도달했던 최고 점수는 7점이었습니다.

즉, 임계값이 너무 높아서 파이프라인이 작동하기 시작한 이후로 단 한 번도 지원이 발생하지 않았던 것입니다. 이는 앞서 언급한 「성공 0건」 문제와 뿌리가 같으며, 「조용히 아무것도 하지 않는」 상태는 에러 로그로 검지할 수 없습니다.

교훈: 게이트(Gate) 수치는 먼저 실제 데이터를 보고 결정한다. 결정한 후에도 초기 운용 단계에서 「정말로 무언가 통과하고 있는가」를 반드시 확인한다.

운영 환경에 직접 쓰게 해서 망가뜨린 이야기

이것이 가장 명확한 설계 미스였습니다.

초기 설계는 AI 에이전트가 웹사이트 개선 제안을 만들고, 그대로 HTML 파일을 직접 수정하여 운영 환경(Production)에 push하는 완전 자율 플로우였습니다. 인간의 확인을 거치지 않는다는 전제였습니다. 이 플로우는 「운영 환경 파괴 리스크」로서 명확한 설계 실패로 인정되어 폐지되었습니다.

재설계된 플로우는 다음과 같은 5단계 구성이 되었습니다.

분석 → 제안 생성 → (인간에게 제시) → 인간이 승인 →
백업 취득 → AI가 수정 → 검증 → git push
→ (실패 시 백업으로부터 자동 복원)

교훈: 「AI에게 실행력을 부여하는 것」과 「취소할 수 없는 곳에 직접 쓰게 하는 것」은 별개의 문제입니다. 자율화를 진행하는 순서로서 유효했던 것은, 「먼저 제안만을 자동화하고, 인간의 승인 단계를 거치며 운용 실적을 쌓은 뒤, 적용까지 자동화한다」는 단계적인 접근 방식이었습니다.

규칙을 써도, 왜인지 같은 버그가 몇 번이고 재발한다

마지막은 가장 수수하지만 가장 뿌리 깊은 이야기입니다.

「코드를 생성할 때는, 도중에 출력을 끊지 말고 마지막 닫는 괄호·닫는 태그까지 반드시 끝까지 작성할 것」이라는 규칙을 명문화하여 AI에 대한 지시(Instruction)에 포함했습니다.

그럼에도 불구하고, 시간이 흐른 뒤에도 몇 번이고 같은 불합격 사례가 재발했습니다. 인간이라면 한 번 실패하면 학습하지만, AI 에이전트(AI Agent) 운용에서는 그것을 기대할 수 없습니다.

효과가 있었던 대책은, 규칙을 말로 전달하는 것을 그만두고 생성 후에 기계적인 검증을 강제 훅(Hook)으로 끼워 넣는 것이었습니다. 코드라면 구문 체크(Syntax Check)를 자동 실행하는 식입니다.

교훈: 지식은 「쓰는 것」만으로는 정착되지 않습니다. 같은 실수를 반복하지 않게 하려면, 검증 게이트(Verification Gate)라는 「기계적인 강제 체크」로 구현할 필요가 있습니다.

지금까지의 6가지 이야기에 공통적으로 흐르는 것은, 모두 「AI가 게으름을 피운」 것이 아니라는 점입니다. AI는 지시된 대로, 오히려 충실하게 움직이고 있었습니다. 망가진 것은 그 주변에 검증 메커니즘이 부족했기 때문입니다.

이 6가지를 포함하여, AI 에이전트 조직을 실제로 운용하며 배운 설계·실패·개선의 기록을 조금 더 자세히 정리한 책을 썼습니다. 권한 설계의 패턴, 자율 플로우의 표준 패턴, 복사해서 바로 쓸 수 있는 템플릿 모음도 수록되어 있습니다. 관심이 있다면 한 번 살펴보시기 바랍니다.

Discussion