2014. 12. 28. 21:28

2014년 12월, (11월 한 달 간의 지인 CBT를 마치고) 소프트웨어 품질 연구소를 오픈하였습니다. 필자와 필자의 지인들이 이 웹사이트에서 하려고 하는 일 중 하나는, 여러 사람들을 만나고 인터뷰하여 대한민국 QA가 가진 문제점을 현실직시하려고 하고 있습니다. 가능한 국내 소프트웨어 업계의 품질관리와 QA를 업으로 가지고 사는 사람들에게 많은 문제점들을 도출해 내고, 이를 구분한 후 어떻게 개선해서 대한민국 소프트웨어 업계의 품질 수준을 높일 지에 대해 연구하려고 하고 있습니다.


당초 예상과 다르게 도와주겠다던 전문가들의 도움의 손길이 점점 줄어들고 있는 점은 안타깝습니다. 어쩔 수 없이 또 저 혼자 공부해서 이런 저런 내용을 채워 넣어야 하는 상황이 오게 될 듯 하네요. 원래 해당 사이트에 올리는 글은 최소 3인 이상의 전문가 집단에게 리뷰를 받은 후 개재하려고 하였었습니다. 이 프로세스를 준비하는 과정이 좀 길었던 듯 하네요. 다들 남을 욕하는 것은 쉽지만 열정을 지속적으로 불태우는 것은 어려운가봅니다. 지금 이 글을 리뷰해 주시고 댓글로 의견 주신다면, (연락 가능한 방법을 알려주시면) 개인적으로 찾아 뵙고 커피 한 잔 사겠습니다.


많은 분들을 만나고 의견을 들었습니다. 그 과정에서 가장 많이 받은 질문과 이야기는 대략 이렇습니다.

  • "15년/20년 동안 많은 QA들과 일 해 보았지만, QA가 뭐하는 사람인지 난 아직 모르겠다."
  • "QA와 함께 일해서 좋은 기억이 별로 없다."
  • "QA의 업무 실체에 대해 네가 나에게 좀 알려다오."
  • "QA로 경력은 쌓고 있는데, 이대로 계속 가야할지 개발자가 되어야 할지 고민이 된다."
  • "개발 경력에서 QA로 옮기려고 보니 막상 개발 품질에 대해 심각히 생각하는 조직이 없다. 옮겨도 되나?"
  • "QA는 뭘 해야 하나?"
  • "QA와 Tester는 뭐가 다른가?


더 많은 질문들이 있지만 대부분 (1) QA라는 업무에 대한 궁금증과 (2) QA가 어떤 식으로 품질을 확보하는지 (3) QA가 어떤 방향성을 가지고 업무에 임해야 하는 지 등에 대한 질문들이었습니다. 사실 이런 부분들은 필자 역시도 2010년부터 계속 고민하고 있었고, 이를 해결하기 위해 다양한 공부를 하고, 다양한 분야의 전문가들을 만났습니다. 그리고 결국 어떤 회사에서 조직의 장으로써 차년도 계획을 세울 때 '이상적인 QA가 무엇인가'에 대한 공감대를 조직 내에 형성하기 위해 아래 그림의 초기 버전을 그려 배포하였습니다. (아래 그림은 한 차례 업그레이드 한 내용입니다.)


서론이 너무 길지만, 시작하기 전에 하나 확실히 하고 싶은 것은 아래의 글과 그림은 단지 "필자가 생각하는 이상적인 QA와 조직적 품질관리 접근방법일 뿐"이라는 점입니다. 본 그림과 본 글은 원래 Test Engineer, QA Engineer로써 현업 종사자들이 자기자신의 현황을 돌아보고 발전해나아갈 수 있도록 조언하는 데에 원래 글의 의미를 두고 작성하기 시작하였으나, 혹시라도 관심 있는 상위관리자분들이 보신다면 역시 스스로 생각해 볼 수 있는 거리를 제공하기 위해 추가적인 내용들을 덧붙였습니다.


