[개발서적] 함께자라기 핵심 내용 정리 및 요약

아래의 내용은 김창준님의 함께자라기를 읽고 정리한 내용입니다.

 

 

 

1. 자라기

---

[ 당신은 몇 년차? ]

연차는 중요한 요소가 아니다

소프트웨어 기술자의 등급은 학력과 연차로 고려되는 경우가 많지만 사실상 경험이 가장 중요한 요소이다. 그 사람의 실력에 대해서는 연차로부터 다음과 같은 사항들만 결정할 수 있다.

• 연차로는 이 사람이 초급인지 아닌지 정도만 기대할 수 있다.
• 초급이 아닌 사람들에 대해서는 연차가 오히려 혼동을 불러일으키는 잘못된 정보로 작용할 수 있다.
• 연차로 채용 여부나 임금 수준을 결정하는 것은 편의적이고 관료주의적이며 조직에 손해를 줄 수 있다.

 

미국 연방 정부의 연구 결과에 따르면 채용 후 성과-연차 또는 성과-학력의 상관성은 매우 낮았다. 반면에 샘플 작업, 지능 테스트, 구조화된 인터뷰를 포함해 성격테스트나 레퍼 체크 등은 오히려 높았다. 물론 경력이 적을 때에는 연차 상관성이 꽤 높지만 연차가 쌓일수록 상관성이 낮아진다. 졸업생과 신입생은 후자의 실력이 높을 수 있지만 5년 차와 10년 차에게는 연차의 큰 의미가 없다는 것이다.

 

 

연차보다는 경험이 중요하다

톰 드마르코와 티모시 리스터의 연구에서는 다음과 같은 사실이 밝혀졌다.

• 최고의 개발자는 최악의 개발자보다 10배 정도의 능력차이를 보였다.
• 경력이 10년인 개발자는 2년인 개발자보다 뛰어나지 않았다.
• 즉, 경력과 생산성은 아무런 상관관계가 없었다.
• 다만 언어를 접한 경험이 6개월 미만인 경우에는 전반적으로 나머지 개발자들보다 성적이 저조했다.

 

즉, 최소 한도의 경험치만 넘어가면 경력과 직무 상관성이 낮다는 것이다. 대신 개발자의 경험이 얼마나 폭넓고 다양했는지가 중요했다. 즉, 경력은 질적으로 좋아야 중요해진다. 채용 시에도 경력 보다는 협업 능력 등이 더 중요하다. 경력으로 판단하기 보다는 구조화된 인터뷰, 작업 샘플 테스트, 실제 업무를 주고 짧은 기간 일해보기 등을 권장한다. 그리고 채용 후에 이 사람을 어떻게 교육 및 성장시킬지도 중요하다.

 

 

1만 시간 법칙의 진실

몇 년 전에 1만 시간의 법칙이 유행하였다. 여기서 1만 시간은 단순 연차가 아니라 의도적 수련 시간을 의미한다. 의도적 수련이란 자신의 기량 향상을 목적으로 반복적으로 하는 것이다. 단순 노동이 아니라 자신의 약점을 개선하려고 노력하는 것만이 의도적 수련이다. 업무를 하면서 의도적 수련을 같이 하려면 업무를 하면서 빠르게 피드백받고 교정하면서 성장하는 "애자일 철학"이 필요하다.

 

 

 

[ 자기계발은 복리로 돌아온다 ]

평균적인 자기 계발 시간

일이 끝나면 회고를 하면서 자기계발 시간을 되짚어보는 것이 중요하다. 현재 나에게 투자한 것이 1~2년 후의 나를 결정하기 때문이다. 잡코리아의 데이터에 따르면 자기계발 시간 통계는 다음과 같다. 하루 평균 1시간도 투자하지 않는 사람은 반성해야 한다.

• 1시간 미만: 33.8%
• 1~2시간: 54.1%
• 2~3시간: 9.4%
• 3시간 이상: 2.8%

 

어떻게 빨리 성장할 것인가?

지식이나 능력은 이자가 복리로 붙기 때문에 축적되면 엄청난 차이를 만들 것이다. 그러므로 더 빨리 자라고 싶다면 1)어떻게 이율을 높일 것인가 2)지속적으로 현명한 투자를 하려면 어떻게 할 것인가에 주목해야 한다.

1. 자신이 이미 갖고 있는 것들을 잘 활용하라
   • 새로운 지식을 유입시키기만 하면 새로 들어온 것들이 기존의 것들을 덮어버릴 수 있다. 자신이 올 해 몇권 읽었는지 보다는 지식을 얼마나 활용했는지로 반성하자.
   • 이미 갖고 있는 것들을 촘촘히 연결하여 이동 속도가 빨라질 수 있도록 하라. 이미 습득한 지식과 기술 및 경험을 연결지어 시너지를 내고, 한 영역에서 다른 영역으로 왔다갔다를 자주 하여 영역을 넘나들기 수월하도록 해라.
   • 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌을 시도하라
   • 현재 내가 하는 일이 차후에 밑거름이 될 수 있도록 하라
2. 외부 물질을 체화하라
   • 계속 내부 순환만 하면 일정 수준에 수렴할 위험이 있으므로 주기적인 외부 자극을 받는 것이 좋다. 단, 외부 자극을 받으면 그것을 빨리 자신의 것으로 체득해야 한다.
   • 외부 자극이 유입된 이후 내부에 충돌이 생길 수 있다. 그것들을 무시하고 덮어두지 말고 상생적 관계를 끌어내야 한다.
