혼자서 프로그래밍 공부를 시작하면서, 막막한 마음에 학습방법론 책들을 찾아 읽은 적이 있습니다. 그 중에 아래과 같은 책 3권이 기억에 남습니다.

• IT에 몸담은 이들을 위한 지적 생산 기술
• 코딩을 지탱하는 기술
• 함께 자라기

아래 내용은 나중에 기억하기 위해 책을 읽으며 간단히 요약했던 메모들의 모음입니다. 자세한 내용은 직접 해당 책을 읽어보시면서 확인하실 것을 추천드립니다.

IT에 몸담은 이들을 위한 지적 생산 기술

1. 새로운 것을 배우려면

학습 사이클

• 추상화/모델화/패턴 발견

• 정보수집

  • 수평으로 뻗어가는 모습
  • 정보수집은 옆으로만 늘어날 뿐 쌓여 올라가지는 않는다.

• 모델화 및 추상화

  • 모델화 및 추상화는 상자를 쌓아 올리는 것과 같다.

  • ‘추상적’이란 말은 높은 곳에 위치한 것이고,

    • ‘구체적’이란 말은 낮은 곳에 위차한 것을 뜻한다.
  • 수집한 정보를 관찰해서 새로운 정보를 만들 수 있고, 이러한 추상적인 지식을 만드는 것이 ‘모델화’다.

학습 사이클을 돌리는 원동력 : 의욕

• 대학 이전과 이후의 학습 방법 차이

  • 대학 이후 : 능동적 학습법

    • 선생님이 가르치는 것이 아니라 스스로 배운다는 자세가 요구된다.

• 의욕을 유지하려면

  • 의욕은 행동과 보상의 사이클에 의해 유지된다. 행동에 대한 보상을 신속하게 하는 것이 핵심이다.
  • 의욕을 유지하려면 목료를 명확하게 정해야 한다.
  • 듀토리얼은 목표를 가깝게 만든다.

• 종이 참고 서적을 선택하는 방법

  • 여러 대학에서 강의의 참고 도서로 선정된 것을 고른다
  • 정오표가 상세히 기술돼 있을 것(출판사의 웹사이트)
  • 개정판이 있는 스테디셀러일 것

정보 수집의 세 가지 방법

• 구체 : 정보 수집 체험

  • 알고 싶은 것부터

  • 소스코드 읽는 법

    • 전체를 읽으려 하지 않는다. 코드에는 스토리가 없으므로 전체를 읽을 필요 없다. 재밌어 보이는 부분을 정독해서 다른 사람의 코드 작성 기술을 배우면 충분하다.
    • 무언가를 배우려는 목적을 가지고 읽는다.

알고 싶은 것부터 배우기 위한 전제 조건

• 목표가 명확할 것

  • ex) ‘파이썬의 리스트와 튜플의 차이점 알기’(X)
  • ex) ‘파이썬의 리스트와 튜플의 차이에 대해 검색해서 읽기’(O)
• 목표가 달성 가능한가?
• 대략적인 전체 모습 파악하기

대충 보기

• 대략적인 전체 모습을 파악하기(전체를 대충 보라)

  • 그렇게 하면 무언가 필요한 것을 찾을 때 ‘분명 이쯤에 있었지’라며 찾는 범위를 줄일 수 있다.

• 1,000페이지 이상의 자료도 목차는 단 6페이지

  • 먼저 목차부터 읽자. 그러면 대충이긴 하지만 전체 모습을 파악하라 수 있다.

• 코드를 단계적으로 읽기

  • 갑자기 함수 내용을 자세히 보는 것이 아니라 다음과 같이 단계적으로 상세화하여 읽기 1. 내부 구조를 해설한 문서가 있으면 읽기 2. 디렉터리 구조 읽기 3. 파일 구성 읽기 4. 약어 구성하기 5. 데이터 구조 파악하기 6. 함수 간 호출 관계 파악하기 7. 함수 읽기
