주말 사이드 프로젝트 웹개발, 순수 CSS vs Tailwind CSS

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

금요일 밤에 시작한 사이드 프로젝트를 일요일 안에 배포하려는데, 첫 화면부터 선택이 갈립니다. 익숙한 순수 CSS로 차분히 작성할지, 유틸리티 클래스를 조합하는 Tailwind CSS로 속도를 낼지에 따라 개발 흐름과 완성 후의 코드가 크게 달라집니다.

둘 중 하나가 무조건 우월한 것은 아닙니다. 제한된 시간, 화면 수, 디자인 변경 가능성, 참여 인원까지 따져야 실제로 유리한 선택지가 보입니다. 기본 개념이 헷갈린다면 코딩의 의미와 역할을 먼저 살펴보면 도구보다 문제 해결 과정이 중요하다는 점을 이해하는 데 도움이 됩니다.

첫 화면을 만드는 속도, Tailwind가 항상 앞설까

빈 프로젝트에서 시작할 때의 차이

Tailwind CSS는 여백, 색상, 글자 크기 같은 스타일을 HTML이나 JSX의 클래스에 바로 조합합니다. 설정이 끝난 프로젝트라면 flex, gap-4, rounded-lg처럼 필요한 속성을 찾아 붙이는 것만으로 카드와 버튼을 빠르게 만들 수 있습니다. 파일을 오가며 선택자 이름을 고민하는 시간이 줄어들어, 주말처럼 마감이 짧은 웹개발에서는 초반 속도가 특히 돋보입니다.

반대로 순수 CSS는 마크업을 작성한 뒤 클래스 이름을 정하고 별도 스타일시트에서 선언해야 합니다. 첫 화면만 보면 느려 보이지만, CSS 문법과 레이아웃 원리를 이미 잘 아는 개발자라면 설치와 설정 없이 곧바로 시작할 수 있습니다. Tailwind 클래스명을 문서에서 계속 검색해야 하는 입문자라면 오히려 순수 CSS가 더 빠를 수도 있습니다.

• Tailwind 우세: 설정된 템플릿이 있고, 비슷한 카드와 버튼을 여러 개 빠르게 조립할 때
• 순수 CSS 우세: 한두 화면뿐이며 별도 패키지 설치 없이 가벼운 결과물이 필요할 때
• 속도 역전 조건: 팀원이 유틸리티 클래스 규칙을 모르거나 복잡한 커스텀 디자인이 많을 때
• 공통 주의점: 도구 선택 전에 모바일·태블릿·데스크톱에서 필요한 화면 상태를 먼저 적어둘 것

첫 30분의 생산성만 비교하지 마세요. 마지막 두 시간 동안 수정 요청을 얼마나 빠르게 반영할 수 있는지가 주말 프로젝트의 진짜 개발 속도입니다.

HTML 가독성 대 스타일 추적성, 어디에 복잡성을 둘 것인가

짧은 클래스와 긴 클래스 목록의 대결

순수 CSS는 product-card나 signup-button처럼 역할이 드러나는 클래스명을 사용할 수 있어 마크업이 단정합니다. 하지만 화면을 보고 실제 색상이나 간격을 확인하려면 스타일시트에서 선택자를 찾아야 합니다. 선택자 중첩과 우선순위가 늘어나면 어떤 규칙이 적용됐는지 추적하는 데 예상보다 많은 시간이 듭니다.

Tailwind CSS는 한 요소에 클래스가 열 개 이상 붙기도 해 처음 읽을 때 복잡해 보입니다. 대신 해당 요소가 어떤 여백과 색상, 반응형 동작을 가졌는지 같은 위치에서 확인할 수 있습니다. 마크업의 시각적 간결함은 순수 CSS가, 스타일의 위치 추적은 Tailwind가 유리한 셈입니다. 프로그래밍의 기본적인 명령 구성은 프로그래밍 용어 설명에서도 확인할 수 있지만, 실무 가독성은 문법보다 팀이 공유한 규칙에 더 크게 좌우됩니다.

