새로워진 스냅덱, 더 빠른 덱 제작 흐름을 만나보세요.

Wanted Sans: 스타트업 제품 문장을 브랜드 자산처럼 보이게 하는 법

Wanted Sans 공식 썸네일 애니메이션

공식 출처: wanteddev Wanted Sans GitHub

Wanted Sans 공식 썸네일
공식 썸네일은 Wanted Sans가 단순 본문 폰트가 아니라 브랜드 목소리로 설계됐다는 점을 먼저 보여줘요. 채용, 커리어, 스타트업 서비스처럼 ‘사람’과 ‘기회’를 말해야 하는 화면에서 이 톤이 중요합니다. Wanted Sans GitHub
Wanted Sans 공식 미리보기 이미지
공식 미리보기에서는 한글과 라틴이 같은 브랜드 안에서 움직이는지 볼 수 있습니다. Wanted Sans는 제목과 본문을 모두 맡길 수 있지만, 가장 강한 장점은 한국어 제품 문장에 살짝 브랜드 표정을 남기는 데 있어요. Wanted Sans GitHub

실제 문장 샘플

Wanted Sans
채용·커리어 제품 문장에 Wanted Sans를 넣으면 이렇게 보여요

지원자가 제안서를 열람했어요. 포지션 설명과 합류 후 맡게 될 역할을 다시 확인해 주세요.

Wanted Sans는 이런 제품 문장을 너무 차갑게 만들지 않으면서도 화면을 전문적으로 정리해요. 스타트업 서비스에서 ‘친근하지만 허술하지 않은’ 톤이 필요할 때 특히 잘 맞습니다.

직무 카드Product Designer · 5년 이상
안내 문장제안 메시지를 검토하고 전송해 주세요.
데이터서류 검토 12명 · 인터뷰 3명

공식 자료에서 읽히는 핵심

  • 공식 README는 Wanted Sans를 원티드의 ‘일하는 사람들의 모든 가능성’이라는 정신과 맞닿은 글꼴로 설명합니다.
  • 기하학적인 모양을 바탕으로 곧은 인상과 읽기 쉬운 형태를 만들고, 제목과 본문에서 모두 쓸 수 있도록 설계됐습니다.
  • 7가지 기본 굵기와 가변 글꼴을 제공하고, 웹폰트 문서에는 jsDelivr를 통한 variable/static, split/complete 로딩 방식이 정리되어 있습니다.
  • 원티드 블로그는 도형 기반 구조에 인간적인 느낌을 더하고, 가독성과 범용성을 높이는 데 집중했다고 설명합니다.

실제로 만들기 좋은 화면

  • 채용 공고 리스트, 후보자 프로필, 제안 메시지, 인터뷰 일정처럼 사람과 데이터가 같이 나오는 화면
  • 초기 스타트업의 랜딩, 온보딩, 대시보드, 팀 설정처럼 브랜드 톤과 실용성이 동시에 필요한 제품 UI
  • 급여, 경력, 포지션, 태그, 상태값처럼 숫자와 짧은 한국어 라벨이 반복되는 카드형 인터페이스
  • 회사소개, 채용 브랜딩, 리브랜딩 캠페인처럼 너무 기업적이면 답답하고 너무 가벼우면 신뢰가 약한 화면

Wanted Sans는 스타트업의 말투를 꽤 잘 압축해요

Wanted Sans를 처음 보면 ‘깔끔한 한국어 산세리프’처럼 보일 수 있어요. 그런데 실제 제품 문장에 넣어보면 이 폰트의 방향이 더 분명해집니다. 프리텐다드처럼 완전히 중립으로 숨는 폰트도 아니고, 강한 디스플레이 폰트처럼 화면을 장악하는 폰트도 아니에요. 정보 전달을 하면서도 브랜드가 살짝 남습니다.

이 균형은 스타트업 서비스에서 꽤 중요합니다. 초기 제품은 브랜드 자산이 많지 않아서 폰트 하나가 화면의 인상을 크게 바꿔요. Wanted Sans는 설정 화면, 온보딩, 알림, 카드 제목 같은 평범한 UI 요소도 ‘임시로 만든 화면’처럼 보이지 않게 잡아줍니다.

특히 채용·커리어 도메인에서는 힘이 좋습니다. 직무명, 경력, 스킬, 제안 메시지, 인터뷰 일정처럼 정보는 차갑지만 내용은 사람과 연결되어 있거든요. Wanted Sans는 이 두 성격을 한쪽으로 무너뜨리지 않습니다.

공식 제작 의도를 읽으면 쓰임이 더 명확해져요

원티드 블로그는 리뉴얼된 원티드 심볼이 원, 세모, 네모 같은 기초 도형을 바탕으로 만들어졌고, Wanted Sans도 기하학적 도형을 응용해 형태를 잡았다고 설명합니다. 그래서 글자의 기본 인상은 정돈되어 있어요.

그런데 여기서 끝나면 차가운 기하학 폰트가 됩니다. 공식 설명에서 중요한 부분은 ‘인간적인 느낌’과 ‘유연한 곡선’이에요. 일반적인 도형 기반 글꼴의 정형화된 형태를 열고, 부드러운 인상을 더했다는 설명은 실제 화면에서도 꽤 느껴집니다.

