[책리뷰] 함께자라기 (2) - 함께(협업)

목차

1. 자라기
2. 함께 (현재)
3. 애자일

---

함께 (협업)

두번째 파트인 ‘함께' 파트는 독자층이 개발자 팀원 보다는 관리자, 리더, 임직원들도 포함되어 있다는 느낌이 들었다. 이번 파트도 인상적인 부분을 요약해서 블록처리 하고, 그 아래에 내 생각을 정리해본다.

👉 소프트웨어 개발을 잘 관리하기 위한 세 가지 근본적인 능력

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

와인버그가 쓴 책으로 QSM은 4권으로 이루어져있는데, 생각하는 품질 높은 소프트웨어를 만들게 도와주는 관리자가 되려면 알아야 할 것들을 요약하고 있음
1. 시스템적 사고
2. 일차적 측정
3. 일치적 행동
4. 변화를 기대하기

내가 프로젝트나 팀 리딩을 하게 된다면 읽어볼만한 책 추천과 내용이라 책갈피 해두었는데, 지금 당장 나에게 필요한 내용은 아니다.

👉 소프트웨어 개발 비용

다음 네 가지 개발 비용을 주도하는 요소를 오름차순으로 나열 (QSM 4권에 소프트웨어 개발 비용에 대한 내용이 있음)
- 도구 : 소프트웨어 개발에 사용하는 모든 종류의 도구를 말함. 컴퓨터, 모니터, 버그 트래커, 디버거, IDE, 하향/구조적 개발 기법 등
- 사람 : 사람들의 능력과 경험
- 시스템 : 제품 자체의 복잡도, 요구되는 신뢰성, DB 크기, 타깃(VM)의 변화 가능성, 스케줄 제약 등
- 관리 : 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기를 고취하는 것, 작업 조건/환경을 개선하는 것, 자원의 준비, 리스크를 일찍 확인하고 적절한 조치를 취하는 것, 요구사항과 설계 스펙이 비준(validate) 되게 돕는 것 등

실제로 프로젝트가 아주 성공거나 실패하거나 하는 이유는 첫 번째가 관리라는 변수 때문이었음
하지만 각 분류별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선 노력이 있었던 분류는 바로 '도구'였음
도구 부분에서 상당한 개선을 이뤄내면 비용 면에서 세 배 정도의 개선을 얻을 수 있음
이에 비해 관리 부분에서 상당한 개선을 이뤄내면 비용 면에서 64배 정도의 개선을 얻을 수 있음

이 부분이 흥미로웠는 데, 관리를 상당 부분 개선하면 비용 측면에서 64배의 개선을 얻을 수 있고, 도구를 개선하면 3배의 개선을 얻을 수 있다고 한다. 그런데 각 부분별로 가장 많은 개선 노력이 있었던 분류가 바로 도구 라는 점이 놀라웠고, 공감이 갔다. 도구가 제일 구체적으로 개선할 수 있고 성능 지표도 확인할 수 있으니까 쉽고 확실한 개선 시도를 한 게 아니었을까. 무엇보다 관리는 변수가 너무 많아서 중요성과는 별개로 개선을 시도하기가 어려운 것 같다.

예전에 팀원들 간의 신뢰가 없고, 때로는 종종 상대방을 힐난하면서 팀이나 조직을 개선하려는 의지는 보이지 않았던 회사에서 일한 적이 있었다. 그래서 팀원들과 개선을 위해 여러 시도를 해봤었는데, 팀원들이 흩어지면서 결국 무로 돌아갔다. 나도 이직해서 그 회사의 상황은 모르지만 새로운 사람들이 많이 들어갔다고 하니 좋은 문화를 꾸려가기를 바란다.

프로젝트를 할 때 효율적인 도구나 최신 기술을 쓰는 것 보다, 올드하더라도 체계적으로 마음 맞는 사람들이랑 일할 때가 더 효율적이고 배로 많은 일을 할 수 있었다. 기본적으로 사람을 존중하지 않는 곳에서는 체계나 관리를 떠나서 무슨 일을 하던 심리적, 시간적 비용이 많이 든다. 대체로 그런 곳들은 이런 비용을 무시하기 때문에 개선의 시도가 쉽지 않고, 원인과 결과가 복합적이기 때문에 개선 액션을 취하는 것도 어려운 것 같다.

