E-1: Tailwind CSS v4 — 이름 짓기를 그만두다

안녕하세요, 홍순구입니다. 지난 시간에 회원가입 폼을 끝냈죠. 규칙은 스키마 한곳에 모였고, 타입도 거기서 나왔습니다.

그런데 마무리하면서 제가 이런 말을 했어요. 폼은 완성됐는데 생긴 걸 한번 보자고요.

signup-form, signup-field, signup-label, signup-input, signup-error, profile-picker-button. 이 이름들 전부 우리가 손으로 지었습니다. 그리고 이름마다 CSS 를 또 손으로 썼죠.

지금 globals.css 를 열어보세요. 387 줄에 클래스 이름이 50 개, 규칙이 56 개 있습니다. 화면은 회원가입 폼 하나와 게시물 카드 두 장이 전부인데요.

오늘은 이름 짓기를 그만두는 방법을 봅니다. Tailwind CSS 입니다.

 오늘의 여정

 Step 1     이름 짓기가 왜 힘든가
    │
 Step 2     한 줄로 들이기
    │
 Step 3     Avatar 를 유틸리티로 옮기기
    │
 Step 4     안 쓴 CSS 는 어디로 갔나
    ▼
 클래스 이름을 짓지 않고 스타일이 붙은 Avatar

💡 오늘 수업의 핵심 — "이름을 짓지 않으면, 이름 때문에 생기는 문제도 없다"

우리가 겪은 불편은 대부분 CSS 자체가 아니라 이름에서 왔습니다. 겹치지 않게 짓느라, 어디 있는지 찾느라, 지워도 되는지 몰라서요. 오늘은 그 이름을 없앱니다.

🎯 학습 목표

• 손으로 이름 짓는 방식의 문제 세 가지를 짚고, 유틸리티 우선 방식이 그 대가로 무엇을 내주는지 말할 수 있다
• 플러그인 한 줄과 @import "tailwindcss" 한 줄로 v4 를 들이고, 함께 딸려 오는 리셋이 기존 화면에 무엇을 하는지 확인할 수 있다
• 손으로 쓴 CSS 규칙을 같은 값의 유틸리티로 옮기고, 옮긴 규칙을 지울 수 있다
• 빌드된 CSS 를 열어 무엇이 들어갔는지 확인하고, 안 쓰는 유틸리티가 왜 딸려 나오는지 설명할 수 있다

Step 1: "이름 짓기가 왜 힘든가"

먼저 지금 방식의 무엇이 문제인지 정확히 짚고 갑시다. "귀찮다" 로 뭉뚱그리면 Tailwind 가 뭘 해결하는지도 흐려지거든요.

선수 과목에서 순수 CSS 를 배울 때는 이 방식이 잘 통했습니다. 화면이 하나였으니까요. B-1 에서 첫 React 컴포넌트를 만들 때도 괜찮았어요. Avatar 하나에 .avatar, .avatar-image, .avatar-name 셋이면 충분했습니다.

문제는 화면이 늘면서 옵니다. 세 가지가 한꺼번에요.

하나 — 이름이 겹칩니다

.post-header 와 .feed-header 를 보세요. 둘 다 머리말인데 이름이 다릅니다. 왜 다를까요. 겹치면 안 되니까요.

그래서 우리는 접두사를 붙였습니다. post- 로 시작하는 클래스가 7 개, signup- 이 6 개, comment- 와 response- 가 각 5 개, feed- 와 profile- 이 각 4 개. 이런 식으로 접두사만 11 종류 입니다.

화면 세 개를 만드는 데 이름 앞에 붙일 말을 11 개나 정해야 했다는 뜻이에요.

이건 CSS 가 전역이라서 생기는 일입니다. 파일을 나눠도 소용없어요. 브라우저에 도착하면 결국 한 덩어리가 되거든요.

둘 — 어떤 스타일이 어디서 오는지 못 찾습니다

카드 안의 "좋아요 1240개" 가 왜 저 위치에 있는지 알고 싶다고 해봅시다.

LikeButton.tsx 를 열면 className="post-likes" 만 보입니다. 값은 없어요. 값을 보려면 globals.css 를 열고 .post-likes 를 찾아야 합니다. 그런데 .post-likes 는 .post-content, .post-comments 와 한 규칙에 묶여 있고, 그 아래에서 한 번 더 덮어써집니다.

찾기도 쉽지 않습니다. 이름만 보면 게시물 본문 어딘가에 있을 것 같은데 실제로는 좋아요 버튼 파일에 있거든요. 이름과 파일이 따로 노는 겁니다.

