BookReview [함께 자라기 애자일로 가는 길]

읽은 기록

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

애자일에 관심이 생겨서 읽게 된 책으로 다른 책들을 먼저 읽다보니 조금 늦게 읽게 되었다.

1장의 내용은 스스로 객관화 하기 좋고 더 좋은 학습법 생각할 내용이 많아서 좋았고, 2장은 협력에 관한 내용으로 현재 팀이 있다면 적용해보기 좋은 내용이다.

3장은 좀 더 현업이나 적용에 따른 실제 사례들과 수치적인 내용으로 애자일이 진짜로 무엇인지, 나아가 실생활에 적용하는 방법까지 적혀있다.

짧은 책으로 정말 간단하게 읽기 좋은 책으로 책도 작아서 지하철이나 이동중에 읽기 편했다.

애자일 입문책으로 가장 적당하다고 생각한다.

머리말

“내가 정말 잘할 수 있을까? 아니, 우리가 정말 자랄 수 있을까?”

무엇이건 실제 바깥세상(야생)에 임팩트를 남기려면 혼자 힘으로만 되는 게 없는 것 같습니다.

함께 해야 합니다.

내 주변 사람들과 함께, 내가 매일 부대끼는 동료들과 함께..

하지만 안탑깝게도 우리는 함께보다 각자 하는 것에 익숙하고, 또 그렇게 강요받아 왔습니다.

세상은 함께 해야 뭔가 이룰 수 있는데 왜 우리는 혼자 하는 것만 배울까요?

사람들은 대부분 지식을 나누려고 하지 않고 자신이 힘들게 얻어낸 자기만의 보물이라고 생각하는 것 같다.

스스로도 남의 지식을 전수받은 것이 틀림 없는데 왜 그럴까..?

저자는 지금 잘하냐 못 하냐가 중요하지 않고 지금 자라나고 있는지에 집중해야 한다고 말한다.

결과보다 과정 즉, 과정에서 오는 결과가 훨씬 중요하다고 말한다.

우리가 스스로 날마다 함께 자라기를 할 수 있다면 어떨까..?

스스로 다음과 같은 질문에 답해보자.

• 내가 정말 자랄 수 있을까?
• 우리가 정말 함께 자랄 수 있을까?
• 우리가 정말 매일매일 함께 자랄 수 있을까?

마지막 질문에서 우리와 함께는 협력을 말하고, 자라다는 학습을 말한다.

그리고 매일매일은 그 접근 방법을 말한다.

이 책에서는 이 단어들을 깊이 있게 살펴보려고 한다.

각 목차가 자라기, 함께, 애자일(매일매일)이다.

나 그리고 남을 변화시키는 것에 대해 조금 더 역량이 생기고 작은 성공들을 만들어 나갈 수 있다고 생각한다.

이 책은 스스로 변하고 싶지만 계속 실패하는 사람, 조직을 개선하기 위한 시도를 하다가 오히려 데어본 사람, 하루하루가 답답한 사람들을 위해 이 책을 썻다고 한다.

이 책에서 말하고자 하는 본질은 애자일이라고 하는 일하는 방법의 핵심이라고 보면 된다.

하지만 사람들은 본질에 집중하기보다 지엽적인 실천법과 도구 들에만 집중한다.

이제 애자일에 첫 걸음을 떼어보자.

1장 자라기

우선 자라기부터 시작해보면 좋을 것 같다.

앞에서 말했듯이 자라기란 학습을 의미한다.

만약 한 가지 정보(경험적)를 탐색하는 과정에서 상반되는 정보를 발견했다면, 그것은 축하할 일이다.

교과서의 내용들이 서로 충돌할 일은 예외적이지만, 현실에서는 충돌하는 것이 정상이라는 것

모든 화살표가 같은 곳을 가리키는 것 자체가 이상한 일이다.

따라서 이런 상반된 의견과 정보 속에서 스스로 생각해 나가는 훈련이 필요하다.(주관을 기름)

이런 개념의 학습을 야생 학습이라고 한다.

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

학습의 본의는 야생 학습에 더 가깝다고 생각하고 현실 세계에서는 야생 학습이 더 많이 필요하다고 본다.

그래서 이 책에서 학습을 이야기할 때에는 대부분의 경우 야생 학습을 언급하는 것이라고 보면 된다.

어떤 경우에 야생 학습이 중요할까?

일반적으로 불확실성이 높은 경우일수록 야생 학습이 중요하다.

요즘 세상에는 더욱 더 불확실성이 높은 일들이 많고, 기술이 발전할수록 관심 또한 불확실한 쪽으로 기울게 되었다.

그럼에도 우리는 학교 학습에서 효과적이였던 방법들을 야생 학습에 가져와서 적용하려고 한다.

따라서 학습 방법을 학습해야 한다.

우리나라 사람들이 대부분 공유하는 판타지는 다음과 같다.

1. 숨겨진 곳에
2. 도인이 존재하며
3. 몇 년간 고립된 곳에서 별생각 없이 그가 시키는 대로 해야 하며
4. 그것이 지금은 납득되지 않지만 결국에는 나에게 좋을 것이라는 무조건적 믿음을 갖고 따르다 보면
5. 종국에는 비급을 사사받고 득도해서
6. 마지막에 하산한다는 것

교육학, 심리학 등의 연구에 따르면 위의 믿음 하나하나가 다 문제이다.

이러한 도인 메타포는 다양한 교육적 문제를 야기하는데, 앞으로 우리는 대체할만한 새로운 메타포를 찾는 여정을 떠나볼 것이다.

당신은 몇 년 차?

경력, 그 견딜 수 없는 무거움

강한 놈이 오래 가는 게 아니라, 오래 가는 놈이 강한 거더라

대다수 개발자는 소프트웨어 사업 대가의 기준에서 말하는 소프트웨어 기술자 등급별 노임 단가에 대해 잘 알 것이다.

기술자격 및 경험, 학력 및 경험을 기준으로 등급을 나누고, 각 등급에 맞는 노임 단가를 책정해 놓은 것이다.

그런데 소프트웨어 기술자의 등급이라는 것이, 겉으로는 기술자격이나 학력에 경험을 함께 고려하는 것 같아 보이지만 사실상 경험이라는 요소가 가장 결정적인 역할을 한다.

개발자의 가치는 그 사람이 이 업계에서 얼마나 오래 살아남았는지로 결정된다.

그래서 개발자를 뽑을 때에도 중급 이상을 뽑는 경우가 많다.

누군가가 중급 몇 년 차라는 사실로부터 그 사람의 실력에 대해 무엇을 얼마마큼 기대할 수 있을까?

저자는 이를 통해 다음과 같이 말한다.

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

직원을 뽑을 때 무엇이 그 사람의 실력을 가장 잘 예측할까?

존 헌터와 론다 헌터 그리고 프랭크 슈미트가 채용 시 가장 효과적인 예측변수가 무엇인지 연구했다.

잘 뽑았다는 것의 기준은 채용된 후에 실제 직무를 하면서 얼마나 생산적이고 성과를 잘 내는지이다.

통계적으로 본다면 채용 시 선발 여부를 고려하는 변수와 직무 성과라는 변수 양자 간의 상관성이 어떤가를 살펴봤다는 것이다.

상관성이란, 어느 하나가 올라가거나 내려올 때 다른 하나도 어느 한 방향으로 움직이는지 또는 움직이지 않는지 그 정도를 수치화한 걸 말한다.

부모의 경제적 수준과 자식의 학업 성적은 상관성이 꽤 높지만, 부모의 머리카락 길이와 자녀의 성적은 상관성이 매우 낮을 것

이 상관성은 1에서 -1사이의 값이 되며 0인 경우 상관성이 없다고 말하며 1(양의 상관성)이나 -1(음의 상관성)에 가까우면 상관성이 높다고 말한다.

통상 0.5를 넘는 경우가 흔하지 않고 0.5를 넘으면 강한 효과, 0.2 ~ 0.5 사이는 중간, 0.2는 약한 효과라고 한다.

그렇다면 사람을 뽑는게 얼마나 중요할까?

상관성 수치로 본다면 경력 연차와 상관성은 0.18, 학력의 상관성은 0.10이라고 한다.

상관성이 2.0 이하이면 약한 상관성으로 본다.

그에 반해 작업 샘플 테스트(채용 후 해야하는 작업에 대한 테스트)가 0.54, 아이큐 같은 지능 테스트가 0.51, 구조화된 인터뷰가 0.51정도로 강한 상관성을 보였다.

경력도 의미없는 수치는 아니지만 상관성이 약하다.

대학교를 갓 졸업한 신입과 2년 차 프로그래머중에는 후자가 더 잘할 확률이 있지만 반대로 5년차와 10년 차의 연차 차이는 실력을 판단하는 데 있어 큰 의미가 없다.

소프트웨어 개발에서 경력과 실력

앞 서 다룬 연구는 범용적인 지표이기 때문에 소프트웨어 분야에서의 경력과 실력은 다르다고 말할 수 있다.

경험성이 많은 사람(없는 사람과 비교해)을 전문가로 본 연구에서는 그들이 문제를 이해하는 데 더 많은 시간과 노력을 기울이는 것으로 밝혀졌다.

이 결과는 요구 사항 분석에 시간을 더 써야 한다는 이야기의 근거로 사용되기도 했다.

하지만 실력이 뛰어난 사람은 실력이 보통 정도인 사람과 비교해 문제를 이해하는 데 시간을 적게 쓰는 것으로 나왔다.

경력: 경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다.
경력과 생산성은 아무 상관관계가 없었다.
단, 언어를 접한 경험이 6개월 미만인 개발자들은 전반적으로 나머지 개발자들보다 성적이 저조했다.

연구 결과는 업무 수행 능력과 경력이 깊은 상관성이 없다고 밣혔다.

즉, 최소한도의 경험치만 넘어가면 경력 연수와 실제 직무 성과의 상관성이 생각보다 낮다는 것은 소프트웨어 개발뿐만 아니라 다른 여러 영역에서도 동일하게 밝혀졌다.

중요하다고 생각하는 것이 중요하지 않다

저자는 개발 프로세스 컨설팅을 하며 소프트웨어 프로젝트 성공을 위해 고민 하면서 사람이라는 요소가 정말 중요하다는 교훈을 얻었다고 한다.

나도 프로젝트를 여러개 진행해 보면서 마찬가지로 개발에 가장 중요한 부분은 커뮤니케이션이라고 생각한다.

몇몇 회사들은 능력으 등한시하고 경력을 중시하는 경향이 있다.

그렇다면 사람을 잘 뽑기 위해선 뭘 봐야할까?

구조화된 인터뷰와, 실제 작업을 해보도록 하는 작업 샘플 테스트, 그리고 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것을 권장한다.

잘 뽑는 것 이상으로 중요한 것

사람을 잡 뽑는 것도 중요하지만 그 이상으로 중요한 뽑은 사람을 어떻게 쓸 것 인지도 문제다.

많은 조직이 사람을 뽑는 것에는 신경을 쓰지만 이후 어떻게 교육, 훈련시키고 성장시킬지는 깊이 고민하지 않는다.

조직이 윈윈하기 위해선 개인의 전문성을 발전시키고 관리할 수 있게 최대한 지원을 해줘야 한다.

뽑고 나서 잘 교육하고 성장하게 도와주는 것 이상으로 중요한 것이 시스템이다.

아무리 훌룡한 사람이라도 조식의 시스템과 문화에 문제가 있으면 그런 사람은 묻혀버리고 쉽고, 반대로 실력이 평범한 사람이라도 좋은 시스템 속에서 뛰어난 성과를 낼 수도 있다.

개발자들이 할 수 있는 것

소프트웨어 개발에서 점차 경력 연수를 중시하는 문화가 사라질 것이다.
따라서 개발자들은 자신의 경력 연차외에 다른 것에도 신경을 써야 한다.

몇 년 전 1만 시간 법칙이 유행을 했는데 이 말을 “특정 분야의 전문가가 되기 위해선 1만 시간이 필요하다”라고 이해한 사람들이 많았다.

1만 시간의 주인공은 말한다.

55년 동안 걸었다고 걷는 게 점점 더 나아지고 있는 건 아닙니다. (중략)
자신이 즐기는 걸 한다고 해서 더 뛰어나게 될 것이라고 믿는 것은 미신이다.

