책 <함께자라기>

1. 기억하고 싶은 문장들

1-1. 학습하기

• 현실세계에서는 협력적이고 비순차적이며, 자료에 한정이 없고, 명확한 평가나 정답이 없고 목표가 불분명하기까지한 야생학습이 훨씬 중요하다.

• 소프트웨어 개발에서 개발자를 채용할 때, 경력을 보고 뽑는 것은 관심사를 보고 뽑는 것과 크게 효과가 다르지 않았다. 경력은 초보와 초보가 아닌 사람만을 구분할 뿐이지, 그 이상의 차이를 증명할수는 없다. 즉, 0년차와 2년차 사이에서는 경력이 중요하지만, 2년차와 10년차 사이에서는 경력이 중요하지 않다.

• 1만시간의 법칙에서 가장 중요한 것은 단순히 1만 시간을 채우는 것이 아니다. 자신의 약점을 커버하기 위해 의도적으로 수련하는 시간을 의미하는 것이다.

• 학습에서 가장 중요한 것은 피드백과 피드백을 받는 주기이다. 애자일 학습법이 효과적일 수밖에 없는 이유이다.

• 자기계발은 복리로 돌아온다. 지금 편한 몸은 반드시 내년에 더딘 성장으로 돌아오고, 지금 열심히 노력하는 것은 반드시 내년에 큰 성장으로 돌아온다. 그리고 하루에 1-2시간씩 누적된 이 시간들은 눈덩이처럼 불어난다.

• 복리로 일하는 조직은 원래 하려고 했던 일을 하는 A단계에서 머물지 않는다. A단계를 개선시키고 효율을 극대화하기 위해 노력하는 B단계를 반드시 수행하며, B단계의 효율을 더 높이고 시스템화하려는 노력을 하는 C단계까지 노력을 기울인다.

• 성장의 진정한 의미는 우리 안에 무언가를 남겨두고 커진다는 것이다.

• 개인은 어떻게 하면 더하기보다 곱하기를 할 수 있을지, 어떻게 해야 곱하는 비율을 높일 수 있을지 혹은 이자 적용 주기를 짧게 할 수 있을지 고민해야한다.

  • 자신이 이미 가지고 있는 것들을 잘 활용하자. 새로운 것을 유입하는 것 대신 가지고 있는 것을 촘촘히 연결시키자.

  • 지금 하고 있는 행위는 추후에 나에게 도움이 될 수 있어야 한다.

  • 외부 물질을 체화하자. 지속적으로 새로운 유입을 받되, 그것을 자기 것으로 빨리 체화해야한다.

  • 자신을 개선하는 프로세스에 대해서 생각해보자. 주기적으로 회고하는 활동을 하자.

  • 피드백을 자주 받자. 사이클 타임을 줄여야한다. 일찍, 자주 실패하고 실패로부터 학습하자.

  • 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들자. 주어진 상황에서 최대의 효율을 만들 수 있도록 점진적으로 개선해야한다.

• 학습 프레임과 실행 프레임. 실행 프레임은 일을 잘하고 성과를 내는 것에 초점을 맞추고, 학습 프레임은 일의 성과와 상관없이 얼마나 배우느냐에 초점을 맞춘다. 역설적이게도 학습프레임의 결과가 훨씬 더 좋은 성과를 낸다.

• 입사한 지 1년도 안되었지만, 어떤 사람은 혼자서 책보고 코딩하며 공부하는데 몰두하고, 어떤 사람들은 선배들에게 자주 물어보고 피드백을 받으며, 스터디를 만들어서 타인을 도와주기도 한다. 소프트웨어 공학의 연구에 따르면 뛰어난 개발 전문가들은 사회 자본, 즉 인맥이 훌륭하다. 업무적으로 꼭 필요하지는 않지만 도움을 받는 사람과 내가 도움을 주는 사람에 대해 명확하게 말할 수 있는 사람은 곧 뛰어난 개발자이거나 그렇게 될 확률이 높은 것이다.

