[16장 보충] '정치적인'이라는 수식어를 붙이고 싶을 때

사람들이 워낙 정치판에 나쁜 기억이 있어서 그런지 몰라도 '정치적인'이라는 수식어가 들어가면 부정적인 느낌이 듭니다. 한번 테스트를 해볼까요?

• 정치적인 사장
• 정치적인 팀장
• 정치적인 갑
• 정치적인 교수
• 정치적인 동료

위 예제를 보면서 어떤 느낌이 들었습니까? 말만 앞서고 책임을 회피해서 남에게 전가시키며 요령을 피워서 임기응변식으로 상황을 극복해나가는 성향이 있으리라는 생각이 불현듯 떠올랐을겁니다.

정말 그럴까요? 다시 한번 물어보지만 정말 그럴까요? 저도 반성을 하고 있지만 스캇 버쿤이 말하듯이 '정치적'이라는 수사를 붙일 경우에는 다른 사람과 함께 일하는 과정에서 불가피하게 생기는 불쾌한 측면을 회피하려는 순진하고도 편리한 방법일 가능성이 상당히 높습니다. 특히 개발자 입장에서 '관리부서', '마케팅'이 얼마나 비효율적이고 멍청한지 성토하는 자리에서 꼭 나오는 단어가 바로 '정치적'이 아닐까요? 좋습니다. 술자리에서는 안주거리로 마음껏 드셔도 되겠지만, 이렇게 '정치적'이라는 수사를 붙인다고해서 욕하는 상대편이 갑자기 덜 정치적으로 변한다거나 똑똑한 사람으로 탈바꿈할리는 만무할테니까, 적당한 선에서 끝내야 합니다.

'정치적'이라는 수식어를 붙여서 스테레오 타입으로 만들어버릴 경우에 가장 큰 손실은 무엇이냐 하면... 진짜 중요한 문제와 해결책을 가려버린다는 데 있습니다. "이 바닥이 원래 그러니 그래."라고 포기해버리면 해결책을 절대 찾을 수 없습니다. 정치적으로 행동해야 할 때는 정치적으로 행동해야 합니다. 이를 인정하지 못하면 현실적인 상황 판단 대신에 좌절감이나 영양가없는 비난만 커지게 됩니다.

자 그렇다면 정치를 어떻게 이해해야 할까요? 제가 오늘 말씀드리고 싶은 내용은 '문제 해결'의 일종으로 여겨달라는 부탁입니다. 아니 정치가 문제 해결이라구요? 공학도가 공학적인 제약하에서 문제를 해결하듯이 프로젝트 관리자도 정치적인 제약하에서 문제를 해결해야 합니다. 조직 내 모든 자원을 무제한으로 활용이 가능하다고 하면 애초에 정치적인 문제는 일어나지도 않았을 겁니다. 상황이 어떻게 되었거나 특정 상황에서 관리자가 선택할 수 있는 현실적인 방안은 한정되어 있으며, 각 방안마다 정치적인 중요성이 따라붙습니다. 따라서 공학 문제를 풀 때 사용하는 규율과 창조력으로 조직적인 문제에 접근한다면 올바른 방안을 찾아 좋은 결정을 내릴 수 있게 됩니다.

말은 쉽지만 행동은 어렵다고 했습니다. 정치적인 문제 해결을 위한 기초 훈련을 어떻게 하면 좋을까요? 옆 동네로 눈을 돌려서 경제학 분야에서 다루는 의사 결정론을 유심히 살펴보시기 바랍니다. 효율적이면서도 항상 비슷한 결과를 내도록 만드는 의사 결정 방법을 체득한다면 권력의 오용이나 남용에 따른 부작용을 최소화할 수 있으며, 일관성 있는 태도로 인해 주변 사람의 신뢰도 구축할 수 있지 않을까 싶습니다.

자 다시 한번 테스트를 합시다.

• 정치적인 사장
• 정치적인 팀장
• 정치적인 갑
• 정치적인 교수
• 정치적인 동료

