[함께 자라기] 2부 함께

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

조엘 스폴스키의 '개발팀 평가 테스트'

소스 컨트롤을 사용하는가?

한 번에 빌드를 만들어낼 수 있는가?

일일 빌드를 만드는가?

버그 데이터 베이스를 가지고 있는가?

새로운 코드를 작성하기 전에 버그를 고치는가?

최신 업데이트된 스케줄이 있는가?

스펙(제품 명세)이 있는가?

프로그래머가 조용한 작업 환경에서 일하는가?

돈이 되는 한 최고의 툴을 사용하는가?

테스터가 있는가?

채용 면접 때 후보가 코드를 짜게 해보는가?

복도 사용성 테스트를 하는가?

모든 항목에 "예"라고 답하는 것이 무조건 더 낫다고 동의하기 어렵다.

팀원들이 상시 의사소통을 할 수 있는 그런 공간이 생산성 향상에 많은 도움이 된다고 역설한 바가 있다. 팀 전체가 공유할 수 있는 '시끄러운' 공간을 주는 것도 생산성 향상에 도움이 된다. "비싼 툴을 쓰면 잘하겠지" 보다 기술에 맞는 스택이 훨씬 중요하다.

12가지 질문이 개발팀 평가에서 정말 중요한 요소인가?

항목들에 예스라고 체크하는 것을 목표로 삼지 말자

품질 전문가 제럴드 와인버그의 세 가지 근본적인 능력(소프트웨어 개발을 잘 관리하기 위한)

복잡한 상황을 이해하는 능력으로 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.

관찰하는 능력으로 무엇이 벌어지고 있는지를 관찰하고 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.

행동하는 능력으로 어려운 대인 상황에서 우리가 심지어 혼란스럽거나 화가 나거나 아니면 무서워서 도망쳐 숨어버리고 싶을 때에도 적절하게 행동할 수 있어야 한다.

높은 품질의 소프트웨어를 만들게 도와주는 관리자가 되려면 알아야할 것들.(QSM)

시스템적 사고

일차적 측정

일치적 행동

변화를 기대하기

도구: 소프트웨어 개발에 사용하는 모든 종류의 도구를 말한다. 컴퓨터, 모니터, 버그 트래커, 디버거, IDE, 햐항/구조적 개발 기법 등

사람: 사람들의 능력과 경험을 말한다.

시스템: 제품 자체의 복잡도, 요구되는 신뢰성, DB 크기, 타깃(VM 등)의 변화 가능성, 스케쥴 제약 등을 말한다.

관리: 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기를 고취하는 것, 작업 조건/환경을 개선하는 것, 자원이 준비, 리스크를 일찍 확인하고 적절한 조치를 취하는 것, 요구사항과 설계 스펙이 비준되게 돕는 것 등

협력을 통한 추상화

커뮤니케이션과 협력

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

시각화를 통한 협력은 전체보다 부분의 합이 더 클수도 있다.

톱니바퀴 실험

둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 요소가 필요하다. 이 요소는 추상화이며 혼자서 작업할 경우에는 이런 추상화의 필요가 상대적으로 덜하다.

추상화의 중요성

객체지향을 하면서 흥미로운 객체들을 발견하지 못한다면 너무 고리타분하지 않을까

추상화는 항상 가독성을 잃는 방향으로만 존재할까 싶다. 중복을 줄이다보면 어느새 늘어나는 역할들이 가독성을 잃게 만들고, 하나로 뭉치자니 중복이 발생하는 기로에 서게 된다. 객체를 지향하던 무엇을 지향하던 완벽한 코드는 없는 것 같다. 가독성은 상대적이며 추상화는 공감을 동반한다. 우선 순위가 있다면 가장 강력한 도구인 추상화이지 않을까.

추상화를 높일 수 있는 방법은 바로 '다른 시각을 가진 두 사람이 협력하기'

대화하는 프로그래밍

두 사람이 한 컴퓨터로 프로그래밍하는 것인데, 두 사람의 대화는 곧 추상화를 높이는 것이고, 컴퓨터는 구체화를 통해 검증하게 하는 것. 그 사이에 깨달음을 얻는다