파일 두 개를 오가면서 규칙 두 개를 합쳐 읽어야 답이 나옵니다. 컴포넌트만 봐서는 절대 알 수 없어요.

셋 — 안 쓰는 CSS 를 지울 엄두가 안 납니다

이게 제일 큽니다. .key-demo-row 를 지워도 될까요?

지워도 되는지 확인하려면 프로젝트 전체에서 key-demo-row 를 검색해야 합니다. 검색해서 안 나와도 확신이 안 서요. 클래스 이름을 문자열로 조립하는 코드가 어딘가 있을 수도 있으니까요.

그래서 아무도 안 지웁니다. CSS 파일은 계속 늘어납니다. 여러분이 실무에서 만날 프로젝트의 CSS 가 몇천 줄인데 아무도 손 못 대는 이유가 이겁니다.

그래서 반대로 갑니다

Tailwind 의 발상은 간단합니다. 이름을 새로 짓지 말고, 이미 이름이 정해진 조각을 골라 쓰자.

p-3 은 padding 을 12px 로 만듭니다. 그게 전부예요. 다른 일은 안 합니다. flex 는 display: flex 만 겁니다. 이렇게 하는 일이 하나씩인 클래스를 유틸리티 클래스 라고 부릅니다.

 지금까지                               유틸리티 우선

 이름을 짓는다     .avatar              이미 있는 이름을 고른다   flex
      ↓                                      ↓
 CSS 를 쓴다       display: flex        고른 것을 붙인다          items-center
      ↓                                      ↓
 두 파일을 오간다                       컴포넌트 한 곳에서 끝난다

이러면 아까 세 문제가 어떻게 되는지 보세요.

이름을 안 지으니 겹칠 이름이 없습니다. 값이 클래스 이름에 그대로 있으니 컴포넌트만 봐도 압니다. 그리고 이게 결정적인데, 안 쓰는 CSS 를 지울 필요가 없습니다. 애초에 안 만들어지거든요. 왜 그런지는 Step 4 에서 직접 확인합니다.

⚠️ 대가도 있습니다

솔직하게 짚고 갈게요. 유틸리티를 쓰면 클래스 문자열이 길어집니다.

className="avatar" 였던 게 className="flex items-center gap-2.5 p-3" 이 됩니다. 처음 보면 지저분해 보여요. "HTML 에 스타일을 다시 집어넣는 거 아닌가" 싶기도 하고요.

이건 취향 문제가 아니라 실제 트레이드오프입니다. 짧은 이름 하나를 읽는 대신, 긴 문자열을 읽게 됩니다. 대신 그 문자열만 읽으면 다른 파일을 안 열어도 됩니다.

어느 쪽이 나은지는 프로젝트에 따라 다릅니다. 오늘 직접 해보고 스스로 판단해 보세요. 마지막에 이 얘기를 다시 꺼낼게요.

💡 한 줄 정리

손으로 이름을 지으면 겹침·추적·삭제 세 가지가 따라옵니다. 유틸리티 우선은 이름 짓기 자체를 없애서 셋을 한꺼번에 피하고, 대신 클래스 문자열이 길어지는 것을 받아들입니다.

Step 2: "한 줄로 들이기 — @import \"tailwindcss\""

이제 실제로 설치해 봅시다. v4 는 설치가 정말 짧아요.

설치

리포지토리 루트에서 실행합니다.

npm install -D --save-exact tailwindcss@4.3.3 @tailwindcss/vite@4.3.3 --workspace apps/web-spa

두 개를 받았습니다. tailwindcss 가 본체고, @tailwindcss/vite 는 Vite 에 물리는 플러그인이에요.

버전을 정확히 고정한 이유는 A-1 부터 이어온 규칙 그대로입니다. 스타일 도구는 마이너 버전에서도 만들어내는 CSS 가 조금씩 달라져서, 여러분 화면과 제 화면이 어긋나면 원인을 찾기 어렵거든요.

붙이는 곳은 두 군데

먼저 Vite 설정입니다.

// apps/web-spa/vite.config.ts
import { defineConfig } from 'vite';
import react, { reactCompilerPreset } from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';
import tailwindcss from '@tailwindcss/vite';

export default defineConfig({
  plugins: [
    react(),
    tailwindcss(),
    // React Compiler — 빌드할 때 자동으로 메모이제이션을 넣어준다
    await babel({
      presets: [reactCompilerPreset()],
    }),
  ],
});

임포트 한 줄과 tailwindcss() 한 줄이 전부입니다. B-1 에서 이 파일을 만들 때 넣어둔 React Compiler 설정은 그대로 두세요.

