13개의 글꼴 파일과 이벤트 루프가 가르쳐 주는 것: 좋은 인터페이스는 기다림의 순서를 설계한다

min dulle

Hatched by min dulle

Aug 18, 2026

8 min read

88%

0

우리는 글꼴을 고를 때 대개 모양을 보고, 자바스크립트를 설계할 때는 기능을 봅니다. 그러나 둘은 사실 같은 문제를 다룹니다. 복잡한 가능성을 어떤 순서로 사람에게 경험하게 할 것인가라는 문제입니다.

화면에 글자가 나타나는 일은 단순히 글자를 저장하는 일이 아닙니다. 글꼴 파일에는 여러 형태와 조합의 가능성이 들어 있고, 브라우저는 그중 적절한 표현을 선택해 화면에 배치합니다. 자바스크립트 역시 한 번에 모든 일을 처리하지 않습니다. 현재 실행 중인 작업을 끝내고, 대기 중인 작업 가운데 다음 것을 선택하며, 사용자가 지각할 수 있는 흐름을 만들어 냅니다.

한쪽에는 100퍼센트 무료로 사용할 수 있는 13개의 글꼴 파일이 있습니다. 다른 한쪽에는 이벤트 루프라는 실행 모델이 있습니다. 얼핏 보면 전자는 디자인 자산이고 후자는 프로그래밍 개념입니다. 하지만 둘을 함께 바라보면 중요한 통찰이 드러납니다. 좋은 디지털 경험은 풍부한 선택지를 한꺼번에 드러내지 않고, 적절한 순간에 적절한 형태로 호출하는 시스템이다라는 사실입니다.

파일의 수와 경험의 속도는 같은 문제가 아니다

13개의 글꼴 파일이 있다는 말은 13개의 경험이 자동으로 생긴다는 뜻이 아닙니다. 파일은 가능성의 저장소일 뿐입니다. 어떤 파일을 언제 불러오고, 어느 화면에서 적용하며, 사용자가 실제로 보게 되는 글자에 얼마나 빨리 반영할지 결정해야 비로소 경험이 만들어집니다.

이 점은 자바스크립트의 이벤트 루프와 닮았습니다. 프로그램 안에는 수많은 일이 발생할 수 있습니다. 네트워크 응답을 기다리는 일, 버튼 클릭을 처리하는 일, 타이머를 실행하는 일, 화면을 다시 그리는 일이 모두 대기할 수 있습니다. 그렇다고 모든 일이 동시에 실행되는 것은 아닙니다. 이벤트 루프는 실행 가능한 작업들을 관리하면서 현재 작업을 끝내고 다음 작업으로 넘어갑니다.

여기서 핵심은 속도가 단순히 처리 능력의 문제가 아니라는 점입니다. 사용자는 시스템이 얼마나 많은 일을 할 수 있는지가 아니라, 지금 무엇을 먼저 보여 주는지를 경험합니다. 글꼴 파일이 아무리 많아도 첫 화면의 제목이 늦게 나타나면 사이트는 느리게 느껴집니다. 자바스크립트가 초당 수많은 연산을 수행해도 클릭 직후 화면이 멈추면 애플리케이션은 무겁게 느껴집니다.

이를 다음과 같은 식으로 생각할 수 있습니다.

내부의 풍부함은 외부의 즉시성과 다르다. 좋은 시스템은 많은 가능성을 갖되, 사용자가 마주하는 순간에는 적은 수의 결정을 빠르게 제공한다.

디자인과 코드에서 자주 발생하는 실수는 내부의 풍부함을 외부에 그대로 노출하는 것입니다. 모든 글꼴 변형을 한 번에 로드하고, 모든 기능을 초기 실행에 포함하고, 모든 데이터를 첫 화면에서 처리하려 합니다. 결과적으로 시스템은 풍부해지지만 경험은 둔해집니다.

이벤트 루프는 타이포그래피의 시간 구조를 설명한다

글꼴은 보통 공간의 문제로만 취급됩니다. 글자의 폭, 높이, 굵기, 줄 간격을 조정하는 식입니다. 그러나 화면에서 읽는 행위는 시간의 경험이기도 합니다. 글자가 언제 나타나는지, 문장이 언제 안정되는지, 로딩 중 배치가 얼마나 흔들리는지가 읽기의 리듬을 바꿉니다.

