Tailwind CSS Preflight 기준: 기본 스타일 초기화가 생기는 이유

• Tailwind를 적용했는데 기본 스타일이 사라지는 이유
• Preflight는 CSS Reset인가, Normalize인가
• Preflight가 실제로 바꾸는 대표 기본값
• 작업할 때 Preflight를 어떻게 받아들여야 할까
• Preflight를 끄기 전에 생각할 기준
• 정리

Tailwind를 적용했는데 기본 스타일이 사라지는 이유

Tailwind CSS를 처음 적용하면 가장 먼저 어색하게 느껴지는 부분이 기본 태그 스타일입니다. 을 넣었는데 생각보다 크지 않고을 작성했는데 점이 보이지 않고, 문단 사이의 기본 여백도 사라진 것처럼 보입니다. CSS를 잘못 연결한 것처럼 보일 수 있지만, 대부분은 Tailwind의 Preflight가 정상적으로 적용된 결과입니다.

브라우저는 원래 각 태그에 기본 스타일을 가지고 있습니다. 은 크고 굵게 보이고에는 위아래 여백이 붙고에는 왼쪽 들여쓰기와 불릿이 들어갑니다. 이 기본값은 문서만 빠르게 작성할 때는 편하지만, 카드 UI나 관리자 화면처럼 정확한 간격이 필요한 화면에서는 예상하지 못한 여백을 만들기도 합니다.

Preflight는 이 기본값을 Tailwind 방식으로 다시 정리합니다. 브라우저가 정한 여백과 글자 크기에 기대지 말고같은 유틸리티 클래스로 화면 의도를 직접 적게 만드는 장치입니다.

예를 들어 관리자 화면의 페이지 제목을 만든다고 하면, Tailwind에서는 태그만으로 제목 스타일을 기대하지 않습니다. 태그는 문서 구조를 나타내고, 시각적인 크기와 굵기는 클래스로 명시합니다.

제목 태그만 넣었을 때와 클래스로 의도를 적었을 때

<h1>회원 관리</h1> <h1 class="text-2xl font-bold tracking-tight"> 회원 관리
</h1>

첫 번째 코드는 문서 구조상 제목이라는 의미만 남습니다. 두 번째 코드는 제목이라는 의미에 더해, 화면에서 어느 정도 크기와 무게로 보여야 하는지까지 같이 적습니다. Preflight를 이해할 때는 “태그의 의미”와 “화면의 모양”을 분리해서 보는 것이 출발점입니다.

Preflight는 CSS Reset인가, Normalize인가

Preflight는 CSS Reset과 비슷하게 보입니다. 기본 margin을 제거하고, heading을 초기화하고, list marker를 없애기 때문입니다. 하지만 목적은 단순히 모든 브라우저 기본값을 지우는 데서 끝나지 않습니다.

Tailwind CSS v4 기준으로 Preflight는 위에 Tailwind 프로젝트를 위한 기본 스타일을 더한 형태로 이해할 수 있습니다. 브라우저 간 차이를 줄이는 Normalize 계열의 역할도 있고, Tailwind 유틸리티 클래스가 예측 가능하게 작동하도록 기준선을 맞추는 Reset 계열의 역할도 같이 있습니다.

작업 방식에서 차이가 드러납니다. 일반 CSS Reset은 “브라우저 기본값을 지우고 다시 CSS를 작성하자”에 가깝습니다. Preflight는 한 걸음 더 나아가 “Tailwind의 spacing scale, border utility, typography utility를 기준으로 스타일을 명시하자”는 방향을 가집니다.

Tailwind v4에서 Preflight가 들어오는 흐름

@import "tailwindcss";

Tailwind v4에서는 기본 CSS 파일에서 를 작성하면 Tailwind의 theme, base, utilities 계층이 함께 들어옵니다. 이때 Preflight는 base layer에 포함됩니다. 그래서 별도로 reset.css를 넣지 않았는데도 기본 태그 스타일이 달라집니다.

이 구조를 모르고 있으면 스타일이 사라진 원인을 컴포넌트 코드나 브라우저 문제에서 찾게 됩니다. 실제 흐름은 전역 base style이 먼저 깔리고, 그 위에 유틸리티 클래스를 올리는 방식입니다.

Preflight가 실제로 바꾸는 대표 기본값

Preflight의 모든 규칙을 처음부터 외울 필요는 없습니다. 작업 중 자주 마주치는 변화부터 잡으면 됩니다. 특히 margin, heading, list, image, border 쪽은 화면에서 바로 드러나기 때문에 원인을 알고 있어야 수정이 빨라집니다.

기본 margin과 padding이 제거됩니다

