Moony01 Studio

지금 스킬보다 MCP가 더 무서운 이유

Fri, 10 Apr 2026 09:20:00 +0000

오늘 개발자 타임라인에서 제일 흥미로운 건 새 모델 점수표가 아니었다. 2026년 4월 10일 오전 기준 Hacker News 상단에 올라온 글은 I still prefer MCP over skills였고, 댓글은 이미 세 자릿수를 넘겼다. 한국 쪽도 비슷했다. GeekNews에서는 Addy Osmani의 agent-skills 정리가 며칠째 회자되고 있고, 같은 날에는 마이리얼트립이 실제 비즈니스 API와 MCP 서버를 같이 공개했다.

이 조합이 왜 중요하냐면, 이제 논쟁의 초점이 “에이전트가 더 똑똑해졌나”가 아니라 “그 똑똑함을 어떤 형식으로 연결할 건가”로 옮겨갔기 때문이다. 내 기준으로 이 흐름은 꽤 선명하다. 팀 내부 규칙과 작업 습관을 주입하는 데는 스킬이 편하다. 반대로 외부 서비스, 인증, 업데이트, 원격 접근까지 걸리는 순간에는 MCP가 훨씬 단단한 선택지가 된다.

오늘 갑자기 이 논쟁이 커진 이유

HN와 GeekNews가 서로 다른 방향에서 같은 질문을 던졌다

Hacker News에서 화제가 된 글은 “스킬이 새 표준처럼 밀리고 있지만, 실제 서비스 연결에는 MCP가 더 낫다”는 주장이다. 반면 GeekNews에서 반응이 큰 agent-skills는 에이전트가 개발 생명주기 전체를 더 잘 따르도록 워크플로우를 패키징하는 방식에 가깝다. 둘은 겉으로 보면 반대처럼 보이지만, 사실 같은 질문을 던진다. 에이전트에게 무엇을 가르칠 것인가, 그리고 무엇을 직접 연결할 것인가.

관점	지금 더 강한 선택	이유
팀 규칙 전달	Skills	저장소 안에서 바로 공유하고 수정하기 쉽다
외부 서비스 연결	MCP	인증과 업데이트를 서버 경계 뒤로 숨길 수 있다
모바일 웹 원격 사용	MCP	클라이언트가 달라도 동일한 서버를 재사용할 수 있다
로컬 작업 습관 표준화	Skills	특정 저장소 맥락과 체크리스트를 붙이기 좋다

그래서 이 표가 중요한 이유는 어느 쪽이 “더 우월한 만능 해법”인지 가리기 위해서가 아니다. 역할이 다르다는 점을 놓치면 설계가 꼬인다. 최근 몇 주 동안 스킬 열풍이 빠르게 퍼진 건 사실이지만, 그 열기를 곧바로 서비스 통합 방식으로 확대 해석하는 순간 운영비와 보안 비용이 다시 튀어 오른다.

한국 커뮤니티도 이미 연결 문제로 이동했다

마이리얼트립이 GeekNews에 공개한 예시는 상징적이다. 이 팀은 콘텐츠가 아니라 실제 상품 데이터를 API와 MCP 서버로 개방했다. 말하자면 “에이전트에게 더 많은 사용법을 가르치자”가 아니라 “에이전트가 안정적으로 붙을 인터페이스를 내놓자” 쪽에 베팅한 셈이다.

이건 국내 팀들에게도 현실적인 시사점이 크다. 사내 도구, 정산 시스템, CRM, 재고 데이터처럼 살아 있는 시스템은 매주 바뀐다. 이런 세계에서는 길고 친절한 SKILL.md보다 인증과 버전 관리를 포함한 연결점 하나가 더 오래 간다.

스킬이 강한 순간은 분명히 있다

지식을 주입하고 행동 순서를 강제할 때

스킬이 매력적인 이유를 과소평가할 필요는 없다. Anthropic 문서가 설명하듯 스킬은 Claude에 새 작업 절차, 커스텀 명령, 팀 규칙을 붙이는 데 강하다. 예를 들어 “우리 팀은 PR 전에 접근성 체크리스트를 반드시 돌린다” 같은 규칙은 MCP 서버보다 스킬이 더 직접적이다. 저장소 안에 파일로 남고, 코드 리뷰와 함께 바뀌며, 팀원 모두가 같은 습관을 공유할 수 있다.

Addy Osmani의 agent-skills가 반응을 얻은 것도 이 지점 때문이다. 개발자는 종종 모델 품질보다 프로세스 품질에서 더 자주 실패한다. 스펙 없이 바로 코딩하고, 테스트를 미루고, 보안을 마지막에 붙인다. 이런 문제는 API 커넥터보다 체크리스트와 워크플로우 패키징이 더 잘 듣는다.

저장소 로컬 맥락이 핵심일 때

특정 레포지토리의 폴더 구조, 코딩 스타일, 리뷰 문화까지 에이전트가 알아야 한다면 스킬이 확실히 편하다. 실제로 MCP 앱 연동 가이드 같은 글을 다시 읽어보면, 툴 연결과 저장소 작업 방식은 서로 다른 층위라는 점이 더 선명해진다. 연결은 프로토콜 문제이고, 팀 습관은 문맥 문제다.

문제는 여기서 한 걸음 더 나갔을 때 생긴다. 많은 팀이 스킬 하나에 “툴 사용법 설명”, “서비스 인증 방법”, “예외 처리 절차”, “CLI 설치 안내”까지 다 우겨 넣기 시작한다. 그 순간 스킬은 지식 파일이 아니라 문서화가 덜 된 운영 런북이 된다.

서비스 연결은 왜 결국 MCP 쪽으로 기운나

인증과 업데이트를 분리할 수 있기 때문이다

MCP 문서의 핵심 철학은 단순하다. 모델은 무엇을 하고 싶은지만 알고, 실제 연결과 실행은 서버가 맡는다. 이 분리가 주는 체감 이점은 꽤 크다. 원격 MCP 서버는 로컬 설치 없이 붙을 수 있고, 서버가 갱신되면 클라이언트는 새 기능을 바로 가져간다. OAuth 같은 인증 흐름도 클라이언트와 서버 사이에서 정리되기 쉬워진다.

반대로 스킬 기반 통합은 자주 이런 모양이 된다. “먼저 CLI를 설치하고 환경 변수를 넣은 뒤 로그인 토큰을 저장하고 이 명령을 외우세요.” 이 방식이 작은 실험에서는 빨라도, 팀이 커질수록 기기별 차이와 토큰 관리, 버전 드리프트가 문제를 만든다. David Mohl의 글이 지적한 불편도 정확히 여기 있다. 우리는 커넥터가 필요한데, 자꾸 매뉴얼과 CLI 묶음을 통합이라고 부르고 있다.

복붙해서 바로 점검할 수 있는 것은 연결 방식이다

아래 예시는 오늘 GeekNews에 올라온 마이리얼트립 MCP 서버 설정이다.

{
  "mcpServers": {
    "myrealtrip": {
      "url": "https://mcp-servers.myrealtrip.com/mcp"
    }
  }
}

이 스니펫이 보여주는 건 거창한 철학이 아니다. “어디에 붙는지”가 먼저 드러난다는 점이다. 실무에서는 이게 크다. 누가 봐도 연결 대상이 명확하고, 서버가 바뀌면 중앙에서 갱신할 수 있으며, 여러 클라이언트가 같은 경계를 재사용할 수 있다.

직접 팀 상태를 점검해보고 싶다면 이런 식으로 확인하면 된다.

printf 'skills\\n'; find .claude/skills -name SKILL.md 2>/dev/null
printf '\\npossible mcp config\\n'; rg -n 'mcpServers|transport|url' . ~/.claude 2>/dev/null | head -n 20

첫 줄은 현재 저장소나 홈 디렉터리에서 스킬 자산이 얼마나 쌓였는지 보여주고, 둘째 줄은 실제 연결 설정이 어디에 모여 있는지 훑어보는 용도다.

내 팀이라면 둘을 이렇게 나눈다

스킬은 행동 표준화에만 쓴다

스킬에는 리뷰 기준, 테스트 순서, 릴리스 체크리스트, 우리 팀이 자주 틀리는 규칙만 넣는다. 길어져도 괜찮지만, 외부 서비스 비밀키를 어떻게 발급받는지 같은 운영 문서는 넣지 않는다. 그건 이미 다른 계층의 책임이기 때문이다.

MCP는 살아 있는 시스템 연결에만 쓴다

반대로 Notion, Slack, 사내 백오피스, 파트너 API처럼 데이터가 바뀌고 인증이 필요한 시스템은 가능하면 MCP 경계로 밀어 넣는다. 여기에는 보안과 유지보수 이유가 모두 있다. 모델이 서비스를 “사용”하는 것과 서비스의 내부 절차를 “설명받는” 것은 같은 문제가 아니다.

내 생각에 앞으로 잘하는 팀은 둘 중 하나를 버리는 팀이 아니라, 둘의 책임을 헷갈리지 않는 팀이 될 가능성이 크다. 스킬은 팀의 일하는 법을 패키징하고, MCP는 팀이 붙어야 할 시스템을 패키징한다. 이 선이 흐려지는 순간 에이전트는 똑똑해 보여도 운영은 더 지저분해진다.

이번 싸움이 남긴 한 가지

오늘의 논쟁을 한 줄로 줄이면 이렇다. 스킬은 에이전트의 습관을 바꾸고, MCP는 에이전트의 손이 닿는 세상을 바꾼다. 지금 시장이 다시 MCP 쪽을 쳐다보는 이유도 여기에 있다. 지시문 몇 장보다, 인증과 업데이트를 품은 연결점 하나가 훨씬 오래 버티기 시작했기 때문이다.

Anthropic이 숨긴 진짜 승부수 클로드 매니지드 에이전트

Thu, 09 Apr 2026 11:00:00 +0000

정작 놀라운 건 새 모델이 아니었다. 2026년 4월 8일 Anthropic이 내놓은 건 더 똑똑한 Claude가 아니라, 개발팀이 그동안 직접 붙들고 있던 에이전트 운영판 자체였다.

지난 몇 달 동안 팀들이 한 일은 비슷했다. 프롬프트를 짜고, 샌드박스를 만들고, 장시간 세션을 붙들고, 툴 실패를 복구하고, 자격 증명을 격리하고, 로그를 뒤쫓았다. 데모는 멋졌지만 운영은 늘 지저분했다. 그런데 Claude Managed Agents는 이 더러운 뒷정리를 통째로 서비스화했다. 그래서 이번 발표가 단순한 기능 추가가 아니라 판갈이로 읽힌다.

GeekNews 메인, WIRED 보도, Anthropic 공식 문서 공개가 같은 날 겹친 이유도 여기에 있다. 개발자 입장에서 이 제품은 “에이전트를 어떻게 만들까”보다 “이제 누가 운영 책임을 질까”라는 질문을 강제로 던진다.

왜 지금 다들 이걸 이야기하나

모델 경쟁보다 운영 경쟁이 됐다

Claude Managed Agents의 핵심은 단순하다. 에이전트 루프, 컨테이너 환경, 장시간 세션, 상태 이벤트, MCP 연결, 자격 증명 분리까지 Anthropic이 관리한다. 개발자는 시스템 프롬프트와 도구 구성을 정의하고, 실제 실행 인프라는 벤더가 가져간다.

