요즘 책 읽기가 부쩍 재밌어졌다! 개발 공부를 위해 공식 문서, 블로그를 떠돌아다니는 것도 재밌지만 책 읽기만의 매력을 느꼈달까?,,, 핵심 주제에 대해 심도 있게 파고들며 많은 생각을 할 수 있게 해준 다는 점이 가장 크다고 느낀다.
가끔은 반복되는 말을 하는 것 같은 느낌도 들지만, 그래서 더 소중하다! 함께 자라기에서도 언급했듯이, 무슨 책을, 얼마나 많은 책을 읽었다고 자랑하는 것이 아닌 여기서 얻은 지식을 얼마나 어떻게 활용했는지를 돌아보려면 그 맥락에 대한 깊은 이해가 필요하기 때문이다.
역시 나는 책을 많이 읽는 것보다, 책을 잘 읽는 것에 더 관심이 간다.
아카데미에서도 꽤나 유명한 '함께 자라기'를 지나가듯 들었던 기억은 있었지만 읽을 생각은 하지 않고 있었다. 가장 큰 이유는 자기 계발서에 나오는 내용들보다 개발 지식이 지금 내게 더 가치 있다고 느꼈기 때문이었다.
그리고 여느 때처럼 보노와 열띤 이야기 중에(개발 얘기만 나오면 시간 가는 줄 모름) 하드 스킬적인 내용은 아니지만, 개발자의 관점에서 배울 점이 분명하다는 말과 함께 이번 책을 추천받게 되었다.
보노라면 좋은 책을 추천해 줄 것이라는 믿음을 가지고 있었기 때문인지 "어, 한번 읽어봐야겠는데?"라고 마음이 바뀌었고, 게다가 때마침(?) 룸메이트가 가지고 있어 "어디 한번 읽어보자!"라는 마음으로 책을 펼치게 되었다.(에이스야 고마워)
나는 성장하고 싶다. 어제보다 나은 내가 되기 위해 하루하루 열심히 노력하고 있다. 그만큼 성장에 대한 고민도 많이 했다. 아니, 많이 했다 생각했고 그렇기에 나름의 방법도 있었다. 내가 바라보고 있는 '성장'이 무엇인지 잘 안다고 확신했었다.
하지만 이 책을 읽으며 내가 정의하고 있는 '성장'이 무엇이었을까? 되돌아보게 됐다. 성장을 위해 학습 방법을 학습해야 한다는 것의 필요성을 느끼게 됐다.
저자는 성장과 관련된 여러 가지 키워드를 제시한다. 애자일, 사회적 자본, 삼투압적 의사소통, 협력, 피드백, 추상화, 공유, 설득, 실수에 대한 인정, 심리적 안전감, 학습 환경을 만드는 리더 등이다.
그리고 모든 키워드는 하나의 본질적인 것으로 귀결된다. 바로 '사람'이다. 역설적이게 들릴 수도 있겠지만, 내가 성장하고 싶다면 다른 사람과 함께 성장해야 한다. 이것이 내가 느낀 이 책의 핵심 문장이다.
언뜻 보기에 효율적이지 못하다고 생각할 수 있다. 내가 해야 할 일도 많은데 언제 다른 러너에게 피드백을 주고 있겠는가? 동료의 실수로 문제가 생겼다면 그 책임은 당연히 그가 짊어져야 할 것이다. 기획 이후 디자인 팀과 개발팀의 대화는 적어지는 게 누가 봐도 합리적일 것이다.
우리는 수도 없이 이런 상황들을 마주쳐왔다. 성장의 포커스가 '나'에 맞춰져 있기 때문이다. 당장은 빠를 수 있다. 기능을 하나 더 완성할 수도 있고, 책임에 대한 스트레스를 받을 일도 없을 것이고, 오로지 '내 일'에만 집중할 수 있다 생각할 것이다.
하지만 그뿐이다. 만약 성장했다고 해도 더 큰 기회를 잃은 것이라 확신할 수 있다.
동료와의 피드백에 시간을 쓰지 않겠다는 것은, 관계적으로든 역량적으로든 피드백을 받는 것도 어렵게 만든다. 이는 내 성장의 관점에서 발전도 어려울뿐더러 문제가 있더라도 전혀 인지하지 못할 것이다.
실수에 대한 책임을 동료에게 돌린다는 것은, 결국 나의 실수도 인정되기 어렵다는 뜻이다. 이는 창의성과 자율성을 해치고 오히려 더 큰 실수를 불러올 수 있다. 실수를 통해 배움을 기대하는 것이 아닌 불안함만 남게 되는 것이다.
팀 간의 커뮤니케이션이 적어진다는 것은, 반대로 '내 일'에 더 집중하지 못하게 만들 것이다. 커뮤니케이션이 적어지니 요구사항에 대한 이해도가 떨어져 개인적으로 자주 연락해야 할 것이며, 작업을 여러 번 다시 하는 상황이 발생하다 보니 일정이 지연되고 결국엔 팀 간 갈등으로 번질 수도 있다.
하지만 늘 그렇듯, '다른 사람과 함께 성장하기' 같은 눈에 보이지 않는 것을 좇는 일은 어렵다. 그래서 우리는 상황을 '언뜻' 보지 말고 '세심하게' 봐야 한다. 당연하지만 당연하지 않은 것을 위해, 내 성장과 동료들의 성장을 위해 다시 한번 마음에 새기자.
동료의 말과 피드백에 귀 기울이자.
동료의 실수에 대해 같이 책임지고, 회복할 수 있게 돕자.
팀 간의 커뮤니케이션과 공유를 위해 노력하자.
성장의 포커스를 나에서 '우리'로 재조정하자.
마지막으로 누군가에겐 걱정이 가득한, 새로운 기회를 찾고 있는, 꿈꾸는 것을 만들기 위해 고민 중일 모든 러너 분들께 내가 얻은 소중한 질문을 드리고 싶다.
"함께 성장할 수 있나요?"
이 질문은 앞으로도 내게 이정표와 같은 역할로서 성장의 길을 이끌어 줄 것이다!
지금 잘하냐?가 아니라 지금 자라냐.
우리가 정말 매일매일 함께 자랄 수 있을까?
학교 학습 <-> 야생 학습
야생 학습?
학습 방법을 학습해야 한다!
경력 연차로 채용 여부나 임금 수준을 결정한다는 것은
판단 편의적이고, 관료주의적이며, 결과적으로 조직에 손해를 줄 수 있는 방식.
직무 성과와 상관성이 낮은 것들
직무 성과와 상관성이 높은 것들
결론?
경력과 실력을 동등하게 보는 함정에 빠지면 잘못된 전문가상을 갖게 될 수 있다!
조직은 개인이 자신의 전문성을 좀 더 발전시키고 관리할 수 있도록 최대한 지원해야 한다.
그것이 윈윈하는 길!
애자일 프로젝트는 지금 내가 한 행동의 피드백을
10분 후, 1시간 후, 하루 후, 일주일 후 등 여러 주기를 통해 지속적으로 얻을 수 있다.
학습은 피드백이 중요하다.
피드백 시점도 중요하다 → 너무 오래걸리면 효과가 떨어진다.
자기계발은 복리로 돌아온다.
더 빨리 자라고 싶다면?
매일 더 나은 내가 된다.
1. 자신이 이미 갖고 있는 것들을 잘 활용하라
2. 외부 물질을 체화하라.
3. 자신을 개선하는 프로세스에 대해 생각해보라.
4. 피드백을 자주 받아라.
5. 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.
실험 프레임은 여러분의 목표가 학습을 통한 성장이라면 불리한 선택이다.
알파고 같은 인공지능 시대에 대비하려면 배우기 힘든 것에 집중하라.
피드백이 주어지고 작업이 반복되며 객관적 분석이 가능한 경우에 해당 직업에서 전문성이 잘 드러난다.
-> 학습이 잘 일어나는 조건
컴퓨터화에 병목이 되는 3가지 카테고리
3가지 카테고리에 속하는 변수
어떤 직업을 컴퓨터화 할 수 있는 확률이 높을수록, 해당 임금이 낮았음.
소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며,
그 과정에서 타인과 상호작용하는 업무가 많다.
→ 개발자는 더 높은 수준의 협상 능력이 필요하다!
자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것이다.
지금이라도 암묵지와 직관을 배우고 수련하는 방법을 배우면 된다.
꾸준한 반복으로 달인이 되려면?
특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스/경험을 오래한다고 해서 자동으로 얻을 수 있는 것은 아니다.
믿을 수 있는 직관이 형성되려면 특정 조건이 필요하다.
전문성 향상을 위해선 타당성과 피드백을 높이는 환경을 만들자!
타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력!
피드백을 높이려면 동료, 상사, 고객에게서 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하기!
실력을 높이기 위해서는 의도적 수련이 중요하다.
의도적 수련을 효과적으로 하기 위해서는?
의도적 수련의 필수 요건 중 하나가 '적절한 난이도'
자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 것.
하지만 우리에겐 매번 몰입하는 일만 주어지진 않는다...
a1 : 작업의 난이도는 그대로 두고 실력을 낮추는 전략
a2 : 실력은 그대로 두고 난이도를 높이는 전략
b2 : 실력 높이기
b1 : 난이도 낮추기
현재 자신의 업무 처리 속도가 외부적으로 문제가 되지 않는 범위 내에서 적절하게 난이도와 실력을 조정해야 한다.
메타인지는 모든 분야의 전문성에 있어서도 핵심적인 요소다!
새로운 언어를 효과적으로 익히는 달인의 방법
전문가들의 전문성을 뽑아내고 적용하는 것이 자신의 전문성을 빨리 높일 수 있는 방법.
전문성을 뽑아낼 수 있는 질문?
무엇인가 잘하고 싶다면 이미 잘하는 사람을 관찰하고, 인터뷰하는 것부터 시작하는 것이 큰 도움!
실수 관리 문화는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생긴다.
실수가 없으면 학습하지 못한다.
불확실한 상황 하에 실수는 피할 수 없다.
지식이 많은 사람을 뛰어난 선생으로 보는 시각은 앞에서 말한,
교육의 효과를 결과가 아니라 투입으로 측정하는 것과 비슷한 오류가 있다.
선생 입장에서는 자신에 대한 메타인지를 높이는 노력하기
아무리 기술적인 실천법이라고 해도 그 기술은 사회적 맥락 속에서 실천되어야 하며, 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다.
신뢰가 깨져있는 상태에서는 어떤 행동을 해도 악의적으로 보인다.
신뢰 == 사회적 자본의 일종
뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓴다. → 동료와의 협업
사회적 기술 훈련 → 마이크로 인터랙션 → 인사 주고 받기, 지나가는 대화 물어보기 등
저자가 중요하게 다루는 사회적 기술
"저는 OOO을 도입하려고 장점에 대한 발표도 하고 교육도 몇 번에 걸쳐 해줬는데 결국 사람들이 쓰게 하는데에 실패했습니다. 사람들이 너무 수동적이고 보수적이에요." -> "그 조직원들이 선생님을 좋아하나요?"
제럴드 와인버그가 이야기하는 소프트웨어 개발을 잘 관리하려면 3가지 근본적 능력.
실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유는? -> 관리
그에 반해 보통하는 개선 시도는? -> 도구
소프트웨어 개발 관리자는 자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 될 것.
실력이 뛰어난 프로그래머는 커뮤니케이션과 협력에 더 오랜 시간을 들인다.
집단의 성과가 부분의 합을 넘는다.
둘이서 협력하며 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다. 서로 다른 것들을 하나로 묶어야 하기 때문.
소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특정지을 수 있다.
추상화를 높일 수 있는 방법 -> 다른 시각을 가진 두 사람이 협력하기
자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화할 것.
3가지 공유 방법
복수 공유!
객관의 개념 자체가 매우 주관적이다.
가만히보면 우리는 그동안 우리의 객관만 신경을 쓰는 실수를 저질러 왔다.
의사결정을 하는 과정에 감정적이고 직관적인 부분이 배제된다면 의사결정을 제대로 할 수 없다.
감정과 이성을 분리할 수 없다.
남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 한다. 그래야 현실적으로 설득이 가능하다.
내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야한다.
출발은 결국 내가 설득하려는 사람에게서 하는 것이다. 자료에서 출발하는 것이 아니다.
객관성이라고 하는 것은 상대적이며, 내가 생각한 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다.
설득을 하기 위해 객관적 자료를 모으는 부분 이상으로 상대를 이해하는데 많은 시간을 투자해야 한다.
전문가는 상황 파악을 먼저 하지만, 초보자는 뭘 할지부터 정하려고 한다는 차이를 발견했다.
공감해주고, 잘 들어주고, 그 사람의 멘탈 모델을 이해하는 코칭이 필요하다.
삼투압적 의사소통 -> 은연 중에 서로 간에 정보가 스며든다!
개발 5단계 (분석-설계-구현-테스트-전개)를 프로젝트 기간에 얼마씩 배치할지 고민하지 말고,
첫 주부터 이 사이를 모두 왔다갔다 할 수 있을까를 고민해야 한다
탑다운이 아닌 삼투압적으로!
그로이스버그 등의 연구에 따르면 스타들이 한명씩 추가될 때마다 팀의 추가적 성과 향상은 한계 효용을 보이며, 어느 수준을 지나면 음의 방향으로 작용한다.
그 원인 중 하나는, 전문가의 Ego
팀에 작업 관련 전문가가 포함되는 것과 동시에 각 멤버의 작업을 조율하고 통합하는 전략을 팀이 드러내놓고 탐색하는 경우에 팀의 분석 작업이 가장 높은 수준의 효과성을 보인다.
팀에 누가 있는지(전문가, 내향/외향, 지능)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
5가지 성공적인 팀의 특징을 찾았는데, 그 중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다.
특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
심리적 안전감?
-> 내 생각이나 의견, 질문, 격정, 혹은 실수가 드러났을 때 처벌 받거나 놀림 받지 않을거라는 믿음.
팀원이 불편한 문제를 제기하거나, 어리석어보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니 없는 실수를 저지를 때 우리는 어떤 마이크로 인터랙션을 보이고 있는가?
리더가 팀 학습 속도에 미치는 영향
→ 단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다!
학습이 빠른 팀은 팀원을 뽑을 때 부터 달랐다.
학습이 빠른 팀의 특징
속도가 빠른 팀은 새로운 기술 도입을 기술적 도전이라기보다, 조직적 도전으로 받아들임. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.
속도가 빠른 팀은 심리적으로 보호가 되고 있었다. 뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 대해 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다.
속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했다.
자신의 학습환경 만들기 -> 학습과 일을 굳이 분리하지 말고 동체로 만들어라
작지만 유용한 프로그램을 매일 작성할 것을 추천한다!
소프트웨어 공학 쪽의 연구를 따르면 사람들이 통상적으로 추정하는 소요 시간에 적어도 2~3배를 해야 80% 확률로 마칠 수 있는 시간이 나온다고 한다.
애자일의 특징
애자일이라면 관리자가 12명에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청할 것이다.
애자일은 고전적 방법과 달리 일을 공유한다. 각자 일을 얼마나 진행했는지 매일 공유하고,
내 일, 네 일의 구분선이 뚜렷하지 않다.
애자일에서는 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다.
애자일은 되도록 일 진행에 단계를 두지 않으려고 한다.
애자일은 마치 프랙털 구조처럼 부분 속에 전체가 들어가게 한다.
애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고,
나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾼다.
학습과 협력이 애자일의 불확실성을 다루는 핵심적이 구동 원리.
애자일은 서로의 업무를 공유하고 상호 검토하는 협력을 통해
불행한 일을 '또는' 조건에서 '그리고' 조건으로 바꾸게 한다.
"고객에게 매일 가치를 전달하라!"
고객은 넓은 의미로 이해관계자
중요한 것은 어렵고 두렵지만 중요한 것을 '얼마나' 뒤로 미루느냐, 두려워도 중요하면 시도해봐야 하지 않겠는가?
진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력하는 것.
애자일 도입의 핵심적 성공 요인?
→ 성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었다.
뛰어난 애자일 코치는 함께 자라기를 하는 사람이다.
우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제가 아닐까?