예를 들어 뉴스 사이트에 접속했을 때 처음에는 기본 글꼴로 본문이 나타났다가 잠시 후 다른 글꼴로 교체된다고 해 봅시다. 글자의 폭이 달라지면 줄바꿈이 바뀌고, 문단의 높이도 변합니다. 사용자는 단순히 글꼴이 바뀌었다고 느끼지 않습니다. 읽던 문장이 이동하고, 시선의 위치를 잃고, 페이지가 불안정하다고 판단합니다.

이 현상은 이벤트 루프가 처리해야 하는 작업의 우선순위와 연결됩니다. 화면에 당장 필요한 작업과 나중에 처리해도 되는 작업을 구분하지 않으면, 덜 중요한 작업이 중요한 작업을 막습니다. 글꼴을 선택하는 일도 마찬가지입니다. 첫 화면의 제목과 핵심 본문에 필요한 자원은 우선적으로 준비해야 하지만, 사용자가 아직 열지 않은 메뉴의 세부 글꼴까지 같은 시점에 불러올 이유는 없습니다.

이것은 단순한 최적화 요령이 아닙니다. 무엇을 지연시킬 것인지 결정하는 일은 무엇을 존중할 것인지 결정하는 일입니다. 사용자의 시간, 주의력, 네트워크 환경을 존중한다면 모든 것을 즉시 실행하려는 태도를 버려야 합니다.

자바스크립트에서 긴 작업 하나가 실행되면 다른 이벤트가 대기해야 합니다. 사용자가 버튼을 눌러도 화면 갱신이 늦어지고, 스크롤이 끊기며, 입력이 밀립니다. 인터페이스는 기능적으로 작동하지만 심리적으로는 응답하지 않는 상태가 됩니다. 글꼴에서도 비슷한 일이 일어납니다. 너무 많은 파일을 초기 로딩에 묶으면 콘텐츠가 늦게 안정되고, 페이지의 첫인상이 손상됩니다.

따라서 좋은 웹 경험은 다음의 질문을 던져야 합니다.

  1. 사용자가 가장 먼저 알아야 할 것은 무엇인가?
  2. 그 정보가 안정된 형태로 나타나기까지 어떤 작업이 필요한가?
  3. 지금 처리하지 않아도 되는 작업은 무엇인가?
  4. 지연이 발생하더라도 사용자가 이해할 수 있는 상태를 보여 주고 있는가?

이 질문들은 프론트엔드 성능 점검표이면서 동시에 편집과 디자인의 질문이기도 합니다.

무료라는 조건은 배포의 문제가 아니라 설계의 문제다

글꼴이 100퍼센트 무료라는 사실은 큰 실용적 가치를 가집니다. 비용과 법적 제약이 낮아지면 더 많은 사람이 사용할 수 있고, 개인 프로젝트부터 상업적 서비스까지 적용 범위가 넓어집니다. 그러나 자유롭게 사용할 수 있다는 사실이 곧바로 좋은 사용으로 이어지는 것은 아닙니다.

자유는 선택지를 늘립니다. 선택지가 늘어나면 설계의 책임도 커집니다. 13개의 파일을 모두 사용할 수 있다는 것은 13개를 모두 사용해야 한다는 뜻이 아닙니다. 오히려 어떤 환경에서 어떤 변형을 선택할지, 어떤 자원은 미리 준비하고 어떤 자원은 필요할 때 불러올지 판단해야 한다는 뜻입니다.

이 구조는 이벤트 루프의 비동기 처리와 비슷합니다. 비동기는 모든 일을 동시에 한다는 뜻이 아닙니다. 기다리는 동안 다른 유용한 일을 수행하고, 준비된 결과를 적절한 시점에 연결하는 방식입니다. 글꼴 파일도 마찬가지입니다. 한 가족 안에 여러 스타일이 있어도 사용자의 현재 맥락에 필요한 것만 먼저 연결할 수 있습니다.

가령 독서 중심의 페이지라면 본문에 사용할 기본 글꼴을 먼저 확보하고, 강조용 굵은 글꼴이나 인터페이스용 변형은 실제로 필요할 때 준비할 수 있습니다. 편집 도구라면 사용자가 선택한 스타일만 우선 적용하고, 나머지 스타일은 선택 목록에 표시하되 초기 화면의 안정성을 방해하지 않게 할 수 있습니다. 이때 중요한 것은 파일 개수가 아니라 노출 순서와 호출 조건입니다.

이를 선택지 관리의 세 층으로 나눌 수 있습니다.

1. 저장된 가능성

파일, 코드 모듈, 데이터, 스타일처럼 시스템이 보유한 자원입니다. 많을수록 유연하지만, 많다는 이유만으로 사용자에게 즉시 노출할 필요는 없습니다.

2. 대기 중인 가능성

