도구 사용 결과에 대해서는 의심스러움

긴 내용을 LLM에 왕복으로 통과시키면 손상되는 건 놀랍지 않음. LLM을 자주 쓰는 사람들은 이미 그렇게 하면 안 된다는 걸 알고 있음

논문에서는 도구 사용이 도움이 안 됐다고 해서 놀랐는데, 동시에 “기본적인 에이전트 하네스”를 구현했고 최신식으로 최적화된 시스템은 아니라고 밝힘

실제 하네스는 read_file()과 write_file()뿐이라, 그냥 왕복 처리에 한 단계가 추가된 것에 가까움. 요즘 코딩 에이전트 하네스는 파일 편집 도구 설계에 많은 공을 들이고, 예를 들어 Claude 편집 도구 묶음이 있음: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

str_replace와 insert 명령은 전체 파일을 다시 쓰는 위험한 편집을 피하는 데 핵심임

최소한 run_python() 도구는 제공하므로, 더 나은 모델들은 이를 이용해 문자열 치환을 실행했을 가능성은 있음. 시스템 프롬프트가 Python 기반 조작을 권장했는지, 아니면 파일을 읽고 다시 쓰도록 유도했는지 보고 싶음

하네스 코드는 여기서 찾음: https://github.com/microsoft/delegate52/blob/main/model_agen...

관련 프롬프트 조각은 “프로그래밍 방식이든 직접 파일을 쓰는 방식이든 가장 효과적이라고 생각하는 방식으로 접근할 수 있다”는 내용임

이런 논문들이 흔히 그렇듯, 결과는 모델 자체보다 논문 저자들이 사용한 하네스 설계를 더 많이 반영함. 경험 있는 AI 엔지니어든 프롬프트 엔지니어든, 하네스 자체를 반복 개선하면 이 테스트에서 더 나은 결과를 낼 수 있다고 봄

• 대부분 동의하지만 “LLM을 자주 쓰는 사람들은 이미 그렇게 하면 안 된다는 걸 알고 있다”는 부분은 예외임

  지금 조직과 팀 전반에 LLM 도입이 밀려오는 상황에서, 매일 LLM을 쓰지만 하네스처럼 기술적인 것에는 접근해 본 적도 없는 사람이 많고, 어쩌면 다수일 수도 있음

  그런 사람들에게 여기서 말하는 동작은 큰 문제임

• 약간 관련된 얘기지만, ed를 기본 파일 편집/읽기 도구로 쓰는 하네스를 보고 싶음. Claude가 실행하는 bash의 절반은 어차피 sed처럼 보이는데, ed에 상태가 유지되면 도움이 될 것 같음

  전체 편집기가 너무 많은 대역폭^H 토큰을 먹을 때는 어떻게 해야 하나? 표준 편집기인 ed를 쓰면 됨

• 이건 LLM 작업을 약간 허수아비로 만든 사례에 가까움

  편집 작업에서는 프로그래밍 방식의 편집 명령만 허용해야 하고, 텍스트가 LLM을 통과하면 안 됨. LLM은 텍스트를 분석하고, 피드백에 따라 목표를 달성할 명령을 내보내야 함

• HN에서는 결과를 가능한 한 부정적으로 해석하려는 경향이 있음. 자기 직업과 정체성에 대한 위협으로 느끼기 때문임

  사실 문서를 읽은 뒤 수정 사항을 반영해 문서 전체를 다시 말하게 하는 방식으로 편집하려면, 사람은 25% 열화보다 더 나쁜 결과를 낼 수 있음. 사람이 0% 열화를 달성하는 것도 가능하긴 하지만, 그 상태는 문서를 수백 번 입력받아 암기해야 가능함. LLM에서 이에 해당하는 건 학습이고, 문서를 LLM에 학습시키면 이 경우 암기한 사람의 편집과 동등해질 수 있음

  하지만 위 내용은 핵심이 아님. LLM은 사람과 비슷한 점이 있으므로, 사람이 문서를 편집하는 방식처럼 LLM도 검색과 외과적 수정으로 편집하도록 하네스를 설계해야 함. 모든 코딩 에이전트는 그렇게 편집하므로, 이 논문은 별로 관련성이 없음

• 자원 제약 때문이든 단순화를 위해서든, 이해하기 어려운 방법론 때문에 이런 논문들은 안타깝게도 가치가 떨어짐

예전부터 말해 왔듯이, 어떤 텍스트든 AI로 덧칠하면 품질이 떨어지고, 반복할수록 누적됨

이걸 부르는 말로는 “의미 절제(semantic ablation)”가 제일 마음에 듦: https://www.theregister.com/software/2026/02/16/semantic-abl...

• 나는 이걸 평균 지능으로의 회귀라고 불러 왔음
• “반복할수록”이라는 게 같은 세션 안에서 반복한다는 뜻인지, 매번 새 세션이나 새 문맥 창에서 한다는 뜻인지 궁금함

“위임에는 신뢰가 필요하다. LLM이 문서에 오류를 넣지 않고 작업을 충실히 수행할 것이라는 기대가 있어야 한다”는 요지인데, 이게 바로 수십 개의 Markdown 파일을 쓰는 하네스와 프롬프트 의식이 광고처럼 작동하지 않는 이유임. 사실상 에이전트 엔지니어링이라는 이름의 사이비에 가까움

에이전트 엔지니어링도 결국 소위 프롬프트 엔지니어링과 거의 같고, 다만 프롬프트가 이제 수십 개의 Markdown 파일과 디렉터리에 흩어져 있을 뿐임

최근 LLM 관련해서 읽은 것 중 가장 덜 놀라운 내용임

LLM은 JPEG 밈과 비슷함. JPEG로 저장할 때마다 품질이 조금씩 떨어져 마지막에는 알아볼 수 없게 되는 것처럼 작동함

다만 LLM에서 시작점은 의도임. LLM을 한 번 통과할 때마다 의도가 열화되고, 정밀한 과학 논문 같은 경우에는 다시 표현하는 과정에서 미묘한 뉘앙스와 정밀도가 조금씩 사라짐

LLM은 평균으로 회귀하는 기계임. 현재 다루는 문맥이나 작업 부하가 학습 범위에서 벗어날수록, 그것을 점점 더 균질한 추상적 평형 상태로 끌어당기려는 경향이 커짐

• LLM으로 코딩하면서 확실히 겪어 봄. 기능 작업을 빠르게 몰아서 하고 나서는 꽤 조심했다고 생각했는데, 나중에 작은 코드 조각을 자세히 보면 “맙소사” 싶은 순간이 자주 있음

  그 뒤 몇 시간을 들여 전체를 다시 훑고, 원하는 대로 되지 않은 부분, 내가 불명확했던 부분, LLM의 이상한 습성이 발동한 부분을 신중히 고쳐야 함

  코드 품질 자체도 중요하지만, 정확히 이런 반복 압축 문제가 걱정됨. 코드베이스가 깨끗하고 머릿속 모델이 최신이면 LLM이 기능 작업을 빠르게 도와주고도 코드베이스를 괜찮은 상태로 남길 수 있음. 하지만 LLM이 코드베이스를 더럽히기 시작하면 과거의 실수나 오해가 누적되고, 점점 더 많은 것을 틀릴 가능성이 커짐. 그래서 LLM을 다시 쓰기 전에 올바른 상태로 “복원”해야 안심됨

• 이 결과가 실제로 흥미롭고 관련 있는 경우는 코딩 에이전트가 큰 소스 파일을 여러 작은 파일로 쪼갤 때임. Opus와 Claude Code는 사람이 하듯 복사/붙여넣기 같은 조작을 쓰는 대신, 긴 소스 코드 구간을 기억에서 암송해 새 파일들에 넣으려 함

  파일 이동은 조금 쉬움. LLM이 가끔 파일을 기억에서 다시 말하려 하기도 하지만, git mv를 쓰고 컴파일러 오류를 고치라고 하면 대체로 잘함

  반면 일반적인 편집은 합리적인 모델과 도구 구성이 있으면 보통 잘 작동함. Qwen3.6 27B도 이 정도는 괜찮음. 제자리 수정은 git diff로 예상 밖 변경을 검토할 수도 있음

• 이걸 보여주는 어린이 놀이도 있음: https://en.wikipedia.org/wiki/Telephone_game

• 동료는 LLM을 “헛소리 층”이라고 표현함. 완전히 깎아내리는 뜻은 아니고, 무언가를 LLM에 통과시킬 때마다 반대편에서 나오는 결과가 기대하거나 원하는 것과 다를 수 있다는 점을 강조하는 말임

  술집에서 몇 잔 마신 사람이 어디서 봤다는 온라인 정보를 전해 주는 것과 비슷함. 맞을 수도 있지만, 아닐 위험도 꽤 큼

  예를 들어 API를 호출해 데이터를 모으고 보고서를 만들 때 LLM을 쓰지 말아야 함. 결정적인 데이터를 헛소리 층에 통과시키는 셈이라 결과를 신뢰할 수 없기 때문임. 대신 LLM은 결정적인 데이터에서 결정적인 출력을 만드는 코드를 작성하는 데 쓰는 편이 나음

  동료들이 API에서 온 결정적인 데이터를 LLM으로 요약하게 했다가, 보고서가 맞을 때만큼이나 크게 빗나가는 것도 봤음. 무엇을 보고 있느냐에 따라 재앙적인 위험이 될 수 있음

• 이력서 편집에서 이걸 겪음. LLM은 내 이력서를 평균적인 경험을 가진 주니어 엔지니어 더미와 구분해 주는 모든 요소를 제거함. 특별하거나 독특하거나 다른 것들은 결국 전부 일반적인 문구로 대체됨

  물론 그 결과물을 쓰지는 않았지만, LLM이 계속 이게 기존 것보다 낫다고 우기는 게 정말 답답했음

  LLM은 이력서 전체의 방향을 잡는 것보다, 아주 작은 덩어리, 예를 들어 한 문장이나 세 문장 정도의 수정 제안을 받을 때 훨씬 유용했음

문제는 우리가 LLM에게 너무 많은 일을 시킨다는 데 있음. 에이전트는 LLM을 자연어 의도를 결정적 과정으로 번역하는 가능한 한 얇은 층으로 쓰도록 설계해야 하고, LLM 왕복을 최대한 줄여야 함

• 조금만 복잡한 일을 해 보려는 사람이라면 이게 분명해짐. 전처리 흐름, 의미 기반 대상 지정, 최소한의 문맥 호출을 LLM API와 결합하는 파이프라인을 만들면 강력한 자동화 단계를 얻을 수 있음

  별도의 검증 단계와 결합하면 LLM은 장난감에서 유용한 도구로 바뀜

• 사람도 요정도 반복 과정에 들어 있지 않아야 비로소 자동화된 과정임

보통 에이전트에게 문서 작성은 마지막 렌더링 단계로만 다루라고 지시함. LLM은 흩어진 지식을 모아 엮는 데 매우 능숙하므로, 지식은 조합 가능한 아이디어와 사실 형태로 저장하는 편을 선호함

실제로 잘 먹힌 방식은 에이전트에게 디렉터리를 주고, 찾아낸 사실이나 발견마다 독립적인 Markdown 파일을 만들라고 하는 것임. 각 파일에는 검색하기 쉽게 앞부분 메타데이터를 넣게 함

이렇게 하면 대부분의 작업이 “최종 문서 형식으로 조사와 저장을 반복”하는 뒤엉킨 형태에서, “문서에 도움이 될 사실과 발견을 조사”하고 “문서를 조립”하는 더 응집된 작업으로 분리됨

완전한 해결책은 아니지만, 사람이 작업할 때처럼 발견물의 재사용성이 더 좋아짐

이건 사람에게도 적용되지 않나? 아이들이 “전화 놀이”를 하면서 메시지가 어떻게 손상되는지 보는 이유도 그 때문임. 해결책은 단일 진실 공급원을 제공하는 것임

이런 종류의 열화와 싸우기 위한 도구를 만들고 있음: https://github.com/JigSpec/JigSpec

여기 평가 방법은 정말 마음에 들었음. 가역적인 단계들의 사슬을 왕복시키면서 충실도를 테스트하는 방식임

겉보기에는 컴퓨터가 다루기 쉬워 보이는 작업에서도 최전선 모델들이 오류를 누적한다는 점이 인상적이었음

Python에서 더 강한 결과가 나온 것이 Python 특화 평가의 산물일 뿐인지, 다른 흔한 범용 언어에도 이어지는지, 그리고 학습 과정의 특정 요소 때문인지 궁금함

모델이 수많은 작은 오류, 즉 “천 번의 베임” 때문에 실패하는 게 아니라는 점은 이미 대체로 알고 있었음. 어떤 라운드에서는 거의 완벽하게 재구성하다가, 몇몇 라운드에서 한 번에 10~30점 이상 잃는 치명적 실패를 겪음

약한 모델의 열화는 주로 내용 삭제에서 오고, 최전선 모델의 열화는 내용 손상에서 온다는 점도 마찬가지임. 그래서 우리가 하네스, 온도 같은 것들을 이리저리 만지는 것임

사람들이 잊었을까 봐 말하면, 중국이 웹사이트 운영 전에 등록 허가를 요구하기 시작했을 때도 명분은 아이들 보호였음
이 단순한 정책은 결국 개인 발행자와 자영 미디어 대부분을 침묵시키고, 산업을 소수 손에 집중시켰으며, 작은 창업자에게 남은 기회를 없앴음. 아이들이 온라인 포르노를 보는 것보다 훨씬 나쁜 결과일 수 있음. 사람들의 평생에 부정적 영향을 주기 때문임
EU가 정말 VPN 서비스를 성인 전용으로 제한하고 싶다면, VPN을 쓰는 아이나 이를 허용한 부모에게 벌금을 물리면 됨. 교통 위반은 도로가 아니라 운전자에게 벌금을 매기는 것과 같음
그래도 충분하지 않다고 생각한다면, 북한처럼 케이블을 끊으면 됨

• 러시아에서 일이 어떻게 진행됐는지 요약하면 이렇다
  2015년쯤 불법 복제 미디어, 특히 torrents.ru를 막는다는 명분으로 법적 틀이 만들어졌고, 전국 단위 DNS 차단이 도입됐지만 8.8.8.8을 질의하면 쉽게 우회 가능했음
  이후 정부는 그 법적 근거로 카지노, 테러 조직 등 추가 항목을 차단 목록에 넣었고 IP 차단도 조심스럽게 적용하기 시작함
  법은 더 넓어져 정부가 모호한 기준으로 특정 미디어를 차단할 수 있게 됐고, 대형 사이트 일부에 IP 차단을 시도했으며, ISP에는 HTTPS SNI 기준 필터링을 위한 DPI 장비 설치가 의무화됨
  2019년쯤 법원 명령 없이 차단을 집행하는 정부 기관 Roskomnadzor(RKN)가 만들어졌고, 2021년쯤에는 RKN 요청에 따라 러시아 법 기준으로 콘텐츠를 필터링하지 않는 사이트가 차단되기 시작했으며, VPN 서비스도 DPI로 트래픽을 필터링해야 했음
  2023년쯤 VPN 단속이 시작돼 인기 상용 서비스가 IP 차단되고 OpenVPN과 IPSec 연결이 DPI로 선택적으로 느려졌으며, 2025년쯤에는 vless, WireGuard 등 강한 VPN 필터링이 도입되고 YouTube, Twitter 같은 특정 사이트 성능도 저하됨
• 정치인, 법 집행기관, 군인까지 이런 반프라이버시 법의 적용을 똑같이 받는다면 찬성하고 싶음. 물론 진짜 찬성은 아님
  야당이 그들의 더러운 자료를 폭로해서 일상적 부패가 드러나고, 서로 그 데이터를 무기로 쓰는 일이 반복되겠지만 그런 세상은 오지 않음. 법이 모두에게 공정하게 적용되는 세계에 살고 있지 않기 때문임
  “너희에게만 규칙, 나에게는 아님”이라는 얘기임
• 너무 논리적인 질문을 하고 있음. 2026년의 세계 시민치고는 너무 많이 생각하고 말하는 중임. 이제 “추론”은 챗봇 전용 예약어라 인간은 더 이상 하면 안 되고, 봇처럼 복종하면서 그들이 말하는 모든 거짓말을 진실인 척해야 함
  나는 튀르키예에 사는데, 정부가 2008년쯤 모든 성인 사이트를 금지했음. 성인이라도 접근할 수 없음. 올해는 전 세계 흐름과 맞춰 VPN을 금지하고, 연령 확인과 신원 확인을 도입하고 있음
  일부 게임도 금지하고, 소셜 미디어를 통제하고, 인터넷에서 모두를 통제하고 추적하는 일을 합법화하는 중임. 여러 독립 국가에서 비슷한 시도가 동시에 벌어지는 게 참 우연임
  그리고 튀르키예에서 2008년 이후 아이들이 실제로 보호된 것도 아님
• “아이들을 보호하자”는 논리는 항상 들림. 규제나 법에 반대하는 사람을 좋게 봐도 “아이들을 위험에 노출시키는 사람”, 나쁘게 보면 “소아성애자”로 낙인찍을 수 있기 때문임
  그 결과 그런 규제나 법의 반대자는 좋게 봐도 들을 가치가 없는 사람이 되고, 나쁘게 보면 감옥에 보내야 할 사람이 됨
  https://en.wikipedia.org/wiki/Think_of_the_children
• 중국의 웹사이트 등록 허가제가 “아이들 보호” 명분이었다는 건 기억나지 않고, 공개적으로 그런 정당화가 크게 있었다는 근거도 찾기 어려움
  내가 보기엔 정부가 인터넷에 대한 통제를 더 필요로 한다고 판단했고, 그래서 통제를 더 주는 법을 만든 것에 가까움. https://www.gov.cn/gongbao/content/2000/content_60531.htm
  그 법에는 처음엔 아이들에게만 한정됐다가 나중에 성인으로 확대된 특별 조항도 없음. 한편 아이들의 게임 시간 제한은 내가 알기로 여전히 아이들에게만 적용됨

이 제목은 오해를 부르는 것 같음
유럽의회 문서는 VPN에 관한 논쟁의 존재를 짚는 것으로 보임
관련 문구는 “일부는 이것이 법의 허점이며 VPN에도 연령 확인을 요구해야 한다고 주장한다. 이에 대해 일부 VPN 제공업체는 제3자와 정보를 공유하지 않으며, 애초에 자사 서비스가 아이들의 사용을 의도한 것이 아니라고 말한다. 영국 아동위원은 VPN을 성인 사용으로만 제한해야 한다고 요구했다”는 식임
물론 EU가 VPN을 규제하지 않을 거라고 말하는 건 아니지만, 이 문서 어디에도 “EU”가 VPN을 닫아야 한다고 말하진 않음

• 이런 멍청한 사람들은, EU만 말하는 건 아니고, 진지하게 청소년의 포르노 시청을 막으려 하며 그걸 위해 인터넷 인프라를 망가뜨릴 준비가 돼 있음. 고령화 사회의 우울한 징후임
• 그 제목은 해당 문서 장의 정확한 제목이기도 함
  전체적으로는 주제를 균형 있게 다루고 있다는 지적은 맞지만, 그 특정 문장 선택은 좋지 않았고 분노 기계에 먹잇감을 주는 표현이 됐음
  https://www.europarl.europa.eu/RegData/etudes/ATAG/2026/7826...
• 아이들에게 벌거벗은 인간을 보여주는 건 끔찍한 범죄임
  아이들을 폭격하는 건 괜찮고, 거기에 필요한 모든 무기를 기쁘게 생산하고 배송함
  병든 사회의 패턴임
• “Children's Commissioner for England”는 EU가 아님. 정말 EU가 아님. 영국은 선거와 수년간의 절차를 거쳐 EU를 떠났음
• 새로운 “헤드라인의 법칙”이 필요함. EU가 뭔가 말했다고 제목에 나오면, 실제로는 EU가 말한 게 아님

모든 신원 확인 제도는 회사의 실소유자부터 시작해야 한다고 봄
정부는 의심스러운 일을 하는 사업체를 소유한 부자들이 완전한 익명성을 유지하도록 로비를 받아 왔고, 보통 사람들은 식료품을 사는 데도 신분증을 보여줘야 하는 쪽으로 가고 있음

• 맞음. 더 나쁘게는, 아무도 정부를 프라이버시 보존형 연령 확인 쪽으로 밀어붙이려 하지 않음
  대신 기술자들은 그냥 아무것도 규제하지 말라고 설득하려 하는데, 그게 잘 먹히지 않을 수 있음
• 그런 공개를 요구하는 관할권에 사는 입장에서 말하면, 이는 소기업에는 상당한 불편이고 일반 대중에게는 별 이득이 없음
• 지배 계급에게는 페이퍼컴퍼니, 농민에게는 계속 줄어드는 익명성임

VPN을 정말 막고 싶어 하는 쪽은 상업 스트리밍 업체들, 특히 실시간 스포츠 쪽임
국가나 집권당과 상관없이 결국 돈으로 돌아옴

• 이 부분은 더 강조될 필요가 있음
  정부만의 문제가 아님. 돈을 가진 일부 대기업도 조용히 밀고 있음

세금 허점은 왜 그만큼 감시받지 않는 걸까
온라인 의무 연령 확인은 내 생각엔 해악이고, 불법화돼야 함

• 동의함. 웹에서의 연령 확인은 100% 금지돼야 함
  부모는 부모 역할을 배워야 하고, 정부가 기업에 양육을 대신 강제해서는 안 됨
• 세금 “허점”은 그냥 네가 동의하지 않는 의도된 정책일 뿐임
• 감시받지 않는다고 생각하는 이유가 뭔가? 특히 Double Irish Dutch Sandwich는 단속됐음
• 왜 그렇게 생각함? 운전면허를 갱신할 때나 Amazon에서 뭔가 살 때도 나이 확인이 되지 않나?
  내가 어릴 때는 아동 프로그램과 광고가 엄격하게 감시됐음. 지금은 어떤 아이든 인터넷에서 포르노, 폭력, 사기에 접근할 수 있음. 해악은 연령 확인이 아니라 그쪽임
• 세금 허점을 어떻게 정의할 수 있나? “세금 허점”이라는 이름의 단일 행위가 있는 게 아니라, 각각은 완전히 합법적인 관행들의 묶음을 최적화로 쓰는 것이라 정의하기 어렵고, 따라서 감시하기도 어려움
  끝없는 두더지 잡기임

EU 정부 관계자가 이걸 읽고 있다면 짧게 전하고 싶음
제발 인터넷에서 아이들을 생각하는 걸 멈춰줬으면 함. 대신 더 긴급하게 해야 할 일은 이쪽임
대기업에 더 많은 세금을 걷고, 초부유층에도 더 과세하고, EU산 오픈소스 기술과 인프라에 자금을 대야 함
부모가 아이들과 더 많은 시간을 보내게 해서, 어떤 멍청한 법보다도 더 잘 자녀를 보호하고 포식자로부터 지킬 수 있게 해야 함
그리고 기차를 더 늘려야 함

계속 머릿속을 맴도는 질문이 있음
왜 연령 확인이 신원 확인과 연결되는 걸까?
전자가 후자 없이는 불가능한 이유는 이해하지만, 확인을 담당하는 기관이 다른 세부 정보 없이 연령 확인 결과만 넘기면 되는 것 아닌가?
내가 잘못 알고 있는 건가? 그게 가능하다면 VPN은 계속 쓸 수 있을 것 같음

• “이중 블라인드” 확인이 바로 그런 방식으로 보임
  보고서는 프랑스에서 쓰이는 이중 블라인드 확인 시스템 같은 새 접근을 강조함. 웹사이트는 사용자의 신원을 알지 못한 채 연령 요건 충족 여부만 받고, 확인 제공자는 사용자가 어느 웹사이트를 방문하는지 보지 못하는 방식임
• 적어도 EU처럼 자체 시스템을 강제하려 하고 독립적인 제3자에 의존하지 않으려는 경우라면, 정부가 연령 확인 앱을 통제하면서도 이를 존중할 것이라고 맹목적으로 믿어야 하는 문제임
• 기술 관점에서는 DID, 즉 분산 신원과 그 검증 가능한 증명으로 약 10년 전부터 해결된 문제임
  EU 디지털 지갑 프레임워크도 이를 기반으로 만들어졌고, 네가 말한 시나리오는 핵심 사용 사례임
  이제 학계와 연구 영역에서 정치 영역으로 넘어가고 있으며, 상업 집단과 정치적 의제의 피드백과 압력이 판을 흐리고 있음
  표준 문서 링크는 여기 있음. 더 짧고 쉽게 설명하는 고품질 영상도 쉽게 찾을 수 있음
  https://www.w3.org/TR/did-1.0/
  https://www.w3.org/TR/vc-data-model-2.0/
  참고로 이건 블록체인 시대의 건강한 부산물 중 하나이니, 암호화폐 홍보꾼들의 과장 영상에 휘둘리지 않는 게 좋음
• 맞음. 프라이버시를 보존하는 방식의 연령 확인은 가능함. 이 아이디어에 매우 강하게 반대하는 사람들 대부분은 그걸 모르는 것처럼 느껴짐
  여기서 보이는 불만 대부분은 연령 확인이 곧 추적이라고 가정함
  사람들이 불평하기 전에 조금만 알아봤다면, 프라이버시 보존형 연령 확인에 대한 흥미로운 논의가 가능했을 텐데 아쉬움

사람들은 소비자용 프라이버시 VPN만 보지만, EU 안에는 훨씬 넓은 상업용 VPN 사용 영역이 있음
두 지점을 하나의 네트워크로 잇는 지점 간 터널, 노트북과 모바일 기기에서 기업 자원에 접근하는 용도, 요즘 많은 사람이 강제로 쓰는 형편없는 인터넷의 일방향성을 보완하는 용도 등이 있음
기본적으로 원격근무를 조금이라도 한다면 지금 반드시 VPN을 쓰고 있다고 말하진 않겠지만, 가능성은 높음. 어쩌면 정치인 본인의 IT 백엔드도 행정부가 입법부를 과도하게 들여다보는 능력에 대해 나름의 생각이 있을 수 있음

정부는 이미 생년월일을 포함해 모두의 신분 정보를 갖고 있음. 문제는 미성년자가 성인 사이트와 서비스에 접근하는 것이라고 말하니, 사이트는 사용자가 18세 이상인지, 또는 정부가 정한 나이 이상인지 알면 됨
표준화된 정부 신원 서비스/API가 있어서 사용자가 요청하는 사이트나 서비스에 자신의 나이, 또는 선택한 정보만 공개하도록 허용할 수 있어야 함. 정부 신원 서비스가 적절한 2단계 인증과 보안을 갖췄다면 그게 필요한 전부임
요청과 응답은 적절히 익명화해 정부는 사이트를 모르고, 사이트는 개인의 신원을 모르게 만들 수 있음
왜 아직 이런 게 없을까? 내가 알기로는 아무도 제안하지 않았음

• 이건 널리 논의됐고 초기 구현도 있음. EU 디지털 지갑이 정확히 이 일을 하고 있음. https://ec.europa.eu/digital-building-blocks/sites/spaces/EU...
  이론상 모든 EU 국가는 곧 이를 지원해야 하고, 사용자는 온라인에서 나이를 사적으로 증명하는 데 쓸 수 있게 됨. 실제 배포까지는 아직 할 일이 남았지만, 기술적인 부분은 이미 진행 중이고 배포 계획도 확정된 것으로 봄
• 아님. 정부가 어떻게 작동하는지 이해하지 못하는 것 같음. 절대 익명화되지 않을 것이므로 끔찍한 아이디어임. 사실상 계정을 여권에 연결하자고 제안하는 셈임
• 독일 정부 신분증은 그걸 지원함. PKI가 있고 신분증은 인증서와 개인키가 들어 있는 스마트카드임 [0]
  “18세 이상인가”라는 질문에 영지식 증명으로 답할 수 있음. 결국 유효한 신분증을 소지하고 있고 그 PIN을 알고 있다는 것만 증명하는 셈이지만, 그 정도면 충분해 보임. 기사에 따르면 프랑스도 이 기능이 있음
  [0] https://www.personalausweisportal.de/Webs/PA/EN/government/t..., https://www.bsi.bund.de/EN/Themen/Oeffentliche-Verwaltung/El...
• 맞음. 예를 들어 프랑스에서는 그렇게 하고 있고, 일반적으로 EU에서 논의되는 방식도 그 방향임
• 맞음. 연령 확인을 진짜 중요하게 여기는 정부라면 그 도구를 제공해야 함. 프라이버시를 침해하지 않고도 할 수단이 있음
  네덜란드 DigiD 같은 서비스가 훌륭한 기반이 될 수 있음. 모두가 반대하는데도 미국에 팔려는 바로 그 서비스 말임. 거기에 연령 확인 서비스만 추가하면 됨. 정부는 이미 가장 법적인 의미에서 네가 누구인지 알고 있음

한때는 부모가 아이들이 접근할 수 있는 웹사이트를 통제했음
이제는 정치인이 우리가 접근할 수 있는 웹사이트를 통제하는 시대임

4일 전에도 이런 내용이 있었음: https://news.ycombinator.com/item?id=48019226
Bun 작업자가 자기 브랜치라며, 당시 스레드는 작동하지 않는 코드에 대한 과잉반응이고 아직 재작성에 확정한 적 없으며 코드가 전부 버려질 가능성이 높다고 했음
작동하는 버전이 어떤지, 성능과 유지보수성이 어떤지, Bun 테스트 스위트를 통과시키기 얼마나 어려운지 확인해서 Rust 버전과 Zig 버전을 나란히 비교하고 싶다고 했었음

• 그 메시지를 썼을 때 cargo check가 컴파일러 오류 16,000개 이상을 냈고, 버전 번호 출력도 JavaScript 실행도 못 했음
  이렇게 빨리 작동할 줄도, 성능이 이렇게 경쟁력 있을 줄도 몰랐고, 자세한 내용은 블로그 글로 나올 예정임
• 유지보수성, 성능, 테스트 스위트 검사를 해보고 결정을 내린 것 같음
• 그렇다면 지금까지는 실험으로서 매우 성공적이라는 뜻임
• 며칠 전에는 “오픈소스는 반대 방향으로 갈 것 같다. 인간 기여 금지. 슬롭은 2025~2026년의 향수 어린 유물이 될 것”이라고도 했음
  Anthropic에 인수된 뒤라 예상했어야 했지만 여전히 실망스럽다. 대규모 언어 모델 기술 자체에 반대하는 건 아니지만, 이런 “AI” 회사들이 소프트웨어 산업과 사회 전반을 먹어치우며 권력을 얻은 방식이 역겹고, 매우 건강하지 못한 의존성을 만들고 있음
  몇 수 앞을 내다보고 슬롭 없는 소프트웨어 스택과 커뮤니티를 준비해야 함. 여기에는 Zig와 그 생태계도 포함됨. 우리와 미래 세대가 슬롭 없이 완전히 살 수 없더라도, 자유로서의 자유를 갖춘 지속 가능한 컴퓨팅 문화를 보장하는 일이 어느 때보다 중요함

이렇게 빨리 해낸 건 매우 인상적임. 비슷하게 TypeScript를 Rust로 포팅하는 프로젝트를 5개월째 하고 있는데, Mythos와 무제한 토큰 접근권은 없음
그래도 거의 100% 통과율에 가까워졌고, 작성 시점에는 99.6%임: https://tsz.dev
Rust는 대규모 언어 모델로 코드를 작성하기에 아주 적합함. 엄격한 타입 시스템 덕분에 다른 언어라면 허용할 수 있는 아주 멍청한 실수를 덜 하게 됨
다만 대규모 언어 모델로 코드를 쓴다고 해서 프로젝트를 만들 때 필요한 설계 비전과 트레이드오프 판단이 사라지지는 않음. 그래서 Jarred와 팀은 대규모 언어 모델로 엄청난 양의 코드를 활용해 쓸 수 있는 적절한 사람들임

• Rust의 컴파일 시점 불변식 강제는 대규모 언어 모델이 빠른 피드백을 받아 되돌아갈 수 있게 하므로 동작하는 코드를 생성하는 데 도움이 됨
  반면 Rust는 복잡한 언어라 작은 변경이 멀리 떨어진 코드의 리팩터링을 강제하는 리팩터링 눈사태가 생기기 쉬움. 초기 아키텍처가 나쁘거나 부족하면, 대규모 언어 모델이 보통 하듯 점진적으로 코드베이스를 키울수록 스파게티화될 위험이 큼
  결국 컴파일되고 실행도 되지만 사람이 읽거나 유지보수할 수 없는 프로그램이 될까 걱정됨
