지난 3월 AX팀에 새롭게 합류하자마자 과제를 받았어요.
Slack으로 처리하던 정산 업무 처리 방식의 비효율을 개선하는 것이었습니다.
가장 먼저 한 일은 FigJam을 열고 현재 업무 플로우를 통째로 그려보는 것이었어요. 현업 관계자들을 인터뷰하면서 업무 플로우를 시각화했습니다. 그러자 병목 구간이 눈에 들어오기 시작했어요.
그런데 플로우 차트가 완성됐을 때 한 가지를 깨달았어요. '아, 이 구간이 병목이네.' 하고 아는 것만으로는 문제를 해결할 수 없다는 것을요.
우리가 업무를 할 때 마주하는 상황과 맥락은 생각보다 매우 다채로워서 업무 순서를 파악하고 병목 구간을 찾는 것만으로 설명할 수 없는 것들이 있습니다.
그래서 제가 진짜 문제를 발견한 건, 훨씬 더 직접적인 방법을 통해서였습니다. 그건 바로 '현장의 데이터'를 확인하면서 였는데요.
지금부터 그 스토리를 모두 공개해 볼게요.
현장 데이터 안에서 진짜 문제를 발견한 일
현업자의 인터뷰를 통해서 업무 플로우는 대략 파악할 수 있었지만, 저는 한 가지를 더 확인해 보기로 했습니다. Slack에 남아있던 이전 정산 업무 스레드를 직접 찾아봤어요. 과거에 실제로 어떤 대화가 오갔는지, 그 현장 데이터를 눈으로 직접 확인한 거예요.
그때 보였습니다. 운영팀과 현장 담당자 사이에서 메시지가 가장 많이 오갔던 구간이 정산 결과를 두고 이의를 제기하고 재확인하는 부분이었어요.
의사소통 비용이 가장 높아 보이는 곳을 찾았고 그것이 제가 해결해야 할 진짜 병목이었습니다.
플로우 차트로는 어디서 '병목'이 발생하는지 위치는 한 눈에 볼 수 있었어요. 그러나 그 중 '핵심 병목'은 무엇인지는 현장의 데이터를 실제로 보지 않고서는 알 수 없는 경우가 있었습니다.
정산 프로세스를 다시 들여다보면 이런 구조였어요.
1. 각 현장에서 정산에 필요한 원시 데이터를 운영팀에 전달한다
2. 운영팀에서 전달받은 데이터를 바탕으로 정산 결과를 계산한다
3. 계산 결과를 각 현장에 통보한다
4. 각 현장에서 그 결과를 역으로 확인한다
5. 이의가 있으면 다시 운영팀으로 돌아간다
이 구조에는 두 가지 문제가 있었습니다.
원시 데이터를 전달받아 운영팀이 직접 계산하는 과정에서 실수나 오류가 생길 여지가 있었고, 설령 계산이 정확해도 각 현장이 결과를 역으로 확인하는 왕복 루프가 반드시 발생했어요. 어떤 툴을 쓰든 이 구조를 그대로 두는 한, 병목은 사라지지 않습니다.
그래서 저는 이걸 기획적으로 풀기로 시도했어요.
결과적으로는 시스템에 정산 미리보기 기능을 추가했습니다. 각 현장 담당자가 수치를 직접 입력하면 정산 결과가 즉시 화면에 표시되는 방식이에요.
현장이 데이터를 입력하는 순간 결과를 바로 확인할 수 있으니, 운영팀의 별도 계산과 통보, 그리고 역확인 과정이 모두 사라졌습니다.
(참고로 기술 스택과 관련된 이야기는 다음 뉴스레터에서 풀 예정입니다. 간단하게만 설명드리자면 Claude Code로 웹 포털을 만든 케이스였어요.)
이 변화는 실로 놀라웠습니다. 사실은 기능 하나를 추가한 게 아니라, 업무 플로우 자체를 바꾼 것이었거든요. 이로써 기대효과는 분기당 업무시간 83% 감소, 연간 240시간 절약으로 나타났습니다.
마무리하며 : 기술보다 중요한 것
'결국 AI 잘 쓰는 법을 배우면 되는 거 아닌가요?'
맞는 말이에요. 그런데 저는 이 프로젝트를 통해 조금 다르게 생각하게 됐습니다.
사실 AI는 잘못 정의된 문제도 빠르게 풀어줍니다. 방향이 틀렸어도 그럴싸한 결과물이 나와요.
즉, AI와 함께라면 기술적인 장벽은 낮아집니다. 하지만 그 강력한 도구를 올바른 문제에 겨냥하는 것은 여전히 사람의 몫입니다.
기술보다 사람의 문제 정의 능력이 왜 그토록 중요한지 이 사례를 통해 한 번 더 확인하셨으면 좋겠어요.
지금 여러분이 AI로 해결하려는 문제, 표면 상의 문제는 아닐까요?
진짜 해결해야 할 올바른 문제라고 확언할 수 있나요?
다음 이야기 예고
그리고 실은 이번 프로젝트를 통해 몇 가지 더 깨달은 게 있습니다.
솔루션이 꼭 하나의 형태일 필요는 없다는 거예요. Slack 자동화든, 노코드 조합이든, 풀스택 개발이든 — 어떤 방법이 이 문제에 가장 잘 맞는지는 직접 실험해봐야 알 수 있어요. 중요한 건 각 시도에서 관계자 피드백을 받고, 그 피드백을 다음 방향에 반영하는 것입니다.
이번 뉴스레터에서는 분량 상 다루지 못했지만 다음 뉴스레터에서 '정말로 문제 정의 능력의 중요성을 실감했다면, 도구는 언제든 바꿀 수 있어야 한다'는 것을 주제로 더 깊이 있는 이야기를 전해볼게요.
다음 이야기가 궁금하시다면, 이 뉴스레터를 구독해 주세요! 📬
의견을 남겨주세요