이 글은 AI가 기업 내 수많은 소프트웨어와 반복 업무를 한 번에 쓸어버릴 것이라는 통념에 반박합니다. 대부분의 사람은 도구를 만드는 사람이 아니며, 무엇을 자동화해야 할지 문제 자체를 발견하는 것이 진짜 어려운 부분이기 때문입니다. 코드 작성이 쉬워진다고 해결되는 문제가 아니라, '도구가 필요하다는 사실을 아는 것'이 핵심 과제라는 점이 이 글의 요지입니다.
번역된 본문
AI, 도구, 그리고 변화 오늘날 전형적인 미국 대기업에는 수백 개, 어쩌면 수천 개의 서로 다른 소프트웨어가 있다. SAP나 Workday 같은 거대한 '빅 아이언(big iron)' 수평형 기록 시스템이 있고, 수백 개의 수직형 SaaS 애플리케이션이 있으며, 그 밖에도 수백 개의 워크플로우, 스크립트, 자동화 도구, 데이터베이스가 있고, 부서 하나를 굴리는 10메가짜리 스프레드시트까지 있다. 회사는 자기가 보유한 소프트웨어가 정확히 얼마나 되는지, 무엇이 실제로 쓰이고 있는지, 무엇에 비용을 지불하고 있는지조차 모르는 경우가 아주 많다. 그런데 이 모든 소프트웨어가 있음에도 회사는 지루하고 반복적인 업무로 가득하다. AI가 이 대부분을 쓸어버릴 것이라고 생각하기 아주 쉽다. 10분 걸릴 작업을 자동화하는 도구를 만드는 데 한 시간을 쓰는 사람이 엔지니어라는 오래된 농담이 있다. 하지만 AI 시대에는 그 도구를 5분 만에 만들 수 있고, 엔지니어일 필요도 없고, 코드를 쓸 필요도 없다. 모델에게 도구를 만들어 달라고 부탁하거나, 더 근본적으로는 작업 자체를 그냥 수행해 달라고 하면 된다. 도구를 하나씩 만들 필요 없이, 소프트웨어는 동적이고, 생성적이며, 자유롭고 즉흥적인 것이 될 수 있다. 훨씬 적은 소프트웨어로 훨씬 많은 작업을 자동화할 수 있다. 당신이 도구 제작자라면, 그리고 실리콘밸리의 모든 사람이 도구 제작자라면, 이것은 취할 듯 매혹적이다. 하지만 나는 이런 생각이 소프트웨어가 어디서 오는지, 사람들이 그것을 어떻게 사용하는지 잘못 이해하고 있다고 생각하며, 회사가 어떻게 변하는지도 놓치고 있다고 본다. 첫째, 대부분의 사람은 도구 제작자가 아니며, 자기 일을 다른 방식으로 할 수 있는지 본능적으로 생각하지 않는다. 실리콘밸리 거품 속에서만 시간을 보내면 이 사실을 잊기 쉽다. 왜냐하면 그곳의 세계 전체가 일하는 방식을 바꾸는 도구를 만드는 것에 관한 것이기 때문이다. 하지만 정말 훌륭한 혼인 전문 변호사라면 하루 종일 자기 사건과 의빽인에 대해 생각하지, 훌륭한 증거개시(legal discovery) 소프트웨어가 어떤 역할을 할지 생각하지 않는다. 정말 훌륭한 기업 영업사원이라면 온종일 제품과 고객과 경쟁사에 대해 생각하지, 훌륭한 세일즈 인에이블먼트 소프트웨어가 어떻게 생산성을 높여줄지 생각하지 않는다. Excel 같은 제품은 온보딩 플로우, 어시스턴트, 템플릿으로 이 문제를 해결하려 한다. '파일/새로 만들기'에서 보이는 모든 것이 이걸 할 수 있다는 제안이다. 하지만 그 템플릿 하나하나는 여전히 회사가 되었고, Claude for X 같은 것에서도 같은 걸 본다. 도움은 되지만 정답은 아니다. 좁게 보면, 자동화해야 할 작업이 눈앞에 있는데도 그 작업을 가진 사람들은 그것을 보지 못한다는 뜻이다. 여기서 '전방배치 엔지니어(forward-deployed engineer)'라는 개념이 나온다. 빌더이면서 AI가 무엇을 만들 수 있는지 아는 사람이 로펌이나 건축사무소를 돌아다니며 변호사나 건축가가 보지 못하는, 탁자 위에 놓인 기회를 '그냥' 발견할 수 있다는 것이다. (이것은 15살 때 인턴십이나 부모의 사무실을 돌아다니며 많은 기술자들이 겪은 경험이기도 하다. "음, 아빠, 이렇게 하면 되는 거 알아?") 더 깊은 문제는, 지난 수십 년간 우리가 자동화한 것의 대부분은 설령 당신이 도구 제작자라 해도 명확하지 않았고, 명백한 해결책도 없었다는 점이다. 우리 모두 매일 쓰는 것들 중 처음 반응이 '이게 왜 필요하지?'였던 예를 떠올릴 수 있다. 문제가 존재한다는 것 자체가 명확하지 않은 경우가 아주 많고, 그것은 다른 무언가 안에 내장되거나 묶이거나 숨겨져 있는 경우가 많다. 마찬가지로, 문제가 보이거나 보인다고 생각하더라도 그것을 고칠 올바른 방법도 명확하지 않은 경우가 많다. 해결책은 문제를 재정의하거나 언번들(분리)하는 것이며, 그걸 알아내는 것은 어렵다. 많은 성공한 소프트웨어 회사 앞에는, 제대로 된 접근법이나 문제를 찾지 못한 채 실패한 시도 여섯 개가 있었다. 이 모든 것은 코드를 쓰기 쉽게 만들고, 도구를 만들기 쉽게 만든다고 해결되지 않는다. 어려운 부분은 이 일에 도구가 필요하다는 걸 아는 것이다.
AI, tools and transformation The typical big American company today has hundreds, and perhaps thousands, of different pieces of software. It has giant ‘big iron’ horizontal systems of record like SAP and Workday, it has hundreds of vertical SaaS applications, and then there are hundreds more workflows, scripts, automations and databases, right down to the 10 meg spreadsheet running a department. Very often, the company doesn’t even know quite how much it has, what’s actually being used, and what it’s paying for. And yet, with all this software, the company is full of boring, repetitive tasks. It can be very tempting to think that AI will sweep most of this away. There’s an old joke that an engineer is someone who’ll spend an hour building a tool to automate a task that would take 10 minutes. But with AI, now you can make that tool in five minutes, and you don't need to be an engineer, and you don’t need to write code. You can just ask the model to make the tool for you, or, more fundamentally, just do the task for you itself . Instead of having to create those tools one at a time, software might be dynamic, generative, free-form, and spontaneous. Massively more tasks can be automated, with massively less software. If you’re a tool-builder, and everybody in Silicon Valley is a tool-builder, this is intoxicating. But I think it misunderstands where software comes from and how people use it, and I think it misses how companies change. First of all, most people are not tool builders, and most people don’t instinctively think about how their job could be done in a different way. If you spend all your time in the Silicon Valley bubble, it can be easy to forget this, because your entire world is about creating tools that change how things are done. But if you’re a really great matrimonial lawyer, you spend all your day thinking about your cases and your clients, not about what great legal discovery software would do; if you’re a really great enterprise salesperson, you spend all your time thinking about your product and your clients and your competitors, not about how great sales enablement software could make you more productive. Products like Excel try to bridge this problem with on-boarding flows, assistants, and templates - everything you see in ‘File/New’ is a suggestion for what you could do with this. But every one of those templates still became a company, and that’s what I see in things like Claude for X as well - this is helpful, but not the answer. Narrowly, that means that the task to be automated might be sitting in plain sight but the people with that task don’t see it. This is what leads to the idea of the ‘forward-deployed engineer’ - someone who is a builder, and knows what AI can build, can ‘just’ walk around a law firm or an architecture office and see the opportunities lying on the table that the lawyer or the architect doesn't see. (This is also the experience of a lot of people in tech when they were 15, wandering around an internship or their parents’s office - “um, daddy, did you realise you could just do it like this?”). The deeper problem is most of what we’ve automated in the last few decades wasn’t obvious, even if you are a tool-builder, and didn’t have an obvious solution either. We can all think of examples of stuff we use every day where our first reaction was “Why would I want that?” Very often, it's not obvious that the problem exists, and very often it's embedded or bundled or hidden inside something else. Equally, even if you can see the problem, or think you can, the right way to fix it often isn’t clear either, and the way to fix it is to redefine it or unbundle it, and working that out is hard. For many successful software companies, there were half a dozen failed attempts that came before and didn't find quite the right approach or the right problem. None of this is solved by making easier to write code - by making it easier to make tools. The hard part is knowing that you need a tool for this in the first place, and then knowing what the tool should do. But even once you reach that point, you have to get everybody else to use it, too. Many of the problems, workflows and tasks that we might want to automate touch 50 or 500 people across five different departments, three different systems of record, and four different regulatory regimes. You might have a great idea for doing an accounts payable differently, but you yourself can't change how everybody in the company does it. That has to be a purchase, and a decision, and an 18-month sales process. Second, all of this means that software is bought or chosen or created on a spectrum from top-down to bottom-up - the company buys SAP and the user makes a spreadsheet - and I think it’s useful to think of this also as a spectrum from institutionalised to improvised. You have tasks that are easy to do in the dedicated tools you already have, whether it’s SAP, Carta or Rippling. These tasks and workflows have been institutionalized - a bunch of people in those companies and your company have spent a lot of time working out the correct way to do that task, and it’s important that everyone do it the same way with the same tools. But then you have edge cases, exceptions and one-off questions, that are hard or impossible to do in those tools. Your users, bottom-up and creating their own solutions, manage these in a fuzzy, improvised space of freeform substrates like Excel, email, shared folders, Tableau, Powerpoint and CSVs, screenshots, PDFs and conference calls. But once this task becomes something that you're doing all the time, in the same way every time, and that lots of people are doing, and becomes important and has revenue and risk attached to it, then, at a certain point, the company has to institutionalize it. You need audit, security, maintenance and accountability. You pave the desire path and pay someone to set it in stone. As above, you might not realize that the path is there - you might not realise that you have hundreds of people wasting an hour a day doing this - and it might be hard to work out the right way to fix that, but that process is why the company has hundreds of apps. We went though a lot of this with the shift to SaaS, which was another order-of-magnitude change in how much software we had, along with a new operating model and a new cycle time, and that killed a lot of incumbents that couldn’t make the jump (the real rationale for the ‘SaaSpocalypse’). It’s a continuous and organic flow of bundling and unbundling. All of those SaaS apps do something that you could do in SAP or Excel or email - Carta is a $4bn company that manages one spreadsheet for your CFO - and sometimes tasks move back. A few years ago I spoke to a consultant who said that half of their jobs were telling people who used Excel to use a database and the other half were the other way around. Hence, if you’re PwC and you hire 3-4,000 graduates every year, you use dedicated, ‘institutionalised’ software to manage that. If you’re a small firm and you hire five or ten, you use email, a shared folder and Google Sheets. As that small firm grows, at a certain point it will outgrow that, and maybe move to Notion, or to an SME-focused SaaS HCM. But a small team inside PwC might also be using Google Sheets to track candidates to fill a role because Workday is too inflexible - the unbundling begins again. Now AI rolls across all that. AI will expand all of the existing apps, and there’ll be many new vertical apps, and Excel, and Tableau, Google Sheets, email and all the other freeform spaces for improvising solutions will gain new capabilities. With that cycle, the chatbot itself is a new freeform space that sits next to Excel and email, taking over tasks from them and from your apps, and also losing tasks to those apps. Now that small company hiring ten graduates might stick in Google sheets a lot longer because AI makes it more scalable, or you might use it as a data store for Gemini, and yo