Hacker News 2026.04.11 37

"코드는 읽히는 것보다 실행되는 횟수가 더 많다" — 가독성 신화에 대한 반론

우리가 당연하게 믿어왔던 것

개발자라면 한 번쯤 이런 말을 들어봤을 거예요. "코드는 작성하는 시간보다 읽는 시간이 훨씬 많으니까, 읽기 좋은 코드를 짜야 한다." 맞는 말이에요. 근데 여기에 한 가지 빠진 관점이 있다는 주장이 나왔어요. 바로 "코드는 읽히는 것보다 실행되는 횟수가 훨씬 더 많다"는 거예요.

이 글의 저자는 "Code is run more than read"라는 제목으로, 개발 문화에서 가독성(readability)에 지나치게 무게를 두다 보니 정작 런타임에서 일어나는 일에 대한 관심이 부족해지고 있다고 지적해요.

가독성 숭배의 그림자

먼저 오해하지 마세요. 이 글은 "가독성이 중요하지 않다"고 말하는 게 아니에요. 가독성은 여전히 중요하죠. 다만, 가독성을 최우선 가치로 놓다 보면 생기는 부작용을 짚는 거예요.

예를 들어볼게요. "읽기 좋은 코드"를 위해 함수를 잘게 쪼개고, 추상화 레이어를 여러 겹 쌓고, 디자인 패턴을 적용하는 건 흔한 일이에요. 코드 리뷰에서도 "이 부분은 가독성이 떨어지니 리팩토링하자"는 피드백을 자주 보죠. 그런데 이렇게 만들어진 코드가 실제로 실행될 때 어떤 일이 벌어지는지는 얼마나 신경 쓰고 있나요?

추상화 레이어가 깊어질수록 함수 호출 스택은 깊어지고, 메모리 할당은 늘어나고, 실행 경로를 추적하기는 오히려 더 어려워져요. 가독성을 위해 도입한 구조가 오히려 디버깅을 어렵게 만드는 역설적인 상황이 생기는 거예요.

"실행되는 코드"의 관점에서 보면

저자가 강조하는 핵심은 이거예요. 코드는 한 번 작성되고, 가끔 읽히지만, 매일 수천 번, 수만 번 실행돼요. 그러니까 코드를 평가하는 기준에 "실행 시 어떤 일이 일어나는가"가 더 높은 비중을 차지해야 한다는 거죠.

이게 뭐냐면, 비유하자면 건축 도면이 아무리 예쁘고 읽기 좋아도, 실제 건물이 흔들리면 소용없는 것과 같아요. 도면(소스 코드)의 가독성도 중요하지만, 건물(실행 중인 프로그램)의 안정성과 성능이 더 근본적이라는 관점이에요.

구체적으로 저자가 제안하는 방향은 이래요. 코드를 작성할 때 "이걸 읽을 다음 개발자가 이해하기 쉬운가?"만 생각하지 말고, "이 코드가 실행될 때 무슨 일이 일어나는가?"를 함께 생각하라는 거예요. 메모리는 얼마나 쓰는지, I/O는 몇 번 일어나는지, 에러가 발생하면 어디서 잡히는지, 로그는 충분한지.

관찰 가능성(Observability)의 중요성

이 논의는 자연스럽게 관찰 가능성(Observability)과 연결돼요. 코드가 읽히는 것보다 실행되는 횟수가 더 많다면, 실행 중인 코드의 상태를 잘 들여다볼 수 있어야 하거든요.

최근 몇 년간 OpenTelemetry, Datadog, Grafana 같은 모니터링·트레이싱 도구가 급속도로 성장한 것도 같은 맥락이에요. 코드를 "읽는" 것만으로는 프로덕션에서 일어나는 일을 이해할 수 없으니까, 실행 중인 코드를 "관찰"할 수 있는 체계가 필요해진 거죠.

저자의 주장을 확장하면, 좋은 코드란 단순히 "읽기 쉬운 코드"가 아니라 "실행 상태를 관찰하기 쉬운 코드"이기도 해요. 적절한 로깅, 메트릭, 트레이싱이 포함된 코드가 프로덕션에서는 오히려 더 "가독성이 좋은" 셈이에요.

기존 논쟁과의 관계

사실 이 주제는 개발 커뮤니티에서 오래된 논쟁이에요. "Clean Code" 진영과 "Performance-first" 진영의 줄다리기라고 할 수 있죠. Robert C. Martin의 클린 코드 원칙이 한쪽 끝에 있다면, Casey Muratori가 주장하는 "Clean Code, Horrible Performance" 비판이 반대편에 있어요.

이 글은 그 스펙트럼 위에서 약간 성능 쪽으로 기울어진 위치에 있는데, 완전히 성능만 챙기자는 극단적 주장은 아니에요. 오히려 균형을 맞추자는 메시지에 가까워요. 가독성이란 렌즈 하나만으로 코드를 바라보지 말고, 실행이라는 렌즈도 함께 쓰자는 거죠.

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

한국 개발 문화에서도 코드 리뷰 때 가독성에 대한 피드백이 많은 편이에요. 변수명, 함수 분리, 주석 등에 많은 시간을 쓰죠. 물론 이건 좋은 문화예요. 하지만 이 글을 읽고 나면 한 가지 질문을 추가해볼 수 있어요. "이 코드가 프로덕션에서 하루에 몇 번 실행되는데, 실행 시의 동작을 내가 정말 이해하고 있나?"

특히 마이크로서비스 환경에서 여러 서비스가 얽혀 있다면, 소스 코드만 읽어서는 전체 그림을 파악하기 어렵거든요. 이럴 때 분산 트레이싱이나 구조화된 로깅(structured logging)을 적극 활용하는 습관이 실무에서 큰 차이를 만들어요.