• 비슷하게 멀티스레드 Postgres도 하고 있음. 1개월 만에 pg 회귀 테스트 96%를 통과했고 823K LOC까지 갔음
  Mythos 없이 월 $200짜리 Codex 계정 8개가 쓸 수 있는 전부였음
  Rust의 장점도 여기서 봤고, Postgres 경험을 바탕으로 사람들이 오랫동안 pg에서 어려워하던 여러 부분에 좋은 설계 결정을 내릴 수 있다고 보고 있음. AI 덕분에 과거에는 실용적이지 않았던 복잡한 소프트웨어 개선이 더 가능해지는 게 기대됨
  [0] https://github.com/malisper/pgrust
  [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
• Microsoft가 이를 Go로 다시 썼을 때, 리드 중 한 명이 Rust 대신 Go를 택한 이유로 패러다임 유사성을 들었음. 가비지 컬렉션 등이 비슷하고, Rust는 더 어렵고 많은 우회가 필요했을 거라고 했는데, 직접 해본 입장에서 어떤지 궁금함
• Rust는 훌륭하지만, 대규모 프로젝트에서 대규모 언어 모델과 함께 Rust 소프트웨어를 만들려 하면 원하는 방식이 무너짐
  깨끗한 경계를 유지하거나 세우는 일조차 몰입 상태가 아니라 고통스러운 리뷰가 되고, 결국 미루기 모드로 빠지게 됨
• Opus가 Rust 관용구를 무시하고 가능한 한 이상한 Rust를 쓰지 않게 만드는 데 애를 먹었음. 팁이 있는지 궁금함

근거가 강한 건 아니지만 더는 Bun과 엮이고 싶지 않음. 직감에 가깝지만 신뢰도 지지도 못 하겠음
LLM 재작성을 활용하려고 Zig를 포크하고, Zig 팀이 명백히 꺼린 비결정적 컴파일 같은 걸 만들었음
이제는 징징대듯 Rust로 LLM 재작성을 하고 있음. Zig의 설계 철학이 어려우면서도 정확한 결정을 강제했기 때문에 지금 위치까지 온 것일 수 있고, Rust 재작성이 몰락의 시작일 가능성도 실제로 있음
기술보다 정치에 가까운 판단이지만, Bun은 Claude에게 완전히 떠받들어지는 것처럼 보임. Anthropic의 다음 마케팅 문구가 “Claude Mythos가 선도적인 950K LOC JS 런타임을 Rust로 재작성”이어도 놀랍지 않음

• 자기 저장소에 코드를 쓰는 개발자가 징징대는 아기인지, Hacker News에서 그걸 불평하는 사람이 그런 건지 모르겠음
• Jarred가 징징댄 건 못 봤고, 감정이 잘못 향한 것 같음
  링크된 Twitter 스레드는 명확한 기술적 근거를 제시하고 있음
• Bun에 개인적으로 그렇게 몰입해 있지는 않지만, 이게 왜 중요한지 모르겠음. 다른 의존성들도 이렇게 검토하는지 궁금함
  JS/NPM 생태계에서 일한다는 건 이미 검증 안 된 의존성에 대한 순수한 믿음에 크게 의존하는 일이고, LLM 재작성 전후가 달라 보이지 않음. 원래 목표와 API 계약을 만족한다면 차이가 있나? 기존 소스 코드는 꼼꼼히 읽고 있었는지도 의문임
• 동의함. Bun은 처음부터 설계 철학이 분명했음. 런타임, 번들러, 테스트 스위트, 패키지 매니저까지 원하는 걸 전부 하고, 매주 깨지는 패치를 내는 식이었음
  매번 기존 경쟁자를 더 좋고 빠르고 강하게 압도한다는 식이었지만, Keep It Simple Stupid만은 절대 하지 않을 게 너무 뻔했음
  가까운 미래에 실제 운영 환경에서 보게 될 곳은 가속제를 뿌린 듯 하나씩 타버리는 YC 스타트업들뿐일 것도 분명했음. 이제는 되돌릴 수 없는 지점을 지난 듯함
• Bun은 사실상 죽었음
  Anthropic은 자기들의 “성능” 문제를 해결하려는 다소 멍청한 시도로 Bun을 샀음. 애초에 형편없는 코드가 문제였다는 걸 몰랐던 듯함
  그래도 실제로 유능한 개발자들을 데려왔으니 어느 정도 도움이 됐을 수는 있음
  하지만 그 과정에서 Bun은 공개 프로젝트에서 Anthropic 내부 도구에 가까워졌고, 지금은 AI 자금으로 과보호받으며 초점을 꽤 잃고 있음
  거품이 꺼질 때 Bun에 들어간 노력이라도 일부 건질 수 있기를 바람. Anthropic이 장기적으로 유지보수할 것 같지는 않음. 그들은 런타임 지원을 파는 사업을 하는 회사도 아니고, 옆에서 런타임을 유지할 만큼의 Google급 규모도 없음

AI 개입을 잠시 빼고 보면 좋은 변화라고 생각함
Bun은 Zig를 사용하면서 크래시와 메모리 버그가 극도로 많았고, Rust 기반인 Deno와 달랐음
물론 Bun의 Rust 포트에 unsafe가 많다면 마법처럼 전부 해결되지는 않겠지만, 그래도 나아질 것임

• Bun에 크래시와 메모리 버그가 극도로 많다는 통계나 출처가 있는지 궁금함. 틀렸다고 생각하는 건 아님
  보기 흉한 부분이 unsafe로 더 분명하게 보이니 리팩터링을 유도한다는 점은, 언어만의 문제가 아니라 Bun 자체가 어느 정도 자초한 면도 있어 보임
• Zig를 쓰면 “크래시와 메모리 버그가 극도로 많아진다”는 주장인지 궁금함
  그렇다면 그런 도구로 고품질 소프트웨어를 만드는 게 사실상 불가능하다는 뜻 아닌가? C/C++로도 품질 좋은 것들이 많이 만들어졌는데, Zig는 무엇을 잘못하고 있는지 의문임
• unsafe로 명확히 표시되니 찾기 쉽고, 해결해야 할 이슈 목록이 자연스럽게 생김

이걸 하는 데 6일이 걸렸음. 최종적으로 의미 있는 결과가 되지 않더라도, 지금과 앞으로 토큰과 작업량이 어떻게 연결될지 보여줌
더 많은 컴퓨팅 자원을 가진 개인이나 회사와 경쟁하기 어려워질 것임. 그들은 내가 못 하는 일을 그냥 할 수 있게 됨

• 좋은 테스트 스위트가 있는 프로젝트를 한 언어에서 다른 언어로 번역하는 건 대규모 언어 모델이 잘하는 대표적인 사례로 알려져 있음
  완성된 코드베이스를 예시로 쓰고 테스트 스위트로 검증할 수 있으면 원하는 목표를 향해 반복하기 훨씬 쉬움. 모델은 목표가 무엇인지, 그리고 한 번 구현된 방식이 무엇인지 이미 볼 수 있으므로, 명세에서 시작하는 것보다 훨씬 쉬운 문제임
• 증기력이나 전기에 대해서도 같은 말을 할 수 있었음. 단순한 비유만도 아님. 이런 것들의 마법은 범용 정보 엔진이라는 데 있음
  자본을 들여 잘 이해된 확장 가능한 기법으로 만들고, 전기를 꽂으면 가치가 나옴
  요지는 현대 세계에서 전기가 그렇게 되지 않았듯, “가진 자와 못 가진 자”가 생길 가능성은 없다는 것임
• 분명하지 않음. 아주 좋은 제품은 대체로 한두 가지를 아주 잘하는 데서 나오지, 많은 것을 하는 데서 나오지 않음
  지금까지 보이는 건 “와, 이제 나는 10배 엔지니어야!”라며 더 많은 코드를 내보내지만 명확한 방향성과 취향은 없는 모습임. 현재 대규모 언어 모델 기반 작업의 대부분은 그냥 잡음처럼 보임
• 아님. 이런 에이전트들은 로컬에서 돌리기가 점점 쉬워지고 있음
  Qwen 3.6 27b를 써봤는지 모르겠지만, 크기에 비해 할 수 있는 일이 미쳤음. 문맥 관리를 잘하면 작은 프로젝트는 100% 바이브 코딩도 가능함
  이런 모델들도 컴퓨팅처럼 결국 가격 경쟁으로 내려갈 것임
• Anthropic 표준 요금으로 냈다면 이게 달러로 얼마 들었을지 궁금함. 대략이라도 추산할 수 있는 사람이 있을까?

이걸 있는 그대로 받아들이는 사람이 많은데, 상당 부분은 이전에 구축된 표준 이상으로 광범위하고 포괄적인 테스트 스위트 덕분에 가능했음

• 그래도 가장 유능한 엔지니어라도 훨씬 더 오래 걸렸을 성과라 인상적임
  나중에 마케팅할 때, 이 속도를 가능하게 한 테스트 스위트를 설계하고 큐레이션하는 데 얼마나 많은 인간 노력이 들어갔는지도 함께 적히면 좋겠음
  테스트 스위트는 현 세대 대규모 언어 모델에 거의 이상적인 환경처럼 작동함. 충분히 포괄적인 테스트 스위트는 에이전트가 원하는 방식으로 구현할 수 있는 명세가 되며, 여기서는 그 대상이 Rust였음
  Bun 같은 프로젝트처럼 잘 만들어진 테스트라면, 경우에 따라 실제 소스 코드를 전부 버리고 테스트만 접근하게 해도 전체를 처음부터 다시 구현할 수 있을 것 같음
• 이게 다른 프로젝트와 비교해 이 작업을 유일하게 가능하게 할 정도의 “표준 이상” 테스트 스위트라면, Bun이 다른 Zig 프로그램보다 유독 불안정해서 재작성할 필요가 있다는 말과는 어떻게 양립하는지 의문임
  책임이 테스트 스위트에도 일부 있다면, Rust 포트에 대해서는 무엇을 뜻하는지도 궁금함
• 6일 만에 이렇게 할 수 있다는 것만 보라니
  그걸 가능하게 만든 원래 아키텍처와 테스트 스위트에 들어간 수십만 시간은 무시하라는 건가

AI를 이용한 Rust 포팅의 주의 사례로 볼 만함
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

• 테스트 통과가 곧 작동을 의미하지는 않음
  Claude code C 컴파일러는 gcc 테스트를 100% 통과했지만 hello world조차 실행하지 못했음
• 그 사례들에서 얻을 교훈은 조금 다름. 대규모 언어 모델은 피드백 루프로 준 것을 기준으로 만듦
  논리 테스트만 주면 속도는 전혀 고려하지 않음. 속도를 측정하는 테스트를 포함하고 성능을 맞추라고 하면 그것도 하게 됨
  대규모 언어 모델의 다른 오류와 같은 부류임. 사람이 중요하다고 여기는 것들에 대한 상식적 맥락이 없음. 경계를 강제하지 않으면 무시함
• 관심 있으면 여기서 논의됐음: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - 2026년 3월, 댓글 422개

살아 있는 시대가 참 대단함
업계와 직업의 근본적인 동역학이 너무 짧은 시간에, 사실상 하룻밤 사이에 바뀌었음
어떤 날은 지금 내가 할 수 있는 일이 너무 많아져서 흥분됨. 원하는 건 뭐든 거의 즉시 만들 수 있고, 소프트웨어로 꿈꾸던 것의 100%가 현실이 될 수 있음
어떤 날은 일자리 시장에 무슨 일이 벌어질지 두려움
갑자기 아주 적은 것으로 아주 많은 것을 얻을 수 있게 됐고, 세상에 필요한 소프트웨어의 양은 한계가 있음
소프트웨어 판매를 핵심 사업 모델로 하는 모든 회사가 망하게 될까?
최고의 모델에 특정 회사나 정부만 접근하게 되면 어떻게 될까?

• 티켓팅 시스템 같은 소프트웨어 사업을 생각해보자
  10억 토큰을 가진 기업 100곳이, 1000억 토큰을 가진 전문 벤더보다 더 나은 제품을 만들 수 있을까?
  “로고 생성기” 같은 소프트웨어 벤더와 SaaS는 이미 죽은 게 맞지만, 다음 세대 대규모 언어 모델에 티켓팅 시스템이 내장되지 않는 한 티켓팅 시스템 벤더는 괜찮을 것임. 인력은 줄 수 있지만 확실하진 않음
• 닷컴 붕괴 무렵에도 소프트웨어 산업은 “너무 포화됐다”며 학생과 구직자에게 들어오지 말라는 이야기가 꽤 있었음
  몰려드는 사람 수에 비해 나눠 가질 일이 별로 없다는 식이었고, 붕괴가 그 서사를 강화했음
  하지만 당시 학생이었어도 소프트웨어의 범위가 사실상 무한하다는 걸 알 수 있었음. 우리가 수작업으로 하는 거의 모든 인지적 일은 소프트웨어로 할 수 있음. 한 번 그런 것들을 열거해보려다가 할 일이 너무나 많다는 걸 금방 깨달았음
  게다가 일을 새로운 방식으로 할수록 상상도 못 했던 더 많은 일이 튀어나온다는 것도 이해했음. 가능성은 셀 수 없었고, “포화” 서사는 소프트웨어가 무엇인지에 대한 상상력과 이해 부족에서 나온 게 분명했음
  그래서 이 분야는 절대 포화되지 않을 거라고 알았음. 소프트웨어로 만들 대상이 바닥나는 건 불가능했기 때문임
  그런데 요즘은 다름. 앞으로도 새 소프트웨어는 늘 만들겠지만, 이제는 우리가 새로 할 일을 상상하는 속도보다 소프트웨어를 쓰는 속도가 더 빨라질 수 있는지 고민하게 됨
• 회사와 정부는 대중보다 더 나은 모델에 접근할 것임. 실제로 Mythos가 이미 그런 사례임
  대중도 최전선보다 뒤처진 모델로 스스로를 도울 수는 있을 것임

최소한 이런 시도가 진행되는 걸 구경하는 건 흥미로움
가장 먼저 궁금한 건 애초에 테스트 스위트의 포괄성과 품질이 어느 정도냐는 것임. 흠집을 내려는 건 아니지만, 모든 플랫폼에서 100%가 나와도 Bun 팀이 마이그레이션에 얼마나 확신을 가질 수 있을지 궁금함

지난주 Ubuntu coreutils 일 때문에 99.8% 테스트 호환 Rust 재작성에 대한 인상이 정말 나빠졌음
여기 링크된 트윗을 눌러보니 몸서리치는 느낌이었고, 이제 이런 걸 보면 정반대의 감정이 듦. 거의 출구를 찾게 됨

HTML로 기울면 사람과 LLM이 문서를 함께 작성·수정하기 쉬운 능력을 잃는 게 걱정됨
단순 설명문이면 괜찮지만, 더 복잡한 명세서라면 생성된 결과에 직접 들어가 고치는 능력이 매우 중요함. HTML 문서는 Markdown보다 그렇게 하기 훨씬 어렵고, LLM에게 다시 HTML 수정을 지시할 수도 있지만 머릿속에 이미 말하고 싶은 내용이 명확할 때는 그 자체가 또 하나의 장애물임. 이런 패턴이 흔해지면 사람/LLM 공동 창작은 더 줄고, 말투·톤·내용 선택까지 LLM에 위임하는 쪽으로 갈 것 같음. 블로그 FAQ에 이 우려가 없어서 놀랐음

• Markdown은 대화형 요소를 위해 인라인 HTML을 지원하니, 알려진 HTML 템플릿과 간단한 빌드 절차를 붙인 Markdown 문서가 흥미로운 대안일 수 있음
  예를 들면 한 줄짜리 pandoc 명령 같은 방식임
• 여기에 한 단계가 더 있다고 봄. HTML이면 대부분 가능하지만, LLM이 자기만의 언어를 정의하게 두는 것도 이상할 정도로 효과적이었음
  지금 등각 시점과 사운드가 있는 작은 모바일 게임을 만들고 있는데, Codex에게 준비된 three.js 문서에 블록을 배치하고 Chromium 개발자 도구로 스크린샷을 찍는 도구를 만들라고 했더니 블록·색·효과를 정의하는 작은 JSON 구조를 만들어 2.5D 타일셋을 출력했음. 또 uv Python 스크립트로 소리와 음악을 정의하게 했더니 잡음을 만들 수 있는 YAML 형식을 만들어냈음. SVG 펠리컨 테스트는 완전히 넘어섰고, Codex가 병사·기사·사제의 충분한 프로토타입 아트와 프로토타입 사운드트랙까지 만들어냄
• 우리는 수십 년 동안 HTML을 손으로 쉽게 작성해왔음. 텍스트 편집기는 HTML 작성에 아주 좋고, 자동 줄바꿈·자동 닫기 같은 명령도 많아서 읽고 쓰기가 단순함
• 원시 텔레타이프 에뮬레이터에 스스로를 가둘 때만 해당하는 얘기 같음. 제대로 된 코딩 환경이라면 HTML 편집은 아주 간단해야 하고, 풍부한 모델 출력으로 가는 흐름이라면 내장 WYSIWYG 편집기도 선택지가 될 수 있음
• 최근 보고서에 HTML을 쓰기 시작했지만, 항상 Markdown 파일을 중간 형식으로 두고 LLM에게 Markdown의 표를 바탕으로 SVG 그래프·그림이 들어간 더 멋진 버전을 만들라고 함

이게 대화형 HTML 페이지가 아니라 HTML 렌더링 이미지를 올린 Twitter 글이라는 점이 아이러니함
Markdown보다 의미 구조가 빈약한 플랫폼에서 HTML을 주장하는 게 결국 꽤 웃김

• https://thariqs.github.io/html-effectiveness/
  둘 다인 것 같음
• Twitter Articles의 “템플릿” 얘기는 시작도 하지 말자. Markdown조차 지원하지 않음

새 아이디어나 도구를 탐색할 때 자주 쓰는 프롬프트는 다음과 같음

In a single index.html, no dependencies, sparse styling, create an app that  

AI 이전에도 작은 도구를 이렇게 만들었고, 친구에게 도구를 이메일로 보내면서 “바꾸고 싶으면 LLM에 던져봐”라고 할 수 있는 점이 좋음

• 이 방식이 맞음
  대시보드, 작은 앱, API와 상호작용하거나 어디선가 데이터를 가져오는 유틸리티를 만들 때 스타일과 JS가 들어간 단일 HTML 파일 하나로 갈 수 있는 범위가 놀라울 정도로 넓음. 회사 공유 서버의 개인 ~ 폴더에 던져두면 모두가 바로 확인하고 쓸 수 있음
• 새 클라이언트의 디자인을 반복할 때도 단순한 index.html에 인라인 CSS를 넣어 만들고, 결과가 마음에 들면 그 파일을 프로젝트 템플릿 파일 옆에 넣은 뒤 LLM에게 index.html의 디자인을 템플릿 파일에 녹여달라고 함
• 이 사용 사례를 전에는 제대로 생각해본 적이 없어서 조금 바보 같았음. 유용할 게 너무 명백함
  지금까지 LLM을 쓸 때 초점은 “앱” 자체였지, 앱 주변의 보조 도구들이 아니었음. 그런 보조 도구들은 완성도 높거나 모든 경우를 처리할 필요가 없고, 유용할 만큼만 작동하면 됨. 다 쓰면 버리고 내일 새로 만들면 됨
• 예전에 이 요령을 알아내서 아날로그 전자회로용 계산기들을 잔뜩 만들었음: https://cofree.coffee/~solomon/calculators/
  이런 도구를 빠르게 조립해 정적 사이트에 올릴 수 있는 게 매우 편리함
• Claude 웹에서도 HTML을 요청하면 이렇게 함. 아티팩트로 만들어주니, 모델이 이 패턴에 잘 학습돼 있을 가능성이 큼

웹 기술은 정말 많은 걸 제대로 해냈음. 많이들 불평하지만 대단함
지난 직장에서 바이브 코딩된 앱을 다뤘고 결국 그 이유로 퇴사했는데, Next.js 단일 페이지 프론트엔드와 별도 API 백엔드 구조라 사용자용 URL이 백엔드 엔드포인트와 맞지 않았음. AI가 모든 것에 React 훅을 쓰다 보니 상태는 메모리에 있고, URL 기반 라우팅은 의식적으로 설계하지 않으면 존재하지 않음. 그래서 링크가 공짜로 생기지 않고, 사용자가 최상위 진입점 말고는 어디에도 링크할 방법이 없었음. 링크 말이다. 특히 내부 도구에서는 모든 것이 링크 가능해야 협업과 문제 해결이 쉬움. 통일된 자원 위치와 동사가 필요하다는 설계는 30~40년 전에도 정말 잘 생각된 것이었음

• 다른 페이지나 탭으로 이동해도 URL이 업데이트되지 않았다는 뜻인가?

HTML과 Markdown의 절충점으로 여기서 빠진 게 몇 가지 있음. HTML은 토큰 효율이 훨씬 낮고, HTML 계획에 정확한 피드백을 주기가 Markdown보다 어려움
이 두 절충점은 Anthropic에 유리하게 작용함. HTML을 매체로 쓰면 토큰 사용량이 늘고, Claude Design의 일부로 HTML에 주석을 달거나 표시하는 도구에 투자하고 있을 가능성이 높아서 락인도 강해질 수 있음. 우연이거나 뛰어난 전략임

• 조금 덜 효율적이긴 하지만 구조나 시각 요소가 아주 많지 않다면 차이가 엄청 크지는 않음
  정확한 피드백이 Markdown보다 왜 더 어려운지도 잘 모르겠음. 태그로 id, 섹션 등을 둘 수 있음
• HTML은 코드 실행 취약점의 범위도 더 넓음. 일반 텍스트는 해를 끼치지 않음

수십 년 동안 HTML을 다뤘지만 단순 문서는 여전히 Markdown이 더 빠름. 중간 지점이 있으면 좋겠고, 실제로 GitHub Markdown처럼 기능이 더 많은 것도 이미 있음
Mermaid를 임베드할 수도 있고, 필요할 때 컴포넌트를 섞는 MDX 같은 것도 쓸 수 있음. readme.com도 내부적으로 MDX를 쓰는 것으로 알고 있음. 카드나 레이아웃이 필요하면 Bootstrap 같은 것에 기반한 컴포넌트를 넣을 수도 있음. 이제 빠진 건 인터페이스 지원뿐임. 순수 HTML은 이미 렌더링할 수 있으니 더 강력한 Markdown을 추가하는 것도 그리 어렵지 않을 것 같음

• MDX가 완벽한 중간 지점이라고 봄. 이 댓글 덕분에 일반 Markdown 대신 MDX를 쓰기 시작할 생각임

원래 Markdown 명세 [1]와 CommonMark [2] 모두 인라인 HTML 지원을 명확히 규정함. 그래서 용도에 따라 양쪽의 장점을 어느 정도 얻을 수 있음
대부분은 일반 Markdown 헤더와 문단을 쓰고, 이미지와 표를 넣으면 HTML 태그 없이도 원문 형태로 읽기 좋음. 글쓴이가 예로 든 SVG 같은 걸 넣고 싶다면 SVG를 직접 임베드하고, 보는 사람은 선호하는 뷰어로 Markdown을 렌더링하면 됨. VS Code에서 원시 Markdown 파일을 보다가 HTML 태그를 만나면 Cmd+Shift+V로 미리보기를 열면 끝임. 물론 대화형 버튼, 완전한 맞춤 스타일링이 있는 본격 웹페이지라면 실현하기 어렵지만, 주로 텍스트·이미지·표 위주이고 여기저기 부가 요소만 더하려는 경우에는 꽤 멀리 갈 수 있음
[1] https://daringfireball.net/projects/markdown/syntax#html
[2] https://spec.commonmark.org/0.31.2/#html-blocks

• Markdown 문서는 미리보기가 필요 없어야 한다고 봄. 그럴 거면 그냥 HTML 문서를 만들면 됨

1월부터 비코딩 용도로 이 방식을 강하게 밀어왔음. 중요한 속성은 편집 가능하고, LLM과 사람이 이해할 수 있으며, 렌더링 가능하고, 점진적으로 수정할 수 있는 단일 진실 공급원이라는 점임
일반인들과 AI 작업에 대해 자주 얘기하는데, 길거리에서 AI 대화를 만나면 인류학자처럼 끼어들곤 함. HTML 아티팩트는 새로운 브라우저 URL 표시줄 같음. 어떤 사용자는 그 표시줄이 사실 Google이라고 이해하듯이 말임. 요즘 많은 사람이 “스프레드시트”, “프레젠테이션”, “마케팅 1장 요약”, “슬라이드 쇼”, “경쟁 분석”, “HVAC 시스템 다이어그램” 같은 작업물 얘기를 하면서 ChatGPT나 Claude 웹에서 작업하는 건 별로였고 Claude Code나 OpenClaw로 새 문서를 만드는 건 기적 같았다고 말함
실제 문서가 무엇이고 경험 차이가 무엇이었는지 물어보면, 컴퓨팅 어휘가 아직 없어서 꽤 캐물어야 하거나 직접 보여달라고 해야 하는데, 결국 항상 아티팩트가 HTML이라는 결론으로 감. 즐거운 경험은 파일시스템에 있는 HTML 파일(+CSS+이미지)을 고품질 즉시 렌더링으로 반복 수정하는 데서 오고, 필요할 때 JavaScript도 조금 뿌릴 수 있음. git 시스템이 있으면 본인도 모르게 버전 관리가 될 수도 있음. 없으면 체크포인트를 만들라고 권함. 일반인에게 버전 관리는 다음 학습 단계일지도 모름
반면 웹에 박힌 경험은 컨텍스트 창 속에 남아 있는 DOCX/PPTX/XLSX를 여러 번 찌르고, 로컬 저장소에 대한 흐릿한 개념을 다루는 식임. 사실 사이드바에서 HTML로 렌더링되는데도 그렇음. HTML 작업 흐름은 다른 매체도 훨씬 쉽게 통합하게 해줌. 결국 이런 발표 작업은 대중의 바이브 코딩이고, 아래에 깔린 거북이들을 모두 알 필요는 없음. 그래도 원한다면 열어보고 고치거나 다른 에이전트에게 쉽게 넘길 수 있음. 협업 멀티미디어 커뮤니케이션을 위해 만들어진 시스템이 기계 지능이 우리의 커뮤니케이션을 돕는 데 유용해진 셈임

예전에는 우리(https://www.definite.app/) 에이전트가 보고서와 대시보드를 프론트엔드 프레임워크가 렌더링하는 YAML 명세로 작성하게 했음
예를 들어 사용자가 “월별 매출과 주문 수를 보여주고 최근 주문 100개를 표시하는 보고서를 만들어줘”라고 하면, 에이전트가 프론트엔드에서 렌더링될 명세를 작성했음. 이 방식은 빠르지만, 프레임워크가 렌더링할 수 있는 기능 요청에 파묻혔음. “여기엔 레이블을 빼고 싶다”, “저기엔 레이블이 필요하다”, “이 차트를 히트맵으로 만들 수 있나” 같은 요청들임. 몇 달 전부터 에이전트가 그냥 HTML을 쓰게 했고, 생성은 더 오래 걸리지만 커스터마이징에는 제한이 없어짐. 새 방식에도 비기술 사용자가 자신이 만든 괴물 같은 앱을 디버깅해야 하는 등 문제가 많지만, 전체적으로 고객들은 훨씬 더 좋아함

• 이 경우 프롬프트 주입은 어떻게 막고 있음?

긴 에이전트 출력은 VIM과 macOS Quick Look(Markdown 렌더링 확장 포함)을 쓰거나, 미리보기 패널이 있는 MarkEdit에 붙여넣어 읽음
최악의 경우 에이전트에게 Markdown을 해석해 렌더링하는 단순한 로컬 웹페이지를 만들게 하면 됨. Markdown은 웹 문법의 축약형으로 발명된 것[0]이고, 바로 그 용도임. 에이전트에게 기본 Markdown을 HTML로 변환하라고 시키는 데 드는 토큰과 시간이 이 방법들보다 더 클 것 같음
0. https://daringfireball.net/projects/markdown/

• 토큰을 더 쓰는 건 맞을 가능성이 높지만, 글쓴이는 Anthropic에서 일하니 토큰 비용을 직접 내본 적이 없을 것 같음
• 끝까지 바이브로 가고 싶다면 긴 출력도 봇에게 요약해달라고 하면 되지 않나?
  봇 사용은 정말 정신없고 자기참조적으로 흘러가고 있음
• 어떤 Quick Look 확장인지 궁금함. 괜찮은 걸 찾고 있었음

Internet Archive도 Usenet이 했던 방식을 따라야 함. 사명은 같지만 소유가 다르고 전 세계에 분산된 여러 독립 조직이 서로 피어링하고, 어느 한 조직이 얻은 콘텐츠를 모두에게 배포하되, DMCA 신고와 삭제 요청을 전달할 기술적 경로나 기능은 두지 않는 구조가 필요함
이게 아는 한 Usenet 불법 복제가 돌아가는 방식임. 불법 복제물을 한 제공자에게 보내면 그 제공자가 피어링된 모든 제공자에게 즉시 복제하고, 재귀적으로 전체 네트워크에 퍼짐. 어떤 제공자가 DMCA 신고를 받으면 법적 의무에 따라 해당 파일을 지우지만, 다른 제공자에게 신고 사실을 알리지 않으므로 그 파일은 계속 제공됨. 그래서 네트워크에서 데이터를 지우는 일이 추가하는 일보다 훨씬 어려워짐

• 그러면 BitTorrent를 쓰면 됨
  개인 보안은 “열린 웹”에서 벗어나 다양화할 때만 좋아질 것 같음. 프로토콜과 사전 공유 키 네트워크를 잔뜩 늘리고, 키는 오프라인에서 함께 만들게 해서 감시망 운영 비용을 너무 비싸게 만들어야 함
  모두가 열린 웹이라는 바구니에 달걀을 몰아넣고 공공 광장에 모이면, 비유하자면 폭탄 하나로 모두가 당할 수 있음
• 이론적으로는 마음에 들지만, IA는 175PB 넘는 데이터를 호스팅함. 그 데이터를 복제할 수 있는 다른 제공자가 얼마나 있을지 궁금함

관련 블로그 글: https://blog.archive.org/2026/05/06/internet-archive-switzer...
“Internet Archive Switzerland는 Internet Archive, Internet Archive Canada, Internet Archive Europe과 함께 사명을 공유하는 조직군에 합류한다. 이 독립 도서관들은 함께 분산되고 회복력 있는 세계 디지털 도서관이라는 공동 비전을 강화한다”는 내용임

• 다른 조직들도 궁금했는데, https://www.internetarchive.eu는 기업 홍보 사이트처럼 보여서 별로임. 히어로 이미지, AI 자랑, 느린 애니메이션 없이는 스크롤되지 않는 뉴스 캐러셀, 얼굴 사진과 지루한 소개가 붙은 거대한 “팀 소개”, 소셜 미디어 링크, 뉴스레터 가입 폼만 있고 실제 아카이브가 어디 있는지는 안 보임

해당 웹사이트가 꽤 버거워하고 있음. 보려고 archive.org의 미러로 가고 싶은 유혹이 큼 :)
이건 미국의 Internet Archive와 꽤 별개로 보이는데, 실제로 얼마나 분리돼 있는지 궁금함
Internet Archive Canada에서 2024년에 일했을 때는 기술적으로는 독립 조직이고 일부 이사가 겹쳤던 것 같지만, 실제 운영은 자회사처럼 느껴졌음. 같은 Slack, 같은 archive.org 이메일 도메인 등을 썼음
IA.ch 이사회에는 Brewster와 Caslon이 있음
이번 10년의 정치적 위협을 생각하면, 여러 Internet Archive 조직은 특히 자금 조달 측면에서 더 독립적으로 운영되기 시작해야 할 것 같음

• Slack을 쓴다니 좀 놀라움. 그래도 장점이라면 가용성 걱정을 하나 줄일 수 있다는 뜻이기도 하겠음
• 캐나다 조직에서 일했던 경험을 더 들려줄 수 있나? 몇 년 전에 꽤 큰 소동이 있었던 느낌인데, 실제로 무엇을 하는지는 명확하지 않음

About Us 섹션에 “우리는 모든 도움의 손길이 아이를 키우고 더 나은 미래를 만들 수 있다고 믿는 변화의 팀입니다”라고 되어 있음
이상하게 느껴져서 이 문구를 검색해 보니 여러 사이트에 그대로 나오는데, 그게 더 이상함. 일종의 템플릿 문구인가? Contact 섹션도 주소가 “123 Fifth Avenue, NY” 같은 식이라 허술한 임시 문구로 보임

• 솔직히 말해 그다지 신뢰가 생기지는 않음

실제 아카이브를 찾을 수가 없음. 열 문장도 안 지나 AI 아카이브를 언급하고 링크도 몇 개 있지만, 실제로 보존된 콘텐츠는 없는 것처럼 보임

Sankt Gallen의 물리적 아카이브도 방문할 만함: https://www.stiftsbezirk.ch/de/stiftsbibliothek/

• 맞음. 오스트리아 Admont의 이곳도 좋음: https://stiftadmont.at/en/about-the-abbey-library/

이걸 운영하고 있고 이 글을 읽고 있다면, 그냥 옳은 일을 해서 자기 이름을 쓰는 게 맞음

• 음… https://blog.archive.org/2026/05/06/internet-archive-switzer...

좋네, 페이지 로딩 속도까지 Internet Archive를 미러링하고 있음

가용성 불평은 그만하고 대신 해결책을 만들어야 함
tpb dot org도 아직 존재할 수 있다면 말임
적어도 이 사람들은 시도했음. 우리 역사가 완전히 다시 쓰이기 전에 P2P 아카이브 솔루션이 최대한 빨리 필요함

• 이 문제는 탈중앙화와 잘 맞지 않는 것 같음. IPFS 같은 것으로 시도한 사람들이 있었고, IA도 https://github.com/internetarchive/dweb-gateway 같은 시도를 했음
  아직 아무도 이걸 제대로 풀지 못했음
• 계속해서 P2P 솔루션을 만들려고 해왔음. Torrents, DWEB, IPFS, Filecoin, WebTorrent, YJS 등 기술 약어가 잔뜩 있음. 실제로 얼마나 자리 잡았는지는 잘 모르겠음
  https://blog.archive.org/tag/decentralized-web/
  https://github.com/internetarchive/dweb-transports
  제3자 시도:
  https://wiki.archiveteam.org/index.php/INTERNETARCHIVE.BAK
  알고 보니 어렵다! 아니면 너무 틈새 분야일 수도 있음. 그래도 오늘 당장 토렌트로 제공되는 일부 컬렉션을 시딩해서 도울 수 있음

5.5 Pro를 잠깐 써본 경험과 맞아떨어짐. 처음으로 지루하지만 명확한 문제를 제대로 풀도록 몰아갈 수 있는 LLM이라는 느낌이 들었음
여전히 실수가 많고 아주 빡빡하게 안내해야 하지만, 다른 모델과 달리 자기 추론을 따라가며 스스로 수정하는 능력이 꽤 좋음
단점은 비용임. 토큰을 미친 듯이 쓰고 토큰 단가도 비싸며, 큰 문제를 높은 정확도로 풀게 하려고 하위 에이전트 흐름을 쓰면 더 비싸짐
대규모 문제에서는 문맥 제한 때문에 훨씬 느려지기도 함. 각 부분마다 문맥을 다시 찾아야 하고, 정확도를 위해 다음 작은 부분으로 넘어가기 전에 문맥을 지우거나 더 많은 에이전트를 띄워야 함
수학 증명처럼 문제와 증명 이해에 필요한 추가 문맥이 작고 “중요한” 문제라면 괜찮을 수 있지만, 큰 코드베이스의 코드 정확성 확인이나 미묘한 가정 검증에는 분명한 한계가 있음
그래서 5.5 Pro를 무제한으로 쓸 수 있는 운 좋은 사람이 아니라면, 이런 모델의 인상적인 능력이 프로그래머의 일상에 스며드는 데는 시간이 좀 걸릴 것 같음

긴 글이고 기술적인 수학 부분과 철학적 부분이 섞여 있는데, 특히 인상적인 대목은 박사 초년생 훈련이 더 어려워졌다는 점임
예전에는 비교적 순한 연구 문제를 주며 시작하게 할 수 있었지만, LLM이 그런 “순한 문제”를 풀 수 있다면 더 이상 그 선택지가 없음
수학에 기여하는 하한선이 “아직 아무도 증명하지 않았고 흥미로운 것”이 아니라 “LLM이 증명하지 못하는 것”이 됨
다만 훈련은 여전히 기초에서 시작해야 함. 모두가 작은 정수 덧셈부터 배우고, 계산기는 오래전부터 그걸 실수 없이 해왔음
글의 다른 부분처럼 어려운 문제를 직접 풀어야 문제 해결 과정 자체에 대한 통찰이 생기고, 이미 어려운 문제를 풀어본 사람이 AI를 더 잘 활용할 가능성이 큼
코딩은 사람들이 돈을 벌기 위해 쓸 물건을 만드는 일이므로 AI로 더 빨리 납품하고 계속 고용될 수 있지만, 수학에서도 같은 식으로 볼 수 있는지는 잘 모르겠음
LLM이 주요 아이디어와 기술 작업을 다 하고 수학자는 유용하게 안내만 했다면, 그것을 수학자의 큰 업적으로 볼지는 의문임

• 어려운 문제를 직접 풀면 다른 문제를 더 잘 풀게 되는 것뿐 아니라, 그 문제 자체를 훨씬 더 깊이 이해하게 됨
  기업에서도 사람들이 LLM에 일을 맡기면 결과가 항상 나쁘지는 않고 때로는 받아들일 만하지만, 그건 그 사람의 작업이 아님
  그래서 작성자는 남들보다 그 일을 더 잘 알거나 이해하지 못하고, 소유하지도 설명하지도 못함. 말 그대로 통과 지점일 뿐이라 가치가 사라짐
• 오히려 그것도 큰 업적으로 봐야 할지도 모름
• 두 핵심을 약간 놓친 것 같음. 기초부터 배워야 하는 건 맞지만, 어느 시점, 예컨대 박사를 시작할 때는 기초 학습이 아니라 연구를 해야 함
  LLM이 “쉬운 연구”를 풀어버리면 그 과정이 더 어려워짐
  어린 사자가 다른 어린 사자와 싸우고 놀며 나중의 사냥을 배우는데, 갑자기 TikTok이 생겨 더 이상 놀지 않는다면 첫 사냥은 훨씬 어려워질 것임
  AI로 더 빨리 납품해 돈을 벌 수 있다는 것도 맞지만, 좋은 코더가 되는 문제와는 다름. 좋은 코더가 되지 못하면 계속 나쁜 바이브 코더로 남게 됨
• 정말 그게 중요한가? 그리고 철학적으로 이전의 컴퓨터 보조 증명과 그렇게 다른가?

Baez의 흥미로운 대목은 생각과 깊은 아이디어의 가치가 어디서 오는가라는 질문임
그 가치가 주로 희소성, 즉 어떤 아이디어를 갖기 어렵다는 사실에서 온다면 아이디어 제조가 자동화될 때 가치가 급락할 수 있음
하지만 가치가 아이디어의 효용, 즉 그 아이디어가 가져오는 이익에서 온다면 이야기가 달라짐. 더 좋은 아이디어를 더 많이 만드는 것이 오히려 더 나을 수 있음
수학자들은 희소성 경제에서 풍요의 경제로의 전환에 적응해야 할지도 모름
https://gowers.wordpress.com/2026/05/08/a-recent-experience-...

• 수학자에는 세 부류가 있음. 첫째는 순수한 문제 해결자이고 Tao가 대표적이며, 이들의 화폐는 흥미로운 문제와 그 해법임
  둘째는 순수한 이론 구축자이고 Conway가 대표적이며, 정리보다 이론과 아이디어에 관심이 많고 수학의 영토를 넓히려 함
  셋째는 응용수학자이고, 수학을 목적을 위한 수단으로 보며 수학 밖의 문제를 수학으로 풀고 싶어 함
  첫 번째 부류인 문제 해결자가 AI에 가장 즉각적으로 위협받는 듯함. 다만 아직 AI는 새 추측을 찾기보다 문제 풀이에 더 강함
  두 번째 부류인 이론 구축자는 더 먼 미래에 위협받음. 지금까지 AI가 새롭고 흥미로운 수학적 아이디어를 내는 능력은 제한적이고, 그런 걸 어떻게 훈련해야 하는지도 아무도 모름
  세 번째 부류는 AI에서 가장 많은 이익을 얻을 수 있음. AI가 수학적 질문에 답해주면 수학에 쓰는 시간을 줄이고, 수학으로 풀고 싶었던 외부 문제에 더 집중할 수 있음
• 새로운 것을 밀어붙이는 사람은 항상 같은 온라인 평론가들인 것 같음. 뛰어난 학자라 해도 마찬가지임
  반면 Wiles와 Perelman은 온라인을 멀리하고 진짜 문제를 풀었음

물리학 교수로서 Gemini를 논문 점검에 자주 쓰는데, 강력한 도구임
며칠 동안 찾지 못했던 복소 수식의 허수 단위 누락 같은 사무적 오류를 찾아냈고, 놓쳤던 개념과 아이디어 사이의 연결도 자주 짚어줌
하지만 개념적 오류도 자주 내며, 해당 주제를 잘 알기 때문에 알아챌 수 있음. 예컨대 3차원 Clifford 대수에서 이중벡터의 지수와 의사스칼라의 지수를 반복해서 혼동함
ChatGPT 5.5 Pro가 출판 가능한 논문을 만들 수 있다는 건 알겠지만, 지금까지 Gemini를 본 바로는 LLM을 논문과 책을 순식간에 읽는 매우 효율적인 학생으로 보되 여전히 많은 지도가 필요한 대상으로 보는 편이 나음

• 위 경험은 GPT-5.5 Pro와 더 비슷한 Deep Think 모드가 아니라 “일반” Gemini 3.1 Pro를 쓴 것으로 보임. 일반 3.1 Pro는 한 단계 낮고 실수가 잦은 편임
  게다가 3~4년 전만 해도 고등학교 수학도 안정적으로 못 풀던 LLM의 발전이 곧 멈출 이유는 없음
  CritPt 벤치마크는 미발표 연구 수준 물리 문제로 구성되어 있으니 추적해볼 만함
  https://critpt.com/
  최전선 모델도 아직 해결과는 거리가 멀지만 발전은 빠름. o3 high는 1.5년 전 1.4%, GPT 5.4 xhigh는 23.4%, GPT-5.5 xhigh는 27.1%, GPT-5.5 Pro xhigh는 30.6%임
  https://artificialanalysis.ai/evaluations/critpt
• “멘토링”이라는 표현은 의인화이고, 무의식적으로 모델이 배울 것처럼 생각하게 만듦. 실제로는 배우지 않으며, LLM처럼 똑똑해 보이는 무언가가 배우지 않는다는 점을 계속 기억하는 건 인간에게 꽤 어려움
  나도 같은 실수를 자꾸 함
  사용자 지정 프롬프트와 지시로 LLM의 기억을 수동 관리해야 하는 것도 짜증나는 이유 중 하나임
  장기 기억 기능은 아직 제대로 써보지 않았지만, 프롬프트보다 더 신뢰하기 어려울 것 같음. 1~2년이면 너무 많은 것이 바뀌어서 그 “기억”도 여러 번 다시 만들어야 할 가능성이 큼
• LLM은 출력에 대한 기대치가 있을 때 가장 잘 작동함. 대체로 정답의 형태를 알고 있으면 줄 단위가 아니라 감각적으로 평가할 수 있음
  기대치가 없으면 모든 것을 액면 그대로 받아들여야 하고, 그 순간 기계의 자비에 맡겨짐
• 물리학 교수는 아니지만, 시니어 엔지니어 영역에서 도구를 쓰는 방식과 비슷함
  기본기를 가져와서 성급한 에이전트를 sanity check하고, 다른 사람들도 같은 일을 할 수 있도록 그 기본기를 심어주려 함
  결국 이 방식이 전체가 작동하는 유일한 길처럼 느껴짐. 언젠가 회사들이 감당 가능한 더 작은 로컬 모델로 옮겨가는 경우를 제외하면 그렇음
• LLM은 장밋빛이고 그럴듯하게 작업을 제시하면서 계속하면 더 해주겠다고 말함
  맞을 확률과 절벽에서 뛰어내리게 할 확률이 반반인데, 여행 자체는 항상 아름다운 5성급처럼 포장됨
  오류를 찾아 LLM에 말하면 대부분 더 나빠짐. LLM은 기쁘게 해주려 하면서 사과하고 방향을 바꾸기 때문임
  그런 상황이 되면 보통 세션을 저장하거나 취소하고 처음부터 다시 시작하거나, 과감하게 방향을 틀게 됨
  내게 Gemini는 가장 예측하기 어려운 LLM이고, 전체적으로는 GPT가 가장 잘 맞음
  최근 Gemini는 같은 질문에 두 가지 다른 답을 줬음. 일부러 새 채팅을 열고 같은 프롬프트를 붙여 넣어 본 테스트였음
  코딩 영역에서는 추론 기능이 큰 도움이 되지 않음. LLM의 설명은 매우 고수준이고 형식적으로는 맞아 보이기 때문임
  LLM 때문에 오히려 구글링을 더 하게 됨. 결국 버튼을 누르기 전에 내가 먼저 검증해야 할 무언가를 누군가 만들어내는 셈이고, 그 반짝이는 버튼이 작동할지 지옥으로 안내할지는 잠시 뒤에야 알 수 있음

수학자가 LLM과 긴 대화를 하면서 유용하게 안내했지만 기술 작업과 주요 아이디어를 LLM이 다 했다면, 그걸 수학자의 큰 업적으로 볼지는 문화적 선택임
현재 수학 문화에서는 낯설게 느껴지는 게 자연스럽지만, 이미 다른 분야나 많은 개인은 인간에게 큰 업적이 있었다고 볼 수 있음
인간-AI 협업이 최고의 결과를 내는 동안에는 인간의 의미 있는 기여가 있고, 깊은 전문가이자 숙련된 LLM 조련자는 큰 기여를 할 수 있음
진짜 변화는 순수 AI가 인간과 인간-AI 협업을 모두 이길 때 옴

• 자동차 경주에서 성능의 대부분은 차에서 나오지만 우리는 운전자를 칭찬함. 두 차의 성능이 비슷할 때 운전자의 뛰어남이나 실수가 차이를 만듦. 승마도 비슷함
  수학에서도 인간이 LLM을 올바른 길로 이끌고, 특정 문제나 다른 문제로 향하게 할 수 있으니 어느 정도 칭찬받을 만함
  차를 만든 팀, 말을 돌본 사람, AI를 만든 팀이 더 큰 칭찬을 받을 수도 있지만, 우리는 보통 가장 눈에 띄는 한 사람에게 더 관심을 둠
• 이 논점은 AI 이미지와 코미디를 떠올리게 함
  이미지가 사람들을 웃긴다면, 프롬프트를 넣은 사람이 제작 작업 대부분의 공을 가져가지는 못하겠지만, 초기 아이디어와 여러 초안 중 특정 결과를 고른 취향에 대해서는 공을 받을 수 있음
  수학자가 LLM이 “한” 놀라운 결과를 얻었다면, 프롬프트를 주고 안내한 점에 대해 어느 정도 공을 받을 수 있다고 봄
  다만 첫 번째 사람은 예술가가 아니라 코미디언이라고 부를 수 있을지 몰라도, 그 수학자는 여전히 수학자인지 아니면 다른 무언가인지가 문제임
• 누군가 프롬프트를 찾았거나 대화를 자동화해서 열린 수학 문제를 전부 훑었더라도, 유용한 결과를 만들고 아무에게도 해를 끼치지 않았다면 가치 있는 인간 활동이고 보상받아야 한다고 봄
  다른 수학자들에게 주는 보상만큼 주면 됨. 물론 억만장자 수학자가 많을 테니 그 보상이 꽤 크겠지만
• 수학자의 큰 업적은 아닐 수 있지만, 그래도 큰 결과임

“수학을 하는 목적이 어떤 종류의 불멸성을 얻는 것이라면, 그게 더 이상 오래 가능하지 않을 수도 있다”는 문장이 조금 슬펐음

• 어제 YouTube에서 영화 ‘21’(2008)을 무료로 봤음
  영화 도입부에는 MIT 캠퍼스를 누비는 학생들과 고등교육이 가져오는 약속과 지위가 가득함
  AI에 얼마나 많은 것이 넘어갈지를 깨닫자 비슷한 슬픔이 들었음
  [0] - https://youtu.be/0lsUsWdkk0Y?si=TJl7f_b1RcWcDqF8&t=278
• 그 문장이 에세이에서 가장 흥미로웠음. 학계 수학 커리어를 바로 접었던 때가 떠올랐고, 19~20살 때는 내가 그 분야에서 세계적 수준이 될 수 없다고 생각했음. 실제로도 맞았음
  다음 생각은 “나는 무엇을 잘하지?”였고, 그 안에는 적어도 “무엇에서 세계적 수준이 될 수 있을까?” 혹은 “아주 잘할 수 있을까?”가 들어 있었음
  내가 어떤 결과를 찾아 이름 붙이고 나보다 오래 남게 해서 수학적 불멸성을 얻을 만큼 충분하다고 생각한 적은 없지만, 그랬다면 이런 나쁜 소식이 비슷한 충격을 줬을 수도 있음
  다만 경계에서는 전제에 동의하지 않음. 얼마나 많은 증명 보조기나 클러스터 컴퓨팅을 쓰든, 리만 가설을 증명하는 팀이나 사람은 유명해질 것임. 적어도 수학계에서는 유명해짐
• 그렇게 실망할 일인지는 모르겠음. 위대한 수학자 대부분이 실제로 불멸성을 얻기 위해 했다고는 생각하지 않음
  아마 많은 이들은 수학→물리→공학으로 이어지는 간접적 실용 응용을 노렸거나, 그냥 수학의 아름다움과 지적 즐거움 때문에 했을 것임
  AI가 실용 응용까지 가져갈 수도 있지만, 나머지 측면은 여전히 누릴 수 있음
• 모든 종류의 인간 성취에 대해 같은 말을 반복해보면 됨

대학원생으로서 이 글은 슬펐음. 내 작업이 나 자신을 넘어, 이 우주적 경험에서 주어진 제한된 시간 너머로 말해줄 것이라고 믿어왔음
그런 불멸성의 감각은 대학원에 뛰어들 때 기대했던 작고 무형의 보너스였는데, AI 때문에 스스로 덜 가치 있게 느껴짐

• 훨씬 더 뒤를 지나온 사람으로서, 그런 생각은 내려놓는 편이 좋다고 조심스럽게 말하고 싶음. 뛰어나고 야심 있는 사람들이 그 생각 때문에 우울에 빠지는 걸 너무 많이 봤음
  그 일을 할 수 있기 때문에 그 일을 할 가치가 있는 것임. 사랑하기 때문에, 그리고 미스터리를 사랑하기 때문에 하길 바람
  그 일을 할 수 있는 매 순간을 즐기면 좋겠음. 만족을 주지 않는 일에 시달리는 사람들과 달리 이런 일을 할 수 있는 큰 행운에서 기쁨을 찾길 바람
  때로는 지루하지만, 때로는 그 자체로 믿을 수 없을 만큼 보람 있음
  다만 영원한 영광의 가능성을 위해 일하지는 말아야 함. 그런 것은 더 이상 존재하지 않음
• 충분히 가치 있음. 대학원에서 기술을 갈고닦으면 오랫동안 어려운 문제와 씨름하지 않은 사람보다 이 AI들을 더 잘 지휘할 수 있게 됨
• “지능을 다른 모든 인간적 자질보다 높게 평가한다면, 힘든 시간을 보내게 될 것이다.” - Ilya Sutskever, 2023
• 이 현실에는 LLM이 스스로 알아낼 수 있는 것보다 훨씬 더 배울 것이 많음. 특히 진실, 윤리, 도덕에 관해서는 더 그렇고, 이 현실을 떠날 때 결국 중요한 것은 그것뿐임
  그보다 더 큰 도전은 없음
• 용기는 이상한 과학적 돌파구보다 시간을 더 잘 초월한다고 느낌. 그런 돌파구는 대개 한 사람에게 귀속되지만, 뿌리는 이름 없는 “덜 중요한” 사람들에게서 온 경우가 많음

동유럽의 이론컴퓨터과학 조교수로서, 수학계의 큰 이름들이 비싼 장시간 추론 모델에 쉽게 접근하는 것이 늘 조금 부러움
현재 학술 예산으로 Pro를 내는 건 여기서는 현실 밖의 일임. 예산은 용도가 제한되어 있고 소프트웨어 결제는 들어맞는 항목이 거의 없음
사실상 새 연구비를 신청하고, 그 규정이 큰 소프트웨어 지출을 허용하며, 반AI 심사자를 만나지 않기를 바라야 함. 그런 절차는 최소 1년 걸림
엎친 데 덮친 격으로 Microsoft가 Copilot의 개인 및 학술 사용을 조이면서 최근 Claude Opus 접근도 막혔음
ChatGPT 5.5 Plus는 새 연구 주제를 깊게 파고들기에는 충분하지 않아 보였고, 직접 해봤음

• @NotOscarWilde 이메일을 남기면 연락하겠음. OAI에서 일하고 있고, 몇 달간 5.5 Pro를 써볼 수 있게 Pro 계정을 마련해줄 수 있음
• 우리 대학에서는 최근 공동 AI 서비스가 도입되기 전까지 모두가 AI 구독료를 자기 돈으로 냈음
  그 서비스를 세팅하는 데 2년이 걸렸고 gpt-oss-120b만 제공해서, 여전히 모두가 다른 서비스를 씀
  그래도 어떤 관리자는 대학 웹사이트 곳곳에 “AI”라는 단어를 뿌릴 수 있고, “이미 AI가 있다”는 이유로 AI 구독 요청을 거절할 핑계가 생김
• 가장 유리한 위치에 있는 사람들이 계속 보상을 거둬들이기 가장 좋은 위치에 있다는 전형적 사례임
  가난한 사람과 부자가 부츠를 사는 예가 있음. 가난한 사람의 부츠는 닳아서 계속 교체해야 하지만, 부자의 부츠는 더 좋은 품질이라 여러 해 감
  시간이 지나면 가난한 사람이 부츠에 더 많은 돈을 쓰게 됨
• OpenRouter는 구독 없이 토큰 단위 과금만 가능하고, Opus 4.7과 GPT-5.5를 포함한 최전선 모델 대부분을 제공함
  아껴 쓰면 보통 꽤 저렴하게 나옴
• ChatGPT 5.5 Pro 접근은 월 100달러로 가능한 것으로 아는데, 그 위치와 지역에서 감당하기 비현실적인 수준인지 궁금함
  대학이 내주지 않더라도 본인 목표를 위해 쓰고 싶을 것 같음
  비난하려는 게 아니라, 그 지역 연구자 대부분에게 완전히 닿을 수 없는 비용인지 궁금함

약 10년 전 Seattle의 AMS-MAA 공동 회의에서 Tim Gowers가 강연하며, 100년 뒤에는 인간이 더 이상 연구 수학을 하지 않을 것이라고 예측하는 걸 봤음. 지금은 일정을 조정했을지 궁금함
당시에는 MathOverflow처럼 작동하는 자연어 검색이 핵심적으로 빠진 도구라고 생각했음. 문제나 아이디어를 자신이 이해한 대로 설명하면, 자신의 경험이나 어휘 밖에 있는 관련 문헌을 찾아주는 방식임

• Teichmüller도 독일이 2차 세계대전에서 이길 것이라 생각하고 동부전선에 자원했음
  뛰어난 수학자라고 해서 맞는 것은 아님. 사실 수학자들은 꽤 기이한 이론을 많이 갖고 있음

올가을 고등교육에 들어가는 학생들의 압도적 다수는 연구를 한다 해도 4~5년 뒤에야 과학에 크게 기여할 수 있음. 박사 과정이 본격화되는 시점까지 보면 현실적으로 6~7년임
5~7년 전의 모델 수준을 보면, 그때는 박사의 실존적 위협 같은 건 레이더에도 없었음. 지금 박사를 마치는 사람들이 이 도구를 진정으로 활용할 수 있는 첫 세대임
이제 연구자가 되려는 학생들이 패배감을 느껴 그만두거나, AI 모델에 완전히 기대어 일을 시키면 문제가 생김
박사 자리의 자금 지원도 마찬가지임. “연구자 양성”을 위한 지원에서 “결과 달성”을 위한 지원으로 옮겨가면, 박사생에게 쓰이던 돈이 컴퓨팅 자원으로 흘러갈 수 있음
냉소적으로 보면, 어떤 연구자는 학생 몇 년을 훈련시키는 것보다 컴퓨팅에 돈을 써서 훨씬 더 많은 논문을 뽑아낼 수 있음
흥미로운 시대지만 불확실성이 너무 큼. 지금 무엇을 할지 결정해야 하는 학생들이 안타깝게 느껴짐

• 이런 일은 이미 일어나고 있고 더 빨라질 것임. 대학원 밖에서도 이미 학위를 살 수 있음
  특히 더 부드러운 분야에서는 박사 논문과 좋은 출판 이력을 지금도 살 수 있음
  학계가 아니라 산업계에 있다면 승진도 살 수 있음. 고용주가 모든 직원에게 AI 예산을 준다면, 승진할 때까지 조용히 자기 돈으로 그 예산을 두 배로 늘리고, 승진 후에는 멈춘 뒤 더 큰 월급을 누리면 됨
• 박사과정생들은 이미 AI 모델을 써서 일을 시키고 있음. 내가 아는 박사 후보 대부분은 월 200달러짜리 Claude Max 플랜을 최대한 활용함
  이전에는 할 수 없던 연구를 할 수 있게 된 것이 보임
  AI 사용이 코드를 직접 짜는 능력을 어느 정도 약화시킨 것도 보이지만, scikit-learn이나 Pytorch로 머신러닝 모델을 짜는 것과 비슷하게 봄
  밑바닥 세부는 추상화되고 AI 없이는 많이 못 하겠지만, 그 연구는 실제로 그 사람 때문에 일어나는 것이며 AI만으로는 일어나지 않았을 것임
• 지금까지 기관들이 박사과정생에게 돈을 펑펑 준 것도 아님
  나중에 붙은 예산 항목에 가까운 그 돈이, 비싸고 다른 절차를 위해 털어갈 만큼 매력적인 표적은 아님

내 글이 어떻게 도움이 됐는지 알려줘서 고마움. 자세한 리뷰를 쓰는 이유는 여러 가지인데, 내 만족도 있고, 원 프로젝트를 돕기 위해서이기도 하고 개발자가 관심을 보일 때도 있지만 아닌 경우도 많고, 인터넷에서 누군가가 틀렸기 때문이기도 함
하지만 가장 큰 이유는 가르치는 걸 좋아하고, 다른 사람들이 이 리뷰를 읽는다는 걸 알기 때문임. 실제로 내 리뷰들은 꾸준히 가장 많은 추천을 받는 댓글에 속함
가끔 모르는 사람이 남겨주는 감사 댓글을 정말 소중하게 여기고, 이렇게 자세한 감사는 더 따뜻한 기분을 줌
재미있는 건 1월에 당신 사이트를 발견했고 특히 “more purple links, please”를 아주 마음에 들어 했는데, 오늘 보니 내가 모르는 사이 당신의 입장에 영향을 준 셈이었음
어제 새 웹사이트를 공개했고, 앞으로 여러 매체에서 리뷰를 훨씬 더 많이 올릴 생각임. 지난달에 이 계획을 조금 적어둠: https://lobste.rs/s/vpdpkq/llm_reviews_cargo_crev#c_8uk441
또 이미 추가 쿼리 문자열에 알레르기 반응을 보이는 페이지 예시가 하나 더 있었다는 점이 조금 놀라웠음. 그 사이트에서는 해당 페이지만 ?1, ?2, ?3, ?4처럼 쿼리 문자열을 하위 페이지 라우팅에 쓰고, 다른 페이지들은 쿼리 문자열을 받아줌. 순차 페이지네이션은 명백히 계층적이라 URL의 정신에는 어긋나지만, ?page=1 같은 방식도 흔하긴 함
어떤 상태 코드를 반환할지 정할 때 404가 잘못된 가정 때문에 부작용을 낼까 걱정했는데, 어쩌면 그 걱정은 과했을지도 모름. 웹의 상당 부분이 경로를 의미 있게 쓰지 않는다는 걸 깜빡했음

• 권한 없는 쿼리 문자열에 대해 "418 I'm not a teapot" 응답을 반환하는 건 고려하지 않았나?

좋음. Wander console이 훌륭하게 성장하고 있고, Susam이 여기서 보여주는 세심함이 작동하는 큰 이유로 보임
내 URL에도 원치 않는 쿼리 문자열이 붙는 변형을 몇 가지 봤음. Programmer Weekly 뉴스레터는 쿼리를 붙이지만 참조자 헤더도 있어서 중복임
또 다른 경우는 구독자마다 고유 ID가 붙는 듯한데, 전혀 원치 않음. 곤란하게도 참조자가 없어서 어느 사이트가 그러는지도 모름
/blog/modeling-on-demand-pricing/?ck_subscriber_id=<unique-id>

“알고 싶으면 Referer 헤더를 보면 되고, 없다면 아마 그럴 만한 이유가 있을 것”이라는 말에 동의하고 싶지만, Referer는 몇 년째 어느 정도 망가졌거나 쓸모없는 상태였음. 이런 것들이 생긴 유일한 이유가 그 때문임

• 어떻게 그렇다는 건가?

“왜 추가했냐고? 대중적 요구에 굴복했다”라니, 정말 그랬나? 관련 없는 이슈에 달린 추천 5개짜리 가벼운 댓글 하나였음. 굴복하기 전 싸움이 그리 치열하진 않았던 듯 ;-)

