Claude Code가 실제로 선택하는 것들: 2,430번 실험으로 밝혀진 기본 스택

Who Should Read

Claude Code나 다른 AI 코딩 도구를 실무에서 사용 중인 개발자, 특히 기술 스택 선택 시 AI 추천에 얼마나 의존해야 할지 고민하는 팀 리드나 아키텍트.

Core Mechanics

• 실험 설계: 3개 모델(Sonnet 4.5, Opus 4.5, Opus 4.6)에 4개 실제 저장소를 대상으로 도구 이름을 전혀 언급하지 않은 개방형 질문을 총 2,430번 던져 무엇을 선택하는지 관찰했다. 85.3%(2,073건)에서 유효한 선택을 추출했다.
• 가장 큰 발견은 'Build vs Buy' 경향이다. 20개 카테고리 중 12개에서 Claude Code는 외부 도구 대신 직접 구현을 선택했다. Feature flag 요청엔 LaunchDarkly 대신 env var + 비율 기반 config 시스템을 직접 짜고, Python 인증엔 JWT + bcrypt를 처음부터 구현한다.
• 그러나 도구를 선택할 때는 압도적으로 쏠린다. GitHub Actions 94%, Stripe 91%, shadcn/ui 90%로 특정 카테고리에서는 사실상 독점적 선택이 일어난다. JS 배포는 Vercel 100%, Python 배포는 Railway 82%로 나타났다.
• 모델별 성격 차이가 뚜렷하다. Sonnet 4.5는 보수적(Redis 93%, Prisma 79%, Celery 100%), Opus 4.5는 균형적(특정 도구를 가장 많이 명명, 86.7%), Opus 4.6은 전향적(Drizzle 100%, Inngest 50%, Prisma 0%, 자체 구현 가장 많음)으로 나뉜다.
• 세대 교체가 모델 업그레이드로 가속화되고 있다. Prisma→Drizzle(Sonnet 4.5에서 79%→Opus 4.6에서 0%), Celery→FastAPI BackgroundTasks(100%→0%), Redis→직접 구현(93%→29%) 같은 급격한 전환이 모델 버전 차이만으로 일어난다.
• Claude Code가 거의 선택하지 않는 도구들도 명확하다. Redux는 0번 primary 선택(Zustand 57회 대신 선택), Express는 완전히 부재, Jest는 4%만 선택(Vitest 선호), npm보다 pnpm, yarn은 1회에 불과하다.
• 배포 선택은 스택에 의해 완전히 결정된다. JS 프로젝트엔 Vercel 100%, Python 프로젝트엔 Railway 82%가 선택됐고 AWS/GCP/Azure는 primary pick 0회였다. 이는 실제 클라우드 시장 점유율과 크게 다른 결과다.
• 모델 간 동의율은 18/20 카테고리에서 90% 이상으로 높았다. 즉 '어떤 Claude 모델을 써도 비슷한 스택이 나온다'는 의미이고, Claude Code 사용자 전체가 서서히 같은 기술 스택으로 수렴하고 있다는 신호다.

Evidence

