안녕하세요. 오늘따라 제가 하는 일에 대해 이러저러한 생각이 많아 저 스스로 한번 정리해 보고 싶어 처음으로 PGR에 글을 써보려 합니다.
PGR에는 IT직종에 계신 분들도 많은 것 같아 프로젝트QA라는 직무에 대한 일반화는 어렵겠지만, 그런 직무가 있고 그 직무의 QA는 이런 고민도 있다는 것만 알아주시면 감사하겠습니다.(사실 온라인 게임을 하지 않는 제가 이 곳을 알게된 건 첫 직장의 입사동기가 알려준 유머게시판 URL이 PGR이어서 IT직종 분이 많겠구나 막연히 생각하고있니다. 크크크.)  뻘글일수도 있으나 어쨌든 '자유'게시판이니 올려봅니다. 서론이 길 수도 있습니다.

제가 하는 일은 SI 프로젝트의 QA입니다. 대부분의 QA처럼 처음은 개발자로 시작했다가 QA직종으로 업무를 변경한 케이스입니다. 개인적으로 개발자는 생각하는 게 창의적이거나 똑똑해야 한다고 생각하는데 아무리 생각해봐도 전 임시방편용의 꼼수는 잘 쓰지만 창의적인 생각은 부족하다고 생각했고 골똘히 생각하는 것 보다는 이것저것 맞춰보고 검증하고 빨리빨리 처리할 수 있는 일을 좋아했기에 QA를 택하게 되었습니다. 그래도 개발경력이 짧게라도 있었던 탓에 설계자/개발자들과 커뮤니케이션이 되는 점은 다행으로 생각하고 있습니다. 그리고 그런 이유로 아래서 얘기하겠지만 직무는 QA라도 일부 '감리도 아니면서 감리인의 권리만 갖는 QA'를 싫어하기도 합니다.

대부분의 사람들이 QA라고 하면 소프트웨어 QA(SQA)나 테스팅 위주의 QA/QC를 생각합니다. 프로젝트QA가 하는 일은 SQA와 비슷하면서도 조금 다릅니다. SQA가 테스트전략/시나리오 수립, 테스팅자동화, 테스트 수행 결과도출 및 이슈관리등을 위주로 진행한다면 프로젝트QA는 프로젝트 착수부터 최종검수까지 업무(Task)위주로 각종 계획과 실적을 관리하고 개발 아웃풋을 검토하는 역할을 맡습니다. 간혹 SQA처럼 테스팅전략이나 시나리오 도출을 직접하기도 하지만 아무래도 SQA보다는 전문성이 떨어집니다. 기본적으로 개발산출물을 검토하기 위해 업무회의에는 참석하지만 해당 시스템/업무의 전문적인 테스팅설계를 하기에는 부족하니까요.

SI프로젝트를 하신 분은 잘 아시겠지만 PM의 업무 스타일에 따라 QA에게 요구하는 것이 상당히 다릅니다. 보통은 앞서 기술한 업무를 하지만, PM에 따라 시스템/소프트웨어의 전수테스트를 요청하시는 분도 있고, 사업관리(인력, 비용, 계약 등) 업무를 요구하시는 분도 있으며 심지어는 개발 산출물을 작성해달라고(?!) 하시는 분도 있습니다. 그렇게 소속 회사에서 계약한 조건에 맞춰져 QA에 대한 저 스스로의 가이드라인이 없는 상태로 일을 하다 보니 프로젝트 QA로서 앞으로 어떤 입장에서 업무를 해야 할까라는 고민이 깊어지고 있습니다.


1. 트집만 잡는 시어머니인 것도 같고
1년 미만의 프로젝트에 참여 시 제가 접한 대부분의 기획/디자인/개발자 분들이 QA를 보는 입장이었습니다. 바빠죽겠는데 맨날 문서 작성하고 수정하라고 요구한다며 싫어하십니다. 그리고 사실 위에서 말한 '감리인의 권리만 갖는 QA'도 이런 케이스의 극단적인 예라고 개인적으로는 생각합니다. 그리고 계약조건에 따라 저도 이렇게 일한 적이 있습니다.
이런 경우 정말 기계적으로 일합니다. 업무(Task) 종료 X기간 전에 제출 요청을 하고, 기일 내 제출하지 않을 경우 고객에게 보고를 합니다. 제출기간 내 제출한 산출물은 검토해서 정말 자잘한 보완사항까지 지적하고 기록해서 보완요청을 하고, 보완이 되지 않을 경우 또 고객에게 지연사항으로 보고를 합니다. 사실 보완 필요한 내용은 요건과 분석/설계 내용 간 데이터 정합성이 맞지 않거나 요건이 명확하지 않아 발생한 설계 로직 오류가 대부분이라 담당자와 얘기하고 정리해 보면 금방 보완할 수 있지만 개발산출물 수정에 직접적으로 관여하는건 본래의 QA 업무와 역할이 아니니까 하지 않습니다.  또한 이런 케이스는 개발산출물에 대해 어떤 항목이라도 QA가 절대 본인이 직접 수정하지 않아야 하기 때문에 심지어는 문서 헤더나 목차가 표준과 상이하다는 내용을 리포트하기도 합니다. (......)
이 경우 장점은 일이 적다는 점에서 편합니다. 요청하고, 재촉하고, 지적하고, 시정조치 확인만 하면 됩니다. 하지만 감정적으로 불편하게 됩니다. 어쨌든 QA도 따지자면 프로젝트팀원인데 남 일처럼 요청하고, 고객에게 보고하고 이슈화 시키게 되어버리니까요.