어떤 느낌이 들었나요? 여전히 부정적인 느낌이 듭니까?

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

[15장 보충] 버그 경향을 통한 제품 출시 일정 결정

제품을 언제 출시해야하는지는 모든 이의 고민입니다. 개발자는 하루라도 늦게 제품을 출시하기를 바라고 영업/마케팅은 하루라도 빨리 제품을 출시하기를 바랍니다. 고객은 당연히 빨리 신제품을 보기를 원하겠지요? 그렇다면 어떤 기준에 의해 제품 출시 일정을 결정해야 할까요? 그냥 사장님 마음? 갑의 변덕? 영업/마케팅과 연구소 사이의 권력 투쟁? 권력을 쥐고 있는 높으신 분이 날씨나 기분에 따라 들이대는 자의적인 기준이 아니라 뭔가 정량적인 기준이 있으면 좋겠다는 생각이 들지 않습니까?

마이크로소프트 사에서 채택하고 있는 출시 일정 결정 방법은 바로 버그 경향 분석을 통한 황금율입니다. 제품 출시 준비가 가까워질수록 새로운 버그 감지 비율이 0에 가까워집니다. 따라서 버그 경향 분석이 제대로 이뤄진다면 얼마나 제품이 빨리 안정화되는지 감지가 가능하고, 이 정보에 따라 제품 출시일을 근접하게 추정할 수 있습니다. 이번에 무척 말이 많았던 마이크로소프트의 신형 운영체제인 비스타도 버그 경향 분석에 따라 제품 출시 일정이 여러 차례 바뀌었던 걸로 보입니다.

비록 조금 오래된 통계 자료이지만 마이크로소프트 맥 워드 4.0 사후 분석 보고서에 실린 버그 감지 비율 그래프를 예를 들어보자면, 1988년 3월달 평균 버그 숫자가 100이라면(이후 버그 숫자는 100에 대해 상대적인 비율), 여러차례 등락을 거듭해서 1988년 10월 코드 완료 시점에서 30을 가리킵니다. 후반 테스트가 강화되면서 1988년 말에는 다시 급상승해서 거의 60을 가리키게 되며, 차츰 낮아져서 1989년 4월 무렵에는 10 이하로 떨어져서 안정화 됩니다. 마이크로소프트와 같이 오피스 프로그램에 강한 회사조차도 코드 완료 시점에서 버그 감지 비율이 0에 가까워지기까지 거의 5개월이 결렸다는 사실을 비춰볼 때, 소프트웨어 부문에서 안정화 작업이 얼마나 어려운지 감이 올겁니다.

이런 이유로 인해 제품 출시가 가까워지면, 프로젝트 관리자, 개발자, 테스터가 눈코뜰새 없이 바빠지게 됩니다. 모든 사람이 코드를 테스트하고 버그를 감지해서 평가하고 결함을 수정하는 작업에 매달립니다. 테스트는 모든 사람이 진행할 수 있지만, 수정은 개발자만이 가능하므로, 개발자가 코드를 바꿔서 거의 매일 체크인한 다음에 일일 빌드를 통해 제품을 안정적이고 항상 준비된 상황으로 유지해줘야 합니다. 이런 작업을 계속 진행하다보면 어느 순간 개발자가 테스터를 따라잡는 순간 - 다시 말해 알려진 모든 심각한 버그를 잡는 순간이 오기 마련입니다. 바로 이 때를 제로 버그 반동(zero bug bounce)라고 부릅니다. 마이크로소프트 버그 경향 황금률에 따르면 응용 프로그램 부문에서 제로 버그 반동이 일어나면 대략 6주 후에 제품 출시가 가능하다고 합니다. 물론 요즘 나오는 복잡한 프로그램의 경우에는 6주가 아니라 6달이 될지도 모르지만 말입니다.