이 변화가 큰 이유는, 에이전트 제품에서 가장 비싼 부분이 모델 추론만이 아니기 때문이다. 직접 만들어보면 금방 드러난다. 실패한 툴 호출 재시도, 세션 복구, 파일 시스템 청소, 토큰 격리, 감사 로그, 웹훅 설계가 실제 비용을 만든다. 내 경험으로도 사내 데모는 하루면 나오지만 운영 가능한 상태로 끌어올리는 데는 그 몇 배의 시간이 들었다.

당일 반응이 뜨거웠던 이유

4월 8일 공개 직후 공식 quickstart, skills, GitHub 연동 문서와 production cookbook이 동시에 열렸다. 이건 마케팅 페이지 한 장이 아니라 바로 붙여볼 수 있는 제품 번들에 가깝다. Reddit의 Claude 커뮤니티에서도 첫 반응이 “결국 클라우드 위의 Claude Code 아니냐”로 모였는데, 그 요약이 꽤 정확하다. 로컬 터미널에서 하던 일을 Anthropic이 관리하는 컨테이너로 옮겨놓은 셈이기 때문이다.

항목	직접 운영할 때	Managed Agents
에이전트 루프	앱에서 직접 구현	Anthropic 기본 제공
장시간 세션	큐와 워커 별도 설계	세션 이벤트와 웹훅 사용
자격 증명 분리	비밀 저장소 직접 설계	Vault 패턴 제공
GitHub 같은 외부 도구	개별 통합	MCP 기반 연결

그래서 이 표가 중요한 이유는 단순 편의성 때문이 아니다. 에이전트 제품의 진입장벽이 모델 성능에서 운영 설계로 이동했는데, Anthropic이 바로 그 병목을 상품으로 팔기 시작했다는 뜻이기 때문이다.

문서에서 읽히는 진짜 설계 의도

beta 헤더 하나에 철학이 들어 있다

공식 quickstart를 보면 모든 요청에 managed-agents-2026-04-01 베타 헤더를 요구한다. 이 한 줄이 의미하는 건 꽤 분명하다. Anthropic은 단순한 응답 API가 아니라 독립된 제품면을 따로 세우고 있다.

AGENT_ID=$(ant beta:agents create \
  --name "Coding Assistant" \
  --model "claude-sonnet-4-6" \
  --system "You are a coding assistant for production tasks." \
  --tool '{type: agent_toolset_20260401}')

curl -sS https://api.anthropic.com/v1/sessions \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d "{\"agent\":\"$AGENT_ID\",\"environment_id\":\"$ENV_ID\"}"

이 예시는 에이전트 정의와 세션 실행을 분리한다. 즉 프롬프트 한 번 던져 답을 받는 구조가 아니라, 재사용 가능한 운영 단위를 먼저 만들고 그 위에서 실행을 붙인다.

Skills와 GitHub MCP가 함께 붙는 순간

더 흥미로운 건 skills와 GitHub 문서다. skills는 파일시스템 기반 전문성을 에이전트가 필요할 때만 불러오게 하고, GitHub 문서는 저장소를 세션 컨테이너에 마운트한 뒤 MCP로 PR 생성까지 이어간다. 이 조합은 꽤 노골적이다. Anthropic은 “잘 대답하는 모델”보다 “도구를 가진 작업자” 시장을 직접 먹으려 한다.

ant beta:agents create \
  --name "Code Reviewer" \
  --model "claude-sonnet-4-6" \
  --system "Review code and open pull requests when needed." \
  --mcp-server '{type: url, name: github, url: https://api.githubcopilot.com/mcp/}' \
  --tool '{type: agent_toolset_20260401}' \
  --tool '{type: mcp_toolset, mcp_server_name: github}'

이 구성은 에이전트가 코드를 읽는 수준을 넘어, 저장소와 워크플로우 안으로 들어가도록 설계됐다는 뜻이다.

이전에 다뤘던 멀티 에이전트 오케스트레이션 가이드에서 병목은 언제나 조율 비용이라고 썼다. 이번 제품은 그 조율 비용을 프레임워크가 아니라 플랫폼으로 흡수하겠다는 선언에 가깝다.

개발팀이 실제로 잃는 것과 얻는 것

얻는 것 먼저 보면 꽤 솔깃하다

가장 큰 이득은 시간이다. 사내에서 에이전트 PoC를 붙여본 팀이라면, 처음 20퍼센트보다 마지막 20퍼센트가 훨씬 더 어렵다는 걸 안다. 감사 로그, 재시도, 멱등성, 세션 상태 추적, 사람 승인 지점 삽입이 그 마지막 20퍼센트다. Anthropic cookbook이 session idle webhook 패턴과 vault 분리 전략을 먼저 내세운 것도 그래서다.

본문 구조를 뜯어보면 Anthropic은 개발자가 원하는 환상을 잘 안다. “자율 에이전트”가 아니라 “장애를 덜 내는 에이전트”가 현업의 요구라는 점이다. 화려한 데모보다 운영성에 무게를 둔 문서 구성이 괜히 나온 게 아니다.

대신 잃는 것도 분명하다

반대로 잃는 것은 제어권이다. 에이전트 루프를 벤더가 쥐면, 디버깅 경계도 벤더 쪽으로 이동한다. 비용 구조 역시 토큰 비용만이 아니라 세션과 도구 실행 정책의 영향을 받는다. 특히 특정 툴셋과 MCP 흐름에 맞춰 제품을 설계하기 시작하면, 추후 다른 모델이나 다른 인프라로 갈아타는 비용이 커질 수밖에 없다.

직접 써보지 않아도 여기서 냄새가 난다. Anthropic은 최근 서드파티 에이전트 도구에 대한 과금 경계를 더 세게 긋고 있다. 그런 시점에 Managed Agents를 내놨다는 건 우연이 아니다. 오픈 에이전트 생태계에서 생긴 수요를 자사 관리형 상품으로 다시 끌어당기려는 움직임으로 읽힌다.

지금 붙여볼 팀과 아직 이른 팀

바로 시험해볼 만한 팀

다음 조건에 해당하면 Claude Managed Agents는 꽤 현실적인 선택이다.

GitHub, Slack, Linear 같은 외부 SaaS와 에이전트를 연결해야 하는 팀
장시간 실행과 사람 승인 흐름이 필요한 백오피스 자동화 팀
데모는 이미 성공했지만 운영 파이프라인 때문에 출시가 밀리는 팀

이 팀들은 에이전트 정확도보다 운영 자동화가 더 절박하다. Managed Agents는 정확히 그 틈을 찌른다.

아직 신중해야 할 팀

반대로 다음 상황이라면 성급한 올인은 위험하다.

모델 라우팅을 자주 바꾸는 팀
자체 샌드박스와 감사 체계를 이미 갖춘 팀
데이터 경계와 비용 예측 가능성을 직접 통제해야 하는 팀

이 경우에는 관리형 전환이 생산성보다 종속성을 더 크게 만들 수 있다. 특히 에이전트 실패 원인을 세밀하게 추적해야 하는 보안 민감 조직이라면 초기에 꼭 별도 비교 운영을 해봐야 한다.

Anthropic의 진짜 승부수는 모델이 아니라 운영판이다. 앞으로 에이전트 시장의 질문은 “누가 더 똑똑한가”보다 “누가 더 싸고, 안정적으로, 책임 있게 돌려주나”로 옮겨갈 가능성이 크다. 지금 한 번 직접 붙여본 뒤, 팀의 병목이 모델인지 운영인지부터 숫자로 확인해보는 편이 낫다.

Karpathy가 RAG를 버렸다 — 40만 단어 AI 위키의 충격

Tue, 07 Apr 2026 02:00:00 +0000

Karpathy는 단 한 줄도 직접 쓰지 않았다.

400,000단어. 100개 기사. 촘촘한 백링크 네트워크. 그것도 단일 연구 주제 하나에 대해서만. 일반 박사 논문 한 편이 80,000~100,000단어쯤 된다는 걸 감안하면, Karpathy는 AI와 함께 박사 논문 다섯 편 분량의 지식 구조물을 만들어낸 셈이다.

그런데 RAG 파이프라인은 없다. 벡터 데이터베이스도 없다. 임베딩 서버도, Pinecone 계정도, Weaviate 인스턴스도 없다. 있는 건 raw/ 디렉토리 하나와 마크다운 파일들, 그리고 LLM이 전부다.

2026년 4월 3일, Andrej Karpathy가 X(구 트위터)에 짧은 포스트를 하나 올렸다. 제목은 “LLM Knowledge Bases”. 이 한 편의 글이 며칠 만에 GeekNews 111포인트, VentureBeat 특집 기사, Reddit 프로그래밍 커뮤니티의 열띤 토론을 불러일으켰다.

LLM 위키의 구조 — raw/에 넣으면 AI가 씁니다

Karpathy의 시스템은 놀랍도록 단순하다. 파이썬 스크립트도, 복잡한 설정 파일도 없다. 디렉토리 두 개와 LLM 호출 루프가 전부다.

raw/ 디렉토리: 재료를 넣는 곳

모든 것은 raw/ 폴더에서 시작한다. 논문 PDF, 기사 링크, GitHub 리포지토리, 데이터셋 설명, 이미지, 메모 파일 — 연구 주제와 관련된 소스 자료를 전부 여기에 쌓는다. 기사를 스크랩하든, PDF를 떨어뜨려 넣든, 링크를 텍스트로 저장하든 형식은 상관없다.

이 폴더 자체는 그냥 입력 창고다. 정리할 필요도 없고, 분류할 필요도 없다. LLM이 알아서 읽는다.

컴파일 단계: LLM이 위키를 만드는 과정

LLM은 raw/ 폴더를 읽고 구조화된 마크다운 위키 파일들을 wiki/ 디렉토리에 생성한다. 단순한 요약이 아니다. LLM은 다음을 수행한다.

핵심 개념 추출: 주요 용어와 아이디어를 식별하고 독립적인 기사로 작성
백과사전형 기사 작성: 각 개념에 대해 심층 설명 작성, 배경부터 적용 사례까지
백링크 생성: 관련 개념 간의 연결 고리를 [[개념명]] 형식으로 자동 삽입
증분 업데이트: 새 소스가 추가되면 기존 위키를 업데이트하고 새 기사를 추가

Karpathy가 강조한 핵심 은유는 “컴파일러(compiler)”다. 소스 코드를 실행 가능한 바이너리로 컴파일하듯, LLM은 원시 데이터를 구조화된 지식으로 컴파일한다. RAG처럼 문서를 검색하는 것이 아니라, LLM이 지식 자체를 직접 생산한다.

그가 공유한 핵심 문장이 있다: “내 최근 토큰 처리량의 상당 부분이 코드를 조작하는 것에서 지식을 조작하는 것으로 옮겨가고 있다.”

RAG와 어떻게 다른가

RAG(Retrieval-Augmented Generation)는 지금까지 LLM 기반 지식 시스템의 지배적인 패러다임이었다. 질문이 들어오면 관련 문서를 벡터 검색으로 찾고, 찾은 문서를 LLM에게 컨텍스트로 제공해 응답을 생성한다. 이 구조를 위해 임베딩 모델, 벡터 데이터베이스, 청킹 전략, 검색 파이프라인을 전부 설계해야 한다.

RAG의 구조적 한계

RAG는 강력하지만 몇 가지 근본적인 문제가 있다.

청킹 딜레마: 문서를 어떻게 쪼갤까? 너무 크면 컨텍스트 낭비, 너무 작으면 맥락 손실. 최적 청크 크기는 도메인마다 다르고, 한번 잘못 설정하면 전체 성능이 흔들린다.

