Styled-components VS Tailwind

회사내에서 Styled-components로 구성된 작업물이 있어 코드를 살펴보니..흠...이거 굉장히 귀찮은데라는 생각이 들었음..

테일윈드에 벌써 익숙해져 그렇게 느꼇을지도 모른다.

인수인계문서에 styled-components를 채택한 이유가 적혀있지 않았고 이전 담당자도 정확히 모르는 것 같았다

 

과연 이 프로젝트에서 어떤 장점이 있길래 사용하게 됐는지 알아보려고 한다. 

 

 

작년을 기점으로 테일윈드의 점유율이 더욱더 많아지고 있다.

styled-components의 경우 사용하는 사람만 계속 사용하는 느낌...줄지도 늘지도 않는

 

우선 styled-components는 css-in-js로 자바스크립트 안에서 css를 작성하게된다. 

그럼 css-in-js의 장점인 유지보수, 컴포넌트와, 재사용성이 높아지는 점등이 따라 오게된다. 

프로젝트를 보니 디자인 라이브러리는 사용하지않고 다 만들었기에 해당 라이브러리를 사용한 것으로 추측된다.

상태관리에 따른 디자인 변경도 많지 않았기에 사실 정말 왜 사용했는지 모르겠다..!!!!!

 

물론 테일윈드가 동적스타일링이 안된다는 불편함이 있긴하지만 그건

인라인 스타일태그로 해결하는 되는 부분인 거 같긴한대..

테일윈드가 아무래도 초반에는 러닝커브가 다소 있다보니  아마 익숙해서 사용한게 아닐가 싶기도하다 

---

Styled-component 언제 사용하면 좋을까?

• 컴포넌트 중심의 디자인 시스템을 쓰는 경우
• 조건부 스타일링, 테마 적용, 상태 기반 UI를 많이 다루는 경우
• 복잡한 스타일 상태 로직을 하나의 파일에서 관리하고 싶은 경우
• 또는 대규모 팀 프로젝트에서 스타일 네이밍 규칙 없이 빠르게 협업해야 할 경우

---

모든 회사의 스타일 라이브러리를 파악 할 수는 없지만 프론트엔드 정보 공유 채팅방도 그렇고 테일윈드가 아무래도 제일 많이 사용되는 거 같다. 토스는 물론 emotion이지만! 컴포넌트 기반의 서비스인 거 같아 당연히 이해가 된다.

 

러닝 커브 측면에서 보면, styled-components는 CSS 문법과 유사하기 때문에 템플릿 리터럴 문법만 익숙해지면 진입 장벽이 크지 않다고 생각한다.

반면, Tailwind CSS는 유틸리티 클래스 기반 방식이라 처음에는 어떤 클래스명을 사용해야 할지 매번 확인하며 작업하게 되어 상대적으로 러닝 커브가 높게 느껴질 수 있다.

 

하지만 최근에는 Copilot이나 Cursor처럼 자동완성 도구를 함께 사용하는 경우가 많고, 필요한 클래스명을 바로 검색해서 적용하는 데 익숙해져 있기 때문에, 이 부분은 충분히 상호보완 가능하다고 본다.

 

인라인 클래스가 물론 지저분하긴 하지만 익숙해진 탓일까 이제 지저분하진 않은 상태까지 온 것 같다 ㅋㅋㅋㅋ