자동화 비용은 어디서 나오는가

자동화 비용의 실체: "한 번"이 아니라 "계속"이다

"한 번 만들어두면 알아서 돌아간다"는 자동화의 약속은 반만 맞다. 나머지 반은 이렇게 고쳐야 한다: "한 번 잘 만들어두면, 잘 유지하는 동안은 알아서 돌아간다." 그 '잘 만들기'와 '잘 유지하기'에 드는 비용은 생각보다 훨씬 구체적이고 지속적이다. 문제는 대부분의 자동화 투자 결정이 첫 번째 비용만 계산하고 나머지 둘을 무시한다는 데 있다.

HEDVION은 결제 수집, 정산 계산, 데이터 파이프라인을 직접 운영하는 작은 팀이다. 인원이 적을수록 자동화의 유혹은 강하다. 수동으로 하기엔 반복이 너무 많고, 사람을 더 뽑기엔 규모가 작다. 그래서 지난 몇 달간 우리는 실제로 자동화에 투자했고, 그 과정에서 비용의 구조를 몸으로 배웠다. 이 글은 그 기록이자 다음에 같은 실수를 반복하지 않기 위한 판단 기준이다.

결제·정산 자동화가 특히 비싼 이유

일반적인 백오피스 자동화와 결제·정산 자동화는 비용 구조가 근본적으로 다르다. 가장 큰 차이는 실패 비용이다. 마케팅 이메일 자동화가 잘못 돌아가면 재전송하면 된다. 하지만 정산 파이프라인이 잘못 돌아가면 클라이언트에게 틀린 금액이 지급되거나, 세금 신고 기준 데이터가 오염되거나, 이중 출금 시도가 발생한다. 오류를 추적하고 복구하는 데 드는 시간이 애초에 자동화하지 않았을 때보다 훨씬 길다. 자동화가 오히려 부채를 만드는 역설이다.

그래서 결제·정산 자동화에는 비즈니스 로직 외에 방어 코드가 필수적으로 따라붙는다. 멱등성 처리(같은 요청이 두 번 들어와도 한 번만 실행되게), 금액 검증 로직, 이상치 탐지, 수동 override 경로. 우리가 정산 자동화 파이프라인 하나를 처음 만들었을 때, 핵심 비즈니스 로직을 짜는 데 하루가 걸렸고 엣지 케이스와 방어 로직을 추가하는 데 사흘이 더 걸렸다. 비율로 보면 방어 코드가 전체 구축 시간의 **75%**였다. 처음엔 이게 비효율처럼 느껴졌지만, 지금은 이 비율이 적정 수준이라고 본다.

비용의 세 층위: 구축, 운영, 유지보수

자동화 비용을 제대로 보려면 세 층위를 분리해야 한다.

첫 번째, 구축 비용. 로직 설계, 엣지 케이스 처리, 알림 설계, 테스트. 우리 경험상 단순 배포 파이프라인은 이틀, 정산 파이프라인처럼 도메인 지식이 필요한 건 최소 일주일이다. 여기서 자주 과소평가되는 항목이 '실패 감지 설계'다. 파이프라인이 조용히 죽으면 아무도 모른다. 어떤 상태가 실패인지 정의하고, 그걸 누군가에게 알리는 시스템을 만드는 데도 별도의 시간이 든다.

두 번째, 운영 비용. 클라우드 실행 비용, API 호출 비용, 로그 스토리지. 우리 규모에서는 파이프라인 하나당 월 10~30달러 수준이지만, 파이프라인이 5개, 10개로 늘면 이야기가 달라진다. 더 중요한 건 비가시적 운영 부채다. 파이프라인이 예상보다 자주 실패해서 누군가가 매일 아침 로그를 확인해야 한다면, 그 시간은 청구서에 나타나지 않지만 분명히 존재한다. 우리는 이걸 추적하지 않다가 한 달에 팀원 한 명의 오전 30분씩이 로그 확인에 사라지고 있다는 걸 나중에야 파악했다.

세 번째, 유지보수 비용. 이게 가장 과소평가된다. 외부 결제 게이트웨이가 API 스펙을 바꾸거나, 정산 기준이 되는 외부 데이터 포맷이 달라지거나, 라이브러리 보안 취약점 패치가 필요해지거나. 자동화된 파이프라인이 많을수록 이 유지보수 표면적이 정비례해서 넓어진다. 실제로 우리는 지난 분기에 외부 API 변경으로 파이프라인 두 개를 동시에 수정해야 했고, 예상 시간의 세 배가 걸렸다. 의존성이 숨겨져 있어서 첫 번째 파이프라인을 고치다 두 번째가 망가진다는 걸 중간에 발견했기 때문이다.

