[개발] 함께 자라기

안녕하세요. 블랙진입니다.

최근 이직과 동아리 활동을 하면서 협업에 대해 많은 관심을 가지게 되었습니다. 팀 내에서 어떻게 하면 협업을 잘 할 수 있을까? 프로젝트 팀원들과 어떻게 하면 모두가 만족한 결과를 만들어 낼 수 있을까? 이 과정에서 나는 얼마나 더 성장할 수 있을까? 저의 달라진 환경에 맞춰 협업과 성장에 대해 계속 고민하게 됩니다. 이런 고민을 하는 중 "함께 자라기 - 애자일로 가는길"을 읽게 되었는데요. 제 고민과 맞물려 많은걸 느낄 수 있었던 책이었습니다.

머리말

 

"내가 정말 잘할 수 있을까? 아니, 우리가 정말 잘할 수 있을까?"

그동안 혼자 고민하고 공부해온 저를 되돌아 보게 하는 문장이었습니다. 공부 하는데 있어서 혼자 하는게 익숙했고 혼자 하는게 더 빠르게 성장하는 법이라고 생각했습니다. 하지만 혼자 공부 하면서 성장에 대한 목마름은 더욱 심해졌습니다. 그러던 와중 이직을 하게 되어 함께하는 동료가 생겼고 동아리 활동을 하며 함께 공부할 친구들을 만나게 되니 이러한 목마름이 조금씩 채워지기 시작했습니다.

1장 자라기

"신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다"  - p101

팀장은 선의로 팀원들에게 책을 선물합니다. 그런데 팀장과 팀원 사이의 신뢰는 이미 깨져 있는 상태입니다. 그러면 팀원들은 팀장의 행동을 악의적으로 느낄 수도 있습니다. "나 보고 이런 거 모르니 공부하라는 얘기야? 자기는 쥐뿔도 모르면서..."라고 생각할 수 있는 것이죠. - p101

정말 공감이 많이 가는 부분이었습니다. 신뢰가 깨져 있다면 그 어떤 말이라고 악의적으로 받아 들어 질겁니다. 같은 말이라도 그 사람을 어떻게 생각하고 있느냐에 따라 내용은 180도 달라질 수 있습니다. 또한 책에서는 뛰어난 개발자에 관해 다음과 같이 언급합니다.

"뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻었습니다." - p102

"뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안되는 사람들만이 동료와의 협력을 언급 했습니다."  - p102

뛰어난 개발자일수록 협력을 더욱 중요시 한다는 문장입니다. 그간 필자는 뛰어난 개발자라면 당연히 프로그래밍을 잘 하는 개발자라고 생각했습니다. 이직을 준비하면서 회사는 프로그래밍을 잘하고 많이 아는 개발자를 선호하는 줄 알았지만 그게 아니라는 것을 느낄 수 있었습니다.  프로그래밍을 잘 하는것만 따지면  3년차나 10년차나 퍼포먼스 적으로는 큰 차이가 없다고 생각합니다. 필자는 4년차 개발자로 그동안 많이 공부하고 코드를 잘 짜는게 저의 성장이라고 생각했습니다. 하지만 소통의 중요성을 최근에 많이 느끼고 있으며 소통을 잘하는 개발자로의 성장이 프로그래밍을 잘하는 것보다 나를 더 발전 시키고 있다는 것을 조금씩 느끼고 있습니다. 마지막으로 책에서 인상깊게 읽은 스토리로 1장을을 마무리 하겠습니다.