1만 시간의 법칙에서 말하는 1만 시간은 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련을 말하는 것이다.

이러한 수련을 의도적 수련이라고 하며 그냥 경험이 아닌 특수한 형태의 수련 방법이다.

연구에 따르면 악기 연주자에게 공연 시간은 의도적 수련이 되지 못하며, 체스 선수에게는 토너먼트 시간이 의도적 수련이 되지 못한다고 한다.

다시 말해 그 시간들은 실력을 예측하지 못한다.

정말 기량 향상을 목적으로 자신의 약점을 개선하려고 애쓰는 수련, 그것만이 의도적 수련이다.

다시 스스로 시간을 계산해보면 상당히 적은 시간이 나오게 된다.

하지만 업무를 하면서도 의도적 수련을 할 수 있는 방법이 있다.

바로 애자일이다.

애자일은 소프트웨어 개발의 가장 큰 병목 중 하나로 본다.

일반적인 프로젝트에서는 모든 피드백의 주기가 느리다.

예를 들면, 내가 설계 단계에서 했던 결정의 피드백을 몇 달 후에 받는다.

그 때쯤이면 왜 그런 결정을 했는지도 가물거리고, 설사 기억이 안난다고 해도 아무렇지 않게 지나치기 쉽다.

내가 과거에 잘못한 실수는 한참 전에 지나가 버렸고 이제 와서 이걸 교정할 기회가 없기 때문이다.

하지만 애자일 프로젝트에서는 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후, 일주일 후 등 여러 주기를 통해 지속적으로 얻을 수 있다.

그리고 그때 저지른 실수는 바로 다음 주기에서 교정할 수 있다.

피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것

이 두 가지가 학습에 어떤 차이를 불러일으킬지 쉽게 상상이 되지 않는 우리를 위해 2가지 예가 있다.

골프 퍼팅 연습을 하는데, 공이 어디로 가는지 전혀 보지 않고 1,000개의 공을 찬다고 생각해 본다면, 이건 도대체 뭘 연습하고 있는 걸까?

뭔가 연습이 되긴 하겠지만 정확히 퍼팅하는 부분은 연습이 되지 않을 것..

내가 잘했나 못 했나 알지 못하면 행동을 조정할 수가 없다.

그래서 학습에서 피드백이 중요하다.

두 번째는 피드백 시점에 대한 예이다.

스키너의 상자 속에 생쥐 한마리가 있고 거기에는 버튼과 먹이가 나오는 대롱이 있다.

버튼을 누르면 먹이가 나오지만 생쥐는 처음엔 그 관련성을 모른다.

우연히 부딪혀서 몇 번 먹이를 받아먹은 후에는 배고플 때마다 직접 버튼을 눌러 먹이를 먹는다.

이는 학습을 한 것이다.

하지만 영원하게 학습하지 못하게 할 수 있다.

버튼을 누른 시점과 먹이가 나오는 시점 사이의 간격을 조금씩 늘려가다 보면 생쥐가 학습하지 못하는 지점을 찾을 수 있다.

즉, 인간도 피드백의 주기가 길어지면 학습이 잘 안되는 것이다.

골프 퍼팅 연습의 피드백이 1년 후라면 학습이 과연 제대로 될까..?

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

저자는 항상 일이 끝나면 회고를 진행한다.

연말에는 한해를 되돌아보고 반성하는 일 년 회고를 한다.

내가 올해에 어떤 것을 했고, 어떤 것을 느꼈고, 어떤 교훈을 배웠는지 짚어본다.

보통 이런 회고는 혼자 하기보다 주변의 지인들과 함께한다.(서로 자극이 된다.)

나도 최근에는 프로젝트, 참여 대외활동, 1년 회고등을 진행하였다.

일 년 회고를 할 때 항상 되짚어 보는 것 중 하나가 자신에게 얼마나 투자했는지이다.(자기계발)

자기계발이 중요한 이유는 현재 나에게 무엇을 투자했는지에 따라 1년, 2년뒤의 내가 달라지기 때문이다.

예를 들어 올해 업무도 잘한 것 같고 사람들에게 인정을 받는다고 느낀다면 1~2년 전을 되돌아 보면 된다.

아마 그때 열심히 자기계발을 했을 것이다.

반대로 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제없는 것 같지만 내년이나 내후년에는 분명 추락을 경험할 것이다.

자기계발의 업계 표준을 살펴보면 1~2시간이 압도적으로 많다.

하루 평균 1시간도 투자하지 않는 사람은 자기계발이란 면에서 직장인의 하위 1/3에 속하는 셈이다.

무서운 사실은 이게 축적되면 엄청난 차이를 만들 거라는 점이다.

자기가 습득한 지식이나 능력은 복리로 이자가 붙기 때문이다.

아인슈타인이 그랬듯이 복리는 정말 대단한 개념이다.

따라서 더 빨리 자라고 싶다면 1) 어떻게 이율을 높일 것인가 와 2)지속적으로 현명한 투자를 하려면 어떻게 할 것인가를 고민해야 한다.

복리의 비밀

자기계발과 복리의 관계를 좀 더 상세하게 설명하기 위해 먼저 더글러스 엥겔바트라는 사람이 했던 작업 구분에 대해 알아본다.

작업을 세 가지 수준으로 구분한다.

A 작업은 원래 그 조직이 하기로 되어 있는 일을 하는 걸 말한다.

자동차 공장이면 자동차를 만드는 것이 A 작업이다.

B 작업은 A 작업을 개선하는 걸 말한다.

제품을 만드는 사이클에서 시간과 품질을 개선하는 것이다.

C 작업은 B 작업을 개선하는 것이다.

개선 사이클 자체의 시간과 품질을 개선하는 것이다.

ex) 인프라 설계

개선하는 능력을 개선하는 것

A 작업은 겉으로 가장 잘 드러나는 수준으로, 한 회사의 제품과 서비스의 개발, 생산, 판매와 관련이 있다.  

그 회사의 사람과 자원의 대부분은 이 수준에 초점이 맞춰져 있다.

하지만 다음 수준인 B 작업 없이는 효과적인 A 작업은 불가능할 것이다.

B 작업은 회사가 자신의 제품과 서비스를 개발, 생산, 판매하는 걸 가능케 해주는 시스템과 프로세스를 설계하는 것과 관련이 있다.

하지만 가장 미묘하고 또 잠재적으로 가장 영향력이 있는 것은 C작업으로, 이는 우리의 사고방식과 사호 적용 방식을 개선한다.

궁극적으로는 C작업의 품질이 우리가 설계하는 시스템과 프로세스의 품질을 결정짓고, 나아가 우리가 제공하는 제품과 서비스의 품질을 결정짓는다.

과연 이렇게 중요한 C작업을 어떻게 접근해야 할까?

일반적인 구조로 일하는 조직과 복리 구조로 일하는 조직의 큰 차이점은 첫 주기에 만들어낸 결과물을 계단 삼아서 다음 주기에는 조금 더 높은 위치에서 다음 결과물을 만들어 낸다는 것이다.

조직을 예로 들었지만 이러한 복리 구조는 어디에나 적용 가능하며 스스로도 적용할 수 있다.

이렇게 작업을 하게 된다면 어떤 일이 생길까?

매일 매일 더 나은 내가 되어 간다.

복리 효과로 마치 게임의 스킬처럼 점점 더 종아지고 빨라진다.

이런 기술을 부트스트래핑이라고 한다.

나의 A 작업을 개선하려면 다음 두 가지 질문을 해 봐야 한다.

첫 번째는 어떻게 하면 더하기보다 곱하기를 할 수 있을 것인가?

두 번째는 어떻게 해야 곱하기 하는 비율을 높일 수 있는가?

이 질문은 평생의 화두이긴 하지만 저자가 깨달은 몇 가지 힌트가 있다.

• 자신이 이미 갖고 있는 것들을 잘 활용하라
  • 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮어버릴 수 있다. 자신이 올해 몇 권을 읽었다고 자랑하지 말고, 내가 그 지식을 얼마나 어떻게 활용하는지 반성해라
  • 이미 갖고 있는 것들을 하이퍼링크로 서로 촘촘하게 연결하라. 노드 간 이동속도가 빨라질 수 있도록 고속도로를 놔라. 즉, 이미 습득한 지식, 기술, 경험등을 서로 연결 지어서 시너지 효과가 나게 하고 하나의 영역에서 다른 영역으로 왔다갔다하는 것을 자주해서 다른 영역 간을 넘나들기가 수월해지도록 하라
  • 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌을 시도하라
  • 현재 내가 하는 일이 차후에 밑거름이 될 수 있도록 하라
• 외부 물질을 체화하라
  • 계속 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다. 주기적인 외부 자극을 받으면 좋다. 단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다. 마치 인체가 음식을 먹어 자기 몸의 일부로 만들듯이, 외부 물질을 받아들이면 소화해서 자신의 일부로 체화해야 한다.
  • 외부 물질 유입 이후 생긴 내부의 갈등을 해결하려는 데에 노력을 기울여야한다. 무시하고 덮어두지 말라. 내가 가진 것들의 상생적 관계를 끌어내도록 하라.
• 자신을 개선하는 프로세스에 대해 생각해보라.
  • 예컨대 나의 A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라(C작업)
  • 나를 개선하는 과정(B 작업)을 어떻게 하면 개선할 수 있을지 고민하라
• 피드백을 자주 받아라
  • 사이클 타임을 줄여라. 새로운 정보를 얻었다면 1년 후에 크고 완벽한 실험을 하려고 준비하기보다는 1달, 혹은 1주 후에 작게라도 실험해보는 것이 좋다. 순환율을 높여라
  • 일찍, 그리고 자주 실패하라. 실패에서 학습하라
• 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라
  • 일례로, 전설적 프로그래머 워드 커닝햄은 자기의 수족을 마음대로 놀릴 수 없는 불편한 언어에서 프로그래밍을 하는 경우 점차적으로 자신을 도와주는 환경을 만들어 나간다. 나의 속도를 늦추는 것들을 중력에 비유한다면, 워드는 중력을 점점 줄여나간다고 할 수 있다. 중력을 요만큼 줄였기 때문에 그 덕으로 몸은 가벼워지고, 또 그 때문에 중력을 줄이는 작업을 좀 더 쉽게 할 수 있다. 이런 식으로 되먹임을 해서 결국은 거의 무중력의 공간을 만들어낸다. 결국 그는 어셈블리 언어에서도 우아한 참을 출 수 있다.
  • 완벽한 도구와 환경을 가지는 데에 집착해서는 안 된다. 그런 식으로는 무엇도 영원히 얻을 수 없다. “방이 조용해지고 배도 안 고프고 온도도 적절해지면 공부 시작해야지”라고 생각하는 사람들 중에 1등은 없다. 또한 그런 환경이 되어도 몸에 배어든 습관 때문에 오히려 공부를 하지 못할 것이다.

학습 프레임과 실행 프레임

EBS다큐에 나온 한 실험으로 초등학교 아이들을 무작위로 두 그룹으로 나눈다.

한 그룹은 실행 프레임 “그림을 얼마나 잘 그리는지 보고 이야기하며 점수를 매기는 그룹”

다른 한 그룹은 학습 프레임 “내가 안 그려본 방식으로 실험해 보는 시간을 가지는 그룹”

즉, 실행 프레임은 잘하기에 초점을 맞추고 학습 프레임은 자라기에 초점을 맞춘다.

정해진 그림 그리는 시간이 끝나면 실행 프레임의 아이들은 놀기 바쁘지만 학습 프레임의 아이들은 이후에도 그림을 그리고 있는 모습을 보인다.

이후 학습한 정도를 비교해봐도 학습 프레임의 아이들이 더 많이 학습한 것으로 나타났다.

이는 여러 분야(사회학, 심리학, 교육학)에서 여러 연구를 통해 거듭 발견된 현상이다.

여기서 실행 프레임은 사람들이 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀이다.

학습 프레임은 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀을 말한다.

실제 사회에서 업무 중에 실행 프레임만으로 세상을 바라보는 사람들이 대다수이며, 인정 받아 다음 단계로 올라가냐 아니냐에 관심이 많을 것이다.

단계로 가지 못한다면 자신이 속한 곳에서의 학습 기회를 보기보다 다른 경쟁체제와 다른 타이틀, 다른 자리에 관심을 두게 되고 이는 학습의 저하로 이어진다.