즉, 본 글은 품질 조직의 '조직도'를 제안하는 것이 아니라는 말씀을 드리고, 이 부분을 강조하고 싶습니다. 소프트웨어 개발 조직의 품질은 결국 제품의 생산에 대한 총 책임을 지는 본부장(Director) 이상 급이 결정하게 되는데, 이런 의사결정권자들이 자신들의 사업에 맞추어 고려하여 구성하는 것이 조직도입니다. 품질조직의 관리자 급이 조직도를 구성할 수는 없음을 이 글을 읽으시는 독자분들께 미리 고지드립니다. 이 글에서는 단순히 테스트나 품질을 업으로 삼으시는 분들께 이런 식의 경력(career path)도 가져갈 수도 있다는 점을 말해주고 싶었고, 또한 '누군가 뜻이 있는 상위 의사결정권자분들 중 단 한 분이라도 제 의견에 설득된다면...' 하는 작은 바램에 추가적인 내용들을 소개하게 되었습니다.


< 그림. Entry-Engineer-Stepping Stone-Expert 단계로 발전하는 품질 관리 created by 천년나무 >



필자는 총 4가지의 영역으로 Software Testing으로부터 Software Quality Management까지를 분류하였습니다.


1. Entry Level

필자는 '입문 단계'라고 정의내렸으며 이는 소프트웨어 품질을 위한 입문 단계라고 볼 수 있습니다.


< 출처 링크 >


우리가 흔히 업무할 때 말하는 "테스트는 누구나 할 수 있는거 아니야?" 라는 것은 단순히 확인활동(Checking)으로써의 확인자(Checker)의 역할을 의미합니다. 테스팅활동(Testing)은 전혀 다른 활동입니다. 


이 확인자(Checker)와 테스터(Tester)의 차이에 대해서는 외국의 저명한 품질관리 전문가인 Michael Bolton과 James Bach가 "확인활동(Checking)과 테스팅활동(Testing)에 대한 구별"이라는 그들의 지식과 경험을 정리하여 발표하였으며, 필자 역시 해당 내용을 토대로 이 둘에 대한 차이를 구분할 수 있었습니다. Bolton은 확인활동(Checking)에 대해 입증(confirmation), 확인(verification), 검증(validation)이라 정의하였으며, 테스팅활동(Testing)에 대해서는 탐사 프로세스(process of exploration), 발견(discovery), 조사(investigation), 학습(learning)이라고 하였습니다.


위와 같은 역사적 사실에 관심이 많으시다면 대한민국 품질 연구소를 방문해 보세요.


* 참고 : 우리가 흔히 QA와 QC를 구분하면서 "QC=Testing이다" 라고 하지만 이는 Error이고 Fault입니다. QC=Checking활동이며, Testing을 통한 데이터를 수집해서 프로세스를 개선하는 것이 QA 활동, 품질관리(Quality management) 활동입니다.


2. Engineer Level

필자는 입문 단계의 다음 단계를 "엔지니어 단계"라고 정의하였으며, 이는 곧 엔지니어들은 어떤 회사에서든 그 조직의 기반이 될 수 있어야 함을 말합니다. 


< 출처 링크 >


필자가 생각하는 Engineer는 다음의 4가지 질문에 답할 수 있어야 합니다.


(1) 테스트를 결과를 도출하고 분석할 수 있는가? 

 - 진행되는 프로젝트에서 테스트 데이터를 도출하고 분석할 수 있는가?

 - 테스트 결과에 대한 보고만이 아니라, 의사결정권자의 빠르고 정확한 의사결정을 도울 수 있는가?

 - (추가로 : 자신이 도출한 결과가 객관적임을 입증할 수 있으며, 시장 대응에 도움이 되는가?)


(2) 분석한 결과를 명확히 증명하고 보증할 수 있는가? 

 - 자신의 테스트 기준에 대한 신뢰성을 어떻게 확보할 것인가?

 - ISO 9001 표준 등 품질관리 지식체계에 대한 이해가 있는가? 

 - (추가로 : 자신의 경험만으로 품질관리를 하려고 들지 않는가? 객관적인 증명이 가능한가?)


(3) 자신이 도출한 결과로 새로운 테스트 계획을 세울 수 있는가?

 - 테스트를 계획한다는 것이 무엇인 지 알고, 효율적인 계획을 수립할 수 있는가?

 - 경험을 기반으로 스스로 테스트 기준을 설정할 수 있는가?

 - (추가로 : 테스트를 진행한다는 것이 어떤 의미인지 명확히 알고 있는가? 기능만 보고 Pass/Fail하고 있지 않은가?)


(4) 자신이 개발하는 제품의 품질 특성을 명확히 이해하고 테스트를 기획할 수 있는가?

 - ISO 9126 표준, 혹은 자신의 도메인 표준 등에 대한 지식을 보유하고 현업에 활용할 수 있는가?

 - 자신이 종사하는 업종의 품질지표를 명확히 도출할 수 있는가?

 - (추가로 : 이를 문서화할 역량을 갖추었는가? 혼자만 알고 있다고 자부하고 있는 것은 아닌가?)


