brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Nov 19. 2021

낭비를 막고 팀을 만드는 XP의 가치

애자일을 습관으로 6

현실을 있는 그대로 보고 운전하기

XP에서 가치를 다루는 장을 읽을 때, 가장 먼저 밑줄을 친 부분에 아래 글이다.

내가 가치 있게 생각하는 것과 정말로 가치 있는 것 사이의 차이에서 낭비가 생긴다.

그리고, 이 글을 몇 년 만에 다시 읽었더니 그 사이에 읽은 팩트풀니스가 영향을 미쳐서 저자가 말한 우리가 사실(Fact)을 있는 그대로(factfullness) 인식하지 못하는 다양한 본능에 대해 떠오른다. (흥미가 있는 독자는 이 리스트를 훑어 보신 후에 책을 읽어 보시길 권한다.)


그렇다. XP는 낭비를 막는 운전 방법에 대한 글이다. XP는 팩트풀니스 저자와 가치관을 공유하는 듯한 부분이 있다. 있는 그대로 현실을 바라보는 힘은 훈련이 필요할 수 있다. 적어도 내게는 그렇다. 팩트풀니스 저자에 따르면 미디어가 호도하는 혹은 우리의 선천적인 본능이 이끄는대로 따라가다 보면 현실을 직시할 수 없다. XP에서는 이를 낭비로 풀어내며, 사실충실성 보다는 낭비에 민감하다. 소프트웨어 산업 초기에 벌어진 엄청난 낭비로 조직은 물론 이를 수행한 사람들에게 미친 나쁜 영향을 극복하는 방법으로 등장했기 때문이다. 덧붙일 이야기는 많지만 이 정도에서 마무리 하고, XP의 가치를 설명하는 문구 중에 인상 깊었던 내용 세 개를 더 살펴본다.


대체 뭐가 문제야?

아래 문장 탓에 '윌로저스 현상'이라는 말이 있다는 사실을 알았지만...

윌 로저스가 말한 것처럼 문제는 <중략> 잘못 아는 데서 생기지

낯선 인용구보다는 올바른 문제 정의 과정이 필요하다는 가르침을 준 인생책 <대체 뭐가 문제야>가 떠올랐다. 보통 우리가 안다고 생각했던 것이 사실과 다르거나 그 바탕이 다르거나 시간이 가면 달라질 수 있다. 게다가 우리의 기억은 매우 부정확하기도 하다. 안다고 믿었지만 막상 해보면 실천 방법은 전혀 모르는 경우 또한 허다하다. 그래서, 정확한 문제 정의 없이 해결책을 들이밀면 낭비로 이어지는 경우가 많다. 스스로도 이런 실수로 낭비를 한 일이 많지만, 주변에서 반복해서 이런 실수를 하는 모습을 본다. 아예 미신이 되어 말릴 수 없는 경우가 허다하다.

와인버그의 책과 XP의 연결지점은 바로 올바른 문제 정의 과정이 낭비를 막아주는 점에 있다. 개인적으로는 Kent Beck의 다른 저서인 TDD By Example에서 문제 정의 과정에 대한 인사이트를 받았지만, 개발자를 위한 책이라 모두에게 권할 수는 없다. 마침 이 글을 쓰는 시점에 XP에 정통한 김창준님이 TDD for Non-Programmers라는 프로그램을 소개하고 있으니 관심있는 분들은 참여가 가능하겠다.


개취인정(이든 뭐든) 극복하고 팀을 만들기

아래 문장을 읽고 독자들은 어떤 느낌을 받을까?

정작 중요한 것은 한 개인이 어떻게 행동하느냐가 아니라 그 개인이 팀의 일원이나 조직의 일원으로서 어떻게 행동하느냐다.

많은 사람들이 팀이 바뀌기 위해서 팀이 함께 움직여야 한다고 생각하는 경우가 많다. 하지만, XP는 그렇게 요구하지 않는다. 나는 2016년 중국에서 기적같은 경험을 했다. 골자만 이야기하면 한국에서 일할 때보다 실력이 형편없는 개발자들과 그것도 중국어를 못하는 내가, 절대 다수가 중국인인 개발 회사에서 서울에서 못했던 일들을 해낸 일이다. 일년 정도 흐른 후에 중국의 우리팀에 합류한 CTO님이 쓰신 글이 있지만, 내가 치밀한 계획이나 확고한 방법론을 갖고 일하지 않았다.


내가 아기발걸음이라고 부르며 '무어라도 가장 빠르게 만들어 가져오라'고 했던 행위와 지속적인 개선을 부르는 반복, 그리고 전체를 하나의 팀으로 보는 사고가 철저하게 지켰던 원칙이다. 시작할 때 개발 리더를 하겠다고 나선 동료가 가져온 (수많은) 기술 선택과 팀 구분을 없앴다. 그리고, 이렇게 분명하게 말했다.

기술은 가장 빠르게 실행할 수 있는 방법을 택하며 팀은 무조건 하나다.


해를 거듭하여 우리가 만드는 것이 복잡해지자 협업 강도가 높아지고, 나에게는 개취인정이 가장 고통스러운 덕목이었음을 말할 수 있다. 개취인정은 '진정한(?) 팀'을 얻기 위해 리더가 혹은 구성원들이 감수해야 할 덕목인지도 모른다.


신뢰와 맥락을 만드는 언어의 특징

가치를 설명하는 도입부에서 의사소통이 떠오르는 문장이 등장한다.

코딩 스타일에서 가장 중요한 문제는 팀이 공통된 스타일을 지향하고 있는지 여부다.

 XP는 어떤 면에서는 교과서의 르네상스 설명에서 들어봤음직한 인간성 회복에 대한 이야기가 자주 나온다. XP 책을 끝까지 읽어 저자가 테일러주의를 극복하고자 했던 XP의 철학을 이해하면 짐작할 수 있지만, 개발 방법론으로 처음 XP 책을 펼쳤을 때는 이를 알 수 없었기 때문에 르네상스 시대 특징이 떠올랐다.


돌아보면 성과를 내기 위해 거친 말을 서슴지 않고 살았다. 그렇기에 습관이 되어 버린 말버릇을 고치기 위해 노력하면서 신뢰를 만드는 언어가 갖는 특징을 배운다. 옳고 그르고가 우선하는 것이 아니라 공감이 먼저 이뤄져야 한다. 그리고, 한 팀이라는 맥락을 갖추기 위해서는 '가장 좋은' 무언가가 아니라 공통 요소를 키워가는 일이 중요하다.


애자일을 습관으로 이전 글 읽기


5. 나만 잘하면 전체가 나아지는 XP

4. 귀찮음 vs 정성 - 무엇이 빠졌을까?

3. 나의 애자일 정리: 안영회-gile

2. 소속감을 돕는 조직 만들기와 미션 분배

1. 협업 조직에서 함께 앉기 구현하기

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari