SW 품질 개선, 그 시작점이란...

개발자로서 SW 문제를 대하는 바람직한 자세는 무엇인가?

아니, 구체적으로... SW 문제를 미연에 방지하기 위한, 그 궁극적 목표를 달성할 수 있는 해결책이란 과연 존재하는가 ?

10여년 대규모 제조업 회사의 SW 개발팀에 근무하면서 내 마음을 가장 무겁고 막연한 안개와 같이 뒤흔드는 주제는 '품질'이었다(관리자들의 가장 중요한 관심사이기도 하고 그들의 성에 차지 않을 때 실무자들을 진흙탕 속으로 몰아 넣기 가장 좋은 '구실'이 되기도 하는).

SW 품질 문제는 그 핵심을 찾기도 어려울 뿐더러 문제의 원인을 찾아냈다고 해도 올바른 개선 방향을 정하기 까지...(그것을 팀원들이 실천하고 업무에 정착시키기 까지)는 예측하기 힘든 정도의 비용, 시간과 돈과 노력, 이 투자되어야 한다. 

나는 SW 품질 문제를 분석하고 해석하는 큰 두 가지 관점이 있다고 생각한다. 

첫번째는 미시적인 관점으로 개발자 한 사람 한 사람의 역량과 자질의 문제로 접근하는 방식이다. 

두번째로 거시적인 관점인데 결국 SW 품질 문제는 경영자를 비롯한 주요 의사 결정권을 가지고 있는 사람들의 인식과 개발 프로세스의 문제로 바라보는 관점이다. 

10년간 개발부서에서 근무한 나름대로의 소회는 SW 품질은 미시적 요소보다는 거시적 요소에 더 많은 영향을 받는다는 것이다(최소한 벤처 회사와 같이 소규모가 아닌 대규모 개발조직에서는 대부분 그렇다). 다분히 개인적인 근거일 수 있지만, 개발자 한 사람이 개발조직에 끼치는 영향보다 조직의 문화와 분위기에 따라 개발자의 업무 방식이 영향을 받는 것을 수 없이 보아왔기 때문이다. 

예를 들어 SW 테스트 기간중 SW 문제점이 발견되었을 때 각 부서간 담당자의 반응은 보통 아래와 같은 형태였다. (이 예는 "HARD CODE 1장-프로젝트 부실관리"에서 발췌) 

• 버그를 발견한 테스터에게 버그는 자신의 시간과 노력을 평가하는 잣대다. "고칠 가치가 없다니 도대체 무슨 말입니까?"
• 기능을 구현한 프로그램 관리자에게 버그는 자신의 설계에 도전하는 반란이다. "버그를 고치려면 기능 자체를 뒤엎어야 합니다!"
• 서비스 운영팀에게 버그는 지속적인 골칫거리를 뜻한다. "별 거 아니라고요? 새벽 세 시에 나와서 서버를 재부팅할 사람이 누구인 줄 아십니까 ?"
• 개발자는 버그를 자기 나름대로 주관적으로 평가한다. "뭐, 그리 심각한 버그는 아니군요."

나 자신도 개발자로 오랫동안 일해 왔기 때문에 위의 예문이 때로는 내 모습의 일부였음을 고백하지 않을 수 없다. 이렇듯 복잡한 제품을 만들고 조직의 규모가 큰 회사일 수록 특히 실무자 '한 사람'의 노력으로 최선의 해결책을 찾고 사람들의 동의를 얻어내기란 정말 어려운 일이다(만약 그런 사람이 주위에 있다면 당장이라도 그에 맞는 권한과 직책을 부여해야한다). 경험상 프로젝트 일정이 점차 막바지에 이르고 그 진행 결과가 긍정적인 신호보다는 부정적인 신호들(빈번한 요구사항 및 설계 변경, 실무자들의 탈진과 피로감, 의사 결정권자들에 의한 잦은 의사 번복, SW 버그..)에 둘러싸였을 때 위와 같은 반응은 점차 자연스러운 것이 되곤 했다.

