[북리뷰] 프로그래머의 뇌: 인지과학으로 배우는 효율적인 코딩의 모든 것

https://link.coupang.com/a/dq37YD

프로그래머의 뇌:훌륭한 프로그래머가 알아야 할 인지과학의 모든 것 - 개발방법론 | 쿠팡

 

펠리너 헤르만스(Felienne Hermans) 저자의 『프로그래머의 뇌』는 프로그래밍을 단순한 기술 문제가 아닌 인지과학적 관점에서 분석한 혁신적인 저작입니다. 이 책은 우리의 뇌가 코드를 처리하는 방식을 과학적으로 이해함으로써 더 나은 개발자가 되기 위한 구체적인 방법론을 제시합니다. 개발 경력이나 경험과 무관하게 모든 프로그래머가 겪는 인지적 어려움의 원인을 파악하고, 이를 체계적으로 해결할 수 있게 도와줍니다.

​

AI 활용

​

핵심 기초: 뇌의 세 가지 인지 체계

이 책의 모든 내용은 인간 뇌의 세 가지 핵심 메모리 시스템에서 출발합니다:

​

1. 장기 기억 공간(Long-Term Memory, LTM) - 하드드라이브

LTM은 컴퓨터의 하드드라이브처럼 작동합니다. 우리가 배운 모든 지식, 읽은 책, 습득한 기술, 그리고 과거의 경험들이 이곳에 저장됩니다. 프로그래밍 맥락에서 LTM은 프로그래밍 언어의 문법, 알고리즘, 데이터 구조, 디자인 패턴 등 우리가 이미 알고 있는 모든 지식을 담고 있습니다. 중요한 점은 LTM의 저장 용량이 본질적으로 무한하다는 것입니다. 많이 학습할수록 더 많은 내용을 저장할 수 있으며, 특정 개념을 충분히 많이 반복 학습하면 거의 잊을 수 없을 정도로 기억이 강화됩니다.

​

2. 단기 기억 공간(Short-Term Memory, STM) - RAM

STM은 컴퓨터의 RAM처럼 현재 작업에 필요한 임시 정보를 저장합니다. 지금 당신의 차 열쇠가 어디에 있는지, 방금 읽은 변수의 이름이 무엇인지와 같은 즉시적이고 관련성 높은 정보들이 여기에 저장됩니다. 하지만 STM은 매우 제한된 용량을 가지고 있습니다. 연구에 따르면 STM은 2~6개 항목 정도만 동시에 보유할 수 있습니다. 이것이 프로그래밍에서 복잡한 코드를 읽을 때 어려움을 겪는 주요 원인입니다.

​

3. 작업 기억 공간(Working Memory) - CPU 레지스터

작업 기억 공간은 CPU의 레지스터처럼 우리가 실제로 생각하고 문제를 해결하는 곳입니다. 여기에서 아이디어를 조작하고, 계산을 수행하고, 해결책을 고안합니다. 프로그래밍할 때 코드의 논리를 분석하고, 버그를 찾고, 새로운 기능을 설계하는 모든 인지 활동이 이곳에서 일어납니다. 작업 기억 공간은 LTM과 STM의 정보를 모두 활용하여 동작합니다.

​

프로그래머가 겪는 혼란의 세 가지 원인

코딩 중 우리가 느끼는 혼란과 어려움은 사실 세 가지 명확한 원인으로 분류될 수 있습니다. 각 원인을 이해하는 것이 문제 해결의 첫 단계입니다.

​

지식의 부족(Lack of Knowledge)

지식 부족은 LTM의 문제입니다. 당신이 사용하는 프로그래밍 언어의 문법에 익숙하지 않거나, 특정 라이브러리나 프레임워크를 처음 접할 때 발생합니다. 예를 들어, Python을 처음 배우는 개발자가 *args나 **kwargs 같은 가변 인수 문법을 모를 때, 이것이 바로 지식 부족입니다. 이 경우 뇌는 낮은 수준의 정보(문자, 키워드)에 의존해야 하므로 STM 공간을 빠르게 소진합니다.

​

정보의 부족(Lack of Information)

