cleanUrl: /retrospect/2019-second-half
2019년의 하반기는 정말 정신없었습니다. WWDC에서 쏟아져 나온 수 많은 내용들을 소화해야 했고, 사내에서는 교정 서비스라는 커다란 프로덕트를 런칭했죠. 번역서비스가 메인이었던 플리토에, 거의 동급의 서비스가 추가된 것이어서, 아주 많은 고민과 시행착오를 겪어야 했습니다. 그래도 그 과정에서 아주 많은 것들을 배울 수 있었어요. 교정서비스 런칭 회고는 추후에 별도로 포스팅 해보도록 하겠습니다.
이번 회고는, 지난 하반기 동안 제가 나름 잘했다고 생각되는 것들과 아쉬운 것들을 정리해 보는 식으로 작성해 보려 합니다.
이전까지는, 아무리 큰 규모의 코드를 작성 하더라도, 어디까지나 큰 프로젝트의 일부분을 제가 구현하는 방식이었다면, 교정서비스는 제가 프로젝트 하나를 온전히 작성한 프로젝트였습니다. 그러다보니 코드의 맥락을 팀원과 공유 하기가 매우 어려웠습니다. 팀원 입장에서는 계속 바뀌는 기획에 대한 팔로우업이 충분히 이뤄지지 않는 상황에서 오직 코드만 보고 코드의 의도를 파악하기란 굉장히 어려운 일 이었을 테니까요. 이런 상황에선 PR을 올려도 팀원으로부터 제대로 된 리뷰를 받을 수 있을 거란 기대를 하기 어려웠습니다. 이대로 PR을 올려서 approve를 받는 일은 요식행위 밖에 되지 않는다고 생각했습니다.
그래서 이 즈음부터 의도적으로 PR을 의식적으로 더욱 자세하게 쓰기 시작했습니다. 관련된 Jira티켓 링크는 물론이고, 구현한 화면의 작동 예시를 보여주는 동영상이나 이미지를 첨부하고, 기획의 의도나 기획이 바뀌게 된 배경을 충분히 설명하려 노력했습니다. 자연스레 PR을 작성하는데 꽤 많은 시간이 소요 되었지만, 이는 나중에 여러 형태의 보상으로 돌아왔습니다.
예를 들어, PR자체가 문서로서의 기능을 하게 되니, 리그레션을 잡아내는 일이 훨씬 쉬워졌습니다. 물론 기존에도 PR 및 커밋에 지라 이슈 티켓을 첨부해 리그레션을 예방 하려 노력 하고는 있었지만, 사람의 심리가 그 링크들을 일일이 열어보지 않게 되더라고요. 또 이슈티켓에서 논의되는 내용과, 그 논의의 내용을 코드로 구현하는 과정에서 논의해야 하는 내용은 별개 이기도 합니다. 그런 맥락에 대한 내용이 PR안에 있으니, 다음과 같은 방식의 작업방식이 가능 해졌습니다.
실제로 이런 작업 방식을 통해 예상치 못한 리그레션 몇 개를 잡아내고 나니, PR 작성에 들이는 시간은 별 것 아니게 느껴졌습니다. 버그를 수정 함으로써 새로 생긴 버그를 발견하기까지 적지 않은 시간이 걸리게 되고, 또 그렇게 늦게 발견한 버그를 수정 할 때 기존의 수정에 대한 맥락을 모르는 상태로 버그를 수정해서 또다른 버그를 낳고 …. 이런 과정에서 낭비할 시간들에 비하면, PR작성에 공을 들이는 것은 충분히 남는 장사인 것 같습니다.
간단한 사이드프로젝트로, 제 포모도로 앱에 지라를 연동시켜서, 포모도로 세션이 끝날 때마다 작업중인 티켓에 작업한 시간을 기록하도록 만들었습니다. 이 과정에서 “작업시간”도 지라가 관리하는 여러 자원 중 하나라는 것을 알게 되었습니다.
처음에는 그저, 제가 작업한 시간을 기록하는 용도로만 사용했는데, 이를 기록하고 보니 그림에 보이는 것 처럼 “Estimated”라는 개념이 있다는 것도 알게 되었습니다. 즉, 지라 티켓은 원래 “일정을 추산하고, 그 일정이 잘 지켜졌는지 트래킹하고, 또 회고 할 수 있는” 툴이었던 것이죠.