3. 자신을 개선하는 프로세스에 대해 생각해보라
   • 예를 들어 본인의 작업을 되돌아보는 회고/반성 프로세스를 만들어라
   • 본인을 개선하는 과정을 어떻게 개선할 수 있을지 고민하라
4. 피드백을 자주 받아라
   • 피드백 사이클이 길어지면 효과가 떨어진다. 새로운 정보를 얻었다면 1주 혹은 1달이라도 작게 진행해 순환율을 높여라.
   • 일찍 그리고 자주 실패해라. 그리고 실패에서 학습하라
5. 자신의 능력을 보여주는 도구와 환경을 점진적으로 만들어라
   • 나의 속도를 늦추는 요소들을 조금씩 줄여나가는 것이 중요하다.
   • 완벽한 도구와 환경에 집착하면 아무 것도 할 수 없다. 예를 들어 방이 조용해지고 온도가 적절해지면 공부를 시작하겠다는 마음가짐으로는 결국 아무것도 하지 못할 것이다.

 

 

[ 학습 프레임과 실행 프레임 ]

업무를 하면서 단순히 일만 한다면 학습을 통해서만 성장해야 한다. 누군가는 업무를 하면서 성장을 하기 때문에 이는 불리하다. 동일한 자극/조건 속에서 그 조건을 더 많은 학습과 성장의 기회로 인지하고 자신에게 유리한 방향으로 갈 수 있어야 한다.

 

 

 

[ 가장 학습하기 힘든 직업이 살아남는다 ]

알파고의 등장 이후 많은 사람들이 "자신의 직업이 미래에 없어지지 않을까?" 하는 충격에 빠졌다. 인간과 인공지능 모두 학습하기 좋은 환경의 요소는 동일하지만 학습 속도는 인공지능이 훨씬 빠르다. 그러므로 우리는 학습하기 힘든 환경과 주제들을 골라야 한다.

1. 목표가 모호하고 주관적일 수 있으며 동적이다.
2. 매 순간 선택할 수 있는 행동/선택의 종류가 불확실하다.
3. 매 순간 내가 목표에 얼마나 근접했는지를 알기 어렵다.(피드백을 빨리 받기 어렵다.)
4. 주로 열린 시스템(즉, 예상 못한 외부 요소가 갑자기 들어오는 경우가 흔한) 속에 일한다.
5. 과거의 선택과 결과에 대한 구조화된 기록이 별로 없다.

 

독창성, 사회적 민감성, 협상, 설득, 타인을 돕고 돌보기 등이 요구되는 수준이 높은 것은 인공지능화 하기 어려웠다. 단순히 주어진 것을 동일하게 개발만 하는 프로그래머는 협상, 설득이 크게 필요하지 않아서 대체될 확률이 높았다. 반면에 뭘 만들지를 고민하고 설계하며 타인과 상호작용하는 소프트웨어 개발자는 그렇지 않았다. 단순히 개발자가 대체되기 어렵다기 보다는 이러한 차이를 인지해야 한다.

 

 

 

[ 달인이 되는 비결 ]

전문성 연구의 대가는 다음과 같인 얘기를 했다. “특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스는 경험을 오래 한다고 해서 자동으로 얻을 수 있는 것이 아니다.” 즉, 달인은 단순히 반복해서 되는 것이 아니고 다음의 2가지 요소가 중요하다.

1. 실력을 개선하려는 동기부여가 필요하다.
2. 구체적인 피드백을 적절한 시기에 받아야 한다.

 

 

[ 당신이 제자리걸음인 이유 ]

의도적 수련

실력을 높이기 위해서는 의도적 수련이 중요하다. 의도적 수련은 양적인 부분 뿐만 아니라 질적인 부분 역시 중요하다. 효과적인 의도적 수련을 위해서는 앞선 동기 부여와 피드백에 더해 적절한 난이도가 필요하다. “몰입" 연구에 따르면 난이도와 실력이 엇비슷 할 때 최고 수준의 집중력을 보이고 퍼포먼스나 학습 능력이 최대가 되며, 최고 수준의 행복감을 경험한다고 한다. 그러므로 자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경이므로 전략이 필요하다.

 

 

업무중 수련을 위한 전략들

1. 지루함을 느끼는 경우: 실력 낮추기
   1. 몸에 모래주머니를 달고 운동하는 것처럼 익숙하지 않은 기법 등으로 나의 실력을 떨어뜨리는 것이다.
   2. 특정 언어나 프레임워크의 좋은 기술들을 이용하지 않고 로우한 레벨로 개발하는 것이다.
   3. 키보드와 마우스 중에서 키보드만을 사용하는 것 역시 마찬가지다.
2. 지루함을 느끼는 경우: 난이도 높이기
   1. 1시간 안에 개발해보기, 리팩토링하기, 자동화 테스트 작성하기 등 자신만의 제약을 추가하는 것이다.
   2. 남들보다 일을 더 효율적/효과적으로 하기 위해 나만의 도구나 방법을 만드는 것이다.
3. 불안함을 느끼는 경우: 실력 높이기
   1. 스터디나 책 읽기 및 교육 수강 등 장기적으로 실력을 높이는 방법은 많다.
   2. 하지만 당장 실력을 올리기 위해서는 사회적 접근(나보다 뛰어난 전문가의 도움을 받는 것-짝코딩 등), 도구적 접근(디버거, 코드 분석 툴 등), 내관적 접근(비슷한 경험을 되살려 문제를 해결하는 것) 을 사용해야 한다.
