이전 블로그에서 이전 함 (원본 글 2013/10/26 작성)
|
|
드리밍 인 코드 :
천국과 지옥을 넘나드는 소프트웨어 개발 이야기
스콧 로젠버그 저/황대산 역 | 에이콘출판사
|
"Software is Hard."
책의 첫 챕터에서 나오는 글이고
이 문구가 책의 결론이자 모든 S/W 개발 프로젝트의 결론인것 같다.
S/W 개발을 주업으로하는 입장에서 상당히 공감가는 글이고 국내, 해외, 개발자의 역량을 떠나서 S/W 프로젝트의 여러 시행 착오와 어려움을 엿볼 수 있는 책이다. 저자가 3자의 입장에서 프로젝트를 관찰하고 집필한 책이므로 객관적인 입장에서 볼 수 있어 좋은 것 같고 또한 S/W 프로젝트에서 manager, architecture, engineers, tester외에도 librarian이 별도로 있으면 좋겠다는 생각도 들기도 한다.
책의 내용은 OSAF (Open Source Application Foundation)에서의 Open Source PIMS application인 챈들러를 개발하는 과정을 기록한 내용이다. 하지만 저자가 챈들러 프로젝트의 끝까지 참여하지 못해 베타테스팅 까지만 기록 되어 있다.
책에서 보던 중 공감하는 일부를 개인적인 생각과 정리하여 나중에 보려고 함.
P.23
"소프트웨어는 골칫덩이다. ... 우리는 더 나은 소프트웨어를 꿈꾼다. 소프트웨어 프로젝트 관리 분야의 창시자라고 할 수 있는 프레데렉 P. 브룩스는 1987년 '은총알은 없다 No Silver Bullet'란 유명한 에세이에서 다음과 같은 말을 했다. "컴퓨터 프로그램을 개발하는 작업은 정말 어렵지만, 이를 한순간에 획기적으로 개선하는 방법은 영어 나타나지 않을 것입니다. 그저 수수한 정도의 점진적이고 꾸준한 진전만이 가능할 것입니다."
=> No Silver Bullet. 뭐든지 한번에 모든 것을 해결하는 것은 없다고 생각한다 더구나 보이지 않는 실체를 만들어야 하는 S/W 개발에서는 더더욱..
(TODO) 다시 읽어보기
P.31
소프트웨어 시간에 관한 최초의, 그리고 가장 명쾌한 설명은 1975년에 프레데릭 브룩스가 쓴 "맨먼스 미신 The Mythical Man-Month"에서 찾아볼 수 있다. ... 개발 과정은 수많은 일정 지연과 비용 초과로 얼룩져 있었다. ... 브룩스의 팀은 일정 지연에 당황해서 마치 전투 인원을 증파하듯이 추가 개발자를 계속 투입했다. 하지만 놀랍게도 이렇게 투입된 인력은 프로젝트가 당면한 문제를 해결하기는 커녕 더 많은 문제들을 만들어낼 분이었다.
=> 추가로 투입되는 인력은 프로젝트에 대한 이해와 개발환경 설정등의 비용이 발생하여 오히려 개발에 방해가 된다. 하지만 일정 지연으로 답답한 관리자 입장에서는 달콤한 방법이 아닐 수 없을 듯... 책은 다소 오래된 내용이고 따분하다.
P.39
성당과 시장
=> 사실 읽어보지는 않았으나 상당히 언급되는 책
(TODO) 읽어보기
P.70
이 장르의 최대 역작은 로버트 브리처의 "The Limits of Software"이다. ... 소프트웨어 프로젝트 역사상 최악의 실패로 손꼽히는 미 연방 항공국의 '진보된 자동화 시스템 AAS, Advanced Automation System" 프로젝트의 개발자 중 한 명이었다.
=> AAS는 S/W 개발 위기를 언급할 때 언제나 나오는 단골 프로젝트이다..
(TODO) 관련 논문 찾아보기
P.82
프레데릭 브룩스는 새로운 기술이나 설계를 도입할는 어떤 프로젝트에서도 "첫 번째 버전은 과감히 내다버릴 계획을 세워야 한다"고 충고했다. 첫번째에 마음에 쏙 드는 물건을 만드는 건 불가능에 가깝기 때문이다.
=> 보통 prototyping의 산출물로 나오는 prototype은 Throw-away prototype으로 생각하는게 맞다. 하지만 처음 결과물을 기반으로 개선해서 가는 형태의 Evolutionary prototyping가 더 reasonable하다고 생각할지 모르지만 나중에 뜯어고치는 비용도 만만치 않다.
P.113
파이썬과 조프 개발자들이 이미 만들어 놓은 것을 무시하고 새로 개발하는 일은 없었으면 좋겠습니다. 파이선과 조프는 이미 수년의 개발 과정을 거쳐왔으며, 이들 툴박스 안에는 훌륭한 기술이 보물처럼 잔뜩 숨어 있습니다.
P.119
원래 사용되는 질문은 "자체적으로 개발할 것인가, 상용 제품을 사다가 쓸 것인가, 기존 것을 빌려다 쓸 것인가?"이다. 하지만 기술적인 관점에서 '사서 쓰는 것'과 '빌려 쓰는 것'은 크게 다르지 않다. 이는 단지 상용 솔루션을 사용할 것인가, 오픈소스 솔루션을 쓸 것인가의 차이일 뿐이다.)
=> 새로운 solution을 사용할 때는 신중해야 한다. 개발 기간이 짧은 경우 당연히 숨겨진 버그나 부족한 feature로 고생을 하게 되고 개발 기간이 길더라도 유지보수가 제대로 되지 않는 경우 전자와 마찬가지라고 생각한다.
P.125
종종 소프트웨어 개발자들은 '자사에서 직접 개발하지 않은 소프트웨어 사용을 거부하는' NIH Not Invented Here 신드롬에 시달리기도 한다.
=> 사실 좀 어려운 이슈다. 개발자라면 자기가 직접 만들기를 원할 것이고 가져다 쓸때는 비용과 시간을 절약하기 위해서 일 것이다. 상황에 따라서 다르겠지만 만약 직접 개발해서 적용하는 제품이 오랜시간동안 사용되어 유지보수 기간이 길어진다면 직접 개발하는 것도 괜찮다고 개인적으로 생각하고 가져다 쓸 경우 해당 소프트웨어가 2-3번의 상품화를 통해 검증 되었다면 가져다 써도 상관없을 것이라 생각되고...
P.159
소프트웨어 프로젝트를 관리하는 일에 있어 커다란 아이러니는 프로그래머들이 작업하는 대상이 한치 오차도 없는 완벽한 정확성으로 작동함에도 불구하고, 소프트웨어 개발 과정을 측정하는 일은 놀라울 정도로 어렵다는 점이다. ... 개발자의 업무량을 가장 계량적으로 측정하려면 코드의 줄수를 세면 된다. 하지만 이는 불충분할 뿐만아니라 지독할 정도로 오해의 여지가 많은 지표다.
허츠펠드는 매킨토시 개발 역사에 관해 쓴 "Revolution in the Valley, 실리콘 밸리의 혁명"에서 이렇게 말한다. "앳킨슨은 가능한 한 적은 양의 코드 줄 수를 평가의 척도로 사용하는 것은 불필요하게 긴 엉터리 코드를 작성하도록 장려하는 일이라고 생각했죠".
=> 앳킨슨의 의견에 절대 공감이다. 하지만 S/W 개발 경험이 있는 관리자도 자주 이런 방법을 사용한다는게 현실이다.
P.162
어쩌면 문제의 근원은 관리 테크닉에 있는 것이 아니라, 소프트웨어 개발을 하는 사람들의 기질에 있는 것이 아닐까 하는 두려움이다. ... 프로그래머들과 커뮤니케이션하는 것은 놀라울 정도로 어렵다 ... 그들은 천재 괴짜이며 문제아다.
=> 일반적인 S/W Engineer가 아닌 geek, guru 같은 애들을 말하는 것이라고 생각한다. 기존 논문을 봤을 때는 생각보다 MBTI 결과에서 외향적인 성격을 가진 S/W engineer가 꽤 있었고 실제 S/W 개발에서는 외향적인 사람들이 더 좋은 역할을 보여줬던 것으로 기억한다.
(TODO) 관련 논문확인 필요
P.189
"모질라의 결과물은 우리보다 훨씬 앞서 있습니다. 이들 중 일부를 활용하면 우리의 개발 속도를 획기적으로 높이게 될 겁니다."
=> 앞에서 말한 것 처럼 상황에 따라서 다르겠지만 상품화 단계의 프로젝트에서는 단지 앞서 개발된 결과물이라고 완성되지 않은 것을 그냥 가져다 쓰면 검증에 문제가 될 가능성이 크다고 생각한다.
(TODO) 모질라 재단 open source 프로젝트 확인하기
P.245
2003년 11월 마이클 토이가 더난 후로 케이퍼는 비전을 제시하는 역할 뿐만 아니라 디자인과 개발에 있어 실질적인 관리자 역할을 맡고 있었다. ... 업무의 범주가 넓어져만 갔다. ... 케이퍼가 참석해야 할 미팅의 수는 늘어났고 이들 미팅에서 그가 눈에 띄게 힘들어하는 모습도 쉽게 눈에 띄었다.
=> 개인적인 생각으로 프로젝트에서 관리자가 관리할 수 있는 팀원의 수는 7-8명이 적절한 것 같다. 사람이 많아지면 많아 질 수록 관리의 역할, 업무가 늘어나고 의사소통의 비용이 늘어나서 오히려 역효과를 내는 것 같다.
P.253
"개밥 먹기는 ... 서버 릴리스 시 마지막 몇개의 버그를 잡기 위해 내부적으로 상당히 적극적으로 수행하는 활동입니다. 제품 개발 초기 단계에서 부터 품질을 높이는 데 있어 큰 동기를 부여해 준다는 사실을 깨달았습니다."
=> 비록 모든 기능을 구현하여 문제를 발견하지 않도록 테스트 한다는 게 단점이긴 하지만 제품 개발에 열정을 가진 사람들이 이런 역할에 적절할 것 같다. 즉 자발적 동기를 가진 사람들.. 윗선으로 부터 타 부서에서 개발한 제품을 대상으로 베타테스팅을 하는 경우가 있는데 대부분 배타적이다.
P.270
"우리 관리자들이 종종 빠지곤 하는 함정은," ... "엔지니어들은 일을 마쳤다고 하는데 아파나와 디자인팀은 어리둥절해하는 상황입니다." 다르게 말하면, 기능은 동작할지도 모른다. 하지만 수많은 버그가 있고 인터페이스에는 디자인이 입혀져 있지도 않고, 아직도 산더미 같이 할일이 남아 있는 것이다.
=> 반성한다..ㅜㅜ 시작이 반이고 기능구현이 반이니.. 보통 기능 구현하면 끝이라고 생각한다. ㅜㅜ
P.302
2001년 워드 커닝햄과 켄트 벡 등 이 분야의 리더 17명이 유타주의 스키 리조트에 모여 일련의 연관성을 띠지만 저마다 다른 접근 방식에서 공통점을 찾으려 했다. ... 이 회합에서 사람들은 좀더 그럴듯한 이름을 만들어냈다. '애자일 소프트웨어 개발 방법론.' 그리고 다음과 같은 선언문도 발표했다.
=> 애자일 개발 방법론은 찾아봤지만 관련 역사는 몰랐었는데.. 애자일 관련 책을 읽어봐야 겠음.
(TODO) 애자일 관련 기본 개론, 역사 책 찾아보기
P.332
만약 당신이 프로그래머에게 버그를 보고한다면, 당신이 들을 첫마디는 이 말일 것이다. "그 문제가 반복해서 나타나나요?" .... 만약 그렇지 않다면 아마도 프로그래머는 어깨를 으쓱하면서 그 문제를 하드웨어 문제나 아니면 우주 광선 때문에 일어난 일 정도로 치부해 버릴지도 모른다.
=> 역시나 반성한다.. 난 이것 보다 더해서 확인하기 전에 먼저 화를 낸다 ㅜㅜ
P.368
2004년에는 마이크로소프트 윈도우 2000의 소스코드 일부가 인터넷을 통해 유출된 적이 있다. ... 매우 놀라웠던 것은 마이크로소프트의 프로그래머들이 소스코드에서 그들 자신과 그들의 도구, 그들의 동료, 그들이 개발한 제품을 심하게 꾸짖었다는 것이다
=> 재밋겟다. 나중에 나도 해봐야지 ㅎㅎㅎ
(TODO) 해보기
P.394
소프트웨어 개발에 있어 수많은 문제와 마찬가지로 챈들러의 반복되는 일정을 어떻게 처리할 것이냐는 문제는 '나누고, 정복하고, 미룬다 divide, conquer and punt'라는 방법으로 해결될 수 있음이 드러났다.
=> 스크럼 방법론을 쓰면서 정말 잘 와닫고 공감하는 것 중 하나이다. 다만 회사에서는 일정과 산출물을 정해두고 한다는게 함정.. ㅜㅜ