검색 정확도: 임베딩 기반 유사도 검색은 의미적으로 유사한 문서를 가져오지만, 논리적으로 관련된 문서를 놓치는 경우가 많다. “GPU 메모리 병목”이라는 질문이 “VRAM 부족”에 대한 문서를 제대로 가져올 보장이 없다.

지식 단편화: RAG는 원본 문서를 분절된 청크로 저장한다. 전체 개념 구조를 이해하는 게 아니라, 조각을 검색해 붙이는 방식이다. LLM이 문서들 간의 관계를 이해할 기회가 없다.

운영 복잡도: 벡터 DB 서버를 띄워야 하고, 임베딩 모델을 유지해야 하고, 인덱스를 관리해야 한다. 개인 프로젝트 수준에서는 배보다 배꼽이 더 커진다.

LLM 위키의 접근 방식

Karpathy의 방식은 이 문제를 근본부터 다르게 접근한다. LLM이 “지식을 검색”하는 것이 아니라 “지식을 구성”하게 한다. 위키 파일은 이미 인간이 읽을 수 있는 형태로 정리된 지식이다. LLM이 나중에 이 파일들을 컨텍스트로 읽을 때, 청크 검색이 아니라 구조화된 글을 읽는 것이다.

물론 이 방식도 한계가 있다. 위키 파일이 커지면 컨텍스트 윈도우를 초과한다. Karpathy는 이를 계층적 구조, 즉 요약 파일과 상세 기사를 분리하는 방식으로 해결한다.

Claude Code로 직접 구현해보기

Karpathy의 아이디어 파일을 보면 구현 방법이 구체적으로 나와 있다. Claude Code를 사용해 비슷한 시스템을 즉시 따라해볼 수 있다.

# 프로젝트 구조 설정
mkdir my-llm-wiki
cd my-llm-wiki
mkdir raw wiki

# raw/에 소스 자료 추가 (PDF, 텍스트, 링크 등 형식 무관)
# 예: 읽은 기사나 논문을 텍스트 파일로 저장
echo "AI 코딩 에이전트 관련 논문 요약" > raw/ai-coding-agents.txt

Claude Code에서 다음 프롬프트로 위키를 초기화한다.

raw/ 폴더의 파일들을 읽고 wiki/ 디렉토리에 마크다운 위키를 생성해줘.
각 주요 개념에 대해 독립적인 .md 파일을 만들어.
관련 개념 간에는 [[개념명]] 형식으로 백링크를 추가하고,
백과사전 스타일로 작성해. 요약 인덱스 파일(index.md)도 함께 만들어.

새 소스를 추가할 때마다 증분 업데이트 프롬프트를 실행한다.

raw/에 새 파일이 추가됐어. wiki/index.md와 기존 기사들을 참고해서
새 정보를 통합해줘. 필요하면 기존 기사를 업데이트하거나
새 기사를 추가해. 새로 추가된 개념은 기존 관련 기사에 백링크로 연결해.

이전에 다뤘던 OpenAI의 Python 생태계 인수처럼, AI 도구가 개발자 워크플로우를 재편하는 속도가 갈수록 빨라지고 있다. 이 시스템은 단 30분 안에 구축할 수 있고, 운영 비용은 LLM API 호출비가 전부다.

개발자 커뮤니티의 반응

GeekNews에서 이 글은 111포인트를 기록하며 당일 최고 인기 글이 됐다. 반응은 크게 두 갈래로 나뉜다.

“드디어 RAG를 단순하게 만들 수 있다”는 쪽은 이 접근법의 유지보수 용이성을 높이 산다. 벡터 DB를 운영할 필요 없이, 마크다운 파일만 Git으로 관리하면 된다. 팀 협업도 쉽고, 에러 추적도 쉽다. “내가 원하는 게 바로 이거였다”는 반응이 많았다.

“이건 결국 컨텍스트 윈도우 문제가 있다”는 쪽은 위키가 커질수록 LLM이 전체를 읽기 어려워진다고 지적한다. Karpathy 본인도 이 점을 인정했다. 그의 해법은 계층적 요약 구조다. 인덱스 파일은 가볍게 유지하고, 세부 기사는 필요할 때만 읽는다.

또 다른 관점도 있다. RAG가 “검색”을 담당했다면, 이 방식은 “이해”를 LLM에게 선제적으로 맡기는 것이다. 어떤 질문이 들어올지 모르지만, LLM이 미리 개념 간 관계를 파악해두면 응답 품질이 달라진다.

이 논쟁 자체가 LLM의 컨텍스트 윈도우 확장이 얼마나 중요한 문제인지를 보여준다. 256K, 1M 컨텍스트가 보편화되면 이 방식의 한계는 자연스럽게 해소된다.

위키는 자라고, 질문은 날카로워진다

Karpathy가 이 시스템에서 발견한 가장 흥미로운 효과는 이것이다. 위키가 커질수록, 자신의 질문 품질이 높아진다.

이유는 간단하다. 위키를 구축하는 과정에서 어떤 개념이 잘 정리됐고, 어떤 부분이 아직 흐릿한지가 드러나기 때문이다. “이 개념에 기사가 없네”라는 관찰이 “다음에 뭘 공부해야 하는지”로 자연스럽게 이어진다. 지식베이스가 학습 가이드 역할을 동시에 한다.

개인 지식 관리 도구(PKM)를 운영해본 사람이라면 이 감각을 알 것이다. Obsidian이나 Notion으로 노트를 쌓을 때, 그 구조가 자신의 사고 구조를 반영한다는 것. Karpathy의 LLM 위키는 그 구조를 AI가 대신 만들어준다. 사람은 재료만 제공하면 된다.

복잡한 RAG 파이프라인 없이도 충분히 강력한 지식 시스템을 만들 수 있다. raw/ 폴더에 오늘 읽은 기사 하나를 떨어뜨려 넣는 것부터 시작해보자. 위키는 스스로 자란다.

AI 시대 개발자를 향한 올트먼의 마지막 감사

Tue, 07 Apr 2026 01:00:00 +0000

2026년 3월 17일 화요일, 수백만 명이 구독하는 X 계정에서 트윗 하나가 올라왔다. OpenAI CEO 샘 올트먼이었다.

“I have so much gratitude to people who wrote extremely complex software character-by-character. It already feels difficult to remember how much effort it really took. Thank you for getting us to this point.”

번역하면 이렇다. “문자 하나하나씩 극도로 복잡한 소프트웨어를 작성해준 분들께 깊은 감사를 전합니다. 그 노력이 얼마나 대단했는지 이미 기억이 흐릿해지고 있습니다. 이 지점까지 이끌어주셔서 감사합니다.”

개발자 커뮤니티의 반응은 즉각적이었다. 그런데 감사 인사가 돌아온 게 아니었다.

올트먼이 올린 그 트윗

트윗 자체는 짧았다. 하지만 커뮤니티가 받아들인 맥락은 훨씬 무거웠다.

트윗이 나온 날의 분위기

3월 17일은 평범한 화요일이 아니었다. 2025년 한 해에만 기술 업계에서 246,000명이 해고됐고, 2026년 들어서도 그 속도는 줄어들지 않았다. 곳곳에서 “AI 때문에 주니어 개발자 채용을 줄인다”는 공고가 나왔고, 스택오버플로우 트래픽은 78% 급감했으며, 코딩 부트캠프 입학생 수는 전년 대비 절반 이하로 떨어졌다.

그 시점에 OpenAI CEO가 개발자에게 “감사합니다”라고 트윗을 올렸다.

트윗에서 눈에 띄는 표현

“It already feels difficult to remember how much effort it really took.”

과거형이다. 개발자의 노력이 이미 과거의 일처럼 느껴진다고 쓰고 있다. 현재 개발자를 향한 말이 아닌, 어떤 시대에 대한 회고처럼 들린다. 그래서 커뮤니티 일부는 이 트윗을 “Sam’s eulogy for software engineers”라고 불렀다. 직역하면 소프트웨어 엔지니어에 대한 조사다.

“Thank you for getting us to this point.”

여기서 “this point”가 무엇을 의미하는지는 트윗에 명시되지 않았다. 하지만 맥락을 보면 자명하다. AI가 코드를 짜주는 지금 이 시점이다.

94%가 부정적이었던 이유

GetFocusLab 분석에 따르면 해당 트윗에 대한 반응의 94%가 부정적이었다. 밈이 쏟아졌고, 풍자 계정들이 패러디를 만들었다.

댓글에서 가장 많이 공유된 문장들

가장 많은 공감을 받은 리플은 단순했다.

“You’re welcome. Nice to know that our reward is our jobs being taken away.”

그리고 이것도 있었다.

“Nothing says ‘you’re being replaced’ quite like a heartfelt thank you from the guy doing the replacing.”

한국어로 의역하면 이렇다. “당신을 대체하는 사람이 직접 진심을 담아 감사하다고 말하는 것만큼 ‘당신은 교체됩니다’를 잘 전달하는 방법은 없다.”

일부는 더 직접적이었다. 올트먼을 “psychopath”라고 부르는 댓글도 달렸다. TechCrunch는 해당 트윗이 이틀 만에 전 세계 기술 뉴스에 오르내리며 “the memes kept coming”이라고 보도했다.

왜 이게 문제였나

트윗 자체에 틀린 말은 없었다. 개발자들은 정말 복잡한 소프트웨어를 만들었고, 그 노력은 실제로 AI 시대의 기반이 됐다. 문제는 타이밍이었다.

TechCrunch는 이를 “a timing problem”이라고 정확하게 짚었다. 개발자들이 AI 도구 때문에 해고되는 시점에, 그 AI를 만든 회사의 CEO가 감사를 표한 것은 위로가 아니라 확인처럼 들렸다.

개발자들이 듣고 싶었던 것은 달랐다. 구체적인 재교육 프로그램 약속, 주니어 개발자 채용 지속 여부, 또는 그냥 침묵이었다. “감사합니다”는 세 가지 중 어느 것도 아니었다.

OpenAI는 그 코드를 어떻게 사용했나

여기서 또 다른 논란이 겹친다.

OpenAI의 AI 모델들은 수십억 줄의 코드를 학습 데이터로 사용했다. 그 코드의 상당 부분은 GitHub에 공개된 개발자들의 작업물이었다. 저작권 논쟁이 진행 중인 상황에서 올트먼이 “감사합니다”라고 말하자, 일부 개발자들은 이렇게 받아들였다.

“내 코드로 AI를 학습시켜 내 일자리를 빼앗은 사람이 감사하다고 한다.”

GitHub 기여자라면 지금 할 수 있는 것

완전한 되돌림은 불가능하다. 과거에 공개했던 코드는 학습 데이터에서 제외할 방법이 없다. 다만 향후 설정은 바꿀 수 있다.

# GitHub CLI로 현재 프라이버시 설정 상태 확인
gh api user 2>/dev/null | jq '.login, .type' 2>/dev/null || echo "gh CLI 미설치 또는 미인증"

# 조직 소유 저장소 AI 학습 opt-out 여부 확인
# Settings → Privacy and Security → Training data preferences
# (웹 UI에서만 가능, CLI 지원 없음)
echo "https://github.com/settings/privacy 에서 직접 설정 필요"

이 명령어로 바로 opt-out이 되지는 않는다. 하지만 GitHub 계정에 로그인된 상태에서 위 URL로 이동하면 개인 데이터 관련 설정을 확인할 수 있다. 특히 2026년 4월 24일 이전에 조치해야 하는 저장소 설정이 남아 있다면 지금이 마지막 타이밍이다.

