23.10.15~23.10.22

업무

1. 온보딩 요소 생성 관련 추가 개발

Builder class들을 통해 온보딩 시 띄워줄 HTMLElement들을 생성하고 있는데, 이 부분의 추가 개발을 진행했다.

(배경, action 제어 등)

 

2. 공통 모듈 패키지 제공

메인으로 진행했던 업무!

 

사용자가 온보딩을 등록한 후, 해당 데이터를 배포하면

서버 측에서 해당 온보딩을 보여줄 수 있는 script 파일을 번들링 하고 있다.

→ 온보딩을 화면에 띄우는 데 필요한 로직은 모두 server에 작성되어 있었다.

 

그런데 client 측에서도 등록 중인 온보딩을 미리 봐야 하는 요구 사항이 있었고...

해당 기능을 구현하는데 필요한 로직의 90% 정도가, 이미 서버에 작성된 내용과 동일했다!

 

모든 파일을 복사 붙여 넣기 하기엔 유지보수 리소스가 훨씬 더 클 것으로 판단,

해당 기능을 제공하는 사내 github 패키지를 만들기로 했다.

처음 만들어 본 패키지!

그리고 패키지를 제공하는데 약 1.5일 정도나 소요하고 말았다.

 

사실 패키지를 생성 자체는 전혀 어려울 게 없었다.

문제는... 내가 번들링과 JS 모듈 시스템에 대해 깊게 알고 있지 못했다는 점.

 

각 용어들의 의미와 옵션들의 뜻을 대략적으로만 알고,

자주 사용하던 것들만 습관적으로 사용하다 보니...

이번처럼 처음부터 필요한 설정을 스스로 만드는 과정에서 크고 작은 삽질을 했다.

 

꼬박 반나절을 쏟고야 '이래서는 안 되겠다'하는 생각이 들어

각 개념과 사용 방법을 차근차근 학습했고...

그 후 내가 작성한 코드를 보자, 무엇이 문제였는지 금방 파악할 수 있었다.

 

그렇게 지지난주부터 작성했던 온보딩 관련 모듈들을 패키지로 제공했고,

덕분에 서버와 클라이언트 측 모두 동일 로직을 손쉽게 재사용하는 기반이 마련할 수 있었다!

 

그리고 이 과정에서 느낀... 객체 지향적 사고의 중요성.

 

일반적으로 한 프로젝트 안에서 팀원들과 작업할 때는

설사 특정 모듈이 잘 추상화되어있지 않거나, 의미를 파악하기 힘들더라도

전체적인 코드의 맥락을 따라가다 보면 (어떻게든) 이해할 수는 있기 마련이다.

 

하지만 이번처럼 내 코드를 각기 다른 프로젝트에서 사용하는 패키지 개발의 경우,

객체지향 원칙을 어기기 시작할수록 점점 사용하기 까다로워짐을 몸소 느낄 수 있었다.

(이 '사용하기 까다롭다'는 직접 사용했을 때도 느꼈지만, 특히 readme에서 모듈들을 정의할 때 뼈저리게 다가왔다)

 

그리고 이의 연장선으로...

수많은 디자인 패턴들이 왜 등장했는지, 설계 원칙과 클린 코드가 왜 중요한지도 다시 한번 상기했던 한 주!

 

회고

1. 부메랑은 던지면 돌아온다

번들링과 관련된 지식이 부족하다는 건, 사실 예전에도 느낀 적이 있었다.

이전 배포했던 프론트엔드 애플리케이션은 대부분 webpack을 통해 번들링을 진행했는데...

그 과정에서 문제가 생기면 해당 문제의 원인을 파악하기보다는, 해결책을 찾고 적용하는데 급급했었다.

(구글링 해서 옵션 몇 가지를 바꿔보고... 동작하면 넘어가고...)

 

마음 한편에는 해당 부분에 대한 부족함을 채워야 한다는 생각이 있었지만...

늘 우선순위에서 밀렸었고, 그게 부메랑처럼 돌아온 것이 이번 주이지 않았을까.

 

부끄러웠다.

부족함을 알면서도 모른 채 했다는 게 부끄러웠다.

언젠가 찾아봐야지~ 라며 미뤄둔 것이 후회됐다.

그때 학습했었다면, 이번 1.5일을 아낄 수 있었을 텐데! 하는 자책도 플러스.

 

이번 주.

패키지를 만들면서 부족했던 부분을 제대로 매울 수 있었던 점은 좋았지만,

그와 별개로

지금 내가 놓치고 있다는 걸 알면서도, 그냥 넘어간 것들엔 무엇이 있는지

한 번 더 돌아볼 수 있게 되었다.

(같은 실수를 반복하지 않았으면 한다! 그러기 위한 feedback!)