이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 보게 된 겁니다. ... (중략) ... 마지막으로 수년 전 모 커뮤니티 모임에서 일어난 일화로 글을 맺을까 합니다.  한 분이 자신이 속한 조직의 형상 관리 도구를 서브버전에서 깃으로 성공적으로 안착시킨 사례를 이야기하고 있었습니다. 잘 아시겠지만 조직의 형상 관리 시스템을 바꾼다는 것은 그리 쉬운 일이 아닙니다. 그 후배는 대리 직급에서 그 일을 했는데. 상대적으로 낮은 직급에서 이런 조직적 전환을 만들었다니 더 놀라운 일이었죠. 사례 공유가 끝나자 청중 한 분이 손을 들고 묻더군요. "이해가 되지 않습니다. 저 역시 그렇게 하려고 깃의 장점에 대한 발표도 하고 교육도 몇 번에 걸쳐 해줬는데 결국 사람들이 쓰게 하는데에 실패했습니다. 사람들이 너무 수동적이고 보수적이에요" 발표자가 뭐라고 답을 했던 것 같은데,  옆에서 지켜보던 제가 호기심이 생겨서 질문하셨던 분과 발표자에게 각기 동일한 질문을 드렸습니다. "그 조직원들이 선생님들 좋아하나요?" 질문자와 발표자가 상반된 답을 했으리라는 건 여러분도 짐작할 수 있지 않을까 하네요. - p103 ~ p105

2장 함께

초기에는 대상에 대한 지식이 거의 없으니 일을 제대로 나눌 수가 없습니다. 사실 일을 가장 잘 나눌 수 있는 때는 프로젝트가 완료되는 시점입니다. - p110

필자는 프로젝트를 진행할 때 초반에 화면별로 역활을 나눠 진행하고 나중에 합치는 식으로 많이 진행 했습니다. 하지만 그 속을 들여다보면 협력은 거의 없었습니다. 각자 선을 긋고 작업하고 안녕이죠.... 필자는 협업을 하고 싶어서 프로젝트를 진행했는데 다시 돌이켜 보니 그 안에 협력은 없었습니다. 위 문장을 읽으면서 그리고 책을 읽어 나가면서 협력에 대해 많은 고민을 했습니다.

"백지장도 맞들면 찢어진다?" - p121

협력하면 밑천도 못 건진다고 생각하는 사람이 많습니다. 많은 실험에서 집단의 퍼포먼스가 개인의 퍼포먼스보다 못 한 경우를 찾아냈습니다.  p121

이 글을 읽는 독자분들은 어떻게 생각하시나요? 필자는 혼자 개발하다보니 그동안 집단보다는 개인의 퍼포먼스가 더 높다고 생각했습니다. '차라리 혼자 만드는게 더 빠르겠다' 라는 생각을 느낀적도 있고요. 하지만 책에서도 언급하지만 그건 잘못된 협력을 하고 있었기 때문이라고 합니다.  

둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 됩니다. 서로 다른 것들을 하나로 묶어야 하기 때문입니다. 반면 혼자서 작업할 경우에는 이런 추상화의 필요가 덜합니다. - p124

여기서 추상화 라는 단어가 나옵니다. 어느정도 규모의 프로젝트를 개발 하신 분이라면 프로그래밍을 할 때 추상화가 얼마나 중요한지를 아실겁니다. 혼자 작업하게 되면 이런 추상화 작업이 잘 이뤄지지 않고 쉽게 지나치게 되는 것 같습니다. 추상화는 프로그램의 확장성을 늘리고 유지보수를 용이하게 해줍니다. 그만큼 중요한 부분인데 추상화를 지키면서 작업하기는 어렵습니다. 이에 책에서는 추상화를 높일 수 있는 여러 방법을 제시해줍니다.

"다른 시각을 가진 두 사람이 협력하기" - p126

자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하세요. 같이 그림도 그려보고 함께 소스코드를 편집하세요. 인간에게는 다른 인간과 소통하고 협력할 수 있는 놀라운 능력이 있습니다. 대화는 기적입니다. - p128

가장 인상 깊었던 문장들입니다. 필자는 한가지 코드를 보며 같이 생각하는 작업을 이직하게 되면서 많이 하게 되었습니다. 처음에는 너무 어색했고 오히러 퍼포먼스를 떨어뜨리는 것 같다고 생각했습니다. 하지만 1달 2달 적응하면서 오히려 제 자신이 업무에 탄력이 붙었다는 걸 느끼게 되었습니다. 

"신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가" - p129

