자동화할 일을 고르는 것도 실력이다

비개발자가 넉 달에 도구 12개를 쌓으며 세운 기준

지난 글 비개발자가 400페이지 서명 검사를 자동화하며 고민한 것에서 나는 400페이지가 넘는 점검철의 서명 검사를 자동화한 이야기를 했다. 도구 하나를 어떻게 만들었는지에 대한 기록이었다. 그런데 그 도구는 내가 넉 달 동안 만든 열두 개 중 하나일 뿐이다. 이번 글은 ‘어떻게 만들었나’가 아니라, 열두 개를 앞에 두고 무엇을 먼저 만들고 무엇은 아예 만들지 않았나에 대한 이야기다.

솔직히 처음엔 나도 ‘많이 만드는 것’이 실력인 줄 알았다. 아니었다. 도구를 몇 개 만들고 나서야, 진짜 어려운 건 코드를 짜는 일이 아니라 손댈 일을 고르는 일이라는 걸 알았다. 반복 업무는 사방에 널려 있는데, 시간과 체력은 정해져 있다. 그래서 이 글은 코딩을 못 해서 자동화를 미뤄 둔 실무자, 그리고 팀에 자동화를 붙여 보려는 분들을 위한 글이다. 도구 만드는 법을 알려 주는 글은 많지만, 무엇을 만들지 고르는 기준을 실제 사례로 이야기하는 글은 드물었기 때문이다.

넉 달에 열두 개, 먼저 전체를 펼쳐 놓고 시작한다

기준 이야기를 하기 전에, 내가 실제로 무엇을 만들었는지부터 펼쳐 놓는 편이 낫겠다. 아래가 넉 달 동안 만든 열두 개다. 하나하나 자세히 볼 필요는 없다. 뒤에서 대표 몇 개만 깊이 들여다볼 것이고, 이 표로는 ‘이런 것들이 쌓였다’는 감만 잡으면 된다.

열두 개를 한 줄로 줄이면 이렇다. 검증이 셋, 수집·정산이 넷, 나머지가 입력·스케줄·변환이다. 처음부터 이렇게 나눠 만든 건 아니다. 그때그때 급한 걸 하나씩 처리했을 뿐인데, 돌아보니 이런 모양이 되어 있었다. 그런데 이 ‘돌아보니’가 중요하다. 어떤 일은 도구로 만들었고 어떤 일은 손대지 않았는데, 그 갈림길에 나름의 기준이 생겨 있었다.

무엇부터 골랐나? 나를 움직인 네 가지 기준

나는 개발 지식이 얕아서, 멋있는 걸 만들 능력이 없었다. 그래서 오히려 ‘이걸 만들 가치가 있나’를 매번 따질 수밖에 없었다. 그 과정에서 굳어진 기준이 네 가지다. 하나씩 풀어 본다.

첫째, 얼마나 자주 하는 일인가 (빈도)

아무리 귀찮아도 1년에 한 번 하는 일이라면, 도구를 만드는 시간이 더 아깝다. 반대로 매달, 매주 돌아오는 일이라면 한 번 만들어 두는 값어치가 매번 쌓인다. 나는 ‘이 일을 앞으로 몇 번이나 더 할까’를 먼저 셌다.

둘째, 한 번에 얼마나 오래 걸리나 (소요 시간)

빈도가 높아도 30초면 끝나는 일은 굳이 자동화하지 않았다. 사람이 한 번에 오래 매달려야 하는 일, 그래서 하고 나면 진이 빠지는 일을 우선했다.

셋째, 틀리면 얼마나 위험한가 (리스크)

이건 조금 결이 다르다. 자주 하지 않고 오래 걸리지 않아도, 틀리면 사고가 나는 일이 있다. 마감 서류에서 서명 하나를 놓치는 것 같은. 이런 일은 시간을 아끼려고가 아니라, 실수를 막으려고 자동화했다.

넷째, 다시 쓸 수 있는가 (재사용성)

한 번 만든 방식을 다른 일에도 붙일 수 있으면, 그 도구의 값어치는 눈에 보이는 것보다 크다. 뒤에서 이야기하겠지만, 나는 도구 하나를 만들면서 만든 ‘실행 방식’ 하나를 이후 여러 도구에 그대로 재활용했다.

이 네 가지를 하나의 체크리스트처럼 놓고 봤다. 어느 하나만 해당한다고 바로 만들지 않았고, 여러 항목에 걸리는 일부터 손댔다. 실제로는 네 가지가 다 걸리는 일은 드물었다. 그래서 완벽한 1순위를 찾기보다, 두세 개에 걸리는 일이면 일단 손대는 쪽을 택했다. 그리고 이 기준이 가장 선명하게 드러난 것이 아래 대표 사례들이다.