• 문서의 대략적인 구조

처음부터 찾기

• 대략적인 전체 구조를 파악할 수 없는 상태는 해당 정보를 이해할 수 있을 만한 재료가 부족하다. 윤곽을 그리기 위한 지식 자체가 부족한 것이다.
• 이러할 때는 거기서 멈춰 있지 말고 먼저 재료를 손에 넣어야 한다.

• 필사라는 기술

  • 새로운 프로그래밍 언어를 배울 때 ‘필사’(베껴 쓰기)라는 기법이 도움이 된다.

    • 교과서 등에 있는 코드를 직접 키보드로 입력해서 실행하는 것이다. 효율을 매우 나쁘지만, 아무런 지식이 없는 초보자가 첫걸음을 내딛기 위한 방법으로 유용하다.
  • 입력하면서 유사점, 차이점을 발견하면서 머릿속에서 모델화가 진행된다.
  • 또한, 의문 등 생각한 것은 주석이나 메모로 남겨 두면 좋다.

• 시간을 세분화하자

  • 예를 들어, ‘지금부터 25분 동안 할 수 있는 곳까지 필사하자’와 같은 목표를 설정한다.

• 필사는 보조 바퀴

  • 필사는 수단이지 목표가 아니다. 필사가 필요없다고 느낀 시점에 필사를 중단해도 좋다.

• 다시 필사가 필요해질 때

  • 필사를 하지 않고 언어를 배우려면 조건이 있다. 즉 지금까지 배운 언어와 공통요소가 많은 언어여야 한다는 것이다.

추상이란 무엇인가?

• 수집한 정보가 추상화돼서 모델이 된다.
• 추상화, 모델화, 패턴 발견

• 추상

  • 구체적인 대상으로부터 주목해야 할 중요한 부분만 추출하는 것이다.

• 모델, 모형

  • 모델은 현실 세계의 구조를 설명하기 위해 간략하게 표현한 것이다.

• 모듈

  • 소프트웨어 코드는 어디에 있든 멀리 떨어져 있는 코드에 영향을 줄 수 있다. 사람의 이해 능력에는 한계가 있으므로, 방대한 소스 코드 전체를 기억할 수 없다. 지금 하는 작업 중에서 중요한 부분에만 주목하고 나머지는 무시하는 경향이 있다.
  • 코드의 상호 작용으로 문제가 나타날 수 있다.

  • 상호 작용 제한하기

    • 이런 코드 간의 상호 작용을 제한하기 위해 만들어진 것이 모듈 개념이다.

      • 모듈 : ‘관련성이 강한 코드를 그룹으로 모은 것’
      • 모듈 안에 있는 구성 요소는 명시적으로 ‘export’하지 않으면 모듈 밖에서 참조할 수 없으며, 또한 모듈 밖의 구성 요소는 명시적으로 ‘import’하지 않으면 모듈 안을 참조할 수 없는 구조였다.
      • 즉, 프로그래밍 언어의 모듈은 내용의 일부만 공개하고 나머지를 숨기는 구조이다.

    • 중요하지 않은 부분을 숨긴다 = 중요한 부분을 추출한다.

      • 프로그래밍에서 모듈의 용도는 추상화(모델화)다.

추상화가 필요한 이유?

• 패턴 발견에 의한 일반화

  • 추상화는 패턴 발견에 의해 이루어진다.

추상화는 어떻게?

• 비교를 통해 배우기

  • 같은 것과 다른 것 사이에 주목

    • 새로운 것을 발견하기 위해서는 ‘같지도’, ‘다르지도’ 않은 일부가 동일하고 일부가 다른 ‘비슷한 것’을 서로 비교해야 한다.

• 비유

  • 비유는 추상적인 것을 전달하 할 때 사용한다. 어디가 같고, 어디가 다른지를 명확하게 파악하는 것이 중요하다.