이렇게 개발팀은 황금률을 뒷받침하는 자료를 확보하고 있어야 합니다. 그래야 위에서 낙하산 식으로 떨어진 출시일정에 휘말리는 바람에 불어오는 피바람을 피할 수 있습니다. 여러분 회사는 어떻습니까? 체계적으로 버그 데이터베이스를 구축/운영하는 노하우를 보유하고 있습니까? 만일 이런 노하우가 있는 회사에 근무한다면 당신은 행운아입니다.

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

[14장 보충] 코딩 파이프라인과 분기 예측

"The Art of Project Management" 전체 내용을 통틀어 가장 흥미로운 부분을 손꼽아 보라고 하면 반드시 들어갈 내용이 바로 14장에서 다루고 있는 '코딩 파이프라인'입니다. 코딩 파이프라인은 구현 전에 수행했던 계획과 설계를 모두 정해진 시간 내에 프로그래머가 막힘없이 효율적으로 진행하기 위해 필요한 작업 연속성으로 생각하시면 됩니다. 코딩 파이프라인을 막힘없이 돌리는 작업은 PM에 달려있으며, 프로그래머보다 며칠 앞서 설계안을 마무리하고 파이프라인을 채워넣는 작업을 진행해야 합니다.

(그림은 '반지의 제왕'으로 유명한 웨타 디지털에서 수행하는 프로젝트 진행 파이프라인)

보통 PM은 여러 개발자 작업을 관리하므로, PM 자신의 시간을 잘 분배해서 여러 파이프라인을 잘 조율해야 합니다. 혼자 모든 일을 처리하기 어려우므로 PM이 수석 프로그래머와 협력해서 작업을 진행하는 경우가 많습니다. 그렇다면 효율적인 코딩 파이프라인을 유지하는 비법(?)은 무엇일까요? 다음 네 가지를 생각해봅시다.

• 현재 활발히 구현 중인 작업을 파악합니다. 그래서 프로그래머가 이런 작업을 진행하는 과정에서 발생하는 장애물을 치워줍니다.
• 현재 작업 항목을 명세서에 맞게 구현하는 데 필요한 모든 사항을 프로그래머가 파악하고 있는지 살펴봐야 합니다. PM과 설계자는 빈틈을 찾아내고 해결하는 과정에 적극적으로 참여할 필요가 있습니다.
• 다음으로 구현할 작업 항목을 파악합니다. PM은 항상 한발 앞서 프로그래머가 현재 구현 중인 작업 항목 다음에 이어지는 작업 항목이 무엇인지 파악해서, 현재 진행 중인 작업에 문제가 없다면 바로 다음에 이어지는 파이프라인을 채울 작업 항목에 초점을맞춰 야 합니다. 프로그래머가 작업을 시작할 시점에 프로그래머를 지연시키거나 중단시킬 미해결 사안이 있다면, 프로그래머에 한발 앞서 이를 해결해놓아야 합니다.
• 완료한 작업이 정말로 완료되었는지 확인해야 합니다. 단위 테스트와 일일 빌드를 사용해서 정말로 파이프라인에 들어있는 작업 항목이 끝났는지 점검할 필요가 있습니다.

우와! 코딩 파이프라인은 프로젝트 중반 이후에 실제 코딩에 들어가면서부터 등장하는 정말 중요한 개념이므로 관리자나 프로그래머는 항상 코딩 파이프라인에 문제가 없는지 촉각을 곤두세워야 합니다. 하지만 프로젝트 관리에서도 일반적인 CPU 아키텍처와 마찬가지로 '분기 예측'이라는 골치 아픈 문제가 등장합니다.

분기 예측은 파이프라인을 채워서 명령을 수행하고 있는 도중에 조건문이 걸려서 명령 분기가 일어나기 때문에 기존 파이프라인을 비우고 새로운 명령을 채워넣도록 만드는 현상입니다. 분기 예측이 정확하다면 파이프라인을 비울 필요가 없으므로 프로그램(컴퓨터 아키텍처 관점)이나 프로젝트(프로젝트 관리 관점) 수행 속력에 영향을 미치지 않지만, 분기 예측이 부정확할 경우에 심각한 문제가 발생합니다. 바로 앞으로 수행을 위해 준비하고 있던 작업 계획이 엉망이 되어버린다는 사실입니다.

