The note of Legendre

프로젝트가 나타내는 86가지의 행동/양상을 자주 반복되는 패턴으로 나누어 설명한 책입니다.

학생들: 등록금 인상은 불가능합니다.

-> 총학생회: 등록금 인상은 무리입니다

-> 등록금책정위원장: 등록금 인상은 어렵습니다만..

-> 총장: 등록금 인상 충분히 가능합니다.

"더 쉽고 재미있게 소프트웨어를 개발하는 방법"을 부제로 단 Head First Software Development를 monaca님의 애자일 3종 강탈 1탄 이벤트를 통해 읽게 되었습니다. 1장에서는 훌륭한 소프트웨어 개발에 앞서서 훌륭한 소프트웨어 개발의 정의를 짚고 갑니다. 요구사항을 주어진 시간과 비용으로 제공하는 것인데요. 그 비밀을 이터레이션이라고 소개하고 있습니다. 이터레이션을 통해 프로젝트의 방향이 고객이 원하는 목표와 맞는지 자주 점검하는 일이죠. 이터레이션의 규모를 추정하는 부분은 불확실성과 화해하는 프로젝트 추정과 계획과 유사했습니다. 딱딱해질 수도 있는 주제를 그림과 화살표로 시각적으로 표현해서 더 쉽게 다가왔습니다. 요구사항 수집 부분은 사용자 스토리를 연상하게 하는 인덱스카드와 시작했는데요. 책에서 개발자 역할을 맡은 희와 혁의 짤막한 대화가 등장합니다. 책 안에 개발자와 고객에 사진과 이름을 붙여서 중간에 제시하니깐, 내가 그 스토리에 참여하는 것처럼 몰입이 잘 되는 효과를 가져온다고 봅니다. 거만한 자세의 고객에 말풍선을 붙여 말을 넣어 두니깐, 독자의 처지에서 괜히 서늘하더라고요. 읽다가 180쪽에 "이번 장의 훼방꾼이 나타났어요" 부분 때문에 깜짝 놀랐습니다. 헤드퍼스트의 파격적인 구성 때문에 소프트웨어 개발 도서임에도, 이런 반전이 갑작스레 등장할 수 있다고 생각합니다.

객체 지향 방법론인 단일 책임 원칙(SRP)나 DRY 원칙을 통해 리팩터링도 다루고, 버전 관리를 돕는 도구인 서브버전의 필요한 사용법도 소개합니다. 빌드 자동화를 위한 빌드 도구인 Ant를 소개했는데, Ant로 빌드 스크립트를 잘 짜두면 컴파일 명령을 입력하면서 실수하는 일도 줄어들고, 빌드할 때마다 편하리라 느껴졌습니다. 블랙 박스 테스트나 화이트 박스 테스트의 이름은 얼핏 들어본 적은 있지만 무얼 뜻하는지 정확히 모르고 있었는데, 테스트를 바라보는 시선도 다르고 집중하는 분야도 다르다는 걸 알게 되었습니다. 테스트 주도 개발 규칙을 설명하고 테스트로 나온 버그는 "버그 트래커"로 관리하라고 이야기합니다.  재사용 소스 코드가 등장하면서 개발자 집단은 엉망인 상황에 부닥치지만, 차근차근 순서대로 문제를 풀어나가는 개발자 집단이 흥미로웠습니다.

테스트 주도 개발, 사용자 스토리, 빌드 자동화, 버전 관리, 디자인 패턴, 리팩터링, 추정과 계획 등 소프트웨어 개발 전반을 골고루 요약해서 다루고 있다는 점이 이 책의 강점이라고 봅니다. 각 주제를 깊이 익힐 시간은 부족하고 이런 개념들에 익숙해져야 할 때 도움이 되리라 생각합니다. 책의 이야기가 자바 언어로만 씌어 있어서 다른 언어의 관점도 소개하면 좋겠지만, 소프트웨어 개발과 관련된 책이라 다른 언어 사용자에도 적용하는 데 무리가 없으리라 예상합니다.

HEAD FIRST SOFTWARE DEVELOPMENT 카테고리 컴퓨터/IT 지은이 댄 필로네 (한빛미디어, 2008년) 상세보기

죽음의 행진이라는 책을 읽었습니다. 부제는 문제 프로젝트에서 살아남는 법입니다. 비정상적인 프로젝트에 대한 이야기를 다루고 있다는 점에서, 이 책은 현실적으로 다가왔습니다. 문제 프로젝트를 처음부터 맡지 않는 게 가장 좋은 대안이겠지만, 문제 프로젝트에 어쩔 도리 없이 참여하게 될 경우 어떤 조치가 도움이 되는지 여러 장에 걸쳐 소개합니다. 우선순위 결정이나, 일을 중요도와 긴급도를 통해 4가지 영역으로 구분하는 일은 일상생활에서 사용하기도 유용한 전략이라고 생각합니다. 기술적인 문제가 아니라 다른 정치, 사회적 문제가 문제 프로젝트에 위기를 가져온다는 이야기를 읽으면서, 문제의 중심은 사람이며 팀의 동기 부여 여부나 사기가 프로젝트에 중요하다는데 공감했습니다.

