4부: 협업하는 두뇌 — 코드 작성, 시스템 설계, 온보딩

프로그래밍은 하나의 활동이 아니다

우리는 흔히 "코딩"을 단일한 활동으로 묶어 말하지만, 실제로 개발자가 하루에 수행하는 프로그래밍 관련 작업은 종류가 다양하다. 헤르만스는 이를 다섯 가지 활동으로 분류한다.

이 분류가 유용한 이유는, 활동마다 인지적으로 요구하는 것이 다르기 때문이다. 이해 작업 중에 전사를 강요받으면(예: 갑작스러운 기능 추가 요청) 두 활동이 충돌해 품질이 낮아진다.

인터럽트: 작업 기억의 적

중단이 초래하는 인지적 비용

업무 중단(Interruption)은 생산성 저하의 가장 큰 원인 중 하나다. Slack 알림, 회의 소집, 갑작스러운 버그 수정 요청이 코딩 흐름을 끊을 때 단순히 멈추는 것 이상의 비용이 발생한다.

작업 기억 공간에 유지되던 맥락 — 추론 중이던 알고리즘, 관련 변수들의 상태, 설계 의도 — 이 중단과 함께 소실되기 때문이다. 연구에 따르면 방해받은 후 원래 작업의 맥락을 완전히 회복하는 데 평균 23분이 걸린다고 한다.

중단 후 복귀를 돕는 기법

헤르만스는 중단 전에 다음 작업을 메모해두는 방법을 제안한다. 코드에 // TODO: 다음은 이 함수에 null 체크 추가 같은 주석을 남기거나, 짧은 메모를 작성해두면 복귀 시 작업 기억을 처음부터 재구성하지 않아도 된다.

이는 GTD(Getting Things Done) 방법론에서 "열린 루프를 닫아라"고 말하는 것과 같은 맥락이다. 중단 직전 상태를 외부 저장소에 옮겨두면 두뇌가 그것을 지속적으로 유지하는 데 쓰는 에너지를 아낄 수 있다.

대규모 시스템 설계와 인지 부하

12장은 설계 결정이 코드베이스의 이해도에 미치는 영향을 다룬다. 아키텍처 결정은 기능 요구사항뿐 아니라 미래의 유지보수자가 코드를 이해하는 인지적 비용을 고려해야 한다.

결합도와 인지 부하

높은 결합도(tight coupling)는 외재적 인지 부하를 높이는 주요 원인이다. 클래스 A를 이해하기 위해 클래스 B, C, D도 동시에 파악해야 한다면, 작업 기억 공간은 여러 모듈을 동시에 유지해야 한다.

반면 낮은 결합도와 높은 응집도(low coupling, high cohesion)는 모듈을 독립적으로 이해할 수 있게 해준다. 한 클래스를 열었을 때 그 안에서 대부분의 문맥이 해결된다면, 외재적 인지 부하가 낮다.

코드 구조화를 위한 인지적 관점

계층 분리(레이어드 아키텍처), 모듈 경계 명확화, 인터페이스 추상화는 모두 아키텍처 원칙이기도 하지만, 동시에 읽는 사람의 청킹을 돕는 인지 설계이기도 하다. "레포지토리 패턴"을 아는 개발자는 UserRepository 클래스를 열기 전에 이미 그 역할을 하나의 청크로 처리한다.

새 팀원 온보딩: 인지적 관점

온보딩에서 흔히 발생하는 문제

새 팀원이 코드베이스에 적응하는 데 어려움을 겪는 가장 큰 이유 두 가지는 다음과 같다.

1. 선임 개발자가 너무 많은 정보를 한꺼번에 준다. 이는 STM의 용량 제한을 무시한 접근이다. "이 프로젝트는 마이크로서비스로 구성되어 있고, 서비스 간 통신은 gRPC를 쓰고, 인증은 OAuth2이고..."는 처음 몇 분 만에 작업 기억을 포화시킨다.

2. 새 팀원이 관련 청크를 LTM에 갖고 있지 않다. 도메인 용어, 코드베이스 관용구, 팀 내 비공식 규칙 등은 코드를 읽는 것만으로는 쌓이지 않는다.

