김범준님이 주변 개발자에게 세번씩 읽어보라고 했다는 QA != 통합테스트를 읽었다. 세번을 읽지는 않았다. 예전 부터 충분히 경험해왔던 너무나 익숙한 내용이었다. 덕분에 오래전부터 얘기하고 싶었던 QA에 대한 이야기를 해보고 싶어졌다.

나는 오페라 소프트웨어에서 오페라 미니의 한국 웹사이트 랜더링 품질을 담당했었다. 길지않은 기간이었지만 정말로 뛰어난 사람들하고 일했고 많은 것을 배웠다. 지금 내가 가지고 있는 제품이나 품질, 프로세스에 대한 생각과 태도는 그때 만들어 졌거나 그때의 경험을 토대로 이후에 곱씹어 보면서 형성된 것이다.

처음에는 BTS 사용 방법을 배울 정도로 QA에 대해 무지했다. 맞다. 그 누구나 다 안다고 얘기하지만 제대로 쓰는 사람은 거의 본 적 없는 버그 트래킹 시스템 사용법 말이다. 버그의 생명주기 말이다. 왜 버그가 항상 존재할 수 밖에 없고 우선순위는 어떻게 정해야 일이 돌아가는지 그런 하찮아 보이지만 굉장히 중요한 프로세스에 대한 내용들을 먼저 배웠다. 다들 신입때나 배우는 지식이라고 말하는 그런 것들이었지만 주변에서 제대로 알고 있는 사람은 거의 찾아보기가 힘들다. 하지만 나는 지금의 내가 있게 해준 소중한 지식과 경험이었다고 생각한다. 개중에는 퇴사하고 몇 년이 지나서야 왜 그렇게 설계가 됐으면 어떻게 작동하는 시스템인지 깨달은 것도 있다.

어마어마어마하게 많은 테스트 케이스가 있었고 테스트 케이스의 종류도 다양했다. 제품별로도 다르고 테스트가 돌아가는 환경도 다르고 자동화가 가능한 테스트도 있고 눈으로 확인하는 테스트도 있고 테스터가 액션을 취해야 하는 테스트도 있었다. 지루한 테스트도 있지만 흥미로운 테스트도 있고 코어 엔진에 대한 버그 발견과 분석, 테스트 케이스 제작은 정말 흥분되는 일이었다.

버그를 트래킹하면서 빌드에 따라 테스트를 잘 통과하는지 확인도 해야하고 결과적으로 버그가 리그레션 없이 잘 수정됐는지 판단해야 한다. 개발자들이 쉽게 테스트를 돌려서 리그레션이 발생하는지 확인할 수 있게 해야 한다. 버그를 개발자가 수정할 수 있게 테스트 케이스를 만들고 이를 자동화 시킨다. 전세계 오피스에서 만들어지는 다양한 테스트 케이스를 수집하고 관리할 수 있는 툴을 만들어야 하고 쌓여있는 테스트 케이스들을 관리하고 개선해야 한다. 이런 품질 관련된 전반적인 일을 QA가 한다. 테스트로 시작하지만 훨씬 더 복잡하고 다양한 기술이 요구되는 일을 하는 것이 QA이다.

품질이 적정 수준으로 유지될 수 있게 업무 프로세스를 만들고 유지하는 일도 해야 한다. 사용자로부터 유입된 버그도 찰떡같이 알아듣고 미니마이즈해서 개발자가 문제를 해결할 수 있게 한다. 그리고 또 다시 검증한다. 숙련된 QA는 개발자에게 구체적인 코드 라인까지 말해주면서 고치라고 알려주기도 한다. 개발자가 자기 도메인에서의 전문성을 발휘할 수 있게 해주고 이를 프로세스에 태워서 제품에 랜딩시키는 일은 QA의 일이다. 제품의 품질과 속성을 너무 잘 알고 있다보니 혁신적인 아이디어가 QA 팀에서 나오기도 한다. 물론 너무 혁신적이어서 논쟁이 커지기도 하지만 그러한 논쟁을 만들고 이 역시 설득하고 제품화 해버리는 것이 QA이다. 결국은 품질이 올라가니까.

그 이후로 나름 큰 회사들을 다녔는데 그 때 만큼 품질 관리 프로세스가 잘 돌아가는 회사는 볼 수가 없었고 고구마만 먹었다. 대부분의 QA 조직은 테스트 지원 조직이었지 제품에 대한 권한이 없었다. 오히려 버그 리오픈이나 우선순위를 협상해서 어떻게든 그 형식적인 절차를 넘어가게끔 해주는 무기력한 경우가 대부분이었다. 물론 나름의 전문성은 분명 있었으나 업무 프로세스 상에서는 테스터 이상의 역할을 수행하지 못했다.

그럼 실질적인 품질과 제품의 안정성은 누가 책임지는가 봤더니 대부분 개발자들이 그 역할을 겸하고 있었다. 개발자가 개발도하고 수정도하고 시스템이 안정적으로 작동할 수 있게 관리도 해야 한다. 대표적으로 페이스북이 이런 시스템을 가지고 있다고 한다. 하지만 우리는 페이스북 개발자가 아니다. 언뜻 보기에는 합리적인 것 같지만 여기에는 큰 모순이 있다.

대규모 수정 작업을 진행해야 할 때 수정한 코드가 잘 돌아가고 리그레션이 발생하지 않게 누군가 확인을 해주는 상황과 그것을 자신이 감당해야 하는 상황중에 보다 도전적이고 혁신적인 자세로 업무를 진행할 수 있는 경우는 어느 경우일까. 우리는 통상 개발자에게 혁신을 원하지만 반대로 보수적인 안정성도 같이 요구한다. 우리는 보수적인 개발자를 싫어하지만 개발자가 보수적이 되는 원인은 우리가 제공한다. 개발자가 혁신을 추구하지만 문제가 발생했을 때 이를 스스로 극복해야 한다는 것을 알게되면 감히 도전적이 되기 어렵다. 좋은 조직장이나 동료가 있으면 어느정도 커버가 되고 그런 회사를 우리는 좋은 회사라고 말하지만 감히 말하건데 건강한 QA 문화가 있다면 상황은 훨씬 좋아질 것이다. TDD나 코드리뷰만 좋은게 아니다.

보통의 웹서비스들은 그렇게 복잡하지 않다. 그래서 오히려 별도의 QA 조직이 필요 없어도 되는지 모르겠다. 하지만 건강하지 못한 구조라는 생각은 떨쳐버릴 수 없고 개발자들의 성장에도 걸림돌이 되는 것 같다. 뭔가 이러한 현실에 적합한 발전된 QA 프로세스가 필요하다는 생각도 들지만 QA를 떠난지 오래되어서 확신은 없다.

품질이 낮다면 QA가 부끄러워해야 한다. 개발이나 기획 탓 할 일이 아니다. 그정도로 QA에게 역할이 주어지고 책임과 권한이 따라갈 때 비로소 품질이 관리될 수 있다. QA가 정말로 품질을 보증할 수 있는 그날을 위해 화이팅!