자동화의 무력화 — 사람 손이 다시 들어가는 신호

결제·정산에서 자동화 붕괴가 특히 위험한 이유

결제와 정산 도메인에서 자동화 무력화는 단순한 운영 비효율로 끝나지 않는다. 잘못된 정산 데이터가 파트너사 지급액에 반영되거나, 실패한 재시도 로직이 중복 청구를 만들거나, 누락된 환불 처리가 민원으로 쌓인다. 자동화가 "살아있는 것처럼 보이지만 실제로는 오염된 결과를 뱉는" 상태가 되는 순간, 그 피해는 로그 파일 안에서 조용히 누적된다.

HEDVION에서 정산 자동화를 운영하면서 가장 긴장되는 순간은 파이프라인이 빨간불일 때가 아니다. 파이프라인이 초록색인데 누군가 "이 숫자 맞아요?"라고 묻는 순간이다. 그 질문은 신호다. 자동화가 아직 돌아가고 있지만, 이미 사람의 판단이 필요한 임계점을 지났다는 신호. 결제·정산 현장에서 이 신호를 놓치면 숫자 오류와 파트너 신뢰 손상이 동시에 온다.

신호 1 — 로그를 아무도 보지 않는다는 것은 소유권 문제다

자동화 초기에는 팀 전체가 파이프라인을 들여다본다. 불안하기 때문이다. 그러다 시스템이 안정화되면 확인 빈도가 자연스럽게 줄어든다. 이것 자체는 문제가 아니다. 진짜 문제는 "아무도 보지 않기 때문에 아무도 모르는 상태"가 운영 관성으로 굳어질 때다. 알림은 설정되어 있고, 채널은 살아있고, 파이프라인은 매일 실행된다. 그런데 아무도 그 결과를 실제로 확인하지 않는다.

우리 팀에서 실제로 있었던 일이다. 정산 데이터를 특정 파트너사 포맷으로 변환해 SFTP로 전달하는 파이프라인이 있었다. 파이프라인은 매일 실행됐고 성공으로 표시됐다. 그러나 파트너사 측에서 "지난 3주간 파일이 비어 있었다"고 연락해온 시점에서야 문제를 알게 됐다. 원인은 파트너사 쪽 SFTP 키 교체였는데, 우리 파이프라인은 해당 오류를 exception 없이 빈 파일로 처리한 뒤 성공으로 리턴했다. 로그를 한 명이라도 정기적으로 확인했다면 이틀 안에 발견했을 이슈였다. 이 사건 이후 우리가 도입한 것은 기술적 솔루션보다 단순했다. 자동화 컴포넌트마다 오너를 지정하고, 주 1회 "정상 여부 확인" 체크를 해당 오너의 명시적 의무로 만들었다. 화려한 모니터링 대시보드보다 "이 자동화를 누가 책임지는가"라는 질문이 먼저다.

신호 2 — 예외 처리 비중이 30%를 넘으면 자동화 자체를 의심하라

자동화 커버리지가 줄어드는 현상은 서서히, 그리고 조용히 온다. 처음 정산 자동화를 설계할 때 커버 가능한 케이스는 전체의 85%였다. 나머지 15%는 파트너사별 커스텀 정산 구조, 수기 조정 건, 분쟁 처리 중인 트랜잭션 등 수작업이 불가피한 영역이었다. 이 15%는 처음부터 예외로 설계되었다.

6개월 후 그 비중은 38%가 됐다. 새로운 파트너사가 추가됐고, 결제 수단이 다양해졌고, PG사 정산 주기 조건이 변경됐다. 자동화 로직은 그대로인데 세상이 바뀐 것이다. 이 상태의 문제는 수치만이 아니다. 수작업 38%를 처리하는 담당자가 자동화 결과 전체를 신뢰하지 않기 시작한다는 점이다. "어차피 내가 다시 확인해야 하니까"라는 생각이 자리잡으면, 자동화는 작업 흐름을 방해하는 중간 단계가 된다. 자동화가 없을 때보다 총 처리 시간이 오히려 늘어나는 역설이 발생한다. 이 임계점에서 HEDVION 팀이 선택한 것은 자동화 확장의 반대였다. 범위를 75%로 다시 좁히되, 그 75% 안에서는 완전히 검증된 결과만 출력하도록 재설계했다. 처리 속도는 소폭 줄었지만 정산 오류율이 명확하게 낮아졌다. 커버리지를 높이는 것이 목표가 아니라, 커버하는 범위 안에서의 신뢰성이 목표다.

