제품 개발

4

Quollect

독서하다 만난 좋은 문장, 어떻게 저장하고 계신가요? 좋은 독서 노트 앱을 찾아 헤맨 분이라면 공감하실 겁니다. 메모장에 옮겨 적다 귀찮아서 포기하거나, 사진만 찍어두고 나중에 못 찾거나. 저도 그랬습니다. 독서 기록을 위해 14개의 앱을 써봤지만 만족스러운 게 없더군요.. 그래서 직접 만들었습니다. 이름은 퀄렉트(Quollect)이고, 아래는 소개 영상입니다. 직접 만든 이유 가장 중요하게 생각한 건 책 읽는 흐름을 방해하지 않는 선에서 가장 간결하게 문장을 수집하는 것과 독서 통계였죠. 이 두 가지 기능이 있는 독서 기록 앱은 있었지만 기능은 많아 복잡하거나, 심플한데 정작 필요한 기능이 빠져 있거나 하는 경우가 많았죠. 독서 기록 앱은 많지만 디자인 측면에서 아쉬운 것들이 많았고, 세련되고 좋은 사용성을 갖춘 디자인만으로도 경쟁력이 있을것 같다고 생각했습니다. Quollect의 핵심 기능 찍고, 드래그, 저장 책을 읽다 마음에 드는 구절을 발견하면, 카메라로 찍습니다. 그 다음 필요한 부분만 드래그해서 선택하면 끝. 30초면 충분합니다. 페이지 번호와 독서 메모 추가 저장한 구절에 페이지 번호를 기록하거나, 짧은 생각을 독서 메모로 남길 수 있습니다. "이 부분이 왜 좋았는지"를 나중에도 기억하고 싶을 때 유용합니다. 책별로 정리된 독서 기록 저장한 구절은 책 단위로 자동 정리됩니다. 특정 책을 열면 그 책에서 모은 구절만 쭉 보입니다. 나중에 "그 책에서 인상 깊었던 부분이 뭐였지?" 할 때 바로 찾을 수 있습니다. 책 구절 저장부터 검색까지 한 앱에서 해결됩니다. AI 서평 기능 (PRO) 최근 업데이트에서 AI 서평 기능이 추가됐습니다. 저장한 문장들을 바탕으로 AI가 독서 내용을 정리해 줍니다. 서평 내용의 비중이나 길이, 말투, 그리고 추가 요청사항을 전달해 내가 원하는 느낌의 서평을 쉽게 완성해보세요! 직접 써보세요 Quollect는 감히 얘기해보건데, 현존하는 독서 기록 앱중 가장 아름답고 사용하기 좋습니다. Quollect는 앱스토어, 플레이스토어에서 모두 무료로 다운로드할 수 있습니다. 독서 기록과 정리의 필요성은 알지만 귀찮았던 분, 퀄렉트가 독서를 더욱 쉽게, 그리고 깊게 할 수 있도록 돕습니다. Quollect iOS 다운로드 Quollect 안드로이드 다운로드

2026.03.17·1분 읽기·만든것

바이브코딩, 나만 어려워?

