충원이 거절되자 "이거 한번 해보자"로 시작한 자동화

인력 대신 도구를 붙잡은 사업관리의 3달

앞서 두 편의 글 ‘비개발자가 400페이지 서명 검사를 자동화하며 고민한 것’, ‘자동화할 일을 고르는 것도 실력이다’에서 나는 도구에 관한 이야기를 했다. 첫 번째 글은 400페이지짜리 점검철의 서명 검사를 자동화한 제작기였고, 두 번째 글은 넉 달 동안 만든 열두 개를 놓고, 무엇을 자동화하고 무엇은 하지 않았는지에 대한 기준이었다. 어떻게 만들었나, 그리고 무엇을 고를까. 두 편 모두 도구가 주인공이었다.

이번 글은 그보다 더 앞의 이야기다. 도구가 아니라 사람 이야기이고, 정확히는 “내가 왜 그 자리까지 몰렸는가”에 대한 기록이다. 코딩이 본업이 아닌 사업관리 담당자가 어느 날 갑자기 자동화에 관심이 생겨서 시작한 게 아니었다. 정확히 말하자면 나는 떠밀렸다. 그래서 이 이야기의 대상은 분명하다. 지금 반복 업무에 짓눌려 있으면서도, “나는 코딩을 못 하니까”라며 미뤄 두고 있는 분들이다. 

이미 도구를 만드는 법이나 고르는 법을 알려 주는 글은 많다. 그런데 정작 그 앞에 있는 질문, 어쩌다 거기까지 갔는가를 솔직하게 적은 글은 드물다. 그 자리에 서 본 사람만 쓸 수 있는 이야기라고 생각해서, 이번 글에서 풀어보고자 한다.

업무가 두 배가 된 해

작년까지 우리 팀은 인프라 운영 사업만 수행했다. 시스템이 멈추지 않게 지키고, 장애가 나면 복구하고, 월마다 운영 실적을 정리해 보고하는 일이다. 익숙했고, 리듬이 있었다.

올해는 여기에 유지관리 사업이 더해졌다. 운영을 계속하면서 유지관리까지 병행하게 된 것이다. 나만 그런 게 아니었다. 팀원 전체가 기존 운영 업무에 더해 유지관리까지 맡게 됐다. 사람은 그대로인데 사업이 하나 더 늘었으니, 늘어난 몫은 고스란히 각자에게 나뉘었다.

숫자로 딱 떨어지게 말하긴 어렵지만, 체감으로는 해야 할 일이 몇 배로 늘었다. 더 정확히 표현하자면 일의 양보다 일의 종류가 늘어난 것이 힘들었다. 하던 일을 더 많이 하는 것과, 안 해 본 일이 새로 들어오는 것은 완전히 다른 피로다.

처음 하는 일에는 체계부터 없었다

유지관리 업무는 나에게 처음이었다. 그리고 처음 하는 일에는 늘 같은 문제가 따라온다. 할 일이 어려운 게 아니라, 할 일을 담을 그릇이 없다는 것.

표준이 없는 상태에서 시작하기

유지관리에 필요한 산출물 표준이 정립되어 있지 않았다. 어떤 문서를 어떤 형식으로 받아야 하는지부터 정해야 했다. 그래서 표준 양식을 만들어 유지관리 업체 전체에 미리 배포했다.

그런데도 매달 같은 오류가 반복됐다. 배포한 양식이 현장 점검자에게까지 제대로 전달되지 않은 듯했다. 반복되는 유형은 대체로 정해져 있었다.

• 작년 양식을 그대로 가져와 작성한 경우
• 점검은 했는데 작업자 서명이 빠진 경우
• 특이사항을 모호하게 적은 경우

마지막 유형이 특히 손이 많이 갔다. “추후 조치예정”이라고만 적혀 있으면 그건 아무것도 정해지지 않았다는 뜻이다. 그래서 “2주 내 조치예정”처럼 정확한 완료일자를 명기하도록 매번 되돌려 보냈다. 점검이 끝난 일지를 최종적으로 확인하는 일은 생각보다 큰 부담이었다.

1) 흐름을 끊는 병목, 파일 반출입

체계를 잡는 것과는 결이 다른 문제도 있었다. 보안상 파일 반출입은 사업단과 고객 사이의 단일 경로로만 처리해야 했다. 다시 말해 그 창구가 나였다. 문제는 요청이 예고 없이 온다는 점이었다. 내 일을 하고 있는 중간에 반출입 요청이 들어오면 하던 작업을 멈추고 처리해야 했다. 한 건 한 건은 몇 분이면 끝난다. 그런데 끊긴 흐름을 다시 잇는 비용은 그 몇 분보다 훨씬 컸다. 이 손실이 하루 종일 쌓였다.

