마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer

소수정예 팀, 핵심인재 중심의 조직 마이리얼트립은 핵심인재가 소수정예 팀을 이루어, 높은 책임과 자율 속에서 일하는 조직입니다.

작은 팀이 빠르게 결정하고 실행하며, 고객의 문제에 끝까지 책임을 집니다. 우리는 맥락 없이 일을 던지지 않고, 변화를 전제로 일합니다.

이 기준이 자연스럽고, 이 기준을 스스로에게 요구할 수 있는 분이라면, 우리가 바라보는 ‘여행 경험의 완전한 연결’을 함께 현실로 만들어갈 수 있다고 믿습니다.

포지션 상세

마이리얼트립이 지향하는 개발 문화인 'Product Engineer'에 대해 알려드려요.

• AI 시대, 개발자의 역할은 한 분야에만 머무르지 않습니다.
• 마이리얼트립의 Product Engineer는 고객의 문제를 발견하고, 해결책이 실제로 효과를 발휘할 때까지 끝까지 책임지는 개발자입니다.
• 우리는 기술 전문성을 기반으로, 제품과 고객 경험 전반을 아우르며 이렇게 일합니다.

(1) 고객 중심 문제 정의

• 사용자와 고객의 관점에서 사고하며, 겉으로 드러난 증상보다 근본 원인을 찾아냅니다.
• “무엇을 만들 것인가?”보다 “왜 만들어야 하는가?”를 먼저 고민하고, 문제 해결의 방향을 스스로 설정합니다.

(2) 경계 없는 문제 해결

• 다양한 기술 영역의 경계를 넘나들며, 문제를 가장 빠르게 해결할 수 있는 방법을 스스로 찾아 실행합니다.
• 필요하다면 새로운 기술을 배우고 적용하며, 역할과 역량을 확장합니다.

(3) 민첩하게 실행, 개선

• 복잡한 절차를 줄여 빠르게 결정하고, 짧은 피드백 주기로 지속적으로 제품을 개선합니다.

(4) 끝까지 책임지는 태도

• 릴리즈가 끝이 아니라, 고객의 문제가 사라질 때까지 개선과 운영을 이어갑니다.

마이리얼트립의 Product Engineer는 기술과 역할의 경계를 넘어 고객 가치가 현실이 될 때까지 끝까지 책임지는 개발자입니다.

함께 일하게 될 팀

우리는 마이리얼트립의 여행자, 파트너, 주문 도메인 핵심 플랫폼을 개발하는 팀입니다. 여행자에게는 쉽고 편리한 구매 경험을, 파트너에게는 유연하고 확장 가능한 비즈니스 환경을 제공하기 위해 노력하고 있습니다.

회원가입, 프로필, 멤버십, 주문, 제휴 및 마케팅 등 이커머스 플랫폼 전반을 책임지며, 서비스의 확장성과 신뢰성을 높이기 위한 기술적 혁신과 개선을 지속적으로 추진하고 있습니다.

우리는 다음과 같은 개발 문화를 지향합니다

• “Why”에 집중합니다. 단순한 기능 구현보다 문제의 본질을 이해하고 해결하려 합니다.
• 고객 중심의 사고를 바탕으로, 사용자 경험을 가장 먼저 고려합니다.
• 주도적으로 문제를 정의하고 해결하며, 팀의 성장을 함께 만들어가는 리더십을 기대합니다.
• 수평적이고 열린 소통을 통해 서로의 전문성을 존중하며 함께 발전합니다.
• 기술 스택의 경계를 두지 않고 문제 해결에 집중하며, 프론트엔드나 인프라와 같은 인접 분야로의 확장을 두려워하지 않는 분을 환영합니다. 새로운 기술 변화에 경계심 없이 몰입하며 빠르게 학습하고, 변화를 즐기는 태도를 가진 분과 함께하고 싶습니다.

이러한 여정에 함께할 열정 있는 개발자를 기다리고 있습니다.

주요업무

• 주문과 위시리스트 데이터를 기반으로 여행자 경험과 비즈니스 성과를 함께 향상시킬 수 있는 제품을 만듭니다.
• 신뢰도 높은 여행자 회원, 프로필, 멤버십 프로그램을 개발합니다.
• 마이리얼트립과 함께 여행 생태계를 만들어가는 파트너(상품, 제휴, 광고주)를 위한 비즈니스 플랫폼을 설계하고 구현합니다.
• 다양한 내부 고객(PM, 디자이너, 운영, QA, BI 등)과 협업하며, 복잡한 비즈니스 요구를 기술로 풀어냅니다.
• 안정성과 확장성을 고려한 아키텍처와 운영 자동화 도구를 설계하고 적용합니다.