그래서 Wanted Sans는 기술 SaaS의 날카로운 톤보다는 사람을 설득해야 하는 제품에 더 잘 맞아요. 채용, 커뮤니티, 교육, 생산성, 팀 협업, 크리에이터 도구처럼 사용자에게 계속 말을 걸어야 하는 화면에서 장점이 큽니다.

제품 UI에서는 카드와 메시지부터 넣어보세요

Wanted Sans를 테스트할 때는 히어로 제목만 보면 부족합니다. 후보자 카드, 팀 초대 메시지, 알림 센터, 가격 플랜, 온보딩 체크리스트처럼 실제 서비스에서 반복되는 조각에 넣어봐야 해요.

예를 들어 ‘지원자가 포트폴리오 링크를 업데이트했어요’, ‘다음 인터뷰 일정을 조율해 주세요’, ‘연봉 정보는 비공개로 저장됩니다’ 같은 문장을 14px와 16px로 확인해보세요. 이때 문장이 너무 가볍지 않고, 너무 딱딱하지도 않다면 Wanted Sans가 잘 맞는 프로젝트입니다.

숫자와 영문도 같이 봐야 합니다. Product Manager, 3-7 years, KRW 60M, Remote OK 같은 조합이 한국어 문장 옆에서 어색하지 않아야 합니다. Wanted Sans는 이런 혼합 정보 카드에서 브랜드 인상을 꽤 안정적으로 유지합니다.

웹폰트 운용은 split을 먼저 고민하세요

공식 웹폰트 문서는 variable/static, split/complete 로딩 방식을 나눠 제공합니다. 글 하나에서 그냥 complete CSS를 쓰는 건 쉽지만, 실제 서비스에서는 한국어 웹폰트 용량이 바로 문제가 됩니다.

랜딩 페이지나 캠페인처럼 첫 화면의 문구가 정해져 있고 굵기 범위가 제한적이면 split이나 필요한 굵기만 쓰는 방식이 더 낫습니다. 반대로 사용자가 입력한 한국어가 많이 나오거나 앱 전체를 Wanted Sans로 통일하려면 self-hosting과 캐시 전략을 같이 봐야 합니다.

Snapdeck 미리보기에서는 빠르게 비교하기 위해 variable complete CSS를 사용하지만, 제품에 넣을 때는 실제 문장 수, 폰트 표시 시점, fallback, layout shift를 꼭 확인하는 편이 좋아요.

어떤 폰트와 조합하면 좋은가요

한국어 중심의 스타트업 제품이라면 Wanted Sans 하나로도 꽤 많은 화면을 처리할 수 있습니다. 제목 700-800, 섹션 라벨 600, 본문 400-500 정도로 시작하면 계층이 자연스럽게 잡힙니다.

영문 헤드라인이 강한 글로벌 SaaS라면 Geist나 Satoshi를 제품명·영문 H1에 두고, Wanted Sans를 한국어 본문과 UI 라벨에 두는 조합이 좋습니다. 이때 Wanted Sans가 너무 브랜드성을 많이 가져가면 제목 폰트와 싸울 수 있으니, 굵기는 한 단계 낮춰보세요.

프리텐다드와 비교하면 Wanted Sans는 더 브랜드성이 있고, SUIT와 비교하면 조금 더 젊고 유연합니다. 그래서 금융·공공·통신보다 채용·교육·커뮤니티·B2B 스타트업 쪽에서 먼저 꺼내볼 만합니다.

라이선스와 실무 메모

공식 README는 Wanted Sans가 SIL Open Font License로 배포되며, 글꼴 단독 판매와 라이선스 변경을 제외한 상업적 행위, 수정, 재배포가 가능하다고 안내합니다. 실무에서는 GitHub URL, OFL 파일, 사용한 CSS 버전을 문서에 남겨두면 좋습니다.

한글 바탕이 본고딕에서 출발했다는 점도 기억해둘 만합니다. OFL 계열 폰트의 장점을 이어받은 만큼, 수정본을 만들거나 앱에 번들링할 때는 OFL의 이름·재배포 조건을 다시 확인하세요.

Snapdeck에서는 Wanted Sans를 ‘스타트업 제품 UI와 채용 브랜딩을 연결하는 폰트’로 분류합니다. 프리텐다드보다 더 목소리가 필요하고, Asta Sans보다 더 사람 중심의 문장이 많은 서비스라면 우선 비교해볼 만해요.

체크리스트

  • 채용 공고 카드, 후보자 프로필, 온보딩 문장처럼 실제 제품 문장을 넣고 14px-18px에서 확인하세요.
  • 영문 직무명, 숫자, 연봉, 날짜, 상태값이 한국어 문장 옆에서 어색하지 않은지 보세요.
  • variable complete CSS를 그대로 쓰기보다 split/필요 굵기/self-hosting 전략을 먼저 정하세요.
  • 공식 GitHub의 OFL.txt와 사용한 CDN 버전을 프로젝트 문서에 남기세요.