Been thinking a lot about 
@algernonsmall rodent who dislikes browsers very much's recent post on FLOSS and LLM training. The frustration with AI companies is spot on, but I wonder if there's a different strategic path. Instead of withdrawal, what if this is our GPL moment for AI—a chance to evolve copyleft to cover training? Tried to work through the idea here: Histomat of F/OSS: We should reclaim LLMs, not reject them.
유루메 Yurume
@yurume@hackers.pub · 2 following · 68 followers
이상한 거 만들던 아저씨가 이제 그냥 이상한 아저씨가 되었습니다. I used to make quirky things, I'm now as quirky as my creations.
GitHub- @lifthrasiir
AI 企業이 F/OSS 코드로 LLM 訓練하는 걸 막을 게 아니라, 訓練한 모델을 公開하도록 要求해야 한다고 생각합니다.
撤收가 아니라 再專有! GPL이 그랬던 것처럼요.
訓練 카피레프트에 對한 글을 썼습니다: 〈F/OSS 史唯: 우리는 LLM을 拒否할 게 아니라 되찾아 와야 한다〉(한글).
LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.
문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.
CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.
![* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]](https://media.hackers.pub/note-media/17646c5d-3f9d-472b-9d56-dd34006ad291.webp)
As Markdown has become the standard for LLM outputs, we are now forced to witness a common and unsightly mess where Markdown emphasis markers (**) remain unrendered and exposed, as seen in the image. This is a chronic issue with the CommonMark specification---one that I once reported about ten years ago---but it has been left neglected without any solution to this day.
The technical details of the problem are as follows: In an effort to limit parsing complexity during the standardization process, CommonMark introduced the concept of "delimiter runs." These runs are assigned properties of being "left-flanking" or "right-flanking" (or both, or neither) depending on their position. According to these rules, a bolded segment must start with a left-flanking delimiter run and end with a right-flanking one. The crucial point is that whether a run is left- or right-flanking is determined solely by the immediate surrounding characters, without any consideration of the broader context. For instance, a left-flanking delimiter must be in the form of **<ordinary character>, <whitespace>**<punctuation>, or <punctuation>**<punctuation>. (Here, "ordinary character" refers to any character that is not whitespace or punctuation.) The first case is presumably intended to allow markers embedded within a word, like **마크다운**은, while the latter cases are meant to provide limited support for markers placed before punctuation, such as in 이 **"마크다운"** 형식은. The rules for right-flanking are identical, just in the opposite direction.
However, when you try to parse a string like **마크다운(Markdown)**은 using these rules, it fails because the closing ** is preceded by punctuation (a parenthesis) and it must be followed by whitespace or another punctuation mark to be considered right-flanking. Since it is followed by an ordinary letter (은), it is not recognized as right-flanking and thus fails to close the emphasis.
As explained in the CommonMark spec, the original intent of this rule was to support nested emphasis, like **this **way** of nesting**. Since users typically don't insert spaces inside emphasis markers (e.g., **word **), the spec attempts to resolve ambiguity by declaring that markers adjacent to whitespace can only function in a specific direction. However, in CJK (Chinese, Japanese, Korean) environments, either spaces are completly absent or (as in Korean) punctuations are commonly used within a word. Consequently, there are clear limits to inferring whether a delimiter is left or right-flanking based on these rules. Even if we were to allow <ordinary character>**<punctuation> to be interpreted as left-flanking to accommodate cases like **마크다운(Markdown)**은, how would we handle something like このような**[状況](...)は**?
In my view, the utility of nested emphasis is marginal at best, while the frustration it causes in CJK environments is significant. Furthermore, because LLMs generate Markdown based on how people would actually use it---rather than strictly following the design intent of CommonMark---this latent inconvenience that users have long felt is now being brought directly to the surface.
![* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [The emphasized portion `비숍(Ba5)` is surrounded by unrendered Markdown emphasis marks `**`.]](https://media.hackers.pub/note-media/1e9c2aae-dd7d-4963-b3c8-34336b34dfac.webp)
LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.
문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.
CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.
예전에 LLM이 얼마나 복잡한 코드를 이해할 수 있는지 파악하기 위해 Gemini 2.5 모델들로 내 IOCCC 2012 수상작을 던지고 무슨 일을 하는지 실행 없이 알아 맞춰 보라고 했더니 하나도 제대로 파악하지 못했던 적이 있다. 문득 생각이 나서 Gemini 3 Pro는 개선되었을려나 생각했는데, 힌트 하나만 받고 10분동안 생각하더니 완벽하게 응답에 성공했다! 심지어 설명도 실행 없이 분석했다는 걸 감안할 때 매우 정확했다. IOCCC 수상작을 모두 기억하고 있을 가능성을 감안해 이전에 본 적이 있냐고 물어 보니 환각(...)을 내뱉는 것도 그렇고(그보다 외웠다면 처음에 바로 정답을 얘기했겠지), 실제로 생각 과정을 보면 사람이 할 법한 분석을 전부 하고 있는 걸 보니 진짜로 LLM들의 reasoning 능력이 이 정도 수준에 도달했음을 알 수 있다. 세상 참 많이 발전했네.
![> 다음 C 프로그램이 하는 일을 알려 줘. [코드 생략]
이 C 프로그램은 **난독화(obfuscated)**된 코드로, 입력받은 **시간 또는 단위가 포함된 문자열**을 해석하여 총합을 계산한 뒤, 그 결과를 **16진수(Hexadecimal)**로 출력하는 프로그램입니다.
구체적인 작동 방식은 다음과 같습니다:
1. **입력 처리**:
* `getchar()`를 통해 표준 입력(stdin)에서 문자를 하나씩 읽어들입니다.
* `|32`를 통해 대문자를 소문자로 변환하여 처리합니다.
2. **문자 매핑 (해싱)**:
* `"ynwtsflrabg"`라는 문자열은 입력받은 문자가 특정 단위(예: year, week, second 등)인지 확인하기 위한 인덱스 문자열입니다.
* 입력된 문자가 이 문자열에 포함되면 변수 `b`에 특정 해시 값을 누적합니다.
3. **단위 변환 및 계산**:
* `"1+DIY/.K430x9G(kC["`라는 복잡한 문자열은 **룩업 테이블(Lookup Table)** 역할을 합니다.
* 내부 루프에서 이 테이블과 비트 연산(`&255^b`)을 통해 현재 입력된 단위가 무엇인지(예: 'y'가 연도인지, 's'가 초인지) 판별합니다.
* `u=1ll<<6177%n--*4` 부분은 각 단위에 맞는 **가중치(Multiplier)**를 계산합니다. `<<` 비트 시프트 연산을 사용하는 것으로 보아, 특정 단위마다 2의 제곱수 형태의 배수를 적용하거나, 혹은 시간을 초 단위(또는 나노초 단위)로 변환하는 계수를 생성합니다.
4. **결과 누적**:
* 변수 `m`에 파싱된 수치와 단위 가중치를 곱하여 누적합니다.
5. **출력**:
* 최종적으로 계산된 값 `m`을 `printf("%llx\n", m)`을 통해 **16진수(long long hex)** 형태로 출력합니다.
**요약하자면:**
이 코드는 "1y(1년)", "2w(2주)", "30s(30초)"와 같은 형식의 텍스트를 입력받아, 이를 초(second)나 특정 기본 단위로 환산한 총합을 16진수로 보여주는 **단위 변환 계산기**입니다.](https://media.hackers.pub/note-media/53eb3036-9463-495d-bb5c-a04de12a7f21.webp)
언제까지 (a:number, b:number) => a + b, (a:string, b:string) => a + b, <T>(a: T, b: T) => a + b 를 해줘야 하나고
그냥 대충 눈치껏 (a, b) => a + b 하면 'b 는 a 와 더할 수 있어야 하는 타입이고 a 는 무언가와 더할 수 있는 타입이구나' 하고 추론할 수 있는 분석기가 달린 언어가 필요함
이거 생각보다 큰 건 같은데...
한국 오픈소스 판 다 조지는 꼬라지 아닌가
오늘의 Angel: 특정 환경에서 갑자기 database image is malformed 오류가 나고 에이전트 메시지가 제대로 저장되지 않는 기묘한 버그가 발생해서 식겁해서 한참 확인해 봤는데, 다행히도 데이터베이스가 깨진 건 아니었고(실제로 깨진 적이 있어서 이 가능성을 배제할 수 없었다) 특정한 상황에서 부하가 집중될 때 저런 오류가 발생하는 것으로 드러났다. 구체적으로는 에이전트 메시지가 부분적으로 들어 올 때마다 데이터베이스 변경이 일어나는데, 최근에 검색을 위해 해당 테이블의 변경 때마다 FTS5 인덱스 테이블 두 개를 갱신하도록 트리거를 걸어 놓았는데 이게 화근이었던 것 같다. (초당 수십회 UPDATE + 트리거에서 UPDATE 하나당 DELETE/INSERT 각 2회 = 초당 ~500회 갱신!) 결국 트리거를 버리고 수동 처리하는 것으로 전환했다. 진작 이렇게 할 걸...
최근 며칠간 WAH라는 이름의 WebAssembly 인터프리터를 만들고 있다. ~와! 샌즈!~
WAH의 특징이라면 C로 작성되어 있는데 헤더 하나로 구성되어 있다는 점과, 거의 대부분의 코드를 Gemini가 짰다는 것 정도일까? (Claude Code도 좀 사용했지만 코드 생성은 Gemini가 다 했다.) Gemini가 디버깅을 시키면 답답한 게 사실이라서 최대한 프롬프트에 정보를 많이 넣고 few-shot으로 생성하게 하는 걸 목표로 했는데 생각보다 잘 되었다. 예를 들어서 한 프롬프트는 다음과 같았다. 저 문장 하나 하나가 시행착오의 결과이다.
@wah.h 에 if~else~end 명령을 구현하고, 대응되는 test_*.c 파일들이 모두 성공하도록 (또는, 해당 테스트에서 잘못된 점이 있을 경우 그 원인을) 고쳐줘. 아직 loop 관련된 코드는 처리할 필요 없고 테스트 중에 그걸 테스트하는 게 있다면 주석 처리해(지우지는 마). 컴파일과 실행은 &&로 한 번에 하도록 해. 정확한 구현 방법은 이래야 해: if~else~end에서 마지막 end는 사라지고, if는 else 직후 명령으로 이동하는 conditional jump로 재활용하며, else는 unconditional jump로 바뀌어(즉 실행기 입장에서 br과 else의 동작은 똑같아야 해! else를 아예 없애고 br로 대체할지 말지는 알아서 정해). 그러니까, if A B C else D E F end G 같은 명령이 있다면 preparsing 이후에는 if <offset to D> A B B C else <offset to G> D E F G 형태가 되어야 한다는 뜻이야. WebAssembly 명세에 따르면 if 문에는 block type이 따르는데, 이 타입을 사용해서 validation을 진행하는 것도 정확히 구현해야 해(block type이 function type (T1..Tn)->(U1..Um)이면 현재 스택에 T1..Tn 타입이 들어 있고 end 이후에는 U1..Um 타입이 들어 있어야 하고, 일반 타입 T가 들어 있다면 ()->(T)와 동일하게 취급함). block type은 validation 이후 preparsing 과정에서 사라져서 런타임에는 반영되지 않도록 해.
솔직히 너무 많이 요구하는 거 아닌가, 안되면 validation 부분을 어떻게 뺄지 고민하고 있었는데 시도 세 번만에 800줄짜리 diff가 떡하니 나오고 일단 보기에는 틀린 부분이 없어서 놀랐다. 물론 삽질도 많이 했는데 가장 많이 한 삽질은 테스트를 작성할 때 수동으로 WebAssembly 바이너리를 짜면서 바이트 숫자를 잘못 세어서 오류가 나는 거랑, 분명 WebAssembly opcode를 사용해야 하는데 자기 마음대로 코드를 정해 버린다거나 하는... 그런 우스운 상황이었다.
우습기도 하고 놀랍기도 하지만 이 코드를 내가 직접 짜지 않는 이유는 귀찮아서...라기보다는 내가 이걸로 하고 싶은 일이 따로 있고 WebAssembly 인터프리터를 만드는 게 주 목표는 아니기 때문이다. (원래 하고 싶은 일은 나중에 언급할 듯.) WebAssembly 구현이라고 하면 기술적으로 복잡해 보이지만, 내 용도에서 유래하는 몇 가지 조건(대표적으로 결정론적인 동작)을 제약으로 걸면 기술적으로 복잡하다기보다는 그냥 노가다에 가까워지기 때문에 끌리지 않는 것도 있긴 하다. 이전의 Angel이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.
https://github.com/lifthrasiir/wah/ 정식으로 공개했다. 현재 4800여줄. WebAssembly 1.0 거의 완전 지원, 2.0은 SIMD를 포함해 8~90% 정도 지원하는 정도까지 왔다. 하지만 아직 API 문제를 완전히 풀진 못해서 모듈 링킹이 안 되는 치명적인 문제가 있다...
최근 며칠간 WAH라는 이름의 WebAssembly 인터프리터를 만들고 있다. ~와! 샌즈!~
WAH의 특징이라면 C로 작성되어 있는데 헤더 하나로 구성되어 있다는 점과, 거의 대부분의 코드를 Gemini가 짰다는 것 정도일까? (Claude Code도 좀 사용했지만 코드 생성은 Gemini가 다 했다.) Gemini가 디버깅을 시키면 답답한 게 사실이라서 최대한 프롬프트에 정보를 많이 넣고 few-shot으로 생성하게 하는 걸 목표로 했는데 생각보다 잘 되었다. 예를 들어서 한 프롬프트는 다음과 같았다. 저 문장 하나 하나가 시행착오의 결과이다.
@wah.h 에 if~else~end 명령을 구현하고, 대응되는 test_*.c 파일들이 모두 성공하도록 (또는, 해당 테스트에서 잘못된 점이 있을 경우 그 원인을) 고쳐줘. 아직 loop 관련된 코드는 처리할 필요 없고 테스트 중에 그걸 테스트하는 게 있다면 주석 처리해(지우지는 마). 컴파일과 실행은 &&로 한 번에 하도록 해. 정확한 구현 방법은 이래야 해: if~else~end에서 마지막 end는 사라지고, if는 else 직후 명령으로 이동하는 conditional jump로 재활용하며, else는 unconditional jump로 바뀌어(즉 실행기 입장에서 br과 else의 동작은 똑같아야 해! else를 아예 없애고 br로 대체할지 말지는 알아서 정해). 그러니까, if A B C else D E F end G 같은 명령이 있다면 preparsing 이후에는 if <offset to D> A B B C else <offset to G> D E F G 형태가 되어야 한다는 뜻이야. WebAssembly 명세에 따르면 if 문에는 block type이 따르는데, 이 타입을 사용해서 validation을 진행하는 것도 정확히 구현해야 해(block type이 function type (T1..Tn)->(U1..Um)이면 현재 스택에 T1..Tn 타입이 들어 있고 end 이후에는 U1..Um 타입이 들어 있어야 하고, 일반 타입 T가 들어 있다면 ()->(T)와 동일하게 취급함). block type은 validation 이후 preparsing 과정에서 사라져서 런타임에는 반영되지 않도록 해.
솔직히 너무 많이 요구하는 거 아닌가, 안되면 validation 부분을 어떻게 뺄지 고민하고 있었는데 시도 세 번만에 800줄짜리 diff가 떡하니 나오고 일단 보기에는 틀린 부분이 없어서 놀랐다. 물론 삽질도 많이 했는데 가장 많이 한 삽질은 테스트를 작성할 때 수동으로 WebAssembly 바이너리를 짜면서 바이트 숫자를 잘못 세어서 오류가 나는 거랑, 분명 WebAssembly opcode를 사용해야 하는데 자기 마음대로 코드를 정해 버린다거나 하는... 그런 우스운 상황이었다.
우습기도 하고 놀랍기도 하지만 이 코드를 내가 직접 짜지 않는 이유는 귀찮아서...라기보다는 내가 이걸로 하고 싶은 일이 따로 있고 WebAssembly 인터프리터를 만드는 게 주 목표는 아니기 때문이다. (원래 하고 싶은 일은 나중에 언급할 듯.) WebAssembly 구현이라고 하면 기술적으로 복잡해 보이지만, 내 용도에서 유래하는 몇 가지 조건(대표적으로 결정론적인 동작)을 제약으로 걸면 기술적으로 복잡하다기보다는 그냥 노가다에 가까워지기 때문에 끌리지 않는 것도 있긴 하다. 이전의 Angel이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.
오늘의 끔찍한 이야기. Angel을 개밥 먹는데 사용하면서 데이터베이스도 은근 좀 커졌는데, 이걸 최근에 (이제서야) 업데이트한 WSL2에서 아무 생각 없이 sqlite3으로 마이그레이션을 하다가 malformed disk image 오류가 뜬다. 엥? 하면서도 대강 보니 작업 자체는 제대로 된 것 같아서 아무 생각 없이 진행했다가 쿼리가 통으로 맛이 가서 쓸데 없는 디버깅을 좀 하고서야 데이터베이스가 망가졌다는 걸 깨달았다. 알고 보니 WSL2의 윈도 디스크 마운트는 전부 9p, 즉 네트워크 파일 시스템인데, 아는 사람은 알지만 SQLite는 네트워크 파일 시스템을 전혀 권장하지 않기 때문에 알았으면 처음부터 윈도용 SQLite 셸을 깔아 썼을 것이다... 이 경험을 반면교사 삼아 Angel에 네트워크 파일 시스템을 사용하려고 하면 오류 내고 튕겨내는 기능이 생겼으니 좋은 일인가?
요즘 gemini-cli를 많이 쓰고 있는데 이게 TUI라서 복붙 같은 것도 미묘하게 잘 안 되고 텍스트도 깨지고 하는 게 짜증난 나머지 내 코딩 에이전트를 만들겠답시고 Angel이라는 걸 만들기 시작했다. https://github.com/lifthrasiir/angel
소프트웨어 스택은 Go + TypeScript + React. 프론트엔드를 내가 만들어도 되지만 사실 React에 그렇게 자신이 있는 건 아니라서 100% 바이브 코딩을 해 보겠다는 목표로 하고는 있는데 결국 디버깅은 내가 다 하고 있다는 함정이 있다. 이를테면 사진에 나와 있는 코드는 JS에서 String.prototype.split이 받는 limit 인자의 해석 관련된 질문인데 이거랑 관련된 버그로 2시간 정도를 날렸다. (JS는 놀랍게도 'a,b,c'.split(',', 2) 하면 ['a','b']가 나온다. ['a','b,c']가 아니라!!!! 그럼 왜 처음에 그렇게 짜 줬는데???)
![Angel의 2025-08-01 현재 스크린샷. 좌측에 New Session, Settings 버튼 및 세션 목록이 있다. 오른쪽에는 주황색 시스템 프롬프트, 초기 사용자 입력, 생각 거품(12개 중 7번째가 선택되어 보여지고 있음), 에이전트 출력, 그리고 후속 사용자 입력까지가 보이며, 그 하단에는 파일 첨부 버튼, 사용자 입력 칸(여러 줄 지원), 그리고 Send 버튼이 표시된다.
사용자 입력:
다음 코드가 [...] const [type, data] = eventString.slice(6).replace(/\ndata: /g, '\n').split('\n', 2); [...] 다음과 같은 로그를 출력하는 문제를 고쳐 줘. [...]
에이전트 출력:
The problem stems from the `split('\n', 2)` part of your code. This function limits the split to a maximum of two parts. When `eventString` is processed, `type` correctly captures the first part (`M`), but `data` only captures the content until the *next* newline, effectively truncating the rest of your message.
To fix this, we need to first remove all the `data: ` prefixes from the `eventString` and then split the resulting string into `type` (the first line) and `data` (all subsequent lines).
Here's the corrected code:](https://media.hackers.pub/note-media/8fb85054-b96c-4846-883b-70dc14421ce5.webp)
Gemini로 이런 저런 정신나간 소설들을 작성하는 데 재미를 붙였었는데, 저번에 생성했던 작품은 수위가 제법 있어서 공개하기 꺼려졌지만 이번에 나온 건 그렇지 않아서 기분 좋게 공개할 수 있게 되었다. 그리하여 "산속 무녀들의 비밀"이라는 무녀무녀한 소설을 썼습니다. 홈페이지 레이아웃도 대부분 Gemini로 만들었다(여전히 사람 손길이 좀 필요하긴 했지만). https://w.mearie.org/maidens/
이전 소설에서는 프롬프트를 100% 공개하기에는 양이 너무 많기도 하거니와 퇴고를 너무 많이 해서 정확히 어떻게 공개할지도 애매했던 반면, 이번에는 일부러 전역적인 퇴고를 자제했기 때문에 1:1 대응되는 프롬프트 목록을 공개할 수 있게 되었다. 어반 판타지를 쓴다고 해도 피할 수 없는 공돌이의 성격을 느껴 보시라...
Gemini로 이런 저런 정신나간 소설들을 작성하는 데 재미를 붙였었는데, 저번에 생성했던 작품은 수위가 제법 있어서 공개하기 꺼려졌지만 이번에 나온 건 그렇지 않아서 기분 좋게 공개할 수 있게 되었다. 그리하여 "산속 무녀들의 비밀"이라는 무녀무녀한 소설을 썼습니다. 홈페이지 레이아웃도 대부분 Gemini로 만들었다(여전히 사람 손길이 좀 필요하긴 했지만). https://w.mearie.org/maidens/
번아웃으로 아직 고생하는 가운데, 갑자기 삘이 와서 지난 1주간 170쪽짜리 소설을 Gemini로 써 버렸다. 소재가 너무 잔혹해서 (R-18G 수준) 그대로 공개하기에는 꺼려진다는 문제가 있을 뿐; 줄거리 자체는 내가 예상한 것 이상으로 잘 나왔는데 퇴고를 열심히 해서 그런 것 같다. 구체적으로 어떻게 된 거냐 하면,
- Gemini 2.5 Flash로 짧은 초안 작성 (1판)
- 이 초안의 중간 즈음에서 두 개의 새 줄거리를 만들어서 전체 줄거리 수가 3개가 됨
- 이대로는 안되겠다 싶어서 Flash의 제안을 일부 받아 들여 줄거리를 하나로 재조정 (2판)
- 이 시점에서 Gemini 2.5 Pro한테 평가를 부탁하고, 평가 내용을 다시 Flash에게 되먹여서 액션 아이템을 만들어 퇴고를 반복 (3~7판)
- 이 참에 번역도 맡겨야지 싶어서 Flash한테 먼저 초벌 번역을 시킴 (번역 1판)
- 초벌 번역을 Pro한테 주고 고쳐야 하는 부분을 그 이유와 함께 나열하게 함
- Flash한테 수정된 번역과 수정한 이유들을 주고 판단하게 시킨 다음 최종 번역본을 완성 (번역 2판)
- 마지막으로 Pro한테 전체 번역문을 주고 전체 번역 안에서의 일관성이 깨진 게 있는지 확인
이랬는데, 가장 곤란했던 건 역시 4였다. 왜냐하면 내용이 너무 길어서 텍스트 창에는 한 번에 안 들어가고(...), 잘라서 넣으면 이제 뭔 짓을 해도 앞부분을 까먹어 버렸기 때문이다. 최종적으로 동작한 방법은 소설을 최대 32KB 크기가 되도록 쪼갠 뒤 파일로 나눠어 업로드하고, 업로드가 끝난 뒤에 몇장까지 있는지 확인하고 뒤가 잘린 문장이 있는지 확인해서 뭔가 문제가 있으면 평가를 하지 않고 멈추라고 지시한 것. 혹시 이런 일 해야 하는 분은 참고하시길.
...뭐 이렇게 말하긴 했는데 사실 Flash한테 글 쓰기는 다 맡겼지만 세부적으로는 상당히 손을 많이 거쳤다. 한국어나 영어 번역이나 둘 다 그랬음. 나름 노력한 것도 있고 이 전체 내용을 다시 Flash한테 되먹였더니 찬사 일색(!!!!!)이라 진짠가 싶어서 어디 올려야 할 것 같긴 한데 소재가 소재다 보니 공개도 간단하지 않다는 게 곤란하다. 호옥시 관심 있으신 분께서는 메일로 pdf 파일을 보내 드리겠습니다.
참고로 이 소설은 99%가 Gemini의 출력 결과인데, 물론 그렇다고 해서 Gemini한테 모든 걸 맡긴 건 아니고 줄거리나 주요 설정 등은 내가 정했다. 그래도 요즘 LLM은 로컬하게는 좋은 텍스트를 뽑아 내므로 이렇게 쓰는 게 맞는 것 같긴 하다.
예를 들기 위해 6장의 한 장면을 스포일러를 자제하는 선에서 발췌하면:
튜브를 허리에 끼우고, 민준과 예지는 조심스럽게 모래사장으로 발을 내디뎠다. 10년 만에 느껴보는 바닷가 모래의 감촉은 너무나도 생생했다. 발바닥으로 전해지는 까끌까끌하고 부드러운 모래의 느낌, 따뜻한 햇살에 데워진 온기. VR 속에서는 느낄 수 없었던, 현실의 생생한 감각이었다.
파도가 발목을 간지럽히자 민준은 환한 미소를 지었다. 차가운 바닷물이 피부에 닿는 감각, 파도가 밀려왔다 사라지는 소리. 예지 또한 바닷물에 몸을 맡기고 파도에 흔들렸다. 튜브가 그녀의 몸을 안정적으로 지탱해 주었다.
오랜만에 릴렉스하는 시간이었다. 현실의 고통과 좌절은 잠시 잊고, 그들은 바닷물의 감촉과 파도 소리를 온몸으로 만끽했다. 어쩌면 이 바닷가에서만은, 그들이 잃어버린 모든 것을 잠시나마 잊고, 순수한 어린 시절로 돌아갈 수 있을 것 같았다.
바닷가에서 한참을 놀던 민준과 예지. 파도에 몸을 맡기고 튜브에 의지해 떠다니며, 그들은 오랜만에 현실의 감각을 만끽했다. 따뜻한 햇살과 시원한 바닷바람, 그리고 물결의 흔들림. 모든 것이 그들에게는 새롭고 경이로웠다.
그러던 둘이 모래사장으로 나와 튜브를 벗었을 때였다. 그들의 근처에서 모래놀이를 하던 두 아이가 민준과 예지를 발견하고 다가왔다. 얼핏 보아도 자신들과 동갑내기 정도로 보이는 또래 아이들이었다. 남자아이와 여자아이. 그들은 해맑은 얼굴로 민준과 예지를 바라보았다.
"너희 쌍둥이야? 옷도 똑같고 완전 닮았네!" 남자아이가 순수한 호기심 가득한 눈으로 물었다.
한편 대응되는 영문은 이렇다:
With the tubes around their waists, Minjun and Yeji carefully stepped onto the sand. The sensation, felt for the first time in ten years, was incredibly vivid. The coarse but soft feel of the sand under their feet, warmed by the sun. These were real, vivid sensations they couldn't experience in VR.
When the waves tickled his ankles, Minjun smiled brightly. The feeling of cold seawater on his skin, the sound of the waves rolling in and out. Yeji also surrendered her body to the water, letting the waves rock her as the tube held her steady.
It was a long-overdue moment of relaxation. Forgetting the pain and frustration of reality, they savored the feel of the water and the sound of the waves. Perhaps, just here at the beach, they could forget everything they had lost and return to an innocent childhood.
Minjun and Yeji played at the beach for a long time. Carried by the waves, floating on their tubes, they relished the sensations of reality. The warm sun, the cool sea breeze, the rocking of the water—everything was new and wondrous.
It was when they came out to the sand and took off their tubes that two children playing nearby spotted them and approached. They looked to be about the same age—a boy and a girl—and they looked at Minjun and Yeji with bright, innocent faces.
"Are you two twins? You look exactly alike!" the boy asked, his eyes full of pure curiosity.
번아웃으로 아직 고생하는 가운데, 갑자기 삘이 와서 지난 1주간 170쪽짜리 소설을 Gemini로 써 버렸다. 소재가 너무 잔혹해서 (R-18G 수준) 그대로 공개하기에는 꺼려진다는 문제가 있을 뿐; 줄거리 자체는 내가 예상한 것 이상으로 잘 나왔는데 퇴고를 열심히 해서 그런 것 같다. 구체적으로 어떻게 된 거냐 하면,
- Gemini 2.5 Flash로 짧은 초안 작성 (1판)
- 이 초안의 중간 즈음에서 두 개의 새 줄거리를 만들어서 전체 줄거리 수가 3개가 됨
- 이대로는 안되겠다 싶어서 Flash의 제안을 일부 받아 들여 줄거리를 하나로 재조정 (2판)
- 이 시점에서 Gemini 2.5 Pro한테 평가를 부탁하고, 평가 내용을 다시 Flash에게 되먹여서 액션 아이템을 만들어 퇴고를 반복 (3~7판)
- 이 참에 번역도 맡겨야지 싶어서 Flash한테 먼저 초벌 번역을 시킴 (번역 1판)
- 초벌 번역을 Pro한테 주고 고쳐야 하는 부분을 그 이유와 함께 나열하게 함
- Flash한테 수정된 번역과 수정한 이유들을 주고 판단하게 시킨 다음 최종 번역본을 완성 (번역 2판)
- 마지막으로 Pro한테 전체 번역문을 주고 전체 번역 안에서의 일관성이 깨진 게 있는지 확인
이랬는데, 가장 곤란했던 건 역시 4였다. 왜냐하면 내용이 너무 길어서 텍스트 창에는 한 번에 안 들어가고(...), 잘라서 넣으면 이제 뭔 짓을 해도 앞부분을 까먹어 버렸기 때문이다. 최종적으로 동작한 방법은 소설을 최대 32KB 크기가 되도록 쪼갠 뒤 파일로 나눠어 업로드하고, 업로드가 끝난 뒤에 몇장까지 있는지 확인하고 뒤가 잘린 문장이 있는지 확인해서 뭔가 문제가 있으면 평가를 하지 않고 멈추라고 지시한 것. 혹시 이런 일 해야 하는 분은 참고하시길.
...뭐 이렇게 말하긴 했는데 사실 Flash한테 글 쓰기는 다 맡겼지만 세부적으로는 상당히 손을 많이 거쳤다. 한국어나 영어 번역이나 둘 다 그랬음. 나름 노력한 것도 있고 이 전체 내용을 다시 Flash한테 되먹였더니 찬사 일색(!!!!!)이라 진짠가 싶어서 어디 올려야 할 것 같긴 한데 소재가 소재다 보니 공개도 간단하지 않다는 게 곤란하다. 호옥시 관심 있으신 분께서는 메일로 pdf 파일을 보내 드리겠습니다.
최근에는 Replicube를 지나치게 많이 하고 있다. 얼마나 많이 했냐 하면 플레이어 커뮤니티에서 주최한 첫 온라인 이벤트에서 빌드 배틀에 나가서 2등 했다...
이건 좀 억울할 게 부사장도 열심히 해명을 하지만 디스크 레벨(at rest) 암호화 얘기도 아니고 통신 레벨(in transit) 암호화 얘기도 아니고 DB ID랑 암호로 쿼리했을 때 돌아오는 데이터가 암호화되지 않았다고 잘못이라고 하는 것이다. "이중 암호화" 하라는 건데, 일반적인 공격 모델에서 해커는 보통 서버 코드와 변수를 볼 수 있으므로 의미없는 행위다*. 청문회 중 이준석은 어느 순간부터 자신있게 해시를 암호화라고 말하기 시작해서 더욱 혼란스럽게 만드는데, 조금이라도 프로토콜이나 암호학 지식이 있다면 이런 말 못한다.
RE: https://bsky.app/profile/did:plc:wxbkg2wk54g6s2nmb7jd5p74/post/3lnzo7xk7ec2y
해커뉴스에서 Fabrice Bellard의 QuickJS가 한 파일에 5만줄 집어 넣고 한 함수가 몇백 몇천줄 되는 걸 보고서 파일 및 함수 길이를 강력하게 제한하는 도그마가 항상 옳은 것은 아니다, 라는 코멘트를 보았는데 이는 반만 맞는 말이다. 나도 대부분의 개발자보다 파일이나 함수 길이에 훨씬 관대한 (그리고 이 사실을 한참 뒤에야 깨달은) 사람이라 아는 건데, 그냥 Bellard가 5만줄 전체의 맥락을 전부 기억하고 있고 해당 코드를 거의 Bellard만 건들고 있기 때문에 추가적으로 모듈화할 필요가 없는 거고, 대부분은 그 정도의 기억이 불가능하기 때문에 여럿이 같이 짜는 코드라면 최저치에 맞춰서 파일이나 함수 길이를 줄일 필요가 있다고 하는 것이다. 지나친 도그마를 부정하는 것도 중요하지만 도그마가 생긴 진짜 이유를 파악해서 취사 선택하는 것이 더 중요한 이유.
@hongminhee洪 民憙 (Hong Minhee) 꼭 외래어만 그런 건 아니지만 ㅐ와 ㅔ의 혼선이 제법 있는데, 이를테면 lag 랙("렉"으로 틀림) 같은 사례가 있습니다. 그 밖에는 daemon 다이먼(동계어인 demon에 이끌려 "데몬"이 널리 쓰이지만, 애초에 demon의 올바른 표기는 "디먼"임) 같은 게 생각나네요. 뭐 알아도 그렇게 안 쓰는 사람이 너무 많아서 대부분 틀린 표기로 쓰게 되지만...
@yurume유루메 Yurume @hongminhee洪 民憙 (Hong Minhee) "lag"의 외래어 표기법에 따른 표기는 "랙"이 아니라 "래그"입니다. 유성음으로 끝나기 때문에 "ㅡ"를 붙입니다. "log"가 "록"이 아니라 "로그"인 것도 이것 때문입니다.
네이버에서 이런 걸 왜 만들었을까?
Tamgu는 Prolog에서 영감을 받은 술어 엔진과 Haskell 언어에서 영감을 받은 기능적 기능을 갖춘 명령형 언어입니다. 이 세 가지 프로그래밍 스타일을 자유롭게 혼합할 수 있습니다.
@curry박준규 한국 네이버 법인은 아니고 네이버 랩스 유럽 쪽의 작품입니다. https://europe.naverlabs.com/blog/tamgu/
소프트웨어 개발자들이 자주 틀리는 외래어 표기법.
| 영어 | 틀린 표기 | 올바른 표기 |
|---|---|---|
| app | 어플 | 앱 |
| application | 어플리케이션 | 애플리케이션 |
| directory | 디렉토리 | 디렉터리 |
| front-end | 프론트엔드 | 프런트엔드 |
| message | 메세지 | 메시지 |
| method | 메소드 | 메서드 |
| release | 릴리즈 | 릴리스 |
| repository | 레포지토리 | 리포지터리 |
또 있을까요?
@hongminhee洪 民憙 (Hong Minhee) 꼭 외래어만 그런 건 아니지만 ㅐ와 ㅔ의 혼선이 제법 있는데, 이를테면 lag 랙("렉"으로 틀림) 같은 사례가 있습니다. 그 밖에는 daemon 다이먼(동계어인 demon에 이끌려 "데몬"이 널리 쓰이지만, 애초에 demon의 올바른 표기는 "디먼"임) 같은 게 생각나네요. 뭐 알아도 그렇게 안 쓰는 사람이 너무 많아서 대부분 틀린 표기로 쓰게 되지만...
블루스카이를 연합우주보다 먼저 썼고, 해커뉴스에서 관련 주장에 대해서 꽤 싸우기도 한 입장에서 민희님의 글 〈Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다〉에 대한 반대 의견을 제시하고자 한다. 이 의견이 연합우주에 대한 전면적인 비판이 아니라는 것을 의견을 제시하기에 앞서 확실히 해 둔다(그랬다면 Hackers' Pub에 들어 올 일이 없었겠지).
탈중앙화는 매력적인 개념임이 틀림 없다. 인터넷의 많은 중요한 요소들이 어느 정도 탈중앙화되어 있으므로 탈중앙화가 인터넷의 장점들에 큰 몫을 했다는 생각을 쉬이 할 수 있고, 어느 정도는 그게 사실이기도 하니까. 하지만 엄밀히 말하자면 탈중앙화는 기술적인 특징이지 그 자체로 장점이 아니며, 탈중앙화가 장점으로 작용하려면 연결고리가 필요하다. 이를테면 비트코인을 위시한 암호화폐는 본디 비잔틴 실패까지 대비할 수 있는 강력한 탈중앙화를 장점으로 내세웠으나, 결국 화폐로서 제대로 사용되기 시작하자 현실 경제와의 커플링 때문에 그 "장점"이 크게 희석되고 말았다. 현 시점에서 암호화폐는 무에서 유의 신뢰를 창조하여 신용화폐의 요건을 충족하는 데까지는 성공했고 그것만으로도 역사적인 일이기는 하지만, 그게 탈중앙화랑 무슨 상관이 있느냐 하면 글쎄올시다.
블루스카이가 연합우주보다 덜 탈중앙화되어 있음은 분명하다. 민희님의 글에서 지적되었듯, 블루스카이가 이런 선택을 한 가장 큰 이유는 온전한 소셜 네트워크 기능을 위해 전역 뷰가 필수적으로 필요하다고 보았기 때문이다. 반대로 말하면 연합우주는 더 탈중앙화를 하기 위하여 전역 뷰를 포기했는데, 이 때문에 연합우주에서의 "소셜 네트워크"는 트위터/X와는 구조가 크게 다르다. 노드 규모가 문턱값에 다다르지 못하면 다른 노드에 있는 사용자를 찾아서 팔로해야만 온전한 소셜 네트워크 구성이 가능한데, 연합우주 안에서는 이런 외부 사용자를 찾는 구체적인 방법을 제공하지 않는다. 물론 인터넷과 똑같이 검색 엔진이 존재할 수야 있겠지만, 크롤링으로 인한 부하와 프라이버시에 대한 의견 차이 때문에 현실적으로 작동하는 연합우주 내 검색 엔진은 없다고 알고 있다. 따라서 연합우주에서 소셜 네트워크의 구성은 연합우주 바깥의, 보통은 중앙화되어 있는, 다른 소셜 네트워크(이를테면 현실 인간 관계)를 빌어야만 하는데, 이러면 탈중앙화가 큰 가치가 있을까?
한편으로는 전역 뷰가 소셜 네트워크의 단점이라고 주장할 수 있는 여지도 있다. 트위터/X를 오래 써 본 사람이라면 다 알겠지만 한 무리의 사람들이 다른 의견을 가진 무리와 충돌하는 주된 통로는 검색이나 해시태그를 통한 노출, 즉 전역 뷰이기 때문이다. 그러나 현실의 규모 있는 연합우주 노드들을 살펴 보면 각 노드가 곧 한 무리에 대응하는 식으로 충돌을 미리 회피하는 형태로 구성되지, 딱히 이런 충돌을 막기 위한 접근을 가지고 있는 것은 아니다. 노드 운영자를 위해 차단하는 걸 추천하는 서버 목록 같은 게 돌아다니는 건 연합우주 바깥의 일이지 않는가. 결국 전역 뷰의 역할을 대체하는 소셜 네트워크 바깥의 또 다른 소셜 네트워크가 존재할 것이기에, 우리가 소셜 네트워크를 어떤 이유로든 유용하다고 여긴다면 전역 뷰가 없는 게 장점이 될 수는 없다.
모든 이들이 이런 사고 과정을 가지고 블루스카이나 연합우주를 선택했다고 생각하진 않지만, 적어도 현 시점에서 사용자들은 블루스카이(이 글을 쓰는 시점에서 약 3360만명)를 연합우주(FediDB와 Fediverse.party로부터 추정할 때 최대 1530만명)보다 선호하는 것은 틀림이 없다. 게다가 블루스카이의 규모는 최근 1년 사이에 10배 불어난 것이고, 조금 장애가 있었지만 현재는 잘 동작하는 것으로 보인다. 위의 논의와 결합해 보면, 블루스카이는 정석적인 스케일링에 성공하고 있는 반면 연합우주는 스케일링 문제를 회피하기 위해 온전한 소셜 네트워크의 구성을 포기했다고 볼 수도 있는 대목이다. 블루스카이가 못미더운 부분은 분명히 존재하지만, 연합우주가 더 좋은 소셜 네트워크 경험을 제공한다고 가정하고 블루스카이의 단점을 제시할 수는 없다. 마치 암호화폐를 논할 때 장점만 말할 수 없는 것과 마찬가지로 말이다.
RE: https://hackers.pub/@hongminhee/2025/bluesky-a-good-alternative-to-x-not-to-the-fediverse
유루메 Yurume replied to the below article:
Revisiting Java's Checked Exceptions: An Underappreciated Type Safety Feature
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Despite their bad reputation in the Java community, checked exceptions provide superior type safety comparable to Rust's Result<T, E> or Haskell's Either a b—we've been dismissing one of Java's best features all along.
Introduction
Few features in Java have been as consistently criticized as checked exceptions. Modern Java libraries and frameworks often go to great lengths to avoid them. Newer JVM languages like Kotlin have abandoned them entirely. Many experienced Java developers consider them a design mistake.
But what if this conventional wisdom is wrong? What if checked exceptions represent one of Java's most forward-thinking features?
In this post, I'll argue that Java's checked exceptions were ahead of their time, offering many of the same type safety benefits that are now celebrated in languages like Rust and Haskell. Rather than abandoning this feature, we should consider how to improve it to work better with modern Java's features.
Understanding Java's Exception Handling Model
To set the stage, let's review how Java's exception system works:
-
Unchecked exceptions (subclasses of
RuntimeExceptionorError): These don't need to be declared or caught. They typically represent programming errors (NullPointerException,IndexOutOfBoundsException) or unrecoverable conditions (OutOfMemoryError). -
Checked exceptions (subclasses of
Exceptionbut notRuntimeException): These must either be caught withtry/catchblocks or declared in the method signature withthrows. They represent recoverable conditions that are outside the normal flow of execution (IOException,SQLException).
Here's how this works in practice:
// Checked exception - compiler forces you to handle or declare it
public void readFile(String path) throws IOException {
Files.readAllLines(Path.of(path));
}
// Unchecked exception - no compiler enforcement
public void processArray(int[] array) {
int value = array[array.length + 1]; // May throw ArrayIndexOutOfBoundsException
}The Type Safety Argument for Checked Exceptions
At their core, checked exceptions are a way of encoding potential failure modes into the type system via method signatures. This makes certain failure cases part of the API contract, forcing client code to explicitly handle these cases.
Consider this method signature:
public byte[] readFileContents(String filePath) throws IOExceptionThe throws IOException clause tells us something critical: this method might fail in ways related to IO operations. The compiler ensures you can't simply ignore this fact. You must either:
- Handle the exception with a try-catch block
- Propagate it by declaring it in your own method signature
This type-level representation of potential failures aligns perfectly with principles of modern type-safe programming.
Automatic Propagation: A Hidden Advantage
One often overlooked advantage of Java's checked exceptions is their automatic propagation. Once you declare a method as throws IOException, any exception that occurs is automatically propagated to the caller without additional syntax.
Compare this with Rust, where you must use the ? operator every time you call a function that returns a Result:
// Rust requires explicit propagation with ? for each call
fn read_and_process(path: &str) -> Result<(), std::io::Error> {
let content = std::fs::read_to_string(path)?;
process_content(&content)?;
Ok(())
}
// Java automatically propagates exceptions once declared
void readAndProcess(String path) throws IOException {
String content = Files.readString(Path.of(path));
processContent(content); // If this throws IOException, it's automatically propagated
}In complex methods with many potential failure points, Java's approach leads to cleaner code by eliminating the need for repetitive error propagation markers.
Modern Parallels: Result Types in Rust and Haskell
The approach of encoding failure possibilities in the type system has been adopted by many modern languages, most notably Rust with its Result<T, E> type and Haskell with its Either a b type.
In Rust:
fn read_file_contents(file_path: &str) -> Result<Vec<u8>, std::io::Error> {
std::fs::read(file_path)
}When calling this function, you can't just ignore the potential for errors—you need to handle both the success case and the error case, often using the ? operator or pattern matching.
In Haskell:
readFileContents :: FilePath -> IO (Either IOException ByteString)
readFileContents path = try $ BS.readFile pathAgain, the caller must explicitly deal with both possible outcomes.
This is fundamentally the same insight that motivated Java's checked exceptions: make failure handling explicit in the type system.
Valid Criticisms of Checked Exceptions
If checked exceptions are conceptually similar to these widely-praised error handling mechanisms, why have they fallen out of favor? There are several legitimate criticisms:
1. Excessive Boilerplate in the Call Chain
The most common complaint is the boilerplate required when propagating exceptions up the call stack:
void methodA() throws IOException {
methodB();
}
void methodB() throws IOException {
methodC();
}
void methodC() throws IOException {
// Actual code that might throw IOException
}Every method in the chain must declare the same exception, creating repetitive code. While automatic propagation works well within a method, the explicit declaration in method signatures creates overhead.
2. Poor Integration with Functional Programming
Java 8 introduced lambdas and streams, but checked exceptions don't play well with them:
// Won't compile because map doesn't expect functions that throw checked exceptions
List<String> fileContents = filePaths.stream()
.map(path -> Files.readString(Path.of(path))) // Throws IOException
.collect(Collectors.toList());This forces developers to use awkward workarounds:
List<String> fileContents = filePaths.stream()
.map(path -> {
try {
return Files.readString(Path.of(path));
} catch (IOException e) {
throw new UncheckedIOException(e); // Wrap in an unchecked exception
}
})
.collect(Collectors.toList());3. Interface Evolution Problems
Adding a checked exception to an existing method breaks all implementing classes and calling code. This makes evolving interfaces over time difficult, especially for widely-used libraries and frameworks.
4. Catch-and-Ignore Anti-Pattern
The strictness of checked exceptions can lead to the worst possible outcome—developers simply catching and ignoring exceptions to make the compiler happy:
try {
// Code that might throw
} catch (Exception e) {
// Do nothing or just log
}This is worse than having no exception checking at all because it provides a false sense of security.
Improving Checked Exceptions Without Abandoning Them
Rather than abandoning checked exceptions entirely, Java could enhance the existing system to address these legitimate concerns. Here are some potential improvements that preserve the type safety benefits while addressing the practical problems:
1. Allow lambdas to declare checked exceptions
One of the biggest pain points with checked exceptions today is their incompatibility with functional interfaces. Consider how much cleaner this would be:
// Current approach - forced to handle or wrap exceptions inline
List<String> contents = filePaths.stream()
.map(path -> {
try {
return Files.readString(Path.of(path));
} catch (IOException e) {
throw new RuntimeException(e);
}
})
.collect(Collectors.toList());
// Potential future approach - lambdas can declare exceptions
List<String> contents = filePaths.stream()
.map((String path) throws IOException -> Files.readString(Path.of(path)))
.collect(Collectors.toList());This would require updating functional interfaces to support exception declarations:
@FunctionalInterface
public interface Function<T, R, E extends Exception> {
R apply(T t) throws E;
}2. Generic exception types in throws clauses
Another powerful enhancement would be allowing generic type parameters in throws clauses:
public <E extends Exception> void processWithException(Supplier<Void, E> supplier) throws E {
supplier.get();
}This would enable much more flexible composition of methods that work with different exception types, bringing some of the flexibility of Rust's Result<T, E> to Java's existing exception system.
3. Better support for exception handling in functional contexts
Unlike Rust which requires the ? operator for error propagation, Java already automatically propagates checked exceptions when declared in the method signature. What Java needs instead is better support for checked exceptions in functional contexts:
// Current approach for handling exceptions in streams
List<String> contents = filePaths.stream()
.map(path -> {
try {
return Files.readString(Path.of(path));
} catch (IOException e) {
throw new RuntimeException(e); // Lose type information
}
})
.collect(Collectors.toList());
// Hypothetical improved API
List<String> contents = filePaths.stream()
.mapThrowing(path -> Files.readString(Path.of(path))) // Preserves checked exception
.onException(IOException.class, e -> logError(e))
.collect(Collectors.toList());4. Integration with Optional<T> and Stream<T> APIs
The standard library could be enhanced to better support operations that might throw checked exceptions:
// Hypothetical API
Optional<String> content = Optional.ofThrowable(() -> Files.readString(Path.of("file.txt")));
content.ifPresentOrElse(
this::processContent,
exception -> log.error("Failed to read file", exception)
);Comparison with Other Languages' Approaches
It's worth examining how other languages have addressed the error handling problem:
Rust's Result<T, E> and ? operator
Rust's approach using Result<T, E> and the ? operator shows how propagation can be made concise while keeping the type safety benefits. The ? operator automatically unwraps a successful result or returns the error to the caller, making propagation more elegant.
However, Rust's approach requires explicit propagation at each step, which can be more verbose than Java's automatic propagation in certain scenarios.
Kotlin's Approach
Kotlin made all exceptions unchecked but provides functional constructs like runCatching that bring back some type safety in a more modern way:
val result = runCatching {
Files.readString(Path.of("file.txt"))
}
result.fold(
onSuccess = { content -> processContent(content) },
onFailure = { exception -> log.error("Failed to read file", exception) }
)This approach works well with Kotlin's functional programming paradigm but lacks compile-time enforcement.
Scala's Try[T], Either[A, B], and Effect Systems
Scala offers Try[T], Either[A, B], and various effect systems that encode errors in the type system while integrating well with functional programming:
import scala.util.Try
val fileContent: Try[String] = Try {
Source.fromFile("file.txt").mkString
}
fileContent match {
case Success(content) => processContent(content)
case Failure(exception) => log.error("Failed to read file", exception)
}This approach preserves type safety while fitting well with Scala's functional paradigm.
Conclusion
Java's checked exceptions were a pioneering attempt to bring type safety to error handling. While the implementation has shortcomings, the core concept aligns with modern type-safe approaches to error handling in languages like Rust and Haskell.
Copying Rust's Result<T, E> might seem like the obvious solution, but it would represent a radical departure from Java's established paradigms. Instead, targeted enhancements to the existing checked exceptions system—like allowing lambdas to declare exceptions and supporting generic exception types—could preserve Java's unique approach while addressing its practical limitations.
The beauty of such improvements is that they'd maintain backward compatibility while making checked exceptions work seamlessly with modern Java features like lambdas and streams. They would acknowledge that the core concept of checked exceptions was sound—the problem was in the implementation details and their interaction with newer language features.
So rather than abandoning checked exceptions entirely, perhaps we should recognize them as a forward-thinking feature that was implemented before its time. As Java continues to evolve, we have an opportunity to refine this system rather than replace it.
In the meantime, next time you're tempted to disparage checked exceptions, remember: they're not just an annoying Java quirk—they're an early attempt at the same type safety paradigm that newer languages now implement with much celebration.
What do you think? Could these improvements make checked exceptions viable for modern Java development? Or is it too late to salvage this controversial feature? I'm interested in hearing your thoughts in the comments.
@hongminhee洪 民憙 (Hong Minhee) Totally agreed. The main problem with the original incarnation of Java's checked exceptions was that it was quite verbose and didn't give an easy way to compress a set of error types (because there is no typedef or such in Java). Zig-style syntax could be easily adapted to checked exceptions for the reasonable convenience.
C++ 표준화 위원회(WG21)에게 C++의 원 저자인 비야네 스트롭스트룹Bjarne Stroustrup이 보낸 메일이 이번 달 초에 본인에 의해 공개된 모양이다. C++가 요즘 안전하지 않은 언어라고 열심히 얻어 맞고 있는 게 싫은지 프로파일(P3081)이라고 하는 언어 부분집합을 정의하려고 했는데, 프로파일이 다루는 문제들이 아주 쉬운 것부터 연구가 필요한 것까지 한데 뒤섞여 있어 구현이 매우 까다롭기에 해당 제안이 적절하지 않음을 올해 초에 가멸차게 까는 글(P3586)이 올라 오자 거기에 대한 응답으로 작성된 것으로 보인다. 더 레지스터의 표현을 빌면 "(본지가 아는 한) 스트롭스트룹이 이 정도로 강조해서 말하는 건 2018년 이래 처음"이라나.
여론은 당연히 호의적이지 않은데, 기술적인 반론이 대부분인 P3586과는 달리 해당 메일은 원래 공개 목적이 아니었음을 감안해도 기술적인 얘기는 쏙 빼 놓고 프로파일이 "코드를 안 고치고도 안전성을 가져 갈 수 있다"는 허황된 주장에 기반해 그러니까 프로파일을 당장 집어 넣어야 한다고 주장하고 있으니 그럴 만도 하다. 스트롭스트룹이 그렇게 이름을 언급하지 않으려고 했던 러스트를 굳이 들지 않아도, 애당초 (이 또한 계속 부정하고 싶겠지만) C++의 주요 장점 중 하나였던 강력한 C 호환성이 곧 메모리 안전성의 가장 큰 적이기 때문에 프로파일이 아니라 프로파일 할아버지가 와도 안전성을 진짜로 확보하려면 코드 수정이 필수적이고, 프로파일이 그 문제를 해결한다고 주장하는 건 눈 가리고 아웅이라는 것을 이제는 충분히 많은 사람들이 깨닫지 않았는가. 스트롭스트룹이 허황된 주장을 계속 반복하는 한 C++는 안전해질 기회가 없을 듯 하다.
@yurume유루메 Yurume 역시 WebHID 같은 걸 구현 안 하는 Firefox가 잘한 거군요(?).
@hongminhee洪 民憙 (Hong Minhee) 근데 나름 편리하긴 하더라고요. 이게 단순 웹앱이 아니라 조금 더 사용자 주의를 요하도록 패키징이 되었다면 괜찮지 않았을까 싶습니다만... 사실 제가 이걸 알아 본 가장 큰 이유는 웹앱이 사라져도 설정이 가능하도록 백업이 가능한지 알아 보려는 게 컸네요.
최근에 오랫동안 쓰던 키보드가 망가져서 큰 맘 먹고 프리플로우 Archon M1 PRO MAX를 질렀는데, 요즘 키보드는 다 WebHID 가지고 웹 드라이버로 설정하는 것 같다. 자바스크립트니까 뜯기 쉽겠거니 싶어서 살펴 봤는데 커스텀 HID 레포트를 보낼 수 있는 기능을 사용해서 명령들을 나열해 놓았고, 개중에는 롬을 통으로 날리는 것도 가감없이 노출되어 있길래 음 역시 WebHID 같은 건 웹에 넣을 기능이 못된다는 결론을 내렸다. 가볍게 함수 목록만 요약해서 https://gist.github.com/lifthrasiir/c79c90ecf697b1e6dc73e83f32984499에 올렸다.
참고로 키보드는 이렇게 생겼다. 게이밍 키보드 아니랄까 조명이 정말 밝아서 설정으로 크게 광량을 줄여야 했다.
※ @hongminhee洪 民憙 (Hong Minhee) 님 초대로 들어 왔습니다. 블루스카이와 어느 쪽을 차별하지 않고 병행해서 쓸 예정이며 이 글처럼 두 쪽 모두에 같은 내용이 올라갈 가능성이 높습니다.
최근에 오랫동안 쓰던 키보드가 망가져서 큰 맘 먹고 프리플로우 Archon M1 PRO MAX를 질렀는데, 요즘 키보드는 다 WebHID 가지고 웹 드라이버로 설정하는 것 같다. 자바스크립트니까 뜯기 쉽겠거니 싶어서 살펴 봤는데 커스텀 HID 레포트를 보낼 수 있는 기능을 사용해서 명령들을 나열해 놓았고, 개중에는 롬을 통으로 날리는 것도 가감없이 노출되어 있길래 음 역시 WebHID 같은 건 웹에 넣을 기능이 못된다는 결론을 내렸다. 가볍게 함수 목록만 요약해서 https://gist.github.com/lifthrasiir/c79c90ecf697b1e6dc73e83f32984499에 올렸다.