정보 부족은 STM의 문제입니다. 당신이 프로그래밍 언어에는 능숙하지만, 새로운 코드베이스나 프로젝트에 처음 진입했을 때 나타납니다. 함수의 이름이 명확하지 않거나, 변수들이 무엇을 하는지 알 수 없을 때입니다. 즉, 언어는 알지만 이 코드가 무엇을 하는지 모르는 상황입니다.

​

처리 능력의 부족(Lack of Processing Power)

처리 능력 부족은 작업 기억 공간의 용량 초과입니다. 코드가 너무 복잡하거나 길어서 한 번에 이해하기 어려울 때 발생합니다. 예를 들어, 깊게 중첩된 루프, 여러 변수가 상호작용하는 복잡한 로직, 또는 많은 매개변수를 가진 함수를 읽을 때입니다.

흥미롭게도, 경력 보다는 경험과 지식의 양이 중요합니다. 10년 경력의 개발자도 새로운 언어를 배울 때는 지식 부족 상태가 되고, 경력 1년의 개발자라도 자신의 전문 분야에서는 전문가 수준의 처리 능력을 발휘할 수 있습니다.

​

 

AI 활용

 

​

코드를 빠르게 파악하는 읽기 전략

코드를 읽는 것은 책을 읽는 것과 근본적으로 다릅니다. 프로그래머는 단순히 정보를 추출하는 것이 아니라 코드의 의도와 구조를 이해해야 합니다.

​

청킹(Chunking): 정보를 묶음으로 처리하기

우리 뇌가 STM의 제한된 용량을 극복하는 방법이 바로 청킹입니다. 청킹은 여러 개의 개별 항목을 하나의 의미 있는 단위로 묶는 것입니다. 예를 들어:

• 초보자는 for i in range(10): 코드를 5개의 개별 요소(for, i, in, range, 10)로 읽습니다.
• 경험 많은 개발자는 이것을 하나의 개념(반복 10회)으로 읽습니다.

이것이 가능한 이유는 LTM에 충분한 지식이 축적되었기 때문입니다. LTM에 더 많은 지식을 쌓을수록, 더 효율적으로 청킹할 수 있으며, 더 많은 코드를 동시에 이해할 수 있습니다.

​

포커스 포인트(Focus Point): 진입점 설정하기

복잡한 시스템을 이해할 때, 무작정 모든 코드를 읽으려 하지 말고 포커스 포인트(시작점)를 설정해야 합니다. 포커스 포인트는 시스템으로의 진입점입니다. 하나의 시스템에는 여러 포커스 포인트가 있을 수 있으며, 각각은 다른 경로를 나타내지만 동일한 엔티티를 사용할 수 있습니다. 예를 들어, 전자상거래 시스템에서 checkoutUser()나 processPayment()를 포커스 포인트로 설정하고, 각각을 깊이 있게 추적하면 전체 시스템 이해가 훨씬 쉬워집니다.

​

패턴 인식

경험이 쌓일수록 반복되는 패턴을 빠르게 인식할 수 있습니다. 트리 순회, 정렬 알고리즘, 캐시 패턴 등을 여러 번 보고 나면, 유사한 코드를 만났을 때 즉시 그것의 의도를 파악할 수 있습니다. 이는 완전한 이해 없이도 패턴을 빠르게 식별할 수 있음을 의미하며, 결국 코드 읽기 속도를 획기적으로 향상시킵니다.

​

인지 부하의 이해: 코드 복잡성 관리

프로그래밍의 핵심 문제 중 하나는 인지 부하(Cognitive Load)입니다. 이것은 우리가 특정 작업을 수행할 때 뇌가 경험하는 정신적 압력을 의미합니다.

​

내재적 부하(Intrinsic Cognitive Load)

내재적 부하는 문제 자체의 복잡성으로부터 발생합니다. 피타고라스의 정리를 사용해 직각삼각형의 빗변을 계산할 때, 복잡한 수학이 필요합니다. 이 복잡성은 문제의 본질이므로 제거할 수 없습니다. 프로그래밍에서도 마찬가지입니다. 어떤 알고리즘 문제가 본래부터 복잡하다면, 그 복잡성은 내재적인 것입니다.

