CSV 리포트 자동화가 매주 수작업이 되는 이유#
매주 받는 CSV의 컬럼이나 값이 달라지면 집계 전에 입력을 확인해야 합니다. 필수 컬럼과 오류 처리 기준을 정해 두면 같은 규칙으로 검증하고 집계하는 절차를 설계할 수 있습니다.
입력 조건에 따라 검증 방법부터 달라집니다.
| 입력 조건 | 처리할 때 정할 것 | 확인할 점 |
|---|---|---|
| 헤더가 있는 CSV | 컬럼명과 필수 순서를 명시 | 첫 데이터 행이 빠지지 않았는지 확인 |
| 헤더가 없는 CSV | 컬럼명을 별도로 제공 | 첫 행이 헤더로 소비되지 않았는지 확인 |
| 구분자·따옴표가 다른 CSV | 파일별 구분자와 인코딩 지정 | 쉼표나 줄바꿈이 들어간 필드를 대조 |
| 누락·잘못된 금액 | 실패 또는 제외 규칙과 알림 경로 결정 | 제외 건수와 합계가 원본과 맞는지 확인 |
Python CSV 공식 문서에 따르면 DictReader에 필드명을 주지 않으면 첫 행을 헤더로 사용합니다. CSV 형식 자동 감지는 추정이므로 입력 계약을 대신하지 않습니다. 이 표는 도구의 동작과 점검 기준이지 Mirr 실행 결과는 아닙니다. 출처 확인: 2026-11-01.
- 원본을 백업하고 샘플에서 헤더 유무, 인코딩, 금액 단위, 필수 컬럼과 누락값 처리 방식을 정합니다. CSV나 샘플을 모델 제공자 등 외부 서비스에 보내기 전에는 조직과 제공자의 데이터 처리 정책을 확인하고 승인된 합성 또는 비식별 데이터만 사용하세요. 비밀정보나 고객 원본 내용은 보내지 마세요.
- Mirr Code에 기존 처리 코드를 조사하고 그 규칙에 맞는 집계 스크립트와 정상·오류 입력 테스트를 작성해 달라고 요청합니다. 기능 구현 가이드는 실행 결과와 미실행 검사를 함께 확인하도록 안내합니다.
- 사용 가능한 실행 환경에서 샘플을 처리하고, 사람이 행 수·그룹별 합계·전체 합계를 원본과 대조합니다. 정기 실행과 실패 알림은 별도 CI 또는 스케줄러 설정 및 권한이 필요합니다.
추가 검증 필요: 실제 업무 리포트의 입력과 화면 대조는 아직 없습니다. 「설치된 Mirr의 합성 CSV 과제와 별도 교정」 절(2026-11-03)에 좁은 Mirr 합성 CSV 실행과 감독하의 교정 기록이 있습니다.
Before / After: CSV 리포트 자동화의 현재 비용과 자동화 후 결과#
수작업과 자동화 결과를 비교할 때는 같은 입력과 집계 기준을 사용하고, 누락된 행과 합계를 함께 확인하세요.
추가 검증 필요: 같은 입력의 수작업 결과와 자동화 결과를 비교한 자료는 없습니다.
단계별로 하기: 입력 규칙 → 실행 → 검증#
위의 절차에 맞춰 입력 규칙과 오류 처리 방식을 정한 다음 스크립트와 테스트를 요청하세요.
예를 들어 “헤더가 없는 입력도 첫 행부터 집계하고, 필수 금액이 비었으면 실패하도록 테스트해 줘”라고 요청할 수 있습니다. 실제 적용 전에 데이터 공개 범위와 실행 권한을 확인하세요.
검증: 테스트 출력과 체크리스트#
샘플 블록의 합성 데이터(branch,amount 세 행)의 행 수와 지점별 합계를 직접 확인할 수 있습니다.
다음 코드 블록은 새 임시 디렉터리에서 실행하도록 적은 독립적인 로컬 합성 데이터 예시입니다. 이 글의 작업에서 실행해 얻은 기록이 아닙니다. Mirr 실행이나 운영 리포트 검증은 아닙니다. 명령 전체를 빈 임시 디렉터리에서 실행하면 sample.csv가 생성됩니다. 같은 이름의 파일이 이미 있으면 덮어쓰지 않고 오류로 중단합니다.
python3 - <<'PY'
import csv
from pathlib import Path
p = Path('sample.csv')
with p.open('x', encoding='utf-8', newline='') as f:
f.write('branch,amount\nA,120\nB,80\nA,30\n')
with p.open(encoding='utf-8', newline='') as f:
rows = list(csv.DictReader(f))
totals = {}
for row in rows:
totals[row['branch']] = totals.get(row['branch'], 0) + int(row['amount'])
print('input_rows:', len(rows))
for branch, total in sorted(totals.items()):
print(f'{branch}: {total}')
print('grand_total:', sum(totals.values()))
PY
예상 출력(실행 기록 아님):
input_rows: 3
A: 150
B: 80
grand_total: 230
이 샘플 블록은 헤더가 있는 정상 입력만 다룹니다. 헤더 없는 입력과 여섯 오류 입력은 「직접 실행한 정상·오류 CSV 계약 검사」 절에서 다루고, 알림·실제 리포트·CI는 여전히 별도입니다.
주의할 점과 한계#
| 점검 결과 | 조사할 원인 | 처리 원칙 |
|---|---|---|
| 첫 데이터가 빠짐 | 헤더 유무와 필드명 지정 | 계약을 고치고 입력 행과 다시 대조 |
| 합계 차이 | 중복 키·누락·금액 단위·잘못된 값 | 제외 건수와 원본 위치를 남기고 실패 기준 적용 |
| 글자·열이 어긋남 | 인코딩·구분자·인용된 쉼표와 줄바꿈 | 단순 문자열 분리 대신 CSV 규칙에 맞춰 처리 |
| 정기 실행 결과가 없음 | CI 권한·작업 상태·알림 경로 | 이전 결과를 새 결과처럼 게시하지 않기 |
위 CSV 문서와 입력 계약을 적용한 진단 기준이며 실제 오류 테스트 결과는 아닙니다.
실제 업무에 적용하기 전에는 입력 형식과 데이터 처리 정책에 맞게 테스트 범위를 정하세요.
추가 검증 필요: 대용량 파일과 실제 업무의 개인정보·접근 정책에 맞는 처리 여부는 확인되지 않았습니다.
컬럼 계약을 집계 코드보다 먼저 고정하기#
CSV는 확장자가 같아도 헤더, 구분자, 인코딩과 값의 의미가 다를 수 있습니다. 입력 계약에는 필수 컬럼, 허용 별칭, 순서와 추가 컬럼의 처리 기준을 적으세요. 헤더가 없는 파일은 필드명을 별도로 주고 첫 행부터 데이터로 처리하는지 확인합니다. 헤더 자동 감지는 편의 기능일 수 있지만 업무 계약을 대신하지 않습니다. 첫 데이터 행이 우연히 컬럼 이름처럼 보여도 임의로 제외하면 안 됩니다.
금액은 단위와 소수점, 음수와 반올림 규칙을 먼저 정합니다. 가상의 원 단위 매출이라면 정수만 허용할 수 있지만 모든 데이터에 같은 규칙이 맞지는 않습니다. 빈 값과 영도 다릅니다. 미제출 금액을 영으로 바꾸면 합계가 그럴듯해 보여도 제출 상태를 잃습니다. 날짜는 표시 형식뿐 아니라 보고 기간과 시간대의 의미를 확인해야 합니다. 사람이 합의하지 않은 업무 규칙을 모델이 추측해 채우도록 두지 마세요.
| 계약의 질문 | 가능한 결정 예시 | 검증할 실패 입력 |
|---|---|---|
| 어떤 행이 한 건인가 | 주문 키가 있는 한 행 | 키 누락·중복 주문 |
| 어떤 금액인가 | 원 단위 정수, 취소는 별도 상태 | 빈 값·문자·허용하지 않은 음수 |
| 어느 기간인가 | 승인된 주간 시작·종료 범위 | 다른 기간의 자료 혼입 |
| 어떤 지점인가 | 고정 지점 코드 목록 | 알 수 없는 코드·공백 값 |
| 무엇을 출력하나 | 지점별 합계와 처리 요약 | 일부 실패를 숨긴 전체 결과 |
예시의 결정은 실제 업무 담당자가 바꿔야 합니다. 컬럼 이름을 소문자로 바꾸거나 공백을 지우는 정규화도 허용 범위를 정하세요. 다른 이름의 두 컬럼이 같은 이름으로 합쳐지면 어느 값을 읽을지 모호해집니다. 계약을 바꾼 경우 버전을 올리고 이전 입력에 어떤 규칙을 적용했는지 남깁니다. 값만 보관하고 계약을 잃으면 나중에 같은 숫자를 재현하기 어렵습니다.
CSV 파서를 쓰고 단순 분리를 피하기#
쉼표가 들어간 설명이나 줄바꿈이 포함된 인용 필드가 있을 수 있으므로 줄을 쉼표로 단순 분리하는 방식은 충분하지 않습니다. Python csv처럼 형식 규칙을 다루는 파서를 사용하고 newline=''와 인코딩을 명시하는 방법을 검토하세요. 구분자가 탭이나 세미콜론이라면 계약에 맞게 설정합니다. 읽힌 열 수와 예상 열 수가 다른 행을 어떻게 처리할지도 정해야 합니다. 남는 필드를 조용히 버리면 원본과의 대조가 어려워집니다.
UTF-8 BOM이 있는 입력과 없는 입력을 같은 것으로 받을지 정하고 실제 파서 결과를 확인하세요. 인코딩 오류를 무시하면 지점 코드나 키가 변할 수 있습니다. 원본을 보관한 상태에서 승인된 복사본으로 처리하고 손실 없는 읽기를 검토합니다. 파일 내용에 수식처럼 보이는 문자열이 있을 때 이를 스프레드시트에서 열면 해석 방식이 달라질 수 있습니다. CSV 작성이 끝났다는 사실과 Excel에서 안전하게 열 수 있다는 판단도 별도입니다.
누락과 중복이 상쇄되는 경우 찾기#
전체 합계가 맞아도 데이터가 정확하지 않을 수 있습니다. 같은 금액의 한 행이 빠지고 다른 행이 중복되면 합계가 유지됩니다. 입력 행 수, 유효 행 수, 제외 행 수와 결과의 업무 키를 함께 비교하세요. 그룹별 부분합도 필요합니다. 지점 A의 값이 B로 잘못 분류돼 전체 합계는 같을 수 있기 때문입니다. 업무 키가 없다면 어떤 기준으로 누락·중복을 확인할지 담당자와 먼저 정해야 합니다.
제외를 허용하는 경우에는 제외 사유와 건수, 금액 영향을 보고합니다. 오류 파일을 통째로 제외할지 오류 행만 보류할지는 업무 결정입니다. 일부 성공한 결과를 정상 전체 리포트처럼 게시하지 않도록 상태를 구분하세요. 필수 입력 하나가 없으면 실패해야 하는 주간 보고서라면 처리 파일 수와 기대 파일 수를 대조해야 합니다. 이전 주 결과가 남아 있더라도 새 주간 실행이 성공한 것처럼 표시하면 안 됩니다.
정상·오류 입력을 분리해 테스트하기#
정상 입력의 기대값은 파서 구현과 독립적으로 정합니다. 앞의 세 행 예시라면 행 수 3, A의 합계 150, B의 합계 80과 전체 230을 사람이 계산할 수 있습니다. 여기에 헤더 없는 동일 데이터, 금액 누락, 중복 키, 잘못된 열 수와 빈 파일을 각각 추가해 보세요. 실패가 필요한 입력에서 실제로 실패하는지가 정상 합계 검사만큼 중요합니다. 오류 메시지에는 파일 식별자와 위치를 남기되 고객 원문 전체를 복사하지 않습니다.
테스트 코드가 실제 집계 함수를 그대로 다시 구현해 기대값을 만들면 같은 실수를 반복할 수 있습니다. 작은 고정 기대값과 계약을 먼저 검토하세요. 파일이 큰 경우의 메모리와 처리 시간은 별도 측정입니다. 작은 합성 테스트로 대용량 성능을 주장할 수 없습니다. 실제 업무 데이터의 접근 정책과 개인정보 처리 역시 합성 자료의 통과와 다릅니다. 어떤 입력과 어떤 검사를 실행했는지 정확히 기록해야 합니다.
결과 파일 확정과 실패 알림을 설계하기#
출력은 모든 필수 검사가 끝난 뒤 확정하는 흐름을 검토하세요. 중간 파일을 최종 결과 이름으로 바로 쓰면 실패한 결과가 정상 파일처럼 남을 수 있습니다. 임시 경로와 최종 경로, 이전 결과의 보존 방식과 중복 실행 처리를 정합니다. 같은 입력으로 다시 실행했을 때 결과가 같은지 확인하려면 입력 목록, 계약 버전과 실행 설정도 필요합니다. 실행 시점에 따라 결과가 달라지는 기본값을 쓰는 경우 그 값을 기록하세요.
실패 알림은 오류 내용과 개인정보를 분리합니다. 담당자가 조치할 파일 식별자, 실패 단계와 재실행 조건만으로 충분한지 검토하세요. Slack이나 이메일로 보내는 행동은 외부 게시이므로 채널과 내용의 별도 승인이 필요합니다. 알림 전송 실패가 집계 실패와 같은 상태인지도 정해야 합니다. 이 글은 실제 CI와 알림 서비스를 실행하지 않았으며 모의 오류 메시지로 실제 전송 증거를 대신하지 않습니다.
CI에 붙일 때의 신뢰 경계#
정기 작업의 실행 계정에는 필요한 입력 읽기와 결과 쓰기 권한만 검토합니다. 저장소 PR의 코드를 비밀값이 있는 환경에서 무조건 실행하지 마세요. PR 검사와 승인된 정기 집계, 결과 게시를 구분하고 대상 커밋을 기록합니다. 외부 산출물이나 CSV 셀의 내용을 실행 스크립트로 취급하면 안 됩니다. 비밀값과 고객 데이터가 로그에 나오지 않도록 실패 경로도 확인해야 합니다. 실제 인증과 실행·종료 상태가 검증되기 전에는 자동 게시를 켜지 않습니다.
CI 결과를 업무 담당자가 읽는다면 실패 상태와 새 보고서의 유무를 함께 보여 줘야 합니다. 예를 들어 이번 실행이 실패했는데 지난 보고서 파일이 남아 있으면 사용자가 최신 결과로 오해할 수 있습니다. 결과의 대상 기간과 입력 목록을 표시하고 새 결과를 확정하지 못한 이유를 분리하세요. 실제 운영 리포트나 고객 자료를 임의로 가져와 시험하지 말고 승인된 비식별 입력 계약과 기대 결과로 먼저 검토합니다. 로컬 명령의 성공은 스케줄러·권한·알림 경로가 동작했다는 증거가 아닙니다.
추가 근거: Python CSV 읽기·쓰기, Decimal의 고정 소수점 검증. CSV 파싱과 숫자 처리의 근거이며 정기 실행의 완료 기록은 아닙니다.
직접 실행한 정상·오류 CSV 계약 검사#
2026-11-03에 Python 3.13.9의 csv 모듈로 합성 fixture 스크립트의 CSV 검사를 별도로 실행했습니다. 이전의 정상 입력 예제와 구분되는 추가 실행입니다. 새 계약은 헤더 id,branch,amount, 비어 있지 않은 주문·지점, 중복 없는 주문 키와 음수가 아닌 정수 금액만 허용합니다. 이 규칙은 가상의 검사용 계약이며 모든 매출 업무의 취소·소수점 규칙을 대신하지 않습니다. 외부 서비스, Mirr와 CI는 실행하지 않았습니다.
헤더가 있는 입력과 없는 입력에 같은 세 행을 주고 각각 행 수 3, A 150, B 80과 합계 230을 assertion으로 확인했습니다. 헤더 없는 경우에는 DictReader의 fieldnames를 직접 지정했습니다. 빈 금액, 같은 주문 키, 남는 열, 음수, 다른 헤더와 빈 파일은 각각 실패하도록 기대값을 정했습니다. 실제 출력은 다음과 같습니다.
csv:header: rows=3 A=150 B=80 total=230
csv:headerless: rows=3 A=150 B=80 total=230
csv:missing_amount: rejected=amount
csv:duplicate_id: rejected=duplicate
csv:extra_field: rejected=columns
csv:negative: rejected=amount
csv:wrong_header: rejected=header
csv:empty: rejected=header
오류 사례에서는 무조건 성공 처리하지 않고 기대한 오류 종류와 실제 결과가 같은지 확인했습니다. 잘못된 입력에서 일부 행을 읽었더라도 그 부분합을 최종 리포트로 내보내지 않았습니다. 정상 두 사례에는 지점별 합계를 담은 작은 Markdown 표를 각각 생성했습니다. 이는 로컬 텍스트 산출물이며 실제 업무 리포트 화면이나 실패 알림 전송 증거가 아닙니다. 실행 기록에는 출력 경로와 각 생성 파일의 해시가 있어 어느 결과를 비교했는지 확인할 수 있습니다.
소스는 2026-11-03 합성 예제 스크립트입니다. 새 결과 디렉터리만 만들도록 했고 표준 출력과 오류 출력, 종료 상태를 따로 보관했습니다. 이 스크립트는 새 업무 파서로 채택하라는 제안이 아니라 작은 계약을 재현하는 독립 fixture입니다. 실제 저장소에 입력 처리 코드가 있다면 그 구현과 오류 방식을 먼저 읽고 확장해야 합니다. 별도의 유사 파서를 무조건 추가할 필요는 없습니다.
이 검사에는 인용된 쉼표와 여러 줄 필드, 잘못된 인코딩, 대용량 성능과 스프레드시트 수식 해석이 없습니다. 따라서 그 조건은 검증된 것으로 표시하지 않습니다. 정기 실행, 중복 실행과 알림도 검사하지 않았습니다. 생성한 두 Markdown 표는 이 작은 입력의 고정 합계를 쓴 로컬 텍스트이며 일반 리포트 생성기의 검증 결과가 아닙니다. 실제 업무 리포트 화면과 CI 자료도 없습니다. 로컬 오류 거부를 CI가 안전하게 동작한다는 주장으로 확대하지 마세요. 적용할 업무 계약에서 필요한 실패 입력을 골라 추가 검사를 설계할 수 있습니다.
오류 CSV를 보관할 때는 재현에 필요한 최소 행만 남기는 방법을 검토하세요. 원본 파일 전체를 알림에 첨부하면 개인정보가 불필요하게 퍼질 수 있습니다. 파일 식별자와 계약 위반 필드, 가린 위치 정보로 담당자가 승인된 저장소에서 원본을 찾을 수 있는지 정합니다. 합성 검사에서는 모든 데이터가 직접 만든 값이지만 실제 업무 자료에는 같은 보관 방식을 그대로 적용할 수 없습니다. 조직의 보존 정책과 접근 권한을 확인해야 합니다.
합성 검사의 주문 키는 파일 전체에서 유일하도록 정했습니다. 실제 여러 파일을 합친다면 지점별 키인지 전체 주문 키인지부터 합의해야 합니다. 지점마다 같은 번호를 쓸 수 있다면 지점 코드와 주문 번호의 조합을 검토할 수 있습니다. 반대로 같은 주문이 다른 지점 파일에 정정본으로 들어올 수 있다면 단순 조합만으로 중복을 찾지 못할 수 있습니다. 어떤 자료가 정본인지 업무 규칙이 필요합니다. 이 결정 없이 중복 제거를 자동으로 수행하면 정상 행을 잃거나 같은 주문을 두 번 더할 수 있습니다. 작은 정상 합계만으로 이 조건을 검증했다고 보고하지 마세요.
설치된 Mirr의 합성 CSV 과제와 별도 교정#
2026-11-03에 설치된 Mirr v0.6.15, macOS arm64에서 작은 Node.js 과제를 수행한 뒤 coordinator가 별도 교정 요청을 보냈습니다. 입력은 date,team,amount 헤더와 인용하지 않은 세 열의 고정 형식입니다. 일반 RFC CSV 전체를 지원하는 파서가 아니며 앞의 Python fixture와도 다른 과제입니다. 실제 node --test sales.test.mjs와 node generate-result.mjs 실행이 기록돼 있습니다.
| 관찰한 단계 | 실제 결과 | 해석 |
|---|---|---|
| 구현 전 검사 | 모듈이 없어 13개 실패 | 실행은 확인했지만 결함 동작을 잡은 실패와는 다름 |
| 최초 생성 검사 | 수정 뒤 13개 통과 | 생성한 기대값만으로 계약 충족을 보장하지 못함 |
| 별도 독립 검사 | 9건 중 6건 실패 | 부호·16진수·지수 금액 허용과 불필요한 연도 제한 발견 |
| 교정 요청 뒤 회귀 검사 | 기존 검사를 보존하고 13개를 더해 26개 통과 | coordinator가 실패 조건을 제공한 감독하의 수정 |
| 마지막 독립 확인 | 처음의 동일한 9건 재통과와 별도 CRLF·저장 결과 비교 통과 | 확인한 고정 형식과 입력 범위에 한정 |
최초 구현은 +1, -0, 0x10, 1e3을 금액으로 받아들이고 요청하지 않은 19002100년 제한을 뒀습니다. coordinator가 독립 실패를 전달하고 금액은 ASCII 숫자만, 연도는 00019999이며 0000 제외라는 교정 조건을 명시했습니다. 모델이 누락 조건을 스스로 모두 발견한 사례가 아닙니다. 최초 13개가 통과했다는 사실만 보여 주면 잘못된 확신을 줄 수 있어 실패와 교정 이력을 함께 남깁니다.
저장된 합성 결과는 행 수 3, 전체 4000, 개발 2500과 영업 1500입니다. 실제 고객 매출이나 성능 통계가 아닌 입력의 문자 그대로의 기대값입니다. 최종 sales.mjs의 SHA-256은 15bac892ddb79ed43fbbb8dc237d90f4cacfb067c88d0c0d8144ba6efac0529b입니다. 최종 산출물 다섯 개의 해시도 기록돼 있어 같은 파일을 대조할 수 있습니다.
이는 한 합성 로컬 과제와 명시적인 별도 교정의 관찰입니다. Excel·HWPX 화면, 실제 업무 ETL, CI·알림·운영 DB와 외부 연동은 검증하지 않았습니다. 새 설치, 사람의 대화형 승인·거부와 체크포인트 복구, 모델 이름·비용·쿼터·비교 성능도 확인되지 않았습니다. 업무에 도입하려면 실제 입력과 보고서의 화면 대조, 정기 실행과 실패 처리도 검증해야 합니다.
다음에 읽을 것#
엑셀 자동화에서는 여러 시트와 수식이 있는 입력을 다룰 때의 선택 기준을 확인할 수 있습니다.
관련#
편집 메모 (2026-11-02): 헤더·합계·실행 범위 FAQ와 실패 진단표를 보충했습니다. 이후 추가한 2026-11-03 Python 검사는 정상 두 입력과 결측·중복 등 오류 여섯 입력을 실제 assertion으로 확인했습니다. 별도의 Mirr 합성 과제에는 최초 실패와 감독하의 교정, 동일 수락 사례 재검사 기록이 있습니다. 실제 업무 입력·리포트 화면과 같은 입력의 전후 비교, 스케줄러·CI·실패 알림과 운영 데이터 정책 검증은 여전히 없습니다. 두 로컬 텍스트 표를 그 증거로 대신하지 않습니다.