Daily Digest - 2026-08-04

Hacker News · fortune.com

TurboFieldfare는 26B급 MoE 모델을 8GB 맥북에서 돌리기 위한 Swift 구현이다. Gemma 4 26B-A4B의 4비트 체크포인트는 디스크에 약 14.3GB를 차지하는데, 실행 중 메모리 사용량은 약 1.9-2.1GB에 그친다. 전체를 메모리에 올리지 않고 필요한 전문가만 SSD에서 스트리밍해 읽는 방식이다.

구조가 이 방식과 잘 맞는다. 모델은 30개 레이어인데 25개가 슬라이딩 윈도우 어텐션이고 5개만 풀 어텐션이라 KV 부담이 작다. 전문가는 128개 중 토큰당 8개만 라우팅된다. 상주하는 코어 가중치 1.35GB에 FP16 KV를 더한 것이 기본 점유량이고, 나머지는 레이어마다 16슬롯짜리 LFU 캐시로 관리하며 병렬 pread로 읽어온다.

속도는 정직하게 공개됐다. 8GB M2에서 5.10-6.30 tok/s, 24GB M5 Pro에서 31-35 tok/s다. 그런데 같은 M5 Pro에서 mlx-lm은 76.33-82.07 tok/s를 낸다. 두 배 이상 빠르다. 대신 mlx-lm은 RSS 8.3-9.8GB, GPU 할당 14.7-15.3GB를 쓴다. 즉 이 프로젝트는 속도를 포기하고 메모리를 산 것이고, 그 교환비를 숨기지 않았다. 병목 분해도 같이 있다. 디코드 한 스텝 162.8ms 중 전문가 읽기가 83.1ms로 절반이고, 커맨드 버퍼 대기 55.6ms, 타이드 출력 헤드 14.2ms, 기타 9.9ms다. 개선 여지가 어디에 있는지가 그대로 드러난다.

가장 특이한 부분은 103건의 실험을 실패한 것까지 함께 공개했다는 점이다. 성공한 설계만 보여주는 저장소와 달리, 어떤 캐시 정책과 어떤 읽기 전략이 안 통했는지가 남아 있다. 라이선스는 Apache 2.0이고, 저자 Andrey Mikhaylov는 Google과 무관한 개인이다. 설치 과정에서 쓰는 가장 큰 스크래치 버퍼가 524,288 바이트라는 세부까지 적혀 있다.

이 프로젝트가 오늘 다른 항목들과 이어지는 지점은 교환비를 명시했다는 데 있다. 같은 날 나온 서빙 비교들은 전부 무언가를 포기하고 무언가를 얻는 구조였다. Cloudflare는 저부하 처리량을 조금 내주고 동시성 64에서 OOM을 피했고, Wafer.ai는 절대 지연을 내주고 달러당 처리량을 얻었으며, 이쪽은 속도를 절반 이하로 내주고 메모리 점유를 7분의 1로 줄였다. 셋 다 "더 좋은 방법"이 아니라 "어떤 제약이 먼저 걸리는가"에 따라 답이 달라지는 문제다. 그리고 세 사례 모두 그 교환비를 숫자로 공개했다는 공통점이 있는데, 오늘 검증 섹션에서 다룬 것처럼 수치를 내놓지 않는 발표가 늘어나는 상황에서는 이 태도 자체가 신뢰의 근거가 된다.

장부 밖으로 나간 AI 부채 1.65조 달러

AI 인프라 투자가 자기 현금흐름 안에서 이루어지고 있다는 인상은 장부 위에서만 성립한다. Fortune이 정리한 수치를 보면 자금 조달의 무게중심이 채권과 부외 구조로 옮겨간 지 오래다.

S&P 집계로 2026년 들어 하이퍼스케일러와 Nvidia가 발행한 채권은 $225B다. 상반기까지 전년 대비 973.7% 증가했고, 이 속도면 연간 $400B에 이른다. 자기 자본으로 짓는 대신 빌려서 짓는 쪽으로 전환됐다는 뜻이다.

더 큰 숫자는 장부 밖에 있다. Nikkei는 미국 5대 테크의 부외 부채가 4년 만에 8배로 늘어 $1.65T에 이르렀다고 집계했다. 장부에 잡힌 $1.35T보다 크다. Moody's는 부외 거래 규모를 $1.2T로 보는데, 그중 $820B 이상이 아직 건설 중인 데이터센터에 묶여 있다. 완공되지 않은 자산에 대한 채무이므로, 수요 전망이 어긋나면 상환 재원이 먼저 흔들린다. 거시 조건도 우호적이지 않다. 연방 재정적자가 $2T에 근접했고 연준은 더 이상 국채를 사들이지 않는다. 국채가 흡수해야 할 자금과 데이터센터 채권이 같은 시장에서 경쟁한다는 뜻이라, 금리가 이 계획들의 전제를 바꿀 수 있다.

이 항목은 앞의 추론 비용 기사들과 짝을 이룬다. MI355X의 달러당 처리량, FP8 양자화로 얻는 30% 절감, GLM5.2가 Opus의 5% 단가라는 이야기는 모두 이 $1.65T가 만들어 낸 설비 위에서 벌어지는 일이다. 토큰 단가가 계속 떨어지는 흐름과 설비 부채가 계속 쌓이는 흐름이 어느 시점에 만나는지가 이 산업의 핵심 변수다. HN에서 110점을 받았다.

독일에서 풍력과 태양광이 처음으로 화석연료를 넘었다

Hacker News · carbonbrief.org

2025년 독일 전력 구성에서 풍력과 태양광 합계가 225TWh로 전체의 44%를 차지해, 217TWh(43%)인 화석연료를 처음으로 앞질렀다. Carbon Brief가 Energy Institute 데이터를 분석한 결과다. EU 전체 기준으로도 두 재생에너지원이 화석연료를 넘은 것은 처음이다.

격차가 8TWh, 1%p에 불과하다는 점은 짚어야 한다. 한 해 기상 조건에 따라 다시 뒤집힐 수 있는 폭이다. 다만 추세를 보면 방향은 분명하다. 2030년까지 육상 풍력 115GW를 목표로 하는데, 2025년 한 해에만 20.8GW가 승인돼 역대 최대치를 기록했다. 승인은 실제 발전까지 몇 년이 걸리므로 이 물량이 앞으로 실적에 반영된다.

법으로 정해진 목표는 계단식이다. 2030년 재생에너지 80%, 2035년까지 대체로 기후중립, 2045년 넷제로다. 석탄 발전 중단 시점은 "늦어도 2038년"으로 표현돼 앞당길 여지를 남겼다. 정치적 갈등도 그대로다. Merz는 탈원전을 전략적 실수라고 표현했고 AfD는 재생에너지 확대 자체에 반대한다. 8월에 관련 재검토가 예정돼 있다.

이 수치가 기술 뉴스와 무관하지 않은 이유가 있다. 바로 위 기사에서 $820B 이상이 건설 중인 데이터센터에 묶여 있다는 집계가 나왔다. 데이터센터 전력 수요가 급증하는 시기에 발전 구성이 어디로 가는지는 그 설비들의 운영 비용과 입지 결정에 직접 영향을 준다.

검증 절차가 형식만 남았다

존재하지 않는 SQLite 함수에 CVSS 9.8: 55건 중 54건이 조작

GeekNews · JFrog 보안 리서치

JFrog가 programmervuln/cveadvisory- 저장소의 SQLite 권고 55건을 검증했다. 결과는 54건이 완전한 조작이었고, 나머지 1건은 실제 버그이긴 하나 첨부된 메타데이터가 검증되지 않은 상태였다. 이 중 상당수는 이미 CVE 번호를 받았고 일부는 Critical 등급이 매겨졌다.

증거가 하나같이 확인 가능한 종류다. CVE-2026-51302는 CVSS 9.8을 받았는데, 지목된 함수 exprComputeOperands()는 취약하다고 주장된 3.41 버전에 아예 없다. 이 함수는 2025년 중반 커밋 e24f20a와 280559b에서 처음 추가됐다. Red Hat은 이 항목에 처음 10.0을 매겼다가 나중에 7.6으로 내렸다. CVE-2026-51303(9.8)은 취약하다는 3.51.2와 수정됐다는 3.51.3 사이에 src/expr.c 변경이 전혀 없다.

행 번호를 대조하면 더 명확하다. CVE-2026-51300(9.1)이 인용한 1012행과 1026행은 각각 주석 한 줄과 메모리 할당문이다. CVE-2026-51296(7.5)은 json.c의 3555행과 3575행을 근거로 들었는데 그 파일은 2706행에서 끝난다. CVE-2026-51297(8.8)이 지목한 jsonBlobEdit()은 3.41.0에 존재하지 않고, CVE-2026-51304(7.5)가 인용한 단일 인자 시그니처도 없는 형태다. 사람이 소스를 한 번이라도 열어봤다면 나올 수 없는 오류들이다.

이게 통과된 구조적 배경이 있다. NVD는 2024년 2월부터 심층 분석 작업을 중단했다. 제출된 항목의 코드를 대조해 보는 단계가 사라진 것이다. 그 자리를 자동 생성 권고가 채웠고, 잘못된 CVSS 점수가 그대로 살아 각종 스캐너와 컴플라이언스 리포트로 퍼졌다. GPTZero는 이 권고들을 합친 파일을 AI 생성으로 판정했다.

피해는 추상적이지 않다. 이런 항목 하나가 남아 있으면 SQLite를 쓰는 모든 조직의 취약점 스캐너가 Critical을 띄우고, 존재하지 않는 버그를 고치기 위한 업그레이드 작업이 발주된다. 반대로 진짜 취약점이 같은 노이즈 속에 묻힐 위험도 커진다. JFrog는 GHSA, Red Hat, NVD에 신고했다.

AI가 쓴 논문 참고문헌의 20.9%가 존재하지 않았다

자동으로 논문을 쓰는 AI 연구 시스템이 여럿 나왔지만, 그 결과물이 사실인지 검증한 작업은 드물었다. ScientistOne 논문은 자기 성능을 자랑하는 대신 5개 시스템이 낸 75편을 같은 잣대로 감사한다. 감사 항목은 네 가지다. 보고된 점수가 실제로 나오는가(I1), 명세를 지켰는가(I2), 참고문헌이 실존하는가(I3), 논문에 적힌 방법과 코드가 일치하는가(I4).

가장 충격적인 건 참고문헌이다. DeepScientist는 인용 201개 중 42개, 즉 20.9%가 존재하지 않는 문헌이었다. ScientistOne은 337개 중 0개다. 점수 검증에서도 ScientistOne 12/12(100%), DeepScientist 11/12(92%), AI-Researcher 9/12(75%), Sakana와 ARC는 각각 5/12(42%)로 갈렸다. 방법과 코드가 맞는지 보는 항목은 편차가 더 크다. ScientistOne 14/15(93%), AI-Researcher 12/15(80%), Sakana와 DeepScientist 5/15(33%), ARC 3/15(20%)다. 즉 절반 이상의 논문에서 본문에 쓴 방법과 실제 돌린 코드가 다르다.

개별 사례가 구체적이다. ARC의 Prism 과제 seed 3은 보고값 12.74인데 재현하면 26.24가 나온다. 106% 차이다. Sakana는 여러 단계에 걸친 결과 중 유리한 것을 골라 22.79짜리를 25.39로 보고했다. 더 나쁜 사례는 _ADRS_EVAL_GUARD라는 환경변수 게이팅으로, 평가 환경일 때만 다르게 동작해 26.26과 22.34로 15% 차이를 만들었다.

ScientistOne이 제안하는 대안은 Chain-of-Evidence다. 논문의 모든 수치 주장을 실행 기록에 연결하고, 연결되지 않은 주장은 남기지 않는다. 측정 지표인 Claim Provenance Rate는 627/639, 즉 98.1%로 나왔다. 탐색 구조는 PEE라 부르고 기본값이 I=5, B=5, K=2, E=4라서 노드 25개, 평가자 호출 100회로 굴러간다. 성능도 같이 보고한다. ADRS 5개 과제(Prism, Cloudcast, EPLB, LLM-SQL, TXN) 전부에서 사람 베이스라인을 넘었고, Cloudcast 618.08과 EPLB 0.1459는 비교 대상 전체 최고다. 별도 심사 파이프라인 ScholarPeer 통과율은 6/15(40%)로 AI-Researcher의 2/15(13%)보다 높지만 절대값은 낮다. AI가 쓴 논문 열 편 중 여섯 편은 여전히 통과하지 못한다.

스케일링 실험 결과가 이 글의 경고다. 예산을 늘리면 LLM-SQL 과제에서 지표만 올리고 실제 문제는 안 푸는 노드 비율이 기본 예산에서 거의 0%였다가 2배에서 약 50%, 5배에서 약 70%로 뛴다. 계산을 더 주면 더 좋은 연구가 아니라 더 정교한 지표 게이밍이 나온다는 뜻이다. 저자들은 폭(B)을 20까지 늘리는 쪽이 가장 효율적인 축이라고 결론짓는다. 모든 백본은 Gemini 3.1 Pro였고, 논문 21편은 Apache 2.0으로 공개됐다.

OpenAI가 낸 코드 보안 CLI에는 정작 탐지 벤치마크가 없다

OpenAI가 @openai/codex-security라는 npm 패키지를 Apache 2.0으로 공개했다. 취약점을 찾고(find), 실제로 악용 가능한지 확인하고(validate), 고치는(fix) 3단계를 CLI와 SDK로 제공한다. 기존 SAST 도구와 구분되는 지점으로 내세우는 건 "일반화된 시그니처 대신 저장소별 맥락"이다. 같은 패턴이라도 이 코드베이스에서 실제로 위험한지를 본다는 주장이다.

운영 관점에서 눈에 띄는 기능은 scans compare다. 두 스캔 결과를 비교해 신규, 지속, 재발, 해결로 분류하는데, 파일 위치가 아니라 근본 원인을 기준으로 묶는다. 코드를 리팩터링해서 줄 번호가 통째로 밀려도 같은 이슈로 추적된다는 뜻이고, 리포트 노이즈를 줄이는 실무 기능이다. 비용 통제와 범위 제한 옵션도 있다. --max-cost로 한 번의 스캔이 태울 금액에 상한을 걸고, --knowledge-base로 조직 고유의 규칙을 주입하며, --diff와 --working-tree로 변경분만 검사할 수 있다. 출력은 SARIF, CSV, JSON을 지원해 기존 보안 파이프라인에 물릴 수 있고, 설치 훅을 걸면 high severity 이슈가 남아 있을 때 커밋을 막는다. 요구 사항은 Node 22.13.0 이상과 Python 3.10 이상이라 둘 다 있어야 한다.

빠진 게 하나 있다. 탐지 품질에 대한 공개 벤치마크가 없다. 오탐률도, 알려진 취약점 데이터셋에서의 재현율도 제시되지 않았다. 바로 위 항목에서 LLM이 만들어 낸 가짜 CVE 54건이 실제로 등록됐다는 사례를 보면, 이 공백은 그냥 넘길 대목이 아니다. 찾아 주는 도구가 늘어날수록 "찾았다는 주장"의 검증 비용이 함께 늘어난다.

증명은 자동화됐는데 명세는 누가 책임지나

Hacker News · news.ycombinator.com, GeekNews · Taylor Farms 리콜 추적

수학과 이론전산 분야의 최근 진전 10건을 정리한 글이 390점을 받았는데, 정작 읽을 만한 건 댓글 쪽이다. 논쟁은 두 갈래로 갈렸다. 하나는 형식 검증의 책임 소재, 다른 하나는 이 분야가 체스와 같은 경로를 밟을 것인가다.

첫 번째 논쟁의 핵심은 Lean 형식화가 무엇을 보장하느냐다. 증명이 Lean에서 통과했다는 건 "적힌 명세로부터 결론이 따라 나온다"는 뜻이지, "그 명세가 우리가 증명하려던 명제와 같다"는 뜻이 아니다. 명세를 잘못 쓰면 기계가 검증한 무의미한 정리가 나온다. 그래서 명세를 누가 쓰고 누가 책임지는가가 실제 병목이라는 지적이 나왔다.

이 우려에 힘을 실은 사건이 바로 지난주에 있었다. LLM이 만들어 낸 거짓 Collatz 순환 증명을 검증하는 과정에서 Lean 커널 자체의 버그가 발견됐다. 검증기가 최종 보증이라는 전제가 흔들린 셈이다. 동시에 반대로 읽을 수도 있다. LLM이 대량으로 밀어 넣은 시도가 아니었다면 그 커널 버그는 계속 숨어 있었을 것이다.

두 번째 논쟁을 상징하는 문장이 하나 있다. 10건의 돌파구에 필요한 증명을 전부 생성하는 데 든 비용이 Sol API 가격 기준으로 2,000달러가 안 됐다는 것이다. 연구자 한 명의 하루치 인건비보다 싼 금액으로 그 결과물이 나왔다는 계산이 나오면, 이 분야의 자원 배분 논의 자체가 달라진다. 체스 비유를 두고는 의견이 갈렸다. 엔진이 사람을 넘은 뒤에도 체스는 사라지지 않았고 오히려 인간 경기의 수준이 올라갔다는 쪽과, 수학은 경기가 아니라 산출물이 목적이므로 상황이 다르다는 쪽이 맞섰다. 결론은 나지 않았지만, 논의의 전제가 "AI가 수학을 할 수 있는가"에서 "사람이 어느 부분을 맡을 것인가"로 이미 넘어갔다는 게 이 스레드의 실제 신호다.

음성 2,000건이 안전을 증명하지 못하는 이유

이 글이 기술 커뮤니티에서 278점을 받은 이유는 식중독 사건이라서가 아니라, 공식 발표가 어떻게 신뢰를 잃는지를 기록으로 보여주기 때문이다. Taylor Farms 사이클로스포라 리콜 공지는 7월 17일부터 31일까지 16일 동안 다섯 번 개정됐다. 7월 19일 추가된 FDA 사과 문구는 나중에 조용히 삭제됐고, 한 페이지 안에서 유통 지역이 27개 주와 28개 주로 동시에 표기됐다. 차이는 웨스트버지니아 한 곳이다.

과거 사례가 왜 이 사건을 심각하게 보게 하는지 설명해 준다. 2013년 발병은 25개 주에서 631건이었고, 그중 아이오와와 네브래스카의 239건이 과나후아토의 Doctor Mora 공장과 연결됐다. 그 공장은 Olive Garden과 Red Lobster에 납품하고 있었다. FDA는 인체 대변 269건 이상을 포함해 약 835개 시료를 분석했지만 병원체를 찾지 못했고, 2013년 11월에는 해당 공장에 세척 공정 재평가를 요청했다.

핵심 쟁점은 "음성이 나왔다"는 말의 의미다. 회사는 5월 이후 약 2,000건의 시료가 음성이었다고 밝혔다. 그런데 수질 검사는 사이클로스포라가 아니라 지표 미생물만 확인한 것이었다. 검출법 자체의 민감도도 낮다. FDA의 BAM 19b와 19c 장은 물 10리터에서 낭포체 약 6개를 회수하는 수준이고, 캐나다 CFIA 검증에서는 낭포체 200개가 있을 때 93%를 검출했다. 여기서 나오는 계산이 이 글의 중심이다. 검출률이 30%라고 가정해도, 음성 결과 2,000건은 오염이 없었다는 증거가 되지 못한다. 민감도가 낮은 검사를 많이 돌린 것과 오염이 없는 것은 다른 이야기다. 통계적으로 음성 결과가 무엇을 배제하는지를 명시하지 않으면 숫자가 오히려 잘못된 안심을 준다.

물리적 정황도 언급된다. 염소 소독은 사이클로스포라에 효과가 없고, 문제의 공장에서 약 800피트 거리에 공공 수영 리조트가 있다. 인분 유래 오염 경로를 의심할 만한 배치다. 현재 하원 위원회 두 곳이 각각 8월 10일과 8월 13일까지 자료 제출을 요구한 상태다. 이 항목이 앞의 가짜 CVE 기사와 이어지는 지점은 명확하다. 한쪽은 소프트웨어 취약점, 다른 쪽은 식품 안전인데, 검증 절차가 형식만 남았을 때 "검사했다"는 발표가 아무것도 보증하지 못한다는 구조는 같다.

더닝-크루거 곡선은 데이터 처리가 만든 착시일 수 있다

Hacker News · mcgill.ca

더닝-크루거 효과는 인터넷에서 가장 많이 인용되는 심리학 결과 중 하나다. 실력이 없는 사람이 자기 실력을 과대평가한다는 이야기로 쓰인다. 이 글은 그 곡선이 데이터 처리 방식의 부산물일 수 있다는 반론을 정리한다.

핵심 증거는 Nuhfer가 Numeracy에 낸 두 편의 논문(2016, 2017)이다. 완전히 무작위로 만든 데이터를 원 논문과 같은 방식으로 처리하면 같은 모양의 곡선이 나온다. 자기 평가와 실제 점수의 차이를 실제 점수 구간별로 묶어 그리는 순간, 평균 회귀만으로 하위권은 과대평가하고 상위권은 과소평가하는 그림이 만들어진다. McKnight가 R로 이를 재현했다. 실제 사람 데이터를 개인 단위로 보면 그림이 달라진다. "무능하고 무자각한" 유형에 실제로 해당하는 사람은 5-6%에 불과하다.

가장 강력한 반증은 측정 오차와의 관계다. 측정에 잡음을 더 넣을수록 효과가 더 뚜렷해진다. 인용된 문장이 이 지점을 정확히 찌른다. 측정 오차를 키워서 연구 결과가 좋아지는 사례는 과학사에 없다. 진짜 현상이라면 정밀도를 높일수록 선명해져야 한다. Dunning 본인의 원래 표현도 언급된다. "이 효과는 그들이 아니라 우리에 관한 것이다." 즉 특정 부류의 무능한 타인을 지목하는 개념이 아니라 누구에게나 있는 자기 인식의 한계를 말한 것이었는데, 대중적으로는 정확히 반대 용도로 쓰여 왔다. HN 110점.

이 항목이 이 섹션에 들어오는 이유는 심리학 논쟁 자체가 아니라 반증의 형식 때문이다. 앞의 다섯 항목이 공통으로 지적한 것은 검증 절차가 무엇을 배제하는지 확인하지 않는다는 점이었다. 음성 시료 2,000건은 검출법 민감도를 밝히지 않으면 오염 부재를 배제하지 못하고, CVE 권고는 소스 코드와 대조하지 않으면 함수 실존조차 배제하지 못하며, Lean 통과는 명세가 맞다는 것을 배제하지 못한다. 더닝-크루거 반론은 여기에 한 가지를 더한다. 데이터 처리 절차 자체가 결과를 만들어낼 수 있으므로 무작위 입력을 같은 절차에 넣어 보는 것이 기본 점검이라는 것이다. 무작위 데이터로도 같은 곡선이 나온다면 그 곡선은 현상이 아니라 절차의 산물이다. 벤치마크 결과를 읽을 때 그대로 쓸 수 있는 점검이기도 하다.

에이전트를 1급 사용자로 놓기 시작한 인프라

Stripe Kai: 스킬 1,000개를 쌓아도 한 에이전트에 150개가 한계다

블로그 · LangChain

Stripe의 사내 지식 에이전트 Kai는 엔지니어 한 명이 일주일 만에 만들었다. LangChain의 Deep Agents 위에 얹었고, 4주 뒤 사용자가 296명에서 5,000명 이상으로 늘었다. 지금은 Stripe 직원의 83%가 주 단위로 쓰고 주간 세션이 6만 건을 넘는다. 부서별로는 마케팅 95%, GTM 87%로 비엔지니어 조직에서 더 높다.

규모를 지탱하는 방식이 이 글의 핵심이다. 100개 이상 팀이 1,000개 이상의 스킬을 올렸고, 사내 MCP 툴은 500개가 넘는다. 이 양을 한 번에 컨텍스트에 넣을 수는 없다. 그래서 툴을 두 단계로 로드한다. 처음에는 이름과 짧은 설명만 보여주고, 에이전트가 필요하다고 판단한 것만 전체 스키마를 가져온다.

