-
-
드리밍 인 코드 - 천국과 지옥을 넘나드는 소프트웨어 개발 이야기 ㅣ AcornLoft
스콧 로젠버그 지음, 황대산 옮김 / 에이콘출판 / 2009년 1월
평점 : 
절판
재밌다. 얻을 게 엄청 많을 진 모르겠지만 실패한 프로젝트가 어떤 식으로 실패했는지 디테일하게 알 수 있는 것은 좋은 일이다. 분명 써먹을 데가 있을 것이다. 내가 하고 있는 일이 챈들러 팀의 일과 겹쳐 보인다면 빨간불이 들어온 게 아닌지 살펴 볼 테니 말이다.
아래는 밑줄.
드리밍 인 코드
Author : 스콧 로젠버그
Publisher : 에이콘출판
Format : 449 pages
ISBN : 8960770701 9788960770706
Hr
우리의 문명은 소프트웨어 위에서 발전하고 있다. 하지만 소프트웨어를 만드는 과정은 전문가들에게조차도 여전히 연금술처럼 느껴진다. 누구도 이처럼 자신 없어 하는 기술에 인류 전체가 이토록 폭넓게 의존한 적은 역사상 단 한 번도 없었다. 우리가 소프트웨어에 점점 더 의존해가는 속도와 프로그래머들이 소프트웨어 개발에 능숙해지는 속도 간에는 걱정스러울 만큼 커다란 격차가 존재한다. 우리의 의존도는 기하급수적으로 커지고 있지만, 소프트웨어를 다루는 노하우와 또 그것을 적용하려는 의지는 그저 터벅터벅 발전하고 있을 뿐이다.
P.22
브룩스에 따르면 소프트웨어 개발자들은 대체로 낙관적이어서 버그가 금세 고쳐질 수 있고 종국에는 모든 문제가 해결될 거라고 믿는다. 이렇듯 낙관적이고, 성미가 급한 관리자의 기대에 부응하려는 개발자들의 순응적인 성격은 프로젝트 초기부터 일정을 왜곡하기 마련이다. 브룩스는 코드 작성은 전체 개발 업무의 단지 1/6 정도만 차지할 뿐이며, 오히려 테스트와 버그 수정 등이 전체 업무 시간의 절반 이상을 차지한다는 사실을 발견했다. 하지만 실제로 프로젝트를 이러한 가정 하에 계획하는 관리자는 찾아보기 힘들다.
P.32
토발즈의 성과에서 브룩스의 법칙[소프트웨어 개발이 지연되는 것을 막기 위해 더 많은 사람을 투입하면 개발이 더 지연된다는 법칙 - 형우]에서 해방될 수 있는 가능성을 처음으로 발견한 사람은 바로 레이몬드였다. 오픈소스 환경에서는 프로젝트를 수렁으로 빠뜨리지 않고도 많은 개발자들의 기술을 활용하는 일이 가능했다. 레이몬드는 이를 위해서 두 가지 조건이 선행돼야 한다는 사실을 발견했다. 바로 인터넷처럼 저비용으로 누구나 쉽게 접근할 수 있는 네트워크와 저장 공간이 있어 개발자들이 빠르고 안정적으로 커뮤니케이션할 수 있어야 하고, 토발즈처럼 효과적인 리더십을 발휘하는 사람이 있어야 한다는 점이었다. 이런 방식이 성공하기 위해서는 새 멤버를 환영하고, 참여자들의 기여를 장려하고, 재능있는 참여자들을 이끌어 들이는 리더십이 필요했다.
P.40
30여 년 전 프레데릭 브룩스는 이런 말을 했다. “소프트웨어 개발에 있어 가장 어려운 일을 개발 그 자체가 아니라, 무엇을 개발할지를 결정하는 일이다.” OSAF[Open Software Assocation Foundation - 형우]는 브룩스의 말이 여전히 유효하다는 사실을 입증하고 있었다.
P.47
하지만 직접 만지고 느낄 수 있는 물리적 세상과 혼란스러울 정도로 동떨어져 있을 뿐만 아니라 ‘디지털’의 기본 장점인 유연성과 다목적성조차도 갖추지 못한 소프트웨어를 접하는 일은 어렵지 않다. “당신의 음악을 장르별로 관리하고 싶다고요? 아무 문제 없습니다. 다만 프로그램에 이미 등록되어 있는 장르 외에 새로운 장르를 추가할 수 있을 거라고는 꿈도 꾸지 마세요.” ...
이런 일이 벌어지는 까닭은 프로그래머들이 사용자를 제약하고 싶어서라기보다는, 프로그래머 역시 자기들이 사용하는 도구나 개발 환경의 제약을 받고 있기 때문일 것이다. ... 소프트웨어는 때때로 엉뚱할 정도로 완고해서 그 경직성은 늘상 우리를 놀래키곤 한다.
... 소프트웨어의 근간을 이루는 기본 결정사항들은 손쉽게 느껴지고 가역적으로 보일지 모르지만, 곧 관성의 힘을 바아 콘크리트를 부어 만든 것처럼 딱딱해져 버린다.
P.78 ~ 79
프레데릭 브룩스는 다음과 같이 말했다. “프로그래머들은 시인처럼 순수하게 그리고 관념적으로 일한다. 또한 상상의 나래를 펼쳐서 공중에 자신의 성을 쌓는다. 소프트웨어만큼이나 유연하고 손쉽게 다듬어 재작업할 수 있으며 웅대한 개념적 구조물을 구혀하게 해 주는 매개물은 없을 것이다.”
P.85 ~ 86
컴퓨터가 더 많은 일을 해야 할지 아니면 프로그래머가 더 많은 이을 해야 할지를 결정해야 한다면 답은 간단하다.
소프트웨어에는 무어의 법칙이 적용되지 않기 때문이다. 컴퓨터는 성능이 매년 두 배로 발전하지만 인간의 두뇌는 그렇지 못하다.
P.91
옵션이 너무 다양하기 때문에 소프트웨어 프로젝트에서 특정 프로그래밍 언어를 선택한 이유를 논리적으로 설명하는 일은 무척 어렵다. 많은 경우, 프로그래머의 취향이나 경험, 직관 등이 결정의 주요 요소로 작용한다. 프로그래머이자 칼럼니스트인 폴 그레이엄은 많은 개발자가 파이썬을 선호하는 이유는 단지 코드가 보이는 방식 때문이지만, 그것이 그렇게 불합리한 기준은 아니라고 설명한다. “프로그래머들은 코드를 작성하는 일보다는 코드를 읽는 일에 더 많은 시간을 보낸다. 프로그래머들은 마치 조각가가 점토 덩어리를 다듬듯이 코드 덩어리를 다듬어 코드를 작성한다. 따라서 소스코드가 지저분해 보이는 프로그래밍 언어는 마치 굳어서 갈라진 점토 덩어리가 조각가를 화나게 하듯이 정확성을 중시하는 프로그래머를 짜증나게 만들기 마련이다.”
P.102
지금은 고인이 된 비즈니스 철학가 피터 드러커(Peter Druker)는 다음과 같은 말을 한 적이 있다. “관리란 사람에 관한 것이다. 관리의 주 목적은 여럿이 함께 일하면서도 성과를 낼 수 있게 하는 것이며, 각 사람의 장점을 발휘하게 하고, 그들이 지난 단점이 중요하지 않게 만드는 것이다.”
P.158
소프트웨어 프로젝트를 관리하는 일에 있어 커다란 아이러니는 프로그래머들이 작업하는 대상이 한치 오차도 없는 완벽한 정확성으로 작동함에도 불구하고, 소프트웨어 개발 과정을 측정하는 일은 놀라울 정도로 어렵다는 점이다. 프로그래밍 관리자들은 수십 년째 소프트웨어 분야에 적합한 생산성의 척도를 만들기 위해 노력해 왔다. ... 한 줄의 코드에는 어떤 표준 척도도 적용될 수 없다. 코드의 양과 프로그램의 완성도, 성능, 사용자가 실제로 느끼는 가치에는 신뢰할 수 있는 어떤 상관관계도 존재하지 않는다.
P.158 ~ 159
험프리는 다음과 같이 이야기했다. “제조업이나 군대, 그리고 기존의 하드웨어 개발에서 관리자는 공장이나 전장, 연구소를 돌아다니면서 다들 어떤 일들을 하고 있는지를 관찰할 수 있다. 만약 누군가가 무엇인가를 잘못하고 있거나 생산성이 떨어진다면, 관리자는 몇 분만 관찰해도 이를 알아챌 수 있다. 하지만 소프트웨어 개발팀에서는 그저 관찰한다고 해서 개발자들이 무엇을 하고 있는지를 알아낼 방법이 없다. 프로그래머들에게 직접 물어보거나 그들의 산출물을 조심스럽게 조사해야만 한다. 소프트웨어 개발자가 무엇을 하고 있는지를 파악하기 위해서는 상당히 기민하고 전문지식이 풍부한 관리자가 필요하다. 만약 관리자인 당신이 개발자들에게 다른 일을 하라고 시키거나 새로운 방법론을 도입할 것을 명령한다고 해도, 정말 그들이 당신 말을 따르고 있는지를 파악할 손쉬운 방법은 없다.”
P.162
그[케이퍼 - 형우]는 이렇게 선언했다. “디자인을 구현하는 과정에서 새로운 내용이 발견될 것이다. 이로 인해 초기 디자인은 계속 변경되기 마련이다. 만약 디자인과 구현이 너무 강하게 얽혀 있다면 결과는 실패로 돌아가기 쉽다. 자연스러운 개선과 변화의 프로세스가 힘들어지기 때문이다.”
P.184 ~ 185
이 책을 읽고 있는 당신이 소프트웨어 개발자라며, 아마 이쯤에서 이런 말을 외치며 이 책을 벽에 던져버렸을 지도 모르겠다. “이런 미친 짓은 이제 그만 두라고! 이미 교과서에 나와 있는 모든 실수를 저지르고 있어!”
...
만약 당신이 자신은 분명히 더 잘 할 수 있다고 확신하는 프로그래머 중 한 명이라면 지난 번 프로젝트에서 이런 생각을 한 적이 몇 번이었는지 자문해 보기 바란다. “맞아요, 나는 우리가 아마도 이것을 해야만 한다는 사실을 압니다.” (여기에서 ‘이것’은 소프트웨어 업계에서 잘 알려진 소프트웨어 개발과관련한 기본 원친 중 어떤 것일 수도 있다.) “하지만 지금은 특수한 상황입니다. 우리는 아주 특별한 경우입니다.” 앤디 허츠펠드는 이렇게 말하곤 했다. “통상적인 프로젝트란 없습니다. 모든 프로젝트에는 저마다 고유한 특성이 있지요.”
P.210 ~ 211
2004년 6월, ‘리눅스 타임스’는 리눅스 개발의 리더인 리누스 토발즈와 인터뷰를 했다.
“대규모 오픈소스 프로젝트를 시작하려는 이들을 위해 충고를 한 마디 해 주실 수 있나요?” 기자가 물었다.
“누구도 대규모 프로젝트를 섣불리 시작하면 안 됩니다.” 토발즈는 단언했다. “자그마한 프로젝트를 시작하면서 그것이 거대해질 거라고 기대해서도 안 됩니다. 만약 그런다면 설계에 지나치게 공을 들이게 되고 자신의 프로젝트가 실제보다 훨씬 더 중요하다고 생각하게 될 겁니다. 더 안 좋은 경우에는 스스로가 구상한 프로젝트의 규모에 겁을 먹고 포기할지도 모르죠. 그래서 작게 시작하고 구체적이고 세세한 부분을 고민하는 편이 좋스비다. 커다란 비전과 놀라운 디자인은 아예 꿈도 꾸지 말아야 합니다. 만약 당장 필요한 어떤 요구사항을 해결하지 못한다면, 분명히 설계가 지나친 걸 겁니다.”
...
하지만 설혹 당신이 토발즈의 충고를 들었다 하더라도, 그래서 작게 시작하고, 꿈이 너무 커지지 않도록 조심하고, 구체적인 부분을 늘상 고민하고, 그리고 커다란 비전에 대해서는 생각하지 않았다 하더라도, 토발즈는 빠른 성공을 꾀하면 안 된다고 말했다.
“짧은 시간에 성공할 거라고 기대하지 마세요.” 그는 단호히 말했다. “저는 리눅스 개발을 13년째 하고 있습니다. 그리고 앞으로 한동안 계속 더 할 예정이고요. 만약 제가 그렇게 커다란 일을 해내려고 생각했다면, 아마 시작조차 하지 못했을 겁니다.”
P.211
추상적인 개념을 혼동없이 커뮤니케이션하는 것은(프로그래머로부터 컴퓨터에게, 프로그래머로부터게다른 프로그래머에게, 프로그램으로부터 사용자에게) 소프트웨어 개발에 있어 가장 어려운 일이다. 프로그래머와 비프로그래머들 사이에 바벨탑의 재앙을 피하려면 어떻게 해야 할까?
P.239 ~ 240
프로그래머들은 새로운 문제를 해결하는 데 있어 언제나 자신이 늘 품어오던 열의와 전문성을 활용하게 된다. 최악의 경우 이것은 ‘망치를 들고 있는 사람에게 모든 것이 못으로 보이는’ 부적절한 짝짓기가 될 수 있다. 최선의 경우에는 물론 해당 분야 전문가 덕분에 난해한 문제가 너무도 손쉽게 해결돼 버린다.
P.259
누구도 케이퍼가 리더십의 가장 고통스러운 역할을 수행하는 것을 비난할 수 없었다. 실패를 깨끗이 인정하는 일. 하지만 케이퍼는 스스로 사기를 꺾거나 조직을 동요시키지 않으면서 실패를 받아들이는 방법을 알고 있었다. 그는 포스트잇 미팅에서의 나쁜 소식을 기꺼이 받아들였다. 케이퍼는 직원들을 위해 거기에 미사여구를 덧씌우지 않았다. 어차피 그들은 어서픈 에둘러 말하기가 통하기에는 너무 똑똑한 사람들이었다. 하지만 그는 그것을 일종의 현실적 낙관주의로 제시했다. 그런 케이퍼의 모습에서는 20년 전에 작은 로터스 사를 성공적인 거인으로 만들어냈던 뭔가를 엿볼 수 있었다.
P.279
프로그래머들이 오랜 기간에 걸쳐 이어지는 단일 프로젝트에서 함께 일하는 경우는 드물다. 이런 면에서 그들은 스포츠팀이나 군부대, 음악 합창단 등과는 다르며, 영화 한 편을 만들려고 헤쳐모여를 반복하는 영화 제작자들과 더 흡사하다. 따라서 개별 프로그래머들과 관리자들은 과거 경험을 통해 경력과 노하우는 쌓았을지언정, 그들이 새로운 팀과 함께 신규 프로젝트를 시작하게 되면 전혀 새로운 프로세스가 필요해진다.
P.287
수백만 명의 사용자가 사용할 제품(패키지 소프트웨어)을 만드는 데 적용되는 프로세스가 어떤 회사에서 내부적으로만 사용될 기업용 소프트웨어를 개발하는 데 적합할 리가 없다. 특정 정부 조직 전체가 사용할 프로그램을 개발하는 일에는 전문 소프트웨어(예를 들어 오디오 음악 처리 프로그램) 개발과는 전혀 다른 프로세스가 요국될 것이다. PC용 소프트웨어는 휴대폰이나 임베디드 전자제품(자동차나 보안 시스템에서 사용되는 시스템)용 소프트웨어와는 성격이 전혀 다르다. 성공적인 프로세스는 재사용될 수 없다. 은총알은 재장전이 불가능하다.
P.288
소프트웨어 산업에서 프로젝트 성공률이 60년대와 70년대 동안 계속해서 고전을 면치 못하자, 소프트웨어 개발 방법론 옹호자들은 좀더 사람에 관심을 두기 시작했다. 특히 프로젝트의 규모가 클수록 실패율이 높아지는 현상이 뚜렷해지자, 사람들은 프로세스를 개선하는 일에 집중하기 시작했다. 시간이 지나면서, 그들은 상반되는 주장을 펼치는 두 캠프로 나뉘게 된다. 마치 참여자들끼리 사이가 나빠진 오픈소스 프로젝트처럼 그들은 반대 방향으로 나아가기 시작했다.
한 캠프는 이렇게 주장했다. “좋은 계획을 만든다는 건 너무도 어렵다. 우리는 더 열심히, 더 오래, 좀더 세부적으로, 그리고 반복해서 계획해야만 한다. 더는 계획할 수 없는 단계까지 계획해야 한다. 그러고 나서도 더 많은 시간을 계획에 쏟아야 한다.” 반대편 캠프는 이렇게 말했다. “계획이란 세우기도 쉽지 않고 실제로 세워놓은 계획도 거의 항상 별 쓸모가 없으므로, 그냥 계획하는 것을 포기하는 편이 낫다. 그냥 흐르는 대로 개발하는 것이 현명하다! 코드를 작성하고, 피드백을 받고, 고객들과 함께 작업하고, 개발하면서 항상 계획을 변경해라. 이것이 신뢰할 수 있는 유일한 방법이다.” 조금 과장된 설명이긴 하지만, 이러한 분화는 뚜렷해서 대부분 프로그래머나 관리자는 자연스럽게 또는 쓰라린 경험으로 인해 두 캠프 중 하나를 선호하게 된다.
프로젝트 관리 저눈가인 와츠 험프리는 “무조건 계획하시오. 더 많이!”라는 방법론을 설파했다. “계획을 세우고 업무를 관리하지 않으면 프로그래머들의 작업은 예측 불가능해집니다. 게다가 프로그래밍 업무의 비용과 일정을 예측할 수 없다면, 전체 프로젝트도 예측 불가능해집니다. 간단히 말해 개별 개발자들이 자신의 업무를 계획하고 관리하지 않으면, 프로젝트 또한 제어와 관리가 불가능해질 것입니다.”
반면에 현대 경영학의 대부인 피터 드러커는 이렇게 말했다. “지식 노동자의 업무에 대한 대부분 논의는 개인 업무를 계획하는 것에서 시작된다. 이는 너무도 자연스러운 현상이지만, 문제는 이런 계획이 잘 작동하는 경우가 거의 없다는 점이다. 계획은 언제나ㅏ 종이에만 남아 있고 좋은 의도에서 끝날 뿐이다. 계획이 성과로 이어지는 경우는 실제로 거의 없다.”
P.299 ~ 300
“‘소프트웨어 공학’이란 사기에 가깝습니다.” 전설적인 제록스 팔로 알토 리서치 세터에서 7~80년대에 근무했던 소프트웨어 베테랑인 L. 피터 도이치는 이렇게 말했다. “물리학이 정립되기 전에 제대로 된 공학을 한다는 것은 어불성설이지요. 소프트웨어에는 물리학 비슷한 것조차 아직 없습니다.”
P.332
공학일까, 문학일까? 과학일까, 예술일까? 프로그래밍의 이중 정체성 문제를 해결하려는 노력은 이 분야 전문가들이 수십 년째 고민해온 문제지만, 여전히 우리는 나토(NATO)가 가르미슈에 전문가들을 소집해 소프트웨어 위기를 해결하려 시도했을 때보다 별로 발전한 것이 없어 보인다. 어쩌면 이 문제는 해결 가능한 것이 아닐지도 모른다. 그게 아니면 이것은 문제라기보다는 프로그래밍이라는 활동이 지니는 고유한 특성일지도 모른다.
P.361
도널드 커누스는 프로그래밍 분야에서 우리가 주목할 만한 또 하나의 업적을 남겼다. 비록 알고리듬에 관하 비교적 난해한 업적으로 가장 잘 알려졌지만, 그는 ‘Literate Programming’ 개념의 옹호자이기도 하다. Literate Programming은 조엘 스폴스키가 말했듯이 “코드를 작성하는 것보다는 읽기가 더 어렵다”는 고통스러운 문제를 해결하기 위해 고안됐다. ...
> 컴퓨터에 명령을 내리는 일이 아니라 다른 사람에게 우리가 컴퓨터에게 무엇을 시킬 것인지를 설명하는 일이 우리의 주업무라고 가정해 보자. Literate Programming을 실천하는 사람들은 작가라고 부르는 것이 맞다. 그들의 주 관심사는 설명과 뛰어난 문체다. 그런 작가는 변수의 이름을 정하는 데 신중을 기할 것이며, 각 변수의 이름이 무엇을 의미하는지를 설명할 것이다. 이렇게 작성된 코드는 필연적으로 이해하기 쉬울 것이다. 프로그램을 구성하는 세부 요소들이 인간의 이해에 최적화되어 설계됐기 때문이다.
P.367
1999년에 앨런 쿠퍼(90년대 초에 비주얼 베이식을 만들었고 지금은 저명한 소프트웨어 디자인 옹호자)는 《정신병원을 뛰쳐나온 디자인 The Inmates Are Running the Asylum》이란 독특한 책을 출판했다. 이 책은 소프트웨어 업계의 죄목을 정리해놓은 전과 기록이다. 이 책에서 쿠퍼는 “소프트웨어 개발에는 한 가지 중요한 요소가 빠져 있다. 이는 ‘완료’됐다는 것이 정확히 무엇을 의미하는지에 대한 이해다.”
P.400
“우리는 계속해서 인프라와 디자인에 지나친 투자를 해왔습니다. 이와 같은 투자는 차기 또는 차차기 개발 사이클에서도 결실을 맺지 못할 것입니다. 즉 앞으로 6개월에서 12개월 동안은 힘들 겁니다. 이로 인해 우리는 신속성에서 많은 대가를 치렀습니다. 제가 뭔가를 조언할 수 있다면, 지난 2년 동안 해온 일을 좀더 많이 하라고 조언할 겁니다. 즉, 혁신을 이어가고, 실행해나가고, 목표를 조금 낮추라고 조언할 것 같습니다. 차기 연도에 달성해야 할 목표에 꼭 필요한 경우가 아니라면 CPIA 같은 인프라에 투자하지 말라고 할 것 같습니다. 저는 장기적인 비전을 유지하면서 가능한 한 민첩한 개발을 하는 것이 중요하다고 생각하게 됐습니다. 솔직히 처음에는 그 중요성을 깨닫지 못했죠.”
P.406
실망스런 일정 지연 등으로 인해 그가 챈들러 프로젝트 취소를 고려한 적이 있었을까? “아뇨, 끔찍할 정도로 낙담에 빠졌던 적은 있었습니다. 하지만 인생에서(단지 여기서만이 아니라) 희망이 사라졌다는 매우 강한 느낌이 든다면 그저 당분간 참고 견뎌야 한다는 사실을 배웠습니다. 뭔가 액션을 취하는 것을 자제해야만 합니다. 이런 감정은 일시적일 뿐이기 때문이죠. 이런 감정은 모두 상황이 만들 따름입니다. 그 대신, 한 시간이든 몇 시간이든, 아니면 하루 이틀이라도 그냥 쉬는 편이 좋습니다. 그리고 이 정도가 제가 전반적인 시야를 다시 회복하는 데 필요했던 시간입니다. 저는 매번 돌아와서 우리가 장기적인 비전을 달성할 방법을 찾을 수 있다고 말을 했죠.”
P.406 ~ 407
OSAF 프로그래머들이 코드 타워를 세우느라 애쓰는 동안, 베이브릿지의 동쪽 편 다리도 새롭게 건축되고 있었다. 매일 자동차 수십만 대가 지나다니는 4.5마일 길이의 2층 교량 절반을 신축하는 이 프로젝트는 1990년대에 시작되면서 10억 달러의 예산이 편성됐었다. 원래는 평범한 포장도로로 만들어질 계획이었지만, 정치적 이햬관계와 지역주의 등이 개입되면서 나중에는 좀더 도전적이고 멋진 서계가 도입되기에 이른다. 새 ‘서스펜션 브릿지’는 중앙의 타워와 교량의 양끝이 이어지는 아름다운 모습으로 설계됐다. 한 다발의 강철 케이블이 타워에서 도로 아래까지 늘어져 거대한 고리들의 우아한 정렬을 이룬 뒤 다시 타워 꼭대기로 이어질 것이었다. 전체의 모습이 각 부분에서 재귀적으로 바복되는 이 디자인은 아마 더글라스 호프스태터도 마음에 들어했을 것이다.
그런데 문제가 하나 있었다. 이러한 설계는 과거에 시도된 적이 단 한 번도 없었다. 게다가 여기에 도전하고 싶어하는 이들도 많지 않았다. 캘리포니아 주의 입찰 공고에 참여한 회사는 한 곳뿐이었으며, 그마저도 캘리포니아주가 채겅한 예산을 훨씬 상회하는 비용을 제시했다.
2004년 12월 캘리포니아 주지사인 아놀드 슈왈제네거는 이 프로젝트를 잠시 보류시키고, 베이 지역이 프로젝트 비용을 좀더 많이 부담할 것을 요구했다. 그리고 이미 건설이 상당 부분 진행돼서 매일 아침 차들이 임시 진입로를 통해 떼 지어 교량으로 진입하고 있었음에도 불구하고, 교량 설계 변경을 제안했따. 슈왈제네거는 프로젝트의 규모를 줄이고 좀더 경제적인 설계로 바꾸기를 원했다. 주지사와 주의회, 주교통위원회가 논쟁을 벌이고 절충을 이뤄내는 데만 몇 달리 소요됐다. 교통위원회는 일정 지연으로 인해 매일 40만 달러의 추가 비용이 발생하고 있다고 불평했다. 마침내 2005년 7월, 원래의 단일 타워 디자인을 고수하되 통행료 징수 등의 방법으로 건설 비용을 메운다는 최종안이 나왔으며, 공사 완료 일정은 2012년으로 공시됐다. 지진으로 인해 원래 교량이 훼손된 지 무려 23년이 지나서야 새 교량이 완성되는 것이었다!
이 논쟁에 관한 이야기를 들으면서, 나는 토목 공학의 정밀한 프로세스와 오랫동안 검증된 표준모델을 모범 삼아 각종 소프트웨어 관리 매뉴얼을 만들던 일화를 떠올리지 않을 수 없었다. “소프트웨어 개발에는 좀더 체계적인 프로세스가 필요합니다.” 그들은 주장하곤 했다. “절반쯤 건설된 교량의 설계를 중간에 바꾸려는 사람은 없습니다!”
캘리포니아주는 그러한 주장이 엉터리였음을 증명해 보였다.
P.411 ~ 412
왜 우리는 교량을 건설하듯이 소프트웨어를 개발할 수 없는 걸까? 물론 나는 캘리포니아주의 교량 건설 방식을 이야기하는 것은 아니다. 이러한 질문을 하는 사람들은 신뢰할 만한 원칙에 기반을 둔 엄밀한 프로세스를 떠올린다. 하지만 물리적 세계를 지배하는 각종 운동 법칙들에 비견할 만한 ‘소프트웨어 물리학’이 발견되기 이전에는 불가능한 일일지도 모른다. 그래도 소프트웨어 개발의 기술적인 난해함은 조금씩이나마 개선됐다. 토목 공사 분야에서도 유사한 과정이 있었다. 오늘날 우리는 건설 분야에서 우리의 통제력을 당연하게 받아들인다. 하지만 많은 이들은 19세기와 20세기 초까지 신기술 도입 과정에서나 경험 미숙 등으로 인해 실패로 끝나거나 붕괴 사고 등을 초래했던 토목 공사의 역사를 망각하고 있다. 그 당시의 재앙들은 여러 면에서 오늘날 소프트웨어 개발에서 발생하는 재앙들을 압도한다.
P.412 ~ 413
Hr
Published from iReadItNow