투자 기준: 우리가 쓰는 단순한 공식

자동화 투자 여부를 결정하는 데 정교한 ROI 스프레드시트보다 더 실용적인 기준이 있다. 우리가 실제로 쓰는 건 이것이다.

주 3회 이상 반복 + 회당 10분 이상 소요 → 자동화한다 그 아래 → 직접 한다

이 기준을 엄격하게 적용했을 때 자동화 후보의 절반 이상이 탈락했다. "어차피 자동화하면 편할 텐데"라는 생각으로 손댈 뻔한 것들이 실제로는 월 2~3회, 매번 5분 미만으로 처리되는 작업들이었다. 그걸 자동화하는 데 일주일을 쓰는 건 어떤 기준으로도 손해다.

반례도 중요하다. 정산 데이터 추출 작업은 처음에 "월 1회, 30분"이라고 생각했다. 그런데 추출 → 검증 → 재포맷 → 클라이언트 전달까지 합산하면 회당 2시간 이상이었고, 실질적으로는 월 2~3회 필요했다. 처음부터 시간을 제대로 측정하지 않으면 의사결정 자체가 틀린다. 우리는 지금도 새로운 자동화 후보가 나오면 바로 만들지 않고, 2주간 실제 소요 시간을 기록한 뒤 결정한다.

자동화하지 않기로 결정한 것들

자동화 적합성에는 기술적 가능성 외에 의도의 훼손 기준이 있다. 클라이언트 커뮤니케이션이 대표적이다. 진행 상황 공유, 변경 사항 논의, 방향 조율. 이것들은 자동화할 수 있지만, 자동화하면 안 된다. 결제·정산 서비스는 신뢰 기반이다. 자동화된 업데이트 메시지는 정보를 전달하지만 신뢰를 쌓지는 않는다. 클라이언트 입장에서 받는 자동 알림과 사람이 직접 쓴 메시지는 내용이 같아도 전혀 다르게 읽힌다.

이 팀 블로그도 자동화하지 않는다. AI 도구로 초안을 뽑으면 속도는 빨라지지만, 우리가 블로그를 쓰는 목적—운영 경험을 언어화하고, 판단 기준을 명문화하는 것—은 그 과정 자체에 있다. 결과물을 빠르게 내는 게 목적이 아니다. 자동화가 목적 자체를 대체할 때는 하지 않는다. 효율과 의미는 교환되지 않는다.

바로 써먹을 수 있는 실행 기준

추상적 원칙이 아니라 내일 당장 쓸 수 있는 체크리스트다.

1. 자동화 전 2주 타이머 규칙: 자동화를 고려 중인 작업이 있다면, 바로 만들지 말고 2주간 실제 소요 시간과 빈도를 기록하라. 예상과 실제는 대부분 다르고, 이 데이터가 없으면 투자 결정이 감에 의존하게 된다.

2. 방어 코드 75% 예산: 결제·정산 자동화라면 멱등성 처리, 금액 검증, 실패 알림, 수동 override 경로에 전체 구축 시간의 75%를 배정하라. 이게 과하다고 느껴지면 자동화할 준비가 안 된 것이다.

3. 비가시적 운영 부채 가시화: 파이프라인이 실패할 때마다 자동으로 기록하고, 월말에 '로그 확인과 재실행에 쓴 총 시간'을 집계하라. 이 숫자가 월 2시간을 넘는다면 해당 파이프라인은 리팩터링 대상이다.

4. 외부 의존성 지도 작성: 외부 API나 데이터 포맷에 의존하는 파이프라인마다 "이 스펙이 바뀌면 어디를 고쳐야 하는가"를 문서화하라. 이게 없으면 변경 비용이 항상 예상의 두세 배로 불어난다.

5. 의도 훼손 체크: 자동화하려는 작업의 가치가 결과물에 있는지, 아니면 과정 자체에 있는지 먼저 확인하라. 후자라면 자동화하지 않는다.

자동화는 도구다. 도구는 목적에 맞게 써야 효과가 있고, 비용을 모르면 목적에 맞게 쓸 수 없다.

— by mings