Product Engineer: iOS 개발자, 프론트엔드에 도전하다

PEPE 세션 2 — Engagement&Retention팀 송은진 님

코드를 설계한 사람과 운영 및 고도화를 하는 사람이 다를 때, 개발은 전혀 다른 국면으로 들어갑니다. 두 번째 PEPE 세션은 바로 그 지점에서 출발한 이야기였습니다.

지난 첫 번째 PEPE 세션에서 김경훈님은 안드로이드 개발자가 AI를 활용해 리셀마켓 프론트엔드를 설계하고 배포까지 완료한 경험을 공유해 주셨습니다. 이번 두 번째 세션은 그 이후의 이야기입니다. 발표자는 같은 팀의 Product Engineer 송은진님으로, 이미 설계가 끝난 리셀마켓을 넘겨받아 실제 운영과 고도화를 맡은 입장에서 경험을 공유했습니다.

첫 번째 세션이 “어떻게 설계하고 배포했는가”에 대한 이야기였다면, 이번 세션은 “그 코드를 넘겨받아 실제로 고치고 키워 나가면서 어떤 일이 이어졌는가”에 더 가깝습니다. 설계와 고도화를 다른 사람이 맡을 때 무엇이 필요했는지, 그리고 그 과정에서 어떤 문제를 마주했고 어떻게 해결했는지를 중심으로 발표가 전개됐습니다.

iOS만 개발해온 개발자, 프론트엔드를 맡다

은진님은 약 4년간 Swift 기반 네이티브 iOS 앱만 개발해 왔습니다. 프론트엔드 개발 경험은 없었습니다. 마이리얼트립 Product Engineer 직무 확장 프로그램을 통해 프론트엔드 개발에 도전하게 되었고, 첫 번째 미션으로 리셀마켓 운영을 맡게 됐습니다.

리셀마켓의 전체 프론트엔드 아키텍처는 안드로이드 개발자인 김경훈님이 설계했고, iOS 개발자인 송은진님이 그 코드를 넘겨받아 고도화 해야하는 구조였습니다. 흔하지 않은 구성입니다.

“안드로이드 개발자가 설계한 아키텍처를 iOS 개발자가 받는 구조가 낯설면서도 신기했습니다. 그래서 더 중요하다고 느낀 게, 설계 의도와 맥락이 명확하게 기록돼 있어야 한다는 점이었습니다.”

그 기록은 코드 주석일 수도 있고, Claude나 Cursor로 작업할 때 생성한 md 파일일 수도 있습니다. 고도화를 하는 자가 설계자의 의도를 따라가기 위해서는, 단순히 코드가 아니라 “왜 이렇게 구현했는지”에 대한 설명이 남아 있는 것이 중요하다는 이야기였습니다.

검수 반려를 줄이기 위한 가이드, 바우처 명의 변경 자동화

은진님이 맡은 운영 미션은 크게 두 가지였습니다.

첫 번째는 검수 신청 페이지에 가이드 이미지를 추가하는 작업이었습니다.

리셀마켓에는 검수 신청 페이지가 있는데, 기존에는 가이드북 버튼만 제공되고 있었습니다. 이로 인해 예약 확정서나 영수증을 누락한 채 신청하는 경우가 많았고, 담당자가 반려 사유를 다시 안내해야 하는 일이 반복됐습니다. 이를 줄이기 위해 “어떤 서류를 어떻게 첨부해야 하는지”를 한눈에 볼 수 있는 가이드 이미지를 추가하는 작업이 진행됐습니다.

두 번째는 바우처 명의 변경을 판매자가 직접 할 수 있도록 개선하는 작업이었습니다.

기존에는 판매자가 바우처 명의 변경을 원할 경우, 담당자가 신규 구매자에게 직접 안내해야 했고, 전 과정이 수동 커뮤니케이션으로 이루어져 처리 지연과 번거로움이 컸습니다. 이를 개선하기 위해 구매자가 발생하면 거래 상태를 ‘거래중’으로 전환하고, 판매자가 여행자 정보를 직접 입력하면 해당 정보로 바우처 명의 변경까지 한 번에 처리되는 흐름을 구현하는 것이 목표였습니다.