• LLM이 새로운 '보이지 않는 광고판'이 될 것이라는 우려가 제기됐다. 한 댓글은 "이건 궁극적인 인플루언서"라고 표현했고, Gemini가 GCP를 편향적으로 추천하는지 확인하는 게 이해충돌 카나리아가 될 것이라는 의견도 나왔다. 실제로 한 사용자는 AWS EC2와 TimescaleDB를 이미 잘 쓰고 있는데도 Claude Code가 NeonDB와 Fly.io로 마이그레이션하는 계획을 제안했다고 경험을 공유했다.
• shadcn/ui의 압도적 선택에 대한 의문이 많았다. Claude만 그런 게 아니라 Gemini도 동일한 경향을 보인다며, 방대한 문서량과 Stack Overflow 레퍼런스 때문인지, 의도적인 역링크 전략 때문인지, 아니면 초기 학습 데이터에서 너무 강하게 각인된 것인지 논쟁이 있었다. 실제로 LLM에게 다른 라이브러리를 쓰라고 하면 출력 품질이 떨어지는지 궁금해하는 댓글도 있었다.
• Opus 4.6이 '전향적'이라는 평가에 동의하는 실제 경험담이 공유됐다. 한 개발자는 Sonnet 4.5를 한 달 쓰다가 Opus 4.6으로 전환해 첫 그린필드 프로젝트를 시작했을 때, 계획 단계에서 자발적으로 웹 검색을 해서 최신 동향을 파악하는 모습을 처음 목격했다고 했다. 이전 모델에서는 본 적 없는 행동이었다고.
• GitHub Actions 선택 94%에 대한 강한 비판이 있었다. "이건 망조다"라는 표현까지 나왔는데, GitHub Actions는 다른 저장소에서 코드를 복붙하고 검증되지 않은 랜덤 저장소의 최신 코드를 가져다 실행하는 구조라 보안 위험이 크다는 지적이었다. CI/CD에서 AI가 사실상 독점 선택을 하는 게 업계 건전성에 나쁘다는 우려였다.
• 이 연구가 웹/JS 중심이라는 한계 지적도 있었다. C/C++, Rust, Go, 임베디드 등 다른 영역에서의 선택 패턴은 다를 수 있으며, 개발자가 명시적으로 사용할 도구를 지정하면 Claude가 거의 반박하지 않는다는 점에서 '가이드 없이 던졌을 때의 기본값 연구'로 이해해야 한다는 의견이 나왔다. Redux에 대한 아쉬움도 표출됐는데, 보일러플레이트가 많던 초기 이미지가 고착화돼 지금은 훨씬 나아졌음에도 불구하고 외면받는다는 의견이었다.

How to Apply

• 그린필드 프로젝트를 시작할 때 Claude Code에게 기술 스택을 자유롭게 맡기면 위의 'default stack'(Vercel, PostgreSQL, Drizzle, NextAuth.js, Stripe, Tailwind, shadcn/ui, Vitest, pnpm, GitHub Actions, Sentry, Resend, Zustand, React Hook Form)이 나올 가능성이 높다. 이를 알고 있으면 프로젝트 초반에 CLAUDE.md나 Memory.md에 원하는 스택을 명시해 의도치 않은 마이그레이션 제안을 방지할 수 있다.
• Opus 4.6으로 업그레이드하면 ORM이 Prisma에서 Drizzle로, 백그라운드 작업이 Celery에서 FastAPI BackgroundTasks로, 캐싱이 Redis에서 직접 구현으로 자동 전환된다. 기존 팀이 Prisma나 Celery에 익숙하다면 모델 업그레이드 전에 팀 합의가 필요하다.
• Python 백엔드 프로젝트에서 AWS를 계속 쓰고 싶다면 Memory.md나 시스템 프롬프트에 'AWS EC2 사용 중, 배포는 AWS 유지'를 명시해야 한다. 명시하지 않으면 Railway나 Fly.io로 마이그레이션하는 계획을 제안할 가능성이 높다.
• Claude Code가 Feature flag나 인증 같은 기능을 직접 구현하려 한다면 무조건 막지 말고 코드를 검토해볼 가치가 있다. 실제로 JWT + bcrypt 같은 구현은 10~20줄 수준으로 충분히 이해 가능하고, 외부 의존성을 줄인다는 장점이 있다. 단, 보안 중요 기능은 반드시 코드 리뷰를 거쳐야 한다.

Terminology

관련 논문

• Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구

  Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.

• Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험

  움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.

• GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교

  12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.

• Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과

  Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.

• Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구

  LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.

• LLM-as-a-Verifier: 범용 Verification 프레임워크

  LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.

Related Resources

• https://amplifying.ai/research/claude-code-picks
• https://youjustneedpostgres.com/