👉 추상화의 중요성

(저자의 말 중에서)
저는 때로 가독성을 손해보면서까지 중복을 줄이기도 합니다.
객체지향이서 그걸 하다 보면 흥미로운 객체들을 발견합니다.
함수형에서 그렇게 하다 보면 흥미로운 함수와 함수의 함수를 발견합니다.
흥미로운 무엇(바로 추상화)을 발견하는 대표적 방법으로 중복 제거만을 이야기 했는데,
제가 생각하는 흥미로운 무엇을 발견하는 방법에는 배경과 시각이 다른 사람과의 대화도 당연히 포함됩니다.

소프트웨어 공학의 역사는 정말 추상화를 높이기 위한 여정이었음
우리는 조금 전 추상화를 높일 수 있는 방법 하나를 찾아냄
바로 '다른 시각을 가진 두 사람이 협력하기' 임

짝 프로그래밍은 절묘한 구성을 가지고 있음
- 두 사람이 대화를 통해 추상화를 높이게 함
- 컴퓨터는 구체화를 통해 검증하게 함
- 미루고 헤아리는 것이 빈번히 교차하고 그 사이에서 "아하"가 터져 나옴

자신이 작성하는 코드의 추상성을 높이고 싶다면 다른사람들과 협동하고, 대화해야함
같이 그림도 그려보고 함께 소스코드를 편집해보기

나는 프로그래밍을 하면서 추상화하는 데에 숙련되지 않아서 그런지 저자와 동일한 경험은 하지 못했다. 하지만 소프트웨어 공학의 역사가 추상화를 높이기 위한 여정이라니. 너무 멋지고 신선한 말이다. 그러고보면 최신 기술이든 무엇이든 기존의 개념을 추상화하고 더 사용하기 쉽고 포터블하게 만들지 않았나? 우리가 도커를 쓸 때 그 안에 돌아가는 혁신적임을 이해하지 못해도 리눅스를 사용하고, 한 대에서 여러 서버를 띄울 수도 있고! ORM도 결국 사용자 입장에서 RDBMS와 NOSQL 같은 데이터베이스를 객체지향적으로 감싼 것 아닐까! 역시 실무와 별개로 컴퓨터 공학에 관련된 내용은 꾸준히 공부해야겠다.

다른 시각을 가진 두 사람의 협력에서 동료 개발자와의 짝 프로그래밍도 너무 도움이 많이 되었다. 그 사람이 알고 있는 도메인 지식과 코딩 방법 등 나와 다른 것을 알아가는데 너무 재밌고 신기했다.

이런 활동은 기획자와도 가능한데, 페어프로그래밍 때 처럼 모니터에 코드를 띄우는 대신 기획자가 제안한 최초 기획서나, 혹은 서로 대화하기 편하게 만든 시각 자료를 보면서 대화를 하는 편이다.

👉 모든 의사결정에는 감정적 판단이 선행된다

'품질이란 누군가에게 가치가 되는 것이다.' - 품질 전문가 제럴드 와인버그
사실 품질은 사람을 빼놓고 이야기할 수가 없음
그러면 우리가 품질을 이야기할 때에는 '누구'를 놓고 하는 말이냐는 걸 생각해 봐야함
이런 이유로 품질 관련 일을 하는 사람들, 고품질을 얻으려고 노력하는 사람들은 '인간'에 대한 이해가 필수적이라 생각함
사람들은 설득하기 위해 객관성이 필요하다고 생각함. 그런데 이 객관의 개념 자체가 매우 주관적임
결국 결정하는 것은 사람임. 마음에 안 들면 어떤 이유를 들어서든 반대하게 됨
가만히 보면 우리는 그동안 우리의 객관만 신경쓰는 실수를 저질러옴
마음에 안들면 어떤 '객관적' 자료를 갖다 줘도 설득할 수 없음
특히나 그 자료에 "당신의 생각이 틀렸다"라는 암시가 강하게 있다면 더더욱 설득이 어려움