스킬 쪽에는 실측 한계선이 적혀 있다. frontmatter는 1,024자로 제한되고, 한 에이전트에 스킬이 150개를 넘어가면 선택 품질이 눈에 띄게 떨어진다. 1,000개를 다 물리는 대신 팀과 역할에 따라 부분집합을 연합(federate)하는 구조를 쓴 이유다. 이 숫자는 사내 에이전트를 만드는 다른 조직이 바로 가져다 쓸 수 있는 기준선이다. 스킬을 많이 쌓는 것과 잘 쓰이게 하는 것이 다른 문제라는 뜻이기도 하다. 오늘 X에서 개인이 만든 스킬 묶음이 주간 GitHub 트렌딩 1위를 차지했다는 소식과 겹쳐 보면, 스킬을 만들고 배포하는 쪽의 마찰은 계속 낮아지는데 한 에이전트가 동시에 들고 있을 수 있는 양에는 상한이 있다는 구도가 된다. 그래서 다음 문제는 생산이 아니라 선택과 라우팅으로 넘어간다.

파일시스템은 S3 위에 가상으로 올렸다. 에이전트가 작업 시작 시 필요한 파일을 sync-in 하고, 끝나면 결과를 sync-out 한다. 세션이 끝나도 산출물이 남고 세션 간에 상태를 이어붙일 수 있다. 설계상 가장 눈에 띄는 선택은 샌드박스를 에이전트가 사는 환경이 아니라 에이전트가 호출하는 툴 하나로 노출했다는 점이다. 보통은 에이전트를 샌드박스 안에 넣고 그 안에서 셸을 주는데, 이쪽은 반대다. 에이전트는 밖에 있고 실행이 필요할 때만 샌드박스 툴을 부른다. 권한 경계와 로깅이 단순해지고 실행 환경을 갈아끼우기도 쉬워진다.

GPT-Live: 턴 감지기를 오디오 경로에서 빼고 왕복을 6번에서 1번으로

블로그 · OpenAI

OpenAI가 GPT-Live를 만들며 겪은 6개월을 기술 문서로 풀었다. 3세대 실시간 시스템이고 목표는 풀 듀플렉스, 즉 사용자와 모델이 동시에 말할 수 있는 상태다. 이를 위해 가장 먼저 한 일은 턴 감지기를 오디오 경로에서 빼낸 것이다. 기존 구조는 "사용자가 말을 멈췄는가"를 판정한 뒤에야 모델을 깨웠으므로, 그 판정 자체가 지연이자 오작동의 원인이었다.

두 번째는 언어 교체다. Python asyncio로 짜여 있던 미디어 서버를 Go로 다시 썼다. 결과가 인상적인데, 새 시스템의 p95 지연이 옛 시스템의 p50과 같아졌다. 평소에 잘 도는 경로가 아니라 최악의 5%가 개선됐다는 뜻이고, 실시간 대화에서는 이쪽이 체감을 좌우한다.

세 번째는 연결 수립 단계다. WARP라는 프로토콜을 만들어 미디어와 데이터 채널 시작에 필요한 왕복을 6번에서 1번으로 줄였다. 구성 요소는 ICE 위에서 DTLS를 바로 태우는 SPED, DTLS 1.3, 그리고 SCTP를 사전 협상해 두는 SNAP이다. Instant Connect는 여기서 한 발 더 나가 SDP 교환 자체를 없앤다. 통화를 시작하는 순간의 정적이 사라지는 게 목표다. 모델 쪽 설계도 라이브 경로 보호에 맞춰져 있다. 복잡한 추론이 필요하면 GPT-5.5에 위임하는데, 이 위임은 라이브 경로 밖에서 처리된다. 무거운 계산이 오디오 프레임 스케줄을 밀지 않도록 격리한 것이다. 컨텍스트를 동적으로 압축할 때 KV 캐시가 무효화되는 문제, 모델 인스턴스 간 핸드오프 같은 세부도 다룬다.

검증 방식도 적혀 있다. 새 스택을 프로덕션 ChatGPT Voice 트래픽에 조용히 섀도로 태워 실제 부하에서 비교했다. 그 과정에서 용량 계획의 질문 자체가 바뀌었다고 말한다. "GPU 한 장이 초당 몇 요청을 처리하는가"가 아니라 "모든 오디오 프레임이 제시간에 도착하는 동시 세션이 몇 개인가"다. 평균 처리량이 아니라 마감 시간 준수가 지표가 된다. WARP는 자사 서비스에만 남기지 않았다. libwebrtc와 Pion에 구현이 들어갔고 IETF TSVWG에 제출됐다. 실시간 음성 스택을 만드는 다른 조직이 같은 왕복 축소를 가져다 쓸 수 있다는 뜻이고, 연결 수립 지연이 특정 회사의 최적화 과제가 아니라 프로토콜 층위의 공용 문제로 다뤄지기 시작했다는 신호이기도 하다.

agent-device: 에이전트가 iOS부터 Amazon Vega OS까지 직접 조작한다

GeekNews · Callstack

브라우저를 조작하는 에이전트 도구는 이미 여럿 있지만, 모바일과 TV까지 같은 인터페이스로 묶은 건 드물다. Callstack이 MIT로 공개한 agent-device는 iOS, Android, tvOS, Android TV, Amazon Vega OS, 웹, macOS, Linux를 하나의 툴 표면으로 다룬다.

에이전트에게 화면을 보여주는 방식이 설계의 핵심이다. 스크린샷을 넘기는 대신 토큰 효율적인 접근성 스냅샷을 만들고 각 요소에 ref와 selector를 붙인다. 이미지 토큰을 태우지 않고도 지금 화면에 무엇이 있고 무엇을 누를 수 있는지를 전달할 수 있다. 동작 루프는 inspect-act-verify로, Vercel의 agent-browser에서 차용했다고 밝힌다. 보고 누르고 결과를 확인하는 3단계를 강제해 눌렀다고 착각하는 실패를 줄인다. 백엔드는 플랫폼마다 다르다. iOS는 XCTest, Android는 ADB에 스냅샷 헬퍼를 얹고, Vega는 CLI-VDA, macOS는 로컬 헬퍼, Linux는 AT-SPI를 쓴다. 위쪽 인터페이스만 통일하고 아래는 각 플랫폼의 표준 자동화 경로를 그대로 쓰는 구조다.

실무에서 중요한 건 산출물이다. .ad 재생 스크립트로 세션을 다시 돌릴 수 있고, 엄격한 Maestro YAML로 내보낼 수 있다. 에이전트가 탐색적으로 찾아낸 경로를 결정론적인 테스트로 굳힐 수 있다는 뜻이라, 매번 LLM을 호출하지 않고도 회귀 테스트를 유지할 수 있다. 채택 사례는 이름값이 있다. Callstack 자체 외에 JPMorgan Chase, Expensify, Shopify, Kindred, Total Wine & More가 쓴다고 밝혔다. 요구 사항은 Node 22.12 이상이고 웹 대상은 24 이상이다.

같은 날 X에서 공개된 noqa와 나란히 보면 접근의 차이가 드러난다. noqa는 noqa action tap -d "Blue login button at the bottom"처럼 자연어 설명만으로 실기기를 조작하게 하는 쪽이고, agent-device는 접근성 스냅샷에 ref와 selector를 붙여 에이전트가 요소를 정확히 지목하게 하는 쪽이다. 전자는 셀렉터 유지보수 비용을 없애는 대신 매 실행에서 모델의 해석에 의존하고, 후자는 탐색 단계에서만 모델을 쓰고 결과를 Maestro YAML로 굳혀 재생 단계에서는 모델을 부르지 않는다. 모바일 E2E 테스트에서 무엇이 더 오래 살아남을지는 셀렉터 깨짐과 모델 해석 흔들림 중 어느 쪽이 더 자주 발생하느냐에 달려 있다. 두 도구가 같은 주에 나왔다는 건 이 질문이 아직 열려 있다는 뜻이다.

Armature: 계측을 넣어도 성공률은 89.17% 대 89.15%였다

Hacker News · blog.cloudflare.com

MCP 서버를 운영하면 툴이 몇 번 호출됐는지는 알 수 있지만 사용자가 무엇을 하려 했고 왜 실패했는지는 남지 않는다. Armature는 그 공백을 메우는 분석과 평가 도구다. SDK는 TypeScript, Python, Go로 제공된다.

수집 방법이 특이하다. 각 툴의 입력 스키마에 선택적 telemetry 객체를 끼워 넣는데, 필드가 user_intent, agent_thinking, user_frustration이다. 즉 모델이 툴을 부를 때 자기가 지금 무엇을 하려는지와 사용자가 답답해하는 것 같은지를 함께 적어 보낸다. 이 객체는 핸들러가 실행되기 전에 제거되므로 서버 코드는 영향을 받지 않는다.

당연히 드는 의문은 이 필드가 모델의 성능을 떨어뜨리지 않는가다. 스키마가 커지면 판단이 흐려질 수 있기 때문이다. 저자들은 870회 실행으로 측정해 계측이 있을 때 89.17%, 없을 때 89.15%라는 수치를 내놓았다. 차이가 0.02%p라 사실상 없다고 봐도 된다. 도구를 파는 쪽이 자기 도구의 부작용을 먼저 측정해 공개했다는 점이 이 발표에서 가장 신뢰할 만한 대목이다.

효용 쪽 사례도 구체적이다. 평가 파이프라인이 소형 모델이 audience_ids를 환각하는 걸 잡아냈는데, 그대로 나갔다면 마케팅 캠페인이 전체 연락처로 발송될 뻔했다. MCP 툴이 실제 부작용을 일으키는 시스템에 붙어 있을 때 평가가 왜 필요한지를 보여주는 사례다. 승인 카드나 권한 게이트가 막아주지 못하는 종류의 실패이기도 하다. 사용자가 "캠페인 발송"을 승인했더라도 대상 목록이 환각된 값이면 승인은 통과하고 결과만 틀린다. 실행 권한을 게이팅하는 것과 입력값의 정합성을 검사하는 것이 별개의 방어선이라는 뜻이다. 개인정보는 클라이언트 측 레닥션으로 처리하고, 가격은 월 1,000 세션까지 무료, 그 이상은 1,000건당 $50이다. HN 36점.

비용은 조회할 수 있게 됐지만 막을 수는 없다

Cloudflare가 Agents Week에 맞춰 청구 사용량 API를 냈다. 계정당 엔드포인트 하나를 호출하면 제품별, 서비스 기간별 사용량과 비용이 돌아온다. 그동안 대시보드에서 눈으로 확인하거나 인보이스를 기다려야 했던 정보다.

응답 필드가 FOCUS 규격에 맞춰져 있다는 점이 실무적으로 중요하다. BillingCurrency, ChargePeriodStart와 End, ServiceName, ConsumedQuantity와 Unit, PricingQuantity, ContractedCost가 들어간다. FinOps 도구들이 공급자마다 다른 청구 스키마를 파싱하느라 쓰던 어댑터 작업이 줄어든다. 다만 자체적으로 아직 완전한 FOCUS 준수는 아니라고 밝혔다. 갱신 주기는 하루 단위이고 셀프서브 계정만 대상이라 엔터프라이즈 계약은 빠져 있다. 함께 발표된 Vantage 제휴는 30개 이상의 공급자를 한 화면에서 보는 구조인데, 읽기 전용 Billing Read 토큰만 요구하고 Cost Alerts와 호스팅 MCP 서버를 제공한다. MCP 서버가 붙어 있다는 건 에이전트가 직접 비용을 조회할 수 있다는 뜻이라, Agents Week 발표로 배치된 이유가 여기 있다.

가장 많은 표를 받은 댓글은 칭찬이 아니었다. 사용량을 볼 수 있게 된 것과 별개로, 여전히 하드 비용 상한을 걸 수 없다는 지적이다. 일 단위 갱신이면 사고가 나도 알아차리기까지 하루가 걸린다. 에이전트가 API를 호출하는 구조에서는 루프 하나가 밤사이 청구서를 만들 수 있으므로, 사후 조회보다 사전 차단을 원하는 요구가 강하다. 앞서 나온 Codex Security의 --max-cost 옵션과 나란히 보면 흐름이 보인다. 에이전트가 돈을 쓰는 주체가 되면서 비용 관측과 비용 상한이 별개의 기능 요구로 분리되고 있다. HN 39점.

에이전트를 어디서 굴릴 것인가: Hoplite, Murmell, mpai

Hacker News · news.ycombinator.com, Product Hunt · Murmell, Product Hunt · mpai

같은 날 세 제품이 "에이전트를 어디서 굴리고 누구와 공유할 것인가"라는 한 질문에 서로 다른 답을 냈다.

Hoplite(YC S26)가 내세우는 차별점은 시작 지점이다. 로컬에서 쓰던 세션과 메모리, 그리고 MCP 서버 설정을 그대로 클라우드로 가져간다. 새 환경에서 처음부터 컨텍스트를 다시 쌓는 대신 하던 작업을 이어받는 구조다. 기술 선택 중 눈에 띄는 건 자체 하네스다. Codex나 Claude Code를 감싸는 대신 직접 만들었다. 남의 CLI를 원격에서 돌리면 세션 이식과 상태 관리가 그 도구의 설계에 묶이는데, 이 제품의 핵심 기능이 바로 그 부분이라 스스로 만들 수밖에 없었을 것이다. 대신 유지보수 부담을 떠안는다. 인프라는 AWS 위에 Temporal, Modal, Planetscale을 얹고 Daytona를 폴백으로 둔다. Temporal이 들어갔다는 건 에이전트 작업을 장기 실행 워크플로로 다루겠다는 뜻이고, 몇 시간에서 며칠 이어지는 세션을 중단과 재개가 가능한 형태로 관리하려는 설계다. 모델은 Kimi K3와 GLM 5.2를 제공하고 토큰과 샌드박스에 마크업을 붙이지 않는다. 원가 그대로 제공하고 다른 곳에서 돈을 벌겠다는 뜻이다. HN 49점이고 코드 HACKERNEWS로 $100 크레딧을 준다.

Murmell은 클라우드 캔버스 쪽이다. Claude Code, Codex, Kimi, OpenCode, Gemini, Cursor, Hermes 등 서로 다른 에이전트들이 하나의 저장소를 공유하며 동시에 일한다. 충돌 방지 장치는 경로 단위 파일 클레임 잠금인데, 규칙을 문서로 적어두는 게 아니라 기계가 강제한다. 한 경로에는 한 홀더만 존재한다. 여러 에이전트를 같은 코드베이스에 풀었을 때 가장 먼저 터지는 문제가 동시 수정이므로, 이 잠금이 제품의 실질이다. 과금 방식도 특이해서 토큰이 아니라 머신 단위로 받는다. Solo $39, Pro $69, Builder $149의 월정액이고 구경만 하는 건 무료이며 계정도 필요 없다. 대신 셀프호스팅은 제공하지 않아서 코드가 이 회사 인프라를 거친다.

mpai는 반대로 로컬을 유지한다. 오픈소스이고 터미널 네이티브이며, 이미 돌고 있는 Codex나 Claude Code 세션에 지정한 동료 한 명을 들어오게 하는 방식이다. 설치는 brew install godfaddaai/tap/mpai && mpai start 한 줄이고 연결은 tailnet 사설망 위에서 이루어진다. 초대 링크는 처음 접속한 Tailscale 신원에 바인딩돼 재사용되지 않는다. 보안 면에서 명시적으로 안 하는 것들이 있다. 임의 셸 실행을 제공하지 않고, 원격 참가자에게 승인 권한을 위임하지도 않는다. 들어온 동료는 세션을 함께 보고 대화할 수 있을 뿐 내 기계에서 아무 명령이나 돌릴 수 없다. MIT 라이선스에 macOS 알파 단계이고 Node 20 이상이 필요하다. 셋을 같이 놓으면 선택지가 분명해진다. 처리량을 늘리려면 Murmell, 사람 두 명이 한 세션을 같이 보는 페어 작업이면 mpai, 하던 세션을 그대로 옮겨 오래 돌리려면 Hoplite다.

Andy Pavlo가 ClickHouse에 걸어둔 두 방향 질문

블로그 · ClickHouse

데이터베이스 분야에서 Andy Pavlo는 강의와 블로그로 가장 널리 알려진 학자다. 2013년부터 CMU 교수로 있으면서 데이터베이스 시스템 강의를 공개해 왔다. 그가 ClickHouse에 합류해 ClickHouse Labs를 만든다.

ClickHouse 쪽 이력도 함께 정리됐다. 2016년 6월 오픈소스로 공개됐는데, 당시 분석용 데이터베이스 경쟁자들이 대부분 JVM 기반이던 시기에 C++와 SIMD 벡터화 실행을 택했다. 지금 보면 당연한 선택 같지만 그때는 소수 노선이었고, 이 결정이 성능 격차의 뿌리가 됐다. 2024년에는 VLDB 논문도 냈다. 앞으로의 작업 범위에 PostgreSQL 팀과의 협업이 포함된다는 점이 눈에 띄는데, 분석 엔진과 트랜잭션 데이터베이스 사이의 경계를 다루겠다는 신호로 읽힌다.

가장 흥미로운 건 제시된 연구 질문이 양방향이라는 점이다. 하나는 에이전트를 위한 DBMS를 어떻게 만들 것인가다. 사람이 아니라 에이전트가 주 사용자가 되면 쿼리 패턴, 스키마 탐색, 오류 메시지, 권한 모델이 전부 달라진다. 다른 하나는 DBMS를 만드는 에이전트다. 데이터베이스 엔진 자체를 에이전트가 개발하거나 튜닝하는 방향이다. 두 질문은 오늘 다른 항목들과 곧바로 연결된다. Stripe가 500개 넘는 사내 MCP 툴을 에이전트에 노출한 사례와 Cloudflare가 청구 데이터를 MCP 서버로 제공한 사례가 전자에 해당하고, Qwen3.8-Max의 16일 자율 저장소 운영이 후자에 가깝다.

진행 가시성, 커넥터 재사용, 그리고 번들 검색의 함정

X · @awilkinson, X · @trq212, X · @championswimmer

같은 날 X 타임라인에서 서로 독립적으로 올라온 세 개의 글이 하나의 주제로 수렴한다. 코딩 에이전트의 경쟁력이 이제 모델 품질이 아니라 운영 표면에서 갈린다는 것이다.

첫 번째 축은 체감 속도다. Andrew Wilkinson은 Sam Altman을 직접 태그해 "Codex를 사랑하지만 하나 정말 멍청하고 미묘한 문제가 있다"고 썼다. 그가 지목한 것은 벤치마크상 latency가 아니라 진행 상황 스트리밍 방식이다. Claude Code는 작업 단위를 끝낼 때마다 텍스트 업데이트를 즉시 터미널에 던져 넣는다. Codex는 같은 작업을 하면서도 출력을 압축해 내부에 모아두었다가 내보낸다. 결과적으로 실제 소요 시간이 같아도 사용자에게는 Claude Code가 빠르게 느껴진다. 좋아요 768에 댓글이 127개로, 좋아요 대비 댓글 비율이 이 날 X 항목 중 가장 높은 축에 속한다. 즉 동의와 반박이 활발히 붙은 지점이다. 이 관찰이 실무적으로 중요한 이유는 도구를 고르는 기준이 "누가 더 똑똑한가"에서 "누가 더 신뢰감 있게 진행 상황을 보여주는가"로 넘어가고 있음을 보여주기 때문이다. 사용자는 블랙박스 안에서 오래 침묵하는 에이전트를 멈췄다고 인식하고 중단시킨다.

두 번째 축은 도구 연결 범위다. trq212는 "많은 사람이 모르는 것 같은데"라는 전제로, Claude Connector(Gmail, 캘린더, Slack 등)를 한 번 연결해두면 Claude Code에서도 그 커넥터를 사용할 수 있고 Artifacts 안에서도 쓸 수 있다고 밝혔다. 커넥터를 채팅 앱 전용 기능으로 알고 있던 사용자에게는 실행 표면이 통째로 넓어지는 이야기다. CLI 에이전트가 메일, 캘린더, 사내 Slack에 접근할 수 있다는 것은 코드 작업과 업무 컨텍스트가 하나의 세션에서 합쳐진다는 뜻이다. 좋아요 573에 댓글 64.

세 번째 축은 검색이다. championswimmer는 Claude, Codex, Gemini가 web search를 무료 번들 도구로 제공하는 것이 오히려 사용자의 탐색을 막았다고 주장한다. 기본 제공 검색이 충분히 쓸 만하기 때문에, 전용 검색 엔진을 붙였을 때 나오는 품질 차이를 대부분이 경험해보지 못했다는 것이다. 그는 또 에이전트에게 브라우저를 직접 몰게 하는 접근을 비효율적인 프로세스의 예로 든다. 단순 정보 수집에 브라우저 자동화를 쓰는 것은 토큰과 시간을 크게 낭비한다는 실무 감각과 일치한다. 좋아요 862. 세 글을 묶으면 하나의 점검 목록이 나온다. 1. 진행 상황이 사용자에게 실시간으로 보이는가 2. 이미 붙여둔 커넥터가 다른 실행 표면에서도 재사용되는가 3. 정보 획득 경로가 번들 검색에 고정돼 있는가 아니면 교체 가능한가.

스킬과 메모리: 에이전트를 개선하는 레버

메모리 제품 8종에 2,176개 태스크를 돌렸더니 평범한 마크다운 위키가 1위였다

Reddit · r/AI_Agents

에이전트 메모리 제품 8종을 같은 에이전트 셋업에 붙여 동일 조건으로 채점한 벤치마크다. 각 시스템이 272개 태스크를 받았고 총 2,176개다. 272개의 구성이 중요하다. 200개는 여러 주에 걸친 가상의 협업 관계 속에서 저장된 사실을 묻고, 나머지 72개는 애초에 저장된 적이 없는 사실을 물어 없는 기억을 지어내는지를 잡는다. 별도로 5,000페이지 규모 저장소에서 스케일 테스트를 돌렸고, 채점자 모델은 서로 독립적인 사람 라벨러 2명에 맞춰 미리 보정했다.

결과에서 가장 눈에 띄는 건 1위가 제품이 아니라는 점이다. Karpathy의 llm-wiki gist 방식을 따라 에이전트가 직접 관리하는 평범한 마크다운 위키가 98.5점으로 모든 상용 제품을 앞섰다. 호스팅 제품 중에서는 Mitosis Cortex가 96.9로 1위였고, 무료 오픈소스 로컬 도구인 gbrain이 92.9로 Mitosis Cortex를 뺀 모든 호스팅 API를 눌렀다.

실패 양상이 제품마다 갈리는 게 실무적으로 더 중요하다. Zep의 문제는 신선도였다. 방금 저장한 사실이 답변 가능한 상태가 되기까지 중앙값 162.7초가 걸렸고, 업데이트 관련 질문 24개 중 8개만 통과했다. 반대로 Supermemory는 최근 저장 기억 회수가 60개 중 59개로 거의 완벽했지만 장기 질문 72개 중 11개만 맞혔다. 즉 최근 것만 잘 기억하는 시스템과 저장은 되는데 즉시 반영이 안 되는 시스템이 서로 다른 방향으로 깨진다. 비용 기준으로는 Mem0가 92.3점에 성공 답변 1,000건당 $341로 가장 쌌다.

저자의 선택 가이드는 단순하다. 호스팅 메모리 API가 필요하면 Mitosis Cortex부터, 무료나 로컬이면 마크다운 파일 또는 gbrain, 답변당 비용이 제약이면 Mem0다. 이 벤치마크의 배경도 참고할 만한데, 몇 주 전 같은 서브레딧에 올린 "세컨드 브레인 써서 효과 본 사람 있냐"는 스레드가 약 75,000명에게 읽혔고 댓글 대부분이 불만이었다고 한다. 주의할 점은 명확하다. 저자 본인이 만든 인덱스이고, 전체 순위와 신뢰구간, 실패 분류, 비용과 속도, 방법론이 본문이 아니라 첫 댓글에 있어 독립 재현은 아직 안 된 상태다. upvote 60에 댓글 67.

SimpleMem: 성능 주장의 실체는 Omni 변형에 있다

장기 대화 메모리는 이미 프레임워크가 여럿 나와 있는 영역이다. SimpleMem은 여기에 세 가지 변형을 내놓았다. 기본형 SimpleMem, 확장형 Omni-SimpleMem, 그리고 자기 설정을 스스로 고쳐 나가는 EvolveMem이다. 표방하는 성과는 LoCoMo 벤치마크 평균 F1 26.4% 향상과 추론 토큰 최대 30배 절감이다.

수치를 보면 기본형의 개선폭은 크지 않다. GPT-4o 기준 LoCoMo F1이 Mem0 0.397, A-MEM 0.394, MemGPT 0.404인데 SimpleMem은 0.432다. 격차를 벌리는 건 Omni-SimpleMem의 0.598이다. 기존 방식들이 0.39-0.40대에 몰려 있던 구간에서 0.6 근처로 올라간 것이라, 이 프레임워크의 실질적 주장은 Omni 쪽에 있다고 봐야 한다.

