이번 포스팅은 회사 창립 이래 30년 만에 최초로 디자인 시스템을 본격적으로 구축하고, 사내 시스템으로 배포하기까지의 과정과 기술적으로 어떻게 구상하고 적용했는지에 대해 두개의 포스팅으로 공유하고자 한다.
사실 최초라고 작성하긴 했지만, 재작년에 작성했던 "Storybook으로 퍼블리셔, 디자이너와 협업 그리고 디자인 시스템 구축까지"라는 글의 주제로 포스팅한 적이 있었다. 하지만 이때는 사내 시스템으로 배포에는 실패하고, 제품의 공통 컴포넌트로 사용하는 수준에서 그쳤다. 왜냐하면 사내에서 디자인 시스템을 구축하고 왜 이걸 하는지 타당한 이유가 부족했다.
그래서 지난번의 디자인 시스템 구축에 실패했던 이유와, 이번에는 성공했던 이유 그리고 소통의 장애를 극복한 이야기에 대해 풀어보고자 한다.
최초의 디자인 시스템 구축의 실패했던 이유
최초의 디자인 시스템에선 나름대로 아토믹 디자인 시스템과 퍼블리셔와의 긴밀한 소통을 하면서 디자이너에게 컴포넌트의 조합을 이해한다는 이유를 말하면서 나름대로 이유를 붙여가면서 적용했다. 문제는 개발자와 퍼블리셔 두 명만 필요성을 느끼고 개인 시간까지 투자하며 만들어갔다. 하지만 이런 방식만으로는 부족했다.
`시스템`이라는 것은 일종의 `규율`이다. 어느 한 명이라도 규율을 지키지 않으면 그 시스템의 체계는 무너지게 된다. 그러면 내가 디자인 시스템 적용을 하고자 했던 이유는 무엇일까?
1. 제품의 정체성 일관성에 따른 UX 제공
2. 일관된 디자인의 컴포넌트 활용에 따른 예외 케이스 최소화
3. 개발 및 디자인 설계 리소스 최소화
4. 디자인에 따른 불필요한 소통 최소화
위 네 가지 이유가 내가 디자인 시스템을 적용하려 했던 이유라고 생각한다. 하지만 위 네 가지 이유는 `실무자기준에서의 장점`일 뿐이다. 결국 저 이유를 적용하기 위해서는 실제 제품을 만드는 시간을 별도로 `투자`해 가면서 시스템을 만들어야 하는 이유가 되지 않는다.
처음에는 이해하지 못했다. 일관된 디자인을 제공해서 사용자에게 더 나은 UX 제공과 실무자들의 소통을 줄이는 것이 생산성이 더 좋은 게 당연하지 않은가라고...
물론 맞다. 하지만 이건 시스템을 적용할 때의 `실무자만의 장점`에만 해당한다. 실제로 회사에선 굳이 디자인 시스템이라는 것을 만들지 않고 하던 대로 그때그때 디자인 요청해서 만들고, 개발하고 하는 것이 더 빠를 수 있다. 또한 디자이너들도 그때그때 디자인하는 데 있어서 다른 고려 사랑을 할 필요가 없어 디자인하는 속도도 빠를 것이다.
그제야 깨달았다. 왜 이 회사가 지금까지의 필요 이상의 디자인과 개발의 리소스가 이렇게나 많이 소모되는지, 또 유지보수가 되지 않아 비슷하지만, 항상 새로 만들어야 하는 디자인이 많은지를…. 또 개발자는 그걸 또 새로 만들고 있었다.
결론은 사내 시스템을 만들기 위해서는 이걸 구축하기 위해서 리소스를 별도로 투자해야 할 정도로 `타당한 이유`가 반드시 있어야 한다.
타당한 이유란?
나는 적용할 때의 장점만 생각하는 것을 넘어서 더 넓은 범위로 이 이유에 대해 고민해 봤다.
`회사는 이익집단`이다. 회사에서 일하는 사람들은 회사의 이익을 전달해 주기 위해 고용된 근로자들이다. 그렇다면 불필요한 리소스를, 돈을 주면서까지 일을 시키고 싶지 않아 한다. 더욱이 사업의 규모가 작거나, 리소스를 투입하기 힘든 상황이라면 더욱더 그렇다.
처음 디자인 시스템을 구축할 때도 내가 생각하는 이유를 전달했지만, 설득력이 부족했다. 지금까지 설득력이 부족했던 이유를 복기해보고 어떤 식으로 극복했는지에 대해 정리해봤다.
소통의 장애와 극복
가장 먼저 실무자끼리 개념적인 이유에 대해 `동기화`가 되지 않았던 것이 가장 큰 문제였고, 긴 세월 동안 관성적으로 일을 해오던 `습관`에서 비롯한 문제가 발생했다.
장애: 실무자끼리의 소통 부재
실패했던 첫 번째 디자인 시스템을 적용할 때 어떻게 디자이너와 소통했는지 다시 생각해 보았다.
"컴포넌트는 아토믹하게 쪼개고, 하나의 컴포넌트는 작은 단위의 일만 해야 한다." "더 큰 범위의 컴포넌트는 우리가 제한한 기능에서 벗어난다.", "이 기능 저 기능 들어가면 이 컴포넌트는 시스템에서 벗어난다." 등...
지금 생각해 보면 디자이너 입장이라면 이렇게 생각하지 않았을까?
"왜 내가 디자인하는 것에 대해 개발자들이 이렇게 제약을 주지? 이렇게까지 제약을 주면서까지 이걸 하는 이유가 뭐지? 이건 재사용할 생각으로 만든 디자인이 아닌데…. 색상은 디자인 관점에서 더 나은 색상을 주고 싶은데…."
실제로 그랬다는 건 아니고 입장바꿔 생각해 보면 이렇게 생각해도 전혀 이상해할 것이 없었다.
극복: 디자인 시스템의 개념과 의미 동기화 작업
내가 놓치고 있던 것이 디자이너니까 당연히 디자인 시스템이 뭔지 알 것으로 판단했다. 하지만 30년 동안 디자인 시스템을 적용하지 않았던 회사에서 이 개념은 기본적으로 알고 있을 것으로 판단했던 나의 치명적인 실수에서 비롯되었다.
그래서 먼저 디자인 시스템이 무엇인지부터 개념적으로 동기화가 필요했다.
처음부터 시작했다. 먼저 디자이너와 개발자끼리 입장차이와 지금 내가 디자인 시스템을 적용하려는 이유와 서로 협심해서 시스템을 구축하고자 하는 마음을 전달했다.
디자이너에게 설득하기 위해 관련 자료와 그때그때 필요한 정보들을 요약해서 전달하거나 참고할 만한 자료를 공유했다. 덕분에 나도 시스템 구축을 위해 뭐부터 준비해야 하는지, 디자인 토큰을 어떤 기준으로 네이밍하고 나눌 것인지, 타사 것을 참고해서 우리 시스템에 어느 수준까지 적용할 것인지에 대한 기준이 세워졌다.
2주간 지속적으로 공유하고 정리된 내용을 기반해서 디자인 시스템의 개념과 의미에 대해 동기화를 진행했다.
> 참고 자료
장애: 관성적 업무 습관으로 인한 스노우볼
개념적으로 자리잡혀갈 때쯤, 다같이 본격적으로 각자 업무를 진행해야 하는 상황이 생겼다. 물리적인 시간을 고려해서, 디자인 시스템 구축과 서비스 개발을 동시에 작업해야하는 상황이 생겼다. 때문에 가장 기본적인 디자인 토큰 정의, 아토믹 컴포넌트 몇가지를 정의하고, 지속적으로 디벨롭하는 방식으로 업무를 진행하기로 했다.
초반에 서비스 개발과 시스템 개발을 동시에 진행하면서 디자이너와 별도로 소통하는 리소스가 엄청나게 소모되었다. 내가 추친하고자 했기 때문에 크게 힘들다는 느낌보다는 제대로 된 시스템을 만들어가고 있다는 생각에 즐겁게 진행했었다.
하지만 `퍼블리셔 <-> 디자이너 <-> 개발자`의 업무를 진행하면서 각자 관성적으로 일하던 습관이 지속적으로 나타나기 시작했다. 중간마다 나와 소통하지 않고 각자 "일단 이렇게 먼저 진행하자"라는 뉘앙스로 업무가 간간이 발생하기 시작했다. 그때마다 교통 정리를 해서 규율을 지키도록 조절했으나, 모든 업무를 혼자서 컨트롤하기에는 나의 물리적 시간도 부족했다.
이렇게 스노우볼이 계속 굴러가다 보니 서비스 1차 오픈할 때쯤 내가 알지 못했던 시스템의 구멍들이 우수수 드러나기 시작했다.
극복: 핸드오프를 통한 스노우볼 제거
관성적인 업무 습관을 해소하기 위해서 핸드오프 시간을 만들었다. 사실 디자인 시스템 구축을 하기 위해선 핸드오프 과정이 필요하다. 하지만 각자 바쁘다는 이유로 이를 진행하지 못했는데, 이번에 단군 소프트에서 진행하는 Figma Design Systems meetup: 서울 세션이 열린다는 소식을 듣고, 디자인 시스템 관계자 중 한 명씩 여기에 참석 권유했다. 세션을 듣고 다들 반응이 되게 좋았고, 지금까지 관성적으로 방식과 간과하고 있던 디자인 컴포넌트 설계 방식에 대해 다시 고민하고 만드는 계기가 되었다.
다음날 바로 핸드오프를 위한 회의를 지금까지의 스노우볼을 제거하기 위해 개선점과 앞으로 고민하고 진행해야 하는 부분들에 대해 자료를 만들고 공유하는 자리를 만들었다.
사내 시스템의 공식 발표
지금까지 핸드오프를 3회차 진행했고, 처음과는 비교가 안 될 정도로 빠르게 개선점과 고민 점을 공유하고 반영에 들어갔다.
3회차 핸드오프 진행 시 C레벨 임원진 세 분이 참석하셔서 현재 디자인 시스템의 적용에 대한 명확한 이유와 그로 인한 낙수효과에 대해 전달할 수 있게 되었고, 점점 더 확장하게 될 도메인 서비스의 디자인 정체성 확립의 중요성까지 전달할 수 있게 되었다.
이미 시스템 자체는 서비스에서 반영하고 있었고, 마침내 사내에서 공식적으로 디자인 시스템을 배포하게 되었다.
이제부터 기획자와 디자이너는 시스템을 기반으로 서비스 시안 작성을 더 빠르게 할 수 있게 되었다. 개발자는 시스템화된 컴포넌트를 통해 더욱 빠른 서비스 개발이 가능해졌고, 사업 전체적으로 디자인 정체성이 명확한 서비스를 배포할 수 있게 되었다.
결론
당분간 안정적인 서비스 운영을 위해 나와 퍼블리셔 한 분씩 디자인 시스템을 유지보수하고, 새로운 컴포넌트의 제안이 올 때 서로 의논하고 공유하여 빠른 컴포넌트 제공하는 환경 구축에 성공했다.
지금까지 경험해 왔던 트러블 슈팅 경험과는 사뭇 달랐다. 시스템을 구축하면서 경험에서 크게 느낀 것은 개발 자체에 대한 이슈는 시간만 투자하면 해결이 된다. 하지만 동료들과의 `소통과 설득`을 어떻게 하느냐에 따라 시스템 구축의 성공이 좌지우지된다.
스스로 새로운 것을 도전하거나 짙은 관성을 극복하는 것은 나 혼자 열심히 하면 된다. 하지만 함께 일하는 동료들과 같이 극복하는 것은 완전히 다른 이야기다. 결국 모두 본인이 만든 제품이 잘되기를 바라는 것이 똑같다. 이 마음을 다 같은 마음으로 함께 가져갈 수 있게 생각하는 것이 정말 어렵다. 어려운 만큼 이걸 극복하고 해냈을 때의 기분은 실로 말할 수 없을 정도로 뿌듯하다.
다음에는 디자인 시스템을 구축하기 위해 기술적인 고민과 어떤 기술을 사용했는지, 개발하면서 겪었던 트러블 슈팅에 대한 포스팅으로 돌아오겠습니다.
'회사 > 도입' 카테고리의 다른 글
| 실용적인 사내 디자인 시스템 설계와 사용 그리고 확장성 (0) | 2025.02.02 |
|---|---|
| 🤝 Storybook으로 퍼블리셔, 디자이너와 협업 그리고 디자인 시스템 구축까지 (2) | 2023.12.20 |
| yarn-berry 마이그레이션 적용기 (0) | 2023.07.31 |