[우아한 개발] - 02. 프론트엔드 개발자로 성장하기

나의 첫 프론트엔드 개발팀 이야기

만다오팀: 웹생산성도구개발TF

온보딩 프로젝트: 3주간 미니 만다오를 만들어보며 진행, 이를 통해 프로젝트의 이해도를 높이고, 사용법이나 프로젝트 관리 방식 등 업무 환경에 적응할 수 있음
데일리 스크럼: 매일 아침 데일리 스크럼을 통한 의견 공유

기획, 디자인, 서버 개발, 운영 지원 등 개발 외에도 업무를 담당하여 진행

기획, 디자인, 서버 개발, 운영 지원, 기타 등등... 개발자가 개발 외적인 부분에서도 목소리를 낼 수 있고, 그게 반영되는 것은 굉장히 좋은 문화라고 생각하지만, 그게 하나의 업무로 주어질 때는 다른 얘기일 것 같다. 아무래도 전문성이 부족해 발생하는 문제나 업무에 익숙하지 않아 일정을 맞추지 못하거나 하는 등의 걱정이 앞선다. 물론, 가볍게 접근해 결과나 책임에 대해서도 가벼운 정도를 부여받는 것이라면 의견을 내세울 수 있다는 점에서 괜찮을 것 같다고 생각한다.

개발자를 위한 셀프 서비스 디자인 시스템

셀프 서비스: 사장님들이 직접 배민 앱에서 가게 설정 등을 수정할 수 있는 서비스

셀프 서비스 개편을 위해 필요한 업무 분량 = 개발자 5명이 하루에 한 페이지씩 만들어야 하는 분량
디자인이 나오지 않은 상태, QA를 위한 시간을 확보해야 하는 상황이었지만, 컴포넌트화를 통해 재사용성을 높이면 효율적으로 개발할 수 있겠다는 생각에 디자인 시스템 도입 결정

코어 컴포넌트
대부분 추상 클래스로 구성되어 이를 상속받아 스택을 쌓아 올리는 구조로 설계

BaseComponent: 모든 컴포넌트가 상속받아야 하는 기본 클래스 컴포넌트

새로운 생명주기를 정의
이벤트를 자동으로 해제
웹 로그 관련된 tracking 멤버 변수가 있으면 자동으로 로그를 전송 하는 역할을 수행

PageContainer: BaseComponent를 상속받는 또 다른 추상 클래스로 URL이 있는 모든 페이지가 상속받아야 하는 컴포넌트

해당 페이지의 뷰 로그를 남기도록 추상변수를 사용해 강제
도메인별 페이지 점검시 점검 화면을 보여줄 수 있도록 서버 상태를 관리하는 변수 추가

코어 라이브러리
CashedEntity: 캐시 관리 기법이 적용된 추상 클래스

화면 구성요소
컴포넌트 간의 관계를 고려해 다양한 규칙들을 정의

상속 구조
공통적인 부분은 최대한 추상 클래스에 구현해, 비즈니스 로직과 관련된 부분만을 작성하도록 격리

Dialog 컴포넌트: 정보 또는 경고 메시지를 표시해 보여주는 추상 클래스 컴포넌트
전역 스토어로 관리되며, 화면에 그려주는 부분은 Root Component에서 담당
모든 다이얼로그는 Dialog 컴포넌트를 상속받고 직접 추상 메서드를 구현하도록 설계되어 있고, 오버라이드를 통해 중복 구현해야 하는 부분들을 최대한 줄여 사용
메소드 오버라이딩

StepDialog 컴포넌트: Dialog 컴포넌트를 상속받은 추상 클래스 컴포넌트로, 여러 화면을 구성하는데 하나의 데이터 객체를 사용하여 진행 상태, 데이터를 포함한 로컬 스토어를 가지고, 각 단계를 배열 순서로 노출시킨다.

우아한 형제들은 디자인 시스템, 컴포넌트 등을 구성할 때, 클래스형 컴포넌트를 사용하는구나~ 싶었고, 어디까지가 디자인 시스템의 영역인지가 크게 와닿지 않았다. 회사마다 디자인 시스템을 정립하고 사용하는 범위가 다르겠지만, 말 그대로 디자인적인 영역까지인지? 아니면 컴포넌트의 내부 메서드 기능까지가 디자인 시스템으로 정해져 있는 건지 알쏭달쏭했다.

