오늘 흥미로운 걸 발견하는 운이 좋은 모양이네요. HN에서 보았는데, 결과물보다는 코멘트 첫머리에 링크된 블로그포스팅이 더 재미있었습니다.

글 초반의 어떤 문구에서 저는 부정적인 인상을 받았는데, HN에서 본 다음 코멘트를 읽고 조금 완화되었습니다.

I mean this pretty literally though - I'm not particularly interested in these questions. They've been discussed a ton by people way more qualified to discuss them, but I personally I feel like it's been pretty much the same conversation on loop for the last 5 years...

That's not to say they're not very important issues! They are, and I think it's reasonable to have strong opinions here because they cut to the core of how people exist in the world. I was a musician for my entire 20s - trust me that I deeply understand the precarity of art in the age of the internet, and I can deeply sympathize with people dealing with precarity in the age of AI.

But I also think it's worth being excited about the birth of a fundamentally new way of interacting with computers, and for me, at this phase in my life, that's what I want to write and think about.

CPU 버그 이야기가 나오니 생각나는 것. 대강 20년 못되는 시간 전에, 베타 서비스 중 원인을 찾느라 고생했던 크래쉬가 있었다. 당시에 나는 C# 으로 로그 분석을 하던 수준의 기획이었는지라 옆에서 구경하는 처지였지만. 허락을 구하고 유저의 집에 직접 찾아가 직접 디버깅을 해봐서 원인을 알게 되었었다. 특정 CPU 에서만 발생하는 시간 체크 관련 하드웨어 버그가 있었는데, 이게 플레이 타임이 길어졌을 때 오차가 누적되어서 시간 동기화 문제를 일으켰던 것. 지금도 강렬한 기억이다.

플라스틱은 썩지 않아! 라는 생각으로 프라모델을 가득 사가지고 있다가 공간을 줄이기 위해 박스에서 런너봉투들을 꺼내서 직사광선에 노출시키는 바람에 바사삭 부서져버렸던 기억이 나는 부분.

CPU 안의 회로도 시간이 지나면 열화된다는 언급.

아아...

예전에는 CPU 버그가 드물었지만, 최근에는 복잡성의 증가로 많이 흔해졌다는 이야기로 시작하는 CPU 버그에 대한 좋은 마스토돈 포스팅. 버그가 어떤 식으로 발생하고 여기에 어떤 식으로 준비/대처하는지에 대해 자세히 이야기를 해준다. 습관적으로 마스토돈에 들어갔다가 상당히 흥미롭고 깊이있는 이야기를 발견해서 기뻤다. 주소는 여기

예전에 lwn.net 에서 본 What every programmer should know about memory가 생각났다. Static RAM 과 Dynamic RAM 의 속도차이는 왜 어떻게 발생하는 것일까에 대해 아주 오랫동안 궁금해하던 것을, 회로도를 통해서 직관적으로 이해할 수 있게 해줘서 굉장히 (...인생에서 가장 기뻤던 순간 중 손에 꼽을 정도였다.) 기뻤던 기억이 아직도 난다.

로우레벨 컴퓨팅에 대한 이야기는 내 정신 저 밑바닥에 있는 "아니 그러니까 왜냐고?!" 의 욕망을 크게 해결해주는 경향이 있어서 좋아한다.

그리고 마스토돈의 기본 웹 클라이언트는 브라우저들이 번역을 정말 잘 못한다-_-; 웹페이지의 기본 언어가 브라우저 언어로 맞추어져 보여지고, 그래서 번역할 필요가 없다고 브라우저가 판단해서 그런 것 같다고 이해하고 있는데 이 문제 어떻게 해결할 방법이 없을까 흠 ' -' ...

HN에서 Claude's new constitution 이야기를 봤고, 몇 차례 타이틀만 보고 눌러보지 않고 지나가다가- 결국 눌러서 나온 댓글들에서 끔찍한 감정을 느끼다가 - 블로그 글을 읽기 시작하다가 - '읽어보세요' 버튼을 눌러서 본문을 보게 되었습니다. 본문 보기 버튼을 눌러보길 잘 했다는 생각이 들었습니다. 학술적/윤리적/철학적 호기심을 많이 자극하는 글이었고, 꽤 공을 들였다는 느낌을 받았습니다.

