비개발자가 400페이지 서명 검사를 자동화하며 고민한 것

매달 마감이 되면 내 책상에는 두툼한 점검철 한 권이 올라온다. 어느 공공 사업의 월 유지관리 점검 기록을 묶은 것인데, 수백 페이지짜리 스캔본이다. 시스템마다 앞에 표지가 한 장씩 있고, 그 표지 맨 아래 오른쪽에 점검자와 확인자가 서명과 날인을 한다. 마감을 담당하는 내 일은 여기서 딱 하나다. 모든 표지에 두 사람의 서명이 빠짐없이 들어갔는지 확인하는 것이다.

말로 쓰면 한 줄이지만, 실제로는 400페이지가 넘는 스캔본을 한 장씩 넘기며 표지를 골라내고, 서명란 두 칸을 눈으로 대조하는 일이다. 한장이라도 놓치면 마감이 틀어진다. 매달 30분에서 한 시간씩, 나는 이 단순 반복에 시간을 썼다.

그래서 자동화를 마음먹었을 때, 솔직히 처음 떠오른 건 이거였다. “요즘 AI가 좋다는데, PDF 파일을 던져주고 ‘서명 없는 칸 찾아줘’ 하면 끝나는 거 아닌가?” 결론부터 말하면, 그렇게 하지 않았다. 아니, 그렇게 할 수가 없었고, 몇 번 부딪히고 나서는 일부러 그렇게 하지 않기로 했다.

이 글은 도구를 만든 자랑이 아니다. 코딩이 본업이 아닌 사업관리 담당자가, 반복 업무 하나를 자동화하면서 “어디까지 도구에 맡기고 어디부터는 내가 봐야 하는가”를 정하게 된 기록이다. 완성품보다 그 사이에서 다섯 번 넘어진 이야기와, 두 번의 방향 전환이 이 글의 진짜 내용이다.

“그냥 AI한테 다 시키면 안 돼?”가 안 되는 이유

가장 먼저 막힌 건 파일 그 자체였다. 대상은 400페이지가 넘고 용량은 100메가바이트를 웃도는데, 전체가 스캔 이미지였다. 종이에 서명·날인을 하고 그걸 복합기로 통째로 스캔한 문서라, 안에 ‘글자 데이터’가 없다. 화면으로 보면 글씨가 또렷하지만, 컴퓨터 입장에서는 전부 사진 한 장이다. 그러니 “서명이라는 글자를 검색”하는 방식은 시작부터 성립하지 않았다.

사실 이건 파일을 열자마자 알았어야 했는데, 나는 한참 뒤에야 깨달았다. 처음엔 화면에 글씨가 멀쩡히 보이니 당연히 검색이 될 줄 알고, 서명이라는 단어를 찾게 시켰다가 아무것도 안 잡혀서야 “아, 이게 다 사진이구나” 하고 알아챘다. 비개발자가 자동화를 처음 붙일 때 흔히 하는 착각이 이거라고 생각한다. 화면에 보이는 것과 컴퓨터가 읽을 수 있는 것은 다르다.

보통 이럴 때 쓰는 게 이미지에서 글자를 읽어내는 OCR(광학문자인식) 프로그램인데, 이것도 막혔다. 내가 쓰는 건 회사 보안 환경의 업무용 PC라, 외부 프로그램을 함부로 설치할 수 없다. 인터넷에 파일을 올려서 처리하는 온라인 서비스도 당연히 못 쓴다. 점검철에는 서명과 날인이 들어 있으니 개인정보에 해당하고, 이건 회사 밖으로 나가면 안 되는 자료다. 자동화를 한다고 회사 자료를 외부 도구에 올리는 순간, 편하려다 사고가 나는 셈이다.

정리하면 나는 이런 상자 안에 있었다. 글자 검색 불가, 프로그램 설치 불가, 외부 전송 불가. AI에 통째로 맡기는 그림이 가장 먼저 깨진 지점이 바로 여기다.

그런데 돌아보면, 이 제약이 오히려 도구의 방향을 잡아줬다. 글자를 못 읽으면, 사람이 눈으로 하듯 그림으로 보고 판단하게 만들면 된다. 제약이 없었다면 나는 아마 편한 길로 갔다가 앞서 말한 사고를 냈을 것이다.

그래서 무엇으로, 어떻게 만들었나?

이제 도구 이야기다. 나는 개발자가 아니라서, 이 도구의 설계 대부분은 클로드 코드(Claude Code)와 대화하며 잡았다. 내가 문제와 제약을 설명하면 클로드가 코드를 제안하고, 나는 그게 왜 안 되는지 실제 파일로 확인해 다시 방향을 트는 식이었다. 따라 해보려는 분을 위해, 무엇을 어떻게 썼는지는 최대한 그대로 남긴다.

환경과 핵심 도구

