Jongbin Oh

I write something to think

13 minute read

’How to Read Code?’ 영상을 재미있게 봤다. 코드를 읽는 데 도움이 되는 인지과학이라니 재미있다. 저서가 있다. 번역본이 있다. 묻지 마 구매를 했다. 읽을 책 큐에 한참을 담겨 있다가 이번에 빼내서 읽었다.

인지 과정 - LTM, STM, Working memory

코드를 이해하는 데 관여하는 세 가지 공간이 있다. LTM(long-term memory)으로 불리는 장기 기억 공간, STM(short-term memory)으로 부르는 단기 기억 공간, Working memory로 부르는 작업 기억 공간이다.

세 가지를 간략하게 설명하면 아래와 같다

  • LTM은 추상적인 알고리즘과 프로그래밍 언어의 문법 같은 지식이 저장되는 곳이다. 반영구적으로 저장되는 곳이다. 컴퓨터로 치면 하드 드라이브다. 지식의 부족이 일어나는 곳이다.
  • STM은 코드에서 키워드, 변수명, 자료구조 등이 저장되는 곳이다. 들어오는 정보를 잠시 보관한다. 컴퓨터로 치자면 캐시나 메인 메모리다. 정보의 부족이 일어나는 곳이다.
  • Working memory는 실제 사고가 일어나는 곳이다. 컴퓨터로 치자면 프로세서이다. 처리 능력의 부족이 일어나는 곳이다.

재미있다. 이게 도움이 될지는 모르겠지만 사고의 폭을 넓힐 수 있는 용어를 배운 건 분명하다.

모든 문제의 원인은 너무나 겸손한 STM의 최대치다. 12개를 넘지 않는다니 충격적이다. 얼마나 빠른 캐시길래 이렇게 인색하게 넣었을까? STM이 충분했으면 인지과학을 조금은 등한시했을지도 모르겠다.

컴퓨터 구조와 너무 딱딱 맞아떨어져서 신기했다. 폰노이만은 인지 과정을 속속들이 알고 컴퓨터 모델을 설계했을까? 만들다 보니 비슷해졌는지 참고했는지 궁금하다. 어떻게 이렇게 닮을 수가 있을까? 무에서 유를 창조할 수 없으니 컴퓨터를 이렇게밖에 설계할 수 없는 건 인간의 한계인지도 모르겠다. AI는 완전히 다르게 설계할 수 있지 않을까?

저용량 STM을 효율적으로 쓸 수 있는 청크(chunk)

인지 과정에서 캐시 역할을 하는 STM의 용량이 터무니없이 적다. 이 공간을 늘릴 방법은 없다고 한다. 그렇다면 효율적으로 사용할 수 있는 방법이 있는 걸까? 이 공간을 어떻게 사용하느냐에 따라 단기 기억량이 극적으로 차이 날 것이다.

반면 전문가 그룹은 첫 번째 실험에서 다른 전략을 보였다. 이 그룹의 전문 체스 선수들은 LTM(long-term memory)에 저장되어 있는 지식을 많이 활용했다. 예를 들면 ’시실리언 오프닝이고, 거기서 나이트 하나는 2칸 왼쪽’ 같은 식이었다. 이런 방식으로 말의 위치를 기억하는 것은 시실리언 오프닝에서 어떤 말이 사용되는지에 대한 지식이 LTM에 있어야만 가능하다. 전문가 그룹이 하는 방식으로 말의 위치를 기억하는 것은 작업 기억 공간에서 4개 정도의 항목만 필요하다. STM(short-term memory)의 용량은 2개에서 6개 사이로 추정되기 때문에 4개 항목은 STM에 저장되는 게 가능하다. p.22

더흐로트는 몇 개의 그룹으로 묶은 정보를 청크(chunk)라고 불렀다. 예를 들어 ’시실리언 오프닝’은 하나의 청크이므로 STM(short-term memory)의 기억 공간 하나만을 차지한다. p.22

LTM에 저장한 지식을 사용하는 것이다. 청크라고 부르는데, LTM 지식의 포인터라고도 볼 수 있다. LTM이 많을수록 저용량 STM을 효율적으로 사용할 수 있다. LTM에는 어떻게 효율적으로 저장할 수 있을까?

인출(retrieval)과 정교화(elaboration) 그리고 플래시카드(flashcard)

코드를 읽고 이해하려면 저용량 STM을 효과적으로 사용해야 한다. 대용량 LTM에 정보를 넣고 쉽게 꺼낼 수 있게 단련해야 STM에 청크 단위로 적재해서 많은 정보를 로드할 수 있다.

스포일러 주의! 결국은 플래시카드 써서 열심히 외우자.

캘리포니아 대학교의 심리학과 교수인 로버트 비요크와 엘리자베스 비요크는 LTM(long-term memory)으로부터 기억을 가져오는 두 가지 서로 다른 기제, 즉 저장(storage) 강도와 인출(retrieval) 강도를 구분했다. p.44

이름, 노래 등을 잘 안다고 생각했는데 막상 잘 기억이 나지 않는 경험이 있을 것이다. 저장 강도는 높지만 인출 강도가 낮을 때, 이런 현상이 나타난다. 저장 강도와 인출 강도 중에서 인출 강도를 더 신경 써야 한다. 저장 강도와 다르게 인출 강도가 시간이 흐를수록 약해지기 때문이다. 마치 저장은 상대적으로 싸지만 읽는 건 비싼 고용량 스토리지를 보는 것 같다.

기억을 강화하는 두 가지 테크닉에 대해서 다룰텐데 적극적으로 무언가를 일부러 기억해보려고 애쓰는 인출(retrieval) 연습과 기존 기억에 새로운 지식을 적극적으로 연결시키는 정교화(elaboration)다. p.44

인출 연습은 인내가 필요하다. 기억이 안 난다고 바로 ChatGPT에 물어보기 전에 기억하려고 애써야 한다. 인출 노력을 하지 않고 검색하게 된다면 두뇌가 문법을 기억할 필요가 없다고 생각한다. 해당 정보에 대해서는 인출 강도를 약하게 유지한다. 그 정보가 필요할 때마다 LTM에서 로드 실패를 하게 되고 인터럽트를 감수하고 찾아보거나 물어봐야 한다.

기억이 처음 저장될 때 기억의 부호화를 강화할 수 있는 한 가지 방법이 바로 정교화(elaboration)다. 정교화는 기억하고자 하는 내용을 기존 기억과 연관 지으면서 생각하는 것을 뜻하고, 이렇게 한 결과 LTM(long-term memory)에 이미 저장되어 있는 스키마타에 맞춰서 새로운 기억이 저장된다. p.49

정교화는 알고 있는 지식과 링크를 만들어서 기억을 강화하는 방법이다. Org-roam, Obsidian과 같은 Personal Knowledge Management System이 도움을 줄 수 있다. 노드 사이에 링크를 권장하는 개인 지식 관리 시스템이기 때문이다.

프로그래밍 언어 문법을 포함해서 무엇이든 신속하게 학습할 수 있는 좋은 방법 중 하나가 플래시카드(flashcard)를 사용하는 것이다. 플래시카드는 종이 카드나 포스트잇으로 간단히 만들 수 있다. 앞면에는 암기하거나 학습하려고 하는 내용에 대한 프롬프트, 즉 그것을 지칭하는 단어나 질문이 있고 뒷면에는 그에 대한 내용이나 답이 있다. p.38

오랫동안 학습한 만큼 더 오래 기억한다. 이것은 더 많은 시간을 학습해야 한다는 것을 의미하는 게 아니라 더 오랜 간격을 두고 학습해야 한다는 것을 의미한다. 플래시카드를 한 달에 한 번 다시 학습하면 오랫동안 기억하는 데 충분하고, 이 정도는 충분히 할 수 있을 것이다. 이것은 정규 교육기간에서 한 학기 동안 혹은 부트캠프에서 3달 동안 배운 모든 지식을 머릿속에 집어넣어야 하는 경우와 극명하게 대비된다. 그렇게 학습한 지식은 그 이후로도 계속 반복해야만 잊어버리지 않는다. p.43

LTM에 정보를 많이 넣고 인출 강도가 높게 유지해야 한다. 즉, 암기가 중요하다. 암기를 과학적으로 할 수 있는 방법이 있을까? 나왔다! Flashcard.