다 읽고 나니까, 아주 오래전, 구글이 'Don't be evil'을 말했던 때가 생각나기도 했습니다.

세계가 전면 핵전쟁 주위를 어슬렁거리고 있어서 요 며칠 우울했는데, 이걸 보니 좀 기분전환이 되더군요.

차별금지법안이 제안됨과 동시에 격렬한 반대 메시지가 쌓이고 있네요.

부디 열화와 같은 성원으로 찬성해주시기 부탁드립니다

https://pal.assembly.go.kr/napal/lgsltpa/lgsltpaOpn/list.do?menuNo=&lgsltPaId=PRC_O2N5O1M1M1V9T1T1S0S9R5R9Z1A1Y3&searchConClosed=0&refererDiv=S

직교. 애증의 존재.

해커스펍 팔로 추천 탭에서 팔로우를 할 때면, 마스토돈에서도 핸들을 입력해 팔로우하고 한국어사용자유저 목록에 추가하는 것을 해오다가

클로드에게 파이어폭스 Greasemonkey 를 통해 자동화하는 자바스크립트를 만들어달라고 했는데

여러 번 시행착오를 해서 한 시간 걸려서 되게 했습니다.

간단한 작업이어서 더 빨리... 아니 한 번 만에 될 거라고 생각했어요.

유튜브 요새 좀 게으르네요. 이걸 이제사 띄워주다니-_-

12월 14일에 올라왔었군요. 오늘에서야 봤습니다.

"엄밀히 말하면, 나는 신해철의 확률입니다."

Ghoststation: the Next - 마왕의 귀환

억양이 원래 것에 조금만 더 가까웠다면 좋았을텐데 아쉽다... 라는 기분이었습니다. 하지만 반가운 목소리라 살짝 울컥하기도 했네요.

골치아프면서 흥미로운 논문을 봤어요 Distributional AGI Safety

"개체들로 구성된 '구조', 즉 개체와 개체 사이의 공간의 집합은 의도 혹은 악의를 가질 수 있는가?" 혹은 "'시스템'은 의지를 가지는 것이 가능한가?" 같은 질문이 머리 안에서 지나가네요.

여전히 LLM 을 (느슨하게나마) AI라고 부르고 있는 것엔 못마땅하다는 감정이 들지만요. 모순적일지도.

• hugo 로 만든 블로그에서,
• 동일 페이지 안에서, 주석이나 챕터같은 링크들을 오갈 때,
• 웹브라우저의 이전 내비게이션을 하면 이전 스크롤 위치로 안돌아가는 문제가 있었는데
• 사이트의 헤더와 푸터 때문에 스크롤 위치를 브라우저가 제대로 인식을 못하기 때문이었다는 걸 클로드 덕에 알게 되었고 (분명 맨 처음엔 영문법 물어보는 걸로 시작했었는데 어쩌다가...)
• 이걸 브라우저의 History API 에 저장해놨다 사용하는 자바스크립트를 사용해보길 권장하길래
• 이런 데 자바스크립트를 쓰는 건 과잉 아니겠느냐고 따졌더니
• GitHub, Notion, Discord 같은 대형사이트에서도 그렇게 해요! 라고 반박하며 설득하길래 (리터럴리 인용: "이건 "과한 JavaScript"가 아니라 "필요한 JavaScript"입니다.")
• 설득에 넘어가서 적용했는데
• 뭔가 진 기분이 들면서도 재미있었어요.
• 언리얼 엔진으로 작업할 때도 이렇게 애가 능숙하면 얼마나 좋을까-_-
• 하지만 이렇게 느끼는 건 제가 웹에 능숙하지 못해서이고, 웹도 복잡한 케이스로 가면 "이 정도 수준이면 심각한 업무에는 걱정도 되고 효율도 별로니까 안쓸래 투덜투덜" 할지도 모르겠다는 생각이 들었어요.