실행 프레임은 여러분의 목표가 학습을 통한 성장이라면 불리한 선택입니다.

혹자는 이런 이야기를 할 수 있다.

“현재 상황 자체가 어렵지 않냐. 업무 하면서 학습이 중요하다는 생각을 갖기가 어렵지 않냐”

하지만 누구는 동일한 자극/조건이 주어졌을 대 어떤 사람은 더 많은 학습과 성장의 기회를 찾고 오히려 그 조건을 자신에게 유리한 조건으로 생각하기도 한다.

코딩 구루의 이야기

입사한지 1년 정도된 사원의 이야기다.

A는 아직 1년도 되지 안항서 책과 코드를 보며 배워가는 단계라고 한다.

그래서 딱히 누구에게 물어보지 않고 또 아직 업무 파악이 안 된지라 누굴 도와주거나 할 입장도 아니라고 한다.

B사원은 아직 1년도 되지 않아서 많이 물어보고 배우고 있다고 한다.

공부하고 싶은 주제로 팀내에서 스터디를 만들어 운영중이며, 출 퇴근 시간에 어려움을 겪는 팀원의 이야기를 듣고 1년도 안 되어서 시간이 있으니 해당 프레임 워크를 분석하여 도와준다고 한다.

두 사람의 대답은 모두 1년차라는 점에서 동일하지만 그 뒤의 자신의 선택과 행동, 반응은 전혀 달랐다.

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

2016년 알파고의 등장 그리고 최근 GPT의 등장으로 많은 사람들은 자신의 일자리가 사라질 것이라고 두려워 했다.

학습에 유리한 조건, 불리한 조건

이런 인공지능 시대에 대비하려면 배우기 힘든 것에 집중해야 한다고 말한다.

알파고를 예로 들어 본다.

알파고가 대단하기는 하지만 모든 경우에 만능이 아니라 자신에게 유리한 전장이 있고 그렇지 못한 전장이 있다.

알파고 같은 인공지능 시스템에 유리한 조건은 다음과 같다.

• 목표가 분병하고 객관적으로 정해져 있으며 정적이다.
• 매 순간 선택을 할 수 있는 행동/선택의 종류가 유한하게 정해져 있다.
• 매 순간 자신이 목표에 얼마나 근접했는지를 알 수 있다.(피드백이 빨리 이루어진다.)
• 주로 닫힌 시스템(예상하지 못한 외부 요인이 들어오지 않는다.)속에서 일한다.
• 과거의 선택과 결과에 대한 구조화된 기록이 많다.

이런 면에서 바둑은 알파고에게 비교적 유리한 환경이다.

집이 많으면 이기고, 19x19 반상 안에서만 돌을 놓고, 매 시점 대략적인 집수 계산이 가능하며, 갑자기 상대가 소리를 지르거나 영향을 주지 않고, 과거의 기보가 많다.

그런데 이 다섯 개의 조건은 사실 인간이 학습 하기 좋은 환경의 조건이기도 하다.

이는 샨토가 발표한 전문성이 드러나는 직업 특징에 대한 연구에서도 비슷하게 나타난다.

피드백이 주어지고 작업이 반복되며 객관적인 분석이 가능한 경우에 해당 직업에서 전문성이 잘 드러난다는 것

학습이 잘 일어나는 조건

학습이 잘 일어나는 조건은 같지만 속도 면에서는 인공지능이 인간을 우습게 뛰어넘어 버린다.

여기서 딜레마가 생기게 되는데 우리의 일자리가 인공지능으로 대체되지 않으려면, 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 하는 상황이 된 것

그렇다면 학습하기 힘든 환경과 주제를 생각해보면 된다.

• 목표가 모호하고 주관적일 수 있으며 동적이다.
• 매 순간 선택할 수 있는 행동/선택의 종류가 불확실하다.
• 매 순간 내가 목표에 얼마나 근접했는지를 알기 어렵다.
• 주로 열린 시스템 속에서 일한다.
• 과거의 선택과 결과에 대한 구조화된 기록이 별로 없다.

이런 환경은 소위 암묵지, 직관같은 것들이 작동하는 회색영역이다.

실제로 이런 영역에서는 어떤 역량이 중요할까?

컴퓨터로 대체되기 힘든 일

옥스퍼드 대학교에서 고용의 미래라는 논문으로 702개의 직종이 미래에 컴퓨터로 대체될 확률을 계산했다.

연구자들은 어떤 직업이 컴퓨터로 자동화가 가능한지 평가하게 했다.

연구자들이 확신을 갖고 평가한 직업은 총 70개였고 그중 대략 절반은 자동화 가능, 절반은 그렇지 않은 직업으로 나눴다.

그리고 기존 연구 리뷰와 워크숍을 통해 컴퓨터화에 병목이 되는 카테고리 3개를 선정했다.

지각과 조작, 창의적 지능, 사회적 지능이다.

그런 다음 해당 카테고리에 속하는 변수들 9개를 찾았다. 그 중 5개의 내용은 다음과 같다.

• 독창성: 주어진 주제나 상황에 대해 특이하거나 독창적인 생각을 해내기, 혹은 문제를 해결하는 창의적인 방법을 만들기
• 사회적 민감성: 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
• 협상: 사람들을 화해시키고 서로 간의 차이를 조정하려고 노력하기
• 설득: 다른 사람들이 마음이나 행동을 바꾸게 설득하기
• 타인을 돕고 돌보기: 개인적 도움, 치료, 감정적 지지, 혹은 동료, 고객, 환자 같은 타인들에 대한 기타의 개인적 도움을 제공하는 것

이 변수 9개에 대한 직업별 요구수준과 70개 직업의 컴퓨터화 기능 여부를 트레이닝 데이터로 사용하니 여기에서 나온 분류함수의 정확도는 90% 수준을 보였다.

이걸 다시 전체 700여 개의 직종에 적용해 컴퓨터화 가능한 확률을 계산해보면 흥미롭게도 컴퓨터화 가능한 확률은 직업 평균 임금과 높은 음의 관계를 보였다.

즉, 어떤 직업을 컴퓨터화할 수 있는 확률이 높을수록 해당 임금이 낮았다는 뜻이다.

정리하자면 해당 직업에서 독창성, 사회적 민감성, 협상, 설득, 타인을 돕고 돌보기 같은 것들이 요구되는 수준이 높을수록 그 직업은 컴퓨터화하기 힘들다는 뜻이다.

실제로 두 직업인 소프트웨어 개발자와 컴퓨터 프로그래머의 차이를 비교해봐도 극명하게 드러난다.

두 직업적 차이가 이해안갈 수 있지만 소프트웨어 개발자는 130등으로 컴퓨터화 하기 어려운 직업에 속하고 프로그래머는 293등으로 컴퓨터화 확률이 높은 편에 속한다.

컴퓨터 프로그래머는 다른 사람이 준 스펙대로 개발하는 것을 주 업무로 하며 그 과정에서 협상, 설득이 크게 필요하지 않다.

반면 소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많다.

앞서 이야기한 독창성, 협상, 설득 등에서 차이가 나는 것이다.

무엇에 집중할 것인가

여기서 주목해야할 것은 내가 하는 일에 대한 명칭이 아닌 실제로 매일 하는 일이 어떤 성격인가 하는 점이다.

명함에 단순히 선임 개발자라고 적혀있다고 안심하면 안된다.

“자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것입니다.”

반면, 컴퓨터화하기 어려운 부분은 크게 성장하지 못하게 된다.

많은 사람들이 놓치고 있는 부분 중 하나는 현재 자신의 업무가 창의적으로, 사회적으로 일하지 않는 시간이 계속 된다면 결국 자신의 커리어에 막대한 손해가 될 수 있다는 점이다.

혼자서 딱 정해진 일만 할 수 있는 환경이 축복이 아니라 저주가 될 수 있다.

결론적으로는 미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가지게 될 것이다.

따라서 자신의 분야에 두각을 나타내고 싶다면 지금이라도 암묵지와 직관을 배우고 수련하는 방법을 배우면 된다.

달인이 되는 비결

달인이 되는 비결은 매우 단순합니다. 매일 세수하고 양치하듯이 꾸준하게 반복하는 것이 바로 그것입니다.
인터넷 글 발췌

전문성 획득에 있어 반복의 중요성을 이야기하는 것으로 그 취지는 이해가 가지만 우리는 평생을 세수와 양치질을 했지만 왜 세수나 양치의 달인이 되지 못할까?

다른 영역에서도 마찬가지로 자신이 10년 넘게 해온 것 중에 전문성이 실제로 높아진 역량은 무엇이고, 거의 변화가 없는 것은 무엇인가 찾아봐라.

그 이유가 여러가지가 있겠지만 크게 다음 두 가지가 있다.

동기가 부족하다

첫 번째 이유는 동기에 대한 것으로 이를 잘 닦는 것에 대해 일정 수준만 되면 더 잘하고자 하는 동기가 딱히 없다.

주변을 봐도 양치질이나 세수에 대해 더 잘하고 싶어하는 사람이 있을까?

피드백을 제때 받지 못한다

두 번째는 피드백이 없어서이다.

내가 양치질을 어떻게 했는지, 어디가 잘 되었고 어디가 부족한지에 대한 정확한 피드백을 제때에 받지 못하기 때문이다.

한마디로, 매번 이빨을 닦은 직후에 내가 이빨을 어떻게 닦았는가에 대한 정확하고 꼼꼼한 피드백을 받지 못한다.

그래서 내가 뭘 잘했는지 못했는지 알지 못하고 실력도 늘지 않는다.

정리하자면 꾸준한 반복으로 달인이 되려면 적어도..

• 실력을 개선하려는 동기가 있어야 하고
• 구체적인 피드백을 적절한 시기에 받아야 한다.

이 두 가지가 충족되어야 한다.

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

수십 년 동안 전문가가 안 되는 비결

심리학에서는 이렇게 서로 반대되는 주장을 하는 학파가 존재하는 경우가 참 많다.

이때는 흑백 논리가 들어맞는 경우는 거의 없다고 보면 된다.

어떤 상황에서는 이야기가 잘 들어맞고, 또 어떤 상황하에서 저 이야기가 들어맞는지 봐야 한다.

전문성 형성에서 타당성과 피드백의 중요성

앞서 반대되는 심리학파에서도 동의하는 부분이 있는데, 믿을 수 있는 직관이 형성되려면 특정 조건이 필요하다는 것이다.

그리고 그 특정 조건으로 두 가지를 든다.

타당성과 피드백이다.

인간의 전문성에 대해 서로 의견을 달리 하는 학파들 사이에서도 이 두가지만큼은 동의한다고 할 만한 부분이기에, 더욱 믿을 만하고 중요한 정보라고 할 수 있다.

타당성 조건이 필요하다는 의미는 직관이 적용되는 영역에 어느 정도 인과관계와 규칙성이 존재해야 한다는 것

예측가능성이라고 말할 수 있다.

이는 불확실성과는 의미가 다른데, 예컨대 포커 게임 자체는 운이 작용하기 때문에 불확실한 면이 있지만 타당성이 높아서 전문성이 형성될 수 있다.

포커 게임에서 내가 카드를 한장 받으면 상대에게 어떤 카드가 있을 혹은 없을 확률을 보정할 정보가 추가적으로 생긴다.

규칙성이 있는 것으로 볼 수 있다.

그런 면에서 포커 게임은 주사위 던지기와 전혀 다르다.

앞전에 6이 세 번 나왔다고 이번에 나올 주사위의 눈에 대해 정보가 더 있는 것은 아니다.(흔히 도박사의 오류라고 말한다.)

타당성이 떨어지는 영역은 장기적 정치 판도 예측과 주가 예측이 대표적이다.

원숭이와 펀드 매니저의 차이는 거의 없었다.

피드백 조건이 필요하다는 의미는 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야 한다는 걸 말한다.

이게 부족한 직업으로는 공항의 보안검사대 조사원을 들 수 있다.

자신이 오늘 얼마나 실수 했는지 아는 방법이 거의 없기 때문이다.

자신이 수십 년 동안 한 가지 일을 하면서 전문가가 안 되는 이유가 있다면 이 타당성과 피드백이 부족한 환경에서 일하는 것이다.

