AI가 등장하면서 누구나 필요한 소프트웨어를 모델에게 부탁해 즉석에서 만들 수 있고, 그래서 우리가 아는 앱은 사라진다는 전망이 유행처럼 퍼지고 있다. 벤 에번스는 이 발상이 실리콘밸리 특유의 착시라고 지적한다. 그의 논지는 단순하다. 소프트웨어가 어디에서 오는지, 사람들이 그것을 실제로 어떻게 쓰는지, 그리고 기업이 어떻게 변하는지를 오해했다는 것이다. 코드를 쉽게 짜게 만드는 것과 조직을 바꾸는 것은 전혀 다른 문제다.
전형적인 미국 대기업은 수백에서 수천 개의 소프트웨어를 굴린다. SAP나 Workday 같은 거대한 기록 시스템, 수백 개의 버티컬 SaaS, 그 아래로 부서 하나를 돌리는 10메가짜리 스프레드시트까지 무수한 스크립트와 자동화가 얽혀 있다. 정작 회사 자신도 무엇을 얼마나 쓰고 있고 무엇에 돈을 내는지 정확히 모르는 경우가 많다. 그런데도 여전히 지루하고 반복적인 업무가 넘쳐난다. 여기서 'AI가 이 모든 것을 쓸어버린다'는 유혹이 생긴다. 도구 하나 만드는 데 10분 걸릴 일을 한 시간 들여 자동화하는 게 엔지니어라는 오래된 농담처럼, 이제는 코드를 모르는 사람도 5분 만에 그 도구를 만들거나 아예 모델에게 일을 시켜버릴 수 있다는 것이다.
문제는 코드가 아니라 '문제를 보는 눈'
에번스의 반론은 대부분의 사람은 도구 제작자가 아니라는 사실에서 출발한다. 뛰어난 이혼 전문 변호사는 하루 종일 자기 사건과 의뢰인을 생각하지, 훌륭한 법률 검색 소프트웨어가 무엇을 해줄지 고민하지 않는다. 유능한 영업 담당자도 마찬가지다. 엑셀이 온보딩 흐름과 템플릿, 'File/New'의 제안들로 이 간극을 메우려 했지만, 그 템플릿 하나하나가 결국 별도의 회사가 됐다. 'Claude for X' 같은 시도도 도움은 되지만 답은 아니라는 게 그의 판단이다.
더 깊은 문제는, 지난 수십 년간 자동화한 것들 대부분이 애초에 눈에 보이지 않았다는 점이다. 문제가 존재한다는 사실 자체가 다른 무언가에 묻히거나 번들되어 감춰져 있기 일쑤고, 문제를 본다 해도 올바른 해법은 대개 재정의하거나 언번들해야 나온다. 성공한 소프트웨어 회사 뒤에는 적절한 문제나 접근을 찾지 못한 여러 번의 실패가 있었다. 코드 작성을 쉽게 만든다고 이 어려움이 사라지지는 않는다. 진짜 어려운 부분은 '여기에 도구가 필요하다'는 것을 아는 것, 그리고 그 도구가 무엇을 해야 하는지 아는 것이다. 도구를 볼 줄 아는 사람이 로펌이나 건축 사무소를 돌며 정작 당사자는 못 보는 기회를 짚어내는 '포워드 디플로이드 엔지니어' 개념이 여기서 나온다.
제도화와 즉흥 사이의 스펙트럼
설령 좋은 아이디어를 얻어도 혼자서 회사 전체의 일하는 방식을 바꿀 수는 없다. 하나의 워크플로가 다섯 부서, 세 개의 기록 시스템, 네 개의 규제 체계에 걸쳐 수백 명을 건드린다면, 그것은 구매이자 의사결정이며 18개월짜리 영업 과정이 된다. 에번스는 소프트웨어가 top-down에서 bottom-up까지, 즉 '제도화된 것'과 '즉흥적인 것' 사이의 스펙트럼 위에서 선택된다고 본다. SAP나 Carta처럼 모두가 같은 방식으로 해야 하는 일은 제도화되고, 예외와 일회성 질문은 엑셀·이메일·공유 폴더·PDF 같은 자유로운 공간에서 임시로 처리된다. 그러다 그 임시 업무가 매번 반복되고 매출과 리스크가 붙으면, 감사·보안·유지보수·책임을 위해 회사는 결국 그것을 제도화한다. 기업에 수백 개의 앱이 있는 이유가 바로 이 과정이다.
이것은 번들과 언번들의 연속적이고 유기적인 흐름이다. Carta는 CFO의 스프레드시트 하나를 관리해주며 40억 달러 규모로 성장했지만, 때로는 업무가 반대로 이동하기도 한다. 어느 컨설턴트는 일의 절반이 엑셀 쓰는 사람에게 데이터베이스를 권하는 것이고 나머지 절반은 그 반대라고 말했다. PwC는 매년 3~4천 명을 뽑으니 제도화된 전용 소프트웨어를 쓰지만, 열 명을 뽑는 작은 회사는 이메일과 구글 시트로 충분하다. 성장하면서 노션이나 SME용 SaaS로 옮겨가고, 반대로 PwC 안의 작은 팀은 Workday가 너무 경직돼서 구글 시트로 후보를 관리한다. 언번들은 그렇게 다시 시작된다.
AI는 답이 아니라 새로운 선택지를 만든다
AI는 이 모든 층위를 가로질러 흐른다. 기존 앱을 확장하고, 새로운 버티컬 앱을 낳고, 엑셀과 이메일 같은 즉흥 공간에도 새 능력을 더한다. 챗봇 자체가 엑셀과 이메일 옆에 놓인 또 하나의 자유로운 공간이 되어 앱으로부터 업무를 가져오기도 하고 빼앗기기도 한다. 결국 AI는 질문을 바꾸는 게 아니라 새로운 선택지를 만들고 임계값을 이동시킨다. 이는 지난 3년간의 엔터프라이즈 AI 도입 경험과 정확히 겹친다. 회사가 전 직원에게 Copilot을 나눠줬지만 소수만 활발히 쓰고, 상당수는 주 몇 번, 나머지는 거의 쓰지 않는다. 이는 1983년에 모두에게 PC와 로터스 1-2-3을, 1997년에 웹 브라우저를 쥐여준 것과 같은 문제다. 도구를 나눠준 것이 곧 송장 처리 효율을 바꾸거나 공급망을 재구축한 방법은 아니었다.
구조적 프로세스를 바꾸는 방식은 여전히 오래된 CIO의 언어, 즉 파일럿과 등대 사례, 퀵윈과 측정 가능한 성과다. 파일럿의 절반쯤 성공하는 것은 정상이다. 문제는 워크플로가 수백 개인데 파일럿은 대여섯 개뿐이라 확장이 안 되는 것처럼 보인다는 점이다. 에번스는 새 기술이 올 때마다 기업이 세 가지 질문을 던져야 한다고 정리한다. 어떻게 사거나 만들어 배포할 것인가, 이것이 우리 업무를 얼마나 바꾸는가, 그리고 우리 사업의 경제성과 경쟁 구도에 새로운 위협을 만드는가. 이 질문들은 전 직원에게 'Claude for X'를 나눠준다고 답해지지 않는다. 한국의 IT 실무자에게 이 글이 주는 함의도 분명하다. AI 전환의 병목은 모델 성능이나 코드 생산성이 아니라, 자동화할 문제를 알아보고 그 해법을 조직 전체에 제도화해내는 역량에 있다는 것이다.