240622 - 2024년이 반 지났다 🥃, 약간의 회사 회고🖋️

날이 덥다, 요즘 하는 것: 듀오링고, 런데이

2024년이 반 지났다 🥃

6월 들어 회사 client 레포지토리 이슈 & PR 넘버링이 1111번째가 넘어섰다.

10페이지의 FAQ라고 쓰고 사용자 가이드라고 읽는 페이지들을 작성하고 나니, 서비스 개발을 일단락하고 있다는 느낌이 든다.

(하지만 아직 버그 수정의 산... 뒷동산이 남아있다)

 

돌아보면 작년 입사 후 초반 3달가량은 서비스의 페이지의 역할, 기능, 태스크를 명세하고 싶은 욕심은 있었지만

문서화에 대한 비용을 계산하지 못해서 매일밤 야근했던 기억이 난다.

이제와 보면, 입사 초반에 작성해 놓은 문서는 실제 구현 기능과 불일치하게 되어서 사용자 가이드는 처음부터 작성해야 했다.

 

1년 동안의 서비스 개발 과정은 시행착오의 연속이었던 것 같다.

스스로 만든 레거시도 많고, 같은 기능을 피드백이나 현실성에 맞게 계속 수정하거나

기능 구현의 마무리가 안되어서 엎고 다시 만든 기능도 있다.

마음이 급해져서 시멘틱 버저닝도 놓아버렸던 점도 아쉽다.

 

디자인 시스템 🎨

 

이전에는 프론트엔드 작업을 혼자 했었고, 동료 FE 개발자들과 일하다는 것은 처음이다 보니

공통으로 사용하는 컴포넌트를 위한 디자인 시스템이 있으면 작업이 편리할 것 같다는 생각을 했다.

 

그래서 외주 디자인 업체에 컴포넌트와 폰트 hierarchy, 색상 테마를 포함한 스타일 가이드를 요청하고 피드백을 진행했고,

개발 기간의 첫 달을 디자인 시스템을 구축해보고자 했다(했었다)

스케치업과 캐노니컬을 통해 문서화하고 "@design/TextButton"처럼 모듈을 import 해서 사용하는 것이 목표였지만

생각지 못한 점은 작업에 대한 비용과 완성된 컴포넌트의 퀄리티였다.

 

목표로 했었던 한 달 동안, 실사용할 수 있는 모듈이 완성될 것 같지 않았고 리뷰 과정이 늘어지는 개발 경험 악화로 인해서

2주간 진행한 작업을 중단하고, 만들어놓은 공용 컴포넌트를 Frontend 레포지토리로 복사해서 코드 작업을 시작했다.

스케치업과 캐노니컬이 적용된 Design 레포지토리가 지우기는 아쉬다는 느낌으로 남아있다.

 

제로부터 시작할 수 없는 현실 생활 🕰️

 

다시 시작한다면 좀 더 잘할 수 있지 않을까 하는 것들이 많다.

마이크로 했던 초반 코드 리뷰와 매일 아침 스크럼의 피로감도 그중 하나인 것 같다.

 

이전 회사에서 혼자 코드를 작성했을 때 코드 리뷰를 받고 싶었던 기억이 있었기 때문에, 처음 코드 리뷰 문화를 적용하면서 너무 과한 리뷰를 진행한 점이 있었다. 리뷰 과정에서 특정 사람이 주요 리뷰어가 되면서, 리뷰어의 작업에도 지장이 생기고 병목 현상도 발생했었다.

 

스크럼은 이전 회사와 달리 정기적인 회의 진행이 없으니 소통이 필요하다고 생각해서

매일 아침 출근 후 10~20분 동안 작업 진행을 공유하고, 막히는 점이 있는지 말하는 정도로 진행했었는데 사람에 따라서 부담스럽고 길다고 받아들이는 경우가 있었다.

다른 회사의 경우를 참고해 보면, 스크럼을 진행하면다면주 1회 정도로 진행하는 케이스가 좋아 보인다.

 

그리고 태스크를 너무 잘게 쪼갠 점도 안 좋은 점이었다.

한 사람이 한 기능을 전담하면서 전체 프로젝트에 대한 개인의 이해도가 떨어지는 점을 방지하는게 목표였는데, 개발 과정에서 개인의 성취감이 떨어지고, 기능에 대해 궁금한 점을 물어볼 때 담당이 없으니 애매한 경우가 있으며, 직원 개인이 서비스 개발에서 내가 무엇을 작업했느냐를 증명하려 할 때 충돌이 생길 수 있다는 점이 단점이었다. 

 

또.. 다른 팀원 분들이 오기 전에 1~2주일간 초기 세팅 (기본 레이아웃과 route 뼈대 작업, 더미 3D 랜더링 리스트, 3S + CFN 배포)을 빠르게 끝내 놓고, 입사 후 스터디와 개발 시작에 집중하는 것이 좋겠다고 생각했었어서 프로젝트의 초기설정을 템플릿을 사용해서 만든 것이 그대로 레거시가 된 부분도 아쉽다.

 

라이브러리처럼 사용할 수 있었으면 해서 만든 버튼 박스, 모달 클래스와 form 컴포넌트도 문제가 되고 있는데 class와 배열 형태의 config 상수로 고정되어 있어서 사용 방법이 너무 제한되어 있다. 버튼별 개별 작업이나, 특정 동작을 하는 input을 끼워넣기가 어렵다. 더 편리하게 사용했으면 좋겠어서 작성한 기능이 걸림돌이 되고 있다. 재사용하는 컴포넌트는 복잡하거나 세밀하지 않더라도, 사용하기 쉬운 것이 가장 중요한 것 같다. 

 