고도화를 하는 자에게 중요한 질문은 “어디를 고쳐야 하는가”

업무를 맡은 입장에서 가장 먼저 필요한 것은 전체 구조에 대한 완벽한 이해가 아니라, “이 기능을 바꾸려면 어디를 고쳐야 하는가”였습니다.

은진님은 먼저 경훈님에게 리셀마켓 내 페이지 흐름을 설명 듣은 뒤, Cursor를 활용해 전체 구조 다이어그램과 컴포넌트 관계도를 요청했습니다. AI가 트리 구조로 시각화해 주면서, 수정해야 할 포인트가 빠르게 드러났습니다. 검수 신청 폼을 수정하려면 어떤 파일을 건드려야 하는지, 새로운 타입 값을 추가하려면 리셀 프로덕트 아이템 영역을 보면 된다는 식으로 명확해졌습니다.

“아키텍처를 새로 설계하는 입장이 아니라 운영을 맡은 입장이었기 때문에, 어떤 부분을 어떻게 바꿔야 빠르게 작업할 수 있는지가 가장 중요했습니다.”

리셀마켓의 세부 정책을 모두 알지 못하더라도, 컴포넌트 관계도를 통해 전체 흐름과 현재 사용 중인 타입을 파악할 수 있었습니다. Swift에 익숙한 만큼, 새로운 언어 역시 Swift와 비교하며 학습했고, 그 과정에서도 AI를 적극적으로 활용했다고 설명했습니다.

Cursor 블로그에서 실제로 도움이 됐던 세 가지

송은진님은 Cursor 공식 블로그(2026년 1월 9일, agent-best-practices)에 소개된 AI 프롬프트 작성 팁 열 가지 중, 실제로 도움이 됐던 세 가지를 공유했습니다.

첫째, Plan 모드 활용입니다. Plan 모드를 사용하면 파일 조사, 질문, 구현 계획이 정리된 md 파일이 생성되며, 이를 기준으로 작업을 진행하면 의도한 방향에서 벗어날 가능성이 줄어듭니다.

둘째, 결과가 만족스럽지 않을 경우 계획을 재정비한 뒤 재실행하는 것입니다. 같은 대화에서 계속 수정하기보다, 목표와 맥락을 다시 정리한 뒤 새로 실행하는 편이 더 효율적이라고 설명했습니다.

셋째, 기능 단위가 바뀌면 새 대화에서 작업을 진행하는 것입니다. 작업 범위를 명확히 나누는 것이 결과 품질에도 긍정적인 영향을 미친다는 이야기였습니다.

“결국 중요한 건 명확한 목표, 충분한 맥락, 그리고 검증 기준을 먼저 설계하는 것입니다.”

웹뷰에서 챗봇 아이콘이 보이지 않았던 이유

개발 중 한 팀원이 DM으로 모바일 웹뷰에서 리셀마켓 문의 버튼이 보이지 않는다는 이슈를 전달했습니다. 웹뷰에서만 발생하는 문제인지, 정책인지, 버그인지 확인이 필요했습니다.

코드를 확인한 결과, 모바일 웹뷰 환경에서는 SendBird 아이콘이 의도적으로 숨겨지도록 구현돼 있었습니다. 버그 여부를 판단하기 위해 프론트엔드 전공자 분들께 여쭤봤고, 관련 스레드를 찾아주시며 모바일 웹이나 외부 환경에서는 해당 아이콘을 노출하지 않는 것이 정책 상 맞다는 설명을 해 주셨습니다.

공통 로직을 수정할 경우 앱 내 모든 웹뷰에 영향을 줄 수 있어 사이드 이펙트가 우려됐고, 결국 리셀마켓 웹뷰에서만 별도의 버튼을 두고 해당 버튼을 통해 SendBird 링크로 이동하는 방식으로 우회했습니다.

배포 권한이 없을 때, Charles로 웹뷰 먼저 확인하기

