현대 소프트웨어 생태계에서 의미 없는 도구 이름이 가져오는 인지적 부담과, 더 명확하고 기술적인 명명 관습으로 돌아가야 하는 이유를 다룬 글
이 글은 프로그래밍 분류 아래에 속하거나, 그와 관련된 글이다.
2022년 12월, 나는 리처드 스톨먼이 EmacsConf에서 한 발표를 봤다. 제목은 “내가 Emacs에서 보고 싶은 것들(What I’d like to see in Emacs)”이었다. 이 발표에서 스톨먼 씨가 짚은 흥미로운 지점 중 하나가 바로 “기억에 남는 이름”이었다. 대략 이런 말이었다. “당신이 만드는 모든 패키지는 […] 그 패키지가 무슨 일을 하는지 기억하는 데 도움이 되는 이름을 가져야 합니다. […] 우리는 말장난을 위한 이름이거나, 분명한 의미가 없는 이름을 패키지에 붙이는 경향이 생겼습니다.” 스톨먼이 2022년에 이런 말을 굳이 해야 했다는 사실 자체가, 우리가 얼마나 멀리까지 미끄러져 내려왔는지를 잘 보여준다. 그것도 디렉터리 에디터인 dired, Emacs 셸인 eshell처럼 설명적인 이름으로 유명했던 Emacs 생태계 안에서조차 말이다.
요즘 소프트웨어 개발에는 이상한 경향이 있다. 전반적으로, 도구 이름을 아무 의미 없는 명사나, 신화 속 생물, 혹은 좋아하는 가상의 캐릭터 이름으로 짓는 게 ‘전문적인 관행’으로도 괜찮다고 집단적으로 합의해 버린 것처럼 보인다. 다른 거의 모든 기술 분야에서였다면 이런 짓은 사실상 커리어 자살에 가깝다.
최근에 지인과 인프라 관련 이야기를 하다가 스톨먼의 그 말을 다시 떠올렸다. 친구가 자기네 인프라 상황을 설명해 주고 있었는데, 대략 이런 식이었다. “설정 관리를 위해 Viper를 쓰고 있고, 그게 CLI 쪽으로는 Cobra로 연결되고, WebSocket 연결은 Melody가 처리하고, 권한 관리는 Casbin이 맡고 있어. 이 모든 걸 Asynq를 통해 잡 큐로 돌리고 있어.” 이 문장에서 마지막 소프트웨어 정도만이 그 패키지/소프트웨어가 실제로 무엇을 하는지 아주 약간이라도 말해 준다. 나는 그 이름들이 도대체 뭘 의미하는지 이해해 보려고 잠시 멈췄고, 몇 개는 검색까지 해 봐야 했다. 그런데 이런 짓을 다른 어떤 분야를 다룰 때도 해 본 적이 있었나 싶더라. Golden Gate Bridge(금문교)는 그 다리가 Golden Gate 해협을 가로지른다는 사실을 그대로 말해 준다. Hoover Dam(후버 댐)은 댐이고, 그걸 추진한 대통령의 이름을 땄다. “Thunderfall 프로젝트”나 “AquaHold” 따위가 아니다. 철제 I-빔(아이빔)은 단면이 알파벳 I 모양이기 때문에 그렇게 부른다. 공학자들이 다소 창의적으로 이름을 지을 때에도 나름의 논리가 있다. butterfly valve(버터플라이 밸브)는 실제로 나비 날개처럼 생겼다. 이름이 그 대상이 무엇인지와 어떻게 연결되는지 알 수 있고, 기억에도 남는다. CLI를 100개를 만들었다고 해도, cobra 같은 이름을 일부러 골라 쓸 이유는 전혀 없을 것이다.
화학공학 같은 다른 분야도 마찬가지인데, 그쪽은 심지어 더 엄격한 규율을 유지한다. IUPAC 명명법에서는 2,2,4-trimethylpentane이라는 이름이 정확히 하나의 분자만을 가리킨다. 어떤 화학자가 아침에 일어나서 “이걸 오늘부터 ‘Steve’라고 불러 봐야지, 이름이 웃기니까 사람들이 제 논문을 더 친근하게 느끼겠지요” 같은 생각을 하는 일은 없다.
나는 소프트웨어 역사 관련 자료를 꽤 많이 읽는 편인데, 어느 시대가 아주 훌륭한 이름짓기의 황금기였다고까지 말할 수는 없다. (아주 노련한 엔지니어들도 어떤아주우스운이름을 짓곤 했다.) 그래도 적어도 80년대에는 어느 정도는 말이 되도록 애쓰는 흐름이 있었던 것 같다. grep(global regular expression print), awk(Aho, Weinberger, Kernighan; 만든 사람들 성의 이니셜), sed(stream editor), cat(concatenate), diff(difference). 줄임말이더라도 이 이름들은 기능을 설명하거나 체계적인 파생 방식에 따른 것이었다. 누구도 복사 명령을 “Sparkle”이라 부르거나, 이동 명령을 “Whisper”라고 부르지는 않았다.
초기의 프로그래밍 언어들도 비슷한 논리를 따랐다. FORTRAN(Formula Translation), COBOL(Common Business-Oriented Language), BASIC(Beginner’s All-purpose Symbolic Instruction Code), SQL(Structured Query Language), Lisp는 list processing에서 왔다고들 한다. 패턴은 명확했다. 이름이 목적이나 기원을 전달했다. 그러다 2010년대 즈음 어딘가에서, 일종의 밈 바이러스가 소프트웨어 공학을 감염시킨 것 같다. 어쩌면 처음에는 무해하게 시작됐을지도 모른다. 지루한 기업식 네이밍에 진력이 난 개발자들이, 오픈 소스 프로젝트에는 자기 개성을 드러내고 싶어 했던 것일 수도 있다. 약간은 그럴싸하고 괴상한 이름들이 나올 정도까지는 귀여웠다. 동물 이름을 딴 데이터베이스? 괜찮다. MongoDB(“humongous”에서 따 옴)는 적어도 목적과 어원적인 연결이 있다. 줄여서 “Mongo”라 부르게 되었을지언정 말이다.
하지만 우리는 거기서 멈추지 않았다. 우리는 계속 갔다. 이제 우리는 이름과 기능 사이의 연결이 완전히 끊긴, 의미 없는 호칭들로 가득한 동물원 속에서 허우적대고 있다. 아마 깃허브와 스타트업 문화가 부상하면서 이런 패턴이 가속되었을 것이다. 모두가 ‘Google’처럼 되고 싶어 했다. 처음에는 아무 의미 없었지만, 시장 지배를 통해 상징이 되어 버린 이름 말이다. 구글은 수십억 달러에 달하는 광고와, 동사로 굳어질 정도의 브랜드 인지도로 그 이름을 밀어붙일 수 있었다. 그러나 당신의 MIT 라이선스 파일 파서, 깃허브 스타 45개짜리 프로젝트는 그럴 수 없다.
이해하기 어려운 이름 하나하나는, 그 이름을 처음 접하는 모든 개발자에게 일종의 거래 비용을 부과한다. “libsodium”이라는 이름을 볼 때마다, 우리는 문제 해결 모드에서 탐정 모드로 잠깐 전환해야 한다. “이건 뭐 하는 거지? README 좀 볼까. 아, 암호 라이브러리네. 왜 이름이 sodium(나트륨)일까? 화학 때문인가? NaCl 농담인가? 음, 그럴싸하긴 하네.” 이제 이런 과정을 현대 프로젝트가 의존하는 여러 의존성에 대해 수십 번 반복한다고 생각해 보라. 각각은 의미를 해독하기 위해 몇 초의 정신적 처리를 ‘조공’처럼 요구한다. 이 몇 초들이 분 단위의 노력으로, 더 나아가 커리어 전체를 통틀어 보면 산더미 같은 인지적 낭비로 누적된다.
당신이 새로 합류한 엔지니어에게 코드베이스 구조와, 어떤 프로젝트의 전체 아키텍처를 설명한다고 상상해 보자. 그리고 특정 작업을 맡기는 데 사용하는 외부 의존성들을 훑어 보며, 그것들이 어떻게 오케스트레이션되는지를 설명해야 한다. 사실 그냥 아까 친구가 했던 말을 다시 가져와 보자. “설정 관리를 위해 Viper를 쓰고 있고, 그게 CLI 쪽으로는 Cobra로 연결되고, WebSocket 연결은 Melody가 처리하고, 권한 관리는 Casbin이 맡고 있어. 이 모든 걸 Asynq를 통해 잡 큐로 돌리고 있어.”
이 문장을 잠깐 멈추고 실제로 곱씹어 보라. 뱀 하나, 또 다른 뱀 하나, 음악, 정체 모를 고유명사, 그리고… q로 끝나는 async? 당신의 정신 메모리 절반은 이 임의의 토큰들을 실제 기능과 매칭시키느라 바쁘고, 정작 논의 중인 아키텍처 결정에 집중하는 데 쓸 여유는 줄어든다. 이것은 심장 전문의가 “당신의 Whisper에 Butterfly를 설치해서 Thunderbeat를 개선하겠습니다”라고 말하는 것과도 비슷하다. 실제로는 “동맥에 스텐트를 넣어서 심박출량을 개선하겠습니다”라고 말해야 할 자리에서 말이다.
재료공학 논문을 읽는 상황과 비교해 보라. “고엔트로피 합금(high-entropy alloys)”이나 “형상기억 고분자(shape-memory polymers)”라는 표현을 보면, 이름 자체가 정보를 전달한다. 설명 문장을 하나도 읽지 않아도, 이런 물질이 어떤 특성을 가질지, 어떤 용도로 쓰일지를 어느 정도 짐작해 볼 수 있다.
전에 이름짓기에 대한 내 걱정을 한 번 공유했을 때, 대략 이런 이야기들을 들었다. 여기에 대한 내 생각을 덧붙여 보겠다.
“근데 기억에 남는 이름이 마케팅에 도움이 되잖아요!”
물론, 소비자용 제품을 만든다면 그렇다. 하지만 당신의 HTTP 클라이언트, CLI 유틸리티 헬퍼, 기타 라이브러리는 소비자용 제품이 아니다. 거기에 관심을 가질 사람들은, 그게 뭘 하는지만 알면 된다.
“설명적인 이름은 지루해요!”
맞다. 그리고 수술 도구 이름도 지루하다. 명확성이 최우선인 영역에서는 지루함이 아무 문제가 되지 않는다. 여기는 창작 글쓰기 수업이 아니다.
“그냥 재미로 그러는 건데요!”
당신의 재미에는 외부 비용이 있다. 당신의 “재미있는” 이름을 접하는 모든 사람이 작은 세금을 낸다. 업계 전체로 보면, 그 세금은 꽤 큰 낭비로 복리처럼 쌓인다. 그리고 안다, 이게 지금 업계가 직면한 가장 큰 문제는 아니고, 우리가 제일 먼저 해결해야 할 걱정거리도 아니다. 그래도 이 얘기는 꼭 하고 싶었다.
“쓸 만한 설명적인 이름은 다 이미 선점됐어요!”
우리는 네임스페이스, 접두사, 합성어 같은 걸 쓸 수 있다. 다른 공학 분야들은 수 세기 동안 그렇게 해 왔다. 그럴 기술은 충분히 있다. 설령 그게 여의치 않더라도, 최소한 이름이 제품과 조금이라도 관련은 있게 만들 수는 있다. “DB” 같은 접미사를 붙이거나, “magit”처럼 말장난을 하더라도 말이다. 정말로 명확하게 지을 수 없다면, 적어도 어느 정도는 연상 가능하게 만들 수는 있다.
지금의 상황이 악의적으로 만들어진 건 아니다. 문화적인 변화의 결과다. 프로그래밍이 기업 메인프레임 업무 중심에서 커뮤니티 빌더 중심으로 옮겨 가면서 말이다2. (그건 좋은 변화였다.) 그러자 사회적 규범도 함께 달라졌다.
따라서 이제는 문화적인 교정이 필요하다. 규제가 아니라—오픈 소스는 자유 위에서 번성하니까—사회적 압력과 교육을 통한, 직업적 기준의 회복이 필요하다.
당신의 라이브러리 이름은, 그 라이브러리가 하는 일을 따서 지어라. 합성어를 사용하라. 필요하다면 장황해지는 것도 받아들여라. 새벽 2시에 운영 사고를 디버깅하면서 의존성 목록을 훑어볼 때, http-request-validator라는 이름은 “zephyr”보다 압도적으로 낫다.
정말, 정말 귀여운 마스코트나 레퍼런스를 꼭 쓰고 싶다면, 그것을 프로젝트 마스코트로만 쓰고 이름으로는 쓰지 말라. PostgreSQL에는 코끼리 마스코트 Slonik이 있다. 그래도 PostgreSQL은 여전히 PostgreSQL이라고 불린다. 코끼리가 의미 전달을 대체하지는 않는다.
브랜딩이 중요한 최종 사용자 대상 제품에야 창의적인 이름을 붙여도 좋다. 하지만 인프라, 도구, 라이브러리에는 언제나 명확한 이름을 선택하라.
다음 번에, 좋아하는 애니메이션 캐릭터 이름을 따서 프로젝트 이름을 붙이려 할 때 잠시 멈춰라. 그리고 스스로에게 물어보라. “토목 공학자가 교량 지지 시스템에 이런 이름을 붙였을까?” 답이 “아니다”라면, 더 나은 이름을 고르라.
우리 분야는, 전문적인 명명법인 척하는 무작위 명사들의 동물원보다 더 나은 것을 누릴 자격이 있다. 명료함은 지루함이 아니다. 그것은 사용자의 시간과 인지 자원을 존중하는 태도다.
그리고 안다, 이게 지금 업계가 직면한 가장 큰 문제는 아니고, 우리가 제일 먼저 해결해야 할 걱정거리도 아니다. 그래도 이 얘기는 꼭 하고 싶었다.
(그건 좋은 변화였다.)
읽어 보기를 권하는 몇 가지 작업들:
나는 쫓겨난 사탄에게서, 하나님께 피난을 구합니다.
생성 도구: Emacs 30.2 (Org 모드 9.7.34). 작성: Salih Muhammed, 작성일: 2025-12-11 Thu 18:27. 마지막 빌드 날짜: 2025-12-11 Thu 21:29.