브라우저 기본 스타일에서는 같은 요소에 기본 margin이 들어갑니다. Preflight는 이 기본 margin과 padding을 제거합니다. 그래서 Tailwind 프로젝트에서는 문단 사이 간격도, 제목 아래 여백도 직접 정해야 합니다.

<section class="space-y-4"> <h2 class="text-xl font-semibold">주문 내역</h2> <p class="text-sm text-gray-600"> 최근 주문 상태를 확인할 수 있습니다. </p>
</section>

여기서 문단 사이 간격은 나 의 기본 margin이 아니라 가 만듭니다. 이 방식은 처음에는 손이 더 가지만, 카드 UI나 관리자 화면처럼 반복되는 구조에서는 간격 기준을 맞추기 좋습니다.

heading은 기본 크기와 굵기를 갖지 않습니다

는 문서 구조상 중요한 태그입니다. 하지만 Preflight가 적용된 Tailwind 프로젝트에서는 브라우저 기본 제목 스타일에 기대지 않습니다. 그래서 이라고 해서 자동으로 크게 보이지 않습니다.

이 부분은 처음에 가장 많이 헷갈립니다. 태그 의미와 화면 모양을 분리하기 때문입니다. 제목 구조는 로 잡고, 시각적인 크기는 굵기는 간격은 로 잡습니다.

목록의 불릿과 숫자도 기본으로 보이지 않습니다

의 marker가 사라지는 것도 Preflight의 대표적인 변화입니다. 메뉴, 탭, 카드 리스트 같은 UI를 만들 때는 기본 불릿이 불필요한 경우가 많습니다. Tailwind는 기본 목록 스타일을 지우고, 필요한 곳에서만를 붙이도록 만듭니다.

<ul class="list-disc space-y-2 pl-5 text-sm text-gray-700"> <li>Preflight는 기본 목록 marker를 제거합니다.</li> <li>본문 목록에는 list-disc와 padding을 직접 지정합니다.</li> <li>메뉴 UI에서는 marker가 없는 상태가 더 자연스럽습니다.</li>
</ul>

같은 이라도 메뉴인지, 본문 목록인지에 따라 기준이 달라집니다. 메뉴라면 marker가 없는 상태가 맞고, 글 본문이라면 marker를 다시 살려야 읽기 흐름이 살아납니다.

이미지와 비디오는 부모 영역을 넘지 않도록 정리됩니다

Preflight는 이미지와 비디오가 부모 너비를 넘치지 않도록 기본값을 잡습니다. 일반적인 반응형 레이아웃에서는 이미지가 컨테이너 밖으로 튀어나가는 일이 줄어듭니다. 카드 썸네일, 상품 이미지, 프로필 이미지처럼 부모 박스 안에 들어가야 하는 요소에서는 이 기본값이 자연스럽게 맞아떨어집니다.

다만 원본 크기 그대로 보여야 하는 로고, 지도 타일, 외부 위젯 이미지에서는 이 기본값이 예상과 다를 수 있습니다. 이때는 전체 Preflight를 의심하기보다 해당 이미지에 같은 보정이 필요한지 먼저 확인합니다.

border 클래스가 예측 가능하게 작동하도록 초기화됩니다

Tailwind의 클래스는 기본적으로 border width를 지정하는 유틸리티입니다. Preflight는 모든 요소의 border style을 기준으로 정리해만 붙여도 실제 테두리가 보이도록 만듭니다.

<div class="rounded-xl border p-4"> <strong class="block text-sm font-semibold">알림</strong> <p class="mt-2 text-sm text-gray-600"> 결제 상태가 아직 확인되지 않았습니다. </p>
</div>

이 카드에서 가 바로 테두리로 보이는 이유는 Tailwind 유틸리티만의 문제가 아니라, Preflight가 전역 border 기준을 먼저 맞춰두기 때문입니다. 기존 CSS에서는 만 지정하고 을 빼면 테두리가 보이지 않는 상황을 만날 수 있는데, Tailwind는 이 출발점을 미리 정리해 둡니다.

작업할 때 Preflight를 어떻게 받아들여야 할까

Preflight를 불편하게 느끼는 지점은 대부분 “HTML 태그만으로 어느 정도 모양이 잡힐 것”이라고 기대할 때 생깁니다. Tailwind에서는 그 기대를 줄이고, 화면에 필요한 스타일을 클래스에 직접 남깁니다.

UI 컴포넌트를 만들 때는 이 방식이 잘 맞습니다. 버튼, 카드, 입력창, 탭, 모달처럼 반복되는 요소는 브라우저 기본값이 섞이면 오히려 수정하기 어렵습니다. 의 기본 배경, 의 기본 들여쓰기, 의 기본 margin이 컴포넌트마다 다르게 섞이면 디자인 기준이 흐려집니다.

