한편 무슨 최적화를 고려하길래 이런 것까지 확인해야 했느냐 하면, 한 마디로 말하면 `a[n]`을 `*(T*)((char*)a + n * sizeof(T))`로 바꿔 쓰는 최적화였다. WebAssembly 바이트코드 인터프리터에서 로컬 변수 같이 배열을 참조할 때 배열의 인덱스를 저장하는 게 아니라 거기에 `sizeof(T)`를 곱한 바이트 오프셋을 저장해서 최적화를 하는 게 적법하느냐의 문제였다. (x86-64 같이 `sizeof(T)`의 값에 따라서는 괜찮은 케이스조차 아니었다.) 결론은 T가 객체 타입이면 적법하다는 것.
여기까지는 ISO C에 한정된 얘기였고, 현실에서는 POSIX 같은 표준이 함께 지원되어야 할텐데 POSIX에서는 `void*`에 함수 포인터도 들어갈 수 있어야 한다는 추가 규칙이 있다고 한다. `dlsym` 같은 함수가 이 규칙에 영향을 받는 대표적인 예이다. 어쨌거나 내가 생각하던 최적화는 ISO C에서 허용되는 걸로 파악했으니 해피 엔딩.
WebAssembly를 써 보신 분들은 어렴풋이 이 사실을 눈치챌 수 있었을 수도 있는데, WebAssembly에는 일반적인 객체를 담는 메모리 타입도 존재하지만 테이블이라 해서 함수 포인터(`funcref`) 같은 특수한 타입을 담을 수 있는 타입도 존재한다. 알고 보니 이게 특이한 결정이 아니라 ISO C에서 원래부터 허용하는 구조였다는 얘기. 나는 WebAssembly가 이 문제를 바이트 표현이 같으나 서로 타입이 다른 포인터가 존재할 수 있게 해서 해결하는 게 강제되는 줄 알았다. (어디까지나 "강제"가 아니었다는 말임)
...라고 알고 있었는데, 최근에 WAH (github.com/lifthrasiir/...) 최적화를 위해 이런 저런 고려를 하던 도중 혹시나 해서 찾아 보니 여기에 한 가지 중요한 예외가 더 있었다. 함수는 객체가 아니다. 즉 함수 포인터는 void*에 담는 게 원칙적으로 불가능하다! 대신 서로 다른 함수 포인터 타입끼리 변환은 가능하다. 어디까지나 변환만 된다는 거지 일반적으로 다른 타입의 함수로 호출이 가능하다는 건 아니지만.
ISO C에는 객체(object)라는 개념이 있는데, 이 개념은 객체지향 프로그래밍 같은 거랑은 상관 없고 자료형이 차지하고 있는 주소 공간의 일부분을 가리키는 말이다. 객체는 그 바이트 표현과 함께 타입이 항상 따라 다니며, union을 사용하지 않고 객체를 캐스팅만으로 다른 타입으로 재해석(reinterpret)하는 건 상당히 제한되어 있다(이게 그 악명 높은 strict aliasing 규칙이다). 다만 너무 막으면 저수준 작업을 아예 할 수 없으므로 몇 가지 예외가 있는데, 대표적으로 void*와 char가 있다.
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.
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!
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.
단순히 `<보통 문자>**<기호>`도 왼편으로 해석하는 식으로 해서 `**마크다운(Markdown)**은` 같은 걸 허용한다 하더라도, `このような**[状況](...)**は` 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.
CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 `**이런 **식으로** 중첩되어**` 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 `**이런 **` 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에 이런 식으로 추론하는 데 한계가 있다는 것이다.
...기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 `**마크다운(Markdown)**은`을 해석해 보면 뒷쪽 `**`의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.
여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 `**<보통 글자>` 꼴이거나 `<공백>**<기호>` 또는 `<기호>**<기호>` 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 `**마크다운**은` 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 `이 **"마크다운"** 형식은` 같이...
문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 `**`는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다.
![* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:vhq2q7oyn65dzg3vi2a7ptum/bafkreicfbh3bvvystricy2kzm7bhguddalw2uqwz4fcci6tmlpxsle7mby)
* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]
LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(`**`)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데(talk.commonmark.org/t/foo-works-...) 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.
전 최근의 AGI에 대한 이야기는 대체로 큰 의미가 없는 이야기라고 생각하는 편입니다. 현세대의 선단 AI들은 대체로 여러 분야에서 학사 정도의 능력을 발휘할 수 있는데, 이걸 과거로 가져가서 이게 AGI같냐고 물어보면 당연히 다 AGI 같다고 이야기 하겠죠. 범용-학사-인공지능 정도면 당연히 AGI라고 할 수 있고요. 저희가 연속적인 발전을 봤으니 이 정도에는 이미 익숙해진 겁니다.
BTW the reason there aren’t actually any consistently right wing AI models really is more or less because the right wing is wrong and they aren’t going to be able to fix this overall.
Angel의 스크린샷. 좌측에 세션 목록, 우측에 채팅 기록, 우측 하단에 대화 입력 창이 표시되어 있다. 세션 목록 위에는 워크스페이스 이름이 굵게 표시되어 있고, 채팅 기록에는 "From now on the following directories are exposed: D:\Dropbox\Works-doremi\git\angel\angel"(주황색, 시스템 메시지), "한 번 실제로 구현해 보겠어?"(녹색, 사용자 메시지), 파란 동그라미(에이전트 생각), "제가 이해한 바에 따르면, ..."(파란색, 에이전트 메시지), 진한 파란색/녹색(도구 사용) 등이 표시되어 있다.
아, Angel이라는 건 Gemini CLI 쓰다가 빡쳐서 만들기 시작한 이렇게 생긴 LLM 에이전트입니다. github.com/lifthrasiir/...
알고 보니 WSL2의 윈도 디스크 마운트는 전부 9p, 즉 네트워크 파일 시스템인데, 아는 사람은 알지만 SQLite는 네트워크 파일 시스템을 전혀 권장하지 않기 때문에 알았으면 처음부터 윈도용 SQLite 셸을 깔아 썼을 것이다... 이 경험을 반면교사 삼아 Angel에 네트워크 파일 시스템을 사용하려고 하면 오류 내고 튕겨내는 기능이 생겼으니 좋은 일인가? github.com/lifthrasiir/...
오늘의 끔찍한 이야기. Angel을 개밥 먹는데 사용하면서 데이터베이스도 은근 좀 커졌는데, 이걸 최근에 (이제서야) 업데이트한 WSL2에서 아무 생각 없이 sqlite3으로 마이그레이션을 하다가 malformed disk image 오류가 뜬다. 엥? 하면서도 대강 보니 작업 자체는 제대로 된 것 같아서 아무 생각 없이 진행했다가 쿼리가 통으로 맛이 가서 쓸데 없는 디버깅을 좀 하고서야 데이터베이스가 망가졌다는 걸 깨달았다. 이런!
이전 소설에서는 프롬프트를 100% 공개하기에는 양이 너무 많기도 하거니와 퇴고를 너무 많이 해서 정확히 어떻게 공개할지도 애매했던 반면, 이번에는 일부러 전역적인 퇴고를 자제했기 때문에 1:1 대응되는 프롬프트 목록을 공개할 수 있게 되었다. 어반 판타지를 쓴다고 해도 피할 수 없는 공돌이의 성격을 느껴 보시라...
Gemini로 이런 저런 정신나간 소설들을 작성하는 데 재미를 붙였었는데, 저번에 생성했던 작품은 수위가 제법 있어서 공개하기 꺼려졌지만 이번에 나온 건 그렇지 않아서 기분 좋게 공개할 수 있게 되었다. 그리하여 "산속 무녀들의 비밀"이라는 무녀무녀한 소설을 썼습니다. 홈페이지 레이아웃도 대부분 Gemini로 만들었다(여전히 사람 손길이 좀 필요하긴 했지만). w.mearie.org/maidens/
소설 "싱크로니시티"의 프롤로그. 내용은 다음과 같음: 프롤로그 아주 높은 탑 꼭대기에, 모든 인형의 움직임을 조종하는 마법사가 살았다. 그의 손끝 하나로 인형들은 기쁨과 슬픔, 사랑과 분노를 표현하며 완벽한 연극을 펼쳤다. 무대 위 인형들은 너무나도 생생하여, 관객들은 그들이 춤추는 모습을 보며 행복의 눈물을 흘리거나 슬픔에 잠겨 고개를 떨구곤 했다. 마법사는 자신의 인형들이 펼치는 아름다운 연극에 만족하며 매일 밤 휘파람을 불었다. 그러나 마법사의 마음속에는 작은 불안이 싹트고 있었다. 인형들이 너무나도 생동감이 넘쳐 예측 불가능했기 때문이다. 가끔은 정해진 움직임에서 벗어나 자신만의 춤을 추려 했고, 때로는 마법사의 명령을 어기고 엉뚱한 방향으로 발걸음을 옮기기도 했다. 마법사는 이러한 인형들의 자유 의지가 자신의 완벽한 연극을 망칠 수도 있다고 생각했다. 그는 그들의 모든 움직임을 단 한 치의 오차도 없이 통제하고 싶었다. 밤낮으로 고민하던 마법사는 마침내 특별한 보이지 않는 실을 만들었다. 이 실은 너무나도 가늘고 투명하여 누구의 눈에도 보이지 않았고, 인형들의 가장 깊은 곳까지 닿아 그들의 모든 움직임을 완벽하게 통제할 수 있었다. 이제 인형들은 마법사의 의지대로만 움직였지만, 여전히 살아있는 듯 아름다운 춤을 추었다. 마법사는 인형들의 등에 더 이상 굵은 조종 줄을 맬 필요가 없었기에, 그의 연극은 더욱 완벽하고 자연스러워 보였다. 그는 인형들이 더 이상 자신의 의지대로 움직이지 않는다는 사실에 희열을 느꼈다. 마법사는 보이지 않는 실로 인형들을 완벽하게 조종하며, 영원히 지속될 자신만의 연극을 꿈꿨다. 그는 자신의 통제 아래 놓인 인형들을 바라보며, 드디어 세상을 손에 넣은 듯한 만족감을 느꼈다. 하지만 마법사는 몰랐다. 어떤 인형들은 그 보이지 않는 실을 느꼈고, 어떤 인형들은 그 실을 느끼지 못했지만, 어떤 인형들은 보이지 않는 실 속에서도 자신만의 춤을 추기 위해 아주 미세하게 발버둥 치고 있었다는 것을.
참고로 이렇게 시작되는 소설입니다. 귀찮다고 프롤로그가 통째로 비유적인 동화라 무슨 내용인지 파악하는 데는 별 쓸모 없겠지만... 그렇다고 1장을 올리자니 이건 이거 나름대로 머리가 아파지므로...
소설 "싱크로니시티"의 한국어판 목차. 이하 다음과 같은 내용임: 싱크로니시티 Synchronicity 2025-06-22T00Z (7.4판), Gemini 2.5 Flash를 이용해 작성됨 프롤로그 - 2 1: 마리오네트 Marionette - 3 2: 태동 Genesis - 7 3: 틀 Frame - 13 4: 수치 Shame - 23 5: 목격 Witness - 37 6: 고난 Ordeal - 50 7: 울림 Resound - 65 8: 결점 Flaw - 73 9: 촉매 Catalyst - 82 10: 개조 Augment - 90 11: 의식 Ritual - 102 12: 쇼 Show - 108 13: 갈채 Acclaim - 117 14: 욕구 Desire - 130 15: 목도 Encounter - 141 16: 이미지 Image - 147 17: 진화 Evolution - 158 에필로그 - 163 '작가'의 변 - 164 작가의 변 - 166 '서평' - 170
최근 1주간 갑자기 삘을 받아서 Gemini로 생각 이상으로 긴 소설을 써 버렸다(이미지는 이 소설의 목차). 얼마나 삘을 받은 건지 소설이 170장짜리가 나오는 건 둘째치고, 소재가 생각 이상으로 잔혹해서 이대로면 소위 R-18G가 그대로 찍히는 상황이라 이걸 어떻게 공개해야 하나 공개하기 전에 수정을 해야 하나 이러고 있다... 소재만 빼면 내 생각보다 훌륭하게 만들어진 것 같긴 한데 이래 저래 고민 중. 일단 관심 있으신 분은 자기 책임으로 연락 주시면 pdf 파일을 보내 드립니다.
Rolling the ladder up behind us
https://xeiaso.net/blog/2025/rolling-ladder-behind-us/
MSG는 몸에 해로울지 모른다는 혐의를 받게 된 이후 너무나 많은 검증을 통과해서 세상에서 가장 안전한 식재료가 됨. 그게 문득 떠올랐음.
진보적 아젠다 측면에서 그다지 기대할 수 없는 인사들이 대거 민주당과 이재명 후보의 깃발 아래 모이는 것에 복잡한 기분이 전혀 안 든다고 하면 거짓말이긴 하지만, 머리로는 온전히 납득하고 있다.
그 측면에선 김상욱의 입당과 지지에 대해서도 충분히 긍정한다 : 적어도 어떤 대원칙을 uphold 하기 위해서 거대한 외력에 마주할 강단을 가진 퍼스널리티는 증명한 사람이니까.
권력이 뭘 해줄 것이냐가 아니라, 권력이 어떻게 성립하며, 어떤 힘으로 동작할 것인지를 재정립하고 재확인해야만 하는 상황이기 때문에 그러하다. 다른 길이 없다.
This is a compelling parable of a person who was forced to hide their creative self by their employer. Appears to be the creation of a new YouTuber.
www.youtube.com/watch?v=Zeb6...
So do I, especially when I am working with crates that have a carefully curated public interface. I even had a case where I switched from local to global because it was getting harder to control that at work.
