실패 패턴: 요건 수집형 AX
AX 팀을 만들고, 그 팀이 각 부서를 돌며 요구사항을 수집하고, 받아온 요건대로 도구를 만들어 전달합니다. 합리적으로 보이는 이 구조가 반복적으로 실패하는 이유는 단순합니다. 현업이 그 도구를 쓰지 않기 때문입니다. AI가 업무 하나를 없애주면 그 시간만큼 더 생산적인 일로 옮겨가는 것이 회사의 기대지만, 실제 인센티브는 반대로 작동합니다. 지금 자리까지 오느라 힘겹게 익힌 업무 방식이 곧 자기 존재 증명인 사람에게, 그 일을 그만하라는 압박은 환영받지 못합니다.
성공하는 AX의 출발점: 업무를 없애고 사람을 옮겨라
4년간 직접 AI 사업을 운영해 온 노정석 대표의 결론은 명확합니다. 성공하는 AX는 "저 팀을 도와주세요"가 아니라 "저 팀의 단위 업무를 통째로 없애세요"에서 출발합니다. 이는 해고의 언어가 아닙니다. 업무 단위를 온전히 제거하고 그 사람을 새로운 직무로 전환하는 설계입니다. 기존 업무에 도구를 더 얹어주는 방식은 결국 엑셀과 파워포인트를 다른 도구로 바꿔주는 것에 그치고, 회사 차원의 생산성 증가는 일어나지 않습니다.
도구는 안 만드는 게 베스트 — 순정 바닐라 구성
또 하나의 반직관적 결론은 효율화 도구를 직접 만들지 말라는 것입니다. 사내에서 온갖 프레임워크와 자체 에이전트를 시도한 끝에 남은 답은, 데이터 커넥터를 깔끔하게 만들고, 도메인을 이해한 프롬프트를 잘 쓰고, 프론티어 모델에 Claude Code 같은 검증된 하네스를 붙이는 구성이었습니다. 자체 개발한 어떤 조합보다 이 단순한 구성의 성능이 좋았습니다.
프롬프트를 잘 쓰는 힘은 엔지니어링 역량이 아니라 도메인 이해에서 나옵니다. 그 업무가 실제로 어떻게 돌아가는지, 데이터가 어떤 모양인지 아는 사람이 쓴 프롬프트가 일을 끝냅니다.
AX 컨설팅이 점검해야 할 것
SH Consulting이 AX 컨설팅에서 도구 제작보다 먼저 보는 것은 두 가지입니다. 어떤 업무 단위를 통째로 없앨 수 있는가, 그리고 그 일을 하던 사람을 어디로 전환할 것인가. 이 설계 없이 도구만 공급하는 AX는 예산을 쓰고도 조직을 바꾸지 못합니다.