▲

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

 (martinalderson.com)
5P by GN⁺ 13시간전 | ★ favorite | 댓글 3개
  • 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 활용 격차는 실제로 존재하며, 그 속도는 점점 더 빨라지고 있음
    • 역사상 소규모 팀이 천 배 큰 기업을 이토록 쉽게 앞설 수 있었던 적이 없음
▲
bichi 44분전  [-]

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

답변달기
▲
xguru 53분전  [-]

중간에 Copilot 비판이 많은데, 정작
Claude Code가 마이크로소프트 내부에서 급속히 확산 중

국내 대기업에도 분명히 적용되는 상황일듯.
회사가 쓰라고 하니 쓰지만, ChatGPT/Claude 는 안되고 Copilot 만 쓸수 있다는 데가 분명히 있을거 같아요.

답변달기
▲
GN⁺ 13시간전  [-]
Hacker News 의견들

  • 나는 사용자들을 두 부류로 나눌 수 있다고 봄
    하나는 도구로서 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)
답변달기