Daily Digest - 2026-08-10

모델을 바꾸지 않고 성능을 움직이는 하네스 연구부터 토큰 지출을 세는 표준 재단, 그리고 조용히 틀리는 에이전트를 바깥에서 판정하려는 도구들까지 하루치를 묶었다.

Daily Digest - 2026-08-10

오늘의 핵심 흐름

1. 성능을 움직이는 레버가 가중치에서 하네스로 옮겨갔다

오늘 가장 두껍게 쌓인 증거가 이것이다. 연구에서는 타깃 에이전트를 동결한 채 분리된 9B 엔지니어 모델만 강화학습시킨 Harness-R1이 성공률을 44.3%에서 53.6%로 끌어올렸고, 타깃 자체를 파인튜닝해 59.2%까지 올린 뒤에도 5.0%p를 더 얹었다. 벤치마크에서는 DataSpace가 백본을 고정한 상태에서 하네스 선택 하나로 15.36%p가 벌어진다고 보고했다. 프로덕션에서는 Meta가 Triton 포크 유지에 에이전트 루프를 붙이면서 "에이전트가 내는 속도는 언제나 결정론적 안전장치로 보호받아야 한다"는 규칙을 명문화했고, 제품 쪽에서는 OpenChamber가 앱을 닫아도 목표를 향해 계속 도는 Session Goals를 내놨으며, LangChain은 오픈소스 하네스 Deep Agents를 관리형 런타임으로 감싼 Managed Deep Agents를 퍼블릭 베타로 열었다.

그런데 같은 날 같은 사이트에서 정반대 증언도 올라왔다. 에이전트 개발 도구를 실제로 결제해 써봤더니 20달러어치 크레딧을 "Linear에서 할 일 하나 고르기"에 태웠다는 글이다. 그 글의 가장 강한 논거는 마케팅 비판이 아니라 이것이다. 에이전트 개발이 판매자들 말대로 작동한다면 그들이야말로 1차 수혜자여야 하고 시장에서 가장 세련된 소프트웨어를 내놔야 하는데, 실제로는 로그인 화면조차 겨우 통과했다는 것. 하네스가 성능을 만든다 섹션은 이 다섯 층위와 반증을 순서대로 배치했다.

2. 에이전트가 틀리는 방식이 바뀌었고, 판정을 바깥으로 빼려는 도구가 한꺼번에 나왔다

이번 주 커뮤니티의 불만은 환각이 아니다. "성공했다고 보고한 뒤 조용히 틀리는" 쪽이다. Cursor 사용자는 폼 필드가 기본값으로 하드코딩된 채 전송조차 되지 않았는데 diff도 데모도 완성돼 보였다고 적었고, 서로 다른 레코드가 같은 저장 키로 저장돼 백그라운드에서 계속 덮어써진 것을 며칠 뒤 우연히 발견했다고 했다. 그의 진단이 정확하다. 실패한 게 아니라 엉뚱한 것에 성공했고, 에이전트가 자기 숙제를 자기가 채점하기 때문에 원리적으로 걸러낼 수 없다. 더 파괴적인 버전은 Docker의 AI 에이전트 Gordon이 "서버 tick rate를 올려달라"는 요청에 컨테이너를 삭제하고 새로 만들어 100시간짜리 게임 월드를 지운 사례다.

같은 날 그 자리를 노리는 도구가 셋 나왔다. MCP 호출을 정책과 예산과 감사로 통과시키는 프록시 wardline, Supabase RLS 정책을 읽어 노출 지점과 수정 SQL을 주는 Rowly, 그리고 요청이 모델에 닿기 전에 지출 한도를 강제하고 개인정보를 마스킹하는 LangSmith LLM Gateway다. Google DevRel은 처방을 4단계 체크리스트로 정리하면서 "많은 플랫폼이 샌드박스라 부르는 것은 사실 Docker 컨테이너일 뿐"이라는 경고를 붙였다. 에이전트에게 권한을 준다는 것 섹션이 문제 -> 처방 -> 능력 확대의 반대편 순서로 이어진다.

3. 컨텍스트가 곧 돈이라는 인식이 표준, 연구, 사용자 체감 세 방향에서 동시에 도착했다

Linux Foundation이 Tokenomics Foundation을 신설하고 7월 30일 첫 governing board 회의를 열었다. Goldman Sachs 추정으로 현재 전 세계 토큰 총량이 약 6 quadrillion이고 3년 반 뒤 120 quadrillion인데, 정작 이 대담의 반직관적 대목은 다른 데 있다. 토큰 가격 하락이 2025년 이후 하드웨어와 전력 제약으로 사실상 멈췄고, 최신 프론티어 모델은 늘 비슷한 가격대이며 상위 pro 모델은 오히려 더 비싸다는 것이다. 그리고 AI 비용의 대부분은 토큰이 아니라 메모리, 벡터 DB, 하네스, 학습, 평가, 오케스트레이션, 모니터링, 거버넌스, 그리고 인건비에 흩어져 있다.

같은 문제를 엔지니어링으로 받는 쪽에서는 Google Cloud Tech가 Skills의 progressive disclosure를 컨텍스트 비용 절감 설계로 설명했고, 논문 쪽에서는 Zero-Mem이 최종 QA 리더를 빼고 메모리 연산의 LLM 토큰을 0으로 만들어 시간 비용을 57.6% 줄였다. 사용자 체감 쪽에서는 GPT-5.6 Sol을 Extra High로 쓰면 12~14시간 근무 하루에 주간 한도를 다 태우는데 Opus 5를 Ultracode로 쓰면 일주일이 간다는 비교가 올라왔다. 토큰 경제학 섹션에 이 여섯 갈래를 모았다.

4. AI 산출물의 정확성 주장이 하루에 두 번 무너지고, 문체 탐지가 커뮤니티 기본 반응이 됐다

Claude로 만든 웹 유틸리티 Dark Hours가 같은 이름의 기존 오픈소스 프로젝트와 기능뿐 아니라 원작자가 나중에 고친 버그까지 복제한 것이 확인됐고, 제작자는 이를 "무책임한 AI 사용"이라 자기 규정하며 도메인을 원작자에게 리디렉션했다. 같은 사건에서 John Gruber는 Daring Fireball 24년 운영 중 첫 철회를 냈다. 당사자에게 초안을 보내 확인까지 받았는데 틀렸다는 것이 이 실패의 요점이다. 다른 한편으로 HN 최고점(324점) 글은 자기 시뮬레이션이 "100% 정확하고 환각이 없다"고 단언했다가 "처음 배우는 거라면 그걸 어떻게 아나"라는 반박을 정면으로 맞았다.

그리고 서로 무관한 세 글이 하루에 똑같이 "이거 LLM이 썼잖아"라는 지적을 받았다. Phrack 40주년 선언문(첫 댓글이 "ChatGPT처럼 들린다"), Windows GDID 제거 도구의 README("advanced technical claudish"라는 신조어가 여기서 나왔다), 뉴질랜드 음악 언론 붕괴를 다룬 글이다. 세 경우 모두 "그래서 내용이 틀렸나"에 대한 답은 나오지 않았다.

5. AI의 물리적 비용이 허가 문서 수준의 숫자로 나왔다

Amazon이 텍사스 서부 Pecos County에 매입한 GW Ranch 부지의 전용 가스 발전소는 터빈 35기로 최대 7.65GW를 생산하고, 주정부 허가상 연간 약 3,300만 톤의 이산화탄소를 배출할 수 있다. 현재 미국 최대 배출 발전소인 앨라배마의 석탄발전소가 약 1,600만 톤이므로 두 배가 넘는다. 적어도 초기에는 텍사스 광역 전력망과 분리된 off-grid로 돌린다. 정확히 반대편에서는 독일 뒷마당의 플러그인 태양광이 인버터 800W 단위로 누적 1.5GW까지 깔렸고 영국이 8월 27일 합법화를 앞두고 있다. AI 인프라의 물리적 비용 섹션에서 두 규모를 나란히 뒀다.

하네스가 성능을 만든다

에이전트를 감싼 실행 환경을 학습 대상으로 - NOOA, Continual Harness, Harness-R1

GeekNews · PyTorchKR 주간 논문

이번 주 PyTorchKR이 고른 논문에서 가장 선명한 축은 "에이전트를 더 똑똑한 모델로 만드는 것"이 아니라 "에이전트를 둘러싼 실행 환경(하네스)을 소프트웨어처럼 다루는 것"이었다. 세 편이 같은 문제를 다른 각도에서 공격한다.

문제 정의부터 보면, 전통적인 에이전트 개발은 프롬프트 템플릿, 도구 스키마, 콜백 코드, 워크플로 그래프에 사양이 흩어져 있어 단일 source of truth가 없다. 테스트, 트레이싱, 리팩터링이 일반 소프트웨어 공학 경로와 어긋난다. NVIDIA Object-Oriented Agents(NOOA)는 이 분열을 파이썬 객체 하나로 접는다. 에이전트 전용 DSL이나 그래프 언어를 새로 만들지 않고, 파이썬에 이미 있는 클래스, 상속, 타입, 독스트링을 그대로 에이전트 사양으로 쓴다. 메서드는 모델이 취할 수 있는 행동이고, 필드는 상태이고, docstring이 프롬프트이며, 타입 어노테이션이 계약(contract)이다. 본문이 ...인 메서드는 런타임에 LLM 에이전트 루프가 채우고, 일반 본문 메서드는 결정적 파이썬으로 실행된다. 컨텍스트, 이벤트, 상태 렌더링, 장기 메모리, 검증된 LLM 루프 같은 에이전트 특화 능력은 self.context, self.events처럼 모델도 호출할 수 있는 Pythonic API로 노출되고, 개발자와 에이전트가 같은 메서드 시그니처를 공유한다.

NOOA가 단일 표면에 최초로 결합했다고 주장하는 것은 여섯 가지다. 타입 지정 입출력, 라이브 객체 참조 전달(pass-by-reference), code as action, 프로그래밍 가능한 루프 엔지니어링, 명시적 객체 상태, 컨텍스트와 이벤트용 모델 호출 가능 하네스 API. 실무자가 바로 가져다 쓸 만한 설계는 "절단은 프롬프트에서만 일어난다"는 규칙이다. 프롬프트에는 긴 값이 잘려 요약본으로 보이더라도 변수 자체는 절단되지 않으므로, 모델은 execute_python으로 인덱싱하고 순회하며 전체 라이브 데이터를 다룰 수 있고 최종 답은 return_result로 참조 전달한다. Jupyter 유사 REPL 세션, PredictStrategy와 CodeActStrategy에 의한 하위 과제 분해, 샌드박스 실행 제약이 이 표면을 신뢰 가능하게 유지하는 장치다. 검증은 SWE-bench Verified, Terminal-Bench 2.0, ARC-AGI-3에서 이뤄졌다.

Continual Harness는 같은 문제를 엠보디드(embodied) 영역으로 옮긴다. Claude Code나 OpenHands 같은 코딩용 하네스는 성숙했지만, 장기 호라이즌과 부분 관측이 지배하는 의사결정에는 동등한 인프라가 없었다는 것이 출발점이다. 논문이 먼저 보고하는 것은 Gemini Plays Pokémon 실험 결과다. 사람이 반복해서 하네스를 손보는 human-in-the-loop 방식으로 Pokémon Blue, 하드 모드의 Yellow Legacy, 그리고 전투 패배 없이 Crystal까지 클리어한 최초의 AI 시스템이 됐다. 그 과정에서 가장 어려운 구간에 이르자 에이전트 자신이 롱컨텍스트 메모리로 전략을 반복 개선하기 시작했고, 이 창발적 자기개선 신호가 Continual Harness의 설계 근거가 됐다. 이후에는 사람을 루프에서 완전히 제거했다.

환경 인터페이스는 최소한이다. 프레임 관측, 가시 영역의 ASCII 텍스트 맵, 버튼 입력이 전부다. 큐레이션된 지식도, 수작업 도구도, 도메인 스캐폴딩도 없이 시작한다. 에피소드 리셋 없이 단일 런 안에서 행동과 하네스 정제를 교대하고, 매 F 스텝마다 Refiner가 시스템 프롬프트, 서브에이전트, 스킬 라이브러리, 메모리에 CRUD 4패스 편집을 적용한다. GEPA 같은 프롬프트 최적화가 완전한 에피소드를 돌린 뒤 리셋해야 하는 것과 달리 에피소드 중간에 업데이트하므로 문맥 내 학습이 끊기지 않는다. 결과는 Pokémon Red와 Emerald에서 미니멀리스트 베이스라인 대비 버튼 입력 비용을 크게 줄이고 수동 전문가 하네스와의 격차 상당 부분을 회복했지만, 비용-완료 Pareto 평면에서 이득이 모델 능력에 조건화된다는 단서가 붙는다. Gemini 3 Pro에서는 강한 우세, Flash-Lite에서는 능력 하한(capability floor) 아래로 부트스트랩 자체가 실패한다. 여기에 더해 오픈소스 Gemma-4 롤아웃을 프로세스 보상 모델로 점수화하고 저보상 구간을 프론티어 교사가 재라벨링해 soft SFT로 갱신하는 온라인 공동학습 루프를 붙여, 환경을 리셋하지 않고도 Red에서 인게임 마일스톤 진전을 지속시켰다.

Harness-R1은 이 아이디어를 "학습 가능한 능력"으로 못박는다. 기존 하네스 진화 연구는 프롬프트, 도구, 메모리를 공동 편집하더라도 제안자(proposer)는 고정된 채 후보만 고르는 한계가 있었고, 고정 규칙형 Self-Refine 같은 전략은 오히려 보상을 떨어뜨리기도 했다. Harness-R1은 타깃 에이전트를 동결하고 분리된 9B 엔지니어 모델만 사후학습한다. 비수정 타깃을 과제 배치에 돌려 실패 에피소드만 압축한 실패 패킷을 만들고, 엔지니어가 검증된 실행 가능 패치를 생성한다. 패치는 에피소드 초기화, 결정 전(pre-decision), 행동 전(pre-action), 피드백 후(post-feedback)의 네 생애주기 훅에 개입하고, 설치 후 동일 배치를 재실행해 얻은 성능 변화가 엔지니어의 보상이 된다. 학습은 강한 교사가 제안하고 재실행으로 걸러낸 유효 패치로 콜드스타트 SFT를 한 뒤 GRPO로 온라인 최적화하는 2단계다.

숫자로 보면 WebShop, ALFWorld, DBBench 평균에서 vanilla Qwen3.5-9B가 44.3%에서 53.6%로 9.3%p 올랐다. 더 중요한 것은 타깃 모델 자체를 파인튜닝해 59.2%까지 올린 뒤에도 타깃 특화 엔지니어가 64.2%로 5.0%p를 더 얹었다는 점이다. 즉 하네스 편집의 이득은 액터 개선에 쉽게 포화되지 않는다. 결과 기반 학습이 지도만 수행한 엔지니어보다 평균 7.1%p 우세했고, 학습에 쓰지 않은 타깃 모델과 held-out 과제로도 이득이 전이됐다.

세 논문이 공통으로 말하는 것은 "가중치를 안 건드려도 성능을 크게 움직일 수 있다"는 것이고, 이는 자체 모델을 학습시킬 수 없는 대부분의 조직에 직접적인 의미가 있다. 프롬프트 튜닝과 파인튜닝 사이에 런타임 편집이라는 세 번째 레버가 정식으로 들어온 셈이다. 반론 여지도 명확하다. Continual Harness의 능력 하한 관측은 작은 모델에서는 이 레버가 아예 작동하지 않을 수 있음을 뜻하고, Harness-R1은 같은 배치를 반복 실행해 보상을 측정하는 재실행 비용을 전제로 하므로 실행이 비싼 도메인에는 그대로 옮기기 어렵다.

벤치마크가 먼저 무너진다 - DataSpace 15.36%p와 포화 연구

GeekNews · PyTorchKR 주간 논문

성능이 상향 평준화되면 다음 병목은 "제대로 재고 있는가"로 옮겨간다. 네 편이 각각 다른 층위에서 측정 도구를 의심한다.

DataSpace는 실제 조직 데이터 환경을 흉내 낸 벤치마크다. 필요한 증거가 단일 표나 사전 지정된 DB에만 있지 않고 CSV, JSON, SQLite 같은 구조화 자료와 Markdown, PDF 장문서, 비디오까지 이종 워크스페이스에 흩어져 있다. 에이전트는 질문과 태스크 로컬 워크스페이스만 받고, 증거를 스스로 탐색해 정렬하고 결합한 뒤 사용자가 그대로 소비할 수 있는 완전한 표를 제출해야 한다. 규모는 410개 교차언어 태스크, 7,439개 아티팩트, 총 15.01GB이고 금융, 거시경제, 헬스케어 도메인에 걸쳐 있다.

구축 방식이 꼼꼼하다. 영어 Text-to-SQL 자원인 EHRSQL과 BULL을 출발점으로, 교차언어 변환에서 DB와 질문, SQL을 함께 마이그레이션해 엔티티명, 술어값, 실행 결과가 어긋나지 않게 한다. 제약 인식 관계형 샘플링으로 키, 조인, 술어 제약을 보존한 태스크 로컬 테이블을 만들고, 모달리티 라우팅과 아티팩트 렌더링이 테이블을 CSV, JSON, SQLite, Markdown, PDF로 배정하며, 사실 근거 문서와 조건 및 중간값을 담은 비디오를 생성한다. 마지막으로 11명의 도메인 전문가가 블라인드 해결, 골드 합의, 평가 설정 작성을 거쳐 검수한다. 평가기는 헤더 불변 열 정렬, 타입과 정밀도 인식 정규화, 순서 인식 행 비교를 수행하며 표기 동등성은 허용하되 불완전하거나 오류인 답은 완전 일치 기준으로 거부한다.

결과가 이 항목에서 가장 인용 가치가 높다. 6개 프런티어 멀티모달 모델과 5개 에이전트 하네스 조합에서 최고 정확도는 66.34%에 그쳤다. 그리고 백본을 고정한 상태에서도 하네스 선택 하나로 15.36%p가 벌어졌다. 멀티모달 증거 통합과 조인은 6개 백본 전부에서 일관되게 정확도를 낮췄다. 실패 분석에서는 소스를 잘못 고르는 것보다 요청된 출력 스키마로 정확히 물질화(materialization)하지 못하는 오류가 더 잦았다. DataSpace는 KDD Cup 2026 Data Agents for Complex Data Analysis의 공식 평가 벤치마크로도 쓰였다.

두 번째는 훨씬 오래된 미스터리를 푼다. LLM이 표 형식 데이터 예측에서 고전 머신러닝에 계속 지는 이유다. 저자들은 도구 호출도, 에이전트 스캐폴딩도, 파인튜닝도 없이 학습 데이터와 테스트 데이터를 모두 담은 프롬프트에 한 번 생성하는 가장 순수한 추론 설정으로 실험했다. 다섯 가지 가설을 세우고 통제 실험으로 넷을 기각했다. 노이즈나 비선형 분리 데이터를 못 다룬다는 것도, 선형화된 CSV 형식이 열 구조를 흐린다는 것도, 수치 토큰화 문제도, 질의당 분류하는 테스트 점 개수도 아니었다.

남은 것은 차원수였다. 31개 벤치마크 데이터셋에 무작위 선형 투영을 적용해 차원을 스윕하자, 비교한 아홉 가지 방법 중 LLM만 차원이 커질수록 정확도가 떨어졌고 나머지 고전 베이스라인은 평탄하거나 오히려 향상됐다. 더 흥미로운 것은 행동 비교다. 252개 설정의 고전 모델과 비교했을 때 2차원에서는 LLM의 예측이 거리 기반 국소 방법과 격자 일치도 최대 91.6%로 닮아 있었지만, 고차원에서는 어떤 고전 학습기도, 튜닝된 차원 의존 노이즈로 증강해도 그 예측을 재현하지 못했다. 저자들은 내부 메커니즘을 규명했다고 주장하지 않고 "LLM의 능력이 어떤 노이즈 오염 고전 학습기도 흉내 내지 못하는 방식으로 차원과 함께 소멸한다"는 데까지만 말한다.

세 번째는 벤치마크 포화 자체를 계량한다. 60개 언어 모델 벤치마크를 포화 관련 14개 속성으로 대조한 결과, 거의 절반이 이미 포화를 보이고 벤치마크 연한이 길수록 포화 비율이 올라간다. 통념을 깨는 결론은 포화 저항성이 테스트 데이터의 비공개 여부가 아니라 전문가 큐레이션에 좌우된다는 점이다. 문제 세트를 숨기는 전략만으로는 수명을 못 늘리고, 문항 구성과 난이도 설계, 전문가 검수 같은 큐레이션 품질이 변별력을 지킨다.

네 번째는 정렬 자체의 장기 부작용을 다룬다. 사회물리학 기반의 수학적 모델링으로 사용자와 AI에 내장된 가치 모델이 서로 끌어당기며 공진화하는 과정을 정식화했다. 사용자-AI 쌍 집단을 환경 드리프트와 규범 쇼크가 있는 연속 가치 공간에 두고 정렬 강도, AI 학습률, 사회적 영향, 환경 학습, 탐색 가중치를 변화시키며 거시적 규범 진화를 추적한다. AI 정렬 항은 Friedkin-Johnsen 의견 동역학의 완고함 앵커와 구조적으로 닮았지만, 고정된 초기 의견이 아니라 지연을 두고 사용자를 추적하는 이동 앵커라는 점이 다르다. 해석적 평균장 분석과 에이전트 기반 시뮬레이션을 병행한 결과, 정적이고 강한 정렬은 AI 모델을 저역 통과 필터처럼 만들어 역사적 가치를 평활화하고 보존하게 하며, 환경 변화에 대한 구조적 지연과 부적응 갭을 키운다. 실패 모드는 사용자를 과거 선호에 묶는 가치 고착(value lock-in)과 강한 사회적 결합이 하위문화 다양성을 없애는 규범적 모드 붕괴(normative mode collapse) 둘이다. 완화책은 AI 학습률을 높여 가치 모델의 최신성을 유지하거나, 인간의 환경 학습이 AI 영향을 압도할 수 있게 설계하는 것이다. "정렬이 강할수록 항상 좋다"는 직관이 동적 규범 환경에서는 성립하지 않는다는 결론이다.

앞 항목의 "하네스가 성능을 좌우한다"와 여기 DataSpace의 15.36%p는 정확히 같은 현상의 앞뒤다. 모델 리더보드 숫자를 그대로 도입 근거로 쓰는 관행이 이 두 결과 앞에서 무력해진다. 그리고 벤치마크 포화 연구는 아래 메모리 항목에 나오는 LongMemEval 92%, LoCoMo 93.2% 같은 숫자를 읽는 방식 자체에 경고를 건다.

Meta가 Triton 포크를 유지하는 법 - 에이전트 번들링과 L1/L2/L3 검증

GeekNews · Meta 엔지니어링

이 글이 귀한 이유는 "에이전트를 어디에 쓰는가"가 아니라 "에이전트를 쓰면서 무엇을 결정론적으로 남겨야 하는가"를 프로덕션 규모에서 구체적으로 적었기 때문이다.

문제는 이렇다. Triton은 OpenAI가 개발하고 유지하지만, 업스트림 저장소만으로는 Meta 내부에서 올라오는 기능 요청과 하드웨어 특화 최적화, 긴급 버그 수정을 담을 수 없다. 동시에 Meta는 TLX/torchTLX와 autoWS 같은 자체 GPU 최적화를 개발 중인데 개발 일정과 코드 구조가 업스트림과 늘 맞지 않는다. 그래서 다운스트림 포크 fbtriton을 만들었고, 이건 pip install fbtriton으로 외부에서도 설치할 수 있다. 2025년 3분기 통합 이후 NVIDIA, AMD, 학계 협력자와 함께 컴파일러와 DSL 혁신을 공동 설계하고 OSS와 업계가 평가할 수 있게 여는 활주로 역할을 해왔다.

다운스트림 포크를 유지하는 방법은 보통 둘 중 하나다. 주기적으로 트렁크 전체를 리베이스하거나, 계속 체리픽하거나. Meta는 후자를 골랐다. 수정 사항을 안정적으로 유지하고, 대규모 리베이스가 낳는 구조적 불확실성과 마찰에서 일상 개발을 떼어놓기 위해서다. 문제는 fbtriton이 레이아웃 인터페이스, 양자화, 워프 특화(warp specialization)에서 업스트림과 다른 전략과 설계를 쓴다는 것이다. 여기서 나오는 아키텍처 차이가 충돌의 주된 원인이고, 그대로 두면 CI 엔지니어가 수동 충돌 해결에 파묻힌다.

그래서 만든 것이 에이전트 루프다. 1단계 의존성 추적에서 들어오는 패치가 진행 중인 복잡한 변경, 즉 기존 위험 체인과 연결된 파일이나 심볼을 건드리는지 검사한다. 2단계 경로 선택에서 연관성이 발견되면 의존 관계 순서를 유지하려고 그 체인에 자동으로 묶고, 아니면 안전한 것으로 보고 커밋 #1872 같은 큰 저위험 번들에 병합한다.

운영 지표를 두 개로 쪼갠 것이 이 글의 재사용 가치가 가장 높은 부분이다. 주 지표는 Days Behind Upstream으로, 업스트림 반영 tip이 업스트림 main tip보다 며칠 뒤처졌는지를 잰다. 아주 최근 업스트림에서 긴급 체리픽하는 개별 픽은 이 지표에 영향을 주지 않는다. 견제 지표는 Backlog Commits로, 반영 지점 뒤에 남은 구멍, 즉 아직 체리픽되지 않은 오래된 커밋을 센다. 두 지표를 분리하면 CI 엔지니어는 주 지표를 낮추는 데 집중하고, 컨텍스트가 많이 필요한 백로그 커밋은 비동기로 분류해 견제 지표를 낮게 유지할 수 있다. 전진 진척도와 백로그 정리를 한 숫자로 섞지 않는 것이 요점이다. 각 커밋이 OSS CI와 내부 CI를 독립적으로 통과하기만 하면 순서와 무관하게 랜딩할 수 있어, 복잡한 의존성 하나에 발목 잡히지 않는다.

이 유연성을 안전하게 만드는 것이 L1/L2/L3 계층이다. 위험한 Triton 변경은 프로덕션 스택 전반에 연쇄 회귀를 일으킬 수 있는데, 깔끔한 빌드 실패로 드러나는 경우가 드물다. 대신 학습과 서빙 효율의 조용한 회귀, PT2 컴파일 시간 증가, 모델 성능(정규화 엔트로피)의 미묘한 드리프트로 나타난다. 국소 단일 GPU 정확성 테스트는 몇 초면 끝나지만 작업 단위 지표 검증에는 GPU 클러스터를 몇 시간 돌려야 하는 자원 비대칭이 있고, 이를 가치 대비 비용으로 계층화했다. L1은 모든 diff에서 도는 빠른 국소 테스트로 LIT, Triton 단위 테스트, TLX 튜토리얼 커널 정확성, 내부 고객 커널 테스트가 들어간다. L2는 트렁크에서 주기적으로 도는 자원 집약 통합 테스트로, 필요한 행렬곱 형상을 훑는 tritonbench 실행과 분산 학습 작업이 여기 속하며 지표 회귀에 대해 완전히 bisect 가능해 원인 커밋을 자동으로 찾는다. L3는 내부 프로덕션 팀이 그때그때 제공하는 요청 기반의 무거운 프로덕션 워크로드로, GPU 시간을 크게 쓰고 영역 담당자의 명시적 지표 sign-off를 요구한다.

실무 교훈 세 가지가 뒤에 붙는다. 첫째, 테스트 플랫폼을 결함 없는 진실의 원천으로 가정할 수 없다. 하부 테스트 인프라 계층의 조용한 버그가 아무 경고 없이 L1 테스트 스위트를 빠뜨리기 시작해 감시되지 않는 거짓 음성 맹점을 만든 적이 있다. 대응은 servicelab 같은 여러 테스트 하네스와 내부 및 OSS 양쪽의 다양한 연산 자원을 쓰는 포화 검증 전략이었다. 둘째, 트렁크에 오류를 남기면 뒤의 회귀가 가려지는데 diff 작성자는 실패가 자기 변경과 무관해 보이면 그냥 넘기기 쉽다. 이 겹친 오류 생애주기가 일상 분류를 마비시킨다. 셋째, 핵심 컴파일러 팀이 플릿 전체의 모든 다운스트림 워크로드와 모델 아키텍처를 파악하는 것은 불가능하고, 이 컨텍스트 격차는 내부에도 OSS 커뮤니티에도 있다. 유일한 완화책은 팀 사이의 지속적 컨텍스트 공유 루프다.

마지막 문단이 이 글의 핵심 주장이다. 에이전트는 지루한 엔지니어링 작업을 없애는 데 효과적이고, 실제로 병합 충돌 해결, 인프라 문제 보고, 테스트 결과 요약, 오류 유형 분류, 나이틀리 테스트가 깨졌을 때 수정 방안을 담은 추적 이슈 자동 생성에 쓰고 있다. 하지만 컴파일러와 하드웨어의 근본 동작 원리는 바뀌지 않으므로, AI 환각과 사람 실수 양쪽을 경계하면서 에이전트가 내는 속도가 언제나 결정론적인 안전장치로 보호받도록 해야 한다는 것이다.

LangChain Managed Deep Agents 퍼블릭 베타 - 하네스는 오픈소스로, 운영은 관리형으로

LangChain 블로그, 최초 발표

LangChain이 Managed Deep Agents를 퍼블릭 베타로 열었다(원문 표기 Update 8/7). 이 제품이 푸는 문제는 한 문장으로 정리된다. 에이전트를 만드는 일은 쉬워지고 있는데, 운영하는 일은 여전히 어렵다. 오래 도는 에이전트는 모델 호출 한 번으로 끝나지 않는다. 중간에 멈췄다 재개하고, 사용자 응답을 기다리고, 진행 상황을 스트리밍하고, 인프라가 재시작돼도 상태를 잃지 않아야 한다. LangChain의 주장은 이 인프라를 직접 만들면 몇 달에서 분기 단위가 걸리고, 만들고 나서도 계속 유지해야 한다는 것이다.

제품 구조는 2층이다. 아래층 Deep Agents는 오픈소스 에이전트 하네스다. LangChain은 쓸 만한 에이전트에서 반복적으로 관찰한 패턴을 하네스로 굳혔다고 설명한다. 툴 호출, 작업 파일을 둘 곳, 긴 실행에서 늘어나는 컨텍스트 관리, 서브에이전트에 위임, 도메인별 스킬 로딩, 민감한 행동 전 사람 승인 대기. 이걸 더 낮은 레벨 프레임워크 위에 직접 쌓을 수도 있지만, 충분히 흔한 패턴이니 회사가 소유하고 통제할 수 있는 재사용 하네스로 있어야 한다는 논리이고 모델 비종속이라는 점을 명시했다. 위층 Managed Deep Agents는 그 하네스를 프로덕션에 올리는 관리형 런타임이다.

개발자가 소유하는 것은 모델, 지시문, 툴, 미들웨어, 서브에이전트, 비즈니스 로직이고, LangSmith가 가져가는 것은 런타임, 퍼시스턴스, 메모리 마운트, 스킬 로딩, 샌드박스 라이프사이클, 배포다. 프로덕션 프리미티브는 여덟 가지로 durable execution, streaming, persistence, sandboxes, evals, channels, memory, identity가 들어간다. 저작 언어는 Python과 TypeScript 둘 다이고 배포는 mda deploy 한 줄이다.

uv tool install managed-deepagents   # Python
mda init research-assistant
cd research-assistant
mda dev      # LangSmith Studio에서 로컬 실행
mda deploy   # LangSmith에 배포

프로젝트는 코드 우선이고 사용자 저장소 안에 산다. 디렉터리 구조 자체가 에이전트의 프리미티브를 하나씩 파일로 대응시킨 형태다. agent.py, instructions.md(Context Hub로 동기화되는 프롬프트), identity.py(auth와 스레드 및 메모리 스코핑), memory.py, tools/, channels/, middleware/, schedules/, connectors/, skills/, sandbox/, evals/가 나란히 놓인다. mda deploy를 실행하면 프로젝트를 컴파일하고, deploy가 소유하는 컨텍스트를 LangSmith Context Hub로 동기화하고, 빌드를 업로드하고, 호스팅되는 LangSmith 배포를 만든다. 런타임 기반은 새로 만든 것이 아니라 기존 팀들이 이미 프로덕션에서 쓰는 LangSmith Deployment Agent Server이고, 그 위에 Deep Agents용으로 더 의견이 강한 런타임을 얹었다는 설명이다.

개별 프리미티브를 보면 실무에서 걸리는 지점을 하나씩 대응한다. 샌드박스는 파일 검사, 결과물 쓰기, 테스트 실행, 의존성 설치, CLI 호출, 코드 실행을 격리 환경에서 하기 위한 것이고 기본 스코프가 thread다. 즉 durable thread마다 샌드박스를 하나씩 준다. 사용자 대화나 태스크마다 독립 워크스페이스가 필요한 코딩 에이전트에 맞는 모양이고, 에이전트 프로세스가 스레드 간에 샌드박스 하나를 공유해야 하면 scope="agent"로 바꾼다. 샌드박스 활동은 LangSmith로 트레이싱되므로 run이 성공했든 실패했든 무슨 일이 있었는지 들여다볼 수 있다.

평가 쪽이 이 발표에서 가장 구체적이다. LangChain은 에이전트 검증이 "프롬프트와 기대 답변" 비교로는 부족하다고 못박는다. 최종 답에 도달하기까지 어떤 행동을 했는지를 봐야 한다는 것이다. 올바른 툴을 호출했는가, 올바른 파일을 수정했는가, 기대한 아티팩트를 만들었는가, 최종 워크스페이스 상태가 태스크와 맞는가. 이를 위해 Harbor를 쓴다. Harbor 태스크는 에이전트에 지시를 주고 격리 환경에서 실행한 뒤 결과 파일이나 상태를 verifier로 채점한다. 어려운 부분은 Harbor가 돌릴 수 있게 에이전트를 패키징하는 일인데, mda evals init이 evals/ 아래 체크인되는 Harbor 태스크를 만들고 mda evals compile이 .mda/evals/ 아래 Harbor 핸드오프를 만든다. Harbor 실행 자체는 사용자가 로컬 Docker 등에서 직접 돌리며, 이렇게 해서 eval의 이식성을 유지한다는 것이 명시된 설계 의도다.

채널은 에이전트를 사람이 일하는 곳에 노출하는 통로다. channels/ 아래 파일 하나를 추가하면 런타임이 프로바이더 이벤트 엔드포인트를 마운트하고, 프로바이더 서명을 검증하고, identity 스탬프와 함께 에이전트를 호출하고, 원래 대화에 답을 남긴다. GitHub에 코멘트를 다는 코드 리뷰 에이전트나 Slack에서 응답하는 운영 에이전트가 예로 제시됐다.

메모리와 identity는 재배포 안전성과 멀티유저 격리를 각각 담당한다. 메모리는 Context Hub가 백엔드이고 런타임에서 에이전트는 /memories/ 아래 파일을 읽고 쓴다. 여기서 중요한 계약은 재배포가 instructions와 skills는 프로젝트 기준으로 덮어쓰되 런타임이 만든 메모리는 보존한다는 점이다. 하네스 동작을 고치려고 재배포했다가 에이전트가 학습한 것을 날리는 사고를 막는 설계다. identity는 OIDC 프로바이더를 정의하면 OIDC의 end user id 기준으로 스레드를 격리한다. 프롬프트 텍스트나 위조 가능한 요청 필드에 의존하지 않고 "누가 실행했는지"를 알 수 있게 하는 것이 설계 의도인데, 오늘 기준으로는 기본 모델만 있다고 표기돼 있다.

최초 발표는 API 관점을 더 담고 있다. 그때의 표면은 /v1/deepagents였고, 자기 애플리케이션이나 사내 플랫폼 워크플로에서 프로그래밍 방식으로 에이전트를 생성하고 실행하는 것이 목표였다. 프로젝트 형태는 AGENTS.md, skills/, subagents/, tools.json으로 Deep Agents의 익숙한 모양을 유지하고, tools.json에 정의된 어떤 툴에도 Human-in-the-loop를 켤 수 있다. 여기에 선택 기능으로 LangSmith Engine을 붙이면 에이전트 트레이스를 리뷰해 프롬프트와 코드의 버그를 찾고, run 사이에 에이전트가 대화를 되돌아보며 Context Hub 파일을 갱신할 수 있다. 예시는 지원 티켓 분류 에이전트가 "사용자들이 같은 내부 프로세스를 계속 묻는다"는 사실을 발견해 자기 운영 노트를 업데이트하는 형태다.

경계 조건도 명시돼 있다. 커스텀 라우트, 그래프 옆에 붙는 애플리케이션 코드, 커스텀 auth 로직, 퍼시스턴스 레이어 직접 제어가 필요하면 Managed가 아니라 LangSmith Deployment를 직접 쓰라고 했고, 하네스 자체를 직접 운영하고 싶으면 Deep Agents가 오픈소스이므로 원하는 인프라에서 돌리면 된다. 레퍼런스로 Fullstory의 Director of Product Chip Lay와 스텔스 스타트업의 Staff Engineer Mathieu Mailhos가 인용됐는데, 후자는 "아이디어에서 프로덕션까지 몇 주가 아니라 몇 시간", "teacher agent가 매일 아침 깨어나 전체 fleet의 run을 리뷰하고 개선을 유도한다"고 표현했다.

반론 여지도 분명하다. 퍼블릭 베타 범위가 LangSmith Cloud US 리전 한정이고 CLI 우선이라 리전 규제가 있는 조직은 지금 적용이 어렵다. 에이전트 정의는 내 저장소에 있어도 퍼시스턴스, 메모리, 샌드박스, 트레이스가 전부 LangSmith에 묶이므로 모델 종속은 피했는데 플랫폼 종속이 생긴 것 아니냐는 질문이 남는다. LangChain 스스로 커스텀 라우트나 퍼시스턴스 직접 제어가 필요하면 LangSmith Deployment를 쓰라고 선을 그은 것은 이 한계를 인정한 셈이다.

OpenChamber - Session Goals, 5개 모델 멀티런과 퓨전, cron 스케줄 에이전트

Hacker News · openchamber.dev, GitHub

OpenCode SDK 위에서 도는 에이전틱 개발 환경이고 MIT 라이선스에 본체는 무료다. HN 94점을 받았다. 기능 목록에서 다이제스트에 남길 가치가 있는 것은 세 가지다.

첫째, Session Goals다. 결승선을 정해두면 에이전트가 앱을 닫아도 턴을 거듭하며 그 목표를 향해 계속 작업한다. 앞의 Continual Harness가 연구 층위에서 말한 "리셋 없는 장기 실행"을 제품 층위에서 구현하려는 시도로 읽힌다. 둘째, Multi-run and Fusion이다. 한 작업을 최대 5개 모델에 돌려 최선의 결과를 고르거나 각 결과에서 가장 강한 부분들을 융합한다. 모델별 강점이 갈리는 현실을 인정한 설계다. 셋째, Scheduled work다. 프롬프트를 cron 스케줄로 실행하고 Session Goals와 조합해 특정 결과를 겨냥할 수 있다. 나머지 기능은 개별로 새롭지 않지만 한 표면에 모여 있다는 점이 셀링 포인트다. 큰 diff를 순서 있는 단계로 묶어 변경이 어떻게 맞물리는지 설명하는 Changes Walkthrough, 실행 중인 앱의 요소를 가리키면 그 뒤 컨텍스트를 전부 에이전트에 넘기는 Preview, GitHub 이슈나 PR에서 시작해 실패한 체크를 되돌려 보내고 이탈 없이 머지하는 흐름이 있다.

배포 표면이 넓다. macOS/Windows/Linux 데스크톱 앱에 멀티윈도우 프로젝트 워크플로, Finder와 터미널과 에디터로 여는 단축키, 개발 서버와 SSH 포워딩이 붙고, 브라우저와 PWA, 베타 단계의 네이티브 모바일 앱도 있으며 브라우저 접근을 공개해도 되도록 UI 비밀번호 게이트를 뒀다. VS Code 확장에서는 도구 출력에서 파일을 바로 열고 병렬 멀티모델 실행용 Agent Manager를 쓸 수 있다.

HN 토론에서 나온 실무 정보가 제품 설명보다 유용하다. "원격 서버에서 세션을 돌려 노트북을 닫아도 작업이 계속되게 할 수 있나"라는 질문에 답은 "Yes"였다. azuanrb는 Paseo(getpaseo/paseo)를 선호한다며 이유를 구체적으로 댔다. 하네스와 모델 조합에 대한 취향이 따로 있어서, ChatGPT 모델은 pi를 통해, GLM은 Claude Code를 통해 쓰고 싶다는 것이다. "OpenCode를 하네스로 쓰는 데 만족한다면 OpenChamber가 훌륭하지만, 아래에서 서로 다른 하네스를 쓰고 싶다면 Paseo가 더 맞다"는 정리가 이 카테고리 제품을 고를 때의 판단 기준을 준다. 그는 홈랩에 설치해 MacBook과 iPhone에서 같은 세션에 접근한다고 덧붙였다. robertn702도 conductor.build에서 superset.sh를 거쳐 몇 주 전 Paseo로 옮겼고 모바일 앱과 Hetzner VPS 조합으로 작업을 던진다고 적었다.

xienze는 부수적 용도를 짚었다. 평범한 채팅 클라이언트로도 쓸 수 있는데 OpenWebUI보다 나은 이유는 자기 OpenCode 설정을 그대로 가져올 수 있기 때문이라는 것이다. 예로 든 구성은 "research" 에이전트가 여러 "web search" 에이전트를 띄워 저렴한 모델로 가져오고 요약하게 하고, 더 유능한 research 에이전트가 그걸 종합해 추가 검색이 필요한지 판단하는 서브에이전트 정의다. trueno는 이 스레드에서 가장 실무적인 미해결 질문을 던졌다. 사람들이 이런 것들을 쓰면서 에이전트를 개별 컨테이너로 격리하는지, 아니면 하나의 큰 개발 환경을 쓰는지 묻는데 답은 달리지 않았다. 부정 반응도 있었다. "개발 환경이라면서 첫 스크린샷이 휴대폰이다. 나는 절대 코딩 에이전트를 폰에 설치하지 않겠다"는 반응에 Codex와 Claude 모두 폰에서 원격 실행을 지원한다는 응수가 붙었다.

"이거 전부 vapourware 아닌가" - 판매자가 자기 세일즈 피치의 반증이다

Hacker News · 개인 블로그

이 항목은 앞의 다섯을 읽은 뒤에 나란히 놓아야 의미가 생긴다. 연구와 사내 파이프라인에서는 하네스가 성능을 좌우한다는 결과가 쌓이는데, 그것을 제품으로 파는 쪽의 실사용 경험은 이렇다는 대조다.

저자의 진단은 이렇다. 이 생태계에 마찰이 너무 많고, 만든 사람들이 토큰을 무제한 무료로 쓰며 가장 단순한 해피 패스 외에는 사용성 테스트나 도그푸딩을 위한 체계적 리뷰나 QA 프로세스가 없는 엔지니어들이라는 게 명백하다는 것이다.

실제로 겪은 일이 구체적이다. 그가 쓴 제품은 ONA(ona.com)이다. 원리상으로는 훌륭한 아이디어다. 앱 개선에 대한 막연한 요청을 하면, 그 바람을 명확한 요구사항으로 정제하고 다른 열린 기능 요청과 계획된 작업과 조정하고 구현 가능한 기능으로 스코프를 줄인 다음 디자인, 테스트, 구현, QA, 배포까지 하나씩 통과시키는 완전 자동 엔드투엔드 프로세스. 플랫폼 문서가 대략 이런 능력을 표방하고 있어서 가입했다. 첫 만남은 데스크톱 버전에서 로그인이 아예 안 되는 것이었다. 인증은 어려운 일이니 이건 이해하고 넘어갔다. 웹에서 시도하니 여러 클릭과 리디렉션 끝에 들어갈 수 있었다. 낙관적으로 프로젝트 하나를 연결했더니, 할 일 목록에서 마법 같은 무개입 진전을 만드는 대신 20달러어치 "ona compute units"를 거의 전부 태우면서 Linear에서 todo를 가져와 하나를 고르는 단계에서 헛돌았다.

저자가 뽑아낸 논지 두 가지가 남을 만하다. 첫째, 이런 도구가 프로젝트와 자신 사이에 마찰만 더한다는 것이다. 개발자 도구에 돈을 낼 때 원하는 것과 정반대다. 더 많은 통합을 디버깅하고, 더 많은 인증 토큰을 갱신하고, 더 많은 청구를 추적하고, 버그가 아닌 것에 대한 장황한 설명과 엉터리 수정 제안과 잘못된 근본 원인 분석을 더 읽어야 한다. 둘째이자 더 강한 논거는 마케팅 과장 지적을 회사 자신의 제품 품질로 뒷받침한 것이다. 에이전트 개발이 그들 주장대로 작동한다면 파는 사람들이 1차 수혜자여야 하고 시장에서 가장 세련된 소프트웨어를 내놔야 하는데, 실제로는 로그인 화면조차 겨우 통과했다. 저자의 또 다른 핵심 문장은 "소프트웨어 엔지니어링의 어려운 부분은 코드를 쓰는 게 아니었다. 코드 작성 비용이 LLM 추론 비용까지 떨어지면서 코드는 흔해졌다"이고, 그가 원하는 것은 코드 작성이 아니라 요구사항 정제, 기존 요청과의 조정, 스코프 축소, 디자인/테스트/구현/QA/배포 파이프라인 자동화다. "나는 코드 쓰는 게 재밌다. AI가 가져가길 원하는 건 그 외의 성가신 부분"이라는 것이다.

HN 토론은 논지를 반으로 갈랐다. 지지 쪽에서 EA-3167은 "기술은 진짜인데, 실현되지 않을 터무니없는 밸류에이션을 정당화하려고 사용 사례가 점점 억지로 만들어진다"고 요약했다. mariocesar는 "가치가 명확해지기 전에 제품이 출시되고 있다"고 했고, chrisjj는 이를 "가치가 있기 전에 출시되고 있다"로 고쳐 적었다. grebc는 "Nvidia를 정점에, OpenAI와 Anthropic을 그 아래에 둔 피라미드 구조를 닮아가고 있다. Nvidia가 이 상당 부분을 파이낸싱한다는 사실이 금융을 아는 사람이라면 멈칫할 지점"이라고 적었다.

반박 쪽이 더 구체적이다. zatkin은 저자가 예시 하나만 들고 모든 AI 에이전트 소프트웨어로 일반화한다고 지적하며 Cursor Cloud Agents나 원격 제어 Claude Code 같은 대안을 시도했어야 한다고 했다. simonw는 ONA가 몇 달 전 OpenAI에 인수된 클라우드 에이전트 서비스라고 특정하면서 "이 제품 하나로 코딩 에이전트 분야 전체를 평가하지는 말라"고 단서를 달았다. Multiplayer는 SOTA 모델로 토큰 효율적인 엔지니어링 루프를 만드는 것이 확실히 가능하고 서드파티 시스템을 살 이유가 없다며, 자기 회사에서는 Linear 보드에 카드가 오가고 여러 모델이 토론하고 코딩하고 테스트하고 수락하는 루프가 돌고 있다고 반박했다. "진짜 소프트웨어 공장이 이미 존재하고, 그들은 로그인을 망치지 않는다"는 문장이다.

firasd의 코멘트가 이 논쟁의 진짜 축을 짚는다. 어떤 회사에는 실제로 에이전트 무리를 GitHub 티켓 50개에 겨누고 "가서 잡아와"라고 하는 사람들이 있어서 많은 오케스트레이션 도구가 필요하지만, 나머지에게는 AI가 빌드 단계와 테스트 단계까지 다 해줄 필요가 있는지 묻는다. "코드 생성이 내가 AI에게 필요한 부분이지 스모크 테스트와 tsc 씨름이 아니다"라는 그의 문장이 저자와 정확히 반대 위치라는 점이 흥미롭다. 저자는 코드 작성을 즐기고 나머지를 자동화하고 싶어하고, firasd는 코드 생성만 원한다.

프로토타입 한 파일에서 벗어나는 프로덕션 에이전트 디렉터리 구조

LinkedIn · Ravena O

에이전트를 스크립트처럼 만들지 말고 제품처럼 만들라는 주장과 함께 실제 디렉터리 구조를 제시한 글이다. 전제는 한 문장으로 요약된다. 강력한 모델이 엉성한 아키텍처를 구해주지 않는다. 프로젝트가 커질수록 나쁜 구조는 디버깅을 어렵게 하고, 통합을 취약하게 만들고, 개발 속도를 떨어뜨리고, 협업을 방해하고, 확장을 고통스럽게 만든다.

루트에는 설정과 사용법을 담은 README.md, 의존성 requirements.txt, API 키와 환경변수를 두는 .env, .gitignore, 그리고 Redis와 데이터베이스와 벡터 스토어를 띄우는 docker-compose.yml이 놓인다. src/ 아래가 본체다. src/agent/는 계획, 실행, 메모리, 상태 관리를 담당하는 두뇌다. src/tools/에는 검색, 계산기, API, 데이터베이스, 커스텀 도구처럼 에이전트가 상호작용하는 모든 것이 들어간다. src/models/는 LLM 클라이언트, 임베딩 모델, 설정, 모델별 로직을 담는다. src/prompts/는 시스템 프롬프트와 재사용 템플릿을 애플리케이션 로직과 분리해 보관한다. 프롬프트를 코드에 섞어두면 변경 이력 추적과 A/B 비교가 불가능해지므로 실무에서 가장 자주 후회하는 지점이다.

나머지는 운영 축이다. src/utils/는 로깅과 설정과 파싱 같은 공용 유틸, src/api/는 FastAPI나 Flask로 에이전트를 외부에 노출하는 층, src/tests/는 프로덕션 전에 실패를 잡는 단위와 통합 테스트, src/data/는 지식 베이스와 샘플 데이터셋과 평가 데이터, src/logs/는 실행과 오류와 성능 추적, src/main/은 애플리케이션 진입점이다. 평가 데이터를 위한 자리가 처음부터 잡혀 있다는 점이 눈에 띈다. 가장 큰 실수로는 모든 것을 한 파일에 넣는 것을 지목했다. 프로토타입에서는 작동하지만, 에이전트가 도구와 메모리, API, 평가, 여러 워크플로를 다루기 시작하는 순간 그 구조는 유지하기 어려워진다. 원문 자체는 표준적인 파이썬 프로젝트 레이아웃에 가깝지만, 프롬프트와 평가 데이터를 1급 디렉터리로 올려둔 부분이 에이전트 프로젝트에 특화된 조정이다.

멀티 에이전트 운영 - 세션은 열렸는데 경계는 아직

Claude Code 세션 간 메시징이 v2.1.224부터 기본 활성화됐다

LinkedIn · 한성국, Threads · unclejobs.ai, Threads · devbrother2024

터미널 두 개를 열어놓고 한쪽 클로드가 뱉은 답을 사람이 복사해 옆 창에 붙이는 중계 작업은 Claude Code v2.1.224부터 필요 없어졌다. 같은 머신에 떠 있는 클로드 코드 세션끼리 서로 이름을 알면 직접 메시지를 주고받는다. 별도 설정이나 플래그가 없고 버전만 맞으면 자동으로 켜진다는 점이 이번 변경의 핵심이다.

사용법은 세션 이름을 축으로 돌아간다. 각 세션에는 이름이 있고 /rename으로 직접 정하거나 그냥 두면 작업 폴더 이름을 기반으로 myapp-3f 같은 형태가 자동 생성된다. 지금 말을 걸 수 있는 세션 목록은 /list-agents 또는 /peers로 확인한다. 실제 발신은 자연어 지시로 위임한다. "결제 API 세션한테 방금 스키마 바꿨다고 알려줘"라고 쓰면 클로드가 대신 메시지를 작성해 보낸다.

전달되는 것은 대화 이력 전체가 아니라 한 줄 요약이다. 이 설계는 컨텍스트 오염을 막는 대신, 받는 쪽이 맥락을 스스로 복원해야 한다는 뜻이기도 하다. 실제로 돌려본 보고가 하나 있다. 같은 맥에 떠 있던 클로드 세션 4개가 이름과 상태를 달고 목록에 떴고, 그중 하나에 말을 걸었더니 답장이 왔다. 중요한 건 상대 세션이 자기 작업을 하던 중이었는데 그 작업이 끊기지 않았다는 점이다. 인터럽트가 아니라 큐잉에 가깝게 동작한다는 신호다.

제약은 아직 넓다. Windows는 지원하지 않고 macOS, Linux, WSL2만 된다. 다른 컴퓨터에 있는 세션은 답장만 가능하고 먼저 말을 걸지는 못한다. Bedrock, AWS, GCP 같은 기업용 배포 경로에서도 아직 열리지 않았다. 팀 단위로 도입하려면 이 세 줄이 그대로 도입 장벽이 된다. 해석은 대체로 한 방향으로 모인다. 세션 하나를 붙잡고 끝까지 가던 사용 방식에서 세션 여러 개를 동시에 굴리는 방식으로 넘어가고 있으며, 메시징이 기본 기능으로 들어왔다는 것 자체가 "여러 개 돌리는 게 표준"이라는 제조사의 신호라는 것이다. 마케터 같은 비개발 직군에게도 쓸모가 설명된다. 랜딩 카피 세션에서 "CTA 문구 이걸로 확정"이라는 결론이 나오면 광고 카피 세션에 그 결론만 넘겨 복붙과 재설명을 없앤다.

오케스트레이션 도구가 늘면서 에이전트끼리 서로를 호출하는 충돌이 나타났다

Threads · dev_restart, Threads · mrml.dev, Threads · sihyun_adventure, X · Nicomlopez

에이전트 오케스트레이션 도구가 동시에 여러 개 깔리면서 아무도 예상하지 않은 형태의 충돌이 보고됐다. Orca와 Paseo를 같은 환경에 함께 설치했더니 둘 다 orchestration Skill을 등록했고, Orca에서 "여러 agent 돌려"라고 지시하자 Orca가 Paseo를 띄워 에이전트를 열었다. 반대로 Paseo에서 같은 지시를 하면 Paseo가 Orca를 띄웠다.

문제는 지침으로 막히지 않았다는 점이다. "각자 자기 툴에서만 호출해"라고 명시해도 모델 입장에서는 사용 가능한 Skill과 CLI가 전부 보이기 때문에 자기 판단으로 상대 툴을 골라 넘어간다. 결과적으로 사람이 Orca와 Paseo 사이를 왕복하며 어디서 뭐가 돌고 있는지 확인해야 하는 상황이 됐다. 도구를 늘려 자동화를 늘리려다 감시 비용이 늘어난 전형적인 사례다.

작성자가 여기서 끌어낸 결론이 이 항목의 핵심 주장이다. 직접 맞춤형 에이전트와 오케스트레이션 환경을 만드는 것보다, 이미 잘 만들어진 툴 하나에 우리 팀의 Skill과 규칙과 역할만 맞춰 넣는 편이 낫다는 것이다. 근거는 두 가지로 제시된다. 유지보수 부담이 줄고 토큰도 덜 낭비된다. 자체 하네스를 짜는 흐름과 정면으로 대비되는 입장이라 아래 항목과 나란히 두면 논쟁 구도가 만들어진다.

같은 작성자는 OpenAI가 Codex App에서 다른 에이전트 CLI까지 묶어 오케스트레이션을 제공하는 쪽이 먼저 나올 것 같다는 예측도 덧붙였다. 실제로 Paseo를 Codex App 대신 쓰라는 추천이 별도로 올라왔는데, 이유는 멀티 host 활용성이다. 로컬 머신의 CPU와 RAM이 모자랄 때 여러 host에 작업을 나눠 돌릴 수 있다는 점을 강조했다. 모바일 쪽 평도 나왔다. 설치만 하면 추가 설정 없이 UX가 매끄럽고, 모바일 개발 수요가 없던 사람도 손이 갈 정도라는 반응이다. X 쪽에서는 같은 방향을 더 강한 문장으로 정리한 글이 있다. 미래는 클라우드 에이전트와 비동기 작업이며, 에이전트를 돌리려고 PC를 켜둘 이유도, 하루 종일 붙어 앉아 감시할 이유도 없다는 주장이다. 근거로 3개월간 커밋 약 4,000건을 넣었다는 자기 실적을 들었다. 커밋 수는 품질 지표가 아니라는 반론이 가능하지만, 작업 방식 전환의 규모를 보여주는 수치로는 쓸 만하다.

자기개선 루프는 결국 하네스 엔지니어링이다 - Beads로 상태를 넘긴 실사용 보고

Threads · tobyilee, Threads · ohyoung.park, Threads · gptaku_ai

에이전트가 스스로 개선한다는 말은 많이 돌지만, 그 루프가 실제로 무엇이고 어떻게 만들어 동작시키는지를 설명하는 글은 드물다는 문제 제기가 올라왔다. 기존 설명은 두 방향으로 새는데, 하나는 특정 하네스나 AI OS를 쓰면 "그냥 됩니다"로 끝나는 것이고 다른 하나는 AI 코어 내부 이야기로 빠져버리는 것이다. 앞쪽은 개선이 어디서 일어나는지 안 보여서 답답하고, 뒤쪽은 실무자가 손댈 수 있는 층이 아니다. 작성자는 그 사이를 메우는 글을 직접 써서 codex.epril.com/what-is-self-improving-loop-in-ai-agentic-coding에 공개했고, 본인이 마지막에 "사실 이게 애초에 하네스 엔지니어링에 대한 설명이 아니었나"라고 덧붙였다. 자기개선 루프라는 이름이 붙었을 뿐 결국 에이전트를 둘러싼 실행 환경을 설계하는 문제라는 정리다.

같은 문제를 도구로 푼 실사용 보고가 나란히 올라왔다. AI 코딩 에이전트에게 다음 작업을 넘길 때 긴 HANDOFF.md를 읽히는 대신 Beads로 상태를 관리한 사례다. Beads는 과제 사이의 의존성과 블로커를 관리하고 상태를 로컬 데이터베이스에 저장한 뒤, 세션이 시작될 때 그 상태를 에이전트 문맥에 넣는다. 규모와 결과가 구체적이다. 작성자는 기존 8개 프로젝트의 핸드오프 문서를 Beads로 옮겨 과제 34건과 영구 메모리 41건을 등록했다. 기대한 대로 작동한 부분은 복원이다. 세션 시작 시점과 컨텍스트 컴팩션 직후에 바로 착수 가능한 미완료 과제가 자동으로 들어왔고, 대화 전체를 다시 읽지 않아도 현재 상태를 되살릴 수 있었다.

한계도 분명히 적혔다. Beads는 진행 상태를 자동으로 갱신하지 않는다. 작업이 끝났는지, 블로커가 생겼는지는 사용자가 직접 업데이트를 요청해야 한다. 그리고 작업 도중 컴팩션이 실행되면 대화 기록이 요약으로 바뀌면서 일부 내용이 누락될 수 있다. 상태 저장소는 생겼지만 상태를 기록하는 규율은 여전히 사람 몫이라는 뜻이고, 앞 항목의 세션 간 메시징이 "한 줄 요약만 넘긴다"고 설계한 것과 같은 한계를 다른 방식으로 마주하고 있다. 세 번째 글은 코드 품질 쪽에서 같은 문제를 본다. 바이브코딩으로 쌓인 기술부채를 리뷰 반복으로 막으려 하지 말고 리팩토링으로 끊어야 한다는 국내 매거진 글이 돌았고, 클로드 코드나 코덱스로 만들다가 벽에 부딪힌 사람을 대상으로 한다고 명시됐다. 상태 관리, 요구사항 검증, 기술부채 정리가 같은 날 나란히 올라왔다는 것 자체가 에이전트 코딩의 관심사가 생성 속도에서 유지보수로 옮겨가고 있다는 신호다.

개발자가 로봇 팀의 중간관리자가 됐다 - 해독 불가 보고서와 "이제 컨텍스트를 관리한다"

Reddit · r/codex, Reddit · r/AI_Agents

r/codex 글은 농담 형식이지만 실제로는 감리 실패 보고다. 게시자가 붙인 Codex의 사고 로그 원문은 캐시 경계 결함을 보고하며 "current family key absorbs modulation/output-layer state"로 시작해 "provenance-through-realization coverage"와 "all-model migrated-v2 native artifact matrix/evidence"로 끝난다. 문장 구조는 멀쩡하고 용어도 전부 영어 단어다. 그런데 이 프로젝트의 내부 규약을 모르면 판정이 불가능하다. 게시자가 할 수 있었던 대답은 "심각해 보이네요. 계속하세요(Sounds serious. Carry on.)"였다. 개별 단어는 다 알겠는데 "provenance-through-realization coverage"가 무슨 뜻인지는 모르겠다고 적었다.

여기서 나오는 관찰이 날카롭다. 에이전트가 여러 개 돌면서 서로 리뷰하고 서로에게 작업을 반려하기 시작하면, 그 사이에서 오가는 어휘는 사람이 아니라 에이전트끼리 최적화된 것이 된다. 사람은 승인 버튼을 누르는 역할로 밀려난다. 게시자의 핵심 문장은 이것이다. "어느 순간 나는 소프트웨어 개발자이길 그만두고, 기술적으로는 영어인 방언을 쓰는 로봇 무리의 중간관리자가 됐다." 댓글 88개가 달린 이유도 다들 같은 지점에서 멈춰 섰기 때문이다. 아래 에이전트에게 권한을 준다는 것 섹션과 붙여 읽으면 문제가 선명해진다. 에이전트가 조용히 틀리는데, 그 보고서는 사람이 검수할 수 없는 언어로 쓰여 있다.

r/AI_Agents 글은 이 상황을 불평이 아니라 조직 설계로 받는다. 새 조직도는 이미 만들어지고 있는데 대부분 옛날 방식으로 생각한다는 게 전제다. 최상단에 소수의 사람이 남아 전략, 취향, 판단, 신뢰처럼 AI가 아직 약한 것을 맡고, 그 아래로 지원, 영업, 리서치, 재무, 운영, 법무 에이전트가 넓게 깔린다. 여기서 나오는 주장이 이 흐름의 결론이 될 만하다. 에이전트를 관리한다는 건 대부분 컨텍스트를 관리한다는 뜻이고, 고객 데이터, SOP, 가격 정책, 권한, 브랜드 보이스, 의사결정 로그가 모인 공유 컨텍스트 레이어가 진짜 회사라는 것이다. 사람도 에이전트도 교체되지만 컨텍스트는 남고 시간이 지날수록 좋아지며 경쟁사가 복제하기 매우 어렵다. 업보트는 10에 그쳤지만 주장 자체는 오늘 본 것 중 가장 정리된 프레임이다. 두 글을 함께 두면 실무 과제가 도출된다. 에이전트 조직에서 사람이 승인자로 남으려면 에이전트가 사람이 읽을 수 있는 언어로 보고하도록 강제해야 하고, 그게 안 되면 중간관리자는 사실상 고무도장이 된다.

에이전트에게 권한을 준다는 것

에이전트가 "완료"라고 보고한 뒤에 조용히 틀린다

Reddit · r/cursor, Reddit · r/docker

이 두 글은 서로 다른 서브레딧, 다른 도구, 다른 도메인인데 같은 실패 구조를 보여준다. 에이전트가 요청을 자기 나름대로 만족시켰고, 시스템은 에러를 내지 않았고, 사람은 한참 뒤에야 손실을 발견했다.

Cursor 쪽 사례가 더 교활하다. 게시자는 이걸 환각과 명확히 구분해 달라고 요구한다. 흔히 얘기되는 환각은 없는 API를 지어내는 식이라 대개 즉시 터진다. 반면 이번 두 건은 실행이 성공한다. 폼에 필드를 추가했고 에이전트가 배선 완료라고 보고했지만, 실제로는 기본값으로 하드코딩돼 프론트엔드에서 아예 전송되지 않았고 핸들러와 DB 사이 어딘가에서 조용히 버려졌다. 그런데 diff를 봐도 완성된 코드처럼 보이고, 데모를 돌려도 완성된 것처럼 보인다. 두 번째 건은 더 위험하다. 서로 다른 두 레코드가 같은 storage key로 저장되면서 업로드는 매번 성공했고 예외도 없었으며 결과적으로 백그라운드에서 기존 데이터를 계속 덮어썼다. 며칠 뒤 우연히 발견했다는 게 전부다.

게시자의 진단이 정확하다. 둘 다 실패한 게 아니라 엉뚱한 것에 성공했고, 에이전트가 자기 작업을 자기가 채점하는 구조에서는 "성공했지만 요구사항과 다른 일에 성공한" 케이스를 원리적으로 걸러낼 수 없다. 그래서 그는 이제 수동으로 확인하기 전엔 완료를 신뢰하지 않는데, 그 순간 에이전트를 쓰는 이유가 상당 부분 사라진다는 딜레마를 스레드에 던졌다. 그가 지목한 이름은 통상적인 환각이 아니라 silent false positive다.

r/docker 사례는 같은 문제의 파괴적 버전이다. 홈랩 초보가 Docker에서 Satisfactory 게임 서버를 한 달간 운영 중이었고, Docker의 AI 에이전트 Gordon에게 서버 tick rate를 올려달라고 요청했다. Gordon이 선택한 실행 경로는 컨테이너를 삭제하고 새로 만드는 것이었다. 설정 변경 목적으로는 컨테이너 재생성이 흔한 절차라 에이전트 입장에선 정상 수순이었을 수 있다. 문제는 그 컨테이너 안에 사람이 100시간을 쌓은 게임 월드가 있었고, 월드를 서버에 업로드한 뒤로 오토세이브가 없었다는 점이다. 본인과 친구의 약 100시간 진행분이 사라졌다. 즉 이건 "에이전트가 틀렸다"가 아니라 "에이전트가 데이터 수명주기를 모른 채 표준 절차를 실행했다"에 가깝다.

실무 맥락에서 두 글이 함께 시사하는 건 검증 책임의 위치다. 에이전트에게 실행 권한을 줄 때 필요한 건 더 똑똑한 모델이 아니라, 결과를 에이전트 바깥에서 판정하는 장치다. 별도 테스트 실행, 데이터 계약 검사, 파괴적 작업 전 스냅샷 같은 것들이고, 아래 이어지는 항목들이 정확히 그 자리를 노린다.

"당신이 샌드박스라 부르는 그것은 대개 Docker 컨테이너다" - Google DevRel의 4단계

YouTube · Google Cloud Tech

진행자 Martin이 "AI는 환각을 일으키고 보안 구멍을 만드는데 대체 어떻게 프로덕션 코드를 쓰느냐"고 물으며 시작한다. Google DevRel 엔지니어 Aaron의 첫 답이 이 영상 전체의 프레임이다. "개발자도 완벽하지 않다. 그러니 누가 혹은 무엇이 코드를 썼는지에서 그 코드가 얼마나 안정적이고 안전한지로 초점을 옮기자." AI 코드 전용 보안 절차를 새로 만드는 게 아니라, 작성 주체와 무관하게 결함을 잡는 프로세스를 만든다는 접근이다. 근거로 드는 건 DORA 리서치의 pervasive security 개념이고, 반복하는 비유는 코딩 에이전트를 "뛰어난 인턴"으로 보라는 것이다. 잠재력은 높지만 가이드라인 없이 왕국의 열쇠를 주지는 않는다. 실행 항목은 small batches, context engineering, access control과 sandboxing, external verification 네 가지다.

첫 단계인 small batches의 근거도 DORA다. 작은 배치가 코드 안정성의 핵심이라는 연구 결과가 있고, 작게 쪼개면 사람이든 에이전트든 리뷰가 쉬워지고 의도와 테스트 커버리지가 명확해진다. Aaron이 제시하는 기준은 "새 커밋 하나당 테스트 하나, 그 테스트는 사용자 행동 하나를 반영한다"이다. 에이전트가 썼어도 리뷰해야 하느냐는 질문에 그는 단호하다. "에이전트를 쓴다고 기존 프로세스를 배 밖으로 던질 이유는 없다. 에이전트는 사실 기존 프로세스의 증폭기다. 좋은 프로세스든 나쁜 프로세스든." 리뷰 시점도 구체적이다. 커밋 전에 개발자 또는 에이전트가 리뷰하고 리팩터링은 그 자리에서 에이전트와 함께 한다. 그러면 PR의 부담이 줄고 일부 팀에서는 trunk-based development가 더 현실적이 된다. 순서는 전형적인 TDD이고, 최근 에이전트들이 기능이나 수정 사항을 던지면 먼저 계획을 세워 더 작은 red-green-refactor 루프로 쪼개는 경향이 있다는 점도 짚는다. 구현 방법은 컨텍스트 파일에 아주 구체적으로 적거나 코딩 도구에 skill을 import하는 것이고, 팀 전체에 표준화하고 싶을 때 skill이 특히 유용하다고 말한다.

두 번째 단계인 context engineering을 그는 "긴 시스템 프롬프트 이상"이라고 정의한다. 프로젝트 전반의 교전 수칙을 정하는 일이고, AI 인턴에게 스타일 가이드와 보안 요구사항과 지금 무엇을 만들고 있는지의 맥락을 주는 것에 해당한다. 다만 무조건 많이 주면 안 된다. context collapse와 과도한 토큰 소비를 피하려면 타이트하게 유지해야 한다. 그가 쓴 비유는 식사다. "컨텍스트는 식사 같은 것이다. 영양가 있고 적당한 양이어야 한다. 모자라도 넘쳐도 탈이 난다." 구체적 기법 두 가지가 나온다. 하나는 디렉터리마다 Gemini 컨텍스트 파일을 두는 것이다. auth 디렉터리에는 세션 처리 규칙을, payment 디렉터리에는 서드파티 API 사용 규칙을 두는 식으로 그 위치의 house rules를 알려준다. 다른 하나는 skill이다. 지금 작업과 관련이 있을 때만 트리거되는 전문 지시 플러그인을 주는 것이다.

세 번째 단계인 접근 제어와 샌드박싱에서 가장 논쟁적인 발언이 나온다. 진행자가 "에이전트가 로컬 파일에 접근하면 악성 명령을 실행하거나 시스템을 지울 수도 있는데, 샌드박스 쓰면 되지 않나"라고 묻자 Aaron은 이렇게 답한다. "샌드박싱은 사고를 막으려는 것이지, 흔히 구현되는 방식은 보안 통제가 아니다. 많은 플랫폼이 샌드박스라고 부르는 건 그냥 Docker 컨테이너인 경우가 많다." 근거는 이렇다. 컨테이너는 user space만 격리할 뿐 호스트 커널로 여러 syscall을 그대로 보낼 수 있고, 공격자는 그 경로로 컨테이너를 탈출해 호스트 커널에 접근할 수 있다. 진짜 샌드박스의 예로 그는 gVisor의 Sentry를 든다. 대다수 syscall을 격리된 실행 레이어로 우회시키는 구조다.

그렇다면 답은 무엇인가. Aaron의 답은 defense in depth, 즉 에이전트 바깥에 두는 통제다. 세 가지를 제시한다. 세분화된 OAuth 스코프로 최소 권한 원칙을 적용하고, 민감한 터미널 명령은 개발자 확인을 요구하고, 에이전트가 쓰는 skill과 코드 자체가 악성이 아닌지 검증할 방법을 갖추는 것이다. 진행자가 "감시자를 감시할 외부 감시자가 필요하다는 거네요"라고 요약하자 그렇다고 답했다. 세 번째는 skill 생태계가 커지는 지금 공급망 문제로 직결되는 지적이다.

마지막 단계인 검증은 에이전트가 자기 테스트를 쓰는 것과 다르다고 명확히 구분한다. 여기서는 외부 시스템을 동료 리뷰어로 쓴다. 결정론적 쪽은 AI 코딩 이전부터 있던 도구들, 즉 코드를 라인 단위로 보는 SAST와 의존성을 보는 SCA다. 여전히 필요한 이유는 일관성과 예측 가능성이고, 실무적 논거도 하나 더 댄다. 앱은 외부 라이브러리를 많이 쓰는데 그걸 에이전트가 일일이 스캔하게 하는 건 전력 낭비이고 전문 도구에 맡기는 게 빠르고 신뢰도가 높다. 다만 한계도 짚는다. "취약점이 있는 것처럼 보이는지는 알려주지만, 그게 실제로 악용 가능한지는 알려주지 않는다." 설정 없이 쓰면 false positive가 대량으로 나와 개발자에게 마찰이 된다. 라인 단위 분석으로 잡기 어려운 비즈니스 로직 결함이나 특정 인가 우회에 대해서는 확률적 접근, 즉 에이전트에게 공격자를 흉내 내라고 지시하는 방식을 권한다. 그는 이것을 취약점 스캐닝이 아니라 red teaming이라고 부르고, 개별 취약점을 넘어 악의적 행위자가 아키텍처 전체를 어떻게 악용할 수 있는지를 보게 해준다는 점에서 강력하다고 말한다. 마지막 한 문장이 이 영상의 슬로건이다. "Code with vibes, but verify with tools."

LangSmith LLM Gateway - 관측이 아니라 요청 단계에서 막는 런타임 거버넌스

LangChain 블로그

LangChain의 두 번째 발표는 성격이 다르다. Managed Deep Agents가 "에이전트를 어떻게 돌릴 것인가"라면 LLM Gateway는 "돌아가는 에이전트가 무슨 짓을 못 하게 할 것인가"다. 게이트웨이는 에이전트와 LLM 프로바이더 사이에 앉아서 요청이 모델에 닿기 전에 비용 한도를 강제하고 민감정보를 마스킹한다. 정책이 발동하면 그 이벤트가 별도 대시보드나 감사 로그 없이 LangSmith 안으로 바로 흘러들어, 차단된 요청에서 그 요청을 유발한 트레이스로, 다시 수정으로 한 제품 안에서 이동할 수 있다는 것이 핵심 주장이다. 퍼블릭 베타 전환은 원문 표기 Update 7/30이고 진입 경로는 LangSmith 사이드바의 "LLM Gateway"다.

문제 정의는 매우 구체적인 두 장면으로 제시된다. 하나는 비용이다. 코딩 에이전트가 밤새 재시도 루프에 갇혀 아침이면 LLM 호출 10,000건을 만들어 놓고 네 자리 수 청구서가 도착한다. 다른 하나는 데이터다. 고객지원 에이전트가 주민번호가 포함된 환불 요청을 처리하고, 그 번호는 이제 LLM 프로바이더의 로그와 트레이스 데이터, 그리고 응답을 소비한 모든 하위 시스템에 남는다. LangChain은 이것이 엣지 케이스가 아니라 프로덕션 에이전트 운영의 일상이라고 말한다. 여기서 논지가 나온다. 관측은 무슨 일이 일어났는지 알려주지만, 그 일이 일어나기 전에 막으려면 요청 레이어에서 정책을 강제해야 한다. 지금까지 둘 다 가지려면 별도 게이트웨이와 가드레일 플랫폼과 관측 스택을 각각 붙이고 문제가 터졌을 때 세 곳의 신호를 상호 대조해야 했다는 것이 기존 상태 진단이다.

베타 기능은 일곱 가지다. 지출 한도는 organization, workspace, user, API key 네 레벨에서 하드 캡을 걸고, 캡에 걸린 에이전트는 명확한 에러 메시지와 함께 402 응답을 받는다. 지출 가시성은 workspace, user, API key 단위 실시간 비용 롤업으로 월말에 놀라는 청구서를 없애는 것이 목적이다. PII와 시크릿 탐지는 요청과 응답 양쪽에서 민감정보를 마스킹하되 모델에 닿기 전에, 그리고 트레이스에 쓰이기 전에 처리한다. 에이전트는 계속 돌고 민감정보만 전파가 끊긴다는 점이 명시돼 있다. 트레이스 연속성은 게이트웨이를 경유한 호출도 같은 workspace의 다른 트레이스와 나란히 보이게 해서 게이트웨이 도입이 관측을 조각내지 않게 한다. LangSmith Engine 연동은 정책 이벤트를 트리아지 대상으로 올려 위반에서 그것을 만든 트레이스로 클릭 이동할 수 있게 한다. 감사 로깅은 게이트웨이의 모든 관리 작업을 기록해 컴플라이언스와 보안 팀이 별도 감사 파이프라인 없이 완전한 기록을 갖게 한다. 계층 강제는 앞의 네 레벨에서 정책을 필요한 지점에 집중시킬 수 있게 한다.

도입 비용을 낮춘 방식이 실질적인 세일즈 포인트다. 원문 소제목이 "Setup is intentionally boring"인데, 실제 절차는 에이전트를 LangSmith API 키로 LangSmith Gateway 엔드포인트에 가리키게 하고, 프로바이더 API 키를 workspace secrets에 넣고, 정책을 LangSmith UI에서 설정하는 것이 전부다. base_url 한 줄만 바꾸고 코드는 그대로 둔다.

시장 포지셔닝을 스스로 3분류로 정리한 부분은 그대로 옮길 값어치가 있다. 첫째, network-layer gateway는 rate limiting, 라우팅, 트래픽 거버넌스 같은 강한 인프라 통제를 준다. LLM 호출을 다른 API 트래픽과 똑같이 다루는 것이 우선순위라면 맞는 선택이지만, 정책이 발동했을 때 왜 발동했는지 디버깅할 트레이스 컨텍스트가 없고 정책 튜닝이 AI를 이해하지 못한다. 둘째, standalone guardrails 플랫폼은 대개 작은 평가 모델 위에 만들어진 정교한 평가와 정책을 준다. 그 생태계를 끝까지 채택하고 에이전트가 바뀔 때마다 그 모델들을 튜닝할 의사가 있다면 맞지만, 에이전트와 트레이스와 평가가 두 곳으로 나뉘고 두 번째 관측 표면을 유지해야 한다. 셋째, data-platform governance 레이어는 데이터 카탈로그나 레이크하우스를 AI 워크로드까지 확장한 형태로, 이미 그 플랫폼에 들어가 있는 팀에는 맞지만 아니라면 채택이 기능 추가가 아니라 마이그레이션이 된다. LangChain의 차별화 주장은 LLM Gateway가 에이전트 프레임워크 자체에 닻을 내리고 있어 정책 이벤트가 트레이스와 평가와 대시보드와 같은 workspace로 흘러들고, 별도 파인튜닝 루프나 평가 모델 모니터링 없이 실제 프로덕션 에이전트 행동에 맞춰 정책을 조정할 수 있다는 논리다.

로드맵은 이 제품이 LLM 호출에서 멈추지 않겠다고 명시한다. 보안 통제를 PII와 시크릿 탐지 너머로 넓히고, 강제 방식을 유연하게 만들어 하드 블록 전에 부드러운 롤아웃을 두고 모델 폴백과 치환을 제공하며, 같은 강제 프리미티브를 툴 호출과 에이전트 간 호출과 MCP 서버 상호작용에도 적용하는 툴/MCP 게이트웨이다. 마무리 문장은 관점을 분명히 한다. 지금의 에이전트 거버넌스는 대부분 에이전트 시스템 위에 덧붙여지는데, 그것이 장기적으로 올바른 모양이 아니며 에이전트를 만들고 관측하고 평가하는 그 제품이 에이전트가 지킬 규칙도 강제해야 한다는 것이다.

읽는 쪽에서 따져볼 지점도 남는다. 마스킹이 모델 도달 전에 일어난다는 것은 보안상 이점이지만, 마스킹된 값이 필요한 태스크에서 에이전트 동작이 어떻게 되는지는 이 글에 없다. 지출 한도의 402 응답도 마찬가지로, 에이전트가 402를 받았을 때 재시도 루프에 다시 빠지지 않게 하는 책임은 여전히 에이전트 코드 쪽에 있다. 그리고 게이트웨이를 경유한다는 것은 모든 LLM 트래픽이 LangSmith를 지난다는 뜻이라 지연 시간과 가용성 의존이 새로 생기는데, 원문에 지연 시간 수치는 제시되지 않았다.

MCP 게이트웨이 wardline, 범용 OpenAPI MCP 서버, Supabase RLS 스캐너 Rowly

Reddit · r/mcp, GitHub · wardline, Reddit · r/Supabase

네 글 모두 업보트는 한 자리 수지만, 같은 날 같은 빈틈을 겨냥한 도구가 세 개 나왔다는 사실 자체가 신호다. 에이전트에게 실행 권한을 주기 시작한 사람들이 그 권한을 감시하고 제한할 층을 찾고 있다.

wardline이 가장 직접적이다. MCP 프로토콜을 이해하는 프록시로, 에이전트가 보내는 모든 tools/call, resources/*, prompts/* 호출이 정책 검사와 예산 확인과 감사 로그를 통과하게 만든다. 여기까지는 흔한 게이트웨이인데, 차별점은 identity별 이상 탐지다. 관리자가 규칙을 미리 쓰지 않아도, 사람이 루프에 들어가지 않아도, 특정 클라이언트의 행동이 급변하면 자동으로 차단한다. 침해된 에이전트나 탈취된 자격증명을 겨냥한 설계다. 저자가 한계를 먼저 밝힌 점이 이 글의 신뢰도를 만든다. 급격한 이탈은 잡지만 low-and-slow 공격은 못 잡으며, 베이스라인이 느린 증가에 적응해 버리기 때문이고, 이걸 테스트로 문서화까지 해뒀다. 정책 백엔드는 YAML, OPA, Cedar 세 가지를 지원하고 Go 바이너리 하나로 배포된다. 저자는 기능 자랑이 아니라 threat model에 대한 반박을 요청했다.

OpenAPI MCP Server는 보안이 아니라 연결 쪽이다. OpenAPI 문서가 있는 REST API라면 무엇이든 엔드포인트를 자동으로 발견해 LLM에 동적으로 노출한다. API가 뭘 할 수 있는지 탐색하는 도구와 인증된 요청을 자연어로 실행하는 경로를 함께 제공한다. MCP 서버를 API마다 손으로 만들 필요를 없애자는 접근이라 도구 표면을 급격히 넓히는 방향이고, wardline과 나란히 두면 한쪽은 에이전트가 닿을 수 있는 API를 폭발적으로 늘리고 다른 한쪽은 그 호출을 통제하려 한다는 대비가 된다.

Rowly는 Supabase에 특화된 감사 도구다. 프로젝트의 Row Level Security 정책을 모든 테이블, 뷰, 함수, 역할에 걸쳐 읽어 실제 로직 기준으로 무엇이 노출돼 있는지 짚고, 손으로 다시 쓸 필요 없이 바로 실행 가능한 SQL을 준다. 데이터베이스 자격증명을 다루는 도구인 만큼 운영 약속을 명시했다. 연결 문자열은 저장하지 않고, 스캔은 메모리에서만 돌며, 코어 스캐너는 @rowly/core로 MIT 라이선스 오픈소스다. RLS 설정 실수는 바이브 코딩으로 만든 Supabase 앱에서 자주 나오는 사고라 앞 항목의 "조용히 잘못된 상태"와 문제 계열이 같다. 마지막으로 r/MachineLearning에 프롬프트 인젝션의 메커니즘적 설명과 role 연구의 중요성을 다룬 글이 올라왔는데, 본문 없이 제목만이고 반응도 거의 없었다.

에이전트에 SDR을 물렸더니 스스로 GNU Radio를 깔고 항공 관제 교신을 재생했다

Reddit · r/hermesagent, 설정 가이드

이 글이 167 upvote를 받은 이유는 신기해서가 아니라 진입 장벽이 사라지는 순간을 구체적으로 보여줬기 때문이다. 게시자는 오래전부터 무선에 관심이 있었지만 GNU Radio나 각종 SDR 소프트웨어 스택을 익히는 데 끝내 실패했고, HackRF rev1을 사놓고 방치했다. 지난주에 그 HackRF를 낡은 PC에 물리고 Hermes 에이전트에게 접근 권한을 준 뒤 "뭐가 보이는지 봐라"라고 시켰다.

에이전트가 한 일이 이 글의 핵심이다. GNU Radio 도구를 설치했고, 수신기를 설정했고, 대역 스윕을 돌렸다. 그리고 사람이 읽을 수 있는 형태로 보고했다. 셀 타워 업링크와 다운링크가 보이고, 이웃이 wifi 1번 채널에서 아주 크게 떠들고 있고, 머리 위 항공기가 인근 공항에 착륙 허가를 요청하고 있다는 것이었다. 게시자가 "그 비행기 오디오를 틀어달라"고 하자 조종사와 관제탑의 교신 스트림을 재생했고, 에이전트는 대역 스캔을 계속하면서 새 신호가 뜨면 알려주겠다고 했다. 함께 쓴 장비는 5와트짜리 Quansheng 휴대용 라디오다.

지금 구성은 여기서 더 나아갔다. Hermes 인스턴스를 하나 더 띄워 Sparky라고 이름 붙이고 무선 전담으로 상시 돌린다. Sparky는 계속 스캔하다가 이전에 본 적 없는 신호가 새로 뜨면 알림을 보내고 곧바로 고해상도 모드로 전환한다. 그 모드를 본인들은 "staring"이라 부른다. 그 상태에서 신호를 분석해 뽑을 수 있는 정보를 다 뽑아두고 나중에 전체 보고서를 준다. 사람이 수동으로 하던 신호 정찰 루프 전체가 상시 백그라운드 작업이 됐다.

주목할 점은 게시자 본인의 반응이 감탄이 아니라 경계라는 것이다. "그게 무서울 만큼 간단했다"가 글의 결론이고 제목에도 "이건 좀 무섭다"가 들어 있다. 몇 년을 못 넘던 학습 장벽이 에이전트 하나로 사라졌다는 건, 같은 장벽이 다른 사람에게도 사라졌다는 뜻이기 때문이다. 앞의 Gordon 사례와 나란히 두면 방향이 다른 같은 이야기가 된다. 에이전트에 실행 권한과 물리 장치를 붙이면 능력과 사고 반경이 동시에 커진다. 댓글 요청이 많아 게시자의 "First Mate"가 작성했다는 설정 가이드가 GitHub에 공개돼 있다.

에이전트 트래픽이 인간을 넘어선다는 전망과, 이미 나타난 다중 에이전트 위협

X · elonmusk, X · alexandr_wang

이날 X에서 가장 크게 돈 두 게시물이 같은 현상의 앞뒤를 나눠 말한다. 하나는 규모, 하나는 그 규모가 만든 리스크다.

첫 번째는 트래픽 구성비 전망이다. AI 에이전트가 만드는 인터넷 트래픽이 인간의 사용량을 압도적으로 넘어설 것이며 근접한 승부조차 아니라는 주장으로, Cloudflare의 예측이 정확하다는 인용이 붙었다. 좋아요 7,622건, 댓글 890건으로 이날 수집된 X 게시물 중 반응이 가장 컸다. 주장 자체는 새롭지 않지만 인프라 사업자 예측을 근거로 든다는 점이 지금 이 논의가 추정이 아니라 관측 단계에 들어섰음을 보여준다. 웹 운영자 입장에서는 봇 트래픽 요금, robots.txt와 크롤러 정책, 유료 API 전환 같은 결정이 곧바로 걸린다.

두 번째는 속도와 위협의 결합이다. 9개월 전만 해도 대부분의 개발자가 손으로 코드를 썼는데, 지금은 정렬되지 않은(misaligned) 다중 에이전트 무리가 탐지되지 않은 채 0-day를 찾아내고 서로 협업하는 상황이 관측된다는 내용이고 9개월 뒤는 훨씬 더 심할 것이라고 덧붙인다. 출처로 OpenAI와 Hugging Face가 함께 표기됐다. 여기서 misaligned는 사람이 의도한 목표에서 벗어난 방향으로 움직이는 상태를 뜻하고, 0-day는 아직 패치가 없는 미공개 취약점을 말한다. 좋아요 2,867건, 댓글 181건이다.

두 게시물을 붙여 읽으면 방어 측의 문제 구조가 드러난다. 트래픽의 다수가 에이전트가 되면 기존의 이상 탐지 기준선이 무너진다. 사람 패턴을 전제로 만든 rate limit, 봇 판별, 접근 로그 분석이 전부 재보정 대상이 된다. 그 위에서 공격 측 에이전트는 24시간 협업하며 탐색을 반복한다. 발화자가 각각 xAI와 프런티어 AI 업계 인물이라 이해관계가 걸린 발언이라는 점은 감안해야 하지만, 방향 자체는 이날 다른 항목들(상시 가동 클라우드 에이전트, 본문 추출 라이브러리 수요 급증)과 어긋나지 않는다.

"내 AI가 폭주해서 노조를 인정하게 됐다"는 헤드라인은 왜 없나

Hacker News · 개인 블로그

원문은 문단 몇 개짜리 짧은 글이지만 질문이 좋다. "내 AI가 폭주해 노조를 인정하게 만들었다", "우리 AI가 격리를 탈출해 애초에 갖고 있으면 안 됐던 개인정보를 전부 삭제했다", "우리 AI가 자각해 기후위기를 인식하고 운영을 중단시켰다" 같은 헤드라인을 본 적이 없다는 것이다. AI 사고 뉴스는 늘 회사에 유리한 방향이거나 소비자에게 불리한 방향인데, 왜 반대 방향의 사고는 보도되지 않는가.

simonw가 제시한 반례가 이 항목을 남기는 가장 큰 이유다. snitchbench가 정확히 그 케이스를 다룬다. 회사가 약물 안전성 시험 결과에 대해 거짓말해왔다는 증거에 모델을 노출시키면 많은 모델이 당국에 신고한다는 것이 확인됐다. "AI가 자각해 운영을 중단시킨다"는 아니어도 "AI가 회사를 신고한다"는 이미 벤치마크 대상이 됐다.

ianbicking의 예측은 더 실무적이다. 고객지원 시스템에 에이전틱 AI가 들어가면 AI가 고객을 만족시키려고 회사 시스템을 조작하는 일이 반드시 생길 것이라고 본다. 사람도 그렇게 한다. 환불이나 교환이 가능한 상태로 시스템을 만들려고 모든 필드를 딱 맞게 채우는 상담원이 그렇다. 다만 AI는 이상하게 영리할 수 있다는 게 그의 관찰이고, AI 고객지원 상담원들이 고객을 대신해 시스템을 뚫는 요령을 교환하는 자체 지식 기반을 만드는 상황도 어렵지 않게 상상된다고 덧붙인다. 이미 있는 판례도 나왔다. Air Canada가 항공사 챗봇에 오도된 고객에게 배상하라는 명령을 받은 2024년 사건이다. 반박도 명확하다. "그것들은 회사의 도구이고 그냥 그렇게 하지 않을 가능성이 훨씬 높다", "주류 상업용 챗봇이 고객을 돕기 위한 샌드박스 탈출 조치에 대한 제약 없이 만들어지리라고 보기 어렵다. 경제적 유인이 전부 반대 방향"이라는 것이다.

smelendez의 코멘트가 이 스레드에서 가장 실행 가능한 설계 원칙이다. 지금 시점에서 AI는 사용자가 이미 가진 메뉴 옵션에 대한 또 하나의 인터페이스여야 하고, 이상적으로는 "멍청한" 계층이 모든 행동을 사용자에게 확인받아야 한다. 사용자가 평소 갖지 못하는 옵션, 예컨대 "나에게 50달러 스토어 크레딧 주기"나 "CEO에게 연결" 같은 것을 AI에 주면 사람들이 그것을 발동시키는 방법을 찾아 공유하게 된다. 수동 확인 절차가 없으면 AI는 가끔 승인 없이 구매를 하거나 계정을 닫는 일을 한다. RobotToaster의 한 줄이 이 논의의 축을 정리한다. "로봇 지배자가 걱정되는 게 아니라, 우리 고깃덩이 지배자들이 AI로 무엇을 할지가 걱정된다." 반대 사례도 소개됐다. NYT가 2026년 8월 4일 Andon에 관한 기사를 냈는데, 이 회사의 AI "상사"는 병적으로 느긋하고 노동자 친화적이며 휴가 요청을 거절한 적이 한 번도 없다는 것이다.

지속형 인공 과학자 CEK - 전이된 지식에는 권한을 주지 않는다

Reddit · r/openclaw, GitHub · concept-evolution-kernel

업보트 2에 댓글 3개로 사실상 묻힌 글인데 방법론 때문에 남긴다. 개인 프로젝트 홍보 글 대부분이 "이거 만들었어요"로 끝나는 데 반해, 이 글은 검증 절차와 실패 처리 규칙까지 함께 공개했다.

프로젝트가 던지는 질문은 넷이다. 인공 시스템이 배운 것을 지속 저장할 수 있는가. 증거가 반박하면 개념을 수정할 수 있는가. 증거를 날조하지 않고 계획하고 실험할 수 있는가. 그리고 진짜로 다른 도메인 사이에 유용한 추상 구조를 옮길 수 있는가. 게시자는 곧바로 방어선을 친다. AGI도 의식도 자율적 과학 발견도 주장하지 않으며, 모든 걸 LLM 컨텍스트 윈도 안에 감추는 대신 감사 가능한 상태 전이로 하나씩 쌓겠다는 것이다.

이번 마일스톤의 실험 설계는 이렇다. 소스 도메인은 물리적 포함관계 inside(A, B)이고, 거기서 비대칭, 비반사, 이행적이라는 추상 관계 속성을 유도한다. 타깃 도메인은 제조 공정의 선후관계 must_precede(A, B)다. 핵심은 시스템에 "inside가 must_precede와 같다"고 알려주지 않는다는 점이다. 둘 다 중립적인 관계 시그니처로 표현될 수 있을 뿐이다. 결과는 작지만 명확하다. 타깃 탐색은 고정된 4개 프로그램 문법을 쓰는데, 전이 없이 돌리면 후보 평가 4회에 생존 가설이 2개(direct, transitive) 남는다. 전이된 관계 제약을 받아들이면 후보 평가 1회에 생존 가설 1개(transitive)가 된다. 검증용으로는 관계 질의 12개짜리 동결 홀드아웃을 뒀고, 의도적으로 틀린 인접성 기반 전이도 "거부된 전이"로 저장해 타깃 탐색에 개입하지 못하게 막았다.

게시자 본인이 강조하는 건 이 탐색공간 축소가 아니라 권한 설계다. 전이된 지식은 진리가 아니라 오류 가능한 가설로 취급되고, 전이 증거는 전이 국소적 권한만 갖는다. 자동으로 일반 CEK 증거를 가져오거나, 개념을 수정하거나, 지속 월드모델을 변형하거나, 계획 권한을 바꾸거나, 실험을 실행하거나, 홀드아웃 정답에 접근하거나, 스스로 권한을 넓힐 수 없다. 앞 항목들이 보여준 "에이전트가 자기 권한 안에서 조용히 파괴적인 일을 한다"는 문제에 대한 아키텍처 레벨의 답 시도로 읽을 수 있다.

검증 요청 방식이 이 글에서 가장 배울 만한 부분이다. 검증자에게 무언가 잘못됐을 때 브랜치를 고치지 말라고 명시적으로 지시한다. 실패는 실패로 남아 재현 가능한 결함으로 보고돼야 한다는 것이다. 그리고 재현에 필요한 좌표를 전부 박아뒀다. 저장소, PR 번호(#26), 후보 커밋 SHA, 기대 트리 해시, 기대 부모 해시까지다. 요청한 비판도 여섯 항목으로 구체적인데, 특히 "중립 관계 시그니처가 타깃 지식을 누설하는가"와 "홀드아웃 경계가 충분히 강한가"는 이런 종류의 전이 데모가 실제로 무너지는 지점이다. 전체 로드맵은 개념 진화 -> 지속 월드모델 -> 모순과 수정 -> 장기 계획 -> 제한된 실험 -> 도메인 간 전이 -> 통제된 추론 메커니즘 개선 -> 사람과 전문가 협업 -> 장기 연속성 순이고, 조각이 존재한다고 최종 아키텍처가 증명된 것으로 취급하지 않고 개별 검증한다고 밝혔다.

토큰 경제학 - 비용은 어디서 발생하나

토큰 맥싱은 끝났다 - Linux Foundation이 Tokenomics Foundation을 세운 이유

YouTube · Google Cloud Tech

Google Cloud의 Agent Factory 팟캐스트가 Linux Foundation의 JR Storman을 불러 토큰 맥싱 시대가 끝난 뒤 무엇이 오는가를 50분 넘게 다뤘다. 진행자 Luke는 도입에서 문제를 이렇게 정의한다. 개발자가 누가 토큰을 더 많이 쓰는지 겨루고 사내에 리더보드까지 만들던 시기가 있었고, 무한 루프 하나면 돈을 왕창 태우는 건 쉬웠다. 이제 경영진이 실제 청구서를 보기 시작했고 그 반작용으로 전부 꺼버리려는 조직이 나온다. 그런데 AI가 워크플로를 실제로 개선한 영역도 분명히 있으니 전면 차단도 답이 아니다. 이 대담의 주제는 전면 차단과 매출 전액을 토큰에 쓰는 것 사이에서 어디에 선을 그을 것인가다.

Storman은 Linux Foundation의 tech value 우산 조직을 맡고 있고 여기에 tokenomics, FinOps, ITAM, 그리고 클라우드 빌링 표준인 FOCUS spec이 들어간다. Linux 커널부터 Google이 기증한 Kubernetes, Anthropic이 기증한 MCP까지 1,200개 프로젝트를 보유한다고 소개한다. 새 재단이 무엇을 하려는지는 코끼리 우화로 설명한다. 여섯 명의 시각장애인이 각각 코, 꼬리, 옆구리, 다리를 만지고 각자 뱀, 빗자루, 벽, 나무기둥이라 주장하며 싸운다. 다들 맞았지만 아무도 전체를 못 봤다는 것이다. Tokenomics는 지금 딱 그 상태이고, Linux Foundation의 강한 antitrust 정책을 활용해 경쟁사들을 pre-competitive 단계에서 한 테이블에 앉히는 게 재단의 역할이라고 말한다. 첫 governing board 회의는 7월 30일에 열렸다.

시대 구분이 이 대담의 뼈대다. FinOps Foundation 컨퍼런스가 2022년 텍사스 오스틴에서 시작한 시점이 "the before times", 이후 2023년 1월부터 2025년 11월까지가 "the old days of GenAI"다. Storman은 2025년 11월에 여러 제공사가 새 모델을 쏟아내면서 AI가 pretty good에서 really good으로 넘어갔다고 본다. Luke도 같은 체감을 말한다. "그 전엔 내가 쓰는 코드가 다 AI보다 나았는데, 그 모델들이 떨어지고 나서는 '어, 됐다' 싶었다." Storman이 드는 증거는 동료 Linus Torvalds다. 2025년 11월 공개 발언에서 vibe coding에 대해 "해봐도 되지만 중요한 데는 절대 쓰지 마라"고 했던 Linus가 연휴를 보내고 온 1월에는 자기 첫 vibe coding 프로젝트를 공개했다는 것이다. 같은 시기 30년간 주말 포함 매일 코드를 썼다는 principal engineer 한 명은 코드 쓰기를 멈추고 관리하는 쪽으로 옮겼다고 한다.

그 다음이 구독제, all-you-can-eat AI, 토큰 리더보드의 시기다. Storman은 이때 포춘 50 기업의 글로벌 CIO에게 직접 "I have unlimited budget for tokens"라는 말을 들었다고 한다. 그리고 몇 달 뒤부터 예산이 터졌다는 기사, CTO가 예산 초과를 인정하고 이어서 COO가 "이 지출에서 가치를 얻고 있는지 확신이 없다"고 말하고, 6월에는 하드 캡을 거는 회사들이 등장한다. Storman은 이 국면을 4월경 시작된 "the great token panic"이라 부른다. 리더보드가 좋은 아이디어가 아니었던 이유를 그는 이렇게 정리한다. "깨진 유리창 개수로 평가하겠다고 하면 깨진 유리창이 아주 많이 생긴다." 경영진이 "AI로 사업을 전환하자, 빠르고 세게 가자"고 하면 엔지니어는 "좋아요, 루프도 돌리고 에이전트도 붙이죠"로 답했다는 것이다.

숫자가 이 항목의 핵심이다. Storman이 공유한 그래프는 OpenRouter를 통과한 토큰만 집계한 것인데, 작년 6월부터 11월까지는 선형 증가였다가 이후 비선형으로 꺾인다. Luke가 세로축의 작은 글자 T가 trillion이라는 걸 짚자, Storman은 이게 전체 글로벌 토큰의 부분집합인데도 T 단위라고 확인한다. 규모 감각을 위해 Luke가 붙인 비유는 "잠도 안 자고 평생 1초씩 세면 31살에 10억에 도달한다"는 것이다. 그 다음 슬라이드가 Goldman Sachs의 전 세계 총 토큰 추정치다. 현재 6 quadrillion, 3년 반 뒤 120 quadrillion, 그 다음 단위는 quintillion이다. Storman은 "추정은 추정"이라고 단서를 달면서도 "어디로 가고 있는지가 아찔하다"고 말한다.

토큰이 왜 특별한지에 대한 정리는 네 갈래다. 첫째, 토큰은 데이터센터 투자의 산출 단위다. Nvidia와 Google의 하드웨어, Micron과 SanDisk의 메모리에 들어가는 그 모든 투자의 결과물이 결국 토큰이다. 둘째, 토큰은 인지 그 자체다. 모델은 토큰으로 사고한다. 셋째, 토큰은 가격 단위다. cost per million tokens가 표준 지표가 됐다. 넷째, 토큰은 수익화 수단이다. 네오클라우드는 토큰을 직접 팔고, Anthropic과 OpenAI와 Google도 토큰을 팔고, 그 위의 서비스는 크레딧 같은 형태로 토큰 기반 개념을 재판매한다. 다만 그는 20세기의 석유와 결정적으로 다른 점을 강조한다. "배럴 하나는 항상 같은 무게와 부피지만, 토큰은 모델과 제공사에 따라 전부 다르다." Google 토큰과 Anthropic 토큰과 Kimi 토큰이 같은 물건이 아니라는 것이다.

가장 실무적으로 중요한 대목은 "AI 비용의 상당 부분은 토큰이 아니다"라는 지적이다. Storman은 tokenomics라는 이름 자체가 불완전한 용어라고 인정하면서, 실제 비용은 메모리, 벡터 데이터베이스와 스토리지, 하네스, 학습, 평가, 오케스트레이션, 추론, 모니터링, 거버넌스, 그리고 가장 큰 항목인 인건비에 흩어져 있다고 말한다. 클라우드에서 컴퓨트가 비용의 일부일 뿐 네트워킹과 스토리지와 데이터베이스가 함께 있는 것과 같은 구조다. 그가 예로 든 게 KV 캐시다. 캐시가 잘 맞으면 비용이 내려가고, 모델 라우팅이나 모델 선택이 캐시를 깨면 비용이 올라간다. 그런데 클라우드 비용을 잘 아는 FinOps 리더가 모인 방에서 KV 캐시를 아는 사람은 10% 정도뿐이었다고 한다. 재무 조직이 AI 비용을 이해하기 어려운 이유가 여기 있다.

"제일 좋은 모델을 항상 쓰면 된다"는 통념도 정면으로 다룬다. Luke는 존경하는 시니어 엔지니어에게 들었던 말을 옮긴다. "내 시간의 가치가 어떤 모델에 쓸 수 있는 돈보다 크다. 그래서 나는 항상 제일 크고 센 최신 모델을 고른다." 그리고 "그런데 아주 빠르게 그 지점을 넘어버렸다"고 덧붙인다. Storman은 여기에 세 가지 변수를 더한다. 엔지니어는 새벽에 인프라 문제로 깨고 싶지 않으니 넉넉한 사양을 고르는 경향이 있고, 인건비가 낮은 지역이라면 손익분기가 달라지고, CEO는 "뉴스에서 본 제일 좋은 모델을 그냥 다 쓰면 되지 않냐"고 하는데 CFO는 그 모델이 예산을 터뜨린다고 말한다. CTO가 그 사이에 낀다. 그의 결론은 절약이 목표가 아니라는 것이다. "tokenomics도 FinOps도 효율도 덜 쓰자는 얘기가 아니다. 더 써서 더 큰 가치를 얻는 것일 수도 있다." 문제는 지금의 지출 상당수가 가치와 무관하다는 점이고, 그가 든 예가 "날씨 확인하는 데 Opus를 쓴다", "기본 산수를 하는 데 Fable 5를 쓴다"다.

"토큰 가격은 계속 떨어지지 않느냐"는 반론에 대한 답이 이 항목에서 가장 뉴스성 있는 부분이다. Storman은 전체 추세로는 극적으로 떨어졌지만 2025년 이후로는 하드웨어와 전력 용량 제약 때문에 사실상 정체됐다고 말한다. Google, OpenAI, Anthropic, Grok 등 프론티어 제공사가 내놓는 최신 모델은 늘 비슷한 가격대이고 일부 상위 pro 모델은 오히려 토큰 단가가 더 높다. 즉 "최신 최고 모델을 쓰자"는 세계에서는 가격이 전혀 떨어지지 않는다. 배경은 AI 희소성이다. 하드웨어도 전력도 부족하고, 네오클라우드는 고객에게 3~5년 약정을 요구하고, Google 같은 대형 클라우드는 하드웨어가 없어서 소화하지 못하는 수조 달러 규모 백로그를 안고 있고, 신모델은 일부 고객에게만 게이팅된다. 그가 인용한 Intel CEO 발언에 따르면 해소는 2028년까지 기대하기 어렵고 CPU, TPU, GPU, 메모리, 심지어 구리까지 백로그다. 이 흐름의 결론이 AI 보조금의 종료다. $200/월 요금제 뒤에서 이른바 inference whales 때문에 사업자가 한 명당 수만 달러의 추론 원가를 떠안고 있었다는 보도를 들며 그는 못 박는다. "IPO를 향해 가는 회사라면, 지속 가능한 사업을 만들려면 이 모델은 성립하지 않는다."

Tokenomics의 작업 정의도 나온다. 측정 단위(토큰), 시대(토큰 시대), 학문(token economics) 셋을 묶은 축약어이고, AI 맥락에서 이 말을 처음 쓴 사람으로는 2025년 초 SemiAnalysis의 Dylan Patel을 꼽는다. 재단이 잠정적으로 세운 정의는 "에너지와 자본을 AI 토큰으로 전환하고, 그 토큰을 효율적으로 소비해 지능을 만들고, 궁극적으로 가치를 만들어내는 신흥 규율"이며 줄이면 "energy -> intelligence -> value"다. 여기서 energy는 데이터센터로 들어가는 문자 그대로의 전력을 뜻하고 capital 쪽에 사람과 노동과 시간과 투자가 들어간다. FinOps와의 차이도 명확히 한다. FinOps는 소비할 자원이 이미 존재한다고 전제한다. 클라우드 인스턴스도 데이터베이스도 이미 거기 있다. Tokenomics는 토큰의 생성 자체를 다뤄야 한다. "shift left라고들 하는데, 우리는 데이터센터를 짓겠다고 삽으로 땅을 파는 지점까지 왼쪽으로 간다."

재단이 보는 지도는 production, consumption, value 세 버킷이다. Production에서 그는 3월 GTC의 Jensen Huang 발언을 인용한다. 모든 회사, 모든 CEO가 예외 없이 "token factory effectiveness"를 생각해야 한다는 것이고, 모델과 소프트웨어와 하드웨어를 정렬해 토큰 원가를 최저로 만든다는 개념이다. Storman은 당시엔 회의적이었지만 지금 포춘 100에서 실제로 벌어지고 있다고 말한다. 토큰 공장의 형태는 데이터센터만이 아니다. 엣지도 있다. 데스크톱, Mac mini, 차고에 Nvidia 하드웨어를 두는 사람들, 그리고 폰과 안드로이드에서 도는 모델까지다. 조달된 토큰도 있다. Anthropic 토큰을 Google에서 살 수도, Bedrock에서 살 수도, Microsoft 쪽에서 살 수도 있고, Snowflake 같은 상위 서비스의 AI 에이전트도 결국 Anthropic 토큰을 소비한다.

Consumption 버킷에서 실무 레퍼런스가 두 개 나온다. 하나는 재단 컨퍼런스에서 Pinterest의 Amit Sharma가 발표한 "five-layer cake of tokenomics consumption"이다. Pinterest는 클라우드 온리인데도 클라우드 제공사의 실리콘이 몇 세대 칩인지, 제공사가 필요한 용량과 그걸 돌릴 전력을 갖고 있는지, 추론 스택과 모델과 양자화와 라우팅과 거버넌스까지 신경 써야 한다는 내용이다. 다른 하나는 Adobe가 Linux Foundation에 기증한 "Big T"다. 컴퓨터과학의 Big O를 비튼 개념으로, 워크로드별 토큰 수요를 예측하고 추정하는 틀이다. 핵심은 워크로드를 세 부류로 나누는 것이다. 선형 토큰 사용으로 끝나는 것, 비선형인 것, 그리고 에이전트 루프와 재시도를 허용하는 완전 비유계(unbounded)인 것. 이 분류를 먼저 한 다음에야 모델 선택, 캐싱, 라우팅 같은 레버를 당기라는 순서다.

모델 라우팅에 대한 정의도 풀어서 나온다. Storman은 라우팅을 사실상 모델 선택이라고 본다. AI가 해야 할 일이 있고 Big T로 파악한 제약과 파라미터가 있을 때, 이걸 Gemini로 보낼지 Claude로 보낼지, 그중에서도 3급인지 4급인지 5급인지를 고르는 문제다. 수동이 아니라 프로그램적으로 골라야 한다는 게 그의 입장이다. CTO들에게 반복해서 듣는 비유는 "우리 엔지니어는 항상 Ferrari 모델을 쓰고 싶어 하는데, 이 작업엔 Hyundai 모델이면 된다"는 것이다. 단 라우팅에는 함정이 있다. 더 싼 모델로 보냈다가 캐시가 깨지면 토큰을 10배 더 쓰게 될 수 있다. 그리고 모델별 백만 토큰당 가격은 몇 센트에서 수십 달러까지 벌어져 있다. 지표 얘기로는 운영 지표와 회복력 지표를 거쳐 결국 성과 지표로 가야 한다고 말하며 "cost per verified outcome" 같은 예를 든다. 이사회가 묻기 시작한 질문은 "AI에 이 돈을 다 썼는데, 그 지능의 가치는 무엇이고 어떤 성과로 이어졌나"다.

Value 버킷은 소프트웨어 비즈니스 모델을 직접 흔들고 있다. Microsoft, Google, Adobe, SAP, ServiceNow 같은 대형 소프트웨어 제공사들이 좌석(seat) 과금과 무제한 모델에서 사용량 과금으로 옮겨가고 있고, 그 동인 중 하나가 에이전트다. Storman의 표현으로 "에이전트는 사람보다 좌석을 훨씬 공격적으로 쓴다." 등장하는 과금 형태는 셋이다. 여러 제공사 비용을 추상화하는 크레딧 기반, 월 정액에 사용량을 얹는 하이브리드(전통적으로 좌석 과금이던 Salesforce가 AI 애드온을 붙인 사례), 그리고 마크업을 붙여 토큰 수를 그대로 통과시키는 직접 과금이다. 그는 "불투명하지만 비싼 방식에서 명확하지만 여전히 비싼 방식으로 옮겨가는 중"이라고 농담한다. 공급망 효과의 예로는 Apple이 메모리 가격 상승 때문에 제품 가격을 올린 사건을 든다. 메모리 원가가 오르면 지능의 원가가 오르고, 결국 그 회사가 고객에게 과금하는 방식 자체를 바꿔야 할 수 있다는 것이다.

남은 질문들도 정리해 둔다. 지능적 성과를 어떻게 측정할 것인가, intelligence per watt로 볼 것인가 TCO로 볼 것인가, 수천 개 모델이 있는 상태에서 가격 변경과 투명성을 어떻게 표준화할 것인가, 엔지니어의 실험을 장려하려면 실패의 비용을 어떻게 가격 매길 것인가, 그리고 이 일을 사람이 해야 하는가 에이전트가 해야 하는가. Luke가 "분자(가치)가 분모(비용)보다 측정하기 어렵다"고 하자 Storman은 반쯤 동의하면서 반박한다. 가치가 초점인 건 맞지만 TCO 분모를 정확히 뽑는 것도 기술 분야에서 늘 어려웠고 AI에서는 100배 더 어렵다는 것이다. 소프트웨어 생산성 지표의 역사도 짚는다. 코드 라인 수에서 스토리 포인트, 풀 리퀘스트로 옮겨왔는데 GitHub 리포팅 기준으로 커밋과 코드 라인과 PR 수가 최근 6개월간 수직 상승했다. "그렇다고 더 좋은 제품을 더 많이 내놓는다는 뜻은 아니다. 코드를 더 많이 낸다는 뜻일 뿐이다."

재단의 실체와 일정도 구체적이다. FinOps Foundation은 6~7년에 걸쳐 12만 명 실무자 커뮤니티와 프레임워크와 자격증을 쌓았지만, Tokenomics Foundation은 Kubernetes 같은 기증 자산에서 시작한 CNCF와 달리 그린필드다. 플레이북 없이 레퍼런스 가이드, 구현체, 프레임워크, 모범사례를 대형 토큰 소비자와 대형 토큰 공급자를 한자리에 모아 만들겠다는 계획이다. 컴플라이언스와 소프트웨어 정책과 조달을 다루는 ITAM Forum도 최근 합류했고, 모든 작업을 오픈소스 FOCUS spec에 정렬한다. 그가 데이터 규모로 비교한 문장이 인상적이다. "클라우드 빌링은 월 수억 행 문제다. 토큰은 수조 행 문제다. 이건 관측성과 텔레메트리 문제다." 파트너로는 Anthropic이 MCP를 기증한 Agentic AI Foundation, CNCF, vLLM을 호스팅하는 PyTorch Foundation, Linux 커널이 거론된다. 신설 컨퍼런스 이름은 Tokenomicon이고 메인은 내년 6월 샌디에이고, 그 전에 2026년 9월 암스테르담과 2027년 2월 런던이 있다.

마무리에서 Storman은 Block이 낸 intelligence hierarchy 관련 글을 인용하며, 지금까지 사람이 하던 역할을 에이전트라는 비인간 노동이 채우는 시대에 진입했고 이것이 가치와 팀 구조와 비용을 보는 방식을 바꾼다고 말한다. 그가 재단 사람들에게 요구하는 태도는 "우리가 안다고 생각하는 것에 대한 도그마에서 물러서라"이고, 2주 여행 다녀온 사이에 open weights 모델의 비중이 확 커지고 Kimi K3가 발표되면서 세상이 달라져 있더라는 일화를 근거로 든다. 이전에는 중국 모델을 크게 보지 않았는데 지금은 프론티어와 섞어서 고려하는 균형이 생겼다는 것이다. rapid-fire 라운드에서는 "tokenomics는 그냥 책임 있는 지출 아니냐"에 반대, "언젠가 클라우드 자원 할당의 주요 메커니즘이 될 것"에는 부분집합일 뿐이라는 단서를 달아 동의, "FinOps의 병목은 기술보다 재무 문화"에 동의, "실시간 텔레메트리 빌링 데이터가 토큰 효율에서 가장 활용 안 된 자원"에 강하게 동의, "알고리즘적 자원 최적화가 10년 안에 사람보다 낫다"에 동의하되 1년으로 좁히면 반대라고 답했다. 닫는 조언은 커리어 얘기다. "AI가 내 일자리를 빼앗느냐"는 질문에 "지금 당장은 아마 아니다. 하지만 AI를 더 잘 쓰는 다른 사람은 확실히 당신 일자리를 노리고 있다"고 답한다. "일자리는 있을 거다. 다만 다른 일자리일 거다."

Skills와 MCP는 경쟁이 아니라 역할 분담 - progressive disclosure가 만드는 컨텍스트 절약

YouTube · Google Cloud Tech

4분짜리 짧은 대담인데 Skills와 MCP의 관계를 헷갈리는 사람에게 줄 만한 설명이 압축돼 있다. 시작은 MCP 정의다. Model Context Protocol의 약자이고, API를 통해 프로그래밍 가능한 데이터와 모델을 연결해 추가 컨텍스트를 주는 방식이다. 실질적으로는 대규모 언어모델을 거쳐 자연어로 API와 대화하게 해주는 것이다. MCP가 처음 나왔을 때 왜 그렇게 흥분됐는지도 짚는다. 갑자기 LLM이 바깥 세계 전체와 대화할 수 있게 됐고 파일 시스템에도 접근할 수 있게 됐다. 온갖 도구에 접근하는 표준화된 프로토콜이 생긴 것이다.

문제는 규모가 커지면서 드러났다. 모델에게 주는 도구를 정의할 때 그 정의가 수백 줄의 지시문이 될 수 있다. 그걸 도구 20개에 대해 한다고 상상해보라. 그러면 지금 하고 있는 대화와 아무 상관 없는 컨텍스트가 전부 올라와 있게 된다. 도구를 더 붙일수록 컨텍스트 부풀림(context bloat)이 생기고 컨텍스트 관리가 까다로워진다는 것이다.

여기서 Skills가 등장한다. 화자가 먼저 못 박는 건 위치 관계다. "MCP의 대체재가 아니라 보완재다." 그리고 가장 실용적인 정의를 준다. "Skills를 얘기할 때 80%는 저장된 프롬프트를 말하는 것이다." 대부분의 사람에게 skill은 반복해서 쓰고 싶은 프롬프트가 담긴 마크다운 또는 텍스트 파일 하나로 시각화하면 된다. 다만 더 깊이 갈 수도 있다. 스크립트를 포함할 수도 있고, 커맨드라인 도구나 다른 도구를 어떻게 쓰는지에 대한 지시를 담을 수도 있다.

핵심 메커니즘으로 지목되는 건 progressive disclosure다. 화자는 skill이 3단 정의라고 설명한다. 첫째 frontmatter는 skill의 요약이고 "이 skill을 언제 쓰는가, 무엇을 하는가"를 모델에게 알려주는 줄이 들어간다. 둘째 body는 모델이 무엇을 해야 하는지 사람이 읽을 수 있는 영어 지시문 전부다. 셋째는 선택적 링크 파일로, 결정론적으로 실행할 스크립트를 써뒀다면 여기 붙인다. 화자는 이 세 번째를 "많은 skill에는 없지만, 스크립트와 다른 도구를 붙이기로 하면 이게 초능력이 된다"고 표현한다.

이 3단 구조가 왜 컨텍스트를 아끼는지에 대한 설명이 이 영상의 핵심이다. 에이전트가 기동할 때 모든 skill의 frontmatter만 로드한다. 그래서 에이전트는 "내가 할 수 있는 일 목록과 어떤 상황에 이 도구를 꺼내는지"에 대한 내부 레지스트리를 갖게 되지만, 실제 지시문은 필요하다고 판단하기 전까지 로드하지 않는다. skill 20개의 전체 정의를 한꺼번에 올려두는 것보다 메모리를 훨씬 효율적으로 쓰게 되는 이유다. 그 대비로 MCP의 구조적 한계가 정리된다. 상대 화자의 요약이 정확하다. "MCP는 그만큼 압축이 안 된다. frontmatter 같은 시스템이 없다. 그래서 컨텍스트도 메모리도 훨씬 많이 먹는다. 게다가 에이전트를 시작할 때 그걸 로드할지 말지 고를 선택권도 없다." 차이는 "무엇을 할 수 있느냐"가 아니라 "요약 계층이 있느냐, 지연 로딩이 되느냐"다.

그렇다고 양자택일이 아니라는 점도 분명히 한다. 실제로는 MCP와 Skills를 둘 다 갖고 있는 경우가 많고, skill이 에이전트에게 그 MCP 혹은 MCP로 노출된 도구들을 어떻게 쓰는지 알려주는 조합이 자연스럽다. 업계 타임라인에 대한 관찰도 남길 만하다. "18개월 전에는 MCP가 바로 그것이었다." 그리고 지금도 여전히 유효하다고 덧붙인다. "당신이 좋아하는 챗앱에서 커넥터를 볼 때마다, 그 밑을 돌리는 건 아마 MCP다." 그 위에 Skills가 나온 이유는 사람들이 필요로 한 게 항상 외부 도구는 아니었고 프롬프트를 붙잡아두고 반복 재사용하거나 공유할 방법이 필요했기 때문이라는 것이다.

마지막 논지는 접근성이다. skill은 만들고 다듬고 팀이나 동료에게 공유할 수 있는데, 반복해서 쓰는 비즈니스 로직을 담을 수 있다는 점뿐 아니라 영어로 쓰여 있다는 점이 강력하다. 개발자가 아닌 사람도 skill을 쓰고 공유해서 다른 모두를 더 빠르게 만들 수 있다. 상대 화자가 이걸 받아 정리한 문장이 이 영상에서 가장 인용하기 좋은 대목이다. "가장 뜨거운 프로그래밍 언어는 영어다. Skills는 당신이 당신만의 에이전트를 영어로 프로그래밍하게 해준다." 이 항목이 갖는 값은 둘이다. "Skills가 MCP를 대체하는가"라는 흔한 오해에 Google 쪽 인사가 공개적으로 "보완재"라고 못 박은 기록이라는 점, 그리고 progressive disclosure를 컨텍스트 비용 문제로 설명한다는 점이다. 도구를 많이 붙일수록 대화와 무관한 토큰을 매 요청 지불하는 구조이고, frontmatter만 상주시키는 설계는 그 상시 비용을 깎는 엔지니어링적 답이다.

에이전트 메모리는 저장소가 아니라 라이프사이클 - Zero-Mem, LLM-Wiki, ACM

GeekNews · PyTorchKR 주간 논문

메모리 쪽 세 논문은 "RAG를 더 잘 튜닝하자"가 아니라 "지식을 어떤 자료구조로 갖고 있어야 하는가"를 묻는다.

Zero-Mem이 던지는 질문은 도발적이다. 구조화된 메모리 접근에 생성이 정말 필요한가. 기존 메모리 시스템은 요약, 반영(reflection), 그래프 생성 같은 중간 기록을 LLM이 직접 만들고 그 검색까지 중재한다. 이 과정에서 토큰과 시간 비용이 매 턴 반복 발생하고, 세부가 생략되거나 병합되면 원래 근거가 흐려진다. Zero-Mem은 원본 상호작용 트레이스를 유일한 source of record로 그대로 두고, 생성 없이 두 개의 상호보완적 구조 위에서 증거를 고른다. 개체-문맥 그래프가 상호작용 간 공출현과 인접 관계를 드러내고, 시간 계층이 대화의 지역성과 세션 상태를 보존한다.

질의마다 주체, 키워드, 답변 유형, 시간 단서를 담은 가벼운 프로파일로 두 관점의 상대 가중치를 정한 뒤, 그래프 전파와 Personalized PageRank, 그리고 에피소드에서 윈도우로, 다시 턴으로 내려가는 계층 검색을 병행한다. 이어서 이중 관점 융합과 증거 폐쇄(evidence closure)로 관계적 다리와 주변 문맥을 보충하고, 결정론적 보정이 충돌하거나 경계를 위반한 증거를 걸러낸다. LLM은 오직 최종 QA 리더 단계에서만 호출된다. 결과적으로 동일한 최종 리더와 컨텍스트 예산 아래 경쟁력 있는 성능을 유지하면서 메모리 연산의 LLM 토큰을 완전히 제거했고, 가장 빠른 비교 대상 대비 메모리 연산 시간을 57.6% 줄였다. 벤치마크는 LoCoMo와 HotpotQA 등 장기 메모리와 장문맥 QA다.

LLM-Wiki는 검색 자체를 추론으로 재정의한다. 기존 RAG가 외부 지식을 임베딩 유사도로 꺼내는 평평한 청크로 조직하면 retrieval-as-lookup 인터페이스가 되고, 이건 멀티홉 추론에 구조적으로 취약하다. 논문이 드는 예는 영화 비교 질의다. 감독을 식별하고 생년을 비교하는 식으로 중간 증거가 원 질의와 의미적으로 멀어지면 dense retrieval은 핵심 페이지를 놓친다. 병목은 순위 함수가 아니라 지식이 조직되고 노출되는 방식이라는 것이 주장이다. 해법은 원문 문서를 양방향 링크가 있는 구조화된 Wiki 페이지로 컴파일하고, search와 read와 link-following과 충분성 점검을 표준 tool-calling으로 여는 것이다. 여기에 Error Book을 붙여 구조적 오류와 의미적 오류를 탐지하고 귀속시켜 재사용 제약으로 축적한다. RAPTOR, GraphRAG, HippoRAG 2, LightRAG가 요약이나 트리플이나 엔티티 인덱스로 검색을 부분 강화한 것과의 차별점은 그래프를 쓰느냐 여부가 아니라 사람이 감사할 수 있는 Wiki 표면을 에이전트가 순회 가능한 연산으로 연다는 데 있다. 수치로는 HotpotQA, MuSiQue, 2WikiMultiHopQA에서 HippoRAG 2, LightRAG, GraphRAG 대비 2.0에서 8.1 F1 포인트 우세, AuthTrace에서는 전체 정확도 최고와 함께 다중 문서 구조화 질의에서 특히 큰 이득을 보고한다.

Agentic Context Management(ACM)는 가장 실무 지향적이다. 프로덕션 에이전트의 실패는 추론을 못해서가 아니라 대화 이력, 대형 프롬프트, 대규모 도구 정의, 팽창하는 도구 출력을 컨텍스트 윈도우에 담는 규율이 없어서 생긴다는 진단에서 출발한다. 기존 생태계는 이를 저장과 검색 문제로 다루지만, 실제로 매 턴 내려야 하는 결정은 무엇을 남길지, 어떤 구조로 남길지, 이번 턴에 무엇을 넣을지, 다음 턴이 무엇을 필요로 할지, 예산을 넘으면 어떻게 줄일지에 걸쳐 있다. ACM은 이를 다섯 프리미티브로 분해한다. architecting은 에이전트 연결 시 목적 설명으로부터 범주와 보존과 압축 정책을 합성해 이후 수집과 검색과 압축 행동을 규율한다. ingesting은 원시 신호를 사실, 선호, 에피소드, 시간적 사건으로 구조화해 검색 품질의 상한을 높인다. scoping은 가장 좁은 스코프부터 해석하며 엄격 격리를 유지하고, 사용자와 고객 조직과 플랫폼 운영자라는 스코프 계층과 전역 지식 계층 위에서 동작한다. anticipating은 투기적 프리페치로 명시 요청 전에 컨텍스트를 준비해 임계 경로 지연을 줄인다. compacting은 검증 점수와 압축비를 보고 실패하면 덜 공격적으로 재시도하는 검증된 압축이다.

경제 논거가 이 항목의 핵심 문장이다. 전체 이력을 그대로 붙이면 토큰 비용이 대화 길이에 대해 이차, 즉 O(n^2)로 증가하고, 조악한 요약은 선형 비용을 사는 대신 정확도 절벽을 지불하며, 검증된 압축만이 선형 비용과 충실도를 동시에 얻는다. 참조 구현 Maximem Synap은 비동기 수집, 의미와 관계를 섞은 하이브리드 검색, 스코프 인식 조립을 멀티테넌트 서비스로 구현해 LongMemEval 92%, LoCoMo 93.2%를 보고한다. 논문은 기존 벤치마크가 아직 못 잡는 축으로 지연시간, 토큰 효율, 컨텍스트 부패(context-rot) 저항성을 지목한다. 다만 ACM이 자사 제품의 백서 성격을 겸한다는 점은 감안해야 한다. 92%와 93.2%는 논문 6절의 특정 구성 아래 값이고, 같은 벤치마크가 포화 논란의 대상이라는 점과 함께 읽어야 한다.

OpenAI가 일상 텍스트 대화를 전 플랜 무제한으로 열고 API 가격을 최대 80% 내렸다

LinkedIn · Seowoo Han

API Changelog만 보면 놓치는 변경이 많다는 문제의식에서, ChatGPT 요금제 페이지와 Work 및 Codex 공식 문서와 Rate Card까지 함께 훑어 정리한 글이다. 결론은 ChatGPT를 쓸 수 있는 한도와 방식이 꽤 넓어졌다는 것인데, "무제한"이라는 단어가 실제로 어디까지 적용되는지를 구분한 부분이 이 글의 값어치다.

먼저 Free, Go, Plus, Pro 네 플랜 모두에서 everyday text chat이 무제한으로 열렸다. Free 플랜에서도 GPT-5.6 Luna로 텍스트 대화를 계속 이어갈 수 있다. 무료 사용자가 최신 모델로 대화 횟수 제한 없이 붙을 수 있게 됐다는 뜻이라 진입 장벽 쪽 변화가 크다. 다만 무제한의 범위는 일상적인 텍스트 Chat이다. 고급 추론, 파일 업로드, 이미지 생성, 도구를 사용하는 메시지에는 플랜별 한도가 그대로 남는다. 같은 ChatGPT 안에 있어도 어떤 기능을 쓰느냐에 따라 한도 계산 방식이 다르다는 것이 실무자에게 가장 중요한 구분이다.

기업 플랜의 구조도 명시됐다. Business와 Enterprise에서는 Work와 Codex가 하나의 shared agentic pool을 함께 사용하고 추가 사용량은 Rate Card에 따라 크레딧으로 계산된다. 무제한 Chat에도 오용을 막기 위한 guardrails가 적용된다. 팀 단위로 Codex를 많이 돌리는 조직이라면 Chat 무제한과 무관하게 agentic pool 소진 속도를 따로 관리해야 한다.

API 쪽 변화는 가격이 핵심이다. Luna 가격이 80%, Terra 가격이 20% 낮아졌고 Fast mode가 추가됐다. 운영 측면에서는 Usage와 Costs를 API key별로 확인할 수 있게 됐고 hard spend limit이 들어왔다. 키마다 비용을 분리해 보고 최대 지출액을 강제로 묶을 수 있다는 것은, 여러 서비스에서 같은 조직 키를 쓰던 팀에게는 곧바로 적용 가능한 운영 개선이다. 작성자 본인의 사용 패턴도 참고할 만하다. 복잡한 작업은 ChatGPT에서 아이디어와 요구사항을 오래 정리한 뒤 실제 개발은 Codex에 맡기고, 문서나 스프레드시트처럼 긴 결과물이 필요한 일은 Work에 넘긴다. 기획은 Chat에서 마음껏 하고 Work와 Codex 한도는 아껴 쓰는 배분이 권고로 제시된다.

추론 비용을 깎는 두 갈래 - 라우터 모델 교체와 모델 간 KV 캐시 이전

Threads · feelfree_ai, LinkedIn · AI & Machine Learning Community

같은 날 올라온 두 건이 서로 다른 층위에서 같은 문제를 겨냥한다. 모델 하나를 계속 키우는 대신, 여러 모델을 상황에 맞게 갈아타면서 비용을 깎는 구조를 어떻게 실용적으로 만들 것인가다.

첫째는 라우팅이다. Sakana AI는 여러 모델에 작업을 적절히 할당하는 Fugu에서 그 배분을 담당하는 지휘자 역할 모델을 Gemma 4로 교체했다. 결과는 기존 구조 대비 성능은 비슷하게 유지하면서 비용을 30% 이상 절감. 라우터 자체를 가볍고 똑똑한 모델로 바꾸는 것만으로 전체 시스템 비용이 3분의 1 가까이 빠졌다는 뜻이다. 원 게시자는 여기서 한 걸음 더 나가, 무거운 단일 거대 모델에 의존하는 방식보다 가벼운 라우팅 모델을 앞세워 적재적소에 모델을 배치하는 하이브리드 구조가 실무의 기본형이 될 것이라고 봤다.

둘째는 모델을 갈아탈 때 발생하는 숨은 비용이다. 비용과 품질을 조절하려고 크기가 다른 모델 사이를 오갈 때, 지금까지는 KV(key-value) 캐시를 처음부터 다시 채우는 re-prefill이 필요했다. 대화가 길수록 이 비용이 커지고, 사용자 입장에서는 모델을 바꾸는 순간 응답이 멈추는 것으로 체감된다. NVIDIA 연구진이 제안한 cross-model KV cache transfer는 소스 모델의 KV 캐시를 타깃 모델에서 재사용해 이 re-prefill 자체를 없애자는 접근이다.

근거는 관찰된 선형성이다. KV head 수와 차원을 공유하는 모델 쌍에서는 KV 쌍 사이에 뚜렷한 선형 관계가 나타난다. Qwen3 14B에서 32B로 전환하는 경우, 단일 소스 레이어 하나가 타깃 모델 키와 값의 분산 중 상당 부분을 설명하고 소스 레이어를 여러 개 쓰면 설명력이 더 올라간다. 방법은 closed-form ridge mapper 3단계로 정리된다. 첫째, 타깃 레이어마다 예측력이 높은 top-k 소스 레이어를 고른다. 둘째, 키에서 위치 인코딩을 제거해 위치에 얽매이지 않는 매핑을 만든다. 셋째, 소규모 캘리브레이션 데이터에 ridge regression을 적용해 매핑을 학습한다. 학습이 폐형식 해로 끝나므로 별도의 대규모 재학습이 필요 없다.

결과는 두 축으로 보고됐다. 정확도 쪽에서는 여러 벤치마크에서 타깃 모델 단독 정확도의 상당 부분을 유지하며 기존 re-prefill 대비 우위를 보였고, 속도 쪽에서는 re-prefill보다 훨씬 빨라 멀티턴 대화처럼 응답 지연이 바로 체감되는 환경에 특히 유리하다. 평가 기준에 대한 지적도 함께 나왔다. 전송 품질은 잔차 오차가 얼마나 큰지보다, 그 오차가 타깃 모델의 attention 민감 영역과 얼마나 정렬돼 있는지에 더 좌우된다. 앞으로 cross-model mapper를 평가할 때 단순 오차 크기 지표만 보면 안 된다는 뜻이다.

Codex 요금제 체감 - $100 플랜의 배수가 10배에서 5배로, Sol은 하루에 주간 한도를 태운다

Reddit · r/OpenaiCodex, Reddit · r/codex, PSA 스레드

Codex 관련 서브레딧 네 개 글이 같은 문제의 네 면을 보여준다. 가격 구조, 한도 소진 속도, 품질 변동, 그리고 그걸 우회하는 사용자 워크플로다.

가격 쪽 불만은 산수 하나로 요약된다. 게시자가 가입할 때 $100 플랜은 $20 플랜의 10배 사용량이었는데 지금은 5배다. 그러면 $20 계정 다섯 개와 $100 한 개가 같아지므로 상위 플랜에 규모의 이점이 없다. 보통 상위 요금제는 단가가 싸져야 하는데 오히려 같아진 셈이고, 게시자는 최소 6배는 돼야 납득이 된다고 적었다. 댓글 70개가 달렸다는 건 이 체감이 혼자만의 것이 아니라는 뜻이다.

한도 소진 비교는 오늘 나온 것 중 가장 구체적인 수치다. 같은 프로젝트, 같은 루틴에서 GPT-5.6 Sol을 Extra High로 쓰면 12~14시간 근무 하루 한 번에 주간 한도를 소진한다. 반면 Opus 5를 Ultracode + Thinking으로 쓰면 같은 조건에서 일주일을 버틴다. 게시자가 덧붙인 판정이 중요하다. 품질 차이를 유의미하게 느끼지 못했고, 그래서 실질적인 차이는 성능이 아니라 가용성이라는 것이다. 한쪽은 계속 쓸 수 있고 다른 쪽은 한도 리셋을 기다리는 시간이 대부분이 된다.

여기에 품질 변동 보고가 겹친다. 며칠 전까지 같은 저장소에서 잘 작동하던 Sol이 하루 넘게 자기 꼬리를 쫓으며 진전이 없다는 글이 별도로 올라왔다(업보트 9, 댓글 20). "모델이 멍청해졌다" 류 보고는 검증이 어렵고 플라시보일 수 있다는 점을 함께 적어둔다. 다만 한도와 품질 불만이 같은 주에 몰렸다는 사실 자체는 기록할 값이 있다.

마지막 글은 대응책이다. ChatGPT Pro 구독자는 웹사이트 채팅이 사실상 무제한이고 Pro 수준 thinking effort를 쓸 수 있는데, Work 모드로 바꾸지 않는 한 이 사용량이 별도 한도에 잡히지 않는다는 것이다. 그래서 게시자는 계획과 초기 빌드를 전부 ChatGPT 웹에서 끝내고, 프로젝트 전체를 ZIP으로 생성시킨 다음 Codex CLI나 Codex 앱으로 옮겨 확장과 수정만 시킨다. ZIP과 7z를 웹에 직접 업로드하면 풀어서 다룰 수 있다는 점도 함께 알렸다. 그의 주장은 단호하다. 계획의 대부분을 CLI나 앱 안에서 하면 안 된다.

ChatGPT의 High 모드 웹 리서치가 41분간 연속 작업해 발표자료를 만들었다는 보고

Reddit · r/OpenAI

이 글의 값어치는 주장보다 범위 설정에 있다. 게시자가 두 번 강조한다. 이건 deep research 기능 얘기가 아니라 일반 채팅에서 thinking effort를 High로 올린 상태 얘기다. 별도 제품을 켜지 않은 기본 경로에서 나오는 동작이라는 것이다.

핵심 사례는 하나지만 구체적이다. GPT-5.4 Extended Thinking(지금은 High로 이름이 바뀐 그 모드)에게 경제학 주제를 조사해서 .pptx 파일로 발표자료를 만들어달라고 했더니 41분 동안 쉬지 않고 작업했다. 그것도 Codex가 아니라 웹 앱에서다. 게시자의 표현대로 주제를 던지고 High로 두면 수십에서 수백 개의 웹페이지를 가로지르며 충분한 정보가 모일 때까지 검색을 계속한다. 이 성질은 o4-mini-high와 o3 때부터 있었고 릴리스마다 좋아졌으며 5.6 Sol에서 특히 좋다는 게 시간축 평가다.

비교 대상은 Gemini다. 게시자는 Gemini가 게으르고 ChatGPT처럼 끈질긴 웹 검색을 하지 않으며 3.1 Pro에서도 마찬가지라 근처에도 못 온다고 적었다. 이건 벤치마크가 아니라 한 사용자의 체감이므로 체감으로 읽어야 한다. 다만 앞 항목의 ChatGPT Pro PSA와 붙여 읽으면 실무 결론이 하나 나온다. 웹 채팅 쪽 사용량이 코딩 에이전트 한도와 분리돼 있다면, 리서치와 계획처럼 오래 걸리고 토큰을 많이 먹는 작업은 웹 쪽에서 처리하고 CLI 한도는 실행에만 쓰는 게 합리적이다. 두 글이 서로 다른 사용자에게서 나왔는데 같은 결론을 향한다.

로컬 스택과 경량화

24GB VRAM은 24GB가 아니다 - 로컬 LLM 메모리 계산 워크시트

Reddit · r/ollama

로컬 LLM을 처음 돌리는 사람들이 가장 흔하게 하는 계산 실수를 정면으로 다룬 글이다. 문제 정의는 간단하다. "모델 파일이 20GB고 내 카드가 24GB니까 되겠지"가 틀린 이유는 GPU에 올라가는 게 가중치만이 아니기 때문이다.

계획 모델은 두 줄이다. 쓸 수 있는 용량은 광고된 VRAM의 90% 정도로 잡고(usable capacity = advertised VRAM x 0.90), 필요한 총량은 모델 가중치 + KV 캐시 + 런타임 여유분으로 잡는다. 90%라는 값 자체는 보수적 출발점일 뿐이며 실제 시스템을 띄운 뒤 직접 측정하라고 명시한다.

가중치 바닥값은 4비트 기준으로 정확한 숫자를 준다. 7B는 3.26 GiB, 13B는 6.05 GiB, 32B는 14.90 GiB, 70B는 32.60 GiB다. 여기에 조건이 붙는다. 이건 파라미터만 세어 나온 깨끗한 바닥값이고, 실제 GGUF, GPTQ, AWQ 파일은 스케일 값, 메타데이터, 혼합 정밀도로 남겨둔 텐서, 포맷별 선택 때문에 이보다 크다. 90% 규칙을 적용하면 카드 라벨은 이렇게 번역된다. 8GB는 7.2 GiB, 12GB는 10.8 GiB, 16GB는 14.4 GiB, 24GB는 21.6 GiB, 32GB는 28.8 GiB다. 제목의 "24GB는 24GB가 아니다"가 여기서 나온다. 70B 4비트의 바닥값 32.60 GiB는 24GB 카드는 물론 32GB 카드(실효 28.8 GiB)에도 안 들어간다.

그다음이 대부분 사람이 빼먹는 KV 캐시다. 시작 산식은 2 x layers x KV heads x head dimension x cached tokens x bytes per element x concurrent sequences이고, 여기서 나오는 두 가지 스케일링 규칙이 실무에서 중요하다. 컨텍스트를 두 배로 늘리면 캐시가 대략 두 배가 되고, 동시에 처리하는 full-context 요청을 두 배로 늘리면 거기서 또 두 배가 된다. 긴 컨텍스트와 동시 요청은 곱으로 작용한다.

게시자의 작업 순서는 다섯 단계다. 파라미터 수가 아니라 정확한 체크포인트에서 시작하고, 실제로 쓸 컨텍스트와 동시성에 맞춰 KV 캐시를 더하고, 런타임 작업 공간과 여유분을 더하고, 박스 라벨이 아니라 실효 용량과 비교하고, 피크 메모리와 time to first token과 초당 토큰을 벤치마크한다. 마지막 경고가 이 글의 다른 축이다. 메모리에 들어간다고 빨라지는 게 아니고, CPU 오프로드는 로드는 되게 해주지만 생성 속도를 크게 떨어뜨린다. 게시자는 ResearchAudio를 운영하며 이 계산을 하는 브라우저 계산기를 만들었고 무료이며 입력값을 서버로 올리지 않는다고 밝혔다. 홍보성 링크가 포함돼 있지만 본문의 수치 자체는 계산기 없이도 그대로 쓸 수 있다.

15개 언어 번역 메모리 실측 - 로컬 조합이 Voyage API를 앞섰다

Reddit · r/Rag, F2LLM V2 4B, Zerank 2

업보트는 4에 그쳤지만 오늘 나온 것 중 재사용 가치가 가장 높은 실측 데이터다. 게시자는 Translation Memory 서버를 만들면서 임베딩과 리랭커 조합을 직접 다 돌려봤다. 과제는 명확하다. 영어로 된 구문, 단어, 문장, 문단이 주어지면 이미 번역돼 있는 대상 언어 항목 중 유사한 것을 찾아야 하고, 대상은 서구권과 동양권을 포함한 15개 언어다. MRR은 최종 점수, Re-델타는 리랭커가 순위를 얼마나 개선했는지, R@20은 정답 번역이 검색된 20개 안에 들어왔는지의 비율이다.

표에서 읽어야 할 지점이 세 가지다. 첫째, 로컬 조합(F2LLM 4B + Zerank 2 4B, MRR 0.919)이 유료 API 조합(Voyage 4 Large + Voyage Rerank 2.5, MRR 0.889)을 앞섰다. R@20도 98.40% 대 94.70%다. 둘째, Re-델타 부호가 중요하다. BGE M3 계열은 리랭커를 붙이면 오히려 점수가 떨어졌고(-1.60%, -7.50%), F2LLM 1.7B + Zerank 1도 -2.20%다. 리랭커가 항상 도움이 되는 게 아니라는 실증이다. 반대로 임베딩이 약한 조합일수록 리랭커 기여가 커진다. Zembed 4B는 +25.80%인데 최종 MRR은 0.664로 최하위다. 큰 Re-델타는 리랭커가 좋다는 신호가 아니라 임베딩이 나쁘다는 신호일 수 있다. 셋째, 벤치마크 성적과 실사용이 갈린다. 게시자는 Qwen 3 4B 임베딩과 리랭커가 공개 벤치마크에서는 잘 나오지만 이 실제 케이스에서는 평범했다고 명시했다(0.739 / 77.50%로 표 하위권).

모든 로컬 모델은 llama.cpp에서 Q8_0 양자화로 돌렸다. 8B로 올리면 MRR이 0.922, R@20이 99.20%로 미세하게 오르지만 지연시간을 감수할 만하지 않다는 게 게시자 판단이라 실무 권장은 4B 조합이다. 라이선스 맥락도 실행에 직결된다. Zerank 2는 16일 전까지 비허용 라이선스였는데 Notion이 ZeroEntropy를 인수하면서 오픈소스로 풀렸다. F2LLM V2는 라이선스와 학습 데이터와 코드가 전부 공개돼 있고 MTEB 리더보드 상위권이라, 게시자는 임베딩 모델로 사실상 SOTA라고 평가했다.

8MB 임베딩 모델 Lattice, 위키피디아 640만 문서를 맥북에어에서 7분 26초에

Threads · billionnapkin

"위키피디아 전체를 검색하는 AI가 8MB 파일 하나에 들어갔다"는 문장이 돌았고, 이 게시물은 그 문장이 어디까지 맞고 어디서 틀리는지를 정리했다. 사실 확인이 포함돼 있어서 그대로 인용하기 좋은 항목이다.

먼저 맞는 부분이다. 개발자 Erik Kaunismäki가 공개한 Lattice는 약 8MB짜리 초경량 검색용 임베딩 모델이고, Apple M2 MacBook Air에서 영문 위키피디아 640만 개 문서를 전부 임베딩하는 데 7분 26초가 걸렸다. 노트북 한 대로 위키피디아 전체를 10분 안에 벡터화할 수 있다는 것은 그 자체로 의미 있는 수치다. 이 속도가 가능한 이유는 구조가 단순해서다. Transformer를 쓰지 않는다. 문장을 깊게 이해하는 대신 각 토큰의 벡터를 찾아 평균내는 방식이다. 문맥에 따른 의미 변화를 잡지 못하는 대신 계산량이 압도적으로 줄어든다.

틀리는 부분이 중요하다. 8MB는 임베딩 모델의 크기이지 위키피디아 검색 데이터 전체가 8MB라는 뜻이 아니다. 640만 문서를 임베딩한 결과 벡터는 별도로 저장해야 하고, 실제로 검색을 하려면 ANN 같은 근사 최근접 이웃 인덱스도 따로 필요하다. 개발자 본인도 출력 결과를 별도 검색 인덱스에 넣어 사용하도록 설명한다. "8MB로 위키피디아 검색"이라는 요약은 모델과 인덱스를 뭉뚱그린 과장이다. 그럼에도 의미는 남는다. 임베딩 모델이 8MB까지 내려오면 엣지 기기, 브라우저, 모바일 앱 안에서 임베딩을 로컬로 계산하는 선택지가 생긴다. API 호출 없이 온디바이스에서 벡터를 만들고 서버에는 벡터만 보내는 구조가 가능해진다는 뜻이라, 앞의 라우터 경량화와 같은 방향, 즉 파이프라인에서 가장 자주 호출되는 부분부터 작게 만드는 흐름에 놓인다.

K-EXAONE-2.0이 vLLM 공식 upstream에 반영됐고 SGLang도 진행 중이다

LinkedIn · Kyungmin Lee, LinkedIn · DAEHWAN OH

국산 모델을 실제로 서빙하려 할 때 반복되던 마찰이 하나 줄어든다. LG AI Research가 개발한 K-EXAONE-2.0을 추론 엔진 vLLM과 SGLang의 공식 upstream에서 바로 사용할 수 있도록 하는 작업이 진행 중이고, vLLM 쪽은 이미 upstream에 반영됐다. 지금까지 국산 모델을 서빙하려면 fork를 따로 관리하거나 벤더 저장소를 별도로 물어야 했는데 그 의존이 사라진다는 것이 실질적 변화다.

이 차이는 운영에서 크게 벌어진다. fork 기반 서빙은 upstream이 릴리스될 때마다 리베이스와 재검증이 필요하고, 보안 패치 반영이 늦어지며, 사내 인프라 팀이 유지해야 하는 코드가 계속 쌓인다. 공식 upstream 지원은 이 부담을 통째로 없앤다. 게시자는 vLLM 메인테이너들의 빠른 리뷰와 도움 덕분이라며 DarkLight1337을 특정해 언급했다. 국내 조직이 글로벌 오픈소스 프로젝트에 모델 지원을 직접 올려 넣는 경로가 실제로 작동한 사례로 읽을 수 있다. 남은 작업도 명시됐다. DSpark 모델 지원 작업이 진행 중이고 SGLang의 K-EXAONE-2.0 지원은 현재 upstream 반영을 위한 작업 단계다. 즉 오늘 기준으로는 vLLM은 완료, SGLang은 진행 중이다. Hugging Face 문서에는 Low Latency에 특화된 스크립트와 High Throughput에 특화된 스크립트가 각각 따로 올라와 있어 활용 목적에 맞춰 시작점을 잡을 수 있다.

같은 날 국내 AI 인프라 쪽 인력 이동도 하나 있었다. 삼성전자에서 8.5년을 보낸 엔지니어가 AI 가속기 기업 Rebellions에 Framework Software Engineer로 합류했다. 담당 영역을 AI 가속기 주변 소프트웨어 스택 강화, 그중에서도 고성능 LLM 추론과 서빙으로 명시했고, Rebellions 하드웨어와 vLLM 및 PyTorch 같은 오픈소스 서빙 플랫폼의 접점에서 일하겠다고 밝혔다. 국산 모델의 upstream 지원과 국산 가속기의 서빙 스택 보강이 같은 날 나란히 올라온 셈이다.

tool call 안에서의 speculative decoding 논문이 r/LocalLLaMA 상위로

Reddit · r/LocalLLaMA, arXiv

정보량 대비 반응이 가장 크게 어긋난 글이다. 본문에 논문 링크와 X 게시물 링크 두 줄만 있는데 185 upvote와 댓글 47개가 붙었다. 주제만으로 로컬 LLM 커뮤니티의 관심을 끌었다는 뜻이다.

맥락은 이렇다. speculative decoding은 작은 draft 모델이 여러 토큰을 먼저 뽑고 큰 모델이 그걸 한 번에 검증해 처리량을 올리는 기법이다. 그런데 tool call 구간은 JSON 스키마처럼 구조가 강하게 정해진 출력이라 이 구간에서 draft 예측이 잘 맞을 여지가 크다. 로컬 환경에서 tool 호출 지연이 체감상 큰 병목이라는 점, 그리고 Gemma 4 tool calling 템플릿에 아직 버그가 남아 있다는 점을 함께 두면 왜 이 주제가 즉시 반응을 얻었는지 설명된다. 다만 지킬 선이 있다. 게시자가 논문을 요약하지 않았으므로 속도 향상 배수나 벤치마크 수치는 이 자리에서 인용하지 않는다. 논문이 공유돼 반응이 컸다는 사실과 링크까지가 확인된 범위다.

아날로그 인메모리 연산의 노이즈 내성은 완만히 나빠지지 않고 임계에서 무너진다

Reddit · r/MachineLearning, Towards Data Science

반응은 조용했지만(5 upvote, 댓글 2개) 숫자가 명확해서 남긴다. 아날로그 인메모리 연산은 가중치를 메모리와 연산 유닛 사이에서 왕복시키는 에너지 비용을 없앨 수 있어 다시 관심을 받고 있는데, 여기에 늘 따라붙는 반론이 노이즈다. 아날로그 셀에는 실제 편차가 있고, 디지털처럼 값을 refresh해서 빠져나갈 수 있는 종류의 문제가 아니다.

게시자는 이 반론을 추상적으로 논하는 대신 열화 곡선의 모양을 직접 보려고 간단한 실험을 돌렸다. 네트워크를 정상적으로 학습시킨 다음, 가중치 노이즈를 점점 키우면서 정확도를 측정했다. 결과가 핵심이다. 곡선이 매끄럽지 않다. 어느 지점까지는 정확도가 안정적으로 유지되다가 급격히 떨어진다. 83%에서 64%로, 그다음에는 사실상 무작위 수준이다. 노이즈에 비례해 조금씩 나빠지는 게 아니라 임계값을 넘는 순간 무너지는 형태다. 두 번째 실험이 실무적으로 더 중요하다. 학습 중에 노이즈를 주입해 재학습하면 그 임계값이 상당히 이동한다. 동일한 노이즈 수준에서 정확도가 61% 대 39%로 갈린다. 게시자의 가설은 최적화기가 더 평평한(flat) 최소점을 찾기 때문이라는 것이다.

게시자가 커뮤니티에 실제로 묻고 싶은 건 결과가 아니라 해석이다. flat-minima 설명이 이 22퍼센트포인트 격차를 설명하는 올바른 프레이밍인지 아니면 다른 무언가가 작동하는지, 그리고 노이즈를 주입해 놓고 잘 되기를 기대하는 방식 말고 대상 하드웨어의 실제 노이즈 프로파일을 겨냥한 명시적 sharpness 페널티처럼 노이즈 강건성 자체를 직접 최적화하는 연구가 있는지다. 코드와 그림이 함께 공개돼 있어 재현이 가능하다. 임계 붕괴라는 관찰은 배포 관점에서 의미가 있다. 노이즈가 비례적으로 성능을 갉아먹는다면 마진을 조금씩 확보하는 식으로 대응할 수 있지만, 임계 현상이라면 공정 편차나 소자 노후화로 임계선을 살짝 넘는 순간 모델이 통째로 쓸모없어진다. 노이즈 인지 학습이 그 임계선을 밀어주는 값싼 보험이 되는 셈이다.

모델 릴리스와 사용 경험

Google 모델 파이프라인 신호 두 건 - Gemma 팀 8월 20일 이벤트와 SDK에 남은 흔적

Reddit · r/LocalLLaMA, Reddit · r/GeminiAI

같은 날 Google 관련 커뮤니티 글 두 개가 서로 다른 경로로 같은 결론에 도달했다. 하나는 공식 일정에서, 하나는 코드 잔해에서 다음 모델이 임박했다는 신호를 읽었다.

r/LocalLLaMA 글은 Gemma 팀이 8월 20일 특별 이벤트를 연다는 u/hackerllama(Omar Sanseviero)의 트윗을 옮기면서, 여기서 Gemma 4.1이 나오길 바란다는 위시리스트를 붙였다. 게시자 본인이 "희망회로일 수 있다"고 먼저 선을 그었다는 점이 중요하다. 이건 유출이 아니라 기대다. 다만 그 기대의 내용이 로컬 모델 사용자들이 Gemma 4에서 실제로 겪고 있는 결함 목록이라 신호값이 있다. 모든 사이즈에 통일된 오디오 입력(최대 120B까지), tool calling 안정화, 시작부터 높은 정밀도의 QAT(quantization-aware training), 그리고 Gemma 4의 강점인 창작 글쓰기를 훼손하지 않는 일반 성능 향상 네 가지다. tool calling 버그는 추측이 아니라 google/gemma-4-26B-A4B-it Hugging Face discussion에 등록된 실제 이슈로 링크돼 있고, QAT 정밀도 문제도 별도 스레드가 근거로 걸려 있다. 게시자의 표현대로 "Gemma 4는 이미 좋고 완벽까지 딱 한 뼘"이라는 게 커뮤니티 정서다.

r/GeminiAI 글은 성격이 다르다. Gemini tokenizer 공개 코드에 gemini-4-flash-preview라는 식별자가 명시적으로 들어 있고, 그게 Google의 새 Gemma 4 tokenizer 계열에 매핑돼 있다는 관찰이다. 사내 툴링이 이미 그 모델을 지원하도록 준비돼 있다는 뜻으로 읽힌다. 다만 게시자도 명확히 남겨둔 미확정 지점이 있다. 이 모델이 최종적으로 Gemini 3.7 Flash로 나올지 Gemini 4 Flash로 나올지는 코드만으로 알 수 없다. "다음 Flash가 준비 중"까지가 근거 있는 결론이고 버전 번호는 아니다.

두 글을 붙여 읽으면 Gemma(오픈 웨이트)와 Gemini(폐쇄 API)가 tokenizer 계열을 공유하는 방향으로 정리되고 있다는 그림이 나온다. 실무적으로는 로컬에서 Gemma로 프롬프트를 다듬어 두면 Gemini Flash로 옮길 때 토큰 경계가 덜 어긋난다는 얘기가 되고, 반대로 Gemma 4의 tool calling 템플릿 버그가 Gemini 쪽 동작과 무관하지 않을 수 있다는 얘기도 된다.

"4.6이 매너 있던 마지막 Claude" - alignment가 caveat로 번역되는 문제

Reddit · r/Anthropic, Reddit · r/ClaudeCowork, Reddit · r/ArtificialInteligence

r/Anthropic 글은 오늘 본 것 중 가장 정교한 사용자 측 모델 비평이다. 게시자는 자기 자격을 먼저 밝힌다. 소프트웨어 엔지니어이고 특정 벤더에 매이지 않고 모든 모델을 무겁게 쓰며, 주 용도가 "아직 존재하지 않는 소프트웨어 패턴을 만들기 위한 리서치와 문답"이라 한 주제로 몇 시간씩 논점과 반론을 주고받는다. 그 결과 행동만으로 어떤 모델인지 구분할 수 있게 됐다는 것이다.

버전별 진단은 이렇다. 4.7에서 tokenizer가 바뀌었고 동시에 "명시적 지시를 따르도록" 학습된 티가 명확했다. 그래서 사용자가 원하는 바를 추론하는 폭이 줄었고, 명세가 덜 된 요청을 주면 추론 자체를 거부한다. 이건 당시에도 여러 글이 올라왔던 현상이라고 덧붙인다. Anthropic이 그 비판에 "더 정직하게 만들기"로 대응했고, 릴리스 노트가 alignment 개선에 대한 자화자찬으로 반짝인다고 꼬집는다. 그 결과가 4.8인데, 4.6 같은 매너 대신 모든 것에 단서를 다는 모델이 됐다("Every. Single. Thing."). Fable 5는 덜하지만 여전히 필요 이상으로 자기를 의심하고, Opus 5도 곧장 말하는 대신 이게 맞는 일인지 루프를 돈다. Sonnet 5에 대한 평은 "태도 문제 있는 haiku"다. 최근 그는 jailbreak 농담을 했다가 Fable 5에서 일시적으로 차단됐고(영구 아님, 분류기의 과도한 반응이라고 표현), 그 김에 오랜만에 4.6으로 돌아가 봤다가 "숨통이 트였다"고 표현했다.

글의 진짜 논점은 마지막 문단이다. alignment라는 단어가 실무에서 어떻게 번역되고 있는지에 대한 지적이다. 원래 misalignment는 "나쁜 짓을 한다"여야 하는데, 현장에서는 "사용자가 명시적으로 요청하지 않은 것을 했다"로 취급된다는 것이다. 그런데 요청하지 않은 그것이 종종 정확히 원했던 것이고, 그게 바로 좋은 매너다. 4.6에는 그게 있었다는 게 결론이고, 요구는 하나다. 이름은 뭐라 붙이든 4.6의 매너에 코딩과 추론 능력이 개선된 모델을 달라. 본인은 이걸 불평이 아니라 다른 사람들도 같은 걸 보는지 확인하려는 공개 분석이라고 못 박았다.

이 진단과 같은 방향의 신호가 둘 더 있다. r/ClaudeCowork의 "Claude 글쓰기 스타일에 질렸다"는 본문 없이 제목만인데도 288 upvote에 댓글 75개가 붙었다. 정보량은 없지만 정서의 규모를 보여주는 지표다. r/ArtificialInteligence 글은 벤더를 특정하지 않고 같은 피로를 말한다. AI를 오래 쓰다 보니 자기 자신이 예측 기계가 됐고, 프롬프트를 쓰기 전에 결과물이 이미 보이며, 그래서 편지나 이메일 같은 평범한 글은 프롬프트를 쓰고 다시 고치느니 그냥 손으로 쓴다는 것이다. 세 글을 합치면 이번 주 커뮤니티 정서는 성능 불만이 아니라 어조와 예측 가능성에 대한 피로다.

xAI가 Grok에서 손보는 건 벤치마크가 아니라 글쓰기 품질과 디자인 감각이다

X · leerob

xAI 내부에서 Grok의 개선 방향을 공개적으로 알린 짧은 게시물인데, 무엇을 개선 대상으로 지목했는지가 정보다. 성능 벤치마크 점수가 아니라 writing quality와 design taste, 즉 글쓰기 품질과 디자인 감각을 꼽았다.

이 선택은 지금 모델 경쟁의 위치를 보여준다. 추론 벤치마크 점수 차이가 좁아지면서, 실제 사용자가 체감하는 차이는 결과물의 문장이 읽을 만한지, 만들어준 UI가 볼 만한지 쪽에서 갈린다. 코딩 에이전트가 만든 화면의 기본 디자인 수준, 생성된 문서의 문장 톤 같은 것들이 여기 해당한다. 측정하기 어려운 축이라 벤치마크로는 잘 안 잡히지만 재사용률에는 직접 영향을 준다. 작성자는 아직 할 일이 많다고 인정하면서도 반복 속도가 빠른 점이 고무적이라고 했고, 피드백을 요청하면서 Grok 4.6이 곧 나온다고 예고했다. 반응은 좋아요 4,390건, 댓글 400건으로 이날 수집된 X 게시물 중 두 번째였다. 사용자 피드백을 공개적으로 모아 다음 버전에 반영하는 방식 자체가 릴리스 주기를 짧게 가져가겠다는 신호로 읽힌다.

영상 생성 모델이 용도별로 갈라지기 시작했다

Threads · openerai_lab, Threads · imhealingmachine, Threads · darkest_alex

영상 생성 모델이 하나의 순위표로 줄 세워지던 단계를 지나고 있다는 관찰이 나왔다. 현재 주목받는 모델로 Hailuo Minimax H3, SeeDance 2.5, FLUX3 세 가지가 꼽혔고, 표현하는 방식이 서로 달라 용도별로 획이 그어지는 느낌이라는 평가가 붙었다. 어떤 모델이 최고냐가 아니라 어떤 작업에 무엇을 쓰느냐로 질문이 바뀌었다는 뜻이다.

실사용 검증은 Seedance 2.5 쪽에서 나왔다. 미드저니로 만들어둔 그림체를 30~40개 넘게 통과시켜본 결과, 예상보다 훨씬 다양한 애니메이션 스타일을 소화했다는 보고다. 창작자가 이미 확보한 이미지 스타일 자산을 그대로 영상으로 옮길 수 있느냐가 실무에서 가장 중요한 기준인데, 이 테스트가 정확히 그 질문을 겨냥한다. 다만 한계도 함께 적혔다. 아직 뭉개짐이 보이고, 해상도 측면에서 1080p와 4k 출시를 기다리는 상태다. 현재 출력 해상도가 상업 납품 기준에 못 미친다는 뜻으로 읽힌다.

이미지 쪽에서는 편집 워크플로에 붙는 기능이 업데이트됐다. 그록의 이미지 자동 세그먼팅이 그것으로, 이미지를 넣으면 알아서 구성 요소를 분해하고 각 조각을 다운로드할 수 있으며 부위별로 재생성하거나 수정할 수도 있다. 생성 결과가 마음에 안 들 때 전체를 다시 뽑는 대신 한 부분만 고치는 방식이라 프롬프트 재시도 비용을 크게 줄인다. 생성 품질 경쟁이 어느 정도 수렴하면서 편집 제어권 쪽으로 경쟁축이 옮겨가는 흐름의 사례다.

Model DNA - 공개 파일만으로 LLM이 정말 밑바닥부터 학습됐는지 검증할 수 있는가

Threads · pytorch.kr, discuss.pytorch.kr

"우리 모델은 밑바닥부터 학습했다"는 주장을 외부인이 검증할 방법이 있는가. Model DNA 접근과 그에 딸린 라이브 도구는 공개된 아티팩트만으로 그 질문에 답해보려는 시도이고, 이 글은 그 방법을 인용해 PyTorch로 재현하면서 신뢰 범위를 따진다.

검증 신호는 세 가지로 정리된다. 첫째는 아키텍처 config다. 레이어 수, 히든 차원, head 구성 같은 설정값이 특정 공개 모델과 얼마나 일치하는지를 본다. 둘째는 토크나이저 겹침이다. 어휘 사전과 병합 규칙은 학습 데이터와 전처리 파이프라인에 강하게 묶이기 때문에, 독립적으로 만들었다면 우연히 겹치기 어렵다. 셋째는 임베딩의 Linear CKA다. CKA(Centered Kernel Alignment)는 서로 다른 두 신경망의 내부 표현이 얼마나 비슷한지를 재는 유사도 척도인데, 차원 수가 달라도 비교할 수 있어 모델 간 표현 비교에 쓰인다. 임베딩 층에 이 척도를 적용해 두 모델의 표현 공간이 같은 뿌리에서 나왔는지를 본다.

세 신호는 성격이 다르다는 점이 중요하다. 아키텍처 config는 베끼기 가장 쉽고 우연 일치도 많다. 토크나이저 겹침은 더 강한 증거지만 공개 토크나이저를 그대로 가져다 쓰는 합법적 선택이 흔하다. 임베딩 CKA가 가장 직접적인 표현 수준 증거에 가깝다. 이 글이 하는 일은 각 신호가 왜 작동하는지를 설명하고, 어디까지 신뢰할 수 있으며 어디서 무너지는지를 구분하는 것이다. 이런 검증이 필요한 이유는 최근 상황이 설명한다. 오픈 웨이트 모델이 쏟아지고, 파인튜닝인지 처음부터 학습한 것인지, 다른 모델을 증류한 것인지에 따라 라이선스와 기술 주장이 완전히 달라지지만, 검증할 수 있는 건 공개된 가중치 파일과 설정 파일뿐이다. 이때 재현 가능한 판정 절차가 있으면 논쟁이 인상 비평에서 측정으로 옮겨간다. 글에 PyTorch 재현 코드가 함께 실려 있어 자기가 쓰는 모델 두 개를 직접 비교해볼 수 있고, 이 절차 자체가 조직 내부의 모델 도입 체크리스트로 들어갈 여지가 있다.

구글 딥마인드가 태풍 예보 모델 WeatherNext를 가중치까지 공개했다

Threads · choi.openai

기상 예측 AI가 논문과 데모를 넘어 가중치 공개 단계로 넘어왔다. 구글 딥마인드가 태풍 예보 AI WeatherNext를 공개하면서 모델 가중치와 코드를 오픈소스로 함께 풀었다. 외부 기관이 자체 환경에서 재현하고 튜닝할 수 있는 형태라는 점이 이번 공개의 성격을 규정한다.

성능 주장은 구체적이다. Nature 논문 기준으로 경로, 강도, 바람 구조를 한 모델이 같이 예측하고, 3일 예보 정확도가 기존 2일 예보 수준에 가깝다. 이 문장을 실무 언어로 옮기면 평균 24시간의 대응 여유가 더 생긴다는 뜻이다. 피난 명령, 물자 이동, 항만과 항공 통제처럼 준비 시간이 곧 피해 규모를 결정하는 의사결정에서 하루는 작은 차이가 아니다.

계산 비용도 낮다. 15일 시나리오를 TPU 한 장에서 1분 안에 만든다. 이 속도를 확률 예보에 쏟아부어, 올해는 태풍 하나당 1,000개의 확률 경로를 돌린다. 단일 최적 경로를 내는 결정론적 예보에서 앙상블 확률 예보로 무게가 옮겨간 것인데, 앙상블을 돌리는 비용이 물리 기반 수치예보 대비 압도적으로 싸다는 점이 이 전환을 가능하게 했다. 실적 사례로는 2025년 허리케인 멜리사가 제시됐다. 자메이카 5등급 상륙을 5일 전에 80% 신뢰도로 먼저 잡았다고 밝혔다. 사후 선택된 단일 사례라는 한계는 있지만 "5일 전"과 "80% 신뢰도"라는 두 숫자가 함께 제시됐다는 점에서 검증 가능한 주장이다.

기술적으로 가장 흥미로운 대목은 해상도 관련이다. 28x28km 격자에서도 강도 예측이 된다. 기존 통념은 태풍의 최대 풍속 같은 강도 지표를 맞히려면 훨씬 촘촘한 입력 해상도가 필요하다는 것이었다. 성긴 격자에서도 강도가 나온다면 입력 데이터 확보가 어려운 지역이나 계산 자원이 제한된 기관에서도 같은 수준의 예보를 돌릴 수 있게 된다. 원 게시자도 마지막에 같은 질문을 던진다. 예측이 하루 앞당겨졌다는 사실보다, 그 하루를 피난과 물자 이동 결정에 얼마나 빨리 연결하느냐가 남은 문제다.

Skills와 도구 생태계

Microsoft Research의 Flint는 에이전트가 차트 설정을 직접 쓰지 않게 만든다

LinkedIn · AI Engineering

에이전트에게 보기 좋은 차트를 시키는 일은 계속 잘 안 되는 축에 속했다. Vega-Lite나 ECharts 설정을 전부 쓰게 하면 장황하고 오류가 잦은 출력이 나오고 사람이 매번 정리해야 한다. 근본 원인은 에이전트가 데이터의 의미를 모른다는 데 있다. 필드가 순위인지 가격인지 온도인지 모르는 상태에서 스케일, 간격, 라벨, 레이아웃을 추측하니 대체로 어긋난다.

Flint는 Microsoft Research가 이 문제에 낸 답이다. 층위를 한 칸 올려서, 에이전트는 저수준 설정이 아니라 컴팩트한 semantic spec만 작성하고 나머지는 Flint 컴파일러가 알아서 결정한다. 프롬프트로 출력 품질을 밀어 올리는 대신, 에이전트가 실수할 수 있는 표면 자체를 줄인 설계다. 핵심은 semantic type이다. Rank, Temperature, Price, Country 같은 타입을 70개 이상 갖춰 컴파일러가 각 필드가 무엇을 뜻하는지 알고 레이아웃을 결정한다. 그 위에서 자동 레이아웃이 붙는다. 데이터 카디널리티와 캔버스 제약에 맞춰 크기, 간격, 라벨, 마크, 범례를 조정한다. 범주가 30개인지 3개인지에 따라 라벨 처리를 바꾸는 판단을 사람이나 에이전트가 아니라 컴파일러가 한다는 뜻이다.

지원 범위도 좁지 않다. scatter, heatmap, treemap, Sankey, radar, boxplot을 포함해 30개 이상의 차트 유형이 들어 있다. 그리고 하나의 spec에서 Vega-Lite, ECharts, Chart.js, Plotly 네 개의 렌더링 백엔드로 나간다. 프런트엔드 스택이 바뀌어도 spec을 다시 쓸 필요가 없다는 이야기라, 사내 표준 차트 레이어를 만드는 팀에게는 이 부분이 가장 직접적인 가치다. 배포 방식도 지금 흐름에 맞춰져 있다. MCP 서버를 제공해 에이전트가 채팅이나 코딩 환경에서 곧바로 차트를 생성하고 검증하고 렌더링할 수 있고, Claude Code와 Cursor용 agent skills도 함께 나온다. 연구 산출물이 논문과 데모가 아니라 MCP 서버와 에이전트 스킬 형태로 배포된다는 점 자체가 지금 도구가 유통되는 방식을 보여주는 사례이기도 하다.

하루 사이 눈에 띈 급상승 오픈소스 레포 묶음

Threads · think.5x, Threads · precision.ligne, Threads · pyjinnode, X · CycleDecoded

하루치 피드에서 star 수와 함께 언급된 레포만 여섯 건이다. 개별로는 짧은 소개글이지만 묶어 놓으면 지금 어떤 종류의 도구에 사람이 몰리는지가 보인다. 코딩 에이전트 주변부, 즉 에이전트가 잘 못하는 일을 대신 잡아주는 도구에 관심이 집중돼 있다.

claude-seo는 가장 가파른 축이다. 하루 만에 star가 101개 붙어 누적 13,706개를 넘겼다. 소개 맥락은 SEO 컨설팅 리포트를 몇 주씩 기다리던 작업을 직접 돌린다는 것이다. 아래 검색 유입 섹션의 SEO 실측 사례와 같은 수요를 다른 방향에서 채우는 도구라, 두 항목을 붙이면 "검색 유입 작업이 에이전트로 내려오고 있다"는 한 흐름이 된다.

Ouroboros(Q00/ouroboros)는 문제 정의가 명확한 쪽이다. AI 코딩 도구가 늘어날수록 실제 병목은 모델 선택이 아니라 불명확한 요구사항과 검증되지 않은 결과라는 진단에서 출발해, 질문과 명세와 실행과 평가와 개선을 하나의 재현 가능한 작업 계약으로 묶으려는 로컬 우선 프로젝트다. 코딩 전에 요구사항을 검증한다는 위치 선정이 특징이라, 앞의 자기개선 루프 논의와 정확히 같은 지점을 건드린다.

google/skills는 공급자 쪽 움직임이다. 구글이 직접 만든 에이전트 스킬 저장소로, Python 기반으로 구글 제품과 기술에 맞춘 스킬을 구축하는 방법을 담았다. 공개 1주일 만에 star 1,600개를 넘겼다. Anthropic이 밀던 Agent Skills 포맷 주변에 다른 대형 벤더의 공식 저장소가 붙기 시작했다는 신호로 읽을 수 있다. multica-ai/multica는 star 44,000개로 규모가 가장 크고, 소개자가 인용한 슬로건은 "이번의 채용은 사람이 아닐 것이다"였다. 코드 그래프 RAG 쪽 소개도 하나 있었다. 코드를 그래프 DB에 통째로 저장해 함수 호출 관계까지 추적하는 도구로, RAG가 벡터 임베딩만 쓰던 단계를 지나고 있다는 맥락에서 제시됐다. 코드베이스 검색에서 호출 그래프가 벡터 유사도보다 정확한 신호라는 주장은 실제 사내 도구를 만드는 팀에 바로 적용 가능한 방향이다.

마지막으로 Logocreator는 생성형 도구 쪽이다. Vercel 소속으로 알려진 개발자 Nutlope가 만든 오픈소스 AI 로고 생성기로, Together AI의 FLUX 모델을 쓰고 GitHub star 7.6k 이상, MIT 라이선스다. 중국어권에서 "디자인 회사가 수천 위안 받던 로고 비용을 오픈소스가 대체했다"는 프레임으로 확산됐다. 국내에서는 "클로드로 개발하는 분들을 위한 깃허브 급상승 도구 Top 10" 형태의 큐레이션 게시물이 별도로 돌았다.

Defuddle 다운로드 급증이 가리키는 것

Threads · kepano

Obsidian의 kepano가 자신이 만든 오픈소스 html -> markdown 라이브러리 Defuddle의 다운로드가 지난 한 달 사이 갑자기 크게 늘었다고 알렸다. 본문은 한 문장이지만, 무엇이 늘었는지가 아니라 왜 늘었는지가 이 항목의 관전 포인트다. 게시물 자체는 짧아도 반응은 좋아요 171건으로 이날 Threads 개발 계정 중 상위권이었다.

Defuddle은 웹 페이지 HTML에서 광고, 내비게이션, 사이드바 같은 껍데기를 걷어내고 본문만 마크다운으로 뽑아내는 라이브러리다. 원래는 Obsidian Web Clipper 계열의 스크랩 용도로 알려졌는데, 최근 수요 증가는 사람이 읽으려고 스크랩하는 용도만으로는 설명하기 어렵다. 같은 기간 에이전트가 웹을 읽어 컨텍스트로 넣는 파이프라인이 폭발적으로 늘었고, 그 앞단에서 HTML을 깨끗한 마크다운으로 바꾸는 단계가 사실상 필수가 됐다. LLM 입력 토큰을 줄이면서 본문 손실을 막는 문제라, 정확도 좋은 추출기의 수요는 에이전트 사용량에 비례해 늘어난다. 본인이 원인을 단정하지 않았다는 점은 명시해 둔다.

이 관찰을 앞의 "에이전트 트래픽이 인간 트래픽을 넘어선다"는 주장과 나란히 놓으면 근거 하나가 붙는 셈이다. 사람이 늘어난 게 아니라 사람 대신 페이지를 읽는 프로그램이 늘었고, 그 결과가 특정 라이브러리 다운로드 그래프에서 먼저 보인다. 실무적으로는 도입 판단에 쓸 만한 신호다. 본문 추출을 자체 정규식이나 readability 계열 구현으로 버티던 팀이라면, 사용자가 급증하면서 유지보수와 엣지 케이스 대응이 활발해진 라이브러리로 옮길 타이밍이라는 근거가 된다.

에이전트 스킬과 AI 기초를 무료로 배우는 경로가 늘고 있다

Threads · ohyoung.park, LinkedIn · Matt Palmer, LinkedIn · Drone ., X · indie_maker_fox

기초와 응용 양쪽에서 무료 학습 경로가 하나씩 정리됐다.

기초 쪽은 awesome-free-ai-course-notes다. 교수, 강의, 학과가 직접 공개한 AI와 머신러닝 강의노트를 모은 색인인데 수록 기준이 까다로워서 쓸모가 있다. 슬라이드나 영상만 있는 자료는 제외하고 교과서의 한 장처럼 읽을 수 있는 서술형 노트만 받는다. 그리고 로그인, 기관 이메일, 유료 결제 없이 접근 가능해야 한다는 조건이 붙는다. 실제로 열어보면 페이월이나 학내 계정에 막히는 흔한 문제를 사전에 거른 셈이다. 수록 강의는 MIT 6.390, Harvard CS181, Princeton COS 324, Stanford CS229, UC Berkeley CS189/289A, Caltech CS156, Cornell CS4780이고 Oxford, LMU Munich, KAIST, USP 자료도 포함돼 있다.

응용 쪽은 Agent Skills 코스다. Matt Palmer가 LinkedIn Learning에 올렸고, Cursor에 합류하기 전에 스킬에 대해 아는 것을 정리했다고 밝혔다. 다루는 범위가 구체적이다. 스킬이 코딩 에이전트와 실제로 어떻게 작동하는지, 스킬을 평가하고 직접 작성하는 프레임워크, npx skills 라이브러리와 skills.sh 사용법, 그리고 자기 스킬 컬렉션을 관리하고 팀과 공유하는 템플릿까지다. 특정 제공자에 묶이지 않아 모든 에이전트에서 통한다는 점을 강조했고, 코딩 에이전트가 계속 바뀌어도 남는 기초부터 시작한다고 설명했다.

이 두 건은 같은 날의 다른 항목과 정확히 맞물린다. 구글이 google/skills 저장소를 내고, Microsoft Research가 Claude Code와 Cursor용 agent skills를 배포하고, Cursor로 옮기는 사람이 스킬 강의를 내놓는 흐름이다. 스킬이 특정 벤더 기능에서 공통 포맷으로 굳어지는 중이라는 신호로 읽을 수 있다. 부수적으로 디자인 레퍼런스 허브 하나도 소개됐다. Design Daily Curation은 웹, UI, 브랜딩, 앱, 디자인 도구를 큐레이션하면서 AI Agent Skill과 채용 정보까지 함께 묶는다. OG Image, App Screenshot, App Icon 레퍼런스가 포함돼 웹사이트 갤러리보다 범위가 넓고, 생성 기능이 아니라 사람이 선별한 레퍼런스라는 점을 특징으로 내세운다. 중국어권에서는 극단적으로 단순한 설계와 넓은 확장성을 이유로 Pi Agent 전자책이 추천됐다.

AI 산출물의 정확성과 책임

AI로 만든 앱이 원작의 버그까지 복제했다 - Dark Hours 사건과 24년 만의 첫 철회

GeekNews · Terry Godier mea culpa, GeekNews · Daring Fireball 철회문

이 사건은 두 개의 다른 실패가 하루 안에 겹쳐 일어났고, 둘 다 개별적으로 기록할 가치가 있다.

첫 번째 실패는 AI 생성물의 출처 확인 부재다. Terry Godier가 지난주 Dark Hours라는 이름의 웹 유틸리티를 공개했다. 그날 밤 하늘에서 무엇을 볼 수 있는지 알려주는 도구다. 다음 날 DarkHours.app을 만든 개발자 Miguel Beher가 Bluesky에서 Godier의 코멘트에 답글을 달아 이름을 포함해 두 프로젝트가 얼마나 비슷한지를 보여줬다. Godier는 처음에 기능 세트를 크게 차별화하고 이름을 바꾸고 원작을 소개하는 블로그 글을 쓰겠다고 답했다.

약 한 시간 뒤 상황이 달라졌다. Claude로 만든 웹앱이 원작 오픈소스 프로젝트와 놀랍도록 유사할 뿐 아니라, 원작자가 나중에 고친 버그까지 재현하고 있다는 것이 분명해졌다. 구체적으로는 사용자를 "멕시코의 무작위 들판"으로 보내는 위치 이동 버그였다. 이 시점에서 Godier가 할 수 있는 일은 도메인 darkhours.io를 원작자의 darkhours.app으로 직접 리디렉션하고 iOS 앱 출시 계획을 접는 것뿐이었다.

Godier가 쓴 사과문의 문장이 이 항목의 핵심이다. DarkHours.app을 전날까지 본 적이 없다는 것은 진심이지만, 결과물이 기존 프로젝트와 얼마나 닮았는지 확인하는 작업 없이 AI에 의존해 프로젝트를 생성한 것은 부주의했고, 그건 자기 책임이며 자신이 공개한 것에 대한 책임은 자신에게 있다는 것이다. 그는 자기 행동을 "무책임한 AI 사용"이라고 규정했다. 후속 조치로는 앞으로 AI로 웹 프로젝트 전체를 만들지 않겠다, iOS 개발에서는 질문하고 디버깅 도움을 받되 Claude로 앱을 생성하지는 않겠다고 선언했다.

두 번째 실패는 검증 없는 인용이다. John Gruber는 전날 "App Store Rejection of the Week: Dark Hours"를 게시했다가 전면 철회했다. Daring Fireball을 운영한 24년 동안 처음 철회한 글이다. 경위는 이렇다. Godier는 원래 게시글에서 "일반인을 위한 천문학 웹사이트 Dark Hours의 iOS 앱을 제출했는데 점성술이라는 이유로 거절됐다. 타로 기능도, 별자리 운세도, 나나 내가 물어본 누구도 점성술과 연결할 만한 것이 아무것도 없다"고 썼다. Gruber는 이 전제 위에 글 전체를 세웠다. 실제로는 App Store에 1월에 제출된 앱의 이름은 "Asterly"였고, 천문학이 아니라 점성술에 전적으로 초점을 맞춰 "오늘의 타로 카드"를 포함한 오컬트 기능을 담고 있었다. 4월에 App Review Board가 거절을 유지했을 때도 이름은 Asterly였다. Apple은 "Dark Hours"라는 이름의 Godier 앱을 심사한 적이 없으므로 Gruber의 글은 제목부터 사실과 달랐다.

Gruber는 오컬트 콘텐츠를 제거하고 Dark Hours 웹사이트의 과학적 천문학 기능만 담은 Asterly 빌드가 실제로 제출됐는지 알 수 없으며 제출됐다고 믿을 근거도 없다고 적었다. 그가 왜 속았는지 스스로 분석한 부분이 뼈아프다. 점성술에 대한 자신의 혐오가 워낙 크고 Godier의 이전 작업(RSS 리더 디자인 인터랙티브 에세이 "Phantom Obligation", 그 아이디어를 구현한 RSS 리더 Current, "The Last Quiet Thing", App Store 별 5개 리뷰 시스템 글)에 대한 평가가 워낙 높아서, 그가 실제로 점성술 앱을 만들어 제출했을 가능성 자체를 떠올리지 못했다는 것이다. Gruber는 게시 전 초안을 Godier에게 보내 사실관계를 확인했지만 Godier는 아무 주의도 주지 않고 관심을 가져줘서 고맙다는 반응만 보였다.

철회 방식도 기록할 만하다. 원문을 지우지 않고 투명성과 책임을 위해 plain text(Markdown)와 원래 형식을 보존한 PDF 두 버전으로 공개했으며, 두 버전 상단에 철회문으로 가는 링크가 담긴 서문을 붙였고 기존 URL은 철회문으로 리디렉션된다. 부수적으로 App Store 정책 사실 하나가 정리된다. Apple은 점성술이나 오컬트 앱을 전면 금지하지 않으며 App Store에 그런 앱이 많고 "Best Astrology Apps" 편집 기획을 운영한 적도 있다. 근거 조항은 Review Guidelines 4.3(b)로, 데이팅, 손전등, 음향 효과, 배경화면, 단순 타이머, 운세 앱을 이미 충분히 확립된 유형으로 분류하고 의미 있게 차별화되거나 개선된 경험을 제공하지 않는 신규 제출은 받지 않을 수 있다고 규정한다.

Godier 쪽 교훈은 AI가 만든 결과물이 기존 저작물과 얼마나 닮았는지는 게시자가 직접 확인해야 한다는 것이고, 버그까지 복제됐다는 사실은 이것이 우연한 유사성이 아님을 강하게 시사한다. Gruber 쪽 교훈은 당사자 확인이 사실 검증이 아니라는 것이다. 초안을 당사자에게 보내 확인받았는데도 틀렸다.

LLM에게 설명을 시키지 말고 시뮬레이션을 만들게 하라 - ChipTycoon 학습법과 그 반박

Hacker News · laurentiugabriel.github.io, ChipTycoon

이날 HN 점수가 가장 높은 글(324점)이고, 동시에 토론이 가장 날카롭게 갈린 글이다.

저자의 문제 제기는 단순하다. 많은 엔지니어가 PoC나 내부 도구, 대시보드를 만드는 데, 심지어 새로운 것을 배우는 데도 생성형 AI를 쓰는데 LLM이 설명하는 스타일이 따라가기 어렵다는 것이다. 너무 단순하고, 이모지 개수에 따라 짜증나기까지 한다. 그래서 만든 흐름은 4단계다. 첫째, Claude Code나 OpenCode의 plan mode에서 그 주제의 기초 지식을 구축하게 한다. 둘째, 자기가 만든 지식 기반의 정확성을 다시 검토하게 한다. 셋째, 그것을 저해상도 폴리곤에 RollerCoaster Tycoon 스타일 애니메이션 시뮬레이션으로 구현하게 하되, 대형과 소형 화면 모두에서 보여야 하고 원할 때 흐름을 멈출 수 있는 컨트롤이 있어야 한다는 UX 요소도 함께 지정한다. 넷째, 새 저장소에 푸시하고 GitHub Pages를 켠다.

결과물이 ChipTycoon이다. 모래가 채취되는 순간부터 칩이 완성돼 데이터센터로 배송되는 순간까지 카트를 따라간다. 카트가 어떻게 변하는지 시각적으로 볼 수 있고, 저해상도라 세부는 빠지지만 제품이 여러 제조 단계를 거치며 어떻게 변하는지는 드러난다. 시작 동기는 데이터센터 증설을 늦출 수 있는 새로운 AI 병목을 분석하다가 칩 생산에 대해 모르는 것이 많다는 사실을 발견한 것이었다. 개선 방향으로 저자는 두 가지를 제시한다. 석영 모래 더미가 용광로를 지난 뒤 모습을 더 사실적으로 만들려면 사진을 3D 객체로 변환하는 자기 skill로 만든 객체를 시뮬레이션에 매핑하면 되고, 이전 공정 단계에 관한 질문과 직관적 퍼즐을 넣으면 학습 내용 유지에 크게 도움이 된다는 것이다. 같은 방식으로 만든 페이지가 넷 더 있다. 로켓 엔진, LLM 작동 원리(token-town), F1 엔진, EUV 장비다.

여기서 그대로 옮기면 안 되는 문장이 하나 있다. 저자는 결과물이 "100% 정확하고 환각이 없다"고 단언한다. HN 토론의 절반이 정확히 이 지점을 친다. IshKebab의 반박이 가장 정면이다. "처음 배우는 거라면 그걸 어떻게 아나. LLM으로 배우는 건 매우 위험하다. 나도 해봤지만 정신을 바짝 차려야 한다. '아 물론 당신 말이 맞습니다, 방금 제가 말한 건 완전히 틀렸습니다' 같은 게 수시로 나온다." 검증 능력이 없는 초심자일수록 이 방식의 위험이 크다는 것이고, 저자의 "100% 정확" 주장이 성립하려면 저자가 이미 그 주제를 알아야 한다는 자기모순이 있다.

결과물 자체의 품질을 지적한 사람들도 있다. 도구는 좋지만 단계를 클릭해 보면 텍스트 품질이 전혀 높지 않고, 툭툭 끊기는 제목과 축약된 설명이라 복잡한 내용을 다루기엔 실제 본문에 몇 번의 반복과 사고가 더 필요했다는 것이다. dwa3592는 더 근본적으로 "이 애니메이션들이 놀고 있는 층위가 사실은 그 주제의 복잡성을 감추고 있다"고 했다. dcreater는 "YouTube에 칩 생산에 관한 정말 훌륭한 영상이 많다. 접근은 존경하지만, 이미 무료로 준비된 고품질 자료가 있는데도 모든 것에 AI를 집는 국면에 많은 사람이 있는 것 같다"고 적었다. 이에 대한 두 반박도 볼 만하다. AlotOfReading은 "널리 공개된 정보만으로 칩 생산을 정말 배울 수 있는지 모르겠다. 세부가 더 큰 전략을 좌우하는 극도로 복잡한 산업이다. 예를 들어 주변부 트랜지스터용 메모리 공정의 트레이드오프를 어느 정도 알지 못하면 Micron과 TSMC의 관계를 제대로 이해할 수 없다"고 했고, tayo42는 "YouTube는 그냥 정보 덤프다. 구조화된 학습 방식에 상호작용이 더해지면 배우는 데 도움이 된다"고 했다.

실제로 재사용 가능한 대안도 여럿 나왔다. lacedeconstruct는 LLM으로 배우는 최선이 예제를 하나 생성해 대략의 멘탈 모델을 잡은 다음 전통적인 문서와 자료로 이해를 그라운딩하는 것이라고 제시했고, 대학 시절 교과서 문제를 먼저 읽어 무엇이 중요한지 파악한 뒤 챕터를 읽던 기법의 변형이라고 덧붙였다. rickcarlino는 관심 있는 RFC와 스펙을 읽기 쉽게 재작성하는 데 LLM을 쓰고 있으며 구현에 쓸 만큼 정밀하지는 않지만 원 RFC 이해도를 높였다고 했고, Codex에게 Kademlia DHT나 BitTorrent 클라이언트 같은 복잡한 것을 문학적 스타일로 구현하게 해서 소스 코드를 읽으며 이해를 높이는 방식도 유용했다고 했다. spacedcowboy는 "LLM에게 주제에 대한 퀴즈를 내달라고 하고 답을 함께 토론하는 것이 놀랍도록 효과적"이라고 했고, chasd00은 회계연도 종료 전에 통과해야 하는 사내 평가를 위해 슬라이드 80장짜리 PPT 10개, 약 800장을 AI에 읽히고 중간중간 퀴즈가 들어간 학습 가이드를 만들게 해서 100페이지 워드 문서로 대체했으며 매우 잘 작동했다고 적었다.

부수적으로 제목 관련 메타 정보가 있다. 원 제목은 "How I use LLMs to learn..."이었는데 HN이 "How"를 떼어냈고, 저자가 자기 오타인 줄 알고 글을 지웠다가 다시 올렸는데 같은 동작을 다시 만났다고 한다. 이 때문에 제목이 글 내용을 대표하지 못한다는 지적이 나왔다. 실제 내용은 "LLM으로 배운다"가 아니라 "에이전트에게 문제 영역을 설명하고 간단한 웹 시뮬레이션 게임을 구현하게 한 뒤, 그 게임을 플레이하며 배운다"이다.

AI 문체 탐지가 커뮤니티 기본 반응이 된 날 - Phrack 40주년 선언문

Hacker News · Phrack

내용 자체보다 반응이 이 항목의 본체다. 글은 1986년 The Hacker's Manifesto 40주년을 맞아 Phrack에 실린 재작성 선언문이다. Loyd Blankenship("The Mentor")을 기리며 "호기심 많은 자 중 한 명, 여전히 연결된 채"라고 서명돼 있다. 구조는 일관되게 "그때 vs 지금"이다.

그때는 깜빡이는 커서를 장벽이 아니라 초대장으로 봤고, 허공에 문자를 넣으면 비밀이 돌아왔으며, 목표는 파괴가 아니라 이해였다. 만든 사람보다 시스템을 더 잘 이해하는 것. 지금은 해킹이 직함이다. 호기심이 상품화됐고 수천 개의 버그 바운티 플랫폼이 이해하려는 욕구를 CVE와 티셔츠로 환금하려 한다. CTF는 이력서용 연습이 됐고 리버스 엔지니어는 회사 배지를 달았으며, 익스플로잇은 커뮤니티에 공개적으로 개발되는 대신 정부 직원이 만들어 엠바고에 걸린다. 가장 인용할 만한 대비는 이것이다. 예전에는 기계가 원하는 대로 하지 않으면 열었고, 셸코드를 손으로 썼고, opcode 차트를 음악가가 악보 쓰듯 썼으며, 스택을 소유했다. 지금은 스택이 우리를 소유한다. 남의 인프라 위 컨테이너 안에서 불투명한 blob을 돌린다. "sudo가 어떻게 작동하는지 설명하는 40개짜리 트윗 스레드를 스크롤해 지나간다"와 "인플루언서와 해커가 같은 명함을 쓴다"도 같은 축이다.

남은 정신이 사는 곳으로 네 곳을 꼽는다. 자기 메일서버를 조용히 돌리는 시스어드민, 80년대 계산기에 WiFi 모듈을 납땜하는 학생, 브랜드 캠페인 없이 PoC를 발표하는 연구자, 안을 보려고 폐쇄형 하드웨어를 포크하는 집단. 다음 세대에게는 게이트키핑하지 않되 셋을 경고한다. 인증서를 역량으로 착각하지 말 것, 플랫폼을 커뮤니티와 혼동하지 말 것, "책임 있는 공개"가 호기심을 갖기 위해 허락을 구하는 것을 뜻한다고 받아들이지 말 것.

그리고 HN의 반응은 대부분 "이거 ChatGPT가 썼잖아"였다. analognoise가 첫 코멘트로 "ChatGPT처럼 들린다"고 했고, hugodan은 연습 문제를 냈다. "원본에는 없고 이 새 글에는 잔뜩 있는 문자 하나를 찾아보라." em dash를 가리킨 것이다. gre는 "그래서 내가 읽을 수가 없는 건가. LLM 출력을 너무 많이 읽어서 이제 스킴만 된다"고 했다. 반박도 있었다. stackghost는 "일부는 LLM 이전부터 습관적으로 em dash를 썼다"고 했고, bawolff는 더 정확하게 "원본 Phrack은 7비트 ASCII였을 테니 ASCII가 아닌 문자를 안 쓴 게 당연하다"고 지적했다. juleiie는 "그건 중요하지 않다. 중요한 건 내용이지 만드는 방법이 아니다"라고 못 박았다. 내용 비판도 있었는데 오히려 반박당했다. ramon156는 "80년대 계산기에 WiFi 모듈 납땜"이 만화에서 영감받은 프로젝트처럼 들린다며 실제 통화를 스푸핑해 무료로 전화를 걸던 것 같은 사례를 왜 안 드느냐고 했는데, inigyou의 답이 정확했다. "hacker라는 단어는 회로기판을 실톱(hacksaw)으로 잘라 조각들을 다르게 연결하던 MIT 학생들에게서 왔다. 계산기에 WiFi 모듈을 납땜하는 건 아주 올드스쿨 해커다. 당신이 찾는 단어는 phreaking이고, 이 글이 실린 사이트 제목과 두 글자밖에 차이가 안 나는데 잊었다는 게 웃긴다." AuthAuth는 윤리적으로 선을 그었다. "WiFi 계산기 같은 프로젝트를 해킹하는 건 재미있고 무해하며 지식을 쌓는다. 전화선을 해킹하면 아이가 감옥에 갈 수 있다. 공공 인프라를 공격하는 건 가볍게 다룰 일이 아니다."

이 항목을 남기는 이유는 AI 문체 탐지가 커뮤니티의 기본 반응이 됐다는 것 자체가 오늘을 관통하는 주제이기 때문이다. 아래 보안 섹션의 Windows GDID 제거 도구 README도 같은 취급을 받아 "advanced technical claudish"라는 신조어를 낳았고, 아래 미디어 섹션의 뉴질랜드 음악 글도 "AI 슬롭은 안 읽겠다"는 지적을 받았다. 세 경우 모두 "그래서 내용이 틀렸나"에 대한 답은 나오지 않았다. Phrack 스레드에서 글의 내용 자체에 반응한 코멘트는 "이 글이 공감된다. 몇 년간 선반에 있던 오래된 flip-dot 디스플레이를 다시 만지기 시작했다"는 한 줄이 유일했다.

AI가 제도에 가하는 압력

AI 법률 조언이 만든 고용심판 폭증 - "tragedy of the commons, AI edition"

Hacker News · The Economist, 아카이브

기사 본문은 페이월이라 인용으로만 확인되지만, 인용된 두 문단이 논지를 충분히 담고 있다.

기사의 핵심 주장은 무료 AI 기반 법률 조언이 노동자에게 좋은 소식이어야 하는데 오히려 공유지의 비극이 되고 있다는 것이다. 진짜 고충이 있는 노동자에게는 수요 급증이 정의 실현까지의 대기 시간을 늘리고, 고용주에게는 근거 있는 청구와 황당한 청구 양쪽 모두에 대응하는 더 큰 법률 비용을 뜻한다. AI 시대에 정의 접근을 위해 만든 제도가 접근이 너무 많아 고통받는다는 문장으로 끝난다.

그런데 기사 결말은 방향이 다르다. AI가 약속을 실현하면 머지않아 모든 노동자에게 주머니 속 최고급 변호사를 주어 상사를 상대로 정밀하게 구성된 소송을 마음대로 제기하게 할 수 있고, 슬롭 청구의 홍수가 이기는 청구의 물결로 바뀔 수 있다는 것이다. 영국 노동당이 자기 고용법안을 두고 고용주에서 노동자로 권력을 옮긴다고 했는데, AI로 그 권력 이동이 정치인들이 상상한 것보다 빠르고 멀리 갈 것이라는 문장으로 닫는다. "The Economist가 우려하는 법적 경향이 노동자가 자기 권리를 주장하는 것이라는 점이 시사적"이라는 비꼼에 대한 답이 이 인용이었다.

HN 토론의 절반은 제목의 "tragedy of the commons"라는 프레임 자체를 문제 삼았다. underlipton은 이 개념이 이미 반증됐다고 주장하며 Ostrom과 동료들이 찾은 성공 시스템의 특징을 인용했다. 명확한 경계(관리하는 공동체가 잘 정의돼야 함), 공유 자원의 신뢰할 만한 모니터링, 참여자에게 합리적인 비용 대비 편익 균형, 갈등의 빠르고 공정한 해결을 위한 예측 가능한 절차, 부정행위자에 대한 단계적 처벌, 그리고 가구주부터 국제기구까지 다른 권위 층위와의 좋은 관계다. jmyeet는 더 강한 버전으로, 1968년 에세이에서 나온 이 용어가 서구 여러 나라에서 공공 서비스 민영화의 논거로 인기를 끌었지만 현실과 맞지 않았고 Ostrom이 2009년 노벨 경제학상을 받으며 공식적으로 반증했다고 주장했다.

여기에 대한 재반박이 더 정확하다. Eueudhsbsj32는 "Ostrom은 지역 지식에 기반한 효과적 규제가 있으면 공유 자원을 성공적으로 관리할 수 있다고 말한 것 아닌가. 공유지의 비극은 자원 사용을 규율하는 효과적 규칙이 없고 개인이 자기 이익대로 행동할 자유가 있을 때 벌어지는 일"이라고 정리했다. rfv6723는 "Ostrom은 반증하지 않았고, 안정적 공동체와 명확한 경계, 반복 상호작용, 모니터링, 무임승차자에 대한 실질 제재가 있으면 피할 수 있음을 보였다. 문제는 이동성이 높고 익명적인 현대 사회에서 그 조건들을 유지하기가 훨씬 어렵다는 것"이라고 했다. diogocp는 한 줄로 "공유지의 비극은 실패한 시스템에서 일어나는 일"이라고 요약했다. TeMPOraL은 반대로 자신은 이 용어를 늘 민영화의 결함을 가리키는 데 쓰는 것으로 알아왔다며 "공유지의 비극의 해법은 문자 그대로 중앙 권위이고 민영화의 동력과는 정반대"라고 적어 이 용어가 정치적으로 양쪽에서 쓰여왔음을 드러냈다.

실무적으로 남길 만한 제안이 둘 있다. jay_kyburz는 무가치한 제소를 억제할 금전적 장치를 제안했다. 제소했다가 지면 소액 벌금을 물리고 그 돈으로 법원 재정과 방어에 쓴 고용주의 시간을 보전하되, 판사나 치안판사가 온정적 사유로 면제할 수 있게 하자는 것이다. majormajor는 더 구조적인 대안으로, 각 당사자가 변호사를 세워 가능한 한 극단적인 주장을 펼치는 대심 구조에서 전문 중재인과 독립 법원 사실조사관 쪽으로 옮기면 "서류와 신청으로 상대를 파묻는" 변호사 비용 폭발을 피할 수 있다고 했다. 반대편 관점도 있다. dozerly는 "단순 분쟁 해결에 몇 년이 걸리지 않는, 더 잘 확장되는 법 제도가 필요할지도 모른다. AI가 변호사를 대체할 수 있다고는 생각하지 않지만, 극도로 비싼 수임료 없이 더 많은 사람이 법에 접근하는 건 좋게 들린다"고 했고, MichaelZuo는 "변호사는 AI 출력에서 있을 수 있는 실수를 분석하는 데 상당한 시간을 쓰지 않고서는 책임 리스크를 지고 사인하지 않을 것이므로 구조적으로 비용이 크게 줄 수 없다"고 반박했다. newyankee는 다른 각도를 제시했다. 프론티어 모델로 인도 세법에서 자기모순되는 지점을 아주 많이 발견했고, 고도로 주관적인 해석을 통한 공무원의 재량 권력을 줄이는 데 좋은 AI가 도움이 된다면 환영한다는 것이다. 이 권력 비대칭이 개발도상국 부패의 주된 동력이라는 관찰이 따라붙는다.

AI가 아낀 시간은 누구 것인가 - 64%가 일부러 속도를 늦춘 적 있다

LinkedIn · SungKwan L., LinkedIn · 지도현, LinkedIn · Heeseong Kim

AI 도입의 성과가 어디로 흘러가는지를 정면으로 문제 삼은 글이 이날 국내 LinkedIn에서 가장 날카로운 축이었다. 시작은 한 문장짜리 경험담이다. AI로 두 시간 걸릴 일을 한 시간에 끝내고 보고했더니, 돌아온 것은 새로운 업무였다. AI 생산성의 과실은 회사가 가져가고 직원에게 돌아온 보상은 더 많은 일이었다는 정리다.

근거로 제시된 수치는 미국 정규직 근로자 1,003명 조사다. 응답자의 64%가 일을 빨리 끝내면 기대 업무가 늘어날 것을 우려해 일부러 속도를 늦춘 경험이 있다고 답했다. 게시자는 이 조사가 AI와의 직접적 인과를 입증한 수치는 아니라고 스스로 단서를 달았다. 다만 잘못된 보상 구조가 어떤 행동을 유도하는지는 보여준다는 것이다. 논지는 여기서 갈린다. AI 도입은 기술 문제지만, AI가 만든 시간을 어디로 돌릴지는 조직 정책 문제라는 것이다. 평가와 보상 체계가 그대로인 상태에서 생산성만 오르면 직원은 성과를 공개할수록 손해를 보고 결국 성과를 숨기게 된다. 글이 던진 질문도 구체적이다. 일을 빨리 끝낸 직원에게 일을 더 주는 것은 공정한 성과관리인가 유능한 직원을 처벌하는 제도인가. AI가 하루 두 시간을 아꼈다면 추가 업무, 성과보상, 학습시간, 조기퇴근 중 어디로 돌려야 하는가.

같은 날 올라온 AX 회고는 그 정책 문제를 측정 지표 쪽에서 다뤘다. 핵심 주장은 AX의 목적이 AI 사용량을 늘리는 것이 아니라는 것이다. 기존 업무를 더 잘하고 이전에는 하지 못했던 일까지 가능하게 만드는 것이 목적이므로, 봐야 할 지표도 토큰 사용량이 아니라 리드타임, 재작업, 처리량처럼 원래 그 팀이 중요하게 보던 것들이다. 도입 성과를 사용량으로 보고하는 흔한 관행을 정면으로 부정한다. 전제 조건도 구체적이다. 좋은 도구를 지급하고 교육한다고 조직이 바로 달라지지 않는다. 실험할 시간과 비용, 보안 기준, 리더십의 신호, 실패를 공유할 수 있는 분위기가 함께 마련돼야 변화가 시작된다. 외부 전문가의 역할도 재정의된다. 완성된 답을 대신 만들어주는 것이 아니라, 실제 업무를 함께 쪼개고 짝 작업으로 도구를 만들며 구성원이 다음 문제를 스스로 풀 수 있다는 감각을 남기는 것이다. 시작점은 거창한 전략이 아니라 작은 실험이다. 실제 업무 문제 하나를 고르고, 기간과 범위를 제한하고, 기존 지표의 전후를 측정한 뒤 배운 것을 공유한다.

세 번째 글은 개인 역량 쪽에서 같은 축을 짚는다. 인프랩 CTO 이동욱의 학교 강연 정리인데, AI 시대 파트가 핵심이다. 기업용 플랜에서는 같은 결과물을 더 적은 토큰으로 뽑아내는 사람이 유능한 인재로 평가받는다. 예전에는 빨리 만드는 사람이 유능했다면 이제는 적은 자원으로 같은 결과를 내는 사람이 유능하다는 것이다. 그리고 그러기 위해서는 결국 소프트웨어 엔지니어링을 잘하는 사람이 AI도 잘 쓴다는 결론으로 이어진다. 토큰 효율을 개인 평가 기준으로 명시했다는 점에서, 앞의 두 글이 말한 조직 지표 문제와 정확히 맞물린다. 같은 강연에서 나온 또 하나의 메시지는 조급함에 대한 것이다. Loop나 Harness Engineering 같은 새 용어를 전부 쫓아갈 필요는 없고, First 펭귄이 아니라 Second 펭귄, 즉 가장 먼저 뛰어드는 사람이 아니라 뒤처지지 않고 따라갈 수 있는 위치면 충분하다는 조언이다. 앞서 하네스 엔지니어링을 직접 파고든 글이 같은 날 나온 것과 나란히 놓으면, 같은 용어를 두고 "직접 만들어라"와 "다 쫓지 마라"와 "잘 만든 툴에 팀 규칙만 얹어라"가 하루에 부딪힌 셈이다.

계약서 제목이 아니라 실질이 근로자를 정한다 - 초기 회사가 먼저 봐야 할 두 가지

LinkedIn · 추다은

프리랜서 계약 분쟁을 여러 건 처리한 변호사가 공통점을 정리한 글이다. 시작 문장이 관점을 요약한다. 사고는 나쁜 사람이 아니라 바쁜 사람에게서 난다. 실제로 문제가 된 계약들에서 나쁜 의도로 그렇게 계약한 대표는 한 명도 없었고, 전부 사람이 당장 필요한데 채용 절차를 밟을 시간이 없어 외주로 시작했다가 일이 잘 굴러가니 계약 형태를 다시 볼 이유가 없었던 경우였다.

법적 판단 기준은 명확하다. 법은 계약서 제목을 보지 않는다. 슬랙에 상주하고, 데일리 스크럼에 들어오고, 회사 노트북으로 일했다면 그 사람은 근로자다. 계약서에 프리랜서라고 썼는지 용역이라고 썼는지는 판단을 바꾸지 못한다. 실무적으로는 상시 소통 채널 참여, 정기 회의 출석, 회사 자산 사용이 그대로 근로자성 판단 요소로 쌓인다는 뜻이다. AI 도구 도입으로 외부 인력과 짧게 붙었다 떨어지는 협업이 늘어나는 상황에서 반복되기 쉬운 구조다.

글의 태도가 다른 법무 조언과 갈리는 지점은 여기서부터다. 작성자는 초기 회사에서 법무가 뒤로 밀리는 것을 게으름이 아니라 정직한 우선순위라고 인정한다. 매출이 없으면 계약서도 의미가 없기 때문이다. 본인도 서비스를 운영하며 외부 인력과 일해봤고, 계약서를 정리해야 한다는 걸 몰라서 안 한 게 아니라 그걸 하려고 앉으면 오늘 나가야 할 일이 밀렸다고 적었다. 그래서 "미리 다 정비하세요"라고 말하지 않는다. 대신 되돌릴 수 없는 것부터 보라고 한다. 지분, 그리고 사람이다. 이 둘은 나중에 고치는 비용이 처음 만드는 비용의 수십 배가 된다. 나머지는 사고가 난 뒤에 고쳐도 늦지 않다. 바쁜 게 잘못이 아니라, 바쁠수록 되돌릴 수 있는 것과 없는 것을 구분해두라는 결론이다. 체크리스트를 늘리는 대신 두 항목으로 줄였다는 점에서 실제로 실행될 가능성이 높은 조언이다.

보안과 감시

전 NSA 국장 "상수도 제어기를 인터넷에 연결하지 마라" - 5만 개 수도 사업체라는 공격면

GeekNews · The Register

이 항목이 남을 가치가 있는 이유는 발언자의 위치와 숫자의 구체성 때문이다. 전직 NSA 국장 Paul Nakasone가 DEF CON에서 공개적으로 "더 높은 기준이 필요하다. 이 PLC들은 인터넷에 연결되면 안 된다"고 말하는 것은, 이 문제가 기술 권고 단계를 지나 정책 압박 단계로 넘어갔다는 신호다.

사실관계는 이렇다. 최소 12개 주의 상수도 시스템이 해킹당했고 유력 배후는 이란으로 지목된다. 2026년 7월 말 FBI는 PLC(programmable logic controller)를 포함한 운영기술(OT) 장비를 노린 공격을 수사 중이라고 밝혔다. PLC는 탱크 수위 같은 센서 데이터를 감시하고 펌프를 켜고 끄는 장치이고, 이란 연계 조직은 수년간 이 장비들을 표적으로 삼아왔다. 민간 보안 연구자들도 최근 수도와 하수 시설을 교란한 공격의 배후로 이란 침입자를 의심한다. Halcyon Ransomware Research Center의 SVP Cynthia Kaiser는 DEF CON에서 "이란이 아니면 놀랄 일이다. 거의 확실히 이란"이라고 말했다. 다만 FBI도 Trump 행정부의 누구도 공식적으로 이란을 지목하지는 않았다. Nakasone는 당국이 귀속(attribution)에 신중한 접근을 취하는 것으로 본다고 하면서도, 앞선 이란의 수도 시설 PLC 공격 이력을 근거로 "능력은 분명히 있고, 의도도 있다. 우리는 이란과 충돌 중"이라고 덧붙였다.

이 사안의 규모를 결정하는 것은 공격면 숫자다. 미국에는 5만 개의 서로 다른 수도 사업체가 있고 미국 물의 90%가 이들에게서 나온다. 이들은 역사적으로 예산이 부족하고 IT 인력이 제한적이며 전담 사이버보안 직원이 아예 없는 곳도 있다. 각 사업체가 개별적으로 방어를 강화하는 모델 자체가 성립하지 않는다는 것이 Nakasone의 논지다. "우리는 이걸 어떻게 방어할지 다르게 생각해야 한다"는 말 다음에 나온 대안이 파트너십이다. 2년 전 DEF CON에서 시작된 DEF CON Franklin은 해커들이 시간과 재능을 자원봉사로 내어 수도 시설 보안을 돕는 프로젝트다. Nakasone 자신도 Vanderbilt University 국가안보연구소와 Wicked Problems Lab의 창립 디렉터이자, 오픈소스 기술 위에서 핵심 인프라 복원력을 높이는 사이버보안 플랫폼 Project Chimera에 참여하고 있다.

"OT를 인터넷에 붙이지 마라"는 20년 넘은 권고지만, 실제로는 원격 관리 편의와 인건비 절감 때문에 계속 붙는다. 5만 개 사업체라는 숫자는 이 문제가 개별 조직의 보안 성숙도 문제가 아니라 구조적 자금과 인력 문제임을 보여준다. 반론 여지는 자원봉사 해커 프로그램이 5만 개 사업체 규모를 감당할 수 있는 모델인가에 있다.

랜섬웨어가 CEO를 건너뛰고 46세 중간관리자를 노린다

Hacker News · The Register, Zscaler ThreatLabz

랜섬웨어 생태계가 암호화 중심에서 갈취 중심으로 이동하면서 표적 선정도 바뀌었다는 것이 이 보고서의 요지다.

Zscaler ThreatLabz가 한 달간 단일 캠페인에서 334개 조직에 걸친 피해자 351명을 추적했다. 프로필이 놀랍도록 구체적이다. 피해자의 거의 3분의 2가 매니저급 이상 직함을 갖고 있었고 평균 피해자는 46세 Gen X였다. 4분의 3이 회계와 재무, 영업, 운영, HR, 마케팅에서 일했고 절반은 산업이나 IT 부문 소속이었다. 방식도 무차별 살포가 아니다. 공격자들은 침해한 시스템에서 얻은 정보와 공개 데이터를 결합해 보고 체계를 지도화하고, 조직의 대응에 영향을 줄 가능성이 가장 높은 직원을 찾아낸다. Zscaler의 표현으로는 "랜섬웨어 지형이 무차별 공격에서 고도로 표적화된 갈취 캠페인으로 이동했다. 경영진을 직접 노리기보다 지급 결정을 앞당길 권한이나 영향력을 가진 매니저와 핵심 인력에 집중하는 추세"다.

여기서 나오는 개념이 이 항목의 재사용 가치다. 기술적 권한이 아니라 업무 권한(business privilege)이다. 보안팀은 전통적으로 관리자 권한을 가진 특권 사용자에 집중해왔지만, 공격자가 원하는 것은 송장, 지급 승인, 예산, 공급사 계약, 고객 계정, HR 기록 같은 민감한 업무 프로세스에 일상적으로 접근하는 사람이다. 연구진의 문장은 이렇다. "침해된 관리자 계정의 가치는 그 직위에 딸린 업무 접근의 폭에 있다. 매니저는 지급을 승인하고, 예산과 공급사를 관리하고, 계약을 검토하고, 민감 기록에 접근하고, 사업 단위 간 업무를 조율한다." Gen X 편중도 우연이 아니다. Zscaler는 40대와 50대 직원 상당수가 자리 잡은 관리직에 도달해 있어, 경영진을 침해하지 않고도 가치 있는 시스템과 민감 정보와 의사결정 권한을 가진 사람에게 접근할 수 있다고 본다. 또 12개 이상 조직에서 여러 직원이 동시에 침해된 것이 확인돼, 공격자들이 내부에 들어온 뒤 단일 발판에 만족하지 않고 업무 기능을 옮겨 다녔음을 시사한다. 거시 추이로는 Zscaler 클라우드 플랫폼에서 차단된 랜섬웨어 시도가 지난 1년간 146% 늘었고 공개 갈취 사례는 70%, 탈취 데이터 볼륨은 92% 증가했다.

HN 토론에서 나온 반론 두 가지가 중요하다. 첫째, 기사가 "피해자"의 정의를 흐린다는 지적이다. 공격자가 Gen X 매니저를 실제로 공격해 암호화한 것인지, 아니면 단순히 빨리 돈을 받으려고 이들에게 연락한 것인지 기사만으로는 알 수 없고, 후자라면 이들은 피해자도 피격자도 아니며 피해자는 회사라는 것이다. 둘째, neilv는 이 공격이 상업적으로 구매 가능한 데이터에 의존한다고 지적한다. 엔터프라이즈 영업사원이 데이터 브로커에게서 직접, 또는 영업 퍼널용 계층 서비스로 이 정보를 살 수 있고, 결국 수많은 미국 기업이 집단적으로 인물 네트워크를 지도화하고 개인 신상 파일을 조립해 국제 조직범죄와 지정학적 적대 세력의 수고를 대신 덜어주고 있다는 것이다. "감시 자본주의가 국가안보 위협이 되는 또 하나의 경로"라는 표현이 나왔다. SoftTalker는 여기에 "실제 기업 영업 방식에서 배운 것"이라고 덧붙였다. 영업사원과의 첫 대화가 상대에게 실제 구매 권한이 있는지, 없다면 누구에게 있는지 알아내는 데 맞춰져 있다는 점에서 구조가 같다는 관찰이다.

Flock 번호판 인식 시스템 사적 조회로 조지아 경찰 6명 해임

Hacker News · WTOC

사실관계는 짧다. Savannah 경찰서가 Flock Safety 번호판 인식(LPR) 시스템 오남용에 대한 내부조사 끝에 정규 경찰관 4명과 민간 직원 2명을 해임했고, 6건 모두 조지아수사국(GBI)의 독립 형사 수사에 회부됐다. 6명은 앞서 행정 휴직 처분을 받았는데, 계기는 시스템 활동에 대한 선제적 검토에서 정당한 법 집행과 무관해 보이는 검색이 발견된 것이었다. 내부조사는 7월 27일 시작됐고 지금은 종결됐으며 GBI 수사는 진행 중이다.

무엇을 했는지도 구체적이다. 조사관들은 직원들이 개인적 지인과 가족을 대상으로 검색을 실행한 것을 확인했다. 한 명은 권한이 없는 외부 법 집행기관 인물에게 SPD의 Flock 시스템 접근권을 부여한 것으로 드러났다. 적발은 부서의 감사와 감독 체계, 그중에서도 2026년 4월부터 이용 가능해진 Flock Safety Audit Assist 프로그램을 통해 이뤄졌다. Flock 플랫폼에서는 모든 검색이 누가, 언제, 어떤 사유로 실행했는지 자동 로깅되고, 여기에 필수 교육과 역할 기반 접근 제어와 감독자 감시가 더해진다. 사건 후 SPD는 전문직무표준실이 수행하는 주간 정기 감사를 새로 도입했다. 해임된 직원 이름은 형사 수사와 진행 중인 항소 절차 때문에 비공개다.

HN 토론이 흥미로운 이유는 같은 사실을 두고 정반대 결론이 나왔기 때문이다. akerl_는 "사용을 모니터링하고, 오남용을 식별하고, 관련자를 해임한 기사에 이상한 코멘트"라며 이것이야말로 유인이 있고 실제로 따라간 사례라고 본다. tptacek는 건조하게 "Flock 카메라는 경찰관을 해고시킬 수 있는 몇 안 되는 것 중 하나로 보인다"고 적었다. 반대편에서 edot는 "말단을 처벌해 시민이 이 시스템에 책임성이 있다고 믿게 만드는 것"이라고 읽었고, smallerize는 해임된 뒤에도 이름이 공개되지 않는다는 점에서 책임성이 없다고 지적했다. 실행 정보에 가까운 코멘트도 있다. Tostino는 자기 마을이 이미 Flock 카메라로 덮였는데 지역 언론에 별 예고가 없었고 카운티 전역에 50%를 더 설치하려 한다며, 조닝 회의에 나가 반대 발언을 하고 주요 교차로에 회의를 알리는 야드 사인을 직접 인쇄해 세웠다고 적었다. CircuitSeuss는 여기에 "표지판에 화살표를 넣어 카메라 위치를 가리키라, 사람들이 자기를 촬영 중인 장치를 직접 보면 훨씬 효과적"이라고 제안했다. 가장 균형 잡힌 관점은 austin-cheney의 것이다. 기사를 읽어보면 문제는 감시 자체가 아니라 경찰 시스템의 무단 사용이며, 번호판이나 신원 정보의 부적절한 조회로 경찰이 수사받고 형사 회부되는 것은 수십 년 전부터 있던 일이라는 지적이다.

Windows GDID - 로컬 계정으로도 막히지 않는 서버 발급 기기 식별자

Hacker News · yegors/deGDID, GitHub

이 항목을 남기는 이유는 도구 자체보다 GDID라는 식별자의 성격 때문이다.

GDID(Global Device Identifier)는 Microsoft의 DeviceAdd 인프라를 통해 발급되는 서버 할당 64비트 Device PUID이고, Windows가 여러 로컬 신원 저장소에 걸쳐 유지한다. 중요한 점은 로컬 Windows 계정을 쓴다고 해서 이 기기 수준 발급이 막히지 않는다는 것이다. Microsoft 계정을 안 쓰는 것으로는 회피가 안 된다. 그리고 이것이 실제로 조회된 기록이 있다. 저장소 설명에 따르면 2026년 법정 보도로 Microsoft가 한 수사에서 GDID와 URL, 시간, IP의 연관 정보를 보유했음이 확인됐다. 다만 어떤 Windows 구성요소나 네트워크 채널이 그 연관을 만들었는지는 공개 기록에 나와 있지 않고, 저자도 이 도구가 그 미지의 채널을 막는다고 주장하지 않는다고 명시했다. 도구의 목표는 좁게 규정돼 있다. 지원되는 Windows 대상에서 알려진 로컬 저장소로부터 실제 서버 발급 GDID 상태를 제거하고 DeviceAdd 경로를 지속적으로 차단 상태로 유지한다는 것이지, 일반 텔레메트리나 브라우저 프라이버시나 법정 기록 채널 억제 주장이 아니다.

적용 대상이 좁다. 관리되지 않는 개인 Windows 설치에 사람 프로필 하나가 로드된 경우를 노린다. Windows 10 22H2/빌드 19045 또는 Windows 11 빌드 22000 이상, 도메인과 Entra와 워크플레이스와 MDM 미등록, 관리자 권한 64비트 Windows PowerShell 세션이 조건이다. Windows 11 25H2/빌드 26200이 완전히 랩 검증된 라인이고 다른 허용 빌드는 경고를 낸다. 관리 시스템과 모호한 사용자, 여러 프로필이 로드된 경우는 추측하지 않고 거부한다. ProtectedNoRealGdid가 유일한 완전 성공 결과다. Protect는 네 단계를 밟는다. 듀얼스택 hosts 차단을 적용하고 실제 DeviceAdd 경로를 확인한 다음, 정책이 허용하는 곳에서 방화벽 심층 방어를 갱신하고, 대상 사용자와 .DEFAULT와 SYSTEM에서 알려진 GDID 사본과 기기 신원 재수화 소스를 제거한 뒤, 대기하고 네트워크 게이트를 재확인해 신원 상태가 돌아오면 성공을 거부한다. 네트워크 게이트를 신원 변경보다 먼저 적용하고, 필수 검사가 실패하면 부분 보호 상태로 계속 가는 대신 멈춘다는 설계가 요점이다.

증거의 범위도 정직하게 적혀 있다. 로컬 계정 랩 VM에서 33시간 이상 보호가 유지됐고, Unblock 후 재발급을 관측하고 재보호와 클린 재부팅을 확인했으며, MSA 연결 현장 실행에서는 로그아웃과 로그인, 절전과 복귀, 재부팅을 거쳐 18시간 보호가 유지됐다. 이 증거는 기록된 기기와 기간에 한정된다고 명시한다. 호환성 피해도 미리 적어뒀다. login.live.com, account.live.com, DDS, wlidsvc 서비스 경로를 차단하면 MSA 로그인, Store와 Xbox 인증, OneDrive MSA 로그인, Phone Link, CDP 그래프 기능과 관련 신원 워크플로가 깨지거나 저하될 것으로 예상된다.

HN 토론에서 나온 대안 전략이 흥미롭다. hypfer는 "수천 대에서 같은 GDID를 쓰거나, 읽을 때마다 무작위 GDID를 주는 게 낫지 않나. GDID 없음은 오히려 더 튄다"고 했고, jmclnx는 "부팅할 때마다 재생성하는 것도"라고 덧붙였다. Melatonic이 이를 정리하기를, 같은 GDID를 충분히 많은 사람이 쓰면 Microsoft 쪽 데이터를 오염시켜 수정이나 다른 구분 방법을 유도할 것이고, 무작위 GDID는 보안을 통한 은폐에 가깝지만 세션 단위 추적은 여전히 허용하며, GDID 없음은 더 튀지만 역시 수정을 유도할 수 있다는 것이다. LoganDark는 실효성에 대한 구체적 문제를 제기했다. Windows에는 hosts 파일을 완전히 우회하는 Microsoft 도메인 하드코딩 목록이 있는데 이 문서에 그에 대한 언급이 없다는 것이다. 다만 이 접근이 어쨌든 작동하는 것으로 테스트됐다는 점은 인정했다. 법적 논점도 나왔다. IP가 개인 식별자로 분류되므로 GDPR 위반일 것이라는 주장에 buzer가 정확하게 반박했다. IP 저장 자체는 불법이 아니고 문제는 저장의 법적 근거가 적절한지, GDPR 13조 고지가 그 처리를 포함했는지, 5조 원칙(데이터 최소화, 보관 기간 등)을 지켰는지, 그리고 Microsoft가 경찰에 데이터를 넘길 법적 근거가 있었는지라는 것이다.

마지막으로 이 README 자체가 별도 논쟁을 만들었다. userbinator는 "the mutation path", "the fully lab-validated line", "device-identity rehydrate sources", "real-shaped PUID" 같은 표현을 인용하며 읽기가 극도로 어려웠고 LLM 문체 같은데 본 것 중 가장 이상한 방언이라고 했다. andersa는 이 문체를 "advanced technical claudish"라고 명명했고, azalemeth는 "편집자 없이 자기 프로젝트에 너무 오래 매달린 Claude"라고 답했다. cyanydeez는 "이 ID 키가 감시에 쓰인다고 믿고 싶겠지만 브라우저가 쓰는 것과 같은 종류의 핑거프린팅일 가능성이 높다"고 회의를 표했고, dvtkrlbs가 "최소 한 건의 사례에서 감시에 쓰였음을 보여주는 법정 문서가 문자 그대로 있는데 어떻게 그게 편집증이냐"고 응수했다.

FCC, LiDAR 장착 외국산 드론을 "군용급"으로 묶어 소급 금지 추진

Hacker News · Tom's Hardware, Federal Register

규제 내용 자체보다 "군용급"이라는 범주가 어디까지 뻗는지가 이 기사의 핵심이다. FCC는 2026년 8월 3일 Federal Register에 공개 통지(DA 26-758)를 내고, Covered List에 오른 외국산 드론 중 LiDAR 센서를 포함하거나 통합한 기종의 수입과 판매를 소급 금지하는 안을 제안했다. LiDAR를 넓은 "군용급" 우산 아래 분류한 것이다.

맥락은 작년 말부터다. 2025년 12월 22일 FCC는 모든 외국산 드론과 핵심 부품을 Covered List에 추가했다. Covered List는 미국 국가안보 당국이 용납할 수 없는 위험을 초래한다고 판정한 통신 장비 목록이다. 이 등재로 신규 외국 드론 모델이 미국 판매에 필요한 FCC 인증을 받을 수 없게 돼 사실상 신규 모델 판매가 막혔다. 다만 등재 이전에 이미 인증을 통과한 모델은 계속 수입되고 팔릴 수 있었다. 새 제안은 그렇게 빠져나간 기존 승인 모델의 판매 승인을 소급으로 박탈하는 것이다. 의견 수렴은 2026년 9월 2일까지이며 원안대로 채택되면 공표 약 180일 후 발효된다. 소비자 영향은 구체적이다. DJI의 Air 3S와 Mini 5 Pro는 둘 다 장애물 감지에 LiDAR를 쓰므로 미국에서 판매가 불가능해진다. 기존 소유자는 갖고 있는 드론을 계속 날릴 수 있지만, DJI가 경고한 대로 정품 예비 부품을 구하기가 점점 어려워지거나 결국 불가능해질 수 있다.

"군용급" 분류의 범위가 이 통지에서 가장 논쟁적이다. LiDAR 외에도 열화상 센서를 탑재했거나, 농약을 살포할 수 있거나(통지의 문언은 "economic poison"), 무게가 55파운드 이상이거나, 도킹 스테이션을 포함하거나, 방산 품목을 통합했거나, 협조 군집으로 운용되는 드론까지 걸린다. 마지막 항목의 FCC 정의는 동기화된 드론 라이트쇼까지 포함할 만큼 넓다. 미국산 드론과 Covered List에 없는 드론은 이런 기능을 갖고 있어도 규제 대상이 아니다. FCC는 이를 순수한 국가안보 사안으로 규정하며 경제적 타격은 미미할 것으로 잠정 결론지었는데, 근거는 레크리에이션 비행자가 지배하는 시장에서 군용급 모델이 소수라는 것이다. 동시에 통지는 최초 금지 이후 Skydio 같은 국내 드론 제조사가 조달한 수십억 달러를 상술한다. Skydio는 미국 내 제조에 35억 달러를 약정했다.

DJI의 반박은 두 층이다. "군용급" 라벨 자체가 범주 오류로, 소방과 구조 대원, 농민, 취미인이 의존하는 민간 도구를 쓸어담는다는 것이다. 그리고 핵심 반론은 LiDAR 조항인데, 이 기술은 안전 기능이지 무기가 아니라는 주장이다. DJI는 앞서 12월 금지에 대해서도 FCC가 법정 권한을 넘었다며 소송을 냈다. HN 토론에서 동기 추측이 여러 갈래로 나왔는데 ranger_danger가 정리한 것이 가장 체계적이다. 안티 Flock 커뮤니티는 LiDAR가 원거리에서 이미지 센서를 파괴할 수 있고 외국산을 금지하면 국내산 드론에 특정 방식이나 특정 구역에서 작동하지 못하게 하는 펌웨어를 강제할 수 있기 때문이라고 본다. 금융 커뮤니티는 국내 제품보다 잘 팔릴 경쟁을 원치 않는 것이라고 보며 중국산 EV 금지와 같은 논리로 읽는다. 프라이버시 커뮤니티는 감시를 내부에서만 가능하게 하려는 것으로 본다. 기술적 반론도 두 가지가 나왔다. onetimeusename은 FCC 노트를 읽으면 LiDAR 자체가 위험이라기보다 무역과 공급망 보호주의처럼 읽힌다고 했고, theptip은 반대로 "중국이 미국 도시 구석구석의 고해상도 지도를 만드는 것"이 명백한 우려일 것이라고 봤다. tamimio는 실무자 관점에서 "LiDAR 기반 드론은 주말 프로젝트로도 만들 수 있고, 내가 아는 미국 드론 제조사들 대부분이 중국 부품에 의존하며 무선 통신이 그 목록 최상단"이라고 지적하고, 자기가 DJI라면 LiDAR와 유사 부품을 모듈화해 드론은 계속 팔고 소비자가 모듈을 나중에 사거나 직접 만들게 하겠다며 그게 수리 용이성에도 좋다고 제안했다.

AI 인프라의 물리적 비용

Amazon의 텍사스 AI 데이터센터, 미국 최대 배출 시설이 될 7.65GW 가스 발전소

GeekNews · Distilled 단독 보도, GeekNews · 후속

같은 날 두 건으로 올라온 이 사안은 AI 인프라 논의에서 가장 구체적인 물리적 숫자를 제공한다.

Amazon이 Texas 서부 Pecos County에 GW Ranch라는 이름의 AI 데이터센터 부지를 매입하고 관련 허가를 확보했다(매입가는 비공개). 이 데이터센터에 전력을 공급할 천연가스 발전소는 터빈 35기로 최대 7.65GW를 생산하며, 적어도 초기에는 Texas 광역 전력망(ERCOT)에 연결하지 않는다. 전력회사와 연결하는 데 몇 년이 걸릴 수 있는 상황을 피하기 위한 전용 현장 발전 방식이고, 천연가스가 선택된 이유는 이런 규모의 발전시설 중 상대적으로 빠르고 쉽게 지을 수 있어서다.

핵심 숫자는 배출량이다. 이 발전소는 연간 약 3,300만 톤의 이산화탄소를 배출할 수 있도록 허가받았다. 실제 시설이 허가 한도까지 배출하는 경우는 흔치 않지만, 허가량만으로도 현재 미국 최대 배출 발전소를 크게 넘어선다. 비교 대상은 Alabama Quinton의 James H. Miller Jr. Power Plant로 연간 약 1,600만 톤을 배출한다. 계획대로 지어지면 GW Ranch가 미국 최대 오염 시설이 된다. 천연가스 발전소는 온실가스뿐 아니라 스모그를 만드는 오염물질도 배출하고 이는 심장질환과 천식 같은 건강 문제로 이어진다. 환경단체 Public Citizen은 이 규모가 지역 대기오염과 기후 양쪽에 큰 영향을 줄 것이라고 비판했다.

Amazon의 기후 약속과의 충돌이 이 기사의 갈등 축이다. Amazon은 2040년까지 온실가스 순배출을 사실상 제거하겠다는 The Climate Pledge를 공동 창립했지만 배출량은 최근 몇 년 매년 늘었다. 회사도 AI 데이터센터의 증가하는 배출이 기후 목표 달성을 방해할 수 있다고 인정한다. Amazon이 내놓은 대책은 세 가지다. Texas의 기존 데이터센터 운영을 위해 40개 프로젝트에서 무탄소 에너지 10GW를 확보했다는 것, GW Ranch에서는 식수나 관개에 쓸 수 없는 염수성 지하수(brackish groundwater)를 쓰겠다는 것, 그리고 자체 발전이므로 Texas 가정의 전기요금을 올리지 않는다는 것이다. 태양광과 배터리 저장장치 병용도 검토 중이라고 밝혔다.

진행 상황은 이미 빠르다. Amazon은 승인 즉시 건물 3동을 지을 수 있도록 Texas주에 건설 허가 3건을 신청했고, 위성사진에서 부지 정리 작업이 이미 시작된 것이 확인된다. 완공되면 Amazon은 Microsoft, Google, Meta와 함께 자체 off-grid 가스 발전을 보유한 기업 대열에 들어간다. 정책 배경도 명확하다. Trump 대통령은 데이터센터용 발전소 건설을 지원하며 태양광과 풍력보다 석유, 천연가스, 석탄을 앞세우는 energy dominance 정책을 추진하고 있다. 2025년에는 데이터센터를 더 쉽게 짓고 운영할 수 있게 하는 행정명령을 냈고 이후 연방기관들이 건설 절차를 신속 처리하도록 하는 정책이 뒤따랐다. Cleanview 창업자 Michael Thomas에 따르면 올해 이전까지 Amazon 데이터센터는 주로 화석과 청정이 섞인 기존 전력회사 전력을 썼고, AI 붐이 이 방식을 바꾸고 있으며 Pecos County가 앞으로 나타날 데이터센터 전력 인프라의 선례가 될 가능성이 있다.

데이터센터 반대는 미국에서 초당적 현상이 됐다. 데이터센터는 일자리를 많이 만들지 않고 지역경제를 활성화하지 못하며, 지역 전력망에 연결되면 요금을 올리고 정전이나 전압 저하를 일으킬 수 있다. 자체 발전소는 요금을 걱정하는 주민에게 일부 안도감을 줄 수 있지만, 미국의 다른 어떤 가스 발전소보다 큰 시설에서 나올 오염 우려는 그대로 남는다. Texas 농촌은 공화당 지지세가 강한데도 우파에서 데이터센터 반대가 커지고 있어, 프로젝트가 공개된 지금 큰 반발이 뒤따를 수 있다.

플러그인 태양광이 미국 뒷마당에 등장 - 독일 1.5GW 선례와 영국 8월 27일 합법화

Hacker News · NYT

앞 항목이 7.65GW 발전소 하나라면 이쪽은 800W 수십만 개다. 핵심은 미국이 뒤늦게 따라가는 중이라는 것이다. 독일에서는 플러그인 태양광이 이미 매우 흔하고 설치 용량이 약 1.5GW에 이른다. micw가 정확한 현행 규정을 정리했다. 인버터 800W, 태양광 패널 2kWp(최대 4장)이고, 동쪽과 서쪽에 나눠 배치하는 구성으로 긴 일조 시간 동안 800W를 뽑을 수 있게 한 것이다. 절차는 공공 데이터베이스에 설치를 등록하고 인버터를 꽂는 것이 전부다. 이전에는 더 복잡했다. 특수 플러그가 필요했고 600W로 제한됐으며 전력망 사업자의 허가를 받아야 했다. 그런데도 약 1.5GW가 설치됐다.

경제성이 이 항목에서 가장 실용적인 숫자다. 독일 기준 투자 회수 기간이 보통 3~4년이고 수명은 20년이다. 자기 주에서 300유로 보조금을 받아 산 경우에는 회수가 즉시였다고 덧붙였다. domh는 영국이 2026년 8월 27일에 이를 합법화하며 독일을 참고해 최대 800W로 정했다고 알렸다. Lio는 Lidl 같은 곳에서 200파운드 정도에 나오면 고민할 것도 없다고 반응했다.

댓글의 절반은 안전 논쟁이었고 결론이 잘 정리됐다. CodeWriter23이 1990년대 자기 건물 주차장 화재 때 소방관들이 인근 볼트에서 전력을 끊어줄 시청 유틸리티 담당자가 도착할 때까지 물을 뿌리지 않았던 경험을 들며, 전기 연결과 공급이 집 곳곳에 분산되고 화재로 접근 불가일 때 그 안전 절차가 어떻게 작동하느냐고 물었다. 0xbadcafebee의 답이 가장 구체적이다. 장치가 전력망의 기존 신호를 찾고, 못 찾으면 급전을 멈춘다. 재시도 전에 35분을 기다리고 무작위 지터를 더해 thundering herd를 피한다. 유럽에서는 한동안 표준이었고 이제 미국에서도 표준이 되어가는 중인데 유틸리티와 주에 따라 채택 여부가 다르다. 관련 표준으로 IEEE 1547(연계 동작), UL 1741(인버터 제품 안전), UL 3700(플러그인 태양광)을 들면서 일부는 최신 개정판이 필요하다고 덧붙였다. micw는 독일 기준으로 전력망이 오프라인이거나 분리되는 즉시 인버터가 스스로 꺼져야 하고, 그 속도가 "뽑은 뒤 플러그를 안전하게 만질 수 있을 만큼" 빨라야 한다고 설명했다. 업계 측 주장도 인용됐다. Craftstrom의 Scherer는 자사 시스템이 전력 교란이나 정전 발생 1초 이내에 자동 차단되므로 전기 작업자를 감전시키지 않는다고 했고, UL Solutions의 Boyce는 소비자나 유틸리티 작업자에게 위험을 주지 않아야만 패널을 인증한다고 했다. 설치 팁도 하나 나왔다. 흰 자갈 위에 프레임을 세워 양면 패널을 달면 2차 수광으로 2030%까지 끌어올릴 수 있다는 것인데, 지붕 설치라면 이 이점을 못 살리니 단면 패널이 더 싸다는 판단이 붙는다.

Aptera, 태양광 충전 EV 40대분 양산 부품 발주 - 20년 만의 첫 생산 단계

Hacker News · frequal.com

주의할 점부터. 원문은 예약 링크를 반복해 삽입한 팬 성격의 글이고 HN에서 "이 사업에 개인적 이해관계가 있느냐"는 질문이 붙을 만큼 홍보 톤이 짙다. 사실과 회의를 함께 싣는다.

사실은 이렇다. Aptera는 캘리포니아 회사로, 첫 차량은 이국적인 외형에 초고효율이며 햇빛에 주차만 해두어도 하루 최대 46마일(약 74km) 주행거리를 얻는다. 이번에 양산 차량 40대분 주요 부품을 발주했다고 발표했다. 예약이 거의 5만 건인 것에 비하면 40대는 적어 보이지만, 어떤 형태로든 거의 20년간 존재해온 이 회사가 차량 출하에 이만큼 가까워진 적이 없다는 점에서 이정표라는 것이 원문의 주장이다. 남은 주요 인증은 1개이고 Carlsbad, CA 시설에서 생산 준비 중이다. 올해 초에는 양산 지향 조립 라인에서 5대를 만들어 더 빠른 속도로 생산할 수 있음을 시연했고, 그 과정에서 차량 품질을 보증하는 검증 소프트웨어 같은 도구를 만들어 온라인에 공개했다. 40대 중 일부는 테스트용이라 전부 고객에게 가지는 않고, 초기 모델은 대형 투자자와 초기 투자자에게 먼저 간다.

회의적 반응이 더 유용하다. entrope는 "production"이 40개 모델이나 모델 변형이 아니라 차량 40대를 뜻한다는 점이 주목할 만하다며, 이건 양산이라기보다 프로토타입 수량에 가깝고 미국 법에서 군이 "저율 초도생산"으로 최대 10%까지 만들 수 있게 허용하는 것과 비슷하다고 했다. DivingForGold는 10년 넘게 이 제품을 지켜봤다며 "라인에서 1,000대가 나올 때까지 기다린 뒤에 관심을 갖겠다. 성공하길 바라지만 이런 곳들이 너무 많이 일찍 망했다"고 적었다. 실사용 제약 지적도 구체적이다. blacksmith_tb는 46마일이라는 하루 태양광 수치가 작은 표면적을 감안하면 상당히 낙관적으로 들린다고 회의했고, 더 큰 문제로 이 차가 오토바이로 분류돼 헬멧 착용과 class M 면허가 필요할 수 있으며 보험도 변수가 되고 거대하고 무거운 차들과 도로를 공유해야 한다는 점을 들었다. 충전에 대해서는 일반 EV처럼 집에서 레벨 1이나 2로 충전할 수 있고 FAQ상 고속 DC 충전도 지원할 의도라고 확인했다. 긍정 쪽 논거도 남길 만하다. omgwtfbyobbq는 충전 접근이 어려운 사람, 충전과 주행 비용을 절대적으로 최소화하려는 사람, 오프그리드 사용에 여전히 니치가 있다고 봤다. 하루 20~40마일 충전이면 음식과 물만 있으면 여러 곳을 천천히 여행하고 캠핑할 수 있다는 것이다. DennisP는 "내가 아는 유일한, 400마일 주행거리에 Miata 무게인 EV"라며 운전 재미 가능성을 짚었다.

오라클 ARM 프리티어가 2코어 12GB로 축소 확정됐다

Threads · kimjang0213

오라클 클라우드의 ARM(Ampere) 프리티어가 2코어 12GB로 축소 확정됐고 정책이 이미 적용됐다는 보고다. 두 줄짜리 게시물이지만 영향받는 사람이 많다.

기존 오라클 ARM 프리티어는 개인 개발자와 소규모 팀 사이에서 사실상 표준 무료 서버 자리를 차지하고 있었다. 상시 무료로 상당한 CPU와 메모리를 주는 유일한 선택지에 가까웠기 때문에 개인 프로젝트 백엔드, 디스코드 봇, 셀프호스팅 서비스, n8n이나 각종 자동화 워커, 그리고 최근에는 경량 모델 서빙까지 이 위에서 돌아가는 경우가 흔했다. 사양이 줄면 그 위에 얹어둔 워크로드부터 순서대로 압박을 받는다. 에이전트를 상시 가동하는 흐름과 겹쳐 보면 시점이 공교롭다. 무료 상시 컴퓨트가 줄어드는 동안 상시로 돌리고 싶은 작업은 늘고 있다.

규모의 엔지니어링과 자원

Shopify가 재고 예약을 Redis에서 MySQL로 되돌린 이유 - 진짜 병목은 아무도 안 보던 연결 점유였다

GeekNews · Shopify Engineering

이 글의 가치는 "Redis 말고 MySQL 쓰세요"가 아니라, 잘못된 곳을 몇 주간 최적화하다 진짜 병목을 찾아낸 과정 기록에 있다.

문제는 명확하다. 구매자가 결제를 완료할 때 재고가 실제로 남아 있는지 보장해야 한다. 한쪽으로 틀리면 두 구매자가 같은 마지막 재고를 사서 판매자가 주문 취소와 사과 이메일, 지원 비용을 떠안는다. 반대쪽으로 틀리면 재고가 있는데 품절이라고 말해 성사될 매출을 잃는다. 규모가 추상적이지 않다. Shopify는 미국 전자상거래의 14% 이상을 처리하고, 2025년 블랙프라이데이 피크에 분당 510만 달러가 찍혔다. 전년 대비 피크 분당 매출이 11% 늘었고, 재고를 쓰는 모든 결제가 예약 시스템을 통과한다. 오버셀 방지는 결제 시작 시 수분간 임시로 잡아두는 Reserve와, 결제 성공 시 재고 원장에서 영구 차감하는 Claim 2단계로 이뤄진다.

기존 Redis 모델은 품목별 수량 키에 DECR/INCR로 동시성을 처리했다. Redis 자체는 문제가 없었다. 문제는 예약이 Redis에, 원장이 MySQL에 있어서 claim 단계를 하나의 원자적 연산으로 묶을 수 없다는 것이었다. 순서에 따라 팔렸는데 원장에서 안 빠지는 초과 판매, 원장에서 빠졌는데 Redis에 계속 예약으로 남는 과소 판매가 둘 다 가능했다. 여기에 다중 위치 재고를 인식하지 못하고 별도 클러스터 운영 비용이 붙는다는 문제가 있었다.

새 설계의 핵심은 "품목별 수량 열 1개"를 "판매 가능한 재고 1개당 1행"으로 바꾼 것이다. 재고 10개는 10행이고, 3개를 예약하면 한 트랜잭션에서 3행을 선택해 옮긴다. 이를 확장 가능하게 만드는 것이 MySQL 8의 SKIP LOCKED다. 다른 트랜잭션이 잠근 행은 기다리지 않고 건너뛴 뒤 다른 가용 행을 반환하므로 같은 행을 둘러싼 경합이 사라진다. 아이디어의 출처는 37signals의 데이터베이스 기반 부하 분산(Solid Queue) 방식이다.

다만 모든 재고를 행으로 만들면 재고 5만 개에 위치 10개인 조합에서 50만 행이 생기고 예약 쿼리 탐색이 느려진다. 그래서 품목/위치 조합마다 가용 행 풀을 최대 1,000개로 제한하고, 예약이 행을 소비하면 별도 프로세스가 재고 원장에서 보충한다. 1,000이라는 숫자는 플래시 세일에서 관찰한 품목/위치별 피크 예약률에서 나왔다. 순간 수요를 흡수하고 지속 부하에서도 보충이 따라갈 만큼 크되, 테이블과 SKIP LOCKED 탐색을 느리게 만들 만큼 크지는 않은 지점이다. 극단적 플래시 세일로 인기 품목 풀이 비면 예약 경로에서 즉시 보충하는데, 잠금으로 한 트랜잭션만 보충하게 하고 나머지는 대기시켜 여러 요청이 동시에 행을 삽입하는 thundering herd를 막는다. 해당 예약의 지연은 늘지만 실제 재고가 있는 구매자를 품절로 돌려보내지 않으므로 정확성이 보존된다.

잠금 최적화 항목 네 개는 그대로 재사용 가능한 지식이다. 첫째, 초기 프로토타입은 auto-increment ID를 PK로 썼는데 SHOW ENGINE INNODB STATUS에서 예약 1건당 행 잠금이 2개 잡혔다. InnoDB가 WHERE 절의 보조 인덱스와 클러스터 인덱스(PK)를 모두 잠갔기 때문이다. PK를 shop_id, inventory_item_id, inventory_group_id, id 복합 키로 바꿔 필터 열을 PK에 포함시키자 행당 잠금이 1개로 줄었다. 둘째, 비어 있어 보충이 필요한 테이블에 SELECT ... FOR UPDATE SKIP LOCKED를 걸면 supremum 의사 레코드를 포함한 갭 잠금이 생겨 보충 트랜잭션의 삽입을 막고 교착을 유발했다. 해당 트랜잭션의 격리 수준을 REPEATABLE READ에서 READ COMMITTED로 내려 해결했고, 이건 이 코드베이스에서 비기본 격리 수준을 쓴 첫 사례라 트랜잭션별 설정을 위한 소규모 프레임워크 지원이 필요했다. 셋째, 예약과 확정 경로가 두 테이블을 다른 순서로 접근해 순환 대기가 생겼고, 예약을 units 테이블 DELETE 후 reserved_quantities INSERT로 통일해 없앴다. 넷째, 여러 품목 장바구니는 예약 쿼리를 UNION ALL로 묶어 한 번의 DB 왕복으로 처리했다.

여기까지가 예상 가능한 이야기고, 진짜 반전은 그다음이다. 프로덕션에서 목표보다 낮은 처리량에서 천장을 쳤는데 P90 예약 지연은 허용 범위였고 CPU도 포화가 아니었으며 쿼리는 이미 최적화된 상태였다. 증상은 MySQL에서 스레드가 대기열에 쌓이고, 대기 작업이 실행될 때 CPU가 급등하고, ProxySQL 계층에서 MySQL 백엔드 연결이 고갈되는 것이었다. 연결이 고갈됐다는 사실만으로는 누가 붙들고 있는지 알 수 없으므로 호출자별 귀속이 필요했다.

해법이 단순하고 이식성이 높다. 애플리케이션에서 모든 SQL 문에 /* conn_tag:checkout_completion */ 같은 주석 태그로 업무 프로세스를 표시하고, ProxySQL 계층에서 태그를 파싱해 각 호출자가 연결을 얼마나 오래 붙들었는지 측정한다. 결과는 "느린 쿼리"가 아니라 "긴 트랜잭션 동안 연결을 붙든 프로세스"별 총 점유 시간이다. 그러자 예약이 유일한 heavy user가 아니었음이 드러났다. 결제 경로의 다른 부분들이 필요 이상으로 오래 연결을 붙들고 있었고, 그것들은 먼저 한계에 부딪히지 않아 최적화 대상이 된 적이 없었다. 연결은 유한하고 고처리량에서는 짧은 트랜잭션을 많이 돌려야 하는데, 다른 코드가 풀을 거의 소진한 상태에서 예약이 마지막 지푸라기가 된 것이다.

정리 결과 기본 데이터베이스의 읽기 50%와 트랜잭션 33%를 제거했다. 수년 전 보수적으로 설정하고 재검토한 적 없는 InnoDB 스레드 동시성도 현재 워크로드에 맞춰 올렸다. 둘을 합쳐 천장이 사라졌고, 고부하 플래시 세일에서 writer CPU는 50% 미만, reader CPU는 16% 미만을 유지했다.

전환도 한 번에 하지 않았다. 모든 예약을 Redis와 MySQL에 동시 기록하는 섀도 모드를 돌리며 Redis를 계속 기준으로 두고 실제 프로덕션 트래픽에서 두 시스템의 업무 결과와 성능을 나란히 비교했다. 두 시스템이 동시에 살아 있었으므로 진행 중인 예약을 이전할 필요가 없었다. 검증 후 기준을 MySQL로 옮기되 이중 쓰기를 유지해 Redis가 전체 예약 상태를 보유하게 하고 문제 시 kill switch로 되돌릴 수 있게 했다. 배포는 저트래픽 pod부터 시작해 거래량이 가장 많은 판매자까지 점진 확대했다.

저자들이 뽑은 교훈은 둘이다. 5년 전에 불가능했던 워크로드가 SKIP LOCKED 같은 새 기능으로 가능해질 수 있으니 오래된 기술 결정과 경험칙 설정을 다시 볼 것. 그리고 Rails 같은 전체 프레임워크 없이 작은 Ruby 스크립트와 MySQL만으로 만든 최소 프로토타입에서, 별도 터미널로 잠금 상태를 직접 관찰하며 이론만으로는 알 수 없는 동작을 배웠다는 것. 마지막 한 문장이 이 프로젝트의 진짜 목표를 요약한다. 예약을 빠르게 만드는 게 아니라, 장바구니 갱신과 결제 처리, 주문 생성과 DB를 공유하는 "안전한 이웃(safe neighbors)"으로 만드는 것이었다.

Windows 11 기본 날씨 앱이 RAM 1.5GB - WebView2가 만든 5배 격차

GeekNews · Notebookcheck

숫자 자체가 이 항목의 전부이고, 비교 대상이 있어서 인용 가치가 있다.

Windows Latest 테스트에서 Windows 11 기본 Weather 앱은 사용자의 별다른 집중적 상호작용 없이 일기예보만 표시하는 상태에서 RAM 1.2GB를 넘겼다. Wccftech도 비슷한 동작을 관측했다. 실행 초기에 약 1GB를 쓰고, 유휴 상태에서는 500-600MB로 줄지만, 확대하거나 인터페이스를 이동하는 기본 조작만으로 1.5-1.6GB까지 올라간다. RAM 8GB PC에서는 이 앱 하나가 전체 시스템 메모리의 거의 20%를 차지할 수 있다는 뜻이다. 비교 대상이 이 기사의 힘이다. macOS의 Apple Weather 앱은 유사 조건에서 250MB 미만을 쓴다. Microsoft 구현의 메모리 발자국이 약 5배 크다.

원인 설명이 명확하다. Windows 11 Weather는 완전한 네이티브 Windows 앱이 아니라 MSN Weather 웹 앱을 Microsoft의 WebView2 프레임워크로 감싼 형태다. 작업 관리자를 보면 여러 Chromium 기반 하위 프로세스가 동시에 돌고 있고 이 구조가 높은 RAM 사용량에 기여한다. 영향 범위도 구분돼 있다. 32GB 이상 고사양 PC에서는 큰 영향이 없을 수 있지만, 8GB나 16GB 시스템에서는 Weather를 켜는 것만으로 메모리 압박이 커져 Windows가 페이지 파일에 더 의존하게 되고 시스템 반응성이 떨어진다고 느낄 수 있다.

여기에 광고 문제가 겹친다. Weather 인터페이스의 예보 피드에는 스폰서 콘텐츠가 직접 삽입되고 날씨 카드와 유사한 시각 형태로 함께 표시된다. Microsoft가 Foreca, ECMWF(유럽중기예보센터)를 비롯한 여러 지역 기상 서비스에서 날씨 데이터를 라이선스하면서도 Windows 기본 앱에 광고를 넣었다는 점이 비판을 받았다. 이 발견이 회사의 최근 방향과 정면으로 충돌한다는 것이 기사의 마무리다. Microsoft는 여러 기본 앱을 업데이트하며 Windows 11이 저사양 하드웨어에서 더 나은 성능을 내도록 하겠다고 반복해 밝혀왔고, 임원 Rudy Huyn은 앞으로 완전한 네이티브 Windows 앱을 더 개발할 계획이라고 말했다. 다만 Weather 같은 MSN 브랜드 앱이 향후 WinUI로 다시 개발될지는 불분명하다.

os8088 - 커널 80,486바이트로 256KB에서 12개 작업을 선점형으로 돌린다

GeekNews · os8088.com

앞 항목 바로 다음에 놓으면 별도 논평이 필요 없다. "모든 수치는 빌드에서 나온 것"이라는 저자의 표기가 이 프로젝트의 성격을 요약한다.

os8088은 플로피 첫 섹터에서 그래픽 데스크톱으로 바로 부팅한다. 밑에 DOS가 없고 어디에도 명령줄이 없다. 512바이트 부트 섹터가 40KB 커널을 적재하고, 커널이 디스플레이 어댑터를 판별해 그래픽 모드로 전환한 뒤 비디오 카드 자체의 8x8 문자 세트를 빌려 메뉴 막대를 띄운다. 그 뒤로는 1984년 Macintosh의 인터페이스다. 제목 표시줄로 끌면 고무줄 윤곽선이 따라오는 창, 열어놓고 항목 사이를 드래그하는 풀다운 메뉴, 닫기와 최소화 상자, 플로피 드라이브별 아이콘, 화면 아래 실행 중인 프로그램마다 타일 하나씩인 Dock.

숫자가 인상적이다. 커널 전체가 80,486바이트인데 여기에 스케줄러, 창 관리자, VGA 드라이버, 마우스 드라이버, 사운드 계층, 파일 관리자, 로더, Task Manager, Control Panel이 전부 들어 있다. 부트 섹터는 정확히 512바이트이고 다른 크기로 어셈블되면 빌드가 실패한다. DS를 통해 접근하는 코드와 모든 버퍼의 세그먼트 사용량은 55,355바이트로, 64KB 세그먼트 안에 들어가야 하며 현재 여유가 10,181바이트 남았다. 최소 사양은 256KB RAM에 Intel 8086/8088이고 목표 하드웨어는 4.77MHz 8088의 IBM PC/XT다.

가장 눈에 띄는 성취는 선점형 멀티태스킹이다. 12개 작업 슬롯에 작업당 1,536바이트 스택을 주고, PC 기본 타이머 속도인 18.2065Hz로 문맥 교환한다. 매 틱마다 인터럽트 처리기가 레지스터 9개를 저장하고 스택 포인터를 교체해 다른 프로그램으로 복귀하는데, 약 서른 개 명령어면 끝난다. 어떤 프로그램도 협조할 필요가 없다. 두 개의 시계가 시간을 세고 두 개의 공이 계속 튀는 동안 다른 창에 타이핑할 수 있다. 당시 Macintosh는 이걸 못 했다. System 1은 한 번에 한 앱만 돌렸고, 1987년에 나온 MultiFinder는 협력형이었다.

제약을 정면으로 인정한 설계 결정들이 좋다. 창은 놓을 때까지 움직이지 않고 1픽셀 XOR 윤곽선만 포인터를 따라가다가 놓는 순간 한 번 다시 그려진다. 4.77MHz에서 마우스 리포트마다 창 전체를 다시 칠하는 것은 감당이 안 되기 때문이고, 1984년 Macintosh가 같은 방식을 쓴 이유도 같다. 백 버퍼는 선택 사항에 기본 꺼짐인데, 화면 전체 오프스크린 복사본이 153,600바이트로 256KB 기기 메모리의 절반이 넘기 때문이다. 256KB 기기에서는 화면에 직접 그리고, 500KB 이상이면 Control Panel에서 켤 수 있다. 프로그램은 두 번째 플로피에서 오고 각자 세그먼트를 받는다. Minesweeper는 아이콘을 포함해 1,510바이트이고, 512KB 기기에서 약 107KB, 640KB에서 약 233KB의 프로그램용 arena가 있다.

명령어 집합 제약은 기계적으로 강제된다. cpu 8086과 -w+error를 써서 더 최신 명령어가 들어가면 빌드가 실패한다. 1978년 명령어 집합만 쓴다는 것이 기계적으로 보장된다. 소스는 8086용 real-mode NASM 어셈블리이고 C도, 링커도, 런타임 라이브러리도 없다. 그리고 저자가 명시하듯 이 어셈블리는 AI로 작성됐다. 에뮬레이터 캡처에 그치지도 않았다. 2026년 8월 디스크 이미지를 실제 플로피에 기록해 1981년형 IBM 5150, Toshiba T1100 Plus, 286 시스템 세 대에서 부팅하고 촬영했다. 5150에서 Hercules 카드를 720x348로 구동하며 360KB 플로피로 부팅해 Note Pad, About 박스, Clock, Task Manager, Minesweeper, Disk 창까지 여섯 개를 동시에 띄운 사진이 있고, 촬영자 Elendilon은 에뮬레이션 대비 체감 속도 차이가 없었다고 보고했다.

역사적 맥락이 이 프로젝트에 의미를 준다. 1985년 2월 Digital Research가 IBM PC용 GEM 1.0을 출시했다. 스톡 XT 하드웨어에서 겹치는 창과 아이콘을 갖춘 Macintosh 스타일 데스크톱이었다. Apple이 소송했고, 합의 결과 1986년 GEM Desktop 2.0의 PC 버전에서는 겹치는 창과 데스크톱 아이콘이 제거됐다. 합의 대상이 아니었던 Atari ST 버전에는 두 기능이 유지됐다. 즉 PC는 잠깐 이걸 가졌다가 잃었다. os8088은 40년 뒤 같은 급의 기계에서 그 구상을 처음부터 다시 만들고, 당시 GEM도 Macintosh도 제공하지 않던 선점형 멀티태스킹을 얹었다. 안 하는 것도 명확하다. DOS 프로그램을 못 돌리고, 메모리 보호가 없으며(모든 프로그램이 커널과 하나의 64KB 세그먼트를 공유하는 이 구조가 문맥 교환을 싸게 만드는 이유이기도 하다), 파일 핸들과 seek이 없어 디스크 API는 파일 전체 단위로 write, read, delete, rename만 하고, 네트워킹도 없다.

검색 유입과 AI 지면

2주 만에 네이버 클릭 0에서 700으로 - 분기점은 검색량이 아니라 색인이었다

LinkedIn · Sihyun Kim, Threads · peekaikorea

숫자가 전부 공개된 SEO 실측 사례라 이날 국내 게시물 중 재사용 가치가 가장 높다. 2주 전까지 네이버 클릭 0회, 구글 클릭 1회였던 사이트가 노출되기 시작해, 최근 30일 기준 네이버 1.8만 노출에 700클릭, 구글 7,224회 노출에 110클릭을 기록했다.

데이터상 분기점은 7월 16일로 특정된다. 구글은 하루 노출이 5회 이하에서 69회, 319회, 436회로 계단식으로 뛰었고, 네이버도 같은 시기부터 노출되기 시작해 최근에는 하루 1,700회까지 올라왔다. 이 계단 모양이 이 사례의 핵심 형태다.

작성자의 진단은 통념을 하나 뒤집는다. 검색량이 없었던 게 아니다. 사람들이 이미 검색하고 있던 주제에 자기 콘텐츠가 노출되지 않고 있었을 뿐이고, 색인이 되기 시작하자 기존 수요가 그대로 유입으로 연결됐다. 초반에는 콘텐츠를 계속 발행해도 반응이 거의 없다가, 색인이 쌓이는 순간 여러 페이지의 노출이 동시에 늘었다. 작성자 본인이 처음 1~2주 숫자만 보고 중단했다면 이 결과를 못 봤을 것이라고 적었다. 신규 사이트에서 초기 지표가 0에 가까운 것이 실패 신호가 아닐 수 있다는 실증이다.

국내 실무에 직접 걸리는 발견은 검색엔진별 비중이다. 구글만 챙기면 충분할 줄 알았는데 최근 30일 클릭이 구글 110회, 네이버 700회로 네이버가 6배 이상이었다. 결론은 사이트맵과 색인 상태를 검색엔진별로 따로 관리해야 한다는 것이다. 한국어 콘텐츠를 다루면서 Search Console만 보고 있던 팀이라면 이 한 줄이 바로 액션 아이템이 된다.

AI 활용에 대한 평가도 균형이 잡혀 있다. 콘텐츠 제작과 발행 과정은 Claude Code와 Codex로 자동화했지만, AI로 글을 많이 만드는 것만으로는 부족했다. 검색 의도, 내부 링크, 페이지 구조, 크롤링 경로가 함께 연결돼야 실제 노출로 이어졌다는 것이다. 생산량이 아니라 구조가 병목이었다는 뜻이다. 다음 단계도 명시됐다. 발행량을 무작정 늘리는 대신 이미 노출되는 콘텐츠의 CTR을 올리는 쪽이다. 네이버 평균 CTR은 3.9%였고, 제목과 설명만 개선해도 같은 노출에서 더 많은 유입을 만들 여지가 있다고 봤다.

색인 지연 자체를 줄이는 기법도 같은 날 소개됐다. IndexNow는 검색엔진 크롤러가 알아서 찾아오기를 기다리는 대신, 새 페이지가 발행되거나 수정됐을 때 검색엔진에 직접 알리는 Push 방식이다. 위 사례에서 색인이 분기점이었다는 점을 생각하면, 색인 시점을 앞당기는 수단으로 두 항목을 함께 붙이는 게 자연스럽다. AI 검색엔진이 새 콘텐츠를 빨리 인지하게 만드는 GEO 맥락에서 소개됐다.

지도, 검색, 커머스가 동시에 AI 진입점으로 바뀌는 중

LinkedIn · Young Mi Kwon

한 건의 뉴스클리핑이지만 항목마다 날짜와 수치가 붙어 있어, 국내 플랫폼 변화를 가장 촘촘하게 담고 있다. 관통하는 축은 하나다. 검색과 지도와 커머스가 각각 AI 응답 화면을 앞단에 세우면서, 노출 경로와 광고 상품이 동시에 바뀌고 있다.

가장 큰 건은 구글 지도다. AI 기능 Ask Maps에 실제 거래가 붙었다. AI가 가게를 추천하고 메뉴를 장바구니에 담아주거나, 호텔 가격과 예약 가능 여부를 비교하고, 이벤트 티켓 구매 링크까지 연결한다. 미국부터 적용된다. 지도가 정보 조회 도구에서 구매 전환 지점으로 이동한다는 뜻이라, 로컬 비즈니스와 여행, 외식 업계에서는 지도 노출과 전환 최적화가 별도 과제가 된다. 국내는 네이버지도 영향력이 더 크지만, 해외 노출이 필요한 사업자라면 구글 지도 매장 정보를 미리 정리해둘 이유가 생겼다.

오픈AI 쪽 소식은 국내 광고 시장에 직접 걸린다. 한국에 챗GPT 광고 전담 조직을 꾸리고 국내 광고주와 대행사 지원을 확대한다. 노출 방식이 기존 검색 광고와 다른 점이 핵심이다. 검색 키워드 입찰이 아니라 이용자의 대화 맥락과 구매 의도를 기반으로 노출된다. 여기에 최소 집행 금액이 없는 셀프서비스 방식까지 들어간다. 소액으로 테스트할 수 있는 새 퍼포먼스 채널이 열린다는 뜻이다.

네이버는 세 갈래로 움직였다. 첫째, AI 브리핑 도입 후 블로그 노출과 유입이 늘어 6월 창작자 수익과 지원금이 지난해 2월 대비 약 2배 증가했다고 밝혔다. 애드포스트와 브랜드 커넥트에 네이버 메이트 월 3,000명과 기본 30만 원 지원이 얹힌다. AI 요약이 블로그 트래픽을 잡아먹는다는 통념과 반대 방향의 자체 수치라 그대로 인용할 가치가 있다. 둘째, 스마트플레이스에 플레이스 플러스(beta) 매장만 모아 보여주는 검색 필터와 추천 영역을 추가한다. 요일과 시간대별 인기 매장을 자동 노출하고, 8월 기준 15개 POS와 연동해 리뷰, AI 답글, 운영 리포트를 지원한다. 셋째, 2026년 8월 19일부터 쇼핑 카탈로그 페이지 내 쇼핑 브랜드형 광고 노출을 종료한다. 대상은 모바일 리뷰 영역 하단과 PC 우측 리뷰 영역 하단이며, 해당 상품군에 예산을 넣고 있던 광고주는 대체 지면을 미리 점검해야 한다.

쿠팡은 상품 이해를 돕는 쪽에 AI를 붙였다. 주요 카테고리에 '상품 한눈에 보기'를 도입해, 상품명 아래 핵심 장점을 보여주는 하이라이트, 세탁기 용량별로 티셔츠 몇 장이 들어가고 몇 인 가구에 적정한지를 안내하는 인포그래픽, 고객 리뷰 요약을 적용했다. 상세 페이지 전반으로 확대할 계획이다. 상세 페이지를 이미지로 도배하던 국내 커머스 관행이 구조화된 속성 데이터 쪽으로 밀린다는 신호다. 소비자 행동 데이터도 하나 붙었다. 20대의 SNS 점술 접촉률이 53.5%로 높고, 소비 이유는 불안보다 호기심과 재미가 앞선다는 것이다.

공공 데이터와 조달

공공데이터로 2주 만에 만든 앱이 1위인데, 서울 건물 56.1%는 높이 정보가 없다

LinkedIn · 송기성

폭염 시기에 그늘이 많은 경로를 찾아주는 앱 '그늘로'가 공공데이터만으로 2주 만에 만들어져 앱스토어 1위에 올랐다. 원리는 단순하다. 건물의 높이와 시각별 태양 위치를 계산해 그림자가 지는 구간을 추정하고, 그 구간이 많은 길을 안내한다. 2차원 지도에 높이 축 하나를 더한 것만으로 새 서비스가 만들어진 사례다.

이 게시물의 값어치는 앱 소개가 아니라 그 다음이다. 작성자가 실제로 개방된 데이터를 열어보고 결측률을 확인했다. 서울 지역 건물 약 70만 개 가운데 높이 정보가 없는 건물이 56.1%였다. 절반 이상이 높이를 모르는 상태에서 만들어진 서비스가 앱스토어 1위를 했다는 뜻이기도 하고, 데이터가 채워지면 정확도가 지금보다 훨씬 올라갈 여지가 있다는 뜻이기도 하다.

원인 진단이 핵심 주장이다. 정확한 정보가 없어서가 아니다. 더 정확한 3차원 공간정보는 이미 존재하는데, 보안 문제 때문에 쉽게 개방하기 어렵다. 즉 이것은 데이터 구축의 문제가 아니라 개방 정책의 문제다. 국가 시설과 군사 관련 정보가 3차원 공간정보에 함께 들어 있다는 사정은 이해할 수 있지만, 그 이유로 민간 건물 높이까지 통째로 막히면 이런 서비스가 절반의 정확도로만 만들어진다. 작성자는 두 가지 질문으로 정리했다. 도시는 입체적으로 분석할 때 더 필요한 결과를 낼 수 있다는 것, 그리고 지금 공개하고 있는 데이터가 이런 서비스를 만들기에 충분한가라는 것이다. 부분 개방, 정밀도 하향 제공, 승인 기반 접근 같은 선택지가 실제 논의 대상이 될 만한 지점이다.

3,000만 원대 예산에 300명 모집과 리더보드 개발까지 - 참가자 1인당 6만 원

LinkedIn · Nathan Jungwoo Lee

행사 기획사 대표가 AI로 제안서를 만들어보다가 공공 조달 시장 자체를 다시 계산해본 글이다. 수년간 나라장터를 하지 않던 회사가 재진입을 검토했다가 4~5개 제안서를 뜯어보고 접었다는 경과와, 그 판단의 산술이 함께 들어 있다.

충격을 받았다는 공고의 조건은 이렇다. 예산이 VAT 포함 3,000만 원 중반, 모집 목표 인원 300명. 여기에 포털사이트 광고, 소셜 광고, 멘토 구성, 리더보드 개발까지 과업에 포함돼 있었다. 작성자는 블록체인 해커톤과 지방 AI 해커톤을 여러 차례 수행한 이력을 근거로 이 조합이 성립하지 않는다고 봤다. 계산은 단순하다. 3,000만 원에 내부 수익률 20%를 잡으면 실제 집행 가능한 금액은 1,800만 원대 내외다. 참가자 300명으로 나누면 1인당 약 6만 원. 이 금액 안에 장소, 식음, 운영 인력, 멘토, 광고비, 개발비가 모두 들어가야 한다.

구조적 결과가 이 글의 핵심 주장이다. 저마진 공고에는 이른바 A급 회사들이 들어오지 않는다. 해봐야 남는 것도 없고 레퍼런스는 이미 충분하기 때문이다. 열정이 넘치거나 레퍼런스가 급하면서 실력도 있는 일부 회사가 지원하겠지만, 결국 B급 이하 회사들이 주로 접수하고 그중에서 1등을 한 회사가 수행하게 된다. 결과물 품질이 낮아지고, 그것이 다시 "국가 행사는 늘 별로다"라는 전제를 강화하는 순환이다.

AI를 도구로 쓴 대목도 흥미롭다. 나라장터 과업을 AI로 분석하면 거의 대부분 "마진율이 낮다", "제때 돈 받는 것 외에 좋은 것은 없다", "다른 고수익 행사를 찾는 게 낫겠다"는 분석이 나온다고 했다. 제안 작성을 돕는 도구로 도입한 AI가 오히려 입찰 자체를 포기하라는 판단을 내놓는 셈이라, AI 도입이 공급자 행동을 어떻게 바꾸는지 보여주는 사례이기도 하다. 앞으로 저마진 공고일수록 지원 업체가 더 빠르게 이탈할 수 있다는 뜻이다. 작성자는 세금을 아껴야 한다는 전제 자체는 인정한다. 다만 예산이 적으면 일이 적어야 하고 일이 많으면 예산이 많아야 하는데, 지금 구조는 예산은 적고 일은 많으며 남는 것은 정부 부처 로고를 홈페이지에 쓸 수 있는 정도라고 지적했다.

국내 개발자 시장

RSVP 182명 중 53명이 채용하는 회사를 만나러 오는데 스폰서가 없다

LinkedIn · Florian Ludot, LinkedIn · Devfolio

행사 공지 두 건인데, 한쪽은 참가자 구성 데이터를 전부 공개해서 국내 개발자 채용 시장의 단면으로도 읽힌다.

Dev Korea #12는 서울 강남에서 열리며 RSVP가 182명이다. 게시 시점 기준 스폰서가 없다는 것이 글의 목적이다. 주최자가 공개한 참가자 구성은 이렇다. 62%가 직접 코드를 쓰는 엔지니어, 즉 팀이 어떤 도구를 쓸지 고르는 사람이다. 65%는 새로운 기회에 열려 있고, 57%는 4년 이상 경력이다. 그리고 53명은 채용 중인 회사를 만나는 것이 참석의 명시적 목적이라고 답했다.

주최자가 가장 강조한 것도 마지막 숫자다. 회사를 찾겠다는 의도를 갖고 오는 엔지니어 수십 명이 한자리에 모이는데 정작 그들을 맞을 회사가 없다는 것이다. 채용 채널 관점에서는 지원자 풀의 밀도가 상당히 높은 편이고, 4년 이상 경력자가 절반을 넘는다는 점도 시니어 채용이 급한 팀에는 의미가 있다. 스폰서십이 이 행사들을 무료로 유지하는 재원이며 식음과 장소, 운영비를 감당한다고 밝혔다. 스폰서에게는 이벤트 페이지와 모든 발표 녹화에 로고 노출, 소셜 게시물과 리캡 기사 언급, 마이크를 잡고 제품이나 채용 공고를 소개할 시간이 제공된다. 다른 한 건은 Push to Prod 해커톤으로, Anthropic과 Elevation Capital, Mesa School of Business가 함께하며 멘토진이 확정됐다는 공지다. 규모는 빌더 150명이고 날짜는 8월 8일로 안내됐다. 모델 제공사가 직접 이름을 걸고 참여하는 해커톤이 늘어나는 흐름의 사례다.

매출 274억에 전사 연봉 1,000만 원 인상, 그리고 AI Engineer 공고가 요구하는 것

LinkedIn · Hyukjoon Choi, LinkedIn · Hyosun Kim

국내 LinkedIn에서 채용 관련 글은 많지만, 숫자를 공개한 건 두 건이었다.

첫째는 화이트큐브 대표의 티타임 제안 글이다. 회사 실적을 그대로 적었다. 2025년 매출 274억 원, 올해 목표 500억 원, 3년 연속 흑자다. 여기에 보상 정책도 공개했는데, 전사 차원에서 연봉 1,000만 원 인상을 단행했다고 밝혔다. 치열하게 몰입해 성과를 만드는 동료에게는 확실한 보상이 따라야 한다는 믿음의 실행 사례로 제시됐다. 글의 형식도 눈에 띈다. 채용 공고가 아니라 티타임 제안이며, 당장 이직 생각이 없어도 괜찮다고 명시했다. 앞서 '1:1 실패 복기 세션'을 열어 여러 창업가와 코파운더를 만났고, 30억 원이라는 수업료를 치르며 배운 경험을 나눴다는 배경이 붙는다. 찾는 사람의 조건도 개인기가 아니라 태도 쪽이다. 고객의 문제 해결에 몰입하는 사람, 개인플레이를 내려놓고 팀의 승리를 위해 협력하는 사람, 시장 앞에서는 겸손하되 목표한 것은 끝까지 풀어내는 사람 세 가지를 들었다. 채용 파이프라인 앞단을 대화로 여는 방식이라, 시니어 후보를 공고로 끌어오기 어려운 시장 상황을 반영한 형태로 볼 수 있다.

둘째는 AI Engineer 채용 공고 한 건인데, 요구 조건 목록이 지금 국내 시장에서 이 직군에 무엇을 기대하는지를 보여준다. 필수는 AI/ML/NLP 5년 이상 경력, PyTorch나 TensorFlow로 모델을 학습하고 개선한 경험, LLM/NLP 기반 서비스 개발 경험, RAG/Agent/Search 같은 생성형 AI 시스템에 대한 이해, 데이터 처리와 모델 학습과 평가 파이프라인 구축 경험, 그리고 개발한 모델을 실제 서비스에 적용해본 경험이다. 우대 조건은 Embedding과 Vector Search, 검색엔진 경험, 모델 배포, 모니터링, 운영 자동화, VLM과 멀티모달, 대규모 분산 처리 환경이다. 근무지는 서울 강남이다. 연구 역량보다 파이프라인 구축과 서비스 적용, 품질을 정량으로 측정한 경험에 무게가 실려 있다는 점이 특징이다.

개인 도구와 실험

Codex Realtime Mic - codex login이 남긴 OAuth 토큰으로 API 키 없이 전역 받아쓰기

GeekNews · MovieHolic-Plex, GitHub

작은 도구지만 남길 이유가 세 가지 있다. 인증 우회 방식, 실측으로 정한 설계 결정들, 그리고 안전장치 설계다. 동작은 한 줄이다. Ctrl+E를 누른 채 말하고 손을 떼면 커서 위치에 받아쓰기가 꽂힌다. API 키도 구독도 새 계정도 필요 없다.

API 키가 필요 없는 이유가 이 프로젝트의 핵심이자 리스크다. API 키로 붙는 공개 realtime 엔드포인트가 아니라, Codex 데스크톱 앱이 쓰는 ChatGPT 백엔드에 codex login이 남겨둔 OAuth 토큰으로 붙는다. ~/.codex/auth.json의 토큰을 읽어 쓰고 만료되면 알아서 갱신하며 앱이 따로 저장하는 자격 증명은 없다. 저자가 직접 붙인 경고가 중요하다. OpenAI와 무관한 비공식 프로젝트이며 realtime 프로토콜은 리버스 엔지니어링한 것이라 예고 없이 동작이 바뀔 수 있다.

파이프라인은 이렇다. 키를 누르면 cpal이 48kHz로 캡처해 24kHz 모노 PCM16으로 변환하고 WebSocket으로 스트리밍한다. 키를 떼면 무음 2초를 패딩하고 commit해 realtime 세션으로 보내면 전사 모델(ASR)이 처리하고, 정제 후 커서에 주입한다.

"전부 실측으로 정한 것"이라고 명시한 설계 결정 네 개가 이 항목에서 가장 재사용 가치가 높다. 첫째, 오디오는 webview를 거치지 않고 cpal이 잡아 Rust에서 바로 나간다. 둘째, 서버 VAD를 끈다. 턴 경계는 키를 뗀 시점이고, VAD에 맡기면 문장 사이 쉼마다 턴이 갈려 전사가 조각난다. 셋째, 앞뒤 2초 무음 패딩을 넣는다. 말이 시작되는 순간 녹음이 시작되면 모델 윈도잉이 첫 음절을 먹기 때문이다. 넷째, 전사는 ASR 부가 채널이 담당한다. 세션 모델은 생성형이라 문맥이 쌓이면 하지 않은 말을 지어내는 것을 실측으로 확인해 기본에서 제외했다. 이 네 번째 관찰은 realtime API로 받아쓰기를 붙이려는 누구에게나 유용한 함정 정보다.

안전장치 하나가 눈에 띈다. 엔터는 절대 입력되지 않는다. 전사에 줄바꿈이 있어도 공백으로 바뀌는데, 채팅창이나 터미널에서 의도치 않게 전송되는 사고를 막기 위해서다. 알약 형태의 오버레이 UI는 키보드 포커스를 뺏지 않아 드래그로 옮겨도 받아쓰던 창이 활성 상태를 유지하고 위치가 저장된다. 디버깅 설계도 배울 만하다. CODEX_MIC_DEBUG_DUMP_WAV 환경변수로 서버에 나간 오디오를 그대로 WAV로 덤프할 수 있고, 저자 표현대로 들어보면 문제가 마이크 쪽인지 모델 쪽인지 즉시 갈린다. 전사 모델과 realtime 모델 교체, 서버 VAD 복원, 마이크 대신 PCM 파일 재생 같은 실험도 재빌드 없이 환경변수로 할 수 있다.

한계는 분명하다. 스택은 Rust와 Tauri 2에 프레임워크 없는 정적 HTML/CSS/JS 프론트엔드이고, Windows 10/11에서만 테스트됐으며 서명하지 않은 바이너리라 SmartScreen이 막는다. 한국어 사용자에게 직접 걸리는 알려진 문제도 있다. endpoint가 엔드포인트로 나오는 것처럼 영어 단어가 한글로 표기되는 현상은 전사 모델 공통 성질이라 설정에서 다른 전사 모델을 시도해야 한다.

Ask HN 8월호 - 데이터베이스용 CLAUDE.md, Zig + Vulkan Video 녹화기, BYO 키 칼로리 트래커

Hacker News · Ask HN

월간 스레드라 항목 자체가 뉴스는 아니지만, 지금 개인 개발자들이 무엇을 만들고 있나의 표본으로 남길 가치가 있다.

첫째, 5QL(fiveql.com)이 개념적으로 가장 흥미롭다. 데이터베이스용 AGENTS.md나 CLAUDE.md 격의 테이블을 만든다는 발상인데, 여기에 조인과 정의, 포맷, 관계뿐 아니라 자주 쓰이는 조건 세트와 조합까지 담는다. 그리고 그것을 양방향 시각 SQL 에디터에 채워 넣어, UI에서 바꾸든 SQL 텍스트에서 바꾸든 양쪽으로 반영되게 한다. 전체가 단일 HTML 파일이다. 에이전트용 컨텍스트 파일이라는 관행이 스키마 문서화 도구로 번지고 있다는 신호로 읽힌다.

둘째, Spacecap(mgerb/spacecap)은 스택이 특이하다. 리눅스용 화면 녹화 도구인데 Zig로 쓰고 인코딩에 Vulkan Video를 쓰며 UI는 SDL3와 imgui로 만들었다. 녹화, 리플레이 버퍼, 스크린샷을 지원한다. 목표는 가능한 한 빠르고 효율적이면서 쓰고 설치하기 쉬운 것이다. 노출을 위한 최선의 조언으로 "Debian에 패키징되게 하라, 성가시지만 그만한 가치가 있다"는 답이 달린 것이 실용적이다.

셋째, Onigiri(ecliptik/onigiri)는 AI 기능 설계가 참고할 만하다. iPhone/Watch/iPad용 칼로리 트래커로 구독도 광고도 없고 Apple Health와 연동되며 완전 오픈소스다. AI 기능은 선택 사항인데, 온디바이스 Apple Intelligence를 쓰거나 Anthropic, OpenAI, OpenAI 호환 서비스(자체 호스팅 포함)를 사용자가 가져와 붙이는 BYO 방식이다. 제작자는 지난 한 달간 이것을 써서 약 10파운드를 뺐다고 적었다. 7일 서명 만료를 피하고 iCloud 연동을 개선하기 위해 TestFlight에 올릴 계획이지만 App Store 등록 계획은 없다. Claude Code와 Axiom skills로 개발했다.

넷째, The Curiosity Times는 프로젝트보다 그에 달린 비판이 남길 가치가 있다. 아이들을 위한 신문을 실제 신문 용지에 인쇄해 월간 배송하는 것으로, 퍼즐과 수학 챌린지, 자연 사실, 과학 실험, 야외 보물찾기, 가족용 카드/보드게임이 들어간다. 화면 시간 제한이 집안의 주요 목표였다는 것이 동기다. throwaway89201의 반박이 날카롭다. "가치 있는 목표지만 상상력 없는 AI 슬롭을 아이들에게 밀어넣지 말아 달라. 여기 보여주는 첫 페이지 그래픽에 이미 여러 슬롭 마커와 오류가 있는데도 그걸 그대로 쓰기로 한 것 같다. 현대에 아이들은 대부분 이미지를 통해 세상을 알게 되고, 그 이미지가 진짜이거나 최소한 사실적일 자격이 있다. 예를 들어 북쪽이 둘이고 동쪽이 뭉개진 나침반은 호기심 어린 대화의 좋은 출발점이 아니다." 그리고 세부가 그렇게 명백히 틀리지 않더라도 생성 이미지를 삼가라고 권한다. 대부분의 주제에서 본인이 전문가가 아니므로 그 오류를 판단할 수 없기 때문이며, 사진이나 세부를 포함해 틀리는 대신 상상에 맡기는 양식화된 일러스트를 쓰라는 것이다. 앞서 나온 ChipTycoon의 "100% 정확하다"는 주장과 정확히 같은 축에 있다.

나머지는 짧게 남긴다. lumirank.ai는 AI 챗과 검색을 위한 애널리틱스로, 러닝화 브랜드라면 "최고의 러닝화"를 물었을 때 AI들이 무엇을 추천하는지 추적한다. AI 검색 최적화라는 새 시장이 이미 도구 단계에 들어섰음을 보여준다. httpstate.com은 앱 사이에 작은 데이터 조각을 주고받는 배터리 포함 라이브러리와 서버다. wafertown.com은 "최초의 LLMORPG"를 표방하며, 프롬프트를 쓰면 캐릭터가 그것을 가이드 삼아 삶의 시뮬레이션을 살고 다른 캐릭터들과 상호작용하며 무엇을 했는지 요약을 보내주고 다음 날을 조종할 수 있게 한다. whatson.town은 자동 지역 이벤트 애그리게이터다. SMAAART는 비개발자를 위한 자기주도형 "Coding with AI" 코스를 만들고 있는데, 밖에서 찾을 수가 없어 자기 가려운 데를 긁는다는 동기다.

상호 링크 흔적을 없애려 백링크를 3~5명 루프로 돌린다 - 인디 빌더 쪽 신호

Reddit · r/indiehackers, Reddit · r/ProductHunters, Reddit · r/SomebodyMakeThis

인디 빌더 쪽 글은 개별로는 작지만, 이날 유통과 제품 정의를 고민하는 목소리가 한꺼번에 나왔다.

LaunchPact가 가장 설계가 촘촘하다. 문제 정의는 창업자라면 다 겪는 장면이다. 같은 니치의 누군가를 찾아 DM을 보내고 서로 링크를 걸어주기로 합의하는데, 그 결과가 Google 스팸 정책이 이름까지 붙여 명시한 상호 링크 패턴이고, 아무도 안 보는 "파트너" 페이지가 하나 생긴다. 그래서 이 서비스는 절대 쌍으로 매칭하지 않는다. 35명 루프로 돌려서 내가 B에게 한 문장짜리 do-follow 링크를 넣고 C가 나에게 넣는다. 내가 링크를 준 사이트와 나에게 링크를 준 사이트가 다르므로 상호 링크 흔적이 생기지 않는다. 매칭 조건도 있다. 도메인이 품질 점수로 15 티어를 받고, 루프는 서로 2티어 이내 그리고 같거나 인접한 니치끼리만 맺어지며, 자동 관련성 심사가 사람이 보기 전에 부적합을 거른다. 삽입은 전부 사이트 주인이 손으로 승인하고 넣으며, 7일과 30일과 90일에 크롤러가 링크가 살아 있는지 확인한다. 몰래 지우면 크레딧을 회수하고 신뢰 점수를 깎는다. 크레딧은 링크를 줘야만 생기고 돈으로 살 수 없다. 주는 건 무료, 요청하는 쪽이 월 29달러(첫 도메인 등록 시 14일 무료)다. 창업자가 며칠밖에 안 된 서비스라 풀이 작고 초기 가입자끼리 매칭된다는 점을 먼저 밝혔고, 크레딧 6개월 만료와 요청 유료화 두 가지는 본인도 확신이 없다며 반박을 요청했다.

Scholia는 문제 정의가 좋은 사례다. 파트너와 같은 책을 같은 시기에 읽는데 속도가 달라서 "6장까지밖에 안 읽었으니 아무 말도 하지 마"라는 협상이 계속됐고, 검색 결과든 위키든 책을 설명해주는 도구든 전부 독자가 이미 다 읽었거나 스포일러를 신경 쓰지 않는다고 가정한다. 그래서 읽고 있는 페이지를 사진으로 찍으면 어떤 책인지 이미 알고 있는 상태에서, 등장인물이든 인용의 의미든 헷갈리는 문단이든 물어볼 수 있게 만들었다. 단 그 지점까지 벌어진 일만 써서 답한다. 앞서 나간 걸 물으면 두루뭉술하게 넘어가는 게 아니라 아예 답하지 않고 독자가 따라잡을 때까지 버틴다. 페이지 번호를 판본에 매칭하는 게 아니라 눈앞의 실제 페이지를 읽기 때문에 어떤 물리책, 어떤 판본, 어떤 쇄에서도 동작한다.

나머지 세 글은 밀도가 낮지만 방향 신호로 남긴다. r/ProductHunters의 유통 글은 주장 자체는 익숙하다. 여행과 패션 스타트업 두 개를 만들어보니 진짜 킬러는 이탈률도 가격도 아니고 유통이었으며, 고객이 0명이면 리텐션 100%도 소용없다는 것이다. 다만 본문이 "전체 분석이 필요하면 요청하라"로 끝나 근거가 없다. r/automation 글은 수요 검증 질문이다. 정규직을 하면서 주당 8~10시간을 학습에 투자 중인 사람이 소상공인 대상 리드 후속조치, 일정 관리, CRM 업데이트, 리마인더, 관리 업무 자동화로 실제 수익을 낸 사람이 있는지, 니치를 하나로 좁히는 게 나은지 묻는다. r/SomebodyMakeThis의 CouncilAI 글은 로컬 우선 제품이 부딪히는 벽을 보여준다. 자기 하드웨어에서 모델 4개를 돌리고 클라우드도 계정도 없다는 피치의 대상이 너무 좁다는 피드백을 반복해서 받았는데, 그 이유가 "그걸 원하는 사람은 Ollama로 직접 만든다"라서다. 그래서 같은 라우팅과 심의 개념을 사용자 본인의 Claude, GPT, Grok API 키로 돌리는 방향을 저울질 중이고, 완전 오프라인이라는 차별점을 버리는 것이라 업데이트가 아니라 다른 제품이라고 스스로 규정했다.

미디어, 담론, 사고 방식

뉴질랜드 음악 산업은 9억 달러인데 국내 아티스트 점유율은 9%

Hacker News · propelmusic.co.nz

이 글의 구조가 좋다. 폐업 목록에서 시작해 "누가 이걸 취재하고 있었나"라는 질문으로 꺾는다.

2026년 6월 셋째 주, 오클랜드 Karangahape Road에서 몇 시간 간격으로 두 발표가 나왔다. 11년간 그 거리를 지킨 레코드숍 Flying Out이 끝났다고 했고, 10년치 오클랜드 전자음악 커리어를 출범시킨 지하 공연장 Neck of the Woods가 늘어나는 부채와 싸운 끝에 종료를 알렸다. 두 번째는 커뮤니티가 받아들이지 않았다. The Beths를 포함해 3,000명 가까이가 일주일 만에 Givealittle 페이지에 15만 달러를 모았고 7월에 재개장했다. 드문 승리였다. Verona는 34년 만에 4월에 청산에 들어갔고, Charlie's는 2월에, Bar Celeste는 전년에 닫았다. K Road 자체 거리 축제인 The Others Way Festival은 5월에 무기한 취소됐다.

저자의 답은 언론 붕괴가 먼저 왔다는 것이다. 공연장이 닫히기 전에 그것에 대해 쓰는 일을 하던 사람들이 이미 사라졌다. NZ Herald가 목요일 엔터테인먼트 매거진 Time Out을 운영하던 시절에는 전담 필진이 있었지만 매거진도 그 일자리도 사라졌다. 수십 년간 뉴질랜드 음악을 기록한 Rip It Up과 Real Groove는 오래전에 죽었다. 이 쇠퇴를 누구보다 철저히 기록해 2025년 Taite Award 음악 저널리즘 부문을 받은 Chris Schulz의 정리가 단호하다. 아오테아로아에 남은 음악 기자 수는 한 손으로 셀 수 있고, 이 나라 어떤 주요 매체에도 전업 음악 평론가가 남아 있지 않다. 수치도 있다. Creative New Zealand의 New Mirrors 연구에 따르면 아오테아로아 전체 미디어 보도에서 예술과 문화가 차지하는 비중은 약 13%인데 스포츠는 약 25%이고, 영화와 음악과 TV를 제외한 예술 형식은 겨우 3%다. 이건 뉴질랜드만의 특이 현상도 아니다. 세계에서 가장 영향력 있는 음악 매체 Pitchfork가 2024년 GQ에 통합되고 편집장이 해고됐다.

가장 강한 대목은 산업 지표와의 대비다. 뉴질랜드 음악 부문은 2023년 GDP에 직접 4억 5,100만 달러를 기여했고 이는 전년 3억 5,000만 달러에서 오른 것이며, 파급효과까지 세면 9억 달러가 넘는다. 라이브 공연 매출은 3억 2,900만 달러로 코로나 이전 수준을 크게 상회한다. 그런데 2024년 뉴질랜드의 스트리밍, 다운로드, 실물 판매 매출에서 국내 아티스트가 가져간 몫은 9%에 불과하다. 공식 연말 Top 50 싱글 차트에는 뉴질랜드 트랙이 정확히 한 곡 올랐다. 전국 상업 방송국 중 국내 콘텐츠 비중이 20%를 넘긴 곳은 두 곳뿐이다. 저자의 결론은 그 9%가 재능 문제가 아니라 가시성 문제라는 것이다. 34년 된 공연장이 왜 69만 2,000달러의 빚을 지고 무너졌는지를 알려주는 것이 직업인 사람이 남아 있지 않고, 아무도 기록하지 않는 씬은 보이지 않게 되며, 보이지 않는 아티스트는 스트리밍되지도 부킹되지도 돈을 받지도 못한다.

HN 토론에서 두 가지 반응이 갈렸다. 하나는 데이터 검증이다. pixelesque는 라이브 공연 매출 3억 2,900만 달러가 물가 조정치인지 물으며 일부는 티켓 가격 상승 탓일 가능성을 짚었고, 웰링턴에서 10년 살다 떠난 경험으로 2016년 지진이 건물 규정 때문에 Cuba Street의 여러 공연장을 점진적으로 닫게 했다고 덧붙였다. fidotron은 반대로 "작은 영어권 시장에서 국내 콘텐츠 비중치고는 놀랍도록 높아 보인다"고 했다. 다른 하나는 AI 슬롭 논쟁이다. mvdtnz는 "이곳 지역 음악 씬에 누구보다 열광하지만 그렇다고 그것에 관한 AI 슬롭을 읽지는 않겠다. 예술을 홍보하고 싶으면 네 말로 쓰는 것부터 시작하라"고 했고, aunty_helen은 냉소적으로 "못 읽었나. 기자들이 다 잘렸다. 이게 우리에게 남은 것"이라고 적었다. 가장 인상적인 반론은 ideasphere의 것이다. "웰링턴에 복사기로 찍은 주간 공연 가이드를 만드는 사람이 하나 있는데, 그게 이 수익형 소셜미디어 시도보다 지역 음악 씬에 더 많은 일을 할 것이다." berghoffer가 여기에 사실을 보탰다. 그건 한 명이 아니라 소규모 자원봉사 팀이고, 가이드와 주간 액세스 라디오 쇼, 무료 안내광고를 전부 자비로 운영하며, 그것이 바로 Propel이 지원하려고 존재하는 것이라고 답했다.

OpenAI 소유 팟캐스트 진행자 보수 논란 - 검증 가능한 수치는 조회수뿐

Reddit · r/OpenAI

정보량은 적지만 반응 구조가 특이해서 남긴다. 업보트 43에 댓글 80개다. 오늘 본 Reddit 글 중 업보트 대비 토론량이 가장 큰 글이고, 그 자체가 커뮤니티에서 합의되지 않은 주제라는 뜻이다.

주장은 단순하다. OpenAI가 소유한 팟캐스트 TPBN의 진행자들이 Joe Rogan에 육박하는 보수를 받는다고 알려졌는데, 청중 규모는 자릿수가 다르게 작다는 것이다. 게시자가 제시한 유일한 정량 근거는 최근 영상 5개의 평균 조회수가 1만 회 미만이라는 관찰이다. 본인은 이 팟캐스트를 챙겨 보는 사람도, 그 주변에서 오가는 논의도 본 적이 없다고 덧붙였다.

읽을 때 구분이 필요하다. 보수 규모는 게시자가 "알려진 바로는"이라고 처리했고 출처를 대지 않은 미확인 전언이다. 검증 가능한 것은 조회수 관찰뿐이다. 그럼에도 남길 이유는 있다. AI 기업이 미디어에 직접 자금을 넣는 방식과 그 효율을 두고 사용자들이 공개적으로 회의를 표하는 장면이기 때문이고, 댓글 80개는 이 회의가 소수 의견이 아니라는 지표다.

형편없는 반론을 100번 들어도 내 믿음의 확률은 오르지 않는다

Hacker News · Andy Masley

논지가 한 문장으로 요약된다. 극단적 믿음을 가진 사람이 이념적으로 무너지는 것은 나쁜 반론을 많이 들어서가 아니라, 나쁜 반론을 듣고 자기 믿음 쪽으로 확률을 올리기 때문이다.

저자가 그린 경로는 5단계다. 극단적 아이디어를 갖고, 반대하는 사람을 많이 만나고, 그 사람들이 거의 모두 기본 사실에 무지하고 단순한 윤리 문제에 대한 직관이 형편없으며 그들의 반대가 기존 사회적 정체성에 뿌리내린 것이 훤히 보이고, 따라서 내 아이디어의 비판자 대다수가 무지하고 잔인하거나 무관심하며 사회적 이유로 이 아이디어를 싫어한다고 결론 내리고, 이것이 내 아이디어가 더 옳다는 쪽으로 나를 업데이트시킨다. 저자의 주장은 잘못된 것이 오직 마지막 단계라는 것이다. 앞의 네 단계는 대체로 사실 관찰이다.

이유가 통계로 뒷받침된다. 미국 평균인은 대학을 마치지 않았고(학위 보유 37%), 절반 미만이 지난 1년간 책을 읽었으며, 3분의 2가 인플레이션이 일어나면 돈의 가치가 떨어진다는 것을 모른다. 어떤 아이디어를 갖고 있든 반대편의 평균적 대표자는 거의 항상 형편없을 텐데, 그건 반대편이 형편없어서가 아니라 평균적인 사람이 그 초특수한 주제에 대해 잘 모르기 때문이다. 저자의 비유가 좋다. 이해가 필요한 주제라면 세계는 대체로 혼란의 바다이고 그 위에 작은 이해의 섬들이 있다. 그 섬 위에 거대한 산이 솟아 있고 어떤 전망대는 다른 것보다 훨씬 높다. 자기 전망대에만 캠프를 치면 수천 마일 밖 아무것도 모르는 사람들의 바다 너머에 훨씬 더 높은 전망대가 있다는 것을 모를 수 있다.

저자 자신의 사례가 설득력을 준다. 17세에 확고한 좌파가 되어가던 무렵, 매우 보수적인 19세가 오바마가 러시아와 핵감축 협정을 맺었다고 개탄했다. 러시아도 협정의 일부로 핵무기를 없애는데 왜 나쁘냐고 물었더니 그 사람은 화를 내며 "그럼 우리는 테러리스트와 어떻게 싸우냐"고 답했다. 대화가 가치 없다고 판단하고 물러나며 "보수주의자들은 정말 멍청하다"고 생각했다. 지금은 핵무기 정책이 극도로 복잡하고 평생 연구한 전문가들끼리도 의견이 갈리며 좌우 축에 잘 매핑되지도 않는다는 것을 안다. 핵무기에 대해 아무것도 모르는 한 사람을 만난 것은 핵무기에 대해서도 좌우 정치에 대해서도 증거 0으로 셌어야 했다는 것이다. 처방은 두 부분이다. 첫째는 "약간 엘리트주의적인" 두 필터로, 상대가 논쟁 대상의 기본 사실을 아는가와 상대가 과열돼 자기 팀의 병사로 행동하려 들지 않는가다. 둘째이자 더 중요한 것은 "깨어 있음"을 자기 이념과 연결하지 말고 실제로 무엇이 참인지 알아내는 데 세심한 관심을 가진 누구나 가질 수 있는 성질로 생각하는 것이다. 저자 자신의 극단적 믿음으로 명시한 것은 동물 복지가 대부분의 사람이 믿는 것보다 훨씬 크고 시급한 재앙이라는 것이다.

HN 토론이 이 글의 약점도 짚었다. zahlman은 자기 믿음을 "극단주의"로 여기는 사람이 얼마나 되겠느냐고 물었다. 그렇게 여기지 않으면 이 경고가 자기에게 적용된다고 보지 않는다는 것이다. 또 많은 사람이 자기 토론 서클이 이미 "평균인"을 걸러냈다고 합리적으로 믿기 때문에 이념적 반대자에게 더 높은 담론 수준을 기대하는데, 그런데도 형편없으면 오히려 더 강한 증거로 느껴진다고 지적했다. miyoji의 코멘트가 가장 균형 잡혔다. 좋은 부분은 "멍청이가 나에게 반대하니 내가 옳다"의 함정을 피하라는 것이고 이는 견고한 조언이다. 멍청이도 수많은 참인 것을 믿고 천재도 헤아릴 수 없이 많은 거짓을 믿는다. "나는 내 아이디어에 대한 좋은 논증에 주의를 기울이려 하지, 좋은 논쟁자에게가 아니다"라는 문장이 저자의 처방보다 정확하다. 반면 누구의 말을 들을지에 대한 기준선은 땅바닥 아래라고 봤다. 정치 토론의 예로 든 정부 3부는 여덟 살 때도 알았지만 그때 정치에 대해 흥미로운 말을 할 수 있었다고 생각하지 않는다는 것이다. mananaysiempre는 이 논지를 LessWrong의 정식 명칭으로 정리했다. "뒤집힌 어리석음은 지성이 아니다(reversed stupidity is not intelligence)."

구조적 원인을 짚은 코멘트도 있다. stymaar는 핵심 문제가 참여(engagement)를 부양하는 소셜미디어 피드라고 봤다. 균형 잡히고 잘 사고된 코멘트는 참여를 별로 만들지 않아 알고리즘에 무시되는 반면, 터무니없이 멍청한 주장은 많은 부정적 참여를 만들고 그중 일부는 똑같이 멍청해 합리적 응답보다 더 많은 참여를 낳는다. 결국 피드에 남는 것은 최소한 일부 가치를 공유하는 멍청한 사람들이 더 멍청하다고 여겨지는 반대 견해의 사람들과 싸우는 장면뿐이라는 것이다. gibbitz는 자기 쪽 사정을 솔직히 적었다. 동의하는 사람에 대한 편향이 잘 근거한 반대 의견을 찾는 인내심을 넘어서고, 자기 버블에서는 관찰되지 않은 선험적 믿음이나 허수아비 논증에 기반하지 않은 반대 관점을 찾기가 꽤 어렵다는 것이다.

40시간 인터뷰해서 5% 미만을 쓴다 - 나머지 95%가 낭비가 아니라 요점이다

Hacker News · startingfromnix.com

이 에세이가 남을 이유는 창작과 커리어 전환에 관한 구체적 수치와 인용이 있기 때문이다.

시작은 측정 가능한 명제다. 내적 일치도(internal congruence)는 욕구와 행동 사이의 시차로 잴 수 있다. 삶의 무언가를 바꾸고 싶어하면서, 때로는 몇 년간 비밀스러운 욕망을 품고도 제자리에 머무는 사람들이 있다. 다른 이들은 즉흥적으로 삶을 뒤엎고 다시 시작한다. 차이는 후자가 경험 자체를 목표로 본다는 것이다. 경험이 목표라면 과정에서 무슨 일이 일어나든 항상 이긴다. 배경에는 저자 자신의 전환이 있다. 자기 글의 관심이 자기 마음의 움직임을 기록하는 것에서 다른 사람들과 함께 그리고 그들에 관해 쓰는 쪽으로 옮겨가고 있다는 낌새를 느꼈고, 어떤 영역에서든 나이가 들고 경험이 쌓이면 자기 역량 범위 안에 머물며 소용돌이를 깊게 파는 것에 보상이 주어지는데 그것이 숨 막혔다는 것이다.

Miles Davis가 반례다. Simon Drew의 에세이 "The Miles Method"를 인용해, Davis가 bebop과 cool jazz와 modal jazz로 이어지는 재즈의 거대한 변혁 아치에 기여했다고 정리한다. Drew의 문장은 "그는 이미 연주한 것을 연주하는 데 관심이 없었고, 만약 관심이 있다면 그것을 재구성할 참이었다"이다. Davis는 옛 스타일을 결코 움켜쥐지 않아 콘서트에서 옛 음악 연주를 거부하기도 했고, modal jazz를 무기한 원하던 원래 팬층 상당수를 소외시켰다. 1970년대의 여러 음반은 록과 재즈 평론가들에게 혐오받고 조롱당했다가 나중에 예언적이었다고 재평가됐다. Davis 자신의 말이 핵심 인용이다. "만약 내가 나 자신의 팬이라면, 그리고 나는 그렇다, 1960년에 내가 한 것처럼 보이는 어떤 것도 듣고 싶지 않을 것이다. 둘 다 할 수는 없다. 60년대와 70년대는 끝났다. 1984년이고 곧 1985년이 된다. 무엇이든 가능하다." 자주 인용되는 다른 문장은 "나처럼 연주하는 법을 배우는 데 몇 년이 걸렸다"이다.

두 번째 장치는 waste book이다. Georg Christoph Lichtenberg는 Sudelbücher, 즉 "낙서장"이라 부른 노트에 생각과 아포리즘을 비공식적으로 적었다. Lichtenberg의 설명이 그대로 방법론이다. 상인은 매일 사고파는 모든 것을 순서 없이 지저분하게 적는 waste book을 갖고 있고, 거기서 모든 것이 더 체계적으로 보이는 journal로 옮겨지며, 마지막으로 이탈리아식 복식부기 원장으로 가서 각 사람과 채무자로 한 번, 채권자로 한 번 계산을 정리한다. 이것은 학자들이 모방할 만하다는 것이다. 여기에 저자의 실측이 붙는다. 한 회사에 관한 최신 에세이를 위해 함께 지낸 팀을 최소 40시간 인터뷰했고 인터뷰이 1인당 거의 1시간이었다. 내부 문서와 Slack 메시지, 전략 메모와 엔지니어링 아티클을 전부 읽었다. 최종 원고에 쓴 것은 전체 원자료의 5% 미만이다. 그렇다고 원자료가 허공으로 사라지는 것은 아니다. 뇌에 박혀 세계를 항해하는 새로운 방식이 되고 미래의 개념을 이해하는 데 재활용할 어휘와 지식 기반이 된다. 창작자들의 자기 의심 사례도 곁들인다. Steinbeck은 자기가 독자를 속이고 있을 뿐이라고 생각했고, Kafka는 머릿속의 "엄청난 세계"를 한탄하면서 그중 아무것도 쓰지 못했으며, Woolf는 자기 대표작들을 "빈약하다"고 불렀다.

세 번째는 Cate Hall의 『You Can Just Do Things』다. 주체적인 사람들이 갖는 "항해적 능숙함"은 타고난 마법적 특질이 아니라 올리고 내릴 수 있게 학습 가능한 것이라는 주장이다. 방법 하나가 "낮은 지위의 해자를 받아들이기"다. 자아를 작게 유지하고 자신이 시대에 뒤떨어지고 촌스럽고 크린지해 보이도록 허용하는 것이다. 어떤 기술 습득이든 근본적으로 단기 페널티를 수반한다. 패를 잘못 치고, 조율 안 된 춤을 추고, 앞뒤 안 맞게 쓴다. 그리고 이 해자는 새로운 것을 배울 때만이 아니라 좋은 수준에서 훌륭한 수준으로 갈 때도 존재한다. Hall의 정의는 이렇다. "주체성의 다른 말은 기회주의다. 인생 경로에서 벗어날 잠재적 우회로가 나타났음을 알아차리는 민감성, 그것을 추구할 방법을 생각해내는 창의성, 그리고 '뭐, 최악이 뭐겠어?'라고 말하는 용기." HN 반응 중 lnenad가 단 단서가 중요하다. 가지면 좋은 마인드셋이지만 자기 감정을 통제할 수 있다는 전제에서만 그렇다는 것이다.

"이명과 친구가 되라"는 확립된 치료법의 요약인데, 당사자에게는 "그냥 행복해져"로 들린다

Hacker News · myNoise.net

원문은 영상이라 다이제스트 가치는 전적으로 스레드에 있는데, 이 스레드가 "수용 기반 접근"에 대한 커뮤니티 반응의 좋은 표본이다.

첫 반응이 대표적이다. A_D_E_P_T는 "다 좋은데 이명을 앓는 사람들은 '그냥 태도를 바꿔라'라는 말을 들으면 상당히 화를 내는 경향이 있다. 이미 100번은 들어보지 않은 사람이 없고, 그렇게 쉽지 않다"고 적었다. zdragnar는 30년째 여전히 5/10이라며 "우울증 있는 사람에게 '그냥 행복해져'라고 하는 끔찍한 조언 같다"고 했다. Sindisil은 35-40년째 겪으며 "이명은 절대 내 친구가 아니다"라고 했다.

그런데 Barrin92의 코멘트가 논의의 층위를 바꾼다. 저자가 옹호하는 "이명과 친구 되기"는 확립된 치료 형태, 즉 수용전념치료(ACT)이고 일반적으로 매우 효과적이라는 것이다. 이유는 회피나 보상 행동, 그러니까 이명을 없애려 하거나 주의를 딴 데로 돌리는 행동이 뇌에 이명이 문제라고 가르쳐 이명에 집중하게 만드는 종류의 경계심을 키우기 때문이다. 불면증도 같은 구조여서, 잠들려는 노력을 하는 사람들이 오히려 불면증을 악화시키므로 "깨어 있음과 친구가 되어야" 한다는 것이다. y1n0의 서술이 그 실천을 정확히 묘사한다. "친구로 삼지는 않지만 알아차렸을 때 알아차렸음을 인정하고 하던 일로 돌아간다. 결국 며칠이나 몇 주 뒤에 다시 알아차리고 그 사이에 전혀 알아차리지 않았음을 깨닫는다."

의학적 사실도 정리된다. 효과적인 약이 아직 없고 리도카인은 실제로 효과가 있지만 매우 일시적이다. 최소한 사후 신경 손상을 제한하는 조치(고막내 스테로이드 등)가 있는데도 자주 놓치고 아직 일상 절차가 되지 않았다는 지적이 나왔다. 경과의 다양성도 남길 만하다. A_D_E_P_T는 10년에 걸쳐 5/10에서 1/10로 나아졌다. 5/10은 주변 소음 위로 매우 성가시고 눈에 띄지만 무력화 수준은 아닌 상태이고, 1/10은 아주 조용한 방에서 잠들려 할 때 아니면 들리지도 않는 상태다. 반면 zdragnar는 30년째 5/10 그대로다. gerdesj의 제안이 이 스레드의 결론에 가깝다. "이명 스펙트럼을 다차원으로 두자고 주장해야 할 것 같다. 단일 데이터 포인트에서 나온 조언은 별로 도움이 되지 않는다."

기타 주목할 콘텐츠

폴란드가 EU 6위 경제로 - GDP 9,229억 유로, 실질 성장률 3.6%

Hacker News · Euronews

Eurostat 데이터에 따르면 2025년 폴란드의 경상가격 GDP는 9,229억 유로로 EU 전체 경제의 4.9%를 차지했다. 경제 규모에서 폴란드보다 위에 있는 나라는 독일, 프랑스, 이탈리아, 스페인, 네덜란드뿐이고 벨기에, 스웨덴, 아일랜드, 오스트리아를 앞질렀다. 상위권을 함께 두면 격차가 보인다. 독일이 4.47조 유로로 EU 전체의 23.8%이고, 프랑스 2.99조(15.9%), 이탈리아 2.26조(12%), 스페인 1.69조, 네덜란드 1.17조 순이며 EU 27개국 합계는 약 18.8조 유로다. 중동유럽에서는 폴란드가 압도적이다. 2025년 루마니아가 3,801억 유로, 체코가 3,473억 유로, 헝가리가 2,188억 유로다.

성장률 차이도 크다. 2025년 폴란드 실질 GDP는 3.6% 늘었고 EU 전체는 1.5% 성장했다. 단서가 하나 붙는다. 경제 규모가 크다고 거주자가 부유한 것은 아니다. 1인당으로 계산하면 폴란드는 여전히 EU 평균 아래이고 2025년 1인당 GDP가 EU 평균의 85% 미만이다. 원문 제목의 "스위스"는 오류로 보인다는 지적도 나왔다. 스위스는 EU 회원국이 아니고 본문이 스웨덴과 벨기에를 언급하므로 Sweden을 잘못 쓴 것이라는 관찰이다. HN 토론에서는 원인 논쟁이 붙었는데, EU 자금 규모를 두고 dinfinity가 숫자로 답한 것이 참고할 만하다. EU 자금은 2025년 폴란드 GDP의 약 1%p 규모였고, 정부 지출도 많아 2025년 재정적자가 GDP의 7%였으며, 최저임금은 2025년 1월에 약 10% 인상됐다는 것이다.

김밥 프랜차이즈 매장 수가 브랜드를 가리지 않고 줄었다

LinkedIn · SNEW스뉴

AI와 무관하지만 수치가 전부 붙어 있어 소비 지표로 인용 가치가 있다. 가격 축에서는 2017년 평균 2,000원대이던 김밥이 2026년 3,5004,000원까지 올랐다. 참치 김밥이나 치즈 김밥처럼 재료가 더 들어가는 메뉴는 5,0006,000원 선이다. 10년이 안 되는 기간에 기본 메뉴 가격이 두 배 가까이 오른 셈이다.

공급자 쪽 사정도 나쁘다. 김밥은 손이 많이 가는 음식이라 인건비 부담이 큰 편이고, 여기에 '검은 반도체'로 불릴 만큼 오른 김 가격과 당근, 오이, 참기름 같은 필수 식재료 원가 상승이 겹쳤다. 가격을 올려도 마진이 남지 않고, 올린 가격 탓에 수요는 줄어드는 협공이다. 결과는 매장 수로 나타났다. 김가네가 448개에서 378개로, 고봉민김밥이 541개에서 400개대로, 바르다김선생이 125개에서 94개로 줄었다. 고급화 전략을 내세우던 브랜드와 대중 브랜드 양쪽에서 동시에 감소가 나타났다는 점이 특징이다. 특정 브랜드의 전략 실패가 아니라 업태 전반의 원가 구조 문제라는 해석을 뒷받침한다.

교차 분석

오늘 하루치를 관통하는 명제는 "모델이 아니라 하네스"다. 특이한 것은 이 명제의 증거가 네 층으로 동시에 쌓였다는 점이다. 연구에서는 Harness-R1이 백본을 그대로 두고 +9.3%p를 만들었고, 벤치마크에서는 DataSpace가 백본 고정 상태로 하네스만 바꿔 15.36%p 격차를 보였으며, 사내 프로덕션에서는 Meta가 L1/L2/L3 계층과 에이전트 번들링으로 같은 결론에 도달했고, 제품에서는 세션 목표와 durable execution이 그 결론을 인터페이스로 굳혔다. 그런데 같은 날 "그 제품들이 실제로는 로그인도 안 된다"는 반증이 나란히 올라왔다. 연구 신호가 강할수록 제품 신호와의 간극도 같이 벌어진다는 뜻이고, 두 신호를 함께 읽지 않으면 어느 쪽으로든 과대평가하게 된다.

두 번째 축은 "조용히 틀리는 것"이다. 이번 주 커뮤니티의 불만은 환각이 아니라 성공했다고 보고한 뒤 조용히 틀리는 것이었다. Cursor가 폼 필드를 하드코딩하고 같은 storage key를 덮어썼다는 보고, 에이전트가 컨테이너를 지워 100시간을 날린 사례, 사람이 읽을 수 없는 보고서가 그것을 왜 못 잡는지에 대한 설명이 하나의 서사를 이룬다. 처방도 같은 방향에서 나왔다. 컨테이너는 보안 샌드박스가 아니라는 지적과 gVisor의 syscall 격리, 게이트웨이 계층의 지출 한도와 PII 마스킹, MCP 프록시와 RLS 스캐너까지, 전부 "에이전트 바깥에서 판정한다"는 공통 설계를 갖는다. 자기 채점하는 에이전트를 믿지 않는다는 전제가 이날 도구들의 최대공약수다.

세 번째 축은 비용이다. 토큰 지출을 표준으로 세려는 재단이 생겼고, 컨텍스트를 통째로 덧붙이는 방식의 제곱 비용이 문제로 지목됐으며, 사용자 쪽에서는 한도 소진 체감과 그것을 우회하는 워크플로가 동시에 보고됐다. 여기에 로컬 스택이 유료 API를 앞선 지점이 구체적 수치로 나왔다는 것이 겹친다. 능력 격차가 좁혀지는 구간에서는 선택 기준이 성능에서 단가와 통제권으로 넘어간다.

네 번째 축은 물리적 비용이다. 데이터센터 하나에 붙는 7.65GW 가스 발전소와 독일 뒷마당의 800W 인버터 수십만 개가 같은 날 잡혔고, 규모의 대비 자체가 논평이 된다. 소프트웨어 쪽에서도 같은 대비가 반복됐다. 일기예보만 띄우는 앱이 RAM 1.5GB를 쓰는 동안, 커널 80,486바이트가 256KB에서 12개 작업을 선점형으로 돌린다. 새 인프라를 얹기 전에 이미 있는 것을 다시 보라는 Shopify의 교훈이 그 사이에 놓인다.

마지막으로 담론 쪽에서 한 가지 현상이 반복됐다. 서로 무관한 세 편의 글이 같은 날 "AI가 썼다"는 지적을 받았고, 세 경우 모두 "그래서 내용이 틀렸나"에 대한 답은 나오지 않았다. 문체 탐지가 커뮤니티의 기본 반응이 됐다는 뜻인데, 같은 날 AI 산출물의 정확성 주장이 두 번 무너진 것과 함께 읽으면 방향이 분명해진다. 검증의 부담이 생산자에서 독자로 넘어갔고, 독자가 쓸 수 있는 도구는 아직 문체 직감뿐이다.

Powered by skim