주의해서 생각하지 않으면 프로그래밍은 특정 프로그래밍 언어로 명령문을 타이핑해서 넣는 것에 지나지 않는다. 대화는 우리가 혼자서는 생각하지 못했던 것들을 만들게 해줄 것이다. 대화는 기적이다.

혼자서 고민하지 말고 다른 사람들과 협동하고 대화해라.

오픈 소스 문화도 이런 특성 때문에 생기지 않았을까 나의 코드를 숨기고 간직하는 것보다 여러 사람들의 의견을 얻는 것이 서로에게 도움이 된다. 문제를 해결하는 그 잘난 코드를 혼자만 간직하지 마라, 어떤 사람이라도 작은 대화가 큰 도움이 될 것이다. 발칙한 상상이 그 대화의 아하 모먼트를 줄 수 있다. 나홀로 성장을 바라는 건 계속 우물에 있단 말과 같다.

신뢰를 깎는 공유인가, 신뢰를 쌓는 공유인가

신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다. 신뢰를 쌓는 데에 널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션이다. 자신이 한 작업물을 투명하게 서로 공유하고 그에 대해 피드백을 주고 받으며 인터랙션 하는 것. 이런 것을 소통 신뢰라고 한다. 상대가 자신이 가진 생각을 나에게 솔직히 말해줄 거라는 신뢰.

공유 조건별 신뢰도 변화 실험

하나 공유: 하나의 작업을 하고 그 결과를 공유하는 것.

최고 공유: 여러 개의 작업을 하고 자신이 최고라 생각하는 작업물 하나를 공유하는 것.

복수 공유: 여러 개의 작업을 하고 전부 공유하는 것.

하나 공유와 최고 공유는 오히려 신뢰감을 떨어뜨린다. 복수 공유는 신뢰감을 상승 시킨다.

복수 공유의 장점

복수 공유는 신뢰도 높아지고 성과도 더 좋았다. 신뢰를 쌓는 공유를 하자.

객관성의 주관성

새로운 개념을 도입하거나 설득해야 할 때 우리는 객관적 자료를 지표로 삼아 얘기하곤 한다. 이 '객관적 자료'가 상황에 따라 주관적이게 들릴 수도 있다. 나에게 객관적이라 함은 모두에게 객관적이 아닌 나의 주관이 들어갈 수 있다. 상대방에게도 마찬가지다 나의 객관적 의견이 상대방에게 들릴 때 주관적 의견이 될 수 있다.

감정을 배제할 수 없다.

의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다. 오히려 객관성을 유지하기 위해 이성과 감성을 분리하고자 하는 노력은 거의 불가능하다. 결국 사람을 이해해야 하고 설득 및 소통의 출발은 자료가 아닌 사람으로부터 출발하는 것이다.

결국, 객관성이라고 하는 것은 상대적이며(주관적이며) 설득을 하고 싶다면 상대를 이해하는 것부터 출발하자.

이것도 모르세요?

행동을 유도하는 대화

의사소통 및 멘토링, 코칭 능력이 떨어지면 음의 생산성이 극대화된다. 상대에 대한 배려가 없어 더 나아갈 힘마저 꺾어버리기 때문이다. 어쩌면 당연한 소프트 스킬임에도 불구하고 한 챕터에 적어둔걸 보니 심심찮게 보이는 상황같다.

상대의 무지를 지적하는 것보단 공감해주고 어떤 부분에서 힘들어하는지 캐치해야 한다. 오히려 같은 질문을 여러번 하는 것이 소통면에선 더 나을 수 있다. 문제를 어떤 시각에서 바라봤는지 그래서 어떻게 해결하려고 접근했는지 왜 그렇게 접근할 수밖에 없었는지 그래서 지금 어떤 상황인지 들어만 주고 물어만 봐줘도 충분한 소프트 스킬이다. 그 문제에 대해서 빠삭하게 알고 있지 않더라도 충분히 도와줄 수 있다.

하향식 접근의 함정

