자동화가 "돌았다"와 "됐다"는 다릅니다: 작은 회사를 위한 실행 루프
2026. 09. 02. 00:50
작은 회사에서 자동화를 만들면 아주 흔한 착각이 하나 있습니다. 코드가 에러 없이 돌면 성공한 것 같다는 착각입니다.
저희는 화장품 소량 OEM 견적을 자동으로 계산해 주는 사내 도구를 만든 적이 있습니다. 잘 돌았습니다. 숫자도 깔끔하게 나왔습니다. 그런데 과거에 실제로 고객에게 발행했던 견적서와 나란히 놓고 대조해 보니, 결과가 크게 벗어나 있었습니다.
원인은 버그가 아니었습니다. 계산식 자체는 정확했고, 서로 다른 상황에서 쓰던 조건값이 한 세트로 섞여 들어가 있던 것이 원인이었습니다. 코드는 정상 동작했지만 목적은 달성되지 않은 상태였습니다. 그리고 이걸 발견한 건, 실제로 발행했던 문서와 직접 대조했을 때뿐이었습니다.
그래서 실행을 이 루프로 씁니다
BOOT → THINK → DECIDE → EXECUTE → VERIFY → LEARN → 다시 BOOT
BOOT
시작 전에 현재 목표, 관련 상황(Context), 이미 승인된 결정, 최근 인수인계를 복원합니다. 기억에 의존해서 시작하지 않습니다.
THINK
선택지만 보지 않고 반대 가설과 리스크를 같이 봅니다. "이게 틀렸다면 어디서 틀렸을까"를 먼저 적습니다.
DECIDE
실행 범위와 성공 기준을 먼저 정합니다. 아직 못 정한 건 "안 정했다"고 명시적으로 남깁니다. 이걸 안 남기면 나중에 정해진 것처럼 굳어집니다.
EXECUTE
작게 실행합니다. 하다가 범위를 넓히지 않습니다.
VERIFY
여기가 핵심입니다. "코드가 실행됐다"와 "목적이 달성됐다"를 분리합니다. 저는 네 가지로 확인합니다.
기능이 실제로 동작하는가
기존에 되던 것을 깨지 않았는가
사람이 하던 시간을 실제로 줄였는가
고객 또는 매출에 연결되는가
LEARN
새로 확인된 사실을 다음 실행자가 재사용할 수 있게 남깁니다.
기대값 → 실제 결과 → 차이 → 학습 → 다음에 강제할 지점
LEARN이 없으면 자동화는 같은 실수를 더 빠르게 반복할 뿐입니다.
또 하나의 사례
고객 문의를 AI로 자동 분류하게 만든 적이 있습니다. 그런데 채용 공고 알림 메일을 고객 문의로 태깅하고 있었습니다. 분류기는 멀쩡히 "돌고" 있었죠. 발신 도메인 필터 하나만 추가해도 상당 부분이 정리되는 문제였는데, 그걸 알 수 있었던 건 결과물을 사람이 표본으로 직접 열어봤기 때문입니다.
자동화의 출력은 그 자체로 증거가 아닙니다. 사람이 한 번은 원본과 대조해야 증거가 됩니다.
마지막 기준 하나
자동화가 늘었는데 대표가 기억하고 관리해야 할 항목도 같이 늘었다면, 설계를 다시 의심합니다.
자동화의 목적은 처리량을 올리는 게 아니라 사람의 인지부하를 낮추는 것입니다. 좋은 운영체계라면 화면에 이 네 가지만 남습니다. 현재 목표, 현재 상태, 다음 한 단계, 판단이 필요한 예외.
루프 전문과 공개용 예시 문서는 아래 저장소에 정리해 두었습니다. 내부 원본이 아니라 일반화·비식별화한 공개 파생본입니다.