제품을 내보낼 때 그 누구도 외롭지 않으려면

나는 시방 이 구역의 지휘자여. 너는?

우리는 QA 조직이 따로 없다. 스타트업 선생님들 별로 안 놀라시는 거 다 알고 있습니다. 그래도 이건 정말 처음이야 싶었던 건 나름 작년 한 해를 통으로 쓴 큰 규모의 프로젝트였는데 QA를 PO인 나 혼자서 했다는 것. Admin, 모바일, IE, 크롬 QA를 한꺼번에 진행하면서 무슨 오케스트라 지휘하는 기분이 들었다. 오보에 음이 튄다고? 대체 오보에 소리가 뭔데? 뭐라고? 저쪽 팀파니가 박이 안 맞다고? 아, 박이 아니라 튜닝이 잘못된 거라고? 튜닝은.... 연주자가... 기본적으로... 연주 전에 맞춰야 되는 거 아니냐?(속마음)

QA를 할 때도 PO의 본분은 잊지 말아야 할 터 이슈를 쳐낼 수 있도록 정확히 리포트하고, 애초의 기획과 달라지는 부분이 있다면 별도로 정리해서 완료 이후에 이어서 진행하고, 이슈 처리가 완료되었으면 재빠르게 확인해서 작업자들이 흐름을 잃지 않고 순조롭게 작업을 마칠 수 있도록 돕는다. 왜냐고? 이 모든 문제가 짬뽕되어 '커뮤니케이션에 문제가 있었다'라고 결론이 나면 책임자는 PO이기 때문이다. 문제는 정신 차려보니 이게 내 거냐 여기서 나만 일해? 싶어 지면서 외로워졌다는 것이다. 이 글은 다음에는 제발 외롭지 않기 위해 정리해두는 글이다.  

Photo by Tim Foster on Unsplash

이 사달이 난 데에는 태초에 기획이 너무 사이즈가 컸다는 데 있다. 년을 묵힌 숙원사업의 출시였는데 그 정도도 각오하지 않았다면 너무 얕잡아본 거지. 리뷰는 문서를 완전히 익힌 채로 싱크를 맞추는 시간이 되어야 하는데 프로젝트에 프로젝트에 프로젝트가 꼬리 물고 이어지는 지금의 조직에서는 어려운 일. 게다가 새로운 인력이 자꾸 수급되는 상황이라, 어 이거 이대로 가면 안 되겠는데 싶어 졌다. 기획 단계 단계 뼈대를 세울 때부터 의견을 구하는 과정, 기획을 세우는 모든 단계에서 논의되는 내용과 정리된 문서를 (내가) 잘 공유해야 되고, 2차적으로는 받아본 사람들이 소화하려 노력해주어야 한다.(교과서 같은 얘기지만요...) 어차피 검토 안 하고 착수부터 한다고 개발기간이 줄어드는 건 절대 아니니까요. 선생님들 다들 짬에서 나오는 바이브로 아시잖아요. 왜 같은 실수를 반복하며... 내 나름대로는 작업자 일일이 충분히 소화가 된 게 맞는지 확인을 해야 되는 건데 그 방법을 회고에서 좀 찾아봤다. 내가 작업자를 태그 하고,  메일에 cc를 건다고 디테일이 챙겨지는 건 아니더라. 적어도 태깅을 한 부분에 대해서는 답변을 받을 수 있도록 합의가 돼야 할 것 같다. 기획 초기부터 유관팀의 의견을 반영하는 건 당연한 거고.

또한 New comer를 언제나 고려해야 한다. 회사 제품들에 통합으로 쓰이는 부분이 있었는데 그 부분은 이미 정의되어있는 것을 그대로 쓰되 추가로 새로 정의되어야 될 부분이 있으면 그 부분을 정의하는 방식으로 진행했다. 이렇게 기획이 될 때에는 기존 시스템의 볼륨이나 히스토리를 잘 아는 사람들이 붙었어야 했지만(이하 생략) 조직 내의 사람이라면 당연히 이 정도는 싶은 것들도 리뷰에서 한 번씩 짚고 넘어가야겠다. 그래야 결과물을 받아 들었을 때 놀래지 않을 수 있을 것 같다. 가령- 기획서에 뻔히 정의되어있는 것들이 상이하다든지, 걱정돼서 몇 번이나 따로 명시한 부분이 전혀 개발에 아예 고려되지 않는다든지.

본격적으로 QA를 진행해보면서 힘들었던 건 물론 인력 사정 상 이번 작업자분들이 이번 작업에 최적인 분들이 아니었고 나도 그 부분을 감안했지만 기능만으로 봤을 때 마땅히 되어야 될 동작(가령 등록된 데이터와 상세화면에서 보이는 데이터가 같아야 함)이 제대로 된 게 별로??? 한번 flow를 보는 데까지 일주일이 넘게 걸렸다. 이 기간이면 디자인 QA까지 마쳤어야 할 기간이었다. 각 flow(앞/뒤 동작)에서도 동작이 미비하여(입력이 완료되었는데 상세화면으로 안 간다거나, 삭제하면 리스트에서 빠져야 된다는데 안 빠진다거나, 토스트 메시지가 동작이 완료되기 이전에 표시된다거나, 선택 후 그 화면을 빠져나갔는데도 선택이 유지된다든지) 아, 정말 이렇게 마무리되면 될 것 같나요 싶은 것들이 많았다. 회고를 진행하면서 그 답을 찾았다. 이번 프로젝트에서 개발팀 입장에서 테스트 구축을 초창기에 제대로 못했었다고.... 아... 그럼 이 구역에서 flow 보는 사람이 정말 나밖에 없었던 거네요. 물론 담당자분들도 다음엔 개선하겠다고 회고에서 언급해주셨기 때문에 다음에는 괜찮아지지 않을까 생각한다. 선생님들, 아니 어떤 상황에서도 개발 QA는 너무나도 중요하다고요 얼렁뚱땅 넘어가지 말자...

제일 난감했던 건 되던 게 안되고 전체 QA의 의미가 없어지는 순간들. 사이드 이펙트는 사실 어쩔 수 없는 부분이지만 예상되면 QA를 당연히 받고 제품이 나가야 되는 것 아니겠어요? 프로젝트가 정신없이 진행될 때는 최대한 싱크를 맞추기 위해서 아침에 잠깐이라도 스크럼(.... 네 그 악명 높은) 회의를 해야 하지 않을까 목소리가 나왔다. 급한 이슈를 체크하고, 배포가 언제 될지 체크하는 거지. 지라(JIRA)로는 한계가 분명했다.

---

외롭게 일하고 있을 스타트업의 PO선생님들께 이 글을 바칩니다. PO라고 무조건 혼자 다 짊어질 짐은 아니죠. 혼자 짊어져야 했으면 내 연봉이 여기에 머무를 리가 없다. 어느 집단이나 빌런은 언제든지 존재하며 그런 제약조건 속에서 다음을 위해 어떤 프로세스를 만들어가야 할지 고민하는 게 우리의 역할 아니겠습니까. No More 자책. 기록으로 남겨두는 이유는 다음에는 작업자를 포함하여 누구도 개고생 하지 않았으면 하는 바람으로. 나도 덜 외롭고.