책 제목에서 풍기는 바와 같이 소프트웨어에 관한 논쟁을 모은 수필집이다. IEEE에서 출판하는 Software 잡지를 구독하는 독자라면 책을 쓴 이 아저씨가 매우 친근할 것이다. 2009년에 아마 ‘Goodbye’라는 컬럼을 마지막으로 Software 매거진의 편집장을 그만 두신 것으로 기억한다.

같이 일하게 된 유명환 대표님께서 읽어보길 권해서, 서울에서 내려오는 차편에서 읽고, 맹장이 터져서 병원에 있는동안 읽게 되었다.

소프트웨어 방법론에 대해서 무지하고, 브룩스 이외에는 아는 것이 전혀 없는 분야이기 때문에 이것 저것 찾아본다고 헤매고 다녔지만 마음에 와 닿는 글이 많아서 남겨본다.

1. 1989년 ICSE(International Conference on Software Engineering) 기조 연설에서 빌 커티스는 이를 멋지게 표현했다. “한 방에 모인 설계자 15명 중 두 사람만 동의하면 이 두 사람이 다수가 된다.” // 소프트웨어 개발 방법론의 다양성에 대한 멋진 표현이다. 개발 방법론이 다양하다는 측면에서 보자면 매우 부드러운(Soft) 분야지만, 다양성이 너무 존중되고, 일반화된 방법론이 없다는 측면에서 보면 전혀 부드럽지(Soft) 못하다는 걸 반증하는 것은 아닐까하는 생각이 들었다.

2. 다음은 D.D. 프라이스의 ‘Sealing Wax and String’ 에서 발췌한 내용으로 알렉산더의 예제와 놀랄 만큼 유사하다. “열역학이 증기 기관에 미친 영향보다 증기 기관이 열역학에 기여한 바가 훨씬 크다. 역사에서 일반적인 사건 발생 순서를 살펴보면 기술이 과학을 응용한 예는 찾아보기 힘들다. 오히려 과학이 기술을 응용한 예가 훨씬 많다.” // ‘프로토타입’에 대한 좋은 설명 아닐까? ‘제품을 보기 전까지, 고객은 무엇을 원하는지 알지 못한다.’ 라는 말과 일맥상통 하는 듯 하다.

3. 설계 자체는 아직 이론으로 설명이 안 되는 부분이 많다. 흔히 설계 과목은 방법론과 표현 방식에 치중하는데, 설계자라면 누구나 설계라는 작업이 단순히 프레임워크나 기록 방법 이상으로 복잡하다나는 사실을 안다. 다시 한 번, 설계 부분에서도 실제가 이론을 훨씬 앞선다. p.6 // 이렇게 실제가 중요하다고 하는데, 그렇다면 이론의 중요성은 어떻게 설명해야 하는 걸까?

4. 진실로 소프트웨어 연구가 미심쩍은 방향으로 엇나가고 있다면 우리는 어떻게 대처해야 할까? 파나스는 여기에 관한 의견도 제시한다.

5. “문제의 실무적인 측면을 잘 아는 사람들만이 연구 프로젝트 결과가 유용한지 여부를 판단할 수 있다. 응용 분야 연구는 성공적인 연구자와 숙력된 시스템 엔지니어가 참여한 팀에서 판단해야 한다. 다시 말하면, 유용한 결과를 내놓고 싶은 연구자라면 평가 과정에 실무자를 참여시켜야 한다.” p.11 // 실무진과 연구자가 함께 참여해야 한다. 이론과 구현의 조화를 강조하는데 이런게 미국에서도 잘 안되는 듯 하다. 배운자의 무능력 때문일까?

6. 그렇다면 파나스와 브룩스가 우리에게 전하려는 메세지는 무엇일까? 소프트웨어 개발은 개념적으로 어렵고, 만병통치약은 없으며, 실무자는 혁명적인 도약을 고대하지 말고 점진적인 발전을 추구해야 한다는 메시지다. p.15 // 저 ‘브룩스’는 그 ‘브룩스’를 말한다. “은총알은 없다”라는 논문으로 유명하고 그것보다 더 유명한 ‘맨먼스’를 만들어낸 그 ‘브룩스’ 말이다. 그런데, 점진적 발전을 추구해야 한다면 혁신은 점진적 발전의 산물인가?

7. 시스템 분석에 관하여, 보고서는 소프트웨어 개발에서 요구사항 정의가 ‘가장 어려운 부분’이라고 지적한다. 요구사항 정의는 소프트웨어 분야에 내재하는 불가피한 문제라고 인정하며, 해결 방법으로 프로토타이핑을 지지한다. p.19 // 고객이 무엇을 원하는지 알아내는 것은 내 자신이 뭘 모르는지 알아내는 것 만큼이나 어렵다. 그러니 고대 그리스에 살던 형님의 말씀이 아직도 전해지고 있는게 아닐까?

8. 설계 교육 면에서, 단순히 방법론이나 표현법 몇 가지를 가르치는 일만으로 충분하지 않다. 설계를 정신적인 과정으로 보는 새로운 개념을 토대로 한 기반 틀안에서 방법론과 표현법을 가르쳐야 한다.

9. 설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이라는 사실을 이해해야 한다. 그래야 설계자가 죄책감을 느끼지 않고 올바른 설계 방식을 추구할 수 있다.

10. 설계 관리 면에서, 관리자는 의사소통 활성화와 문제 해결에 신경 써서 설계에 기여해야 한다. 한 걸음 더 나가서 실증주의 연구자들은 설계 관리를 통해 설계 과정에서 발생하는 핵심 문제를 관리해야 한다고 제안한다. p.35 // 시행착오를 거쳐야 한다. 그렇다면 성공한 케이스를 모아야 하는가? 실패한 케이스를 모아야 하는가?