​

외재적 부하(Extraneous Cognitive Load)

외재적 부하는 우발적으로 추가되는 복잡성입니다. 이것은 피할 수 있으며, 피해야 하는 부하입니다. 예시:

• 명확하지 않은 변수명: a, x, temp 같은 이름은 외재적 부하를 증가시킵니다. 명확한 이름 user_age, transaction_id로 변경하면 부하가 감소합니다.
• 중복 코드: 같은 로직이 여러 곳에 흩어져 있으면, 각각을 이해해야 합니다.
• 나쁜 문서화: 함수의 목적이 명확하지 않으면 코드를 이해하는 데 더 많은 시간이 필요합니다.
• 과도한 들여쓰기나 중첩: 깊은 중첩은 구조를 파악하기 어렵게 만듭니다.

​

본유적 부하(Germane Cognitive Load)

본유적 부하는 새로운 개념을 LTM에 저장하는 과정에서 발생하는 인지 부하입니다. 이것은 유의미한 학습을 위해 필요한 부하입니다. 새로운 개념을 배울 때는 일정 수준의 본유적 부하가 필수적입니다.

핵심 원칙: 내재적 부하는 피할 수 없지만, 외재적 부하는 최소화해야 하고, 본유적 부하는 최적화해야 합니다. 외재적 부하가 높아지면 학습 효율이 떨어지고, 결국 코드 이해도 어려워집니다.

​

복잡한 코드를 다루는 실용 기법

복잡한 코드를 마주했을 때, 우리는 여러 기법을 활용할 수 있습니다.

​

인지적 리팩터링(Cognitive Refactoring)

리팩터링의 목표가 항상 코드의 성능을 향상시키는 것만은 아닙니다. 이해를 위한 리팩터링도 중요합니다. 복잡한 코드를 읽을 때, 더 읽기 쉽도록 임시로 코드를 리팩터링하고, 이해한 후 원래 상태로 돌릴 수 있습니다. 이는 외재적 부하를 줄이면서 내용을 더 깊이 이해하는 데 도움이 됩니다.

​

프로그램 이해의 4단계

복잡한 코드를 효과적으로 이해하려면 단계적 접근이 필요합니다:

1. 포커스 찾기: 시스템 내 특정 진입점(포커스 포인트)을 선택합니다.
2. 포커스로부터 지식 확장: 선택한 포커스 포인트로부터 관련 코드를 탐색합니다.
3. 관련 엔티티로부터 개념 확장: 비슷한 엔티티나 구조를 이해합니다.
4. 여러 엔티티에 걸친 개념 이해: 전체 시스템의 구조와 흐름을 파악합니다.

​

외부 메모리 활용

작업 기억 공간의 한계를 극복하기 위해 종이에 적거나 다이어그램을 그려야 할 때도 있습니다. 중간 변수의 값, 함수 호출 흐름, 시스템의 전체 구조를 외부에 기록함으로써 작업 기억 공간의 부하를 줄일 수 있습니다.

​

프로그래밍 문제 해결 능력 강화

더 나은 문제 해결 능력을 개발하기 위해서는 LTM에 정신 모델(Mental Models)을 축적해야 합니다.

​

정신 모델과 청킹

정신 모델은 우리가 특정 개념이나 구조에 대해 가지고 있는 이해의 집합입니다. 예를 들어:

• 트리 순회의 다양한 방식(전위, 중위, 후위 순회)
• 정렬 알고리즘의 작동 원리
• 캐시 전략
• 아키텍처 패턴

이러한 모델을 잘 이해할수록, 새로운 문제를 빠르게 인식하고 해결할 수 있습니다. 플래시카드를 사용해 이러한 개념들을 자동으로 회상할 수 있을 때까지 반복 학습하는 것이 효과적입니다.

​

의존성 파악의 중요성

복잡한 문제를 풀 때, 문제의 구성 요소들 간의 상호 의존성을 파악하는 것이 핵심입니다. 의존성이 적으면 각 부분을 순차적으로 배우고 해결할 수 있습니다. 의존성이 많으면 여러 부분을 동시에 이해해야 하므로 내재적 부하가 증가합니다.

