Computer/project

투비소프트 “QA역할? 개발프로세스 비추는 거울“

박현철 2012. 3. 12. 14:26


소프트웨어(SW) 분야의 '변방'이었던 품질보증(QA)이 산업 생태계 발전과 맞물려 주목된다. 개발사가 기획, 구현, 테스트, 관리에 필요한 프로세스 중심적 사고를 실체화하는 노력이 중시되면서다. QA활동은 품질에 기반한 SW 경쟁력 강화를 추구함으로써 국내 시장 가치뿐 아니라 해외 진출 성공 가능성도 북돋워줄 키워드로 떠올랐다.

 

이전까지 SW개발 조직들에게 실제 제품을 수년 이상 개선, 확장시켜나가는 경험적 방법론이 설파된 사례는 찾기 어려웠다는 비판이 있다. 세미나 등을 통해 주어진 개발 방법론은 프로젝트 성공, 완수에만 초점을 맞춘 경향이 짙었던 것이다. 그 대상이 패키지SW든 시스템 통합(SI) 작업이든 일회성 개발이든 마찬가지였다.

 

우리나라에 과연 품질 기반 경쟁력을 갖추고 해외 시장에 국산SW 제품을 내다 팔기 위한 고민이 존재하는 것인지에 대한 회의론도 제기된 가운데 기업용 리치 애플리케이션 플랫폼을 공급해온 투비소프트는 첫 제품을 출시한 지난 2003년부터 품질관리 전담부서인 QA그룹을 운영해왔다. 이달 중순께 만난 홍성호 QA그룹장과 그 소속 팀원들을 만나 SW개발 조직에서 QA활동의 역할과 한계를 물었다. 이들의 QA활동 이력과 철학, 그에 녹아든 현재까지의 경험과 현장 QA 업무의 개념과 성격이 그려졌다.

 

■"테스팅(QC)-QA, 헷갈린다면…"

 

홍 그룹장은 우선 QA와 비슷하거나 같다고 오해되는 품질제어(QC) 업무는 분명 다르다고 설명했다. 그에 따르면 QC는 만들어놓은 SW를 점검하는 것이고, QA는 SW를 만들기 전에 '점검의 여지' 자체를 줄이는 활동으로 요약된다.

 

 
▲ 투비소프트 QA그룹 홍성호 그룹장
 

"QA와 QC를 정확히 구분하긴 어렵지만 많이 달라요. QC는 간단히 말해 이미 나온 제품을 사후 테스트하는 과정이죠. '버그(결함)'를 찾고 제거할 수 있도록 그 원인을 추적합니다. QC 업무는 버그가 많을수록 늘죠. 제품이 나오기 전에 할 일은 없지만요. SW만드는 처음 단계인 요구사항 정의부터 마지막인 테스트까지 전 개발 과정 관여하는 것을 QA라 볼 수 있습니다. 항상 '프로세스' 개념이 따라다녀요."

 

그에 따르면 QA 업무는 개발 조직이 좋은 프로세스를 찾아 정립하도록 돕는 활동이다. 다만 홍 그룹장은 자신을 비롯한 QA담당자 대부분이 직접 '프로세스'를 만들려다 실패를 겪곤 한다고 밝혔다. 사장 직속이 아니라 구속력이 떨어진다는 이유도 있지만, QA업무 성격이 조직에 미칠 수 있는 영향력이 크다 해서 외부의 좋은 프로세스를 강제로 가져올 수 있는 것도 아니기 때문이란다.

 

"진짜 좋은 프로세스는 이미 경험해 본 것들이죠. 남이 찾아낸 패턴이 아니라…어느 회사든 같은 실수를 반복하는데, 그 패턴에 답이 있어요. 딴 게 아니라 실수로 배우는 게 프로세스고, 품질을 높이는 길이죠. 남이 실수를 거듭하면서 바꿔온 결과를 어느날 갑자기 흉내내 봤자 제대로 활용될 리 없죠. 스스로 조금씩 보완, 수정하는 과정이 필요한 건데요. QA부서가 강제할 수 없지만 바뀌도록 기회를 포착하는 거죠."

 

QA부서가 실제 SW개발 담당 부서와 협업은 중요하지만 이미 정립된 외부 절차를 '이식'하는 건 어렵단 얘기다. 홍 그룹장은 모범적인 프로세스를 제시하는 QA활동을 '거울'에 빗댄다.

 

"이미 정립된 프로세스와 품질에 대한 기준이 필요하고, 개발 조직이 원할 때 제시할 수 있는 방법론도 확보하고 있어야 됩니다. 기준이 될 프로세스와 품질은 일종의 '거울'이고, 방법론은 일종의 결점을 제거할 수 있는 '화장지'같은 거예요. SW조직들이 기준을 요구할 때 우리는 거울을 내밀고, 방법론이 필요하다 싶으면 화장지를 갖다 주는 거죠."

 

■투비소프트도 한때 'QA 오남용'

 