전체적으로 어렵지만, 쉽게 말해 "엔지니어면 적어도 자기가 한 일에 대해 (자신의 특출난 경험이 아닌) 객관적인 증거로 남을 설득시킬 능력이 있어야 한다." 입니다.


* 참고 : 흔히 "우리 회사는 다르다." 라는 논리나 "몇 년 하면 QA는 다 똑같다." 라는 논리로 Engineer가 되고 싶어하는 새내기들의 앞길을 막는 것을 많이 봅니다. 각 회사들에서는 지금 근무하는 직원의 이직을 걱정하기 보다는, 이직 오고 싶은 회사를 만드는 것이 나을 것이며, 그 중 하나는 품질 엔지니어를 기획-개발-검증 전체에서 육성하는 방법이라고 제안드립니다.


3. Stepping stone Level

Stepping stone은 영어로 '징검다리'라는 의미입니다. 


< 출처 - STEPPING STONE PEDIATRICS >


소프트웨어는 시작된지 60여년 밖에 되지 않았고, 그 중 서비스로서의 소프트웨어(Software as a service)는 등장한 지 10여년 밖에 되지 않았습니다. 컴파일러가 안정화되어 인간이 하는 실수를 먼저 알아차리고 선-대응 해준 지는 불과 몇 년 되지도 않았습니다. 쉽게 말하자면 소프트웨어 개발의 프로세스는 (애자일이건 뭐건 간에) 아직 안정화되지 않았고, 그렇기 때문에 그 안에서 일하는 사람들은 프로세스에 대한 이해가 높지 않다고 감히 말씀드릴 수 있습니다. (심지어 자신이 Quality Management를 한다는 Scrum Master들 조차 품질이 실무에서 어떻게 작동하는 지 이해를 못하는 경우가 대부분이었습니다.)


자, 이렇게 안정화되지 않은 프로세스 내에서 누군가는 제품의 마지막 프로세스에 서 있어야 하고, 여태까지는 그것이 Tester라 불리우는 (사실은 Checker인) QC 역할이었습니다. 그리고 얼마 전부터 웹-프론트엔드 등에는 QC 역할이 점점 줄어드는 추세입니다. 이렇게 급변하는 소프트웨어 개발의 유행 속에서 QA라는 직군은 업무를 정의 내리기 힘든 부서입니다. 대부분이 자신의 도메인과 사업에 대한 이해 없이, 단지 개발자원으로서 “공용 자원” 혹은 “지원부서” 역할로만 QA/QE를 사용하기 때문입니다. 


그렇지만 그렇다보니 QA/Tester로써 인생을 살다보면 여러 가지 다양한 일들을 경험하게 되므로, QA/QE는 업무 성격상 BA나 PjM, PdM, DEV 등 다른 포지션으로 비교적 쉽게 이동이 가능한 사람들입니다. 이 징검다리 단계에서는 각 업계의 도메인이나 시장 대응 방식에 따라 QA/QE가 여러가지 업무로 나뉘게 됩니다. 이를 토대로 주위에서 QA/QE라는 이름을 업으로 삼는 사람들이 실제로 하고 있는 일들을 살펴보았습니다. 그랬더니 소프트웨어 사업과 개발의 거의 전 영역에서 업무를 진행하고 있었습니다. 특히 대단위 사업에서는 대부분 QA라는 이름을 달고 Junior PM이나 PMO처럼 일하는 경우가 많았고, 국방 등 감사가 필수인 곳에서는 품질감사 역할, 모바일 게임 등에서는 단순 확인자(checker)의 역할 등 QA/QE라는 이름을 달고 맡은 역할들은 놀랄 정도로 다양했습니다. 최근의 특징점이라면 QE라는 이름으로 DevOps 역할이나 Test Automation쪽에 제대로 투자하는 조직이 늘어나고 있다는 점이겠네요.


* 참고 : 필자는 개인적으로 PM을 아래와 같이 나누어 기술합니다.

 (1) PjM : Project Manager

 (2) PdM : Product Manager 혹은 PdO : Product Owner

 (3) PgM : Program Manager (프로그램은 프로젝트의 회사 전략단위를 말하는 단어. PMBOK 참고.)


