42주차

이번 주

이번 주에 실은 글은 스물세 편입니다. 가장 뚜렷한 흐름은 이해를 맡길 수 없다는 주장이 이번에는 실험 결과와 시스템 설계 논리로 뒷받침됐다는 점입니다. DHH가 코드를 읽지 않고 AI에 맡긴 Campfire 재작성을 Piotr Sarnacki가 해부했더니, 프롬프트가 비워 둔 결정이 동전 던지기가 되고 벤치마크도 결론을 속였습니다. n-the-loop는 일관성 같은 전역 속성은 어느 컴포넌트도 보장하지 못하므로 시스템 전체를 아는 사람이 있어야 한다고 같은 결론을 설계 쪽에서 끌어냈습니다. 둘째 흐름은 에이전트가 "끝났다"고 말하는 것을 믿지 않는 장치를 어디에 두느냐입니다. Stack Overflow, Cloudflare, GitHub가 각자 다른 층에 검증을 심는 방법을 내놓았고, 수학 쪽에서는 검증기가 통과시켜도 의도한 것이 검증된 것은 아닐 수 있다는 논문이 나왔습니다. 셋째로 개인의 층위에서는 세부를 아는 즐거움을 잃는 슬픔, 평범한 일을 지키자는 주장, AI가 지적 공동체의 동기를 없앤다는 진단이 한꺼번에 나왔습니다. 넷째로 에이전트의 규모가 Git 저장소와 시크릿 보호 같은 인프라에 압력을 주고, 하네스가 모델보다 먼저 한계에 닿는다는 불만이 함께 보였습니다. 이 모든 글의 바탕에는 일을 맡기는 속도가 이해와 검증의 속도를 앞질렀다는 인식이 깔려 있습니다.

맡긴 일의 이해와 책임은 누가 지는가

읽지 않고 맡긴 Campfire 재작성이 보여준 것, 그래도 생각해야 한다 (Piotr Sarnacki)는 이번 주 가장 구체적인 실험 기록입니다. DHH가 Campfire를 Rails에서 Rust, Elixir, Go로 AI에게 다시 쓰게 했는데, 프롬프트가 정하지 않은 결정(하위 호환, 지연과 처리량의 우선순위, 메모리 사용)을 LLM이 구현하면서 암묵적으로 답해 버려 두 구현은 같은 제품이 아니었습니다. 벤치마크도 문제였습니다. 요청에 응답이 와야 다음 요청을 보내는 폐쇄 루프 방식은 빠른 시스템이 더 많은 부하를 받게 해서 비교 자체를 왜곡하고, 일정한 도착률로 다시 재자 순위와 약점이 달라졌습니다. 이 글은 앞서 다룬 이해는 위임할 수 없다 (Codex 수석 엔지니어)와 Dex Horthy- 컨텍스트 엔지니어링에 있던 "코드를 안 읽고 배포한 실험" 계열의 후속편으로 읽힙니다. 일관성은 국소적 속성이 아니다 (n-the-loop)는 같은 결론을 시스템 설계에서 끌어냅니다. Kafka의 정확히 한 번 처리조차 종단 간 보장이어서 애플리케이션이 깨지 않게 설계돼야 하므로, 컴포넌트 담당자가 각자 "내 부분은 잘 돈다"고 말해도 전역 속성은 보장되지 않고 전체에 책임지는 사람이 필요하다는 논지입니다. Fowler- 에이전트 시대에 코드는 어디에 남는가 (Fragments 10월 4일)는 이 책임을 개념 모델로 풀어 줍니다. 코드는 기계에 주는 명령이면서 도메인의 개념 모델이므로, 생성이 싸질수록 명령 작성보다 어휘를 찾아가는 일이 중요해지고 수동적 리뷰어가 되어서는 안 된다는 것입니다. 다만 Fowler는 사람이 읽는 최상위 표기를 남겨야 한다는 쪽이고, DHH와 Geoffrey Huntley는 사람이 이해하기 쉬운 코드라는 목표를 더는 믿지 않는다는 쪽이어서 여기서 입장이 갈립니다. Sam Ruby가 든 숫자(같은 앱이 Ruby/Rails로는 약 6만 토큰, C로 컴파일하면 400만 토큰)는 후자의 가정이 컨텍스트 창 때문에 성립하기 어렵다는 반론입니다. LLM 역량에 대한 공유된 이해의 격차가 벌어진다 (Andrej Karpathy)는 이 논쟁의 배경이 되는 관찰입니다. 최상위 모델을 업무로 쓰는 약 0.2%와 나머지 사이의 인식 격차가 깔때기처럼 벌어지고, 사람의 검토와 이해가 뒤처지기 시작했다는 것입니다. 네 글을 이으면, 이해를 맡길 수 없다는 주장이 감각(이해가 병목이다)에서 실험(Campfire)과 설계 논리(일관성)로 내려왔고, 남은 쟁점은 사람이 읽는 표기를 어디까지 남기느냐입니다. 앞서 다룬 이해가 새로운 병목이다 (Geoffrey Litt, Notion)과 Naur- 이론 구축으로서의 프로그래밍 (1985)에 이어서 읽을 수 있습니다.

