엑셀 파일 100개, AI 자동화는 어디까지 맡길 수 있을까?

“100개 넘는 엑셀 파일에서 특정 데이터를 뽑아 하나로 만들고 싶은데, 파일마다 시트와 필요한 정보가 다르다면?”

결과부터 말하면, 실험용으로 만든 가짜(합성) Excel 파일 100개 중 83개는 프로그램이 값을 하나로 정해 OK로 출력했고 17개는 검토 목록으로 보냈다. 미리 정답을 적어 둔 표와 사후에 대조하니 OK 83개는 모두 일치했다. 여기서 중요한 점이 하나 있다. 실행할 때마다 AI가 파일을 읽고 의미를 판단한 것이 아니다. AI가 대표 파일을 보고 만든 고정 규칙 Python 프로그램을 내 컴퓨터에서 반복 실행했다.

전체 관계는 다음과 같다.

검토 17개는 다시 모호한 값 5개 + 실제 값 없음 4개 + 프로그램이 놓친 정상값 8개로 나뉘었다. 실제 업무에는 정답표가 없으므로 마지막 두 종류를 파일을 열기 전에 구분할 수 없다는 점이 이 실험의 핵심 한계다.

17개가 검토 목록으로 간 이유

합성 보고서 100개 가운데 91개에는 추출해야 할 정상값을 하나씩 넣었다. 4개에는 값을 넣지 않았고, 5개에는 같은 항목의 서로 다른 값을 두 개 넣어 정답을 하나로 정할 수 없게 했다.

첫 버전을 고친 최종 프로그램의 출력과 정답표를 대조한 결과는 이랬다. 수정 과정은 다음 절에서 설명한다.

MISSING 12개는 출력만 보면 모두 똑같이 “값을 찾지 못함”이다. 정답표가 있었기 때문에 그중 4개는 실제 값 없음, 8개는 탐지 누락이라고 나눌 수 있었다. 실제 회사 파일에서는 사람이 원본을 확인하기 전까지 이 둘을 구별하기 어렵다.

AI는 파일을 매번 읽지 않고 규칙을 만들었다

처음에 AI에게 보낸 요청은 이랬다. 파일과 워크시트 구성이 제각각이니, 시트명이나 특정 단어를 보고 보고서 유형별로 필요한 값을 찾아 달라는 것이었다. 실험에서는 여기에 원본 파일명·워크시트명·라벨 셀·값 셀을 결과에 남기고, 통합표와 대시보드를 만들며, 원본은 수정하지 말라는 조건을 더했다.

Claude의 fable 모델에는 합성 대표 파일 5개와 요청을 보냈다. Claude가 만든 프로그램은 매출·예산·프로젝트 유형을 구분하고 정해진 시트명과 라벨 표현을 찾아 값을 가져오는 방식이었다. 실행 중 외부 AI를 호출하는 프로그램은 아니었다.

대표 5개는 모두 정확했지만, 같은 코드를 100개 전체에 실행하자 정상값이 있는 91개 중 60개만 찾았다. 찾았다고 확정한 60개는 정답표와 모두 일치했지만 31개를 놓쳤다. 첫 실행이 찾아낸 비율은 **60/91, 약 65.9%**였다.

놓친 파일 3개를 추가 예시로 보내 Claude에 수정을 요청했지만 답이 끝까지 오지 않아 수정본을 받지 못했다. 이후 다른 AI 코딩 도구인 Codex가 전체 실적, 승인 금액, 누적 집행 같은 표현을 같은 의미의 항목으로 인식하도록 규칙을 넓히고 차트를 추가했다. 특정 파일명·셀 위치·금액을 답처럼 코드에 넣지는 않았다.

Codex가 보완한 최종 프로그램은 정상값 91개 중 83개를 찾았다. 이때의 **83/91, 약 91.2%**는 “전체 파일 중 성공률”이 아니라 “정상값이 있는 91개 가운데 찾아낸 비율”이다. 처음 예시 5개와 수정 때 확인한 3개도 이 100개 안에 포함됐으므로, 이는 예시에 쓰지 않은 별도 파일로 측정한 점수가 아니다.

프로그램이 OK로 확정한 83개만 놓고 보면 모두 정답표와 일치했다. 즉 틀린 값을 맞다고 내놓은 경우인 오추출은 없었다. 다만 이것이 다른 실제 파일에서도 오류가 없다는 보장은 아니다.

0.73초보다 중요한 것은 출처와 검토 방식이었다

최종 프로그램은 파일 100개를 0.73초에 처리했다. 미리 갖춰진 Python 환경과 Excel 파일을 읽고 쓰는 부품인 openpyxl을 사용했고, 실행 중 외부 AI 호출은 0회였다. 원본 파일도 바꾸지 않았다.