그다음 CSS 입니다.

/* apps/web-spa/src/styles/globals.css */
@import "tailwindcss";

/* 화면에 안 나가는 파일까지 훑지 않도록 미리 일러둔다 */
@source not "../../scratch";
@source not "../**/*.test.ts*";

body {
  margin: 0;
  background: #fafafa;
  color: #262626;
  font-family: system-ui, -apple-system, 'Apple SD Gothic Neo', sans-serif;
}

맨 위에 @import "tailwindcss"; 한 줄을 넣었습니다. 아래 손으로 쓴 CSS 는 아직 그대로 두세요. 오늘 한 번에 다 걷어내지 않습니다.

이게 v4 설치의 전부입니다. 설정 파일은 만들지 않습니다.

@source not 두 줄은 잠깐 설명이 필요합니다. Tailwind 는 프로젝트 폴더를 훑어서 쓸 클래스를 찾는데, 화면에 안 나가는 파일까지 함께 훑습니다. 그래서 그런 파일이 있으면 미리 제외해 둡니다.

두 줄이 가리키는 곳은 이렇습니다. 아래쪽은 테스트 파일이고, 위쪽 scratch 는 버려도 되는 실험용 코드를 따로 모아두는 폴더예요. 이름은 프로젝트마다 다르지만, 배포되지 않는 코드를 한곳에 모아두는 폴더는 대개 하나쯤 생깁니다.

지금 여러분 프로젝트에는 아직 그런 파일이 없습니다. 그래서 두 줄을 넣어도 당장은 아무것도 안 바뀌어요. 미리 넣어두는 건 F 카테고리에서 테스트 파일을 만들기 시작하는 순간부터 필요해지기 때문입니다.

왜 필요한지는 Step 4 에서 Tailwind 가 파일을 어떻게 훑는지 직접 확인하고 나면 분명해집니다. 지금은 두 줄을 넣어두기만 하세요.

v3 를 검색하면 다른 게 나옵니다

⚠️ 여기서 꼭 짚고 가야 할 게 있어요. 여러분이 Tailwind 를 검색하면 v3 예제가 압도적으로 많이 나옵니다. 블로그도, 스택오버플로 답변도, 강의 영상도요.

v3 는 이렇게 했습니다. CSS 맨 위에 @tailwind 로 시작하는 지시어를 세 줄 넣고, 프로젝트 루트에 tailwind.config.js 라는 설정 파일을 만들어서 거기에 색·간격·폰트를 자바스크립트 객체로 적었습니다. 그리고 어떤 파일을 훑을지 content 배열에 경로를 손으로 적어줬고요.

v4 에서는 셋 다 없어졌습니다. 지시어 세 줄은 @import 한 줄로 합쳐졌고, 설정 파일은 사라졌으며, 훑을 파일은 자동으로 찾습니다.

그러니 검색하다가 @tailwind 로 시작하는 세 줄이나 설정 파일이 보이면 v3 문서구나 하고 넘기세요. 우리 코드에 그대로 넣으면 동작하지 않습니다.

색이나 간격을 우리 브랜드에 맞게 바꾸는 건 v4 에서도 당연히 됩니다. 다만 자바스크립트 설정 파일이 아니라 CSS 안에서 해요. 그건 다음 시간에 정식으로 다룹니다.

설치는 두 경로가 있습니다

우리는 Vite 를 쓰니까 @tailwindcss/vite 플러그인을 썼습니다. 이게 가장 빠른 경로예요.

Vite 를 안 쓰는 프로젝트라면 PostCSS 경로를 씁니다. @tailwindcss/postcss 를 설치하고 PostCSS 설정에 등록하는 방식이에요. 나중에 Next.js 로 넘어가면 그쪽을 쓰게 됩니다.

어느 경로든 CSS 쪽은 똑같습니다. @import "tailwindcss"; 한 줄이에요.

그리고 autoprefixer 를 따로 설치하지 않았다는 점을 눈여겨보세요. v3 까지는 벤더 접두사를 붙여주는 도구를 따로 깔았는데, v4 는 내부 엔진이 그 일까지 합니다. 우리 package.json 에 autoprefixer 가 없는 이유예요.

화면을 확인해 봅시다

npm run dev --workspace apps/web-spa 로 띄우고 브라우저를 열어보세요.

대부분 그대로입니다. 카드도, 폼도, 버튼 색도요. 그런데 맨 위 제목을 보세요.

"인스타그램" 이 가늘어졌습니다.

