모두가 프로덕트 엔지니어가 된다면 무엇을 배워야 할까

Laurie Voss가 2026년 9월 14일에 쓴 We are all Product Engineers now는 앞으로 개발자의 일이 어떻게 달라질지 전망한다. 코드 작성과 운영이 자동화될수록 무엇을 만들고 어떤 결과를 좋은 것으로 볼지 결정하는 일이 중요해진다는 주장이다. 그는 그 역할을 프로덕트 엔지니어라고 부른다.

이 전망에는 두 가지 큰 가정이 있다. 에이전트가 개발 전 과정을 자동화할 수 있게 되고 소프트웨어 수요에도 사실상 한계가 없다는 것이다. 이런 가정으로 내다본 직업의 미래가 이미 정해졌다고 받아들이기는 어렵다.

그럼에도 제품을 판단할 줄 아는 개발자가 더 많이 필요해진다면, 그 능력은 어디에서 배우게 될까. 글을 읽고 이 질문을 오래 생각했다.

제품 판단에도 기술적 근거가 필요하다

프로덕트 엔지니어라는 말을 들으면 사용자를 만나 요구사항을 정리하고 곧바로 제품을 만드는 사람이 떠오를 수 있다. 그런데 무엇을 만들지 결정할 때도 시스템이 어떻게 동작하는지 알아야 한다. 사용자의 요청을 잘 이해하는 것만으로는 선택의 비용까지 알 수 없기 때문이다.

가령 문서 서비스에서 “저장이 끝나면 다음 화면으로 바로 이동하게 해달라”는 요청을 받았다고 하자. 이 예시는 가상이다.

다음 작업으로 빨리 넘어가고 싶다는 목적은 이해할 수 있다. 하지만 어떤 순간을 저장 완료로 볼 것인지는 더 살펴봐야 한다. 브라우저가 요청을 보낸 순간인지, 서버가 저장을 확인한 순간인지에 따라 사용자가 보는 결과가 달라진다. 응답이 늦거나 연결이 끊겼을 때 입력을 어디에 남겨둘지도 정해야 한다. 기다리는 화면을 없애는 선택이 저장 여부를 확인하기 어려운 흐름을 만들 수도 있다.

기술적 제약을 설명할 수 있어야 “빨리 넘어가게 하자”는 요청을 어떤 동작으로 구현할지 함께 결정할 수 있다. 이런 제품 판단에는 사용자의 작업 흐름과 함께 통신 실패, 상태 관리, 데이터 보존에 대한 이해가 들어간다.

그래서 나는 제품에 더 가까이 일할수록 기술을 배우는 목적도 구체적이어야 한다고 생각한다. 어떤 API를 호출할 수 있는지와 그 호출이 실패했을 때 사용자의 일이 어떻게 되는지를 함께 설명할 수 있어야 한다. 구현을 도구에 맡기더라도 선택의 결과를 이해하는 일은 개발자에게 필요하다.

판단을 연습할 기회

Voss는 주니어가 코드를 작성하고 시니어의 검토를 받으며 성장하던 경로가 약해질 수 있다고 걱정한다. 자동화의 영향을 고용 전망으로만 보면 놓치기 쉬운 부분이다. 일을 처리하는 방식이 바뀔 때 그 과정에서 배우던 경험은 어떻게 이어갈 것인가.

주니어에게 처음부터 좋은 제품 판단을 요구하기는 어렵다. 대신 작은 변경에서 판단하고 결과를 확인할 기회를 줄 수는 있다. 요청된 화면 이동을 구현하기 전에 문제를 자기 말로 설명해볼 시간이 필요하다. 앞의 저장 흐름을 개선하는 작업이라면, 먼저 실제로 사용자가 어디에서 기다리는지 확인하게 할 수 있다. 저장이 느린지, 완료된 뒤에도 화면이 그대로여서 기다리는지, 다음 행동을 찾기 어려운지 살펴보는 것이다.

