프롤로그

컴포넌트를 어떻게 구현하면 좋을까?
어떻게 하나의 컴포넌트가 하나의 책임만 갖도록 할 수 있을까?

1️⃣ 도메인의 흔적을 지우기

페이먼츠 미션을 예로 들면, CardInputForm이라는 컴포넌트가 있었다. 이 컴포넌트에는 도메인의 흔적이 있다. 바로 Card라는 도메인에 종속되어 있다는 점이다. 미션에서는 별 문제가 없었지만, 다른 도메인에서 이 컴포넌트를 재사용하기는 어렵다는 생각이 들었다.

이렇게 통짜로 컴포넌트를 쓰지 말자는 생각이 들었고 도메인을 걷어내 봤다. 일단 InputForm처럼 더 일반적인 형태로 바꿀 수 있다. 하지만, 도메인 이름을 제거해도 여전히 조합 형태의 컴포넌트다. 그렇다면 좀 더 작은 단위로 쪼갤 수는 없을까? 라는 생각이 들었고 더 작게 나눌 수 있었다. 예를 들어 Box, Flex, Container처럼 구조 자체에 집중한 컴포넌트 수준까지도 나눠볼 수 있다.

따라서 CardNumberInput처럼 도메인에 밀접한 컴포넌트보다는 Input처럼 보다 일반적이고 범용적인 수준의 컴포넌트로 분리하는 시도를 해볼 수 있다. 그럼 새로운 도메인에서도 여러 컴포넌트를 가져다 쓰면 되기에 문제가 없어진다.

2️⃣ 아토믹 디자인 패턴 관점에서 바라보기

하지만 무작정 작게 쪼개는 게 좋을까? 이렇게 규칙없이 반복해서 쓸 것 같으면 쪼개고 아니면 안 쪼개고 직감대로 가는 게 맞을까?

그래서 아토믹 디자인 패턴을 공부해봤다. 이 관점에서 바라보니 인터페이스를 구성하는 기본 단위를 구분할 수 있었다. 다시 말하자면, 단순히 컴포넌트를 만들 때 '일단 작게 쪼개자'는 접근이 아니다. UI를 Atom < Molecule < Organism < Template < Page 단계로 분리한다. 뒤로 갈수록 컴포넌트의 복잡도와 의존성이 증가한다.

• Atom: 인터페이스를 구성하는 가장 작은 단위의 UI 요소 (조합되지 않은 Primitive UI 컴포넌트)
• Molecule: Atom을 조합한 컴포넌트
• Organism: Molecule을 조합한 컴포넌트
• Template: Organism과 Atom을 조합한 레이아웃
• Page: 여러 Template과 Organism을 조합한 페이지

그리고 이런 생각을 할 수 있다.

컴포넌트를 나눌 때 어디까지를 가장 작은 단위(Atom)으로 볼 수 있을까? 왜 이게 Atom 단위가 돼야 하는지, Atom, Molecule 등 단위별로 어떤 책임을 줄 것인지에 대한 생각도 자연스럽게 하게 된다. 이런 생각은 각각 단계별로 컴포넌트를 나누는 기준을 세운다는 말이 되고 그래서 디자인 시스템을 일관성 있게 유지할 수 있다. 아무래도 컴포넌트를 나눌 때 규칙이 생기면 컴포넌트를 유지보수하거나 재사용할 때 용이해지긴 한다.

결론적으로 Atom의 기준은 내가 정하는 것이다. 회사에서는 아토믹 디자인 패턴에서 각 단위를 나누는 기준은 회사가 추구하는 비즈니스 가치와 도메인 컨텍스트를 함께 고려해서 정한다고 한다.

3️⃣ 미래의 요구사항에 대응하게 하기

아토믹 디자인 패턴 관점으로 컴포넌트를 구현하는 것도 좋지만,
이 방법도 좋았다. 미래의 요구사항에 대응하게 구현하는 것이다.

변화는 다양하다.

• 새로운 폴더 구조
• 상수 혹은 함수의 네이밍
• UI 요구사항
  ...

그럼 생각해보자.
내 컴포넌트는 "요구사항 변경에 얼마나 잘 대응할 수 있는가?"

기존 요구사항을 살짝 비틀어보면 더 쉽게 와닿는다.

🎯 기존 요구사항: 기본 모달을 제공한다.

🎯 바뀐 요구사항: 다양한 형태의 모달을 제공한다.

이 변화에 유연하게 대응하려면, 컴포넌트의 스코프(범위)를 명확히 하는 것이 중요하다.
다시 말해, 사용할 컴포넌트의 스코프를 어디까지 뚫어줄지에 대한 고민이 필요하다.

4️⃣ 디자인 패턴을 이용하기

그리고 나 혼자 너무 새로운 걸 만들지 않아도 된다는 걸 느꼈다. 이미 아토믹 디자인 패턴 관점에 맞는 디자인 패턴도 많다. 그래서 디자인 패턴을 학습하면 더 쉽게 학습할 수 있다. 토스에서 말하는 "바퀴부터 만들지 마세요"라는 말이 딱 맞는 표현이다. 이미 많은 사람들이 문제를 겪었고, 그걸 해결하기 위해 좋은 패턴들을 만들어놨다. 나는 그걸 보고 적재적소에 적용할 줄 알면 되는 것이다.

다음과 같은 디자인 패턴이 있다. 몇 개는 써봤고 몇 개는 아직 안 써봤다.
실제 코드에는 어떻게 적용했는지는 다음에 얘기해보겠다.

• Container and Presentational Components Pattern
• Higher-Order Component Pattern
• Render Props Pattern
• Disabled Prop Pattern
• Controlled and Uncontrolled Component Patterns

🍵 마무리

컴포넌트가 단일 책임 원칙을 지키게 하라는 말이 처음에는 정말 막연하게 들렸다. 컴포넌트는 UI를 그려주는 일을 주로 하기 때문에, 그럼 UI를 그리는 일 말고 다른 일은 전부 어디론가 책임을 이동시키라는 건가? 싶었다. 그래서 막연했다. UI를 그릴 때도 어떤 걸 그리느냐에 따라 책임이 커질 수 있어서, 단순히 그려주기만 해도 안됐다.

근데 이렇게 도메인 흔적을 지워보며, 아토믹 디자인 패턴 관점에서 또 디자인 패턴도 써보면서 이런 식으로 하면 조금씩 컴포넌트가 나만의 기준을 가지면서 하나의 역할을 할 수도 있겠다는 생각이 든다.

이번 글에는 코드에 대한 예시가 없는데, 다음 글에 코드를 가지고 설명해보겠다.