The note of Legendre

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

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

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

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

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

다음 캘린더가 베타서비스로 티스토리 공지블로그에서 소개되었습니다.

구글기어스와 같은 툴을 이용해서, 오프라인에서도 일정을 편집하다가
네트워크에 컴퓨터가 연결되면 동기화해주는 그런 기능이 있으면 좋을 것 같아요.

Sunbird, Thunderbird와 같은 로컬 프로그램과 다음 캘린더가 연동될 수 있으면, 좋겠어요.

일정을 일정 개수 이상의 개수를 입력하면
more 버튼이 나와서 누르고 나서 생략된 내용이 보이도록 하는데, 그냥 클릭하면
그 부분이 확대되서 생략된 일정 내용이 보였으면 좋겠어요.

연간 일정 보기도 있었으면 좋겠어요. 그러면 좀 더 거시적인 계획을 세우는 데 도움이 될 것 같네요.

태터툴즈^[각주:1]라는 오픈소스 블로그 툴을 기반으로 한 티스토리는, 설치형 블로그의 번거러움과 불안정성을 해소하고  상세한 기능 요구를 어느정도 절충하여 나온 모델인데요. 오픈소스로부터 피어난 성공 모델이 국내에 하나 더 늘어나게 되어 기쁩니다. 티스토리의 정식오픈을 진심으로 축하합니다.

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

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

특히 흥미를 가졌던 주제는

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

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

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

2007 JCO 오픈소스 컨퍼런스라는 포스팅에서 소개했던 2007년 10월 13일 토요일 건국대학교 새천년관에서 2007 JCO 오픈소스 컨퍼런스가 열렸습니다. 새천년관에 들어가서 지하로 내려가는 계단이 있더군요. 입장은 무료였는데, 자료집은 5000원에 따로 판매하더군요. 처음 JCO 옥상훈 회장님이 개회사를 하신 후,  한국공개소프트웨어활성화포럼 의장이신 고건 교수님과 KLDP 권순선 대표님께서 축사를 해 주셨습니다. 그러고 나서 Sun의 심명종 상무님께서 오픈소스 채택 배경 등을 주제로 발표가 바로 시작되었습니다. Sun과 관련된 Glassfish와 같은, 오픈소스가 소개되었습니다. NHN에서는 Java 오픈소스를 어떻게 활용하고 있는지 등의 주제로 이야기해 주셨습니다.

(행사가 지연되어 점심시간이 사라졌습니다.)

첫 번째 시간에는 대공연장에서 '블루오션'이라는 말에 끌려 들었는데, 디자이너, 개발자 등을 위한 유용한 도구나 기법 등을 주로 소개해 주셨습니다. 오픈소스에 개발해서 기여하지 않더라도, 문서화나 관련 도서를 씀으로써 오픈소스 확산에 기여한다는 이야기도 나왔습니다.
두 번째 시간에는 Java를 들었는데 지금 Apache 라이센스가 걸려있는 부분과, 저작권이 있는 부분을 해결하느라 완전한 오픈소스가 될 예정인 Java SE 7의 공개는 내년에서야 이루어 질 것 같다는 이야기를 들었습니다. 위원회를 구성해서 Java를 계속 개발해나간다고 하셨는데, 긍정적인 계기가 되었으면 좋겠습니다.

그 다음은 잠시 휴식시간이 있었는데, 커피가 인기가 있어서 마시기가 힘들더군요.

세 번째 시간에는 윤석찬님의 모질라 프로젝트 등을 주제로 국제회의실에서 들었습니다. Firefox의 탄생과 성장과정을 웹 브라우저의 스크린샷으로 볼 수 있어 인상깊었습니다. 선더버드, 선버드, 버그질라 등 모질라 측에서 진행하고 있는 다른 오픈소스 프로젝트에 대한 정보를 얻을 수 있었고, Firefox 주소창 옆에 있는 검색창에 대한 기원도 들을 수 있었습니다. 이는 Firefox가 웹 브라우저를 공개할 때 첫 페이지로 제공될 화면을 구글이 제공해 주었기 때문에 그에 대한 감사의 표시로 검색툴바를 달았는데 구글에서 이 검색툴바로 들어오는 검색 요청이 많아지자, 비용을 지불하기를 원했고, 모질라 재단은 비영리이기 때문에 자회사인 모질라 코퍼레이션을 만들어 비용을 받았다고 합니다. XUL^[각주:1]을 기반으로 만들어진 음악 재생 프로그램 송버드와 동영상 재생 프로그램 미로에 대한 소개도 있었습니다. 파이어폭스 관련 기념품도 나누어 주셨는데, 인기가 많아서 몸이 날렵하지 못한 저는 받지 못했습니다.

네 번째 시간에는 JBoss 이야기를 들었는데요. 오픈소스 계에서는 상당히 유명하신 분으로 생각되었습니다. JBoss의 어원이 EJBoss(open source software)였는데, EJB 측과 상표에 문제가 생겨서 앞에 E를 빼고 제이보스가 되었다는 이야기가 재미있었습니다. JBoss에 대한 차세대 개발 소식을 들을 수 있었습니다.