대표 사례로 보는 선별, 세 개만 깊이 들여다본다

열두 개를 다 설명하면 지루하고, 사실 다 볼 필요도 없다. 기준이 어떻게 작동했는지 잘 보이는 세 개만 골랐다.

사례 하나, 서명 검사: 빈도도 높고, 틀리면 위험하다

내가 가장 먼저 완성한 것이 지난 글에서 다룬 서명 누락 검사 도구다. 왜 이걸 첫 번째로 골랐는지가 이 글의 맥락에서는 더 중요하다. 이 일은 매달 돌아오고(빈도), 한 번에 30분에서 한 시간이 걸리며(시간), 하나라도 놓치면 마감이 틀어지는(리스크) 일이었다. 내 네 가지 기준 중 셋이 동시에 걸린 셈이다. 고민할 것도 없이 1순위였다.

결과는 앞 글에서 밝힌 대로다. 400페이지가 넘는 스캔본을 눈으로 넘기며 서명란을 대조하던 30분에서 한 시간짜리 일이, 1분 남짓의 자동 분석과 한 화면 확인으로 줄었다. 무엇보다 결과가 그림이 박힌 문서 한 장으로 남아, “확인했다”가 아니라 “이렇게 확인했다”는 증빙이 함께 생겼다.

사례 둘, 출근부·휴가 대조: 사람이 오래 매달리던 일

두 번째는 출근부(출퇴근 기록)와 휴가 신청서를 맞대어 보는 일이다. 매달 마감 때, 기록부에 반차나 연차로 표시된 날이 실제 휴가 신청서와 맞는지, 신청서가 빠진 건 없는지 한 장씩 대조했다. 빈도는 서명 검사와 같지만, 이건 ‘오래 걸린다’는 쪽(시간)이 더 컸다. 사람 수만큼, 날짜만큼 눈이 왔다 갔다 해야 했다.

특히 반차처럼 하루 안에서 나뉘는 휴가나, 대체휴무처럼 종류가 헷갈리는 경우에는 한 번 더 확인해야 해서 손이 더 갔다. 놓치기 쉬운 건 대단한 실수가 아니라, 기록부에는 휴가로 표시돼 있는데 정작 신청서가 빠져 있는 것 같은 작은 어긋남이었다. 이런 건 눈이 피로할수록 더 잘 지나친다.

이 도구는 두 서류를 나란히 읽어 휴가 표시를 서로 맞춰 보고, 한쪽에만 있고 다른 쪽에 없는 것만 붉게 띄운다. 눈으로 30분쯤 걸리던 대조가 1분으로 줄었다. 결과는 대시보드 형태의 리포트로 나와서, 나는 애매한 항목만 한눈에 보고 직접 확인했다. 여기서도 원칙은 서명 검사와 같았다. 최종 판단은 사람이 한다. 도구는 어긋난 지점만 찾아 눈앞에 모아 줄 뿐이다.

실제로 돌려 보니, 사람이 훑을 때는 지나치기 쉬운 한두 건이 리포트 맨 위에 붉게 떠올랐다. 시간을 줄인 것보다, ‘빠진 것을 빠짐없이 봤다’는 확신이 생긴 게 나에게는 더 컸다.

사례 셋, 예산 이월: 한 번 만든 방식을 다시 쓰다

세 번째는 조금 다른 이유로 골랐다. 예산 이월 도구는 월 이익금을 다음 예산으로 넘기는 계산을 대신하는데, 이 일 자체의 빈도나 위험보다 재사용성 때문에 이야기할 값어치가 있다.

앞서 만든 도구들에서 나는 ‘점검철 파일을 아이콘 위에 끌어다 놓으면 실행되는’ 방식을 만들어 두었다. 명령어를 칠 줄 몰라도 쓸 수 있게 하려던 것이었다. 그런데 이 ‘끌어다 놓기’ 실행 방식은 서명 검사에만 쓰이는 게 아니었다. 블로그용 이미지 변환에도, 예산 이월에도 그대로 붙었다. 도구마다 하는 일은 달라도, 사람이 쓰는 입구는 똑같이 만든 것이다. 하나를 잘 만들어 두니, 다음 도구는 그 위에 얹기만 하면 됐다.

