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

마이리얼트립의 다섯 번째 PEPE(Product Engineer Possibility Exchange) 세션에서는 조금 다른 도전기가 등장했습니다.

마이리얼트립에는 ‘백엔드 개발자’, ‘프론트엔드 개발자’라는 구분이 없습니다. 모두가 Product Engineer(PE)입니다. 하지만 사람마다 익숙한 기술 영역은 다릅니다. 백엔드에 익숙한 엔지니어가 프론트엔드 코드를 모르는 상태에서 관리자 페이지 화면을 직접 만든 이야기입니다.

그로스엔지니어링팀 황재선님은 버티컬 홈 개편 프로젝트에서 하단 커스텀 영역의 백엔드와 관리자 페이지 프론트엔드 개발을 함께 맡았습니다. 쿠폰 섹션, 쇼컷 스타일, 라이브 상품 카드 같은 유형의 데이터를 노출하는 백엔드 작업과, 이 데이터를 운영팀이 직접 등록하고 세팅할 수 있는 관리자 페이지를 함께 만들어야 했습니다. 백엔드 쪽은 익숙한 영역이니 문제가 없었지만, 관리자 페이지 프론트엔드는 사정이 달랐습니다. 프론트엔드 코드를 직접 다뤄본 적이 거의 없었기 때문입니다. 재선님은 이 작업을 AI 코딩 도구인 커서(Cursor)와 함께 진행하기로 했습니다.

결과부터 이야기하면, 관리자 페이지 개발은 가능했습니다. 그리고 그 과정에서 “AI에게 코드를 짜달라고 하는 것”보다 훨씬 중요한 것을 발견했습니다. AI가 잘 일하려면 컨텍스트를 쌓을 수 있는 구조, 즉 허브가 필요하다는 점입니다.

피그마에서 정책서로, 정책서에서 코드로

프로젝트의 시작은 피그마였습니다. 디자이너가 피그마에 화면 구성뿐 아니라 정책과 상세 요구사항을 꼼꼼하게 정리해 두었습니다. 각 버티컬 홈의 목록 페이지에 대한 정책, 유형별 등록 화면 구성, 어떤 데이터를 입력하면 화면이 어떻게 나오는지까지 세세하게 잡혀 있었습니다.

재선님은 이 피그마 내용을 빈 페이지에 복사한 뒤 커서에게 넘겼습니다. “이 링크를 기준으로 정책서를 뽑아 달라”고 요청했고, 커서는 프로젝트 배경, 사용자 흐름, 화면별 요구사항, 프로젝트 구조 설계까지 정리된 정책서를 만들어냈습니다. 이 문서는 그대로 위키에 등록됐습니다.

여기서 핵심은 단계별 계획이었습니다. 재선님은 전체 작업을 한 번에 맡기지 않았습니다. 기반 구조를 먼저 잡고, 메인 페이지를 만들고, 이후 유형별로 나눠서 AI가 점진적으로 작업하도록 설계했습니다. 각 페이지별로도 상세 계획을 나눠서, 작업이 중간에 끊기더라도 끊긴 부분부터 다시 진행할 수 있도록 위키 문서를 구성했습니다.

“AI가 조금씩 작업을 단계별로 진행할 수 있게끔 계획을 세웠습니다. 끊겨도 이어서 진행할 수 있도록 각 단계를 문서화해 두는 게 중요했어요.”

이 접근이 통한 데는 조건도 있었습니다. 관리자 페이지 프론트엔드가 다른 기능에 영향을 주지 않는 독립적 구조였고, 개발 범위가 명확했으며, 기존에 패턴이 잘 잡혀 있었다는 점입니다. 어떤 레포를 건드려야 하는지도 프로젝트 초반 설계 단계에서 이미 결정된 상태였습니다.

“코드를 몰라도 개발을 할 수가 있었고요. 독립적 구조에 범위가 명확하고 기존 패턴이 잘 잡혀 있었기 때문입니다.”

겉보기에는 완벽했지만

단계별 작업을 거쳐 관리자 페이지가 만들어졌습니다. 디자인 스타일까지 반영된 결과물이었습니다.

“겉보기에는 문제 없을 정도로 거의 디자인 스타일까지 완벽하게 반영이 된 관리자 페이지가 만들어졌는데…”

하지만 문제는 안쪽에 있었습니다. 실제로 백엔드 서버와 통신하는 방식을 살펴보니, 관리자 페이지에서 수정한 아이템들을 한 번에 저장해야 하는데 각각의 아이템마다 개별적으로 API를 호출하고 있었습니다. 아이템이 30개면 API 통신이 30번 발생하는 구조였습니다. 겉으로는 잘 동작했지만, 실제 운영 환경에서는 성능 문제가 될 수 있는 비효율이었습니다.

재선님은 위키에 등록해 둔 설계 문서를 업데이트하고, 백엔드 서버와 프론트 서버 각각의 변경 사항을 위키로 전달해서 반영하는 방식으로 수정 작업을 진행했습니다. 여기서 또 다른 불편이 드러났습니다. 에디터를 두 개 띄워 놓고, 프론트 작업은 프론트 프로젝트를 띄운 에디터에서, 백엔드 작업은 백엔드 에디터에서 각각 요청하며 왔다 갔다 해야 했습니다. 프론트에서 API를 호출하는 코드를 수정하려면 백엔드 레포의 API 스펙을 확인해야 하고, 백엔드를 고치면 다시 프론트로 돌아가야 했습니다.

