Product Engineer의 가능성과 조건: 대규모 예산이 투입되는 프로젝트에서 확인하다

5월 초, 코딩 에이전트에게 이렇게 물었습니다.

"DB 트랜잭션과 스프링 트랜잭션의 차이는 뭐야? 분산 락은 왜 필요한 거야?"

당시만 해도 저는 백엔드 개발 경험이 없었습니다. 하지만 두 달 뒤, 이 개념들을 적용해 신규 기능을 출시했습니다.

저는 지난 10년 동안 프론트엔드 개발만 해왔습니다. 그런 제가 Product Engineer 파일럿에 참여해 PO(프로덕트 오너), BE(백엔드), FE(프론트엔드)의 역할을 모두 맡았습니다. 개발한 기능은 요기요 앱의 '친구 초대'였으며, 대규모 마케팅 예산이 투입되는 프로젝트였습니다.

이번 경험을 통해 Product Engineer의 가능성을 확인했습니다. AI의 도움을 받아 처음 맡는 업무도 해낼 수 있었고, 기획과 개발을 함께 맡으면서 의사결정도 빨라졌습니다. 동시에 여러 팀과의 협업이 한 사람에게 집중되면서 생기는 부담도 실감했습니다.

이 글에서는 각 역할에서 어떻게 일했는지 이야기하고, Product Engineer가 지속적으로 성과를 내려면 무엇이 필요한지 살펴보겠습니다.

무엇을 만들었나

사용자가 요기요 앱의 이벤트 페이지를 친구에게 공유하고, 공유받은 친구가 해당 페이지에 접속하면 두 사람 모두 포인트를 받는 친구 초대 기능입니다.

이 기능은 이벤트 페이지 방문자를 늘리고, 한동안 앱을 이용하지 않은 사용자의 재방문을 유도하기 위해 만들었습니다. 2026년 7월 13일에 출시했으며, 이 글을 작성하는 9월 초 현재까지 안정적으로 운영되고 있습니다.

이제 이 기능을 출시하기까지 각 역할에서 어떻게 일했는지 살펴보겠습니다.

PO

기대 효과와 개발 공수를 함께 고려해 제안하다

현업의 요청을 구체적인 요구사항으로 정리하는 일은 처음이었습니다. 하지만 개발 경험은 기획 업무에서 강점이 됐습니다. 요구사항의 기대 효과와 구현에 필요한 공수를 함께 검토할 수 있었기 때문입니다. 대표적인 사례가 마케팅팀이 제안한 '48시간 유효' 조건입니다.

마케팅팀은 공유 직후 방문을 유도하기 위해 '48시간 유효' 조건을 제안했습니다. 하지만 링크를 다시 만들 때마다 유효 시간이 초기화되는 구조라면 제한의 실효성이 낮다고 판단했습니다. 구현과 운영에 드는 비용까지 고려해 이번 단계에서는 제외하자고 제안했고, 마케팅팀과 논의해 최종적으로 합의했습니다.

기술적으로 구현할 수 있는지를 묻는 질문에도 그 자리에서 답할 수 있었습니다. 마케팅팀이 카카오 API 사용량에 따라 카카오톡 공유하기 버튼의 노출 여부를 제어할 수 있는지 물었을 때도, 구현 가능 여부와 필요한 개발 공수를 바로 판단해 답했습니다.

기획과 개발을 한 사람이 함께 맡으니 의사결정도 빨라졌습니다. 개발팀에 구현 가능 여부와 예상 공수를 문의하고 답변을 기다린 뒤 다시 협의할 필요 없이, 논의하는 자리에서 기대 효과와 개발 공수를 함께 검토하고 바로 결론을 내릴 수 있었습니다.

처음 맡는 업무는 AI를 활용해 파악하다

법무 검토와 사용자 행동 로그 설계는 새 기능을 출시하기 전에 반드시 거쳐야 하는 절차입니다. 그러나 각 절차를 진행하려면 무엇을 준비하고, 누구에게 어떤 방식으로 요청해야 하는지는 알지 못했습니다. 경험이 있는 PO에게는 익숙한 과정이겠지만, 업무를 처음 맡은 저에게는 모든 단계가 생소했습니다.

요청 절차와 담당자는 동료들에게 물어 파악했고, 이후의 세부 작업부터는 기존 자료를 적극적으로 활용했습니다. Confluence, Google Drive, Slack 등 흩어져 있던 사내 자료를 AI로 찾아 정리한 뒤, 이를 바탕으로 처음 작성하는 법무 검토 요청 메일과 사용자 행동 로그 설계 문서도 수월하게 완성할 수 있었습니다.