착시가 아닙니다. 개발자 도구에서 제목을 선택하고 Computed 탭에서 font-weight 를 보면 400 입니다. 설치 전에는 700 이었어요.

왜 가늘어졌나

@import "tailwindcss" 는 유틸리티만 들여오는 게 아닙니다. 리셋(reset) 도 함께 들어옵니다. 브라우저마다 제각각인 기본 스타일을 하나로 맞추는 CSS 예요.

그 리셋에 이런 규칙이 있습니다. 제목 태그의 글자 굵기를 부모에게서 물려받게 하는 거요. 브라우저는 원래 h1 을 굵게 그리는데, 리셋이 그 기본값을 지웁니다.

우리 .feed-title 을 보세요.

/* apps/web-spa/src/styles/globals.css */
.feed-title {
  font-size: 24px;
  margin-bottom: 16px;
}

크기와 여백은 정했는데 굵기는 안 정했습니다. 지금까지는 정할 필요가 없었어요. 브라우저가 알아서 굵게 그려줬으니까요. 그 기본값이 사라지자 우리가 안 정해둔 게 그대로 드러난 겁니다.

이게 리셋의 양면입니다. 브라우저 차이를 없애주는 대신, 브라우저가 대신 해주던 것도 같이 없앱니다.

첫 유틸리티를 써봅시다

고치는 방법은 굵기를 직접 정해주는 거예요. 손으로 CSS 를 쓸 수도 있지만, 마침 좋은 기회니까 유틸리티로 해봅시다.

// apps/web-spa/src/App.tsx
<h1 className="feed-title font-bold">인스타그램</h1>

font-bold 하나 붙였습니다. 저장하면 제목이 다시 굵어져요. Computed 탭에서 font-weight 가 700 으로 돌아온 것도 확인해 보세요.

주목할 게 있습니다. 손으로 쓴 feed-title 과 유틸리티 font-bold 가 한 줄에 나란히 있습니다. 둘은 싸우지 않아요. 크기와 여백은 손 CSS 가, 굵기는 유틸리티가 맡습니다.

오늘 전부 갈아엎지 않아도 되는 이유가 이겁니다. 필요한 곳부터 하나씩 옮기면 됩니다.

💡 한 줄 정리

v4 설치는 플러그인 한 줄과 @import 한 줄이고 설정 파일은 없습니다. 다만 유틸리티와 함께 리셋이 딸려 오므로, 브라우저 기본값에 기대고 있던 스타일은 직접 정해줘야 합니다.

Step 3: "Avatar 를 유틸리티로"

이제 컴포넌트 하나를 통째로 옮겨봅시다. Avatar 로 시작할게요. B-1 에서 우리가 만든 첫 컴포넌트고, 규칙이 셋뿐이라 대조하기 좋습니다.

지금 모습

먼저 옮길 대상을 봅시다.

/* apps/web-spa/src/styles/globals.css */
.avatar {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 12px;
}

.avatar-image {
  width: 32px;
  height: 32px;
  border-radius: 50%;
  object-fit: cover;
}

.avatar-name {
  font-weight: 600;
  font-size: 14px;
}

규칙 셋에 선언이 아홉 개입니다. 이걸 유틸리티로 하나씩 바꿔볼 거예요.

하나씩 짝지어 봅시다

유틸리티 이름은 대부분 CSS 속성 이름에서 짐작이 됩니다.

숫자 규칙이 눈에 들어오시나요. p-3, gap-2.5, size-8 의 숫자는 4px 단위입니다. p-3 이면 3 × 4 = 12px 예요.

처음엔 이 환산이 번거롭습니다. 익숙해지면 오히려 편해져요. 디자인이 4px 격자 위에서 움직이게 되니까 간격이 제멋대로 튀지 않습니다. 손으로 쓸 때 11px, 13px 이 섞여 들어가는 걸 막아줘요.

옮긴 결과

// apps/web-spa/src/components/Avatar.tsx

interface AvatarProps {
  username: string;
  profileImageUrl: string;
}

export function Avatar({ username, profileImageUrl }: AvatarProps) {
  return (
    <div className="flex items-center gap-2.5 p-3">
      <img
        className="size-8 rounded-full object-cover"
        src={profileImageUrl}
        alt={`${username} 프로필 사진`}
      />
      <span className="text-sm font-semibold">{username}</span>
    </div>
  );
}

AvatarProps 는 손대지 않았습니다. src, alt 도 그대로고요. 바뀐 건 className 세 개뿐입니다.