코딩 없이 앱 만들기, 정말 되는 걸까? 나는 디자이너 출신이다. 웹 코딩을 10년 했고, 최근에는 바이브 코딩으로 모바일 앱까지 직접 만들었다. 그 과정에서 확신하게 된 것이 하나 있다. "바이브 코딩을 잘하려면 코딩을 어느 정도는 알아야 한다." 간단한 건 코딩 몰라도 된다. 랜딩 페이지 하나, 간단한 계산기 정도는 자연어만으로 충분하다. 하지만 데이터베이스를 붙이고, 로그인을 구현하고, 결제까지 연결하려면 이야기가 완전히 달라진다. AI가 제대로 고쳤는지, 확인할 수 없는 불안감 자연어로 요청하면 AI가 뭘 어떻게 바꿨는지 확인하기 어렵다. 건드리면 안 되는 로직을 건드렸는지, 기존에 만들어둔 기능이 망가지진 않았는지. 코드를 읽을 줄 모르면 매번 직접 하나하나 테스트하는 수밖에 없다. 코드를 보고 로직을 파악할 줄 알면 이런 실수를 훨씬 줄일 수 있다. 제품이 커져도 퀄리티를 유지하는 핵심 능력이다. 실제로 Veracode 분석에 따르면 AI가 생성한 코드의 45%에서 보안 결함이 발견됐고, 보안 취약점은 사람이 작성한 코드보다 2.74배 높았다. 아마존도 AI 코딩 도입 후 일주일에 크리티컬 사고 4건을 기록했다. 코드를 검증할 줄 모르면 이런 문제를 그냥 넘기게 된다. AI 코딩 한계는 결국 사용하는 사람의 지식에 달려 있다. 코드를 알면 AI에게 정확한 지시를 내릴 수 있다 코드를 이해하는 수준으로 알아두면 바이브코딩 실력이 확 달라진다. 예를 들어 UI를 수정하고 싶을 때, "하단 확인 버튼의 모서리를 좀 더 부드럽게 둥글려줘"라고 말하는 대신, 해당 코드 블록을 멘션하면서 **"이 버튼의 border-radius를 12px로 변경해줘"**라고 할 수 있다. "부드럽게"는 해석의 여지가 있다. 하지만 "12px"는 답이 하나다. 지시가 명확하면 AI가 정확히 알아듣는다. 바이브코딩 코딩 지식이 있으면 이런 소통이 자연스럽게 가능해진다. 바이브코딩 공부, 최소한 이것만은 알아두자 변수, 함수, 반복문. 코드가 어떻게 작성되어 있고 어떻게 연결되어 있는지. 실행 순서가 어떻게 되는지는 파악할 수 있어야 한다. 전부 외울 필요 없다. 코드를 읽고 "이 함수가 저 데이터를 받아서 처리하는구나" 정도만 이해하면 충분하다. 이 정도만 알아도 AI가 작성한 코드에서 문제를 발견하거나, 수정 방향을 잡는 게 훨씬 수월해진다. 프린트문 하나면 디버깅이 달라진다 AI에게 "프린트문을 활용해 로그를 자세히 남겨달라"고 요청해보자. 디버깅할 때 정말 큰 도움을 받을 수 있다. 어디서 에러가 나는지, 어떤 값이 넘어오는지 로그로 바로 확인할 수 있다. 코드를 완전히 이해하지 못해도 문제 지점을 좁혀나갈 수 있다. 코딩 없이 앱 만들기를 시도하는 사람이라면 이 방법부터 익혀두자. 코드를 몰라도 쓸 수 있는 가장 강력한 디버깅 도구다. 점진적으로 배우면 된다 한꺼번에 다 배울 필요 없다. 처음엔 HTML 태그 이름만. 그다음엔 CSS 속성. 그다음엔 JavaScript 변수와 함수. AI가 작성한 코드를 읽으며 하나씩 배워가면 된다. 계속 자연어로만 하려다 보면 지치기 마련이다. 같은 요청을 세 번, 네 번 반복하면서 원하는 결과가 안 나올 때의 피로감. 코드 용어를 조금만 알아도 이 과정이 훨씬 줄어든다. 그것이 바이브코딩 공부의 시작이다. 결론 바이브 코딩은 강력하다. 하지만 코딩 지식 없이는 AI 코딩 한계에 금방 부딪힌다. "코드를 읽을 줄 알면, 바이브 코딩은 10배 더 강력해진다." 지금 당장 AI가 작성한 코드를 한 줄씩 읽어보자. 모르는 부분은 AI에게 설명해달라고 하면 된다. 그것이 바이브코딩 실력을 키우는 첫걸음이다.

2026.03.17·2분 읽기·아티클

디자이너가 바이브코딩 강의를 했더니, 결과는?

