반응형
나의 평점 : 5.0 / 5.0
이 고전을 역시나 이제야 읽었다.
이 고전이 여전히 우리에게 시사하는 바가 크다는 사실에 또 다시 놀랐다.
이런 걸 통찰력이라고 하나보다. 시간이 흘렀지만 소프트웨어 개발의 내면에 흐르는 진리는 뭔가 분명히 있나보다. 그 당시에 짚었던 내용들이 거의 대부분 맞는 것을 보면...
어떻게 보면 시간을 흘렀는데 변한 것은 많이 없다는 뜻일 수도 있다.
그 당시에도 최고 개발자와 최고 관리자는 대우가 거의 동등해야 한다고 주장하고 있으니 말이다.
주로 IBM 메인 프레임 개발에 대한 이야기지만 오래전 시스템 프로그래밍에 대한 여러가지 일화들과 개념들이 그리 낯설게 느껴지지 않았다. 기본적인 틀은 소프트웨어 개발이기 때문일 것이고 또한 말로만 듣던 IBM 360 그리고 OS 개발에 대한 세부적인 이야기이기 때문이었던 것 같다.
일단 시작하면서 이 아저씨가 정의하는 프로그래밍 작업의 즐거움과 고통은 개발자들의 심정을 매우 잘 헤아려 주고 있다.
[작업의 즐거움]
1. 무엇을 만든다는 순수한 즐거움이다.
2. 다른 사람에게 쓸모 있는 뭔가를 만드는 데서 오는 즐거움이다.
3. 다루기 쉬운 매체를 갖고 작업한다는 즐거움이 있다. 프로그램을 작성하는 것은 시를 짓는 것처럼 거의 순수에 가까운 사고 영역에서 작업하는 것이다. 프로그래머는 아무 것도 없는 허공에, 허공으로부터 상상력을 동원하여 성을 쌓는다.
[작업의 고통]
1. 작업은 완벽하게 해야 한다.
2. 목표를 설정하고, 자원을 공급하고, 정보를 제공하는 주체가 내가 아니라 다른 사람이라는 점이다. 자신의 작업 환경, 심지어 자신의 목표를 프로그래머 자신이 직접 정하는 일은 거의 없다. 책임에 상응하는 충분한 권한이 주어지지 않는 것이다.
3. 야심찬 개념을 설계하는 것은 재미있지만, 서캐투성이 같은 자잘한 버그들을 찾는 것은 단순노동에 지나지 않는다.
일정에 대한 통찰력도 봐 줄만 하다.
테스트는 프로그래밍에서 일정계획이 가장 부정확하게 잡히는 부분이란다.
프로젝트들을 조사해 본 결과 테스트에 프로젝트 전체 일정의 절반 정도를 할애한 경우는 매우 드물었지만 실제로는 대부분 실제 일정의 절반 정도를 테스트 목적으로 사용했다고 한다.
지금은 어떤가? 저런 조사 결과가 있었음에도 여전히 테스트를 전체 일정의 절반으로 계획하는 프로젝트는 없는 것 같다.
아직 나에게 익숙하지 않은 설계자의 개념에 대해서도 몇가지 힌트를 주고 있다.
1. 설계자는 구현 작업에 대하여 독재자 노릇을 하는 것이 아니라, 단지 제안하는 역할이라는 점을 기억해야 한다.
2. 구축 담당자가 어떤 것을 명시하더라도 그 구현 방법을 제시할 준비가 되어 있어야 하고, 목적에 부합하는 다른 방법을 수용할 태세가 되어 있어야 한다.
3. 그런 제안들에 대하여 의논할 때는 조용히 비공식적으로 한다.
4. 개선된 결과를 낳은 제안에 대하여는 항상 구축 담당자의 공적을 인정하여야 한다.
아주 쿨한 사람이다. 우리나라 문화에서 이런 설계자가 나올 수 있을까 모르겠다.
사실 미국에도 있을까 의문이기는 한데 저렇게 쿨한 사람이 되어 보고는 싶다. ^^
프로듀서와 테크니컬 디렉터의 관계도 재미있는데 즉, 매니저와 개발리더의 관계다.
우리 주변에는 주로 매니저가 상급자인 경우가 많은데 이 책에서는 매니저가 보스고 개발리더가 보조하는 경우와 개발리더가 보스고 매니저가 보조하는 경우 모두에 대해 설명하기도 한다.
몇가지 본문만 가져와 이야기 해 봤지만 전체적으로 나무랄데 없는 훌륭한 내용이 많이 있다.
나중에 시간 나면 또 읽어 봐야 겠다.
반응형
