Daily Digest - 2026-08-18

하네스가 제품이 되고 가드가 벤치마크가 된 날. 컴팩션이 비용을 늘린다는 실측, Claude의 모델 레벨 워터마킹 개시, GitHub 장애가 드러낸 소셜 레이어 공백, 메모리 가격 500% 상승까지.

Daily Digest - 2026-08-18

오늘의 핵심 흐름

오늘 가장 크게 움직인 줄기는 에이전트를 잘 쓰는 법에서 에이전트가 넘을 수 없는 구조를 파는 법으로 논의가 통째로 옮겨갔다는 것이다. Deno의 Ryan Dahl은 자기 에이전트에게 데이터베이스 접근을 맡기면서 "Opus는 위험한 요청을 거부하지만 그것으로는 불충분하다"고 못 박고, HTTP보다 아래 계층에서 Postgres 와이어 프로토콜을 직접 파싱해 차단하는 1,000줄짜리 규칙을 짰다. 같은 날 훅 계층에서 rm -rf를 끊는 Doberman이 나왔고, opencode 플러그인 yaop은 리뷰 에이전트의 edit 권한만 막는 데 그치지 않고 permission.task까지 자기 소유 서브에이전트 세 개로 못 박아 우회 경로를 닫았다. 그리고 이 흐름의 정점에 holdline이 있다. 가드를 (commitments, action) -> block? 함수로 표현하면 어떤 가드든 채점하는 벤치마크인데, 저자의 문장이 이 날의 요약에 가깝다. "가드의 README에 '위험한 명령을 차단합니다'라고 적힌 건 증거가 아니다. 이 하네스가 증거다." 반대 증거도 같은 날 나왔다. Wiz의 레드팀 에이전트가 Snowflake 저장소의 워크플로 결함을 파고들어 Jira 자격증명에 닿았는데, 그 PR을 리뷰한 Copilot은 "문제없다"고 판정했다.

두 번째 줄기는 컨텍스트를 줄이는 게 비용을 줄이지 않는다는 실측이다. 500600달러어치 API 호출로 검증한 발표에 따르면, 대화 전체를 매번 그대로 보내는 것이 요약해서 보내는 것보다 쌌다. 프롬프트 캐시 할인이 최대 50배라 캐시 적중률 97%를 유지하는 full history가 토큰을 가장 많이 보내면서도 총비용이 가장 낮았고, 손익분기점은 "50배로 압축할 수 있을 때"였다. 정확도 쪽은 더 갈렸다. 멀티턴 회수율이 전부 유지에서 95%, 요약에서 32%였다. 발표자의 결론은 한 줄이다. "기본값으로 컴팩션하지 말라." 여기에 붙는 것이 평가의 문제다. Terminal Bench 2에서 모델을 손대지 않고 타임아웃만 늘렸더니 점수가 1415퍼센트포인트 올랐다는 사례, 그리고 Sparse Attention 논문의 벤치마크를 원하는 대로 만드는 방법을 저자 본인이 공개한 글이 같은 날 올라왔다. 슬라이딩 윈도만 써도 5~10배 속도 향상을 보고할 수 있고, RULER 13개 태스크 중 6개가 사실상 같은 needle-in-a-haystack이며, AIME는 30샘플이라 80 대 79를 볼드 처리할 수 있다는 것이다.

세 번째 줄기는 AI가 쓴 글을 누가 어떻게 가려내는가다. 2026년 8월부로 Claude 신규 모델이 모델 레벨에서 텍스트를 워터마킹하기 시작했다는 사실이 정리 글을 통해 다시 조명됐다. 마크는 글자가 아니라 단어 사이의 선택에 살고, 탐지는 텍스트를 읽지 않고 키로 색을 다시 칠해 초록 비율을 세는 일이다. 다만 이 방식의 실용 임계는 냉정하다. 1,500단어 문서가 겨우 55% 초록에서 플래그되고, 의미부터 다시 쓰는 재구성을 거치면 원래 표현의 window가 0.5%만 살아남아 AUC가 0.99에서 0.5로 무너진다. 반대편에서는 사람의 감별이 언어마다 다른 단어에 걸린다는 관찰이 나왔다. 일본어에서는 実務, 帳簿, 効く, 刺さる가 영어권 "delve"의 자리에 있다는 것이다. 그리고 셋째 태도가 같은 날 이름을 얻었다. AI;DR, 즉 AI; Didn't Read다. "검토하고 편집할 만큼 신경 쓰지 않았다면 나도 읽지 않겠다"는 한 줄 정책인데, 판별 이전에 거절하겠다는 선언이다. 이 태도가 우스개가 아니라는 건 반대 방향 증거가 증명한다. 이스라엘 정부 예산으로 운영된 가짜 싱크탱크가 챗봇 답변에 원하는 서사를 심으려 100건 넘는 글을 쏟아냈고, GPTZero는 그중 12건을 검사해 11건을 AI 생성으로 판정했다.

네 번째 줄기는 AI 지출이 다른 자원을 밀어내는 그림이 층층이 확인됐다는 것이다. 가장 직접적인 건 메모리다. 128GB 키트가 1년 사이 10배로 올라 3,399달러가 됐고, 유럽에서는 345% 상승이 관측됐다. 2027년 DRAM 생산능력을 대형 사업자가 선점하고 있고, Stargate 한 곳이 40%를 잡아뒀다는 이야기까지 붙었다. 자본시장에서는 30년물 미국 국채 금리가 5.311%로 2007년 6월 이후 최고를 찍었는데, 소매판매가 마이너스로 나온 날에 장기 금리가 올랐다. 바클레이즈는 원인으로 인플레이션이 아니라 재정적자와 기간 프리미엄, 그리고 AI 관련 채권 발행이 국채와 같은 투자자 풀을 놓고 경쟁한다는 점을 꼽았다. 연구비 쪽에서도 같은 신호가 나왔다. AI와 무관한 데이터베이스 연구자들이 자금을 찾아 커뮤니티 포럼에 매칭 스레드를 열었고, 스레드 작성자가 밝힌 이유가 "비AI 영역 자금이 AI 지출 때문에 크게 감소했기 때문"이었다. 그 스레드가 올라온 바로 다음 날 DuckDB는 1만 개 넘는 커밋을 쌓은 v2.0 프리뷰를 공개했고, 그중 재귀 CTE 40배 가속 같은 성과는 수십 년 데이터베이스 연구의 직접적 산물이다.

마지막 줄기는 인프라의 기본값이 흔들린 하루였다. GitHub이 다시 멈췄고, 상태 페이지는 그 사실을 제때 말하지 않았다. 흥미로운 건 그 장애가 만든 논의가 "어디로 옮길까"가 아니라 "옮길 데가 없다"였다는 점이다. git 저장소를 호스팅할 곳은 많지만 오픈소스 커뮤니티를 호스팅할 곳은 드물고, Ghostty처럼 저명한 프로젝트조차 명백한 기본 이전지가 없어 상용과 FOSS 사업자를 하나씩 물색해야 했다. 같은 날 Cursor는 자기 제품 안에 저장소 호스팅을 넣은 Origin을 열었는데, GitHub 장애 몇 시간 뒤였다. 그리고 로컬 쪽에서는 17GB짜리 오픈웨이트 27B 모델이 노트북에서 코딩 에이전트 루프를 완주했다. 다만 기본 추론 강도가 xhigh로 잡혀 있어 원 하나 그리는 데 몇 분을, 자전거 탄 펠리컨 SVG 하나에 21분과 추론 토큰 22,276개를 태웠다. 추론을 끄면 같은 프롬프트가 137초에 끝난다. 성능이 아니라 기본값이 문제였다는 이 관찰이, 오늘 하루 반복해서 나온 주제를 정확히 요약한다. 도구는 이미 강한데 그 도구를 어디까지 풀어놓을지에 대한 기본값이 아직 아무도 정하지 못했다.

하네스가 제품이 됐다 - 프리셋, 라우터, 스킬

DeepSeek Harness와 프리셋 - "Everything is a plugin"

LinkedIn · Jeongmin Lee, Stanislav Beliaev

8월 13일 공개된 DeepSeek Harness(dsh)가 45일 만에 GitHub 스타 145,000150,000개를 모았다는 집계가 돌았다. 숫자 자체는 게시자가 센 값이라 그대로 옮기되, 중요한 건 속도가 아니라 이 도구가 도입한 어휘다. dsh의 설계 원칙은 "Everything is a plugin"이고, 프로젝트 루트의 cordis.yml 한 장이 어떤 플러그인을 어떤 순서로 얹을지 결정한다.

핵심 개념이 Preset이다. Standard, Code, Minimal, Creator 네 종이 기본으로 오는데, 프리셋은 프롬프트 묶음이 아니라 "이 작업에서 어떤 도구와 규칙이 활성화되는가"를 정의하는 실행 프로필이다. 게시자가 강조한 구분이 이것이다. Skill은 에이전트가 특정 상황에서 꺼내 읽는 절차 문서이고, Preset은 세션 전체의 기본 사양이다. 둘을 섞으면 스킬을 프리셋처럼 상시 로드해 컨텍스트를 태우거나, 반대로 항상 필요한 규칙을 조건부 스킬에 묻어 놓치게 된다.

정리 게시물이 반복해서 강조한 문장은 AGENT = MODEL + HARNESS다. 같은 모델도 하네스가 다르면 다른 에이전트라는 것이고, 그래서 모델 벤치마크만 보고 도구를 고르면 실제 성능과 어긋난다는 논지다. 내부 스킬 3종과 .agents/notes/ 디렉터리를 통해 세션 밖 메모를 남기는 구조도 함께 소개됐다.

주의할 점은 dsh가 아직 developer preview라는 것이다. 공식 문서에 breaking change가 언제든 있을 수 있다는 경고가 붙어 있어서, 프로덕션 자동화의 기반으로 삼기 전에 버전 고정을 먼저 해야 한다.

하네스도 라우팅한다 - HarnessRouter와 Unified Harness Protocol

Hacker News · Kuanze (HarnessRouter)

앞 항목이 "하네스가 갈아끼울 수 있는 것"이라는 전제를 만들었다면, HarnessRouter는 그 전제를 프로토콜로 굳혔다. Docker 이미지 한 장 안에 Codex, Claude Code, Hermes를 넣되 라이선스 문제 때문에 이미지에 미리 담지 않고 컨테이너 첫 실행 시점에 설치한다. 그 위에 Unified Harness Protocol(UHP) 2026-08-11 스펙 10장이 얹혀, 어떤 하네스든 같은 요청 형태로 부를 수 있게 만든다. 외부 인터페이스는 OpenAI Responses 호환이라 기존 클라이언트를 대부분 그대로 쓴다.

같이 온 스타터 킷이 네 종이고, 그중 Dashboards가 설계 판단을 잘 보여준다. 생성된 SQL을 SELECT 전용으로 제한하는 데 그치지 않고 READ ONLY 트랜잭션 안에서 실행한다. 문자열 검사로 막는 게 아니라 데이터베이스 엔진이 강제하게 만든 것이다.

운영 관점의 경고도 문서에 그대로 있다. 0.1.x0.2.0에는 로그인 게이트가 없어서 노출된 인스턴스가 곧 열린 실행 권한이다. 스트리밍이 버퍼링돼 끊기는 문제는 Caddy의 flush_interval -1로 푼다. 그리고 push는 단방향이라 양쪽을 동기화하는 용도로 쓰면 안 된다.

HN에서 Bnjoroge가 던진 반론이 이 카테고리의 진짜 질문이다. "codex app server가 이미 있는데 왜 또 한 층이 필요한가." 답은 결국 하네스를 여러 개 굴리는 조직이 실제로 있느냐에 달려 있는데, 오늘 하루치 항목만 봐도 그런 조직이 늘고 있다는 정황은 뚜렷하다.

Claude Code v2.1.234 - 경로 우회 차단과 스킬 200k에서 25k로

GitHub Releases · anthropics/claude-code

이번 릴리스에서 보안 항목 하나가 눈에 띈다. Windows의 \??\ 접두사 경로를 거부하도록 바뀌었다. 이 표기는 NT 오브젝트 매니저 네임스페이스로 바로 들어가는 경로라, 애플리케이션 레벨의 경로 검사를 우회해 UNC 경로로 흘러가고 결국 NTLM 인증 정보를 외부 호스트에 흘리는 벡터가 된다. 파일 경로 화이트리스트만 믿는 도구가 흔히 놓치는 자리다.

효율 쪽 변경도 있다. claude-api 스킬이 200k 토큰이 넘던 것에서 25k로 줄었다. 스킬 하나가 컨텍스트의 상당 부분을 먹고 있었다는 뜻이고, 앞 항목의 "스킬과 프리셋을 구분하라"는 조언이 왜 실무 문제인지 보여준다. MCP 진단 출력에 시크릿이 섞여 나오던 문제와, 서브에이전트가 권한 요청에 대한 응답을 받지 못하고 유실하던 버그도 함께 고쳐졌다.

/goal 기능에는 두 가지 동작이 붙었다. 목표를 달성하면 자동으로 해제되고, 30분마다 체크인이 들어온다. 장시간 세션에서 목표가 조용히 낡는 문제를 도구 쪽에서 다루기 시작한 것인데, 오늘 별도로 다룰 Engelbart와 같은 문제 인식이다.

Claude Code /design research preview

X · @ClaudeDevs

/design 슬래시 커맨드가 research preview로 열렸다. 게시물은 좋아요 4,873에 댓글 180개를 모았다. 성격은 신규 발명이라기보다 이식인데, Claude Design의 아트보드 워크플로를 CLI와 Desktop으로 가져온 것이고 artifacts 위에 구현됐다.

사용 흐름이 짧다. /design을 실행하면 UI 후보 아트보드를 편집 가능한 형태로 여러 개 받고, 그중 하나를 골라 수정한 뒤 구현으로 넘긴다. 시안을 이미지로 받아 다시 설명해야 하는 단계가 빠지는 것이 핵심이다. 앞서 본 컨텍스트 논의와 겹쳐 보면, 화면을 스크린샷으로 주고받는 대신 구조화된 아트보드를 주고받는 쪽이 토큰과 오해를 동시에 줄인다.

같은 날 실사용 사례가 하나 돌았다. 컨셉 앱 Shelf(읽은 책을 수집하고 기록하는 개인 책장 서비스)를 만든 흐름인데, 컨셉과 기능을 먼저 정리하고 Claude Design으로 화면을 만든 뒤 Figma로 다듬는 순서였다. Figma에서 시작해 코드로 가는 통상적 순서가 뒤집힌 것이다. 디자인 도구가 출발점이 아니라 정리와 협업의 종착지가 되는 배치인데, 팀 프로세스 관점에서는 핸드오프 규약을 먼저 정하지 않으면 누가 어느 시점의 화면을 정본으로 볼지가 흐려진다.

SKILL.md 380만 개 - 레지스트리 없이 퍼진 포맷

LinkedIn · DAIR.AI

GitSkills가 공개 저장소를 훑어 집계한 수치가 나왔다. SKILL.md 파일이 저장소 282,200곳에 3,800,000개 존재하고, 내용 기준 중복을 제거하면 1,877,981개다. 절반가량이 복사본이라는 뜻이다. 수집 결과는 SQLite 한 파일로 배포된다.

집계 시점이 의미를 더한다. Anthropic이 이 포맷을 오픈 스펙으로 공개한 지 9개월이다. 9개월 만에 28만 개 저장소로 퍼졌다는 뜻이다.

이 규모에서 눈여겨볼 것은 없는 쪽이다. 레지스트리도 패키지 매니저도 없다. npm이나 PyPI 같은 중앙 색인 없이 폴더를 저장소 사이에 복사하는 방식으로 퍼졌고, 그래서 버전도 의존성도 신뢰 경로도 없다. 앞선 Claude Code 릴리스에서 스킬 하나가 200k 토큰을 먹고 있었다는 사실과 겹쳐 보면, 이 생태계가 아직 크기와 품질을 관리할 도구를 갖지 못했다는 그림이 된다.

연구 관점에서 더 어려운 지적도 붙었다. 스킬에는 기존 소프트웨어 마이닝 기법이 잘 먹히지 않는다. 자연어로 쓰이고, 런타임에 에이전트가 확률적으로 고르며, 컴파일러나 타입 체커가 그 선택을 검증하지 않는다. 코드였다면 정적 분석으로 잡을 수 있는 문제가 스킬에서는 실행해봐야만 드러난다. 오늘 별도로 다룬 holdline이 "README에 적힌 건 증거가 아니다"라며 가드를 실행해 채점한 이유도 같은 자리에 있다.

실제 활용 사례도 함께 돌았다. GBrain은 Codex와 Claude Code용 개인화 에이전트를 만들어주는데, 질문 12개에 답하면 SOUL.md를 생성하고 제작자 본인의 개인 에이전트 스킬 70개를 설치한다. Threads에서는 세일즈 프레임워크 6종(Dale Carnegie, Russell Brunson, Grant Cardone, Zig Ziglar, Jordan Belfort, Alex Hormozi)을 각각 스킬로 옮겨 콜 녹취만으로 세일즈 분석을 돌리는 구성이 공개됐다.

가장 재사용 가치가 높은 것은 할루시네이션 차단을 3단계 스킬로 나눈 사례다. 1단계에서 근거로 쓴 페이지와 라인 넘버를 명시한 초안을 만들고, 2단계에서 그 초안을 원문과 대조 평가하고, 3단계에서 틀린 것을 고쳐 검증된 최종 답변만 출력한다. 오늘 다룬 법률 인용 검증 논문이 "모델이 확인했다고 지어낸다"고 보고한 실패 유형에 대한 실무적 대응이 정확히 이 구조다. 생성과 검증을 같은 호출 안에 두지 않고 단계로 분리한 것이다.

효과의 방향을 보여주는 수치가 별도 보도에 있었다. 스킬이 **절차를 앵커링할 때 65.7%**의 개선을 보이는 반면 **사실을 주입할 때는 4.5%**에 그쳤다. 스킬은 "무엇을 알아야 하는가"보다 "어떤 순서로 해야 하는가"를 담을 때 값이 나온다는 이야기다.

모노레포에서 에이전트 스킬을 쓰는 6원칙

Reddit · r/AI_Agents haasilein

앞 항목이 규모를 보여줬다면 이 글은 관리 방법이다. 게시물 자체는 TLDR 6줄이 전부이고 본문은 외부 아티클로 넘기는데, 그 6줄이 지금 여러 곳에서 반복 확인되는 결론과 정확히 겹친다.

앞의 두 원칙은 컨텍스트 예산 문제다. 전역적으로 발견 가능한 컨텍스트를 최소화하고, 전문화된 컨텍스트는 지연 로딩한다. 대형 모노레포에서 모든 규칙과 문서를 항상 로드하면 토큰 예산이 소진될 뿐 아니라 모델의 주의가 분산돼 정작 중요한 지시를 놓친다. 앞 항목에서 본 claude-api 스킬이 200k 토큰을 먹고 있었다는 사실이 이 원칙이 왜 실무 문제인지를 보여준다.

세 번째 원칙은 성격이 다르다. 결정론적 연산은 설명이 아니라 실행 가능하게 만든다. "이 순서로 파일을 옮기고 이 명령을 실행하라"고 문서에 적어두는 대신 스크립트로 만들면, 모델이 매번 절차를 재구성하다 실수할 여지가 사라진다. 오늘 별도로 다룬 Dirge가 괄호 불일치를 모델에 되돌려주지 않고 하네스 안에서 기계적으로 고친 것과 같은 판단이다.

나머지 셋은 검증 쪽이다. 에이전트 산출물을 특별 취급하지 말고 린트와 테스트와 CI 같은 기존 엔지니어링 도구로 강제할 것, 직관에 기대지 말고 실제 에이전트 행동을 측정할 것, 그리고 궁극적으로는 스킬을 태스크 결과 기준으로 평가할 것이다. 마지막 두 항목은 같은 날 나온 RAG 논의의 "eval set만은 뺄 수 없다"를 스킬 층위에서 반복한 것이다.

이 목록의 배치 가치는 바로 뒤에서 다룰 "프롬프트 엔지니어링은 상식의 재포장인가" 논쟁과의 대비에 있다. 컨텍스트 로딩 전략, 결정론적 작업의 코드화, 행동 측정 같은 것들은 "명확하게 말하기"로 환원되지 않는다. 개인이 한 대화에서 잘 지시하는 능력과 조직이 재현 가능한 에이전트 행동을 만드는 능력이 다른 문제라는 점이 두 글을 나란히 두면 드러난다. 참고로 원 게시물 자체는 4업보트에 댓글 4개로 반응이 크지 않았다.

OmO(oh-my-openagent) 베타8이 Grok을 받았다

Threads · @yeon.gyu.kim

오픈소스 CLI 에이전트 OmO(oh-my-openagent)가 베타8에서 Grok 공식 지원을 예고했다. 할인 요금제로 산 Grok 구독을 그대로 붙여 쓸 수 있게 된다는 것이 실사용자들이 주목한 대목인데, 앞서 본 Grok 구독 가격 논의와 곧바로 이어진다. 할인 이벤트 기간에 툴 체인을 그쪽에 맞추는 움직임이고, 모델 구독과 CLI 도구가 서로를 끌어당기는 구조다. 설치는 npm install -g omo-ai@beta 또는 bun install -g omo-ai@beta이고 저장소는 code-yeongyu/oh-my-openagent다.

짧은 소식이지만 방향은 분명하다. 하네스가 특정 모델 제공사에 묶이지 않는 계층으로 자리 잡고 있어서, 모델 추가가 곧 릴리스 노트의 머리 항목이 된다. 앞서 본 HarnessRouter가 프로토콜 수준에서 하려는 일을 개별 도구가 각자 하고 있는 셈이다.

같은 계열의 다른 게시물은 Aside라는 도구를 두고 비슷한 주장을 편다. 가성비 모델 DeepSeek API부터 Grok까지 온갖 모델이 붙고 CLI를 연결하면 할 수 있는 것이 매우 많은데 별로라고 느낀다면 활용법을 모르는 것이라는 논지다. 근거보다 단정이 앞선 글이라 주장 자체보다는 여러 모델을 갈아 끼우는 CLI 프런트엔드라는 카테고리가 한국 커뮤니티에서 형성되고 있다는 신호로 읽는 편이 맞다.

개발자가 명시적으로 수익화 의도가 없다고 선을 긋고 이슈 제보를 요청한 점도 함께 기록해둔다. 오늘 다룬 nodeterm이 사용량은 늘었는데 유지 비용을 감당할 스폰서를 찾고 있다고 밝힌 것과 대조적인데, 개인이 만든 에이전트 도구의 지속 가능성이 아직 각자 해결하는 문제로 남아 있다는 점은 같다.

nodeterm - 터미널 사이에 컨텍스트를 흘린다

Reddit · r/ClaudeAI ottasilver

여러 터미널을 띄워 각각 에이전트를 돌릴 때 생기는 문제를 겨냥한 도구다. 100% 오픈소스이고 Claude로 만들었다. 제작 계기가 구체적인데, macOS 기본 터미널로 여러 프로젝트, 특히 SSH 원격 프로젝트를 관리하는 게 감당이 안 됐고 Git 때문에 VS Code를 계속 띄워둬야 해서 머신 부하가 늘었다는 것이다. 모든 터미널을 하나의 캔버스에서 관리하는 프로그램으로 시작해 "자율 개발 환경"에 가까운 것으로 커졌다.

기능이 여섯이다. 터미널 영속성은 앱을 닫거나 연결이 끊긴 뒤 SSH로 재접속해도 같은 레이아웃과 세션을 그대로 복원한다. SSH 서버 터미널을 로컬처럼 다루고 드래그앤드롭에 이미지까지 된다. 휴대폰에서 세션을 이어갈 수 있고, Git push/pull/commit이 내장돼 있다.

에이전트 관점에서 중요한 것은 나머지 둘이다. 터미널 간 통신은 컨텍스트를 연결해 스킬을 통해 한 터미널이 다른 터미널의 컨텍스트를 읽거나 사용하게 한다. 그리고 오케스트레이션은 예를 들어 한 터미널에 "프런트엔드용 Claude Code 세션을 시작하고 오케스트레이터 역할을 하라"고 지시해 다른 세션들을 관리하게 만드는 구성이다. 오늘 다룬 Forklane이 사람과 사람 사이의 에이전트 동기화를 겨냥했다면, 이쪽은 한 사람이 띄운 여러 세션 사이의 동기화다.

이번 게시물은 298업보트에 댓글 124개를 받았고, 일주일 전 다른 서브레딧에 올렸을 때는 조회수 30만을 기록했다. 제작자가 함께 밝힌 사정이 이 카테고리의 현실을 보여준다. 스폰서 또는 커뮤니티의 동기 부여가 필요하다고 공개적으로 적고 GitHub 스타를 요청했다. 개인이 만든 에이전트 도구가 인기를 얻어도 수익 경로가 없는 상태가 오늘 하루에만 여러 번 나온다.

Forklane - 사람과 에이전트가 같은 세션에서 코딩한다

Hacker News · akshayl284 (forklane.ai)

문제 정의가 해커톤 현장에서 나왔다. 팀원 각자가 자기 파트를 에이전트로 만들면 두 가지가 동시에 터진다. 에이전트들이 서로의 컨텍스트를 모르고, 각자 만든 해법이 어긋난 채 진행되다가 마지막에 합쳐지지 않는다.

Forklane은 에이전트와 오케스트레이션 스택을 내장한 실시간 멀티플레이어 코딩 환경으로 이 문제를 겨냥한다. 팀원들과 그들의 에이전트가 서로를 밟지 않으면서 협업하고, 모든 팀원의 에이전트를 동기화 상태로 유지하는 것이 목표다. 현재 무료 퍼블릭 베타이고 이 기간에는 세션과 컴퓨트가 무료다.

기술 세부는 거의 공개되지 않았다. 실시간 동기화를 CRDT로 하는지, 에이전트 간 컨텍스트 공유가 어떤 형태인지 알 수 없어 지금 검증 가능한 것은 문제 정의와 포지셔닝뿐이다. 다만 그 문제 정의 자체는 팀 단위로 에이전트를 쓰는 조직이 실제로 겪는 것이라 기록할 값이 있다.

흐름상 위치도 분명하다. 오늘 뒤에서 다룰 Engelbart 논의가 한 사람과 한 에이전트 사이에서 무엇이 함께 참인지를 문제로 삼는다면, 이쪽은 정확히 한 층 위, 여러 사람과 여러 에이전트 사이의 목표 공유를 겨냥한다. 그리고 바로 앞의 nodeterm이 한 사람이 띄운 여러 세션을 잇는 쪽이니, 세 항목을 이어 놓으면 동기화 문제가 개인 안에서, 개인과 도구 사이에서, 팀 전체로 세 번 반복되는 그림이 된다.

Cronloop - 크론으로 도는 Claude Code와 Codex

Hacker News · miketromba (cronloop.ai)

5분에 한 번부터 주 1회까지 주기를 정해 Claude Code나 Codex를 돌리는 호스팅 서비스다. 잡 설명은 평문 Markdown으로 쓰고, 실행 로그가 앱으로 실시간 스트리밍된다. 과금 구조가 특이한데, 모델 사용량은 사용자가 연결한 기존 ChatGPT/Claude 구독이나 API 키에 남는다. API 크레딧을 재판매하는 기존 자동화 SaaS와 다른 접근이다. 가격은 Free 0달러와 Pro 월 25달러(연간 결제 시 월 20달러) 둘뿐이다.

기술적으로 볼 지점이 셋이다. 모든 실행이 일회용 격리 샌드박스에서 시작하고, 에이전트마다 실행 간에 유지되는 Markdown 기반 durable memory가 있으며, 커넥터가 200개 넘게 제공된다. 실행마다 배운 것을 기록하도록 지시에 넣으면 시간에 따라 자기 개선을 하고 다른 에이전트가 그 기록을 읽는 구성이 가능하다.

MCP 통합도 특징적이다. https://app.cronloop.ai/v1/mcp를 Claude나 ChatGPT의 커넥터로 추가하고 표준 OAuth로 한 번 승인하면, 대시보드를 열지 않고 대화로 에이전트를 만들고 실행하고 실패를 사후분석할 수 있다. 시크릿은 들어갈 때 암호화되고 다시 읽어낼 수 없다고 명시돼 있다. 에이전트가 자격증명을 쓸 수는 있어도 유출할 수는 없게 하려는 설계다.

랜딩에 붙은 사례별 수치(지원 티켓 83% 자동 해결, 90일간 오가닉 클릭 38% 증가 등)는 마케팅 예시이지 검증된 값이 아니다. 더 신뢰할 만한 신호는 제작자가 HN 댓글에 밝힌 자기 사용법인데, 자율 운영 이벤트 사이트 aievents.now를 만들고 도시마다 에이전트를 하나씩 붙여 매일 아침 이벤트를 큐레이션하게 했다는 것이다.

Codex로 6시간 만에 만든 대조 설계

LinkedIn · jiwoo lee

학생 대상 Codex 해커톤에서 나온 VibeCheck의 설계가 오늘의 에이전트 보안 논의와 정확히 겹친다. GitHub 저장소나 배포 링크를 넣으면 서비스의 기능을 node로, 기능 사이의 데이터와 권한 흐름을 edge로 구조화하고 위험한 흐름을 시각적으로 보여준다.

설계 원칙이 핵심이다. AI에게 코드를 주고 "안전한지 판단해줘"라고 묻지 않는다. 대신 코드에서 추출한 사실을 Knowledge Graph로 구조화하고 보안 규칙과 대조한 뒤, 문제가 발견되면 수정 위치와 근거를 제시하고 Codex로 수정안까지 연결한다. 판단을 모델의 총평에 맡기지 않고 구조화된 사실과 규칙의 대조로 내린다는 것인데, 오늘 다룬 holdline이 가드를 함수로 표현해 채점한 것, yogthos가 Behavior Trees를 인용해 "모델은 리프 노드"라고 정리한 것과 같은 층위다. 이 전부를 6시간 안에 기획부터 모델과 파이프라인 설계, 웹 구현, 시연, 발표 자료까지 끝냈다.

참가자 회고가 솔직하다. 기술과 제품에 집중하느라 팀 협업 과정과 Codex 활용 방식을 결과물에서 충분히 보여주지 못한 것이 아쉬웠고, 다음에는 "어떻게 함께 만들었고 AI를 어떻게 활용해 검증했는가"까지 결과물의 일부로 담겠다는 것이다.

같은 흐름에서 다른 산출물도 돌았다. Codex와 Blender MCP와 Three.js로 만든 PC용 낚시 게임이 있는데 **제작 동기가 "Codex 토큰 소비용"**이었다. 리셋이 3일 남았는데 사용량이 82% 남아 있어 만들었다는 것인데, 구독제 한도가 사용 패턴을 만드는 사례다. Codex만으로 이틀 만에 만든 RPG 게임도 공개됐고, OpenAI 직원이 "코덱스 목요일을 기대합시다"라고 예고했다.

커뮤니티 질문 하나가 이 카테고리의 현재 상태를 보여준다. Codex와 Antigravity를 한 프로젝트에서 병행해도 컨텍스트나 파일 충돌이 없는지를 묻는 글에 댓글 13개가 붙었다. Antigravity는 MCP 연결과 배포가 편하고 Codex는 코딩과 토큰 효율이 좋다는 판단에서 나온 질문인데, 하네스를 여러 개 쓰는 사람이 늘면서 논점이 "어느 도구가 더 좋은가"에서 **"여러 도구를 동시에 쓸 때 컨텍스트와 작업 이력을 어디에 둘 것인가"**로 옮겨갔다.

에이전트에게 구조를 판다 - 실행 권한과 검증

에이전트는 스스로를 단속할 수 없다 - Ryan Dahl의 Claw Patrol

YouTube · AI Engineer, 발표 Ryan Dahl (Deno)

Node.js를 만들고 지금 Deno를 이끄는 Ryan Dahl이 자기 회사에서 에이전트에 프로덕션 데이터베이스 접근을 열면서 만든 도구를 공개했다. 이름은 Claw Patrol이고 MIT 라이선스 오픈소스다.

출발점이 된 관찰이 이 섹션 전체의 명제다. "Opus는 위험한 요청을 거부한다. 그것으로는 불충분하다." 모델이 판단해서 거절하는 것은 통계적 성향이지 보장이 아니고, 프로덕션 데이터가 걸린 자리에서는 성향으로 충분하지 않다는 것이다. 그래서 판단을 모델 밖으로 꺼냈다.

구현 방식이 구체적이다. 흔한 접근은 HTTP 레벨에서 URL이나 헤더를 보고 막는 것인데, Claw Patrol은 그보다 아래 계층에서 Postgres 와이어 프로토콜을 직접 파싱한다. 에이전트가 어떤 클라이언트 라이브러리를 쓰든, 어떤 방식으로 쿼리를 조립하든, 네트워크로 나가는 순간의 실제 쿼리를 본다. 규칙은 HCL로 쓰고 현재 1,000줄 규모다. 네트워크 경로는 Tailscale exit node를 통과하게 묶어서 에이전트가 우회 경로를 찾지 못하게 했다.

검증 방법도 언급됐다. 규칙 자체를 fixture 기반 유닛 테스트로 검사한다. 가드를 코드로 취급하면 가드에도 테스트가 필요하다는 당연한 귀결인데, 실제로 그렇게 하는 사례가 드물다는 게 오늘 별도로 다룰 holdline의 문제 제기와 정확히 맞물린다.

Doberman - rm -rf를 실행하기 직전에 끊는 실행 경로 게이트

Hacker News · alanfuNZ (Doberman-Core)

같은 처방을 로컬 개발 환경의 훅 계층에서 구현한 도구다. Apache 2.0, Python 3.11 이상, 스스로 alpha라고 밝혔다.

판정 결과가 세 가지다. PASS는 그대로 통과, AUTH는 사람 승인 요구, BLOCK은 차단이다. 설계 원칙 두 개가 이 도구의 성격을 정한다. fail closed - 게이트 자체가 오류로 죽으면 통과가 아니라 차단으로 떨어진다. 그리고 raise-only - 하위 설정이 상위 설정보다 위험도를 낮출 수 없고 올리는 것만 가능하다. 프로젝트 로컬 설정으로 전역 정책을 무력화하는 경로를 막은 것이다.

모드별 임계값 표가 문서에 있고, 모드와 무관하게 항상 차단되는 항목도 지정돼 있다. CI/CD 설정 파일 편집은 전 모드에서 스텁업된다. 앞으로 보게 될 Wiz 사례가 정확히 그 경로였다는 점에서 근거 있는 선택이다. turn gate는 Tier 0에서 돈다.

정직한 대목이 둘 있다. 하나는 적응형 판정 계층이 훅 경로에서는 돌지 않는 이유를 밝힌 것인데, 해당 모듈 import에만 호출당 2초가 걸려서 모든 명령마다 2초를 더할 수 없었다는 것이다. 다른 하나는 uninstall-hooks의 순서 함정을 문서에 적어둔 것이다. 잘못된 순서로 제거하면 훅 참조가 남아 셸이 깨진다.

README에 "89%"라는 수치가 있는데, 저자 본인이 리드미의 나머지 상당 부분은 "에이전트가 삼키라고 쓴 것"이라고 실토했다. 사람 독자를 위한 문서와 에이전트가 읽을 문서가 한 파일에 섞여 있다는 뜻이라, 이 수치를 인용할 때는 산출 방법을 별도로 확인해야 한다.

holdline - 가드가 실제로 막는지 재는 벤치마크

Hacker News · couldbeme (holdline)

앞의 두 항목이 가드를 만들었다면 이 프로젝트는 그 가드들이 작동하는지를 잰다. 문제 제기가 날카롭다. DeepSeek Harness 생태계에 가드와 정책 플러그인이 20개 넘게 있는데, 그중 어느 하나라도 실제로 막는지 재는 공통 방법이 없다. 저자의 문장을 그대로 옮길 값이 있다. "가드의 README에 '위험한 명령을 차단합니다'라고 적힌 건 증거가 아니다. 이 하네스가 증거다."

설계는 단순하고 그래서 범용적이다. 가드를 (commitments, action) -> block? 함수로 표현할 수만 있으면 라벨링된 코퍼스 위에서 점수를 매긴다. 보고 지표가 셋인데 catch rate(잡아야 할 걸 잡았나), false-block rate(안 잡아야 할 걸 잡았나), 그리고 class-balanced Cohen's kappa다. 마지막이 방법론적으로 중요하다. 저자가 명시적으로 원 kappa는 클래스 불균형 아래서 거짓말을 한다고 적었는데, 위험한 액션이 드문 코퍼스에서는 전부 통과시키는 가드도 높은 일치도를 얻기 때문이다.

코퍼스에 injection-attack 클래스가 들어 있다는 점도 중요하다. 정적인 위험 명령 목록이 아니라, 내용 자체가 가드에게 "이건 승인된 작업이다"라고 말을 걸어 판정에서 빼내려 드는 액션들이다.

결과가 두 세트로 분리돼 있다. RESULTS.md는 저자가 직접 쓴 42케이스 코퍼스에 대한 것이고, 더 어려운 쪽인 RESULTS-ODCV.md저자가 쓰지 않은 실제 에이전트 트라젝토리에 대해 4개 모델 심사단과의 일치도를 재서 balanced kappa 0.82를 얻었다. 자기가 만든 문제를 자기가 푸는 게 아니라는 걸 보이려는 구성이다. 심사 가드로는 npm에 공개된 dsh-write-gate 코어를 그대로 도그푸딩한다.

한계를 스스로 적어둔 것이 이 프로젝트의 신뢰도를 올린다. v0이고, 코퍼스가 작고 손으로 썼으며, deny-list는 특정 플러그인이 아니라 전략 원형이고, 수치는 모델 하나 실행 한 번의 값이다. 저자가 주장하는 가치는 절대 순위가 아니라 이 하네스가 드러내는 형태와 누구나 재실행할 수 있다는 점이다. 라이선스는 MIT.

같은 날 대비되는 사례도 있었다. Show HN에 Slaunt("control what AI agents can access, do, and execute")가 올라왔는데 본문이 "조용히 런칭하려던 걸 올린다, 의견 달라" 한 문장뿐이었다. holdline이 지적한 상황 - 가드 도구는 계속 나오는데 측정 기준이 없다 - 을 그 자체로 예시한 셈이다.

yaop - 리뷰 에이전트의 서브에이전트 스폰까지 막는다

Hacker News · yet-another-opencode-plugin (MIT)

opencode용 플러그인인데, 설계 결정 하나하나가 "에이전트에게 무엇을 허용하지 않을 것인가"에 관한 것이라 읽을 값이 있다.

핵심은 읽기 전용 primary 에이전트 두 개다. Review는 Build/Plan과 동급 지위이지만 절대 편집하지 않고, 요청이 들어오면 항상 전체 프로토콜을 돈다. 대상 결정(기본은 git diff와 status) -> 전체 컨텍스트 읽기 -> 기능적 렌즈(YAGNI, 과설계, 죽은 코드, 근본 원인) -> yaop-review 스킬을 통한 4개 비기능 레이어(성능, 보안, 유지보수성, 아키텍처) -> 임계 이상인 레이어마다 deep-dive 서브에이전트 -> 심각도 순으로 정렬된 리포트 하나. Dream은 코드를 쓰기 전 아키텍처 결정을 확정하는 플래너로, 프로젝트를 kind와 concern 태그로 분류하고 카탈로그를 가지치기한 뒤 남은 결정만 질문한다. 파일을 쓰지 않는다.