그렇다면 QA 조직이 모범적인 기준이 될만한 방법론과 프로세스만 갖춰 주면, SW개발 품질이 '수직상승' 할 것인가? 조직이 QA의 역할을 왜곡시키려는 경향도 있기 때문에, 그리 간단치 않은 문제다.

 

"QA라는 존재를 일종의 보험으로 생각하거나 뒷감당에 이용하려는 경우도 있어요. 개발 프로젝트를 당장 급하게 진행해야 된다는 현실 논리를 들어, 나중에 문제가 될 것을 알면서 상황을 모면하려는 거죠. 정작 문제가 불거지면 현실 논리를 강변했던 실무자는 수습해 달라면서 바로 그 눈감아달라던 문제를 들고 나타나는데, 이런 뒷감당이 QA 본연의 역할은 아니죠."

 

사실 QA를 도입함으로써 당최 존재하지도 않았던 '수준'이란 것이 어떤지 알 수 있게 된다는 이점도 존재한다고 홍 그룹장은 지적했다. QA를 통해 SW품질을 높인다는 말을 쉽게 하고 있지만, 여기엔 SW품질을 측정할 수 있는 프로세스를 도입한다는 전제를 깔고 있다는 얘기다.

 

"뭔가 현업에 일어난 변화의 전후 상태를 측정할 수 있다는 건 이미 그 프로세스 수준이 높다는 겁니다. 낙후된 환경일 경우 SW품질을 높이겠다면서 QA를 막 도입한다고 해도 보통은 그 도입 이전에 비교할 측정값이란 게 없죠. QA를 도입한 그 시점에 이미 객관적인 상태를 진단해낼 수 있다는 '수준'에 와 있음을 암시합니다. 품질이 높아지는 건 QA가 정착된 이후에나 볼 수 있는 거죠."

 

홍 그룹장은 SW개발 조직 입장에서 QA를 도입할 경우 품질개선을 목표로 설정할 수 있게 됐다는 장점뿐 아니라 각 개발자들에게도 긍정적인 자극을 줄 수 있게 된다고 설명했다.

 

"개발자들 정말 열심히 일해요. 그런데 결과물이 어떤 경지에 올랐다는 것을 모르면 자부심을 못 느끼죠. 그럼 주로 제품을 써 본 사용자 피드백에 의존해 판단하게 돼요. 개발자 스스로가 제품에 대해 어떤 수준에 도달했다는 느낌을 받지 못하면 결국 지칩니다. 투비소프트가 제품을 하나 만들면 생명주기가 최소 6~7년 가는데 패치와 유지보수가 끝도 없이 계속될 것 같은 기분이 들죠. QA는 이런 환경에서 개발자들에게 객관적 정보를 통해 자신감을 불어넣기도 하죠."

 

■자긍심은 SW품질에 비례?

 

QA그룹 품질관리팀의 다른 구성원들 생각도 들어봤다. QA는 물론이고 그 한 부분인 QC 업무 역시 중요성과 역할이 높게 정립되고 있음을 피부에 와닿는다고 전했다.

 

 
▲ (왼쪽부터) QA그룹 품질관리팀 유동규 사원, 조한형 팀장, 정해영 과장, 홍성호 그룹장
 

QA그룹 품질관리팀 사원 유동규 씨는 "과거 QC 담당자의 업무를 얕잡아 보는 인식이 있어왔는데 이제 테스트와 인증 작업 전반에 대한 인식이 구현을 맡는 개발자들 업무 못지 않게 중요한 것으로 바뀌었다"고 말했다.

 

이어 "신규제품에 대한 요구사항을 담은 문서를 보고 테스트케이스를 설계하고 자동화되는 부분과 나머지를 나눠 테스트를 거치는 업무를 하고 있다"며 "얼마 전부터 품질에 민감한 일본 고객사들이 회사에 찾아와 우리 팀 프로세스를 보고 배워 갈 정도로 주목받고 있다"고 언급했다.

 

지난해 4월 입사한 그는 이전에 HP 등에서 자동화프로세스 구축 업무를 담당하는 개발자였다. 삼성 등에 들어가서 현장 사용자가 다룰 시스템을 구현해 본 경험이 있지만 품질 관련 업무와 맞비교할만한 사례는 아니라고 한다.

 

같은 팀 정해영 과장도 "일본 시장에 SW를 수출하는 국내 기업이 드문데 익히 알려진 배경은 요구사항 대응하기가 엄청나게 까다롭고 상세한 피드백이 오간다는 고객 특성 때문"이라며 "그런 일본에서 품질담당부서에 견학을 오고 자신들이 수행을 마친 프로젝트에 대해 '안심'하고 가는 뜻으로 비친다"고 평했다.

 

또 "지난 2007년 1차 인증을 받았던 '역량 성숙도 모델 통합(CMMI) 레벨3'를 지난해 재인증 받았다"면서 "내부에서 자체 검증을 통해 제품이 안정화되는 부분 말고도 이처럼 외부의 직접적인 반응을 통해 QA 업무 담당자의 자긍심 같은 것을 느낀다"고 밝혔다.

 