@analoggreenMTG AI이미지들이라는 확신이 들게 만드는 일관적인 느낌이 있더군요:) 하지만 진짜로 믿는 사람이 0명일 것이라고 생각하진 않습니다(...)

@analoggreenMTG 사이트의 다른 것들도 주욱 봤습니다. 황홀하군요!

레딧을 노닐다 이런 걸 봤어요.

Browser extensions are becoming a huge security headache

아... 저는 여러 어플리케이션들에서 이런저런 확장을 활발하게 사용하는 편인데, 보안 관리자 시점에서 이걸 생각해본 적은 없다는 걸 깨달았습니다.

그리고 '내가 보안 책임자면 어떻게 했을까'를 상상해보니까... 대강 생각해봐도 악몽이군요 O>-<

마스토돈에서 멘션을 받아 알게된 것

https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/

싫은 기억은 곧잘 잊는 편입니다. 분명 예전에 찾아봤던 기억이 나는데, 자세한 건 기억이 나질 않아 다시 찾아봤습니다.

한 동안 괴로워했습니다. 분명 과거의 저도 짧지 않은 시간 동안 괴로워했을 거라고 생각했어요.

StackOverflow: Elegant solution to duplicate, const and non-const, getters? [duplicate]

아아아아 괴로워요 O>-<

예전 혜화 전화국 사고 때도 그렇고, 국가 기간 시설들에 대한 사고시 예비 수단을 마련하는 게 좋지 않을까 라고 생각하면 좀 배부른 소리일까 같은 생각이 나서 잠깐 위키피디아에서 관련 항목들을 찾아 읽어보는 중입니다.

• Fail-safe
• Redundancy (engineering)
• Fault tolerance

I saw this now.

Pebble is officially Pebble again - theverge.com

https://www.theverge.com/news/713931/pebble-smartwatch-name-trademark-recovered

#pebble

U+237B NOT CHECKMARK :: Rethinking CLI interfaces for AI

이런 데서 Bulk Rename Utility 스크린샷을 볼 줄은 몰랐습니다. 저는 저 프로그램 없이는 못 살아요.

요즘 이런 생각을 종종합니다.

"윤리는 안보의 문제다. 철학은 생존의 문제다."

어제 이런 것들을 읽었습니다. 인상적이었어요.

• "사고의 사슬 모니터링: AI 안전을 위한 새롭고 취약한 기회"
• "사고의 사슬이 필요할 때, 언어 모델은 평가자를 회피하기 위해 고군분투한다."
• "Claude Sonnet 3.7은 (종종) 정렬 평가에 언제 들어가는지 알고 있다."

마스토돈에서 제 경우, 새로 팔로우할 사람이나 새 정보를 접하는데엔 해시태그에 대한 팔로우를 더 많이 사용하는 편이에요.

생각해보니 여기선 해시태그를 한 번도 써본 적이 없네요 추천 알고리즘을 좋아하지 않는게 #fediverse 의 분위기다 보니, 서로 관심사를 공유하는데엔 해시태그가 주로 사용되고 있습니다.

2025년 7월 6일. 남의 c++ 코드를 감사히 가져다 쓰다가 new 와 delete 의 개수가 맞지 않는 것을 발견했습니다.(비명)

놀라서 malloc과 calloc 도 뒤져보고 있어요.

사실 그 코드와 관련된 논문에서 그림이 사소하게 틀린 것도 발견했는데 아직 메일을 귀찮아서 쓰지 않고 있어요.

