반성이 없다... 그렇다면 개선도 없다.

지난 15년간 테스터 내지는 QA 엔지니어, PMO, PM 등의 역할을 수행하면서 참 많은 것을 느꼈다.
하지만, 사람은 망각의 동물이기에... 동일한 실수와 동일한 상황에서 똑같은 오류를 만들어낸다.

다양한 조직을 다녀보았다.
SI, 보안, 모바일, 게임, 패키지, 시스템, 솔루션 개발사들...
도메인도 마찬가지다. 광고, 영상, 임베디드, 웹 프로젝트들도 그랬고... 

다양한 조직형태도 있었다. 기획팀 밑에, QA 분사조직, 대표 직속, 연구소 소속, 개발팀 소속, 외주, 파견 등등.
그 조직 중에 QA에 대한 인식이 높은 곳은 한두곳 뿐이다. 

그러면서 나에게는 노하우가 쌓였다. 나름 어디가서 한마디도 지지 않을 자신감 같은 것도 생겼지만...
구한말, 갑오경장, 갑오개혁을 겪어보지 못한 사람들에게 품질이란 단어는 아직도 흥선대원군에게 신문물을 받아드리자는 의견하고 뫼한가지다.

(흥선대원군 : 위키 백과)

그래도 QA 및 테스트 조직에 대한 업계 인식은 조금은 바뀐것 같다.
예전에는 고등학교 졸업반 친구들을 QA로 양성하라는 지시나 CS하던 친구들을 QA로 트레이닝 시키라는 다소 어이없는 지시를 받은 적이 많다. 내가 지금하고자 하는 이야기는 그들을 비하하고자 함이 아니라 정식 TO 발령이 아닌 단순히 머릿수 채워가는 식의 조직 운영이였다고 생각한다.

그러니 테스트라는 업무에 대한 진입장벽은 자연스럽게 낮어졌고, 그 빈 공간은 아웃소싱에서 항상 치고 들어갈 수 있었다. 무슨 프로젝트가 전문가 양성과정인가 싶기도 했다.

하지만 관리자나 프로젝트의 이해관계자들의 눈높이도 높아졌고 최근 QA 구인 광고를 살펴보면... 이건 뭐하는 사람을 뽑는지 알 수 없는 광고들이 많이 나온다. PM도 가능해야 하고, DB도 만져야 하고, 인증도 받아야 하고, 운영도 해야하는 다용도 역할로 변화된것 같다. 이 대목에서 사람들은 Devops와 agile이라는 양날의 검을 만지작거리며 내세운다. 결국 자기손이 베어 후회할지도 모르면서...

조직을 변경하다보면... 여러가지 타입의 관리자가 존재한다.

1. QA나 테스트 역할에 대해서 아주 잘알고 있는데... 지금 니가하려는 일은 그렇게 하는게 아니야.
2. QA에 대해서 잘은 모르지만, 다년간의 짬빱으로 니가하는일 대부분은 내가 알고 있다. 그러니 나한테 자세히 설명해봐. 1~100까지
3. QA에 대해서 잘 모르는데, IT 트렌드가 이러하니 이런 기술 도입해보는 것이 어떨까?
4. QA는 관심이 없는데 고객한테 크레임만 안걸리게 해줘. 가능할까?

(관리자 : 출처 http://www.centroacp.it/)

이래저래 고민하다보면... 4번쪽으로 치우칠 수록 성과가 더 극대화될 수 있겠으나... 그 조직에서는 QA역할이 곧 실망이 될 수 있다.
왜냐하면 단기의 성과가 업무에 큰 성과로 바로 드러날 수 있기 때문이다. 하지만 다음 성과가 다시 만족할 것이라는 보장은 없다.

혹은 어떤 조직에서는 CTO내지는 QA를 배치한 뒤에 엄청난 성과가 나오길 바라는 것은 어불성설이다.
개인의 역량은 단기에 가시적 목표로 표시될 수 있겠지만, 조직의 역량은 단기에 달성되는 것이 아니다. 프로세스를 다 잡고 프로덕트를 다잡는 과정에 개별의 역량이 향상됨을 체크하고 지속개선해야 한다.

하지만, 한국의 IT문화는 ROI를 상당히 중시한다. 그런 문화 끝에 일년? 이년이지나 한달 두달 내에.. 성과를 보고하길 바란다.
드라이브 권한도 제대로 없는 QA조직이 어떤 CEO, CTO, 개발총괄, 개발자, 빌더, 디자이너에게 어필이 될까?

늘 그렇듯 어떤 조직이든 이직하면 운영중인 시스템과 신규 시스템에 대한 QA를 부탁했다.
그런 프로젝트를 처음부터 까보다보면 묵은 버그, 결함, 취약점, 이슈, 에러 들이 수두룩 하게 나온다. 관련 데이터는 BTS(방탄소년단 아님, Bug tracking System)에 기재해놓고 리뷰 끝에 이런 코멘트가 추가된다. 이번 차수에서 못하겠으니 다음에 하겠다. 이번 배포 버전이 아니니 다음에 하겠다. 하면서 일을 뭉겐다... 그렇게 또 사장될 쯤... 다시 QA가 다시 이슈화 하면... 암 유발하는 소리들의 일색이다.

(BTS 중 JIRA Workflow custom ver. : 출처 http://www.adempiere.com/)

이런 조직에서 관리자들과 인터뷰를 해보면... 이런 이야기가 나온다.
왜 그런지 모르겠다. 나는 충분한 교육, 인력, 시간을 줬는데 합당한 아웃풋이 나오지 않는다. 정말 이유는 모르겠다.
(반대로 아무런 인풋도 없는 조직에서도 동일한 이야기 일색이다.)

우리나라 IT에서는 회고가 없다. 프랙티스 자체를 관리하지 않는다. 반성이 없으면 개선도 없다.
반성 없이 연장선에 프로젝트에 또 투입된다. 같은 실수가 반복된다. 달라지지 않는다. 그러고 ROI가 어쩌고 하면서 감원, 충원 거부로 이어진다. 그럼 굴레가 시작된다. 다시 같은 문제에 봉착했을 때 한큐에 해결할 사람을 찾거나 시스템을 찾는다.

체계적이지 못한 것에 대한 이유는 바로 관리자로 부터 출발한다.
그러나 그 문제를 특정인원에 어싸인하는 것은 참으로 잘못된 형상이다.
반성도 없다. 그럼 개선도 없다. 그나마 바뀐 인식이 15년이 지난 지금에서야 약간이라면...
다음 15년 후에 난 아무런 자기계발 없이 똑같이 다른 조직에서 같은 일을 하고 먹고 살수 있을것이다.
(뭐 그렇게 하겠다는 소린 아니고!!!)

Written By 밤의카사노바