스냅덱 폰트 사이트를 만들며

snapdeck font는 처음부터 서비스를 만들려고 한 게 아니었어요.

Snapdeck를 만들면서 폰트 고르는 데 시간이 자주 새요. 슬라이드 제목 하나, 본문 조합 하나, UI 버튼·입력창 타이포 — AI로 생성 속도는 올랐는데 폰트를 정하고 라이선스를 확인하는 구간에서는 손이 멈추는 날이 많았어요. 한글은 영문 미리보기와 실제 적용 결과가 다른 경우도 많고, "무료"라고 적혀 있어도 OFL인지, 상업 사용 가능한지, 원 출처가 어디인지 매번 다시 봐야 했어요.

그래서 Snapdeck 제품에 넣을 폰트를 고르기 전에, OFL 기준으로 라이선스 문제가 크지 않은 폰트를 모아두고 팀 안에서 비교·걸러내기 위한 리서치 사전작업 공간이 필요했어요. 기획서나 로드맵 없이, 사이트를 만드는 데 약 2시간을 투자했어요. 그 2시간 안에 데이터를 모으고, UI를 붙이고, font.snapdeck.app에 올렸어요.

2시간 중 대부분은 코딩이 아니라 디깅이었어요. Google Fonts, 눈누, Fontshare, Open Foundry, xz 등 각 사이트를 돌면서 OFL·무료 조건에 맞는 폰트를 긁어모으는 작업이에요. "한글 지원 되나", "OFL 맞나", "슬라이드 제목용으로 무겁지 않나", "Snapdeck 다크 UI 톤이랑 맞나" — 탭을 여러 개 열어두고 하나씩 확인하는 시간이 더 길었어요. 코딩은 그나마 짧았어요.

왜 사이트였나

스프레드시트에 URL을 쌓거나 Notion 페이지에 링크 모음을 만들 수도 있었어요. 근데 폰트 리서치는 보는 작업이라서, 링크 목록만으로는 부족했어요.

"Pretendard + Inter를 슬라이드 제목·본문으로 쓰면?" — 이걸 판단하려면 실제 문장, 같은 크기, 같은 맥락에서 나란히 봐야 해요. Google Fonts에서 하나 열고, 눈누에서 또 열고, Fontshare에서 또 — 비교는 결국 머릿속에서 하게 되고, 탭만 늘어나요.

Snapdeck 본 제품과 별개로, 폰트 고르는 구간만 떼어내서 한 화면에서 처리하려고 사이트를 만들었어요. 팀 내부용 리서치 도구에 가깝고, URL만 열려 있는 형태예요.

폰트를 찾다가

폰트를 파고들수록 하나가 분명해졌어요. 내가 모르는 예쁜 폰트가 생각보다 훨씬 많다는 것.

팀이 평소 쓰던 Pretendard, Inter, SUIT 정도의 짧은 후보 목록 밖에도, 슬라이드 제목용으로 쓸 만한 것, 본문용으로 가독성 좋은 것, UI 버튼·라벨용으로 밀도 맞는 것 — 용도마다 괜찮은 선택지가 Google Fonts, 눈누, Fontshare 쪽에 곳곳에 있었어요. Fontshare 쪽 영문 UI 폰트, 눈누 쪽 한글 디스플레이 폰트, Google Fonts 쪽 범용 sans — 출처가 달라도 한 화면에서 훑고 걸러내는 게 필요했어요.

디깅하면서 정리한 기준은 대략 이랬어요.

OFL 또는 상업 사용 리스크가 낮은 라이선스
한글·영문 모두 쓸 수 있는지 (또는 용도별로 구분)
굵기 범위 — UI·슬라이드 둘 다 쓰려면 400~700 정도는 있어야 함
출처 — 나중에 원문 라이선스 확인할 때 찾을 수 있어야 함

이 기준으로 모아두니, Snapdeck UI 작업할 때 "일단 font.snapdeck.app부터"가 습관이 됐어요.

눈누와 UI — 세로 스크롤, 가로로 긴 행

눈누는 한국어 무료 폰트를 찾을 때 당연히 봤어요. 카드형 레이아웃이 예쁘고, 폰트 소개·분류도 잘 돼 있어요. 다만 폰트를 하나씩 디깅하는 작업 — 후보 50개를 10분 안에 훑고 5개만 남기는 작업 — 에는 UI가 맞지 않았어요.

카드마다 크기·여백·정보 배치가 달라서 시선이 분산돼요. 스크롤할 때마다 "다음 후보"로 넘어가는 리듬이 끊기고, 탐색보다 구경에 가깝게 느껴졌어요. 후보군을 좁히는 데 시간이 더 들었어요.