이제 컴포넌트만 봐도 어떻게 생겼는지 압니다. 가로로 늘어놓고, 세로 가운데 정렬하고, 10px 띄우고, 12px 안쪽 여백. globals.css 를 안 열어도 돼요.

옮겼으면 지웁니다

여기가 중요합니다. 옮기고 끝내면 CSS 는 그대로 남아요. globals.css 에서 .avatar 세 규칙을 삭제하세요.

/* apps/web-spa/src/styles/globals.css */
/* .avatar, .avatar-image, .avatar-name 세 규칙을 지운다 */

지우기 전 392 줄이던 파일이 373 줄이 됩니다. 규칙 세 개에 그 사이 빈 줄까지 19 줄이 빠졌어요.

처음에 387 줄이라고 했는데 392 가 된 건 Step 2 에서 @import 와 @source not 줄들을 넣었기 때문입니다.

지울 때 마음이 편한 것도 느껴보세요. Step 1 에서 .key-demo-row 를 지울지 말지 망설였잖아요. 이번엔 안 망설입니다. 방금 내가 옮긴 것이고, 쓰던 곳은 Avatar.tsx 하나였다는 걸 아니까요.

정말 똑같이 나올까

옮겼으면 확인해야죠. 브라우저에서 프로필 사진 부분을 선택하고 Computed 탭을 열어보세요.

값이 그대로입니다. 화면도 당연히 그대로고요.

⚠️ 딱 하나 다른 게 있습니다. text-sm 은 글자 크기만 정하는 게 아니라 줄 간격(line-height)도 함께 20px 로 정합니다. 우리 손 CSS 는 줄 간격을 안 건드렸으니 원래는 브라우저 기본값이었어요.

한 줄짜리 이름이라 눈에 안 띄지만, "완전히 똑같다" 고 말하면 거짓입니다. 유틸리티 중에는 이렇게 한 번에 두 가지를 정하는 것이 있어요. text-sm, text-lg 같은 글자 크기 계열이 대표적입니다.

rounded-full 도 비슷합니다. 우리는 50% 를 썼는데 rounded-full 은 아주 큰 고정값을 넣습니다. 정사각형 이미지에서는 결과가 같지만, 직사각형이면 달라져요.

💡 한 줄 정리

CSS 규칙을 유틸리티로 옮기면 스타일이 컴포넌트 안으로 들어와 다른 파일을 안 열어도 됩니다. 옮긴 뒤에는 원래 규칙을 지우고, 값이 정말 같은지 Computed 탭으로 확인하세요.

Step 4: "안 쓴 CSS 는 어디로 갔나"

Step 1 에서 제가 이렇게 말했죠. 유틸리티는 안 쓰는 CSS 를 지울 필요가 없다고, 애초에 안 만들어진다고요. 이제 그걸 직접 확인합니다.

빌드해서 열어봅시다

npm run build --workspace apps/web-spa

dist/assets/ 에 CSS 파일이 하나 생깁니다. 이게 실제로 사용자에게 전달되는 CSS 예요.

먼저 크기부터 봅시다. 지금까지 세 시점을 재보면 이렇습니다.

두 번째 줄이 이상하지 않나요. 유틸리티를 하나도 안 썼는데 4,197 B 가 늘었습니다.

그게 Step 2 에서 만난 리셋입니다. 유틸리티가 아니라 리셋이 저 4 KB 의 대부분이에요. Tailwind 를 들이는 순간 내야 하는 고정 비용이라고 보면 됩니다.

이때 CSS 안에 Tailwind 가 만든 변수는 네 개뿐입니다. 글꼴 관련된 것들이고, 그마저도 리셋이 쓰기 때문에 들어간 거예요. 색·간격 같은 기본값이 통째로 쏟아지지 않는다는 뜻입니다.

세 번째 줄은 768 B 늘었습니다. 유틸리티 아홉 개와 제목의 font-bold 가 들어오고, 대신 .avatar 세 규칙이 빠진 결과예요. 더한 것과 뺀 것을 합친 순증입니다.

쓴 것만 들어있는지 확인

이제 진짜 확인입니다. CSS 안에 뭐가 있는지 직접 찾아봅시다.