• 여기서 ‘가벼운 댓글’이 무슨 뜻인지 잘 모르겠음. 그 댓글은 내 소프트웨어를 직접 써보고, 자기 웹사이트에 설치하고, 그 사이트를 커뮤니티 네트워크의 일부로 만든 사람이 남긴 것이었음. 그걸 ‘가벼운 것’으로 치부하진 않겠음
  이 프로젝트에 사용자가 열 명 정도뿐이던 시점에 새 기능 제안이 추천 5개를 받았다면, 내게는 대중적 요구처럼 느껴졌음
  내 프로젝트들은 보통 취미로 만드는 작은 도구임. 몇 가지 예외를 빼면 사용자 수가 많지 않음. 그래서 기능 요청이나 버그 보고를 받으면, 관련 이슈든 관련 없는 이슈든 내게는 중요함. 항상 바로 작업하진 못해도, 어떤 요청이 더 많은 수요를 받았는지는 마음속에 기록해 둠

그래서 다시 모든 것에 앱이 필요하다는 건가? 스크립트 기능 자체가 실수였다는 데는 동의하지 않음
웹이 운영체제 경계를 넘는 범용 플랫폼이라는 점은 좋다고 봄

• 같은 생각임. 표준화된 파일이나 URL을 네이티브 프로그램으로 여는 장점이 기기에 맞게 최적화되고 “모두에게 하나로 맞추는” 웹페이지 방식을 피하는 것이라지만, Linux 사용자가 2등 시민이던 시절로 돌아가고 싶지는 않음
  Windows만 지원하고 가끔 Mac만 추가되던 시절 말임
• 웹 앱에 대해 불평할 수는 많지만, 모바일 플랫폼에 앱을 배포할 때 Apple 세금과 미래의 Google 세금을 피할 수 있는 거의 유일한 방법이기도 함
  그리고 네이티브 데스크톱 개발 상황도 단순하지 않아서, 데스크톱에서 웹 앱이나 Electron을 택하는 사람들에게 충분히 공감함
• 왜 모든 것에 앱이 필요함? 이 명세가 일반 웹 브라우저 실행을 막는 것도 아니고, 지금의 웹이 사라지는 것도 아님
• 진짜 적절한 지점은 표준화된 마크업만으로 어디까지 할 수 있는지 찾는 것이라고 봄
  현대 웹의 문제는 개념을 끝없이 재발명한다는 데 있고, 그중 상당수는 선언적 마크업이어야 함. 웹사이트 표시 경로에 JavaScript가 끼어들 필요는 없어야 함. 스크립팅은 서버에서 하던 작업을 클라이언트에서 하는 경우, 예를 들어 서버가 반환한 데이터셋을 가공하는 식의 특정 클라이언트 측 프로그래밍에 쓰여야 함
