프로그램을 짜다 보면 한 줄로 기막히게 줄인 코드나 남들이 쉽게 떠올리지 못할 기발한 풀이를 쓰고 싶어지는 순간이 있습니다. 짧고 영리한 코드는 실력을 보여 주는 증거처럼 느껴지기 때문입니다. 그런데 몇 달 뒤 그 코드에서 오류가 나면, 정작 코드를 쓴 사람조차 무슨 뜻이었는지 한참을 들여다봐야 하는 경우가 많습니다. 이 상황을 날카롭게 짚은 경험칙이 바로 ‘커니핸의 법칙(Kernighan’s Law)’입니다.

커니핸의 법칙이란 쉽게 말해 ‘오류를 찾아 고치는 일은 코드를 처음 쓰는 일보다 두 배 어려우므로, 쓸 수 있는 가장 영리한 방식으로 코드를 짜면 그 코드는 스스로 고칠 수 없게 된다’는 원칙을 의미합니다. 영리함보다 명료함을 앞세우라는 이 조언은 오늘날까지 프로그래머들 사이에서 널리 인용됩니다.

본 자료에서는 커니핸의 법칙이 나온 배경부터 문장에 담긴 뜻, 이 법칙을 둘러싼 오해, 그리고 현장에서 이 법칙을 살리는 방법까지 차례로 살펴보겠습니다.

---

영리한 코드보다 명료한 코드가 오래가는 이유

벨 연구소에서 나온 한 문장

이 문장을 쓴 브라이언 커니핸(Brian Kernighan)은 미국 벨 연구소에서 일한 캐나다 출신 컴퓨터 과학자입니다. 그는 데니스 리치(Dennis Ritchie)와 함께 C 언어의 교과서로 꼽히는 책을 썼고, 유닉스 개발에도 깊이 참여했습니다. 텍스트 처리 언어 awk의 이름에 들어간 세 글자 가운데 K도 그의 성에서 따온 것이며, 2000년부터는 프린스턴대학교에서 학생들을 가르치고 있습니다.

• 출처(The Elements of Programming Style): 1974년 동료 P. J. 플라우거(P. J. Plauger)와 함께 펴낸 「프로그래밍 스타일의 요소」에 이 문장이 실렸습니다.
• 개정판(Second Edition): 1978년 2판이 나왔고, 문제의 문장은 수식과 표현을 다루는 2장에 들어 있습니다.
• 집필 동기(Textbook Examples): 두 저자는 당시 교과서에 실린 엉성한 포트란(FORTRAN)과 PL/I 코드를 하나씩 고쳐 쓰며 좋은 코드의 규칙을 뽑아냈습니다.

책 제목은 글쓰기 지침서로 유명한 「문체의 요소(The Elements of Style)」를 본뜬 것입니다. 좋은 문장이 그렇듯 좋은 코드도 군더더기 없이 뜻이 분명해야 한다는 생각이 책 전체에 깔려 있습니다.

---

두 배 어렵다는 말의 뜻

원문은 ‘누구나 알듯이 디버깅은 처음 프로그램을 짜는 것보다 두 배 어렵습니다. 그러니 짤 때 최대한 영리하게 짰다면, 대체 어떻게 디버깅하겠습니까?’라는 뜻의 두 문장입니다. 여기서 디버깅(Debugging)은 프로그램 속 오류인 버그를 찾아 고치는 일을 말합니다.

(1) 고치는 일은 쓰는 일보다 어렵다
코드를 쓸 때는 머릿속에 의도가 생생하지만, 오류를 찾을 때는 그 의도와 실제 동작이 어디서 어긋났는지 거꾸로 추적해야 합니다. 내가 옳다고 믿었던 부분 어딘가에 잘못이 숨어 있기 때문에 더 힘듭니다.

