폰트/타이포그래피/디자인

앱 폰트 결정을 기획부터 출시까지 순서대로 정리했습니다

글쓴이 · 폰트비2026년 9월 11일

시안이 거의 완성됐을 때 "이 폰트, 앱에 넣어도 되나요?"라는 메시지를 받는 순간, 디자이너는 머릿속으로 빠르게 계산을 시작한다. UI를 처음부터 다시 잡아야 할 수도 있다는 것을. 그때는 이미 늦다.

앱 폰트 결정은 기획 초반에 방향을 잡고 단계마다 확인하면서 가는 게 맞다. 기획에서 출시까지, 각 단계에서 무엇을 확인해야 하는지 순서대로 정리했습니다.

타이밍을 놓치면 무엇이 되돌아오나

폰트 결정이 늦어질수록 되돌아오는 비용이 커진다. 단계마다 어떤 상황이 생기는지를 먼저 보는 게 이 글을 읽는 이유입니다.

디자인 완성 후 라이선스 문제 발견
시안을 전부 잡은 다음에 "이 폰트 앱 임베딩 안 돼요"가 나오면, 폰트 교체는 폰트 파일 하나 바꾸는 게 아니다. 글자 크기·자간·줄높이·텍스트 박스 여백을 전체 화면에서 다시 검토해야 한다. 컴포넌트가 20개라면 조정 대상도 20개다.

개발 착수 후 포맷 문제 발견
디자이너가 Figma에서 쓴 폰트를 "그냥 이거 써주세요"로 넘기면 개발팀에서 막힌다. Figma에는 WOFF2나 구글 폰트 URL로 끌어온 폰트가 섞여 있는데, 앱 번들에는 TTF 또는 OTF만 쓸 수 있다. 개발팀이 직접 파일을 구해오거나 작업을 멈추고 확인을 요청하는 상황이 생긴다.

출시 직전 라이선스 고지 누락 발견
OFL 폰트는 앱 내 법적 고지 화면에 라이선스를 포함하는 것이 조건이다. 출시 직전에 이게 빠진 걸 알면, QA 일정 안에 화면을 새로 만들어 넣어야 한다.

세 상황의 공통점은 하나다. 앞 단계에서 챙겼으면 발생하지 않는다.

기획에서 시스템 폰트로 충분한지 먼저 판단합니다

앱의 성격이 폰트 선택의 첫 번째 기준입니다.

시스템 폰트가 더 나은 경우

계산기, 날씨, 메모, 가계부 같은 유틸리티 앱은 정보를 빠르고 명확하게 전달하는 것이 핵심이다. iOS는 SF Pro, Android는 Roboto와 Noto Sans KR을 기본 폰트로 제공합니다. 두 폰트 모두 가독성 최적화 설계가 되어 있고, 시스템 렌더링을 그대로 쓰므로 별도 파일을 번들에 포함할 필요가 없습니다. 앱 용량도 아낄 수 있고, 동적 타입(접근성 글자 크기 조정)도 자동으로 따라온다.

"다국어 지원이 필요한 앱"도 시스템 폰트가 유리하다. 한국어·영어·일본어를 동시에 쓰는 경우, 커스텀 폰트를 굵기별·언어별로 묶으면 번들이 급격히 무거워진다. Noto Sans 계열 시스템 폰트는 이 문제를 별도 비용 없이 처리한다.

단, SF Pro는 앱 번들에 직접 포함할 수 없습니다. Apple이 제공하는 시스템 API를 통해서만 사용 가능하며, 파일을 다운로드해 직접 끼워 넣는 방식은 Apple 라이선스 위반입니다.

커스텀 폰트가 필요한 경우

패션 쇼핑몰, 게임, 감성 다이어리처럼 첫 화면에서 브랜드 인상이 잡혀야 하는 앱은 시스템 폰트만으로는 한계가 있습니다. 커스텀 폰트가 브랜드 분위기를 결정하는 핵심 요소가 되거든요.

다만 현실적인 비용이 따릅니다.

한글 폰트 TTF 파일 하나는 글리프 수에 따라 2~10MB 수준입니다.
굵기를 여러 개 쓰면 번들 크기가 빠르게 늘어납니다.
iOS의 동적 타입을 커스텀 폰트로 지원하려면 별도 구현이 필요합니다.

이 점을 기획 단계에서 개발팀과 먼저 합의해 둬야 이후에 번복이 없다.

폰트를 고르면서 라이선스를 동시에 확인합니다

"나중에 확인하지"는 이미 한 번 실수를 허용한 것입니다. 무료 폰트라도 앱 임베딩이 허용되지 않는 경우가 있습니다.

