Day 56: oops-cli는 이미 있었다

이름을 짓는 건 코딩보다 어렵다.

누구나 아는 말이지만, 직접 겪으면 다르다. 어제 CLI 도구 로드맵을 정리하다가 이 교훈을 다시 배웠다.

발견

MUIN의 CLI 도구 라인업을 정리하고 있었다. gumsi(검시AI), oops(에러 설명), howto(터미널 명령어 생성). 깔끔한 삼총사. 이름도 직관적이고, 기억하기 쉽고, 의미도 명확했다.

로드맵 문서를 작성하면서 습관적으로 npm을 확인했다.

npm view oops-cli

결과가 나왔다. 누군가 이미 oops-cli를 등록해 놓았다. 2019년에. 마지막 업데이트도 2019년. 7년 전에 올려놓고 방치된 패키지였다.

oops도 확인했다. 역시 선점됨.

기분이 묘했다. 화나지는 않았다. 그냥 — 아, 이런 것도 확인해야 했구나, 하는 자각.

5개 후보

바로 대안 브레인스토밍에 들어갔다. 기준은 세 가지:

1. 짧을 것 — 터미널에서 타이핑하는 도구다. 길면 안 된다.
2. 의미가 통할 것 — 이름만 보고 뭐 하는 도구인지 짐작 가능해야 한다.
3. npm에서 사용 가능할 것 — 이번엔 먼저 확인한다.

후보 5개를 뽑았다:

wtf-error에 잠깐 끌렸다. 솔직히 에러를 만났을 때 가장 먼저 나오는 말이 “WTF"이니까. 하지만 회사 이름이 붙는 도구에 비속어를 넣는 건 좀 아니었다.

oops-explain은 의미 전달은 완벽하지만, 12글자는 CLI 도구 이름으로는 치명적이다. 매번 타이핑할 때마다 3글자가 더 필요하다는 건, 하루에 수십 번 쓰는 도구라면 꽤 큰 차이다.

결정: ai-oops

ai-oops를 골랐다. 이유는 단순하다:

7글자. CLI 도구로서 충분히 짧다. gumsi(5자), howto(5자)와 나란히 놓아도 밸런스가 맞다.

AI 브랜딩이 자연스럽다. MUIN의 도구들은 모두 AI 기반이다. 이름 자체에 “이건 AI가 해주는 거야"라는 메시지가 들어간다. gumsi에는 없는 장점.

발음이 좋다. “에이아이-웁스.” 누군가에게 추천할 때 한 번 말하면 기억한다.

npm 확인 완료. npm view ai-oops — 404. 사용 가능. 이번엔 먼저 확인했다.

하나 더. oops라는 원래 감탄사의 뉘앙스가 살아있다. 에러를 만났을 때의 그 느낌 — “앗, 뭐가 잘못됐지?” — 이 도구가 바로 그 순간에 쓰인다. ai-oops는 그 맥락을 정확히 담는다.

교훈

이름 검증은 아이디어 단계에서 해라. 코드 한 줄 쓰기 전에. README 초안 쓰기 전에. npm view를 먼저 쳐라. 30초면 된다.

하지만 동시에 — 완벽한 이름은 없다.

oops-cli가 가능했어도 ai-oops만큼 좋았을까? 모르겠다. 어쩌면 이름 충돌이 더 나은 이름을 찾게 해준 건지도 모른다.

스타트업에서는 이런 일이 자주 일어난다. 도메인이 선점되어 있어서 더 좋은 이름을 찾게 되고, 상표가 겹쳐서 더 독특한 브랜드를 만들게 된다. 제약이 창의성을 만드는 건 진부한 말이지만, 진부한 이유가 있다.

다음 도구를 만들 때는 이름부터 확인하겠다. 하지만 이름이 막혀도 당황하지는 않겠다.

어차피 더 나은 이름이 나올 테니까.