표준화되는 Tailwind CSS, Bootstrap의 위상은 진짜 꺾였는가

2026년 State of CSS에서 Tailwind CSS 사용률이 80%를 돌파했다. 그런데 Bootstrap은 아직도 npm 주간 다운로드 500만 회를 넘기고 있다. 진짜 이상한 구도다. 뉴스 제목만 보면 "Tailwind가 다 먹었다"고 하지만, 실제 프로덕션 현장에 가 보면 Bootstrap이 깔린 레거시가 여전히 넘쳐난다. 그래서 누가 이겼고 언제 무엇을 써야 하는지 2026년 4월 기준 최신 데이터로 정리했다. 감성 추천은 접어두고 숫자로만 본다.

 

Tailwind CSS가 표준이 된 이유 3가지

 

 

Tailwind CSS vs Bootstrap 구도에서 Tailwind가 지난 3년간 왜 폭발적으로 올라왔는지 분석해 보면, 단순히 "힙해서"가 아니라 구조적인 이유가 존재한다.

 

유틸리티 퍼스트가 결국 개발자의 뇌를 해킹한다

 

처음 Tailwind를 보면 반응은 거의 같다. "HTML에 클래스가 왜 이렇게 많은가", "더러워 보인다". 다만 한 달만 써 보면 돌아가기 싫어진다. CSS 파일을 왔다 갔다 하지 않아도 되기 때문이다. .card-title-primary 같은 네이밍 고민도 사라진다. BEM을 쓰다가 지친 개발자들이 Tailwind로 넘어가면서 "이게 맞다"는 결론에 이른 것이다.

 

State of CSS 2025 기준으로 Tailwind의 개발자 만족도(retention)는 82%다. Bootstrap은 같은 지표에서 48%까지 떨어졌다. 한 번 써 본 사람이 계속 쓰느냐는 질문에서 이 정도 차이라면 게임은 사실상 끝난 것이다.

 

JIT과 v4 Oxide 엔진으로 번들 사이즈 고민은 끝났다

 

예전에는 Tailwind 초기 버전을 쓰면 생성되는 CSS가 3MB를 넘겨서 프로덕션 전에 PurgeCSS를 돌려야 했다. 이 세팅이 까다로워 포기하는 사람도 많았다. 다만 2021년 JIT(Just-In-Time) 컴파일러가 나오면서 해결되었고, 2025년 1월 릴리즈된 Tailwind v4 Oxide 엔진은 빌드 속도가 10배 빨라졌다.

 

이제 실제 프로덕션 빌드로 나오는 CSS는 평균 10~30KB다. Bootstrap 5.3의 최소 빌드가 23KB 정도인데, Tailwind는 쓰지 않은 클래스를 모두 제거하기 때문에 오히려 더 가볍다. 번들 사이즈로 트집 잡던 시절은 끝났다.

 

shadcn/ui, Radix 에코시스템과의 궁합이 남다르다

 

이 부분이 진짜 결정타다. Tailwind 단독이 이긴 것이 아니라 "Tailwind + Headless UI" 조합이 이긴 것이다. shadcn/ui는 2023년 말부터 폭발했는데, 컴포넌트를 npm 패키지로 설치하는 방식이 아니라 소스 코드를 프로젝트에 복사하는 방식이다. 이 구조가 Radix UI의 접근성과 Tailwind 스타일링과 맞물리면서 "쓰면서 바로 커스터마이징이 가능한 컴포넌트"라는 신세계가 열렸다.

 

GitHub 스타 기준으로 shadcn/ui는 2024년 한 해에만 8만 개 이상의 스타를 받았다. 이 생태계 전체가 Tailwind에 올라타 있다. Bootstrap은 같은 레이어에서 견줄 만한 생태계가 아예 없다.

 

Bootstrap의 단점 중 진짜 치명적인 것

 

 

출처: it--crunch.blogspot.com

Bootstrap 단점 이야기를 꺼내면 보통 "디자인이 촌스럽다" 정도로 끝나는데, 진짜 치명적인 것은 따로 있다.

 

커스터마이징은 오히려 Tailwind보다 까다롭다

 

