The note of Legendre

"Release it! 성공적인 출시를 위한 소프트웨어 설계와 배치"를 읽었습니다. Hani님 블로그인 Talk about Software with hani를 틈틈이 구독하다가 베타리딩 공지를 보고, 참여할 수 있게되어 더욱 기억에 남는데요. 12월 7일 있었던 베타리더 모임 때 Hani 님이 쓰신 메시지가 담긴 책을 받게 되어 기뻤습니다.

이 책은 프로젝트를 완성하고 나서 그 이후라는 시점에 대해 집중하고 있습니다. 2장에서 소개되는 사례연구 중 하나인 "항공사를 정지시킨 예외(Exception) 사건"이 있는데요. 실제로 모든 버그에 대해 릴리스하기 전에 대처하기는 어렵습니다. 이런 버그가 미칠 수 있는 영향을 최대한 축소시키는, 설계를 채택하는 방법이 논의되고 있습니다.

깊은 인상을 받았던 곳은 4장 안정성 안티패턴에서 언급된 "느린 응답"입니다. 저도 어떤 웹 페이지에 들어갔는데, 불러오는 과정이 더디면 무의식적으로 페이지 새로 고침을 누르곤 했습니다. 이런 사용자의 행동은 웹 서비스의 트래픽을 더 무겁게 할거라고 예상되는데요, 이런 부분에서 저자의 통찰력을 느꼈습니다.

프로젝트 출시 이후의 삶을 다룬다는 점에서, 실용적인 도움이 될 수 있는 책이라고 생각합니다. 이 책은 지난 번에 소개해드렸던 "Ship it!"을 읽었습니다와 같은 시리즈입니다.

실용주의 프로그래머를 위한 단위테스트 with JUnit를 읽었습니다. 실용주의 서가에서 나온 책인데요, 데이비드 토머스와 앤드류 헌트가 실용주의 프로그래머의 실천편이라고 보시면 될 듯합니다. 테스트는 코드를 다 작성하고 나서 발견하지 못한 오류를 찾기 위해 나중에 작성하는 것이 아닌가라고 생각하시는 분이 꽤 되리라고 생각합니다. 시간과 공간 자원에 제약이 걸린 일반적인 프로젝트의 경우에는, 동작하는 코드를 만들기에 급급해서 테스트라는 부분을 소홀히 하는 경우도 드물지 않을 것입니다. 그리고 그때 테스트를 수행한다고 해도 그건 요구사항에 적합한지 확인하는 인수 테스트(acceptance test)이죠.

이 책은 단위테스트를 왜 도입해야 하는가에 대해 서론에서 매우 설득력 있게 설명하고 있습니다. 원천적으로 오류가 없는 소프트웨어란 매우 어렵습니다. 목적은 매 순간의 코드를 단위테스트를 통해 검증함으로써 나중에 일어날 수 있는, 즉 찾지 못한 오류가 누적됨으로써 발생하는 재앙을 막아보자는 데 있습니다. 이런 패턴적 문제 해결은 애자일 쪽과 통하는 면이 있습니다. 코드를 작성함으로써 부산물로 나오는 단위테스트 코드는, 그 코드를 후에 인수할 사람들에게는 좋은 문서이자, 참고자료, 나침반이 됩니다.

이 책에서는 JUnit으로 테스트를 작성하는 근본적인 부분부터, 테스트의 대상은 무엇인지, 모의 객체는 어떻게 사용하는지, 프로젝트에서는 테스트를 어떤 식으로 할 것인지 등에 대해 차근차근 다루고 있습니다. 재치있는 약자를 통해 쉽게 책의 내용을 숙지할 수 있도록 돕는 것도 책의 장점입니다. 이를 테면 Right-BICEP과 CORRECT가 있습니다.

사실 이 책을 고른 이유는, 책의 서문에서 비록 이 책이 예제는 Java를 사용하고 JUnit 프레임워크를 사용했지만 다른 60개가 넘는 언어에서 비슷한 테스트 프레임워크가 지원된다고 했기 때문입니다. c2.com에서 Testing Framework라는 문서를 통해 다양한 프레임워크가 있다는 것을 알 수 있습니다. 개인적으로 SmlUnit^[각주:1]이라는 테스팅프레임워크를 다루어 보려고 하다가, 막막해서 JUnit에 대한 책이 나와 있으니 이 책을 우선 참고하는게 어떨까 하는 생각이었죠.

프로젝트에 단위테스트를 도입하여 꾸준한 피드백으로 잘 조직화된 코드를 작성한다면, 유지보수성이 높고 안정적인 결과물이 나오지 않을까 생각해 봅니다.

P-Camp 그 두번째 만남을 다녀왔습니다. 2007년 10월 10일 수요일, 코엑스 컨퍼런스센터 401호에서 열렸습니다. 시작하기 전에 신청했던 샌드위치를 먹고나서(처음에는 물이 없어서 그냥 먹다가… 나중에 물을 주셔서 다행이었습니다.) 401호로 들어갔습니다. 오프닝 튜토리얼로 김창준님 께서 "Ontogeny^[각주:1] of Unit Tests in Test Driven Development"를 주제로 발표해 주셨습니다. 국제 콘퍼런스 때에 발표되었던 자료라, 발표자료가 영어로 되어 있다고 하시더군요.

Test에는 두가지 방식이 있다고 하셨는데요.

• Support Programming Test to pass
• Critic Programming Test to fail

이 있다고 합니다. "린 소프트웨어 개발"의 저자 중 한 명인 Merry Poppendick은 둘 다 선택하라고 하는데, 발표자료에서 다루는 건 "Test to pass"쪽에 중점을 맞춘다고 하셨습니다.