논리적이라는 것도 상대적인 것. 그리고 논리랑 감정적 판단을 분리할 수 없음
의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없음
이런 사실에도 불구하고 감정과 이성을 깨끗하게 분리할 수 잇으며, 또 그렇게 해야 한다고 믿는 사람들이 많음
좌뇌와 우뇌의 기능을 깨끗하게 분리할 수 없는 것 처럼 감정과 이성을 분리할 수 없음
남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 함. 그래야 현실적으로 설득이 가능함
내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 함
출발은 결국 내가 설득하려는 사람에게서 하는 것임. 자료에서 출발하는 것이 아님

모든 의사결정에는 감정적 판단이 선행된 후에 이뤄진다. 누군가에게 가치를 전달하고 설득하기 위해서는 인간에 대한 이해가 필수적이라는 뜻일까?

나는 본인이 객관적이고 이성적이라는 말을 믿지 않는다. 객관적이고 이성적이란 단어는 사람마다 다른 의미를 부여한다. 그 단어들이 논리적으로 존재하는 게 맞는 지 의문이다. 우리는 누군가를 원하는 방향으로 상상하고 오해하는데, 본인을 볼 때도 마찬가지이다.

심지어 근거 자료를 바탕으로 의견을 주장해도, 다른 누군가에게는 객관적이지 않다니. 누군가를 설득하려면 상대방을 좋아해야하나.

👉 코칭할 때 대화 방식

* 공감하고 이해하려는 대화
공감하면서 듣고 상대가 어떤 멘탈 모델을 갖고 있는지 파악하기
그 사람이 이 상황에서 왜 이런 접근을 할 수 밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 제안을 해줄 수 있음
다 설명해줄 필요도 없고, 핵심적인 부분만 짚어주면 됨
또 소위 암묵지라고 부르는 것들을 전달해줄 수도 있음
이 방법은 누가 물어볼 때 뿐만이 아니라 누가 실수나 잘못을 했을 때에도 매우 효과적으로 도움을 줄 수 있음
훌륭한 팀장이라면 먼저 그 사람의 사고 과정과 전략을 이해하려고 함

* 행동을 유도하는 대화
코칭의 흥미로운 점은 코치 자신이 해당 영역에 대한 전문지식이 없어도 코칭하라 수 있음
저자의 코칭 경험에 따르면 코칭받는 사람은 스스로 약속한 것을 지킬 확률이 매우 높음

첫번째 공감하고 이해하려는 대화는 당장의 실천법이 떠오르지는 않지만 최대한 상대방이 어떤 생각으로 문제를 접근하고 해결하려고 했는지 먼저 물어볼 수 있을 것 같다. 그러면 상대방이 왜 그런 생각을 하게 되었는지, 어떻게 문제를 바라보고 있는지 이해할 수 있어서 서로 모르는 것과 알고 있는 것을 공유하기 더 좋을 것 같다.

그런데 두번째 행동을 유도하는 대화는 설명을 들어도 감이 잘 잡히지 않는다. 내가 이런 류의 피드백을 받았다고 인지한 적이 없어서 상대방이 이런 대화 방식을 선호할지도 의문이다. 이렇게까지 해야하나 싶기도 하다.

👉 전문가의 문제 접근 방법

- 잘 정의된 문제 : 출발 상태와 목표 상태가 명확히 알려져 있고 그 상태 간 이동의 규칙이 주어진 문제
- 잘 정의되지 않은 문제 : 무엇이 목표 상태인지 불분명하고 최초의 출발 상태에 대한 정보도 온전히 주어지지 않고,
무엇이 적법한 행동이고 무엇이 부적법한 것인지 규칙의 경계도 불투명함

전문가들은 자신이 자주 접하지 않았떤 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꿈
전문가는 추상성의 정도를 오르락내리락거리고,
특히 탑다운(철저하게 계획하고 단계적으로 접근하기)과 바텀업의 방향이 전환되는 시점들에서 '아하 순간'이 찾아옴

