서비스 이름 짓기는 왜 항상 어려울까?

PO, PM은 서비스의 특성을 가장 잘 반영할 수 있는 이름을 선호했습니다. 이 이름이 한 번에 서비스가 가진 고유한 특성을 전달 할 수 있는지, 처음 듣는 사람도 무슨 서비스인지 짐작할 수 있는지, 서비스가 속한 생태계 분위기에 자연스럽게 녹아드는지를 중점으로 봤습니다. 이름이 아무리 세련되고 멋지더라도 이름이 모호하게 느껴지거나 기존 생태계와 어울리지 않으면 낮은 점수를 줬습니다.

디자이너는 PO/PM과 의견이 비슷했지만, 확실히 무게중심은 달랐습니다. 이름을 심볼화하여 로고를 만들거나 할 때 더 잘 표현할 수 있는지를 따져봤습니다. 그래서 추상적으로 관념을 담은 이름보다는 특정 사물과 연결될 수 있는 이름을 선호했습니다. 그리고 여기에 더해서 이름을 이미지화 시켰을 때 이미지의 확장, 변형이 용이한지도 중요하게 생각했습니다. 예를 들어, 흑백으로 표현해도 여전히 이름이 같은 의미를 전달하는지, 텍스트와 심볼을 나란히 두어도 오해가 없는 이름인지, 앱 아이콘처럼 정방형에도 똑같은 의미를 담을 수 있는지를 고려했습니다.

개발자는 선호이유가 앞선 둘보다는 훨씬 모호해 보였습니다. 이름에 담긴 의미나 디자인 확장성을 따지기보다는, 단지 이름이 소리내어 불렀을 때 입에 잘 감기는지, 발음이 편안한지, 그냥 들었을 때 좋은 느낌이 드는지를 봤습니다. 그리고 도메인을 선점할 수 있는지, 코드에 이름을 타이핑 할 때 오타가 많이 날 수 있는지도 중요하게 생각했습니다. 예를 들어 발음을 들었을 때 철자가 헷갈려서 쓸 때마다 한 번 더 고민해야 하는 이름은 질색했습니다. 개발과정에서 코드 타이핑이 번거롭다는 것을 넘어서, 헷갈리는 철자는 검색 용이성도 해치기 때문에 유저가 서비스를 찾는 입구인 SEO(Search Engine Optimization)에서도 불리하다는 기술적 근거를 들었습니다.

팀원들의 아이디어는 모두 빛났지만 이 아이디어는 각각 다른 이유로 상반된 평가를 받았습니다. 어떤 이름 후보는 PO에게는 만점, 개발자에게는 낙제였고, 다른 후보는 그 반대이기도 했습니다.

다수결이 별 도움이 되지 않은 이유

이름의 좋음은 그 특성상 좋고 나쁨을 정량화하기 힘듭니다. 그래서 다수결 투표를 해봤습니다만, 그 투표 결과를 따르는 것이 최선인지는 확신이 들지 않았습니다.

투표 결과가 미덥지 않았던 이유는 명확했습니다. 팀원들은 서로 다른 축으로 평가한 점수를 하나의 총점인 것처럼 더하고 있었기 때문입니다. 이런 투표 결과는 이름의 좋음보다는 그 회의실에 앉아있는 직군 구성비를 측정한 결과에 더 가까웠습니다. 개발자가 셋이고 디자이너가 하나인 회의실이라면, 개발 편의성이 좋은 이름이 이길 확률이 높습니다. 반대로 구성되면 시각적으로 활용하기 좋은 이름이 이길 확률이 높아집니다. 어느 쪽도 고객과 서비스 입장에서 가장 훌륭하다는 근거로 득표했다고 보기 어려웠습니다.

그렇다면 각 표에 가중치를 다르게 주는 것은 어땠을까요? PO나 디자이너는 서비스의 인상을 종합적으로 판단하는 일을 합니다. 그리고 고객과 맞닿는 표면적도 개발자보다 훨씬 넓습니다. 그렇기에 이들의 판단에 무게를 더 실어야 한다는 논리도 자연스럽습니다.

하지만 발상을 전환해 볼 지점도 있습니다. 이름에 내포된 의미 따위에는 관심 없이 발음 소리와 철자만 따지던 개발자의 감각이, 오히려 실제 사용자의 감각에 더 가까울 수도 있는 것입니다. 사용자에게는 브랜드 스토리나 심볼의 미학적인 아름다움이 닿지 않을 수 있습니다. 대부분 사용자는 그저 이름을 한 번 듣고, 검색창에 쳐보고, 친구에게 말로 옮깁니다. 이 모든 과정에서 팀이 공급자로서 유저에게 전달하고자 하는 욕망이 담긴 그 가치들은 온전히 작동하지 않을 수도 있습니다.

