AI를 사용하는 방식에서 사용자(그리고 그들이 속한 조직) 간 격차가 커지고 있으며, 특히 기업 환경에서 도구·정책·인프라 차이가 생산성의 차이로 이어진다는 점을 다룬 글.
URL: https://martinalderson.com/posts/two-kinds-of-ai-users-are-emerging/
AI 사용자의 차이가 이렇게까지 크다는 사실은 지금도 나를 놀라게 한다. 그리고 이 차이가, AI와 생산성 영향에 관한 (내게는 종종 혼란스러운) 미디어 보도의 많은 부분을 설명해 준다고 생각한다.
이제 내 눈에는 AI 사용자(그리고 그들이 일하는 조직)들이 명확히 두 부류로 나뉘어 보인다.
첫째는 “파워 유저(power users)”다. 이들은 Claude Code, MCP, 스킬 등 새로운 AI 기술을 적극적으로 받아들인다. 놀랍게도 이런 사람들은 종종 기술적인 배경이 거의 없다. 나는 기대했던 것보다 훨씬 많은 비(非)기술 직군이 터미널에서 Claude Code를 쓰는 모습을 봤고, 소프트웨어 엔지니어링이 아닌 작업에도 수십 가지 방식으로 활용하는 것을 봤다. 특히 금융 직무가 엄청난 가치를 뽑아내는 듯하다(전혀 놀랍지 않은데, 금융 쪽에서 쓰는 Excel은 프로그래밍 생태계—예를 들어 Python—의 힘에 익숙해지기 시작하면 놀라울 정도로 제약이 많기 때문이다).
둘째는 대체로 ChatGPT나 비슷한 도구로 ‘대화’만 하는 사람들이다. 내가 그럴 줄 몰랐던 정말 많은 사람들이 여전히 이 범주에 있다.
가장 당혹스러운 깨달음 중 하나는 Microsoft Copilot이 얼마나 형편없는지였다. Copilot은 여러 Office 365 구독에 번들로 묶여 있어 엔터프라이즈에서 엄청난 점유율을 가지고 있지만, (이미 그리 좋지 않은) ChatGPT 인터페이스를 조악하게 복제한 것 같은 느낌이다. “에이전트(agent)” 기능은 CLI 코딩 에이전트(심지어 이름이 혼란스럽게도 Copilot인 마이크로소프트의 GitHub Copilot CLI까지 포함해서)와 비교하면 정말 웃음이 나온다.
이 점을 더 분명히 보여주는 사례로, 마이크로소프트는 (당연히) 거의 0에 가까운 비용으로 Copilot을 사용할 수 있고 OpenAI에 대한 상당한 지분도 보유하고 있음에도 내부 팀에 Claude Code를 배포하고 있다[1]. 이 한 가지가 그들이 얼마나 뒤처져 있는지를 요약해 준다고 생각한다.
문제는 기업 환경에서 Copilot이 종종 유일하게 허용된 AI 도구라는 점이다. 그래서 다른 도구를 쓰려면 해고 위험을 감수하거나, 혹은 다른 AI 도구를 조달하고 사용하기 위해 많은 노력을 들여야 한다. Copilot은 느리고, 안에 들어 있는 코드 실행 도구는 제대로 작동하지 않으며, (조금만) 큰 파일을 처리하면 끔찍하게 실패한다. 아마도 메모리와 CPU 제한을 매우 매우 공격적으로 걸어둔 탓인 듯하다.
이것은 많은 기업에게 실존적 위험이 되어가고 있다. 고위 의사결정자들이 이런 형편없는 도구를 써 보고는 결과가 나쁘니 AI를 ‘쓸모없다’고 치부해 버리거나, 아니면 대형 컨설팅/경영 컨설팅 회사에 막대한 비용을 지불하고도 별 진척을 못 내는 상황이 벌어질 수 있다.
엔터프라이즈의 기업 IT 정책은, 사람들이 더 ‘최첨단’ AI 도구를 성공적으로 쓰지 못하도록 만드는 완전히 재앙적인 제약들의 조합을 만들어낸다.
첫째, 이들은 대개 매우 강하게 잠긴(locked down) 환경을 갖고 있어서 로컬에서 기본적인 스크립트 인터프리터조차 실행할 수 없다(운이 좋으면 VBA 정도지만, 그것조차 각종 그룹 정책에 의해 제한될 수 있다). 둘째, 핵심 업무 흐름에서 사실상 “내부용” API가 없는 레거시 소프트웨어에 묶여 있다. 즉, 에이전트를 돌릴 수 있다 해도 연결할 대상이 없다.
마지막으로, 엔지니어링 조직이 극도로 사일로화되어 있는 경우가 많고(아예 외주화돼 있을 수도 있다), 그래서 설령 원하더라도 안전하게 샌드박싱된 에이전트를 실행할 인프라를 내부에서 만들 사람이 없다.
보안 우려는 현실이다. 통제 없이 코딩 에이전트를 운영 데이터베이스에 ‘YOLO’로 던져 넣는 건 절대 원치 않는 일이며, 내가 이전에 다뤘듯이, 에이전트를 샌드박싱하는 일은 어렵다[2].
하지만 그렇다고 해도, 안전하게 샌드박싱된 에이전트를 자사 데이터셋에 붙여 돌릴 수 있는 인프라를 만들도록 도와줄 엔지니어링 팀이 없다는 점은 매우 큰 문제를 낳는다.
반대로, 이런 짐(baggage)이 없는 더 작은 회사들과도 많이 이야기해 봤는데, 그들은 AI로 말 그대로 날아다닌다. 양쪽을 모두 보면 격차가 너무나 분명하다.
한쪽에는 Excel을 위한 마이크로소프트의 (형편없는) Copilot 통합이 있다(공정하게 말하자면 Google Sheets의 Gemini 통합도 나쁘다). 그러니 재무 이사들이 그걸 써 보다가 가장 단순한 작업조차 엉망으로 만들고는 다시는 손대지 않게 되는 모습을 상상할 수 있다.
다른 한쪽에는 Claude Code를 이해하고 로컬에서 예를 들어 Python을 실행할 수 있는 비기술 임원이 있다. 나는 최근 한 사람을 도와, Claude Code로 30개 시트에 걸친 정신이 아득해질 정도로 복잡한 Excel 재무 모델을 Python으로 거의 한 번에[3] 변환하도록 했다.
모델이 Python으로 들어가면, Claude Code와 함께 사실상 ‘주머니 속 데이터 사이언스 팀’을 갖게 된다. 몬테카를로 시뮬레이션을 쉽게 돌릴 수 있고, 외부 데이터 소스를 입력값으로 끌어올 수 있으며, 웹 대시보드를 만들 수도 있고, Claude Code와 함께 모델(또는 비즈니스)의 약점을 정말로 파고들며 개선할 수도 있다. Excel에서 몇 시간/며칠을 갈아 넣지 않고도, 손끝에 엄청난 힘이 있음을 깨닫는 장면을 보는 건 꽤 마법 같은 경험이다.
결과적으로 작은 회사의 직원들이 엔터프라이즈의 동급 역할 담당자보다 훨씬 더 생산적일 수 있는 상황이 된다. 예전에는 작은 회사 사람들이 큰 경쟁사가 가진 자원과 팀을 부러워하는 경우가 많았지만, 점점 더 저울추가 반대편으로 기울고 있다고 생각한다.
나는 점점 ‘일의 미래’가 어떤 모습일지 감을 잡아가고 있다. 첫 번째 관찰은, (종종) 진짜 도약은 위에서 내려오는 AI 전략이 아니라 직원들에 의해 유기적으로 만들어진다는 점이다. 내가 보는 실질적인 생산성 향상은, 작은 팀이 어떤 프로세스에 대해 AI 보조 워크플로우를 시도해 보기로 결정하고, 그들이 그 프로세스를 속속들이 알고 있기 때문에 매우 좋은 결과를 얻는 데서 나온다. 이는, 자신들이 자동화하려는 프로세스를 해본 적이 전혀 없는(그리고 종종 외주화된) 소프트웨어 엔지니어링 팀과는 정반대다. 나는 이것이 엔터프라이즈의 대부분 ‘디지털 전환’ 프로젝트가 생김새였던 것과 반대라고 본다.
두 번째로, 내부 시스템에 대해 어떤 형태로든 API를 가진 회사는 그렇지 않은 회사보다 훨씬 더 많은 일을 해낼 수 있을 것이다. 이는 직원들이 연결해 사용자 대신 쿼리를 실행할 수 있는 읽기 전용 데이터 웨어하우스처럼 단순한 것일 수도 있고, 여러 복잡한 핵심 비즈니스 프로세스가 완전히 API화되는 수준까지 갈 수도 있다.
세 번째로, 이 모든 것은 어떤 형태로든 보안 메커니즘으로 감싸져야 한다. 하지만 적어도 읽기 전용 리포팅의 경우, 잘 설계된 네트워크 제한을 둔 호스티드 VM에서 어떤 코드 에이전트를 실행하는 방식이 꽤 잘 작동할 거라고 본다. 데이터를 생성·편집하는 경우에는, 비기술 사용자(특히)가 에이전트를 안전하게 사용할 수 있는 모델이 (아직) 완전히 갖춰졌다고 보지 않는다.
마지막으로, 레거시 엔터프라이즈 SaaS 플레이어들은 관점에 따라 엄청난 락인(lock-in)을 갖고 있거나, 혹은 극도로 취약하다. 대부분은 “API-퍼스트” 제품이 아니고, 그들이 가진 API도 대개 개발자 사용을 위한 것이다. 수천 명의 직원들이 이상하고도 비효율적인 방식으로 마구 호출하도록 최적화돼 있지 않다. 하지만 그 제품이 회사의 ‘단일 진실 공급원(source of truth)’이라면, 다른 것으로 옮기기 매우 어렵고 동시에 많은 생산성 향상을 병목시킬 것이다.
다시 말하지만, 작은 회사들은 대체로 더 최신 제품을 쓰는 경향이 있고, 그런 제품들은 API가 훨씬 더 잘 설계돼 있다(대개 수십 년 전에 만들어지고 시간이 지나며 인터페이스가 덧붙여진 제품이 아니기 때문이다).
사용자가 프롬프트를 주면, 에이전트가 종합한다—API에 연결하고 필요할 때 결과물을 만들어낸다.
내가 깨달은 바는, 프로그래밍 언어와 시스템에 대한 API 접근을 갖춘 bash 샌드박스에 에이전틱 하네스(agentic harness)가 결합되면, 비기술 사용자에게도 터무니없이 좋은 결과를 낸다는 점이다. 이는 사실상 거의 모든 표준 생산성 앱을 대체할 수 있다—전통적인 Microsoft Office 스타일 앱은 물론이고 웹 앱까지도. 원하는 어떤 리포트든 만들 수 있고, 원하는 형식으로 내보낼 수도 있다. 내게 이것은 지식 노동의 미래처럼 보인다.
이러한 양극화는 현실이며, 오히려 극적으로 더 빨라지고 있는 것 같다. 역사상 이렇게 작은 팀이 자기보다 1,000배 큰 회사를 이렇게 쉽게 능가할 수 있었던 시기가 있었나 싶다.
