함께 자라기: 애자일로 가는 길

개요

지난주 자주 보는 페이스북 페이지인 개발자스럽다에 공유된 함께 자라기라는 책의 리뷰를 봤습니다. 간추린 내용임에도 불구하고 좋은 글들이 많아 직접 구매한 뒤 읽어봤습니다.

책의 내용을 요약하고 중요하다고 생각되는 글 조각들을 발췌하여 정리했습니다.

들어가는 글

이 책은 소프트웨어 개발을 함에 있어서 개발자가 어떻게 성장해 나감과 동시에 프로젝트를 성공적으로 완성할 수 있는지를 애자일 방법론을 토대로 설명하고 있습니다.

그를 위해서 책에서 강조하는 가장 중요한 키워드가 바로 학습과 협력입니다. 그래서 책의 제목이 함께 자라기 인 것 같습니다.

저도 어느새 나이 든 개발자 축에 속하게 되었습니다. 하지만 스스로 돌아봤을 때 아직도 부족함을 느낍니다. 이 책을 통해 더 좋은 개발자가 되기 위한 과정을 학습하고, 공유함으로써 더 좋은 결과를 낼 수 있길 기대합니다.

책이 이야기를 이끌어 가는 큰 순서는 1. 자라기(학습), 2. 함께(협력), 3. 애자일입니다.

스스로 자라나가려면 어떻게 해야 하는 지를 첫 번째 챕터인 자라기를 통해 설명합니다.

그런데 소프트웨어 개발이라는 불명확한 일을 성공적으로 완수하려면 혼자서만 자라서는 힘듭니다. 팀원들과 함께 자라면서 효율적으로 일해야만 합니다. 그래서 필연적으로 두 번째 챕터, 함께가 이어집니다.

위의 두 챕터를 통해 성장하는 방법과 함께 일하는 방법에서 우리가 갖고 있던 미신이 깨어지고 더 좋은 방법들이 소개됩니다. 그리고 알고봤더니 짜잔! 바로 그 방법들이 애자일이란 이름으로 이미 정의되어 있습니다.

---

1. 자라기

의도적인 수련

경력이나 연차는 개발자의 생산성, 성과와 상관관계가 없다는 말로 글이 시작됩니다. 경력이 적더라도 그 시간을 알차게 의도적 수련으로 채웠다면 더 우수한 개발자가 될 수 있다는 이야기입니다.

의도적인 수련이란 자신에게 주어진 일을 그저 반복하는 것이 아니라 어떻게 하면 그 작업의 과정이나 결과물을 좀 더 개선할 수 있을 지 고민하고 적용해야 한다는 것입니다.

단지 적용만으로 끝나선 안됩니다. 그 적용 결과에 대해 피드백을 받아야만 합니다. 피드백이 있어야만 현재 나에게 부족한 것이 무엇인지, 더 개선할 점은 없는지 알 수 있게 되고 또 다른 수련의 단초를 잡을 수 있습니다.

그러므로 우리는 맡은 일에 대해서 항상 개선하고, 그 개선에 대해 빠른 시간 안에 피드백을 받은 후 또 다시 개선하는 과정을 반복해야 합니다. 그 의도적인 과정을 통해 학습과 발전이 일어납니다.

피드백에 대한 두려움을 줄이자

개발과 개선에서 항상 좋은 결과만 있을 수는 없습니다. 그렇기 때문에 항상 좋은 피드백이 있을 수만은 없죠. 하지만 피드백이 있어야만 성장할 수 있습니다.

피드백에 대한 두려움을 줄이기 위한 첫번째 방법은 우리의 생각을 실행 프레임에서 학습 프레임으로 바꾸는 것이 중요합니다. 실행 프레임은 업무의 완수, 성과를 중요시하는 것이고 학습 프레임은 업무를 통해 무언가를 배우고 성장하는 것을 중요시하는 것입니다.

실수를 하지 않는 것보다 실수를 통해서 배우는 것이 중요하다는 태도를 갖게 되면 그만큼 피드백에 대해 열린 자세를 갖게 됩니다.

두번째 방법은 실수를 대하는 조직의 문화를 실수 예방에서 실수 관리로 변화시키는 것입니다. 실수 예방은 실수를 없애는 것을 최우선의 가치로 두는 것이고, 실수 관리는 실수를 발생할 수밖에 없는 것으로 보고 그 실수로 인한 나쁜 결과를 빠르게 회복하도록 돕고, 실수를 공개함으로써 모든 구성원이 그 실수로부터 배우도록 장려하는 것입니다.

만약 조직 전체가 실수를 감추기 보다는 실수를 공개하고 그를 통해 무언가를 배우기를 장려한다면 점점 실수는 줄어들게 될 것이고 모든 구성원이 피드백에 익숙해지게 될 것입니다.

