충원 거절에서 시작된 비개발자의 업무 자동화 사례

반복 업무에 눌린 사람은 흔히 더 빠르게 처리하는 방법부터 찾는다. 그러나 이 사례가 보여주는 출발점은 다르다. 인력 충원이 어려운 상황에서 한 사업관리 담당자는 자신에게 몰린 업무를 그대로 가속하기보다, 왜 모든 요청과 검토가 자신을 거쳐야 하는지부터 다시 살폈다.

이 글은 자동화 기술의 기능 소개가 아니라 자동화를 시작할 수밖에 없었던 업무 환경, 첫 구조 개선, 비개발자의 학습 과정과 그 경험에서 일반화할 수 있는 원칙을 분석한다.

사례의 출발점: 일의 양보다 복잡성이 늘었다

해당 팀은 원래 인프라 운영 사업을 담당했다. 시스템을 안정적으로 운영하고 장애에 대응하며 월별 실적을 정리하는 업무에는 이미 익숙한 흐름이 있었다. 문제는 기존 인력을 유지한 채 새로운 유지관리 사업이 더해지면서 시작됐다.

이는 같은 일을 두 배로 수행하는 상황과 달랐다. 담당자는 경험하지 못한 업무를 처리하는 동시에 다음 요소까지 새로 설계해야 했다.

• 어떤 산출물을 받을 것인지
• 문서에 어떤 항목을 넣을 것인지
• 업체와 고객의 검토 순서를 어떻게 정할 것인지
• 작업별 번호와 일정을 어떻게 관리할 것인지
• 서명된 결과물을 어떤 방식으로 회수하고 보고할 것인지

업무가 늘어난 것뿐 아니라 업무를 처리할 체계까지 만들어야 했다는 점이 과부하의 핵심이었다.

표준이 없으면 검토와 반려가 반복된다

유지관리 산출물의 기존 표준이 충분하지 않아 담당자는 양식을 직접 만들고 업체에 배포했다. 하지만 현장에서는 이전 연도 서식을 사용하거나, 작업자 서명을 빠뜨리거나, 특이사항을 모호하게 작성하는 문제가 반복됐다.

예를 들어 결과란에 ‘추후 조치 예정’이라고만 적으면 관리자는 완료 시점을 추적할 수 없다. 구체적인 예정일을 적어 달라고 반려하고, 수정본을 다시 확인해야 한다. 점검 자체보다 산출물을 확인하고 수정시키는 관리 작업이 커지는 구조다.

이 사례는 문서 자동화보다 표준화가 먼저라는 점을 보여준다. 입력 형식과 필수 항목이 정해지지 않은 상태에서는 자동화 도구도 모호하고 불완전한 데이터를 빠르게 옮길 뿐이다. 자동화를 검토한다면 먼저 다음을 정해야 한다.

1. 반드시 입력해야 하는 항목
2. 허용되는 날짜와 이름 표기 방식
3. 서명이나 첨부가 필요한 조건
4. 반려 사유와 수정 책임자
5. 완료로 판단할 수 있는 기준

몇 분짜리 요청이 하루의 흐름을 무너뜨린 이유

보안상 외부 파일의 반입과 반출은 담당자 한 명을 거치는 단일 창구 방식으로 운영됐다. 요청 한 건의 처리 시간은 길지 않았지만, 요청 시점이 예고되지 않는다는 문제가 있었다.

본래 업무에 집중하던 중 요청이 들어오면 작업을 멈추고 파일을 처리해야 했다. 그 뒤에는 중단된 업무의 맥락을 다시 떠올려야 했다. 이 사례에서 체감 부담을 키운 것은 개별 요청의 소요 시간보다 반복되는 업무 전환이었다.

자동화 후보를 찾을 때는 한 건을 처리하는 시간만 계산해서는 부족하다. 다음 비용도 함께 살펴야 한다.

• 요청을 확인하고 우선순위를 판단하는 시간
• 하던 일을 멈추고 다시 시작하는 전환 비용
• 누락된 정보를 요청자에게 다시 묻는 시간
• 처리 여부를 별도로 기록하고 보고하는 시간
• 특정 담당자가 자리를 비웠을 때 생기는 대기 시간

짧지만 예측할 수 없이 반복되는 요청은 전체 일정과 집중력을 크게 흔드는 병목이 될 수 있다.

