JobRadar를 매치다로 바꾸기까지 — 개인 프로젝트 리브랜딩 이야기

이름은 나중에 바꾸면 되지, 라고 생각했다

개인 프로젝트를 시작할 때 이름은 대충 지었다. 채용공고를 긁어와서 매칭해 주는 툴이니까 "JobRadar". 직관적이고, 뜻이 바로 통했다. 그렇게 몇 달을 썼다.

그런데 프로젝트가 커지고 "이걸 진짜 서비스로 내볼까" 하는 마음이 들자, 이름이 자꾸 걸리기 시작했다. JobRadar는 기능을 설명하는 이름이지 브랜드가 아니었다. 검색해 보니 비슷한 이름도 많았고, 도메인도 깔끔한 게 안 남아 있었다.

결국 이름을 바꾸기로 했다. JobRadar → 매치다(matchda). 이 글은 개발자가 코드 말고 이름을 고민한 기록이다. 기술적인 도메인 연결이나 OAuth 리다이렉트 이슈는 별도 글에서 다루고, 여기선 순수하게 "왜, 어떻게 이 이름을 골랐나"에 집중한다.

JobRadar라는 이름의 한계

먼저 왜 바꾸고 싶었는지부터. JobRadar를 뜯어보니 이런 문제들이 있었다.

문제	설명
기능 설명형	"Job(직업) + Radar(레이더)". 뜻은 명확하지만 딱 거기까지. 브랜드로 확장이 안 됨
평범함	Job으로 시작하는 서비스가 너무 많다. 기억에 안 남음
확장성 부족	나중에 이력서·커리어로 기능을 넓히면 "Job"이 오히려 발목을 잡음
도메인	깔끔한 `.com`이 이미 다 나가 있었음

특히 확장성이 컸다. 지금은 채용공고 매칭이지만, 방향은 "사람과 기회를 잇는 것" 전반으로 넓히고 싶었다. 그런데 이름에 "Job"이 박혀 있으면 그 틀에 갇힌다.

매치다에 담은 뜻

새 이름의 조건은 하나였다. "매칭"이라는 핵심 가치를 담되, 기능이 아니라 브랜드일 것.

그래서 나온 게 매치다(matchda) 다. 두 가지 뜻을 겹쳤다.

match + da — "세상의 모든 직업(기회)을 매칭해 준다"는 의미. da는 전부를 아우른다는 어감으로 붙였다.
한국어 "매치다" — "매치한다"는 동사의 어감. 한국 사용자에겐 이름 자체가 곧 서비스의 동작을 말해 준다.

영어로 읽으면 "match-da", 한국어로 읽으면 "매치다". 두 언어권에서 같은 이름이 각자 자연스럽게 읽히고 뜻이 통한다는 점이 마음에 들었다. 다국어 서비스를 지향하는 입장에서 이건 꽤 중요한 장점이었다.

좋은 이름의 기준 — 내가 세운 체크리스트

이름을 고르며 나름의 기준을 정리했다. 사이드 프로젝트에 이름을 붙일 때 참고할 만한 체크리스트다.

기준	질문	매치다는?
기억하기 쉬움	한 번 듣고 다시 떠올릴 수 있나?	✅ 2~3음절, 짧음
발음	한국어·영어로 다 자연스럽나?	✅ 매치다 / match-da
도메인 확보	`.com`을 잡을 수 있나?	✅ `matchda.com` 확보
확장성	기능이 늘어도 이름이 안 걸리나?	✅ 매칭이라는 가치 중심
의미	이름만으로 뭐 하는지 감이 오나?	✅ "매치"에서 유추 가능
중복	같은 이름의 서비스가 많나?	✅ 상대적으로 희소

이 중에서 개인 개발자가 가장 놓치기 쉬운 게 도메인 확보다. 아무리 좋은 이름이라도 .com이 이미 팔렸거나 터무니없는 가격이면 쓰기 어렵다. 그래서 나는 이름 후보를 정하기 전에 도메인부터 검색하는 순서로 바꿨다. 이름을 먼저 사랑에 빠진 뒤 도메인이 없어서 좌절하는 일을 막기 위해서다.

💡 팁: 이름 후보가 떠오르면 곧바로 도메인 등록 사이트에서 .com 여부를 확인하자. 동시에 상표·앱스토어에 같은 이름이 있는지도 검색해 두면 나중에 문제를 피할 수 있다.

이름을 바꾸면 손대야 할 곳들

이름 하나 바꾸는 게 생각보다 일이 많다. 실제로 손댄(또는 손대야 할) 목록이다.

도메인 연결 — matchda.com 등록 및 배포 연결 (기술 상세는 별도 글)
서비스 내 브랜드명 — 로고, 헤더, 메타 태그, OG 이미지
외부 노출 지점 — 포트폴리오, 소개 페이지, 링크
OAuth 리다이렉트 URI — 도메인이 바뀌면 로그인 콜백도 갱신 (별도 글)

나는 이번에 우선 backtodev 포트폴리오부터 업데이트했다. 카드 제목을 JobRadar에서 매치다/Matchda로 바꾸고, 사이트 링크를 새 도메인으로 교체하고, "원래 JobRadar로 시작했다가 매치다로 리브랜딩했다"는 문장을 한국어·영어 설명에 함께 넣었다. 리브랜딩은 "이름을 바꿨다"로 끝나는 게 아니라, 바뀐 이름이 노출되는 모든 접점을 하나씩 정리하는 일이라는 걸 그때 실감했다.

트러블슈팅 — 리브랜딩하며 부딪힌 것들

상황	고민/함정	대응
기존 이름이 이미 여기저기 박혀 있음	GitHub 저장소명, 이미지 파일명, 포스트 slug 등	링크가 깨질 위험이 있는 건(파일명·slug) 그대로 두고, 노출용 브랜드명만 우선 교체
옛 도메인으로 들어오는 사용자	링크가 갑자기 죽으면 안 됨	옛 도메인 → 새 도메인 리다이렉트 유지
옛 이름의 흔적 검색 노출	구글에 JobRadar로 색인된 것	급하게 지우기보다 새 이름 콘텐츠를 쌓으며 자연스럽게 전환

핵심은 한 번에 완벽히 갈아엎으려 하지 않는 것이다. 사용자·검색엔진·기존 링크가 놀라지 않게, 노출 접점부터 순차적으로 바꾸는 편이 안전했다.

정리

JobRadar는 기능 설명형 이름이라 브랜드로 키우기 어려웠다
매치다(matchda) = "match + da"(모든 직업을 매칭) + 한국어 "매치다"의 어감 → 한·영 양쪽에서 뜻이 통함
좋은 이름 기준: 기억 용이성 · 발음 · 도메인 확보 · 확장성 · 의미 · 중복 회피
개인 개발자는 이름 정하기 전에 도메인부터 확인하는 습관이 중요
리브랜딩은 이름 교체가 아니라 노출 접점을 하나씩 정리하는 과정

코드만 잘 짜면 되는 줄 알았는데, 서비스를 서비스답게 만드는 건 결국 "이걸 뭐라고 부를 것인가"에서 시작하더라. 이름 하나에 이렇게 오래 고민해 본 건 처음이었지만, 매치다라는 이름을 확정하고 나니 프로젝트를 대하는 내 마음가짐부터 달라졌다. 이름이 방향을 정한다는 말을, 이번에 몸으로 배웠다.