환경은 회사 보안 PC(윈도우)다. 인터넷·설치 없이 돌아가야 하므로, 파이썬(Python)과 오프라인에서 쓸 수 있는 라이브러리(library, 미리 만들어진 기능 묶음)만으로 구성했다. 핵심 도구 세 가지는 이렇게 나눠 썼다.

• PyMuPDF:PDF의 각 페이지를 한 장씩 흑백 이미지로 바꾸는 데 썼다. 글자를 못 읽으니, 페이지를 아예 ‘사진’으로 만들어 픽셀(pixel, 이미지를 이루는 작은 점) 단위로 다루기 위해서다.
• NumPy:그렇게 만든 이미지를 숫자 표로 바꿔서, 특정 영역이 얼마나 ‘어둡게 칠해져 있는지’를 계산했다. 서명이 있으면 그 자리에 잉크가 묻어 어두워지고, 비어 있으면 밝다. 결국 서명 유무를 ‘잉크 양’이라는 숫자로 바꾼 것이다.
• Pillow:판정이 끝난 서명 부분만 잘라내 사람이 볼 수 있는 이미지로 저장하는 데 썼다.

동작 순서와 실행 방식

돌아가는 순서는 이렇다. 먼저 낮은 해상도로 페이지를 빠르게 훑어 표지인지 아닌지 가려낸다. 표지라고 판단되면 그 페이지만 다시 높은 해상도로 읽어 서명란 두 칸의 잉크 양을 잰다. 그리고 애매한 것만 위로 올려 사람이 보게 한다. 마지막으로 결과를 그림이 들어간 HTML 한 장으로 저장하는데, 이건 마감 증빙으로도 그대로 쓴다.

실행 방식도 나 같은 사람이 쓸 수 있어야 했다. 명령어를 칠 줄 몰라도 되도록, 점검철 PDF를 배치 파일 아이콘 위에 끌어다 놓기만하면 분석이 시작되게 만들었다. 매달 쓰는 도구인데 매번 사용법을 떠올려야 한다면, 그건 자동화가 아니라 또 다른 숙제다.

다섯 번 넘어진 이야기

‘표지만 자동으로 골라낸다’는 이 한 문장이, 실제로는 가장 오래 걸린 부분이었다. 스캔본은 페이지마다 밝기와 기울기가 제각각이라, 그럴듯한 기준을 세울 때마다 번번이 빗나갔다. 순서대로 적어 본다.

• 잉크가 많은 페이지를 표지로 보자:실패. 표지나 글자 빽빽한 보고서나 잉크 양이 비슷해서 구분이 안 됐다.
• 가운데 큰 제목 글자의 진하기로 보자: 실패. 표지의 제목이 오히려 더 진해서, 일반 페이지가 표지로 잘못 잡혔다.
• 회사 로고 색으로 표지를 찾자: 어떤 표지는 흑백으로 스캔되어 색 정보가 아예 없었다.
• 표의 세로선 개수로 판단하자:실패. 본문의 체크리스트 표와 겹쳐서 오히려 더 헷갈렸다.
• 맨 위 굵은 검은 띠로 표지를 확정하자: 절반의 성공, 절반의 실패. 잘 되다가도, 흐리게 스캔된 표지에서는 그 띠를 놓쳤다.

넘어질 때마다 나는 클로드에게 “이건 왜 안 됐을까”를 설명하고, 실패한 페이지를 예로 들어 다시 물었다. 그러면 클로드가 다른 방법을 제안하고, 나는 또 실제 파일로 돌려 확인했다.

이 과정이 지루하게 느껴질 수도 있는데, 나는 오히려 이때 자동화가 뭔지 감을 잡았다. 자동화는 ‘한 번에 맞히는 마법’이 아니라, 틀린 이유를 하나씩 지워 가는 일에 가깝다. 개발을 못 해도 이건 할 수 있다. 틀린 결과를 눈으로 알아보고, 왜 틀렸는지 말로 설명할 수만 있으면 된다.

한 방에 맞는 ‘단일 정답’은 없었다. 다섯 번을 헤매고 나서야 방향을 바꿨다. 하나의 완벽한 기준을 찾는 대신, 약한 신호 여러 개를 겹쳐서 판단하게 한 것이다. 본문 여백 비율, 상단의 검은 띠, 하단 오른쪽의 서명 블록, 페이지 번호 유무. 각각은 불완전하지만, 함께 보면 표지를 꽤 안정적으로 골라냈다.

사람도 표지를 알아볼 때 한 가지만 보지 않는다는 걸 생각하면, 오히려 자연스러운 방식이었다.

그리고 이때 원칙을 하나 세웠다. “빠뜨리느니, 차라리 좀 더 보여주자.” 마감 검사에서 진짜 위험한 건 없는 걸 잘못 띄우는 것(오탐)이 아니라, 있는 걸 못 보고 지나치는 것(누락)이다. 그래서 애매하면 무조건 사람이 한 번 더 보도록, 판정을 ‘확인 필요’ 쪽으로 기울여 두었다.

