보고서 자동화 — 사람의 일이 사라진 자리

결제·정산 현장에서 보고서 자동화가 더 위험한 이유

결제·정산 도메인에서 "보고서 자동화"는 단순한 생산성 도구가 아니다. 우리 팀이 매주 만들어내는 PG사별 매출 집계, 정산 금액 요약, 환불 현황 시트는 실제 돈과 직결된 숫자를 담고 있다. 일반적인 서비스에서 KPI 리포트 자동화가 틀리면 의사결정이 다소 늦어지는 정도다. 하지만 정산 파이프라인이 틀린 숫자를 배포하면 이야기가 달라진다. 거래처에 잘못된 정산 금액이 통보되고, 내부적으로 이중 지급 혹은 미지급 판단이 내려지고, 회계 마감이 꼬인다. 오류 하나의 파장이 기술 문제를 넘어 재무 문제로 번진다.

그래서 우리가 보고서 자동화에서 배운 가장 중요한 교훈은 파이프라인 구조에 관한 것이 아니었다. "수작업에서 자연스럽게 일어나던 판단을 얼마나 코드로 복원했는가"였다. 이 질문이 처음부터 설계 기준이 되어야 하는데, 대부분의 자동화 프로젝트는 파이프라인을 완성한 뒤에야 이 질문과 마주친다. 그때는 이미 이상한 숫자가 한 번쯤 나가고 난 뒤다.

처음엔 단순했다 — 세 개 소스, 하나의 파이프라인

원래 구조는 실제로 단순했다. PG사 API, 내부 거래 DB, 정산 계정 스프레드시트라는 세 개의 데이터 소스에서 쿼리를 당겨 HTML 템플릿에 채우고, 스케줄러가 매주 월요일 오전 9시에 이메일로 배포하는 파이프라인이다. 코드는 200줄 남짓, 한 사람이 매주 2시간씩 쓰던 작업이 사라졌다. 처음 몇 주는 잘 됐다.

그런데 이 단순함이 함정이었다. 파이프라인이 단순할수록 오류는 더 조용히 통과한다. 세 소스 중 하나가 지연 응답을 보내면 어떻게 되는가? PG사 API가 전날 집계 오류를 포함한 데이터를 내려주면? 내부 DB의 타임존 설정이 바뀌어 당일 새벽 거래가 전날 건으로 집계되면? 수작업 시절에는 담당자가 숫자를 눈으로 옮기는 과정에서 "이 값 이상하지 않나?" 하는 신호를 자연스럽게 포착했다. 자동화된 파이프라인은 그 신호를 무시하고 그냥 내보낸다.

수작업에 숨어 있던 암묵적 검증

우리가 이 문제를 실감한 건 구체적인 사건 덕분이었다. 자동화 이후 세 번째 주, PG사 API에서 이전 주 환불 건이 중복 집계된 채로 데이터가 내려왔다. 파이프라인은 이걸 그대로 받아 정산 보고서를 배포했다. 거래처 담당자로부터 "이번 주 환불 수치가 전주 대비 두 배 가까운데 맞냐"는 연락이 온 건 배포된 지 세 시간이 지난 뒤였다. 수정 보고서를 재작성하고 원인을 설명하는 데 반나절이 걸렸다. 보고서 작성에 쓰던 2시간보다 더 많은 시간을 수습에 썼다.

수작업 때라면 담당자가 환불 집계 셀에 숫자를 입력하면서 "저번 주 300만 원이었는데 이번 주 580만 원? 뭔가 이상한데"라고 바로 알아챘을 것이다. 이 판단은 명시적으로 설계된 게 아니라 숫자를 손으로 다루는 과정에서 자연스럽게 발생했다. 자동화는 이 암묵적 검증을 조용히 제거했다. 그래서 우리는 이 검증을 코드로 다시 심었다. 전주 대비 ±40% 이상 변화가 있는 지표, 소스 간 합계가 일치하지 않는 경우, 집계 건수가 0인 이상 케이스 — 이 세 조건 중 하나라도 해당하면 배포를 멈추고 Slack 알림을 보낸다. "보고서를 막는 코드"를 쓰는 것이 자동화의 완성이었다.

시간을 회수한다는 것의 실제 의미

