코드 문법을 둘러싼 은근한 신경전
프로그래밍 언어에 새 기능이 하나 추가된다고 해봐요. 그럼 개발자들 사이에서 꼭 이런 논쟁이 벌어져요. “이건 무슨 일을 하는지 딱 보이게 길고 명확하게 써야 해!” vs. “아니 왜 이렇게 길게 써, 짧게 줄이자!” 이 밀당, 사실 아무렇게나 벌어지는 게 아니라 나름의 규칙이 있어요. 그걸 정리한 게 바로 스트롭스트룹의 법칙(Stroustrup’s Rule)이에요. C++를 만든 비야네 스트롭스트룹이 한 말인데요.
법칙은 이렇게 요약돼요. “새로운 기능에 대해서는 사람들이 요란할 만큼 명시적인 문법을 원하고, 자리 잡은 기능에 대해서는 간결한 문법을 원한다.”
왜 이런 일이 벌어질까요
이게 뭐냐면, 사람 심리랑 딱 맞아떨어져요. 낯선 기능을 처음 볼 땐, 코드만 봐서는 이게 무슨 일을 하는지 감이 안 오잖아요. 그래서 문법이 길고 장황하더라도 “여기서 이런 일이 벌어집니다!”라고 대놓고 알려주는 편이 안심돼요. 읽는 사람을 위한 배려인 거죠.
그런데 그 기능을 몇 년씩 매일 쓰다 보면 이야기가 달라져요. 이미 다들 아는 내용을 매번 장황하게 타이핑하는 게 귀찮아지거든요. 그때부턴 “아 좀 줄여줘, 다 아는 건데” 하는 마음이 커져요. 그래서 익숙해진 기능일수록 짧고 간결한 표기를 원하게 되는 거예요.
언어의 역사가 증명해요
실제 예를 보면 무릎을 치게 돼요. 예전엔 변수 타입을 일일이 다 적어야 했어요. int x = 10;처럼요. 그런데 타입이라는 개념이 완전히 익숙해지자, 이제는 컴파일러가 알아서 타입을 추론해주는 auto x = 10;(C++), var(자바), let(러스트) 같은 간결한 문법이 대세가 됐죠. 처음 나왔을 땐 “타입을 숨기면 코드 읽기 힘들다!”고 반대하는 사람이 많았는데, 익숙해지니까 다들 자연스럽게 받아들였어요.
람다(익명 함수)도 마찬가지예요. 처음 등장했을 땐 문법이 꽤 복잡하고 명시적이었는데, 지금은 화살표 하나(=>, ->)로 슥 넘어가는 간결한 형태가 표준이 됐죠. 이 패턴이 언어 역사에서 계속 반복되는 거예요.
이 법칙을 어떻게 써먹을까요 — Hillel Wayne의 통찰
이 글을 쓴 힐렐 웨인은 여기서 한 걸음 더 들어가요. 이 법칙의 핵심은 결국 ‘읽기’와 ‘쓰기’의 이해관계가 다르다는 데 있다는 거예요. 명시적이고 장황한 문법은 읽는 사람(특히 그 기능에 낯선 사람)에게 유리하고, 간결한 문법은 쓰는 사람(이미 익숙한 사람)에게 유리해요. 기능이 새것에서 익숙한 것으로 넘어갈수록, 저울추가 ‘읽기 편함’에서 ‘쓰기 편함’ 쪽으로 옮겨가는 거죠.
그래서 이건 단순한 우스갯소리가 아니라, 언어 설계자에게 “새 기능은 일부러 좀 시끄럽게(명시적으로) 내놓고, 자리를 잡은 뒤에 조용하게(간결하게) 다듬어라”는 실전 지침이 돼요. 물론 항상 들어맞는 건 아니고 반례도 있지만, 문법 논쟁이 벌어질 때 “지금 이 기능은 새것이라 명시적인 게 맞나, 익숙한 거라 줄이는 게 맞나?”를 가늠하는 좋은 잣대가 되는 거예요.
우리 실무에도 통해요
이건 언어 설계자만의 이야기가 아니에요. 팀에서 코드 리뷰를 하거나 사내 라이브러리·API를 설계할 때도 똑같이 적용돼요. 팀원들이 아직 낯설어하는 새 패턴이라면, 조금 장황하더라도 의도가 훤히 드러나게 쓰는 게 나아요. 반대로 모두가 손에 익은 관용구라면 과감히 줄여서 잡음을 없애는 게 좋고요. “명시적인 게 무조건 좋다”거나 “짧은 게 무조건 좋다”가 아니라, 팀의 익숙함 정도에 따라 답이 달라진다는 걸 알려주는 거죠.
마무리
한 줄 정리: “낯선 것은 시끄럽게 설명하고, 익숙한 것은 조용히 줄여라 — 문법의 좋고 나쁨은 ‘얼마나 익숙하냐’에 달려 있다.”
여러분이 쓰는 언어나 프레임워크에서 “처음엔 장황했는데 이제는 간결해진” 문법, 어떤 게 떠오르세요? 반대로 “아직도 너무 장황해서 빨리 줄었으면” 하는 문법도 있나요?
🔗 출처: Hacker News