디자인 시스템에 회의적이었다가 필요성을 느끼게 된 계기

디자인 시스템의 필요성을 못 느꼈는데 최근 들어 많이 느끼고 있어 정리를 해본다.
 

디자인 시스템에 회의적이었던 나

전 회사에선 웹뷰 비중이 커서 앱 단에서 적용할 디자인 시스템이랄 게 없었다. 앱바나 바텀시트 등을 컴포넌트화 해서 쓰는 정도였다.
 
디프만에서 했던 사이드 프로젝트에선 디자인 팀원들이 엄청 작은 단위까지 디자인 시스템을 만들어줬는데 다 만들기엔 시간이 너무 오래 걸릴 것 같아서 자주 쓰일 것 같은 몇개만 컴포넌트화 해서 썼었다

 
이렇게 처음 해보고는 "좋긴 한데 만드는 시간을 고려하면 배보다 배꼽이 더 큰 거 아닌가?"라는 생각이 들었다.

그래서 디자인 시스템에 회의적이었고 지금 회사에 들어오고 나서도 "정말 효용이 있는 것이 맞는가? 전체적으로 보면 오히려 생산성이 떨어진 결과가 나올 수 있지 않을까?"와 같은 생각이 계속 들었다.
 

---

 

필요성을 느끼게 된 계기

바텀 시트를 띄워야 했다. 바텀시트는 정식 디자인 시스템 컴포넌트가 아니었지만 앱 단에서 재사용성을 챙기기 위해 컴포넌트화해서 사용하고 있었다. 그런데 이 코드가 확장성이 떨어지게 짜여 있었다. 새 요구 사항을 반영하려면 구조를 건드려야 했고 영향 범위가 넓었다. 

이슈가 없을지 다 직접 테스트해봐야 하는데 너무 많은 시간이 소요될 게 뻔해서 아찔했다. 지그재그는 UI가 동적으로 많이 바뀌기 때문에 모든 케이스를 재현까지 해야 했다. 😔 

 
필요하다면, 해야 한다면 하겠지만 1~2dp를 위해서 매번 이렇게 많은 시간을 써서 스릴 넘치게 영향 범위를 테스트 해야 한다면 고통스러울 것이다. 고통스러운 건 개발자 뿐만이 아니라 검증해주시는 분들도 포함일 것이다. (1~2dp가 안 중요하다는 말이 아니다.) 
 
다행히 이번 작업 건에선 기존에 재사용하고 있던 대로 사용하기로 하여 우려했던 상황은 일어나지 않았지만 몇가지 생각이 계속됐다.
 
"왜 처음부터 확장성 좋게 설계가 되지 못했을까?" 그리곤 이내 어쩔 수 없었겠다는 생각이 들었다.
 
처음 설계할 땐 이렇게까지 많은 지면에 다양한 variation으로 활용될 줄 몰랐을 것이다. 필요 이상으로 작업을 해놓는 건 오버스펙이 되기도 하기 때문이다.
 
"그러면 어디까지 확장될 수 있을지를 합의해서 디자인 시스템을 구축하고 그 합의된 범주 내에서 디자인이 이루어진다면 되겠다"라는 생각이 들었다.
 
그리고 오늘 마침 팀원 분들과 비슷한 주제로 논의를 했는데 한 팀원 분께서 "다른 파트와 합의된 건 디자인 시스템밖에 없고, 디자인 시스템을 제한 나머지 것들에 대해서 재사용성을 챙기려는 건 우리만의 합의다."라는 의견을 주셨다.
 
너무 공감이 됐고 내가 생각했던 것과 똑같은 의견이었다. 그래서 재사용성을 온전히 챙기기 위해선 여러 파트 간의 합의, 즉 디자인 시스템이 필요하겠단 생각이 들었다. 다르게 표현하자면, "영향 범위에 따른 검증 부담을 줄이기 위해선 디자인 시스템이 필요하다."라고 할 수도 있겠다. 개발 못지 않게 검증도 신경이 많이 가는 영역이란 생각이 자주 드는 요즘이다.
 
한편, "그냥 복사 붙여넣기를 두려워하지 말라는 말도 있더라구요."라는 의견도 나왔다. 
 
맞다. 사실 검증이 부담스러우면 그냥 비슷한 걸 하나 만들어 쓰면 되긴 한다. 비즈니스를 위해 개발이 존재하는 거지 역은 아니기 때문이다. 

 
하지만 위와 같은 상황은 조심해야 할 것이다. 어렵다.