만능 컴포넌트는 오래 버티지 못한다
만능이 되려는 순간 시스템은 무거워진다
피그마에서 컴포넌트를 만들 때 가장 흔하게 생기는 착각은 하나의 컴포넌트가 최대한 많은 상황을 대응해야 한다는 생각이다. 버튼이면 버튼으로서 등장할 수 있는 모든 상태를 담아야 할 것 같고, 카드면 카드로서 나올 수 있는 모든 변형을 하나로 묶어두는 게 더 체계적인 관리처럼 느껴진다. 그래서 처음에는 단순했던 컴포넌트가 점점 살이 붙고, Variant는 하나씩 늘어나며, 어느 순간에는 이 컴포넌트 하나만으로 거의 모든 화면을 만들 수 있을 것 같은 상태가 된다. 겉으로 보면 효율적이고 정리된 구조처럼 보이지만, 실무에서는 이 지점부터 컴포넌트가 서서히 무거워지기 시작한다.
문제는 이 컴포넌트가 무엇을 책임지는지에 대한 기준이 흐려진다는 데 있다. 하나의 버튼 컴포넌트가 액션 실행, 상태 전환, 위험한 동작, 단순한 링크 역할까지 모두 담당하게 되면, 그 차이는 결국 형태로만 구분된다. 색이 다르고, 아이콘이 붙고, 텍스트 스타일이 달라지지만, 이 차이는 모두 Variant로 처리된다. 이때 컴포넌트는 더 이상 하나의 명확한 역할을 가진 도구가 아니라, 상황에 따라 의미가 바뀌는 덩어리가 된다. 디자이너는 Variant 목록을 보며 매번 고민하게 되고, 이 버튼이 지금 어떤 의미로 쓰이는지를 스스로 다시 해석해야 한다.
역할을 정확하게 책임진다는 것은 이와 반대의 선택이다. 이 컴포넌트는 무엇을 하기 위해 존재하는지, 어떤 맥락에서만 사용되는지, 그리고 어떤 상황에서는 절대 쓰이지 않는지를 먼저 정하는 것이다. 예를 들어 이 버튼은 사용자의 명시적인 행동을 실행하는 역할만 맡고, 상태 전환이나 경고성 액션은 다른 컴포넌트가 책임지도록 분리하는 식이다. 이렇게 역할의 경계를 먼저 긋기 시작하면, 자연스럽게 Variant는 줄어든다. 줄어든다는 것은 기능이 부족해진다는 뜻이 아니라, 책임이 명확해졌다는 뜻에 가깝다.
실무에서 이 차이는 아주 분명하게 드러난다. 역할이 명확한 컴포넌트는 사용하는 사람이 고민하지 않는다. 이 상황에서는 이 컴포넌트를 쓰는 게 맞다는 판단이 거의 자동으로 이루어진다. 반대로 만능 컴포넌트는 늘 선택의 부담을 만든다. 이 Variant가 맞는지, 저 Variant가 더 적절한지, 혹시 다른 속성을 켜야 하는지 같은 질문들이 계속 따라붙는다. 컴포넌트가 많아서 헷갈리는 게 아니라, 하나의 컴포넌트가 너무 많은 의미를 품고 있어서 헷갈리는 상태다.
이 문제는 디자인 파일 안에서만 끝나지 않는다. 개발 단계로 넘어가면 더 선명해진다. 역할이 명확한 컴포넌트는 코드에서도 대응하기 쉽다. 어떤 상황에서 호출되는지, 어떤 상태를 가지는지, 어디까지를 책임지는지가 분명하기 때문이다. 반면 역할이 섞인 컴포넌트는 코드에서 조건문을 늘린다. 디자인에서는 Variant로 깔끔하게 보이던 분기가, 코드에서는 여러 if와 예외 처리로 풀어지고, 그 과정에서 일부 상태는 생략되거나 다르게 구현된다. 결국 디자인과 구현 사이의 간극은 컴포넌트의 기술적 복잡성보다 역할 정의의 부재에서 생긴다.
그래서 경험이 쌓일수록 컴포넌트를 만드는 기준도 바뀐다. 얼마나 많은 Variant를 만들 수 있는지가 아니라, 이 컴포넌트가 하지 않아도 되는 일이 무엇인지를 먼저 생각하게 된다. 이 컴포넌트는 여기까지만 책임지고, 그 너머는 다른 컴포넌트나 다른 레이어의 문제로 남겨두는 선택이다. 이 선택은 처음에는 불편해 보일 수 있다. 컴포넌트가 늘어나는 것 같고, 관리 대상이 많아지는 느낌도 든다. 하지만 시간이 지나면 오히려 구조는 더 단순해진다. 각 컴포넌트가 맡은 역할이 분명하기 때문에, 전체 시스템을 이해하는 데 필요한 사고량이 줄어든다.
역할을 정확하게 책임진다는 말은 결국 컴포넌트를 API처럼 대한다는 뜻과도 닿아 있다. 이 컴포넌트는 어떤 입력을 받고, 어떤 결과를 만들어내며, 어떤 경우에는 사용되지 않는지를 명확히 아는 상태다. 이렇게 설계된 컴포넌트는 오래 살아남고, 새로운 화면이나 기능이 추가되어도 쉽게 무너지지 않는다. 반대로 모든 경우를 커버하려는 컴포넌트는 처음에는 유연해 보이지만, 시간이 지날수록 변화에 가장 취약한 존재가 된다.
피그마에서 만능 컴포넌트를 만들 수 있는 능력은 분명 기술적으로는 가능하다. 하지만 실무에서 중요한 것은 가능함이 아니라 적절함이다. 모든 경우를 대응하는 컴포넌트보다, 자기 역할을 정확하게 알고 그 범위 안에서만 잘 작동하는 컴포넌트가 팀의 속도를 지켜준다. 그리고 그 판단은 테크닉의 문제가 아니라 설계의 문제다. 컴포넌트를 어떻게 나눌 것인가는 결국 화면을 어떻게 이해하고 있는지에 대한 디자이너의 사고를 그대로 드러낸다.
그래서 요즘은 컴포넌트를 만들 때 스스로에게 이런 질문을 먼저 던진다. 이 컴포넌트는 무엇을 책임지는가, 그리고 무엇을 책임지지 않는가. 이 질문에 명확하게 답할 수 있을 때, Variant는 자연스럽게 줄어들고, 구조는 생각보다 훨씬 가벼워진다. 피그마를 잘 다룬다는 것은 모든 기능을 활용하는 것이 아니라, 책임의 경계를 정확하게 긋는 일에 더 가깝다는 생각을 요즘은 자주 하게 된다.
