[작성자:] kevin

  • Claude 작업 공간을 시작하지 못했습니다: 원인과 해결법 총정리

    이 글을 검색해서 들어왔다면 이미 알고 있을 것이다. Claude Code 터미널 어딘가에서 한 줄짜리 메시지가 떠올랐다. “Claude 작업 공간을 시작하지 못했습니다.” 어제까지 멀쩡히 돌아가던 도구가 갑자기 열리지 않는다. 메시지가 짧아서 어디부터 손대야 할지 막막하다. 결론부터 말하면 — 대부분의 경우 5분 안에 해결된다. 원인이 보통 셋 중 하나로 좁혀지기 때문이다.

    왜 이 오류가 나는가

    Claude Code의 “작업 공간을 시작하지 못했습니다” 오류는 거의 다음 세 가지 중 하나로 귀결된다.

    • 인증 만료 — OAuth 토큰이 만료됐거나 계정 상태에 변화가 생긴 경우
    • IDE 연결 실패 — VS Code, JetBrains 같은 IDE와 Claude Code 사이의 연결이 끊어진 경우
    • 실행 환경 문제 — WSL 설정, PATH 누락, Node.js 버전 충돌

    중요한 사실 한 가지. 이 오류는 거의 Claude Code 자체의 버그가 아니다. 대부분 환경 설정 차원의 문제이고, 그래서 짧은 조치 몇 가지로 해결된다. 아래 순서대로 시도해 보면 90% 이상의 케이스가 잡힌다.

    해결법 1 — 가장 먼저 시도할 것: 로그아웃 후 재로그인

    인증 토큰이 만료된 경우가 가장 흔한 원인이다. Claude Code 터미널에서 다음을 입력한다.

    /logout

    로그아웃이 끝나면 Claude Code를 완전히 종료한다. 터미널을 새로 열고 다시 실행한다.

    claude

    로그인 화면이 나타나면 안내에 따라 브라우저 인증을 완료한다. 브라우저가 자동으로 안 열리는 경우가 있는데, 이때는 c 키를 눌러 URL을 클립보드에 복사한 다음 직접 브라우저에 붙여 넣으면 된다. 이 단계만으로 해결되는 비율이 가장 높다.

    해결법 2 — PATH 문제 (command not found 포함)

    설치는 됐는데 실행이 안 되는 경우다. 터미널에서 다음을 입력해 PATH를 점검한다.

    echo $PATH | tr ':' '\n' | grep local/bin

    아무것도 출력되지 않는다면 PATH에 설치 경로가 빠져 있는 것이다. 사용 중인 셸에 맞춰 추가한다.

    macOS (zsh)

    echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
    source ~/.zshrc

    Linux (bash)

    echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
    source ~/.bashrc

    이후 claude --version으로 정상 실행 여부를 확인한다.

    해결법 3 — WSL 환경에서의 추가 조치

    Windows에서 WSL로 Claude Code를 쓰는 경우 별도 설정이 필요하다. 자주 부딪히는 세 가지 케이스가 있다.

    브라우저 로그인이 안 되는 경우. WSL이 Windows 브라우저를 못 띄우는 상황이다. BROWSER 환경 변수를 직접 지정한다.

    export BROWSER="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
    claude

    Node를 못 찾는 경우. WSL이 Windows 경로의 Node.js를 잘못 참조하는 게 원인이다. which node를 입력했을 때 /mnt/c/로 시작하면 이 문제가 맞다. nvm으로 Linux용 Node를 별도로 설치한다.

    source ~/.nvm/nvm.sh
    nvm install --lts

    JetBrains IDE가 감지 안 되는 경우. WSL2 방화벽이 IDE 연결을 차단하는 케이스다. PowerShell을 관리자 권한으로 열고 다음을 실행한다(WSL2 IP는 wsl hostname -I로 확인).

    New-NetFirewallRule -DisplayName "Allow WSL2" -Direction Inbound -Protocol TCP -Action Allow -RemoteAddress 172.21.0.0/16 -LocalAddress 172.21.0.0/16

    해결법 4 — 마지막 수단: 구성 파일 초기화

    위 세 가지로 안 잡힌다면 Claude Code 설정 파일을 통째로 초기화한다. 세션 기록은 사라지지만 기능은 그대로 복구된다.

    rm ~/.claude.json
    rm -rf ~/.claude/

    이후 claude를 다시 실행하면 초기 상태로 돌아간다. 처음 설치한 것과 같은 상태에서 다시 로그인하면 된다.

    그래서

    Claude Code는 업데이트 속도가 빠른 도구다. 그만큼 간헐적인 환경 충돌이 생긴다. 다만 거의 모든 경우 재로그인 → PATH 확인 → 구성 초기화 순서로 풀린다. 이 흐름을 머리에 넣어 두면 다음 번에는 5분 안에 끝낼 수 있다.

    지금 할 일

    가장 먼저 할 일은 Claude Code 터미널에서 /doctor를 실행하는 것이다. Anthropic 공식 문서가 권장하는 1차 진단 도구다. 결과가 어디에 문제가 있는지 직접 알려 준다. 진단 결과에 따라 위 4가지 해결법 중 해당하는 것부터 시도한다. 같은 오류가 반복적으로 발생한다면 운영 환경(WSL 사용 여부, Node 버전, 셸 종류) 정보를 메모해 두자. 다음 번 troubleshooting이 훨씬 빨라진다.

    관련 글

    출처

  • Claude Code 처음 시작하는 법: 설치부터 실전까지 2026 완전 가이드

    Claude Code를 처음 써 보려는 사람에게 가장 큰 벽은 도구 자체가 아니다. “터미널에서 시작한다”는 한 줄 때문에 마음이 멈춘다. Cursor나 GitHub Copilot처럼 익숙한 IDE 화면이 아니라 검은 터미널 창에서 출발해야 한다는 사실이 막막함을 만든다. 그런데 막상 깔아 보면 5분이면 끝난다. 이 글은 “어디서부터 시작해야 하지”라는 첫 막막함을 해소하기 위한 한국어 단계별 가이드다.

    Claude Code가 정확히 뭔가

    Claude Code는 Anthropic이 만든 AI 코딩 에이전트다. 터미널에 자연어로 지시를 입력하면 코드를 작성하고, 버그를 수정하고, Git 커밋까지 알아서 처리한다. 2026년 기준으로 VS Code, JetBrains, 데스크톱 앱, 웹(claude.ai/code)에서도 같은 흐름으로 쓸 수 있다. 즉 “터미널 전용”이라는 인상은 정확하지 않다. 입구가 터미널일 뿐, 본인이 편한 환경을 골라 쓰면 된다.

    가격 면에서 결정적인 사실 하나. Claude Code는 Claude Pro($20/월) 이상 구독자라면 추가 비용 없이 그대로 쓸 수 있다. Cursor Pro와 같은 가격이지만 작동 방식이 다르다. Cursor가 코드 완성 중심이라면 Claude Code는 에이전트 방식으로 작업 단위를 통째로 처리한다.

    설치 전 준비

    • Claude Pro·Max·Teams·Enterprise 구독 (또는 Anthropic Console API 계정)
    • 터미널 환경 — Mac은 기본 터미널 또는 iTerm2, Windows는 PowerShell 또는 Git Bash
    • Windows 사용자라면 Git for Windows 사전 설치

    운영체제별 설치

    macOS / Linux

    curl -fsSL https://claude.ai/install.sh | bash

    Windows PowerShell

    irm https://claude.ai/install.ps1 | iex

    macOS Homebrew

    brew install --cask claude-code

    Homebrew와 WinGet으로 설치하면 자동 업데이트가 안 된다는 점 한 가지만 기억해 두자. 주기적으로 brew upgrade claude-codewinget upgrade Anthropic.ClaudeCode를 실행해 최신 버전을 유지한다.

    첫 실행과 로그인

    설치가 끝나면 작업할 프로젝트 폴더로 이동해 실행한다.

    cd /path/to/your/project
    claude

    처음 실행 시 로그인 화면이 나타난다. 브라우저가 자동으로 열리면 Claude 계정으로 로그인하고 끝. 만약 브라우저가 안 열린다면 c 키를 눌러 URL을 복사해 직접 붙여 넣으면 된다. 이 한 번의 로그인이 끝이다. 이후로는 claude만 입력하면 바로 시작된다.

    기본 사용법 — 어렵게 생각하지 말 것

    Claude Code는 대화 방식으로 작동한다. “어떻게 명령을 써야 하지”를 고민하지 말고, 하고 싶은 걸 평소 말하는 대로 입력하면 된다. 다음은 자주 쓰는 패턴 다섯 가지다.

    • 코드 이해: “이 프로젝트가 뭘 하는 건지 설명해 줘”
    • 기능 추가: “로그인 폼에 입력값 유효성 검사 추가해 줘”
    • 버그 수정: “빈 폼을 제출해도 통과되는 버그가 있어, 수정해 줘”
    • Git 커밋: “변경 사항을 설명적인 메시지로 커밋해 줘”
    • 테스트 작성: “이 함수에 대한 단위 테스트 작성해 줘”

    중요한 안전장치 하나. 파일을 수정하기 전에 항상 사용자의 승인을 요청한다. 모든 변경이 본인의 OK 후에야 적용되기 때문에 마음 편히 시켜도 된다.

    알아두면 유용한 명령어

    명령어 기능
    claude 대화형 모드 시작
    claude "작업 내용" 일회성 작업 실행
    claude -c 직전 대화 이어서 시작
    /clear 대화 기록 초기화
    /help 사용 가능한 명령 전체 보기
    /doctor 설치 상태 자가 진단

    입문 단계에서 가장 자주 쓰게 되는 건 /clear/help 두 개다. 막혔을 때 /doctor를 기억해 두면 troubleshooting이 쉬워진다.

    그래서 — 5분이면 충분하다

    Claude Code는 단순한 코드 완성 도구가 아니다. 프로젝트 전체 맥락을 파악하고, 파일 사이의 연결을 이해하면서 작업한다. 이게 다른 도구와의 가장 큰 차이다. 기존에 Claude Pro를 구독 중인 사람이라면 추가 비용 없이 지금 당장 시작할 수 있다는 점도 결정 비용을 0에 가깝게 만든다. 설치 5분, 첫 대화 1분이면 충분하다.

    지금 할 일

    위에 정리된 한 줄 명령어로 Claude Code를 5분 안에 설치한다. 이미 진행 중인 프로젝트 폴더로 들어가 claude를 실행한 다음, 첫 질문은 “이 프로젝트 설명해 줘”로 시작해 보자. AI가 본인 코드베이스를 어떻게 이해했는지 한 화면에 드러난다. 그 다음 단계는 평소 미뤄 두고 있던 작은 버그나 기능 추가를 자연어로 시켜 보는 것. 그 한 사이클을 끝내면 Claude Code의 진짜 매력이 손에 잡힌다.

    관련 글

    출처

  • AI가 쓴 논문이 동료 심사 통과 — Sakana AI Scientist v2의 충격적 성과

    심사위원 세 명이 한 논문을 읽고 점수를 매겼다. 6점, 7점, 6점. 평균 6.33점으로 동료 심사를 통과했다. 그런데 저자 칸에 사람 이름이 없었다. 가설을 세운 것도, 실험을 설계한 것도, 데이터를 분석하고 글을 쓴 것도 모두 AI였다. 2025년 4월, Sakana AI가 공개한 AI Scientist v2의 논문이 머신러닝 최상위 학술 행사 ICLR의 워크숍 동료 심사를 통과하면서 연구계에 조용한 충격이 퍼졌다.

    이 사건이 단순한 기술 시연인지, 대학원생과 연구자의 일하는 방식이 바뀌는 신호탄인지 — 두 질문 모두 진지하게 다뤄야 할 시점이다.

    심사위원은 몰랐다

    Sakana AI는 세 편의 완전 자동 생성 논문을 ICLR 2025 워크숍에 제출했다. 심사는 이중 맹검으로 진행됐고, 심사위원들은 “AI가 쓴 논문이 포함됐을 수 있다”는 사실만 안내받았을 뿐 어느 논문이 AI 작성인지는 알지 못했다. 결과는 세 편 중 한 편 통과. 통과한 논문 제목은 「Compositional Regularization: Unexpected Obstacles in Enhancing Neural Network Generalization」이다.

    중요한 디테일 한 가지. Sakana AI는 ICLR 조직위와 브리티시컬럼비아대 IRB(연구윤리위원회) 승인을 받고 실험을 진행했다. 심사 통과 이후에는 논문을 자진 철회했는데, 이유는 명확했다. “AI 생성 논문을 동일 학술지에 게재할지에 대해 커뮤니티가 아직 합의에 이르지 못했다.” 학술 무결성에 대한 자기 절제가 포함된 실험이었다.

    v1과 v2의 결정적 차이 — 코드 템플릿이 사라졌다

    AI Scientist v2가 이전 버전과 결정적으로 다른 점은 한 가지다. 인간이 작성한 코드 템플릿에 의존하지 않는다. v1은 사전에 작성된 실험 코드 틀 위에서만 작동했다. v2는 백지에서 시작해 스스로 실험을 구성한다.

    핵심 기술은 프로그레시브 에이전틱 트리 탐색(Progressive Agentic Tree Search)이다. 연구 방향을 트리 구조로 탐색하면서 유망한 가지는 확장하고 성과가 낮은 경로는 자동으로 가지치기한다. 실험 관리 전담 에이전트가 이 과정을 조율하고, VLM(시각 언어 모델) 피드백 루프가 그래프와 수식을 포함한 논문의 시각적 완성도를 반복 개선한다. 전체 파이프라인이 가설 수립 → 실험 설계 → 코드 작성 → 데이터 분석 → 시각화 → 논문 작성 → 자체 검토까지 완전 자동화돼 있다.

    한계와 맥락 — 과장 광고인가, 진짜 이정표인가

    이 결과를 균형 있게 읽으려면 몇 가지 단서를 같이 봐야 한다. TechCrunch 등 주요 매체는 통과한 워크숍 트랙의 수락률이 약 30~60%로, ICLR 메인 트랙(수락률 약 20%)보다 관문이 낮다는 점을 지적했다. 세 편 중 한 편만 통과했고, Sakana AI 자체 검토에서도 메인 트랙 기준을 충족하는 논문은 없었다.

    기술적 한계도 분명하다. 실험의 42%가 코딩 오류로 실패했고, 인용 오류도 발견됐다. 기존에 알려진 개념을 새로운 발견으로 오분류하는 사례도 있었다. 학술 무결성 측면의 우려도 가볍지 않다. AI 생성 논문이 급격히 늘면 할루시네이션 인용을 포함한 논문이 학술 데이터베이스를 오염시킬 위험이 있고, 심사위원의 부담도 늘어난다. 이건 단순한 기술 진보가 아니라 학술 인프라 전체의 구조 변화를 요구하는 사건이다.

    그러나 이 모든 한계에도 불구하고 부정할 수 없는 한 가지 사실이 남는다. AI가 인간 심사위원이 모르는 상태에서 동료 심사를 통과했다. 이전에는 없던 일이다.

    한국 연구자·대학원생에게 의미

    이 사건을 한국 학술 현장 관점에서 읽으면 세 층위로 나뉜다. 첫째, 연구 보조 도구로서의 현실적 활용. AI Scientist v2의 파이프라인은 GitHub에 오픈소스로 올라와 있다. 지금 당장 논문을 통째로 AI에 맡기는 건 무리지만, 가설 탐색·실험 설계 초안·문헌 정리 단계에서 연구 속도를 높이는 도구로 활용하는 건 충분히 현실적이다. 특히 반복 실험이 많은 딥러닝·ML 연구실에서 즉각적인 생산성 향상이 가능하다.

    둘째, 논문 심사와 학술 투명성 기준 변화. 국내 주요 학회와 저널도 조만간 AI 생성 논문 표기 의무화, AI 심사 보조 도입 같은 정책 변화를 검토해야 할 시점이다. 본인이 투고하는 저널의 AI 활용 정책을 지금부터 파악해 두는 게 안전하다. 셋째, 대학원생 역할의 재정의. AI가 실험 설계와 데이터 분석을 대신할 수 있다면 연구자의 핵심 가치는 “무엇을 왜 연구할 것인가”라는 질문 설정 능력과 결과를 비판적으로 검증하는 능력으로 옮겨 간다. AI 도구를 모르는 게 리스크가 되는 시대로 들어서고 있다.

    지금 할 일

    ML 연구자라면 github.com/SakanaAI/AI-Scientist-v2 레포를 한 번 클론해 보는 게 가장 빠른 시작이다. 에이전틱 트리 탐색이 실제로 어떻게 작동하는지 코드 단위로 볼 수 있다. 더 가벼운 진입은 arxiv.org/abs/2504.08066에서 원문을 30분 정독하는 것이다. 마지막으로 본인이 준비 중인 논문이 있다면 투고 예정 저널의 Author Guidelines에서 AI 관련 항목을 지금 확인해 두자. Nature, ACM, IEEE 등 주요 출판사는 이미 AI 활용 표기 의무 정책을 시행 중이다.

    관련 글

    출처

  • Alibaba Qwen3.5 Omni 출시 — GPT-4o급 음성·영상·텍스트 멀티모달 AI, 지금 써보는 법

    “GPT-4o급”이라는 표현은 마케팅에서 가장 흔하면서도 가장 검증하기 어려운 수식어다. 3월 30일 Alibaba Qwen 팀이 공개한 Qwen3.5-Omni가 그 표현을 들고 나왔다. 텍스트·이미지·오디오·영상을 단일 모델로 처리하고 실시간 음성 대화까지 가능하다는 주장이다. 같은 주에 에이전틱 LLM Qwen 3.6 Plus도 함께 공개되면서 한 주 만에 두 개의 굵직한 카드가 나왔다.

    이 글은 그 주장 안에 무엇이 사실이고 무엇이 마케팅인지를 따져 보기 위한 것이다.

    모델의 뼈대 — 4가지 감각의 단일 파이프라인

    Qwen3.5-Omni의 핵심 차별점은 멀티모달 처리의 통합 방식이다. 기존 모델 대부분은 텍스트, 이미지, 오디오를 각자 다른 파이프라인으로 처리한 뒤 결과를 합친다. Qwen3.5-Omni는 단일 컴퓨팅 파이프라인 안에서 네 가지 모달리티를 동시에 다룬다. Thinker-Talker 구조와 Hybrid-Attention MoE를 채택했고, 1억 시간 이상의 오디오·비주얼 데이터로 사전 학습된 Audio Transformer 인코더를 사용한다.

    구체 사양은 다음과 같다.

    • 컨텍스트 윈도우 256K 토큰. 음성 10시간 이상, 720p 영상 400초 이상(1 FPS) 처리
    • 음성 인식 113개 언어·방언, 음성 생성 36개 언어 (한국어 포함)
    • 실시간 턴테이킹 — 사용자가 말을 끊으려는 의도와 단순 추임새(“응”, “어”)를 구분하는 네이티브 대화 인식
    • Audio-Visual Vibe Coding — 영상과 음성 지시만으로 코드 작성. 손 스케치를 카메라로 보여주면 React 웹페이지로 변환

    마지막 항목이 흥미롭다. 음성과 영상을 입력으로 하는 코딩이라는 발상은 실험적이지만, 작동만 한다면 접근성 측면의 의미가 크다.

    벤치마크 — 정말 GPT-4o를 앞서는가

    Alibaba는 Qwen3.5-Omni-Plus가 215개 오디오·오디오비주얼 서브태스크에서 SOTA를 달성했다고 발표했다. 주요 수치를 모아 보면 이렇다.

    • MMMU(다중모달 이해): Qwen3.5-Omni 82.0% vs GPT-4o 79.5%
    • HumanEval(코딩): 92.6% vs GPT-4o 89.2%
    • LibriSpeech WER(음성 인식 오류율): 1.7% vs GPT-4o 2.2% (낮을수록 우수)
    • 음성 안정성(Seed-zh): 1.07점 — ElevenLabs(13.08), Gemini 3.1 Pro(2.42), GPT-Audio(1.11)를 앞섬

    표 위에서 보면 결과는 분명해 보인다. 특히 오디오 이해·추론·인식·번역 전 영역에서 Gemini 3.1 Pro까지 앞선다는 점은 눈에 띈다. 다만 한 가지 단서가 빠지면 안 된다. 이 수치는 Alibaba 측 자체 측정값이다. 독립 검증이 나오기 전까지는 마케팅 숫자로 한 칸 미뤄 두는 게 안전하다. 한국어 성능이나 실제 한국 콜센터 음성에서의 동작은 직접 돌려 봐야 답이 나온다.

    같은 주에 나온 또 한 카드 — Qwen 3.6 Plus

    같은 시기에 공개된 Qwen 3.6 Plus는 성격이 완전히 다르다. 멀티모달이 아니라 에이전틱 능력에 집중한 플래그십 LLM이다. 컨텍스트 윈도우 1M 토큰(약 2,000페이지 분량을 단일 요청으로 처리), Terminal-Bench 2.0에서 61.6점을 기록해 Claude Opus 4.6의 59.3점을 앞섰다. 터미널 기반 에이전트 작업에서 Claude의 우위가 처음 흔들렸다는 뜻이다. Always-On CoT 구조로 추론 토큰을 최소화하면서 에이전트 신뢰도를 높이는 설계가 더해졌다.

    가장 매력적인 점은 OpenRouter에서 qwen/qwen3.6-plus-preview:free로 무료 프리뷰가 열려 있다는 것이다. 가장 가벼운 검증 경로가 만들어졌다.

    접근 경로 — 단, 완전 오픈소스는 아니다

    여기서 한 가지 주의가 필요하다. Qwen3.5-Omni는 완전 오픈소스가 아니다. Plus·Flash 변형은 현재 API 전용으로만 공개됐고, 모델 가중치는 공개되지 않았다. Alibaba가 그동안 유지해 온 오픈소스 행보에서 한발 물러난 결정이다. 클라우드 의존성이라는 비용을 감수해야 한다는 뜻이기도 하다.

    접근 가능한 경로는 여러 가지다. Alibaba DashScope API는 OpenAI 호환 인터페이스를 제공하고, 한국에서는 싱가포르나 미국 리전으로 접근할 수 있다. Hugging Face Spaces에서 Qwen3.5-Omni Offline Demo로 Light 변형을 체험해 볼 수 있고, Qwen 3.6 Plus는 OpenRouter 무료 프리뷰가 있다. 전 세대인 Qwen3-Omni는 GitHub QwenLM 레포에 오픈소스로 올라와 있어 로컬 실행이 가능하다.

    한국 개발자·스타트업에게 의미

    이번 발표가 한국 시장에 던지는 메시지는 세 갈래다. 첫째, 음성 AI 비용 장벽이 한 단계 낮아진다. GPT-4o Audio API는 가격이 비싸기로 유명한데, Qwen3.5-Omni가 비슷한 성능을 더 낮은 비용으로 제공한다. 한국어를 포함한 113개 언어 인식이라는 점이 한국어 음성 앱을 만드는 팀에게 직접적인 검토 가치가 된다. 둘째, 에이전트 작업에서 Claude를 대체할 옵션이 생겼다. Qwen 3.6 Plus가 Terminal-Bench 2.0에서 Claude Opus 4.6을 앞섰다는 결과는 — 자체 측정이라는 단서를 감안해도 — 비용 대비 성능을 재검토할 이유로는 충분하다. 셋째, 멀티모달 파이프라인을 단일 API로 통합할 수 있다는 가능성. 텍스트 모델·음성 인식 모델·영상 분석 모델을 따로 연결하던 구조가 한 번에 정리된다면 인프라 복잡도가 크게 줄어든다.

    다만 Plus·Flash가 API 전용이라는 점, 그리고 Alibaba 클라우드 의존성이 새로 생긴다는 점은 프로덕션 도입 전에 충분히 따져 봐야 한다.

    지금 할 일

    가장 가벼운 검증 경로는 OpenRouter에서 Qwen 3.6 Plus 무료 프리뷰를 한 번 돌려 보는 것이다. 평소 Claude나 GPT에 던지던 긴 문서 요약이나 코딩 에이전트 작업을 같은 프롬프트로 던져 비교해 보면 한 시간 안에 감이 잡힌다. 멀티모달이 궁금하다면 Hugging Face Spaces의 Qwen3.5-Omni Offline Demo가 가장 빠른 입구다. API를 본격적으로 쓰려는 단계라면 DashScope에서 무료 크레딧을 받아 OpenAI SDK의 base_url만 갈아 끼우면 곧바로 연동된다.

    관련 글

    출처

    대표이미지 출처: Qwen 공식 사이트

  • MCP 9,700만 설치 돌파 — AI 에이전트 인프라 표준은 이미 결정됐다

    표준 전쟁의 승자가 결정되는 순간은 보통 조용하다. AI 인프라 영역에서 그 일이 막 일어났다. 2024년 11월 Anthropic이 공개한 Model Context Protocol(MCP)이 16개월 만에 SDK 누적 다운로드 9,700만 건을 돌파했고, OpenAI·Google·Microsoft·AWS가 모두 채택했으며, 운영 주체는 Linux Foundation 산하 비영리 재단으로 넘어갔다. 종합하면 한 줄이다. AI 에이전트 인프라의 표준은 이미 정해졌다.

    9,700만이라는 숫자가 흔치 않은 이유

    16개월. 일반적인 개발자 인프라 표준이 5년에 걸쳐 도달하는 규모를 16개월에 이뤘다. 비교를 위해 다른 표준의 채택 곡선을 떠올려 보면 이 차이가 더 분명해진다. React가 npm 누적 1억 건에 도달하는 데 3년이 걸렸고, Kubernetes가 사실상 표준이 되기까지는 약 4년이 걸렸다. MCP는 그 곡선을 압축했다.

    현재 프로덕션 환경에서 운영 중인 MCP 서버는 1만 개 이상. ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code 같은 주요 AI 플랫폼이 모두 MCP를 기본 지원한다. 더 무거운 사실은 그 뒤에 있는 기업들의 면면이다. 평소에는 서로 직접 경쟁하는 OpenAI·Google·Microsoft·AWS·Cloudflare·Bloomberg가 단 하나의 프로토콜에 동시에 손을 들었다. 기술적 우수성을 넘어서 생태계 전략 차원의 합의가 이뤄졌다는 신호다.

    Linux Foundation으로의 이관 — 중립 표준의 완성

    2025년 12월 9일, Anthropic은 MCP를 Linux Foundation 산하의 새로운 비영리 단체에 기증했다. 이름은 Agentic AI Foundation(AAIF). 이 재단은 Anthropic·Block·OpenAI가 공동 창립했고, Google·Microsoft·AWS·Cloudflare·Bloomberg가 플래티넘 멤버로 참여한다. 한 회사가 독점적으로 소유하는 기술이 아니라 업계 공동의 표준 거버넌스 아래 관리되는 인프라가 됐다는 뜻이다.

    AAIF가 출범하면서 함께 발표한 메시지가 흥미롭다. “AI 에이전트가 투명하고 협력적인 방식으로, 공공 이익에 부합하도록 진화하는 것을 보장한다.” 자기 회사가 만든 프로토콜을 자기가 통제하기를 포기한 결정의 배경이다. AAIF는 MCP 외에도 Block의 goose와 OpenAI의 AGENTS.md를 초기 프로젝트로 포함하며 에이전트 생태계 표준화를 본격적으로 추진하고 있다.

    MCP가 실제로 하는 일 — 한 줄 비유

    MCP를 가장 정확히 설명하는 비유가 있다. AI 에이전트용 USB-C. USB-C가 등장하기 전까지는 노트북마다 충전 단자가 달랐다. 어댑터 가방을 챙기는 게 일상이었다. MCP 이전에도 비슷했다. AI 모델마다, 도구마다, 데이터 소스마다 별도의 연동 코드를 짜야 했다. 같은 Slack을 Claude에서 쓰려면 Claude용 어댑터, ChatGPT에서 쓰려면 ChatGPT용 어댑터가 따로 필요했다.

    MCP는 이걸 단일 인터페이스로 정리한다. AI 모델이 외부 데이터베이스, CRM, 개발 도구, 클라우드 서비스에 표준화된 방식으로 접근하고 도구를 호출할 수 있게 만든다. 한 번 잘 만든 MCP 서버는 어떤 AI에서도 그대로 동작한다. 현재 공개된 MCP 서버만 5,800개가 넘고, 사내 운영을 포함한 전체 프로덕션 서버는 1만 개를 넘었다.

    한국 개발자·기업에게 의미

    표준이 결정됐다는 추상적인 사실은 현장에서 네 가지 구체적 변화로 떨어진다.

    첫째, 새로운 AI 에이전트를 도입할 때 “MCP를 지원하는가”가 필수 체크 항목이 됐다. MCP를 지원하지 않는 솔루션은 점점 고립된 섬이 된다. 기업 도입 평가 표에 한 줄로 추가해 둘 만하다. 둘째, 사내 시스템 데이터 연동 비용이 결정적으로 낮아진다. ERP·CRM·DB 위에 MCP 서버를 한 번 올려 두면 이후 어떤 MCP 호환 AI도 별도 작업 없이 바로 붙는다. 사내 표준 인프라 후보 1순위다. 셋째, 한국어·한국 서비스 MCP 서버라는 빈자리가 있다. 현재 글로벌 MCP 서버의 대부분은 영어권 서비스에 집중돼 있다. 네이버 클라우드, 카카오, 쿠팡, 국내 금융 시스템 연동 MCP 서버는 아직 개척지다. 넷째, AI 개발자 채용 공고에 MCP 이해가 기본 스펙으로 등장하기 시작했다. 지금 익혀 두면 향후 1~2년 동안 시장에서 우위를 점할 수 있다.

    지금 할 일

    가장 가벼운 시작은 modelcontextprotocol.io에서 공식 사양과 튜토리얼을 한 번 훑는 것이다. Python·TypeScript SDK가 모두 준비돼 있다. 개발 경험이 적다면 Claude Desktop 설정에서 로컬 MCP 서버 하나를 연결해 보는 게 가장 직관적이다. 파일 시스템이나 GitHub 같은 오픈소스 MCP 서버를 5분 안에 붙여 보면 AI가 외부 도구를 어떻게 호출하는지 한눈에 들어온다. 사내 도입을 검토 중이라면 벤더 평가 항목에 “MCP 호환 여부” 한 줄을 지금 추가해 두자. 2~3년 안에 결정의 무게가 분명해진다.

    관련 글

    출처

  • OpenAI Sora 서비스 종료 — 출시 6개월 만에 실패한 이유와 지금 쓸 수 있는 대안 3가지

    3월 24일, OpenAI가 조용히 공지 하나를 올렸다. AI 영상 생성 서비스 Sora의 종료. 출시 6개월도 채 안 된 시점이었다. 한때 영상 생성 AI의 끝판왕으로 불리며 전 세계 크리에이터의 기대를 한 몸에 받았던 서비스가 왜 이렇게 빠르게 사라졌을까. 그리고 그 자리에서 떠난 사용자들은 지금 어디로 갔을까.

    숫자가 말해 주는 죽음의 곡선

    Sora는 2025년 말 정식 출시 직후 반짝 흥행에는 성공했다. 월 사용자 수 100만 명을 돌파하며 화제가 됐지만, 곡선이 너무 빨리 꺾였다. 종료 직전에는 50만 명 이하. 절반 이상이 떠난 셈이다. 표면 이유는 여러 가지가 거론됐지만 실제로는 한 가지 단순한 사실이 결정적이었다. 비용 구조가 작동하지 않았다.

    고화질 영상 생성에는 막대한 GPU 연산이 필요하다. 업계 추산에 따르면 Sora의 하루 운영 비용은 약 100만 달러(약 13억 원). 구독료 수입으로 메우기에는 너무 큰 격차였다. 단가가 비싼 영상 생성 작업의 대부분이 무료 체험과 저가 플랜에서 발생했다는 점도 부정적이었다.

    Disney 파트너십 — 신뢰의 균열

    가장 충격적이었던 디테일은 Disney와의 파트너십 처리 방식이다. Disney는 Sora와 10억 달러 규모의 콘텐츠 제작 파트너십을 체결했는데, 서비스 종료 통보는 종료 직전에야 받았다고 알려졌다. 이 정도 규모의 B2B 고객조차 충분한 사전 협의 없이 끊겼다는 사실은 OpenAI의 엔터프라이즈 신뢰도에 적지 않은 타격을 줬다는 평가가 따라붙는다.

    이 부분이 단순한 해프닝이 아닌 이유는 명확하다. 한국 기업 고객 입장에서도 같은 일이 벌어질 수 있다는 신호로 읽힌다. AI 서비스를 핵심 워크플로에 박아 넣는 결정을 할 때 SLA와 종료 통지 조항을 한 번 더 확인할 이유가 생긴다.

    이탈 사용자들이 향한 곳

    Sora 종료 발표 당일, Kling AI(콰이쇼우)가 애플 앱스토어 무료 앱 차트 상위권에 진입했다. 우연이 아니다. Sora 이탈 사용자들이 곧바로 대안을 찾아 옮겨 간 결과다. 현재 영상 생성 AI 시장의 주요 대안은 세 갈래로 정리된다.

    Kling AI는 콰이쇼우가 만든 모델이다. 최대 2분 영상, 1080p 품질, 무료 플랜까지 갖춘 가성비 카드다. Sora 종료 이후 한국 크리에이터 커뮤니티에서도 빠르게 알려지고 있다. Runway Gen-4는 정반대 포지션이다. 할리우드 프로덕션이 쓰는 정밀 편집과 일관된 캐릭터 유지가 강점이고 가격대도 그에 맞게 높다. Pika Labs는 빠른 생성과 단순한 UI로 처음 영상 AI를 만져 보는 사람에게 진입 장벽이 가장 낮다.

    세 서비스 모두 Sora 종료 이후 트래픽이 눈에 띄게 늘었다는 보고가 함께 나오고 있다.

    Sora 실패의 진짜 의미

    이번 사건은 단일 서비스 하나의 실패가 아니다. OpenAI가 ChatGPT 이후 새 수익원을 찾는 과정에서 마주친 구조적 한계를 드러낸 사건이다. 텍스트 AI는 토큰당 비용 곡선이 빠르게 내려갔지만 영상 생성은 그렇지 않다. 같은 가격으로 같은 품질을 내는 데 들어가는 GPU 자원의 차이가 너무 크다.

    또 한 가지 신호. OpenAI는 ChatGPT·Codex·Atlas 통합으로 슈퍼앱 전략을 강화하는 중이다. Sora처럼 별도 서비스로 운영하던 라인을 정리하고 핵심 플랫폼 안에 기능을 통합하는 방향으로 선회하는 것으로 보인다. 이번 종료는 그 정리 과정의 첫 번째 신호일 가능성이 높다.

    그래서 — 한국 사용자에게 의미

    Sora에 월정액을 결제하고 있었다면 즉시 구독 취소와 청구 내역 확인이 첫 번째 조치다. 더 중요한 건 이번 사건이 던지는 세 가지 메시지다. 첫째, OpenAI가 모든 영역을 이긴 건 아니다. 텍스트의 압도적 지위가 영상으로 자동으로 이어지지 않는다. 분야별 전문 도구를 병행하는 전략이 여전히 유효하다. 둘째, 중국산 AI 도구의 부상을 더 이상 무시하기 어렵다. Kling AI 같은 가격·품질 경쟁력을 갖춘 서비스가 한국 시장에도 빠르게 들어오고 있다. 데이터 보안 이슈를 감안하되 기능 면 비교는 필요하다. 셋째, 단일 AI 서비스에 깊이 의존하는 건 위험하다는 점이 한 번 더 입증됐다. 최소한 2~3개 대안을 늘 같이 테스트해 두는 습관이 필요하다.

    지금 할 일

    가장 빠른 대안 탐색은 세 도구를 한 시간씩 굴려 보는 것이다. klingai.com에서 무료 크레딧을 받아 Sora와 비슷한 프롬프트를 던져 본다. runwayml.com에서는 무료 플랜으로 125 크레딧을 받을 수 있다. pika.art는 가입과 동시에 시작 가능하다. 같은 프롬프트로 세 결과를 비교하면 본인 작업에 어느 도구가 맞는지 한 시간이면 답이 나온다.

    관련 글

    출처

  • Google Gemma 4 오픈소스 공개 — Apache 2.0으로 상업 이용 전면 허용, 지금 바로 쓰는 법

    AI 모델의 성능 발표는 이제 일주일이 멀다 하고 나온다. 그 사이에서 주목할 만한 변화는 사실 모델 능력보다 라이선스에서 나오는 경우가 있다. 4월 2일 Google이 Gemma 4를 공개하면서 함께 발표한 한 줄이 그렇다. 이번 공개부터 라이선스가 Apache 2.0이다. 이전 Gemma 시리즈가 들고 있던 자체 라이선스의 조건들이 통째로 사라졌다는 뜻이다. 모델 능력은 그 다음 이야기다.

    왜 라이선스 변경이 더 큰 뉴스인가

    Gemma 1·2·3은 Google 자체 Gemma Terms of Use 라이선스를 따랐다. 연구·비상업 목적에는 관대했지만 상업 서비스에 적용할 때는 별도 조건 충족이 필요했고, “월간 활성 사용자 1억 명 이상 서비스는 Google과 별도 협의” 같은 조항이 기업 법무팀의 검토 부담을 만들었다. 이 한 줄 때문에 한국 기업이 Gemma를 도입할 때마다 몇 주짜리 검토 절차가 생기곤 했다.

    Apache 2.0은 OSI 공식 승인 라이선스다. 수정·배포·상업 이용 모두 자유롭고, 특허 사용권까지 포함돼 법적 리스크가 낮다. 소스코드 공개 의무도 없다(GPL과 가장 큰 차이). 한 마디로 정리하면 — Gemma 4를 자사 서비스에 탑재해 수익을 내도 Google에 따로 허락을 구하거나 비용을 낼 필요가 없다. Google Open Source Blog는 “개발자 커뮤니티의 오랜 요청을 반영했다”고 설명했지만, 사실 이건 Llama·Mistral 계열에 비해 Gemma가 가지고 있던 가장 큰 약점 하나를 없앤 결정에 가깝다.

    Gemma 4 라인업 — 4가지 사이즈

    모델 자체도 검토해 둘 만하다. Google DeepMind는 Gemma 4를 Gemini 3와 동일한 연구·기술 기반 위에서 만들었고, 네 가지 크기로 나눠 공개했다.

    • E2B (Effective 2B): 스마트폰·엣지 디바이스 수준. 추론 시 활성 파라미터 약 2B
    • E4B (Effective 4B): 노트북·소형 서버 수준. 활성 파라미터 약 4B
    • 26B-A4B (MoE): 전체 26B 중 추론 시 3.8B만 활성. 속도는 4B급, 품질은 26B급
    • 31B Dense: 전 파라미터 상시 활성. 일관된 고품질 응답, 파인튜닝 베이스로 최적

    주목할 수치는 두 가지다. 31B 모델이 Chatbot Arena 글로벌 랭킹에서 전체 3위(오픈모델만이 아니라 유료 상용 모델 포함)에 올랐고, 26B MoE도 6위에 안착했다. 사이즈 대비 성능 효율이 매우 높다. 멀티모달 기능도 강화됐다 — 텍스트·이미지·음성·영상 입력을 네이티브로 처리하고 한국어 포함 140개 이상 언어를 지원하며, 컨텍스트 윈도우는 최대 256K 토큰이다.

    받는 곳 세 군데

    Hugging Face에서 google/gemma-4-31b-it, google/gemma-4-26b-a4b-it, google/gemma-4-e4b-it, google/gemma-4-e2b-it로 검색하면 된다. 계정 로그인 후 라이선스(Apache 2.0) 동의만 하면 즉시 다운로드된다. Kaggle Models에서도 Google 계정 연동으로 노트북에서 바로 활용할 수 있다. 가장 가벼운 진입은 Ollama다. 터미널에서 한 줄.

    ollama run gemma4

    Mac(Apple Silicon), Linux, Windows를 모두 지원한다. 로컬 실행 최소 사양은 E2B 기준 RAM 6GB, 31B Dense는 VRAM 20GB 이상의 GPU를 권장한다. RTX 4090이나 M3 Max 이상의 MacBook Pro면 31B를 실용 속도로 굴릴 수 있다. VRAM이 부족하면 GGUF 양자화 버전이 별도로 제공된다.

    한국 시장에 떨어지는 세 가지 변화

    Gemma 4 공개가 한국 시장에 주는 실질 변화는 라이선스 한 줄에서 나온다. 내용은 단순하다.

    첫째, 스타트업의 AI 서비스 출시 비용이 거의 0원이다. 챗봇, 고객 응대, 문서 요약 같은 기능을 만들 때 OpenAI API 비용 없이 충분한 성능의 모델을 확보할 수 있다. Apache 2.0이라 법무 검토 부담도 없다. E4B나 26B MoE 모델이면 웬만한 비즈니스 태스크는 충분히 소화한다.

    둘째, 데이터 보안이 필수인 금융·의료·공공 분야의 온프레미스 AI 도입이 현실화된다. 지금까지 규제 산업에서 외부 API 사용은 데이터 주권 문제로 기피 대상이었다. Gemma 4를 내부 서버에 직접 올리면 데이터가 외부로 나갈 일이 없고, 상업적 제약도 없으니 서비스 운영도 자유롭다.

    셋째, 한국어 특화 파인튜닝 모델 제작과 상업 배포가 합법이다. 이전 라이선스 하에서는 파생 모델의 상업 배포에 제약이 있었다. Apache 2.0에서는 그 제약이 사라진다. 한국어 도메인 데이터로 파인튜닝한 모델을 만들어 SaaS로 판매하는 것까지 자유롭다.

    지금 할 일

    가장 빠른 경험은 ollama.com에서 Ollama를 설치하고 ollama run gemma4:e4b 한 줄로 E4B 모델을 띄우는 것이다. 8GB RAM 환경에서도 돌고, 평소 자주 던지는 질문 몇 개를 그대로 던져 보면 본인 작업에 맞는지 한 시간 안에 감이 잡힌다. 파인튜닝까지 가 보고 싶다면 Hugging Face 계정을 만들고 Google Colab이나 Kaggle 노트북에서 샘플 코드를 굴려 보는 게 다음 단계다. 이미 OpenAI API를 쓰는 프로젝트가 있다면 어떤 태스크가 Gemma 4 E4B나 26B MoE로 대체 가능한지 한 번 점검해 ROI를 계산해 보자. Apache 2.0이라는 라이선스가 그 결정을 훨씬 가볍게 만든다.

    관련 글

    출처

    대표이미지 출처: Google Blog

  • Claude 구독으로 OpenClaw 못 쓴다: 4월 4일부터 서드파티 하네스 별도 과금 시작

    4월 4일 아침, Claude 구독자에게 이메일이 도착했다. 요점은 한 줄이었다. 4월 4일부터 OpenClaw 같은 서드파티 하네스를 Claude 구독으로 쓸 수 없고, 별도 과금되는 Extra Usage로 분리된다는 것. 구독료를 내고 있는데도 추가 비용이 생긴다는 변경이 캐시 버그로 사용량이 폭증하던 시점에 떨어지면서 개발자 커뮤니티가 즉시 달아올랐다.

    이번 변경의 진짜 내용과 — 더 중요한 — Anthropic이 왜 이 카드를 꺼냈는지를 한 번 짚어 본다.

    구체적으로 무엇이 바뀌었나

    이전에는 Claude Pro·Max 구독자가 OpenClaw 같은 서드파티 도구를 자기 Claude 계정에 연결해 구독 한도 안에서 자유롭게 쓸 수 있었다. 4월 4일(한국 시간 5일 새벽)부터 이 구조가 둘로 갈라진다.

    • Claude Code, Claude Cowork, claude.ai 채팅 — 기존 구독 한도 그대로
    • OpenClaw 등 서드파티 하네스 — 구독과 별개로 Extra Usage(종량제) 차감

    Extra Usage는 쓴 만큼 내는 방식이다. Anthropic이 충격을 완화하기 위해 두 가지 카드를 같이 풀었다. 하나는 월 구독료에 상당하는 Extra Usage 크레딧 1회 지급(4월 17일까지 직접 수령 필수). 다른 하나는 Extra Usage 번들의 최대 30% 할인 선구매 옵션. 서드파티를 안 쓰는 사용자라면 사실상 아무것도 달라지지 않는다는 점을 한 번 더 짚어 둘 만하다.

    Anthropic이 이 카드를 꺼낸 진짜 이유

    Claude Code 총괄 Boris Cherny가 직접 설명했다. “우리 구독은 이 서드파티 도구들의 사용 패턴을 위해 설계되지 않았다.” 이 한 문장이 핵심이다.

    실제 이슈는 프롬프트 캐시 효율에 있다. Claude Code 같은 Anthropic 자체 도구는 캐시 히트율을 높이도록 최적화돼 있다. 한 번 처리한 컨텍스트를 재사용해 연산 비용을 낮추는 구조다. 반면 OpenClaw 같은 서드파티 하네스는 이 최적화 없이 매 요청마다 전체 컨텍스트를 새로 보내는 경우가 많다. 같은 구독료를 받아도 실제 서버 비용이 몇 배 차이가 난다는 뜻이다.

    최근 Reddit에서 제기된 Claude Code 캐시 버그 이슈로 일부 사용자의 사용량이 10~20배 폭증한 정황도 함께 작용한 것으로 보인다. Anthropic의 입장 자체는 명확했다. “용량은 신중하게 관리해야 하는 자원이며, 핵심 제품 사용자를 우선해야 한다.”

    커뮤니티의 두 갈래 반응

    Hacker News와 개발자 커뮤니티는 즉각 갈라졌다.

    납득하는 쪽 논리는 단순하다. 구독 모델은 태생적으로 사용자 대부분이 최대치를 안 쓴다는 가정 위에 서 있다. 에이전트를 24시간 돌리는 헤비 유저 한 명이 일반 사용자 수십 명의 비용을 잠식하는 구조는 지속 불가능하다.

    비판하는 쪽도 만만치 않다. 이미 5시간 윈도우와 주간 한도 같은 하드캡이 있는 상태에서, Claude Code 자체에도 루프와 크론 같은 자동화 기능이 내장돼 있는데 유독 서드파티만 차별하는 것은 일관성이 없다는 지적이다. OpenClaw 개발자 Peter Steinberger는 “Anthropic이 우리 기능을 흡수한 뒤 경쟁을 차단한 것”이라고 직접 비판했다. 다만 Boris Cherny가 API 사용자에게 캐시 최적화를 돕겠다고 제안하면서 감정의 날은 일부 누그러졌다.

    한국 Claude 구독자가 당장 해야 할 두 가지

    이 변경은 서드파티 하네스를 안 쓴다면 실질 영향이 없다. claude.ai, Claude Code, Claude Cowork를 그대로 구독 한도 안에서 쓰면 된다. 그러나 OpenClaw나 다른 서드파티 연동을 활용해 온 사람이라면 지금 당장 두 가지를 확인해야 한다.

    첫째, 무료 크레딧 수령. 4월 17일까지가 마감이다. Anthropic이 보낸 이메일의 “Redeem it here” 링크를 클릭해 월 구독료 상당의 Extra Usage 크레딧을 받아 두자. 기한을 놓치면 사라진다. 둘째, 사용 패턴 점검. 본인이 서드파티 하네스를 어느 빈도로 쓰는지 파악하고 Extra Usage 번들 선구매(최대 30% 할인)가 경제적인지 계산해 본다. 사용량이 적다면 크레딧만으로 충분히 커버될 가능성이 높다.

    중장기 — API 직접 사용을 고려할 시점

    이번 사건은 한 가지 더 큰 메시지를 던진다. SaaS 가격 정책은 언제든 바뀔 수 있다는 것이다. 헤비 유저라면 지금이 Anthropic API 키 직접 사용을 검토할 시점일 수 있다. 토큰당 과금이라 비용 예측이 쉽고, Boris Cherny가 약속한 캐시 최적화 지원도 API 사용자에게 적용된다. 무엇보다 구독 정책 변경에 휘둘리지 않는 안정성이 가장 큰 가치다.

    지금 할 일

    가장 시급한 건 4월 17일 전에 Anthropic 이메일의 “Redeem it here” 링크로 무료 크레딧을 받는 것이다. 그다음 자기 Claude 계정에 연결된 서드파티 도구 목록을 한 번 점검하고 한 달 동안의 Extra Usage 예상 비용을 계산해 본다. 그 숫자가 부담스러운 수준이라면 console.anthropic.com에서 API 키를 발급해 토큰당 과금으로 전환하는 게 더 효율적일 수 있다.

    관련 글

    출처

  • Meta, 엔지니어 코드 75%를 AI로 작성하라: 성과평가에 AI 활용도 반영

    Meta, 엔지니어 코드 75%를 AI로 작성하라: 성과평가에 AI 활용도 반영

    Meta가 4월 3일 던진 메시지 한 줄. 엔지니어 코드의 75% 이상을 AI로 작성하라. 이게 권장사항이 아니라는 점이 결정적이다. 성과 평가 항목에 ‘AI 기반 임팩트’가 신설되면서 AI를 안 쓰는 엔지니어는 인사 평가에서 직접적으로 손해를 본다. 실리콘밸리에서 AI 코딩이 선택에서 의무로 넘어가는 순간이 됐다.

    구체적인 숫자 — 75%가 무엇을 뜻하는가

    Meta의 지시는 부서별로 조금씩 다르다. Facebook·WhatsApp·Messenger를 담당하는 Creation 조직에서는 엔지니어의 65%가 2026년 상반기까지 코드의 75% 이상을 AI 도구로 작성해야 한다. Scalable ML 부서는 50~80% 범위의 AI 코딩 목표를 설정했다. 약 1,000명 규모의 내부 도구 팀은 더 급진적이다. ‘AI Pod’로 재편되면서 기존 직함 대신 ‘AI 빌더’와 ‘AI Pod 리드’라는 새로운 역할을 부여받았다.

    이 숫자들이 단순한 권장 목표가 아닌 이유는 한 가지다. 2026년부터 Meta의 모든 직원은 성과 리뷰에서 ‘AI 기반 임팩트(AI-driven impact)’ 항목으로 평가받는다. AI 도구 활용이 단순 권장에서 공식 KPI로 격상됐다는 의미다. AI 코딩 도구 사용을 거부하는 엔지니어에게는 실질적 불이익이 돌아간다.

    왜 Meta가 가장 먼저 움직였나

    이 결정은 한 번에 나온 게 아니다. AI 코딩 생산성에 대한 경험적 증거가 누적된 결과다. 자주 인용되는 NBER(전미경제연구소) 연구에 따르면, 생성형 AI 접근권을 가진 고객 지원 에이전트 5,179명의 생산성이 평균 14% 향상됐다. 더 흥미로운 디테일은 그 안에 있다. 초보·저숙련 직원의 생산성은 34%까지 올랐다. 평균 14% 향상의 대부분이 주니어 그룹에서 나왔다는 뜻이다.

    코딩 분야의 효과도 비슷한 패턴을 보인다. 시니어 엔지니어의 생산성 향상은 비교적 완만하지만, 주니어와 미들 레벨에서는 효과가 크다. Meta가 노린 건 이 그룹의 생산성을 한 번에 끌어올리는 것이다. 1,000명 단위의 조직을 ‘AI Pod’로 재편한 것도 같은 맥락이다. 조직 구조 자체를 AI 활용을 전제로 다시 설계하지 않으면 도구 도입의 효과가 분산된다.

    이 변화가 던지는 노동의 질문

    Meta의 결정에는 두 가지 함의가 함께 있다. 하나는 명확한 효율성 향상 — AI를 잘 쓰는 엔지니어가 그렇지 않은 엔지니어보다 몇 배 더 빠른 결과를 내는 것은 더 이상 가설이 아니다. 다른 하나는 평가 시스템의 변화가 가져올 압박 — AI 활용이 KPI가 되는 순간, 엔지니어는 코드를 쓰는 사람에서 AI를 지휘하는 사람으로 역할이 옮겨 간다.

    이 변화가 모두에게 반가운 건 아니다. AI 도구 사용에 거부감이 있는 시니어 엔지니어, 자기 손으로 코드를 짜는 만족감을 중요하게 여기는 개발자, 검증되지 않은 AI 코드를 프로덕션에 올리는 것에 보수적인 입장 — 이런 의견들이 사내 토론에서 빠지지 않는다. 하지만 회사가 KPI로 박았다면 토론은 끝났다는 뜻이다.

    한국 IT 기업에 의미하는 것

    Meta 같은 빅테크가 AI 코딩을 KPI로 만들었다는 사실은 두 단계로 한국에 영향을 준다. 단기적으로는 시그널링 효과다. 글로벌 빅테크의 사례가 한국 대기업·중견기업의 AI 도구 도입 결정에 영향을 준다. “Meta가 75% 목표를 잡았는데 우리는 어떤가”라는 질문이 임원 회의에서 나오기 시작한다는 의미다.

    장기적으로는 채용과 평가 기준의 변화다. 2026~2027년 사이에 한국 IT 기업의 채용 공고와 성과 평가 기준에도 ‘AI 도구 활용 능력’이 명시적으로 들어갈 가능성이 높다. 지금 AI 코딩 도구를 한 번도 안 써 본 개발자라면 그 격차를 줄일 시간이 1년 안짝이다.

    지금 할 일

    가장 가벼운 시작은 cursor.com에서 무료 버전을 설치해 평소 만지는 프로젝트 폴더를 한 번 열어 보는 것이다. 자동완성 한두 번 써 보면 감이 잡힌다. VS Code를 이미 쓰고 있다면 GitHub Copilot 확장을 활성화하는 게 가장 진입 장벽이 낮다. 팀 단위 도입을 고민하는 리더라면 한 단계 더 들어가서 AI 생성 코드의 리뷰 기준과 보안 체크리스트부터 만들어 두자. 이게 없으면 도입 자체보다 사고 수습에 더 많은 시간이 들어간다.

    관련 글

    출처

  • 골드만삭스 “AI 생산성이 S&P 500을 7,600으로”: 기술주 넘어 전 산업 확산

    골드만삭스 “AI 생산성이 S&P 500을 7,600으로”: 기술주 넘어 전 산업 확산

    7,600. 4월 초 골드만삭스가 제시한 S&P 500 연말 목표치다. 현재 지수가 6,575~6,600 수준이라는 점을 감안하면 약 15%의 상승 여력. 단순 낙관 전망이 아니다. 핵심 근거는 한 줄로 정리된다. AI 생산성 향상이 기술주를 넘어 전 산업으로 확산되면서 기업 이익이 12% 성장한다.

    이 한 줄 안에 어떤 전제가 깔려 있는지 — 그리고 한국 투자자에게 어떻게 읽혀야 하는지를 짚어 본다.

    12% 이익 성장의 산수

    골드만삭스 전망의 핵심은 AI가 대규모 설비 투자(CAPEX) 단계를 지나 실질 생산성 향상으로 전환되고 있다는 판단이다. S&P 500 기업의 주당순이익(EPS)이 305~309달러 범위로 12% 성장하고, 선행 PER 22배 기준으로 “펀더멘털 바닥”이 형성된다는 논리다. 7,600이라는 숫자는 이 전제 위에서 자연스럽게 따라 나온다.

    중요한 단어는 “광범위한 마라톤”이다. 골드만삭스가 강조한 표현이다. 기술주 몇 종목이 끌어올리는 게 아니라, 비기술 섹터까지 AI 효과가 퍼지는 국면이라는 뜻이다. 이 차이가 결정적이다. 소수 종목 랠리는 깨지기 쉽지만 광범위한 이익 성장은 펀더멘털이 받쳐 준다.

    고용 시장이 함께 이 그림을 받쳐 준다

    4월 3일 발표된 미국 3월 비농업 고용 보고서가 흥미롭다. 31만 2,000개 일자리 증가. 시장 예상치 18만 5,000개를 크게 상회했다. AI가 일자리를 빼앗는다는 우려와 정반대 방향의 숫자다. AI를 도입한 기업들의 고용이 오히려 늘어나는 양상이 데이터로 확인된다.

    이 두 가지가 합쳐지면 골드만삭스가 그리는 그림이 입체적으로 보인다. AI 생산성 향상 → 기업 수익 증가 → 고용과 투자 확대 → 다시 생산성 인프라에 재투자. 단기적으로는 흔들릴 수 있지만 구조적으로는 선순환이 형성되고 있다는 해석이다.

    독주에서 확산으로 — 2026년이 분기점

    골드만삭스 애널리스트들은 2026년이 “기술주 독주에서 전 산업 확산”으로 전환하는 해라고 진단한다. 추상적인 표현이지만 구체 사례가 빠르게 누적되고 있다. GM은 AI로 차량 디자인 주기를 2주에서 하루로 단축했다. MLB는 구글 Gemini 기반 AI 해설 시스템 ‘Scout Insights’를 도입했다. 자동차, 스포츠, 금융, 의료 — 전통 산업의 생산성 향상 사례가 분기 실적에 등장하기 시작했다.

    이 패턴이 중요한 이유는 단순하다. AI 수혜 종목 = 기술주라는 단순 등식이 깨지고 있다는 신호다. 향후 1~2년 동안 진짜 알파는 비기술 섹터 안에서 AI를 가장 빠르게 흡수하는 기업에서 나올 가능성이 높다.

    한국 투자자에게 의미

    이 전망을 한국 시장 관점에서 읽으면 두 가지 포인트가 있다. 첫째, AI 테마주와 AI 활용 기업을 구분해서 봐야 한다는 점이다. 단순히 ‘AI’를 마케팅에 쓰는 회사가 아니라 AI를 실제 생산성 향상에 활용해 분기 실적이 개선되고 있는 기업이 진짜 알파의 후보다. 제조, 유통, 금융 같은 전통 섹터에서 그런 후보를 찾는 게 의미 있는 작업이다.

    둘째, 미국 시장과의 연동성이다. S&P 500이 7,600을 향해 움직인다면 그 흐름은 한국 코스피·코스닥에도 시차를 두고 영향을 준다. 직접 미국 종목에 노출되고 싶다면 ETF 쪽이 더 분산된 옵션이다. 단, 골드만삭스 전망 자체는 어디까지나 한 시나리오라는 점을 기억해 두자. 같은 데이터를 다른 IB가 다르게 해석하는 경우도 많다.

    지금 할 일

    본인이 미국 주식에 직접 노출되고 싶지 않다면 한국 상장사 중 AI 생산성 도구를 실제로 도입한 기업의 분기 실적을 한 번 훑어보는 게 출발점이다. 사업보고서에서 AI가 어떻게 비용 구조나 생산성에 반영되고 있는지를 보면 마케팅과 실체를 구분할 수 있다. 미국 시장을 직접 노린다면 AI 섹터 비중이 높은 ETF(QQQ, SOXX) 또는 전 산업 확산을 베팅하는 광범위 ETF(SPY, IVV)를 비교해 본인 리스크 성향에 맞는 쪽을 고르면 된다. 어느 쪽이든 한 종목에 몰빵하지 않는 게 골드만삭스 전망의 가장 큰 메시지다 — 광범위한 확산은 광범위한 노출로 잡는 게 자연스럽다.

    관련 글

    출처