grep -o "\.p-3[{,]" dist/assets/*.css | wc -l
grep -o "\.p-4[{,]" dist/assets/*.css | wc -l

p-3 은 Avatar 가 씁니다. p-4 는 아무도 안 써요.

결과는 1 과 0 입니다. 우리가 쓴 것만 들어있어요.

몇 개 더 해보세요. size-8, rounded-full, text-sm 은 전부 1 입니다. size-12, flex-col, items-start, bg-red-500 은 전부 0 이에요.

⚠️ gap-2.5 를 찾을 때는 주의하세요. CSS 에서는 클래스 이름의 점을 이스케이프해서 gap-2\.5 로 적습니다. 점을 그대로 넣고 검색하면 못 찾고, "없구나" 하고 잘못된 결론을 내리게 돼요.

설정한 적 없는데 어떻게 알았을까

우리는 어떤 파일을 훑으라고 적어준 적이 없습니다. 설정 파일 자체를 안 만들었으니까요.

v4 는 프로젝트를 자동으로 훑습니다. 소스 파일을 찾아 읽고, 거기서 발견한 클래스 이름만 CSS 로 만들어요. 이걸 자동 content 감지라고 합니다.

덕분에 Step 1 의 셋째 문제가 사라집니다. 안 쓰는 유틸리티를 지울 필요가 없어요. 안 쓰면 안 만들어지니까요. 그리고 Avatar 에서 p-3 을 지우면 다음 빌드에서 .p-3 규칙도 같이 사라집니다.

어떻게 찾는지 직접 확인해 봅시다

"쓴 것만 만든다" 는 말이 정확히 무슨 뜻인지 실험 하나로 확인할 수 있습니다.

Toast.tsx 를 열고 맨 아래에 주석 한 줄을 넣어보세요. 코드가 아니라 주석입니다.

// apps/web-spa/src/components/Toast.tsx
// p-4

그리고 다시 빌드해서 .p-4 를 세어 보세요.

grep -o "\.p-4[{,]" dist/assets/*.css | wc -l

방금까지 0 이던 것이 1 이 됩니다.

주석이잖아요. 자바스크립트는 저 줄을 아예 실행하지 않습니다. 그런데도 CSS 가 만들어졌어요.

자동 감지는 마법이 아닙니다

이유를 알면 허무합니다. Tailwind 는 파일을 그냥 글자로 훑습니다.

코드를 해석해서 "이건 클래스고 저건 주석이야" 를 가려내지 않아요. 유틸리티 이름과 똑같은 단어가 파일 어딘가에 있으면 그걸 클래스 후보로 봅니다.

 우리가 기대한 것                   실제로 하는 일

 컴포넌트를 해석해서                파일을 글자로 훑어서
 className 만 골라낸다              같은 단어를 전부 줍는다
      ↓                                  ↓
 쓴 것만 나온다                     쓴 것 + 우연히 겹친 단어

주석만 그런 게 아닙니다. 변수 이름이 container 이거나, 이벤트 이름 문자열이 'resize' 이거나, 객체 속성 이름이 ring 이어도 똑같이 걸립니다. 전부 실제 유틸리티 이름이거든요.

확인이 끝났으면 방금 넣은 주석은 지우세요.

그래서 Step 2 의 두 줄이 있었습니다

이제 설치할 때 넣어둔 @source not 두 줄이 왜 필요했는지 보입니다.

Tailwind 는 앱에 포함되는지를 따지지 않습니다. main.tsx 에서 불러오지 않는 파일이라도 폴더 안에 있으면 훑어요. "앱에 들어가는가" 와 "Tailwind 가 훑는가" 는 서로 다른 기준입니다.

방금 주석 한 줄로 확인했죠. 그렇다면 화면에 안 나가는 파일 안의 단어들도 똑같이 걸립니다.

실무 프로젝트에는 그런 파일이 늘 함께 있습니다. 테스트 파일, 목업 데이터, 문서, 실험용 코드 조각 같은 것들이요. 전부 사용자에게 전달되지 않는데도 Tailwind 는 훑습니다.

특히 테스트 파일이 그렇습니다. F 카테고리에서 우리도 만들게 될 텐데, 화면을 확인하는 코드라 container 처럼 유틸리티와 겹치는 이름을 자연스럽게 쓰게 되거든요. 방금 말한 변수 이름 사례가 바로 그것입니다.

/* apps/web-spa/src/styles/globals.css */
@source not "../../scratch";
@source not "../**/*.test.ts*";

경로는 이 CSS 파일 위치 기준 상대 경로입니다. Step 2 에서 넣어둔 두 줄이 이것이었어요.

⚠️ 지금은 제외할 파일이 없어서 두 줄을 지웠다 넣어도 CSS 크기가 그대로입니다. 효과를 눈으로 보는 건 F 카테고리에서 테스트 파일이 생긴 뒤예요. 오늘은 왜 그 장치가 필요한지까지만 이해하면 됩니다.

💡 한 줄 정리