자격요건

• Java(Kotlin) & Spring Framework 기반 웹 서버 개발 경력 5년 이상
• Restful API 설계 / 구현 경험이 있으신 분
• ORM (JPA, Hibernate)기반 개발 역량을 보유하신 분
• NoSQL(Redis, ElasticSearch, Kafka) 개발 및 운영 경험이 있으신 분
• 대규모 서비스 설계, 구축, 운영 경험이 있으신 분
• 다양한 Stakeholder, 개발자와 함께 복잡한 비즈니스 요구사항을 풀어내며 적극적이고 원활한 커뮤니케이션이 가능하신 분
• 제품 및 서비스의 성장을 위한 개선 기획과, 안정적이고 효율적 제공을 위한 운영 기획을 주도적으로 수행하여 객관적으로 훌륭한 성과를 만들어낸 경험이 있으신 분
• 목표에 대한 지표 설정, 액션 아이템을 도출하고 성과를 만드는 역량이 있으신 분
• 특정 기술 스택에 얽매이지 않고, 프론트엔드·인프라 등 인접 영역에 대해 학습하고 협업할 수 있는 유연함이 있으신 분
• 변화하는 기술 환경에 빠르게 적응하며, 새로운 기술을 즐겁게 받아들이는 분

우대사항

• 이커머스 회원, 주문 도메인 경력을 가지고 계신 분
• Cloud 환경(AWS)에서 개발 경험이 있으신 분
• MSA(Microservice Architecture), EDA(Event Driven Architecture) 개발 경험이 있으신 분
• 컴퓨터 공학 또는 관련 분야 학사 학위를 소지하신 분
• 조직의 기술과 문화를 지속해서 높여나가기 위해 적극적인 활동을 하신 분
• 다양한 AI 도구를 적극 활용해 생산성을 극대화해본 경험이 있으신 분
• AI 를 활용한 응용서비스를 개발해본 경험이 있으신 분
• 기술 스택에 상관없이 제품을 기획부터 개발, 배포까지 완료해본 경험이 있으신 분

면접 질문 대비

Q1. "병태님은 NHN에서 슬롯 AI TF로 활동하시며, AI 에이전트를 활용해 슬롯 서버 개발 기간을 4주에서 3주로 단축하셨습니다. 이 과정에서 단순히 도구를 도입한 것을 넘어, '개발자로서 어떤 비즈니스적 고민'을 거쳐 이 프로젝트를 기획하게 되셨는지, 그리고 그 과정에서 기술적으로 가장 해결하기 어려웠던 지점은 무엇이었는지 설명해 주세요."

• 저희 팀의 비즈니스 목표는 시장 우위 점유를 위해 "2주당 1개의 신규 슬롯 출시"라는 빠른 속도를 확보하는 것이었습니다.
• 당시 백엔드 개발 공수는 약 4주가 소요되어 더 빠른 속도가 필요했고, 저는 이를 시스템적 효율화로 해결하고자 했습니다.

• 우선 슬롯 게임 로직의 반복 패턴을 확인하고 템플릿을 구성하고 데코레이터 패턴을 도입해 구조를 공통화했습니다.
• 그리고 에이전트가 슬롯 게임의 맥락을 이해하고 코드를 생성할 수 있도록 구조화된 컨텍스트 파일 체계를 수립하는 데 집중했습니다.

• 가장 어려웠던 점은 LLM의 결과물이 실제 운영 환경의 품질을 충족하는지 검증하는 것이었습니다.
• 여러 모델을 사용해보며 테스트 코드 생성 능력과 로직의 일관성을 확인했고, 에이전트가 스스로 루프를 돌며 결과물을 보정할 수 있도록 프로세스를 설계했습니다.
• 결과적으로 개발 기간을 3주로 단축했고, 개발자별 편차를 줄여 생산성을 표준화할 수 있었습니다.