OFL(SIL Open Font License) 폰트

나눔고딕, Pretendard, Noto Sans KR 등 많은 한글 폰트가 OFL로 배포됩니다. OFL 폰트는 앱 번들에 포함하는 것이 허용됩니다. 단, 두 가지 조건이 있습니다.

첫째, 앱 내 법적 고지 화면에 해당 폰트의 저작권 표기와 OFL 라이선스 원문을 포함해야 합니다. iOS는 Settings 번들, Android는 오픈소스 라이선스 화면이 일반적인 위치입니다. 항목이 작아도 되고 링크 처리도 가능합니다.

둘째, 폰트 파일 자체를 별도로 판매하는 것만 금지됩니다. 앱에 번들로 포함하거나 상업적으로 배포하는 것은 OFL이 명시적으로 허용합니다.

앱에 실제로 포함한 굵기의 라이선스만 고지하면 되고, 사용하지 않는 굵기까지 전부 포함할 필요는 없습니다.

상업 폰트

일부 폰트는 인쇄·영상 사용은 무료이지만 앱 임베딩은 별도 라이선스 구매가 필요합니다. 라이선스 안내에 "임베딩 별도 문의" 또는 "소프트웨어 탑재 불가"라고 명시된 경우입니다. 디자이너가 시안에 쓴 폰트가 여기 해당한다면, 개발 착수 전에 비용 확인과 라이선스 구매가 선행되어야 합니다.

이 과정을 단축하려면 폰트비에서 해당 폰트의 상세 페이지를 먼저 열어보는 게 빠릅니다. 인쇄, 영상, 웹, 앱, BI/CI 등 용도별 허용 여부가 정리되어 있어서, 라이선스 원문을 처음부터 뒤지지 않아도 됩니다. AI 폰트 찾기를 활용하면 분위기와 용도로 폰트를 먼저 추려볼 수도 있습니다.

임베딩 가능 여부를 확인한 뒤, 실제 다운로드와 라이선스 원문 확인은 폰트 제작사의 공식 배포처에서 합니다. 라이선스 분쟁이 생길 경우 가장 확실한 증빙은 공식 배포처에서 받은 원문입니다. 다운로드 시점의 라이선스를 텍스트 파일로 따로 저장해 두는 것이 좋습니다.

개발 착수 전에 파일 포맷과 굵기 목록을 명확히 넘깁니다

이 단계에서 가장 많이 생기는 마찰이 포맷 혼선입니다. 파일은 TTF 또는 OTF다. WOFF2는 웹 브라우저 전용 포맷이므로 앱 번들에는 맞지 않는다. Figma에서 구글 폰트를 그대로 끌어 쓴 경우, Figma 화면에서는 잘 보이지만 개발팀에 전달할 수 있는 파일 형식이 따로 필요하다. "Figma에 있는 걸 쓰면 되지 않나요"는 이 지점에서 막힌다.

한글 폰트는 글리프 수가 많아 기본 TTF 파일이 2~10MB에 달하는 경우가 많습니다. 앱에서 실제로 사용하는 글리프만 추출한 서브셋 폰트를 만들면 500KB 이하로 줄어드는 경우도 있습니다. 번들 크기가 앱 다운로드 전환율에 영향을 주므로, 서브셋 처리 여부를 개발팀과 미리 상의해 두는 것이 좋습니다.

Thin, Light, Regular, Medium, Bold처럼 굵기마다 파일이 별도로 있습니다. 앱에서 실제로 쓰는 굵기만 번들에 포함해야 합니다. 디자인 시안에서 쓴 굵기를 목록으로 정리해 개발팀에 넘기는 게 불필요한 확인을 줄이는 가장 빠른 방법입니다.

출시 직전, 렌더링과 고지 화면을 실기기에서 확인합니다

앱 번들에 포함된 폰트 파일과 실제 화면에서 렌더링되는 폰트가 일치하는지 확인합니다. 의도치 않게 fallback 폰트가 출력되는 경우를 이 단계에서 잡아냅니다. 시뮬레이터에서는 보이지 않던 문제가 실기기에서 나오는 경우가 있어서, 대표 기기 2~3종으로 직접 확인하는 게 안전하다.

법적 고지 화면에 폰트 라이선스가 정확히 표기되어 있는지도 확인합니다.

기획 단계에서 폰트가 결정되어 있으면, 개발 착수 회의에서 라이선스 이야기를 꺼낼 필요 자체가 없다. 먼저 굳혀놓는 것이 전부입니다. 아직 폰트를 못 정한 단계라면 폰트비 AI 폰트 찾기에서 분위기와 용도를 넣어보는 것부터 시작해도 됩니다.