• 인공지능 시대에서 살아남는 것은 가장 학습하기 힘든 직업이다. 연구에 따르면, 현재 받고 있는 연봉이 낮을 수록 컴퓨터화하기가 어렵다고 한다. 연봉이 낮은 직업군은 주로 독창성, 사회적 민감성, 협상능력, 설득, 타인을 돕고 돌보기 등의 능력이 요구되는데, 이는 인공지능이 학습하기 어려운 능력들이기 때문이다.

• 소프트웨어 개발자와 컴퓨터 프로그래머를 비교해보자. 주어진 스펙대로 코딩만 하는 것이 컴퓨터 프로그래머라면, 요구사항을 정의하고 분석하며 그에 대한 솔루션까지 설계하는 것을 소프트웨어 개발자라고 해보자. 소프트웨어 개발자는 인공지능에 의해 대체되기 힘들지만, 컴퓨터 프로그래머는 그렇지 않다.

• 따라서 지금이라도 암묵지와 직관을 배우고 수련하는 방법을 학습하고 연습해야한다. 그리고 인공지능과 함께 일을 해나가야한다.

• 단순 반복으로는 달인이 될 수 없다. 달인이 되기 위해서는 실력을 개선하려는 동기가 있어야 하고, 구체적인 피드백을 적절한 시기에 받을 수 있어야 한다.

• 수십년을 일해도 전문가가 되지 않는 이유는 간단하다. 일을 하는 동안 타당성과 피드백이 결여되어있기 때문이다. 내가 제대로 일을 했는지 확인할 수 있고, 성과에 대해 적절히 피드백을 받을 수 있다면, 분명 성장할 수 밖에 없다.

• 소프트웨어 업계는 타당성과 피드백이 모두 낮은 편이다. 따라서 이를 의도적으로 높이려는 노력이 필요하다. 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력을 하고, 동료, 상사, 고객, 혹은 프로그램으로부터 주기적으로 피드백을 받으면 된다.

• 제자리 걸음에서 벗어나는 방법

  • 내 실력보다 쉬운 업무를 하는 경우

    • 실력을 낮춘다 : 모래주머니를 차고 달리기, 마우스 안쓰고 키보드로만 코딩하기 등 제약사항을 추가하여 실력을 낮추는 방법

    • 일의 난이도를 높인다 : 원래 주어진 범위 이상을 하거나 시간 제약이나 스펙 제약 사항을 추가하여 일하는 방법

  • 내 실력보다 어려운 업무를 하는 경우

    • 실력을 높인다 : 사회적 접근, 도구적 접근, 내재적 접근의 방법이 있다. 실력자를 찾아가 짝 프로그래밍을 하거나 내 일을 도와주는 도구적 사용을 하거나 비슷한 일을 했던 과거의 경험을 머릿속에서 되살려 보는 등을 의미한다.

    • 일의 난이도를 낮춘다 : 어려운 일을 작은 단위로 쪼개 결과 확인 및 피드백의 주기를 짧게 가져가는 것이다. 내가 익숙한 방식으로 먼저 해보면, 그 이후에는 더 어렵게 하기도 쉽다. 파이썬에 익숙하다면, 파이썬으로 먼저 짜보고 이후에 C언어로 짜는 것도 방법이 될 수 있다.

• 중요한 것은 나의 실력이나 작업의 난이도가 유동적이라는 것이다. 따라서 일을 진행하는 동안, 동적으로 균형점을 계속 찾으려고 노력해야한다. 알아차림 혹은 메타인지 전략이라고 한다.

• 팀장은 팀원들에게 적절한 난이도로 일을 주려는 노력이 필요하다.

• 전문가들은 자신들조차 어떻게 전문성을 획득하는지 잘 모른다. 전문가로부터 전문성을 효과적으로 끌어내려면 최대한 구체적인 사건을 떠올리도록 유도해야한다.

