The note of Legendre

Ajax 인 프랙티스는 위키북스에서 발행하는 열 번째 도서라고 하는데요. 실무에 도입할 수 있는 내용을 많이 다루고 있어서, 실용적으로 볼 수 있는 책이라고 생각합니다. 개인적으로 위키북스에서 지속적으로 좋은 책들을 번역해주신 것에 대해 감사를 표하고 싶습니다. 쉽게 배우는 JRuby On Rails도 만족했었는데, 이번 책도 매우 기대되네요.

린 소프트웨어 개발을 읽었습니다.^[각주:1] 도요타라는 자동차 회사에서 적용하고 있는 작업 방식(혹은 도요타 생산방식이라고 알려진)에 대해서는, 많은 경영서들에서 언급하고 있었고 이런 방식이 소프트웨어 개발에 적용될 수 있다는 점에서 이 책에 관심을 갖게 되었습니다. 책의 부제는 "애자일 실천 도구 22가지"인데, 이 부제대로 책은 각 도구를 기준으로 하여 차분히 설명하고 있습니다.

특히 흥미를 가졌던 주제는

• 도구 1의 가치를 전달하지 않는 모든 행위를 낭비로 간주했던 점이 신선했던, 낭비 찾아내기
• 도구 11의 시간 자원의 효율적 사용을 도와주는 대기행렬이론^[각주:2]
• 도구 13의 피상적 접근을 경계하고, 사람에 집중하는 자기 결정권
• 6장의 통합성
  
• 고객과 개발자가 동적으로 의견을 교환하도록 돕는 인식통합성,
  
• 신속하고 잦은 소통이 강조되는 개념통합성

입니다. 더불어 책 중간에 예시로 소개되었던 "죽음의 행진"이라는 책에도 호기심이 생겼습니다. 22개의 도구가 여러 장에 걸쳐 소개되고 나서는, 주의사항과 환경별 사용법 등이 소개된 사용설명서와 제품보증서가 나옵니다. 책에 나왔던 여러 지침들을 실행하기 전에 이 부분을 읽어보는 것이 바람직해 보입니다. 아쉬웠던 점은, 사이드바에 제시된 주석의 양이 많고 빈번한 것입니다. 저자의 의도는 본문에 제시된 글에 대해 풍부한 참고자료나, 적절한 출처, 본문에 대한 보강설명 등을 제공하려는 것으로 보입니다. 주석을 꼼꼼하게 챙겨 보는 저같은 경우에는 본문을 읽다가, 사이드바의 주석을 읽고 다시 본문으로 돌아오려면 맥이 끊겨서, 본문에 집중하는데 어려움을 겪었습니다.

그림과 도표로 린 방식의 이해를 돕는 이 책은, 소프트웨어 개발에 관련된 다양한 역할의 분들이 '린'방식의 본질을 알고, 실천하는 데 좋은 길잡이가 될 것으로 보입니다.

익스트림 프로그래밍, 애자일 프랙티스에 이어서 (고객 중심의 요구사항 기법) 사용자 스토리를 읽게 되었습니다. 이제 '린 소프트웨어 개발'만 읽는다면, 인사이트에서 나온 애자일 시리즈 도서를 다 읽게 되는군요. 사용자 스토리는 현실을 반영하지 못하는 요구사항 명세에서, 고객과의 지속적인 대화를 강조합니다. 대화로 하여금, 모호한 문장으로 생기는 고객과 개발자 사이의 간극을 좁힐 수 있습니다. 고객으로 하여금 사용자 스토리를 작성하게 함으로써, 개발자와 고객 사이의 공통된 언어를 사용하도록 돕습니다.

고객 또는 대리사용자로부터 수집한 사용자 스토리는 2부의 '추정과 계획'에서 점수를 매깁니다. 이 스토리 점수에 따라서 이터레이션마다 어떤 스토리를 개발할 것인지 계획하고,  각 이터레이션 주기를 모니터링 함으로써 이터레이션 차트를 그리도록 합니다.

