두 번째 프로젝트 회고

프로젝트

• 5월 초~6월 말까지 짧은 기간이지만 2가지 프로덕트를 개발-런칭-운영했다.
• 뉴웨이즈 피드 : feed.newways.kr
  • strapi 기반의 백엔드 코드를 인계받아 작업했다. 혼자서 백엔드 코드를 맡았다.
  • 성능상 중요한 핵심 API들을 직접 설계하고 작업했다.
• 뉴웨이즈 정치인 : politicians.newways.kr
  • 피드의 정치인 유저를 위한 관리자 사이트 (배민의 사장님 사이트 같은 것)의 백엔드 코드를 처음부터 혼자 작업했다.
  • 프로젝트 레포, 개발 스택 결정부터 내가 전부 맡아서 시작했다. (azure 배포 제외)

전반적인 회고

• 그 어느 때보다 몸으로 느낀 점이 많은 프로젝트였다.

• ‘하나의 기능을 구현한다’ → ‘기능을 1)제한된 시간 안에 2)어떤 성능이 나오도록 구현한다’는 관점이 처음 생겼다. 당시 내가 감당할 수 있는 역량에 비해 기능은 많았고, 시간을 짧았다. 제한된 시간 안에 성능이 나오도록 구현하는 것은 당연히 달성해야 하며 그 과정에 대한 커뮤니케이션도 잘해야 한다…

• 디버깅에 대한 접근법과 태도에 대해서도 여러 가지를 느꼈다.

  • 디버깅은 급한 상황임에도 침착한 마음으로 해야 한다. 디버깅은 한 글자 한 줄 천천히 보면서 흐름을 짚어야 한다. 빨리 구현하고자 스키밍을 하면 아무것도 찾지 못한다.
  • 문제의 본질을 바로잡기보다 빠르게 아는 걸로 대체 해보려고 하는 것은 나쁘다.
  • 피드백, 오류 요청이 오면 내가 핵심 원인을 파악하고 주인으로서 해결한다.
  • 오류 체크 요청이오면 99.999% 내 문제다. 잘 확인하고 디버깅하자.
  • ‘이럴 리 없어’하며 문제를 부정하는 생각에 단 0.1초도 내주지 않는다.

• 작업 시 구현하는 단위 별로는 기술적으로 깔끔하게 매듭짓는다. 내가 찝찝하게 남겨둔 로직, 코드는 나중에 어차피 무조건 잡아야 된다. 그렇게 남겨두지 말자. (비즈니스 로직 결정으로 대기하는 것은 물론 오키)

• ‘스타트업에서 한 프로덕트를 담당하고 잘 운영하는 것은 대단한 역량이구나’ 하는 생각이 들었다. 굉장히 단순한 말로 “프로젝트 런칭, 운영”이라고 적을 수 있지만. 그 안에는 ‘배포 설정, 다운타임 없는 서비스 유지, 로깅하고, 버그 확인하고 실시간 대응하기, 기획 변경 빠르게 반영하기’ 등등이 다 들어가 있다. 아 물론 사용자가 있는 운영 중인 상태에서.

  • 그런 면에서 후니가 담당하고 있는 역할에 대한 다른 관점의 리스펙이 생겼다. 예전에는 사업 담당자 동료로서 일하면서 프로덕트를 약속한 기한에 런칭하고 굴러가게 하는 것에 대한 존경이 있었다면. 지금은 개발자로서 프로덕트를 일정 수준까지 끌어올리고 런칭하고 운영하는 관점에서 리스펙이 생겼다. 이런 역량은 코딩을 잘하는 것뿐만 아니라, 시의 적절하게 좋은 판단을 할 줄 알아야 하고, 현시점의 프로덕트의 완성도에 대한 기준을 세우고 점검할 줄 알아야하고, 타협이 필요할 경우 사업 담당자와 커뮤니케이션, 기한은 부족한데 퀄리티를 올려야 할 경우 개발팀과의 커뮤니케이션 모두 잘 해야 한다. (쉽지 않네)

