iiinova — where your digital self keeps evolving

11년만에 결국 문제를 파악한 건 좋은데 그 문제의 근본 원인이 2019년에서야 발견된 어이없는 실수였다는 것이 뭔가 거시기하고 거시기하다. 하나 확실한 건... 그동안 괜한 윈도 의심해서 미안했다. 그래도 내 탓은 아니었으니 됐어. 아, 근데 Unison은 결국 어떻게 되었냐면...

000

[maxp] Include 'maxComponentElements' in the table's recalculation by miguelsousa · Pull Request #1433 · fonttools/fonttools

maxp라는 건 글꼴이 사용하는 최대 뭐시기 크기라거나 하는 걸 미리 계산해서 구현체들에게 정보를 주는 헤더로, 당연히 maxp를 하나도 지정하지 않아도 fontTools가 자동 계산을 하는 게 당연한 일이다. 당연한 일인데... 아니 글쎄 옛날 버전에 버그로 필드 하나가 누락되고 있었던 것이었다!!!! (github.com/fonttools/fo...) 윈도가 잘못한 건 이렇게 잘못 생성된 maxp를 철썩같이 믿고 구현을 했던 것 하나 뿐이었다.

github.com

100

그러더니 글꼴을 fontTools로 이리 저리 조작해 보다가, 더 벙찌는 메시지를 뱉어 내더라: > 결정적인 차이를 찾았습니다. A/B는 실제 composite glyph가 최대 8개 top-level component를 쓰는데 maxp.maxComponentElements == 0이고, I는 같은 glyf 크기인데 maxp.maxComponentElements == 8입니다. I에서 4+ component 페이지가 있어도 모두 OK인 이유가 설명됩니다. [후략] **글꼴에 문제가 있던 게 맞았다고?**

100

> 기존 실험 결과와 커널 경로를 연결하면 강한 패턴이 하나 나옵니다. 실패 페이지는 전부 top-level composite component 수가 4 이상인 글리프를 포함하고, 인접 OK 페이지는 최대 3입니다. AC00-AC27 같은 “page-mate victim”도 자기 글리프 때문이 아니라 같은 64-glyph page 안의 4+ component 글리프 때문에 같이 실패하는 형태로 설명됩니다. 번역: 글리프가 다른 글리프의 집합으로 이루어질 수 있는데 그런 서브글리프 숫자가 너무 많으면 터지는 패턴이 발견되었다.

100

...그리고 커널 얘기가 나온 시점에서 예상할 수 있듯이 개같이 클로드한테 safeguard로 막혀서 (그것도 두 번이나) 우회해야 했다. 그래서 클로드는 글렀구나 싶으니 클로드가 작업하던 걸 코덱스로 옮겨서 마저 분석해 달라고 했다. 코덱스도 한동안 삽질하다가, 클로드가 작업하던 데이터를 슥 보더니 이런 메시지를 뱉어 냈다.

100

따라서 내부적으로 64개 단위의 테이블이 있고 이 테이블이 어떤 이유로 초기화가 덜 되었다거나 하는 게 아닐까 하는 가설이 세워졌다. - 글꼴의 cmap이나 메타데이터에는 전혀 문제가 없는 게 재확인되었다. 특히 ulUnicodeRange라고 해당 글꼴이 무슨 문자들을 지원하는지 비트셋으로 만들어 놓은 게 문제가 아닐까 하는 가설이 있었는데, 이 비트셋을 뭘로 설정해도 문제는 똑같이 재현되어서 가설은 기각되었다.

100

- 이 문제의 정확한 근원은 GetCharacterPlacementW라는 함수가 오동작하는 것이었다. 이 함수는 GDI의 일부로, GDI는 윈도에서 커널에 포함되어 있기 때문에 꼼짝 없이 커널 분석을 해야 했다... - Workaround가 한글에 대해서는 문제를 완화시켰지만 실제로는 완벽한 해법이 아니었다. 영향받는 글리프 목록만 바꾸었던 것. - 정확히 문제가 되는 글리프 번호를 뽑아 본 결과 1216~1663과 1792~2047이라는 두 개의 영역이 드러났는데, 1216, 1664, 1792, 2048 모두 64의 배수다.

