How much fun are you to work with?

이미 아는 분은 아시겠지만 지금 소프트웨어 논쟁 2.0(Software Conflicts 2.0)을 한창 번역 중입니다. 충분히 예상은 했지만 번역이 까다로워서 블로그에 조금 소홀하니 이해해주시기 바랍니다.

오늘은 제가 가끔씩 떠올리는 질문 하나를 소개하겠습니다.

원래는 MSNBC에서 상담을 진행하는 Dr. Phill이라는 분이 한 커플에게 던졌던 질문입니다 - 제가 TV를 좀 "많이" 봅니다. ^^;; 서로 항상 싸우다 못해 상담을 신청한 커플에게 이렇게 묻더군요.

"How much fun are you to live with?" (너는 같이 살기에 얼마나 재밌는 사람이냐?)

이상하게 이 질문 하나가 참 오랫동안 마음에 남더군요. 나는 재밌는 사람이랑 같이 지내고 싶고, 재밌는 사람이랑 같이 일하고 싶은데... 그럼 나는 과연 같이 지내고, 싶고 같이 일하고 싶은 사람일까?

내가 함께 일하고 싶다고 느꼈던 사람들을 떠올려봅니다. 나도 동료들에게 그런 사람이 되었으면 합니다. 그래서 가끔 자신에게 이렇게 묻습니다.

How much fun am I to work with?

이해영 올림.

Book of Corporate Life

회사 동료가 보낸 메일입니다. 한국은 곧 긴 명절 연휴가 다가온다죠? 연휴 전에는 더더욱 일이 손에 안 잡히니, 조금 기분전환하시라고 재미난 글 올립니다.

1. In the beginning was the Plan.

2. And then came the Assumptions.

3. And the Assumptions were without form.

4. And the Plan was without substance.

5. And darkness was upon the face of the Workers.

6. And they spoke among themselves saying, "It is a crock of s--t, and it stinks."

7. And the Workers went unto their Supervisors and said, "It is a pail of dung and we cannot live with the smell."

8. And the Supervisors went unto their Managers saying, "It is a container of organic waste, and it is very strong, such that none may abide by it."

9. And the Managers went unto their Directors, saying, "It is a vessel of fertilizer, and none may abide its strength."

10. And the Directors spoke among themselves, saying to one another, "It contains that which aids plant growth, and it is very strong."

11. And the Directors went to the Vice Presidents, saying unto them, "It promotes growth, and it is very powerful."

12. And the Vice Presidents went to the President, saying unto him, "This new plan will actively promote the growth and vigor of the company with very powerful effects."

13. And the President looked upon the Plan and saw that it was good.

14. And the Plan became Policy.

15. And this is how s--t happens.

이해영 올림.

[8장 보충] 순발력 있는 의사 결정이 어려운 이유

프로젝트를 진행하다 보면 순발력있는 의사 결정이 필요할 경우가 있습니다. APM 8장에서 게리 클라인은 "의사결정에 관한 공식적인 방법을 가르치는 강의를 의심하라. 이런 강의는 사람들이거의 사용하지 않는 방법을 가르친다"라고 갈파하고 있습니다. 대신 게리는 노련한 조종사, 소방수, 응급실 간호사가 결정을 내리는 다양한 방법을 설명하고, 교과서에서 가르치는 공식적인 방법을 사용하지 않는다는 사실을 확인해줍니다.

이런 전문가들은 경험, 직관, 훈련, 동료라는 네 가지 무기를 사용해서 위기를 극복합니다. 하지만 이런 작업은 결코 쉽지 않습니다. 오늘은 초기 상승 과정 중에 엔진 고장으로 런던의 히드로 공항에 불시착하는 과정에서 다섯 명의 목숨을 앗아간 동시에 기체 전파라는 치명적인 결과를 초래한 BOAC(과거 British Airways) 707-465 G-ARWE 편의 불운에 대해 이야기해보겠습니다. (아래 사진: 사고기와 유사한 기종)

비행기 운항 중에 비상 사태가 벌어지는 경우가 있습니다. 조종사들은 이런 비상 사태에 대비해서 공통적인 문제와 난관을 시물레이션하도록 훈련을 받습니다. 일단 문제가 발생하면 매뉴얼에 따라 대응을 하게 되는데, 조종사와 부조종사가 서로 교차 점검을 하면서 훈련받은 절차에 따라 한 단계씩 문제 원인 분석과 해결에 들어갑니다. 물론 이 과정에서 조종사의 역량이 무척 중요합니다.