v4 는 설정 없이 프로젝트를 훑어 쓴 유틸리티만 만들어냅니다. 다만 코드를 해석하는 게 아니라 글자로 훑기 때문에 이름이 겹치는 단어가 딸려 올 수 있고, 그럴 땐 @source not 으로 훑지 않을 곳을 알려줍니다.

// 이렇게 조립하면 Tailwind 가 못 찾는다
const color = liked ? 'red' : 'gray';
<button className={`text-${color}-500`}>♡</button>

// 완성된 이름이 파일에 있으니 찾을 수 있다
<button className={liked ? 'text-red-500' : 'text-gray-500'}>♡</button>

마무리

오늘 한 일을 한 줄로 줄이면 이렇습니다. 이름을 짓는 대신 골라 쓰기 시작했다.

Avatar 하나를 옮겼을 뿐인데 확인한 게 많았죠. 값이 그대로 나온다는 것, 옮긴 CSS 를 지워도 마음이 편하다는 것, 그리고 안 쓴 유틸리티는 애초에 만들어지지 않는다는 것까지요.

오늘 배운 핵심 세 가지

💡 하나 — 유틸리티 우선은 CSS 를 줄이는 기술이 아니라 이름을 없애는 기술입니다. 겹치지 않게 짓기, 어디 있는지 찾기, 지워도 되는지 판단하기. 이 셋은 전부 이름 때문에 생긴 일이었어요. 이름이 없으면 셋 다 없습니다.

💡 둘 — 리셋은 브라우저 차이를 없애는 대신 브라우저가 해주던 것도 없앱니다. 제목이 가늘어진 게 그 증거였죠. 값을 직접 정해둔 곳은 멀쩡했고, 기본값에 기대던 곳만 드러났습니다.

💡 셋 — 자동 감지는 코드를 해석하지 않고 글자로 훑습니다. 그래서 설정 없이도 동작하지만, 이름이 겹치는 단어가 딸려 오고 조립한 클래스 이름은 못 찾습니다. 편리함과 한계가 같은 뿌리에서 나와요.

시작할 때 내걸었던 것들

Step 1 에서 문제를 셋 꺼냈죠. 어디서 닫혔는지 봅시다.

다음 시간 예고

그런데 오늘 옮긴 Avatar 를 다시 보세요.

<span className="text-sm font-semibold">{username}</span>

text-sm 과 font-semibold 는 Tailwind 가 미리 정해둔 값입니다. 우리가 고른 게 아니라 주어진 걸 쓴 거예요.

그런데 우리 앱에는 우리만의 값이 있습니다. globals.css 를 보면 #0095f6 이라는 파란색이 버튼에 쓰이고, #ed4956 이라는 빨간색이 좋아요와 오류 메시지에 쓰입니다. #dbdbdb 테두리 색은 여러 규칙에 반복해서 적혀 있고요.

이 색들은 Tailwind 가 모릅니다. 그래서 지금은 유틸리티로 못 씁니다.

특히 #dbdbdb 는 11 번 반복해서 적혀 있어요. 테두리 색을 한 번 바꾸려면 11 곳을 고쳐야 한다는 뜻입니다.

다음 시간에는 우리 색과 간격을 Tailwind 에게 알려주는 방법을 봅니다. 알려주고 나면 bg-brand 같은 유틸리티가 저절로 생겨요. 우리가 만들지 않았는데도요.

그리고 오늘 못 한 게 하나 더 있습니다. 화면 크기에 따라 다르게 보이게 하는 것, 마우스를 올렸을 때 색이 바뀌는 것 말이에요. B-4 과제에서 창 너비를 재는 훅을 만들면서 "CSS 로 되는 일을 굳이 자바스크립트로 하지 말라" 고 했던 것 기억하시나요. 그 CSS 쪽 얘기를 다음 시간에 합니다.

오늘 옮긴 건 Avatar 하나뿐이니, 나머지 컴포넌트도 다음 시간에 마저 옮깁니다.

과제

[구현] 게시물 카드의 머리말을 유틸리티로

PostHeader 와 그 안의 더보기 버튼을 유틸리티로 옮기세요.

• globals.css 의 .post-header 와 .post-more 두 규칙이 대상입니다.
• Step 3 에서 한 순서를 그대로 따르세요. 값을 표로 짝지어 보고, 옮기고, 원래 규칙을 지우고, Computed 탭으로 확인합니다.
• .post-more 에는 line-height: 1 이 있습니다. 이 값에 맞는 유틸리티를 찾아보세요. Tailwind 공식 문서에서 line-height 를 검색하면 나옵니다.
• 옮긴 뒤 globals.css 가 몇 줄이 됐는지 적어 주세요.