연구에 따르면 전문가는 프로그램을 이애할 때 참조 전략(cross referencing strategy)을 쓰는 반면, 하수는 그렇지 않았음
전문가는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로 번역함
그리고 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증하는 것을 상호 참조 전략이라고 함. 추상과 구상의 차원을 자주 오가는 것

예전에는 이거 해보고 어 안되네? 저거 해보고 어 안되네? 중구난방으로 일을 했었는데, 이제는 한번도 만들어본 적 없는 기능을 구현해야할 때 큰 틀에서 어떻게 해야겠다 초기 계획을 세우고, 그 계획이 조금 틀어지거나 내가 모르던 사실을 알게 되면 다시 세부 계획을 세워서 그 가설이 맞는지 구현해서 테스트하고 다시 큰 계획을 돌아오는 걸 반복하는 걸 의식적으로 하고 있다.

전문가가 왜 참조전략을 쓰는지 체감하지 못했지만, 내가 개발하는 기능과 로직을 다른 직군의 동료가 알아들을 수 있도록 도메인 언어로 풀어서 설명하는 것은 중요하다고 생각한다.

👉 프로젝트 생명주기

문제와 해결책에 불확실성이 높은 경우 단계적으로 접근하는 것은 더 낮은 품질로 가는 지름길
흔히들 말하는 개발의 5단계도 비슷함
어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다할 수 있을까를 고민해야 함

여러모로 애자일을 갑자기 도입하기가 쉽지 않겠다는게 느껴졌다. 애자일을 하기 위해서는 한 사람이 다기능을 갖추고 팀원간 협업이 쉬어야한다. 그리고 이걸 뒷받침하려면 서로 기본적인 신뢰를 갖추고 빠르고 구체적인 피드백을 주고 받아야겠지..?

애자일로 가기 위해서는 변해야할 것들이 있는게 그게 구성원들에게 체화되기까지 기다림의 시간이 필요할 것 같다. 그리고 팀에 애자일 전문가가 없다면 ‘변해야할 무언가'를 찾고 실험하고 발견해내는 시간도 오래 걸리겠지.

만약 어떤 사람이 좁은 영역과 자기 업무만 할 줄 아는데 갑자기 조직에서 자유롭게 협력하며 빠르게 싸이클을 돌라고 하면 뜬금없을 것 같다. 심지어 아무런 기반없이 애자일을 할 준비가 안되어 있고 이해도가 낮은 사람이 시키면 nodap...

어떻게 해야 점진적으로 변화를 시도할 수 있을까?

👉 심리적 안전감

저자는 구글에서 시행한 뛰어난 관리자의 특성을 찾는 프로젝트의 결과 중 중요하다고 생각하는 부분을 안내함
1. 팀에 누가 있는지보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요
2. 5가지 성공적 팀의 특징을 찾았는데, 그 중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감
3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선 가능

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

심리적 안전감을 측정하기 위한 질문 (모두 O를 유도하는 질문이 아님, 역질문 포함됨)
- 내가 이 일에서 실수를 하면 그걸로 비난을 받는 경우가 많다
- 이 조직에서 남들에게 도움을 구하기 어렵다
- 내 관리자는 내가 전에 한 번도 해보지 않은 걸 해내는 방법을 배우거나 혹은 새로운 일을 맡도록 격려하는 경우가 많다
- 내가 만약 다른 곳에서 더 나은 일을 구하려고 이 회사를 떠날 생각이 있다면 나는 그에 대해 내 관리자랑 이야기를 나눌 것이다
- 내가 나의 관리자에게 문제를 제기하면 그는 내가 해결책을 찾도록 도와주는 일에 그다지 관심을 보이지 않는 경우가 많다

이 모든 것 이전에 우선적으로 중요한 게 있다.
어떤 새로운 프로그램을 도입하기 전에 리더와 관리자가 매일매일 팀원들과 갖는 마이크로 인터렉션에서 다른 행동 양태를 보여줘야 한다.
일상적으로 벌어지는 인터렉션에는 변화가 없으면서 무슨 토론회 같은 것만 챙기면 오히려 신뢰가 깎인다
팀원들이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로 인터랙션을 보여주고 계신가요?

