오래된 SW 엔지니어의 평생 공부

개요

애자일 서적 등에서 많이 사용되는 설명 방법 중 비유(Metaphor)가 있다. 가치와 원칙 관련한 글에서도 빙하 비유(Iceburg Metaphor)를 소개하기도 했다. 여기서는 여러 서적에서 사용한 정원 가꾸기 비유 관련 내용을 정리해 보려 한다. 정원사, 정원 가꾸기와 같은 비유는 일상에서 접하기 쉬운 내용을 통해서 애자일 이론을 쉽게 이해할 수 있는 설명 방법이기도 하다. 이러한 비유가 좋은 점 중에 하나는 비유는 그곳에서 이어지는 생각의 타래, 즉 더 깊은 이해로 가는 입구이기 때문이다.

"XP Explained"에서의 비유

익스트림 프로그래밍(Extream Programming, XP)은 내가 가장 처음 접한 애자일 개발 방법이었다. 짝 프로그래밍(Paired Programming)에 탐복하고 지금도 정말 익스트림(Extream)하게 개발과 배포를 동시에하는 데브옵스(DevOps)와 같은 맥락의 지속 통합(Continous Integration)의 개념을 소개했던 방법론이었다. 무엇 보다도 프로젝트의 일정과 목표도 중요하지만, 개발자 중심으로 관점을 바꾸게 해준 중요한 방법론이었다.

XP Explained(한국에는 익스트림 프로그램으로 번역[1])은 Manifesto for agile software development의 초기 서명자 중 한명이면서 JUnit으로도 유명한 Ken Beck이 저자인 책이다. 이 책에서는 운전하는 방법에 대한 비유도 있지만, 내가 처음 보았던 정원 가꾸기 비유가 포함되어 있다. 원본의 일부를 잠시 살펴 보면 다음과 같다.

No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a gardener. So it is with XP. Reading the book won't make you an extreme programmer. That only comes with programming in the extreme style, participating in the community of people who share these values and at least some of your practices sharing what you know with others.

애자일 해지기(Being Agile) 위해서는 책에 있는 이론만 한다거나 읽어서만은 안된다는 것이다. 실재로 실행(Practice)도 하고, 다른 애자일 커뮤니티에 참석하고, 애자일 방법론에 대해서 가르치기도 해야 한다. 그래야, 애자일리스트(Agilist)가 될 수 있다.

소프트웨어 장인정신에서의 비유

소프트웨어 장인정신[2][3]은 애자일 접근방법 중 개발자들의 역량을 강조하면서 나오는 활동 중에 하나이다. 많은 애자일 방법론에서는 훌륭한 동료들과 일하는 것을 강조하지만, 어떻게 훌륭한 개발자가 되는지에 대해서는 이야기 하고 있지 않다. 소프트웨어 장인[3]에서도 정원가꾸기에 비유가 있다. 여기서는 코드 개발하는 것이 정원 가꾸기와 유사하다고 설명하고 있다.

Code is organic, not mechanical. Like a garden, code needs constant maintenance. Look after its soil, Remove weeds, Water it, Remove dead plants, plant new ones, and trim or rearrange existing to make healthy, looking nice and whole. With basic and regular maintenance, the garden will always look great if we neglect it, it will require much more effort to make it look good again. Code is no different. we don’t look after it constantly, the code starts to deteriorate as changes and new features are added. Bad design choices, lack of tests, and poor use of languages and tools will make the code rot faster. Gradually, other parts of the code will also be contaminated up to the point that the whole code base is extremely ill, making it painful and costly to maintain it.

소프트웨어 제품을 만들 때, 계속 새로운 기능만 추가 하는 것이 고객을 만족시키는 일이 아닐 것이다. 잡초도 제거하고 물도 주고, 죽은 화초들은 제거하고 새로운 화초를 심기도 해야 한다. 단순히 코드라고 했지만, 소프트웨어 제품으로 본다면 정말 크고 훌륭하게 관리되어 사람들이 돈을 지불하고 관람하는 식물원과 같은 수준을 고려한다면, 어떻게 관리하여야 할지 생각해 볼일이다.

맨먼스 미신에서의 비유

