힘껏 차라

‘나는 저렴한 비용으로 신속하고 완벽하게 개발할 수 있지요. 이들 중 두 가지만 고르세요’ – 스콧 로젠버그의 <드리밍 인 코드>, 150p

프로젝트 단계에서는 주로 앞의 두 개가 압박한다. 하지만 운영 시점에서 고객은 기어코 그토록 빼어들고 싶어 안달나하던  ’완벽’ 이라는 숨은 카드를 내놓는다. 이건 개발자가 이길 가능성이 거의 없어 보이는 게임이다.

“미키 마우스는 지금까지 세상에 나온 것들 중에서 가장 저열한 모델이다. … 독립심 강하며 명예를 아는, 건전한 정서를 지닌 젊은이라면 동물 세계 최대의 보균자인 이 더럽고 오물로 뒤덮인 동물이 동물의 이상형이 될 수 없음을 깨달을 것이다. … 인류에 대한 유태인의 야만 행위를 타도하자! 미키 마우스를 타도하자! 철십자를 가슴에 꽂아라!”

- 1930년대 중반, 독일, <포메라니아>지의 신문기사

번역판 나온지도 10년이 넘은 아트 슈피겔만의 ‘쥐’라는 만화책을 얼마 전에서야 회사 동료 추천으로 읽었다. 감상평이라도 적어야지 해놓곤 차일피일 미루다 기억 한 편으로 거의 넘어가려던 참에 오늘 ‘서울 한복판 쥐와의 전쟁’, ‘OECD 국가 맞나? 서울서 `쥐잡기 운동`’ 등의 기사들이 포탈 메인에 떴다는 얘길 전해 듣고는 책 앞 장 다시 한 번 들춰보았다(왜? 아무 이유없어 … 아니 그냥 거시기 ‘쥐’ 때문에 …).

‘쥐’라고 불리우는 한 사내 때문에 책 제목만 보고도 경끼 일으킬 분들 있을지 몰라 조심스럽긴 하지만 이 만화책 심하게 추천한다.

p.s : 황금색 순종 포메가 순수 아리아인들의 상징인건가? 아무튼 다행이다 우리 뭉구는 잡종 포메라서.

그간 우리에게 Agile 은 곧 XP 였고 Agile 관련 서적도 XP 일색이었다.

그렇게 접한 XP 의 실천 기법들을 실험적으로 소규모 팀 단위에서 적용해보면서 XP 자체에 대한 고민들이 조금씩 고개를 쳐들었다.

- XP 란 이름에 담긴 ‘Extreme’에 대한 심리적 저항을 어떻게 극복할 것인가?

- XP 적인 실천을 통해 얻어진 가치들을 어떻게 조직적인 차원으로 확대, 고양시킬 것인가?

뒤늦게 Scrum 서적(켄 슈와버, 마이크 비들 저 ‘스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론’)이 번역되어 나왔고, 그 책을 또 조금 늦게 이제사 읽었다.

생경한 용어들이 몇 나오지만 의미상 유사한 개념들도 꽤 되고 XP 를 통해서 이미 접했던 기법들이 많이 있어 내용이 그닥 생소치는 않다. 아니 당신이 개발자라면 오히려 뭔지 먹은것 같긴한데 씹는 느낌은 없었다 싶을지도 모르겠다.

왜일까?

스크럼은 XP 에서처럼 엔지니어링적인 기법들이 구체적으로 정의되어 있지도 않으며 XP 만큼 ‘Extreme’하지도 않아 보인다. 다시말해 XP 란 센 맛부터 본 이들에게 이 책을 통해 본 스크럼은 그것에 비해 조금은 밋밋하고 덜 부담스럽고, 덜 공학적일게다.

느지막이 다가온(번역된) 이 밋밋함의 의미는 과연 무엇일까?

XP 를 현장에 적용하는 과정에서 떠올렸던 질문들을 스크럼을 향해 던져보자.

- 럭비에서 가져온 메타포인 이름 자체가 ‘Extreme’ 에 비해서는 훨씬 평범하며 덜 부담스럽다. 변화에 대한 저항을 극복하기 위해 ‘Extreme’한 충격 요법만이 있는 것은 아닐게다.

