검색 중 2009년 작성한 도서 리뷰(드리밍 인 코드)를 발견했다. 십년을 넘게 유지해오던 블로그를 호스팅 업체에서 날려먹으면서 허탈해진 기억이 난다. 그나마 여기저기 인터넷에 남아 있는 내 기록의 파편들을 발견해서 약간은 위안이 된다.

이제 그 파편이라도 여기 다시 뿌려 본다.

드리밍 인 코드(Dreaming in code) – 막장이 되는 이유

2009.03.31.

지난 달에 구입해서 정말 재미있게 본 책입니다. 저자인 스콧 로젠버그는 컬럼니스트이지만 아마추어 개발자로 챈들러 프로젝트에 몸을 담고 그 프로젝트의 3년간을 기술합니다. 챈들러 프로젝트는 미치 케이퍼, 알랜 케이등 전설급의 프로그래머들이 OSAF로 구성되어 진행되었지만 책에 기록된 3년은 그야말로 막장으로 보입니다. 챈들러는 현재 1.0.2가 릴리즈되어 있고 http://chandlerproject.org/ 에서 확인할 수 있습니다.

전설급 프로그래머들이 모여있고, 무한에 가까운 자금이 있으면서, 딱 정해진 일정도 없이(완전이 일정이 없는 것은 아니지만 SI 프로젝트와 같이 살을 죄는 듯한 일정은 아니니까..) 자유스러운 분위기의 프로젝트가 왜 막장이 되어가는지도 섬세히 기록되어 있습니다.

놀라운 것은 필자가 프로 개발자가 아닌데도 풍부한 지식으로 이야기를 풀어나가고 개발방법론, 프로그램 역사 등을 세세히 알려주는데, 그 깊이에 감탄했습니다.

흔히들 SI 프로젝트 하면 막장이라고 표현되는데요, 챈들러가 막장이 되어 가는 과정이나 이유가 막장 SI 프로젝트와 유사한 점들이 발견됩니다. SI 프로젝트 하면 갑을병정의 발주처-원청-하청-하청의 하청 구조와, 말도 안되는 일정, 끊임없이 실시간으로 바뀌어나가는 요구사항, 지쳐 떨어지는 개발자와 다시 충원되는 개발자, 연결고리가 약한 여러 하청의 조직 등등 많은 이유가 있습니다.

챈들러와 SI 프로젝트와의 공통점은 잦은 변경입니다. 설계부터 흔들리는 요구사항 변경은 프로젝트를 막장으로 만드는데 1등공신이죠. 물론 SI와 챈들러 사이의 요구사항 변경 이유야 절실히 다르지만요. 챈들러는 미치 케이퍼의 아젠다라는 비전이 있지만 SI야 고객 기분에 따라, 고객 직책에 따라 요구사항이 바뀌는 거니까요. 그렇지만 요구사항이 바뀌는 근본적인 이유가 무엇인지 이 책을 보면서 스스로 깨닭았습니다. 그건 “개발해야할 대상이 무엇인지 모른다.”였습니다.

챈들러는 아젠다의 비전에 따라 이전까지 없던 프로그램이었기 때문에 고민하고 연구했겠지만 SI프로젝트는 두리뭉실한 목적하에 고객도 모르고 개발자도 모르는 정체불명의 시스템을 만들어야 한다는 겁니다. 하긴 대개의 프로젝트는 이미 있던 업무(손으로 하든 엑셀로 하든)를 전산 시스템으로 구현하는 거라 완전히 모른다고는 할 수 없지요. 또 비슷비슷한 프로젝트를 진행한 개발자도 있을 것이며 경험많은 PM등 제대로 분석할 수 있는 경우도 있습니다. 그러면 뭐합니까.. 고객이 모르는데요. 이 빌어먹을 고객이라는 인종은 현재 자신들이 하고 있는 업무 조차 헷갈려한다는게 문제지요.

예를 들면 요전에 제가 재고수불관리시스템 프로젝트를 진행했는데요, 재고수불이라는 게 생산한 제품들의 모든 이력은 그때그때 남기고 그 총 합이 현재고와 딱 맞는다는 간단한 원리로부터 시작됩니다. 시스템 구현이 어느정도 끝나가고 있을 시점, 그러니까 테스트 버전을 고객이 볼 수 있는 시점부터 진정한 막장이 시작되었습니다. 사용자는 데이터를 삭제했다 살렸다 하는 업무를 반복할 수 있는데 그 데이터는 무의미하다고 기록하지 말라는 겁니다. 모든 이력을 남기는 것이 저 수불이라는 것인데 기록하지 말라니요. 물론 처음에는 고객이 동의했고 이해했다고 생각했는데, 제가 잠시 착각한 거였습니다. 고객은 아무것도 모르고 있었습니다. 아아.. 무식이 죄지만.. 그 무식이 사람 여럿 잡았지요. 문제는 그 잘못된 생각(비단 저 하나의 예시 뿐 아니라 꽤나 많은 끔찍한 요구들을 포함하여)이 설득도 되지 않고 절대 꺾이지도 않는다는 점입니다. 결국 시스템의 품질은 개판이 되는 거죠. 더욱이 더 큰 문제는 고객이라는 인종이 전문가인 해당 프로젝트의 개발자들(PM을 포함하여)의 말을 인정하지 않는다는 것입니다. 그들의 그때그때 바뀌는 생각이 항상 옳으며 그대로 따라야 제대로 된다는 것이죠. 프로젝트가 어느 정도 막바지에 이르게 되면 프로젝트를 진행했던 각 팀원들이 열심히 본업에 충실했다면 현업만큼 또는 사람에 따라서 현업보다 훨씬 업무를 잘 이해하고 진행할 수 있지만, 고객이라는 인종은 이 정도는 고사하고 개발자를 전문가로 인정하는 생각이 뇌속에서 제거된 상태입니다. 

챈들러 프로젝트를 진행했던 구성원들은 이상을 고수하며 현실을 위해 투쟁하는 모습이 책에 잘 그려져 있습니다. 그들은 그들 나름대로 깨우친 것들이 있었겠지요. 로젠버그는 그것을 “소프트웨어를 개발하는 것이 가장 어렵다.”라고 말한 TAOCP의 도널드 커누스 교수의 말을 인용하여 표현해 놓았습니다. 그리고 결정적으로 사람들은(프로그래머를 포함하여) 소프트웨어가 무엇인지 모른다고 말합니다. 그래서 해야 할 것들이 많다는 것이죠.

책을 덮고 나서, 잘 알기 어려운 이 소프트웨어라는 것을 제대로 현실로 이끌어낼 사람은 프로그래머밖에 없다는 생각이 들었습니다. 제겐 너무나 다행이고, 저를 흥분시키게 하네요. 비록 지금은 썩 쓸모있지도 않아 보이는 것들을 만들고 있지만, 일할 때 프로그래밍하는 것 보단 업무 이외로 하는게 점점 더 증가하고 있으니까요.

미래를 만드는 것을 제 손으로 올리고 하나씩 만들어 나가는 중이고 앞으로도 계속 하다보면 정말 좋은 미래가 올 것 같은 예감이 듭니다.

P.S 전 책 표지가 꽤 멋지다고 생각되서 편집 디자인을 하는 아내에게 보여줬더니 반응이 시큰둥하네요. 광고쪽에서는 저런 디자인이 별로 안먹히나 봅니다.