노트

인지 부하

Cognitive Load

개발 문화#learning · 연결된 개념 16개

쉽게 말하면

인지 부하는 두 손에 한 번에 들 수 있는 짐의 양 같은 거예요. 물건 자체가 무거운 건 어쩔 수 없지만, 포장이 엉망이라 들기 힘든 건 코드를 잘 써서 덜어 줄 수 있어요.

비유가 깨지는 곳 짐은 무게가 정해져 있지만 외재적 부하는 읽는 사람의 지식에 따라서도 달라져요. 그래서 코드를 읽는 사람이 이미 아는 이름과 형태로 바꾸는 리팩터링이 부하를 줄여요.

작업 기억(Working Memory)이 한 번에 감당해야 하는 정신적 부담(Cognitive Load)이다. 작업 기억의 용량은 작아서, 부하가 한계를 넘으면 코드를 제대로 이해하지 못하고 실수가 늘어난다.

두 종류

  • 내재적 인지 부하(Intrinsic Cognitive Load): 문제 자체가 가진 복잡함. 정렬 알고리즘을 이해하는 데 드는 부담은 줄일 수 없다
  • 외재적 인지 부하(Extraneous Cognitive Load): 문제와 상관없이 표현 방식이나 읽는 사람의 지식 부족 때문에 생기는 부담. 줄일 수 있다

같은 로직도 어떻게 쓰느냐에 따라 외재적 부하가 크게 달라진다.

// 외재적 부하가 큰 코드: 읽는 사람이 조건을 머릿속에서 계산해야 한다
if (!(u.a > 17 && !u.b)) return;
 
// 이름이 의도를 대신 기억해 준다
const isAdult = user.age >= 18;
const isActive = !user.banned;
if (!isAdult || !isActive) return;

부하를 키우는 코드

이런 구조적 문제가 코드 냄새이고, 리팩터링은 코드를 읽는 사람이 이미 아는 형태로 바꿔 외재적 부하를 줄이는 일이다. 변수 추출하기, 함수 추출하기이 대표적이다.

읽는 쪽에서 줄이기

  • 의존 관계가 복잡하면 함수 호출을 종이에 그려 의존 그래프(Dependency Graph)를 만든다
  • 계산이 많은 코드는 실행 단계별 변수 값을 표(상태표, State Table)로 적어 본다

AI(Artificial Intelligence)가 짠 코드를 이해할 때 생기는 부담은 인지 부채와 이해 병목에서 다룬다.

출처: 『프로그래머의 뇌』 펠리너 헤르만스 (원서 The Programmer's Brain)

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 기술 부채

    지금 지름길을 택한 대가로 나중에 갚아야 할 비용을 빚에 빗댄 말. 워드 커닝햄(Ward Cunningham)이 1992년에 처음 썼다. 원금은 언젠가 제대로 고치는 비용이고, 이자는 지저분한 코드 때문에 매번 더 드는 개발 시간이다.

  • 재귀

    함수가 자기 자신을 다시 호출해 문제를 푸는 방식. 같은 함수를 점점 작은 입력으로 부르다가 더 나눌 필요가 없는 지점(기저 조건, Base Case)에서 멈춘다.

  • 동적 프로그래밍

    복잡한 문제를 더 작은 부분 문제로 나눠 풀되, 한 번 푼 부분 문제의 답을 저장해 다시 계산하지 않는 방법. 두 조건이 맞을 때 쓴다.

  • AI 시대 엔지니어의 역할 변화

    AI가 코딩을 맡으면서 개발의 무게가 기획·검증·학습으로 옮겨 가고, 병목은 리뷰와 결정으로 이동한다.

  • 섣부른 최적화

    "섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.

보기 옵션