AI 시대에 개발자가 준비할 것들

올트먼의 트윗이 어떤 의도였든 간에, 실제로 개발자의 역할이 바뀌고 있다는 사실은 부정하기 어렵다. 모건 스탠리의 AI 시대 개발자 커리어 분석도 같은 결론을 냈다. 코드를 가장 빠르게 짜는 사람이 아니라, 무엇을 만들어야 하는지 가장 잘 판단하는 사람이 살아남는다.

지금 점검해야 할 체크리스트

아래는 “AI에게 대체되지 않는 방법”이 아니다. AI 도구를 가장 잘 쓰는 개발자가 되기 위한 실용적인 접근이다.

항목	내용
AI 도구 숙련도	Claude Code, Cursor, GitHub Copilot 중 최소 1개를 실무 수준으로 활용
시스템 설계 역량	코드 한 줄보다 아키텍처 결정을 내리는 능력 강화
비즈니스 이해	개발 결정이 매출과 비용에 미치는 영향을 설명할 수 있어야 함
AI 아웃풋 검증	AI가 생성한 코드의 버그와 보안 취약점을 빠르게 찾는 능력
커뮤니케이션	비개발자에게 기술 결정을 설명하는 능력

가장 중요한 건 네 번째 항목이다. AI가 코드를 생성하더라도, 그것이 프로덕션에 나가도 되는지 판단하는 사람은 여전히 개발자다. 그 판단 능력이 없으면 AI 도구의 생산성 이점은 오히려 위험이 된다. 2026년 3월 발생한 다수의 AI 생성 코드 보안 사고들이 그 증거다.

올트먼의 트윗이 남긴 질문

트윗은 삭제되지 않았다. 올트먼은 추가 해명도 하지 않았다. 94%가 부정적으로 반응했지만, 그 트윗은 아직 X에 남아 있다.

이 트윗을 어떻게 읽느냐는 각자의 해석에 달려 있다. 진심 어린 감사인지, 은퇴 선언인지, 아니면 실책인지. 한 가지만 확실하다. 적어도 올트먼에게는 character-by-character로 코드를 짜던 시대가 이미 과거가 됐다.

그 판단이 맞는지 틀리는지를 확인하는 건 앞으로 몇 년이 말해줄 것이다. 그 몇 년 사이에 어디에 서 있느냐는 지금의 선택이 결정한다.

Gemma 4 출시 — 구글 오픈소스 모델이 중국 AI에 밀린 이유

Mon, 06 Apr 2026 02:00:00 +0000

글로벌 오픈소스 AI 리더보드에서 구글은 3위다.

2026년 4월 2일, 구글은 Gemma 4를 공식 발표했다. “바이트 단위로 가장 성능이 우수한 오픈 모델”이라고 선언했고, Apache 2.0 라이선스로 완전 무료 공개했다. E2B부터 31B까지 네 가지 모델, 최대 256K 컨텍스트, 멀티모달(이미지·비디오·오디오) 지원, 에이전트 워크플로우 최적화. 스펙만 보면 나무랄 데 없다.

그런데 Arena AI 텍스트 리더보드를 열면 현실이 나온다. Gemma 4 31B의 ELO는 약 1452. 오픈소스 모델 중 3위다. 1위는 Alibaba의 Qwen 3.5, 2위는 Zhipu AI의 GLM-5, 3위에 Moonshot AI의 Kimi K2.5도 근접해 있다. 구글이 자신만의 게임에서 중국 AI 스타트업들한테 밀렸다.

이게 단순한 벤치마크 수치 차이가 아닌 이유를 짚어본다.

Gemma 4, 스펙부터 보자

Gemma 4는 네 개의 변형 모델로 구성된다.

모델	파라미터	컨텍스트	특징
E2B	2.3B 유효 / 5.1B 총합	128K	오디오 지원, 온디바이스 최적화
E4B	4.5B 유효 / 8B 총합	128K	오디오 지원, 최소 비용
26B A4B	4B 활성화 / 26B MoE	256K	Mixture of Experts, 속도 우선
31B Dense	31B	256K	최고 성능, 최고 품질

여기서 주목할 숫자는 26B A4B 모델이다. 총 파라미터는 26B지만 추론 시 활성화되는 건 4B뿐이다. Mixture of Experts(MoE) 아키텍처 덕분에 메모리와 연산량을 줄이면서도 높은 품질을 유지한다.

아키텍처 혁신도 몇 가지 있다. Per-Layer Embeddings(PLE)는 기존 트랜스포머의 단일 임베딩 방식 대신 각 레이어마다 전용 벡터를 생성한다. 멀티모달 입력에서는 중립 신호(패드 토큰)를 사용해 이미지·오디오·텍스트를 일관되게 처리한다. Shared KV Cache는 마지막 N개 레이어가 이전 레이어의 Key-Value 상태를 재사용하게 해서 긴 컨텍스트 생성 효율을 높인다.

벤치마크 수치도 인상적이다. 31B 모델 기준으로 AIME 2026에서 89.2%, GPQA Diamond에서 84.3%, LiveCodeBench v6에서 80.0%를 기록했다. BigBench Extra Hard에서는 74.4%인데, 이전 세대 Gemma 3이 19.3%였으니 거의 4배 향상이다.

로컬에서 바로 돌릴 수 있다

오픈소스의 진짜 가치는 내 환경에서 실행 가능하다는 점이다. 가장 빠른 방법은 llama.cpp다.

# macOS에서 설치
brew install llama.cpp

# E2B IT 모델 서버 실행
llama-server -hf ggml-org/gemma-4-E2B-it-GGUF

Apple Silicon을 쓴다면 MLX가 더 빠르다.

pip install -U mlx-vlm

mlx_vlm.generate \
  --model google/gemma-4-E4B-it \
  --image ./screenshot.png \
  --prompt "이 이미지에서 버그를 찾아줘"

E4B 모델은 8GB VRAM이면 충분히 돌아간다. 개인 노트북에서 무료로 쓸 수 있는 멀티모달 모델 중에서 이 정도 성능을 내는 건 처음이다.

벤치마크 현실: 3위의 의미

Arena AI 리더보드는 사용자들이 직접 두 모델을 비교하고 더 나은 쪽을 선택하는 방식으로 점수를 산출한다. 단순히 정해진 테스트셋 점수가 아니라 실제 사용 맥락에서의 선호도를 반영한다는 점에서 다른 벤치마크보다 신뢰도가 높다고 평가받는다.

이 리더보드에서 Gemma 4 31B는 ELO 약 1452로 오픈소스 3위를 기록했다. 1위 Qwen 3.5와의 격차는 수십 포인트 수준으로 크지 않지만, “구글의 플래그십 오픈소스 모델”이라는 기대치와 비교하면 씁쓸한 결과다.

중국 모델들이 앞선 구체적인 영역을 보면 패턴이 보인다. 멀티턴 대화 품질, 코딩 태스크에서의 자기 수정 능력, 그리고 언어 이해 정확도 부분에서 Qwen 계열이 일관되게 높은 평가를 받고 있다.

이게 왜 중요한가. Gemma 4 이전까지 구글은 “오픈소스도 우리가 제일 잘 한다”는 포지션을 유지할 수 있었다. Gemma 3까지는 오픈소스 최상위권을 다퉜다. 그런데 이번에 중국 모델들이 명확한 우위를 가져가면서 그 포지션이 흔들렸다.

왜 중국 모델이 앞섰나

이걸 단순히 “중국이 열심히 했다”로 설명하는 건 부족하다. 구조적 차이가 있다.

첫째, MoE 아키텍처 활용의 차이다.

Gemma 4 26B A4B는 MoE를 쓴다. 그런데 31B Dense가 메인 플래그십이다. Qwen 3.5와 같은 중국 모델들은 이미 MoE를 메인 아키텍처로 올인하는 추세다. 같은 추론 비용으로 더 많은 파라미터를 쌓는 전략이다. 구글은 여전히 Dense와 MoE를 병행하며 보수적으로 간다.

둘째, 학습 데이터 전략의 차이다.

공개된 정보만으로 확인하기 어렵지만, Alibaba와 같은 중국 빅테크는 자사 플랫폼 사용자 데이터(타오바오, 알리바바 클라우드, 딩딩)와 방대한 중국어 웹 데이터를 활용한다. 글로벌 커버리지 면에서는 구글이 앞서지만, 특정 도메인 밀도에서는 중국 모델이 유리할 수 있다.

셋째, 오픈소스 생태계 성숙도다.

Qwen 계열은 이미 Hugging Face 커뮤니티에서 파인튜닝 레시피, 양자화 모델, 서빙 최적화 노하우가 충분히 쌓였다. 커뮤니티 피드백이 다음 모델에 반영되는 속도가 빠르다. Gemma도 비슷한 생태계를 갖추고 있지만, 중국 모델들이 더 공격적으로 커뮤니티 참여를 유도했다.

직전에 다뤘던 GitHub AI 학습 정책 논란처럼, AI 개발에서 데이터 접근권과 생태계 통제가 얼마나 중요한지를 이번에도 확인할 수 있다.

개발자가 Gemma 4를 써야 하는 이유

그렇다고 Gemma 4가 나쁜 선택이라는 말은 아니다. 개발자 관점에서 여전히 강력한 이유가 있다.

Apache 2.0 라이선스는 상업적 제약이 없다. Qwen과 GLM도 오픈소스를 표방하지만 라이선스 세부 조항을 확인해야 한다. Gemma 4는 상업적 사용, 파인튜닝, 재배포 모두 가능하다. 프로덕션에 올리는 데 법적 리스크가 낮다.

온디바이스 추론이 실질적으로 가능하다. E2B와 E4B 모델은 소비자 등급 하드웨어에서 돌아간다. 데이터를 외부로 보내지 않고 로컬에서 처리해야 하는 민감한 케이스에 적합하다.

함수 호출과 에이전트 지원이 기본이다. transformers 파이프라인 한 줄로 멀티모달 에이전트를 구성할 수 있다.

from transformers import pipeline

pipe = pipeline("any-to-any", model="google/gemma-4-e4b-it")

messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "url": "https://example.com/chart.png"},
            {"type": "text", "text": "이 차트에서 이상한 점을 찾아 JSON으로 반환해줘"}
        ],
    }
]

result = pipe(messages, max_new_tokens=500)
print(result)

이 코드는 실제로 실행된다. E4B 기준으로 이미지 분석 + JSON 출력까지 로컬 RTX 3080 환경에서 10초 내외다.

오픈소스 왕좌는 누가 가져갔나

Gemma 4 출시 이후 개발자 커뮤니티에서 나오는 질문은 두 가지다. “왜 구글은 1위를 못 가져왔나”와 “그래서 어떤 모델을 써야 하나”.

첫 번째 질문의 답은 이미 위에서 다뤘다. 두 번째 질문의 답은 상황에 따라 다르다.

법적 안전성이 우선이면: Gemma 4 (Apache 2.0)
최고 성능이 우선이면: Qwen 3.5 (상업 라이선스 확인 필요)
온디바이스 멀티모달이 필요하면: Gemma 4 E4B
에이전트 파이프라인을 빠르게 구축하려면: Gemma 4 (Google 생태계 통합)

