# 프로그래머와 소프트웨어 개발자들이 도구 이름 짓기에서 길을 잃었다 > Clean Markdown view of GeekNews topic #25024. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25024](https://news.hada.io/topic?id=25024) - GeekNews Markdown: [https://news.hada.io/topic/25024.md](https://news.hada.io/topic/25024.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-12T22:33:23+09:00 - Updated: 2025-12-12T22:33:23+09:00 - Original source: [larr.net](https://larr.net/p/namings.html) - Points: 14 - Comments: 7 ## Summary 현대 **소프트웨어 개발 문화**에서는 프로젝트 이름이 기능과 무관한 임의적 단어로 채워지며, 이름이 더 이상 도구의 역할을 설명하지 못하고 있습니다. 과거 *grep*, *awk*, *FORTRAN*처럼 목적이 드러나는 명명 관행이 사라지면서, 개발자들은 각 도구의 기능을 파악하기 위해 불필요한 탐색과 학습을 반복하게 됩니다. 이 글에선 이러한 흐름을 **브랜드 중심 문화의 부작용**으로 보고, 기술 도구의 이름은 다시 **명료성과 전문성**을 기준으로 정립되어야 한다고 제안합니다. ## Topic Body - 현대 **소프트웨어 개발 문화**에서 프로젝트와 라이브러리의 이름이 기능과 무관한 **임의적 단어**로 채워지고 있음 - 과거에는 **grep, awk, sed, FORTRAN, COBOL** 등처럼 이름이 기능이나 목적을 직접 설명했으나, 최근에는 **의미 없는 명칭**이 난무함 - 이러한 경향은 **GitHub와 스타트업 문화**의 확산 속에서 가속화되어, 이름과 기능의 연결이 완전히 끊어짐 - **이해 비용과 인지적 부담**이 커지며, 개발자들은 각 도구의 역할을 파악하기 위해 불필요한 탐색을 반복하게 됨 - 글은 **명확하고 기능 중심적인 명명 규칙의 복원**을 요구하며, 기술 도구에는 브랜드보다 **명료성과 전문성**이 우선되어야 함을 강조함 --- ### 소프트웨어 명명 관행의 변화 - **Richard Stallman**은 2022년 EmacsConf 강연에서 “기억하기 쉬운 이름”의 중요성을 언급하며, 패키지 이름이 수행하는 일을 드러내야 한다고 강조함 - Emacs 생태계는 전통적으로 **dired(디렉터리 편집기)** , **eshell(Emacs 셸)** 등 기능 기반 명명 관행을 유지해 왔음 - 그러나 현대 개발자들은 **무작위 명사, 신화 속 존재, 허구 인물** 등과 같은 이름을 도구에 붙이는 경향을 보임 - 이는 다른 기술 분야에서는 **전문성 결여로 간주될 행위**임 ### 의미 없는 이름의 문제 - 예시로 “Viper”, “Cobra”, “Melody”, “Casbin”, “Asynq” 같은 도구 이름은 기능을 전혀 유추할 수 없음 - 저자는 친구의 인프라 설명을 이해하기 위해 **검색까지 해야 했던 경험**을 언급 - 다른 공학 분야에서는 이름이 구조나 기능을 설명함 - 예: **Golden Gate Bridge**, **Hoover Dam**, **I-beam**, **butterfly valve** 등은 형태나 역할이 명확히 드러남 - 화학 분야의 **IUPAC 명명법**처럼, 명칭이 정확히 한 대상을 지칭하도록 규정되어 있음 - 예: **2,2,4-trimethylpentane**은 단 하나의 분자를 의미하며, 임의로 “Steve”라 부르지 않음 ### 과거의 명명 규칙과 현재의 단절 - 1980년대에는 **grep, awk, sed, cat, diff** 등 기능 기반 약어가 주류였음 - **FORTRAN, COBOL, BASIC, SQL, Lisp** 등 프로그래밍 언어 이름도 목적을 반영함 - 2010년대 이후 **의미 없는 이름의 확산**이 시작됨 - **MongoDB**처럼 일부는 기능과 어원적 연관이 있었으나, 이후 **GitHub와 스타트업 문화** 속에서 무의미한 명칭이 급증 - **Google**처럼 브랜드 중심의 성공 사례를 모방하려는 경향이 원인으로 지적됨 ### 인지적 비용과 개발 효율 저하 - **libsodium** 같은 이름은 기능을 추론하기 어렵고, 개발자가 **문맥 전환**을 반복해야 함 - “왜 sodium인가?”를 해석하는 데 불필요한 시간이 소모됨 - 프로젝트 의존성이 많을수록 이러한 **인지적 세금(cognitive tax)** 이 누적됨 - 이는 개발자 생산성 저하로 이어짐 - 저자는 “Viper, Cobra, Melody…” 같은 문장을 처리할 때 **의미 없는 토큰 해석**에 정신적 자원이 낭비된다고 지적 ### 흔한 반론과 그에 대한 반박 - “기억하기 쉬운 이름이 마케팅에 유리하다” → **개발자용 도구는 소비자 제품이 아니며**, 기능 명확성이 더 중요함 - “설명적인 이름은 지루하다” → **지루함은 명확성의 대가로 허용 가능**, 외과기구도 지루하지만 정확함 - “재미로 짓는 것이다” → **모든 사용자가 그 ‘재미’의 대가를 치름**, 산업 전체의 시간 낭비로 이어짐 - “좋은 이름은 이미 다 쓰였다” → **네임스페이스, 접두사, 복합어** 등으로 해결 가능하며, 최소한 기능과 연관된 이름을 택해야 함 ### 앞으로의 방향 - 문제는 악의적이라기보다 **문화적 변화**의 결과로 설명됨 - 프로그래밍이 기업 중심에서 커뮤니티 중심으로 이동하면서 **사회적 규범이 약화됨** - 해결책은 **명명 규칙의 문화적 복원** - 규제보다는 **전문성 회복과 교육, 사회적 압력**을 통한 개선 필요 - **라이브러리 이름은 기능을 반영**해야 하며, 필요하다면 **복합어와 장황한 표현**도 허용 - 예: “http-request-validator”는 “zephyr”보다 훨씬 명확함 - **마스코트와 이름을 분리**할 것 - 예: PostgreSQL은 **코끼리 마스코트 Slonik**을 사용하지만, 이름 자체는 기능적 의미를 유지함 - **브랜딩이 중요한 소비자 제품**이 아니라면, **명료성과 전문성**을 우선해야 함 - “좋아하는 애니메이션 캐릭터 이름”을 붙이기 전, “토목기술자가 교량 시스템에 이런 이름을 붙일까?”를 자문해야 함 - 결론적으로, **무의미한 명칭의 난립을 멈추고 명확한 전문 언어로 돌아가야 함** - 명확성은 지루함이 아니라, **사용자의 시간과 인지 자원에 대한 존중**임 ## Comments ### Comment 47687 - Author: epdlemflaj - Created: 2025-12-13T22:53:22+09:00 - Points: 3 Awk도 기능 기반 이름이라기에는.... ### Comment 47785 - Author: roxie - Created: 2025-12-15T18:44:17+09:00 - Points: 1 예시 안적었으면 설득력 10% 는 올라갔을 듯.. ### Comment 47743 - Author: kandk - Created: 2025-12-15T10:35:30+09:00 - Points: 1 어느정도 동의하긴한데, 이름 짓는 스트레스를 받기 싫어하는듯 ### Comment 47684 - Author: qpolsa95 - Created: 2025-12-13T19:16:43+09:00 - Points: 1 쓸만한 이름은 이미 다 누군가 쓰는중임 ### Comment 47675 - Author: khris - Created: 2025-12-13T13:41:03+09:00 - Points: 2 emacs 뭔 뜻인지 아시는 분? 뜻이야 있다지만 두문자 이름은 척봐서 알수도 없는데 이름인데… 그리고 기능만으로 이름을 붙이기엔 이제는 너무 많은 프로젝트가 있죠 ### Comment 47682 - Author: cgl00 - Created: 2025-12-13T17:30:23+09:00 - Points: 2 - Parent comment: 47675 - Depth: 1 깃헙탓하는 거 보면 그냥 RMS식 억까네요 ㅋㅋ ### Comment 47651 - Author: neo - Created: 2025-12-12T22:33:23+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46234806) - 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 등도 이름의 의미가 제각각임. 결국 이름 논쟁은 **별 의미 없는 소란**이라고 생각함 - [Back Orifice 2000](https://en.wikipedia.org/wiki/Back_Orifice_2000)은 이름만 봐도 무슨 일을 하는지 명확했지만, [BitchX](https://en.wikipedia.org/wiki/BitchX)는 그렇지 않았음 - grep, awk, sed, cat, diff 등 UNIX 명령어들은 기능적이거나 체계적인 이름이었지만, 사실 **diff** 정도만 직관적으로 추측 가능함. awk를 좋은 이름이라 칭하는 건 과장임 - 이런 이름들이 자연스럽게 느껴지는 건 **익숙함의 착각**일 뿐임. 지금은 수많은 유틸리티와 라이브러리가 존재하므로, 이름의 차별화가 필수임 - [Libiberty](https://en.wikipedia.org/wiki/Libiberty)는 가장 웃긴 이름 중 하나였음. `-liberty` 옵션으로 링크할 수 있게 지은 이름임 - cat은 concatenate의 축약형이 아니라 **catenate**에서 온 것임. ‘con’ 접두사는 중복이라 생략된 형태임. 언어학적으로도 흥미로운 예시임 - awk, sed, cat은 좋은 이름이라기보다 **익숙한 이름**일 뿐임. grep은 오히려 의성어처럼 들려서 패턴을 ‘잡아내는’ 느낌이 있음 - 이런 약어나 축약어는 **산업별 전문용어**처럼, 한 번 배우면 자연스러워짐. 예전엔 타이핑 효율이 중요했기 때문에 cat vs concat의 차이가 생산성에 영향을 줬음 - “기술 분야에서 이런 이름 짓기는 커리어 자살”이라는 주장에 반박함. [미국 국방부 코드명 목록](https://en.wikipedia.org/wiki/List_of_U.S._Department_of_Defense_and_partner_code_names)을 보면, 오히려 **의도적으로 불투명한 이름**이 많음. Hoover Dam도 처음엔 Boulder Canyon Project로 불렸고, 이름이 기능을 설명하지 않음. Requests보다 Reitzlib이 더 나은 이름일까? 결국 이름은 맥락에 따라 다름 - 화학에서도 **재미있는 이름**이 많음. 예를 들어 SHAKE, RATTLE, CHARMm, Amber 같은 알고리즘이나 패키지들이 있음. 귀여운 이름은 생물학 분야에서 더 흔함 - 기상학에서도 예외가 아님. [STEVE](https://en.wikipedia.org/wiki/STEVE)라는 오로라 현상 이름이 대표적임 - 군사 코드명은 **의도적으로 무작위**로 지어져서 의미를 숨기기 위한 것임. 기업 내부 프로젝트도 종종 이런 방식을 씀 - 생물학에서도 마찬가지로 [Sonic hedgehog protein](https://en.wikipedia.org/wiki/Sonic_hedgehog_protein) 같은 이름이 존재함 - 천문학은 특히 **최악의 약자 이름들**로 유명함. 예시는 [이 링크](https://lweb.cfa.harvard.edu/~gpetitpas/Links/Astroacro.html)에서 볼 수 있음 - awk 같은 이름은 사실 좋은 이름이 아님. 단순히 **저자 이니셜**일 뿐이며, 기능을 전혀 전달하지 않음. 요즘은 탭 자동완성이 있으니 굳이 짧게 줄일 필요도 없음 - 나는 [이 반론 글](https://medium.com/better-programming/software-component-names-should-be-whimsical-and-cryptic-ca260b013de0)에 공감함. 외부 식별자는 시간이 지나면 의미가 변하므로, 처음부터 정확히 묘사하는 이름은 오래 못 감. 게다가 “X Manager”, “X Service” 같은 이름이 너무 많아 구분이 어려움 - 나는 **기발한 이름**을 좋아함. 이름 짓기 어렵다면 개념이 명확하지 않다는 신호임. 이상적인 이름은 처음엔 이상하지만, 나중에 의미를 알면 기억에 남는 이름임. Spotify의 A/B 테스트 팀이 자신들을 “**ABBA**”라 부른 건 최고의 예시임 - 물론 목표에 따라 다름. 하지만 **한 가지 일에 집중하고, 그 일을 이름에 담는 것**도 좋은 원칙임 - 나는 자동차 OEM에서 엔진 보정 엔지니어로 일했는데, 모든 변수와 함수가 **약어**로 되어 있었음. 처음 한 달은 머리가 터질 정도로 피곤했음. 결국 동료가 “이건 새로운 언어를 배우는 것과 같다”고 말했는데, 정말 그랬음. 즉, **기술적 이름이 많다고 인지 부하가 줄어드는 건 아님** - 모바일 통신 분야에서도 마찬가지임. 모든 약어를 외우려 하면 끝이 없음. 예를 들어 AP가 Application Processor인지 Access Point인지 맥락에 따라 다름. 그래도 MSISDN보단 짧아서 쓸 수밖에 없음 - [런던 택시 자격시험 영상](https://www.youtube.com/watch?v=6ZwWG1nK2fY)을 보면, 사람의 뇌 구조가 실제로 바뀔 정도로 학습 피로가 크다고 함. 복잡한 명칭 체계는 본질적으로 **인지적 부담**을 줌 - “기능적 이름이 마케팅보다 낫다”는 주장에 동의하기 어려움. 기능 기반 이름은 결국 **끝없는 약어의 바다**를 만든다. 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 같은 구조적 이름은 프로젝트 내부에선 좋지만, **독립적 맥락**에서는 쓸모없음 - 반대로, 어떤 사람들은 **전문성 자체에서 즐거움**을 느끼며, 귀여운 이름을 산만하다고 여김. 장인정신에서 오는 만족이 진짜 즐거움이라는 시각도 있음