죽음의 행진(문제 프로젝트에서 살아남는 법) 카테고리 경제/경영 지은이 에드워드 요든 (소동, 2005년) 상세보기

Agile Software Development with Scrum의 번역서이다. 팀의 생산성을 극대화시키는 애자일 방법론이 책의 부제이다. "극대화시키는" 보다 "극대화하는"이라는 표현을 썼으면 더 낫지 않을까 하는 생각이 든다. 익스트림 프로그래밍처럼 애자일 소프트웨어 기법에 속하는 스크럼은 단순하고 효과적인 원칙과 기법을 소개하여 프로젝트에 활력을 불어 넣는다고 나왔다. 스크럼에서는 반복주기를 스프린트(sprint)라는 용어로 표현했다. 스프린트는 사전적으로 전력 질주를 뜻한다. 전력 질주를 연습하려면, 보통 두 명 이상이 목표 지점을 정해 두고 경쟁하면서 달린다. 순간적으로 온몸의 능력을 다 끌어내야만, 시간을 단축하게 된다. 스프린트라는 말이 선택된 이유가 전력 질주를 되풀이함으로써 팀의 체력을 키운다는 의미가 아닐까 추측한다.

스크럼 카테고리 컴퓨터/인터넷 지은이 켄 슈와버 (인사이트, 2008년) 상세보기

Agile Estimating and Planning의 번역서로, "규모 추정, 우선순위, 일정 배치"가 책의 부제이다. 이 책의 저자인 마이크 콘은 사용자 스토리의 저자이다. 책에서는 사용자 스토리의 내용을 이어받아 인덱스 카드를 사용하고, 이터레이션 가운데 할 일에 스토리 점수를 매기는 과정들이 묘사된다. 기억에 남는 네용은 일정 버퍼를 소개한 내용인데, 실생활에서 어떤 지점에 어느 시간까지 가야할 때 여유 시간을 배치하는 일과 비슷하다고 생각했다. 즉, 지하철을 타면 기다리는 시간 20분, 버스를 갈아타면 기다리는 시간 15분을 목적지까지 도달하는데 얼마나 걸릴까 예측할 때 고려하는 일과 유사했다. 책의 42쪽 2번째 줄에 나오는 '~에 다름 아니다'는 '~에 불과하다, 또는 ~일 뿐이다.'로 표현했으면 더 우리말다운 표현이 되겠다.

불확실성과 화해하는 프로젝트 추정과 계획 카테고리 컴퓨터/인터넷 지은이 마이크 콘 (인사이트, 2008년) 상세보기

쉽고 재미있게 읽을 수 있었다. 책의 절반은 갓 팀장이 된 나팀장이라는 인물을 중심으로, 소설 형식으로 되어있는데, 비록 소설이지만 프로젝트 관리자의 심정, 상황을 엿볼 수 있어서 좋았다. 현실에서 구루 같은 멘토가 있으면 정말 좋겠다는 생각도 들었다. 많이 회자되고 있는 애자일, XP 등의 방법론 소개도 인상적이었다. 인지부조화를 이용해 긍정적인 기여를 유도하는 법도 기억에 남았다. 요구사항은 변하기 마련이라고 가정하는 게 프로젝트 완수에 도움이 된다고 생각한다. 마음에 든다.

소설로 배우는 프르젝트를 다루는 책 중에 '데드라인'이라는 책도 기억난다.

Agile Retrospectives: Making Good Teams Great의 번역서 애자일 회고: 최고의 팀을 만드는 애자일 기법이 출간되었습니다. 이 책은 애자일 시리즈의 5번째 책인데요. 애자일 방법론에서 말하는 '회고'를 하는 방법과 회고를 통해, 개인과 팀을 개선하는 방향으로 나아가는 길을 제시합니다.

되짚어보니 학교 중에서도 '회고'하는 프로세스가 포함되어 있습니다. 예컨대 도플러 효과에 관한 실험을 수행했는데, 그에 대한 결과보고서를 쓰도록 요구받는데요. 만약 보고서를 쓰지 않았다면, "정말 좋은 실험이었다."로 끝나게 되겠죠. 하지만 보고서를 쓰면서, 실험 과정을 한번 더 떠올려 보고, 어떤 원리 때문에 이런 결과가 나왔는지, 일치하지 않는다면 그 오차의 원인은 무엇인지 고민하게 됩니다. '중간고사'와 '기말고사'도 그냥 수업시간으로 끝날 수 있었던 과목을 스스로 정리하고 생각해 볼 기회를 준다는 점이 긍정적이죠. 나중에 과목 내용이 더 기억에 남고요.

어떤 회의에서 회고를 도입하자고 했을 때, 어려웠던 점이 생각납니다. 회고 중에 물론 잘했던 점에 칭찬도 이루어지지만, 못했던 점을 반성하는 과정이 포함됩니다. 그래서 회고는 남을 '비판'하려는 과정이 아니라 '팀'을 개선하는 길임을 납득시키는 일이 쉽지 않았는데요. 이 책에서 소개된 다양한 활동은, 보드게임처럼 즐겁고 흥미진진하게 회고를 진행하는데 도움이 될 것이라고 보았습니다. 회고를 통해 개인과 팀의 성취가 날마다 더 나아지는 경험을 겪고 싶으시다면 읽어보시길 추천합니다.