그 이름을 더 잘 이해하고, 적극적으로 활용할 직군에게 가중치를 주는 것도 뾰족한 답은 아니었습니다.

객관적으로 판정 가능한 것과 판정이 어려운 것

각 팀원이 보던 축들은 각 직무의 특성을 반영한 다른 관점이면서, 동시에 판정 가능한 것과 판정 불가한 주관적인 요소도 섞여있기도 합니다.

도메인 선점, 상표 등록 가능 여부같은 것들은 O/X로 판별하거나, 팀 내부에서 확인이 불가능하다면 검토가 가능한지 판단할 수 있습니다. 설령 등록 가능 여부에 대한 답이 X라고 하더라도, O로 만들기 위해서 어떤 노력과 비용이 들어가는지 가늠해 볼 수 있습니다.

흔한 일반명사라서 검색에 어려움이 있는지, 소리와 표기 사이에 오해가 없는지도 판정 가능합니다. 가령, 제미나이(gemini)라는 이름이 한국사용자들에게 제미니, 재미니, 잼미니 등의 이름으로 오해를 불러 일으킬 것이라는 것은 충분히 판정 가능합니다.

반면 이 이름이 팀이 유저에게 주고자 하는 가치가 잘 전달 되는지, 심볼화 했을때 유저들이 충분히 아름답게 느낄지는 측정하기 어렵습니다. 노련한 UX 전문가들에 의해 합리적으로 예측 될 수는 있어도 그 예측은 가정에 무게가 더 실릴 수 밖에 없습니다. 새로운 서비스를 만드는 시점에는 그 이름을 실제로 듣게 될 ‘사용자’라는 사람들은 실존하지 않고, 서비스 출시 이후에도 회의실에 앉아있는 팀원들은 그 이름을 감각하게 될 사용자들을 직접 대변할 수 없기 때문입니다.

성질이 다른 요소들을 같은 방식으로 다루었기에 논의가 평행선을 달린 것입니다. 우리는 후보하나를 놓고 한참 고민하다가, 나중에서야 이미 그 상표가 특허에 의해서 보호받고 있으며, 도메인 선점도 어렵다는 사실을 깨닫고 처음으로 돌아가는 일을 반복했습니다. 순서를 뒤집었으면 일은 훨씬 빨리 끝났을 것입니다. 발산은 넓게 하되, 모인 후보들을 먼저 판정 가능한 조건으로 걸러내고, 남은 것들에 대해서 판정 불가능한 요소들에 대한 호불호를 논하는 것입니다.

다만, 무조건 필터를 너무 빡빡하게 걸어둘 필요는 없습니다. 앞서 말했듯, 도메인 선점 여부 같은 것은 서비스 특성을 고려하여 유연하게 열어둬도 괜찮습니다. .com을 누군가 선점하고 있다면 .io 같은 대안을 사용하거나 비용을 지출하여 그 이름을 살려낼 수 있습니다. 그러니 대부분의 경우에 필터 조건은 통과, 탈락으로 이분법으로 나누기보다는 그 문제를 해결하기 위한 비용으로 남겨두는 것이 더 낫습니다. 이 도메인은 얼마면 살 수 있고, 어떤 이름은 상표 출원 시 거절 위험이 있거나, 어떤 이름은 검색 노출에 초기비용이 얼만큼 더 든다는 식으로요. 그렇다면 이 부분만큼은 취향대결이 아니라, 합리적인 투자비용대비 이득에 대한 합리적 판단으로 옮겨갑니다.

가중치는 전혀 의미가 없을까?

앞에서 직군별 가중치를 따지는 것도 답은 아니라고 했는데, 조금 더 구체화 해보면 활용해 볼 여지가 있습니다. 직군을 기준으로 순위를 매기기는 어렵지만, 팀이 만드는 것이 어떤 서비스인지를 기준으로는 그 가중치를 매길 수 있습니다.

1) 이름이 사용자의 입으로 직접 옮겨지는 서비스인가

B2C 앱이나 커뮤니티처럼 사용자가 친구에게 말로 추천하는 서비스라면, 발음과 철자가 중요한 축이 될 수 있습니다. 물론 서비스 인지도가 충분히 자리잡은 뒤에는 아무리 발음이 어렵더라도 상관없지만 서비스 초기 단계에서는 검색 용이성이 크게 작용할 수 있습니다. 반면 B2B SaaS는 도입 경로가 검색이 아니고, 기업간 계약에 의해 이미 사용하기로 결정된 이후에 실제 사용자에게 그 이름이 전달됩니다. 그리고 이름이 귀보다는 사내 문서를 통해 눈으로 먼저 전달되니, 조금 어렵더라도 크게 상관 없습니다.