(2) 영리함을 다 쓰면 남는 힘이 없다
자기 능력의 끝까지 끌어올려 쓴 코드는, 그보다 두 배 어려운 디버깅을 할 때 능력이 모자라게 됩니다. 여기서 두 배는 정확히 잰 수치가 아니라 차이가 크다는 것을 강조한 표현입니다.

(3) 그러니 명료하게 써야 한다
결론은 영리함을 아껴 두라는 것입니다. 처음부터 내 능력의 절반쯤으로 이해할 수 있게 써 두면, 나중에 문제가 생겨도 남은 힘으로 충분히 원인을 찾아낼 수 있습니다. 실제로 같은 책에는 ‘분명하게 써라, 너무 영리하게 굴지 마라(Write clearly – don’t be too clever)’라는 규칙이 함께 실려 있습니다.

---

법칙을 둘러싼 오해

커니핸의 법칙은 짧고 재치 있는 만큼 원래 뜻과 다르게 읽히기도 합니다.

어려운 기술을 쓰지 말라는 뜻일까

이 법칙은 어려운 기술 자체를 금지하는 말이 아닙니다. 꼭 필요한 곳에 정교한 방법을 쓰는 것과, 단순하게 풀 수 있는 문제를 일부러 꼬아 쓰는 것은 다릅니다. 경계해야 할 것은 이해하기 어려운 코드를 자랑삼아 쓰는 습관입니다. 글자 수를 최대한 줄이는 놀이인 코드 골프(Code Golf)는 재미있는 두뇌 훈련이지만, 그런 코드를 실제 서비스에 그대로 넣으면 고치는 사람이 고생하게 됩니다.

커니핸의 지렛대라는 다른 해석

스웨덴의 프로그래머 리누스 오케손(Linus Åkesson)은 이 문장을 ‘커니핸의 지렛대(Kernighan’s Lever)’로 다시 읽었습니다. 자기 실력을 넘는 코드를 고치느라 애쓰는 과정에서 오히려 실력이 자란다는 해석입니다. 다만 이는 배우는 자리에서의 이야기이고, 여럿이 오래 쓰는 코드에서는 원래 조언이 더 안전합니다.

---

현장에서 커니핸의 법칙을 살리는 법

커니핸의 법칙은 코드를 읽기 쉽게 만드는 여러 습관으로 이어집니다.

(1) 읽는 사람을 먼저 생각한다
코드는 한 번 쓰고 여러 번 읽힙니다. 몇 달 뒤의 나나 처음 보는 동료가 바로 이해할 수 있도록 이름을 분명하게 짓고, 한 줄에 너무 많은 일을 몰아넣지 않습니다.

(2) 맞게 만든 다음 빠르게 만든다
같은 책은 ‘빠르게 만들기 전에 먼저 맞게 만들어라’라고 권합니다. 성능을 위해 코드를 비트는 일은 정말 느린 곳을 확인한 뒤에 해도 늦지 않습니다.

(3) 짧은 코드보다 고치기 쉬운 코드를 고른다
요즘은 인공지능 도구가 순식간에 복잡한 코드를 만들어 주지만, 그 코드를 이해하고 고치는 책임은 여전히 사람에게 있습니다. 내가 설명할 수 없는 코드는 그대로 받아들이지 않는 편이 안전합니다.

커니핸은 1979년 글에서 가장 효과적인 디버깅 도구는 여전히 신중한 생각과 적절한 곳에 넣은 출력문이라고도 말했습니다. 화려한 도구보다 차분히 따져 볼 수 있는 단순한 코드가 문제 해결의 바탕이 된다는 뜻입니다.

---

커니핸의 법칙은 실력을 숨기라는 말이 아니라, 실력을 어디에 써야 하는지 알려 주는 조언입니다. 오늘 쓴 영리한 한 줄보다 내일도 술술 읽히는 평범한 열 줄이 결국 더 많은 시간을 아껴 줍니다.

내 머리로 다시 풀 수 있을 만큼만 영리하게 쓰는 일, 그것이 오래가는 코드의 첫걸음입니다.