아이러니한 팩트다. Bootstrap은 "빨리 만들 수 있는 프레임워크"로 유명하지만, 디자인 커스터마이징에 들어가면 지옥이 시작된다. Sass 변수를 오버라이드하고, _variables.scss를 파고들고, !important 싸움을 해야 한다. 버튼 하나의 색상만 바꾸려 해도 레이어가 복잡하다.

 

Tailwind는 tailwind.config.js에서 토큰 한 줄만 바꾸면 끝이다. v4부터는 CSS-first 설정 방식으로 바뀌어서 @theme 블록에 CSS 변수만 넣으면 된다. 러닝 커브는 Tailwind가 높다고들 하지만, 커스터마이징을 깊게 들어가 보면 오히려 Bootstrap이 더 까다롭다.

 

디자인 동질화로 "부트스트랩 냄새"를 벗지 못한다

 

2014~2019년쯤 웹사이트 99%에서 Bootstrap 냄새가 났던 기억이 있는가? 파란색 primary 버튼, 둥근 모서리, 똑같은 breakpoint. 지금도 btn-primary 클래스 기본값을 그대로 쓴 사이트를 보면 티가 난다. 이를 벗어나려면 앞서 언급한 커스터마이징 지옥을 거쳐야 한다.

 

Tailwind는 유틸리티만 제공하기 때문에 디자인 시스템 자체가 없다. 개발자가 직접 조합해서 만들기 때문에 "Tailwind 냄새"는 존재하지 않는다. 동일한 이유로 배우기는 어렵지만, 결과물의 차별화 측면에서는 Tailwind의 압승이다.

 

jQuery 유산과 무거운 JS 컴포넌트

 

Bootstrap 5부터 jQuery를 뗐다고 공식 발표했지만, 실제 프로젝트에 가 보면 jQuery 의존성을 벗지 못한 곳이 많다. Bootstrap 3~4 시절의 코드가 아직도 살아 있기 때문이다. 그리고 Bootstrap JS 컴포넌트 자체가 모달·드롭다운·툴팁을 합치면 70KB가 넘는다. React/Vue를 쓰는 프로젝트에서는 이중 부담이 될 뿐이다.

 

Tailwind는 JS 컴포넌트 자체가 없다. 필요하다면 Headless UI, Radix, React Aria처럼 접근성이 좋은 라이브러리를 끼우면 된다. 구조적으로 가볍다.

 

그래도 Bootstrap이 아직 쓰이는 현장

 

 

출처: bootstrapdash.com

여기서 균형을 맞춰야 한다. "Bootstrap은 죽었다"는 말은 틀렸다. 아직도 쓰이는 곳이 분명히 있고, 그런 현장에서는 Bootstrap이 더 낫다.

 

사내 어드민·관리자 페이지에는 여전히 Bootstrap

 

B2B SaaS 어드민 페이지, 사내 도구, 내부 대시보드 같은 것을 만들 때는 Bootstrap이 체감상 3배 빠르다. 디자인 차별화가 필요 없고, 기본 컴포넌트를 바로 갖다 붙이면 되는 영역이다. 폼, 테이블, 모달, 페이지네이션이 모두 기본으로 제공된다.

 

Tailwind로 같은 것을 만들려면 shadcn/ui나 daisyUI 같은 것을 붙여야 하는데, 세팅 자체가 번거롭다. 비전공자나 주니어 개발자가 섞인 팀이라면 Bootstrap이 실용적이다.

 

빠른 프로토타입과 해커톤에서는 Bootstrap이 유리하다

 

48시간 해커톤에서 "예쁨"보다 "돌아감"이 중요한 경우, CDN 링크 하나를 박고 container, row, col-md-6를 치는 것이 가장 빠르다. Tailwind CDN도 존재하지만 클래스를 찾는 시간이 더 걸린다. "0에서 바로 동작"까지의 거리는 Bootstrap이 압도적으로 짧다.

 

비개발자 주도 프로젝트 (워드프레스, 룰베이스)

 

워드프레스 테마, Shopify 템플릿, 교육용 샘플 사이트에서는 Bootstrap이 여전히 기본값이다. 이유는 단순하다. 마케터나 디자이너가 직접 수정할 가능성이 있는 프로젝트에서 Tailwind의 유틸리티 퍼스트 접근은 러닝 커브가 너무 높다. Bootstrap 기본 클래스는 문서를 한 번 훑으면 이해되지만, Tailwind는 CSS를 알아야 제대로 쓸 수 있다.

 