​

생각의 오류: 버그의 심리학적 원인

버그는 단순히 코드 실수만이 아닙니다. 우리의 잘못된 가정과 오류적 사고(Misconceptions)가 버그를 만듭니다.

​

전이(Transfer)와 오류

새로운 언어를 배울 때, 기존 언어의 지식이 도움이 될 수도 있고 방해가 될 수도 있습니다.

• 긍정적 전이: 기존 지식이 새로운 학습을 촉진합니다. Python에서 JavaScript로 전환할 때, 루프와 조건문의 개념은 쉽게 적용됩니다.
• 부정적 전이: 기존 지식이 새로운 학습을 방해합니다. Java의 null 처리 방식을 Python에 적용하려 하면 오류가 발생할 수 있습니다.

​

시맨틱 웨이브(Semantic Wave): 효과적인 학습 곡선

새로운 개념을 배울 때 효과적인 학습 곡선이 있습니다:

1. 이해(Understanding): 먼저 일반적인 개념을 이해합니다. 예: "가변 인수 함수는 필요한 만큼의 매개변수를 수용할 수 있다"
2. 포장(Unpacking): 곡선의 저점에서 구체적인 세부 사항을 배웁니다. Python의 *args 문법, JavaScript의 rest parameter 등을 배웁니다.
3. 재포장(Repacking): 다시 일반적인 개념 수준으로 돌아가 그것의 유용성과 실제 적용을 이해합니다.

​

명확한 명명의 힘

변수명, 함수명, 클래스명은 단순한 식별자가 아닙니다. 우리 뇌가 코드를 이해하는 방식에 직접적인 영향을 미칩니다.

​

명확한 이름이 중요한 이유

명확한 이름은 LTM의 적절한 정보를 검색하는 데 효과적인 단서가 됩니다. 함수 이름이 process()일 때보다 validateUserEmail()일 때, 우리 뇌는 더 정확하게 관련 정보를 인출합니다. 결과적으로:

• 코드 읽기 속도 증가: 복잡한 분석 없이 의도가 명확합니다.
• 버그 감소: 명확한 이름의 코드에는 버그가 더 적습니다. 실제로 연구에 따르면, 명확한 명명 규칙을 따르는 코드는 버그가 적습니다.
• 유지보수 용이성: 새로운 개발자가 코드를 이해하기 쉬워집니다.

​

좋은 변수명의 세 단계 모델

변수명을 정할 때 고려해야 할 요소들이 있습니다:

• 이름이 무엇을 나타내는가? (what) - 변수가 어떤 데이터를 담는가?
• 그것이 왜 그 이름인가? (why) - 비즈니스 맥락에서 그 이름이 의미하는 것은?
• 어떤 역할을 하는가? (role) - 코드의 흐름에서 이 변수의 역할은?

​

나쁜 코드와 인지 부하: 두 가지 프레임워크

코드베이스를 개선하기 위해 두 가지 프레임워크가 있습니다.

​

첫 번째: 외재적 부하 감소

코드 자체를 간단하고 명확하게 만들기:

• 명확한 변수명 사용
• 함수의 크기 줄이기 (한 번에 이해 가능한 범위)
• 깊은 중첩 제거
• 중복 코드 제거 (DRY)
• 좋은 문서화 제공

​

두 번째: 멘탈 모델 구축 지원

학습자나 새로운 팀원이 효과적으로 LTM에 지식을 저장할 수 있도록 지원:

• 패턴 명시적 설명
• 단계별 학습 자료 제공
• 포커스 포인트 제시
• 점진적 복잡성 증가

​

새로운 개발자 온보딩: 인지과학 기반 접근

새로운 팀원을 빠르게 생산적으로 만드는 것은 인지과학적 이해가 필수입니다.

​

온보딩의 세 가지 활동

