자, 가볍게 QA 한번 돌릴까요?
어느 주니어 PM의 회고
네카라쿠배와 같은 큰 조직이나 체계가 잡혀있지 않는 소규모 스타트업이나 중소기업에서 커리어를 시작하게 되는 서비스기획자 또는 프로덕트 매니저는 정말 많은 태스크를 직접 만들어보고 체험할 수 있는 경험을 가질 수 있다. 누군가는 이 부분을 레거시 하게 볼 수 있지만, 또 어느 누군가는 레거시라고 생각하는 일들에서 새로운 인사이트와 가치 그리고 배움을 찾아낸다.
최근 들어 나는 프로덕트 매니저로서 직접 QA문항을 구성하고 직접 진행해 보았다.
한 줄 소감으로는 정말 'QA는 쉽지 않다.'였다.
그러면서도 직접 해보는 체험을 통해서 얻은 프로덕트 매니저로서의 인사이트 3가지 정도가 있어 공유해 보겠다.
QA는 단순히 잘 작동하는지만, 살펴보는 과정이 아닌 '서비스'에 대한 관심이다.
주니어 기획자들이 많이 하는 실수는 단순히 '기획'만 열심히 한다는 것이다.
더 좁혀 들어가면 '신규 기능에 대한 기획'만 진행하려는 경향이 있다는 것이다.
이미 구현된 기능에 대해서는 전임 기획자나 전임 개발자에게 기능에 대한 히스토리를 찾기 급급해하고 불편하게 생각만 할 뿐이다. 불편함을 전달하는 기능에 대해서 '왜?' 이 기능이 이 당시에 도입될 수밖에 없었는가?'에 대한 고민을 하지 않는다는 것이다.
나 또한, QA 초기에 이 부분에 대해 생각해 보기보다는 '이건 작동돼야 하는데, 왜? 작동되지 않는 거야?'라는 오직 '작동'에 대한 부분에만 불만을 느꼈기 때문이다.
QA과정은 어쩌면, 우리 서비스의 전반적인 흐름과 상태를 진단해 보는 '건강검진'과 같은 프로세스라고 생각이 들었다.
그리고 서비스에 대한 관심과 고뇌를 더하게 되는 계기가 되었다.
QA는 단순히 QA담당자만의 일이 아닌 오히려 '기획자'도 세심히 봐야 할 부분이다.
우리가 이용하는 서비스 중에 가장 완벽한 서비스가 과연 무엇이 있을까?
생각나는 서비스가 있는가? 내가 완벽하다고 생각하다고 하여 남도 똑같은 생각을 가지고 사용할까?
우리의 서비스들은 하나하나 살펴보면 완벽한 구조를 취하는 것 같지만, 불안하고 어설픔의 연결의 연속성이고 그 속에 불안전성이 늘 가지고 있다. 이는 어쩌면 서비스를 기획하는 사람도 서비스를 개발하는 사람도 영원히 해결하지 못할 숙제일 것이다.
늘 불안정함 속에서 해결책을 찾으려는 삶의 생리가 단지 '앱 서비스'에 녹여 들어가 있을 뿐이기 때문이다.
QA를 진행하다 보면, 분명 기획과는 다른 의도의 값을 배출하거나 작동 및 연관되는 기능들을 만날 수 있을 것이다. 그저 '작동' 기준에서만 보면 PASS 값을 줄 수 있지만, 넓게 보면 이것은 결국 개발 로직과 더불어 서비스 작동 로직에 큰 오류를 가져다줄 수 있는 큰 경고라고 볼 수도 있다.
여러분이 사용하는 서비스 중 흔히 '나이스하다'라고 여겨지는 모든 서비스들은 '업데이트'라는 관문을 거치기 전에 치열한 검증과 테스트를 통과하여 99.99999% 이상의 사용 안전성을 거쳤다고 판단되었을 때 세상에 나온다.
( 단, 1%는 어쩌면 QA로 통제할 수 없는 불가항력의 그 무엇을 이야기한다. 그리고 존재한다 )
QA를 무시하는 조직은 결국 무너지는 모래성이 될지어다
정말 감사하게도 내가 커리어를 만들어오면서 겪었던 모든 조직은 QA에 대해 중요하게 생각하였고 심지어는 대표님을 포함한 모든 인원들이 QA테스트를 진행하기까지 하였다.
하지만, 최근 들어 이 마저도 외주화를 진행하려는 조직들을 정말 많이 만나고 봤다.
여러분들이 사용하는 수많은 앱서비스들 중에 간혹 사용성이 무지하게 불편하거나 조잡하고 툭하면 잦은 업데이트를 진행하는 서비스들을 만난 적이 있을 것이다.
물론, 잦은 업데이트를 잘못하고 있다고 탓하는 것은 아니지만, 업데이트를 했음에도 문제가 계속해서 발생하고 특정 문제가 계속 발생하는 서비스들은 사실 자체적인 QA가 심도 깊게 진행되는 것이 아닌 구색만 맞추기에 집중하여 '출시'만 중요하게 여기는 경우가 많다.
예전 같은 경우에는 오직 '기능적'으로만 서비스롤 평가하고 빠르게 출시하는 것이 미덕이었다.
하지만, 지금은 한 번의 잘못된 출시가 사용자 경험 신뢰 하락과 브랜드 신뢰 하락으로 직결되는 시대이다.
아무리 스타트업에서 '속도'가 중요하다고 하나, QA가 제대로 진행되지 않은 출시는 마치 안전벨트 없이 출시된 자동차와 같다고 생각해 주면 좋겠다.
QA는 양식이 중요하는 것이 아닌 모든 조직원들이 한번 진행해 보는 '자세'가 중요하다고 이야기하고 싶다.
많은 IT업계에서는 고정된 문서양식은 없다.
오직, 그들의 조직에 맞게 편하게 재가공될 뿐, 그 재가공된 구성이 때로는 표본 답인 듯이 교육을 시키는 곳이 있지만, 다시금 묻고 싶다. '과연 IT업계에 표준화되고 고착화된 문서라는 개념이 존재는 한가요?'.
그러니 QA양식에 고집하기보다는 빠르게 한 사이클을 시도해 보는 것을 추천한다.
( 양식과 방법을 찾아주는 채널은 정말 많다. 단, 그것이 절대적이라고 맹신해서는 안된다)
QA를 마무리하고 시계를 바라보니 새벽 2시를 향해 시간이 가고 있었다.
1~2차까지 QA를 진행하였다고 해서 완벽하다고 볼 수는 없다. 항상 완벽에 가까운 서비스를 제공하기 위한 '시도'만 있을 뿐이다.
그럼에도 QA를 하는 것은 서비스를 기획하고 제공하는 사람들의 최소한의 예의이자 도리라고 생각한다.
그래서 나는 QA를 오늘도 진행한다
