Atomic Design Pattern 도입기 (2)⚛️

안녕하세요! 미어켓 프론트엔드 개발자 노윤지입니다.😊

지난 글에서는 미어켓에서는 아토믹 디자인 패턴이 무엇인지와 이 방법론을 도입한 이유를 소개했었어요.
이번에는 미어켓 팀이 아토믹 디자인 패턴을 도입한 방식와 실제 사용 후기를 나눠볼게요.

"아토믹 디자인 패턴은 멘탈 모델이기 때문에, 팀 내에서 아토믹 디자인 패턴 규칙을 정립해야 한다."

미어켓 팀은 다른 팀들의 사례를 분석하여 각 팀이 아토믹 디자인 패턴을 도입하면서 새로운 규칙을 만들고 있음을 알게 되었어요. 미어켓 팀도 추상적인 패턴을 구체화할 필요가 있었죠.

Atomic Design Pattern 사용 규칙

미어켓 팀에서는 크게 4가지 규칙을 정했어요.

1. 디렉터리 구조 통일하기

프로젝트의 디렉터리 구조는 다음과 같이 구성했어요.

src/
├── components/
│   ├── atoms/
│   │   └── Input/
│   │       ├── index.tsx
│   │       ├── stories.ts
│   │       └── styled.ts
│   ├── molecules/
│   ├── organisms/
│   └── templates/
└── pages/

• components 디렉터리는 아토믹 디자인 패턴에 따라 atoms, molecules, organisms, templates로 구성했어요.
  pages는 다른 레벨과 달리 비즈니스 로직을 포함하기 때문에 별도로 분리하여 역할과 책임을 명확히 했어요. 이렇게 함으로써 컴포넌트와 페이지 간의 의존성을 줄이고, 각자의 역할을 명확히 할 수 있었어요.
  
  또한 아토믹 디자인 패턴과 궁합이 좋은 Emotion(CSS-in-JS)과 Storybook을 사용하여 각 컴포넌트의 스타일링과 문서화를 체계적으로 관리했어요. 각 컴포넌트마다 index.tsx, stories.ts, styled.ts 파일을 두어 역할을 명확히 구분함으로써 코드의 일관성을 높이고 유지보수성을 향상시킬 수 있죠.

2. Atoms에서 HTML 태그 속성 상속하지 않기

• 타입스크립트를 사용하여 HTML 엘리먼트를 래핑하는 컴포넌트를 구현하는 과정에서 HTML 태그의 모든 Attuributes를 상속받을지 여부에 대한 논의가 있었어요. 모든 속성을 상속받을 경우 컴포넌트가 불필요하게 무거워질 수 있으므로, 현재는 필요한 기능만 구현하고 추후에 기능이 더 필요할 경우 그때 확장하기로 결정했어요. 이를 통해 초기 개발의 복잡성을 줄이고 필요에 따라 유연하게 확장할 수 있는 구조를 유지할 수 있어요.

3. 계속 유사하게 재사용될 것 같은 컴포넌트는 컴파운드 패턴으로 구현하기

• 미어켓에서 경매 물품을 보여줄 때 사용되는 <PostItem> 컴포넌트예요. 셋은 비슷하지만 동일하지 않는 디자인들이죠. 각 컴포넌트를 개별적으로 구현하면 중복 코드가 불가피해지므로 이를 최소화하기 위해 컴파운드 패턴을 적용했어요. 단순히 요소의 위치가 왼쪽이나 오른쪽으로 바뀌는 경우에는 props으로 구현할 수 있지만, 향후 확장 가능성이 있는 컴포넌트들은 컴파운드 패턴으로 구현하기로 결정했어요.

4. 컴포넌트를 5가지 레벨로 분류하기: 회의를 통해 결정!