그다음에는 바꿀 동작을 예상해본다. AI에게 대안을 요청할 수 있지만 자신이 어떤 이유로 하나를 선택했는지는 직접 설명해봐야 한다. 저장 중에도 다른 작업을 허용하면 어떤 상태가 생길까. 완료를 기다리면서 진행 상황을 보여주면 충분할까.

시니어의 검토는 그 설명에서 시작할 수도 있다. “이 코드가 잘못됐다”에서 그치면 수정 방법은 배우겠지만 왜 그 선택이 위험했는지는 놓칠 수 있다. 이번에는 사용자의 입력을 보존하는 것이 왜 중요한지, 다른 기능에서는 왜 같은 결정을 하지 않았는지 함께 이야기해야 다음 판단에 쓸 근거가 생긴다.

배포한 뒤에는 예상과 실제를 비교해야 한다. 기다리는 시간이 줄었는지, 저장 실패를 알아차릴 수 있는지, 사용자가 다음 작업을 끝낼 수 있는지 확인한다. 선택이 맞았는지를 볼 기회까지 있어야 “무엇을 만들지 판단해봤다”는 경험이 된다.

AI가 만든 결과물을 검토하는 일도 이런 연습에 쓸 수 있다.

다만 결과를 읽고 승인하는 역할만 계속 맡기면 스스로 선택하고 틀려볼 기회는 부족해진다. 작은 범위라도 문제를 설명하고 대안을 고르고 결과를 확인하는 과정을 직접 맡아볼 수 있어야 한다.

책임을 맡을 조건

이런 학습을 개인의 노력에만 맡기기는 어렵다.

실제 사용자 사례에 접근할 수 있어야 하고 선택의 이유를 이야기할 동료도 필요하다. 배포한 기능이 어떻게 쓰이는지 볼 수 없다면 구현은 계속해도 제품 판단에 대한 피드백은 받기 어렵다.

사용자 문제까지 책임지라고 하면서 정해진 요구사항에 질문할 권한이 없다면 판단을 맡겼다고 보기 어렵다. 오류를 살펴볼 시간 없이 다음 기능의 일정만 주어진다면 결과를 확인하는 책임도 수행하기 어렵다. 이미 일하고 있는 개발자에게도 같은 조건이 필요하다.

한 사람이 더 넓은 범위를 맡아 도움이 될 만한 작업도 있을 것이다. 다만 역할을 넓히는 결정에는 그 사람이 무엇을 결정할 수 있고 누구에게 도움을 받을 수 있는지도 포함되어야 한다. 사용자와 구현자 사이의 전달 과정이 짧아지면 잘못 이해한 내용을 빨리 발견할 수 있다.

나는 모두가 같은 직무를 수행해야 한다고 생각하지는 않는다. 복잡한 기반 시스템을 깊이 이해하는 사람도, 사용자와 함께 문제를 좁히는 사람도 필요할 수 있다. 팀에서 역할을 나눠 맡더라도 구현의 이유와 사용자의 결과를 서로 설명할 수 있다면 함께 제품을 판단할 수 있다.

코드를 쓰고 읽으며 배우는 시간도 그 안에 남겨두고 싶다. 실패의 원인을 직접 따라가거나 여러 구현을 비교해보는 경험은 선택의 비용을 이해하는 데 도움이 된다. 어떤 연습을 AI에 맡길지는 작업을 끝내는 속도와 그 사람이 이번에 배워야 할 것을 함께 보고 결정할 수 있다.

Voss의 전망을 읽고 학습에 관한 질문을 가져가고 싶다. 어떤 직함을 쓰게 되든 사용자의 상황을 이해하고 선택의 결과를 설명할 수 있는 개발자가 되고 싶다.

그리고 그런 개발자를 필요로 하는 팀이라면 작은 판단을 맡기고 이유를 함께 검토하고 결과까지 확인할 시간을 마련해야 한다. 판단을 요구하는 만큼 판단을 배울 기회도 주었으면 한다.