Tailwind CSS와 순수 CSS, 실무 웹개발 한 달 사용 후기

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

버튼 하나를 수정했는데 다른 페이지의 여백이 무너지고, 사용하지 않는 스타일 규칙은 계속 쌓이는 상황을 겪어본 적이 있나요? 저도 소규모 예약 서비스의 화면 12개를 만들면서 같은 문제를 반복했고, 결국 절반은 Tailwind CSS로, 나머지는 순수 CSS로 구현해 한 달 동안 유지보수 차이를 직접 기록했습니다.

두 방식은 문법만 다른 것이 아니었습니다. 코딩 속도와 파일 구조, 반응형 웹개발, 팀원이 코드를 읽는 방식까지 달라졌습니다. 참고로 코딩의 기본 개념은 네이버 지식백과의 코딩 설명에서도 확인할 수 있지만, 실무에서는 코드를 작성하는 행위보다 변경을 안전하게 관리하는 방식이 훨씬 큰 비중을 차지했습니다.

첫 주에는 Tailwind CSS가 압도적으로 빨랐다

디자인을 보며 바로 조립한 화면

처음 구현한 것은 로그인, 예약 목록, 상세 화면이었습니다. 순수 CSS에서는 클래스 이름을 정하고 스타일 파일을 오가며 속성을 추가했습니다. 반면 Tailwind CSS에서는 마크업 안에 간격, 색상, 정렬 유틸리티를 붙였기 때문에 브라우저와 편집기 사이에서만 작업할 수 있었습니다. 단순한 카드 화면 한 개를 완성하는 데 순수 CSS는 약 55분, Tailwind CSS는 약 34분이 걸렸습니다.

특히 간격과 반응형 레이아웃을 조정할 때 차이가 컸습니다. 작은 화면에서는 세로로 쌓고 넓은 화면에서는 두 열로 나누는 코드를 같은 요소에서 확인할 수 있어 수정 지점을 찾기 쉬웠습니다. 클래스 이름을 고민하다 흐름이 끊기는 일도 줄었습니다. 화면을 빠르게 시각화해야 하는 프로토타입이라면 이 장점은 꽤 강력합니다.

• 장점: HTML을 보면서 크기와 간격을 즉시 바꿀 수 있었습니다.
• 장점: 미리 정해진 단위가 있어 15px, 17px처럼 애매한 값이 늘어나는 일이 줄었습니다.
• 단점: 유틸리티 클래스에 익숙하지 않은 첫 이틀은 공식 문서를 자주 확인해야 했습니다.
• 단점: 조건부 클래스가 많아지면 한 줄이 길어져 구조를 한눈에 읽기 어려웠습니다.

순수 CSS가 더 편했던 작은 상호작용

모든 작업에서 Tailwind CSS가 빠른 것은 아니었습니다. 복잡한 가상 요소, 여러 단계로 이어지는 애니메이션, 특정 자식 요소를 정교하게 선택하는 코드는 순수 CSS가 더 자연스러웠습니다. 예약 완료 아이콘에 선이 그려지는 효과를 만들 때는 유틸리티를 억지로 조합하는 것보다 별도 클래스와 키프레임을 작성하는 편이 짧고 이해하기 쉬웠습니다.

빠르게 쓸 수 있다는 이유로 모든 스타일을 유틸리티에 넣을 필요는 없습니다. 반복되는 화면 배치는 Tailwind CSS로, 복잡한 동작은 별도 CSS로 두는 혼합 방식이 실제 작업에서 가장 편했습니다.

코드가 길어질수록 읽는 위치가 달라졌다

한 파일에서 확인하는 편리함과 피로감

Tailwind CSS로 작성한 버튼은 색상, 높이, 테두리, 포커스 상태가 마크업에 함께 드러났습니다. 다른 파일을 열지 않아도 모양을 예상할 수 있다는 점은 분명 편했습니다. 그러나 테이블 행처럼 조건에 따라 배경색과 정렬 방식이 달라지는 요소에서는 클래스 문자열이 지나치게 길어졌습니다. JSX 조건식까지 섞이자 기능 코드보다 스타일 코드가 먼저 눈에 들어왔습니다.