'전문가는 언제나 탑다운(top-down)으로 깔끔하게 생각할 것이다.' 추상성의 정도를 오가면서 때론 탑다운(top-down) 때론 바텀업(bottom-up) 방식으로 접근할 줄 알아야 한다. 모든 문제는 어떤 문제인지 명확히 알려주지 않는다. 때론 하나의 작은 구체적인 해결법들을 묶어줄 추상화도 필요할 것이며 지금 적용하고자 하는 방법이 최선이 아님을 경계해야 한다. 탑다운(top-down)에서 바텀업(bottom-up)으로, 바텀업(bottom-up)에서 탑다운(top-down)으로 생각을 전환할 때, '아하 모멘트!'가 찾아온다.

경력이 많다고 실력과 상관성이 높지 않다. 고수는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로, 도메인 어휘를 프로그램상의 어휘로 다시 바꿔 검증하는 상호 참조 전략(cross-referencing strategy)을 쓴다. 추상과 구상의 차원을 뜻하는 '두 세계'를 빈번히 연결하려는 노력을 기울인다.

조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나 현실은 불가하다. 마치 모든 레이어를 꿰뚫는 전문가가 있는 것처럼 만들려면

한 사람이 다기능을 갖추도록

협력이 쉽게 되도록

두 가지 방법으로 접근이 가능하다.

빠르고 빈번한 바통 터치가 가능한 전문가 조직

'삼투암적 의사소통'. 은연중에 서로 간에 정보가 스며든다. 사람들이 물리적으로 가까운 거리를 유지하고, 문제 해결에 대한 빠른 소통과 피드백, 그리고 대화에 참여하지 않더라도 해당 대화에 언제든 참여할 수 있다. 새로운 가치를 줄 수 있고 빠른 피드백의 장점과 더불어 대화에 참여하지 않고 듣는 것만으로도 조직 내부에 도메인 싱크가 맞춰진다. 한 번에 처리되는 양(batch size)을 줄여 지속적 흐름(continuous flow)을 만들어 짧은 시간 내에 탑과 바텀을 오가야 한다.

위의 아이디어를 웹 개발에 적용하여 추상화의 단게를 다섯 면으로 나눈다면,

전략(strategy)

범위(scope)

구조(structure)

뼈대(skeleton)

표면/비주얼(surface/visual)

더 높은 품질을 얻기 위해선 바텀-업, 탑-다운을 오르락 내리락 반복하는 것이 중요하며 개발의 5단계를 얼마씩 배치하고 진행해야 완벽한 일정이고 계획일지 고민하는 건 오히려 저품질로 가는 방법이다. 5단계의 범위를 얼마나 자주 '반복' 하느냐를 고민해야 한다. '얼마나 자주'.

전문가팀이 실패하는 이유

위대한 기업에서는 버스에 적절한 사람을 태우는 것이 우선이고 어디로 갈지 정하는 건 그 다음이라고 말한다. 스포츠에서 볼 수 있는 '올스타팀'의 성적은 그리 인상적이지 못하다. 최고의 전문가만 모여있지만 그 전략은 오히려 실패했으며 전문가들의 전문성이 유사하다. 유사한 전문성을 가진 전문가들이 모인다면 이러한 경향은 더 도드라졌다.

전문가와 비전문가로 나누고 협력의 개입 여부로 성과 지표를 연구한 결과를 토대로 소통의 중요성을 얘기한다.

전문가, 협력 개입 (가장 큰 양의 생산성)

전문가, 협력 비개입 (가장 큰 음의 생산성)

비전문가, 협력 개입 (비개입보다 큰 양의 생산성)

비전문가, 협력 비개입 (개입보다 작은 음의 생산성)

협력이 없다면 오히려 비전문가로 구성된 경우의 수보다 더 높은 음의 생산성을 기록했다. 그 원인은 정보 공유의 차이다. 협력이 개입된 경우 팀원들은 정보를 공유해서 더 통합된 해결책을 제시했고 협력 개입이 없으면 결과물은 서로 모순되는 등 통합되지 못했다. 전문가라고 해서 무조건 협력을 잘하는 건 아니다.

정리해서,

전문가들이 모아서 팀을 만든다고 잘하는 것은 아니다.

오히려 성과가 떨어질 수 있다.(협력 비개입시)

정보를 공유하고 협력을 잘하기 위한 명시적은 도움이 필요하다.

소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.

