사소한 귀찮음에서 시작된 스노우볼
요즘 서비스 기획자나 PM의 JD를 보다 보면 유독 눈에 띄는 우대사항이 있다. 바로 n8n, RAG 등 AI 활용을 기반으로 한 업무 자동화다.
처음에는 이 우대사항이 나와는 영 관련이 없다고 생각했다. AI를 활용한 자동화 프로젝트를 시도한 적은 있었지만 실패(…)했고, 정책 아카이브를 만들어 문서 간 이동을 편리하게 만든 것도 기업에서 말하는 자동화와는 조금 거리가 있어 보였다. 나에게 업무 자동화란 에이전트나 n8n 같은 것을 구축해서 뭔가 거창하게 만들어야 한다는 이미지가 강했기 때문이다.
그런데 조금 넓게 생각해 보면 자동화란 결국 사람이 반복해서 하던 일을 일정한 규칙에 따라 시스템이 대신하도록 만드는 작업이다. 이렇게 생각하니 업무뿐만 아니라 일상에서도 크고 작은 자동화를 여러 번 해 왔다는 사실이 떠올랐다.
그래서 이번 글에서는 거창한 AI 자동화 이야기가 아니라, 불편한 반복을 찾아 자동화해 온 경험들을 기록해 보고자 한다.
가장 최근에 한 자동화 작업은 아주 사소한 불편에서 시작됐다. 나는 보통 Figma로 이력서와 포트폴리오를 작업하고, 기업에 제출할 때는 이를 PDF로 내보낸다. 그런데 Mac을 사용한 지 얼마 되지 않았던 탓에, 파일명이 NFD 방식으로 저장될 수 있다는 사실을 몰랐다.
한글ㅎㅏㄴㄱㅡㄹMac에서는 둘 다 정상적으로 보이지만, NFD 파일명은 Windows에서 자모가 분리되어 깨져 보일 수 있다.
생각해 보면 Windows 환경에서 일할 때 가끔 한글 자모가 죄다 깨진 파일을 받은 적이 있었다. 그때는 ‘뭐 이렇게 저장해서 보내나~’ 싶었는데, 그 사람이 바로 나였던 것이다 ^^…
이 사실을 알고 난 뒤에는 반디네이머라는 프로그램을 이용해 파일명을 수동으로 NFC 변환했다. 하지만 문제는 Figma를 꽤 자주 수정하고 PDF를 다시 내보낸다는 점이었다. 수정하고 내보내고 변환하고. 이걸 반복하다 보니 매번 변환 여부를 기억하는 데에도 한계가 있었다. 결국 실제 지원 과정에서도 변환이 누락된 파일을 제출하고 말았다. 지원 서류의 파일명은 기업이 처음 마주하는 정보 중 하나인데, 이런 초짜 같은 실수를 한 나를 결코 용서할 수 없었다.
귀찮고 화가 난 나는 ‘앞으로는 까먹지 말아야지!’라고 다짐하는 대신, 애초에 내가 변환하지 않아도 알아서 처리되는 방법을 찾기로 했다. 그리하여 반려 GPT와 방법을 찾던 중 macOS에 기본으로 설치된 Automator를 이용하면 아주 간단하게 해결할 수 있다는 사실을 알게 됐다. 이런 좋은 프로그램이 내장이라니!
원리는 생각보다 단순했다. Downloads 폴더에 새로운 파일이 들어오면 Automator가 이를 감지하고, 파일이 생길 때마다 미리 등록해 둔 셸 스크립트를 실행한다. 이 스크립트는 새 파일의 이름을 확인해 NFD로 된 한글을 NFC 방식으로 정규화한다. 나는 어떤 동작을 원하는지만 설명했고, 실행 방법과 필요한 코드는 GPT의 도움을 받아 설정했다.
테스트 결과는 대성공. 이제 Figma에서 PDF를 내보내면 Downloads 폴더에 저장되는 순간 파일명이 자동으로 정리된다. 별도의 프로그램을 열 필요도, 변환해야 한다는 사실을 기억할 필요도 없어졌다. 야호!
‘게으름이 세상을 바꾼다’는 말이 있다. 귀찮은 일을 줄이고 싶어 하는 인간의 본능은 몇 차례의 산업 혁명을 거쳐 지금과 같은 AI 시대를 만들었다. 나 또한 산업 혁명까지는 아니지만, 이전 업무에서 비슷한 시도를 한 적이 있다.
때는 바야흐로 내가 IT 업계에서 일하게 될 거라고는 꿈에도 모르던 몇 년 전. 신문사에서 경영 지원과 고객 관리 업무를 맡고 있었다. 그중에는 각 지사에서 엑셀로 보내온 신규 독자 정보를 확인하고 사내 전산에 등록하는 업무도 있었다.
당시 한 사람이 하루에 처리할 수 있는 양은 약 40건 정도였다. 지사마다 엑셀 양식이 달랐던 데다, 몇백 건의 정보를 전산에 일일이 수기로 입력하고 있었기 때문이다. 여러 업무 중 하나일 뿐인데 상당한 시간이 들었고, 신규 독자 등록이 실적과 직결되는 지사에서는 이를 재촉하는 경우가 많았다.
그러다 문득 이런 생각이 들었다.
‘어차피 들어가야 하는 필수 정보는 똑같은데, 이걸 왜 매번 직접 옮기고 있지?’
제각각인 열 순서나 전화번호 표기 등을 하나의 규칙으로 통일하고, 이를 자동으로 정리해 주는 엑셀 매크로를 만들기로 했다. 지금 같았으면 GPT를 붙잡았겠지만 생성형 AI가 지금처럼 활성화되기 전이었다. 그래서 네이버 지식인에 하고 싶은 동작을 하나씩 질문하며 감사한 답변자분의 도움을 받아 매크로를 완성했다.
결과는 성공적이었다. 단축키를 누르면 데이터가 정해둔 규칙에 맞게 정리됐고, 하루 약 40건이던 처리량은 120건 정도로 3배가량 늘었다. 반복 입력에 쓰던 시간이 줄어든 만큼 다른 업무에 집중할 수 있었고, 빠른 처리를 원하던 지사도 만족을 표했다.
당시에는 이걸 업무 자동화라고 생각하지 않았다. 그저 반복 작업이 번거로워 어떻게든 줄이고 싶었을 뿐이다. 하지만 지금 돌아보면 이후의 문제 해결 방식에도 꽤 영향을 준 경험이었다. 불편한 일을 마주했을 때 그냥 익숙해지는 대신, 더 적은 수고로 해결할 방법부터 찾게 된 것도 아마 이때부터였던 것 같다.
본격적으로 IT 회사에 입사한 뒤에는 비슷한 문제를 팀 단위에서 마주하게 됐다. 당시 회사에서는 B2C 서비스를 운영하며 카카오톡 채널로 고객 상담을 진행했다. 하루에도 몇백 건씩 들어오는 문의 중에는 상담원이 없어도 스스로 해결할 수 있는 단순 문의가 상당히 많았다. 내용 없이 “안녕하세요”만 보내고 답장을 기다리는 고객도 적지 않았다. 운영팀의 개입이 필요한 문의와 단순 응대가 한데 섞이면서 부담이 커지고 있었고, 이를 줄이기 위해 챗봇 구축 업무를 맡게 됐다.
우선 운영팀을 통해 단순 문의 유형 약 50개를 수집했다. 이를 그대로 챗봇에 옮기지 않고 유사한 질문끼리 묶어 20개 정도로 통합, 중요도와 이용 빈도를 고려해 메뉴 순서를 구성했다. 견적 문의, 예약 문의, 자주 묻는 질문으로 큰 카테고리를 나누고 고객이 챗봇에서 먼저 해결 방법을 찾아본 뒤, 해결되지 않을 때 상담원에게 연결되도록 설계했다.
챗봇을 구축한 뒤에도 실제 문의를 살펴보며 유사 발화를 지속적으로 추가했다. 예를 들어 고객이 ‘견적 취소’라는 정확한 표현을 쓰지 않고 “취소할래요”, “견적 안 할래요”라고 말해도 같은 답변으로 이어질 수 있도록 실제 고객들이 자주 사용하는 표현을 파악해서 반영했다.
약 한 달 뒤 확인한 결과 상담원 직접 연결은 이전보다 약 56% 감소했다. 운영팀에서도 단순 인사만 남기고 상담을 기다리는 고객이 확실히 줄었다는 피드백을 받았다.
신문사에서 매크로를 만들 때만 해도 출발점은 내가 반복하는 일을 줄이고 싶다는 것이었다. 챗봇에서는 그 범위가 내가 아닌 팀이 반복하고 있는 일로 넓어졌다. 두 경험은 규모도, 사용한 기술도 전혀 달랐지만 시작 방식은 비슷했다. 반복되는 일을 찾고, 그 안에서 일정한 규칙을 찾아낸 다음, 사람이 직접 해야 하는 일을 줄이는 것. 내가 자동화를 바라보는 관점도 이 과정을 거치며 조금씩 달라졌다.
처음 자동화를 시도한 이유는 늘 단순했다. 눈앞의 귀찮은 일을 줄이고 싶었다. 하지만 비슷한 경험이 쌓이면서 개별 작업보다 전체 과정이 먼저 보이기 시작했다. 업무가 시작해서 끝날 때까지 어떤 단계를 거치는지, 그중 무엇이 반복되고 있는지를 자연스럽게 살펴보게 됐다.
그렇다고 반복되는 일을 모두 자동화할 수 있는 건 아니다. 일정한 규칙만으로 처리할 수 있는 일이 있는 반면, 반드시 사람의 확인이 필요한 일도 있다. 자동화에 드는 공수와 구현 비용에 비해 줄일 수 있는 수고가 크지 않다면 차라리 사람이 하는 편이 나을 수도 있다. 결국 중요한 건 자동화 자체가 아니라 어디까지 자동화할 것인지를 판단하는 일이다.
그래서 요즘은 ‘어떤 자동화 도구를 사용할까?’보다 ‘얼만큼의 범위까지 자동화할 수 있을까?’에 더 관심이 간다. 도입부에서 이야기한 기업들의 JD 속 업무 자동화 경험도 이제는 조금 다르게 읽힌다. 특정 기술을 사용할 줄 아는 것만큼이나, 업무 속 반복과 낭비를 발견하고 무엇을 개선할지 결정하는 능력이 중요하다는 의미로 말이다.
자동화를 여러 번 해보고 나니, 줄이고 싶었던 건 업무량 자체가 아니라 사람이 굳이 하지 않아도 되는 일에 쓰이는 시간이었다. 신문사에서 하루 40건이던 처리량을 120건으로 늘렸을 때도, 가장 좋았던 건 숫자가 3배가 됐다는 사실만은 아니었다. 반복 입력에 쓰던 시간을 줄이고 그만큼 다른 업무에 집중할 수 있게 됐다. 챗봇도 마찬가지였다. 상담원을 대신하려고 만든 것이 아니라, 굳이 사람이 답하지 않아도 되는 단순 문의를 먼저 걸러 정말 도움이 필요한 고객에게 더 많은 시간을 쓸 수 있도록 한 것이었다.
자동화를 좋아하는 이유도 여기에 있는 것 같다. 생산량을 무작정 늘리기보다, 사람의 손이 꼭 필요한 곳에 더 많은 여유를 남겨두고 싶었다.
편리함이라는 건 참 웃기게도 한번 경험하고 나면 묘한 기준이 생긴다. 하루 40건의 독자 정보를 수기로 입력할 때는 그게 원래 그런 일인 줄 알았고, 매번 파일명을 변환할 때도 그냥 내가 더 잘 챙겨야 할 과정이라고 생각했다. 그런데 다른 방법을 찾고 나니 이전에는 당연했던 반복이 갑자기 불편하게 느껴진다.
편리함은 이전에는 당연하다고 생각했던 행위를 불편으로 만든다.
어쩌면 내가 참을 수 없게 된 건 편리함 그 자체가 아니라, 다른 방법이 있다는 걸 알면서도 같은 일을 계속 반복하는 것인지도 모른다.
앞으로도 새로운 자동화 도구를 익히면서 눈앞의 반복을 당연하게 받아들이지 않는 감각을 잃지 않고 싶다. 그리고 가끔은 귀찮은 일을 마주쳤을 때 한 번쯤 질문해 보려고 한다.
“이 일, 정말 사람이 계속 해야 하나?”
for f in "$@"; do
[ -e "$f" ] || continue
dir="$(dirname "$f")"
name="$(basename "$f")"
nfc_name="$(printf '%s' "$name" | iconv -f UTF-8-MAC -t UTF-8)"
if [ "$name" != "$nfc_name" ]; then
mv "$f" "$dir/$nfc_name"
fi
done