Hacker News 2026.06.29 33

사람 머리는 생각보다 작다 — '유한한 인지'를 전제로 시스템을 설계한다는 것

사람 머리는 생각보다 작다

개발하다 보면 이런 순간 한 번쯤 겪죠. 분명 두 달 전에 내가 짠 코드인데, 다시 열어보니 '이걸 누가 짰지...?' 싶은 순간이요. 자책할 일 아니에요. 사람의 머리는 원래 한 번에 그렇게 많은 걸 담아두지 못하거든요. 심리학에서는 우리가 동시에 붙잡고 굴릴 수 있는 정보 덩어리가 고작 네댓 개 수준이라고 봐요. 이걸 작업 기억(working memory) 의 한계라고 하는데, 바로 이 '사람의 인지에는 명확한 천장이 있다'는 사실을 설계의 출발점으로 삼자는 게 유한한 인지를 위한 엔지니어링(engineering for bounded cognition) 이라는 발상이에요.

복잡함은 늘 우리 머리보다 빨리 자란다

소프트웨어의 골치 아픈 점은, 시스템의 복잡도는 무한히 자라는데 그걸 이해해야 하는 사람의 머리 용량은 그대로라는 거예요. 코드는 매주 늘고 의존성은 얽히고 예외 케이스는 쌓이는데, 그걸 읽는 개발자의 뇌는 진화 안 하잖아요. 그래서 잘 만든 시스템과 못 만든 시스템의 진짜 차이는 '기능이 많냐'가 아니라 '한 사람이 한 번에 머릿속에 담아야 하는 양을 얼마나 줄여줬냐' 에서 갈려요.

여기서 핵심 개념이 인지 부하(cognitive load) 예요. 이게 뭐냐면, 어떤 일을 해내기 위해 머리가 동시에 굴려야 하는 정보의 양이에요. 학계에선 이걸 세 가지로 나눠요. 문제 자체가 원래 어려워서 생기는 부하(이건 어쩔 수 없어요), 코드가 지저분하거나 도구가 불편해서 '괜히' 생기는 부하, 그리고 진짜 학습과 이해에 쓰이는 좋은 부하요. 우리가 엔지니어링으로 공격해야 할 대상은 명확해요. 바로 가운데, '괜히 생기는 부하'를 깎아내는 것 이죠.

그럼 구체적으로 뭘 어떻게 하나

좋은 설계 원칙들은 사실 다 이 '인지 부하 줄이기'로 다시 읽을 수 있어요.

예를 들어 깊은 모듈(deep module) 이라는 개념이 있어요. 인터페이스는 단순한데 그 안에서 복잡한 일을 다 처리해주는 모듈이죠. 쓰는 사람은 '함수 하나 부르면 알아서 된다' 정도만 머리에 담으면 되니까, 내부의 복잡함을 대신 짊어져 줘서 내 인지 부하를 덜어줘요. 반대로 얕고 자잘한 추상화가 잔뜩이면, 그걸 다 기억해야 해서 오히려 머리가 터지죠.

좋은 이름 도 그냥 취향 문제가 아니에요. 변수나 함수 이름이 하는 일을 정확히 말해주면, 우리는 그 구현을 일일이 머릿속에 펼치지 않아도 이름만 보고 넘어갈 수 있어요. 이름이 곧 '머릿속에 안 담아도 되게 해주는 압축'인 셈이죠. 지역성(locality) — 관련된 코드가 가까이 모여 있어서 이 화면 저 파일 왔다 갔다 안 해도 되는 것 — 도 같은 맥락이에요. 코드를 이해하려고 파일 일곱 개를 띄워야 한다면, 그 자체가 작업 기억을 다 잡아먹는 거거든요.

머리 용량이 더 쪼그라드는 순간 — 장애 대응

특히 잊지 말아야 할 게, 사람의 인지 용량은 고정값이 아니라 상황에 따라 더 줄어든다 는 거예요. 새벽 3시에 알림 울려서 깬 채로 장애를 보고 있을 때, 스트레스와 피로로 평소의 절반도 머리가 안 돌아가요. 그래서 '평소 똑똑한 사람이라면 이해할 수 있는' 시스템으론 부족하고, 지치고 당황한 사람도 헤매지 않을 시스템이어야 해요. 명확한 로그, 한눈에 들어오는 대시보드, 따라만 하면 되는 대응 절차서(런북)가 중요한 이유가 여기 있어요. 잘 만든 시스템은 사용자가 똑똑하길 기대하지 않고, 사용자가 멍해진 순간에도 버텨줘요.

한국 개발자에게 주는 시사점

이 관점은 협업과 온보딩에서 특히 힘을 발휘해요. 신입이 우리 코드베이스에 적응 못 하는 게 정말 그 사람 능력 문제일까요, 아니면 한 기능을 이해하려고 머릿속에 스무 가지를 동시에 띄워야 하는 구조 탓일까요? 코드 리뷰에서도 '이거 동작은 하는데, 다음에 읽는 사람이 머리에 담아야 할 게 너무 많지 않아요?'를 기준으로 삼으면 리뷰의 질이 확 올라가요. 똑똑하게 짠 코드보다 머리를 덜 쓰게 해주는 코드 가 팀 전체로 보면 더 좋은 코드인 경우가 많거든요.