원문 출처 : https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/
아토믹 디자인을 활용한 디자인 시스템 도입기 | 카카오엔터테인먼트 FE 기술블로그
정호일(harry) 카카오페이지에서 웹 프론트엔드를 개발하고 있습니다. 집보다 밖에 돌아다니는 걸 좋아합니다.
fe-developers.kakaoent.com
이전 카카오의 아티클에서 아래와 같은 문구가 있었다. ' 디자인 시스템을 구축하면 응집도 높은 UI 컴포넌트들이 도출됩니다. 이렇게 도출된 컴포넌트를 개발에서 그대로 사용하기 위해 아토믹 디자인을 차용했습니다.' 결국 관심사를 분리하기 위해선 좋은 설계가 뒷받침 되어야 한다. 이런 아토믹 패턴은 좋은 설계를 돕는 툴이며, 카카오페이지에서는 어떻게 사용했는지 관심이 생겨서 읽게 되었다.
아티클 내용
해당 아티클은 Atom, Molecule, Organism, Template, Page 에 대해서 우선 설명해줍니다.
Atom : atom은 더 이상 분해할 수 없는 기본 컴포넌트입니다
Molecule : molecule은 여러 개의 atom을 결합하여 자신의 고유한 특성 가짐
Organism : organism은 앞 단계보다 좀 더 복잡하고 서비스에서 표현될 수 있는 명확한 영역과 특정 컨텍스트를 가짐
Template: 템플릿은 page를 만들 수 있도록 여러 개의 organism, molecule로 구성할 수 있음
page : 유저가 볼 수 있는 실제 콘텐츠를 담고 있음
정의 잘 되어있지만 이를 실제로 적용해보려 하면 간혹 모호함이 생깁니다. 이에 대해서
1. Molecule과 Organism 을 나누는 기준의 주관성
2. Organism을 나누는 기준
3. 약간 다른 Organism이 있을 때 중복 컴포넌트가 생기거나 불필요한 Props의 증가
에 대해서 예시를 들며 설명해줍니다.
개인적으로는 해당 아티클에서도 Input의 경우에는 왜 Atom이 아니라.. Molecule일까?? 이런 고민도 했었고,
Molecule중에서도 크기가 동일하진 않은데, 좀 더 복잡하고 서비스에서 표현될 수 있는 명확한 영역과 특정 컨텍스트의 기준은 무엇일까??
그에 대한 고민을 우려해선지 각각의 요소에 대해서 설명하면서 , ' 아토믹 디자인의 각 단계는 선형(linear) 프로세스가 아 이렇게 스텝 별로 나아가는 방법론이 아닙니다.' 또한 brad frost의 아토믹 디자인 플로우 에서 팀원들과 페이지의 스크린샷을 찍고 고유한 UI 패턴을 카테고라이징하는 과정에 대해서 언급해줍니다.
아마도 중요한건 주관적인 부분에 대해선 완벽히 해결할 순 없어도,, 아토믹하게 나눌려 했고 이 과정에서 서로 합의하고 카테고라이징 하는 것 아닐까요?
또한 아토믹 패턴을 사용하면서도 style같은 경우엔 외부에서 주입하고, 컴퍼넌트를 제어하는 요소도 외부에서 주입하는 방식으로 유연성을 늘리는 방식을 사용하고 있다고 말합니다.
또한 아토믹 패턴은 단순히 프론트엔드가 도입하는 패턴이 아니라 , 디자이너가 작성한 피그마 컴포넌트(디자인 시스템)를 원천으로 소통에 도움을 주는 요소라고 말합니다.
느낀점
작년에 디자이너가 없는 프로젝트에서 아토믹 패턴을 도입하려고 했었습니다. 그 당시에 다른 아티클을 보고 아티클 패턴은 어떻게 사용하는지에 대해서만 읽었었는데, 실제로 도입하기에 굉장히 모호하다고 느꼈었습니다.
컴퍼넌트는 기능에 따라 비슷해 보이지만 다르고,, 어디까지 같다고 분류해야 할까..?
결국 복잡도와 크기에 따라서 atom, moluecule, Organism을 분류하는데 기준이 개개인마다 다른데 어떻게 하지..?
부트캠프에서 진행하는 프로젝트인데 괜히 너무 많은 내용을 도입하려 해서 개발 비용만 증가하는게 아닌가??
이런 고민을 하다 결국 도입을 하지 않았습니다. 지금 생각해보면 어느 정도 핑계도 있지 않았나 싶고,, 위 아티클을 읽고 피드백된 내용은 아래와 같습니다
1. 설계가 꼼꼼하지 않아서 더욱 모호했다.
설계를 세세히 했고, 와이어프레임을 좀 더 구체적으로 그렸다면 개개인의 모호함을 팀적 합의로 해결할 수 있었을 겁니다.
2. 외부에서 주입하는 방식에 대해서 깊게 생각하지 못했다.
외부에서 스타일이나 기능을 제어한다면 좀 더 재사용성이 높기 때문에, 쪼갤만한 컴퍼넌트의 단위가 많았을 거 같다고 느꼈습니다.
'공감이 간 아티클' 카테고리의 다른 글
파일 변수 Deep-Dive[카카오 FE 블로그] (0) | 2024.08.13 |
---|---|
가독성 좋은 코드와 코드 품질에 대하여(Toss의 모닥불) (0) | 2024.06.20 |