DDM(Datarize Dev Meetup)의 두 번째 세션은 프론트엔드(Front-end) 챕터였습니다. 이번 세션은 FE 개발과 프론트엔드 챕터 Lead를 맡고 있는 종형님이 발표해주셨는데요. CDD를 주제로 데이터라이즈 개발 방식을 전해주셨어요. 아래 내용을 통해 직접 확인해 보세요!
안녕하세요. 프론트엔드 챕터 Lead 이종형입니다. 저는 오늘 CDD를 통해 프론트엔드 개발의 효율을 더하고 있는 데이터라이즈만의 업무 방식을 전해드리고자 합니다.
CDD(Component Driven Development)란?
먼저, CDD(Component Driven Development)에 대해 이야기 하겠습니다. CDD의 핵심인 컴포넌트(Component)는 UI에서 독립적이고 재사용 가능한 블록을 의미합니다. 각 컴포넌트는 고유의 기능과 스타일을 가지고 있고 독립적으로 작동할 수 있는 것이 특징인데요. 이 컴포넌트를 구성하는 4가지 핵심 요소가 있습니다. 첫 번째는 독립성입니다. 컴포넌트는 독립적으로 개발, 테스트, 유지보수 될 수 있어야만 합니다. 이는 컴포넌트 간의 결합도를 낮추고 재사용성을 높이기 때문이죠. 두 번째는 재사용성입니다. 여러 프로젝트나 애플리케이션에서 재사용할 수 있도록 설계합니다. 이는 곧 코드 중복을 줄이고 개발 효율성을 높입니다. 세 번째는 모듈화입니다. 애플리케이션을 작은 모듈(컴포넌트)로 분리하여 개발합니다. 각 모듈은 특정 기능을 담당하고 있어야 이를 조합한 복잡한 UI 구성도 가능합니다. 마지막은 디자인 시스템과의 통합입니다. 디자인 시스템과 통합되어 일관된 스타일과 사용자 경험을 제공합니다. 이는 곧 UI의 일관성을 유지하고 브랜드 이미지를 강화하는 방법이 됩니다.
FE x CDD
사실 위에서 제시한 핵심 요소만으로도 프론트엔드 개발에서 CDD가 왜 필요한지 명확하지만 더 깊이 보겠습니다. 고객이 제품을 보고 느끼는 것들은 다 다르지만 일관된 디자인과 UX를 유지하는 것은 서비스의 기본 요소입니다. 이 기본적인 요소를 위해 모든 컴포넌트들이 동일한 가이드와 시스템을 따르면서 제품의 일관성을 유지합니다. 가령 컴포넌트로 이루어지지 않은 프론트엔드 개발은 페이지마다 미세한 차이가 발생할 수 있습니다. 물론 컴포넌트가 아니라도 스타일의 통일성을 갖추는 일이 가능하지만 동일한 컴포넌트를 여러 개 만들면 시간과 디자인 리소스의 비효율이 발생합니다. 컴포넌트로 이루어지면 문제가 생길 때 통째로 문제가 생기기도 하지만 저는 망가질 때 다 같이 망가지는게 더 좋다고 생각합니다. 문제가 있는 영역이 어딘가에 숨어 있어 그 영역을 찾느라 힘들 수 있기 때문이죠.
코드를 작은 단위로 분리한 모듈화가 핵심 요소인 이유는 컴포넌트가 독립적으로 개발, 테스트, 유지보수 될 수 있기 때문입니다. 이는 코드 관리와 디버깅을 용이하게 합니다. 이것 저것 많은 기능들이 포함된 다이얼로그가 있다고 가정해 볼게요. 타이포, 입력창, 버튼 등을 따로 개발하고 사용할 때는 아무리 조합해도 모든 타이포와 입력창, 버튼이 독립적이게 됩니다. 이는 테스트와 유지보수의 용이성을 높이게 합니다.
디자인 시스템과의 통합은 디자이너와 개발자의 원활한 협업을 위해 필요합니다. 동일한 언어와 개념으로 소통함으로써 커뮤니케이션의 효율을 높이기 때문입니다. 또한 디자이너는 디자인 시스템을 통해, 개발자는 컴포넌트 라이브러리를 통해 협업할 수 있습니다. 예를 들어, 디자이너가 피그마로 만든 디자인 시스템을 개발자가 스토리북을 통해 컴포넌트로 구현하고 문서화 합니다. 디자이너와 개발자는 스토리북을 살펴 보면서 수정사항이 있는지 변경이 필요한지 등의 여부를 한눈에 확인할 수 있게 되죠. 더불어, 독립적인 컴포넌트 단위로 테스트를 작성하기 쉬워집니다. 이는 전체 시스템의 안정성과 신뢰성을 높여줍니다.
전통적인 방식 vs CDD
전통적인 개발 방식에서는 페이지 그 자체 혹은 화면에서 보이는 요소들 모두를 개발하는 것이 기본이었습니다. 하지만, CDD가 적용된 개발에서는 컴포넌트들을 개발하고, 그 컴포넌트들을 조합하여 페이지나 화면을 구성하게 됩니다. 싸이월드 시절 화면을 보시면 모든 버튼과 요소가 assets입니다.
하지만 핀터레스트는 같은 컴포넌트를 하나 만들어두고 각각 다른 크기의 이미지만 넣어주었다는 걸 볼 있습니다.
데이터라이즈 x CDD
지금까지의 내용을 통해 CDD의 특징과 장점에 대해 공감하셨을 것 같은데요. 지금부터는 그러한 CDD를 데이터라이즈에서는 어떻게 사용하고 있는지 이야기하고자 합니다.
디자인 시스템
당연히 규격화되고 통일화된 가이드라인(색상, 타이포 등)이 필요합니다. 이는 이번 주제에서 자세하게 커버할 영역은 아닌듯 하여 언급만 하고 넘어갑니다.
스토리북
독립된 개발 환경에서 컴포넌트를 개발하고 문서화하기 위해서는 스토리북을 활용합니다. 컴포넌트 자체를 확인할 수 있는 공간이 필요하기 때문이죠. 페이지에 붙어 있는 상태로 확인하지 않습니다. 기본 버튼 상태, 호버 시의 버튼 상태, 클릭 시의 버튼 상태 등의 각종 상태들을 컴포넌트 단위에서 확인할 수 있습니다.
컴포넌트 라이브러리 구축
공통 컴포넌트들을 모아두는 라이브러리입니다. 저희 데이터라이즈에서는 dtr-design-library라는 디자인 라이브러리를 운영하고 있습니다.
이미 구축된 것들이 있긴 하지만 아직도 개선해야 할 부분들이 많습니다. 저희도 아직 CDD를 완전히 도입했다고 보기엔 어렵습니다. 수많은 디자인 요구사항이 있기 때문입니다. 서두에 말씀드렸던 Component Driven이 가능하려면, 디자인 시스템/라이브러리에 존재하는 Component를 기반으로 그 형태를develop하는 형태여야 합니다. 필요하다면 기존의 컴포넌트를 확장하고 새로운 컴포넌트로 분리하여 구성해야 합니다. 이런 작업들을 하기 위해 현재 새로운 디자인 시스템과 라이브러리로의 개편을 준비하고 있습니다.
다음 밋업 때는 새로운 디자인 시스템과 라이브러리도 소개해드릴 수 있지 않을까 합니다. 긴 내용 들어주셔서 감사합니다. 컴포넌트 기반으로 효율성을 찾고 다양한 기능들을 구현하고 있는 데이터라이즈 FE에 관심이 있는 분들은 언제나 연락 부탁드립니다 🙂
