엑셀 매크로가 아니라 구조를 다시 짜는 일(report-automation design 4 steps)
매주 같은 보고서를 다시 만들고 있는가.
파일 이름만 바뀌고 숫자만 교체되는 문서를 반복하고 있는가.
자동화 툴을 도입했지만 여전히 사람이 붙어 있어야 돌아가는가.
문제는 속도가 아니라 설계일 가능성이 높다.
이 글은 반복 보고서를 자동으로 만드는 기술을 설명하지 않는다. 구조를 다시 짜는 방법을 정리한다.
이 글이 다루지 않는 것
특정 툴 사용법은 다루지 않는다.
RPA, GPT, 매크로, BI 툴 비교도 하지 않는다.
기술은 수단이다. 설계가 정리되지 않으면 어떤 툴을 써도 결과는 같다.
현장에서 실제로 나오는 질문
“왜 자동화했는데도 사람이 계속 붙어야 합니까?”
“보고서 하나 만드는데 2시간이면 되는데, 굳이 구조를 바꿔야 합니까?”
이 질문이 반복된다면 이미 구조 문제가 있다.
구조가 정리되지 않은 기업 사례
수도권에 위치한 B유통.
연매출 120억 원, 직원 34명.
매장 5개, 온라인몰 1개 운영.
주간 보고서 3종, 월간 보고서 2종 작성.
보고서 작성 담당자는 재무팀 2명.
주간 보고서 하나에 평균 1시간 40분 소요.
데이터는 POS, 온라인몰, ERP, 수기 엑셀에서 수집.
문제는 속도가 아니었다.
같은 숫자가 보고서마다 다르게 나온다는 점이었다.
표면 문제가 아니라 구조 문제
겉으로 보이는 문제는 반복 업무다.
그러나 실제 문제는 이 세 가지다.
- 데이터 원천이 통합되지 않았다.
- 지표 정의가 문서마다 다르다.
- 보고서 목적이 불분명하다.
자동화 이전에 정의가 없다.
정의가 없으니 사람마다 계산 방식이 다르다.
사람들이 흔히 하는 착각
첫째, “툴을 바꾸면 해결된다.”
툴은 계산을 빠르게 할 뿐 정의를 통일하지 않는다.
둘째, “보고서는 원래 손이 간다.”
반복 보고서는 설계 대상이다.
셋째, “일단 자동화부터 하자.”
흐름이 정리되지 않은 상태에서 자동화하면 오류만 빠르게 증폭된다.
Fieldbly 방식: 4단계 설계 구조
반복 보고서는 아래 4단계로 재설계한다.
1단계: 목적 재정의
이 보고서의 결정 주체는 누구인가.
이 보고서를 보고 무엇을 결정하는가.
보고서마다 목적을 1문장으로 명확히 쓴다.
“매장별 재고 발주 결정용”처럼 구체적으로.
2단계: 지표 구조 통일
같은 매출이라도 정의가 다르면 비교가 불가능하다.
| 구분 | 기존 상태 | 재설계 후 |
|---|---|---|
| 매출 | 부가세 포함/미포함 혼재 | 정의 통일 |
| 방문객 | POS 기준 | POS+온라인 통합 기준 |
| 재고회전율 | 월별 수기 계산 | ERP 기준 자동 계산 |
지표는 정의서로 만든다.
이 문서가 자동화의 기준이 된다.
3단계: 데이터 흐름 설계
데이터가 어디서 시작해 어디로 모이는지 그린다.
원천 → 정제 → 저장 → 출력
예시
POS / 온라인몰 / ERP → 정제 테이블 → 통합 DB → 보고서 템플릿
이 단계에서 API, 수집 주기, 오류 점검 위치를 정한다.
이 흐름이 없으면 자동화는 단순 복붙이다.
4단계: 출력 템플릿 고정
보고서 형식을 먼저 고정한다.
페이지 수, 표 위치, 그래프 위치까지 결정한다.
그 다음 데이터를 연결한다.
많은 기업이 이 순서를 반대로 한다.
구조 재설계 전과 후 비교
재설계 전
- 보고서 작성 1건 1시간 40분
- 수기 오류 월 3회
- 숫자 불일치로 회의 지연
재설계 후
- 보고서 작성 1건 10분 내 확인
- 오류 월 0~1회
- 회의 시간 30% 단축 (※ 추가 조사 필요: 실제 평균 단축 비율)
속도보다 중요한 것은 신뢰도였다.
실행 체크리스트
다음 주 바로 점검할 항목이다.
- 보고서 목적을 1문장으로 정의했는가
- 지표 정의서를 별도 문서로 만들었는가
- 데이터 흐름을 화살표로 그려봤는가
- 출력 템플릿을 먼저 고정했는가
- 오류 발생 시 수정 위치가 명확한가
이 다섯 개 중 세 개 이상이 “아니오”라면 자동화 이전 단계다.
점검 질문
이 보고서는 누구의 결정을 돕는가.
같은 지표가 모든 문서에서 동일하게 계산되는가.
데이터가 이동하는 경로를 그림으로 설명할 수 있는가.
반복 보고서는 노동 문제가 아니다. 설계 문제다.
AI현장감독 이동주는 AI 도입 과정에서 반복되는 구조 문제를 연구한다.
AI adoption failure를 기술 문제가 아닌 설계와 흐름의 문제로 바라본다.
Fieldbly에서 현장 사례를 기반으로 정리하고 있다.
(homepage) http://www.fieldbly.com