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

다니엘 핑크의 "후회의 재발견", 원제는 "Power of Regret"[1]. 신철님 진원님께서 추천해 주셨던 것으로 기억하여 바로 주문하여 책을 받아서, Reading less를 시도해 보았다.

우리는 우리 의지대로 될 것이라는 "자유 의지"와 모든 일에는 이유가 있다는 "환경"의 교차점에 살고 있다고 저자는 이야기 한다. 여기서 불행이 발생했을 때, 거기서 부터 구원의 시퀀스(redemption sequence)로 가는지 아니면 다른 방향으로 오염 시퀀스(contamination sequence)가는지 이 두 가지 경우가 서로 우위를 차지하기 위해서 경합을 벌인다고 한다. 마치 디즈니의 인사이드 아웃에서 예전의 슬픈 기억도 가족들과 이겨내는 시퀀스가 연결될 것인지 아니면 거기에 머무를 것인지 바뀌기도 하는 것도 이와 관련되어 보인다.

저자는 또한, 스포츠에서 2위 선수의 내가 조금 더 "했더라면" 1위 했을 텐데라는 입장과 3위 선수가 "적어도" 4위를 하지 않아 메달을 땄다라는 것에서 누가 더 만족하고 있는가에 대한 차이도 이야기 한다. 그러면서, 감정을 바라보는 두 관점에 대해서 이야기 하는데, "무시해야 할 것"과 "중요한 것"이라는 입장에 대해서도 설명한다. 무시할 것이라는 입장은 감정을 묻어 두면 결국 직면해야 할 순간을 유예하는 것 뿐이라고 이야기 한다. 또한, "중요한 것"이라는 것은 감정이 우리 존재의 본질이라고 생각하고 "항상 자신의 감정을 믿어라"라고 이야기 한다. 나 예전에는 전자의 입장이었지만 후자의 입장을 가지고 있다.

저자는 책에서 위에 이야기 한 두 방법 이외에 새로운 접근 방법을 제안 한다. 그 감정에 대해서 "생각"을 보태어 "행동"으로 보다 나은 향샹된 성과와 보다 깊은 의미를 찾도록 하는 다른 접근 방법을 제시한다. 이것을 후회 최적화 프레임워크라고 부르고 있다.

참고

[1] 다니엘 핑크, "후회의 재발견 - 더 나은 나를 만드는, 가장 불쾌한 감정의 힘에 대하여", 김명철 (옮긴이) 한국경제신문

"복잡하지만 단순하게(Simply Complexity)"[1], 이 책은 복잡계 삼인방이 읽은 책 중 단 한 권만 골라 추천할 것이라는데 동의한 책이다. 어려운 내용을 꿰뚫는 정리와 다양한 사례가 포함되어 다양한 분야의 사람들이 흥미를 가지고 살펴볼 수 있는 책이다. 많은 복잡계 책이 다루고 있는 바이러스, 도시, 전쟁, 물리학 그리고 금융에서의 다양한 사례가 설명되어 있다.

이 책에서는 여러 책에서도 채용하고 있는 복잡성 과학 정의를 채용하는데, "상호작용"하는 "개체"들의 집합에서 "창발"하는 현상에 대한 연구가 그 것이다. 사실 복잡계가 무엇이라 정의하는 것 보다는 우리가 보는 "현상"을 가지고 정의하는 것이 흥미롭다. 또한, 흥미로운 것은 현실 세계에서의 복잡성 사례 대부분은, 여러 존재들이 식량, 공간, 에너지, 권력, 부 등 "한정된 자원을 놓고 경쟁하는 상황"이 핵심이라고 지적하고 있는 것이다. 나는 이 부분이 가장 다른 책들과 다른 부분이라 생각한다.

좀 더 상세한 복잡계의 특징은 다음과 같다.
1. 복잡계는 다수의 상호작용 하는 개체, 또는 행위자(agent)의 집합체를 포함한다.
2. 개체들의 행태는 '기억' 또는 '되먹임'에 의해 영향을 받는다. 과거가 현재의 의사결정에 되먹임(feedback)되었다.
3. 객체들은 과거 이력에 따라 그들의 전략을 조정할 수 있다.
4. 복잡계는 일반적으로 '열려' 있다. 흥미로운 것은 대조적으로 우주는 닫혀 있다.