필자가 몇 년 간 컨설팅 및 관리자 역할로써 조직을 지켜보다보니 바로 이 징검다리 그룹의 확보가 조직의 품질 경쟁력을 향상시킬 수 있는 열쇠로 보였습니다. 이 세상 모두가 '혁신'을 원하지만 21세기의 시장은 너무나도 분화되어 있고, 또 빠르게 급변합니다. 그렇기 때문에 20세기처럼 업무별 편제로 시장을 대응하기에는 의사결정 구간이 너무 많기 때문에 느릴 수 밖에 없습니다. 그렇기에 ‘전체적인 사업의 품질 관리그룹/개발그룹’을 만드는 것이 급변하는 21세기에는 더 빠르게 시장에 대응할 수 있도록 해 주는 것을 목격했습니다. 필자가 징검다리 단계에서 제안하는 저 역할들 중 각자의 회사에서 필요한 역할이 무엇인 지 고민하고, 정의하고, 전략적으로 역량을 향상시킨다면 여러 회사들의 품질경영을 소프트웨어 관점에 맞게 개편할 수 있을 것입니다. 특히 스타트업 회사들은 덩치가 커지면서 발생하는 여러가지 이슈들을 최소화할 수 있습니다.


4. Expert Level

전문가 단계입니다. 


< 출처 - Forbes의 Steve Jobs >


미리 글의 서두에서 밝힌 바와 같이 Director급은 고려하지 않았고, 여기에서 말하는 Manager 역할이 팀장인지 실장인지 고려하지 않았습니다. 본 글은 조직도를 그린 것이 아니라 필자가 생각하는 품질 엔니지어로서의 역량별 단계를 나눈 것이기 때문입니다.


마지막 단계인 전문가 단계는 다른 단계들보다는 역할들이 이해하기 쉬운 편인데 그 중 두 개는 오해를 줄이기 위해 설명이 필요합니다. 


첫 번 째는 '관리자'와 '기술자'를 나누어야 한다고 생각한 점입니다. 한국은 경력이 많아지고 나이가 들면 '관리자'가 되어야 한다는 무언의 암시를 받게 됩니다. 저 역시 그런 암시를 받고 관리자가 되었지만, (분명히 말하건데) 제가 관리자를 선택한 것은 순전히 제 다음 세대는 저 같은 선택을 하지 않아도 되기를 바라며 택한 것입니다. (그리고 저는 지금 이 글을 쓰고 있습니다.) 


회사의 경영 입장에서도 (징검다리 단계에서 말했던 영역들 중 자신의 도메인, 자신의 회사에 어떤 것이 필요한 지를 명확히 파악하고 있다면) junior급 3~4명을 뽑아 관리하는 데에 투자 비용을 더 들이기 보다는 경험 많은 elder senior를 뽑는게 여러모로 유리합니다.


두 번 째는 PMO 조직 중 QMO와 TMO를 두기를 제안하는 점입니다. 한국의 PMO 제도는 PjM 경력을 위주로한 사람들이 프로젝트를 선-감사 하기 위한 제도라고 해석됩니다. 굉장히 잘 못 된 해석입니다. 적어도 필자가 몇 년간 공부한 해외의 PMO 자료는 그렇게 말하고 있지 않습니다. 미국에서 말하는 PMO 조직은 PMBOK에서 설명하는 PMO의 3가지 역할 중 하나인 형상기준을 제시하고, 전사 규약을 만들어 배포하는 조직 쪽에 가깝습니다. 즉, 프로젝트 관리 관점도 중요하지만 사실은 아키텍트, 기술전문가, 품질전문가가 함께 해야 작동하는 한 팀으로서의 PMO 조직이 되는 것입니다.


출처 링크 >


글을 마무리 해야 할 것 같네요.

다양한 관점의 많은 이견이 있을 수 있는 글임을 알지만, 많이 다듬지 않고 글을 올립니다. 왜냐하면 이 정도 고민도 할 여유가 없는 QA들이 많다는 점을 그 동안 만난 여러분들을 통해 알게 되었기 때문입니다. 많은 분들이 많은 의견 주셨으면 좋겠습니다.


한 해가 마무리 되네요. 아직 올리려고 준비 중인 자료가 너무 많습니다. 2015년에는 더 공부하고, 더 고민해서, 논의가 될 만한 글들을 많이 올려보겠습니다. 다들 연말 정리 잘 하시고, 2015년 희망찬 새 해 맞이하시길 바랍니다.




Posted by 『 Lv8+の 꽃怪獸 』 천년나무