전문가보단 오히려 제너럴리스트(팀 내 다양성이 높은)가 팀에 더 도움이 될 수 있다.

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

팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.

5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감(Psychological Safety)이었다.

팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있다.

전문가들보단 제너럴리스트가 도움이 될 수 있고 협력이 없는 전문가팀은 음의생산성이 크다. 실수는 예방하지말고 관리해야한다. 실수를 감추려고, 공개하는 것이 곧 공격받을 수 있는 상황은 음지에서 음의 생산성을 키운다. 심리적 안전감이란 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀리받지 않을 거라는 믿음을 말한다. 대화의 화살이 상대를 향하면 안 된다.

아무리 좋은 의견이라도 신뢰가 없다면 변화가 생기기 어렵다. 마이크로 인터랙션을 통해 신뢰를 쌓고 심리적 안전감을 줄 수 있는 방법을 모색해야 한다.

팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 어떤 마이크로 인터랙션을 보여주고 있는지 되돌아 보자.

쾌속 학습팀

패러다임 전환, 죽느냐 사느냐

기술적 변화의 전환 주기가 특히 짧은 IT 업계의 개발자들에게 있어 학습이라는 것, 더 나아가 빠른 학습이라는 것은 늘 고민거리이다.

최소 침습 심장 수술

전통적인 심장 수술은 가슴을 완전히 열어젖히고 수술을 하지만, 최소 침슴법은 절개를 가능한 한 최소화한다. 환자 입장에서는 좋지만 의사는 괴롭다. 전혀 새로운 방법을 익혀야 하고, 수술 시간도 길어진다. 수술 시간은 기존의 방식보다 2~3배 길었다. 물론 수술을 거듭할수록 수술 시간은 점차 줄어들었지만, 시간 감소율이 팀마다 천차만별이었다.

학습 속도와 상관없는 것

교육 배경, 수술 경험 등은 학습 곡선의 기울이게 영향을 주지 않는다. 의사의 실력, 수술 성공률과 경력 연차가 통계적으로 상관성이 없다.

챌시아 병원 : 리더- 저명한 심장 외과의, 수술에 대해 이미 많은 경험

마운틴 메디컬 센터 : 리더- 경험이 부족한 젊은 외과의

하지만 마운틴 메디컬 센터의 수술 시간 감소율이 더 높았다. 경영진의 적극 지지, 지원 여부도 프로젝트 심사, 결과 보고 등 팀의 수술 시간 감소율에 영향을 주지 못했다.

무엇이 학습 속도를 결정하는 것일까?

리더가 팀 학습 속도에 미치는 영향

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

학습 환경의 차이

선발부터 다르다. 단순한 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 선발했다. 새로운 기술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.

학습 속도가 느린 팀은 새로운 기술에 대해 부정적 태도를 가지고 있다. 냉소주의는 전염성이 강하다. 새로운 기술에 대한 태도를 굳이 부정적으로 가져갈 필요가 없다.

신뢰가 충분히 쌓이고 심리적 안전감이 들면 팀은 빠른 속도로 나아갈 수 있다. 자유롭게 의견을 제시하고 수렴하고 실수를 관리하는 방향으로 나아가는 것이 결국 좋은 학습 환경을 만드는 것이다. 신뢰, 심리적 안전감, 공유, 실수 관리 등 이러한 환경이 조성되려면 새로운 기술에 대한 냉소주의 태도는 꽤 부정적일 것 같다.

기술 전환에 성공한 개발팀

낙오된 팀은 학습을 개인의 과제로 치부했다. 성공한 팀은 학습을 팀의 중대한 목표로 받아들였다.

낙오된 팀은 학습보다는 단기 퍼포먼스를 중요시했다. 성공한 팀은 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.

낙오된 팀은 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했다. 성공한 팀은 같이 학습해야 한다고 생각했다.

현실에서 실천하기

주변의 동료 및 상황이 여의치 않다면 나만의 학습 환경을 만들자. 좋은 리더와 좋은 문화가 자리 잡은 환경도 좋다. 하지만 반면교사 삼을 대상이 없는 것도 무조건 좋다고 할 수 없지 않을까

일과 학습을 분리하지말고 적용하자. 진정한 학습은 실행 속에서 이루어지고 진정한 실행은 학습을 수반한다.