평범한 어부가 만든 엄청난 변화, 사천 바다가 달라지고 있다(링크: https://v.daum.net/v/20250630114200933) 트위터를 통해 읽게된 기사인데, 많은 울림을 준다.

김정판씨의 걱정은 자신의 죽방렴에만 머물지 않고 늘 바다 전체를 향했다. -> 하는 일에서 조금 더 큰 시각을 가지는 자세의 중요성 "사람이 성을 내면, 생각이 멈춘다 아입니까? 하지만 왜 그럴까, 어떻게 하면 될까, 계속 스스로에게 질문을 던지면서 관찰하다 보면 보이지 않던 게 어느 순간 보이기 시작합니다. 결국은 답을 꼭 찾습니다." -> 시니컬한 자세는 똑똑해 보일 수 있지만, 진짜 똑똑한 사람은 질문을 던지고 답을 찾는다. "사람 머리가 똑똑해도 연필 끝보다 못하다"고 말하는 김정판씨는, 시간이 지나면 변질되는 '기억'보다는 '기록'의 힘을 믿었다. -> 기록하면서 왜곡이 안생기게 자기 피드백 루프를 만듦. 김정판씨에겐 '몰입'의 시간이었지만, 누군가에겐 '집착'으로만 보이던 세월이 있었다. 다행히 그 시간은 과거가 되었다. 생업, 관찰, 기록, 어느 하나 소홀히 하지 않고, 달빛과 물때와 한 몸이 되어 돌아가는 일상을 성실히 살아낸 그였기에 가능했다. -> 편집광?? 근면성실함의 가치는 바뀌지 않았다. 알면서 실천하지 않는 게 문제다.문제가 있는데도 '소극적으로 방치'하는 건 '적극적 은폐'와 다를 바 없지 않냐고 '받는' 것과 '물려받는' 것은 다르다. 같은 맥락에서 주는 것과 물려주는 것 역시 다르다. 물려주고 물려받는 행위에는 '책임'이 따른다. 물려받을 때는 거기에 담긴 뜻을 잘 새기며 써야 하고, 물려줄 때는 훼손된 부분이 있는지 잘 살핀 후 복원해서 주는 것이 도리다. -> 우리의 미션을 이어받을 후임자에게 잘 물려주어야 한다.

@bglbgl gwyng 기능면에서 대단히 훌륭합니다. 한동안 잘 썼었어요. 다만 다소 무거운 감이 있어서 저는 순정으로 돌아왔습니다 ㅡㅠ.

@evenharder이하 너무 날것이라 저도 본 직후엔 충격이었어요. 근데 곰곰이 생각해보니 마지막 방법이 정신적으론 편하겠더라구요:) 부탁해 컴파일러!

로딩과 병렬처리와 UI가 만나는 곳에서 일어난 이런저런 사단을 겪은 뒤,

FSM 을 만들어야 이후 발생할 끔찍한 일들을 막겠다 싶어서 검색을 해보니까

c++에서는 std::variant 가 최신 유행이야! 라는 말이 제일 많이 나왔습니다만, 영-_- 마음에 안들어서

가장 간단한 switch 문으로 하다가 모든 일이 그렇듯이 이걸로 감당이 안되겠다 싶어서 더 뒤지다 보니까...

#UnrealEngine 엔 TVariant라는 아이가 있더군요. (지금 쓰는 게 언리얼인지라) 하지만 그래도 마음에 안들어서 더 뒤지다보니까...

Finite State Machines (FSM) in Embedded Systems (Part 3) - Unuglify C++ FSM with DSL
이런 흑마술도 나오더군요 하지만 역시 마음에 안들어서 더 뒤지다보니까...

Oh my...

Tech Breakdown: AI with Finite State Machines

/* shorthand macro */
#define FSM_ID( SID, EID ) ( uint64(STATE_##SID) | (uint64(EVENT_STATE_##EID) << 32) )

uint32 SomeEnemy::HandleEvent( const FSMEvent& Event ) override
{
	switch( Event.MakeSwitch(State) )
	{
	case FSM_ID( STANDING_STILL, ENTER ):
	{
		/* code for entering the standing-still state */
		break;
	}
...
	}
}

상태 enum 을 비트시프트한 다음 합쳐서 switch 문의 case로 쓰고 있는 끔찍한 짓을 하고 있더군요' -'

근데 이게 마음에 들더라구요(퍼엉) 이걸로 하려구요.

