# Myna - 기호 중심 프로그래밍 언어를 위해 설계된 모노스페이스 폰트

> Clean Markdown view of GeekNews topic #24232. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24232](https://news.hada.io/topic?id=24232)
- GeekNews Markdown: [https://news.hada.io/topic/24232.md](https://news.hada.io/topic/24232.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-09T04:33:04+09:00
- Updated: 2025-11-09T04:33:04+09:00
- Original source: [github.com/sayyadirfanali](https://github.com/sayyadirfanali/Myna)
- Points: 2
- Comments: 2

## Topic Body

- 프로그래밍 언어에서 자주 쓰이는 **기호를 알파벳과 동등하게 다루는 모노스페이스 폰트**로, 코드 편집기의 시각적 조화를 목표로 함  
- **ASCII 기호 중심 설계**를 통해 `->`, `::`, `=~` 등 다문자 기호의 정렬을 개선하고, **균형 잡힌 굵기와 명확한 구분**을 제공  
- **언어별 가독성**을 고려해 Perl, Haskell, C 등에서 기호와 연산자의 형태를 명확히 표현  
- 현재는 **단일 굵기와 비리거처 형태**로 제공되며, Linux의 fontconfig·pango 환경에서 합성 볼드 지원  
- **SIL Open Font License 1.1**로 배포되어 자유로운 사용과 수정이 가능  
  
---  
### Myna 개요  
- **Myna**는 **기호를 1급 글리프로 다루는 모노스페이스 폰트**로, 프로그래밍 언어에서 기호의 시각적 일관성을 높이는 데 초점을 둠  
  - `->`, `$`, `@`, `%` 등의 기호가 기존 폰트에서 어색하게 보이는 문제를 해결  
  - ASCII의 단순함을 유지하면서 **Ligature의 미적 효과**를 모방  
  
### 주요 특징  
- **Symbol-First Design**: 프로그래밍 언어 전반에 걸쳐 사용되는 ASCII 기호를 중심으로 설계  
- **정렬 정확도**: `->`, `>>=`, `::` 등 **다중 문자 기호의 정렬 정확도**를 높여 코드 가독성 향상   
- **균형 잡힌 두께(Weight)**: 기호와 문자 간의 대비가 조화롭게 유지  
- **미니멀한 형태**: 따옴표와 쉼표 등은 기하학적 형태로 단순화  
- **명확한 구분성**: `1`, `l`, `I`, `|`, `0`, `O`, `o` 등 혼동되는 문자의 구별 강화  
- **언어 인식형 디자인**: Perl의 Sigil, Haskell의 연산자, C의 기호 표현을 각각 명확히 표시  
  
### 개발 배경 및 현황  
- 기존 모노스페이스 폰트의 세부 글리프에 만족하지 못해 직접 제작된 서체  
- 개발자 본인이 **전문 및 개인 프로젝트에서 장기간 사용한 후 공개**  
- 현재는 **단일 두께, 비-Ligature 버전**으로 제공되며, 향후 수요에 따라 확장 가능   
  - Linux 환경에서 **fontconfig 및 pango**를 통한 합성 볼드 지원  
- **SIL Open Font License 1.1** 적용  
- 초기 버전은 **Hera**(Source Code Pro 기반 커스터마이즈)에서 출발  
- **Fira Mono, Inconsolata, Plex Mono, Office Code Pro, Anonymous Pro** 등 다양한 폰트의 장점을 참고하여 발전함   
  
### 향후 계획  
- **터미널 및 에디터 전반에서의 범용 사용**을 목표  
- 비ASCII 글리프(기하학·수학 기호 등) 일부 포함  
- 커뮤니티 피드백에 따라 **글리프 확장 및 기능 추가** 예정

## Comments



### Comment 46164

- Author: bobross0
- Created: 2025-11-11T08:14:02+09:00
- Points: 1

젯브레인 폰트 쓰는데 흥미롭네요

### Comment 46086

- Author: neo
- Created: 2025-11-09T04:33:05+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45849342) 
- 최근에 **Iosevka**(발음은 *Joseph*)로 바꾼 이유가 바로 이런 **간결함** 때문임  
  [Iosevka GitHub 링크](https://github.com/be5invis/Iosevka)  
  재미있는 점은 이 폰트의 소스코드를 실제로 읽을 수 있을 정도로 구조가 명확하다는 것임
  - Iosevka는 정말 아름다운 폰트임. Myna의 **압축된 형태(condensed look)** 도 사실 Iosevka에서 영감을 받았음  
    이전 버전인 Hera는 Source Code Pro를 커스터마이징한 비압축 버전이었음
  - Iosevka는 자체적으로 **커스텀 빌드**를 지원해서 다양한 글리프 변형과 **리거처 선택**이 가능함. 꽤 놀라운 수준임
  - Iosevka가 Joseph의 변형이라는 걸 이제야 알게 됨. 수년간 써왔는데 발음조차 몰랐음. README에 있었는데도 말임
  - [Pragmasevka](https://github.com/shytikov/pragmasevka)도 한 번 써볼 만함. Iosevka에서 넘어왔는데 **가독성**이 조금 더 좋게 느껴짐
  - 나는 [Iosevka Orw](https://github.com/s0la/orw/tree/master/.fonts)를 사용 중임. 표준 Iosevka와 일반 monospace의 중간 정도 폭이라 이상적임

- 솔직히 말하면 “**symbol-heavy 언어**를 위한 폰트”라는 설명이 잘 이해되지 않음. 기호들이 평범해 보임. 혹시 간격이 조금 넓은 걸까?
  - GitHub 페이지의 첫 번째 포커스 항목이 “**Near-Perfect Alignment**”임. 즉, `->`, `>>=`, `::` 같은 다문자 기호들이 완벽히 정렬된다는 뜻임
  - 디자이너임. 여기서 말한 symbol-heavy 언어는 Perl이나 Haskell처럼 **기호 사용이 많은 언어**를 의미함. 나는 리거처를 쓰지 않으면서도 정렬이 깔끔한 폰트를 만들고 싶었음
  - 디자인 차이를 설명할 때는 실제 비교 예시가 필요함. 비교 이미지가 없으니 혼란스러울 수밖에 없음

- 폰트가 꽤 예쁨. 다만 샘플에서 **emdash(—)** 문자가 빠져 있는 것 같음. Markdown을 자주 쓰는데, 많은 프로그래밍 폰트가 이 문자를 잘못 표현함  
  스크린샷이 다른 폰트들보다 훨씬 **평가에 도움이 됨**
  - 맞음, em-dash는 단순한 문자 이상임. 좋은 글쓰기의 **핵심 요소**라고 생각함 (농담 반 진담 반)
  - 피드백 고마움. 이 폰트에서는 en-dash를 넓게 만들어서 em-dash와 구분이 어려움. 나는 em-dash를 거의 안 써서 구분 필요성을 느끼지 못했음  
    그래도 요청이 있다면 개선을 검토하겠음

- 많은 폰트와 마찬가지로 이 폰트도 **수직 화살표(↑↓)** 정렬이 어색함  
  `^` 문자는 원래 타자기 시절 **circumflex 악센트**를 위한 것이었음. 그래서 높이가 비대칭임. caret의 하단이 `v`와 대칭되면 좋겠다고 생각함
  - 나는 caret을 위아래 화살표로 쓰는 걸 본 적이 없음. 대칭이 꼭 필요하다고는 생각하지 않음
  - caret을 수직 화살표로 쓰는 건 비현실적임. 두 줄에 걸쳐 입력해야 하니까. 실제로 이런 걸 쓰는 언어가 있는지도 궁금함
  - 혹시 줄을 넘는 **리거처**를 만들려는 건가? 그냥 Unicode의 `↑`를 쓰는 게 낫지 않음?
  - 디자이너임. 이런 조합은 감지하기 어렵고, caret은 본래 **연산자 기호**라서 프로그램적 의미를 깨뜨리면 안 됨. `v`와 비교하는 건 불공평함
  - caret의 역사적 이유는 중요하지 않음. 지금은 모두 그 모양에 익숙함. 이런 특수한 케이스를 위해 폰트를 바꾸면 오히려 혼란을 줌  
    폰트는 **예상 가능한 형태**를 유지해야 함

- “`->`가 화살표처럼 안 보인다”는 불만에 대해, 진짜 해결책은 **←→ 같은 실제 화살표**를 쓰는 것임. 언젠가 언어들이 더 나은 **타이포그래피 품질**을 지원하길 바람
  - 디자이너임. **우아함과 일관성**을 동시에 얻는 건 불가능함. 우리는 리거처 없이도 ASCII 기반 코드가 보기 좋게 보이도록 노력 중임
  - 리거처는 존재함

- [JuliaMono](https://juliamono.netlify.app)는 Julia 언어의 **전체 Unicode 지원**을 위해 설계된 폰트임
  - 링크 고마움. 글리프가 매우 풍부해 보임. 폰트 한계를 넘기 위해 JuliaMono2, 3, 4 같은 **fallback 체계**를 쓰는 것도 흥미로움
  - 디자이너임. 나는 주로 ASCII 범위에서 작업하지만, Myna에 JuliaMono를 **보조 폰트**로 설정하면 Unicode 커버리지를 확장할 수 있음

- 폰트가 예쁘긴 한데, 상단의 “Lorem” 글자 간격이 너무 벌어져 보여서 **커닝(kern)** 이 어색하게 느껴짐. 개인적으로는 신경 쓰임
  - 디자이너임. 매일 쓰다 보니 결함에 둔감해졌음. 그래도 지적은 타당함. 다음 버전에서 **커닝 수정**을 고려하겠음. 구체적인 예시가 있다면 이슈로 남겨주길 바람

- **리거처(ligature)** 는 개발자들 사이에서 꽤 논쟁적인 주제임  
  어떤 사람은 코드가 더 **아름답고 읽기 쉬워진다**고 하고, 어떤 사람은 “기호를 숨기는 건 불필요하거나 부정직하다”고 봄  
  또 어떤 사람은 “언어가 Unicode를 제대로 지원했다면 리거처가 필요 없었을 것”이라 말함  
  결국 이 프로젝트는 세 진영 모두를 동시에 자극했지만, 그래서 더 흥미로움. GitHub에서 별을 눌렀음
  - 대부분의 에디터에서 리거처는 **옵션**으로 켜고 끌 수 있음. 그래서 누구도 배제되지 않음

- 기호들이 소문자 옆에서 너무 높게 배치된 것 같음. 괄호 정렬에 맞추려다 생긴 문제로 보임. **균형감**이 조금 아쉬움
  - 디자이너임. 일반 폰트는 텍스트 중심이라 전통적인 정렬을 따르지만, **코드는 텍스트가 아님**  
    전통을 깨면 오히려 가독성이 좋아짐. 하이픈은 `>`와 정렬되어 **화살표 형태**를 이루도록 설계했음

- 이미 [Myna UI](https://mynaui.com/icons)라는 **아이콘 폰트**가 존재함. 혼동될 수 있을 듯함
  - 디자이너임. 알려줘서 고마움. 그래도 큰 혼란은 없을 것 같음