이 글은 [이현의 Human AX]에서 발행되었습니다.

AX 실전 벤치마크 사례, 퀄리티 있는 AI 인사이트를 
매주 이메일로 받아보고 싶으시다면, 뉴스레터를 구독해 주세요.

[구독하러 가기]

지난 3월 AX팀에 새롭게 합류하자마자 과제를 받았어요.

Slack으로 처리하던 정산 업무 처리 방식의 비효율을 개선하는 것이었습니다.

가장 먼저 한 일은 FigJam을 열고 현재 업무 플로우를 통째로 그려보는 것이었어요. 현업 관계자들을 인터뷰하면서 업무 플로우를 시각화했습니다. 그러자 병목 구간이 눈에 들어오기 시작했어요. 

그런데 플로우 차트가 완성됐을 때 한 가지를 깨달았어요. '아, 이 구간이 병목이네.' 하고 아는 것만으로는 문제를 해결할 수 없다는 것을요. 

우리가 업무를 할 때 마주하는 상황과 맥락은 생각보다 매우 다채로워서 업무 순서를 파악하고 병목 구간을 찾는 것만으로 설명할 수 없는 것들이 있습니다.

그래서 제가 진짜 문제를 발견한 건, 훨씬 더 직접적인 방법을 통해서였습니다. 그건 바로 '현장의 데이터'를 확인하면서 였는데요.

지금부터 그 스토리를 모두 공개해 볼게요.

현장 데이터 안에서 진짜 문제를 발견한 일

현업자의 인터뷰를 통해서 업무 플로우는 대략 파악할 수 있었지만, 저는 한 가지를 더 확인해 보기로 했습니다. Slack에 남아있던 이전 정산 업무 스레드를 직접 찾아봤어요. 과거에 실제로 어떤 대화가 오갔는지, 그 현장 데이터를 눈으로 직접 확인한 거예요.

이미지 출처 : https://unsplash.com/ko

그때 보였습니다. 운영팀과 현장 담당자 사이에서 메시지가 가장 많이 오갔던 구간이 정산 결과를 두고 이의를 제기하고 재확인하는 부분이었어요.

의사소통 비용이 가장 높아 보이는 곳을 찾았고 그것이 제가 해결해야 할 진짜 병목이었습니다.

플로우 차트로는 어디서 '병목'이 발생하는지 위치는 한 눈에 볼 수 있었어요. 그러나 그 중 '핵심 병목'은 무엇인지는 현장의 데이터를 실제로 보지 않고서는 알 수 없는 경우가 있었습니다.

정산 프로세스를 다시 들여다보면 이런 구조였어요.

1. 각 현장에서 정산에 필요한 원시 데이터를 운영팀에 전달한다

2. 운영팀에서 전달받은 데이터를 바탕으로 정산 결과를 계산한다

3. 계산 결과를 각 현장에 통보한다

4. 각 현장에서 그 결과를 역으로 확인한다

5. 이의가 있으면 다시 운영팀으로 돌아간다

  이미지 출처 : 나노바나나2 생성  

이 구조에는 두 가지 문제가 있었습니다.

원시 데이터를 전달받아 운영팀이 직접 계산하는 과정에서 실수나 오류가 생길 여지가 있었고, 설령 계산이 정확해도 각 현장이 결과를 역으로 확인하는 왕복 루프가 반드시 발생했어요. 어떤 툴을 쓰든 이 구조를 그대로 두는 한, 병목은 사라지지 않습니다.

 

그래서 저는 이걸 기획적으로 풀기로 시도했어요.

결과적으로는 시스템에 정산 미리보기 기능을 추가했습니다. 각 현장 담당자가 수치를 직접 입력하면 정산 결과가 즉시 화면에 표시되는 방식이에요.

현장이 데이터를 입력하는 순간 결과를 바로 확인할 수 있으니, 운영팀의 별도 계산과 통보, 그리고 역확인 과정이 모두 사라졌습니다.

(참고로 기술 스택과 관련된 이야기는 다음 뉴스레터에서 풀 예정입니다. 간단하게만 설명드리자면 Claude Code로 웹 포털을 만든 케이스였어요.)

이미지 출처: 나노바나나 2 생성

이 변화는 실로 놀라웠습니다. 사실은 기능 하나를 추가한 게 아니라, 업무 플로우 자체를 바꾼 것이었거든요. 이로써 기대효과는 분기당 업무시간 83% 감소, 연간 240시간 절약으로 나타났습니다.

마무리하며 : 기술보다 중요한 것

 '결국 AI 잘 쓰는 법을 배우면 되는 거 아닌가요?'

맞는 말이에요. 그런데 저는 이 프로젝트를 통해 조금 다르게 생각하게 됐습니다.

사실 AI는 잘못 정의된 문제도 빠르게 풀어줍니다. 방향이 틀렸어도 그럴싸한 결과물이 나와요. 

즉, AI와 함께라면 기술적인 장벽은 낮아집니다. 하지만 그 강력한 도구를 올바른 문제에 겨냥하는 것은 여전히 사람의 몫입니다.

기술보다 사람의 문제 정의 능력이 왜 그토록 중요한지 이 사례를 통해 한 번 더 확인하셨으면 좋겠어요.

지금 여러분이 AI로 해결하려는 문제, 표면 상의 문제는 아닐까요?

진짜 해결해야 할 올바른 문제라고 확언할 수 있나요?

다음 이야기 예고

그리고 실은 이번 프로젝트를 통해 몇 가지 더 깨달은 게 있습니다.

솔루션이 꼭 하나의 형태일 필요는 없다는 거예요. Slack 자동화든, 노코드 조합이든, 풀스택 개발이든 — 어떤 방법이 이 문제에 가장 잘 맞는지는 직접 실험해봐야 알 수 있어요. 중요한 건 각 시도에서 관계자 피드백을 받고, 그 피드백을 다음 방향에 반영하는 것입니다.

이번 뉴스레터에서는 분량 상 다루지 못했지만 다음 뉴스레터에서 '정말로 문제 정의 능력의 중요성을 실감했다면, 도구는 언제든 바꿀 수 있어야 한다'는 것을 주제로 더 깊이 있는 이야기를 전해볼게요.

다음 이야기가 궁금하시다면, 이 뉴스레터를 구독해 주세요! 📬