Product Engineer: “코드는 AI가, 나는 제품 관점에서 고민을” AI 네이티브 개발 한걸음

“코드를 누가 짜는가”에 따라 개발자의 역할이 달라집니다. 두 번째 PEPE 세션에서는 설계가 끝난 코드를 넘겨받아 운영·고도화를 맡은 입장의 이야기가 나왔습니다.

마이리얼트립 세 번째 PEPE(Product Engineer Possibility Exchange) 세션에서는 세일즈 솔루션팀 송다인님이, 코드 작성 대부분을 AI에게 맡기고 사람이 “무엇을 만들지” “왜 만드는지”를 정한 뒤 결과를 검증하는 — 일상 업무에 AI를 활용하는 AI 네이티브(Native) 개발의 한 모습 — 으로 옮겨 온 경험을 나눴습니다.

“왜 만드는지 알면 더 잘 만들게 될 것이고. 사용자의 흐름을 알면 구현 우선순위가 보입니다.”

이번 세션에서는 코드를 AI에게 맡기고 검증에 집중하게 된 전환, AI로 디자인·코드를 뽑아 내는 해커톤 사례, 그리고 “빨리 만드는 것보다 실서비스 환경에 맞추는” 과정에서 생긴 병목과 PE(프로덕트 엔지니어)로서 이어지는 고민을 소개합니다.

왜 만드는지 알면, AI에 맡길 때도 방향이 잡힌다

AI에게 작업을 맡기는 개발에서도 “무엇을 만들지”, “왜 만드는지”가 먼저 있어야 AI가 만든 결과를 제대로 검증할 수 있습니다.

한 프로젝트에서 웹·iOS·안드로이드가 함께하는 프론트 팀과 일하며 송다인님은 그걸 구체적으로 깨닫게 됐습니다.

제품 흐름은 예약 생성부터 여행자 화면, 주문·결제까지 이어지는데, 당시 잘 알고 있던 건 그중 “여행자 화면” 하나뿐이었습니다. 팀과 함께 하면서 연결되는 흐름을 가깝게 이해하게 되었고, 그때부터 “왜 만드는지”를 같이 보는 게 중요하다고 느꼈습니다.

“iOS 개발을 하더라도 제품 관점으로 보면 몰입도가 높아졌어요.

큰 그림을 이해했을 때 구현이 아닌 해결책, 화면 완성이 아니라 이 화면이 누구에게 연결되는지에서 만족도를 얻는다고 생각했어요.”

같은 내용을 바라보고 있는지가 중요하다는 것입니다. 서버 쪽 흐름을 이해하면 화면 설계를 잘 파악할 수 있고, 플랫폼 간 합의가 코드 품질을 높인다고 봅니다. AI에게 맡기며 개발할 때도 사용자 흐름을 알면 “무엇을 AI에게 맡기고, 무엇을 검증할지” 구현 우선순위가 보인다는 요지였습니다.

AI가 디자인하고 코드를 만들고, 사람은 맥락을 준다 — 해커톤 사례

AI가 만들고 사람이 검증하는, 즉 에이전트형 코딩(agentic coding) 흐름을 구체적으로 보여준 사례는 작년 12월 말 동료와 함께한 항공권 지연 정보 해커톤입니다.

앱스토어 사용자 리뷰에서 항공권 지연 정보를 확실히 알 수 없다는 점이 반복됐고, 지연 시 안내·알림톡 등 팀 프로세스를 보며 이걸 앱에 녹이면 여행자 문제를 개선할 수 있겠다고 판단했습니다.

앱의 여행 일정·예약 정보 화면에는 인천공항 실시간 현황이 있었지만 인천공항에 한정돼 있어 다른 공항 데이터를 앱과 연결할 수 없을까 하는 고민이 나왔습니다. 메인 서비스에 녹여 앱과 연결하면 광고 배너·상품 추천, iOS 실시간 데이터까지 이어질 수 있겠다는 방향으로 기존 아이디어를 다듬기로 했습니다. 항공권 상세에서 지연·게이트·수화물 변경을 전 세계 공항에서 알 수 있게 하고, 도착 시 아직 구매하지 않은 사람에게 상품을 연결하며, 비행 중 실시간 정보는 iOS 기능으로 보여 주는 것을 목표로 했습니다.

