yarn plugin으로 우아하게 로깅하기

 

로그는 에러 뿐만아니라 비즈니스 결정을 위한 중요한 요소가 된다.

 

 

 

 

 

이처럼 많은 로그를 자동화하기 위해서 많은 중복 코드가 발생할 수 밖에 없다.

 

 

토스는 자체 디자인 시스템인 TDS를 이용해 로깅을 자동화했다.

 

 

첫번째 시도 - 디자인시스템에 로그 기능을 추가하자

개발 비용도 적고 기존에 사용하던 곳에도 적용하기 쉬웠음

 

그러나, 계열사 별로 로그 코드가 많고 형태가 달라 통합하기 쉽지않음

그리고 로깅관련 코드가 함께 배포되는 이슈가 있었음

 

 

TDS가 로깅관련 코드를 포함해 로깅관련 수정사항을 반영하면 모든 컴포넌트의 디자인 사양도 변경해야하는 문제도 발생했다.

 

 

 

두번째 시도 -  HOC 형태로 로그 감싸기

 

 

TDS 컴포넌트를 감싸 제공하는 형태로 제공,

서로 독집적으로 수정하고 배포가 가능해졌다.

 

그러나, 로깅 레이어를 사용하기 위해서 기존의 tds대신 hoc가 적용된 tds 컴포넌트를 사용해야했음

그래서 너무 많은 양의 코드 수정이 필요해짐

 

 

 

 

 

TDS를 사용하는 기존 서비스의 코드를 유지하면서 TDS를 가져올때 HOC가 적용된 로깅 컴포넌트를 사용할 수 있게 해보자

 

 

동일한 이름으로 코드 변경없이 로깅 기능을 제공할 수 있도록

의존성 트리 자체에서 TDS대신 로깅 라이브러리를 직접 바라보도록 수정해보자

 

 

이를 가능하게 하기 위해 yarn berry의 plugin을 이용해보기로 했다.

yarn(2)은 package manager 자체가 plugin 형태로 구성되어있다.

 

 

이에 앞서 yarn의 설치과정을 살펴볼 필요가있다.

 

 

- yarn add 시 Resolution step에서 새롭게 설치된 패키지명이 표시가됨 

- 설치된 패키지의 사이즈가 명시됨

 

1. resolution - 버전의 범위 git repo등의 출처를 받은 뒤 하나의 고유 버전을 가리키는 id를 받음

2. fetch - resolution에서 얻은 id를 바탕으로 필요한 의존성 다운로드

3. link - 다운로드한 의존성을 어플리케이션에서 사용할 수 있게 연결

(node moldules에선 필요한 의존성을 복사, pnp환경에선 pnp manifest안에 각각의 패키지 위치를 기입)

 

 

그래서 결론적으로 TDS를 직접가져오는 것이 아닌 해당 패키지가 로깅 패키지를 거치게 하기 위해선

Resolution step에서 처리해야한다.

 

 

좀더 각 step의 동작 순서를 세부적으로 살펴보자

 

 

tds 버전을 넣을 수 있게 decriptor를 수정하고, 로깅 관련 코드를 대신 resolve할 수 있게

tds 버전과 로깅의 버전을 각각 독립적으로 관리할 수 있음

 

yarn plugin 기반으로 개발된 환경에서

package.json에서 의존성의 npm 버전 대신 logging으로 시작되는 특수한 버전을 사용할 수 있다.

 

 

기존과 똑같이 사용가능해진다.

---

 

출처

https://www.youtube.com/watch?v=E7jdKomaqjI