2022. 10. 31. 11:18ㆍ일상
이 글은 [WOOWACON 의 배민 커머스 프론트엔드의 진화]
세션을 보고 정리한 글입니다.
해당 세션은 크게 2파트로 나뉘어졌습니다.
첫번째 파트로 배민커머스 프론트엔드 파트의 성장과정을 보여주며 시기에 따라 3개의 세부적인 내용으로 나누었습니다.
- 프론트엔드의 환경구축
- 리액트로의 점진적인 환경의 변화
- 완전한 리액트 이관
두번째 파트로 안정적인 프론트엔드팀에 대하여 필요한
조직문화나 개발문화 그리고 업무프로세스에 대해 설명해줬습니다.
Atomic Design과 Container-Presentational
배경
초기의 배민 커머스의 경우 "도메인 단위 컨포넌트"
로 구성되어 있었습니다.
이로인해 한눈에 기능이 확인이되는 장점이 있었지만, 규모가 어느정도 커지게 되면 중복된 로직이 많아지며 얻었던 장점을 잃어버리게 됩니다.
이를 통해서 "도메인 단위 컨포넌트"
사용에 대해서 이렇게 정리됩니다.
- 프로젝트 하나, 5개 페이지 미만의 ‘시작지점’의 프로젝트에 적합한 구조
- 다양한 페이지에 대해서 중복 로직을 수정하려면 비효율적이다.
- 규모가 커지면서 로직과 레이아웃에 섞이게되어 코드를 파악하기 힘들다.
해결책
- 컴포넌트와 비즈니스 로직을 분리하자! →
"Container-Presentational"
- 재사용성과 확장을 위한 레이아웃의 분리가 필요하다! →
"Atomic Design"
Atomic Design
Atomic Design
프로젝트 내에서 컴포넌트 계층을 쉽게 나눌 수 있는 디자인 시스템 방법론 중 하나입니다.
Atom, Molecule, Organism, Template, Page 으로 나눠집니다.
Atom
- 더 이상 세분화할 수 없는 UI 요소
- label, input, button과 같이 기본 HTML element 태그 혹은 글꼴, 애니메이션, 컬러 팔레트, 레이아웃과 같이 추상적인 요소
- 인터페이스의 기본 빌딩 블록 역할을 합니다.
- 추상적인 개념을 표현하는 요소입니다.
Molecule
- 비교적 단순한 UI 구성 요소를 형성하는 원자의 집합
- 고유한 특성을 가지게 되며 한 가지일을 하게 됩니다.
- 단일 책임 원칙(Single Responsibility Principle)
Organism
- 인터페이스의 개별 섹션을 형성하는 비교적 복잡한 구성 요소
- 서비스에서 표현될 수 있는 명확한 영역과 특정 컨텍스트를 가집니다.
- 구체적으로 표현이 되지만 그만큼 재사용성이 낮아집니다.네이버의 검색 헤더
Template
- 레이아웃 내에 구성 요소를 배치하고 디자인의 기본 콘텐츠 구조
- 실제 컴포넌트를 레이아웃에 배치하고 구조를 잡는 와이어프레임
Page
- 실제 콘텐츠를 템플릿에 적용하고 변형을 명확하게 표현하여 최종 UI를 보여줍니다.
- 디자인 시스템의 탄력성을 테스트합니다.
- template 의 인스턴스
- 예시
장점
- 추상적인 요소와 구체적인 요소간 이동이 빠릅니다.
- 컴포넌트의 재사용성이 높아집니다.
단점
- 미세한 UI 변화를 적용시키기 어렵습니다.
- 컴포넌트가 분리되어있으며 상위 컨테이너 컴포넌트의 사이즈를 결정할수 없다면, 미디어 쿼리를 사용하기 어렵습니다. → 이는 flex, grid 처럼 css속성을 구현한 레이아웃 컴포넌트를 도입해야합니다.
※ Atomic Design 적용 시, 고려해야되는 점
컴포넌트를 나눈다고 되는게 아니라 디자인 단위를 나누는데 기준을 명확히 정해야합니다.
1. Molecule과 Organism의 기준
- Organism은 layout 영역과 컨텍스트를 갖습니다.
- Molecule은 컨텍스트 없이 UI적 요소로 SPR을 지킬수 있습니다.
2. Organism을 나누는 기준
- organism은 명확안 영역을 가지고 있기때문에 이에 대한 기준도 주관적입니다.
- 만약 영역이 세부적으로 나눠진다면, 공통된 컨텍스트를 묶어서 organism 컴포넌트로 표현할수 있습니다.
3. 중복 컴포넌트
- 비슷한 컴포넌트를 만들게되는 상황이 있습니다. 이 경우 compound 컴포넌트를 활용할 수 있습니다.
- compound 컴포넌트?
- 컴파운드 컴포넌트 패턴은 하나의 완벽한 컴포넌트를 구성하는 암시적 상태 공유 컴포넌트 API 집합을 제공하는 방법입니다.
- 리액트 디자인패턴 : Compound Components (컴파운드 컴포넌트 패턴)
이는 카카오 페이지에서 아토믹 디자인을 적용하면서 겪은 일을 참고했습니다.
Container - Presentationals
Container - Presentationals
레이아웃 요소와 비즈니스 로직을 분리합니다
이제 react16.8에서 Hooks를 통해서 구현이 가능하며 임의의 분할 없이 작업이 가능합니다.
- Container 에는 비즈니스로직 → stateful한 경향을 가짐
- Presentationals에는 레이아웃 → stateless한 경향을 가짐
장점
- 더 나은 관심사 분리가 가능해집니다. 구성요소에 대한 이해가 높아 집니다.
- 더 나은 재사용성을 가질수 있습니다.
- Markup 작업이 편합니다.
- Presentation 구성요소를 통해 앱의 로직을 안건들고 변형을 조정할 수 있습니다.
단점
- 각각의 컴포넌트마다 분리를 진행하는 것은 각각의 기능을 따로 관리하는 것보다 매우 복잡합니다.
- 이는 오히려 가독성을 떨어뜨리며 유지보수가 힘들어집니다.
etc..
이 패턴을 소개한 Dan Abramov이 이제는 이 방식을 추천하지않는데, 자연스러운 코드베이스로 따라가는 것이 아닌 의도적으로 필요성없이 맹목적으로 따라가는 모습이 많이 보였다고 합니다. 하지만 자주 거론되는 패턴으로서 알아두면 좋다고 생각합니다.
배민 커머스의 적용결과
컴포넌트를 먼저 Container 와 Presentaionals로 두계층으로 나눠지게 되며
컨테이너에서는 로직을 분리해서 전달함 → Presentaionals는 오로지 순수한 레이아웃을 맡게 됩니다.
추가적으로 Container에서 바로 Template 만으로 데이터를 전달하는것이 아닌 Organisms 와 Molecules 로도 전달을 합니다.
참고 사이트
Vue에서 React로의 변화
현업에서 기술의 변화가 왜, 어떻게 이뤄지고 적용되는지 볼 수 있어서 흥미가 있었습니다.
무작정 기술적으로 안정성이나 성능이 좋은 것을 고르기보다 채용같은 현실적인 이유도 고려하는게 인상깊었습니다. 그리고 무엇보다 팀원의 기술 숙련을 고려하며 SSR 적용을 React + Loadable Component로 진행한 점이 기억에 남습니다.
고려요소
- 현실적인 관점
- 시장에서 사용되고 있는 기술인지?
- 사용되는 기술의 커뮤니티의 크기는 어떠한지?
- → 이는 프로덕트의 지속가능성에 크게 영향을 끼친다.
- 기술적인 관점
- Vue에서 리액트로 포팅이 될것인가?
- 현재 아키텍처를 구현할 수 있는 리액트 문법이 있는지?
- 어떠한 범위부터 이관할지?
- CRA? NEXT?
- 상태관리 라이브러리는 어떤걸?
과정
1. 초기 프로젝트
- CRA를 통해서 상태나 비즈니스가 존재하지 않는 상품도메인을 대상으로 진행
- 페이지가 빠르지 않아도되니 SSR 은 사용 X
- 추가 챌린지로 타입스크립트를 적용
- 비즈니스 관련된 파트를 개선해나가며 숙련도 향상
- 커스터 훅을 통해서 계층분리 진행
- 공통 커스텀 훅과 모델을 조합한 페이지에서 1:1 대응되는 비즈니스 커스텀 훅을 만듬
2. Vue → React 마이그레이션 작업
- 정해진 아키텍처는 이미 있음으로 폴더 수정 진행
- 컴포넌트를 리액트화
- watch, computed비동기 로직중 메모이제이션이 필요한 부분을
- useMemo, useCallback등으로 변경
- vuex → redux로 변경
- watch, computed비동기 로직중 메모이제이션이 필요한 부분을
3. React+ SSR 진행
- 장점
- 핫한 트렌드의 주제 → 채용에 이점
- 더 빠른 fcp
- 노드서버를 통한 브라우저를 포함한 개발 선택지 확장
- 단점
- 노드서버 모니터링, aws 유지보수등 프론트할일이 늘어남
- 이미 SPA로 개발하거나 웹팩 커스텀빌드를 하면 50ms내 제공이 되기 때문에 굳이 할 필요없는 업무
- 선택지
- React + Loadable Component
- 웹팩 커스텀 설정 및 Loadable Component로 Hydration 시키기
- 많은 설정 필요, 정보 많이 없음
- 노드 서버 설정도 직접 해야함
- Next.js
- 프레임워크로써 이미 보장된 기술을 사용
- 많은 설정을 사용하지 않아도 간단하게 사용 가능
- 노드 서버 설정도 어느정도 지원
- React + Loadable Component
→ SSR 기술을 근본부터 설정해보고 이점을 찾기위해 Loadable Component 를 선택함
→ 근본을 공부하는 것이 프로덕트 규모가 적을때는 유효하며, 서비스가 크면 안정적인것으로 교체가 맞음
→ 현재 Next.js 교체된 상황
프렌젠테이셔널 계층개선
문제
각 프로젝트마다 상황이 달라서 일관적인 적용이 어려우며 그리고 매번 디자이너와 상의하는건 불가능
해결
→ 디자이너와 최소단위로 논의하는 범위를 정해서 분리관리하는게 낫겠다.
→ Molecules / Atoms 를 분리하여, 디자인 시스템으로 명칭하고 사용하기
디자인 컴포넌트 라이브러리 적용을 통해서 관심사 분리 및 레포지토리 단위 중복코드 개선
현업에서의 프론트엔드의 프로세스
이번 세션을 들으면서 좋았던 점은 현업에서의 문화를 형성하는 이유와 그 안에서의 진행되는 업무프로세스를 알 수 있다는 점입니다.
토이프로젝트를 진행하면서 Jira를 사용해본적이 있지만 확실히 현업에서 사용하는 방식하고는 많이 차이가 나는 걸 알수가 있었습니다.
이번 우아콘을 통해서 현업에서의 일이 어떻게 이뤄지는지 알아보며 서비스가 어떻게 개선되고 발전되는지를 알 수 있었습니다.
특히 "WOOWACON 의 배민 커머스 프론트엔드의 진화" 세션의 경우 현업의 프로세스와 서비스의 아키텍쳐와 기술이 변해가는 과정을 보면 개발의 전체적인 흐름을 볼 수 있었던 좋은 세션이였습니다.
물론 모든 것을 다 이해했다고 말하기 어렵지만 보는 것만으로도 시야가 많이 넓혀졌습니다. 또한 연계되는 세션도 많아 스토리라인이 잘 구성되어있다고 생각됬습니다.
이번 기존에 우아콘을 알고있었지만 직접 접하면서 우아콘을 경험한 것은 이번이 처음이었습니다. 덕분에 세션 하나하나 보면서 학습할 것들이 방학숙제마냥 한가득 쌓이게됬습니다. 이번 우아콘 세션을 다 살펴보고 시간이 된다면 지난번의 우아콘도 살펴보려고 합니다.
'일상' 카테고리의 다른 글
힘든 알고리즘 재활훈련;; (0) | 2022.01.22 |
---|---|
SSAFY 프로젝트 끝! 끝! 끝! (0) | 2021.11.23 |
당신의 디자인 감각은 어떤가?! (0) | 2021.11.13 |
시간이 더 필요하다. (0) | 2021.11.12 |
뭐를 해야 할까? (0) | 2021.11.07 |