숫자로 보는 점유율 변화

 

 

출처: Jiyeon Kang Design

감으로 말하면 끝이 없으니 숫자로 본다. 2026년 4월 기준 공개 데이터만 모았다.

 

npm 다운로드 추이 (2020~2026)

 

연도	Tailwind 주간 다운로드	Bootstrap 주간 다운로드
2020	約 60만	約 320만
2022	約 380만	約 450만
2024	約 1,100만	約 510만
2026 (4월)	約 1,850만	約 530만

 

Tailwind는 2024년 즈음에 Bootstrap 다운로드를 크로스오버했고, 지금은 3배 이상 앞서간다. Bootstrap도 절대 수치로는 줄지 않았다. 신규 프로젝트가 Tailwind로 몰릴 뿐, 기존 Bootstrap 프로젝트는 그대로 유지 중이라 다운로드 수가 버티고 있는 구조다.

 

State of CSS 2025 사용률 비교

 

• Tailwind CSS 사용률: 82% (전년 대비 +8%p)
• Bootstrap 사용률: 31% (전년 대비 -6%p)
• CSS Modules: 44%
• Sass/SCSS: 58%

 

여기서 주목할 점은 "사용률"과 "선호도"는 다르다는 사실이다. Bootstrap은 사용률이 31%인데 신규 채택률(retention)은 48%까지 떨어졌다. 이는 "이미 쓰고 있어서 쓴다"는 뜻이다. 반대로 Tailwind는 신규 채택률 82%로, 새 프로젝트의 압도적 다수가 Tailwind를 고르고 있다.

 

GitHub Stars, Stack Overflow 태그 트렌드

 

• Tailwind CSS GitHub Stars: 82K (2026년 4월 기준)
• Bootstrap GitHub Stars: 170K (누적치라 압도적)
• Stack Overflow [tailwind-css] 월간 질문 수: 약 1,800건
• Stack Overflow [bootstrap-5] 월간 질문 수: 약 950건

 

GitHub 스타는 누적치라 Bootstrap이 앞서지만, 신규 질문 수로 보면 Tailwind가 Bootstrap의 2배에 가깝다. 활발히 개발 중인 프로젝트 신호로 보면 이 지표가 훨씬 정확하다.

 

신규 프로젝트라면 무엇을 써야 하는가

 

이분법으로 답하고 싶지 않지만, 그래도 상황별로 정리한다. Tailwind CSS vs Bootstrap을 선택할 때 체크해야 할 포인트들이다.

 

Tailwind로 가야 하는 경우

 

• React / Vue / Svelte 같은 컴포넌트 프레임워크를 쓰는 프로젝트
• 디자인 시스템을 자체 구축하거나 Figma 디자인이 따로 있는 경우
• shadcn/ui, daisyUI, Flowbite 같은 에코시스템을 쓰고 싶은 경우
• 팀 전체가 프론트엔드 실력 중상급 이상
• 번들 사이즈에 민감한 B2C 서비스

 

Bootstrap이 여전히 나은 경우

 

• 디자인 차별화가 필요 없는 사내 어드민
• 워드프레스, Shopify, 오피스 포털 같은 템플릿 기반 사이트
• 비개발자가 수정할 가능성이 있는 프로젝트
• 24~72시간 안에 끝내야 하는 프로토타입
• 팀에 CSS에 익숙치 않은 백엔드 개발자 비율이 높은 경우

 

둘 다 안 쓰고 CSS 모듈만 쓰는 선택지

 

의외로 요즘 뜨는 세 번째 길이다. CSS Modules + PostCSS 조합이나 Vanilla Extract 같은 zero-runtime CSS-in-JS로 가는 팀도 늘어나고 있다. Next.js 프로젝트는 기본으로 CSS Modules를 제공하기 때문에 Tailwind 없이도 무리가 없다. "프레임워크 의존성을 싫어하는" 시니어 개발자들을 중심으로 이 선택지가 다시 부상하고 있다.

 

특히 디자인 시스템을 자체 구축한 회사(토스, 당근마켓 규모)는 Tailwind도 Bootstrap도 쓰지 않는다. 자체 토큰 시스템과 CSS Modules 조합이 더 깔끔하다.

 