순수 CSS 버전은 마크업이 짧아서 데이터 흐름을 읽기 좋았습니다. 대신 reservation-row라는 이름만 보고는 실제 여백이나 색상을 알 수 없어 스타일 파일을 찾아야 했습니다. 또한 비슷한 클래스가 여러 파일에 존재하면 어떤 규칙이 최종 적용되는지 개발자 도구로 확인해야 했습니다. 프로그래밍이 명령과 절차를 구성하는 작업이라는 기본 맥락은 프로그래밍 용어 설명에서 살펴볼 수 있는데, CSS 역시 적용 순서와 범위를 설계하는 작업이라는 점을 체감했습니다.

1. 클래스 문자열이 길어지면 요소의 역할별로 줄을 나눠 읽었습니다.
2. 두 번 이상 반복되는 조합은 컴포넌트로 분리하되, 이름만 다른 불필요한 추상화는 만들지 않았습니다.
3. 조건부 스타일은 문자열을 직접 이어 붙이지 않고 프로젝트의 기존 클래스 결합 함수를 사용했습니다.
4. 복잡한 애니메이션과 인쇄용 스타일은 별도 CSS 파일로 이동했습니다.

팀원이 처음 코드를 읽었을 때

프론트엔드 경험이 있는 팀원은 Tailwind CSS 화면을 빠르게 수정했지만, 유틸리티 문법이 낯선 백엔드 개발자는 클래스 이름의 의미를 검색해야 했습니다. 순수 CSS는 속성 자체가 표준 문법이라 진입 장벽이 낮았지만, 프로젝트 고유의 파일 구조와 이름 규칙을 익히는 시간이 필요했습니다. 결국 어느 쪽이 더 읽기 쉬운지는 개인 취향보다 팀이 이미 공유하는 지식에 가까웠습니다.

저희는 자주 쓰는 여백, 색상, 반응형 접두어를 한 페이지 문서로 만들었습니다. 그 뒤 간단한 텍스트 크기 수정에 걸리는 시간이 평균 7분에서 3분 정도로 줄었습니다. 도구를 도입하는 것보다 팀 안에서 사용 범위를 합의하는 일이 먼저라는 사실을 보여준 변화였습니다.

유지보수에서는 일관성과 예외 처리가 승부를 갈랐다

디자인 변경을 두 방식에 적용해 본 결과

셋째 주에는 의도적으로 요구사항을 바꿨습니다. 기본 강조색을 교체하고, 카드 모서리와 모바일 여백을 한 단계 줄였습니다. Tailwind CSS 버전은 테마에 연결한 색상과 간격을 수정하자 공통 컴포넌트가 함께 바뀌었습니다. 임의의 색상값을 직접 넣었던 두 곳은 자동으로 바뀌지 않았기 때문에 검색으로 찾아 수정했습니다.

순수 CSS 버전도 CSS 사용자 지정 속성을 사용한 부분은 한 번에 변경됐습니다. 반대로 초기에 급하게 작성한 페이지에는 같은 색상이 서로 다른 표기 방식으로 남아 있었습니다. 이름 있는 색상 토큰, 16진수, RGB가 섞여 검색 한 번으로 모두 찾기 어려웠습니다. 이 경험에서 얻은 핵심은 프레임워크 자체보다 디자인 값을 변수로 관리했는지가 변경 비용을 결정한다는 점입니다.

• 색상: 브랜드색과 상태색은 의미가 드러나는 토큰으로 지정했습니다.
• 간격: 자주 쓰는 값의 범위를 제한하고 임의 값은 특별한 이유가 있을 때만 허용했습니다.
• 컴포넌트: 버튼 크기와 상태 조합을 공용 컴포넌트에서 관리했습니다.
• 예외: 캠페인 페이지처럼 수명이 짧은 화면은 공통 규칙을 과도하게 확장하지 않았습니다.
• 검증: 모바일, 태블릿, 데스크톱 너비에서 핵심 화면을 직접 확인했습니다.

제가 실제로 겪은 실패 패턴

Tailwind CSS에서는 반복을 없애겠다는 생각으로 작은 유틸리티 조합까지 별도 클래스로 추출했다가 오히려 추적이 어려워졌습니다. 클래스 이름을 클릭해도 다시 여러 유틸리티가 묶인 선언을 읽어야 했기 때문입니다. 반대로 순수 CSS에서는 선택자 중첩을 깊게 작성해 특정 페이지의 버튼만 수정하려다 다른 상태 스타일과 충돌했습니다.