11. 여기서 잠시만 1950년대를 벗어나겠다. 우리는 다음 몇 가지 사실을 이해해야 한다. 첫째로, 1950년대는 전산 학계라고 칭할만한 분야가 없었다. 전산 학계는 10년 후에나 생겨났다. 당시는 수학, 비즈니스 관리, 심지어 영문학을 전공한 사람들이 프로그래머가 되었다. 그러니 전산쪽 논문도 거의 없었다. CACM에서 조금 다루긴 했지만 많지는 않았다. 좀 더 널리 알려진 데이터메이션이 있었다. 낼개도 펴지 못하고 꺾인 소프트웨어 에이지라고 불리는 운이 없었던 잡지도 있었다. 따라서 출판으로는 소프퉤어 분야에서 명성을 얻기 어려웠다.

12. 둘째로, 1950년대는 소프트웨어 분리 판매가 아직 일어나지 않았다. 사실, 끼워 팔기조차 시작하지 않았다. 때로 컴퓨터 하드웨어에 소프트웨어를 전혀 탑재하지 않은 상태에서 판매되는 경구도 종종 있었다. 이런 상황에서 SHARE와 같은 사용자 그룹이 진가를 발휘했다.

13. 사실 그래서 SHARE라는 이름도 말이 된다. 다른 곳에서 구하지 못하는 소프트웨어를 공유하는 그룹이기 때문이다. p.79 // 그리운 시절이다. 만인이 만인을 위한 투쟁이 없던, 그리고 예전에도 전산쪽은 전산 전공이 아닌 다른 전공자들이 많이 유입되었다는 걸 알 수 있다. 전산 분야는 원래 부터 ‘다른쪽 인재를 포섭해서’ 성장한 분야였던게 아닐까?

14. 프로토타이핑을 놓고 여전히 논쟁 중이든 아니든, 이와 같은 질문은 언제나 유효하다. 프레드 브룩스가 “The Mythical Man-Month”에서 “버릴 수 있도록 만들어라”라고 말한지 십여 년이 넘었지만, 우리는 아직도 방법을 제대로 파악하지 못한 상태이다. 단지 프로토타이핑이 장래성 있는 기술이라는 사실만은 안다. 그리고 그 장래성은 사실인 듯하다. p.93 // 버릴 수 있도록 만들어라. 버릴 수 있도록 만들어라. 버릴 수 있도록 만들어라. 버릴 수 있도록 만들어라.

15. 그때나 지금이나, 방법론이나 분야에 무관하게 모든 소프트웨어 개발자들이 반드시 갖추어야 할 최소 도구 집합이라는 개념이 빠졌다. p.98

16. 또한 컴파일러 개발은 소수만이 흥미를 보이는 분야이다. 이런 이유로 컴파일러 과목을 가르칠 필요가 있는지는 의심의 여지가 있다. ‘가르쳐야 한다’고 우길 정도로 관심 있는 독자도 많지 않다. 하지만 컴파일러 과목은 흥미롭고 더 일반적인 학습 경헙을 제공한다.

17. 첫번째로, 사회가 가르치는 지식과 학생이 배워야 할 지식 사이에는 별다른 관계가 없다. 컴파일러 과목과 마찬가지로, 운영체제 과목이나 데이터베이스 과목 역시 같은 문제를 안고 있다. p.118

18. 내 기준을 간략히 설명하겠다. 참고 문헌이 있는 경우 사용하는 편이 바람직하다. 하지만 새로운 아이디어에 참고 문헌을 요구하는 경우는 불공평하다. 불공평 할 뿐만 아니라 더 나쁘게는 독창적인 아이디어를 죽인다. p 199 // 독창적인 아이디어에 ‘참고’문헌을 요구하는 것은 ‘아이디어를 죽이는’ 일이다. 뭔가 울림이 있다.

19. 미신4. 기술적으로 우수하면서 전략적으로 중요한 혁신은 반드시 받아들여진다.

20. “흥미롭게도 그릇된 생각이다. 유용한 제품이 나오는 시기와 시장이 이를 받아들일 준비가 된 시기, 즉 타이밍이 상업적 성공이나 실패에서 가장 중요한 요소이다.” p. 209

21. 무지가 낳은 낙관주의로 인해 한쪽 응용 분야에서 두각을 나타내는 전문가가 자신이 습득한 지식이 다른 분야에도 통하리라 가정하고 주장한다. 불행하게도 이런 주장은 참이 아니다.

22. 1 SEI가 1988년에 주최한 전문가 강연에서 디지털 이큅먼트 캠브리지 연구 소장인 빅터 비소츠키는 바로 이런 생각을 주제로 삼아 소프트웨어 개발자는 소프트웨어 지식 자체만큼이나 응용 분야의 복잡성도 파악해야 한다고 말했다. 2 … “모든 응용 분야에 적합한 최상의 설계 방식은 존재하지 않으며, 이런 신기루를 쫓는 행동이 오히려 중요한 발전을 방해할지도 모른다.” 9 테스트와 검토를 비교한 바실리/셀비 논문에서 저자들은 소프트웨어에서 응용 분야가 오류 특성이나 오류 제거 특성과 관련이 있음을 찾아내었다. p.247 // 한 분야의 전문가는 다른 분야에도 전문가 일 수 있다는 편견에 대한 반박인데, 굉장히 논리적이다. 좀 깊게 고민해야 할 부분이다.