따라서 다음번에 구글에서 프로그래밍 문법에 대해 검색하려고 할 때, 검색 이전에 먼저 그것을 능동적이고 의도적으로 기억하려고 시도해보기 바란다. 당장 기억이 나지 않더라도 이런 기억하려는 노력은 기억을 강화하고 다음번에 기억해내는 데 도움이 될 것이다. 이렇게 해도 기억이 나질 않는다면 플래시카드를 사용해서 적극적으로 연습해보기 바란다. p.47

플래시카드는 정말 필요한가 보다. 뭔가 강화하는 게 나오면 어김없이 나오는 플래시카드. 이걸 한번 배워야겠다. 이런 학습법을. 플래시카드 어쩌면 이 책에서 얻은 가장 값어치있는 방법일지도 모른다고 생각했다.

’변수 역할’ 프레임워크

변수 역할을 나눠서 청크를 효율적으로 사용할 수 있는 프레임워크를 소개한다.

사야니에미에 따르면 우리는 ’변수’나 ’정수’처럼 너무 많은 것을 포함하는 청크를 사용하거나 혹은 number_of_customer 같은 너무 구체적인 변수명처럼 너무 적은 것을 포함하는 청크를 사용하는 경향이 있다고 한다. 프로그래머는 그 사이의 중간이 필요한데, 이것이 사야니에미로 하여금 변수 역할(role of variables)이라는 프레임워크를 만든 동기가 됐다. 변수의 역할은 프로그램 내에서 변수가 하고자 하는 바를 나타낸다. p.72

이건 좀 놀랐다. 인정한다. 이론 만세다. 내가 생각하는 변수가 다 소개하는 프레임워크로 분류할 수 있는 것 같다. 코드를 읽을 때 청크를 효율적으로 할 수 있는 프레임워크인 것 같다.

  • 고정값(fixed value)
    • 초기화를 통해 값이 할당된 이후 값이 변경되지 않는 변수다
    • 예) constant
  • 스테퍼(stepper)
    • 루프를 반복 실행하며 값이 단계적으로 변하는 변수
    • 예) for 루프 i
  • 플래그(flag)
    • 무엇인가 발생했거나 어떤 경우에 해당하는지를 나타내는 변수
    • 예) is_set, is_available
  • 워커(walker)
    • 스테퍼와 유사하지만 차이점은 자료구조를 순회하는 방식
    • 스테퍼는 미리 정해진 값을 따라 반복
    • 예) for i in range(0, n)
    • 워커는 루프가 시작되기 전에는 어떤 값을 가지게 될지 알 수 없다
    • 예) 스택, 트리
  • 최근값 보유자(most recent holder)
    • 어떤 값이 변해갈 때 가장 최근에 변경된 값을 갖는 변수
    • 예) 파일을 한 줄씩 읽어 들일 때 가장 마지막으로 읽는 줄을 저장하는 변수
    • line = file.readline()
  • 목적값 보유자(most wanted holder)
    • 어떤 값에 대해 반복할 때는 그 목적이 어떤 특정한 값을 찾는 것
    • 최근값 보유자랑 비슷하지만 목적이 다름
    • 예) min, max
  • 모집자(gather)
    • 데이터를 모으거나 모은 데이터에 대해 어떤 연산을 수행하여 얻은 값을 저장하는 변수
    • 예) 루프를 돌며 sum += list[i] 실행하는 경우 sum이 모집자
  • 컨테이너(container)
    • 값을 새로 추가하거나 삭제할 수 있는 자료구조
    • 예) 리스트, 배열, 스택
  • 추적자(follower)
    • 어떤 알고리즘에서는 이전 값 혹은 다음 값을 추적해야 할 필요가 있는데 그때 사용
    • 예) Linked list에서 이전 값에 대한 포인터
  • 조직자(organizer)
    • 추가적인 처리를 위해 변수의 값을 변환
    • 예) 문자열 내 개별 문자에 접근하려고 문자 배열로 변환
    • 종종 임시 변수이기도 함
  • 임시(temporary)
    • 잠시만 사용하기 위한 변수
    • 예) swap 내 변수