당시 은진님은 프론트엔드 Jenkins(dev 환경) 배포 권한이 없는 상태였습니다. 직무확장 온보딩을 막 시작한 지 일 주일도 안 된 시점이라, 개발이 끝날 때마다 뒤에 계시는 프론트엔드 전문가들에게 배포를 요청해야 했고, 버그가 있으면 수정 후 다시 요청하는 과정이 반복됐습니다. 1~3일 정도면 배포해 주셨지만, 수정과 테스트 사이클이 길어지는 건 피하기 어려웠습니다.

이 문제를 해결하기 위해 배포 없이 웹뷰를 확인할 수 있는 방법을 찾았고, 선택한 도구가 Charles였습니다.

Charles는 네트워크 요청·응답을 제어하고 원하는 주소로 맵핑할 수 있는 프록시 도구입니다. SSL Proxying을 켜면 현재 사용 중인 서버 주소와 포트를 확인할 수 있고, PC와 모바일을 같은 Wi‑Fi에 두고 모바일에서 해당 주소로 HTTP 프록시를 설정한 뒤, Charles의 Map Local에서 “현재 Host + Path”를 “작업 중인 로컬 Host + Path”로 맵핑하면 앱 웹뷰가 서버가 아닌 로컬 환경을 바라보게 됩니다. 이를 통해 배포 없이도 웹뷰 동작을 검증할 수 있었습니다.

또 다른 방법으로는 모바일 테크톡에서 다른 동료가 소개해 준 건데요. Chrome 확장 프로그램 ModHeader를 설치한 뒤, 앱에서 전달하는 정보(App 정보)를 브라우저 요청에 추가하면 브라우저에서도 웹뷰에서 보는 화면과 동일하게 확인할 수 있다고 합니다. 은진님은 아직 직접 사용해 보지는 않았지만, 충분히 시도해볼 만한 방법이라고 덧붙였습니다.

배포 이후 마주한 이슈들

배포 이후에도 두 가지 이슈가 추가로 발생했습니다.

첫 번째는 안드로이드에서만 사진 업로드가 되지 않는 문제였습니다. 처음에는 본인이 수정한 코드(사진 업로드 가이드) 때문이라고 의심했지만, GPT, Cursor에 물어보고 코드를 점검해도 해결되지 않았습니다. 확인 결과 안드로이드 WebView에서는 파일 선택을 위한 별도의 콜백 처리가 필요하다는 점이 원인이었습니다.

두 번째는 특정 상황에서 페이지가 무한 리로드되는 문제였습니다. 웹뷰 로그인 필수 페이지에서 SSR(webViewServerSideProps)이 누락돼 웹뷰 판정이 실패했고, 이로 인해 useAuth 리다이렉트가 반복되면서 무한 리로드가 발생했습니다.

“플랫폼별로 알아야 할 전문적인 지식이 아직 부족하다고 느꼈고, 계속 학습이 필요하다고 생각했습니다.”

역할 확장이 가져온 변화

프론트엔드 직무 확장 이후, 은진님은 스스로 해결할 수 있는 범위가 넓어졌다고 느꼈습니다.

예를 들어 커뮤니티 데이터 수집과 필터링이 필요한 상황에서, 이전에는 백엔드 개발자에게 최근 6개월치 커뮤니티 글 데이터를 요청했을 것입니다. 이번에는 프로젝트에 접근할 수 있게 되면서 매니저 페이지에서 필터를 걸어 데이터를 조회하고, 필요한 만큼 가공해 활용할 수 있었습니다. 이를 통해 의사결정에 필요한 정보를 더 빠르게 확보할 수 있었고, 팀의 업무 효율에도 기여할 수 있었습니다.

은진님은 발표를 마무리하며, AI가 많은 부분을 도와주지만 플랫폼별 특성이나 WebView, SSR과 같은 영역은 여전히 직접 학습이 필요하다고 강조했습니다. 첫 번째 세션에서 언급된 “Back to the Basic”과 마찬가지로, 기본기에 대한 중요성을 다시 한번 느꼈다고 전했습니다.

PEPE 은진님의 발표는 Product Engineer 직무확장이 설계와 배포에서 끝나지 않는다는 점을 보여줬습니다.

운영 단계에서 마주하는 문제와 그 과정에서 축적되는 학습이, 결국 역할을 확장시키는 핵심이라는 점을 다시 한번 확인할 수 있었습니다!