10월은 쓸 말이 별로 없을 정도로 신기능 개발에 올인한 한 달이었다. ^^; 개발이 마무리 되어 가는 시점에서 나름 기한도 잘 맞추고 팀원들과의 의사소통도 잘 해가면서 잘 마무리한 것 같(아보이)지만, 몇 가지 배운 점이 있어 정리할 필요가 있다고 생각해서 적어 본다.
10월 프로젝트로부터 배운 점들
1. PM이 된 것 처럼 제품을 자세히 분석하자
이번 프로젝트가 기존 프로젝트와 달랐던 점은 팀원들과 일을 거의 정확히 1/n으로 했고, 그 일들이 함께 깊이 연관되어 있었다는 거다. 입사 후 맡았던 프로젝트들을 돌이켜 보면 1. 혼자 프로젝트의 메인을 리드하거나 2. 나눠서 하더라도 거의 완전히 분리되어 있는 경우 두 가지 중 하나였다. 그런 경우 PRD와 티켓, Figma를 통해 제품의 얼개를 파악하고 개발에 들어가면 중간에 변경 사항이 있거나 잘못 이해한 부분이 있어도 내가 빠르게 수정하면 그만이었다.
하지만 여러 사람이 얽힌 작업을 나눠서 할 경우 개발에 들어가기 전에 좀 더 상세한 분석이랑 확인이 필요하다고 느꼈다. 내가 의존하고 있는 부분이 만약 명확하게 적혀 있지 않다면 명확한 정의를 요구해야 할 때도 있다. 왜냐하면 하나의 요구 사항 변경으로 나 혼자 고쳐서 되는 것이 아니라 불필요한 시간 낭비가 나 그리고 동료에게 두 배로 발생하게 되기 때문이다. 내가 의존하고 있는 작업이 마냥 완성되길 기다리기 보다는 그 진행 상황을 체크하고 잘못된 방향으로 가고 있다면 불가피하게 개입이라도 해야겠다고 생각했다. (개입이 필요한 이유로는 티켓으로 스토리 포인트나 작업 범위가 명확히 나눠져 있는 경우 선행 작업을 하는 사람은 기다리는 사람 만큼은 마음이 급하지 않다는 점도 있다.)
2. 분석한 내용을 기반으로 테스트를 먼저 작성하자
실제로 테스트를 MR에 포함시키지 않더라도 테스트를 작성하는 것이 좋겠다는 생각이 들었다. 당장 저번 주에도, 몇 주 전에도 먼저 테스트를 작성하는 것의 중요성에 대한 글을 봤는데도 실제 프로젝트에 착수하면 쉽지 않다. 하지만 이번 프로젝트에서 디자이너와 백엔드, 기획 사이에서 가교 역할을 자주 해야 하는 프론트엔드의 특성상 로직을 먼저 명확히 하고 개발에 들어가는 게 누구보다 필수라고 느낄 수 있었다. 개발 중간에 로직이 확정되고(나도 미처 파악하지 못했던 내용, 테스트를 작성하면서 로직을 천천히 따라가 봤다면 발견할 수 있을 수 있던 구멍이라고 느꼈다.) 작업한 내용을 갈아 엎는 과정에서 시간 낭비가 있었기 때문이다. 물론 이미 회사에서 활발하게 테스트를 작성하고 있고 그 과정에서 리팩토링하는 것만으로도 많은 도움이 되고 있지만, 다음 프로젝트부터는 수도-테스트라도 작성하고 시작하는 것으로 해야겠다. 이미 레퍼런스는 많았지만 내가 안하고 있었던 것 뿐!
댓글