앞에서 언급한 복잡계가 "한정된 자원을 놓고 경쟁하는 상황"이라는 부분은 대부분의 복잡계 책에서 다루는 상황이다. 이 책이 특이한 부분은 이렇지 않은 경우에 대해서 연결, 즉 복잡계 네트워크 특징에 대해서 언급하는 부분이다. 즉, 자원이 많지 않은 집단에서의 네트워크는 집단 구성원 사이에 약간의 상호연결만 더해 줘도 성공적인 사람과 그렇지 못한 사람들 사이의 격차는 커지고 평균적인 성공률도 떨어진다고 한다. 예로 보면 후진국(60년대 한국, 멕시코 등)에서는 빈부 격차 확대, 독점 현상 발생하는 것을 살펴 볼 수 있다. 반대로는 자원이 풍부한 집단을 생각할 수 있다. 상호연결성이 낮으면 평균 성공율 높아지고, 대부분의 구성원이 성공하지만 상호연결성이 높으면 전체적인 공정성이 높아지고 성공율 격차가 작아진다.
선진국이라고 할 수 있는 유럽에서 이런 부분을 살펴 볼 수 있다.

7장 "교통 네트워크와 기업의 사다리"에서는 팀과 더글라스의 수레 바퀴에 비유하는 바퀴통-바퀴살 네트워크가 흥미로웠다. 이는 바퀴통에 해당하는 바깥 고리 위에서 바퀴살을 이용하여 두 점 사이 이동에 최단 이동 시간 계산하는 수학 이론이라고 할 수 있다. 여기서는 바퀴살, 즉 도로의 수 최적화 가능한 것에 대해 이야기한다.  흥미로운 것은 이 모델로 구한 답은 하나가 아닐 경우도 많다. 그렇다면, 어느것이 '정답'일까? 이 모델을 제안/적용하여 연구를 진행한 연구자들은 모두가 답이라는 의견이다.

9장에서는 앞에서 언급한 바퀴통-바퀴살 모델을 전쟁의 전략으로도 응용하고 있다. 비유로 늑대로 부터 양 때를 보호하는 개의 입장에서의 전략을 설명하고 있다. 이는 외부의 바퀴통에서 안의 바퀴통으로 가는 바퀴살의 숫자에 따라 다른 전략을 쓰는 것이 핵심이다. 우선 크게 공세적 방어와 수세적 방어로 나누어 이야기 한다. 공세적 방어는 개가 공격자를 공격함으로써 목표 대상을 방어하는 것이다. 이 것은 개, 양, 늑대의 수가 적을 수록 공격이 최선의 방어라는 측면이다. 늑대가 소수라면 추적하여 공격하는 것이 최선의 전략이라는 것이다. 수세적 방어라는 것은 보호 대상에 바싹 붙어서 방어하는 것이다. 보디가드가 VIP를 보호하는 방식과 유사하다 볼 수 있다. 이와 같이 적응적 전략이 유요할 수 있겠다.

앞에서 언급한 것처럼 복잡계의 정의, 사례 그리고 복잡계 네트워크까지 그리고, 자원의 다양성과 같은 상황에 따른 설명까지 폭넓은 시야를 제공하는 것이 이 책의 장점이다.

참고문헌

[1] 닐 존슨, "복잡하지만 단순하게 - 복잡한 세상에도 패턴은 있다", 한국복잡계학회 (옮긴이), 바다출판사 2020-02-24

들어가며...