대신 B2B 사업 담당자의 눈에는 띄어야하니 검색했을 때 우리 서비스가 구분되어 보이는지는 중요할 수 있습니다. 해외 진출을 고려한다면, 이 축은 언어 갯수만큼 늘어날 수 있습니다.

2) 개발자가 곧 사용자인가

개발자 도구나 API 상품이라면 이야기는 좀 달라집니다. 이름이 곧 브랜드이면서 동시에 명령어입니다. 좋은 npm, GitHub 조직명을 확보 가능한지가 .com 도메인을 확보할 수 있는지만큼 중요해집니다.

개발자에게 이미 익숙한 이름에 붙어가는 것도 좋은 방향입니다. Typescript처럼 이름만으로 Javascript의 계보임을 밝히는 것은 이름으로 의미를 전달하려는 그 목적을 아주 쉽게 해결할 수도 있습니다. 다만, 서비스가 이미 자리를 잡은 뒤에는 “Java와 Javascript가 무엇이 다르냐”같이 자연스럽게 따라오는 개념 혼동 문제를 해결해야 할 수도 있습니다. 그리고 상표 관련 법적 문제를 지지 않도록 면밀히 검토해야 할 것입니다.

3) 시각적 요소가 곧 경쟁력인가

앱스토어의 아이콘, 오프라인 굿즈에서 서비스 이름이 곧 서비스를 홍보하는 간판 역할을 한다면 디자이너의 축에 가중치를 주는 것이 좋습니다. 앞서 디자이너는 관념이 사물로 치환되는 이름인지를 중요하게 여긴다고 했었습니다. 만약 이런 속성의 서비스라면 디자이너의 이 고민이 큰 힘을 갖게 됩니다. 반대로 백오피스 도구나 인프라 제품이면, 상대적으로 이 축의 가중치를 낮추는 것도 좋은 방법입니다.

4) 이름이 서비스 카테고리를 설명해야 하는가

인지도가 전혀 없는 신규 서비스는 그 이름이 모든 설명을 떠맡는 경우가 많습니다. 대부분 스타트업은 아마 이 고민을 풀어나가야 할 것입니다. 다만 이건 시기에 따라서 다를 수 있으므로, 조심스럽게 다뤄야합니다.

당근의 사례를 참고할 수 있습니다. 당근은 2015년 전국 서비스를 준비하던 시절에도 ‘당근’이 이름 후보에 올랐지만, 이제 막 시작하는 기업에게는 파격적이라고 판단해서 중고 거래를 뜻하는 ‘마켓’을 붙이고 ‘당근마켓’으로 시작했다고 합니다. 초기에는 ‘마켓’이라는 그 글자가 당근이 어떤 서비스인지 정확하게 알려주는 역할을 했습니다.

하지만 당근이 인지도 높은 서비스가 되고, 모임, 알바, 부동산으로 다루는 영역이 넓어지면서 ‘마켓’이 중고거래에 한정돼 보이게 만드는 요소로 작용했고, 8년 만에 그 이름을 떼어내어 ‘당근’이 되었습니다. 이름에 카테고리를 넣는 것은 초기 인지 비용을 아낌과 동시에, 사업 확장시 리브랜딩하는 비용을 미리 빚져서 쓰는 일이라고 볼 수도 있습니다.

물론 이런 가중치들은 출발선일뿐 완벽한 정답은 아닙니다. 그래도 서비스 작명 브레인스토밍 회의의 시작 전에 ‘우리 서비스는 어떤 서비스인가’에 대해서 짧게 합의를 하고 시작하는 것이 좋습니다. 그래야 뒤이어 나올 각 이름에 대한 선호가 취향 대결이 아니라 근거 있는 의견으로서 작용할 수 있습니다.

마지막에 필요한 것은 합의가 아니라 ‘결정’

이런 조건과 가중치를 다 적용하고 나더라도 ‘이름 짓기’에는 여전히 정답이 없습니다. 여전히 마지막 우열은 판단의 영역이고, 그 판단은 사람마다 다릅니다.

저는 수많은 이름 짓기 회의를 하면서 단 한 번도 깔끔한 만장일치 합의에 이른 적이 없습니다. 그때마다 가장 권한이 많은 대표의 의견에 따르기도 했고, 이 서비스를 처음 기획한 기획자의 아이디어를 따르기도 했습니다. 때로는 일단 가제로 이름을 지어놓고 만들면서 생각하자는 결론에 이르기도 했습니다. 그것이 가장 합리적인 절충 합의안으로 보였습니다. 하지만 지금은 조금 다르게 봅니다. 애초에 이름 짓기는 합의만으로 끝날 수 있는 성격의 일이 아닙니다.

