▲

프로그래머와 소프트웨어 개발자들이 도구 이름 짓기에서 길을 잃었다

 (larr.net)
9P by GN⁺ 2일전 | ★ favorite | 댓글 5개
  • 현대 소프트웨어 개발 문화에서 프로젝트와 라이브러리의 이름이 기능과 무관한 임의적 단어로 채워지고 있음
  • 과거에는 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을 사용하지만, 이름 자체는 기능적 의미를 유지함
  • 브랜딩이 중요한 소비자 제품이 아니라면, 명료성과 전문성을 우선해야 함
    • “좋아하는 애니메이션 캐릭터 이름”을 붙이기 전, “토목기술자가 교량 시스템에 이런 이름을 붙일까?”를 자문해야 함
  • 결론적으로, 무의미한 명칭의 난립을 멈추고 명확한 전문 언어로 돌아가야 함
    • 명확성은 지루함이 아니라, 사용자의 시간과 인지 자원에 대한 존중임
▲
epdlemflaj 18시간전  [-]

Awk도 기능 기반 이름이라기에는....

답변달기
▲
khris 1일전  [-]

emacs 뭔 뜻인지 아시는 분? 뜻이야 있다지만 두문자 이름은 척봐서 알수도 없는데 이름인데… 그리고 기능만으로 이름을 붙이기엔 이제는 너무 많은 프로젝트가 있죠

답변달기
▲
cgl00 24시간전  [-]

깃헙탓하는 거 보면 그냥 RMS식 억까네요 ㅋㅋ

답변달기
▲
qpolsa95 22시간전  [-]

쓸만한 이름은 이미 다 누군가 쓰는중임

답변달기
▲
GN⁺ 2일전  [-]
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의 기능을 완벽히 비유함

    • 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은 이름만 봐도 무슨 일을 하는지 명확했지만, BitchX는 그렇지 않았음

  • 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 같은 알고리즘이나 패키지들이 있음. 귀여운 이름은 생물학 분야에서 더 흔함
    • 기상학에서도 예외가 아님. STEVE라는 오로라 현상 이름이 대표적임
    • 군사 코드명은 의도적으로 무작위로 지어져서 의미를 숨기기 위한 것임. 기업 내부 프로젝트도 종종 이런 방식을 씀
    • 생물학에서도 마찬가지로 Sonic hedgehog protein 같은 이름이 존재함
    • 천문학은 특히 최악의 약자 이름들로 유명함. 예시는 이 링크에서 볼 수 있음

  • 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 같은 구조적 이름은 프로젝트 내부에선 좋지만, 독립적 맥락에서는 쓸모없음
    • 반대로, 어떤 사람들은 전문성 자체에서 즐거움을 느끼며, 귀여운 이름을 산만하다고 여김. 장인정신에서 오는 만족이 진짜 즐거움이라는 시각도 있음
답변달기