낸내 :: 광고 없이 상업적으로 이용할 수 있는 한글 폰트 모음 사이트
🎨

낸내 :: 광고 없이 상업적으로 이용할 수 있는 한글 폰트 모음 사이트

Created
Jun 7, 2021 10:38 PM
Tags
 
notion image
 
 
Vue를 복기할 겸? Figma 익숙해질 겸? 작은 서비스 하나를 구현했다.
이름은 낸내. 기존의 '눈누'라는 서비스를 타깃으로 만든 애플리케이션이다.
 
'왜 만들었을까?'를 먼저 말해보자면...
일단 눈누는 상업적인 용도로 사용이 가능한 무료 한글 폰트를 소개하는 웹 사이트이다.
처음에는 광고도 없었고, 폰트도 많아서 줄곧 사용했으나... 언젠가부터 눈에 띄게 증가했다.
그래, 뭐 서버비를 벌기 위해서는 어쩔 수 없다지만. 나는 불편했다.
 
개발자란 무엇인가? 불편함이 있다면 해결하는 사람이 아닌가? (아님말구)
그래서 기존 눈누에서 몇 가지 불편한 사항을 해결한, 동일한 아이템의 서비스를 하나 만들었다.
 
  • 서버
  • 광고
  • 라이선스
  • 그리고 약간의 퍼포먼스 개선...
 

눈누의 문제점

문제점 1 : 광고

서버 비용(눈누는 Nginx 기반의 서버를 구현해 사용중이다) 때문인지는 모르겠으나... 안타깝게도 광고가 너무 많다. 한번 보자.
 
notion image
 
위 사진은 눈누의 메인 페이지인데, 폰트 소개와 관련된 아티클은 단 하나밖에 없다.
누가 이런 서비스를 사용하고 싶어할까? 이 뿐만이 아니다.
심지어 저 '원스토어 모바일 POP체'를 클릭이라도 해버리면...
 
notion image
 
사용자의 흐름을 막아버리는 이런 광고가 나타나게 된다.
운영비로 인해 어쩔 수 없는 조치였겠지만... 이로 인해 나는 새로운 서비스를 만들고자 결심했다.

눈누의 문제점 2 : 라이선스

눈누라는 서비스를 분석하던 중 조금 의아한 부분이 있었다.
분명히 '재배포 불가'로 명시되어 있는 폰트인데, 눈누에서 이를 재배포하고 있었다.
실제 예를 하나 들어보자면, 다음과 같다.
 
  1. 폰트릭스에서 Rix열정도체를 개발 ⇒ 수정 및 재배포 불가 명시
  1. 폰트는 TTF 및 OTF 포맷만 개발됨
  1. 눈누의 GitHub에서는 WOFF 포맷의 폰트로 배포중
 
다시말해 눈누는 수정뿐만 아니라 재배포 까지도 하고 있는 상황이다.
폰트릭스와 사전에 어떠한 협약이 있었던 것일까?
 
내가 알 방법은 없지만, 낸내는 적어도 '재배포 가능한 폰트'만을 취급해야 한다는 판단이 들었다.
혹시나 발생될지 모르는 좋지 않은 상황을 항상 염두해 두어야 한다.
가장 좋은 방법은 애초에 그런 짓을 하지 않는 것이고.

눈누의 문제점 3 : 서버

눈누는 앞서 말했듯이 서버가 존재한다.
물론 서버는 당연히 존재해야 하겠지만... 문제는 이게 지출이 필요한 서버라는 것이다.
즉, 눈누라는 서비스를 제공하기 위해 지속적으로 지출이 필요하다는 말이 되며, 결국 광고를 통해 이 지출을 메꿀 수 밖에 없다.
 
그러나 광고는 어떤 방식을 사용하든 사용자에게 불편함을 끼칠 수 밖에 없다.
낸내는 이를 어떻게 해결했을까? 답은 간단하다.
그냥 지출이 필요한 서버를 사용하지 않으면 되는 것이다.
 
'비용을 지출하는 서버'가 없다는 말이다. 나는 그냥 GitHub Pages를 이용했다.
그럼 폰트 파일별 CSS 스크립트를 전달해야 하는 문제는 어떻게 해결했을까?
 
이것도 그냥 설정 파일(fonts.yml)과 GitHub Actions 그리고 jsdelivr을 이용해서 Deploy 전 모든 준비(필요한 파일 생성 및 설정)를 끝마치도록 구현했다.
이런 방식으로 지속적인 지출이 필요한 부분을 해결했다.

눈누의 문제점? 4 : 퍼포먼스

눈누는 새로고침 시마다 필요한 폰트 파일을 모두 서버에서 다시 다운로드한다. 그러나 폰트 파일은 변경될 일이 없는데, 굳이 이래야 했을까?
낸내는 Service Worker 및 Cache Storage API를 이용해 이를 해결했다.
 
다만 한 가지 우려되는 점이 하나 있다.
눈누는 현재 몇 십 개의 폰트를 불러오기만 해도 툭 툭 끊기는 현상이 발생된다.
 