3부에서는 스토리로 오해하기 쉬운 것들과, 사용자 스토리를 써야 하는 이유, 그리고 스토리를 사용할 때 주의해야 할 점들을 다룹니다. 또한 Agile 계열의 방법론 중 하나인 Scrum에서 사용자 스토리를 사용하는 예시를 보여줍니다. 4부에서는 항해업에 종사하는 사람들을 위해 온라인 도서 판매 서비스를 제공한다는 예제를 통해, 사용자 스토리를 전체적으로 짚어봅니다. 5부에서는 익스트림 프로그래밍을 접하지 못한 사람들을 위해, 간략한 개요가 들어있고 각 장의 연습문제 해답이 들어 있습니다.

다른 서적에 소개된 요구사항 기법들에 짓눌려 있었다면, 사용자 스토리를 통해 재빠르고 가벼운 기법을 도입한다면 어떨까요?

(우리가 미처 알지 못한) 소프트웨어 공학의 사실과 오해(원서명: Facts and Allacies of Software Engineering)을 주변에서 추천해 주셔서, 읽게 되었습니다. 소프트웨어 컨플릭트 2.0의 저자이기도 한 로버트 L.글래스가 지은 책입니다. 책은 사실 55가지와 오해 5+5가지를 다루고 있습니다. ^[각주:1]

제일 감명 깊게 읽은 곳은 오해의 마지막 부분입니다. 교육에 관련된 오해인데요. 저도 처음에 프로그래밍 언어를 배울 때나, 아니면 특정한 프로그래밍 언어를 가르쳐 주는 책을 볼 때면 이런 이런 문법을 설명해 줍니다. 그 다음에 연습문제로 이런 이런 코드를 짜 보라고 하죠. 이렇게 많은 책에서 설명하고 있기 때문에, 그렇게 프로그래밍 언어를 학습하는 일이 당연한 것처럼 느꼈습니다. 우리가 어떤 언어를 학습할 때에 쓰기는 가장 끝 부분에 배웁니다. 읽는 법을 알아야, 쓰고 나서라도 자신이 쓴 문장을 읽는 일이 가능합니다. 그런데 프로그래밍 언어를 가르치는 쪽의 경우에, "코드 읽기"라는 부분에 대해 관심도가 떨어진다는 느낌이 듭니다. "코드 읽기"는 다른 사람이 썼던 코드를 인수받아야 할 경우나, 아니면 자신이 몇 달 전에 작성했던 코드를 분석할 때와 같이 쓸 일이 있음에도 말이죠.

이 책에서는 각각의 사실 또는 오해에 대해 "토의-논쟁-출처-참고문헌"의 구조로 짜임새 있게 이루어져서 자신이 관심있는 사실 또는 오해를 더 탐구할 수 있도록 열어두고 있습니다. 특히 오해 부분에서는 이 오해들을 읽더라도 화를 내지 말 것을 주문하는 문장이 기억에 남았습니다. 소프트웨어 부문의 문제를 지적하고, 설명하며, 문제를 보는 새로운 관점을 건넨다는 점에서 유용한 책이라고 생각합니다.

익스트림 프로그래밍(Extreme Programing Explained 2/E)를 읽었습니다. Extreme Programming, 줄여서 XP는 "애자일 소프트웨어 개발"에서 논의되는 방법론 중의 하나입니다. 한국 eXtreme Programming 사용자 모임도 있고요.
첫 부분에 XP에 대한 설명과 1부 XP 탐험하기에 대해서는 차근차근 XP가 추구하는 가치, XP의 실천방법 등에 대해 나와 있습니다.

제일 관심있게 읽었던 부분은 "제약이론"입니다. 세탁하는 과정을 비유로 들어서 제약 이론을 설명하고 있었는데, 제약 지점을 찾는 것에 대한 이야기를 하고 있었습니다. 제약 이론은 전체적인 처리 역량을 좋게하는데 초점을 두고 있다는 점에서 좋은 방법으로 보입니다. 다만 XP를 적용함으로써 새로운 제약지점 부서는 주목받는 일을 원하지 않기 때문에, XP가 도입되기 여렵다고 하는 점에서 아쉬웠습니다.

도요타 생산 시스템이 언급되는 장도 있었습니다. 이 장에서 언급되었던 Lean Software Development가 2007년 9월 중순에 번역본으로 나왔던 소식을 들었던 터라, 반가웠습니다. 테일러주의가 보편적으로 사회에 자리잡기는 했지만, 특정 분야(이를테면 소프트웨어 개발)에서는 그에 적합한 방법을 사용하는 것이 맞다고 봅니다.