런던에서 쮜리히를 경유하여 시드니로 향하는 BOAC 707-465 G-ARWE는 1968년 4월 8일에 3시 반 경에 런던 히드로 공항을 이륙했습니다. 707 조종 경험이 풍부한 기장 둘과 항법사와 엔지니어를 포함하여 승무원 5명과 승객 127명을 태운 이 비행기는 이륙허가를 받은 다음에 활주로를 가로질러 날아올랐습니다. 하지만 이륙 후 20초 후에 2번 엔진에 화재가 발생했고 기장이 이를 감지해서 'fire drill'을 외치고 비상 대응에 들어갔습니다.

초기 대응은 신속했습니다. 기장은 관제탑에 비상 사태가 났음을 알려주고 비상 착륙 허가를 요청했으며, 엔지니어인 힉스가 'fire drill' 절차에 따라 점검 항목을 살피면서 1단계 조치에 들어가고, 2단계 조치를 계속해서 수행했습니다. 1등 항법사인 키크랜드가 힉스를 돕기 위해 큰 소리로 점검 항목을 반복해서 읽으려고 했으나 힉스는 이미 처리가 끝났다고 중단 시켰습니다. 바로 이런 사소한 실수가 큰 문제를 일으키고 있다는 사실을 모른채 말입니다.

화재가 발생했을 때, 비행기는 225노트로 3000피트 상공에서 운항 중이었기 때문에 비상 착륙 허가를 받은 활주로 착지 범위에 가까스로 들어갈 상황이었습니다. 설상가상으로 유압 시스템에도 문제가 생겨서 비행기 조종이 상당히 어려운 상황이 되었습니다. 기장은 엔진 화재 대책은 엔지니어에게 전담시킨 채 엔진 세 개로 최대한 단거리 착륙을 감행해야 했습니다.

엔진을 껐음에도 불구하고 화염은 사그러들 기세를 보이지 않았습니다. 착지 한계점까지 400m를 남겨두고 비행기를 착륙시킨 기장은 최대한 빨리 정지시키기 위해 역추진 엔진을 켰지만, 불행하게도 이런 대응이 동체쪽으로 화염 방향을 트는 바람에 문제를 더 복잡하게 만들었습니다.

착륙 직후 바로 기장과 엔지니어는 엔진 세 개를 모두 끄고 화재 진압에 나섰지만 폭발이 일어나고 있었습니다. 다행스럽게 기내 승무원이 엔진에 불이 붙은 상황을 인지하고 조종실에 이야기를 해서 착륙하는 동안 이미 비상 탈출 장치를 준비해 놓은 상황이었습니다. 화재가 커져서 날개쪽에 불이 붙자마자 바로 기체 포기를 택하고 급히 승객을 탈출시키기 시작했습니다.

불붙은 파편이 날아다니고 동체 쪽에도 불이 붙는 바람에 출구가 막힌 승객들은 아비규환 속에서 불이 붙지 않은 반대편으로 탈출을 시도했고 슬라이드가 망가지는 바람에 뛰어내리다가 다친 승객도 많았습니다. 결국에는 승무원 1명을 포함한 다섯 명의 희생자를 내고 말았습니다.

사고 조사 위원회가 기체 정밀 검토를 마치고 내린 결론은 놀랄 정도였습니다. 처음에는 2번 엔진 소화기가 동작하지 않아서 화재가 커졌다고 생각했지만, 소화기는 정상적으로 동작을 했다는 사실이 밝혀졌습니다. 핵심 문제는 승무원 비상 사태 대응 점검 항목에 들어있는 엔진 연료 밸브 잠금이었습니다. 'fire drill' 과정에서 가장 먼저 2번 엔진 밸브를 잠궈야 하는데, 이를 무시한 상태로 계속 비행을 했기 때문에 2번 엔진 일부가 본체에서 떨어져 나간 다음에도 계속해서 화재가 발생했으며, 화재로 인한 유압 밸브 손상으로 인해 유압 시스템에도 문제가 생겼던 것입니다. 어려운 여건에서도 놀랄만한 기술로 기체를 무사히 착륙시켰지만 기체 포기 직전에 연료 부스터 펌프를 꺼야 한다는 사실을 잊어버리는 바람에 생각보다 화재 전파속도가 빨라져서 공항 소방대가 바로 화재 진압에 나섰음에도 불구하고 희생자가 늘어나 버렸다는 사실도 밝혀졌습니다.

기장은 비행기를 착륙시켜야 한다는 임무를 수행하느라 동료 승무원이 'fire drill'을 제대로 수행했는지 감시하지 못했습니다. BOAC의 매뉴얼에 따라 비상시 절차를 복창해야 한다는 사실을 지키지도 않았습니다. 보잉에서 만든 707 조종석은 인체공학적으로 엔진 화재 발생시에 한눈에 문제점이 드러나도록 설계되어 있지도 않았습니다. 탈출구에서 전개된 비상 탈출 장치가 화재에 잘 버티는 재료로 만들어서 30초만 더 버텼더라도 모든 승객을 다 구출했을지도 모릅니다. 결론적으로 말씀드리자면 순발력 있는 의사 결정을 내렸더라도, 환경과 맞물려 전혀 예상치 못했던 상황을 불러일으킬지도 모릅니다. 이렇게 때문에 순발력 있는 의사 결정이 어렵습니다.

