[독서광] 린 소프트웨어 개발의 적용

이 책을 다 읽고 나서 서평 작성을 위해 첫 페이지(색지로 되어 있는 부분)를 펼쳤더니 '린 소프트웨어 개발 원칙'이라고 책 전체를 정리해 놓은 요약이 눈에 들어왔다. 나름 책을 상당히 까칠꼼꼼하게 읽는다고 자부했지만 예상하지 못했던 곳에서 허를 찔리면 늘 즐겁다. 우선 이 책 특성을 가장 잘 나타내는 요약 부문을 (예상 독자)를 위해 간략하게 정리해보겠다.

• 낭비를 제거하라
  
  
  
  • 가외 기능
    
  • 혼란
    
  • 경계 넘어가기
    
  
  
• 품질을 내재화하라
  
  
  
  • 테스트 주도 개발을 통해 코드 실수를 방지하라
    
  • 레거시 코드를 만들지 마라
    
  • 빅뱅 통합은 진부하다
    
  
  
• 지식을 창출하라
  
  
  
  • 과학적 방법을 사용하라
    
  • 표준은 도전받고 개선되기 위해 존재한다
    
  • 예측 가능한 성과는 피드백에 기반한다
    
  
  
• 확정을 늦춰라
  
  
  
  • 의존성을 깨뜨려라
    
  • 옵션을 유지하라
    
  • 돌이킬 수 없는 결정은 마지막 순간에 하라
    
  
  
• 빨리 인도하라
  
  
  
  • 신속한 인도, 고 품질, 저 비용은 공존할 수 있다
    
  • 대기 행렬 이론을 개발에 적용하라
    
  • 일의 양을 할 수 있는 만큼으로 제한하라
    
  
  
• 사람을 존중하라
  
  
  
  • 팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다
    
  • 효과적인 리더십을 제공하라
    
  • 파트너를 존중하라
    
  
  
• 전체를 최적화하라
  
  
  
  • 전체 가치 흐름에 초점을 맞춰라
    
  • 완전한 제품을 인도하라
    
  • 더 높은 것을 측정하라
    
  
  

'린 소프트웨어 개발'은 유명한 자동차 회사인 도요타에서 고객 가치 창출에 최우선을 둔 기민한 생산 방법론을 소프트웨어 세상으로 옮겨온 버전으로 생각하면 된다. 엄청난 규모와 인력이 투입되는 대규모 생산 라인과 공장이라는 면모는 그다지 찾기 어려운 소프트웨어 개발 부서 사이에 끊어진 연결 고리를 찾기 위해 메리 포펜딕과 톰 포펜딕 부부는 좌충우돌 경험담을 이 책에서 풀어놓고 있다.

포펜딕 부부는 엄청난 압력, 딱 정해진 기한, 까탈스러운 고객 요구 사항이 짬뽕이 되어 사람들을 압박하는 분야가 비단 소프트웨어만이 아닌데, 왜 그렇게 소프트웨어 부문에서는 그렇게 삽질이 많은가라는 의문을 던진다. 매달 책을 칼같이 내는 잡지사, 계절마다 난리를 치는 패션 디자이너(얼마나 스트레스가 강한지 궁금하면 악마는 프라다를 입는다를 보시라)', 목이 빠지라고 기다리는 고객에게 정확하게 차를 인도하는 자동차 회사, 조금만 방심하면 바로 시장 선두를 빼앗기는 CPU 제조사는 모두 어려운 환경을 잘 극복해나가지만 유달리 소프트웨어 회사는 양치기 소년 짓을 아직까지도 반복하고 있다. 소프트웨어 개발 과정에서 벌어지는 이런 어려운 상황을 극복하기 위해 소위 말해 잘 나가는 제조업에서 아이디어를 빌어와서 소프트웨어 개발에 맞춰 보려는 시도가 바로 린 소프트웨어 시초이다.