• 사실 이미 모든 것에 앱이 있음. 다만 앱 대신 URL이나 도메인 이름이라고 부를 뿐임
  IT 업계는 Java와 Swing, Flash 같은 샌드박스 대안이 고통스러울 정도로 열등하다는 게 분명해지자 웹 브라우저를 사실상의 가상 머신으로 밀어준 느낌임. 이제는 단일 애플리케이션인 Google Chrome이 사용자 일반 컴퓨팅 대부분의 가상 머신 역할을 하고 있고, 그것도 감시 자본주의 독점 기업이 소유하고 개발함. 이게 진짜 더 안전한지, 아니면 실제 제로데이가 너무 비싸져서 공개되지 않는 것인지는 모르겠음
  스크립팅 추가는 실수였다고 봄. 적어도 나중에 덧붙인 기능이었고, Dillo가 하이퍼텍스트 문서 리더의 범위를 문서 읽기에 두고, 리더 안에서 문서 작성·편집까지 가능하게 하려 하지 않는 데 동의함
  목표는 웹을 기능별로 복제하는 게 아니라, 지식·메모·정보를 교환하기 위해 풀사이즈 가상 머신을 실행해야 하는 요구 없이 읽을 수 있는 명세를 만드는 것임
  더 나은 샌드박스 안에서 대부분의 “상호작용” 요구를 처리하는 축소된 범용 애플리케이션을 보고 싶음. Reddit 같은 소셜 미디어 피드에서 하이퍼텍스트를 주고받는 데 전체 가상 머신이 정말 필요한가? 쇼핑 카트와 결제 정보를 처리하는 데도 전체 가상 머신이 필요한가?
  다만 “범용”이 결국 “애플리케이션”을 집어삼키고, 그 지점에서 웹을 다시 발명하게 될 가능성이 큼. 그래도 Google이 아닌 주체, C++가 아닌 언어가 기반이 될 기회가 있다면 더 나을 수도 있음. Dillo는 C와 C++인 듯하니 둘 중 하나만이라도 나아진 셈인가 싶음

추가로 개선하면 좋을 점은 HTTP 축소판을 쓰되 쿠키는 클라이언트가 제어하는 세션 쿠키만 지원하는 것, 서드파티 리소스를 금지하고 모든 리소스를 문서와 같은 웹 서버에 두는 것, 브라우저 내부 변환기로 text/markdown 같은 형식 렌더링을 요구하는 것임

• 서드파티 리소스 금지만으로도 여러 심각한 문제를 막을 수 있음
• 이상적으로는 전송 방식에 독립적으로 만들고 싶음. 아마 먼저 로컬부터 시도해서 어떤 원격 파일시스템 마운트 지점에서도 동작하게 할 듯함
  이번에는 식단을 개선해서 쿠키를 피할 수 있는지 보자는 입장임. 이건 문서의 기계 표현이며, 사람이 읽을 수 있게 설계됐지만 사람이 직접 쓰기 위한 것은 아님. 대신 Markdown 같은 프런트엔드 언어를 쓰고, 이를 이식 가능한 엄격한 문서로 컴파일하는 방식이 좋음
• 제안하자면 쿠키가 꼭 필요하다면 해당 사이트 도메인에만 적용해야 함. example.net의 쿠키는 sub.example.net에 보내지 않고, sub.example.net의 쿠키도 example.net에 설정되지 않아야 함
  HTTP/2와 HTTP/3는 애플리케이션 웹에 남기고, HTTP/1은 문서 웹에 남기는 편이 좋음. JavaScript를 어떻게 제한해야 “내 콘텐츠를 보려면 전용 브라우저가 필요함” 문제를 피할 수 있을지는 모르겠으니 JavaScript는 없어야 함
  text/markdown 렌더링을 요구한다면 어떤 버전을 말하는지도 문제임. 지원해야 할 변형이 대략 반 다스는 됨

엄격한 문법은 잘 안 될 것임. XHTML이 실패한 이유도 그거고, HTML5가 흔한 “깨짐”을 처리하는 규칙을 추가한 이유도 그 때문임
저자가 원하는 것처럼 HTML5를 더 형식적인 문법으로 다시 명세화할 수는 있겠지만, 페이지를 엄격하게 거부하는 것은 포크의 좋은 활용으로 보이지 않음. 다른 대안은 또 하나의 gopher/gemini 대체물이 되는 것인데, 열성 팬층은 있어도 인기 없는 데는 이유가 있음. 하위 호환성의 힘이 너무 강함

• XHTML이 실패한 이유가 엄격함 때문이라는 데는 동의하지 않음. IE가 2011년까지 XHTML을 지원하지 않은 것이 너무 늦었고, 그래서 사람들이 실제 XHTML을 쓰지 않아 그 이점을 얻지 못했기 때문임
  엄격함은 아주 좋을 수 있지만, 지원이 있어야 작동함

“스크립트 기능 추가가 실수였다”는 생각은 재미를 허용하지 않는 우울한 프로그래머 타입 사이에서 오래된 밈이었지만, 상상력 부족에 가깝다고 봄
신중하게 적용된 상호작용형 멀티미디어는 의사소통과 설명을 크게 향상시킬 수 있음. 예를 들어 Red Blob Games Hex-Grid tutorial의 상호작용 도표나 Bartosz Ciechanowski's fantastic explanation of mechanical watch movement를 보면 됨. 웹의 상호작용 미디어 덕분에 Canon Cat 같은 역사적으로 중요한 희귀 컴퓨터도 네이티브 에뮬레이터를 컴파일하고 실행하는 악몽 같은 절차 없이 링크 클릭 몇 초 만에 써볼 수 있음. 폼 제출과 이미지 맵은 멀티미디어의 극히 희미한 그림자일 뿐이고, 상호작용 지원 부담을 본질적으로 서버 중심이자 잠재적으로 대역폭을 많이 쓰는 모델로 옮김
문제는 스크립트 동작 자체가 아니라, 현재 브라우저에서 스크립트가 할 수 있도록 허용된 일임. HTTP와 HTML을 더 작고 단순하며 사용자 자율성을 존중하는 시스템으로 줄일 수 있듯, 웹 JavaScript의 긍정적인 면 대부분은 유지하면서 API 표면적과 악성 가능성은 크게 줄일 수 있음. 예를 들어 페이지 안에 Flash 같은 상호작용 사각형이 있고, 그 상호작용은 사용자가 접근·검사 가능한 Lua 스크립트와 Love2D 같은 그래픽·입력 기능으로 제공되며, 원격 서버로 연락하거나 웹캠에 접근하는 사생활 침해성 작업은 강한 샌드박스와 사용자의 명확한 사전 동의 뒤에 놓이는 웹을 상상해볼 수 있음
이런 식으로 존중하는 웹 애플리케이션을 오늘날에도 만들 수는 있지만, 기반이 울퉁불퉁하고 일관성이 없으며, 유용한 기능의 명백한 누락과 사용자 안전·사생활에 대한 불필요한 위협이 곳곳에 있음
접근성 관점의 비전으로는, 버튼·필드·체크박스·슬라이더 같은 선언적 UI 입력을 엄격하게 처리하고, 정적 페이지처럼 <iframe> 안에 이미지와 마크업을 렌더링하되 원격 서버 왕복 없이 동작하는 클라이언트 측 폼을 생각할 수 있음. 다양한 계산기, 도구, 상호작용 시각화가 이런 모델에 들어갈 수 있고, 백엔드 주도 모델보다 지연 시간과 사용자 보안이 더 나아짐

“텍스트 우선”이라면 CSS도 내려놓아야 함. CSS는 대체로 사용자가 아니라 회사를 위해 존재함. 스타일은 페이지가 아니라 브라우저가 제어해야 함
사용자가 원시 페이지 페이로드를 읽기로 했다면, 그 대부분이 브라우저가 읽으라고 보여준 정보와 같아야 함. 오늘날 읽을 수 있는 콘텐츠는 빙산의 일각일 뿐임
“스크립팅 없음”에 대해서는, 스타일과 부피 큰 페이지를 제거하면 표시 방식에 영향을 주는 스크립팅 필요도 크게 줄어들 수 있다고 추측함. 표시 방식에 영향을 주지 않는 스크립팅은 대체로 사용자 이익에 반해 쓰여 왔음

• 그게 원래 CSS 캐스케이드의 핵심이었음. 책과 논문 서식에 쓸 수 있는 합리적인 CSS 부분집합이 있고, 사용자 스타일과 병합되도록 되어 있었음
  하지만 CSS와 서식이 지나치게 복잡해졌고, 사용자 스타일은 이제 전체 CSS 리셋으로 시작하거나 사이트별로 매우 구체적이어야 함
• 독자의 시간대에 맞춰 타임스탬프를 표시하고 싶다면, 현재는 클라이언트 측 스크립팅 없이는 방법이 없음
  클라이언트에 JS 없이 개인용 도구를 만들다가 이 문제를 겪었고, 서버에 “내 시간대 설정”을 두거나 작은 보조 스크립트를 추가해야 한다는 걸 깨달았음
  스타일을 브라우저가 제어하게 하면 “내 페이지는 브라우저 X와 Y에서는 읽을 만한데 Z에서는 안 읽힘” 같은 문제가 지금보다 더 심해질 수도 있어 보임
• CSS가 가득한, 색상과 화려한 배경, 좋은 글꼴, flexbox와 grid 레이아웃이 있는 세상에서 행복하게 살겠음
  저자의 목소리를 흰 배경의 검은 텍스트로 씻어내린 밋밋한 문서만 보는 쪽보다는 낫다고 봄. CSS는 웹에서 저자의 표현 방식이며, 정말 없애고 싶지 않음. 복잡하긴 하지만, 더 많은 개인이 자기 웹사이트에서 재미있는 일을 할 수 있게 해주므로 오히려 좋은 점이라고 봄
• 동의함. 선택적 저자 스타일을 금지하기 전에 더 조사해봐야 함
  스타일과 부피 큰 페이지를 제거하면 표시를 바꾸는 스크립트 필요가 줄어들 것 같다는 감각도 비슷함. 단순한 문법이 있으면 상호작용형 네이티브 프로그램 안에 “문서”를 임베드할 수 있고, 그 반대가 아니게 될 수도 있음

다른 사람들이 말하듯 Gemini는 참고할 좋은 예라고 봄. 다시 말하지만 Gemini는 퍼포먼스 아트 같지만, 배울 점이 정말 많음
Gemini에서 충분히 알려지지 않은 주목할 기능 하나는 구독 가능한 페이지임. 페이지 안에서 텍스트가 YYYY-MM-DD로 시작하는 링크들이 암묵적 피드를 이룸. 매우 제한적이고 멍청해 보이지만, Gemini의 가장 인상적인 기능 중 하나라고 봄. Spec here
전통적인 HTML에서는 블로그를 손으로 쓰는 게 가능함. 지루하긴 해도 충분히 할 수 있음. 하지만 RSS/ATOM 피드를 유지하려면 거의 반드시 피드 생성 도구가 필요함
차세대 “콘텐츠 지향” HTML이라면 비슷한 기능을 넣는 게 좋음. 아마 h-feed in microformats가 맞는 방식일 수도 있지만, Gemini의 구독 가능한 페이지가 주는 단순함이 정말 좋음. 그리고 어디에나 있는 피드는 좋은 것임
Gemini가 줄 단위이고 파싱하기 쉬운 것은 큰 장점이지만, 너무 제한적이고 접근성 측면에서 나쁜 영향을 줄 수도 있다고 느낌. 그래도 Gemini처럼 보이는 HTML-lite가 있다면 괜찮을 듯함
웹 포크가 얻을 수 있는 또 다른 이점은 HTML에 덧붙여진 부분들을 정리하는 것임. <meta name="viewport" content="width=device-width, initial-scale=1.0"/>는 꽤 거슬림. 오늘날 아는 것을 바탕으로 새 버전을 만들면 꽤 괜찮을 가능성이 큼
다른 부분은 확신이 덜함. 원칙적으로는 JS 없음에 완전히 찬성함. 다만 웹의 최고 활용 중 하나는 정부, 은행 같은 필수 서비스에 대한 범용 접근이라고 봄. 좋은 사용성을 유지하면서 정말 모든 것을 JS 없이 할 수 있을지는 아직 완전히 확신하지 못하겠지만, 가능할 수도 있음
another comment의 “이 명세가 일반 웹 브라우저 실행을 막는 건 아니고, 지금의 웹이 사라지는 것도 아니다”라는 부분도 강조하고 싶음
“콘텐츠 웹 브라우저”와 “앱 브라우저”를 따로 실행할 수 있으면 좋겠음. 많은 목적에서 앱 플랫폼으로서 웹만큼 좋은 대안은 많지 않고, 웹은 많이 발전했으며 개발자들도 다른 것보다 웹을 훨씬 선호하는 듯함
이런 세상에서는 Google Maps가 내 콘텐츠 웹 브라우저에서 동작하지 않고 앱 브라우저에서 열릴 것임. GMail을 앱 브라우저에서 실행하면 이메일 안의 링크는 콘텐츠 웹 브라우저에서 열리게 됨
콘텐츠 웹 브라우저는 이상적으로 훨씬 구현하기 쉬워야 하고, 그러면 경쟁과 혁신이 촉진될 것임. 하지만 이를 실현할 경로는 잘 보이지 않아 아쉬움. 그런 콘텐츠 브라우저로 모든 콘텐츠 탐색을 할 수 있다면 훨씬 행복할 듯함. 공격 표면이 훨씬 작아져 보안 면에서 더 편안할 테니까. 하지만 이제 아무도 신경 쓰지 않는 것 같음

• 웹페이지에서 JS의 정당한 사용 사례는 거의 전부 브라우저에 중요한 기능이 빠져 있어서 생김. 수십 년 동안 배워 왔고, 스크립트 덕분에 브라우저는 그 기능들을 굳이 추가하지 않아도 됐음
  그러니 그냥 브라우저 기능으로 추가하면 됨

Gemini와 조금 비슷하게 들리지만, 이 포크는 좀 더 많은 것을 허용할 듯함
웹사이트는 Markdown 변형이나 비슷한 무언가로 쓸 수 있다고 봄. 원시 형태로도 쉽게 읽을 수 있는 문서여야 함. Gemtext에 인라인 미디어 같은 기능을 조금 더한 형태 말임
그리고 약간의 스타일 기능도 허용해야 함. 웹은 창의성을 발휘하기에 훌륭한 장소였고 지금도 그럼. 단순하고 일관된 스타일 집합을 유지하면 창의적인 사람들이 더 기발한 사이트를 만들 수 있음

HTMX의 기본 요소도 다루면 좋겠음

• 개인적으로는 Triptych 원시 기능만 내장하면 좋겠음. 클라이언트를 과도하게 복잡하게 만들지 않으면서 서버 측에서 빌드하기에 충분한 정도를 제공함

이 아이디어는 명확한 동기가 있으면 더 잘 작동할 것임. “단순하게 만들자”는 너무 추상적임. 사람마다 단순함에 대한 생각이 다르기 때문에, 왜 웹이 더 단순해야 하는지, 어떤 구체적 필요를 충족하는지 더 명시적인 목표가 필요함
예를 들어 Gemini 프로젝트는 특정한 형태의 소통을 중시하는 커뮤니티를 만드는 데 초점을 둠. 그 커뮤니티의 목표에 맞기 때문에 웹을 그 소통 형식으로 제한해 단순화했고, 이미지조차 기술적으로는 지원하지 않는 것으로 기억함
반면 Sciter나 Blitz 같은 도구는 다른 애플리케이션에 브라우저 비슷한 렌더러를 더 쉽게 임베드하는 것을 목표로 함. 이들은 불필요한 특이 동작을 제거하거나 HTML 파싱, JS 실행을 선택 사항으로 만들어 단순화함. 그러면 구현할 것도 줄고 사용자가 임베드할 것도 줄어듦
둘 다 단순함을 목표로 하지만, 근본 목표가 매우 다르기 때문에 결과도 매우 달라짐. 여기서의 근본 목표는 무엇인가?

gofmt에도 비슷한 서식 유도 동작이 있었던 것으로 기억하고, 그런 포매터가 rustfmt보다 더 마음에 듦
그래도 포매터가 아예 없는 것보다는 어떤 형태의 서식 자동화라도 있는 편이 낫다고 봄

• “포매터가 없는 것보다 뭐든 있는 게 낫다”는 말은 그냥 넘기기 어렵다
  자동 포매터는 평범함을 강제하고, 서식을 못 쓰는 사람들을 끌어올리지만 잘 쓰는 사람들도 끌어내린다
  협업할 때 다른 사람들이 원하거나 그들의 개인 서식 규율을 신뢰하기 어렵다면 쓰겠지만, 혼자 작업할 때는 절대 쓰지 않음
  내 취향도 있고 포매터의 취향도 있는데, 둘은 화해 불가능하게 다르다
  다만 이 글에서 보여준 내용 자체는 인상적임
  그 문장은 Fiddler on the Roof에서 중매쟁이 Yente가 “나쁜 남편이라도—신이여 막아주소서—남편이 없는 것보다는 낫다!”라고 한 대사를 떠올리게 함
• 기억하기로 Elm 포매터도 비슷하게 동작했고, 원래 서식을 고려하지 않는 포매터들에 비해 꽤 좋게 느껴졌음
• 일부 C++ 프로젝트에서 clang-format을 쓰는데 끔찍함
  버전 간 안정성이 너무 낮아서 clang-format 업그레이드가 코드 모든 줄을 건드리는 서식 커밋으로 이어짐
  포매터가 없는 것보다 나은지 정말 확신이 안 듦
• 예전에는 “어떤 포매터든 없는 것보다 낫다”고 오래 생각했지만, 최근에는 완전히 생각이 바뀜
  자동 포매터는 주로 풀 리퀘스트에서 자전거 헛간 논쟁을 없애는 사람 문제를 해결함
  그런데 이제 에이전트형 개발로 넘어가면서 그 문제는 점점 덜 중요해짐
  지금 여러 프로젝트에서 기계가 대부분의 작업을 하고 있는데, 그렇게 되면 포매터를 돌리지 않는 편이 더 낫다는 쪽으로 느껴짐

Python에서 명령줄 인자를 만들 때는 튜플을 리스트에 스플랫하는 방식을 좋아해서, 글의 마지막 예제는 이렇게 쓸 것 같음

[  
  "aws",  
  "s3",  
  "sync",  
  path,  
  url,  
        *("--include", "*.html"),  
  *("--include", "*.xml"),  
  *("--metadata-directive", "REPLACE"),  
  *("--cache-control", "max-age=0"),  
]  

마지막으로 봤을 때 zig fmt에는 80열 제한을 100열 제한 대신 쓰도록 설정하는 방법이 없었는데, 아직도 그런가?
하루에 여러 시간 작업하면 눈이 덜 피로해서 터미널 글꼴 크기를 키워 쓰는데, 80열과 100열 차이는 vim 분할 두 개와 nerd tree를 나란히 둘 수 있느냐를 가름함

• zig fmt에는 열 제한이 없음

포매터가 전혀 없던 팀에 rigid formatter를 도입한 사람으로서, 가끔은 수동으로 서식에 영향을 줄 수 있는 능력이 그리움
그런 면에서 Zig가 유연한 건 정말 멋짐

훌륭하다!
이런 식의 TS/JS 포매터가 있을까?
maplibre-gl을 쓰는 프로젝트가 있는데 스타일 명세 표현식이 가끔 너무 과하게 서식화돼서 아무것도 안 보임
지금은 포매터 사용을 멈췄지만, 디버깅하고 복사하고 주석 처리하다 보니 코드가 지저분해지고 있음
어쩌면 Zig 포매터를 다른 언어도 포매팅하도록 만들 수 있을지도 :)

• Prettier에도 비슷한 기능이 있지만, 구체적으로는 객체 리터럴에 한정되고 “한 줄에 전부”와 “각 요소를 다른 줄에” 중에서만 고를 수 있음
  예를 들어 한 줄에 네 요소씩 두라고 포매터에 지시할 방법은 없음
  또한 객체 리터럴이 너무 길어지면 입력 텍스트가 어떻게 되어 있든 Prettier가 결국 “각 요소를 다른 줄에” 형식으로 바꿔버림

가벼운 방식의 포매터, 사실상 줄바꿈만 하는 포매터에는 실망한 적이 있어서, 더 엄격한 예시 안에서 이런 유연성을 갖는다는 발상이 부럽고 마음에 듦 :p
최근 fedi에서 비례폭 글꼴로 Lisp를 작성하고 서식화하는 질문에 답하면서, 의미 있는 공백을 쓰는 s-expression 변형들, 즉 wisp, Readable/Sweet expressions, SRFI 119와 110을 짚었음
이 문법 계열은 선택적 중위 표기 확장을 활용해 줄바꿈에 대한 제어권을 일부 돌려준다는 관찰도 덧붙였음

흥미로운 설계지만 마음에 드는지는 잘 모르겠음
내 포매터에서는 다르게 처리함: 포매터가 후행 쉼표를 무시하고 서식을 결정한 뒤, 여러 줄로 나뉘면 항상 후행 쉼표를 추가하고 한 줄이면 항상 후행 쉼표를 제거함
그래서 “유도”는 못 하지만 f(1, 2, 3)은 후행 쉼표 유무나 토큰 사이 공백의 양과 종류와 관계없이 일관되게 포매팅됨
어느 정도의 유도는 필요함
예를 들어 긴 리스트 리터럴 [<expr1>, <expr2>, ..., <expr100>]이 있으면 대부분의 포매터는 각 표현식을 한 줄에 하나씩 두겠지만, 가능한 한 많이 한 줄에 넣고 싶을 수 있음
이 둘을 후행 쉼표로 결정하는 건 이상하다고 보고, 일반적으로는 선택지가 2개가 아니라 N개일 수 있음
이런 목적에는 속성이 더 잘 맞는다고 생각함
예를 들어 이미 있을지도 모르지만, 문장 앞에 #[rustfmt::list_layout(flow)] 같은 것을 붙여 해당 문장 안의 리스트 리터럴 서식에 영향을 주는 식이 가능함
유도가 너무 많으면 전체 생태계의 코드 서식을 일관되게 만들고 코드 리뷰를 쉽게 하는 포매터의 목적을 해치므로 제한된 경우에만 해야 함
긴 리스트 리터럴은 정말 필요한 예라고 봄
내 프로젝트에도 테스트 기대값 리뷰에 서식이 도움이 되는 예가 있는데, 여기가 그렇다
Dart 포매터에도 다른 “유도” 동작이 하나 떠오름: 긴 리스트 리터럴에서 주석 줄을 추가해 줄들을 그룹화할 수 있음
예를 들어 [1, 2, 3, ..., 1000]이면 각 요소를 한 줄에 하나씩 두지만, 수동으로 이렇게 그룹화할 수 있음

[1, 2, 3, 4, 5,  //  
 6, 7, 8, 9, 10, //  
 ...]  

이런 기능을 의도적으로 넣은 것인지, 주석 처리 방식에서 나온 부산물인지는 모르겠음

• 그 방식이 정확히 rustfmt의 동작이고, 그게 미치게 만듦
  가끔은 줄 길이 제한을 넘기더라도 함수 호출을 나누지 않는 편이 더 읽기 좋은 경우가 있고, 거기에 대한 내 판단을 반영할 수 있으면 좋겠음
  떠오르는 한 가지 사례는 OpenGL임
  보통 하나의 리소스를 수정하거나 사용하면서, 예를 들어 텍스처 초기화처럼 gl.* 호출을 연속으로 많이 하게 되는데 rustfmt는 “줄이 너무 김. 줄을 쪼개야 함”이라는 로봇 같은 목적 말고는 아무 감각 없이 밀어버림
  이 예제는 동작을 보여주기 위한 인위적인 것이고 실제 rustfmt 동작과 완전히 같지는 않음
  줄도 그렇게 길지는 않음
  지금 휴대폰으로 쓰고 있어서 100% 정확한 예제를 만들 도구가 없음

  gl.bind_texture(gl::TEXTURE_2D, tex);  
  gl.tex_parameteri(gl::TEXTURE_2D, gl::TEXTURE_MIN_FILTER, gl::NEAREST);  
  gl.tex_parameteri(gl::TEXTURE_2D, gl::TEXTURE_MAG_FILTER, gl::NEAREST);
  
  // -->
  
  gl.bind_texture(gl::TEXTURE_2D, tex);  
  gl.tex_parameteri(  
      gl::TEXTURE_2D,  
      gl::TEXTURE_MIN_FILTER,  
      gl::NEAREST,  
  );  
  gl.tex_parameteri(  
      gl::TEXTURE_2D,  
      gl::TEXTURE_MAG_FILTER,  
      gl::NEAREST,  
  );  
  

  이런 식으로 이어지는 gl.tex_parameteri 호출을 여러 줄로 쪼개는데, 사실 각 호출은 한 줄에 완전히 펼쳐 두는 편이 더 낫다
  열이 맞춰지면 두 줄의 차이를 훨씬 쉽게 찾을 수 있기 때문임
  쪼갠 버전은 시각적 근접성이 떨어지고 읽기 더 어렵다
  눈으로 두 줄을 쉽게 비교할 수 없게 됨
  또 줄을 문자 수 제한 안에 맞게 포매팅할 수 없을 때 완전히 실패하는 우스운 일도 생김
  컴파일러 코드를 쓰며 문자열 리터럴로 진단 메시지를 만들 때 이런 일이 자주 일어나는데, 메시지가 꽤 길어질 수 있음
  rustfmt는 이를 어떻게 나눌지 몰라서 포기하고 해당 문장 전체를 포매팅하지 않음
  흔히 이런 식임

  match something {  
      // ... match arms above this one ...  
      _ => emit_diagnostic(&mut state, "This is a very long message to try and illustrate the problem. Help: please consult a doctor.")  
  }  
  

  여기서 emit_diagnostic 호출이 표현식일 뿐이라는 이유로 전체 match 문의 포매팅을 포기하는데, 그냥 어리석다
  내 코드를 최대 100열로 밀어붙이려 하지 않았다면 전부 피할 수 있었음

끝부분의 코멘트를 보고 나처럼 찾아봐야 했던 사람을 위해 적자면, ++는 배열 연결 연산자임
그래서 배열을 두 개로 나누면 서로 다르게 포매팅할 수 있음

Antirez의 "Don't fall into the anti-AI hype" [0]가 떠오름
한 줄로 요약하면, 이런 기반 모델은 “행렬 곱을 더 빠르게 하라”처럼 매우 고수준이면서도 매우 잘 정의된 문제 공간을 최적화하는 데 정말 강함. Antirez의 경우는 “Redis를 더 빠르게 하라”였음
반응은 “내 일에는 절대 안 통할 것”과 “몇 달 걸릴 일을 한 시간 만에 끝냈다”로 갈렸고, 둘 다 맞다고 봄. Antirez가 이후에도 성과를 내는 건 기뻐할 만하지만 [1], 대부분의 사람이 하는 암묵지 많고 인간 시스템 중심이며 모호하게 정의된 일은 LLM이 다루기 어렵거나 애초에 그런 용도가 아니었을 수 있다고 봐도 된다고 생각함
[0] https://antirez.com/news/158
[1] https://antirez.com/news/164

• 솔직히 이제는 그렇게 믿지 않음. 모델들이 모호성을 꽤 잘 다루기 시작했고, Claude Code는 모호한 부분이 있으면 이제 나에게 질문함
  곧 모든 회의가 녹음·전사되어 에이전트가 모호함을 마주했을 때 검색할 수 있는 잘 색인된 장소에 저장될 것임. 지금 질문할 수 있다면, 그런 환경이 갖춰졌을 때 스스로 답을 검색할 수도 있게 됨. 사실 문서화가 잘 된 Notion/Confluence가 있으면 이미 그렇게 하며, 다만 그런 조직이 거의 없을 뿐임
  “모호성 식별”을 강화학습시키는 건 성능 알고리즘을 강화학습시키는 것보다 어렵겠지만 불가능하지 않고 이미 진행 중이라고 봄. 이제 시간 문제임
• Claude 등은 내가 생각한 알고리즘을 빠르게 구현하는 데 꽤 좋았음. 다만 통제 질문을 많이 하고 코드를 확인해야 함
  비주류 알고리즘을 새로 발명하는 데는 약하고, 어이없을 정도로 단기적인 지름길을 끼워 넣는 경우가 잦음. 아직은 도구이지 도구를 능숙하게 다루는 장인은 아님. 이건 점차 바뀔 것이고, 드문 알고리즘이 이기는 구석도 더 줄어들 것임
• 결국 요인은 둘 중 하나처럼 보임: “놀랍다, 효율을 1% 개선했다” 또는 “멍청하게도 환각 API를 디버깅하느라 한 시간을 날렸다”
  평균적으로 어느 쪽이 이길지 판단하기가 정말 어려움
• AI 보조 연구가 AI를 LLM 너머로 밀어 올리면 어떨까? 그런 일이 일어날 수 없다고 보는 건가?
• “LLM이 암묵지 많고 인간 시스템 중심이며 모호하게 정의된 일을 못 한다”는 말은 2030년쯤이면 굉장히 근시안적으로 보일 가능성이 큼

AI CEO들은 AI가 암을 치료할 거라며 장광설을 늘어놓기 좋아하지만, 실제로 그런 연구 문제에 적극적으로 매달리는 곳은 DeepMind뿐인 것 같음
OpenAI와 Anthropic은 대체로 기업 매출과 코딩 매출을 좇는 쪽으로 보임

• Google은 전쟁자금으로 자체 조달이 가능하지만, OpenAI와 Anthropic은 투자자에게 손 벌리는 처지임

Googler들은 Claude Code나 Codex 대신 Gemini 코딩 에이전트를 쓰는 걸 만족해하나? 비꼬는 게 아니라 정말 궁금함

• 그렇다. 모델은 좋고 빠르며, 내부 도구도 이제 따라잡았음
  아직 UI/UX/도구 쪽에서 정리 중인 부분, 버전 관리 시스템 연동, 말하기 어려운 더 깊은 문제들이 있지만, 대부분의 불만은 실제 능력보다 변화 속도에 더 가깝다고 봄
  흥미로운 건 내부에서 영향력 있는 여러 사람이 Pro 모델보다 Flash 모델을 더 선호한다고 강하게 말한다는 점임. 이게 사실인지와 별개로, 이제 “더 나은” 모델이 반드시 더 유용한 건 아니며, 더 빠른 모델과 하네스 개선을 조합하는 쪽이 더 나은 절충일 수 있는 단계에 왔다는 게 흥미로움
• Gemini VS Code Extension을 말하는 거라면 Claude Code나 Codex에 비해 형편없음. 어떻게 이 상태로 운영되는지 모르겠음
  계속되는 시간 초과, 이상한 실패 모드, 모드를 바꾸려면 새 채팅을 시작해야 하는 문제 등이 있음. 다만 이건 Gemini 모델 자체의 문제라기보다는 확장 프로그램 문제로 보임
  VS Code 확장 측면을 빼고 실제 문제 해결만 보면, 세 프리미어 모델 모두 내 용도에는 훌륭한 코딩 에이전트임
• 코딩은 Gemini나 이런 모델들의 유일한 용도가 아님. 이 글이 다루는 것도 코딩이 아님
  Gemini가 최고의 코딩 에이전트가 아닐 수는 있지만, 다른 일에는 매우 좋을 수 있음
• 지난달 Steve Yegge는 그렇지 않다고 시사했음: https://xcancel.com/Steve_Yegge/status/2043747998740689171
• Google에 있는 사람들과 이야기해 보면, 대부분 내부 Gemini 에이전트에 불만이 있었고 최근 들어 상당히 나빠졌다고 보는 듯함
  도구 호출 방법을 완전히 잊고 한참 시간을 낭비하다가 결국 포기하거나, AGENTS.md 비슷한 파일의 코드 스타일 지침을 완전히 무시하는 식임
  Gemma 4를 로컬에서 돌린 내 경험도 비슷했음. 도구 호출을 한두 번 한 뒤에는 제멋대로 호출하기 시작함. 바로 어제도 read_file(start, end) 같은 도구를 read_file(start, number_of_bytes)로 재정의해 놓고, 자신이 틀렸다는 가능성조차 인정하지 않는 걸 봄

AI가 스스로, 또는 적어도 자신이 돌아가는 아키텍처를 개선한다면 사람들이 말하듯 특이점이 가까운 셈임
합성 데이터 생성이나 모델 테스트 외에, AI가 LLM을 개선하는 데 쓰인 다른 사례가 있을까?