이론과는 달리 현실에서는 분기 예측이 자주 실패합니다. 예를 들어 철썩같이 믿고 있었던 클래스 라이브러리에 심각한 버그가 있어서 이를 활용하지 못하고 직접 구현해야 한다거나, 하드웨어 명세와는 달리 실제 지원 범위에 제약이 있어서 구현 과정에서 다른 하드웨어 기능을 사용해야 하는 외부적인 문제점 노출과 요구 사항에 결함이 구현 과정에서 발견되어 설계부터 뒤집어 버리는 경우가 여기에 해당합니다.

코딩 파이프라인을 원활히 유지하도록 치밀하게 계획을 작성하는 임무 이외에도 코딩 파이프라인이 돌아가면서 발생하는 분기 예측에 대한 임무가 PM에게 하나 더 추가되는 셈입니다. 바로 여기서 유능한 PM과 무능한 PM의 차이점을 여기서 찾아낼 수 있습니다. 유능한 PM은 분기 예측 실패 확률을 최소로 줄입니다. 무능한 PM은 분기 예측 자체에 대한 감이 없기 때문에 잦은 파이프라인 미스를 유발합니다. "여러분 미안합니다. 이 산이 아니라 아까 저 산이었습니다. 설계와 프로그램을 모두 다시 하시기 바랍니다."라는 말 한마디에 코딩 파이프라인은 공황상태에 빠져들며 개발자는 왕짜증 모드에 무한 야근 모드로 돌입하게 되므로 전반적인 생산성이 낮아질 수 밖에 없습니다.

결국 이런 코딩 파이프라인 해악(hazard)를 얼마나 줄이느냐에 따라 중반 이후 프로젝트 승패가 갈립니다. 리눅스 커널에서는 분기 예측을 돕기 위해 프로그래머가 likely()와 unlikely()를 명시적으로 사용하는 경우가 있는데, PM도 프로그래머와 밀접한 의사소통을 통해서 사전에 분기 예측 확률을 구할 필요가 있습니다. PM이 일방적으로 명령을 내리고 프로그래머가 이를 따르는 방식이 큰 효과가 없다는 중요한 이유 하나가 오늘 밝혀지네요. 당신이 PM이나 수석 프로그래머라면 종종 프로그래머들과 맥주집에 가서 허심탄회하게 코딩 파이프라인을 막는 문제점을 파악하고 분기 예측에 도움이 되는 정보를 얻으십시오. 그리고 이렇게 얻어낸 정보를 프로젝트 관리에 활용하십시오.

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

[13장 보충] 급할수록 돌아가라

옛말에 '급할수록 돌아가라'는 속담이 있습니다. 프로젝트가 엉망진창이 되고 일정이 밀릴 때는 누구나 급한 마음에 프로젝트 팀원을 재촉하게 되는 데, 여러 가지 문제가 생기지 않던가요? 오늘은 임계 경로와 관련해서 버퍼를 어떻게 둬야할지 함께 고민해보기로 합시다.

임계 경로 방법은 1950년대 듀폰에서 공장 관리와 유지보수를 위해 만들었으며, 다음과 같은 세 가지 항목을 포함하여 프로젝트를 모델링 하는 기법을 말합니다.

• 프로젝트를 완료하기 위해 필요한 모든 활동 목록
• 각 활동을 끝내기 위해 필요한 시간
• 활동 사이에 의존성

이렇게 활동을 정의하고 활동 사이에 의존성을 그리고 나면 특정 프로젝트를 끝내기 위해 반드시 핵심적으로 수행해야 하는 간선 도로, 즉 임계 경로를 발견하게 됩니다. 임계 경로에 놓여있는 작업이 늦어지면 모든 작업이 늦어지는 결과를 초래하므로, 프로젝트 관리자는 임계 경로 관리에 전력투구해야 합니다.