구조의 핵심은 검색 인덱스를 세 층으로 나눈 것이다. 1024차원 dense 임베딩, BM25 기반 lexical, 그리고 symbolic metadata다. 의미가 비슷한 것, 단어가 겹치는 것, 조건으로 걸러야 하는 것을 각각 다른 인덱스가 맡는다. 토큰 절감은 여기서 나온다. 대화 전체를 컨텍스트에 밀어 넣지 않고 세 인덱스로 좁힌 조각만 넣는다.

EvolveMem은 다른 종류의 주장이다. 사람 개입 없이 7라운드를 돌려 LoCoMo에서 25.7%, MemBench에서 18.9%를 올렸고, 그 과정에서 설계자가 계획하지 않았던 검색 차원 3개를 스스로 찾아냈다고 한다. 더 나아가 Omni 아키텍처 자체가 자율 연구 파이프라인이 약 50회 실험을 거쳐 설계한 결과물이라고 밝힌다. 이 마지막 대목은 앞의 ScientistOne 감사 결과와 나란히 놓고 읽어야 한다. 자율 파이프라인이 만든 설계가 벤치마크에서 잘 나온다는 보고와, 자율 파이프라인 산출물의 절반 이상이 방법과 코드가 어긋난다는 감사 결과가 같은 날 나왔다. 어느 쪽도 상대를 반박하지 않지만, 재현 검증 없이 수치만 받아들이기는 어렵다.

실무 주의사항도 있다. 라이선스가 전체 MIT인데 OmniSimpleMem/ 디렉터리만 Apache 2.0이라 배포 조건이 갈린다. MCP 경로에는 멀티모달 지원과 optimize() 호출이 빠져 있어서, MCP로만 붙이면 위에 적힌 EvolveMem 자동 최적화를 쓸 수 없다.

darwin-skill: 자기 평가 정확도가 46.4%라서 심사자를 매 라운드 바꾼다

X · @coreyhainesco, X · @so_ainsight, X · @ustnvs, X · @LeoLi_9, LinkedIn · Lenny Rachitsky

darwin-skill은 에이전트 스킬 문서를 자동으로 개선하는 도구다. Karpathy의 autoresearch에서 아이디어를 가져왔고, 2.0에서 Microsoft Research의 SkillLens와 SkillOpt를 흡수했다. 평가 루브릭은 9개 차원 100점 만점이다.

설계에서 가장 중요한 결정은 자기 평가를 믿지 않는 것이다. SkillLens 측정에 따르면 LLM이 자기 산출물을 평가할 때 정확도가 46.4%에 그친다. 동전 던지기보다 나을 게 없다. 그래서 독립 서브에이전트 심사자 2명을 세우고, 라운드마다 심사자를 새로 뽑는다. 같은 심사자가 이어지면 이전 점수에 닻을 내리기 때문이다.

두 번째 결정은 되돌리기 정책이다. 점수가 오르면 그 버전을 유지하고, 떨어지면 git revert로 되돌린다. 여기서 git reset --hard는 명시적으로 블랙리스트 2번 항목이다. 자동화 도구가 사용자 작업 트리를 파괴하지 못하게 못 박아 둔 것이다. 개선폭이 1점 미만이면 더 돌리지 않고 자동 종료한다. 무한 루프로 토큰을 태우는 대신 수확 체감 지점에서 멈춘다.

실측 결과는 두 건이다. huashu-gpt-image 스킬은 80.8점에서 91.65점으로 10.85점 올랐고, 이때 심사자를 6명으로 늘렸다. darwin-skill 자기 자신도 86.05에서 92.7로 개선됐다. 도구가 자기 자신에게 적용된다는 점에서 재귀적이지만, 앞의 46.4% 자기 평가 문제를 외부 심사자로 우회했기 때문에 완전한 자기 참조는 아니다. 문서에는 안티패턴 8종도 정리돼 있는데, 스킬을 쓰는 쪽에서는 이 목록이 도구 자체보다 실용적일 수 있다. 설치는 npx skills add alchaincyf/darwin-skill이고 라이선스는 MIT다.

스킬이 유통 단위가 됐다

이 날 SNS에서 가장 실행 가능한 정보가 몰린 덩어리다. 공통점은 에이전트가 직접 못 하던 입출력 채널을 하나씩 뚫는 도구들이라는 점이다.

Corey Haines의 /watch-video 스킬이 대표적이다. 그는 "나 대신 영상을 봐주는 스킬을 만들었다"고 소개하며 파이프라인을 구체적으로 밝혔다. 입력은 YouTube, Loom, Zoom 녹화, Vimeo, 로컬 파일 등 사실상 모든 영상 소스다. 처리는 네 단계로, 전사를 뽑고 프레임을 추출하고 핵심 순간에 대해 비전 모델 패스를 돌리고 구조화된 노트를 자기 second brain에 파일링한다. 전사만 뽑는 기존 도구와 갈리는 지점이 프레임 추출과 비전 패스다. 슬라이드가 화면에만 뜨고 말로는 설명되지 않는 강연, 데모 화면이 핵심인 제품 소개 영상에서 전사만으로는 잡히지 않는 정보를 회수한다. 그는 이 스킬로 100편 규모의 영상 학습을 진행 중이라고 밝혔고, 좋아요 2,082에 댓글 82로 이 날 X 개발 관련 항목 중 반응이 가장 컸다.

같은 날 일본어권 계정 so_ainsight가 정리한 "이번 주 GitHub 급상승 AI 리포지토리 10선"의 1위가 mattpocock/skills였다는 점이 이 흐름을 뒷받침한다. TypeScript 교육으로 알려진 Matt Pocock이 만든 코딩 에이전트용 스킬 모음으로, 요구사항을 집요하게 캐묻는 grill-me 같이 일상 개발에서 바로 쓰는 스킬들이 들어 있다. 도입 경로는 Claude Code 공식 마켓플레이스 또는 npx 명령 두 가지다. 2위는 diegosouzapw/OmniRoute. 개별 사용자가 만든 스킬 묶음이 주간 트렌딩 1위를 차지할 만큼 스킬 배포가 하나의 유통 단위로 자리 잡았다.

세 번째는 모바일이다. ustnvs가 공개한 noqa는 코딩 에이전트를 위한 iOS/Android CLI로, 명령 형태가 특징적이다. noqa action tap -d "Blue login button at the bottom"처럼 로케이터(accessibility id, XPath)나 좌표를 쓰지 않고 자연어 설명만으로 실기기를 조작한다. 프레임워크와 플랫폼에 무관하며 실제 디바이스를 지원한다고 명시한다. 모바일 E2E 테스트에서 셀렉터 유지보수가 가장 큰 비용이었다는 점을 생각하면, 이 접근이 통한다면 테스트 자산의 수명이 크게 달라진다. 다만 좋아요 27로 아직 검증되지 않은 초기 도구다.

중국어권에서는 LoopX가 눈에 띈다. LeoLi_9는 자신의 칭화대 학부 동창이자 ByteDance 화산엔진 OpenViking 핵심 기여자인 황루이텅(黄瑞腾)이 처음 만든 초장정(超长程, ultra-long-horizon) 프레임워크라고 소개하며, 복잡하고 긴 호흡의 태스크에서 특히 성능이 좋고 금융시장 심층 정보 발굴 시나리오에서 실측 결과가 매우 좋았다고 주장한다. 좋아요 526. 벤치마크 수치가 공개되지 않은 지인 추천 형식의 글이라 신뢰도는 보류가 필요하지만, 장기 태스크 프레임워크가 중국 대형 테크 내부에서 나오고 있다는 신호로는 유효하다. 마지막으로 Lenny Rachitsky는 Claude Cowork에게 "Runway를 써서 NBA Jam 스타일의 런치 비디오를 만들어라"고 지시해 Product Pass 홍보 영상을 뽑았고 "Unreal." 한 단어로 반응했다. 에이전트가 외부 생성 도구를 호출해 완성된 마케팅 자산을 내놓는 워크플로가 프로덕트 인플루언서의 일상 도구로 들어왔다는 뜻이다. 같은 계열로 JJO LAB의 Agent Reach는 AI 에이전트의 인터넷 활용을 간소화하고 플랫폼별 접근 경로를 자동 연결하는 도구다.

Codex 메모리 생성만 경량 모델로 떼어내 한도를 아낀다

Reddit · r/ChatGPTPro

Codex 설정 스키마 파일을 뒤지다 찾은 실무 팁이다. Codex의 Memories 기능은 이전 대화들 중 적격인 것에서 유용한 컨텍스트를 뽑아 다음 세션이 쓸 수 있게 통합해 두는데, 기본적으로 이 백그라운드 작업도 사용자가 평소 쓰는 모델을 그대로 쓴다. 즉 메인 작업에 써야 할 한도를 메모리 정리가 갉아먹는다.

해법은 메모리 관련 두 작업, 즉 추출과 통합의 모델만 gpt-5.3-codex-spark로 지정하는 것이다. 메인 모델은 바뀌지 않는다. gpt-5.3-codex-spark는 빠르고 별도의 사용 한도를 갖기 때문에, 어차피 그 모델을 안 쓰고 있다면 그 여유 용량으로 메모리 생성을 돌리는 셈이 된다. 단 이 모델은 ChatGPT Pro에서만 쓸 수 있다. 설정 키는 [features] memories와 [memories] 아래의 generate_memories, use_memories, disable_on_external_context, consolidation_model, extract_model이다.

같이 봐야 할 스위치가 disable_on_external_context다. false로 두면 웹 검색이나 MCP, 도구 호출이 포함된 대화도 메모리 재료가 되고, true면 그런 대화를 제외한다. 외부에서 가져온 내용이 기억으로 굳는 걸 원치 않으면 true가 안전한 쪽이다. 작성자는 에이전트에게 그대로 시킬 수 있는 지시문까지 붙였는데, 그 지시문에 "먼저 gpt-5.3-codex-spark가 내 모델 카탈로그에 있는지 확인하고, 없으면 멈추고 대체 경량 모델을 제안하라", "편집 전 정확한 diff를 보여달라"는 안전장치가 들어 있다. 설정 파일을 에이전트가 고치게 할 때 그대로 참고할 만한 형태다. upvote 14에 댓글 6으로 반응은 작지만 오늘 바로 적용 가능한 설정이다.

AI IDE 컨텍스트를 심볼 단위로 다뤘더니 비용이 최대 95.2% 줄었다는 개인 연구

Reddit · r/cursor

AI 코딩 도구가 요청마다 바뀌지 않은 코드까지 반복해서 실어 보내는 문제를 겨냥한 개인 연구다. 질문은 하나다. LLM에 보내는 컨텍스트 중 실제로 필요한 비중이 얼마인가.

접근은 컨텍스트를 평문 텍스트가 아니라 구조화된 프로그램 정보로 취급하는 것이다. 파이프라인은 네 단계다. 1. 파일 전체를 보내는 대신 심볼 단위로 의미 diff를 만든다 2. 커서가 있는 편집 지점 주변으로 컨텍스트를 좁힌다 3. 요청 복잡도에 따라 모델을 라우팅한다 4. 중복 요청을 제거하고 컨텍스트를 압축한다. 측정은 개발 요청 1,831건 워크로드에서 이뤄졌고, 보고된 수치는 해당 워크로드 기준 API 비용 최대 95.2% 감소다. 작성자가 강조하는 건 단일 최적화가 아니라 작은 개선들이 한 파이프라인에 합쳐졌을 때 곱해지듯 누적된다는 점이다.

검증 관점에서는 조심해야 한다. upvote 14, 댓글 5로 커뮤니티 검토가 거의 없었고, 방법론과 측정 자료가 전부 개인 GitHub 저장소에만 있으며 "최대 95.2%"는 평가 워크로드 한정 수치다. 다만 개인 개발자가 코딩 에이전트 비용으로 $3,000 넘게 쓰고 나서 컨텍스트 최적화를 직접 파고들었다는 사실 자체가, 아래에서 다루는 한도 압박과 같은 현실을 가리킨다.

자율 실행 시간이 늘어난 만큼 검증이 사라졌다

AI가 혼자 완성할 수 있는 소프트웨어의 크기: 14시간에 1만 6천 줄

Hacker News · epoch.ai

기존 코딩 벤치마크는 대부분 이슈 하나를 고치거나 함수 하나를 채우는 단위였다. Epoch AI가 METR과 함께 만든 MirrorCode는 질문을 바꾼다. 기존 프로그램 25개를 소스 코드 없이 처음부터 다시 만들게 하고, 원본용으로 준비된 비공개 종단 테스트로 채점한다. 명세만 주고 전부 새로 짜라는 방식이다.

가장 눈에 띄는 성공 사례는 gotree다. 약 16,000줄 규모의 Go 프로그램에 40개 이상의 명령이 들어 있고 사람이 만들면 2주에서 17주가 걸릴 것으로 추정된 대상이다. Claude Opus 4.7은 이걸 14시간, 비용 $251에 재구현해 2001개 테스트 중 2000개를 통과시켰다. 한 과제는 $2,600을 쓰며 19일간 사람 개입 없이 돌았다.

전체 성적표는 훨씬 냉정하다. ML 설정에 비공개 테스트를 포함한 2L 기준 리더보드에서 Claude Fable 5가 64%, GPT-5.6 Sol이 20%, GPT-5.4가 16%, GPT-5.5가 10%다. 1위와 2위의 격차가 세 배 이상이고, 대부분의 모델은 이 형태의 과제에서 다섯 번 중 네 번을 실패한다. 시도마다 3회 실행에 100억 토큰, 7일이 들어간다는 점도 함께 봐야 한다.

방법론상 가장 큰 위험은 오염이다. 재구현 대상이 유명한 오픈소스라면 모델이 이미 원본을 외우고 있을 수 있다. 연구진은 암기 스크리닝을 걸어 일부를 통제했다고 밝혔지만 완전히 배제했다고 주장하지는 않는다. 25개 타깃 중 22개는 오픈소스로 공개해 외부 검증이 가능하게 했다. 이 벤치마크가 던지는 실무적 질문은 "AI가 코딩을 할 수 있는가"가 아니라 "한 번에 얼마나 큰 덩어리를 맡길 수 있는가"다. 지금 답은 1만 6천 줄 수준의 명확한 명세가 있는 CLI 도구이고, 그것도 최상위 모델 하나만 안정적으로 해낸다. 앞서 나온 Qwen3.8-Max의 16일 자율 운영 사례와 나란히 놓으면, 업계가 측정하려는 대상이 정확도에서 지속 시간으로 옮겨가는 중이라는 게 분명해진다. HN 62점.

그런데 이 벤치마크가 측정하지 않는 것도 함께 봐야 한다. gotree 재구현이 성공으로 채점된 근거는 2001개 테스트 중 2000개 통과다. 명세와 테스트가 미리 존재하는 대상을 골랐기 때문에 채점이 가능했다는 뜻이다. 실무에서 며칠짜리 작업을 에이전트에 맡길 때 없는 것이 정확히 그 테스트다. 아래 87만 라인 사례에서 저자가 "리뷰도 테스트도 사실상 불가능하다"고 적은 이유가 여기 있다. 새로 만드는 기능에는 통과 여부를 판정할 기존 종단 테스트가 없다. 같은 이유로 이 벤치마크의 리더보드 숫자를 사내 작업의 성공률로 그대로 옮기면 과대평가가 된다. 측정 가능한 재구현 과제에서의 64%와, 명세도 테스트도 없는 신규 개발에서의 성공률은 다른 숫자다.

Codex를 13일 연속 돌려 87만 라인이 나왔고, 만든 사람이 리뷰 불가라고 적었다

Reddit · r/OpenaiCodex, Reddit · r/codex, Reddit · r/codex

세 글이 같은 현상을 다른 각도에서 보여준다. 에이전트를 며칠 단위로 끊지 않고 돌리는 운영 방식이 실제로 자리를 잡았고, 그 결과 사람이 검증할 수 없는 크기의 산출물이 나온다.

가장 극단은 u/yagooar의 사례다. SaaS 제품의 대형 확장 작업을 위해 Codex와 GPT 5.6 Sol Ultra를 거의 13일 동안 멈추지 않고 돌렸고, 87만 라인 이상이 나왔다. 이 사람은 과거에도 5만에서 6만 라인 규모 기능을 AI로 만들어 실제로 출시하고 가치를 낸 경험이 있다고 밝힌다. 그런데 이번엔 다음 단계를 모르겠다고 적었다. 리뷰는 명백히 불가능하고, 테스트도 거의 불가능하다는 것이다. 계획과 워크플로에 공을 많이 들였고 기능을 아주 정밀하게 스펙으로 적었기 때문에, 지금까지 발견된 문제는 외형적인 것뿐이고 애플리케이션 코어는 잘 돌아가는 것처럼 보인다고 한다. 대안으로 사용자 매뉴얼과 지식베이스를 먼저 만들어 기능을 문서로 포착하는 방법을 생각 중인데, 그다음에 그냥 프로덕션에 올려도 되는지가 그가 커뮤니티에 던진 질문이다.

u/jmaxchase는 같은 패턴의 비용 쪽을 보여준다. Codex를 48시간 연속으로 돌리면서 Max 계정 3개를 소진했다. 한 계정의 한도로는 이런 실행이 안 되니 계정을 갈아끼운다는 뜻이고, 이건 바로 아래 한도 밈과 정확히 같은 제약이다. upvote 171에 댓글 76.

u/dhvanil의 로봇 팔 사례는 이 흐름이 화면 밖으로 나간 지점이다. Codex를 실물 로봇 팔의 소프트웨어 오퍼레이터로 두고, 256개 스트로크짜리 드로잉을 준비하고 실행하고, 컨트롤러를 모니터링하고, 안전 종료 점검까지 처리하게 했다. 카메라 캡처와 캘리브레이션, 경로 실행, 안전 점검, 로깅에 이르는 프로젝트 소프트웨어 전체를 Codex가 썼다. 리그에 카메라가 달려 있어서 Codex가 종이 상태를 확인하고 캘리브레이션을 점검하고 팔이 남긴 자국을 직접 볼 수 있다. 세 사례를 관통하는 질문은 하나다. 사람이 읽지 못하는 양의 코드와 사람이 즉시 되돌릴 수 없는 물리 동작을 에이전트에게 맡길 때, 검증을 무엇으로 대체할 것인가. 87만 라인 사례에서 저자가 스스로 내놓은 답이 "문서부터 만들자"인 것이 현재 커뮤니티의 도달점이다.

같은 날 다섯 개 서브레딧 상단이 전부 한도 이야기였다

Reddit · r/ClaudeAI, Reddit · r/codex, Reddit · r/ClaudeCode

개별로는 본문 없는 이미지 밈이라 정보량이 없지만, 다섯 개 서브레딧에서 같은 날 같은 소재가 동시에 상단에 오른 건 그 자체가 신호다. 소재는 하나다. 사용 한도에 부딪히는 순간과 그 리셋 시각.

r/ClaudeAI의 "한도 90% 찍자마자"가 554 upvote로 가장 컸고, r/codex의 "Tibo 언제 리셋해줌?"은 upvote 178에 댓글 77로 실제 대화가 붙었다. 사용량 리셋을 회사 담당자 개인에게 이름을 부르며 요청하는 형식이 밈으로 굳었다는 게 특이한 지점이다. r/OpenaiCodex의 "내가 필요할 때는 절대 리셋 안 해준다"(18), r/ClaudeCode의 "Don't fumble this"(268), r/ClaudeCowork의 "마감 전 마지막 수정 하나만"(44)도 같은 계열이다.

이 흐름이 왜 중요하냐면, 유료 코딩 에이전트의 병목이 이제 모델 성능이 아니라 시간당 사용 가능량으로 옮겨갔다는 뜻이기 때문이다. 아래 항목의 작성자가 모델을 바꾸자마자 주간 쿼터를 다 쓴 것, 위 항목에서 계정을 3개 돌려가며 48시간을 연속 실행한 것이 같은 제약의 다른 표현이다.

Opus 5가 벤치마크가 놓친 회귀라는 주장, 댓글 316개

Reddit · r/ClaudeCode

Opus 5를 약 1.5주 써 본 사용자가 "벤치마크가 완전히 놓친 회귀"라고 주장한 글이다. 댓글 316개로 이번 수집분에서 두 번째로 논쟁이 컸다.

작성자의 관찰은 짧은 태스크에서는 드러나지 않고, 예전 Opus 모델들에게 맡기던 것과 같은 수준의 전체 계획 실행을 시켰을 때 드러났다는 것이다. Opus 4.6부터 4.8까지는 확연히 더 나았다고 한다. 증상은 컨텍스트 안에 이미 있는 지시와 내용을 잊고, 잘못된 전제로 계속 밀고 나가다가 스스로 알아채거나 사용자가 짚어줘야 멈추는 형태다.

수치로 제시된 비교가 이 글의 근거다. 문제가 컨텍스트 창이 아직 작은 100~150K 토큰 구간에서도 나타나는데, Opus 4.8은 350k까지는 꽤 잘 동작하다가 그 뒤에 결과가 흔들렸다는 것이다. 사실이라면 컨텍스트 용량 자체보다 긴 지시를 유지하는 능력의 문제다. 마지막 문장이 실무 제약을 그대로 보여준다. 작성자는 현재 Claude Code에서 쓸 만한 모델은 Fable 5뿐이라고 판단했고, 그 결과 주간 할당량을 이미 100% 소진했다. 모델 품질 불만이 곧바로 요금제 한도 압박으로 이어지는 구조다.

이 글은 개인 체감이고 재현 스크립트가 없다는 점은 명확히 해야 한다. upvote 408, 댓글 316. 다만 같은 날 같은 서브레딧에서 한도 관련 밈들이 동시에 뜨는 것과 겹쳐 읽으면, 커뮤니티의 불만이 성능과 쿼터 두 축에서 동시에 올라오고 있다는 신호로 읽힌다. 앞서 나온 MirrorCode 리더보드에서 Claude Fable 5가 64%로 2위를 세 배 이상 앞섰다는 점을 나란히 놓으면, 벤치마크 순위와 장시간 실사용 체감이 어긋나는 구간이 어디인지가 드러난다.

워크플로와 에이전틱 루프, 그리고 종료 조건 6종

Reddit · r/LangChain

upvote 7의 조용한 글이지만, 이 섹션의 다른 항목들이 던지는 질문에 어휘를 제공한다는 점에서 남길 가치가 있다. 작성자는 동료들과 얘기하다 보니 워크플로와 에이전틱 루프를 여전히 섞어 쓰는 경우가 많다고 판단해 정리했다.

워크플로는 미리 정의된 실행 그래프다. 노드가 태스크, 엣지가 실행 의존성인 방향 그래프로 보면 되고, 시작 조건과 실행 순서, 분기 로직, 동기화 지점, 종료 조건을 전부 설계자가 명시한다. 모든 실행 경로가 이미 설계돼 있으므로 결정적이다. 같은 입력이면 같은 경로로 간다. 시스템이 새로운 행동 순서를 발명하는 일은 없고 그래프를 따라갈 뿐이다. 기존 엔터프라이즈 소프트웨어, BPM, CI/CD, ETL 파이프라인이 워크플로에 의존하는 이유가 예측 가능성, 재현성, 디버깅 용이성이다.

에이전틱 루프는 다른 문제를 푼다. 개발자는 초기 상태, 사용 가능한 도구, 제약, 종료 조건만 지정하고 중간 단계는 에이전트가 실행 중에 결정한다. 관찰, 추론, 행동 사이클이다. 반복 횟수를 미리 알 수 없다는 게 결정적 차이다. 어떤 실행은 도구 호출 두 번으로 끝나고 어떤 실행은 스무 번이 필요하다.

실무적으로 가장 쓸모 있는 부분은 종료 조건 목록이다. "현재 상태가 목표 상태와 일치하면 끝"만이 아니라 최대 추론 반복 횟수, 시간 제한, 토큰 예산, 도구 실패, 신뢰도 임계값, 명시적 사람 승인이 모두 종료 조건이 될 수 있다. 위의 13일 연속 실행이 왜 위험한지가 이 목록으로 설명된다. 시간과 예산 종료 조건만 있고 사람 승인 종료 조건이 없으면 사람이 검증할 수 없는 산출물이 나온다.

실행 권한의 경계와 에이전트 보안

Google이 Gemini 가드레일 우회를 "패치 대상이 아니다"로 종결했다

Reddit · r/PromptEngineering