Rust언어를 들어 보기는 했지만, 그나마 최근에 Linux 6.1에서 채용하기 시작한다는 기사[1]를 보고 다시 보기 시작했다. 최근에는 새롭게 시작한 프로젝트와 관련한 Open Source가 Rust를 채용하고 있어서 더 관심을 가지게 되었다. 최근에 살펴본 TIOBE Index[2]에서 보면 20위에 진입했다. 올해 말, 내년까지는 조금 씩은 보게 될 것이라 생각되니 익숙해 져보자는 생각에 이 것 저 것 뒤져 보다가, 바이블이라고 하는 The book[3]도 찾아 보고 읽어 보았다. 총 20장까지 있는데 현재는 10장 정도까지 어렵게 읽은 상태이다. 부족하지만, 기억나는 것을 정리하고 우선 멈추려고 한다. 이 후에, 정말 필요할 때 더 읽어 보려고 한다.

변수, 스코프 그리고 소유 

Hello World 프로그램을 보고 몇 가지 예제를 보고 가장 먼저 눈에 띄는 것은 mutable, immutable 개념이다. Rust에서는 변수를 만들면 값의 변경이 불가능한 immutable이 된다. 상수(constant)와는 다르다. 다시 같은 이름으로 선언할 수 있기 때문이다. 변경하기 위해서는 let mut x = 1;과 같이 mutable로 만들어야 한다. 쉐도우잉이라는 개념도 있는데 이는 Python등과 유사한 것 같다. 이는 같은 이름의 변수를 다시 선언해서 사용하는 것이다. 즉, let x = 1; let x = x +1;과 같이 사용한다는 것이다.

그 다음에 새로웠던 것이 소유권(Ownership)이다. Rust가 메모리 관리에 우수하다고 해서 Java 처럼 가비지 컬렉터가 있는가 했다. 하지만, 다른 방법으로 이 부분을 강화 했는데 그 중 하나가 소유권이라는 것이다. 이 것이 C나 다른 언어에서 알고 있는 스코프(Scope)과 관련이 있다. 즉, 변수의 Visibility와 관련된 것으로 같은 레벨이나 그 하위에서 보이는 것이라 알고 있을 것이다. 그런데, Rust에서는 Heap에 관리하는 변수의 경우 얕은 복사(Shallow Copy)의 경우는 같은 스코프라고 하더라도 유효하지 않을 수 있다.

또한 함수의 인자로 전달된 변수의 인자의 소유권이 넘어가 다시 복귀하게 되더라도 유효하지 않을 수 있다. 좀 더 상세히 이야기 하면, 메소드가 인자를 단순히 읽기만 하여 함수 처리 후 복귀했을 때 유효하기도 하다 (&self). 혹은 함수 내부에서 변형시키기도 하다(&mut self). 여전히 복귀 후에 사용이 가능하다. 아니면 소유권을 호출하는 함수에 넘겨 함수가 소비하고 함수 호출 이후에는 유효하지 않게 하기도 (self)한다. 즉, 인자를 어떻게 사용할지 결정론적으로 정하게 되는 것이다. 

Android와 Rust

Google도 Rust를 지원하는 큰 기업 중에 하나이고, Android에도 적용한다고 한다[4]. 이 부분도 관심과 시간을 가지고 살펴 볼 부분이다. Android에 Sandboxing이 도입되고 있음에도 메모리 관련 관리에 어려움이 있는 것[5]으로 보인다. 2019년도 부터 채용되고 있는 것으로 보아 조금이라도 적용되는 부분이 증가하지 않을까 생각된다. 

정리하며...

여전히 성능적 측면의 우려와 학습 곡선이 가파르다는 비판도 있는 것으로 보이지만, 2022년도에 Linux 커널에 도입되는 것을 보았을 때에는 추이를 계속 지켜봐야할 부분으로 보인다. 한국에서도 채용이 되고 있고 사용자 모임[5]이 있다. Discord도 상당히 활발해 보인다.

참고 내용

[1] Linus Torvalds: Rust will go into Linux 6.1, https://www.zdnet.com/article/linus-torvalds-rust-will-go-into-linux-6-1/?taid=6329bce71c8e3300010028ae&utm_campaign=trueAnthem%3A%20Trending%20Content&utm_medium=trueAnthem&utm_source=twitter

