시작하는 중
아토믹 디자인을 알아야하는 이유 본문
프론트엔드로써 프로젝트에 참여하다보면 고민이 점점 늘어난다.. 3번의 프로젝트를 react로 진행하면서 느낀 점은 다음과 같다.
1. eslint와 prettier로 코딩 컨벤션을 어느정도는 강제해야한다.
2. 폴더 구조를 어떻게 잡을 것인가가 중요하다.
3. 컴포넌트를 어디까지 쪼갤 것인가를 정해야한다.
1번과 2번은 지금 프로젝트에서는 적용했는데, 3번은 감이 안잡히다가 요새 잡히기 시작했다. 그래서 3번에 대해서 글을 써보려고 한다.
지금 진행 중인 프로젝트에서 생긴 문제이다.
두 개의 카드 컴포넌트가 있다. 좌측의 카드는 내가 보유하고 있는 쿠폰을 나타내주는 컴포넌트이고, 우측의 카드는 상점의 살 수 있는 쿠폰을 나타내주는 컴포넌트이다.
좌측은 내가 맡았고, 우측은 팀원이 맡았다. 충분히 재사용가능한 컴포넌트였지만, 서로 다른 컴포넌트를 만들며 시간적 낭비와 재사용성 있는 코드를 못하게 만들었다..
또, 서로 컴포넌트를 만드는 것도 다르다. 위의 코드를 살펴보면,
...
<section className={style.cardWrapper}>
{isCouponTitle(data) &&
data.map((title, idx) => (
// idx를 사용하지 않는 것을 권하지만, title과 함께 엮었기에 key가 중복될 일은 없습니다.
// eslint-disable-next-line react/no-array-index-key
<article key={`${title}+${idx}`} className={style.cardContentWrapper}>
<img src={`/reward/${mappingTitle[title]}.svg`} alt="" className={style.cardImg} />
<h2 className={style.cardTitle}>{title}</h2>
</article>
))}
</section>
...
이것이 내가 좌측의 컴포넌트를 만든 코드이고,
export default function GiftCard() {
return (
<div className={style.giftcard}>
<div className={style.giftimg}>
<img src="./tmpFile/tmp.jpg" alt="tmp" />
</div>
<div className={style.gifttitle}>상품명</div>
<div className={style.coin}>
<div className={style.coin_content}>
<img src="./icons/coin_color.svg" alt="coin" className="-ml-8" />
<div className="ml-5">100</div>
</div>
</div>
</div>
);
}
이것이 우측의 컴포넌트를 팀원이 만든 코드이다.
참고로 지금은 퍼블리싱 단계이며, 상태는 딱히 고려하지 않아도 상관 없다.
중요한 포인트는 같은 기능을 하는 코드들을 두개를 작성하게 된 계기와 컴포넌트를 어디까지 쪼개기 위해서 생각을 왜 다르게 했는가 이다.
특히, HTML 5의 헤더 태그 같은 것들을 제외하더라도, div를 나누는 분기점도 다르다. 코딩 컨벤션이 과연 지켜졌다고 볼 수 있을까?
이번 프로젝트를 시작할 때 우리는 1,2번을 해결하기 위해서 이야기를 했으나, 컴포넌트 단위들에 대해선 깊게 이야기하지 않았다.
우리가 이야기한 것들은 다음과 같다.
1. 폴더 구조
2. eslint 설정
3. 기술 스택 (react, ts, react-router)
이야기를 했으나, 제대로된 협의가 이뤄진 것은 하나가 있다.
컴포넌트를 어디까지 재사용할 것인가
피그마를 보며, 재사용할 컴포넌트를 따로 만들어두었다면 좋았을 것 같다.
그 예로, 내가 위에서 말한 두개의 카드 컴포넌트와 같다.
내가 생각이 짧았던 것이, 다른 컴포넌트를 피그마로 미리 살피고 팀원이 작업 중인 것을 기다렸다가 했다면 좋았을 것 같다.
하지만, 이 역시도 피그마를 보면서 같이 충분히 이야기했다면 나오지 않았을 상황이다.
다른 이유로 컴포넌트를 쪼개는 이야기를 할 때 관점이 달랐다.
어떤 의견은 하나의 태그여도 어떤 형태를 고정적으로 나타내고, 다른 컴포넌트에서도 쓰일 수 있다면 따로 빼야한다고 하였다. 그 예시 코드이다.
import React from "react";
interface Props {
size: "sm" | "md" | "lg";
}
export default function PlusButton({ size }: Props) {
return (
<button type="button" className="inline-block w-120 h-120 text-60 text-white bg-ssafveyGreen rounded-full">
+
</button>
);
}
어떤 의견은 이런 형태는 왜 사용하는지 설득되지 않는다고 하였다. 그 이유는, PlusButton을 다른 컴포넌트에서 직접 만든다면 다음과 같은 형태로 렌더링할 수 있다.
...
<button type='button' className='plusBtn'>+</ button>
...
사용될지도 모른다는 불확실한 이유로 따로 컴포넌트를 만들고 불러와야한다는 것에 대한 회의감에서 비롯된 의견이다.
즉, 컴포넌트화하는 단위에 대한 생각이 다를 수 있다는 문제가 있다
1. 컴포넌트를 어디까지 쪼개고 재사용할 것인가
2. 컴포넌트화하는 단위에 대한 생각이 다르다.
내가 프로젝트를 진행하며 느낀 문제점 두가지이다.
하지만 이미 개발자들은 이런 문제를 겪고 이런 과정들을 대처하는 설계들을 만들어두었다. 이를 통해 효율적으로 프로젝트를 진행하고자 하였다.
그 중의 하나로 아토믹 디자인이 있다.
카카오 기술블로그 - 아토믹 디자인을 활용한 디자인 시스템 도입기
카카오 기술블로그의 아토믹 디자인 관련 글이다. 여기서도 아토믹 디자인이 필요한 이유에 대해서 말하고 있다.
여기서 공감되는 내용은 명확한 컴포넌트 설계 기준 미비이다.
명확한 컴포넌트 설계 기준 미비
컴포넌트 구조 설계 시 명확한 기준이 없습니다. 팀원들 각자가 생각하는 의미있는 기준으로 컴포넌트를 나눕니다. 성격이 비슷한 컴포넌트 끼리 묶어서 아래 이미지와 같이 페이지를 여러가지 방법으로 표현할 수 있습니다.
하지만 제각각인 규칙으로 인해 관심사가 너무 많거나 재사용이나 확장할 수 없는 컴포넌트가 생기는 문제가 있습니다. 기준이 없으므로 구조에 대한 코드 리뷰를 하기 어렵습니다. 이에 따라 좋은 구조를 가진 컴포넌트를 만들기 어려운 문제가 있습니다.
정확하게 내가 진행하는 프로젝트에 너무 와닿는 말이었다.. 코드리뷰를 하면서, 왜 이렇게 작성했는지 물어보는 일이 종종 있었고, 내가 겪은 문제인 재사용할 수 있는 컴포넌트를 재사용할 수 없게 만들었다.
아토믹 디자인
이 글은 아토믹 디자인에 대한 글이 아니기에, 아토믹 디자인을 적용하며 느낀 것에 대해 살펴볼 것이다. 하지만, 다음의 글을 이해하기 위해, 간단하게 아토믹 디자인에 대해 인용글 하나로 어떤 것인지는 알아야한다.
brad frost의 아토믹 디자인은 화학적 관점에서 영감을 얻은 디자인 시스템입니다. 모든 것은 atom(원자)으로 구성되어있고 atom(원자)들이 서로 결합하여 molecule(분자)이 되고, molecule는 더 복잡한 organism(유기체)으로 결합하여 궁극적으로 모든 물질을 생성합니다. 아토믹 디자인에서는 이 개념을 차용해서 컴포넌트를 atom, molecule, organism, template, page의 5가지 레벨로 나눕니다.
아토믹 디자인을 겪으며 겪은 것들
카카오 기술블로그 - 아토믹 디자인을 겪으며 겪은 것들
알려준 대로 컴포넌트를 나누면 될 것 같지만..
아토믹 디자인을 처음 접했을 때에는 Brad Frost의 아토믹 디자인 기준대로만 컴포넌트를 나누면 되겠구나 라고 막연하게 생각했습니다. 하지만 아토믹 디자인 단위를 나누는 기준은 주관적이기 때문에 팀원 간 이 기준을 좁히는데 시간을 많이 사용했습니다. 그래서 이것에 대해 얘기해보려고 합니다.
이 인용글에 내가 생각했던 문제를 말해주고 있다. 나름대로 정의를 잡고 설득해보려고 했는데 선뜻하자고 하는 것이 쉽지가 않다. 중요한 것은 시간적 비용이다. 지금 프로젝트는 6주간의 시간동안 기획부터 개발까지 해야하는 넉넉하진 않은 시간이고, 이미 3주차가 지나는 시점이다. 그리고 퍼블리싱이 끝나가는 도중에 지금 설득하려고 하니 문제점이 보였다.
그 중에서 약간 다른 Organism에 대한 불필요 props와 분기처리에 대한 고민이 컸다.
다시 나의 예시로 돌아와서,
여기서 보면, 두개의 컴포넌트를 하나로 합치는 과정에서 당장 필요해보이는 프롭스는 2가지가 있다.
백그라운드 색과 포인트 프롭스 두개이다.
만약, 더 복잡한 로직들을 비슷한 디자인이라는 이유 하나로 하나의 컴포넌트로 묶고 해당 컴포넌트에 함수들을 막 써야할까?
하지만 이 역시도 해결책이 있다. compound 컴포넌트로 해결할 수 있다고 한다.
https://kentcdodds.com/blog/compound-components-with-react-hooks
이미 타입스크립트와 JEST를 활용하기 위해서 공부하고 취준으로 바쁜 상황 속에서 내가 이를 설득한다고 해서 좋은 프로젝트가 나올까? 하는 생각이 들었다.
결론
디자인 패턴들은 예전부터 개발자들이 겪어왔던 문제를 효율적으로 관리하기 위해 만들어진 시스템이며, 이 시스템들의 문제점들을 해결하기 위한 여러 대비책들도 존재한다.
하지만, 이 역시 설계부터 신경써야하는 것이기에 모든 것은 시간을 얼마나 사용하는가에 대한 저울질이라고 생각한다
디자인 패턴들도 공부하고 프로젝트에 적용해야하는 시간적 비용이 든다. 공부하는 것을 제외하더라도, 이런 패턴들을 고려하면서 꼼꼼하게 따져야하는 이유는 팀마다 다를 것이라고 생각한다.
reference
https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/