맨먼스 미신은 후배의 책장에 꼽혀 있던 책으로 처음 접했다. 어디선가 보았던 제목이지만, 잠시 펼쳐 보았을 때에는 저자의 내공이 느껴지는 오래된 책이었다. 역시 다시 검색해 보니, 1975년의 책이다. 한글판은 번역이 된지는 얼마 되지 않았다. 이 책에 포함된 점진적 개발(Incremental Development)에서는 소프트웨어를 살아있는 생물에 비유 했다. 그래서, 구축(Build)하는 것이 아니고 키우는(Grow)한다고 이야기 하고 있다. 오래된 책이지만, 현재에도 통용될만한 지혜를 전달하고 있다고 할 수 있다.

So it must be with our software systems (In other words, software system is similar to complex system such as living things). Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions. 

피플웨어에서의 비유

피플웨어[5]에서는 팀 빌딩을을 농업(Argiculture)로 비유 한다.

We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn’t entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop; you might not. If it all comes up roses, you’ll feel fine, but next year you’ll be sweating it out again. That’s pretty close to how team formation works. 

농업에서 전체를 통제하지 못한다. 대신, 근간이 되는 토양을 푸엉하게 하고, 씨를 뿌리고, 이론에 따라 물도 주고 가꾼다. 하지만, 어떻게 될지는 숨죽이고 기다리는 수 밖에 없다. 수확이 있을 때도 있지만, 그렇지 않을 때도 있다. 안되었다고, 실망하고 있을수만은 없다. 왜 그랬는지 고민도 해야 하지만, 결국 다시 시도해 보는 것이 정답일 것이다.

매니지먼트 3.0에서의 비유

매니지먼트 3.0[6]에서도 조직관련해서 정원에 비유를 제공하고 있다.

. Living systems grow fast in the beginning and then reach a level of maturity. Mature systems don’t need to be looked after as often as the young systems.
. When a garden is not managed, it will simply keep growing but in another direction than what was intended. It’s the same with software systems and teams.
. Many growing systems have a certain life expectancy. They have a tendency to wither away and die.

생명체가 가지는 특징을 소프트웨어 혹은 조직이 유사하게 가진다는 것이다. 처음 태어났을 때, 급격히 성장하고 성숙하게 된다는 것이다. 또한, 관리하지 않으면 원하는 방향으로 발전하지 못한다는 것이다. 생명체와 같이 마지막에는 죽음을 맞이한다는 경향을 설명한다.

또한, 개발자와 관리자가 정원사와 같이 해야 하는 활동도 설명하고 있다.

. Seed, feed, and nurture the systems
. Young systems need more care than mature ones.
. Weed out everything that draws energy away from our healthy growing systems
. When the time has come, we recognize when to replace the old with the new.

정원에 있는 식물의 생명 주기를 알고 시기에 맞는 관리를 해주고, 필요한 교체 시점 또한 파악해야 한다는 것을 이야기 한다.

정리하면서...

정원의 비유는 소프트웨어 제품, 소프트웨어 개발 조직에 대해서 이해하기 쉬우면서도 명료하게 특징을 잘 설명해 준다. 하지만, 이 비유만으로 모든 것이 설명되지는 않는다. 기본적으로 애자일 이론들과 더 나아가서는 소프트웨어와 개발 조직이 복잡 시스템(Complex System)임을 이해 해야 한다는 것을 한번 더 깨닫게 한다.

참고 문헌

[1] 익스트림 프로그래밍 (Extreme Programming) - 변화를 포용하라 2판, 켄트 벡,신시아 안드레스 저/ 정지호, 김창준 역, 2006년 7월

[2] Manifesto for Software Craftsmanship, http://manifesto.softwarecraftsmanship.org/#/en

[3] 소프트웨어 장인 프로페셔널리즘, 실용주의, 자부심, 산드로 만쿠소 저 / 권오인 역, 길벗, 2015년 09월 25일

[4] 맨먼스 미신, 프레더릭 브룩스 저 / 강중빈 역, 인사이트(insight), 2015년 03월 23일

[5] 피플웨어 3판, 톰 드마르코, 티모시 리스터 공저 / 박재호, 이해영 공역, 인사이트(insight), 2014년 07월 15일

[6] 매니지먼트 3.0 - 새로운 시대, 애자일 조직을 위한 새로운 리더십, 위르헌 아펄로/조승빈 역, 에이콘출판, 2018년12월 27일