프로그래머의 뇌

2022-07-12

프로그래머의 뇌

도서명 프로그래머의 뇌:훌륭한 프로그래머가 알아야 할 인지과학의 모든 것
지은이 펠리너 헤르만스
옮김 차건회
출판사 제이펍
TAG 컴퓨터/IT 개발방법론 프로젝트관리 프로그래밍 언어 프로그래밍일반
ISBN 9791191600650
금액 24,000원
출판일 2022년 01월 12일 발행
페이지수 272쪽
참고 펭귄의 외부 저장소 프로그래머의 뇌 요약
참고 ? 프로그래머의 뇌
참고 손혜정 The Programmer’s Brain (프로그래머의 뇌)
참고 임이지의 블로그 프로그래머의 뇌 - 제이펍
참고 도롱벌레 『프로그래머의 뇌』 리뷰
참고 책쓰는 프로그래머 유동 프로그래머의 뇌

title: “프로그래머의 뇌 요약” date: 2022-04-17 lastmod: 2022-04-24 categories:

  • 책 요약 tags:
  • 프로그래머의 뇌
  • 책 요약 draft: false hidden: false image: cover.png links:
    • title: 프로그래머의 뇌 website: http://www.yes24.com/Product/Goods/105911017 image: cover.png —

프로그래머의 뇌란 책을 읽고, 인상 깊었던 내용을 정리한다.

1 코드가 초래하는 세 가지 종류의 혼란

  1. 지식의 부족
    • 프로그래밍 언어나 알고리즘, 업무 영역에 대한 지식 부족
    • LTM의 문제
  2. 정보의 부족
    • 라이브러리, 모듈, 패키지 등의 정보 (ex. 움직임) 부족
    • STM의 문제
  3. 처리 능력의 부족
    • 코드가 너무 복잡해서, 두뇌의 처리 용량이 부족
    • 작업 기억 공간의 문제

2 코딩에 영향을 주는 인지 과정

  1. LTM (Long Term Memory)
    • 기억이 아주 오랫동안 보관되며, 별 노력 없이 인출이 가능하다.
    • 프로그래밍에서는 추상적인 알고리즘, 프로그래밍 언어의 문법 뿐 아니라 키보드로 입력하는 동작을 기억하는 것까지 포함한다.
    • 컴퓨터의 하드 드라이브와 비슷
  2. STM (Short Term Memory)
    • 들어오는 정보를 잠시 보관하기 위해 사용
    • 크기에 제한이 있으며, 최대 12개를 넘지 않는다고 알려져 있다.
    • 코드에서 키워드, 변수명, 자료구조 등을 기억하는 것을 포함한다.
    • 컴퓨터의 메인 메모리와 비슷
  3. 작업 기억 공간
    • 실제 사고 작용이 일어나는 공간
    • 컴퓨터의 프로세서와 비슷

코드를 읽는 동안 LTM, STM, 작업 기억 공간이 상보적으로 같이 일어난다.

  • 정보 -> 필터 -> STM -> 작업 기억 공간 -> LTM

3 코드를 신속하게 읽는 방법

사람의 STM 용량은 2~6개 사이로 추정되며, 용량을 향상 시킬 수 없다. 그로 인해 생소한 코드를 읽는 것에 어려움을 느낀다. 청크를 이용하여 STM의 용량 한계를 극복할 수 있다.

3.1 청크 (chunk)

몇 개의 그룹으로 묶은 정보, 하나의 청크는 STM의 기억 공간 하나만 차지한다.

  • LTM에 지식이 많으면 그 지식으로 인해 청킹(chunking) 하기 용이하고, 결과적으로는 코드를 읽기 수월해진다.
  • 반대로 뛰어난 프로그래머라도 LTM에 아직 저장되지 않은 지식을 이용한 코드 읽기에는 어려움을 겪는다.
    • ex. 키워드, 구조, 도메인 개념 등

3.2 청킹 효율 향상 방법

  • 코드에서 자주 사용되고, 예상 가능한 흐름
    • ex. 디자인 패턴, 프로그래밍 구성 요소, 도메인 지식
    • 디자인 패턴을 교육 후, 해당 디자인 패턴으로 만들어진 코드를 수정하게 할 경우 더 짧은 시간에 수정을 완료하였다. 디자인 패턴이 적용되지 않은 코드를 수정할 경우에는 수정시간에 차이가 거의 없었다.
  • 고수준 주석문
    • ex. 이 함수는 주어진 이진 트리를 중위 순회하며 프린트한다.
    • 저수준 주석문은 오히려 청킹 작업에 부담이 된다. (ex. i++; //i를 1만큼 증가)
  • 표식
    • 단순 표식: 식별자 (변수명, 클래스명, 메서드명), 연산자, 구조문 등
    • 복합 표식: 2개 이상의 단순 표식을 합친 표식
    • 청크보단 작은 범위를 나타냄

4 문법을 기억하는 것이 중요한 이유

문법 검색 등으로 업무가 중단되면 효율성에 큰 문제를 야기한다.

  • 보통 코딩 중단 후 다시 업무로 돌아가는데 약 15분 정도가 걸림
  • 메서드 수정 작업 도중 중단이 되고 나서 1분 이내에 하던 일을 다시 시작하는 경우는 10% 정도밖에 되지 않음
  • 업무가 중단되면 그동안 코드에 대한 중요한 정보를 잊어버리기 때문

5 플래시카드를 통한 학습

  • 플래시카드를 사용하기 좋을 때
    • 새로운 프로그래밍 언어나 프레임워크, 라이브러리를 배울 때 나오는 새로운 개념 학습
    • 어떤 개념을 검색할 때 (중요하다고 판단되는 개념만)
  • 연속으로 카드의 내용을 맞추면 개수를 줄이자

6 오랫동안 기억을 유지하는 비결

  • 오랫동안 학습한 만큼 더 오래 기억한다.
    • 많은 시간 학습해야 한다는 것을 의미하는게 아님
    • 계속 반복하는 것이 중요

7 저장 강도와 인출 강도

LTM으로부터 기억을 가져오는 두가지 기제가 존재한다.

  • 저장 강도: LTM에 얼마나 잘 저장하고 있는가
  • 인출 강도: 무언가를 얼마나 쉽게 기억할 수 있는가

7.1 두 강도의 상관관계

  • 저장 강도는 감소하지 않고 늘어나는 반면 인출 강도는 시간이 흐를수록 약해진다.
  • 학습을 추가로 하지 않고 정보를 기억하려고 능동적으로 노력하는 것만으로도 배운 것을 많이 기억할 수 있다.

7.2 문법을 기억하지 않음의 악순환

  1. 정보를 찾는 것이 쉽기 때문에 문법을 기억 할 필요가 없다고 생각
  2. 정보를 인출하려하지 않고, 검색하여 찾아 냄
  3. 인출 강도가 강화되지 않음
  4. 1번으로 돌아가 반복

8 스키마와 정교화

  • 스키마(schema): 사고나 생각이 서로 관련되어 조직된 방식
    • ex. 1, 3, 15, 127, 63, 31 => 이진수로 표현했을 때 모두 1로만 이루어진 숫자
  • 정교화(eleboration): 기억하고자 하는 내용을 기존 기억과 연관 지으면서 생각하는 것, LTM에 이미 저장된 스키마타에 맞춰서 새로운 기억이 저장되는 것
    • ex. java의 반복문을 알고있는 사람이 golang의 반복문을 학습하는 경우

9 인지 부하

작업 기억 공간은 ‘문제에 적용된 STM’의 의미로 정보를 처리하는 역할을 한다. 그렇기에 STM과 동일하게 한 번에 2 ~ 6개의 항목만 저장이 가능하다. 이 용량이 채워짐의 정도를 인지 부하라 하며, 넘치게 될 경우 과부하(overload) 상태가 된다.

9.1 인지 부하의 종류

  • 내재적 부하: 문제 그 자체가 갖는 특성이 원인이 된 인지 부하
  • 외재적 부하: 문제를 풀려는 과정의 복잡도가 원인이 된 인지 부하. 가지고 있는 지식에 따라 부하의 정도가 결정되는 특정이 있다.
  • 본유적 부하: LTM에 새로운 정보가 저장 될 때 발생하는 인지 부하

9.2 인지 부하를 줄이는 기법

  • 리팩터링 (인지적 리팩터링)
  • 생소한 언어 구성요소를 다른 것으로 대치 (ex. 삼항 연산자 -> if)
  • 플래시카드에 코드 동의어 추가

10 앱 헝가리안 vs. 시스템 헝가리안

  • 헝가리안 표기법: 변수명에 변수에 대한 정보를 접두어나 접미어의 형태로 추가하는 표기법
  • 시스템 헝가리안: 변수명에 타입을 나타내는 방식
  • 앱 헝가리안: 변수명에 역할이나 목적을 나타내는 방식
  • 현대의 타입 기반 프로그래밍 언어에서는 시스템 헝가리안을 사용하는 것이 권장되지는 않으나, 앱 헝가리안은 변수의 역할의 이해를 돕기때문에 여전히 유용한 방법이다.

11 텍스트 지식 vs. 계획 지식

  • 텍스트 지식: 키워드가 하는 일이나 변수의 역할 같은 프로그램의 표면적인 이해를 돕는 지식
  • 계획 지식: 프로그래머가 프로그램을 작성할 때 계획한 것이 무엇인지 혹은 무엇을 달성하려고 했는지에 대한 이해를 돕는 지식
  • 기술 스택, 프레임워크 (ex. 의존성 주입 프레임워크) 는 초점을 분리하기 때문에 실제 구조의 이해를 저하시키며, 즉 ‘계획 지식’을 쌓기 어렵게 한다.
  • 계획 지식을 얻기 위한 깊은 코드 이해를 위해서는 ‘초점’을 찾는 것이 중요하다.
    • 초점은 main() 메서드같은 진입 점이나, 오류가 발생한 라인 등을 가리킨다.

12 인지 능력과 프로그래밍 능력의 상관관계

  • 계산 능력(수학적 능력)을 통한 프로그래밍 능력 예측: 2% 분산(편차)
  • 언어 능력을 통한 프로그래밍 능력 예측: 17% 분산(편차)
    • 얼마나 빨리 프로그래밍 언어를 배울 수 있는지에 대한 예측력은 크다.
  • 작업 기억 공간 용량과 추론 능력을 통한 프로그래밍 능력 예측: 34% 분산(편차)
  • %가 높을 수록 예측력이 높음을 의미

13 모델 사용의 장단점

모델은 문제의 특정 부분에만 집중하게 해주며, 이로인해 LTM이 관련된 기억을 찾는데 도움을 주기 때문에 문제 해결에 유용하다. 그러나 모델은 생각하는 방식을 제약하고, 생각을 특정한 방향으로 유도하기 때문에 오히려 문제를 어렵게 만들기도 한다.

14 정신모델

  • 풀어야 할 문제에 대해 추론하기 위해 사용할 수 있는 작업 기억 공간 내의 추상화된 모델이다.
  • 작업 기억 공간에서 먼저 만들어 지고, 경우에 따라 LTM으로 이동한다.
  • 문제 풀이 시 사용 가능한 모델이 LTM에 있으면 그 모델을 이용하여 작업 기억 공간에서 모델을 재구축 한다. 이때 만들어지는 모델은 LTM에 저장된 모델과 같지 않을 수 있다.

14.1 정신모델의 예

  • 파일 시스템의 폴더와 파일의 구조: 실제로는 0과 1만을 가지고 있을 뿐
  • 코드의 특정라인이 실행: 실제로는 컴파일 되어 생성된 이진코드가 실행 되는 것임, 컴파일 타임에 최적화가 이뤄지는 경우 실제 동작은 코드와 다르게 수행 될 수 있다. (ex. case문의 최적화)

14.2 정신모델의 특징와 예

  • 불완전: 변수를 박스로 생각하는 것이 변수의 모든 특징을 설명하진 못한다.
  • 불안정: 처음에는 변수를 박스로 생각하지만, 변수에 대한 이해가 깊어지면서 이름표가 더 나은 모델이라고 생각한다.
    • 나은 모델을 찾았다고 해서 먼저 만들어진 모델이 두뇌에서 삭제되지는 않는다.
  • 모순이 있는 여러 개의 모델이 공존: 변수를 박스로도 이름표로도 생각 할 수 있다. 인지 부하가 높은 상황에서는 갑자기 오래된 모델을 사용 할 수도 있다.
    • 오래된 모델이 상대적으로 더 단순한 모델일 가능성이 높고, 인지 부하가 높아지면 단순한 모델을 사용하는 것을 선호하기 때문
  • 사용하지 않으려고 함: 디버깅 시 일반적으로 정신 모델을 만들어 해결하려하지 않고, 코드를 조금만 고치고 다시 돌려보고 버그가 해결됐는지 확인하는 것을 선호한다.

15 개념적 기계 (notional machine)

  • 추상적 수준에서 컴퓨터가 코드를 실행하는 방법에 대해 추론할 때 사용하는 모델이다.
  • 개념적 기계는 프로그래밍 언어 수준에서 작동하며 기저에 있는 시스템의 모든 세부 사항은 추상화 한다.

15.1 프로그래밍과 개념적 기계

프로그래밍에 관해 말할 때는 암시적으로 개념적 기계를 사용하며, 개념적 기계의 구성을 나타내는 단어는 개념적 기계를 만들때 사용한 특정 정신 모델에 영향을 받아 만들어진다. 예를 들어

  • 파일의 열림과 닫힘 상태 => 파일: 열고 닫을 수 있는 박스
  • 포인터가 특정 값을 가리킨다 => 포인터: 특정 값의 위치 정보
  • 함수가 값을 반환한다 => 함수: 입력값을 넣으면 결과값이 나오는 기계

실제 세계의 객체와 동작을 이용하여 만든 개념적 기계로 정신모델을 구축 할 경우, 학습에는 용이하지만, 실제 코드의 움직임을 완전히 설명하지 못하거나 오해하게 만들 수 있다. 한번 저장된 정신 모델은 제거되지 않고, 지속적으로 사용되므로 실제 세계로부터 차용한 개념적 기계를 이용하여 학습하는 것은 신중하게 해야한다.

16 전이(transfer)

LTM에 저장된 프로그래밍 지식은 새로운 프로그래밍 개념을 배우는데 도움을 주며, 이러한 활동을 전이라 부른다.

  • 학습 도중 전이: LTM에 저장된 정보를 사용해 새로운 내용을 쉽게 배우는 과정
    • ex. 자바를 알고 있는 상태에서 파이썬의 메서드를 배울 때, 자바의 메서드가 생각 나면서 좀 더 빨리 학습 할 수 있는 것
  • 학습 전이: 전혀 다른 환경에서 이미 알고있는 개념을 적용하는 과정
    • ex. 노트북을 바꿔도 어떻게 키보드를 사용하는지 아는 것

16.1 전이의 용이에 영향을 주는 요인

  • 숙달: 숙달된 지식일 수록 전이가 용이하다.
  • 유사성: 두 작업 사이의 유사성이 높을 수록 전이가 용이하다.
  • 배경: 작업을 실행하는 환경(ex. IDE)과 더 큰 범위에서의 환경(ex. 동료가 자신과 비슷한지)이 비슷 할 수록 전이가 용이하다.
  • 중요 특성: 어떤 지식을 전이해야 효과적인지 알고, 적용하면 전이가 용이해 진다.
    • 효과적인 지식의 선정은 누군가의 조언을 듣고 받아들이거나, 스스로 질문하여 답을 찾아야 한다.
  • 연관: 두 작업이 얼마나 비슷하다고 느끼는지에 따라 전이가 용이하다.
  • 감정: 작업에 대해 느끼는 감정이 긍정적일 수록 전이가 용이하다.
    • 작업에 대해 부정적으로 느끼면, 그 작업 자체에 대해 깊이 생각하지 않으려하므로 전이가 일어나기 힘들어 진다.

16.2 범주에 따른 전이의 종류

  • 저도 전이와 고도 전이
    • 저도 전이: 새 편집기에서 Ctrl + C, Ctrl + V 사용
    • 고도 전이: 변수 선언 방법
  • 근거리 전이와 원거리 전이
    • 근거리 전이: C#과 자바
    • 원거리 전이: 프로그래밍과 철학

16.3 긍정적 전이와 부정적 전이

  • 긍정적 전이: 기존 지식이 새로운 것을 배우거나 작업 할 때 도움이 되는 전이
  • 부정적 전이: 기존 지식이 새로운 것을 배우거나 작업 할 때 방해가 되는 전이
    • ex. 객체 지향 언어를 배운 후 함수형 언어를 배울 때 어려움을 겪음
    • 부정적 전이는 새로운 언어를 배우고 사용 할 때 혼란을 야기하고 버그로 이어질 수 있음

16.4 전이의 어려움

  • 일반적으로 전이가 될 거라 생각하는 것들이 사실은 전이되지 않는다.
    • 체스 지식이 논리적인 추론 기술과 기억력, 일반 지능을 높여주지 않는다.
    • 프로그래밍을 배운다고 인지 영역으로 전이되어 능력이 향상되지 않는다.
  • 하나의 프로그래밍 언어를 숙달했다고 해서, 새로운 언어를 배우는데 항상 도음이 되는 것이 아니다.
    • 즉, 새로운 프로그래밍 언어에서는 문법부터 차근차근 공부를 해 나가야 한다.
  • 사고방식을 확장하기 위해서는 이미 습득한 지식과 근본적으로 다른 지식을 선택하는 것이 중요하다.
  • 두 작업의 공통점과 차이점에 의식적으로 주의를 기울이면 전이가 쉬워 질 수 있다.

17 오개념(misconception; 오해)

부정적 전이의 결과로서 아래의 3가지가 모두 만족하면 발생한다.

  1. 사실과 다르다.
  2. 서로 다른 상황에서 일관되게 유지된다.
  3. 확신에 사로잡혀 있다.

17.1 오개념 교정

  • 기존의 개념을 근본적으로 바꾸거나 대체하여 새로운 언어에 맞는 정신모델로 대체하는 과정을 개념 변화(conceptual change)라고 한다.
    • 실제적으로 대체되는 것은 아니고 기존 개념의 인출 빈도를 줄이고, 새로운 개념의 인출 빈도를 늘리는 것이다.
  • 개념 변화를 위해서는 기존의 지식을 떨쳐내야 하기 대문에 많은 에너지 소비와 시간이 필요하다.
  • 억제의 통제 메커니즘을 통해 잘못된 개념대신 올바른 개념을 인출 할 수 있음이 밝혀졌다.
    • 억제는 자의식, 머뭇거림, 수줍음과 연관이 있음

17.2 오개념 방지

  1. 자신이 옳다고 확신하더라도 여전히 틀릴 수도 있다는 것을 인지
    • 즉, 열린 마음을 유지하는 것
  2. 흔하게 발생하는 오개념에 대해 의도적으로 연구
  3. 코드베이스 내의 테스트 및 문서화

18 식별자 이름 명명

18.1 명명이 중요한 이유

  1. 이름은 코드베이스의 상당 부분을 차지
  2. 코드 리뷰 시 이름의 역할
  3. 이름은 문서화의 가장 쉬운 형태
  4. 이름이 표식 역할을 할 수 있음 (인지 부하 감소)

18.2 명명의 인지적 측면

  • 형식이 있는 이름은 인지 부하를 줄이고, 일관성 있는 이름은 청킹을 용이하게 한다.
  • 식별자에서 사용되는 단어의 갯수도 작업 기억 공간의 최대 크기(2~6개)와 비슷해야 가독성이 좋아진다.
  • 명확한 이름은 LTM에서 각 단어에 해당하는 지식을 검색하기 용이하게 한다.
  • 이름에 대해 심사숙고하는 것은 코딩 후에 하는 것이 좋다. 코드 리뷰가 이름의 품질을 검토하기 좋은 타이밍이다.
    • 코딩 시 문제 해결에 몰두해 있으므로 높은 인지 부하를 겪으며, 그럼 좋은 변수 이름을 생각할 여유가 없다.

18.3 단어 축약 유무에 따른 차이

  • 식별자의 이름을 단어로 하는 것이 문자나 약자를 썼을 때보다 더 가독성이 좋다.
  • 단일 문자는 변수로 흔히 사용되지만, 독자가 필자와 같은 의미로 단일 문자를 이해 할 가능성은 높지 않으므로 단어를 선택하거나 명명 규약을 따르는 것이 낫다.

18.4 스네이크 케이스 vs. 캐멀 케이스

  • 캐멀 케이스로 써있으면 실수 할 확률을 줄여주지만, 인식하는데 좀 더 오랜 시간이 소요된다.
  • 캐멀 케이스로 훈련받은 프로그래머들은 일반인보다 인식속도가 빠르다.
  • 캐멀 케이스로 훈련받은 프로그래머들은 스네이크 케이스를 일반인보다 인식 속도가 더 늦다.

18.5 페이텔슨의 3단계 모델

더 나은 이름을 선택하는데 도움을 주기위한 목적으로 만들어진 3단계 모델

  1. 이름에 포함할 개념을 선택한다.
  2. 각 개념을 나타낼 단어를 선택한다.
    • 프로젝트 어휘 사전(project lexicon)이 있으면 일관된 이름을 선택하는 데 도움이 될 수 있다.
  3. 이 단어들을 사용하여 이름을 구성한다.
    • 자연어에 맞춰 이름 틀을 사용 (ex. 최대 점수 -> max_points)
    • 전치사를 추가하는 것 (ex. indexOf, elementAt)

19 코드 스멜과 인지 부하

코드 스멜은 구조적 안티패턴(structural antipattern)을 가진 코드다. 코드 스멜을 가지고 있는 코드는 오류가 있을 가능성이 높은 것으로 밝혀졌다. 아래는 대표적인 코드스멜과 그에 따른 인지 부하를 나타낸 것이다.

  • 긴 매개변수 목록, 복잡한 스위치 문: 작업 기억 공간의 용량 초과
  • 신의 클래스, 긴 메서드: 효율적인 청킹 불가능
  • 코드 클론: 청킹이 잘못됨

20 나쁜 이름과 인지 부하

나쁜 이름은 언어적 안티패턴(linguistic antipattern)이라고도 한다. 코드 내 언어적 요소가 수행하는 역할과 일치하지 않을 때 발생한다. 독자의 두뇌에 혼란을 초래해 인지 부하를 높인다.

21 문제 해결과 LTM

21.1 문제 해결을 위한 일반적 접근법

1945년 수학자 포여 죄르지는 ‘How to Solve It’ 이라는 책에서 아래와 같은 ‘사고 체계’를 제안했다.

  1. 문제 이해
  2. 계획 수립
  3. 계획 실행

연구 결과 아래의 이유로 위에 서술한 일반적 접근법이 효과적이지 않음이 밝혀졌다.

  • 계획 수립과 계획 실행은 LTM에 저장된 지식에 크게 영향을 받는다.
    • 저장된 지식이 없으면 어떻게 해결해야 하는지, 그리고 그 해결책을 어떻게 실행해야 하는지 모르기 때문이다.
  • 풀고자 하는 문제를 위한 계획 수립에 알맞는 전략을 LTM에서 인출 할 수 있는 가능성이 희박하다.
    • 지식의 전이 가능성도 낮기때문에, 다른 영역에서의 경험이 도움을 주기도 쉽지 않다.

21.2 문제 해결에 역할을 하는 기억

  • 절차적(암시적) 기억: 의식하지 않고 발휘하는 기술에 대한 기억 (ex. 자전거 타는 법)
  • 선언적(명시적) 기억
    • 일화적 기억: 경험에 대한 기억 (ex. 버그 수정 과정)
    • 의미적 기억: 의미, 개념, 사실에 대한 기억 (ex. 5 x 7 = 35)

암시적 기억은 다른 것을 배우는데 오히려 방해가 될 수도 있다. (쿼티 키보드 타이핑 -> 드보락 키보드 타이핑)

22 자동화(automatization)를 통한 문제 해결 능력 향상

암시적 기억에 저장된 정보를 인출 할 경우, 인지 부하가 거의 없기 때문에 더 어려운 문제를 해결하기 쉬워진다.

22.1 시간 경과에 따른 암시적 기억

암시적 기억은 반복에 의해 생성된다. 즉, 연습을 통해 만들어진다. 암시적 기억은 아래의 세 단계를 통해 형성된다.

  1. 인지 단계: 새로운 정보를 더 작은 부분으로 나누고 당면한 작업에 대해 명시적으로 생각한다.
  2. 연상 단계: 패턴이 나타날 때까지 새 정보를 받아들이는 것을 반복하는 단계, 패턴이 나타나면 완료된다.
  3. 자율 단계: 자동화 단계로 해당 기억을 인출해도 인지 부하가 증가하지 않는다.

22.2 인스턴스 이론(instance theory)

미국의 심리학자 고든 로건은 자동화는 LTM의 일화적 기억이 저장된 부분으로부터 기억을 인출함으로써 이루어진다고 주장한다. 이런 일화적 기억(인스턴스)들 하나하나는 어떤 기술(클래스)에 대한 기억으로 묶을 수 있고, 충분히 많은 일화적 기억이 있으면 더 이상 추론 없이 자동으로 해당 기억이 인출된다.(자동화)

22.3 암시적 기억 개선

자율 단계에 도달 하기 위해서는 반복적으로 실행하는 것이 좋다. 프로그래밍에서는 아래의 두가지 방법을 고민해보는 것이 좋다.

  1. 연습하고자 하는 기술이 필요한, 유사하지만 다른 프로그램을 많이 작성해보는 것
  2. 이미 작성된 프로그램을 수정하는 것

간격을 둔 반복은 학습의 핵심이며, 따로 시간을 떼어두고 연습하는 것이 좋다. 웨이트 트레이닝처럼 반복할 때마다 조금씩 더 강해진다.

23 풀이된 예제(worked example)를 통한 문제 해결 능력 향상

다른 사람들이 문제를 어떻게 해결했는지 의도적으로 연구함으로써 어려운 문제를 해결 할 수 있게 된다.

  • 제공 받은 풀이된 예제를 가지고 문제를 풀 경우, 그 문제와 비슷한 문제 뿐만아니라 해당 레시피를 적용 할 수 있는 다른 문제도 잘 푸는 것으로 확인되었다.
    • 수학, 음악, 체스, 스포츠, 프로그래밍을 포함한 다양한 연령 그룹과 주제에 대한 연구 결과에서 공통적으로 확인
  • 사람들은 해답을 스스로 생각하지 않고, 제공해 주는 것이 실력 향상에 도움이 되지 않는다고 생각하지만 실제로는 그렇지 않다.
  • 깃허브 리포지토리를 탐구하거나, 소스 코드에 대한 책 또는 블로그 게시물을 읽는 것이 프로그래밍 분야의 풀이된 예제 학습 경로이다.

23.1 본유적 부하

  • 본유적 부하는 두뇌가 정보를 LTM에 다시 저장하기 위해 수행하는 노력을 의미한다. 다른 부하에 비해 우선순위가 낮으므로, 인지 부하가 높아질 경우 문제와 그 해결책을 기억할 수 없다.
    • ex. 힘든 코딩 작업 후 때때로 자신이 한 일이 기억나지 않음)
  • 풀이된 예제를 제공받으면 본유적 부하가 높지 않게 되고, 레시피를 응용 할 여유가 생겨서 비슷한 다른 문제도 잘 푸는 것이다.
  • 프로그래밍에 대해서도 아이들에게 프로그램을 읽고 이에 대한 설명을 통해 배우는 것이 프로그램을 작성하며 배울 때보다 배우는 것이 더 많다는 연구결과도 있다.