필요할 수 있지만 아직 실행하거나 불러오지 않은 자원입니다. 이벤트 루프의 대기열처럼 이 층에서는 순서와 우선순위가 중요합니다.

3. 경험된 가능성

사용자가 실제로 보고, 누르고, 읽고, 이해한 결과입니다. 시스템의 품질은 첫 번째 층의 규모가 아니라 세 번째 층으로 전환되는 과정의 매끄러움으로 평가됩니다.

많은 제품은 첫 번째 층을 키우는 데 집중합니다. 기능을 추가하고 파일을 늘리고 선택지를 확장합니다. 그러나 사용자가 체감하는 품질은 두 번째 층을 어떻게 관리하는지, 그리고 세 번째 층에서 얼마나 적은 마찰로 결과를 제공하는지에 달려 있습니다.

좋은 인터페이스는 주의력의 이벤트 루프를 설계한다

이벤트 루프가 프로그램의 실행 순서를 관리한다면, 인터페이스는 사용자의 주의력 순서를 관리합니다. 사용자는 화면의 모든 요소를 동시에 읽지 않습니다. 제목을 보고, 맥락을 파악하고, 버튼을 찾고, 세부 내용을 훑습니다. 디자인은 이 순서를 직접 지시하지 않더라도 시각적 위계와 시간적 등장 순서를 통해 유도합니다.

여기서 글꼴은 단순한 장식이 아닙니다. 글꼴의 크기와 굵기, 간격과 대비는 어떤 정보가 먼저 이벤트 루프에 들어갈지를 결정합니다. 굵은 제목은 주의력의 우선 큐에 들어가고, 작은 보조 문구는 후순위 큐에 들어갑니다. 잘 만든 페이지는 모든 정보를 같은 목소리로 말하지 않습니다.

반대로 모든 요소가 강조되면 우선순위가 사라집니다. 모든 버튼이 굵고, 모든 문장이 큰 글자로 표시되며, 모든 알림이 즉시 등장하면 사용자는 무엇이 중요한지 판단해야 합니다. 시스템이 처리해야 할 부담을 사용자에게 떠넘기는 셈입니다.

이 관점에서 접근성도 새롭게 보입니다. 접근성은 특정한 사용자를 위한 추가 기능이 아니라, 주의력 처리 비용을 낮추는 설계입니다. 명확한 대비, 안정적인 줄바꿈, 예측 가능한 위치, 충분한 입력 반응은 사용자가 자신의 인지 자원을 콘텐츠에 사용할 수 있게 합니다.

가장 좋은 인터페이스는 사용자의 주의를 빼앗지 않는다. 사용자가 주의를 어디에 둘지 쉽게 결정하게 한다.

실제로 적용할 때는 다음과 같은 작은 실험이 유용합니다. 페이지를 처음 열고 3초 동안 아무것도 누르지 않은 채 관찰합니다. 가장 먼저 보이는 것이 브랜드 장식인지, 핵심 메시지인지, 로딩 오류인지 확인합니다. 그다음 키보드로 이동해 봅니다. 포커스가 어디에 있는지, 입력 후 반응이 언제 나타나는지 살핍니다. 마지막으로 느린 네트워크나 낮은 성능의 기기에서 같은 흐름을 시험합니다.

이 실험은 코드의 실행 순서와 디자인의 시선 순서를 동시에 드러냅니다. 무엇이 먼저 준비되고, 무엇이 뒤로 밀리며, 어디에서 사용자의 인내심이 소모되는지 보이기 때문입니다.

자원을 배치하는 기술에서 자원을 기다리게 하는 기술로

성숙한 설계는 무엇을 추가할지보다 무엇을 기다리게 할지를 더 잘 결정합니다. 글꼴의 경우에도 모든 파일을 동일하게 취급하지 않는 것이 핵심입니다. 기본 본문용 파일은 초기 경로에 두고, 특정 언어 지원이나 장식적 스타일은 조건부로 불러올 수 있습니다. 사용자가 실제로 도달할 가능성이 낮은 화면의 자원은 그 화면의 진입 시점까지 미뤄도 됩니다.

코드에서는 이 원칙을 작업 분할이라고 부를 수 있습니다. 하나의 거대한 작업을 여러 작은 작업으로 나누면 브라우저가 사용자 입력과 화면 갱신에 다시 응답할 기회를 얻습니다. 콘텐츠에서도 같은 일이 가능합니다. 한 번에 모든 설명을 노출하는 대신 핵심 요약을 먼저 제공하고, 상세 정보는 사용자의 요청에 따라 펼치게 할 수 있습니다.