책 끝부분에 많은 참고문헌이 소개되어 있어서,
어떤 주제에 대해 관심이 있다면 찾아서 학습할 수 있도록 돕고 있습니다.

블로그에 읽었던 책을 틈틈이 정리하고는 하는데, 이번주는 정말 책을 열심히 읽었네요.

맨먼스 미신을 도서관에서 빌려 읽었습니다. The Mythical Man-Month라는 책을 여러 책에서 추천하고 있었는데, 번역본이 출간되어 반가웠습니다. 책 겉면에는 출간 20주년 기념판이라고 써 있었는데, 본래 책이 1995년에 나왔으니 32년 넘게 시간이 흘렀군요. 꾸준하게 다양한 배경의 사람들이 읽었다고 들은 책이라 기대가 되었습니다. "소프트웨어 컨플릭트 2.0"처럼 한겨레신문에서 제공하던 서체를 사용하던데, 처음에는 좀 어색했지만 적응하고 나니 글씨도 큼직하고 읽기 좋습니다.

이 책의 구조에서 가장 깊은 인상을 남긴 것은 각 장이 시작될 때마다 한 페이지 전체에 관련된 그림이나 사진이 실리는 모습이었습니다. 앞의 그림을 떠올리면서 책을 읽어나가다보면, "이런 주제를 드러내려고 이런 그림을 실었구나!"하고 느낄 수 있었습니다.

다른 소프트웨어 공학 에세이에서도 빈번하게 나타나는 주제인, "은총알(Silver bullet)"에 대한 언급도 있었습니다(은총알은 없다). 소프트웨어 공학에서 발생하는 괴물같은 주제를 늑대인간에 비유하고, 이른 해결할 돌파구를 늑대인간을 무찌를 수 있다고 알려진 은총알에 비유한 것인데요. 흥미롭게 읽었습니다.

다른 한 가지는 프로젝트 팀을 수술 팀이라는 은유로 생각했던 부분이었습니다. 이 해결책은 Harlan Mills라는 분이 제안했던 것인데, 문제를 조각내지 않고 많은 손이 필요한 부분에 적절히 역할을 맡아 효과적인 문제 해결을 위해 노력한다는 점이 마음에 들었습니다.

맨먼스 미신의 초판에서 제안되었던 사항들이 지금은 어떻게 되었는지, 맨먼스 미신의 초판에 대한 저자의 고찰과 회고가 담긴 장들이 뒷부분에 추가되어 있었습니다. 과거가 미래 예측에 도움이 되는가에 대해서는 논란이 있지만, 그래도 현재 살아가는데 과거의 지식이 가치있으리라고 생각합니다. 책에 나온 기술들이 현재 사용되는 것과 다소 동떨어질 수 있지만, 근본적인 가치는 크게 변하지 않아서 여러 사람들에게 도움이 되리라 생각합니다.

애자일 프랙티스를 읽었습니다. Practices of an Agile Developer의 제목 공모 이벤트에 참여만 했을 뿐인데 책을 받게 되어 기쁩니다. 책을 처음 펼치자 마자 맞닥뜨린 인용구가 인상적이었습니다. 책에서는 한 장이 시작할 때마다 그와 관련된 속담, 격언, 인용구 등으로 주제를 도입하고 있습니다. The Pragmatic Programmer(실용주의 프로그래머로 국내에서 번역되었죠.)의 공동저자 중 한 사람인 앤디 헌트와 Agile Developer의 설립자 벤캣 수브라마니암이 쓴 이 책은 말 그대로 적용 가능한 실천 지침들을 제공하고 있습니다.

1장에서는 우선 애자일 소프트웨어 개발에 대한 배경적 지식을 논합니다. 2장부터 8장까지 각 장의 서두에는 어떤 지침들이 나올 예정인지 간략히 소개되어 있습니다. 각 지침의 첫 부분에는 악마가 사람들이 피해야 할 나쁜 습관을 일러줍니다. 지침에 관련된 에피소드나 실례를 제시하여 이 지침이 왜 유용한지 거부감없이 느낄 수 있게 하며, 천사가 사람들이 가져야 할 좋은 습관을 일러 줍니다. 책 표지에 악마와 천사가 등장하는 것은, 독특한 캐릭터들이 지침의 설명 부분에 등장하기 때문으로 생각합니다. 그 후에는 "어떻게 느껴야 하는가?"라는 부분이 있습니다. 말 그대로 이런 느낌을 갖고 있다면, 바르게 가고 있다는 안내를 해 주기 위해 도입된 것으로 보입니다.