[2] TIOBE Index for November 2022, https://www.tiobe.com/tiobe-index/

[3] 러스트 공식 안내서 "The Rust Programming Language", https://rinthel.github.io/rust-lang-book-ko/ch00-00-introduction.html

[4] Android Rust 소개, https://source.android.com/docs/setup/build/rust/building-rust-modules/overview?hl=ko 

[5] Rust in Android Platform, https://security.googleblog.com/2021/04/rust-in-android-platform.html

[6] 한국 러스트 사용자 그룹, https://rust-kr.org/

정확한 연도가 기억이 나지 않는데, 강남의 러닝 스푼즈에서 OKR 과정을 듣고 페친이 된 분이 개설하신 성과 관리 워크샵을 들었다. 그 때도 CFR(Conversation, Feedback and Recognition)이었던 것 같은데 그 때 대표님이 교육생분과 했던 시연이 인상적으로 생각이 나고 참여한 사람들이 나에게 했던 칭찬 릴레이(?)로 느꼈던 그 때 감정이 기억이 난다. 이 때 부터 Personal OKR을 Bullet Journal의 형식에 적용해 사용해 왔었지만, 올해는 회사에서의 10개월 가량의 교육 과정으로 이 것과 업무 이외에는 다른 활동에 들인 에너지는 최소화될 수 밖에 없었다. 이러한 와중에 이 번 성과 관리 워크샵을 들은 후에 든 생각은, 이 과정을 선택한 것이 내년이 더 풍성할 수 밖에 없는 Good Start라고 이미 단정 지어도 될 것이라는 것이다. 이렇게 생각하는 이유는 다음 3가지 부분이다.
 
교육에서 무엇 보다도 가장 인상적이었던 부분은 Mission과 Vision에 대한 부분이다. 과정 중에 Mission과 Vision을 North Star와 North Pole에 비유해주신 부분이 너무 와 닿았다. 앞에서 언급한데로 올해는 내가 하고 싶었던 목표와 과정 측면에서는 모두 만족스러운 한해였지만 거기에 너무 함몰되었던 한해이기는 하다. 즉, 내가 가려는 방향은 잊고 내 목적지에 함몰하고 있다는 것을 깨닳게 한 것도 이 부분이다. 이런 상황에서는 아주 쉽게 길을 잃고 그 주변을 맴돌거나, 더 잘 못되면 잘못된 방향으로 길을 걸을 수도 있을 것 같다. 그러니, 기존에 잊고 있던 내가 잠시 잊고 있던 Mission/Vision 그리고 Goal, 즉 Objective와 느슨해 진 연결을 정비할 때가 된 것이다. 이러한 깨닳음이 지금의 나를 관통하고 지나가고 있다.

두 번째는 과정 중 MBO와 OKR에 대한 관점에 대한 들은 이야기는 기존의 나의 관점을 깨뜨렸기 때문이다. 얼마 전 후배와 식당에서 식사를 타기 위해 줄을 서 있으면서 한 잡담 중 했던 이야기가 생각난다. 자기 배우자와 자기가 너무 달라 힘들다는 이야기를 하면서 이런 저런 잡담을 할 때였다. 이 때 후배에게 했던 이야기를 짧게 줄이면  "정말 두 사람이 완전히 다르면 서로 관심도 없었을 것이다. 두 사람이 대부분 비슷하고 약간 다른 몇가지 때문에 다르게 보이는 것이다."라는 이야기이다. 즉, MBO와 OKR도 성과 관리라는 측면에서 보면 공통점이 많고, OKR이 성과 관리를 Agile하게 접근하는 것이라는 설명은 너무 인상적이었다. 결과적으로는 개인적으로 뿐 아니라, 회사 업무에서도 상위 목표들과 우리들의 Mission/Vision을 Align하는 것 그리고 구성원들을 여기에 더 참여시켜야 겠다는 Action Item으로 만들게 되었던 순간이었다.