다만 지연은 그 자체로 좋은 것이 아닙니다. 무작정 미루면 사용자는 시스템이 고장 났다고 생각합니다. 따라서 지연에는 두 가지 조건이 필요합니다. 첫째, 무엇이 먼저 나타날지 명확해야 합니다. 둘째, 나중에 나타날 항목이 준비 중이라는 사실을 사용자가 이해할 수 있어야 합니다.

여기서 중요한 개념은 지연의 신뢰성입니다. 1초 늦더라도 매번 같은 순서로 나타나는 인터페이스는, 빠르지만 레이아웃이 계속 흔들리는 인터페이스보다 더 안정적으로 느껴질 수 있습니다. 예측 가능성은 속도의 일부입니다.

디자이너와 개발자가 함께 사용할 수 있는 실용적 기준은 다음과 같습니다.

  • 첫 화면에서 반드시 보여야 하는 것과 나중에 보여도 되는 것을 분리합니다.
  • 자원마다 중요도, 용량, 실패했을 때의 영향을 기록합니다.
  • 긴 작업 하나가 입력과 화면 갱신을 막고 있지 않은지 확인합니다.
  • 글꼴이 바뀌어도 줄바꿈과 주요 요소의 위치가 크게 흔들리지 않게 설계합니다.
  • 사용자가 기다리는 동안 빈 화면 대신 의미 있는 임시 상태를 제공합니다.
  • 무료로 쓸 수 있는 자원도 라이선스 조건과 배포 방식을 확인해 장기적인 신뢰를 확보합니다.

이 원칙은 특정 글꼴이나 특정 언어에만 해당하지 않습니다. 이미지, 동영상, 분석 스크립트, 번역 데이터, 추천 알고리즘에도 그대로 적용됩니다. 모든 자원은 비용을 가진다는 사실을 인정하면, 비용은 돈뿐 아니라 시간, 메모리, 주의력, 화면의 안정성까지 포함한다는 것을 알게 됩니다.

Key Takeaways

  • 파일의 수와 경험의 품질을 분리해서 생각하세요. 많은 자원을 보유하는 것보다 사용자의 현재 맥락에 필요한 자원을 먼저 연결하는 일이 중요합니다.
  • 첫 화면의 작업을 우선순위 큐로 다루세요. 핵심 콘텐츠, 입력 반응, 화면 안정성을 막는 작업은 먼저 처리하고 장식과 부가 기능은 뒤로 미룹니다.
  • 글꼴을 시간의 요소로 설계하세요. 글자의 모양뿐 아니라 등장 시점, 교체 과정, 줄바꿈의 안정성까지 함께 점검해야 합니다.
  • 지연을 숨기지 말고 설계하세요. 기다림이 필요하다면 사용자가 현재 상태와 다음에 일어날 일을 이해할 수 있도록 만드세요.
  • 성능을 처리량이 아니라 주의력의 흐름으로 측정하세요. 사용자가 무엇을 먼저 보고, 언제 반응을 얻고, 어디에서 읽기를 중단하는지 관찰하세요.

결국 글꼴과 이벤트 루프의 만남이 알려 주는 것은 간단하지만 깊은 사실입니다. 디지털 시스템은 가능한 모든 것을 즉시 보여 주는 장치가 아닙니다. 그것은 가능성의 집합을 시간 순서로 번역하는 장치입니다.

13개의 파일은 잠재력입니다. 이벤트 루프는 그 잠재력을 순서로 바꾸는 규칙입니다. 인터페이스는 그 순서가 사용자의 눈과 손, 기억 속에서 어떻게 경험될지를 결정합니다. 그러므로 좋은 제품을 만드는 질문은 “무엇을 더 넣을까?”에서 끝나서는 안 됩니다. 더 중요한 질문은 이것입니다.

사용자가 지금 이 순간 감당할 수 있는 가장 중요한 하나는 무엇이며, 나머지는 어떤 순서로 기다려야 하는가?

이 질문을 품으면 글꼴 선택은 미적 취향을 넘어 자원 배치가 되고, 비동기 코드는 기술적 구현을 넘어 인간의 주의력을 보호하는 장치가 됩니다. 가장 세련된 시스템은 가장 많은 것을 동시에 말하는 시스템이 아닙니다. 필요한 순간에 필요한 목소리만 정확히 들려주는 시스템입니다.

Sources

← Back to Library

Hatch New Ideas with Glasp AI 🐣

Glasp AI allows you to hatch new ideas based on your curated content. Let's curate and create with Glasp AI :)

Start Hatching 🐣