[여기어때] Product Owner [주문/결제] 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 앱·웹 주문서와 예약·취소·부분취소·환불 프로세스의 정책을 세우고 프로덕트를 기획·운영합니다(관련 백오피스 포함).

  이렇게 볼 수 있어요

  국내숙소부터 패키지, 렌터카·레저티켓, B2B까지 모든 상품이 하나의 주문결제 플랫폼에서 거래되므로, 취소·환불 정책도 상품마다 다른 규정을 한 흐름에서 처리하는 구조입니다. 상품별 취소 규정이 다른 서비스에서 부분취소나 환불 정책을 설계해 본 경험이 이 업무와 바로 이어집니다.

• PG 연동, 결제수단·간편결제 도입 등 결제 로직과 정책을 기획하고, PG사 등 결제 파트너와의 제휴 협의와 대외 업무를 맡습니다.

  이렇게 볼 수 있어요

  PG·간편결제 제휴 협의에서는 수수료율, 정산 주기, 결제사 할인 프로모션의 비용 분담이 주로 다뤄집니다. 기획과 함께 PG사 같은 결제 파트너와 이런 조건을 협의해 본 경험이 있다면 협의한 항목과 결과를 함께 적습니다.

• 쿠폰·즉시할인·포인트·상품권 등 혜택 정책을 기획·운영하고 주문·결제 데이터와의 연계를 설계합니다.

  이렇게 볼 수 있어요

  혜택이 결제와 정산 데이터로 어떻게 이어지는지까지 설계합니다. 이 PO는 혜택 기획과 결제 데이터 설계를 함께 다룹니다.

• 국내외 숙소, 채널링 등 도메인별 공급사 연동 구조를 이해하고, 신규 상품·사업 출시 때 주문결제 플랫폼 대응과 예약 API 연동을 기획합니다.

  이렇게 볼 수 있어요

  새 상품이 붙을 때마다 주문결제 쪽 대응을 설계합니다. 외부 공급사 API와 주문 흐름을 연결해 봤다면 어떤 예외를 처리했는지까지 밝힐 수 있습니다.

• 주문·결제·혜택 데이터 정합성을 검증하고 거래 리스크를 관리하며, 운영 이슈가 생기면 근본 원인을 분석해 정책과 시스템 개선을 주도합니다.

  이렇게 볼 수 있어요

  정산 단계의 대사는 같은 회사 Product Owner [정산·재무·회계시스템] 공고가 맡습니다. 이 자리는 그 앞의 주문·결제·혜택 데이터가 맞는지를 책임집니다. 결제는 승인됐는데 공급사 예약 확정이 실패하거나 부분취소 뒤 쿠폰이 복원되지 않는 경우처럼 주문과 결제 기록이 어긋나는 지점이 자주 생깁니다. 그런 불일치의 원인을 찾아 시스템을 고친 사례라면 불일치 규모와 고친 뒤 결과를 나란히 쓰면 개선 폭이 분명해집니다.

2자격 요건

• 프로덕트 관리(PM/PO) 경력이 5년 이상 필요합니다.

  이렇게 볼 수 있어요

  같은 회사 PO 공고 가운데 Product Owner [파트너서비스]는 3~5년을, 이 공고와 Technical Product Owner는 5년 이상을 적었습니다. 서비스 기획자로 주문이나 결제 기능을 맡아 온 기간도 프로덕트 관리 경력으로 함께 적을 수 있습니다. 그 기간에 맡은 기능과 직접 결정한 범위는 구체적으로 쓰는 것이 좋습니다.

• E-commerce나 예약 플랫폼에서 주문, 결제, 예약/취소, 혜택(쿠폰/포인트) 가운데 하나 이상의 프로덕트를 기획·운영해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  업무에는 네 영역이 모두 들어 있습니다. 실제 일은 쿠폰을 쓴 주문을 부분취소할 때 혜택 복원과 결제 부분환불이 한 번에 움직이는 식으로 영역 사이에서 생깁니다. 맡았던 영역을 밝히고, 다른 영역과 맞물린 예외를 처리해 본 일이 있다면 함께 적을 수 있습니다.

• API, 데이터 흐름, 시스템 간 연동 구조를 이해하고 개발팀과 기술적 트레이드오프를 논의할 수 있어야 합니다.

  이렇게 볼 수 있어요

  주문결제에서 개발팀과 논의하는 트레이드오프는 공급사 예약 확정을 기다릴지 결제를 먼저 받을지, 결제 요청이 중복될 때 어떻게 한 번만 처리할지 같은 문제입니다. 업무에도 예약 API 연동 기획과 PG 연동이 함께 있습니다. 이런 결정을 개발팀과 의견을 나눠 정한 사례는 면접에서 꺼낼 수 있게 준비합니다.

• 복잡한 문제를 논리적으로 구조화하고, 개발·QA가 바로 착수할 수 있는 수준의 정책서·PRD·인수 조건(AC)을 쓸 수 있어야 합니다.

  이렇게 볼 수 있어요

  PRD와 인수 조건(AC)까지 이름으로 적은 것은 같은 회사 PO 공고 네 건 가운데 이 공고뿐입니다. 인수 조건은 QA가 바로 테스트 케이스로 옮길 수 있게 조건과 기대 결과를 짝으로 쓰는 경우가 많습니다. 취소·환불처럼 경우의 수가 많은 정책을 AC로 풀어 쓴 문서가 있다면 그 문서로 개발과 QA가 어떻게 진행됐는지 설명할 수 있습니다.

