Archive for April, 2008


여유와 품질

Thursday, April 10th, 2008

‘품질이 우수하다’라는 말을 할 때, ‘품질’이란 무엇일까요?

품질공학, 품질관리, 품질경영… 품질은 X변수처럼 다양한 것과 결합될 수 있습니다. 그렇기 때문에, 문맥을 말하지 않고서, 품질을 정확하게 정의내릴 수 없습니다.

제가 쓰는 이야기는 대개 소프트웨어 개발 프로젝트입니다. 특히 SI성격의 프로젝트와 관련되어 있죠. 이런 문맥에서 바라보자면, 품질이 우수한 프로젝트란 무엇일까요?

수 많은 고수 프로젝트 관리자가 있기에, 어설프게 품질이라는 이런 것들이다라고 정의내리기 두렵지만. 용기 내어 정의하자면, 요즘 느끼는 품질의 개념은 이렇습니다.

고객들이 제가 맡은 프로젝트에서 만든 프로그램을 쓰면서

야! 그래도 이 시스템을 쓰니까 예전보다 많이 편해졌네.

라고 말한다면, 품질이 우수한 프로젝트라고 자평합니다. 물론 저희가 만들어 놓은 시스템을 쓰는 사용자들이, 만나는 사람마다 저희 프로그램을 칭찬해 준다면 무척 좋겠지만. 이 세계에서 욕 안 먹는 시스템을 만드는 것만으로 성공이라고 하니. 고객들이 “참 편리한 시스템이에요!” 정도로 칭찬해 준다면 엄청난 성공이죠.

고객들이 던지는 이런 말은, 제3자가 듣기에 대수롭지 않은 말이지만. 이런 말이 고객 입에서 자발적으로 나오게 한다는 게 쉽지 않습니다.

***

팀장은 핵심 경로(Critical path) 위에 놓인 업무를 맡아선 안 됩니다. 팀장이라는 역할이 전체적인 관점에서 업무를 조율하는 것인데, 팀장이 핵심 경로 위에 업무를 맡아버리면, 업무 조율보다는 업무 수행에 몰입해 프로젝트를 버뮤다 삼각지대로 끌고갈 확률이 매우 높기 때문입니다.

하지만, 팀장이 핵심 경로 위에 없을 때, 핵심 경로 위에 놓인 팀원들의 업무 부하를 덜어주는 것은 팀장으로서 마땅히 해야 할 일이죠. 이런 관점에서, 며칠 전에 인스톨쉴드로 배포 프로그램 작성하는 것을 맡았습니다. 팀장 역할에 부합하는 프로그래밍이었죠.

제가 사용자로서 생각하는 훌륭한 설치 프로그램은 이렇습니다. 사용자에게 이것 저것 선택하라고 말하기보다, 사용자 의도를 파악해 알아서 프로그램을 설치하고. 삭제할 때는 CSI가 와서 검식해도 프로그램이 설치되었다는 사실조차 알지 못하도록 정보를 모두 삭제하는 그런 설치 프로그램입니다.

이상과 현실, 아는 것과 실천하는 것을 일치시키려고. 인스톨쉴드로 설치 프로그램을 짜면서 고민을 많이 했습니다. 사용자를 귀찮게 하지 않으려고, 사용자가 프로그램을 설치하는 가지 수를 고민하기 시작했습니다. 이런 저런 고민을 하다 문득 이런 생각이 들었습니다.

다른 사람이 제가 이렇게 하잖은 것까지 고민하는 모습을 본다면, 제가 상당히 여유롭게 보이겠다는 생각 말이죠. 여유롭게 보이기는 하지만, 호수에 떠 있는 백조처럼… 저는 설치 프로그램 품질을 높이기 위해 잔머리를 무척이나 굴렸습니다.

남이 보기에 사치라고 보일 정도로, 여유로운 사색을 해서, 제 생각하는 이상향에 가까운 설치 프로그램을 만들었습니다. 물론 아직 고객에게 인도되지 않았기에. 고객의 평가는 듣지 못했지만, 제가 사용자라면 “우와~ 진짜 설치하기 쉬운데요!”라고 평가할 것 같습니다. :)