이에 대해 낸내는 사전에 모두 필요한 파일을 로드하고 이를 캐싱하도록 하는데... 과연 몇 백 개의 폰트(구글처럼)가 불러와져도 괜찮을까?
당장에 테스트 하기에는 조금 힘들어서, 일단 나중의 일로 생각하고는 있다.
 
현재는 낸내에서 다루는 컴포넌트를 줄이는 방식으로 해결할 수 있을 것이라 생각하는데, 잘 될지는 아직 모르겠다.
 
아무튼 이런 방식으로 낸내라는 서비스를 만들게 되었고, 현재 서비스중이다.
아직 뭐 사용자는 당연히 없지만... 폰트 파일을 늘려가다 보면 점차 늘어날 것이라 생각한다.
뭐 없어도 내가 불편해서, 내가 사용하기 위해 만든 서비스여서... 크게 의미는 없다. 어차피 이득이 될 것도 없고 그러니.

해결

각각의 문제와 해결 방법은 이렇다
 
  1. 서버 : 비용 지출 ⇒ GitHub Pages + jsDelivr CDN
  1. 퍼포먼스 : 트래픽 및 렌더링 ⇒ Font Subset, Browser Storage API, Virtual Scrolling

문제 해결 1 : 비용 지출 줄이기

GitHub Pages를 이용해 무료로 파일을 배포하도록 하였으며
jsDelivr CDN 서비스로 더 빠르게 콘텐츠를 제공하도록 구성하였다
 
물론 GitHub Pages에도 Traffic Limit이 있었기에, 이는 Font Subset을 이용
적절하게 구현했다 생각한다
 
notion image
 
Font Subset을 사용하기 전과 비교해보면 5.7배 Blocking Time이 줄어든 것을 볼 수 있고
(Simulated Network Throttle : 10,240 Kbps Throughput)
 
notion image
 
네트워크 트래픽 역시 Font Subset을 통해 7.2배 줄어든 것을 확인할 수 있었다

문제 해결 2 : 폰트 파일 캐싱

Service Worker 그리고 Cache Storage API를 이용해 폰트 파일을 캐싱하도록 했다
그 결과는?
 
notion image
모든 폰트 파일을 Browser Storage에 캐싱하게 된다

문제 해결 3 : Virtual Scroll을 이용한 렌더링 퍼포먼스 개선

구현한 레이아웃에 적절하게 Virtual Scroll을 구현하여 10k 개 이상의 폰트가 렌더링되어도 퍼포먼스 이슈 없이 사용자가 콘텐츠를 마주할 수 있도록 구성하였다

그 후

210614

백 개 이상의 폰트를 추가해 놓으니 예상했던 대로 퍼포먼스 이슈가 생겼다.
이는 다음과 같이 해결.
 
  1. Storage usage estimation 해서 사용량 초과하면 Caching하지 않도록 함
  1. GitHub Pages 파일 분리해서 Pagination 구현
 
아직 좀 미흡한 점이 있는데... 이는 차차 해결해 나가야 할 문제다.
현재 파악하고 있는 미흡한 요소는 아래와 같다.
 
  • 검색 시 모든 폰트가 불러와지지 않음 (Pagination 적용으로 인함)
    • ⇒ 파일 분리하는 알고리즘 재정의 필요
 
notion image
 
그리고 최근 일 주일 간 사용자가 0.1k를 넘어섰다.
광고 효과 때문이겠지만..
아무튼 하루에 열 명의 방문자만 꾸준하게 있어도 좋겠다.

210623

notion image
 
현재는 일주일에 300~400명의 사용자가 있는 것 같다. 하루에 대략 50~70명 가량...
아마 광고 때문이겠지만... (광고는 7월 7일까지 진행된다.)
그 기간 사이에 최대한 사용자를 확보해 놓아야 하지 않을까 싶다.

210707

Virtual Scrolling 및 Font Subset을 이용해 UX를 증대시켰고, 검색 이슈도 해결했다. 다만... Size Limit으로 인해 Actions를 이용한 Build 시 파일 유실이 발생됨을 확인.
임시적으로 Local에서 Build하는 방식으로 처리하고 있기는 한데... 고쳐야 한다.
이 방식으로 진행해버리면 PR 시 바로 Build → Deploy가 이뤄지지 않는다.

210718

Build 방식을 고쳤다. 방법은 간단했다.
그냥 Fonts를 저장할 리포지터리를 하나 생성하고, 거기서 관리하도록 하면 되었던 것.
이런 방식으로 상당히 서비스 리포지터리가 깔끔해지게 되었다. 좋다.
actions/cache 를 이용해 Actions에서 Deps를 캐싱하도록 하여 Build 속도도 한 층 높여봤다.
나쁘지는 않은 듯?..
 
남은 건 이제 SEO 향상만 남았는데... 아직도 SEO로 인해 잘 검색되지 않는것이 아쉽다.
애초에 처음부터 nuxt로 구현할 걸 그랬나 싶다.
 

Loading Comments...