Product Engineer: 전직 백엔드 개발자의 AI와 함께한 프론트엔드 도전기

마이리얼트립의 PEPE(Product Engineer Possibility Exchange) 세션에서, 백엔드에 익숙한 엔지니어가 Cursor와 함께 프론트엔드 관리자 페이지를 만든 경험을 공유했다. 핵심은 AI에게 단순히 코드를 맡기는 것이 아니라, AI가 맥락을 쌓을 수 있는 허브와 단계별 구조를 먼저 설계하는 일이었다.

작업은 Figma에서 시작됐다. 디자이너가 화면 구성뿐 아니라 정책과 상세 요구사항까지 정리해 두었고, 이를 바탕으로 커서가 프로젝트 배경, 사용자 흐름, 화면별 요구사항, 구조 설계가 담긴 정책서를 만들어 wiki에 등록했다.

이후 작업은 한 번에 맡기지 않고 단계적으로 쪼갰다.

• 기반 구조를 먼저 만들고
• 메인 페이지를 구성한 뒤
• 유형별 화면을 순차적으로 구현하는 방식으로 진행했다.

이 접근은 관리자 페이지가 다른 기능과 분리된 독립적 구조였고, 범위가 명확했으며, 기존 패턴이 잘 잡혀 있었기 때문에 가능했다. 코드를 깊게 몰라도 개발을 진행할 수 있었고, 중간에 끊기더라도 문서화된 단계부터 다시 이어갈 수 있었다.

겉보기에는 완성도가 높았지만, 실제로는 문제가 있었다. 관리자 페이지에서 여러 아이템을 수정해도 각 아이템마다 개별 API를 호출하는 구조였고, 아이템이 30개면 통신도 30번 발생했다. 화면은 정상처럼 보였지만 운영 관점에서는 비효율적인 설계였다.

이후에는 위키에 쌓아둔 설계 문서를 업데이트하고, 백엔드와 프론트의 변경 사항을 각각 반영하는 방식으로 수정했다. 동시에 프론트 에디터에서 로컬의 백엔드 레포를 직접 참조하도록 구조를 바꾸면서, 문서보다 코드 자체를 AI가 읽고 작업을 이어갈 수 있게 했다.

더 나아가 하나의 에디터에서 모든 작업을 처리하는 AI 전용 작업 허브도 만들었다. workspace 디렉토리 아래에 작업을 명시하고, 참조할 레포들을 연결해 두면 AI가 여러 레포를 오가며 프론트와 백엔드를 함께 다룰 수 있었다. 새 작업도 허브 하위 디렉토리에서 바로 시작할 수 있어, 매번 설명을 반복할 필요가 줄었다.

이 경험은 개인 업무 환경으로도 확장됐다. 온보딩 단계에서 업무 스타일, 기술 스택, 회사 정보, 성장 목표를 입력하면 AI가 맞춤 가이드를 주는 데브 워크스테이션 구상을 진행했고, MCP(Model Context Protocol) 로 위키와 프로젝트 레포를 연결하는 구조도 설계했다.

반대로 실패도 있었다. 병렬 작업을 위해 Git worktree 를 활용했지만, 여러 브랜치의 작업을 정리하고 병합하는 과정이 꼬이면서 오히려 맥락이 흩어졌다. 결론은 분명했다. AI 협업의 핵심은 좋은 프롬프트가 아니라, 컨텍스트를 집중해서 쌓을 수 있는 환경을 만드는 일이다.