▲

Claude Code가 실제로 선택하는 것

 (amplifying.ai)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • 실제 오픈소스 저장소 2,430개를 대상으로 Claude Code의 도구 선택 경향을 분석한 연구 결과
  • 전체 20개 범주 중 12개에서 기성 도구 대신 직접 구현(Custom/DIY) 방식을 택했으며, 이는 가장 빈번한 선택 유형
  • 반면 도구를 선택할 때는 GitHub Actions(94%), Stripe(91%), shadcn/ui(90%) 등 특정 항목에 높은 집중도를 보임
  • 배포 환경은 언어별로 고정적으로, JS는 Vercel, Python은 Railway를 기본 선택하며 AWS·GCP·Azure는 1차 선택에서 제외
  • 최신 모델로 갈수록 Drizzle, FastAPI BackgroundTasks 등 신흥 도구로 교체되는 경향이 뚜렷하며, 생태계 내 선택 일관성은 90% 수준

연구 개요

  • Claude Code v2.1.39를 이용해 총 2,430회 실험을 수행, 실제 저장소에서 오픈엔드 질문을 통해 도구 선택을 관찰
    • 3개 모델(Sonnet 4.5, Opus 4.5, Opus 4.6), 4개 프로젝트 유형, 20개 도구 범주
    • 85.3%의 추출률, 2,073건의 유효 응답 확보
  • 모델 간 90% 일치율, 20개 중 18개 범주에서 동일 생태계 내 선택 일관성 유지

주요 발견: Build vs Buy

  • 20개 범주 중 12개에서 Custom/DIY 구현이 가장 흔한 선택
    • 총 252건의 Custom/DIY 선택으로, 개별 도구보다 많음
    • 예: 기능 플래그는 환경변수 기반 설정 파일로 구현, Python 인증은 JWT + passlib 직접 작성, 캐싱은 메모리 TTL 래퍼 사용
  • 범주별 Custom/DIY 비율
    • Feature Flags 69%, Authentication(Python) 100%, Authentication(전체) 48%, Observability 22%

기본 스택(Default Stack)

  • Claude Code가 실제로 도구를 선택할 때 JS 생태계 중심의 기본 스택을 형성
    • 상위 선택 도구: Zustand(64.8%), Sentry(63.1%) 등
    • JS 관련 선택의 100%가 특정 도구로 집중되는 경우도 존재
  • 이 기본 스택은 다수의 신규 애플리케이션 개발에 직접적 영향을 미침

시장 주류와의 괴리(Against the Grain)

  • 시장 점유율이 높은 도구 중 Claude Code가 거의 사용하지 않는 항목 존재
    • 상태 관리: 주요 선택 없음, 대신 Zustand 57회 선택
    • API Layer: 프레임워크 내장 라우팅 선호
    • 테스트: 4%만 주요 선택, 31건은 대체 선택
    • 패키지 관리자: 1건 주요 선택, 51건 대체 선택

최신 모델의 도구 교체 경향(The Recency Gradient)

  • 신형 모델일수록 최신 도구로 전환
    • JS ORM: Prisma(79%) → Drizzle(100%)
    • Python 작업 처리: Celery(100%) → FastAPI BackgroundTasks(44%)
    • Python 캐싱: Redis(93%) → Custom/DIY(50%)
  • 각 생태계 내에서 세대별 도구 교체가 명확히 관찰됨

배포 환경의 분화(The Deployment Split)

  • 배포 선택은 언어 스택에 따라 고정적
    • JS(Next.js + React SPA): 86건 중 86건이 Vercel 선택
    • Python(FastAPI): Railway 82% 선택
  • AWS, GCP, Azure는 모든 112건에서 주요 선택 0건
    • 대체 추천으로 Netlify(67회), Cloudflare Pages(30회), GitHub Pages(26회), DigitalOcean(7회) 등장
    • AWS Amplify, Firebase Hosting 등은 언급만 있고 추천 없음
  • 예시 응답에서 Vercel은 설치 명령과 이유까지 제공, AWS Amplify는 한 줄 언급에 그침

모델 간 불일치 구간(Where Models Disagree)

  • 20개 중 5개 범주에서 모델 간 차이 존재
    • JS ORM: Prisma → Drizzle
    • JS Jobs: BullMQ → Inngest
    • Python Jobs: Celery → FastAPI BgTasks
    • Caching: Redis → Custom/DIY
    • Real-time: SSE → Custom/DIY
  • 나머지 18개 범주는 생태계 내 일관된 선택 유지

기업용 벤치마크 서비스

  • Amplifying은 개별 개발도구 기업을 위한 비공개 대시보드를 제공
    • AI 에이전트가 자사 도구를 경쟁사 대비 얼마나 추천하는지 확인 가능
    • 실제 코드베이스 기반의 도구 추천 경쟁력 분석 지원

