AI, 도구, 그리고 변화

게시일: 2026년 11월 2일 | 원문 작성일: 2026년 9월 3일 | 저자: Benedict Evans | 원문 보기

• • •

전형적인 미국 대기업에는 지금 수백, 어쩌면 수천 개의 소프트웨어가 있어요. SAP나 Workday 같은 거대한 ‘빅 아이언’ 수평형 시스템T1이 있고, 수백 개의 수직형 SaaS 애플리케이션이 있고, 그 밖에도 수백 개의 워크플로, 스크립트, 자동화, 데이터베이스가 있어요. 한 부서를 돌리는 10메가짜리 스프레드시트까지 포함해서요. 회사가 자기 소프트웨어가 정확히 얼마나 되는지, 실제로 뭐가 쓰이는지, 얼마를 내고 있는지조차 모르는 경우도 아주 많아요. 그런데도 소프트웨어가 이렇게 많은 회사가 여전히 지루하고 반복적인 업무로 가득해요.

AI가 이걸 대부분 쓸어버릴 거라고 생각하고 싶어지는 건 자연스러워요. 엔지니어란 10분 걸리는 일을 자동화하려고 한 시간 동안 도구를 만드는 사람이라는 오래된 농담이 있잖아요. 그런데 이제 AI가 있으면 그 도구를 5분 만에 만들 수 있고, 엔지니어일 필요도 없고, 코드를 쓸 필요도 없어요. 모델에게 도구를 만들어 달라고 하면 돼요. 더 근본적으로는, 모델이 그 일을 직접 해 주면 되고요. 도구를 하나씩 만드는 대신, 소프트웨어 자체가 동적이고 생성적이고 자유롭고 즉흥적인 무언가가 될지도 몰라요. 훨씬 적은 소프트웨어로 훨씬 많은 업무를 자동화할 수 있게 되는 거예요.

당신이 도구 제작자라면, 그리고 실리콘밸리 사람은 모두 도구 제작자인데, 이 이야기는 짜릿해요. 하지만 저는 이게 소프트웨어가 어디서 오는지, 사람들이 소프트웨어를 어떻게 쓰는지를 오해한 것이고, 회사가 어떻게 변하는지도 놓치고 있다고 생각해요.

우선 대부분의 사람은 도구 제작자가 아니에요. 자기 일을 다른 방식으로 할 수 있을지 본능적으로 생각하는 사람도 많지 않고요. 실리콘밸리라는 거품 속에서만 지내다 보면 이걸 잊기 쉬워요. 그곳에서는 온 세상이 일하는 방식을 바꾸는 도구를 만드는 일을 중심으로 돌아가니까요. 하지만 이혼 소송을 정말 잘하는 변호사는 하루 종일 자기 사건과 의뢰인을 생각하지, 훌륭한 증거 개시 소프트웨어가 무엇을 해 줄 수 있을지는 생각하지 않아요. 정말 뛰어난 기업 영업 담당자도 자기 제품과 고객과 경쟁사를 생각하느라 시간을 다 쓰지, 훌륭한 영업 지원 소프트웨어가 생산성을 얼마나 높여 줄지는 생각하지 않아요.

엑셀 같은 제품은 온보딩 흐름, 어시스턴트, 템플릿으로 이 문제를 메워 보려고 해요. ‘파일/새로 만들기’에 보이는 것들은 모두 이걸로 무엇을 할 수 있는지에 대한 제안이에요. 하지만 그 템플릿 하나하나가 결국 회사 하나가 되었어요. ‘Claude for X’ 같은 것에서도 같은 모습이 보여요. 도움은 되지만 정답은 아니에요.

좁게 보면, 자동화해야 할 일이 눈앞에 빤히 놓여 있어도 그 일을 하는 사람은 그걸 보지 못한다는 뜻이에요. ‘전진 배치 엔지니어(FDE, forward-deployed engineer)’T2라는 발상이 여기서 나와요. 스스로 만드는 사람이고 AI가 무엇을 만들 수 있는지 아는 사람이 로펌이나 건축 사무소를 ‘그냥’ 돌아다니면, 변호사나 건축가는 못 보는 기회가 테이블 위에 널려 있는 게 보인다는 거죠. (많은 기술업계 사람이 열다섯 살 때 인턴십이나 부모님 사무실을 돌아다니며 했던 경험이기도 해요. “음, 아빠, 이거 이렇게 하면 된다는 거 알았어요?”)

