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

관련 논문

• LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크

  LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.

• Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법

  Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.

• ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?

  LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.

• MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정

  티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.

• LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다

  13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.

• LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개

  스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.

Related Resources

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