Posts

Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다. 원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12) TL;DR 요약 세 가지 미덕: Larry Wall의 Programming Perl(“Camel Book”)이 말한 Laziness, Impatience, and Hubris는 좋은 소프트웨어 설계의 토대였다. 진짜 게으름: 문제를 머릿속에서 굴리고 또 굴려, 미래의 개발자에게 도움이 되는 강력한 추상화를 만들어내는 지적 노동이다. LLM의 결함: 일에 비용이 들지 않으니 “쓰레기의 레이어케이크에 더 많은 것을 기쁘게 쌓아 올린다” — 시간 희소성을 겪지 않기에 게으름의 미덕이 작동하지 않는다. 숫자 대비: Garry Tan이 자랑한 하루 37,000줄(여전히 가속 중) vs DTrace 전체 약 60,000줄. 폴란드 엔지니어 Gregorein의 분석은 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(하나는 0바이트)을 발견. 결론: “최고의 엔지니어링은 항상 제약에서 태어난다.” LLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야지, 자율 개발자로 풀어주어선 안 된다. Oxide의 LLM 가이드라인(RFD 0576)이 그 사례. 시작점 — Larry Wall이 정의한 세 미덕 Cantrill은 Programming Perl(통칭 “Camel Book”)의 한 줄을 다시 끌어옵니다. ...

Addy Osmani가 2026년 4월에 정리한 글입니다. 핵심 명제는 단순합니다 — 코딩 에이전트 = 모델 + 그 주변에 당신이 만든 모든 것이고, 그 “주변"을 진지하게 다루는 규율을 하네스 엔지니어링이라 부릅니다. 원문: Agent Harness Engineering — Addy Osmani (2026-04-19) 한 줄 A decent model with a great harness beats a great model with a bad harness. 평범한 모델 + 훌륭한 하네스가, 훌륭한 모델 + 나쁜 하네스를 이깁니다. Claude Code, Cursor, Codex, Aider, Cline이 종종 동일한 모델을 쓰면서 행동이 완전히 갈리는 이유는 모델이 아니라 하네스 차이에 있습니다. ...

LLM 하이프 사이클이 시작될 때, 우리 시대의 큰 논쟁 중 하나가 Python과 Markdown 사이의 에이전트 명세 언어 선택이 될 거라고는 아무도 예상하지 못했습니다. 하지만 The AI Frontier(Vikram Sreekanti 외)가 Agent Native 시리즈의 일부로 짚듯, 이 질문은 빠르게 AI 아키텍처에서 가장 결정적인 논쟁이 되었습니다. 글의 핵심 주장은 단순합니다 — 이 논쟁은 두 개의 방어 가능한 입장 사이의 선택이 아니라, 양쪽 모두 실패 모드라는 것입니다. 어느 쪽도 agent-native가 아니기 때문입니다. TL;DR 요약 가짜 선택지: Python 캠프는 단계의 엄격한 요구사항을 코드로 표현하고, Markdown 캠프는 영어로 목표·제약을 주고 계획을 맡긴다. 양쪽 다 극단에 가면 에이전트의 본질을 망친다. 코드 최대주의의 세 가지 실패: 인간의 직렬 가설 추적을 모방, 시도/배제 이유에 대한 가시성 부재, 시스템이 바뀌면 진화하지 못함 — RunLLM이 AI SRE 런북 접근에서 초기에 직접 부딪힌 함정. 마크다운 최대주의의 실패는 AI 슬라이드 생성에서 보인다 — “슬라이드 7번 레이아웃을 세로로, 차트는 아래로"를 지정할 수 있는 주소 가능한 단위가 없다. 하이브리드는 타협이 아니다: 컨텍스트 관리·모델 선택·비용·교차 에이전트 조정 같은 부분은 결국 code harness로 흡수된다. Claude Code와 RunLLM이 독립적으로 같은 자리에 도달했다. Agent-native 판정 4문항: 가설 병렬 평가? 시도/배제 가시성? 시스템 변화 적응? 사용자 단위의 교정 granularity? 원문: Agents can’t choose between structure and flexibility — The AI Frontier (Agent Native series) ...

LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다. 원문: All Your Agents Are Going Async — Zak Knill (2026) 핵심 도발 “The interesting thing is what agents can do while not being synchronously supervised by a human.” 흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다. ...

“한 명의 개발자가 24개의 Claude를 동시에 부린다.” — 2026년 에이전틱 개발 도구 마케팅이 즐겨 그리는 그림입니다. Maggie Appleton(GitHub Next, Staff Research Engineer)은 이 그림이 틀린 문제를 풀고 있다고 말합니다. 구현이 빨라진 만큼, 진짜 병목은 다른 곳으로 옮겨갔습니다 — 무엇을 만들지에 대한 팀의 합의. 원문: One Developer, Two Dozen Agents, Zero Alignment — Maggie Appleton (2026) 핵심 도발 “Software is not made by one person in a vacuum. It’s a team sport.” ...