- 스크럼은 복잡계 이론에서 차용한 ‘자기 조직화 체계’란 개념을 이용해서 개별적인 가치들을 어떻게 조직적인 차원으로 확대, 고양시킬 수 있을지에 대한 실마리를 제시하고 있다(가령 열린 시스템, 역동성, 밀도있는 국소 상호작용 등의 개념들을 통해 ‘알아서 행동하는 독립적인 개체’로서의 ‘행위자’들 개개의 지식들이 어떻게 교환, 확산되는지 그리고 ‘창발성’이란 것에 의해 어떻게 행위자 자신 및 조직이 고양될 수 있는지 등에 설명하고 있는 장들을 살펴보라)

다시 XP 로 시선 돌려 이런 질문을 해보자. 애초의 질문이 XP 의 단점이나 한계를 드러내는 것인가?

글쎄, 현장에서의 고민, 시행 착오 속에서 우리 스스로가 성장하고 있다는 반증은 아닐까? 이제사 스크럼에 관한 책이 번역되어 나온 것 역시 이것의 현상 아닐까?

(역서 계기로 스크럼의 현재적 가치를 XP 실천 기법 중심으로 사고되고 진행되었던 우리 프로젝트 현실에서 뽑아보려 했었던 듯 한데 지금 다시 읽어보니 미친 X 널뛰기 하듯 그냥 팩 꼬꾸라져버렸다. 애초 생각 다시 풀어볼까 했지만 그러려면 원글 꽤 헤풀어야할 듯 싶어 그 부분은 숙제로 남기고 중간 얘기없이 지 혼자 멀찍이 꼬꾸라진 부분만 지운다)

이제 책 자체로 돌아와보자.

날 추워서 버스로 출근하는 날에 쉬엄쉬엄 읽어보았는데 여러 Agile 방법론 중 MS 에서 가장 많이 사용되는 방법론이란 것 외에 아는 것 없던 상태에서도 그리 오래 걸리지 않아 읽을 수 있을 정도의 부담없는 책이다.

- 스크럼의 기틀을 다지는데 중요한 역할을 한 책이라지만 나온지 이미 오래 되었다. 팀의 가치에서 언급된 ‘공진(coevolving)’의 개념은 스크럼 자체에도 적용되어질 수 밖에 없는 가치이다. 결국 저자가 스크럼의 과제로 뽑은 스크럼의 조직 패턴과 XP 기술의 견고한 통합 등은 이 후의 다른 책에서 확인할 수 밖에 없다.

- 방법론의 틀 정립해나가는 과정의 고민이 책 구성 자체에 영향을 미치고 있는 듯 느껴지는데 이런 구성을 따라가는 독서가 스크럼 자체의 이해에 얼마나 효과적일지 잘 모르겠다.

당장은 몇 권의 스크럼 책들 더 읽은 후 이 책 가치 다시 언급할 때가 있게 되리라 생각하지만  (XP 에 대한 국내 첫 역서였던 것으로 기억하는데) 론 제프리의 ‘XP Installed’ 를 읽고 뭔가 환해지던 느낌과 동시에 숱한 질문들 이어지던 때의 느낌, 그 충격을 기억하는 이라면 충분히 읽어볼만한 책이리라 싶다 ( 특히나 스탠드 업 미팅이 왠지 관성화되고 있다고 느껴지는 리더라면 꼭 … )

p.s :

1. 밥 아저씨가 추천사에서 “우리는 일을 통해서 자신의 고양을 경험할 수 있고, 또 그래야만 한다”라고 이 책 시작된다고 했는데 시작 장에서 이 문구 아무리 눈 씻고 찾아봐도 못 찾겠더라.

2. ‘왜 스크럼은 통할까?’ 가 아마 가장 이견 많은 장일 것이다. 스크럼 자체를 이해하는 데에는 읽어도 그만 안 읽어도 그만인 내용이다. 하지만 Agile 방법론의 사상적 배경이나 이 후 확장 방향 등에 대해 알고 싶다면 꽤 도움을 줄 수도 있는 내용이다. 이 책에 필요한 내용였을까, 아닐까?