Q2. "병태님은 이력서에서 'MSA 간 데이터 정합성 확보'를 위해 노력하셨다고 하셨습니다. 마이리얼트립의 주문 시스템은 결제, 쿠폰, 항공, 숙박 등 여러 마이크로서비스와 얽혀 있어 정합성이 매우 중요합니다. 본인이 경험하신 프로젝트에서 '분산 환경의 데이터 정합성'을 깨뜨릴 뻔했던 구체적인 장애 시나리오나 기술적 난관이 있었다면, 이를 어떻게 해결하셨는지 기술적으로 상세히 설명해 주세요."

• 회원과 슬롯 서버가 분리된 MSA 환경에서, 유저 경험의 핵심인 '잔액 반영'은 동기 방식으로, 상대적으로 즉시성이 덜한 '미션 처리'는 메시지 큐를 통한 비동기 방식으로 설계하여 성능과 사용자 경험을 잡고자 했습니다.

• 특히 분산 트랜잭션 이슈를 해결하기 위해 Transactional Outbox 패턴을 도입했습니다.
• Spring의 @TransactionalEventListener를 사용해 메인 비즈니스 로직이 DB에 커밋된 직후에만 이벤트를 발행하도록 했고, 만약 브로커로의 전송이 실패하더라도 DB에 저장된 Outbox 데이터를 재처리 하도록 최소 1회 전송을 보장했습니다.

• 또한, 메시지 중복 소비로 인한 중복 미션 처리를 방지하기 위해 Unique한 spinId를 기반으로 한 멱등성 검증 로직을 컨슈머 측에 구현했습니다.
• 이 구조를 통해 시스템 장애 상황에서도 데이터 정합성을 유지하며 유저들에게 신뢰성 있는 게임 환경을 제공할 수 있었습니다.

Q3. "마이리얼트립의 '주문'은 항공, 숙박, 투어 등 다양한 파트너사의 API와 연동됩니다. 만약 유저가 결제를 완료했는데, 특정 파트너사의 시스템 장애로 인해 예약 확정이 지연되거나 실패하는 상황이 발생할 수 있습니다. 병태님이 말씀하신 Outbox나 멱등성 설계 경험을 바탕으로, 이러한 '외부 의존성이 높은 결제/주문 파이프라인'에서 시스템의 안정성을 높이고 유저에게 부정적인 경험을 주지 않기 위해 어떤 아키텍처적 고려를 하시겠습니까?"

• 외부 파트너사 연동은 우리 제어권 밖의 영역이므로, 장애는 언제든지 발생할 수 있다는 전제하에 설계를 하겠습니다.

• 우선, 특정 파트너사의 장애가 마이리얼트립 전체로 전파되지 않도록 Resilience4j 같은 도구로 Circuit Breaker를 적용하겠습니다.
• 임계치 이상의 실패 발생 시 즉시 Fallback을 실행하여 시스템 자원을 보호하겠습니다.

• 기술적으로 가장 중요한 정합성은 상태 기반의 비동기 처리로 해결하겠습니다.
• 주문별로 상태를 두어, 주문 요청 시 상태를 PENDING으로 두고 외부 API를 호출합니다.
• 외부 API에 타임아웃이 발생하면 이를 단순 실패로 간주하기 않고 '상태 미확정'으로 분류합니다.
• 이후 스케줄러나 Kafka 리트라이 큐를 통해 파트너사의 예약 조회 API를 호출하여 최종적으로 확정 또는 실패 상태를 동기화 하는 상태 머신 구조를 가져가겠습니다.

Q4. "병태님은 Java/Spring 전문가이시지만, 필요에 따라 Typescript, SvelteKit 도입 등 기술 스택의 경계를 넘나들며 문제를 해결해오셨습니다. 마이리얼트립에서도 본인의 주력 스택이 아닌 기술(예: 프론트엔드 특정 라이브러리나 새로운 인프라 도구)을 사용하여 문제를 해결해야 하는 상황이 온다면, 본인만의 '빠른 학습 및 적용 노하우'는 무엇인가요?

• 저는 이제까지 새로운 기술을 마주할 때 "공식 문서에 기반한 이해"를 중요시 했습니다.
• 우선 기술 스택의 근본적인 원리를 파악하기 위해 공식 문서를 탐독하고, 이를 팀원들이 빠르게 흡수할 수 있도록 핵심 위주로 요약하여 전파하는 것을 즐깁니다.
• 최근에는 여기에 더불어 "AI를 통한 공부 효율화"를 같이 사용합니다.
• 공식 문서에서 얻은 지식과 현재 프로젝트의 아키텍처 맥락을 바탕으로 AI와 함께 새로운 설계를 해보고, 새로운 기술이 적용된 코드 초안을 짜봅니다.