세 번째는 상대를 인정하는 부분에 대한 것이다. 최근에 회사에서는 코칭 강의에서도 소개 받고, 기존에도 여러 번 들었던 이너 게임 책을 읽고 있다. 이와 더불이 같이 복잡계 공부하는 분 통해 알게된 동기 면담 과정도 참여했었다. 이 두가지와 성과 관린 워크샵에서도 약간 다르지만 비슷하게 들린 부분이 대화 상대방에 대한 태도에 대한 것이다. 물론 이너 게임은 나 자신에 대한 것이지만 나를 객관화 한다면, 혹은 이 이너 게임을 코칭의 개념으로 생각해 본다면 그 태도가 유사하다는 생각이다. 이 부분을 실행한다는 부분은 매우 어려운 점이라고 생각된다. 회사에서도 실재로 매우 격하게 느끼고 있던 부분이다. 그래도, 내가 실행해보고 싶은 부분이기도 하다. 내년에 내가 이 부분에 대해서 책에서 이야기 하는 것들을 발견할 수 있을 지 걱정되면서도 기대되는 부분이다. 

2022년이 2주 가량 남아 있는데 너무 큰 숙제가 남았는지도 모르겠다. 하지만, 그것이 힘들더라도 즐거울 것이라는 것은 의심의 여지가 별로 없다. 과정에 마지막에 느꼈던 것 처럼 동기(Motivation)이 뿜뿜일 것이라고 생각되기 때문이다.

복잡계 3인방 오프라인 모임을 가졌다. 무엇보다도 린다 라이징의 이야기가 나와서 반가웠다. 그러고는, YouTube에서 다니엘 커너만의 "생각에 대한 생각(Thinking, fast and slow)"에 대한 그녀의 발표 [1, 2]를 들었다. 무엇보다도 그녀의 문제 해결 접근법이 매우 인상적이었다.

1. 문제를 정의한다. 크게 이야기 해보고, 종이 위에 써본다.

2. 데이터가 충분한가?
3. 해결하기 위해 최소한의 시간을 투자한다. (1번과 2번의 내용을 조정하기 위해서 사용하기도 한다) 10분이 넘지 않게 한다.

4. 적절한 해결 방안이 나오지 않는다면, 그 일에서 손을 놓는다. 아마도 다음과 같은 일을 할 수도 있다.

    - 다른 작업을 한다.

    - 서거나, 앉거나, 스트레칭을 한다.

    - 짧은 휴식(bio break)을 취한다.

    - 긴 휴식을 취한다. (운동, 식사, 다른 용무, 수면)
5. 인사이트가 없다면, 위 단계를 반복한다.
6. 시스템 1은 항상 옳지는 않다. 시스템 2가 최종 결정을 하게 한다.

아마도 이미 많은 사람들이 사용하는 방법일 것이다. 특히, 4번의 경우는 이미 알려진 아이디어를 찾아내는 방법이라 할 수 있다. 그녀의 발표에도 있는 스티브 잡스의 "Let's go for a walk"라는 인용에서도 대가들의 이 도구 사용에 대해서 슬쩍 살펴 볼 수 있을 것이다. 송 나라 시대의 구양수의 시상을 생각하는 세 가지 장소인, 침상, 마상, 측상과 연결 되기도 한다. 누군가가 놀리고 웃을지도 모르지만, 어려운 문제를 만나게 되면 나도 사용하던 방법들이기도 하다.

참고

[1] Linda Rising, "Thinking, fast and slow" slides, https://agile2018.sched.com/event/EU9Z/thinking-fast-and-slow-so-what-can-we-do-about-it-linda-rising

[2] GOTO conference, Linda Rising, "Thinking, fast and slow", https://youtu.be/XjbTLIqnq-o

[3] Microsoft Research, Daniel Kanhmen, "Thinking, fast and slow", https://youtu.be/C-4MM8sd3BE

Waydroid는 Linux 기반의 기기에 Android를 Container로 동작케 한다. 리눅스만 설치 되며 쉬운데, 사실 리눅스 설치가 어렵다는 생각이 들었다. 여기서는 포인트와 참고할만한 싸이트를 정리해 두자.

1. Ubuntu 설정

