[10장 보충] 프로세스를 거부해야 할 때

톰 드마르코가 지은 데드라인이라는 프로젝트 관리에 대한 소설을 읽다보면 CMM과 같은 프로세스 개선 공정에 대해 강하게 비판하는 구절이 여러 번 나옵니다. 누구보다도 소프트웨어 공학 부문에서 잔뼈가 굵었을텐데 자칫 잘못하면 스스로 무덤을 팔지도 모르는 이런 내용을 드 마르코가 강조한 이유는 무엇일까요? 오늘은 여기에 대해 개인적인 생각을 적어보도록 하겠습니다.

혹시 HACCP이라는 단어를 보신 적이 있습니까? '식품위해요소 중점관리기준'이라고도 불리는 이 단어는 식품의 원재료 생산에서 제조, 가공, 유통 단계를 거쳐 우리 식탁에 오르기 전까지 각 단계에서 발생할 수 있는 위해 요소를 규명하고 이를 중점적으로 관리하기 위한 위생 관리 시스템을 일컫습니다. 갑자기 아닌 밤중에 홍두깨라고 프로젝트 관리에서 음식 이야기를 꺼내냐구요? 조금만 더 가봅시다.

패스트푸드의 어두운 면을 적나나하게 그린 책인 '패스트푸드의 제국'(에릭 슐로서 지음, 김은령 옮김, 에코리브르 펴냄)를 보면 HACCP이 떠오르게 된 동기를 소개합니다. 햄버거에 이콜리 균이 감염된 음식을 먹고 아이들이 사망하는 바람에 큰 사회적인 문제를 일으킨 이후에 도축장과 가공 공장이 의무적으로 HACCP을 따르도록 미 행정부에서 규정을 만들어 내었습니다. 쉽게 말해 음식물을 안전하게 가공하고 유통하는 새로운 프로세스를 도입한 셈입니다. 하지만 유감스럽게도 현실은 그렇지 못했습니다. 연방 조사관과 육류 검사관은 고개를 가로저었고, 현장에서 직접 뛰고 있는 품질 관리자조차도 HACCP은 서류상의 이야기일 뿐 실질적으로는 별 도움이 안된다는 맘 속에 품고 있던 이야기를 꺼내놓았습니다. HACCP는 이름만 거창하지 실제로는 도축장과 가공 공장이 자발적으로 만든 프로그램을 따르도록 면죄부를 주는 결과를 초래했고, 고양이에게 생선을 맡긴 꼴이 되고 말았습니다. 한국에서도 단체 급식 과정에서 식중독 사고가 생겨서 큰 대기업이 곤란을 겪기도 했었는데, 과연 대기업 내부적으로 체계적인 프로세스가 없어서 이런 일이 생겼을까요?

HACCP은 거리가 너무 먼가요? 그렇다면 조금 더 소프트웨어 쪽 이야기로 넘어옵시다. ISO 900x 시리즈 인증을 받아본 경험이 있는 분이라면 누구나 느끼겠지만, 이론과 실제는 다릅니다. ISO 900x 시리즈도 실제 생산 공정에는 전혀 무관하게 서류 작업만 제대로 하면 얼마든지 획득할 수 있습니다. HACCP과 마찬가지로 ISO 900x도 빈틈이 너무나도 많은 규약인 셈입니다. 프로세스를 제대로 따라서 작업을 하면 되지 않겠느냐구요? 현장에 가서 이런 틀에 박힌 이야기를 하면 바로 쫓겨납니다. 시간과 인력을 충분히 확보하지 않은 상태에서 프로세스에 따라 작업하라는 이야기는 매일 철야하고 휴일 근무하라는 이야기와 똑같습니다.

좋습니다. 여기까지는 강 건너 불 구경이었습니다. 그렇다면 실제 소프트웨어를 다루는 CMMI와 같은 프로세스 개선 프로그램은 어떨까요? 역시 HACCP나 ISO 900x와 같은 운명에 처해있습니다. 심지어 CMM 5등급을 받은 놀라운 회사도 100% 소프트웨어 오류를 막을 수 없다는 연구 결과가 나와 있을 정도이니 할 말이 없습니다. 저도 미국 현지 CMMI 공인 강사가 진행하는 CMMI GAP Analysis 직전 단계까지 다루는 워크숍에 참석해보았지만, 최전선에서 야근하는 소프트웨어 개발자에게 불을 밝혀주는 빛나는 등대는 온데간데 없고 해변 가득 자욱하게 내려앉은 짙은 안개만 보다가 돌아왔습니다. 관리자를 위한 관리 기법은 관리자만 사용하면 됩니다. 이를 개발자에게도 강제하려다 보니 온갖 부작용이 생기게 됩니다.

좋습니다. 개발자가 상부에서 낙하산을 타고 내려온 프로세스를 거부할 때가 언제나구요? 특별한 추가 인력이나 시간 확보 약속이 없이 막무가내로 진행하는 경우와 소프트웨어 개발 생산성이 장기적으로도 떨어지고 단기적으로도 떨어지리라고 예측했을 경우입니다. 전사적으로 특정 프로세스를 도입하자는 이야기가 나올 경우 실제 생산성이 올라가는지를 검증하는 파일럿 프로젝트를 먼저 진행해보고 이 결과에 따르겠노라고 이야기하십시오. 별 외부 압력이 없는 파일럿 프로젝트조차도 특정 프로세스를 야전교범대로 그대로 적용해서 성공시키기란 하늘에 별따기입니다. 경험이 풍부한 개발자라면 이런 파일럿 프로젝트에 참가할 여력이 없을테고(제 말이 틀렸나요? 설령 파일롯 프로젝트에 투입된다고 할지라도 며칠 후 발등에 불이 떨어져서 유지 보수나 신규 프로젝트를 빌미로 얌전히 원상 복귀 될 겁니다. 제가 맛있는 맥주 내기 걸 수 있어요!), 병아리 개발자나 일부 의욕이 앞서는 개발자만 투입될테니 말입니다. 좋은 개발자가 없이 프로젝트가 성공할 수 있나요?

결국 오늘의 핵심은 _프로세스_가 아니라 _사람_이네요. 프로세스에 알듯말듯한 반감을 느끼신 분이라면 속이 좀 시원해 지셨나요?

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림