• 프로그래밍 언어를 빨리 배우는 법

  • 튜토리얼을 읽을 때 뭘 만들지 생각하며 읽는다. 이렇게 읽으면 어느정도 감을 잡으면 읽기를 중단하고 필요한 것을 만든다. 다 만든뒤 다시 와서 읽기 시작하는 것이다. 이렇게 목적성을 가지고 있는 읽기를 적극적 읽기라고 부르며 읽기에 대한 효과가 월등히 뛰어나다. S님은 주로 첫번째 프로그램으로 단어 개수 세기 프로그램을 만든다고 한다.

  • 공부할 때 표준 라이브러리의 소스코드를 찾아 읽는다. 튜토리얼만으로는 그 언어와 코드들의 말뭉치를 파악하기 어렵다. 그 언어의 스타일과 숙어를 적절하게 사용할 수 있으려면, 표준 라이브러리 소스코드를 직접 읽어봐야 한다.

  • 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다. SSH 클라이언트에서 지원되었으면 하고 바라던 특정 기능이 있었고, 자신이 공부하던 언어로 구현된 오픈소스 SSH 클라이언트를 찾아 다운받고 코드를 읽으며 기능을 추가했다고 한다.

• 실수는 예방하는 것이 아니라 관리하는 것이다. 실수를 예방하는 조직에서는 혁신이 일어나지 않는다. 성장하지도 않는다.

• 우리가 그렇게 공부해도 실력이 제자리인 이유

  • 뛰어난 선생에 대한 미신

    • 연구에 따르면 선생의 지식정도는 제자의 실력향상과 상관이 없다.

    • 선생은 자기가 가지고 있는 지식을 잘 전달하는 능력이 훨씬 중요하다. 보통 전문가는 가르칠 때, 자신이 과제를 수행하면서 하는 행위나 지식의 70%는 가르치지 않는다.

    • 학생의 경우는 전문가에게 배울 때, 그 전문가가 문제를 해결하고 새로운 내용을 학습한 인지적 과정을 물어볼 수 있다.

  • 나홀로 전문가에 대한 미신

    • 혼자서 일하는 전문가는 없다. 뛰어난 개발자의 70%는 동료와의 협력을 언급한다.

    • 결국 전문가가 되려면 사회적 자본과 기술이 모두 충족되어야 한다.

1-2. 협력하기

• 실제로 우리가 협력하는 방법은 작업을 세밀하게 나누고 각자의 역할을 부여하는 것이다. 그 과정에서 협력은 단 한번도 발생하지 않는다.

• 조엘테스트의 위험성

  • 소스컨트롤 사용 여부, 버그 데이터베이스, 스펙, 조용한 환경 등 12개의 항목에 예라고 답하면 좋은 개발팀이라고 판단하는 조엘 테스트는 위험성이 많다.

  • 첫번째는 단순히 12개의 항목에 ‘예’라고 답하는 것이 개발팀의 우수성을 보장하지 않기 떄문이다.

  • 두번째는 팀의 성공을 좌지우지하는 데에는 관리 > 시스템 > 사람 > 도구의 순서로 파급력이 크기 때문이다. 관리자는 자기 자신을 제일 먼저 바꾸어 관리를 효율적으로 할 수 있도록 해야한다. 그것이 가장 적은 비용으로 큰 효율을 만들 수 있는 방법이기 때문이다.

• 컴퓨터 프로그래밍은 결국 추상화다. 그런데 재미있는 점은 추상화는 다른사람들과 협력할 때, 더 잘 발생할 수 있다. 혼자서 개발할 때에는 다른 시각을 접할 기회가 없기 때문에 혼자만의 방식으로 작업을 하지만, 다른 사람들과 함께 작업을 할 때에는 서로 바라보는 시각이 다르기 때문에 추상화를 떠올리기가 쉬워진다.

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

• 디자이너들을 대상으로 한 실험이 있다. 공유에는 한 가지 시안에 대한 작업을 공유하는 하나공유, 3가지 시안 중 최고의 것을 공유하는 최고공유, 그리고 3가지 시안을 모두 공유하는 복수 공유의 방법이 있다고 한다. 재밌는 것은 하나공유나 최고공유의 경우, 작업물이 한가지이기 때문에 작업물에 대한 비판을 곧 나에 대한 비판으로 여겨 상처받거나 상대에 대한 신뢰감을 잃기 쉬운 반면, 복수공유의 경우는 여러가지 케이스를 다같이 놓고 고민하고 토론할 수 있어서 작업물과 나를 동일시 하지 않고, 작업물 자체에만 집중하여 일을 할 수 있다는 점이다. 이 경우, 동료에 대한 신뢰감도 향상되었고, 최종 작업 결과물도 훨씬 좋았을 뿐더러, 실제 데이터 상으로도 노출률이나 클릭률 등의 지표가 훨씬 향상되었다고 한다.

