[밑줄긋기] 함께 자라기

애자일컨설팅 김창준 대표님의 저서. 나에 대해 돌아보는 것의 중요함을 절실히 깨닫개 해준 책.

직업인으로서 함께 자라기, IT기업 재직자로서 함께 자라고 매일 고객에게 가치를 전하기, 자연인으로서 함께 자라고 신뢰를 쌓아가기.


<1. 자라기>

p11-12. 이런 ‘학교 학습’과 반대되는 개념으로 ‘야생 학습’이 있다고 말합니다. 야생 학습의 특징은 아래와 같습니다.

야생 학습 학교 학습 
협력적 개별적 
비순차적 순서가 정해져 있음 
자료에 한정이 없음 교과서, 교재, 시험 범위 등이 정해져 있음 
명확한 평가가 없음 대부분 시험이라는 명확한 평가기준이 있음 
대부분 정답이 없음 무엇이 정답이라고 하는 것이 명확 
대부분 목표가 불분명하고 바뀌기도 함 대부분 합격, 자격증 같은 목표가 분명 

p21-22. 게임 결과를 분석한 결과, 우리는 다음 요소들이 생산성과 거의 또는 아예 무관하다는 사실을 발견했다. (중략)
경력 : 경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다. 단, 언어를 접한 경험이 6개월 미만인 개발자들은 전반적으로 나머지 개발자들보다 성적이 저조했다.
이렇게 전문가에 대한 새로운 정의, 즉 퍼포먼스의 수준으로 접근한 연구들을 통해 앞서 말한 바와 같이, 최소한도의 경험치만 넘어가면 경력 연수와 실제 직무 성과의 상관성이 낮다는 것은 소프트웨어 개발뿐만 아니라 다른 여러 영역에서도 동일하게 밝혀졌습니다.

p33-34. 더글러스 엥겔바트라는 사람이 했던 작업 구분에 대한 이야기를 해야겠습니다. 더글러스는 작업을 세 가지 수준으로 구분합니다. A, B, C 작업입니다. A 작업은 원래 그 조직이 하기로 되어 있는 일을 하는 걸 말합니다. 자동차 공장이면 자동차를 만드는 것이 A작업이 되겠죠. B작업은 A작업을 개선하는 걸 말합니다 (중략) C작업은 B작업을 개선하는 것입니다.

p47. 우리의 일자리가 인공지능으로 대체되지 않으려면, 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 하는 상황이 된 것입니다.

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

p91. 실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다. 실수에서 배우지 못하겠지요. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다.

p92. 실수가 없으면 학습하지 못합니다 (고로 직원들에게 실수하지 말라고 하는 조직은 학습하지 말라고 지시하는 것과 같습니다). 이는 학습이론의 기본입니다. 즉, 실수 관리를 하는 문화일수록 학습을 더 잘합니다.

->이 책을 읽으면서 얻은 아주 큰 수확

p100. 너무도 중요하기 때문에 다시 한 번 반복하겠습니다. 어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요합니다. 설사 나 혼자 하는 실천법이라고 해도 말이죠. 예컨대 상사가 내가 하는 일을 보고 반대하면 그를 설득해야 하며, 하다가 모르는 것이 생기면 주변에 물어봐야 하므로.

p103. 예전에는 소프트웨어 개발 전문성과 사회성은 별개로 치부되어 “프로그래밍 실력은 좋은데 의사소통 능력은 부족하다”든가 하는 이야기를 했다면, 이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 보게 된 겁니다. (중략) 그런 사회적 자본과 기술이 없는 상황에서 도메인 지식만 높으면 해당 지식의 확산과 성공에 오히려 장애가 되기도 합니다.

p105. (형상 관리 도구를 서브버전에서 깃으로 성공적으로 안착시킨 사례 vs 깃에 대해 발표도 하고 교육도 했지만 사람들이 수동적이라는 청중의 상황) 옆에서 지켜보던 제가 호기심이 생겨서 질문하셨던 분과 발표자에게 각기 동일한 질문을 드렸습니다. “그 조직원들이 선생님을 좋아하나요?” 질문자와 발표자가 상반된 답을 했으리라는 건 여러분도 짐작할 수 있지 않을까 하네요.

<2. 함께>

p110. 초기에는 대상에 대한 지식이 거의 없으니 일을 제대로 나눌 수가 없습니다. 사실 일을 가 장 잘 나눌 수 있는 때는 프로젝트가 완료되는 시점입니다. 그럼에도 불구하고 이 친구들은 초기에 일을 빨리 나눠 버렸던 거지요. 저는 이 일화가 우리가 협력에 대해 갖고 있는 인식의 현주소를 보여주고 있다고 생각합니다. 사람들은 협력이 중요하다고 합니다. 그래서 프로젝트를 할 때 협력적으로 하자고 합니다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋습니다. 그리고 안녕이죠. 각자 진행하고 나중에 만나서 서로 합쳐봅니다. 그 속을 들여다보면 협력은 거의 없습니다.

->회사 생활을 하면서 종종 겪는 일. 각자 맡은 일을 진행하기로 했는데, 나중에 만나서 맞춰보면 어긋나는 부분이나 서로 이해가 다른 부분이 꼭 있다.