4. 불안함을 느끼는 경우: 난이도 낮추기
   1. 가장 간단하면서 효과적인 방법은 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물(v0.01)을 첫 목표로 잡는 것이다.
   2. 가장 핵심적이지만 작은 단위부터 만드는 것이다.

 

유의할 점은 자신의 실력이나 작업 난이도가 계속해서 변한다는 것이다. 그러므로 자신의 상태를 살피면서 계속해서 전략들을 바꿔가며 사용해야 한다. 만약 팀장이라면 팀원들의 상태를 파악하고 올바른 전략을 적용할 필요도 있다.

 

 

 

 

[ 달인이 되는 비결 ]

프로그래밍 언어 배우기 전문가의 특징

프로그래밍 언어를 빠르게 배우는 사람으로부터 프로그래밍 언어 학습의 전문성을 끌어낸 결과 다음과 같은 특징이 있었다.

1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.
   1. 단어 개수 세기와 같이 다음 작성할 프로그램을 염두해 둔다는 것이다.
   2. 튜토리얼을 읽다가 그 프로그램을 작성할 수 있다는 판단이 들면 코딩을 먼저 하고 돌아와 다시 읽기 시작하는 것이다.
   3. 그러면 언제 이 문법을 사용할 수 있을까 스스로 반문하면서 적극적으로 읽게 된다.
2. 공부할 때 표준 라이브러리 소스코드를 읽는다.
   1. 표준 라이브러리는 해당 개발자가 작성한 문화와 스타일이다.
   2. Java로 개발해도 C로 작성하는 것과 별반 차이없는 결과가 나올 수 있다.
   3. 그러므로 해당 도구의 결을 배우고 따르는 것이 중요하다.
3. 공부중 다른 사람의 코드에 내가 필요한 기능을 추가한다.
   1. 전문가는 단순히 장난감 코드가 아니라 튜토리얼을 읽어가면서 실질적인 사용 예를 만들어냈다.
   2. 본인이 원했던 기능을 실제로 추가한 것이다.
   3. 여기서 중요한 것은 그 당시에 자신이 만들 작고 간단한 추가 기능을 생각낼 수 있냐는 것이다.

 

전문가로부터 배우기

주변의 전문가로부터 전문성을 뽑아내는 것은 자신의 전문성을 빨리 높일 수 있는 방법이다. 이때 중요한 것은 “프로그래밍 언어를 빨리 배우는 비결이 무엇인가요?”라고 묻지 않는 것이다. 이러한 질문은 형식적인 답변을 받을 가능성이 매우 높다. 대신 구체적인 사건에 대해 말하도록 유도하면 전문가가 구체적인 기억들을 상기하면서 의미있는 내용을 얻을 수 있다. 결국 무언가 잘하고 싶다면 이미 잘하는 사람을 관찰하고 인터뷰하는 것이 큰 도움이 된다.

 

 

 

[ 실수는 예방하는 것이 아니라 관리하는 것이다 ]

실수 문화

실수 문화에는 크게 2가지가 있다. 사실 이미 결과가 난 실수에 대해서 학습하고, 계획을 세우는 2차적 예방도 있다.

• 실수 예방
  • 행동에서 실수로 가는 경로를 차단하는 것
  • 실수를 저지르지 말라고 요구하는 것인데 거의 불가능하다.
  • 실제로 전문가도 1시간에 평균 3~5개의 실수를 발생시킨다.
• 실수 관리
  • 실수를 조기에 발견하고 빠른 조치를 취하는 것.
  • 실수는 어떻게든 할 수 밖에 없다.
  • 대신 그 실수가 나쁜 결고로 이어지기 전에 일찍 발견하고 고치는 것

 

실수 관리 문화가 중유한 이유

실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하게 된다. 그래서 실수를 감추고 문제가 생겼을 때 협력하지 못한다. 그러면서 실수에서 배우지 못하는 것이다. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 거기에 대해 얘기하면서 배우는 분위기가 생긴다. 실수를 하는 것은 불가피하고, 오히려 실수가 없으면 학습할 수 없다.

 

 

 

 

[ 뛰어난 선생에 대한 미신 ]

많은 조직에서는 직원의 몇 퍼센트가 어떤 교육을 들었고, 얼마를 썼는지 등 투입으로 교육 성과를 측정한다. 하지만 대부분의 교육은 6개월이 끝나면 효과가 거의 사라지는데, 교육의 효과가 미비한 이유 중에서 교사의 요소만 살펴보도록 하자.

연구 결과에 따르면 교사가 얼마나 많은 지식을 갖고 있느냐는 큰 영향을 미치지 않았다. 왜냐하면 아는 것을 온전히 가르치는 능력은 지식의 양과 무관하기 때문이다. 교사에게 중요한 것은 메타인지 능력이다. “내가 이 문제를 해결할 때 어떠한 과정을 거치는가?”를 스스로 관찰하고 질문하며 분석을 잘하는 사람들이 일반적으로 잘 가르친다.

 

 

 

[ 나홀로 전문가에 대한 미신 ]

뛰어난 연구자의 특징

벨 연구소는 수십 년에 걸쳐 뛰어난 연구자의 특성을 분석하였다. 그 결과 뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻었다. 즉, 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰는 것이다. 그리고 그들의 대부분은 초보 개발자들에게 조언을 해줄 때 동료와의 협업을 언급하였다. 혼자서 일하는 고독한 천재들은 전문가가 아니다. 이제 프로그래밍을 잘한다는 정의에 의사소통 능력도 포함되는 것이다. 타인과의 관계는 새로운 문화를 전파하는 데에도 좋은 영향을 끼친다.

 

 