Maybe Jack Tramiel was no Steve Jobs. He was older and more single-minded. He never really saw past his idea of selling computers “to the masses, not the classes."
- A history of the Amiga, part 10: The downfall of Commodore in Series:History of the Amiga

"계급이 아닌 대중에게" 라는 말은 느낌이 좋네요. 이야기 자체는 슬픈 엔딩으로 끝나긴 하지만.

근데 시리즈 페이지(와 주소)가 있었다는 걸 이제 알았어요.

앞으로 Ars Technica 에 자주 가게 될 것 같네요. 어제까지는 그냥 "나와 비슷한 관점으로 이야기하곤 하는 웹진"이었는데요.

이야. 여기 컴퓨팅 역사 맛집이었어요.

Bill Atkinson, architect of the Mac’s graphical soul, dies at 74 를 통하여 30-plus years of HyperCard, the missing link to the Web를 알게 되었고, 위키피디아에서 HyperCard 항목을 읽었습니다. 하이퍼링크와 웹의 역사에 관해 이것저것 읽으면서 Project Xanadu 같은 것은 들어본 적이 있었지만, HyperCard 에 대해서는 오늘 처음 알게되었습니다. 기쁘네요.

역사는 사물의 본질에 대하여 여러 각도로 이해할 수 있는 수단이라 많이 좋아합니다:)

Arstechnica 에서 이런 글을 보았습니다.

A history of the Internet, part 2: The high-tech gold rush begins

제가 이것저것의 역사에 대하여 흥미가 많다는 말을 여기에 쓴 적이 있던가요? 게임이라거나 컴퓨팅이라거나 ...

사실 대강의 사연을 알고있던 저 2편보다는, 제가 모르던 사연이 더 많은 1편 An Ars Technica history of the Internet, part 1이 더욱 흥미로웠습니다.

그 와중에 글을 쓰는 방식과 디테일들이 마음에 들어서 글쓴사람을 클릭해보니 와우' -' 보물창고가 쨘 하고 나타나는 것이었습니다.

일단 처음에 눈에 띄여서 이 시리즈를 읽었습니다. 재미있었어요.

• A history of ARM, part 1: Building the first chip
• A history of ARM, part 2: Everything starts to come together
• A history of ARM, part 3: Coming full circle

그래서 ARM의 원래 이름은 Acorn RISC Machine. 도토리 RISC 머신이었던 것입니다 ' -' ...

다음에는 Amiga 의 역사를 읽어볼 생각이에요. 두근두근.

@nyeongAn Nyeong (安寧) emacs 는 저에게 동경의 대상이지만 아직 게을러 시작하질 못하고 있어요' ▽ ' ...

고백하자면 이번이 처음이 아닙니다 털썩. 역시 한 번 했던 실수는 다른 어딘가에서 반복되는군요.

3일 동안 원인을 알 수 없었던 오동작의 원인을 찾았습니다.

비동기 관련 부분은 생각해야 하는 것이 많고 까다롭네요 역시.

다시는 람다식에 셰어드포인터 캡쳐하지 않겠습니다

그래서 기뻐해야 하는 타이밍인데, 뉴스를 보고 있자니 기쁜 마음을 가지기는 힘드네요. 흑. 긍정적으로 생각하자면 순식간에 핵전면전으로 번지지는 않았으니 다행이긴 한데요.

@linea 축하드려요>_</

@hongminhee洪 民憙 (Hong Minhee) @linea 참고로 저 학부시절이라고 쓴 때는 1999년인가 2000년인가 그럴 거에요. 교수님이 "나중에는 웹에서 3D 로 된 쇼핑몰을 돌아다니며 쇼핑을 할지도 몰라요" 같은 이야길 했었죠' -' ...

@linea @hongminhee洪 民憙 (Hong Minhee) 학부시절 VRML의 존재에 대해 수업중에 알게 되고 "이 사람들 제정신인가 웹에서 이런 걸?" 같은 생각을 하던 저였습니다만, 요즘 저는 모바일 웹브라우저에서 최신 그래픽의 게임이 돌아가는 세상을 상상하곤 합니다 ㄲㄲㄲ 아니 뭐 스트리밍을 쓰면 지금도 되긴 하겠지만(...)