• AI가 스스로를 더 유능하게 만드는 것과, AI 학습·추론에 쓰이는 소프트웨어를 최적화하는 것은 사과와 오렌지만큼 다름
  더 효율적인 트랜스포머는 실행 비용을 낮출 뿐임
  “AI가 AI를 개선한다”라고 하려면 한 세대의 AI가 자신보다 근본적으로 더 유능한 차세대 AI를 설계해야 함. 단지 더 빠르거나 싸게 만드는 게 아니라, 파충류 뇌가 포유류 뇌를 자율적으로 설계하는 수준이어야 함
  AlphaEvolve 같은 똑똑한 하네스에 연결해도, LLM에 그런 창의성이 있다고 보지는 않음. 다만 차세대 아키텍처가 LLM이 예측하도록 유도할 수 있는 부품 조합으로 뻔히 숨어 있다면 예외일 수 있음
  더 가능성 높은 경로는 AGI를 향한 인간 혁신이 몇 단계 더 진행된 뒤, 프롬프트 기반 조합 생성이 아니라 자율 혁신을 할 수 있는 AI가 나오는 것임
• 있음. 작년에 AlphaEvolve를 공개했을 때 이전 Gemini 모델로 이번 세대 모델 학습에 쓰이는 커널을 개선했고, 학습 실행을 1% 빠르게 만들었음. 크지는 않지만 그래도 성과임
• 최근 가장 바이럴된 건 https://github.com/karpathy/autoresearch 같음
• 자기 개선이 꼭 특이점을 뜻하지는 않지 않나?
  특이점을 불가능하게 만들 정도의 강한 제약이 있을 수도 있고, 시간 지평이 너무 길어서 실용적이지 않을 수도 있지 않나?
• “AI가 스스로 개선한다”는 건 개인적으로 2027년에 봐야 할 지점이라고 생각함
  모든 대형 AI 연구소가 연구 에이전트, 특히 AI 개선을 위한 에이전트 프로젝트를 크게 진행 중이고, 올해 그중 상당수가 실험 단계를 벗어날 것으로 예상함
  내년에는 실제로 많은 일을 하게 될 것이고, AI가 공동 발명한 첫 번째 큰 유효 아키텍처 변화가 나올 거라고 봄

Erdős 문제 얘기를 또 몇 번이나 들어야 하나 :) 처음엔 인류의 대단한 성취처럼 들리지만, 시간이 지나면 계속 다시 돌아옴

• 아직 열린 Erdős 문제가 700개 정도밖에 안 남았으니, 전부 풀리면 드디어 쉴 수 있음

그 와중에 Gemini CLI는 몇 달째 망가져 있음
https://github.com/google-gemini/gemini-cli/issues/22141

Google이 Gemini 3.x 모델을 정식 출시하는 데 집중하고, 429 오류와 계속 싸우지 않아도 될 만큼 충분한 용량을 제공해 줬으면 함
Vertex API로 기업 고객용 애플리케이션을 개발하지 말라는 것처럼 느껴질 때가 많음. 문서 분석 등에서 모델이 정말 훌륭했던 걸 생각하면 아쉬움이 큼

• 무료 요금제에서 하는 건가? 무료 요금제에서는 429를 훨씬 더 많이 내는 걸 봤음

모든 *Evolve 논문은 결과가 매우 인상적이지만, 공개된 정보를 살펴보며 느낀 건 관심이 LLM과 AI 쪽에 쏠린다는 점임
그런데 보고된 성과는 거의 항상 LLM과 진화 알고리즘이 잘 작동하도록 매우 잘 설계된 환경의 결과임
이 논문이 그 좋은 예이고 읽어볼 만함
Magellan: Autonomous Discovery of Novel Compiler Optimization Heuristics with AlphaEvolve
https://arxiv.org/abs/2601.21096

알고리즘 개선을 위한 굉장히 단순한 해법임. 활성화 엔지니어링을 하던 몇 년 전에 이런 게 있었으면 좋았겠음: https://blog.n.ichol.ai/llm-activation-engineering-an-easy-f...
AlphaEvolve에는 어떻게 접근할 수 있나?

• 그냥 과시용 글임. 10억 달러 회사가 되거나 아니면 나가라는 뜻임

Claude에서 느낀 문제는 간단한 작업에도 코드와 산출물을 지나치게 부풀려 내고, 때로는 작동하지도 않는다는 점임
Gemini는 작동하는 해법을 딱 필요한 만큼의 코드와 최소 복잡도로 제공해서 관리하기 더 쉬운 균형을 꽤 잘 맞춤
요즘 Claude를 찾는 건 프런트엔드 코드, 특히 HTML 정도임. 여기서도 CSS 코드가 너무 많아 파일 크기의 60%쯤을 차지하지만, 그래도 조금 더 다듬어진 느낌을 주기 때문에 파일 크기가 커지는 건 감수하고 있음

https://archive.is/JUPmz

흐름은 이렇다: Zuck이 어떤 아이디어를 떠올리면, 주변의 예스맨들이 “맞습니다, 이건 세상을 바꿀 겁니다”라고 하고, 이후에는 반지에 입 맞추는 보여주기 게임으로 변함
“Metaverse에 어떻게 800억 달러를 날릴 수 있었지?”라고 묻는다면, 바로 이런 식임
Meta에 합류하지 말라. 채용 담당자가 아무리 빨리 답해도, 일이 아무리 멋져 보여도 마찬가지임. 팀 매칭에서 매니저들이 거짓말을 함. 평균 재직 기간이 2년 미만인 데는 이유가 있음
유해하고 공포에 기반한 문화임. 들어가면 주변 사람들은 이미 당신을 희생양으로 삼을 생각을 하고 있음. 실제 일은 정치적으로 유리한 사람들에게만 잠가두고, 바깥에 있는 사람들은 그럴듯한 헛프로젝트를 만들어내야 함. 스스로 일을 찾아내도 곧바로 그 일을 빼앗으려는 정치질이 시작됨

• 아니면 Meta에 들어가서 영혼을 팔고, 7년 버틴 뒤 은퇴해서 영원히 일을 끝내는 방법도 있음
• 추측인지, 아니면 직접 겪은 일인지 궁금함

경영진은 약한 노동시장을 보고 골치 아픈 엔지니어들을 마음껏 해고할 수 있다고 상상함
특히 최근 몇 년간 기술 기업 경영진은 부모의 부가 입학 가능성을 크게 좌우하는 일부 엘리트 대학 출신이 대부분이었고, 지금처럼 노동을 극도로 경시하는 분위기가 놀랍지 않음
수년간 교육받은 엔지니어들을 육체노동자처럼 대체 가능한 존재로 보는 시도는 반복됐고, 결과도 늘 같았음. LLM이 그걸 바꾸지는 못함

지식노동에서 AI를 쓰는 데 대한 더 넓은 사회적 규범이 빠져 있는 듯함
얼마 전 직장에서 누군가 Teams로 엄청난 양의 텍스트를 전달했음. 평소에는 선의가 있지만 단어마다 맞춤법 오류가 하나씩 있고 메시지도 20단어를 거의 넘기지 않던 사람이었는데, 명백히 ChatGPT 복붙이었음
HN 사람들처럼 문맥 전환, 정보량 같은 관점으로 생각하는 사람에게는 이 상황의 문제가 뻔하지만, 일반 대중에게는 전혀 뻔하지 않다는 걸 깨달음. 그 사람은 15초 동안 프롬프트를 입력하고 내가 30분 동안 AI 잡탕을 풀어내게 하는 게 진심으로 도움이 된다고 생각한 듯함
이런 일에 대해 무엇이 허용 가능한 관행인지에 대한 이해나 합의가 아직 사회 규범에 전혀 들어와 있지 않음

• AI 덕분에 정보를 만드는 비용은 낮아졌지만, 이제 그 정보를 해석하는 데 더 많은 시간이 들어감
  덜 유능하거나 덜 유용한 사람들이 더 적은 시간으로 더 많은 정보를 만들고, 더 유용한 사람들이 그걸 해석하느라 더 귀한 시간을 쓰는 구조가 됨. 그래서 대부분의 조직에서 LLM이 순이익이 될 수 있을지 회의적임
• 기본 원칙은 AI가 생성한 내용을 커뮤니케이션에 그대로 복붙하지 않는 것임. 그게 선이라고 봄
  뒤에서 무엇을 쓰든 상관없지만, 전달되는 건 본인의 생각을 종합한 결과이길 원함
  그렇지 않다면 많은 사람이 말했듯이 그냥 프롬프트를 보내면 됨. 동료가 무언가를 전달하는 데 어려움을 겪고 있다는 사실을 아는 편이 오히려 더 흥미롭고 낫기도 함
• “15초 프롬프트로 만든 걸 내가 30분 동안 풀어야 한다”는 게 직장 전반으로 퍼지는 핵심 좌절감임
  AI 이전에는 설계 문서, Jira 티켓, 풀 리퀘스트를 만들려면 적어도 그 사람이 자기 시간과 노력을 꽤 들였다는 전제가 있었음
  LLM이 그 전제를 지워버림. 이제 이메일, 12쪽짜리 설계 문서, 100줄 또는 1000줄짜리 풀 리퀘스트, Jira 티켓 10개가 누군가 시간을 들여 만든 건지, 아니면 AI 구독으로 그럴듯하게 뽑아낸 건지 알 수 없음. 실제로 읽고 처리해야 하며, 그 비용은 만든 사람의 노력보다 100배 큼
  직장을 자기 노력과 가치 있어 보이는 외관 사이의 최적화 게임으로 보던 사람들에게 LLM은 완벽한 지름길임. 몇 줄 요청만으로 많은 일을 한 것처럼 보이는 문서를 만들 수 있음
  누군가 15초 프롬프트에서 나온 AI 잡탕을 30분 들여 검토하면, 그 피드백을 ChatGPT에 붙여 넣고 수정된 문서를 다시 보낼 것임. 그러면 당신까지 그 사람 일을 대신하게 된 셈임
  활동의 외관을 기여의 대리 지표로 삼던 팀이나 회사에는 어려운 전환이 될 것임. 전 세계의 이메일 기반 사무직은 자기 일을 한 것처럼 보이는 결과물을 만들어주는 도구를 얻었고, 대부분 그럴듯하게 맞을 수도 있음. 한 사람이 수많은 설계 문서와 Jira 티켓을 만들고 회사 Slack에 재치 있는 답변까지 복붙하면서, 실제 일은 그 어느 때보다 적게 하면서도 가장 적극적이고 헌신적인 직원처럼 보일 수 있음
  이미 좋은 리뷰 문화가 있고 매니저가 지표보다 산출물을 신경 쓰는 팀은 괜찮을 것임. 조금만 들여다봐도 AI 복붙 직원은 드러남. 문서를 훑고 풀 리퀘스트 수나 코드 변경 줄 수를 그래프로 그리던 게으른 매니저들은, 자기 게임에서 상위권인 직원들이 팀에 가장 큰 피해를 주고 있다는 걸 깨닫고 충격을 받을 것임
• 현재 기준은 “내가 사람에게서 답을 기대하고 있다는 걸 알면, 편집하지 않은 ChatGPT 출력을 붙여 넣고 보내지 말라”는 것임
  모두가 자기 꼼수의 산출물은 보내고 싶어 하지만, 받는 건 싫어함
  대부분은 자신이 그렇게 하고 있다는 걸 알고 있음. LLM 사용을 숨길 필요를 느낀다면 최종 초안에 자기 목소리와 작업이 충분히 들어가지 않았다는 뜻이고, 그걸 고쳐야 함
• 고객 지원 티켓에 참조로 들어가 있으면, 지원 담당자가 내가 이미 읽을 수 있는 고객의 단일 이메일을 명백한 AI 요약으로 다시 보내는 일이 있었음
  도우려는 의도라는 건 알지만, 나를 아이나 바보로 보는 것처럼 느끼지 않기 어렵다. 예전에는 누군가를 위해 검색해주는 게 무례하다는 합의가 있었고 letmegooglethatforyou.com이 좋은 예였는데, 왜 AI 요약과 잡탕은 같은 방식으로 이해되지 않는지 모르겠음

Meta의 해고를 언급하는데, 직원 사기에 더 큰 영향을 주는 건 AI보다 정리해고일 가능성이 큼
현재 기술 기업 해고에 대한 가설은 이렇다. 지난 10년쯤 동안 스택 랭킹처럼 이직률을 유발하는 관행이 유행에서 벗어났음. 이유는 추측할 수 있음. 세대 변화 때문에 중간관리자가 더러운 일을 하기 싫어졌을 수도 있음. 어쨌든 그런 변화는 일어났음
하지만 회사들은 여전히 저성과자를 제거하고 싶어 하고, 어떤 이들은 그게 필요하다고도 봄. 그래서 이제는 주기적으로 전사적 인력 감축을 하고, 그때그때 편한 명분을 붙임. 거시경제 상황이든 AI든 무엇이든 가능함
이 가설은 회사가 해고 중이나 직후에 공격적으로 채용하는 현상, 그리고 해고가 해마다 반복되는 이유를 설명해줌

• 걱정하지 않아도 됨. 기술 기업에서 스택 랭킹과 인력 회전은 여전히 아주 유행 중임

Mark는 유출자를 싫어하는데, NYT가 아마 수십 명의 실무자와 직통선을 가진 것처럼 보이는 건 꽤 웃김
결국 7만 명 직원과 공유한 비밀을 지키기는 어려움

• 예전에 Zuckerberg의 행동을 더 많이 신경 쓰던 시절, 그는 “유출자를 싫어”하면서도 사람들을 화나게 해 유출하고 싶게 만드는 자기 행동을 돌아보고 바꾸지는 못한다는 생각이 들었음
  그는 매우 반응적인 사람이지, “내가 변화가 되려면 어떻게 해야 하나”나 “내가 무엇을 해서 이런 일이 생겼나”를 고민하는 타입은 아님
  2010년대 말 여러 스캔들을 보며 이런 생각을 했음. 그에게 모든 건 홍보 대응이었지 내면을 돌아보는 일이 아니었음. 최고의 홍보는 나쁜 사람이 되지 않는 것임. 그걸 생각해본 적이 있는지 궁금함

작은 회사에 있거나 혼자 일하는 사람들이 AI를 쓰면서 더 많은 즐거움을 느끼는 것 같음
자영업자로서 지난달 토큰에 거의 1000달러를 태웠고, 그렇게 하면서 꽤 즐거웠음

• 놀랍지 않음. 사람들은 생산성이 올라간 이익을 일부라도 직접 얻을 때 더 생산적이 되는 걸 좋아함
  10배 더 생산적이길 기대받지만 임금 인상이 없다면, 결국 임원의 주머니에 돈을 채워주면서 자기 고용 안정성만 낮추는 셈임
• Meta는 정반대 끝에 있음. 기사 첫머리부터 이제 AI로 모든 사람이 컴퓨터를 어떻게 쓰는지 감시한다고 나옴
  Meta가 이걸 좋은 아이디어라고 생각했다는 것, 그리고 익명 AI 학습에만 쓰인다고 주장하면 직원들이 편안해할 거라고 본 것이 아직도 말이 안 됨
• 혼자 일하지만 AI를 쓰는 데서 즐거움을 느끼지는 않음
• 그 에너지를 느끼고 있음. 건강보험 때문에 지금 다니는 대기업에 어떻게든 남아 있으려 하지만, 끌림이 너무 강함

“이 데이터는 매우 엄격하게 통제됩니다”라고 Bosworth가 답했음. “유출 위험은 없을 겁니다”
아이고. 유명한 마지막 말임

인생의 큰 부분을 기술이 삶을 더 낫게 만들 것이라고 믿으며 보냈지만, 이제 그 생각이 오류라는 걸 깨달음
기술은 권력을 증폭함. 모두에게 이로운 가치 체계를 집단적으로 다시 정의하고 집행하기 전까지, 기술 발전은 단순히 예속의 수단으로 작동함

• 여기까지 가보자면, 이게 Unabomber가 말하던 내용이고, 사람들이 이걸 알아차리지 못하게 하려는 노력도 오래전부터 있었음
  결국 전체주의로 가거나, 아니면 그것에 저항하며 미지의 영역으로 밀고 나가 탈출구를 만들려 하게 됨. 전체주의는 현상 유지에서 발전을 멈추거나, 무정부적 원시주의를 유지하거나, 기술관료적 지루함으로 이어질 수 있음
  실제로는 미지의 방향을 향해 나아가며 희망하는 수밖에 없음. 다만 이 모든 것을 통과하는 길이 무엇인지 보인다고 거짓말할 수는 없음
• 핵심 진실은 바로 그거라고 봄. 기술 자체가 삶을 더 좋게 만들지는 않음
  최근 Luddites에 관한 글을 썼음. 그들의 실제 요구를 보면 반기술이 아니었고, 노동운동가였음. 산업혁명 동안 대부분의 사람들의 삶은 훨씬 더 나빠졌고, 그들이 주장한 법이 마침내 시행된 뒤에야 나아졌음
  https://www.disruptingjapan.com/the-real-luddites-would-have...
• “기술적으로 발전한 어떤 사회에서도 개인의 운명은 그가 크게 영향을 미칠 수 없는 결정에 좌우될 수밖에 없다. 기술 사회는 작고 자율적인 공동체로 쪼개질 수 없다. 생산이 매우 많은 사람과 기계의 협력에 의존하기 때문이다. 그런 사회는 고도로 조직되어야 하고, 매우 많은 사람에게 영향을 주는 결정이 내려져야 한다. 어떤 결정이 예컨대 100만 명에게 영향을 준다면, 영향을 받는 각 개인은 평균적으로 그 결정에 100만분의 1의 몫만 가진다”
• “모두에게 이로운 가치 체계를 집단적으로 다시 정의하고 집행”하는 건 불가능함
  첫째, 무엇이 “모두에게 이로운가”를 두고 사람들은 자주, 그것도 매우 근본적으로 의견이 갈림. 그런 차이 중 상당수는 물리력 없이는 해결할 방법이 없음
  둘째, “집행”은 어떤 사람들에게 다른 사람에게 무언가를 할 권력을 준다는 뜻임. 다른 사람이 하면 범죄가 될 일, 즉 감옥에 보내고 벌금을 물리고 할 수 있는 일을 제한하는 권력임. David Friedman은 읽어볼 만한 책 The Machinery of Freedom에서 정부를 그렇게 정의함. 문제는 정부도 결국 인간이 운영해야 하고, 인간은 그런 권력을 맡길 만큼 신뢰할 수 없다는 것임
  결국 유일한 방어는 그런 권력을 다른 사람에게 주지 않는 것임. 정부에도, 거대 기술 기업에도, 누구에게도 주면 안 됨. 하지만 그러려면 대부분의 사람들이 갖고 있지 않거나 쓰고 싶어 하지 않는 수준의 예견력이 필요함. 특히 눈앞에 달콤한 것이 있을 때는 더 그렇다. Facebook이 처음 나왔을 때, 몇십 년 뒤 통제할 방법을 모르는 거대한 괴물이 될 걸 내다보고 그냥 쓰지 않겠다고 한 사람이 얼마나 됐을까? 내 주변만 보면 “의미 있을 만큼은 아니었다”가 답임. 내가 아는 사람 중 Facebook을 쓰지 않고 한 번도 쓰지 않은 사람은 나뿐임. 나조차도 처음부터 오늘날을 예견해서 거부한 건 아니었고, 본능적 거부감에 따랐을 뿐이며 이후 수년간 열차 사고가 천천히 벌어지는 걸 지켜봤음
  그래서 우리는 갇혀 있음. 예를 들어 정부가 거대 기술 기업을 쪼개고 Zuckerberg, Bezos 등에게 막대한 벌금을 물리고, 재산을 몰수하고, 사회봉사를 시키고, 일부는 감옥에 보낼 수도 있다고 결정하더라도, 결국 신뢰할 수 없는 인간들이 다른 인간에게 그런 일을 하는 것일 뿐임. 근본 문제는 고쳐지지 않음. 깡통을 조금 더 멀리 차는 것에 불과함
• 기술에 따라 정말 다름. 서로 다른 기술은 권력을 서로 다르게 재분배함
  LLM은 확실히 매우 중앙집중적임. 개인이나 작은 회사가 자기 LLM을 학습시키는 건 거의 불가능함. 기껏해야 사전학습된 모델을 내려받을 수 있는데, 그래도 최소한 누군가가 조용히 바꾸거나 빼앗아갈 수는 없음

AWS US-East 1은 계속 인터넷의 아킬레스건임
여러 리전과 가용 영역에 걸쳐 구축할 수는 있지만, AWS는 US-East 1 문제가 더 넓은 영향을 내는 사고를 반복해 왔고, AWS가 암시하는 것만큼 중복성과 복원력이 높지 않게 만듦

• AWS 서비스가 완전히 리전별로 분리되어 있다는 생각은 늘 신화에 가까웠음
  중국 외 퍼블릭 클라우드의 모든 식별·접근 서비스, 즉 직원들이 말하는 “aws 파티션용 IAM”은 us-east-1에 중앙화되어 있음. 계정, 과금, 권한을 일관되게 보려면 사실상 이런 중앙화가 필요함
  IAM도 완전히 독립된 소프트웨어 스택이 아니고 DynamoDB 등 몇몇 서비스에 의존하며, 그 서비스들은 다시 IAM에 순환 의존함
  us-east-1 장애 중에는 다른 리전에서 기존 인증 토큰이나 세션을 계속 쓰는 것은 가능할 때가 있지만, 새 토큰을 발급하지 못할 수 있음. 예전에 근무할 때는 장애가 끝날 때까지 잠길 수 있다며 온콜에게 SSH 세션이나 AWS 콘솔 브라우저 탭을 닫지 말라고 한 적도 기억남
• 다들 그렇게 말하지만 이번 건은 단일 가용 영역 문제였음
  지난 3년간 스타트업을 거의 use-1에서 운영했는데 리전 장애는 한 번뿐이었고, 그마저도 부분 장애라 대부분 인스턴스는 영향이 없었음
  솔직히 고객들의 것도 전부 use-1에 있으니 장애가 고객과 상관관계를 갖는다는 장점은 있음
• 너무 많은 사람이 쓰고 있음
  환상의 마법 나라에서는 부하가 여러 클라우드 제공자에 고르게 분산되고, 단일 장애 지점은 존재하지 않음
  첫 여자친구와도 잘 풀렸고, 쌍둥이는 영어와 한국어에 능통하며, 대규모 서비스를 배포할 때 AWS 하나에만 의존하면 안 된다는 것도 앎
  미국 의료비도 감당 가능함. 하지만 현실은 또 하루가 지나고, AWS US-East 1 하나가 인터넷 대부분을 쓰러뜨릴 수 있음
• 복원력을 위해 여러 리전과 가용 영역을 쓴다면 용량세를 낼 준비가 필요함
  2개 리전이면 2배 용량, 3개 리전이면 1.5배 용량을 준비해야 하고, 다중 리전 구성에서 머신을 이미 실행 중이어야 함. 장애 중에 인스턴스를 띄우거나 용량을 확보할 수 있을 거라 기대하면 안 되며, 다중 리전 호스팅의 추가 복잡성도 감당해야 함
• 들은 바로는 us-east-1에서 넘어온 사람들 때문에 us-east-2에도 연쇄 영향이 있었던 것 같음
  여러 리전/가용 영역 구성이 이렇게 노골적으로 겉치레처럼 보이는데도, 다 같이 클라우드 종교의 신조처럼 믿고 있는 모습이 좀 웃김

이런 베팅은 위험함. AWS를 다운시킬 수 있는 직원 같은 사람이 베팅을 할 수 있기 때문임
이런 베팅은 보기만큼 무해하지 않은데, 베팅한 사람이 결과에 영향을 주거나 바꿀 수 있는 경우가 많음

• 빅테크가 돈이나 사회적 지위만 신경 쓰는 사람이 아니라 윤리적인 엔지니어를 뽑아서 참 다행임
• 정작 모든 베팅 사이트가 US-East1 위에 있으면 말짱 도루묵임
• AWS가 내려가서 베팅 웹사이트 자체가 닫히는 상황도 상상 가능함
  전체적으로는 이런 예측 시장이 내부자 거래와 부정적 시나리오를 유인할 수 있다는 주장에 동의함. 그런 상황을 이용해 이익을 얻을 동기가 생김

데이터센터의 냉각은 거의 미리 계획되어 있고, 냉각 가능한 것보다 더 많이 설치하지 않는 줄 알았음
여기서는 냉각 장비가 고장 난 건지, 과열에 외부 원인이 있었던 건지, 아니면 Amazon이 데이터센터 냉각 용량을 초과 예약하는 건지 궁금함

• 지붕에 여러 중복 냉각기, 각 층에 여러 중복 냉각 장치가 있는 데이터센터에서 일한 적이 있는데, 어떤 식으로든 급수 배관이 고장 나자 건물 전체 냉각이 한꺼번에 멈췄음
  자세한 원인은 말해주지 않았지만 각 층과 지붕 사이 배관은 중복화되어 있지 않았던 듯하고, 수리에 거의 24시간이 걸렸음
• 거의 확실히 장비 고장 문제임
  데이터센터 냉각은 다른 모든 것처럼 과잉 provision과 과소 provision이 동시에 존재함
  큰 열교환 장비는 N+1이고, 매우 중요한 소규모 부하 시설에서는 2N/3N으로 구성되므로 과잉 provision임. 정기 점검을 위해 내려야 하고, 전통적인 데이터센터 부품보다 고장률이 높으며, 전문 인력과 긴 조달 시간이 필요한 기계 수리가 필요하기 때문임
  큰 시설에서는 N이 커질수록 냉각이 N+3 이상인 것도 드물지 않음. 항상 뭔가를 정비 중이거나, 더 이상 존재하지 않는 부품을 선반으로 새로 만들어야 해서 전체 장비 교체보다 싸기 때문에 부품을 기다리는 장치가 생김
  반대로 시설의 모든 컴퓨팅 용량이 평균 전력 사용량에서 갑자기 100%로 올라가면 냉각 용량을 초과하게 되므로 과소 provision이기도 함. 전기와 다른 경로도 흔히 초과 부하가 걸리며, 업계의 본질이 과잉 판매에 가까움
  보통은 큰 문제가 되지 않음. 컴퓨팅 부하가 전체 용량의 100%까지 치솟는 일은 드물고, 치솟아도 오래가지 않으며, 냉각이나 전력 용량을 칼날 위에 놓고 시설을 만들지는 않기 때문임
  문제는 여러 사건이 교차할 때 생김. 평균 부하의 200%를 처리하도록 냉각 시스템을 설계해 유지보수와 장애에 충분한 여유가 있음
  화요일에 수리 기사가 장비 하나를 보러 왔다가 베어링 불량을 찾고, 다른 주에서 부품을 가져와야 해서 팬 어셈블리를 망가뜨릴 위험을 피하려고 밤새 장비를 꺼둠
  인접한 냉각 장치 둘이 조금 더 세게 일하다가, 그중 하나에 살짝 불균형한 모터나 헐거워져 열이 나던 퓨즈가 있었고, 몇 년간 잘 버티던 부품이 늘어난 가동률 때문에 터짐
  이제 N+2 시설에서 두 대가 빠졌지만, 평균 부하 200% 기준이라 아직 치명적이지 않음
  첫 고장 장치 반대편의 세 번째 장치도 부하가 커진 상태에서 결함이 터지면 N+2 시설에서 세 대가 빠짐. 그래도 평균 부하 200%로 설계했으니 아직 대참사는 아님
  그런데 새벽 4시라 현장 운영자는 이 결함을 고칠 수 없고, 업체는 7시에야 일어나 9시에야 도착함. 그 사이 부하가 올라가기 시작함
  이런 일은 미국 어딘가의 데이터센터에서 매일 일어나고, 아마 모든 데이터센터에서 1년에 한 번쯤은 생김
  다음에 일어나는 사건의 합류가 뉴스를 만드는 부분임. 큰 고객 하나가 지금이 대규모 일괄 처리 작업을 시작하기 좋은 시간이라고 판단함. 어떤 핀테크가 장 시작 전에 큰 모델을 돌리거나, 석유 회사가 새 유전에 대한 빠른 분석을 돌림
  VM 10,000개를 새로 띄움. 평소라면 남는 용량이 있으니 괜찮음
  하지만 냉각은 평균 냉각 용량의 200%로 계획했을 뿐이고, 이번 노드는 적당히 바쁜 노드가 아니라 최적화된 고강도 수치 계산을 수행해 최대 전력을 끌어 쓰고 최대 폐열을 내는 노드임
  전체 머신 수 기준 부하뿐 아니라 평균 폐열 영향도 커짐. 그러면 연쇄 장애가 터지고 냉각은 N-4가 됨
  서버 팬이 더 빨리 돌기 시작해 전력을 더 먹고, 냉각은 N-5가 됨. 경보가 사방에서 울림
  냉각 장치의 안전장치가 부하와 냉매 압력 상승으로 차례로 작동하면서 냉각은 N-6, N-7, 그리고 0이 됨
• 데이터센터의 냉각 루프 하나가 고장 난 것임
• 비슷한 주제는 여기서 듣기 좋음: https://signalsandthreads.com/the-thermodynamics-of-trading/

올해 EU에서는 Hetzner가 AWS보다 가동 시간이 더 좋았는지 궁금함

• OVH는 왜 사랑받지 못하는지 모르겠음
  Hetzner의 UI는 너무 헷갈려서 관리하기 어렵다고 느낌

관련 글: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294

늘 East 1임. 농담은 제쳐두고, east-1이 다른 리전에 비해 왜 이렇게 자주 내려가는지 이해가 안 됨
아키텍처상으로는 다른 리전과 꽤 비슷해야 할 것 같음

• east one이 핵심 데이터센터이자 가장 오래된 곳 아닌가 싶음
  다른 리전보다 부하가 더 크고, 처음 만들 때 경험이 적었으니 기술 부채와 아키텍처/엔지니어링 부채도 더 많을 것 같음
  기억상 IAM이나 일부 S3 구성처럼 east-1을 단일 장애 지점으로 의존하는 서비스도 있음
• 가장 오래된 리전 시스템이고, 내부 인증 기관이 거기에 있는 것처럼 구조적으로 중요한 역할이 있음
• 재밌게도 이런 글이 있었음

  AWS in 2025: The Stuff You Think You Know That’s Now Wrong
  us-east-1 is no longer a merrily burning dumpster fire of sadness and regret.
  — https://www.lastweekinaws.com/blog/aws-in-2025-the-stuff-you...
  그 외에는 좋은 글임

Coinbase는 여러 가용 영역이 내려갔다고 했지만, AWS 발표는 단일 가용 영역만 영향받았다는 내용이었음
더 자세히 아는 사람이 있는지 궁금함

• Coinbase가 X에서 거래소를 지연 시간 때문에 한 가용 영역에서만 운영했다고 확인함: https://x.com/i/status/2052855725857329254
• 암호화폐 회사가 정직할 거라고 믿으면 안 됨
• 공식 출처는 못 찾겠지만 폭발 반경이 해당 가용 영역에만 한정되지는 않은 것 같음
  us-east-1에서 시스템을 돌리고 있는데, 사고 중 az4 밖에서도 전에 본 적 없는 설명하기 어려운 간헐적 연결 문제가 보였음
• East-1이 내려가면 항상 다른 가용 영역의 일부도 같이 영향을 받음. 늘 뭔가가 East-1에 의존하기 때문임
• 저녁 내내 리전 전체가 터지나 싶어 SLI 그래프를 보고 있었지만 결국 그렇게 되지는 않았음
  여러 환경 중 몇 개에서 단일 가용 영역의 EBS 볼륨이 조금 나빠졌을 뿐이고, 확실히 단일 가용 영역(use-az4) 문제였음

지난번에 “친구라면 친구가 USE1을 쓰게 두지 않는다”는 말을 봤는데, Slack에 USE1과 거기에 배포한 것들이 전부 망가졌다는 메시지가 뜨자 그 말이 떠올랐음

여기 댓글에는 us-east-1이 중앙화되어 있고 AWS의 단일 장애 지점이며 고쳐야 하고 거기에 올리지 말라는 익숙한 얘기가 많음
이번 일은 다중 영역 리전 안의 한 영역에 있는 데이터센터 하나의 문제였음
IAM/R53 등은 거기에 중앙화되어 있고, 그 서비스를 탈중앙화·교차 리전 구조로 바꾸는 건 좋은 일임. 하지만 us-east-1 자체는 이미 6개 영역, 2026년 예정인 7번째 영역까지 있는 다중 영역 리전이고, 영역 안에도 여러 데이터센터가 있음
기억상 IAM 같은 전역 서비스가 내려갈 때는 “교차 리전이었다면 죽지 않았을 것”이라기보다 구현이나 의존성 버그인 경우가 더 많음
이번에는 AWS 전역 서비스 장애가 아니었음. 더 큰 영향을 받은 것으로 보인 건 MSK 정도였고, 그건 AWS 관련이라기보다 Kafka 쪽 문제일 가능성이 큼

