React 아키텍쳐, 디자인 시스템, 파일 구조에 대한 고찰

 

반년일기 사이드 프로젝트를 진행하면서 리액트에 대한 한계점에 매일 매일 도달했다.

무엇보다 퍼블리싱과 기능 구현을 동시에 진행하려는 욕심에,

대충 짜놓았던 디렉토리 구조가 무너지는 느낌,  가뜩이나 어수선한 프로젝트가 더 어수선해지는 기분이었다.

그때 현 회사 사수가 디자인 시스템에 대해 꼭 공부 할 필요가 있다고해서

무작정 코드부터 작성하려는 급한 마음을 잠시 내려놓고,

아키텍쳐, 디자인 시스템을 기반으로 리액트 디렉토리 구조를 어떻게 하면 좋을지에 대해 공부를 해보려고한다

 

 

---

 

 

1. 현재 상태

아래 이미지는 현재 플젝 리액트 디렉토리 구조다

반년일기 프로젝트 디렉토리 구조

가장 크게 client, db, doc, server로 나눈 상태고 나는 client를 담당하고 있다

client의 핵심 상위 폴더는 assets, components, router이다

반년일기 프로젝트의 assets 폴더, router 폴더, components 폴더 구조

생각없이 짠 구조는 아니고 나름 취준시절 니꼬의 리액트 네이티브 무비앱 유료강의를 들었던 그때 그 디렉토리 구조를 반영한거다....

그러나 이 구조는 음.......... 현재 프로젝트와 안 맞는 느낌이고 무엇보다 저 구조로 작성했던 시절이 벌써 1년전이다

그리고 기능 구현에 급급하다보니 구조가 무분별하게 꼬여있다 서로 뒤엉킨 느낌........?

그래서 그런지 가뜩이나 코딩하는데 어수선한 마음이 더 어수선해지는 기분이더라.....

사수가 리액트의 디자인 시스템은 뜨거운 논쟁중의 하나이기도 해서 정답은 없지만 더 좋은 형태는 있다고 해서...

이 참에 좋다는 영상과 글들 읽어보면서 분석도 하고 후기도 써보면서 우리 프로젝트에 어떻게 반영할지 고민해보려고 한다

 

 

 

2. 다양한 디자인 시스템 정보에 대한 고찰

사실 개발 첫 입문시!

구글에 디자인 시스템을 쳐봤을때 가장 먼저 뜨는 내용들은 하나같이 디자이너 입장에서의 디자인 시스템이었다

그래서 사실 나는 개발자와는 연관이 없는 분야군 (...) 하면서 넘겼었다.....

일단 '개발자 디자인 시스템' 이라고 치면 가장 먼저 뜨는 글을 읽어보았다

https://simsimjae.medium.com/%EB%94%94%EC%9E%90%EC%9D%B8-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%ED%95%84%EC%9A%94%EC%84%B1-2d76d424ac03

디자인 시스템의 정의와 필요성

일단 이 글에서 디자인 시스템은 매우 많은 것들을 포함한 영역이고,

그 안에 작은 단위의 스타일 가이드, 그리고 그 작은 단위를 합친 컴포넌트 단위를 말하는 느낌이다

(여기까지는 내가 회사에서 자사 스타일 가이드를 만들면서 들었던 내용과 일치한다)

한마디로 디자인 시스템을 잘~ 도입해서 하나만 제대로 따악! 만들어 놓으면

여기저기 재사용이 가능해서 디자이너, 개발자들에게 매우 편리하다인데.....

마치 리액트의 컴포넌트가 추구하는 방향(?)과 일치하는 것 같다

그래서 유독 리액트에서 디자인 시스템이 뜨거운 논쟁인건가? 싶기도....

 

https://blog.gangnamunni.com/post/welchis/

개발자 여러분, 디자인시스템 지금 바로 도입하세요!

강남언니 기술 블로그에서 작성한 글도 읽어봤다

확실히 모두 재사용성에 큰 의미를 두고 있고 하나같이 스토리북이란걸 사용하고있다

 

https://story.pxd.co.kr/1434

디자인 시스템 1편 - 디자인 가이드/디자인 시스템은 왜 필요한가

위 글에서 전반적인 디자인 가이드와 시스템에 대해 폭넓게 알려주고 있다

 

https://team.modusign.co.kr/%EC%9E%98-%EC%82%AC%EC%9A%A9%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EB%A7%8C%EB%93%A4%EA%B8%B0-7387b40f547a

“잘” 사용할 수 있는 디자인 시스템 컴포넌트 만들기

요즘 엄청 떡상중이라는 모두의 싸인...

여기에서는 리액트에 디자인 시스템을 어떻게 사용했는지 예시를 들어준다

 

https://beige22.medium.com/%EC%BD%94%EB%93%9C%EB%A1%9C-%EB%A7%8C%EB%93%9C%EB%8A%94-design-system-b04bb916a02b

코드로 만드는 Design System