이 문제는 결국 구조를 바꿔서 풀었다. 내부 프로젝트 관리 시스템에 있는 게시판 기능에 반출입 요청 창구를 만들고, 요청이 나를 거치지 않고 고객에게 바로 가도록 흐름을 다시 짰다.

반입부터 보겠다. 외부에서 온 메일을 담당 고객에게 보내 두고, 요청자가 내부 시스템에 해당 건의 반입을 직접 요청한다. 반출도 같은 방식이다. 요청 글을 내부 시스템에 올려 두면 고객이 확인하고 외부로 반출해 준다.

바뀐 것은 처리 건수가 아니라 경로였다. 예전에는 모든 요청이 나를 한 번 거쳐야 다음으로 넘어갔다. 지금은 요청자와 고객이 시스템 위에서 직접 주고받고, 나는 그 기록을 확인하면 된다. 내 하루를 끊던 지점이 사라진 것이다. 이 경험이 나중에 자동화를 생각할 때 기준이 되기도 했다. 일을 더 빨리 하는 것보다, 나를 거치지 않아도 되게 만드는 편이 낫다.

2) 결국 내가 만든 관리 흐름

그래서 점검 관리 흐름을 직접 만들었다. 순서는 단순하다. 팀원이 점검 일정을 잡으면, 작업일정계획표를 보고 엑셀에 번호를 매겨 업체와 담당 파트, 작업자 정보를 정리한다. 한 달 치 계획이 끝나면 작업일지를 고객에게 전달해 전체 검토와 서명을 받고, 그것을 스캔해 검수 문서로 보고한 뒤 업체별로 스캔본을 다시 전달한다.

돌아보면 이 흐름 자체가 대단히 어려운 일은 아니었다. 정리하고 나면 순서대로 하면 되는 일이다. 문제는 따로 있었다. 하나씩 하면 어렵지 않은 일도, 한꺼번에 몰리면 사람이 무너진다.

석 달, 퇴근 후에야 일이 시작됐다

그 시기를 한 문장으로 말하면 이렇다. 낮에는 내 일을 하지 못했다. 일이 복합적으로 몰리다 보니 집중이 흩어졌다. 게다가 여러 곳에서 동시에 나를 찾았다. 반출입 요청, 업체 문의, 팀원 확인, 고객 요청이 순서를 지키지 않고 들어왔다. 하나에 손을 대면 다른 하나가 밀렸다.

그래서 나는 퇴근 시간이 지나기를 기다리게 됐다. 사람들이 빠지고 연락이 잦아들면, 그제야 자리에 앉아 그날 처리했어야 할 일들을 하나씩 쳐냈다. 조용한 사무실에서 혼자 노트북을 보고 있는 시간이 하루 중 유일하게 일이 되는 시간이었다.

그렇게 약 석 달을 버텼다. 버틴다는 말이 정확하다. 그때 나는 문제를 해결하고 있던 게 아니라 견디고 있었다. 매일 밀린 것을 따라잡을 뿐, 구조는 그대로였다. 다음 달에도 같은 일이 같은 방식으로 돌아올 것을 알면서 견뎠다.

사람을 요청했지만, 받아들여지지 않았다

석 달쯤 지나 나는 결론을 냈다. 이건 개인의 노력으로 메울 문제가 아니라고 판단했다. 그래서 업무보조 한 명을 충원해 달라고 요청했다. 가장 상식적인 해법이라고 생각했다. 일이 늘었으면 사람이 늘어야 한다. 그런데 요청은 받아들여지지 않았다. 솔직히 말하면 그때 좌절했다. 방법을 몰라서가 아니라, 방법을 알고 있는데 그 방법을 쓸 수 없다는 사실이 사람을 지치게 만든다. 사람이 안 되면 남는 선택지는 하나뿐이었다. 일하는 방식 자체를 바꾸는 것. 다만 그때는 그게 무엇인지 몰랐다.

“이거 한번 해보자”

그 무렵 본사 행사에 참석했는데, 거기서 클로드를 활용한 자동화 시연을 보게 됐다. 지금 돌아봐도 신기한 건, 그 시연이 대단히 어려운 기술을 보여주지는 않았다는 점이다. 그런데 화면을 보는 순간 머릿속에 든 생각은 분명했다. 이거다.

그 자리에는 사업관리 후배 직원이 함께 있었다. 우리는 시연을 보면서 서로에게 말했다. “이거 한번 해보자.”라는 문장이 이 글의 제목에 들어간 이유가 있다. 나중에 도구를 열두 개까지 만들게 되지만, 그 출발점은 대단한 결심이나 계획이 아니었다. 옆자리 동료와 나눈 한마디였다. 시작이 혼자가 아니었다는 것이 지금 생각해도 큰 차이를 만들었다.

명령어 한 줄, 그리고 첫 화면

돌아와서 실제로 설치를 해 봤다. 여기서부터는 비개발자가 어떻게 첫발을 뗐는지에 대한 이야기라, 따라 해 보실 분들을 위해 최대한 그대로 적는다.