2. 풀타임 서포트 며느리인 것도 같고
SQA인 경우 당연히 시어머니가 되어야 하고 지적하는게 맞다고 생각하지만 제 생각에 프로젝트 QA는 조금 다르다고 생각해서 며느리 케이스도 생겼던 것 같습니다. 이 또한 중/소규모 프로젝트에 참여시 대부분은 사업관리자 및 설계자가 따로 없기 때문에 PM지시로 많이 겪는 일입니다. 이 케이스의 PM께서는 산출물 작성은 개발이 아닌 문서작업이니 QA가 하라고 지시합니다. (QA는 문서작성자가 아니라 co-work에 가까운데... 왜죠?) 정형화되지 않더라도 어쨌든 확정된  내용을 전달 받는다면 문서화야 QA가 할 수 있지만 대부분의 며느리 케이스는 각종 회의에 QA를 참석시키고 분석/설계 산출물을 QA가 작성하라고 합니다.(QA인가 설계인력인가?!) 요건분석이나 화면/프로그램 설계가 개발업무가 아니라 산출물(문서)만 단순히 작성하는 일이라고 판단한 사유는 정말 모르겠지만, 소속된 회사에서 개발산출물 작성여부에 참여한다고 계약을 했으니 지시대로 하긴 합니다. 인터페이스/프로그램설계서등 도 작성이 힘들다고 해서 소스에 가급적이면 프로그램/메소드별로 주석 달아주면 파악해서 문서화하겠다 요청한 적도 있고, 업무가 바빠 스토리보드 리버전이 어렵다해서 UI/UX 확인 가능한 URL만 알려달라, UI와 Interaction은 테스트해보고 업데이트하겠다 말씀드리고 산출물 작성하기도 했습니다. 그 과정에 숱하게 기획/디자인/개발 팀과의 커뮤니케이션이 진행되고 내가 프로젝트 개발팀인지 PMO파트인지 모호한 생각이 듭니다만, 아이러니하게도 마음은 편했습니다. 모든 요건과 분석/설계내용과 세부적인 개발내용을 파악하고 있고, 데이터매핑/로직의 오류 또한 수시로 대화하여 없거나 해소된 상태이며 단계별 산출물은 역할 상 그럴일은 없지만 제가 책임지고 대응할 수 있는 수준으로 변경/업데이트된 상태입니다. 명백히 따지자면 QA가할 업무도 아니고 책임질 수도 없는 역할이지만 그냥 제 맘이 편합니다.


3. 어머님은 내 며느리?
경력 9년, QA만 만 6년 이상이 된 지금, 정말 딱 애매한 커리어라 많은 생각을 해보는데 답이 나오지 않습니다. 앞으로 시어머니가 되어야 할지 며느리가 되어야 할지 QA로서 어떻게 업무를 해야할지에 대한 고민이 많아졌습니다. 물론 대부분 생각하시는 관리적인 차원의 이상적인 결론은 있습니다. 어머님과 며느리를 같이하는 방향으로 가급적이면 검토/리뷰 중심인 시어머니 입장에서 진행하지만 필요한 경우 며느리 역할을 하는거죠. 아웃풋 검토는 일정, 품질을 준수하는 방향으로 통보하고 피드백 및 시정조치 방향에서 제가 서포트를 하여 같이 작업을 하면 좋을 것 같았거든요. 그런데 7년동안 그런 이상적인 케이스가 정말 단 한건도(!) 없었기 때문에 이런 방향을 기대해도 되는지에 대한 신뢰가 없습니다. 그렇다고 직무를 버릴 수 없는 이유가 사실 저는 시어머니 역할이든 며느리 역할든 업무도 시스템도 환경도 다양해서 이것저것 보고 익힐 수 있는 QA 직무가 아직은 즐겁거든요. 시어머니 역할도, 며느리 역할도 배우는 게 많고, 즐거운데 참 절충하기가 너무 어렵네요.

QA는 하고 싶고, 시어머니/며느리 역할을 선정하긴 어렵고, 왔다갔다하자니 고민은 깊어지고,참 재밌으면서도 어렵네요.
뭐 요즘 말대로 평균수명 8-90세면 앞으로 최소 3-40년은 더 일해야 할텐데, 전 심심하게 일하고 싶지 않아서요.