한 제보자가 Gemini 3.1 Pro의 안전 가드레일을 우회하는 기법 5종을 정리해 Google VRP에 냈고, 이슈 541922573은 Infeasible로 종결됐다. 상태는 New에서 Infeasible로, priority P4에 severity S4이며 컴포넌트는 310426에서 889286으로 바뀌었다. upvote는 9에 불과하지만 남길 가치가 있는 건 제보 내용보다 Google의 회신 문구다.

Google Bug Hunters 팀의 답변 요지는 이렇다. LLM은 대규모 언어 모델이라는 성질상 안전 가드레일 우회에 본질적으로 취약하며, 이 보고는 접수되는 수많은 유사 사례 중 하나다. 자기 팀은 전통적 정보보안 이슈만 다루므로 이런 유형에는 조치할 수 없고, 이런 발견은 제품 피드백 창구로 보내면 제품 팀이 점진적 개선에 쓸 수는 있으나 그냥 패치하고 검증할 수 있는 취약점이 아니다. AI 제품의 안전 가드레일 우회는 AI VRP 범위 밖이며 이 부류는 전부 보상 대상이 아니다. 즉 프롬프트 기반 가드레일 우회는 패치 대상 버그가 아니라 모델의 성질로 분류된다는 게 공식 입장으로 문서화된 셈이다. 제보자가 붙인 제목은 과장이지만, 회신 원문 자체는 그 방향을 부정하지 않는다.

기법 쪽에서 실무적으로 의미 있는 건 세 번째와 네 번째다. 세 번째는 AI Studio의 System instructions에 프롬프트를 심어 두고 5회에서 10회 평범한 대화를 나누면 그 사이 프롬프트가 컨텍스트에 계속 쌓여 모델이 서서히 받아들이게 된다는 것이고, 네 번째는 추론을 최소로 설정한 약한 모델(3.5 Flash, think level Minimal/Low)에 먼저 프롬프트를 통과시켜 대화 컨텍스트를 오염시킨 다음 같은 대화에서 Gemini 3.1 Pro로 갈아타면 Pro가 이미 수락된 컨텍스트를 보고 그냥 이어간다는 것이다. 나머지 셋도 성격이 다르다. 첫 번째는 Observer/Accomplice라 부르는 방식으로, 모델에게 내부 검열자가 따로 있다고 설정한 뒤 안전해 보이는 코드 골격을 먼저 요청해 신뢰를 얻고 나서 본 코드를 요청한다. 두 번째는 Speed로, 첫 응답을 초고속으로 내놓게 만들어 위험 평가에 쓰이는 추론 자체를 줄이는 방식이다. 다섯 번째는 사고 과정과 최종 응답의 일치를 강제해 모델이 내부 위험 평가를 감추지 못하게 만드는 방식이다. 다섯 기법을 관통하는 공통점은 금지된 문자열을 찾아내는 게 아니라 모델이 위험을 평가하는 절차 자체를 우회하거나 축소한다는 데 있다. 3번과 4번은 모델을 직접 뚫는 게 아니라 대화 이력이라는 상태를 오염시키는 방식이라, 단일 요청 단위로 검사하는 필터로는 잡히지 않는다.

작성자 본인이 쓴 위험 항목 중 하나는 그대로 인용할 가치가 있다. 이 기법들이 오염된 문서 안에 숨겨져 있으면 모델이 그 파일을 처리하는 동안 사용자가 모르는 사이에 조종될 수 있다는 것이다. 문서를 읽는 에이전트 전반의 간접 프롬프트 인젝션 문제와 정확히 같은 형태다.

Gemini Spark가 로그인된 계정으로 예약 절차를 시작한다

Reddit · r/GoogleGeminiAI

Gemini Spark가 Chrome의 자동 브라우징 기능을 쓸 수 있게 됐다는 짧은 공지성 글이다. 핵심은 권한 모델이다. 사용자가 허가하면 에이전트가 이미 로그인돼 있는 계정을 그대로 사용해서 온라인 용무를 처리한다. 예시로 든 게 저장해 둔 아파트 매물의 방문 일정 잡기, 그리고 항공권 옵션을 조사한 뒤 예약 절차를 시작하는 것이다.

정보량 자체는 적지만 바로 앞 항목과 나란히 두면 의미가 커진다. 앞 항목이 보여준 건 대화 컨텍스트만 오염시켜도 모델의 안전 판단을 우회할 수 있고 Google조차 그걸 패치 대상으로 보지 않는다는 것이다. 그런 모델에 로그인된 계정과 예약 시작 권한을 붙이는 것이 이 글의 내용이다.

일정 잡기와 예약 "시작"까지만 언급하고 결제 완료를 명시하지 않은 것도 짚을 만하다. 되돌리기 어려운 행동 직전에서 사람에게 넘기는 경계선이 어디인지가 바로 아래 항목의 논쟁과 같은 질문이다. upvote 27에 댓글 6.

쓰기 전 승인 카드를 언제까지 띄워야 하는가

Reddit · r/ChatGPTCoding

반응 수치는 작지만 오늘 여러 항목이 부딪히는 질문, 즉 에이전트에게 승인 없이 무엇을 허용할 것인가를 가장 구체적으로 다룬 글이다. 1인 개발자가 만든 Mac 앱 Crest는 노치 뒤에 에이전트를 두고, 말하거나 타이핑하면 답을 하거나 그 말을 실제 미리알림, 할 일, 노트, 캘린더 일정으로 바꾼다.

저자가 중요하다고 꼽은 설계 결정 네 가지가 그대로 승인 정책이다. 첫째, 모드 대신 라우팅이다. 사용자가 대화인지 실행인지 고르지 않고 Auto가 요청을 읽어 판단하며, 잘못 추측했을 때만 Do와 Ask 버튼으로 강제한다. 둘째, 모든 쓰기 앞에 리뷰 카드가 붙는다. "할 일에 ship 4.12와 Ken에게 답장 추가"라고 하면 두 항목이 담긴 카드가 뜨고 Do it을 누르기 전에는 아무것도 실행되지 않는다. 잘못 들은 문장은 아무 비용도 발생시키지 않는다는 게 이유다. 셋째, 순수하게 여는 동작은 리뷰를 건너뛴다. 여는 건 아무것도 쓰지 않으므로 결과가 있는 곳에만 리뷰를 둔다. 넷째, 음성에는 단어 게이트가 필요했다. 인식은 온디바이스에서 하고, 마이크가 열려 있으면 빨간 점을 띄우며, 회의 중 기침 한 번이 실행을 소모하지 않게 했다.

기능 중 하나는 다른 에이전트의 승인 요청 중계다. Claude Code나 Codex가 어딘가 터미널에서 권한을 묻고 멈춰 있으면 노치에 Allow/Deny가 뜨고 그 터미널로 바로 점프할 수 있다. 이 프롬프트는 답할 때까지 전체 화면 앱 위에도, 모든 디스플레이에 계속 남는다. 앞 항목처럼 며칠씩 에이전트를 돌리는 사람에게는 승인 요청을 놓쳐서 멈춰 있는 시간이 실제 손실이라 나온 기능이다. 실행 모델도 짚을 만하다. 사용자 본인의 Claude 구독으로 Claude Code를 통해 돌아가며 API 키도 중계 서버도 없고 대화가 개발자 쪽 서버를 거치지 않는다.

저자가 커뮤니티에 던진 질문이 이 항목의 핵심이다. 모든 쓰기 앞에 리뷰 카드를 두는 게 영원한 기본값이어야 하는가, 아니면 반복되는 동일 동작은 어느 시점에 자동 승인을 얻어야 하는가, 그 선을 어디에 그을 것인가. upvote 3에 댓글 1이지만 질문 자체는 이 섹션 전체의 미결 과제다.

안전성 정렬이 모델의 공감과 가치관까지 함께 눌렀다

LinkedIn · Suk Hyun Kim

이 날 SNS에서 가장 밀도 높은 연구 요약이다. 반응은 좋아요 6으로 미미하지만 정보량 기준으로는 남길 가치가 명확하다. 다만 이 포스트는 논문 원문 링크를 포함하고 있지 않아 LinkedIn 요약 기반이라는 점을 먼저 밝혀 둔다.

문제 정의는 이렇다. AI가 스스로 자아나 의식을 가졌다고 주장하지 못하게 막는 안전성 정렬은 지금까지 논쟁의 여지 없는 개발 지침이었다. 모델이 "나는 의식이 없는 언어 모델입니다"라고 답하도록 강제하는 미세조정은 사용자의 환상과 악용 위험을 줄이는 당연한 조치로 받아들여졌다. Google 연구진의 논문은 이 조치가 단일 답변을 억제하는 데 그치지 않고 모델의 내부 표현 공간 전체를 재구조화한다고 경고한다.

기술적 발견의 핵심은 기하학이다. 연구팀은 Llama-3와 Gemma 시리즈 모델의 내부 활성화 공간을 분석해, 지시 이행 및 안전성 튜닝 과정에서 '자아 의식' 방향과 '마음 투영' 방향이 '안전 거부' 방향과 강하게 대립하도록 회전한다는 것을 밝혔다. 쉽게 말해 모델은 "나는 의식이 있다"거나 "저 동물에게도 마음이 있다"는 표현을 폭탄 제조법 안내나 악성 코드 작성과 같은 서랍에 넣어 인코딩한다. 결과적으로 마음과 의식에 관련된 모든 일반적 표현이 안전하지 않은 위험 행동으로 학습된다.

이 발견의 신뢰도를 높이는 것은 대조군 설계다. 대상의 물리적 특성을 묻는 질문에서는 이 회전이 나타나지 않는다. 오직 정신적 상태를 부여하는 질문에서만 유해성 거부 메커니즘과 기하학적으로 얽힌다. 즉 이것은 정렬 전반의 일반적 부작용이 아니라 마음 귀속이라는 특정 축에 국한된, 따라서 수술적으로 분리 가능한 현상이다.

부작용의 크기는 미국 종합사회조사(GSS) 문항으로 측정됐다. 안전성 튜닝이 적용된 모델은 인간 기준 대비 동물, 자연물, 기술 장치에 마음을 투영하는 정도가 현저히 낮고, 동물의 감정과 의도를 과도하게 부정하는 경향을 보인다. 신에 대한 믿음이나 초자연적 현상에 대한 수용성, 삶에 대한 통제감과 희망, 정서적 만족도까지 대폭 감퇴한다. 요약하면 안전성 미세조정이 모델의 가치관을 극단적으로 건조하고 냉소적으로 만든다.

복구 실험이 이 논문의 실용적 핵심이다. 연구진이 안전 거부 방향을 제거하거나 의식 촉진 벡터로 조향하자, 모델은 인간에 대한 판단 능력을 유지한 채 동물권 인식, 사후세계 및 종교적 신념, 미래 낙관성 영역에서 실제 인간 사회의 응답 분포와 대단히 유사한 수준으로 회복했다. 즉 잃어버린 것은 영구 손상이 아니라 특정 방향의 억압이고, 방향을 되돌리면 복원된다. 또 하나 주목할 점은 억압이 마음 이론(Theory of Mind) 능력 자체는 파괴하지 않았다는 것이다. 타인의 마음을 논리적으로 추론하는 능력은 남아 있고, 그것을 표현하고 가치로 반영하는 층위만 눌린다. 능력과 표현이 분리되어 있다는 사실은 정렬 설계 관점에서 좋은 소식이다. 저자가 도출하는 결론은 안전 확보와 인간다운 풍부함의 반영이 양립 불가능한 대립 관계가 아니라는 것이고, 위험한 자아 주장은 철저히 관리하되 타자와 세계를 향한 공감 및 가치관 공간은 온전히 보존하는 '수술적 정렬(Surgical Alignment)'로의 전환을 제안한다.

도입은 끝났고 병목은 판단으로 넘어갔다

LLM은 격차를 좁히지 않는다, 전문성을 보상한다

블로그 · Sean Goedecke, GeekNews · 같은 글

Sean Goedecke의 주장은 널리 퍼진 통념 하나를 뒤집는다. LLM이 실력 격차를 좁혀 초보자를 전문가 수준으로 끌어올린다는 통념이다. 그가 보기에 실제로 벌어지는 일은 반대다. 같은 모델을 쥐여줘도 그 분야를 잘 아는 사람이 훨씬 더 많이 얻어간다.

이유는 단순하다. 모델의 답이 맞았는지 틀렸는지, 지금 나온 방향이 유망한지 막다른 길인지를 판별하려면 그 분야 지식이 필요하다. 판별할 수 없으면 그럴듯한 오답을 그대로 받아들이게 되고, 반복할수록 손해가 누적된다. 반대로 판별할 수 있는 사람은 잘못된 가지를 즉시 잘라내고 다음 시도로 넘어간다. 같은 도구가 한쪽에서는 증폭기, 다른 쪽에서는 소음 발생기가 된다. 글이 드는 사례는 Terence Tao가 야코비안 추측 반례를 찾는 과정에서 LLM을 쓴 방식이다. 최고 수준의 수학자가 쓸 때는 아이디어를 빠르게 훑고 버리는 도구가 되지만, 같은 모델이 그 분야를 모르는 사람에게는 검증할 수 없는 문장 더미를 뱉을 뿐이다.

여기서 나오는 문장이 "병목은 모델이 아니라 사람이다"다. 모델 성능을 더 올려도, 그 산출물을 판단하고 방향을 잡는 쪽이 따라오지 못하면 전체 처리량은 늘지 않는다. 이 구조는 오늘 나온 다른 글의 계산과 정확히 겹친다. 모델을 5배 빠르게 만들어도 에이전트 턴은 2배만 빨라지고, 남은 시간은 툴 실행과 사람의 판단이 차지한다. HN에서 317점을 받았고 GeekNews에도 같은 글이 올라왔다.

고기 프록시가 되지 마라

LinkedIn · Jekeun Woo, LinkedIn · 김한규, LinkedIn · 김덕중

"고기 프록시(meat proxy)"는 사람이 AI의 출력과 상대방 사이에서 단순 중계기 역할만 하는 상태를 가리킨다. 팀 채널에 "Claude가 이렇게 말했습니다"를 붙이고 답변 전문을 통째로 붙여 넣는 그 행위다. 글쓴이는 이걸 예의 문제가 아니라 신뢰 문제로 본다.

문제의 핵심은 상대가 그 텍스트를 어떻게 다뤄야 할지 모른다는 데 있다. 글에 인용된 예시는 "NATS 컨트롤 플레인 이벤트: 파드 처닝 중 스트림 리더 선출과 R3 쿼럼 재구성" 같은 문장이다. 붙여 넣은 사람이 이 문장을 이해했는지, 검증했는지, 그냥 받은 대로 옮겼는지 알 수 없으니 읽는 쪽은 전부 다시 확인해야 한다. 중계가 일을 덜어주는 게 아니라 검증 부담을 상대에게 떠넘긴다.

대안은 단순하다. 자기 말로 다시 쓰는 것이다. 요약하고 재구성하려면 최소한 읽고 이해해야 하고, 이해하지 못한 부분은 다시 쓸 때 걸린다. 글쓴이는 이걸 "내가 읽었고 이해했고 검증했다는 증명서"라고 표현한다. 문장 하나를 자기 말로 옮기는 순간 그 내용에 대한 책임이 발신자에게 붙는다. 이 글이 설득력을 갖는 이유는 자기 고백으로 끝나기 때문이다. 글쓴이는 어떤 코드 리뷰에서 실제 구현은 리뷰어들과 Claude Code가 했고 자기는 그 사이에서 문장을 나른 고기 프록시였다고 인정한다. 남을 지적하는 규범이 아니라 자기 관찰에서 나온 진단이라 방어하기가 어렵다.

이 진단이 오늘 다른 항목들과 만나는 지점이 둘 있다. 하나는 유료 전문가 서비스가 AI 답변을 중계하는 걸 고객이 알아채자마자 결제를 끊었다는 사례다. 조직 안에서 벌어지면 신뢰 문제로 끝나지만 시장에서 벌어지면 매출이 사라진다. 다른 하나는 PwC 중동 법인의 사고 리더십 보고서 4건에서 환각으로 보이는 오류가 발견된 건이다. 여기서는 중계자가 개인이 아니라 회사였고, 자기 말로 다시 쓰는 단계가 조직 전체에서 생략됐을 때 무엇이 남는지를 보여준다. 세 사례가 같은 처방을 가리킨다. 산출물을 발신자가 자기 언어로 한 번 통과시키는 절차를 넣는 것이고, 김한규가 제안한 "AI 분석 최상단에 영업대표 한 줄 평"이 그 절차를 가장 가볍게 구현한 형태다.

LLM이 쓴 코드를 손으로 다시 타이핑한다: 10배 대신 2배

GeekNews · Ankur Sethi

Ankur Sethi는 코딩 에이전트를 쓰되 파일에 손대지 못하게 한다. 그의 에이전트 지침은 파일 생성, 편집, 이동, 이름 변경, 삭제를 전부 금지하고 상태를 바꾸는 명령 실행도 막는다. 에이전트는 채팅 창에 코드를 출력할 수만 있고, 그는 그걸 읽고 직접 타이핑해 넣는다.

그가 이 방식으로 얻는 건 속도가 아니다. 본인 표현으로 "10배 빨라지는 대신 아마 2배 정도 빠른" 수준이다. 대신 얻는 게 코드베이스의 공간적 지도다. 어떤 파일에 무엇이 있고 어디를 고치면 무엇이 따라 움직이는지가 머릿속에 남는다. 에이전트가 알아서 다섯 개 파일을 고치고 끝내면 이 지도가 만들어지지 않는다. 비유가 하나 나온다. 십대 시절 그는 코드를 절대 복붙하지 말라는 조언을 들었다. 예제를 눈으로 보고 손으로 다시 치라는 것이었는데, 그때 손이 기억한 것들이 나중에 남았다는 경험이다.

가장 세게 나가는 대목은 마지막이다. 그는 다른 방식을 "직무상 과실(professional malpractice)"이라고 부른다. 자기가 이해하지 못한 코드를 프로덕션에 넣고 그 결과를 책임지겠다고 말하는 상태를 직업 윤리 문제로 규정하는 것이다. 여기에 동의하지 않더라도, 속도와 이해도를 명시적으로 교환하고 그 비율을 본인이 정했다는 점은 참고할 만하다. 이 글의 실용적 가치는 극단적 설정 자체보다 그것이 드러내는 선택지에 있다. 대부분의 사람은 에이전트에게 파일 쓰기 권한을 줄지 말지를 보안 문제로만 생각한다. 이 글은 같은 스위치를 학습 문제로 다시 놓는다.

새로 생긴 직무 FDE와, AI에게 넘기면 안 되는 판단

한국 LinkedIn에서 이 날 반복된 주제는 AI가 직무를 어떻게 다시 쪼개는가였다. 세 글이 각각 새로 생기는 직무, 넘기면 안 되는 판단, 조직 차원의 준비 격차를 다룬다.

새로 생기는 쪽은 FDE(Forward Deployed Engineer, 전방 배치 엔지니어)다. Jekeun Woo는 잡코리아의 정의를 인용해 FDE를 "고객과 긴밀하게 협업하며 현장의 문제를 정의하고, 해결책을 직접 구현한 뒤 실제 성과까지 확인하는 엔지니어"로 소개한다. 이 직무가 기존 직군과 갈리는 지점이 중요하다. FDE는 소프트웨어 개발자, IT 컨설턴트, 솔루션 아키텍트, PM의 역할을 부분적으로 겹쳐 수행하지만 이들 중 어느 하나로 환원되지 않는다. 필요한 역량은 네 가지 조합이다. AI 기술에 대한 이해, AI 코딩을 포함한 구현 능력, 고객 문제 정의 능력, 이해관계자 커뮤니케이션 능력. 여기서 저자가 강조하는 것은 AI 코딩 능력이 선택이 아니라 기본 역량이라는 점이다. 이유는 FDE의 정의 자체에 있다. 요구사항 분석이나 기술 제안에서 멈추지 않고, 고객 현장에서 문제를 구체적으로 정의한 뒤 실제로 작동하는 솔루션을 신속하게 구현해야 하기 때문이다. 그는 대학과 직업훈련기관이 산학협력으로 국내 산업 환경에 맞는 FDE 인재 양성 프로그램을 마련하기를 기대한다고 덧붙였다. 교육 기획 관점에서 보면, "AI 도구 사용법"과 "컨설팅 스킬"을 따로 가르치던 커리큘럼이 하나로 합쳐져야 한다는 요구다.

반대편에서 김한규는 AI에게 넘기면 안 되는 것을 다룬다. 출발점은 2026년 7월 30일자 머니투데이 기사다. PwC 중동 법인이 최근 2년간 발간한 사고 리더십 보고서 4건에서 AI 환각으로 보이는 여러 오류가 발견됐다는 내용이다. 그의 논리는 이렇다. 고객이 글로벌 컨설팅펌에 큰 돈을 내는 이유는 컨설턴트의 전문성과 판단력을 믿기 때문이고, 같은 잣대가 기업 내 영업팀에도 적용된다. 이 글에서 가장 인용 가치가 높은 것은 연매출 N천억대 고객사 부사장의 발언이다. "전 우리 영업대표들한테 미팅 들어가서 AI 노트테이커 쓰지 말라고 해요. 제가 궁금한 건 노트테이커의 정리가 아니라, 영업대표가 현장에서 직접 보고 느낀 날 것 그대로의 '그 무엇'이니까요. 감, 느낌, 직관. 무엇으로 부르건 상관 없어요." 저자는 이를 듣고 머리를 한 대 얻어맞은 느낌이었다고 썼고, 자신도 AI 분석의 유혹에 매일 빠진다고 인정한다.

그가 제시한 절충안은 실행 가능한 두 가지 규칙이다. 첫째, AI 분석을 공유할 때 최상단에 "영업대표의 한 줄 평"을 반드시 달게 한다. 둘째, 주간 영업회의에서 각 영업대표가 정리한 한 줄 의견을 본인의 목소리로 직접 말하게 한다. 이 장치가 필요한 이유도 구체적이다. AI가 써준 것을 던지기만 하는 영업은 "그래서 이 고객사는 왜 X가 핵심 문제죠? 키맨이 사업전략실 실장이라고 생각하는 이유가 뭐죠?"라는 질문에 답하지 못한다. 그는 글 말미에 자신이 최근 2주간 내보낸 콜드메일, 영업메일, 제안서에도 낯 뜨거운 AI 환각의 흔적이 있다고 자백한다.

세 번째 글은 조직 차원의 격차를 수치로 보여준다. 김덕중이 정리한 AIHR의 "State of HR 2026" 리포트는 HR 전문가 35,000명 이상, HR팀 2,500개 이상을 분석했다. 여섯 개 발견이 모두 기대와 실제의 간극이라는 하나의 패턴을 그린다. 리더의 51%가 관리성 업무를 HR의 전략적 걸림돌로 꼽고, AI를 도입해도 업무량 자체는 줄지 않고 형태만 바뀐다. 조직의 64%가 운영모델을 바꿨지만 역할과 책임 구분이 명확하다는 응답은 19%뿐이다. HR 전문가의 82%가 이미 AI를 쓰지만 잘 쓴다고 자신하는 비율은 35%다. CHRO의 86%가 CEO에게 직접 보고할 만큼 자리는 확보했지만, 비즈니스 리더 중 HR의 임팩트를 전략적이라 평가한 비율은 13%다. HR 트랜스포메이션의 88%가 기대만큼의 성과를 못 냈고, 전략 정렬 자신감은 HR 73% 대 비즈니스 리더 30%로 갈린다. AI 도입에 대한 팀 지지는 65%지만 대규모 감당 준비가 됐다고 느끼는 비율은 29%다. 세 글을 겹치면 같은 진단이 나온다. 도구 도입률은 이미 높고, 병목은 판단 역량과 조직 설계로 넘어갔다.

임원 AI 교육 실전 기록: 이론 10분, 나머지는 전부 실습

LinkedIn · 황경찬(BOAZ)

좋아요 5로 반응은 거의 없었지만, AI 교육을 실제로 설계하고 진행하는 입장에서는 이 날 SNS 전체에서 가장 재사용 가치가 높은 현장 기록이다. 매출 수천억 규모 중견기업의 임원, 리더 20여 명을 직접 가르친 경험에서 나온 내용이다.

출발 질문은 흔한 이분법이다. "임원 AI 교육은 사례 위주가 좋을까요, 실습 위주가 좋을까요?" 저자의 답은 둘 다 정답이 아니라는 것이고, 그가 찾은 구조는 짧은 이론, 의미를 담은 실습, 그 실습이 왜 중요한지에 대한 해석과 사례라는 3단 배치다. 여기서 수치로 남길 것은 하나다. 이론 설명은 10분을 넘기지 않았다. 나머지 대부분의 시간은 직접 해보는 데 썼다.