자동화 이후 그 주당 2시간이 어디로 갔는지를 우리는 의식적으로 추적했다. 솔직히 말하면, 처음 3주는 비슷한 성격의 다른 반복 작업으로 흡수됐다. 시간이 회수됐다고 해서 그 시간이 자동으로 가치 있는 일에 쓰이지는 않는다. 이건 생산성에 관한 일반론이 아니라 작은 팀에서 실제로 벌어지는 현상이다. 슬랙 메시지 정리, 다른 부서 긴급 요청 응대, 채 결론 나지 않은 회의들이 빈 시간을 먼저 채운다. 회수한 시간을 방어하지 않으면 그 시간은 다른 노이즈로 대체될 뿐이다.

결국 팀 차원에서 "회수한 시간에 무엇을 할지"를 명시적으로 결정해야 했다. 우리가 선택한 건 코드 리뷰 주기를 짧게 가져가는 것이었다. 이전에는 PR이 이틀씩 방치되는 일이 빈번했고, "다들 바빠서"라는 말이 통용됐다. 그런데 실제로 어디서 시간이 빠져나가는지 들여다보고 나니 그 변명이 성립하지 않았다. 일주일 단위로 PR 응답 시간을 측정했더니 평균 리뷰 시간이 48시간에서 18시간으로 줄었다. 자동화의 효과가 기술이 아니라 팀 운영에서 나타난 셈이다.

자동화해도 되는 것과 하면 안 되는 것

모든 보고서가 자동화 대상이 아니라는 건 처음부터 알고 있었지만, 기준을 명확히 세우는 건 다른 문제다. 우리가 사용하는 기준은 하나다. "이 보고서에서 숫자 외에 사람의 판단이 필요한 부분이 있는가?" 숫자를 특정 형식으로 모아 배포하는 것이 전부라면 자동화 대상이다. 그 숫자에 이번 달 특수 요인을 설명하는 맥락이 필요하거나, 수치 이면의 패턴을 해석해야 하거나, 외부 이해관계자에게 전략적 메시지를 담아야 한다면 사람이 쓴다. 우리가 자동화한 건 "숫자를 옮기는 일"이지 "숫자에 의미를 부여하는 일"이 아니다.

실제로 우리는 세 단계로 보고서를 분류해 운영한다. 완전 자동화(주간 정산 집계 — PG사별 매출·환불·수수료, 검증 레이어 포함), 반자동화(월간 파트너 리포트 — 숫자는 자동, 코멘트는 수기 작성), 완전 수동(분기 사업 현황 보고서 — 맥락과 전략 판단이 중심). 이 세 단계를 문서로 정해두니 "이 보고서도 자동화할 수 있지 않냐"는 제안이 들어올 때 기준을 근거로 판단할 수 있게 됐다. 기준이 없으면 자동화 가능한 모든 것을 자동화하려는 관성이 생기고, 사람의 판단이 빠진 자리가 늘어나는 것을 인지하지 못하게 된다.

지금 바로 써먹을 수 있는 시사점

처음부터 이 순서대로 설계했다면 사건 하나와 반나절의 수습을 피할 수 있었다. 뒤늦게 추가하는 건 항상 더 귀찮다.

1. 자동화 전에 담당자에게 물어라. "수작업 하면서 이상하다고 느꼈던 순간이 있었나요?" 이 질문의 답이 검증 레이어 설계의 원천이다. 담당자가 "어, 이 숫자가 갑자기 두 배가 됐는데"라고 반응했던 경험이 있다면, 그 조건이 자동 검증 기준이 된다.

2. 배포를 막는 코드를 파이프라인보다 먼저 설계하라. 처음 설계 단계에서 "이 보고서가 배포되면 안 되는 조건"을 정의하고, 그 조건을 통과해야만 배포되는 구조를 만들어라. 우리 기준은 전주 대비 ±40% 변화, 소스 간 합계 불일치, 집계 건수 0 세 가지다.

3. 회수한 시간의 목적지를 팀 단위로 명시적으로 결정하라. 자동화로 확보한 시간은 저절로 좋은 곳에 쓰이지 않는다. "이 시간에 X를 한다"는 결정이 없으면 산발적 요청 처리로 흡수된다. 결정하고 수치로 추적하라.

4. 자동화 범위를 세 단계로 분류하고 문서화하라. 완전 자동화 / 반자동화 / 완전 수동. 이 분류를 팀 문서에 올려두면 미래의 자동화 요청에 즉각 판단 기준이 생긴다.

5. 이상값을 직접 주입해 파이프라인을 테스트하라. 소스 데이터에 의도적으로 이상값을 넣고 파이프라인이 어떻게 반응하는지 확인하라. 알림이 오는가? 배포가 멈추는가? 아니면 이상한 숫자가 그냥 나가는가? 이 테스트를 한 번도 해보지 않은 파이프라인은 언젠가 실제 상황에서 배운다.