• 이러한 저의 학습 방식은 마이리얼트립에서 '여행자 경험 개선'이라는 비즈니스 목표가 주어졌을 때
• 기술적 제약에 갇히지 않고 가장 적합한 도구를 즉시 도입하여 문제를 끝까지 해결하는 Product Engineer로서 강력한 무기가 될 것 입니다.

과제 면접 질문 대비

Q1. 구현하신 프로젝트에 대한 전반적인 소개와 설계를 진행하면서 내리셨던 핵심적인 기술적 의사결정(Key Design Choices) 3~4가지를 간략하게 요약해서 설명해주시겠습니까? 특히, 여러 구현 방법 중에서 **왜 현재의 방식을 선택했는지(Why)**에 초점을 맞춰 말씀해 주세요.

• 이번 과제에서 저는 '읽기 최적화'와 '시스템 결합도'에 가장 크게 집중했습니다.
• 첫 째로, 포스트 작성과 피드 업데이트를 이벤트 기반으로 분리했습니다.
  • 사용자가 글을 쓰는 시점에 수많은 팔로워의 피드를 갱신하는 작업(Fan-out)은 무겁기 떄문에,
  • 이를 비동기로 처리하여 사용자에게는 즉각적인 응답을 주고 시스템 처리량은 별도로 관리하고자 했습니다.
• 둘 째로, 이 과정에서 발생할 수 있는 데이터 유실을 막기 위해 Transactional Outbox 패턴을 적용하여,
  • 메인 비즈니스 로직과 이벤트 발행의 원자성을 보장했습니다.
  • 이를 통해 확장 가능하면서도 신뢰성 있는 소셜 피드 구조를 설계하고자 했습니다.

Q2. "방금 말씀하신 대로 이벤트를 분리하고 비동기로 처리하면 성능상 이점이 큽니다. 하지만 Transactional Outbox 패턴을 사용하면 필연적으로 'Worker(또는 Relay)'가 Outbox 테이블을 주기적으로 읽어서 메시지를 발행해야 합니다. 만약 서비스 규모가 커져서 Outbox 테이블에 데이터가 초당 수천 건씩 쌓인다면, 이를 처리하는 Worker에서 병목이 생기거나 메시지 발행 순서가 뒤섞일 수 있습니다. 병태님은 이 Outbox Worker의 성능을 어떻게 최적화하시겠습니까? 혹은 순서 보장이 중요한 소셜 서비스 특성을 고려할 때 어떤 전략을 쓰실 건가요?"

• 순서 보장이 중요한 소셜 서비스의 특성상, userId를 파티션 키로 활용하여 메시지 큐(Kafka 등)의 토픽을 파티셔닝하는 전략을 취하겠습니다.
• 이를 통해 동일 유저의 포스트 작성/수정 이벤트는 항상 같은 파티션에 순서대로 담기게 되어 데이터 정합성을 유지할 수 있습니다.

• 또한, Worker 자체의 처리량을 높이기 위해 DB 레벨에서의 작업 분할도 고려하겠습니다.
• Outbox 테이블을 읽어올 떄 각 Worker가 담당할 userId 범위를 지정하거나, SKIP LOCKED 구문을 활용해 여러 Worker가 경합 없이 병렬로 메시지를 퍼블리싱 할 수 있도록 최적화 하겠습니다.

Q3. "방금 답변에서 파티셔닝을 통해 확장성을 확보하겠다고 하셨습니다. 그런데 소셜 서비스에는 이른바 'Hot Partition' 문제가 존재합니다. 예를 들어, 특정 유명인이 포스트를 올렸을 때 그 유저의 파티션에만 수백만 건의 피드 업데이트 작업이 몰리게 되면, 해당 파티션을 담당하는 컨슈머(Consumer)만 과부하가 걸리고 다른 컨슈머들은 노는 상황이 발생할 수 있습니다. 이처럼 특정 파티션에 부하가 집중되는 현상을 방지하거나, 지연(Lag)이 발생했을 때 이를 효과적으로 처리할 수 있는 병태님만의 전략이 있을까요?"