p114-115. 품질 전문가 제럴드 와인버그가 한 말을 살펴봅시다. 이분은 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다고 했습니다.

  • 복잡한 상황을 이해하는 능력으로, 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.
  • 관찰하는 능력으로, 무엇이 벌어지고 있는지를 관찰하고, 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.
  • 행동하는 능력으로, 어려운 대인 상황에서 우리가 심지어 혼란스럽거나 화가 나거나 아니면 무서워서 도망쳐 숨어버리고 싶을 때에도 적절하게 행동할 수 있어야 한다.

p117. 관리, 시스템, 사람, 도구 순서였습니다. 이 실험뿐 아니라 통상적으로도 그러합니다. 실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유는 첫 번째가 관리라는 변수 때문이었습니다. 하지만 각 분류별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선 노력이 있었던 분류는 바로 ‘도구’였습니다.

->나도 마찬가지였다. 하는 일과 그 일을 하는 방식이 똑같은데, 거기에 이슈트래킹 툴 하나 도입한다고 해서 뭔가 바뀌길 기대한 것은 올바른 판단이 아니었다.

p119. 소프트웨어 개발 관리자는 예컨대 어떤 소스 컨트롤 툴을 사용할지 고심하는 것 외에도 노력해야 할, 중요한 것들이 있다고 생각합니다. 자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 되지 않을까 합니다.

p120. 일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어납니다. 우리가 생각하는 전형적 영웅 프로그래머와는 이미지가 정반대입니다. 게다가 실력이 뛰어난 프로그래머는 커뮤니케이션과 협력에 더 오랜 시간을 들입니다. 반면 설계나 코딩, 테스팅에 들이는 시간에는 통계적으로 큰 차이가 없었습니다.

p121. 집단의 성과가 부분의 합과 같다는 것은 더하기 때문에 시그마 모델이라고 부르며, 집단의 성과가 부분의 합을 넘는다는 것은 합이 아니라 곱하기 연산을 해서라고 봐서 파이 모델이라고 부르기도 합니다.

p131-134. 복수 공유의 장점

->시안을 하나만 만들어 공유하거나(하나 공유-share one), 작업한 시안 중 최고라고 생각하는 것 하나만을 공유하는 것보다는(최고 공유-share best), 공유할 때 여러 가지를 보여주는 것(복수 공유)이 가장 좋다. 상호 간의 적절한 피드백이 가능해지고, 그리고 실제 최종 결과물의 퀄리티도 가장 좋다.

p140.  마음에 안 들면 어떤 ‘객관적’ 자료를 갖다 줘도 설득할 수 없습니다. 특히나 그 자료에 “당신의 생각이 틀렸다”라는 암시가 강하게 있다면(그리고 그렇게 해서 그들의 코를 납작하게 해 주고 싶다면) 더더욱 설득이 어렵습니다.

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

->설득의 본질. 물론 협상은 다른 얘기겠지만.

p157. 비전문가일수록 자신이 만든 애초에 세운 계획에 집착했습니다. 오히려 전문가일수록 자신의 계획을 수정한 횟수가 많았습니다. 또한 전체 개발 기간 동안 자신의 개발품에 손댄 부분을 따져보면 비전문가는 아주 소수의 부분만 바꿨습니다만 전문가는 전체적으로 순을 대고 바꿔나갔습니다.

p161. 더 높은 품질을 얻기 위해서는 이 사다리를 오르락내리락 반복하는 것이 필요합니다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길입니다. 특히나 문제와 해결책에 불확실성이 높을 경우. (중략) 흔히들 말하는 개발의 5단계도 비슷합니다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마씩 배치할까로 고민하지 말고, 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다할 수 있을까를 고민해야할 것입니다.

->지금 읽고 있는 The Nature of Software Development에서 하는 이야기와 같은 주장.

p170. 팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로인터랙션을 보여주고 계신가요?

p176. 마지막으로, 속도가 빠른 팀은 심리적으로 보호가 되고 있었습니다. 뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았습니다. 팀원들은 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했습니다. 설사 새로운 방식이 효과가 없는 것으로 밝혀질지라도 말이죠.

p177. 반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했습니다. 학습보다는 단기 퍼포먼스를 중요시했습니다. 리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했습니다. 서로 다른 회사에 존재하는 팀 간의 이야기가 아닙니다. 심지어 옆자리에 있는 팀끼리도 이런 차이가 있었습니다. 즉, 학습 환경은 회사에 단일한 것이 아니고 동일 회사의 이웃 팀끼리도 큰 차이가 있을 수 있다는 말입니다.

p179-189. 프로젝트 확률론

->잘 이해하지 못했다.

<3. 애자일>

p215. 예를 들어 애자일 방법론 도입을 원하는 팀장이라면 “나는 어떤 팀장인가”를 먼저 자문해봐야 하지 않을까 싶습니다. 내가 어떤 팀장인지가 전혀 바뀌지 않으면서 새 방법론만 도입한다고 무슨 효과가 있을까요. 반대로, 항우울제보다도 강력한 설탕물을 쓸 수 있는 의사처럼, 별 볼 일 없어 보이는 방법론일지라도 그걸 처방하는 팀장에 따라 전혀 다른 효과가 있을 것입니다.

One thought on “[밑줄긋기] 함께 자라기

Leave a Reply

Your email address will not be published. Required fields are marked *