• 다른 것에 주목
• 역사를 통해 배우기

• 패턴 책을 통해 배우기

  • 패턴 책은 구체적인 경험으로부터 스스로 패턴을 발견할 수 있게 도와줄 수 있지만, 구체적인 경험이 없는 상태에서 패턴만 습득할 수 없다.

검증

• 머릿속 모델을 사용해서 실행하고 그 결과를 검증하기

• 만들어서 검증

  • 해설도 만드는 것의 일종

    • 블로그
    • 배운 것을 다른 사람에게 이야기
• 시험을 통한 검증

2. 동기부여를 하려면

• 의욕이 없는 사람의 65%는 태스크를 하나로 추리지 못한다.

  • 여러 태스크를 하려고 해서 의욕이 생기지 않거나 머리가 복잡해진다면 일단 하고자 하는 것을 하나로 추려서 차례로 정리해 가면 된다.
• 추려내기 위해서 먼저 전체 모습을 파악하자

• Getting Things Done: 먼저 모두 정리한다.

  • GTD기법(데이비드 앨런의 저서 ‘쏟아지는 일 완벽하게 해내는 법’)에서는 ‘신경 쓰이는 것’을 전부 한 곳에 정리한다.

    • 기억할 수 있는 것 이상을 기억하려고 하면 그 부담이 스트레스가 돼서 인지 능력이 저하된다. 그래서 먼저 ‘해야 할 것을 모두 여기에 정리한다’는 상황을 만들면 ‘해야 할 것을 기억하지 않으면 안 된다’는 부담으로부터 자유로워질 수 있다.
    • 정리하는 단계에서는 내용을 확인하지 않고 정리할 위치(Inbox)에 넣기만 하면 해당 작업이 끝나는 것이다.

• 전부 모아서 나중에 처리하기

  • GTD에서는 수집 단계와 처리 단계를 명확하게 나누는 것이 중요하다. 정리하면서 생각하는 것이 아니라 일단 다 정리한 후에 전체 모습을 파악하는 것이다.
• 어떻게 하나의 태스크를 선택할 것인가?

• 방 정리와 비슷하다

  • ‘일단 정리한 후에 버려라’

하나의 태스크를 위한 동기부여

• 타임박싱

  • 아주 큰 태스크를 작은 단위로 나누는 쉬운 방법은 ‘시간으로 나누는 것’이다.
  • 태스크에 맞추어 시간을 정하는 것이 아니라, ‘정해진 크기(시간)의 상자에 태스크를 넣는다’고 생각하는 것으로 타임박싱이라고 한다.

• 뽀모도로 기법

  • 25분을 1뽀모도로라고 부른다.
  • 기법 정리 1. 오늘 1일분의 태스크를 만든다. 2. 태스크의 크기를 뽀모도로 개수로 게산한다. 3. 1뽀모도로 동안에는 태스크를 변경하지 않고 하나에 집중한다 4. 만약 자신 또는 타인에 의한 간섭이 발생한다면 그것을 기록한다 5. 1뽀모도로에서 집중 상태가 계속된다면, 서서 몇 발자국 걸어 보는 등 기분 전환을 한다.

• 예상 시간 측정 능력 단련하기

  • 1일에 8뽀도로가 현실적인 한계다.

3. 기억력 단련하기

4. 효율적으로 읽으려면

• 안다는 것의 정의

  • 알기 위해서는 ‘왜 그런지’라는 질문에 답할 수 있어야 한다.
  • 아무것도 보지 않고 자신만의 언어로 설명할 수 있는 상태를 ‘안다’고 정의하고 있다.
  • 시간 낭비를 하지 않기 위해 책을 제대로 선택하는 것이 매우 중요하다.

