Intro
SwiftUI 기반의 디자인 시스템 라이브러리 작성에 대하여 기록합니다.
아직 미완성 프로젝트이지만
커피팩토리는 아직 완성하지 못한 프로젝트다. 처음에는 프로젝트를 완성하고,
정리하는 글을 작성하려 했는데, 어려운 취업 준비로 바쁜 와중, 구상했던
구조를 완성하기까지 최소 년 단위는 훌쩍 지날 것 같아, 계기 및 제작 과정에 대한
글을 작성해야겠다고 마음 먹게 되었다.
시작하게 된 계기
UI는 제품 개발의 우선순위 '하' 다.
필자는 디자이너였다. 특히 UI에 관심이 많은 디자이너였다. 사용자 경험을 설계하고, 그에 적합한 UI를 설계하여 사용자와 서비스를 연결시키는 일은 무척이나 매력적인 일이었고 지금도 그렇게 생각한다. 디자이너로 일하며 UI를 설계하면서 느낀 점이 있었는데, UI는 변경이 잦음에 불구하고, 실제 개발되기까지 시간이 많이 소요된다는 것이다. 그리고 제작 및 수정에 시간 소요가 많음에도 불구하고 우선순위는 매우 낮게 측정된다. 그렇기에 시간이 촉박한 프로젝트일 수록, UI는 시스템 및 라이브러리의 틀을 벗어나기 힘들다.
우선순위가 낮게 측정되는 이유는 당연하다. 실제로, 제품 측면에서 UI가 차지하는 영역보다, 비지니스 기획 및 사용성 설계, 안정적인 기능의 개발과 같은 제품의 시스템 설계 및 안정성이 훨씬 중요하기 때문이다. 아무리 미려한 UI일지라도, 잘못된 시스템 위의 UI는 빛 좋은 개살구일 뿐이다. 그렇기에 시스템이 완성되지 않았다면 UI의 우선순위는 밀려질 수 밖에 없다.
중요한 점은 UI가 제품의 인상 및 사용성을 결정할 수 있다는 점이다. 아무리 좋은 기능을 가진 제품이라도, UI의 따라 사용자들의 제품의 사용수준이 달라질 수 있다. (물론 기획과 UX 설계가 사전에 잘 고려되었다면, UI 역시 잘 설계되었을 확률이 높다.) 게다가 기능적인 완성도가 비슷한 경우, UI의 중요성은 도드라진다. 사용자가 제품을 선택하게 만들 이유가 되기 때문이다.
그러나 경쟁사의 기능적인 완성도 비슷하더라도 많은 경우에 UI 보다는 기능적인 차별성 강화를 위해 새로운 기능 개발에 코스트를 소비할 것이다. 그것이 효율적이기 때문이다. 또한 일정 수준 이상의 UI 완성도를 유지한다면, 그 이상의 UI 개발을 비효율적이기도하다. 대부분의 사용자들은 원하는 기능을 잘 사용할 수 있다면, 거슬리지 않는 이상 UI에 대해 신경쓰지 않기 때문이다.
프로젝트 진행하며
필자는 이렇듯 UI의 우선순위가 계속 미뤄지는 것이 아쉬웠다. 특히 신규 개발 프로젝트에서, 참고할 레퍼런스가 적어, MVP를 사용자에게 전달해 실험하며 빠르게 제품을 바꿘나갈 때, 이 아쉬움은 커져갔다. 프로젝트를 진행하며 디자인 단계에서의 제품과 개발된 제품과의 차이점이 계속 보아왔는데, 아쉬움에 대한 갈증이 크게 느껴졌다. 프로토타입만으로 테스트를 할 수도 있지만, 실제 제품을 사용했을 때 오는 피드백의 차이가 커서 실제 제품을 전달했을 때 변경되는 사항이 훨씬 많았었다. 피드백을 받아가며 점점 디자인은 정리되어 나가지만, 개발된 화면은 피드백을 받기 이전과 크게 달라지지 않는 경우도 많았다. 그러다보니 받았던 피드백을 중첩해서 받는 경우도 많아졌다.
기한은 정해져 있었고, 진행도는 낮으니 자연스레 타협할 수 밖에 없어졌다. 완성된 UI를 추구할수록 전체적인 제품의 완성도가 떨어지게 되었다. 왜 이렇게 되었을까? 가장 큰 이유는 역시 시간이 부족한 것이겠지만, 시간은 항상 부족하니..
부족한 시간도, 부족한 시간이지만, 그것만큼 중요한 이유는 그 부족한 시간조차 효율적으로 사용하지 못했기 때문일 것이다.
만들면서 불필요한 시도들도 많았고, 롤백하는 경우도 많았는데, 문제는 그 시도 및 롤백할 때 조차 시간을 많이 사용했다. 미리 만들어져있던 거의 리소스도 없었고 만들어져있던 것 조차 비효율적이었기 때문이다. 그렇기에 모든 시도마다 새로운 리소스를 생성하며 작업을 진행해 왔는데, 특히 UI 작업 시 반복적인 리소스 생성이 많았다. 이 같은 비효율성을 개선할 수 있었다면 어땠을까? 하는 아쉬움이 들었다.
반복적인 작업을 효율적으로 할 수 없을까?
제품개발을 해본사람이라면 잘 알다시피, 제품개발의 많은 작업들이 일반적으로
패턴화되어 있다. 특히 UI 작업 같은 경우 반복적이고 패턴화된 작업들이 정말
많다. 그렇기 때문에 이를 단순화시킬 수 있는 라이브러리 및 프레임워크도 상당수
존재하고, 많은 곳에서 활용하고 있다. 프로젝트를 진행할 때도 다양한 도구들을
활용했는데, 이러한 도구들이 없었다면.. 끔찍
그럼에도 UI 작업에 많은 시간이 소요되었는데, 커스텀 된 UI가 많았기 때문이다. 기존의 만들어져 있는 툴이나 컴포넌트의 스타일을 일부 수정하는 것은 오래 걸리지 않지만, 제공하지 않는 옵션을 추가한다거나, 조합하는 식의 작업은, 해당 도구에 대한 이해도 필요하므로 이를 학습하는 시간이 오래 걸리기도 했다. 그리고 이렇게 커스텀한 컴포넌트들이 규격화되어 있지 않아, 작업 시마다 서로 다르게 만들어졌고, 사소한 변경에도 서로 호환되지 않았다. 변경이 필요하다면 새롭게 만들게 되었는데 왜냐, 당시에는 긴 시간을 고민해서 수정하는 것보다 새롭게 만드는게 훨씬 더 빠르고 필요했기 때문이다. 그럴수록 점점 전체적인 완성도와 작업속도는 늦춰져가는 있었지만 말이다.
그렇다. 효율적이지 못했던 이유는 만드는게 부족하고 미숙했기 때문이다. 그리고 이렇듯 부족함과 미숙함이 만든 아쉬움의 경험이 효율적인 방법을 고민하게 만들었다. 완성도 높은 좋은 제품을 만들기 위해 어떻게 하면 효율적으로 UI를 만들 수 있을까? 그것이 필자가 디자인 시스템에 관심 갖게 만들고, 이 프로젝트를 시작하게 만든 첫 번째 계기가 되었다.
효율적인 개발을 위한 디자인 시스템
어떻게 작업을 효율적으로 할 수 있을까하는 고민의 해결방안을 제시해 준 것은 디자인 시스템이었다. 디자인 시스템과 관련한 내용을 말하자면, 너무나도 긴데, 가장 기본적인 핵심은 규격화 및 패턴화다.
앞서 말했든 대부분의 제품개발 시 작업은 어느정도 패턴화되어 있다. 특히 UI 작업이 패턴화 된 작업이 많은데, 이 패턴를 효율적으로 만들기 위해 규격화를 시키는 것부터 디자인 시스템 개발이 시작된다. 그리고 규격화 된 값들을 점점 확장하여, 패턴화 시켜나가고 패턴화 된 작업들을 조합해 나가다보면 어느새 쉽게 UI 작업을 완료할 수 있다.
디자인 시스템의 장점
이렇게 규격화 및 패턴화 시킨 UI들은 수정 또한 용이하다. 규격이 변경되면, 해당 규격만 변경하면 되고, 패턴화된 작업의 변경이 필요하면, 해당 작업요소만 다른 패턴으로 대체하면 되기 때문이다. 물론 이렇게 해결되지 않은 경우도 있다. 공통화 된 요소로 해결되지 않는 경우, 그것이 일반적으로 대체할 수 없는 핵심요소이거나, 새로운 규격화가 필요한 경우일 수 있다. 혹은 둘 다 이거나. (핵심요소도 규격화 및 패턴화 시킬 수 있다는 뜻) 그렇지만 적용 가능한 공통요소를 적용한 이후에 적용이 안된 요소에만 신경써서 보다 많은 시간을 투자할 수 있으니 적용할 요소가 없을 때 보다 훨씬 낫다.
여러 시행착오를 겪어가며 디자인시스템의 개념을 프로젝트에 적용하면서, 그 효과를 톡톡히 누렸다. 효율적인 UI 생성 및 수정을 통해 UI 생산 속도를 크게 증가시켰고, 이후 버전개발 시 완성도를 크게 상승시켰기 때문이다.
디자인 시스템을 개발하고 사용하면서 장 · 단점이 분명했지만, 지속적인 제품 개발을 원한다면 장점이 훨씬 많다고 느꼈다.
디자인 시스템을 경험한 이후
디자인 시스템의 긍정적인 효과를 본 이후, 여러 프로젝트에 디자인 시스템의
개념을 적용해보고자 했고, 커피팩토리 프로젝트도 그 중 하나이다. SwiftUI 를
경험하며 디자인 시스템을 적용하기 효과적이겠다는 생각도 들었고, 개인적인
디자인 시스템을 만들어보자는 생각도 들었다. 특히 23년 피그마가 업데이트 된
이후 추가된 variables 는 이 프로젝트를 시작하게 만든 이유 중 하나이다.
그래서 정리하면
커피팩토리는 개인적인 SwiftUI 디자인 시스템 패키지다. 개발하게 된 이유는
비효율적인 작업의 쓰라린 경험을 통해 관심 갖게 된 디자인 시스템으로 크게
효과를 보고 SwiftUI에도 적용할 수 있지 않을까 싶어 시작하게 되었다.
저게 위에 주저리주저리 써놓은 내용을 정리하면 저게 다다.. 앞으로 글들에서는 어떻게 커피팩토리 디자인 시스템을 구성하고 개발하였는지에 대해 작성하고자 한다.