잘못된 접근법 사용; 과연 Atomic Design이 좋은 패턴일까

설계한 컴포넌트들을 어떤 규칙에 맞게 정리를 할것인가에 대해서도 고민이 있었는데, 적

컴포넌트를 설계하는 것에도 미숙함이 있었지만, 이를 어떤 원칙에 맞게 정리를 하고 모아야 하는가에 대한 고민에서도 Atomic Design을 적용하면서 많은 고찰을 할 수 있었습니다.

<aside> 📖 Atomic Design 간단소개 Atoms(원자): 기본 빌딩 블록 Molecules(분자): 그 자체의 특성을 가지고 있는 디자인 시스템의 중추 역할 Organisms(유기체): 분자들을 결합하여 유기체를 형성할 수 있음 Templates: Organism의 집합, 레이아웃이 실제로 구동하는 것을 볼 수 있음 Pages: Template의 인스턴스

</aside>

실제로 컴포넌트가 설계되는 과정에서 다른 컴포넌트들이 들어가기도 하지만, 한 컴포넌트가 Atom, Molecule ,Organism중 무엇이냐를 구별하는 것에 큰 의미가 없었다. 각 레벨마다 무엇을 하는지를 정의하기 힘들었다.

예를 들어

• html태그로서 input은 간단할 수 있으나, 우리가 정의하고자 하는 Input은 상당히 많은 기능을 내포한다. 오탈자 발생 시 경고문구 표기, 검사 로직, 라벨 표시 등등…
• “한가지만 하고 그거 하나만 잘해라"가 Molecule인데, 우리가 만든 Form은 너무 많은걸 한다. 그런데 원문에서는 Molecule이라고 지정한다.
• Template의 경우에는, 디자인 시스템이라고 부르기 민망할 정도로 범용화시키기 어려워서 UI구현체 라이브러리 밖의 앱 프로젝트에서 별도로 폴더를 만들어 구현을 진행하였다.

명확한 목적 구분이 있는 Foundation-Implementation (Grid, FontSize, Color등을 정하고 이 디자인 토큰들을 기반으로 컴포넌트를 설계)와는 다른, 그저 겹겹이 쌓기 이론에 불과하다는 느낌을 받았다. Atomic Design에서 Atom, Molecule, Organism, Template, Page가 그저 Lv 1,2,3,4,5라고 해도 무방하지 않은…

수많은 방법을 통틀어 아토믹 디자인은 우리가 특정 방식을 의식적으로 생각하지 않았더라도 어쩌면 우리가 모든 것을 함께 작업했던 방식일지 모릅니다.

아마도 2013년에 작성된 글이기에 글에 적혀있는 ‘디자인 시스템'과 지금 우리가 생각하는 ‘디자인 시스템'에 간극이 있거나, 아직 컴포넌트 기반의 개발이 덜 이루어지던 시기에 직관적인 이해를 위해 만들어진 개념이 아닐까 싶다.

결론

• Atomic Design Pattern은 디자인 시스템을 위한 패턴이 아니며, 일반적인 프론트엔드 개발에서 가져가고자 하는 컴포넌트 기반의 개발 접근법에 가까운 것 같다.
• 하지만 이런 모호한 명칭 없이도 이미 잘 사용되고 있던 패턴이었으며, 굳이 folder structure에 Atomic Design을 가져가서 이게 Atom이냐 Molecule이냐를 규범하고 분리하는것은 무의미한 일이다.
  • 다만 겹겹이 쌓이는 컴포넌트 구조를 어떤식으로 풀어내야하는가는 여전히 풀어야하는 과제인 것 같다.

섣부른 디자인 시스템 구현체 분리

희망편: 완성된 디자인 시스템 구축과 간편한 적용, 점진적인 디자인 변경사항 유지관리

절망편: 급격한 디자인 변경사항과 지원되지 않는 prop 발생으로 인한 DDS 컴포넌트 미사용, 방치

• UI디자인이 시스템 기반해서 나와야만 잘 사용할 수 있을텐데.. 현실은..

DDS를 정립한 후, 이를 별도의 코드 구현체에 적용했습니다. 디자인 시스템과 이에 대한 구현체, 그리고 구현체를 활용한 서비스 내 적용은 원칙 상 모두 분리되어야 하기 때문에, 코드 구현체도 동일하게 적용하였습니다.