나에게 맞는 UI가 뭔지 고민하다 DaFont를 다시 봤어요. DaFont는 페이지 자체는 세로 스크롤이에요. 아래로 내리면 다음 폰트, 그다음 폰트 — 익숙한 목록 흐름. 그런데 각 폰트 한 줄(한 행)은 가로로 길게 펼쳐져 있어요. 미리보기 샘플, 이름, 카테고리, 다운로드 수, 라이선스 힌트 — 필요한 정보가 한 행 안에 가로로 나란히 들어와요.

스크롤 방향: 세로 (페이지 전체)
정보 배치: 가로 (한 행 안)
인터랙션: 행 클릭 → 상세, 스크롤 → 다음 후보

snapdeck font도 이 구조를 따랐어요.

세로 스크롤 — 아래로 내리며 후보를 연속적으로 봐요
가로로 긴 행 — 미리보기·이름·굵기·출처(Google Fonts / 눈누 / Fontshare 등)·라이선스 힌트를 한 줄에
라이트·다크 미리보기 — 폰트가 어디에 적용될지 모르니까, 밝은 UI와 어두운 UI 양쪽에서 동시에 봐요

폰트는 랜딩 페이지에 쓸 수도 있고 Snapdeck처럼 다크 UI에 쓸 수도 있어요. 한쪽만 보여주면 고른 뒤에 Figma나 코드에서 다시 확인해야 해서, MVP 단계부터 라이트·다크를 넣었어요.

snapdeck font 웹 화면

2시간 — 만들고 올리기

UI 형태를 정한 뒤 나머지는 빠르게 붙였어요.

OFL·무료 조건에 맞는 폰트 목록 (디깅으로 수집)
세로 스크롤 + 가로 행 레이아웃
라이트/다크 토글
Snapdeck 도메인 서브도메인 font → font.snapdeck.app

딱 2시간이면 됐어요. 대시보드, 온보딩, "Coming soon" 페이지, 회원가입 — 없어요.

올린 뒤 Snapdeck UI 작업할 때, 슬라이드 폰트 고를 때 북마크 하나로 들어가서 썼어요. Product Hunt, 런칭 공지, 팀 내 발표, SNS 홍보 — 전혀 안 했어요. 개인적으로 쓰기에 충분히 만족했고, 지인 몇 명에게 "이거 써봐" 하고 링크 공유하는 정도였어요. Snapdeck 본 서비스 메뉴나 공지에도 넣지 않았어요.

배포 후 — 조용히 쓰던 몇 주

font.snapdeck.app을 올린 뒤 며칠·몇 주는 특별한 일 없이 지나갔어요.

저는 Snapdeck 작업할 때 계속 썼고, 폰트 목록은 디깅하면서 조금씩 늘렸어요. 팀원 몇 명한테 링크를 줬고, 가끔 "이거 편하다"는 반응이 왔어요. traffic 숫자는 대부분 작았어요. 홍보를 안 했으니 당연한 수준이었어요.

그래도 진짜 단순한 analytics는 붙여뒀어요. GA 퍼널이나 코호트 분석 수준은 아니고, "오늘 몇 명 왔지", "어제랑 비슷한가", "어디서 들어왔지" 정도. font.snapdeck.app을 쓰면서 동시에 관찰하려고 했어요.

주 2회 오는 사용자

그러다 한 사용자가 보였어요.

제가 링크를 준 지인으로 보이지 않았고, referral 파라미터도 없었어요. UTM도 없고, 제가 공유한 Threads나 DM과도 연결되지 않았어요. 그런데 최소 매주 2번 — 월·목처럼 고정된 요일은 아니지만, 한 주에 두 번 이상 — 이 사이트에 들어오더라고요.

첫 주: 2번. 다음 주: 2번. 그다음 주: 역시. bot인지, 크롤러인지 한번 확인했지만, 동일 IP·동일 패턴의 의미 있는 체류가 이어졌어요.

홍보·광고·추천 없이 모르는 사람이 습관적으로 돌아온다 — 이게 이후에 Threads에 올릴지 말지 판단하는 기준이 됐어요. 일일 방문자 100명보다, 재방문 1명이 그 시점에서는 더 분명한 신호였어요. "나만 귀찮아서 만든 도구"가 아니라, 다른 사람도 실무에 쓰고 있다는 뜻이에요.

Threads — 2.4만 조회

재방문 패턴을 본 뒤 Threads에 올렸어요. 계정은 한동안 글을 안 써서 조회수가 잘 나오는 계정은 아니었어요. 팔로워 수도 많지 않았고, 최근 게시물 reach도 낮은 편이었어요.

올린 내용은 길지 않았어요. snapdeck font를 왜 만들었는지, 세로 스크롤 + 가로 행 UI, OFL 위주로 모아뒀다는 정도 — 스크린샷 하나 붙여서요.

올리자마자 반응이 왔어요.