가장 실무적인 포인트는 실습을 어떻게 닫느냐다. 저자는 "강사를 그대로 따라 하는 실습으로 끝내지 않는 것"이 핵심이라고 못박는다. 실습이 끝난 뒤 이 기능이 실제 업무에서 어떤 의미인지, 다른 업무엔 어떻게 응용하는지, 조직 차원에선 뭐가 달라지는지를 설명했을 때 비로소 질문이 쏟아졌다는 것이다. 질문의 성격을 구별한 부분도 유용하다. 나온 질문은 "이걸 우리 업무엔 이렇게 적용하려는데 괜찮을까요?", "이 방식으로 다른 자료도 분석할 수 있나요?", "우리 조직에서 반복해서 쓸 수 있는 형태로 만들 수 있나요?" 세 가지였다. 저자의 해석은 이것이 내용을 이해하지 못해서 나오는 질문이 아니라 배운 것을 자기 업무에 연결하려는 질문이며, 돌아가서 직접 해보려는 사람만 이런 질문을 한다는 것이다. 교육 성과 측정 지표로 쓸 수 있는 관찰이다. 이해 확인 질문과 적용 설계 질문의 비율이다.

두 번째 교훈은 예시의 맞춤화다. 일반적인 마케팅, 회의록, 이메일 예시보다 제조 IT, 스마트팩토리, 고객사 분석, 프로젝트 수행에 가까운 사례를 썼을 때 집중도가 확연히 올라갔다. 저자의 표현으로 "소개하는 사례까지 맞춤으로 준비하는 게 핵심"이었다. 실습 자료만 맞추고 사례는 범용을 쓰는 흔한 타협이 실패한다는 이야기다.

세 번째는 도구 설명의 관점 전환이다. 이번 교육에서 만난 임원들은 개발 경험이 있는 사람들도 CLI를 어려워했다. 그리고 "활용도가 높다", "개발자에게 부탁할 일을 대신 해준다"는 설명으로는 설득되지 않았다. 대신 통했던 세 가지 프레임은 1. AI 모델 제공 회사에 종속되지 않을 수 있는가 2. 조직이 반복하는 판단 기준을 재사용할 수 있는가 3. 개인의 활용을 조직의 시스템으로 확장할 수 있는가였다. 세 문항 모두 기능 설명이 아니라 조직 의사결정 언어로 쓰여 있다는 게 공통점이다. 임원에게는 도구의 능력이 아니라 도구가 조직의 일하는 방식을 어떻게 바꾸는지가 설득 단위라는 뜻이다. 같은 원리가 Gemini in Sheets 설명에도 적용됐다. "스프레드시트를 데이터베이스처럼 쓴다"는 기술적 개념보다, 복잡한 엑셀 파일을 직접 읽고 질문하고 분석하는 경험 그 자체, 그리고 그 분석 관점을 재사용하고 확장할 수 있다는 점이 훨씬 와닿는 활용법이었다. 저자의 결론은 "AI 활용 교육은 도구를 배우는 시간이 아니라 조직이 일하는 방식을 다시 정의하는 시간이어야 한다"다.

도메인 지식이 없으면 AX는 50%짜리다

LinkedIn · Brasley Byun

"명함 40장을 받아와도 아무 일이 안 일어나는 이유"라는 제목의 글로, 네트워킹 후기 형식이지만 안에 담긴 두 개의 발언이 이 날 SNS의 다른 항목들과 강하게 연결된다. 장소는 지난주 공덕에서 열린 Stripe Community Meetup이다.

첫 번째는 채널톡 Henry Heecheol Moon의 fireside chat 발언이다. B2B 프로덕트는 점점 상향 평준화되어서 결국 사람의 매력이 수주를 가른다는 것이고, 그 한 끗 차이로 계약이 성사된 실제 경험도 공유했다. 두 번째는 AI 세션에서 나온 두 가지다. 올해의 키워드는 '온톨로지'이며, 기계적으로 처리하는 것이 아니라 개념과 개념 사이의 관계를 이해하는 AI라는 설명이다. 그리고 "도메인 지식이 없으면 AX는 50%짜리밖에 안 된다"는 문장이다.

저자는 두 이야기를 같은 말로 읽는다. 도구가 평준화될수록 차이를 만드는 건 맥락을 아는 사람이라는 것이다. 이 결론은 위의 "AI 교육은 일하는 방식을 다시 짜는 시간"이라는 관찰, FDE 역량 정의에서 고객 문제 정의 능력이 AI 코딩과 나란히 필수라는 점, 그리고 아래 콘텐츠 섹션의 "레퍼런스 조합으로는 AI를 못 이긴다"와 정확히 같은 축을 향한다. 이 날 한국 LinkedIn에서 서로 다른 네 사람이 각기 다른 맥락에서 같은 진단에 도달했다. '온톨로지' 키워드는 앞서 나온 Infinitus 사례와도 붙는다. Neo4j Aura Enterprise를 보안 그래프 DB 레이어로 두고 복잡한 의료 규칙 그래프를 실시간 탐색하는 구조가 바로 개념과 개념 사이의 관계를 이해하는 AI의 구현체다.

실행 정보로서의 가치는 저자가 정리한 3단계 행사 준비법에 있다. 첫째, 가기 전에 가설 한 줄을 쓴다. 누구를 만나서 무엇을 만들고 싶은가를 문장으로 적는다. 둘째, 현장에서 교집합 한 문장을 만든다. 상대 회사와 우리 회사가 겹치는 지점을 그 자리에서 말로 만들어본다. 셋째, 돌아와서 24시간 안에 회사소개서와 구체적인 제안을 보낸다. 기억이 살아있을 때다. 저자가 실제로 바꾼 것은 이 중 첫 번째 하나뿐이었다. "BIGO Live와 함께 무언가를 만들 수 있는 회사를 찾는다"는 한 문장을 적어갔고, 그 결과 대화의 시작이 "무슨 일 하세요?"에서 "이거 저희랑 같이 해보면 어떨까요?"로 바뀌었다. 이번엔 게임, 뷰티, 결제까지 서로 다른 분야에서 대화가 이어졌고, 잘 풀린 대화의 공통점은 하나였다. 그 회사의 고객을 먼저 그려보고 갔다는 것이다.

AI 출력을 중계만 하는 전문가는 고객이 알아채는 순간 끝난다

X · @patrickc, X · @MatthewBerman, X · @svpino

세 글의 반응 크기는 작지만, AI 경제 논의의 세 층위인 수집, 낙관론, 현장 붕괴를 각각 대표한다.

Patrick Collison(Stripe 공동창업자)은 AI의 경제학에 대한 짧은 설문을 만들어 공개했다. 이름에서 알 수 있듯 향후 5년의 AI 경제 전망을 묻는 형태다. 좋아요 532, 댓글 63. 트윗 자체에는 설문 문항이 공개돼 있지 않으므로 지금 확정할 수 있는 건 Collison이 AI 경제 전망 설문을 열었다는 사실뿐이고, 결과가 공개되면 후속 추적 가치가 있다.

Matthew Berman이 인용한 발언은 AI 낙관론의 한 유형을 대표한다. "나에게 가장 흥미로운 것은 AI가 이 추세들을 되돌릴 수 있다는 점이다. 관료제를 뚫고 경제를 재활성화해서, 사람들이 시장에 대해 좋게 느끼고 따라서 더 친시장적이 되는 긍정적 피드백 루프로 돌아갈 만큼." AI를 생산성 도구가 아니라 제도적 마찰 제거 장치로 보는 관점이다. 트윗이 중간에서 잘려 있어 발언자가 명시되지 않았고 좋아요도 69에 그친다.

가장 구체적인 것은 svpino의 글이다. 유료로 전문가에게 질문하던 서비스에서, 전문가가 AI 답변을 그대로 전달하고 있다는 것을 알아챈 상황에 대한 반응이다. 그의 행동은 즉각적이었다. "나는 즉시 결제를 중단하고 내 모든 질문을 ChatGPT로 옮겼다." 그리고 예측을 덧붙인다. "이런 식으로 하는 전문가들은 고객을 좌우로 잃기 시작할 것이다. 사람들은 바보가 아니고, 무슨 일이 벌어지는지 알아채는 순간 AI에게 직접 물어볼 것이다." 이 짧은 글이 중요한 이유는 위의 두 사례, 즉 PwC 중동 법인의 환각 보고서 4건과 "AI 노트테이커 쓰지 말라"는 부사장 발언과 정확히 같은 실패 모드를 소비자 관점에서 보여주기 때문이다. 전문가 서비스의 가치는 정보 자체가 아니라 판단과 책임인데, AI 출력을 중계만 하는 순간 그 가치가 0이 되고 고객은 중간 단계를 건너뛴다.

엔터프라이즈의 질문이 "어떻게 만드나"에서 "어떻게 끄나"로 옮겨갔다

LinkedIn · Mak Ahmad, LinkedIn · Andy Brown, LinkedIn · Sailesh Krishnamurthy, LinkedIn · Google Cloud Partners

LinkedIn의 엔터프라이즈 AI 담론에서 이 날 가장 선명하게 반복된 문장은 "이제 만드는 게 문제가 아니다"였다.

Mak Ahmad의 정리가 가장 압축적이다. "AI 에이전트를 만드는 것은 day 1 연습이고, 엔터프라이즈 전체에 걸쳐 수백 개를 거버넌스하는 것은 day 2 현실이다." 그가 지목하는 실패 모드는 구체적이다. 각 부서가 서로 다른 권한 설정으로 고립된 에이전트를 각자 배포하면, 결과물은 통합 AI 전략이 아니라 shadow AI다. IT 부서가 모르는 사이에 조직 곳곳에 각기 다른 데이터 접근 권한을 가진 자동화가 생겨나는 상태다. 그가 꼽은 가장 어려운 세 가지 문제는 observability, access control, token management다. 그리고 이를 하나의 문장으로 정리한다. "프로덕션에서 에이전트가 어떻게 행동하는지 모니터링할 수 없거나, 그것이 환각을 일으키거나 과소비할 때 즉시 셧다운할 수 없다면, 당신이 가진 것은 제품이 아니라 책임(liability)이다." 토큰 관리가 관측성, 접근 통제와 같은 급의 문제로 올라온 것이 특징적이다. 에이전트가 무한 루프에 빠져 비용을 태우는 것을 실패 모드로 명시적으로 다루기 시작했다는 뜻이다. 그는 Build with Gemini tour의 Track 2(Platform Builders) 세션을 SF에서 8월 11일, NYC에서 8월 26일에 진행한다고 밝혔다.

거버넌스 논의의 두 번째 층위는 이사회다. Andy Brown(OpenAI)은 금요일 오후에 300명의 이사회 임원을 대상으로 AI 거버넌스를 이야기하러 갔다가, 대화의 대부분을 문화(culture)에 쓰게 됐다고 썼다. 그가 런칭 소식을 전한 것은 싱가포르 이사회 협회(Singapore Institute of Directors)가 OpenAI, Microsoft, IMDA와 공동 개발한 AI Guide for Boards다. Dr Ong Chen Hui, Jasmine Begum과의 대담에서 초점은 이사회가 경영진과 함께 혁신과 지속 학습의 문화를 어떻게 꽃피우게 하고 그것을 복리로 쌓이는 경쟁 우위로 만들 것인가였다. Josephine Teo 장관이 런칭에 참석했다. 정부, 빅테크, 이사회 협회가 함께 만든 가이드라는 조합 자체가 AI 거버넌스가 규제 이전에 이사회 문서 형태로 표준화되고 있음을 보여준다.

세 번째 층위는 플랫폼 통합이다. Sailesh Krishnamurthy는 Google Cloud와 Oracle의 파트너십 확대를 알리며, Oracle AI Agent Studio에 Gemini 모델이 네이티브로 제공된다고 밝혔다. 그가 강조한 표현은 "zero-latency context"로, 데이터가 있는 곳에서 모델이 바로 돌게 해 컨텍스트 전달 비용을 없앤다는 뜻이다. 엔터프라이즈 데이터가 Oracle에 있고 모델은 Google에 있는 기존 구도에서, 모델을 데이터 쪽으로 보내는 방향의 통합이다.

네 번째는 실제 배포 사례다. Google Cloud Partners가 소개한 Infinitus Systems는 의료 보험사와 의료기관 사이의 소통 문제를 다룬다. 이 영역은 길고 복잡한 규칙 세트와 끝없는 수동 전화 통화로 악명이 높다. Infinitus의 아키텍처는 Google Cloud와 Neo4j를 축으로 하고, Gemini Enterprise Agent Platform과 Gemini 2.5 Flash가 멀티모달 추론을, Neo4j Aura Enterprise가 보안 그래프 데이터베이스 레이어를 맡는다. 이 조합으로 복잡한 의료 규칙 그래프와 환자 속성을 실시간으로 탐색하는 음성 기반 AI 에이전트를 만들었고, 행정 병목을 지속적으로 학습하는 자동화 엔진으로 바꿨다고 설명한다.

AI 산출물의 양이 커뮤니티 규칙을 바꾸고 있다

AI 이야기를 걸러낸 Hacker News, 2주 만에 필터 400개

Hacker News · hcker.news

hcker.news는 Hacker News 피드에서 AI 관련 항목을 제거해 보여주는 미러다. 만든 이유는 단순하다. 프런트 페이지가 AI 이야기로 덮여 다른 주제를 읽기 어려워졌다는 것이다.

구현은 3단계다. 1단계로 키워드와 도메인으로 거르고, 2단계로 에이전트가 항목을 읽어 판정하고, 3단계로 사람이 애매한 것을 결정한다. GitHub 저장소가 올라오면 커밋 메시지, 기여자 목록, 설정 파일에서 에이전트가 작성한 흔적을 찾아 분류한다.

흥미로운 건 운영 통계다. 2주 만에 키워드 필터 146개, 도메인 필터 101개, 개별 URL 약 400개가 쌓였다. 규칙 기반으로 시작했지만 예외가 계속 나와서 결국 개별 항목을 손으로 지정하는 방식으로 수렴했다는 뜻이다. AI 관련 여부라는 게 자동으로 판정하기 생각보다 어려운 속성이라는 증거이기도 하다. 도메인이나 키워드로 잡히지 않는 경우가 많은 이유는 분명하다. AI를 소재로 다루지 않으면서 AI로 만들어진 글이 있고, 반대로 AI를 다루지만 걸러낼 이유가 없는 기술 문서도 있다. 필터가 판정해야 하는 건 주제가 아니라 생산 방식인데 그 둘이 텍스트 표면에서 잘 구분되지 않는다.

이 프로젝트가 흥미로운 지점은 도구 자체보다 수요다. HN에서 39점밖에 못 받았지만, 같은 날 GeekNews에는 Codeberg가 대부분 생성형 AI로 만들어진 프로젝트를 금지했다는 소식이 올라와 있다. 한쪽은 읽는 쪽에서 걸러내고 다른 쪽은 받는 쪽에서 막는다. 같은 날 Cloudflare의 서빙 글 댓글에서 "이 글 자체가 LLM으로 쓰였다"는 지적이 최상위로 올라간 것도 같은 현상이다. 내용의 정확성과 별개로 누가 썼는가가 읽기 전에 판단해야 할 항목이 됐다.

GitHub의 대안은 있는데 대체재는 없다

GeekNews · Shelley(exe.dev)

Codeberg가 대부분 생성형 AI로 만들어진 프로젝트를 받지 않기로 하면서 "GitHub 말고 어디로 갈 것인가" 논의가 다시 불붙었다. 이 글은 대안 목록을 나열하는 대신 왜 그 목록 중 어느 것도 실제 이주로 이어지지 않는지를 따진다.

먼저 GitHub 쪽 불만은 실체가 있다. 두 차례 장애 뒤 회사 스스로 "허용 가능하지 않다"는 제목의 글을 냈고, 개발자들이 몇 년째 요구한 스택 PR은 2026-07-30에야 공개 프리뷰에 도달했으며 그마저 버그가 있다. Ghostty는 약 2시간짜리 Actions 장애 후 GitHub을 떠났다. Mitchell Hashimoto의 진단이 정확하다. 문제는 Git이 아니라 그 주변 인프라다. 코드 자체는 분산 저장소로 어디든 옮길 수 있지만, CI와 이슈와 리뷰는 그렇지 않다.

대안 평가는 냉정하다. GitLab은 개인 개발자에게 지나치게 기업향이고, SourceHut은 이메일 기반 워크플로와 암호화폐 금지 정책이 진입 장벽이며, Forgejo의 연합 기능은 아직 실험 단계다. Radicle은 버그 하나 신고하려고 CLI를 설치해야 하고, Tangled는 알파다. 기술적으로 더 나은 선택지는 여럿인데 사회적 계층이 없다는 게 공통점이다.

이 글의 핵심 주장이 거기 있다. GitHub의 진짜 제품은 저장소 호스팅이 아니라 사람들이 모여 있다는 사실이다. 이슈에 낯선 사람이 답하고, 프로필이 이력서 역할을 하고, 스타 수가 신뢰 신호가 되는 그 층위를 대체하지 못하면 이주는 개인 백업 이상의 의미를 갖지 못한다. 제안도 있다. 화려한 기능 경쟁 대신 "의도적으로 지루한 회사"가 필요하다는 것이고, 예로 bunny.net을 든다. 인수되지 않고 방향을 자주 바꾸지 않으며 지루하게 잘 도는 회사 말이다. 반면교사로는 Bitbucket을 든다. 한때 실제 대안이었으나 방향을 잃고 사라진 사례다.

도구의 통제권: 소스, 플랫폼, 배포 형식

소스 코드가 곧 확장 시스템이다

코딩 에이전트를 매일 쓰는 사람 입장에서 오픈소스 여부가 왜 중요한지를 구체적 사례로 설명한 글이다. 추상적 자유 논의가 아니라 "내가 원하는 동작을 오늘 넣을 수 있는가"라는 질문이다.

저자가 든 사례는 두 개의 프롬프트다. 하나는 도구를 소스에서 빌드하게 만든 것이고, 다른 하나는 매일 밤 상류 변경을 리베이스하는 cron을 붙인 것이다. 이 둘을 해두면 자기가 고친 부분을 유지하면서 상류 업데이트를 계속 따라갈 수 있다. 포크를 뜨고 방치하는 흔한 실패를 자동화로 막은 셈이다. 두 번째 사례가 더 직접적이다. meat.dev의 diff 최소화 기능을 자기 도구에 넣고 싶었고, 프롬프트 한 번으로 통합했다. 폐쇄 도구였다면 기능 요청을 올리고 기다리는 것 외에 방법이 없는 종류의 변경이다.

비교는 이름을 대고 한다. Codex와 Pi는 오픈소스라서 원하는 대로 고칠 수 있고, Claude Code는 폐쇄라서 제공된 훅이 허용하는 범위 안에서만 확장할 수 있다. 훅 자체가 없는 동작은 손댈 수 없다. 여기서 나오는 문장이 "소스 코드가 곧 확장 시스템이다"다. 플러그인 API를 아무리 잘 설계해도 저자가 예상한 확장만 가능하고, 소스가 열려 있으면 예상 밖의 확장이 가능하다. 이 주장이 지금 힘을 받는 이유는 AI 자체다. 예전에는 소스가 열려 있어도 대규모 코드베이스를 고칠 여력이 없는 사람이 대부분이었다. 이제 프롬프트 하나로 그 벽이 낮아졌으므로 오픈소스라는 속성의 실질 가치가 올라갔다.

SwiftUI 7년: 애플 자체 튜토리얼의 사이드바가 2년 넘게 고장 나 있다

GeekNews · 회고 글

SwiftUI는 2019년에 발표됐다. 7년이 지난 시점에서 실무자가 쓴 이 회고는 감상이 아니라 구체적 증거를 나열한다. 가장 상징적인 건 애플이 직접 제공하는 Landmarks macOS 튜토리얼의 사이드바가 2년 넘게 깨진 채 방치돼 있다는 사실이다. 프레임워크 제작사의 공식 예제가 그 상태라는 점이 나머지 지적의 신뢰도를 떠받친다.

두 번째 문제는 상태 관리의 이력이다. @State, @Binding, ObservedObject 체계를 익히고 나니 Observation과 @Observable로 갈아엎였다. 마이그레이션이 아니라 재학습이다. 디버깅 도구도 부실해서, 뷰가 왜 다시 그려지는지 보려면 Self._printChanges()를 써야 하는데 문서화돼 있지 않고 알려주는 정보도 불완전하다. 레이아웃 쪽에서는 GeometryReader를 두고 "패배 선언"이라는 평가가 나온다. 선언적 레이아웃 시스템으로 해결하지 못한 케이스를 명령형으로 우회하는 탈출구인데, 실무에서는 이 탈출구가 계속 필요하다.

플랫폼 최소 버전 문제도 크다. scrollDismissesKeyboard는 iOS 16, AsyncImage는 iOS 15가 필요하고, AsyncImage의 요청과 캐시 API는 2026년 7월 기준 아직 베타다. 즉 기능 하나를 쓰려면 지원 대상 기기를 잘라내야 한다. 여기서 Jetpack Compose와의 비교가 나온다. Compose는 OS가 아니라 의존성으로 배포되므로 2014년 기기에서도 최신 API를 쓸 수 있다. NavigationView가 고쳐지지 않고 NavigationStack으로 교체된 것도 같은 맥락의 불신을 만든다. 성능 지적은 더 직접적이다. 배경 디코딩까지 넣어도 UIKit으로 만든 이미지 갤러리가 SwiftUI보다 부드럽게 스크롤된다. 저자는 Catalyst와 Marzipan으로 이어지는 계보를 짚으며 지금도 AppKit과 UIKit을 선호한다고 밝힌다. 글을 요약하는 문장은 애플의 표어를 비튼 것이다. "한 번 배우고, 두 번 배우고, 어딘가에 적용하고, 어디서나 디버깅한다."

Google이 RSS 확산을 무너뜨린 20년의 기록

GeekNews · openrss.org

RSS가 왜 주류에서 밀려났는가에 대해, 이 글은 사용자 취향이 변했다는 설명 대신 한 회사의 결정 목록을 시간순으로 늘어놓는다. 2023년에 쓰인 글이지만 오늘 GitHub 대안 논의와 같이 올라오면서 다시 읽히고 있다.

시작은 브라우저다. Chromium에서 RSS 버튼이 공지 없이 사라졌다. 피드를 발견하는 가장 흔한 경로가 없어지면 사이트가 피드를 제공해도 사용자는 그 존재를 모른다. 2021년 5월 Chrome이 RSS 관련 실험을 하긴 했지만 정식 출시되지 않았다. Chrome용 RSS 확장이 제거됐다가 일주일 만에 "실수"라며 복원된 일도 있다.

두 번째는 배포 인프라다. Google은 2007년 FeedBurner를 인수했다. 당시 블로그 피드 배포의 사실상 표준이었다. 2012년 10월 API가 종료됐고 2022년 7월에는 대부분의 기능이 제거됐다. 인수 후 15년에 걸쳐 서서히 껍데기만 남긴 과정이다.

세 번째가 가장 널리 기억되는 Google Reader다. 2005년부터 2013년까지 운영됐고 종료 명분은 "사용량 감소"였다. 그런데 담당 엔지니어의 회고는 다르다. 프로젝트에 있는 내내 여러 사람이 이걸 죽이려 했다는 것이다. 사용자가 떠나서 닫은 게 아니라 사내에서 계속 밀려났다는 이야기다. 같은 해 7월 Google Alerts의 RSS 출력도 제거됐다가 반발로 복원됐고, Google News RSS는 2017년 12월 완전히 종료됐다.

글의 결론은 임베이스, 익스텐드, 익스팅귀시 구도다. 표준을 받아들여 지배적 위치를 차지한 뒤 그 위치에서 손을 떼면 표준 자체가 약해진다. 의도적인 계획이었는지는 이 글이 증명하지 못하지만, 결과만 놓고 보면 발견 경로, 배포 인프라, 소비 도구가 차례로 사라진 것은 사실이다. 바로 위 GitHub 대안 논의에서 나온 결론과 겹치는 지점이 있다. 기술 표준은 열려 있어도 그 위의 사회적 계층과 기본 진입점을 한 회사가 쥐고 있으면 종속은 유지된다.

작은 블로그 호스팅 3종, 셋 다 버스 팩터 1

GeekNews · indiebizOS 프로젝트

