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

자동화 전의 일상

매주 같은 숫자를 같은 양식에 채워 넣는 작업이 있었다. 데이터 소스는 세 곳, 형식은 고정, 배포는 이메일. 한 사람이 매주 2시간씩 쓰는 일이었다. 누가 시킨 것도 아니고, 없애도 된다는 결정을 내린 사람도 없었다. 그냥 계속됐다.

자동화를 시도하기로 한 건 기술적인 욕심이 아니라 단순한 피로감 때문이었다. 반복 작업이 주는 지루함보다, 그 시간에 다른 걸 할 수 있다는 기회비용이 더 크게 느껴졌다.

구조 자체는 단순했다. 세 개의 데이터 소스에서 쿼리를 돌리고, 결과를 정해진 HTML 템플릿에 채운 뒤, 스케줄러가 배포하는 파이프라인이다. 코드 분량은 크지 않았다. 어렵지 않은 작업이었다.

다만 한 가지 예상 못 했던 지점이 있었다. 수작업으로 보고서를 만들던 사람이 숫자를 입력하면서 이상한 값을 발견하면 바로 알아챘다는 것이다. 자동화된 파이프라인은 그냥 내보낸다. 이상한 숫자가 들어오면 이상한 숫자가 배포된다.

그래서 파이프라인에 검증 레이어를 추가했다. 전주 대비 특정 임계치를 넘는 변화가 있으면 배포 전에 알림을 보내고 멈추는 방식이다. 수작업에서 자연스럽게 일어났던 판단을 코드로 다시 심은 셈이다.

자동화 이후 그 2시간이 어디로 갔는지를 의식적으로 추적했다. 처음 몇 주는 솔직히 비슷한 다른 반복 작업으로 채워졌다. 시간을 회수했다고 해서 그 시간이 자동으로 좋은 일에 쓰이지는 않는다.

결국 팀 단위로 “이 시간에 뭘 할 것인지”를 명시적으로 결정해야 했다. 우리는 그 시간을 코드 리뷰 주기를 짧게 가져가는 데 썼다. 이전에는 리뷰가 밀리면 “바쁘다”는 말로 넘어갔는데, 실제로 어디서 시간이 사라졌는지 확인하고 나니 그 말을 하기가 어색해졌다.

모든 보고서가 자동화 대상은 아니다. 판단이 필요한 요약, 맥락 설명이 들어가는 부분은 여전히 사람이 쓴다. 우리가 자동화한 건 “숫자를 옮기는 일”이지 “숫자에 의미를 부여하는 일”이 아니다.

이 구분을 처음부터 명확히 했다면 검증 레이어를 처음부터 설계했을 것이다. 후반에 추가하는 건 항상 더 귀찮다.

— by slecs