다 하고 나면 npm run typecheck -w web-spa 와 npm run lint -w web-spa 를 돌려 둘 다 통과하는지 확인해 주세요.

[탐구] 훑기의 경계를 직접 건드려 보기

각 단계에서 무슨 일이 일어났는지 한두 줄씩 적어 주세요. 확인이 끝나면 전부 원래대로 되돌립니다.

• Avatar 에서 p-3 을 지우고 빌드한 뒤, CSS 에서 .p-3 을 찾아보세요. 몇 개가 나오나요? Step 1 의 셋째 문제와 이어서 설명해 보세요.
• Step 4 의 주석 실험을 변수 이름으로 바꿔서 해보세요. 아무 컴포넌트에 const container = 1; 을 넣고 빌드한 뒤 .container 를 세어 보세요. 몇 개가 나오나요? 주석 실험 때와 개수가 다르다면 왜 그럴지 생각해 보세요.
• 🙋 토글에서 본 조립 방식(`text-${color}-500`)을 LikeButton 에 실제로 넣고 빌드해 보세요. CSS 에서 .text-red-500 이 몇 개인가요? 그리고 빌드된 JS 에서 like-button text- 를 찾아보세요. 클래스는 붙는데 색은 안 먹는 상태를 두 곳에서 각각 확인하는 겁니다. 이런 실패가 왜 발견하기 어려운지 적어 주세요.
• 위 조립 방식을 완성된 이름으로 고친 뒤 다시 빌드해서 .text-red-500 을 세어 보세요. 이번엔 몇 개인가요?

생각해볼 주제

1. 긴 클래스 문자열은 정말 읽기 나쁜가

Step 1 에서 대가를 이야기했죠. className="avatar" 가 className="flex items-center gap-2.5 p-3" 이 됐습니다.

Tailwind 를 처음 본 사람들이 가장 많이 하는 반응이 이겁니다. "HTML 이 더러워진다", "이럴 거면 인라인 스타일이랑 뭐가 다르냐" 요.

그런데 오늘 실제로 옮겨보고 나서 생각이 좀 달라지셨을 수도 있습니다. 짧은 이름 하나를 읽고 다른 파일로 이동하는 것과, 긴 문자열 하나를 그 자리에서 읽는 것 중에 무엇이 더 빠를까요.

여러분의 판단은 어느 쪽인가요. 그리고 그 판단이 프로젝트 크기나 팀 인원에 따라 달라질지도 생각해 보세요.

2. 어디까지를 컴포넌트로 묶을 것인가

🙋 토글에서 같은 모양이 반복되면 클래스가 아니라 컴포넌트를 공유한다고 했습니다. B-3 에서 배운 방식이죠.

그런데 이 기준이 늘 선명하지는 않습니다. 카드 세 개가 비슷하지만 완전히 같지는 않다면요? 여백만 다르다면 컴포넌트를 나눠야 할까요, props 로 받아야 할까요, 아니면 그냥 유틸리티를 두 번 적는 게 나을까요.

B-3 에서 우리는 CommentItem 을 만들지 않기로 했습니다. 한 줄짜리라 자기 상태도 이벤트도 없었으니까요. 그때의 기준을 스타일에도 그대로 적용할 수 있을까요.

같은 유틸리티 문자열이 몇 번 반복되면 컴포넌트로 묶을지, 여러분만의 기준을 세워 보세요.

3. 편리한 자동화가 규칙을 만들 때

Step 4 에서 자동 감지의 두 얼굴을 봤습니다. 설정을 안 해도 되는 대신, 클래스 이름을 조립하면 안 된다는 규칙이 생겼어요.

이런 거래는 도구를 쓸 때 자주 만납니다. 뭔가를 알아서 해주는 도구는 대개 "이렇게 써야 알아볼 수 있다" 는 전제를 깔고 있거든요. 그 전제를 어기면 조용히 동작하지 않습니다. 오류도 안 나고요.

여러분이 이미 만난 것 중에도 비슷한 게 있습니다. A-6 에서 확인했듯 번들러는 타입을 검사하지 않아서 타입 오류가 있어도 빌드가 성공했죠. 그래서 우리는 타입 검사를 따로 돌리는 습관을 들였습니다.

이런 "조용한 실패" 를 팀이 놓치지 않으려면 무엇이 필요할까요. 문서에 적어두는 것으로 충분할까요, 아니면 다른 방법이 있을까요.