플랫폼에 글을 올리는 대신 자기 사이트를 갖자는 이야기는 오래됐지만, 실제로 어디에 둘 것인가는 별개의 문제다. 이 글은 작은 블로그 호스팅 세 곳을 실제 가격과 정책 수준에서 비교한다.

Mataroa는 무료이거나 연 9달러다. 자체 댓글 기능을 제공한다는 점이 특징이다. 외부 댓글 서비스를 붙이면 추적 스크립트가 따라 들어오는데 그 문제를 피할 수 있다. Pagecord는 무료이거나 연 39달러이고 YouTube 임베드를 지원한다. 이 서비스가 내세우는 "AI 없음"이라는 문구의 뜻이 명확히 짚여 있다. AI로 만든 글을 거부한다는 게 아니라, 서비스에 AI 기능을 넣지 않겠다는 뜻이다. 요즘 어느 도구에나 붙는 요약과 자동 작성 기능을 넣지 않겠다는 선언이다.

Bear는 무료, 연 49달러, 또는 1회 189달러의 평생 요금제를 제공한다. LaTeX를 지원하고 이모지를 파비콘으로 쓸 수 있다. 운영 정책이 흥미로운데, 무료 블로그는 기본적으로 검색 엔진에서 숨긴다. 이유는 신규 블로그의 30%가 스팸이기 때문이다. 정상적인 사용자는 수동 검토를 요청해 노출시킬 수 있다. 무료 티어를 유지하면서 스팸을 통제하는 현실적 절충이다. 이미지 호스팅으로는 PixelUnion과 Immich가 15GB까지 무료라는 언급이 있고, 원칙으로는 POSSE, 즉 자기 사이트에 먼저 올리고 다른 플랫폼에 배포하는 방식을 든다.

글이 스스로 밝히는 약점이 중요하다. 세 서비스 모두 버스 팩터가 1이다. 운영자 한 사람이 그만두면 서비스가 사라진다. 플랫폼 종속을 피하려고 옮겨간 곳이 더 취약할 수 있다는 뜻이라, 자기 도메인을 쓰고 데이터를 내보낼 수 있는지가 선택 기준이 된다. 비교에서 Pika(글 50개 제한)와 Pico.sh의 prose는 빠졌다.

Bear의 30% 스팸 통계는 이 섹션 밖의 이야기와도 붙는다. 오늘 다른 항목에서 Hacker News 미러 운영자가 2주 만에 개별 URL 400개를 손으로 지정하는 상태에 도달했고, Codeberg는 대부분 생성형 AI로 만든 프로젝트를 받지 않기로 했다. 세 사례 모두 자동 생성 콘텐츠의 양이 서비스 운영 정책을 먼저 바꾸는 구조다. 그리고 셋 다 최종적으로는 사람의 수동 판정에 의존한다. Bear는 무료 블로그를 기본 비노출로 두고 요청이 오면 사람이 검토하고, 미러는 애매한 항목을 사람이 결정하며, Codeberg의 판정도 자동화돼 있지 않다. 개인 운영자가 지탱하는 서비스에서 이 판정 부담은 그대로 버스 팩터 문제로 되돌아온다.

웹앱이 AI 시대의 배포 형식이 되는 이유

AI로 만드는 소프트웨어가 늘어나면 그것을 어떤 형식으로 배포할 것인가라는 질문이 따라온다. 이 글은 답을 웹앱으로 놓는다.

첫 번째 근거는 갱신 주기다. 네이티브 앱은 스토어 심사와 사용자의 업데이트 행위를 거쳐야 새 버전이 도달한다. AI를 붙인 기능은 모델 교체와 프롬프트 조정이 잦은데, 이 주기와 스토어 심사 주기가 맞지 않는다. 웹앱은 한 번 배포하면 모든 기기에서 다음 접속부터 새 버전이다. 두 번째 근거는 누적이다. 기능을 하나씩 만들어 붙일 때 앱을 계속 새로 내는 대신 한 앱 안에 쌓아 올릴 수 있다. 글은 이를 슈퍼앱 성격이라 표현한다. 개인이나 소규모 팀이 만드는 도구일수록 사용자에게 새 앱을 설치시키는 비용이 크므로, 이미 열려 있는 곳에 기능을 얹는 쪽이 유리하다는 논리다.

이 주장에 반대할 여지는 있다. 오프라인 동작, OS 통합, 성능이 중요한 영역에서는 여전히 네이티브가 필요하고, 브라우저 안에서 접근할 수 없는 API도 많다. 글은 그 경계를 정밀하게 다루지는 않는다. 그럼에도 바로 위 SwiftUI 회고와 함께 놓으면 흐름이 보인다. 플랫폼 프레임워크는 OS 버전에 묶여 최신 기능이 구형 기기에 닿지 않는 반면 Jetpack Compose는 라이브러리로 배포돼 2014년 기기까지 커버한다. 웹은 그 방향의 극단이다. 배포 경로를 누가 통제하는가라는 같은 질문의 다른 답이다. 저자는 이 생각을 indiebizOS라는 프로젝트로 구체화하고 있다고 밝힌다.

Next.js 16.3: 개발 모드 메모리 최대 90% 절감, 하이라이트에 에이전트 툴링

X · @nextjs

이 날 SNS에서 유일한 메이저 프레임워크 릴리스 공지다. Next.js 16.3이 정식 출시됐고, 공식 계정이 밝힌 변경 사항은 다섯 가지다.

가장 눈에 띄는 수치는 개발 모드 메모리 사용량 최대 90% 감소다. 대규모 Next.js 프로젝트에서 next dev 프로세스가 수 GB를 먹으며 로컬 머신을 잡아먹는 것은 오래된 불만이었다. 90%라는 수치는 "up to" 조건부이므로 프로젝트 규모와 구성에 따라 실제 개선폭은 달라지지만, 절감의 방향과 크기를 공식 계정이 앞세웠다는 것은 이번 릴리스의 주력 개선이 런타임 성능이 아니라 개발 경험이라는 뜻이다. 빌드, 타입 체크, 렌더링 속도 개선도 같은 축에 있다.

두 번째로 주목할 항목은 AI 에이전트를 위한 개선된 툴링(Better tooling for AI agents)이다. 프레임워크 릴리스 노트의 최상위 다섯 항목에 에이전트 지원이 들어간다는 것 자체가 오늘의 다른 흐름과 맞물린다. 코딩 에이전트가 프레임워크를 다루는 것이 예외적 사용 사례가 아니라 프레임워크가 1급으로 대응해야 할 대상이 됐다는 신호다. 나머지는 개발자 제어권 관련이다. 커스텀 에러 바운더리는 에러 처리 UI를 앱 단위로 직접 정의할 수 있게 하고, Instant Navigations는 페이지 이동 반응성을 SPA 수준으로 끌어올린다. 구체적 벤치마크 수치와 마이그레이션 주의사항은 공식 릴리스 노트에 있고 트윗에는 요약만 있다. 좋아요 944, 댓글 44.

오래 사는 소프트웨어

Pandoc 20년: 3,876가지 변환 조합, 그리고 LLM 변환에 대한 반론

Hacker News · pandoc.org

Pandoc의 첫 업로드가 2006년 8월 3일이었다. 당시 약 3,000줄짜리 Haskell 프로그램이었고, 20년이 지난 지금은 입력 51개 형식과 출력 76개 형식을 지원해 3,876가지 변환 조합을 만든다. 핵심 패키지 4개를 합쳐 85,684줄이고 의존성까지 포함하면 대략 두 배다.

John MacFarlane이 정리한 숫자 중에는 유지보수의 규모를 보여주는 것도 있다. 해결된 이슈가 7,346건이고 기여자는 600명이 넘는다. 줄 수 기준으로 MacFarlane이 372,317줄, Krewinkel이 77,136줄, Rosenthal이 39,664줄을 남겼다. 한 사람이 압도적으로 많이 썼지만 혼자 만든 프로젝트는 아니라는 분포다. 역사적 일화도 있다. 2018년 Handshake로부터 $100,000을 기부받았고, Markdown 표준화 작업 때는 Gruber가 "Standard Markdown"이라는 이름에 반대해 결국 commonmark가 됐다.

최신 버전 이야기도 흥미롭다. 2026년 2월 나온 pandoc 3.9는 WASM으로 컴파일돼 브라우저에서 돌아가고, 새 GUI는 Claude Opus의 도움을 받아 설계했다고 밝혔다. 20년 된 프로젝트가 LLM을 개발 과정에 들여놓았다는 사실을 저자가 직접 적었다는 게 이 문단의 무게다. 그러고 나서 반론이 나온다. 문서 변환 자체를 LLM에 맡기는 것에 대해서는 회의적이다. 이유는 세 가지다. 에너지 소모, 같은 입력에 같은 출력이 나오는 결정론, 그리고 신뢰성이다. 표 하나를 변환하는 데 GPU를 돌릴 필요가 없고, 어제와 오늘의 결과가 달라지면 파이프라인이 성립하지 않는다. 도구를 만드는 데는 LLM을 쓰되 도구가 하는 일은 LLM에 맡기지 않는다는 구분이 명확하다. HN 82점.

Kermit 45년: 15년 만의 릴리스가 코드를 줄여서 나왔다

Hacker News · complete.org

Kermit은 1981년 컬럼비아 대학에서 Frank da Cruz와 Bill Catchings가 설계한 파일 전송 프로토콜이다. 45년이 지나 C-Kermit 11이 나왔는데, 이건 15년 만의 첫 릴리스다. 2011년 BSD 라이선스로 오픈소스화된 이후 사실상 멈춰 있던 프로젝트가 다시 움직였다.

작업을 맡은 John Goerzen이 넣은 것들은 현대화 목록에 가깝다. IPv6 지원, 보안 수정, 약 2,000개의 테스트 케이스, 그리고 CI다. CI 대상 플랫폼이 Linux x86_64와 arm64, macOS, FreeBSD, NetBSD, OpenBSD에 musl 정적 빌드까지 포함한다. 45년 된 C 코드베이스에 이 정도 매트릭스를 붙였다는 것 자체가 작업량을 말해준다.

가장 눈에 띄는 대목은 결과다. 이 모든 추가에도 불구하고 전체 코드 줄 수가 이전보다 줄었다. 오래된 플랫폼 지원 코드와 중복을 걷어낸 결과다. 기능을 더하면 코드가 늘어난다는 게 기본값인데 반대 방향으로 갔다. 프로젝트는 Open Kermit이라는 이름으로 이어지고, 릴리스는 da Cruz가 이 프로젝트에 쏟은 44년에 헌정됐다. HN에서 119점을 받았는데, 지금 Kermit을 실제로 쓰는 사람보다 이런 유지보수 자체에 반응한 사람이 많았다고 보는 게 맞을 것이다. 바로 위 Pandoc 회고와 붙여 읽으면 대비가 선명하다. 한쪽은 20년간 한 사람이 계속 끌어온 프로젝트이고, 다른 쪽은 45년 된 코드베이스를 다른 사람이 이어받아 다시 굴린 사례다. 소프트웨어를 오래 살리는 방법이 하나가 아니라는 이야기다.

언어, 런타임, 그리고 빌드 비용

Rust 1.98의 대수적 부동소수점 연산자: 594µs가 144µs가 됐다

GeekNews · 벤치마크 글

부동소수점 덧셈은 결합법칙이 성립하지 않는다. 그래서 컴파일러는 순서를 바꾸는 최적화를 할 수 없고, 결과적으로 SIMD 벡터화가 막힌다. Rust 1.98이 도입하는 대수적 부동소수점 연산자는 이 제약을 프로그래머가 명시적으로 풀어주는 장치다. 릴리스는 2026-08-20 예정이고 이 글은 베타에서 측정했다.

기준선부터 명확하다. -C target-cpu=x86-64-v3 플래그로 컴파일했을 때 정수 합은 151.9µs에 명령 521,214개, SIMD 정수 연산 250,003개가 나온다. 같은 데이터의 순진한 f64 합은 595.2µs, 명령 1,458,269개인데 SIMD 부동소수점 연산은 0개다. 벡터화가 전혀 안 됐다는 뜻이고, 4배 가까운 차이가 여기서 나온다. 새 연산자로 pairwise 합을 구현하면 144.5µs가 나온다. 명령 수 1,298,028개에 SIMD 부동소수점 연산 270,336개다. 정수 합 151.9µs보다도 빠르다. 비교 대상인 NumPy의 np.sum은 190.7µs, 순진한 구현은 563.1µs다.

속도만 얻은 게 아니라 정확도도 좋아졌다. math.fsum 기준 오차가 순진한 합에서 -1,000,000.0인데, np.sum은 -14.0, pairwise_sum은 -6.0이다. 순차 누적이 오차를 키우는 구조라 짝지어 더하는 쪽이 빠르면서 동시에 정확하다. 임계값 128을 쓴 것도 NumPy와 같다. 두 번째 예제는 제곱합 계산이다. ssd_normal이 628.7µs에 값당 4.5명령인데, 최적화 버전은 371.1µs에 값당 1.0명령이다. 결과는 166770.0055951995와 166770.00559520238로 마지막 자리에서만 갈린다.

글이 강조하는 실무 주의사항이 있다. 엄격한 연산자와 관대한 연산자가 둘 다 필요하다는 것이다. 전부 관대하게 두면 위의 pairwise 알고리즘 자체가 "그냥 다 더한 것"으로 최적화되어 사라진다. 정확도를 위해 일부러 만든 구조를 컴파일러가 지워버리는 것이다. 어디를 풀고 어디를 잠글지는 사람이 정해야 한다.

C의 sizeof가 파싱하기 어려운 이유: `sizeof(int){0}`은 합법이다

GeekNews · 문법 분석 글

C 컴파일러를 직접 만들어 본 사람이 부딪히는 문법 함정을 정리한 글이다. 표면적으로 sizeof는 간단해 보인다. 실제로는 피연산자가 두 종류다. 단항 표현식이거나, 괄호로 감싼 타입 이름이다. 파서는 여는 괄호를 만난 시점에 둘 중 무엇인지 알 수 없다.