그러나 0.73초는 이미 만들어진 프로그램의 반복 실행 시간일 뿐이다. 자동화를 설계하고, 대표 파일을 준비하고, Claude 수정 요청이 완료되지 않은 뒤 코드를 수정하고, 결과를 검증한 전체 시간은 일관되게 측정하지 않았다. 사람이 100개를 직접 처리한 기준 시간도 없으므로 “몇 배 빨라졌다”거나 손익분기 횟수를 계산할 수 없다.

자동 확정 83개도 무조건 믿을 수는 없다. 이번에는 정답표로 모두 맞았음을 확인했지만, 실제 대시보드의 전체 합계를 믿으려면 필요한 수준만큼 원본 근거를 추적해야 한다. 그래서 통합표에 원본 파일명, 워크시트명, 라벨 셀, 값 셀을 남겼다. 합계가 중요하다면 17개만 보는 것으로 끝내지 말고 83개의 출처도 표본 검사하거나 전수 확인할 수 있어야 한다.

실제 업무에 옮긴다면 이렇게 시작하는 편이 안전하다

처음부터 모든 예외를 AI에게 글로 설명할 필요는 없다. 대신 대표 파일과 원하는 결과를 함께 주고, 다음 안전장치를 요구하는 편이 현실적이다.

1. 회사 자료가 아닌 합성 파일이나 비식별 예시로 먼저 시험한다.
2. 자주 나오는 보고서 유형을 대표하는 소수의 파일과 원하는 추출 결과를 제시한다.
3. 모든 결과에 원본 파일·시트·라벨·값 셀을 남기게 한다.
4. 후보가 겹치거나 값을 못 찾으면 추측하지 말고 검토 목록으로 보내게 한다.
5. 예시에 쓰지 않은 별도 파일과 정답표로 탐지 누락과 오추출을 확인한다.
6. 실제 회사 파일이나 검토 목록을 외부 AI에 보내기 전에는 조직의 데이터 처리 정책을 확인한다.
7. 생성된 프로그램이 원본을 덮어쓰거나 작업 폴더 밖 파일에 접근하지 않는지 실행 전에 확인하고, 먼저 복사본에서 실행한다.

AI가 만든 규칙은 보고서 형식이 바뀌면 다시 점검해야 한다. 새 파일을 추가해 같은 프로그램으로 통합표와 대시보드를 갱신하는 과정은 이번에 시험하지 않았다.

이번 실험에서 확인하지 못한 것

처음 검토 단계에서 후보로 놓았던 다른 방식은 실행할 때마다 AI가 각 파일의 의미를 판단하는 자동화였다. 이번에는 비용 때문에 그 방식을 시험하지 않았다. 따라서 파일별 AI 판단 방식의 정확성·비용·보안 부담은 알 수 없다.

또한 정확히 100개만 시험했으며 100개 초과 규모는 실행하지 않았다. Excel이 없는 환경이라 Apple의 Numbers 앱으로 열어 보고 파일 구조를 검사하는 방식으로 결과를 확인했기 때문에 Excel에서의 완전한 호환성도 검증하지 않았다. 비개발자가 직접 설치·실행·오류 대응을 할 수 있는지도 시험하지 않았다.

Excel 자체의 대안도 있다. Microsoft 공식 문서에 따르면 Power Query는 기록한 데이터 변환을 새로 고침 때 다시 적용할 수 있다. Office Scripts는 반복 동작을 기록하거나 코드로 만들어 다시 실행할 수 있지만 계정·라이선스·관리자 설정·플랫폼 조건이 있다. 이번 실험은 두 기능을 실행하거나 현재 Python 프로그램과 비교하지 않았다.

결론: 자동화의 목표는 검토를 없애는 것이 아니었다

이번에 실행한 것은 파일마다 AI가 의미를 판단하는 방식이 아니라, AI의 도움으로 만든 고정 규칙 Python 프로그램이었다. 수정본은 합성 파일 100개 가운데 83개를 자동 확정하고 17개를 검토 목록으로 분리했다. 정상값 91개를 기준으로는 83개를 찾고 탐지 누락 8개를 남겼다. 대표 5개의 완벽한 결과만으로 전체 성공을 판단할 수 없었고, 고정 규칙은 보지 못한 표현을 여전히 놓쳤다.

따라서 이 방식의 가치는 “AI가 알아서 다 처리한다”는 데 있지 않다. 반복 취합을 빠르게 실행하면서도 출처를 남기고, 애매하거나 찾지 못한 파일을 사람이 확인할 수 있게 만드는 데 있다. 실제로 시도한다면 먼저 합성 예시로 검증하고, 원본을 보존하며, 결과에서 원본 셀까지 돌아갈 수 있게 만드는 것부터 시작하는 편이 안전하다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.