24.01.28~24.02.04

업무

core package 이관(!)

무려 3개월 된 이슈

서비스 제공에 필요한 공통 요소들을 제공하는 kit 패키지가 있었다.

 

첫 개발 당시에는 협업 기업의 요구사항을 빠르게 반영하기 위해 하드코딩에 가까운 형태로 개발했었다.

하지만 점차 코드가 늘어나면서 데이터 흐름을 파악하기가 힘들어졌고, MVC 패턴을 이용한 리팩토링으로 이를 해결했다.

 

하지만 이 역시, 기능들이 늘어나면서 view와 model이 점차 늘어나 controller가 지나치게 복잡해졌고 

결정적으로 react로 작성된 extension에서 동일한 역할의 컴포넌트와 hooks를 재사용하지 못한다는 문제가 있었다.

 

따라서 이를 해결하고자...

1) 단일 패키지를 각각 공통 패키지와 server script용 패키지 두 개로 나누었고

2) script 번들링을 담당하는 server에서는 후자만 바라볼 수 있게 하였으며

3) 공통 패키지 제공 모듈을 extension과 동일하게 가져갔다(react 사용, styled-component 사용)

→ 이를 통해 다음 주에 있을 UX 개선본 개발에 박차가 가해질 것이란 기대!

 

추가적으로 core-package에

기존 MVC 대신 flux 패턴을 사용, 단방향 데이터 플로우를 통해 예측 가능성을 높였다.

(이 과정에서 처음으로 zustand를 사용했는데, 아주 만족 중!)

 

UX 개선본 extension 설계

version1 extension은 POC 참여 기업들 중... 한 군데도 제대로 사용하지 못했다.

그 이유는 다름 아닌 → 어려워서!

 

아무런 설명 없이도 서비스 전체 플로우를 체험할 수 있어야만 한다 판단했고

그 과정에서 참고할 만한 서비스를 발견, 이를 기반으로 UX 개선 작업에 들어가기로 했다.

 

기존 단일 content script만으로 조작이 이뤄지던 것에서

popup과 side panel을 활용하는 것으로 변경될 예정이었기 때문에

이를 반영한 아키텍처 설계 및 기본 구성 요소들을 작업했다.

 

회고

자기 자신을 설득시키는 게 우선이다

아키텍처 설계 과정에서, 굳이 이런 작업이 필요 없다는 입장의 팀원이 있었다.

주된 이유는... 어차피 변경될 것이기 때문!

 

기획/디자인이 하루에도 몇 번이고 바뀌는 스타트업의 특성상

사실 전체 그림을 미리 설계해 두는 게 큰 의미가 없다는 의견이었다.

 

물론 이도 틀렸다 볼 수는 없지만...

지난 경험들에 비추어 보았을 때

전체 아키텍처를 그리지 않고, 각 팀원들이 주먹구구식으로 코드를 작성해 나갈 경우

각 모듈들의 관심사가 개인의 판단에 의존하게 되면서

점차 코드를 이해하기 어려워져 유지보수가 힘들어지는 경우가 많았다.

 

따라서 설사 추후에 변경되더라도,

현재 하루~이틀 정도 쏟는 시간이 나중의 일주일~한 달을 아껴줄 것이란 생각이 있었다.

 

그런데, 정작 이를 팀원들에게 얘기하기가 쉽지 않았다. 왜일까?

→ 반대로 팀원들을 설득시키기 쉬웠던 순간을 떠올리니... 그 차이를 명확히 알 수 있었다.

 

바로 

자기 자신이 얼마나 설득되어 있는가가 중요한 차이점이었다.

 

나 자신이

'그럼에도 불구하고 전체 아키텍처를 설계하고 코드 작성에 들어가야 하는지'에 백 프로 납득되지 않았었다.

 

지난 경험, 클린 아키텍처 원칙 등을 통해 말 그대로 어렴풋한 직감(그러하지 않을까~~? ) 정도만 있었기 때문에

이를 논리적으로 풀어낼 힘이 부족했고,

그로 인해 설득 단계에서 턱 막히는 듯한 느낌을 받았다.

 

나 자신이 설득되지 않았다면, 다른 사람을 설득시키기란 불가능하다.

(얘기를 이어나가는 것조차 어렵다)

 

그리고 나 자신이 설득되기 위해서는

1) 지식

2) 경험

두 가지 내공이 충분히 쌓여야만 할테다!!!