인지 부하(cognitive load)를 줄이는 리팩터링

처음엔 ’리팩터링 Refactoring (마틴 파울러, 2012)’ 재탕이라고 생각했다. 읽을수록 다른 관점에서 설명한다. 인지 부하를 줄이는 방향으로 리팩터링을 할 수도 있고 유지보수 비용이 낮은 쪽으로 리팩터링을 할 수도 있을 것 같다. 인지 부하를 인식하는 순간부터 리팩터링의 다른 길이 보일 수 있을 것만 같다.

긴 매개변수 목록과 복잡한 스위치 문은 Working memory 용량 초과를 유발한다. god class와 긴 메서드 같은 경우엔 효율적인 청킹이 불가능하게 한다. 복사한 후 조금만 고친 코드는 청킹이 잘못될 수 있다.

정보를 LTM에 저장하는 노력인 본유적 인지 부하

문제 자체에 있는 내재적 부하와 문제의 표현이 초래하는 외재적 부하를 다뤘다. 하지만 앞에서 살펴보지 못한 세 번째 유형의 인지 부하가 바로 본유적(germane) 인지 부하다.

본유적 부하는 두뇌가 정보를 LTM에 다시 저장하기 위해 수행하는 노력을 의미한다. 여러분이 가지고 있는 모든 인지 부하가 내재적 부하와 외재적 부하로 가득 차면, 본유적 부하를 위한 여지는 남아 있지 않게 된다. 즉 문제와 그 해결책을 기억할 수 없다.

힘든 코딩 작업을 마친 후 때때로 자신이 한 일을 기억하지 못하는 경우가 있을 것이다. 이것이 바로 이런 이유 때문이다. 두뇌가 해결책을 저장할 수 없을 정도로 몰입해 있었던 것이다. p.188

이런 적이 있었던 것 같다. 다른 사람이 문제를 푸는 걸 의도적으로 공부하면 본유적 부하를 줄일 수 있다고 한다. 즉, 적은 부하로 두뇌가 정보를 LTM에 다시 저장할 수 있다. 중간보고 습관이 생각났다. 쓰는 사람에게 가장 직접적으로 도움이 되지만 다른 사람이 어떻게 문제를 풀었는지 손쉽게 접근할 수 있게 해준다. 같이 일하는 동료의 본유적 인지 부하를 줄일 수 있게 도와준다. 정말 모두에게 좋은 훌륭한 습관이다.

코드 작성 중 인터럽트에 대처하는 방법

크리스 파닌의 연구 결과 업무가 중단된 후 코드 작성 작업을 다시 시작하는 데 약 25분이 소요된다고 한다. 이건 많이 들었던 얘기다. 뭐 그러니 집중 시간이 있어야 한다는 등의 얘기가 있다. 하지만 이건 우리가 통제할 수 없는 환경이다. 애석하게도 지금은 Slack이 연 대인터럽트의 시대를 살고 있다. 인터럽트가 일어나는 상황은 통제할 수 없으니 어떻게 하면 잘 대처할 수 있는지를 설명한다.

정신 모델(mental model)을 저장하라. 코드에 대한 최신 정신 모델을 주석문의 형태로 덤프하면 도움이 된다. 나는 주로 일지나 중간보고로 덤프를 남긴다. 집에서 사이드 프로젝트를 할 때는 일지가 도움이 많이 된다. 사이드 프로젝트를 할 수 있는 시간도 짧을뿐더러 인터럽트가 많기 때문이다. 중단 전까지 진행하던 정신 모델을 빠르게 로드해야 한다. 그걸 일지가 도와준다.

하위 목표(subgoal) 라벨을 붙이는 건 인터럽트에 대처하는 방법에도 좋고 Copilot에게 주는 힌트로도 훌륭하다. 요즘 어디 주석을 사람 보라고 쓰나요? AI 보라고 쓰지.

예를 들어 텍스트를 재구성하는 방법을 구현하고 있다면 아래와 같이 하위 목표를 파일 상단에 주석 형태로 적어놓는 식이다.

  1. 텍스트를 구문 분석하고 구문 분석 트리를 생성한다
  2. 구문 분석 트리를 필터링한다
  3. 트리를 선형구조로 변환해 텍스트를 만든다

