Posts

Ed Zitron이 2026년 6월 8일 발표한 “AI Is Slowing Down” 은 AI 산업(특히 OpenAI와 Anthropic 중심)을 강하게 비판하는 장문의 분석입니다. 핵심 주장은 AI가 과도한 투자와 약속에 비해 성장 속도가 둔화되고 있으며, 이는 거품 붕괴의 신호 라는 것입니다. 원문: AI Is Slowing Down 3줄 핵심 정리 핵심 주장: AI 산업이 수조 달러 투자를 정당화하려면 2030년까지 연간 최소 $2~3T 매출이 필요하지만, 현재 수요는 OpenAI + Anthropic 두 회사에 집중되어 있고 그마저도 적자다. 지출 둔화 증거: Uber, T-Mobile, Brex 등이 token-based billing의 예측 불가능한 비용에 대응해 AI token 지출 상한(cap)을 도입했으며, CFO들은 ROI 측정이 거의 불가능하다고 보고한다. 순환 경제의 붕괴 위험: AI labs → hyperscalers → NVIDIA로 이어지는 circular economy가 유지되려면 매년 2배씩 성장해야 하지만, 실제 제품 가치가 부족해 지속이 불가능하다. IPO 압박: OpenAI와 Anthropic의 IPO 준비는 보다 현실적인 수익 모델(비용 인상, 보조금 축소)을 강요할 것이며, 이는 거품 수축을 가속화할 전망이다. 1) AI는 반드시 폭발적으로 성장해야 하지만, 현실은 그렇지 않다 데이터센터 건설(190GW 규모)과 GPU 구매 등으로 수조 달러 규모의 투자 가 이뤄지고 있습니다. NVIDIA, hyperscalers(Google, Microsoft, Amazon 등), OpenAI/Anthropic의 compute commitment는 수천억 달러에 달합니다. ...

Christoph Nakazawa(React/Vite/Jest 핵심 기여자)가 2026년 6월, AI 코딩 에이전트(특히 Codex CLI + GPT 5.5)로 여러 프로젝트를 거의 100% AI로 개발/개선한 경험을 바탕으로 엔지니어링의 핵심 가치가 어떻게 변화해야 하는지 정리한 글입니다. 원문: Modern Engineering Values TL;DR 요약 강한 소유권(Strong Ownership) : 도메인을 깊이 아는 2~3명 팀이 독립된 저장소에서 일할 때 AI의 증폭 효과가 극대화된다. 코드 리뷰는 스타일 논쟁이 아닌 ‘정렬(alignment)’ 중심으로. 취향(Taste) : AI는 엄청난 양의 쓰레기 코드도 빠르게 생성한다. 중요한 것은 ‘무엇을 만들 가치가 있는지’ 판단하는 능력. 가드레일과 피드백 루프 : 린트·자동 테스트·빠른 검증 도구가 강력할수록 AI가 빠르고 정확하게 일한다. 변경된 파일 중심으로 동작해야 함. Repo 속 맥락 : AI 세션은 매번 새로운 직원이 들어오는 것과 같다. 모든 원칙과 설계를 저장소 안에 명확히 문서화하라. 직접 소유(Own your Stack) : 핵심 부분(데이터, UI, i18n)은 직접 소유해 제품 경험을 완전히 통제하라. 옵션 가치 : 변경할 때마다 미래에 더 많은 선택지를 열어주는 방향으로 설계하라. 핵심 메시지 — 코딩이 병목에서 판단으로 AI 코딩 에이전트(Codex CLI + GPT 5.5)가 등장하면서 프로그래밍 방식이 근본적으로 바뀌었다. 이제 손으로 코드를 거의 쓰지 않게 되었고 , 에이전트가 인간 수준 이상의 코드를 몇 분 만에 작성한다. 코딩 자체는 더 이상 병목이 아니며, 엔지니어링의 본질은 “코드를 직접 쓰는 것” 에서 시스템을 지휘하고 판단하는 것 으로 이동했다. ...