Ubuntu는 현재(2022년 4월) Focal과 Hirsute를 지원한다고 한다. 우선은 설치를 해야 하고, 나는 외장 저장소(혹은 Micro SD를 메모리 형태로 가능)에 설치하는 방법을 정리해 둔다.

아래는 추천하지 않는 방법

1. ISO를 받아 USB로 부탕하여 시도하는 버전: lxc 등 설치가 되지 않고, binder에도 문제가 있어 권하지 않음.
2. Virtual Machine: 렌더링 성능이 나오지 않아 매우 느림 비추천.
3. WSL은 시도해 보지 않았지만, 아직 이슈가 많은 듯 (waydroid.io 참고하여 시도해볼지 확인할 것)

외장 메모리를 이용하여 Ubuntu 설치하기 위해, ISO로 만든 부팅 USB를 이용하여 부팅을 한다.

Terminal에서 gparted를 이용해서 외장 저장소(메모리 상관없음)를 사용하여 storage와 swap을 잡는다. [1]을 참조하면 된다.

관련된 몇가지 이슈가 있었는데 다음 링크를 참조하면 좋겠다.

1. 검은 화면으로 부팅이 안되는 경우: [2]
2. UEFI관련 이슈: 다시 설치할 때 부팅이 안되거나 아니면, Ubuntu 삭제시 참고 필요 내용 [3]

설치는 되었는데, Ubuntu 부팅을 하지 못하는 경우는 설치 장소를 못 찾는 경우이므로 USB로 외부 저장소를 잡아 볼 수있다. Wifi 안되는 경우도 있었는데, 이 부분은 커널 빌드가 필요하다고 하나, 시도 하지 않았다.

2. Waydroid 설정

Waydroid 설치[4]를 위한 관련 package (curl, lxc, ptyhon3, ca-certificates)를 설치한다.

Ubuntu 버전 (hirsute)를 찾아 아래에서 (bullseye)를 바꾸어 실행한다.

설치, init 그리고 container를 실행한다.

3. App store

F-droid와Aurora가 가능하다고 한다. apk를 받아서 설치한다[5].

4. 총평

Waydroid는 아직 불안하지만, 여러 앱이 동작한다는 부분에서는 충분히 멋지다. 특히, AOSP를 Open Source화 한 LeanageOS의 버전이 올라갈 수록 흥미로운 일일 것으로 보인다.

참고내용

[1] [4-2] 외장하드 SSD에 Ubuntu 16.04.1 LTS 설치하기, https://developer-thislee.tistory.com/12

[2] 우분투 USB 설치 블랙스크린 해결, https://arca.live/b/programmers/29170509

[3] 윈도우 EFI 파티션 마운트 및 수정하기, https://blog.djjproject.com/389

[4] Ubuntu/Debian Based Install Instructions, https://docs.waydro.id/usage/install-on-desktops#ubuntu-debian-based-install-instructions

[5] Install and Run Android Applications, https://docs.waydro.id/usage/install-and-run-android-applications

테크니컬 리더십(Technical Leadership) 

. 실용주의 프로그래머

. 피플웨어

. 테크니컬 리더

. 조엘 온 소프트웨어

. 스트브 워즈니악(iWoz)

. iCon

. 리눅스 그냥 재미로 (Just for Fun)

. 시장과 성당

. Geeks

. 스티브 잡스

애자일: 소프트웨어 장인 정신

. 소프트웨어 장인정신

. Clean Code

. Clean Coder

애자일: 소프트웨어 개발

. Extreme Programming

. Kanban

. Scrum

. 클린 소프트웨어(Agile Software Development, Principles, Patterns, and Practices)

애자일: 관련 이론 및 이야기

. 조직의 재창조

. 팀이 빠지기 쉬운 5가지 함정(신규 번역서: 팀워크의 부활)

. 커넥티드 컴퍼니

. ADAPT

. 린 스타트업

. 린 싱킹

. 디자인 싱킹

. 디자인 싱킹 바이블

. 드림팀의 악몽: 애자일로 뒤집기

