Justif - 웹을 위한 Knuth-Plass 양쪽 정렬과 마이크로타이포그래피

• Justif는 브라우저 기본 렌더링과 출판물 수준의 텍스트 양쪽 정렬을 직접 비교하는 웹 데모임
• 하이픈 처리와 글자 돌출, 너비 확장, 자간 조절, 마지막 줄 간격 맞춤을 각각 설정할 수 있음
• 최소 마지막 줄 너비와 문장부호 내어쓰기 범위를 조절하고 text-wrap: pretty 적용 결과와도 비교 가능함
• 영문 문학·기술 문서뿐 아니라 히브리어·아랍어 RTL 텍스트와 일본어를 serif, sans, monospace 서체로 시험할 수 있음
• 줄 수, 하이픈 줄바꿈, 넘치는 줄, 짧은 마지막 줄, 공백 편차와 리버(rivers) 등을 브라우저 렌더링과 나란히 측정함

---

양쪽 정렬과 세부 설정

• Justif는 웹에서 Knuth-Plass 양쪽 정렬과 여러 마이크로타이포그래피 기능을 시험할 수 있도록 구성됨
  • 하이픈 처리
  • 글자 돌출
  • 너비 확장
  • 자간 조절
  • 마지막 줄 간격 맞춤
• 문장부호 내어쓰기는 글자 돌출을 활성화해야 사용할 수 있으며, 줄 끝과 첫 줄 시작 또는 전체 범위에 적용 가능함
• 최소 마지막 줄 너비는 0.33, 본문 너비는 13em으로 조절할 수 있음

텍스트·서체 비교와 측정

• Alice in Wonderland, Frog Prince, Frankenstein, Ulysses, 기술 포스트, RFC 2324, 서체 견본 중에서 비교할 텍스트를 선택할 수 있음
• 히브리어·아랍어 RTL 텍스트와 일본어 텍스트도 제공함
• 지원 서체는 Junicode, EB Garamond, Alegreya, IM Fell English, Vollkorn, Amstelvar, Latin Modern, Georgia, Roboto Flex, Courier Prime, IBM Plex Mono 및 시스템 글꼴을 포함함
• 결과를 클릭하거나 길게 누르면 브라우저 기본 렌더링이 드러나 Justif 렌더링과 비교할 수 있음
• 비교 도구는 text-wrap: pretty, 흐림 처리, 여백 눈금자, 불균일한 공백 표시를 지원함
• 측정 항목은 줄 수, 하이픈 줄바꿈, 넘치는 줄, 짧은 마지막 줄, 리버와 함께 평균 공백, 자연스러운 공백 대비 평균 편차, 표준편차, 가장 넓은 공백을 포함함

[GN⁺]

Lobste.rs 의견들

• 이 프로젝트는 Fable로 바이브 코딩했음 https://news.ycombinator.com/item?id=48946738#49002419

  • 글의 주제가 바이브 코딩이 아닌데도 정말 해당 태그가 필요한지 의문임
    LLM 사용기를 읽는 데 관심이 없어 걸러내고 싶지만, 실제로는 코딩 도우미를 사용했다는 의심만 있어도 본문과 무관하게 태그가 붙는 듯함
    이번에는 사용 사실이 명백하지만, 코딩 도우미를 쓰는 기여자를 받는다는 이유만으로 프로젝트 글에 태그가 붙은 경우도 봤음
  • 이 프로젝트를 만들 때 LLM을 사용했음을 거리낌 없이 인정함
    다만 바이브 코딩이라는 용어와 여기서 쓰는 태그는 이미 효용을 잃었으며, LLM 사용을 다루는 글과 제작 과정에서 우연히 LLM을 사용한 결과물을 구분하는 더 정확하고 생산적인 표현이 필요함
  • 바닷가재 1: “암을 치료하는 약을 개발했대!”
    바닷가재 2: “그래… 그런데 AlphaFold와 CRISPR, 그리고… 두구두구… Fable을 썼대”
    바닷가재 1: “세상에, 용납할 수 없어! 인류를 위해 전부 버리고 다시 칠판에 색연필로 단백질을 그리는 데 40년을 쓰자!”