신피아제주의 프레임워크

장 피아제의 발달 이론에 기반한 신피아제주의(Neo-Piagetian Theory)는 새로운 정보를 마주할 때 사람이 거치는 단계를 설명한다. 성인도 완전히 새로운 도메인을 접할 때 이 단계를 거친다.

새 팀원은 처음에 코드를 구체적으로 따라가는 것(구체적 조작기)부터 시작해, 점차 코드베이스 전체의 패턴을 추상적으로 이해하는 수준(형식적 조작기)으로 발전한다. 이 단계를 건너뛰려 하면 오히려 습득이 느려진다.

효과적인 온보딩 설계

헤르만스는 온보딩 과제를 다섯 범주로 배분하기를 권장한다.

온보딩의 한계는 현실적이다. 책이 제안하는 절차가 체계적으로 이루어지기 위해서는 선임 개발자의 시간과 에너지, 팀의 프로세스 성숙도가 필요하다. 사람마다 학습 속도와 방식이 다르다는 점, 어느 시점에서 성장이 정체되는 경우도 있다는 점은 인지 프레임워크만으로 해결되지 않는다.

종합 리뷰: 책이 남긴 것과 남기지 못한 것

이 책이 잘 하는 것

인지과학의 언어를 제공한다. "왜 이 코드가 읽기 어려운가"를 STM, 청킹, 인지 부하라는 개념으로 설명할 수 있게 된다. 이 언어는 코드 리뷰, 설계 논의, 온보딩 계획을 위한 공통 어휘가 된다.

"경험을 쌓아라"에 근거를 붙인다. 숙련 개발자가 왜 코드를 더 빨리 파악하는지, 왜 특정 습관이 효과적인지를 LTM과 청킹으로 설명한다. "그냥 많이 짜다 보면 늘어"보다 인지과학적으로 근거 있는 설명이다.

코드 품질을 인지적 효율성으로 재해석한다. 좋은 이름, 낮은 결합도, 적절한 추상화가 단순한 미학이 아니라 읽는 사람의 인지 비용을 낮추는 실용적 이유가 있다는 것을 설명한다.

이 책이 아쉬운 것

처방들의 현실 적용성이 낮다. 플래시카드, 인지적 리팩터링, 변수 역할 표기를 팀 전체가 채택하는 것은 상당한 조직적 노력을 필요로 한다. 책은 "이것이 효과적이다"를 주장하지만, 현실적인 도입 장벽을 충분히 다루지 않는다.

AI 보조 개발 시대와의 괴리가 크다. 문법을 플래시카드로 외우라는 조언이나, 복잡한 코드를 손으로 상태표로 추적하라는 제안은 AI 자동 완성과 인터랙티브 디버거가 보편화된 환경에서 시대착오적으로 느껴진다. 책의 출판 연도(2021)를 감안해도 이 부분의 실용성은 제한적이다.

근거 인용과 실전 적용 사이의 간극이 있다. 체스 실험, fMRI 연구, 에빙하우스 망각 곡선 등 풍부한 학술 근거를 인용하지만, 이것이 실제 개발 업무에서 어떻게 작동하는지에 대한 현장 사례가 부족하다.

마치며

이 책을 읽으면서 가장 인상 깊었던 것은 "좋은 코드란 무엇인가"라는 오래된 질문에 대한 인지과학적 답변이다. 외재적 인지 부하를 낮추는 코드가 좋은 코드다. 이 단 하나의 명제가 변수명, 함수 크기, 추상화 수준, 주석, 패턴 사용 등 수십 가지 코드 품질 지침을 하나의 원리로 통합한다.

실무에서 이 책의 언어를 활용하는 가장 현실적인 방법은, 코드 리뷰 피드백을 줄 때 "인지 부하"와 "청킹" 개념을 근거로 삼는 것이다. "이 함수가 너무 길어요"보다 "이 함수는 STM 용량을 초과하는 맥락 추적을 요구합니다"가 더 설득력 있고, 개선 방향도 명확해진다.