• 독서는 수단, 목적은 따로 있다.

  • 진짜 목적

    • 대략적인 지도의 입수

      • 필요할 때 다시 읽는 것을 목적으로 삼는 사람도 있다.

    • 결합하기

      • 한 권의 책에서만 정보를 찾는 것이 아니라 해당 책의 내용과 다른 지식을 결합해서 새로운 가치를 만드는 경우도 있다.

복습을 위한 교재 만들기

• 독서의 목적 중 가장 추천되는 것은 복습을 위한 교재를 만드는 것을 목적으로 하는 것이다.

  • 한 번 읽고 다시 읽지 않은 책의 내용은 거의 남아 있지 않는다.
  • 기억을 정착시키려면 간격을 늘려서 복습하는 것이 중요하다.

코딩을 지탱하는 기술

방대한 정보 앞에서 좌절할 때 방법. 이빨로 씹다

1. 필요한 부분부터 흡수한다

• 책이나 자료 전체가 동일한 정도로 중요하다고 말할 수 없다. 목적이 명확하고, 목적 달성을 위해서 어디를 읽어야 할지 알고 있다면 다른 페이지는 신경 쓰지 말고 바로 그곳을 읽도록 한다.
• 전체 모두 읽지 않은 것이 께름칙한가? 하지만 좌절하고 전혀 읽지 않는 것보다는 낫다. ‘전부 읽지 않으면’이라는 완벽주의가 배우고자하는 동기를 짓누르고 있다면, 버려버리는 것이 낫다. 동기는 매우 중요하다.
• 이 전략을 사용하기 위해서는 읽고 싶은 부분이 어디인지 대략적으로 전체적인 구조를 파악하고 있어야 한다.

2. 대략적인 부분을 잡아서 조금씩 상세화한다

• 책이나 문서에는 목차가 있다. 목차를 보면 전체 구조를 대략적으로 알 수 있다. 그리고 나서 본문을 속독으로 읽어나간다. 자세히 보지 않고 우선은 소제목이나 강조 부분, 그림과 그림 제목 등을 본다.
• 소스코드를 읽을 때는 우선 디렉터리 구조나 파일명을 본다. 그리고 파일을 속독으로 읽고 거기서 정의하고 있는 함수나 클래스 이름, 자주 호출되는 함수명을 본다.
• 이 방법들에는 ‘우선 대략적인 구조를 잡고, 조금씩 상세한 정보로 접근한다’는 공통점이 있다. 이것이 기본 원칙이다.

3. 끝에서부터 차례대로 베껴간다

• 명확히 ‘하고 싶은 것’, ‘조사하고 싶은 것’ 이 없이 ‘대충 읽으면’ 읽은 내용이 뇌를 그냥 스쳐 지나갈 뿐이다. 이런 상태에서 어떻게 배울까를 고민한다고 해도, 판단을 위한 지식 자체가 없기 때문에 무의미하다.
• 그래서 지식의 밑바탕을 만들기 위해서 교과서를 그대로 베껴 쓴다. 이것이 ‘베끼기’라 불리는 기술이다. 지식이 없는 상태에서 고민하는 것은 무익하기 때문에 우선 아무것도 생각하지 않고 지식을 복사하는 것이다.
• 이 이상의 방법은 없다. 저자는 시간을 정해서 ‘25분간 어디까지 베낄 수 있는지’ 도전하는 것을 좋아한다. 분량으로 나누는 것도 좋은 방법이다. 중요한 것은 간격을 적절히 해서 목표를 이루었다는 만족감을 얻을 수 있도록 하는 것이다.

---

함께 자라기