Addy Osmani가 2026년 6월 8일 Substack을 통해 제시한 개념으로, AI 코딩 에이전트(Claude Code, Codex 등)를 직접 프롬프트 하는 대신 에이전트를 프롬프트하고 관리하는 시스템(Loop) 을 설계하는 접근법입니다. 원문: Loop Engineering TL;DR 요약 핵심 전환 : “에이전트를 프롬프트하지 말고, 에이전트를 프롬프트하는 Loop를 설계하라” — 프롬프트 엔지니어링에서 시스템 설계로의 전환. Loop의 정의 : AI가 스스로 작업 발견 → 처리 → 검증 → 다음 작업 결정하는 재귀적·자동화된 루프. 타이머 기반 실행, 하위 에이전트 생성, 자체 유지. 5+1 구성 요소 : Automations(스케줄 기반 작업 발견), Worktrees(병렬 작업 격리), Skills(프로젝트 지식 저장), Plugins(외부 도구 연결), Sub-agents(Maker-Checker 분리), Memory(디스크 기반 상태 관리). 실전 예시 : 매일 아침 자동화로 CI 실패 발견 → Skills로 분석 → Worktree에서 Sub-agent 수정 → PR 생성 → 티켓 업데이트. 리스크 : 검증은 여전히 인간 몫이며, Comprehension Debt와 Cognitive Surrender가 주요 위험 요소. 핵심 개념 Loop Engineering은 Agent Harness Engineering의 상위 개념입니다. ...

Alex Self가 AI(특히 Claude)를 활용한 개발 과정에서 신뢰 부족 을 극복하기 위해 만든 ‘자동화된 의심(Automated Doubt)’ 프로세스를 소개합니다. 핵심은 다중 에이전트(multi-agent) 를 통해 설계·구현 단계에서 철저한 검증과 비판을 앞당기는 것입니다. 원문: My Automated Doubt Development Process TL;DR 요약 핵심 문제 : AI에 “너무 많이, 너무 빨리” 맡기다 신뢰를 잃음. 하나의 LLM으로는 놓치는 부분이 많다. 해결책 : 의심(doubt)을 자동화하고, 여러 관점(parallax)에서 반복 검증하는 다중 에이전트 프로세스. Phase 1 - Design : Pre-Implementation Architect, Assumption Excavator, Gap Analyzer 등으로 Spec 검증 (10~25개 findings). Phase 2 - Development : 구현은 단일 Claude가 담당. Post-Implementation Workflow에서 Code Validator, Security Analyst 등으로 15~35개 findings 도출 후 수정 반복. Phase 3 - Ship : Anxiety Reader, API Contract Validator, Release Readiness Validator 등으로 최종 배포 적합성 판단. 주요 철학 초기 AI 사용 시 “너무 많이, 너무 빨리” 맡기다 신뢰를 잃음. 해결책: 의심(doubt)을 자동화 하고, 여러 관점(parallax)에서 반복 검증. 하나의 LLM이 아닌, 특화된 서브에이전트 들을 활용해 설계 누락, 가정, 보안, 완전성 등을 철저히 파헤침. 개발 프로세스 3단계 1. Phase 1 — Design (설계 단계) 아이디어 → Claude에게 Spec(PRD) 작성 요청으로 시작합니다. ...

Jordan Cutler(Pinterest Staff Engineer)가 Senior에서 Staff Engineer로 성장하는 데 필요한 마인드셋 변화 와 실전 사례를 정리한 글입니다. Staff Engineer는 단순히 더 깊은 기술력이나 빠른 실행력이 아니라, 다른 차원의 영향력 을 발휘하는 역할이라는 점을 강조합니다. 원문: How to Grow From Senior to Staff Engineer in the AI Era TL;DR 요약 핵심 전환: Senior → Staff는 “내가 더 많은 코드를 쓰는 것"에서 “다른 사람들이 더 많은 일을 할 수 있게 만드는 것"으로의 전환이다. Surface Area 확장: 주어진 업무 외에 자발적으로 기회를 만들고 가치를 먼저 증명하면 조직적 영향력이 따라온다. 팀 간 영향력: 문제만 지적하지 말고, 데이터 + 구체적 해결책 + 도움 제안을 함께 전달해야 신뢰와 실행을 이끌어낸다. 확장 가능한 시스템: 내가 없어도 돌아가고, 다른 팀까지 자연스럽게 확장되는 시스템을 구축하는 것이 multiplier의 본질이다. AI 시대 함의: Heads-down 코딩에서 벗어나 영향력과 시스템을 만드는 multiplier 사고가 더 중요해졌다. Staff Engineer가 되는 데 방해가 되는 것 기술 깊이, 실행 속도, 복잡한 시스템에만 집중하는 것 “개인 기여” 중심 사고에서 벗어나지 못함 Staff로 성장하지 못하는 엔지니어들의 공통점은 기술 역량 자체가 부족해서가 아니라, 그 기술을 조직 전체로 확장하지 못한다는 점입니다. ...

