Kang Seonghoon

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)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]

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/...

angel/src/fs/network_windows.go at main · lifthrasiir/angel Experimental LLM agent based on gemini-cli. Contribute to lifthrasiir/angel development by creating an account on GitHub.

알고 보니 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는 몸에 해로울지 모른다는 혐의를 받게 된 이후 너무나 많은 검증을 통과해서 세상에서 가장 안전한 식재료가 됨. 그게 문득 떠올랐음.

WinDirStat Windows Directory Statistics

혹시 WinDirStat windirstat.net 같은 거랑은 차이가 큰가요?

진보적 아젠다 측면에서 그다지 기대할 수 없는 인사들이 대거 민주당과 이재명 후보의 깃발 아래 모이는 것에 복잡한 기분이 전혀 안 든다고 하면 거짓말이긴 하지만, 머리로는 온전히 납득하고 있다.

그 측면에선 김상욱의 입당과 지지에 대해서도 충분히 긍정한다 : 적어도 어떤 대원칙을 uphold 하기 위해서 거대한 외력에 마주할 강단을 가진 퍼스널리티는 증명한 사람이니까.

권력이 뭘 해줄 것이냐가 아니라, 권력이 어떻게 성립하며, 어떤 힘으로 동작할 것인지를 재정립하고 재확인해야만 하는 상황이기 때문에 그러하다. 다른 길이 없다.

my teacher was a youtuber YouTube video by nobody

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.

대부분은 그 정도의 기억이 불가능하기 때문에 여럿이 같이 짜는 코드라면 최저치에 맞춰서 파일이나 함수 길이를 줄일 필요가 있다고 하는 것이다. 당연히 그런 상황이 아니라 혼자 짜는 코드라면 자기가 감당할 수 있을 정도까지 길이를 늘려도 문제가 없는 것이고. 지나친 도그마를 부정하는 것도 중요하지만 도그마가 생긴 진짜 이유를 파악해서 취사 선택하는 것이 더 중요한 이유.

해커뉴스에서 Fabrice Bellard의 QuickJS가 한 파일에 5만줄 집어 넣고 한 함수가 몇백 몇천줄 되는 걸 보고서 파일 및 함수 길이를 강력하게 제한하는 도그마가 항상 옳은 것은 아니다, 라는 코멘트를 보았는데 이는 반만 맞는 말이다. 나도 대부분의 개발자보다 파일이나 함수 길이에 훨씬 관대한 (그리고 이 사실을 한참 뒤에야 깨달은) 사람이라 아는 건데, 그냥 Bellard가 5만줄 전체의 맥락을 전부 기억하고 있고 해당 코드를 거의 Bellard만 건들고 있기 때문에 추가적으로 모듈화할 필요가 없는 것일 뿐이다.

개인적으로는 판결문을 듣고 있는 시간 자체가 상당히 힐링효과가 있었다. 민주적 정통성이 부여한 권위 있는 기관의 언어로 말해주는 상식적인 말들에 너무 큰 안심감과 위로를 받는다.

ChatGPT 4o 로 만든 지브리풍 그림 유행의 가장 큰 위협은 지브리 흉내가 넘쳐나는거나(원래도 많았다), 저작권 침해가 (재산권은 스타일이 아니라 개별 저작물에 있으며, 그 저작물을 써서 학습한 것에 대한 비용은 냈어야 하며, 전체 틀은 OpenAI 회사 상대로 상업적 2차 창작에 준하여 다뤄야 한다) 아니라고 생각하는 편.

그보다는, 캐릭터 그림체 느낌 말고는 대놓고 퀄 떨어지는 결과물에 대해 지브리랑 거의 같다!라고 감탄하시는 많은 분들을 통해 드러나는, 문화예술에 별로 완성도를 요구하지 않는 시대상.

…솔직히 허황된 주장에 기반해 그러니까 프로파일을 당장 집어 넣어야 한다고 주장하고 있으니 그럴 만도 하다. 일부러 러스트 얘기를 안 꺼내는 건 둘째 치고, 애당초 (이 또한 계속 부정하고 싶겠지만) C++의 주요 장점 중 하나였던 강력한 C 호환성이 곧 메모리 안전성의 가장 큰 적이기 때문에 뭘 해도 안전성을 진짜 확보하려면 코드 수정이 필수적이고, 프로파일이 그걸 해결한다고 주장하는 건 눈 가리고 아웅이라는 것을 이제는 충분히 많이 인지하지 않는가. 스트롭스트룹이 이런 주장을 반복하는 한 C++는 안전해질 기회가 없을 듯 하다.