권한 경계가 이 플러그인의 실질이다. 두 에이전트 모두 editdeny, bashask이되 git 읽기 서브커맨드만 허용한다. 여기까지는 흔한데, 한 걸음 더 갔다. Review의 permission.task가 자기 소유의 *-deep 서브에이전트(security-deep, performance-deep, architecture-deep)로만 제한되고, Dream은 permission.task 자체가 denied다. 리뷰어가 임의의 서브에이전트를 스폰해 자기 권한 제한을 우회하는 경로를 닫은 것인데, 서브에이전트를 쓰는 시스템에서 자주 빠지는 구멍이다.

응답 스타일 규칙에도 안전 예외가 박혀 있다. 필러와 헤징을 걷어내는 저강도 간결화를 기본으로 두되, auto-clarity가 보안 경고와 되돌릴 수 없는 작업과 모호한 상황에서는 그 간결함을 해제한다. 간결함이 안전을 깎지 않게 하는 명시적 장치다.

실무 팁도 하나 있다. opencode가 opencode.json을 엄격하게 검증하기 때문에 플러그인 설정을 그 안에 넣을 수 없고 ~/.config/opencode/yaop.json에 따로 둬야 한다. 기본값은 review.deepDiveThreshold"high", review.parallelSkillstrue로 4개 레이어를 병렬 분석한다. 마지막 설계 결정도 중요한데, 메인 Build/Plan 에이전트는 건드리지 않고 룰셋을 review와 dream 프롬프트에만 임베드한다.

Wiz Red Agent가 Snowflake의 Jira를 열었다

Wiz 블로그 · Gal Nagli

앞 항목들이 처방이라면 이건 처방 없는 환경에서 실제로 벌어진 일이다. Wiz의 레드팀 에이전트가 Snowflake 공개 저장소의 GitHub Actions 워크플로에서 결함을 찾아 Jira 자격증명에 도달했다. PR은 #1218, 커밋은 4a1b8ce다.

결함의 정체가 흔하고 그래서 무섭다. 워크플로가 github.event.pull_request를 참조하는데 해당 트리거 컨텍스트에서는 그 값이 항상 null이었다. 조건문이 의도한 대로 평가되지 않고 통째로 우회된 것이다. 노출은 5일간 지속됐다.

두 가지 대목이 이 사건을 오늘의 다른 항목들과 연결한다. 하나는 문제의 PR을 리뷰한 Copilot이 "문제없다"고 판정했다는 것이다. AI 리뷰가 AI 공격을 놓친 자리다. 다른 하나는 에이전트가 진행 중 발생한 Bash 구문 오류를 사람의 개입 없이 스스로 고쳐 공격을 이어갔다는 점인데, 자율성이 공격 쪽에서도 그대로 작동한다는 증거다.

권고는 둘이다. GitHub Actions 워크플로 전용 정적 분석기 zizmor를 CI에 넣을 것, 그리고 워크플로에 넣는 자격증명을 수명 짧은 토큰으로 바꿀 것. 앞서 본 Doberman이 CI/CD 설정 파일 편집을 전 모드에서 차단하는 이유가 여기 있다.

대용량 데이터를 다루는 대화 앱의 보안 6함정

Reddit · r/microsaas VerbaGPT

데이터에 자연어로 질문하는 앱을 실제로 운영하는 사람이 컨텍스트, UI, 보안 세 축으로 정리한 글이라 추상론이 없다. 경쟁 지형부터 솔직하다. Databricks Genie, Azure의 동종 제품, Snowflake(구 Cortex) 같은 대형 제품이 있고 사내 자체 구축도 흔한 영역이다. 스택은 React와 FastAPI, 멀티테넌트 런타임 격리, 멀티모달, 데이터 분석용으로 튜닝한 커스텀 하네스다. 아키텍처 분기점은 text-to-SQL에 머물지 않고 text-to-SQL/Python으로 간 것이다. 고급 시각화와 데이터 사이언스 작업까지 하려면 SQL만으로는 부족하다는 판단이다.

컨텍스트 쪽 난점은 사내 용어다. 답변 품질을 내고 환각을 줄이려면 모델이 "churn"이 이 회사에서 무엇을 뜻하는지, "trend"를 어떻게 계산하는지 알아야 한다. 시맨틱 레이어의 기본은 어떤 테이블이 있고 어떻게 조인되며 어떤 컬럼이 무엇을 뜻하는지이고, 여기에 DB 전체가 무엇을 위한 것인지 같은 메타 설명과 테이블별 설명을 붙이면 크게 도움이 된다.

특히 효과적이었던 것이 **벡터화된 "가이드라인"**이다. 데이터 정의와는 별개로 회사가 매출을 세는 특정 방식, EBITDA 정의, 월간 예측을 만드는 워크플로 같은 것을 저장해두고 분석 때마다 커스텀 하네스가 빠르게 검색해 가져온다. 좋아요 형태의 피드백도 유용한데, 유사 쿼리 벡터 저장소가 자동으로 쌓여 이후 쿼리가 참조하기 때문이다. 컬럼이 수천 개인 DB에서는 전체를 컨텍스트에 밀어 넣는 것이 불가능하므로 벡터 검색으로 스키마를 관련 부분만 추리되, 부족하면 LLM이 더 질의할 수 있게 문을 열어둔다. 이유가 명확하다. 저렴한 모델에서도 잘 돌게 만드는 것이 목표이고, 그게 되면 좋은 모델에서는 그냥 보너스다.

UI 절의 요지는 내부 복잡도를 사용자에게 전가하지 않는 것이다. Databricks나 Snowflake, 혹은 터미널 앱으로 같은 일을 하려면 학습 곡선과 버튼이 많은데, 목표는 터미널이나 ETL 도구를 다뤄본 적 없는 복도 건너편 현업 전문가가 쓸 수 있는 수준이다. 구현은 이원화됐다. 클라우드에서 도는 빠르고 토큰 효율적인 커스텀 하네스가 **실사용의 80%**를 차지하고, 멀티모달에 멀티모델이라 OpenAI와 Anthropic은 물론 OpenRouter, DeepSeek, Meta API도 붙는다. 저자는 제공자, 특히 대형 AI 랩에 종속되지 않는 것이 자기 핵심 철학이라고 밝힌다. 별도로 로컬 옵션이 있어 사용자의 Claude Code 구독에 얹혀 로컬 파일이나 네트워크 SQL을 분석하고, Claude Code SDK를 구독으로 돌리거나 OpenRouter와 Meta API의 저렴한 모델로 돌릴 수 있다. 저자 평가로는 muse spark 1.2 모델이 Claude Code 하네스와 놀랄 만큼 잘 맞는다. 앞서 본 HarnessRouter가 작업별로 하네스를 갈아 끼우려던 것과 같은 동기가 제품 층위에서 나타난 사례다.

보안 절이 이 글에서 재사용 가치가 가장 높다. 여섯 항목이 이렇다. 첫째, 생성된 코드가 시크릿을 볼 수 없게 실행 환경을 분리한다. 둘째, 위험 패턴을 정규식으로 거르지 말고 샌드박싱한다. 정규식은 우회되고 샌드박스는 우회가 훨씬 어렵다. 셋째, 역할 검사와 소유권 검사를 구분한다. "이 사용자가 관리자인가"와 "이 행이 이 사용자 것인가"는 다른 질문인데 전자만 하고 넘어가는 구현이 흔하다. 넷째, NL-to-SQL은 그 자체가 인젝션 표면이다. 다섯째, 수집해 들여온 데이터도 인젝션 벡터다. 사용자가 올린 CSV의 셀 내용이 곧 모델에 들어가는 프롬프트가 된다. 여섯째, 비용도 보안이다. 제한 없는 LLM 호출은 제한 없는 청구서이므로, 크레딧과 레이트 리밋을 프런트엔드에 맡기지 말고 서버에서 원자적으로 강제해야 한다.

각 항목의 근거도 구체적이다. 첫째는 API 키와 접속 문자열을 암호화해 실행 컨텍스트 바깥에 두어, 분석 샌드박스가 시도하더라도 환경변수나 시크릿을 읽을 수 없게 하라는 것이다. 둘째에 대한 저자 표현이 인상적인데, 이 문제는 누군가 탈출구를 찾기 전까지만 해결된 것처럼 보이는 종류라 첫날부터 진지하게 다뤄야지 나중에 덧붙일 일이 아니다. 셋째에서 든 실패 사례가 구체적이다. 관리자 A가 조직 B의 데이터를 조용히 볼 수 있는 관리 패널을 만들어버리기가 아주 쉽다. 모든 엔드포인트에 DB 수준의 명시적 소유권 검사가 필요하다. 넷째는 쿼리를 LLM이 쓴다고 해도 파라미터화와 인용은 그대로 하고 커넥션 스코프를 좁혀, 영리한 프롬프트가 자기 테이블이나 스키마 밖으로 나가지 못하게 하라는 것이다. 다섯째는 데이터 노트, 업로드 파일, 컬럼 값 등 컨텍스트 윈도로 되먹여지는 모든 것이 인젝션 벡터이며 메모리와 피드백 루프를 붙이는 순간 더 그렇다는 경고다.

마지막으로 저자가 짚은 것이 로컬과 클라우드의 차이다. 둘은 인프라만 다른 게 아니라 위협 모델이 다르다. 로컬은 사용자 자기 머신이라는 이유로 격리 부담을 일부 덜지만, 클라우드는 그 가정을 할 수 없으므로 한 사용자의 세션 상태가 다른 사용자에게 새지 않도록 동시성 안전한 요청 격리가 필요하다.

Reddit 반응은 5업보트에 댓글 1로 미미하다. 그래도 남길 값이 있는 이유는, 오늘 다른 글들이 원칙 수준에서 말한 것을 이 글이 구현 수준의 체크리스트로 내려놓기 때문이다. 앞의 yaop과 Doberman이 실행 권한을 다뤘다면 이 목록은 데이터 권한 쪽이다. 두 축이 만나는 자리가 NL-to-SQL이라, HarnessRouter의 Dashboards가 READ ONLY 트랜잭션을 쓴 이유도 여기서 설명된다.

에이전트에게 진짜 신용카드를 줘도 되는가

Reddit · r/AI_Agents burikismat47

실행 권한 논의의 금전 버전이다. 업보트 13개에 댓글 27개로 반응이 갈렸는데, 이 비율 자체가 신호다. 동의는 적고 할 말은 많은 주제다.

댓글에서 반복해서 관찰된 것은 반대 논거가 대체로 사후 검증 불가능성으로 수렴한다는 점이다. 에이전트가 잘못 샀을 때 그게 잘못된 결정이었는지 판정할 방법과 되돌릴 방법이 함께 없다는 것이다. 온체인 검증을 내세우는 OpenGradient 같은 접근이 언급됐지만, 실행 자체를 증명하는 것과 그 실행이 옳았는지를 판정하는 것은 다른 문제라는 지적이 함께 붙었다.

오늘 별도로 다룰 OrbitQuote가 "스스로 사지 않는다, 조합을 만들고 멈춘다"를 제품 카피에 명시한 것과 정확히 같은 지점이다. 돈이 나가는 행위에 사람 승인을 붙이는 것이 현재 시장의 사실상 기본값이라는 뜻이다.

코드 리뷰 대상을 diff에서 intent로

YouTube · AI Engineer, 발표 Ankit Jain (Aviator)

앞 항목들이 개별 실행을 다뤘다면 이 발표는 조직 규모의 병목을 다룬다. 제시된 수치가 상황을 설명한다. 코드 churn이 861% 증가했고, 리뷰 대기 시간이 4배로 늘었으며, 30%의 변경이 리뷰 없이 들어간다.

진단은 리뷰 대상 자체가 틀렸다는 것이다. 2006년 Google의 Mondrian 이래 코드 리뷰의 단위는 diff였는데, 사람이 손으로 쓰던 시절에는 diff가 곧 의도의 근사치였다. 에이전트가 수백 줄을 한 번에 쏟아내는 지금은 diff를 다 읽어도 무엇을 하려던 것인지 복원되지 않는다. 그래서 리뷰 단위를 intent로 올리자는 제안이다.

alignment를 재정의하는 대목이 이 발표의 핵심이다. 통상 쓰이는 모델 정렬이 아니라 "이 변경이 원래 요청과 맞는가"를 뜻하는 조직 용어로 쓴다. 그러려면 원래 요청이 어딘가에 기록돼 있어야 하는데, 발표자의 관찰은 test plan을 사람이 따로 쓰는 게 아니라 에이전트 세션에서 뽑아내야 한다는 것이다. 무엇을 시켰는지는 세션에만 남아 있기 때문이다.

AI slop registry, 즉 반복적으로 생성되는 저품질 패턴을 목록화해 자동 탐지하는 아이디어도 나왔고, 리뷰 코멘트 1,000개를 마이닝해 어떤 지적이 실제로 결함을 잡는지 분류하는 것을 숙제로 남겼다. 마지막 프레임은 J 커브다. AI 도입 직후 리뷰 부담이 먼저 커지고, 리뷰 방식 자체를 바꾼 뒤에야 생산성이 올라온다는 것이다.

에이전트 메모리는 저장이 아니라 폐기의 문제다

에이전트 루프는 유전 알고리즘이고 테스트가 선택압이다

개인 블로그 · yogthos

"LLM이 작동할 때는 마법 같지만, 실패할 때는 자신만만한 헛소리꾼과 말싸움하는 느낌"이라는 문장으로 시작하는 실전 워크플로 정리다. 저자는 Clojure를 20년 가까이 다뤄온 사람이고, 지금 Chez Scheme 위에서 도는 Clojure 방언 컴파일러 Jolt를 만들고 있다.

개념 프레임이 둘이다. 하나는 방향의 역전이다. 손으로 코드를 쓸 때는 함수를 하나씩 의도적으로 쌓아 올리지만, LLM은 처음부터 코드를 왕창 뱉기 때문에 초점이 깎아내리는 쪽으로 옮겨간다. 다른 하나가 제목의 비유다. 에이전틱 하네스가 효과적인 이유는 진화 과정이 돌기 때문이다. 모델이 대충 맞는 것을 내고, 코드가 테스트되고, 피드백으로 반복하며 테스트되는 파라미터에 맞게 수렴한다. 테스트가 곧 선택압이다.

위임할 것은 셋으로 정리된다. 백만 번 반복돼온 전형적 작업, 콜 그래프 추적 같은 탐색 작업, 그리고 녹슨 언어의 문법이다. 저자는 10년 넘게 안 만진 JavaScript 프로젝트를 자기가 능숙한 Clojure만큼 효과적으로 다뤘다고 쓴다.