브레인스토밍 회의는 진행하다보면 무한히 발산할 수 밖에 없습니다. 개성 강한 팀원이 많고, 수평적인 조직문화를 가진 스타트업일수록 이 현상은 더 뚜렷해집니다. 그렇기에 논의를 시작하기 전에 한 가지를 정해야합니다. 결국 마지막에 이름을 선택할 한 사람을 정해야 합니다.

그렇다면 논의의 성격은 조금 달라집니다. 각자가 자기 후보를 관철하려는 설득의 경쟁이 아니라, 결정할 사람에게 더 좋은 판단을 할 수 있는 재료를 넘겨주는 작업이 됩니다. 디자이너는 이 이름이 심볼로 어떻게 풀리는지를 보여주고, 개발자는 도메인과 개발편의성에 대한 지표를 알려주고, 법률 담당자는 상표 출원 가능 여부를 측정 가능한 지표로서 전달합니다. 그리고 각자의 취향이 담긴 판정 불가능한 호불호까지 전달합니다. 그리고 결정권자는 이 모든 것을 고려해서 최종 판단을 하는 것 입니다. 물론 이 모든 과정에서, 팀원들은 각자 참신한 아이디어는 아낌없이 내놓고, 다른 아이디어에 대해서 대안없는 비난은 하지 않아야합니다.

마치며: 이름 짓기는 얼마나 중요한 일일까?

그리고 하나 더. 이름 짓기는 중요한 일입니다. 하지만 어떻게 보면 그렇게 중요하지 않은 일일 수도 있습니다. 비바리퍼블리카라는 회사 이름이 토스의 기능을 잘 설명하지는 않습니다. 배달의 민족 서비스에서 느끼는 유쾌함과 재치있는 이미지도, ‘우아한’ 형제들 이라는 회사 이름에 잘 녹아있지는 않고요. 하나의 단어가 모든 정체성과 인상을 전부 짊어져야만 성공하는 것은 아니라는 뜻이기도 합니다.

서비스명 쪽도 비슷합니다. 종합 금융 플랫폼이 된 토스의 기능들은 3초 간편송금기능을 설명하는 토스(Toss)라는 의미를 초월해버린지 오래입니다. 이름이 서비스의 성장속도를 따라가지 못하게 된 것입니다. 하지만 토스는 이미 훌륭한 서비스이고 여전히 사용자들은 토스를 사랑합니다. 이름이 못 따라가더라도 사람들은 스스로 그 이름에 새 뜻을 채워넣습니다.

앞서 다룬 당근 사례처럼 일단 잘 만든 뒤에 리브랜딩을 하는 선택지도 있고요. 반면 이름은 기가막히게 지었지만, 사용자들이 가치를 느끼지 못하고 사라져버렸기에 우리가 이름조차 기억하지 못해서 예시를 들 수 없는 서비스도 많습니다. 성공한 서비스들만 놓고 비교하면, 그 성공에서 이름의 몫이 얼마만큼이었는지는 끝내 완벽하게 알 수 없습니다.

그래서 저는 법률, 기술 이슈처럼 측정 할 수 있는 부분들은 빠짐없이 깊게 고민하되, 그저 호불호만 남는 영역에 깊게 몰두하는 것은 경계합니다. 측정이 불가한 호불호 영역에 대해서 고민하는 시간은, 유저에게 가치를 전달하는 본질적인 일을 해야 할 시간을 떼어와서 쓰는 것일 수도 있기 때문입니다. 오랫동안 정답을 찾기 위해 고민하는 것은 멋진 일이지만, 애초에 정답이 없는 일이라는 것을 아는데도 불구하고 한없이 붙들고 있는 것은 무모한 일일 수도 있습니다.

서비스 이름 짓기 과정이 여전히 아주 중요한 일인 이유가 적어도 저에게는 한 가지 더 있습니다. 내가 만드는 서비스가 사람들에게 불리게 될 이름을 만드는 과정의 시작부터 끝까지, 그 모든 과정을 함께했다는 사실 자체가 의미를 가집니다. 이름을 짓는 과정에 참여하면, 그 서비스는 ‘회사의 것’에서 ‘내 것’이 됩니다. 그리고 ‘내 것’은 그 서비스를 더 가치 있게 만들어 낼 동력이 되죠. 그리고 그 동력으로 만들어낸 서비스는 분명 사용자에게 더 나은 경험을 선사할 겁니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.