100

하지만 글꼴 생성에 사용했던 fontTools는 해당 필드를 자동으로 계산하기 때문에 틀릴래야 틀릴 수 없었다. 그러므로 윈도가 문제일 거라는 가설이 유력해졌던 것. 도무지 이유는 모르겠지만 아무튼 workaround가 있긴 하고 쓰는 데 불편함은 없으니까 언젠가 다시 봐야지 하고 주석으로 한바탕 하소연을 쓴 이래 벌써 11년(!!!!)이 흘렀다. 문득 이 버그를 LLM으로 분석해 봐야지 하는 생각이 들었다. 생각이 났으면 해 보는 게 에이전틱한 시대의 덕목 아니겠는가. 그렇게 해서 얻은 추가적인 정보는 다음과 같았다.

100

글리프 번호 1200을 넘기면 대부분의 글자들이 없는 걸로 처리되다가, 정확히 2048번 글리프가 되면 거기서부터는 전혀 문제가 없었던 것이다. 그리고 이리 저리 시도해 보다가 문제가 되는 글자들의 글리프 번호를 모조리 앞으로 당겨버리면 문제가 사라진다는 것도 확인했다. 2048이라니 너무 수상한 숫자가 아닌가? 맨 처음에는 OpenType의 cmap 포맷에는 이진 탐색을 가속화하기 위한 필드들이 있는데 이런 것들이 잘못되어서 그런 건가 싶었다.

100

이걸 극명하게 보여 주는 사례가 메모장이었는데, 메모장에서는 지정 글꼴에서 문자에 대응되는 글리프가 없으면 대체 글꼴로 넘어가는 fallback 옵션을 사용하고 있다. 그래서 문제가 되는 문자를 입력하는 순간 그 문자 앞에 있던 모든 문자들이 싸그리 대체 글꼴로 바뀌어 버리는 기현상을 볼 수 있었다. 이 문제를 오랫동안 윈도 버그로 의심해 왔던 이유는 정확히 어떤 문자의 글리프가 없는 걸로 인식되는지가 꽤 독특했기 때문이었다.

100

영어 울렁증이 있거나 도대체 Uniscribe가 뭔지 모르거나 둘 다인 사람들을 위한 빠른 설명. Uniscribe라는 건 윈도의 글꼴 렌더링 시스템의 내부 이름이다. 널리 쓰이는 OpenType 글꼴에는 0부터 n-1까지 번호가 붙은 글리프와 무슨 문자가 어느 글리프에 대응되는지를 나타내는 문자 매핑(cmap)이 존재하는데, Uniscribe에서 cmap에는 분명 존재하는데 정작 글리프는 없다고 반환되는 경우가 있었던 것이다.

100

Kang Seonghoon @mearie.org · 21/06/2026

멀고 먼 옛날 Unison이라는 괴상한 글꼴을 만들던 적이 있었다. (github.com/lifthrasiir/...) 비트맵-벡터 하이브리드 글꼴이라는 컨셉을 가지고 있어서 글꼴의 소스 코드도 텍스트로 만들고 파이썬으로 컴파일해서 글꼴 파일을 생성하게 하는 구조였는데, 당시에 전혀 그 원인을 알 수 없던 버그가 하나 있었다. 해당 버그가 얼마나 곤란했냐 하면 지금까지도 컴파일러에 주석과 함께 workaround가 남아 있다.

def custom_sort_key((name, _)):
# what, the, real, fuck.
# it seems that Uniscribe has some bug with Hangul and possibly more scripts:
# some characters, when they are located in specific glyph indices, are correctly
# mapped via ScriptGetCMap but considered to be missing via ScriptShape.
# combined with SSA_FALLBACK it causes the wrong *and* inconsistent fallback behavior.
# given that the range of those indices abruptly end with 2^n boundaries,
# I strongly suspect that this is something to do with the internal lookup mechanism.
# for now, reorder problematic scripts to (empirically) avoid the problem... *sigh*
if not name.startswith('uni'): return (2, name)
try: c = int(name[3:], 16)
except ValueError: return (2, name)
return (0 if 0x1100 <= c <= 0x11ff or 0x3130 <= c <= 0x318f or
0xa960 <= c <= 0xa97f or 0xac00 <= c <= 0xd7ff else 1, c)