@linea @hongminhee洪 民憙 (Hong Minhee)

그 결과, 2015년 3월에 열린 Game Developers Conference, GDC의 기간 중에, Google이나 Mozilla 등의 개발자가 모여, 당시는 WebAsm이라고 불리고 있던 것에 대해 논의해, 웹의 새로운 언어를 표준화하기 위해, 계획은 점점 구체적으로 되어 갔다.

후년, 2015년 4월 1일의 구글과 모질라 사이의 메일로부터 WebAssembly라는 이름을 언급한 것으로 보이는 최초의 메일이 발견되어, 이 시기에 명확해졌다고 생각된다.

Mozilla의 흑마술부와 Google의 흑마술부가 손을 잡고, 나중에 MS의 흑마술부가 합류 ' ㄱ' ... GDC에서 작당모의를 했다는 건 저도 오늘 처음 알았는데요, 꽤 시사적인 부분이라고 생각해요. 성능을 쥐어짜내는 역할은 많은 경우 게임이죠 ㄱ-;

@hongminhee洪 民憙 (Hong Minhee) 올려주신 걸 보고 "검색..." 이란 단어가 생각났고, 바로 그 때 사이트 상단의 "검색" UI를 인지했습니다:D!

@hongminhee洪 民憙 (Hong Minhee) 공개와 조용히 공개의 차이가 궁금합니다 :D

@linea 몇 년 전에 이거 소식을 처음 들었을 때는, "서로 다른 회사들의 사내 동아리들이 연합해서 사이드 프로젝트 비슷한 분위기로 뭔가 해봤는데 반응들이 굉장해!" 같은 분위기였던 걸로 기억해요.

완벽하게 이해했다는 자신이 없는 상태에서 남의 코드의 변수명들을 수정하면서 이해해가고 있는 와중에
__pragma(optimize("",off))로 최적화를 끄라고 했는데도 디버거가 로컬 변수의 값을 괴상하게 보여줘서
뭔가 이해가 부족한 상황에서 잘못 수정한 게 아닌가 깜짝 놀랐습니다만

개발 빌드가 아니라 디버그 빌드로 하니까 제대로 보여서 안심했다는 사연입니다.

그리고 오늘 명확히 알게 된 것

최적화 프로그램은 로컬 변수를 제거하거나 디버거가 이해할 수 없는 위치로 옮길 수 있습니다.
- https://learn.microsoft.com 최적화된 코드 디버그

하지만 지금까지 cpp 파일에선 이런 깜짝쇼를 본 적이 없는 것 같은데 말이죠 - _ - 헤더에서 일어난 일이라 그런 걸까요... 템플릿도 아니었는데 음-_-;

라이브러리를 좀 대국적으로 만드십시오!!!

이탤릭이 적용되어서 | 이 삐딱하게 들어간 것이 거슬리지만 일단 내비두는 것으로... 아니.. 폰트를 고치면 되긴 하는데... 으으윽...(참고 있어요)

' -' 이제 좀 알 것 같아요.

오늘의 교훈: 남의 코드에 손을 대게 되는 것이 숙명일 것 같다면, 버전관리솔루션과 IDE의 리팩토링 기능을 믿고 과감하게 지르자. 이름을 고치면서 학습되는 효과가 생각보다 크다. 아니 그 전에 직관적으로 디버깅을 할 수 없는 환경이면 내 호두만한 두뇌의 버퍼로는 일을 할 수가 없다!

제 코드가 아닙니다. 이것 관련해서 디버깅해보면서 조사해봐야 하는 이것 의 코드에요. 이대로는 도저히 못하겠어서 인간친화적인... 디버깅이 쉬운... 타입으로 바꿔서 돌려보려고 생각중이에요.

아아아 O>-<

으아아아 도망가고싶다아아아