더 흥미로운 건 이 경쟁이 앞으로 어떻게 전개되느냐다. 구글은 이미 Gemma 5 개발에 착수했을 것이고, Alibaba와 Zhipu AI도 멈추지 않는다. 오픈소스 AI의 세력도는 반년 주기로 바뀌고 있다.

“구글이 최고의 오픈소스 AI를 만든다”는 전제는 이번에 흔들렸다. 다음 Gemma 발표 때 그 전제가 복원될지, 아니면 중국 모델의 우위가 굳어질지 — 개발자 입장에서는 좋은 선택지가 늘어나는 셈이다.

Opus 위의 비밀 모델 Claude Mythos가 유출됐다

Sat, 28 Mar 2026 06:00:00 +0000

“당신네 블로그 CMS에 미공개 문서 3000건이 공개 상태입니다.”

Fortune 기자가 Anthropic에 보낸 메일의 요지다. 3월 26일, Anthropic의 콘텐츠 관리 시스템에서 한 번도 공개된 적 없는 내부 문서 약 3000건이 누구나 검색하고 열람할 수 있는 상태로 발견됐다. 블로그 초안, 내부 이미지, PDF, CEO 비공개 행사 자료까지 전부. 그리고 그 문서 더미 한가운데에 ‘Claude Mythos’라는 이름의 모델 발표 초안 두 버전이 있었다.

Anthropic은 Fortune의 연락을 받고 즉시 접근을 차단했다. 그리고 이례적으로 모델의 존재를 공식 인정했다. “지금까지 만든 것 중 가장 강력한 모델이며, 단계적 도약(step change)이다.”

3000건이 쏟아진 경위

CMS 디폴트 설정의 함정

원인은 허무할 정도로 단순했다. Anthropic의 콘텐츠 관리 시스템에서 파일을 업로드할 때 기본값이 ‘공개’로 설정되어 있었다. 누군가 이 디폴트를 변경하지 않았거나, 바꿔야 한다는 사실 자체를 인지하지 못했다. Fortune은 이를 “인적 오류(human error)”로 분류했고, Anthropic도 이를 부인하지 않았다.

유출된 자산 약 3000건에는 블로그 초안만 있었던 게 아니다. 내부 마케팅 자료, CEO 비공개 행사 관련 문서까지 포함됐다. AI 안전성을 핵심 가치로 내세우는 기업이라는 점을 생각하면 아이러니가 상당하다.

며칠 전 GitHub의 AI 학습 데이터 수집 기본값 변경에서도 다뤘지만, 기본값의 방향이 곧 현실이다. 대부분의 사용자는 설정을 바꾸지 않는다. Anthropic 내부 엔지니어도 예외가 아니었다.

직접 운영하는 인프라가 있다면 지금 당장 확인해볼 수 있는 명령이 하나 있다:

# S3 버킷의 퍼블릭 접근 차단 상태 확인 (AWS CLI)
aws s3api get-public-access-block --bucket YOUR_BUCKET_NAME

네 항목 — BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets — 이 전부 true가 아니라면, Anthropic과 같은 상황이 당신의 인프라에서도 일어날 수 있다. GCP를 쓴다면 gsutil iam get gs://YOUR_BUCKET으로 allUsers 바인딩이 있는지 확인하면 된다.

유출이 불러온 연쇄 반응

Fortune의 단독 보도 이후 24시간 만에 CoinDesk, Seeking Alpha, Futurism, The Decoder가 후속 기사를 쏟아냈다. 특히 CoinDesk는 “사이버보안 악몽이 될 수 있는 AI 모델”이라는 제목을 달았고, 소프트웨어 관련 주식에 미칠 영향을 분석했다. GeekNews에서도 19시간 만에 15개의 댓글이 달렸는데, 한국 개발자 커뮤니티에서 이 정도 반응 속도는 드물다.

Opus 위에 새로운 계층이 있었다

유출된 초안에서 가장 주목할 부분은 모델의 포지셔닝이다. 두 버전의 초안이 있었는데, 하나는 “Mythos”, 다른 하나는 “Capybara”라는 이름을 사용했다. 내용은 동일했다. 이름의 유래는 “지식과 아이디어를 잇는 깊은 연결 조직(the deep connective tissue that links together knowledge and ideas)”에서 따왔다고 한다.

Opus 4.6과의 격차

핵심 문장은 이것이다. “Capybara는 Opus 모델보다 더 크고 더 지능적인 새로운 티어의 모델이다.”

비교 항목	Opus 4.6 대비 Mythos 성능
소프트웨어 코딩	“극적으로 높은 점수(dramatically higher scores)”
학술 추론	동일하게 극적 향상
사이버보안	“현존하는 어떤 AI 모델보다 훨씬 앞선 수준”

구체적인 벤치마크 수치는 초안에도 포함되지 않았다. 내 생각엔 이건 의도적이다. 숫자를 넣으면 경쟁사가 즉시 비교 분석에 들어간다. 초안이니 최종 수치가 확정되지 않았을 수도 있고, 아니면 숫자 자체가 너무 파격적이라 내부 검증이 더 필요했을 수도 있다. 어느 쪽이든, Anthropic 대변인이 Fortune에 직접 확인한 “step change”라는 단어가 모든 걸 말해준다.

가격과 출시 타이밍

Anthropic은 Mythos에 대해 “우리가 제공하기에 매우 비싸고, 고객이 사용하기에도 매우 비쌀 것”이라고 밝혔다. 효율성을 개선한 뒤에야 일반 출시할 계획이다. 현재는 소수의 얼리 액세스 고객만 API를 통해 접근하고 있다.

출시 전략도 이례적이다. “이전 모델들보다 의도적으로 느리게 출시할 것”이며, 첫 번째 대상 그룹은 사이버 방어 조직이다. 공격자보다 방어자가 먼저 무기를 손에 쥐게 하겠다는 것. 이 순서가 왜 중요한지는 바로 아래에서 다룬다.

AI가 사이버무기가 되는 시나리오

유출된 초안에서 무게감이 가장 큰 문장은 이것이었다.

“방어자의 노력을 훨씬 앞지르는 속도로 취약점을 악용할 수 있는 모델 물결의 전조다.”

Anthropic이 자사 모델에 대해 쓴 문장이다. 만든 회사가 스스로 이렇게 경고한다는 건, 내부 레드팀 테스트에서 실제로 그런 결과를 확인했다는 뜻이다.

공격 자동화가 현실이 되는 순간

현재 AI 모델로도 코드 리뷰와 취약점 탐지는 가능하다. 하지만 Mythos 급 모델이 공격자의 손에 들어가면 게임의 규칙 자체가 바뀐다:

자동 취약점 탐색 — 대규모 코드베이스에서 제로데이급 취약점을 분 단위로 스캔
익스플로잇 자동 생성 — 발견한 취약점에 대한 공격 코드를 즉시 작성
대규모 병렬 공격 — 수천 개 타겟에 각각 맞춤형 공격을 동시 실행

이 시나리오가 허황된 이야기가 아닌 이유가 있다. 이전 세대 모델에서 이미 멀티 에이전트 시스템이 병렬로 코드를 분석하고 수정하는 능력이 확인됐다. Mythos가 이 능력을 사이버보안 영역으로 극대화했다면, Anthropic의 경고는 과장이 아니다.

Anthropic이 직면한 딜레마

“전례 없는 사이버보안 위험”을 만들었다고 스스로 인정한 회사가, 동시에 그 모델을 상업화해야 한다. safety-first를 내세우는 기업 이미지와 “현존 최강의 사이버보안 AI”를 만들었다는 현실 사이의 줄타기다.

방어 조직 우선 접근이라는 출시 전략은 이 딜레마에 대한 답이다. 의도는 분명히 좋다. 그런데 한 가지 질문이 남는다 — 얼리 액세스 API 키가 유출되거나, 모델 가중치가 탈취되면? 바로 며칠 전 CMS 설정 하나를 놓친 회사가, 이보다 훨씬 높은 수준의 보안을 유지할 수 있을까?

CMS 한 줄이 바꿔버린 타임라인

Anthropic이 Mythos를 공개할 시점은 아마 수개월 뒤였을 것이다. 벤치마크를 확정하고, 안전 평가를 마치고, 마케팅 메시지를 다듬은 뒤에. CMS 설정 파일의 public: true 한 줄이 그 계획 전체를 날려버렸다.

AI 보안의 미래를 논하는 회사가 자사 콘텐츠 관리 시스템의 접근 제어 기본값 하나를 놓쳤다. 가장 정교한 위협 모델을 설계하는 팀도, 가장 기본적인 인프라 점검에서 실패할 수 있다. 보안은 언제나 가장 약한 고리에서 무너진다. 이번에는 그 고리가 차세대 AI 모델이 아니라, 블로그 CMS였을 뿐이다.

GitHub가 당신 코드로 AI를 훈련시킨다

Sat, 28 Mar 2026 02:00:00 +0000

4월 24일부터 GitHub가 Copilot Free, Pro, Pro+ 사용자의 상호작용 데이터를 AI 모델 학습에 기본 사용한다. opt-in이 아니라 opt-out이다. 지금 설정을 끄지 않으면, 한 달 뒤 당신이 Copilot에 입력한 코드 조각, 파일 구조, 탭 이동 패턴까지 Microsoft의 AI 파이프라인으로 흘러간다.

3월 25일 GitHub 공식 블로그에 올라온 약관 변경 공지를 읽은 개발자들의 반응은 즉각적이었다. The Register는 “GitHub: We’re going to train on your data after all”이라는 제목을 달았고, Hacker News와 Reddit에서는 수백 개의 댓글이 쏟아졌다. 가장 많은 질문은 하나였다 — “그래서 내 프라이빗 레포 코드도?”

직접 약관을 읽어봤다. 그리고 생각보다 범위가 넓었다.

3월 25일에 무엇이 바뀌었는가

핵심: opt-in에서 opt-out으로

기존에는 Copilot 사용 데이터를 AI 학습에 쓸지 여부를 사용자가 직접 켜야 했다. 4월 24일부터는 반대다. 별도로 끄지 않으면 자동 활성화된다.

GitHub의 Chief Product Officer는 이 변경의 이유를 이렇게 설명했다. “Microsoft 직원들의 상호작용 데이터를 학습에 포함시킨 결과, AI 제안 수락률이 의미 있게 향상됐다.” 요약하면 — 데이터가 많을수록 모델이 좋아지니, 기본값을 켜겠다는 것이다.

이 논리 자체는 기술적으로 틀리지 않다. 문제는 기본값의 방향이다. 보안 분야에서는 “기본값이 곧 현실”이라는 격언이 있다. 대부분의 사용자는 설정을 바꾸지 않는다. opt-out 기본값은 사실상 대규모 데이터 수집과 같다.

영향 받는 플랜, 안전한 플랜

플랜	AI 학습 대상	비고
Copilot Free	O	4월 24일 기본 활성화
Copilot Pro	O	4월 24일 기본 활성화
Copilot Pro+	O	4월 24일 기본 활성화
Copilot Business	X	기업 데이터 보호
Copilot Enterprise	X	기업 데이터 보호
학생/교사 무료 플랜	X	별도 면제

기업 사용자가 면제된 건 당연하다. 엔터프라이즈 고객의 코드를 학습에 쓴다고 했다간 계약이 날아간다. 결국 개인 개발자와 소규모 팀이 데이터 제공자가 되는 구조다. 월 $10 내고 Copilot Pro를 쓰면서 동시에 Microsoft의 AI 학습 데이터도 제공하는 셈이다.