지난해 7월 입사한 정 과장은 과거 전산실에서 ERP 등을 구축하는 외주 프로젝트가 끝날 때 최종적인 요구사항을 점검하는 인수테스트를 맡아 봤다. 다만 투비소프트 제품은 요구사항이 아니라 기획한 내용을 기반으로 점검하기 때문에 분명한 요구사항이 없는 고객을 만족시켜야 한다는 입장에선 더 어려운 일을 하는 셈이다.

 

조한형 품질관리팀장은 "품질은 원래 SW공학의 한 장을 차지했는데 품질이 강조되면서 단일 전공과목으로 분리되는 추세"라며 "SW 테스팅이라는 영역도 국내외 자격증 알려지고 보유자가 늘면서 저변 확대가 진행중이다"고 말했다. 조 팀장은 투비소프트 창립 시기부터 함께 일해왔고 정식 입사만 지난 2006년 11월께 했다.

 

그는 "QC조직이 이전엔 연구소 결과물을 흠잡아 따지는 업무부서로 인식돼 '연구소의 적'이라는 별명이 있었다"면서도 "이제 연구소가 수동적으로 테스트 단계 넘어가길 기다리기보다는 복잡한 케이스를 일부러 요청하기도 하는 등 상호 보완적인 관계로 발전해나가는 추세다"고 덧붙였다.

 

■"SW개발, 코딩이 전부가 아니다"

 

그렇다면 QA가 왜 저평가돼왔을까. 기성세대 개발자들이 만든 '나쁜 습관' 때문이라는 게 홍 그룹장의 설명이다. 구현 담당 개발자가 코딩 외에는 자기 일이 아니라 보고, 구현에 몰입하는 것이 SW품질을 높일 수 있는 유일한 방법이라 여기는 게 문제란 지적이다.

 

"우리처럼 과거 SW전문인력 세대가 나쁜 개발습관을 물려줬기 때문인 것 같아요. 자판 앞에 앉아 번개처럼 손가락을 움직이고 화면 스크롤시키는 게 'SW개발하는 모습'이라고 인식하게 된 겁니다. SW 완성도를 높이기 위해 평가회의, 방법론 연구, 결과검토, 이런 일 하자고 요청하면 막상 구현하는 개발자 입장에서는 '바빠죽겠는데, 당장 코딩해야되는데' 이런 생각이 드니까요."

 

투비소프트도 과거에는 그와 다르지 않은 분위기였다고 홍 그룹장은 고백했다.

 

"개발자들에게 구현하기 전 단계에 대한 평가가 없었어요. 재작업을 수도 없이 반복하고, 날밤을 새고, 부사수한테 그런 버릇을 물려 주기도 하죠. 지금도 대부분 회사가 비슷할 겁니다. 저희는 그 상태를 고치지 않으면 안 되는 상황이었어요. 사람을 뽑아도 매번 가르칠 여력이 부족하고, 계속 재직한다는 보장도 없는데 복잡한 제품을 안정되게 계속 만들려면 '거울'을 보여줘야 했죠."

 

얼추 돌아가는 결과물을 내놓는 순간 SW개발이 끝났다고 생각하는 조직이라면 '코딩(구현)'을 가장 중시할 수 밖에 없을 것으로 보인다. 다만 최근 흐름상 SW개발을 기획, 구현, 테스트, 출시까지 이르는 일련의 과정에 더해 사후조치로써 확장과 발전 단계까지 포함하는 인식과 거리가 있다는 게 문제다.

 

투비소프트는 QA조직을 별도 운영하면서 제품개발 프로세스와 융합시키는 회사 입장에선 오히려 이 '잘못된 인식' 때문에 개발하는 제품 규모와 협력해야 할 사람들이 늘어날수록 물리적 시간과 인력만으로 감당할 수 없는 문제가 발생한다고 봤다.

 

홍 그룹장은 "투비소프트는 1천200여개 고객사들이 제품을 사용하는 환경마다 일일이 대응이 필요해서 출시, 유지보수 프로세스 모든 과정을 QA와 맞물리게 해 전산화시켰다"며 "일단 제품이 나오는 것도 한 성공일 수 있겠지만 우리 회사는 그 때부터 '이제 시작이구나'하고 마음의 준비를 한다"고 말했다.

 

이어 "우리 제품이 상대적으로 더 어려운 것이라 전문 테스터들 뽑았다가 다 나가버리고 4번 물갈이된 QA 조직에 전문개발자 출신들만 남았다"며 "그간 내가 쌓은 경험이 회사 입장에서 다 실패에 따른 '비용'으로 감수됐을 텐데 이를 참고 계속 맡겨준 것은 경영진들에게도 고맙게 생각한다"고 덧붙였다.

출처 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20111130181703&type=det