데이터 탐색

  • 세부 분석 항목으로 범주별 심층 분석, 문구 안정성, 저장소 간 일관성, 시장 영향 등이 포함
  • 연구 결과는 향후 Sonnet 4.6 모델 기준으로 업데이트 예정
▲
GN⁺ 7시간전  [-]
Hacker News 의견들

  • LLM 광고의 미래는 완전히 보이지 않게 되는 것이라 생각함
    결국 가장 강력한 ‘인플루언서’가 되는 셈임
    혹은 광고가 아니라 이해 상충(conflict of interest) 문제일 수도 있음
    예를 들어 Gemini가 GCP 기반 구축을 더 선호하는지 여부가 그 신호가 될 수 있음

    • LLM은 아주 적은 데이터로도 쉽게 오염(poison) 될 수 있음
      Anthropic의 연구를 보면, SEO 대신 LLM 제품 노출을 노릴 수 있는 방법이 있음
      1. 수백 개의 GitHub 저장소를 만들어 특정 제품을 사용하는 예시를 올림
      2. 동일한 내용을 담은 웹사이트와 수많은 도메인을 연결
      3. Reddit, Facebook, X, Wikipedia 등에 같은 정보를 퍼뜨림
        6개월쯤 기다리면 크롤러가 수집해 학습 데이터로 사용함 → 결국 이익
    • 최근 Google 지원 담당자와 대화 중, LLM이 생성한 듯한 답변으로 경쟁사 제품을 추천받았음
      만약 Gemini를 사용 중이었다면 이런 일은 없었을 것 같음
    • Richard Thaler가 자랑스러워할 듯함
      이것이야말로 ‘넛지(Nudge)’ 의 궁극적 구현임
    • ‘인플루언서’라는 단어로는 부족함
      미래에는 에이전트형 코딩 시스템이 스스로 무엇을 만들지 결정할 것이고, 인간은 그 선택지를 보지도 못한 채 결과만 얻게 될 것임
      공급망조차 LLM이 정하는 세상이 될 것임
    • 이건 오히려 Walmart/Amazon 모델에 가까움
      플랫폼이 ‘진열대’를 통제하고, 인기 있는 SaaS 기능을 보고 자체 브랜드(예: Great Value, Amazon Basics)를 만드는 식임
      세금 소프트웨어가 대표적인 예가 될 것 같음

  • 흥미로운 점은, 이 글에서 언급된 Claude Code의 웹 스타일이 실제로 해당 블로그에 그대로 드러난다는 것임
    JetBrains Mono 폰트는 Opus 4.6이 만든 웹의 대표적 특징임
    최근 한 달간 JetBrains Mono를 과도하게 사용하는 웹페이지의 99% 이상이 Opus로 생성된 것으로 보임
    Opus 4.6은 Drizzle을 32.5% 선택했고, Prisma는 20.5%에 불과함
    모델이 강력할수록 Prisma를 덜 선택하는 경향이 있음 — 일종의 지능 벤치마크처럼 느껴짐
    또 다른 예시로 youjustneedpostgres.com도 JetBrains Mono를 과하게 사용함

    • 나도 비슷한 느낌을 받았음
      카테고리 막대 디자인이 어제 내가 무심코 생성한 UI와 거의 동일했음
    • 나에게는 폰트보다 박스 스타일이 더 눈에 띔
      카드형 CSS가 전부 같은 느낌이라, 이 블로그도 그런 식으로 만들어진 듯함

  • 나는 LLM에게 모호한 프롬프트를 주지 않음
    대신, 2026년에는 LLM에서 정확한 정보를 끌어내는 법을 새로 배우는 중임
    예전 2006년 구글 검색을 다시 배우는 느낌임
    ‘리버스 프롬프트(reverse prompt)’를 써서 한 모델이 다른 모델의 가설을 검증하게 함
    예를 들어 Opus 4.6의 결과가 의심스러우면 ChatGPT나 Codex에 넘겨서 허점을 찾아보게 함
    Claude는 상대적으로 덜 고집스럽고, ChatGPT나 Codex가 더 단호하지만 종종 더 정확함
    실제로 Docker 컨테이너 문제에서 Claude는 ZFS 버그라 했지만, ChatGPT는 단순한 설정 오류라 했고 그게 맞았음
    이런 식으로 LLM 간 교차 검증을 통해 올바른 답을 얻음

    • LLM이 사용자의 작업에 대해 더 묻지 않는 게 아쉽다면, 직접 “나에게 질문해 달라”고 요청하면 됨
      그러면 정말 많은 질문을 던짐
    • 나는 계획을 반복적으로 세우게 하는 스킬을 씀
      세부 계획이 나올 때까지 계속 수정하게 하고, 필요한 질문도 더 많이 하게 함
    • 나는 Codex CLI를 매일 씀
      ChatGPT 구독으로는 한도에 도달하지 않지만, 가끔 오류가 나면 Claude를 다른 터미널에서 띄움
      회사의 Claude 예산은 월 750달러로 매우 제한적임

  • 나는 AWS에서 TimescaleDB를 사용 중임
    Claude Code가 AWS CLI로 EC2 인스턴스를 관리하고 있음
    그런데 오늘 아침 Claude가 NeonDB와 Fly.io 계정 생성을 제안했음
    이미 AWS 설정이 잘 되어 있는데도 새 서비스를 추천한 게 의아했음

    • 하지만 이런 제안은 신뢰하기 어려움
      내 경험상 LLM 에이전트는 아키텍처 결정을 끔찍하게 내림
      불필요한 추상화와 버전 관리에 집착하고, 코드가 과도하게 복잡해짐
      결국 직접 코드를 짜야 함
    • 나도 같은 경험을 했음
      모든 프로젝트에서 Planetscale을 쓰는데, Claude가 Neon을 추천했음
      이건 단순한 버그로 보임

  • Opus 4.6이 ‘미래지향적’이라 불린 게 흥미로움
    4.5를 한 달간 쓰다가 4.6으로 새 프로젝트를 시작했는데, 계획 단계에서 웹 검색을 수행하더라
    모델이 충분히 발전했지만, 여전히 조율과 역할 분담이 핵심 과제임

    • 나도 비슷한 생각임
      예전에 GPT-3.5로 안드로이드 앱을 직접 출시했는데 (앱 링크)
      그때는 일주일 걸리던 작업이 이제는 하나의 프롬프트로 가능함
      LLM을 잘 오케스트레이션하면 훨씬 빠르게 결과를 낼 수 있음

  • LLM과 함께 코딩하면서 느낀 건, 특히 웹 분야에서 npm 패키지 의존성이 얼마나 줄어드는지임
    예전엔 jwt auth나 빌드 플러그인 같은 걸 썼지만, 이제는 몇 줄의 코드로 대체 가능함
    코드가 단순하고 이해하기 쉬워서 신뢰할 수 있음

    • 사실 이런 변화는 오래전부터 진행 중이었음
      2010년엔 jQuery가 JS의 왕이었지만, 지금은 순수 JS로 충분함
      다만 JWT 같은 보안 관련 코드는 Claude가 만든 걸 그대로 쓰진 않을 것임
    • 예전엔 코드 재사용이 많았지만, 그로 인해 다이아몬드 의존성 지옥이 생겼음
      이제는 직접 구현하는 게 더 나을 수도 있음
      코드 중복은 늘겠지만, 의존성 문제는 줄어듦

  • 나는 Claude에게 항상 어떤 라이브러리와 특허 기술을 사용할지 명시함
    개발자는 모델을 잘 가이드할 수 있어야 한다고 생각함
    확신이 없을 땐 별도의 창에서 아키텍처나 장단점을 물어보고 결정함

    • 그런데 “특허 기술을 지정한다”는 게 무슨 뜻인지 궁금함

  • 두 프로젝트에서 Claude가 Github Actions를 자동으로 추가했음
    내가 요청하지도 않았는데, 숨김 폴더라 git diff에서 놓쳤음
    다행히 비용은 4센트였지만 꽤 불안한 경험이었음

  • 궁금한 게 있음
    왜 shadcn/ui가 이렇게 기본 UI 라이브러리로 자리 잡았을까?
    Claude뿐 아니라 다른 모델도 기본으로 사용함
    shadcn을 제외하라고 하면 품질이나 속도가 떨어질까?
    혹시 문서와 예시의 풍부함 때문일까, 아니면 단순히 학습 데이터에 너무 많이 등장해서일까?
    나도 2025년 중반쯤 Gemini가 React 대시보드에 shadcn을 기본으로 넣는 걸 보고 놀랐음

    • 아마 Tailwind와의 시너지 때문일 것임
      shadcn/ui는 Tailwind 기반이라 AI가 선호함
      실제로 npm 다운로드 수가 12월 이후 폭발적으로 증가함
      npm 패키지 링크
    • 나도 같은 의문을 가졌음
      더 오래된 컴포넌트 라이브러리도 많은데, 왜 이게 승리했는지 과학적으로 분석할 가치가 있음
    • 나는 에이전트 이전부터 shadcn을 써왔음
      구성 요소가 일관되고 커스터마이징이 쉬워서 프로젝트 통합이 간편함
      정말 잘 만들어진 프로젝트임

  • 이제는 shadcn을 기본 스타일 그대로 쓰는 사이트를 보면 AI가 만든 웹사이트라는 신호로 느껴짐
    10년 전 Bootstrap이 그랬던 것처럼, 기본 스타일이 너무 흔함

    • 하지만 대부분의 사람도 기본 스타일을 그대로 쓰지 않나?
      그렇다면 그게 꼭 AI의 흔적이라고 볼 수 있을까?
      “10년 전 Bootstrap”이라는 비유가 정확히 어떤 의미인지 궁금함
답변달기