• 순수 CSS 장점: 콘텐츠 구조와 표현 규칙이 분리되어 HTML을 빠르게 훑기 좋습니다.
• 순수 CSS 약점: 전역 스타일, 상속, 명시도가 얽히면 수정 범위를 예측하기 어렵습니다.
• Tailwind 장점: 특정 요소의 스타일을 찾기 위해 여러 파일을 이동할 일이 적습니다.
• Tailwind 약점: 조건부 클래스까지 섞인 컴포넌트는 문자열이 길어져 핵심 로직을 가릴 수 있습니다.
• 현실적인 기준: 클래스가 반복되면 컴포넌트로 추출하고, 복잡한 문자열은 의미 있는 변수로 분리합니다.

코드 리뷰에서 확인할 포인트

리뷰어가 디자인 시스템에 익숙하다면 Tailwind의 클래스 나열도 빠르게 판독할 수 있습니다. 그렇지 않다면 왜 이 수치와 색상을 골랐는지가 드러나지 않아 리뷰가 단순한 오탈자 검사로 끝날 수 있습니다. 순수 CSS 역시 의미 없는 box1, box2 같은 이름을 쓰면 장점을 잃으므로, 결국 가독성은 도구보다 명명과 컴포넌트 경계에서 결정됩니다.

디자인 변경이 몰려올 때 재사용 방식이 갈린다

공통 버튼 열 개를 고쳐야 하는 상황

시연 두 시간 전에 주요 색상이 바뀌고 모든 버튼의 모서리를 더 둥글게 해달라는 요청이 왔다고 가정해 봅시다. 순수 CSS에서 공통 클래스와 CSS 사용자 지정 속성을 잘 만들어 두었다면 변수 한두 개만 수정하면 끝납니다. 반면 화면마다 색상 코드와 반지름을 따로 적었다면 관련 선택자를 전부 찾아야 하므로 설계 품질에 따른 격차가 크게 벌어집니다.

Tailwind 역시 설정의 디자인 토큰이나 CSS 변수에 색상을 연결했다면 일괄 변경이 쉽습니다. 그러나 모든 요소에 임의 값 클래스를 반복해서 적었다면 유틸리티 기반의 장점이 사라집니다. 예를 들어 rounded-[13px] 같은 값을 여러 곳에 복제하면 검색과 치환은 가능해도 의도한 요소만 안전하게 바뀐다는 보장이 없습니다. Tailwind는 재사용을 없애는 도구가 아니라 재사용의 단위를 CSS 선택자에서 컴포넌트로 이동시키는 도구에 가깝습니다.

1. 버튼, 입력창, 카드처럼 세 번 이상 등장하는 UI를 먼저 표시합니다.
2. 색상과 간격을 임의 숫자로 흩뿌리지 말고 작은 토큰 집합으로 제한합니다.
3. 순수 CSS라면 공통 클래스와 변형 클래스를 분리하고, Tailwind라면 공통 컴포넌트의 속성으로 변형을 표현합니다.
4. 모바일과 다크 모드까지 바꿔 본 뒤 한 요소의 수정이 다른 화면을 깨뜨리지 않는지 확인합니다.

재사용은 같은 코드를 무조건 한곳에 모으는 일이 아닙니다. 함께 바뀔 가능성이 높은 스타일을 같은 경계 안에 두는 것이 더 안전합니다.

작은 프로젝트에서 과도한 추상화 피하기

화면이 두 개뿐인데 거대한 디자인 시스템부터 만들면 실제 기능 개발 시간이 줄어듭니다. 반대로 복사한 버튼이 열 개를 넘어가는데도 “사이드 프로젝트니까 괜찮다”고 넘기면 마지막 수정에서 발목을 잡힙니다. 세 번째 반복이 나타나는 시점을 추출 후보로 삼되, 색상 하나만 다른 요소를 성급하게 별도 컴포넌트로 나누지는 않는 편이 좋습니다.

성능과 유지보수 비용은 빌드 이후에 드러난다

파일 크기보다 먼저 살펴볼 항목

Tailwind CSS는 실제 사용한 클래스 중심으로 결과 CSS를 생성하도록 구성할 수 있어, 개발 중 보이는 방대한 기능 전체가 그대로 배포되는 것은 아닙니다. 다만 빌드 도구의 콘텐츠 탐색 범위가 잘못되면 동적으로 만든 클래스가 결과물에서 누락될 수 있습니다. 색상명을 문자열로 조합하는 코드가 개발 서버에서는 보였지만 배포 후 사라지는 사례가 대표적입니다.