책의 저자는 "선별(triage) 회의"(쉽게 말하면 문제점 분석 회의 정도가 될 것 같다) 사례에서 지켜야할 다섯 가지 규칙을 소개한다. 책을 읽으면서 이것은 단순한 규칙이라기 보다는 SW 제품을 생산하는 조직, 특히 '개발 조직'에서 풀어야 할 "수 많은 문제들"을 어떻게 다루어야 하는가? 라는 질문에 "선별 회의"라는 국한된 주제를 통해 가능한 해결책을 암시해 주는 것 같다. (규칙은 결국 문제가 많고 혼란스러운 상황 속에서 그 빛을 발하는 것이 아니던가?)

1. 문을 닫아라. - 협상은 비공개로 진행해야 참가자들이 솔직하게 흥정하고 타협할 수 있다는 의미
2. 모든 결정은 팀 의사다. - 모두가 합의한 사안에 대해 조건 없이 결정을 지지해야 한다는 의미. 의사 결정에 참여한 구성원은 모든 결정을 자신이 내린 결정인 양 방어할 수 있어야 한다. 
3. 참여 인원을 제한한다. - 머릿수가 많으면 회의가 늘어지고 사적인 감정이 얽히게 되어 결론이 쉽게 도출되지 않는다. 단호하고도 다양한 시각을 얻기 위해서는 부서당 한 명씩이 가장 적당함.
4. 한 사람이 최종 결정을 내린다. - 팀이 사안에 합의하지 못할 경우 누군가는 최종 결정을 내려야 한다(이상적으로는 이런 상황이 생기지 않는 것이 좋다). 책에서는 PM(프로젝트 매니저)이 가장 적합하다고 설명함.
5. 모든 결정은 '퀘이커(Quaker)'식 합의를 따른다. - 가장 중요한 규칙으로 합의가 어렵고 사적인 감정이 개입된 모임에서 만장일치를 기대하기는 어려우므로, '퀘이커'식 합의(반대자가 없다는 뜻)를 통해 누구도 반재하지 않는 결론을 찾아야 한다는 의미. 만장일치보다 훨씬 달성하기 쉬우며 훨씬 합리적인 결론이 나올때가 많다고 한다.

회사와 같이 비즈니스를 기반으로 한 조직에서 조직의 시작과 더불어 문화라는 것은 존재하지도 할 수도 없다. 그것은 결국 사람과 시스템, 시간과 프로세스의 '산물'일 수 밖에 없다. 조직에 영향력을 행사하는 사람들의 철학과 더불어 그들이 만들어 놓은 프로세스에 의해 조직이 운영되고 그 산출물로 문화가 생성된다. 그리고 그 문화는 그 조직에 속한 많은 사람들의 행동과 생각에 영향을 주는 요소가 된다. 

  

결론이다. 우리 모두는 건강한 개발 문화를 꿈꾸고 소망한다. 나의 꿈이기도 하다. 건강한 개발 문화란 무엇인가? 어쩌면 위의 "선별 회의" 사례에서 볼 수 있듯이, 우리가 '이상'이라 믿고 생각할 수 있는 합리적인 회의 문화를 정의하고 그것을 실천하는 배경에는 그 회사(조직)이 얼마나 '고객'과 '비즈니스'에 집중하고 있는가에 달려있는 것은 아닐까? 최고의 제품, 품질이라는 것은 결국 '고객'과 '비즈니스'를 바탕에 두지 않고서는 도무지 그 실마리를 찾을 수 없는 미로와 같은 주제이기 때문이다. 

이 즈음에서 질문을 던져보자. 우리가 이 일을 하는 이유는 무엇인가? 

고객을 위한 것인가? 아니면 정체도 알 수 없는 그 누군가의 목표와 욕망을 채우기 위해서인가?