코드는 빨리 쌓이는데, 설계 이유를 아는 사람이 없다
AI 코딩의 성과를 출시 건수로만 평가하면 다음 수정에 필요한 설계 이해를 놓칠 수 있습니다. Claude Code를 쓰는 팀이 담당자와 검토 시간을 남겨야 하는 이유를 살펴봅니다.
주제
엔지니어링 리더십
엔지니어링 리더십 관련 글을 모았습니다. 유토모 테크로그에서 새 기술과 제품이 일과 제품에 만드는 변화를 살펴봅니다.
성과가 안 보일수록 더 큰 일을 떠맡는 악순환을 끊는 법
성과가 보이지 않을수록 더 큰 일을 혼자 떠안는 악순환을 짚고, 작은 완료와 짧은 공유로 협업의 신뢰를 회복하는 방법을 설명합니다.
AI로 사내 도구를 더 쉽게 만들 때, 3년 뒤 유지보수 비용을 먼저 묻는 이유
AI는 사내 도구의 초기 개발비를 낮췄지만, 패치·보안·업무 변경을 맡을 사람까지 없애지는 못했습니다. 직접 구축 여부를 3년 차 유지보수 책임으로 판단하는 방법을 설명합니다.
AI가 장애를 대신 처리할수록 더 중요해지는 훈련: 온콜 팀이 준비할 일
AI가 일상 장애를 처리할수록 온콜 팀은 더 어려운 사건을 적은 실습으로 맡게 됩니다. 시뮬레이션 중심의 준비도 훈련을 정리했습니다.
AI 도구 예산보다 먼저 고쳐야 할 조직의 병목
AI 도구의 작업 속도만 보면 전체 생산성을 오해할 수 있습니다. 예산을 늘리기 전에 작성, 결정, 검토, 전달 중 어디에서 일이 기다리는지 기록하는 방법을 정리했습니다.
AI 시대의 전문직, 일을 시스템으로 바꿔야 하는 이유
AI가 구현 부담을 낮추면서 전문직의 역할은 결과물 생산에서 업무 시스템의 규칙과 검토를 설계하는 일로 넓어지고 있습니다.
코드 생성이 빨라진 뒤, 개발팀이 문제 정의를 다시 맡아야 하는 이유
AI가 구현 시간을 줄인 뒤 개발팀은 문제 정의와 실험 조건을 더 직접 맡게 됐습니다. 태스크 수행과 프로덕트 엔지니어의 차이, 5% 실험과 지표 설정의 순서를 정리합니다.
아무나 AI로 제품을 만드는 시대에도 프로덕트 매니저가 여전히 필요한 이유
마티 케이건이 벤 에반스의 글을 인용해 AI 시대에도 프로덕트 매니저가 필요한 이유를 정리했습니다. 핵심은 도구를 쓰는 능력과 만드는 능력이 서로 다른 스킬이라는 점입니다.
코드가 공짜에 가까워져도 사내 플랫폼 투자를 줄이면 안 되는 이유
에이전트가 코드를 짜는 비용이 낮아져도, 사내 플랫폼을 재사용하면 에이전트가 읽고 다시 짤 코드 범위가 줄어 실제 토큰 비용도 줄어든다는 두 개발자의 글을 정리했습니다.
AI가 개발자 조직의 허리를 없애고 있다는 경고
소프트웨어 엔지니어 플로리안 헤렌트는 AI가 구현 속도의 상한선을 없애면서 판단력 있는 엔지니어와 없는 엔지니어의 몸값 격차를 더 벌린다고 주장했습니다. 되돌리기 어려운 결정이 하루 만에 쌓이는 구조를 짚었습니다.
1년 넘게 AI로 코딩하던 개발자가 도구를 내려놓은 이유
20년 경력 개발자 브렛은 18개월간 쓰던 AI 코딩 도구를 정신 건강과 소프트웨어 품질, 환경·사회적 비용을 이유로 전부 그만두기로 했습니다.
기술 부채가 아니라 그저 엉망인 상태다, 프레이밍이 놓치는 것
냇 베넷은 개발팀이 기술 부채라 부르는 문제 대부분이 사실은 비용을 미리 몰랐던 미숙한 작업이나 취향 차이일 뿐이라고 설명합니다.