수련의 효과를 높이려면

의도적인 수련의 효과를 높이려면 나의 실력과 작업의 난이도가 비슷해야 합니다. 만약 난이도에 비해 실력이 낮다면 불안감을 느끼게 될 것이고, 높다면 지루함을 느끼게 될 겁니다.

지루함을 느끼는 경우엔 의도적으로 도구를 사용하지 않거나, 맡은 업무의 수준을 더 높이는 방법으로 극복할 수 있습니다. 혹은 리팩토링을 하거나 테스트 자동화를 적용하거나, 자신만의 도구를 만들어 보는 식으로 난이도를 높일 수 있습니다.

불안감을 느끼는 경우엔 다른 실력있는 전문가에게 도움을 요청하거나, 업무의 실질적이고 핵심적인 기능만을 구현한 아기 버전을 개발을 목표로 낮은 난이도에서 시작하여 서서히 난이도를 올려가는 방법이 효율적일 겁니다.

전문가로부터 배우자

다른 전문가처럼 되고 싶다면 중요한 것은 그 전문가로부터 배우는 것입니다.

뛰어난 소프트웨어 개발자일 수록 타인과의 인터랙션에 더 많은 시간을 쓴다고 합니다.

아무리 선진적인 기술적 실천법이 있다고 해도 그 기술은 사회적 맥락 속에서 실천되어야 하며 그 기술의 성공을 위해선 사회적 자본과 사회적 기술이 필요합니다.

즉, 타인과의 인터랙션을 통해 축적된 신뢰라는 사회적 자본이 있어야 비로소 개선, 피드백, 그리고 개선이라는 프로세스가 팀 단위로 정착될 수 있습니다.

또한 프로그래밍 과정에서도 다른 개발자와 함께 일을 하게 되면 더욱 효율적인 추상화 과정을 경험하고 그를 통해 새로운 것들을 배울 수 있습니다.

발췌

직무 성과에 대해 경력 연차의 상관성은 0.18, 학력의 상관성은 0.10입니다. 상관성이 0.20 이하이면 약한 상관성이라고 말합니다. 그렇다면 어떤 것들이 상관성이 높았을까요? 작업 샘플 테스트가 0.54, 아이큐 같은 지능 테스트가 0.51, 구조화된 인터뷰가 0.51 이었습니다. 성실성이나 꼼꼼함 같은 성격 테스트도 0.41이나 0.31 정도의 상관성이 있었습니다. 레퍼런스 체크도 0.26으로 앞서의 연차들의 상관성보다 높았습니다.
- p.19

경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다.
<톰 드마르코와 티모시 리스터의 연구>
- p.22

1만 시간의 법칙에서 1만 시간은 '자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련'을 한 시간을 일컫습니다. 그런 수련을 의도적 수련이라고 합니다.
- p.27

수련의 효과를 높이기 위해 피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것이 중요하다.
- p.28

어떻게 작업을 효과적으로 개선시킬 수 있는가?
1. 자신이 이미 갖고 있는 것들을 잘 활용하라.
2. 외부 물질을 체화하라.
3. 자신을 개선하는 프로세스에 대해 생각해 보라.
4. 피드백을 자주 받아라.
5. 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.
- p.39

실행 프레임은 사람들이 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀을 말합니다. 학습 프레임은 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀을 말합니다.
- p.43

현재 자신의 업무 상황 속에서 창의적으로, 그리고 사회적으로 (다른 사람의 생각과 마음에 관심을 갖고, 그들을 설득하고 협상하는 것) 일하지 않는 기간이 계속된다면 결국 자신의 커리어에 막대한 손해가 될 수 있습니다.
- p.52

꾸준한 반복으로 달인이 되려면 적어도
1. 실력을 개선하려는 동기가 있어야 하고
2. 구체적인 피드백을 적절한 시기에 받아야 한다.
- p.55

특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스는 경험을 오래 한다고 해서 자동으로 얻을 수 있는 것은 아닙니다.
<에릭손>
- p.55

믿을 수 있는 직관이 형성되려면 특정 조건이 필요한데 바로 타당성과 피드백입니다. 타당성 조건이 필요하다는 의미는 직관이 적용되는 영역에 어느 정도 인과관계와 규칙성이 존재해야 한다는 것입니다.
피드백 조건이 필요하다는 의미는 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야 한다는 걸 말합니다.
- p.57

의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 합니다. 실력이 난이도보다 낮다면 불안감을 느끼고 실력이 난이도보다 높다면 지루함을 느끼게 됩니다. 자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있다는 겁니다.
뛰어난 선수는 자기 기량보다 어려운 기술을 연마하지만 그렇지 못한 선수는 이미 잘하는 걸 더 연습합니다.
- p. 61

