운좋게 우테코 크루들과 컴포넌트에 대해서 토론 할 수 있는 기회가 생겼다.
토론은 당일날 진행했던 수업 내용과 관련된 것이었다.
수업에서는 아래 사진처럼 사람 프로필 / 그룹 프로필이 함께 렌더링될 때 컴포넌트를 어떻게 분리해볼지에 대해 이야기하는 것이었다.
결론만 간략히 말하자면, 사람 프로필과 그룹 프로필은 보여주고자 하는 데이터와 책임이 다르다. 사람을 표현하는 컴포넌트와 그룹을 표현하는 컴포넌트는 서로 다른 도메인 지식을 가지기 때문에 1개의 컴포넌트로 묶지말고 2개의 컴포넌트로 나눠야 한다는 것이었다.
도메인이 다르므로, 앞으로 UI가 다르게 발전할 가능성이 높다
토론 주제는 이 결론에 대한 것이 아니었다. 컴포넌트는 분리하지만, 이를 공통 Layout으로 묶어도 되는가? 이것이 우리의 논쟁거리가 되었다.
나는 Layout 컴포넌트를 깊이 생각하며 나눠본 적은 없기 때문에 처음에 든 생각이 하나 있었다.
"기껏 다르게 발전할 가능성이 높아서 2개의 컴포넌트로 나누어 놨는데, 이걸 다시 1개의 Layout으로 묶으면 그게 무슨의미이지? 2개중 1개라도 바뀌게 되면, 만들어놓은 Layout이 의미가 없어지고 새로 만들던가 해야될텐데 굳이 Layout을 만들어야 하나?"
나는 여기서 성급한 추상화(AHA)를 떠올릴 수밖에 없었다. 쉽게 말하면 당장 공통으로 묶을 수 있어도 묶지 말라는 말이다.
수업에서 우리는 1개의 컴포넌트로 묶지 않고, 2개의 컴포넌트로 분리를 잘 해냈다. 성급한 추상화를 하지 않은 것이다. 그런데 이 논리대로라면, 이 2개의 컴포넌트의 공통 Layout을 만드는 것 또한 하지 말아야 할 행동이다.
그래서 나는 이 Layout 컴포넌트를 적용하려는 크루들을 보며 잘 이해가 되지 않았다.
하지만 지금의 나는 어느정도 정답을 찾은 것 같다.
내가 놓치고 있던 부분이 있었다고 생각하고, 그것이 "변경의 이유"라고 생각한다.
<UserProfile />이라는 도메인과 결합되어 있는 컴포넌트가 존재한다면, 이 컴포넌트의 변경의 이유는 User 도메인이다. User 도메인은 해당 컴포넌트의 UI가 될 수도 있고, Data 구조가 될 수도 있다.
<Stack />이라는 컴포넌트에 대해 이야기 해보자, "무언가를 쌓는다"라는 의미만 존재할 뿐이다. 가로가 될 수도 있고, 세로가 될 수도 있지만 무언가를 쌓는다는 의미는 변하지 않는다.
온전히 Layout적인 의미만 담고 있기 때문에 Stack 컴포넌트의 변경의 이유는 Layout 자체 규칙이다. 그리고 이 규칙은 거의 변하지 않는다.
물론 여전히 이런 생각은 가지고 있다.
두 곳에서 공통 Layout을 하나 추출했다가 한 곳이라도 Layout이 달라지면 나머지 한 곳에서만 쓰이는 Layout이 될 텐데 자원낭비 아닌가?
하지만, Layout적인 의미를 담고 있으므로 홀로 존재해도 괜찮다고 생각한다.
또한 공용 레이아웃이므로 도메인과 결합된 컴포넌트보다도 더 자주 사용될 가능성이 높다.
지금 드는 생각으로는
"Layout 컴포넌트를 한 곳에서만 쓰고있네 너무 아깝다.."라는 생각은 마치 HTML 개발자가
"내가 기껏 만든 semantic 태그를 한 번밖에 쓰지 않다니.. 아쉽군"이라고 말하는 것과 거의 유사하다고 느껴졌다.
Layout 컴포넌트를 만들 때 주의할 점이라고 한다면, 도메인 지식을 최대한 배제시켜야 한다는 것이다. 도메인과 결합된 Layout은 사실상 도메인 컴포넌트라고 생각한다. 그리고 그 도메인 컴포넌트는 결국 성급한 추상화를 해버린 것이다.
여기서부터는 본문과 크게 관련 없는 말이지만 성급한 추상화에 대한 나의 생각을 정리해보고자 한다.
성급한 추상화를 매우 싫어하지만, 그 규칙이 3번이 반복되면 그때는 추상화를 해도 된다는 주의이다.
Rule of Three라는 말도 있고, 3개가 모이면 패턴이 된다라는 말도 있듯이 3번 반복부터는 추상화를 하지 않았을 때 감당해야 할 유지보수 비용이 더 커진다고 생각한다.
군중심리도 3명부터 시작한다는 실험 결과가 있다.
마침 오늘 축구 경기장에서 관중 3명이 물타기를 시작해서 그게 전 축구장으로 이어진 영상을 봤다.
그래서 이 3이라는 숫자가 더 와닿았던 것 같다. 😅