이 비효율을 해결하기 위해 재선님은 프론트엔드 에디터에서 로컬에 있는 백엔드 레포를 직접 참조할 수 있도록 구조를 바꿨습니다. 위키 문서를 매번 업데이트해서 AI에게 전달하는 대신, 로컬에 작업된 코드 자체를 AI가 파악하게 한 것입니다. 이렇게 하니 위키가 업데이트되지 않아도 바로 코드 기반으로 작업을 이어갈 수 있었습니다.

에디터 하나로 모든 작업을: AI 전용 작업 허브

하지만 여전히 에디터를 왔다 갔다 하는 불편은 남아 있었습니다. 여기서 한 걸음 더 나아간 것이 AI 전용 작업 허브입니다. “아예 하나의 에디터에서 모든 작업을 할 수 없을까”라는 생각에서 출발했습니다.

workspace라는 디렉토리를 만들고, 그 하위에 해야 되는 작업을 명시해 놓고, 어떤 레포들을 참조해야 하는지 가이드를 줍니다. AI는 작업 시점에 해당 레포들을 파악하고, 프론트 작업과 백엔드 작업을 동시에 수행합니다.

“하나의 레포, 허브에서 멀티 프로젝트를 제어할 수 있게 됐고요. AI는 여러 레포를 컨트롤할 수 있으므로 허브 레포가 효과적입니다.”

실제로 이 허브를 활용하면 새로운 작업도 유연하게 시작할 수 있었습니다. 특정 레포 이름을 알려주고 클론 받아서 작업을 수행하라고 하면, 새로운 workspace 하위 디렉토리를 만들어서 처리하는 것까지 가능했습니다. 기존에는 매번 위키를 만들거나 채팅으로 일일이 설명해야 했던 일이, 허브 하나로 정리됐습니다.

프로젝트를 넘어서: 나만의 개발 환경을 설계하다

재선님은 이 경험을 바탕으로 ‘데브 워크스테이션’이라는 개인 업무 허브 개념까지 확장하고 있습니다. 프로젝트 단위의 작업 허브를 넘어서, 개발자 개인의 업무 전체를 아우르는 환경을 만들겠다는 시도입니다.

온보딩 단계에서 자신의 업무 스타일, 기술 스택, 회사 정보, 성장 목표 등을 입력하면 AI가 업무 수행 시 맞춤 가이드를 제공하는 구조입니다. 예를 들어 프로젝트를 진행할 때 성장 관점에서 어떤 부분을 중점적으로 작업하면 좋을지 가이드를 요청할 수도 있습니다. MCP(Model Context Protocol)를 통해 컨플루언스 같은 위키를 연결하고, 회사 프로젝트 레포들도 연결해서 하나의 환경에서 쓸 수 있게 설계했습니다. 현재는 클로드 기반으로 재구축을 진행하고 있다고 합니다.

회사 차원에서는 여러 가지 AI 도입을 진행하게 되지만, 개인 차원에서도 자신만의 업무 허브를 만들어 두면 업무를 진행하면서 파악한 내용들이 계속 쌓이게 됩니다. AI 시대에 개발자가 갖춰야 할 것은 특정 도구의 사용법이 아니라, 자신만의 작업 환경과 스타일을 설계하는 역량이라는 것입니다.

“컨텍스트를 쌓을 곳을 만드는 게 중요합니다. 개인 차원에서 나만의 업무 허브를 만들어 가면, AI 시대에도 나만의 업무 스타일을 강점으로 내세울 수 있다고 생각합니다.”

동시에 여러 일을 시켰더니: 실패에서 배운 것

물론 모든 시도가 성공한 것은 아닙니다. 재선님은 병렬 작업을 위해 Git 워크트리(worktree)를 활용해 봤습니다. 여러 브랜치를 동시에 열어두고 전혀 다른 개별 업무를 동시에 수행하면 효율이 올라갈 것이라는 기대였습니다.

AI 관점에서는 워크트리를 펼쳐서 병렬로 작업을 진행하는 것 자체는 가능했습니다. 하지만 문제는 사람 쪽에서 생겼습니다. 여러 브랜치에서 동시에 진행된 작업들을 어떻게 정리해서 레포에 합치고, 배포까지 관리할 것인지가 꼬이기 시작했습니다. 어떤 브랜치에서 어떤 작업을 했는지 추적이 어려워졌고, AI에게 전달하는 맥락도 흩어졌습니다.

“워크트리로 병렬 작업을 시도했는데, 여러 브랜치를 관리하다 꼬여서 실패했습니다. 한 번에 하나의 작업에 집중하는 것이 낫다는 결론을 내렸습니다.”

이 실패가 오히려 “허브에 컨텍스트를 집중해야 한다”는 결론을 더 단단하게 만들어줬습니다.

AI가 잘 일하는 환경을 설계하는 것

재선님의 발표를 관통하는 메시지는 하나입니다. AI를 잘 쓰는 것은 좋은 프롬프트를 쓰는 것이 아니라, AI가 잘 일할 수 있는 환경을 만드는 것이라는 점입니다.

독립적 구조와 명확한 범위가 있으면 코드를 몰라도 개발이 가능했고, 정책서와 단계별 계획이 있으면 작업이 끊겨도 이어갈 수 있었습니다. 여러 레포를 하나의 허브에서 관리하니 맥락이 흩어지지 않았고, 반대로 워크트리로 맥락을 분산시키면 오히려 효율이 떨어졌습니다.

결국 AI 협업의 핵심은 컨텍스트를 쌓을 곳을 만드는 것. 재선님은 그 답을 프로젝트 안에서 찾았고, 이제 자신만의 업무 허브로 확장해 가고 있습니다.

*마이리얼트립의 PEPE(Product Engineer Possibility Exchange)는 PE(Product Engineer)들이 “어디까지 시도했는지, 어디서 막혔는지”를 결과보다 과정으로 나누는 사내 세션입니다.