타인과의 관계의 중요성에 대한 실제 사례

누군가가 형상 관리 도구를 서브버전에서 깃으로 성공적으로 안착시킨 사례를 발표하였다. 상대적으로 낮은 직급에서 이러한 변화를 만든 것을 보고 누군가가 질문하였다. “이해가 되지 않습니다. 저 역시 그렇게 하려고 깃의 장점에 대한 발표도 하고 교육도 몇 번에 걸쳐 해줬는데 결국 사람들이 쓰게 하는데 실패했습니다. 사람들이 너무 수동적이고 보수적이다.” 이러한 차이는 팀원들과 나의 관계에 기인한 것이였고, “그 조직원들이 나를 좋아하는가?”를 떠올려보면 해답이 될 수 있다.

 

 

 

 

2. 함께

---

[ 소프트웨어 관리자의 개선 우선순위 ]

조엘 테스트의 8번 문항에는 조용한 공간이 중요하다는 얘기가 있다. 애자일 컨퍼런스에서 저자들은 그룹 차원의 몰입이 가능하며, 팀원들이 상시 대면 의사소통할 수 있는 공간이 생산성 향상에 큰 도움이 된다고 역설하였다. 개발자에게 독립적인 사무 공간을 주는 것이 아니라 “시끄러운" 공간을 제공해 주는 것이 생산성에 도움이 된다는 것이다. 서로 같은 목표로 일하는 팀의 소음은 더 이상 소음이 아니다. 조용한 작업 환경을 강조하다 보면 면대면 소통을 나쁘게 생각할 수 있고, 이를 귀찮아하는 사람들에게 핑곗거리를 주기도 한다.

조엘 테스트에서 대부분의 항목은 도구에 속하지만 실제로 관리자의 개선 우선 순위를 측정해본 결과 다음의 순서대로 중요했다.

1. 관리
2. 시스템
3. 사람
4. 도구

 

 

[ 협력을 통한 추상화 ]

지금까지는 전문 프로그래머 연구에서 소프트 스킬(협력과 커뮤니케이션 능력 등)이 관심을 받지 못했다. 하지만 뛰어난 프로그래머는 보통 실력의 프로그래머에 비해 커뮤니케이션 및 협업 능력이 뛰어나다는 것이 밝혀졌다. 또한 단순 텍스트나 통화만으로 하는 협력보다 화이트보드나 종이 등으로 시각화된 협력이 훨씬 낫다는 연구들이 있었다. 대표적으로 짝 프로그래밍은 협업에 좋은 방법이다.

 

 

 

[ 신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가 ]

신뢰의 중요성

신뢰 가치는 최근 많은 주목을 받고 있는데, 신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높았다. 여기서 신뢰 자산이 높다는 것은 조직원들 간에 높은 수준의 신뢰가 기반이 되어 있다는 것이며, 이는 증감할 수 있다. 신뢰를 쌓는데 널리 사용되는 한 가지 방법은 투명성과 공유 및 인터랙션이다. 자신의 작업물을 투명하게 서로 공유하고 피드백을 주고 받으며 인터랙션하는 것이다. 이를 소통 신뢰라고 하는데, 상대가 자신의 생각을 나에게 솔직히 말해줄 것이라는 신뢰이다.

 

 

복수 공유

공유 할 때 중요한 것은 하나 공유는 안하느니만 못하다는 것이다. 여러 대안을 만들고, 그것을 모두 공유해야 신뢰가 유의미하게 높아진다. 왜냐하면 하나 공유는 그 자체에 대한 비판이 나에 대한 공격이 된다. 반면에 복수 공유는 나에게 또 다른 대안이 있으니 나에 대한 공격이 아니다. 또한 피드백을 주는 사람도 여러 개를 상대적으로 피드백할 수 있어 편하다. 즉, 복수 공유는 신뢰도와 성과가 더 좋아진다.

 

 

 

 

[ 객관성의 주관성 ]

설득에 대한 오해

팀장의 자리에 있으면 새로운 아이디어 전파가 쉬울 것이라고 생각할 수 있는데, 이는 상관이 없다. 누군가 “어떤 자료를 제시해야 하나요?” 혹은 “설득에 효과적인 사례가 있나요? 물어보기도 한다. 이 때의 대답은 “상대방에 대해 얼마나 이해하고 계신가요? 혹은 "얼마나 대화를 해보셨나요”가 된다. 설득에서 중요한 것은 상대방과의 관계이며 만약 별로 이야기를 못해봤다면 설득에 성공할 확률은 매우 낮다. 

 

 

설득에 있어 관계의 중요성

설득하기 위해서는 객관성이 필요한데, 이 객관성 자체가 매우 주관적인 개념이다. 내가 엄청난 데이터를 모아도 결국 판단은 사람이 하므로, 그 사람의 맘에 드는지가 매우 중요하다. 즉, “누구의 객관"인지가 중요한 것이다. 그러므로 누군가를 설득할 때 그 사람의 마음에 들지 않으면 어떠한 객관적 자료도 의미가 없다. 특히 그 자료에 “당신의 생각이 틀렸다"가 암시되어 있다면 더욱 어려워진다.