'작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다.'

'크고 쓸모없는 설계'를 반면교사 삼는다면 얼마나 실감날지 알 수 있다. 주변에서 나와 함께 학습 환경을 만들 수 있는 '학습 공동체'를 구축하라. 그것이 쾌속 학습으로 가는 지름길이다.

프로젝트 확률론

어디에 돈을 걸 것인가

1-1. 속이 안 보이는 주머니 속에 빨간 돌 5개, 흰 돌 5개가 들어 있다. 임의로 하나를 꺼냈는데 빨간 돌이면 성공이다. 1-2. 속이 안 보이는 주머니 속에 빨간 돌 9개, 흰 돌 1개가 들어 있다. 꺼낸 돌을 다시 주머니에 넣으면서 총 7번 돌을 꺼내 색을 확인한다. 모두 빨간 돌이면 성공이다.

2-1. 속이 안 보이는 주머니 속에 빨간 돌 5개, 흰 돌 5개가 들어 있다. 임의로 하나를 꺼냈는데 빨간 돌이면 성공이다. 2-2. 속이 안 보이는 주머니 속에 빨간 돌 1개, 흰 돌 9개가 들어 있다. 꺼낸 돌을 다시 주머니에 넣으면서 총 7번 돌을 꺼내 색을 확인한다. 한 번이라도 빨간 돌이 나오면 성공이다.

직관의 허점

실제 이런 실험에서 직관적 선택을 통해 결과를 보면, 첫 번째 질문에서 2번을 선택하고 두 번째 질문에서 1번을 선택한다. 확률적으로 1-1은 0.5, 1-2는 0.48 2-1은 0.5, 2-2는 0.52 이다.

사람들은 통상 '그리고(AND)' 조건의 사건은 확률을 과대평가하는 경향이 있고 '또는(OR)' 조건의 사건은 확률을 과소평가하는 경향이 있다.

이러한 오류를 심리학에서는 인지적 편향이라고 한다.

이번 프로젝트는 제때에 끝낼 수 있을 것 같았는데

한 명의 관리자와 7명의 개발자가 독립적으로 하나의 프로젝트를 개발하고 있다. 7명이 각기 90% 확률의 확신으로 마감일을 지킨다고 답했다. '빨간 돌 흰 돌' 게임의 오류를 그대로 저지르고 있는 셈이다.

모든 개발자가 마감일을 지킬 확률을 0.9 * 7 / 7 로 계산하게 된다면 대푯값을 취하는 경향이 있어 평균의 악용이 된다. 이 경우는 0.9⁷ = 0.48 이 나온다.

일반적으로 일의 소요 시간을 추정할 때 사람들이 낙관적으로 추정한다. 추정하는 소요 시간에 적어도 2~3배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다.

애자일 확률론

애자일은 앞서의 고전적 방법과 달리 일을 공유한다. 역시 7명이 있고 모두 90% 확률로 (마감일을 지키는 것에) 확신을 한다면, 분명 몇 명은 일찍 끝내는 사람도 있을 것이다. 고전적인 방법에서는 일을 공유하지 않았기 때문에 일찍 끝내는 것이 이 프로젝트에 큰 도움이 되지 않지만 일을 공유한다면 얘기는 달라진다.

'그리고' 라는 독립적으로 실행되는 확률을 '또는' 의존적으로 실행되는 확률로 바꾸면 훨씬 높은 확률로 프로젝트 마감을 달성할 수 있을 것이다.

반대로 디버깅도 마찬가지일 것이다. 한 명의 개인이 버그를 발견할 확률은 10%라고 가정한다. 일을 공유하지 않는다면 해당 프로젝트(혹은 작은 프로세스)에서 버그를 찾아 수정할 확률이 10%밖에 되지 않는다. 하지만 일을 공유한다면 나 이외에도 다른 사람들이 순차적으로 모두 발견하지 못해야만 버그가 존재하게 된다. 한 사람당 10% 확률로 버그를 발견할 수 있고 7명이 일을 공유한다면 버그를 고칠 확률은 0.52가 된다. 단 한 번만 발견해서 수정하면 되니까.

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