숨기지 말고 드러내놓고 하라고

 

지난 2025년 8월 9일에 Linux Kernel Mailing List에 Linus Torvalds가 쓴 메시지가 흥미롭다

https://lore.kernel.org/lkml/CAHk-=wjLCqUUWd8DzG+xsOn-yVL0Q=O35U9D6j6=2DUWX52ghQ@mail.gmail.com/

 

Linus는 Pull Request를 reject하면서, PR을 일찍 보냈니 늦게 보냈니 등등 말하지만 다 떠나서 가장 재밌었던 부분은 "그냥 드러내도 쉽게 읽히는 걸 helper function 뒤에 숨기지 마라"는 부분이었다.

 

And by "garbage" I really mean it. This is stuff that nobody should ever send me, never mind late in a merge window.

Like this crazy and pointless make_u32_from_two_u16() "helper".

That thing makes the world actively a worse place to live. It's useless garbage that makes any user incomprehensible, and actively *WORSE* than not using that stupid "helper".

If you write the code out as "(a << 16) + b", you know what it does and which is the high word. Maybe you need to add a cast to make sure that 'b' doesn't have high bits that pollutes the end result, so maybe it's not going to be exactly _pretty_, but it's not going to be wrong and incomprehensible either.

In contrast, if you write make_u32_from_two_u16(a,b) you have not a f%^5ing clue what the word order is. IOW, you just made things *WORSE*, and you added that "helper" to a generic non-RISC-V file where people are apparently supposed to use it to make *other* code worse too.



그리고 "쓰레기"라고 한 것은 진심이다. 이딴거는 늦게건 빨리건 아무도 나한테 보내지 마라.

특히 이 미친 무의미한 make_u32_from_two_u16() "helper" 말이다.

저건 대놓고 세상을 더 나쁜 곳으로 만들겠다는 것이다. 이 쓸모없는 쓰레기는 어떤 사용자도 이해할 수 없고, 그 멍청한 "helper"를 쓰지 않는 것보다 *훨씬 나쁜* 수정이다.

그냥 "(a << 16) + b" 이면 이게 무슨 일을 하고 어디가 high word인지 분명하다. 'b'에 high bits 있으면 최종 결과 문제되니까 없도록 아마 cast 추가해야 할 테니까 엄밀히 말해서 예쁜 코드가 되진 않겠으나, 이 방식으로는 잘못되거나 이해할 수 없게 되지는 않는다.

반면에 make_u32_from_two_u16(a,b)를 작성하면 뭐가 high word고 low word인지 ㅈ도 알 수가 없잖아. 즉, 당신은 상황을 그냥 *나쁘게*만 만든 게 아니라 그 놈의 "helper"를 일반적인 non-RISC-V 파일에도 추가해서 *다른* 코드마저도 더 나쁘게 만들어지도록 한 셈이다.

 

 

어휴 상남자..

 

 

 

문제의 'helper'는 두 개의 16bit integer a와 b가 있을 때 a를 high word, b를 low word로 하여 32bit integer로 뽑아내는 일을 한다.

 

그런데 굳이 별도의 function은 불필요해보인다. 예를 들어 a = 0x1234, b = 0xABCD일 때, 그것들로부터 1234ABCD를 원한다면 가장 직관적인 방식은 a를 16자리 올려보내는 것이다. a<<16 = 0x12340000 이렇게. 이제 밑에 4자리가 비었으니 그냥 b를 더하면 될 일이다. 굳이 별도의 'helper'를 쓰지 않아도 된다.

 

그나저나 나는 왜 언어학 블로그에 이걸 쓰고 있느냐? 하면, "겉으로 드러내서 하면 이해도 쉽고 잘못됐을 때 딱 드러나잖아! helper뒤에 숨어서 하지 마!" 라는 일갈(?)을 보며 Distributed Morphology 생각이 나서이다.

 

Marantz (1997)는 제목부터가 "형태론을 숨기지 말고 해"였다. "Don't try mophological analysis in the privacy of your own lexicon"

 

통사론을 아주 쉽게 하는 방법은, 설명하기 곤란한 모든 것들을 다 어휘부(렉시콘)에서 결정되어 나온다고 주장하는 것이다. 그 정도까진 아니더라도 "이건 왜그러냐면 통사론과 다른 논리가 적용되는 형태부에서 🧙신비롭게🧙 쨘 나와서 그런거다"라고 결론지으면 쉽다. 그렇게 하면 발뻗고 잠이 오려나 모르겠지만..

 

그런데 그러면 안 된다. 어휘부는 진짜 말그대로 최후의 보루여야 한다. 대부분의 '형태론'은 통사부와 같은 computational system이다 그니까 helper뒤에 숨기지 말고 밖으로 빼내서 해라 😂😂.... 이게 분산형태론이다 (아마도..? 사실 매우 거칠게 일반화해서 자신이 없음)

 

다시 리눅스 커널 얘기로 돌아와서, `make_u32_from_two_u16(a, b)`를 쓰면, 밖에서 보기에 무엇이 high word인지 알 수 없기에 "더 나쁜" 방향이다. 아마도 Distributed Morphology도 비슷한 철학일 것이다. 숨겨서 하는 건 "더 나쁜" 방향이다.

 

그리고, 불행인지 다행인지 모르겠지만 통사론은 리눅스 커널 개발처럼 중앙집권(?)식은 아닌 듯하다.ㅋㅋㅋㅋㅋ 촘스키 할아버지가 더 에너지가 있었더라도 Linus 처럼 반응하지는 않았을 것이다.

 

 

 

---

이어서 어떤 글을 읽을 건가요?

 

---

• 글이 유익했다면 후원해주세요 (최소100원). 투네이션 || BuyMeACoffee (해외카드필요)
• 아래 댓글창이 열려있습니다. 로그인 없이도 댓글 다실 수 있습니다.
• 글과 관련된 것, 혹은 글을 읽고 궁금한 것이라면 무엇이든 댓글을 달아주세요.
• 반박이나 오류 수정을 특히 환영합니다.
• 로그인 없이 비밀글을 다시면, 거기에 답변이 달려도 보실 수 없습니다. 답변을 받기 원하시는 이메일 주소 등을 비밀글로 남겨주시면 이메일로 답변드리겠습니다.

---