누군가는 그 사람이 잘못되었으며 감정적이지 않은 논리적인 판단을 해야 한다고 반박할 수 있다. 하지만 의사결정에 감정과 직관은 매우 큰 역할을 하며, 이것이 배제되면 의사결정을 제대로 할 수 없다. 그러므로 감정을 배제하는 것은 불가능하다고 생각하는 것이 맞다. 그러므로 남을 설득하려면 논리성과 객관성보다는 상대를 자주 만나 신뢰를 쌓고, "그 사람이 무엇을 중요하게 여기는지" 혹은 "어떤 설명 방식을 선호하는지" 이해해야 한다. 설득의 출발은 자료가 아니라 사람에서 시작하므로 설득에 성공하려면 먼저 그 사람을 이해해보도록 하자.

 

 

 

[ 이것도 모르세요? ]

누군가 물어보았을 때는 용기를 내어 질문한 것이다. 그런데 “이것도 모르세요?” 처럼 좋지 못한 피드백이 왔다면 앞으로 더 이상 질문할 가능성은 매우 낮다. 십중팔구 문제가 더 커지는 상황을 혼자 끌어안고 있을 테고, 결국 팀 전체에 타격을 주는 상황이 올 수 있다. 그러므로 누군가 물어보면 공감하면서 들어주고, 상대가 어떤 멘탈 모델 및 상황인지 파악해야 한다.

그러면 질문자가 상황을 이해하고 있는지, 어떠한 시도를 했는지 등을 파악하여 질문자의 머릿 속 지도와 사고 흐름을 엿볼 수 있다. 그러면 우리는 질문자가 모르는 핵심적인 부분만 설명해주면서 더 정확하고 효과적인 제안을 해줄 수 있다.

공감과 상황 파악에 더해 다음 행동 유도까지 한다면 금상첨화이다. 그러면 질문자는 자기주도적으로 공부하고, 책임감을 갖을 뿐 아니라 관계 역시 더욱 좋아질 것이다. 또한 목표를 달성할 확률과 이후의 만족도도 모두 높다.

 

 

 

[ 하향식 접근의 함정 ]

탑다운은 시간의 흐름으로 보아 추상적인 숲에서 구체적인 나무로 내려오는 접근법을 말한다. 탑다운은 깔끔해보이므로 전문가일수록 탑다운으로 사고하고 문제를 해결할 것이라고 생각한다.

문제는 잘 정의된 문제와 잘 정의되지 않은 문제로 나뉘어진다. 잘 정의된 문제는 “6의 약수는 무엇인가"와 같이 명확하지만 잘 정의되지 않은 문제는 “아름다운 그림을 그리시오"와 같이 불분명하다. 전문가는 자신이 자주 접하지 않았던 문제, 어려운 문제 혹은 잘 정의되지 않은 문제를 만나면 탑다운과 바텀업을 섞어 쓴다. 뛰어난 전문가일수록 그러하며, 번뜩이며 통찰력이 켜지는 순간은 방식이 변하는 순간에서 왔다. 비전문가는 자신이 세운 계획에 집착하는 반면에 전문가는 자신의 계획을 계속해서 수정하였다.

 

 

 

[ 전문가팀이 실패하는 이유 ]

연구 결과에 따르면 스타들이 팀에 추가될 때마다 팀의 추가적 성과 향상은 점차 줄어들다가 어느 수준을 지나면 성과를 깎아먹는 것으로 나타났다. 문제는 이런 분석이 올스타 팀을 만드는 비용을 고려하지 않았다는 것인데, 이를 포함하면 더 심각한 결과가 나올 것이다. 전문가가 추가되는게 도움이 안되거나 오히려 성과를 깎아먹는 경향은 특히나 전문가들의 전문성이 서로 유사할 때 도드라졌다.

협력 없는 전문가 팀과 협력하는 비전문가로만 구성된 팀을 구성하여 실험을 하였다. 결과를 보니 전문가팀은 정보 공유가 없어 비전문가팀보다도 훨씬 못한 결과가 나왔다. 협력이 없으니 결과물이 서로 모순되고 통합되지 않은 것이다. 추가적으로 개인 내 다양성이 높은 멤버가 없다면 정보 공유는 더욱 안된다는 결과도 발견할 수 있었다. 이 연구를 요약하면 다음과 같다.

1. 전문가들 모아서 팀을 만든다고 잘하는 것이 아니고
2. 오히려 성과가 떨어질 수 있으며
3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
4. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.

 

 

 

[ 구글이 밝힌 탁월한 팀의 비밀 ]

뛰어난 팀의 특징

구글은 데이터 기반으로 뛰어난 관리자의 특징을 찾는 옥시전 프로젝트 이후에도 뛰어난 팀의 특징을 찾기 위해 2년간 노력했다. 이름하여 아리스토텔레스 프로젝트이다. 2015년 11월 구글은 그 연구 결과를 일부 공개했는데, 중요한 부분을 요약하면 다음과 같다.

1. 팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다 팀원들이 어떻게 서로 상호작용하고 자신의 일을 바라보는지가 훨씬 중요하다.
2. 5가지 성공적 팀의 특징을 찾았는데, 그 중 앞도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이다.
3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.

 

1번은 앞서 올스타 팀이 실패하는 이유에서 그 중요성을 살펴보았다. 2번은 실수 관리와도 관련이 있는데, 여기서 심리적 안전감이란 내 생각이나 의견, 질문, 걱정 혹은 실수 시에 처벌받거나 놀림받지 않을 거라는 믿음이다. 에드먼드슨 교수의 연구에 따르면 실수율이 낮은 병원이 좋은 병원이 아니였다. 발견된 실수율은 해당 조직의 보고 문화와 관련이 깊었는데, 실수율이 낮은 조직은 실수를 적게 하는 것이 아니라 실수를 공개하는 것이 공격을 받을 수 있어 실수를 감추는 조직이라는 것이다.

 

 

 

