코드를 모르는 기획자의 Product Engineer 도전 : 준비와 소통으로 서버부터 앱까지

URL

https://techblog.yogiyo.co.kr/%EC%BD%94%EB%93%9C%EB%A5%BC-%EB%AA%A8%EB%A5%B4%EB%8A%94-%EA%B8%B0%ED%9A%8D%EC%9E%90%EC%9D%98-product-engineer-%EB%8F%84%EC%A0%84-%EC%A4%80%EB%B9%84%EC%99%80-%EC%86%8C%ED%86%B5%EC%9C%BC%EB%A1%9C-%EC%84%9C%EB%B2%84%EB%B6%80%ED%84%B0-%EC%95%B1%EA%B9%8C%EC%A7%80-f6c1db423de9?source=rss----c1b33ccbbc42---4

생성 일시

2026/10/15 05:06

최종 편집 일시

2026/10/15 05:06

태그

요기요

파일과 미디어

|| “레포지토리가 뭐야? 브랜치는 왜 만드는 거야?” 당시 저는 코드를 한 줄도 읽을 줄 몰랐습니다. 하지만 PE 활동을 하며 약 1개월 뒤 서버와 어드민, Android, iOS 앱까지 직접 개발한 기능을 실제 서비스에 출시했습니다. 저는 요기요에서 서비스 운영과 기획을 메인으로 해왔습니다. 앞선 글에서는 개발자가 PO의 역할까지 맡은 경험을 다뤘다면, 이번에는 반대 방향입니다. 기획자가 개발까지 맡으면 무엇이 가능하고, 무엇이 필요할까요? 결론부터 말하면, 이번 프로젝트에서 가장 많은 시간을 쓴 일은 코드 검토가 아니었습니다. 코드를 모르는 사람이 개발을 끝까지 해낼 수 있었던 건 개발에 들어가기 전의 준비와 동료들과의 소통 덕분이었습니다. 이 글에서는 그 과정을 이야기하고, 비개발자가 Product Engineer로 일하려면 어떤 조건이 필요한지 제 경험을 토대로 살펴보겠습니다. PE 활동을 하며 오픈한 서비스 주문 후 배달 상황을 보여주는 주문추적화면(OTP)의 지도에는 라이더 위치와 도착지를 표시하는 핀 마커가 있습니다. 이 마커를 광고 소재로 활용하는 기능입니다. 운영자가 어드민에서 광고를 등록하면 조리 중/배달 중 상태일 때 지도의 마커가 광고 이미지로 바뀝니다. 사용자가 마커를 누르면 하단에 배너가 올라오고, 배너를 누르면 광고 랜딩 페이지로 이동합니다. 이 기능은 사용자가 주문 후 가장 자주 확인하는 화면을 새로운 광고 지면으로 활용하기 위해 만들었습니다. 기획서로 보면 단순한 기능이지만 실제로는 데이터를 저장하는 서버, 앱에 데이터를 전달하는 API, 운영자가 쓰는 어드민, 그리고 Client까지 여러 영역을 함께 수정해야 했습니다. 2026.06.17에 출시했으며, 이후 첫 외부 광고에서 사전에 설정했던 목표 수치 대비 노출수, 클릭수와 같은 항목에서 200% 이상을 달성했습니다. 현재까지도 여러 광고를 진행하고 있고 안정적으로 운영되고 있습니다. 준비 : 개발 환경에 대한 학습보다 먼저 한 일가이드 문서로 개발 환경을 세팅하다 가장 먼저 부딪힌 벽은 코드가 아니라 내 컴퓨터에서 프로젝트를 실행하는 일이었습니다. 설치할 프로그램, 신청할 권한, 설정 파일 모두 처음 보는 것이었습니다. 이때 같이 PE 활동을 하는 백엔드 개발자께서 비개발자를 위해 정리해 주신 가이드 문서가 큰 도움이 되었습니다. 모든 단계가 ‘설치->확인->정상일 때의 결과’ 순서로 정리되어 있어, 터미널을 처음 여는 저도 설치를 마칠 수 있었습니다. 또 여러 저장소를 하나의 작업 폴더로 묶어 두어 AI가 기능 전체를 한눈에 보며 작업할 수 있었습니다. 덕분에 막힐 때도 “가이드 00단계에서 이런 오류가 납니다.”처럼 구체적으로 질문할 수 있었습니다. AI로 영향 범위를 먼저 파악하다 예전 같으면 “이 기능을 만들려면 어디를 수정해야 하나요?”를 여러 서비스의 담당 개발자에게 물어야 했습니다. 이번에는 Claude Code에게 기획 초안을 주고 영역별로 코드를 분석하게 했습니다. 어떤 영역을 수정해야 하는지, 새로 저장해야 할 데이터는 무엇인지, 앱에서는 지금 마커가 어떻게 동작하는지를 먼저 정리했습니다. 정리한 내용을 들고 개발자를 찾아가자 대화가 달라졌습니다. “어디를 고쳐야 하나요?”와 같은 문의가 아닌 “이렇게 파악했는데 맞을까요?”로 시작할 수 있었습니다. 개발자의 시간을 덜 쓰면서도 장황한 설명이 아닌 직접적인 피드백을 받을 수 있었습니다. 설계 계획서 하나에 모든 맥락을 모으다업무 진행 시 작성한 계획서 이번 프로젝트에서 가장 중요한 도구를 하나만 꼽으라면 마크다운으로 작성한 설계 계획서입니다. 영향 범위, 영역별 변경 내용, 확정된 정책, 바뀐 스펙을 모두 한 문서에 모았습니다. 이 문서는 AI가 읽는 용도로 작성했습니다. 기존 위키 문서는 사람이 보기 좋게 구성되어 있어 AI에게는 불필요한 형식의 정보가 많았기 때문에 컨텍스트를 효율적으로 쓰도록 내용을 정리했습니다. Claude는 새 작업을 시작할 때마다 이 문서를 먼저 읽으므로 프로젝트에서 여러 영역을 오가며 작업해도 전체 맥락을 유지할 수 있