Product Engineer: 안드로이드 개발자가 AI로 프론트엔드까지 넘겨본 이유

PEPE 세션 1 — Growth실 E&R팀 김경훈 님

2025년 9월, 마이리얼트립은 전 테크 직군의 직무명을 Product Engineer(PE)로 전환하고 직무 확장 프로그램을 시작했습니다.

현재까지 총 3개 기수가 운영됐고, 비개발 직군도 참여하는 4기를 앞두고 있죠. 이 과정을 거치며 PE 구성원들이 다루는 문제의 범위와 역할의 스펙트럼도 점차 넓어지고 있습니다.

이 흐름 속에서 마련된 자리가 Product Engineer Possibility Exchange(PEPE) 세션이었습니다.

PEPE는 완성도 높은 결과나 성과를 공유하는 자리가 아니라, 어디까지 시도해봤는지, 어디에서 막혔는지, 그리고 그 과정에서 무엇이 달라졌는지를 솔직하게 나누는 자리입니다.

첫 발표는 Growth실 Engagement & Retention 팀의 김경훈님이 맡았습니다. 발표 주제는 안드로이드 개발자가 AI를 활용해 프론트엔드 영역까지 직접 구현해본 경험, 그리고 그 출발점이었던 리셀마켓(여행 상품 양도 서비스) 프로젝트였습니다.

안드로이드 개발자라는 분명한 출발점

발표에서 경훈님은 본인의 출발점을 안드로이드 개발자로 설명했습니다.

오랜 기간 모바일 플랫폼에서 개발을 진행해 왔으며, 중간에 서버 개발자로 직무 전환을 했던 경험도 함께 언급했습니다.

다만 프론트엔드 영역은 직접 구현해 온 영역이 아니라, 주로 협업의 대상이었던 영역이라고 설명했습니다.

리셀마켓, 그리고 우당탕 시작된 프론트엔드 개발

경훈님은 원래 iOS 직무 확장을 신청한 상태였습니다. 하지만 다음 날 바로 프론트엔드 개발을 맡게 됐고, 실제 개발 기간은 약 2주 남짓이었습니다. 배포는 11월 3일로 예정돼 있었고, 시간은 넉넉하지 않았습니다.

이때 AI가 개발의 출발점이 됐습니다.

경훈님은 커서(Cursor)를 열고 가장 먼저 이렇게 질문했다고 했습니다.
“나는 안드로이드 개발자고, 웹 개발은 잘 모른다. 이 프로젝트 전반을 설명해 줄 수 있나?”

AI를 활용한 방식은 단순한 코드 자동 생성이 아니었습니다.

프로젝트가 어떤 프레임워크와 구조로 구성돼 있는지, 화면을 그리는 부분은 어디인지, API 호출과 데이터 가공은 어떤 흐름으로 이뤄지는지를 파악하는 데 AI를 사용했습니다. 경훈님은 이를 ‘설계 도면을 먼저 파악하는 과정’에 비유했습니다.

과거 AI가 없던 시절의 직무 전환에서는 언어부터 공부하고, 그다음 프레임워크와 아키텍처를 학습한 뒤, 실무에 투입되는 바텀업 방식이 일반적이었습니다. 실제로 경훈님도 서버 개발자로 전환했을 당시, 언어와 프레임워크, 아키텍처를 순서대로 학습하는 데만 수개월이 걸렸다고 했습니다.

이번에는 접근 방식이 달랐습니다. 현재 프로젝트에 딱 필요한 프레임워크와 아키텍처를 먼저 파악하고, 바로 개발을 시작하는 탑다운 방식이었습니다. 언어 학습은 그 과정에서 병행됐습니다.

AI가 작성한 코드를 보며 “이 문장은 어떤 의미인가”, “왜 이렇게 동작하는가”를 하나씩 확인하며 필요한 언어 지식을 그때그때 채워 나갔습니다.

하지만, 반드시 챙겨야 할 부분이 있었습니다

경훈님은 이 지점에서 분명히 강조했습니다.

“AI 덕분에 빨라졌지만, 반드시 챙겨야 할 부분이 있다”고 말했습니다.

프로젝트를 시작하기 전, 경훈님은 프론트엔드 개발팀에 몇 가지 조건을 걸었다고 했습니다. 이 조건은 단순한 약속이 아니라, 스스로에게 건 규칙이기도 했습니다.

