[회고] 2024/08/06

C 프로젝트 1, 2차 스펙 개발 완료 후 회고

• 초기부터 일단 스케줄에 겁먹고, Vue를 처음 쓰는 것에 대해 겁먹어서 너무 개발을 막했다. 약간 스타트업 다닐 때 혼자 프로젝트를 시작하는 것과 똑같았고(실제로 혼자했고, 초기 세팅부터 다 내가 했다. 하지만, 내가 익숙한 프레임워크도 아닌 VueJS3이었고, monorepo를 처음 적용해서 공통 컴포넌트들을 가져다 쓰는 입장이었기에 자유롭게 개발하는 것도 아니었다. 앞서, 개발을 막했다는 것은 천천히 소단위로 기능을 쪼개고(함수형 설계), UI 컴포넌트도 공통 컴포넌트 외에 것들은 내가 소단위로 관리하면서 큰단위로 개발할 수 있었는데, 그러지 못했다. 스케줄 핑계와 처음쓰는 프레임워크에서 오는 두려움(이 두려움으로 스케줄을 소화하지 못하면 어쩌나와 같은)에 대한 핑계가 있긴하지만, 현실적인 어려움도 확실히 있었다.
• 새로운 경험을 해봤다. 공통 컴포넌트를 개발하는 팀원이 따로 있고, 나는 그 공통 컴포넌트에 대해 외주를 맡기는 식으로 일을 해봤다. 그 공통 컴포넌트가 완성되면 나는 공통 컴포넌트가 아닌 컴포넌트와 그외 비즈니스 로직을 개발하는 식으로 일을 했다. 처음에는 같은 팀 내에 외주 업체가 있는 식으로 일하는 체계가 효율적일까 싶었는데, 나름의 효율성은 있다고 생각한다.
• 또 처음으로, 함수형 프로그래밍 기법을 회사 프로젝트에 적용해봤다. 올해 상반기 동안에 함수형 프로그래밍 관련 공부를 혼자서 해봤는데, 그 기법을 내 프로젝트에 적용시켰다. 모든 곳에 적용할 정도로 익숙치 않았기에 일단 개발을 진행하고, form validation을 하는 로직이 자주 쓰인다는 점에 착안하여 이 부분을 함수형으로 잘게 쪼개서 만들었다. 실제로 확장성이 좋았고, form validation을 하는 부분은 모두 이 함수형 기법으로 만든 함수를 써서 개발했다. 처음에는 억지로 함수형에 내 코드를 끼워맞추는 듯한 코드가 나왔지만, 점점 함수형의 이점(확장성, 재사용성, 가독성 향상 등)을 가져갈 수 있는 코드가 돼서 뿌듯했다. 주로 Either 를 써서 개발을 했다. 좀 더 공부해서 더 다양한 기법이 개발을 할 때 떠오르도록 연습해야겠다.
• VueJS의 양방향 바인딩이 리액트의 단방향 바인딩과 비교하여 어떤 장점이 있는지를 어느정도 깨닫게 됐다. 처음에는 항상 단방향 바인딩에 따라 데이터를 직접 업데이트하고(흔한 예시로 input event, 리액트에서는 change 이벤트에서 조차 직접 state 업데이트를 해줘야한다), 이를 구독해줘야하는 리액트와 다른 방식 자체가 센세이션했고, 이걸 왜 이제알았지? 정도로 신나게 썼던 것 같다. 하지만, 점점 내 관점에서 단점이 보이기 시작했는데, 양방향 바인딩은 개발자가 세세하게 컨트롤을 안해줘도 될만큼 편하게 데이터 바인딩이 되지만, 그 장점과 반대로 막상 개발을 하고 나중에 사이즈가 점점 커지게 되면 데이터 추적이나 디버깅이 좀 어렵다는 생각이 들었다. 머리속으로 데이터가 어떻게 돌아가는지를 직접 setState 등으로 해주는게 아닌, 자동으로 된다고 생각했을 때, 프로젝트 사이즈 및 로직이 복잡해질수록 이걸 머리속으로 이해하려니까 꽤나 골치가 아팠다. 그래도 양방향 바인딩에 대해 이해도가 올라가고 vuejs를 더 많이 써본 좋은 경험이었다.
• 아쉬운 점 및 고칠점
  • 처음부터 컴포넌트, 비즈니스 로직을 작은 단위로 쪼개면서 점점 키워가는 개발을 하는 버릇을 들여보면 좋을 것 같다. 물론 이건 상당히 어려울거다. 차라리 내가 지금 한 것처럼 일단 개발을 하고, 작은 단위로 쪼개가는 것이 내 수준에서는 나을 수 있다. 하지만, 처음부터 그런 노력을 해보는건 좋은 방향이라는 생각이다.
  • 웬만하면 CSS 로 처리하자. JS 등의 힘(?)을 빌리는 것도 좋지만(혹은 DOM API) CSS 만으로 처리할 수 있는게 점점 늘어나고 있으므로, 그에 대해 배울겸 CSS로 처리하는 것을 1순위로 생각하는 습관을 들이자.
  • 나만의 프로젝트 도식화를 직접 그리면서 개발해보자. 머리속으로 도식화를 하면서 해도 되지만, 실제로 Draw.io 등을 통해 이런걸 작성하면서 진행하면 나중에 스스로 본인 프로젝트에 대한 이해도가 높아질 것이고, 타인과 대화할 때도 이로울 것이다.
  • 이번에 개발을 할 때, 타부서에서 원하는 개발 내용을 외주 업체처럼 개발을 해주는 방식으로 일을 했는데, 이렇게 개발을 할 때나 같은 실사람들끼리 프로젝트를 할 때나 중요한건 만들고자 하는 것 혹은 프로젝트의 방향성에 따라 개발의 중요도를 달리하고, 이에 대해서 개발자의 관점을 명확히 공유해야 한다는 점이다. 옛날에는 나도 모든 것을 기획, 디자인 쪽에서 원하는대로 해주려고 하는 개발자였다면, 이번 프로젝트를 해보고 나니까 실제 이 서비스를 사용할 사람들 혹은 이 프로젝트의 방향성에 따라 경중이 정해지는 것이고, 스케줄과 특정 기능의 중요도 등에 따라 명확하게 아닌건 다음으로 미루거나 쳐낼줄 아는 개발자가 돼야 효율적이라는 것을 배웠다. 착함 혹은 눈치를 보느라 이런걸 놓치면 오히려 개발을 안하는 직무의 사람들 입장에서는 피해를 볼 수 있으니, 본인 분야에서 얻는 인사이트를 타직군 사람들에게 자신있게 공유하는 개발자가 되자.
  • 초반에 스케줄 관리를 잘못해서 새벽 세시까지 야근을 하는등 생전 처음해보는 회사 생활을 경험했다. 스케줄 관리를 잘못했단건 앞서 말한 것과 비슷한데, 어떻게보면 사서 고생한거다. 스케줄과 제품의 퀄리티는 유효한 상관관계를 가진다고 생각하는데, 이번 프로젝트에서는 제대로 고려하지 못했다. 일단 시키는걸 다한다는 자세로 임해버려서 내가 감당할 수 없는 량이 감당할 수 없는 기간에 주어졌다.. 물론 결국 밤을 새서라도 해버렸지만, 이 때의 배움(?)으로 2차 스펙 개발 때는 확실히 선을 그으면서 일을 해서 지금에 와서보면 1차보다 2차 때 더 성장한 개발자가 아니었나 싶다.
• 공부 쪽으로 보완할점
  • 다음 프로젝트도 결국 Vue를 쓸 것 같은데, Composable 등 더 공부해보자.
  • 함수형 프로그래밍이 나에겐 매력적인 방식으로 느껴졌고, 더 공부하고 싶어졌다. 하지만 타입스크립트에선 ramda가 에러를 많이 일으켜서 fp-ts 등 다른 모듈을 찾던지, 직접 만들어서 쓰던지 해야겠다. 어쨌든 함수형 관련 공부를 더해봐야겠다.
  • Vue 만 쓰다보니까 리액트가 그립다.. 리액트 프로젝트를 혼자서 조금씩이라도 해보자.
  • 은근 코딩 머리가 굳는 것 같다. 알고리즘 풀이 이런거 하루에 0.5문제라도 좋으니 꾸준히 하자.