24 업무 중단에 대한 팁

업무 중단을 피할 수 없으면 인지 부하가 적을 때 업무 중단을 하는 것이 업무에 도움이 될 수 있다.

  • 한창 업무 중에 업무 중단을 당할 경우, 그렇지 않은 그룹보다 작업을 끝마칠 때까지 시간이 더 오래 걸렸고, 더 작업을 마치기가 어렵다고 인식했다.

25 멀티태스킹

  • 사람은 깊은 인지 작업을 하는 동안 여러 가지 일을 할 수 없다.
    • 단, 자율 단계에 도달 한 경우에는 두 개 이상의 작업을 동시에 수행 가능하다.

26 적응 지원(onboarding)

26.1 적응 지원의 문제

일반적으로는 아래의 과정으로 적응 지원이 진행된다.

  1. 코드베이스의 도메인, 워크플로, 코드베이스를 한꺼번에 소개한다.
  2. 소개가 끝난 후 질문을 하거나 과제를 준다.

이로인해 적응 지원을 받은 팀원은 아래와 같은 어려움을 겪는다.

  • 너무 많은 정보의 양으로 인한 높은 인지 부하
  • 도메인이나 프로그래밍 언어의 부족으로 인한 청킹의 어려움
  • 자동화 기술 부족으로 인한 인지 부하