따라서 전문성의 요체는 위 두가지 사항을 말할 수 있다.

소프트웨어 개발은 과연 두가지를 충족하는 직업일까?

전반적으로 타당성도 낮은 편이고 피드백도 낮은 편이라고 생각되지만 개인의 노력에 의해 충분히 끌어올릴 수 있는 분야라고 생각된다.

타당성과 피드백을 높이기

자신이 일하는 환경에서 전문성 향상을 위해 할 수 있는 일이 없을까?

자신이 일하는 방식, 개발하는 방식을 바꾸면 이 타당성과 피드백을 어느 정도 높일 수 있다.

그리고 전문성을 현재보다 좀 더 빨리 발전시킬 수 있다고 생각한다.

예컨대, 타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력을 하면 된다.

피드백을 높이려면 동료나 상사, 고객에게서, 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하면 된다.

스스로 평소에 어떤 노력을 하고 있는지 생각해보면 좋다.

당신이 제자리 걸음인 이유

이소룡은 샌프란시스코에서 온 남자를 이겼을 때 스스로에게 화를 냈다고 한다.

이유는 자신이 정한 3분이라는 기준을 넘겼서 이겼기 때문이다.

스스로 실력을 높이기 위해서는 의도적 수련이 중요하다.

의도적 수련은 대중 서적과 매체를 통해 많이 알려졌지만 실제로는 본질을 보지 못하는 것이 문제가 된다.

사람들은 의도적 수련은 양이 아닌(1만 시간의 법칙과 같은..) 질적인 부분, 즉 어떤 조건을 갖춰야 의도적 수련이 되는지, 뎌 효과적인 의도적 수련이 되기 위해서는 어떠해야 하는지 등에 대해서는 잘 모른다.

의도적 수련의 필수조건, 적절한 난이도

의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 한다.

이것은 미하이 칙센트미하이의 몰입이론과도 일치하는 부분이다.

가로축은 해당 작업에 대해 자신이 느끼는 자기 실력을 말한다.

세로축은 해당 작업에 대해 자신이 느끼는 난이도이다.

그렇다면 지루함측에서 일을 하고 있다면 어떤 느낌이 들까?

물론 실력이 작업 난이도를 초과하는 지역이기 때문에 기업 입장에서는 땡큐다.

하지만 지금은 만족할 수 있어도 조금만 지나도 금방 지루함을 느끼게 될 것이다.

반대로 불안 영역은 어떨까?

실력보다 높은 난이도의 일을 하는 영역이기 때문에 불안함이나 두려움을 느끼게 된다.

여기서 주목해야할 부분은 몰입채널부분이다.

난이도와 실력이 엇비슷하게 맞는 부분으로 미하이는 이 부분에서 인간이 몰입을 경험한다고 한다.

그리고 바로 이때 최고 수준의 집중력을 보이고, 그 덕분에 퍼포먼스나 학습 능력이 최대치가 될 수 있다고 한다.

또한 그때 최고 수준의 행복감을 경험한다는 흥미로운 사실을 발견하기도 했다.

비슷한 이야기로 언어학자 크라센이 입력가설을 통해 말한다.

i + 1이론이라는 현재 언어 학습자의 언어 수준을 i라고 할 때 딱 한 단계 높은 i + 1 수준의 입력이 주어질 때에만 언어 능력이 유의미하게 진전한다는 이론이다.

교육학에서도 마찬가지로 비슷한 이야기를 한다.

인지 부하 이론에서 학습 시 불필요하게 인지적인 부담을 주면 어떤 것도 제대로 학습하기 어렵다는 말을 한다.

예컨대 미적분을 독일어로 배우면 미적분 자체보다 엉뚱한 다른 것들에 두뇌 에너지를 빼앗겨서 학습 효율이 떨어질 수 있다는 것이다.

반대의 경우도 있는데, 영단어를 여러 개 외울 때 모음을 감추고 외우면 ‘더 어려워서’ 오히려 기억이 오래갈 수 있다는 연구도 있다.

핵심은 적절한 난이도

실력이 늘지 않는 이유

의도적 수련의 필수 요건 중 하나가 적절한 난이도인데 앞 그림의 몰입 채널에서의 수련이 의도적 수련으로 이어진다는 것

반대로 말하면 A나 B영역의 일은 의도적 수련이 되지 않고, 실력 향상에 별 도움이 안 된다는 말이다.

이 상황에서의 수련은 의미가 없는 행동.

이 부분이 아주 중요한데 자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 것이다.

더 무서운 건 점차 이런 환경에 익숙해지고 행동이 습관화된다는 점이다.

그때는 자기 인식도 잘 되지 않는다..!

더 뛰어난 스케이터가 엉덩방아를 더 자주 찧을 수 있따.

뛰어난 선수는 자기 기량보다 어려운 기술을 연마하지만 그렇지 못한 선수는 이미 잘하는 걸 더 연습한다는 두 그룹의 차이를 잘 보여준 연구이다.

제자리걸음에서 벗어나기

그럼 어떻게 해야 할까?

팀에서 받은 업무가 내 실력에 딱 맞는 혹은 그보다 약간 어려운 일들만 주면 좋겠지만.. 그렇지 않다면, 단순 반복업무라면?

다시한번 그림을 보면 a1, a2, b1, b2라는 몰입 밖에서 몰입으로 가기 위해 쓸 수 있는 전략이다.

본인의 하루가 불안하거나 지루할 때가 대부분이라면 이 전략들을 사용해야 합니다.

문제는 해야 하나 말아야 하나가 아닙니다.

무조건 이런 전략을 써야 한다.

그러지 않으면 실력이 제자리걸음일 수밖에 없다.

핵심은 어떻게 하느냐이다.

우선 지루함을 느낄 때 즉, 실력에 비해 너무 쉬운 일을 하는 경우를 본다.

이 때는 a1, a2 두 가지 전략을 쓸 수 있다.

복합적 전략을 써서 대각선으로 이동하는 것도 가능하데, 간단한 설명을 위해 기본적인 경우 다룬다.

지루함을 느끼는 경우: a1 실력 낮추기

a1의 경우, 작업의 난이도는 그대로 두고 실력을 낮추는 전략입니다.

같은 난이도의 체력훈련을 하는데, 팔과 다리에 모래주머니를 달고 운동하는 경우를 생각하면 이해가 쉬울 것

일시적으로 몸이 무거워지고 민첩성이 떨어지게 된다.

프로그래머의 예로, 평상시 즐겨 쓰던 보조 도구를 일부러 안쓰는 행위를 할 수 있다.

마우스를 즐겨 쓴다면 디버거를 안 쓰는 것, 캄파일 30초마다 하다가 5분으로 늘려보기 등등의 행위가 있을 수 있다.

실력이 팍 떨어진 느낌을 받을 수 있지만, 좀 더 집중해야 하고 머릿속에서 좀 더 많은 연산을 해야 한다.

힘들 수 있지만 난이도와 실력이 잘 맞아 들어가기만 하면 의도적 수련이 될 수 있다.

지루하던 작업이 몰입하는 작업이 되고 실력이 늘 수 있다.

지루함을 느끼는 경우: a2 난이도 높이기

a2는 실력은 그대로 두고 난이도를 높이는 전략이다.

문두에 소개한 이소룡의 예로 무술을 너무 잘하기 때문에 스스로 제약을 추가한 형태이다.

a2 전략은 뛰어난 프로그래머들이 이미 많이 쓰고 있다.

a2전략을 쓰던가 아닌가로 뛰어난 프로그래머를 가려내는 것도 좋은 방법이다.

흔하게 쓰는 방법은 자기에게 요구되는 수준을 더 높게 여기는 것으로 하루 만에 개발하라고 주어진 업무인데 지루한 느낌이 드니 한 시간 만에 할 수 있는 방법을 고안해보기

평소 코드를 검토할 때 버그를 시간당 하나 찾았다면 오늘은 두 개 찾기, 익숙한 작업을 새로운 언어로 진행해 보기 등

또 다른 방법으로는 공식적으로 안 해도 되는 업무를 자신의 의지로 추가로 하는 경우가 있다.

이 외에도 a2에서는 자신만의 도구 방법을 만드는 게 매우 중요하다.

남들보다 일을 좀 더 효율적/효과적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구을 만들기

이런 것들을 만들기 위해선 자주 일어나는 반복 패턴을 파악하고 분석해야 하며, 부족한 시간에도 짬을 내어 도구를 고안하고 작성해야 한다.

일의 난이도가 확 올라가는 셈이다.

불안함을 느끼는 경우: b2 실력 높이기

b2는 불안함을 느끼는 경우 실력을 높여 몰입영역으로 들어가는 방법이다.

장기적으로 실력을 높이는 방법은 다양하다.

책을 읽거나, 스터디에 참가하는 등..

하지만 지금 당장 불안함을 느낀다면 어떻게 해야할까?

크게 보면 사회적 접근과 도구적 접근, 내관적 접근 세 가지가 가능하다.

사회적 접근은 나보다 뛰어난 전문가의 도움을 얻는 것이다.

잘하는 사람에게 짝 프로그래밍을 부탁하거나 전문가의 도움을 받는 것

괜찮은 튜토리얼 문서가 있다면 따라가보는 것도 하나의 선택

도구적 접근은 다른 도구의 도움을 받는 것이다.

a1에서 도구 접근을 제약하는 경우와 반대로 볼 수 있다.

내 능력을 확장시킬 수 있는 도구를 찾아 쓰면 된다.

내관적 접근은 비슷한 일을 했던 경험을 머릿속에서 되살려 보는 것으로 그때 그 일을 어떻게 했는지 떠올려 보면서 비유적으로 문제를 해결한다.

보통 이런 과정을 거치면 자기효용감이 증대하면서 스스로 인식하는 자기 실력이 향상되기 쉽고 결과적으로 몰입영역에 들어가기 좋다.

불안함을 느끼는 경우: b1 난이도 낮추기

b1은 불안감을 느낄 때 난이도를 낮춰서 몰입영역으로 들어가는 방법이다.

간단하면서 효과적인 방법은, 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기버전을 첫 번째 목표로 삼는 것이다.

애자일에서 말하는 WTSTTCPW(What’s The Simplest Thing That Could Possibly Work)와 같다.

테트리스를 만들어야 하는데 불안감이 엄슴해 온다면, 일단 화면 한가운데에 네모난 사각형 하나 그리기를 목표로 한다.

그걸 완성하면 난이도를 조금 올려서, 좌우 화살표로 움직이게 한다.

이때 자료구조나 회전 알고리즘을 먼저 완성하는 게 아니라는 점이다.

테트리스의 핵심은 살아 있으면서도 간단한, 아기 버전의 테스트를 만드는 것이다.

유명한 P프로그래머의 경우 대학 시절 알고리즘 수업을 들었을 때, 알고리즘 퀴즈를 파이썬으로 한번 C로 한번 풀어서 제출했다고 한다.

남들이 C언어로 힘겹게 짜고 있을 때 파이썬으로 로우 레벨을 신경쓰지 않고 알고리즘 자체에만 신경을 쓸 수 있었던 것이다.

P는 상대적으로 쉬운 언어를 쓰면서 과제의 난이도를 일시적으로 낮추어 몰입을 경험했다.

난이도를 낮춘 결과 학습효과, 동기 강화, 스트레스 감소, 자기 효능감 증가 등의 긍정적인 효과가 생겨 이득을 얻은 것으로 볼 수 있다.

유사한 연구로 유지보수 작업에서 어려운 작업을 먼저 시작하냐, 쉬운 작업을 먼저 시작하냐에 따른 수행시간 정확도 비교 연구에 따르면 작업을 먼저 시작할 경우 수행시간에는 큰 차이는 없으나 정확도가 높아지는 것으로 나타났다.

동적인 균형

이렇게 몰입영역으로 들어가는 4가지 전략이 있다.

여기서 집중해야 하는 부분이 있는데, 바로 자신의 실력이나 작업의 난이도는 계속 조금씩 요동을 치고 있다는 점이다.

이해안되던 부분이 이해가 되면서 진도가 확 나가는 경우나 쉬운일로 생각했지만 버그가 나면서 난이도가 확 올라가는 경우 등등

반대로 난이도를 너무 올리거나 너무 내려버리는 경우도 해당된다.