3. 인싸이트 이벤트 도전해볼 량으로 예전 글 다시 트랙백만 추가해 올릴려다 심히 낯 부끄러워 몇몇 이음새 손질하고 글 전개에서 뜬금없이 날아다닌 부분 삭제 또는 스트라이크 처리하고 다시 올린다.

윌리엄 진서가 ‘글쓰기 생각쓰기(원제 : On Writing Well)’ 개정판을 또다시 쓰게 된다면 빌 브라이슨의 ‘발칙한 유럽산책’ 을 ‘여행기: 장소에 대한 글쓰기’의 예문으로 인용할거라는 상상을 해본다.

진서는 장소에 대해 잘 쓰는 두 가지 원칙으로 문체와 내용을 꼽는다.

이 원칙들을 설명하며 이야기하는 것들이 이런 것들이다.

단어 선택에 주의하자. 어떤 문구가 금방 떠오른다면 깊이 회의해보자. … 경이로운 광경을 묘사하기 위해 찬란하고 서정적인 문구를 짜내려고 애쓰지 말자. … 참신한 단어와 이미지를 찾도록 노력하자.
…
내용도 주의 깊게 가려 쓰자. … 잘 알려진 사실은 모두 지워버리자.   - 96, 97p,  ’글쓰기 생각하기’ 중
 

진서가 꼽은 원칙과 예문들 보고나면 브라이슨의 이 책이 여행기에 대한 글쓰기 교본으로 꽤 괜찮은 책임을 충분히 확신할 수 있으리라 믿는다. 

…

뭐에 휘둘려 그 때는 ‘Far and Away’ 식의 여행을 했을까? 언제 다시 유럽에 가게될런지 모르겠지만 그 때는 이 진득함을 잊지 않으리라. 기둘려라 코펜하겐, 암스텔담아!

Head First Software Development

Head First Software Development – 더 쉽고 재미있게 소프트웨어를 개발하는 방법   

• 댄 필로네, 러스 마일즈 지음
• 이정룡, 조재혁, 황상철 옮김
• 한빛미디어

이런 주제를 설명하기 위해 Head First(이하 H.F) 시리즈를 선택한 것은 꽤 괜찮은 판단이었던 듯 싶다.

시리즈의 모든 책 앞 부분에 보면 H.F 학습 원리라는 것이 설명되어 있는데 이걸 조금만 들쳐봐도 이 주제와 시리즈가 얼마나 잘 어울리는지 확인할 수 있는데 가령

‘비주얼하게 만들자’ : 이 바닥 표현으로 진행 과정의 ‘가시성 확보’를 위해 단계별 산출물을 지정한다거나 인포메이션 대쉬보드 설치하는 것 등을 꼽을 수 있을거다(물론 현업에서 이것은 ‘학습 원리’라는 측면보다는 ‘운영 원리’에 가깝기는 하지만 ) . 하지만 뭐니 뭐니해도 칸반(Kanban)만큼 확실한 예도 없을거다. 칸반은 ‘비주얼’ 방식의 효과를 직접적으로 소프트웨어 개발에 적용이라고 할 수 있을 것이다.

‘개인적인 대화 형태의 문체를 사용하자’ : 책에도 소개된 ‘계획 포커 게임’처럼 애자일 방법론에서는 소프트웨어 개발 프로세스의 각 단계에서 필요한 작업들을 게임화하여 보다 친숙하며 사적인 행위로 변화시키려는 노력을 하고 있다. ‘스탠드업 미팅’ 등의 회의 문화에도 역시 이런 고려가 들어 있음은 두말하면 잔소리. 또다른 예로는 ‘사용자 스토리’를 들 수 있겠다. ‘요구사항 정의서’ 등과 비교해보면 이 역시 따로 설명 필요없을 듯.

이 외에도 두어가지 원리들이 더 나열되어 있는데 그 역시도 어렵지 않게 애자일 방법론의 철학이나 실천 기법들과 연관지어 더 풍부하게 설명할 수 있다.