디자이너가 바이브코딩 코스를 하면 반응이 어떨까? 12명의 수강생을 모시고 최근 4주간. 매 주 3시간씩 진행했던 "바입빌딩 1기"를 마무리하며 회고를 작성해본다. 원래 강의할 생각은 없었다.. 사시 처음에는 강의를 할 생각은 없었다. 직접 만든 독서 기록앱 Quollect로 작게나마 수익을 얻게 되었고, 이 경험을 지난 7월 12일, 프롬이라는 디자이너 커뮤니티에서 공유하게 되었다. 프롬 디자이너 커뮤니티 오프라인 첫 발표! 약 40여 명의 디자이너분들이 들으러 와주셨는데 끝나고 정말 많은 관심과 질문을 주셨다. 뒷풀이 자리에서도 바이브 코딩으로 제품 만드는 것에 대한 질문을 엄청 받았다. 그날 밤 집에 오면서, 더 많은 디자이너들에게 이 이야기를 소개해보고 싶었다. 자료를 정말 열심히 만든게 아깝기도 했고 😂 그래서 개인적으로 같은 내용이되, 그날 받은 질문들을 고려해 내용을 보완하고 이번에는 웨비나로 한 번 더 발표를 할 계획을 세우고 웨비나를 소개하는 랜딩페이지를 만든 뒤, 디자이너 커뮤니티 몇 군데에 공유했다. [웨비나 소개 페이지] 디자이너 혼자 바이브 코딩으로 앱 제작부터 수익까지! 목표 날짜는 7월 30일이었고, 바이브코딩 관련된 질문을 자유롭게 주고 받을 수 있도록 별도의 오픈 카톡방도 만들어서 공유했다. 이름은 바입 코딩 클럽, 아래 링크를 통해 입장할 수 있다. 바입코딩클럽 오픈 카톡방 두 건의 유료 강연 요청과 코스를 해봐야겠다는 생각 해당 링크를 뿌려놓고 나니 며칠 뒤 AI 커뮤니티를 운영하시는 리더 두 분이 각 커뮤니티를 위해 동일한 내용의 발표를 해줄 수 있냐고 요청을 해오셨다. 하나는 7월 19일, 다른 하나는 7월 22일. 살다보니 내가 돈을 받고 강연을 할 날이 오다니, 조금 실감나진 않았지만 두 건의 발표를 하면서 더 많은 질문을 받았고, 직접 만든 오픈 카톡방에도 점점 더 많은 사람들이 들어와 300명이 넘었다. 많은 분들이 구체적인 내용을 최대한 공유드렸음에도 여전히 "어떻게"를 질문하셨고, 이야기로 전하는 것을 넘어 바이브 코딩으로 제품을 만드는 과정을 함께하는 코스를 만들어봐야겠다는 생각까지 이르렀다. 지난 10년간 코딩하는 디자이너로서 제품을 만들어오며 공부했던 모든 것을 압축해, 바이브코딩으로 제품을 만드는 기본 사이클을 직접 경험시켜주는 그런 강의. 나의 목표는 강의를 듣고 나면 "이제 나도 바이브 코딩으로 내 제품을 만들 수 있겠다"는 자신감을 심어드리는 것이다. 그리고 그 강의를 7월 30일, 마지막 웨비나에서 공개하고 강의는 8월 9일에 시작해 4주간 매 주 3시간씩 진행하기로 했다. 강의 커리큘럼 준비와 공개, 그리고 12석 매진 7월 30일, 프롬 디자이너와 함께 웨비나를 진행했고 프롬 디자이너 웨비나 계정 제약상 100명 인원제한이 있어 100분과 함께 웨비나를 시작했고, 마지막에 강의를 공개했다. 강의 가격 책정에 많은 고민이 있었지만 여러 고민 끝에 40만원으로 책정했다. [바입빌딩] 바이브코딩으로 앱 제작부터 수익까지! 적지 않은 금액이라 과연 12명이 다 채워질까 싶었는데 강의 전날 8월 8일, 남은 두 자리가 모두 채워져 총 12 자리가 만석 상태로 8월 9일 강의를 시작할 수 있었다. 4주 동안 무엇을 다뤘나? [1주차] 서비스 구성 요소, 코딩 기본의 이해, 그리고 바로 바이브코딩 실습 : 120 슬라이드 첫 주차에는 전반적인 서비스 개발에 필요한 요소들과 각 요소들의 관계를 알아보고, 코드를 어느정도 읽을 수 있는 능력을 기르기 위한 코딩의 기본 개념들을 학습한 뒤 바로 바이브 코딩으로 Todo 앱을 제작했다. 이날 준비한 슬라이드는 120장이었다 😂 서비스 구조의 이해 위 이미지는 직접 정리한 서비스 개발에 필요한 요소와 관계도다. 바이브코딩으로 코딩 자체에 대한 장벽은 낮아졌지만 내가 원하는 서비스를 만들기 위해 무엇이 필요한지 모르면 어떤 질문, 어떤 요청을 해야할지 알기 어렵다. 따라서 나는 전체적인 구조를 알고 진행하는 것이 매우 중요하다고 생각해서 이 장표를 만들었고, 강의를 진행하면서 종종 이 장표를 다시 들고와 우리가 어떤 부분을 건드리고 있는 것인지 설명하며 진행했다. 나중에 본인의 서비스를 만들더라도 이를 지도처럼 사용해주신다면 더할 나위없이 보람찰 것 같다. 단도직입, 바이브코딩 실습! 바이브코딩을 배우러 왔으니 첫 날부터 뭔가 직접 구현해보는 경험이 동기부여에 좋을거라고 생각해서 첫날부터 Todo 앱을 만드는 실습을 진행했다. 시간과 좀 더 매끄러운 코스 진행을 위해 디자인은 미리 준비해두었고, 첫 날 환경설정으로 많은 분들이 헤메시기도 했지만 강의 끝나고 다같이 카페로 이동해 도와드린 결과 대부분 화면 구현을 하실 수 있었다. [2주차] 앱 기획 과정과 수요 확인, Github 과 Supabase Google 로그인 구현 : 149 슬라이드 1주차 수업에서 내 생각보다 환경 설정과 코딩에 대한 기본 개념을 많이 힘들어하셨다. 환경 설정이 힘들거라는 얘기를 듣긴 했지만 내 상상 이상이었고, 한 분씩 봐드리다보니 시간이 생각보다 많이 소요됐다. 2주차 강의때 부터는 본인이 각자 만들고 싶은 서비스를 만드는 방식으로 진행하려고 했었는데 그것 보다 간단한 것부터 기본 개념을 더 확실히 익히는 것이 중요한 상황이라고 판단됐다. 그래서 기획에 대한 내용은 이론으로 진행하고 본인 서비스 기획은 별도로 진행하는 것으로 양해를 구한 뒤, 4주차 까지 원래 다루고자 했던 내용들을 모두 Todo 앱에 적용하는 방향으로 강의를 재구성했다. 그래서 이 날은 프로젝트 관리를 위한 Github 사용법을 다루고, 이제는 필수인 간편 로그인을 구현하는 실습을 위주로 진행했다. 2주차 슬라이드는 149장이었다 😂 Github이 무엇인지, 어떻게 작동하는 것인지, 그리고 왜 필요한지에 대해 다루고 실제 Github으로 Todo 프로젝트를 관리하는 실습을 진행했다. Supabase에서 Google 로그인을 구현하기 위해 Google Cloud Console 을 직접 설정해보는 실습도 진행했다. Google Cloud Console의 수많은 버튼과 메뉴에 다들 조금은 버거워했지만 결국 대부분 구글 로그인까지 성공할 수 있었다. [3주차] 데이터베이스와 사용자 행동데이터, 이해와 활용 : 132 슬라이드 데이터베이스 이해와 활용 모든 서비스가 데이터베이스가 필요한 것은 아니지만 데이터베이스를 사용해야할 경우, 서비스를 직접 운영하는 관점에서는 데이터베이스의 구조를 잘 알고 있는 것이 중요하다. 그렇다면 데이터베이스의 테이블과 컬럼, 그리고 다른 테이블과 어떻게 관계 맺어 사용하는지 등을 알아야한다. 따라서 3주차에는 관계형 데이터베이스에 대한 이해를 시작으로, 실습 Todo 앱에 필요한 요소들을 고려해 테이블 컬럼을 구성하고, AI를 통해 전달받은 SQL 코드를 활용해 테이블 생성, 그리고 실제 앱 기능과 데이터베이스를 연결해 Todo 아이템 생성시 데이터베이스에 잘 추가되는 것 까지 실습을 진행했다. AI는 우리가 어떤 생각을 하는지 정확히 알지 못하기 때문에 꼭 필요하지 않은 것들도 넣어서 코드를 작성하는 경우가 많다. 간단한 프로젝트라면 문제 없겠지만, 내가 오래 끌고갈 제품이라면 직접 한 번 읽고 불필요한 것은 제거해달라고 재요청하는 것이 제품에 대한 장악력을 갖는 것에 많은 도움이 되며 개인적으로는 꼭 필요한 과정이라고 생각한다. 사용자 행동 데이터의 이해와 앰플리튜드 붙여보기 처음 바이브코딩을 하게되면 높은 확률로 사용자 행동 데이터까지 다룰 여유는 없을 것이다. 당장 기능 개발하는 것만도 버겁기 때문인데, 서비스를 운영하다보면 어느 순간에는 사용자가 내 서비스를 "잘 쓰고 있는지" 궁금할 때가 온다. DAU, MAU, 리텐션등 구글 애널리틱스만 붙여도 많은 데이터들을 볼 수 있지만, 앱에 들어와서 사용자들이 어떤 행동을 하고 있는지를 알고 싶은 때가 온다면, 그 때가 바로 이벤트 단위 트래킹이 필요한 순간이다. 서비스 개발에 아주 필수는 아니지만 강의에 넣었고, 이 부분은 과제로 내드렸다. (많은 분들이 조금 지쳐계셔서 과제 체크를 빡세게 하진 않았지만.. 몇 분은 준비한 슬라이드를 하나씩 따라하시면서 이벤트 수집에 성공하셨다!) [4주차] Admob 광고의 이해와 활용, 그리고 배포와 결제 상품 붙이기 : 256 슬라이드 😂 드디어, 바로 어제 끝난 대망의 마지막 주차 강의. 기획부터 제작까지 많은 시간과 노력을 들인 서비스가 그냥 나의 심리적 만족으로 끝나면 너무 아쉽다. 많은 분들이 앱을 만들어서 어떻게 돈을 벌 수 있는지 궁금해하셨고, 가장 흔하고 우리도 가장 쉽게 시도해볼 수 있는 것이 바로 광고이기 때문에 커리큘럼에 넣게 되었다. Admob의 이해와 Admob 붙이기 웹은 Adsense를 사용하고 모바일은 Admob으로 광고를 붙인다. 실습은 모바일앱을 만드는 과정이기 때문에 Admob을 기준으로 어떤 과정을 통해 앱 제작자에게 수익이 돌아갈 수 있는지 큰 그림을 먼저 설명했다. 무엇이든 큰 그림을 알고 세부 내용을 파악하면 길을 잃지 않는다. 큰 그림을 파악한 뒤에는 광고 성과 파악을 위한 기본 적인 용어와 개념들을 다뤘다. 제품 고도화에 시간을 쏟는 것도 물론 중요하지만, 광고가 내 서비스의 주 수익원이라면 광고를 통해 내가 얼마를 벌 수 있을지 가늠해가면서 서비스 방향성을 고민하는 것 또한 중요하기 때문이다. Admob 에는 총 6가지 다양한 광고를 붙일 수 있는데, 각 광고의 특징을 알아 본 뒤, 결과적으로 Todo 앱에는 하단 배너와 앱 오픈 광고 두 가지를 붙이는 실습을 진행했다. 배포와 앱 결제 상품 붙이기 (RevenueCat 활용) 이제 열심히 만든 앱을 앱스토어와 플레이스토어에 테스트를 거친 뒤 배포할 때이다. 테스트와 배포는 애플 개발자 계정 연 99달러, 구글 개발자 계정 평생 25달러의 비용이 발생하기 때문에 실습으로 진행하지 못했지만, 배포 과정을 눈으로 익히실 수 있도록 내용을 준비했다. 또한 인앱 결제나 광고 제거 상품등 구독 결제 상품이 필요할 때를 대비해 구글 플레이와 앱스토어 코드를 따로 직접 관리하지 않고 RevenueCat을 사용해 모두 관리하는 방법도 다루었다. Admob 관련 내용은 79 슬라이드에서 끝났는데, 배포와 결제 상품 붙이는 과정에 App developer, App Store Conect, Google Cloud Console, Google Play Console, 그리고 RevenuCat 웹사이트까지 여기저기 절차가 복잡하다보니 256슬라이드까지 만들게 되었다 😂 아무래도 전달할 내용이 많았다보니 실습 시간은 상대적으로 적었는데, 그럼에도 강의 들으시면서 테스트 광고를 붙이신 분들도 계셨다. 너무 감사했던 수강하신 분들의 피드백들, 그리고 마무리 누군가 가르친다는 것이 쉽지 않다는 것을 알고는 있었고, 그래서 많이 노력했지만 정말 쉽지 않았다. 더 쉽게 전달할 방법은 없었을지, 어떻게 했었어야했을지 등 반성하게 되는 부분이 있음에도 수강하신 분들이 고마움을 표현해주시고 격려해주신 덕분에 더 열심히 할 수 있었던 것 같다. 이번 강의를 만들면서 약속했던 것이 "이제 나도 바이브 코딩으로 내 제품을 만들 수 있겠다" 하는 자신감을 심어드리는 것이었는데 이야기 나눠보니 그래도 80% 이상은 그렇게 느끼시는 것 같다. 강의가 끝나서 더 소통이 없어질까봐 아쉬워하시는 분들이 계신것 같아 디스코드 채널은 열어두고 소통을 이어나가기로 했다. 2기는 언제 열리나요? 2기는 언제 열거냐는 질문도 종종 받고 있는데, 사실 강의 하면서 나도 너무 힘들다보니 2기는 못하겠다 싶었는데, 수강하신 분들의 응원과 격려로 아마 2기까지는 하게될 것 같다. 시점은 고민중이지만 너무 멀지 않은 미래로 생각중이다. 더 재미있게 쓰고 싶었는데.. 지난 시간을 기록하는 목적이 더 크다보니 건조하게 쓰여진 것 같아 조금은 아쉽지만, 아주 오랜만에 쓰게 된 이번 블로그 글을 이만 맺어본다.