Martin Fowler가 간헐적으로 올리는 Fragments 시리즈는 최근 읽은 글들에 대한 짧은 주석 모음입니다. 2026년 4월 2일자는 유독 밀도가 높습니다 — 부채의 재정의, 사고 시스템의 확장, 검증의 경제학, 그리고 언어와 이름 짓기에 관한 다섯 개의 조각이 한 페이지에 놓여 있습니다. LLM이 코드를 생성하는 시대에 인간이 무엇에 집중해야 하는지에 대한 하나의 일관된 그림이 드러납니다. 원문: Fragments: April 2 — Martin Fowler (2026) 조각 1. 시스템 건강의 세 층위 — Technical / Cognitive / Intent Debt Margaret-Anne Storey의 논문이 제시하는 프레임은 기술 부채(technical debt) 개념의 한계를 정면으로 겨냥합니다. ...

소프트웨어는 결정론적 공학에서 확률적 공학으로 전환되고 있습니다. 에이전트는 사람이 잠든 사이에도 코드를 생성하지만, 그것을 검증할 용량은 같이 자라지 않습니다. Tim Davis는 이 비대칭이 역할, 조직, 그리고 엔지니어가 살아남기 위해 쌓아야 할 근육 자체를 재편한다고 주장합니다. 원문: Probabilistic Engineering and the 24-7 Employee — Tim Davis (2026) 핵심 논제 “지식 노동 역사상 처음으로, 집에 간 사람이 자기 뇌의 유일한 사본을 들고 가지 않는다.” 저자가 운영하는 Compound Loop는 밤새 자율적으로 PR을 생성하는 코딩 시스템입니다. 24/7 근무하는 사람이 생긴 것이 아니라, 병렬화된 에이전트 노동이 생긴 것 — 이 차이가 모든 논의의 출발점입니다. ...

“백만 토큰당 $X” 는 LLM 가격을 비교하는 가장 흔한 기준이지만, TensorZero의 Gabriel Bianconi는 이 기준이 근본적으로 망가졌다고 주장합니다. 동일한 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성하기 때문입니다. 리스트 가격이 비슷해 보여도 실효 비용은 크게 벌어지며, 특히 도구(tool) 정의가 많은 에이전트 워크로드에서 순위가 뒤집힙니다. 원문: Stop comparing price per million tokens: the hidden LLM API costs — Gabriel Bianconi, TensorZero (2026-04-16) · 오픈소스: tensorzero/tensorzero 핵심 주장 같은 입력이 모델에 따라 2.65배 이상 더 많은 토큰을 생성한다. ...

Shann Holmberg는 에이전트가 쓸모 없는 근본 이유는 지식을 보관하지 않기 때문이라고 주장합니다. 모든 대화가 0에서 시작하고, 매번 비즈니스 맥락·목소리·목표를 재설명해야 하며, 결과는 늘 제네릭합니다. 해법은 에이전트와 사용자 사이에 앉는 Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어 시스템입니다. 20분 셋업, 매일 스스로 개선, 오픈소스. 원문: AI Knowledge Layer (and why your agents are useless without it) — Shann Holmberg · 구현체: shannhk/llm-wikid 핵심 문제 — 에이전트는 매번 0에서 시작한다 대부분의 팀이 겪는 패턴: ...

개발자 문서를 인간 독자만을 대상으로 최적화하는 시대가 끝나가고 있습니다. AI 코딩 에이전트는 문서를 전혀 다른 방식으로 소비하며, 기존 포털은 점점 에이전트에게 보이지 않는 존재가 되고 있습니다. Addy Osmani는 이를 해결하기 위한 새로운 규율로 Agentic Engine Optimization(AEO) 을 제안합니다. 과거 SEO가 검색 크롤러를 위해 콘텐츠를 구조화했던 것처럼, AEO는 에이전트가 실제로 사용할 수 있도록 기술 콘텐츠를 구조화·포맷팅·제공하는 실천입니다. 왜 AEO인가 — 에이전트는 인간처럼 읽지 않는다 인간 패턴: 4~8분간 섹션을 점진적으로 클릭하며 탐색. 스크롤 깊이, 체류 시간, 링크 클릭 같은 분석 이벤트가 발생. 에이전트 패턴: 여러 페이지 탐색을 1~2개의 HTTP 요청으로 압축. 클라이언트 사이드 분석 이벤트는 전혀 남지 않음. 서버 로그에는 고유한 에이전트 핑거프린트가 남음 — Claude Code는 axios/1.8.4, Cline/Junie는 curl/8.4.0, Cursor는 got, Aider·OpenCode는 headless Chromium. 토큰 문제 — 문서 크기는 이제 1급 지표다 Cisco Secure Firewall Management Center REST API 퀵스타트는 193,217 토큰으로, 대부분 에이전트의 사용 가능 컨텍스트를 초과합니다. 이런 경우 에이전트는 조용히 잘라내거나, 건너뛰거나, 솔루션을 환각합니다. ...