에이전트의 자기 보고를 어디서 검증하는가

초록색 종료 코드는 일이 됐다는 증거가 아니다 (Chase Hughes)는 에이전트 루프의 exit 0이 관찰이 아니라 모델이 "done"을 냈다는 자기 평가일 뿐이라고 짚고, 검증은 에이전트가 쓰지 않은 산출물 상태에서 해야 한다고 처방합니다. 이 처방을 시스템으로 구현한 사례가 단일 에이전트는 증거와 권한을 섞는다 (Cloudflare 보안 운영 하네스)입니다. Cloudflare는 증거 수집과 고객 범위 고정을 모델 앞단의 결정론적 코드로 옮기고, 전문 에이전트가 증거 항목을 인용하면 코드가 그 인용이 실제로 존재하고 주장을 뒷받침하는지 검사합니다. 핵심 교훈인 "프롬프트는 경계가 될 수 없다"는 앞의 Campfire 사례에서 프롬프트가 비워 둔 결정이 동전 던지기가 된 것과 같은 문제를 반대편에서 본 것입니다. 에이전트의 확신을 합성하고 보정하고 심판에게 검증시키기 (Stack Overflow)는 검증을 확신도로 계량합니다. 모델 자기평가의 가중치를 가장 낮게(0.25) 두고 결정론적 검증, 다른 계열 심판의 반박, 과거 정확도를 합성하며, 사람 이관이 승인 버튼뿐이면 앵커링 때문에 가짜 책임만 만든다고 경고합니다. ReviewBench- AI 코드 리뷰 오프라인 벤치마크 (GitHub)는 검증하는 쪽, 곧 AI 리뷰어 자체를 재는 도구입니다. 오프라인 점수가 온라인 A/B 결과의 방향을 예측했다고 하지만 제작자가 자기 제품에 쓴 자체 보고라서 에누리해서 읽어야 합니다. 이 흐름에서 가장 서늘한 글은 Lean 검증이 자연어 증명의 정확성을 보장하지 않는다 (Navier-Stokes 사례)입니다. AI가 자연어 증명을 Lean으로 번역해 기계가 검증해도, 번역이 충실한지는 별개의 문제이고 그것이 정지 문제보다 어렵다는 주장입니다. 개발에 옮기면 "검증기가 통과시켰다"와 "의도한 것이 검증됐다"는 다른 말이라는 뜻이고(이는 이 글의 해석이고 논문의 주장은 아닙니다), 명세나 테스트를 AI가 번역해 만든 경우에도 같은 간극이 생길 수 있습니다. 앞 글들이 검증을 에이전트 바깥에 두자고 한다면 이 논문은 바깥의 검증기도 번역 층에서 속을 수 있다고 덧붙이는 셈입니다. 앞서 다룬 에이전트는 끝났다고 했고 데이터베이스는 아니라고 했다 (Microsoft ThinkingBox)와 TLA+가 검증할 수 있는 것과 없는 것 (Hillel Wayne)이 지난주에 같은 문제를 다뤘고, 이번 주 글들은 그것을 설계 패턴과 한계 증명으로 확장했습니다.

세부, 평범한 일, 공동체를 잃는 개인의 목소리

세부를 잃는 슬픔 (purplesyringa)은 논증이 아니라 일기라고 스스로 밝힌 글입니다. 저수준 세부와 기계를 이해하는 데서 즐거움을 얻던 저자가, LLM이 느린 코드의 핫 루프를 찾고 포인터 출처까지 설명해 주니 세부 전문성을 따로 고용할 이유가 줄었다고 쓰며 아끼는 일에는 LLM을 쓰지 않기로 합니다. 프로그래밍은 특별하지 않다 (Glyph)는 같은 상실감을 논증으로 바꿉니다. 작가와 미술가는 집단으로 AI에 저항하는데 프로그래머만 체념하고, 평범한 일을 AI로 지우면 걸작이 나올 연습 기회가 사라진다는 것입니다. 평범한 프로젝트 하나가 걸작이 될 확률을 0.1%로 놓으면 모든 프로젝트를 AI로 하는 순간 "가끔은 반드시"가 "영영 없음"이 된다는 확률 비유가 핵심입니다. AI는 지적 공동체를 해체한다 (borretti.me)는 한 단계 더 나아가 개인의 지적 활동에 연료가 되는 외부 공동체와 인정이 AI 때문에 사라진다고 봅니다. 블로그 글은 학습에 흡수되고 질문은 출처 없이 답해지니 공유지에 기여할 이유가 줄어든다는 것입니다. 세 글은 모두 "AI가 일을 대신하면 사람의 성장 경로가 막힌다"는 같은 직관을 다른 층위에서 말하고, 앞서 다룬 AI 코딩은 전문성을 막는다 (Lars Faye)와 AI 사용을 그만두기로 한 이유 (Brett)에 이어집니다. 갈리는 지점은 처방입니다. purplesyringa는 쓰지 않는 쪽으로 물러나고, Glyph는 평범한 일을 의도적으로 지키라고 하며, 지속 가능한 웹 커리어 (David Bushell)는 접근성, CSS, 소통처럼 희소해질 기술을 쌓고 React와 GitHub 의존은 버리라고 합니다. 다만 Bushell의 글은 근거나 수치가 없는 의견 에세이여서, 앞의 두 글과는 달리 "남는 기술"에 대한 한 실무자의 판단으로 읽어야 합니다. 이 쪽의 반대편 증거로 2026 Stack Overflow 개발자 설문 결과는 사용자의 73%가 AI 도구를 매일 쓰고도 52%는 여전히 일반 코딩 기술을 배운다고 답한 숫자를 줍니다. 그리고 소프트웨어 블로깅 안티패턴 (Refactoring English)은 글쓰기를 AI에 맡겨 블로그가 밋밋하고 비슷해지는 지금은 개성이 차별점이라고 해서, borretti의 공동체 진단과 닿는 실용적인 이면을 보여줍니다.