• 객관성의 주관성. 객관적이라는 것은 마치 투명하고 모두에 의해 납득되는 마법의 말 같지만, 사실은 이 객관성 조차도 매우 주관적이다. 따라서 어떤 사람을 객관적 데이터를 근거로 설득한다는 것은 말이 될 수 없다. 결국 결정은 사람이 하기 때문이다. 객관성을 논하기 전에, 우리는 사람에 대한 이해에 가장 많은 시간을 들여야 한다.

• “이것도 모르세요?”와 같은 태도로 서로를 대하는 팀은 결코 성장할 수 없다. 사수는 코칭을 통해 상호 대화가 자연스럽게 오고가는 환경을 조성해야하고, 실제로 무엇을 해야할지 알려주기보다는 피코치가 스스로 약속하게끔 해야한다. 이 경우, 피코치는 제대로 행동할 확률이 90%이상 된다.

• 뛰어난 전문가들은 자신들이 잘 알고있는 것은 탑다운 방식으로 접근하되, 잘 모르는 새로운 개념은 탑다운과 바텀업 방식을 섞어서 사용한다고 한다. 즉, 전문가들은 상황에 맞게 전략을 변경하며 적용할 줄 아는 사람들이라는 것이다. 하지만 조직의 경우, 스스로를 전문가 집단으로 인식하여 탑다운 방식만 고수하려고 하는데, 이 때문에 올바른 문제해결이 불가하거나 비효율이 발생하는 경우가 많다.

• 흔히 일을 잘한다고 하는 조직의 경우, 삼투압적 의사소통을 한다. 이는 자연스럽게 스며드는 방식으로 의사소통을 하는 것인데, 물리적으로 가까운 위치에 서로 존재하며, 상호간의 대화에 자연스럽게 노출되어 서로가 서로에게 부가정보를 잘 전달할 수 있는 구조를 가진다는 것이다. 또한 의사소통의 주기를 짧게 가져가는데, 이를 위해 일을 처리하는 배치 사이즈를 작게 가져간다. 50개의 일을 한번에 처리하고 소통하는 것이 아니라, 30개, 10개, 1개의 일을 처리하고 의사소통하는 방식으로 일을 진행한다는 것이다.

  • 자연스러운 노출 + 짧은 의사소통 주기 + 작은 일의 단위

• 전문가들만 모여있는 집단이 반드시 성공하지는 않는다. 오히려 서로 협력하지 않는 전문가 집단은 일반적인 비전문가 집단보다 훨씬 더 최악의 결과를 만들어낸다. 전문가 집단이 성공하기 위해서는 서로 정보를 공유하고 협력을 잘 하기 위한 명시적인 도움이 필요하며, 이러한 도움은 팀 내에 있는 소셜스킬이 뛰어난 제네럴리스트를 통해 받을 수 있다.

• 구글에서 좋은 관리자와 뛰어난 팀을 찾는 아리스토텔레스 실험을 진행한 결과, 세 가지 점이 주목할만하다.

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

  • 5가지 뛰어난 팀의 특징 중, 가장 높은 상관성을 보인 것은 심리적 안정감이다.

  • 심리적 안정감은 팀 토론 등 훈련을 통해 충분히 개선될 수 있다.

• 즉, 실수에 대해 두려움이 적고, 팀 내에서 토론이 활발하게 이루어질 수 있는 분위기에서는 팀원들이 심리적 안정감을 더 많이 느끼고, 그에 따라 성과로 높아진다는 것이다.

• 쾌속학습팀의 특징은 다음과 같다.

  • 새로운 기술로의 전환을 기술적 문제가 아니라 조직적 문제로 바라보고 팀 전체가 어떻게 학습하고 적용할 것인지를 고민한다.

  • 리더는 학습을 개인에게 부담지우는 것이 아니라 팀 전체의 것으로 가져왔고, 학습으로 인해 변화할 긍정적인 모습에 집중하도록 팀을 격려했다.

  • 학습이 빠른 팀은 심리적 안정감이 높았다. 자신의 의견을 적극적으로 개진하며 그것에 대한 심리적인 부담이 없었다.