순수 CSS는 빌드 단계가 단순하고 결과를 직접 예측하기 쉽습니다. 대신 사용하지 않는 규칙이 쌓여도 자동으로 발견되지 않으며, 페이지가 늘수록 전역 스타일 충돌과 중복 선언이 증가할 수 있습니다. 실제 체감 성능은 CSS 파일 크기만으로 결정되지 않습니다. 폰트, 이미지, 자바스크립트 실행량과 렌더링을 막는 리소스가 더 큰 병목일 수 있으므로 개발자 도구의 네트워크 및 성능 패널로 함께 측정해야 합니다.

• Tailwind 점검: 프로덕션 빌드에서 조건부 클래스가 빠지지 않았는지 직접 페이지를 순회합니다.
• 순수 CSS 점검: 사용하지 않는 선택자와 지나치게 높은 명시도를 정기적으로 제거합니다.
• 양쪽 공통: 개발 서버가 아닌 배포용 빌드 결과의 CSS 용량을 비교합니다.
• 접근성 확인: 색상 대비, 키보드 초점, 확대 시 레이아웃을 도구 선택과 별개로 검사합니다.
• 유지보수 확인: 새 개발자가 버튼 변형 하나를 추가하는 데 필요한 파일 수와 시간을 기록합니다.

학습 비용도 프로젝트 비용이다

순수 CSS를 깊게 익히면 프레임워크가 바뀌어도 사용할 수 있는 레이아웃, 상속, 캐스케이드 지식이 남습니다. Tailwind를 사용하더라도 CSS 원리를 건너뛸 수는 없습니다. 왜 flex 항목이 줄어드는지, position의 기준이 무엇인지를 모르면 유틸리티 클래스를 바꿔 끼우는 시행착오만 늘어납니다. 코딩 학습의 여러 맥락은 코딩 관련 지식백과 항목도 참고할 만합니다.

이번 주말 프로젝트에서 20분 승부를 직접 내보자

같은 카드 UI를 두 방식으로 구현하기

선택을 오래 고민하는 대신 작은 실험으로 자신의 답을 얻을 수 있습니다. 프로젝트에서 가장 자주 등장할 카드 하나를 고르세요. 제목, 설명, 버튼, 모바일 반응형 상태가 포함된 정도면 충분합니다. 먼저 순수 CSS로 10분, 이어서 Tailwind CSS로 10분 동안 같은 화면을 만들고 단순히 완성 속도만 보지 말고 수정 과정까지 비교합니다.

두 구현이 끝나면 버튼 색상 변경, 카드 간격 확대, 모바일에서 세로 배치라는 세 가지 요청을 각각 적용해 보세요. 어느 쪽에서 실수가 적었는지, 수정 위치를 바로 찾았는지, 클래스나 선택자의 의도가 다시 읽어도 분명한지 기록하면 선택 기준이 선명해집니다. 혼자 개발한다면 개인 숙련도를, 팀 프로젝트라면 가장 경험이 적은 구성원의 이해 속도까지 반영해야 합니다.

1. 실제 프로젝트와 동일한 프레임워크 및 빌드 환경에서 카드 컴포넌트를 준비합니다.
2. 각 방식에 정확히 10분씩 사용하고 문서 검색 시간도 개발 시간에 포함합니다.
3. 완성된 카드에 색상·간격·반응형 변경 요청을 차례로 적용합니다.
4. 소요 시간, 검색 횟수, 깨진 화면 수를 세 줄로 기록합니다.
5. Tailwind가 확실히 빠르면 공통 토큰과 컴포넌트 규칙을 정한 뒤 채택하고, 차이가 작다면 의존성이 없는 순수 CSS로 시작합니다.

지금 당장 타이머를 20분으로 맞추고 가장 단순한 카드 하나를 두 번 만들어 보세요. 검색 결과에서 본 인기나 다른 개발자의 취향보다, 당신의 웹개발 환경에서 나온 시간과 오류 기록이 이번 사이드 프로젝트에 가장 정확한 선택 근거가 됩니다.