AI 자동화 감사 능력 — 검증할 수 없는 워크플로우의 기술 부채
지난달, 제가 6개월 전에 만든 Zapier 워크플로우가 멈췄어요. Airtable에서 데이터를 뽑아 Claude API로 요약하고 Slack에 올리는 자동화였습니다. 문제는 어디서 틀렸는지 찾는 데 3시간이 걸렸다는 겁니다. 저는 이게 진짜 함정이라고 봐요. 자동화는 성공했는데, 그걸 감사할 능력이 없다면 그건 기술 부채를 쌓는 것과 같거든요.
자동화를 이해하지 못한 채 쓰면 무슨 문제가 생기나요?
제가 처음 Zapier와 Make를 배웠을 때는 신났습니다. 코드 한 줄 없이 Gmail에서 특정 키워드가 들어온 메일을 파싱해서 HubSpot에 자동 등록했거든요. Claude API를 붙이니까 자연어 지시로 복잡한 로직도 돌아갔죠.
어느 날 HubSpot에 중복 레코드가 17건 생겼어요. 워크플로우 로그를 봐도 뭐가 문제인지 모르겠더라고요. LLM이 생성한 JSON 필터 로직이 있었는데, 제가 그걸 이해 못 하는 거예요. "일단 돌아가니까 됐지"라며 넘어갔던 부분이었거든요. 결국 그 워크플로우를 끄고 처음부터 다시 만들었습니다.
제 주변 사례를 보면 비슷한 상황이 많아요. 한 지인은 PDF에서 작업 지시서를 자동 추출하는 자동화를 굴리는데, 틀렸을 때 알아챌 수단이 없어 불안하다더군요. 맞아요. 검증할 능력이 없는 자동화는 시한폭탄이거든요.
제가 운영하는 워크플로우가 지금 12개인데, 그중에서 제가 완전히 이해하는 건 4개뿐이에요. 나머지 8개는 "돌아가니까 건드리지 말자" 상태죠. 이게 편하긴 한데, 장애가 나면 복구 시간이 평균 2시간은 걸립니다. 이해하는 워크플로우는 10분이면 고치는 걸요.
전문가 고용 전까지 버틸 수 있을까요?
많은 분이 "어차피 나중에 개발자 고용하면 되지 않나요?"라고 물어보세요. 근데 그 '나중'이 생각보다 길어요.
제 경우엔 자동화를 굴린 지 8개월째인데 아직 전문가를 못 구했습니다. 예산도 문제지만, 제가 만든 스파게티 워크플로우를 넘겨받을 사람이 있을까 싶기도 해요. 실제로 면담한 개발자가 제 Zapier 설정 보더니 "이거 처음부터 다시 짜는 게 나을 것 같은데요"라고 하더군요. 이미 레거시가 된 거죠.
더 큰 문제는 그동안의 리스크 누적이에요. 자동화가 6개월 동안 고객 데이터를 잘못 처리했는데 제가 모르고 있었다면요? 감사 능력이 없으면 그런 걸 사후에 발견해도 언제부터 틀렸는지 추적이 안 됩니다. 제가 실제로 겪은 일인데, 한 워크플로우가 5주 동안 특정 조건에서 Slack 알림을 빼먹고 있었어요. 로그에 에러도 안 남았고요.
테스트나 로그로 커버하면 되는 거 아닌가요?
"테스트를 잘 짜면 이해 못 해도 괜찮지 않나요?"라는 반론도 있을 겁니다. 이론적으로는요. 문제는 제가 테스트를 제대로 짤 수 있는 수준이 아니라는 겁니다.
Zapier나 Make 같은 노코드 툴은 단위 테스트 개념이 약해요. 전체 워크플로우를 실행해보는 게 전부죠. 그것도 제가 생각한 시나리오만 테스트하게 되고요. 예상 못 한 엣지케이스는 검증이 안 됩니다. LLM이 생성한 로직은 특히 더 그래요.
로그도 마찬가지예요. 로그가 쌓이긴 하는데, 제가 뭘 봐야 할지 모릅니다. 한번은 LLM이 생성한 JSON에 특수문자가 들어가서 파싱 에러가 났는데, 로그에는 그냥 "failed"만 찍혔거든요. JSON 구조를 이해해야 문제를 찾을 수 있었는데, 제가 그걸 몰랐으니까요.
테스트와 로그는 이해를 대체하는 게 아니라 보완하는 도구입니다. 내가 뭘 만들었는지 알아야 뭘 테스트할지, 로그에서 뭘 찾을지 알 수 있어요.
감사 능력이 없는 자동화의 진짜 비용
지금까지 제 경험을 정리하면, 감사 능력 없는 자동화의 소유 비용은 세 가지입니다.
첫째는 장애 복구 시간이에요. 이해 못 하는 워크플로우는 복구에 평균 2시간, 이해하는 건 10분이었죠.
둘째는 레거시화 속도입니다. 제가 3개월 전에 만든 자동화를 지금 고치려면 거의 새로 만들어야 해요.
셋째는 보이지 않는 오류의 누적이에요. 감사할 능력이 없으면 뭐가 틀렸는지 모르고 몇 달을 갈 수 있습니다.
당신이 만든 자동화, 지금 멈추면 왜 멈췄는지 30분 안에 알아낼 수 있나요? 없다면 그건 편리함이 아니라 빚입니다. 저는 지금 워크플로우 12개 중 8개를 천천히 다시 배우고 있어요. 이해할 수 없는 자동화는 언젠가 대가를 요구한다고 생각하거든요.
자주 묻는 질문
Q. 노코드 툴로 만든 자동화도 감사가 가능한가요?
A. 가능합니다. 다만 각 단계가 뭘 하는지, 데이터가 어떻게 변환되는지 이해해야 해요. 제가 보기엔 노코드라도 기본 프로그래밍 개념(변수, 조건문, 반복)을 알면 훨씬 수월합니다. LLM이 짠 로직도 프롬프트와 출력 패턴을 문서화해두면 나중에 추적할 수 있고요.
Q. 자동화를 완전히 이해하려면 개발자 수준이어야 하나요?
A. 그 정도까진 아니에요. 워크플로우를 단계별로 쪼개서 각 단계의 입력과 출력을 예측할 수 있으면 됩니다. 제 기준으론 "이 단계가 왜 실패했는지 로그만 보고 짐작할 수 있나"가 감사 가능 여부의 기준이더라고요.
Q. LLM이 만든 자동화는 블랙박스라서 감사가 불가능한 거 아닌가요?
A. 부분적으로 맞습니다. LLM 내부 추론은 블랙박스지만, 프롬프트와 출력은 제어할 수 있어요. 제가 쓰는 방법은 프롬프트에 "단계별로 사고 과정을 출력하라"를 넣고, 그 로그를 보관하는 겁니다. 완벽하진 않지만 전혀 안 보이는 것보단 낫더라고요.
Q. 감사 능력을 키우려면 어디서부터 시작해야 하나요?
A. 지금 굴리는 워크플로우 중 가장 간단한 것 하나를 골라서 처음부터 다시 만들어보세요. 이번엔 각 단계를 노트에 적으면서요. 그 과정에서 "아, 이게 이런 이유로 돌아가는구나"를 체감하면 됩니다. 저는 그렇게 하나씩 다시 배우는 중이에요.