일본에서 공연 뛰고 돌아오니까 제정신을 못 차리겠다

LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.

문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.

CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.

I finally got the data transfer from the AISC110C high-speed camera sensor working!

It's a 5€ chip that outputs 80x120 video at up to 40k fps.

Data is read with a Xilinx Spartan7 and transmitted via USB3 with a Cypress FX3, each on its own little PCB.

The front PCB is exchangeable, making this a neat modular platform. I already have an analog video frontend with the ADV7182 and am working on a Cameralink interface.

Videos are coming tomorrow, I need more light for the high framerates.

오픈소스 활동하면서 고민하게 되는 법적 어려움들

1. 오픈소스가 완전 공개에 무료인 것은 맞으나, 무상이라도 저작권 관리, 기업 납품 등 법적 행위가 정상적으로 성립하려면 절차상 결국 사업자등록 사실이 필요한 경우가 많다.

2. 리눅스 재단과 하버드대 공동 연구에 따르면, 오픈소스 메인테이너들은 본업 외에 주당 20시간 이상을 오픈소스에 쏟으며 사실상 '투잡'을 뛰지만 월급은 한 곳에서만 받는 기형적 구조다.

3. 이런 기형적인 구조에서, 그나마 비영리 활동을 한다고 인정을 받는 방법을 고민하게 되지만 실질적으로는 그 어느 나라도 제도적으로 방법이 없다시피한 경우가 많다.

4. 기존의 영리 사업자 제도에 대부분을 의존해야 해서 협력자가 아닌, 겸업으로 인식되거나 아예 경쟁사를 창업한 것으로 인식되는 등 의도치 않은 여러가지 오해를 불러일으키기도 한다.

5. 이 1에서 4까지의 내용을 이해하고 상담해주는 법률가조차 찾아보기 어렵다.

모든 연락 다 끊고 (트위터 제외) 쭉 쉬었더니 아주 좋았다

CI 실행 시간을 1/3로 줄였음

[2일차 -20p.]

데이터 종속을 수작업으로 분석한다면, 결국 실수를 하게 될 것입니다. 구조만 개선하려고 하다가 실수로 동작까지 변경하게 될 수도 있습니다. 그래도 문제는 없습니다. 올바른 버전의 코드로 되돌리면 됩니다. 작은 단계로 작업하세요. 그 방식이 바로 코드 정리 방법입니다. 커다란 설계 변경은 어렵고 무섭죠? 더 작은 단계로 진행하세요. 그래도 무섭다면, 더 작게 하세요. 두려움을 느끼지 않는 수준의 바로 그 단계가 가장 좋은 수준입니다.

일하다 막힐 때 위키피디아, 한국민족문화대백과사전, man 페이지 설명 읽는게 머리 식히는데 좋은 것 같음

코드 수정 제안 반영은 해당 줄을 대치하는 방식으로 처리해도 충분했는데 이제 그래프 매칭 문제로 바꿔야겠다

오랜만에 튜사에 왔다

증명 가능한 조건을 만족하는지만 검사하면 되고 AST 국소 패턴만 다루는 것만 모델링 하면 되서 오히려 구현 자체는 간단해질 것 같음

아직 zed에서 작업에 사용 중인 언어를 인식하지 못하고 있기 때문에 익스텐션을 만들어야하나 고민 중

When code is more complex than it needs to be, its under-engineered, not over

CLI 툴들 이것저것 써보니까 시간이 금방 지나간듯

@quadr최치선 맥북 M5 Pro (16GB)로 변경했습니다. 쭉 M1 프로 쓰다가 갈아타니까 성능 차이가 체감이 되네요

Thinking of using a Raspberry Pi as your daily driver? These Linux distro options might surprise you. 🖥️

https://itsfoss.com/raspberry-pi-desktop-os/

#linux #raspberrypi

이 참에 zed로 완전히 갈아탐. vscode는 너무 무거운 것 같음

새 장비를 받았고 세팅을 다했다

@z9mb1Jiwon 세상에

산타 할아버지는 개인정보 수집 및 이용동의, 개인정보 국외이전 동의, 이벤트 안내 수신 동의를 안 한 아이에게 선물을 안 주신대

구현 중인 린터의 코드 수정 제안 기능에 부분적으로 한번 형식 증명을 적용해볼만 할 것 같기도 하다

내 로컬에서는 됐는데. 라는 말을 20년 넘게 사용할 줄, 20년전의 나는 (당연히) 몰랐겠지. #중년의개발자

오늘은 오랜 숙원이였던 리뷰 중 "invariant" 말하기를 달성했다

@z9mb1Jiwon 민초도 좋아하시나요?

아무생각 없이 1:1 면담하러 갔다가, 갑작스럽게 연봉이 인상되어서 돌아 옴