지루함을 느끼는 경우에는 평상시 즐겨 쓰던 보조도구를 일부러 쓰지 않거나, 자기에게 요구되는 업무 수준을 더 높게 여기는 방법을 적용해볼 수 있습니다.
공식적으로는 안해도 되는 업무를 자신의 의지로 추가하는 것도 좋습니다. 리팩토링을 하거나 자동화 테스트를 달거나, 자신만의 도구를 개발할 수도 있습니다.
- p.67

불안함을 느끼는 경우에는 나보다 뛰어난 전문가의 도움이나 도구의 도움을 받는 것도 좋습니다. 혹은 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전을 첫 번째 목표로 삼고 개발하는 것도 좋은 방법입니다.
- p.71

프로그래밍 언어를 빠르게 배우는 팁
1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.
2. 공부할 때 표준 라이브러리 소스코드를 읽는다.
3. 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다.
- p.83

전문가조차도 1시간에 평균 3~5개의 실수를 저지른다고 합니다. 따라서 실수를 예방하기보다는 실수를 관리하는 문화를 조직에 정착시키는 것이 유리합니다. 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다.
- p.91

1. 아무리 기술적인 실천법이라고 해도
2. 그 기술은 사회적 맥락 속에서 실천되어야 하며
3. 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다.
- p.100

뛰어난 전문가는 사회적 자본과 사회적 기술 또한 뛰어납니다.
뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻었습니다.
뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언을 할 때 사회적인 측면이 포함됩니다.
이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력도 일부로 보게 된 겁니다.
- p.102

---

2. 함께

팀의 신뢰 자산을 키우자

최근의 소프트웨어 개발은 대부분 팀 단위로 이루어집니다. 따라서 혼자서만 학습을 한다고 해서 업무의 전체적인 생산성이 크게 향상되지 않습니다. 즉, 팀 전체가 혹은 조직 전체가 자라야 합니다.

의도적인 수련을 팀 단위로 적용할 수도 있을겁니다. 하지만 그러기 위해서 선행되어야만 하는 것이 있습니다. 바로 사회적 자본입니다. 나와 팀원들 간에 생성된 신뢰가 필요한 것입니다. 그래야만 팀 전체가 하나의 목표를 갖고 움직이게 됩니다.

실제로 신뢰 자산이 높은 팀은 커뮤니케이션 효율이나 생산성이 높다는 연구가 있습니다. 신뢰 자산을 높이기 위해선 팀원들 간에 투명한 공유와 인터랙션이 필요합니다.

투명한 공유는 팀 내에서 나의 결과물을 공유하고 팀원들이 그에 대해 바른 피드백을 줄 것이라 믿는 것입니다. 바른 피드백이 항상 좋은 피드백인 것만은 아닐 것입니다. 비록 공유된 결과물에 대해 비판적인 피드백이 있더라도 건설적으로 받아들이고 학습하며 개선하는 태도를 가져야 합니다.

또한 피드백을 주고 받을 때, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음이 필요합니다. 이것을 심리적 안전감이라고 합니다.

인터랙션은 팀원들이 서로 상호작용하고 의사소통하는 것입니다.

단순히 업무에 대한 내용만이 아니라 안부 인사나 일상에 대한 잡담 등의 마이크로 인터랙션도 팀의 신뢰 자산을 키우는 데 큰 영향이 있다고 합니다.

팀 단위의 수련 모델

1 챕터 자라기에서 의도적 수련은 작업물에 대해서 빠르게 피드백을 받고 또 그것을 개선해 나가는 과정이라고 했습니다.

이것이 팀 단위가 되면 Task 단위에서 Product 단위로 확장이 됩니다.

개발의 과정은 보통 분석, 설계, 구현, 테스트, 전개로 나뉩니다. 하나의 단계를 완전히 끝낸 후 다음 단계로 넘어가는 방식으론 빠른 피드백과 개선 적용을 할 수 없습니다.

심지어 단계를 확실하게 구분짓는 방식은 결과물의 품질을 낮추는 효과가 있다고 합니다.

어떻게 해야 첫 달, 첫 주부터 위 과정을 자유롭게 오갈 수 있을지 고민해야 합니다. 빠르게 구현하고, 빠르게 피드백을 받고, 다시 그 피드백을 설계에 적용해서 개선해 나가야 결과물의 품질이 좋아질 수 있습니다.

발췌

팀원들이 상시 대면 의사소통을 할 수 있는 공간이 생산성 향상에 많은 도움이 됩니다.
서로 같은 목표로 일하는 팀이 만드는 소음은 그들 사이에서는 더 이상 소음이 아니기 때문입니다.
- p.113

둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 됩니다.
- p.124