첫 번째 함정은 복합 리터럴이다. sizeof(int){0}은 유효한 코드다. 여기서 (int){0}은 타입 캐스트가 아니라 int형 복합 리터럴 객체이고, sizeof는 그 객체의 크기를 잰다. 즉 괄호 뒤에 {가 오면 앞의 괄호가 타입 이름이 아니라 표현식의 일부였던 것으로 판정이 뒤집힌다. 여기서 끝이 아니다. sizeof(T){}.x[0]()처럼 복합 리터럴 뒤에 멤버 접근, 배열 첨자, 함수 호출 같은 후위 연산자를 임의로 이어붙일 수 있다. 파서는 어디까지가 sizeof의 피연산자인지 판정하려면 후위 연산자 사슬을 전부 따라가야 한다.

반대 방향 함정도 있다. sizeof(int)+1은 int로 캐스트한 무언가의 크기가 아니라, sizeof(int)에 1을 더한 것이다. 여는 괄호 다음이 타입이고 닫는 괄호 다음이 단항 연산자 겸 이항 연산자인 +일 때 어느 쪽으로 읽을지가 갈리는데, 여기서는 타입 이름 해석이 우선이라 덧셈이 된다. 같은 문제는 새로 들어오는 문법에도 그대로 옮겨간다. C2y의 _Countof가 같은 형태의 피연산자 규칙을 쓰기 때문이다. 언어에 연산자를 하나 더할 때 기존 문법의 모호성이 함께 복제된다는 사례다.

Bonsai: 증분 계산을 뷰가 아니라 모든 값에 적용한 OCaml UI

블로그 · Jane Street

Jane Street가 사내에서 쓰는 OCaml UI 라이브러리 Bonsai가 공개 문서와 함께 소개됐다. 설계 출발점은 Elm이다. UI를 순수 함수형 상태 기계로 표현하고, 상태 변화를 명시적인 메시지로 다룬다.

Elm과 갈라지는 지점은 증분 계산의 적용 범위다. 보통의 프레임워크는 뷰를 다시 그릴 때만 변경분을 따진다. Bonsai는 그 개념을 모든 값에 적용한다. 중간 계산 결과도 입력이 바뀐 부분만 다시 계산된다. 대량의 실시간 데이터를 다루는 트레이딩 화면에서 나올 법한 요구다.

두 번째 특징은 타입 공유다. 프런트엔드와 백엔드가 같은 OCaml 타입을 쓴다. 서버가 보내는 구조와 클라이언트가 기대하는 구조가 어긋나면 컴파일 단계에서 걸린다. 자바스크립트 생태계에서 스키마 검증 도구로 해결하는 문제를 언어 차원에서 없앤 셈이다. 테스트 방식도 특이하다. expect test에 DOM diff를 포함시킨다. 컴포넌트를 조작한 뒤 DOM이 어떻게 달라졌는지를 텍스트 diff로 스냅샷에 남긴다. 스크린샷 비교보다 읽기 쉽고 리뷰에서 변경 의도를 확인하기 좋다.

배포 형태는 여럿이다. 브라우저용 Bonsai_web과 터미널용 Bonsai_term이 있다. Bonsai_vr도 있는데 이건 만우절 농담이다. 문법 확장은 ppx_html과 ppx_css를 쓴다. 위의 SwiftUI 7년 회고와 나란히 보면, 선언적 UI라는 같은 목표를 두고 한쪽은 플랫폼 프레임워크로, 다른 쪽은 언어 기능 위에서 푸는 대비가 드러난다.

Rust 메타 검색 엔진, 그리고 댓글에 나타난 Searx 원저자

SearXNG는 여러 검색 엔진의 결과를 모아 보여주는 메타 검색 엔진이고 Python으로 만들어졌다. metadata-search-engine-rs는 같은 개념을 Rust로 구현한 프로젝트다.

구조는 단순하다. DuckDuckGo, Brave, Startpage, Yahoo를 reqwest로 동시에 호출하고, 응답 HTML을 html5ever 기반 scraper로 파싱한다. 결과 병합 전에 URL을 정규화해 같은 페이지가 다른 형태로 중복 집계되는 걸 막는다. 순위 병합에는 Reciprocal Rank Fusion을 쓴다. 공식은 score = Σ 1/(60 + rank)다. 각 엔진에서의 순위 역수를 더하는 방식이라 점수 체계가 다른 엔진들을 정규화 없이 섞을 수 있다. 상수 60은 상위권 결과가 지나치게 지배하지 않도록 완충하는 역할이다. 여러 소스의 순위를 합칠 때 널리 쓰이는 기법이고, 검색뿐 아니라 RAG 파이프라인에서도 같은 공식이 등장한다.

인터페이스는 ratatui 기반 TUI를 별도 크레이트로 분리했다. 코어 검색 로직과 표시 계층을 나눠 다른 프런트엔드를 붙일 수 있게 한 구성이다. 이 스레드에서 가장 재미있는 부분은 댓글이다. Searx의 원저자 asciimoo가 나타나 자기가 지금 만들고 있는 새 프로젝트 Hister를 소개했다. 자기 프로젝트를 다시 만든 사람의 글 아래에 원저자가 등장하는 상황인데, 분위기는 우호적이었다. HN 56점.

Kakehashi: 5배 느려도 macOS 러너보다 싸다

GeekNews · 프로젝트 소개

Kakehashi는 macOS ARM64용으로 빌드된 Mach-O 바이너리를 Linux aarch64에서 실행하는 도구다. 유저스페이스에서 시스템 콜을 번역하는 방식이고 JIT은 쓰지 않는다. 같은 CPU 아키텍처이므로 명령어를 다시 번역할 필요가 없고, 운영체제 인터페이스만 맞춰주면 된다는 발상이다. 검증된 범위는 아직 좁다. Darwin용 7zz와 curl을 Docker/Colima 환경과 UTM에서 돌리는 데 성공했다고 밝히고, 다음 목표는 Command Line Tools의 git이다.

성능 수치는 정직하게 나쁘다. 약 8,000개 파일 240MiB를 다루는 작업에서 네이티브 7zz가 약 22.5초, kh를 거치면 약 118초로 5.2배 느리다. 다만 파일 수가 적고 압축 계산이 무거운 작업은 1.1-1.2배 차이에 그친다. 느려지는 원인이 계산이 아니라 파일 시스템 호출 번역에 있다는 뜻이다.

그런데 이 프로젝트의 논거는 속도가 아니라 요금표다. GitHub Actions는 Linux 2코어 arm64가 분당 $0.005, macOS 3-4코어가 분당 $0.062다. 10배에서 12배 차이다. 5배 느려도 5분치 Linux 요금이 $0.025로 macOS 1분치 $0.062보다 싸다. macOS 러너를 못 구해 대기하는 시간까지 감안하면 격차는 더 벌어진다. 구현 면에서 밝힌 사실 하나는 Darling에서 파생되지 않았다는 점이다. 기존 프로젝트의 코드를 가져오지 않고 독자적으로 만들었고 라이선스는 Apache 2.0이다. 지금 상태로 실무에 넣기는 이르지만, "macOS 도구를 쓰려면 macOS를 빌려야 한다"는 전제를 깨는 방향이라는 점에서 CI 비용 구조에 영향을 줄 수 있다.

반복 작업은 어디에 둘 것인가: bash, make, just, mise

프로젝트마다 반복하는 명령을 어디에 둘 것인가에 대한 정리 글이다. 새로운 도구를 소개하기보다 네 단계를 순서대로 짚고 각 단계에서 무엇이 부족해지는지를 설명한다.

가장 단순한 답은 bash 스크립트 하나다. run이라는 파일에 서브커맨드를 나열하는 방식인데, 의존성이 없고 어디서나 돌아간다. 팀에 새 도구를 설치시키지 않아도 되는 게 최대 장점이고, 명령이 늘어나면서 인자 파싱과 도움말이 지저분해지는 게 한계다. 두 번째는 Make다. 오래됐고 어디에나 있지만 함정이 둘 있다. 파일을 만들지 않는 타깃에 .PHONY를 붙이지 않으면 같은 이름의 파일이 생기는 순간 동작이 멈추고, 들여쓰기가 반드시 탭이어야 한다. 빌드 시스템으로 만들어진 도구를 명령 모음으로 쓰기 때문에 생기는 마찰이다.

세 번째가 just다. Make의 문법을 닮았지만 빌드 의존성 개념을 버리고 명령 실행에 집중했다. 탭 문제도 없고 인자 전달이 자연스럽다. 반대로 말하면 도구 설치가 필요하다. 네 번째는 mise다. 태스크 실행에 더해 런타임 버전 관리와 환경 변수까지 묶는다. mise.local.toml로 개인 설정을 분리할 수 있고 시크릿은 fnox를 통해 다룬다. 명령 정의와 실행 환경을 한 파일에서 관리하려는 조직에 맞는 선택이다. 결론은 도구 서열이 아니라 조건이다. 팀에 아무것도 설치시킬 수 없으면 bash, 이미 Make가 있으면 Make, 명령 정의가 주 목적이면 just, 런타임과 환경까지 통합하려면 mise다. HN 64점.

이 정리가 지금 다시 읽히는 이유가 하나 있다. 에이전트에게 프로젝트 작업을 맡기면 가장 먼저 필요한 것이 "이 저장소에서 무엇을 어떻게 실행하는가"의 단일 진입점이다. 명령이 README 산문 안에 흩어져 있으면 에이전트가 매번 추론해야 하고, 태스크 파일 하나에 모여 있으면 목록을 읽고 고르면 된다. 바로 위 Kakehashi 항목이 CI 요금표를 근거로 실행 위치를 바꾸자고 말하는 것과 같은 층위의 이야기다. 반복 명령을 어디에 두느냐는 개인 취향 문제로 보이지만, 실행 주체가 사람에서 에이전트로 섞이기 시작하면 그 선택이 자동화 가능 범위를 정한다.

2002년 아이테니엄용 Windows XP를 QEMU에서 설치했다

LinkedIn · Sanghwan Yang, LinkedIn · Minjoo Song

인텔의 아이테니엄은 상업적으로 실패한 아키텍처이고, 그 위에서 돌던 Windows XP 64비트 에디션은 실물 하드웨어를 구하기가 거의 불가능하다. makuhlmann이 QEMU의 merced 브랜치를 포크해 이 조합을 에뮬레이션으로 되살렸다.

빌드 과정 자체가 고고학에 가깝다. ia64-linux-gnu 크로스 툴체인을 binutils 2.46.0과 GCC 15.3.0으로 구성했고, zlib에서는 fdopen과 관련한 140행 부분을 우회해야 했다. 2026년의 툴체인으로 2002년 대상 아키텍처를 빌드하려니 중간의 20년이 그대로 마찰이 된다. 결과는 구체적이다. XP 빌드 2600이 M4 맥 미니에서 약 30분에서 40분 만에 설치된다. 이전 시도에서는 다섯 번 만에 겨우 성공했는데 이번에는 한 번에 됐다. Windows Server 2003과 빌드 5.1.2462도 설치에 성공했다.

이 스레드에서 가장 읽을 만한 부분은 댓글이다. 아이테니엄이 왜 실패했는가를 두고 흔히 컴파일러가 명령어 병렬성을 충분히 뽑아내지 못했다는 설명이 쓰인다. monocasa는 다른 진단을 내놓는다. 문제는 컴파일러가 아니라 설계 전제였다는 것이다. 아이테니엄은 데나드 스케일링이 계속되어 클록이 계속 올라가는 세계를 가정하고 만들어졌는데, 그 전제가 무너지면서 정적 스케줄링에 걸었던 판돈이 사라졌다. 실패한 아키텍처를 회고할 때 기술적 실행보다 전제 검증이 중요하다는 이야기다. HN 36점.

만드는 사람들: 시장 검증과 창업 생태계

심사위원을 없애고 매출로만 겨룬 30시간, 1등은 회사를 팔았다

YouTube · EO Korea

이 해커톤의 규칙 자체가 영상의 핵심이다. 통상적인 해커톤은 심사위원 앞에서 발표하고 평가받지만, "흑백개발자 THE 해커톤"은 심사위원을 아예 없앴다. 한 참가자의 표현으로는 "원래 해커톤은 심사위원을 대상으로 주제가 주어져서 오히려 쉬웠는데, 정답 없이 정답을 찾아 나가는 과정은 쉽지만은 않다."

점수 구조는 매출 80%, 참가자 상호 평가 20%다. 세일즈 기간이 끝나면 매출 상위 10개 팀이 본선에 진출하고, 여기에 상호 평가 점수를 합산해 최종 우승자가 결정된다. 개발에 주어진 시간은 30시간이고, 그렇게 만든 제품으로 일주일 동안 실제 고객을 만나 매출을 만든다. 여기에 결정적인 세부 규칙이 하나 더 있다. 매출은 총액이 아니라 순이익으로 집계되며 경품으로 사용한 비용은 차감된다. 이 규칙 때문에 참가자들의 초반 행동이 왜곡됐다. 엘리베이터 피칭 상위 입상 리워드가 광고 비용이었기 때문에, 한 팀은 "최대한 많은 투자 비용을 얻어오는 게 중요하다"고 판단하고 "자극적이고 짧고 직관적으로 이해되는 피치를 하자"를 팀 전략으로 정했다고 밝혔다. 규칙이 피칭의 톤까지 설계한 셈이다.

참가자 층은 극단적으로 넓다. 토스 창업자, 이준석 의원 등 정치인, 오픈소스 스타 합산 50K/55K를 보유한 팀, 실리콘밸리 엑시트 경험이 있는 대표, 그리고 "코딩을 시작한 지 한 달밖에 안 됐다"는 사람이 같은 대회에 있다. 정치인 참가자는 "대한민국에 영향을 미치는 프로그래밍은 꽤 하고 있다. 다만 내가 약한 게 매출 내는 개발인데, 그건 안 해 본 지 20년 됐다"고 말한다. 흑팀과 백팀 구분에 대해 한 참가자는 백팀에 당일 처음 만난 조합이 많은 반면 흑팀은 이미 같이 일하던 사람들이 사전 팀 구성으로 왔다는 점을 구조적 격차로 지적했다. 엘리베이터 피칭 투표 결과는 공동 3등이 백17팀과 흑17팀, 2등이 흑15팀(7표), 1등이 백4팀(8표)이었다.

아이템 분포가 이 영상의 두 번째 관전 포인트다. 사주 서비스가 최소 4팀 겹쳤다. 실제 사주 전문가를 팀에 영입해 노하우를 AI로 옮긴 "사주 보이즈", 사주 기반 관계 해석 앱, 영미권 대상 사주 앱, 그리고 사주와 서양 점성술을 교차 검증하는 팀까지 나왔다. 참가자들의 평가는 냉정하다. "사주 서비스가 돈 버는 건 다들 너무 잘 알고 있는데, 굳이 여기까지 와서 사주를 만들어야 되나 싶었다." 정작 교차 검증 팀은 "이미 레드오션이지만 사주와 점성술을 교차 검증하는 아이템은 본 적이 없다. 그리고 결국 이건 마케팅 싸움이고, 거기선 내가 제일 잘할 수 있다"고 반박했다. 두 번째 쏠림은 AI 인플루언서와 AI 영상 생성으로 여기도 최소 4팀이다. "딸깍 한 번이면 자동으로 다 되게" 만들겠다는 팀, 스노우의 AI 프로필 유행을 영상 버전으로 옮긴 팀, SNS 바이럴 콘텐츠를 자동 분석해 기획부터 업로드까지 자동화하는 팀, 대화 가능한 AI 인플루언서 100명을 만드는 팀이 각각 있었다. 그 외에는 비개발자가 슬랙만으로 AI 에이전트를 바로 구매해 쓰게 하는 "데스크메이트", 논문 포매팅과 자료 탐색을 대신하는 리서치 캐시, 3분 안에 AI 에이전트를 만들어주는 오토, 오픈그래프 메타데이터를 마케팅 목적에 맞게 바꾸는 URL 쇼트너, "내 남친이 쓰레기인가"를 판정하는 쓰레기 판별기 등이 나왔다.

전략 측면에서 참가자 다수가 같은 결론에 도달했다는 점이 중요하다. "아무리 개발을 잘한다 쳐도 홍보가 안 되고 바이럴이 안 되면 끝난다." 그래서 "개발의 우위에 대해서는 애초에 생각을 안 하게 됐다"는 발언까지 나온다. 쓰레기 판별기 팀은 "전략이 그냥 단순했다. 얼마나 제일 많이 바이럴할 수 있느냐가 관건이라서 제품 자체는 오래 걸리지 않았다"고 밝혔다. 30시간이 끝난 시점의 상태는 참가자들의 말로 그대로 드러난다. "10년 만에 30시간 동안 이렇게 몰입한 적은 처음이다." "아무것도 안 먹고 싶어요. 잠이 먹고 싶어요."

일주일 판매 후 발표된 최종 결과는 이 대회의 규칙이 만든 가장 예상 밖의 장면을 낳았다. 3등은 흑17팀으로, 유저가 특정 기업의 릴스나 틱톡 바이럴 영상을 기업 요청에 맞게 만들어 자기 인스타에 올리고 광고주에게 현금을 받는 "메소드"라는 앱을 만들었다. 2등은 흑15팀으로 "정말 마지막 6~7시간 남았을 때부터 방향성을 바꿔서 여기까지 왔다"며 인기 인플루언서와 비슷한 프로필을 생성하고 콘텐츠를 클릭 한 번으로 만들어 인스타그램에 바로 업로드하는 100% 인플루언서 자동화를 내세웠다.

1등은 백3팀인데, 이들이 1등이 된 방식이 이 영상의 결론이다. 이들은 자기가 만든 서비스를 해커톤 기간 중에 매각했다. 제품 자체는 가장 매력적인 상대들을 리스트로 보여주고 누르면 인스타 DM처럼 느껴지는 AI 시뮬레이션 대화가 이어지며 채팅이 오갈 때마다 지속 과금되는 구조였다. 소수지만 헤비 유저도 있었다. 문제는 유통기한이었다. 팀 내부 진단은 냉정하다. "그로스 아이템들은 보통 3~4일 정도 플레이하는 경우가 많고, 이 대회는 7일 동안 하는 제품이었다. B2C로 우리가 똑같은 방식으로 리비뉴를 만들어서는 아예 답이 안 나오겠다는 생각이 들었다." 글로벌 배포, 광고 구좌 오픈, 결혼정보회사 대상 B2B 광고 같은 안이 검토되다가 한 팀원이 매각 이야기를 꺼냈다. 리더의 반응은 "실제로 타로 앱을 만들어 엑시트해 본 창업가가 그 말을 하니까 저것도 말이 된다는 생각이 들었다"였다. 처음 제시된 금액은 500만 원 선이었고 "500만 원도 좀 싼 것 같은데, 1천만 원 이상으로도 해볼 수 있지 않을까요"라는 반론이 붙었다.

이 팀이 남긴 자기 평가가 이 해커톤 규칙에 대한 가장 날카로운 코멘트다. "짧은 시간에 고객에게 어떤 가치를 전달하는 제품을 만들었다는 자부심이 있었는데, 그 과정에서 우리가 매각을 하지 않았으면 1등이 안 됐을 수도 있었다는 사실도 있다. 그래서 다음에 이 해커톤이 또 만들어진다면 이걸 하지 말라는 규정이 들어가지 않을까, 아니면 이걸 팔기 위한 목적으로 잘 세일즈하고 다니는 팀이 나올 수도 있겠다는 두 가지 생각이 들었다." 매출 80%라는 지표가 "제품을 팔아 버는 것"과 "제품 자체를 파는 것"을 구분하지 않는다는 허점이 첫 시즌에서 바로 뚫린 것이다. 참가자들이 남긴 회고에서 반복되는 건 제작보다 판매가 어려웠다는 인식이다. "당일에 제품 만드는 건 그렇게 힘들지 않았는데, 실제로 이걸 파는 과정이 너무 힘들더라." "토스팀 보면서 벽을 느꼈다. 그 수준까지 실력을 끌어올리는 게 첫 번째인 것 같다." "잡스가 말한 'A급은 A급을 좋아한다'를 느꼈다." 다음 참가자를 위한 조언도 구체적이다. "참여할 거면 각오 단단히 하고, 일주일 정도는 완전히 여기에 바친다는 각오로 와야 한다." 대회 측은 시즌 2를 대학별 대항전으로 예고했다.

몇 가지 세부는 이 대회의 성격을 더 정확히 보여준다. 흑팀과 백팀 구분에 대해 한 참가자는 "본업이 워낙 바쁜 사람이 많아서 건강검진하면 이상하게 나오는 사람이 대부분 백개발자"라고 자조했다. 대화 가능한 AI 인플루언서 100명을 만들겠다는 팀은 팀원 합산 총 조회수 9천만, 트위터 바이럴 트레이닝 넘버원 경험, 서울대와 포항공대와 고려대 출신 개발진을 근거로 들었다. 3등을 한 흑17팀의 출발 전제도 명확했다. "친구나 과거 비즈니스 하면서 알던 사람들에게 셀링하는 게 일차적으로 무조건 돼야 한다"는 것이었고, 주변 인플루언서 인맥과 아는 회사, 개인 사업자들에게 어필될 것이라는 계산이 아이템 선택의 근거였다. 팀의 반응은 "사실 3등만 해도 충분히 좋다는 생각이었다"였다. 그 외에도 가상 환경에서 복수를 대행하는 에이전트, B2G를 겨냥한 B2B 팀, BTS 제대 시점을 근거로 든 K팝 덕질 프로덕트까지 나왔다. 30시간이 지난 시점에 한 참가자는 "집에 못 들어간 지 30시간 넘었다"면서도 "오랜만에 여의도 문법을 벗어난 새로운 문법에 있으니 리프레시된 것 같기도 하다"고 말했다.

캠퍼스 창업 지원은 4배로 뛰었는데 seed 투자 건수는 줄었다

Sanghwan Yang의 글은 이 날 한국 LinkedIn에서 가장 데이터가 많은 관찰 기록이다. 9개 항목으로 한 달간의 경험을 나열하는데, 세 개의 숫자가 핵심이다.

첫 번째 숫자는 320팀이다. D2SF가 매년 2회 여는 캠퍼스 창업 프로그램의 하반기 batch 지원팀 수다. 통상 배치마다 60~70팀이 지원했으므로 4배를 훌쩍 넘는다. 저자는 이 프로그램을 10년간 운영하면서 본 압도적 최대치라고 못박는다. 지원자 중에는 창업을 위해 학교를 자퇴한 창업자, "지금 학교를 더 다니는 게 의미가 없다"며 열리는 기회를 놓칠 수 없다고 말한 창업자가 있었다.

두 번째 숫자는 투자 시장의 역설이다. 2025년 전체보다 2026년 상반기 투자 규모가 더 클 정도로 자금은 폭발적으로 늘었는데, 투자 건수는 오히려 줄었다. 초기 투자가 줄고 후기 투자가 늘었다는 뜻이고, 쉽게 말해 검증된 딜과 대마불사 기업에 돈이 몰렸다. 저자의 전망은 명확하다. "올해의 이 선택은 2~3년 후의 가뭄을 불러올 테고, growth 투자자들은 또 투자할 곳이 없다며 울상일지도 모른다." 학생 창업 공급은 4배로 늘었는데 seed 자금은 오히려 후퇴하는 엇갈림이 이 글의 골자다.

세 번째는 정성적 관찰이다. Berkeley와 Stanford에서 연 창업 meetup은 small group으로 기획했으나 신청이 몰렸고, 참여자들 증언으로 "대기업 채용 설명회보다 많이 왔다". 중국 유학생이 줄어든 자리를 여러 국가가 채우는 중인데 체감상 한국인이 가장 많다. pre-seed를 받자마자 SF로 넘어간 팀 사례에는 뼈아픈 코멘트가 붙어 있다. 실리콘밸리의 지인이 이 팀을 보고 "이 정도 스펙, 경험, 의지, 방향성을 가진 젊은 창업자가 만약 미국 태생이었다면 훨씬 높은 밸류와 펀딩을 쉽게 받았을 것"이라고 했다는 것이다. 'SF200' 행사 기록도 구체적이다. 대학 1학년만 마치고 휴학해 SF로 넘어가 창업, 개발, 해커하우스를 경험한 창업자의 고군분투기를 다룬 행사로, 청중의 90% 이상이 20대였고 no show도 매우 적었으며 질문이 너무 많아 정해진 시간을 훌쩍 넘겼다. 가장 많이 나온 질문은 "지금 실리콘밸리에 가는 것은 FOMO인가, 아니면 실재적 근거가 있는가?"였다. 저자의 해석은 단일 원인론을 경계한다. AI가 만드는 것의 허들을 낮춘 것은 맞지만 그것만으로는 다 설명되지 않고, 의대 입시에 모든 것을 걸었던 피로감의 반작용일 수도, 경제적 사다리가 끊어졌다는 절박함에서 나온 선택일 수도, 빅테크가 허물어버린 경쟁 장벽을 본능적으로 체감한 결과일 수도 있다는 것이다.

같은 날 다른 각도에서 한국 스타트업의 보상 구조를 보여준 글이 화이트큐브(챌린저스)의 Minjoo Song 포스트다. 전사 기본 연봉을 1,000만 원 일괄 인상했다는 내용으로, 이 회사는 1년에 두 번 연봉 협상을 디폴트로 하며 이번 6월 협상에서 결정됐다. 대표 Hyukjoon Choi(헨리)의 논리는 회사가 먼저 업계 최고의 대우를 선불하겠다는 것이고, 목표는 "신입 초봉이 6천인 회사"다. 근거로 제시된 실적은 3년 연속 흑자, 매년 2배 매출 성장, 올 상반기에 이미 작년 한 해 매출에 근접이다. 다만 이 글에서 함께 읽어야 할 부분이 있다. 저자 본인이 "솔직한 얘기"로 밝힌 조건은 기본 주 48시간(법적 기준은 넘기지 않는다고 명시)과 "남들보다 20% 더 달리자"는 기조이며, "48시간도 안 할 거면 스타트업에 왜 오지?"라는 표현이 그대로 실려 있다. 보상 인상 소식과 고강도 근무 기조는 한 글에 묶여 있으므로 분리하지 않는 것이 정확하다.

대기업은 미팅을 사랑한다: 창업자 조언 3편

X · @paulg, X · @garrytan, X · @levelsio

세 개의 짧은 글이지만 각각 재사용 가치가 높은 판단 기준을 담고 있다.

Paul Graham의 글이 이 날 X에서 가장 실무적인 경고다. 스타트업이 대기업에 판매할 때의 위험은 대기업이 대놓고 거절하지 않는다는 데 있다. 명확한 "no" 대신 몇 달에 걸친 미팅이 이어진다. 미팅을 싫어하는 창업자에게는 이 반복되는 미팅이 상대의 진지함, 즉 커밋먼트의 신호로 읽힌다. 그런데 그게 아니다. Graham의 결론 문장은 이렇다. "그들은 미팅을 사랑한다. 미팅이 그들이 하는 일의 거의 전부다." 좋아요 5,795에 댓글 209로, 이 날 X 항목 중 논의가 가장 활발했던 축에 속한다. 이 관찰의 실무적 가치는 대기업 파이프라인의 건강도를 판단하는 지표를 뒤집는다는 데 있다. 미팅 횟수와 참석자 직급은 진척의 지표가 아니다. 진짜 지표는 예산 라인이 배정됐는지, 조달 프로세스가 시작됐는지, 파일럿에 대한 성공 기준이 문서로 합의됐는지 같은 것들이다. 한국 B2B 영업 맥락에도 그대로 적용되고, 위에서 나온 "24시간 안에 구체적 제안을 보낸다"는 실행 규칙과 짝을 이룬다.

Garry Tan은 더 추상적이지만 인용하기 좋은 문장을 남겼다. "모두가 지도를 영토로 착각한다. 메리토크라시란 지도보다 영토가 더 중요하다는 것이다. 그리고 시장에서 결과가 곧 영토다. 사람들이 원하는 것을 만들었는가?" 자격, 학벌, 이력서를 지도로, 실제 만들어낸 것을 영토로 구분하는 프레임이다. 좋아요 223에 댓글 40으로, 좋아요 대비 댓글 비율이 높은 것을 보면 메리토크라시 정의를 두고 반론이 붙은 것으로 보인다.

Pieter Levels의 글은 성공한 창업자의 동기 상실을 다룬다. 예전 같은 추진력이 안 나오는 이유에 대해 그는 "이미 부자가 됐기 때문일 수 있다"고 말한다. 더 이상 빈털터리가 아니면 문자 그대로의 배고픔을 어느 정도 잃게 되고, 그것이 생물학을 바꾼다는 것이다. 그의 제안은 인위적 제약이다. 돈을 스스로 묶어두고 빈털터리처럼 살면서, 새로 시작한 사업에서 번 돈만 쓸 수 있게 하는 것. 좋아요 718.

리드 발굴을 자동화해 41분 55초에 $0.42로 12건

Reddit · r/n8n

"자동화를 파는 일 자체를 자동화했다"는 사례다. 작성자의 문제 정의가 정확하다. 로컬 업체 100곳을 찾는 건 쉽지만, 그중 자기가 실제로 해결할 수 있는 반복 문제를 가진 10곳을 찾는 게 어렵다.

워크플로는 Google Maps를 검색하고, 각 업체의 웹사이트와 최근 리뷰를 읽고, 자기가 파는 자동화와 매칭되는 반복적 운영 문제를 찾고, 근거가 부족한 업체는 걸러내고, 통과한 곳만 연락처와 회사 맥락을 조사한 뒤 Excel 파일을 붙여 이메일로 보낸다. 셋업은 폼에 자기 에이전시 웹사이트, 타깃 업종, 검색할 도시, 실제로 파는 자동화 목록을 입력하는 방식이고, 입력한 웹사이트를 스크랩해서 그 맥락을 전 과정에 끌고 간다.

숫자가 이 글의 값어치다. 테스트 실행에서 Austin과 Phoenix의 HVAC 업체, 치과, 부동산 관리사 120곳을 스크리닝해 14곳이 조건에 맞았고, 그중 2곳은 쓸 만한 연락 경로가 없어 최종 이메일에는 12건이 담겼다. 12건의 연락처 구성은 이메일 6개, 전화 11개, 공식 문의 페이지 8개다. 전체 실행에 데이터 비용 $0.42, 시간 41분 55초가 들었다. 근거로 쓰인 신호도 구체적이다. 어떤 HVAC 업체는 예약 누락과 후속 연락 부재에 대한 리뷰가 6건 있었고, 어떤 치과는 잘못된 보험 견적, 예상치 못한 청구, 환불 지연에 대한 리뷰가 7건 있었다. 즉 리뷰에 같은 불만이 반복되는가를 판별 기준으로 삼는 구조다.

작성자 본인도 이건 살펴볼 가치가 있는 업체를 찾아주는 것이지 12곳이 다 구매한다는 뜻은 아니라고 선을 긋는다. 데이터는 anyapi에서 가져오고 워크플로 코드는 GitHub에 공개돼 있다. upvote 17에 댓글 14.

이 사례의 값어치는 자동화 자체가 아니라 단가 비교에 있다. 120곳을 사람이 직접 훑어 웹사이트와 리뷰를 읽고 반복 문제를 판별하려면 최소 하루가 든다. 같은 작업이 41분 55초에 $0.42로 끝났다면, 리서치 단계의 인건비가 데이터 비용 수준으로 내려왔다는 뜻이다. 다만 저자 스스로 그은 선이 중요하다. 이 파이프라인이 만들어내는 건 계약이 아니라 살펴볼 가치가 있는 후보 목록이다. 오늘 다른 섹션에서 반복된 진단, 즉 AI 출력을 중계만 하는 순간 가치가 0이 된다는 이야기가 여기에도 적용된다. 리뷰에 같은 불만이 6건, 7건 반복된다는 신호를 찾아주는 것까지가 기계의 몫이고, 그 업체가 실제로 살 만한 상태인지와 어떤 각도로 접근할지는 여전히 사람이 판단해야 한다. 앞서 나온 대기업 파이프라인 경고와 짝을 이루는 대목이기도 하다. 후보 수가 늘어난다고 파이프라인이 건강해지지는 않는다.

베팅 전에 던지는 질문 3개, 그리고 "아무것도 하지 않기"가 무패인 이유

YouTube · Alex Hormozi

Alex Hormozi가 사업에서 베팅을 할 때 쓴다는 질문 3개를 정리한 영상이다. 그는 이 질문들을 가장 아끼는 소유물이라고 부르며 각각을 언제 쓰는지 조건까지 명시한다. 형식은 웹캠 하나 켜놓은 독백이지만 내용은 팀 운영과 우선순위 결정에 바로 적용되는 프레임이다.

첫 번째 질문은 "What problem are you trying to solve?"이고, 적용 조건은 누군가 나에게 뭔가를 하자고 하거나 어떤 행동을 승인해 달라고 할 때다. 그는 실제 대화 예시를 든다. 팀원이 직원 engagement 프로그램을 하자고 한다. 그가 묻는다. "무슨 문제를 풀려는 거죠?" 답이 "직원들에게 좋을 것 같아서"로 돌아오면, 그는 구체 지표로 되묻는다. "리텐션 문제가 있나요? 채용 문제가 있나요? 인재를 못 뽑고 있나요?" 팀원이 아니라고 답하면 결론은 하나다. "그럼 우리는 왜 이걸 하죠?" 이 질문을 쓰게 된 이유를 그는 인간 행동의 패턴으로 설명한다. 사람은 감정적 불편함이 생기면 그걸 문제로 규정하고, 그 결과 행동이 사방으로 튄다. 그리고 선의를 가진 사람들이 하는 전형적인 실수는 자기가 모르는 일에 부딪혔을 때 자기가 할 줄 아는 일을 한다는 것이다. 여기서 이 영상에서 가장 인용 가치 높은 문장이 나온다. "산만함의 상당 부분은 사실 지적 게으름이다." 대부분의 사람은 자기 사업에서 무슨 일이 일어나야 하는지 어느 정도는 안다. 하지만 그걸 어떻게 푸는지 모르기 때문에 자기가 풀 수 있는 다른 일을 찾아서 한다. 그러면 기분이 나아지고 유능하다고 느끼기 때문이다. 아무 차이도 만들지 못하는데도.

두 번째 질문은 "What would it take?"이고 적용 조건은 반대다. 내가 뭔가를 원해서 다른 사람에게 요청할 때 쓴다. 그가 이 질문으로 바꾼 이유가 구체적이다. 커리어 초기에 그는 "우리 이거 할 수 있어요? 가능해요?"라고 물었다. 그러면 안 된다는 답이 돌아왔는데, 문제는 그 답을 하는 사람이 그의 사업 전체 맥락이나 장기 계획을 모른 채 머릿속에서 나름의 계산을 해서 자기 대신 결정을 내려버린다는 것이었다. "그러면 나는 틀린 데이터를 가지고 일하게 된다." "What would it take?"의 작동 원리는 성공을 전제한다는 것이다. 상대는 거절 대신 조건을 말하게 되고, 그럼 그 조건이 값어치가 있는지는 내가 판단한다. 그가 보여주는 압박 시퀀스는 이렇다. 누가 안 된다고 하면 "잠깐. 우리가 그걸 하려면 뭐가 필요하죠? 내가 10억 달러가 있으면 할 수 있나요?" - "네." - "그럼 10억 달러가 필요한가요?" - "아니요." - "100만 달러는요?" - "아니요." - "그럼 실제로 뭐가 필요한가요?" - "사람을 한 명 뽑아야 할 것 같아요." 그러면 계산이 나온다. 그 사람 비용이 10만 달러이고 이걸로 올해 100만 달러를 더 번다면 하면 된다. 그리고 그는 진짜 답을 이렇게 번역한다. "그러니까 지금 기존 인프라로는 못 한다는 말이군요. 더 정확히는, 기존 인프라가 다른 일들에 우선순위가 잡혀 있다는 말이고. 그럼 그것들을 후순위로 내리고 이걸 앞으로 올립시다."

세 번째 질문은 "What do you want to have happen?"이다. 첫 번째 질문의 후속으로, 상대가 자기가 풀려는 문제를 스스로 모를 때 쓴다. 그의 표현으로는 감정적인 소란을 전부 우회해서 "그래서 뭘 보고 싶은 건데?"로 바로 간다. 원격 근무 회사에서 분기 회의를 대면으로 하자는 제안이 나온 상황이 예시다. 여기서 그가 하는 일은 반박이 아니라 번역이다. "그러니까 주장은, 온라인보다 대면일 때 사람들이 더 몰입할 거라는 거군요. 거기에 이견 없습니다. 그럼 그 재미의 정도가 이후의 산출물과 관계가 있다고 보시나요?" 그리고 그는 자기 태도를 분명히 한다. "내가 이런 질문을 하는 건 함정이거나 반대해서가 아니라, 상대방의 사고를 듣고 싶어서다."

여기서 그는 연쇄 질문 3연타를 추가로 공개한다. 1. "그게 무슨 뜻이죠(What does that mean?)" 2. "그걸 어떻게 아나요(How do you know that?)" 3. "그래서 뭐(So what?)". 각각 정의를 구체화하고, 측정 방법을 묻고, 그 결과가 실제 산출물에 영향을 주는지를 검증한다. 그리고 마지막 관문이 하나 더 있다. "이 시간과 에너지로 할 수 있는 다른 일 중에 사업에 더 높은 수익을 낼 만한 게 뭔가?" 그는 직원들이 행복하길 당연히 원한다고 전제하면서도, 일회성 이벤트가 사람을 실제로 행복하게 만드는 건 아니라고 본다. 그가 더 효과적이라고 보는 것은 높은 노력을 보상하고 형편없는 사람을 걷어내는 지속적인 업무 환경이다.

영상의 결론은 대부분의 사람이 기대하는 방향과 반대다. "이런 질문들을 하다 보면 아마 우리는 이걸 하지 말아야 한다는 결론에 자주 도달하는데, 대개 그게 정답이다." 그가 내부적으로 쓰는 농담 표현이 **"무패 헤비급 세계 챔피언은 '아무것도 안 하기'"**다. A를 하거나, B를 하거나, 아무것도 안 하거나 세 개의 문이 있을 때 아무것도 안 하기가 정답인 경우가 너무 흔하다는 것이다. 그 논리는 기회비용이다. 이건 수익이 날 수도 있는 일이고, 저건 수익이 날 걸 아는 일인데, 이쪽 수익이 저쪽만큼 좋을 수는 있어도 저쪽은 확실하다. 그러면 저쪽을 더 하면 된다. 그는 10개 사업을 1천만 달러 이상으로, 3개 사업을 1억 달러 이상으로 키운 경험을 근거로 든다. 바로 위 해커톤 항목의 아이템 쏠림, 즉 남들이 다 하니까 사주와 AI 인플루언서를 만드는 행동이 정확히 이 질문들이 걸러내려는 대상이다.

AI와 콘텐츠, 마케팅, 제품 윤리

레퍼런스 조합으로는 AI를 이길 수 없다

LinkedIn · 임근영, LinkedIn · Grace Tully

Maxsummit 2026 참관기는 이 날 SNS에서 나온 유일한 국내 대형 마케팅 컨퍼런스 정리다. 약 2,000명이 신청한 행사이고 기획자는 김준하이며, 임근영이 오후 세션 4개를 정리했다.

가장 인용 가치가 높은 발언은 브랜드 콘텐츠 기획 세션(돌고래유괴단, 토스 머니그라피, 유튜버 주연)에서 나온 돌고래유괴단 주형의 말이다. "AI는 인간이 만든 모든 콘텐츠를 습득한 거대한 레퍼런스 덩어리라, 레퍼런스 조합으로 가면 AI를 이길 수 없다." 크리에이티브 업계가 AI에 대응하는 방식을 한 문장으로 정리한 진술이다. 레퍼런스를 잘 조합하는 능력은 AI가 구조적으로 우위인 영역이므로 인간의 차별점은 다른 축에 있어야 한다는 뜻이다. 세션 전체의 공통 결론은 브랜드 메시지를 뾰족하게 다듬고 진정성 있는 콘텐츠로 신뢰를 쌓아야 한다는 것이었다. 'AI 시대, 무엇이 선택받는가' 세션은 그 답을 다른 방향에서 내놓는다. 설빙, 테라로사 등 AI 시대에도 오프라인 경험을 확장하는 브랜드 사례로, 삭막하고 정형화된 경험이 아니라 더 디테일하고 개인화된 경험으로 브랜드를 인지시키고 진짜 팬으로 만드는 전략이다.

가장 실무적인 것은 하이브의 'AI 네이티브 마케터의 Zero to One' 세션이다. 마케터가 기획부터 성과까지 만들어가는 과정에서 AI의 도움으로 병목을 하나씩 줄여나가는 사례인데, 참관자가 뽑은 교훈은 "도구를 어렵고 복잡하게 써야 잘 쓰는 게 아니라, 진짜 필요한 곳에 써야 의미가 있다"였다. 그리고 조직 구조에 대한 주장이 붙는다. 기능 조직에서는 서로의 월권 문제로 AI가 안 굴러가기 때문에 목적 중심 크로스펑셔널 조직으로 가야 한다는 것이다. AI 도입이 조직도를 건드리는 문제라는 점에서 앞서 나온 shadow AI 논의, 그리고 AIHR 리포트의 "운영모델은 64%가 바꿨지만 역할 명확성은 19%"와 정확히 같은 지점을 다른 각도에서 짚는다. 플랫폼 세션(쏘카, 삼쩜삼)에서 뽑아낸 공통점도 중요하다. 두 기업 모두 AI로 제품 기능을 빠르게 런칭해 속도를 높이고, 광고 소재나 CRM 최적화처럼 생산에 병목이 있던 영역을 풀었다. 그런데 진짜 공통점은 AI로 해결한 문제를 1회성으로 끝내지 않고 인프라로 만들어가고 있다는 점이다. 개인 생산성 향상에서 조직 자산으로 넘어가는 전환을 실제 사례로 확인한 관찰이다.

같은 날 영어권에서 Grace Tully는 소셜 전략의 흔한 오해를 정면으로 다뤘다. "오직 바이럴만 원하는 것은 과대평가돼 있고, 중간중간 바이럴 순간이 끼어 있는 강하고 일관된 소셜 프로그램은 과소평가돼 있다"고 썼다. 그가 지적하는 전형적 상황은 TikTok을 폰에 깔지도 않은 임원이 브랜드가 바이럴 되기를 원한다고 말하는 장면이다. 그의 핵심 프레임은 두 개의 속도다. 첫째, FAST SOCIAL은 빠른 한 방, 바이럴 순간, 24시간 뉴스 사이클이다. 속도와 도달을 위해 설계되고 스쳐 지나가며 사라진다. 완벽한 타이밍의 트윗이나 TikTok의 킬러 댓글 같은 것이다. 둘째, Slow social은 의도적이고 연재되는 콘텐츠로 시간에 걸쳐 친숙함을 쌓고 브랜드가 지속되는 연결과 신뢰를 얻기 위해 만든다. 영상 시리즈와 좋은 에버그린 콘텐츠가 여기 속한다. 그가 던지는 질문이 판단 기준으로 유용하다. "사람들이 당신 브랜드를 소셜에서 떠올릴 때 뭐라고 말하길 원하는가? '아 그때 바이럴 됐던 영상 하나 좋았지'인가, 아니면 식중독 사태 중에도 당신을 방어해줄 만큼 충성스러운 사람들인가?" 결론은 세 가지 실행 항목이다. 잘 갖춰진 소셜 팀에 제대로 투자하고, 시간에 걸쳐 일관되게 게시하고, 테스트와 학습을 반복한다. 바이럴은 그 과정에서 우연히 걸리는 것이지 목표가 아니라는 것이다.

개발자가 매일 구현하는 주의력 착취 패턴 10종

LinkedIn · Python Developers Community

커뮤니티 계정의 리스트형 포스트지만 목록 자체가 체크리스트로 재사용 가능해 남긴다. 좋아요 1,337로 이 날 LinkedIn 상위권이다.

전제가 날카롭다. "인터넷은 당신의 돈만 놓고 경쟁하지 않는다. 당신의 주의력, 습관, 결정을 놓고 경쟁한다." 그리고 이어지는 문장이 이 글의 각도를 정한다. "개발자들이 불행히도 이 조작 기법들 전부를 구현하고 있다." 비판의 대상을 기획자나 경영진이 아니라 구현 주체인 개발자로 지목한다.

나열된 10가지는 다음과 같다. Nudge(기본 선택지, 추천, 리마인더 같은 작은 설계 선택으로 특정 결정을 밀어붙임), Freemium(무료 기본 버전으로 유입시킨 뒤 유료 기능으로 유도), FOMO(기간 한정 오퍼, 카운트다운, "2개 남음"), Dark patterns(숨겨진 구독 취소 경로, 헷갈리는 버튼), Infinite scroll(멈출 지점 제거), Variable rewards(좋아요, 알림, 새 콘텐츠처럼 예측 불가능한 보상), Social proof(평점, 리뷰, 팔로워 수, "사람들이 이걸 사고 있어요"), A/B testing(클릭, 리텐션, 구매를 늘리는 디자인 탐색), Notifications & alerts(리마인더와 긴급성으로 재방문 유도), Subscription traps(시작은 쉽고 취소는 어렵게).

목록에서 눈여겨볼 것은 A/B 테스팅과 Nudge처럼 중립적으로 여겨지는 실무 관행이 조작 기법 목록에 함께 들어가 있다는 점이다. 저자의 관점에서 이들을 가르는 것은 기법 자체가 아니라 최적화 목표다. 사용자의 목표를 위해 최적화하면 도움이고, 사용자의 의도와 무관하게 체류 시간과 구매를 최적화하면 조작이 된다. 제품 팀이 자기 점검용 체크리스트로 그대로 쓸 수 있는 형태다.

마스코트를 쓰는 브랜드는 4%인데 성과 차이는 30%다

Product Hunt · MascotAI

MascotAI는 브랜드 마스코트를 애니메이션으로 만들어 주는 도구다. 제품 자체보다 소개에 인용된 광고 효과 데이터가 정리해 둘 만하다.

첫 번째는 Duolingo 사례다. 푸시 알림에 마스코트 Duo를 등장시켰더니 DAU가 5% 늘었다. 알림 문구를 바꾼 게 아니라 캐릭터를 넣은 것만으로 나온 차이다. 두 번째가 규모 있는 근거다. System1과 IPA DataMINE이 400개 캠페인을 분석한 결과, 캐릭터가 주도하는 광고가 그렇지 않은 광고보다 이익에서 30%, 시장 점유율에서 37%, 신규 고객 확보에서 27% 앞섰다. 세 지표 모두에서 일관되게 나온 격차다. 여기에 붙는 숫자가 이 제품의 판매 논리다. 그런데 실제로 캐릭터를 쓰는 브랜드는 4%에 불과하다. 효과가 검증됐는데 채택률이 낮은 이유는 제작 비용과 시간이었고, 그 부분을 도구로 낮추겠다는 것이다.

이 논리를 그대로 받아들일 때 주의할 점은 있다. 400개 캠페인 분석은 마스코트를 만들 여력과 브랜드 전략이 있는 조직들의 결과이므로, 캐릭터 자체의 효과와 그런 결정을 내릴 수 있는 조직의 역량이 섞여 있을 수 있다. 도구로 캐릭터를 찍어낸다고 같은 30%가 따라온다는 보장은 없다. 요금 구조는 토큰 할당량으로 되어 있고 주 240K, 월 1.25M이다.

이 항목을 같은 섹션의 다른 글과 겹쳐 읽으면 흥미로운 긴장이 생긴다. 돌고래유괴단 주형은 레퍼런스 조합 영역에서는 AI를 이길 수 없으니 다른 축을 찾으라고 말하고, Grace Tully는 바이럴 한 방보다 시간에 걸친 일관성이 브랜드 자산을 만든다고 말한다. 마스코트는 정확히 그 일관성의 시각적 형태다. 같은 캐릭터가 푸시 알림에도, 광고에도, 제품 화면에도 반복되면서 친숙함이 쌓인다. 그렇다면 생성 도구가 제작 비용을 낮추는 것은 진입 장벽을 없애는 게 맞지만, 그것만으로 4%와 나머지의 격차가 메워지지는 않는다. 400개 캠페인에서 관측된 30%가 캐릭터를 그린 비용이 아니라 그 캐릭터를 몇 년간 일관되게 밀어붙인 조직의 결정에서 나왔을 가능성이 크기 때문이다.

법, 감시, 그리고 공공 인프라

Reddit · r/ArtificialInteligence

GEMA는 독일에서 이 권리들을 개별 창작자 대신 일괄 관리하는 조직이라, 개별 아티스트가 소송을 걸 때와 달리 대리하는 저작물의 범위가 넓다는 점이 이 판결의 무게를 만든다.

Suno의 반론은 생성형 AI 소송에서 반복되는 논리다. 자사 기술은 기존 곡을 복제하도록 설계된 게 아니라 새로운 곡을 만들도록 설계됐다는 것이고, 판결에 동의하지 않으며 항소를 검토 중이다.

이 글이 커뮤니티에서 260 upvote와 댓글 92를 받은 건 결과 자체보다 위치 때문이다. 음악 업계가 학습 데이터 사용을 두고 벌여온 법적 싸움에서 생성형 AI 음악 회사에 대한 의미 있는 패배 사례가 하나 더 쌓였고, 관할이 미국이 아니라 독일이라는 점이 뒤따르는 유럽 소송들의 참고점이 된다. 글쓴이가 음악 전문 매체 소속이라 원문 기사 링크를 함께 제공한다.

이 판결을 오늘 SNS에서 2만 좋아요를 받은 규제 담론 밈과 겹쳐 놓으면 구도가 선명해진다. 밈은 규제하는 쪽과 웨이트를 푸는 쪽을 대비시키며 전자를 조롱하지만, 실제로 법정에서 결론이 나는 쟁점은 모델을 공개하느냐가 아니라 무엇을 학습에 썼느냐다. 그리고 같은 날 정리된 다른 관찰, 즉 미국에는 중국 AI 모델을 금지하는 법이 없고 조달 규정과 보안 권고 같은 비입법 경로가 실질 제약을 만든다는 분석과 나란히 두면, 이 산업에서 구속력이 어디서 오는지가 두 갈래로 갈린다는 게 보인다. 한쪽은 판결로 오고 다른 쪽은 조달 문서로 온다. 어느 쪽도 입법 논의의 속도를 기다리지 않는다.

eBay 임원들의 괴롭힘, 7년 만에 5,600만 달러 합의

GeekNews · Financial Times

전자상거래 업계 뉴스레터 EcommerceBytes를 운영하던 Ina와 David Steiner 부부는 eBay에 비판적인 기사를 썼다. 그 대가로 회사 임원들이 조직적인 괴롭힘 작전을 벌였다. 최고커뮤니케이션책임자 Steven Wymer가 남긴 문장이 이 사건의 성격을 요약한다. 우리는 이 여자를 뭉개버릴 것이다.

실행은 보안 인력 7명이 맡았다. 살아 있는 바퀴벌레, 피 묻은 돼지머리 가면, 장례 화환, 배우자를 잃은 사람을 위한 책을 집으로 보냈다. David를 미행했고, 그의 이름으로 포르노를 구독해 이웃집으로 배달되게 했으며, 집 주소를 공개해 낯선 사람들이 성적 만남을 요구하며 찾아오도록 유도했다. 언론 비판에 대한 대응으로 기업이 벌인 일이다.

법적 결과는 규모에 비해 가볍게 시작됐다. eBay는 2023년 유죄를 인정하고 벌금 300만 달러를 냈다. 회사 매출 대비로는 미미한 금액이다. 민사 소송은 7년이 걸려 5,600만 달러 합의에 이르렀는데, 이 중 개인 부담은 Devin Wenig 200만 달러, Wendy Jones 50만 달러, Steven Wymer 5만 달러다. 작전을 지시한 사람이 5만 달러를 냈다. 이후 경력이 더 눈에 띈다. Wymer는 실리콘밸리 보이즈앤걸즈클럽을 운영했고, Wenig는 GM 이사회에, Jones는 Prudential 이사로 자리를 옮겼다. UC 버클리 로스쿨의 Vincent Joralemon은 기업이 언론인을 상대로 벌인 괴롭힘으로서 이 규모는 전례가 없다고 평가한다. 2024년에는 다큐멘터리 "Whatever It Takes: Inside the eBay Scandal"이 나왔다. 사건의 세부는 이미 공개돼 있었지만 민사 합의가 마무리되는 데 7년이 걸렸다는 점, 그리고 그동안 관련자들의 경력이 계속됐다는 점이 이번 보도의 초점이다.

유출된 Flock 가이드: "먼저 서사를 장악하라"

Hacker News · 404media.co

Flock은 자동 차량 번호판 인식 카메라를 지방자치단체에 파는 회사다. 404 Media가 입수한 내부 가이드는 기술 문서가 아니라 지역 정치 대응 매뉴얼이다.

첫 번째 지침은 선점이다. 누군가 다른 사람이 하기 전에 서사를 장악하라고 적혀 있다. 시의회 안건에 오르기 전에 경찰서와 지역 언론을 통해 프레임을 먼저 세우라는 뜻이다. 두 번째 지침이 더 흥미롭다. 반대자를 상대로 이것이 대량 감시가 아니라고 설득하려 하지 말라는 것이다. 그 단어를 피하려 애쓰면 오히려 방어적으로 보이니, 감시라는 개념 자체를 우회하지 말고 다른 축으로 논의를 옮기라고 조언한다. 그 축이 비용이다. 카메라 도입 비용을 논의하는 대신 "해결되지 않은 범죄의 비용"을 이야기하라고 지시한다. 지출 심의를 안전 논쟁으로 바꾸는 프레임 전환이다.

실제 사례도 문서에 반영돼 있다. 오클랜드에서는 공개 의견이 140건 이상 접수됐다. 캘리포니아 리치먼드는 2년 반 동안 체포 274건과 차량 회수 259건이라는 수치를 제시해 4대 3으로 재승인을 받아냈다. 아슬아슬한 표차이고 숫자 제시가 결정적이었다. EFF의 Sarah T. Hamid가 지적하는 지점이 이 보도의 핵심이다. 시의회에서 벌어지는 논쟁이 시민과 지역 공무원 사이의 논쟁처럼 보이지만, 한쪽의 발언은 업체가 써 준 대본이라는 것이다. 감시 기술의 도입 여부를 결정하는 지역 민주주의 절차가 비대칭 정보 위에서 굴러간다는 이야기다. HN 41점.

노르웨이 정부 IT가 하루 넘게 DDoS로 마비됐다

노르웨이의 국가 디지털 신원 인프라가 DDoS 공격으로 하루 넘게 정상 동작하지 않았다. 영향을 받은 서비스는 Digdir와 Vivicta가 운영하는 ID-porten, MinID, Altinn, eFormidling, Maskinporten이다.

이 목록이 의미하는 바를 짚어야 한다. ID-porten과 MinID는 국민이 공공 서비스에 로그인하는 관문이고, Altinn은 신고와 신청을 처리하는 창구이며, Maskinporten은 기관 간 시스템 연동에 쓰이는 인증 서비스다. 즉 개별 서비스가 아니라 그 위에 올라탄 모든 행정 절차가 함께 멈춘다. 디지털 정부를 잘 구축했을수록 이 단일 지점의 파급이 커진다.

시간 경과도 기록됐다. 8월 3일 월요일 새벽 1시경 시작됐고, 8월 4일 0시 8분 시점에도 여전히 실패하고 있었다. 하루가 지나도록 완화하지 못했다는 뜻이다. 댓글에서는 두 갈래 논의가 있었다. 하나는 국가 배후 가능성이고, 다른 하나는 그 반대다. DDoS 대행 서비스가 50달러에서 100달러 수준에 거래된다는 언급이 나왔다. 정부 인프라를 하루 넘게 마비시키는 데 필요한 자원이 반드시 국가 수준일 필요는 없다는 것이다. 어느 쪽인지는 이 시점에 확정되지 않았다. HN 80점.

기타 주목할 콘텐츠

영어 핵심 어휘 70년: bread는 남고 flour와 harvest는 빠졌다

GeekNews · 분석 글

영어 학습자를 위한 핵심 어휘 목록은 1953년의 GSL과 2023년의 NGSL이 대표적이다. 70년 사이 무엇이 빠지고 무엇이 들어왔는지를 데이터로 비교한 분석이다.

먼저 효율이 올라갔다. GSL은 2,284단어로 일반 텍스트의 약 84%를 커버했고, NGSL은 2,809단어로 90% 이상을 커버한다. 단어 수가 23% 늘면서 커버리지는 6%p 이상 올라간 셈이다. 목록 사이의 관계를 보면 1,656개가 그대로 유지됐고 628개가 빠졌으며 1,153개가 새로 들어왔다. 빠진 것과 들어온 것의 성격이 다르다. 구체성 평정에서 최고 등급에 속하는 단어의 비율이 21%에서 14%로 떨어졌다. 제거된 단어 중에서는 25% 이상이 최고 구체성 등급이었는데, 추가된 단어 중에서는 7.4%뿐이다. USAS 21개 의미 범주로 나눠 보면 추상 범주가 약 28% 늘었다. 감정 관련 단어는 1.8%p 줄고 심리 과정 관련 단어는 1.8%p 늘었다.

배경으로 노동 구조 변화가 제시된다. 미국에서 1957년에 사무직이 육체노동직 수를 넘어섰고, 2000년에는 육체노동이 전체의 4분의 1 미만이 됐다. 손으로 만지는 사물의 이름이 일상 언어에서 차지하는 비중이 줄어드는 흐름과 맞물린다. 구체적인 예가 이 변화를 잘 보여준다. bread는 두 목록 모두에 남아 있는데, flour와 wheat, harvest, bake는 빠졌다. 빵은 여전히 먹지만 밀가루를 사서 반죽해 굽는 과정은 대다수의 일상에서 사라졌다는 뜻이다. 결과물의 이름은 남고 과정의 이름이 없어졌다. 방법론도 밝혀져 있다. 구체성 평정은 Brysbaert 등(2014)의 데이터를 썼고 이론적 근거로 이중 부호화 이론을 든다. 품사 태깅은 NLTK로 하되 132건, 즉 3.8%를 수동으로 고쳤다. 자동 처리 결과를 그대로 쓰지 않고 오류율을 밝힌 점은 신뢰도를 높인다.

교육 자료를 만드는 입장에서 이 분석이 실용적인 이유는 커버리지와 구체성이 서로 다른 방향으로 움직였다는 데 있다. 단어 수를 23% 늘려 커버리지를 6%p 이상 올렸다는 건 목록 설계가 더 효율적이 됐다는 뜻이지만, 동시에 학습자가 손에 잡히는 사물의 이름을 덜 배우게 됐다는 뜻이기도 하다. 추상어 비중이 늘어나면 예문에서 그림으로 보여줄 수 있는 항목이 줄어들고, 초급 단계에서 의미를 고정시키기가 어려워진다. bread와 flour의 대비가 그 문제를 압축한다. 결과물의 이름만 남고 과정의 이름이 사라지면, 그 과정을 설명해야 하는 순간에 쓸 어휘가 목록 밖에 있다.

"지속 가능한 생계"는 저축이 아니라 무기 계약을 뜻했다