요약
Iosevka는 코드와 터미널, 기술 문서용으로 만든 오픈소스 고정폭 글꼴 패밀리입니다.
Iosevka의 공식 소개 페이지입니다. 2015년부터 개발해 온 글꼴로, 지금은 34.9.0 버전까지 나왔습니다.
왜 중요한가
- 글자 폭이 정확히 0.5em(글자 크기의 절반)이라 같은 화면 폭에 더 많은 열의 코드를 띄울 수 있습니다.
- 문자 모양과 굵기를 골라 직접 빌드할 수 있어 쓰는 사람마다 자기 취향의 글꼴을 만들 수 있습니다.
- 고정폭과 준비례 계열이 한 패밀리라 코드와 문서를 같은 인상의 글꼴로 맞출 수 있습니다.
핵심 내용
- 기본형 외에 터미널용 Term, 리가처(여러 글자를 기호 하나로 합쳐 보여 주는 기능)를 뺀 Fixed가 있습니다.
- 세 계열 모두 슬랩 세리프판(Slab)이 따로 있습니다.
- 문서용으로는 글자마다 폭이 조금씩 다른 준비례 계열 Aile(산세리프)과 Etoile(슬랩 세리프)을 제공합니다.
- 146개 문자의 모양을 바꿀 수 있고, Consolas나 JetBrains Mono 등을 닮게 만드는 스타일 세트 19개가 들어 있습니다.
- 굵기는 Thin부터 Heavy까지 9단계이고, 이탤릭·오블리크와 넓은 폭(Extended)도 고를 수 있습니다.
HN 반응
- 직접 빌드할 수 있는 점과 글꼴을 코드로 만드는 전용 언어 PatEL을 높이 산 이용자가 많았지만, 글자가 좁아 읽기 힘들다는 반론도 나왔습니다.
- 코딩 리가처는 등호가 몇 개인지 세기 어렵다는 불만과, 보기 좋고 헷갈린 적이 없다는 반응이 맞섰습니다.
Iosevka, 몇 년째 제가 제일 좋아하는 폰트입니다!
저는 커스텀 버전을 쓰고 있어요. 폰트를 마음대로 설정¹하고, 저장소에 들어 있는 빌드 시스템²으로 나만의 ttf(아니면 ttc가 더 좋고요)를 빌드할 수 있거든요.
폰트 제작자 be5invis는 폰트를 프로그램으로 생성하려고 PatEL(Parametric Type Expression Language)이라는 DSL을 통째로 만들었는데, 이건 따로 칭찬받아 마땅합니다!
Renzhi, 혹시 이 글을 읽게 된다면 Iosevka 만들어 줘서 정말 고맙습니다!
¹ https://typeof.net/Iosevka/customizer
² https://github.com/be5invis/Iosevka/blob/master/doc/custom-build.md
잘 맞으신다니 다행입니다. 저는 이 폰트가 그렇게 칭찬받는 게 늘 신기합니다. 써 보면 저한테는 완전히 읽을 수가 없거든요.
이번에도 다시 써 봤습니다. 터미널에서 Jetbrains Mono 대신 "Iosevka Term" 버전으로 바꿔 빠르게 설정해 봤는데, 사람들이 이걸 어떻게 읽는지 도무지 이해가 안 됩니다.
저도 꽤 오랫동안 이 폰트의 한 버전을 썼습니다. 커스터마이저가 아니라 GitHub 페이지에서 내려받았던 기억이 납니다. 결코 나쁜 폰트가 아니에요. 쓰는 동안 Iosevka를 정말 즐겨 썼습니다.
그런데 Berkeley Mono를 3분 써 보고는 일주일쯤 지나 모든 곳에서 그걸로 갈아탔고, 다시는 돌아보지 않았습니다. 정확히는 다른 곳을 기웃거리지도 않았고요.
네, 무료가 아니고, 네, 개성이 강한 폰트입니다. 제 취향은 이 폰트와 거의 딱 맞습니다. 제 일을 정말 잘 해내고, 곁에 있는 것만으로도 기분 좋게 해 주는 비싼 수공구처럼 아끼는 물건 중 하나입니다.
돈을 내기 싫거나 낼 수 없는 분들을 위해, Berkeley Mono를 흉내 낸 Iosevka 설정을 소개합니다. https://ahatem.github.io/IoskeleyMono/
와. 모방은 정말 최고의 찬사라더니 맞는 말이네요.
와. 정말 멋지네요! 공유해 주셔서 고맙습니다
웃기게도 저는 Berkeley Mono를 돈 주고 샀는데, 이탤릭체가 영 마음에 안 들더라고요(가격에는 더더욱 못 미치고요). Iosevka Mono는 글리프가 아주 예쁜데 제 취향에는 폭이 너무 좁습니다. 지친 제 눈에는 JetBrains Mono, IBM Plex Mono(아니면 Lilex), Roboto Mono가 훨씬 잘 맞는 것 같아요!
그럴 수 있죠. super-compiler 애드온을 쓰면 이탤릭 각도를 조절할 수 있는 걸로 알고 있습니다.
이탤릭 설계 의도에 관한 이야기를 어렴풋이 본 기억은 있는데 지금은 떠오르지 않네요. 어쨌든 저한테는 이탤릭이 불편해 보이지 않습니다.
아버지가 예전에 다니시던 직장에 있던 ACT Sirius One 중 한 대가 쓰던 데이지휠 활자체랑 비슷해 보이네요.
솔직히 그 시절 폰트처럼 보이도록 설계된 폰트입니다. 저도 예전에 쓰던 옛날 컴퓨터가 떠오릅니다. 타자기 같기도 하고, 진짜 VT320이나 제가 쓰던 옛날 DOS 시스템 같기도 하고요.
그 옛날 폰트들을 현대적으로 되살리면서도 시대 분위기는 그대로 살렸고, 문자 집합도 제대로 지원하고, 세부에 대한 애정이 담겨 있습니다. 제게는 너무 완벽해서 존재감이 사라질 정도인데, Berkeley 페이지에도 이렇게 적혀 있죠. "It's boring. It's good"*.
제작자에게도 몇 주 써 보고 이렇게 메일을 보냈습니다. "너무 완벽해서 내 컴퓨터가 전부 좋은 의미로 70년대로 돌아간 것 같아요".
*: 이 댓글을 쓰다가 브라우저의 고정폭 폰트를 정말 Berkeley로 설정해 놨나 싶어서 의심한 적이 있습니다. 시간이 지나면 그 정도로 투명해집니다.
이렇게 인기가 많은 이유는 프로그래밍 합자(ligature)를 잔뜩 넣은 최초의 폰트(중 하나?)였기 때문입니다. 그래서 일찍부터 인지도를 쌓았고, 폰트 취향은 워낙 개인적이다 보니 쓰는 사람이 많을수록 좋아하고 글을 올리는 사람도 늘어납니다.
저는 Iosevka에 칭찬을 듬뿍 보태고 싶은데, 이유는 커스텀 S-표현식 DSL로 정의되어 있다는 점입니다.
https://github.com/be5invis/PatEL
진짜 해커의 서체예요.
Iosevka와 그 패밀리는 진정한 걸작입니다. 깔끔하고 눈이 편해서 주력 고정폭 폰트로 썼습니다.
지금은 Berkeley Mono와 비슷해 보이도록 만든 Iosevka 설정인 Ioskeley Mono로 갈아탔습니다.
https://github.com/ahatem/IoskeleyMono
Iosevka 원본이든 Ioskeley든 둘 다 멋진 폰트입니다. 만든 분께 감사드립니다.
저는 웹 페이지의 주력 폰트와 글자 폭, 굵기를 맞춰 커스터마이즈할 수 있어서 좋아합니다. 제 설정은 여기 있습니다. https://github.com/vincentbernat/vincent.bernat.ch/blob/main/flake.nix#L288 .
저만 그런가요? 저는 "코드 합자"가 정말 싫습니다. 연속된 "="가 몇 개인지 세려고 글자를 드래그해서 표시해야 하고, /는 주변에 다른 글자가 없으면 V와 구분이 안 되고, <>는 다이아몬드 모양이라 복사해서 붙여 넣어 봐야 뭔지 알 수 있고, 꼬불꼬불한 꼬리가 달린 화살표에, 보기 흉한 />에, 가운데에 점이 찍힌 <.까지...
폰트에서 제가 바라는 건 "제대로 된" 크거나 같다/작거나 같다 기호 정도가 최대입니다.
저한테는 늘 존재하지도 않는 문제의 해결책처럼 보였습니다. 코드는 읽기 어려워지는데, 합자라는 게 있으니 구현해 보면 멋진 기술 과시가 될 것 같았고 스크린샷에서도 멋져 보이겠죠. 하지만 실제로는 제 생각에 그냥 평범한 문자가 낫습니다. 그래도 결국 취향 문제겠죠. 다른 사람이 쓴다고 해서 해될 건 없으니까요.
코드 품질에서 가장 중요한 요건 가운데 하나가 코드 스타일의 일관성이라는 연구는 아주 오래전부터 있었습니다.
그래서 탭 대신 스페이스를 쓰든지, 아니면 어느 기계에서나 코드가 비슷하게 보이도록 editor config를 강제하라는 세부 사항까지 내려갑니다.
물론 그렇다고 코드 합자가 자동으로 해롭다는 뜻은 아니지만, 저라면 쓰는 데 꽤 조심스러울 겁니다. 적어도 마찰이 생기는데, ASCII 기호 대신 실제 수학 기호를 쓰면 정신적 부담이 줄어든다는 점이 그 마찰을 상쇄하는지는 잘 모르겠습니다.
저는 코딩한 지 15년쯤 됐는데, 아직 스페이스 대 탭 논쟁을 이해할 만큼 나이를 먹진 않았나 봅니다 :)
제가 고른 IDE에서는 그 문제가 드러난 적이 없는 것 같습니다. 눈으로 보면 똑같아 보이거든요. 어떤 코드베이스가 스페이스고 어떤 게 탭인지 구분도 못 합니다. 생각해 본 적도 없고요. 그냥 탭 문자를 누르고, 거기 스페이스가 있었든 말든 신경 안 씁니다. 아니면 엔터나 {를 치면 IDE가 들여쓰기를 해 주고요. 저는 그저 스페이스를 2번, 4번, 8번, 16번 연달아 누르지 않기로 했을 뿐입니다.
이제 HN 사람들한테 불도저처럼 밀려나지 않길 바랍니다...
탭이 스페이스보다 낫다는 주된 논거 하나는 늘 들여쓰기 한 단계가 화면에서 차지하는 폭을 사람마다 설정하고 싶어 한다는 것이었습니다.
탭이면 notepad.exe 같은 것만 빼고는 옛날부터 거의 모든 에디터가 그걸 할 수 있었고, 스페이스면 에디터가 처리를 좀 더 해야 해서, 프로젝트에서 정한 들여쓰기가 정말 거슬리는 사람은 에디터 선택에 제약이 조금 있었습니다.
그래서 사실 합자 논쟁과 꽤 비슷합니다. 예전에는 "8칸 들여쓰기는 화면 낭비가 너무 심해 :(" 하던 사람들이, 이제는 "!=나 -> 같은 게 보이는 것보다 최신 유니코드 기호가 좋은데 :(" 하고 말하는 셈이죠.
스페이스 대 탭은 다른 프로그래머와 코드를 공유하는 파이썬 프로그래머에게 문제를 많이 일으킵니다. 스페이스 대 탭이 문제가 되는 또 다른 곳은 makefile인데, POSIX에서 가장 짜증 나는 특징 중 하나일 겁니다.
옛날 bourne shell도 어떤 곳(case 문이었나?)에서는 탭을 요구했던 기억이 납니다. bash는 그런 문제가 없고요.
요즘은 makefile 말고는 탭을 피하려고 합니다.
1990년대 중반 POSIX 표준화로 줄어들기 전까지
/bin/sh에는 구현체가 여러 가지였던 걸 생각하면, 그중 하나가 스페이스와 탭을 구분했다 해도 놀랍지 않습니다.그렇긴 해도 원조 UNIX V7의 /bin/sh 구현은 공백 문자의 종류를 구분하지 않았습니다.
https://www.in-ulm.de/~mascheck/bourne/v7/
글쎄요, 탭 대 스페이스는 대체로 정리가 끝났고 스페이스가 이겼습니다. 하지만 어떤 물리 키를 누르느냐가 문제였던 적은 당연히 없었습니다. 스페이스 쪽에서도 들여쓰기하겠다고 스페이스바를 연타하는 사람은 없었어요(탭 키가 스페이스를 입력하도록 설정할 수 없는 에디터를 쓸 수밖에 없는 불행한 상황이나, 탭 키가 포커스를 옮겨 버리는 비(非)에디터 UI의 텍스트 필드 정도라면 모를까).
저는 아직도 "들여쓰기는 탭, 정렬은 스페이스" 파입니다. 이걸 지키면 탭 크기가 어떻든 코드가 보기 좋거든요.
엑셀에서 수식 입력할 때요
스페이스가 이겨서 아쉽습니다. 탭이 맞다고 생각해요. 탭스톱을 원하는 들여쓰기 크기로 설정할 수 있으니까요. 2칸 들여쓰기를 읽는 데 이제 지쳤습니다. 파이썬만 빼고는 이제 전부 그쪽으로 넘어간 것 같아요. C에서도 보이는데, 특히 눈에 거슬립니다. 중괄호로 블록을 나누는 언어는 특히 4칸이 필요하다고 생각합니다. 파이썬은 가장 덜 필요하고, 루비는 블록이 단어로 구분되고 긴 메서드를 쓰는 게 나쁜 스타일이라서 읽을 수 있고요.
동의합니다. 4칸이 최적이고, 다행히 제가 일한 프로젝트에서도 표준이었습니다. 깊은 중첩을 피하게 만들기도 하고요.
저는 가독성이 떨어지는 느낌이 없어서, 그냥 예쁜 기호 = 제가 더 행복하다는 얘기죠
프로그래밍하거나 수학 식을 쓸 때 저는 -> >>= <*> 같은 것을 의미가 하나로 정해진 단일 기호로 보고 그렇게 생각합니다. 그래서 합자를 쓸 뿐 아니라 키보드에서 그것들을 키 하나로 입력하게 해 놨습니다. 같은 이유로 "forall"을 입력하는 키도 있는데, Emacs가 그걸 ∀로 표시해 줍니다.
흔한 불만이죠.
저는 개인적으로 좋아합니다. 보기 좋고, ==, ===, = 합자를 구분하는 데 어려움을 겪은 적이 없습니다.
저만 그런 줄 알았어요! 제가 미쳤거나 나이가 들어 고집만 세진 건가 싶었거든요. 합자가 있는 폰트를 처음 봤을 때는 멋있어 보여서 써 봤는데, 거의 바로 싫어졌습니다. 그 뒤로도 몇 번 길이를 달리해 가며 다시 써 봤는데, 정말 싫어한다는 결론을 내렸습니다.