1. 자라기

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

  • 상관성 : 0.5를 넘기면 강한 효과가 있고, 0.2~0.5 사이는 중간 정도, 0.2 이하는 약한 효과라고 한다.

  • 직무성과와

    • 경력 연차의 상관성 : 0.18
    • 학력의 상관성 : 0.10
    • 관심사 상관성 : 0.10
    • 작업 샘플 테스트(실제로 채용 후 해야 할 작업의 일부를 해보는 테스트) : 0.54
    • 아이큐 같은 지능 테스트 : 0.51
    • 구조화된 인터뷰(모든 후보에게 직무 분석을 토대로 한 같은 순서의 동일 질문을 하는 인터뷰) : 0.51
    • 성실성이나 꼼꼼함 같은 성격 테스트 : 0.41, 0.31
    • 레퍼런스 체크(예전 직장의 상사 등에게 확인) : 0.26
    • 필체 : 0.02
    • 나이 : -0.01
  • 대학교를 갓 졸업한 사람과 2년 차 프로그래머 중에서 후자의 실력이 높을 확률이 크다. 하지만 5년 차와 10년 차의 연차 차이는 실력을 판단하는 데 있어 큰 의미가 없다.

• 경력의 양적인 면이 아니라 질적인 면의 중요성

  • 경력이란 경력 연차를 말하는 게 아니라, 개발자의 경험이 얼마나 폭넓고 다야했느지가 실제 직무성과와 관련이 있다.

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

  • 경력은 오히려 경계해야할 대상 중 하나이다.
  • 대안은 ,구조화된 인터뷰와, 실제 작업을 해보도록 하느 작업 샘플 테스트, 그리고 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것(시험 외주) 등이다.

• 잘 뽑는 것 이상으로 주요한 것

  • 전문성 관리

• 개발자들이 할 수 있는 것

  • 1만 시간 법칙을 만든 주인공, 안데쉬 에릭손은 1만 시간은 ‘자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련’을 한 시간이라고 말한다. 그런 수련은 의도적 수련(deliberate practice)이며, 그냥 경험이 아니고 매우 특수한 형태의 수련 방법이다.

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

  • 애자일 프로젝트에서는

    • 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후, 일주일후 등 여러 주기를 통해 지속적으로 얻을 수 있다. 그리고 그때 저지른 실수는 바로 다음 주기에서 교정할 수 있다.

      • 학습에서는 피드백이 중요하다.

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

• 자기가 습득한 지식이나 능력은 복리로 이자가 붙는다. 예를 들어, 하루에 1%씩 이자를 복리로 받는다고 하면 원금의 두 배가 될 때까지 며 칠 걸릴까?70일이면 된다. 1년이면 약 38배가 된다.

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

• 복리의 비밀

  • A,B,C 작업: A작업은 원래 해야 할 일, B작업은 A작업을 개선하느 일, C작업은 B작업을 개선하는 일
  • A작업을 개선하려면 다음 두 가지 질문 1. 어떻게 하면 더하기보다 곱하기를 할 수 있을 것인가 2. 어떻게 해야 곱하는 비율(이자율)을 높일 수 있는가 혹은 이자 적용 주기(예컨대 1년에 한 번 대신에 1달에 한 번)를 짧게 할 수 있느가

  • 방법

    • 자신이 이미 갖고 있는 것들을 잘 활용하라
    • 외부 물질을 체화하라
    • 자신을 개선하는 프로세스에 대해 생각해 보라
    • 피드백을 자주 받아라

    • 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라

      • 완벽한 도구와 환겨을 갖추는 데에 집착해서는 안 된다. 그런 식으로는 무엇도 영원히 얻을 수 없다. “방이 조요해지고 배도 안 고프고 온도도 적절해지기만 하면 공부 시작해야지”라고 생각하는 사람들 중에 1등은 없다. 또한 실제로 그런 환경이 되어도 몸에 배어든 습관 때문에 결국은 공부하지 못할 것이다.

학습 프레임과 실행 프레임