즉, 지속적으로 자신의 감정 상태를 살피면서 지금 지루한지 불안한지를 알아채고 만약 지루함을 느낀다면 앞 네가지 전략을 적절히 사용해야 한다는 것이다.

그런 면에서 자기가 지금 어떤 상태인지 살피는 알아차림이 꼭 필요하다.

메타인지 전략으로 많이 소개되는데 심리학과에서 공부잘하는 사람의 특징으로 꼽는다.

팀장이 할 수 있는 일

기본적으로 앞의 내용은 전문가가 되길 원하는 사람이 개인적으로 적용하는 것을 설명했지만, 다른 사람을 관리하는 사람도 동일 내용을 응용할 수 있다.

팀원들이 현재 어떤 상태를 주로 경험하고 있는지 파악하고 적절한 전략을 구성할 수 있도록 도와줄 수 있다.

이상적으로는 그 사람의 실력에 맞는 난이도의 일을 나눠주는 걸 생각할 수 있지만 현실은 그렇지 않다.

그보다 자기 스스로 몰입 상태를 조장하는 능력을 키우게 도와주는 것이 더 바람직하다.

하지만 안타깝게도 정반대의 행동을 하는 팀장들을 더 자주 봤다.

몰입 영역 밖으로 팀원들을 몰아내는 행동을 하는 것이다.

의도적 수련의 일상적 예시

앞 <당신이 제자리="" 걸음인="" 이유="">에서는 몰입이 아닌 상황에서 사용할 수 있는 4가지 전략에 대해 알아 봤다.

모두 프로그래밍을 예시로 들었지만, 프로그래밍 뿐만 아니라 삶의 많은 영역에서 이 전략을 적용할 수 있다.

이렇게 한 가지 영역에서의 교훈을 다른 영역에 적용하는 것을 심리학에서는 학습 전이라고 한다.

프로그래밍을 배우면 좋은 이유로 컴퓨터적인 사고방식을 말하는 이유와 같다.

실력 조정하기(a1, b2)

매번 다니는 길로 등산하는 것은 지루함을 느끼기 쉽다.

실력을 낮추기 위해 무거운 짐을 들고 등산하게 되면 속도가 떨어지고 더 조심하게 된다.

난이도 조절하기(a2, b1)

등산에서 난이도를 조절하는 가장 간단한 방법은 더 험한 길, 혹은 더 쉬운 길을 가는 것이다.

혹은 시간 제약을 두고 타이머를 사용하여 등산하는 것도 하나의 방법이다.

프로그래밍 언어 배우기의 달인

스스로 어떤 작업을 하고 메뉴얼 대로 행동하는지 행동 양식을 분석하는 작업을 인지적 분석 작업이라고 한다.

튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다

튜토리얼을 읽는 것은 다른 프로그래머와 비슷해보이지만, 여기에 차이가 있다면 읽을 때 다음 작성할 프로그램을 염두에 둔다고 점이다.

따라서 달인은 튜토리얼을 읽다가 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 멈추고 코딩을 시작한다.

프로그램을 완성하면 잠시 멈췄던 자리로 돌아와서 읽기를 계속한다.

이때에는 다음 프로그램을 목표로 두고 읽는다.

이런 것을 적극적 읽기라고 한다.

무언가를 읽을 때 구체적인 질문이나 목적을 가지고 읽는 방법을 말한다.

달인이 주로 첫 번째 목표로 삼는 프로그램은 단어 개수 세기 프로그램이라고 한다.

공부할 때 표준 라이브러리 소스코드를 읽는다

자연 언어 교육과 다르게 프로그래밍 언어 교육에서 읽기보다 쓰기를 강조하는 경향이 있다.

하지만 프로그래머의 실제 업무는 읽는 시간이 쓰는 시간을 압도한다.

좋은 코드를 읽어야 좋은 코드를 짤 수 있기 때문이다.

입력이 주어져야 출력이 생긴다.

달인은 튜토리얼을 읽어 나가면서 틈틈히 해당 언어의 표준 라이브러리를 찾아 읽었다.

표준 라이브러리는 보통 해당 언어 개발자가 작성하거나 검증한 코드이기 때문에 좋은 코드를 읽을 수 있다.

실제로 java로 작성된 프로그램이냐 C로 작성된 프로그램이냐는 어떤 언어 키워드를 썼느냐가 아니라 어떤 스타일을 따르고 어떤 숙어를 사용했는가이다.

이것이 프로그램의 기능에 차이를 가져오지는 않을지 몰라도 프로그램 작성 비용과 더 나아가 수정 비용을 좌우하게 된다.

그래서 해당 언어의 결을 배우고 그걸 따르는 것이 중요하다.

공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다

달인은 튜토리얼 문서를 읽어 나가면서, 실질적인 사용 예를 스스로 만들어 낸다.

튜토리얼은 토이 프로젝트가 많은데 이를 실질적 사용적인 예로 코드 감을 익히는 것이다.

전문성을 효과적으로 뽑아내는 전문가가 되기

달인에게서 비결을 배웠듯이 타 영역의 전문가로부터 그의 비결을 배워 실행해 옮겨보길 추천한다.

저자가 달인에게서 “프로그래밍 언어를 빨리 배우는 비결이 무엇인가요?”라고 묻지 않은 것 처럼 전문가에게 구체적인 사건에 대해 말하도록 유도하는 것이다.

위와 같은 질문은 일반적인 답, 이론적인 답을 하는 경향이 있다.

뭔가 잘하고 싶다면 이미 잘하는 사람을 관찰하고 인터뷰하는 것부터 시작하는 것이 큰 도움이 된다는 것이다.

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

바람은 계산하는 것이 아니라 극복하는 것이다.

남이 <최종병기 활="">

실수에 대해 스스로 갖는 느낌이 망신에 가까운지, 좋은 학습에 가까운지 생각해보자.

미연에 실수를 막아야 한다?

생태학에서 불을 인위적으로 억제하면 오히려 그 지역에 가연성 물질이 과도하게 축적되게 해서 결과적으로 한번 불이 나면 엄청난 규모의 불이 나게 할 수 있다고 설명한다.

라마누잔의 사례나 미국 산림청의 사례와 같이 실수에 의한 사례를 보면 실수 이후에 조치가 중요하다는 것을 알 수 있다.

두 가지의 실수 문화

실수 문화에는 크게 두 가지가 있다. 실수 예방과 실수 관리

실수 예방은 행동에서 실수로 가는 경로를 차단하려고 한다. 즉, 실수를 저지르지 말라고 요구한다.

근데 사실 이것은 불가능에 가깝다. (전문가도 1시간에 평균 3~5개의 실수를 저지른다고 한다.)

실수 투성이인데 왜 세상은 엉망이 아닐까?

그것은 전문가들은 실수를 조기에 발견하고 빠른 조치를 취하기 때문이다.

이러한 태도를 실수 관리라고 한다.

다른 경로로는 이미 결과가 난 실수에 대해서는 학습을 통해 “다음 행동할 때는 이렇게 하자”는 계획을 세우기도 한다. (2차적 실수 예방)

실수 예방 문화에서 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 된다. 실수에서 배우지 못한다.

반대로 실수 관리 문화에선 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하게 되면 배우는 분위기가 생긴다.

실제 연구결과또한 실수 예방보다 관리 문화인 회사가 더 수익성이 높다.

실수가 없으면 학습하지 못하기 때문에 실수 관리를 하는 문화일수록 학습을 더 잘한다.

고로 직원들에게 실수하지 말라고 하는 조직은 학습하지 말라고 지시하는 것과 같다.

불확실한 상황하에서 실수는 피할 수 없다.

그 상황에서 학습을 잘 하려면 실수를 격려하기도 해야 한다.

뛰어난 선생에 대한 미신

조직이나 개인 들 모두 많은 돈과 시간을 투자해 교육을 받는다.

흥미롭게도 많은 조직에서 교육은 투입으로 성과를 측정하는 대표적 분야이다.

얼마나 썻냐로 얼마나 잘했는지를 가늠하는 것(회사)

뛰어난 선생이 가진 지식은 사실 학생의 성과를 높여주는 면에 있어 큰 영향을 주지 못한다.

즉, “지식이 많은 사람이라고 해서 꼭 좋은 선생이라고 할 수 없다”, “지식이 많은 사람에게 배웠다고 해서 내가 실력이 꼭 느는 것은 아니다”

전문가가 가르쳐주는 것은 전부가 아니다

실제 의료계의 연구를 보면, 전문가가 특정 수술법을 학생에게 가르칠 때, 의료적지식, 무엇을 어떻게 해야 할지에 대한 행동 단계, 의삭결정 단계 등 자신이 해당 과제를 수행할 때 사용하는 지식 중 70%는 가르치지 않다는 분석이 거듭해 나왔다.

전문가들은 그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각하는 것이다.

이런 현상이 벌어지는 이유에는 여러 가지가 있지만 대표적인 것이 자동화이다.

전문가가 되면 자신이 하는 일이 반복적으로 몸에 익고 자동화되어서 결국 암묵적이 되어 버린다.

그래서 오히려 인식이 없어지는 것이다.

인지적 작업 분석으로 극복하기

앞에서 나온 인지적 작업 분석으로 이를 극복할 수 있다.

예를 들어 선생 입장에서는 자신에 대한 메타인지를 높이는 노력을 할 수 있다.

“내가 이 문제를 해결할 때 어떤 과정을 거치는가”를 생각하며 자신의 머릿속을 관찰하고, 질문을 던지고 분석하는 것이다.

나홀로 전문가에 대한 미신

이번엔 전문가의 사회성이라는 측면에 관한 이야기다.

보통 어떤 사람이 전문가라고 하면 그 사람의 뇌 안에서 무슨 일이 벌어질까에만 주목하는 면이 있다.

때로는 전문지식은 뛰어나지만 사회성이 부족한 사람을 떠올리기도 한다.

과연 현실에서의 전문가도 그럴까?

프로젝트에 유용한 라이브러리나 개발방법을 도입하자고 할 때, 사람들의 반응을 생각해보자

물론 긍정적인 생각도 있을 수 있지만 대다수가 부정적인 시각으로 볼 수 있다.

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

하지만 안타깝게도 현실에서는 팀원들이 맘에 안 들고, 그들도 나를 맘에 들어 하지 않는 상황, 즉 사회적 맥락이 나쁜 상황에서 타개책으로 기술에만 매몰되는 경우가 있다.

어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요하다.

사회적 자본과 기술

부부의 사례로 알 수 있듯이 신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다는 것이다.

이러한 신뢰를 사회적 자본의 일종이다.

ex) 회사에서 사이가 안좋은 팀장과 신입사이의 관계에서 팀장이 신입에게 책을 선물했다면 신입은 공부하라는 신호로 인식

고독한 전문가라는 미신

전문가가 해당 도메인 지식만 뛰어난 사람이라는 것은 대표적인 미신이다.

전문가는 사회적 자본과 사회적 기술 또한 뛰어나다.

소프트웨어 공학에서 이뤄진 연구의 결과를 봐도 ‘뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며’, 초보 개발자들에게 조언을 할 때 사회적인 측면이 포함된다. 기술적 조언만 하는 게 아니라는 뜻이다.

뛰어난 개발자가 초보 개발자들에게 해주는 조언의 약 70%가 동료와의 협업임을 알 수 있다.

사회적 자본과 기술이 그렇게 중요하다면 왜 개발자를 포함한 다른이들은 학교에서 그걸 배우지 못했을까?

그것은 전문가에 대한 잘못된 모형 때문이다.(전문가는 혼자서 일하는 고독한 천재라는 프레임)

마무리

1장의 초반부분은 정말 재밌게 읽었다.

흥미로운 부분이 많아서.. 특히 의도적 수련과 프레임, 회사의 이야기, C레벨의 작업 등등

그런데 후반부 아주 조금은 홍보성 글이 많아서 앞장의 내용보단 별로 재미가 없었다.

애자일 컨설팅의 홍보목적의 글을 잘 포장해놓은 몇가지 사례와 이야기는 실제로 검색하는데 도움을 주긴 했지만, 애자일 컨설팅 비용이 600이 넘어간다는 내용을 보고.. 놀랐다.

친구는 소마에서 직접 만났다고 하는데.. 저자는 만나보고 싶기는 하다.

2장 함께

