Blast Radius

Addy Osmani의 2026년 6월 15일 글 **“Agentic Code Review”**는 AI 코딩 에이전트가 보편화된 뒤 코드 리뷰의 의미가 어떻게 바뀌었는지 다룹니다. 글의 핵심은 단순합니다. 코드 작성은 기계 속도로 빨라졌지만, 사람이 변경을 이해하고 신뢰하는 속도는 거의 그대로이기 때문에 병목은 리뷰와 검증으로 이동했다는 것입니다. 원문: Agentic Code Review — Addy Osmani TL;DR 핵심 정리 병목 이동: AI는 수천 줄의 코드를 빠르게 만들지만, 사람이 “이 변경을 믿어도 되는가"를 판단하는 속도는 그대로다. 데이터의 경고: Faros는 AI 채택이 높은 팀에서 code churn 861%, incidents-to-PR ratio 242.7%, median review duration 441.5%, zero-review merge 31.3% 증가를 보고했다. 상황별 리뷰: 솔로 프로토타입과 결제·인증·개인정보를 다루는 장기 운영 시스템은 같은 리뷰 규칙을 적용하면 안 된다. 의도 복원 비용: 에이전트가 만든 diff에는 구현 의도와 대안 검토가 사라지기 쉬우므로, PR에 decision log와 테스트 증거를 붙여야 한다. 사람의 역할 변화: 사람은 모든 줄을 읽는 reviewer에서 risk tiering, sampling, audit, high-blast-radius gate를 책임지는 owner로 이동한다. 1) 코드 작성은 싸졌고, 이해는 그대로 비싸다 과거 코드 리뷰는 속도의 균형 위에 있었습니다. 주니어가 코드를 작성하는 속도보다 시니어가 읽는 속도가 빨랐기 때문에, 리뷰는 자연스럽게 병목이 되지 않았습니다. 하지만 에이전트는 이 균형을 깨뜨립니다. ...

Peter Szász가 “엔지니어링 매니저(EM) 역할에 에이전트를 적용하면 어떻게 될까?“라는 사고 실험을 통해 기회와 리스크를 동시에 드러내는 글입니다. 코드 완성에서 에이전틱 엔지니어링으로 넘어가는 흐름이 매니지먼트 영역까지 확장될 수 있는지 탐색합니다. 원문: Agentic Engineering Management TL;DR 요약 에이전트 정의: 사용자 프롬프트로부터 목표 달성까지 “도구 호출 → LLM 평가” 루프를 자율적으로 반복하는 시스템. EM 분해: Execution(실행), Team Dynamics(팀 다이내믹스), Personal Development(개인 성장) 3축. 위로 갈수록 사람과의 거리는 가깝고 리스크는 높아진다. 두 평가 축: ① Autonomy Fitness — 반복성·데이터 풍부도·모호성·가역성. ② Trust Gradient — 개인적일수록 신뢰 리스크 증가. 하네스 설계: confidence threshold, dry-run, blast radius limit, reversibility, audit trail로 자율성 강도 조절. 결론: 신뢰가 깨지면 매니지먼트는 무너진다. 그러나 하네스 설계가 없으면 EM은 “풀타임 에이전트 베이비시터"가 된다. 핵심 정의 Agent: 초기 프롬프트에서 시작해 목표가 충족될 때까지 도구 호출과 LLM 평가를 반복하는 루프. Engineering Management: 비즈니스 목표에 부합하는 결과(outcome)를 전달하도록 팀을 이끄는 일. EM의 일은 세 가지로 분해된다: ...

출처: https://addyosmani.com/blog/bias-towards-action/ 이 글에서 저자는 “행동 지향성"이 단순히 무모하게 빨리 움직이는 것이 아니라, 학습 속도를 높이되 실패해도 치명적이지 않은 시스템을 구축하는 것 이라고 강조합니다. 1. 핵심 개념: “실행 가능한 최소한의 단계” 정의: 행동 지향성이란 실제 피드백을 얻을 수 있는 가장 작고 책임감 있는 단계 를 기본값으로 설정하는 것입니다. 오해: 단순히 스타트업 창업자가 소리치는 무모한 구호가 아닙니다. 제대로 된 행동 지향성은 “내가 틀렸을 때 어떻게 회복할지"를 정확히 아는 상태에서 움직이는 것입니다. 2. 가드레일(안전장치)의 중요성 빠르게 움직이는 팀은 단순히 속도가 빠른 것이 아니라, 실패해도 죽지 않는 시스템을 갖추고 있습니다. ...

보내주신 글은 현직 개발자와 관리자가 느끼는 “AI 환상(Hype)과 실제 업무 사이의 괴리” 를 아주 날카롭게 짚고 있습니다. 특히 단순한 성능 지표가 아닌, 작업의 복잡도 와 부작용(Side-effects) 이라는 두 축으로 AI의 유용성을 정의한 점이 매우 인상적입니다. 출처: Getting Real With LLMs - Gilad Peleg 🚀 실무 중심의 AI 활용 매트릭스 이 글은 엔지니어링 업무를 복잡도(X축) 와 부작용/파급력(Y축) 으로 나누어, 현재 LLM이 실제로 도움이 되는 영역과 단순히 “연기(Smoke & Mirrors)“에 불과한 영역을 구분합니다. ...