• 구현 단계에서 모르는 문제에 봉착할 때가 있었는데, 시니어로서 후니가 적절하고 빠른 판단을 해준 것이 큰 도움이 되었다. 시간은 없고 당장 해결해야 할 때는 천천히 서칭하고 결론을 내는 방식으로 일하는 것이 불가능하고 빠르게 적합한 솔루션을 내놓을 줄 알아야 한다. 현재 서비스의 구성에서 어느 정도, 어떤 방식으로 구현해야하는지 좋은 판단을 빌릴 수 있어 좋았다. 그렇게 판단을 내리는 감각을 보고 배우는 것도 큰 수확.

• ‘백엔드를 담당한다’는 역할 측면에서 느낀 점도 많았다.

  • 백엔드를 맡는다는 것의 책임은 단순히 백엔드 코드를 짜는 것 만에만 있는 게 아니라, 코드를 짜고 그 정책을 팀에 전파해야하는 것도 있다.
  • 예전 레거시를 다 이해하고, 거기서 고칠 것을 고치고 그 정책을 다 전파해야한다.
  • 이 역할에 대해서 초반에는 잘 느끼지 못했던 것 같다. 이제 하자

• 후니가 요런 코멘트를 줬는데

  “더기가 실제 운영하는 백엔드 1인 개발자로 작업한 게 처음일 텐데 백엔드의 책임과 권한에 대해서 알 수 있으면 좋겠다. 백엔드 개발자의 빡센 시기는 오픈 1주 전-1주 후다. 개발자가 홀로 백엔드를 맡는 것에 대해서 어떤 책임을 가져야 하는지 생각해 볼 수 있는 기회가 되었길.”

  제대로 몸으로 느낄 수 있었다.

• 남이 짠 코드를 인수를 받아 일하는 경험도 처음이었는데, 이 부분에는 좀 아쉬움이 남는다. 기존 레거시 중에서 어디까지가 문제고 어디를 고쳐야 할까? 를 고민할 수 있는 시간이 거의 없었다. 또한 이 판단은 개인이 아니라 사업 담당자를 포함한 팀 단위에 판단으로 진행해야 한다.

• 위에 회고는 잘 정리되어 쓰긴 했지만, 프로젝트 막바지 당시에는 정말 심리적으로 많이 힘들었다.

  • 이미 2주 이상 달려왔던 시점에서 런칭을 하는데 그때도 자잘자잘한 문제들이 계속 발견되고, 스펙도 계속 추가됐다. (기간이 워낙 짧고 처음 운영하는 제품이다 보니 운영 버전을 올려보고 나서야 필요한 부분을 다시 개선하는 식으로 개발되었다.) 이미 심리적으로 지친 상태에서는 조그만 복잡도를 가진 문제도 어렵게 느껴졌다. 부하가 심하게 걸려서 일을 뽀개야 하는데 내가 뽀개짐. 못뽀개고 있는데 요청이 더 오면 내가 더 뽀개짐… 사실 두 번째로 들어가는 프로젝트에서 (인프라 제외) 백엔드를 전담한다고 하는 게 쉽지 않은 일은 맞지.

• “The more you feel dumb, the faster and more you’re gonna learn” 이라는 말이 있다. 이번 처럼 많이 스스로를 dumb하게 느낀 프로젝트가 없었고, 또 그만큼 많이 배운 거 같다. 끝나고 잘 쉴 수 있어서 회복됐다.

기타

• 일정 규모, 복잡도, 실시간성이 있는 서비스의 외주 개발은 언제까지 가능한가? 하는 생각도 들었다. 왜 많은 회사들이 높게 얼라인 되어 있고, 구현 안정성 높은 팀을 만들려고 하는지도 이해가 됐다. 좋은 프로덕트가 유지되려면 주인으로서 일해야 할 파트가 많다.