일지와도 비슷한 맥락이긴 한데 AI에게 힌트를 주기엔 이 방법이 더 좋다.

마치며

요즘은 뭐 AI가 코드를 다 짜준다며? 시기가 이런데 프로그래밍에 관련된 인지과학 지식을 담은 이런 책이 도움이 되는 걸까? 더 읽는 게 많아져서 오히려 더 중요해질 수도 있다고 생각한다. 저자는 프로그래머가 코드를 짜는 것만 배우지 읽는 것은 배우지 않는다고 지적했다. AI 때문에 읽는 능력이 전보다 더 중요해질 것 같다. AI가 코드를 정말 잘 짜고 다 해준다고 해도 결국 책임을 질 사람은 꼭 필요하니깐.

AI의 답변을 아무 생각 없이 복사해서 붙이거나 남에게 이렇다고 전달하는 게 아니라면. 짜주는 코드를 그대로 써서 커밋하고는 문제가 생기면 AI가 짠 코드인데요. 이렇게 말도 안되는 핑계를 대는 게 아니라면. 이해하는 게 필수이다. 만약 저렇게 말한다면 월급을 AI에게 줘야 한다. LTM(long-term memory), STM(short-term memory), Working memory를 사용하는 인지 과정을 AI가 피할 수 있게 해주는 게 아니다. Prompt Engineering에서 프로그래밍 관련 질문을 할 때, “나는 프로그래머야”라고 프롬프트 문장을 시작하는 이유가 프로그래밍에 관련된 지식이 LTM에 있으니 설명할 때, 내가 청크를 만들 수 있게 고려하라는 뜻이기도 하다.

인지 과정에 STM을 효율적으로 사용할 수 있어야 인지 과부하를 피할 수 있다. LTM에 저장된 지식을 가르키는 포인터로 비유할 수 있는 청크로 저용량의 STM을 잘 쓸수 있다. 지식의 외주화가 일어나도 암기는 여전히 중요할 수밖에 없다는 생각이 들었다. 책에서 추천한 Flashcard를 적극적으로 써봐야겠다. 혹시 Emacs에도 관련 패키지가 있을까? 역시 있다. 헤매지 말고 익숙한 Emacs에서 org-drill.el부터 사용해 봐야겠다.

책이 별로라고 생각했다. 초반에는 엄청나게 재미있다가 뒤로 갈수록 재미가 급격히 떨어졌기 때문이다. 재미의 밸런스가 망가졌다. 하지만 독후감을 적어보니 꽤 많은 걸 배웠다. 암기에 시큰둥한 사람에게는 한 번 읽어보라고 하고 싶다.

