GNU 버전의 Yacc은 Bison이라 불림. Pine은 “Pine Is Not Elm”의 약자였고, UNIX는 MULTICS의 말장난으로 UNICS에서 유래했음. dd는 무슨 뜻인지 모르겠고, nano는 pico의 복제판이며, Postfix는 ‘post’와 ‘bug fix’를 합친 말임. C++은 C의 증분 버전이고, C는 B의 후속, B는 BCPL의 후속임. 사실 개발자들은 ‘이름 짓기의 철학’을 잃은 게 아니라 애초에 없었음. 반대로 Clang, LLDB, jq, fzf, loc 같은 현대 프로젝트들은 좋은 이름의 예시라고 생각함. mise-en-place는 mise의 기능을 완벽히 비유함
dd는 JCL의 DD 문장에서 유래했음. 원래는 IBM 메인프레임의 파일 기술 방식에서 따온 것으로, UNIX의 dd 명령은 메인프레임과 파일을 교환하기 위해 만들어졌음. 그래서 UNIX답지 않게 key=value 형식의 문법을 가지게 되었음
dd는 전통적으로 “delete disk”나 “destroy data”의 농담으로 불렸음. 실제로 디스크 블록을 덮어쓸 때 자주 사용되었기 때문임
C++은 C의 후위 증가 연산자를 의미함. 즉, C와 같은 값을 가지지만 읽은 후에 증가한다는 완벽한 은유임
GNU, Emacs도 재귀적 약자임. Perl, Python, Java, Go, Pascal, Git, Mercurial, CVS 등도 이름의 의미가 제각각임. 결국 이름 논쟁은 별 의미 없는 소란이라고 생각함
grep, awk, sed, cat, diff 등 UNIX 명령어들은 기능적이거나 체계적인 이름이었지만, 사실 diff 정도만 직관적으로 추측 가능함. awk를 좋은 이름이라 칭하는 건 과장임
이런 이름들이 자연스럽게 느껴지는 건 익숙함의 착각일 뿐임. 지금은 수많은 유틸리티와 라이브러리가 존재하므로, 이름의 차별화가 필수임
Libiberty는 가장 웃긴 이름 중 하나였음. -liberty 옵션으로 링크할 수 있게 지은 이름임
cat은 concatenate의 축약형이 아니라 catenate에서 온 것임. ‘con’ 접두사는 중복이라 생략된 형태임. 언어학적으로도 흥미로운 예시임
awk, sed, cat은 좋은 이름이라기보다 익숙한 이름일 뿐임. grep은 오히려 의성어처럼 들려서 패턴을 ‘잡아내는’ 느낌이 있음
이런 약어나 축약어는 산업별 전문용어처럼, 한 번 배우면 자연스러워짐. 예전엔 타이핑 효율이 중요했기 때문에 cat vs concat의 차이가 생산성에 영향을 줬음
“기술 분야에서 이런 이름 짓기는 커리어 자살”이라는 주장에 반박함. 미국 국방부 코드명 목록을 보면, 오히려 의도적으로 불투명한 이름이 많음. Hoover Dam도 처음엔 Boulder Canyon Project로 불렸고, 이름이 기능을 설명하지 않음. Requests보다 Reitzlib이 더 나은 이름일까? 결국 이름은 맥락에 따라 다름
화학에서도 재미있는 이름이 많음. 예를 들어 SHAKE, RATTLE, CHARMm, Amber 같은 알고리즘이나 패키지들이 있음. 귀여운 이름은 생물학 분야에서 더 흔함
awk 같은 이름은 사실 좋은 이름이 아님. 단순히 저자 이니셜일 뿐이며, 기능을 전혀 전달하지 않음. 요즘은 탭 자동완성이 있으니 굳이 짧게 줄일 필요도 없음
나는 이 반론 글에 공감함. 외부 식별자는 시간이 지나면 의미가 변하므로, 처음부터 정확히 묘사하는 이름은 오래 못 감. 게다가 “X Manager”, “X Service” 같은 이름이 너무 많아 구분이 어려움
나는 기발한 이름을 좋아함. 이름 짓기 어렵다면 개념이 명확하지 않다는 신호임. 이상적인 이름은 처음엔 이상하지만, 나중에 의미를 알면 기억에 남는 이름임. Spotify의 A/B 테스트 팀이 자신들을 “ABBA”라 부른 건 최고의 예시임
물론 목표에 따라 다름. 하지만 한 가지 일에 집중하고, 그 일을 이름에 담는 것도 좋은 원칙임
나는 자동차 OEM에서 엔진 보정 엔지니어로 일했는데, 모든 변수와 함수가 약어로 되어 있었음. 처음 한 달은 머리가 터질 정도로 피곤했음. 결국 동료가 “이건 새로운 언어를 배우는 것과 같다”고 말했는데, 정말 그랬음. 즉, 기술적 이름이 많다고 인지 부하가 줄어드는 건 아님
모바일 통신 분야에서도 마찬가지임. 모든 약어를 외우려 하면 끝이 없음. 예를 들어 AP가 Application Processor인지 Access Point인지 맥락에 따라 다름. 그래도 MSISDN보단 짧아서 쓸 수밖에 없음
런던 택시 자격시험 영상을 보면, 사람의 뇌 구조가 실제로 바뀔 정도로 학습 피로가 크다고 함. 복잡한 명칭 체계는 본질적으로 인지적 부담을 줌
“기능적 이름이 마케팅보다 낫다”는 주장에 동의하기 어려움. 기능 기반 이름은 결국 끝없는 약어의 바다를 만든다. ABDC와 ADBC를 헷갈리는 상황이 생김
나도 그런 조직에서 일했는데, 결국 CoreMainHttp와 MainHttpCore 같은 이름이 생기고, 심지어 같은 이름의 다른 API가 공존함. “DataOrgUtils”처럼 사라진 조직명이 남기도 함. 결국 귀여운 이름도 반복적으로 수렴함. Phoenix, Keymaster, Simpsons, Star Wars 같은 문화적 밈이 반복됨
저자는 도구들이 경쟁을 거쳐 살아남았다는 점을 간과함. 기억에 남는 이름은 생존에 도움이 되었음
HN에 이런 글이 올라온 게 신기함. awk 같은 이름을 예로 들며 “이름 짓기의 본질을 잃었다”고 주장하는 건 모순임. 결국 귀여운 이름에 대한 개인적 반감으로 보임. 참고로 이 댓글은 Firefox에서 작성했음 — 이름만 봐도 웹 브라우저임을 알 수 없음
awk 같은 이름도 당시엔 나름 의미가 있었음. 현대 소프트웨어는 더 넓은 사용자층을 고려하므로, 전문성과 재미의 균형이 필요함. 귀여운 이름을 싫어하는 건 아니지만, 다만 직업적 맥락에서는 신중해야 함. (이 댓글은 msmtp로 보냄 — 이름처럼 기능을 설명하는 SMTP 클라이언트임)
“설명적인 이름은 지루하다”는 주장에 대해, 수술실의 도구들도 사실 사람 이름을 따서 만들어졌음. Adson, Allis, Babcock, Kocher 같은 이름은 기능을 전혀 설명하지 않음. 결국 익숙해지면 의미가 생김. awk는 별로지만 diff는 괜찮은 예시임
Kirchner 핀을 몸에 박아본 사람이라면 이 말에 공감할 것임
“우리 분야는 무작위 명사들의 동물원 같다”는 주장에 대해, 나는 재미있는 이름을 좋아함. 내 프로젝트 Wimsey는 데이터 테스트 라이브러리지만 이름만 봐선 모름. 그래도 Python, Cron, Zellij처럼 사랑과 유머가 담긴 이름이 좋음. 기술은 결국 사람이 만드는 것이고, 즐거움이 있어야 함. “brown-dog-2”보단 “cookie”가 더 인간적임
하지만 “data-testing-library” 같은 이름은 두 번째가 생기는 순간 의미를 잃음
.NET의 Project.Parser.Pcapng 같은 구조적 이름은 프로젝트 내부에선 좋지만, 독립적 맥락에서는 쓸모없음
반대로, 어떤 사람들은 전문성 자체에서 즐거움을 느끼며, 귀여운 이름을 산만하다고 여김. 장인정신에서 오는 만족이 진짜 즐거움이라는 시각도 있음
Hacker News 의견들
GNU 버전의 Yacc은 Bison이라 불림. Pine은 “Pine Is Not Elm”의 약자였고, UNIX는 MULTICS의 말장난으로 UNICS에서 유래했음. dd는 무슨 뜻인지 모르겠고, nano는 pico의 복제판이며, Postfix는 ‘post’와 ‘bug fix’를 합친 말임. C++은 C의 증분 버전이고, C는 B의 후속, B는 BCPL의 후속임. 사실 개발자들은 ‘이름 짓기의 철학’을 잃은 게 아니라 애초에 없었음. 반대로 Clang, LLDB, jq, fzf, loc 같은 현대 프로젝트들은 좋은 이름의 예시라고 생각함. mise-en-place는 mise의 기능을 완벽히 비유함
key=value형식의 문법을 가지게 되었음grep, awk, sed, cat, diff 등 UNIX 명령어들은 기능적이거나 체계적인 이름이었지만, 사실 diff 정도만 직관적으로 추측 가능함. awk를 좋은 이름이라 칭하는 건 과장임
-liberty옵션으로 링크할 수 있게 지은 이름임“기술 분야에서 이런 이름 짓기는 커리어 자살”이라는 주장에 반박함. 미국 국방부 코드명 목록을 보면, 오히려 의도적으로 불투명한 이름이 많음. Hoover Dam도 처음엔 Boulder Canyon Project로 불렸고, 이름이 기능을 설명하지 않음. Requests보다 Reitzlib이 더 나은 이름일까? 결국 이름은 맥락에 따라 다름
awk 같은 이름은 사실 좋은 이름이 아님. 단순히 저자 이니셜일 뿐이며, 기능을 전혀 전달하지 않음. 요즘은 탭 자동완성이 있으니 굳이 짧게 줄일 필요도 없음
나는 이 반론 글에 공감함. 외부 식별자는 시간이 지나면 의미가 변하므로, 처음부터 정확히 묘사하는 이름은 오래 못 감. 게다가 “X Manager”, “X Service” 같은 이름이 너무 많아 구분이 어려움
나는 자동차 OEM에서 엔진 보정 엔지니어로 일했는데, 모든 변수와 함수가 약어로 되어 있었음. 처음 한 달은 머리가 터질 정도로 피곤했음. 결국 동료가 “이건 새로운 언어를 배우는 것과 같다”고 말했는데, 정말 그랬음. 즉, 기술적 이름이 많다고 인지 부하가 줄어드는 건 아님
“기능적 이름이 마케팅보다 낫다”는 주장에 동의하기 어려움. 기능 기반 이름은 결국 끝없는 약어의 바다를 만든다. ABDC와 ADBC를 헷갈리는 상황이 생김
HN에 이런 글이 올라온 게 신기함. awk 같은 이름을 예로 들며 “이름 짓기의 본질을 잃었다”고 주장하는 건 모순임. 결국 귀여운 이름에 대한 개인적 반감으로 보임. 참고로 이 댓글은 Firefox에서 작성했음 — 이름만 봐도 웹 브라우저임을 알 수 없음
“설명적인 이름은 지루하다”는 주장에 대해, 수술실의 도구들도 사실 사람 이름을 따서 만들어졌음. Adson, Allis, Babcock, Kocher 같은 이름은 기능을 전혀 설명하지 않음. 결국 익숙해지면 의미가 생김. awk는 별로지만 diff는 괜찮은 예시임
“우리 분야는 무작위 명사들의 동물원 같다”는 주장에 대해, 나는 재미있는 이름을 좋아함. 내 프로젝트 Wimsey는 데이터 테스트 라이브러리지만 이름만 봐선 모름. 그래도 Python, Cron, Zellij처럼 사랑과 유머가 담긴 이름이 좋음. 기술은 결국 사람이 만드는 것이고, 즐거움이 있어야 함. “brown-dog-2”보단 “cookie”가 더 인간적임