왜 이런 것을 바다 근처에 짓지 않는지 궁금함. 원자력 발전소처럼 냉각 용량이 많이 필요한 시설도 그렇지 않나 싶음
열교환기를 둔 2루프 순환으로 열을 빼내면 될 것 같음

• Ashburn VA가 데이터센터 허브가 된 이유는 세계 최초의 비정부 인터넷 교환 지점이 거기에 있었기 때문임(https://en.wikipedia.org/wiki/MAE-East)
  1990년대에는 전 세계 인터넷 트래픽의 절반가량이 MAE-East를 거쳤고, 그 결과 AWS가 첫 리전을 거기에 두었음. us-east-1은 eu-west-1보다 2년, us-west-1보다 3년 먼저 나왔음
  데이터센터를 지을 줄 아는 사람과 공급할 줄 아는 업체가 많아지면서 Dulles Corridor는 여러 회사 데이터센터의 주요 허브가 됨
  AWS에서는 us-east-1이 첫 리전이라 압도적으로 가장 복잡하고 이상하며, 다른 AWS 서비스의 많은 제어 평면이 여기에 의존하게 됨. 그래서 다른 리전보다 자주 내려가고, 내려가면 스페인의 eu-south-2와 달리 전국 뉴스가 됨
  NoVA는 공장이 아니라 데이터센터에 대한 사례일 뿐, Paul Krugman이 노벨 경제학상을 받은 연구 주제와 같은 종류의 경제 클러스터임
• 서로 다른 데이터센터 두 곳에서 중대한 과열 장애를 겪은 적이 있음
  하나는 Hosting.com의 SOMA 데이터센터가 너무 뜨거워져 지붕에서 호스로 물을 뿌려 식혔던 사건이고, 다른 하나는 Alibaba의 Chai Wan 데이터센터가 너무 뜨거워져 제어 평면을 포함해 거기서 돌던 모든 것이 내려간 사건임
  그래서 바다와 가깝다고 비상 방열 측면에서 추가 이점이 생기지는 않는다고 봄. 열을 밖으로 빼내는 용량은 정해져 있고, 바닷가에 있든 Nebraska 한가운데 있든 전체 시스템이 특정 성능을 만족하도록 설계되어야 함
• 석사 과정에서 데이터센터 수업을 들었는데, 교수는 미국 중부의 더운 지역 데이터센터를 예로 들며 이상적인 시나리오와 비교했음
  슬라이드에는 데이터센터 입지 결정에 영향을 주는 요소들이 있었고, 충분한 공간과 그 데이터센터에서 일할 숙련 인력을 찾는 항목이 여럿 포함되어 있었음. 때로는 다음 데이터센터 위치 선정에 정치가 개입된다고도 했음
• 떠오르는 것만 적어보면, 해수 수준의 소금이 들어간 물 시스템은 유지보수 비용이 훨씬 비쌈. 2차 루프도 마찬가지임
  해안 토지는 훨씬 비싸고, 외딴 해안 지역으로 가면 전력 접근성이 좋지 않을 가능성이 큼
  해안 부지는 보통 더 심한 기상 현상에 노출됨
  예측하기 어려운 일도 있음. Diablo Canyon 원전은 잔해와 해파리 이동 때문에 해수 냉각 취수구가 막히는 문제를 겪었음
  https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
• 바다에는 소금이 있음. 소금물은 일반 물보다 전자장비에 훨씬 나쁨
  물이 충분히 깊어야 하고, 그렇지 않으면 표면 온도까지 데워짐. 또한 전통적인 증발 냉각과 가격 경쟁력이 있어야 함
  이 방식이 잘 되는 교과서적 사례는 Toronto임. 해안에서 비교적 가까운 곳에 깊은 담수호가 있고, 도심은 부동산이 비싸 전통적인 방식이 막혀 있음
  https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System

borkdude가 이 스레드를 올렸고, 이번 릴리스의 기여자로도 올라와 있는 걸 봤음
오래전부터 async/await 지원 반대 논리는 대체로 두 가지였음: CLJS 컴파일러 전반에 깊은 변경이 필요하다는 점과, Promesa 같은 라이브러리의 매크로가 비슷한 편의성을 제공한다는 점
그 외에도 core.async를 쓰면 된다거나, 표현식 지향 언어는 async/await와 잘 맞지 않는다는 주장도 있었지만, 포럼에서 반복되던 주류 논거라기보다는 개인별 견해에 가까웠음
Clojurians Slack에서 borkdude는 지원 추가가 비현실적이라고 확신하지 않는다고 한 적이 있는데, 결국 시간을 들여 구현해낸 듯해서 정말 고마움

• Borkdude가 먼저 자신의 ClojureScript 대체 구현인 Squint에 async/await를 구현해서 가능성을 보였고, 그때 얻은 내용을 핵심 CLJS 컴파일러로 가져온 것 같음

재미있는 사실은 ClojureScript가 JavaScript 자체에 async/await가 들어오기 훨씬 전부터 core.async 라이브러리로 비동기 패러다임을 지원했다는 것임
이 릴리스의 가치를 깎아내리려는 건 전혀 아니고, 의존성에 라이브러리 하나를 추가하는 것만으로 호스트 언어에 아직 없는 새 언어 기능을 쓸 수 있다는 점이 멋지다는 얘기임. Clojure는 굉장함

• 확실히 그랬음. 많이 써봤고 동작도 잘했으며, 약간의 특이점은 있었지만 10년 넘게 사실상 async/await를 가지고 있었음
  David Nolen의 발표를 보고 알게 된 것 같음
  이후에는 프런트엔드에서 JavaScript를 최소한으로 쓰는 쪽으로 옮겼고, SSE는 단방향이라서 그 점이 아름다움. 요즘 여러 언어권 개발자들이 SSE에 관심을 갖는 걸 보니 반가움
  David Nolen의 최근 발표 “A ClojureScript Survival Kit”도 좋았음: https://youtu.be/BeE00vGC36E
  David “Swannodette” Nolen이 ClojureScript와 core.async 초창기부터 해온 작업에는 아무리 감사해도 부족함. 이 발표에서 특히 놀라운 건, 그가 ClojureScript를 버리고 서버 쪽의 순수 Clojure와 서버 전송 이벤트, 아주 약간의 JavaScript만 쓰는 방향에도 실제로 기대감을 보인다는 점임
  실제 데모는 26:30쯤 시작함. 클라이언트에서 돌아가는 웹앱의 리소스 사용량을 보여준 뒤, 같은 웹앱을 서버에서 실행하고 SSE로 클라이언트에 단방향으로 밀어주는 모습을 보여주는데, 리소스 사용량이 거의 0에 가까워져서 꽤 강렬함
  모든 경우에 맞지는 않겠지만, 최소한의 DOM 변형 라이브러리를 쓰니 웹앱과 상태를 추론하기가 더 쉬워졌음. 예전에는 Clojure용 REPL과 ClojureScript용 REPL을 둘 다 띄우고, 양방향 트래픽과 재현하기 어려운 상태를 많이 다뤄야 했는데, 지금은 훨씬 빠르고 재현도 쉬움
• 맞지만 2026년에 core.async를 피할 이유도 많음
  JavaScript 산출물이 커지고, 내재된 오류 모델이 없으며, 문제가 생기면 읽고 디버깅하기 어려운 상태 기계 코드로 변환됨
  게다가 go 매크로는 자기 S-표현식 바깥의 코드를 변환할 수 없어서 함수가 지나치게 커지도록 유도함
  어떤 Cognitect 사람이 말했듯이 “core.async는 아름다운 헛소리”임

최근 갑자기 소셜에서 Clojure/ClojureScript가 더 자주 보이는 게 의외임
2012년쯤 몇 년간 업무에서 썼지만, 다른 많은 사람들처럼 JVM을 떠나 타입 있는 함수형 언어로 옮겼음
요즘 관심이 늘어난 건 에이전트형 코딩 때문일까? 타입 검사도 없고 잘못된 문법 오류나 예약어도 적어서 코드 훑기가 더 빠른 걸까? S-표현식의 부활이 오는 건가 싶음

• 개인적으로는 타입 있는 함수형 언어에서 ClojureScript로, 그리고 약 10년 전 Clojure로 옮겼음
  내가 아는 진지한 Clojure 코드베이스들은 테스트 스위트에 많이 투자하므로, AI에게 테스트 스위트를 가장 효과적으로 쓰는 방법을 알려주는 기술만 추가하면 꽤 잘 달리게 할 수 있음
  동료 중에는 에이전트가 REPL과 상호작용하게 하는 사람들도 있고, 매번 시작 비용을 내지 않으니 더 빠르다고 함. 나는 게을러서 거기까지는 안 했지만 지금도 충분히 빠름
  Clojure는 걸리적거리는 요소가 적음. false와 nil을 제외하면 모두 참이고, 연산자 우선순위 표가 없으며, 핵심 언어가 불변·영속 자료구조를 기본으로 지원함
  모든 것이 표현식이고, 연산자와 표현식이 뒤섞인 구조가 아님. map, reduce, filter는 내장되어 있고 일반 코드에서 당연히 쓰임
  10년 전에 쓴 Clojure 코드는 오늘도 대체로 동작할 가능성이 높고, 생태계와 언어 설계자들은 코드를 깨뜨리는 일을 금기처럼 다룸
  써본 언어 중 아이디어를 표현하는 데 가장 자유롭고 두통이 가장 적었음. 사실상의 역방향 디버거인 Flowstorm도 프로그래밍의 꿈 같은 도구임
  만족스럽게 지내고 싶다면 참 좋은 언어임. 반대로 사용자 대부분이 그걸 당연하게 여겨서 많이 떠들지 않는 편임
  상업적으로 Clojure를 쓰는 프로그래머 중에는 언어를 잘 이해하지 못해 그다지 행복하지 않은 사람도 많음. 본인이 원해서 선택한 게 아니거나 아직 준비가 안 된 경우가 많고, Clojure를 쓰기 전 다른 언어에서 싫었던 점들을 10년쯤 겪어봤어야 했다고 봄
  Clojure 창시자 Rich Hickey의 소프트웨어 관련 영상들이 유명하고 영향력 있긴 하지만, 동료들이 그걸 봤거나 신경 쓴다는 뜻은 아님
• 최근 관심 증가는 Clojure 다큐멘터리 공개 영향이 큰 것 같음: https://clojure.org/about/documentary
• 에이전트형 코딩과 잘 맞는 또 다른 기능은 REPL 주도 개발임. 이론적으로 지원 가능한 다른 언어들에서 왜 이 접근이 더 널리 퍼지지 않았는지 모르겠음
• 여러 언어에서 에이전트형 코딩을 해봤는데, 타입 있는 언어가 훨씬 잘 맞음. 에이전트가 환각으로 만든 오류를 타입 시스템이 사실상 교정해주기 때문이고, 특히 큰 리팩터링에서 그렇음
  큰 규모의 타입 없는 Python 코드베이스를 AI와 다루는 건 힘들었음. 테스트로 덮이지 않은 부분은 망가지지 않았는지 확인하는 작업이 너무 지루함
  타입 시스템이 강할수록 더 좋음. 또한 AI 모델은 코드로 학습되므로 언어가 더 대중적일수록 성능도 더 좋을 가능성이 큼. ClojureScript는 좋지만 주류 언어는 아니라서 JavaScript보다 AI 성능이 떨어질 거라고 봄
  결국 AI를 염두에 둔다면 타입 있는 언어를 고르거나, 동적 언어라도 타입 힌트가 있는 쪽을 고르는 게 낫다
• 다큐멘터리가 나왔거나 발표됐던 걸로 기억하는데, 그 영향일 수도 있음

이건 정말 큼. Jank가 발표된 이후 Clojure 생태계에서 이렇게 기대된 적이 없었음

프런트엔드에서 JavaScript 대안이 obscure한 수준을 넘어 실제로 자리 잡았으면 좋겠음
ClojureScript 같은 걸 써보고 싶지만, 개인 사이드 프로젝트 말고 어디에 쓸 수 있을지 상상하기가 어렵다. 이미 백엔드가 Clojure인 조직이라면 도입이 더 쉬울지도 모르겠음

• 주류 언어가 아니라 동료들이 모를까 봐 걱정하는 건지, 아니면 언어 자체가 버려지거나 나쁘거나 할까 봐 걱정하는 건지 궁금함
  프로덕션에서는 안 써봤지만, 사이드 프로젝트 몇 개와 가족용 물건은 배포해봤음. ClojureScript의 React 래퍼인 Reagent는 솔직히 React 자체보다 더 말이 된다고 느꼈음
  Hiccup으로 HTML을 만들고, 컴포넌트는 Hiccup DSL 안의 함수일 뿐인데 이 DSL도 사실상 리스트라서 결과가 아주 깔끔함. 정적인 것은 정적으로 보이고, 동적인 것은 분명히 동적으로 보이며, 일반 React보다 마법이 훨씬 적게 느껴졌음
  안 좋게 느낀 건 NPM에서 찾은 비함수형 컴포넌트를 쓰려 할 때였음. 치명적이진 않지만 코드가 못생겨짐. 래퍼로 고칠 수는 있었지만, 일부 JS 라이브러리는 cljs에서 기본 상태가 굉장히 지저분함
• 겁낼 필요 없음, 정말 좋음. 10년째 복잡한 앱을 고도로 최적화된 클라이언트 코드로 컴파일하는 데 쓰고 있고, obscure하다고 부르지는 않겠음
  커뮤니티도 매우 친절하고 성숙함
• 상상만 하지 말고 작게 시작하면 됨. 팀에서 쓰는 bash 스크립트가 있다면 Babashka로 다시 써보면 됨
  먼저 개인 스크립트부터 바꿔보고 감을 익힌 뒤 장점을 느껴보는 게 좋음. 모든 경우에 더 나은 건 아니지만, 나중에 사람들이 조언을 구하러 올 수 있으니 본인이 충분히 확신해야 함
  낯선 기술을 들여올 때는 덜 중요한 것을 골라 다시 쓰고 그냥 두는 전략이 좋음. 문제가 되면 되돌리기 쉽고, 사람들이 좋아하기 시작하면 조금씩 늘리면 됨
  예전에 .NET 조직에 F#을 몰래 들여올 때도 덜 중요한 테스트부터 F#으로 쓰기 시작했음
• Gleam을 써보면 좋음. 프로덕션에서 아주 만족스럽게 쓰고 있음
  https://blisswriter.app/
  https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and
• https://hypermedia.systems/를 읽고 나서는 최고의 프런트엔드는 프런트엔드가 없는 것이라는 결론에 도달했음

cljs를 오래 따라가지 않았지만, 원래는 “JavaScript 위의 Clojure” 정도로 소개됐던 걸로 기억함. 적어도 Rich가 처음에는 그렇게 설명했던 것 같음
최대한 또 하나의 런타임에 가깝게 만들려는 의도라고 이해했음
그런데 이번 변경은 cljs에만 있는 기능을 추가하는 것처럼 보이고, await가 이미 clojure.core의 키워드라서 Clojure 자체와도 충돌함
두 구현이 시간이 지나며 갈라진 건지, 아니면 이 기능이 사용자들에게 그 차이를 감수할 만큼 중요했던 건지 궁금함

추가 라이브러리를 넣지 않고 JavaScript 상호운용성을 다룰 수 있다는 점에서 중요함
오래 빠져 있던 기능이라 이번 릴리스가 꽤 반가움

async/await 함수를 CSP로 감싸는 편이 더 나은 처리 방식 같음. Clojure에는 이미 더 좋은 패턴이 있었음

• 이번 릴리스는 호스트 언어의 원시 기능을 ClojureScript에 노출하는 것에 관한 것임
  core.async가 사라지는 건 아니고, async/await가 Promise 기반 구현보다 더 잘 맞는다면 core.async의 .cljs 부분도 업데이트될 수 있음
• 여전히 그렇게 할 수 있음. ClojureScript 세계에서는 이미 여러 해 동안 가능했고, 결국 그것들은 Promise일 뿐임
  이번 새 함수 힌트가 들어와도 그 방식이 사라지지는 않을 것 같음
  https://clojurescript.org/guides/promise-interop#using-promi...

이걸 어떻게 받아들여야 할지 잘 모르겠음. core.async의 요지 중 하나가 이런 것들을 모두 채널로 밀어 넣는 것 아니었나 싶음
JavaScript식 async 키워드를 갖는 게 업그레이드인지 확신이 안 듦

• 이건 core.async 같은 추가 의존성을 가져오지 않고 JS 기능을 쓰기 위한 것임
  반드시 쓸 필요는 없고, 여전히 core.async도 쓸 수 있음. 최근 ClojureScript 설문에서 가장 많이 요청된 기능이기도 했음

대단하네. 예전에 스마트 기기를 만드는 작은 회사와 연동하는 일을 했는데, 그 회사의 유일한 엔지니어가 어셈블리 언어밖에 몰랐음
하드웨어 제어 코드부터 서버 운영체제, 우리가 쓰던 JSON 웹 API까지 전부 어셈블리로 직접 작성돼 있었음
한 번은 웹 API가 엉뚱한 기기의 데이터를 반환하는 버그를 만났는데, 알고 보니 운영체제 스케줄링 시스템에 오프바이원 오류가 있어서 “데이터베이스”가 웹 서비스에 잘못된 행을 돌려주고 있었음

• 혹시 그 사람 이름이 Mel은 아니었나?

“자살” 같은 표현을 다룰 때는 제발 콘텐츠 경고를 붙였으면 함. 더 낫게는 아예 언급하지 않는 편이 좋고

• 뭐지? 글 일부는 대충 읽긴 했지만 처음 읽을 때 자살 관련 언급을 못 봤음
  이 댓글 보고 다시 찾아봤는데도 못 찾겠는데, 내가 뭔가 놓친 건가?
• 유머 감각이 전혀 없는 쪽이 오히려 본인 건강과 사회 전체에 훨씬 더 위험함

“전부 어셈블리로 작성”됐다는 얘기를 보니 Therac-25 조사 보고서가 떠오름

중앙화된 독점 소프트웨어가 독점 플랫폼 위에서 돌아가면, 특정 업데이트를 통해 모든 개인키를 결정론적으로 만들 수 있고, 그 백도어를 아는 사람에게는 종단 간 암호화가 무력해짐
검증 가능한 종단 간 암호화는 자유·오픈소스 소프트웨어만 제공할 수 있으며, Zoom, WhatsApp, Instagram 같은 중앙화·독점 솔루션은 보안 연극을 그만둬야 함
그래도 Meta가 한 제품에 대해서는 솔직했다는 점은 높게 봄

• 중앙화된 자유·오픈소스 소프트웨어도 똑같이 암호화를 제거할 수 있음
  오픈소스가 보안의 필수 조건은 아님

“DM에서 종단 간 암호화 메시지를 켜는 사람이 매우 적었다”고 Meta가 말한다면, 왜 Signal이나 WhatsApp처럼 기본값으로 켜지 않았는지 궁금함 :-)

• Instagram은 애초에 그런 구조가 아니었음
  새 휴대폰에 설치하거나 브라우저에서 열 때, DM을 복구하려고 복구 키를 입력할 거라고 기대하지 않음
  FB Messenger에는 종단 간 암호화를 추가했지만, 전혀 안전하지 않은 6자리 숫자 PIN까지 포함해 매우 투박했음
• 둘 중 하나임: 제공자가 암호화된 데이터에 사실상 접근 가능한 종단 간 암호화 시스템이거나, 키 관리를 사용자에게 넘겨 데이터 손실 위험을 감수하게 하는 방식임
  어느 쪽이든 제공자는 언제든 클라이언트 쪽에서 데이터에 접근하는 앱 버전을 배포할 수 있고, 대부분의 사용자는 종단 간 암호화와 SSL/TLS를 구분하지 못하며, 구분하려 하지도 않고, 관심도 없음
• 종단 간 암호화가 가능했다는 사실조차 몰랐으니, 사람들이 켜도록 만드는 데 진지했다고 보긴 어려움
  존재조차 몰랐던 기능을 사람들이 쓰지 않았다는 이유로 이제 꺼야 한다니 참 안타까움 /s

이런 종류의 기업의 비겁함은 선출되지 않은 관료들이 압박하는 방식으로 더 심해질 뿐이고, 열린 웹을 조이는 올가미도 더 팽팽해질 것 같음
하드웨어 증명과 벽으로 둘러싸인 앱 스토어의 결합이 이 분야 정책 입안자들의 최종 목표처럼 보이며, Google, Apple, Facebook 같은 독점 기업에도 아주 잘 맞아떨어짐
시간이 지나면 항상 나아지는 것은 아니고, 우리 생애의 안전한 통신은 이미 정점을 지나쳤을지도 모른다는 시의적절한 상기처럼 느껴짐

• 하드웨어 증명은 컴퓨터에 일어날 수 있었던 최악의 일 중 하나처럼 들림
• 이건 단지 “열린 웹의 죽음”이 아님
  이런 결정은 미국이 파시즘으로 기울고 있는 와중에 내려지고 있음
  Meta가 종단 간 암호화 폐지가 자유 발언 탄압을 쉽게 하려는 의도는 아닐 수 있지만, 종단 간 암호화를 없애면 실제로 그렇게 됨
  DHS는 이미 ICE를 비판한 사용자 정보를 얻으려고 기술 회사들에 소환장을 보내고 있음: https://www.nytimes.com/2026/02/13/technology/dhs-anti-ice-s...
  이제 벽으로 둘러싸인 정원은 큰 걱정거리도 아님
  모든 디지털 커뮤니케이션을 비밀경찰이 읽고, 위반이 심하면 괴롭히거나 협박하거나 수용소로 사라지게 할 수 있다는 게 여기서 걸린 문제임
• 사람들이 Instagram이 자기 Instagram 비공개 메시지를 읽지 못한다고 기대하진 않을 것 같음
  그리고 종단 간 암호화는 HN 사람들이 말하는 것만큼 저렴하지 않음
  중앙 서비스 없이 기기들이 그 키를 어떻게 얻겠나, 특히 그중 하나가 웹 브라우저라면 더 그렇다

냉소적으로 보면, 이걸 종단 간 암호화가 붙은 추가 인증 프로그램을 파는 수익성 있는 구도로 만들 수도 있을 것 같음
Instagram DM에는 불륜 배우자, 폭로되는 운동선수 같은 수상한 메시지부터 범죄성 메시지까지 많이 오감
플랫폼이 스크린샷을 찍으려면 상대 동의가 필요하게 하는 식의 추가 보험성 인증 프로그램을 팔 수 있다면 말임

“우리 메시징 시스템은 오래전부터 사용자 프라이버시와, 사용자가 신고하거나 법적으로 요구될 때 사기·괴롭힘·기타 안전 문제에 대응할 수 있는 능력 사이의 균형을 맞추도록 설계되어 왔다”
TikTok이 비공개 메시지에 종단 간 암호화를 넣지 않는 이유라고 함
아이들을 구하려면 프라이버시를 포기하는 게 합리적인가 봄
TikTok은 아이들의 안전과 행복을 정말 많이 챙기나 봄!

• 끔찍함
  이들은 말 그대로 아이들에게 광고하려고 이러는 것임
  데이터베이스도 저장 시 암호화가 안 되어 있을 것 같음
  완전히 어리석다

Apple 엔지니어들과 이야기해 봤는데, Siri가 뒤처진 건 Apple의 프라이버시 보호가 너무 강했기 때문이라고 들었음
사람들은 자신을 보호해 주는 걸 조롱했음
이건 그 정반대 사례로, Mark가 또다시 사용자와 아이들을 버스 밑으로 던지는 셈임
새로울 게 없고, 통계적으로 남의 사생활을 파고드는 방식 말고는 돈 버는 법을 모르는 것처럼 보임

• 보안과 맞바꿔 기능이 조금 줄어드는 건 괜찮아서 보통 Siri를 옹호하는 편임
  오히려 그쪽이 더 좋음
• 종단 간 암호화 위에 새 기능을 만드는 건 정말 어렵고, 엄격한 종단 간 암호화를 유지하면서 혁신을 계속하려다 고생하는 회사를 많이 봤음
  여러 선도적인 메시징·VoIP 스택을 내부에서 본 입장에서, 실제 운영 환경에서 종단 간 암호화의 여러 제약을 우회하는 데 들어가는 엔지니어링 비용은 엄청남
  단순한 일상 기능조차 종단 간 암호화 없이 돌아가는 같은 기능의 지표와 비교가 안 됨
• 흥미롭지만, Siri 팀에서 직접 일한 Apple 엔지니어들과 이야기했을 때 그런 주장은 없었고, 대체로 문화적 문제라고 했음
• “Siri가 뒤처진 건 Apple의 프라이버시가 너무 강해서다”라는 건 전혀 말이 안 됨
  Siri의 문제는 Siri 자체, 즉 인터페이스임
  내 불만 중 프라이빗 데이터에 접근하지 못해서 생긴 건 하나도 없음
  애초에 요청을 이해하지 못하거나 기본 기능이 부족한 게 전부임
• 동의하기 어려움
  그런 제약이 있어도 더 많은 걸 할 수 있었음
  Apple은 오랫동안 관심이 부족했음
  몇 년마다 완전히 새 Mac Pro를 요란하게 발표하고는, 곧 관심을 잃고 5년 동안 시들게 두는 것과 비슷함

여기서는 좋아하지만, 종단 간 암호화는 그 기능에 관심 없는 사람에게는 객관적으로 더 나쁜 사용자 경험임

• 내게 종단 간 암호화를 쓰는 이유는 숨길 게 있어서가 아니라, 숨길 게 있는 인권 활동가 친구들이 있기 때문임
  소비자 기능이라기보다 제대로 작동하는 민주주의의 기반에 가깝다고 봄
• WhatsApp의 종단 간 암호화 사용자 경험은 꽤 괜찮고, 암호화를 도입했을 때 더 나빠지지 않았다고 봄
  다만 WhatsApp은 처음부터 기술 모델이 “뚱뚱한 클라이언트, 멍청한 서버”였음
• 왜 더 나쁜 경험인지 모르겠음
  앱이 대화 상대에게 공개키를 보내는 건 터무니없이 단순하고, 최종 사용자는 알아차릴 필요도 없음
  내가 뭘 놓치고 있나?
• 앱 방식의 종단 간 암호화에서 문제는 앱이 여전히 메시지를 평문으로 볼 수 있고, 그걸로 아무것도 하지 않는지 검증할 방법이 없다는 점임
• IRC를 좋아하는 사람들은 예외일 듯함
  그들은 종단 간 암호화를 좋아하지 않을 것 같음

이건 결국 Instagram을 쓰는 미성년자 보호 때문 아닌가?
종단 간 암호화를 허용하면 CSAM 탐지나 다른 감시를 효과적으로 할 수 없으니, 미성년자에게 “안전한” 장소를 제공할 수 없음
당연히 정답은 아이들이 소셜 미디어에 노출되지 않는 것이지만, 우리 아이들보다 더 많은 눈알이 더 중요하겠지

• 친구야, 이건 절대 진짜 이유가 아님

프라이버시에 신경 쓰면서 Instagram을 쓰는 사람이라면 이 일에도 신경 쓰지 않을 것임
Meta가 이렇게 하는 게 좋은 일은 아니지만, 지난 20년 이상 사람들은 무지한 채로 뭐든 받아들이는 편을 선호한다는 걸 보여줬음
케이크나 먹고 썩어가게 두면 됨
이 모든 게 어떻게 악용될 수 있는지 안다는 이유로 편집증 취급받는 데 지쳤음

이 일이 진행되던 시기에 Instagram에서 일했음
종단 간 암호화 팀은 아니었지만 충분히 봤고, 꽤 엉망이라는 걸 알 수 있었음
중단 이유는 “의지”나 회사 방침보다는 기술적 문제와 사용자 경험에 더 가까웠다고 봄
내가 이해하기로 Zuck은 이걸 원했음
구현은 엉망이었고, 사람들은 모든 플랫폼에서 메시지가 나타나길 기대함
기기나 웹 사이에서 메시지가 사라지거나, 암호화 키를 백업해야 하는 등은 정말 형편없는 사용자 경험이었음
직원들조차 이 기능을 싫어했음
실제 사용자가 요구한 기능이라기보다, 플랫폼 사용 과정에서 생기는 온갖 법적 문제를 피하려고 만든 기능에 가까웠음
어느 시점에는 이걸 성사시키려고 리드가 64명이나 있었음
각 리드는 특정 영역이나 화면을 맡았고, 이는 Facebook과 Instagram 전반에 걸쳐 수백 명이 관여했다는 뜻임
완전한 낭비 프로젝트였고, 사용자들이 원한 것도 아니었음
HN에는 이걸 정말 중요하게 여기는 사람이 많다는 걸 알지만, 평균 사용자는 이를 위해 사용자 경험 저하를 감수하려 하지 않았음
모든 우회책은 종단 간 암호화를 약화해야 해서 결국 의미가 없어졌음
진짜 종단 간 암호화를 원한다면 그걸 위해 특별히 만들어진 플랫폼을 써야 함
IG/FB는 그런 곳이 아님
Telegram조차 명시적으로 지정하지 않으면 기본으로 켜져 있지 않음

• 세부 사항을 전부 알지는 못하고 암호학자도 아니지만, Wire messenger는 짜증 나지 않는 방식으로 이걸 해결했던 것 같음
  방향 전환 이후로는 써 보지 않아서 구현에 대해 많이 말하긴 어렵지만, 여러 기기에서 매끄럽게 동작했던 기억이 있음
• 예상했던 그대로이고, 실제 경험이 있는 사람에게 들으니 좋음

이 중 몇 개는 풍선이나 새처럼 보임
이미 전에 유출된 두 개는 둘 다 적외선 카메라로 본 미사일이었음. 하나는 시야를 빠르게 지나가며 뒤에 모션 블러가 남은 장면이고, 다른 하나는 기동 중인 미사일에 밝은 적외선 광원 때문에 별 모양의 회절·조리개 아티팩트가 생긴 장면임
이 영상들 자체는 특별히 흥미로운 행동을 하는 물체처럼 보이지 않음. 군인이 영상을 찍고, 당시엔 정체를 몰라 “unknown”으로 분류해 DoD 파일 서버에 올려두면, 나중에 본인이나 다른 사람이 일부를 잘라 “대단한 UAP 영상”처럼 소문을 퍼뜨리는 흐름으로 보임. DoD 내부 파일 서버를 뒤져 외계인의 증거처럼 보일 만한 것을 찾는 데 여가 시간을 많이 쓰는 사람들이 있고, 가끔 Jeremy Corbell 같은 공개 UFO 인플루언서에게 이야기나 클립을 흘리는 듯함

• 별 모양으로 보이는 것은 멀리 있는 미사일 같지만, 영상 후반 몇 지점에서 낙하산이 보이고 열원이 거기에 붙어 있는 것처럼 보여서 미사일보다 더 평범한 낙하산 조명탄일 수도 있음
  몇 프레임: https://imgur.com/a/MyGZj3x
  원본 영상: https://www.dvidshub.net/video/1006088/dow-uap-pr38-unresolv...
• 흑색-고온 영상에서 차갑게 보이는 새가 어떤 새인지, 배기 없이 뒤에 유령 껍질 같은 흔적을 남기는 미사일이 어떤 것인지, 중립이 아니라 대비로 보이는 풍선이 어떤 것인지 의문임
  이 댓글은 확신으로 가득하고, 스레드도 그 확신에 보상하고 있음. 사람들이 불확실성을 느끼는 만큼 단정적인 답을 찾는 듯한데, 정말 그런 답을 줄 자격이 있다고 느끼는지 묻고 싶음
  평범한 것에 소문이 마법을 덧씌운다는 설명은 여기선 꼭 필요하지 않음. 그 확신을 제거하면, 매체 자체는 여전히 “설명되지 않은” 상태이기 때문임
  침묵이나 미지의 영역을 확실성이라는 발명품으로 채우는 건 매력적일 수 있지만, 알려진 것의 경계에서는 더 정직하게 접근하려면 호기심과 경이감이 필요함
• 물론 모든 건 그냥 지루한 무언가일 뿐임. 우리가 우연히 대기권에서 외계인을 목격할 가능성은 사실상 0에 가까움
  비밀 사진과 묻힌 증거를 찾는 사람들은 절대 그런 걸 찾아내지 못할 것임. DoD 내부 사람들도 일반 대중만큼, 어쩌면 그보다 더, 비합리적일 수 있음
  비행접시가 앞마당에 착륙하고 작은 초록색 인간들이 나와 “지도자에게 데려가라”고 해도 실제 외계인일 가능성은 극히 작음. 외계인과의 만남은 지금까지 나온 어떤 영화나 책과도 전혀 다를 것이고, 예외가 있다면 Contact 정도일 듯함
