프로덕트 엔지니어 뜻, 한 문장이면 됩니다
AI가 코드를 이렇게 잘 짜는데, 그럼 나는 앞으로 뭘 하는 사람이어야 할까요? 백엔드 10년차인 저는 이 질문 앞에서 지금 환경이 답답한 느낌, 개발이 지겨운 느낌, AI에 밀려날지 모른다는 불안을 한꺼번에 겪었고, 그때 '프로덕트 엔지니어'라는 단어를 처음 진지하게 찾아봤습니다. 답부터 드리면, 프로덕트 엔지니어란 기술 스택보다 '제품 문제'에서 출발해, 무엇을 만들지 정하는 일부터 출시와 반응 검증까지 끝까지 책임지는 개발자입니다.
그런데 검색해 보면 1페이지 글 대부분이 해외에서 나온 정의를 옮긴 글이에요. 읽고 나면 고개는 끄덕여지는데, "그래서 지금 내가 하는 일과 실제로 뭐가 다른데?"라는 질문은 그대로 남았습니다.
정의대로 일하는 회사가 어떤 모습인지, 프론트엔드·백엔드 개발자가 거기까지 어떻게 건너가는지가 잘 안 보였거든요. 그러다 PE(프로덕트 엔지니어) 포지션 채용 과정을 직접 밟게 됐고, 거기서 답의 일부를 볼 수 있었습니다.
이 글은 그 과정에서 확인한 것들을 정리한 기록입니다. 먼저 프론트엔드·백엔드·풀스택 개발자와 무엇이 다른지 3가지로 나눠 보고, 왜 하필 AI 시대에 이 직군이 떠오르는지 이야기할게요. 이어서 요즘 채용공고와 실제 PE 포지션에서 본 일하는 방식, 내가 PE형인지 세어보는 체크리스트, 지금 자리에서 PE로 넘어가는 3단계를 차례로 다룹니다.
프로덕트 엔지니어 vs 프론트엔드·백엔드·풀스택 개발자, 딱 3가지가 다릅니다
처음엔 저도 PE를 "프론트엔드도 하고 백엔드도 하는 사람", 그러니까 풀스택의 다른 이름쯤으로 생각했어요. 그런데 자료를 읽고 실제 PE 포지션 이야기를 들을수록, 선이 전혀 다른 곳에 그어져 있다는 걸 알게 됐습니다. 차이는 딱 3가지로 정리됩니다.
① 출발점이 다릅니다. 프론트엔드·백엔드 개발자는 보통 자기가 맡은 레이어에서 일을 시작합니다. 화면, API, DB 같은 것들이죠. 풀스택 개발자는 그 레이어를 프론트엔드와 백엔드 양쪽으로 넓힌 사람이고요.
프로덕트 엔지니어의 출발점은 고객과 제품의 문제입니다. 문제를 먼저 붙잡고, 그걸 푸는 수단으로 기술을 고르죠. 그래서 엔지니어링으로만 풀려고 하지 않고, 코드 말고 더 나은 방법이 있으면 그걸 먼저 씁니다. 갖가지 방법을 다 동원하는 셈이에요.
한 컨퍼런스에서 엔지니어 출신 제품 리더가 자기 한계로 꼽은 말이 오래 남았습니다. "제품의 문제를 개발이 아닌 더 좋은 방법으로 해결하려고 생각해야 한다." 개발자 출신일수록 모든 문제를 코드로 풀고 싶어지는데, PE는 그 습관을 한 번 의심해 보는 사람입니다.
② 책임 범위가 다릅니다. 한 레이어를 맡은 개발자의 책임은 대개 받은 티켓과 기능을 완료하는 데서 끝납니다. PE의 책임은 그 앞뒤로 길게 늘어나요.
앞으로는 '무엇을 만들지' 정하는 단계까지, 뒤로는 출시한 뒤 사용자가 어떻게 반응하는지 확인하는 단계까지 갑니다. 기획, 디자인, 개발, 런칭, 데이터 분석을 한 사람이 처음부터 끝까지 쥐고 가는 모습이에요.
③ 평가 기준이 다릅니다. 코드 품질이나 기능을 제때 끝냈는지도 물론 봅니다. 그래도 PE가 마지막에 평가받는 건 그 기능이 지표와 매출을 얼마나 움직였느냐, 즉 임팩트예요. 깔끔하게 잘 만든 기능이라도 아무도 쓰지 않으면, PE 입장에선 일이 덜 끝난 겁니다.
세 가지를 한 줄로 줄이면 이렇습니다. 풀스택은 기술의 폭이 넓은 개발자이고, PE는 책임의 폭이 넓은 개발자예요.
여기까지 읽으면 "그럼 PM(프로덕트 매니저)과는 뭐가 다른데?"라는 질문이 자연스럽게 나옵니다. 요즘 PE와 PM의 경계가 모호한 건 맞아요. 둘 다 예전보다 맡는 범위가 크게 늘어서, 어디까지가 PE 일이고 어디부터가 PM 일인지 선을 긋기가 어려워졌죠.
그래도 하나는 남습니다. PE는 여전히 엔지니어라는 점이에요. 앞의 그 제품 리더는 좋은 엔지니어를 '어떻게든 되게 만드는 사람'이라고 했고, 당장 되게 만드는 데서 멈추지 않고 지속 가능하도록 기술적인 기반까지 책임지는 사람이라고 덧붙였습니다. 범위가 아무리 넓어져도 PE의 바닥에는 이 몫이 깔려 있어요.
의견을 남겨주세요