콜라 좀 쉽게 담을 수 없나요?

메뉴 탐색 사용성 개선을 위한 TF 팀의 개발 이야기였는데, 이렇게 규모가 큰 회사라면 웬만하면 기능을 다 만들어서 사용할 것 같다고 생각했는데, 역시 라이브러리를 쓰는 구나 싶었다. 그리고 역시 컴포넌트는 재활용이 중요하다~ 싶으면서도 잦은 변경 사항 때문에 관리 포인트를 줄이기 위해 새 화면의 모델은 새로 생성하는 것을 보고 '언제나 정답인 경우는 없구나' 싶었다. 때에 따라서는 다르게 접근하는 시각을 항상 가질 수 있도록 해야겠다.

만드는 사람이 수고로운 UX 개발기

"만드는 사람이 수고로우면 쓰는 사람이 편하고, 만드는 사람이 편하면 쓰는 사람이 수고롭다." 백오피스 서비스는 특성상 디자이너 없이 개발되는 경우가 많고, 기능만 동작하도록 개발해서 불편한 UX를 갖는 경우가 많은데다가 일반 고객용 서비스와 달리 사용자들이 하루 종일 업무에 사용한다. => 하루 종일 고통 🧟 이에 UX를 개선해서 사용이 편해지면 에러도 줄어들고, 업무 생산성을 높일 수 있다. 😊

탭 UI
여러 탭(페이지)을 동시에 열어두고 작업하는 것이 가능

메뉴를 클릭하면 페이지가 바뀌는 대신 새로운 탭이 열림
각 탭은 독립적인 상태로, 다른 탭으로 이동해도 작업 중이던 내용을 유지 가능
작업 중인 페이지를 탭에 표시

매우 매력적인 기능이지만, 개발자로서 구현하기 위한 수고로움이 있음

성능 이슈: 열려 있는 탭이 많아질수록 DOM에 추가되는 엘리먼트의 증가로 성능 저하가 발생할 수 있음
해결방법: 활성화된 탭의 페이지만 렌더링하고, 나머지 탭의 엘리먼트는 DOM에서 제거
상태 관리의 복잡도: Form을 다룰 때는 일반적으로 비제어 컴포넌트를 사용하지만, 탭의 활성화/비활성화로 컴포넌트가 삭제되면 비제어 컴포넌트가 가지고 있던 값이 사라짐
해결방법: 실시간으로 상태를 저장하고 관리
탭 간 정보 동기화: 상세 페이지에서 수정 후 목록 페이지로 돌아오면 수정 내용이 목록 페이지에도 반영되어야 함
해결방법: 이미 목록 페이지가 열려 있는 탭 UI에 별도의 처리를 통해 작업 후 탭을 이동했을 때 새로운 데이터를 받아올 수 있도록 설계

입력 중인 상태 보호, 편집됨
편집 중인 탭을 닫으려고 하면 변경 중인 내용이 있음을 알리고 선택지를 제공

유효성 검증 시각화
유효성 검사를 보여주기 위한 컴포넌트를 만들어 사용

파일 다운로드 아이콘
버튼 혹은 이름으로 된 링크를 사용했으나, 일관성이 부족하고 직관적이지 않았음
파일 아이콘을 만들어 사용

최근 블로그 어드민 페이지 작업 등을 하며 백오피스 개발에 대해 책에서와 비슷한 환경에서의 작업이 이어졌는데, 아직 완성되지 않았지만 비슷한 접근도 많은 것 같고, UX 개선을 위해 함께 논의하던 과정이 떠올랐다.

"편한 UI/UX는 그냥 편하게 사용하지만, 불편함은 바로 알아차린다는 말에 매우 공감한다. 다른 사람들이 QA를 하면 그래서 많이 보이는걸까...? 어떻게 하면 사용자가 더 편하게 서비스를 사용할 수 있을지 고민하는 프론트엔드 개발자가 될 수 있도록 노력해야겠다.