처음 맡는 업무에서는 필요한 정보와 작성 기준을 파악하는 일이 가장 어렵습니다. AI가 정리한 사내 사례와 참고 자료를 바탕으로 업무를 시작하니, 생소한 업무를 이해하고 초안을 작성하는 부담을 크게 줄일 수 있었습니다.

BE

코드보다 문서를 먼저 작성하다

백엔드 개발 과정에서 가장 많은 시간을 들인 일은 코드 작성이 아니라 문서 작성이었습니다. PRD, 개발 설계 문서, API 명세를 차례로 작성하며 서비스의 전체 구조부터 세부 정책까지 구체적으로 정의했습니다. 문서를 통해 구조와 정책을 미리 확정해 둔 덕분에 주요 비즈니스 로직을 단 사흘 만에 구현할 수 있었습니다. 이후 구현 단계에서 추가된 내용은 일부 세부 정책과 입력값 검증 로직 정도였으며, 코드의 전체 구조와 처리 흐름은 처음 설계한 내용에서 크게 달라지지 않았습니다.

검증된 컨벤션을 따르다

기술 스택과 개발 방식을 처음부터 새로 정하지는 않았습니다. 친구 초대 기능과 도메인이 유사하고 향후 유지보수를 담당할 팀이 운영하는 서비스에서 기술 스택, 모듈 구조, 테스트 코드 작성 방식, 오류 처리 방식 등 이미 검증된 개발 컨벤션을 그대로 적용했습니다. 프로젝트가 끝난 뒤 해당 팀이 코드를 빠르게 이해하고 쉽게 유지보수할 수 있도록 하기 위해서였습니다.

이에 백엔드 개발의 첫 커밋은 개발 컨벤션이었습니다. 이 컨벤션을 코딩 에이전트의 지침에 포함하고, 구현 과정에서 판단이 필요할 때마다 먼저 확인하도록 했습니다. 그 결과 에이전트가 작성한 코드의 일관성을 유지할 수 있었고, 기술과 구현 방식을 매번 새로 결정하는 데 드는 시간과 고민도 줄일 수 있었습니다.

백엔드 개발자에게 설계 피드백을 받다

설계 과정에서 중요한 결정을 내릴 때마다 동료 백엔드 개발자에게 피드백을 요청했습니다. 예를 들어 처음에는 포인트를 지급하기 전에 메시지 큐를 거치도록 설계하려 했습니다. 하지만 프로젝트의 규모와 요구사항을 고려하면 메시지 큐가 필요하지 않다는 의견을 받아 사용하지 않기로 결정했습니다. 경험이 풍부한 동료의 피드백 덕분에 불필요하게 복잡한 구조를 피하고, 프로젝트에 적합한 수준으로 설계할 수 있었습니다.

FE

UI 검증을 한 화면에서 끝내다

직접 열어 비교하던 Figma 원본과 구현 화면을, 이제는 에이전트가 캡처해 한 화면에 나란히 배치합니다.

프론트엔드 개발은 제 본업이기 때문에 기존 업무를 AI로 더 효율적으로 수행하는 데 집중했습니다.

대표적인 사례가 UI 검증 효율화입니다. 기존에는 코딩 에이전트에 Figma 링크를 제공해 UI 구현을 요청해도, 구현을 완료했다는 보고와 달리 실제 화면이 원본과 다른 경우가 종종 있었습니다. 그때마다 개발 환경에서 구현 화면을 실행한 뒤 Figma 원본과 직접 비교해야 했습니다.

그래서 구현 결과를 Figma 원본과 한 화면에서 바로 비교할 수 있도록 UI 검증 방식을 바꿨습니다. 에이전트가 구현을 마치면 Figma 원본과 구현 화면을 각각 캡처하고, 두 이미지를 한 화면에 나란히 배치하도록 지침을 작성했습니다. 덕분에 각 화면을 따로 열어 보지 않고도 차이를 바로 확인할 수 있었고, 실제로 원본과 다르게 적용된 스타일도 빠르게 발견할 수 있었습니다.

Product Engineer는 가능하다. 단, 조건이 있다

대규모 예산이 집행되는 실무 프로젝트에서 한 사람이 PO, BE, FE를 모두 책임지고 서비스를 출시하면서 Product Engineer의 가능성을 확인했습니다. 그 이유는 AI의 도움으로 처음하는 업무에 대한 진입장벽이 낮아졌고, 직군 간 커뮤니케이션 비용이 줄어들어 의사결정이 빨라지기 때문입니다.