이러한 부하들로 인해 결국은 본유적 부하에 대한 여유 공간이 없어지므로 새로운 정보를 기억하는데 문제가 생긴다.

26.2 전문가의 저주

어떤 기술을 충분히 익히고 나면, 그 기술이나 지식을 배우는 것이 얼마나 어려웠는지 잊어버리는 것. 새 팀원이 처리할 수 있는 작업의 양을 과대평가한다.

26.3 전문가와 초보자의 차이

  • 전문가의 뇌는 LTM에 관련 기억이 많이 저장되어 있다. 그러므로 문제에 대해 이미 알고 그것에 접근하는 방법을 알고 있을 가능성이 높다.
  • 전문가는 코드 및 코드와 관련 있는 모든 사항을 매우 효과적으로 청킹할 수 있다.
    • ex. 오류 메시지, 테스트, 문제, 해결책 등

26.4 신피아제주의 개발 단계

  1. 감각운동기
    • 프로그램을 정확하게 추적할 수 없다.
    • 코드와 분리해서 일반적인 원리를 설명하는 것이 유용하지 않다. 실행 모델에 대한 이해가 우선 필요하다.
  2. 전조작기
    • 코드에 대해 귀납적으로 추론하므로, 그 코드의 의미를 설명하기는 어렵다.
    • 코드 자체에 매우 집중하는 단계이므로 다른 결과물들 (ex. 도표)을 보는 것을 어려워하므로 도표 제공이 유용하지 않다.
    • 코드를 깊이 이해하는 것이 어렵기 때문에 교육자가 보기에 일관적이지 않아 보인다.
  3. 구체적 조작기
    • 코드 자체를 읽음으로써 코드에 대해 연역적으로 추론한다.
    • 코드를 작성할 때 계획을 세우고 실행할 수 있다.
    • 때때로 코드베이스에 대한 전체적인 이해가 부족할 수 있고, 처음 수립한 전략에 대해 과도하게 몰입하는 것이 나타날 수 있다.
      • ex. 특정 버그를 수정하려고 종일 시도했지만 계속 실패한 주니어 프로그래머는 원래 방식을 계속 시도하곤 한다.
  4. 형식적 조작기
    • 논리적이고 일관적이며 체계적으로 추론할 수 있다.
    • 세부 사항을 스스로 배우는 데 어려움이 없고 필요하면 도움을 요청할 것이다.

