프로덕트 엔지니어: 무엇을 만들지까지 정하는 엔지니어 트랙

리니어와 리플릿은 엔지니어를 프로덕트 엔지니어라는 직함으로 뽑는다. 스펙을 받아 구현하는 대신 문제 정의부터 출시 후 지표까지 한 사람이 안는 트랙.

3 분 읽기

2026년 7월 27일 업데이트

한 줄 요약

프로덕트 엔지니어: 무엇을 만들지까지 정하는 엔지니어 트랙

이 분야가 중요한 이유

리니어의 엔지니어 공고는 직함이 Product Engineer 다. 시니어와 스태프 단계도, AI 팀 자리도 같은 이름을 쓴다. 그러면서 풀스택 엔지니어 공고를 따로 걸어 둔다. 이름만 바꾼 게 아니라 다른 자리로 취급한다는 뜻이다. 리플릿도 같은 직함으로 뽑는다.

차이는 범위에 있다. 프로덕트 엔지니어는 스펙 문서를 받아서 시작하지 않는다. 사용자에게 무엇이 불편한지 직접 확인하고, 그중 무엇을 만들지 고르고, 화면을 그리고, 배포하고, 2주 뒤 지표를 보고 자기 판단을 채점한다. PM과 디자이너가 없다는 뜻이 아니라, 그들과 같은 테이블에서 결정에 참여한다는 뜻이다.

이 자리가 지금 늘어나는 이유는 구현 시간이 짧아졌기 때문이다. 에이전트가 코드를 뱉는 속도가 올라가면 병목은 앞단으로 옮겨간다. OpenAI가 낸 연구는 AI 도입이 사람의 일을 좁히기보다 다루는 범위를 넓히는 방향으로 나타난다고 정리한다. 광고 지주사를 세운 데이비드 존스는 파이낸셜타임스에 자기 회사 업무의 95%를 기계에 넘겼다고 말했다. 반대편에는 조심스러운 관측도 있다. 스탠퍼드 SIEPR의 정책 브리프는 AI가 고용에 준 충격을 실측 데이터로 과장과 구분해 보자고 제안한다. 직함이 먼저 움직이고 통계가 뒤늦게 확인하는 구간이라고 보는 편이 정확하다.

필요한 역량

문제를 고르는 감각. 사용자 인터뷰를 남에게 맡기지 않는다. 더 중요한 건 무엇을 안 만들지 정하는 쪽이다. 요청 목록에서 세 개를 지우는 근거를 댈 수 있어야 한다.
디자인 마감. 디자이너 없이도 빈 화면, 로딩, 에러, 권한 없는 상태까지 그린다. 해피 패스만 만들어 놓고 나머지를 남에게 넘기면 이 트랙에서는 절반만 한 것이다.
계측. 이벤트 스키마를 먼저 설계하고 배포한다. 출시 후에 지표를 붙이면 늘 늦고, 늦으면 자기 판단이 맞았는지 영영 모른다.
풀스택과 배포. 프런트부터 데이터 모델, 마이그레이션, 롤아웃까지. 기능 하나를 혼자 끝낼 수 있어야 결정 권한이 따라온다.
에이전트 위임과 검증. 구현을 도구에 넘기고 남은 시간을 판단에 쓴다. 대신 출력물을 읽고 걸러 내는 눈이 없으면 속도만 빨라진 채로 틀린다.
짧은 글. 스펙 한 장, 릴리스 노트 다섯 줄. 결정 이유를 남기지 않으면 6개월 뒤에 같은 논쟁을 다시 한다.

커리어 경로

주니어 구간에서는 기능 하나를 요구 정의부터 릴리스까지 혼자 끌고 가 본다. 여기서 배우는 건 코드가 아니라 자기가 고른 문제가 틀렸을 때의 감각이다. 시니어가 되면 제품 영역 하나를 소유하고, PM이 있어도 우선순위를 함께 짠다. 스태프나 리드 구간은 어떤 문제를 팀이 아예 건드리지 않을지 정하고, 그 기준을 채용 기준으로 옮긴다.

국내에서는 이 직함이 제도화된 곳이 아직 적다. 대신 스타트업에서 개발자가 기획을 겸하는 형태로 존재한다. 반대로 대형 플랫폼은 PM, 디자이너, 개발의 분업이 뚜렷해서 이 트랙이 잘 보이지 않는다. 그래서 국내 지원자의 실질적인 문제는 직함이 아니라 증거다. 이력서에 “구현했다"만 적혀 있으면 어느 쪽에서도 프로덕트 엔지니어로 읽히지 않는다. 무엇을 안 만들기로 했고 그 결정이 숫자를 어떻게 바꿨는지 한 줄이라도 쓸 수 있으면 읽는 사람이 달라진다.

면접 준비로 딱 하나만 한다면, 자기가 만든 기능 중 사용자가 끝내 쓰지 않은 것을 하나 골라 왜 틀렸는지 5분 분량으로 정리해 두는 것을 권한다. 성공 사례는 다들 준비해 오고, 실패를 분해해 본 사람은 드물다.