다섯 번째 시간에는 한국스프링사용자모임(KSUG)의 안영회 님께서 Spring 2.0 활용을 주제로 발표하셨는데요. 중국 개발자에 위협받고 있는 한국 개발자 자리와 관련해서, 가격경쟁력은 부족하지만 자신만의 뛰어난 개발능력을 키움으로써 대비해야 한다는 이야기가 인상깊었습니다. 또한 스프링을 사용하면서 또는 공부하면서 얻을 수 있는 이점들에 대한 소개가 있었습니다. KSUG에서 세미나도 꾸준히 개최하고 있다는 소식도 들을 수 있었는데요, 스프링에 관심있는 분들은 세미나에 참석하는 일도 좋아 보였습니다.


애석하게도 경품에는 당첨되지 못했습니다. 좋은 강연을 듣게 되어서 좋았고,
내년 오픈소스 컨퍼런스도 기대해 봅니다.

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 세 번째 만남을 기대합니다.

한국소프트웨어진흥원(8호선 가락시장 역 근처) 5층 강당에서 9월 23일 "웹 환경과 오피스 파일 포맷 활용 세미나"가 있었습니다. 웹 환경에 대한 이야기는 상대적으로 적게 나왔지만, 근래에 Microsoft가 주도하는 OOXML이 ISO 표준으로 등록되느냐 마냐에 따른 문제로 인해 오피스 파일 포맷에 대해 관심이 높아진 상태였습니다. OASIS에서 제안한 ODF는 이미 ISO 표준으로 제정되어 있는 상태입니다.

"우리오피스"를 개발 중이시라는, 테크다임의 대표이사님께서 ODF의 특징에 대해 설명해 주셨는데요, 차분한 진행이 인상적이었습니다. 특정회사에 의존하는 바이너리 포맷이 아닌, 투명한 XML 포맷의 ODF 규격을 사용함으로써 오피스 파일 포맷이 중립성을 지키도록 할 수 있다고 하셨습니다. 특정한 바이너리를 위해 그에 맞는 상용 에디터를 구매하지 않아도, 누구에게나 열린 문서를 작업할 수 있는 환경이 와야한다는 점에서 공감되었습니다.

그 다음에는 한글과컴퓨터에서 오신 남동선 팀장님이 ODF 및 XML 활용방안에 대해 이야기 해 주셨습니다. 처음 서두를 꺼내실 때, .hwpml에 대한 이야기를 해 주셨는데요. 저는 예전에 아래아한글을 쓰면서 이 저장형식을 보고, 왜 이런 게 있을까 궁금했는데 기업이나 정부기관 등에서 정보를 효율적으로 검색하고 색인하려면 마크업 언어를 쓰는 게 좋다고 들은 기억이 납니다. ODF를 지원하는 에디터들 사이에서 명확한 지침이 없어서 어떤 ODF 에디터로 저장한 문서를 다른 ODF 에디터로 열었더니 모습이 달라지는, 그러한 문제가 해결되어야 한다고 하셨습니다.

마지막으로 "문서 표준의 국제 표준 선정 과정"이라는 주제로 기술표준원 강영식 연구사님이 오셔서 설명해 주셨습니다. 국제 표준을 정하는 일이기 때문에, 각 나라의 총의(Consensus)를 모으는 일이 중요하다고 하셨습니다. OOXML에 대해서는 이번에 부결되었다고 끝나는 것이 아니라, 반대 표를 던진 국가들이 왜 OOXML을 반대하는지 Commentary를 내는데 이 Commentary를 제안자인 ECMA 측에서 검토하여 수정할 기간을 주고, 그 다음에 다시 투표를 한다고 합니다. 만일 Commentary의 내용이 고스란히 반영되었다면 반대표를 던진 국가 측에서는 그 표준에 반대할 이유가 (문서상으로는) 사라지게 됩니다.

OOXML의 ISO 표준 투표에 대해 서명운동도 온라인에서 일어났는데, 연구사님의 말에 의하면 표준에 대한 서명보다 OOXML이 왜 표준으로서 부적합한지 이유를 설명하는 게 표준 적합성을 검토하는 사람들에게는 더 도움이 된다고 합니다. 저도 이 관점이 옳다고 봅니다. 특정 기업이기 때문이 아니라, 이것이 표준으로서 적합하느냐 아니냐를 보는 것이 표준원에서 바라봐야 하는 관점이겠지요. 더불어 표준에 대한 검토를 맡고 있는 전문위원회에 여러 전문가 분들이 활발하게 참여할 것을 독려해야 한다는 말씀도 했습니다. 주제가 개인적으로 흥미로웠고, 가장 질문이 많이 있었던 세션이기도 했습니다.

이미 국제표준으로 지정된 것은, 국제표준 고유번호 앞에 'KS^[각주:1](분류 기호)'를 붙여서 국내표준에도 도입하는 규정이 WTO 우루과이 라운드에서 있다고 합니다. 국제표준을 준수하지 않음으로써, 무역장벽을 세우지 않게 하기 위한 의도라는데요. 이런 사실을 전에 모르고 있던 상태라, 많이 배우게 되엇습니다. 따라서 현재 ODF는 국제표준이 된 상태이기 때문에, KS 표준으로도 만들어져 있다고 합니다. 이런 표준에 대한 문서들은 ISO에서 영문으로 만들고, 배송을 요청하려면 다소 큰 비용을 지불해야 하는데 KS 표준으로 구입하면 번역된 채로 저렴하게 구입할 수 있다고 합니다.

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

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

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

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