이후에는 요소가 기능 단위로 반복될 때만 컴포넌트로 만들고, 단순히 클래스 문자열이 길다는 이유만으로 숨기지 않았습니다. 순수 CSS 선택자는 가능한 한 클래스 한두 개로 제한했습니다. 웹개발 초보자라면 코딩의 또 다른 개념 설명도 함께 읽어보면 문법 학습과 문제 해결 과정의 차이를 이해하는 데 도움이 됩니다.

CSS 문제가 생겼을 때 새 규칙을 덧붙이기 전에 계산된 스타일을 먼저 확인해 보세요. 우선순위 충돌인지, 상속인지, 잘못된 레이아웃 조건인지 구분하면 불필요한 덮어쓰기를 크게 줄일 수 있습니다.

일정 10일과 예산 0원 안에서 선택한 기준

프로젝트 조건별로 달라진 선택

한 달 사용 후 새 관리 화면에는 Tailwind CSS를 유지하고, 기존 서비스의 작은 기능 수정에는 순수 CSS를 사용하기로 했습니다. 새 프로젝트는 처음부터 토큰과 컴포넌트 규칙을 맞출 수 있지만, 오래된 프로젝트에 프레임워크를 추가하면 설정과 변환, 기존 스타일 충돌을 확인하는 시간이 발생하기 때문입니다. 도입 여부는 유행보다 남은 일정과 화면 수를 기준으로 판단하는 편이 현실적이었습니다.

예를 들어 화면이 2개뿐이고 운영 기간도 한 달이라면 기존 순수 CSS에 규칙 몇 개를 추가하는 편이 빨랐습니다. 반면 화면이 10개 이상이고 버튼과 입력창이 반복된다면 Tailwind CSS의 일관성이 시간을 아껴줬습니다. 여러분의 프로젝트에서 가장 자주 바뀌는 것은 색상인가요, 레이아웃인가요, 아니면 데이터 상태인가요? 그 답이 도구 선택의 기준이 됩니다.

• 신규 화면 10개 이상: 공통 설정을 잡는 데 2~4시간을 쓰고 Tailwind CSS로 반복 작업을 줄였습니다.
• 기존 페이지 1~3개 수정: 설치와 마이그레이션 없이 순수 CSS를 유지했습니다.
• 참여자 3명 이상: 시작 전에 클래스 작성 규칙을 60분 동안 함께 맞췄습니다.
• 애니메이션 비중이 큰 화면: 별도 CSS 작성 시간을 전체 일정의 약 15%로 확보했습니다.

제가 다시 시작한다면 잡을 시간표

실무 웹개발 일정이 10일이라면 첫날 2시간은 색상과 간격 토큰을 정하고, 3시간은 버튼·입력창·카드의 기본 컴포넌트를 만드는 데 사용하겠습니다. 둘째 날부터 일곱째 날까지 화면을 구현하고, 여덟째 날에는 모바일 너비 360px와 390px, 데스크톱 1440px에서 레이아웃을 확인합니다. 마지막 이틀은 접근성 상태, 긴 텍스트, 오류 메시지처럼 처음 구현할 때 빠뜨리기 쉬운 조건에 배정하는 편이 안전했습니다.

도구 사용료만 보면 두 방식 모두 무료로 시작할 수 있지만, 실제 비용은 학습과 검수 시간에서 발생했습니다. 제 기록에서는 Tailwind CSS 문법 적응에 약 5시간, 프로젝트 설정과 공통 규칙 작성에 3시간, 순수 CSS의 중복 규칙을 찾아 합치는 데 6시간이 들었습니다. 따라서 화면 5개 이하의 단기 작업은 순수 CSS가 부담이 적었고, 화면 10개 이상을 3개월 넘게 운영할 계획이라면 초기 8시간을 투자한 Tailwind CSS 쪽이 수정 시간을 더 안정적으로 줄여줬습니다.

1. 무료 도구라도 초기 학습 시간 4~6시간을 비용으로 계산합니다.
2. 화면 하나당 반응형 검수 시간을 최소 20~30분 확보합니다.
3. 공통 컴포넌트는 첫 주에 5~8개만 만들고 실제 반복이 생길 때 늘립니다.
4. 10일 일정이라면 기능 구현 7일, 스타일 검수와 예외 처리 3일로 나눕니다.