알파 버전을 공개합니다. 공개하겠습니다. 요리사들도 훌륭하고, 모든 재료가 완벽한데도 절대 식사 시간까지 완성되지 않는 신기한 요리. "아니 한참 소고기를 썰고 있는데, 드리밍 인 코드는 챈들러라는 아웃룩 킬러(...를 노리는) 프로젝트가 진행되면서 발생한 여러가지 이슈들을 나름 시간 순으로 나열한, 연대기 같은 느낌의 책입니다. |
|
개발과 디버깅 작업 끝없는 유지보수 작업에 지친 소프트웨어 개발 6년차. 어떻게 하면 깔끔한 프로그램을 만들수 있을까, 했던 작업을 중복하지 않고 발전된 프로그램을 만들수 없을까, 여러 사용자들의 요구나 불만을 분산하지 않고 한가지 깔끔한 방법으로 해결을 할수 없을까 등의 수많은 고민으로 책을 고르고 있던 중에 드리밍 인 코드란 책을 만나게 되었다.
제목부터 딱 시선을 끌었는데 꿈, 이상, 이런것들을 어떻게 풀어나갔을까 궁금해 하면서 책장을 넘겼다. 처음부터 심상치 않았다. 큰 프로젝트들의 일정지연 일화들로 이야기를 풀어나간다. 저 깊숙한 곳으로부터 공감해 가면서 어떻게 하면 이런것들을 해결할 수 있을지 이책은 과연 해결책을 어떻게 제시를 할지 궁금해 하면서 책에 푹 빠져버렸다. 어느정도 읽고 나서야 주 소재는 챈들러라는 오픈소스 프로젝트를 취재하는 형식으로 이야기가 진행되고 있다는 것을 알았다. 그만큼 소프트웨어 전반적인 역사와 유명한 프로젝트 일화, 유명한 개발자들의 속사정까지 아주 방대한 양의 정보를 책에 담고 있었다.
이미 많은 사람들이 칭찬을 했지만 저자의 깔끔한 이야기 전개는 내가 그 프로젝트의 일부가 된것처럼 같이 고민을 하고 어려움에 처하면 같이 답답하게 만들었다. 그렇게 생각하면서 읽다보니 1권의 책을 읽는데 몇년이 걸린것 같은 느낌이 든다. 2001년부터 시작된 프로젝트가 2008년 드디어 1.0 버전을 만드는데 까지 같이 참여를 한 듯하고 중간중간 많은 정보로 인해 여러권의 책을 읽은 듯한 기분이 든다. 또한 훌륭한 개발자들의 개발하는 모습을 눈앞에서 본것처럼 선하고 그들의 삶이 불완전하긴 하지만 내가 생각했던 개발자의 모습과 비슷하여 (한국개발자와 다른) 그들의 삶과 사상이 동경의 대상이 되기까지 한다. 돈에 연연하지 않고 만들고 싶은 프로그램을 만드는데 희열을 느끼며 집중적인 개발과정이 끝나면 가족과 함께 1달여의 여행을 다녀온다. (이게 한국에서는 과연 가능한 일인지!)
이런 저런 생각이 많았지만 책을 덮는 순간 느꼈다. 오픈소스에 더 관심을 가지고 정말 훌륭한 프로그램을 만들어 보자! 그들도 못이뤘지만 소프트웨어의 미래가 밝아지는 그날까지 열심히 해 보자! 라고... |
|
프로그램을 어떻게 만들 것인가에 대한 논의를 지켜보면, 많은 경우, 서로의 반대편에 서서 한 치의 양보도 없는 주장을 펼치고 있는 형국이 만들어지는 것을 발견하게 된다. 게다가 조금이라도 더 구체적인 각론으로 들어가면 영원한 친구도 영원한 적도 없다는 걸 바로 느낄 수 있게 된다.
기본적으로는 모든 측면에서 나와 전적으로 동의하는 사람은 있을 수 없다. 만약 그런 사람이 내 주위에 있다면, 그가 무엇인가 놓치고 있던가, 내가 뭔가 오해하고 있는 경우다. 그런 측면에서, 프로그램을 만든다는 것은 수천년 동안 분화되어 온 개인이나 집단 차원의 종교 생활과 방불하게 느껴진다.
[드리밍 인 코드]는 이러한 상황에 대해 한 번쯤 차분하게 살펴볼 기회를 제시해준다. 물론 저자의 개인적인 의견이 언듯언듯 나타날 수밖에 없지만, 이 정도의 티는 '아마추어 개발자'라는 변명으로 쉽게 넘어갈 수 있다.
저자가 가장 강조하고 있는 것과 같이, 소프트웨어는 어렵다. 정확하게 말하자면, 소프트웨어를 만든다는 것이 정말 어렵다. 어느 하나 사람이 관련되지 않은 것이 없기 때문이다. 그 복잡한 사람이 모여, 더 복잡한 사람을 위해, 그나마 덜 복잡한 기계에게 시킬 일을 계획하는 것. 이러한 일에 대한 지난 50년의 고민과 주장을 이 책의 "노트" 부분에서 차근차근 찾아보면서, 소프트웨어가 99%의 '삶'과 1%의 '로직'으로 되어 있다고 느끼게 되는 것이 나만의 경험만은 아닐 것이라 감히 확신해본다.
|
|
전설급 프로그래머들이 모여있고, 무한에 가까운 자금이 있으면서, 딱 정해진 일정도 없이(완전이 일정이 없는 것은 아니지만 SI 프로젝트와 같이 살을 죄는 듯한 일정은 아니니까..) 자유스러운 분위기의 프로젝트가 왜 막장이 되어가는지도 섬세히 기록되어 있습니다. 놀라운 것은 필자가 프로 개발자가 아닌데도 풍부한 지식으로 이야기를 풀어나가고 개발방법론, 프로그램 역사 등을 세세히 알려주는데, 그 깊이에 감탄했습니다. 흔히들 SI 프로젝트 하면 막장이라고 표현되는데요, 챈들러가 막장이 되어 가는 과정이나 이유가 막장 SI 프로젝트와 유사한 점들이 발견됩니다. SI 프로젝트 하면 갑을병정의 발주처-원청-하청-하청의 하청 구조와, 말도 안되는 일정, 끊임없이 실시간으로 바뀌어나가는 요구사항, 지쳐 떨어지는 개발자와 다시 충원되는 개발자, 연결고리가 약한 여러 하청의 조직 등등 많은 이유가 있습니다. 챈들러와 SI 프로젝트와의 공통점은 잦은 변경입니다. 설계부터 흔들리는 요구사항 변경은 프로젝트를 막장으로 만드는데 1등공신이죠. 물론 SI와 챈들러 사이의 요구사항 변경 이유야 절실히 다르지만요. 챈들러는 미치 케이퍼의 아젠다라는 비전이 있지만 SI야 고객 기분에 따라, 고객 직책에 따라 요구사항이 바뀌는 거니까요. 그렇지만 요구사항이 바뀌는 근본적인 이유가 무엇인지 이 책을 보면서 스스로 깨닭았습니다. 그건 “개발해야할 대상이 무엇인지 모른다.”였습니다. 챈들러는 아젠다의 비전에 따라 이전까지 없던 프로그램이었기 때문에 고민하고 연구했겠지만 SI프로젝트는 두리뭉실한 목적하에 고객도 모르고 개발자도 모르는 정체불명의 시스템을 만들어야 한다는 겁니다. 하긴 대개의 프로젝트는 이미 있던 업무(손으로 하든 엑셀로 하든)를 전산 시스템으로 구현하는 거라 완전히 모른다고는 할 수 없지요. 또 비슷비슷한 프로젝트를 진행한 개발자도 있을 것이며 경험많은 PM등 제대로 분석할 수 있는 경우도 있습니다. 그러면 뭐합니까.. 고객이 모르는데요. 이 빌어먹을 고객이라는 인종은 현재 자신들이 하고 있는 업무 조차 헷갈려한다는게 문제지요. 예를 들면 요전에 제가 재고수불관리시스템 프로젝트를 진행했는데요, 재고수불이라는 게 생산한 제품들의 모든 이력은 그때그때 남기고 그 총 합이 현재고와 딱 맞는다는 간단한 원리로부터 시작됩니다. 시스템 구현이 어느정도 끝나가고 있을 시점, 그러니까 테스트 버전을 고객이 볼 수 있는 시점부터 진정한 막장이 시작되었습니다. 사용자는 데이터를 삭제했다 살렸다 하는 업무를 반복할 수 있는데 그 데이터는 무의미하다고 기록하지 말라는 겁니다. 모든 이력을 남기는 것이 저 수불이라는 것인데 기록하지 말라니요. 물론 처음에는 고객이 동의했고 이해했다고 생각했는데, 제가 잠시 착각한 거였습니다. 고객은 아무것도 모르고 있었습니다. 아아.. 무식이 죄지만.. 그 무식이 사람 여럿 잡았지요. 문제는 그 잘못된 생각(비단 저 하나의 예시 뿐 아니라 꽤나 많은 끔찍한 요구들을 포함하여)이 설득도 되지 않고 절대 꺾이지도 않는다는 점입니다. 결국 시스템의 품질은 개판이 되는 거죠. 더욱이 더 큰 문제는 고객이라는 인종이 전문가인 해당 프로젝트의 개발자들(PM을 포함하여)의 말을 인정하지 않는다는 것입니다. 그들의 그때그때 바뀌는 생각이 항상 옳으며 그대로 따라야 제대로 된다는 것이죠. 프로젝트가 어느 정도 막바지에 이르게 되면 프로젝트를 진행했던 각 팀원들이 열심히 본업에 충실했다면 현업만큼 또는 사람에 따라서 현업보다 훨씬 업무를 잘 이해하고 진행할 수 있지만, 고객이라는 인종은 이 정도는 고사하고 개발자를 전문가로 인정하는 생각이 뇌속에서 제거된 상태입니다. 챈들러 프로젝트를 진행했던 구성원들은 이상을 고수하며 현실을 위해 투쟁하는 모습이 책에 잘 그려져 있습니다. 그들은 그들 나름대로 깨우친 것들이 있었겠지요. 로젠버그는 그것을 “소프트웨어를 개발하는 것이 가장 어렵다.”라고 말한 TAOCP의 도널드 커누스 교수의 말을 인용하여 표현해 놓았습니다. 그리고 결정적으로 사람들은(프로그래머를 포함하여) 소프트웨어가 무엇인지 모른다고 말합니다. 그래서 해야 할 것들이 많다는 것이죠. 책을 덮고 나서, 잘 알기 어려운 이 소프트웨어라는 것을 제대로 현실로 이끌어낼 사람은 프로그래머밖에 없다는 생각이 들었습니다. 제겐 너무나 다행이고, 저를 흥분시키게 하네요. 비록 지금은 썩 쓸모있지도 않아 보이는 것들을 만들고 있지만, 일할 때 프로그래밍하는 것 보단 업무 이외로 하는게 점점 더 증가하고 있으니까요. 미래를 만드는 것을 제 손으로 올리고 하나씩 만들어 나가는 중이고 앞으로도 계속 하다보면 정말 좋은 미래가 올 것 같은 예감이 듭니다.
P.S 전 책 표지가 꽤 멋지다고 생각되서 편집 디자인을 하는 아내에게 보여줬더니 반응이 시큰둥하네요. 광고쪽에서는 저런 디자인이 별로 안먹히나 봅니다. |
|
이 책은 차라리 소설처럼 구성했다면 참 좋지 않았을까 싶다.
400 페이지가 넘는 조금은 두꺼운 책인데
책의 구성은 프로젝트를 진행해가면서 부딪히게 되는 개발자들간의 갈등 및 해결 등의 여러 진행과정을 얘기하다가 중간에 저자가 다른 사람들의 말을 인용하다가 프로젝트에 대한 이론적인 부분을 이야기하다
이러한 내용들이 뒤죽박죽이 되어 사실 책에 빠져들기가 힘들었다.
하나의 프로젝트을 진행해 가면서 겪는 여러가지 내용들이 참 흥미로운데 반해
개인적으로는 흥미있게 읽다가 중간 중간에 흐름이 끊겨 빠져들기가 힘든 책이었다.
임백준 님의 뉴욕의 프로그래머와 비슷한 책인데 내가 읽기엔 조금은 지루한 감이 있었다.
내용이 간결하게 구성이 되었다면 좀더 좋지 않았을까 하는 아쉬움이 있다. |
|
SW 개발에 대한 에세이를 읽는 것은 참 즐거운 일이다. 또 이 책은 전문 작가가 쓴 책이라서 그런지 유머가 있고, 전체적인 이야기를 잘 풀어나간다.
하지만 이 책의 단점이 있다. 개발하기로 한 프로젝트는 늦어지고 일정이 보이지 않는다. 또 개발 책임자인 Project Manager는 프로젝트를 떠난다. 개발은 앞으로 2년이 지나도 끝나지 않는다. 이런 상황에서 책을 쓴 작가마저도 중간에 떠나 버린다. 아마 작가가 떠나고 난 이후의 수습 과정과 버전 1.0을 결정하는 것이 하이라이트일 것인데, 정장 이 책은 앞 부분의 50% 부분까지밖에 안 보여준다. 또 하나 SW가 망하는 것 중에 하나가 사람들가의 관계에 있어 갈등하고 반목하게 되는 것이다. 저자가 아주 깊숙이 들어가지 않았거나 의도적으로 그런 부분을 뺀 것으로 보인다.
챈들러 프로젝트는 성공한 프로젝트일까. 잘 모르고 비난하는 것일 수 있어 조심스럽지만 자유로운 일정과 넉넉한 자금으로 인해, 긴장감이 사라져보인다. 어쩌면 그래서 일정 지연이 생겼을 수도 있다고 생각한다.
그래서 이 책은 챈들러 프로젝트의 이야기라기 보다는 그냥 일반적인 소프트웨어 개발 이야기이다. 과거 소프트웨어가 어떤 식으로 발전해 왔으며, 또 개발은 어떤 식으로 진행되고 있으며, 다른 회사들은 어떻게 진행하고 있는 가의 일반적인 내용을 보여 주고 있다. 이런면에서 이 책은 재미있고 좋은 책이다.
책 내용 중간에 유명한 소프트웨어 인물들은 모두 언급되고 있다. 튜닝부터 시작하여 거의 대부분의 사람들이 나온다. 그들이 한 말이 인용되는 것만 보아도 이 책은 가치가 있다.
이 책에서 마이크로소프트와 구글이 성공하는 이유가 있고,피터 드러커의 인용을 보면서 피터 드러커의 책을 봐야겠다고 생각했다. 그리고 챈들러 홈페이지를 구경하였고, 팀에서 Mimi 등의 이 책에서 많이 나오는 멤버를 확인할 수 있었다.
|