기획 피드백

기획 문서를 작성한걸 기반으로 오늘 미팅을 했다. 그런데 한가지 아쉬운 점이 있었다.
목표를 실행하기 위해서는 몇가지 액션 아이템이 있는데 나는 예외 케이스를 해결하기 위해 기술검토를 해왔다. 그런데 이 예외케이스를 굳이 지금 해결해야할까? 라는 얘기가 나왔다. 그리고 결국에는 해당 예외케이스는 일단 대응하지 않기로 했다. 뭐 언젠가는 이 검토 내용이 도움이 될 수는 있지만 좀 아쉽다. 사실 해도 될만한 작업이다. 근데 문제는 그 빈도수에 있었다. 나는 예외케이스가 꽤 자주 발생할거라고 예상했는데 현재 상황에서는 1/5보다 덜 발생하고 있었다. 근데 이건 신규입사자 + 백엔드 api 구현내용을 모르는 나는 알 수 없었다. 더 미리 검토요청을 하지 않은건 어쩔 수 없는 상황이였기 때문에 그건 제외하고 셀프 피드백을 해보겠다.

"잘 모를 때 추측하지 않기."
도메인 지식이 부족할 때는 기술적 근거로 추측하는 것만으로는 부족하다. 서비스내의 도메인 지식이 부족하면 좋은 결정을 내리기 어렵다.

"회의 리딩능력 기르기"
리딩을 해본적이 없어서 그런가 좀 아쉬웠던 것 같다. 내용이 꽤 복잡했던 것도 있지만 내가 잘 설명하지 못했던 것도 있던 것 같다. 특히 상대방과 내가 앞단에서부터 완전 다르게 생각하고 있다보니 그 부분의 싱크를 맞추는데도 시간이 걸렸다. 그래도 나름대로 중간중간 문제를 파악하고 회의를 잘 진행한 것 같다. 진짜 못했을때는 열감이 올라오는데 이번에는 그정도는 아니였다.

모노레포 package의 다양한 문제

어쩌다보니 package들을 계속해서 건드리고 있다. 오늘은 package에 layer를 추가하는 작업을 했다. (ex packages/L1/utils, packages/L2/system)
layer를 추가하는 이유는 크게 두가지다.

[1] 안정적이지 않은 빌드환경을 안정적으로 변경하기 위해
[2] layer를 추가해서 시각적으로 package의 의존성을 쉽게 확인하고 그로인해 circular dependency, 의존성이 꼬이는, 복잡해지는 현상 등을 막기 위해

근데 1번은 내가 작업하면서 좀 말이 안된다고 생각했다. 이미 그걸 위한 툴을 사용하고 있고 꽤 유명한 툴인데 이걸 못하는거 자체가.. 근데 하나 의심되는걸 발견했다. package에서 deps, devDeps, peerDeps를 잘못사용하는 곳을 발견했다. 빌드할 때 의존성 트리를 그리는 툴은 devDeps를 신경쓰지 않을 것 같다는 생각이 들었다. 그렇기 때문에 빌드 순서가 꼬이는 문제가 발생하지 않을까?

그렇게 package를 깊게 살펴보다보니 적절하게 나눠져있지 않은 package들을 발견했다. 그리고 그로인해 의존성이 복잡해지는 문제를 발견했다.

결국 모노레포 package라는게 하나 개선하려다보면 이런저런 문제가 같이 수면위로 떠오를 수 밖에 없다. 그리고 작업 순서, 마이그레이션 가이드, pr 머지 시점 등을 같이 고려해야하는데 재밌지만 꽤나 스트레스 받는 일이기도 하다. 그래도 뭐 할일이 있음에 감사한다.