첫 해결은 자동화가 아니라 경로 제거였다

파일 반출입 문제에 대한 첫 개선은 프로그램 개발이 아니었다. 내부 프로젝트 관리 시스템의 게시판을 이용해 요청자와 고객이 직접 요청을 주고받도록 흐름을 바꿨다.

여기서 얻을 수 있는 원칙은 명확하다. 내가 맡은 일을 더 빨리 수행하는 것보다 그 일이 나를 거칠 필요가 없도록 만드는 편이 더 나은 해결일 수 있다.

자동화를 설계하기 전에는 다음 순서로 검토하는 것이 유용하다.

1. 없애도 되는 단계인가?
2. 요청자가 직접 입력하거나 확인할 수 있는가?
3. 기존 시스템의 기능으로 경로를 단순화할 수 있는가?
4. 입력과 판단 기준을 표준화할 수 있는가?
5. 그 뒤에도 남는 반복 작업을 자동화할 수 있는가?

여러 단순 업무가 동시에 몰리며 과부하가 고착됐다

유지관리의 전체 흐름에는 일정 수립, 업체·작업자 정보 정리, 번호 부여, 작업일지 회수, 고객 검토와 서명, 스캔, 검수 보고, 업체별 결과물 전달이 포함됐다. 각 단계는 개별적으로 어려운 업무가 아니었지만 한꺼번에 겹치면 사람이 기억과 수작업만으로 통제하기 어렵다.

이 상태는 약 석 달 동안 이어졌다. 낮에는 반출입 요청, 업체 문의, 팀원 확인과 고객 요청에 대응하고, 연락이 줄어드는 퇴근 시간 이후에야 밀린 핵심 업무를 처리하는 패턴이 반복됐다. 문제를 해결하는 것이 아니라 당일 발생한 일을 뒤늦게 따라잡는 상태에 가까웠다.

담당자는 업무보조 인력 충원을 요청했지만 받아들여지지 않았다. 인력 추가가 불가능해지자 기존 방식을 바꾸는 선택지가 중요해졌다. 자동화는 관심에서 시작된 취미가 아니라 현재의 업무 구조로는 다음 달에도 같은 문제가 반복된다는 판단에서 나온 대응이었다.

Claude Code 시연이 작은 실험의 계기가 됐다

전환점은 본사 행사에서 본 Claude 활용 자동화 시연이었다. 복잡한 개발 기술보다 ‘이 도구를 우리 업무에도 적용할 수 있겠다’는 가능성을 확인한 것이 중요했다. 함께 참석한 동료와 작은 시도를 해보자는 대화를 나눈 것이 이후 자동화 작업의 출발점이 됐다.

개발자가 아니었던 담당자는 Claude Code 설치 방법부터 다른 생성형 AI에 질문했다. 운영체제에 맞는 안내와 명령어를 확인해 실행하고, 영상 자료 등을 보며 다른 사용자의 초기 설정 과정을 따라 했다. 처음부터 프로그래밍 이론을 완전히 익힌 뒤 시작한 것이 아니었다.

다만 이 방식은 출처를 알 수 없는 명령어를 그대로 실행해도 된다는 뜻이 아니다. 업무용 기기에서는 조직의 보안 정책과 소프트웨어 설치 권한을 확인하고, 가능하면 공식 문서의 설치 절차를 사용해야 한다. 명령어가 파일 삭제, 권한 변경, 외부 전송을 수행하는지도 실행 전에 확인해야 한다.

결과물보다 중요했던 대화형 문제 해결 과정

첫 결과물은 ‘비개발자도 자동화를 만들 수 있다’는 자신감을 제공했다. 그러나 이 사례에서 더 중요한 학습은 완성된 프로그램보다 제작 과정에 있었다.

대화형 개발은 대체로 다음과 같은 순환으로 진행된다.

• 해결할 문제와 현재 절차를 설명한다.
• 입력 파일, 출력 형식, 보안 제한 등 제약 조건을 전달한다.
• AI가 제안한 방법과 코드를 검토한다.
• 복사본이나 시험 데이터로 실행한다.
• 오류 메시지와 예상과 다른 결과를 다시 설명한다.
• 수정안을 적용하고 재검증한다.