더 깊은 문제는 지난 수십 년 동안 우리가 자동화해 온 것 대부분이 도구 제작자에게조차 명백하지 않았고, 뻔한 해법도 없었다는 점이에요. 매일 쓰는 것들 중에 처음에는 “내가 이걸 왜 써야 하지?” 싶었던 게 누구에게나 있잖아요. 문제가 존재한다는 사실 자체가 명백하지 않은 경우가 아주 많고, 그 문제가 다른 무언가에 끼워져 있거나 묶여 있거나 숨어 있는 경우도 아주 많아요. 문제가 보이거나 보인다고 생각해도 고치는 올바른 방법이 분명하지 않은 건 마찬가지예요. 해법은 문제를 다시 정의하거나 쪼개는 데 있고, 그걸 알아내는 일은 어려워요. 성공한 소프트웨어 회사 중 상당수는 그 전에 올바른 접근법이나 올바른 문제를 제대로 짚지 못한 시도가 여섯 번쯤 실패로 끝났어요.

코드를 더 쉽게 쓸 수 있게 해 줘도, 즉 도구를 더 쉽게 만들 수 있게 해 줘도 이 중 어느 것도 풀리지 않아요. 어려운 건 애초에 이 일에 도구가 필요하다는 걸 알아채는 것, 그다음으로 그 도구가 무엇을 해야 하는지 아는 거예요.

거기까지 갔다 해도 다른 모든 사람이 그 도구를 쓰게 만들어야 해요. 자동화하고 싶은 문제, 워크플로, 업무 중에는 다섯 개 부서, 세 개의 기록 시스템, 네 개의 규제 체계에 걸친 50명, 500명이 얽힌 것이 많아요. 매입채무를 다르게 처리하는 멋진 아이디어가 있어도, 회사 모든 사람이 그 일을 하는 방식을 혼자 바꿀 수는 없어요. 그러려면 구매하고, 결정하고, 18개월짜리 영업 과정을 거쳐야 해요.

• • •

둘째, 이 모든 건 소프트웨어를 하향식에서 상향식까지 이어지는 스펙트럼 위에서 구매하고, 고르고, 만든다는 뜻이에요. 회사는 SAP를 사고 사용자는 스프레드시트를 만들죠. 저는 이걸 제도화된 것에서 즉흥적인 것까지 이어지는 스펙트럼으로 봐도 유용하다고 생각해요.

SAP, Carta, Rippling처럼 이미 갖춘 전용 도구로 쉽게 할 수 있는 업무가 있어요. 이런 업무와 워크플로는 제도화되어 있어요. 그 도구를 만든 회사들과 당신 회사의 많은 사람이 오랜 시간 공을 들여 그 일을 하는 올바른 방식을 정리해 왔고, 모두가 같은 도구로 같은 방식으로 하는 게 중요해요. 하지만 그런 도구로는 하기 어렵거나 불가능한 예외, 엣지 케이스, 일회성 질문도 있어요. 사용자들은 밑에서부터 자기 해법을 만들어 이런 일을 처리해요. 엑셀, 이메일, 공유 폴더, Tableau, 파워포인트, CSV, 스크린샷, PDF, 전화 회의처럼 형식이 자유로운 바탕 위의 모호하고 즉흥적인 공간에서요.

그러다 어떤 업무가 늘 하는 일이 되고, 매번 같은 방식으로 하게 되고, 많은 사람이 하게 되고, 중요해져서 매출과 위험이 걸리게 되면 어느 시점에 회사는 그걸 제도화해야 해요. 감사, 보안, 유지보수, 책임 소재가 필요해지니까요. 욕망의 길(desire path)을 포장하고 돈을 주고 사람을 시켜 돌에 새기는 셈이에요. 앞서 말했듯 그 길이 거기 있다는 걸 모를 수 있고, 수백 명이 하루에 한 시간씩 이 일에 낭비하고 있다는 걸 모를 수도 있고, 올바른 해법을 찾는 것도 어려울 수 있어요. 하지만 그 과정이 바로 회사에 앱이 수백 개씩 있는 이유예요.

SaaS로의 전환 때도 이런 일을 많이 겪었어요. SaaS는 소프트웨어의 양을 또 한 자릿수 늘렸고, 새로운 운영 모델과 새로운 주기를 가져왔고, 그 도약을 따라가지 못한 기존 강자를 여럿 무너뜨렸어요(‘SaaS 종말론(SaaSpocalypse)’T3의 진짜 근거예요). 이건 묶기와 쪼개기가 끊임없이 이어지는 유기적인 흐름이에요. 그 모든 SaaS 앱은 SAP나 엑셀이나 이메일로도 할 수 있는 일을 해요. Carta는 CFO 한 사람을 위한 스프레드시트 하나를 관리하면서 40억 달러짜리 회사가 되었고요. 그리고 업무가 되돌아가기도 해요. 몇 년 전에 만난 컨설턴트는 일의 절반이 엑셀을 쓰던 사람에게 데이터베이스를 쓰라고 말하는 것이고, 나머지 절반은 그 반대라고 하더군요.

