불필요한 QA팀 테스트 건너뛰기

사내에서 개발되는 코드는 개발자의 작업 이후로 여러 단계의 검수를 거친다. 개발팀, 기획/디자인팀, QA팀 등 여러 팀에서 서비스 동작을 확인하여 엔드 유저에게 노출될 때 문제가 없도록 한다. 이 과정은 버그나 기획 누락을 사전에 발견하여 우리 회사 서비스 품질 향상에 도움을 준다. 이 검수 단계가 중요하다는 것엔 아무도 이의가 없을 것이다.

다만, 나는 우리 회사에서 QA팀 테스트가 일부 불필요하게 진행되는 것들이 있다는 생각을 해왔다. 물론, 이 불필요해 보이는 검수 단계를 통해 얘기치 못한 side effect 를 찾아낸다거나 하는 긍정적인 측면이 있다는 것은 잘 알고 있다. 그치만 최근 QA 인원의 축소로 인해 QA팀 테스트 업무가 몰리게 되며 마일스톤 배포가 늦어지는 일이 있어서, 요즘 우리 회사가 서비스 안정성에 너무 발목잡히는 것이 아닌가 싶다.

서비스 안정성과 빠른 배포 사이에서 트레이드 오프(trade-off)의 적정선을 찾아야겠다. 99% 넘게 문제없다고 확신할 수 있다면 패스할 건 패스해도 된다고 생각한다. 나는 개인적으로 QA팀 테스트를 건너뛸 때가 많다. 제품개발과 거리가 있는 데이터팀 업무의 경우가 그렇고, 일부 서비스(제품) 개발도 마찬가지다. 간단한 버그 수정이나 간단한 기능 개발을 할 경우, 개발 검수와 기획 검수로 충분한 경우가 많다. 2중 안전망이면 충분하다는 얘기다. 혹시나 문제가 생겨도 서비스 다운까지 갈만한 것들이 아니므로 빠르게 수정하고 재배포하면 된다.

내가 작성한 코드의 영향 범위를 고려해서 그 범위가 국소적이어서 다른 feature 에 영향을 주지 않는 경우에는 QA팀 테스트를 건너뛸 필요도 있다고 생각한다. 테스트 코드의 커버리지를 높이고, 자신의 코드에 확신을 갖는 것이 필요하다고 본다. 그 영향 범위는 코드를 작성한 개발자가 제일 잘 알기 때문에, 때론 타직군의 팀원들에게 이상없을 것임에 대한 확신을 줘야할 줄도 알아야 한다는 얘기다.

장기적으로는 AI 를 활용한 QA 자동화 등으로 관련 업무 부하를 낮추는 방법이 요새 트랜드에 발맞춰가는 방안이겠다. 현실적으로 그에 필요한 시스템을 구축하는데 당장 어려움이 있으니 간단하게나마 부하를 경감시킬 방안을 생각하고 적어봤다.