• 미어켓 팀은 컴포넌트 개발 시 발생할 수 있는 혼란을 방지하기 위해, 컴포넌트를 5가지 레벨로 명확히 분류하기로 결정했어요. 각자 기능을 분배하고 작업을 진행할 경우, 기준이 모호해 서로의 작업을 파악하는 데 어려움이 발생할 수 있기 때문이에요. 아토믹 디자인 패턴은 특히 추상적인 부분이 많아 팀원 간의 원활한 소통과 이해가 중요해요! 전체 회의를 통해 모든 의견을 반영하고, 필요한 컴포넌트들을 각 레벨에 맞게 구분한 후 이를 팀원들에게 분배하여 혼란을 미연에 방지할 수 있었죠.

+ 미리 정했으면 더 좋았을 규칙들

1. children 적극 활용하기

• 현재 대부분의 컴포넌트들은 props를 통해 데이터나 다른 컴포넌트를 받아오는 방식으로 설계되어 있어요. props를 통해 데이터를 전달하는 경우, 의존성이 증가하고 재사용성이 저하될 수 있어요. 반면 children을 사용하면 컴포넌트의 독립성과 유연성이 증가되죠. Organisms에서도 children을 통해 하위 레벨의 컴포넌트를 받도록 리팩터링을 한다면 훨씬 더 깔끔하고 직관적인 구현이 가능할 거예요.

2. 공통적으로 쓰이는 추상 요소들은 Atom으로 구현하여 사용하기

• 현재 구현된 컴포넌트 중 공통적으로 사용되는 스타일이 많다는 것을 실감했어요. <Text> 뿐만 아니라 Color나 <Flexbox>와 같은 레이아웃 관련 스타일을 Atom으로 구성하면 작업 효율성이 향상될 수 있을 거예요.

3. 레이아웃 스타일 주입 방법 통일하기

• margin, padding, display 같은 스타일을 어디에서 주입할 지는 여러 방법이 있어요. 컴포넌트 내부에서 처리 CSS-in-JS로 래핑하여 처리하거나, 컴포넌트 외부에서 직접 style={}로 주입하거나 <div>를 레이아웃 용도로만 래핑할 수도, 혹은 Atom으로 구현하여 쓸 수도 있겠죠. 현재는 팀원마다 선호하는 스타일 적용 방식이 다르므로 이를 통일하여 코드의 일관성을 높이는 것이 필요해요.

이 세 가지 규칙들은 리팩터링 후에 더 자세히 다룰 예정이에요.

마이페이지로 보는 아토믹 디자인 패턴 적용 예시

• Atom의 <Text>와 <Icon> 컴포넌트를 결합하여 <IconWithText> 컴포넌트를 생성했어요. 이후 <IconWithText>를 활용하여 여러 개의 메뉴 항목을 포함하는 <MyPageMenu>를 구성하고, 이를 다른 Organism과 조합하여 <MyPageTemplate>를 완성했어요.

그래서 실사용 후기는?

👍 좋았던 점

1. UI 일관성

• 사용 규칙이 명확하게 정해져 있기 때문에 다른 팀원의 코드를 쉽게 읽고 이해할 수 있었어요. 문제가 발생했을 때도 수정이 훨씬 수월했답니다.

2. 재사용성

• 하위 컴포넌트를 필요할 때마다 가져다 쓸 수 있다는 점이 정말 좋았습니다. "이런 컴포넌트가 있었지!" 하며 필요한 것을 쉽게 찾아서 사용할 수 있으니 개발 속도가 확실히 빨라졌어요.

3. 체계적이고 깔끔한 구조

• 스토리북을 통해 컴포넌트를 관리하면서 느낀 것은 잘 정리된 구조가 주는 편안함이었어요. 모든 컴포넌트가 체계적으로 정리되어 있어 전반적인 파악이 용이하고, 직관적으로 이해할 수 있었어요.

4. 모듈화 레고처럼 하나씩 붙여가는 점

• 레고처럼 컴포넌트를 조합하여 UI를 구성할 수 있는 점이 정말 매력적이었어요. 각 컴포넌트가 독립적으로 존재하면서도 필요에 따라 조합할 수 있는 유연성이 주어지니, 창의적인 접근이 가능해졌어요.

👎 아쉬웠던 점

1. 러닝 커브와 초기 논의의 필요성