반대로 블로그 본문, 약관, 공지사항 상세처럼 긴 글을 보여주는 영역에서는 Preflight가 너무 밋밋하게 느껴질 수 있습니다. 이때는 모든 태그에 일일이 클래스를 붙이는 것보다 콘텐츠 영역에만 별도 스타일을 주는 방식이 더 현실적입니다.

콘텐츠 영역은 별도 기준을 줄 수 있습니다

<article class="prose max-w-none"> <h1>서비스 이용 안내</h1> <p>아래 내용을 확인한 뒤 신청을 진행해 주세요.</p> <ul> <li>신청 후 관리자 확인이 필요합니다.</li> <li>수정 요청은 영업일 기준으로 처리됩니다.</li> </ul>
</article>

본문처럼 태그 자체의 읽기 흐름이 중요한 영역은 UI 컴포넌트와 분리해서 봐야 합니다. 를 쓰거나, 프로젝트에 맞는 같은 클래스를 만들어 heading, paragraph, list 스타일을 따로 정리할 수 있습니다.

중요한 건 Preflight 때문에 기본 스타일이 사라졌다고 해서 모든 곳에 같은 방식으로 스타일을 되돌리지 않는 것입니다. 메뉴 리스트와 본문 리스트는 목적이 다르고, 관리자 화면 제목과 블로그 글 제목도 다릅니다.

Preflight를 끄기 전에 생각할 기준

Preflight가 기존 CSS나 외부 라이브러리와 충돌하는 경우도 있습니다. 예를 들어 레거시 페이지 일부에만 Tailwind를 도입하거나, 지도·캘린더·웹 컴포넌트처럼 자체 스타일을 강하게 가진 도구를 붙일 때 예상과 다른 모양이 나올 수 있습니다.

그렇다고 바로 Preflight 전체를 끄는 것은 신중해야 합니다. Preflight를 끄면 Tailwind 유틸리티가 전제하던 기본 기준도 같이 달라집니다. 어떤 요소는 브라우저 기본 margin을 다시 갖게 되고, 어떤 요소는 Tailwind 예제와 다른 출발점에서 보일 수 있습니다.

먼저 확인할 기준은 세 가지입니다. 문제가 전체 프로젝트에서 반복되는지, 특정 외부 컴포넌트에서만 생기는지, 콘텐츠 영역처럼 기본 HTML 스타일이 필요한 곳에서만 생기는지입니다.

전체 비활성화보다 범위 보정이 먼저입니다

@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/utilities.css" layer(utilities);

Preflight를 제외해야 한다면 Tailwind의 theme와 utilities만 가져오는 방식으로 구성할 수 있습니다. 다만 이 선택은 새 프로젝트보다는 기존 CSS가 이미 강하게 잡힌 레거시 화면에 Tailwind를 부분 도입할 때 더 자주 검토합니다.

새로 만드는 Tailwind 중심 프로젝트라면 Preflight를 유지하고, 필요한 영역을 보정하는 흐름이 관리 측면에서 낫습니다. 예를 들어 본문 영역에는 typography 기준을 추가하고, 외부 위젯에는 해당 컴포넌트의 wrapper 안에서만 필요한 reset 보정을 넣는 식입니다.

@layer base { .content-body h1 { font-size: var(--text-3xl); font-weight: 700; } .content-body ul { list-style-type: disc; padding-left: 1.5rem; }
}

이런 보정은 Preflight를 되돌리는 작업이 아니라, 프로젝트 안에서 콘텐츠 영역의 성격을 따로 정의하는 작업에 가깝습니다. Tailwind로 UI를 만들 때와 HTML 문서를 읽기 좋게 보여줄 때의 기준을 나눠두면, 나중에 유지보수할 때 원인을 찾기 쉬워집니다.

정리

Preflight는 Tailwind가 기본 HTML 스타일을 망가뜨리는 기능이 아닙니다. 브라우저 기본 스타일에 기대던 부분을 걷어내고, 프로젝트의 클래스와 디자인 기준으로 다시 명시하게 만드는 base style입니다.

처음에는 이 작아 보이고, 의 점이 사라지고, 문단 여백이 없어져서 불편하게 느껴질 수 있습니다. 하지만 UI 컴포넌트를 만들 때는 이 초기화 덕분에 브라우저 기본값에 덜 흔들리는 구조를 만들 수 있습니다.

다음에 Tailwind 프로젝트에서 기본 태그 스타일이 예상과 다르게 보이면, 먼저 Preflight가 어떤 기준을 바꿨는지 확인하면 됩니다. 제목은 태그 의미와 시각 스타일을 분리해서 보고, 목록은 메뉴인지 본문인지 구분하고이미지는 부모 영역에 맞춰지는 기본값이 필요한지부터 살펴보면 수정 방향이 분명해집니다.