신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다는 연구가 많습니다.
신뢰를 쌓는데 널리 사용되는 방법은 투명성과 공유, 인터랙션입니다.
- p.129

뛰어난 팀이라면 공통적으로 갖고 있는 특징 중 하나가 바로 '삼투압적 의사소통'입니다.
삼투압적 모형은 은연중에 서로 간에 정보가 스며드는 걸 말합니다. 그렇게 하려면 사람들이 물리적으로 가까운 거리에 있어야 유리합니다.
예를 들어 프로그래머가 프로그래밍을 하다가 디자이너에게 무언가 질문을 할 때, 그 내용을 기획자가 우연히 듣고 끼어들어 새롭고 가치 있는 정보를 주는 것입니다.
또한 한번에 처리되는 일의 양을 줄이고, 지속적인 흐름을 통해 짧은 시간 내에 기획과 구현을 오가게 하는 것이 유리합니다.
- P.159

개발의 과정은 보통 분석, 설계, 구현, 테스트, 전개로 나뉩니다. 위 과정 중 어느 한 단계를 완료한 이후에 다음 단계로 나아가는 방식은 낮은 품질로 가는 지름길입니다.
어떻게 해야 첫 달, 첫 주부터 위 과정을 자유롭게 모두 왔다 갔다 할 수 있을까를 고민해야 합니다.
- P.161

구글이 밝힌 탁월한 팀의 비밀은 아리스토텔레스 프로젝트를 통해 아래와 같이 밝혀졌습니다.
1. 팀에 누가 있는지보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
2. 5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안정감이었다.
3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
- p.167

심리적 안전감이란 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말합니다.
- p.168

---

3. 애자일

게임 개발은 불확실성이 높은 프로젝트입니다. 그렇기에 더 다양한 사람으로부터 더 자주, 그리고 더 일찍 피드백을 받는 애자일이 적합한 것 같습니다.

자주 피드백을 받는 다는 것은 배울 점이 더 많이 생긴다는 것입니다. 이것을 통해 우리는 개인의 학습만이 아니라 팀 단위에서 품질의 개선도 이룰 수 있습니다.

그리고 이러한 학습이 조직 전체에 까지 투명하게 공유된다면 조직 전체의 업무 개선도 이룰 수 있을 것입니다.

그러기 위해선 저 뿐만이 아니라 더 많은 사람들이 함께 학습 프레임을 장착하고 업무를 개선해가며 의도적 수련을 통해 다른 사람들을 도우면서 함께 자라 가는 그런 개발자가 되어야 할 것입니다.

발췌

애자일은 불확설성이 높은 프로젝트에서 더 적합합니다.
애자일이 불확실성을 다루는 방식은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있습니다.
- p.194

불확실하다는 것은 우리가 이동을 할 때 목표점의 위치가 자주 바뀌거나 우리 위치가 자주 바뀌거나 하는 상황으로 비유해볼 수 있습니다. 그럴 경우일수록 우리는 가다가 멈춰 서서 주위를 둘러보고 목표점과 우리 위치를 확인하는 피드백을 통해 방향을 재조정하는 일을 자주 해야 합니다.
다시 말해 이동하면서 계속 배워나가야 한다는 뜻입니다.
- p.195

좋은 일은 확장해야 합니다.
모든 사람이 통찰을 얻어야 업무를 개선할 수 있는 게 아니라 한 사람이라도 통찰을 얻으면 그걸 공유해서 전체가 개선되는 것입니다.
- p.196

고객에게 매일 가치를 전하라.
매일이란 학습의 빈도를 말합니다. 좋은 학습은 질 높은 피드백에서 오게 됩니다. 즉 자주, 그리고 이른 시점에서부터 피드백과 학습과 개선을 시작해야 합니다.
고객에게란 협력의 중요성을 말합니다. 협력을 통해서 결과가 나옵니다. 고객 또한 협력의 중요한 부분입니다.
- p.199

설계, 코딩, 테스팅 등의 소프트웨어 개발 활동에 대한 시간 투자는 전문가와 그렇지 않은 사람에 큰 차이가 없는 반면, 리뷰 회의나 다른 사람과 상담하는 등의 의사소통과 협력 활동에서는 전문가가 훨씬 많은 시간을 사용한다는 것이 밝혀졌습니다.
- p.210

탁월한 소프트웨어 엔지니어와 그렇지 못한 사람을 구별하는 효과적인 요소는, 주어진 업무 외에도 관심을 갖는가 하는 점이었습니다.
탁월한 엔지니어들은 프로젝트 전부에 대한 큰 그림을 가지려고 하고, 경영진에게 더 적극적인 태도로 가가가고, 다른 엔지니어들을 도와줍니다.
뛰어난 애자일 코치는 함께 자라기를 하는 사람입니다.
- p.210