# 두 가지 유형의 AI 사용자가 등장하고 있으며, 그 격차는 놀랍습니다

> Clean Markdown view of GeekNews topic #26345. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26345](https://news.hada.io/topic?id=26345)
- GeekNews Markdown: [https://news.hada.io/topic/26345.md](https://news.hada.io/topic/26345.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-02T22:33:31+09:00
- Updated: 2026-02-02T22:33:31+09:00
- Original source: [martinalderson.com](https://martinalderson.com/posts/two-kinds-of-ai-users-are-emerging/)
- Points: 43
- Comments: 4

## Summary

AI 활용 방식의 **양극화**가 뚜렷해지고 있습니다. 일부 ‘파워 유저’는 **Claude Code·MCPs 같은 고급 도구를 로컬 워크플로에 통합**하며 업무 자동화를 일상화하지만, 다수의 직장인은 여전히 단순 질의응답형 사용에 머물러 있습니다. 보안 정책과 레거시 시스템에 묶인 대기업과 달리 **소규모 팀은 API 중심 환경과 샌드박스형 코드 실행으로 생산성을 폭발적으로 끌어올리고** 있으며, 이는 지식 노동의 구조 자체를 재편하는 흐름으로 이어지고 있습니다.  
  
작년부터 하던 얘기였는데, 올해는 더 극적으로 변하고 있는 것 같아요. AI를 잘 활용하는 사람과 아닌 사람의 생산성 차이가 점점 더 커지고 있습니다.

## Topic Body

- **AI 사용자 간 생산성 격차**가 급격히 벌어지고 있으며, **‘파워 유저’** 는 **Claude Code, MCPs 등 고급 AI 도구를 적극 활용**하는 반면, 대다수는 여전히 **ChatGPT 수준의 대화형 사용에 머무름**  
- 대기업은 **보안 정책, 폐쇄적 IT 환경, 레거시 시스템**으로 인해 최신 AI 도구를 도입하기 어려운 반면, **소규모 기업은 빠르게 AI를 내재화**하며 효율을 높이고 있음  
- 이러한 격차는 **작은 팀이 대기업보다 훨씬 높은 생산성을 낼 수 있는 시대**로 이어지고 있으며, **내부 API와 안전한 코드 실행 환경 구축**이 미래 경쟁력의 핵심으로 부상함  
- 프로그래밍 언어와 API 접근이 가능한 **bash 샌드박스**에 에이전트를 결합하면 비기술 사용자도 거의 모든 생산성 앱을 대체할 수 있으며, 이것이 **지식 노동의 미래** 형태  
  
---  
  
### 두 가지 AI 사용자 유형  
- AI 사용자 간의 **생산성 격차가 급격히 확대**되고 있음  
  - 한쪽은 Claude Code, MCPs, 스킬 기반 워크플로를 활용하며 **비기술자조차 터미널에서 AI를 적극 사용**  
  - 특히 **재무 부문**에서 Python 기반 자동화로 **Excel의 한계를 극복**하는 사례가 많음  
- 다른 한쪽은 여전히 **ChatGPT 수준의 단순 질의응답형 사용**에 머물러 있음  
  - 많은 직장인들이 여전히 이 범주에 속하며, AI의 잠재력을 충분히 활용하지 못하고 있음  
  
### Microsoft Copilot의 한계  
- **M365 Copilot**은 Office 365 구독에 번들로 제공되어 기업시장에서 점유율이 높지만, **ChatGPT의 열화판 수준 인터페이스**  
  - **"에이전트" 기능**은 CLI 코딩 에이전트(Microsoft 자체의 GitHub Copilot CLI 포함)와 비교하면 웃음거리 수준  
    대용량 파일에서 자주 실패하며, **메모리·CPU 제한이 과도**함  
- Microsoft 내부조차 **Claude Code를 사내 팀에 도입**하고 있음  
  - 이는 Copilot이 기술적으로 뒤처져 있음을 보여주는 사례  
- 기업 환경에서는 Copilot이 유일하게 허용된 AI 도구인 경우가 많아, 직원들은 다른 도구를 쓰려면 해고 위험을 감수하거나 많은 노력을 들여야 함  
  — 고위 의사결정자들이 이런 도구로 **형편없는 결과를 경험한 뒤 AI 전체를 폄하**하거나, 대형 **컨설팅 업체에 막대한 비용을 지출**하고도 성과를 내지 못하는 상황  
  
### 대기업이 직면한 구조적 위험  
- **보안 중심의 폐쇄적 IT 정책**이 혁신을 가로막고 있음  
  - **극도로 잠긴 환경**: 기본적인 스크립트 인터프리터조차 로컬에서 실행 불가 (운이 좋아야 VBA 정도, 그마저도 Group Policy로 제한)  
  - **레거시 소프트웨어**: 핵심 워크플로에 내부용 API가 없어 에이전트가 연결할 대상 자체가 없음  
  - **사일로화된 엔지니어링 부서**: 완전히 외주화된 경우가 많아 **안전하게 샌드박싱된 에이전트를 운영**할 인프라를 구축할 내부 인력 부재  
- 물론, 보안 우려는 실재함 — 프로덕션 데이터베이스에 통제 없이 코딩 에이전트를 무분별하게 실행하는 것은 위험  
- 하지만 샌드박싱은 **어려운 작업**이며, 이를 **안전하게 구축할 엔지니어링 팀이 없다는 것이 핵심 문제**  
  
### 소규모 기업의 급성장  
- **레거시 제약이 없는 중/소기업**은 AI를 빠르게 도입하며 생산성을 폭발적으로 높이고 있음  
  - 한쪽에는 Microsoft의 Excel용 Copilot(Gemini의 Google Sheets 통합도 마찬가지로 형편없음)을 써보고 단순 작업도 엉망으로 처리되자 다시는 손대지 않는 재무 이사들이 있는 반면,   
  - 다른 한쪽에는 **Claude Code를 익힌 비기술직 임원**이 Python을 로컬에서 실행  
    - 30개 시트로 구성된 극도로 복잡한 Excel 재무 모델을 Claude Code로 Python으로 변환하는 작업을 **2~3개 프롬프트**만으로 거의 완료  
    - 모델이 Python으로 전환되면 Claude Code로 **데이터 사이언스 팀 수준의 역량** 확보 가능  
    - 몬테카를로 시뮬레이션 실행, 외부 데이터 소스 연동, 웹 대시보드 구축, 모델(또는 비즈니스)의 약점 분석 지원 등이 모두 가능  
- 과거에는 소규모 기업 직원들이 대기업의 리소스와 팀을 부러워했지만,  
  이러한 환경에서는 **소규모 팀이 대기업보다 훨씬 높은 효율**을 보이며 **생산성의 추세가 역전**되고 있음  
  
### 미래의 업무 구조  
- **AI 생산성 향상은 상향식(bottom-up)으로 발생**  
  - 소규모 팀이 특정 프로세스에 AI 지원 워크플로 구축을 시도하고, 해당 프로세스를 속속들이 알기 때문에 좋은 결과 도출  
  - 프로세스 경험이 전무한 외주 소프트웨어 엔지니어링 팀과는 대조적  
  - 대부분의 기존 **'디지털 트랜스포메이션'** 프로젝트와 정반대 양상   
- **내부 시스템용 API를 보유한 기업**이 훨씬 더 많은 것을 달성할 수 있음  
  - 단순히 직원들이 연결해 사용자 대신 쿼리를 실행할 수 있는 읽기 전용 데이터 웨어하우스부터, **핵심 비즈니스 프로세스의 API화**까지 범위는 다양  
- **보안이 통제된 VM 환경에서 코드 에이전트를 실행**하는 방식이 현실적 대안  
  - 읽기 전용 리포팅에는 적합하지만, 데이터 수정에는 아직 한계 존재  
- **레거시 엔터프라이즈 SaaS** 업체들은 강력한 락인 상태이거나, 관점에 따라 극도로 취약한 상태  
  - **대부분 "API-first" 제품이 아니며**, **기존 API는 개발자용으로 설계**되어 수천 명의 직원이 비효율적으로 호출하는 상황에 **최적화되어 있지 않음**  
  - 그러나 회사의 단일 진실 공급원(source of truth)이라면 이전이 매우 어렵고 **생산성 향상의 병목**이 됨  
- 소규모 기업들은 **더 새롭고 API가 잘 설계된 제품**을 사용하는 경향이 있음  
  - 이들, **신생 SaaS 제품은 API 중심 설계**로 AI 통합에 유리함  
  
### 지식 노동의 새로운 형태  
- **프로그래밍 언어와 시스템 API 접근이 가능한 bash 샌드박스**와 **에이전트 프레임워크**의 결합이 **비기술자에게도 강력한 생산성 도구**로 작동  
  - 사용자는 프롬프트를 입력하고, 에이전트는 API를 통해 결과를 생성  
  - 보고서 작성, 데이터 분석, 문서 생성 등 사용자가 요청하는 모든 것을 원하는 형식으로 내보낼수 있어 **기존 오피스 앱 대부분을 대체 가능**  
- 사용자가 프롬프트하면 에이전트가 API에 연결하고 요청에 따라 출력물을 생성하는 방식이 **지식 노동의 미래**  
  - 이 **양극화는 실재하며 급격히 가속화** 중  
- 이러한 변화는 **작은 팀이 대기업보다 빠르게 경쟁 우위를 확보할 수 있는 시대**를 열고 있음  
  - AI 활용 격차는 실제로 존재하며, **그 속도는 점점 더 빨라지고 있음**  
  - 역사상 **소규모 팀이 천 배 큰 기업을 이토록 쉽게 앞설 수 있었던 적이 없음**

## Comments



### Comment 50487

- Author: neo
- Created: 2026-02-02T22:33:31+09:00
- Points: 2

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46850588) 
- 나는 사용자들을 두 부류로 나눌 수 있다고 봄  
  하나는 **도구로서 AI를 활용**하는 사람들로, 한계를 인지하고 반복적이거나 지루한 일을 맡기거나 요약을 얻는 용도로 씀  
  다른 하나는 **사고 자체를 외주화**하는 사람들로, 주제에 대한 이해가 거의 없고 결과만 원하며 학습 의지가 없음  
  후자는 챗봇이 시니어 개발자를 대체할 수 있다고 믿는 부류임
  - 회사가 ‘생각하는 엔지니어’를 원치 않는다는 걸 깨닫고 나도 일에서 사고를 외주화하기 시작했음  
    빠른 납기만 중요하고, 고객 피드백은 반년 후에나 오니 의미가 없음  
    이제는 최소한의 노력만 들여 월급만 받으며 버티는 중임
  - 또 다른 유형도 있음. **사고 능력을 활용해 더 고도화된 도구를 만들어**, 점점 더 많은 사고와 기술을 AI에 위임하는 사람들임. 나와 내 주변이 여기에 해당함
  - 사고를 외주화하는 게 항상 나쁜 건 아님  
    나는 독일어 듣기 연습용 앱을 Claude Code와 ElevenLabs로 만들었는데, 교사도 놀랄 정도로 효과적이었음  
    코드 학습엔 관심 없고, **독일어 실력 향상**이 목적이었음
  - 세 번째 그룹도 있다고 봄. AI를 **가상의 팀원**처럼 활용해 아이디어를 주고받는 사람들임. 이게 가장 흥미로운 사용 사례라고 생각함
  - 또 다른 부류는 검색엔진, 의사나 상담사, 문서 대체용으로 쓰는 사람들임.  
    즉, 단순한 도구 그 이상으로 **대화형 파트너**로 쓰는 경우임

- AI를 **그린필드 프로젝트**와 **브라운필드 프로젝트**에서 써보면 생산성 차이가 큼  
  새 프로젝트 첫날엔 일주일치 일을 해내지만, 기존 시스템에서는 20% 정도 향상에 그침  
  결국 AI가 ‘혁신가의 딜레마’를 빠르게 재현하게 만드는 셈임  
  문제는 AI가 복잡한 시스템을 성숙시키는 단계에서 얼마나 역할을 할 수 있느냐임
  - 엔터프라이즈 IT에서 일하는 입장으로서 이 말에 공감함  
    Hashicorp Packer 빌드파일을 AI로 거의 완성했는데, **로컬 AI**가 큰 도움이 되었음  
    하지만 오래된 인프라에선 예측 불가능성이 커서 LLM이 오히려 망칠 가능성이 큼
  - 사실 이런 현상은 AI가 없어도 새 프로젝트에서 항상 일어남  
    처음엔 빠르지만, 나중엔 **아키텍처의 한계**가 드러남
  - 나는 AI를 **생산성 윤활유**로 씀. 피곤하거나 과도하게 고민할 때 시작점을 잡아줌  
    과공학을 줄이는 데도 도움 됨
  - 하지만 이 속도 향상은 **컨텍스트 윈도우 한계**에서 멈춤  
    프로젝트가 200k 토큰을 넘으면 생산성이 0이 됨  
    결국 조직은 기억에 의존하지 않는 프로세스로 승리함
  - 평소엔 10~20% 향상 정도지만, 개인 프로젝트에서는 200~500%까지 향상된 적도 있음

- 한 임원이 Claude Code로 **30시트짜리 복잡한 Excel 재무 모델을 Python으로 변환**했다는 이야기를 듣고 거의 구역질이 났음  
  수학과 지구물리학 배경이 있는 입장에서, 그런 Excel 모델 자체가 악몽임  
  그래도 Python 변환본이 원본보다 나쁠 가능성은 크지 않다고 인정함
  - 이런 코드 인접 분야의 비밀은 **테스트가 거의 없다는 것**임  
    잘못된 모델링을 누가 잡아낼까? 거의 아무도 없음  
    LLM이 만든 시뮬레이션은 검증 절차가 더 부족함
  - 금융권에서는 실제로 **프로덕션 Excel 스프레드시트**를 코드처럼 버전 관리하고 테스트함  
    초기엔 빠른 실험용으로 쓰다가, 수익이 커지면 기술팀이 정식 앱으로 전환함
  - 하지만 나는 Claude Code 버전이 훨씬 나쁠 거라 확신함  
    원본 Excel은 수년간 수정된 반면, 변환본은 **가짜 복제물**에 불과함
  - “나쁠 가능성이 크지 않다”는 말에 웃음이 나왔음
  - 이제는 “엑셀이 불황을 만들던 시대에서, **AI가 만든 금융 모델이 불황을 만드는 시대**”로 가는 중임
  - Claude Code가 변환을 거의 한 번에 끝냈다 해도, 중요한 로직을 망쳤을 확률이 높음
    - 물론 Excel과 Python을 동시에 실행해 결과를 비교할 수 있다면 정확도는 높아질 수 있음
    - 하지만 그 Excel 모델 자체가 제대로 검증됐을 가능성도 낮음
    - ‘거의 한 번에’라는 말은 CPU가 ‘거의 100% 신뢰성’ 있다고 말하는 것과 같음
    - 결국 우리의 **401k가 AI가 만든 모델에 의해 운용될 수도 있음**이 두려움임

- **AI로 금융 모델을 만드는 비전문가들**이 있다는 게 무섭게 느껴짐
  - 하지만 한 번 큰 사고가 나야 자본가들이 경각심을 가질 듯함
  - 그래도 옆에 Excel을 두고 비교 테스트할 수 있고, 이상하면 AI에게 설명을 요구할 수도 있음
  - 의료 분야로 넘어가면 더 무서울 것 같음
  - 나도 Python에서 Rust로 배우는 중인데, LLM이 자주 실수하는 걸 보며 **AI 신뢰의 위험성**을 절감함
  - 사실 많은 Excel 모델도 제대로 테스트되지 않음. 그냥 ‘맞는 것 같아’ 수준임

- 지금은 **Shadow AI의 탄생기**임  
  2000년대의 Shadow IT처럼, 직원들이 몰래 Claude Code를 터미널에서 돌림  
  공식 Copilot이 CSV도 제대로 못 다루니까  
  CISO들은 공포에 떨지만, 금지하면 유능한 직원들이 떠날 것임
  - 문제는 이들이 **토큰이나 계정 권한**을 그대로 AI에 넘긴다는 점임. 보안 악몽임

- 1980년대식으로 표현하자면, 진짜 혁신은 **현장 직원들이 자발적으로 만든 워크플로우**에서 나옴  
  그들이 프로세스를 가장 잘 알기 때문임  
  이후에야 CIO 친화적 패키지 소프트웨어가 따라옴
  - 결국 **힘은 꼬리 분포에 있음**, 즉 소수의 실험적 시도가 변화를 이끎

- 최근 몇 달간 에이전트가 쓸 만해지면서 다들 이제 막 사용하기 시작했음  
  MCP나 LangChain, 벡터 DB 같은 건 한때 유행했지만 지금은 조용함  
  아직은 **트렌드를 논하기엔 너무 이름**  
  - MCP 열풍은 대부분 **판매 목적**이었음. 하지만 프로토콜로 보면 꽤 유용함  
    context7과 playwright MCP 서버를 써봤는데, 계획 수립과 피드백 루프에 효과적이었음
  - MCP 얘기하는 사람들은 대부분 **LinkedIn에서만 활동하는 관리자**들임
  - 나처럼 오래된 리눅스 유저도 Claude Code로 **2개의 앱을 주말마다 완성**할 정도로 쉬워졌음
  - 실제로는 MCP 대신 REST나 기존 API를 더 많이 씀

- Microsoft Copilot의 Excel 통합은 형편없음  
  30년간 복잡한 XML 포맷을 만든 탓에 LLM이 이해할 수 없음  
  그래서 우리 회사는 **Word 문서를 Markdown으로 마이그레이션** 중임. 일종의 업보 같음
  - Tim Berners-Lee가 예견했던 **기계가 읽을 수 있는 웹**의 꿈이 이제야 현실화되는 중임  
    하지만 문서를 AI 친화적으로 만드는 데 드는 시간은 점점 늘어남
  - 아이러니하게도 Claude Code는 Excel에서 훨씬 잘 작동했음  
    Copilot은 CSV 변환 지시도 무시하고 실패함
  - 예전에 인턴들에게 Visio XML을 파싱해 JSON으로 변환시키는 프로젝트를 맡겼는데, 성공했지만 금세 사라졌음

- 예전에 들은 말이 있음 — “이제는 큰 기업이 작은 기업을 이기는 게 아니라, **빠른 기업이 느린 기업을 이긴다**”  
  지금 AI 시대에 이 말이 더 진실처럼 느껴짐. 문제는 **어떻게 빠르게 유지하느냐**임
  - 하지만 빠른 게 항상 좋은 건 아님. 절벽 아래로 먼저 떨어질 수도 있음
  - 또 언제 **속도를 늦춰야 하는지 아는 것**도 중요함. 보안과 컴플라이언스를 해치지 않으면서 빠르게 움직이는 법이 관건임
  - 물론 이런 말은 전형적인 **스타트업 조언**이지만, 때로는 느린 쪽이 이길 때도 있음 (예: Teams vs Slack)

### Comment 50633

- Author: tazuya
- Created: 2026-02-05T05:28:32+09:00
- Points: 1

여전히 까이는 Copilot. MS는 언제 개선하려나.

### Comment 50519

- Author: bichi
- Created: 2026-02-03T10:51:52+09:00
- Points: 1

머슴1, 2, 3 으로 쓰고 있어요

### Comment 50517

- Author: xguru
- Created: 2026-02-03T10:42:55+09:00
- Points: 1

중간에 Copilot 비판이 많은데, 정작   
[Claude Code가 마이크로소프트 내부에서 급속히 확산 중](https://news.hada.io/topic?id=26359)  
  
국내 대기업에도 분명히 적용되는 상황일듯.   
회사가 쓰라고 하니 쓰지만, ChatGPT/Claude 는 안되고 Copilot 만 쓸수 있다는 데가 분명히 있을거 같아요.
