서비스를 위한 로직 작성하기

 

목표

---

어트랙션 프로젝트는 실 서비스를 염두하여 진행한 프로젝트였기때문에, 그에 맞추어 유지보수를 위한 설계가 필요했습니다. 또, 이후 서비스의 확장도 고려해야 했습니다.

이를 모두 고려하여 요구 조건을 생각해보자면

1. 유지보수가 용이해야한다. (중복되는 로직은 최대한 피해야한다)
2. 추후 서비스를 확장할 수 있어야한다.
3. 인원이 변경되거나 하는 여러가지 사항에 대비해 문서화를 철저히 진행해야한다.

팀원들과 어트랙션 서비스를 준비하면서 내린 결론은 다음과 같았습니다.

1. 디자인 시스템을 통해 공통 컴포넌트를 관리하여 중복되는 컴포넌트를 최대한 피한다.
2. 모노레포 구조를 도입하여 추후 서비스를 확장할 수 있도록 한다.
3. 디자인 시스템에 Storybook을 도입하여 컴포넌트에 대해서 문서화를 진행하고, 노션을 통해 개발 기록을 남긴다.

모노레포

---

우선, 모노레포를 왜 사용하는가? 에 대해서부터 알아보겠습니다.

모노레포란, 하나의 저장소를 의미하는 ‘Monolithic Repository’의 줄임말로, 많은 프로젝트를 단일 저장소에서 관리하는 방식을 말합니다.

단일 저장소에서 여러 프로젝트를 관리함으로써 여러가지 이점이 생기는데 이는 다음과 같습니다.

1. 프로젝트를 생성할 때 기본적으로 세팅 해야 하는 일들이 줄어든다.
2. 패키지의 중복 코드를 줄일 수 있다.
3. 개발자 경험을 일관적으로 유지시켜 줄 수 있다.
4. 다른 패키지의 변경사항을 파악하는데 용이하다.

그렇다고 해서 모노레포가 반드시 기존의 방식보다 항상 나은 방법은 아닙니다. 모노레포는 다음과 같은 상황에서 사용했을 때 효과적입니다.

1. 유사한 제품의 집합일 때
2. 여러 프로젝트의 변화를 한눈에 파악해야 할 때
3. 공통 기능을 재사용하는 관련된 프로젝트의 집합일 때

위의 내용을 충분히 고려하여 모노레포와 멀티레포를 선택하는 것이 중요합니다.

모노레포를 구현하는 방법에는 여러가지가 있습니다. 현업에서는 모노레포를 관리할 때 일반적으로 turborepo 나 lerna 를 사용합니다.

어트랙션 또한 위의 방법을 사용할까 했으나, 모노레포를 처음 적용해보는 것이기 때문에 모노레포 환경을 직접 구축해보는게 좋다고 생각했고, 자료를 찾아본 결과 pnpm 에서 workspace 기능을 통해 모노레포 환경을 지원한다는 것을 알 수 있었습니다.

하여, 어트랙션은 pnpm workspace 기반으로 모노레포 환경을 구성했으며, 패키지 매니저 또한 pnpm으로 사용하게 되었습니다.

모노레포 환경에서 일반적으로 사용되는 패키지 매니저는 pnpm과 yarn-berry 두 종류인데, yarn-berry의 경우 plug-n-play기능을 통해 zero-install 환경을 구축할 수 있다는 점은 매력적이었으나, 3버전까지 ghost dependency문제가 있었고, 해당 내용이 4버전으로 메이저 업데이트가 진행되며 해결되었다고는 하나 yarn-berry의 PnP가 Git에 지속적으로 부하를 준다는 내용과 모든 패키지들이 PnP를 지원하지 않는다는 점에서 pnpm을 선택하게 되었습니다.

 

Yarn 대신 pnpm으로 넘어간 3가지 이유

Yarn 대신 pnpm으로 넘어간 3가지 이유

 

디자인 시스템

---