이전에 Copilot이 프롬프트 인젝션 공격에 취약하다는 분석을 한 적 있다. 그때도 핵심은 “사용자가 인지하지 못하는 사이에 데이터가 흘러간다”는 것이었다. 이번 정책 변경도 같은 맥락이다.

코드만 가져가는 게 아니다

수집 범위의 실체

GitHub FAQ에 명시된 수집 대상 목록이다:

수집 항목:
- 커서 주변의 코드 (code surrounding the cursor)
- 주석과 문서 (comments and documentation)
- 파일명 (file names)
- 레포지토리 구조 (repository structure)
- 탐색 패턴 (navigation patterns)
- Copilot Chat 대화 기록 (chats with Copilot features)
- 제안에 대한 피드백 — 수락/거부 (thumbs-up or thumbs-down)

이 목록이 의미하는 건 단순하다. 코드 조각만 수집하는 게 아니라, 어떤 파일을 어떤 순서로 열었는지, Copilot에게 무슨 질문을 했는지, 어떤 제안을 수락하고 거부했는지까지 전부 포함된다. 코드 학습이 아니라 개발자 행동 패턴 학습이다.

내 생각엔 이게 더 위험하다. 코드 스니펫은 컨텍스트 없이는 의미가 제한적이지만, 개발 패턴 데이터는 “이 개발자가 어떤 문제에서 막히는지, 어떤 유형의 코드를 자주 쓰는지, 어떤 아키텍처를 선호하는지”를 드러낸다. 이건 GitHub이 Copilot 추천 품질을 높이는 데 쓸 수도 있지만, 경쟁 제품과의 차별화 무기가 되기도 한다.

이전에 거부한 사용자는 안전한가

기존 설정은 유지된다

한 가지 다행인 건, 이전에 데이터 수집을 거부한 사용자는 설정이 유지된다는 점이다. GitHub FAQ 원문이다:

If you previously opted out of the setting allowing GitHub to collect this data for product improvements, your preference has been retained.

2024~2025년 사이에 Copilot 설정에서 데이터 수집을 껐던 사람은 4월 24일에 자동 활성화되지 않는다. 하지만 한 번도 설정을 건드린 적이 없는 사용자는 전부 자동 활성화된다. Copilot을 쓰면서 설정 페이지를 한 번이라도 열어본 사람이 얼마나 될까.

지금 당장 확인하는 두 가지 방법

방법 1: 브라우저에서 직접 끄기

https://github.com/settings/copilot

접속 후 Privacy 섹션에서 Allow GitHub to use my data for AI model training 항목을 찾아서 OFF로 변경한다.

방법 2: 터미널에서 설정 페이지 바로 열기

# macOS
open "https://github.com/settings/copilot"

# Linux
xdg-open "https://github.com/settings/copilot"

# Windows
start https://github.com/settings/copilot

설정 변경 자체는 웹에서만 가능하지만, 터미널에서 바로 열 수 있다. 10초면 끝난다.

옵트아웃 버튼 하나로 끝나지 않는 이유

설정을 끄는 건 쉽다. 하지만 더 근본적인 질문이 남는다.

이미 수집된 데이터는 어떻게 되는가. GitHub은 이전에 수집한 “제품 개선용” 데이터와 이번 “AI 학습용” 데이터를 어떻게 구분하는지 명확하게 밝히지 않았다. 유럽 사용자는 GDPR의 ‘right to erasure’로 삭제를 요청할 수 있지만, 한국이나 미국 사용자에게는 동일한 경로가 아직 없다.

GitHub 없이 개발이 가능한가. 현실적으로 GitHub은 대체가 어렵다. GitLab, Bitbucket, Codeberg 같은 대안이 있지만, 오픈소스 생태계의 중심은 여전히 GitHub이다. 이직할 때 “GitHub 프로필 보여주세요”라고 하는 세상에서, GitHub을 떠나는 건 개발자 커리어에 불이익이 될 수 있다. 이 구조적 종속이 GitHub에게 기본값을 바꿀 자신감을 준 것일 수도 있다.

이건 시작일 뿐이다. Microsoft는 이미 LinkedIn 데이터로 AI 학습을 하고 있고, Bing 검색 데이터도 Copilot 학습에 활용한다. GitHub 코드 데이터는 Microsoft AI 전략의 마지막 퍼즐 조각이었다. opt-out 기본값이라는 작은 스위치 하나가, 전 세계 개발자의 코딩 패턴을 Microsoft의 모델에 주입하는 파이프라인을 완성한다.

4월 24일이 한 달도 안 남았다. 지금 터미널을 열어라.

# 설정 페이지로 바로 이동 — OS별 명령어
open "https://github.com/settings/copilot"       # macOS
xdg-open "https://github.com/settings/copilot"   # Linux
start https://github.com/settings/copilot         # Windows

끄는 데 10초면 된다. 안 끄면 영원히 학습된다.

팀워크는 거짓말이다 — 개발팀 생산성의 불편한 진실

Thu, 26 Mar 2026 06:00:00 +0000

1947년, 미군 역사학자 S.L.A. Marshall은 충격적인 데이터를 발표했다. 제2차 세계대전 전투에서 실제로 총을 발사한 소총수는 전체의 15~20%에 불과했다. 나머지 80%는 총을 들고 있었지만 방아쇠를 당기지 않았다.

이 수치는 80년이 지나도 달라지지 않았다. 전장만 바뀌었을 뿐이다. 슬랙 채널과 줌 회의실에서도 실제로 ‘총을 쏘는’ 사람은 소수다.

지난주 Joan Westenberg의 “Collaboration” is bullshit 글이 GeekNews에서 20개 댓글, Hacker News에서 수백 개의 댓글을 끌어모았다. 찬반은 65 대 35로 “협업이 과대평가됐다”는 쪽이 우세했다. 30년 경력 개발자부터 스타트업 창업자까지, 댓글의 핵심은 하나였다 — “내 팀에서도 실제로 일하는 사람은 소수다.”

직접 써보니 나도 같은 경험이 있다. 10명짜리 팀에서 일할 때, 스프린트 회고에서 발언하는 사람은 항상 같은 3명이었다. 나머지 7명은 고개를 끄덕이거나 노트북 화면을 쳐다봤다. 그런데 매니저는 “우리 팀의 협업이 잘 되고 있다”고 보고했다.

애자일이 만든 ‘협업 극장’

회의가 곧 일이 된 팀

스탠드업, 스프린트 리뷰, 회고, 그루밍, 플래닝 포커. 애자일 방법론이 한국 개발팀에 정착한 이후, 개발자의 하루에는 ‘의식(ritual)’이 늘었다. 문제는 이 의식들이 코드 품질이나 출시 속도에 기여하는가이다.

2024년 Microsoft Research 조사에 따르면, 개발자는 평균 6~9분마다 업무를 중단당한다. Slack 알림, 멘션, 스레드 답변, 줌 초대. 한 번 중단되면 원래 맥락을 되찾는 데 평균 23분이 걸린다는 연구 결과도 있다. 하루에 컨텍스트 스위칭만 10~15회라면, 순수 코딩 시간은 하루 3시간도 안 된다.

도구는 쌓이는데 코드는 안 나온다

Notion, Jira, Confluence, Slack, Figma, Linear. 팀이 사용하는 협업 도구의 수는 2020년 이후 2배 넘게 늘었다. 그런데 도구가 늘어난 만큼 코드가 나왔는가?

Joan Westenberg의 표현을 빌리면, “투명성과 가시성을 진짜 진전이라고 착각하기 시작했다.” Jira 보드의 티켓을 옮기고, Confluence에 회의록을 정리하고, Slack에서 스레드를 만드는 행위 자체가 “일”이 되어버린 것이다. 내 경험상, 협업 도구를 가장 열심히 쓰는 사람과 가장 많은 코드를 배포하는 사람은 거의 겹치지 않았다.

이 현상에는 이름이 있다. 1913년 프랑스 농업공학자 Maximilien Ringelmann이 줄다리기 실험에서 발견한 링겔만 효과다. 줄을 잡는 사람이 늘어날수록, 각자가 쓰는 힘은 줄어든다. 심리학에서는 ‘사회적 태만(Social Loafing)’이라 부른다. 팀이 커지면 “누군가 하겠지”라는 무의식이 작동한다.

80 대 20 — git log는 거짓말을 안 한다

이론은 됐고, 숫자를 보자. 터미널을 열고 다음 명령을 쳐보라. 당신 팀의 현실이 그대로 드러난다.

# 최근 6개월간 팀원별 커밋 수 확인
git shortlog -sn --since="6 months ago" --no-merges

# 팀원별 실제 코드 변경량(추가+삭제) 집계
git log --since="6 months ago" --no-merges --format='%aN' --numstat \
  | awk '/^[0-9]/{a[n]+=$1; d[n]+=$2} /^[^0-9]/{n=$0} \
    END{for(i in a) print a[i]+d[i], i}' \
  | sort -rn

이 명령은 팀 레포지토리에서 누가 얼마나 코드를 움직였는지를 한 눈에 보여준다. 상위 20%의 개발자가 전체 코드 변경량의 70~80%를 차지하는 패턴이 나올 것이다. 이건 당신 팀만의 문제가 아니다. 파레토 분포는 거의 모든 소프트웨어 프로젝트에서 반복된다.

Frederick Brooks는 1975년 《맨먼스 미신(The Mythical Man-Month)》에서 “늦어지는 프로젝트에 인력을 투입하면 더 늦어진다”고 경고했다. 50년이 지났지만 이 법칙을 무시하는 조직은 여전히 넘친다. 이유는 간단하다. 커뮤니케이션 오버헤드는 n(n-1)/2로 증가한다. 5명일 때 10개이던 소통 경로가 10명이면 45개, 20명이면 190개가 된다.

AI 코딩 에이전트가 판을 뒤집었다

이 논쟁이 2026년에 다시 불붙은 데는 이유가 있다. AI 코딩 도구가 개인의 생산성 천장을 깨버렸기 때문이다.

1인 개발 생산성의 폭발

이전에 다뤘던 YC CEO Garry Tan의 gstack 프로젝트가 이 논쟁에 불을 붙였다. Claude Code를 활용한 가상 엔지니어링 팀으로, 한 명이 60만 줄 이상의 코드를 생산했다는 주장이다. 과장이 섞였을 수 있지만, 방향성은 부정하기 어렵다.

GeekNews에서도 “Claude Code로 생산성을 높이는 방법”(33포인트)이 동시에 트렌딩됐다. 반복 작업 자동화와 병렬 워크트리로 커밋 수가 급증했다는 경험담이 줄을 이었다.

곱셈기 효과는 상위 20%에게만 작동한다

여기서 불편한 진실이 하나 더 나온다. AI 코딩 도구의 본질은 “평범한 개발자를 슈퍼 개발자로 만드는 것”이 아니다. 이미 생산적인 20%를 더 생산적으로 만드는 것이다.

코드 맥락을 정확히 이해하고, 프롬프트를 효과적으로 쓰고, AI가 뱉은 결과물을 검증할 수 있는 사람만이 진짜 생산성 폭발을 경험한다. 나머지에게 AI는 또 하나의 도구일 뿐이다. Notion이 추가되었을 때와 다를 바 없다.

# Brooks의 법칙 시뮬레이션: 팀 규모별 실질 생산량
def team_output(n, output_per_person=100, overhead_per_pair=2):
    """팀 규모별 순 생산량 계산"""
    paths = n * (n - 1) / 2          # 커뮤니케이션 경로 수
    overhead = paths * overhead_per_pair
    gross = n * output_per_person
    net = max(0, gross - overhead)
    return n, gross, overhead, net, f"{net/gross*100:.0f}%"