나는 먼저 다른 인공지능에게 설치 방법을 물었다. 평소 쓰던 생성형 인공지능 서비스에 “클로드 코드 설치 방법 알려줘”라고 입력했더니, 운영체제별로 명령어 한 줄씩을 정리해 알려 줬다. 별도의 개발 환경을 갖출 필요 없이 명령 프롬프트에 그 명령어를 복사해 붙여넣기만 하면 되는 방식이었다.

그래서 그대로 했다. 복사하고, 붙여넣고, 실행했다. 설치는 몇 분 만에 끝났다.

실행하자 화면에 인사말이 떴다. “조차장님, 안녕하세요.”

별것 아닌 문구인데, 그게 제일 먼저 눈에 들어왔다. 도구를 켰다기보다 누군가에게 말을 건 것 같은 기분이었다. 그리고 화면 자체가 낯설지 않았다. 평소 쓰던 인공지능 서비스와 크게 다르지 않은 구성이라, 무엇을 어디에 입력해야 하는지 헤매지 않았다. 비개발자에게는 이 ‘낯설지 않음’이 생각보다 중요하다. 진입 장벽은 대체로 기능이 아니라 낯설다는 느낌에서 생기기 때문이다.

이후에는 유튜브를 찾아봤다. 처음 설정할 때 알아두면 좋은 것들, 이렇게 쓰면 편하다는 사용법을 영상으로 보면서 하나씩 따라 했다. 배우는 방식도 특별할 게 없었다. 남들이 해 둔 것을 보고 그대로 해 보는 것부터였다.

자신감은 결과물이 아니라 과정에서 왔다

첫 결과물이 완성됐을 때의 기분은 기억에 남는다. 그동안 머릿속으로 고민만 하다가 끝났던 것들이 눈앞에 형태로 보이기 시작했다. 그러자 뭔지 모를 자신감이 생겼다. 이걸 할 수 있으면 저것도 되겠다는 생각이 자연스럽게 따라왔다. 그런데 시간이 지나고 나서 돌아보니, 나를 바꾼 건 결과물 자체가 아니었다.

정말 좋았던 것은 거기까지 가는 과정이었다. 무엇보다 대화하듯 주고받으며 만들었다. 내가 문제와 제약을 설명하면 방법을 제안받고, 실제로 돌려 본 뒤 왜 안 됐는지를 다시 설명하는 식이었다. 지시하고 받는 게 아니라 오가는 흐름이었다.

내가 생각하지 못한 선택지를 제안받은 것도 컸다. 나는 아는 만큼만 질문할 수 있는데, 답이 내가 아는 범위 밖에서 오는 경우가 많았다. 혼자 고민했다면 떠올리지 못했을 방향이었다. 그리고 그 선택지에 나오는 용어가 어려워서 다시 물으면 비유를 들어 쉽게 풀어 줬다. 이게 비개발자에게는 결정적이다. 모르는 단어 앞에서 멈추지 않아도 된다는 것, 물어봐도 창피하지 않다는 것. 나는 이 지점에서 계속할 수 있겠다고 느꼈다.

자신감은 완성된 결과물이 아니라, 대화하는 과정에서 왔다. 결과물은 증거였을 뿐이다.

마치며: 자동화는 여유가 아니라 한계에서 시작된다

이 글을 쓰면서 다시 확인한 것이 있다. 나는 자동화에 관심이 많아서 시작한 사람이 아니다. 더 이상 버틸 수 없어서 시작했다. 업무가 두 배가 됐고, 체계는 없었고, 사람은 늘지 않았다. 남은 선택지가 그것뿐이었다.

그래서 혹시 지금 비슷한 자리에 계신 분이 있다면, 시작의 조건을 오해하지 않으셨으면 한다. 여유가 생기면 배워서 해 보겠다고 미루기 쉬운데, 내 경우는 정반대였다. 여유가 없었기 때문에 시작했다. 그리고 그 시작은 거창하지 않았다. 시연 하나를 보고 옆자리 동료와 “이거 한번 해보자”고 말한 것, 명령어 한 줄을 복사해 붙여넣은 것이 전부였다.

그때의 나에게 지금 한마디를 건넬 수 있다면 이렇게 말하고 싶다. 이 또한 지나갈 것이고, 언젠가는 너의 자산이 될 거라고. 실제로 그 석 달은 지금 이 글의 재료가 됐다. 지금 반복 업무에 눌려 있다면, 완벽한 준비를 기다리지 않으셔도 된다. 가장 귀찮은 일 하나를 떠올리고, 옆자리 동료에게 한 번 말해 보시면 좋겠다. “이거 한번 해보자.” 나도 딱 그 한마디에서 시작했다.

이 글이 마음에 드셨다면, 작가 페이지에서 알림 설정과 좋아요를 부탁드립니다.

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

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