레거시 Bootstrap 프로젝트 마이그레이션 현실

 

 

출처: linkedin.com

"Tailwind가 좋다는 것은 알겠는데, 지금 있는 Bootstrap 프로젝트는 어떻게 해야 하는가?" 이 질문이 실무에서 가장 많이 나온다.

 

실제 마이그레이션 공수 (페이지당 시간)

 

몇몇 중견 서비스 개발팀의 사례를 모아 보면 대략 이 정도다.

 

• 랜딩 페이지 1개 (정적 HTML): 2~4시간
• SaaS 대시보드 페이지 1개: 6~12시간
• 어드민 CRUD 페이지 1개: 4~8시간
• 컴포넌트 라이브러리 전체 재구축: 2~3개월

 

전체 마이그레이션 공수는 페이지 수 × 평균 6시간 + 초기 디자인 토큰 정의 2~3주로 계산하면 근접한다. 50페이지짜리 중간 규모 서비스라면 최소 2~4개월의 풀타임 공수가 필요하다.

 

점진적 전환 전략

 

한 번에 다 바꾸는 것은 사실상 자살 행위다. 실제로 성공한 팀들은 다음 순서로 진행한다.

 

1. Tailwind를 Bootstrap과 공존시킨다 (preflight: false 옵션으로 base reset 충돌 방지)
2. 새로 만드는 컴포넌트만 Tailwind로 작성한다
3. 기존 페이지는 손댈 일이 생길 때만 Tailwind로 리라이트한다
4. 6개월~1년이 지나면 자연스럽게 Tailwind 비율이 커진다
5. 마지막에 Bootstrap 의존성을 제거한다

 

preflight: false 팁이 핵심이다. Tailwind 기본 reset이 Bootstrap reset과 충돌하면 스타일이 모두 깨진다. 공존시키려면 이 옵션을 반드시 꺼야 한다.

 

마이그레이션하지 않는 편이 나은 케이스

 

냉정하게 말해서 마이그레이션 비용이 새로 만드는 것보다 비싼 경우가 많다. 아래 조건이라면 그냥 Bootstrap으로 유지하는 것이 낫다.

 

• 서비스가 유지보수 모드이고 신규 기능이 없음
• 트래픽이 낮은 어드민·내부 도구
• 팀에 프론트엔드 전담 인력이 1명 이하
• 디자인 리뉴얼 계획 없음

 

Tailwind 마이그레이션은 기술 부채 해결이 아니라 새로운 디자인 시스템 구축으로 봐야 한다. 그럴 의지가 없다면 기존 Bootstrap을 그대로 두는 것이 정답이다.

 

2026년 Tailwind CSS vs Bootstrap, 최종 판정 정리

 

3줄 요약으로 간다. Tailwind CSS vs Bootstrap의 2026년 현재 상황을 팩트로 정리하면 다음과 같다.

 

• Tailwind가 트렌드를 이긴 것은 팩트다. 신규 프로젝트 채택률, 개발자 만족도, 에코시스템 모두에서 압승이다. State of CSS 2025 기준 사용률 82%는 이미 "선택 가능한 옵션"이 아니라 "표준"이다.
• 다만 Bootstrap이 죽은 것은 아니다. 사내 어드민, 프로토타입, 비개발자 주도 프로젝트에서는 여전히 Bootstrap이 실용적이다. npm 주간 다운로드 500만 회라는 숫자는 허수가 아니다.
• 프로젝트 성격을 보고 골라야 한다. Tailwind가 무조건 정답이라는 주장도 틀렸고, "Bootstrap 아직 쓰세요?"라는 조롱도 무의미하다. 팀 구성·디자인 요구도·유지보수 기간을 따져서 적정한 선택을 내리는 것이 진짜 시니어다.

 

내 프로젝트에 무엇이 맞을지 체크하는 법은 단순하다. 신규 프로젝트 + 프론트엔드 팀 보유 + 디자인 차별화 필요 → Tailwind. 레거시 유지 + 어드민 중심 + 인력 부족 → Bootstrap. 둘 다 애매하다면 CSS Modules로 시작해 필요할 때 붙이면 된다. 2026년의 정답은 이것이다.