에이전트의 규모와 속도가 인프라와 하네스에 거는 압력

에이전트 규모의 개발을 위한 Git 인프라 재설계 (GitHub)는 에이전트가 행동 하나마다 커밋하므로 월간 push가 1년 새 6.9억에서 33.5억 건으로 4.9배 늘었고, 병목은 읽기가 아니라 쓰기라고 합니다. 복제본이 곧 읽기 확장 수단이자 모든 쓰기의 참여자인 현재 구조(Spokes)를, 합의가 필요한 ref 갱신만 조율하고 저장과 컴퓨트를 분리하는 구조로 바꾼다는 선언이지만 실제 설계 세부는 후속 글로 미뤄져 있습니다. 에이전트가 코드를 쓰는 속도를 보호가 따라가야 한다 (GitHub 시크릿 보호)는 같은 압력을 보안에서 봅니다. AI 에이전트가 관여한 PR이 1년 사이 10건 중 1건 미만에서 3건 중 1건이 됐는데, 푸시당 유출 비율에는 유의한 추세가 없었으니 개발자가 부주의해진 것이 아니라 양이 늘어난 것이고, 예방은 컴퓨트로 확장되지만 유출 한 건을 수동으로 폐기하는 데 평균 약 40일이 걸리는 사후 대응은 사람 수로만 확장된다는 논지입니다. 두 글 모두 자사 제품 홍보를 겸한 자체 보고이니 숫자는 방향을 보는 용도로 쓰는 편이 안전합니다. 코딩 에이전트는 왜 이렇게 멍청한가 (Michael Lynch)는 이 규모의 바닥에서 사용자가 겪는 불만을 모읍니다. 모델은 좋아졌는데 병목은 모델과 코드베이스를 잇는 하네스이고, 작업 위임, 계획 전달, 샌드박스가 기본 수준에도 못 미친다는 것입니다. 반대로 DeepSeek 4.1 Flash를 한 달 쓴 후기- 충분히 좋은 모델이 일하는 방식을 바꾼다 (dgt.is)는 값싼 모델이 충분히 좋으면 무인 작업과 탐색에 부담 없이 에이전트를 돌릴 수 있고, 중요한 곳에만 상위 모델을 "새로운 눈"으로 부른다는 주관적 사용기입니다. 이 사용기는 벤치마크가 아닌 체감에 기댄 글이어서 근거가 약하지만, 비용이 내려가면 위의 쓰기 부하와 검증 부담이 더 커진다는 방향으로는 앞의 글들과 이어집니다. 기술 쪽의 작은 소식들은 이 주제와 거리가 있지만 같은 결로 읽을 수 있습니다. Workers 운영 환경 온디맨드 프로파일링 (Cloudflare)는 로컬이 아니라 운영 환경에서 프로파일해야 앱이 이해된다는 사례이고, Deno를 떠나 Node로 돌아온 이유 (David Bushell)은 pnpm의 릴리스 지연 설정으로 공급망을 방어하는 개인 구성입니다. 앞서 다룬 Ferd- 인간은 루프의 어디에 있어야 하나와 느려져야 빨라진다 (Gergely Orosz, Craft 2026 키노트)가 던진 "속도를 사람이 감당할 수 있는 양으로 맞춰라"라는 질문이 인프라 층에서도 확인된 한 주였습니다.

이번 주의 두 편

• 읽지 않고 맡긴 Campfire 재작성이 보여준 것, 그래도 생각해야 한다 (Piotr Sarnacki): 코드를 읽지 않고 맡긴 재작성을 실제 코드와 부하 측정으로 해부해 "이해는 위임할 수 없다"를 실험으로 뒷받침한 글입니다.
• 일관성은 국소적 속성이 아니다 (n-the-loop): 전역 속성은 컴포넌트가 아니라 전체를 이해하는 사람에게 뿌리를 둔다는 논지가 이론 구축과 책임 논의를 설계 쪽에서 잇는 짧고 단단한 글입니다.