구현은 에이전트형 코딩에 가깝게 갔습니다. Figma Make로 AI가 디자인 시안을 만들고, Figma MCP로 그 디자인을 코드로 바꾸는 방식이었고, 당시에는 Cursor로 코드를 작성했습니다. 기존 화면과 결을 맞추기 위해 링크·참고 앱 정보를 넘겨 화면을 받았고, 항공권 정보와 연결해 출발 시점별 경우를 정리해 구현했습니다. 하단 추천은 기존 검색 결과의 목록을 그대로 활용했고, iOS에서는 앱을 켜지 않아도 볼 수 있는 정보 제공을 염두에 두었습니다.

AI가 만든 코드를 실서비스 환경에 맞추는 과정

AI가 디자인을 만들고 코드를 뽑아 내는 것까지는 수월했습니다.

병목은 그다음입니다. “만들어 달라”고 하면 만들어 주지만, 그 결과물을 기존 코드·디자인 규칙·팀 규칙에 맞추는 건 사람이 맡아야 할 부분이었습니다. 기존 항공 정보 영역의 구현 방식·노출 조건 파악이 어려웠습니다. Figma Make로 만든 시안에 팀 디자인 규칙을 적용하는 것, 화면 단계에서 디자인 세부 사항을 요청하는 것도 쉽지 않았고, 목록을 검색 결과의 것을 그대로 쓸 때 웹·앱 화면 쪽 규칙에 맞는지 검토가 필요했습니다. 그런 “맞추는” 고민은 해커톤이 끝난 뒤에도 이어졌습니다.

“빠르게 만드는 것보다는 이 결과물을 우리 환경에 맞추는 과정에서 고민되는 사례들이 많았다고 생각해요.”

마이리얼트립은 AI Native(네이티브) 조직으로서, 구성원이 AI에 대한 의견을 나누고 어려운 점에 대해 도움을 받는 ‘모두의 AI’라는 슬랙 채널이 활성화되어 있습니다.

그 채널에서 기존 인천공항 플라이보드(실시간 현황 서비스)와 해커톤 아이디어로 나왔던 항공편·항공권 추적에 대한 이야기가 고객 관점에서 그 필요가 제기되며 다시 논의됐습니다. 그렇게 직접 추적·알림을 만드는 작업이 이어졌습니다. 그 과정에서 항공 개발팀처럼 도메인 지식이 있는 사람의 의견이 반영되었고, 현재는 그 결과물을 메인 서비스에 녹이는 작업을 진행 중입니다.

송다인님은 이렇게 채널에서 나눈 의견이 서비스에 반영되는 것이 의미 있다며, 앞으로도 그런 논의가 이어질 자리가 있기를 바란다고 강조했습니다.

그런 문제의식은 해커톤이 왜 쉬웠는지, 실제로는 왜 더 어려운지와도 맞닿아 있습니다. 해커톤에서 하루 이틀 만에 구현할 수 있었던 건 요구사항이 두 사람의 머릿속에서만 나온 수준이라 단순했고 충돌·플랫폼 간 맞춤이 없었기 때문입니다. 실제 서비스 배포 단계에서는 기존 코드와의 충돌, 다른 플랫폼과의 맞춤, AI가 만든 코드를 어떻게 검증할지가 더 큰 과제로 남았습니다.

그 고민을 지금은 PE 조직에서 하고 있습니다. 기획·디자인·개발을 통합한 프로덕트 엔지니어 직무 체계에서 AI·개발 프로세스를 개선하는 프로젝트로 그 작업이 이뤄지고 있습니다.

AI가 이해할 수 있는 규칙 — PE와 iOS 파트

PE 조직에서는 “AI가 이해할 수 있는 형태로 규칙이 정리돼 있어야 한다”는 게 공통 인식입니다.

