요즘 비디어스 리뉴얼 QA를 진행하고 있다.
QA는 Quality Assurance의 약자로 ‘품질 보증’이란 뜻을 갖고 있는데,
서비스의 기능을 검증하고 관리하기 위한 작업이다.

큰 조직에서는 QA를 전담하는 팀이 있기도 하지만,
규모가 작은 경우에는 1명이 맡거나 팀 전체가 다 같이 조금씩 나눠서 진행하기도 한다.
우리 회사는 나 혼자 QA를 하고 있는데, QA를 할 때 나는 종종 딜레마에 빠진다.

왜냐하면 나는 여러 롤을 맡고 있기 때문이다.
QA 담당자이기도 하지만, 전체적으로 서비스를 관리하는 PM이기도 하고 또 회사의 대표이기도 하다.
QA 업무를 하다보면 요구사항에서 주문했던 ‘모든’ 기능을 ‘완벽’하게 구현되도록 하고 싶은 마음이 생긴다.
그리고 처음 QA를 했을 때는, 그것을 목표로 진행했었다.
하지만 여러 차례 QA를 하면서 깨달았다.
모든 것이 완벽하기란 불가능에 가깝고, 모든 것이 완벽하지 않아도 된다는 것을.
완벽보다는 서비스의 핵심 가치를 전달할 수 있는 품질인지가 중요했다.
그러한 품질이라면 요구사항과 조금 다른 부분이나
마이너한 버그나 코너케이스 같은 이슈들은
오히려 진행하지 않고 일정을 맞추고 추후 개선으로 진행하는 것이 더 나은 의사결정이라고 생각하게 됐다.

이제는 이것을 확실히 알고 있지만, 막상 QA를 하면 고민이 되는 지점들이 생긴다.
예를 들면 안내 문구 2줄을 표기하는데
기획서 요구사항은 가운데 정렬, 일정 간격 띄우기인데
실제 개발은 왼쪽 정렬로 텍스트가 간격 없이 붙어 있다고 가정해보자.
QA 담당자로서는 디자인을 수정하고 싶지만,
또 PM으로서는 일정 내 QA를 마치고 빠르게 오픈을 하는 것이 중요하다.
그래서 수정을 하고 싶지만… 추후 개선 일감으로 넘기는 경우가 있다.
이렇게 갈등이 생길 때는 해당 이슈가 ‘이번 리뉴얼 목표에서 해결이 되어야 하는 부분인지’를 기준으로 판단을 한다. 혼자 결정하기 어려울 때는 팀에 의견을 구하기도 한다.
(대표의 자아는 거의 넣어두어야 한다. 안 그러면 너무 간섭이 심해서 진척이 안된다.)

여러 자아를 적재적소에 꺼내어 저글링 할 줄 아는 내가 되기로 다짐해 본다.
(당분간 대표 자아는 들어가 있기로)