안녕하세요. 요기요 모바일팀 이원종입니다.
IT 회사의 대표적인 조직 구조에는 기능조직과 목적조직이 있고, 이는 팀의 규모나 서비스의 성장 단계에 따라 유연하게 선택됩니다. 현재 요기요는 플랫폼과 기술 도메인별 전문성을 극대화할 수 있는 기능조직 구조로 일하고 있습니다. 기능조직은 기술적 깊이를 더하기엔 훌륭하지만, 아이디어가 제품으로 릴리즈되기까지 필연적으로 여러 직군 간의 커뮤니케이션과 핸드오프 비용이 발생하곤 합니다.
2026년 2분기에는 기능조직의 경계를 넘어 한 명의 엔지니어가 제품의 문제 정의부터 기획, 백엔드와 모바일 구현, 배포까지 온전히 책임지는 Product Engineer(PE) 파일럿을 진행했습니다.
Android 개발자였던 제가 전문성을 잠시 내려놓고 비즈니스 기회 분석부터 풀스택 구현까지 완주하며 겪은 시행착오와 파일럿 이후 발견한 병목들을 조직 차원에서 어떻게 풀어내고 있는지 그 여정을 공유해 드리고자 합니다.
작업 배경
Product Engineer 를 시작하며 평소처럼 안드로이드 스튜디오를 켜고 익숙한 패턴의 코드를 작성하며 과제를 진행한다면 기존의 기능조직 안에서 하던 방식과 본질적으로 다를 바가 없다고 생각했습니다. AI 가 개발 생태계의 판도를 바꾸고 있는 지금, 엔지니어가 나아가야 할 방향은 단순히 코드를 더 빠르게 타이핑하는 사람이 아니어야 했습니다. Product Engineer 는 비즈니스의 문제를 날카롭게 포착하고 이를 가장 기민하게 풀어내는 해결사여야 한다고 생각했기 때문에 다음과 같은 생각으로 파일럿 과제를 수행했습니다.
모든 기술 전문성을 내려놓고 백지상태로 문제를 바라봤습니다.
특정 플랫폼에 대한 숙련도를 앞세우는 순간, 비즈니스 문제를 넓게 보지 못하고 모바일 개발자의 시선으로만 문제를 해석하거나 기존의 굳어진 개발 프로세스를 당연하게 받아들일 위험이 있었기 때문입니다.
오히려 아무런 사전 지식이 없는 백지상태의 Product Engineer 입장에서 제품을 마주해야만, 오롯이 ‘이 비즈니스 문제를 어떻게 가장 빠르고 올바르게 해결할 것인가’에 모든 에너지를 쏟을 수 있다고 생각했습니다. 동시에 기존 프로세스 안에 당연하게 녹아 있던 번거로운 절차와 보이지 않던 비효율들을 편견 없이 포착할 수 있을 것이라 생각했습니다.
코드를 직접 쓰지 않고 문제 정의와 검증에 집중했습니다.
미래의 Product Engineer 는 단순한 코드 작성자를 넘어 제품을 설계하는 사람이어야 한다고 생각했기 때문입니다. 코드 생성과 리팩토링은 AI에게 온전히 맡기고 저는 문제정의와 AI 가 구현한 결과물이 제품의 의도와 품질에 정확히 부합하는가를 고민하고 검증하는 역할에 집중하고자 했습니다.
모르는 것은 먼저 AI에게 물었습니다.
시스템의 맥락이 공식 문서가 아니라 특정 개인의 머릿속에만 암묵지로 남아 있다면, 그 지식은 그 사람이 자리를 비우는 순간 함께 멈춥니다. 그래서 궁금한 것이 생기면 동료에게 묻기 전에 먼저 문서와 코드베이스를 근거로 AI에게 물었습니다.
잘 갖춰진 시스템이라면 문서와 코드베이스만으로도 AI 가 답을 찾을 수 있어야 합니다. 반대로 AI가 답을 내지 못하는 지점이 있다면, 그곳이 바로 우리 조직이 기록으로 남겨야 할 지점이라고 보았습니다.
한 일
제가 Product Engineer 파일럿을 진행하며 맡은 과제는 홈 화면에서 타겟팅 사용자에게 할인랭킹 바텀시트를 노출하는 기능이었는데요, 이를 어떤 과정으로 구현했는지 공유드리겠습니다.
https://medium.com/media/651e16a6ccea7f23426ef2b2d810658e/href데이터 분석
Product Engineer 의 주요 목표 중 하나는 GMV 상승이었는데요, BigQuery 를 통해 CTR(클릭률)과 구매 전환율이 검증된 할인랭킹 지면의 노출량이 이전분기와 비교해 크게 감소한 것을 발견했습니다. 과거 할인랭
Product Engineer 도전: 업무 영역의 확장
생성 일시
2026/10/29 08:02
최종 편집 일시
2026/10/29 08:02
태그
요기요
파일과 미디어