좋은 팀에 있는지 측정하기

• 내가 이 일에서 실수를 하면 그걸로 비난받는 경우가 많다.
• 이 조직에서 남들에게 도움을 구하기 어렵다.
• 내 관리자는 내가 전에 한 번도 해보지 않은 걸 해내는 방법을 배우거나 혹은 새로운 일을 맡도록 격려하는 경우가 많다.(반대)
• 내가 만약 다른 곳에서 더 나은 일을 구하려고 이 회사를 떠날 생각이 있다면 나는 그에 대해 관리자랑 얘기를 나눌 것이다.(반대)
• 내가 나의 관리자에게 문제를 제기하면 그는 내가 해결책을 찾도록 도와주는 일에 그다지 관심을 보이지 않는 경우가 많다.

 

심리적 안전감을 높이려면 팀 토론 등 특별히 고안된 활동을 통해 토론 주제를 안전한 환경에서 이야기하게 해주는 것 자체가 심리적 안전감을 높일 것이다. 단순히 우리팀의 현황에 대해 열린 대화를 시작하는 것만으로 변화가 시작될 수 있다.

하지만 이 모든 것 이전에 우선적으로 중요한 것은 리더와 관리자가 새로운 프로그램을 도입하기 전에 매일 매일 팀원들과 갖는 마이크로 인터렉션에서 다른 행동 양상을 보여줘야 한다는 것이다. 일상적인 인터렉션에는 변화가 없으면서 토론만 하는 것은 오히려 신뢰가 깎일 것이다. 하지만 일상에서도 변화가 생기고, 신뢰가 조금씩 쌓인다면 이러한 특별한 활동이 의미를 갖게 된다.

 

 

 

 

[ 쾌속 학습팀 ]

리더의 중요성

기술적 변화의 순간인 패러다임 전환은 언제든 찾아올 수 있으며 IT 업계는 특히나 이런 전환 주기가 짧다. 개발자들에게 있어 학습이라는 것, 더 나아가 빠른 학습은 늘 고민거리이다.

빠른 학습 요인에 대한 분석 결과 교육 배경이나 경험 등은 학습 속도에 영향을 주지 못했다. 또한 기존의 실력과 경력 역시 상관이 없었다. 이 외에도 해당 팀의 경험이나 높은 위치의 경연진의 지지 및 프로젝트 심사와 결과 보고 등도 큰 영향을 주지 못했다.

중요한 것은 리더의 영향이였는데, 단순히 기술적 탁월함을 갖춘 사람보다는 학습 환경을 만들어주는 리더가 중요했다. 학습이 빠른 팀은 팀원을 뽑을 때부터 달랐다. 선발 자체가 매우 협동적이였으며 선발 기준도 달랐다. 단순 업무 수행 능력뿐만 아니라 얼마나 협력을 잘 하는지, 새롭고 애매모호한 상황을 즐기는지, 자기보다 높은 지위의 사람에게도 자신있게 의견을 제안할 수 있는지 등을 보고 뽑았다. 또한 학습 속도가 빠른 팀은 새로운 기술 도입을 개인의 도전이 아닌 조직적 도전으로 받아들였다. 개인이 새로운 개술을 획득해야 한다는 것이 아니라 함께 일하는 새로운 방법을 만든다고 보는 것이다. 그들은 자신이 팀원이 되었다는 사실을 자랑스럽게 생각하며 개선되는 모습을 본다는 생각에 흥분하였다. 마지막으로 그들은 심리적으로 보호되고 있었다. 새로운 시도에 열려 있고, 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는데 부담을 느끼지 않았다. 팀원들은 새로운 방식이 효과가 없어도 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는걸 강조했다. 그들은 개인 단위의 실험에서 그치지 않고 모두가 공유하는 실험을 했으며, 무엇보다도 학습이 실행과 동시에 이루어졌다.

 

 

팀원들의 학습 태도의 중요성

성공적인 조직의 사례를 살펴보니 리더와 팀원들의 학습 태도에 근본적인 차이가 있었다. 학습 속도가 빠른 팀은 이를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했다. 학습을 팀의 중대한 목표로 받아들였고, 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다. 반면에 실패한 조직은 학습을 개인의 과제로 치부했다. 학습보다는 단기 퍼포먼스를 중요시했고, 낙오의 위험성을 강조하며 팀원들의 실력이 부족하다고 불평했다. 이는 같은 회사의 이웃 조직 얘기이다.

 

 

팀원들의 학습 태도의 중요성

내가 팀장도 아니고, 정치적인 힘도 없다면 우선 자신의 학습 환경을 만들어야 한다. 개별 기술 이상으로 일하는 방식에 대해 실험을 해보자. 학습할수만 있다면 실패해도 괜찮으니 좌절할 필요가 없다. 학습과 일을 분리하지 말고, 하나로 만들면 된다. 30분이라도 업무 개선을 당장 시작해보도록 하자. 주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 만드는 것도 좋다.

 

 

 

[ 프로젝트 확률론 ]

직관을 따르면 손해를 보는 경우가 있는데, 이런 오류가 있는 직관을 인지적 편향이라고 한다. 일의 소요 시간 또는 일이 제시간에 끝날 확률 등의 추정에 이런 편향이 생긴다. 이러한 추정은 믿을 수 없지만 애자일을 도입하면 이러한 직관의 문제를 해결할 수 있다.