유용한 프로그램을 만들려면 억까를 상당히 많이 당해봐야 하는 것 같다.

If a problem is improved by sleeping, it's probably a race condition.

If it's a race condition, then sleeping is never a correct solution to the problem... you're just making it less likely to happen, not fixing it...

I've seen this kind of bug and the root cause is almost always that something is writing to a nonblocking pipe/service/whatever and not retrying when it fails because the buffer is full.

Second most likely cause is a hidden message size limit somewhere that isn't respected.

https://fixupx.com/i/status/1999317065237512224

그거 아시나요 극장에서 이어폰 착용은 모나딕하다는 사실

페라이트 자석이 도착했으니까 연휴간 메모리를 짜볼 예정

린터 규칙을 새로 작성할 때 마다 꽤 곤란한데 뭔가 좋은 방법이 없을까

최적화 작업이 무사히 끝났다. 꽤 만족스러운 시간들이였음

I wrote up the story of Erdos problem 1026, which was fully solved in the last few days through a collaborative effort involving multiple people, multiple AI tools, and multiple results from past literature: https://terrytao.wordpress.com/2025/12/08/the-story-of-erdos-problem-126/

비록 오늘은 오하아사 12위지만 느낌은 좋다

At last, I finished reading Chapter 7 of "Theorem Proving in Lean 4" in Korean by explaining how to use three tactics: cases, induction, and injection. https://youtu.be/N-ELdwO-vN4?si=kfemVPbbNP-Gf0m8

@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 저 안쓰는거 하나 있는데 드릴까요?

하카타에서 보냈던 엽서가 도착했군

@akastoot악하 @z9mb1Jiwon 원래 범법이 짜릿한거죠

Officially unemployed now after almost 5 years at aws working completely in the open on the Rust compiler.

With https://rustnl.org/fund/ and https://rustfoundation.org/media/announcing-the-rust-foundation-maintainers-fund/ both figuring out how to ensure maintainers are paid to do reviews, refactorings and mentoring, I'm optimistic I can continue doing my work in the future.

If your company uses Rust a lot and would like to support it and talk about how that support can either indirectly or directly benefit its Rust-writing employees, I'm happy to chat to explain both funds and make the connection to the right fund for you. Or just skip directly to one of the funds if you already know ppl there!

@z9mb1Jiwon 방금 하고 왔는데 이거 참 보여드릴 수도 없고

길이 전부 얼어붙어서 출퇴근할 때 스릴이 증가했다

최적화 작업을 진행하고 있는데 수치가 바로바로 보여서 아주 재밌게 하고 있는 중

@evenharder이하 생각해보니까 저도 "이론 상으로는"을 자주 쓰긴 하네요

괜히 쓰면 있어보이는 단어가 뭐가있을까? cascade가 가장 근접해 보이는 것 같긴하다

물론 소프트웨어 장인 정신에 가까운 것도 잃어버린지 오래되어 흔히 얘기하는 해커는 아니게 되었습니다. 그렇지만 AI로 바이브코딩이 가능해지고, 소프트웨어 엔지니어가 더 잘 사용할 수 있는 환경까지 마련되면서 소프트웨어 개발에 본질에 더 가까워질 수 있지 않나?라는 생각도 듭니다.

제가 생각하기엔 AI와 함께 인간 지능은 해결해야하는 문제와 이를 뒷받침하는 소프트웨어 구조에 더 잘 집중할 수 있다고 느꼈습니다. 그리고 이것들을 빠르게 반복하면서 개선할 수 있는 생산성까지 얻게된 셈이니까요. 적어도 몇년전부터 그리고 앞으로도 코딩에만 집중하지 못할 저에게는 그러한 부분이 더 크게 다가왔던것 같네요.

최근 바이브코딩에 너무 익숙해지며 생기는 반대 급부 문제도 있습니다만(모든 코드를 다 쉽게 accept한다던지 ㅋㅋㅋ), 발전된 기술을 사용하면서 오는 사이드 이펙트 정도로 생각하고 좋은 해결 방법을 계속 고민하면 되는 문제 정도라고 판단하고 있습니다.

세상은 너무 빠르게 바뀌고 있기 때문에 내년 여름쯤에는 또 다른 생각을 하고 있을수도 있겠습니다.

아 맞다 행사신청

Codex 쓸맘이 안드는게 ChatGPT는 틈만나면 친한척 해서 Claude 계속 씀

최적화 작업을 위해 프로파일러를 만들었는데 확실히 분석 도구가 있으니까 효율적으로 작업을 할 수 있게 된 것 같다. 이전에는 깜깜히 진행하는 느낌이였는데 본격적으로 활용할 수 있게 되니까 뭘 해야하지 잘 보이는 느낌임

잘 놀고와서 그런지 작업이 잘 된다