자화자찬 포스트가 되어 버렸지만. 제가 생각하는 품질은 그렇습니다. 여유가 없는 프로젝트에서 품질을 기대하기란, 칼로리 계산하지 않고 대충먹고 운동이라곤 진보신당 지지율만큼 하는 사람이 완소남 완소녀가 되길 바라는 것과 비슷합니다.

물론 여유가 넘친다고, 팀장이나 팀원 프로젝트 첫 날부터 품질을 어떻게 달성할지 고민하지 않는다면, 품질 좋은 소프트웨어 못 얻겠지만요. 세상만사가 비슷합니다. 얻는 게 있으면 잃는 것도 있듯이. 고민하는만큼 반드시 얻는 게 있죠.

Be Agile! :)

QA에 면역된 팀장

Friday, April 4th, 2008

내일은 새롭게 시작된 프로젝트가 QA를 처음으로 받는 날입니다. 제가 몸 담은 부서에서는, 운 좋게도 같은 부서분이 QA를 해주십니다. 날이 선 QA부서분들에게 받는 것보다 조금 유연하죠. 팀장으로서 부담을 덜 느낍니다.

엊그제가요. 저희 부서의 QA를 총괄하시는 부장님이, 제가 맡은 프로젝트의 QA를 맡아주실 과장님께 이런 말씀을 하셨답니다.

Hani PM은 QA를 많이 받아 봤기 때문에, 어떻게 QA를 하는지 잘 알죠. 그러니까, 신경써서 QA를 해야 될거에요.

부장님의 말씀은 칭찬이기도 하지만. 어떻게 보면 산전수전 겪어봤기 때문에 QA를 요리저리 피해갈 수 있으니, 조심하라는 경고성 멘트로 받아들일 수 있습니다. :)  저도 이런 사실을 부정할 생각은 없습니다. 왜냐면, 어떻게 QA를 받으면 점수를 높게 받을지 알기 때문이죠. 그리고 QA 체크리스트도 어느 정도 외우고(?) 있기도 합니다.

***

살충제 패러독스(Pesticide paradox)라는 게 있습니다. 즉, 동일한 테스트케이스를 이용해 테스트를 반복적으로 수행하면, 새로운 버그를 잡아내지 못한다는 것입니다. 개발자들이 테스트케이스에 익숙해져서, 테스트케이스를 만족시키는 형태로 프로그램을 짜기 때문이죠. 물론 개발자들이 테스트케이스에 익숙해지면, 그 테스트케이스로 잡아내는 문제점은 줄어들지만…… 버그를 잡아내지 못하는 테스트케이스는 더 이상 ‘테스트케이스’로서 가치가 없습니다.

그렇기 때문에, 끊임없이 새로운 버그를 잡아내도록 테스트케이스를 바꿔야 합니다. 창과 방패의 영원한 대결이 조용한 프로그램 개발세계에도 존재합니다.

***

오늘 퇴근하면서 들은 이야기인데, QA를 해 주실 과장님께서 무척이나 세심하게 준비하고 계신다고 합니다. 하~ 살충제(?)에 면역이 되어 왠만한 것으로 간에 기별도 안 간다고 생각했는데. 소문을 들으니 만만치 않은 QA가 될 것 같습니다. 긍정적으로 보자면, 잘 된 일입니다. QA가 점수 잘 받자고 하는 행위는 아닙니다. 물론 점수가 나쁘면, 여러 가지 문제가 생기지만. QA 본연의 목적을 생각한다면, 더 큰 문제가 될 잠재적인 요소를 찾아 제거하는 것이니까요.

물론 QA에 문제 없다고, 프로젝트 품질이나 프로그램이 우수하다는 뜻은 아니죠. 보통은 먹고 간다는 의미 정도일까요? 아무튼 점점 QA에 내성이 생겼는데, 초심으로 돌아가는 하루가 될 듯합니다.

Be Agile! :)