생성형 AI는 사용자가 몰랐던 기술이나 접근법을 제안할 수 있고, 낯선 용어를 다시 설명해 달라고 요청할 수도 있다. 반면 제안이 항상 정확하거나 조직의 환경에 적합한 것은 아니다. 따라서 AI는 판단을 대신하는 승인자가 아니라 선택지를 넓히고 시행착오를 줄이는 보조 수단으로 다뤄야 한다.

사례에서 추출한 자동화 대상 판단 기준

반복된다는 이유만으로 모든 업무를 자동화할 필요는 없다. 다음 기준을 함께 평가하면 우선순위를 정하기 쉽다.

우선 자동화할 업무는 보통 규칙이 명확하고 반복 빈도가 높으며, 결과를 사람이 쉽게 대조할 수 있는 작은 작업이다. 반대로 법적 판단, 보안 승인, 계약상 책임 또는 중요한 금액 결정이 포함된 업무는 사람의 검토 단계를 유지하는 편이 안전하다.

자동화에서 빠뜨리기 쉬운 통제와 유지관리

업무가 급하다는 이유로 자동화를 서두르면 기존의 수작업 위험이 코드 안으로 옮겨갈 수 있다. 특히 이 사례처럼 외부 파일, 서명본, 고객 자료를 다루는 환경에서는 처리 속도와 함께 통제를 설계해야 한다.

최소한 확인할 통제 항목

• 권한: 자동화 도구가 접근할 수 있는 폴더와 계정을 필요한 범위로 제한한다.
• 데이터 보호: 개인정보, 계약 자료, 인증정보를 승인되지 않은 외부 AI 서비스에 입력하지 않는다.
• 시험 환경: 원본이 아닌 복사본과 비식별 시험 데이터로 먼저 실행한다.
• 사람의 승인: 파일 전송, 삭제, 최종 보고처럼 되돌리기 어려운 단계에는 확인 절차를 둔다.
• 기록: 입력, 실행 시각, 처리 결과, 오류와 수정 이력을 남긴다.
• 복구: 실패했을 때 이전 상태로 돌아갈 수 있도록 원본과 백업을 보존한다.
• 담당자 의존성: 제작자 외의 팀원도 실행 방법과 중단 방법을 알 수 있도록 문서화한다.

자동화의 성공 기준도 ‘한 번 실행됐다’가 되어서는 안 된다. 양식이 바뀌거나 담당자가 교체돼도 수정할 수 있는지, 오류를 발견할 수 있는지, 수동 절차로 복귀할 수 있는지를 함께 평가해야 한다. 이는 단기적인 개인 생산성 도구와 지속 가능한 업무 시스템을 구분하는 기준이다.

경험에서 확인된 사실과 일반화할 때의 한계

이 사례는 한 담당자의 실제 경험을 바탕으로 하므로 모든 조직에 같은 결과를 보장하지 않는다. 사례에서 직접 확인되는 내용과 다른 환경에 적용할 때 검증해야 할 내용을 구분할 필요가 있다.

따라서 이 사례의 핵심 가치는 특정 도구가 누구에게나 같은 성과를 낸다는 주장에 있지 않다. 반복 업무를 개인의 노력 부족으로 해석하지 않고 흐름, 표준, 권한과 병목의 문제로 다시 정의했다는 데 있다.

결론: 시간이 없다는 사실이 출발점이 될 수 있다

자동화는 여유가 생긴 뒤 배우는 별도 프로젝트로만 볼 필요가 없다. 업무가 계속 쌓이고 다음 달에도 같은 문제가 반복된다면, 현재 구조를 바꿔야 한다는 신호일 수 있다.

출발은 거창한 개발 계획일 필요가 없다. 가장 자주 집중을 끊는 요청 하나를 고르고, 그 단계가 꼭 자신을 거쳐야 하는지부터 확인할 수 있다. 제거하거나 기존 시스템으로 넘길 수 없다면 입력 형식을 표준화하고, 결과를 쉽게 검증할 수 있는 작은 부분부터 자동화하는 편이 안전하다.

이 사례가 남기는 가장 중요한 질문은 ‘이 일을 어떻게 더 빨리 할까’가 아니다. ‘왜 이 일이 반복되고, 왜 반드시 나를 거쳐야 하며, 어느 단계까지 시스템에 맡길 수 있는가’이다.