[FE] 프론트 엔드 에서는 어떤식으로 디자인 패턴을 가져갈까?

 

목차

글작성계기

해결과정

과정에서 느낀 점

결론

 

1. 글 작성 계기

사이드 프로젝트로 현재 프런트를 하게 되었다.

아무래도 메인으로 한 번도 해보지 않은 프로젝트다 보니 우선은 단순 기능 구현에 집중을 하였다.

그렇게 생각이 드는 대로만 코드를 작성하고 개발을 하다 보니 코드의 가독성이 스스로 별로 좋지 않다고 느꼈다.

 

지금은 규모가 크지 않은 프로젝트여서 괜찮을 수도 있을 거 같은데 추후 문제 가 될 것이라 느껴졌다.

 

즉, 아키텍처 룰이 필요하다 느꼈고 어떤 룰을 정해서 해야 할까 고민을 했다.

 

 

2. 해결과정

이럴 때 가장 문제를 해결하는 법은 이러한 경험이 있는 분들에게 조언을 얻는 것이 가장 빠른 해결법이라 생각을 하여

주변 프런트 엔드 지인분에게 현재의 나의 상황에 대해 설명을 하였고 그리고 결론을 내렸다.

 

그 결론에 대해 글을 작성하게 된 것이 현재의 이 포스터이다.

 

이야기를 나누어본 결과부터 이야기하면,

 

백엔드에서 사용했던 용어인 ServiceFat이 되어있었다.

(최종적으로 문제를 해결을 하는 Service에 모든 Impl 코드들이 다 있는 것)

 

프론트에서 고객한테 최종적으로 보여주어야 할 page 부분에

모든 코드들이 다 구현이 되어있다 보니,가독성이 떨어지고 있다는 말을 들었다.

 

그럼 어떻게 이를 분리하여 관리를 해야 할까의 해결방안 중 하나로 brad frost의 아토믹 디자인을 추천 해주셨다.

 

react를 쓰는 이유 중 가장 핵심은 재사용이다.

이 재사용을 잘하기 위해서 룰을 세워야하는데(단순 혼자만 하는 프로젝트도 아니다 보니 룰이 필요)

 

가장 작은 단위에서부터 핵심적으로 합쳐지는 부분들을 만들어 공통화하는 개념이었다.

(이에 대한 상세 내용은 아래 첨부글을 참고)

 

그 개념을 듣고 이해를 했을 때 객체 지향 설계와 유사하다 느꼈다.

다만  클래스 단위가 아니라 컴포넌트로 하는 것이라는 것을 말이다.

 

그리고 각 객체 간의 의존성을 줄이기 위해 의존성 주입, 의존성 역전을 하듯

만들어진 컴포넌트들을 언제든 유연하게 사용하기 위해 headless컴포넌트를 추구해야 한다는 것을 깨달았다.

 

변경에 쉽게 대응하기 위해서는 해당 컴포넌트가 무엇을 하는지 알아야 하며, 내부와 외부에 두어야 할 것을 완전히 분리해야 한다. 외부가 변경되었다 하더라도 내부 컴포넌트가 영향을 받아서도 안되고, 내부가 수정되었다 하더라도 외부가 변경이 되지 않도록 하는 것

 

 

3. 과정에서 느낀 점 과 결론

 

프런트나 백엔드나 결국 추구하는 아키텍처는 도메인에 집중을 하는 것이며,

변경사항이 있을 때 유연하게  대체 할 수 있도록 설계 하는 것임을 깨닫게 되었다

(결국 하는 영역이 다르지 추구하는 본질은 같다)

 

 

 

---

참고 글

 

아토믹 디자인을 활용한 디자인 시스템 도입기 | 카카오엔터테인먼트 FE 기술블로그

 

아토믹(Atomic) 컴포넌트 디자인 개발 패턴

 

Headless 컴포넌트