• 개발, QA, 디자인, 사업, 운영 등 여러 이해관계자와 원활하게 소통하고 우선순위를 조율할 수 있어야 합니다.

  이렇게 볼 수 있어요

  국내숙소부터 B2B까지 여러 사업이 한 주문결제 플랫폼을 씁니다. 그래서 사업 조직마다 다른 요청이 같은 개발 일정 안에서 부딪칠 수 있습니다. 서로 다른 사업의 요청과 운영 이슈가 동시에 몰렸을 때 우선순위를 정한 기준과 그 결정을 QA·운영에 어떻게 공유했는지를 사례로 듭니다.

• 데이터 무결성과 정확성을 최우선으로 두고 세심하게 검증하는 태도가 필요합니다.

  이렇게 볼 수 있어요

  주문결제 데이터의 금액 차이는 1원이라도 정산과 회계 마감에서 다시 나타납니다. 뒤에서 고칠수록 바로잡을 범위도 커집니다. 업무의 정합성 검증과 관련해 숫자가 맞지 않는 것을 먼저 발견해 바로잡은 일이 이 태도를 보여 주는 예입니다. 차이를 어디까지 추적했는지까지 말하면 세심함이 구체적으로 보입니다.

3우대 사항

• 여행, 숙박, 액티비티, 렌터카 등 여가 플랫폼(OTA) 거래 도메인 경험을 우대합니다.

  이렇게 볼 수 있어요

  업무에 도메인별 공급사 연동 구조와 예약 API 연동 기획이 있어, OTA 거래 경험 우대는 예약 확정을 외부 공급사와 주고받는 주문 흐름을 다뤄 봤는지와 관련됩니다. 공급사의 예약 확정이 늦거나 실패할 때의 주문 처리 정책을 다뤄 봤다면 그 사례가 이 우대의 근거가 됩니다.

• PG 결제 연동, 간편결제, 결제수단 도입 프로덕트 기획 경험(PG사·카드사 대외 협의 포함)이나 핀테크·결제 생태계에 대한 높은 관심을 우대합니다.

  이렇게 볼 수 있어요

  결제수단 하나를 새로 붙이려면 제휴 계약, PG를 거칠지 직접 연동할지의 결정, 결제창 노출 순서와 혜택, 정산 확인까지 거쳐야 합니다. 결제수단을 새로 붙여 본 프로젝트가 있다면 이 가운데 맡았던 단계를 나눠 밝힙니다. 직접 해 보지 않았다면 간편결제사별 혜택 경쟁 같은 생태계 흐름을 여기어때 결제 화면에 비춰 말해 볼 수 있습니다.

• 쿠폰·포인트·즉시할인 등 혜택 정책 설계 경험과, 혜택이 정산 데이터로 이어지는 흐름에 대한 이해를 우대합니다.

  이렇게 볼 수 있어요

  혜택과 정산의 연결을 이해하는지 묻습니다. 쿠폰이나 포인트 비용이 정산 데이터에 어떻게 반영되는지가 면접에서 나올 수 있는 질문입니다.

• B2B 서비스나 홀세일, 채널 연동 프로덕트를 기획·운영해 본 경험이나 외부 공급사 채널 API 연동 프로덕트 경험을 우대합니다.

  이렇게 볼 수 있어요

  업무에 적힌 공급사 연동이 우대 사항에도 다시 나옵니다. B2B나 홀세일, 채널 연동 프로덕트를 다뤘다면 연동한 채널 수와 방식을 함께 적을 수 있습니다.

• SQL로 데이터를 검증·분석하고 데이터 기반으로 의사결정해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 PO 공고 가운데 이 공고와 Product Owner [정산·재무·회계시스템]는 SQL을 데이터 검증에 쓰는 능력으로, Technical Product Owner는 조회와 기본 분석으로 적었습니다. 쿼리로 주문과 결제 금액이 어긋난 건을 찾아낸 사례가 있다면 업무의 정합성 검증과 함께 이야기할 수 있습니다.

• 대규모 플랫폼 개선·재설계 등 규모 있는 프로젝트를 PO로서 발의부터 오픈까지 리딩해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  업무에 신규 상품·사업 출시 때 주문결제 플랫폼 대응 설계가 있고, 여기어때는 2026년에 해외투어를 열고 리럭스 숙박 상품을 연동했습니다. 결제 플랫폼을 고치거나 다시 설계하며 새 상품을 붙여 본 프로젝트는 기존 거래를 멈추지 않고 어떻게 옮겼는지까지 적어야 프로젝트의 규모가 전해집니다.

4기타 사항

• 게시일 : 2026년 9월 15일
• 고용형태 : 정규직(수습 3개월)
• 근무지 : 서울 (대한민국 서울특별시 강남구 봉은사로 479)
• 경력 조건 : 경력 5~10년
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• PG
• API
• SQL

전형과 지원

여기어때 합류 여정은 서류 심사, 1차 인터뷰, 2차 인터뷰, 처우 협의, 입사 확정 순서이고 직군과 직책에 따라 코딩 테스트, 과제 테스트, 사전과제, 추가 인터뷰, 레퍼런스 체크 등이 추가되거나 생략될 수 있습니다. FAQ가 24개 질문에 답해 두어 인터뷰 형식과 결과 안내 기간까지 미리 확인할 수 있습니다.

지원 전 준비할 것

1. 1

   정책서·PRD 사례

   직접 쓴 주문·결제·환불 정책서나 PRD 하나를 골라 개발이 바로 착수할 수 있었던 근거를 정리합니다.

2. 2

   정합성 이슈 해결

   결제나 혜택 데이터 불일치를 찾아 원인을 고친 사례를 준비합니다.

3. 3

   신규 상품 연동

   새 상품이나 공급사를 주문 흐름에 붙인 경험이 있다면 설계한 예외 처리를 적어 둡니다.