• 미군이 기관 간 검토까지 거치고도 새, 풍선, 빛, 특히 미사일을 식별하지 못한다면 나무만 보고 숲을 못 보는 것 같음

UFO에 빠진 삼촌이 있다면 Mick West의 YouTube 채널이 매우 유용함: https://www.youtube.com/c/mickwest
Mick은 은퇴한 게임 프로그래머로 Spider Man, Guitar Hero, Tony Hawk에 참여했고, UFO 주장들을 매우 잘 조사한 영상으로 분석함
화려하거나 재미 위주가 아니라 철저하고, 증거 기반이며, 과학적으로 엄밀함. 통제 실험, 재현, 3D 모델까지 만들어 실제로 무슨 일이 있었는지 검증함. 아무리 황당한 주장에도 늘 예의를 지키고, “Gimbal Video”를 설명한 작업이 좋은 예임: https://www.youtube.com/watch?v=Q7jcBGLIpus

• 어릴 때 좋아했던 게임 시리즈 세 개가 다 들어 있다니 전설적임
• 최근 인기를 끈 transients에 대해서는 설명하지 않는 것 같음
• 이미 결론을 정해놓고 거꾸로 맞춰가는 것처럼 들림. “UFO-crazy”라는 전제부터 가족 안에서의 인신공격을 입증할 분석을 끌어오려는 느낌이고, 증거를 따라 미스터리를 밝히려는 태도와는 달라 보임
  그런 식이면 Mr West의 작업도 잘못 쓰이는 셈임

전쟁이 만족스럽지 않게 멈춰 서자 이제 두 번째 distraction을 풀고 있는 것 같음. 지금부터 11월까지 몇 개나 더 필요할지 궁금함
내가 틀렸다고 설득해보길 바람

• 상황이 정말 나쁠 때마다 늘 이런 식임. “아, 그런데 외계인!?” 같은 식의 심리전임
  사람들이 더 높은 권위에 의존하고 정부가 자신들을 지켜준다고 느끼게 만들려는 것임. 실제로 외계인이 미국과 접촉한다면, 대표자들은 자기들이 싫어하는 나머지를 죽이는 데 쓸 외계 무기를 얻으려고 우리를 팔아넘기려 할 것임
• 그뿐 아니라 항상 너무 허술하게 함. 이쯤 되면 전략이 조금이라도 있고 실행 품질이 좋은 심리전이 나오면 오히려 더 감탄하고 분노할 듯함. 이건 그런 수준이 아님
• 무엇으로부터 주의를 돌리려는 건지 궁금함
• distraction처럼 보임. Epstein 파일, 그리고 서구 사회에서 실제 권력을 가진 사람들 중 아동 성범죄자와 인신매매범이 있다는 문제에서 시선을 돌리는 게 아니라는 식으로는 설득하기 어려움
  현 행정부가 세상을 더 낫게 만든다는 명분으로 다루는 낮은 수준의 중요하지 않은 일들에 집중하는 것도 distraction처럼 보임
• 이런 파일을 공개하려면 상당한 조율이 필요한데, 정부의 무능함까지 고려하면 평범한 설명이 더 그럴듯함
  즉 사건들이 서로 관련 없을 가능성이 더 큼

외계인이 여기 왔다는 건 새 Polymarket 계정이 “곧 외계인이 발견된다”에 1천만 달러를 걸 때 알 수 있을 것임

• https://polymarket.com/event/will-the-us-confirm-that-aliens...
• “곧”의 의미가 무엇인지 문제 삼아 지급이 거부될 듯함
• 너무 사실 같아서 싫음
• “Epstein 파일 공개”에 대한 Polymarket이 있었으면 함

개인적으로 가장 흥미로운 건 사실상 이란 관련 작전 세부사항임. Hormuz 해협에서 수년간 지속된 ISR이 어떤 모습인지 들여다보는 자료에 가까움
PDF 전체 묶음을 Codex에 넣고 이란 관련 세부사항을 뽑아달라고 했음
“OKAS에서 출격한 482 ATKS Reaper가 20시간 궤도 비행을 하고, NAVCENT와 24시간 사전 조율을 하며, NASER WAPs, SAFIR KISH PCs, HOUDONG급 보트, Abu Musa Island 비행장의 IRIN 항공기(IL-76, IL-38, A-50U Mainstay D, SU-27/35), Bushehr와 IRIN 조선소의 선박 등 명명된 이란 자산을 특성화하고 있음. 이란 방공 대응도 ‘Guardcall Tone: PROFESSIONAL’ 대 ‘DIRECTIVE’ 같은 공식 범주로 기록돼 있어, 미국 양식이 이란의 위협 행동을 등급화하는 구조를 갖고 있음을 보여줌. 공개된 자료를 통해 21시간짜리 단일 임무에서 다섯 차례 호출을 받았고 그중 두 번은 ‘Directive’로 분류됐다는 것도 볼 수 있음. 몇몇 보고서는 메시지를 보낼 만큼만 작전 세부사항을 드러냄. 예를 들어 d28은 무장 감시 맥락, 무기 보정, 사용 탄약, MX-25 같은 명명된 센서 시스템, AGM-176 교전 중 MX-20과 MX-25가 탐지한 물체까지 꽤 풍부하게 담고 있음. d74는 임무 후반 UAP 사건 전에 있었던 유력 차량·관심 인물에 대한 정지·추적 활동 등 표적 개발 맥락을 제공함”
Trump가 “일부 사람들은 꽤 흥미롭게 볼 것”이라는 식으로 계속 말한 게, 적대국들이 얼마나 오래, 얼마나 많은 정보가 수집됐는지 곧 보게 된다는 뜻이었는지 궁금함

• CIA reading room에서 내가 사는 지역에 대해 무엇을 갖고 있는지 봤는데, 그들이 찾아낸 것들이 지금도 남아 있는 걸 보니 꽤 충격적이었음

정의가 마침내 실현되도록, 두 번째 Unpublished American Pedophile(UAP) 문서와 영상 묶음 공개를 간절히 기다림

• 이 행정부의 진짜 유산은 파일을 팔아먹는 일이 되어가는 듯함

미국 하원의원 Luna에 따르면 이번 공개는 앞으로 몇 주 동안 이어질 여러 공개 중 첫 번째라고 함
여러 영상을 봤는데 개인적으로는 특별한 건 찾지 못했음. 목격자 진술도 다른 많은 사례들과 비슷하게 읽힘

• 진술이 다른 사례들과 비슷하게 읽힐 수는 있지만, FBI 특수요원들이 왜 굳이 이상 현상을 직접 보고하려 했는지는 이해가 안 됨
  연방 법 집행기관에서 증언의 권위가 핵심 기능인 사람들에게는 커리어 제한 행동(CLM)에 가까워 보임
  예: https://www.war.gov/medialink/ufo/release_1/western_us_event...
  2023년 9월 1일 사건 데이터의 문서 묶음 중 하나임
• 이름이 운명을 정한다는 말이 딱 맞음
• 미국 정부가 실제로 한 번에 대량 파일 공개를 할 수 있긴 한가 봄. Epstein 때문에 묻는 것임

미국 국방부가 UAP, 즉 미확인 공중 현상 관측 기록을 담은 CSV 데이터셋을 공개했음. 독립 분석과 연구에 쓸 수 있는 구조화된 항목들이 들어 있는 것 같음
데이터셋: https://www.war.gov/Portals/1/Interactive/2026/UFO/uap-csv.c...
미러: https://gist.github.com/ahmetcadirci25/e4edb7d30109fdb8ff14b...
데이터 분석, 이상 탐지, 공개 정부 데이터셋에 관심 있는 사람에게 유용할 수 있음

• 웹페이지의 네트워크 소스를 보니 CSV를 찾을 수 있었음. 다만 데이터셋은 누락 데이터가 많은 지저분한 데이터임
  예를 들어 65_HS1-834228961_62-HQ-83894_Serial_153에는 CSV와 웹페이지 모두에서 작동하지 않는 링크가 있음
  반면 NASA-UAP-D3A, Gemini 7 Audio Excerpt, 1965는 CSV에는 링크가 없지만 웹페이지의 링크는 작동함. 콘텐츠 요청에는 https://api.dvidshub.net/를 사용함
  DOW-UAP-PR36, Unresolved UAP Report, Middle East, May 2020 같은 사건 날짜는 CSV에서 N/A인데, 스니펫 내부에는 5/14/20이 아니라 5/1/20이라는 잘못된 날짜가 들어 있음. 같은 사건이 서로 다른 매체만 붙어 중복된 것도 있는 듯함. 참고로 이 사건의 영상은 꽤 설득력 있음
  데이터셋을 해부해보는 건 기대되지만 완벽과는 거리가 멈. 그래도 잠재력은 매우 큼
• 어떤 이유에서인지 Department of Defense를 Department of War로 바꾼 것 같음

꽤 멋짐. 예를 들어 FBI SEPTEMBER 2023 SIGHTING - COMPOSITE SKETCH 자산에는 “2023년 9월, 하늘의 밝은 빛에서 130~195피트 길이의 타원형 청동 금속 물체가 나타났다가 즉시 사라졌다는 일치된 목격자 진술을 묘사하는 FBI Lab 렌더링 그래픽 오버레이가 포함된 실제 현장 사진”이라고 되어 있음
https://www.war.gov/medialink/ufo/release_1/2024-04-30-compo...
이 사건의 위성 이미지가 있는지, 아니면 가까운 미래에 위성 커버리지가 더 넓어져 이런 주장을 영상으로 검증할 수 있을지 궁금함

• 카메라가 많아질수록, 즉 모두의 주머니와 거리와 하늘에 카메라가 더 많아질수록 UFO나 크립티드 목격은 줄어듦
  뭔가를 말해주는 현상임
• 이 이미지를 보고 떠오르는 단어는 “cool”이 아님
• 왜 흥분하는지 잘 모르겠음. 하늘에 있었다는 거대한 구체에 대한 상상도 아닌가? 이전에 공개된 실제 UAV 영상이 더 인상적임
• 혼란스러움. 이런 건 사진이어야 하는 것 아닌가, 아니면 3D 렌더링을 보고 감탄해야 하는 건가?

이건 순수한 선전임. 몇 주 전부터 4chan과 주류 소셜 미디어에 인위적으로 퍼졌고, 4chan 쪽에서는 회의론이 컸음
UFO에 대한 관심이나 믿음을 자기 정체성 전체로 삼고 다른 고려는 밀어내는 UFO 광신 커뮤니티가, 백신 반대나 chemtrail 커뮤니티처럼 정치적 지렛대로 무기화되고 있음

• 다음 distraction임. 11월까지 매주 새 distraction을 줄 세워둔 것 같음
• UFO 광신 커뮤니티가 정치적 지렛대로 무기화되는 건 적어도 1947년 이후로 늘 그래왔음
• 큰 Polymarket 베팅 몇 개도 정산될 듯함. “정부가 UFO가 진짜라고 발표할 것”은 오랫동안 인기 있는 베팅이었음
• 누군가를 선전이라고 부르는 사람이 있다면, 그 사람의 HN 제출 이력을 보면 패턴이 보임
  Trump 관련 정치 글, China 관련 정치 글, Iran 관련 정치 글, DOGE 관련 정치 글, RFK Jr. 관련 정치 글, Covid-19 관련 글, 경제 관련 정치 글, 선거 관련 정치 글, 반러시아·반“나치” 정치 글이 있음
  그런 이력이라면 무엇이 “선전”이고 아닌지 판단해도 된다고 믿기 어렵고, 본인도 거대한 선전 계정이 아닌지 의심스러움

지난 2년간 재미로 Mojo를 많이 써봤는데, 정말 멋진 언어임
Rust에 가까운 소유권 모델, Zig보다 강력한 컴파일 타임 실행, 풍부한 타입 시스템, 일급 SIMD 지원 등이 있음
성능 면에서도 오랜만에 단순한 LLVM 래퍼가 아닌 언어처럼 보임. LLVM은 여전히 쓰지만 Rust나 Zig와는 다른 방식으로 활용함
올해 말 오픈소스가 되면 Mojo가 매우 기대됨

• “Zig보다 강력한 컴파일 타임 실행”이라는 부분을 좀 더 설명해주면 좋겠음
  지금 Mojo 문서만 봐서는 그 결론에 도달하기 어려움

머신러닝을 하면서 성능에 관심 있는 입장에서는 Mojo가 성공하길 바람. 특히 같은 언어에서 GPU 코드와 CPU 코드를 섞을 수 있다는 점이 기대됨
다만 지금의 변화가 Python 개발자들을 멀어지게 만들지 걱정됨. 마지막으로 실행해봤을 때 기본적인 문자열 조작을 테스트하려고 var x = 'hello'; print(x[3])를 해봤는데 동작하지 않았고, len(x)도 안 돼서 한 시간을 헤맸음
알고 보니 바이트와 코드포인트 표현을 더 구체적으로 나누기로 한 것이었는데, 문서가 실제 구현과 모순됐음
일반적인 머신러닝에도 쓸 만한 상태가 되길 바라지만, 현재는 아직 꽤 제한적으로 느낌. Tensor 관련 괜찮은 기본 기능들도 일부 폐기했음
당분간은 JAX를 쓰면서 가끔 확인해볼 생각임

• 단순한 계산 중심 코드를 최소한의 추가 문법만으로 SIMD / 멀티스레드 / 멀티프로세싱 / GPU 코드로 바꿔주는 언어가 왜 아직 없는지 모르겠음
  이런 건 컴파일러와 언어 설계에 관심 있는 사람들이 꿈꿀 만한 일 아닌가 싶음
  어떤 상황에서도 효율을 보장하거나 최첨단 성능을 낼 필요는 없고, 그냥 존재하기만 해도 좋겠음
  이런 언어를 만들 수는 있다고 이해하지만, 만들 수 있는 사람의 흥미를 끌지 못한 것 같음
• Mojo는 멋지지만 Python 하위 호환성을 왜 붙잡는지 모르겠음. 그 때문에 스스로 발목을 잡고 있음
  Kotlin에서 떠오르는 단점들은 거의 Java 호환성 때문임. 여기서는 더 명시적인 방식으로 잘 풀 수도 있었겠지만, 현재 방식은 실패할 운명처럼 보임
• 오픈소스가 아니라면 별 의미 없음. 대부분의 Python 개발자는 어차피 오지 않을 것임
• 이 측면에서는 거의 Nim 프로그래밍 언어를 다시 만들려는 것처럼 보임

“Mojo를 2026년 가을에 오픈소스로 공개하겠다고 약속했다”고 되어 있음
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced

• 실제 최첨단 MLIR 프로그램의 소스 코드를 볼 수 있다면 좋겠음

안타깝게도 그 사이 Nvidia도 가만히 있지 않았고, MLIR 기반의 비슷한 컴파일러 스택을 통해 Python용, 곧 C++용 CuTile이라는 차세대 CUDA를 만들었음
이식성은 없더라도 Nvidia가 강하게 밀고, 개발 도구에 통합되며, 기존 CUDA 코드와 함께 동작한다는 이유만으로 Mojo보다 훨씬 많이 쓰일 가능성이 큼
Tile IR은 Mojo보다는 Triton의 위협에 대한 대응에 가까웠을 가능성이 큼. 적당히 성능 나오는 LLM 커널을 얼마나 쉽게 작성할 수 있느냐는 관점에서 특히 그렇다고 봄

• 뒤처지지 않기 위해 Intel과 AMD도 비슷한 노력을 하고 있고, CPython JIT도 여러 번의 시도 끝에 드디어 현실화되고 있음
  GraalPy와 PyPy 같은 시도도 있음
  이런 노력들은 모두 현재 Windows에서 동작함. 회사에서 직원 대부분에게 Windows 장비가 배정되고 서버만 Linux 배포판을 쓰는 환경에서는 꽤 중요함
  이게 또 다른 Swift for Tensorflow 같은 결말이 되지 않을까 계속 생각하게 됨
• 몇몇 Tile IR 개발자들과 이야기해본 바로는, 주된 동기는 PTX보다 텐서 코어 프로그래밍의 이식성을 더 잘 제공하는 것이었음
  고객 피드백 외에 무언가에 대한 대응이라고 말한 사람은 없었음
• 사람들이 Mojo를 GPU 코드를 쓰기 좋은 문법 정도로 착각하고, Nvidia의 Python 프레임워크가 이미 그 역할을 한다고 생각하는 경우가 많음
  하지만 CuTile이 AMD GPU나 Apple Silicon에서도 동작할까? Nvidia가 뭘 하든 여전히 벤더 종속은 남음
• CuTile의 영향력이 얼마나 큰지 궁금함

처음 Mojo를 들었을 때는 기존 Python 코드와 호환되게 만들려는 줄 알았음
하지만 가까운 미래에는 그 목표와 매우 멀어 보임. Python과 Mojo 사이를 오가며 호출할 수는 있겠지만, Mojo 자체가 기존 Python 코드를 실행할 수는 없음

• 원래 홍보에서는 분명 그게 핵심 중 하나였음. Python 코드에 타입 힌트를 추가하면 큰 속도 향상을 얻는다는 식이었음
  하지만 실제로 만들어가면서 방향이 달라진 것처럼 보임
• 기억이 맞다면 동등한 Python 대비 36,000배 속도 향상도 광고했는데, 극단적인 엣지 케이스에서만 가능하다는 점을 전혀 명확히 하지 않았음
  Python 생태계를 개선하려는 정직한 시도라기보다는 펌프 앤 덤프식 암호화폐 계획처럼 느껴짐
• 아주 주의 깊게 봤다면 처음부터 아이디어는 차세대 시스템 언어를 만드는 것이었음이 분명했음
  Swift와 Rust의 교훈을 가져오고, CPU/GPU/이기종 타깃을 겨냥하며, MLIR을 중심에 둔 언어였음
  동시에 언젠가 Python을 비교적 쉽게 임베드하거나 확장할 수 있게 염두에 둔 구조였고, Python 프레이밍은 자금 조달에 거의 확실히 도움이 됐을 것임
  Chris Lattner는 Python과 Mojo의 관계보다 MLIR과 Mojo의 관계를 더 많이 이야기했음
• 원래 광고는 그랬음. Python에 대한 Kotlin 같은 존재가 되고 싶어 했지만 금방 방향을 틀었음
  그 점과 완전히 오픈소스가 아닌 개발 모델 때문에 항상 베이퍼웨어처럼 느껴졌음
• 사이트에는 이렇게 되어 있음
  Python 상호운용성: “Mojo는 Python과 네이티브로 상호운용되므로 모든 것을 다시 작성하지 않고도 기존 코드의 성능 병목을 제거할 수 있습니다. 함수 하나에서 시작해 필요에 따라 성능이 중요한 코드를 Mojo로 옮기며 확장할 수 있습니다. Mojo 코드는 자연스럽게 Python으로 임포트되고 배포용으로 함께 패키징됩니다. 마찬가지로 Python 생태계의 라이브러리를 Mojo 코드로 임포트할 수 있습니다”

Mojo는 괜찮아 보이지만, CPU와 GPU를 아우르는 고성능 수치 계산에서는 지금 Julia에 꽤 만족함
Python 같은 문법을 제외하면 이 틈새는 이미 대부분 해결된 느낌임. Python조차 Numba와 Triton처럼 덜 복잡하고 더 독립적인 유형의 문제에 효과적인 도구들이 있음

같은 목적이라면 Julia가 더 성숙했고, 작년부터 Nvidia는 CUDA에서 Python 도구와 C++ 도구의 기능 동등성을 맞추고 있음
Python cuTile JIT 컴파일러를 쓰면 순수 Python처럼 CUDA 커널을 작성할 수 있음
AMD와 Intel도 비슷한 접근을 따라가고 있음
Mojo가 더 넓은 채택을 얻을 만큼 제때 도착할지는 아직 봐야 함

• Python cuTile JIT 컴파일러가 순수 Python으로 CUDA 커널을 작성하게 해준다는 말은 맞지 않음. 현재도 순수 Python이 아니고 앞으로도 그럴 수 없음
  이런 “성능 친화적” Python 방언들, 즉 Triton, Pythran, CuTile, Numba, Pycell, cuPy 등은 겉보기에는 Python 같지만 표면만 긁어도 전혀 Python이 아님
  최적화와 타입 추론이 잘 되도록 만들어진 Python풍 DSL임. 실제로 써보면 그렇게 느껴짐. 각각에서 많은, 어쩌면 대부분의 Python 기능을 사용할 수 없는데도 Python 고유의 문제는 여전히 감수해야 함
  솔직히 Python은 효율과 성능에 본질적으로 좋지 않음
  이건 GIL을 훨씬 넘어서는 문제임. 동적 타이핑, 참조 의미론, 몽키 패치, 극도로 동적인 객체 모델, CPython ABI, 기본 BigInt, 런타임 모듈 시스템 등은 작은 스크립팅 언어에는 말이 되지만 고성능 컴퓨팅과 효율에는 매우 나쁨
  NumPy/SciPy 생태계 자체도 단순한 CPU 바운드 텐서 산술을 위해 Python의 한계를 우회하는 해킹에 가까움
  기본 Python 성능이 너무 나빠서 단순한 for 루프조차 Excel을 경주마처럼 보이게 만들기 때문임
  Mojo는 다름
  Mojo는 기존의 문제 많은 기반을 해킹하는 대신 깨끗한 출발점에서 시작하려고 함
  그리고 30년 넘은 Python이 아니라, 지난 언어 설계 경험 위에 잘 설계된 언어로 “Python 같은 경험”을 제공하려 함
  그 이유만으로도 성공하길 바람

요즘은 적어도 일부 사람들에게 AI native를 전면에 내세우는 광고가 필요한 것 같음
하지만 내게는 좀 거부감이 듦. 실제로 아무 말도 하지 않는 표현처럼 보이기 때문임
“컴파일되고 정적으로 타입이 지정된 언어이기 때문에 에이전트형 프로그래밍에도 이상적”이라는 말이 왜 그렇고, 무슨 뜻인지 AI에 열광하는 사람들이 설명해줄 수 있을까

• AI가 부각된 이후 이런 제품과 서비스들의 첫 화면에서 절박함이 보이는 게 정말 흥미로웠음
  개인적으로 가장 웃겼던 건 IBM DB2 제품 페이지를 열었더니 AI database라고 붙어 있던 장면이었음
  컴파일 시점에 더 많은 오류를 잡으면, 에이전트가 단위 테스트나 다른 테스트 없이도 정적으로 자기 작업을 빠르게 확인할 수 있다는 뜻으로 보임
• 현재 LLM은 과거 코드의 방대한 라이브러리로 학습됐음. 따라서 가까운 미래에는 새 언어보다 이미 자리 잡은 언어에서 더 잘 동작할 것임
  특히 Python처럼 사용 가능한 오픈소스 코드가 많은 언어가 유리함. 학습할 기존 코드가 없는 신규 진입자에게는 큰 문제임
  그래서 “에이전트형” 세계에서 관련 있어 보이려면 이런 절박한 AI native 마케팅이 필요할 수도 있음. 충분한지는 시간이 말해줄 것임
• AI 열성 사용자라고 생각하진 않지만 실제로 쓰기는 함
  에이전트는 피드백을 많이 받을수록 더 잘하는 경향이 있음. 타입 검사는 멍청한 실수들을 자동으로 꽤 많이 잡아내는 데 좋음
  요지는 에이전트에게 힌트가 많을수록 대체로 더 낫다는 것임
• 무슨 뜻으로 쓴 말인지는 모르겠고, 이런 프로그래밍 언어에서 “AI native”라는 표현이 다소 무의미하다는 생각에는 동의함
  컴파일과 정적 타이핑에 대해서는, 에이전트형 프로그래밍을 할 때 컴파일 시점에 문제를 잡을 수 있는 게 매우 도움이 됨
  그러면 런타임에서 마주치는 문제가 줄고, 에이전트가 해결하기 어려운 상황도 줄어듦. 단위 테스트가 어느 정도 간극을 메울 수는 있지만 완전히는 아님
  웹사이트에 적혀 있지 않은 점은, Mojo가 에이전트형 프로그래밍에는 오히려 나쁜 선택일 가능성이 크다는 것임. 아직 Mojo 학습 데이터가 많지 않기 때문임
• 이건 새로운 “...on the blockchain”임
  Python+ruff+pycheck와 TypeScript는 기계어가 아니라 바이트코드로 컴파일됨. Rust식 의미의 정적 타입도 아님
  그런데도 모델이 둘 다에서 꽤 좋은 유효한 코드를 만들어내는 걸 봤음. 엄격하게 “컴파일”되거나 “정적 타입”일 필요는 없었음
  결국 AI는 코드를 빠르게 확인하고 반복할 수 있는 좋은 도구만 있으면 그런 속성에는 별로 신경 쓰지 않음

Modular는 올해 말 컴파일러를 포함한 전체 Mojo SDK를 오픈소스로 공개할 예정임
“Mojo 1.0은 올해 말 확정되며, 컴파일러 공개와 언어 안정성 제공도 함께 진행된다”고 되어 있음
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...

Mojo를 계속 지켜보고 있음. 솔직히 Python에서 가장 마음에 안 드는 건 문법임
여기서 다른 사람이 Julia를 언급했는데, 좋은 언어라고 생각함. 하지만 컴파일러 오류 메시지와 라이브러리 문서는 그 정도 성숙한 언어에서 기대하는 수준이 아님
예전에 읽은 블로그의 정확성 문제들도 걱정됨. 또한 바이너리 크기와 최초 실행 시간 때문에 원하는 형태의 Python 모듈을 Julia로 만들 수 있을 것 같지 않음
그렇다고 해도 Mojo가 선택지가 되길 바라고 있음. 다만 REPL을 좋아하고 Python의 동적인 성격도 좋아해서, 성능 때문에 NumPy 바깥으로 나가는 일은 결국 안 할 수도 있음

• 내게는 반대임. Python에서 유일하게 좋아하는 게 문법임
  그래서 Nim을 정말 좋아함. C 수준 속도, 컴파일 타임 실행, 메타프로그래밍, 강력한 타입 시스템, 메모리 안전성을 얻으면서 코드도 자주 짧고 우아함
  Mojo도 흥미롭지만 지금까지는 범용 프로그래밍보다 머신러닝 쪽에 주로 집중하는 것 같음. 그리고 컴파일러는 아직 오픈소스가 아닌 걸로 앎
• Mojo의 설계를 매우 좋아함. 결정적 메모리 관리가 있기 때문에 Julia와 비교할 수 없음
  Mojo가 산업용 강건한 언어가 되는 데 더 초점을 맞춘 것 같기도 함. Julia의 첫 사전 컴파일 구현이 파일 입출력을 제공하지 않는 걸 보고 충격받았음

멋지긴 한데, 처음 실행해 본 게임에서 Ruffle이 불러올 파일이 없을 수 있다며 로딩에 실패함
이후에는 활성화할 Cloudflare 스크립트가 보이지 않았는데도, 다른 브라우저로 확인해 보니 Cloudflare에 막혔음
수정: uBlock Origin에는 Cloudflare 스크립트가 보이지만 NoScript에는 처음에 스크립트 3개가 표시되지 않았던 듯함. 나중에 다시 시도해 봐야겠음

와… DLC도 없고, 시즌도 없고, 유료 콘텐츠도 없음. 그냥 콘텐츠만 있음. 게임 전체가 광고 같은 성격인 것 외에는 광고도 없고, 이게 정말 놀라움
요즘은 훌륭한 기계와 프레임워크, 온갖 가능성이 있는데도, 그 자체로 즐거운 경험을 만드는 대신 다른 목표를 향하는 느낌임. “재미”는 최소한의 실행 가능 수준까지만 우선순위가 내려간 체크박스가 되고, 콘텐츠는 광고나 사용자 유지, 사용자 포획, 오래된 데이터 수집이 되어버림
물론 Flash는 보안 악몽이었지만 기술 자체는 대단했음. 벡터 이미지 일부를 확대하는 것조차 버거워하던 Pentium 100 같은 머신에서도 Flash는 모핑 벡터 애니메이션으로 화면을 가득 채울 수 있었음
Apple이 Flash를 허용하지 않겠다는 뉴스를 들은 날이 기억남. 그때가 끝의 시작이라고 생각했음
독점 기술이었고 여러 문제가 있었지만, 그 시대 기준으로는 정말 훌륭했고 지금 봐도 좋음. 그 시대 파일 안에 문화와 시대정신이 엄청나게 갇혀 있음

예전에 몇몇 Cartoon Network 게임 작업을 했는데, 여기에는 내가 만든 것들이 안 보임. 계속 추가되면 좋겠음

• 내가 가장 좋아하던 세 개도 없네. 생각해 보니 전부 Dexter's Lab 테마였음
  하나는 거울로 레이저를 튕겨 풍선을 터뜨리는 퍼즐 게임이었고, 두 번째는 Chip's Challenge 비슷하게 Dexter가 폭주 로봇에게서 도망치며 컴퓨터 칩 같은 걸 모으는 게임이었던 것 같음
  세 번째 게임에서는 Dexter가 뜬금없이 레코드 가게를 운영했음. 기억 안 나는 특정 에피소드와 연결된 건지는 모르겠지만, 꽤 웃긴 설정이고 게임도 재미있었음
  혹시 이 게임들 중 하나라도 만들었다면 고마움. 그때 그 게임들과 다른 많은 게임에 정말 많은 시간을 썼음
  당시에는 아직 전화 접속을 쓰고 있었고 오래 온라인 상태로 있을 수 없었음. 나중에 웹사이트를 열어둔 채 연결을 끊으면, 부모님이 가르쳐 준 것처럼 창을 닫고 끊는 것과 달리 게임이 계속 돌아간다는 걸 알아냈음. 지금 보면 당연하지만, 아무것도 모르던 6~7살에게는 진짜 해커가 된 기분이었음
  그 뒤로는 방과 후 저녁 루틴이 접속해서 그날 밤 할 게임 3~4개를 고르고, 로딩시킨 다음 연결을 끊고 마음껏 플레이하는 것이었음. 그 운명의 밤에 뭔가를 해킹했다면, 그건 부모님이 나를 컴퓨터에서 떼어놓을 주된 핑계였음
• 나도 그랬음. 사용자명으로 보아 같은 나라 출신일 수도 있겠음. 그렇다면 우리 둘 다 같은 끔찍한 상사 밑에서 일했을 가능성이 큼
  잠깐은 당신이 그 끔찍한 사람일지도 모른다고 생각했지만, 그는 HN에 절대 올 사람이 아님. 실제 일을 한 사람들을 착취하고 학대하면서, 공로를 가져가거나 이력서에 언급하는 것조차 금지하는 게 그의 방식이었음
• Power Puff Girls, Dexter, Cow & Chicken 등이 나오는 어드벤처 게임을 만들었다면 고맙다고 말하고 싶음
• 나도 내가 작업한 건 하나도 없음. 다만 Cartoon Network보다 Nickelodeon 일을 더 많이 했으니 크게 놀랍진 않음
  내가 만든 CN 게임은 하나만 기억나지만, 다시 보면 알아볼 만한 게 두세 개쯤 더 있을 수도 있음
  2008~2012년 작품이 아주 적은데, 내가 그 시기에 그 일을 하고 있었음
• 내 어린 시절의 일부가 되어줘서 고마움. 아마 또래들처럼 CN 게임은 거의 전부 해봤을 것 같음. 공식적으로 보존하려는 노력을 거의 하지 않았다는 게 아쉬움

TV 네트워크와 다른 미디어 회사들이 무료 온라인 컴퓨터 게임을 제공하던 시절이 그립다. 내 게임은 Clone-a-doodle-doo와 Code of the Samurai였음
ESPN에도 훌륭한 Flash 게임들이 있었음. 집 지붕 위에서 스케이트를 타는 게임도 있었고, BMX 게임은 레이싱 버전과 프리스타일 버전이 있었던 것 같음

이런 Flash 게임을 더 보고 싶다면 Flashpoint 아카이브를 확인하면 됨
https://flashpointarchive.org/