Lean StartUp
사업이나 상품을 개발하는 방법론 중 하나로 빠른 개발 주기를 통해 가설을 검증해 나가며 초기부터 고객과 함께 가는 특징이 있다.
단순하하자면 고객 개발과 애자일, 이 두 가지를 합친 것으로 볼 수 있다.

린 스타트업을 조사한 대학생들의 사례로 그들은 초기에 대상에 대한 지식이 거의 없어서 일을 제대로 나눌 수가 없었지만 초기에 일을 빨리 나눠버려 불상사가 발생했던 것

사실 일을 가장 잘 나눌 수 있는 때는 프로젝트가 완료된 시점이다.

사람들은 협력이 중요하다고 말 하지만 사례와 같이 초반에 일을 세밀하게 나누고 선을 긋는다. (그리고는 안녕)

가장 많이 형태를 띄는 각자 진행하고 나중에 만나서 서로 합쳐본다.

그 속을 들여다보면 협력은 거의 없다.

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

조엘 스폴스키라는 사람이 만든 개발팀 평가 테스트라는 것이 있다.

1. 소스 컨트롤을 사용하는가?
2. 한 번에 빌드를 만들어낼 수 있는가?
3. 일일 빌드를 만드는가?
4. 버그 데이터 베이스를 가지고 있는가?
5. 새로운 코드를 작성하기 전에 버그를 고치는가?
6. 최신 업데이트된 스케줄이 있는가?
7. 스펙(제품 명세)이 있는가?
8. 프로그래머가 조용한 작업환경에서 일하는가?
9. 돈이 되는 한 최고의 툴을 사용하는가?
10. 테스트가 있는가?
11. 채용 면접 때 후보가 코드를 짜게 해보는가?
12. 복도 사용성 테스트를 해보는가?

hallway usability test
자신이 속한 회사 복도에서 아무나 지나가는 사람을 잡아다가 하는 사용성 테스트를 말한다.
미리 누구를 테스트할지 치밀하게 계획해서 하는 통상적인 사용성 테스트와 대조적이기 때문에 무작위 사용성 테스트라 하기도 한다.

이 테스트는 당시에 인기를 많이 얻기도 하고, 비판도 많이 받았다.

만약 이 테스트에 모두 ‘예’라도 대답한다면 완벽하다고 조엘스키는 말한다.

책의 저자는 전혀 동의하지 않으며 좋은 점이라곤 간단하다는 것이다.

여기서 발생하는 문제점은 관리자나 경영진이 각 질문의 맥락을 이해하지 못하고 단순히 12가지 질문에 예라고 답하는 것을 목표로 노력하는 경우를 말하는 것이다.

이런 경우를 문제로 보는 데 크게 두 가지의 이유가 있다.

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

쓰면서 의문이였던 8번.. 프로그래머는 조용한 환경에서 일해야 한다고 주장한다.

하지만 다른 예시를 보면 팀원들이 상시 대면 의사소통할 수 있는 공간이 생산성 향상에 많은 도움이 된다고 역설한 바가 있다.

오히려 개발자에게 팀 전체가 공유할 수 있는 시끄러운 공간을 주는 것이 생산성 향상에 더 좋을 수 있다.

조용한 작업환경을 강조하다 보면 자칫 면대면 의사소통을 나쁜 것으로 생각하게 될 수 있다.

9번의 경우도 빠른 컴퓨터, 듀얼 모니터, 좋은 용량 등등 이런 것에 돈을 팍팍 쓰라는 말인데, 소프트웨어 툴의 경우 고를 때 단순히 비싼것을 생각하고 고르지 않는다.

단순 비싼 것을 고르는 것은 경영자 마인드에 가깝다.

정말 뛰어난 팀은 툴을 고를 때 여러 조건을 고려한다. (직접 수정이 가능한가?)

따라서 단순하게 ‘예’라고 말해서 평가가 좋을 순 없다.

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

많은 회사의 CTO나 관리자가 이 테스트를 기반으로 소프트웨어 개발 팀을 관리, 개선하려고 한다.

과연 이 12가지가 개발팀에 얼마나 중요한 것일까?

제럴드 와인 버그는 소프트웨어 개발을 잘 관리 하려면 3가지 근본적인 능력이 필요하다고 했다.

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

이 분이 쓴 책 ‘품질 소프트웨어 관리’라는 책은 총 4권으로 각 제목은 다음과 같다.

• 시스템적 사고(Systems Thinking)
• 일차적 측정(First-Order Measurement)
• 일치적 행동(Congruent Action)
• 변화를 기대하기(Anticipating Change)

책 제목과 와인 버그가 주장한 근본적인 능력은 일치한다.

마지막 책은 계획하지 않았던 책으로 3가지 능력을 활용해 실제 조직과 개인을 어떻게 바꿔나갈 것인가 하는 이야기이다.

실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유의 첫 번째가 관리라는 변수 때문이었다.

하지만 분류별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선은 도구에서 일어났다.

실제 통계를 내어보니 관리의 개선은 64배의 비용이 절감되고 도구는 약 3배의 절감이 발생한다고 한다.

다시 조엘 테스트로 돌아가 가장 만만하고 쉬운 것부터 시작하는 관리자의 성향과 충돌하지 않는다.

이것이 조엘 테스트가 위험할 수 있다고 생각하는 두 번째 이유다.

자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 되지 않을까 한다.

협력을 통한 추상화

커뮤니케이션과 협력

이제까지 전문 프로그래머 연구에서 가장 관심 받지 못했던 분야는 소프트 스킬이다.

이는 커뮤니케이션이나 협력능력 같은 것을 말한다.

실제로 컨퍼런스나 강연을 들어도 실력있는, 오래 일한 프로그래머 일수록 커뮤니케이션을 강조한다.

일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어나다. (반면 코딩, 테스팅에 들이는 시간은 별 차이가 없다.)

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

협력하면 밑천도 못 건진다고 생각하는 사람도 많다.

과거 ‘부분의 합보다 큰 전체’라는 이야기가 나왔던 것 처럼, 실력이 뛰어난 사람은 혼자 일하게 둬야 한다고 주장하는 사람도 있었다.

하지만 최근의 연구 결과는 반대의 이야기가 늘어나고 있다.

그냥 협력이라고 좋은 것이 아닌 몇 가지 전제 조건이 필요하다는 것이다.

예컨대 두 사람이 시각화 없이 헙력하는 것(전화, 텍스트)보다 중간 매개(화이트 보드, 종이)를 두고 협력하는 것이 훨씬 낫다등의 연구 결과가 있다.

톱니바퀴 실험

스탠퍼드 대학교의 심리학자인 대니얼 슈와르츠는 같은 문제를 혼자 푸는 경우와 두 사람이 함께 푸는 경우의 차이에 대한 연구를 시행했다.

다섯 개의 톱니바퀴가 가로로 길게 연결되어 있다. 가장 왼쪽에 있는 톱니바퀴를 반시계 방향으로 돌리면 가장 오른쪽의 톱니바퀴는 어느 쪽으로 돌까?

이런 문제를 일곱 개를 낸다.

문제에서 톱니바퀴의 수는 각기 3, 4, 5, 6, 7, 8, 9로 증가(뒤섞인다.)하며 마지막 문제의 경우 131개라는 바퀴수를 낸다.

처음에는 다들 허공에 손을 돌리며 풀다가 일종의 법칙(패리티 법칙으로, 톱니바퀴 개수의 홀짝 여부에 따라 좌우측 바퀴의 회전이 결정됨)을 발견하고 그 때부터는 허공에 손을 내젓지 않고 답을 한다.

일곱 번째 문제까지 추상화된 규칙을 찾아내는지 그렇지 못한지를 살펴보았더니, 혼자서 작업한 경우는 14%만이 추상화 규칙을 찾아냈다.

반면 둘이서 작업한 경우 58%나 이 규칙을 찾아내었다. (4배가 넘는다.)

이런 차이가 생긴 이유는 두 사람이 서로 같은 문제를 이해하거나 혼동을 해결하기 위해서 추상적 개념을 도입한다는 것이다.

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

되게 흥미로운 내용으로 코드로 따지면 서로가 이해할 수 있는 하나의 인터페이스를 설계한 것과 같은 것 같다.

추상화의 중요성

객체지향 프로그래밍에서 코드의 중복을 줄이다보면 흥미로운 객체들이 발견되는데, 함수형에서는 함수와 함수의 함수를 발견한다.

이는 모르던 것을 배우게 하기도 하고, 프로그래머의 영역을 넘어서 고객들의 대화가 바뀌기도 한다.

이런 객체들을 발견하지 못했다면 너무 고리타분한 코딩은 아닐까 생각한다.

여기서 ‘흥미로운 무엇’이 바로 추상화다.

특히 예상하지 못했던 추상화로, 말하자면 창발적 추상화라고 할 수 있다.

전산학의 모든 문제는 또 다른 차원의 간접성으로 해결할 수 있다. :버틀러 램슨

전산학은 추상화의 과학이다. :알프레드 아호와 제프리 울먼

소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특징 지을 수 있다. :그래디 부치

복잡한 현상에 대한 이해를 발전시켜 나갈 때, 인간 지성에 가장 강력한 도구는 추상화다. 실세계의 특정한 대상체, 상황, 과정 간의 유사성을 인식하는 데에서, 그리고 이러한 유사성에 집중하고, 차이점은 일시적으로 무시하는 결정에서 추상화가 생겨난다. :토니 호이

읽으면서 생각이 들지만 추상화란, 지금 우리가 믿고 있는 개념, 이데올로기에도 포함되어 있다고 생각한다. 신을 믿거나 자본주의, 화폐의 개념또한 추상화에 가깝다.

추상화는 이토록 중요한데, 그렇다면 추상화를 높이는 방법은 뭐가 있을까?

이번 소제목은 협력을 통한 추상화로, 톱니바퀴 실험을 통해 알 수 있듯이 협력을 통해 추상화 수준을 높일 수 있다.

대화하는 프로그래밍

짝 프로그래밍에 관한 이야기로, 두 사람이라는 구성은 대화를 통해 추상화를 높이게 한다.

짝 프로그래밍의 조금 낮은 버전이 코드리뷰의 형태라고 생각한다. 엄연히 다르지만..

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

최근 신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다는 등의 연구가 많이 있다.

그렇다면 어떻게 신뢰를 쌓을 수 있을까?

신뢰를 쌓는 데에 많이 쓰이는 방법은 투명성과 공유, 인터랙션이다.

자신이 한 작업물을 투명하게 서로 공유하고 그에 따라 피드백을 주고 받으며 인터랙션하는 것이다.

조직에서의 신뢰를 연구하는 사람들은 이런 것을 소통 신뢰라고 한다.

그런데 과연 그렇게 공유하고 소통하면 신뢰가 쌓일까요?

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

두명의 디자이너가 각자 고인 단체를 위한 광고를 디자인 한다.

주어진 시간 동안 개별적인 디자인이 끝나면 두 사람은 한 방에 모여서 서로 디자인을 공유하고 피드백을 나누며 인터랙션을 한다.

그러고 각자 돌아가서 자신의 최종 버전이 될 광고를 다시 새롭게 만든다.

이 최종 버전은 전문가 평가나 클릭률 등을 통해 실제 성과를 측정하게 된다.

첫 광고 디자인을 시작하기 전에 상호 간의 신뢰 정도를 측정했다.

그리고 한 방에서 공유하고 다시 상호 간 신뢰를 측정했다.

5개의 질문에 답하는 것이였는데, 대부분 SVI라고 하는 측정 도구의 관계 항목을 사용하였다.

결과부터 말하면 신뢰감이 떨어졌다.

공유를 해서 신뢰감이 떨어진 상황이 발생한 것

다른 조건으로 실험을 진행했는데 신뢰감이 유의미하게 증가했다.

디자이너들이 각자 여러 개의 디자인을 만들고 그걸 모두 공유한 경우였다.

신뢰면에선 최악인 안 하느니만 못한 좋은 결과물의 공유보다 상대방에게 불안감을 가지는 “이걸 보고 흉을 보면 어쩌지”와 같은 상황이 더 신뢰감을 주는 이유는 뭘까?

복수 공유의 장점

복수 공유는 작업자가 부정적으로 피드백을 수용하려는 마음도 많아진다.

여러개를 준비했으니 그중 하나를 두고 뭐라고 해도 나에 대한 공격은 아닌 것이다.