설계·개발·테스트 전체 흐름에서 AI가 PRD(제품 요구사항 문서)를 만들어낼 수 있는지에 초점을 두고, 코드 리뷰 막단뿐 아니라 개발·설계 과정에 녹여 넣어야 비용을 되돌리지 않고 맞출 수 있다는 의견이 공유됩니다. 회사 전체 규칙을 AI가 이해할 수 있는 형태로 정리할 필요가 있고, 디자인 규칙·목록 같은 주제는 사람끼리도 논의를 많이 했는데 규칙이 정리되지 않았던 것이 아니냐는 생각이 든다고 합니다.

인프라, 권한, 서버·iOS·안드로이드·애플, 분야별 프롬프트 설계, 기존 소프트웨어 유지 보수 등 플랫폼별 병목을 점검하고 있습니다.

마이리얼트립에는 이런 PE 성장을 지원하는 PE Expert(엑스퍼트)라는 내부 전문가 그룹이 있습니다. 직무확장 프로그램을 통해, AI Native 업무 방식과 회사 개발 맥락을 이해하고 다른 구성원이 개발에 기여할 수 있도록 돕는 역할을 맡습니다.

iOS 개발 파트에서는 프로젝트 규칙·문서 기본 틀을 만들고, 기존 스타일·시스템 미준수 대응과 목록 반복 작업·검증 흐름을 구축해 나가고 있습니다.

송다인님은 항공·투어 등 서비스별 첫 화면에서 목록 열 가지 화면을 Figma와 정의 문서가 연결돼 원하는 결과가 나오는지 테스트 중이며, 주 1회 미팅으로 병목을 개선하고 있습니다. 예전 iOS 쪽 개발 문화를 만드던 것이 지금 다시 이어지고 있지 않나 하는 인식입니다.

숙소, 투어·티켓, 항공, 마이팩 등 서비스별 첫 화면 개발에서는 서비스마다 다른 로직의 의도와 필요성을 판단하는 과정이 가장 어려웠습니다. 그래서 각 서비스 담당 팀과 의사소통하며 논의가 필요했고, 구역 규칙은 분산돼 있어 Figma 디자인을 한 번에 정책으로 뽑는 것도 어려웠습니다. 그런 과제를 PE Expert 팀에서는 서비스별 정책, API 접근 방법 논의로 풀어 가고 있습니다.

코드 작성은 위임하고, 목적과 검증에 집중하기

송다인님은 작년 1월만 해도 Cursor를 잘 모르는 수준이었고, 이후 AI 보조 코딩 도구로 개발하다가 최근에는 코드 작성 대부분을 AI에게 맡기게 되었습니다. “AI가 만들고 사람이 검증한다”는 쪽으로 바뀐 셈입니다.

AI가 구현을 잘하려면 초반에 설계를 잘하는 것이 중요합니다. 작업 흐름·빌드 병목이 iOS 쪽에서 선제적으로 제거되면서 단순 구현·반복 작업은 AI가 상당 부분 담당하게 되었고, MCP 도입으로 iOS 빌드 환경 관리 부담이 줄고 시나리오 기반 자동 테스트가 가능해져 반복 작업이 감소했습니다.

지금은 Claude Code를 많이 쓰며, “직접 짜기”보다 “목적을 주고 결과를 검증하기”에 더 가깝게 일하고 있습니다.

“개발 관점에서 코드를 작성하기보다는 설계에 대한 고민이 늘어났어요. 어떻게 구현할까가 아니라 어떤 목적을 갖는지, 빨리 만드는 것보다 만든 게 어떤 가치를 주는지가 중요해요.

혼자 해결하기보다 팀과 방향을 맞추고 규칙을 정리하는 게 더 빠르고, 기능 완성으로 끝이 아니라 다음 단계를 같이 고민하는 게 다음 스텝이에요.”

AI에게 맡기며 개발하면 그 구분이 더 분명해집니다. 송다인님은 AI 도구로 해커톤과 실제 서비스 배포의 차이를 경험했고, PE 조직에서 설계·규칙·검증을 함께 고민하며 “AI가 이해할 수 있는 규칙”과 팀의 같은 방향을 맞추는 것이 더 빠르게 결과를 낸다는 것을 확인했습니다.

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