||
5월 초, 코딩 에이전트에게 이렇게 물었습니다.
“DB 트랜잭션과 스프링 트랜잭션의 차이는 뭐야? 분산 락은 왜 필요한 거야?”
당시만 해도 저는 백엔드 개발 경험이 없었습니다. 하지만 두 달 뒤, 이 개념들을 적용해 신규 기능을 출시했습니다.
저는 지난 10년 동안 프론트엔드 개발만 해왔습니다. 그런 제가 Product Engineer 파일럿에 참여해 PO(프로덕트 오너), BE(백엔드), FE(프론트엔드)의 역할을 모두 맡았습니다. 제가 맡은 과제는 요기요 앱의 ‘친구 초대’ 기능 개발이었으며, 대규모 마케팅 예산이 투입되는 실제 서비스 프로젝트였습니다.
결론부터 말하면, Product Engineer는 가능합니다. 이 글에서는 먼저 어떤 기능을 만들었는지 소개하고, 이어서 PO·BE·FE 각 역할에서 어떻게 일했는지, 그리고 이 방식이 지속적으로 성과를 내려면 무엇이 필요한지 순서대로 살펴보겠습니다.
무엇을 만들었나
사용자가 요기요 앱의 이벤트 페이지를 친구에게 공유하고, 공유받은 친구가 해당 페이지에 접속하면 두 사람 모두 포인트를 받는 친구 초대 기능입니다.
이 기능은 이벤트 페이지 방문자를 늘리고, 한동안 앱을 이용하지 않은 사용자의 재방문을 유도하기 위해 만들었습니다. 2026년 7월 13일에 출시했으며, 이 글을 작성하는 9월 초 현재까지 안정적으로 운영되고 있습니다.
이제 이 기능을 출시하기까지 각 역할에서 어떻게 일했는지 살펴보겠습니다.
PO기대 효과와 개발 공수를 함께 고려해 제안하다
현업의 요청을 구체적인 요구사항으로 정리하는 일은 처음이었습니다. 하지만 개발 경험은 기획 업무에서 강점으로 작용했습니다. 각 요구사항의 기대 효과와 구현에 필요한 공수를 함께 고려해 제안할 수 있었기 때문입니다.
대표적인 사례가 ‘48시간 유효’ 조건입니다. 마케팅팀은 처음에 초대 링크를 공유한 뒤 48시간 안에 친구가 이벤트 페이지에 접속해야 보상을 지급하는 조건을 제안했습니다. 그러나 링크를 다시 생성할 때마다 유효 시간이 처음부터 계산되는 구조라면 48시간 제한을 우회할 수 있어, 기대한 효과를 얻기 어려웠습니다. 반면 이를 구현하고 유지하는 데에는 적지 않은 개발 공수가 필요했습니다. 기대 효과에 비해 개발 공수가 크다고 판단해, 해당 조건은 이번 단계에서 제외하자고 제안했습니다. 마케팅팀과의 논의를 거쳐 최종적으로 제안대로 진행하기로 했습니다.
기술적으로 구현할 수 있는지를 묻는 질문에도 그 자리에서 답할 수 있었습니다. 마케팅팀이 카카오 API 사용량에 따라 카카오톡 공유하기 버튼의 노출 여부를 제어할 수 있는지 물었을 때도, 구현 가능 여부와 필요한 개발 공수를 바로 판단해 답했습니다.
기획과 개발을 한 사람이 함께 맡으니 의사결정도 빨라졌습니다. 개발팀에 구현 가능 여부와 예상 공수를 문의하고 답변을 기다린 뒤 다시 협의할 필요 없이, 논의하는 자리에서 기대 효과와 개발 공수를 함께 검토하고 바로 결론을 내릴 수 있었습니다.
처음 맡는 업무는 AI를 활용해 파악하다
법무 검토와 사용자 행동 로그 설계는 새 기능을 출시하기 전에 반드시 거쳐야 하는 절차입니다. 그러나 각 절차를 진행하려면 무엇을 준비하고, 누구에게 어떤 방식으로 요청해야 하는지는 알지 못했습니다. 경험이 있는 PO에게는 익숙한 과정이겠지만, 업무를 처음 맡은 저에게는 모든 단계가 생소했습니다.
요청 절차와 담당자는 동료들에게 물어 파악했고, 이후의 세부 작업부터는 기존 자료를 적극적으로 활용했습니다. Confluence, Google Drive, Slack 등 흩어져 있던 사내 자료를 AI로 찾아 정리한 뒤, 이를 바탕으로 처음 작성하는 법무 검토 요청 메일과 사용자 행동 로그 설계 문서도 수월하게 완성할 수 있었습니다.
처음 맡는 업무에서는 필요한 정보와 작성 기준을 파악하는 일이 가장 어렵습니다. AI가 정리한 사내 사례와 참고 자료를 바탕으로 업무를 시작하니, 생소한 업무를 이해하고 초안을 작성하는 부담을 크게 줄일 수 있었습니다.
BE코드보다 문서를 먼저 작성하다
백엔드 개발 과정에서 가장 많은 시간을