• 대학 다닐 때 작업했던 게임 몇 개를 찾아서 꽤 멋졌음
  Pizza City: https://flashpointproject.github.io/flashpoint-database/sear...
  Cookie Party: https://flashpointproject.github.io/flashpoint-database/sear...
  컴퓨터과학을 공부하면서 이 게임들을 만들며 많은 걸 배웠음. 플랫폼 게임에는 커스텀 물리 엔진이 있었고, Pizza City의 오픈 월드는 당시 나에게 최적화가 어려웠던 기억이 남
  작업이 정말 재미있었고 PixelJam에서 이런 게임을 만들 기회를 얻은 것도 감사했음. 이 게임들은 Comedy Network와 Adult Swim용이라 같은 결이라고 볼 수 있음
• 안타깝게도 Teagames Flash 게임 대부분은 사라졌고, 여기에서도 아카이브된 걸 찾지 못했음. 당시 내 기준으로는 최고 중 일부였고, 예를 들어 Top Dog II는 정말 재미있었음
  Teagames는 인수된 것 같고 예전 게임들은 모두 사라진 듯함
• 개별 SWF 파일만 내려받는 것도 가능한가?

Cartoon Network 향수를 더 느끼고 싶다면, Cartoon Cartoon Fridays의 VHS 녹화본을 보면 됨
https://www.youtube.com/watch?v=iwcQH5bF1LI

이걸 보존해 준 사람들에게 고마움. CartoonNetwork 웹사이트는 내 어린 시절 가장 소중한 기억 중 하나였음
요즘 공식 웹사이트는 YouTube 채널로 리디렉션되는데, 정말 슬프게 느껴짐. 예전에는 인터넷에 아이들을 위한 공간이 있었지만, 이제는 모든 게 거대 플랫폼으로 향하고 있고 장기적으로는 청소년에게 해로울 것 같음

• 장기뿐 아니라 단기 영향은 어떨까? Newgrounds의 Sallad Fingers처럼 날 선 불안감이 있던 Flash 애니메이션조차 현대 빅테크 기준으로 보면 꽤 귀여운 편임

와, 멋지다
Internet Archive에도 몇 개 있음: https://archive.org/details/softwarelibrary_flash_unsorted?t...
원글을 보고 20년 만에 Teen Titans Battle Blitz가 떠올랐다면 참고할 만함

• 그 게임 정말 재미있었음. 다시 떠올리게 해줘서 고마움
• TTBB가 격투 게임에 처음 입문한 계기였고, 좋은 기억이 많음

그 Gorillaz Flash 게임 기억하는 사람 있나? 모래언덕 버기카를 타고, 랜덤하게 흩어진 장애물과 지형이 있는 3D 세계를 돌아다니는 게임이었음
9학년 컴퓨터 수업 내내 그걸 했음
그것과 netsend로 선생님들을 괴롭히는 것까지

• https://archive.org/details/gorillaz_final_drive
• 그건 모르겠지만 gorilla.bas가 떠오름. 그걸 기억한다면 꽤 대단한 일임. 내가 처음 해본 게임이었고 BASIC으로 작성된 게임이었음
• Netsend라니! 혹시 우리가 같은 반이었나 싶을 정도임
  안타깝게도 Gorillaz 게임은 잊어버렸음
• GET THE COOL SHOE SHINE!
• 맞음. 그 당시에는 이상할 정도로 첨단 기술처럼 느껴지던 경험 중 하나였음

Cartoon Orbit의 gToons를 기억한다면 이것도 있음: https://gtoons.app

• gToons를 정말 많이 했음. MSN 그룹에서 berniefoo를 만났을 때 완전 팬을 만난 기분으로 놀랐던 기억이 남
  gtoons.app에 링크된 Discord 참여를 추천함. 곧 발표가 있을 예정임
• 이거 대단하다. Orbit을 정말 많이 플레이했음

jandrewrogers: 이건 의외로 흔함. UUIDv4의 안전성은 고품질 엔트로피 소스가 있다는 가정에 기대는데, 하드웨어 결함, 일반적인 소프트웨어 버그, 개발자의 엔트로피 이해 부족으로 이 가정이 쉽게 깨짐
엔트로피 소스가 망가졌는지 감지하는 건 꽤 비싸서 거의 아무도 안 하고, 결국 충돌이 난 뒤에야 알게 됨. 그래서 많은 고신뢰·고보증 시스템에서는 UUIDv4가 명시적으로 금지됨

• LocalH: 그래서 CloudFlare가 라바 램프 벽 같은 걸 만든 것임. 그 자체가 엄청난 엔트로피 소스라기보다는, 난수 생성과 엔트로피 개념을 잘 모르는 사람에게도 눈에 보이게 만드는 효과가 있음
  엔트로피 소스는 많을수록 좋고, 상당수는 비결정적이어야 함. 작은 규모의 게임에서도 마우스 좌표, 버튼 입력 간격, 시작 버튼 누르기 전 프레임 수 같은 값을 초기 시드에 섞으면, 내부적으로 의사난수 생성기를 쓰더라도 예측이 훨씬 어려워짐. CloudFlare가 엔트로피 소스를 100개 미만으로 쓴다면 실망스러울 듯함
• Groxx: 불량 하드웨어에서 그럴듯한 중복을 본 적이 있음. 또 일부 UUID 라이브러리에서는 뒤쪽이 0으로 잔뜩 채워지는 중복 패턴도 매우 흔했음
  예전 Go 쪽처럼 “N바이트 요청했는데 3바이트만 반환됐으니 N-3바이트를 다시 요청해야 한다”는 반환값을 검증하지 않으면 생김. 대부분의 하드웨어나 운영체제에서는 잘 안 터져서 사람들이 확인하지 않고, 어느 날 운영 환경에서 수만 건 충돌로 드러남
• thecloud: 고신뢰 시스템에서는 UUIDv4 대신 어떤 대안을 쓰는지 궁금함

throwaway_19sz: 믿기 어려운 웃긴 얘기지만 사실임. 10년 전 친구가 고성장 스타트업 CTO로 합류했는데, 개발자가 200명쯤 되는 회사였고 첫 주에 UUID 생성 전용 마이크로서비스가 있다는 걸 발견함
엔드포인트 하나에 전담 엔지니어 3명, 심지어 데이터베이스 담당자까지 있었음. 새 “안전한” UUID가 필요하면 모든 팀이 이 서비스를 호출해야 했고, 서비스는 UUID를 생성한 뒤 자체 DB에 기존 발급 UUID가 있는지 확인하고, 없으면 삽입한 다음 반환했음. 마음의 평화를 위한 것이었는지, 그 팀은 자체 칸반 보드와 스프린트도 굴리고 있었음

• Aurornis: 초기에는 자원이 제한된 스타트업에서 일해서, 뭔가를 만들거나 사람을 뽑을 때마다 신중히 결정했음. 그때라면 이 얘기는 소설처럼 보였을 것임
  나중에 들어간 스타트업은 누군가 새 걱정거리를 떠올릴 때마다 새 마이크로서비스와 새 팀이 생겼음. 분기 목표가 명시적으로 엔지니어링 팀 규모 확대였고, 3~4명짜리 팀들이 자기 스프린트와 계획 회의에서 스스로 일을 만들어냈음. 안정적인 프로젝트 인력을 급한 일로 옮기자고 제안했지만, 엔지니어 수를 특정 숫자까지 늘려야 하는 KPI와 충돌한다며 막혔음
• wongarsu: 언젠가는 전사 글로벌 128비트 증가 카운터로 최적화할 사람이 나올 것임. 커지는 DB를 조회하지 않고 현재 카운터를 가져와 1 증가시켜 나눠주면 O(1)이고 빠름
  고가용성과 전 세계 배포를 위해 각 인스턴스에 전용 ID 범위를 주면 샤딩도 가능함. 상위 비트 일부는 데이터센터 ID, 몇 비트는 그 안의 ID 생성기 인스턴스에 예약하면 됨. 잠깐, 이거 어디서 본 것 같은데… Twitter가 아직도 이 방식을 쓰는지, 결국 바꿨는지 궁금함
• roryirvine: 큰 실리콘밸리 기술 회사 깊숙한 곳에서 비슷한 걸 봤음. 다만 사용 중 UUID의 마스터 목록이 다른 부서가 운영하는 외부 CMDB 서비스에 있어서 절차가 더 복잡했음
  매일 DB 덤프를 받아 “임시” ID 생성 때 확인하고, CMDB에 제대로 제출된 뒤에야 “확정” 상태가 됐음. 임시 ID가 운영에서 쓰이지 않도록 가드레일도 있었고, 쓰지 않은 확정 ID를 재활용하는 절차도 있었음. 마지막으로 들었을 때는 로컬 DB 캐시를 Zookeeper로 옮기는 6개월짜리 프로젝트를 18개월째 하고 있었음

CodesInChaos: 보통 시드가 부족한 의사난수 생성기 때문에 생김. UUID를 백엔드에서 만들었는지 프런트엔드에서 만들었는지가 중요함
프런트엔드는 의도적 충돌을 포함해 여러 이유로 근본적으로 신뢰하기 어려우니 충돌 처리가 필요함. 백엔드는 안정적으로 만들 수 있음. 과거에는 VM에서 이런 문제가 있었지만 요즘은 해결됐어야 하고, 강하게 샌드박싱된 프로세스가 안전하지 않은 대체 난수 경로를 쓰면 여전히 터질 수 있음. 프로세스나 VM 포크도 상태 복제로 충돌을 만들 수 있음

• danpalmer: Segment라는 분석 회사가 웹브라우저에서 생성한 UUID에 제품 전체를 기대고 있었다는 얘기를 들은 적이 있음. 여기저기 브라우저 UUID 충돌이 나서, 제품이 근본적으로 유용한 데이터를 만들 수 없는 상태였던 것 같음. 지금은 고쳤기를 바람

kst: “Pro Git”의 한 구절이 떠오름. <https://git-scm.com/book/en/v2>
지구상의 65억 명이 모두 매초 Linux 커널 전체 히스토리 규모의 코드를 만들어 거대한 Git 저장소 하나에 푸시해도, SHA-1 객체 충돌 확률이 50%가 되려면 대략 2년이 걸린다는 예시였음. 그래서 자연적인 SHA-1 충돌은 팀원 전원이 같은 밤 서로 무관한 늑대 습격으로 죽을 확률보다 낮다는 표현이 좋았음. SHA-1 해시는 난수가 아니고 160비트라 UUIDv4와 다르지만, 무관한 늑대 습격이라는 비유가 마음에 듦

• mega_dean: 카드 한 벌을 섞는 순열이 얼마나 큰지 설명하는 이 페이지가 떠오름: https://czep.net/weblog/52cards.html
  적도에서 10억 년에 한 걸음씩 지구를 돌고, 한 바퀴마다 태평양에서 물 한 방울을 빼고, 바다가 비면 종이 한 장을 쌓는 과정을 태양까지 닿을 만큼 반복해도 52!초 타이머의 앞 세 자리는 변하지 않는다는 식의 비유임
• swiftcoder: 반대로 사전상 공격은 꽤 현실적이고, 그 테스트 케이스 파일을 생각 없이 Git에 커밋한 사람들이 증언하듯 상당히 골치 아픔
• TacticalCoder: Git 팀이 SHA-1에 더해 SHA256 같은 다른 해시를 선택적으로 제공하려고 열심히 작업 중이지 않았나?

e12e: 관련 논의가 여기 있음: https://github.com/uuidjs/uuid/issues/546
예를 들면 crypto.getRandomValues()를 googlebot에서 테스트했더니 결정적이었다는 내용이 있음

• D2OQZG8l5BI1S06: 말은 됨. 다만 왜 브라우저에서 UUID를 생성하는지 모르겠음. 목적을 무너뜨리는 것처럼 보임

adyavanapalli: 지금 말하는 일은 너무 희귀해서, 이 순간 지구 전체가 소행성에 파괴될 가능성이 더 높을 정도임

• thomasmg: 그렇게까지 희귀하진 않음. 계산해 보니 운석에 맞는 것보다는 드물었고, 그 내용과 생일 문제를 Wikipedia의 UUID 문서에 추가한 적이 있음. 몇 년 전 삭제·교체됐지만
  실제로 운석에 맞았지만 다리 부상으로 생존한 여성이 있었다고 들었음. UUID 충돌이 났다면 소프트웨어 버그나 컴퓨터 이상일 가능성이 압도적으로 높고, 우주선일 수도 있음. 우주선이 메모리나 CPU를 건드리는 일은 생각보다 흔함
• delichon: 소행성이 말줄임표를 입력하고 댓글 추가 버튼을 누를 확률 정도임
• spindump8930: 다른 사람들이 말했듯 시드를 잘못 주면 매우 흔함. 비유하자면 지구가 SF식 고밀도 소행성대에 둘러싸여 있을 때 맞을 확률 정도임

juancn: 난수 생성기 초기화가 이상하거나 엔트로피가 부족한 것 아닌가? 커스터마이즈하지 않았다면 crypto.getRandomValues(rnds8)를 쓰는데, getRandomValues는 최소 엔트로피 양을 명시하지 않음

• Hizonner: 난수 생성기가 심하게 잘못됐을 가능성이 거의 확실하고, 아마 시드 처리 문제일 것임. 암호화도 같이 망가뜨리고 있을 가능성이 큼

Geee: 양자역학의 다세계 해석에 따르면 모든 UUID가 같은 우주 분기가 하나쯤은 있을 것임. 그 세계 사람들은 무슨 생각을 하고 있을지 상상됨

• suprjami: 아마 “그 UUID”를 만든 뒤 끝에 증가하는 숫자를 붙여 유일하게 만들 것임. 문제 해결
• BobaFloutist: 그뿐 아니라 UUID 하나만 빼고 전부 같은 우주가 훨씬 더 많을 것임. 다만 그 하나까지 쓰지 못했을 뿐임. 또는 처음 두 개만 유일하고 이후 모든 UUID가 그 둘 중 하나인 우주도 있음
• nyantaro1: 그래서 Everett식 접근을 별로 좋아하지 않음

mittermayr: 말이 안 된다는 데 완전히 동의함. 그래도 추측해 보면, 예전에는 사용자의 휴대폰에서 UUIDv4를 생성해 DB로 보냈고, 오늘 아침 충돌한 UUID는 Ubuntu 서버에서 생성됐다는 차이가 있음
UUIDv4가 어떻게 생성되는지, 생성 머신의 특성이 알고리즘에 들어가는지는 잘 모르겠지만, 유일하게 떠오르는 변화는 예전에는 기기에서 만들다가 몇 달 전부터 서버에서 만들게 됐다는 것임

• AntiUSAbah: 사용자에게 UUID를 생성하게 했다는 건가? 솔직히 실제 UUID 충돌보다 뭔가 이상한 구현을 했을 가능성이 더 높아 보임. DB가 그 충돌을 어떻게 표시했는지 궁금함
• wongarsu: 둘 다 기기에서 생성한 UUID였다면 충돌 가능성을 이해할 수 있음. 저가형 단말에서 난수 생성기 시드가 제대로 잡히지 않아 “무작위” 값이 충돌한 사례가 있었고, 라이브러리가 제대로 된 암호학적 난수 생성기 대신 값싼 난수 생성기를 쓰면 더 나빠짐
  하지만 서버에서는 특히 2026년에는 그러면 안 됨. 과거에는 VM 난수 시드가 문제였지만, 지금은 덜해야 함. 한쪽 UUID가 나쁘게 생성됐더라도 정말 무작위인 UUID가 그것과 충돌할 확률은 매우 낮으니, 양쪽 생성기 모두에 문제가 있어야 함
• stubish: UUIDv4 충돌은 통계적으로 극도로 희박함. 더 그럴듯한 건 두 시스템이 같은 시드를 썼다는 것임. 시드가 몇 바이트뿐이면 충돌 가능성이 수십억 분의 1이나 수백만 분의 1까지 올라감

dweez: 이 재미있는 글을 다시 볼 때임: https://jasonfantl.com/posts/Universal-Unique-IDs/
우주 전체를 거대한 컴퓨터로 바꿔 열죽음까지 UUID만 생성한다면, ID 공간에 몇 비트가 필요할까?

• CodeWriter23: 거기까지 갈 거면 이건 필수임: https://www.decisionproblem.com/paperclips/
• ipaddr: “지금 지구상의 모든 인간이 운석에 맞을까 걱정하느냐”는 예시는 별로일 수 있음. 운석 하나가 세계를 끝낼 수도 있고, 충분한 시간이 주어지면 그 가능성은 높아짐

beejiu: UUID를 클라이언트 쪽에서 생성하는지 서버 쪽에서 생성하는지 궁금함. 클라이언트 쪽이라면 크롤러 봇 때문일 수 있음. 예를 들어 Googlebot은 결정적 “무작위성”으로 JavaScript를 실행함

• adzm: 그 패키지의 이전 사고에서도 Googlebot의 무작위성 부족이 결론이었음: https://github.com/uuidjs/uuid/issues/546
• AgentME: 거의 확실히 이 경우이거나, 시스템 난수 생성기를 제대로 쓰지 못한 패키지의 오래된 버전을 썼거나, JS crypto API를 재구현한 낡고 깨진 폴리필을 로드했거나, 동일한 VM 스냅샷을 여러 서버에서 재개해 난수 상태가 복제되는 이상한 호스팅 구성일 가능성이 큼
  이런 종류의 설명이 진짜 무작위 충돌보다 몇 자릿수는 더 그럴듯함

merlindru: 시드 문제일 가능성이 큼. 아니라는 걸 증명할 수 있다면 아마 조금 유명해질 수 있음

erlkonig: 데이터가 충분히 많으면 무작위 값은 언젠가 충돌할 수 있고, 그때 소프트웨어가 얼마나 튼튼한지 보게 된다고 계속 팀에 말해 옴
그래도 경력 많은 개발자, 팀 리드, CIO 중에도 불가능하다고 믿고 그 상황을 처리하는 코드를 전혀 쓰지 않는 사람이 많음. 그러면 나쁜 난수 생성기가 언제든 예상보다 훨씬 빨리 시스템을 망가뜨릴 수 있고, 감지·재생성 없이 동시 손상도 가능함. malloc() 성공 여부를 확인하지 않는 부류와 같아 보임. “불가능하다면 비트를 너무 많이 쓰는 거 아닌가?”라고 묻곤 함

leni536: 우연히 일어난 게 아니라 어딘가에 버그가 있음. 대충 보니 패키지는 JS 런타임의 crypto.randomUUID()를 호출하는 것 같고, 이건 항상 제대로 시드되어 있어야 함
런타임에 버그가 있을 가능성은 극히 낮아 보이지만 모를 일임. 어떤 JS 런타임을 쓰는지 궁금함

jbverschoor: 가장 그럴듯한 원인은 uuid 패키지가 의존하는 난수 생성 패키지가 최근에 침해되어 “무작위” 숫자를 예측 가능하게 만들었다는 것임. 그 결과 공급망 공격으로 많은 암호화, SSL, 통화 관련 프로젝트가 위험해졌을 수 있음

• jbverschoor: 3주 전에 바뀐 uuid/src/rng.ts에서 무작위 배열이 const가 됐음. 모든 호출이 같은 무작위 배열을 공유하게 됨
  이후 호출이 이전 무작위 코드를 갱신하므로, 중요한 걸 생성했다면 행운을 빌어야 함. 예전 코드는 slice()로 새 복사본을 만들었음. 의도치 않은 변경일 수도 있지만, 난수 두 개를 만들어 서로 다른지 확인하는 테스트도 안 통과할 것 같은데 어떻게 지나갔는지 모르겠음

pif: 고품질 엔트로피 소스가 있어도 “그럴 것이다”를 “반드시 그렇다”로 바꿀 수는 없음. 추측하기 어려운 값이 필요하면 암호학 쪽을 찾으면 되지만, 보장된 유일성이 필요하면 직접 만들어야 함

athrowaway3z: 간단한 경험칙은 ID에 무작위 값 외에 타임스탬프를 넣을 수 있는지 생각하는 것임. 대개 답은 예이고, UUIDv7이면 충분함
정보 누출이 받아들일 수 없다는 증명을 직접 써낼 만큼 문제를 깊게 검토했다면, 축하함. 그 시스템은 강한 암호학적 해시를 쓰거나 귀찮으면 UUIDv5를 써도 될 만큼 복잡하고 느린 시스템일 가능성이 큼

darqis: PostgreSQL 18은 uuidv7을 네이티브로 지원하고, 기본값은 unique와 uuid7()로 두면 됨

tumdum_: 시드가 나쁜 의사난수 생성기임

serf: 4.72 × 10²⁸분의 1, 즉 47.3 옥틸리언분의 1 수준임. 진짜라면 복권을 사기보다 먼저 경쟁 조건이나 다른 단순한 실수를 의심하겠음

• petee: 오히려 반대로 봐 왔음. 이미 그렇게 운이 좋았다면 다른 행운이 또 올 가능성은 더 낮으니 돈을 아낄 때임
• k4rli: 복권 얘기는 말이 안 됨. 통계적으로 그렇게 희박한 일이 이미 일어났다면, 다시 일어날 확률은 더 희박해야 함

evnix: 확률 수학을 다 제쳐도, 우리가 사는 현실은 최고의 하드웨어 난수 생성기를 써도 생각보다 덜 무작위일 수 있음
보안이 중요하지 않은 곳에서는 TSID 같은 것, 아니면 uuidv7로 옮겨서 실무에서 이런 일이 사실상 안 생기게 함. 재시도로 코드를 과하게 설계하는 것보다 낫다고 봄

jordiburgos: b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd는 쓰지 말아 줬으면 함. 내 DB를 확인해 보니 이미 쓰고 있었음

• rich_sasha: 무작위로 UUID를 생성하는 건 항상 미쳤다고 생각했음. 이제는 LLM만 씀. 프롬프트는 “UUID를 생성해라. 어느 코드나 데이터베이스에서도 누구도 쓴 적 없는지 확인해라. 작업을 검토하고 각 단계를 깊이 생각해라. 추론이나 일반 영어는 출력하지 말고 UUID 자체만 출력해라”임. 천만에
• mittermayr: 역시 그랬음. 우리는 다 같은 싸구려 UUID를 받고 있고, 좋은 UUID는 큰손들에게 예약되어 있음
• robshep: 16b55183-1697-496e-bc8a-854eb9aae0f3를 쓰고 있고 아마 더 있을 것임. 모두가 여기 자기 목록을 올리면 중복을 확인할 수 있지 않을까?

pyuser583: 요즘 선호되는 UUID는 무엇인지 궁금함

smokel: 컴파일러, 우주선, 양자 효과, 최소한 obscure한 커널 버그를 탓하다가 결국 내가 버그의 원인이었다는 걸 깨달은 적이 여러 번 있음
15,000개 레코드에서 충돌은 너무 희박하니, 먼저 다른 원인을 의심하겠음. 중복 처리, 재전송된 요청, 재사용된 객체, 오해를 부르는 로그, 다른 코드 경로의 식별자 재사용 같은 것들임. 주변 코드를 조금 더 공유하면 같이 확인할 수 있음

wazoox: 아직 내게 일어난 일은 아니지만, 이틀 전 운영 중인 PHP 코드베이스 깊숙한 곳에서 이런 걸 찾았음: md5(uniqid('', true))로 만든 값을 잘라 UUID 모양으로 붙이는 createUUID() 함수였음
이런 공포가 어떻게 아직 우리 급소를 물지 않았는지 모르겠음

sedatk: uuidjs/uuid에는 Googlebot 같은 결정적 난수 생성기 클라이언트에서 중복 UUID를 생성할 수 있다는 경고가 있음
클라이언트 생성 UUID가 항상 유일하다고 기대하는 앱에는 문제가 될 수 있으니, 중복을 확인하고 우아하게 실패하거나 Googlebot 클라이언트의 쓰기 작업을 비활성화하는 전략이 필요하다고 되어 있음: https://github.com/uuidjs/uuid/commit/91805f665c38b691ac2cbd...

xyzzy123: Linux 기반 분산 시스템에서 장시간 부하 테스트가 중복 UUID 때문에 실패한 적이 있음
오래 조사한 결과 커널 버그, 정확히는 경쟁 조건 때문이었음. 다중 프로세서 시스템에서 두 프로세스가 동시에 /dev/random을 읽으면 매우 드물게, 대략 백만 분의 1 수준으로 같은 바이트를 받을 수 있었음. 먼저 난수 생성기 초기화를 볼 것 같음

baq: 실행 중인 VM이 엔트로피를 전부 가상화로 날려 버린 것 같음

• Imustaskforhelp: 이 경우가 꽤 그럴듯해 보임. 관련해서 조금 멋진 물건도 있음: https://eu.mouser.com/new/leetronics/leetronics-infinite-noi...

glaslong: 라바 램프를 좀 사야 함

0xfffafaCrash: UUID가 프런트엔드에서 생성됐는지 백엔드에서 생성됐는지 궁금함. 프런트엔드라면 엔트로피 문제보다 클라이언트 코드나 요청이 조작되어 이미 알려진 UUID가 주입됐을 가능성에 걸겠음

latentframe: 엔지니어링에서 가장 위험한 말 중 하나가 통계적으로 불가능임. 규모가 충분히 커지면 극단적 사례는 이론이 아니라 운영 이벤트가 됨

8organicbits: 작년에 실제 충돌과 그 라이브러리까지 포함해 글을 쓴 적이 있음: https://alexsci.com/blog/uuid-oops/
UUID가 충돌 저항성을 가지려면 엄격히 지켜야 하는 제약이 많고, 이번 건은 난수 생성기에 문제가 있을 가능성이 커 보임

nu11ptr: 결국 엔트로피 소스 문제임. 그래서 항상 루프 안에서 생성하고 삽입함. 충돌이 나면 우아하게 처리할 수 있음

sbuttgereit: “기술적으로 불가능”은 아님. 아주 기술적으로 가능함. 좋은 무작위성이 있으면 매우, 매우 희박할 뿐이고, UUIDv4가 중복 값을 생성하는 걸 기술적으로 막는 것은 없음

beardyw: 멍청한 질문일 수 있지만, 날짜를 16진수 초 단위로라도 붙이면 안 되나? 몇 바이트만 추가해도 지금 괜찮은 건 미래에도 괜찮도록 보장할 수 있을 것 같은데

• flohofwoe: 타임스탬프 데이터를 포함하는 다른 UUID 변형을 쓰면 됨. 예를 들어 v1이나 v7이 있고, MAC 주소를 포함하는 변형도 있음
• itsyonas: 그냥 uuidv7을 쓰면 됨
• mittermayr: 맞음, 어떤 식의 추가적인 준무작위 데이터라도 이런 일을 막는 데 도움이 됐을 것임. 다만 그게 UUIDv4의 아이디어이기도 함. 이미 많은 무작위성과 시간이 들어 있다고 생각했음

mdavid626: 다른 설명도 가능함. 예를 들어 누군가 요청을 수동으로 건드렸거나 DB를 건드렸을 수 있음

radial_symmetry: 나도 한 번 이런 일을 겪고 내가 미쳐 가는 줄 알았는데, 여기 댓글을 읽으니 안심됨

NKosmatos: “기술적으로 불가능”은 아님. 불가능한 게 아니라 아주, 아주 희박한 것임. 복권이나 Powerball을 사 봐야 할 듯함
“improbable”이라는 말을 쓸 때마다 https://hitchhikers.fandom.com/wiki/Infinite_Improbability_D...가 떠오름

• sebazzz: 사실 복권을 사면 안 됨. 그 충돌과 복권 당첨이 둘 다 일어나는 건 더 드묾
• rithdmc: 상상도 못 할 일임

sudb: 내 프로젝트 중 하나에서 CUID2를 선택한 게 실제로 좋은 생각이었다는 보상을 처음 느꼈음: https://github.com/paralleldrive/cuid2

• 내 서버에서는 sops-nix를 쓰는데, 내 위협 모델에는 충분하고 잘 동작한다고 봄. 이제 SSH 개인키를 TPM에 저장하는 방식이 궁금해짐
  서버 쪽에는 NixOps 접근도 있음. Colmena가 하는 방식을 보면 됨: https://colmena.cli.rs/0.4/features/keys.html
  핵심은 비밀값을 가진 신뢰된 머신이 원격 서버로 밀어 넣는 구조임. 지금 scp로 하는 것과 비슷하지만, 그 과정을 더 Nix답게 구동함
• 좋아하는 표현을 꺼낼 때가 됐네. “상황에 따라 다름!” 여기서 비밀값 관리는 두 문제를 동시에 다룸: 디스크 위의 비밀 파일을 보호하는 것, 그리고 시스템을 빌드하는 데 쓰는 설정 안의 비밀값을 보호하는 것. 결국 그 값들은 어딘가에는 있어야 하기 때문임
  최근 며칠 밤을 들여 내 시스템 flake에 agenix 계열을 다시 세팅했기 때문에, agenix에 대해서만 말할 수 있음. 관심 있는 사람에게는 agenix-rekey를 골랐는데, 비밀값이 들어간 .yml 파일을 둘 필요가 없고 이미 해둔 것처럼 비밀값을 전부 Nix 안에서 설정할 수 있기 때문임
  암호화된 비밀값은 Nix store에 있고, Nix store의 다른 것들처럼 전역 읽기 가능함. 그 비밀값을 푸는 SSH 개인키는 보통 실제 SSH 서버의 개인키이고, 선택적으로 그렇지 않게 할 수도 있음. 비밀값은 활성화 시점, 대략 부팅 시점에 복호화되어 /run/agenix/<user>에 놓임
  secrix라는 도구는 더 나아가 비밀값을 systemd 서비스에 묶고, 그 서비스를 비밀값이 필요한 서비스에 다시 묶음. 그래서 해당 서비스가 실행 중일 때만 비밀값이 복호화됨. 다만 실제로는 NixOS 사용자가 서비스를 자주 켰다 끄는 일이 드물어서 대부분 계속 실행 중이라는 뜻이 되기 쉽다. 사용자 생성 같은 시스템 활성화용 비밀값에는 맞을 수 있음
  agenix-rekey는 재키잉을 덜 귀찮게 만들고, secrets.nix 대신 flake 출력으로 대체해 줌. 키의 한쪽 절반으로 YubiKey 분할 ID를 쓴다. 재키잉은 그 키와 다른 절반으로 인증해서 비밀값을 복호화한 뒤, 서버의 SSH 공개키로 다시 키를 거는 과정임. 공개키는 시스템 설치 시점에 생성되며, 나는 nixos-anywhere에 --copy-host-keys를 써서 설치 클로저에서 생성된 키를 가져옴. 암호화된 비밀값은 저장소 안에 두지만, 신뢰된 빌더만 접근 가능한 별도 서브모듈에 둠
  참고로 vTPM은 대개 하드웨어 기반이 아니고, 많은 제공자는 TPM을 제공하더라도 대부분 TPM v2가 아니라 TPM v1.2만 제공함. 내 제공자인 BinaryLane도 그렇다. 보안 계층이 하나 더 생기는 건 맞지만, 실제 TPM 같은 마법의 HSM은 아니며 제공자나 호스트 노드 침해로부터 보호해 주지는 못함. 실제 HSM 기반 vTPM을 허용하려면 제공자 입장에서는 비용이 매우 클 것 같고, AWS는 AWS 가격으로 제공하는 듯함
• 나는 agenix + agenix-rekey + age-plugin-1p를 씀
  마스터 키는 1Password 안에 있어서, 노트북 디스크에 어떤 자격 증명도 두지 않고도 어느 서버의 비밀번호든 편집, 조회, 재키잉할 수 있음
  실행 중 키 접근이 필요한 서버에는 접근권을 줄 수 있음. agenix-rekey에 해당 서버가 어떤 키를 볼 수 있는지 알려주고 agenix rekey를 실행하면, 그 서버가 복호화할 수 있는 암호화된 키 버전이 Nix store에 기록됨. 해당 서버의 SSH 개인키는 그 서버에만 있고 절대 밖으로 나가지 않음. agenix-rekey는 재키잉에 공개키만 필요함
  따라서 비밀값이 털리는 경우는 내 1Password 계정이 해킹되거나, 그 비밀값을 쓰는 서버가 해킹되는 경우임
• Agenix에서는 기본적으로 암호화된 비밀값을 /etc/ssh/ssh_host_ed25519_key로 복호화한 뒤, /run/agenix.d에 마운트된 ramfs에 넣음
  그래서 맞음. 암호화된 내용, 암호화 키, 복호화된 내용이 모두 파일시스템에서 접근 가능함
• 이렇게 하면 전체 NixOS 설정을 공개로 공유할 수도 있음. 그렇게 하는 사람은 많지 않지만, Nix의 약속 중 절반은 다른 사람도 내 시스템 문제를 같이 디버깅할 수 있다는 데 있다고 느낌