• 러닝 커브가 크고 사용 규칙이 구체화되지 않아 초기 단계에서 논의해야 할 사항이 많았어요. 컴포넌트를 5가지 레벨로 설정하는 것의 모호함부터 아토믹 디자인 패턴을 적용 시 발생할 수 있는 문제 해결 방법 등을 정립해야 하는 상황이 발생했어요. 애매한 상황에서는 의사결정이 필요했으며 기존 규칙에 맞추려다 보니 타협이 많아졌어요.

2. 컴포넌트 단계의 복잡성

• 컴포넌트의 단계가 불필요하게 많아지는 느낌이었어요. 예를 들어 Template과 Organism의 props가 거의 유사해지는 경우가 발생하여 이러한 세분화가 정말 필요한지에 대한 의문이 들었어요. 이로 인해 코드의 가독성과 유지보수성이 저하되는 점이 아쉬웠어요.
• 또한 상위 컴포넌트를 구현하는 과정에서 하위 레벨의 컴포넌트 설계에 문제가 있음을 발견하면, 계속 파고 들어가며 지속적으로 수정해야 하는 번거로움이 있었어요.

3. page에 주는 과도한 책임

• page가 비지니스 로직을 포함해야 한다는 점에서 책임이 무겁게 느껴졌어요. Map과 같은 컴포넌트는 이미 책임을 가지고 있는 상황에서 비지니스 로직에 대한 애매모호함도 있었죠.

4. 디자인 변경에 따른 버려지는 컴포넌트들

• 디자인이 100% 확정되지 않았을 때, 이미 구현한 컴포넌트가 쓸모없어지는 경우가 있었어요. 기존에는 컴포넌트만 수정하면 되었지만, 디자인이 바뀌면 아예 사용하지 못하게 되는 점이 아쉬웠어요.

다시 돌아간다면 이렇게 하고 싶다: 아토믹을 똑똑하게 사용하는 방법

1. 개발 전에 규칙을 최대한 구체화하기

2. 아토믹 디자인 패턴을 100% 반영하려고 하지 말기

• ex) 필요에 따라 컴포넌트 레벨 간소화하기, 비즈니스 로직 책임을 분배하기

아토믹 디자인 패턴은 과연 유용한가?

"아직은 잘 모르겠다."

• 아토믹 디자인 패턴은 분명히 고유한 장점이 있지만, 저의 생각은 이 패턴의 개념만으로는 개발을 진행하기 충분하지 않다고 느껴요. 구체적인 사용법을 정립해야 한다는 점에서, 아직 배워가는 입장보다는 전반적인 디자인 패턴과 개발 지식이 있는 상태에서 훨씬 유리하게 패턴을 활용할 수 있을 것 같아요.

• 하지만 단순히 개발에 그치는 것이 아니라, 지속적인 유지보수와 운영이 필요한 상황에서 아토믹 디자인 패턴의 진가가 발휘될 것이라고 생각해요. 따라서 앞으로 미어켓을 확장하고 유지보수하는 경험을 쌓은 후에 그 유용성에 대해 다시 평가해 볼게요.

미어켓 팀은 아토믹 디자인 패턴을 활용하여 현재 프로젝트의 컴포넌트 완성도를 높이고, 모노레포 기반의 디자인 시스템 라이브러리를 구축할 계획이에요. 이를 통해 재사용성과 일관성을 극대화할 수 있을 것으로 기대하고 있어요. 기회가 되면 추후에 디자인 시스템 라이브러리 구축기로 돌아올게요!

읽어주셔서 감사합니다! 오늘도 행복한 하루 되세요😊

해당 포스팅은 향후 프로젝트 리팩터링에 따라 지속적으로 콘텐츠가 갱신될 예정입니다.

참고한 글

Atomic Design
아토믹 디자인을 활용한 디자인 시스템 도입기
전국 각지 지구촌 구석구석에 계신 React 개발자님들! 코드에 디자인 시스템을 찍어 드셔보세요 [아토믹 컴파운드 패턴 적용기]