4개의 단계는 연속적이며, 새로운 프로그래밍 개념이나 코드베이스의 새로운 측면을 학습할 때 학습자는 일시적으로 하위 단계로 다시 떨어질 수 있다.

26.5 의미적 파동(semantic wave)

초보자가 무언가 이해하려 할 때는 오스트레일리아의 과학자 칼 메이튼에 의해 정의된 의미적 파동을 따른다.

  1. 사용하는 목적이나 이유와 같은 일반적인 개념을 이해
  2. 포장 풀기: 특정 개념에 대해 구체적인 세부 사항을 학습
  3. 재포장: 학습한 내용을 바탕으로 다시 추상적인 수준으로 되돌아옴, LTM에 통합하는 작업을 포함

이와 관련하여 3가지 안티패턴이 존재한다.

  1. 고 평면선: 추상적인 용어만 사용
  2. 저 평면선: 해당 개념이 왜 적절하고 유용한지 모르고 세부 사항만 지나치게 학습
  3. 하향 에스컬레이터: 일반적 개념을 이해하고, 세부 사항을 학습했으나 재포장 시간이 없어서 LTM에 통합되지 못함
    • 새로운 개념과 예비 정보 사이에서 발견되는 공통점을 초보자에게 명시적으로 물어보는 것으로 도움을 줄 수 있음