이 방식이 특히 좋았던 건, 나 말고 다른 사람도 쓸 수 있다는 점이었다. 사용법이 ‘파일을 아이콘에 끌어다 놓는다’ 한 줄이면, 길게 설명하지 않아도 옆자리 동료가 바로 따라 했다. 도구를 나 혼자 쓰는 것과 팀이 함께 쓰는 것은 값어치가 다르다. 재사용성은 나중에 시간을 아껴 주는 정도가 아니라, 도구가 나 한 사람을 넘어서게 해 주는 성질이었다.

만들지 않기로 한 것들: 고르는 눈의 반대편

‘무엇을 자동화할까’만큼 중요한 게 ‘무엇은 자동화하지 않을까’였다. 몇 가지는 만들 수 있었는데도 일부러 손대지 않았다.

하나는 어쩌다 한 번 하는 일이다. 1년에 한두 번 하는 정리 작업은, 도구를 만들고 관리하는 품이 그 일을 손으로 하는 것보다 컸다. 만들고 싶은 마음은 굴뚝같았지만, 그건 자동화가 아니라 취미가 될 참이었다.

다른 하나는 틀렸을 때 사람이 책임져야 하는 판단이다. 예를 들어 애매한 특이사항을 ‘문제없음’과 ‘조치 필요’ 중 어디로 볼지 같은 것. 이건 도구가 대신 단정하게 두면 오히려 위험하다. 그래서 이런 일은 도구가 자료를 모아 주는 데까지만 맡기고, 판단 자체는 넘기지 않았다. 앞 글에서 말한 ‘사람 먼저, 도구 나중’이 여기서도 그대로 적용됐다.

자동화를 하다 보면 ‘이것도 되네’ 하는 욕심이 붙는다. 그 욕심을 어디서 멈출지 정해 두는 것도 도구를 만드는 일의 한 부분이었다. 안 만들기로 정하고 나면, 남은 시간을 진짜 손댈 값어치가 있는 일에 쓸 수 있었다.

이 두 가지를 걸러 내는 것만으로도, 나는 헛심을 꽤 아꼈다. 고르는 눈은 결국 ‘만들 것’과 ‘만들지 않을 것’을 함께 보는 눈이었다.

하나가 다음을 부른다, 열두 개가 쌓인 방식

돌아보면 열두 개는 계획해서 나온 숫자가 아니다. 첫 번째 도구가 생각보다 잘 돌아가고, 그게 눈에 보이는 결과로 남으니, 자연스럽게 ‘그럼 저것도 되지 않을까’ 하는 생각이 따라왔다. 하나를 만들면 다음이 보였고, 앞서 만든 조각(끌어다 놓기 실행 방식 같은)을 다시 쓰니 두 번째, 세 번째는 점점 빨라졌다.

열두 개째에 이르러서는, 새로운 반복 업무를 만나면 ‘이건 며칠이면 붙이겠다’는 감이 먼저 왔다. 그 감이 생긴 것이 도구 개수보다 더 남는 것이었다. 처음엔 도구를 하나 만드는 게 목표였는데, 어느새 ‘어떤 일을 도구로 바꿀 수 있는가’를 보는 눈이 생겨 있었다.

그래서 지금 반복 업무에 지쳐 있는 분께 권하고 싶은 건 ‘열두 개를 만들라’가 아니다. 딱 하나만 골라 보라는 것이다. 앞의 네 기준으로 오늘 한 일을 훑어보면, 유난히 자주·오래·위험한 일 하나가 반드시 눈에 걸린다. 그 하나부터다. 나도 그 하나에서 시작했다.

마치며: 코딩보다 먼저 필요한 건 고르는 눈

나는 개발자가 아니다. 넉 달 동안 도구 열두 개를 만들었지만, 그 사이 내 코딩 실력이 는 것 같지는 않다. 대신 분명히 는 것이 하나 있다. 무엇을 자동화하고 무엇은 두어야 하는지 고르는 눈이다.

자동화는 대단한 기술에서 시작되지 않았다. 매달 나를 지치게 하던 일 하나를 정확히 짚는 데서 시작됐다. 자주 하는가, 오래 걸리는가, 틀리면 위험한가, 다시 쓸 수 있는가. 이 네 가지만 스스로에게 물어도, 어디부터 손댈지가 보인다. 구현은 그다음 문제고, 그건 요즘 도구의 도움을 받으면 된다.

혹시 “나는 코딩을 못 하니까”라며 미뤄 둔 반복 업무가 있다면, 만드는 법을 배우기 전에 고르는 연습부터 해 보시길 권한다. 가장 자주, 가장 오래, 가장 위험한 일 하나. 거기서부터 생각보다 많은 것이 바뀐다.

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

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