• 실행 프레임은 ‘잘하기’에 초점을 맞추고, 학습 프레임은 ‘자라기’에 초점을 맞추게 한다.

  • 실행 프레임 : “여러분이 얼마나 그림을 잘 그리는 지 보고자 합니다. 점수를 매길 겁니다. 각자 그림을 하나씩 그려서 내야 합니다.”

    • 쉬는 시간에, 실행프레임의 아이들은 논다고 정신이 없다.
    • 실행 프레임은 사람들이 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀을 말한다.

  • 학습 프레임 : “내가 안 그려 보았던 방식들을 실험해 보는 시간이에요. 여러 가지 방식으로 실험해 보세요”

    • 쉬는 시간에도 계속 그림을 그리는 아이들이 많다.
    • 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀을 말한다.
• 학습 정도도 학습 프레임의 아이들이 훨씬 더 많이 학습한다.

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

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

• 컴퓨터 프로그래머는 스펙대로 코드를 만드는 사람으로 설정했고, 반대로 소프트웨어 개발자는 사용자의 요구사하을 분석하고 그에 대한 솔루션을 설계하는 것까지 포함하는 것으로 보았다.
• 소프트웨어 개발자는 702개의 직업 중 컴퓨터화될 확률이 낮은 직업 130등(4.2%)으로 컴퓨터화가 어려운 편에 속한다. 그런데 컴퓨터 프로그래머는 293등이고, 확류은 48%로 컴퓨터화 확률이 꽤 높은 편이며, 이 연구의 분류상 ‘중위험군’에 속한다.
• 혼자서 딱 정해진 일만 할 수 있는 환경이 축복이 아니라 저주가 될 수도 있다.
• 미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가진다.

달인이 되는 비결

• 꾸준한 반복으로 달인이 되려면,

  • 시력을 개선하려는 동기가 있어야 하고
  • 구체적인 피드백을 적절한 시기에 받아야 한다.
• 특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스는 경험을 오래한다고 해서 자동으로 얻을 수 있는 것이 아니다.

• 타당성과 피드백을 높이기

  • 타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력을 하면 된다.
  • 피드백을 높이려면 동료나 상사, 고객에게서, 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하면 된다.

당신이 제자리걸음인 이유

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

  • 난이도와 실력이 엇비슷하게 맞는 부분에서, 인간은 몰입을 경험한다. 그리고 퍼포먼스나 학습 능력이 최대치가 될 수 있고, 최고 수준의 행복감을 경험한다.
  • 자신의 실력보다 낮은 난이도의 작업을 하게 된다면, 지루함을 느끼게 되고, 높은 난이도의 일을 하게 되면 불안함이나 두려움을 느낀다.

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

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

  • 읽을 때 다음 작성할 프로그램을 염두에 두며, 읽다가도 이 정도면 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 읽기를 멈추고 코딩을 시작한다. 완성하면 잠시 멈췄던 자리로 돌아와서 읽기를 계속한다. 이때에는 다음 프로그램을 목표로 두면서 말이다. (적극적 읽기)

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

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

  • 좋은 코드를 읽어봐야 좋은 코드를 쓸 수 있다. 표준 라이브러리는 가장 그 언어다운 코드들의 말뭉치이다. 이런 실제 사례들을 통해 해당 언어의 문화와 스타일을 익히는 것이 주요하다.
• 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다.

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

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

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

• 보통 교육에서는 학생들이 실수를 최소화할 수 있도록 설계한다. 하지만 교육 중에 실수를 더 유도해야 오히려 학습전이가 더 잘 일어난다. 다양한 실수를 경험하는 걸 격려하고, 실수 사례를 배우고, 실수 시에 어떻게 대처하는가를 가르치는 교육이 더 효과적이다.

2. 함께

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

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

협력을 통한 추상화

• 커뮤니케이션과 협력
• 소프트웨어 공학의 역사는 추상화를 높이기 위한 과정이었다.
• 추상화를 높이는 방법은 바로 ‘다른 시각을 가진 두 사람이 협력하기’이다.