또 여러 개이니 상대적으로 이야기를 할 수 있어 말하는 사람도 편하고, 듣는 사람도 좋다는 이야기랑 안 좋다는 이야기를 같이 들으니 마음이 좀 더 편하다.

또한 복수 경우의 실제 결과에서도 피드백 수용률이나 개선정도도 더 크다는 것이다.

가장 중요한 부분은 복수 경우는 성과도 더 좋아졌다는 사실이다.

과연 나는 신뢰를 깎아 먹는 공유를 하고 있었을까? 아니면 신뢰를 쌓아가는 공유를 하고 있었을까?

복수 공유의 특징 즉, 투명한 공개와 시행착오의 공유는 회고의 또 다른 형태로 보인다.

객관성의 주관성

팀장 자리에 있으면 새로운 아이디어 전파가 쉬울 거라고 생각하는 것은 환상입니다.

애자일 같은 새로운 개념을 주변에 설득하기 위해 노력하는 사람들이 있다.

어떤 측정 자료를 근거로 해여할지, 효과적인 사례는 뭐가 있는지 등등..

사실은 이런 자료에 근거한 것 보단 상대방에 대한 이해가 먼저 선행되어야 한다.

책에선 함수 포인터에 대한 설명으로 강사와 학생의 입장으로 보여준다. (실패하는 이유)

품질은 상대적이다

품질이란 누군가에게 가치가 되는 것이다.

제럴드 와인버그

실제로 사용되는 품질의 정의와는 조금 다른 느낌인데, 실생활에서 사용되는 품질의 경우 성능이 얼마나 좋은가?, 요구사항과 얼마나 일치하는가?등으로 품질을 이야기 하곤 한다.

하지만 이런 정의는 상당히 플라톤적이며, 고상하고 완벽한 품질이라는 것이 존재한다고 생각한다.

반해, 와인버그의 주장은 상대적이며 동시에 실용적이다.

사실 품질은 사람을 빼놓고 이야기할 수 없다. (사람이 없으면 품질이라는 개념 자체가 없다.)

결함또한 상대적으로 정의된다.

이런 이유로 품질 관련 일을 하는 사람들, 고품질을 얻으려고 노력하는 사람들은 ‘인간’에 대한 이해가 필수적이라고 한다.

설득도 마찬가지로 사람들을 설득하기 위해선 객관성이 필요하다고 생각한다.

그런데 이 개념 자체가 매우 주관적이라는 것이다. (인지적 편향의 발생)

결국 결정하는 것은 사람이다.

객관성을 확보하기 위해 데이터를 수집하고 분석하는 것은 좋은 방법이지만, 이것만으로는 부족하다.

마음에 들지 않으면 객관적 자료를 갖다 줘도 설득할 수 없다.

감정을 배제할 수 없다

“그건 판단하는 사람이 잘 못돼서 그런거야. 감정적인 선호에 휘둘리지 말고 논리적 판단을 해야지”

하지만 논리적이라는 것도 상대적이고, 논리랑 감정적 판단을 분리할 수가 없다.

다양한 연구 사례에도 불구하고 사람들은 이성과 감정은 분리할 수 있다고 생각한다. (나아가 그렇게 해야한다고 생각한다.)

따라서 설득에는 상대방에 대한 대화와 이해가 필요하다.

성향과 기질에 따른 애자일 설명법

KAI라고 하는 사람의 인지 성향에 대한 이론을 빌려서 애자일을 설명해본다.

• I(Innovation)에 가까운 사람에게는: “애자일 이거 정말 새로운 겁니다. 이걸하면 당신에게 새로운 경험을 할 기회가 생깁니다. 모조리 싹 바뀔 겁니다.”
• A(Adaption)에 가까운 사람에게는: “애자일은 새로운 것이 아닙니다. 기존의 방법들을 더 낫게 개선한 겁니다. 지금 하고 있는 업무 방식을 조금 더 효율적으로 개선하는 겁니다. 많이 바꿀 필요가 없습니다.”

MBTI도 마찬가지로 큰 그림을 그리는 NT, 사람들관의 관계에 관심이 많은 NF, 구체적이며 체계적인 SJ, 모험을 좋아하고 닥친 문제를 푸는 것을 즐기는 SP 이렇게 4가지로 구분하여 설명한다.

• NT(직관적 사고형): “애자일을 하면 낮은 의존성과 높은 응집성의 이상적이고 우아한 설계를 실제로 구현하고, 또 지속적으로 유지할 수 있습니다. 이제 스파게티 코드는 안녕입니다”
• NF(감정적 사고형): “고객과 우호적 관계를 이어갈 수 있습니다. 팀원들 모두가 신뢰하고 협력하면서 즐겁게 일할 수 있습니다. 누군가를 비난하거나 하는 일은 없을 겁니다. 개인적 성장도 가능합니다.”
• SJ(감정적 판단형): “효율적입니다. 낭비되는 작업을 하지 않습니다. 불필요한 문서화나 회의를 안 합니다. 현 프로젝트 상황이 한눈에 들어오고, 지금 당장 뭘 해야할지가 명확하게 보이게 됩니다. 더 안전합니다. 데드라인에 와서 죄송합니다라고 말하는 상황이 절대 나오지 않고, 점점 정확한 예측이 가능해집니다.”
• SP(감정적 지각형): “설계한다고 몇 달씩 시간 끌지 않습니다. 당장 개발로 들어갈 수 있습니다. 순식간에 원하는 코드를 바꾸고 테스트를 통과하고 하는 짜릿한 경험을 할 수 있습니다. 테스트가 실패하면 그 원인이 되는 버그를 찾아서 고치는 것이 마치 게임 같습니다.”

결론은 객관성이라고 하는 것은 상대적이며, 내가 생각하는 객관이 상대방의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다는 말이다.

그러므로 설득을 하기 위해 객관적 자료를 모으는 부분 이상으로 상대를 이해하는 데 많은 시간을 투자해야 합니다!

이것도 모르세요?

대부분의 사람들은 질문을 쉽게 하지 않는다.

그리고 데드라인 다 되어서 “못했습니다.”라고 이야기를 한다. (or 어느정도 노력한 흔적, 연기, 그럴듯한 결과물을 가져온다.)

홍춘이와 술퍼맨의 대화에서 명백하게 홍춘이의 잘못이다.

(질문 방식에 대한 조언을 하려면 먼저 답변을 해주고 더 좋은 접근 방법을 소개시켜 준다.)

공감하고 이해하려는 대화

이번 대화에서 중요한 점은 답변자가 질문자의 어떤 멘탈 모델(개인이 갖고 있는 믿음과 생각)을 파악하려고 했다는 점이다.

이런 과정을 통해 답변자는 질문자의 사고방식을 어느정도 엿볼 수 있고, 답변자는 질문자의 사고방식을 파악할 수 있다.

그렇게 되면 이 상황에서 왜 이런 접근을 했는지, 할 수밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 답변을 할 수 있다.

이 방법은 누가 물어볼 때뿐만 아니라 실수나 잘못을 했을 때도 효과적으로 도움을 줄 수 있다.

능력없는 팀장일수록 비난만 한다.

나중에 비슷한 일이 생기게 되고 악순환이 반복되게 된다.

하지만 훌륭한 팀장이라면 먼저 그 사람의 사고 과정과 전략을 이해하려고 한다.

행동을 유도하는 대화

여기서 좀 더 나아가서 다음 행동을 유도하는 코칭까지 나갈 수 있으면 더욱 좋다.

행동으로 옮길 수 있도록 공감을 통해 상대방의 멘탈 모델을 참고하여 적절한 질문을 하고, 해당 답변을 통해 스스로 행동할 수 있도록 유도한다.

이 과정은 10분이면 충분하고, 흥미로운 점은 코치 자신이 해당영역에 전문지식이 없어도 코칭을 할 수 있다는 점이다. (공감의 효과)

하향식 접근의 함정

우리는 일정의 미신을 갖고 있다. “전문가는 언제나 탑다운으로 깔끔하게 생각할 것이다.”

탑다운은 문제 해결 과정을 시간의 흐름에서 볼 때 추상적인 숲에서 출발해서 점점 더 구체적인 나무로 내려오는 접근법을 말한다.

그 반대라 할 수 있는 바텀업은 나무에서 출발해서 숲으로 올라오는 과정이다.

탑다운은 더 깔끔해 보이는데, 바텀업 탐색적인 성격이 많다.

여기저기 찔러보거나 방향을 바꾸기도 한다.

기업이나 실제 전문가들은 탑다운의 모습을 띄기도 한다. (특히 기업에서 많이 보인다.)

인공지능 연구에선 이 세상의 문제를 두 종류로 나눈다.

잘 정의된 문제와 잘 정의되지 않은 문제.

잘 정의되지 않은 문제는 출발 상태와 목표 상태가 명확히 알려져 있고 그 상태 간 이동의 규칙이 주어진 문제를 일컫는다.

오목이나 체스 같이 승패와 말의 이동 규칙이 명확한 게임

하지만 “벽을 장식할 아름다운 그림을 그리시오” 같은 문제는 잘 정의되지 않은 문제다.

무엇이 목표 상태인지 불분명하다.

심지어 최초의 출발 상태에 대한 정보도 온전히 주어지지 않고, 무엇이 적법한 행동이고 부적법한 것인지 규칙의 경계도 불투명하다.

잘 정의된 문제는 연구하기가 쉽기 때문에 많은 연구가 이루어졌다.

하지만 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제이다.

사실상 뭔가 만들어야 하는 문제, 디자인이 개입더ㅣ는 것은 거의 다 제대로 정의될 수 없는 문제다.

실제 전문가들은 자신이 자주 접하지 않았던 문제를 만나면 접근법을 바꾼다.

탑다운과 바텀업을 섞어 사용하는데, 뛰어난 전문가일수록 더욱 그러하다.

이런 현실에도 우리는 이 믿음을 협력 방식에도 도입하여 사용한다.

오히려 전문가일수록 불확실한 일에서는 초보자의 마인드로 돌아가고 비전문가일수록 탑다운으로 접근한다.

비전문가는 계획을 수정하지 않고, 전문가는 계획을 많이 수정한다.

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

오버헤드를 낮추려면 협력 모델이 바통 터치 모형에 기반하지 않고 삼투압 모형에 기반해야 한다.

뛰어난 팀들의 몇 가지 특징으로 대부분 삼투압적 의사소통이라는 특징을 보인다.

삼투압적 모형은 화살과 같은 모형이 아닌 은연중에 스며드는 것이다.

전문가팀이 실패하는 이유

사업을 하는 사람들이 흔히 버스에 사람 태우기라는 메타포를 이야기하곤 한다.

이 메타포를 사용하는 사람은 상당수는 ‘뛰어난 사람’을 뽑는 것이 얼마나 중요한가를 말하기 위해 이 비유를 든다.

그들에게 있어서 뛰어난 사람은 해당 전문 분야의 역량이 뛰어난 사람을 의미한다.

소프트웨어로 따진다면 남들보다 뛰어난 개발 실력을 가진 사람으로 어려운 기술을 잘 쓰면서 남들보다 짧은 시간에 코드를 만들어 내는 능력이 될 것이다.

하지만 뛰어난 사람을 뽑아두면 어떻게든 잘할 거라는 사고가 지나치게 낙관적인 기대라고 생각한다.

실제 연구 결과에서도 가장 뛰어난 팀을 골라서 만든 올스타팀 (롤 올스타전과 같이)의 결과는 스타들이 한 명씩 추가될 때마다 한계효용(점차 줄어든다.)을 보이며 어느 수준을 지나면 음의 방향으로 작용한다고 한다.

결국 결과가 더 안좋아지고 이 실상 이팀의 비용도 생각하지 못한 것으로 비용까지 따지게 되면 더욱 안좋아진다.

비전문가와 전문가를 데리고 실험을 했는데 단순 전문가를 모아둔다고 해서 높은 성과가 나오지 않은 것이다.

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

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

구글은 뛰어난 팀의 특징을 찾기 위해 옥시전 프로젝트 이후에 아리스토텔레스 프로젝트를 진행했다.

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

실수율이 낮은 병원이 좋은 병원이 아니다.

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

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

그렇다면 심리적 안전감을 높이려면 어떻게 해야 할까?

