첫 개발 프로젝트 회고

처음으로 제품의 큰 부분을 맡아서 개발했던 프로젝트가 마무리됐다. 느낀 점들이 많아서 남겨둔다.

전반적인 회고

• 개발은 정말 수많은 선택의 연속이다. A라는 결과를 도출하는 함수 하나를 짜더라도 여러 구현 방법이 있다. 그리고 그 선택에 따라 그 뒤의 선택이 종속되기도 하며, 의존성이 생기기도 한다. 선택의 과정마다 내 판단이 맞았는지 생각을 많이 했다. 개발할 때 그 상황에 맞는 좋은 선택을 하고, 그 선택에 대한 근거 있는 확신을 갖는 게 개발을 잘하는 거다, 하는 생각이 들었다.
• 기획에 대한 이해와 얼라인을 초반에 더더더 빡세게! 하더라도 프로젝트 후반부에 스펙이 변경되거나 추가되는 경우가 생긴다. 특히 QA, 런칭 직전에 새로운 피쳐를 쳐내야 한다면 퀄리티가 낮은 코드를 작성하게 될 확률이 높다. 그러니 기획과 정책이 잡히는 초기에 더 많은 이야기를 꺼내고 더 많은 경우의 수를 미리 계산하고 이야기해야한다. 끝에 가서 피쳐를 추가해야할 수 있지만 그 범위를 최소화하기 위해 커뮤니케이션이 많이 해두어야 한다.
• 제어할 수 있는 것 vs 제어할 수 없는 것에 대한 생각. 내가 기획에 참여하는 범위, 스펙을 결정하는 범위를 명확하게 하는 것이 좋다. 일단 프로젝트에 들어가면 내가 제어할 수 없는 것에는 연연하지 않는다. 그래야 끝낼 수 있다. 아쉬운 점은 한 사이클을 끝내고 돌아보면 된다. 완벽한 과정은 없다.
• 스타트업 신에 이런 밈이 있다. 개발자에게 뒤늦게 기능 추가를 요청하는 상황을 두고 그건 건물을 다 지은 뒤 1cm 옮겨달라 하는 것과 마찬가지라고. 기존 코드 구조에 맞지 않은 요구가 뒤늦게 들어왔을 때, 개발자 입장에서 실행하기 어렵다는 말이다. 스타트업 환경에서 나는 이런 말에 완전히 동의하지 않는 편이다. 변경할 수 있게 설계해야하고, 비즈니스의 필요에 따라 변경해야 한다면 변경해야 한다. 스타트업의 제품은 바뀌어야 살아남는다. 유연하게 변할 수 있는 프로덕트가 살아남는다.
• 프로젝트에서 일부분을 담당하더라도 프로젝트 전체 구조가 어떻게 돌아가는지 아는 건 중요하다. 이걸 알고 일하는 상태와 아닌 상태일 때 커뮤니케이션의 질이 달라진다.
• 동료에 대한 신뢰감은 매우 중요하다. 개발 리드, 다른 파트 개발자 대한 신뢰감으로 든든한 기분으로 일할 수 있었다. 서로가 제 역할을 하고, 커뮤니케이션이 쉽게 가능하다는 신뢰감은 좋은 퀄리티로 연결된다. 이게 가능한 팀이라 좋았다.
• Next.js T3 stack을 썼는데 초반에는 zod, TRPC같은 새로운 라이브러리가 주어지니 며칠은 꽤 해맸다. 내가 잘 모르는 라이브러리로 작업을 하려니 더듬더듬 속도가 나질 않았고, 내가 잘하는 건지 아닌 건지 판단할 수 없었다. 근데 코드를 하나둘씩 작성하고 익숙해지고 나니 그 뒤는 어렵지는 않았다. 기술적으로 이해할 수 있다면 프로젝트에서 처음 써보더라도 활용할 수 있다. 오히려 프로젝트 후반으로 갈 수록 TRPC 덕에 효율적으로 API를 짤 수 있어서 만족스러웠다.
  • 한번 익숙해지니 API 피쳐를 쳐내는 건 수월해졌다. 이때부터는 스스로 작업시간을 예상할 수 있고 그 시간에 맞춰서 일을 끝낼 수 있었다.
• 프로그램의 복잡도를 단순하게 예상하지 말 것. 로그인, 비로그인을 동시에 처리해야 하는 화면이 있으면 단순히 x2의 경우가 되지 않는다. 그 안에 들어가 있는 컴포넌트 분기들만큼 복잡도가 증가한다. 그리거 그만큼 짜야할 API가 늘어난다. 일정 산정 시 이 단순하게 x2라고 생각했다가 뒤에 달려야했다.

리뷰

개발 리드를 맡았던 후니에게 작업 과정에 대한 리뷰를 요청했고 요런 답을 받았다.

1. 이번 프로젝트에서 후니가 저에게 기대한 것? 그리고 작업 과정 및 수행에 대한 피드백

   기대 이상을 했다. 굳. 커뮤니케이션 과정, 실행에서 신뢰할 수 있는 상태로 일할 수 있어서 좋았다. 오히려 그래서 좀 더 넓은 범위의 책임을 넘기기도 했다.

2. 앞으로 어떤 범위를 학습하고 작업 범위를 늘려갈지?

   같은 역할을 하는 도구를 여러 것을 찍먹해보는 것은 그렇게 중요하지않다. 오히려 그 도구가 돌아가는 기술에 대한 이해가 중요하다. 앞으로 프로젝트를 한다면 그것에 더 집중해 볼 것. 예를 들면 auth.js 를 공부하기보다는 전반적인 authentication authorization 과정을 아는 것.

기타

• 여행, 장소의 변경은 생각의 리프레시에 굉장히 큰 도움이 된다. 프로젝트 끝에 달리고 살짝 피로도가 몰려왔는데 하루 여행으로 장소를 바꾸니 많은 것이 개운해졌다. 좋은 컨디션으로 참여해야 팀에게 내 불필요한 부정적 기운을 전달하지 않는다. 여행은 비용이 들지만 매우 효과적이다.
• 신뢰하는 동료들과 티키타카 일하며 제품을 만드는 것만이 줄 수 있는 재미가 있다. 즐겁게 작업했다!