100

텍스트를 선택하면 선택되는 기능, 크롬 번역 같은 도구와 호환되게 하기 위한 다양한 삽질 등등등을 했다. 보기에는 단축키 딱 하나만 있는 정말 단순한 도구인데 디테일하게 들어가니 신경 쓸 게 많았다.

010

Kang Seonghoon @mearie.org · 21/06/2026

기술적 얘기: 모델은 PP-OCRv6의 fp16 버전을 WebGL2로 돌리고 있다. 일본어와 중국어 인식은 잘 되는데 한국어는 현재 지원이 안된다는 한국인에게는 별로 중요하지 않은 단점이 있다. WebGPU도 시도해 봤는데 드라이버가 너무 느려서 도저히 쓸 수 없어서 포기했다. 모델은 가져다 쓰지만 인터페이스는 꽤 공을 들였는데, CORS 우회, 오버레이 글자색/배경색 감지, 세로쓰기 감지, <img>에 src가 없다거나 하는 예외 케이스들 처리, 오버레이 위에 커서를 올려 놓고 조금 기다리면 텍스트 밑의 이미지가 보이는 기능,

100

Kang Seonghoon @mearie.org · 21/06/2026

주말에 Loupe라고 하는 OCR 웹 확장을 만들어 공개했다. github.com/lifthrasiir/... 정확히 주말에 만든 건 아니고, 일본어 텍스트가 들어간 이미지를 제법 볼 일이 있는데 읽는 것 자체는 가능하지만 너무 느려서 지치는 게 싫어서 짬짬이 만들다가 주말에 마무리한 것. 아직 크롬 웹 스토어나 그런 데다가 올리진 않았는데 (등록하려면 돈을 내야 하더라... 귀찮게) 사용에는 전혀 문제가 없으니 많이 이용해 주시라.

123

Reposted by Kang Seonghoon

Shriram Krishnamurthi @shriram.bsky.social · 09/06/2026

I've spent months rethinking and rebuilding my programming languages course from scratch for the agentic coding era. I wrote myself a memo explaining what I'm doing. I figure others might be interested in the redesign, so here goes! Feedback welcome of course. docs.google.com/document/d/e...

docs.google.com

RFC: Programming Languages Course Reboot, 2026

55413

Kang Seonghoon @mearie.org · 01/06/2026

백만년만에 돌아온 직소퍼즐. 정확하게는 9년 전에 SVG로 만들고 방치해 놓고 있다가 클로드로 간만에 WebGL로 재작성하고 저장소도 공개했다. 참고로 저는 결국 마지막 퍼즐은 못 풀었습니다... s.mearie.org/jigsaw/

000

Reposted by Kang Seonghoon

Ed @ed3d.net · 31/05/2026

Yeah, I'm not going to lie--unless paid for it, open-source software development seems even more awful now than before. Catching a Mastodon mob in exchange for giving stuff away for free? Bargain at twice the price.

527027

한편 무슨 최적화를 고려하길래 이런 것까지 확인해야 했느냐 하면, 한 마디로 말하면 `a[n]`을 `*(T*)((char*)a + n * sizeof(T))`로 바꿔 쓰는 최적화였다. WebAssembly 바이트코드 인터프리터에서 로컬 변수 같이 배열을 참조할 때 배열의 인덱스를 저장하는 게 아니라 거기에 `sizeof(T)`를 곱한 바이트 오프셋을 저장해서 최적화를 하는 게 적법하느냐의 문제였다. (x86-64 같이 `sizeof(T)`의 값에 따라서는 괜찮은 케이스조차 아니었다.) 결론은 T가 객체 타입이면 적법하다는 것.

000