팀원들끼리 피드백을 활발하게 주고 받고, 실수를 관리하는 문화가 생기기 위해서는 심리적 안전감이 기반이 되야한다. 그래서 팀 주간회의를 할때 질문 과 관련된 액션, 친밀감을 높이기 위해 사적 대화 를 위한 액션을 하기로 했다. 아무래도 개발팀이 재택 근무가 기본이다보니 신입 분들께서 질문하거나 친밀감을 형성하기 더 어려울테니 편안한 분위기를 만들기 위해 동료들이랑 함께 액션을 설정했다.

👉 학습환경

단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다

학습이 빠른 팀은 팀원을 뽑을 떄 부터 다르다.
단순한 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았다.

새로운 기술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다.
개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.

냉소주의는 전염성이 강하다.

속도가 빠른 팀은 심리적으로 보호가 되고 있었다.
뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다.
팀원들은 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했다.
그들은 개인 단위의 실험에서 그치게 하지 않고 모두가 공유하는 실험을 했고, 무엇보다도 학습이 실행과 동시에 이루어졌다.

새로운 기술을 도입에 성공한 팀은 해당 팀에 그 기술에 숙련된 사람이 있는지는 큰 작용을 하지 못했다.
속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했다.
학습을 팀의 중대한 목표로 받아들였다.
리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.
반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했다.
학습보다는 단기 퍼포먼스를 중요시했다.
리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했다.

나는 팀장도 아니고 정치적인 힘도 없다. 이 상황에서 내가 무엇을 할 수 있을까?
우선 자신의 학습 환경을 만드는 것 부터 출발하자. 개별 기술 이상으로 일하는 방식에 대해 실험해보라.
학습과 일을 굳이 분리하지 말고 동체로 만들라.
그리고 학습 공동체를 구축하라. 주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 찾아라.

누군가를 비난하지 말고 함께 성장할 수 있게 노력하자.

👉 직관의 허점 (일정산정)

소프트웨어 공학 쪽의 연구에 따르면 사람들이 통상적으로 추정하는 소요 시간에 적어도 2~3배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다고 한다.
일반인들(의사와 같은 전문가 포함)의 확률에 대한 직관이 형편없다는 것을 고려할 때, 개발자들이 90%의 확률이라고 말했다는 것을 그대로 믿기 힘들다.
이 경우 확률을 계산하려면 0.9를 인원수만큼 곱해야한다.
즉, 모든 개발자가 90% 확률로 안심을 하고 있지만 전체 프로젝트 입장에서는 마감일에 맞출 확률이 1/2도 되지 않는다.
게다가 일반적으로 일의 소요 시간을 추정할 떄 사람들이 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다는 점까지 고려하면 상황은 더 심각해진다.

핵공감 😂 나도.. 일정 산정 정확하게 하고 싶은데요.. 이건 어떻게 연습해야하죠?

경험해본 작업은 얼추 산정하지만, 대부분 조금씩 변수가 달라서 일정에 오차가 꾸준히 발생해서 잘 모르겠음!

👉 애자일

애자일은 앞서의 고전적 방법과 달리 일을 공유한다.
각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다.
애자일에서는 되도록 사람들이 섞이도록 한다.
관심사의 섞임(mingling of concerns)을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문임
이런 식으로 학습한 지식은 한 사람이 모델링한 것의 위험을 피할 수 있다. (한 사람이 모델링한 모델 주도 접근법은 불리하기 때문)

개발자 중 누구 하나라도 먼저 일을 끝내면, 나머지 사람을 돕기 때문에 0.9 * 인원수보다 확률이 높아진다.
게다가 애자일에서는 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다.
그리고 좋은정보는 각자의 일에 모두 도움이 된다.
서로 판이한 일을 하는 것이 아니고 관련성이 있는 것들을 진행하기 때문이다.

이어지는 세번째 파트는 애자일 이다. 더 자세한 내용은 다음 파트에 대한 독후감을 작성해보겠다.