무엇을 자동화할지 고르는 법 — 비개발자를 위한 네 가지 질문
대상: 코드를 모르는 일반 성도·목회자·사무직 등 비개발자. AI로 “무엇을” 자동화할지 고르는 판단 기준을 다룹니다. “어떻게 만드는가”는 다루지 않습니다.
들어가며 — 우리는 늘 “어떻게”만 물었다
지금까지 교육 시리즈에서 우리는 클로드에게 무엇을 시키는 법, 프로젝트를 꾸리는 법, 여러 단계를 엮어 자동화를 설계하는 법을 배웠습니다. 그런데 그 모든 이야기는 하나의 전제 위에 서 있었습니다. “자동화할 일이 이미 정해져 있다”는 전제입니다.
실제로는 그렇지 않습니다. 반복 업무는 늘 여러 개가 동시에 밀려 있고, 우리에게 주어진 시간과 체력은 하루치뿐입니다. 그러니 진짜 첫 질문은 “어떻게 만들까”가 아니라 “이 중 무엇부터 손댈까”입니다. 코드를 한 줄도 몰라도 상관없는 질문입니다. 오히려 이 질문 앞에서는 코딩 실력보다 판단하는 눈이 더 중요합니다.
이 글은 개발자가 아닌 한 직장인이 넉 달 동안 자동화 도구 열두 개를 만들며 세운 기준을 다룬 요즘IT 기사 「자동화할 일을 고르는 것도 실력이다」(2026-08-10, 아이엠조차장)를 소재로 삼습니다. 저자는 개발자가 아닙니다. 그런데도 코딩 실력이 늘어난 것 같지는 않다고 스스로 말합니다. 대신 분명히 늘어난 것이 하나 있다고 합니다. “무엇을 자동화하고 무엇은 두어야 하는지 고르는 눈”입니다. 우리 목회·교회 행정 현장에도 그대로 적용되는 이야기입니다.
지금까지 우리 교육 시리즈가 다뤄 온 “어떻게 만드는가”는 AI 도구가 좋아질수록 점점 더 쉬워집니다. 몇 년 전이라면 며칠씩 걸렸을 자동화가 지금은 대화 몇 번으로 끝나는 경우도 흔합니다. 그런데 “무엇을 만들 것인가”는 도구가 아무리 좋아져도 저절로 답이 나오지 않습니다. 이 질문은 결국 그 일을 매일 하는 사람만이 답할 수 있는 질문이기 때문입니다. 만드는 능력이 흔해질수록, 무엇을 만들지 고르는 눈의 값어치는 오히려 더 커집니다.
1. “많이 만드는 것”이 실력이 아니었다
저자는 처음엔 많이 만드는 것이 실력이라고 생각했다고 고백합니다. 그런데 실제로 넉 달을 지나 보니, 가장 어려운 일은 코딩이 아니라 “손댈 일을 고르는 일”이었다고 합니다. 반복 업무는 사방에 널려 있지만 시간과 체력은 정해져 있기 때문입니다.
저자가 넉 달 동안 만든 열두 개 도구는 이렇게 나뉩니다.
- 입력·등록: 유틸 등록, 신규 인력 작성 대기
- 수집·정산: 매입 대기목록 수집, 시스템 목록 수집
- 스케줄: 휴가·당직·관제 근무표, 엑셀 월 스케줄 생성
- 검증: 폐쇄망 오타 검사, 서명 누락 검사, 출근부·휴가 대조
- 변환: 산출물 PDF, 블로그 이미지 변환
- 정산: 예산 이월, 월 이익금 계산
중요한 건 이 목록을 처음부터 계획해서 짠 게 아니라는 점입니다. 그때그때 급한 일을 처리하다 보니 돌아보니 이런 모양이 되어 있었다고 저자는 씁니다. 이 “돌아보니”라는 표현이 핵심입니다. 어떤 일은 도구로 만들었고 어떤 일은 손대지 않았는데, 그 갈림길에는 저자도 미처 의식하지 못한 나름의 기준이 이미 작동하고 있었다는 뜻입니다. 이 글은 바로 그 기준을 뒤늦게 말로 꺼내 본 기록입니다.
2. 나를 움직인 네 가지 기준
개발 지식이 얕았던 저자는 도구 하나를 만들 때마다 “이걸 만들 가치가 있나”를 매번 따질 수밖에 없었습니다. 그 과정을 반복하면서 굳어진 기준이 네 가지입니다.
첫째, 얼마나 자주 하는 일인가 (빈도)
아무리 귀찮아도 1년에 한 번 하는 일이라면 도구를 만드는 시간이 오히려 더 아깝습니다. 반대로 매달, 매주 돌아오는 일이라면 한 번 만들어 두는 값어치가 매번 쌓입니다. 저자는 “이 일을 앞으로 몇 번이나 더 할까”를 먼저 세었다고 말합니다.
교회 행정으로 옮겨 보면, 매주 반복되는 주보 명단 정리나 매달 돌아오는 헌금 집계는 이 기준에서 상위에 놓입니다. 반면 몇 년에 한 번 있는 행사 기획서 작성은 아무리 손이 많이 가도 이 기준만으로는 자동화 우선순위가 낮습니다.
둘째, 한 번에 얼마나 오래 걸리나 (소요 시간)
빈도가 높아도 30초면 끝나는 일은 저자는 굳이 자동화하지 않았다고 합니다. 사람이 한 번에 오래 매달려야 하는 일, 그래서 하고 나면 진이 빠지는 일을 우선했습니다. 자동화의 진짜 보상은 “짧은 일을 없애는 것”이 아니라 “긴 시간을 짧게 만드는 것”에서 나온다는 뜻입니다.
셋째, 틀리면 얼마나 위험한가 (리스크)
자주 하지 않고 오래 걸리지 않아도 “틀리면 사고가 나는 일”이 있습니다. 저자는 마감 서류에서 서명 하나를 놓치는 것 같은 일을 예로 듭니다. 이런 일은 시간을 아끼려고가 아니라 실수를 막으려고 자동화했다고 명확히 구분합니다. 교회 현장이라면 세례 명부, 헌금 영수증, 공문서 발송처럼 한 번의 실수가 신뢰를 흔드는 일들이 여기에 해당할 것입니다.
다만 여기서 반드시 먼저 정하고 넘어가야 할 선이 하나 있습니다. 교인의 민감자료 — 개인정보(이름·연락처·주소·주민번호), 헌금 내역, 심방·상담 기록 — 는 외부 AI 서비스에 입력하지 않습니다. 우리가 쓰는 대화형 AI는 대부분 외부 사업자의 서버로 내용을 보내는 구조이고, 한 번 보낸 자료는 회수할 수 없습니다. 이런 업무를 자동화할 때는 실제 자료 대신 가상의 예시 데이터로 방법과 서식만 만들고, 실제 교인 자료를 넣는 마지막 단계는 교회 안에서 사람이 직접 합니다. 자동화의 값어치보다 성도의 신뢰가 먼저입니다.
넷째, 다시 쓸 수 있는가 (재사용성)
한 번 만든 방식을 다른 일에도 붙일 수 있으면 그 도구의 값어치는 눈에 보이는 것보다 큽니다. 도구 하나를 만들면서 다듬은 “실행 방식” 하나를 이후 여러 도구에 그대로 재활용했다고 저자는 씁니다.
저자는 이 네 가지를 체크리스트처럼 놓고 봤다고 설명합니다. 어느 하나만 해당한다고 바로 만들지는 않았고, 여러 항목에 동시에 걸리는 일부터 손댔습니다. 실제로는 네 가지가 다 걸리는 일은 드물었기 때문에, 완벽한 1순위를 찾기보다 두세 개에 걸리는 일이면 일단 손대는 쪽을 택했다고 합니다. 완벽한 기준을 세우려다 아무것도 시작하지 못하는 것보다, “여러 개에 걸리면 일단 착수”라는 실용적인 문턱을 둔 셈입니다.
3. 대표 사례로 보는 선별 — 세 가지만 깊이 들여다본다
기준을 말로만 늘어놓으면 추상적으로 들리기 쉽습니다. 저자는 실제로 만든 열두 개 중 세 개를 골라, 각 도구가 왜 그 순서로 만들어졌는지 보여줍니다.
사례 하나 — 서명 검사: 빈도도 높고, 틀리면 위험하다
저자가 가장 먼저 완성한 것은 서명 누락 검사 도구입니다. 이 일은 “매달 돌아오고(빈도), 한 번에 30분에서 한 시간이 걸리며(시간), 하나라도 놓치면 마감이 틀어지는(리스크)” 일이었습니다. 네 가지 기준 중 셋이 동시에 걸린 것입니다.
결과적으로 400페이지가 넘는 스캔본을 눈으로 넘기며 서명란을 대조하던 30분에서 한 시간짜리 일이 “1분 남짓의 자동 분석과 한 화면 확인”으로 줄었습니다. 무엇보다 저자가 강조하는 대목은 결과가 그림이 박힌 문서 한 장으로 남아 “확인했다”가 아니라 “이렇게 확인했다”는 증빙이 함께 생겼다는 점입니다. 시간을 아낀 것 이상으로, 확인의 근거가 눈에 보이는 형태로 남았다는 이야기입니다.
사례 둘 — 출근부·휴가 대조: 사람이 오래 매달리던 일
두 번째는 출근부와 휴가 신청서를 맞대어 보는 일입니다. 매달 마감 때 기록부에 반차나 연차로 표시된 날이 실제 휴가 신청서와 맞는지, 신청서가 빠진 건 없는지 한 장씩 대조했습니다. 빈도는 서명 검사와 같지만, 이 도구는 “한 번에 오래 걸린다”는 시간 기준 쪽이 더 크게 작용했습니다.
특히 반차처럼 하루 안에서 나뉘는 휴가나 대체휴무처럼 종류가 헷갈리는 경우에는 한 번 더 확인해야 했다고 저자는 씁니다. 놓치기 쉬운 것은 기록부에는 휴가로 표시돼 있는데 정작 신청서가 빠져 있는 것 같은 작은 어긋남이었습니다. 눈이 피로할수록 더 잘 지나치는 지점입니다.
이 도구는 두 서류를 나란히 읽어 휴가 표시를 서로 맞춰 보고, 한쪽에만 있고 다른 쪽에 없는 것만 붉게 띄웁니다. 눈으로 30분쯤 걸리던 대조가 1분으로 줄었고, 결과는 대시보드 형태의 리포트로 나와 애매한 항목만 한눈에 보고 직접 확인했다고 합니다.
여기서도 원칙은 서명 검사와 같습니다. “최종 판단은 사람이 한다.” 도구는 어긋난 지점만 찾아 눈앞에 모아 줄 뿐, 그것이 문제인지 아닌지는 저자가 직접 판단했습니다. 실제로 돌려 보니 사람이 훑을 때는 지나치기 쉬운 한두 건이 리포트 맨 위에 붉게 떠올랐다고 합니다. 저자는 시간을 줄인 것보다 “빠진 것을 빠짐없이 봤다”는 확신이 생긴 것이 더 컸다고 말합니다.
사례 셋 — 예산 이월: 한 번 만든 방식을 다시 쓰다
세 번째는 조금 다른 이유로 골랐습니다. 예산 이월 도구는 월 이익금을 다음 예산으로 넘기는 계산을 대신하는데, 이 일 자체의 빈도나 위험보다 “재사용성” 때문에 이야기할 값어치가 있다고 저자는 설명합니다.
앞서 만든 도구들에서 저자는 ‘점검철 파일을 아이콘 위에 끌어다 놓으면 실행되는’ 방식을 만들어 두었습니다. 명령어를 칠 줄 몰라도 쓸 수 있게 하려던 궁리였습니다. 그런데 이 “끌어다 놓기” 실행 방식은 서명 검사에만 쓰이지 않았습니다. 블로그용 이미지 변환에도, 예산 이월에도 그대로 붙었습니다. 도구마다 하는 일은 달라도 “사람이 쓰는 입구는 똑같이” 만든 것입니다.
이 방식이 특히 좋았던 이유는 저자 본인 말고 다른 사람도 쓸 수 있었다는 점입니다. 사용법이 “파일을 아이콘에 끌어다 놓는다” 한 줄이면, 길게 설명하지 않아도 옆자리 동료가 바로 따라 했습니다. 도구를 나 혼자 쓰는 것과 팀이 함께 쓰는 것은 값어치가 다릅니다. 저자는 재사용성이 나중에 시간을 아껴 주는 정도가 아니라, 도구가 나 한 사람을 넘어서게 해 주는 성질이었다고 정리합니다.
4. 만들지 않기로 한 것들 — 고르는 눈의 반대편
“무엇을 자동화할까”만큼 중요한 것이 “무엇은 자동화하지 않을까”였다고 저자는 말합니다. 몇 가지는 만들 수 있었는데도 저자는 일부러 손대지 않았습니다.
하나는 **“어쩌다 한 번 하는 일”**입니다. 1년에 한두 번 하는 정리 작업은 도구를 만들고 관리하는 품이 그 일을 손으로 하는 것보다 컸습니다. 저자는 만들고 싶은 마음은 굴뚝같았지만 그건 자동화가 아니라 취미가 될 참이었다고 솔직하게 씁니다.
다른 하나는 **“틀렸을 때 사람이 책임져야 하는 판단”**입니다. 예를 들어 애매한 특이사항을 ’문제없음’과 ‘조치 필요’ 중 어디로 볼지 같은 것인데, 도구가 대신 단정하게 두면 오히려 위험합니다. 그래서 이런 일은 도구가 자료를 모아 주는 데까지만 맡기고, 판단 자체는 넘기지 않았다고 저자는 분명히 선을 긋습니다.
자동화를 하다 보면 “이것도 되네” 하는 욕심이 자연히 붙습니다. 그 욕심을 어디서 멈출지 정해 두는 것도 도구를 만드는 일의 한 부분이었다고 저자는 말합니다. 안 만들기로 정하고 나면 남은 시간을 진짜 손댈 값어치가 있는 일에 쓸 수 있었습니다. 이 두 가지를 걸러 내는 것만으로도 헛심을 꽤 아꼈다고 합니다. 고르는 눈은 결국 “만들 것”과 “만들지 않을 것”을 함께 보는 눈이었던 셈입니다.
이 대목은 우리 현장에도 그대로 옮겨집니다. “심방 중 이 성도의 상태를 어떻게 볼 것인가”나 “이 민원을 어느 선에서 처리할 것인가” 같은 판단은, 자료를 정리해 주는 도구는 만들 수 있어도 결정 자체를 도구에 넘겨서는 안 되는 영역입니다.
5. 하나가 다음을 부른다 — 열두 개가 쌓인 방식
돌아보면 열두 개는 계획해서 나온 숫자가 아니라고 저자는 씁니다. 첫 번째 도구가 생각보다 잘 돌아가고, 그게 눈에 보이는 결과로 남으니 자연스럽게 “그럼 저것도 되지 않을까” 하는 생각이 따라왔습니다. 하나를 만들면 다음이 보였고, 앞서 만든 조각(앞서 말한 “끌어다 놓기” 실행 방식 같은)을 다시 쓰니 두 번째, 세 번째는 점점 빨라졌습니다.
열두 번째에 이르러서는 새로운 반복 업무를 만나면 “이건 며칠이면 붙이겠다”는 감이 먼저 왔다고 저자는 말합니다. 그 감이 생긴 것이 도구 개수보다 더 남는 것이었다고 스스로 평가합니다. 처음엔 도구를 하나 만드는 게 목표였는데, 어느새 “어떤 일을 도구로 바꿀 수 있는가”를 보는 눈이 생겨 있었던 것입니다.
그래서 지금 반복 업무에 지쳐 있는 분께 저자가 권하고 싶은 것은 “열두 개를 만들라”가 아닙니다. “딱 하나만 골라 보라”는 것입니다. 앞의 네 기준으로 오늘 한 일을 훑어보면 유난히 자주·오래·위험한 일 하나가 반드시 눈에 걸립니다. 그 하나부터입니다. 저자도 그 하나에서 시작했습니다.
6. 네 가지 기준을 우리 현장에 옮겨보기
원문은 회사 사무직 현장의 이야기이지만, 네 가지 기준 자체는 업종을 가리지 않습니다. 교회 행정·목회 현장에서 흔한 반복 업무를 같은 틀로 한번 짚어 보겠습니다.
| 업무 | 빈도 | 소요 시간 | 위험 | 재사용성 | 판단 |
|---|---|---|---|---|---|
| 주보 명단·순서지 정리 | 매주 | 매번 30분~1시간 | 낮음(오탈자 정도) | 중간 | 빈도·시간 두 개가 걸린다 → 우선 후보 |
| 헌금 집계·영수증 발급 | 매달 | 짧으면 수십 분 | 높음(금액 오류는 신뢰 문제) | 낮음 | 빈도·위험 두 개가 걸린다 → 서명 검사 사례와 같은 유형 |
| 심방 대상자 명단·상태 정리 | 수시 | 짧음 | 판단이 사람 몫 | 중간 | 자료 정리는 자동화, 최종 판단은 사람 — 4절의 “만들지 않을 것”에 해당 |
| 연 1회 행사 기획서 | 연 1회 | 길다 | 낮음~중간 | 낮음 | 네 기준 모두 약함 → 저자라면 손대지 않았을 일 |
이렇게 표로 펼쳐 놓고 보면, 저자가 말한 “여러 항목에 걸리는 일부터 손댄다”는 원칙이 그대로 적용됩니다. 단, 표의 헌금·심방 항목은 앞서 3절에서 그은 선을 그대로 지킵니다. 집계 서식과 정리 방식을 만드는 데까지만 AI를 쓰고, 실제 헌금 내역이나 교인 명단·상담 기록을 외부 AI에 붙여 넣지 않습니다. 자동화 후보로 오른다는 말이 곧 그 자료를 외부에 보내도 된다는 뜻은 아닙니다.
위 예시에서는 주보 명단 정리와 헌금 집계가 상위 후보로 떠오르고, 연 1회 행사 기획서는 아무리 손이 많이 가더라도 뒤로 밀립니다. 심방 대상자 정리처럼 최종 판단이 사람 몫인 일은, 자료를 모아 정리하는 부분까지만 AI에게 맡기고 “이 성도를 어떻게 볼 것인가” 하는 판단 자체는 넘기지 않는 것이 4절에서 저자가 그은 선과 같은 방향입니다.
중요한 것은 이 표가 정답이 아니라는 점입니다. 교회마다, 부서마다 실제 빈도와 소요 시간, 위험의 크기는 다릅니다. 표는 예시일 뿐이고, 진짜 작업은 각자 자신의 반복 업무를 직접 이 틀에 넣어 보는 것입니다. 그것이 바로 다음 실습입니다.
7. 오늘의 실습 ✍️
코드를 몰라도 오늘 바로 해 볼 수 있는 연습입니다.
미션 1 — 목록부터 펼치기: 최근 한 달 동안 반복했던 업무를 열 가지만 적어 보십시오. 계획하지 말고, 저자처럼 “돌아보니 이랬다”는 방식으로 떠오르는 대로 적습니다.
미션 2 — 네 가지 질문 통과시키기: 각 업무마다 다음 질문에 짧게 답해 보십시오.
- 앞으로 몇 번이나 더 할 일인가 (빈도)
- 한 번 할 때 몇 분·몇 시간이 걸리는가 (소요 시간)
- 틀리면 어떤 일이 벌어지는가 (위험)
- 이 일에서 얻은 방식을 다른 일에도 쓸 수 있는가 (재사용성)
미션 3 — 하나만 고르기: 두세 개 질문에 동시에 걸리는 일이 있다면 그것이 오늘의 후보입니다. 그 일을 클로드에게 그대로 설명해 보십시오. “이 일을 자동화하고 싶다”는 말 한마디로 충분합니다. 나머지 “어떻게 만들 것인가”는 앞선 교육 편들이 다룬 영역입니다.
미션 4 — 하지 않을 것 정하기: 목록 중 “1년에 한두 번뿐인 일”과 “내가 최종 판단해야 하는 일”을 표시해 두십시오. 이번엔 자동화하지 않기로 정하는 것도 오늘의 성과입니다.
마치며 — 코딩보다 먼저 필요한 건 고르는 눈
저자는 개발자가 아닙니다. 넉 달 동안 도구 열두 개를 만들었지만 그사이 코딩 실력이 늘어난 것 같지는 않다고 스스로 말합니다. 대신 분명히 늘어난 것이 하나 있습니다. “무엇을 자동화하고 무엇은 두어야 하는지 고르는 눈”입니다.
자동화는 대단한 기술에서 시작되지 않았습니다. 매달 지치게 하던 일 하나를 정확히 짚는 데서 시작됐습니다. 자주 하는가, 오래 걸리는가, 틀리면 위험한가, 다시 쓸 수 있는가. 이 네 가지만 스스로에게 물어도 어디부터 손댈지가 보입니다. 구현은 그다음 문제이고, 그건 지금까지 우리가 배운 AI 도구들의 도움을 받으면 됩니다.
혹시 “나는 코딩을 못 하니까”라며 미뤄 둔 반복 업무가 있다면, 만드는 법을 배우기 전에 고르는 연습부터 해 보시길 권합니다. 가장 자주, 가장 오래, 가장 위험한 일 하나. 거기서부터 생각보다 많은 것이 바뀝니다. 오늘 하나를 고르고, 그 하나를 실제로 손대 보십시오. 두 번째, 세 번째는 저자의 말처럼 그보다 훨씬 빨리 옵니다.
한 줄 정리: 자동화의 첫걸음은 “어떻게 만들까”가 아니라 “무엇을 고를까”입니다. 빈도·소요시간·위험·재사용성, 이 네 가지 질문이 오늘 손댈 일 하나를 가려 줍니다.
ⓒ Wave AI Networks — AI 활용 학습 시리즈 (비개발자용)
참고자료
- 아이엠조차장, 「자동화할 일을 고르는 것도 실력이다」, 요즘IT, 2026-08-10. https://yozm.wishket.com/magazine/detail/3890 (외부 기고자 글이며, 원문 말미에 AI의 도움을 받아 작성했다는 표기가 있습니다.)