• 프로젝트 확률론에 따르면 대부분의 개발자가 개발 완료 일정을 추산할 때, 그 정확도가 현저히 낮다고 한다. 보통 사람의 경우, 추정치의 2-3배는 산정해야 80%의 확률로 끝낼 수 있다고 한다. 이때 애자일한 팀의 경우는 이러한 직관의 문제점을 아래와 같이 해결한다.

  • 팀이 함께 작업하기에 팀 내에서 한 명만 아하 모먼트를 겪어도 팀 전체가 그것을 공유할 수 있도록 한다. 좋은 일을 OR 확률로 만드는 것이다.

  • 버그와 같이 나쁜 일들에 대해서는 팀원 모두가 실수를 해야 발생할 수 있도록 짝프로그래밍, 코드공유, 코드 리뷰, 퀵 디자인 세션 등과 같은 중복 검토를 통해 AND 확률로 만든다.

1-3. 애자일

• 좁은 의미로 보자면, 애자일은 소프트웨어를 개발하는 한 가지 스타일을 말한다. 1990년대에 전통적인 소프트웨어 개발 방법론에 회의를 가진 사람들이 각자 자기만의 방법으로 개발을 하기 시작했는데, 2001년에 이들 간의 유사성을 모아 공통된 철학, 추구하는 가치, 원칙을 추려내어 애자일 선언문을 발표한 것으로부터 유래되었다.

• 넓은 의미로 보자면, 애자일은 협력과 학습, 즉 함께 자라기이다. 소프트웨어 개발 뿐만 아니라 삶을 살아가는데에도 불확실성을 효과적으로 다루게 해주는 좋은 전략이 된다.

• 애자일의 핵심은 “고객에게 매일 가치를 전하는 것”이다.

• 애자일 도입의 성공 요인을 분석한 결과, 애자일 초보 조직일수록 고객이 개발 과정에 참여할 수 있도록 하는 것이 가장 중요한 요소였고, 애자일 전문가 조직일수록 짧은 개발주기, 고객참여, 코드 공유 등이 성공의 핵심 요소가 되었다.

• 결국 고객참여는 가장 중요한 요소임에도 많은 조직에서 미루고 있다. 그 이유는 사람에 관한 일이기 때문이다. 고객을 설득해야하고 같이 일하는 동료를 설득해야한다. 때문에 많은 조직에서 이 일을 가장 후순위로 미루고는 작은 요소부터 적용하기 시작하는데, 이렇게 미루다가는 끝도 없다. 가장 무섭고 중요한 일일수록 피하지말고 맞서라.

• 애자일 도입시 가장 중요한 것은 그것을 이끄는 리더이다. 단순한 방법론을 도입하는 것으로는 애자일 문화가 자리잡기 힘들다. 그보다는 누가 참여하는가가 훨씬 더 압도적으로 중요하다.

• 뛰어난 능력을 가진 슈퍼슈링크들을 찾고 그들을 연구하고 육성해야한다.

• 애자일을 반 애자일적으로 진행하는 것이 가장 큰 폐단이다. 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제가 된다. 애자일을 도입할 때, 뭘 해야할 지 명확하게 알려달라는 것은 모순이다. 각자 자기 조직의 모습에 맞게 방법론 적용하고 수정해가며 찾아가는 것이다.

2. 느낀점

• 사람들이 그렇게 추천하고 읽으라고 애원할 때는 청개구리처럼 더 보기 싫은 것 같다. 그러다가 시간이 많이 남아돌 때, 빌린 책인데, 오늘 하루만에 다 읽었고 읽기 너무 잘했다는 생각이 든다.

• 문장 하나하나에 인사이트가 가득하다. 늘 뭔가를 시작할 때, 처음부터 끝까지 혼자 하려는 경향이 있고 같이 하면 더 효율이 떨어진다는 마음 속 깊은 곳의 의심이 있었는데, 역시 뭐든 오래하고 꾸준히하고 잘하려면 사람들과 함께하는 것이 좋은 것 같다.

• 마침 개발 (이직) 스터디를 시작하게 되었다. 이 기회에 사람들과 함께 성장하는 방법에 대해 공부하고 실천해야겠다. 잘 연구해보자…!