Lucas F. Costa의 **“Backpressure is all you need”(2026-05-23)**는 코딩 에이전트를 더 오래, 더 안전하게 위임하기 위한 운영 원칙을 설명합니다. 글의 핵심은 단순합니다. LLM이 코드를 빠르게 생산하는 시대에는 사람이 기본 백프레셔가 되면 안 됩니다. 사람이 매번 출력물을 읽고, 실패를 찾아주고, 다시 프롬프트에 복사해 넣는 구조는 위임이 아니라 병목입니다. 원문: Backpressure is all you need Backpressure 핵심 정리 문제 진단: 에이전트를 완전히 방치하면 저품질 PR이 쏟아지고, 모든 작은 결정을 사람이 검토하면 에이전트를 쓰는 의미가 줄어든다. 핵심 해법: 사람 대신 시스템이 먼저 “아직 안 된다"고 말하게 만든다. 테스트, 타입, 린트, 벤치마크, 리뷰 에이전트, PR 모니터링이 그 역할을 한다. 운영 원칙: 체크는 마지막에 한 번이 아니라 각 패치/반복마다 실행한다. 실패하면 다음 패치로 넘어가지 말고 원인 분석 → 수정 → 재실행을 강제한다. 가장 큰 효과: 리뷰 에이전트와 PR 모니터링. 전자는 인간에게 넘어오기 전 품질 문제를 줄이고, 후자는 CI 실패·충돌·리뷰 코멘트가 남은 PR을 방치하지 않게 한다. 결론: 앞으로의 코딩 에이전트 생산성은 더 똑똑한 프롬프트보다 잘 설계된 백프레셔 루프에 달려 있다. 1) 두 가지 obvious한 사용법은 모두 나쁘다 Costa는 코딩 에이전트 사용법의 양극단을 비판합니다. ...

Shreya Shankar의 2026년 5월 21일 글 **“Exploring Agent-Assisted Qualitative Analysis”**는 “정성 분석(qualitative analysis)을 에이전트가 어디까지 도울 수 있는가"를 실제 실험으로 검토한 기록입니다. 핵심은 단순합니다. 에이전트가 텍스트를 많이 다루는 것과, 연구적으로 좋은 해석을 만드는 것은 전혀 다른 문제라는 점입니다. 원문: Exploring Agent-Assisted Qualitative Analysis TL;DR 핵심 정리 문제 설정: 저자는 grounded theory 기반 정성 분석을 대상으로, 사람 개입 정도와 멀티에이전트 구성을 바꿔 6개 조건을 비교했다. 핵심 관찰 1: 무개입 또는 약한 개입 조건에서 에이전트는 분석보다 재진술(paraphrase)에 가까운 출력을 내는 경향이 강했다. 핵심 관찰 2: exp1에서 “트윗 길이 ↔ 코드 수” 상관이 ρ=0.81로 높았고, 메모 피드백 조건(exp2-memo)에서는 ρ=0.15까지 낮아졌다. 핵심 관찰 3: 코드 재사용이 거의 일어나지 않아(예: exp1에서 코드 93.8%가 1회 사용) 누적적 코드북 형성이 약했다. 실무 결론: 정성 분석 자동화의 병목은 모델 성능보다 “언제·어떻게 사람 판단을 끼워 넣는지"를 정의하는 워크플로우 설계에 있다. 1) 왜 이 문제가 어려운가 정성 분석은 정답이 고정된 작업이 아닙니다. 같은 데이터라도 연구 질문, 독자, 맥락에 따라 서로 다른 해석이 성립할 수 있습니다. 저자는 이 지점을 AI 시스템의 난제로 봅니다. 즉, “정확도 하나"로 환원할 수 없는 작업이며, 평가 기준도 분석 과정에서 계속 변합니다. ...

