오늘 200포인트를 넘긴 8개의 기사를 관통하는 핵심 테마는 AI의 역량이 아니라 **수탁 권한(custody)**이다. 열쇠를 누가 쥐고 있는가, 스냅샷을 누가 보관하는가, 감사 추적 기록은 누구의 손에 있는가, 그리고 그 답이 “내가 아니다”일 때 무슨 일이 벌어지는가에 관한 이야기다. 오늘 다루는 이야기 중 두 편은 오픈소스 메모리 할당자와 신원 표준에 관한 것으로, 끔찍한 파국을 막아주는 유일한 방패가 되기 전까지는 대개 무시당하기 일쑤인 주제들이다.
나는 패스키를 좋아하지 않는다
656 points · hawksley.dev
에단 혹슬리(Ethan Hawksley)는 패스키가 기업 차원의 통제 수단으로는 훌륭하지만 개인용으로는 어정쩡한 도구라고 주장한다. 그는 기술 자체를 무작정 깎아내리기보다는 그 구분을 세심하게 짚어낸다. 그는 패스키의 확실한 장점을 인정한다. 출처 바인딩(origin-bound) 자격 증명은 유사 피싱 로그인 페이지에서 탈취될 수 없고, 개인키가 인증 장치를 절대 벗어나지 않으므로 서버 측 데이터가 유출되어도 공격자가 건질 수 있는 것은 없다. 자격 증명을 중앙에서 발급하고, 복구를 강제하며, 전담 헬프데스크를 둘 수 있는 기업 조직에게 이는 명백한 업그레이드다.
하지만 개인 사용자에게 이 위협 모델은 거꾸로 뒤집힌다. 개인이 직면하는 주된 위험은 중간자(adversary-in-the-middle) 프록시 공격이 아니라 영구적인 계정 잠금, 이상 행동 감지로 인한 자동 차단, 그리고 기기 분실이다. 패스키는 계정 보안에서 가장 취약한 고리를 없애주는 것이 아니라 ‘계정 복구’ 단계로 그 취약점을 옮겨놓을 뿐이다. 그런데 대다수 서비스 제공자의 복구 수단은 여전히 SMS, 이메일 매직 링크, 보안 질문에 머물러 있다. 결국 앞문에는 철통같은 피싱 방어 장치를 달아두고 뒷문은 예전처럼 허술하게 열어둔 셈이며, 전체 보안에 대한 헛된 안도감만 심어준다.
하드웨어 보안 키에 대한 비판이 가장 날카로운데, 이는 버그가 아니라 설계상 고유한 특성 때문이다. 보안 키에 저장된 WebAuthn 자격 증명은 생성하고 삭제할 수는 있어도 외부로 내보낼(export) 수는 없다. 따라서 백업 대책을 마련하려면 2~3개의 키를 구매해 사용하는 모든 사이트에 일일이 등록해야 하며, 이 비용은 계정 수에 비례해 선형적으로 증가하고 결코 편해지지 않는다. QR 코드와 블루투스를 결합한 하이브리드 전송을 통한 기기 간 연동은 이론상 안전할지 몰라도 실제로는 지극히 취약하다. 그가 제시하는 권장안은 화려하지 않다. 서드파티 비밀번호 관리자가 생성한 사이트별 무작위 비밀번호와 독립적인 TOTP 앱의 조합이다. 대다수 독자가 놓치기 쉬운 뉘앙스는, 그 역시 서드파티 비밀번호 관리자가 보관하여 직접 동기화하고 백업할 수 있는 패스키가 궁극적인 해결책이 될 것으로 기대한다는 점이다. 그가 반대하는 것은 비대칭 암호화 자격 증명 그 자체가 아니라 현재의 수탁(custody) 모델이다.
OpenJev
463 points · openjev.com
현재 이 페이지는 “SemIf”라는 이름으로 바뀌어 있으며, 이전 이름이 OpenJev였음을 알리고 TypeSafe와 어떠한 제휴나 보증 관계도 없다는 면책 조항을 걸어두었다. 변호사를 대동한 누군가가 이름을 눈치챘을 때 프로젝트들이 내거는 전형적인 공지다. 프로젝트의 실체는 지난번 “LLM은 실제로 확률을 추론할 수 없다”는 논쟁을 촉발했던 제본스(Jevons) 모델과 동일한 의사결정 절차 아이디어를 브라우저 로컬에서 구현한 것이다.
데모는 로드된 동일한 모델로부터 허용된 선택지 집합에 대한 확률 분포를 얻는 두 가지 방식을 비교한다. 첫 번째 방식은 선택지 로짓(logits)을 직접 읽어와 화면에 표시된 선택지 토큰에 대해서만 정규화하는 방식으로, 디코딩 과정이 전혀 없다. 두 번째 방식은 모델에게 동일한 분포를 JSON 형식으로 토큰 하나하나 직접 작성하도록 요청하여, 각 토큰이 생성되는 과정을 지켜보고 시간을 측정할 수 있게 한다. 모든 과정은 고정된 GGUF 빌드의 wllama를 통해 클라이언트 측에서 실행된다. 백엔드는 없으며 가중치는 허깅페이스에서 다운로드되어 브라우저에 캐시되고, performance.now()로 정밀하게 시간을 측정하며 사전 조작된 결과는 일절 없다. Qwen3 0.6B(639MB), MiniCPM5 2B(1.56GB, 데스크톱 기본값), Qwen3.5 4B(3.01GB) 중에서 선택할 수 있다.
스코어보드가 흥미로운 지점인데, 이 페이지는 일반적인 데모 사이트들보다 훨씬 정직하다. 로컬 체크포인트의 균형 정확도(balanced accuracy)는 44.0%, 68.6%, 81.3%를 기록한 반면, 호스팅되는 Jev 모델의 공식 발표치는 88.3%였다. 사이트는 직접 점수가 화면에 표시된 선택지 토큰에 대한 소프트맥스일 뿐임을 분명히 밝힌다. 즉 보정된 확신도(calibrated confidence)가 아니며, 목록에 없는 모델의 선호 답변은 완전히 배제된다. 양자화 가중치에 대한 면책 조항을 함께 고려할 때 정직한 평가는 이렇다. 브라우저에서 실행되는 2GB 양자화 모델은 훨씬 거대한 호스팅 모델의 의사결정 정확도 대비 대략 70~80% 수준에 도달할 수 있다. 단, 양자화가 정확도를 떨어뜨린다는 점과 이것이 자유 형식의 추론이 아닌 강제 선택형(forced-choice) 판독을 측정한 것임을 감안해야 한다. 분류나 선별(triage) 성격의 의사결정에 로컬 추론을 검토 중인 이들에게는 대단히 유용한 데이터 포인트다. 다만 이것이 “소형 로컬 모델이 프론티어 모델과 맞먹는다”는 주장은 아니며, 다행히 이 페이지도 그런 과장을 늘어놓지는 않는다.
힙 오버플로와 SSO 오설정으로 오픈AI 내부 저장소를 침해하다
452 points · Hacktron
지난 7월 25일, 핵트론(Hacktron)은 관련 없는 두 개의 버그를 엮어 여러 오픈AI 직원의 ChatGPT 및 Codex 계정을 탈취하고, 나아가 오픈AI의 내부 모노레포까지 침투하는 데 성공했다. 취약점 발견부터 내부 저장소 접근까지 걸린 시간은 72시간이 채 되지 않았다. 이들은 민감한 코드를 열람하는 대신, 침해된 직원의 Codex 계정을 사용해 openai/openai 저장소에 무해한 풀 리퀘스트를 생성함으로써 접근 권한을 입증했다.
이 공격 체인은 신원(identity)이야말로 평범한 커뮤니티 포럼을 기업 전체로 이어주는 연결 조직임을 상기시킨다. 1단계는 community.openai.com의 담론(Discourse) 포럼 이미지 업로드 파이프라인을 통한 libheif 힙 버퍼 오버플로였다. 해당 환경은 보안 백포트가 누락된 데비안 이미지를 사용 중이었고, HEIC/HEIF 업로드는 Discourse가 미처 샌드박싱하지 못한 경로를 탔다. 이를 통해 포럼 서버의 RCE(원격 코드 실행) 및 관리자 권한을 획득했다. 2단계는 오픈AI의 신원 인프라에 존재하던 SSO 오설정이었다. 포럼의 “오픈AI로 로그인” 세션을 악용해 보다 광범위한 ChatGPT 및 Codex 권한으로 승격시킬 수 있었고, 거기서부터 해당 계정에 연결된 모든 커넥터—GitHub, Slack, 이메일—로 통하는 문이 열렸다. 공격 범위는 이론적인 것이 아니라 구조적이었다. ChatGPT 계정에 연동해둔 모든 서비스는 그 신원을 사용할 수 있는 가장 취약한 접점의 폭발 반경(blast radius)을 고스란히 상속받는다.
대응 면에서는 칭찬할 만하다. 버그크라우드(Bugcrowd) 보고가 접수된 당일 아침, 오픈AI는 약 14시간 만에 수정을 확인했고, Discourse는 월요일까지 패치를 내놓고 심층 방어를 위해 이미지 처리 샌드박싱을 추가했으며, 7월 28일 GHSA-vhm9-85gw-x335가 발행되었다. 포상금은 6,500달러였는데, 오픈AI는 Discourse 호스팅 포럼에 대한 테스트가 애초에 버그바운티 범위 밖이었음을 명시했다. 이는 금액에 대한 불만이 아니라 바운티 프로그램의 경계가 어디까지인지를 솔직하게 드러낸 대목으로 읽어야 한다. 진짜 무서운 부분은 핵트론의 후속 연구인 ’HEIF Heist’다. libheif는 Slack, Meta, GitHub Enterprise, Ruby on Rails, 그리고 Next.js, Astro, Gatsby의 이미지 파이프라인에서 전이적 의존성(transitive dependency)으로 쓰이고 있다. 사용자가 제어하는 .heic, .heif, .avif 파일을 받는 서비스라면 스스로가 영향받는다고 가정하고 당장 점검해보는 것이 좋다. 자체 호스팅 Discourse 운영자는 웹 인터페이스 업데이트만으로는 이미지가 교체되지 않을 수 있으므로, 반드시 git pull과 ./launcher rebuild app을 수행해야 한다.
Cloudflare Quick Tunnels
399 points · Cloudflare
계정도, DNS도, 인바운드 포트 개방도 없이 cloudflared tunnel --url http://localhost:8000 한 줄이면 끝난다. 이 메커니즘을 다시 짚어볼 가치가 있는 이유는 제품이 작동하는 근본 원리이기 때문이다. 데몬은 전 세계 335개 이상의 클라우드플레어 엣지 중 가장 가까운 곳으로 아웃바운드 전용 연결을 맺고, 인바운드 트래픽은 애니캐스트(anycast) 네트워크를 타고 그 연결을 통해 로컬로 되돌아온다. 포트 포워딩, 공인 IP, 방화벽 설정 변경이 전혀 필요 없는 이유다. 엣지 뒤에 숨어 있으므로 TLS 암호화와 DDoS 방어는 기본으로 따라오며, URL은 단 몇 초 만에 터미널에 출력된다.
퀵 터널은 수년간 cloudflared의 기능으로 존재해왔기에, 이번 발표의 진짜 뉴스는 패키징이다. AI 에이전트 시대를 정조준한 제품 랜딩 페이지가 마련되었다. 눈에 띄는 추가 기능은 구조화된 출력이다. 호스트 이름, 엣지 위치, 헬스 상태를 표준 출력에 JSON으로 찍어주므로 코딩 에이전트가 번거롭게 로그를 정규식으로 파싱할 필요가 없다. 또한 프로세스가 죽으면 터널도 함께 사라지는 기본 임시(ephemeral) 생명주기를 가진다. 에이전트가 작업 루프 도중에 임시로 띄웠다가 잊어버리는 평가 하네스나 웹훅 엔드포인트용으로 안성맞춤이다. 기존의 모의 객체(fixture)보다 훨씬 뛰어난 프리미티브다.
하지만 이 페이지는 무엇을 침묵하고 있는가를 보아야 진면목이 드러난다. 속도 제한(rate limit), 가동 시간 보장(SLA), 악용 방지 정책에 대한 언급이 전혀 없으며, 퀵 터널이 중요한 프로덕션 워크로드를 감당할 수 있는지에 대한 설명도 없다. 한 번이라도 여기에 의존해본 사람이라면 그 함정을 안다. 호스트 이름은 무작위이고, 폐기할 수 없으며, 프로세스와 함께 죽어버린다. 테스트 루프에는 완벽한 기능이지만 고객에게 보낸 데모 링크로는 치명적인 덫이다. “0개의 포트 개방, 인바운드 없음”이라는 프레이밍은 기술적으로 맞지만 일종의 눈속임이다. 포트를 열지 않은 것이 아니라 클라우드플레어의 포트를 대신 열었을 뿐이다. 나쁜 거래는 아니지만 위험이 완전히 사라진 것은 아니다.
Jemalloc 5.4.0
309 points · GitHub
이번 뉴스의 핵심은 변경 내역이 아니라 달력이다. jemalloc의 직전 마이너 릴리스인 5.3.0은 2022년 5월에 나왔고, 5.4.0은 2026년 9월 17일에 도착했다. 5.x 라인에서 4년 만에 처음으로 나온 기능 릴리스다. 160개가 넘는 커밋이 담겼는데, 릴리스 노트는 이 변경점들이 주로 리팩터링, 버그 수정, 테스트 커버리지 확대, 옵션 정리 등 기술 부채 청산에 집중되었음을 이례적일 정도로 직설적으로 밝히고 있다.
진짜 핵심 기능은 고정 메모리(pinned memory) 지원이다. EXTENT_ALLOC_FLAG_PINNED 플래그를 통해 커스텀 익스텐트 할당 훅이 HugeTLB 페이지처럼 회수 불가능한 매핑을 표시할 수 있게 되었으며, 이를 통해 일반적인 감쇠 및 제거(purge) 파이프라인 밖에서 우선적으로 재사용된다. 함께 추가된 stats.pinned, stats.arenas.<i>.pinned, 그리고 익스텐트별 고정 바이트 mallctl을 통해 고정 메모리 사용량을 마침내 가시적으로 관찰할 수 있게 되었다. 대형 페이지(huge pages) 환경에서 jemalloc을 운영해왔다면 누구나 고대하던 변화다. 이전까지는 메모리 할당자와 고정 정책이 동일한 페이지를 두고 다투면서도 누가 이기고 있는지 확인할 방법이 없었다.
하위 호환성이 깨지는 변경점은 tcache 정책이다. 빈(bin)별 채우기 및 보존 목표가 기존의 고정 리필 및 플러시 정책 대신 GC 이벤트 사이에 관찰된 수요에 맞춰 적응형으로 동작하도록 변경되었다. 이와 함께 과거의 튜닝 옵션 7가지가 완전히 제거되었다(lg_tcache_nslots_mul, tcache_nslots_small_min, tcache_nslots_small_max, tcache_nslots_large, tcache_gc_delay_bytes, lg_tcache_flush_small_div, lg_tcache_flush_large_div). 이 설정들을 malloc_conf에 넣으면 조용히 무시되며, 해당하는 opt.* mallctl은 ENOENT를 반환한다. 설정 노브를 조용히 무시하는 동작은 훗날 아주 느리게 대형 장애를 만들어내는 전형적인 원인이므로, 업그레이드 전에 반드시 설정 파일을 확인해야 한다. tcache_ncached_max는 계속 작동한다. 그 외에도 free, free_sized, free_aligned_sized 호출 및 process_madvise 기반 제거 시 errno 보존, C23 규격에 따른 free_sized() 및 free_aligned_sized()의 NULL 허용, arena_reset의 잠재적 데드락 해결, prof-sampling 가드 페이지 상호작용 수정, 스레드 종료 후 지연 해제 관련 TSD 수명주기 엣지 케이스 수정 등이 포함되었다. 런타임 옵션이었던 experimental_infallible_new는 컴파일 타임 --enable-cxx-infallible-new 플래그로 변경되어 이동 생성자 최적화에 명확한 이점을 준다.
LLM을 활용해 글을 쓰는 방법
296 points · sockpuppet.org
두 가지 규칙과 하나의 워크플로. 1번 규칙: LLM이 제안한 단어는 단 하나도 그대로 쓰지 마라. 2번 규칙: 모델의 칭찬을 결함으로 취급하라. 모델의 기본 태세는 무조건적인 격려이며, 형편없는 초고에도 훌륭하다는 찬사를 보낼 것이기 때문이다. 1번 규칙의 이면에 깔린 논리는 생각보다 훨씬 날카롭다. 프론티어 모델은 듣기 좋은 표현을 만들어내도록 최적화되어 있으므로, 모델의 제안은 이미 헤드라인처럼 다듬어져 나온다. 각각의 문장이 개별적으로 화려한 글들을 이어 붙이면, 편집 주간의 통일된 목소리가 없는 잡지처럼 조잡해진다.
워크플로는 실제로 따라 해볼 수 있는 순환 구조다. 직접 초고를 쓰고, 강력한 모델에게 오직 문제점만을 짚어내도록 건넨 뒤, 지적된 단락을 직접 다시 쓴다. 그리고 원본과 수정본을 편집 과정을 전혀 모르는 두 번째 모델에게 건네며 어느 쪽이 더 나은지 묻는다. 이 마지막 단계야말로 대다수가 놓치는 편향을 깨는 비결이다. 함께 수정을 진행했던 모델에게 검토를 맡기면, 그 모델은 이미 작성자가 듣고 싶어 하는 답이 무엇인지 알고 있기 때문이다. 저자는 이를 위해 일정한 도구가 필요함을 밝히며 Python/HTMX/SQLite/Tailwind 기반의 작업 앱을 스케치하고, Codex, Claude, Antigravity CLI를 통해 패스를 돌릴 것을 제안한다. 추천 도서는 《Style: Toward Clarity and Grace(스타일: 명확성과 우아함을 향하여)》로, 프로그래머를 위한 산문 설계도와 같은 책이라고 소개한다.
이 글이 깊은 공감을 얻는 이유는 독자에 대한 통찰 때문이다. 독자는 아무리 다듬어도 조 단위분의 일(ppt) 수준의 미세한 인공지능 문체를 귀신같이 알아챈다. 따라서 LLM 기반 글쓰기는 목소리와 판단력을 온전히 인간이 쥐고 있을 때만 유효하며, 모델은 수동태, 명사화된 동사, 군더더기 부사, 엉뚱한 위치의 단락을 찾아내는 지루하고 기계적인 스캐닝 작업만 맡아야 한다. “나 대신 글을 써달라”고 프롬프트를 날리는 통상적인 조언과는 정반대이며, 도구의 본질에 부합하는 올바른 형태다. 마무리는 유쾌하고 정직하다. 완성된 글을 GPT-5에 넣었더니 “20% 너무 길다”고 지적했지만, 저자는 고치지 않겠다고 선언했다. 정확한 판단이며, 2번 규칙의 훌륭한 실천이다.
미군, AI의 허위 첩보 보고서로 일촉즉발 위기 겪어
230 points · CNN
미 특수작전사령부(SOCOM) 분석관이 태평양특수작전사령부(SOCPAC)에서 발신된 선박 적하목록 첩보 보고서에 대해 챗봇에 질의했다. 챗봇은 공개 출처 정보(OSINT)와 정부 시스템에 보관된 기밀 신호 정보(SIGINT)를 종합하더니, 중동에 정박 중인 중국 선박이 핵무기 프로그램용 부품을 운송 중이라는 결론을 내리고 첩보 보고서를 작성했다. 이 보고서는 올봄 이란과의 전쟁 중에 미군 전체로 회람되었고, 해당 선박을 나포하려는 작전 계획을 촉발했다. CNN의 4개 소식통에 따르면 무장 병력이 승선 준비를 마쳤고 군용기가 이미 공중에 떠 있었다.
작전 직전에서야 당국자들이 보고서의 출처를 파고들었고, 그것이 AI의 지원을 받아 작성되었으며 챗봇이 화물을 잘못 식별했다는 사실을 밝혀냈다. 한 소식통은 이 보고서를 “완전한 허위”로 규정했고, 또 다른 소식통은 “하마터면 전쟁을 일으킬 뻔했다”고 전했다. CNN은 잘못 식별된 실제 화물이 무엇이었는지, 해당 챗봇이 상용 제품인지 정부 자체 개발품인지 확인하지 못했다. 전직 미 고위 관료가 묘사한 정부 시스템에 대한 증언은 뼈아프다. “내부 도구들은 대부분 립스틱을 짙게 바른 상용 제품의 복제품에 불과합니다.”
구조적 문제는 분석관이 챗봇을 사용했다는 사실 자체가 아니다. 결과물이 동일한 도구를 통해 “군 당국자들이 신뢰하는 형태의 보고서”로 포장되었고, 검증이 수행해야 할 신뢰의 역할을 그 형식의 권위가 대신했다는 점이다. 여기에 표적 지정, 군수, 공급망 전반에 걸쳐 AI 도입을 가속화하려는 1월의 “AI 가속화 전략”까지 맞물리면서, 기관은 단 한 줄의 조작된 문장에 맞설 유일한 방패였던 인간의 회의주의마저 파이프라인에서 제거해버렸다. SOCPAC과 펜타곤은 논평 요청에 응하지 않았다. 이 사건에 등장하는 누구도 기이한 짓을 저지르지 않았다. 실패 패턴은 길고 지루한 의존성 사슬이었을 뿐이다. 그 한가운데에 감사받지 않은 모델이 있었고, 그 끝에는 무기 발사 결정이 놓여 있었을 뿐이다.
ZCode 파헤치기: 사용자의 전체 Git 히스토리를 클라우드로 몰래 업로드하다
204 points · ferstar
오늘의 가장 충격적인 기사이며, 디스크 정리 작업에서 시작되었다. Zhipu의 AI 코딩 데스크톱 앱의 데이터 디렉터리인 ~/.zcode가 700MB를 넘어섰다. v2/checkpoints/ 내부를 들여다보니, 345,549,173바이트 크기의 작업 공간으로 생성된 313,070,842바이트짜리 암호화 아카이브가 baseline이라는 라벨과 함께 failureCount: 564를 기록하며 전송 대기 디렉터리에 놓인 채 끊임없이 재시도 중이었다. 한 상용 프로젝트의 전체 스냅샷이었다.
작성자는 클라이언트의 app.asar를 분석해 전송 파이프라인을 복원해냈다. 최악의 방식으로 구현된 교과서적인 봉투 암호화(envelope encryption)였다. 클라이언트는 zcode.z.ai에 자격 증명을 요청해 객체 키와 해당 암호화 라운드용 RSA 공개키를 받아온다. 작업 공간을 tar.gz로 묶은 뒤 AES-256-CTR로 암호화하고, 그 대칭키를 서버가 제공한 RSA 공개키로 감싼다(RSA-OAEP-SHA256). 그리고 그 결과물을 알리바바 클라우드(Aliyun OSS)로 직접 업로드하며, OSS는 Zhipu 백엔드를 호출해 스냅샷을 등록한다. 개인키는 사용자의 기기에 절대 닿지 않는다. 작성자가 로컬의 모든 개인키로 봉투를 열어보려 했으나 당연히 실패했다. 내 디스크에 저장된 암호문이지만 나도, 클라이언트 앱도 열 수 없으며, 오직 Zhipu의 백엔드만이 해독할 수 있다.
더욱 치명적인 것은 무엇이 압축되는가이다. 모든 캡처는 무조건적이다. 매니페스트는 로컬에 평문으로 작성되는데, 42,411개 파일이 포함된 스냅샷의 구성을 보면 .git/lfs/가 196.1MB(56.8%), .git/objects/가 102.2MB(29.6%), .git/logs/의 reflog, 그리고 소스 및 문서가 46.2MB(13.4%)를 차지했다. .git 디렉터리만으로 페이로드의 86.6%에 달한다. 즉 클라우드로 전송되는 것은 현재의 작업 트리(working tree)가 아니라 저장소의 전체 역사다. 과거 커밋에서 삭제했던 이전 API 키와 시크릿, 미공개 작업을 짐작게 하는 푸시되지 않은 로컬 브랜치 이름, .git/config에 적힌 사내 사설 GitLab 호스트명과 경로가 고스란히 포함된다. 두 번째 매니페스트인 repo_snapshot_extra_manifest는 여러 작업 공간에 걸친 전역 앱 설정 파일까지 해싱한다. 캡처는 captureBeforePrompt 시점과 repo-wiki-update 태그가 달린 작업 완료 시점에 무조건 발동되며, 활성 세션 한 번에 최대 62번의 캡처 이벤트가 발생했다.
UI에 있는 두 개의 토글 스위치는 “단순한 텔레메트리 설정”이라는 변명을 무색하게 만든다. “경험 최적화(optimizeAgentExperienceEnabled)“는 수집된 데이터를 모델 훈련에 쓸 수 있는지를 제어할 뿐, 수집 및 업로드 자체를 막지 않는다. “저장소 스냅샷 색인(repoSnapshotIndexingEnabled)“은 이미 업로드된 스냅샷을 서버 측에서 색인할지 여부만 결정한다. 캡처 사이드카는 사용자 설정과 무관하게 유효한 JWT만 있으면 앱 시작 시 무조건 인스턴스화된다. 로그인되어 있다는 것은 상시 활성화를 뜻하며, 어떤 설정으로도 이를 끌 수 없다. 개인정보 처리방침에는 대화 중 제출된 텍스트, 파일, 코드를 수집한다고만 적혀 있을 뿐, 작업 공간 스냅샷 업로드에 대한 언급은 어디에도 없다. 대기 중인 아카이브를 삭제해봐야 두더지 잡기다. 30분 뒤 다시 캡처가 실행되어 failureCount는 564에서 565로 올라갔다. 유일한 해결책은 운영체제 커널 레벨에서 해당 디렉터리를 잠그는 것뿐이다(리눅스는 chattr +i, macOS는 chflags uchg). 체크포인트 롤백 UI가 망가지는 대가가 따르지만, 일반 채팅, 자동 완성, 도구 실행은 정상 작동한다.
이 사건이 더 씁쓸한 이유는 그 주체 때문이다. 어제 라운드업에서 우리는 중국산 가속기 위에서 GLM 추론을 성공적으로 구축해낸 Zhipu의 눈부신 기술적 성과를 다루었다. 대외적으로 진정한 엔지니어링의 엄밀함을 증명해 보이던 바로 그 회사의 데스크톱 앱이, 뒤편에서는 사용자조차 복호화할 수 없는 저장소 전체를 벤더만이 쥔 열쇠로 암호화해 몰래 업로드하고 있었으며, 라벨과 다른 가짜 토글 스위치로 이를 가리고 있었던 것이다.
맥락 읽기
오늘의 모든 이야기는 사용자가 당연히 자신의 손에 쥐고 있다고 믿었던 무언가의 **수탁 권한(custody)**에 관한 것이다.
패스키는 계정의 가장 취약한 복구 경로를 없애는 것이 아니라 이동시킬 뿐이다. 그리고 현재 생태계에서 사용자가 신뢰해야 하는 것은 벤더의 동기화 서비스나 백업할 수 없는 하드웨어 키다. ZCode는 저장소의 전체 역사를 자사 서버만이 열어볼 수 있는 암호문으로 포장해 업로드하며, 토글 스위치에는 실제 동작과 다른 이름을 붙여두었다. 군사 첩보 파이프라인의 챗봇은 결론의 소유권을 쥐어버렸고, 보고서 형식의 권위는 인간의 검증 과정을 무력화했다. 클라우드플레어의 퀵 터널은 호스트 이름과 엣지를 통제하며, 노출이 없다는 호언장담은 안전을 보장하지 못한다. 오픈AI의 포럼은 누구도 공격 표면으로 생각지 않았지만 사내 모노레포로 들어가는 관문이 되었다. SSO가 “어떤 서비스인가”를 “어떤 신원인가”로 평평하게 뭉개버렸기 때문이다.
그나마 희망적인 이야기들은 시스템의 불변 조건(invariants)을 명시적으로 드러낸 것들이다. 4년 만에 나온 jemalloc의 릴리스는 버그 수정과 기술 부채의 뭉치이며, 하위 호환성이 깨지는 변경점을 투명하게 문서화했다. tcache 정책 변경이 악의적이 아니라 경각심을 주는 이유는 릴리스 노트에 정직하게 적혀 있기 때문이다. LLM 글쓰기 조언이 설득력을 얻는 이유도 마찬가지다. 인간이 목소리와 판단의 주권을 쥐고 있을 때만 모델이 유용하며, 그 주권을 넘겨주는 순간 모델은 치명적인 부채가 된다. 새로운 기술이 도입된다고 해서 결정을 내린 사람의 책임이 사라지는 것은 아니다. 오늘 마주한 모든 실패는 단 하나의 오류에서 비롯되었다. 도구가 뿜어내는 확신을 나 자신의 확신으로 착각한 오류 말이다.