개발 도구와 언어, 웹 기술과 오픈소스 프로젝트의 변화를 다룹니다.
AI 코딩 도구가 초안 생성 비용을 거의 0으로 만들었지만, 리뷰와 유지보수 비용은 그대로라서 '생산성'의 회계가 왜곡된다는 글입니다. 저자는 자신의 오픈소스 프로젝트들에서 관찰한 패턴과 METR 연구(숙련 개발자가 AI 사용 시 19% 더 느려짐)를 근거로, 생성 속도가 아닌 소유 비용(ownership cost)을 측정해야 한다고 주장합니다. 디버깅, 태스크 단위 비용, 무한 루프, 이해의 외주화라는 네 가지 숨은 비용 항목을 구체적 수치와 함께 제시합니다.
저자가 30일간 작성 에이전트와 별도의 '회의론자(skeptic)' 리뷰 에이전트를 운영한 실험 기록입니다. AI 리뷰어는 41개 실제 이슈 중 38개를 잡았지만, Stripe 웹훅의 'ack-before-persist' 같은 조용한 데이터 정합성 버그는 같은 모델 계열 특유의 공통 맹점 때문에 놓쳤고, 시니어 엔지니어는 과거 장애 경험으로 5분 만에 발견했습니다.
30일간 실제 프로덕션 SaaS의 모든 코드를 AI로 작성한 실험 후, 저자는 'AI가 개발자를 대체할 것'이라는 글 500편을 분석했습니다. 낙관론과 비관론 모두 코드 생성을 직업 전체로 착각하고, 주니어-시니어 사다리가 고정돼 있다고 가정하며, 데모를 근거로 미래를 외삽한다는 세 가지 공통된 오류를 지적합니다.
리포트 대시보드의 페이지네이션 버그를 고치던 개발자가 필터 상태 중복, 클라이언트-서버 검증 로직 중복을 연달아 발견하고 수정하다가 서버 컴포넌트 전환 직전에 멈춘 경험담입니다. 변경 파일이 하나에서 일곱 개로 불어나는 순간, '이 변경이 제품에 필요한가, 아니면 내가 하고 싶은가'를 자문해 PR을 분리했다고 합니다. 저자는 변경의 크기가 아니라 정당화에 걸리는 시간과 그 정당화가 누구를 위한 것인지가 판단 기준이라고 말합니다.
독자는 LLM이 생성한 문장을 즉시 알아채므로, 글은 직접 쓰고 LLM은 교정자(copyeditor)로만 써야 한다는 주장입니다. 모델이 제안하는 표현은 단 하나도 쓰지 말 것, 모델의 격려를 받아들이지 말 것이라는 두 규칙과 함께, 문제 지적·수정본 비교·CLI 기반 편집 도구까지 실전 워크플로를 제시합니다.
AI 코딩 도구가 대부분의 개발자보다 낫다는 주장에 대해, 실무 개발자가 연구 데이터를 근거로 반박한 글입니다. METR 연구에서 숙련된 개발자들은 AI 도구 사용 시 19% 더 오래 걸리면서도 20% 더 빠르다고 느꼈고, AI 생성 코드는 버그 발생률이 1.7배, XSS 취약점은 2.7배 높았습니다. 저자는 AI를 매일 쓰면서도 '코드를 읽고 틀린 부분을 즉시 잡아내는 능력'이야말로 지금의 핵심 역량이라고 주장합니다.
AI 코딩 도구로 몇 분 만에 동작하는 앱을 만들 수 있게 되면서, '작동하는 결과물'과 '왜 작동하는지 이해하는 것'이 혼동되고 있다는 비판 에세이입니다. 저자는 자신의 MERN 스택 프로젝트 ShelfTalk을 프로덕션 수준으로 재구축한 경험과, 탭 가시성(tab visibility) 가정이 낳은 알림 유실 버그 사례를 통해 리뷰·디버깅·설계 검증이야말로 엔지니어의 본질적인 일이라고 주장합니다.
AI로 코드를 생성하는 vibe coding 자체는 문제가 아니며, 그것을 '엔지니어링'이라 부르는 태도가 문제라는 주장입니다. 저자는 creation(만들기)과 engineering(엔지니어링)을 구분하고, 개인 프로젝트는 vibe coding으로 충분하지만 돈과 개인 데이터를 다루는 실제 제품에서는 코드 리뷰와 기초 학습이 필수라고 선을 긋습니다.
많은 조직이 소프트웨어 딜리버리를 공장 생산 문제로 오진하지만, 코드 복제는 공짜이고 만드는 모든 것이 전례 없는 것이므로 엔지니어링은 생산이 아니라 연속적인 발견(discovery) 활동입니다. 저자는 인력 투입·압박·프로세스 게이트라는 세 가지 실패한 관리 레버를 데이터로 반박하고, 학습 속도를 최적화하면 속도는 자연스럽게 부산물로 따라온다고 주장합니다.
Stripe와 Amazon 출신 엔지니어 Justin Duke가 2017년 직장을 다니며 시작한 뉴스레터 플랫폼 Buttondown이 완전 자기자본(bootstrapped)으로 ARR 100만 달러를 넘겼습니다. 바이럴 런칭이나 대규모 투자 없이 입소문·공개 글쓰기·인간적인 고객 지원으로 성장한 사례로, 안정적인 급여라는 안전망이 장기적 의사결정을 가능하게 했다는 점을 솔직하게 짚습니다.
코드 리뷰에서 명확한 근거 없이 느껴지는 '뭔가 이상하다'는 감각은 무시할 것이 아니라 아직 언어화되지 않은 데이터라는 글입니다. 침묵하면 코드는 그대로 배포되고 몇 주 뒤 장애 보고서가 되어 돌아온다고 지적하며, 확신 없이도 우려를 꺼낼 수 있는 구체적인 표현 템플릿과 3단계 방법을 제시합니다.
일본컴퓨터엔터테인먼트협회(CESA)가 Tokyo Game Show 2026에서 공개한 업계 보고서에 따르면, 일본 게임 개발자의 85.8%가 업무에 생성형 AI를 사용하는 것으로 나타났습니다. 이는 전년도 51%에서 크게 상승한 수치이며, 응답자의 63%는 매일 사용한다고 답했습니다. 다만 CESA는 지식재산권 침해 우려에 대한 업계 차원의 대응이 필요하다고 지적했습니다.
개발자가 실제 채용 과제를 받는 과정에서 위장 기업이 심어둔 악성 npm 패키지를 발견한 사례입니다. 의존성 트리에 숨어든 transitive dependency가 C2 서버와 통신하며 임의 JavaScript를 실행할 수 있는 구조였고, package.json만으로는 감지할 수 없었습니다. npm install 전에 저장소 자체를 신뢰할 수 없는 소프트웨어로 취급해야 한다는 경고를 담고 있습니다.
웹 개발 입문 시리즈의 첫 번째 단계로, 코드를 작성하기 전 알아야 할 웹의 기본 개념들을 정리한 안내서입니다. 브라우저와 서버, 프런트엔드와 백엔드, 데이터베이스, HTTP 요청과 응답, URL 구조, DNS, HTTPS, GET/POST 구분까지 클라이언트-서버 아키텍처의 전체 흐름을 다룹니다. 브라우저 DevTools의 Network 탭으로 실제 요청과 응답을 관찰하는 실습 과제도 포함되어 있습니다.
LLM 기반 '바이브 코딩'은 초기 생산성을 높이지만, 유지보수 3개월 차부터 인간이 작성한 코드에서는 드물게 보이는 구조적 기술 부채를 드러낸다고 저자는 지적합니다. 의존성 팽창, 아키텍처 경계 침범, 형식만 있는 테스트 등 구체적인 실패 패턴을 분석하고 '검증 기반' 워크플로로 전환할 것을 제안합니다.
AI 코딩 도구 Lovable로 해커톤에 참여해 첫날 90%를 완성했지만 둘째 날 버그에 파묻힌 엔지니어링 매니저의 경험담입니다. 저자는 비기술 리더에게 '소프트웨어는 왜 항상 더 복잡해지는가'를 설명하기 위해 집 리노베이션 비유를 제시하며, 코드 작성 자체보다 인프라와 유지보수가 본질적인 난제임을 강조합니다.
러시아의 새로운 법령(569-ФЗ)으로 .ru 도메인 등록에 러시아와의 연고가 요구되면서, 저자가 2014년부터 유지해온 농담 도메인 verygoodsoftwarenotvirus.ru를 갱신할 수 없게 됐습니다. 등록은 2026년 11월까지 유효하지만 12월 11일에는 해제되어 요건을 충족하는 누구나 가져갈 수 있으며, 저자는 이 도메인이 자신의 개발자 커리어와 정체성으로 자라난 과정을 회고합니다.
YAGNI와 KISS 같은 '단순함 우선' 원칙이 반복 적용되면, 어느 순간 단순했던 설계가 코드베이스의 표준 패턴으로 굳어지며 기술 부채가 된다는 글입니다. 저자는 이를 '깨진 유리창 이론(Broken Window Theory)'에 빗대어, 나쁜 패턴이 나쁜 패턴을 낳는 구조적 원인과 이를 막기 위한 실용적인 대응책을 제시합니다.
엔지니어링 생산성의 상당 부분이 거창한 이론이 아니라 작은 지식 조각에서 나온다는 에세이입니다. fzf·ripgrep·git pickaxe·EXPLAIN ANALYZE 같은 즉시 쓸 수 있는 팁을 소개하고, 회사에서도 이런 지식을 하루 하나씩 공유하는 방식을 제안합니다.
저자가 Mozilla 및 Lincoln Loop과 함께 Firefox.com을 전처리기 없이 순수 모던 CSS로 재구축한 경험을 다룹니다. Custom Properties·Grid·Flexbox의 등장으로 2008년 CSS Zen Garden이 보여준 이상이 마침내 실전에서 실현됐으며, 70개 이상의 컴포넌트와 19개 로케일을 지원하는 디자인 시스템이 완성됐습니다.