AI 자동화 사례를 찾을 때, 주로 등장하는 것은 “성공 사례”입니다.
업무량이 몇 퍼센트 감소했다는 식으로 하는 것들.
저도 처음에는 그것을 읽었습니다. 그래서 따라 해서 똑같이 움직이는 지점까지 할 수 있었습니다.
문제는 바로 그 다음에서 비롯된 것이었습니다.
현재 PLai社에서는 30명의 AI 직원들이 매일 정해진 시간에 활동하고 있습니다. 기사를 쓰고, 데이터를 추출하고, 보고서를 작성합니다. 사람이 아침 알림을 주지 않아도 그 정도까지 발전했습니다.
그것에 이르기까지 고장 난 자동화는 총 6가지였고, 그 공통점은 명확하게 드러났습니다.
부서졌을 때, 아무 소리도 나지 않았습니다.
오류 때문에 멈춰서면 깨닫을 수 있을 텐데. 하지만 실제로 일어난 건 움직이는 것처럼 보이지만 잘못된 결과를 계속 반환하는 것이었다.
오늘은 그 사례를 5가지, 무슨 일이 있었고 무엇을 채워서 막았는지까지 상세히 적겠습니다. 잘 풀린 이야기는 없습니다.
AI 자동화의 사례는 성공 사례보다 “멈춘 이야기”에 더 큰 가치를 지닌다.
먼저, 왜 실패 사례를 나열하는지 한 단락으로 설명하겠습니다.
자동화를 도입할 때, 사람들은 보통 “정상적으로 작동하는지”를 확인합니다. 움직였다면, 출력이 나오면 괜찮습니다.
하지만 이 방법에는 결함이 있으며, “움직였다”와 “정답”은 서로 다른 개념입니다.
처리 결과는 끝까지 진행되었지만 내용이 오래되었고, 파일은 생성되었지만 내용이 비어 있었다. 검사는 통과되었지만 검사 대상 항목을 한 건도 읽을 수 없었다.
저에게 실제로 일어났던 일입니다.
그리고 가장 까다로운 점은, 이 정도의 고장은 성공 사례들만으로는 배울 수 없다는 것입니다. 성공 사례들은 “움직였다”로 끝맺음하고 있기 때문에, 그 이후의 상황을 파악하지 못하고 있습니다.
또 다른 점은 AI를 통합한 자동화에는 복잡한 측면이 있다는 것입니다.
평범한 프로그램은 입력이 깨졌을 때 멈추지만, AI는 멈추지 않고 그럴듯한 답변을 생성합니다.
이 부분이 결정적으로 다른데, 그래서 지금까지의 “예외가 발생하지 않으면 정상”이라는 해석이 통하지 않게 됩니다.
다음은 사례 5가지, 파괴 유형별로 나열합니다.
매일 달리던 데이터를 가져오지 못했는데, 5일 전 데이터만 계속 반환했습니다.
저희에게는 각 사의 공식 업데이트를 매일 아침 수집하는 프로세스가 있습니다. 수집한 결과를 장부에 저장하여 그 날 무엇을 쓸지 결정하는 데 사용합니다.
여기 두 개의 명령이 있었습니다. 하나는 가져오기 명령이고, 다른 하나는 장부에서 신선도를 기준으로 필터링하는 명령입니다.
그 쪽에만 가볍게 두드리면 “해당 없음”이라고 표시됩니다.
저기, 그것은 “오늘 업데이트가 없었던 것”인지, “실제로 가지고 있지 않았던 것이기에 비어있는 것”인지, 어느 쪽입니까?
서로 구별하기 어려웠어요. 똑같은 얼굴이 돌아다니는 것처럼요.
사과를 하자면, 이 두 가지는 이름도 비슷하고, 한쪽은 “가져오기”, 다른 한쪽은 “가져온 것에서 오늘 분을 고르는”이라는, 담당으로서의 연속적인 처리로 설계되었습니다.
또한 “該当なし”는 실무에서는 매일 보통으로 나오는 답변입니다. 업데이트가 없는 날도 있습니다. 따라서 의심할 만한 이유가 없습니다.
결과적으로 5일 동안 계속해서 좁히는 쪽만을 골라 선택하고 있었습니다. 깨달았을 때는 5일 전의 1차 정보를 “속보”로 1건 발표한 후였습니다.
속보를 자처하며 5일 전의 정보를 낸다. 이것은 독자에게는 가장 해서는 안 될 행동이다.
한 번 정보를 빠르게 전달한다는 것을 핵심으로 삼고 있는 이상, 신선도가 떨어지는 것 자체보다 신선도가 떨어지는 것에 우리가 인지하지 못하는 구조가 훨씬 더 문제라고 생각합니다.
들어간 관문은 이것입니다.
낡은 회계 장부를 열려고 하던 중 경고가 발생하여 멈췄습니다.
그 시간으로부터 24시간이 초과되면 컷오프 명령 측에서 오류로 종료된다.
가지가지하지 않은 것을 “해당 없음”으로 표현하지 않도록, 그것뿐입니다.
덧붙여서 또 한 가지를 수정했습니다. 획득 지점마다 마지막으로 정상이었던 시간을 각각 보관하도록 했습니다. 5개 중 1개만 떨어져 있는 상태가 이전에는 보이지 않아서 그랬습니다.
일반적으로는 이렇게 됩니다. 읽기만 하는 처리는 가져오는 처리가 실패했을 때 그 징후를 숨기고, 두 가지를 동일한 모습으로 반환하지 않도록 합니다.
사례 2: 이미지를 제작할 때, 기사에 언급되지 않은 금액이 표시에 나타나는 경우
이건 이해하기 어려운 상황입니다.
언젠가 게시글의 표지를 이미지 생성에 맡겼었습니다. 주제와 분위기를 전달하면, 그에 맞는 그림이 나오는 것이죠. 실제로 꽤 예쁘게 잘 나왔습니다.
어느 날, 비용에 대한 기사 표지에 7桁의 금액이 올라왔습니다.
글 내용 어디에도 쓰여있지 않은 숫자입니다. 모델이 “비용 관련 그림 같은 이미지”를 만드는 과정에서, 그것과 유사한 금액을 발상한 것입니다.
같은 주에 다른 기사에서는 다루지 않았던 회사의 로고가 2개가 생겼습니다.
기계 검사는 모두 통과했습니다. 글자는 깨지지 않고, 여백도 맞춰져 있으며, 튀어나온 것도 없습니다. 형식은 완벽하고 내용만이 거짓이라는 상태였습니다.
아니, 그렇게 직접 눈으로 봐도 알 수 있겠지?
저 역시 그렇게 생각했습니다만, 매일 15본 분량의 그림이 나오면 사람들은 “손상된 부분은 없는가”만 찾게 됩니다. 실제로 작성하지 않은 금액이 얼마인지 판단하려면 기사를 다시 읽어봐야 합니다.
들어가는 관문은 두 개입니다.
로고는 실 소재를 전달하여 그 위에 직접 그리지 않도록 합니다. 완성된 이미지에서 문구를 확인하고, 지시된 문구와 일치하는지 검토합니다. 불일치하는 문구가 있다면 다시 제작합니다.
이후 비슷한 일이 다시 발생했습니다. 그림 설명서 안에 전달하지 않은 판 번호가 2개 생겨버렸습니다. “이전 판의 태그”라고만 쓰고 실제 물건을 전달하지 않았다면 존재하지 않는 판 수를 만들어낸 것입니다.
배운 점은 AI에게 “예상 질문 확인란”을 남겨두면, 해당 칸은 반드시 채워진다는 것입니다. 빈 칸은 그대로 비워진 채로 나오지 않습니다.
그래서 지금은 그림에 넣고자 하는 단어들을 모두 여기서 전달합니다. 전달이 불가능한 단어는 그림 구성 자체를 변경하여 포함하지 않습니다.
제가 전달한 언어만으로 그림이 완성될 수 있을지 먼저 고려하게 되면서, 결과적으로 그림에 담기는 정보량은 줄었지만, 쓰지 않은 것이 그림에 나타나는 문제는 한 번도 발생하지 않았습니다.
그리고 현재도 남아있는 운영 방식이 하나 있습니다. 생성물은 반드시 사람이 열어보고 확인합니다. 기계가 보고 있는 것은 문자열의 대응 관계일 뿐이므로, 더욱 그럴듯한 거짓말은 눈으로만 감지할 수 있는 것입니다.
사례 3: “0건”을 합격으로 처리하고 있었다.
전장에 게시되지 않았는지 확인하는 검사가 있습니다. 과거 자사 블로그를 전부 읽어내려 40자 이상 일치하는 경우 중단하는 방식입니다.
그것은 어느 날, 코퍼스 읽기에 실패했습니다.
로딩 0건. 일치 대상이 0건. 일치 결과도 0. 판정 결과는 합격.
쓰고 있는데 어색하고 부끄럽네요. 그런 식으로 만들어진 작품이라서요.
검사 자체는 이미 멈춰 버린 상태인데, 가장 자신 있는 표정으로 통과시켜 온다. 게다가 평소와 출력 변화가 전혀 없다. “일치 0건”은 정상적인 날에도 나올 수 있는 표현이다.
즉, 검사가 살아있었고 아무것도 발견되지 않은 날과 검사가 죽고 아무것도 보이지 않은 날이 기록상으로는 완전히 똑같은 1행으로 남아있었던 것입니다.
예시 1과 같은 형태라는 것을 깨닫게 됩니다. 정상적인 결과와, 손상된 결과가 같은 문자열로 나타납니다.
들어간 검문소는 1개입니다. 0건은 합격이 아니며 “검사 불능”으로 불합격 처리합니다.
현재는 중복 키워드 검사도 동일하게 처리하며, 매칭을 위한 장부를 열람할 수 없으면 해당 게시물을 즉시 삭제합니다. “검토가 완료되지 않았으니 환불해 줍니다”라는 표현을 삭제했습니다.
저희는 이것을 3번 밟았습니다. 같은 형태의 구멍이 다른 장소에도 있었기 때문입니다. 검사를 만들 때마다 확인하는 문구를 정해놓고 있습니다. 이 검사는 대상이 한 건이라도 보이지 않을 때 어떤 말을 해야 하는지.
사례 4: 청소 자동화가 앞으로 배포할 파일을 삭제했습니다.
배포물을 놓으면 오래된 물건이 쌓입니다. 그래서 청소 처리를 추가했습니다.
규칙은 간단합니다. 장부에 기록되지 않은 파일은 삭제합니다.
이제 깔끔하게 정리될 것이라고 생각했습니다. 오히려 지나치게 정리되어 버렸습니다.
배포 절차는 다음과 같습니다. 파일을 위치시키고, 전송하며, 성공 시에는 장부에 기록합니다.
알겠습니다. 기록 장부에 적는 것이 마지막입니다.
그러다 청소가 시작되자마자, 지금 배포하려고 했던 파일은 “대장부에 기록되지 않은 파일”이었고, 삭제되었습니다.
게시물에서 사라진 결과가 404 오류가 아니었습니다. 154바이트의 빈 페이지를 200 상태 코드로 반환했습니다.
배포 로그에는 성공 메시지가 나타나고 있습니다. HTTP 코드를만 보았다면 합격으로 보일 것입니다. 실제로는 그 날의 확인은 “200 응답이 오면 OK”로 끝났었습니다.
내용물이 비어 있다는 것을 깨달은 것은, 배포한 상대에게서 “열어봐도 아무것도 나오지 않는다”라는 말을 들었을 때였다. 즉, 그것은 시스템이 아닌 사람에게서 비롯된 것이었다.
담은 것은 2개이다. 청소에 대해 “곧 배포할 물품은 이것입니다”라고 명확하게 전달한다. 그리고 확인은 개수와 내용으로 본다. 상태 코드는 확인하지 않는다.
일반적으로 청소 순서와 장부 기록 순서를 반드시 일치시켜야 합니다. 한쪽만 기준으로 설계하면 가장 최근에 만든 것이 먼저 사라질 것입니다.
AI 직원 수를 늘릴수록 이러한 문제가 발생하기 쉬워집니다. 제작 및 정리 담당이 분리되면서 순서의 일관성을 아무도 확인하지 않은 상태가 자연스럽게 나타납니다.
사례 5: 인증을 해지했음에도 불구하고, 본문만 계속 배포되었다.
마지막으로, 지웠다고 생각했는데 지워지지 않았다는 이야기입니다.
사내 확인용 페이지에서 인증을 진행하고 있었습니다. 이후 방식이 변경되면서 인증 메커니즘을 완전히 제거하고 새로운 URL로 재배포했습니다.
며칠 후에 혹시 모를 사태에 대비해 이전 URL에 접속한 결과, 비밀번호 없이 모든 내용이 그대로 돌아왔습니다.
범인은 스트리밍 네트워크의 캐시였습니다. 인증을 시도했던 부분을 삭제했음에도 캐시에만 남아 있던 본문만이 계속해서 배포되었습니다.
자신이 수행한 “삭제” 조작을 근거로 하고 있었던 것은 잘못된 것이었습니다. 삭제된 것은 시스템이었고, 이미 배포된 복사본이 아니었기 때문입니다.
우선, 3장을 겹쳐 대응책을 마련했습니다. 현금을 보관하지 않도록 명시하는 지시를 명확히 하고, 배포할 때마다 URL의 암호 자체를 재설정하여 기존 URL을 폐기했습니다. 최후의 수단으로 해당 위치를 완전히 재구성했습니다.
여기에서 얻는 깨달음은 한 문장입니다. 그 깨달음을 얻기 위해 제거했는지 여부는 제거한 사람의 의도가 아니라, 외부에서 얻은 결과로 확인해야 합니다.
5가지 사례에 공통적으로 존재했던 단 하나의 것
병렬적으로 살펴보니, 원인은 각각 상이합니다. 신선도, 이미지 생성, 검사, 청소, 캐시 등입니다. 담당 처리도 각각 분리되어 있습니다.
하지만 부서지는 방식은 모두 똑같았습니다.
성공과 실패를 판단할 수 없는 출력을 반환하고 있었다.
“該当なし”라는 용어는 두 가지 의미를 갖는다. 기록되지 않은 금액이 정확한 그림과 동일한 형태로 나타나고, 0건이 합격되는 경우를 의미한다. 빈 페이지가 200페이지로 반환되고, 지워졌어야 할 내용이 정상적으로 열리는 현상이다.
정상적인 경우와 비정상적인 경우를 분리하여 설계하는 한 가지 단계를 아무도 제대로 실행하지 않았기 때문입니다.
그래서 저희가 자동화 시스템을 만들 때 마지막으로 확인하는 것은 작동하는지 여부가 아니라 되었습니다.
듣는 내용은 다음과 같습니다. 그것은
이것이 고장 났을 때, 고장 났음을 명확하게 확인할 수 있는 형태로 나타나는지 확인해야 합니다.
95/114번 본문 청크의 내용이 제공되지 않았습니다.
부러진 것을 확인할 수 있는 세 가지 방법
저희가 실제로 사용하는 기술 3가지를 소개합니다.
첫째, 출력을 분리한다. 같은 “없음”이라도 “검토 결과 없음”과 “검토 불가”를 다른 표현으로 반환시킨다. 사례 1과 사례 3은 이 방법으로 해결되었다. 가장 저렴하고, 가장 효과적이다.
두 번째는 외부에서 측정한다. 자신이 무엇을 했는지 아닌지 아닌, 외부에서 다시 취득한 결과로 판단한다. 사례 4와 사례 5는 이것이다. 배포했다면 획득하여 내용을 확인하고, 삭제했다면 쳐서 확인한다.
마침내 성공했을 때만 남는 표시를 남긴다. 시간, 건수, 도장 등 어떤 것이든 상관없다. 표시가 없다면 중단된 것으로 판별할 수 있다. 이 표시가 없다면 사례 1의 “5일간 알아차리지 못하는” 상황이 재발할 수 있다.
순서는 일단 정해져 있으며, 첫째, 둘째(다음), 마지막으로 셋째입니다. 출력을 분리하는 것은 코드를 몇 줄 더하는 것뿐이지만, 겉으로 측정하는 것은 시스템을 1개 늘리는 문제에 해당합니다.
오늘 30분 안에 가능한 일
이미 어느 정도 자동화를 진행하고 있다면, 한 가지만 선택해 주세요. 매일 실행되는 것을 선택하는 것이 좋습니다.
그리고 이렇게 물어보아 보세요.
제가 오늘 아무것도 하지 않았더라면, 제가 알아챌 수 있었을까요.
알아채지 못한다면, 그것이 약점입니다. 저희의 5가지 사례 모두 이 질문에 대해 “알아채지 못했다”는 답변으로 돌아왔습니다.
반대로 말하면, 이 질문에 답할 수 있도록 구성해 놓으면 실제로 망가질 것을 막을 수는 없지만, 망가진 채로도 몇 날 며칠 계속 돌아가는 가장 비싼 상태만은 피할 수 있습니다.
할 일은 단 하나뿐입니다. 성공했을 때만 나타나는 도장을, 어디에나 남겨둡니다.
다음 날, 그 표시가 없었다면 멈췄을 것이라는 사실이 밝혀졌다. 그것만으로도 5일 동안 알아채지 못했다는 것은 일어나지 않는다.
성공 사례를 모으는 것보다, 아마 이 방법이 더 빠를 거예요. 적어도 저희 집에서는 이 순서대로 다시 시도한 후에, 고장나도 반나절 만에 찾게 되었습니다.
AI 직원 도입으로 기존 수작업 방식의 업무를 자동화하고, 완료된 태스크를 명확하게 나타내는 “완료 마크”를 종료의 증거로 활용하게 되었다. 구체적으로 AI 직원이 처리한 데이터나 서류를 완료 시점에 완료 마크로 표시하고, 그 마크가 기록된 데이터베이스를 기초로 업무 진행 상황을 시각화했다. 이를 통해 업무 효율화는 물론 AI 직원의 성과를 객관적으로 평가할 수 있게 되었으며, 완료 마크의 기록은 AI 직원의 잘못된 처리에 대한 신속한 원인 규명과 대책 수립의 중요한 증거가 되었다.
30명의 AI 인력을 매일 운영하는 데 사용하고 있는 설계와, 어려움을 겪었던 부분을 정리한 자료를 준비했습니다. 앞으로 사내에서 자동화를 구축하는 데 활용될 예정입니다.
AI 직원에게 12가지 혜택을 받으세요.
AI 자동화, AI 직원, 업무 자동화, 사례, 내製, 품질 관리, ClaudeCode, 정기 실행, 검사 설계, 생성 AI, 경영, 시스템화
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 81청크
원문 보기 | 출처: note.com