처음에는 단순한 불안에서 시작했습니다. 기존 PC 프로그램에서 뽑던 거래명세서와 웹에서 뽑는 거래명세서가 정말 같은지, 늘 마음 한구석이 찜찜했습니다. 동기화가 조금이라도 어긋나면 거래명세서 인쇄는 곧바로 사고로 이어질 수 있으니까요.
그래서 웹 기능을 만들어 놓고도 인쇄만큼은 기존 프로그램에 더 기대고 있었습니다. 그러다 문득 이런 생각이 들었습니다. “모바일에서 기존 PC 프로그램을 직접 조작해 인쇄하게 만들면 되지 않을까?” 비개발자인 제 머릿속에서는 꽤 그럴듯한 방법처럼 보였습니다.
‘불안하다’와 ‘실제로 틀리다’는 다르다
AI와 가장 먼저 한 일은 감으로 결론 내리지 않는 것이었습니다. 동기화 로그와 자동 검증 기록부터 다시 확인했습니다. 결과는 의외였습니다. 최근 영업일을 기준으로 거래명세서 대상 매출 건수와 금액이 계속 맞고 있었습니다.
물론 이것만으로 “완벽하다”고 말할 수는 없습니다. 입력 직후 몇 초 안에 인쇄하는 경우, 기존 프로그램에서 수정한 전표가 언제 반영되는지, 실제 종이 출력 양식이 눈으로 봐도 같은지 등은 별도로 검증해야 했습니다. 그래도 최소한 “동기화는 막연히 못 믿겠다”는 상태와는 거리가 있었습니다.
모바일에서 PC 프로그램을 조작하는 방식의 한계
다음으로 살펴본 것은 기존 PC 프로그램을 모바일에서 직접 다루는 방법이었습니다. 원격 데스크톱으로 접속해 버튼을 누르는 방식은 당장 가능해 보였습니다. 하지만 모바일 화면에서 PC 프로그램을 조작하고 사무실 프린터 상태까지 맞춰야 했습니다. 급할 때 쓰는 비상수단은 될 수 있어도, 매일 사용하는 자동화라고 부르기는 어려웠습니다.
RPA처럼 화면을 대신 눌러주는 방식도 검토했습니다. 하지만 사무실에서 누군가 같은 프로그램을 사용하고 있으면 화면을 빼앗을 수 있고, 버튼 위치나 창 모양이 조금만 바뀌어도 작동하지 않을 수 있었습니다. 처음에는 멋져 보였지만 실제 운영 관점에서는 불안한 자동화였습니다.
AI와 함께 방향을 바꾼 지점
이날의 결론은 “기존 프로그램을 억지로 조작하자”가 아니었습니다. 오히려 반대였습니다. 웹 인쇄와 동기화가 이미 상당 부분 맞아가고 있다면, 먼저 웹 인쇄를 실제로 검증해 신뢰할 수 있는 범위를 확정하자는 쪽으로 방향을 바꿨습니다.
AI가 정리한 순서도 마음에 들었습니다. 첫째, 실제 거래 몇 건을 기준으로 기존 출력물과 웹 출력물을 나란히 비교합니다. 둘째, 입력 직후와 수정 직후처럼 위험한 시점을 따로 테스트합니다. 셋째, 문제가 발견되면 기존 프로그램을 원격조작하는 대신 웹 인쇄 엔진을 고칩니다.
비개발자인 저는 자꾸 “새로운 자동화 기술”부터 떠올립니다. 하지만 이번에는 자동화가 멋진 조작을 붙이는 일이 아니라, 어디까지 믿을 수 있는지 경계를 그리는 일에 더 가깝다는 것을 배웠습니다.
비개발자 김부장이 배운 점
이번 작업에서 가장 크게 배운 것은 질문의 순서였습니다.
예전 같으면 “모바일로 기존 프로그램을 조작할 수 있어?”라고 바로 물었을 겁니다. 하지만 AI와 함께 살펴보니 먼저 물어야 할 질문은 따로 있었습니다.
“정말 기존 프로그램을 조작해야만 하나?”
이미 웹 시스템이 충분히 맞고 있다면 불안한 우회로를 만드는 것보다, 검증표를 만들고 남은 차이를 줄이는 편이 낫습니다. 특히 거래명세서처럼 실수가 곧바로 현장 문제로 이어지는 기능은 더욱 그렇습니다.
다음 편에서는 비슷한 맥락으로, 입고예정 자동화가 저녁 알림을 조용히 놓치던 문제를 시간 조건과 재시도 기준으로 어떻게 좁혀 봤는지 정리해보려 합니다.