V-Model 이야기와 함께, Design Pattern에는 GoF^[각주:2] 여러가지 경험을 두루 쌓은 Christopher Alexander[/footnote]물리와 화학, 수학, 건축학, 전산과학 등을 공부했다고 합니다. [/footnote]가 지었다는 4권으로 된 "Nature of Order"가 소개되었습니다. (시간 없는 분은 2권만이라도 읽으라고 추천하시더군요. 저도 도서관에 신청했습니다.) 이 책은 검증받진 못했지만, 가능성이 있다고 합니다. Best practice라기보다는, A practice로 보는 게 맞다고 하시더군요.

Living Structure의 기준은 Wholeness(전체성)가 언급되었습니다. Life에 대해서 Christopher Alexander는 A와 B를 두고 어느 것이 더 살아있는 느낌이 나는지 피실험자로 하여금 고르게 하였는데, 대부분의 사람들이 살아있다고 느끼는 선택점은 대부분 일치했다고 합니다.

Which one of these two things would I prefer to become by the day of end of life?^[각주:3]

Mistake-free^[각주:4], 즉 실수가 없으려면 창조(설계적)보다는 생성(단계적)으로 접근하는 게, 실수의 여지가 감소하며 살아있는 느낌을 받을 수 있다고 합니다. 이는 Community, Product, 시(Poem)에도 적용 가능하다고 합니다.

여기서 정의된 Ontogeny는, "Living Sturcture를 만드는 과정"이라고 정의되었습니다. Addition(추가)와 대치되는 Differentiation(분화)^[각주:5] 즉 자라나기 전에 기미가 나타나고, 그 후에 출현한다는 모습으로 설명되더군요.

또한 Contextual(직역하면 '문맥상의')을 키워드로 하여 본래 존재하던 것의 훼손을 경계한다는 이야기를 들었습니다. "건물을 피어나게 한다"라는 생각에 약간 감동을 받았습니다. 이를 Structure Preserving Transformation이라고 하더군요. 화가 Henry Matisse의 이야기와 더불어, 살아있는 특징에 대해 몇 가지 언급되었는데요. Center는 주의를 집중하게 하고, 도드라져 보이며, 하나 이상일 수 있다고 합니다. Pattern은 Center를 생성하는 규칙이고, 이보더 더 일반적인 Sequence는 과정을 거치면 Center가 만들어지는 것을 말한다고 합니다.

Unfolding Generative 15 Properties (of Natural Morphology)가 다음에 소개되었는데요. 다음과 같습니다.
(강조된 것은 *)

1. Levels of Scale
2. Strong Centers *
3. Boundaries
4. Alternating Repetition *
5. Positive Space
6. Good Shape
7. Local Symmetries
   
8. Deep Interlock and Ambiguity
9. Contrast
10. Gradients
11. Roughness
12. Echoes
13. The Void
14. Simplicity and Inner Calm
15. Not-Separateness^[각주:6]

이는 15 transformations라고도 불리고, Refactoring(Latent Center를 찾음으로써)에도 적용될 수 있다고 합니다. 신용카드가 유효한 지 검증하는, Luhn Algorithm으로 원시적인 코드에서 Center를 강화시킴으로써 자라는 코드를 보여 주셨는데 매우 인상깊었습니다. 특색처럼, 대규모 응용에는 Process, People Relation, Online Community, Interaction Design이 언급되었습니다.

Q&A시간에는 어떻게 이런 것들을 적용하면 좋겠냐고 하셨는데,
Do once more good thing, Do it again and again…이라고 하시더군요.
작은 좋은 것들이 모여 더 큰 좋은 일에 기여한다는 것이었죠.

토론에는 "14. 효율적인 교육과 여가활용 방안"에 참석했습니다. 뵙기 힘든 다양한 분들을 만나, 진솔한 이야기를 나누고 들을 수 있어 유익한 자리였습니다. 각자 여가를 어떻게 활용하는 지에 대해 퍼실리테이터 역할을 맡으신 분의 조정으로 돌아가면서 이야기를 듣고는 했습니다. "아키텍트를 꿈꾸는 사람들"이라는 네이버 카페에서 활동하시는 분도 있으시더군요. 혼자서 하는 공부와는 다르게 여럿이 하는 스터디는 책임감에서라도 더 열심히 하게되는 동기가 주어진다는 생각을 했습니다. 하지만 토론규칙이나 형식이 지나치게 제약을 주지 않은 한에서, 더 짜임새있더라면 좋지 않았을까 하는 아쉬움도 남았습니다.

토론이 끝나고 나서는, 희망하는 조에 한해서 퍼실리테이터가 토론에서 의미있는 결론이나, 새로이 통찰할 수 있는 것들을 모아 정리해서 간단히 발표하는 시간이었습니다. 발표하는 분에게는 한정판 Geek 티셔츠(!)가 주어지더군요. 발표까지 끝나고 나자, 어느덧 저녁 10시를 약간 넘긴 시각이 되었습니다. 만나기 힘든 분들이 한 자리에 모여 서로 소통하고 배울 수 있다는 점에서 P-Camp는 가치있다고 생각합니다. P-Camp 세 번째 만남을 기대합니다.

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

고객 또는 대리사용자로부터 수집한 사용자 스토리는 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월 중순에 번역본으로 나왔던 소식을 들었던 터라, 반가웠습니다. 테일러주의가 보편적으로 사회에 자리잡기는 했지만, 특정 분야(이를테면 소프트웨어 개발)에서는 그에 적합한 방법을 사용하는 것이 맞다고 봅니다.

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

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