AI가 소프트웨어 엔지니어를 대체할 것이라는 전망이 끊임없이 제기되지만, 실제 데이터는 정반대의 그림을 보여주고 있습니다. AI 적용이 가장 빠르고 앞선 분야인 소프트웨어 엔지니어링에서조차 대규모 해고나 노동력 감소는 일어나지 않았으며, 그 이유는 단순히 AI의 능력 부족이 아니라 소프트웨어 개발이라는 작업의 근본적인 구조 에 있습니다. TL;DR 요약 AI 해고는 대부분 AI 워싱 : Block, Snap, Intuit 등 유명 기업의 해고 사례 분석 결과 실제 원인은 재정 압박과 구조조정이었으며, 뉴욕주 WARN Act에서 AI 관련 체크박스를 사용한 사례는 0.2%에 불과하다. Decide-Execute-Deliver Sandwich : AI는 중간의 Execute(코딩)만 압축했을 뿐, 양 끝의 Decide(무엇을 만들지 결정)와 Deliver(테스트·검증·배포·책임)는 여전히 인간의 깊은 맥락 이해가 필요하다. 코딩은 전체 업무의 일부에 불과하다 : 개발자들이 실제로 코딩에 사용하는 시간은 9~61% 수준이며, 나머지는 미팅·디버깅·코드베이스 이해 등에 소요된다. 미국 소프트웨어 엔지니어 고용은 여전히 성장 중 : AI 이후 성장률이 다소 둔화되었을 뿐, 절대 고용 수치는 감소하지 않았다. 원문: Why AI hasn’t replaced software engineers, and won’t ...

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는 코딩 에이전트 사용법의 양극단을 비판합니다. ...

출처: https://www.categoryvc.com/writing/where-the-ai-hardware-market-is 이 글은 2026년 현재 AI 인퍼런스 시장을 “누가 더 많은 FLOPS를 내느냐"가 아니라 “누가 메모리 병목을 더 잘 푸느냐"의 관점으로 재정리합니다. 특히 LLM serving의 실제 병목이 prefill과 decode에서 다르게 나타난다는 점을 기준으로, 어떤 레이어에서 기업들이 경쟁하는지 살펴봅니다. TL;DR 핵심 정리 병목의 본질: H100급 GPU에서도 LLM autoregressive decode 구간은 메모리 대역폭 제약이 커서 Tensor Core 사용률이 낮아지기 쉽다. 칩 레벨 전략: Groq·Cerebras·d-Matrix류 접근은 연산 유닛 증설보다 메모리-연산 거리 단축(SRAM, scratchpad, wafer scale)으로 성능을 끌어올린다. 소프트웨어 전략: RadixArk(SGLang), Inferact(vLLM) 같은 엔진 경쟁의 핵심은 prefill(연산 중심)과 decode(메모리 중심)를 분리 최적화하는 스케줄링이다. 인프라 전략: KV cache를 GPU→CPU RAM→NVMe→S3로 계층화하면 긴 컨텍스트 비용을 줄이고 재사용률을 높일 수 있다. 시장 결론: 승자는 “NVIDIA 대체"보다 “특정 병목 해결"에서 먼저 나오며, 이후 클라우드·엔진·플랫폼에 통합될 확률이 높다. 1) 왜 지금도 GPU는 놀고 있는가 많은 팀이 “GPU가 비싸다"는 문제를 이야기하지만, 더 정확히는 “GPU 안의 연산 장치가 놀고 있다"는 문제가 큽니다. 이유는 단순합니다. ...

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 기반 에이전트를 **“프로그래밍 분포를 모사하는 통계 모델”**로 규정합니다. 즉, 결과물이 사람 코드처럼 보일 수는 있지만, 실제로는 인간 개발자가 수행하는 문제 분해·검증·의도 보존의 과정을 동일하게 재현하지 못한다는 입장입니다. ...