하지만 어떤 지침이든 지나치게 적용하거나, 느슨하게 적용하면 그 효과를 제대로 발휘하지 못할 수 있습니다. 이런 부분을 바로잡기 위해 "균형 유지하기"에서는 어떤 부분에 중점을 두어야 하고, 어느 정도가 적당한지 지적합니다.

에필로그를 읽다보니 전에 보았던 Ship It!을 개발 기반의 마련을 위한 Starter Kit으로 추천하더군요. 뒤에는 여러 참조 링크와 관련 문헌들이 소개되어 있고, 실용주의 프로그래머처럼 가이드라인 요약본이 뒷표지 앞에 붙어 있습니다.

최근에 IT 회사에 다니시는 분에게 이야기를 들을 기회가 있었습니다. 그 분이 의아해하셨던 것은, "왜 대학에서는 테스트를 가르치는 과목이 없느냐?"였습니다. 애자일의 인프라스트럭처에는 "유닛테스트"가 중요한 위치를 차지하고 있습니다. "테스트 주도 개발"이라는 움직임이 보이고, 국제 테스팅 컨퍼런스(2007년 10월 초에 서울 코엑스에서 열린다고 합니다.) 도 열리고 있으며, 수습 불가능한 스파게티 코드가 되는 일을 피하고 유지보수를 쉽게 하기 위해서라도 테스트의 중요성은 날로 커지고 있습니다. 그래서, 테스트에 대한 과목도 교과과정에 들어있으면 하는 바람이 생겼습니다.

애자일이라는 걸 머리로는 알고 있지만, 어떻게 실천해야 하는가에 대해 막막함을 느낀 분들도 있을거라 생각합니다. 이 책에서 시도하기 쉬운 지침을 선택하여 점진적으로 적용한다면, 개인과 팀에 긍정적인 변화가 생기지 않을까 생각해 봅니다.

소프트웨어 컨플릭트 2.0 (부제: 시대를 뛰어넘는 즐거운 논쟁)번역본이 2007년 1월에 위키북스에서 나왔습니다. 책을 읽을 때, 서문을 읽을 것인가 말 것인가의 문제는 개인의 취향에 달린 문제입니다. 저같은 경우에는 책을 읽을 때 서문도 꼼꼼하게 읽어보는 데요. 글쓴이가 감사를 표하기 위해 적은 사람들을 위해서이기도 합니다. 이번 책은 1판 서문 등이 포함되어 유난히 서문이 길더군요.

이 책은 6가지의 범주로 되어 있습니다. "논쟁의 장/기술 진영에서/최신 무기 정보/지휘 본부에서/연구실에서/전장 사후 분석"인데요. 책 안을 살펴보면 범주와 관련된 수필들이 들어 있습니다. 15년 전에 쓰인 글들도 들어 있지만, 로버트 L. 글래스가 말하고자 했던 주제와, 그 통찰력이 인상에 남았습니다.

특히 저를 반성하게 했던 글 가운데 하나는 6부 "전장 사후 분석"에서의 첫 번째 수필 '전산학이 진짜 과학이 되며, 소프트웨어 공학이 되려면'이었습니다. 본질적인 핵심을 찌른 수필이었습니다. 저도 "구조적이다, 정형적이다"라는 형용사를 "좋다"라는 형용사와 이어서 생각하는, 그런 선입관이 있었습니다. 전산 분야에서 "실험"이라는 연구 방법이 사용되지 말아야 하는 이유는 없으며, 오히려 전산학이 과학으로서 굳게 자리매김하려면 "실험"은 권장되어야 한다고 생각하게 되었습니다.

이 책의 수필에서 제시하고 있는 문제들 가운데에는 현재 해결되지 못한 문제도 많이 들어 있습니다. 그래서, 읽고 난 뒤에  독자에게 고민할 재료를 주는 것도 이 책의 특징이지요. 도서관에서 며칠 째 눈도장만 찍다가 지난 번에 빌렸는데, 개인적으로 유익했습니다. 지하철에서 들고 다니며 읽기도 좋고요.