• 슈퍼 인플루언서로 인해 발생하는 핫 파티션 문제를 해결하기 위해 Push와 Pull을 혼합한 하이브리드 전략을 사용하겠습니다.

• 팔로워 수가 일정 임계치를 넘는 유저는 '인플루언서'로 분류하여 포스트 작성 시, Fan-out을 수행하지 않습니다.
• 대신, 일반 유저가 피드를 조회하는 시점에 본인을 팔로우하는 인풀루언서들의 최신 글을 실시간으로 Pull(Fan-in) 하여 이미 생성된 비중요 유저들의 피드 데이터와 메모리상에서 병합 및 정렬하여 반환하겠습니다.

• 이 방식을 통해 시스템 전체의 쓰기 부하를 평준화할 수 있으며, 인플루언서 여부는 사용자 지표에 따라 동적으로 관리하여 변화하는 트래픽에 유연하게 대응하겠습니다.

Q4. "하이브리드 전략을 통해 효율적인 피드 구성을 설계하셨습니다. 그런데 유저가 피드를 조회할 때마다 매번 수십 명의 인플루언서 데이터를 DB에서 Pull 해오고, 이를 기존 피드와 병합/정렬하는 작업은 조회(Read) 성능에 부담을 줄 수 있습니다. 특히 마이리얼트립처럼 동시 접속자가 많은 서비스에서 '피드 조회 API의 Latency'를 낮추기 위해 어떤 캐싱(Caching) 전략을 세우시겠습니까? Redis 같은 NoSQL을 활용한다면 어떤 자료구조를 사용하여 피드를 저장하고 관리하실지 궁금합니다."

• 인플루언서의 포스트 조회 부하를 줄이기 위해 Redis 기반의 캐시 전략을 사용하겠습니다.

• 구체적으로는 포스트의 메타데이터(제목, 요약, URL 등)를 JSON 형태로 캐싱하되, 효율적인 정렬 조회를 위해 Redis의 Sorted Set (ZSET) 자료구조를 병행하겠습니다.
• 포스트의 ID를 Value로, 생성 시간을 Score로 저장하면, 유저가 피드를 조회할 떄 최신순으로 필요한 구간만 빠르게 슬라이싱하여 가져올 수 있습니다.

• 또한, 포스트 수정이나 삭제 시에는 이전에 구현했던 이벤트 기반 아키텍처를 활용하여 Redis 캐시를 즉시 갱신함으로써, 유저가 항상 최신 피드를 볼 수 있도록 데이터 일관성을 유지하겠습니다.

Q5. 병태님은 NHN에서 테스트 커버리지를 4%에서 51%까지 끌어올려 안정성을 확보한 경험이 있으십니다. 이번 소셜 피드 과제에서도 '피드 생성 로직'은 매우 복잡하고 실패 시 유저 경험에 치명적입니다. 이 과제 결과물에서 가장 중요하게 테스트해야 한다고 생각하는 핵심 시나리오 하나를 꼽아주시고, 비동기 이벤트 기반으로 동작하는 이 시스템을 **어떻게 하면 신뢰성 있게 검증(Test)**할 수 있을지 본인만의 노하우를 말씀해 주세요."

• 이벤트 기반 시스템의 신뢰성을 위해 컴포넌트 단위 검증에서 엔트투엔드(E2E) 성능 검증으로 확장하는 전략을 취하겠습니다.

• 우선 포스트 작성 시 Outbox에 정확히 기록되는지, 그리고 워커가 이를 읽어 발행하는지 등의 개별 로직을 단위 테스트로 검증하겠습니다.
• 특히 비동기 흐름의 통합 테스트에서는 Awaitility를 활용하여 이벤트가 소비되고 최종적으로 피드가 반영되는 시점까지의 흐름이 비즈니스 타임아웃 내에 완료되는지 확인하겠습니다.

• 마지막으로 k6를 활용한 부하 테스트를 통해, 팔로워가 많은 유저의 포스트를 발행할 떄 시스템의 전반의 지연(Lag)을 측정하겠습니다.
• 이를 통해, 어떤 상황에서도 피드 발행, 조회 응답 속도가 일정 수준 이하로 유지됨을 보장하는 신뢰성 있는 시스템을 만들겠습니다.