1. 바벨 프로젝트의 경영 감사.
창세기의 바벨탑은 프로젝트 성공에 필요한 전제 조건(명확한 임무, 인력, 재료, 시간, 기술)을 갖추었으나 크게 실패했다.
프로젝트가 실패한 두 가지 이유는
의사소통, 거기서 귀결되는조직이다.
2. 대규모 프로그래밍 프로젝트 내 의사소통
일정 붕괴, 기능적 부조화, 시스템 버그 같은 일들은 모두 오른손이 하는 일을 왼손이 알지 못해서 생긴다. 일이 진척되어 가면서 몇몇 팀이 자신들 프로그램의 기능, 크기, 속도를 조금씩 바꾸고 입출력에 대한 가정 역시 명시적, 혹은 암묵적으로 변경한다.
따라서 팀들간 의사소통을 위해 가능한 한 여러가지 방법을 동원해야 한다:
- 비공식적으로 소통한다. (e.g. 전화 서비스 품질이 괜찮다면 빈번하게 연락하여 소통할 수 있따.)
- 회의를 이용한다. 각 팀이 차례로 기술적 브리핑을을 하는 정기 프로젝트 회의는 매우 유용하다.
- 워크북을 활용한다.
3. 워크북
- 1. 워크북인란 무엇인가?
프로젝트 진행 과정에서 생상되는 모든 문서
- 프로젝트 목표
- 외부 명세
- 인터페이스 명세
- 기술 표준
- 내부 명세
- 관리 메모 등등...
- 2. 왜 만드는가?
프로젝트 워크북의 구조를 설계해 두면 문서화가 마구잡이로 진행되는 것을 방지할 수 있음이 첫 번째 이유다.
두 번째 이유는 정보 전달 통제다. 정보의 제한이 목적이 아닌 필요한 사람 모두에게 관련 정보가 전달되도록 하기 위함이다. 이를 위해 모든 메모에 번호를 붙여 목록으로 정리하거나 메모들을 계층적인 트리 단위로 관리할 수 있다.
- 3. 어떻게 운영하는가?
옛날에는 '모든' 프로그래머가 '모든' 자료를 보기 위해 자기 사무실에 워크북 사본을 하나씩 갖고 있었다고 한다. 정말 놀라운 사실은 루스리프(looseleaf)식 제본의 노트(???) 로 보관됐다고 하는데...
나중에는 워크북의 두께가 1.5m 에 달했고 사무실 내 프로그래머들에게 배포된 100권(?????) 은 차곡차곡 쌓으면 사무실이 있던 맨해튼 타임-라이프 빌딩보다도 더 높아질 지경이였다.
이 시점에서 마이크로피시(microfiche)로 워크북을 전환했다. 필자는 마이크로피시가 Micro PC 의 약자인줄 알았는데 놀랍게도 아니였다...
영상을 보면 알겠지만 그냥 메모가 적힌 필름이다... 보기만 해도 아찔하다.
마이크로피시는 공간적 측면과 워크북 제작에 들어가는 소요시간을 크게 줄일 수 있으나 단점도 있다. 관리자 입장에서 문사 사이에 종이를 끼우며 철하는 불편함은 다른 한편으론 그 변경 사항들이 원래 목적대로 '읽혀짐'을 보장하는 측면이 있으나, 마이크로피시를 사용하는 경우 변경 사항을 담은 종이 문서를 함께 배포하지 않으면 워크북 유지 관리가 지나치게 손쉬워지는 면이 있다.
필자가 보기에 이건 너무 옛날 방식이라 솔직히 이해도, 공감도 쉽게 되지 않는다. 확실한건 위 방식은 절대 쓰면 안된다는 것이다
- 4. 오늘날에는 어떻게 운영할 것인가?
워크북을 직접 접근식 파일에 두고 변경 표식과 개정 일자를 명기하는 방법이 좋을 것 같다. 필자가 보기에 위 이건 너무 구식이다. 단순하고 쉽게 git 을 통해서 문서의 버전을 관리할 수 있다. 정말 어떻게 이런 환경에서 대규모 프로젝트 작업을 진행할 수 있었는지가 놀라울 따름이다.
4. 대규모 프로그래밍 프로젝트의 조직 구성
조직의 목적: 필요한 의사소통 및 팀 간 조율의 양을 줄이는 것이다.
따라서 조직이란 개념은
의사소통 문제에 대한 근본적인 해결책이다.
의사소통을 줄이기 위한 방도는 분업 과 전문화 다. 트리 형태의 조직 구조에는 분업과 전문화가 적용될 때 세세한 의사소통의 필요가 줄어드는 것이 나타나 있다.
그러나 실제 소통에서 트리 구조는 별 의미가 없으며 실제론 매트릭스형으로 진행된다. 트리 형태의 프로그래밍 조직을 가정할 때, 효율적인 운영을 위해 서브트리에 해당하는 하위 조직이 반드시 갖춰야 할 핵심 사항은 이하와 같다:
- 임무
- 프로듀서
- 기술 총괄 또는 아키텍트
- 일정
- 업무 분장
- 각 파트 간 인터페이스 정의
여기에서 프로듀서와 기술 총괄을 제외한 나머지의 역할을 자명하다.
- 프로듀서
그렇다면 프로듀서의 역할은 무엇인가? 프로듀서의 역할은 팀을 조직하고 업무를 나누며 일정을 수립한다. 그리고 필요한 자원을 지속적으로 확보할 책임을 맡는다.
이것은 프로듀서의 역할 대부분이 팀 외부와 위로든 옆으로든 소통하는 것임을 의미한다.
- 기술 총괄
그는 설계를 구성하고 하위 요소를 결정하며, 시스템을 외부에서 볼 때 어떻게 보일지를 명세하고, 내부 구조를 스케치한다.
그의 의사소통은 주로 팀 안에서 이루어지며, 업무는 거의 기술적인 것이다.
조직이란 현재 있는 사람들을 중심에 두고 구성하는 것이지, 이론적인 조직에다가 사람들을 끼워 맞춰서는 안된다. 두 사람의 역할 관계는 세 가지 경우가 가능하다.
5. 프로듀서와 기술 총괄의 역할 관계
- 프로듀서와 기술 총괄이 같은 사람일 경우
이 상황은 세 명에서 여섯 명 정도의 아주 작은 팀에 잘 맞는다. 조금 더 규모가 커지면 이하의 이유로 운영이 어렵다:
- 관리적 재능과 기술적 재능이 모두 뛰어난 사람을 찾기가 어렵다.
- 규모가 커지면 각 역할이 상근직 또는 그 이상의 일이 되기 때문이다.
- 프로듀서가 수장이고 기술총괄이 그의 오른팔인 경우
이 상황에서는 기술 총괄을 명령 계층 상에 두어서 시간을 뺏기게 하지 않고도 기술적 결정에 대한 '권위'가 서도록 하는 것이 과제다.
프로듀서가 기술 총괄의 권위를 공원해 두어야 함은 명백하며, 향후 발생할 많은 시험적 사례에 있어 그의 권위를 강하게 뒷받침해 주어야 한다.
- 기술 총괄이 수장이고 프로듀서가 그의 오른팔인 경우
아주 큰 프로젝트 내의 규모 있는 하위 조직이라면 프로듀서가 우두머리를 맡는 것이 더 적합할 수 있다. 이 조합은 3장의 외과 수술팀 과 같은 소규모 팀에 잘 맞는 것이다. 그러나 이런 조직 역시 효과적으로 운영이 가능하다.
필자는 지금까지 맨먼스 미신에서 너무나 당연한 소리를 길게 늘어놓는다고 생각했는데 이는 큰 착각이였다. 위 책이 집필되던 시대는 필자가 생각했던 것보다 훨씬 더 이전(적어도 유닉스 운영체제 이전의 시대)으로 보인다 .
최초의 소프트웨어 팀을 구축하고 그 과정에서 발생한 문제들을 정리하고 어떻게 하면 효과적으로 팀을 운영할 수 있을지 정말 상세하게 잘 적어두었다. 지금의 와서 당연해 보이는 이런 구조는 그들의 시행착오에서 왔으리라 필자는 확신한다.
출처
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음, 강중빈 옮김)
[동영상] https://www.youtube.com/watch?v=HxXhLhTHkD0