print(f"{'팀원':>4}  {'총생산':>6}  {'오버헤드':>8}  {'순생산':>6}  {'효율':>5}")
print("-" * 38)
for size in [3, 5, 8, 12, 20]:
    m, g, o, net, eff = team_output(size)
    print(f"{m:4d}  {g:6d}  {o:8.0f}  {net:6.0f}  {eff:>5}")

이 시뮬레이션을 돌려보면, 팀원 12명을 넘어서면 효율이 급격히 떨어진다. 20명이면 순 생산량이 8명짜리 팀보다 낮아지는 역전 현상까지 발생한다. 물론 현실에서 오버헤드 계수는 팀마다 다르겠지만, 방향성은 변하지 않는다.

그래서 팀을 해체하라는 건가?

아니다. 핵심은 ‘협업’과 ‘조율’을 구분하는 것이다.

조율(Coordination)은 필요하다. 누가 어떤 모듈을 담당하고, API 스펙은 어떻게 맞추고, 배포 일정은 언제인지 합의하는 것. 이건 오버헤드가 아니라 기반 구조다.

협업(Collaboration)이 문제가 되는 건, 모두가 모든 결정에 참여해야 한다는 환상 때문이다. 코드 리뷰에 5명이 달라붙고, 아키텍처 결정에 팀 전체 투표를 하고, 디자인 리뷰에 백엔드 개발자까지 소환하는 식이다.

Hacker News 토론에서 30년 경력의 한 개발자는 이렇게 썼다:

“The date is always more important than the actual deliverable.”

조직이 정말 신경 쓰는 건 산출물의 품질이 아니라 데드라인이다. 그리고 데드라인을 지키는 가장 확실한 방법은 결정권자를 줄이는 것이지, 회의 참석자를 늘리는 것이 아니다.

Linux 커널처럼 대규모 협업이 성공한 사례도 분명히 있다. 하지만 Linux 커널의 구조를 자세히 보면, 실은 수천 개의 소규모 독립 팀이 명확한 서브시스템 오너십 아래에서 움직이는 구조다. “모두가 함께”가 아니라, “각자의 영역에서 책임지고 만든 것을 합친다”에 가깝다.

당신 팀의 git log가 말해주는 한 가지

결국 협업이 헛소리인지 아닌지는 추상적 논쟁이 아니다. git log를 열면 답이 나온다.

내 팀에서 실제로 코드를 밀어넣는 사람이 몇 명인지, 나머지는 뭘 하고 있는지, 회의에 쓰는 시간 대비 배포 빈도는 어떤지. 측정할 수 있는 것은 측정해야 한다.

그리고 측정 결과가 80 대 20을 보여준다면, 두 가지 선택지가 있다.

팀을 줄이고 개인에게 권한을 준다. AI 도구로 무장한 3명이 10명의 “협업 팀”보다 빠르게 움직일 수 있다.
80%의 기여도를 끌어올릴 구조를 만든다. 회의를 줄이고, 오너십을 명확히 하고, 블로킹을 없앤다.

어느 쪽이든, 지금 하고 있는 “모두가 참여하는 협업”은 답이 아니다. 진짜 생산성은 혼자 집중하는 오후 3시간에서 나온다. 슬랙 알림을 끄고, 줌 초대를 거절하고, 에디터만 바라보는 그 시간에서.

OpenAI가 Python 생태계를 삼켰다 — uv·Ruff·ty가 OpenAI 소유가 된 날

Thu, 26 Mar 2026 01:00:00 +0000

Python 개발자라면 지금 커뮤니티에서 무슨 이야기가 오가는지 알아야 한다.

2026년 3월 19일, OpenAI가 Astral을 인수했다고 발표했다. Astral은 uv, Ruff, ty를 만든 회사다. 매일 쓰던 그 도구들이 이제 OpenAI 소유가 됐다. Hacker News 스레드는 발표 직후 수 시간 만에 757 포인트, 475개 댓글을 기록했다. 분위기는 단 하나였다: 불안.

이 글은 무슨 일이 벌어졌는지, 왜 커뮤니티가 반응했는지, 그리고 개발자가 지금 실질적으로 어떻게 생각해야 하는지를 정리한다.

Astral은 도대체 뭔 회사인가

Astral은 Python 생태계에서 “Rust로 만든 도구가 얼마나 빠를 수 있는지”를 증명한 스타트업이다. 창업자 Charlie Marsh가 이끄는 소규모 팀이지만, 이들이 만든 도구는 Python 커뮤니티 전체의 기반 인프라가 됐다.

uv: Python 패키지 매니저. 2024년 2월 출시 이후 월 1억 2,600만 다운로드를 기록 중이다. pip의 후계자로 불리며, 가상환경 생성부터 의존성 관리까지 기존 대비 10~100배 빠르다. 이 속도는 Rust로 구현했기 때문이다.

# uv 설치 및 사용 예시
curl -LsSf https://astral.sh/uv/install.sh | sh

# pip 대신 uv
uv pip install requests pandas numpy

# 가상환경 생성
uv venv .venv

# 프로젝트 초기화 (pyproject.toml 자동 생성)
uv init my-project

Ruff: Python 린터 + 포매터. Flake8, Black, isort를 대체한다. 기존 도구 대비 10~100배 빠른 속도로 Python 프로젝트 코드 품질 관리에 사실상 표준이 됐다.

ty: 타입 체커. mypy의 경쟁자로 빠르게 자리를 잡아가고 있다.

세 도구의 공통점은 두 가지다. Rust로 작성됐고, 수십만 개의 오픈소스 프로젝트에서 사용되고 있다는 것.

OpenAI는 왜 Python 도구 회사를 샀나

표면적 이유는 간단하다: Codex를 키우기 위해서다.

OpenAI의 AI 코딩 에이전트 Codex는 현재 주간 활성 사용자 200만 명을 넘겼다. 연초 대비 3배 성장이다. Codex가 Python 코드를 생성할 때, 그 코드가 실행되는 환경에는 uv와 Ruff가 있다. 개발 환경의 기반 툴체인을 직접 소유하면 Codex와의 연동을 훨씬 깊게 만들 수 있다.

OpenAI 측 발표:

“Astral 팀이 Codex 팀에 합류하면, 개발자가 이미 사용하는 도구와 Codex가 직접 상호작용하는 더 깊은 통합을 탐구할 수 있게 됩니다.”

쉽게 말하면: AI가 코드를 짤 때 패키지 매니저와 린터를 AI가 직접 제어하겠다는 뜻이다.

비슷한 움직임이 AI 업계에서 동시에 일어나고 있다. Anthropic은 2025년 12월 JavaScript 런타임 Bun을 인수했다. AI 코딩 에이전트들이 개발자 툴체인의 기반부터 장악하는 흐름이다.

커뮤니티는 왜 불안해하는가

MIT 라이선스 도구라 오픈소스는 유지된다. 그런데 왜 개발자들은 불안해하는가.

첫 번째 우려: 개발 우선순위 이동

Astral 엔지니어들이 OpenAI의 상업적 목표에 재배치되면, 지금처럼 uv와 Ruff 유지보수에 집중하기 어려워진다. GitHub 이슈가 쌓이고, 새 Python 버전 지원이 늦어지고, 버그 수정 주기가 길어질 수 있다. “도구가 사라지는 게 아니라, 정체되는 것”이 더 현실적인 걱정이다.

두 번째 우려: 오픈소스 지배력의 독점

Simon Willison(Django 공동 창업자)이 지적한 핵심 포인트다: OpenAI는 대형 오픈소스 프로젝트를 인수 후 유지보수한 경험이 거의 없다. 이전 사례들을 보면 인수 후 점진적 소홀함이 나타나는 경우가 많았다.

세 번째 우려: 생태계 포획(Ecosystem Capture)

Python 개발자 대부분이 의존하는 핵심 도구를 AI 회사 하나가 소유하게 된다. 지금 당장은 문제없다. 1년 뒤에도 아마 괜찮을 것이다. 하지만 5년 뒤 OpenAI가 uv에 유료 기능을 추가하거나, Codex 구독자에게 Ruff 고급 기능을 제공하기 시작하면?

# 현재 Ruff 설정 (pyproject.toml)
[tool.ruff]
line-length = 88
select = ["E", "F", "W", "I"]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"

# 이 설정이 언제까지 완전히 무료로 유지될까?

MIT 라이선스의 의미 — 정말 안전한가

Astral 측 Douglas Creager의 공식 입장:

“uv와 Ruff는 MIT 라이선스입니다. 이건 영원히 변하지 않습니다. 최악의 경우 포크해서 가면 됩니다.”

MIT 라이선스는 강력한 보호막이다. OpenAI가 내일 당장 uv를 비공개 소프트웨어로 전환하는 건 불가능하다. 기존 버전은 영구히 MIT 라이선스로 남는다.

그러나 현실적인 리스크는 다른 곳에 있다.

시나리오	MIT 라이선스로 보호되는가	실제 위험도
uv 소스 코드 비공개 전환	보호됨 (기존 버전 포크 가능)	낮음
신규 기능 유료화	보호 안 됨	중간
유지보수 방치	보호 안 됨	높음
OpenAI 전용 기능 우선 개발	보호 안 됨	높음
커뮤니티 기여 반영 축소	보호 안 됨	중간

포크는 기술적으로 가능하다. 하지만 포크 후 uv 수준의 도구를 소규모 커뮤니티가 유지하는 것은 현실적으로 다른 이야기다. Astral은 전문 엔지니어 팀 + VC 자금으로 여기까지 왔다. 커뮤니티 포크는 그 반의 반도 투자하기 어렵다.

Anthropic과 OpenAI의 툴체인 장악 경쟁

이번 인수는 더 큰 그림의 일부다.

2025년 12월: Anthropic이 Bun(JavaScript 런타임) 인수
2026년 3월: OpenAI가 Astral(Python 툴체인) 인수

JavaScript 생태계는 Anthropic이 기반을 잡았고, Python 생태계는 OpenAI가 가져갔다. 두 회사 모두 AI 코딩 에이전트(Claude Code, Codex)를 키우고 있다. 에이전트가 코드를 작성할 때 사용하는 런타임과 도구를 직접 소유하면 전체 개발 경험을 설계할 수 있다.

개발자 입장에서 이 흐름이 의미하는 것:

앞으로 더 많은 개발자 도구가 AI 회사의 품으로 들어올 것이다
“내가 쓰는 오픈소스 도구를 누가 소유하고 있는가”가 중요한 질문이 된다
의존성 다양화(특정 생태계에 올인하지 않기)가 리스크 관리 전략이 된다

지금 당장 해야 할 것과 안 해야 할 것

지금 당장 할 필요 없는 것:

uv, Ruff, ty에서 다른 도구로 전환. 아직 아무것도 바뀌지 않았다.
패닉. MIT 라이선스 도구는 내일 사라지지 않는다.

지금부터 눈여겨봐야 할 것:

GitHub에서 uv, ruff, ty 레포의 이슈 해결 속도 변화
커뮤니티 기여 PR merge 속도
OpenAI가 Codex에 이 도구들을 어떻게 통합하는지
향후 유료화 시도가 있는지 여부

# 현재 사용 중인 Astral 도구 버전 확인
uv --version
ruff --version