신호 3 — 팀원이 자동화 결과를 직접 고치기 시작할 때

이것이 가장 명확한 신호다. 자동화가 생성한 정산 보고서를 받아서 수치를 손으로 고치고, 자동 발행된 세금계산서 초안을 받아서 항목을 수정한 뒤 전송하는 일이 반복된다면, 그 자동화는 기능적으로 이미 절반이 무너진 것이다. 자동화가 사람의 판단을 보조하는 구조가 아니라, 사람이 자동화의 오류를 수정하는 구조가 됐기 때문이다. 이 구조는 겉으로는 자동화가 돌아가는 것처럼 보이기 때문에 더 위험하다.

우리 팀에서 이 상황이 발생했을 때 가장 어려운 결정은 "일단 돌리면서 고치자"는 유혹을 거부하는 것이었다. 자동화를 계속 운영하면서 수정 작업을 병행하는 방식은 오류의 원인을 흐릿하게 만들고 결과적으로 수정 비용이 더 커진다. 우리는 해당 정산 자동화를 2주간 완전히 중단했다. 그 2주 동안 수작업으로 정산을 처리하면서 실제 입력 데이터 패턴을 다시 수집했고, 그 데이터를 기반으로 로직을 재설계했다. 재가동 이후 수작업 개입률은 기존 대비 70% 이상 감소했다. 2주 중단의 비용보다 방치했을 경우의 누적 비용이 훨씬 컸다는 것을 나중에서야 계산으로 확인했다.

자동화는 "완성" 이후가 더 어렵다

자동화 도입 후 처음 3개월은 대부분 잘 돌아간다. 설계 당시의 가정들이 현실과 일치하는 시기이기 때문이다. 문제는 그 이후다. 도메인이 조금씩 바뀌고, 팀 구성이 바뀌고, 외부 시스템의 스펙이 변경된다. 자동화가 만들어진 맥락이 흐려지기 시작하면, 그 자동화는 서서히 현실에서 이탈한다. 이 과정이 천천히 진행되기 때문에 어느 시점에 문제가 시작됐는지 파악하기도 어렵다.

HEDVION에서 결제·정산 자동화를 운영하며 배운 핵심은 하나다. 자동화를 "한 번 구축하면 되는 인프라"가 아니라 "정기적인 검토가 필요한 살아있는 컴포넌트"로 취급해야 한다. 코드에 리뷰와 리팩토링 주기가 있듯, 자동화에는 커버리지 점검과 오너 검토 주기가 필요하다. 사람 손이 다시 들어가는 것은 실패가 아니라 재조정 타이밍을 알려주는 피드백이다. 결제·정산 현장에서 그 신호를 무시하면 조용한 오염이 숫자 오류와 파트너 신뢰 손상으로 직결된다.

지금 바로 써먹을 자동화 붕괴 점검 기준

다음은 HEDVION 팀이 실제 운영에서 쓰는 판단 기준이다. 거창한 모니터링 시스템 없이도 내일부터 적용 가능하다.

오너십 명시화: 운영 중인 자동화 컴포넌트 목록을 만들고 각 항목 옆에 담당자 이름을 써라. 이름이 없는 자동화는 이미 위험 상태다. 이름을 넣는 것 자체가 첫 번째 점검이다.

커버리지 추이 월간 기록: 자동 처리 건수 대비 수동 개입 건수의 비율을 매월 기록하라. 수동 비율이 전월 대비 5%p 이상 증가하면 원인 분석을 시작하는 트리거로 삼아라. 숫자를 쌓지 않으면 추이를 볼 수 없다.

결과물 주 1회 랜덤 샘플링: 자동화가 생성하는 결과물(정산 파일, 보고서, 알림 등)을 매주 최소 3건 이상 사람이 직접 열어서 확인하라. 100% 자동화를 신뢰하는 것 자체가 리스크다.

"수동 수정 횟수" 지표 추가: 팀원이 자동화 결과를 수동으로 수정하는 빈도를 집계하라. 이 숫자가 주 3회를 넘으면 자동화 재설계 검토를 시작하는 기준으로 삼아라. 수정 행위 자체가 시스템이 보내는 가장 정직한 피드백이다.

중단 기준 사전 정의: "오류율 X% 이상", "수동 수정 Y회 이상"처럼 자동화를 멈출 조건을 미리 숫자로 정해두어라. 문제가 생긴 뒤 기준을 만들면 감정적 판단이 개입하고 결정이 늦어진다. 트리거를 미리 정해두면 상황이 발생했을 때 즉시 행동할 수 있다.

— by slecs