첫 번째 조건은 “내가 작성한 코드를 내가 이해할 수 있어야 한다”는 것이었습니다.

AI가 작성한 코드라 하더라도, 한 줄 한 줄 설명할 수 없다면 그 코드는 쓰지 않겠다는 기준이었습니다. 문제가 생겼을 때 대응할 수 없고, 새로운 요구사항이 들어왔을 때 수정할 수 없기 때문입니다. 실제로 경훈님은 AI에게 반복해서 “이 코드를 한 줄씩 설명해 달라”고 요청했고, 그 과정에서 언어 학습이 함께 이뤄졌다고 했습니다.

두 번째 조건은 “기존 프로젝트의 규칙을 최대한 따른다”는 것이었습니다.

이미 프론트엔드 팀이 만들어둔 구조와 컨벤션을 벗어나지 않기 위해, 다른 화면과 모듈은 어떻게 구성돼 있는지 계속 확인하며 코드를 다듬었습니다. 혼자만 이해할 수 있는 코드가 아니라, 팀의 코드로 남는 것이 중요했기 때문입니다.

배포, 그리고 소감

우여곡절 끝에 리셀마켓 프로젝트는 배포까지 완료됐습니다. 경훈님은 이 경험을 통해 몇 가지 중요한 소감을 정리했습니다.

첫째, 우리는 더 이상 ‘코드 라이터’가 아니라 ‘코드 로케이터’에 가까워졌다는 점입니다. 모든 코드를 손으로 작성하는 역할이 아니라, 어떤 코드가 어디에 배치돼야 하는지를 판단하는 역할이 더 중요해졌다고 했습니다.

둘째, 전공 외 영역에서는 모든 것을 공부할 필요는 없다는 점입니다. 전공 분야라면 언어, 프레임워크, 아키텍처를 깊이 있게 학습해야 하지만, 부전공 영역에서는 현재 직면한 문제에 필요한 것만 타겟팅해서 학습하는 방식이 오히려 효율적일 수 있다고 했습니다.

셋째, PE 관점에서는 아키텍처의 중요성이 더 커진다는 점입니다. 언어의 디테일보다, 구조와 책임을 읽어낼 수 있는 능력이 중요해졌다고 했습니다.

넷째, 생소한 환경에서 AI가 만든 코드의 ‘질’을 판단할 수 있어야 한다는 점입니다. 이를 위해서 결국 <클린코드>나 <리펙토링> <디자인 패턴> 등에서 학습한 기본기가 중요하며, 다시 ‘Back to the Basic’으로 돌아가게 된다고 정리했습니다.

결국, 혼자서는 할 수 없었습니다

경훈님은 마지막으로 가장 솔직한 이야기를 꺼냈습니다.

이 프로젝트는 결코 혼자 한 일이 아니었다는 점입니다. 10월 14일부터 11월 3일까지, 총 7번 이상 프론트엔드 전공자, 이른바 ‘스승님’을 찾았다고 했습니다. PR 리뷰, 배포, 브랜치 관리, 그리고 “이렇게 해결해도 괜찮은지”를 확인하기 위해서였습니다.

이 경험을 통해 경훈님은 하나의 고민을 던졌습니다. PE 한 명의 부전공 생산성보다, 전공자 한 명의 생산성이 훨씬 크다는 사실입니다. 그렇다면 조직 차원에서 PE를 도와주는 전공자의 생산성이 떨어지지 않도록 구조적으로 어떻게 지원해야 할지 고민해야 한다는 문제의식이었습니다.

AI가 많은 것을 도와줄 수는 있지만, 양질의 질문을 던질 수 있는 숙련도는 여전히 사람에게 달려 있고, 그 지점에서는 전문가의 도움이 필요할 수 있다는 점도 이야기했습니다.

PEPE 세션은 이런 이야기를 쌓아가는 자리입니다.

완벽한 결과보다, 어디까지 시도해봤는지에 대한 기록을 남기는 것. 김경훈님의 발표는 PE 직무 확장이 무엇을 의미하는지, 그리고 AI와 함께 일하는 개발자가 어떤 기준을 가져야 하는지를 잘 보여주는 사례였습니다.