26.7 적응 지원 개선 방안

  • 작업은 하나의 프로그래밍 활동으로만 제한
    • 탐구: 코드베이스의 전체적인 이해를 위한 코드 훑어보기
    • 검색: 특정 인터페이스를 구현한 클래스 찾기
    • 전사: 구현할 메서드에 대한 명확한 계획을 알려주기
    • 이해: 코드의 여러 측면에 대해 이해하기 (ex. 특정 메서드 요약하기)
    • 증가: 향후 계획을 포함해서 기존 클래스에 한 가지 기능을 추가하기
  • 기억 지원
    • LTM 지원: 관련 정보 설명
    • STM 지원: 규모가 작고 집중할 수 있는 작업 준비
      • 만드는 것 보다 이해하는 것이 중요 (ex. 기존 클래스 요약, 특정 기능의 실행에 참여하는 모든 클래스를 기록)
      • 간단한 기능을 구현하는 것도 가능. but, 관련 코드를 미리 준비 하는 작업 등의 인지 부하 감소 활동이 동반되어야 함
    • 작업 기억 공간 지원: 도표 그리기
      • 완전 초보자에게는 항상 유용하지는 않다.
  • 코드 함께 읽기

results matching ""

    No results matching ""

    카탈로그

    최근글

    99 other / uml

    04 react / JSX