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

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