디자인 시스템이란 디자인 원칙과 규격, 재사용할 수 있는 UI 패턴과 컴포넌트, 코드를 포괄하는 시스템을 말합니다.

디자인 시스템은 크게 3가지 정도로 나뉘는데

1. UI 가이드라인(스타일 가이드)
   • UI를 표준화하고 화면 간의 일관성을 확보하기 위한 가이드입니다.
2. UX 가이드라인
   • 서비스와 브랜드 측면에서 사용자가 일관적이고 차별화된 경험을 하도록 하기 위한 가이드입니다.
3. 디자인 시스템
   • 디자인 원칙과 규격, 재사용 가능한 UI 패턴과 컴포넌트, 코드를 포괄하는 시스템입니다.

어트랙션의 경우 재사용 가능한 컴포넌트와 아이콘 패키지를 디자인 시스템에 추가했고, 이를 통해 중복되는 코드를 줄이고 사용자에게 일관적인 경험을 주고자 했습니다.

어트랙션의 경우 현재 서비스중인 뉴스레터 서비스 이외에도 추후 백오피스와 같은 서비스를 계획하고있었기 때문에 사용자에게 일관적인 경험을 주는 것이 중요하다고 생각했습니다.

또, 이렇게 생성된 컴포넌트에 대해서 Storybook을 통해 문서화를 진행했습니다. 이를 통해 추후 디자이너와 같은 비개발자 직군과 소통할 때 어려움이 없도록 하고, 개발에 새로 참여하는 사람들도 가이드를 통해 쉽게 컴포넌트를 사용하도록 하고자 했습니다.

그리고 생성된 Storybook문서는 chromatic 서비스를 통해 배포했고, 이를 Github Action 을 통해 CD 파이프라인을 구축하여 최신의 내용을 반영하도록 했습니다.

 

UI / AspectRatio / Aspect Ratio Default

@storybook/cli - Storybook

 

Storybook은 chromatic을 통한 컴포넌트 테스트도 지원하는데, 어트랙션 서비스는 추후 테스트 로직의 추가를 통해 DS의 커버리지 상태를 개선할 예정이며, shadcn/ui기반으로 되어있는 컴포넌트 또한 자체컴포넌트로 교체할 예정입니다.

써드파티 시스템을 통한 사용자 경험 개선하기

---

여기에 추가적으로 써드파티 시스템을 통해서 사용자의 경험을 개선하고자 했습니다.

 

Sentry를 탑재하여 에러를 로깅하고, 에러에 대한 디테일한 정보를 받아 에러를 수정하고 있습니다. 이는 이후 프론트엔드 서비스의 로드 밸런싱을 고려하여 에러를 종합적으로 로깅할 수 있도록 구축해놓은 것입니다.

 

 

Sentry에서는 특히 에러가 디테일하게 로깅되어 어떤 환경에서 에러가 발생했는지를 쉽게 확인할 수 있습니다.

세션 리플레이 기능을 통해서 정확히 어떤 상황에서 에러가 발생했는지도 확인할 수 있습니다.

 

 

에러 발생시에는 슬랙과 알림 연동설정을 해두어 슬랙 알림을 통해 프로덕션에서 에러가 발생했음을 빠르게 인지할 수 있습니다.

 

 

이외에도 채널톡 을 통해 일반 유저에게 문의와 피드백을 받아 유저의 사용성을 개선했습니다.

기존에는 서비스에 문의를 하려면 일반 유저에게는 접근성이 떨어지는 깃허브 이슈나, 언제 답장이 올지 기약이 없는 이메일을 사용해야했지만, 채널톡을 추가함으로써 실시간으로 문의를 받고 해당 내용에 대해 답변할 수 있게 되었습니다.

참고

---

https://yozm.wishket.com/magazine/detail/1830/

https://medium.com/musinsa-tech/journey-of-a-frontend-monorepo-8f5480b80661

https://fastcampus.co.kr/pages/43837