이 책은 로터스 1-2-3라는 전설적 프로젝트를 개발했던 케이퍼가 OSAF(Open Source Applications Foundation) 를 설립하고 챈들러라는 개인 정보 관리 프로젝트를 개발하며 겪은 일들을 다룬 책이다.
https://en.wikipedia.org/wiki/Chandler_(software)
챈들러 프로젝트는 순탄하기는 커녕, 두명이상의 프로젝트에서 있을 수 있는 많은 어려움을 다 겪었다.
그것도 훌륭하고 경험 있는 프로그래머들과, 풍부한 자금력을 기반으로 둔 회사에서 말이다.
작은 선택과 큰 선택 모두 최고의 결론을 내리기 위해 토의 시간이 길어졌고 프로젝트는 그만큼 지체됐다.
선행작업이 진행 되기전엔 속도가 붙지 않고, 선행 작업들에 대한 인사이트나 경험이 충분하지 못해, 빠르게 진행되지 못했다.
거기에다 업무 도구 마저 빈약하니 불만과 생산성이 급락했고, 그를 해결하기 위한 업무 도구 개발을 선행하고 만다.
프로젝트의 규모는 해야 할 일의 양에 따라 결정난다. 새로 작성해야 하거나, 결정 해야 되는 것이 많은 프로젝트가 (인원을 막론하고) 대규모 프로젝트가 될 수 있다.
첸들러 프로젝트가 겪은 문제들은 프로젝트의 규모에 상관없이 겪을 수 있는 문제를 비롯하여, 실력은 충분하다 하더라도 손발이 맞지 않는 개발자들이 모여서 작업 하는 일은 그리 쉽지 않다는 얘기를 비롯 수많은 교훈을 얻을 수 있었다.
워낙에 인상적인 구문이 많아 한 두 구문으로 정리 될 게 아니다보니, 아래에 문구들을 정리했다.
“우리가 직접 만들어서 사용합시다”란 의견이 나오면 긱들은 금새 들떠서 환호성을 지를것다 - P176
나도 그랬지.. 아니 아직도 좀 그런가?
MIT 캠퍼스에는 유명한 낙서가 있는데, “나는 프로그램만드는것보가 프로그램 작성에 도움이되는 프로그램을 더 좋아한다” - P176
내가 라이브러리 작업을 즐기고, 툴 개발을 선호하는 이유다. 나는 아직도 내 개인 작업에도 스크립팅을 비롯한 툴 작업을 좋아한다.
하지만 챈들러의 디자인이 지연됐던 또다른 이유는 디자인의 완성이란 곧 이상과 현실 사이의 고통스런 절충을 의미했기 때문이다. 최종 디자인없이 기술적 결정을 내리는 일은 힘들었고 기술 로드맵 없이 디자인을 완성하는 일 역시 어려웠다 - P185
닭이 먼저냐 달걀이 먼저냐는 어려운 문제이고, 실제로 이런 문제에서 정치로 이어지기도 해서 많은 생각이 들었다.
결과적으로 정답은 없다. 다만 빠른 프로토타이핑을 통해 우려 사항을 지워낸 쪽이 먼저 치고 나가 줘야 하는것 같다.
무엇보다도 OSAF는 앞으로 데드라인에 의한 릴리스는 하지 않을 계획이었다. 미래의 릴리스는 각각 몇 가지 기능들을 목표로 해서 모양새를 갖출 것이며 일정은 필요에 따라 변경될 (즉 늦춰질) 여지가 있었다. - P199
사실은 모든 개발 일정은 지키기 어렵다. 일정 완수에 근접하려 노력 할뿐. 그래서 버퍼가 필요하다. 사용자를 위한 일정과 내부 버퍼를 감안한 일정.
GTD(일을 깔끔하게 해치우기)의 주요 원칙 중 하나는 정기적으로 시스템에 등록된 모든 업무를 검토해서 다음에 할 일을 결정하는 것이다. p201
개발자들은 작업에 집중하려는 경향이 있기에, 주기적으로 이를 환기시켜주고, 누락된 일을 체크해야 될 필요가 있음을 말하는 것 같다.
리누스 토발즈 “자그마한 프로젝트를 시작하면서 그것이 거대해질 것이라고 기대해서도 안됩니다” 만약 그런담녀 설계에 지나치게 공을 들이게 되고 자신의 프로젝트가 실제보다 훨씬 더 중요하다고 생각하게 될 겁니다. 더 안 좋은 경우에는 스스로가 구상한 프로젝트의 규모에 겁을 먹고 포기할지도 모르죠. 그래서 작게 시작하고 구체적이고 세세한 부분을 고민하는 편이 좋습니다. 커다란 비전과 놀라운 디자인은 아예 꿈도 꾸지 말아야 합니다. 만약 당장 필요한 어떤 요구사항을 해결하지 못한다면, 분명히 설계가 지나친 걸 겁니다” - P211
“짧은 시간에 성공할 거라고 기대하지 마세요.” 그는 단호히 말했다. “저는 리눅스 개발을 13년째 하고 있습니다. 그리고 앞으로 한동안 계속 더 할 예정이고요. 만약 제가 그렇게 커다란 일을 해내려고 생각했다면, 아마 시작조차 못했을 겁니다. - P211
큰 목표보다는 작은 목표를 꾸준히 달성하는 것이 쉽다는 얘긴데, 격하게 공감한다.
좋은 관리자는 큰 일을 작게 쪼개서, 처리하기 쉽게 해준다.
챈들러 팀이 지난 일 년 동안 힘들여 개발한 진짜 데이터 저장소와 아키텍처를 가지고 더 이상 프로토타입이 아닌 실제의 인터페이스를 개발 할 수 있게 되자, 프로그래머들은 점차 개발에 욕심 내기 시작했다. 그들은 청사진과 구체적인 개발 명세서를 필요로 했다. - P218
바로 이 것이 좋은 리더와, 좋은 관리자가 필요한 이유라고 할 수 있을 것이다.
작업을 깊이 이해하고 있고 기술적인 레벨이 충분하지 않다면 청사진과 구체적 개발 명세서를 제대로 만들어 낼 수 없다.
사람들이 챈들러의 더딘 진전에 대해 회의를 표시하면, 케이퍼는 그의 올빼미 같은 눈썹을 치켜올리며 이런말을 내뱉었다. “저는 끈기를 빼면 아무것도 아니죠” - P251
실제로 케이퍼의 끈기가 아니었다면 이 프로젝트는 절대로 완수 될 수 없었다.
프로젝트에 대해 흔들리지 않는 뚝심을 보여줘야, 구성원들도 믿고 희망에 몸을 던질 수 있다.
“저는 현재 시점에서 ‘개밥 먹기’를 가능하게 만든다는 게 중요하다고 생각합니다. 가능하면 빨리 사용 가능한 소프트웨어를 내놓았으면 좋겠어요. 이를 반대하는 논리는 특정 시점에 별로 흥미롭지 않은 제품을 릴리스 하는 위험을 무릅써야 한다는 것 입니다. 하지만 ‘절반의 빵이 아무것도 없는 것보다는 낫다’고 생각합니다.” - P264
이것이 상시 빌드가 필요한 이유다. 개발 속도가 더뎌지더라도, 상시 빌드가 가능한 상태로 유지한 채로 협업 하는 것이 최종 완성도를 높게 유지하는 원동력이 되곤 한다.
그렇다고 하더라도 챈들러의 모든 기능을 구현하려면 시간이 많이 들거라고 두솔트는 대답했다. 개발 속도를 높이기 위해 할 수 있는 일은 그렇게 많지 않았다. 그리고 새 프로그래머를 너무 많이 투입한다면, 브룩스의 법칙이 작동하기 시작할 것이었다. - P265
물론이다. 개발에 속도가 안나는 이유는, 주로 문제가 복잡해졌기 때문이다.
문제를 단순하게 풀기 위한 노력은 다양하게 이뤄져야 한다.
“우리가 시도할 수 있는 한가지는,” 그녀가 제안했다. “포스트잇에 나눠 적는 거에요. 하나의 포스트잇이 대략 비슷한 작업량을 의미해야겠죠.” 포스트잇 종이 한 장에는 한 사람의 개발자가 한 달에서 두 달 정도 걸릴 작업 내용을 적어야 했다. 그들의 벽에 지금까지의 릴리스별로 포스트잇 종이를 정리할 계획이었다. 그러면 그들은 릴리스 때마다 계획한 내용과 그 계획에 현실적이었는지를 한눈에 볼 수 있을 것이다. - P274
화이트 보드 + 포스트잇! 트렐로를 통해 익숙한 스크럼 방식이다.
내 경험상 여타 업무 관리 시스템에 비해 직관적이고 쉽다.
성공적인 프로세스는 재사용될 수없다. 은총알은 재장전이 불가능하다. - P288
팀마다 문제가 미묘하게 다르거나 완전히 다르기 떄문에, 해결책은 팀마다 다를 수 밖에 없다.
TSP (Team Software Process)와 PSP (Personal Software Process)는 ‘독재적인 관리 스타일’을 지양하고 개별 프로그래머 들과 팀에게 계획, 품질 관리, 정보 공유, 그리고 업무 재분배에서 주도권을 돌려줌으로써, 자신들의 업무에 대한 통제력을 갖도록 장려하고 있다. 험프리는 한 발표에서 이를 다음과 같이 설명했다.
- 우리는 모두 회사에서 일한다.
- 회사는 일정 계획을 필요로 한다.
- 당신이 재정적으로 자유롭지 않다면, 반드시 일정을 지켜 일해야 한다.
- 당신 스스로 일정을 관리하지 않으면, 누군가 다른 사람이 당신의 일정을 관리하게 될 것이다.
- 그렇게 되면 그 사람이 당신의 업무를 통제하게 된다.
- P295
업무를 본인 스스로 관리하라는 의미다. 좋은 관리자가 필요하다는 얘기가 위에 많았지만, 사실 나도 하고 싶었던 말은 개발자 개개인도 자기 자신의 업무를 잘 관리하여 관리자와 시너지를 일으켜야 된다.
“우선 버그를 수정하시오”는 그럭저럭 그럴듯한 원칙이고, 대부분 개발자들은 적어도 이론적으로는 이에 동감을 표시할 것이다. 하지만 프로그래머의 의도가 어떻든 간에, 코드에는 항상 버그가 있기 마련이다. 소프트웨어 개발 과정에서 가장 널리 쓰이는 단어 중 하나를 차용해 설명하자면, 코드를 작성하는 과정은 ‘반복적’이기 때문이다. - P297
버그는 줄이려 노력하는 것이고, 빠르게 찾으려 노력하는 것이지 없앨 순 없다.
MS, Google, Apple, IBM 등 수 많은 기업들이 버그를 없애진 못했다.
결국 버그는 피해갈 수 없다. 개발중인 소프트웨어의 버그 목록을 훑어본다면, 심각한 버그에서부터 하찮은 것 까지 버그의 스펙트럼이 매우 넓다는 사실을 확인하게 될 것이다. 버그는 사용자를 성가시게 만드는 정도도 다르고, 버그를 발견하거나 수정하는데 드는 노력등에 있어서 커다란 편차를 보인다. 다시 말하면 모든 버그는 동등하지 않다. - P297
치명적인 버그를 미연에 방지하거나, 조기에 감지하거나, 얼마나 빨리 수정 할 수 있는가에 대한 문제다.
이를 위한 노력 비용도 동등하지 않게 하면 된다.
리스크가 큰 모듈이나 시스템 작업에 더 많은 코스트를 할당한다던지 말이다.
XP는 자칫 잘못하면 “쓰레기같은 결과물을 빨리 내놓는” 방법으로 전락 할 수 있다. - P305
XP의 방법론들은 오용의 여지가 많긴하다. 중요한 것은, 서로간의 신뢰를 잃지 않는 선에서 비효율을 제거하는 것이다.
스폴스키에 따르면, “방법론의 근본적인 문제는 방법론을 똑똑한 사람들이 만들어냈고, 이들이 사용할 때는 제대로 작동을 한다는 것입니다. 하라는 대로 지시만을 좇아가는 얼간이들이 이를 도입할 때는 제대로 작동하는 경우가 없죠. - P308
방법론은 만능약이 아니다. 실제로
37 시그널즈가 베이스 캠프 코드에서 레일스 프레임워크를 추출해낸 것 처럼, 그들은 베이스캠프를 만든 경험에서 애플리케이션 설계철학을 이끌어냈다. 이 철학은 다음과 같이 요약 될 수 있다. “더 적은 양의 소프트웨어” “새로운 기능 요구를 거절하는 것을 망설이지 마라.” “적임자를 찾아라.” “절반의 품질을 지닌 제품을 만드는 대신에, 절반의 기능을 갖추는 제품을 만들어라.” - P314
Rails가 훌륭한 소프트웨어일 수 있었던 이유라고 할 수 있다.
기능의 다양함 보다, 품질이 더 중요하다는 것을 사용자 일땐 매번 느끼지만, 개발자 일땐 종종 놓치는 것 같아 아쉽다.
마이크로소프트에 도전장을 내밀고 있는 구굴은 제이슨 프리드의 소프트웨어 개발 철학과 놀라울 정도로 비슷한 방식을 사용했다. 구글에서는 프로젝트 마다 소규모 팀을 순식간에 구성해 빠듯한 일정에 따라 업무를 진행하며, 비교적 지엽적인 문제를 해결하기 위한 웹 서비스를 내놓는다. 그러고 나서는 사용자 피드백과 서비스 운영 과정을 통해 점진적으로 서비스를 개선해 나간다. 또한 구글은 업무시간 중 20% 정도를 개인프로젝트에 사용할 것을 장려한다. 이런 ‘20% 시간’의 성과는 멋지고 새로운 서비스로 발전할지도 모른다. (아니어도 상관없고). “걱정하지 마세요” 구글은 직원들에게 이렇게 말한다. “그저 당신이 하고 싶었던 일을 해보세요!” - P315
서비스는 점진적 개선이 매우 중요하다. 한번에 다수의 사용자를 만족 시키는 것은 어려우며, 간단한 기능을 심플하게 제공 한 후, 피드백과 운영 과정에서 개선해나가는 것이 좋다는 것에 크게 공강한다.
리스프와 객체지향 전문가이자 썬 사의 “뛰어난 공학자”인 리처드 가브리엘은 주장한다. “저는 프로그래머들도 시인, 예술가처럼 창의적인 활동을 하는 사람들을 양성하는 방식으로 양성해야 한다고 생각합니다. 사람들은 이게 엉뚱한 소리라고 말할지도 모릅니다. 하지만 시문학 석사학위를 받으려고 교육받을 때 사람들은 무엇을 하나요? 그들은 위대한 시들을 공부합니다. 소프트웨어 공학에서 그렇게 하나요? 아니요, 우리는 위대한 소프트웨어의 소스코드를 읽지 않습니다. 위대한 소프트웨어의 설계를 공부하지도 않죠. 그 디자인을 보지도 않고요. 위대한 소프트웨어 디자이너들의 인생을 공부 하지도 않습니다. 즉 우리는 우리가 만들려는 것의 기존 문헌들을 공부하지 않습니다.” - P358
우리는 개발 경험을 공부하지 않는다. 선배들이 실패한 경험을 복기하고, 피해간다면 조금이라도 덜 실패할 수 있지 않을까?
결과적으로 기대한 것 이상을 얻어갈 수 있었던 책이다.
비슷한 문제를 겪고 있을 때 한번쯤 떠올려볼 조언 같은 느낌이었다.
이런 책 들을 통해 선배들로 부터 이런 조언들을 하나 둘 더 듣고 배우다보면, 확률 높은 성공적인 소프트웨어 개발에 대한 나름의 결론을 얻게 되지 않을까 기대해본다.