여기까지는 ISO C에 한정된 얘기였고, 현실에서는 POSIX 같은 표준이 함께 지원되어야 할텐데 POSIX에서는 `void*`에 함수 포인터도 들어갈 수 있어야 한다는 추가 규칙이 있다고 한다. `dlsym` 같은 함수가 이 규칙에 영향을 받는 대표적인 예이다. 어쨌거나 내가 생각하던 최적화는 ISO C에서 허용되는 걸로 파악했으니 해피 엔딩.

100

WebAssembly를 써 보신 분들은 어렴풋이 이 사실을 눈치챌 수 있었을 수도 있는데, WebAssembly에는 일반적인 객체를 담는 메모리 타입도 존재하지만 테이블이라 해서 함수 포인터(`funcref`) 같은 특수한 타입을 담을 수 있는 타입도 존재한다. 알고 보니 이게 특이한 결정이 아니라 ISO C에서 원래부터 허용하는 구조였다는 얘기. 나는 WebAssembly가 이 문제를 바이트 표현이 같으나 서로 타입이 다른 포인터가 존재할 수 있게 해서 해결하는 게 강제되는 줄 알았다. (어디까지나 "강제"가 아니었다는 말임)

100

...라고 알고 있었는데, 최근에 WAH (github.com/lifthrasiir/...) 최적화를 위해 이런 저런 고려를 하던 도중 혹시나 해서 찾아 보니 여기에 한 가지 중요한 예외가 더 있었다. 함수는 객체가 아니다. 즉 함수 포인터는 void*에 담는 게 원칙적으로 불가능하다! 대신 서로 다른 함수 포인터 타입끼리 변환은 가능하다. 어디까지나 변환만 된다는 거지 일반적으로 다른 타입의 함수로 호출이 가능하다는 건 아니지만.

100

Kang Seonghoon @mearie.org · 14/03/2026

ISO C에는 객체(object)라는 개념이 있는데, 이 개념은 객체지향 프로그래밍 같은 거랑은 상관 없고 자료형이 차지하고 있는 주소 공간의 일부분을 가리키는 말이다. 객체는 그 바이트 표현과 함께 타입이 항상 따라 다니며, union을 사용하지 않고 객체를 캐스팅만으로 다른 타입으로 재해석(reinterpret)하는 건 상당히 제한되어 있다(이게 그 악명 높은 strict aliasing 규칙이다). 다만 너무 막으면 저수준 작업을 아예 할 수 없으므로 몇 가지 예외가 있는데, 대표적으로 void*와 char가 있다.

100

I also can't really understand stances against CoC. CoC is just a codification of politeness. Do you dislike the overt formality of some CoCs? No one force you how to make one, you can keep it informal if you wish (my preference, by the way). It's just a fancy name for "community rules" after all.

000

Kang Seonghoon @mearie.org · 14/03/2026

Sure, everything is a trade-off and politeness is no exception. Heck, rudeness is even acceptable when that improves clarity *and* clarity is absolutely required. But we are not in a war, we are just doing a freakin' software development. Politeness is a common sense because it works in most cases!

100

Kang Seonghoon @mearie.org · 14/03/2026

Political correctness is all about politeness. Politeness is not a strict requirement for the discourse, and some even see it as hinderance without actual value. But even under this view---which is debatable in reality---politeness is helpful simply because it's the easiest solution for many things.

100

단순히 `<보통 문자>**<기호>`도 왼편으로 해석하는 식으로 해서 `**마크다운(Markdown)**은` 같은 걸 허용한다 하더라도, `このような**[状況](...)**は` 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.

011

CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 `**이런 **식으로** 중첩되어**` 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 `**이런 **` 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에 이런 식으로 추론하는 데 한계가 있다는 것이다.

112

...기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 `**마크다운(Markdown)**은`을 해석해 보면 뒷쪽 `**`의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.

111

여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 `**<보통 글자>` 꼴이거나 `<공백>**<기호>` 또는 `<기호>**<기호>` 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 `**마크다운**은` 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 `이 **"마크다운"** 형식은` 같이...

111

문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 `**`는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다.

121