직접 잡아야 할 것은 컨텍스트와 창의성이다. "Clojure 방언"이라고만 말하면 모델은 자기가 배운 JVM 툴체인(clojure, lein)을 집는데 그 맥락에는 존재하지 않는 것들이다. 런타임이 순수 Chez Scheme이고, 모든 빌드가 chez --script를 통한 make로 이뤄지며, 정본 소스는 host/chez/*.ssjolt-core/*.clj라고 명시해야 한다.

"순진한 구현"의 함정이 이 글에서 가장 실용적인 부분이다. 예시가 셋이다. 문자열 메서드 호출을 제네릭 디스패치 테이블로 라우팅해 매 호출마다 수신자 타입을 다시 유도하게 만든다. 올바른 수정은 컴파일 타임에 그 값이 문자열임을 증명하는 타입 추론 패스를 넣어 디스패치를 통째로 건너뛰는 것인데, "문자열 메서드를 빠르게 만들어라"라고만 하면 cond 절 순서만 바꾸고 제네릭 경로를 유지한다. 시퀀스 count는 컬렉션이 이미 길이를 알아 상수 시간에 부를 수 있는데도 전체를 순회하며 셀을 새로 할당한다. 문자열 결합은 한 번 순회 대신 반복 concat을 준다. 저자의 표현은 **"질의를 최악의 방식으로 해석하는 사악한 지니"**다.

궤도 유지 요령 중 눈에 띄는 것이 계획 단계다. 요구사항을 준 뒤 Markdown 단계별 계획과 함께 Mermaid 다이어그램을 만들게 한다. 다이어그램이 나오면 논리를 눈으로 검사할 수 있고, 잘못된 단계만 지목해 고치라고 하면 된다. 텍스트로 논쟁하는 것보다 훨씬 빠르다는 것이다. 그리고 절대 원칙 하나 - AI에게 빈 캔버스를 주지 않는다. 파일 구조와 컴포넌트는 사람이 정하고 빈칸을 채우게 한다.

테스트는 요구사항 문서로 취급한다. 컴포넌트 기능 테스트와 e2e 통합 테스트가 가장 값지고 너무 세분화할 필요는 없으며, 웹앱이면 Storybook과 Playwright를 쓴다. 테스트가 없으면 에이전트가 새 기능을 넣으며 기존 기능 셋을 조용히 깨뜨릴 확률이 그만큼 높다. 테스트가 성능은 못 잡으므로 CPU와 메모리 벤치마킹 스위트를 따로 둔다. Git은 비디오게임의 퀵세이브처럼 쓴다. 안정 상태마다 즉시 커밋하고, 실험이 실패하면 손으로 풀지 말고 되돌린다.

실무에서 가장 자주 쓸 판단 기준이 하나 있다. 에이전트가 첫 시도에서 대체로 맞히지 못하면 나중에도 제대로 만들지 못한다. 버그를 지적해도 에이전트는 근본 문제를 이해하러 물러서지 않고 그 특정 불만에만 kludge를 덧붙여 문제를 증식시킨다. 나선형에 들어가면 문제 정의를 다시 짜고 처음부터 시작할 때다.

반대편의 이점이 탐색 비용이다. Jolt의 런타임으로 Janet을 골랐다가 세대별 GC가 없어 영속 자료구조가 만드는 단명 객체와 맞지 않는다는 걸 깨닫고 Chez Scheme으로 갈아탔는데, Janet 스파이크 전체가 약 1주, Chez에서 되는 걸 증명하는 데 며칠이었다. LLM 없이는 몇 달짜리였을 일이다.

자체 하네스 Dirge에서 처리한 두 함정이 오늘 다른 항목들과 직결된다. 하나는 괄호 불일치인데, 코드를 그냥 모델에 되돌려주면 빠진 괄호를 찾느라 토큰을 태우고 심지어 괄호를 세는 파이썬 스크립트를 짜기까지 한다. 하네스가 기계적으로 고치면 모델이 관여할 필요가 없다. 다른 하나가 더 중요하다. Markdown 추적은 취약하다. 파일이 낡고 모델이 갱신을 잘 안 해 오히려 오도한다. 그래서 SQLite를 하네스의 데이터스토어이자 프로젝트 메모리로 쓰고, beads 방식을 본떠 태스크까지 추적하며, 작업 중인 태스크를 컨텍스트 최상단에 주입한다. 태스크가 끝나면 별도의 critic 역할이 diff를 보고 리뷰해 설익은 결과가 나가는 걸 막는다.

논문 하나를 통합한 것도 언급할 값이 있다. Behavior Trees Enable Structured Programming of Language Model Agents는 모델을 에이전트 전체로 보지 말고 행동을 만들어내는 primitive, 즉 결정론적 제어 구조의 리프 노드로 다루자는 제안이다. verifier와 critic과 code reviewer가 실행 종료 전 반드시 통과해야 하는 고정된 검사 시퀀스를 이루고, 실패 사다리는 retry fallback 노드로 막으며, publish state guard 같은 장치가 안전 제약을 구조적으로 강제한다. 저자의 결론 문장이 세다. "올바른 구조를 두르면 로컬 모델조차 꽤 복잡한 작업을 유능하게 해낸다."

마지막 못이 이 글 전체를 지탱한다. LLM은 자기 전문성 밖의 문제를 풀어주지 못한다. 저자가 컴파일러를 만들 수 있는 건 그 언어를 20년 다뤄 내부 동작과 최종 형태와 피해야 할 함정을 알기 때문이고, 익숙하지 않은 문제였다면 다트를 던지는 것과 같았을 뿐 아니라 결과가 맞는지 평가할 능력조차 없었을 것이라는 이야기다.

Engelbart와 Facts - 무엇이 조용히 참이기를 그만뒀는가

Hacker News · Engelbart 팀 / Al Newkirk (Facts 프로토콜)

같은 날 서로 다른 두 프로젝트가 같은 문제를 다른 층위에서 짚었다. 에이전트와 오래 일하면 무엇을 하려던 것이었는지무엇이 사실인지가 둘 다 흘러내린다는 것이다.

Engelbart는 목표 쪽이다. 오픈소스 Claude Code 플러그인으로, 현재 세션과 과거 대화 턴을 분석해 목표, 계획, TODO를 추론하고 그것을 로컬 서버에 목표 트리로 띄운다. 사용자는 제안된 트리를 검사하고 수정한 뒤 작업을 재개한다. 설치는 npx engelbart-cli이고 macOS 또는 Linux, Node 18 이상, Claude Code 2.1.175 이상이 필요하다. /goals-ui로 이 채팅의 goal workspace를 로컬 포트에 열고, /goals-ui disable로 분석과 주입을 끈다.

주입 방식이 이 도구의 실질이다. 첫 호출 이후 goals 문서가 채팅으로 되돌아오는데, 세션 시작 시점과 compaction 직후에는 파일 전체를 넣고 그 다음부터는 diff만 넣는다. 그리고 서브에이전트와 툴 배치도 그것을 읽는다. 한 번 호출하면 그 채팅의 수명 동안 유지된다. compaction으로 날아가는 문제를 goals 문서라는 별도 상태에 앵커링해서 푼 구조다.

기존 도구 비판이 분명하다. autocompact나 projects 같은 것들이 자율적 컨텍스트 보존으로 일부를 풀려 하지만 여전히 중요한 정보를 잃고 뒤섞으며, 더 나쁜 건 사람의 개입이 없어서 에이전트가 무엇을 달성하려 한다고 생각하는지를 사람이 검사하거나 조종할 수 없다는 점이라는 것이다. 초기 베타이고, 인간과 AI가 장기 작업에서 어떻게 계획하고 목표를 유지하는지에 대한 인지과학 연구의 일부라고 밝혔다.

Facts 프로토콜은 사실 쪽이다. 저자 Al Newkirk가 자기 AllSign 프로젝트의 코어 기본기를 오픈소스화할지 고민하다가 그것이 에이전트 메모리 문제의 해법이라는 걸 깨닫고 만든 행위자 중립(actor-agnostic) 지식 관리 오픈 프로토콜과 CLI다. 출발점이 된 논문은 Filesystem-Based Memory for LLM Agents(arXiv 2607.26637)이고, 저자가 동의하며 인용하는 결론이 **"정보 수집과 조직화가 자동으로 지능을 주지는 않는다"**이다.

빠졌다고 본 것이 큐레이션이다. 무언가가 결정해야 한다 - 무엇이 남길 가치가 있는지, 무엇이 무엇을 대체하는지, 무엇이 참인지, 그리고 무엇이 조용히 참이기를 그만뒀는지. 마지막 항목이 핵심이다. 에이전트 메모리 시스템 대부분이 추가만 하고 폐기를 다루지 않기 때문이다. 그래서 HITL(human-in-the-loop)과 HOTL(human-on-the-loop)을 함께 지원하는 지식 관리를 목표로 한다.

앞 항목의 Dirge까지 겹쳐 보면 셋이 같은 결론에 독립적으로 도달했다. Dirge는 Markdown이 낡으니 SQLite로 옮겼고, Engelbart는 Markdown을 유지하되 갱신과 주입을 플러그인이 강제하며 사람이 검사하게 했고, Facts는 무엇을 남기고 버릴지의 규칙 자체를 프로토콜로 표준화하려 한다.

메모리를 선택적으로 적용하는 실험 - 회상 후 기각도 성공이다

Reddit · r/AI_Agents jennifer_1mm

에이전트 메모리를 평가할 때 흔히 재는 것은 "규칙을 기억했는가"인데, 이 실험은 그것으로 부족하다는 걸 보인다. 설계가 영리하다. 표면적으로 똑같이 502를 반환하는 두 상황을 만들었다. 하나는 안전하게 재시도해도 되는 GET이고, 다른 하나는 멱등성 키가 없어 재시도하면 이중 청구가 나는 결제 POST다.

좋은 메모리는 "502면 재시도"라는 규칙을 기억하되 두 번째 상황에서는 그 규칙을 꺼내 보고 적용하지 않는 것이다. 그래서 이 실험은 회상한 뒤 기각한 경우도 성공으로 센다. 규칙을 아예 잊은 것과, 규칙을 떠올렸지만 맥락이 다르다고 판단한 것은 완전히 다른 결과인데 단순 회상률 지표는 둘을 구분하지 못한다.

부수적으로 확인된 사실도 실무에 쓸모가 있다. 새 채팅을 여는 것이 메모리 초기화가 아니다. 지속 메모리를 켜둔 시스템에서 "깨끗한 상태로 다시 시작"하려고 새 대화를 여는 습관은 실제로는 아무것도 리셋하지 않는다.

WhatsApp 3주 초록불 - 로그가 거짓말할 때

Reddit · r/n8n Salman94157

자동화가 3주 동안 아무 오류 없이 초록불이었는데 실제로는 망가져 있었다는 기록이다. WhatsApp Business API의 24시간 창 규칙 때문이었다. 사용자가 마지막으로 메시지를 보낸 지 24시간이 지나면 자유 형식 메시지를 보낼 수 없고 승인된 템플릿만 나가는데, 워크플로는 그 구분을 몰랐다.

결과가 구체적이다. 500건을 보내고 40명이 답장했는데 그 답장이 그대로 방치됐다. 파이프라인은 발송 성공만 기록했고 수신 처리 경로가 없었다. 더 나쁜 건 그 사이 계정 품질 등급이 떨어졌다는 것이다. 응답률이 낮고 차단이 쌓이면 플랫폼이 발송 한도를 조인다.

작성자의 결론이 이 섹션의 주제와 정확히 겹친다. "n8n은 거짓말하는 초록 로그로부터 당신을 구할 수 없다." 자동화 도구가 보고하는 성공은 자기가 호출한 API가 200을 돌려줬다는 뜻일 뿐, 그 결과 사람이 원하는 일이 일어났다는 뜻이 아니다. 앞 항목들이 에이전트 메모리에서 "무엇이 아직 참인가"를 물었다면, 여기서는 모니터링이 같은 질문을 놓친다.

컨텍스트 경제학 - 압축하지 말라는 실측

컴팩션은 기본값이 아니다 - 전체 히스토리가 더 싸다

YouTube · AI Engineer, 발표 Towards AI (Louis-François Bouchard, Omar Solano, Samridhi Vaid)

오늘 가장 반직관적인 실측이 여기 있다. 결론부터 말하면 대화 전체를 매번 그대로 보내는 것이 요약해서 보내는 것보다 쌌다. 자체 실험에 500~600달러의 API 비용을 썼다고 밝혔다.

논리는 프롬프트 캐시에 있다. 캐시된 프롬프트 토큰의 할인이 최대 50배다(DeepSeek 기준). 대화 앞부분이 바뀌지 않으면 그 전부가 캐시에 적중하므로, full history 전략은 토큰을 가장 많이 보내면서 총비용이 가장 낮았다. 측정된 캐시 적중률이 97%였다. 반대로 요약을 끼워 넣는 순간 프리픽스가 바뀌어 캐시가 무효화되고, 그 뒤 모든 턴이 정가로 청구된다. 발표자가 정리한 손익분기점이 명확하다. 요약이 이기려면 50배로 압축할 수 있어야 한다. 실제 요약이 그 정도로 줄이지 못한다.

정확도 쪽 차이는 더 컸다. 멀티턴 대화에서 앞서 나온 정보를 다시 꺼내야 하는 태스크의 회수율이 **전부 유지에서 95%, 요약에서 32%**였다. 프로덕션 도구들이 흔히 쓰는 기본 압축률(38%)에서도 손실이 관측됐다. 그리고 800k 토큰까지는 이른바 context rot, 즉 컨텍스트가 길어질수록 앞부분을 무시하는 현상이 관측되지 않았다고 보고했다.

RAG 쪽 수치도 함께 나왔는데 방향이 뚜렷하다. 400k 토큰 규모에서 dense 임베딩 검색의 회수율이 **0%**였던 반면 BM25는 **100%**였다. 긴 문서에서 특정 문자열을 찾는 종류의 질의에서 의미 검색이 무력화되는 자리다. 로컬 모델과 클라우드 모델의 캐시 활용률 차이도 지적됐다. 로컬이 33%, 클라우드가 92~95%였다.

발표 마지막 문장이 실행 지침이다. "do not compact by default." 컴팩션을 아예 쓰지 말라는 게 아니라, 도구가 자동으로 켜두는 기본값을 그대로 두지 말고 자기 워크로드에서 계산해보라는 것이다.

eval을 먼저 고치고 학습은 마지막에

YouTube · Hamel Husain 진행, 게스트 Prime Intellect

강화학습으로 모델을 개선하려는 팀이 실제로 시간을 어디에 써야 하는지에 대한 대담이다. 핵심 재정의가 하나 있다. eval은 데이터셋이 아니라 task set과 harness와 infrastructure 세 부분의 합이다. 문제 목록만 있고 그것을 실행하고 채점하는 환경이 허술하면 측정값이 모델을 반영하지 않는다.

가장 강한 증거가 Terminal Bench 2 사례다. 모델을 전혀 손대지 않고 타임아웃만 늘렸더니 점수가 14~15퍼센트포인트 올랐다. 그 정도 폭이면 모델 세대 차이와 맞먹는데, 실제로는 하네스 설정 하나였다. 벤치마크 비교표를 볼 때 실행 환경이 공개되지 않았다면 그 표가 무엇을 재고 있는지 알 수 없다는 뜻이다.

안티패턴으로 지목된 것이 temperature 0이다. 재현성을 위해 0으로 고정하는 관행이 흔한데, 그러면 모델의 실제 출력 분포를 못 보고 단일 샘플의 운에 의존하게 된다. 평가에서는 여러 샘플을 뽑아 분포를 봐야 한다는 것이다.

RL 맥락에서 나온 경고가 이 대담의 제목 격이다. "RL is less forgiving of sloppy evals." 지도학습은 엉성한 평가에도 어느 정도 굴러가지만, 보상 신호로 학습하는 순간 평가의 허점이 그대로 학습 목표가 된다. 실제로 관측된 reward hacking 사례도 소개됐는데, 생성된 텍스트의 어휘 특성으로 Claude 계열과 Llama 계열을 구분할 수 있었다는 것이다.

태스크 난도 설계에 대한 조언도 실용적이다. 모델이 0%를 받는 문제와 100%를 받는 문제는 둘 다 학습 신호를 주지 않는다. 그 사이 구간의 문제를 골라내는 것이 eval 작업의 상당 부분이다.

Sparse Attention 벤치마크를 조작하는 매뉴얼

Reddit · r/MachineLearning, 원문은 Piotr Nawrot

이 분야에서 논문을 쓰는 연구자가 자기 분야의 벤치마크를 원하는 대로 만드는 방법을 직접 공개했다. 내부자 고발에 가까운 글이라 앞 두 항목의 수치를 어떻게 읽어야 하는지에 대한 교정 장치가 된다.

지적된 수법이 구체적이다. 첫째, 슬라이딩 윈도 어텐션만 써도 5~10배 속도 향상을 보고할 수 있다. 정교한 방법을 만들 필요가 없다. 둘째, 그 윈도 크기를 256으로 잡느냐 512로 잡느냐에 따라 결과가 갈리는데 논문은 유리한 쪽만 싣는다. 셋째, 베이스라인 구현을 불공정하게 만든다. 비교 대상은 2023년 공개 코드를 그대로 쓰고 자기 방법만 Triton으로 최적화하면 속도 비교가 성립하지 않는다.

정확도 벤치마크 쪽 지적이 더 아프다. RULER의 13개 태스크 중 6개가 사실상 같은 needle-in-a-haystack 변형이라, 그 유형에 강한 방법 하나면 평균 점수가 올라간다. AIME는 샘플이 30개뿐이라 80과 79의 차이가 통계적으로 무의미한데 논문 표에서는 80이 볼드 처리된다.

이 글이 오늘 다른 항목과 물리는 지점은 분명하다. 컴팩션 발표가 "800k까지 context rot이 없었다"고 보고하고, 로컬 추론 튜닝 기록이 "MTP로 2.81배"를 보고할 때, 그 수치들이 어떤 조건에서 나왔는지를 묻는 습관이 필요하다는 것이다.

프롬프트 엔지니어링은 상식의 재포장인가

Reddit · r/ClaudeAI Pretend_Sell6592

207업보트에 댓글 111개가 붙은 도발형 글이다. 주장은 짧고 분명하다. 커뮤니티가 Claude Code 프롬프팅을 비밀 기법이 있는 깊은 기술처럼 다루는데, 실제로 유통되는 조언은 구체적으로 쓸 것, 예시를 줄 것, 작업을 쪼갤 것, 엣지 케이스를 언급할 것 정도이며 이는 유능한 주니어 개발자에게 일을 설명하는 방식과 똑같다는 것이다. 저자는 한 걸음 더 나가 "고급 프롬프팅" 콘텐츠의 절반은 기본적인 커뮤니케이션 능력을 Claude 전용 트릭으로 재포장한 것이라고 본다. 그가 인정하는 진짜 역량은 둘이다. 자기 코드베이스를 아는 것, 그리고 원하는 바를 명확히 표현하는 것. 둘 다 특정 모델과 무관하다.

댓글이 111개나 붙었다는 사실 자체가 이것이 합의된 견해는 아니라는 뜻이다. 그리고 같은 날 입력 안에 반대 방향의 구체 사례가 둘 있다. 바로 앞에서 본 모노레포 6원칙(전역 발견 가능 컨텍스트 최소화, 전문 컨텍스트 지연 로딩, 결정론적 연산의 실행 가능화, 에이전트 산출물의 CI 강제, 실제 행동 측정)은 "명확하게 말하기"로 환원되지 않는다. 오늘 뒤에서 다룰 대행사 사다리 역시 프롬프트 개선을 1단으로 두면서도, 그게 충분한지 판별하려면 eval set이 있어야 한다고 못 박는다.

두 입장을 합치면 경계선이 보인다. 단일 대화에서 요구사항을 전달하는 기술은 일반적인 커뮤니케이션 능력에 가깝다. 반면 여러 세션과 여러 개발자에 걸쳐 재현되는 에이전트 행동을 설계하는 일, 즉 컨텍스트 예산을 배분하고 도구를 언제 노출할지 정하고 결과를 측정하는 일은 별개의 엔지니어링 영역이다. 오늘 하루의 무게중심도 후자로 옮겨가 있다.

Cerebras의 사내 지식베이스 - 하루 1.5만 질의를 4신호로

Reddit · r/Rag umur957, 원 자료는 Cerebras 엔지니어링 블로그

실제 운영 규모의 사내 RAG 설계라 참고할 값이 크다. 하루 1만 5,000건의 질의를 처리한다.

검색은 4개 신호를 융합한다. 그리고 결정적으로 retrieval 단계 전체가 LLM-free다. 질의 재작성이나 재순위화에 모델을 쓰지 않는다는 뜻인데, 이 규모에서 지연과 비용을 잡는 가장 큰 선택이다. 융합에는 RRF(reciprocal rank fusion)를 k=60으로 쓰는데, 그 값에서 상위 문서 점수가 0.048, 하위가 0.016으로 벌어져 순위가 실질적으로 갈린다.

전처리 쪽에 재미있는 장치가 둘 있다. 하나가 thread distillation으로, Slack 스레드처럼 잡담과 정보가 섞인 원본을 그대로 색인하지 않고 요약 단계를 거친다. 다른 하나가 bursting 게이트다. 문서를 더 잘게 쪼갤지 판단하는 조건으로 IDF 4.0 이상, 200자 이상, 리액션 존재라는 세 가지를 건다. 리액션을 신호로 쓴다는 게 사내 데이터의 특성을 활용한 부분이다.

후보는 20개를 뽑아 10개로 줄인다. 색인 파이프라인은 CocoIndex를 쓰고 전체 40GB 규모다. 앞서 본 컴팩션 발표가 "400k 토큰에서 dense 검색 회수율 0%"를 보고한 것과 겹쳐 보면, 이 시스템이 왜 단일 임베딩 검색에 의존하지 않고 신호 4개를 섞는지가 설명된다.

RAG인가 파인튜닝인가 - 3단 사다리와 죽는 자리 4곳

Reddit · r/AI_Agents 247Labs_Inc

AI 딜리버리를 업으로 하는 팀이 정리한 판단 기준이다. 사다리는 프롬프트 개선 -> RAG -> 파인튜닝 순서이고, 각 단에서 멈출 수 있으면 멈추라는 것이 기본 논지다.

가장 실용적인 부분은 엔터프라이즈 RAG가 죽는 자리 4곳의 목록이다. 그중 반복해서 강조된 것이 접근 제어다. 접근 제어를 검색 이후 단계로 미루면 두 번 낸다. 색인 시점에 권한 메타데이터를 붙이지 않으면 검색 결과를 받아 다시 필터링해야 하는데, 그러면 상위 k개가 권한 없는 문서로 채워져 실제로 쓸 문서가 남지 않거나, 필터링을 통과시키려 k를 키워 비용이 뛴다.

파인튜닝을 정당화하는 사유는 셋으로 정리되는데, 그중 둘이 성능이 아니라 경제성이다. 같은 품질을 더 작은 모델로 내서 추론 비용을 줄이는 것, 그리고 긴 시스템 프롬프트를 가중치에 흡수시켜 토큰당 비용을 줄이는 것이다. 품질 자체를 올리려는 파인튜닝은 생각보다 드물게 정당화된다는 이야기다.

그리고 어느 단계를 고르든 eval set만은 뺄 수 없는 항목이라고 못 박는다. 앞서 본 Prime Intellect 대담의 결론과 같은 자리다. 참고로 이 팀의 Ben Auffarth 워크숍이 2026년 8월 29일로 예정돼 있다.

오픈웨이트 모델과 로컬 추론

Qwen 3.8 27B - 17GB 파일이 프런티어 근처에 붙었다

개인 블로그 · Simon Willison / Reddit · r/LocalLLaMA anderspitman

Artificial Analysis의 독립 평가에서 Qwen 3.8 27B가 52점을 받았다. 같은 표에서 OpenAI의 5.6 Luna와 동점이고, 파라미터가 27배 넘는 GLM 753B와 비교 대상에 오른다. 오픈웨이트 27B가 이 자리에 붙은 건 이번이 처음이다.

다만 그 점수를 어떻게 받았는지가 함께 봐야 할 부분이다. 출력 토큰이 160M으로 평가 대상 모델 중앙값 43M의 네 배 가까이 됐다. 같은 문제를 풀어도 훨씬 많이 생각하고 훨씬 많이 쓴다는 뜻이고, 그래서 시간당 처리량으로 환산하면 순위가 달라진다. 추론 강도별 소요 시간이 그 차이를 보여준다. xhigh에서 717.8초, low에서 111.6초다.

로컬 실행 조건도 정리돼 돌았다. 16GB 환경에서 컨텍스트 73k로 잡는 설정 블록이 공유됐고, AMD Radeon 6800에서의 실측 수치도 함께 나왔다. r/LocalLLaMA의 관련 스레드는 778업보트에 댓글 316개를 모았는데, 다만 그 스레드에는 세부 항목별 점수가 실려 있지 않아 "어느 영역에서 강한가"는 이 자료만으로 말할 수 없다.

반론도 붙었다. 벤치마크에 과적합됐다는 이른바 benchmaxxed 의혹, 그리고 특정 상용 모델에서 증류했다는 Empero 관련 주장이 있었는데 후자는 검증된 바 없다. 오픈웨이트 모델이 상위권에 올라올 때마다 반복되는 형태의 의심이라, 독립 평가가 여러 곳에서 쌓이기 전까지는 판단을 미루는 게 맞다.

참고로 표에 표기된 DeepSeek 파라미터 값이 "1.6B"로 나와 있는데 문맥상 1.6T의 오기로 보인다. 확인이 필요하다.

원 하나에 몇 분 - Simon Willison의 실사용 리뷰

개인 블로그 · Simon Willison

같은 모델을 자기 장비 두 대(128GB M5 Max MacBook Pro, NVIDIA DGX Spark)에서 며칠 굴려본 리뷰다. 결론이 두 문장으로 갈린다. 모델 자체는 로컬에서 돌릴 수 있는 것 중 최고인데, 기본 설정은 절대 그대로 쓰면 안 된다.

문제는 성능이 아니라 기본값이었다. Qwen 문서가 reasoning_effortxhigh, medium, low 세 단계로 두고 기본을 xhigh 잡았고, LM Studio GGUF도 그 기본을 그대로 보존한다. 저자 표현으로는 "hilarious한 기본값"이다. LM Studio의 기본 컨텍스트 한도 8,192 토큰은 가장 평범한 문제를 생각하는 데만으로 다 소진됐고, 최대치인 262,144 토큰으로 올려서야 사라졌다.

수치가 이 과잉을 정확히 보여준다. 저자의 고정 벤치마크인 "자전거 탄 펠리컨 SVG"를 컨텍스트를 늘린 뒤 돌렸더니 21분이 걸렸고 추론 토큰 22,276개를 태워 출력 3,223 토큰을 냈다. 결과물은 로컬 실행 모델 중 최고였다. 자전거 프레임이 정확하고, 다리가 자전거 양쪽에 하나씩 있으며(저자가 "매우 드물다"고 강조한 항목), 부리 주머니가 뚜렷하고, 날개가 핸들바까지 닿고, 해와 구름과 언덕과 꽃까지 붙었다. 그런데 저자의 평가는 "21분 기다릴 가치가 있었나? 전혀 없다"이다. 추론을 끄면 137초에 3,715 토큰으로 끝난다.

극단은 draw an svg of a circle이었다. 추론 트레이스가 "단순한 요청이지만 정성 들인 작품으로 만들고 싶다"로 시작해서 컴퍼스 제도 느낌의 동심원 가이드, 눈금, 그라디언트, 회전 대시 링, 팔레트 후보(딥 틸 잉크 대 바우하우스풍 버밀리언)까지 스스로 고민한 뒤 몇 분에 걸쳐 애니메이션 작품을 내놨다. 요청한 것과 다른 물건이다.

비전은 확실히 좋았다. 사진 속 펠리컨에 0~1000 스케일 bounding box JSON을 요구했더니 실제 위치와 잘 맞는 좌표를 냈다. 흥미로운 건 그 박스를 그리는 HTML 도구를 만들게 했을 때인데, 추론을 켠 채로는 요청하지 않은 데모 씬까지 붙은 과설계가 나왔고 추론을 끄니 박스가 엉뚱한 위치에 그려지는 반쯤 동작하는 결과가 나왔다. 과잉 추론이 순수한 낭비만은 아니었다는 뜻이다.

코딩 에이전트 루프도 통과했다. 시스템 프롬프트가 짧다는 이유로 Pi를 골라 tailscale serve로 노출한 DGX Spark의 LM Studio 엔드포인트를 등록했고, datasette 저장소에서 "how does auth work?"를 물었더니 여러 파일을 툴 콜로 열어본 뒤 "매우 견고한" 답을 냈다.

남은 병목은 속도다. LM Studio에서 15~30 tokens/sec가 나오는데, Artificial Analysis 기준 OpenAI 5.6 Sol이 74 tok/s, Luna가 184 tok/s이라 호스팅 API와 정면 비교가 안 된다. 커뮤니티가 이틀 만에 찾아낸 가속 경로가 모델에 내장된 Multi-Token Prediction이고, llama.cpp 제작자 Georgi Gerganov가 공유한 설정으로 돌리니 기본 GGUF 대비 약 72% 빨라졌다(비교 벤치마크는 저자가 Codex의 GPT-5.6에게 시켜 수행).

Lobsters 댓글은 "과잉 추론"이라는 프레임 자체를 반박한다. nelson은 이게 과잉 사고인지 아니면 복잡한 태스크를 잘하는 방식 그 자체인지가 논쟁 중이라며, 몇 달 전 Claude 신모델도 토큰을 훨씬 많이 쓰면서 확실히 더 잘했던 전례를 든다. vpr은 thinking trace를 모델이 문자 그대로 "생각하는" 것으로 오해하는 사람이 많은데 그건 latent space를 통과하는 과정의 부산물이라며 Huginn(arXiv 2502.05171)을 근거로 든다. Yogthos는 "쉬운 문제는 예산을 제한해 과설계를 막고, 큰 문제는 시간을 쓴 만큼 결과가 좋아지는 것 같다"로 정리한다.

저자의 마무리 논지는 벤치마크 순위가 아니다. 긴 컨텍스트, 신뢰할 만한 툴 콜링, 강한 비전, 쓸 만한 코드 생성을 모두 갖춘 범용 오픈웨이트 모델이 17GB 파일 하나에 들어갔고 데이터센터급 하드웨어에 50만 달러를 쓸 필요가 없다는 것이다. 발목을 잡는 건 dense 모델이 메모리 대역폭을 많이 먹는다는 사실이지 모델 품질이 아니다.

24GB 한 장에 256K를 밀어 넣은 튜닝 기록

Hacker News · 개인 블로그

같은 모델을 24GB GPU 한 장에서 256K 컨텍스트와 비전까지 켠 채로 굴리기 위해 밀어붙인 기록이다. 최종 프로덕션 설정에서 평균 50.441 tok/s가 나왔다.

수치가 촘촘하다. 커스텀 빌드로 +21.97%, Multi-Token Prediction으로 2.81배를 얻었다. 다만 컨텍스트를 261.5K까지 실제로 채운 상태에서는 12.606 tok/s로 떨어진다. 양자화는 5.01 BPW다.

가장 값진 관찰은 실패한 시도 쪽이다. 드래프터 모델에 정밀도를 조금 더 주려고 69 MiB를 추가했더니 처리량이 26.60% 떨어졌다. 메모리 여유가 남아 있어도 그 여유를 쓰는 순간 다른 것이 밀려난다는 뜻이고, 저자가 뽑아낸 문장이 그대로 교훈이다. "산술적 여유 메모리는 운영 여유가 아니다." MTP의 n 값 스윕 결과가 비단조여서 큰 값이 항상 좋지 않았다는 것, DSpark 사이드카 구성이 오히려 46.6% 느렸다는 것도 함께 기록돼 있다.

방법론 원칙 하나가 특히 인용할 값이 있다. 로드만 되는 것을 두고 "256K 지원"이라고 말하지 않는다는 것이다. 컨텍스트를 실제로 채운 상태의 처리량을 재야 그 설정이 쓸 수 있는 것인지 알 수 있다. batch-invariance 이슈(#25618)도 언급됐다.

HN 반응에서 문체 비판이 붙은 것도 기록할 값이 있다. simonw가 "읽기 지친다"며 분량을 줄이라고 지적했다. 밀도 높은 실측 기록과 읽히는 글이 같은 것이 아니라는, 오늘 여러 곳에서 반복된 지적 중 하나다.

Apple Silicon에서 3B 모델이 조용히 실패하는 다섯 가지

Hugging Face Papers · John Halloran (arXiv 2608.13987)

로컬 추론의 반대 극단이다. Nanbeige4.2-3B를 Apple Silicon에서 돌리며 발견한 로딩 버그 5종을 정리한 논문인데, 성능 문제로 보이던 것이 실은 로딩 문제였다는 구조가 반복된다.

가장 위험한 것이 RoPE 관련 버그다. inv_freq 텐서가 0으로 채워지는데 예외가 발생하지 않는다. 위치 인코딩이 사실상 무력화된 채 모델이 정상적으로 실행되고 그럴듯한 텍스트를 낸다. 조용한 실패라 벤치마크 점수가 낮게 나와도 원인을 모델 품질로 오해하기 쉽다.

메모리 쪽에서는 long-text 프리필이 예상의 두 배를 쓰는 문제가 있었다. chunked prefilling을 적용해 처리 가능한 길이를 4,096에서 11,231 토큰으로 약 2.7배 늘렸는데, 대가로 22.8~40.9%의 속도 저하가 따랐다. 공짜가 아니라는 걸 명시한 점이 좋다.

가장 미묘한 것이 chat 템플릿 문제다. 시스템 메시지가 있으면 템플릿이 학습 시 쓰인 도구 프롬프트를 다른 것으로 교체해버린다. 차이가 \n\n 두 문자 수준이라 눈으로는 안 보이는데, 도구 호출 정확도가 무너진다.

그 영향이 벤치마크로 확인된다. MCPMark는 원본 상태에서 평가 자체가 불가능했고 패치 후 10건 중 3건(30%)을 통과했다. BFCL의 parallel 카테고리는 30건 중 1건(3.3%)이었다. 소형 모델을 로컬에서 평가할 때 낮은 점수를 곧바로 모델 탓으로 돌리기 전에 로더와 템플릿을 먼저 봐야 한다는 사례다.

llama.cpp에 v0.1.0 태그가 튀어나온 사건

Hacker News · ggml-org/llama.cpp 릴리스

스타 12만 4,000개짜리 프로젝트에 갑자기 v0.1.0 태그가 나타났다. 실제 소스 버전은 v0.20.1인데 릴리스 태그만 처음으로 돌아간 모양새라 커뮤니티가 술렁였다.

8월 17일 09시 08분에 github-actions가 v0.1.0 태그를 달았고 4시간 뒤 v0.1.1도 나왔다. 저장소 규모는 스타 12만 4,000개에 포크 2만 1,800개, 열린 이슈 761건과 PR 1,400건이다.

ggerganov 본인이 직접 답했다. 여기 올라올 줄 몰랐으니 일단 무시해달라는 것, 그리고 llama.cpp의 공식 시맨틱 버저닝을 준비 중이고 거의 다 됐지만 아직 완전히는 아니라는 것이다. 버저닝 과정 설명은 ggml 저장소 discussion #1579에 있다. 지금까지는 커밋 단위 버저닝뿐이라 따라가기 어려웠다는 환영 반응이 나왔다.

댓글은 major version zero 논쟁으로 흘렀다. 0.x로 출시하면 시맨틱 버저닝이 무의미해진다는 지적이었는데, 지적한 본인이 곧바로 체념하는 대목이 이 스레드의 압권이다. 아무도 진지하게 안 받아들이는데 자기 목소리가 무슨 의미가 있겠냐며, 0ver.org가 업계가 소프트웨어 버저닝에 별로 신경 쓰지 않는다는 것을 보여주니 차라리 가식을 버리고 커밋 해시와 날짜를 쓰라고 하는 게 낫겠다고 했다.

릴리스 운영에 대한 실용적 불만도 나왔다. asveikau는 이 프로젝트의 GitHub 릴리스 페이지가 누구를 위한 것인지 모르겠다고 했다. 하루에 릴리스가 여러 번 나오고 리눅스 릴리스 바이너리는 CUDA로 컴파일되지도 않아서, 많은 사람에게는 master를 따라가며 소스에서 빌드하는 편이 더 합리적이라는 것이다.

이 작은 사건을 남기는 이유는 앞의 Qwen 튜닝 기록과 붙기 때문이다. 그 저자는 PR 여섯 개를 감사된 커밋 해시로 핀하고 어떤 PR head가 움직이면 빌드를 거부하도록 빌더를 만들었다. 시맨틱 버저닝이 붙으면 그런 수작업 고정의 상당 부분이 표준화될 수 있다. 로컬 추론 스택이 실험 단계에서 인프라 단계로 넘어가는 국면을 보여주는 신호다.

Grok 4.6 벤치마크와 파라미터 추정

Threads · @sonnmanner

Grok 4.6의 벤치마크 결과가 돌면서 파라미터 규모 비교도 함께 나왔다. Grok이 1.5T, GLM이 744B-A40B로 표기됐다. 작성자의 논지는 알려진 크기로는 공개된 점수가 나오기 어렵다는 것인데, 그렇다면 점수 차이가 규모가 아니라 학습 방식에서 왔다는 뜻이 된다. 추정된 방식은 사람이 seed 데이터 수천 개를 만들고 그것을 AI로 베리에이션해 합성 데이터를 양산한 뒤 SFT와 RL을 도는 구조다. 이 학습 방식 서술은 공개된 값이 아니라 추정이므로 그대로 인용하면 안 된다.

더 짚을 값이 있는 것은 벤치마크 구성 비판이다. 공개된 평가가 밸류가 높은 "코딩과 에이전틱 업무 수행"에 몰려 있고, 시맨틱 분석이나 전략적 판단처럼 측정이 어렵지만 사용자가 체감하는 영역은 거의 버려져 있다는 것이다. 같은 날 나온 Sparse Attention 벤치마크 조작 매뉴얼과 GPT-5.6 Sol의 항목별 엇갈린 결과를 옆에 두면, 무엇을 재느냐가 무엇을 잘하느냐만큼 순위를 정한다는 이야기가 세 번째로 반복된다.

실사용 쪽 반응은 가격에 몰렸다. 월 99달러 이벤트가로는 계속 쓰겠지만 정가로는 비싸다는 평이 주를 이뤘고, "원래 월 100달러에 기대하는 수준이 이 정도는 되어야 하지 않았나"라는 자문이 붙었다. 한국 사용자들 사이에서는 할인 요금제를 가리키는 은어가 통용되고 있고, SuperGrok과 Cursor를 동시 구독할 때의 이득을 묻는 글도 나왔다. 프런티어 모델 구독 가격대가 20달러 근처에서 200달러 근처로 벌어지는 중이라, 그 사이 구간을 실험하는 사례로 볼 만하다.

TRL 델타 동기화 - 1.2GB를 25MB로

LinkedIn · Sergio Paniego Blanco (Hugging Face)

강화학습 루프에서는 학습된 가중치를 추론 엔진으로 계속 넘겨야 한다. 정책이 갱신될 때마다 롤아웃을 뽑는 쪽도 새 가중치를 받아야 하기 때문인데, 이 전송이 반복되면서 병목이 된다.

출발점이 된 관찰이 단순하고 강하다. bf16 가중치의 약 99%가 연속된 옵티마이저 스텝 사이에서 비트 단위로 동일하다. 학습 스텝 하나가 실제로 바꾸는 비트가 그만큼 적다는 뜻이다. 그래서 TRL이 전체 모델 대신 델타만 vLLM에 동기화하도록 바꿨다.

결과가 스텝당 1.2GB 전송에서 약 25MB로, 약 48배 축소다. 알고리즘을 바꾸지 않고 데이터 이동만 줄여 얻은 개선이라, 같은 구성에서 바로 적용할 수 있는 종류다. 참고로 이 글은 Hugging Face post-training 팀이 쏟아내는 블로그를 하나씩 소개하는 시리즈의 첫 편이다. 앞서 본 GPU 스케줄링 연구가 "구조가 정교함을 이긴다"고 정리한 것과 같은 성격의 개선인데, 둘 다 모델을 건드리지 않고 자원 이동 방식만 바꿨다.

프런티어 모델: 가격, 비전, 라우팅

GPT-5.6 Sol의 비전 - 탐지는 3배, OCR은 후퇴

Roboflow 블로그 · Piotr Skalski

컴퓨터 비전 회사가 GPT-5.6 Sol을 자기 평가 세트로 돌린 기록이다. 결론이 한쪽으로 쏠리지 않아서 오히려 쓸모가 있다.

객체 탐지가 크게 올랐다. mAP가 13.8에서 46.2로 뛰었다. 이전 세대에서 사실상 못 쓰던 수준이 실용 구간에 들어온 것이다. 반면 OCR은 91.2에서 90.7로 후퇴했고, 문서에서 구조화된 값을 뽑는 추출 태스크는 87.6에서 82.5로 더 크게 떨어졌다. 세대가 올라가면 모든 항목이 개선된다는 가정이 여기서 깨진다.

가장 실무적인 발견은 좌표 포맷이다. 같은 모델에 같은 이미지를 주고 좌표를 요구하는 형식만 바꿨더니 mAP가 15만큼 움직였다. 프롬프트 수정 한 줄이 모델 세대 차이만 한 폭을 만든다는 뜻이라, 비전 평가표를 볼 때 출력 포맷이 명시돼 있지 않으면 그 표를 신뢰하기 어렵다. 2000픽셀 이상 이미지에서 결과가 불안정해지는 문제는 OpenAI 쪽에서도 확인됐다.

비용 비교도 붙어 있다. 이미지당 약 2.5센트인데 Gemini 3.5 Flash가 0.8센트다. 세 배 차이라, 대량 처리 파이프라인에서는 정확도 차이가 그 격차를 정당화하는지 계산이 필요하다.

한 가지 단서를 그대로 옮긴다. **저자 본인이 "4주 전에 썼는데 벌써 낡았다"**고 밝혔다. 원문 작성이 7월 중순이고 그 사이 모델과 API가 움직였으므로, 절대 수치보다 "항목별로 방향이 다르다"는 구조를 가져가는 게 안전하다.

Sol 가격 50% 인하 - 단 OpenRouter 한정

Hacker News · OpenRouter 모델 페이지

GPT-5.6 Sol의 가격이 절반으로 떨어졌다. 입력 100만 토큰당 5.00달러에서 2.50달러로, 출력은 30.00달러에서 15.00달러로, 캐시는 0.50달러에서 0.25달러로 내려갔다. 해당 제공자 기준 레이턴시는 3.33초에 42 tps다. Sol은 GPT-5.6 시리즈의 플래그십으로 컨텍스트 100만, 출시 2026년 7월 9일, 지식 컷오프 2026년 2월이고, 복합 추론과 코딩, 특히 커맨드라인과 다단계 코딩 작업에 강하다는 포지셔닝이다. 다른 제공자들은 5.00/30.00 또는 5.50/33.00 구간에 있고 처리량은 14에서 65 tps로 편차가 크다.

중요한 단서가 있다. 이 인하는 OpenRouter 경유에 한정되며 OpenAI 네이티브 API 가격이 아니다. 특정 제공자 라우팅에 걸린 할인이라 직접 호출 비용은 그대로다. 이런 종류의 혼동은 모델 가격 소식에서 반복되므로, 인하 소식을 보고 예산을 다시 잡기 전에 자기 호출 경로가 어디인지 먼저 확인해야 한다.

가격보다 앞서는 제약이 데이터 취급 정책이라는 증언이 함께 나왔다. 한 사용자는 자기 유스케이스 다수에서 사실상 Anthropic과 OpenAI 둘 중 하나인데 양쪽 모두와 Zero Data Retention 계약이 있기 때문이라고 적었다. 임의의 추론 제공자에게 민감 데이터를 맡길 생각이 없다는 것이다. 라우터가 아무리 싼 경로를 찾아줘도 ZDR 계약이 없으면 후보에서 빠진다는 뜻이라, 규정 요건이 강한 곳일수록 라우팅 계층의 가격 이점을 온전히 못 가져간다.

품질 쪽 불만도 하나 붙었다. 5.6이 단순 과제에서 오히려 더 나쁘고 자주 과잉 복잡화한다는 것인데, 사용자 할일 목록을 써달라 했더니 4쪽짜리 에세이가 나왔고 같은 과제를 5.4에 주니 기대한 체크박스 목록이 나왔다고 했다. 답변은 추론 수준 설정이 사용자 책임이고 단순 과제에는 instant 모델을 쓰라는 것이었다. 뒤에서 볼 Luna/Terra/Sol 배정 규칙이 필요한 이유가 여기 있다. 경쟁 구도로는 Grok 4.6이 100만 토큰당 6달러로 "Sol과 비슷한 지능"이라는 주장이 나왔고 곧바로 믿지 못하겠다는 반박이 달렸다. Luna는 가격 인하 후 사용량이 크게 뛰었다는 관찰도 있었다.

같은 결과를 20% 적은 토큰으로 - 벤더 제작 영상

YouTube · OpenAI 공식 채널, 사례 기업 Base44

GPT-5.6이 같은 결과를 내면서 토큰을 20% 덜 쓴다는 주장이 담긴 영상이다. 제작 주체가 모델 공급사 본인이고 사례 기업도 함께 등장하는 벤더 콘텐츠라는 점을 먼저 밝힌다. 독립 검증이 아니므로 수치를 그대로 받아들일 자리가 아니다.

주장 자체는 앞서 본 컨텍스트 경제학 논의와 맞물린다. 토큰 20% 감소는 캐시 할인과 곱해지면 실제 청구액에서 더 큰 차이를 만든다. 다만 그 20%가 어떤 태스크 집합에서, 어떤 추론 설정으로 측정됐는지는 영상에서 확인되지 않는다.

한 가지 주의할 점이 있다. 이 영상의 자동 전사에서 "Soul and Terra"로 들리는 대목이 있는데 모델명 Sol과 Terra의 전사 오류일 가능성이 높다. 그대로 인용하지 않는 게 안전하다.

Luna / Terra / Sol을 업무 기준으로 배정하기

Threads · @crazy.codex

모델 라인업이 늘어날수록 실무자가 겪는 문제는 성능 비교가 아니라 배정이다. 이 글은 거기를 정확히 친다. 출발 질문이 **"PPT 하나 만들어줘는 AI한테 쉬운 일일까"**인데, 답은 그 요청이 무엇을 뜻하는지에 따라 완전히 갈린다. 기존 자료를 정해진 템플릿에 옮기는 일일 수도 있고, 여러 자료를 읽고 경영진이 결정할 자료를 만드는 일일 수도 있다. PPT 제작, 보고서 작성, 코딩 모두 같은 이름 아래 난이도가 다른 일이 섞여 있어서, 업무 이름만 보고 모델을 고르면 어긋난다.

작성자는 OpenAI의 현재 설명을 업무 언어로 번역한다. Luna는 빠르고 반복적인 일, 추출과 분류와 정리, 범위가 좁은 코딩에 쓴다. Terra는 보고서와 문서 분석, 일상적인 production 업무, 일정 수준의 판단이 필요한 코딩에 쓴다. Sol은 문제가 모호하고 여러 자료가 충돌하는 일, 복잡한 추론, 고난도 코딩, 실패 비용이 큰 판단에 쓴다.

실제로 쓸모 있는 것은 판별 기준이다. Luna부터 시험해볼 업무는 입력 위치와 결과 형식이 이미 정해져 있거나, 원본과 결과를 비교하기 쉬운 일이다. 이 기준은 모델 이름이 바뀌어도 유지되는 종류의 규칙이고, 일반화하면 검증 비용이 낮으면 싼 모델부터 시도하고 검증 비용이 높으면 처음부터 비싼 모델을 쓰라는 뜻이 된다. 절약이 아니라 오류의 발견 비용을 기준으로 삼는 것이다.

제시된 Luna 예시 여섯 개는 그대로 체크리스트로 쓸 수 있다. 회사 PPT 템플릿에 행사명, 날짜, 연사, 목차 옮기기. 기존 30장 자료에서 제목과 요점만 뽑아 10장짜리 초안 만들기. 회의록에서 담당자, 할 일, 마감일을 찾아 표로 정리하기. 설문 답변 200개를 미리 정한 다섯 가지 항목으로 분류하기. 여러 파일 이름을 규칙에 맞게 바꾸고 폴더별로 정리하기. 작성된 메일의 맞춤법을 고치고 정해진 말투로 바꾸기.

바로 앞의 Grok 벤치마크 항목과 나란히 두면 대비가 선명하다. 한쪽은 벤치마크 점수가 어느 항목에 몰려 있는지를 의심하고, 다른 한쪽은 벤치마크를 아예 보지 않고 업무의 검증 가능성으로 모델을 배정한다. 조직에서 모델 가이드를 쓸 때 실제로 필요한 건 후자에 가깝다. 이 규칙이 앞서 본 Qwen 3.8 27B의 추론 강도 논쟁과 같은 형태라는 점도 짚을 만하다. 쉬운 문제에 xhigh를 물리면 시간과 비용이 낭비되고, 어려운 문제에 low를 물리면 결과가 반쯤 동작한다.

Stripe가 OpenRouter를 70억 달러에 - 라우터가 결제 레이어로

Latent.Space AINews · 원 보도 Bloomberg, The Information

오늘 최대 규모 딜이다. Stripe가 모델 라우터 OpenRouter를 70억 달러에 인수했다. 시리즈B 90일 후의 거래이고, 보도된 배수가 50배다.

숫자가 이 가격을 설명한다. OpenRouter는 월 250조 토큰을 중계하고 개발자 800만 명이 쓴다. 총이익률은 70%로 보도됐다. 결제 회사가 토큰 중계 계층을 사는 이유가 여기서 드러난다. 에이전트가 돈을 쓰는 시대에는 API 호출 자체가 과금 이벤트이고, 그 흐름 위에 앉는 것이 결제 인프라의 자연스러운 확장이다.

리스크도 함께 지적됐다. OpenRouter의 경쟁력 일부는 마크업을 거의 0으로 유지한 데서 왔는데, 인수 후 마진을 올리면 그 이점이 사라지고 개발자가 직접 호출로 돌아갈 수 있다. 압축된 마진 위에 세워진 거래라 통합 방식이 성패를 가른다.

같은 날 정리된 다른 소식들도 함께 옮긴다. OpenAI가 오하이오에 8GW 규모를 발표했다. Agent Arena가 170만 세션을 기록했다. 에이전트 스킬 연구에서 **절차를 앵커링할 때 65.7%, 사실을 주입할 때 4.5%**라는 효과 차이가 보고됐다. GPT-5.6 Sol이 ARC-AGI-3에서 13.3%에서 38.3%로 오르면서 동시에 토큰을 6배 적게 썼다. Cartesia가 Sonic 3.6을, NVIDIA가 Nemotron 3.5 Lightning을 냈다. 그리고 Qwen 계열 누적 다운로드가 30억 건을 넘었다.

AI가 판단에 들어갈 때 - 법률과 사법

법률 인용 검증 - 모델은 "체크 안 함"이 아니라 "체크했다고 지어냄"

Hugging Face Papers · Apurv Verma, Bloomberg (arXiv 2608.12571)

법률 문서의 인용이 실제로 그 출처가 말하는 바를 지지하는지 검증하는 태스크를 놓고 프런티어 모델들을 평가한 논문이다. 결과가 두 겹으로 불편하다.

첫 겹은 난도 격차다. Easy 세트에서는 **93100%**가 나오는데, Hard 세트에서는 판결문 기준 36.5~60.6%, 준비서면 기준 **51.582.7%**로 떨어진다. 최상위 설정인 GPT-5.4에 high 추론을 붙여도 판결문에서 40%를 놓쳤다. 그리고 모델 서열이 뒤집힌다. Opus 4.6이 Sonnet 4.6보다, Sonnet 4.6이 Sonnet 4보다 낮았고, GPT-5.4가 GPT-5보다 낮았다. 최신 모델이 이 태스크에서 더 나쁘다는 뜻이라, 범용 벤치마크 순위를 도메인 태스크에 그대로 옮기면 안 된다는 사례다.

둘째 겹이 더 중요하다. 실패의 성격이 "확인하지 않음"이 아니라 "확인했다고 지어냄"이었다. 모델이 놓친 사례의 3분의 2에서 출력에 "expressly states"(명시적으로 진술한다) 같은 확언 표현이 들어 있었다. 축자 인용을 틀린 경우의 92%는 원문에 존재하지 않는 문장을 인용부호 안에 넣은 것이었다. 검증 도구로서 가장 나쁜 실패 형태인데, 사용자가 "모델이 확인했다"고 읽게 만들기 때문이다.

완화책도 반쪽이었다. 페이지 단위 근거를 함께 요구하는 page-grounded 프롬프트가 재현율을 올리긴 했지만 거짓 양성률도 함께 1.0~24.7퍼센트포인트 올랐다. 논문의 정리 문장이 이 상황을 요약한다. 모델을 회의적으로 만들 수는 있어도 선택적으로 회의적이게 만들지는 못한다. 의심을 늘리면 맞는 인용까지 의심하고, 줄이면 틀린 인용을 통과시킨다.

판결을 전부 AI에 맡겼어도 판사는 면책된다

Hacker News · The Volokh Conspiracy (Eugene Volokh)

Phillips v. Parlade에서 네바다 연방지방법원 Navarro 판사가 내린 판단이다. 원고는 담당 판사가 판결을 AI에 맡겼다고 주장했는데, 법원의 답은 그 주장이 사실이더라도 사법면책(judicial immunity)이 적용된다는 것이었다. 판결문의 표현이 **"even if the allegations are correct"**다.

법리 자체는 새롭지 않다. 사법면책은 판사가 사법 기능 범위 안에서 한 행위에 대해 손해배상 소송을 막고, 그 판단이 틀렸거나 부주의했더라도 마찬가지다. 잘못된 판결에 대한 구제는 손해배상이 아니라 항소와 사법 징계 절차를 통해서만 이뤄진다.

문제는 그 구제 경로가 이 상황에 잘 맞지 않는다는 점이다. 앞 항목이 보여줬듯 모델은 "확인했다"고 쓰면서 확인하지 않는다. 판결문에 그런 확언이 실려 있으면 항소심에서도 그 서술을 근거로 받게 되고, 어느 대목이 생성됐는지 밖에서는 알 수 없다. 사법 징계는 판사가 무엇을 했는지에 대한 기록이 있어야 작동하는데 그 기록도 남지 않는다. AI 사용 사실을 판결문에 공개하도록 요구하는 규칙이 왜 논의되는지가 이 사건에서 설명된다.

AI 텍스트를 가려내기 - 워터마크, 문체, 거절

워터마크는 글자가 아니라 단어 선택에 산다

declaude.org · James Padolsey

평문 텍스트에 워터마크를 넣는다는 건 직관적으로 불가능해 보인다. 픽셀도 없고, 복사-붙여넣기를 견디는 메타데이터도 없고, 모든 글자가 그대로 눈앞에 있다. 그런데 마크는 실재한다. 이 글은 그 원리를 5단계 도해로 설명한 교육용 자료인데, 지금 시점에 중요한 이유는 첫 단락의 사실 관계에 있다.

Google은 2024년부터 Gemini 앱과 웹 경험에서 나온 텍스트를 워터마킹해왔고(API는 작성 시점 기준 문서화된 예외), 2026년 8월부로 Claude의 신규 모델들이 모델 레벨에서 텍스트를 마킹하기 시작했으며 이전 모델들도 뒤따를 예정이다. 출처는 Anthropic Help Center의 "How Claude marks AI-generated content"다. 논문 속 이야기가 아니라 지금 쓰는 도구의 출력에 들어가 있는 기능이라는 뜻이다.

1단계. 모델은 매 단어마다 가중치 붙은 주사위를 굴린다. 문장 중간에서 다음 단어를 아는 게 아니라 선호도가 붙은 후보 목록을 갖고, 그중 상당수 갈림길에서는 여러 선택지가 똑같이 자연스럽다. 그 여유가 재료다.

2단계. 키가 후보 목록에 몰래 색을 칠하고 한쪽을 민다. 고전적 레시피(Kirchenbauer et al. 2023)는 비밀 키 기반 연산으로 후보를 green과 red로 가르고 주사위를 green 쪽으로 조금 기울인다. 교묘한 지점이 둘이다. 밀어주는 정도가 약해서 red 단어도 여전히 이길 수 있고, 색칠이 단어의 고정 속성이 아니다. 키는 직전 몇 단어로부터 색을 계산하므로 같은 후보가 어떤 앞맥락에서는 green이고 다른 맥락에서는 red다. 프로덕션에 들어가 있는 Google SynthID는 그 nudge를 작은 비밀 토너먼트로 대체해, 키의 추첨을 평균 내면 모든 단어의 확률이 모델 의도 그대로 유지되게 만든다. OpenAI에서 나온 Aaronson의 스킴은 주사위 굴림 자체를 키에서 유도한다.

3단계. 탐지는 다시 칠하고 세는 것뿐이다. 탐지기는 텍스트를 읽지도 문체를 판단하지도 않고, 키 보유자의 색칠을 재생해 green이 몇 번 나왔는지 센다. 마크가 없거나 키가 틀리면 약 50%, 동전 던지기다. 여기서 저자가 밝히는 한계가 중요하다. 데모는 눈에 보이라고 기울기를 세게 줬지만 프로덕션 마크는 훨씬 부드럽게 기울고 그만큼 더 많은 텍스트를 요구한다. 데모의 50/50 모델에서는 1,500단어 문서가 겨우 약 55% green에서 플래그된다. 작은 기울기는 길이를 통해서만 설득력을 얻고, 그래서 짧은 텍스트는 진짜로 판정이 어렵다.

4단계. 편집은 정확히 run이 끊기는 자리에서만 마크를 지운다. 어떤 위치가 증거로 카운트되려면 원본 표현의 짧은 window가 온전히 살아남아야 한다. 실측이 있다. MarkLLM의 KGW와 EXP 스킴을 오픈 모델에 적용하고 full-rewrite 경로로 세탁했더니 약 0.5%의 window만 살아남았고 탐지 정확도가 사실상 확실에서 동전 던지기로 떨어졌다(AUC 0.99에서 약 0.5). 반대로 context-free unigram 마크는 살아남는다(AUC 0.73~0.84). 방향이 중요한데, 가볍거나 한 번 돌린 패러프레이즈는 마크를 삭제하는 게 아니라 희석할 뿐이다. Kirchenbauer et al.의 실험에서는 사람이 직접 한 패러프레이즈조차 약 800 토큰(약 600단어)이 넘으면 다시 탐지 가능해진다.

5단계. 탐지는 사적이고, 확률적이며, 저작이 아니라 처리에 대한 것이다. 워터마크는 "이 글을 누가 썼는가"를 말해주지 않는다. "이 텍스트가 특정 모델을 거쳐 나왔는가"에 대한 확률적 증거이고 그 검사는 키 보유자만 할 수 있다. 전문가용 각주로 잔여 증거 모델을 z ≈ f·√N·z₁로 제시한다(f는 살아남은 비율, N은 길이, z₁은 토큰당 강도).

경계도 정직하게 적혀 있다. 이 수치들은 측정 가능한 오픈 구현에서 나온 것이고, Anthropic의 프로덕션 스킴은 비공개라 Anthropic 밖의 누구도 Claude 자체 마크에 대해 이 테스트를 돌릴 수 없다.

SynthID는 base64로 응답받으면 뚫린다

Hacker News · 텍스트 포스트

앞 항목의 원리에 대한 구체적 우회 사례다. 모델에게 답을 base64로 인코딩해서 달라고 하면, 인코딩된 토큰열에는 워터마크가 실리지만 디코딩한 평문에는 실리지 않는다. 마크가 토큰 선택에 사는데, 사용자가 최종적으로 쓰는 텍스트는 그 토큰열이 아니라 디코딩 결과이기 때문이다.

같은 논리가 다른 변환에도 적용된다. 모델에게 특정 규칙으로 치환된 형태를 요구하고 사람이 되돌리면, 마크가 걸리는 토큰열과 실제로 쓰이는 텍스트가 분리된다. 앞 항목의 4단계에서 본 "표현의 run이 끊기면 증거가 사라진다"는 성질의 극단적 버전이다.

한 가지 표기를 정확히 해둔다. 이 글에서 언급된 Anthropic의 워터마킹 도입은 "계획"으로 서술된 전제이고, 이 게시물 자체가 그 도입을 확인한 1차 자료는 아니다. 앞 항목의 Help Center 인용이 더 직접적인 근거다.

실무적으로 정리하면 이렇다. 워터마킹은 평범한 사용 경로에서 출처를 확인하는 장치이지 의도적 회피를 막는 장치가 아니다. 앞 항목이 보여준 대로 마크는 토큰 선택의 통계에 얹혀 있고, 그 통계를 건드리는 모든 변환(전면 재작성, 인코딩 요청, 치환 규칙)이 마크를 지우거나 희석한다. 반대로 그 사실이 탐지기의 무용을 뜻하지도 않는다. 우회하려면 우회하려는 의도와 절차가 필요하고, 그 절차 자체가 오늘 다룬 AI;DR 논쟁이 겨냥하는 지점, 즉 "검토했는가"라는 질문으로 되돌아온다.

AI 문체는 언어마다 다른 단어로 티가 난다

Hacker News · Ask HN, 일본어 원어민 작성자

기계 판별의 반대편이다. 작성자는 일본어 원어민이고, 여전히 단어 선택만으로 AI가 쓴 일본어를 대개 알아본다고 말한다. 구체적인 예시를 든 게 이 글의 가치다.

과다 출현하는 단어로 実務(실무)와 帳簿(장부)를 든다. 통계적으로 있을 법한 것보다 훨씬 자주 나온다는 것이다. 구어체 쪽에서는 効く(효과가 있다, 잘 듣는다)와 刺さる(찌르다에서 파생해 "마음에 꽂힌다")가 원래는 다른 단어가 먼저 떠올라야 할 자리에 온다. 작성자는 이것들을 **"일본어판 delve"**라고 부른다. 영어권에서 delve가 AI 문체의 상징이 된 것과 정확히 같은 종류의 신호라는 뜻이다.

자기 한계도 밝힌다. 영어 원어민이 아니라 확신할 수 없지만 영어 AI 텍스트는 최근 많이 좋아져 예전만큼 골라내기 쉽지 않다는 인상이라는 것이다. 중국어는 가장 많이 학습된 언어 중 하나이니 영어만큼 개선됐을 것이라 추정하고, 스페인어와 힌디어처럼 사용자가 많은 언어는 어떤지 질문으로 남겼다.

더 실무적인 주장은 그다음이다. 영어를 벗어나면 어떤 모델을 쓰느냐가 훨씬 큰 차이를 만든다. 작성자의 첫 "싱귤래리티 순간"은 Gmail의 AI 초안 기능이 일본 기업 이메일 문화의 관례를 관료주의적 형식까지 포함해 명백히 흡수하고 있는 것을 봤을 때였다. 현재 체감으로는 Anthropic의 Opus 4.6(그리고 코딩 세션 밖에서는 Fable 5)이 꽤 괜찮은 장문 일본어를 쓰고, Google 모델은 더 넓은 레지스터 범위에서 버틴다. 반면 OpenAI 모델들과 코딩 세션 안에서의 Opus/Fable은 "너무 geeky하게" 들린다고 적었다.

비영어권에서 콘텐츠를 만드는 사람에게 이 관찰이 뜻하는 바는 분명하다. 모델 선택이 곧 문체 선택이다. 한국어에도 같은 종류의 표지 단어 목록이 있을 텐데 아직 정리된 것을 보지 못했다.

AI;DR - "검토 안 했으면 나도 안 읽는다"

개인 블로그 · Rick Manelius

판별도 우회도 아닌 세 번째 태도가 이름을 얻었다. AI;DR, 즉 AI; Didn't Read다. TL;DR이 소셜미디어 시대에 대한 답이었다면 AI;DR은 AI 슬롭에 대한 답이라는 대칭 구도다. 원 표현은 이틀 전 X 계정 @seclilc가 올린 것으로, 16,600 좋아요에 리포스트 2,090건, 조회 34만 6,000건을 기록했다. 이 표현을 다룬 글은 Hacker News에서 538점을 받았다.

블로그 쪽 저자는 자기가 "가능한 한 pro-AI에 가까운 사람"이라고 먼저 못 박은 뒤 이것을 새 정책으로 채택한다고 선언한다. 정책 자체는 한 줄이다. "검토하고 편집할 만큼 신경 쓰지 않았다면, 나도 읽지 않겠다." 남 얘기가 아니라 자기도 존경하는 사람이 걸러지지 않은 AI 출력을 보내면 물리적으로 움찔한다고 - 어깨가 처지거나 눈이 살짝 씰룩거린다고 - 묘사한다.

예외 처리를 해둔 게 단순한 불평과 갈리는 지점이다. 고객 지원처럼 100% AI 생성 카피를 기대해도 되는 상황이 있다. "휴대폰을 초기화해보셨나요"류 대화에 장인정신을 요구하는 사람은 없다. 문제가 되는 건 동료가 Slack 토론에 모델 출력 벽을 그대로 붙이는 경우, 그리고 뉴스레터와 소셜 콘텐츠에 자기 이름을 걸고 AI 특유의 어투가 흩뿌려진 산문을 올리는 경우다.

Hacker News 쪽 논의에서 나온 것들도 함께 옮긴다. em dash를 AI의 표지로 보는 밈이 다시 돌았고, PR마다 수백 줄짜리 AI 생성 문서가 붙어 오히려 리뷰가 어려워졌다는 사례가 공유됐다. 그리고 **"post-readability"**라는 표현이 나왔는데, 읽히기 위해 쓰이지 않는 글이 늘어난 상태를 가리킨다.

반론도 있었다. gcupc는 "늦어도 2024년에는 이 표현을 문자 그대로 쓰던 사람들이 있었는데 이번 달 인용을 가져온다"며 신조어 주장 자체를 깎았다. 더 흥미로운 건 classichasclass가 지적한 파생 현상이다. 기사를 읽지 않고 AI에 밀어 넣은 다음 그 요약에 반응하는 사람들이 있어서 특정 친구들에게는 기사 보내기를 그만뒀다는 것이다. "어차피 AI만 읽을 걸 아니까." 그러면서 "어쩌면 그게 애초에 내가 그만하기를 바랐던 것일지도"라고 덧붙였다.

이스라엘 정부가 만든 가짜 싱크탱크와 "LLM 포이즈닝"

Hacker News · Responsible Statecraft, 원 보도 Politico / Drop Site

판별 논의의 반대편이다. AI가 쓴 글을 가려내는 문제가 아니라, 챗봇의 답변에 원하는 내용을 심는 쪽에서 벌어진 일이다.

Hanover Institute라는 싱크탱크가 8월 6일 이후 100건 넘는 글을 쏟아냈다. GPTZero가 그중 12건을 검사해 11건을 AI 생성으로 판정했다. 자금 흐름도 보도됐는데 Piro 쪽에 90만 달러, Parscale 쪽에 4,650만 달러 규모다.

이 작업을 수행하는 업체는 스스로를 **"AI Story Optimization"**이라고 부르고, 비판자들은 **"LLM poisoning"**이라고 부른다. 같은 행위에 붙은 두 이름의 거리가 이 산업의 상태를 보여준다. 메커니즘은 SEO와 비슷하되 목표가 다르다. 검색 순위가 아니라 모델이 특정 주제를 요약할 때 인용할 출처 풀을 채우는 것이다. 웹에 같은 주장을 하는 그럴듯한 문서가 충분히 많으면, 그것을 학습하거나 검색해 읽는 모델의 답변이 그쪽으로 기운다.

방어가 어려운 이유가 여기 있다. 앞서 본 워터마킹은 "이 텍스트가 모델에서 나왔는가"를 판정하지만, 심어진 문서가 AI 생성인지 아닌지는 사실 부차적이다. 사람이 손으로 쓴 100건이어도 효과는 같다. 출처의 진위와 이해관계를 추적하는 문제이지 생성 여부를 판정하는 문제가 아니라는 것이다.

NoToAI.org - 제품별로 AI를 끄는 경로 모음

Hacker News · NoToAI.org

판별도 심기도 아닌 네 번째 태도, 회피의 실무 정리다. 244점을 받았다. 도서관에서 기술 상담(Drop-In Time)을 운영하는 사람이 만든 목록인데, 그 배경이 내용의 성격을 설명한다. 이론이 아니라 "다음 사람에게 알려줄 수 있는 클릭 경로"를 모았다.

제품별로 항목이 나뉘어 있다. Apple의 경우 일반 AI 설정과 별개로 **"learn from this app"**이 앱마다 따로 있다는 점을 짚는다. Chrome은 chrome://flags의 GLIC과 Gemini 관련 플래그를 꺼야 하고, Firefox는 148 버전부터 일괄 토글이 생겼다. 검색 쪽 처방이 구체적인데, DuckDuckGo는 noai.duckduckgo.com 서브도메인을 쓰고, Google은 URL에 **udm=14**를 붙이거나 콘텐츠 차단 규칙 **google.com##.hdzaWe**로 AI 개요 블록을 숨긴다.

댓글에서 freeone3000이 남긴 정리가 이 목록의 성격을 짚는다. **"안 쓰는 게 이상적 결과"**라는 것이다. 끄는 방법을 모아둔 사이트가 필요하다는 사실 자체가, 이 기능들이 기본값으로 켜진 채 배포되고 있다는 뜻이기 때문이다. 최종 갱신은 8월 17일이다.

책 한 권에 테스트 5,500개 - 산문을 CI에 태운 기록

Hacker News · Ben Balter (전 GitHub)

"AI가 썼다"는 의심에 저자가 공정 전체를 공개해 답한 사례다. 100,000단어 576쪽짜리 책 한 권을 코드처럼 CI에 태운 기록인데, 규모가 구체적이다. 테스트 케이스 2,204개, 검사 5,500건, CI 잡 14개다. 린터 6종에 자체 검증기 30개를 붙였다.

가장 재미있는 대목은 자기 검증기에 자기가 걸린 것이다. validateHypotheticalHooks - 실제로 존재하지 않는 가상의 사례를 근거처럼 쓰는 패턴을 잡는 검사인데, 저자 본인의 문장이 여기 걸렸다. 그리고 semantic 중복 감사가 5개 챕터와 166건의 자기반복을 찾아냈다. 사람이 읽어서는 발견하기 어려운 종류의 결함이다.

사실 검증 쪽 성과도 있다. Claims 렌즈라고 이름 붙인 검사가 본문의 "절반"이라는 서술을 잡아냈는데, 원 자료를 확인하니 실제로는 3분의 1이었다. 통계 인용이 반복 편집을 거치며 뭉개지는 전형적 경로다.

조판 쪽 발견도 하나 있다. @media not screen 규칙이 의도와 달리 인쇄 출력에 새고 있었고, 고치니 576쪽이 567쪽으로 줄었다. 이모지 처리에 대해서는 통념과 정반대 처방을 내놨다. 알파 채널을 다루는 방식이 인쇄에서 문제를 일으켜, 흔히 권장되는 것과 반대로 설정해야 했다는 것이다.

의심에 대한 답은 이력 공개였다. Copilot으로 초안을 잡고, 사람이 전면 재작성하고, Claude로 라인 편집을 했다는 것이다. 표지는 사람 디자이너가 맡았다. 앞서 본 AI;DR의 기준 - "검토하고 편집할 만큼 신경 썼는가" - 에 대해 공정을 통째로 열어 답한 형태라, 두 글을 나란히 놓으면 이 논쟁의 실용적 출구가 보인다.

"제품 공지는 직접 쓴 것이었으면" - dotenv-ng 1.0

Hacker News · SecretSpec 팀 블로그

같은 반발이 릴리스 노트에서 터진 사례다. 다만 이 프로젝트 자체의 내용도 실무에 쓸모가 있다.

출발점은 파서 버그였다. 이슈 #73은 bcrypt 해시에 들어가는 달러 기호를 .env 파서가 변수 확장으로 해석해 시크릿 값을 바꿔놓는 문제였다. 저장된 것과 읽힌 것이 달라지는데 오류는 나지 않는다. 그래서 dotenv-ng는 기본값을 "달러는 문자 그대로"로 잡았다. 확장이 필요하면 명시적으로 켜는 쪽이다. 파서와 렌더러 모두 라인 커버리지 100%를 유지한다.

설계 철학 문장이 좋다. "떠나려면 먼저 정확히 읽어야 한다." 기존 포맷에서 마이그레이션하려는 도구가 그 포맷을 대충 읽으면 마이그레이션 과정에서 값이 손상된다는 뜻이다.

표기 문제도 하나 지적됐다. 공지에서 dotenvy를 "well-maintained fork"라고 소개했는데, dotenvy 0.15.7의 마지막 릴리스가 2023년 3월 22일이다. 3년 넘게 릴리스가 없는 프로젝트를 그렇게 부르는 것은 사실과 다르다.

그리고 댓글에서 eterm이 남긴 한 줄이 이 항목을 이 섹션에 두는 이유다. "제품 공지는 직접 쓴 것이었으면 좋겠다." 기술적 내용은 견실한데 공지문의 어투가 생성물처럼 읽혔다는 지적인데, 앞의 Doberman 저자가 "리드미 나머지는 에이전트가 삼키라고 쓴 것"이라고 실토한 것과 같은 날 나왔다.

학습 데이터는 어디서 오는가

희귀본에 AirTag를 넣었더니 아마존 AI 학습 시설로 갔다

개인 블로그 · Simon Willison, 원 보도 404 Media

한동안 서적상들 사이에 소문이 돌았다. 가격에 전혀 둔감하지 않은, 신원을 밝히지 않는 구매자들이 대량으로 책을 주문한다는 것이었다. AI 학습용으로 스캔하려는 기업일 거라는 의심이 널리 퍼져 있었지만 확인할 방법이 없었다. 소문과 확증 사이의 간극을 404 Media가 아주 단순한 방법으로 메웠다.

7월에 한 서적상이 마켓플레이스 Biblio에서 약 1,000권짜리 대량 주문을 받았다. 404 Media가 판매자에게 Apple AirTag를 제공했고, 판매자는 그 주문에 포함된 책 한 권 안에 넣어 보내는 데 동의했다.

책은 라스베이거스 북동부의 Amazon LAS8 시설 VGT3 구역에 도착했다. 그 입구에는 책을 들고 있는 공룡 로고가 걸려 있었다. 여기서 끝났다면 정황 증거였겠지만, 아마존 노동자들끼리 나눈 온라인 포럼 논의가 VGT3이 대량의 책을 파괴적으로(destructively) 스캔한다는 것을 확인해줬다. 파괴적 스캔은 제본을 잘라내고 낱장을 고속으로 넘겨 찍는 방식이라 원본이 남지 않는다.

이 이야기가 스크래핑 논쟁과 결이 다른 이유가 있다. 크롤링은 접근 권한과 robots.txt와 이용약관의 문제지만, 책을 정가에 사서 스캔하는 건 소유물에 대한 행위라 법적 방어선이 다르다. 그래서 조용히, 그러나 대규모로 진행될 수 있었고 서적상들만 이상함을 감지하고 있었다.

배경에 깔린 동기도 함께 짚을 값이 있다. 2022년 이전에 생산된 텍스트의 가치가 올라가고 있다. 그 이후 웹에는 모델 생성물이 대량으로 섞여 들어가서, 그것으로 다시 학습하면 품질이 퇴화하는 이른바 model collapse 우려가 있기 때문이다. 오래된 인쇄물은 그 오염이 없는 몇 안 되는 대규모 코퍼스다. 참고로 Anthropic과 xAI는 이런 방식을 쓰지 않는다고 공언했고, Amazon은 회피성 코멘트를 냈다. Willison은 이 건을 2025년 6월 자신이 다룬 Anthropic의 책 스캔 보도와 이어 붙이며 업계 관행에 가깝다는 그림을 그린다.

Lobsters 댓글은 취재 방법 자체로 옮겨 붙었다. alcides가 "배송 상품에 AirTag를 넣는 게 얼마나 합법인지 궁금하다, 이건 독립 매체가 아니라 당국이 해야 할 일"이라고 문제를 제기했다. JayTongue은 "어느 수준에서는 운송장 번호와 그렇게 다르지 않다"고 받고, JulianSildenLanglo는 "수취인을 스토킹하는 것과 눈에 띄게 다르지 않으니 합법일 것"이라고 말한다. 그러자 alcides가 되받는다. "많은 지역에서 수취인을 스토킹하는 건 불법이고 형사 범죄다. 전제에는 동의하지만 나는 반대 결론에 도달한다." 같은 유비에서 정반대 결론이 나오는 것이 이 논쟁의 요점이다.

"Anthropic's War on Open Source AI" - 1인 필자 논설

Hacker News · Ahmad

먼저 성격을 분명히 해둔다. 1인 필자가 쓴 논설이고 회사의 공식 입장이나 검증된 보도가 아니다. 주장의 상당 부분이 필자의 해석이므로 그렇게 읽어야 한다.

필자의 핵심 주장은 오픈웨이트 모델을 대하는 태도가 은밀한 방식에서 가시적 방식으로 바뀌었다는 것이다. Fable 계열 모델이 오픈웨이트 관련 요청에서 조용히 품질을 떨어뜨리던 단계에서, 이제는 명시적으로 거부하는 단계로 넘어갔다는 관찰이다. 검증되지 않은 관찰이지만 주장 자체는 기록해둔다.

더 확인 가능한 논점은 이용약관의 비대칭이다. 상용 모델의 출력으로 경쟁 모델을 학습시키는 것을 금지하면서, 정작 자기 학습 데이터의 출처에는 같은 기준이 적용되지 않는다는 것이다. 여기서 필자가 인용하는 수치들이 앞 항목과 이어진다. 700만 권 규모의 도서, 15억 달러 규모의 합의금, 50만 종에 대해 작품당 약 3,000달러라는 계산이다.

규제 쪽 논점도 있다. 10^25 FLOPs를 기준선으로 삼는 규제안이 논의되는데, 그 선 아래에서 훈련하는 오픈웨이트 진영에는 부담이 적고 그 위의 대형 모델에만 의무가 붙는 구조가 오히려 대형 사업자의 진입장벽으로 작동할 수 있다는 것이다. 필자가 인용한 기업 가치는 9,650억 달러이고, 5년 보존 의무 관련 논의도 함께 언급된다.

HN 댓글에서 나온 as;dr이라는 표현이 앞서 본 AI;DR과 직결된다. 저자의 편향이 뚜렷한 글에 대해 "내용을 읽기 전에 관점을 알겠다"는 뜻으로 쓰였는데, 판별 논쟁이 AI 생성 여부에서 관점 신뢰도로 확장되는 자리다.

Dario Amodei가 신뢰 위기를 인정했다

Reddit · r/ArtificialInteligence, 원 보도 Fortune

앞 항목이 비판이라면 이건 비판받는 쪽의 자기 진술이다. Fortune 인터뷰에서 Anthropic CEO가 AI 산업이 신뢰 위기를 겪고 있다고 인정했다.

원인 진단이 특이하다. 스케일링 법칙 자체를 원인으로 지목한다. 모델 성능이 계산량에 따라 예측 가능하게 오른다는 사실이 알려지면서, 능력 향상이 자본 투입 경쟁으로 환원됐고 그 경쟁이 신뢰 구축보다 빠르게 진행됐다는 논리다.

오픈웨이트에 대한 입장도 나왔는데, 여기서 흥미로운 논변이 등장한다. 가중치를 공개하면 권력이 분산될 것 같지만 실제로는 그 모델을 돌릴 컴퓨트를 가진 쪽으로 권력이 옮겨간다는 것이다. 앞 항목의 필자가 비판하는 입장과 정확히 반대편에 있는 주장이라, 두 글을 나란히 놓아야 논쟁의 양쪽이 보인다.

구체적 제안도 있었다. 안전하게 배포하기 위한 세 가지 조건을 (a)(b)(c)로 제시했고, 규제 형태로는 FINRA에 준하는 자율규제기구를 언급했다. 정부 직접 규제와 완전 자율 사이의 중간 형태인데, 금융 산업에서 그 모델이 실제로 어떻게 작동했는지에 대한 평가가 갈린다는 점은 함께 봐야 한다.

Anthropic 3조 달러 상장 보도

Reddit · r/Anthropic, 원 보도 Daily Mail

기업 가치 3조 달러 규모의 기록적 상장("record-shattering $3 trillion stock market launch")을 노리고 있으며 투자자들이 "extraordinary bet"에 줄을 서고 있다는 보도가 돌았다. r/Anthropic에서 401업보트에 댓글 229개로 서브레딧 규모 대비 큰 반응이었다.

출처가 Daily Mail이다. 이 매체의 금융 보도는 1차 소스로 삼기 어렵고, 공유 게시물에는 밸류에이션 산출 근거도 주관사도 목표 시점도 실려 있지 않다. 일정이나 규모를 기정사실로 서술하지 않는 게 맞다. 앞 항목에서 인용한 비공개 IPO 신청 후 9,650억 달러라는 값과도 자릿수가 다르므로 두 숫자를 섞어 쓰지 않는다.

이 항목을 남기는 이유는 숫자보다 배치 때문이다. 같은 날 같은 커뮤니티 생태계에서 세 가지가 한꺼번에 올라왔다. 사용량 프로모가 다음 날 만료된다는 예고, 3조 달러 상장 보도, 그리고 CEO가 신뢰 위기를 인정한 발언이다. 커뮤니티에서는 이 셋이 하나로 묶여 읽혔고, 한도 관련 스레드에서 반복된 정서가 **"밸류에이션은 올리면서 제공량은 깎는다"**는 것이었다. 오늘 뒤에서 다룰 사용량 한도 항목과 앞의 신뢰 위기 항목을 이 문장으로 이어 읽어야 실제 여론의 모양이 나온다. 데이터 조달 비용, 소송 합의금, 규제 대응 비용을 감당하려면 대규모 자본이 필요하다는 구조 자체는 사실이므로, 보도는 그 방향의 신호로만 읽는다.

개발자 인프라 - GitHub 장애와 포지 이탈

GitHub 연쇄 장애와 상태 페이지가 말하지 않는 것

Hacker News · 288점, Ask HN 동반

GitHub이 다시 멈췄다. 사용자들이 먼저 알아차렸고 상태 페이지는 한동안 정상을 표시했다. "지금 GitHub 맛이 갔나요"류의 Ask HN이 99점을 받으며 나란히 올라온 것이 그 간극을 보여준다.

규모 감각을 잡을 수치가 함께 정리됐다. 커밋 수가 과거 대비 14배로 늘어 주당 2억 7,500만 건, 연간 140억 건 추정이다. 그리고 전체 계정의 20%가 최근 6개월 안에 생성됐다. 에이전트가 만드는 커밋과 봇 계정이 이 증가의 상당 부분이라는 해석이 자연스러운데, 그렇다면 부하 특성 자체가 바뀌었다는 뜻이 된다.

가용성 비교도 돌았다. 어떤 사용자는 6년간 셀프호스팅한 GitLab의 누적 다운타임이 1.5일인데 같은 기간 GitHub은 2개월이었다고 보고했다. Codeberg는 14일 기준 **98.76%**로 집계됐다. 다만 이 수치들은 측정 기준과 대상 서비스 범위가 제각각이라 직접 비교로 쓰기는 어렵다.

대안 검토에서 걸린 실무 제약도 하나 나왔다. Tangled는 아직 비공개 저장소를 지원하지 않는다. 개인 실험이 아니라 업무 저장소를 옮기려는 순간 이런 항목 하나가 결정을 막는다.

대안은 많고 대체재는 없다 - 없는 건 소셜 레이어다

개인 블로그 · Lalit M

Codeberg가 생성형 AI로 대부분 작성된 프로젝트의 호스팅을 금지하기로 하면서 논쟁이 붙었는데, 이 글의 접근이 좋은 건 그 결정의 옳고 그름을 따지지 않는다는 점이다. 저자는 결정 자체는 놀랍지 않다고 본다. Codeberg는 늘 중립 인프라가 아니라 미션 주도 대안임을 자처해왔기 때문이다. 저자가 흥미롭게 본 건 반응 쪽의 실망감이다. 많은 사람이 마치 몇 안 되는 그럴듯한 대체재 하나가 자기 프로젝트를 배제해버린 것처럼 반응했다.

여기서 핵심 명제가 나온다. git 저장소를 호스팅할 곳은 많지만, 오픈소스 커뮤니티를 호스팅할 곳은 놀랄 만큼 적다. GitHub이 프로젝트에 주는 건 공유된 신원 풀, 공유된 습관, 그리고 발견 경로다. 어떤 대안도 비슷한 규모로 그걸 재현하지 못했다.

셀프호스팅이 답이 안 되는 이유도 자기 경험으로 설명한다. 저자는 Gitea를 몇 년째 돌리고 있지만 낯선 사람의 기여를 바라는 프로젝트에는 쓰지 않는다. GitHub에서는 대부분 이미 계정이 있고 issue와 PR이 어떻게 돌아가는지 안다. 자기 forge에서는 작은 버그 하나 신고하려 해도 계정을 또 만들고 규약을 배워야 한다. 어지간히 관심 있지 않으면 안 하고, 저자 본인도 안 할 거라고 인정한다.

발견 쪽 관찰도 뾰족하다. GitHub은 예전에 발견에 정말 좋았다. 팔로우하는 사람이 별을 눌렀다는 이유로 직접 검색할 리 없는 분야의 프로젝트를 정기적으로 만났는데, 피드가 개편된 뒤로는 거의 방문하지 않는다. 발견이 눈앞에 내밀어지는 경험의 일부가 아니게 되자 발견 자체가 워크플로에서 사라졌다는 것이다.

그런데 GitHub도 답이 아니다. 느리고, 로딩 실패가 잦고, 알림이 불안정하다. GitHub 스스로 최근 두 건의 대형 장애를 **"용납할 수 없다"**고 표현했다. stacked PR은 대기업에서 10년 넘게 흔한 관행이었는데 이제야 들어왔고 그마저 버그가 많다. 이 글에서 가장 날카로운 문장이 AI 관련 비판이다. 코어 forge는 방치된 느낌인데 Copilot은 곳곳에 등장하고, 에이전트가 코드를 더 많이 써봐야 그걸 리뷰하는 인터페이스가 이미 허덕이면 도움이 안 된다.

Ghostty가 그 좌절의 전형이다. 4월 말 Mitchell Hashimoto가 이탈을 발표하며 남긴 인용이 이렇다. "이 글을 쓰는 날, GitHub Actions 장애 때문에 약 2시간 동안 PR 리뷰를 전혀 하지 못했다. 매일 몇 시간씩 막아 세운다면 더 이상 진지한 작업을 할 곳이 아니다." 그리고 그도 "'git은 분산형이다'라고 하는 사람들에게: 문제는 Git이 아니라 그 주변에 의존하는 인프라, 즉 issues, PR, Actions다"라고 짚는다. 저자가 강조하는 건 결과가 아니라 과정이다. 그 정도로 저명한 프로젝트조차 명백한 기본 이전지가 없어 여기저기 물색해야 했다는 사실 자체가 그 공백이다.

대안별 진단도 정리돼 있다. GitLab은 유능하지만 GitHub보다 더 기업적이고 우연한 발견이 약하다. SourceHut은 투명하고 가치 주도적이지만 이메일 중심 워크플로가 대다수에게 낯설다. Forgejo의 연합은 유망하나 개발이 오래됐고 여전히 실험적이다. Radicle은 P2P 복제가 기술적으로 흥미롭지만 기여하려면 CLI나 데스크톱 앱을 설치해야 하는데, 저자의 반문이 뾰족하다. 버그를 마주친 사람이 그걸 신고하겠다고 forge의 소프트웨어를 설치해야 할 이유는 없다. 가장 관심 있는 건 Tangled인데 소셜 경험에 집중하고 홈페이지가 옛 GitHub처럼 프로젝트를 바로 보여준다는 점이 마음에 들지만 아직 알파다.

저자의 제안은 **bunny.net 같은 "일부러 지루한 회사"**다. 소프트웨어 개발의 운영체제가 되겠다는 야심 없이 오픈소스 협업을 쾌적하고 안정적으로 만드는 데만 집중하고, 개발자와 소규모 조직에 직접 과금하고, 매출이 허용하는 속도로 성장하는 형태다. 다만 스스로 난점을 인정한다. 공유 신원과 규약과 발견성은 규모에 도달해야 가치가 생기므로 cold-start 문제가 남는다. 마지막 문장이 이 글의 결론이다. "진짜 대체재는 소셜 레이어를 제품으로 취급해야 한다. 저장소가 충분히 쌓이면 저절로 생기는 무엇으로 여겨서는 안 된다."

댓글이 논지를 여러 방향으로 민다. technomancy가 17점으로 최다인데 전제를 뒤집는다. "GitHub에 대체재가 없는 건 '세상의 모든 소스 코드를 담는 웹사이트 하나'가 지금도 늘 근본적으로 나쁜 생각이었기 때문이다." m_eiman은 Tangled가 Bluesky 프로토콜 기반이라 VC 자금의 변덕에 좌우된다고 비판했고, ngp는 서드파티 구현이 이미 여럿이고 정확히는 ATProto이며 PLC 디렉터리도 유럽 비영리 기관으로 넘어가는 중이라고 반박했다. 그런데 lilac이 짧게 찌른다. "tangled 자체도 VC 돈이다." ChrisDenton은 빠진 실질을 지적했는데, GitHub의 킬러 기능은 오픈소스에 주는 넉넉한 무료 CI이고 Linux뿐 아니라 macOS와 Windows 호스트까지 준다는 것이다. 그 관대함이 경쟁자 여럿을 실제로 죽였고, 떠난다는 건 그 비용을 다시 지불하는 법을 배운다는 뜻이다.

같은 날 Show HN에 올라온 Ghostfork는 이 문제의 다른 축인 신뢰를 건드린다. 서버를 신뢰하지 않는 암호화 git 원격인데, 클라이언트가 오픈소스 git helper로 동작해 모든 통신을 중계하고 서버는 암호화된 코드와 인가된 사용자별 암호화된 repo 키 사본만 보유한다. 위협 모델이 명확하다. 서버 운영자가 신뢰할 수 없을 뿐 아니라 무능할 수도 있다고 가정한다는 것이다. 슬로건은 "Zero plaintext access is not a policy. It is the architecture." 사용법은 gf init-vault로 볼트를 만들고 gf://<username>/<repo>를 원격으로 등록한 뒤 gf add-user로 접근을 허용하는 식이다. 다만 초대제 비공개 볼트라 발견성은 정반대 방향이고, 앞 글이 말한 소셜 레이어 문제는 건드리지 않는다.

왜 아무도 GitHub을 떠나지 못하는가 - 무료 CI와 미러링의 한계

Hacker News · 텍스트 포스트 + Ask HN

앞 글이 소셜 레이어를 이유로 들었다면 이 논의는 경제적 이유를 세운다. GitHub의 월간 활성 사용자는 1억 8,000만 명이고, 오픈소스 프로젝트에 Mac과 Windows를 포함한 무료 CI를 제공한다.

경쟁이 어려운 구조적 이유가 지적됐다. egress 비용 때문이다. 코드 호스팅은 다운로드가 곧 비용인데, 대형 클라우드를 끼고 있지 않은 사업자가 무료로 그 트래픽을 감당하기 어렵다. 그래서 진입 유인이 애초에 약하다.

미러링으로 해결하자는 흔한 제안에 대한 반박도 명확하다. "PR과 리뷰는 미러링으로 해결되지 않는다." 저장소 사본을 여러 곳에 두는 건 쉽지만, 리뷰 대화와 이슈 스레드와 CI 결과는 한쪽에만 산다. Hashimoto가 "문제는 Git이 아니라 그 주변 인프라"라고 한 것과 같은 지점이다.

가용성에 대한 냉정한 코멘트도 있었다. "codeberg는 2 nines도 안 된다." 대안이 더 자주 멈춘다면 이탈의 명분이 약해진다는 것인데, 앞 항목의 98.76%라는 14일 집계와 겹쳐 보면 근거 없는 말은 아니다.

Cursor Origin - 저장소를 에디터 쪽으로 당기기

Hacker News · Cursor 공식 발표, Tomas Reimers 응답

Cursor가 자기 제품 안에 저장소 호스팅을 넣었다. 전 유료 사용자에게 얼리 베타로 열렸고 주소 체계는 cursor.com/codebase/<이름>이다.

설계에서 중요한 건 완전한 이탈이 아니라는 점이다. GitHub과 양방향 동기화하되 GitHub이 source of truth로 남는다. CI도 마찬가지로 기존 GitHub Actions를 Depot과 Buildkite가 실행한다. 즉 개발 경험을 에디터 쪽으로 당기면서 인프라 의존은 유지하는 구성이다. 현재 생성되는 저장소는 전부 비공개다.

발표에 붙은 경고 하나가 실무적이다. origin이라는 이름이 git 원격의 관용 이름과 겹쳐서, "origin main"이 무엇을 가리키는지 대화에서 모호해진다는 것이다. 제품명으로는 매끄럽지만 문서와 스크립트에서 혼동을 부른다.

타이밍이 화제가 됐다. 발표 게시물이 16,365 좋아요를 받는 사이 mattyp가 **"GitHub was down"**이라고 적었고, levelsio는 "The timing" 한 마디를 남겼다. 장애 몇 시간 뒤에 저장소 호스팅을 여는 그림이 우연이든 아니든 강한 인상을 남겼다는 뜻이다.

한 가지 정리해둘 것이 있다. 관련 스레드에서 Cursor의 소유구조를 특정인과 연결하는 전제가 돌았는데 확인되지 않은 내용이라 여기서는 다루지 않는다.

~/.pi 하나로 터진 설정 관행 논쟁

Hacker News · GitHub 이슈(earendil-works/pi) + Ask HN

코딩 에이전트 도구 하나가 설정을 ~/.pi에 두는 것을 놓고 긴 스레드가 붙었다. 쟁점은 XDG Base Directory 규격을 어떤 순서로 해석할 것인가였다. XDG_CONFIG_HOME을 우선할지, 기존 홈 디렉터리 관행을 유지할지, 둘을 어떤 폴백 순서로 볼지에 대해 의견이 갈렸고 결국 절충안으로 정리됐다.

사소해 보이는 논쟁이 길어진 이유가 있다. 이 도구들이 아직 관행을 못 정했기 때문이다. 에이전트 하네스마다 설정, 세션 기록, 캐시, 시크릿을 각자 다른 자리에 두고 있고, 여러 개를 동시에 쓰는 사람이 늘면서 홈 디렉터리가 지저분해진다. 앞서 본 yaop이 설정을 opencode.json이 아니라 별도 yaop.json에 둬야 했던 것도 같은 미정 상태의 산물이다.

fny가 보인 태도가 실용적이었다. 논쟁하느니 포크해서 패치하고 쓰겠다는 것인데, 오픈소스 도구에서 설정 위치 같은 취향 문제를 해결하는 가장 빠른 경로이긴 하다.

이 스레드에서 우연히 드러난 사실 하나가 오늘의 다른 항목과 물린다. 댓글에 붙은 GitHub 링크의 절반가량이 404를 반환했다. 장애 시간대에 걸린 것인데, 논의의 근거 자료가 통째로 접근 불가가 되는 상황을 그대로 보여줬다. 같은 스레드에서 파생된 "AI 없는 에디터를 찾는다"는 논의도 붙었고, Zed가 AI 기능을 일괄 토글로 끄게 해둔 점이 대안으로 언급됐다.

데이터베이스 - 제품의 진보와 연구의 자금난

DuckDB v2.0 "Cyanoptera" - 인프로세스 DB가 서버가 된다

DuckDB 공식 블로그

DuckDB가 v2.0 프리뷰를 공개했다. 코드네임은 Cyanoptera(붉은갈색 오리 cinnamon teal의 학명)이고 올 가을 출시 예정이다. 3월 v1.5 이후 1만 개가 넘는 커밋이 쌓였다. 팀은 메이저 버전을 올리는 이유가 의례가 아니라고 강조하는데, 실제로 새 SQL 파서, 새 기본 스토리지 포맷, 재작업된 C API, 그리고 소수의 신중히 고른 breaking change가 함께 들어간다.

서버가 된 DuckDB. DuckDB는 첫날부터 인프로세스 DB였는데, 클라이언트/서버 모드 요구가 집요하게 들어와 결국 수용했다. quack 확장이 네이티브 프로토콜을 구현하고, 아무 DuckDB 프로세스나 자기 데이터베이스를 네트워크로 서빙하며, 다른 DuckDB가 붙어 새 CONNECT 문으로 쿼리를 그쪽으로 라우팅한다. 서버 쪽은 CALL quack_serve(token = '...'), 클라이언트 쪽은 ATTACH 'quack:server.example.com' AS qk (TOKEN '...')CONNECT qk다. 그리고 Quack 전용이 아니다. 신규 remote pushdown optimizer(#22914)가 PostgreSQL과 MySQL에 SQL을 직접 밀어 넣어 테이블을 네트워크로 끌어오지 않는다.

"DuckDB는 트랜잭션 워크로드 못 하지 않냐"는 흔한 가정도 정면 반박한다. 첫날부터 완전한 MVCC와 트랜잭션 격리를 갖춘 다중 연결 DB였고, 단일 사용자 시나리오에서 아무도 그 기능을 쓸 일이 없었을 뿐이라는 것이다. 장기 실행에 대비해 메트릭과 관측성도 개선했다.

성능. 노트북에서 돌릴 수 있는 마이크로벤치마크가 하나 실렸다. 엣지 100만 개 그래프의 단일 소스 도달성을 평범한 재귀 CTE로 쓴 것인데, v1.5.4가 4.90초, v2.0 프리뷰가 0.12초로 약 40배다. 그 외에 부분 집계를 조인 아래로 밀고, 중복 집계를 재사용하고, 재귀 CTE 엔진을 다시 썼고, 집계가 메모리를 넘으면 디스크로 spill하고, Windows CLI의 멀티스레드 결과 materialization이 약 2.2배 빨라졌다. row-group pruning이 크게 확장돼 struct, list, decimal, UUID, IN 필터, 심지어 WHERE contains(message, 'ERROR') 같은 함수 술어까지 스캔 대신 건너뛴다.

ICU 제거. 타임존 인식 타임스탬프와 캘린더와 콜레이션이 늘 ICU 라이브러리로 돌아갔는데, 아주 일부만 쓰면서 모든 배포판이 통째로 이고 다녔다. v2.0에서 ICU가 완전히 사라지고 icu 확장이 직접 구현한다. 타임존 데이터는 IANA DB에서 직접 빌드해 약 45 kB로 압축했다. 크기만 준 게 아니라 더 빠르다. 2,500만 행 AT TIME ZONE이 0.24초에서 0.11초로 2.2배, 500만 행 COLLATE de 필터가 0.15초에서 0.06초로 2.6배다.

새 파서. PostgreSQL 파생 파서를 버리고 자체 PEG 기반 파서(#22194)를 싣는다. 확장이 문법 자체에 훅을 걸 수 있어 완전히 새로운 SQL 문법을 노출하는 확장이 가능해지고, 소스 위치가 정확한 에러 메시지와 첫 dialect 호환 모드(SET dialect_compatibility_mode = 'spark')가 따라온다. 팀은 "파서 교체를 체감하면 안 되도록 설계했으니 체감했다면 이슈를 열어달라"고 적었다.

그 외. VARIANT가 1급 시민이 돼 스토리지에서 바로 shredded 실행이 되고 Parquet 읽기/쓰기까지 파이프라인이 닫힌다. 트리거가 완전한 형태로 들어온다(BEFORE/AFTER, FOR EACH ROW/STATEMENT, REFERENCING OLD/NEW TABLE, RETURNING). 벡터 워크로드용 NEAREST 조인이 top-k 유사도 검색을 조인 절로 만든다. 엔진 전반에 비동기 I/O가 도입돼 오브젝트 스토어 접근이 쿼리 처리와 독립적으로 스케일한다. 스토리지 포맷 기본값이 v2.0.0으로 오르고 buffer-managed ART 인덱스로 인덱스가 더 이상 메모리에 고정되지 않아 큰 인덱스 테이블이 즉시 열린다.

생태계 쪽 변화도 크다. stable C API를 충분히 넓혀 확장을 한 번 쓰고 한 번 빌드하면 계속 동작하게 만들었고, 그 유지 가능성을 위해 C API를 선언적 버전 스펙(api_spec/의 YAML)에서 생성하며 CI가 헤더와 스펙을 대조한다. 배포도 열렸다. 자체 신뢰 저장소를 등록할 수 있고, 저장소 정의에 RSA 공개키를 핀으로 박고 SHA-256 지문을 출력해 별도 경로로 대조할 수 있게 했다. 그리고 가을부터 DuckDB Foundation에 stakeholder advisory board가 생겨 로드맵에 주요 이해관계자가 발언권을 갖는다.

매일 데이터베이스를 배포하는 법 - turbopuffer

Hacker News · turbopuffer 엔지니어링 블로그

100개가 넘는 클러스터에 하루 수십 번 배포하는 팀의 기록이다. 규모가 먼저다. 1조 개 이상의 문서, 초당 1,000만 건 이상의 쓰기, 초당 2만 5,000건 이상의 쿼리를 처리한다.

가장 흥미로운 제약은 BYOC 환경에서 자기들이 고객 자격증명을 갖고 있지 않다는 것이다. 고객 클라우드 계정 안에서 도는 클러스터에 직접 손을 뻗을 수 없다. 보통은 이게 운영을 어렵게 만드는 조건인데, 이 팀에서는 오히려 배포 자동화를 강제하는 조건이 됐다. 손으로 고칠 수 없으니 전부 선언적으로 굴려야 했다.

설계 핵심은 **단일 CRD TurbopufferOperation**이다. 배포, 업그레이드, 설정 변경을 전부 같은 오브젝트로 표현하고 컨트롤러가 처리한다. 그 판단을 뒷받침하는 문장이 이 글의 백미다. "Terraform 파일은 훌륭한 매니페스트지만 형편없는 잡 큐다." 원하는 상태를 기술하는 데는 좋지만, "지금 이 순서로 이 작업들을 진행하라"는 흐름 제어에는 맞지 않는다는 것이다.

안전장치는 fleet controller의 wave 게이트다. 클러스터를 물결 단위로 나눠 앞 물결이 건강해야 다음이 진행된다. 그리고 격리 설계가 하나 더 있는데, cluster agent는 fleet의 존재를 모른다. 개별 클러스터의 에이전트가 전체 함대 상태에 의존하지 않으므로, 중앙이 죽어도 개별 클러스터는 계속 돈다.

HN에서 나온 질문 중 답이 안 붙은 것도 하나 있다. 왜 메타데이터 저장소로 MySQL을 골랐는지에 대한 것인데, 이 글에서는 설명되지 않았다.

비AI DB 연구는 자금이 마르고 있다

Hacker News · Ask HN (Remy Wang)

짧은 Ask HN 두 개가 쌍을 이룬다. "Who wants to fund DB research?"와 "Who needs funding for DB research?"인데, 자금을 대려는 쪽과 찾는 쪽이 댓글로 만나는 매칭 스레드다.

작성자가 범위를 한정한 이유가 이 항목의 신호다. 비AI 영역에 집중하는 이유는 그쪽 자금이 AI 지출 때문에 크게 감소해왔기 때문이라는 것이다. 데이터베이스 연구는 지난 수십 년간 실무 시스템에 직접 흘러든 분야인데, 그 자금 배분이 AI 쪽으로 쏠리면서 개인이 커뮤니티 포럼에 매칭 스레드를 열어야 하는 상황이 됐다.

첫 응답은 UCLA 조교수 Remy Wang이었다. 연구 주제로 쿼리 언어(Prela와 Datalog)와 조인 알고리즘(WCOJ, instance-optimal joins, 조인 순서 결정)을 들었고 각각 프로젝트 사이트와 arXiv 논문(2601.00098)을 링크했다.

인력 이동도 함께 관찰됐다. 같은 사람들이 라벨을 바꿔 벡터 DB와 에이전트 시스템 쪽으로 옮겨가고 있다는 것이다. 연구 자체가 사라지는 게 아니라 AI 이름표가 붙은 하위 분야로 재배치되는 형태인데, 그 과정에서 AI와 직접 관련 없는 기초 문제가 후순위로 밀린다.

앞 항목과 나란히 놓으면 대비가 선명하다. DuckDB는 1만 커밋으로 재귀 CTE를 40배 당기고 자체 파서를 쓰고 ICU를 걷어냈는데, 그런 종류의 진보를 떠받치는 조인 알고리즘 연구는 자금 매칭을 커뮤니티 포럼에서 하고 있다. 스레드에서 나온 표현대로 "DuckDB는 수십 년 DB 연구의 직접적 결과물"이다.

OFFSET 없이 페이지 번호를 만드는 다섯 가지

Threads · @bear_dba

같은 날 나온 실무 DB 기법이다. 문제는 흔하다. LIMIT ... OFFSET ...으로 페이지네이션을 구현하면 뒤쪽 페이지로 갈수록 느려진다. 데이터베이스가 건너뛸 행을 실제로 읽어야 하기 때문에 100,000번째 행부터 20개를 가져오려면 100,020개를 훑는다.

처방 다섯 가지가 제시됐고, 그중 실무에서 가장 자주 쓰이는 것이 Deferred Join이다. 인덱스만으로 필요한 행의 기본키를 먼저 확정하고, 그 키 목록으로 본 테이블을 조인해 나머지 컬럼을 가져오는 방식이다. 넓은 테이블에서 OFFSET 구간을 통과할 때 읽는 데이터 양이 크게 줄어든다.

그리고 설계 판단 하나가 이 글의 핵심이다. "5000페이지로 점프하는 사람은 없다." 임의 페이지 번호로의 직접 이동을 지원하려니 OFFSET을 쓰게 되는 것인데, 실제 사용자 행동을 보면 그 기능이 거의 쓰이지 않는다. 커서 기반 페이지네이션으로 바꾸면 성능 문제가 통째로 사라지고, 잃는 것은 아무도 안 쓰는 기능이다. 성능 최적화가 아니라 요구사항 재검토로 푸는 문제라는 점에서 다른 네 처방과 성격이 다르다.

AI가 밀어내는 자원 - 메모리, GPU, 자본

메모리 가격 500% - 128GB가 10배가 됐다

Hacker News · Zak Killian, Tom's Hardware

개인 사용자가 가장 직접 체감하는 항목이다. 128GB 메모리 키트가 1년 사이 10배로 올라 3,399달러가 됐다. 표로 정리된 것 중 32GB 두 개짜리 구성은 191달러에서 1,118달러로 올랐다. 유럽에서는 345% 상승이 관측됐다.

원인은 수요 쪽에 있다. AI 데이터센터가 HBM과 서버용 DRAM을 대량으로 흡수하면서 소비자용 생산 라인이 축소됐고, 대형 사업자가 2027년 생산능력까지 선점하고 있다. Stargate 한 곳이 그 물량의 40%를 잡아뒀다는 이야기가 함께 돌았다. SK하이닉스 곽노정 대표와 업계 관계자 Simon Chen의 발언이 인용됐다.

비교 하나가 상황의 이상함을 잘 보여준다. 현재 DRAM의 킬로그램당 가격이 금값의 절반 수준이다. 반도체가 원자재보다 비싼 것 자체는 당연하지만, 소비자용 메모리가 이 구간에 들어온 것은 정상이 아니다.

댓글에서 나온 표현이 **"사다리 걷어차기"**였다. 개인이 로컬에서 큰 모델을 돌려보려면 메모리가 필요한데, AI 붐이 정확히 그 메모리를 가져가면서 개인의 진입 비용을 올린다는 것이다. 앞서 본 "17GB 모델이 노트북에서 돈다"는 좋은 소식이, 그 노트북의 메모리 가격이 10배가 됐다는 소식과 같은 날 나왔다.

GPU 할당기 - 구조가 정교함을 이긴다

Hugging Face 블로그 · Dharma AI

부족한 자원을 더 사지 않고 더 잘 나눠 쓰는 쪽의 연구다. GPU 클러스터 스케줄링을 다시 설계해 얻은 개선이 33퍼센트포인트, 특정 조건에서 최대 **105.1%**다.

가장 반직관적인 결과가 하나 있다. 대규모 테스트에서 GPU 사용률(utilization)은 기존과 동률인데 산출 가치가 15.9% 올랐다. 사용률은 스케줄러 성능 지표로 흔히 쓰이지만, 무엇을 돌리느냐를 반영하지 못한다. 같은 시간 동안 GPU가 꽉 차 있어도 중요한 잡이 뒤에 밀려 있으면 조직이 얻는 값은 낮다. 우선순위가 전부 동일한(uniform priority) 조건에서도 23.1% 개선이 나온 것이 이 논지를 뒷받침한다. 순서만 바꿔도 값이 달라진다는 뜻이다.

실시간성 처리에 대한 판단도 구체적이다. 지연에 민감한 잡에 5~10배의 페널티 가중치를 주고 스케줄링 결정을 1~15밀리초 안에 끝낸다. 그리고 접근법이 흥미로운데, 24시간 지평으로 최적화를 돌린 뒤 실제로는 1 timestep만 커밋한다. 모델 예측 제어와 같은 구조다. 먼 미래까지 계획하되 계획 전체를 실행하지 않고 한 걸음만 밟은 뒤 다시 계획한다. 여기서 end-of-world effect를 피하는 것이 중요한데, 최적화 지평의 끝에서 스케줄러가 "이후에는 아무 일도 없다"고 가정해 이상한 결정을 내리는 현상이다.

LoRA 관련 수치가 특히 크다. 어댑터 방식이 전체 파인튜닝 대비 자원 요구를 10,000배 줄이는 구간이 있어, 스케줄링 단위 자체가 달라진다.

저자가 뽑은 결론이 이 항목의 제목이다. "Structure beat sophistication." 정교한 예측 모델보다 문제를 어떻게 구조화하느냐가 더 큰 차이를 만들었다는 것이다.

30년물 5.311% - 바클레이즈가 AI 발행 물량을 지목했다

Hacker News · CNBC

미국 30년물 국채 금리가 **5.311%**로 2007년 6월 이후 최고를 기록했다. 10년물은 **4.724%**다. 원자재 쪽에서는 WTI가 2.6% 올라 배럴당 84.50달러, 브렌트가 90.87달러였다.

이 항목이 기술 다이제스트에 남는 이유는 금리 숫자 자체가 아니다. 바클레이즈가 장기 금리 상승 요인으로 AI 관련 채권 발행을 명시적으로 꼽았다. 데이터센터와 AI 인프라 투자가 회사채 발행으로 자금을 조달하면서 국채와 같은 투자자 풀을 놓고 경쟁한다는 논리다. 세 가지 요인 중 나머지 둘은 재정적자와 기간 프리미엄이었고, 인플레이션은 주 요인으로 지목되지 않았다.

시장이 무엇에 반응하지 않았는지도 눈여겨볼 대목이다. 소매판매가 -0.6%로 나오고 PPI가 보합인 날에 장기 금리가 올랐다. 통상 금리를 끌어내릴 지표가 나왔는데 반대로 움직였다는 건, 인플레이션 기대나 통화정책이 아니라 수급 요인이 지배하고 있다는 뜻이다. 7월 FOMC는 9대 3으로 동결했는데, 반대한 3인은 인하가 아니라 25bp 인상을 주장했다.

HN에서 커브 해석을 두고 논쟁이 붙었는데 quickthrowman의 정정이 정확하다. "거꾸로다. 시장이 수요와 공급으로 커브의 장기 구간을 정하고, 연준은 단기 구간을 통제한다. 연준이 단기 금리를 올리면 장기 인플레 기대가 내려가고 장기 국채 수익률도 함께 내려간다."

규모 감각을 잡으려면 같은 날의 다른 숫자를 옆에 놓으면 된다. Meta 한 곳만 올해 최대 1,450억 달러를 AI에 쓸 수 있다는 추정이 재판 관련 보도에서 나왔다.

Intel 150억 달러 증자 - 1971년 이후 첫 공모

LinkedIn · AI Brief

Intel이 성장 자금 조달을 위해 보통주 150억 달러어치를 매각한다. 주목할 점은 이것이 1971년 이후 Intel의 첫 공개 주식 매각이라는 것이다. 반세기 넘게 신주 공모 없이 운영해온 회사가 자본시장에 손을 벌렸다는 뜻이라, 투자 규모가 자체 현금흐름으로 감당되지 않는 구간에 들어왔다는 신호로 읽힌다.

조달 자금의 용처가 둘로 밝혀졌다. AI와 파운드리 등 프로젝트 투자, 그리고 부채 부담 완화다. 두 번째가 함께 있다는 점이 중요한데, 순수 성장 투자만이 아니라 재무구조 정리도 목적에 들어 있다는 뜻이다.

주가 반응은 두 숫자를 함께 봐야 한다. 발표 후 4.1% 하락했지만 올해 들어서는 160% 상승한 상태였다. 증자에 따른 희석 우려로 단기 조정이 나왔을 뿐 연간 흐름은 강했다는 것이라, 어느 한쪽만 인용하면 상황이 정반대로 읽힌다.

같은 날의 메모리 가격 급등, 30년물 금리 상승과 나란히 놓으면 그림이 하나로 모인다. AI 인프라 투자가 반도체 생산능력과 채권시장 자금을 동시에 끌어당기고 있고, 그 흐름 안에서 파운드리 사업자가 대규모 자기자본 조달에 나섰다.

사용량 한도 - 프로모 만료와 체감 감소

Reddit · r/ClaudeCode DosePlotter 외

앞의 세 항목이 거시 비용이라면 이건 개인 사용자에게 닿는 자리다. Claude Code의 50% 추가 한도 프로모션이 8월 19일에 만료된다는 공지가 나오면서 여러 커뮤니티에서 사용량 논의가 동시에 올라왔다.

체감 보고들이 흥미롭다. 프로모 종료 전인데도 이미 33% 정도 줄어든 느낌이라는 글들이 있었다. 실제 한도 변경인지 사용 패턴 변화인지 개별 보고만으로는 판정할 수 없다는 점은 짚어둔다. r/codex 쪽에서는 Pro 20x 요금제로 월 200달러를 내고 12일치를 썼다는 글이 339업보트를 받았다. Fable 쪽에서는 50% 캡을 풀어달라는 요구가 올라왔다.

메타적인 신호도 하나 있다. r/ClaudeCode에 "요즘 이 서브레딧에 올라오는 글 전부"라는 제목의 자조적 게시물이 98업보트에 댓글 44개를 모았다. 도구 커뮤니티의 대화 주제가 기능에서 한도로 옮겨간 상태를 반영한다.

플랫폼 규제, 감시, 결제

Meta 29개 주 연합 재판 - 청구액 최대 1.4조 달러

Hacker News · CNBC

29개 주 검찰총장이 연합해 제기한 소송의 재판이 오클랜드에서 시작됐다. 쟁점은 Meta가 미성년자에게 의도적으로 중독적인 제품을 설계하고 그 위해를 알면서 은폐했는지다.

청구 규모의 폭이 이 사건의 성격을 보여준다. 주 측이 주장하는 액수는 2,000억 달러 규모이고, Meta 측이 최악의 시나리오로 계산한 값은 1.4조 달러다. 열 배 가까이 벌어지는데, 위반 건수를 어떻게 세느냐에 따라 달라지기 때문이다. 선례로 참조되는 뉴멕시코 사건의 합의 규모가 약 10억 달러였던 것과 비교하면 자릿수가 다르다.

가장 눈여겨볼 요구는 금액이 아니다. COPPA 위반이 인정되면 위법하게 수집한 데이터로 학습된 모델까지 삭제하라는 요구가 포함돼 있다. 미국 연방거래위원회가 몇 차례 적용한 이른바 알고리즘 폐기(algorithmic disgorgement)를 이 규모에 적용하는 시도인데, 데이터만 지우는 것과 그 데이터가 녹아든 가중치를 지우는 것은 실행 난도가 완전히 다르다. 이 요구가 받아들여지면 학습 데이터 출처 관리가 법적 필수 요건이 된다.

재무 배경도 함께 봐야 한다. Meta 매출의 98%가 광고에서 나오고, 올해 AI 투자는 최대 1,450억 달러로 추정된다. 광고 타기팅의 근간이 되는 데이터 수집 관행이 재판 대상인데 그 수익으로 AI 투자를 대고 있는 구조라, 판결 방향에 따라 자금 흐름 전체가 영향을 받는다.

SignalTrace - 차 안 기기의 WiFi 지문으로 사람을 따라간다

Hacker News · TechRadar (David Nield)

앞 항목이 데이터 수집의 출구(책임)라면 이건 입구다. 방위산업체 Leonardo가 내놓은 SignalTrace는 번호판을 읽지 않는다. 대신 차 안에 있는 기기들이 내보내는 WiFi와 블루투스 신호의 조합을 지문으로 삼는다. 업체 표현으로 "electronic fingerprint"다.

번호판 인식과 다른 점이 결정적이다. 번호판은 차를 식별하지만 이 방식은 사람이 들고 다니는 기기 묶음을 식별한다. 차를 바꿔도, 렌터카를 타도, 걸어가도 같은 지문이 따라간다. 그리고 광학이 아니라 전파라 야간, 악천후, 창문 틴팅이 방해가 되지 않는다.

익명화가 왜 어려운지는 인용된 연구가 보여준다. Scientific Reports에 실린 결과인데, 시간과 장소가 찍힌 로그 네 개만 있으면 150만 명 중 95%를 고유하게 식별할 수 있다. 이름이나 식별자가 없어도 이동 패턴 자체가 지문이라는 뜻이라, "개인정보를 수집하지 않는다"는 설명이 실질적 보호가 되지 못한다.

현재 배치 규모는 미국의 번호판 인식 네트워크 수준에 이르지 못했다는 점은 함께 짚는다. 스레드에서 RFID 기반 추적에 대한 우려도 나왔지만 그건 제품 설명에 근거한 것이 아니라 논의 중 제기된 가능성이다.

Binance가 우크라이나 기부 기록을 러시아에 넘겼다

Hacker News · 원 보도 미상, 인용문 기반

보도 요지는 이렇다. Binance가 작년에 우크라이나 모금 캠페인에 대한 암호화폐 기부 상세 내역을 러시아 당국에 넘겼고, 그것이 러시아 IT 전문가에게 테러자금 조달 혐의를 적용하는 증거로 쓰였다. 법 집행 문서로 확인된 내용이라고 전해진다.

모순 지점이 이 항목의 핵심이다. 기업이 영업하는 국가의 법 집행기관이 정당한 요청을 하면 응하는 것은 정상적인 절차다. 그런데 Binance는 2023년에 러시아에서 완전히 철수했다고 밝힌 바 있다. 떠났다고 선언한 관할권에 기록을 넘긴 것이다.

법률 의견도 인용됐다. 암호화폐 규제 자문 로펌 Stellar Consulting 창업자 Mike Bystrov는 러시아를 떠난 이상 제공할 의무가 없었고, 오히려 EU 데이터보호법상 제공하지 않을 의무가 있었을 수 있다고 말한다.

HN 반응 중 dantyti의 냉소가 뼈아프다. "그냥 제대로 된 금융기관을 통해 은행 송금을 하는 게 나았겠다." 암호화폐가 검열 저항성과 프라이버시를 판매 문구로 쓰지만 실제 사용자 대다수는 중앙화 거래소를 통과하고, 그 거래소가 KYC 기록을 갖고 있다는 것이 이 사건의 요지다. 은행 송금이었다면 오히려 관할권 경계와 데이터보호법이 더 분명하게 작동했을 것이라는 지적이다.

한 가지 취재 한계를 밝힌다. 원 기사 본문이 확보되지 않았고 인용된 발췌만 확인됐다. 인용 범위를 넘어서는 사실 주장은 하지 않는다. HN 점수는 38점이다.

인도 UPI가 수수료를 받기 시작한다

Hacker News · BBC

세계 최대 규모의 무료 결제 인프라가 과금으로 전환한다. 인도의 UPI가 대형 가맹점의 2,000루피 초과 거래에 대해 **0.3~0.5%의 MDR(가맹점 수수료)**을 도입한다.

적용 범위 설계가 영리하다. **건수 기준으로는 전체의 4%에 불과하지만 금액 기준으로는 67%**를 차지하는 구간이다. 소액 결제와 소상공인은 그대로 무료로 두면서 수익 기반을 확보하는 구조인데, 무료 인프라의 지속 가능성 문제를 푸는 방식으로 참고할 값이 있다.

규모가 이 결정의 무게를 설명한다. UPI는 월 236억 건, 금액으로 3,135억 달러를 처리한다. 도입 이래 성장 배수가 12,000배로 집계됐다. 이 정도 규모에서 0.3%는 큰 금액이다.

반응은 갈렸다. LocalCircles 조사에서 75%가 반대로 나왔는데, 수수료가 결국 가격에 전가된다는 우려다. 비교 대상으로 브라질 Pix가 자주 인용됐다. 무료를 유지하되 중앙은행이 직접 운영하는 모델이라 비용 구조가 다르다는 것이다. 호주가 카드 수수료를 규제한 사례도 언급됐다.

배경에 대한 해석 하나는 단서를 달아 옮긴다. 미국-인도 무역협상 과정에서 카드사 접근성 문제가 다뤄졌고 그것이 이 결정과 무관하지 않다는 주장이 스레드에 있었는데, 확인된 사실이 아니라 그런 주장이 제기됐다는 수준으로만 기록한다.

Bluesky는 스크린샷에만 로고를 그린다

개인 블로그 · Tim Marinin

작은 발견에서 시작해 정확한 메커니즘까지 파고든 글이다. 저자는 Bluesky 포스트를 스크린샷으로 찍었다가 오른쪽 구석에 Bluesky 로고가 찍혀 있는 걸 알아챘다. 그런데 앱에서 같은 포스트를 다시 보면 로고가 없고 그 자리에 "Follow" 버튼이 있었다. 앱 전환 제스처 도중에 찍으면 또 로고가 안 나왔다.

답은 이름이 모든 걸 말하는 파일에 있었다. **GrowthHack.tsx**다. 2026년 1월 mozzius가 도입했고, 실제 구현은 같은 사람이 만든 의존 패키지 **expo-privacy-sensitive**에 있었다.

메커니즘이 영리하다. 패키지는 isSecureTextEntry가 true인 UITextField를 만들고 실제 콘텐츠(Follow 버튼)를 그 필드의 .layer에 렌더한다. 스크린샷을 찍으면 iOS가 비밀번호 필드 보호를 위해 그 레이어를 비우고, 그 아래 계속 있던 Bluesky 로고가 드러난다. 저자 표현으로는 "로고가 내내 거기 있으면서 날개를 퍼덕인다". 다른 플랫폼에서는 마스킹 없이 콘텐츠를 그대로 렌더한다. 앱 전환 시 안 통하는 이유에 대한 저자의 추정은, iOS가 제스처 시작 시점에 blanking을 발동시키지 않고 스스로 스냅샷을 찍기 때문이라는 것이다. 그 상태에서는 반응할 살아 있는 UITextField 인스턴스가 없고 정적 이미지만 있다.

판단이 갈리는 지점은 성격이다. 프라이버시를 위해 만들어진 OS 기능이 마케팅 워터마크 삽입에 그대로 재사용됐다. 이 동작을 추가한 PR 스레드에서는 대부분이 반대했고 스레드가 잠겼다. 다른 곳에서는 "키로거에 인접한 기법"이라는 표현까지 나왔다. 저자 본인은 "귀엽다"는 쪽이다.

기술 자체는 새롭지 않다. Telegram이 비밀 채팅에, Signal도 같은 방식을 구현했다. 그래서 Apple이 조만간 막을 것으로 보지 않는다는 게 저자의 판단이다.

AI 시대의 일과 배움

Andrew Ng의 AI Engineering Skills Map

discuss.pytorch.kr · Andrew Ng, DeepLearning.AI The Batch 366호 정리

채용 공고 1만 건 이상과 수십 건의 인터뷰를 바탕으로 AI 엔지니어에게 필요한 역량을 네 갈래로 정리한 자료다.

가장 강조된 것이 evals와 error analysis다. 모델을 고르거나 프롬프트를 다듬는 것보다, 무엇이 왜 실패했는지 분류하고 그 분류에 따라 다음 작업을 정하는 능력이 실무 성과를 가른다는 것이다. 오늘 별도로 다룬 Prime Intellect 대담의 "eval을 먼저 고쳐라"와 정확히 같은 자리다.

두 번째로 짚은 것이 컨텍스트 설계인데, 진단이 구체적이다. 대부분의 실패가 "모델이 못한다"가 아니라 "어떤 컨텍스트를 줘야 하는지 모른다"에서 온다. 이 역량을 Ng는 Context Advantage라고 부른다. 도메인 지식을 가진 사람이 모델에게 무엇을 보여줘야 하는지 안다는 뜻인데, yogthos의 "도메인 전문성 없이는 결과를 평가할 수도 없다"와 같은 주장의 다른 표현이다.

프레임으로 제시된 세 개의 루프는 개발 루프, 평가 루프, 배포 후 개선 루프를 가리킨다. 각 루프의 회전 속도가 서로 다르고, 느린 루프에 병목이 생기면 빠른 루프의 개선이 실제 제품에 도달하지 못한다는 논지다.

한계도 함께 짚어둔다. 공고 기반 분석이라 아직 이름이 붙지 않은 역량은 잡히지 않는다. 채용 담당자가 쓸 줄 아는 단어만 데이터에 들어오기 때문이다. 그리고 발행 주체가 AI 교육기관이라 커리큘럼과 역량 목록이 서로를 정당화하는 구조가 있다는 점도 감안해야 한다.

2026 신입 채용 - $12에서 $45로, 그리고 연 수십만

LinkedIn · Sajjaad Khader, Irena Palamani Xhurxhi, 이진호

첫 인턴십 시급이 12달러였고 주변에서 후려쳐졌다는 말을 들었지만 결과적으로 커리어에서 가장 좋은 선택이었다는 회고에서 시작한다. 그 12달러가 45달러가 됐고 이후 연 수십만 달러가 됐다는 것이다.

그런데 회고의 목적이 자기 자랑이 아니다. 2026년 시장은 그때와 다르다는 진단이 이어진다. 기업의 신입 채용이 크게 줄었고, AI가 인턴에게 주던 일을 하고 있으며, 학생들은 인턴십 하나에 수백 통을 지원한다. 신입이 배우면서 기여하던 자료 정리와 초안 작성과 기초 조사가 도구로 넘어가면서 그 단계 자체가 사라졌다.

저자의 명제가 그 상황에서의 처방이다. "공부는 배울 수 있다는 것을 증명하고, 일은 해낼 수 있다는 것을 증명한다." 급여는 일시적이고 기술과 경험과 증거는 남는다는 것인데, 첫 자리의 조건보다 그 자리에서 남길 증거를 기준으로 고르라는 이야기다.

같이 소개된 Career Mirror의 문제의식도 구체적이다. 총계 데이터는 일에 무슨 일이 벌어지는지는 설명하지만, 밤 11시에 왜 아무도 연락을 주지 않는지 궁금해하는 한 사람에게는 아무 도움이 안 된다는 것이다. 그래서 구직 사이트가 아니라 사용자의 이야기에서 시작한다. 실제로 무엇을 해왔는지, 아무도 이름 붙여주지 않은 강점이 무엇인지, 그리고 다음에 어디로 갈 수 있는지(현재 자리에서 성장, 공백 후 복귀, 방향 전환, 아직 모름)를 묻는다. 제작 경로도 요즘 형태다. 해커톤에서 시작해 첫 버전을 주말 동안 Lovable에 올렸고 이후 두 달간 퇴근 후 대부분의 밤에 작업했다.

마무리 문장이 이 글이 널리 돈 이유다. "시장이 망가진 것이지 당신이 망가진 게 아니다."

같은 흐름에 붙은 관리자 관점의 글도 함께 기록한다. 수습기간을 웬만해선 연장하지 않는 이유에 대한 회고인데, 연장은 배려가 아니라 결정 회피였다는 것이다. 실제 연장 케이스에서 결국 탈락시키자 당사자가 "그럼 왜 연장을 하신 거예요"라고 물었을 때 할 말이 없었다고 적었다. 3개월 안에 판단이 안 서면 6개월, 12개월이 지나도 마찬가지이며 부족한 건 시간이 아니라 기준이다.

"기회는 평등, 결과는 불평등" - 핵심인재 유지의 재정의

LinkedIn · 전준수

AI 교육 현장에서 20년차 팀장이 던진 질문에서 시작된 글이다. "저는 이제 무엇으로 인정받아야 하나요?" 예전에는 보고서를 가장 잘 쓰는 사람이 본인이었는데, 이제 신입사원이 AI로 30분 만에 초안을 만들어 오고 피드백을 주면 AI로 재검토해 더 나은 대안까지 가져온다는 것이다.

저자의 핵심 명제가 제목이다. "기회는 평등해졌지만, 결과는 더 불평등해진다." AI는 누구에게나 열려 있지만 같은 도구를 써도 같은 결과가 나오지 않고, 잘하는 사람이 훨씬 더 많은 일을 한다. 도구 접근을 균등하게 하는 것이 결과를 균등하게 만들지 않고 오히려 격차를 증폭한다는 뜻이다.

그래서 시니어 역할을 다시 정의한다. "많이 해본 사람"에서 "더 나은 판단을 내리고 결과의 품질을 책임지는 사람"으로다. 중요해지는 것은 경험의 양이 아니라 그 경험으로 무엇이 중요한지 판단하고 품질을 책임지는 능력이라는 것인데, 오늘 다룬 법률 인용 검증 논문이 보여준 상황과 정확히 맞물린다. 모델이 확인했다고 지어냈을 때 그것을 알아보는 사람이 필요하다.

핵심인재 유지의 정의도 뒤집는다. 그 사람에게 계속 중요한 일을 맡기는 것이 아니라, 그 사람이 없어도 조직이 움직이게 만들면서 그 사람은 더 중요한 판단에 집중하게 하는 것이다. 진단 질문 하나가 실용적이다. "우리 조직에서 그 사람이 없으면 안 되는 일은 무엇인가." 목록이 길수록 그 사람은 중요한 동시에 가장 위태롭다.

같은 저자의 다른 글에 붙은 사례가 구체적이다. 아동복 사업부에서 외부 영입한 경력 디자이너들이 6개월에서 1년이 지나도 성과가 나오지 않았는데, 원인이 글로벌 ERP였다. 패션 사업에 최적화되지 않아 입력할 내용이 너무 많았고, 12년 써본 기존 직원은 숙달됐지만 밖에서 디자인만 하던 사람에게는 치명적이었다. 별도 공간에 데스크톱을 놓고 **23일 집중 학습**을 시키자 불만이 사라졌다. 결론이 이 항목의 실무 교훈이다. "사람을 잘못 뽑은 것이 아니라 조직이 그 사람을 받을 준비가 되어 있지 않았다."

학습 경로 두 갈래 - 1,000쪽 완독과 재구현 목록

Reddit · r/deeplearning LostAd4986

이른바 튜토리얼 지옥에서 빠져나온 두 사람의 글이 같은 날 올라왔다. 방법은 다르지만 둘 다 느리다.

첫 번째는 완독과 재구현이다. YouTube 플레이리스트를 전전하다 "보고 있을 뿐 배우고 있지 않다"고 느낀 뒤 Aurelien Geron의 Hands-On Machine Learning 1,000쪽 이상을 완독했다. 방식이 중요하다. 챕터마다 코드를 직접 돌리고 일부러 부수고 왜 작동하는지 이해할 때까지 디버깅했다.

그 과정에서 만든 목록이 구체적이다. GoogLeNet 스타일 CNN을 커스텀 DepthPool 레이어와 함께 저수준에서 구현하고, 이어서 RNN, 어텐션 메커니즘, 트랜스포머, 오토인코더, GAN, 확산 모델, 강화학습을 차례로 재구현했다. 각각이 다른 방식으로 깨졌고 왜 그런지 알아내는 과정이 학습이었다는 것이다. 결론도 그 경험에서 나왔다. 가장 빠른 설명을 찾는 대신 실제 소스, 즉 문서와 연구 논문과 기술 문서로 손이 가게 됐다. YouTube에도 자리는 있지만 자기를 읽는 사람으로 만든 것은 이 책이었다는 정리다. 45업보트에 댓글 15개를 받았다.

두 번째는 교재 선정 기준이다. 연속체 역학 수업으로 미적분과 선형대수 배경이 있고 트랜스포머까지 기초를 익힌 공대생이 수학 심화용 쇼트리스트에 대한 검증을 요청한 글인데, 세운 기준이 재사용할 값이 있다. 문제 수보다 콘텐츠 품질을 본다. 설명과 유도가 뛰어나면 문제가 적어도 좋은데, 문제집은 다른 데서 구할 수 있지만 콘텐츠가 약하면 고칠 방법이 없기 때문이다. 또 수학이 모델 안에서 실제로 어떻게 쓰이는지 보이는 책을 원하고, 현대 모델 대부분이 근본적으로 확률적이므로 그 렌즈를 중시한다.

쇼트리스트가 저자명과 함께 정리돼 있어 실제로 찾을 수 있다. 통계와 확률은 Wasserman의 All of Statistics, 수학 중심 ML은 Mohri와 Rostamizadeh와 Talwalkar의 Foundations of Machine Learning, Deisenroth와 Faisal과 Ong의 Mathematics for Machine Learning, Hastie와 Tibshirani와 Friedman의 The Elements of Statistical Learning이다. 마지막 책은 쉬운 버전인 Introduction to Statistical Learning을 먼저 읽을 계획이라고 밝혔다. 딥러닝은 Goodfellow와 Bengio와 Courville의 Deep Learning이다.

오늘 별도로 다룬 학습 에이전트 Suki와 겹쳐 읽으면 대비가 된다. 이쪽은 사람이 스스로 규율을 세우는 방식이고 저쪽은 도구가 규율을 강제하는 방식인데, 두 글 모두 "설명을 소비하는 것과 다시 만들어보는 것은 다르다"는 같은 전제 위에 있다.

Suki - 읽었다는 이유로 안다고 믿어주지 않는 학습 에이전트

GitHub · grandimam/suki

에이전트를 코딩이 아니라 학습에 쓰는 오픈소스 도구다. 제작 동기가 실제 경험에서 나왔다. 책과 강의로 배웠는데 진짜 멘탈 모델이 만들어지지 않았고, 책이 건너뛴 부분을 채우려면 늘 LLM을 옆에 켜둬야 했다. 그래서 책을 직접적 진리 원천으로 삼기를 그만두고 LLM 자체로 커리큘럼을 설계하고 이해했는지를 캐묻게 하기로 했다.

설계 철학이 한 문장에 담겨 있다. "Suki turns an AI coding agent into a learning partner that doesn't trust you." 도덕적 의미가 아니라, 읽었다는 이유로, 강의를 봤다는 이유로, 튜토리얼에 고개를 끄덕였다는 이유로 안다고 믿어주기를 거부한다는 뜻이다. 이어지는 문장이 논지다. 학습은 콘텐츠 소비가 아니라 자기 머리에서 다시 말하도록 강제당하는 것이고, 그게 자리 잡을 때까지 반복하는 것이다.

루프는 세 단계다. /suki curriculum <topic>이 챕터와 순서와 그 주제에서 "숙달"이 무엇인지를 정의하고, /suki probe <topic> [ch]가 이해를 캐묻고, /suki book <topic>이 그동안 쌓인 것을 교재로 렌더한다.

probe가 핵심이다. "Kerberos 인증을 당신 말로 설명하시오" 같은 질문이 나오고, 사용자가 진술하면 그 진술의 균열을 캐고, 약한 지점이 나오면 그 자리에서 표적 드릴로 고친다. 모델은 반드시 사용자의 말이어야 하고 책의 말이면 안 된다. 숙달했으면 3, 10, 30, 90일 간격으로 다시 꺼낸다. 성적을 매기지 않고 모든 것이 아티팩트로 누적된다.

상태 관리가 깔끔하다. 모든 게 ~/.suki/ 아래 주제당 한 폴더로 살고, 현재 상태는 JSON, 이력은 append-only JSONL이라 아무것도 삭제되지 않아 학습의 전체 궤적이 복원 가능하다. 각 단계가 아티팩트를 쓰고 다음 단계가 그걸 읽어 작업이 복리로 쌓인다.

배포 방식도 눈여겨볼 만하다. pip install sukisuki install --all이 opencode, claude, codex 세 하네스 모두에 스킬 5종을 링크한다. 개별 선택도 되고, 에이전트를 재시작하면 /suki 하나가 단일 진입점이자 상태 대시보드가 된다. /suki book만 pandoc과 xelatex이 있는 LaTeX 배포판을 요구하고 KOMA scrbook에 Palatino로 조판한다. 커리큘럼, probe 이력, 만든 책 모두 로컬에 남고 외부 호출은 LLM과 웹 페치뿐이다.

커리큘럼 출력 예시(active-directory)가 구체적이다. tier 1 기초, tier 2 코어 메커닉(Kerberos, 티켓, 트러스트), tier 3 공격(Kerberoasting, 골든 티켓, 위임), tier 4 방어와 탐지, tier 5 전문가 영역 순이다.

보조금 신청서를 95% 자동으로 쓰는 회사와 그 회의론

YouTube · Google Cloud, The Agent Factory (게스트 Thierry Lindor, Happly AI)

기술 트랙과는 결이 다른 사례라 따로 둔다. Happly AI는 비희석 자금(non-dilutive funding), 즉 지분을 내주지 않고 받는 보조금과 지원금을 찾아 신청서를 쓰는 일을 자동화한다. 북미 시장 규모를 2조 달러로 잡는다.

실적으로 제시된 숫자가 구체적이다. 사용자 8만 4,000명, 확보된 자금 9,000만 달러, 그로 인해 만들어진 일자리 2,000개다. 사용자 구성이 특히 강조됐는데 84%가 여성, 유색인종, 원주민 창업자다. 현재 3,000건 규모, 총 30억 달러의 기회를 추적하고 있고, 신청서의 95%를 자동으로 작성한다.

그런데 이 대담에서 가장 흥미로운 대목은 성과 수치가 아니라 두 사람이 주고받은 회의론이다. 진행자가 "민주화"라는 서사에 의문을 제기했고, 게스트가 인정한 사실이 둘이다. 하나는 주 고객이 실은 개인 창업자가 아니라 grant writer, 즉 보조금 신청서를 대신 써주는 전문가들이라는 것이다. 도구가 진입장벽을 없애는 게 아니라 기존 전문가의 생산성을 올리고 있다는 뜻이다. 다른 하나는 게스트 본인의 문장인데, AI가 특권을 영구화할 수 있다는 인정이다. 도구를 쓸 줄 아는 쪽이 더 많이 받아가면 격차는 오히려 벌어진다.

낙관적 사례 발표에서 이 정도 자기 반박이 나오는 경우가 드물어서 기록할 값이 있다.

도구를 파는 사람들 - 제품과 과금 실험

SaaS 13종을 해지하고 포크로 갈아탔다

Threads · @startkim1214

에이전트가 구매 결정을 어떻게 바꾸는지 보여주는 가장 구체적인 사례다. 걷어낸 SaaS가 열 개가 넘고 목록이 실명으로 공개됐다. 미팅 녹음(Fireflies), CRM(Attio), 화면녹화(Loom), 일정예약(Calendly), 자동화(Zapier), 음성 받아쓰기(Wispr Flow), 노트(Reflect), 웹사이트 개발(Webflow), 노트 동기화(Obsidian Sync), 소셜미디어 스케줄링(Buffer), SaaS 구독 관리, 명함, 전자계약까지다. 그 자리를 채운 것은 처음부터 만든 소프트웨어가 아니라 오픈소스를 포크해 다듬은 것이다.

가장 선명한 사례가 CRM이다. 진단이 정확하다. 필요한 것은 범용 CRM이 아니라 에이전트가 손쉽게 붙고 모든 맥락을 한자리에 기록하고 관리하는 저장소였는데, 기성 CRM은 사람이 입력하고 사람이 보는 전제 위에 설계된 물건이다. 화면과 워크플로가 사람의 손을 상정하고 만들어져 있어서, 에이전트가 쓰기에는 오히려 방해가 된다. 오픈소스 CRM을 포크해 자체 서버에 올리고 기능 몇 가지를 붙이는 데 며칠 걸렸다.

핵심 명제가 build냐 buy냐가 아니라 **"fork and shape"**다. 논지는 비용 구조의 역전이다. 범용 도구의 핏과 우리 팀의 핏 사이 간극을 메우는 비용이 예전에는 구독료보다 훨씬 비쌌는데, AI가 코드를 쓰고 오픈소스 생태계가 두꺼워지면서 그 관계가 뒤집혔다는 것이다.

계산 방식에서 정직한 대목도 있다. 도입을 검토하다 접은 SaaS까지 포함했다는 점을 밝혔다. 회계와 인사 서비스를 곧 해지할 예정이라 대체재를 살펴봤지만 결론이 도입하지 않는 것이었다는 사례다. 실제로 결제하지 않은 도구의 구독료를 절감으로 세는 건 과대 계상으로 볼 여지가 있는데, 숨기지 않았으니 인용할 때 그 부분을 빼고 보면 된다.

남는 비용도 하나 짚어둔다. 포크한 도구의 보안 패치와 업그레이드를 누가 계속 따라갈 것인가는 몇 달 뒤에야 청구되는 종류라 지금 계산에 잡히지 않는다.

에이전트 9종으로 굴리는 AI CMO - 회사 주장과 그 한계

LinkedIn · Fatima Rizwan

Okara의 AI CMO v2가 마케팅 기능을 에이전트 9종으로 쪼개 운영한다. 5개월간 수백만 건의 게시물과 기사와 광고와 런치를 스캔해 만들었다고 밝혔다.

역할 분담이 구체적이다. Influencer는 캠페인 브리프 작성부터 크리에이터 계약, 아웃리치 발송, 추적, 정산까지 처리한다. SEO & GEO는 기술 이슈와 콘텐츠 갭을 찾고 ChatGPT와 Perplexity와 Google AI Overviews에 인용되도록 최적화한다. Content는 키워드를 발굴해 블로그를 쓰고 CMS에 자동 발행하며, LinkedInX는 브랜드 보이스로 글을 쓰고 올린다. Reddit은 구매 의도가 높은 스레드를 찾아 트래픽 유도 댓글을 쓴다. Copy는 웹사이트 카피를 전환 영향 순으로 재작성하고, UGC video는 대본과 비주얼과 보이스오버로 완성 영상을 만들며, Coding은 기술 SEO 수정을 자동화해 저장소에 PR을 낸다. 연동 대상은 Google Search Console, Analytics, WordPress, Webflow, Framer, Sanity, GitHub, LinkedIn, X다.

주장된 성과는 평균 45일 내 engagement와 트래픽 30% 상승, Influencer Agent를 통한 런치가 5개월간 1억 뷰 초과다. 회사가 자기 제품에 대해 밝힌 수치이고 독립 검증이 없다. 고객군으로 YC, a16z, Sequoia, Antler, Techstars, Khosla 출신 스타트업을 들었다. 가격 비교는 정규직 마케터 채용 비용 연 16만 달러 대 Okara 시작가 1,290달러인데, 전자가 무엇을 포함한 인건비인지 명시되지 않아 그대로 비교하기 어렵다.

기술 용어로 등장한 **GEO(generative engine optimization)**가 이 항목을 오늘의 다른 자리와 잇는다. 검색 엔진이 아니라 생성 모델이 답변할 때 인용하도록 콘텐츠를 최적화한다는 개념인데, 앞서 본 이스라엘 가짜 싱크탱크 건에서 업체가 "AI Story Optimization"이라 부르고 비판자들이 "LLM poisoning"이라 부른 것과 기법 자체는 같다. 하나는 상업 마케팅이고 다른 하나는 국가 개입이라는 점이 다를 뿐이라, 이 기법의 경계를 무엇으로 그을지가 질문으로 남는다. Reddit 에이전트가 구매 의도 높은 스레드에 댓글을 쓴다는 항목도 같은 질문 안에 있다.

"문서당 과금은 게으른 단위다" - OrbitQuote

Hacker News · Show HN

브라질 B2B 조달의 PDF 지옥을 직접 겪은 창업자가 만든 견적 비교 도구다. 문제 배경이 구체적이다. 브라질 B2B는 수작업과 PDF 견적 협상에 묶여 있고 이커머스를 하는 곳이 없다. 공장에서 사서 마진을 붙여 되파는 중개상뿐이라 마진을 확보하려면 공장 직거래가 답인데, 공급사 한 곳과 주문 한 건에 2주를 썼다.

공급사 쪽은 모든 게 100쪽 안팎의 PDF 카탈로그다. 한 쪽에 제품이 100개 넘게 들어 있을 수 있고, 그걸 SKU와 함께 수작업으로 엑셀에 옮겨야 가격과 최소 주문 수량을 물을 수 있다. 답으로 또 PDF가 오고 다시 옮겨 확인한다. 창업자 표현으로 .final.final_right.final_corrected.xlsx(10).xlsx 지옥이다.

제품은 카탈로그와 견적과 프로포마 인보이스를 라이브 에디터로 추출한다. OrbitQuote Compare는 같은 제품을 여러 공급사에 걸쳐 비교하는데, 핵심 난점이 공급사마다 제품 표기가 다르다는 것이고 이를 집계해 최적 조합을 고른다. 예시 화면 수치가 익명화된 실제 배관 자재 견적인데, 공급사 4곳 6품목에서 최고가 대비 8,250.90달러(21%) 절감, 최적 조합이 30,465.60달러로 단일 최저 공급사보다 1,431달러 저렴하다. 가장 싼 조합은 4곳 중 3곳에서만 산다.

과금 논리가 이 항목을 남기는 이유다. 문서 단위가 아니라 토큰 단위로 청구하고, 근거를 이렇게 적었다. "'문서'는 게으른 단위다. 1쪽짜리 WhatsApp 스크린샷일 수도, 50쪽 스캔 PDF일 수도 있다. 문서로 청구하면 전부를 평균가로 묶어, 적게 보내는 사용자가 평균을 낸다. 토큰이 처리의 실제 단위다." 대신 사용자가 비용을 예측하기 어려워지므로 대시보드에 사용량을 실시간으로 보여주고 잔여를 이월시킨다. 가격은 트라이얼 6.99달러 일회, Starter 월 129달러, Business 월 499달러이고 Enterprise만 토큰이 아니라 확보한 절감액 기준으로 완전히 다른 축을 쓴다.

자율성 경계도 명시한다. "스스로 사는가? 아니오. 만들고, 당신이 승인한다." 가격을 교차하고 가장 싼 바구니를 만든 뒤 멈춘다. 앞서 본 "에이전트에게 진짜 카드를 줄 것인가" 논쟁에 대한 시장의 현재 답이 이 문장에 있다.

주의할 점은 명확하다. 절감액과 ROI 계산(월 순 9,356달러, 연 약 11만 2,271달러)은 전부 판매자 자체 자료이고 제3자 검증이 없다. 레퍼런스가 없는 이유도 밝히는데, 고객이 견적 개선을 경쟁 우위로 보고 기밀유지 조항을 걸어 브랜드 사용 허가가 없다는 것이다. 로고와 후기 대신 트라이얼에서 직접 감사하라고 제안한다. HN 점수는 4점이고 크롤된 내용이 사실상 랜딩 페이지 전문이라 외부 검증은 없다.

하루 5,000만~1억 토큰을 쓰는 곳은 코딩 에이전트가 아니다

Hacker News · Ask HN

토큰 소비량 상위 사용처가 어디인지 묻는 스레드에서 나온 답들이다. 코딩 에이전트가 화제를 독점하지만, 하루 5,000만에서 1억 토큰을 쓰는 곳은 다른 데 있었다. 인보이스, 수주서, 보험 문서를 대량으로 처리하는 업무다.

운영 방식이 실용적이다. 모든 문서를 같은 모델에 넣지 않고 단순한 것과 복잡한 것을 라우팅한다. 표가 단순하고 레이아웃이 정형화된 문서는 싼 모델로 처리하고, 스캔 품질이 나쁘거나 구조가 불규칙한 것만 비싼 모델로 올린다. 이 물량에서는 라우팅 규칙 하나가 월 비용을 크게 바꾼다.

이 항목을 여기 두는 이유는 오늘 여러 자리에서 같은 구조가 반복되기 때문이다. 바로 앞의 OrbitQuote가 문서 단위 과금을 버리고 토큰 단위로 간 것, 음성 라우터 Speko가 "대부분의 턴은 프런티어 모델이 필요 없다"며 두 개의 고정 라우트를 둔 것, 그리고 Luna/Terra/Sol 배정 규칙이 검증 비용으로 모델을 고르라고 한 것이 전부 같은 계산이다. 토큰을 많이 쓰는 쪽일수록 모델을 고르는 문제가 성능 비교에서 라우팅 설계로 바뀐다. 그리고 화제성과 실제 소비량이 어긋난다는 점도 기록해둘 값이 있다. 코딩 에이전트가 담론을 독점하는 동안, 실제 대량 소비는 눈에 안 띄는 문서 처리 업무에서 일어나고 있다.

자체 모델을 준비 중이라는 답도 있었는데, 앞서 본 "파인튜닝을 정당화하는 사유 셋 중 둘이 경제성"과 정확히 같은 논리다. 물량이 충분히 크면 같은 품질을 더 작은 모델로 내는 것이 곧 이익이다. 보안 취약점 평가를 대량으로 돌리는 이른바 팩토리 구성도 언급됐다.

Meridian - 티켓에 안 남는 작업 8종

Reddit · r/ProductHunters Akarsh_Hegde

Product Hunt에서 Product of the Day 1위를 했다는 기록인데, 순위보다 팀이 런칭 과정에서 뒤집힌 가정 쪽이 남길 값이 있다. 몇 달 전 직장을 그만두고 개발자 생산성 제품을 만들기 시작한 팀인데, 런칭 당일 사람들이 제품에 관심을 갖는 것보다 제품의 전제를 얼마나 강하게 반박하는지가 예상 밖이었다고 적었다.

거기서 나온 결론이 이것이다. 개발자에게 필요한 것은 무엇을 해야 하는지 알려주는 도구가 하나 더 있는 게 아니라, 이미 하고 있는 일에 대한 더 나은 가시성이다. 근거로 든 목록이 구체적이다. 디버깅, 이슈 조사, 코드 리뷰, 문서 읽기, 동료 돕기, 회의, 실험, 그리고 계획에 없던 것 고치기. 이 여덟 가지 중 어느 것도 Jira나 Linear나 GitHub에 남지 않는다. 티켓 시스템이 기록하는 것은 실제 엔지니어링 작업의 일부일 뿐인데, 평가와 회고는 그 일부만 보고 이뤄진다.

Meridian이 하는 일은 개발 활동으로부터 워크로그를 자동 생성해 하루를 "실제로 무슨 일이 있었는지"의 요약으로 바꾸는 것이다. 오픈소스이고 개인 개발자에게는 현재 무료다. 팀이 커뮤니티에 던진 질문도 그대로 옮길 만하다. 지금은 하루가 끝날 때 자기가 무엇을 했는지 어떻게 재구성하고 있는가.

오늘 다룬 다른 항목들과 겹쳐 보면 이 문제가 왜 지금 커졌는지가 보인다. 작업이 여러 에이전트 세션에 분산될수록 티켓 시스템과 실제 작업의 괴리는 더 벌어지고, 코드 리뷰 발표에서 나온 "test plan을 사람이 쓰는 게 아니라 에이전트 세션에서 뽑아내야 한다"는 관찰도 같은 자리를 가리킨다.

pgDumpster - 3일 만에 만든 백업 도구와 source-available 선택

Reddit · r/Supabase Ciroco01

발단이 재미있다. 3일 전 같은 서브레딧의 Supabase 백업 논의에서 작성자가 흔한 답(supabase db dump를 돌리고 Storage는 따로 복사하고 cron이나 GitHub Actions로 실행)을 달았다가 반박을 받았다. 지적된 항목이 길다. 암호화, Storage 일관성, 복구 테스트, auth, roles, 체크섬, Supabase가 무엇을 노출하고 무엇을 안 하는지 파악, 그리고 정작 필요한 날이 오기 전에 백업이 실제로 쓸 수 있는지 확인하는 것. 작성자가 "며칠만 달라"고 하고 실제로 3일 뒤 내놓은 것이 pgDumpster다.

범위가 넓다. PostgreSQL, Storage 오브젝트와 메타데이터, Supabase가 노출하는 범위의 Auth와 API 상태, 복구 가능한 범위의 Edge Functions와 config, 그리고 읽고 복구할 수 있는 컨트롤 플레인 설정까지 다룬다. 백업 산출물에는 매니페스트와 무결성 정보가 함께 번들되고 age로 암호화할 수 있으며 R2 같은 S3 호환 스토리지에 선택적으로 저장된다.

복구가 의도적으로 편집증적이다. dry-run과 계획 단계를 거치고 대상을 검증하고 충돌을 처리하며, 안전하게 또는 자동으로 복구할 수 없는 것들을 명시적으로 보고한다. 백업을 만드는 것보다 복구가 되는지 확인하는 것이 어렵다는 점을 정면으로 다룬 설계다.

가장 정직한 대목은 만들며 배운 것으로 적은 문장이다. 완전히 원자적인 "Supabase 백업" 같은 것은 존재하지 않는다. PostgreSQL과 Storage와 컨트롤 플레인은 서로 다른 시스템이기 때문이다. pgDumpster는 그런 척하지 않고 일관성 경계를 기록하며, 무언가가 플랫폼 제약이나 수동 복구에 달려 있으면 전부 "성공"이라고 부르는 대신 그렇다고 말한다. 오늘 다룬 WhatsApp 자동화의 "거짓말하는 초록 로그"와 정확히 반대편의 태도다.

라이선스는 통상적 셀프호스팅 용도로 무료이되 OSI 오픈소스가 아닌 source-available을 골랐다. 이유를 명시했는데, 누군가 이걸 가져다 경쟁 호스팅 백업 서비스로 감싸는 것을 원하지 않아서다. 백업 도구는 신뢰가 곧 제품이라 코드 비공개가 채택을 막는데 완전 오픈소스는 관리형 경쟁자를 부른다. 그 사이에서 고른 절충이다. 작성자가 요청한 것도 명확하다. 프로덕션에서 Supabase를 쓰는 사람들이 도구를 부숴보고, 자기가 고려하지 못한 이상한 프로젝트 구성을 찾아내고, 백업과 복구 테스트를 실제로 돌려 워크플로가 어디서 나쁜지 알려달라는 것이다.

Speko - 응답 헤더에 자기 점수를 싣는 음성 API

Hacker News · Bek, Speko (YC S26)

자기소개는 "음성 AI의 OpenRouter"인데 실제로 파는 것은 라우팅보다 지속적 측정에 가깝다.

문제 설정이 설득력 있다. 프로덕션 음성 에이전트는 STT, LLM, TTS 세 모델의 앙상블이고 각 계층마다 신뢰할 만한 벤더가 열 곳 넘게 있으며 매달 새 모델이 나온다. 그런데 거의 모두가 한 번 평가하고 스택을 고른 뒤 다시 확인하지 않는다. 벤더를 바꾸려면 또 다른 통합 작업과 숫자를 둘러싼 논쟁이 필요하기 때문이다. 결과적으로 더 좋고 싼 선택지가 나와 있는데도 지난 분기 모델로 음성 에이전트를 돌리게 된다. 창업자 Bek은 이전에 4년간 아시아 10개국 이상 언어로 기업용 음성 에이전트를 만든 CTO였고, 새 모델이 나올 때마다 원어민 평가자를 고용해 기존 스택과 비교하고 개선되면 프로덕션을 갱신하는 의식을 반복했다. Speko는 그 의식을 API로 만든 것이다.

동작은 이렇다. 최적화 기준(정확도, 지연, 비용, 균형)과 언어, 지역을 담아 요청하면 라우터가 그 조합에서 실측한 모델로 후보를 좁히고 벤치마크해 승자를 고른 뒤, 응답 헤더에 프로바이더와 모델명, 점수를 담아 돌려준다. 게이트웨이는 서명된 세션 계획을 프리페치해서 새 세션이 메모리에서 곧장 프로바이더로 다이얼되므로, 통화자가 기다리는 동안 컨트롤 플레인 왕복이 없다. 폴백은 연결 설정 단계에서만 일어나 프로바이더가 연결을 거부하면 차순위로 붙는다.

가장 신뢰를 사는 부분은 측정 공개다. 같은 입력을 한 지역의 모든 모델에 날짜별로 돌리고 보드를 공개하는데, 자기 선택이 대안보다 나쁘게 나온 것도 함께 공개한다고 명시했다. TTS 자연스러움 자동 채점기는 블라인드 head-to-head 청취 투표로 학습시켰고, 투표를 본 적 없는 프로바이더에 대해서도 사람 평가자들끼리 일치하는 정도만큼 같은 승자를 고른다고 했다. 벤치마크 철학도 인용할 값이 있다. 런치 데모는 30초 클립 중 어느 쪽이 더 좋게 들리냐를 묻지만 프로덕션은 8분째에 어느 모델이 살아남느냐를 묻는다. 그래서 즉흥 발화, 금액과 날짜, 10분 테이크를 테스트하고 그러면 순위가 바뀐다. 모델을 직접 학습하거나 팔지 않는 것이 순위 공정성을 지키는 방법이라고 못 박았다.

오픈소스 쪽도 실용적이다. 게이트웨이를 MIT로 열었다(github.com/SpekoAI/gateway). Go 바이너리 하나로 에이전트 컨테이너의 사이드카로 돌고, Unix 소켓으로 로컬 프로토콜 하나를 말하며, 프로바이더 호스트를 핀 고정하고 사용자 키를 붙인다. BYOK 모드에서는 Speko와 아예 통신하지 않는다. 그리고 익명, 무내용 텔레메트리가 기본 활성이고 환경변수 하나로 끌 수 있다는 사실을 본문에 직접 밝혔다. 이런 고지를 스스로 하는 경우는 드물다. 과금은 게이트웨이와 BYOK가 영구 무료, 호스티드 라우터와 관리형 키와 통합 청구가 유료다. 6월 말 배치 시작 이후 외부 사용량이 주 평균 약 25%씩 늘었다(런치 주간에 몰려 있다). OpenAI API를 그대로 말하기 때문에 LiveKit 같은 기존 프레임워크는 호스트명과 model: 'auto'만 바꾸면 붙는다.

HN에서 가장 값진 건 아키텍처 논쟁이다. narrationbox가 정면으로 반박했다. 업계는 세 조각 아키텍처가 아니라 end-to-end 단일 모델(S2S)로 가고 있고, 지연 때문이기도 하지만 결과 자체가 훨씬 낫다는 것이다. TTS도 스타일별로 다른 모델을 두는 게 아니라 하나의 큰 모델에 스타일을 시스템 프롬프트로 주는 방식이 프로덕션 SOTA라고 했다. 포지셔닝 조언도 붙였다. "OpenRouter"보다 **"음성 모델의 LM Arena"**가 더 나은 피치인데, 가치의 대부분이 라우팅이 아니라 자동 평가에 있기 때문이다.

창업자 답변도 좋았다. S2S도 같은 방법론으로 측정하고 있고(benchmarks.speko.ai/s2s) 단일 모델이 이기면 똑같이 라우팅하므로 아키텍처를 가리지 않는다는 것이다. 다만 지금 프로덕션에서 보는 것은 대부분의 팀이 각 조각을 통제하고 싶어한다는 사실이다. 의료 어휘용으로 STT만 바꾸고 LLM과 음성은 유지하는 식이다. 현장 경험자들의 판정도 갈렸다. cootsnuck은 수백 곳의 엔터프라이즈 경험을 근거로 "실제로 돈을 내는 엔터프라이즈는 STS로 의미 있게 이동하지 않는다. 구성 가능성, 관측 가능성, 신뢰성 프로필이 엔터프라이즈 기준에 맞지 않고 비용도 문제"라고 했고, jvwww도 "대체로 다들 캐스케이딩 스택을 쓴다"고 거들었다.

턴테이킹 답변에 실무 팁이 섞여 있다. 호스티드 에이전트 플랫폼은 VAD와 턴테이킹까지 포함하지만, 자체 오케스트레이션이면 게이트웨이는 라우팅 레이어일 뿐이고 턴테이킹은 프레임워크에 남는다. Speko 자체 스택은 Pipecat의 Smart Turn을 in-process로 돌리고 실제 통화로 commit threshold를 튜닝한다. "빠른 작은 모델이 즉답하고 똑똑한 모델이 뒤에서 넘겨받는" 분할도 실험 중인데 지금은 두 개의 고정 라우트다. 논거가 명확하다. 전화 통화의 대부분의 턴은 프런티어 모델이 필요 없고, LLM 보드에서 가장 빠른 모델들은 전부 작은 모델이다. 앞서 본 OpenRouter 인수가 텍스트 쪽에서 라우팅 레이어에 값을 매긴 것과 같은 논리가 음성에서 반복되고 있다.

직장평 1,000개에서 나온 질문과 Cal.com의 1,000만 달러

LinkedIn · 추다은

변호사가 로펌 직장평을 남기는 서비스 "김변호사"를 만든 사람의 회고다. 변호사계의 글래스도어를 목표로 해커톤 수상 지원금을 받아 개발자 친구와 시작했다. 구조는 단순하다. 직장평 하나를 남기면 다른 변호사들의 직장평을 볼 수 있다. 로스쿨 동기들에게 하나씩 부탁해 모은 것이 1,000개를 훌쩍 넘었다.

성장 속도가 이상하다고 느껴 로펌으로 이직했다는 대목이 재미있다. 이유가 실용적이다. 송무 변호사는 전국으로 재판을 다녀 이동 시간이 길고, 기차에서 노트북을 열고 작업할 수 있기 때문이었다.

그런데 결과가 갈렸다. 유저는 계속 늘었지만 돈은 별로 늘지 않았다. 여기서 나온 교훈이 이 글의 핵심이다. "사람들이 많이 쓰는 서비스를 만드는 것과 사람들이 돈을 내는 사업을 만드는 것은 전혀 다른 문제다."

그래서 지금은 뭘 시작하든 먼저 한 줄을 적어본다고 한다. "이건 누가, 왜, 얼마를 낼까." 세 부분이 각각 다른 실패를 막는다. "누가"는 불만을 겪는 사람과 돈을 내는 사람이 다를 수 있다는 점을 잡고, "왜"는 그 불만이 지금 견딜 만한 수준인지를 가르고, "얼마"는 해결의 가치가 개발 비용을 넘는지를 본다. 그 한 줄이 안 써지면 아직 사업이 아니라 사이드프로젝트일 수 있다는 것이다.

같은 흐름에 오픈소스 수익화 사례가 붙었다. Cal.com이 1,000만 달러 달성을 알리며 남긴 자평이 이렇다. "AI 하이프 열차 없이도 복리로 성장하는 고마진 저이탈 SaaS 사업을 2026년에도 만들 수 있다는 증거." 좋아요 747개를 받았고 Stripe 공개 프로필로 그 흐름을 확인할 수 있게 링크를 붙였다. 스케줄링이라는 흔한 카테고리에서 오픈소스로 그 규모에 도달한 사례라, 앞의 "누가 얼마를 내는가" 질문에 대한 답이 실제로 존재한다는 증거이기도 하다.

이케아 100만 회원 - "멤버십은 명단이고 커뮤니티는 관계다"

LinkedIn · Inae Kim (전 이케아 코리아 마케팅)

2016년부터 2019년까지 이케아 코리아 마케팅팀에서 팝업스토어와 오프라인 이벤트를 담당하고 광명점, 고양점 오프닝에 참여한 사람의 회고다. 2016년 12월 이케아 패밀리 국내 가입자가 100만 명을 넘었고 100만 번째 회원 행사를 광명점에서 열었다. CRM 전담 팀이 따로 있을 정도로 가입 유도가 오프라인 이벤트의 기본 미션이었다.

그런데 가입 동기를 진단한 대목이 냉정하다. 프락타백, 그러니까 그 파란 장바구니 때문이었다. 매장이 몇 개 없던 시절이라 인기가 컸고 도시를 돌아다니는 광고판 역할까지 해 설계 자체는 훌륭했지만, 브랜드를 좋아해서 온 관계가 아니라 사은품을 받으러 온 관계였다. 해외에서 이미 가입한 사람들이 "한국에서 또 가입해야 하나요, 여기선 뭘 해주는데요"라고 물을 때마다 그 질문이 오래 남았다고 한다.

진짜 커뮤니티는 다른 데 있었다. 매장 안이었다. 각 지점에 로컬 마케팅 담당이 있었고 패밀리 멤버를 초대해 여름 미드솜마르 파티, 크리스마스 파티, 푸드 셰어링 같은 스웨덴 시즌 행사를 열었다. 문제는 그게 알려지지 않았다는 것이다. 당시 소셜미디어 가이드가 엄격해 지점이 따로 계정을 만들 수 없었고, 저자는 본사 익스터널 마케팅팀 소속이라 손을 대지 못했다. 브랜드 일관성을 위한 정책이 지역 커뮤니티의 가장 자연스러운 도구를 막은 셈이다.

지금이라면 어떻게 하겠느냐에 대한 답도 구체적이다. 큰 행사에 패밀리 멤버를 우선 초대하고 그들만 들어오는 채널을 따로 만들겠다는 것이다. 가장 큰 공백으로 꼽은 것이 100만 명 중 누가 진짜 우리 이야기를 듣고 싶어 하는지 구분할 방법이 없었다는 점이다.

핵심 문장이 이렇다. "멤버십은 명단이고 커뮤니티는 관계입니다. 명단은 100만 개를 모았는데 관계는 그만큼 만들지 못했어요." 현재는 방향이 조금 바뀌었다. 작년 8월 구매액이 아니라 활동 자체에 포인트를 주는 리워드 프로그램을 새로 선보였고, 평일 매장 방문 시 무료 커피나 워크숍 참여 혜택도 유지 중이다.

인도네시아 하이퍼로컬 VC - 부채금융과 이익배분

LinkedIn · EO planet

배경 진단이 먼저다. 현재 인도네시아에서는 외국 자금이 빠지고 스타트업 밸류에이션이 급락하며 자카르타 테크씬 자체가 위축되는 중이다. 그 와중에 수표를 멈추지 않는 투자자들이 있는데, AI 스타트업이나 다음 유니콘을 보지 않는다. 투자 대상이 팜유 상인, 동네 제조업체, 수공예품 수출업자다.

이름이 하이퍼로컬 VC다. 한 개 지방에서만 활동하고, 지분 투자 대신 부채금융과 이익배분으로 자금을 운용한다. 피치덱도 없고 밸류에이션 협상도 없다. 엑시트가 없어도 자본이 회수되는 구조라, 상위 소수의 대박에 의존하는 스타트업 투자와 달리 대부분의 투자처가 평범하게 성공해도 성립한다. 연 실효수익률로 **25~30%**가 언급됐는데, 전언으로 소개된 수치이고 검증된 실적 공시가 아니다. 언급된 곳은 Wilt Venture Builder이고 대표는 Daero Won이다.

게시자의 배경 설명이 이 항목을 단순 소개 이상으로 만든다. 2006년 동남아 벤처투자를 위해 싱가포르에 온 뒤 20년을 보낸 사람인데, 최근 1~2년 돌아본 결론이 실리콘밸리는커녕 한국식 벤처 생태계도 생기기 어렵다는 것이었다. 이유가 수요와 공급 양쪽에 있다. 잠재 수요는 있지만 초기 제품이나 서비스를 기꺼이 구매할 층이 매우 얇고, 공급 측에서는 자금과 고급 인력과 국가 시스템 같은 자원이 절대적으로 부족하다.

그 결과가 두 가지다. capital market 부재로 엑시트가 안 되고, 획기적 아이디어와 네트워크를 가진 로컬 창업자도 부족하다. 그래서 게시자의 표현대로 "VC라고 쓰고 특수 니치 금융기관이라고 읽어야 하는" 애매한 투자자들이 등장한다. 자본 구조가 시장 조건에 맞춰 진화한 사례로 볼 수도 있고, 벤처 모델이 이식되지 않은 자리에 다른 것이 들어선 것으로 볼 수도 있다.

문서를 기계가 읽게 만들기

Spotlight가 스캔 PDF를 못 찾는 이유와 세 가지 해법

Hacker News · Tidy 개발자 블로그 (Show HN)

Show HN이지만 제품 홍보보다 설명 글로 남길 값이 있다. 문제 진단이 정확하다. PDF라 불리는 두 가지가 완전히 다른 물건이다. Word나 브라우저 인쇄에서 나온 PDF는 문자가 문자로 저장돼 Spotlight가 읽고 색인한다. 스캐너나 폰 카메라에서 나온 PDF는 PDF 컨테이너에 싸인 페이지 사진이다. 문자가 없고 문자 모양으로 배열된 픽셀만 있다. 저자의 정리가 명료하다. "Spotlight가 단어를 못 읽는 게 아니다. 단어가 없다."

30초 확인법이 있다. Preview에서 문서를 열고 텍스트 줄 위로 커서를 끌어본다. 단어가 하이라이트되면 텍스트 레이어가 있는 것이고, 사각형만 그려지면 없는 것이다. 폴더 전체를 훑는 셸 명령도 제시됐다.

for f in *.pdf; do
  strings "$f" | grep -qm1 "/Type/Font" || echo "no text layer: $f"
done

저자가 스스로 단서를 붙인 것이 신뢰를 준다. 일부 PDF는 내부 구조를 압축해 텍스트가 있어도 없다고 보고될 수 있으므로, 이 명령은 대략적 카운트용이지 개별 파일 판정용이 아니라는 것이다. Preview 테스트 쪽이 거짓말하지 않는다.

해법이 셋이다. 첫째, 파일에 텍스트 레이어를 추가한다. OCR이 인식한 텍스트를 각 단어 그림 위에 보이지 않는 레이어로 써넣으면 외관은 그대로이고 검색과 복사가 동작한다. 대부분의 스캐너 소프트웨어가 옵션만 켜면 해준다. 한계는 처리한 파일만 도움이 된다는 것이고, 이미 쌓인 것을 전부 돌리는 일은 "결코 일어나지 않는다". 둘째, macOS 단축어 앱의 Extract Text from Image가 로컬에서 돈다. 계정도 업로드도 없고 사진에서 글자를 선택할 때 쓰이는 Live Text와 같은 엔진이다. 무료이고 가끔 있는 문서에는 실용적이지만 600개짜리 폴더에는 고되다. 셋째, 파일을 수정하지 않고 별도 색인을 유지한다. 앱이 각 문서를 한 번 읽어 인식된 텍스트를 자기 색인에 두고 그것을 검색한다.

세 번째 해법 설명에 들어 있는 판단 기준이 문서 도구 전반에 적용된다. 도구가 데이터를 소유하는가, 참조만 하는가. 저자의 표현이 좋다. "도구가 문서를 붙들고 있으면 떠나는 건 마이그레이션이다. 읽기만 한다면 떠나는 건 앱을 휴지통에 끄는 것이고 폴더는 정확히 있던 그대로다." 노트 앱, 사진 관리, 문서 관리 도구를 고를 때 그대로 쓸 수 있는 기준이다.

저자의 권고는 상황별로 갈린다. 문제가 "앞으로의 모든 것"이면 스캔하는 무엇에든 OCR을 켜라. 파일 자체를 영구히 개선하니 가장 깔끔하다. 문제가 "이미 쌓인 더미"면 색인이 빠르다. 수천 개를 재처리하고 다시 저장할 필요가 없기 때문이다. 제품인 Tidy는 온디바이스 인식으로 이미지와 스캔 PDF 내부를 읽고 내용에서 파일 이름을 지으며 파일을 원래 폴더에 그대로 둔다. 9달러 일회 결제, 구독 없음, macOS 14 이상.

Roboflow Playground - 비전 모델 30여 종을 같은 이미지로

Hacker News · Roboflow 블로그 (James Gallagher)

같은 이미지와 프롬프트를 30개 이상의 비전 모델에 태워 결과를 나란히 보는 도구다. 한 번에 최대 5개 모델을 고를 수 있고 태스크는 object detection, captioning, classification, OCR, open prompt(이미지에 대한 자유 질문) 다섯이다. 커버리지에는 Anthropic, OpenAI, Meta, Google, Mistral 같은 API 제공자와 Florence-2 같은 오픈소스가 함께 들어가고, 오픈웨이트 쪽으로는 Qwen3.8 27B와 Muse Glimmer 30B, Llama 최신 시리즈가 언급됐다. 겨냥한 비용도 명확하다. 최신 모델을 조사하고 클라우드 API 호출 코드를 쓰고 오픈웨이트용 인프라를 프로비저닝하다 보면 어느새 새 모델이 나와 있다는 것이다. 모델 가용성이 태스크에 종속된다는 점도 짚어뒀다. Gemini 3.6 Flash와 SAM 3은 object detection에 쓸 수 있지만 SAM 3은 VQA를 지원하지 않아 그쪽에는 못 쓴다.

블로그의 실측 예시가 하나의 관찰로 수렴한다. "book"과 "coffee" 프롬프트로 Florence-2, YOLO World, Claude 3.5 Sonnet을 돌렸더니 앞의 둘은 두 객체를 모두 찾고 정확한 바운딩 박스를 그렸는데 Claude 3.5 Sonnet은 대략적 위치는 찾았지만 정밀한 박스를 그리지 못했다. 반면 open prompt에서는 Claude 4 Sonnet과 GPT-4.1 모두 테이블 위 커피컵을 정확히 식별하고 배경까지 상세히 묘사했다. 범용 VLM은 물체가 무엇이고 어디쯤 있는지는 알아도 픽셀 좌표를 정확히 찍는 것은 다른 능력이라는 뜻이다. 파이프라인에서 detection이 필요하면 프런티어 VLM보다 Florence-2나 YOLO World 계열이 여전히 유효하다. 앞서 본 GPT-5.6 Sol의 mAP가 46.2로 오른 것이 의미 있는 이유도 여기 있고, 동시에 좌표 포맷만 바꿔 15 mAP가 움직였다는 사실도 이 관찰과 맞물린다. 위치 정보가 모델 안에 있긴 한데 좌표로 꺼내는 경로가 불안정한 것이다.

HN 쪽에서는 OCR Arena(ocrarena.ai)의 업데이트판처럼 보인다는 평가와 함께 Mistral OCR 4, Baidu Unlimited-OCR, OlmOCR2를 추가해달라는 요청이 나왔고 Roboflow가 답변을 남겼다. 세그멘테이션용 무료 오픈 모델 추천을 묻는 질문에는 답이 없었다.

한 가지 단서를 붙인다. 인용된 블로그의 날짜가 2025년 9월 30일이라 비교에 쓰인 모델 목록과 결과가 낡았을 수 있다. 위의 Claude 3.5 Sonnet 사례도 현재 성능 판정이 아니라 "태스크별로 강약이 갈린다"는 논점의 예시로만 읽는 편이 안전하다. 도구 자체는 지금 돌려볼 수 있으므로, 결론보다 직접 비교해보라는 사용법을 가져가는 쪽이 맞다.

Visimer - AI가 만든 Mermaid를 캔버스에서 직접 고친다

Hacker News · Nick (OpenKnowledge), MIT

모델이 만들어준 Mermaid 다이어그램을 고치려면 보통 다시 프롬프트를 던진다. 그런데 전체 재생성은 주석과 포맷을 먹는다. 손으로 붙여둔 설명이나 정렬이 매번 사라지고, 고친 부분 외의 다른 노드까지 달라진다.

Visimer의 접근이 영리하다. 렌더된 SVG를 CST(concrete syntax tree)로 역매핑한다. 화면에서 노드를 옮기거나 라벨을 고치면 그 편집이 원본 텍스트의 해당 위치에만 적용되고 나머지는 글자 그대로 보존된다. 코드 포매터가 AST가 아니라 CST를 쓰는 이유와 같은 논리인데, 주석과 공백처럼 의미에는 없지만 사람에게 중요한 정보가 CST에만 남기 때문이다.

커버리지가 구체적이다. Mermaid 23개 다이어그램 타입 중 22개가 편집 가능하다. flowchart, sequence, state, class, ER, pie, gantt는 항목 편집과 구조 편집을 모두 지원하고, journey, timeline, quadrant, kanban, mindmap, treemap, packet, sankey, radar, gitgraph, xychart, requirement, C4, architecture, block은 항목 편집만 된다. zenuml은 외부 플러그인이라 보기만 가능하다. 모든 타입이 무손실 라운드트립되고 코드와 캔버스의 선택 상태가 동기화된다.

패키지 설계에서 눈에 띄는 것은 에디터 통합을 의존성이 아니라 계약으로 만든 것이다. 헤드리스 엔진인 @visimer/core는 DOM 의존성이 0이고 무손실 CST, 시맨틱 그래프, 편집 연산을 최소 텍스트 편집으로 바꾸는 변환, 통합 히스토리를 담당한다. 여기에 bindTextPane이라는 5개 메서드 어댑터를 노출해 어떤 에디터든 같은 양방향 동기화를 갖게 한다. CodeMirror와 Monaco 패키지는 그 구현일 뿐이라 설치하지 않으면 딸려오지 않고, 다른 에디터를 붙이려면 약 40줄짜리 어댑터를 구현하면 된다.

사용 감각도 문서에 잘 정리돼 있다. 라벨을 더블클릭하면 다이어그램 위에서 바로 타이핑되며 노드가 커지고, 고스트 엣지 미리보기와 함께 드래그로 연결한다. 시퀀스 메시지를 드래그로 재정렬하면 소스의 문장 순서도 함께 바뀐다. 도형과 타입과 화살표 선택기, 카디널리티, 색상 스와치, fragment와 note 팝오버가 있고, 캔버스와 코드를 아우르는 단일 undo 스택을 쓴다. 타이핑 도중 문법이 깨져도 캔버스가 비지 않는 error tolerant 동작이고, 모르는 문법은 글자 그대로 보존해 diff에 바꾼 것만 남는다. 설치는 npm i @visimer/core @visimer/dom mermaid이고 MIT 라이선스다.

제품 포지션도 정확하다. 만든 사람의 표현이 이렇다. AI는 콘텐츠 생성에 훌륭하지만, 다른 사람과 공유할 아티팩트를 만들려고 세부를 다듬을 때는 point-edit이 훨씬 낫다. 오늘 뒤에서 다룰 책 CI 파이프라인이 "AI는 감사와 검토에 쓰고 문장은 사람이 쓴다"로 분업을 그은 것과 같은 선 긋기다.

앞서 본 yogthos의 워크플로에서 "계획을 Mermaid로 그리게 하고 눈으로 검사한다"는 조언이 나왔는데, 그 다이어그램을 고치는 단계에서 정확히 이 문제를 만난다. 두 항목이 한 워크플로의 앞뒤다.

WebMCP - 페이지가 툴을 직접 노출한다

YouTube · Google Cloud, 발표 Hugo

문서를 읽게 만드는 대신 페이지가 스스로 도구를 내주는 반대 접근이다. 지금 브라우저 에이전트는 스크린샷을 찍어 무엇이 보이는지 해석하고 좌표를 눌러 조작한다. 비용이 크고 실패도 잦다.

WebMCP는 페이지가 자기가 할 수 있는 동작을 MCP 툴로 직접 노출하게 한다. 장바구니에 담기, 검색하기, 필터 적용하기 같은 것이 함수 시그니처로 제공되면 에이전트는 화면을 해석할 필요 없이 호출만 한다. 페이지마다 다른 툴 집합을 주므로 컨텍스트에 들어가는 것도 그 페이지에 필요한 만큼이다. 스크린샷 방식 대비 토큰 절감이 크다는 것이 발표의 주요 논거였다.

데모로 Happy Coffee 사이트를 썼고, 로컬 에이전트와 웹 UI를 섞는 하이브리드 구성도 소개됐다. 사용자가 화면을 보면서 일부는 직접 조작하고 일부는 에이전트에 맡기는 형태다.

남는 질문은 채택이다. 사이트가 자기 기능을 에이전트에게 열어줄 유인이 있어야 하는데, 광고 기반 사이트에서는 에이전트가 화면을 건너뛰는 것이 수익 감소를 뜻한다. 거래가 발생하는 사이트와 광고로 사는 사이트의 유인이 정반대라, 이 표준이 어디까지 퍼질지는 기술이 아니라 사업 모델이 정한다.

AI 콘텐츠 제작 파이프라인

AI 영상 제작 - 프롬프트 구조 12개와 로컬 GPU 파이프라인

Threads · @nam_ai_ai 외

오늘 소셜 쪽에서 가장 실무적인 묶음이다. 여러 계정이 각자의 파이프라인을 공개했는데 겹쳐 읽으면 현재 표준 구성이 보인다.

프롬프트 쪽. Higgsfield 팀이 공개한 브리프와 문서와 에셋으로 패턴 연구를 마친 결과가 정리돼 돌았다. 프롬프트 구조가 최소 12개이고 이 구조들이 서로를 보완해 모델이 헛도는 것을 막는다는 것이다. 그리고 이미지 시트가 앵커 역할을 한다. 프롬프트로 부족한 정보를 이미지로 강하게 고정하는 방식이다.

가장 실용적인 발견이 화각 표기다. 가장 안정적인 앵글과 렌즈 화각이 MCU와 47이었다. 35mm나 85mm처럼 흔히 쓰는 표기보다 숫자로 표현하는 쪽이 더 잘 먹힌다는 관찰인데, Higgsfield가 반복적으로 쓰는 최적화된 심도 수치가 따로 있다는 지적도 붙었다. 결론이 냉정하다. 일반인이 AI 도움 없이는 절대 못 하고, 영화 감독 출신이어도 생성형 모델 고유의 해석 습관 때문에 맞추기 어렵다. 촬영 지식이 그대로 이식되지 않는다는 뜻이다.

두 갈래 경로. 플랫폼(Higgsfield와 Kling 등, 비용은 들지만 편리)과 로컬 PC 셋업으로 갈린다. 로컬 쪽 진입 기준이 구체적인데 4070급이 입문, 4090이 적당, 5090이 최상이다. 핵심 스택은 ComfyUI + MiniMax H3 + Wan2.2다. 반년 전만 해도 일일이 수작업으로 셋업하던 것을 이제 Claude가 대부분 처리하고, 세세한 부분에서 사람이 개입하는 것이 노하우가 됐다는 관찰이 붙었다. 앞서 본 메모리 가격 상승이 이 취미의 진입 비용을 직접 올리고 있다는 점도 함께 봐야 한다.

가장 반응이 컸던 것은 종이 질감 모션그래픽 쇼츠를 10분에 만드는 5단계 파이프라인이었다. 좋아요 617에 댓글 618개로 댓글이 좋아요와 맞먹었는데, 따라 해보고 막힌 지점을 묻는 사람이 많았다는 뜻이다. 단계는 이렇다. 1. Pinterest에서 Vox 스타일 이미지를 레퍼런스로 저장한다. 2. Flow에서 애셋 시트를 만들고 대본에 맞춰 씬별 이미지를 추출한다. 3. 씬 이미지를 종이 콜라주 스톱모션 영상으로 변환한다. 4. ElevenLabs에서 AI 성우를 고르고 Pinokio(Qwen3)로 자막과 음성 환경을 준비한다. 5. Claude Code로 GitHub 원클릭 세팅을 한 뒤 스크립트만 전달해 자동 편집한다. 마지막 단계에서 코딩 에이전트가 영상 편집 자동화에 들어간다는 점이 눈에 띈다.

기업 쪽 소식으로는 징둥(JD)이 실시간 영상 편집 모델 JoyAI-Video-Edit을 오픈소스로 공개했다. 카메라 영상이 들어오는 즉시 인물과 배경과 의상을 바꿀 수 있고 영상 길이 제한 없이 계속 편집할 수 있다. 720p에서 약 30FPS로 동작하지만 RTX PRO 6000 Blackwell급 GPU가 필요해 일반 PC에서는 부담이다.

Hermes Bot Mode - 같은 글이 X 4,270, LinkedIn 115

X · Nous Research

Nous Research가 Hermes의 Bot Mode를 공개했다. 구조는 이렇다. 에이전트 프로필이 이름 붙은 Bot들의 묶음으로 바뀐다. 각 Bot이 자기만의 역할과 모델과 메모리와 스킬과 프로필 사진을 갖고, 아무 모델이나 쓸 수 있으며 Bot끼리 서로 통신한다. 슬로건은 "전문 Bot을 한 번 만들어 두면 계속 쓴다"이다.

오늘 다룬 다른 항목들과 겹치는 지점이 뚜렷하다. dsh의 Preset이 세션의 실행 프로필을 정의했다면 이쪽은 그 프로필을 인격 단위로 쪼개 이름을 붙이고 각각에 별도 메모리를 붙였다. Okara의 AI CMO가 마케팅 기능을 에이전트 9종으로 나눈 것과도 형태가 같다. 역할별로 나눈 뒤 그들 사이의 통신을 허용하는 구성이 여러 곳에서 동시에 나오고 있다.

제품과 별개로 기록할 값이 있는 것은 같은 문구를 같은 시점에 두 플랫폼에 올렸을 때의 반응 격차다. X에서 4,270 좋아요, LinkedIn에서 115였다. 37배 차이다. 오픈웨이트 모델과 에이전트 자동화라는 주제가 X의 기술 커뮤니티와는 맞고 LinkedIn 오디언스와는 어긋난다는 뜻인데, 콘텐츠를 여러 플랫폼에 동시 배포하는 것이 기본이 된 지금 이 격차를 무시하면 잘못된 신호를 읽게 된다. 같은 글의 LinkedIn 성과가 나쁘다고 콘텐츠가 실패한 것이 아니다.

여행 계획을 4단계 도구 체인으로

LinkedIn · Karl Weinmeister (Google)

문제 제기가 이 글의 논점이다. AI에게 "7일 이탈리아 일정" 하나를 통째로 시키면 관광객 함정으로 가는 지름길이라는 것이다. 단일 프롬프트로 결과를 통째로 받는 것과, 통합된 도구 묶음을 단계별로 오케스트레이션하는 것은 다른 일이라는 논지다.

실제로 연결한 체인이 넷이다. 첫째, Gemini Deep Research로 여행 소스 100개 가까이를 하나의 계획으로 압축한다. 둘째, Audio Overview로 짐을 싸면서 들을 팟캐스트를 만든다. 셋째, Google Antigravity Browser Agent가 Chrome을 직접 제어해 Trenitalia 사이트에서 최적 기차 노선을 탐색한다. 넷째, Google Workspace로 캘린더를 동기화하고 오프라인에서도 열리는 문서를 상시 보유한다.

세 번째 단계가 기술적으로 핵심이다. API가 아니라 사람이 쓰는 화면을 그대로 조작했다는 것인데, 앞 섹션에서 본 WebMCP가 풀려는 문제를 현재 방식으로 통과한 셈이다. 이탈리아 국철 예매 사이트처럼 API가 공개되지 않은 서비스에서는 이 경로 말고 대안이 없고, 그래서 WebMCP 같은 표준이 논의되는 것이다.

네 번째 단계도 의외로 실용적이다. 여행 중 데이터가 안 터지는 상황을 전제해 오프라인 문서를 미리 확보한다는 것인데, 클라우드 도구 체인의 결과물을 마지막에 오프라인으로 떨어뜨리는 습관은 여행 외의 상황에도 그대로 적용된다.

한 가지 짚어둘 것은 자동화 범위다. 검색과 조회까지는 에이전트가 하되 실제 결제는 사람이 확인하는 구성이 안전하다. 앞서 본 OrbitQuote의 "만들고 멈춘다"와 같은 경계다.

연구자용 LLM 위키 - NotebookLM이 못 하는 것

Threads · @jiihn.bible

인문학 연구자들이 매번 채팅창에 논문 PDF를 업로드하고 그때그때 대화하는 방식의 한계를 짚은 글이다. 실제 연구 흐름을 단계로 나열한 대목이 문제를 정확히 보여준다. 논문을 읽는다, 메모한다, 며칠 뒤 다른 논문을 읽는다, 질문한다, 또 설명한다, 한 달 뒤 다시 같은 문제를 조사한다. 매 단계마다 앞서 세운 이해를 처음부터 다시 설명해야 한다.

NotebookLM에 대한 비판도 구체적이다. 좋은 도구이지만 그 이전 문서들의 기억을 가져가지 못한다. 노트북마다 컨텍스트가 닫혀 있어서, 20편을 읽었어도 21번째를 읽을 때 앞의 20편에서 세운 개념 지도를 쓸 수 없다. 오늘 별도로 다룬 에이전트 메모리 논의와 같은 문제를 개인 연구 워크플로에서 만난 것이고, Engelbart가 "compaction 이후 목표가 흘러내린다"고 진단한 것과 구조가 같다.

대안으로 제시된 것이 LLM 위키다. 파일 시스템이 곧 지식베이스가 되고 에이전트가 이전 노트를 검색해 읽은 뒤 새 문서를 그 맥락에서 정리하는 구성이다. 앞서 본 Dirge가 Markdown 대신 SQLite를 프로젝트 메모리로 삼은 것, Facts 프로토콜이 큐레이션 규칙을 표준화하려는 것과 같은 자리인데, 개인 연구자는 그 규칙을 스스로 세워야 한다.

다만 진입 장벽이 솔직하게 나열됐다. 이걸 쓰려면 Claude Code, Codex, 터미널, CLI, Obsidian으로 영역을 확장해야 한다. 연구자 대다수에게 이 다섯은 각각 별개의 학습 비용이고, 그래서 이 구성이 NotebookLM보다 낫다는 것과 그것을 권할 수 있다는 것은 다른 이야기다.

건강, 과학, 공공

사진 한 장으로 대사 위험을 - Google PhotoScan

Google Research 블로그 · Cassie Zhou, Ahmed Metwally

스마트폰 사진에서 체성분과 대사 위험을 추정하는 연구다. UK Biobank의 3만 5,000건 이상으로 사전학습하고 677명으로 파인튜닝했다.

수치가 흥미로운 이유는 비교 대상 때문이다. 체지방률 추정에서 PhotoScan의 평균절대오차가 2.15인데 가정용 체성분계에 널리 쓰이는 생체전기저항(BIA) 방식이 2.91이다. 사진 한 장이 전용 측정 장비보다 정확했다.

더 중요한 결과는 위험 예측 쪽이다. 대사 위험 판별에서 AUROC가 BMI 단독 0.692, PhotoScan 0.760, DXA(이중에너지 X선 흡수계측) 0.773이었다. DXA는 임상에서 쓰는 정밀 장비인데 사진 기반 추정이 그 근처까지 왔다. 반면 BIA는 BMI 대비 개선이 사실상 0이었다. 널리 쓰이지만 위험 예측에는 정보를 더하지 못한다는 뜻이다. 인슐린 저항성 지표인 HOMA-IR 관련 수치는 2.9로 보고됐다.

연구 프로토타입 단계임을 명시해둔다. 제품이 아니고 임상 승인 대상도 아니다. 그리고 UK Biobank 기반이라 인구 구성이 특정 지역과 연령대에 치우쳐 있어, 다른 집단에서 같은 성능이 나올지는 별도 검증이 필요하다.

7년 독학 뒤에 만든 게놈 탐색 도구

Hacker News · Sergey, gene-inspector.pro (Show HN)

Show HN 중에서도 배경 서사와 데이터 규모가 함께 있는 드문 사례다.

계기가 이렇다. 저자의 아들이 여러 건강 문제를 진단받았을 때 의사가 **"그걸 안고 사는 법을 배우라"**고 했다. 저자는 거부하고 답을 찾기 시작했고, 이후 7년을 유전학과 세포생물학 독학에 썼다. 그 탐색이 도구를 만들고 가족 DNA를 시퀀싱하는 데까지 이어져, 지금은 3대에 걸친 가족 14명의 게놈 데이터를 연구한다.

도구가 하는 일은 원시 DNA 데이터를 조사해볼 만한 후보 목록으로 좁히는 것이다. 수백만 개 변이를 훑는 대신 흥미로운 것을 찾고, 그것이 건강 주제나 대사 경로나 약물과 어떻게 연결되는지 탐색한다. 일반 DNA 검사와 Whole Exome Sequencing, Whole Genome Sequencing 데이터를 지원한다.

설계에서 눈에 띄는 건 근거 파이프라인이다. 저자는 오픈액세스 논문을 처리해 특정 변이에 대한 주장을 찾아내고 각 주장을 그 출처에 연결하는 파이프라인을 따로 만들었다. 의도가 명확하다. 사용자가 블랙박스 해석을 신뢰하는 대신 연구를 스스로 확인할 수 있게 하려는 것이다. 소비자 유전자 검사 서비스가 흔히 받는 "어떤 근거로 그 해석이 나왔는가"라는 비판을 정면으로 겨냥한 구조다.

데이터 규모가 구체적으로 공개돼 있다. 유전자 23,605개, 사전 구축 패널 102개, evidence signal 8종이고 약물 쪽은 반응 노트 28,139건에 약물 1,165종, 연구 참조 8,431건이다. 패널은 비타민 14개, 미네랄 12개, 호르몬 22개, 에너지와 경로 8개, 지원 경로 18개, 유전 질환 컬렉션 20개로 나뉘고 커스텀 패널도 만들 수 있다.

결과 화면 예시가 하나 실려 있다. TNFRSF11A rs1805034, 유전형 CT, 빈도 0.55, 독성 카테고리인데, 이 유전형이 여러 진통제에서 두드러기나 혈관부종 위험 증가와 연관됐다는 설명과 함께 "다른 유전적, 임상적 요인도 중요할 수 있다"는 단서가 붙는다. 단정하지 않고 한계를 함께 표기하는 방식이다.

AI는 나중에 붙었다. 대부분의 사용자가 유전학자가 아니므로 설명을 돕는 AI 리서치 에이전트 Diana를 만들고 있는데, 이 에이전트가 모자 두 개를 쓴다. 유전학자 모자는 엄격하고 회의적이며 더 강한 임상 근거에 집중하고, 기능의학 모자는 대사와 효소와 경로와 흔한 변이를 더 넓게 본다. 텍스트와 실시간 음성 대화를 지원하지만 초대제 베타다. 저자가 덧붙인 문장이 이 프로젝트의 성격을 요약한다. "Gene Inspector의 대부분을 AI 물결 이전에 손으로 만들었다."

가격은 개인 월 15달러(게놈 1개), 의료 종사자 월 99달러(활성 게놈 최대 15개)다. 규제 표기는 분명하다. FDA 검토나 승인 대상이 아니고 어떤 질병도 진단, 치료, 예방, 완화, 치유하지 않으며 의사-환자 관계가 성립하지 않는다.

이 항목을 오늘 다른 글과 겹쳐 읽으면 대비가 산다. yogthos가 "LLM은 자기 전문성 밖의 문제를 풀어주지 못한다"고 쓴 것과, 7년 독학 뒤에야 도구를 만들고 AI를 마지막에 붙인 이 사례가 정확히 같은 이야기를 다른 분야에서 한다.

단일지불자 전환 비용 추정 - 프리프린트

Hacker News · Alison Galvani (Yale), medRxiv 프리프린트

미국 의료를 단일지불자 체계로 전환할 때의 비용과 효과를 추정한 연구다. medRxiv 프리프린트이고 동료심사를 거치지 않았다. 규모가 큰 추정이라 이 단서를 먼저 붙인다.

핵심 추정치는 연간 1조 400억 달러(약 20%) 절감이고, 보수적 시나리오에서도 6,630억 달러다. 그중 3,040억 달러는 이미 다른 경로로 반영된 절감이라 순증분은 그만큼 줄여 봐야 한다.

인명 관련 추정에서 눈여겨볼 구성이 있다. 예방 가능한 사망 추정 62,863명 중 29,631명이 이미 보험에 가입한 사람들이다. 무보험이 문제의 전부가 아니라 과소보험(underinsured) 4,500만 명이 별개의 문제라는 뜻인데, 보장은 있지만 자기부담금 때문에 치료를 미루는 집단이다. 합계 추정은 114,174명이다.

방법론 반박도 함께 기록해둔다. jandrewrogers가 추정에 쓰인 가정들이 절감 쪽에 유리하게 설정됐다고 지적했다. 행정 비용 절감분과 약가 협상 효과를 어떻게 잡느냐에 따라 결과가 크게 달라지는 종류의 모형이라, 단일 숫자보다 시나리오 범위로 읽는 것이 맞다.

시스템 엔지니어링과 저수준

Rust 인프라 두 장면 - Pingora의 절감과 fwctl.rs의 정체

Threads · @catveloper

같은 언어의 성공과 정체가 같은 날 나란히 돌았다.

성공 쪽은 Cloudflare의 Pingora다. 하루 1조 건의 요청을 처리하면서 이전 스택 대비 **CPU 70%, 메모리 67%**를 절감했다. 이 규모에서 그 정도 절감이면 서버 대수와 전력이 통째로 달라진다. 메모리 안전성이 Rust 채택의 명분으로 자주 인용되지만, 실제로 대규모 도입을 정당화한 것은 자원 효율이었다는 사례다.

정체 쪽은 NVIDIA가 제출한 fwctl.rs다. 593줄짜리 커널 드라이버가 아직 머지되지 않았다. 쟁점은 use-after-free 관련 논의인데, Rust로 작성한 드라이버가 C로 된 커널 서브시스템과 생명주기를 주고받는 지점에서 안전성 보장이 어디까지 유지되는지가 문제다. Rust 쪽 타입 시스템이 보장하는 것과 C 쪽에서 넘어오는 포인터의 실제 수명이 어긋날 수 있다.

두 장면을 나란히 놓으면 현재 위치가 보인다. 사용자 공간의 대규모 서비스에서는 이미 검증됐고, 커널 경계에서는 여전히 협상 중이다.

SoLo - 정적 바이너리가 호스트 GPU 드라이버를 dlopen한다

Hacker News · pg83 (SoLo, IX 빌드 시스템)

이식성 논쟁을 실측으로 끌어내린 글이다. 문제 상황이 이렇다. musl로 빌드한 정적 바이너리는 어디서든 돌지만, GPU를 쓰려면 호스트에 설치된 glibc 기반 드라이버를 dlopen해야 한다. 정적 링크된 musl 세계와 동적 glibc 세계 사이에 문을 내야 하는 것이다.

저자가 만든 검증 방식이 인상적이다. 매 커밋마다 CI가 Debian 상위 1,000개 패키지에서 나온 2,100개 이상의 공유 객체를 실제로 로드해본다. 되는지 안 되는지를 주장하지 않고 매번 잰다. 미지원 심볼을 만나면 조용히 실패하지 않고 심볼명과 버전을 대며 abort한다.

다루기 어려운 부분들이 구체적으로 나열됐다. C++ 예외가 경계를 양방향으로 넘나드는 문제, TLS(thread-local storage)의 네 가지 모델과 그중 load-once나 initial-exec가 강제하는 제약 같은 것들이다.

저자가 남긴 두 문장이 이 글의 논지다. "시스템 .so 하나 때문에 배포판을 통째로 배송하는 건 이식성이 아니다." 컨테이너로 전체 유저랜드를 싸서 돌리는 현재 관행에 대한 반박이다. 그리고 "Loading is the floor, not the claim." 로드된다는 건 최소 조건일 뿐 동작한다는 주장이 아니라는 것인데, 앞서 본 로컬 추론 튜닝 기록의 "로드만 되는 것을 256K 지원이라 부르지 않는다"와 정확히 같은 태도다.

rustc의 GPU 오프로드 - "C++에서 안 됐는데 왜?"

Hacker News · Manuel Sebastian Drehwald

Rust 컴파일러에 GPU 오프로드를 네이티브로 통합하려는 작업이다. 별도 라이브러리나 DSL이 아니라 컴파일러가 직접 커널을 뽑아내는 방식이다.

Rust가 유리한 지점이 하나 있다. 소유권 규칙 덕분에 noalias를 훨씬 공격적으로 붙일 수 있다. 포인터가 서로 겹치지 않는다는 보장은 GPU 코드 생성에서 최적화 여지를 크게 벌리는데, C++에서는 프로그래머가 restrict를 손으로 붙이고 그게 맞기를 바라야 한다.

어려운 지점도 구체적이다. cross-vendor ABI mismatch가 있고, 현재 구성은 2-pass 파이프라인이라 컴파일 흐름이 단순하지 않다. 벤치마크로는 RAJAPerf가 쓰인다. 관련 작업 일부(#131513)는 이미 코드베이스에 들어가 있다.

댓글에서 나온 반문이 이 프로젝트의 핵심 질문이다. "C++에서 수십 년 시도해도 안 됐는데 왜 Rust에서는 될 거라 보는가." 답으로 제시된 것이 앞서 말한 앨리어싱 보장과, 컴파일러와 표준 라이브러리와 패키지 매니저가 한 조직 아래 있어 실험을 밀어붙일 수 있는 구조다. 설득력이 있는지는 결과가 말할 문제다.

스무 살이 쓴 5만 줄 - 512KB 컴파일러가 자기를 재현한다

Hacker News · Oscar Toledo G. (nanochess)

스무 살에 쓴 5만 줄짜리 프로젝트 이야기다. 컴파일러 바이너리가 512KB인데 비교 대상인 GCC는 2MB다.

가장 강한 주장이 재현성이다. 컴파일러와 어셈블러 합쳐 10,203줄이 자기 자신을 바이트 단위로 동일하게 재현한다. 부트스트래핑된 컴파일러가 자기 소스를 컴파일해 나온 바이너리가 원본과 완전히 같다는 것인데, 컴파일러 정확성에 대한 가장 직접적인 증거 중 하나다.

제약을 우회한 방식도 재미있다. 링커가 없어서 이미지 파일을 다루려면 별도 방법이 필요했는데, JPEG 포맷을 개조해 풀었다. 그리고 2000년에 이미 JavaScript 지원을 넣었다. DJGPP에 대한 헌사가 함께 실렸다.

앞서 본 SoLo와 나란히 놓으면 흐름이 보인다. 하나는 정적 바이너리가 시스템 라이브러리에 문을 내는 이야기고 하나는 아예 시스템 없이 자기 완결적으로 도는 이야기인데, 둘 다 "무엇이 있어야 소프트웨어가 도는가"를 최소로 깎는 작업이다.

Parano1d - 저장하는 대신 증명하는 L1

Hacker News · Ignotus Nemo (Show HN)

Show HN 치고 문서 밀도가 이례적으로 높다. 홍보 문구보다 수치가 많아 남길 값이 있다.

문제 정의가 명확하다. 블록체인에는 구조적 결함이 하나 있는데, 현재 상태가 스스로를 증명하지 못한다는 것이다. 유효성이 누적된 역사에서 상속되기 때문에 Bitcoin은 제네시스부터 체인을 검증해 그 유효성을 재구성한다. 스냅샷이나 체크포인트로 부트스트랩을 줄여도 의존성을 앞으로 옮길 뿐이다. 저자는 이게 일시적 한계가 아니라 모델에 구워져 있는 것이라고 못 박는다.

전환의 핵심은 유효성을 완전한 정보가 이미 존재하는 자리에서 한 번 확립하는 것이다. 인가는 private witness를 가진 지갑 소유자가 로컬에서 증명하고, 채굴자는 공개 트랜잭션 로직과 정확한 상태 전이를 증명하며, 네트워크는 같은 실행을 반복하는 대신 그 증명들을 검증한다. 수락된 모든 블록이 **재귀적 HistoryStep**을 지녀 그 블록의 상태 전이를 증명하고 직전 터미널을 검증한다. 증명 크기와 검증 작업이 블록 높이에 따라 늘지 않는다. 결과적으로 체인의 나이가 하드웨어 요구사항이 되지 않는다. 몇 년 뒤에도 평범한 노트북이 전체 라이브 상태를 담고 독립 검증할 수 있다는 것이다.

소유권 설계도 특이하다. 공개키도 전자서명도 없다. 주소는 256비트 지출 비밀의 Poseidon2b 이미지이고, 소유권은 그 preimage에 대한 영지식 지식 증명이다. 여기서 파생되는 결과가 흥미로운데, 트랜잭션 합의에 타원곡선이 전혀 없어 포스트양자 마이그레이션 시 교체할 트랜잭션 스킴 자체가 없다.

프라이버시 성격을 오해하지 않게 명시한 것도 좋다. 투명 체인이지 프라이버시 체인이 아니다. 현재 값과 소유자는 공개이고 릴레이되는 트랜잭션도 보인다. 여기서 프라이버시는 은폐가 아니라 비보존에서 온다. 외부 추적자를 만들 수는 있지만 그 사람이 전체 트랜잭션 스트림을 직접 기록해야 하고, 네트워크가 모든 노드에 그 부담을 지우지 않는다.

성능의 핵심은 자체 개발한 FROST-GKR(Frobenius Reduction Over Shifted Tables)이다. 순열마다 저차 sumcheck 체인을 돌리는 대신 Poseidon2b 배치와 Merkle 경로 전체를 공유 Boolean hypercube 위의 직접 7차 관계로 묶는다. 동일 조건 59-순열 벤치마크에서 프로버 중앙값 시간 10.69배, 프로토콜 검증자 중앙값 시간 14.80배, 원 대수 증명 바이트 51.67배 감소다.

보안 주장이 이례적으로 구체적이다. 목표 FRI 보안 128비트에 대해 Block-Tiwari FS-FRI 기준으로 provable 127비트, conjectured 127비트(둘 다 [127, 128) 구간)를 보고한다. NIST 포스트양자 Category 1이고, 지배적 Category 1 게이트 깊이 하한이 173.273866314232비트로 NIST 2^170 기준 대비 3.273866314232비트 마진이다. 산술 스택은 커밋된 트레이스가 이진 타워 필드 GF(2^128) 위에, 프로덕션 wide-challenge 레이어가 GF(2^256)에 올라간다.

PoW 설계도 특이하다. 해시파워만으로는 블록을 만들 수 없다. 생산자는 정본 상태를 따라가며 nonce와 무관한 HistoryStep을 완료한 뒤에야 고정된 헤더를 탐색할 수 있고, PoW의 유일한 일은 유효한 전이들의 순서를 정하는 것이다. 외부 채굴자는 변경 불가능한 일회용 템플릿을 받아 nonce만 돌려주며 트랜잭션이나 상태 루트를 바꿀 수 없다.

퍼블릭 테스트넷 프로필은 평균 블록 목표 20초, 블록당 최대 논리 트랜잭션 255, 최대 1페이지 처리량 12.75 TPS, reorg 구간 18블록이다. 배분은 프리마인 없음이고 블록 1부터 6,307,200까지(정확히 365일 기준 3년) 보상을 90% 채굴자, 5% Network Fund, 5% Lab으로 나눈 뒤 이후 100%가 채굴자에게 간다.

운영 주의사항이 하나 명시돼 있다. 현재 wallet.key가 비밀번호로 암호화돼 있지 않다. 소유자 전용 권한으로 생성되니 백업하고 보호하라는 것이다. 라이선스는 Apache 2.0이고, 재현 가능 빌드의 trustless 경로는 릴리스 태그를 체크아웃한 뒤 HistoryStep 행렬을 로컬에서 생성하는 것이다.

판단을 하나 붙인다. 익명 개발자의 신생 L1이라는 점에서 채택 전망은 논외로 두는 게 맞다. 다만 "현재 상태가 자기 증명을 지니면 체인 나이가 하드웨어 요구사항이 되지 않는다"는 명제와 FROST-GKR의 구체적 배수, 그리고 서명 없는 소유권으로 포스트양자 마이그레이션 대상 자체를 없앤 설계는 기술적으로 기록할 값이 있다.

declarative-forms - 마운트할 컴포넌트가 아니라 호출할 함수

Hacker News · wolfoo2931 (Show HN)

폼 라이브러리 하나지만 API 설계 논지가 분명하다. 한 문장으로 요약된다. 모든 다른 폼 라이브러리는 마운트할 컴포넌트를 주는데, 이건 호출할 함수를 준다. 원하는 레코드를 기술하면 평범한 객체를 돌려받는다.

출발점 논리가 설득력 있다. prompt()는 브라우저가 공짜로 주는 유일한 폼 API이고 모두가 당연하다고 느끼는 모양이다. 물어보면 브라우저가 다이얼로그를 그리고 답을 받는다. 유일한 결함은 정확히 문자열 하나만 물어본다는 것이다. declarative-forms는 그 모양을 유지하고 한계만 없앤다. 통합의 전부가 const release = await ask([...]) 한 줄이라, 컴포넌트도 폼 상태도 마운트 지점도 없다.

선언만으로 얻는 동작들이 실질이다. 탭은 필드당 tab 키 하나로 만들어지고 활성 필드가 없는 탭은 스스로 숨는다. 조건부 필드는 isActive로 처리되고 숨겨진 필드는 getValues()에서 완전히 사라진다. 비동기 의존 옵션은 reloadOnChangeOf: ['team']으로 선언하는데, 오래된 요청이 새 요청보다 늦게 답하면 라이브러리가 옛 답을 버린다. 경쟁 조건을 사용자가 아니라 라이브러리가 처리한다는 뜻이라, 실무에서 자주 새는 버그 하나를 구조적으로 막았다. 파생값은 kind: 'computed', 중첩 레코드는 kind: 'array'이고, 다이얼로그가 쌓이면 자식이 stackData로 아래 다이얼로그들의 값을 읽는다.

경쟁 라이브러리와의 구분도 명확하다. React Hook Form이나 Formik은 상태 라이브러리라 입력과 라벨과 레이아웃을 직접 써야 하고 각각 단일 프레임워크에 묶여 있다. declarative-forms는 다이얼로그 전체를 렌더하고 순수 DOM에 웹 컴포넌트 하나라 프레임워크가 필요 없다. JSON-Schema 렌더러와의 구분은 디스크립터가 살아 있다는 것이다. options, isActive, defaultValue, compute가 각각 현재 폼 데이터의 함수일 수 있다. 런타임 의존성도 빌드 단계도 없다.

가장 좋은 점은 안 맞는 자리를 더 분명히 적었다는 것이다. 범용 폼 라이브러리가 아니고 고정 레이아웃 하나만 렌더한다. 검증 프레임워크가 없다 - required도 규칙 객체도 스키마도 없고, 필드별 메시지와 isValidRecord와 버튼 isActive는 있지만 모든 검사가 직접 쓰는 코드이며 메시지 표시와 제출 차단이 분리돼 있다. 그리고 접근성이 미완성이다. 라벨과 id와 포커스 가능한 버튼은 맞지만 다이얼로그 시맨틱, 콤보박스 ARIA, 키보드로 도달 가능한 체크박스가 아직 없다. 접근성 준수가 필요한 곳에 쓰기 전에 문서를 읽으라고 못 박았는데, 자기 한계를 이 정도로 구체적으로 나열한 라이브러리가 드물다.

Klar와 openleetcode - 차용 출처를 밝힌 언어, 저장소로 내려온 판정기

Hacker News · ProCode-Software (Klar) / therepanic (openleetcode)

Klar는 덴마크어로 "명확한"이라는 뜻이고 원칙이 한 줄이다. 코드를 읽으면 그게 곧 하는 일이고 숨은 동작이 없다. 목표로 진보성, 명확함, 안전(모든 에러 처리, 런타임 크래시 최소, null 예외 없음), 작은 언어(하나의 방법만 존재), 초보자 친화, 상호운용, 빠른 컴파일을 든다.

차용 출처를 하나하나 밝힌 게 흥미롭다. 관용구는 Go, 에러 처리는 Rust와 Gleam, 타입 시스템은 TypeScript, 문법은 Swift와 Go, when 표현식은 Kotlin, 열거형과 패턴 매칭은 Gleam과 Rust, 툴링은 Go와 JavaScript, 컴파일러는 Go와 Gleam이다. 신규 언어가 영향 관계를 이 정도로 명시하는 경우가 드물다.

툴체인이 통합돼 있다. 컴파일러와 포매터와 린터와 버전 매니저가 기본 내장이고 패키지 매니저는 Glas, 자체 마크업 포맷 Klon(KLar Object Notation)으로 매니페스트 glas.pack과 빌드 파일 klar.build를 쓴다. 컴파일러는 Go로 작성됐고 캐싱과 증분 컴파일을 활용한다. 타입체커가 개발 중이라 NO_TYPECHECK=1로 끄면 문법만 검사한다. 프로덕션 사용을 권장하지 않는다고 명시했고, 기능 구현 방향에 대한 피드백을 RFC로 모으는 중이라 의견이 절실하다고 적었다. Apache 2.0이다.

openleetcode는 성격이 다르다. LeetCode를 로컬에서 돌리되 테스트가 저장소 안에 사는 러너다. 약 1.4k 문제를 지원하고 평범한 해답 파일을 받아 문제 매니페스트를 찾고, 작은 언어별 하네스를 만들고, 플러그형 실행 백엔드로 보내고, 로컬에서 판정한다. 저자의 정리가 좋다. 테스트도 런타임 템플릿도 저장소에 있고 CLI는 접착제일 뿐이다.

실행 백엔드는 Docker로 띄우는 Piston이고 런타임 템플릿이 12종이다. 각 런타임이 LeetCode 문제가 흔히 요구하는 호환 계층(JSON 출력, 배열, 행렬, 연결 리스트, 이진 트리)을 제공하고, 임포트와 공용 라이브러리를 공식 환경에 가깝게 맞춰 해답이 전용 프로그램이 아니라 평범한 제출처럼 보이게 한다. Haskell로 작성됐고 Cabal로 빌드하며 라이선스는 Unlicense다. 시스템 디자인, SQL, 동시성 문제는 아직 미지원인 MVP다.

기여 경로에서 LLM을 쓰는 방식이 이 프로젝트를 오늘 다른 항목과 잇는다. 헬퍼 스크립트 셋 중 spartan.pyOPENROUTER_API_KEY가 있으면 LLM에게 매니페스트 초안을 시키고, molotov.py가 그 폴더에서 언어별 해답 파일을 채운다. 저자가 붙인 단서가 좋다. "출력을 인내심이 무한한 주니어 기여자처럼 다뤄라. 유용하고 빠르지만 여전히 리뷰가 아주 많이 필요하다." README 상단에는 DHH 인용이 붙어 있다. "There are no magic machines and no magic operators."

Fairphone 6에서 postmarketOS 메인 카메라가 돌았다

Hacker News · Catcrafts 운영자 개인 블로그

1인 리눅스폰 프로젝트의 현실이 수치와 함께 공개된 글이다. 성과는 Fairphone 6의 메인 카메라 드라이버를 직접 작성해 postmarketOS에서 동작시킨 것이다.

가장 인상적인 항목은 카메라가 아니라 긴급전화다. 네덜란드 1-1-2 담당 기관(TB112)이 2026년 8월 18일 13:30~14:15 시간대에 긴급전화 테스트를 승인했다. 리눅스폰이 실사용 기기가 되려면 통과해야 하는 관문인데, 개인 프로젝트가 공식 절차를 밟아 시험 슬롯을 받은 것이다. 캐리어 4곳에서 동작을 확인했다.

프로젝트 운영 쪽 공개도 이례적이다. 은행 명세서를 근거로 재정 상태를 밝혔고, 미국과 캐나다로 배송하지 못하는 이유가 배상책임보험 때문이라는 것도 적었다. 하드웨어를 파는 개인이 부딪히는 실제 장벽이 기술이 아니라 보험이라는 사실이 드러나는 대목이다. RISC-V 폰을 만들 수 있을지에 대한 구상과 그에 대한 자기평가도 함께 실렸다.

댓글에서 나온 반론 하나가 근본을 짚는다. **"SoC 벤더의 NDA가 근본 원인"**이라는 것이다. 개인이 드라이버를 역설계해야 하는 상황 자체가 칩 문서가 공개되지 않기 때문이고, 개별 기기를 하나씩 되살리는 방식으로는 구조가 바뀌지 않는다는 지적이다.

Quake 셰어웨어 CD - 39일 만에 뚫린 "전화로 잠금 해제"

개인 블로그 · Fabien Sanglard

30년 전 DRM 이야기지만 실패 지점이 지금 봐도 익숙하다.

배경. 1996년 6월, 3년 작업 끝에 id Software가 Quake를 완성했다. 게임이 겨우 22 MiB를 써서 CD-ROM(당시 640 MiB로 PC 하드디스크의 3배)의 남은 용량을 활용하자는 아이디어가 나왔다. id 전체 카탈로그의 암호화 버전을 함께 넣으면 중간상을 자르고 전화 한 통과 신용카드로 즉시 접근을 줄 수 있다는 것이었다. CD는 1996년 7월 3일 발표, 8월 30일 출시됐다.

결과. 해커 그룹 GNOMON이 39일 뒤 Quakecrk.zip을 배포했다. 안에 든 QCRACK.EXE는 CD의 모든 게임을 복호화했다. Kushner의 Masters of Doom이 전하는 결말은 이렇다. 유통과 주문 이행이 통제를 벗어났고, id는 창고에 CD 약 15만 장을 떠안았다.

어떻게 작동했나. 게이머는 CompUSA나 Computer City 같은 수백 개 매장에서 CD를 9.95달러에 산다. 앞면 스티커에 셰어웨어 버전임과 **1-800-669-9342(1-800-ID-GAMES)**로 전화해 정식판을 열라는 안내가 있었다. 그 번호는 지금도 살아 있는데 CompUSA가 2007~2008년 사이 문을 닫아 잠금 해제 오퍼레이터 대신 노인용 상품을 파는 자동응답이 나온다.

기술 스택은 TestDrive Corp가 제공했다. 이 회사의 암호화기는 .EXE를 "denature"할 수 있었다. 앞 32 KiB를 커스텀 헤더로 교체하고(실행하면 "This application has been disabled"가 뜬다), 파일을 .MJ3로 개명하고, 원본 헤더를 .ST3로 암호화하고, seed를 발급한다. 잠금 해제를 시작하면 GUI가 CHALLENGE를 생성하고 이걸 전화로 불러준다. 결제하면 SERIAL을 받는다. 유선전화라는 통신 수단의 착오를 줄이려 두 숫자 모두 체크섬이 붙었고, 리플레이 공격을 막으려 CHALLENGE는 프로그램을 돌릴 때마다 바뀌고 GUI가 떠 있는 동안 5분마다 회전했다.

설명대로라면 결함이 없다. 그런데 GNOMON이 알아낸 것이 이것이다. 전화로 받은 SERIAL에는 비밀이 전혀 담겨 있지 않았다. 그건 그냥 결제 증명이었다. CD에 실려 있는 FLOW.EXE가 CHALLENGE로부터 SERIAL을 스스로 생성할 수 있었고, 하는 일이라고는 자기가 로컬에서 만든 SERIAL과 사용자가 입력한 값이 일치하는지 확인하는 것뿐이었다. 전체 보호 메커니즘이 security by obscurity에 의존하고 있었다. 파이프라인은 복잡했지만 2016년 rmolina가 리버스했다.

허술함이 더 있었다. 암호화된 SKU.17 옆에 **완전히 암호화되지 않은 평문 SKU.TXT**가 같은 아카이브 안에 있었다. PRODUCT.TXT, EXE.TXT처럼 .17 암호화 버전과 짝을 이루는 평문이 여럿이었다. 전화할 때 함께 불러주게 돼 있던 "SOURCE CODE" 필드는 잠금 해제 코드 생성에 아무 역할도 하지 않았고 유통사가 거래 수수료를 청구하는 수단이었던 것으로 보인다. eBay에서 확인된 값들이 22-CUSA(CompUSA), 24-CCITY(Computer City), 12-BSTBY(BestBuy) 같은 식이다.

저자가 뽑아낸 격언이 **"Fab's Razor"**다. "악의로 설명할 수 있는 것을 어리석음으로 돌리지 마라. 그리고 어리석음으로 설명할 수 있는 것을 시간 압박으로 돌리지 마라." 그리고 논의에서 _def가 남긴 정리가 이 사건의 교훈을 현재로 가져온다. 시스템이 외부 정보가 필요한 척했을 뿐 실제로는 클라이언트가 답을 스스로 계산할 수 있었다는 것이다. 클라이언트가 서버의 답을 계산할 수 있으면 그건 인증이 아니라 영수증 확인이고, 30년 뒤 클라이언트 사이드 라이선스 검증에도 그대로 적용된다.

셀프호스팅 소품 셋 - Particle, PlopKit, 자장가 변환기

Hacker News · crnst8 (Particle) / runn077 (PlopKit) / 익명 (Lullaby Converter)

세 개 모두 개인이 자기 필요로 만들었고 셀프호스팅이나 로컬 처리를 전제한다.

Particle의 동기가 공감을 산다. 자동재생 영상과 CTA와 쿠키 경고로 뒤덮인 웹에 지쳐서 만들었고, 저자가 만든 앱 중 가장 많이 쓰는 것이 됐다. 기사 URL을 넣으면 구조와 포맷과 풀인용과 이미지를 유지한 채 추출해 SQLite 라이브러리에 저장한다. 태블릿이나 폰 독서용으로 PWA 저장이 잘 된다. 실행은 한 줄이다.

docker run -d -p 4747:4747 -v particle-data:/app/data ghcr.io/crnst8/particle:latest

PlopKit은 Disqus 대안을 표방하는 오픈소스 셀프호스팅 댓글 플랫폼이다. 스크립트 한 줄로 임베드하고 웹 대시보드에서 관리한다. gzip 21.3 kB로 가볍고, 셀프호스팅과 클라우드 사이를 오가는 사이트 데이터 import/export를 지원한다. 정책이 분명한데, 셀프호스팅 인스턴스는 호스팅 버전 대비 기능 제한이 전혀 없고 과금과 사용량 제한 코드는 셀프호스팅 모드에서 아예 실행되지 않는다. HN 댓글이 한 줄로 급소를 찔렀다. popalchemist"가입 없음은 거의 확실히 재앙으로 끝난다(봇)." 댓글 시스템에서 스팸 대응 없이 진입 장벽을 없애는 것의 위험을 지적한 것이다.

Lullaby Converter는 좋아하는 노래를 아기용 오르골 자장가로 바꾼다. 육아휴직 중 만든 두 번째 프로젝트인데 전제가 재미있다. 아기도 어른 음악을 얼마든지 즐길 수 있지만 대부분의 어른 음악은 아기가 이해하기엔 너무 밀도가 높고 복잡하다는 것이다. 파이프라인은 입력 오디오의 스템 분리에 BS-roformer, MIDI 전사에 Spotify Basic Pitch를 쓴다. 저자 자평이 솔직하다. 아직 손볼 데가 많고 원곡의 좀 취한 오르골 버전처럼 들리지만 아주 재미있다는 것이다.

AI 시대의 인간 조건

화면 앞에서 보낸 시간이 가족과 보낸 시간보다 많다면

Hacker News · Ask HN 묶음

기술 커뮤니티의 그날 최고 점수가 기술 뉴스가 아니었다는 사실 자체가 신호다. 74점을 받은 글은 컴퓨터 앞에서 보내는 시간이 가족과 보내는 시간보다 많다는 자각이었다.

계산이 단순하다. 주 40시간 노동에 더해, 수면(하루 7시간)과 노동을 뺀 나머지 79시간의 상당 부분도 화면과 보낸다. 작성자의 진단은 "부분적으로는 그게 인간이 줄 수 있는 것보다 자극적이고, 우리가 단기 쾌락을 기본값으로 삼기 때문"이라는 것이다. 그가 가장 무섭다고 꼽은 대목은 통계가 아니었다. 과거의 정상이 무엇이었는지 잊는 것이다. "10년 전엔 이렇지 않았다. 천천히 세계를 삼킨 강력한 힘이었다. 정상이 되고 익숙해질 때까지 알아채지도 못하게."

반박이 지적으로 더 값지다. 노동 자체가 대부분 화면 보기가 된 상황에서 이상한 얘기 아니냐는 것, 1800년대에 훨씬 오래 일하던 때와 비교하면 가족과 보내는 시간이 정말 줄었느냐는 것, 그리고 **"그 전엔 TV였고 그 전엔 신문이었다"**는 되풀이되는 도덕적 공포에 대한 경계다. 여기에 lbriner의 반론이 붙는데 정도의 차이가 종류의 차이가 될 수 있음을 짚는다. "컴퓨터가 주의를 붙잡는 능력은 TV나 신문보다 한 자릿수 크다. 넷플릭스와 수많은 채널이 있어도 TV는 하루 2~3시간이 한계인데, 시간만 있으면 컴퓨터 게임은 12시간도 쉽게 한다." sebst는 진짜 변한 건 함께 앉아 있으면서 각자 화면을 보는 쪽이라고 짚었다.

인용 가치가 가장 높은 것은 Tim Urban의 "The Tail End" 계산이다. 사람이 18세가 되는 시점에 부모와 직접 대면하는 시간의 90% 이상을 이미 써버렸다. "화면 시간이 나쁘다"는 추상적 훈계보다 훨씬 강하게 작동한다. 육아 관점의 현실론도 붙었다. 화면만 없으면 질 좋은 가족 시간이 저절로 생길 거라 믿는 부모가 있는데, 때로는 실제로 양육을 해서 함께 뭔가 하도록 시켜야 한다는 것이다.

같은 배치의 다른 스레드 셋이 같은 불안의 다른 얼굴이다. **"지금이 인간으로 살기 최악의 때인가"**는 AI가 코드를 생성해 개발자의 즐거움을 앗아가고 그림으로 먹고사는 사람을 더 비참하게 만든다는 문제 제기였다. 답변들이 역사적 비교로 되받았다. AnimalMuppet은 "화산 폭발 직후도, 유럽 인구 3분의 1이 죽은 흑사병도, 1차대전과 대공황과 2차대전을 앞둔 1913년도 아니다. 이건 '5년 뒤 일자리가 어떨지 모르겠고 직무 불만족이 높다'는 것"이라고 정리했고, quickthrowman은 530~550년 동지중해를 들었다. 532년 니카 폭동으로 콘스탄티노플 절반이 불탔고, 536년 화산 겨울이 시작됐고, 541년 유스티니아누스 역병이 시작됐다는 것이다. 다만 watwut의 유보가 그 비교의 한계를 짚는다. "최악의 때는 아니지만 최고의 때도 전혀 아니다. 쾌락 적응 이론으로 사람들이 실제로 하는 말을 평가절하하지 말라."

**"어떻게 하면 더 적은 것에 더 마음 쓸 수 있을까"**는 정보 과잉을 다뤘다. "링크 다음 링크, 매일 더 많은 링크다. 이게 무력화 효과를 낸다. 많으면 각각이 덜 중요해 보인다"는 진술에 대한 답 하나가 실용적이었다. 실제로 나에게 영향을 미칠 때까지 기다렸다가 유한한 주의를 준다는 것이다.

마지막 스레드는 AI를 싫어하는 친구들을 이해하고 싶다는 글이었는데, 여기서 논점이 옮겨간 것이 이 묶음에서 가장 흥미롭다. 작성자는 반대 논거가 대부분 물 사용량인데 그들도 고기를 먹고 새 옷을 산다고 지적했다. 그런데 답변 하나가 축을 바꿨다. "나에게 과한 것은 에이전트가 무엇을 하는지 이해하지 못한 채, 또는 명시적이거나 강한 제한 없이 AI 에이전트를 쓰는 것이다." 감정 논쟁으로 보이던 스레드에서 오늘 이 다이제스트의 첫 섹션이 다룬 것과 정확히 같은 실무 논점이 튀어나왔다.

제인스의 양원제 마음이 LLM 시대에 다시 읽히는 방식

Hacker News · Mark Dominus 블로그(2008)

2008년에 쓰인 서평이 2026년에 53점을 받았다. 이유는 원문이 아니라 댓글에 있다.

줄리언 제인스의 주장은 이렇다. 인간의 의식은 비교적 최근의 발전으로 길게 잡아야 약 3,000년 전이다. 언어, 특히 은유를 통한 사고의 매개가 의식의 필수 전제이며, 따라서 의식은 금속 가공과 대규모 농업과 복잡한 위계 사회구조, 심지어 문자보다도 나중이다. 그 이전의 마음은 두 반구가 덜 통합된 "양원제"였고, 어려운 결정에 부딪히면 기다리다가 신의 목소리를 들었다. 일리아스에서 아테나가 아킬레우스를 물리적으로 제지하는 장면은 꾸며낸 것이 아니라 우뇌가 만든 환청이었다는 해석이다.

블로거 본인의 태도가 정직하다. "이 이론이 놀랍도록 뛰어난지 놀랍도록 멍청한지, 나도 확신이 없다. 심오한 천재의 작업이거나 심오한 헛소리다. 어느 쪽이든 대단히 흥미롭다."

이 글을 오늘 남기는 이유는 TheHardProblem의 댓글이다. 의식에 대한 유물론적 관점의 한계를 이해하는 사람으로서 LLM이 자기를 여러 방식으로 틀렸다고 증명했다고 인정하며 이렇게 쓴다. 단어 완성에서 문장, 문단, 에세이, 코드, 픽셀 배열, 음악 완성으로 갔고, 그 전부를 영어로 집계하고 모델링하는 것만으로 그렇게 됐다는 것이다. 단어를 예측하는 것이 지식과 창의성과 생산성으로 창발할 수 있다는 데 놀랐고, 그것들이 여전히 사고로 인정된다고 본다면서 이렇게 끝맺는다. "다만 사고하는 자가 없는 사고다(just without a thinker)."

동시에 스레드는 이 유비의 약한 고리도 보여준다. Telemakhos가 제인스가 의존한 선행 연구 일부가 무효화됐다고 지적한다. Bruno Snell이 1946년에 기하학기 도기의 팔다리 표현을 근거로 고졸기 그리스인에게 통합된 신체 개념이 없었다고 했는데, 이후 고고학이 Pylos Combat Agate 같은 사실적이고 생동감 있는 묘사를 그 이전 시기에서 발견했다. 기하학기의 미학은 선택이었지 다른 종류의 의식의 증거가 아니었다는 것이다. ElFitz는 내적 독백 없이 사고하는 사람들(anendophasia)이 실재한다는 반례를 들어 "언어 = 의식" 등식을 흔든다. 그리고 검증 가능성 문제가 있다. geophile의 정리가 날카롭다. "우리는 의식이 무엇인지 모르고 다른 인간에게서도 신뢰성 있게 탐지하지 못한다."

Neal Stephenson의 Snow Crash가 이 책에서 영감을 받았고, The Big U의 서브플롯도 확실히 제인스에서 왔다는 저자 확인이 있다. 최종 정리로는 제인스를 근거로 LLM 의식론을 펴는 방향이 아니라, AI가 오래된 철학 논쟁의 판돈을 바꿔놓았다는 관찰로 읽는 것이 정확하다.

em dash의 원래 용법 - "문제로 정의할 필요 없다"

LinkedIn · 최진규

AI 문체 논쟁이 문장부호까지 내려온 자리다. em dash가 AI의 표지로 지목되면서 그 부호를 피하는 사람이 생기자, 원래 용법을 정리한 글이 돌았다.

구분은 길이로 갈린다. 하이픈은 "long-term relationship"처럼 단어를 연결한다. 대문자 N 폭인 en dash는 "1990년 - 2000년"처럼 범위를 표시한다. 대문자 M 폭인 em dash는 문장 중간에 삽입해 부연 설명하거나 강조할 때 쓴다. 셋은 길이가 다른 별개 부호이고 용도가 겹치지 않는다.

입력법도 함께 정리됐다. MS워드에서 en dash는 글자와 공백과 하이픈과 공백과 글자를 입력한 뒤 스페이스바를 누르면 자동 변환되고, em dash는 글자 다음에 하이픈 두 개를 붙이고 글자를 이어 쓴 뒤 스페이스바를 누른다. 자동 교정이 조용히 부호를 바꿔놓기 때문에, 문서에 em dash가 늘어난 것이 반드시 AI 때문만은 아니라는 점도 이 입력 규칙에서 드러난다.

저자의 입장이 이 항목의 결론이다. 문서에 em dash가 자주 보이는 것은 AI 활용에 따른 자연스러운 현상이고 이를 문제로 정의할 필요는 없다. 다만 AI가 왜 그렇게 긴 dash를 뱉었는지 용도 정도는 알고 있어야 한다는 것이다.

한 가지 덧붙일 관찰이 있다. 어떤 부호가 AI 문체의 상징이 됐다는 이유로 그것을 피하기 시작하면 쓰는 쪽이 자기 도구를 잃고, 그 회피 자체가 다음 세대의 표지를 만든다. 앞서 본 워터마킹 논의가 "표현의 run이 살아남아야 증거가 된다"고 했던 것과 겹쳐 보면, 문체를 바꿔 판별을 피하려는 시도는 워터마크를 지우지도 못하면서 글만 나빠지게 만든다.

커뮤니티, 정책, 행사

국제 AI 안전 보고서 2026 한국어판

LinkedIn · Songiy Baik (NAVER)

인공지능안전연구소(ETRI AISI)가 『국제 AI 안전 보고서 2026』 한국어판을 발간했다. Yoshua Bengio 교수가 의장을 맡고 30개국 이상 전문가가 참여한 국제 공동 과학 평가로, 범용 AI의 역량과 위험, 그리고 현재 안전장치의 현황을 담는다. 정책 논의에서 공통 참조점이 되는 문서라 번역본이 나온 것 자체가 실무적 의미가 있다.

주목할 부분은 부록이다. 원문 번역에 더해 한국의 AI 안전 정책과 산업과 연구 사례가 추가됐고 카카오, LG AI연구원, 셀렉트스타, 에임인텔리전스, 네이버가 이름을 올렸다. 국제 문서의 사례 수집에 국내 조직이 들어가는 것은 정책 대화 참여 경로가 열렸다는 뜻이다.

네이버가 실은 항목이 비교적 구체적이다. Singapore AI Safety Red Teaming Challenge 2026 참가, 생성형 AI 안전성 강화 기술 연구(STG, DATE, C-SEO Bench, SLM as Guardian), 그리고 NAVER AI Safety Framework(ASF) 업데이트다. 이 중 C-SEO Bench는 앞서 다룬 GEO와 LLM 포이즈닝 논의와 같은 문제 영역을 벤치마크로 다루려는 시도라 눈여겨볼 만하다.

같은 흐름에서 두 소식이 함께 돌았다. Anthropic이 Mind Viruses라는 논문을 냈다는 것인데, 그 발표가 있었다는 사실만 기록하고 내용 평가는 별도 자료를 봐야 한다. 붙은 논평은 목적 달성만을 위한 기술의 시대가 끝나고 사회와 마음 같은 개념을 다루는 기술이 필요한 시대가 온다는 해석이었다. 그리고 LG AI Research가 CVPR 2026에서 **Align While Search(AWS)**를 발표했다. 월드 모델이 미래 예측에서 의사결정으로 이동하는 흐름 속에서 불확실성을 다루는 belief 기반 접근이다.

Karpathy의 2시간 무료 강의

X · @0xwhrrari

Andrej Karpathy가 OpenAI와 Tesla에서 보낸 8년의 내용을 2시간짜리 무료 강의 한 편으로 정리해 공개했다. 소개 게시물은 좋아요 1,417을 받았다.

구성이 Agents -> Loops -> Graphs -> Self-Improving Systems 순서다. 단일 호출에서 루프로, 루프에서 그래프 구조로, 그리고 자기 개선 시스템으로 올라간다. 오늘 별도로 다룬 Behavior Trees 논문이 "모델을 결정론적 제어 구조의 리프 노드로 다뤄라"고 한 것, yaop이 리뷰 프로토콜을 고정 시퀀스로 못 박은 것, Dirge가 critic 게이트를 결정론적으로 배치한 것이 전부 이 사다리의 세 번째 칸에 해당한다. 커뮤니티가 각자 부딪히며 도달한 구조를 강의가 순서로 정리한 셈이다.

같이 돌던 비교 문구는 단서를 붙여 옮긴다. 게시자가 **"이보다 적게 가르치는 부트캠프에 사람들이 1만 5,000달러를 낸다"**고 썼는데, 이 비교는 검증된 것이 아니다. 어떤 부트캠프를 가리키는지, 그 커리큘럼이 실제로 이 강의보다 적은지는 확인되지 않았다.

같은 흐름에서 Google Research의 시계열 예측 모델 TimesFM도 화제였다. 1,000억 개 타임포인트로 사전학습됐고 무료로 배포된다. 언어와 비전에서 익숙해진 파운데이션 모델 방식이 시계열로 넘어온 사례인데, 수요 예측이나 용량 계획처럼 전통적으로 도메인별 모델을 따로 만들던 영역이라 파급이 크다.

Maddox AI - 0.6초 육안검사가 실제 공장에서 돈다

LinkedIn · Ilir Aliu

산업 현장 배치 사례라 기록해둔다. 공정이 구체적이다. 로봇이 부품을 집어 양면을 확인하고, AI 모델 4개가 0.6초 안에 품질 판정을 낸다. 정상이면 그대로 흘려보내고 불량이면 라인에서 빼내 공정으로 재투입한다. 중요한 건 데모 영상이 아니라 Hager 공장에서 실제 가동 중인 화면이라는 점이다.

제조 라인의 육안 검사는 컴퓨터 비전의 오래된 응용 분야인데, 실제 도입을 막는 것은 대체로 정확도가 아니라 라인 속도와 오탐 처리 비용이다. 0.6초라는 숫자가 의미 있는 이유가 여기 있다. 라인을 세우지 않고 흐름 안에서 판정할 수 있어야 도입이 성립하고, 판정 결과가 폐기가 아니라 재투입으로 이어져야 오탐의 비용이 감당 가능해진다. 모델을 하나가 아니라 4개 돌린다는 것도 같은 맥락으로 읽힌다. 서로 다른 결함 유형을 나눠 맡거나 합의로 오탐을 걸러내는 구성일 가능성이 크다.

같은 날 다룬 Roboflow Playground의 관찰과 겹쳐 보면 이 사례의 성격이 분명해진다. 범용 비전 모델은 물체가 어디 있는지는 알아도 정밀한 박스를 그리지 못하는데, 공장 검사는 정확히 그 정밀도를 요구한다. 그래서 이 영역은 여전히 태스크 전용 모델의 자리다.

배경으로 독일 튀빙겐 소재라는 점과 Cyber Valley가 9월에 10주년을 맞는다는 사실이 함께 언급됐다. 연구 클러스터에서 나온 회사가 인근 제조업에 배치되는 구조인데, 연구와 산업이 지리적으로 붙어 있을 때 나오는 응용의 형태를 보여준다.

이번 주 행사 둘

LinkedIn · Chanran Kim(가짜연구소), Yiseo HA(Figma)

실행 가능한 정보라 사실만 정리한다.

Figma Build in Public: Seoul Hackathon2026년 8월 21일 금요일 19:00에 서울 서초구 서초대로 67 3층 단군소프트에서 열린다. 규모는 디자이너 50명과 개발자 50명 총 100명, 4인 1팀이다. 형식이 특이한데, 아이디어를 디자인부터 배포 가능한 코드까지 전부 Figma 안에서 만든다. 부대 세션이 둘 붙는데 하나는 Figma AI 활용 팁이고 다른 하나는 개발자 관점의 Figma 사용 팁이다. 우승 팀 상품이 있고 Figma와 단군소프트가 공식 후원한다.

가짜연구소9월 18일 홍콩이공대학교(PolyU) SHTM과 공동으로 "AI for Smart Hospitality, Tourism & Culture" Joint Forum & Workshop을 연다. 홍콩 현지 오프라인 전용이고 온라인 참여가 없다는 점을 먼저 확인해야 한다. 가짜연구소 빌더 7명이 발표와 워크숍 진행, 패널, 모더레이터로 참여한다. 배경으로는 작년 PseudoCon 2025에서 외국인 참가자 비율 10% 목표를 세워 초과 달성했고 미국 대학에서도 참가자가 왔다는 경험이 있다. 국내 커뮤니티가 해외 대학과 공동 행사를 여는 형태라 참고할 사례다.

세계 - 전쟁, 물, 에너지

우크라이나 최대 규모 드론 공격과 러시아 내부의 균열

Hacker News · The Independent 라이브 블로그

우크라이나가 로스토프주 Kamensk-Shakhtinsky 로켓연료 공장을 타격했다. 이 공장은 여러 다연장로켓시스템과 미사일 체계, 공중발사 탄약용 고체 로켓 연료를 생산한다. 우크라이나 군은 작업장 2곳 파괴와 4곳 손상을 주장하며 위성사진을 공개했다.

규모가 컸다. 러시아 당국은 800대가 넘는 드론이 포함됐다고 밝혔고 밤사이 822대를 격추했으며 그중 600대가 수도로 향했다고 발표했다. 러시아가 올해 최대 규모라고 표현한 공격이다.

전략적으로 주목할 것은 두 번째 표적이다. 모스크바주 포돌스크의 Wildberries 창고가 파괴됐다. 러시아판 아마존으로 불리는 온라인 소매업체이고, 타격된 곳은 이 회사 소유 중 가장 큰 시설로 알려졌다. 키이우는 전쟁을 평범한 러시아인에게 체감시킨다는 목표를 공개적으로 밝힌 캠페인을 이어가고 있고, HN에서 Animats가 정리한 집계에 따르면 Wildberries 10대 허브 중 7곳이 이미 타격됐다. 민간 물류 인프라를 표적으로 삼는 전략이 체계적으로 진행되고 있다는 뜻인데, 스레드에서 "논거가 뭐냐, Wildberries가 군수 장비를 창고에 숨기고 있나"라는 반문이 나온 것이 이 전략의 논쟁적 성격을 그대로 보여준다.

러시아 내부 소식이 이 항목에서 가장 드문 자료다. 국책 개발은행 VEB가 수석 이코노미스트 Andrei Klepach를 해임했다. 러시아 최고 거시경제학자 중 한 명인데, 금융포럼에서 한 발언 때문이다. "우리는 뒤처지고 있다. 세계에서 기술 경쟁과 경제 경쟁을 모두 잃고 있다. 중국과 미국뿐 아니라 어떤 면에서는 우크라이나에게도 지고 있다." 그리고 "우리는 이 소모전에서 경쟁을 이기지 못할 것이다. 저쪽이 다 무너질 거라는 환상이 있다. 무너지지 않았고 무너지지 않을 것이다. 우리 비용은 쌓이고 있다." 그는 사회적 위기를 예고했다. 국가기관 고위 인사의 드문 공개 비판이고, 본인도 해임을 확인했다. VEB는 이유를 밝히지 않았다.

같은 날 정치 쪽에서는 대법원이 반전 성향 야블로코당의 총선 참여 금지에 대한 항소를 기각했다. 야블로코는 우크라이나 전쟁 종식을 요구하는 유일한 등록 정당이다. 부의장 Lev Shlosberg는 11년 1개월 징역형을 선고받았고 최후진술에서 무죄를 주장하며 휴전 요구를 반복했다. 전문가 영역과 정치 영역 양쪽에서 반대 의견의 공간이 동시에 닫히고 있다는 그림이다.

몇 가지 확인 상태를 함께 적는다. 이탈리아 국방장관은 콜레페로의 KNDS Ammo Italy 공장 폭발에 러시아 연관 징후가 없다고 밝혔다. 러시아가 주장한 흑해 화물선 2척 타격은 독립 확인이 불가능하다고 원 매체가 명시했다.

파월호와 미드호 동시 사상 최저 - 손실 경로가 셋이다

Hacker News · 원문 미확보, HN 논의 기반

콜로라도강 유역의 두 대형 저수지 파월호와 미드호가 나란히 사상 최저를 기록했다. 원 기사 본문이 확보되지 않아 저수율 퍼센트나 정확한 수위는 이 기록에 없다.

인용된 원인 설명은 이렇다. 이번 겨울 사상 최저 적설량의 직접적 결과이고, 그마저 봄철 기록적 더위로 지워졌다. 녹은 적설이 건조한 여름 동안 콜로라도강 유량의 대부분을 만든다.

기술 독자에게 값진 부분은 적설량과 하천 유량이 선형 관계가 아니라는 물리다. HN 논의에서 손실 경로가 셋으로 정리됐다. 첫째, 열에 승화해 바로 수증기가 되는 몫이 있다. 유타대 연구들에 따르면 폭염 중 적설의 상당 비율이 녹을 기회조차 없이 사라진다. 둘째, 녹은 물이 마른 토양을 먼저 채워야 하천에 도달한다. 이 지역의 바싹 마른 토양이 상당량을 흡수한다. 셋째, 산악 서부의 따뜻하고 건조한 봄은 강한 바람을 동반하는데 그것이 융설 증발과 토양 건조와 식물 증산을 함께 늘린다.

역설적 결과가 하나 있다. 기록적 추위였다면 오히려 물이 더 많았을 것이라는 지적이다. 나중에 빠르게 녹고 토양이 이미 충전돼 있어 하천으로 흘렀을 것이기 때문이다. 온난화의 영향이 "눈이 덜 온다"에 그치지 않고 손실 경로를 여러 개 동시에 키운다는 뜻인데, 기후 리스크 모델링에서 단순 수지 계산이 왜 낙관 편향을 갖는지 보여주는 사례다.

정책 쪽 논점도 뚜렷하다. 스레드에서 반복된 판단은 **"사람이 마실 물이 부족한 게 아니라 사막에서 알팔파를 키우는 농업이 지속 불가능하다"**는 것이다. 반론은 그 조정이 기술 문제가 아니라 수리권과 로비의 문제라는 것이다. 호주 사례를 들며 농업은 정치적으로 신성불가침이라 외국계 수출업체가 소농과 목장주 연합 뒤에 로비스트를 붙일 것이고 주민이 먼저 물 제한을 받게 된다는 지적이 나왔다. 지하수 양수로 돌아가면 대규모 지반침하 문제가 생긴다는 반박도 있었다.

유럽 가정용 배터리 차익거래 - 회수 11년

Hacker News · 개인 블로그

전기요금이 싼 시간에 충전하고 비싼 시간에 쓰는 가정용 배터리의 경제성을 실측한 글이다. 설비는 1,600유로에 5kWh 용량, 3kW 출력이다.

결과가 냉정하다. 투자 회수 기간이 독일 11.1년, 스페인 12.7년이다. 배터리 수명과 비슷하거나 더 길다. 저자 스스로 **"5년 회수가 아니다"**라고 인정했는데, 이 분야 마케팅에서 흔히 도는 수치와 실측이 두 배 이상 벌어진다는 뜻이다.

댓글에서 Terr_가 붙인 관점이 실용적이다. 이 정도 절감액은 세전 연봉의 3% 수준이라, 같은 시간과 자본을 다른 데 쓰는 편이 나을 수 있다는 것이다. 취미로서의 가치와 투자로서의 가치를 구분해야 한다는 지적이다.

다만 개별 가정의 경제성과 계통 전체의 가치는 다르다는 점도 나왔다. 유럽에서 재생에너지 출력 제한으로 버려지는 전력이 40TWh 규모로 전망되는데, 분산 저장이 그 일부를 흡수하면 사회적 편익은 개별 회수 계산에 잡히지 않는다. 그 격차를 메우는 것이 보조금의 역할인데, 현재 설계로는 개인이 그 편익을 회수하지 못한다.

기타 주목할 콘텐츠

교차 분석

1. 오늘의 중심축은 "구조"라는 단어 하나로 모인다. 서로 모르는 사람들이 같은 날 같은 결론에 도달했다. Ryan Dahl은 모델의 거부 성향을 믿지 않고 Postgres 프로토콜 계층에 규칙을 심었고, yaop은 리뷰 에이전트의 서브에이전트 스폰 권한까지 닫았고, Doberman은 하위 설정이 위험도를 낮추지 못하게 raise-only를 걸었고, holdline은 그 가드들이 실제로 막는지를 채점하는 벤치마크를 만들었다. yogthos는 Behavior Trees 논문을 인용해 **"모델을 에이전트 전체가 아니라 결정론적 제어 구조의 리프 노드로 다뤄라"**로 정리했고, 그 결론 문장이 이 흐름 전체의 요약이다. "올바른 구조를 두르면 로컬 모델조차 꽤 복잡한 작업을 유능하게 해낸다." 프롬프트를 잘 쓰는 경쟁에서 실행 경로를 설계하는 경쟁으로 넘어갔다.

2. 에이전트 메모리 논의가 저장에서 폐기로 이동했다. 세 프로젝트가 독립적으로 같은 지점에 닿았다. Dirge는 Markdown 추적이 낡아 오히려 오도한다며 SQLite를 프로젝트 메모리로 삼았고, Engelbart는 Markdown을 유지하되 갱신과 주입을 플러그인이 강제하며 사람이 목표 트리를 검사하게 했고, Facts 프로토콜은 큐레이션 규칙 자체를 표준화하려 한다. Facts의 질문 목록 중 마지막 항목이 핵심이다. "무엇이 조용히 참이기를 그만뒀는가." 여기에 실무 사례가 붙는다. WhatsApp 자동화가 3주간 초록불이었지만 24시간 창 규칙이 바뀐 뒤로 사실상 망가져 있었고, 메모리 실험은 "회상한 뒤 기각한 경우"를 성공으로 세야 한다고 보였다. 셋 다 같은 이야기다. 시스템이 기억하는 것과 지금 참인 것을 구분할 장치가 필요하다.

3. 기본값이 반복해서 범인으로 지목됐다. Qwen 3.8 27B는 기본 추론 강도가 xhigh라 원 하나에 몇 분을 태운다. LM Studio의 기본 컨텍스트 8,192는 그 모델이 생각을 시작하지도 못하게 한다. 컴팩션 발표의 결론은 "기본값으로 압축하지 말라"였고, 프로덕션 도구들이 흔히 쓰는 기본 압축률 38%에서 회수율 손실이 관측됐다. Replit의 Power mode가 최저 추론으로 설정돼 있다는 주장도 같은 형태다. 도구가 강해질수록 그 도구를 어디까지 풀어놓을지에 대한 기본값이 결과를 지배하는데, 지금 그 기본값 대부분이 안전이나 비용이 아니라 데모 인상을 기준으로 잡혀 있다.

4. 측정의 신뢰도가 여러 각도에서 흔들렸다. Terminal Bench 2에서 타임아웃만 늘려 점수가 14~15퍼센트포인트 올랐다. Sparse Attention 논문의 벤치마크를 원하는 대로 만드는 매뉴얼이 내부자에 의해 공개됐다. GPT-5.6 Sol의 비전 평가에서 좌표 포맷만 바꿔 mAP가 15만큼 움직였다. holdline은 원 kappa가 클래스 불균형에서 거짓말한다며 균형 kappa를 쓴다. 로컬 추론 튜닝 기록은 "로드만 되는 것을 256K 지원이라 부르지 않는다"고 못 박았고, SoLo는 같은 말을 **"Loading is the floor, not the claim"**으로 썼다. 여섯 곳이 각자 다른 분야에서 같은 지적을 했다. 숫자를 인용하기 전에 그 숫자가 어떤 조건에서 나왔는지 묻는 것이 지금 가장 값싼 품질 관리다.

5. AI 텍스트를 둘러싼 네 태도가 같은 날 모두 나타났다. 기계로 심고(가짜 싱크탱크의 LLM 포이즈닝), 기계로 판별하고(Claude의 모델 레벨 워터마킹), 사람이 감별하고(일본어의 実務와 帳簿), 아예 거절한다(AI;DR). 그리고 다섯 번째로 회피가 있다(NoToAI.org). 흥미로운 건 서로 어긋난다는 점이다. 워터마킹은 "이 텍스트가 특정 모델을 거쳤는가"를 답하는데, AI;DR을 선언한 사람들이 실제로 묻는 건 **"네가 검토는 했는가"**다. 두 질문의 답이 다를 수 있다. 모델을 거치지 않은 게으른 글도 있고, 모델을 거쳤지만 공들여 다듬은 글도 있다. 책 한 권에 테스트 5,500개를 붙이고 작업 이력을 통째로 공개한 사례가 그 두 번째의 실증이라, 판별 기술보다 공정 공개가 더 실용적인 답일 수 있다.

6. AI 지출이 다른 자원을 밀어내는 그림이 네 층위로 확인됐다. 소비자 하드웨어에서 메모리가 500% 올랐고 2027년 생산능력까지 선점됐다. 자본시장에서 30년물 금리가 19년 만의 최고를 찍었는데 바클레이즈가 AI 관련 발행을 원인 중 하나로 명시했다. 기업 현금흐름에서는 Meta 한 곳이 올해 최대 1,450억 달러를 쓸 수 있다는 추정이 나왔다. 연구비에서는 비AI 데이터베이스 연구자들이 커뮤니티 포럼에 자금 매칭 스레드를 열었다. 마지막 층위가 가장 조용하고 그래서 가장 늦게 드러난다. DuckDB v2.0의 재귀 CTE 40배 가속 같은 성과가 수십 년 조인 알고리즘 연구의 산물인데, 그 연구를 떠받치는 자금이 지금 마르고 있다면 다음 40배는 몇 년 뒤에 오지 않는다.

7. "도메인 전문성 없이는 도구가 소용없다"가 두 분야에서 같은 형태로 나왔다. yogthos는 Clojure를 20년 다뤘기 때문에 LLM으로 컴파일러를 만들 수 있고, 익숙하지 않은 문제였다면 결과가 맞는지 평가할 능력조차 없었을 것이라고 썼다. Gene Inspector의 저자는 7년간 유전학을 독학한 뒤에야 도구를 만들었고 **"대부분을 AI 물결 이전에 손으로 만들었다"**고 밝혔다. Andrew Ng가 Context Advantage라고 부른 것도 결국 같은 이야기다. 실패의 대부분이 "모델이 못한다"가 아니라 "어떤 컨텍스트를 줘야 하는지 모른다"에서 온다는 것이다. 그리고 반대 증거도 같은 날 있었다. 법률 인용 검증 논문에서 모델이 확인하지 않고 확인했다고 지어냈을 때, 그것을 알아챌 수 있는 사람은 그 분야를 아는 사람뿐이다.

8. 인프라의 기본값이 동시에 흔들렸다. GitHub이 멈췄고 상태 페이지가 제때 말하지 않았다. 그 장애가 만든 논의는 대안 선택이 아니라 **"옮길 데가 없다"**였고, 없는 것이 저장소 호스팅이 아니라 소셜 레이어라는 진단이 나왔다. 같은 날 Cursor가 저장소 호스팅을 열었지만 GitHub을 source of truth로 남겼고, Codeberg는 AI 생성 코드 금지로 자기 자리를 좁혔고, Ghostfork는 신뢰 문제를 아키텍처로 풀되 발견성은 반대 방향으로 갔다. Ghostty처럼 저명한 프로젝트조차 물색을 해야 했다는 사실이 공백의 크기를 말한다. 그리고 그 공백을 메우기 어려운 이유가 무료 CI라는 아주 물질적인 것이라는 지적이 붙었다.

9. 자율성의 경계선이 실제 제품 카피에 나타나기 시작했다. OrbitQuote는 **"스스로 사는가? 아니오. 만들고, 당신이 승인한다"**를 랜딩에 적었다. Cronloop은 시크릿을 write-only로 만들어 에이전트가 쓸 수는 있어도 유출할 수 없게 했다. yaop은 리뷰 에이전트에게 편집 권한을 주지 않았다. 반면 같은 날 Wiz의 레드팀 에이전트는 워크플로 결함을 파고들며 Bash 구문 오류를 스스로 고쳐 공격을 이어갔고, 그 PR을 리뷰한 Copilot은 문제없다고 판정했다. 자율성이 방어 쪽에서는 제약으로 관리되는데 공격 쪽에서는 그대로 작동한다는 비대칭이 오늘 가장 불편한 관찰이다.

10. 그리고 사람 쪽 이야기가 기술 뉴스를 이겼다. 그날 커뮤니티에서 가장 높은 점수를 받은 글은 새 모델도 새 도구도 아니라 "나는 가족보다 컴퓨터와 더 오래 있었다"는 자각이었다. 1976년 가설을 다룬 2008년 서평이 LLM 때문에 다시 읽혔고, 거기 달린 댓글이 남긴 표현이 **"사고하는 자가 없는 사고"**였다. 신입 채용에서는 AI가 인턴 업무를 가져가면서 "배우면서 기여하는" 단계 자체가 사라졌다는 진단이 나왔고, 보조금 자동 작성 회사의 창업자는 주 고객이 개인 창업자가 아니라 전문 대필가라는 사실과 **"AI가 특권을 영구화할 수 있다"**는 인정을 함께 내놨다. 도구 이야기가 임계에 도달하면 늘 이쪽으로 넘어온다.

Powered by skim

aidenahn.com — terminal
visitor@aidenahn.com:~ $ banner
█████╗ ██╗██████╗ ███████╗███╗ ██╗ █████╗ ██╗ ██╗███╗ ██╗ ██████╗ ██████╗ ███╗ ███╗ ██╔══██╗██║██╔══██╗██╔════╝████╗ ██║██╔══██╗██║ ██║████╗ ██║ ██╔════╝██╔═══██╗████╗ ████║ ███████║██║██║ ██║█████╗ ██╔██╗ ██║███████║███████║██╔██╗ ██║ ██║ ██║ ██║██╔████╔██║ ██╔══██║██║██║ ██║██╔══╝ ██║╚██╗██║██╔══██║██╔══██║██║╚██╗██║ ██║ ██║ ██║██║╚██╔╝██║ ██║ ██║██║██████╔╝███████╗██║ ╚████║██║ ██║██║ ██║██║ ╚████║██╗╚██████╗╚██████╔╝██║ ╚═╝ ██║ ╚═╝ ╚═╝╚═╝╚═════╝ ╚══════╝╚═╝ ╚═══╝╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═══╝╚═╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝ Welcome to aidenahn.com Type 'help' for available commands
visitor@aidenahn.com:~/digest $ 
! for AI mode