관리자

. 매니지먼트 3.0

. 유능한 관리자

. 90일 안에 장악하라

. 존 도어 OKR

. 개발 7년차, 매니저 1년차

. 설득하지 말고, 납득하게 하라

동기 부여

. Grit

. 열정과 몰입의 방법

. Drive

소프트웨어 아키텍처 & 디자인

. 적정 소프트웨어 아키텍처

. Clean Architecture

. 소프트웨어 아키텍처 101

. 소프트웨어 아키텍처 이론과 실제

. 개발자에서 아키텍트로

. 디자인 패턴 (GoF)

. 해드 퍼스트 디자인 패턴

. 리팩터링

. 레거시 코드 활용 전략

복잡계(Complex System)

. 전체를 보는 방법

. 링크

. 스케일

. 성공의 공식 포뮬러

. 신호와 소음

. 슈퍼 예측

. 결정

. Cynefin (커네빈: 번역서 아직 없음)

소프트웨어 아키텍처 101: 3장의 모듈성.

그 안에서 추상도 불안전성에 관한 것에 대해서는 [2]에서도 언급함

여기서는 [1]에서의 커네이선스에 대해서 정리해 본다.

[1]

[2] Clean Architecture: 컴포넌트 원칙, https://technical-leader.tistory.com/75?category=1015398

공통점

로버트 마틴(이후 밥)은 밥 아저씨라는 별명으로 불리며 "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는 아주 의미있는 분야가 되었다.

소프트웨어 개발을 하는 사람으로서, 밥을 목표로 할 수 있다. 하지만, 그렇다면 실재로 업무를 수행하면서 죄책감을 느낄 수 있다. 그가 말하는 것은 내가 도달하기 어려운 이상향일 수 있다. 반대로 마틴을 목표로 할 수 있다. 내가 드디어 대가가 이야기 하는 것을 적용할 수 있을 것 같다. 하지만, 여전히 고객과 이해 관계자들에게 휘둘리다 보면 내가 정말 잘하고 있는 것인가 회의가 들기도 한다.

소프트웨어 개발을 하는 사람으로서 여러 분은 이 두사람에 가까울 수도 있거 좀 더 멀 수도 있다. 하지만, 이 두 사람을 좀 더 잘 이해하고 자신이 어떤지 고민하면서 성장한다면 그 또한 충분하지 않을까?

참고자료

[1] 로버트 마틴, "Clean Code 클린 코드 애자일 소프트웨어 장인 정신", 인사이트(insight), 박재호, 이해영 역
[2] 마틴 파울러, "리팩터링 2판 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기", 한빛미디어, 개앞맵시, 남기혁 역
[3] 애자일 소프트웨어 개발 선언, https://agilemanifesto.org/iso/ko/manifesto.html
[4] Extreme Programming, a Reflection, https://blog.cleancoder.com/uncle-bob/2013/12/10/Thankyou-Kent.html
[5] Flaccid Scrum, https://martinfowler.com/bliki/FlaccidScrum.html
[6] Manifesto for Software Craftmanship, https://manifesto.softwarecraftsmanship.org/
[7] What Software Craftsmanship is about, https://blog.cleancoder.com/uncle-bob/2011/01/17/software-craftsmanship-is-about.html
[8] Extreme Programming, https://martinfowler.com/bliki/ExtremeProgramming.html
[9] Aigle Software Guide, https://martinfowler.com/agile.html
[10] Robert C. Martin vs Martin Fowler, https://social.msdn.microsoft.com/Forums/en-US/4cdf6e1c-2f9a-46ca-b457-11d588d52850/robert-c-martin-vs-martin-fowler?forum=asparchitecture
[11] The Tragedy of Craftsmanship, https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html
[12] The Agile Fluency Model, https://martinfowler.com/articles/agileFluency.html
[13] 로버트 마틴, "클린 아키텍처 소프트웨어 구조와 설계의 원칙", 인사이트(insight), 송준이 역
[14] Is Design Dead?, https://martinfowler.com/articles/designDead.html