프로덕트 엔지니어의 사고방식 - 태스크 수행자에서 문제 해결의 주체로

AI가 명확한 명세를 코드로 옮기는 일을 빠르게 수행하면서, 엔지니어의 차별점은 주어진 태스크를 잘 구현하는 능력보다 무엇을 해결해야 하는지 찾아내는 능력으로 이동하고 있음 Product Engineer는 특정 기술 스택보다 제품과 사업에 관심을 갖고, 돈을 새게 하거나 사용자를 불편하게 만드는 문제를 스스로 발견해 제안하거나 직접 해결하는 엔지니어에 가까움 이를 위해 의견을 근거와 함께 제시하고, 고객이 실제로 일하는 도메인을 배우며, 작은 사용자 집단에서 안전하게 실험하고 사업 목표와 데이터로 결과를 판단하는 습관이 필요함 좋은 아이디어를 혼자 떠올리는 사람이 될 필요는 없으며, 회사의 분기 목표를 확인하고 이를 해결하는 Hackathon을 열거나 아직 정의되지 않은 중요한 문제를 구조화하는 일도 높은 영향력을 만들 수 있음 코드 작성은 눈에 잘 보이는 병목이었을 뿐이며, 앞으로 더 희소해지는 역량은 지금 가장 중요한 일이 무엇인지 판단하고 사람·데이터·기술을 이용해 실제 결과까지 책임지는 자세라는 주장임 Product Engineer가 늘어나는 이유 Product Engineer는 Product Manager와 Engineer의 성격을 함께 가진 역할로, 최근 기업들이 관련 채용을 빠르게 늘리고 있음 기업이 사람을 구하기 어려워하는 이유는 코딩 실력이나 경력 부족보다 제품을 자신의 문제처럼 바라보고 판단하는 방식을 가진 엔지니어가 드물기 때문이라고 봄 따라서 이 역할을 준비하기 위해 기술 스택을 하나 더 배우는 것보다 사고방식을 바꾸는 것이 더 중요하다는 주장임 엔지니어는 오랫동안 ‘태스크 수행자’로 훈련됨 전통적인 개발 조직에서는 Project Manager가 이미 작은 단위로 나눈 작업과 명세를 전달하고, 엔지니어는 이를 코드로 구현하는 역할을 맡아왔음 언어와 기술 스택을 익힌 뒤 다른 사람이 정의한 문제를 정확히 실행하는 능력이 좋은 엔지니어의 중요한 기준이었음 하지만 Claude Code를 만든 Boris Cherny의 표현처럼 “coding is basically solved”에 가까워지면서, 이런 형태의 작업은 AI가 특히 잘하는 영역이 됨 엔지니어의 가치가 “태스크를 주면 구현한다”에만 있다면 AI와 직접 경쟁하게 되며, 좋은 아이디어와 문제 정의가 새로운 병목으로 부각됨 조직이 평평해지면서 엔지니어에게 판단까지 요구됨 많은 기업이 중간관리 계층을 줄이고 있어 적은 인원으로 더 많은 일을 처리...