책에서는 디자이너가 디자인을 공유했을 때 신뢰관계에 대한 변화 실험을 하나 보여줍니다. 두 디자이너가 서로 잘했다고 생각하는 최고의 한가지 안을 공유했을 때 오히러 신뢰감이 떨어집니다. 하지만 복수의 안을 공유했을 때는 신뢰도가 높아지고 성과도 더 좋았다고 합니다. 왜 이런일이 벌어진 걸까요?

하나의 공유는 기대감 보다는 불안감이 더 커지고 방어적으로 대응하게 됩니다. '작업물 = 나'가 되기 때문이죠. 하지만 복수 공유는 그 불안감이 상대적으로 덜 됩니다. 말하는 사람도 편하고 듣는 사람도 좋다는 이야기랑 안 좋다는 이야기를 같이 들으니 마음이 좀 더 편해지는 거죠. 협력할 때 여러 안을 가지고 편하게 대화하는것의 중요성을 설명한 부분이었습니다.

남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 합니다. .. (중략) .. 내가 설득하고 싶은 상대를 자주 만나고 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 합니다. 출발은 결국 내가 설득하려는 사람에게서 하는 것입니다. - p141

뭔가 뼈를 때리는 문장이지 않나요? 설득을 하기 위해서 의견을 뒷받침 해줄 자료를 조사하는게 아니라 그 사람을 이해해야 된다고 합니다. 필자는 아직 다양한 사람과의 프로젝트 경험이 적고 심한 충돌을 겪어 보지 않아봐서 잘 모르겠습니다. 하지만 이것 하나는 확실합니다. 프로젝트를 진행하면서 사람이 미웠던 적은 없었습니다 :)

"이것도 모르세요?" - p145

독자 분들은 어떤 사수가 좋은 사수라 생각하시나요? 혹은 부사수가 질문했을 때 어떻게 대답해 주실 건가요? 위 문구처럼 "이것도 모르세요? 여기 책에 다 나와있어요. 공부부터하고 질문하세요" 이렇게 대답하실 건가요? 책에서는 사수와 부사수간의 문답 형식으로 자세한 설명과 함께 공감하고 이해하려는 대화법을 소개합니다. 내용이 많아 여기 다 옮길 수는 없지만 꼭! 읽어보고 되씹어봐야 되는 부분입니다. 

책에서는 훌륭한 팀장은 먼저 그 사람의 사고 과정과 전략을 이해하려고 해야 한다고 합니다. 그리고 행동을 유도하는 대화를 이끌어 낼 수 있어야 합니다.  이 부분을 읽으면 필자는 괜스레 반성을 하게 되었고 함께 자라기 위한 대화법에 대해 고민하게 되었습니다. 이 외에 다양한 예시와 함께 좋은 협력 방법에 대해 책에서는 계속 소개합니다. 아래는 그중 필자가 인상 깊게 읽었던 문장들입니다.

삼투압적 의사소통 - p159

내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음 - p168

애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는" 확률을 '그리고' 확률로 바꾸는 경향이 있습니다. - p189

2장의 마지막으로 재밌는 법칙이 소개되어 잠깐 언급하고자 합니다. 

파킨슨의 법칙 - 교수가 숙제 기한을 일주일 늘려줬을 때 학생들이 숙제를 하는데 걸리는 시간도 일주일 늘어나는 현상

공감가시는 분들이 많을 것 같습니다 (필자는 200% 공감합니다.)  특정 기한까지 뭔가를 해야되는데 그 기한이 늘어난다고 해서 빨리 끝내는게 아니라 늘어난 기한 만큼 할일을 미룬다는 거죠. 이게 법칙으로 만들어질 정도면 사람이 생각하고 행동하는게 다 비슷비슷 한가 봅니다.

3장 애자일

애자일에 대해 본격적인 이야기를 시작합니다. 애자일을 적용했을 때 실제로 성과가 나온 기업과 성과가 없는 기업들을 분석하며 어떤식으로 애자일을 도입해야 되는지 자세한 예제와 함께 저자의 생각을 보여줍니다. 필자가 느끼기에 결국에는 애자일을 잘 하기 위해서는 1장과 2장의 내용이 선행되어야 하며 책에서 말하는 "함께 자라기"가 성공적인 애자일로 가는 길이라는 걸 느꼈습니다.