밑줄

  • 프로그래밍을 처음 배울 때는 코드를 만들어내는 것에 관심을 많이 갖는다. 대학이나 직장, 혹은 부트캠프에서도 일단 프로그래밍을 배우고 나면 코드를 작성하는 것에 훨씬 더 많은 관심과 시간을 쏟는다. 문제를 어떻게 풀고 그것을 코드로 어떻게 구현하는지를 집중적으로 훈련한다. 코드를 읽는 연습은 거의 전무할 것이다. p.15
  • 코드에 있는 정보를 모두 STM(short-term memory)에 저장하고 처리하는 것은 물리적으로 불가능하다. STM은 읽거나 들은 정보를 짧은 시간만 저장한다. 여기서 짧은 시간이라는 것은 정말로 짧은 시간을 의미하는데 연구에 의하면 30초를 넘지 않는다. 30초 후에 그 정보는 LTM(long-term memory)에 저장되거나 잊힌다. p.19
  • 좀 더 최근의 연구에서는 STM(short-term memory)의 용량이 2개에서 6개 사이로 심지어 더 적다고 추정한다. 이 용량은 거의 대부분의 사람에게 해당하고, 과학자들은 STM의 용량을 향상하는 방법을 아직 찾지 못했다. 기억 공간이 채 1바이트도 되지 않는 인간이 그 많은 일을 한다니 기적 아닐까? p.20
  • 반면 전문가 그룹은 첫 번째 실험에서 다른 전략을 보였다. 이 그룹의 전문 체스 선수들은 LTM(long-term memory)에 저장되어 있는 지식을 많이 활용했다. 예를 들면 ’시실리언 오프닝이고, 거기서 나이트 하나는 2칸 왼쪽’ 같은 식이었다. 이런 방식으로 말의 위치를 기억하는 것은 시실리언 오프닝에서 어떤 말이 사용되는지에 대한 지식이 LTM에 있어야만 가능하다. 전문가 그룹이 하는 방식으로 말의 위치를 기억하는 것은 작업 기억 공간에서 4개 정도의 항목만 필요하다. STM(short-term memory)의 용량은 2개에서 6개 사이로 추정되기 때문에 4개 항목은 STM에 저장되는 게 가능하다. p.22
  • 더흐로트는 몇 개의 그룹으로 묶은 정보를 청크(chunk)라고 불렀다. 예를 들어 ’시실리언 오프닝’은 하나의 청크이므로 STM(short-term memory)의 기억 공간 하나만을 차지한다. p.22
  • ’이 함수는 주어진 이진 트리를 중위 순회하여 프린트한다’ 같은 고수준 주석문은 청크 단위를 쪼개는 데 도움이 된다. 반면 i++; 다음에 ’i를 1만큼 증가’ 같은 저수준 주석문을 넣는 것은 오히려 청킹 작업에 부담이 된다. p.30
  • 의도적 연습(deliberate practice)은 어떤 기술을 향상하기 위해 조금씩 연습하는 것을 의미한다. 팔의 근육을 늘리기 위해 하는 푸시업은 의도적 연습이다. 음계(스케일) 연습 또한 음악가에게는 의도적 연습이다. 단어의 스펠링 연습하는 것도 처음 책을 읽는 아이에게는 의도적 연습이다. 프로그래밍에서는 여러 가지 이유로 의도적 연습이 흔치는 않다. 많은 사람이 코드를 많이 작성해보는 것으로 프로그래밍을 학습한다. 그렇게 해도 되지만 효과적인 방법은 아닐 수도 있다. 청킹을 의도적으로 연습하기 위해서는 적극적으로 코드를 기억해내는 것을 훈련하면 아주 좋다. p.34
  • 프로그래밍 문법에 대한 지식을 갖는 것에 대해 대수롭지 않게 생각할 수도 있다. 모르면 결국 온라인에서 찾아보면 되니 말이다. … 코드를 효율적으로 이해하는 정도는 이미 알고 있는 지식에 의해 영향을 받는다. 따라서 프로그래밍 언어의 문법, 개넘과 자료구조를 외우면 코드를 더 빨리 파악하는 데 도움이 된다. p.36
  • 프로그래밍 언어 문법을 포함해서 무엇이든 신속하게 학습할 수 있는 좋은 방법 중 하나가 플래시카드(flashcard)를 사용하는 것이다. 플래시카드는 종이 카드나 포스트잇으로 간단히 만들 수 있다. 앞면에는 암기하거나 학습하려고 하는 내용에 대한 프롬프트, 즉 그것을 지칭하는 단어나 질문이 있고 뒷면에는 그에 대한 내용이나 답이 있다. p.38
  • 오랫동안 학습한 만큼 더 오래 기억한다. 이것은 더 많은 시간을 학습해야 한다는 것을 의미하는 게 아니라 더 오랜 간격을 두고 학습해야 한다는 것을 의미한다. 플래시카드를 한 달에 한 번 다시 학습하면 오랫동안 기억하는 데 충분하고, 이 정도는 충분히 할 수 있을 것이다. 이것은 정규 교육기간에서 한 학기 동안 혹은 부트캠프에서 3달 동안 배운 모든 지식을 머릿속에 집어넣어야 하는 경우와 극명하게 대비된다. 그렇게 학습한 지식은 그 이후로도 계속 반복해야만 잊어버리지 않는다. p.43
  • 기억을 강화하는 두 가지 테크닉에 대해서 다룰텐데 적극적으로 무언가를 일부러 기억해보려고 애쓰는 인출(retrieval) 연습과 기존 기억에 새로운 지식을 적극적으로 연결시키는 정교화(elaboration)다. p.44
  • 망각 곡선과 인출 강도의 효과에 대해 살펴봤기 때문에 매번 필요할 때마다 문법을 찾아보기만 하는 것이 왜 좋은 방법이 아닌지 분명해졌을 것이다. 너무 쉽게 정보를 찾고 또 그것이 너무 일상적으로 이뤄지다 보니 우리 두뇌는 문법을 기억할 필요가 없다고 느낀다. 따라서 프로그래밍 문법에 대한 인출 강도가 강화되지 않고 계속 약한 상태로 남아 있게 된다. p.46
  • 우리 두뇌에서 기억은 다른 기억과 사실에 연결되는 연관된 네트워크의 형태라는 것을 살펴봤다. 사고나 생각이 서로 관련되어 조직된 방식을 스키마(schema) 혹은 스키마타(schemata)라고 부른다. 새로운 정보를 학습할 때 정보는 LTM(long-term memory)에 저장하기 전에 먼저 스키마의 형태로 만들어진다. 이미 존재하는 스키마에 잘 맞는 정보일수록 더 쉽게 기억할 수 있다. p.47
  • 기억이 처음 저장될 때 기억의 부호화를 강화할 수 있는 한 가지 방법이 바로 정교화(elaboration)다. 정교화는 기억하고자 하는 내용을 기존 기억과 연관 지으면서 생각하는 것을 뜻하고, 이렇게 한 결과 LTM(long-term memory)에 이미 저장되어 있는 스키마타에 맞춰서 새로운 기억이 저장된다. p.49
  • 사야니에미에 따르면 우리는 ’변수’나 ’정수’처럼 너무 많은 것을 포함하는 청크를 사용하거나 혹은 number_of_customer 같은 너무 구체적인 변수명처럼 너무 적은 것을 포함하는 청크를 사용하는 경향이 있다고 한다. 프로그래머는 그 사이의 중간이 필요한데, 이것이 사야니에미로 하여금 변수 역할(role of variables)이라는 프레임워크를 만든 동기가 됐다. 변수의 역할은 프로그램 내에서 변수가 하고자 하는 바를 나타낸다. p.72
  • 문제 자체에 있는 내재적 부하와 문제의 표현이 초래하는 외재적 부하를 다뤘다. 하지만 앞에서 살펴보지 못한 세 번째 유형의 인지 부하가 바로 본유적(germane) 인지 부하다. 본유적 부하는 두뇌가 정보를 LTM에 다시 저장하기 위해 수행하는 노력을 의미한다. 여러분이 가지고 있는 모든 인지 부하가 내재적 부하와 외재적 부하로 가득 차면, 본유적 부하를 위한 여지는 남아 있지 않게 된다. 즉 문제와 그 해결책을 기억할 수 없다. 힘든 코딩 작업을 마친 후 때때로 자신이 한 일을 기억하지 못하는 경우가 있을 것이다. 이것이 바로 이런 이유 때문이다. 두뇌가 해결책을 저장할 수 없을 정도로 몰입해 있었던 것이다. p.188
  • 주석문의 배후에 놓인 전반적인 아이디어는 설계자의 마음속에는 있었지만 코드로 표현할 수 없었던 정보를 포착하는 것이다. - 존 오스터하우트 p.200
  • 팀의 선임자들이 효과적으로 가르치고 설명하는 데 어려움을 겪는 이유 중 하나는 많은 경우 ’전문가의 저주’ 때문이다. 어떤 기술을 충분히 익히고 나면, 그 기술이나 지식을 배우는 것이 얼마나 어려웠는지 잊어버린다. 따라서 새 팀원이 동시에 처리할 수 있는 새로운 작업의 수를 과대평가하게 된다. p.223
  • 인지 과정에 대해 지금 필자가 알고 있는 것을 알기 전에는, 복잡한 논문을 읽거나 낯선 코드를 탐구할 만큼 똑똑하지 못한 것에 대해 자신에게 화가 나곤 했다. 이제 필자는 자신에게 더 관대하게 ’음, 어쩌면 뇌가 너무 큰 인지 부하를 겪고 있나 봐’라고 말할 수 있다. p.238

링크

You May Also Enjoy