로버트 마틴(이후 밥)은 밥 아저씨라는 별명으로 불리며 "Clearn Code"[1]로 유명하다. 또한 마틴 파울러(이후 마틴) 하면 "Refactoring"[2]으로 유명하다. 이 두 사람은 많은 공통점을 가지고 있다. 앞에서 말한데로, 소프트웨어 개발자가 공부를 하다 보면 알게 되는 유명한 책의 저자이다.
둘다 애자일리스트이다. 즉, 애자일 소프트웨어 개발을 지지하는 사람들이다. 이 두 사람은 애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)[3], 소위 애자일 선언문(Agile Manifesto)에 서명한 17명에 포함되어 있다. 두 사람은 모두 애자일 소프트웨어 개발 중에서 의 가장 엔지니어링 실천법(engineering practices)에 집중하는 익스트림 프로그래밍(Extreme Programming, XP)의 추종자이다.
밥의 블로그인 The Clean Code Blog의 글[4]를 보면 그는 Extreme Programming(XP)을 지지하는 것을 알 수 있다. 그의 글이 2013년도 이고, 글에서도 15년 전 이야기라고 언급 하고 있으니 1998년도 즈음의 이야기를 회고(reflection)하면서 XP를 제외한 Scrum, Kanban 그리고 Lean에서 일어나고 있는 일들을 비판하고 있다. 그는 마틴의 축 늘어진 스크럼(Flaccid Scrum)[5]이라는 비판에 동의 하고 있다. 특히, 밥은 XP의 12개의 실천법 중에서 다른 애자일 신천법은 단 하나, 플래닝 게임(Planning Game, 소위 반복 Iteration)만을 도입하고 있다고 비판한다. 그는, XP를 넘어서 소프트웨어 장인 선언[6]을 지지하고 있다. 특히, 그의 블로그의 첫번 째 글[7]을 보면, "Clean Code"가 바로 이 소프트웨어 장인 정신을 실천하기 위한 것임을 알 수 있고, 그의 유명한 책[1]도 서문에서 부터 그 내용을 다루고 있다.
마틴의 웹페이지(martinfolwer.com)의 글[8]에서 알 수 있듯이, 그도 XP 추종자이다. 그는 XP와 관련된 책의 주요 저자인 켄트 벡(Kent Beck)과 함께 일하였다. 그 때, 켄트 벡에게서 리팩터링을 배우면서, 그의 유명한 책[2]으로 만들어 낸 것이다. 그의 웹페이지에는 주요 관심사로 보이는 항목들이 있다. 첫 번째가 리팩터링이고 두 번째가 애자일[9]이다. 여기서는 바로 그가 애자일에서 중요하다고 생각하는 부분이 드러난다.
"Agile Development is adaptive rather than predictive is people-oriented rather than process-oriented"
애자일이 예측(predictive)보다는 대응(adpative)하고, 프로세스에 기반(process-oriented)을 두기 보다는 사람에 기반(people-oriented)하다는 것이다. 특히, 나의 개인적인 경험으로도 후자가 매우 중요하다는 생각이 든다. 처음 커리어를 시작했을 때, Software Engineering을 전공하던 선배의 말이 아직도 기억이 난다. "설계 (문서)를 아주 꼼꼼하게(detail)하게 (작성)하면 코딩은 그냥 되는 거야". 이 말은 전형적인 프로세스 위주의 말이었다. 즉, 프로세스에서 필요로 하는 설계 문서를 만드는 것이었다. 내가 없어도 다른 사람이 프로세스의 산출물(artifact)인 그 문서가 중요한 것이었다. 거기에 사람은 없었다. 즉, 대체 가능한 것이었다.
차이점
밥과 마틴의 차이점에 대해 [10]에서 이야기를 하는 부분이 매우 인상적이다. 글을 쓴 사람이 Anonymous로 누가 작성한 것인지 모르지만, 매우 공감이 가는 부분이다. 한마디로 밥은 순수주의자(Purist) 그리고 마틴은 실용주의자(Progmatist)라고 한다. 밥이 정리한 OOP의 원칙인 SOLID 혹은 관심사 분리(seperation of concerns)와 같은 실천을 바라 보는 관점이 다르다.
밥은 실천이 원칙와 떨어져서는 안된다고 한다. 이러한 원칙은 법이다. 이를 지켜야만 한다는 것이다. 이것이 한마디로 소프트웨어 장인이다. 밥은 이러한 입장에서 마틴을 비판[11]하기도 한다.
마틴은 실천도 중요하지만, 원칙 혹은 가치가 더 중요하다고 한다. 이러한 실천은 모범 사례(Best Practice)이지 이해 관계자(고객)이 요구하는 실제 문제를 해결이 더 중요하다는 입장이다.
사실 두 사람의 블로그 및 웹페이지를 보면 애자일을 보는 관점에서도 차이가 난다. XP 추종자였던 둘은 이 관점에서도 달라진다. 밥은 애자일 선언문을 넘어서 더 소프트웨어 장인으로 갔고, 마틴은 엔지니어링 기반의 XP에서 애자일 개발에서 스크럼이나 칸반과 같은 다른 분야에도 관심을 보이면서, 애자일 능숙도 모델(Agile Fluency Model)[12]을 제안하기도 했다. 그는 XP도 능숙도 측면에서 4단계 중 2번 째 단계로 이야기 하고 있다. 여기서, 3단계 이 후는 린 스타트업과 같은 비지니스 및 조직 관점에서 차이가 난다고 이야기 하고 있다.
재미있는 부분은 두 사람 모두 소프트웨어 아키텍처에 관해서도 관심을 가지고 있다. 하지만, 둘의 입장에서 보는 아키텍처는 또한 다르다. 밥은 클린 아키텍처[13]에서 도달해야 하는 아키텍처의 모습을 제안한다. 마틴은 리팩터링이 그의 전문 분야인 만큼 기존에 초기에 충분한 시간을 들여 특정 기간(Phase)에서 설계하는 계획 설계(Planned Design)과 대비하여 애자일 개발에서 점진적인 개발에서 나오는 소프트웨어 설계 혹은 아키텍처가 진화적 설계(Evolutionary Design)이라고 했다[14].
결론
초창기 애자일의 경우, 학문적으로 인정 받기는 어려웠다. 하지만, 두 사람의 말대로 애자일은 주류가 되었고, 소프트웨어 엔지니어링 분야의 학계에서도 반복적 접근, 리팩터링, 테스트 기반 개발(TDD)와 같은 XP의 엔지니어링 실천법들이 학계에서도 받아 들여 지고 있다. 그런면에서 두 사람이 기반을 두고 있는 XP는 아주 의미있는 분야가 되었다.
소프트웨어 개발을 하는 사람으로서, 밥을 목표로 할 수 있다. 하지만, 그렇다면 실재로 업무를 수행하면서 죄책감을 느낄 수 있다. 그가 말하는 것은 내가 도달하기 어려운 이상향일 수 있다. 반대로 마틴을 목표로 할 수 있다. 내가 드디어 대가가 이야기 하는 것을 적용할 수 있을 것 같다. 하지만, 여전히 고객과 이해 관계자들에게 휘둘리다 보면 내가 정말 잘하고 있는 것인가 회의가 들기도 한다.
소프트웨어 개발을 하는 사람으로서 여러 분은 이 두사람에 가까울 수도 있거 좀 더 멀 수도 있다. 하지만, 이 두 사람을 좀 더 잘 이해하고 자신이 어떤지 고민하면서 성장한다면 그 또한 충분하지 않을까?
많은 종이책을 정리했지만, 여전히 활자로 보는 것과 전자책은 달라서 옆에 두고 보는 책이 여전히 많다. 낡은 책장을 반 이상 버려, 현재는 쌓아 놓는 책이 많아 정리하게 되었다.
정리하면서 내 나름의 분야로 분류해 봤을 때, 2가지 분야의 책이 가장 많다. 하나는 담당 업무에 대한 책 하나는 애자일 관련이다.
담당 업무 관련은 소프트웨어(Language, Algorithm), 설계(Object Oriented Design, SW Architecture), 네트워크(Computer network, Mobile network) 그리고 멀티미디어(Codec, Signal processing)가 그것이다.
애자일 책에는 방법론(Scrum, Kanban, Lean), 이론(복잡계, 팀, 리더십, 디자인 싱킹)이 그 아래 큰 분류라고 할 수 있다.
위에 모습은 당연한 것 처럼 보인다. 반대로, 의외인 부분은 역사 관련 책이다. 소설으로는 '삼국지', '한제국 건국사', '파운데이션'이 보인다.또한 '스티브 잡스'(영문판도 있다), 'iCon', 'Geeks', 'Just for Fun'과 같은 Nerd들의 이야기도 책장에 꽂혀 있다. '총균쇠', '역사의 역사', 심지어 아일랜드에서 구했던 Primary School에서 사용되는 History Textbook 3권을 보니 줄을 그어가며 보았던 부분이 보인다.
또 다른 흥미로운 것은 글쓰기를 포함한 공부에 관한 책이 좀 있다는 것이다. 아이 공부 관련도 있었겠지만, 그 전에도 자기 개발서 처럼내가 그런 책을 사모우고 있었다는 것이 흥미롭다.
고등학교 때 구해 가지고 있는 초판이 1980년이고 1989년 8판 책으로 가지고 있는 '혼비 영문법', 그 이후에 구해 가지고 있는 여러 영어 공부 방법에 대한 책과 최근 동명이인 고등학교 동창의 저작인 '영어는 개소리'도 이와 연결되어 있다고 생각된다.
자기조직화(Self-Organizing)은 자연 스러운 것이다. 옛말에도 삼인행이면 필유아서헌이라고 했다. 왜 2명도 4명도 아닌 3명이면 선생이 있을까? 2명이면 상호작용이 간단할 것이고 3명이 되면 상호작용이 복잡해 지면서, 자연스럽게 리더가 생긴다는 것으로 이해할 수 있다.
그런데, 애자일 방법론에서 왜 자기 조직화를 강조할까? 자연스럽고 효과적인 팀인데? 실재 조직에서는 이와는 다르게 인위적으로 Hierarchy를 만들기 때문에 Self-Organizing과는 괴리가 생길 수 있다. 그렇다면, 어떻게 운영하는 것이 좋을까?
마침, 인터넷에서 재미있는 글[1]을 찾아서 번역해 본다.
왜 자기 조직화 팀이 나은가?
많은 사람들이 자기조직화 팀의 개념에 대해 혼란스러워합니다. 그들은 무정부 상태와 동일시되거나 자기조직화를 자기 형성(self-forming), 자기주도(self-directed) 또는 자기관리(self-managing)와 혼동합니다. 자기 조직화란 무엇을 의미하며 다른 모든 용어와 어떻게 다른가요?
자기 조직화 팀이란 무엇입니까?
자기조직화 팀의 개념부터 시작하겠습니다. 이 용어는 2001년에 발표된 애자일 선언문 뒤에 있는 12 가지 애자일 원칙에 포함되었습니다.
"최고의 아키텍처, 요구 사항 및 디자인은 자기조직화 팀에서 나옵니다."
일부 사람들은 이를 다음과 같이 특성화합니다. 자기조직화 팀은 스스로 작업을 수행하고 프로세스를 관리하며 진행 상황을 모니터링하는 방법을 스스로 결정합니다. 저는 이것은 자기 관리 팀(Self-managed team)이 더 적절한 표현이라고 생각합니다. 저는 그것이 선언문의 저자들이 의미 한 것이라고 생각합니다. 팀의 문제는 "팀을 구성(Organize)하는 방법"이 아니라 "작업 방법(How)"을 파악하는 것이기 때문입니다.
마찬가지로 가장 최신 Scrum Guide[2]는 "자기조직화 팀"을 6번 언급합니다(2019/01/04에 확인한 결과 2번, Self-Organizing은 4번 언급합니다.). 이 용어가 팀 구성 방법이 아니라 팀이 작업을 수행하는 방법을 의미하고 있음이 분명합니다.
애자일과 스크럼에서 자기 조직화의 근원
2001년 애자일 선언문과 스크럼 가이드에서 자기조직화가 언급되었지만 실제로는 두 가지보다 이 용어가 먼저 나왔습니다. "자체 조직화"가 가장 먼저 사용된 곳 Scrum에 영감을 준 1996 년 HBR 기사 인 "The New Product Development Game"[3]으로 거슬러 올라갑니다. 이 기사에서는 자기조직화가 세 가지 주요 특징을 갖는 것으로 설명했습니다.
“그룹은 자율성(Autonomy), 자기 초월성(Self-transcendence) 및 교차 수정(Cross-fertilization)의 세 가지 조건을 보일 때 자기 조직화 능력을 보유합니다. 다양한 신제품 개발 팀에 대한 연구에서 우리는 세 가지 조건을 모두 발견했습니다."
자기조직화 팀의 수준
실제로, 자기 조직화는 온/오프와 같은 이진 개념이 아닙니다. 더 일반적인 구분 방법은 다른 수준의 자기조직화의 구성이 있다는 것입니다.
Richard Hackman은 자신의 저서 인 The Wisdom of Teams(아마도 [4]를 잘못 언급한 것으로 보임) 에서 자기 조직화를 살펴볼 수있는 유용한 프레임 워크를 제공합니다. Hackman은 누가 방향을 제시하는가, 누가 팀 구성원 구성을 디자인하는가, 누가 작업을 모니터링 및 관리하는가, 그리고 누가 실행하는가를 포함하여 팀 감독 및 관리를 위한 4 가지 요소를 살펴 봅니다. 아래 다이어그램에 표시된 것처럼 관리자(Manager) 또는 팀(Team)이 각 작업을 수행하는지에 따라 팀 이름이 다르게 지정됩니다.
Hackman의 프레임워크를 기반으로 작업하는 대부분의 Agile 및 Scrum 팀은 아래의 자체 관리 팀 범주에 속합니다.
Hackman의 프레임워크[1]
자기조직화 팀과 자기형성(Self-forming)의 약간의 혼동
나는 최근에 자기 조직화라는 용어를 자기형성 팀을 의미하는 것으로 해석 한 고객이있었습니다. 그들은 새로운 문제가 생길 때마다 조직 내 팀이 구성 될 것이라고 생각했습니다. Richard Hackman은 이를 자기설계 팀(Self-designing Team)을 호출합니다.
새로운 문제가 생길 때마다 고객이 자기설계 팀을 구성 할 수는 있지만 어떤 팀이 존재할 것인지 한 번만 결정할 가능성이 높습니다. 일반적으로 경영진은 어떤 팀이 필요하고 누가 팀을 구성 할 것인지 결정합니다.
그러나 관리자가 팀에 할당하지 않고 팀 구성원이 작업 할 팀을 결정할 수 있도록하여 민첩한 전환을 시작하기로 선택한 일부 조직이 있습니다. 권한 부여 및 의사 결정 및 팀 구성원이 그러한 결정을 내릴 수 있도록하는 것입니다.
저는 두 개의 다른 조직에서 팀의 자기형성(Self-forming) 연습을 촉진하는 특권을 가졌습니다. 팀 자체 구성은 개별 팀 구성원이 작업 할 팀을 선택할 수 있는 시점입니다. 이는 일반적으로 필요한 팀 비전과 필요한 작업 로그 및 원하는 팀 수를 설명하고 개별 팀 구성원이 팀을 구성하는 방법을 결정할 수있게하여 수행됩니다.
Ahmad Fahmy는 Bank of America에서 이러한 유형의 운동에 관한 훌륭한 기사[5]를 썼습니다. 벤 코펠 (Ben Kopel)은 시카고 스타트 업 업 테크 (Chicago Startup Uptake)에서 자체 선택 팀화 (self-selection teamification)[6]라고하는 유사한 운동에 관한 기사를 썼습니다. 이것을 볼 대, 아직 혼돈란을 해결하지 못한 것 같습니다.
무정부 상태(Anarchy) 아닌가요? 누가 책임자인가요?
어떤 사람들은 자기조직화가 무정부 상태와 같다고 생각합니다. 그들은 사람들이 실제로 옳은 일을 할 것이라고 믿지 않으며, 상황이 맞다면 그들에게 기대되는 것을 믿지 않습니다.
보다 전통적인 리더는 팀 전체를 다루기보다는 목을 조를 사람(The single throat to choke)[7]을 가지기를 기대합니다.
제 경험 상 이런 일이 결코 일어나지 않습니다. 팀에는 가이드 레일 위를 달립니다. 우선 순위는 프러덕트 오우너(Product Owner)가 설정합니다. 팀 구성원은 일반적으로 리더십(저는 경영층이나 중간 관리자라는 의미로 이해됩니다)에 의해 선택되며, 일반적으로 애자일 프레임워크 (예 : Scrum 또는 Kanban)도 설정합니다. 무정부 상태가 아닙니다.
참고문헌
[1] Why Self-Organizing Teams are Better, https://vitalitychicago.com/blog/why-self-organizing-team-are-better/
