클로드코드 교육으로 AX 했다고요? 데이터부터 깔아야 합니다

회사에서 "우리도 AX 하자"고 선언한 뒤, 제일 먼저 한 일이 뭐였나요? 십중팔구 클로드코드 사내 교육이거나, 마케팅 자동화 워크숍이었을 거예요. 솔직히 저도 그 순서가 자연스럽다고 생각했거든요.

근데 이게 함정이더라고요. AX를 제대로 하는 기업은 별로 없고, 대부분 "AI로 뭔가 했다"는 보람에 그치는 이유가 여기 있었어요. 자동화하기 쉬운 것부터 건드리는 순간, 정작 조직의 진짜 병목은 아무도 안 보게 되잖아요.

"자동화 = AX"라는 착각이 가장 위험하다

AX 도입 초기에 빠지는 전형적 패턴이 있어요. 개발 자동화, 마케팅 자동화부터 시작하는 거죠. 에이전트한테 시키기 제일 쉬워 보이니까요. 프롬프트 깎고, Skill 세팅하고, 하네스 만들고, "오늘도 열심히 AX 했다"며 뿌듯해하는 거예요.

문제는 목표 설정 자체가 틀렸다는 거예요. AX의 목표는 생산성 혁신이지, 업무 위임이 아니거든요. 병목이 되는 지점을 찾아서 그 부분만 개선하면 되는 건데, 자동화하기 쉬워 보이는 것부터 해결하고 있으니 엉뚱한 데 리소스를 쏟는 셈이죠. 개선할 지점이 안 보인다면? 그건 AI를 적용할 타이밍이 아니라, 데이터 측정부터 해야 할 타이밍이에요.

Skill과 하네스는 시니어가 만들어야 한다 — 전 직원 바이브코더는 재앙

많은 기업이 AX 추진 명목으로 "클로드코드 사용법", "Skill + 하네스 만드는 법" 사내 교육을 해요. 이 접근도 근본부터 잘못됐어요.

Skill과 하네스는 조직 공유 시스템이에요. 시스템을 만드는 건 어려운 일이잖아요. 지금 당장 조직의 모든 인원이 업무 시스템의 비효율을 개선하는 데 적극적으로 기여하고 있나요? 아마 아닐 거예요. 시스템적 비효율은 시니어, 리드 위주로 개선하고 있을 거고, 그건 시스템에 대한 의사결정을 내리기 위해 알아야 할 '맥락'이 많기 때문이에요. 만드는 것만으로도 어려운데, 전파하고, 유지관리하고, 장기적으로 교육하는 것까지. 바텀업으로 발생하기 정말 어려운 이유가 여기 있어요.

과연 직원 모두가 바이브코더가 되는 게 좋은 미래일까요? 아무도 책임지지 않는, 관리되지 않는 막대한 코드들이 쌓이고 버려질 거예요. 코딩 실력이 생겼다고 개발자가 아니고, 시스템은 단순할수록 좋다는 거. 불편한 얘기지만 사실이에요.

실무진이 각자 AI 도입하면 — 정작 제일 큰 병목은 방치된다

AX는 바텀업보다 탑다운이 훨씬 효과적이에요. 제대로 된 혁신은 기존 프로세스를 파괴해야 하니까요.

실무진 위주로 AX를 진행하면 원래 하던 일을 '더 빠르게' 하는 데 집중하게 될 가능성이 높아요. 기존 업무 흐름을 그대로 둔 채 각 단계에 AI를 얹는 식이죠. 근데 진짜 생산성 혁신은 '이 단계가 왜 필요한가'를 묻고, 불필요한 단계를 통째로 없애는 데서 나와요. 이런 판단은 전체 프로세스를 조망할 수 있는 리더십 레벨에서만 가능하고요.

실무진이 각자 AI를 도입하면, 조직 전체로 봤을 때 최적화 지점이 분산돼요. A팀은 보고서 작성을 자동화하고, B팀은 회의록 정리를 자동화하지만, 정작 가장 큰 병목인 '팀 간 커뮤니케이션 지연'은 아무도 안 건드리는 상황. 조직 차원의 병목은 위에서 내려다봐야 보이잖아요.

데이터 수집 → 병목 발견 → 위임 반복 — 이 순서를 지켜야 하는 이유

그래서 어떻게 해야 하냐고요? 순서가 있어요.

첫째, 데이터 수집 파이프라인을 세팅하세요. 업무 시작, 완료, 프롬프트 입력, 채팅 입력 등 모든 이벤트를 수집해야 해요. 영업처럼 데이터화가 어려운 업무도 자체 도구를 도입해서 통화 시작, 통화 종료, 내용 요약 같은 이벤트를 최대한 많이 남기는 게 포인트예요. GA, Amplitude 같은 웹 인게이지먼트 도구와 굉장히 유사한 방식이라, 이들의 데이터 수집 및 시각화를 참고하면 쉬워요.

둘째, 데이터로 병목을 찾으세요. 업무 프로세스가 가시화되는 것만으로도 큰 도움이 돼요. 오래 걸리는 단계들 중에서 AI에게 위임하기 쉬운 것을 찾아내는 거죠.

셋째, 위임하고 반복 개선하세요. (여기서 실전 예시가 하나 있는데요.) 코드 리뷰를 자동화한 뒤 2주간 모니터링을 했더니, 문제가 된 티켓들이 모두 '기획서에 포함되지 않은 엣지 케이스를 구현하지 않은 경우'였대요. 이 인사이트를 바탕으로 PO를 위한 '기획 엣지케이스 점검' 하네스를 만들었더니, 이후 AI 코드 리뷰를 완전히 자동화해도 문제가 발생하지 않았다고요. 병목의 진짜 원인이 코드 리뷰가 아니라 기획 단계에 있었던 거예요.

측정할 수 없으면 개선할 수 없다 — AX도 똑같다

AX는 교육이나 하네스 세팅으로 해결되는 문제가 아니에요. 분야를 한정하지 않고 AI 에이전트 시대에 맞춰 프로세스 자체를 재구성해야 하고, 조직마다 특성이 다르기 때문에 반복적으로 개선할 수밖에 없거든요.

이때 가장 중요한 건 데이터예요. 데이터가 없으면 감으로 개선할 수밖에 없고, 결국 엉뚱한 업무만 자동화하다가 끝날 가능성이 높아요. "측정할 수 없으면 개선할 수 없다"는 말. 너무 많이 들어서 귀에 딱지가 앉았을 텐데, AX도 예외가 아니었어요.

AI Native 기업이 되고 싶다면, '재밌는 클로드코드 교육'이 아니라 지루한 데이터 수집과 분석에 집중해야 해요. 지루한 게 맞아요. 근데 그 지루함을 견딘 팀만 진짜 혁신을 만들더라고요.