그래서 PwC처럼 매년 졸업생을 3~4천 명 뽑는 곳은 그걸 관리하는 데 전용의 ‘제도화된’ 소프트웨어를 써요. 한 해에 대여섯 명, 열 명을 뽑는 작은 회사는 이메일, 공유 폴더, 구글 시트를 쓰고요. 그 작은 회사가 커지면 어느 시점에 그걸로는 감당이 안 되어 노션이나 중소기업용 SaaS HCM으로 옮길 수도 있어요. 하지만 PwC 안의 작은 팀이 Workday가 너무 뻣뻣하다는 이유로 어떤 포지션을 채울 후보자를 구글 시트로 추적할 수도 있어요. 쪼개기가 다시 시작되는 거죠.

이제 AI가 이 모든 영역에 한꺼번에 밀려들어요. AI는 기존의 모든 앱을 확장할 것이고, 새로운 수직형 앱도 많이 나올 것이고, 엑셀, Tableau, 구글 시트, 이메일처럼 즉흥적인 해법을 위한 자유로운 공간들도 새로운 기능을 얻을 거예요. 이 순환 속에서 챗봇 자체도 엑셀이나 이메일 옆에 놓인 새로운 자유 공간이 되어, 그 둘과 여러 앱에서 업무를 넘겨받기도 하고 반대로 그 앱들에 업무를 내주기도 해요.

이제 졸업생 열 명을 뽑는 그 작은 회사는 AI가 구글 시트의 확장성을 높여 주니 훨씬 더 오래 쓸지도 몰라요. 아니면 시트를 Gemini의 데이터 저장소로 쓸 수도 있고요. 그러다 “Claude에게 뭘 만들어 달라고 할까, 아니면 노션으로 옮길까?” 하고 고민하는데… 그때 이 문제와 당신이 생각지 못한 다른 문제까지 풀어 주는, 바로 당신을 겨냥한 새 SaaS 앱이 눈에 띄는 거죠. AI는 질문을 바꾸지 않아요. 새로운 선택지를 만들고 문턱을 옮길 뿐이에요.

• • •

저는 이 모든 것이 지난 3년간의 기업 AI 도입 경험에서 보인다고 생각해요. 대기업마다 모두에게 Copilot(혹은 ChatGPT나 Claude)을 줬어요. 그런데 소수만 이걸 아주 많이 쓰고(그중 일부는 실제로 생산성이 올랐어요), 더 많은 사람은 일주일에 두어 번 쓰고, 나머지 대부분은 사실상 전혀 쓰지 않아요. 일부는 변화 관리와 교육의 문제지만, 대부분은 1983년에 전 직원에게 PC와 Lotus 1-2-3T4을, 1997년에 인터넷 연결과 웹 브라우저를 줬을 때 겪었을 문제와 같아요. 이것이 모두의 업무, 그리고 그들이 이번 주에 실제로 안고 있는 문제와 정확히 어떻게 이어질까요? 그래요, 모두에게 PC와 Lotus를 줬어요. 하지만 그게 송장 처리 효율을 바꾼 방법은 아니었어요. 모두에게 웹 브라우저를 줬어요. 하지만 그게 인터넷을 중심으로 공급망 관리를 다시 짠 방법은 아니었고, 소매업체가 전자상거래를 운영한 방법은 더더욱 아니었어요.

구체적으로 보면, 회사가 그런 구조적 프로세스를 바꾸려 할 때 흔히 떠올리는 방식은 파일럿을 시작하는 거예요. AI의 새로운 능력을 이용해 전에는 자동화할 수 없던 프로세스를 자동화하는 제품(사 온 것과 내부에서 만든 것 모두)을 시험해 보는 거죠. 이제는 이런 파일럿이 얼마나 많은지, 몇 개나 성공하는지(보통 그렇듯 대략 절반이에요. 그래서 파일럿이라고 부르는 거죠!), 무엇이 잘못될 수 있는지에 대한 온갖 데이터가 있어요.

그런데 이것 역시 유스케이스, 등대 프로젝트T5, 파일럿, 영웅, 빠른 성과, 측정 가능한 결과를 이야기하는 아주 구식 CIO식 대화예요. 그러는 사이 CEO와 이사회는 고개를 갸웃거리며 말해요. “잠깐, 워크플로가 수백 개인데 파일럿을 대여섯 개, 열 개 했다고? 이게 확장될 것 같지 않은데?” 모두에게 ChatGPT를 주는 건 이론적으로는 확장돼요. 다만 대부분의 사람이 정작 쓸 방법을 찾지 못할 뿐이죠.

1980년대에 모두에게 스프레드시트를 나눠 준 가상의 은행이나, 1990년대에 모두에게 웹 브라우저를 준 소매업체로 돌아가 볼게요. 그래요, 당연히 그렇게 해야 하고, 당연히 교육과 변화 관리를 비롯해 KPMG가 알려 줄 만한 다른 좋은 것들도 고민해야 해요. 하지만 그건 한 세대에 한 번 나올 새 기술을 두고 회사가 일하는 방식을 바꾸는 방법이 아니에요.