"링크 알려주세요"
"한글 UI에도 되나요?"
"Mac에서 바로 설치되나요?"
"상업적으로 써도 되나요?" (→ 라이선스 확인 필요하다고 답변)

좋아요도 붙기 시작했고, 댓글 수도 빠르게 늘었어요. 게시물 조회수는 최종 약 2.4만, 실제 font.snapdeck.app 방문은 조회수 대비 괜찮은 편이었어요. "봤다"에서 "들어왔다"로 넘어간 비율이 — 홍보 없이 올린 글치고는 의미 있었어요.

Threads 게시물

referral 추적을 보면 유입이 Threads에만 있지 않았어요. initial referral 데이터상 LinkedIn DM, Slack 채널(팀·커뮤니티), direct·기타 경로로 링크가 전달되는 게 확인됐어요. Threads에 한 번 올렸지만, 링크는 DM·슬랙·카카오 등 여러 채널로 복사돼서 퍼진 형태예요. 단일 채널 게시물이 trigger가 됐고, 확산은 네트워크를 거친 거예요.

Snapfont — 3시간, 400명 이상

Threads 댓글에서 Mac에서 바로 설치 관련 문의가 반복됐어요.

font.snapdeck.app은 탐색·비교·라이선스 힌트 확인까지는 좋아요. 근데 "이 폰트로 결정"한 뒤 다운로드 → Mac에 설치 → Figma/코드에 적용까지 가는 동선은 여전히 귀찮았어요. 출처 사이트마다 다운로드 UI가 다르고, 설치 파일 형식도 (.ttf, .otf, .woff) 제각각이에요.

같은 프로젝트 안에서 약 3시간 더 투자해 Mac 앱 Snapfont를 만들었어요.

font.snapdeck.app에서 고른 폰트 다운로드
설치 전 미리보기
Mac 설치·관리

웹 2시간 + Mac 앱 3시간. 합쳐도 하루도 안 되는 투자예요.

Snapfont Mac 앱

400명 이상 다운로드됐어요. Snapfont 단독 홍보는 하지 않았고, font.snapdeck.app의 다운로드 페이지 링크와 Threads 댓글 답변 정도가 유입 경로였어요.

이후에 붙인 것들

웹 2시간, Mac 앱 3시간 이후에도 기능은 쓰다 보니 필요한 것부터 추가했어요. 처음부터 로드맵에 넣어둔 기능이 아니에요.

카탈로그·검색 — 폰트가 수천 개로 늘면서 "한글", "UI", "본문", "브랜드", "코드" 같은 키워드로 좁히는 게 필요해졌어요. 출처·굵기·유사 폰트도 한 행에서 같이 봐요.

페어링 — font.snapdeck.app/?view=pairs에서 헤드라인·본문 조합을 슬라이드, 랜딩, SaaS 대시보드 맥락별 실제 문장으로 한 번에 비교해요. "제목이랑 본문 같이 보고 싶다"는 사용·댓글 패턴에서 나왔어요.

라이선스 — 출처·라이선스 힌트를 미리보기 옆에 둬요. OFL·무료 여부를 빠르게 확인하되, 실제 사용 전 원문 라이선스 확인은 사용자 몫이에요. Snapdeck 제품에 넣을 때도 이 원칙 그대로예요.

에이전트 리소스 — Snapdeck 팀이 Codex·Claude로 UI 작업할 때, 프로젝트 맥락(한글 B2B 대시보드 vs 브랜드 타이틀 등)에 맞는 폰트 후보와 CSS 힌트를 고르게 하는 JSON·프롬프트예요. 실험적이지만 font.snapdeck.app과 Snapdeck 본 제품이 만나는 지점이에요.

지금 font.snapdeck.app에는 Google Fonts, 눈누, Fontshare, Open Foundry, xz 등 3,100개 이상 폰트가 모여 있어요.

지금

따로 홍보하지 않아도 사람들이 계속 방문하고 써요. traffic은 유지되거나 서서히 늘고 있어요.

"스냅덱 폰트"로 검색하면 상위에 노출돼요. Threads 이후 백링크가 쌓인 영향으로 보이고, SEO를 목적으로 설계한 것은 아니에요. 사용하고 공유하니까 검색이 따라온 쪽에 가까워요.

OnlyDecks나 Snapdeck 블로그와도 결이 비슷해요. 팀이 실무에서 겪은 병목을 작게 만들고, 조용히 열어두고, 반응이 오면 그때 확장하는 방식. font.snapdeck.app은 2시간짜 리서치 사이트에서 시작해서, 재방문·Threads·Snapfont·페어링·에이전트 리소스까지 이어진 상태예요.

앞으로도 홍보를 크게 하지 않더라도 꾸준히 늘 것 같아요. 폰트 고르는 게 작업 병목이라면 아래 링크부터 보면 돼요.