• 결과물이 아주 멋지며, microtype 패키지를 쓰지 않은 TeX보다도 더 나아감
  이런 조판 기능은 브라우저가 직접 처리해야 함
  일부 브라우저가 text-wrap: pretty를 구현했지만 몇 줄 정도로 제한되는 듯함

  • 요즘 Safari에는 pretty가 제대로 구현돼 있지만, justify와 함께 쓰면 버그가 있음
    https://matklad.github.io/2026/02/14/justifying-text-wrap-pretty.html
  • text-wrap: pretty 명세를 보면 동작이 정의되지 않은 순수한 힌트임
    사용자 에이전트가 속도보다 나은 배치를 우선하고 줄바꿈을 결정할 때 여러 줄을 고려해야 한다는 정도이며, 그 외에는 auto와 같음
    지나치게 짧은 마지막 줄, 글줄 사이의 강처럼 보이는 공백, 연속된 하이픈 등을 피할 수 있지만 정확한 개선 방식은 브라우저마다 다름
    여러 브라우저가 서로 다르게 구현하겠다고 하자 지나친 제약을 피하려고 명세에 들어간 것으로 기억함
    구현체가 결국 SQLite를 쓸 것이라는 사실이 노출돼 Web SQL이 폐기된 것과 비슷한 사정임
    언젠가는 이 기능들이 text-wrap: auto에 기본 적용돼 text-wrap: pretty가 아무 효과도 내지 않기를 바라며, https://bugzilla.mozilla.org/show_bug.cgi?id=630181 도 구현되길 기대함
    이런 힌트는 새롭지 않으며 will-change도 이전 세대 브라우저를 위한 최적화 힌트였음
    명세화될 무렵 Firefox에는 대부분 필요하지 않았고 일부 차세대 엔진에는 아예 도움이 안 되는데도 심하게 남용됐으니, 차라리 명백한 편법이었던 transformZ(0)를 유지하는 편이 나았을 듯함
  • 이상적인 세상이라면 이 라이브러리는 존재할 필요가 없음
    데모에서 text-wrap: pretty를 전환하며 브라우저별 동작을 시험할 수 있는데, Blink·WebKit·Gecko의 처리 방식이 놀랄 만큼 다르므로 여러 브라우저에서 확인해 보길 권함

• 내어쓰기 문장부호는 대체로 과하게 적용된다고 오래전부터 생각했음
  눈에 띈다면 이미 지나친 것이며, 특히 “는 거의 항상 두드러지므로 지금의 절반보다도 덜 내밀어야 함
  오히려 문단 첫머리의 “가 작은 들여쓰기처럼 기능하는 모습은 마음에 듦
  내어쓰기는 끄고 더 미묘한 돌출만 켠 결과는 견딜 만하지만, 대부분은 둘 다 끄는 편을 선호함
  이런 처리는 글꼴에 크게 좌우됨
  내가 쓰는 세리프 글꼴 Equity에서는 줄 끝의 “f,”에 이를 적용하면 커닝으로 쉼표가 이미 f 아래에 들어가 있어 f 윗부분까지 줄 밖으로 튀어나오므로 어색함
  세리프 글꼴이 글자의 꼬리나 돌기를 글자 폭 밖에 두어 자연스럽게 내밀게 한다면, 대부분의 문장부호보다 더 적절한 대상일 듯함
  자간 조정에서는 letter-spacing이 합자와 잘 맞지 않아 위험함
  합자가 먼저 적용되면 “T h i s i s fi n e!”처럼 되고, 0이 아닌 letter-spacing이 합자를 끄면 f가 i의 점과 충돌함
  대개 후자가 나타나지만 문자 체계와 글꼴, 명시적으로 활성화된 OpenType 기능에 따라 달라지고 의도치 않게 발생하기도 쉬움

  • 개인적으로 내어쓰기 문장부호의 모양을 좋아하지만, 물론 설정으로 바꿀 수 있음
    합자 때문에 자간 조정이 까다롭다는 데 동의하지만 기본 제한인 ±3% 라면 보기 괜찮다고 생각함
    “Type Specimen” 예시의 첫 문단 끝에서 fl, fi, ffi 합자가 연속된 부분을 확인할 수 있고 3% 제한도 설정 가능함
  • 일부 스웨덴 사이트에서 여는 오른쪽 큰따옴표가 앞줄 끝에 홀로 남아 화가 났던 현상을 문장부호 내어쓰기로 설명할 수 있을 듯함
    스웨덴어는 인용문의 시작과 끝 모두 오른쪽 큰따옴표만 사용함
    특정 텍스트의 언어나 로케일을 브라우저에 알려 큰따옴표와 소수점 등을 자동 처리하게 할 방법이 있는지 오래전부터 궁금했음

• 예시가 개선 효과를 강조하려고 인위적으로 좁은 줄 너비를 사용했다는 점은 짚고 싶음
  일반적으로 한 줄은 소문자 알파벳 두 벌 정도, 즉 약 60자 너비가 적절하다고 권장됨

  • 옛날 신문 단의 너비도 예시와 비슷하지 않았나 싶지만, 오늘날 따라야 할 기준이라는 뜻은 아님
  • 단 너비를 넓혀 현실적인 본문 폭에서 비교할 수 있음
    차이는 훨씬 덜 극적이지만 여전히 분명하며, 36em 줄 너비에서도 기본값보다 통계가 매우 좋게 나옴

• 다른 사이트에서 작성자가 LLM을 사용했다고 밝혔다는 이유로 바이브 코딩 태그가 붙은 것인지 의문임
  링크의 내용은 LLM이나 바이브 코딩과 무관하므로, 이제 이 태그는 마녀사냥처럼 느껴짐

  • 좀 더 호의적으로 보면 이 태그가 두 가지 역할을 하기 때문이며, 글이 바이브 코딩을 다룬다는 표시 외에 자극 요소 경고로도 자주 붙음
    더 명백한 용도와 충돌해 혼란스럽고 지나치게 공격적으로 보일 수 있음
    하나의 태그가 두 목적을 갖는 건 이상적이지 않지만, 대체로 자극 요소 경고와 보기 싫은 내용을 자유롭게 거르는 기능에는 찬성함
    혼란스러운 태그이긴 해도 적어도 작성자에게 불이익을 주지는 않음