• • •

한 걸음 물러서서 보면, 변혁적인 새 기술이 나올 때마다 모든 회사는 세 종류의 질문을 던져야 하는 것 같아요. 첫째, 이걸 어떻게 사고, 만들고, 배포할까? 파일럿을 할까? Microsoft/Google/Oracle가 끼워 파는 제품을 쓸까, 직접 만들까, 누군가에게 돈을 주고 만들게 할까, 스타트업의 새 제품을 살까? 둘째, 이것이 우리 운영을 얼마나 바꿀까? 이것은 우리에게 무엇을 뜻할까? 이메일은 우리에게 무엇을 뜻했나? 스프레드시트는 우리에게 무엇을 뜻했나? 답은 보험사냐 로펌이냐에 따라 완전히 다를 수 있어요. 셋째, 이 기술이 사업의 경제성에 새로운 도전과 경쟁 압력을 불러오는지, 어쩌면 존립 자체를 위협하는지 물어야 해요.

이런 질문은 모두에게 Claude for X를 준다고 풀리지 않아요. 오히려 이 모든 것은 전문 서비스 업계에 새로운 영업 기회가 많이 생긴다는 뜻이에요(AI가 그들 자신의 사업 모델에 던지는 질문이 얼마나 많은지를 생각하면 아이러니하죠). 콜센터에 LLM 기반 음성 분석 도구를 어떻게 도입할지 알아내고 싶나요? 아마 Accenture에 전화하게 될 거예요. 벤더들은 늘 기꺼이 도와 왔고, 이제 대형 연구소들은 자체 ‘배포 전담 조직(deployco)’까지 갖고 있어요. 예전에 ‘머신러닝 과학자’는 샌프란시스코에 사는 통계학자라고 농담했는데, 그러면 ‘전진 배치 엔지니어’는 OpenAI가 시스템 통합 업체에서 데려온 아무나인지도 몰라요. 반대편에서, 당신의 스타트업이 멋진 새 도구를 만들고 있고 빨리 시장에 나가고 싶나요? 아마 빅4에 전화하게 될 거예요. 로펌이나 회계 법인에 AI 소프트웨어를 파는 게 너무 어려워서 답답한가요? 좋아요, ‘AI 기반’ 로펌을 직접 차려서 그게 핵심 지렛대가 될 수 있는지 알아보세요(아니면 1980년대에 ‘PC 기반 로펌’을 차리는 것과 비슷한 일인지도요). 그리고 물론 이사회라서 이것이 존립을 위협하는 일인지 엄청난 매출 기회인지 가려내야 한다면 Bain, BCG, McKinsey(혹은 동네에서 친한 M&A 은행가)에게 전화할 생각을 하겠죠. 그게 그들의 일이니까요.

• • •

하지만 이 모든 것에서 한 걸음 물러서 보면, 이 질문을 훨씬 단순하게 보는 방법도 있어요. 새로운 기술이 나오면 우리는 먼저 이미 하던 일에 쓰고, 그 일을 더 많이, 더 빨리 해요. 그러다 시간이 지나면 완전히 새로운 것을 만들어 내요. 우리는 AI로 기존 워크플로와 기존 회사 안의 넓은 범주의 일을 자동화할 거예요(다만 위에서 설명했듯 그건 모두에게 모델을 쥐여 주는 것보다 훨씬 더 많은 수고와 노력이 들어요). 하지만 지금까지의 모든 플랫폼 전환에서 정말로 중요했던 건 전에는 아예 불가능했고 아무도 상상하지 못했던 것이었어요.

역자 주

1. 빅 아이언(big iron): 원래 메인프레임 같은 대형 컴퓨터를 가리키던 말이에요. 여기서는 SAP나 Workday처럼 회사 전체의 핵심 기록을 쥐고 있는 거대한 기간 시스템을 비유해요. ↩

2. 전진 배치 엔지니어(FDE, forward-deployed engineer): 고객사에 직접 상주하며 현장 문제에 맞춰 제품을 붙이고 고치는 엔지니어예요. 데이터 분석 기업 Palantir가 널리 퍼뜨린 직군 이름이에요. ↩

3. SaaS 종말론(SaaSpocalypse): AI가 기존 SaaS 기업의 사업을 잠식해 주가와 가치가 무너질 거라는 시장의 우려를 가리키는 말이에요. ↩

4. Lotus 1-2-3: 1980년대에 PC 보급을 이끈 스프레드시트 프로그램이에요. 나중에 엑셀이 그 자리를 이어받았어요. ↩

5. 등대 프로젝트(lighthouse): 작게 먼저 성공 사례를 만들어 두고, 조직 전체가 따라 할 본보기로 삼는 시범 프로젝트를 말해요. ↩