31가지 맛 트러블슈팅 🍦

 

데이터베이스를 모킹 하는 방식을 여러 차례 고민해 봤는데, 현재 프로젝트에서는 MSW, OAS generator를 사용하고 있다. 

우여곡절이 있었다. 스펙이 바뀔 때마다 에러가 발생했고 서버가 다운될 때 개발이 멈춰버렸기 때문에 Mocking Service Worker를 도입했다. MSW를 사용하는 더 좋은 방법이 있었을지도 모르지만, 단일 요청/응답을 모킹 했기 때문에 사용자별 로그인이나, 여러 분기별로 나누어진 API 응답을 재현하기 어려웠고, websocket의 경우는 적용할 수 없었다. 그리고 API가 변경/추가되면 결국 수동으로 모킹 데이터를 업데이트를 해줘야 해서 효율적이지 않았다. 

 

이후에 Swagger와 OAS Generator으로 Swagger기준의 모킹을 개선했지만 서버가 내려갔을 때는 사용할 수 없다는 단점이 있다... 두 가지 방법으로 데이터베이스를 모킹 하고 있는데, 뭔가 명확하게 구현되지 않았다는 느낌이다. DB가 다운될 때 MSW를 활용하는 정도로 사용하고 있다.

 

WebRTC를 적용하는 데도 문제가 많았다. 11월 7일부터 1월 8일까지 기능 구현을 진행했는데, 연결하는 과정(caller와 calle가 서로 연결된 상태에서 ICE 후보를 교환하고 peerConnection 설정)에 문제가 많았다. 연결이 되지 않아서 12월부터는 3명이 chrome://webrtc-internals을 켜놓고 공식문서와 레퍼런스를 찾아보며 완성하려고 했었는데, 일반적으로 WebRTC를 구현하는 목적인 영상/음성 공유(MediaStream)이 아닌, 인터렉션에 따른 3D Matrix를 전송하기 위한 DataChannel을 연결하려 하니 레퍼런스도 많지 않았다. 결국 연결이 되다가 안되다가 하는 현상이 보여서 WebSocket으로 다시 작업하게 되었다. 지금 채팅과 캔버스 공유는 웹소켓으로 구현되어 있는 상태다. 결과를 보면 좀 더 빨리 그만두고 WebSocket으로 구현했었어야 했었다. 상용서비스에 어떻게 구현되어 있는지 궁금해서 마침 항해 플러스 3기를 수료하고 있던 중이라 WebRTC를 다루고 계신 명균 님께 여쭤봤을 때는 mediasoup를 추천받았었는데 클라이언트 단에서만 처리할 수 없는 문제라 적용할 수는 없었다. CS를 더 공부해야겠다는 생각을 했다. 

 

그리고 3D mesh에 대한 출력과 컨트롤을 ThreeJS, R3F, Drei로 구현을 마치고 어느 정도 기능 개발이 완료되었다고 생각한 3월 4일에 문제점을 발견했었다. 실시간 공유를 하다 보니 기존 C++ 소프트웨어와 origin이 맞지 않는 이슈가 생겼고, 화면을 회전하는 방식과 매트릭스를 그리는 방식이 달랐기 때문에 랜더링 기능의 많은 부분을 수정해야 했다. 3D 랜더링을 다루는 도메인은 더 깊게 들어갈 경우 훨씬 로우 레벨에 대한 이해가 필요하다. 고민이 되는 부분이다.

 

파일 데이터 관리에 대해서도 버그가 지속적으로 발생한다. 3가지 url 리스트의 스토리지 링크에서 각 데이터를 받아와서 블롭으로 파일을 만들고, 이를 토대로 트리 형태를 만들고, 트리의 유저 인터페이스 상호작용을 반영하는 로직이 있는데, 플로우 차트를 그려보고 최대한 정리를 해봐도 어려운 코드가 되는 것 같다. 목적별로 나눈 커스텀 훅 5개의 실행이 절차적으로 필요하다 보니, 파일 Import 같은 추가 기능을 구현할 때 다른 팀원이 이해하기 어려웠다. 문자열이나 byte를 잘라서 확인한다던가 태그와 확장자가 일치해야하는 미세한 기능들이 있어서, 정해진 타입에 딱 맞춰 작성하지 않으면 오류가 생긴다. 그리고 게시글 이동 시마다 3D 모델 파일을 다시 다운로드하지 않기 위해 캐싱이 필요하다는 점만 알고, 효율적인 방법은 몰랐기 때문에 야매 느낌으로 blob 캐싱을 구현해 놓은 점이 있는데, 다시 좀 더 잘 만들고 싶다. 처리에 시간이 많이 드는 기능에 월간CS의 모던 리액트 딥 다이브 스터디 때 범연님이 말해주셨던 web worker를 적용해보고 싶다. 학습이 필요하다.

 

잘 마무리하기 📌

 

앞으로의 회의나 새로운 기능에서 내가 할 수 있는 일이 없어지는 것 같아 허무한 마음이 든다.

FAQ를 작성하면서 든 생각인데 FAQ가 사용자 기반 가이드라면, 팀원들을 위한 메인 로직에 대한 가이드를 써보는 것도 좋은 생각일 것 같다.

모쪼록 최대한 프로젝트 마무리가 잘 되었으면 좋겠다는 마음으로 작업을 진행 중이다.