2025.08.31·7분 읽기·아티클

폰트 확장자별 크기와 용도 정리!

폰트는 확장자에 따라 용도와 크기가 다르다. 앱이나 웹사이트를 만들 때 용량이 큰 폰트를 포함하면 로딩 속도나 성능에 영향을 미칠 수 있다. 요즘은 시스템 폰트를 사용하거나 CDN을 이용해 별다른 고민 없이 폰트를 적용할 수 있지만, 앱이 오프라인 상태에서도 작동해야 하는 경우에는 폰트를 직접 포함해야 할 수도 있다. 그런 상황을 맞이한 누군가를 위해 폰트 확장자별 크기와 용도를 정리해본다. Thread에 짧은 글로 썼더니 반응이 좋아 롱폼으로도 정리한다. 결론부터 말하자면 구형 기기를 지원할 필요 없을 경우 .woff2 하나면 충분하다. Woff2를 쓰는데도 크게 느껴진다면? 한글 폰트같은 경우, .woff2를 써도 용량이 크게 느껴질 수도 있다. 잠시 영문과 한글폰트의 아주 기본적인 차이에 대해 얘기해보자면 이렇다. 영문 폰트는 대소문자와 숫자, 특수문자까지 포함해도 약 100자로 구성되지만, 한글은 자주 사용되는 최소 상용자인 2,350자를 포함해야 해서 용량이 크다. 근데 한자는? 상용자만 2만개가 넘는다 😂 근데 만약 이걸 두께별로 Regular, Medium, Bold를 만든다면? 모두 다 디자이너들이 직접 눈으로 봐가며 균형을 맞춰야한다. 그래서 한글은 본문용으로 균형이 잘 잡힌 폰트를 만들려면 1-2년씩 걸린다. 중국은 너무 압도적인 개수 탓인지 기술이 엄청 발달했다. 사실 돈이 많이 되지 않을텐데 이런 곳에 돈을 투자하는 문화는 좀 배울필요가 있다. 어쨌든, 이야기가 길었다. 결국 한글 폰트는 용량이 크니까 최대한 용량 작은 것을 찾아써야한다는 말이다. 근데 만약 woff2를 쓰는데도 용량이 크게 느껴진다면? subset을 활용하는 방법이 있다. 아래 방법으로 더 최적화해보자. Subset으로 폰트 파일 크기 더 최적화 하기 Subset이란 기존 폰트 파일에서 필요한 문자만 포함한 좀 더 작은 셋의 폰트 파일을 말한다. 예를 들면 중국어 폰트에 너무 많은 글자들이 있어서 폰트 파일 하나만 100메가가 넘어가는 경우라면, 서비스에 사용되는 폰트들만 추려서 작은 셋의 폰트 파일을 만드는 것이다. 출시 이후부터 많은 사랑을 받고 있는 Pretendard도 일본어 폰트인 JP 버전을 보면 한자가 많다보니 subset을 지원하고 있다 이 파일들 중 원하는 글자를 포함한 폰트들을 모아서 폰트 파일 합쳐주는 서비스를 이용해 커스텀 서브셋 폰트를 만들어 이용할 수 있다. 예를 들면 transfonter 같은 곳이 있다. 사실 앱 만들 때에는 시스템 폰트를 쓰는것이 좋다고 생각한다 😂 폰트도 신경쓰기 시작하면 참 번거롭다. 사람들이 폰트 때문에 서비스를 쓰거나 쓰지 않거나 하진 않기 때문에, 정말 브랜딩이 너무 중요한 것이 아니라면 사용성과 앱 개발의 편의를 위해 시스템 폰트를 쓰는 것을 추천한다.

2025.02.03·2분 읽기·아티클