다만 Product Engineer로서 일을 제대로 하기 위해서는 세 가지 조건이 필요합니다.

업무 절차 정리와 업무의 템플릿화가 필요하다

일정을 산정할 때 일부 업무를 누락한 이유는 해당 업무가 필요하다는 사실 자체를 몰랐기 때문입니다. 예를 들어, PO 업무에 법무 검토가 포함된다는 것을 몰랐습니다.

Product Engineer가 수행해야 하는 전체 업무를 파악하려면, 서비스 기획부터 배포까지의 절차를 정리한 문서가 필요합니다. 각 단계에서 해야 할 일과 담당자, 요청 채널, 예상 소요 시간을 하나의 문서에서 확인할 수 있어야 합니다. 이러한 문서가 있었다면 일정 산정 과정에서 필요한 업무를 미리 확인하고 누락을 방지할 수 있었습니다.

또한 법무·보안 검토나 로그 설계 요청처럼 반복적으로 수행하는 업무는 템플릿을 마련하여 자동화해야 합니다. 이렇게 하면 요청할 때마다 담당 부서와 요청 방법, 작성 형식을 다시 확인하지 않고도 업무를 빠르고 일관되게 처리할 수 있습니다.

전문가의 도움을 적극적으로 받아야 한다

AI는 큰 도움이 되었지만, AI만으로 해결하기 어려운 일도 많았습니다. 특히 요구사항에 맞는 기술적 판단을 내리는 데에는 동료의 도움이 필요했습니다. 예를 들어, 백엔드 설계에서 불필요하게 복잡한 부분을 단순화할 수 있었던 것도 AI가 아니라 동료 백엔드 개발자의 피드백 덕분이었습니다.

AI만으로 판단하기 어려운 부분은 혼자 오래 고민하기보다 전문가에게 바로 도움을 구하는 편이 낫습니다. 필요한 순간에 신속하게 도움을 요청하는 것이 업무를 원활하게 진행하는 데 큰 도움이 됩니다.

커뮤니케이션을 동시에 관리할 수 있어야 한다

세 직군을 겸하다 보니 협업해야 할 팀도 많았습니다. PO 역할에서는 마케팅팀, 법무팀, CXI, 데이터 거버넌스팀과 협업했고, BE로서는 보안팀과 성능 테스트를 담당하는 QE팀과 협업했습니다. 협업하는 팀이 많을수록 각 논의의 배경과 진행 상황을 다시 떠올려야 했고, 이러한 맥락 전환에는 적지 않은 시간과 집중력이 들었습니다.

문제는 다수의 팀과의 커뮤니케이션이 순차적으로 진행되지 않는다는 점입니다. 다른 팀의 일정은 제가 통제할 수 없기 때문에 특정 시기에는 여러 팀과의 논의가 동시에 진행되기도 했습니다. 일정이 겹칠수록 각 논의의 맥락을 다시 파악하는 데 드는 시간과 집중력도 늘어났고, 그 시기에 업무 부담이 가장 컸습니다.

세 직군을 겸하는 한 이러한 부담을 완전히 없애기는 어렵습니다. 따라서 Product Engineer에게는 동시에 진행되는 여러 논의의 우선순위를 정하고, 논의가 바뀔 때마다 필요한 내용을 빠르게 다시 파악해 업무를 이어가는 능력이 필요합니다.

마치며

한 사람이 PO, BE, FE 역할을 함께 맡으면 직군 간 협의 과정이 줄어 의사결정이 빨라집니다. 그러나 다른 팀의 검토와 협조를 기다리는 시간까지 줄어드는 것은 아닙니다. 오히려 한 사람이 다수의 팀과 동시에 소통해야 하므로 업무 부담이 커질 수 있습니다.

이 방식이 지속 가능하려면 조직과 개인 모두 준비가 필요합니다. 조직은 전체 업무 절차와 담당자를 확인할 수 있는 프로세스 지도를 마련하고, 반복적으로 처리하는 업무는 템플릿과 자동화 시스템으로 지원해야 합니다. 개인은 잘 모르는 영역을 혼자 오래 고민하지 않고 전문가에게 신속히 도움을 구해야 하며, 여러 팀과의 논의가 동시에 진행될 때는 우선순위를 정하고 논의가 바뀔 때마다 발생하는 시간과 집중력의 소모를 줄일 수 있어야 합니다.

한 사람이 Product Engineer로서 여러 직군의 역할을 함께 수행하는 것은 가능합니다. 이 글이 앞으로 Product Engineer의 시행착오를 줄이는 데 도움이 되기를 바랍니다.