🌱 아토믹 디자인 도입해보기
이번에 진행하는 프로젝트에서 Atomic Design 패턴을 적용하기로 했다.
내가 아닌 팀장님이 먼저 Atomic Design을 도입하는 것에 대해서 이야기를 꺼내주었는데 나 역시 이번 프로젝트에 이 패턴을 도입해보고 싶었다.
그 이유는 이전 프로젝트를 진행할 때 기능별로 컴포넌트들을 분리해서 작성했었는데 그러다보니 같은 기능을 수행함에도 중복되어서 선언되는 컴포넌트들이 많아졌다.
그로 인해서 컴포넌트 재사용성도 많이 안좋아졌고, 또 컴포넌트들을 관리하고 유지보수하는 것이 너무 어려웠다. 결국 프로젝트 종료 후 중복되는 컴포넌트들을 리팩토링 하는 데에 시간을 꽤 소요했었다. 그렇기 때문에 이번 프로젝트에서 Atomic Design 패턴을 적용한다면 컴포넌트의 재사용성을 크게 높일 수 있을 것 같았다.
프로젝트 진행 전 카카오 기술 블로그나 Atomic Design에 대해 적용하는 글들을 읽어보았다. 대부분의 블로그에서 팀원간 Atom과 Molecule을 분리하는 데에 관점 차이로 어려움을 겪는다는 말이 많았다.
사실 당시에는 크게 공감이 가지 않았다. 당연히 Atom이 모여 Molecule가 되고, Molecule가 모여 Organism이 된다고 생각했다. 그러나 이번에 프로젝트를 진행하면서 Figma로 만든 컴포넌트들을 Atom과 Molecule, Organism으로 분리하기 위해 팀원들과 이야기를 나눌 때가 되어서야 다른 분들이 말하셨던 어려움에 공감이 가기 시작했다.
🥹 모호한 기준
위와 같은 일종의 input form이 있었는데, 사실 이런 것들을 나누는 것은 크게 어렵지 않았다. Atomic Design을 설명할 때 input form을 예시로 설명하는 글이 많아서 그런진 몰라도 당연히 Molecule라고 생각했다.
input form의 왼쪽 요소는 HTML의 input 요소와 같다고 생각해서 Atom이라고 생각했고, 오른쪽 요소는 button 요소와 같다고 생각해서 역시 Atom이라고 생각했다. 그리고 이 둘을 합친 input form은 Atom과 Atom이 합쳐졌고, 댓글을 작성한다는 하나의 책임이 존재하며 여러 곳에서 재사용이 가능하다고 생각이 들었기 때문에 이 요소가 Molecule이라는 의견에는 모두 동의했다.
그런데 위 컴포넌트를 정할 땐 의견이 많이 갈렸다. 우선 첫번째로 저 컴포넌트 안의 사진과 텍스트들, 그리고 오른쪽 더보기 버튼 각각을 Atom으로 나눠야하는가에 대해서도 의견이 분분했다. 위와 같은 컴포넌트를 어디까지 Atom으로 나눠야 하는지 기준이 모호했다.
누구는 안의 요소를 모두 Atom으로 나눠야 한다고 생각했고, 나는 몇몇 중복되는 요소들만 Atom으로 나눠도 괜찮다고 생각했다.
내가 이렇게 생각한 것이 Atomic Design 내용에 맞는진 잘 모르겠다. 그렇지만 재사용성을 위해서 Atomic Design을 적용하는 것이라고 생각했는데, 재사용이 되지 않을 것 같은 요소까지 Atom으로 만드는 것은 오히려 효율적이지 못하다고 생각했었다.
그래서 이번에 이렇게 겪은 어려움을 블로그에 작성해보며 스스로 정리해보고 프로젝트에 맞는 기준을 한번 세워보면 어떨까 하는 생각이 들어 글을 작성해보기로 했다!
🦖 기준 정의해보기
사실 스스로 기준을 정의해본다기 보단, 다른 Atomic Design에 대해 잘 설명해놓은 글을 보고 참고해서 기준을 세워보고 팀원과 이야기를 나눠보고 싶었다. 주로 카카오 기술 블로그의 글과 테오님의 글을 참고했다.
1. 어디까지 Atom으로 정의해야 하는가?
Atom은 의존성이 없고 독립적인 요소들이다.
나는 p, span, h1과 같은 요소들은 일반적으로 재사용이 되지 않는다고 생각해 atom 안에 포함하는 방식을 생각했다.
그렇지만 Atomic Design에 대해 설명한 글들을 찾아보니 이런 요소들까지 Atom으로 나누는 것이 Atomic Design 방식에서 정의한 방식이라고 생각하게 되었다.
p, span, h1과 같은 요소들도 재사용도 하려면 충분히 할 수 있다.
위 컴포넌트를 다시 예시로 들면 각각의 이미지, 이름, 반이름, 더보기 버튼을 Atom으로 정의하는 것이다.
2. Atom vs Molecule
Atom은 import가 없는 컴포넌트가 Atom이다. 만약 import 등을 이용해 외부 의존성을 갖게 되면 그 때부터 Molecule인지, Organism인지 고민을 해야 하는 것 같다.
3. Molecule vs Organism
프로젝트에서만 재사용이 가능한 요소들이다.
카카오 기술 블로그를 보면서 생각이 든 방법인데, 컴포넌트를 작성할 때 Context 없이 UI적인 네이밍으로 정의할 수 있다면 Molecule로 작성하고 이름을 정의할 때 Context가 필요하다면 Organism으로 정의하는 것은 어떨까 하는 생각이 들었다.
예를 들면 위 컴포넌트는 TextForm이라는 이름으로 Context에 대한 내용 없이 UI에 대한 이름만으로 정의할 수 있을 것 같다.
위 요소는 내가 이름을 정의해본다면 StudentInfoItem 이런 식으로 작성할 수 있을 것 같다. 이렇게 "Student"라는 Context가 들어가므로 이 요소는 Organism이라고 생각해볼 수 있을 것 같다.
만약 그럼에도 기준이 모호하다면 우선은 Organism으로 판단하고, 이후에 코드 리뷰를 통해 Molecule인지 Organism인지 결정해보면 좋을 것 같다.
🤔 추가 고민
Atomic Design은 Atom, Molecule, Organism, Template, Page로 이루어져 있지만 Template와 Page는 프로젝트에 따라 적용하지 않는 개발자 분들도 많이 보이는 것 같다.
그 이유는 Template와 Page까지 사용하게 된다면 props가 5계층을 내려가면서 전달되며 props drilling이 일어나기 때문이다. 따라서 data fetch를 Organism에서 하는 방식으로 프로젝트를 진행하는 분들이 많은 것 같다.
또한 일반적으로 웹 페이지의 Layout을 재사용하는 일은 거의 없기 때문에 Template을 이용할 필요는 없다고 생각했다.
⭐ 마치며
프로젝트를 진행하면서 팀원과 어려움을 겪었던 부분을 해결해보고 싶어서 Atomic Design에 대해서 설명해놓으신 글들을 많이 찾아보았다.
스스로가 이해해야 팀원들에게도 잘 설명할 수 있기 때문에 블로그에 팀원에게 설명을 하는 것처럼 작성을 해보았는데, 내 의견이 잘 전달되었으면 좋겠다 😭
글들을 참고하고 읽어보면서, Atomic Design에 대해 잘못 알고 있었던 부분을 바로잡을 수 있었다.
개인적으로 공부를 하며 작성한 글이라 틀린 내용이 많을 수 있습니다. 틀린 내용이 있다면 정정해주시면 정말 감사하겠습니다!
🔗 참고 링크
Atomic Design Pattern의 Best Practice 여정기
아토믹 디자인을 활용한 디자인 시스템 도입기
아토믹 디자인을 적용하고 느낀 것들
Atomic Design 설계와 Container Component