geohot(George Hotz)의 2026년 5월 24일 포스트 **“The Eternal Sloptember”**는 AI 코딩 에이전트에 대한 강한 반대 의견을 담고 있습니다. 글의 톤은 도발적이지만, 문제 제기는 실무적으로 중요합니다: 생산성 수치가 좋아 보여도 코드베이스의 평균 품질은 오히려 나빠질 수 있다는 주장입니다. 원문: The Eternal Sloptember TL;DR 요약 핵심 주장: geohot은 “AI 에이전트의 소프트웨어 개발 도입"이 장기적으로 매우 비싼 비용을 유발할 수 있다고 본다. 근거 경험: tinygrad 개발과 하드웨어 리버스 엔지니어링 사례에서, 초기 속도는 빨라도 마무리 품질·정합성에서 사람이 직접 하는 편이 더 낫다고 평가한다. 조직 리스크: 고성과자는 슬롭(sloppy output)을 교정하지만, 대기업은 피드백 루프가 느려 하위 성과자의 “겉보기 10배 생산성"이 평균 품질을 끌어내릴 수 있다고 본다. 품질 착시: 문법·형식이 그럴듯한 산출물이 늘어나면서 기존 품질 프록시(문장/코드의 표면적 완성도)가 무력화된다고 지적한다. 실행 결론: 에이전트를 “대체재"가 아니라 “제한적 가속기"로 다루고, 사람이 각 라인을 이해하는 검토 규율을 버리지 말아야 한다. 1) 글의 문제의식: “에이전트는 프로그래머가 아니다” 저자는 LLM 기반 에이전트를 **“프로그래밍 분포를 모사하는 통계 모델”**로 규정합니다. 즉, 결과물이 사람 코드처럼 보일 수는 있지만, 실제로는 인간 개발자가 수행하는 문제 분해·검증·의도 보존의 과정을 동일하게 재현하지 못한다는 입장입니다. ...

이 글은 Tuhin Nair의 아티클 **「Why senior developers fail to communicate their expertise」(2026-05-12)**를 바탕으로, 시니어 개발자의 설명이 왜 조직에서 잘 받아들여지지 않는지 구조적으로 정리한 글이다. TL;DR 핵심 정리 시니어 개발자는 “덜 만들기, 재사용, 지연"을 통해 **복잡성(complexity)**을 관리하려고 한다. 반면 비즈니스 조직은 시장 학습 속도를 높여 **불확실성(uncertainty)**을 줄이는 데 집중한다. 그래서 시니어가 “유지보수성·안정성"만 강조하면, 상대의 핵심 문제를 해결하지 못해 설득이 실패한다. 저자가 제안한 실전 문장: “Can we try something quicker?” AI 시대에는 Speed(실험용)와 Scale(안정화용) 시스템을 분리해, 속도와 안정성을 동시에 달성하자는 제안이 나온다. 원문: https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise ...

LLM 에이전트 메모리의 정석처럼 여겨졌던 “경험 정리 → 텍스트 저장 → 반복 재작성” 루프가 실제로는 자기개선을 보장하지 않는다는 문제 제기입니다. 이 글은 Dylan Zhang의 **“Useful memories become faulty when continuously updated by LLMs”**를 빠르게 파악하려는 분들을 위한 정리입니다. TL;DR 요약 핵심 결과: GPT-5.4가 ARC-AGI에서 메모리 없이 100% 풀던 문제군이, 정답 기반 통합(consolidation) 후 **54%**까지 하락. 중요 포인트: 같은 데이터여도 업데이트 스케줄이 달라지면 메모리가 달라지고 성능도 달라짐(특히 Stream가 최악). 실패 원인 3가지: 잘못된 묶기(misgrouping), 과잉 일반화/간섭(interference), 반복 재작성에 따른 과적합(overfit). 실무 시사점: " 메모리 누적"보다 선별된 raw episodic evidence 보존이 더 안정적일 수 있음. 원문: https://dylanzsz.github.io/faulty-memory/ ...