사고 이후에 무엇이 바뀌었을까요? 우선 정신 사납게 분산되어 있던 'fire drill'이 'Engine Fire or Severe Failure Drill'로 바뀌어서 단순화되었습니다. 707 조종석에 붙어있는 엔진 관련 스위치 개선이 있었습니다. 707 조종사 매뉴얼이 비상 사태를 대비해서 좀더 강화되었습니다.

BOAC 707-465 G-ARWE 사고 요약은 ASN 보고서를 참조하시고, 자세한 설명은 Macarthur Job이 지은 Air Disaster Volume 1 7장을 참조하시기 바랍니다.

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

[7장 보충] 명세서는 고정 불변일까?

바위에 글자를 새기듯 한번 만들어진 명세서가 절대로 바뀌지 않는다는 느낌이 드는 분들이 많으실 겁니다. 하긴 제품 완성 후에 부랴부랴 조건을 충족시키기 위해 명세서를 급조하는 경우도 있으니, 차라리 처음에 명세서를 만드는 경우는 양반이라고 하겠습니다. 그렇다면 다른 사람들은 어떻게 할까요? 마이크로소프트 사를 좋아하지 않는 분도 계시겠지만, 오늘은 마이크로소프트 사의 예를 좀 들어보려고 합니다. 참고 서적은 Cusumano, Selby가 지은 "Microsoft Secret"(Free Press 1995)입니다.

이미 APM과 조엘 온 소프트웨어를 읽어보신 분이라면 동감하겠지만, 마이크로소프트 사는 명세서에 목숨을 겁니다. 팀 규모가 크고 제품이 복잡하기 때문에 명세서 없이는 어떤 작업도 하기 어렵기 때문입니다. 명세서는 비전문서(vision statement)에서 출발해서 점점 요리 가이드에 가깝게 발전해나갑니다. 예를 들어, 엑셀 5.0의 비전문서 크기는 고작 다섯 페이지였다고 합니다. 하지만 요구 사항 분석 결과를 마치고 코딩에 앞서 완료된 명세서 크기는 무려 1,500페이지에 이릅니다.

그렇다면 이렇게 열심히 만든 1,500페이지에 이르는 명세서가 나중에 어떻게 되었을까요? 우리가 흔히 겪었듯이 프로젝트 완료 후에 높으신 분에게 전달할 목적으로 책장 한 구석에 처박아두는 대신에 프로젝트 진행과정에서 끊임없이 개선되고 추가되어서 프로그램 출시 직전에는 1,850페이지까지 늘어났다고 합니다. 처음에는 전자편지로 주고받던 명세서가 나중에는 한권으로 제본하기에도 어려울 정도였으니 여기에 투입한 인력과 시간을 생각하면 정말 놀랍다는 생각이 듭니다.

그렇다면 페이지를 덕지덕지 붙여서 명세서 크기만 늘어났을까요? 마이크로소프트 사 개발자 내부 인터뷰에 따르면 대략 30퍼센트에 이르는 문서가 변경되었다고 합니다. 초기에 생각한 기능은 그대로 둔 상태에서 새로운 기능만 추가 되었을까요? 그렇지 않습니다. 제품 초기 명세에 포함되어 있는 기능 중에서 20~25퍼센트에 이르는 기능이 없어졌다고 합니다. 그렇다면 명세에 들어있는 모든 기능을 100퍼센트 구현했을까요? 그렇지 않습니다. 대략 70퍼센트 정도 기능만 구현이 된다고 합니다.

이런 상황으로 미뤄볼 때 명세서는 코드와 마찬가지로 유기적입니다. 비전을 망가뜨리지 않는 이상 언제나 항목이 바뀌거나 새로운 항목이 추가되거나 불필요한 항목은 삭제될 수 있습니다. 명세서가 고정되었다는 이야기는 개발자가 창의력을 발휘할 수 있는 숨쉴 공간이 없다는 이야기이며, 결국 태어나기도 전에 죽어버린 제품을 만드는 꼴이 됩니다.

마이크로소프트 사의 예를 보면 비전문서와 프로젝트를 이끌어나갈 기능 명세야말로 프로젝트 성공에 가장 필수적인 요소이므로 여러분들도 프로젝트 진행 과정에서 각별히 주의를 기울이시기 바랍니다.

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

EOB