아키텍트 이야기를 읽고 있습니다. 처음에는 딱딱하고 어려운 책 아닌가 생각했었는데, 설명 중간에 줄거리가 되는 이야기가 있어서 책을 읽을 때 흥미를 꾸준히 느낄 수 있도록 합니다. 책에서는, 아키텍트란 소프트웨어 개발과 관계되어, 기술적 결정을 하는 최고 책임자라고 정의합니다. 프로그래머의 정년은 다른 직업보다 짧게 이야기되곤 하는데요, 이 책에서는 그에 대한 대안으로 아키텍트라는 역할을 제시합니다. 줄거리가 되는 이야기의 등장인물들은 이니셜을 가지고 등장하는데요. C라는 인물이 아키텍트로서 마주하는 상황들이 재미있으면서도 현실적으로 느껴졌습니다. 이는 저자가 다양한 시스템을 개발한 경험을 가지고 있는 데에서 기인한 듯합니다.

한국에서도 아키텍트라는 직업은 이제 낯선 이름이 아니게 된 듯합니다. 네이버 카페 아키텍트를 꿈꾸는 사람들에서는 스터디와 캠프 등 활발한 활동을 펼치고 있습니다. 문제를 풀기 위해 기술을 판단한다는 점에서 아키텍트란 직업은 매력이 있습니다. 다만, 훌륭한 아키텍트가 되기 위해서는 끊임없이 기술을 학습하고 의사소통을 잘 하는 법을 익히는 등 많은 노력이 필요할 것 같습니다. 아키텍트에 대한 전반적인 정보를 듣고, 아키텍트와 개발자 사이의 차이를 인지하는 데 도움을 주는 책이라고 봅니다.

서브버전을 이용한 실용적인 버전 관리는 Pragmatic Version Control using Subversion의 번역서입니다. 번역서가 2006년 3월에 나왔는데, Pragmatic Version Control using Subversion, 2nd Edition이 2006년 5월에 나왔습니다. 이 책의 번역서는 없는 것 같습니다. 2판에서는 subversion 1.3의 주요한 변화들이 반영되어 있다고 합니다.^[각주:1]

번역서는 조금 낯선 용어들이 보입니다. 가지(branck), 꼬리표(tag), 조리법(recipe) 등이 그에 해당합니다. 책의 짜임새는 잘 구성된 편입니다. 명령 요약도 대체로 만족합니다. 설명이 명령어 중심이라, 서브버전을 명령 줄 인터페이스에서 사용할 때 참고하기 편합니다. 기타자료로 제시된 Subversion Book도 볼만 한 것 같습니다. 어제는 접속이 안 되었는데 이 글을 쓸 때에는 접속이 잘 되는군요. 영문이며, 무료로 내려받을 수도 있습니다.

모르는 부분을 찾아 보면서 서브버전^[각주:2]을 익혀야겠습니다.

Professional 소프트웨어 개발을 읽었습니다. 스티브 맥코넬 씨가 지은 책인데요, 번역서가 2003년에 초판이 발행되었네요. 책의 용어를 사용하자면 이 책은 SWEBOK(Software Engineering Body of Knowledge)에서 변하지 않는 범주에 속하는 책이라고 여겨집니다.

책을 읽고 나서 곰곰이 생각하게 된 것은, 컴퓨터과학과 소프트웨어공학 사이의 격차인데요. 일단 컴퓨터과학은 현업에서 그 가치가 크게 인정받지 못하더라고, 다른 과학자와 주로 관련을 맺는 점에 반해, 소프트웨어공학은 현업에서 실제로 소비자와 부딪치기 때문에 여러가지 제약 조건들을 숙지하고 있어야 한다는 점이 인상적이었습니다.

마지막 파트인 업계의 프로정신에서 다루어진, "혁신의 확산"에 대한 그래프가 있었는데요. 선각수용자와 전기 다수의 캐즘(chasm)을 다루고 있는 부분이 있었습니다. 혁신자보다는 적은 위험을 안는 선각수용자들은 XP나 스크럼 등 애자일 방법론을 적용하는 쪽이고, 전기 다수인 사람들은 역량 성숙도 모델(CMM) 종류를 적용하는 것이라고 생각했습니다. 책에서는 Code&Fixing(일단 코드를 작성하고, 나중에 고치는)을 가장 피해야 한다고 했는데, 이 부분에서 가책을 느꼈습니다.

책의 역자서문에서는 Rapid Development나 Code Complete를 스터디하기 전에, 다소 추상적인 에세이들이 모인 이 책을 먼저 읽을 것이 추천되고 있습니다. 소프트웨어공학 분야를 아우르면서, 동시에 "프로페셔널"하다는 것에 논한다는 점에서 신선한 자극을 주는 책이락 생각합니다.