1. 전사(Transcription): 명확한 지시를 받으며 특정 기능을 구현합니다. 이 단계에서는 세부 사항을 수행하는 것에 집중합니다.
2. 탐색(Exploration): 코드베이스의 특정 부분을 탐색하며 전체 작동 방식을 파악합니다.
3. 이해(Comprehension): 클래스나 함수를 자연언어로 설명할 수 있을 정도로 깊이 있게 이해합니다.

​

STM과 LTM 동시 지원

효과적인 온보딩은 두 가지를 동시에 제공해야 합니다:

• LTM 지원: 중요한 도메인 개념, 사용된 기술, 아키텍처 패턴 등 배경 정보 제공
• STM 지원: 동시에 여러 활동을 하지 않도록 단계를 나누고, 집중할 수 있는 작업 준비

방해(Interruption)를 최소화하는 것도 중요합니다. 심층적 업무 중 방해를 받으면 뇌가 다시 집중하는 데 매우 많은 시간이 필요합니다.

​

실제 코드 작성: 효율성과 정확성

코드 작성 행동 자체도 인지과학적으로 분석할 수 있습니다.

​

작업 중단의 영향

개발 중 자주 중단되면 생산성이 생각보다 훨씬 떨어집니다. 뇌가 다시 작업에 집중하는 데 필요한 "재입장 비용"이 상당합니다. 따라서:

• 집중력이 필요한 작업은 연속적인 시간 확보
• 슬랙, 메일 등 주기적 확인으로 중단 최소화
• 팀 문화상 깊이 있는 작업 시간 보호

​

자동화와 암시적 기억

특정 코딩 패턴을 충분히 많이 반복하면, 그것이 자동화되어 작업 기억 공간의 부하를 줄입니다. 이것을 "암시적 기억" 형성이라 합니다. 경험이 쌓일수록 이 자동화 영역이 커져서, 더 복잡한 문제에 인지 자원을 집중할 수 있습니다.

​

큰 시스템 설계 및 개선

대규모 코드베이스를 다룰 때, 인지과학적 원칙을 적용하면 전체 시스템을 더 이해하기 쉽게 만들 수 있습니다.

​

아키텍처의 인지 부하

아키텍처 결정 자체가 팀의 인지 부하를 결정합니다:

• 높은 응집도, 낮은 결합도: 이 원칙은 외재적 부하를 줄입니다. 각 모듈을 독립적으로 이해할 수 있기 때문입니다.
• 계층적 구조: 복잡한 시스템을 여러 추상화 수준으로 나누면, 한 번에 이해해야 할 범위가 줄어듭니다.
• 명확한 경계: 어느 부분이 어디서 끝나는지 명확하면, 포커스 포인트를 설정하기 쉽습니다.

​

문서화의 역할

단순히 "코드는 최고의 문서"라는 신화를 벗어나야 합니다. 명확한 문서화는 새로운 개발자의 LTM 형성을 직접 지원합니다. 특히:

• 왜 이 아키텍처를 선택했는가?
• 각 모듈의 책임은 무엇인가?
• 어떤 도메인 개념이 중요한가?

이러한 정보는 코드만으로는 명확하지 않습니다.

​

결론: 뇌를 이해하면 코드가 보인다

『프로그래머의 뇌』의 핵심 메시지는 간단합니다. 프로그래밍의 어려움은 코드 때문이 아니라, 우리의 뇌가 어떻게 작동하는지 모르기 때문입니다.

이 책을 통해 배운 인지과학적 원칙들을 적용하면:

• 주니어 개발자는 자신이 느끼는 어려움이 "원래 그렇게 작동한다"는 것을 알게 되어, 불필요한 자책을 줄일 수 있습니다.
• 시니어 개발자는 팀원을 더 잘 이해하고, 코드베이스를 더 효율적으로 설계할 수 있습니다.
• 모든 개발자는 새로운 언어나 프레임워크를 더 빠르게 배우고, 코드를 더 깊이 있게 이해할 수 있습니다.

​

프로그래밍 스킬을 향상시키고 싶다면, 컴퓨터 과학이 아니라 우리의 뇌 과학부터 이해해야 합니다. 이것이 펠리너 헤르만스가 우리에게 전하는 혁신적인 메시지입니다.