이미 엘리 골드렛이 지은 더 골이나 마이크로소프트 사가 생존을 위해 채택한 기민한 방법을 소개하는 Microsoft Secrets를 읽어보신 분들께서는 이 책을 통해 좀더 체계적으로 지식을 정리할 수 있지 않을까 싶다. 특히 성공적인 린 소프트웨어 프로젝트의 표본이라고 말할 수 있는 전략 핵탄두 미사일 탑재 잠수함 개발 프로젝트인 폴라리스 계획과 상용 여객기 부문에서 에어버스에 밀리고 있던 보잉을 극적으로 살려낸 777 프로젝트는 절대 놓치지 말기 바란다.

본문 중에 나오는 일본에서 아주 유명했던(미국에서는 ...) 에드워즈 데밍 이야기도 흥미로웠다. 데밍이 주장한 '경영을 위한 14가지 포인트'를 읽어보면 탁월한 식견에 놀랄 따름이다. 그 중 몇 가지만 뽑아보았다.

• 7. 리더십을 제도화하라. 관리자의 임무는 사람들이 자신의 일을 더 잘할 수 있도록 돕고, 자부심을 갖고 일을 수행하는 데 방해가 되는 시스템적인 장벽을 제거하는 것이다.
  
• 10. 슬로건, 훈계, 목표를 없애라. 결함을 만들고 생산성을 떨어뜨리는 것은 작업자가 아니라 시스템이다. 훈계는 시스템을 변화시키지 못한다.(블로그 주인장 강조: 별 10개에 동그라미 쳐라) 시스템을 변화시키는 것은 경영자의 책임이다.
  
• 11. 작업자의 작업할당량, 경영자들의 목표 수치를 없애라. (우리는 여기에 하나 더 추가한다. '임의로 설정된 개발 데드라인을 없애라') 이는 두려움과 공포를 이용한 관리이다. 진정한 리더십을 발휘하라.
  

결론: 프로젝트 관리자라면 이 책을 반드시 읽어보기 바란다.

자... 독자 여러분께서 학수고대하던 까칠 모드로 들어간다. 이 책을 읽다보니 역자들이 서두르는 바람에, 충분히 뜸이 들지 않았다는 생각이 떠나지 않았다. 즉, 완성이 덜 된 느낌이 든다. 번역을 정확하게 했는지도 조금 의문이 드는데, 예를 들어 40페이지 '원칙: 6 사람을 존중하라'를 보면 본문 번역도 잘못되었고(원서부터 잘못되었는지는 원서가 없어 확인을 못해봤다), 역자 주도 잘못되었다. 본문을 읽어보면 대규모 회의 다음 날 부사장이 조엘과 같이 식당에 들었다고 했는데, 원문은 조엘이 식사하는 도중에 갑자기 마이크로소프트 오피스 부문장인 피트 히긴스가 '짠~' 등장해서 질문하는 내용이었다.(주의: 블로그 주인장이 '조엘 온 소프트웨어' 번역자라는 사실을 기억하라.) 역자 주에는 이 내용이 '똑똑한, 100배로 일 잘하는 개발자 뽑기: 조엘 온 소프트웨어 시즌 2'에 나온다고 설명이 되어 있는데, 실제로는 한국어판 '조엘 온 소프트웨어' 22장 '이야기 둘'에 나온다. 나중에 잘못된 역자주에 낚였다고 불평하지 마시길...

추가: kks군 확인에 따르면, '원칙: 6 사람을 존중하라' 부분은 번역이 아니라 원서가 잘못되었다고 한다(그러면 역자주까지 달면서도 다시 한번 '조엘 온 소프트웨어' 원문을 검토하지 않았다는 이야기인가?????). 본문 중에서도 원서 쪽 오류라고 짐작되는 곳이 몇 군데 눈에 들어왔는데, 어디인지 잊어먹었다. T_T 시간 내어 검토해주신 kks군에게 다시 한번 감사!

EOB