위 글을 읽어보니 리액트에서는 버튼 하나를 만들때도 모듈화 하나보다....

그리고는 스타일을 변수로 받는 것 같은데 내가 기존에 알고있던  styled-components에서 props로 받는 것 보다 더 복잡해서 굉장히 놀랬다.... 이런거 처음 본다....

아이콘이 어느 위치에 있든, 아이콘만 있든, 텍스트만 있든 간에 여백 크기도 적절하게 배분되는게 굉장히 신기했다

보니까 스타일 props를 className에 동적으로 넣어서 미리 작성해논 scss를 오버라이딩? 상속? 하는 개념같다

이런 구조는 최소 기획자 1, 디자이너 1, 퍼블리싱에 빠삭한 프론트엔드 개발자 1 정도는 있어야지 구축 가능한 시스템 같다...

기준과 컨셉을 애매하게 잡고 시도했다가는 시간에비해 아까운 구조만 남길거같은 느낌....

 

 

 

3. 리액트 디자인 패턴

https://velog.io/@holim0/React-Design-Pattern

React Design Pattern 🎨

리액트 디자인 패턴이라고 검색하면 가장 먼저 뜨는 게시물이다

그 외에도 대부분의 블로그  글에서는

• 데이터 처리 → Container (리덕스나 State, API 호출 등 로직 처리를 담당 그리고 그 값을 Props를 통해 Presenter에 전달)
• 데이터 출력 → Presenter (오직 Props를 통해 전달받은 데이터를 화면에 출력)
• UI를 담당하는 → Components

이렇게 3가지를 분리해서 작성하라고 가이드한다

 

https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

Presentational and Container Components

리액트 창시자가 작성한 글

위 포스팅이 뭔가 Container VS Presenter의 뜨거운 논쟁이 있었던 느낌인데............

영어를 못하니까... 번역체도 좀 이상해서 뭐라는지 모르겠다😭😭

그 후 좀 더 찾아보니 단순 Container, Presenter 파일을 분리하는 패턴은 Hook이 생기기 이전에 흥행한 방식같다

그럼 Hook이 생기고서는 뭐가 대세일까? 대세는 모르겠지만 VAC 패턴이란걸 발견하게 되었다

 

3-1. VAC 패턴

https://wit.nts-corp.com/2021/08/11/6461

React에서 View의 렌더링 관심사 분리를 위한 VAC 패턴 소개 | WIT블로그

위 글에서 VAC 패턴은 FE 개발자와 UI 개발자(웹퍼블리셔) 사이의 협업 문제를 줄일 수 있는 패턴이라고 소개해준다

VAC 패턴의 특징

1. 반복이나 조건부 노출, 스타일 제어와 같은 렌더링과 관련된 처리만을 수행한다
2. 오직 Props를 통해서만 제어되며 스스로의 상태를 관리하거나 변경하지 않는 stateless(무상태) 컴포넌트이다
3. 이벤트에 함수를 바인딩(하나를 다른 것으로 매핑시키는 것을 의미)할 때 어떠한 추가 처리도 하지 않는다
4. VAC는 state를 가질 수 없지만 state를 가진 컴포넌트를 자식으로 자기는 것은 가능하다. 이 경우 VAC는 부모 컴포넌트와 자식 컴포넌트 중간에서 개입하지 않고 단순히 props를 전달하는 역할만 한다

// Props Object 정의
const SpinBox = () => {
	const [value, setValue] = useState(0);

	// JSX를 추상화
	const props = {
		value,
		onDencrease: () => setValue(value - 1),
		onIncrease: () => setValue(value + 1),
	};
	
	// JSX 
	return <SpinBoxView {...props} />;
}


// JSX를 VAC로 분리
const SpinBoxView = ({value, onIncrease, onDecrease}) => (
	<div>
		<button onClick={onDecrease}>-</button>
		<span>{value}</span>
		<button onClick={onIncrease}>+</button>
	</div>
);

위 예시도 말만 다를뿐이지 Container, Presenter 개념을 나눠서 분리 작성한거 아닌가...? 싶다

왜냐면 니꼬 강의 들었을때 딱 저 패턴으로 작성했어서... 흐으으으으음....

딱히 색다로운 방식이라는 느낌이 안드는데 내가 잘 모르는건가 싶다

근데 다른 예시를 들어주니 딱 이해가 갔다

예를 들어 SpinBox의 최소 값을 0 이하로 설정할 수 없는 조건과 증가, 감소 버튼을 둥글게 처리하는 디자인 수정이 발생한다면?

FE개발자는 Props Object의 onDecrease를 수정하면 되고 웹퍼블리셔는 VAC에서 className을 추가하든 style 속성을 추가하면 된다.

그럼 서로 수정한 파일이 다르니 충돌이 안 일어난다는 것!!

그리고 Container, Presenter 와 차이를 막판에 설명해주는데 이해가 간다