여기까지 다 아는 내용이라구요? 그렇다면 지금부터 일반적인 상식과 전혀 맞지 않아 보이는 재미있는 이론을 하나 소개합니다. 바로 톰 드마르코가 slack이란 책에서 말한 '급할수록 돌아가라'입니다.

드마르코는 프로젝트가 늦어져서 "서둘러, 서둘러, 서둘러, 서둘러, 서둘러"라고 말할 때는 "천천히"가 필요할 때라고 지적합니다. 아니 자다가 남의 다리 긁는 이야기라구요? 이런 가능성을 이해하려면 활동 관점으로 프로젝트를 보지 말고 사람 관점으로 프로젝트를 봐야 합니다. 조직은 사람으로 구성되어 있고, 사람 사이에 정보, 작업 결과물, 부산물이 흘러갑니다. 작업을 진행하다보면 자연스럽게 불균형이 생깁니다. 예를 들어 탐이 제리가 만든 작업을 기다리면서 스타크래프트를 하고 있군요. 결국 탐은 야근을 하고 있긴 하지만 생산성에 기여하는 바는 0이며 너무 오랫동안 스타크래프트를 하는 바람에 제리가 결과물을 넘겼을 무렵에는 지쳐서 하루 쉬고 그 다음 날 작업을 진행할지도 모르므로 생산성이 마이너스로 갈지도 모릅니다. 어디서 많이 본 모습 아닙니까?

이런 상황을 피하기 위해 드마르코는 시스템에서 특정 사람이 너무 많은 산출물을 만들거나 너무 적은 산출물을 만들지 않도록 전반적인 생산성을 떨어뜨려서 균형잡힌 버퍼를 유지하도록 조언합니다. 자 이제 제리 작업 일부를 탐에게 넘겨서 균형을 맞추고 나니까 기다리느라 야근할 필요없이 모든 사람이 일과 중에 바쁘게 움직이네요.

항상 일이 이렇게 진행되면 얼마나 좋겠습니까만은... 꽉 짜여진 틀이 아니라서 살다보면 매일매일 상황이 바뀌게 됩니다. 이는 새로운 작업 불균형을 초래해서 며칠 지나면 다시 어떤 사람은 일에 치이고 어떤 사람은 일을 기다리느라 허송 세월을 보냅니다. 아이쿠 원래대로 돌아왔네요...

다시 탐을 봅시다. 탐이 자기 작업 버퍼가 비어간다는 사실을 발견하고, "서둘러, 서둘러, 서둘러"라는 압력을 받으면 탐은 "바쁜척이라도 해야겠군"이라는 생각이 들겁니다. 탐 주변에 있는 모든 사람이 허둥지둥 작업을 하고 있으니, 탐은 자기 버퍼가 다 비어서 스타크래프트밖에 할 일이 없음에도 불구하고 늘 불안감을 느낍니다. 일찍 퇴근하면 다른 팀원에게 민폐를 끼치는 듯이 보이기도 하구요 심하면 죄의식을 느낄지도 모릅니다.

이럴 때 탐이 살아남는 방법은 바로 버퍼가 비어가기 시작하면 일을 천천히 진행하는 겁니다. 물론 너무 심하게 느림보로 변하면 병목으로 작용하기 때문에 관리 압력이 들어오므로 버퍼에 딱 맞춰 천천히 가도록 엑셀레이터를 밟아야 합니다. 자 지금부터는 탐이 항상 스타크가 아닌 업무에 100% 시간을 사용하므로 버퍼가 병목이 아니라 진짜 작업을 위한 대기열로 바뀝니다. 동료에 대해 미안한 감정이나 죄의식을 느낄 필요도 없겠죠? 여러분도 앞으로 "서둘러"라는 말이 나오면 "천천히"라는 말로 해석하시기 바랍니다.

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