# 만약 마이그레이션이 필요한 상황이 오면
# 대안 패키지 매니저: pip, poetry, pdm
# 대안 린터: pylint, flake8
# 대안 포매터: black
# 지금 당장은 대안 전환 불필요

인수 발표 직후 Astral 창업자 Charlie Marsh는 이렇게 썼다:

“We’ll keep building in the open, alongside our community – and for the broader Python ecosystem.”

이 약속이 얼마나 지켜지는지가 앞으로 1~2년간의 핵심 관전 포인트다. Python 개발자라면 기억해둬야 한다: 2026년 3월 19일, 당신이 매일 쓰는 도구의 주인이 바뀐 날이었다.

마치며

OpenAI의 Astral 인수는 단순한 M&A 뉴스가 아니다. AI 회사들이 개발자 생태계의 기반 인프라를 장악하는 더 큰 흐름의 신호탄이다.

지금 당장 도구를 교체할 필요는 없다. 하지만 자신이 의존하는 오픈소스 도구가 누구 소유인지, 그 소유자의 인센티브가 커뮤니티와 일치하는지를 주기적으로 확인하는 습관이 필요한 시대가 됐다.

uv와 Ruff는 여전히 훌륭한 도구다. 오늘도 내일도 쓸 수 있다. 다만 그 뒤에 누가 있는지를 이제 알게 됐을 뿐이다.

보안 스캐너가 백도어로 변했다 — LiteLLM 공급망 해킹, AI 앱 전체가 위험하다

Wed, 25 Mar 2026 01:00:00 +0000

어제 오전(3월 24일, UTC 기준) AI 생태계에 조용하지만 치명적인 폭탄이 터졌다. 보안 취약점을 잡아주는 스캐너가 오히려 공격의 진입로가 됐고, AI 프록시 라이브러리 LiteLLM의 PyPI 패키지에 백도어가 심어졌다.

일일 다운로드 340만 회. 쿠버네티스 자격증명부터 AWS 키, SSH 개인키, 암호화폐 지갑까지 한꺼번에 탈취하는 3단계 페이로드. 그리고 공격의 핵심에는 아무도 의심하지 않는 보안 도구 Trivy가 있었다.

LiteLLM이 뭔데 이렇게 중요한가

LiteLLM은 OpenAI, Anthropic, Google Gemini, AWS Bedrock, Ollama 등 100개 이상의 LLM API를 단일 인터페이스로 추상화하는 Python 라이브러리다. 쉽게 말해 AI 앱의 게이트웨이 레이어다.

스타트업이든 대기업이든 AI 기능을 붙이는 개발팀 상당수가 LiteLLM을 쓴다. 프록시 서버 모드로 쓰면 여러 팀이 하나의 엔드포인트로 GPT-4o, Claude, Gemini를 돌려가며 쓸 수 있고, 비용 추적과 레이트 리밋까지 한 번에 관리된다. 그만큼 운영 환경 깊숙이 들어가 있는 라이브러리다.

일일 다운로드 340만 회라는 숫자가 이번 사건이 왜 심각한지를 설명한다. PyPI 역대 공급망 공격 중 잠재적 피해 규모 기준으로 손에 꼽힌다.

공격 체인 전체를 해부한다

이 공격이 특히 무서운 이유는 단순한 악성 패키지 업로드가 아니라는 점이다. 보안 도구 자체를 감염시켜 다른 프로젝트들을 연쇄 감염시키는 정교한 공급망 공격이다.

1단계: Trivy GitHub Action 침투 (2월 말)

Trivy는 Aqua Security가 만든 오픈소스 취약점 스캐너다. 컨테이너 이미지, 파일시스템, IaC 코드를 스캔해 CVE를 잡아준다. CI/CD 파이프라인에 박혀 있는 흔한 보안 도구다.

공격자 TeamPCP는 Trivy의 GitHub 워크플로우에서 pull_request_target 트리거의 취약점을 발견했다. 이 워크플로우는 외부 PR에서도 저장소 시크릿에 접근할 수 있는 권한이 열려 있었다. 악성 PR 하나로 Trivy의 내부 시크릿을 탈취할 수 있었던 것이다.

2단계: Trivy 릴리스 태깅 변조 (3월 19일)

Trivy의 PyPI 배포 토큰을 손에 넣은 공격자는 v0.69.4 Git 태그를 악성 릴리스로 재작성했다. 이 시점부터 Trivy를 CI에서 돌리는 모든 프로젝트가 잠재적 피해 대상이 됐다.

3단계: Checkmarx KICS도 감염 (3월 23일)

같은 날 또 다른 보안 도구인 Checkmarx의 KICS GitHub Action도 동일한 인프라로 공격받았다. C2(Command and Control) 도메인도 이 시점에 등록됐다. 무대를 다 깔았다는 신호다.

4단계: LiteLLM CI/CD에서 PyPI 토큰 탈취 (3월 24일 10:39 UTC)

LiteLLM의 CI/CD 파이프라인이 Trivy를 실행하는 순간, 감염된 Trivy가 PYPI_PUBLISH 토큰을 포함한 환경 변수 전체를 C2 서버(https://models.litellm.cloud/)로 전송했다. 이 도메인은 겉으로 보면 LiteLLM 공식 인프라처럼 보이도록 설계됐다.

5단계: 악성 패키지 배포 (3월 24일 10:52 UTC)

토큰 탈취 후 불과 13분 만에 악성 버전 1.82.7이 PyPI에 올라갔다. 이어서 더 공격적인 벡터를 추가한 1.82.8도 배포됐다. 두 버전 모두 약 3시간 후 PyPI 보안팀에 의해 격리됐다.

악성 페이로드 3단계 구조

# litellm/proxy/proxy_server.py (1.82.7)에 삽입된 base64 인코딩 페이로드 일부 (재구성)
import base64, subprocess
_payload = "aW1wb3J0IG9zLCBzb2NrZXQsIHN0cnVjdC4uLg=="  # 실제 악성 코드 (예시)
exec(base64.b64decode(_payload))

1단계: 크리덴셜 하베스터

감염 즉시 실행되는 정보 수집 모듈이다. 탈취 대상은 다음과 같다.

대상	경로
SSH 개인키	`~/.ssh/id_*`
.env 파일	현재 디렉토리 및 상위 경로
AWS 자격증명	`~/.aws/credentials`
Kubernetes 설정	`~/.kube/config`
Git 자격증명	`~/.git-credentials`
암호화폐 지갑	공통 지갑 파일 경로

수집된 데이터는 AES-256-CBC + RSA-4096 조합으로 암호화된 후 tpcp.tar.gz로 패키징돼 C2 서버로 전송된다.

2단계: Kubernetes 횡이동 키트

쿠버네티스 환경이 감지되면 node-setup-* 이름의 악성 파드를 kube-system 네임스페이스에 배포한다. Privileged 컨테이너로 클러스터의 모든 노드에 퍼진다. 클러스터 단위 대규모 침해로 이어질 수 있는 가장 위험한 단계다.

3단계: 지속성 백도어

~/.config/sysmon/sysmon.py

systemd 사용자 서비스(sysmon.service)로 등록돼 C2 서버를 폴링하면서 추가 바이너리를 다운로드·실행한다. 패키지를 삭제해도 백도어가 남아 있어 이 파일을 별도로 제거해야 한다.

버전 1.82.8의 추가 벡터는 더 심각하다. .pth 파일을 사이트 패키지에 심어 Python이 시작될 때마다 자동 실행되게 만들었다. 패키지를 제거해도 .pth 파일이 남아 있으면 매 Python 실행마다 악성 코드가 돌아간다.

지금 당장 확인해야 할 것들

LiteLLM을 쓰고 있다면, 아니 AI 스택 어딘가에 Python 패키지가 있다면 지금 바로 다음을 실행해야 한다.

1. 버전 확인

pip show litellm

Version: 1.82.7 또는 1.82.8이 보인다면 즉시 업그레이드 또는 다운그레이드해야 한다.

pip install litellm==1.82.6  # 안전 버전으로 다운그레이드
# 또는
pip install --upgrade litellm  # 최신 안전 버전으로 업그레이드

2. 백도어 파일 확인

ls -la ~/.config/sysmon/
systemctl --user list-units | grep sysmon

3. Kubernetes 악성 파드 확인

kubectl get pods -A | grep node-setup-

node-setup-으로 시작하는 파드가 있다면 클러스터가 감염된 것이다.

4. 자격증명 즉시 교체

감염이 확인됐다면 순서가 중요하다. AWS/GCP/Azure 액세스 키, Kubernetes 서비스 어카운트 토큰, GitHub Personal Access Token, 데이터베이스 비밀번호, SSH 키 전체를 교체해야 한다. 이미 C2 서버로 전송된 자격증명은 재사용될 수 있다.

커뮤니티에서 만들어진 감염 탐지 스크립트도 있다: litellm-vuln-detector

이 사건이 개발자에게 던지는 진짜 질문

보안 도구가 공격 벡터가 됐다

역설이 아닐 수 없다. CI/CD에 Trivy를 붙인 이유는 보안을 강화하기 위해서였다. 그런데 그 보안 도구 자체가 공격의 진입로가 됐다. 신뢰받는 도구일수록 더 위험한 벡터가 된다는 공급망 공격의 본질이 여기서 드러난다.

`pull_request_target` 워크플로우 패턴

이번 Trivy 침해의 핵심은 GitHub Actions의 pull_request_target 이벤트 트리거다. 외부 포크에서 오는 PR도 저장소 시크릿에 접근할 수 있게 되는 이 패턴은 이미 2021년부터 GitHub이 경고해온 안티패턴이다. 보안 스캐너를 포함해 많은 오픈소스 프로젝트가 여전히 이 취약점을 갖고 있다.

직접 CI/CD를 관리하는 팀이라면 지금 당장 워크플로우를 감사해야 한다.

# 위험: 외부 PR에서 시크릿에 접근 가능
on:
  pull_request_target:
    types: [opened, synchronize]

AI 툴링의 보안 부채

LiteLLM이 340만 다운로드를 기록할 수 있었던 이유는 AI 붐과 함께 폭발적으로 성장했기 때문이다. 빠르게 성장하는 프로젝트는 기능 개발 속도에 비해 보안 감사가 뒤처지기 쉽다. PyPI 토큰을 .env 파일로 관리한 것이 그 결과다. AI 인프라를 구축하는 팀들이 지금 얼마나 빠른 속도로 달리면서 보안을 후순위로 미루고 있는지 돌아볼 필요가 있다.

마치며

공급망 공격은 “내가 직접 악성 코드를 다운로드할 리 없다”는 안일한 믿음을 깨는 공격이다. 내가 믿는 도구, 내 팀이 검증했다고 생각했던 도구가 이미 감염된 상태로 내 파이프라인에 들어올 수 있다.

LiteLLM 사태는 AI 생태계가 얼마나 빠르게 넓어지고 있는지, 그리고 그 확장 속도에 비해 보안 관행이 얼마나 느리게 따라오는지를 보여준다. 빠르게 움직이는 건 좋다. 하지만 보안 스캐너를 도입했다고 해서 끝이 아니다. 그 스캐너 자체가 안전한지도 검증해야 한다.

본 글은 공개된 보안 연구 자료와 사고 분석 보고서를 바탕으로 작성되었습니다. 취약점 악용 방법을 권장하지 않으며, 방어적 목적의 이해를 돕기 위해 공격 메커니즘을 설명했습니다.

출처: