24년 11월 회고

현회사의 팀은 한달 단위로 스프린트를 진행한다. 일이 바쁘다보면 시야가 좁아지고 일을 쳐내기 바쁠때도 있다. 그래서 개인적으로 좋았던 점, 아쉬웠던 점들을 돌이켜보며 더 발전하기 위해 스프린트가 끝나면 회고를 하려 한다.

회고는 KPT 방식으로 진행하며 앞으로는 Try에 작성한 방법들을 적용하며 Keep의 항목이 더 많아지는 것을 목표를 잡아본다.

Keep

기획 과정에서 개선 방안이나 아이디어를 많이 제안한 것이다. 그 덕분에 기능이 좀 더 견고해진 것 같다. QA 중 종종 A 케이스에는 어떻게 처리가 되는 건가요? 와 같은 질문이 올 때가 있는데 기획 과정에서 누락된 케이스들이 발견되곤 한다.

중요한 부분을 놓칠 때도 있어서 QA 중 기획 및 개발 수정이 들어가곤 하는데 이번에는 그런 부분들이 적었던 것 같다.

기획 단계에서 여러 사람이 의견을 낼수록 서비스는 더 견고해진다고 생각한다. 따라서 기획서대로 개발만 하는 것이 아닌 주도적인 참여를 계속 이어갈 것이다.

Problem

실수도 실력이다

PROD 배포 후 자잘한 버그를 4건이나 발견해 hotfix 배포를 진행했다. 개발 중 확인해야 했던 부분들었는데 실수를 했다는 사실에 정말 창피했다.

꼼꼼하지 못한 성격에 디테일을 놓친 것이 원인이었다. 기획서에 기재된대로 동작하는지 확인하는 과정에서 작은 부분을 놓쳐버렸다. QA를 통과했다고 완벽한 것은 아니기에 안심할 수 없다.

리소스에 따른 업무 중요도 판단

기존 서비스에서 일부 페이지만 분리해 별도의 서비스를 구축하는 작업이 있었다. 권한 관련 이슈들도 있어서 모든 경우의 수를 생각해 설계하다보니 flow가 좀 복잡해졌었다.

완벽해야 한다는 생각에 모든 경우의 수를 고려해 설계를 했지만 사수분께서는 좀 과한 리소스를 투자한 것 같다는 의견을 주셨다. 서비스가 완벽하면 좋지만 현재 서비스 자체가 디테일에는 크게 신경쓰지 않는 분위기이기에 자잘한 버그들에 대한 클레임은 잘 들어오지 않는 편이다. 따라서 아주 드물에 일어나는 예외적인 상황에 대비해 코드를 짜는 것보다는 기획쪽과 협의해 예외적인 상황에 대해서는 CS선에서 대응하며 더 중요한 이슈에 리소스를 사용하는 쪽이 더 합리적일 것 같다고 하셨다.

사수분의 말씀에 머리가 띵했다.. 리소스는 한정적이기에 이슈 중요도에 따라서 리소스를 분배해야 했는데 그러지 못했다. (권한 관련 flow로 고민하느라 며칠 야근을 해버렸다…)

그 리소스로 더 중요한 이슈에 투자했더라면 hotfix 배포는 안하지 않았을까 하는 아쉬움이 든다.

hotfix 판단 여부

hotfix 배포 전 관련 이슈들을 테스트하다 다른 자잘한 기존 버그들도 발견했다. 이번 hotfix때 같이 나가면 좋지 않을까? 라는 생각과 동시에 인증 관련 버그로 임시 방편으로 대체할 것이 아니라 구체적인 코드 분석이 필요하다고 느껴졌다. 그래서 같이 수정해서 나가야할지 고민이 들어 사수분께 문의했다.

사수분께서는 기존에도 있던 버그였지만 크리티컬하지 않으며 관련 클레임이 없었기에 급하게 대응하기 보단 기존 소스 분석을 통해 관련 이슈들을 정리해 제대로 수정하는 것이 좋다고 말씀하셨다.

물론 눈에 보이는 버그들을 수정해서 같이 나가면 좋지만 임시방편으로 대응하는 코드가 많아질 경우 나중에 유지보수도 힘들기에 hotfix 배포는 정말 중요한 이슈들이 발견된 경우에만 나가야겠다고 느꼈다.

Try

꼼꼼하지 못한 성격이라면 2,3 번 검토해서라도 완벽히 일을 끝내야 한다. 내 단점을 커버하기 위해 디테일에 집착해야 QA 중 발견되는 버그도 줄고 더 완벽하게 개발할 수 있지 않을까 싶다.

기획에 누락된 부분이 있다면 무작정 대응하는 것이 아니라 크리티컬한 이슈인지, 아니면 정말 드문 예외 케이스인지 판단하고 현재 리소스에서 대응할 수 있는지 고려해 이슈 개발 혹은 기획측과의 협의 방법을 선택해야 한다. 한정적인 리소스를 효율적으로 써야 한다는 것을 잊지 말자.