원리에서 직접 언급되지는 않지만 H.F 의 구성 특징 중 하나는 일정한 스토리 라인을 가진다는 점이다. 이 책 역시 몇 명의 개발자와 고객을 등장시켜 계속 스토리를 끌고 나가고 있다.

이렇게 일정한 스토리 구조를 취하는 목적이야 쉽게 몇가지 유추해볼 수 있다.

H.F 학습 원리 중 네번째에서 언급되었듯 이 방식은 ‘독자가 계속해서 주의를 기울일 수 있도록’ 하는데 매우 유용한 방식이다. 더불어 적절하기만 하다면 독자에게 ‘현실감’ 또는 ‘공감’을 이끌어 내기도 좋고.

하지만 이런 방식을 채택하면서 저자들은 의도적으로 몇가지를 포기한 듯 보인다. 가령 ’다양성’과 뭣 좀 있어 보이듯 표현하자면 어떤 행위/기법 배경의 ‘철학’이나 ‘역사’ 등이 그것들이다.

이렇게 추정하는 몇가지 이유를 대보자면

테스팅을 설명하는 부분만 놓고 봐도 당장 수많은 단위 테스트/Mock 객체 테스트 프레임워크들이 있어서 현장에 적용하기 위해서는 선택을 위해 골머리를 한동안은 썩힐 수 밖에 없을거며 테스팅도 단위 테스트 뿐만 아니라 통합 테스트, 시스템 테스트, 인수 테스트 등 단계별로 다른 전략과 접근 방식, 시나리오가 필요할 수 밖에 없다. 그럼에도 이 책에서는 단위 테스트 위주로 TDD 정도만을 설명하고 있을 뿐이며 그도 jUnit 과 EasyMock 프레임워크 정도만을 언급하고 있을 뿐이다.

가능한 설명의 단순함을 추구한 경우도 다양성을 일정 포기한 예라고 할 수 있을텐데 그 경우가 지속적인 통합(CI) 챕터 아닌가 싶다. 이터레이션 크기/일정 추정하면서 추정치만 언급할 뿐 ‘스토리 점수’를 빼놓은 것도 설명의 단순화를 위한 건지 이 점은 좀 확신이 서지 않는다.

추정에 대해 얘기 나온 김에 더 이야기 해보자면 일정 추정을 위해서 이 책에서는 ‘스토리 카드’와 추정치, 속도 등을 이용하는 방법을 설명하고 있다. 하지만 당장 현업에서는 WBS 라는 방법을 사용하고 있는데 이에 대해서는 전혀 언급되고 있지 않다. 그 외에도 이 책에 설명된 다양한 실천 기법들은 나름 이전 개발 방법론의 문제를 극복하기 위해 개발 혹은 개선된 기법이지만 아직 그 이전 방식들이 끈끈하게 숨 이어가고 있는게 현실이고 그렇다면 책과 현실의 간극은 개발 방법론의 역사에 대한 이해가 필요할 수 밖에 없다. 하지만 이 책은 일절 이런 부분은 관심 두지 않고 있다. 또한 ‘철학’ 관련해서는 단적으로 대다수의 애자일 관련 책들에는 애자일 방법론의 철학이 농축되어 있는 애자인 연합의 선언문이 인용되어 있지만 이 책은 그런 부분 역시 생무시하고 있다.

이런 점에서 짝프로그래밍이나 코드 리뷰, 인스펙션 등에 대한 내용이 없는 이유를 ‘다양성’의 포기 측면에서 설명할 수도 있지만 ‘코드 공동 소유’라는 애자일 철학 측면과 연관해서 유추해볼 수도 있을 듯하다.

앞에서 ‘의도적’ 포기라고 한 것에서 어림 짐작할 수 있겠지만 나는 몇가지 주제의 생략을 저자들의 계획된 전략이라고 생각하며 그 연장선상에서 이런 점들이 개인적인 아쉬움을 넘어 이 책 내용의 ‘단점’으로 단정 지어져서는 안될거라고 생각한다.

어쩌다 책에서 주제를 다루는 방식과 다뤄지지 않은 주제들만 어줍짢게 언급했는데 그래도 이런 면만으로도 이 책을 어떻게 읽어야할지 누가 읽어야할지 어느 정도 가늠할 수 있지 않을까?