• 대화하는 프로그래밍

  • 짝 프로그래밍은 두 사람이 한 컴퓨터를 사용해 함께 프로그래밍하는 것이다. 두 사람이라는 구서은 대화를 통해 추상화를 높이게 한다. 한 컴퓨터라는 구서은 구체화를 통해 검증하게 한다. 미루고 헤어라리느 것이 번번히 교차하다가, 그 사이에서 ‘아하’가 터져 나온다.
  • 자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하세요. 같이 그림도 그려보고 함께 소스코드를 편집하세요.

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

• 복수 공유의 장점

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

    • 신뢰가 유의미하게 증가하였다. 성과가 더 좋아졌다.

객관성의 주관성

• 품질은 상대적이다.

  • “품질이란 누군가에게 가치가 되는 것이다.”
  • 고품질을 얻으려고 노력하는 살마들은 `‘인간’에 대한 이해 가 필수적이다

• 설득을 하기 위해서는 객관성이 필요하다.

  • 그러나 이 객관성의 개념 자체가 매우 주관적이다.

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

    • 마음에 안 들면 어떤 ‘객관적’ 자료를 갖다 줘도 설득할 수 없다.
    • 특히나 그 자료에 “당신의 생각이 틀렸다”라는 암시가 강하게 있다면 더더욱 설득하기 어렵다.

• 감정을 배제할 수 없다.

  • “상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?”

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

  • KAI(Kirton Adaption Innovation) 인지 성향에 대한 이론

    • KAI에서는 적응형과 혁신형이라는 극단 사이의 스펙트럼 위에 있는 것으로 본다.

      • 적응형은 잘하는 것이 중요하고, 혁신형은 다르게 하는 것이 중요한 사람들이다.

  • MBTI 성격 유형 4가지 기질(Keirsey Temperament Sorter)

    • NT : 이성적 판단을 하고 큰 그림을 그린다
    • NF : 사람들과의 관계에 관심이 많다.
    • SJ : 구체적이며 체계적이다
    • SP : 모험을 좋아하고 닥친 문제를 푸는 것을 즐긴다.
  • 결론은 객관성이라고 하는 것은 상대적이며, 내가생각하는 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다.

이것도 모르세요? ←NO

• 공감하고 이해하려는 대화

  • 공감하면서 들어주려고 하고, 상대가 어떤 멘탈 모델을 갖고 있는지 파악하려는 것이 중요하다.

하향식 접근의 함정

• Pennington의 ‘프로그래밍에서의 이해 전략’이라는 연구에 따르면,

  • 프로그램을 이해할 때

    • 고수는 상호 참조전략(cross-referencing strategy)을 쓰는 반면, 하수는 그렇지 않다.

      • 고수는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로 번역한다. 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증한다. 이것이 상호 참조 전략이다. 추상과 구상의 차원을 자주 오가는 것이다.

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

  • 삼투압적 의사소통

    • 이것은 ‘배어드는’ 소통방식이다. 은연중에 서로 간에 정보가 스며든다.

      • 그러려면 사람들이 물리적으로 가까운 거리에 있어야 유리하다.
      • 한번에 처리되는 일의 양(batch size)을 줄여야 한다.
      • 배치 사이즈를 줄여서 지속적 흐름을 만들고 짧은 시간 내에 탑, 바텀을 오가게 한다.

전문가팀이 실패하는 이유

• Groysberg 등의 연구에 따르면, “이런 스타들이 한 명씩 팀에 추가될 때마다 팀의 추가적 성과 향상은 한계효용을 보이며 어느 수준을 지나면 음의 방향으로 작용한다”고 한다.

  • 협력 계획하기라는 개입을 받지 못하고 전문가들이 포함된 팀은 다른 팀보다 더 못한 성과를 보였다. 이것은 멤버들이 전문가의 특별한 재능을 사용하도록 도움을 받지 않는다면 전문가 멤버들의 존재가 사실은 팀의 효과서을 떨어뜨릴 수 있다는, 기대를 거스르는 가능성을 제시한다.
• 분더슨 등의 연구에서는 팀 내에 개인 내 다양성이 높은 멤버가 없다면 전문가로 구성된 팀은 정보 공유가 잘 안 되어서 성과가 떨어질 수 있다는 분석을 했다. 여기에서 개인 내 다양성이 높다는 것은 다양한 분야를 경험한 제너럴리스트 같은 사람을 뜻한다.

• 정리

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

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

1. 팀에 누가 있는지보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
2. 5가지 성공적 팀의 특지을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다.
3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
4. 여기서 말하는 심리적 안전감이란, 내 생가이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말한다.

쾌속 학습팀

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

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

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

• 학습 환경의 차이

  • 학습속도가 빠른 팀은 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다. 학습을 팀에 중대한 목표로 받아들인다.리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.
  • 반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했다. 학습보다는 단기 퍼포먼스를 중요시했다.

• 현실에서 실천하기

  • 개인으로서, 우선 자신의 학습 환경을 만든다.학습과 일을 굳이 분리하지 말고 동체로 만든다.
  • 지금 당장 실행한다.
  • 학습 공동체를 구축한다.

프로젝트 확률론

• 애자일은 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다. 애자일에서는 되도록 사람들이 섞이도록 한다.

  • 고전적 방버에서느 내가 일을 빨리 끝내는 것이 이 프로젝트에 큰 도우미 되지 않는다. 내 일은 내 것이고 다른 사람 일은 다른 사람 일이기 때문이다. 그래서 마감 시간에 맞춰 끝나도록 일부러 일을 늘리는 경향도 생긴다. 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와준다.
  • 애자일에서느 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다. 그 좋은 정보는 각자의 일에 모두 도움이 된다.

3. 애자일

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

  • 애자일이 불확실성을 다루는 방식은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있다. 이런 특징을 가진 애자일 방법론은, 마침 시대가 바뀌면서 불확실성이 낮은 프로젝트는 비즈니스적 가치가 없어지고 불확실서이 높은 프로젝트를 하는 것이 일반적이 됨에 따라 빠른 속도로 인기를 얻게 됐다.

• 삶에 애자일을 적용

  • 학습과 협력

  • 학습

    • 불확실하다는 것은 우리가 이동을 할 때 목표점의 위치가 자주 바뀌거나 우리 위치가 자주 바뀌거나 하는 상황으로 비유해 볼 수 있다. 그럴 경우일수록 우리는 가다가 멈춰 서서 주위를 둘러보고 목표점과 우리 위치를 확인하는 것 같은 피드백을 통해 방향을 재조정하는 일을 자주 해야 한다. 초기 계획대로 가면 완전히 동떨어진 곳으로 갈 수 있기 때문이다. 다시 말해 이동하면서 계속 배워나가야 한다.

  • 협력

    • 애자일은 서로의 업무를 공유하고 상호 검토하는 협력을 통해 불행한 일을 ‘또는’ 조건에서 ‘그리고’ 조건으로 바꾸게 한다.
    • 애자일은 좋은 일의 상황에 대해서는 ‘그리고’ 조건을 ‘또는 조건으로 바꾸게 한다. 모든 사람이 통찰을 얻어야 업무를 개선할 수 있는 게 아니라 한 사람이라도 통찰을 얻으면 그걸 공유해서 전체가 개선되는 것이다.

• 애자일의 씨앗

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

    • 고객에게

      • 우리의 진짜 고객은 누구인가?

    • 매일

      • 어떻게 점진적으로 가치를 전할 것인가?

      • 어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?

        • 불확싱성이 높을수록 학습빈도가 자주 있어야 한다.

    • 가치를

      • 무엇이 가치인가?
      • 지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가?
      • 지금 가장 높은 가치는 무엇인가?
      • 비슷한 수준의 가치를 더 값싸게 전달하는 방법은?

    • 전하라

      • 가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?
      • 고객이 정말 가치를 얻고 있는가?