애자일은 고전적 방법과 달리 일을 공유한다. 각자 일을 얼마나 진행했는지 매일 공유할 뿐만 아니라 내 일, 네 일의 구분선이 뚜렷하지 않고, 사람들이 섞인다. 그러다보니 내 일이 빨리 끝나면 다른 사람을 도와줄 수 있으며 누가 가장 밀렸는지 확연하기 때문에 도와주기 쉽다. 또한 좋은 정보는 모두가 공유하게 되어 프로젝트의 속도를 높이는데 큰 도움이 되는 경우가 많다. 애자일에서는 1명만 발견해도 모두가 알게 되지만(or 조건), 고전적 방법에서는 모두가 각자 발견해야 모두 알게되는 것(and 조건)이다. 애자일은 좋은 일은 OR 조건으로 만들고 나쁜 일은 AND 조건으로 바꾸는 경향이 있다. 좋은 일은 1사람만 발견해도 퍼지는 것이고, 나쁜 일은 짝 프로그래밍, 코드 공유, 코드 리뷰 등을 해도 모두가 실수해야만 발생하는 것이다.

 

 

 

 

 

 

3. 애자일

---

애자일 개발 방법론은 1990년대에 모습을 드러내기 시작했다. 그 당시의 전통적인 소프트웨어 개발 방식이 비지니스적 상황, 고객의 요구와 맞지 않는다고 생각한 사람들이 있었고, 각자 자기들만의 개발 방식을 만들어서 실천하고 있었다. 그런데 이 방법들 간에는 크게 보아 유사성이 있었다. 그래서 이 방법들의 창안자 약 20명이 2001년에 스키장에서 선언문을 작성하게 되는데, 이를 애자일 선언문이라고 한다. 이는 공식적으로 유일하게 애자일을 정의한 문서이며, 자신들이 사용하는 방법 이면의 공통된 철학, 추가하는 가치와 원칙을 추려냈다.

당시 주도적인 소프트웨어 개발 방식은 계획 주도의 방식이였다. 초면에 꼼꼼하고 정교하게 설계하기 위해 엄청난 노력을 한다. 그러면 실행 단계는 간단해지며 예측 가능해진다고 생각하기 때문이다. 하지만 애자일은 불확실성이 높은 일에 대해 미리 분석하고 설계하는 것이 한계가 있으므로 이것이 불가능하다고 본다. 그러다보니 불확실성이 클 때 어떻게 해야 하는지를 고민하다가 나오게 되었다. 따라서 애자일은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있다. 그리고 우리가 지금까지 살펴봤던 학습(자라기)과 협력(함께)이 불확실성을 다루는 애자일의 핵심적인 구동원리이다.

 

 

 

[ 애자일의 씨앗 ]

애자일을 쉽게 10분 안에 전달해달라는 요구가 상당히 많은데, 불가능하다. 그래도 애자일의 가장 핵심이 되어 꽃피울 수 있는 씨앗을 한 문장으로 압축하면 “고객에게 매일 가치를 전하라”이다. 이 문장의 단어들은 각기 중요한데, 다음과 같이 여러 질문을 해볼 수 있다.

• 고객
  • 우리의 진짜 고객은 누구인가?
• 매일
  • 어떻게 점진적으로 가치를 전할 것인가?
  • 어떻게 보다 일찍, 그리고 자주 가치를 전할 것인가?
• 가치를
  • 무엇이 가치인가?
  • 지금 우리가 하는 일이 정말 가치를 만드는 일인가?
  • 지금 가장 높은 가치는 무엇인가?
  • 비슷한 수준의 가치를 더 값싸게 전달하는 방법은?
• 전하라
  • 가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?
  • 고객이 정말 가치를 얻고 있는가?

 

학습적인 면에서 “매일"은 학습의 빈도와 이른 시점(하루의 시작)에 해당한다. 불확실성이 높을수록 빈도는 높고 이른 시점은 빨라야 한다. 그래야 학습의 복리 효과를 얻을 수 있다. 그리고 좋은 학습은 질 높은 피드백에서 온다. 물론 가짜 피드백이라면 잘못된 학습이 될 수도 있다. 진짜 가치를 전달하면 우리는 진정한 피드백을 받을 수 있다.

협력이라는 면에서 “고객에게”는 그 중요성을 말하고 있다. 무엇이든 홀로 결과물이 나오는 경우는 거의 없고, 협력이 필수적이다. 여기서 고객은 모든 이해관계자이다. 협력 시에는 가치를 전하면 신뢰가 쌓이며 의사소통이 명확하고 구체적이게 되면서 협력이 쉬워진다.

 

 

 

[ 애자일 도입 성공 요인 분석 ]

애자일 도입 성공 사례 분석

애자일 도입 후 성공 요인을 분석한 결과 애자일 실천법 중에서 “고객 참여"가 가장 높은 원인으로 뽑혔다. 물론 고객 참여 외의 3가지 요인들도 모두 중요하다. 이 4가지가 모두 잘되어야만 애자일이 도움이 된다.

• 고객 참여
• 리팩토링
• 코딩 후 자동화된 단위 테스트 작성
• 코드 공유
• 짧은 개발 주기

 

그런데 많은 조직들은 고객 참여와 코드 공유를 미뤘고, 애자일의 도움을 받지 못했다. 왜냐하면 그것들은 “사람” 중심이기 때문에 고객이나 다른 개발자를 설득해야 하므로 사람과의 대면 및 충돌이 무서워 피한 것이다. 전문가팀은 초보팀과 달리 무섭고 두려워도 중요한 일이라면 그 일을 안하는 리스크를 인식하고 꾸준히 시도한다는 점에서 차이를 보였다. 