DOM 스크립트라는 책을 읽게 되었습니다. 이 책을 번역해 주신 분은 Channy's Blog를 운영하는 분이기도 합니다. 막상 책을 직접 잡을 때까지는 몰랐는데, 만박님, 현석님, 주일님이 추천의 글을 써 주셨더라고요. DOM이라는 이름도 저에게는 되게 생소했는데, 1장에서 브라우저 전쟁에 대한 이야기와 함께 어떻게 지금의 사태까지 흘러왔는지 설명되어 있었습니다. 저는 DOM^[각주:1]도 무슨 언어이겠거니 하고 오해를 하고 있었는데, 책에서는 API^[각주:2]처럼 라고 생각해보라고 이야기 해주더군요.

자바스크립트^[각주:3]의 문법은 이전에 보았던 C와 대체로 비슷했습니다. 주석 형식도, 문장 뒤에는 세미콜론을 붙이는 것도. "결합형 배열"같은 개념은 루비의 해시나 파이썬의 딕셔너리와 유사하다고 느꼈지요. 연산자, 조건문, 반복문, for문 C와 유사했습니다. for 문 안에 변수 선언이 된다는 점은 제외하고요.
"객체"라는 것에 대해 많이 이야기를 듣기는 합니다. "객체지향"이라는 형태로 쓰이기도 하지요. 하지만 막상 다른 사람에게 "객체"를 설명해보라고 하면 자꾸 막히곤 합니다. 자바스크립트에서도 객체가 있더군요.

각 장의 끝 부분에는 "이러이러한 내용을 배웠고, 저러저러한 내용을 배울 것이다"라고 정리가 되어 있어서 장마다 독자가 읽은 내용을 확인하도록 도와줍니다. 작은 부분이지만, 전 마음에 들었습니다.

책에서 중심이 되는 예제는 사진첩 예제인데요. 처음에는 사진첩을 간단하게 만들어 보고, 중간에 표준에 관한 내용이 설명된 후, 그에 맞게 개선하는 작업이 나와 있습니다. 그중 "단계적 기능 축소"라는 부분이 공감이 되었습니다. 파이어폭스^[각주:4] 브라우저를 사용할 때, 내비게이션에 나쁜 방법으로 자바스크립트를 써서 작동되지 않을 때 불편했던 기억이 떠올랐기 때문입니다. 가능하면 스크립트코드를 바깥쪽으로 빼내고, 브라우저 지원을 위해 방어적으로 코드를 작성할 것을 여기선 추천합니다.

온전히 기술적인 내용만 다루고 있는게 아니라, "조엘 온 소프트웨어" 느낌이 드는 글이 포함되어 있어서 왜 이렇게 해야하는가에 대해 설득력있게 다루고 있습니다.

부록에는 메소드/프로퍼티 참조자료, DOM 식으로 개발되어 바로 가져다 쓸 수 있는 예제^[각주:5], 협업 방법론^[각주:6]에 대한 글이 실려 있습니다.

나는 책을
읽는다, 산다, 판다, 펼친다, 닫는다, 연다, 잃었다, 본다, 받는다, 준다, 가리킨다, 잡는다, 든다, 돌린다, 찢는다, 쌓는다, 정리한다, 쓴다, 맨다, 뒤적인다, 꽂는다, 둔다, 놓는다, 살핀다, 덮는다, 버린다, 보관한다, 구입한다, 출판한다, 펴낸다, 떠난다, 간행한다, 열람한다, 발행한다, 전시한다, 빌린다, 자랑한다, 고른다, 선택한다, 연구한다, 공부한다, 생각한다, 대여한다, 만든다, 판매한다, 홍보한다, 알린다, 인쇄한다, 보관한다, 맡는다, 지킨다, 수집한다, 모은다, 교환한다, 찾는다, 발견한다, 묻는다, 안내한다, 소개한다, 거부한다, 공개한다, 분류한다, 나눈다, 발간한다, 심의한다, 검색한다, 흥정한다..

'나'와 '책' 사이의 관계 채워넣기.
단어와 단어 사이의 관계 찾기.
온톨로지