두 번의 방향 전환

만들면서 흐름을 바꾼 순간이 두 번 있었다.

첫 번째, 서명란을 기준점으로 삼다

서명란이 비었는지 보려는데, 표지마다 서명 블록의 위치가 미세하게 달라서 자꾸 엉뚱한 자리를 쟀다. 멀쩡히 서명된 칸을 ‘비었다’고 잘못 읽기도 했다. 한참을 헤매다 알아챘다. 서명 칸이 비어 있어도, 그 옆의 ‘(인)’이라는 날인 표시는 인쇄물이라 항상 같은 자리에 찍혀 있다. 이 ‘(인)’을 기준점으로 삼아 점검자 칸과 확인자 칸의 위치를 잡으니, 한쪽이 비어 있어도 정확히 그 자리를 짚어냈다. 작은 발상 하나로 막혔던 게 풀렸다.

두 번째, 도구에도 다 맡기지 않기로 하다

스캔 품질이 들쭉날쭉하다 보니, “서명이 있다 / 없다”를 도구가 100% 단정하게 만드는 건 위험했다. 흐린 서명을 없다고 우기거나, 얼룩을 서명으로 볼 수 있었다.

그래서 나는 도구의 역할을 일부러 줄였다. 도구는 표지를 전부 찾아 서명 부분만 잘라 한 화면에 모아주는 데까지만 하고, 있다·없다의 최종 판단은 사람이 1초 눈으로 하도록 했다. 의심스러운 것만 빨갛게 맨 위로 올려서. 처음의 “AI한테 다 시키자”에서 정확히 반대편으로 온 셈인데, 이게 더 정직하고 실제로 더 빨랐다.

그래서 얼마나 바뀌었을까

완성한 도구로 그달 점검철(400페이지가 넘는 실제 파일)을 돌려봤다. 표지를 빠짐없이 찾아냈고, 서명 누락은 0건으로 확인됐다. 시간으로 보면, 30분에서 한 시간 걸리던 눈 검사가 1분 남짓의 자동 분석과 한 화면 확인으로 줄었다. 매달 반복되는 일이니, 1년으로 치면 결코 작지 않은 시간이다.

무엇보다 결과물이 그림이 들어간 문서 한 장으로 남으니, “확인했다”는 말이 아니라 “이렇게 확인했다”는 증빙이 함께 생긴 것도 실무에서는 컸다. 마감 업무는 결국 누군가에게 “제대로 봤다”는 걸 설명해야 하는 일이기도 한데, 이제는 그 근거가 파일로 남는다. 시간을 줄인 것보다 이쪽이 더 마음에 든다.

솔직히 처음 도구를 돌려 누락 0건이 뜨고, 그게 눈으로 다시 봐도 맞았을 때의 기분은 좀 특별했다. 한 시간짜리 눈싸움이 1분으로 줄어드는 걸 직접 보면, 다음엔 또 어떤 일을 넘길 수 있을까 하는 생각이 자연스럽게 든다.

실제로 이 도구는 내가 최근 넉 달 동안 업무에 붙여 만든 자동화 도구 여러 개 중 하나다. 대단한 개발을 한 게 아니라, 귀찮고 반복적인 일을 하나씩 골라 자동화해 본 결과다. 하나가 되니 그다음이 보였고, 그렇게 늘어났다.

마치며: 도구에 다 맡기지 않는다는 것

이 작업에서 내가 진짜로 배운 건 파이썬 문법이나 라이브러리 이름이 아니었다. 어디까지 도구에 맡기고, 어디부터는 사람이 봐야 하는가를 스스로 정한 경험이다.

처음엔 “AI가 다 해주겠지”로 시작했지만, 실제로 쓸모 있는 도구는 정반대 지점에 있었다. 도구는 사람이 지치는 일, 400페이지를 뒤져 표지를 찾고, 서명란만 잘라 모으는 일을 대신하고, 판단이라는 마지막 1초는 사람에게 남겨 둔다. 나는 이걸 ‘사람 먼저, 도구 나중’이라고 부르는데, 다음에 다른 업무를 자동화할 때도 계속 쓰게 된 기준이다.

나는 개발자가 아니다. 그런데도 현장에서 매달 쓰는 도구 하나를 완성했다. 내가 한 일은 문제를 정확히 정의하고, 안 되는 걸 솔직히 인정하고 방향을 다시 트는 것이었다. 구현은 클로드와 함께했다. 혹시 지금 반복 업무에 지쳐 있는데 “나는 코딩을 못 하니까”라며 미뤄 두고 있다면, 딱 하나만 권하고 싶다. 가장 귀찮은 일 하나를 골라, 어디까지 맡길지부터 정해 보는거다. 거기서부터 생각보다 많은 게 바뀐다.

이 글은 AI의 도움을 받아 작성했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.