애자일의 성숙도가 낮은 조직에서 프로젝트를 성공적으로 만드려면 “고객 참여" 밖에 답이 없다. 이를 하지 않고 다른 것들과 씨름하는 것은 중요한 것에 대한 회피일 뿐이다. 반면에 성숙도가 높은 조직에서는 고객 참여보다 짧은 반복 개발 주기가 더 기여도가 높았다. 짧은 반복 개발 주기를 통해 고객 참여가 잘 안되는 상황을 보완할 수 있다는 의미로 해석하면 된다.

결국 프로젝트 성공의 가장 핵심은 고객 참여(함께)와 짧은 개발 주기(자라기)이다. 누군가는 현재 조직에서 고객 참여가 어려울 것 같다는 얘기를 한다. 하지만 앞서 언급하였듯 고객 참여란 고객 혹은 고객을 대표하는 사람의 참여이다. 진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 계속 노력하는 것이다. 이런 노력조차 시도할 수 없는 경우는 전무하다다.

 

 

애자일 코치의 중요성

애자일 도입을 성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었다. 뛰어난 애자일 코치의 특징은 다음과 같다.

• 의사소통 스타일(팀원, 상사, 팀장 등과)
• EQ 및 스트레스 하에서의 행동
• 리더십 및 코칭 스타일(동기부여 등)
• 회고를 통한 개인적 합슥 능력
• 개인적 성장 의지, 성장 사고관, 자기효능감
• 관찰 및 상황 파악 능력
• 일치적 행동(믿는 것을 행동에 옮기는 능력)
• 기술적 능력(중요하지만 필수는 아님)

애자일 코치는 팀장일 수도, 팀원일 수도, 사장일 수도 있다. 애자일 코치는 어느 누가 혹은 조직이 정해줄 수 있는 것이 아니며 조직적 정치적 위치와 관계가 없다. 오로지 자신의 선택일 뿐이다. 그러므로 내가 애자일 코치가 되겠다고 결심하는 것이 가장 중요하다. 또한 뛰어난 애자일 코치는 정해져 있는 것이 아니고, 누구나 성장을 통해 뛰어난 애자일 코치가 될 수 있다.

 

 

애자일 관련 내용 요약

1. 애자일을 도입해서 성공하는 조직들이 국내에 있다.
2. 애자일 실천법을 잘 실행하면 성공률도 높아질 수 있다.(애자일 초심자도 가능하다.)
3. 실천법 중에서 비교적 성공과 직결되는 것들이 존재한다. 그것은 고객 참여, 리팩터링, 코딩 후 자동화된 단위 테스트 작성, 코드 공유 등이다.
4. 애자일 성숙도가 낮은 조직일수록 고객 참여를 하지 않으면 프로젝트 성공이 어렵다.
5. 무섭고 두렵지만 중요한 일이라면 계속 미루지 말자.
6. 뛰어난 애자일 코치가 있는 것이 애자일 도입 성공에 핵심적이다.
7. 뛰어난 애자일 코치는 함께 자란다.

 

 

 

[ 당신의 조직에 새 방법론이 먹히지 않는 이유 ]

"어떤 기법을 사용하느냐?" 보다 "누가 사용하느냐?" 가 더 중요한 요소로 작용한다. 어떤 기법이나 방법론이 말하고자 하는 것은 지극히 부분적이며, 그것만으로는 해결이 불가능하다. 새 프로젝트 진행에 방법론 보다는 참여자가 훨씬 압도적으로 중요하다는 것이다.

만약 애자일을 도입하고 싶은 팀장이라면 “나는 어떤 팀장인가?”를 자문해봐야 한다. 내가 바뀌지 않고 새로운 방법론만 도입하는 것은 어떠한 효과도 없지만, 내가 바뀐다면 어떠한 방법론도 효과를 보일 것이다.

 

 

 

 

[ 애자일을 애자일스럽게 도입하기 ]

결국 어떤 방법론이 중요한 것이 아니고, 구조와 문화가 중요하다. 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 하면 문제가 된다. 애자일을 도입할 때 뭘 해야 하는지 명확하게 알려달라고하지만 이는 전혀 애자일적이지 않다. 찾아가는 것이 애자일이다. 방법론 도입은 매우 불확실하기에 정답이 있을 수 없으며 이전 경험이 이번에도 먹히지 않을 수 있다.

방법론은 태생적으로 불확실성이 높기 때문에 거의 모든 종류의 방법론 도입에 적용된다. 그럴때 현명한 전략은 정해진 수순을 따르는 것이 아니고, 주변 동료들과 함께 탐색하고 조금 나아가고 확인하고를 반복하면서 현재 맥락에 맞게 좋은 전략들을 스스로 만들어 나가는 것이다.

그리고 이 과정에서 함께 자라기는 중요한 나침반이 되어줄 것이다.

 

 

 

 

 

 

 

 

위의 내용은 김창준님의 함께자라기를 읽고 최대한 핵심만을 뽑아서 정리한 내용입니다. 좋은 개발자가 되기 위해서는 하드 스킬 뿐만 아니라 소프트 스킬 역시 상당히 중요하다고 생각합니다! 시간이 바쁘신 분들은 위의 내용들만 참고해도 충분하지만, 최근에 필독서로 꼽히는 책인 만큼 한번 쯤은 직접 읽어보시는 것을 추천드립니다ㅎㅎ