개인적으로 개념이 완벽히 분리된듯한 VAC 패턴이 마음에 든다

💥 VAC 잘못된 예시

View 컴포넌트의 기능이나 상태 에저에 VAC가 관여해서는 안된다 (아마 이벤트에 파라미터도 설정하면 안된다는 말 같다)

그리고 위 블로그 글에서 잠깐 언급된 BLoC 패턴이 있길래 알아봤다

 

3-2. BLoC 패턴

https://pks2974.medium.com/bloc-%EC%9D%B4%ED%95%B4-%ED%95%98%EA%B8%B0-%EB%B0%8F-%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC-%ED%95%98%EA%B8%B0-7dc705e4c640

BLoC 이해 하기 및 간단 정리 하기

https://github.com/sbyeol3/articles/issues/15

[번역] React에서 BLoC 패턴 사용하기 · Issue #15 · sbyeol3/articles

와 이건 생각보다 더 어려운 구조같다 React에 적용한 예시가 있는데... 정말 간단한 코드같은데 내 기준 코드의 가독성이 안좋은 느낌이다ㅠㅠㅠ 뭐라는지 모르겠다....

개인적으로 자바 코드 보는듯한 느낌이 든다

리액트를 다양하게 고오급 스킬을 사용해본 사람이나 좀 이해가 갈듯한......

이게 Redux 흐름과 비슷한편이라서 적용해보면 좋을거 같은데 Redux를 모르는 내가 당장 쓰기에는... 여러모로 시간이 많이 필요한 패턴인거같다

 

3-3. 아토믹 디자인

https://ui.toast.com/weekly-pick/ko_20200213

리액트 어플리케이션 구조 - 아토믹 디자인

아토믹 디자인은 회사에서 처음 접하게되어서 익숙하게 알고있다

현재 이 방식으로 자사 common style을 구축하려고 밑바탕 작업을 해논 상태이다(?)

근데 현재 자사 서비스가 리액트로 갈것인가 자바로 갈것인가에따라....

내가 만든 common style의 규모가 달리할거같다..........

쨌든 이런식으로 작업을 해봐서 익숙하고! 이게 얼마나 좋은 디자인 시스템인지 몸소 느꼈었다

체계적으로 작은단위부터 관리할 수 있어서 참 좋은데 문제는 초기에 생각하는 시간을 엄청나게 잡아먹는다는 것이다...ㅋㅎ

 

 

 

4. 디렉토리 구조

https://www.stevy.dev/react-design-guide

리액트 설계 가이드

위 글에서 매우 다양한 프로젝트 구조 설계 패턴을 제시해주고 있다

제시한 구조 중에서 실제 회사에서 쓰고 있는 구조랑 비슷한 구조가 있었다

그리고 여기서도 아토믹 디자인 이야기가 빠지지 않는다

https://isa-dev.tistory.com/9

프론트엔드 설계 및 디자인 패턴

여기에 플젝 폴더명이 무엇을 의미하고 어떻게 짜면 좋은지 간결하게 설명해놨다

 

 

 

5. 바꾼 결과

일단 크게 assets, components, pages, utils로 나눴다

src/assets/

assets폴더에는 정적 파일들이 위치해있다

src/components/

components에는 아토믹 디자인 구조를 적용해봤다

다른점은 templates 부분이 없고 layout 폴더가 있다

규모가 큰 프로젝트가 아니다보니 templates 컴포넌트까지 나오지도 않고, layout 관련 컴포넌트들을 templates에 포함시킬까? 하다가 의미가 너무 안맞는 느낌이라서 그냥 layout 폴더를 만들었다s

src/pages

그리고 routes 폴더를 싹 갈아엎었다

일단 pages로 변경하고 페이지마다 폴더를 각각 생성해줬다

그리고 각각 페이지별로 적용되는 hook과 api 로직을 분리해서 작성해주려고한다

그래서 페이지 안 폴더도 쪼개야하나..? 싶은데 의미가 맞는게 딱히 없는 느낌이라.... util도 아닌거같고... hook이라기엔 custom hook을 쓰게될지 말지 잘 모르겠고.... 그래서 일단은 냅뒀다

src/utils

전역적으로 쓰이는 회원 인증 로직, 인증 라우터는 어떻게 둬야하지? 싶었다

다들 전역적으로 쓰는 컴포넌트는 utils로 퉁 치는 것 같길래 일단은 나도 그 구조로 해놨다

근데 찰떡같이 맞는다는 느낌은 안들어서... 또 수정될수도 ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ

 

 

 

 

6. 마무리

현재는 이렇게 구조를 가져갈 생각이고

이 부분은 경험에 따라, 취향에 따라 많이 바뀔 수도 있는 부분이라

이 디렉토리 구조가 언제까지 갈지는....ㅋㅋㅋㅋ 잘 모르겠다ㅋㅋㅋㅋㅋㅋㅋㅋ

디자인 패턴에 대해 꾸준히 습득하는게 좋을거 같다