앞에서 언급한 팀 토론 등 특별히 고안된 활동을 통해 토론 주제를 안전한 환경에서 이야기하게 해주는 것 자체가 심리적 안전감을 높일 것이다.

단순히 우리팀의 현상황에 대해 연린 대화를 시작하는 것만으로 변화가 시작될 수 있다고 생각한다.

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

쾌속 학습팀

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

기술적 변화는 언제 어디서든 찾아올 수 있다.

이를 패러다임의 전환이라고 하며, IT업계에서는 전환 주기가 짧아서 더욱 빠르게 변화가 일어난다.

개발자에게 있어 학습이라는 것, 더 나아가 빠른 학습이라는 것은 늘 고민거리이다.

최소 침습 심장 수술

그렇다면 팀의 학습속도를 높이기 위한 방법이 뭐가 있을까?

실제 수술팀의 경우 팀 학습의 가장 대표격으로 이야기가 되는데, IT업계의 개발팀도 마찬가지의 형태이다.(각 분야로 나눠진 전문가들)

실제 수술팀에 어느정도 러닝커브가 있는 시술법(새로운 기술)을 학습하게 하고 이를 실험해봤는데, 각 팀마다 천차만별의 결과를 도출했다.

학습 속도와 상관없는 것

학습 속도와 상관 없는 것에는 교육 배경, 수술 경험 등 은 학습 곡선의 기울기에 영향을 주지 못했다.

참고로 의사의 실력, 예컨대 수술 성공률과 경력 연차가 통계적으로 상관성이 없다는 널리 알려진 사실이다.

따라서 무조건 젊은 의사라고 신뢰하는 것은 좋지 못하다.

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

논문 결과에서도 기술적 탁월함을 갖춘 사람 보다는 학습 환경을 만들 수 있는 리더가 필요하다는 것이다.

학습 환경의 차이

학습이 빠른 팀은 팀원을 뽑을 때부터 달랐다.

선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라, 선발 기준도 달랐다.

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

또한, 속도가 빠른 팀은 새로운 수술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다.

개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.

마지막으로 속도가 빠른 팀은 심리적으로 보호가 되고 있었다.(새로운 것을 제안하고 시도하는 데 두려움이 없음)

기술 전환에 성공한 개발팀

개발도 마찬가지로 PHP에서 자바로 이동에서 자바를 능속하게 하는 사람이 있는지가 중요한 것이 아닌, 리더와 팀원들의 학습에 대한 태도가 근본적인 차이였다.

리더가 기회와 가능성, 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.

반면 느린 팀은 그것을 개인 과제정도로 생각하고 실력이 부족하다고 불평을 자주 했다.

현실에서 실천하기

우선 자신의 학습 환경을 만드는 것이 중요하다.

개별 기술 이상으로 일하는 방식에 대해 실험을 해보고, 실패에 좌절하지 말자(사실 실험에는 실패는 없다. 학습만 있을 뿐)

학습과 일을 굳이 분리하지 말고 동체로 만들 것, 학습과 실행은 하나이다.

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

이 말의 힘을 느끼려면 정반대를 생각해볼 것

프로젝트 확률론

어디에 돈을 걸 것인가

생략

직관의 허점

위 사례에서 보여주는 직관의 허점을 말해준다.

(사실 나는 첫 번째 문제에 2번 두 번째 문제에 2번을 선택했다..)

불확실한 상황에서의 판단 (인지적 편향, 추정에 관한 추천 책)

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

이제 프로젝트로 바꿔서 생각해보자.

우리는 흔히 통상 시간을 추정할 때 대푯값으로 최반값을 선택하는 경향이 있다.

개발자는 약속이 아닌 대부분의 추정을 한다.

그 추정은 대부분 어긋나기에 더욱 더 중요하다.

• 클린코더 추정에 관한 글

애자일 확률론

애자일 프로젝트라면 어떨까?

관심사의 섞임을 통해 일의 병렬처리가 아닌 협동을 중시한다.

고전적인 방법과 달리 일을 공유하고, 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다.

애자일에선 일이 빨리 끝나면 다른 사람의 일도 자신의 일이기에 자연스럽게 협동하게 된다.

애자일은 좋은 일에 대해서는 ‘그리고’ 확률을 ‘또는’ 확률로 바꾸고, 나쁜 일에 대해서는 ‘또는’ 확률을 ‘그리고’ 확률로 바꾼다.

개개인이 같은 일을 따로 처리하는 것이 아닌 팀으로써 일을 처리하는 것이다.

마무리

2장은 함께라는 주제에 맞게 팀이 어떻게 협력하고, 어떻게 협력을 통해 성과를 내는지에 대한 이야기를 했다.

팀이라는 것은 한 덩어리이며 같이 굴러가야 한다는 점과 지금 내가 진행하고 있는 프로젝트에 적용하고 싶은? 필요한 내용이 많아서 좋았다.

3장 애자일

지금까지 0~2장까지 애자일이라는 말이 여러번 등장했지만, 그 정의에 대해서 직접적으로 논하지 않았다.

과연 애자일이란 무엇일까?

먼저 좁은 정의를 알아보면, 애자일 소프트웨어 개발 방법론은 소프트웨어를 개발하는 한 가지 스타일을 일컫는다.

대략 1990년대에 그 모습을 드러내기 시작했으며, 그 당시 전통적인 소프트웨어 개발 방식이 너무 느리고 비효율적이라는 것을 깨닫고 나서 등장했다.

이 방법들간의 유사성을 추려서 선언문을 작성한다. (자신들이 사용하는 방법 이면에 깔려 있는 공통된 철학, 추구하는 가치와 원칙을 추려냄)

이 때 공시겆로 선언문을 작성한 것이 애자일 선언문이다.

당시 주도적인 소프트웨어 개발 방식은 계획주도의 방식이었다.

초반에 계획을 정교하고 꼼꼼하게 만들려고 엄청난 노력을 하게 되고 이를 통해 실행단계에는 간단하고 예측이 가능해진다고 믿었기 때문이다.

하지만 애자일은, 불확실성이 높은 일에 대해서는 애초에 이것이 불가능하다고 본다.

불확실성이 크기에 미리 분석하고 설계하는 데 한계가 있다고 생각하는 것이다.

사실 애자일은 불확실성이 클 때 우리가 어떻게 해야 하는지를 고민한 결과물로 불확실성에 높은 일에 적합하다.(프로젝트)

애자일이 불확실성을 다루는 방식은 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 일찍 피드백을 받는 것으로 정리할 수 있다.

이런 특징을 가진 애자일 방법론은, 마침 시대가 바뀌면서 불확실성이 낮은 프로젝트는 비즈니스적 가치가 없어지고 불확실성이 높은 프로젝트를 하는 것이 일반적이 됨에 따라 인기를 얻게 되었다.

여기까지가 협소한 의미의 애자일이었다면 이번엔 광의의 애자일을 알아보자.

애자일을 단순히 소프트웨어 개발 방법론이라는 울타리에 가두지 말고, 일하는 한 가지 스타일, 혹은 더 넘어 삶을 사는 방식까지 확장시키는 것이다.

이건 더 넓은 의미의 애자일로 이런 시각은 삶의 다양한 면에도 불확실성을 컨트롤 하는 데 도움이 된다.

지금까지 다룬 1장과 2장의 학습 방법, 협업 방식 모두 애자일의 핵심적인 구동원리이다.

먼저 학습에 대해서 이야기해보면 다음과 같다.

불확실하다는 것은 이동을 할 때 목표점의 위치가 자주 바뀌거나 현재 위치가 자주 바뀌거나 하는 상황으로 비유할 수 있다.

그럴 경우일수록 우리는 가다가 멈춰 서서 주위를 둘러보고 목표점과 우리 위치를 확인하는 것 같은 피드백을 통해 방향을 재조정하는 일을 자주 해야할 것이다.

초기 계획대로 가면 완전히 동떨어진 곳으로 갈 수 있다.

다시 말해 이동하면서 계속 배워나가야 한다는 것이다.

불확실성이 높을수록 학습을 잘해야 하는 것이다.

계속해서 새로운 상황에 대해서 계속 배우고 내가 맞춰 나가야 한다.

따라서 학습 능력을 향상시킬 수 있다면우리는 불확실성에 대해 더 잘 대응할 수 있다.

협력은 두 가지로 나눠서 생각해볼 수 있다. (안 좋은 일이 생기는 경우, 좋은 일이 생기는 경우)

불확실한 상황일수록 리스크가 높은 것이고, 고로 안 좋은 일이 벌어질 확률이 높은 것이다.

일반적으로 안 좋은 일이 벌어질 확률은 ‘또는’ 조건으로 연결되어 있을 때 더 높아진다.

앞서 다뤘지만 결과적으로 애자일은 서로의 업무를 공유하면서 상호 검토를 하는 협력을 통해 불행한 일을 ‘또는’ 조건을 ‘그리고’ 조건으로 바꾸는 것이다.

반대로 불확실한 상황에서는 예상치 못한 좋은 일이 생길 확률도 있다.

그런 경우 이 좋은 일을 확장해야 한다. 애자일의 좋은 일의 상황에 대해서는 ‘그리고’ 조건을 ‘또는’ 조건으로 바꾸는 것이다.

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

학습과 협력은 불확실성이 큰 상황에서 좋은 대응 전략이 된다!

애자일의 씨앗

애자일의 핵심, 애자일의 씨앗이라고 할 수 있는게 무엇일까?

글이나 말을 통해 애자일을 배우는 것은 한계가 있고 결국은 어떤 씨앗을 갖고 각자 자신의 토양에서 고유한 나무를 키워내야 한다.

고객에게 매일 가치를 전하라

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

매일한다는 것의 반대는 몰아서이다. 벼락치기 하지 않고 매일 조금씩 해나간다는 것이다.

스스로 이 씨앗을 되새기고 잘 실천하는지 계속해서 확인해보자.

애자일 도입 성공 요인 분석

애자일 도입 설문

설문을 통해 궁극적인 애자일이 아니더라도 애자일을 실천하고 있다는 것 만으로 긍적인 효과를 얻을 수 있다는 것을 알 수 있었다.

애자일 도입에 대한 무서운 사실

다양한 결과속에서 얻은 교휸은 두려워도 중요하다면 시도해봐야 하지 않겠는가이다.

성숙도가 낮다면 고객 참여는 필수

성숙도가 낮은 조직을 보면 고객 참여가 유의미한 실천법으로 나타난다.

반대로 성숙도가 높은 조직은 반복 개발 주기가 1등이다.

고객 참여보다 짧은 반복 주기가 성공에 더 도움이 될 수 있다는 뜻이다.

즉, 애자일에 대해서 어느정도 이해하고 성공 기여도를 높이려면 짧은 반복 개발 주기, 고객 참여, 코드 공유에 관심을 기울여야 한다.

이런 것들을 제대로 하지 못하면서 다른 실천법만 계속 신경쓰고 있으면 프로젝트의 성공을 미루는 일이 될 수 있다.

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

소프트웨어 개발 에서 예측이 어렵고 복잡한 도메인이라는 점은 대부분 인정을 할 것이다.

새 프로젝트를 진행할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제이다.

애자일 방법론 도입을 원하는 팀장이라면 “나는 어떤 팀장인가”를 먼저 자문해봐야 한다고 생각한다.

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

애자일을 도입하고 싶어하는 팀들은 많지만 성공적인 사례는 별로 없다.

가장 대표적인 실수가 애자일을 반애자일적으로 진행하는 것이다.

방법론 도입이라는 것 자체가 매우 불확실성이 강하기에 거의 모든 종류의 방법론 도입에 적용되는 원칙으로 애자일하게 접근하는 것이 좋다.

현명한 전략은 정해진 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 현 맥락에 맞는 좋은 전략들을 스스로 만들어 나가는 것이다.

마무리

추천 책으로 읽기 시작했지만, 다른 책에 밀려서 가끔읽었던 책인데 2장부터는 진도가 빠르게 나갔던 책이다.

다른 책에서도 많이 나오는 내용들이라 더 공감이 갔으며, 실제 팀을 운용하는데 있어서 내가 좋은 방향으로 가고 있는지 검증하기 좋은 멘토책이였다.

3장에서 말하는 고객의 피드백을 듣고 빠르게 개선해나가는 것을 좀 더 실천해보고 싶다는 생각이다.