어쩌다 일정 늦었음에도 별 앙꼬없이 리뷰 길어졌는데 이쯤에서 간단히 책에 대한 느낌 두어줄 정도로 정리하면서 끝맺겠다.

많은 독자들이 이 책을 Head First Software Development 아닌 Head First Agile Development 라고 했어야 한다고 평들 하던데 충분히 동의하는바다. 그리고 덧붙이자면 애자일 방법론에 대해 충분히, 제대로 이해하는 것을 목적으로 하지않는 효과적으로 학습하려는 이 또는 팀에게 권할 수 있는 교재로는 꽤 괜찮은 선택일거라는 …

p.s : 시리즈 모든 책에서 계속 사용되는 ‘키치’ 광고에서 봄 직한 5,60년대 미 중산층 인물 사진의 의도는 무얼까? 이런 낯섬, 불편함, 지루함을 통해 발생하는 인지적 자극이 학습에 도움이 되기 때문일까? 어찌되었든 시리즈에 계속되는 이런 사진 패턴이 좀 지루해지기 시작했다.

이진경의 ‘사회구성체론과 사회과학방법론’이 다시 나온단다.

내 기억 속의 ‘사사방’은 보편과 특수, 구체 등의 개념 정립을 위한 철학, 인식론 텍스트였다(물론 이런 기억은 당시의 내 학습 방법과 소위 커리란 것의 영향이 크다).
이진경은 지금 ‘코뮨주의’를 이야기하고 있고 보편과 특수가 아닌 공통된 것(the common)과 특이한 것(the singular)이라는 코뮨의 구성 문제를 고민하고 있다.

그렇다면 ‘사사방’을 다시 내놓는다는 것은 소위 ‘이진경 주의’라는 것의 이해를 위해 그의 사상적 편력을 추적해볼만한 때가 되었다는 판단 때문에서인가?
우야튼 김편집장님 그 뚝심만큼은 멋지다(깐죽거리는거 아니고 진심으로 … )

과연 어떤 친구들이 읽고 블로그에 서평을 올릴지 사뭇 기대된다.

불확실성과 화해하는 프로젝트 추정과 계획

‘애초에 명시한 일정과 예산 그리고 기능 범위를 모두 만족시킨 프로젝트’ 를 성공적인 프로젝트라고 정의하는 것은 이 정의에 동원된 구성 요소들의 변경을 최대한 억제하거나 변경을 방어하는 행위의 집합을 프로젝트 관리라고 믿게끔 하는 방어적이며 소극적인 프레임을 활성화시키게 된다.
이에 비해

‘프로젝트를 시작할 때 정한 요구사항보다 더 나은 아이디어들이 개발 과정에서 전혀 나오지 않는 프로젝트가 실패한 프로젝트이다’ – ‘불확실성과 화해하는 프로젝트 추정과 계획’ 중에서

와 같은 정의는 변경을 적극적으로 수용하거나 더 나아가 변경을 추동하는 행위가 프로젝트 관리의 핵심이라고 여기게끔하는 주체적이며 활동적인 프레임을 활성화시킬 것이다.

Kent Beck 이 ‘계획은 필요악’과 비교하며 ‘계획은 가치를 추구하는 행위’을 추천사에서 언급한 것 역시 이런 까닭이리라.

Neil’s point-free blog » Book – OSGi in Practice

역시나 ‘침대와 책’ 중에서

진정한 행복은 이런 것인가? 야망이 없으면서도 세상의 야망은 다 품은 듯이 말처럼 뼈가 휘도록 일하는 것. 사람들에게서 멀리 떠나, 사람을 필요로 하지 않되 사람을 사랑하며 사는 것, 성탄절 잔치에 들러 진탕 먹고 마신 다음 잠든 사람들에게서 홀로 떨어져 별은 머리에 이고 뭍을 왼쪽, 바다를 오른쪽에 끼고 해변을 걷는 것… 그러다 문득 이 모든 것이 기적적으로 하나로 동화되었다는 것을 깨닫는 것… [그리스인 조르바] 중에서