Showing Posts From

만들어둘게요

컴포넌트로 만들어둘게요, 를 반복하는 6년차의 미래

컴포넌트로 만들어둘게요, 를 반복하는 6년차의 미래

컴포넌트로 만들어둘게요 "이거 컴포넌트로 만들어둘게요." 입에 붙었다. 회의 때마다 나오는 말. 버튼 하나 디자인해도, 카드 레이아웃 잡아도, 입력 폼 만들어도. 컴포넌트. 6년 차가 되니까 모든 게 컴포넌트로 보인다. 신입 때는 몰랐다. 예쁘게만 만들면 되는 줄 알았다. 페이지마다 새로 그렸다. 버튼 색깔이 조금씩 달라도 신경 안 썼다. #3B82F6이랑 #3B83F6이 뭐가 다르냐고. 지금은 안다. 다르다. 엄청 다르다. 컴포넌트 없이 프로젝트 진행하면 어떻게 되는지. 3개월 뒤에 수정 요청 오면 어떻게 되는지. 30개 페이지에 흩어진 버튼을 하나하나 고치면 어떻게 되는지. 지옥이다. 그래서 만든다. 컴포넌트를.처음엔 재미있었다 시스템을 만드는 게 재미있었다. 디자인 시스템 구축 프로젝트. 3년 차 때였다. 팀장이 말했다. "최디자님, 이번에 디자인 시스템 제대로 만들어봅시다." 드디어. 버튼부터 시작했다. Primary, Secondary, Tertiary, Ghost. State는 Default, Hover, Active, Disabled. Size는 Small, Medium, Large. Icon 들어가는 버전, 안 들어가는 버전. 경우의 수를 다 만들었다. 48개 variant. 아름다웠다. Input field도 만들었다. Label, Placeholder, Helper text, Error message. 전부 프로퍼티로 조절 가능하게. 카드 컴포넌트도. 이미지 있는 버전, 없는 버전. CTA 버튼 1개, 2개. 태그 최대 3개까지. 완벽했다. 문서도 썼다. 사용 가이드. 언제 어떤 버튼을 쓰는지. 컬러 토큰 정리. Spacing 규칙. Typography scale. Notion에 20페이지. 뿌듯했다. "이제 모두가 이걸 쓰면 돼. 일관성도 생기고 작업도 빨라질 거야." 순진했다.그리고 현실이 왔다 기획자가 물었다. "이 버튼이요, 조금만 더 크게 할 수 없을까요? 사용자가 더 잘 보게." "Medium과 Large 사이 크기요?" "네, 딱 그 중간이요." 심호흡. "시스템에 정의된 사이즈를 쓰는 게..." "아, 그럼 이 페이지만 예외로 할게요." 예외. 이 단어가 시작이었다. 마케팅팀이 요청했다. "이벤트 페이지인데요, 좀 특별하게 만들고 싶어요. 시스템 컴포넌트 말고 새로 디자인해주세요." "컴포넌트 변형해서 쓰면..." "아니요, 완전히 새로운 느낌이 필요해요. 이건 특별한 프로젝트니까." 모든 프로젝트가 특별하다더라. 개발자가 말했다. "이 컴포넌트요, 구현하기 좀 복잡한데요. 이렇게까지 세분화해야 하나요?" "재사용성 때문에..." "근데 실제로 다 쓰이나요? 지금까지 3개 variant만 썼는데." 할 말이 없었다. 48개 중에 3개.효율성의 역설 컴포넌트는 효율을 위해 만든다. 한 번 만들어두면 계속 쓸 수 있으니까. 수정도 한 번에 반영되니까. 일관성도 유지되니까. 이론상으로는. 실제로는 다르다. 컴포넌트 만드는 데 시간이 든다. 모든 경우의 수를 고려해야 한다. 확장 가능하게 설계해야 한다. 문서도 써야 한다. 그냥 디자인하는 것보다 3배는 오래 걸린다. "지금은 시간이 좀 걸려도, 나중에 효율적이니까." 그렇게 믿었다. 근데 나중이 온다. 프로젝트 방향이 바뀐다. 요구사항이 달라진다. 예외 케이스가 생긴다. 컴포넌트를 수정한다. 기존 사용처에 영향이 간다. 또 수정한다. 또 영향이 간다. 컴포넌트가 컴포넌트를 부른다. 버튼 수정하면 카드 깨진다. 카드 수정하면 리스트 깨진다. 리스트 수정하면 페이지 깨진다. 연쇄작용. "detach instance"를 누르는 순간의 죄책감. 시스템을 배신하는 기분. 하지만 어쩔 수 없다. 일정은 내일까지고 이 페이지만 예외니까. 그렇게 예외가 쌓인다. 효율을 위해 만든 시스템이 비효율을 만든다. 유연성이라는 함정 그래서 배웠다. 유연하게 만들어야 한다고. 모든 케이스에 대응 가능하게. 프로퍼티 많이 열어두고. 옵션 다양하게. 버튼 하나에 프로퍼티 12개.Size (4종) Variant (5종) State (4종) Icon position (3종) Full width (Boolean) Loading (Boolean)완벽하다. 이제 어떤 요청이 와도 대응 가능하다. 근데. 너무 복잡해졌다. 신입 디자이너가 물었다. "이 버튼 어떻게 쓰는 거예요?" 설명하는 데 10분. "아... 그냥 새로 만들까요?" 아니. 그러면 안 되는데. 유연성을 높이면 복잡도가 올라간다. 복잡도가 올라가면 사용성이 떨어진다. 사용성이 떨어지면 아무도 안 쓴다. 안 쓰이는 컴포넌트. 공들여 만든 시스템. Figma 파일 구석에서 먼지 쌓인다. 그리고 모두가 새로 만든다. 각자의 방식으로. 일관성은 다시 무너진다. 원점이다. 80%의 법칙 5년 차쯤 깨달았다. 100% 완벽한 컴포넌트는 없다. 모든 케이스를 커버하는 시스템은 없다. 80%면 된다. 80%의 경우에 잘 작동하면. 나머지 20%는 예외로 두면. 그게 현실이다. Primary 버튼 하나. 잘 만들어둔다. 대부분의 경우에 쓸 수 있게. 특별한 이벤트 페이지? 그건 detach 해서 쓴다. 괜찮다. C레벨이 "이 페이지만 특별하게"라고 하면? 시스템 무시하고 만든다. 어차피 일회성이니까. 완벽주의를 내려놓았다. 시스템은 가이드라인이다. 법이 아니다. 컴포넌트는 도구다. 목적이 아니다. 일관성은 중요하다. 하지만 절대적이지 않다. 이걸 받아들이니까 편해졌다. "이거 컴포넌트 안 쓰고 해도 돼요?" "네, 괜찮아요. 특수한 케이스니까." 죄책감 없이 말할 수 있다. 핵심만 지킨다 지금은 핵심만 컴포넌트로 만든다. 정말 반복적으로 쓰이는 것. 정말 일관성이 필요한 것. 버튼. Input. 카드. 모달. 네비게이션. 이 정도. 나머지는 페이지별로 자유롭게. 컬러 토큰은 확실히 지킨다. Primary, Secondary, Background, Text. 8개 정도. Typography도. Heading 3개, Body 2개, Caption 1개. Spacing은 4px 기준. 8, 16, 24, 32, 48. 이 정도면 일관성은 유지된다. 세부적인 컴포넌트는? 필요할 때 만든다. "나중을 위해" 미리 만들지 않는다. 나중은 안 온다. 다른 나중이 온다. YAGNI. You Aren't Gonna Need It. 개발 원칙인데 디자인에도 적용된다. 지금 필요한 것만 만든다. 효율적이다. 문서는 짧게 디자인 시스템 문서. 3년 차 때는 20페이지 썼다. 아무도 안 읽었다. 지금은 3페이지. 컬러, 타이포, Spacing. 스크린샷 몇 개. 끝. "자세한 건 Figma 파일 보세요." 컴포넌트 자체가 문서다. 잘 만들어두면 설명 필요 없다. 프로퍼티 이름만 잘 지으면 된다. "showIcon" 말고 "hasIcon". "isLarge" 말고 "size=large". 직관적이면 문서 필요 없다. 업데이트도 쉽다. 20페이지 문서 유지보수? 불가능하다. 일주일 지나면 구버전 된다. 3페이지? 한 달에 한 번 10분이면 업데이트 끝. 지속 가능하다. 완벽한 문서보다 유지되는 문서가 낫다. 개발자와의 간극 디자인 컴포넌트랑 코드 컴포넌트는 다르다. 이걸 이해하는 데 2년 걸렸다. Figma에서는 쉽다. variant 추가하고 프로퍼티 바꾸고. 클릭 몇 번. 코드에서는? 복잡하다. "이 컴포넌트 prop 12개나 되는데요. 테스트 케이스만 50개예요." 개발자의 한숨. "Figma에서는 간단한데..." "구현은 다릅니다." 배웠다. 디자인 컴포넌트를 만들 때 개발 복잡도를 고려해야 한다. 이 프로퍼티가 정말 필요한가. 이 variant가 코드에서 어떻게 구현되는가. 개발자랑 같이 본다. Figma 파일 놓고 이야기한다. "이거 구현하려면 조건 분기가 10개 필요한데요." "그럼 이렇게 단순화하면 어때요?" 타협한다. 디자인적으로 완벽하지 않아도. 구현 가능한 선에서. 작동하는 시스템이 완벽한 시스템보다 낫다. 버전 관리의 악몽 컴포넌트 업데이트. 축복이자 저주. Master 컴포넌트 하나 수정하면 모든 instance에 반영된다. 편하다. 근데. 작업 중인 파일에도 반영된다. "어? 내 디자인이 왜 깨졌지?" 다른 디자이너의 비명. 내가 버튼 수정했는데 그 디자이너 작업물에 영향이 간 것. 미안하다. 그래서 조심스럽다. 컴포넌트 수정할 때. 누가 어디서 쓰고 있는지 확인한다. 슬랙에 공지한다. "버튼 업데이트합니다, 확인해주세요." 그래도 누군가는 놓친다. 그리고 다음 날. "어제 뭐 바꾸셨어요? 제 파일 다 깨졌는데요." 죄책감. 버전 관리가 필요하다. v1, v2, v3. 별도 페이지에. 근데 그러면 어떤 버전을 써야 하는지 헷갈린다. "최신 버전 쓰세요." "v3이요? 근데 v2가 더 안정적이라던데." "아니 v3이 최신이니까..." 혼란. 정답은 없다. 트레이드오프다. 항상. 6년 차의 깨달음 컴포넌트는 만능이 아니다. 시스템은 목적이 아니다. 도구다. 그냥. 좋은 제품 만드는 게 목적이다. 컴포넌트는 그걸 돕는 도구. 도구가 목적을 방해하면? 도구를 버린다. 시스템이 일을 느리게 만들면? 시스템을 무시한다. 일관성이 사용성을 해치면? 일관성을 포기한다. 원칙은 중요하다. 하지만 맹목적이면 안 된다. 깨야 할 때를 아는 게 경험이다. 신입 때는 몰랐다. 규칙을 배우느라 바빴다. 3년 차 때는 규칙을 만들었다. 완벽하게. 6년 차인 지금은 규칙을 깬다. 필요하면. 그게 시니어다. 미래는 어떨까 10년 차가 되면 어떨까. 아마 컴포넌트를 더 적게 만들 것 같다. 정말 필요한 것만. 핵심만. 경험이 쌓일수록 단순해진다. 복잡함이 답이 아니라는 걸 알게 되니까. AI 도구가 발전하면? "이런 느낌으로 버튼 10개 만들어줘." 클릭 한 번에 variant 생성? 그럼 컴포넌트 개념이 바뀔 것 같다. 수작업으로 만드는 게 아니라 규칙을 정의하는 것. "이런 조건일 때 이런 스타일." 코드처럼. 개발자랑 디자이너의 경계가 흐려질지도. "Design Engineer"라는 직무가 늘어나는 것처럼. Figma에서 직접 코드 생성하고. 컴포넌트가 그대로 프로덕션에 들어가고. 그럼 디자이너의 역할은? 시스템 설계자. 아니, 그것보다. 문제 해결자. 도구는 계속 바뀐다. Sketch에서 Figma로. Figma에서 다음 도구로. 컴포넌트 만드는 방식도 바뀐다. 하지만 본질은 안 바뀐다. 사용자 문제를 이해하고. 솔루션을 디자인하고. 팀과 협업하고. 컴포넌트는 그냥 과정일 뿐. 그래도 계속 말한다 "이거 컴포넌트로 만들어둘게요." 여전히. 완벽하지 않아도. 모든 경우를 커버 못 해도. 나중에 깨질 수도 있어도. 만든다. 왜냐면 그래도 낫다. 아예 없는 것보다. 80% 작동하는 시스템이 0% 시스템보다 낫다. 불완전한 일관성이 완전한 무질서보다 낫다. 깨지는 컴포넌트라도 다시 고칠 수 있다. 시스템은 진화한다. 처음부터 완벽할 순 없다. 써보면서 개선한다. 실패하면서 배운다. 6년 차의 컴포넌트는 1년 차와 다르다. 더 단순하고. 더 유연하고. 더 현실적이다. 10년 차는 또 다를 것이다. 그게 성장이다. 오늘도 출근했다. 슬랙 메시지. "최디자님, 이 버튼 좀 수정 가능할까요?" Figma 켠다. 컴포넌트 페이지 연다. 버튼을 본다. 3개월 전에 만든. 수정한다. 123개 instance에 반영된다. 누군가의 파일이 깨질지도 모른다. 미안하다. 하지만 어쩔 수 없다. 더 나은 시스템을 위해. 저장한다. "수정했습니다. 확인 부탁드려요." 슬랙에 보낸다. 커피 마신다. 네 번째. 다음 컴포넌트를 만들 준비한다. 오늘도.완벽한 시스템은 없다. 있는 건 계속 나아지는 시스템뿐이다. 6년 차가 되어서야 알았다. 컴포넌트는 목적지가 아니라 여정이라는 것을.