AI를 '쓰는' 것과
AI로 '일하는' 것의 차이
Agentic Flow가 만드는 생산성 대분기
1. AI로 일한다는 것의 진짜 의미: 검색의 진화인가, 노동의 소멸인가
지금 전 세계적으로 AI를 도입했다는 기업과 개인이 급증하고 있다. 그런데 이상한 일이 벌어지고 있다. 한쪽에서는 AI 덕분에 생산성이 5배에서 20배까지 향상되었다고 말하고, 다른 한쪽에서는 AI를 도입했지만 별다른 효과를 못 느끼겠다고 말한다. 언론 보도도 마찬가지로 혼란스럽다. 어떤 기사는 AI가 모든 것을 바꿀 것이라 하고, 바로 옆 기사는 AI 생산성 효과가 과장되었다고 주장한다. 같은 기술을 두고 왜 이렇게 극단적으로 다른 평가가 나오는 것일까.
그 답은 놀라울 정도로 단순하다. 'AI로 일한다'는 말의 정의가 사람마다 완전히 다르기 때문이다. 대부분의 사람들에게 AI를 쓴다는 것은 예전에 구글에 검색하던 것을 ChatGPT에게 물어보는 것을 의미한다. 궁금한 게 있으면 질문하고, 답변을 읽고, 그 정보를 바탕으로 자신이 직접 작업한다. 이메일을 써달라고 하거나, 요약을 부탁하거나, 아이디어를 브레인스토밍하는 식이다. 이것은 분명히 유용하다. 하지만 이것은 본질적으로 검색 도구가 조금 더 똑똑해진 것에 불과하다. 구글링의 진화이지, 일하는 방식의 변화가 아니다.
진짜 AI로 일한다는 것은 완전히 다른 차원의 이야기다. 그것은 에이전트 흐름(Agentic Flow)를 설계해서, 이전에 사람이 직접 수행하던 업무를 AI Agent가 처리하게 만드는 것이다. 그 일은 여전히 이루어진다. 보고서는 만들어지고, 데이터는 분석되고, 재무 모델은 돌아간다. 하지만 더 이상 사람이 그 일을 하지 않는다. 사람은 어떤 일이 이루어져야 하는지를 정의하고, Agent가 그 일을 수행한다. 이것이 핵심적인 차이다.
예를 들어보자. 한 금융 담당자가 매주 월요일 아침마다 엑셀 파일 다섯 개를 열어서 수치를 취합하고, 피벗 테이블을 만들고, 차트를 그리고, 그 결과를 파워포인트에 붙여서 경영진에게 보고했다고 하자. AI를 쓴다는 첫 번째 방식에서 이 사람은 ChatGPT에게 물어볼 수 있다. 이 데이터를 어떤 차트로 보여주면 좋을까. 피벗 테이블 함수를 어떻게 쓰는 거지. 이 정도의 도움은 받을 수 있다. 하지만 여전히 엑셀을 직접 열고, 수치를 직접 복사하고, 차트를 직접 만들고, 파워포인트에 직접 붙이는 것은 사람이다.
두 번째 방식에서 이 사람은 전혀 다른 접근을 한다. Claude Code나 유사한 Agentic 도구를 사용해서, 다섯 개 엑셀 파일을 자동으로 읽어 들이고, 데이터를 정제하고, 분석을 수행하고, 시각화를 만들고, 보고서를 자동 생성하는 전체 워크플로우를 설계한다. 한 번 설계해두면 매주 월요일 아침 프롬프트 한 줄로 전체 보고서가 완성된다. 그 일은 여전히 이루어지지만, 사람이 더 이상 그 일을 하지 않는다.
이 두 가지 접근의 생산성 차이는 비교 자체가 무의미할 정도로 크다. 첫 번째 방식은 기존 작업 시간을 10퍼센트에서 20퍼센트 정도 줄여줄 수 있다. 두 번째 방식은 그 작업에 들어가던 시간 자체를 거의 제로에 가깝게 만든다. 미디어에서 AI 생산성 효과에 대한 엇갈린 보도가 나오는 이유가 바로 여기에 있다. 첫 번째 방식만 경험한 사람에게 AI 생산성 효과는 실망스럽다. 두 번째 방식을 경험한 사람에게 AI는 말 그대로 게임 체인저다. 이들은 같은 도구를 쓰고 있지만, 완전히 다른 세계에 살고 있는 것이다.
2. 두 부류의 사용자: Chat User와 Flow Designer
현장에서 관찰되는 AI 사용자는 크게 두 부류로 나뉜다. 편의상 Chat User와 Flow Designer라고 부르자. 이 구분은 기술적 역량의 차이가 아니다. 일에 대한 인식의 차이다.
Chat User는 AI를 똑똑한 대화 상대로 사용한다. ChatGPT, Claude, Gemini 같은 채팅 인터페이스를 열고 질문을 입력하고 답변을 받는다. 이메일 초안을 써달라고 하고, 보고서를 요약해달라고 하고, 코드 에러를 설명해달라고 한다. 이 방식은 분명히 가치가 있다. 하지만 본질적으로 이 사용자는 자신의 업무 프로세스를 그대로 유지한 채, 중간중간 AI를 보조 도구로 활용하는 것이다. 구글에서 검색하고 Stack Overflow를 참고하던 것이 ChatGPT에게 물어보는 것으로 바뀌었을 뿐, 일하는 방식 자체는 변하지 않았다.
Flow Designer는 근본적으로 다르게 접근한다. 이들은 AI를 대화 상대가 아니라 자신을 대신해서 일하는 Agent로 본다. Claude Code 같은 CLI 기반 코딩 에이전트를 활용해서 Python 스크립트를 짜고, API를 연결하고, 전체 워크플로우를 자동화한다. 이들에게 AI와의 대화는 목적이 아니라 수단이다. 대화를 통해 Agent가 수행할 작업을 정의하고, Agent가 그 작업을 실행하고, 결과물이 자동으로 생산된다.
놀라운 사실은 Flow Designer 중 상당수가 전혀 기술적인 배경이 없다는 것이다. 현장에서 관찰하면, 비기술직 종사자들이 터미널에서 Claude Code를 돌리고 있는 모습을 예상보다 훨씬 많이 보게 된다. 특히 금융 분야가 두드러진다. 재무 담당자, CFO, 애널리스트들이 Excel의 한계를 뚫고 Python 생태계의 힘을 활용하기 시작했다. 이들은 프로그래밍을 배운 것이 아니다. Agent에게 무엇을 만들어야 하는지를 설명하는 법을 배운 것이다.
이 차이가 만들어내는 격차는 실로 충격적이다. 한 비기술직 경영진이 Claude Code를 활용해서 30개 시트로 구성된 극도로 복잡한 Excel 재무 모델을 Python으로 전환한 사례가 있다. 두세 번의 프롬프트로 해냈다. Plan 모드를 사용해서 Excel 시트의 구조를 먼저 파악하게 하고, 그다음에 구현을 지시했다. Agent는 Python 모델 안에 유닛 테스트까지 자동으로 추가했다. 이전 같았으면 데이터 사이언스 팀에게 몇 주에 걸쳐 의뢰해야 할 작업이었다.
두 부류의 차이를 더 선명하게 이해하기 위해 동일한 업무 상황을 두 가지 접근으로 비교해보자. 분기별 실적 분석 보고서를 만들어야 한다고 하자. Chat User는 ChatGPT를 열고 이렇게 물을 것이다. 분기 실적을 분석하는 좋은 프레임워크가 뭐야. 이 수치를 어떻게 해석하면 좋을까. 보고서 목차를 제안해줘. 그리고 이 답변을 참고해서 직접 Excel을 열고, 직접 수치를 넣고, 직접 워드로 보고서를 쓴다. AI가 도와주긴 했지만, 모든 실행은 여전히 사람의 몫이다.
Flow Designer는 완전히 다르다. 이전 분기 데이터 파일을 지정하고, Agent에게 이렇게 지시한다. 이 데이터를 읽어서 전분기 대비 변화율을 분석하고, 주요 이상치를 식별하고, 시각화를 만들고, 경영진 보고 형식의 PDF 리포트로 출력해. Agent는 Python으로 데이터를 처리하고, 통계 분석을 수행하고, 차트를 생성하고, 완성된 리포트를 출력한다. 사람이 한 것은 무엇을 원하는지 정의한 것뿐이다. 실행의 전 과정은 Agent가 수행했다. 이것이 Chat User와 Flow Designer의 본질적 차이다. 질문하는 사람과 설계하는 사람의 차이다.
3. Microsoft Copilot이라는 거대한 착각: 왜 엔터프라이즈는 Chat User에 갇혔는가
AI 생산성 격차를 이해하는 데 있어 Microsoft Copilot의 역할은 결정적이다. 엔터프라이즈 시장에서 압도적인 시장 점유율을 가진 이 제품이, 역설적으로 수많은 기업과 의사결정자들이 AI의 잠재력을 과소평가하게 만드는 핵심 원인이 되고 있기 때문이다.
M365 Copilot은 다양한 Office 365 구독에 번들로 포함되어 엔터프라이즈에 거대한 시장 점유율을 확보했다. 문제는 이 제품의 품질이다. 현장에서의 반응은 한결같이 충격적일 정도로 부정적이다. 인터페이스는 이미 그다지 뛰어나지 않은 ChatGPT 인터페이스를 조악하게 복제한 느낌을 준다. Agent 기능은 CLI 기반 코딩 에이전트와 비교하면 실소가 나올 수준이다. 코드 실행 도구는 제대로 작동하지 않으며, 약간이라도 큰 파일을 처리하려 하면 극도로 공격적인 메모리 및 CPU 제한 때문에 처참하게 실패한다. 속도도 느리다.
아이러니의 극치는 Microsoft 자신의 행동에서 드러난다. Microsoft는 내부 팀들에게 Claude Code를 배포하고 있다. OpenAI에 막대한 투자를 하고 있고, 자체적으로 Copilot을 거의 무비용으로 사용할 수 있음에도 불구하고, 자사의 GitHub에서도 혼란스럽게도 Copilot이라는 이름을 쓰는 CLI 도구가 아닌 Anthropic의 Claude Code를 내부적으로 도입한 것이다. 자사 제품을 파는 회사가 내부에서는 경쟁사 제품을 쓴다는 것은, 그 제품이 얼마나 뒤처져 있는지를 이보다 더 명확하게 보여주는 증거가 없다.
진짜 문제는 그다음에 발생한다. 많은 엔터프라이즈에서 Copilot은 유일하게 허용된 AI 도구다. 다른 AI 도구를 사용하면 직장을 잃을 위험이 있거나, 다른 도구를 조달하고 승인받기 위해 엄청난 노력을 들여야 한다. 결과적으로 수천, 수만 명의 직원들이 이 제한적인 도구만을 경험하게 된다.
여기서 구조적인 악순환이 시작된다. 기업의 의사결정자들, 즉 C레벨 경영진, VP, 디렉터 등이 Copilot을 직접 써본다. Excel에서 Copilot에게 데이터 분석을 시켜보면 가장 단순한 작업에서도 엉뚱한 결과를 내놓는다. 워드에서 문서 작성을 시켜보면 품질이 기대에 한참 못 미친다. 이 경험을 바탕으로 이들은 자연스럽게 결론을 내린다. AI는 아직 쓸 만한 수준이 아니다. 이 결론은 틀렸다. 하지만 이들이 접한 AI의 유일한 경험이 Copilot이라면, 이런 결론에 도달하는 것은 충분히 합리적이다.
그 결과 두 가지 방향으로 흘러간다.
첫째, AI 투자 자체를 축소하거나 유보한다. AI는 과대평가되었다, 우리 산업에는 아직 적용하기 이르다, 라는 판단이 경영 회의에서 지지를 받는다.
둘째, 대형 컨설팅 회사에 막대한 비용을 들여 AI 전략 수립을 의뢰한다. 문제는 이 컨설팅 회사들 역시 같은 엔터프라이즈 환경의 제약 안에서 작업하기 때문에, 결국 번드르르한 전략 문서만 남기고 실질적인 생산성 향상으로 이어지지 못하는 경우가 대부분이라는 것이다.
한편 Google의 Gemini와 Google Sheets의 통합도 솔직히 좋지 않다. 이것은 Microsoft만의 문제가 아니라, 기존 생산성 도구 위에 AI를 얹으려는 접근 방식 자체의 한계일 수 있다. 레거시 소프트웨어의 제약 안에서 AI의 능력을 발휘하게 하는 것은 태생적으로 한계가 있다. AI의 진짜 힘은 Excel 안에서 AI를 쓰는 것이 아니라, Excel이라는 도구 자체를 넘어서는 데서 나온다. 하지만 Copilot은 구조적으로 사용자를 Chat User 모델에 가두어놓는다. 물어보고 답변받는 것, 그것이 이 제품이 허용하는 AI 활용의 전부이기 때문이다.
4. 엔터프라이즈의 3중 족쇄: Agentic Flow가 불가능한 구조적 이유
Copilot의 품질 문제를 넘어서, 엔터프라이즈 환경 자체가 Agentic Flow의 작동을 구조적으로 불가능하게 만드는 세 가지 족쇄를 가지고 있다. 이것은 개별 도구의 문제가 아니라 기업 IT 정책 전반의 문제이며, 이 세 가지가 결합되면 완전히 재앙적인 결과를 낳는다.
첫 번째 족쇄: 잠겨있는 로컬 환경
Agentic Flow가 작동하려면 가장 기본적으로 코드를 실행할 수 있는 환경이 필요하다. Agent가 Python 스크립트를 작성하고 실행해서 데이터를 처리하고, 결과물을 생성해야 하기 때문이다. 그런데 대부분의 엔터프라이즈는 직원의 로컬 환경을 극도로 잠가놓는다. 기본적인 스크립트 인터프리터조차 실행할 수 없다. 운이 좋으면 VBA 정도를 쓸 수 있지만, 그마저도 Group Policy로 제한되어 있는 경우가 많다. Python 설치는 당연히 불가능하고, Node.js도, 어떤 개발 환경도 허용되지 않는다. 이 상태에서 Agent가 할 수 있는 일은 없다. 아무리 뛰어난 AI Agent를 도입한다 해도, 코드를 실행할 수 없으면 결국 Chat User 모드, 즉 질문하고 답변받는 것 이상을 할 수 없다.
두 번째 족쇄: 내부 API의 부재
설사 코드를 실행할 수 있다고 해도, Agent가 연결할 대상이 없으면 의미 있는 자동화는 불가능하다. 엔터프라이즈의 핵심 업무 시스템들, 즉 ERP, CRM, 재무 시스템, HR 시스템 등은 대부분 수십 년 전에 구축된 레거시 소프트웨어다. 이들은 내부를 향한 API가 없다. 정확히 말하면, 사람이 화면을 보고 클릭하고 입력하는 것을 전제로 설계되어 있어서, 프로그래밍 방식으로 접근할 수 있는 인터페이스가 제공되지 않거나 극히 제한적이다. Agent는 API를 통해 시스템에 접속하고, 데이터를 읽고, 작업을 수행한다. API가 없으면 Agent는 아무리 똑똑해도 시스템에 접근조차 할 수 없다. 마치 문이 잠긴 방 앞에 서 있는 전문가와 같다. 실력은 뛰어나지만 방에 들어갈 수 없으면 아무것도 할 수 없다.
세 번째 족쇄: 아웃소싱된 엔지니어링 역량
그러면 이 두 가지 문제를 해결할 내부 엔지니어링 팀이 있으면 되지 않느냐고 물을 수 있다. 안전하게 샌드박싱된 Agent 실행 환경을 구축하고, 레거시 시스템에 API를 만들어주면 될 일이다. 문제는 대부분의 엔터프라이즈가 엔지니어링 부서를 극도로 분산시켜 놓았거나, 완전히 외부에 아웃소싱했다는 것이다. 내부에 이런 인프라를 구축할 수 있는 사람이 없다. IT 부서는 존재하지만, 이들의 역할은 기존 시스템을 유지보수하고 보안 정책을 집행하는 것이지, 새로운 AI 인프라를 설계하고 구축하는 것이 아니다.
이 세 가지 족쇄가 결합되면 완벽한 교착 상태가 만들어진다. Agent를 실행할 환경이 없다. 실행할 수 있다 해도 연결할 시스템이 없다. 이 두 문제를 해결할 내부 역량도 없다. 결과적으로 엔터프라이즈의 수만 명의 직원들은 Chat User 수준에 영구적으로 고정된다.
여기서 반드시 짚고 넘어가야 할 것은 보안 우려가 실재한다는 점이다. 아무런 통제 없이 코딩 에이전트가 프로덕션 데이터베이스 위에서 자유롭게 돌아가게 하는 것은 당연히 위험하다. Agent를 안전하게 샌드박싱하는 것은 기술적으로 어려운 과제다. 하지만 이 보안 우려가 현재 상태를 정당화하지는 못한다. 보안 우려 때문에 아무것도 하지 않는 것은, 보안 문제를 해결하는 것이 아니라 AI 시대에 경쟁력을 상실하는 것이기 때문이다.
5. 작은 회사들이 날아오르는 이유: Bash + Python + API = 데이터 사이언스 팀
엔터프라이즈의 3중 족쇄가 없는 회사들은 완전히 다른 세계에 살고 있다. 특히 작은 회사들, 스타트업들, 그리고 족쇄에서 벗어나기로 결단한 중소기업들이 AI로 달성하고 있는 성과는 대기업의 AI 도입 효과와는 차원이 다르다. 이 격차는 양쪽을 동시에 관찰하면 충격적일 정도로 선명하게 드러난다.
한쪽을 보자. 대기업의 재무 이사가 Microsoft Copilot의 Excel 통합 기능을 사용해본다. 가장 기본적인 데이터 분석 요청을 해보지만 결과는 엉망이다. 이 경험을 바탕으로 AI에 대한 기대치를 대폭 하향 조정한다. AI는 아직 갈 길이 멀다고 판단하고, 기존 방식대로 엑셀 시트를 수동으로 작업하는 것으로 돌아간다.
다른 쪽을 보자. 비기술직 출신의 한 경영진이 Claude Code의 개념을 이해하고, Python을 로컬에서 실행할 수 있는 환경을 갖추었다. 이 사람은 30개 시트로 구성된, 정신이 아득해질 정도로 복잡한 Excel 재무 모델을 Claude Code를 사용해서 Python으로 전환했다. 거의 한 번에 완성했다. Plan 모드로 먼저 Excel 시트의 구조를 파악하게 한 다음, 구현을 지시하는 것으로 충분했다. Claude Code는 Python 모델 자체에 유닛 테스트까지 추가했다.
이 전환이 만들어내는 차이는 단순히 파일 형식의 변경이 아니다. 패러다임의 전환이다. Excel 안에 갇혀 있을 때 재무 모델은 정적인 스프레드시트다. 수치를 바꾸면 결과가 바뀌지만, 기본적으로 사람이 직접 시나리오를 하나하나 입력하고 확인해야 한다. 하지만 이 모델이 Python으로 옮겨가는 순간 완전히 다른 가능성이 열린다.
첫째, 몬테카를로 시뮬레이션을 돌릴 수 있다. 주요 변수에 확률 분포를 부여하고, 수만 번의 시뮬레이션을 돌려서 결과의 확률 분포를 확인할 수 있다. 엑셀에서는 현실적으로 불가능했던 작업이 Python에서는 코드 몇 줄이면 된다.
둘째, 외부 데이터 소스를 자동으로 연동할 수 있다. 환율 데이터, 원자재 가격, 경제 지표 등을 API로 실시간으로 가져와서 모델에 반영할 수 있다.
셋째, 웹 대시보드를 구축할 수 있다. 경영진이 브라우저에서 실시간으로 재무 모델의 결과를 확인하고, 변수를 조정해가며 시나리오를 탐색할 수 있다.
넷째, 그리고 이것이 가장 중요한데, Claude Code와 함께 모델 자체의 약점을 식별하고 개선할 수 있다. Agent에게 이 모델의 취약점은 뭐야, 어떤 가정이 가장 위험해 라고 물으면, Agent가 감도 분석을 수행하고 약한 고리를 식별해준다.
이것은 사실상 주머니 속의 데이터 사이언스 팀을 갖게 되는 것과 같다. 예전에는 대기업만이 데이터 분석 팀을 보유할 수 있었고, 이 팀에게 분석을 의뢰하면 몇 주가 걸렸다. 지금은 10명짜리 회사의 CFO가 Claude Code 앞에서 프롬프트 몇 줄로 동일한 수준의 분석을 몇 분 만에 수행할 수 있다. 사람이 스프레드시트를 만지는 것이 아니라, Agent가 분석을 수행하고 사람은 의사결정만 한다. 이것이 바로 앞서 정의한 일이 이루어지지만 사람이 더 이상 그 일을 안 하는 상태다.
이런 상황은 기업 규모와 자원의 전통적인 우위를 근본적으로 뒤흔든다. 과거에는 작은 회사의 직원들이 대기업의 팀과 자원, 도구, 인프라를 부러워했다. 하지만 이제 추가 점점 반대로 움직이고 있다. 작은 회사의 직원들은 잠긴 환경, 느린 의사결정, 제한된 도구에 갇힌 대기업 직원들보다 훨씬 더 생산적이다. Bash 셸, Python, API 접근 권한, 그리고 Agentic 도구만 있으면 한 사람이 해낼 수 있는 일의 양과 질이 대기업의 전체 부서를 능가하기 시작한 것이다.
6. 미래의 지식노동 공식: User Prompt → Agent → API → Output
Bottom-up 혁신이 Top-down 전략을 이기는 이유
미래의 업무 방식이 어떤 모습일지 윤곽이 잡히기 시작했다. 가장 중요한 관찰 중 하나는 진짜 생산성 도약이 종종 직원들의 자발적인 실험에서 유기적으로 일어나고 있다는 것이다. 최고 경영진이 수립한 AI 전략에서 시작되는 것이 아니다. 현장에서 가장 뛰어난 결과를 내는 곳은 소규모 팀이 스스로 AI 보조 워크플로우를 구축하기로 결정한 곳이다. 이들은 자신이 매일 수행하는 프로세스를 속속들이 알고 있기 때문에 매우 좋은 결과를 얻을 수 있다. 이것은 흔히 아웃소싱된 소프트웨어 엔지니어링 팀이 프로세스 자체를 한 번도 직접 해본 적 없으면서 자동화를 돕는 것과 정반대의 접근이다. 대부분의 디지털 트랜스포메이션 프로젝트가 실패하는 이유가 바로 이것이었다. 일을 모르는 사람이 일을 자동화하려 했기 때문이다. AI 시대에는 일을 아는 사람이 직접 자동화한다. 이것이 게임 체인저다.
API-First 아키텍처가 생존 조건이 되는 시대
두 번째 관찰은 내부 시스템에 어떤 형태로든 API가 있는 회사가 그렇지 않은 회사보다 압도적으로 많은 것을 해낼 수 있다는 것이다. 이것은 매우 단순할 수 있다. 직원들이 접속해서 사용자를 대신해서 쿼리를 실행할 수 있는 읽기 전용 데이터 웨어하우스만 있어도 엄청난 차이가 난다. 혹은 복잡한 핵심 비즈니스 프로세스가 완전히 API화되어 있을 수도 있다. 중요한 것은 Agent가 연결할 수 있는 진입점이 존재하느냐는 것이다. 여기서도 작은 회사들이 유리하다. 이들은 대체로 더 최신의 제품들을 사용하고 있고, 이 제품들은 수십 년 전에 만들어진 시스템 위에 인터페이스가 겹겹이 덧대어진 것이 아니라, 처음부터 API를 핵심에 두고 설계되었기 때문에 훨씬 잘 정돈된 API를 가지고 있다.
보안 VM 기반의 Agent 운영 모델
세 번째로, 이 모든 것은 적절한 보안 메커니즘으로 감싸져야 한다. 현실적인 해결책으로 보이는 것은 호스팅된 VM 위에서 코드 에이전트를 실행하되, 잘 설계된 네트워크 제한을 적용하는 방식이다. 적어도 읽기 전용 리포팅 용도로는 이 접근이 충분히 실용적이다. 데이터를 생성하고 수정하는 작업의 경우, 비기술직 사용자가 Agent를 안전하게 사용할 수 있게 하는 모델은 아직 완전하지 않다. 하지만 이것은 기술적 한계라기보다 거버넌스의 문제이며, 빠르게 해결되고 있다. 사실 이미 선례가 존재한다. GitHub Codespaces와 같은 서비스가 개발자들을 위해 이 문제를 해결한 바 있다. 필요한 것은 이와 유사한 접근을 조직 전체로 확장하는 것이다. CISO들은 이런 종류의 보안 VM을 대규모로 활성화하는 방법을 고민해야 한다. 직원들이 이미 이런 시스템에 대한 접근을 원하고 있고, 비공식적으로 사용하고 있을 가능성이 높기 때문이다.
레거시 SaaS의 딜레마: Lock-in인가 취약점인가?
마지막으로, 레거시 엔터프라이즈 SaaS 업체들은 관점에 따라 거대한 록인을 가지고 있거나, 극도로 취약한 위치에 있다. 대부분의 기존 SaaS 제품은 API-First로 설계되지 않았다. 보유한 API들은 대체로 개발자 용도로 만들어진 것이지, 수천 명의 직원이 Agent를 통해 다양하고 비효율적인 방식으로 대량 접속하는 상황에 최적화되어 있지 않다. 하지만 이 SaaS 제품들이 회사의 진실의 원천, 즉 핵심 데이터의 소스인 경우 마이그레이션은 극히 어렵다. 결과적으로 이 레거시 시스템들이 생산성 향상의 병목이 된다. 다시 말하지만, 작은 회사들은 이 문제에서도 유리하다. 더 최신의, API가 잘 설계된 제품을 처음부터 사용해왔기 때문이다.
이 모든 것을 종합하면 미래 지식노동의 공식이 드러난다. 사용자가 프롬프트한다. Agent가 API를 통해 시스템에 연결한다. 데이터를 처리하고 결과물을 생성한다. 사람은 무엇이 필요한지를 정의하고, Agent가 실행하고, 시스템이 결과를 산출한다. 이것이 Bash 샌드박스, 프로그래밍 언어, API 접근, Agentic 하네스의 결합이 만들어내는 미래다. 이 조합은 비기술직 사용자들에게도 충격적으로 좋은 결과를 만들어낸다. 사실상 기존의 모든 표준 생산성 앱을 대체할 수 있다. 클래식한 Microsoft Office 스타일의 도구들만이 아니라 웹 앱도 마찬가지다. 어떤 보고서든 요청하면 만들어지고, 원하는 형식으로 내보내진다. 이것이 지식노동의 미래다.
7. 대분기 시대, 일의 정의를 바꾸지 않으면 도태된다
지금 일어나고 있는 것은 AI 기술의 발전이 아니다. 일의 의미 자체가 재정의되고 있는 것이다. 그리고 이 재정의의 속도를 따라가지 못하는 조직과 개인은 돌이킬 수 없는 격차에 직면하게 된다.
앞서 살펴본 것처럼 생산성 대분기의 핵심은 기술이 아니다. 기술은 이미 존재한다. Claude Code가 있고, Python이 있고, API가 있고, 샌드박싱된 VM을 만드는 방법도 알려져 있다. 핵심은 일에 대한 정의다. AI에게 묻고 답을 받는 것을 AI로 일한다고 부르는 한, 생산성 혁명은 일어나지 않는다. AI가 일하게 만드는 것, 즉 Agentic Flow를 설계해서 사람이 하던 업무를 Agent가 수행하게 만드는 것이 진짜 AI로 일하는 것이다.
이 정의의 차이가 만들어내는 현실적 결과를 다시 한번 정리해보자. Chat User 모드에 머물러 있는 엔터프라이즈는 AI에 대한 환멸에 빠져 있다. Copilot의 실망스러운 성과를 근거로 AI 투자를 유보하거나, 대형 컨설팅 회사에 막대한 비용을 지불하며 실질적 성과 없는 전략 문서를 받아들고 있다. 잠긴 로컬 환경, API 없는 레거시 시스템, 아웃소싱된 엔지니어링 역량이라는 3중 족쇄가 이들을 영구적으로 옥죄고 있다.
반면 Flow Designer 모드로 전환한 작은 회사들은 하늘을 날고 있다. 한 사람이 Agent와 함께 데이터 사이언스 팀 수준의 분석을 수행하고, 재무 모델을 Python으로 전환해서 몬테카를로 시뮬레이션을 돌리고, 실시간 대시보드를 구축한다. 그 일은 여전히 이루어지지만, 사람이 더 이상 그 일을 직접 하지 않는다. 사람은 설계하고 판단한다. Agent가 실행한다.
이 양극화는 가속되고 있다. 감속이 아니라 가속이다. 역사상 처음으로 극소규모 팀이 자신의 천 배 규모의 기업과 맞설 수 있는 시대가 열리고 있다. 과거에는 대기업이 규모의 경제, 인적 자원, 자본력으로 압도적 우위를 점했다. 하지만 AI Agent가 노동의 한계비용을 제로에 가깝게 만들면, 규모의 우위는 오히려 규모의 족쇄가 된다. 잠긴 환경, 레거시 시스템, 관료적 의사결정은 대기업만이 가지는 짐이기 때문이다.
미래를 향한 길은 이미 보인다. 직원들이 자신의 업무를 가장 잘 알고 있으므로, Bottom-up 방식의 자발적 혁신이 Top-down AI 전략보다 효과적이다. 내부 시스템의 API화는 선택이 아니라 생존 조건이다. 보안 VM 기반의 Agent 실행 환경을 조직 전체에 확대하는 것이 CISO의 최우선 과제가 되어야 한다. 그리고 이 모든 것의 시작점은 기술 도입이 아니라, 일의 정의를 바꾸는 것이다.
AI를 도입했는가가 아니라, 사람이 하던 일을 Agent가 하게 만들었는가. 이것이 유일한 기준이다. 이 기준으로 자신의 조직과 자신의 업무 방식을 평가해보라. Chat User인가, Flow Designer인가. 그 답이 앞으로의 경쟁력을 결정한다. 대분기는 이미 시작되었고, 분기점은 기술이 아니라 일에 대한 정의에서 갈리고 있다.
