Meituan 면접 질문

Meituan 면접의 초점

일반적인 Meituan 면접 질문

• 배달 지점 목록(위도/경도)과 시작 위치가 주어졌을 때, 모든 지점을 방문하고 돌아오는 최단 경로를 찾으세요.
  좋은 답변이 다루는 것

  • TSP 문제는 NP-hard이므로, 입력 크기가 작을 때는 DP + 비트마스크를 사용하여 정확해를 구함
  • 큰 입력에 대해서는 최근접 이웃(Nearest Neighbor)이나 유전 알고리즘 같은 휴리스틱을 고려
  • DP 접근법: dp[mask][last] = mask에 포함된 도시를 last에서 끝나도록 방문한 최소 거리
  • 초기화: 시작점을 0번으로 가정, dp[1][0] = 0, 나머지 INF
  • 최종 답: 모든 점 방문 후 시작점으로 돌아오는 거리 min(dp[(1<<n)-1][i] + dist[i][0])

  샘플 답변 보기

  이 문제는 전형적인 외판원 문제(TSP)로, 모든 배달 지점을 정확히 한 번씩 방문하고 시작점으로 돌아오는 최단 경로를 찾는 것입니다. 입력 크기가 작다면(보통 n≤20) DP와 비트마스크를 이용해 O(n^2·2^n) 시간에 정확해를 구할 수 있습니다. 하지만 n이 크면 패널티가 커지므로, 실무에서는 최근접 이웃, 2-opt, 유전 알고리즘 같은 근사해법을 사용합니다. 또한 Meituan 같은 배달 시스템에서는 경로가 동적으로 변경될 수 있으므로, 온라인 알고리즘이나 실시간 재계산 전략도 고려해야 합니다. 여기서는 작은 n에 대해 DP로 구현하겠습니다. DP 배열은 dp[mask][i]로, mask는 방문한 도시 집합, i는 마지막 방문 도시를 뜻합니다. 시작 도시는 0번으로 고정하고, 모든 마스크를 순회하며 점화식을 적용합니다. 최종적으로 모든 도시를 방문한 상태에서 시작점으로 돌아오는 거리의 최솟값을 반환합니다.

  import sys
  import math
  
  def solve_tsp(dist):
      n = len(dist)
      INF = 10**9
      dp = [[INF]*n for _ in range(1<<n)]
      dp[1][0] = 0  # 시작점 0, mask=1
  
      for mask in range(1<<n):
          for last in range(n):
              if dp[mask][last] == INF:
                  continue
              # 다음 방문할 도시 선택
              for nxt in range(n):
                  if mask & (1<<nxt) == 0:
                      new_mask = mask | (1<<nxt)
                      new_dist = dp[mask][last] + dist[last][nxt]
                      if new_dist < dp[new_mask][nxt]:
                          dp[new_mask][nxt] = new_dist
  
      # 모든 도시 방문 후 시작점으로 복귀
      full_mask = (1<<n)-1
      answer = INF
      for last in range(n):
          if dp[full_mask][last] + dist[last][0] < answer:
              answer = dp[full_mask][last] + dist[last][0]
      return answer
  
  # 예시: 위도/경도 좌표로 거리 계산
  # dist[i][j] = haversine(lat,lon) 등
  # n <= 20 적합
  # 시간 복잡도: O(n^2 * 2^n), 공간 복잡도: O(n * 2^n)

• 수백만 사용자를 위한 실시간 주문 추적 시스템을 설계하세요. 지연 시간, 일관성, 내결함성을 고려하세요.
  좋은 답변이 다루는 것

  • 시스템은 고가용성과 낮은 지연 시간을 위해 마이크로서비스 아키텍처 채택
  • 주문 데이터는 시간 순서가 중요하므로 Kafka 같은 메시지 큐로 이벤트 수집
  • 실시간 조회를 위해 Redis 같은 인메모리 데이터스토어에 현재 상태 캐싱, 이력은 Cassandra에 저장
  • 내결함성을 위해 각 서비스는 여러 복제본으로 운영되고, 주문 상태는 영구 저장소에 커밋 로그로 보존
  • 지연 시간 최소화를 위해 사용자 위치 기반으로 가까운 지역의 서버에 라우팅

  샘플 답변 보기

  실시간 주문 추적 시스템은 수백만 사용자의 주문 상태 변경을 초 단위로 반영해야 하므로, 높은 처리량과 낮은 지연 시간이 핵심입니다. 우선 마이크로서비스 아키텍처를 채택하여 주문 서비스, 배달원 서비스, 위치 서비스, 알림 서비스 등으로 분리합니다. 각 서비스는 독립적으로 확장 가능합니다. 실시간 이벤트는 Kafka를 통해 수집되고, 각 서비스는 필요한 이벤트를 구독합니다. 현재 주문 상태(예: 배달 중, 완료)는 Redis에 캐싱하여 빠른 읽기를 지원하고, 전체 이력은 Cassandra에 저장하여 내구성을 확보합니다. 내결함성을 위해 각 서비스는 최소 3개의 복제본을 두고, 주문 생성 시에는 영구 로그에 기록하여 장애 시 복구가 가능하게 합니다. 지리적으로 분산된 데이터 센터를 두고, 사용자 위치와 배달원 위치를 고려하여 가장 가까운 지역의 서버로 요청을 라우팅함으로써 지연 시간을 줄입니다. 또한 주문 상태 업데이트는 멱등성을 보장하여 중복 메시지에도 일관성이 유지되도록 합니다. 부하가 급증할 때는 자동 스케일링으로 대응하며, 특히 플래시 세일 같은 이벤트를 대비해 사전 용량을 확보합니다.

• get 및 put 작업을 평균 O(1) 시간에 지원하는 LRU 제거 정책을 가진 캐시를 구현하세요.
  좋은 답변이 다루는 것

  • LRU 캐시는 해시 테이블과 이중 연결 리스트를 결합하여 구현
  • 해시 테이블은 키-노드 매핑을 제공하여 O(1) 접근, 리스트는 노드 순서로 LRU 순서 관리
  • get: 키가 있으면 해당 노드를 리스트 맨 앞으로 이동 후 값 반환, 없으면 -1
  • put: 키가 있으면 값을 업데이트하고 노드를 맨 앞으로, 없으면 새 노드 생성 후 리스트 앞에 추가, 용량 초과 시 리스트 꼬리 노드 제거
  • 더미 헤드와 테일을 사용하여 경계 조건 처리 단순화

  샘플 답변 보기

  LRU 캐시는 가장 오래전에 사용된 항목을 제거하는 정책을 가진 캐시입니다. get과 put을 모두 O(1) 평균 시간에 지원하기 위해 해시 테이블과 이중 연결 리스트를 함께 사용합니다. 해시 테이블은 키를 리스트 노드에 매핑하여 빠른 조회를 가능하게 합니다. 리스트는 최근 사용 순서를 유지하며, 가장 최근에 사용된 노드는 헤드에 가깝고, 가장 오래된 노드는 테일에 위치합니다. get을 할 때는 해시 테이블에서 노드를 찾고, 존재하면 리스트에서 그 노드를 분리하여 헤드로 이동시킵니다. put에서는 키가 이미 있으면 값을 업데이트하고 노드를 헤드로 이동시키며, 없으면 새 노드를 만들어 헤드에 추가합니다. 캐시 용량을 초과하면 테일 노드를 제거하고 해시 테이블에서도 삭제합니다. 이중 연결 리스트를 사용함으로써 노드의 삽입과 삭제가 O(1)에 가능합니다. 구현 시 더미 헤드와 테일 노드를 두어 포인터 조작을 단순화할 수 있습니다.

  class DLinkedNode:
      def __init__(self, key=0, value=0):
          self.key = key
          self.value = value
          self.prev = None
          self.next = None
  
  class LRUCache:
      def __init__(self, capacity: int):
          self.capacity = capacity
          self.size = 0
          self.cache = {}  # key -> node
          # 더미 헤드와 테일
          self.head = DLinkedNode()
          self.tail = DLinkedNode()
          self.head.next = self.tail
          self.tail.prev = self.head
  
      def _add_node(self, node):
          # 노드를 헤드 바로 다음에 추가
          node.prev = self.head
          node.next = self.head.next
          self.head.next.prev = node
          self.head.next = node
  
      def _remove_node(self, node):
          # 리스트에서 노드 제거
          prev = node.prev
          nxt = node.next
          prev.next = nxt
          nxt.prev = prev
  
      def _move_to_head(self, node):
          # 노드를 꺼내서 헤드로 이동
          self._remove_node(node)
          self._add_node(node)
  
      def _pop_tail(self):
          # 테일 노드 반환 및 제거
          res = self.tail.prev
          self._remove_node(res)
          return res
  
      def get(self, key: int) -> int:
          node = self.cache.get(key)
          if not node:
              return -1
          self._move_to_head(node)
          return node.value
  
      def put(self, key: int, value: int) -> None:
          node = self.cache.get(key)
          if node:
              node.value = value
              self._move_to_head(node)
          else:
              new_node = DLinkedNode(key, value)
              self.cache[key] = new_node
              self._add_node(new_node)
              self.size += 1
              if self.size > self.capacity:
                  # 테일 노드 제거
                  tail = self._pop_tail()
                  del self.cache[tail.key]
                  self.size -= 1
  
  # 시간 복잡도: get, put O(1) 평균
  # 공간 복잡도: O(capacity)

• Meituan의 음식 배달 추천 시스템을 개선하는 책임이 있습니다. 다양성을 보장하면서 어떻게 개인화된 추천을 하시겠습니까?
  좋은 답변이 다루는 것

  • 개인화를 위해 사용자 과거 주문 이력, 검색 기록, 위치, 시간대 등 다양한 특징을 활용한 협업 필터링 및 딥러닝 모델 사용
  • 다양성 보장을 위해 추천 결과에 MMR(Maximal Marginal Relevance)이나 DPP(Determinantal Point Process) 적용
  • 비즈니스 규칙으로 카테고리별 최소 개수, 새로운 음식점 노출 보장 등을 추가
  • A/B 테스트를 통해 개인화와 다양성의 균형을 지속적으로 최적화
  • 콜드 스타트 문제는 인기 기반 추천과 지식 기반 추천을 혼합하여 해결

  샘플 답변 보기

  음식 배달 추천 시스템에서 개인화는 사용자 만족도를 높이는 핵심이지만, 지나치게 편중된 추천은 사용자가 선택의 폭이 좁다고 느끼게 합니다. 따라서 다양성과 개인화의 균형이 중요합니다. 먼저 개인화를 위해 사용자의 과거 주문, 검색, 클릭, 리뷰 데이터를 기반으로 한 협업 필터링 모델과 딥러닝 기반의 시퀀스 모델(예: GRU4Rec)을 사용합니다. 또한 시간대, 위치, 날씨 같은 컨텍스트 정보도 추가합니다. 다양성을 보장하기 위해 MMR(Maximal Marginal Relevance) 기법을 적용하여 추천 리스트에서 이미 선택된 아이템과 유사한 아이템은 패널티를 주고, 새로운 아이템을 우선시합니다. 또는 DPP(Determinantal Point Process)를 사용해 아이템 간의 다양성을 수학적으로 최적화할 수 있습니다. 비즈니스 규칙으로 각 카테고리(한식, 중식 등)에서 최소 하나씩 포함시키고, 일정 기간 동안 노출되지 않은 새로운 음식점을 반드시 포함시키도록 합니다. 이러한 접근은 A/B 테스트를 통해 개인화 점수와 다양성 점수를 모니터링하며 점진적으로 개선합니다. 콜드 스타트 사용자에게는 인기 순위와 사용자의 위치, 선호 음식 종류를 기반으로 한 규칙 기반 추천을 제공합니다.

• 속도와 품질 사이에서 트레이드오프를 해야 했던 경험에 대해 말씀해 주세요. 어떻게 결정했고 결과는 어땠습니까?
  좋은 답변이 다루는 것

  • 상황: 대규모 데이터 마이그레이션 프로젝트에서 빠른 전환(속도)을 요구받았지만, 데이터 정합성 검증(품질)이 부족했음
  • 결정: 먼저 전환 속도를 늦추고 자동화된 검증 파이프라인을 구축한 후, 단계적으로 마이그레이션 진행
  • 결과: 초기 지연이 있었지만, 전환 후 데이터 오류가 거의 없었고, 오히려 전체 프로젝트 일정을 단축할 수 있었음
  • 배운 점: 초기에 품질을 희생하면 나중에 더 큰 비용이 발생할 수 있으므로, 균형을 맞추는 것이 중요
  • 실제로 속도를 높이기 위해 검증 자동화와 병렬 처리를 도입하여 품질을 유지하면서 속도도 개선

  샘플 답변 보기

  제가 속도와 품질 사이에서 트레이드오프를 경험한 사례는 대규모 레거시 시스템에서 새로운 마이크로서비스로 데이터를 마이그레이션하는 프로젝트였습니다. 경영진은 빠른 전환을 원했지만, 저는 데이터 정합성 검증이 부족하면 서비스 장애로 이어질 수 있다고 판단했습니다. 따라서 저는 먼저 자동화된 데이터 검증 파이프라인을 구축할 것을 제안했고, 초기에는 전환 속도를 늦추더라도 품질을 우선시하기로 결정했습니다. 구체적으로, 마이그레이션을 여러 단계로 나누고 각 단계마다 원본과 대상 데이터의 무결성을 비교하는 스크립트를 실행했습니다. 그 결과, 초기에는 전환 속도가 느렸지만, 대규모 데이터 오류를 사전에 발견하여 수정할 수 있었습니다. 이후 검증 파이프라인이 안정화되자 병렬 처리를 도입하여 속도를 높였고, 결국 전체 프로젝트가 원래 예상보다 일찍 완료되었습니다. 이 경험을 통해 품질을 먼저 확보한 후 속도를 높이는 것이 장기적으로 더 효율적임을 배웠습니다. 만약 처음부터 속도만 강조했다면, 데이터 문제를 해결하는 데 더 많은 시간이 소요되었을 것입니다.

• 플래시 세일 중에도 다운되지 않는 확장 가능한 쿠폰/할인 시스템을 어떻게 설계하시겠습니까?
  좋은 답변이 다루는 것

  • 플래시 세일은 트래픽이 집중되므로, 요청을 큐잉하고 처리율 제한을 적용하여 시스템 보호
  • 쿠폰 재고는 Redis의 원자적 연산(decr)으로 관리하여 동시성 제어
  • 데이터베이스는 최종 일관성을 허용하고, 쿠폰 발행 내역은 비동기로 기록
  • 아키텍처는 비동기 이벤트 기반으로 설계하여 처리량을 높이고, Redis Cluster로 샤딩
  • 정전이나 장애 대비를 위해 쿠폰 발행 전에 예약 로직을 두고, 실패 시 롤백

  샘플 답변 보기

  플래시 세일 중에도 쿠폰/할인 시스템이 다운되지 않으려면, 대규모 동시 요청을 처리할 수 있도록 설계해야 합니다. 우선, 모든 쿠폰 발행 요청은 API 게이트웨이에서 처리율 제한(rate limiting)을 적용하여 초당 최대 요청 수를 제한합니다. 그 다음, 요청은 Redis 큐에 저장되고, 워커가 순차적으로 처리합니다. 쿠폰 재고는 Redis의 단일 키에 저장하고, INCR/DECR 명령어를 원자적으로 사용하여 동시성 문제를 해결합니다. 재고가 소진되면 이후 요청은 즉시 실패 응답을 반환합니다. 데이터베이스는 초당 쓰기 부하를 견디기 힘들기 때문에, 쿠폰 발행 내역을 비동기 배치로 기록합니다. 예를 들어, Redis 리스트에 발행 로그를 쌓고, 일정 시간마다 또는 일정 개수마다 DB에 일괄 삽입합니다. 또한, 시스템 장애에 대비하여 쿠폰 발행 전에 '예약' 단계를 두고, 예약 성공 시에만 실제 발행을 진행합니다. 만약 예약 후 발행이 실패하면 일정 시간 후 재고를 복구하는 롤백 프로세스를 둡니다. 전체 아키텍처는 Redis Cluster를 사용하여 키를 샤딩하고, 각 샤드는 여러 복제본을 두어 고가용성을 보장합니다. 이렇게 하면 플래시 세일의 피크 트래픽도 안정적으로 처리할 수 있습니다.

• 관리자와 기술 방향에 대해 의견이 달랐던 상황을 설명하세요. 어떻게 처리했습니까?
  좋은 답변이 다루는 것

  • 상황: 관리자가 기존 모놀리식 아키텍처를 유지하자고 주장했지만, 저는 마이크로서비스 전환이 필요하다고 생각함
  • 처리: 관리자의 우려(복잡성 증가, 운영 부담)를 이해하고, 작은 모듈부터 점진적으로 전환하는 방안 제시
  • 구체적 실행: 영향이 적은 사용자 인증 모듈을 먼저 분리하여 마이크로서비스로 전환하고, 모니터링 대시보드 구축
  • 결과: 성공적인 전환으로 관리자의 신뢰를 얻고, 이후 주요 기능도 마이크로서비스로 전환
  • 배운 점: 기술적 논쟁보다는 데이터와 작은 성공 사례로 설득하는 것이 효과적

  샘플 답변 보기

  이전 회사에서 마이크로서비스 아키텍처 전환을 추진할 때, 관리자는 현재 모놀리식 시스템이 잘 동작하고 있다며 반대했습니다. 관리자의 주된 우려는 마이크로서비스 도입으로 인한 운영 복잡성과 초기 개발 비용 증가였습니다. 저는 관리자의 의견을 존중하면서도, 장기적인 확장성과 유지보수성을 위해 변화가 필요하다고 생각했습니다. 그래서 저는 전체 시스템을 한 번에 전환하는 대신, 가장 독립적이고 영향이 적은 사용자 인증 모듈을 먼저 분리하여 마이크로서비스로 전환하는 파일럿 프로젝트를 제안했습니다. 또한, 전환 후 성능과 장애 지표를 실시간으로 모니터링할 수 있는 대시보드를 구축하여 관리자에게 가시성을 제공했습니다. 파일럿 프로젝트가 성공적으로 완료되자, 관리자는 마이크로서비스의 이점을 인정하고 이후 주요 기능들도 점진적으로 전환하는 데 동의했습니다. 이 경험을 통해 기술적 논쟁보다는 작은 성공 사례와 데이터를 바탕으로 설득하는 것이 효과적임을 깨달았습니다. 또한, 관리자의 우려를 경청하고 함께 해결책을 모색하는 것이 중요하다고 배웠습니다.

• 대규모 사용자 리뷰 데이터 세트가 주어졌을 때, 실시간으로 가짜 리뷰를 탐지하고 필터링하는 시스템을 설계하세요.
  좋은 답변이 다루는 것

  • 가짜 리뷰 탐지는 텍스트 분석, 사용자 행동 패턴, 네트워크 분석을 결합한 하이브리드 접근법 사용
  • 실시간 처리를 위해 스트리밍 플랫폼(Kafka)으로 리뷰를 수집하고, 특징 추출 후 머신러닝 모델로 분류
  • 모델은 지도 학습(이상 탐지)과 비지도 학습(클러스터링)을 혼합하여 새로운 패턴에도 대응
  • 의심 리뷰는 바로 차단하지 않고 추가 검증을 위해 큐에 넣거나, 사용자 신뢰도 점수를 낮춤
  • 낮은 정확도로 인한 오탐을 줄이기 위해 앙상블 모델과 휴먼 인더 루프(Human-in-the-Loop) 도입

  샘플 답변 보기

  가짜 리뷰 탐지 시스템은 실시간으로 엄청난 양의 리뷰를 처리해야 하므로, 스트리밍 기반 아키텍처가 필요합니다. 먼저, 모든 리뷰는 Kafka 토픽으로 들어오고, 스트림 프로세서(예: Apache Flink)가 특징을 추출합니다. 특징으로는 리뷰 텍스트의 언어적 패턴(예: 반복 단어, 과장된 표현), 사용자 행동(리뷰 작성 빈도, IP 주소, 평점 분포), 그리고 리뷰어 간의 소셜 네트워크(같은 IP에서 여러 계정) 등을 사용합니다. 이 특징들을 미리 학습된 머신러닝 모델(예: XGBoost, LSTM)에 입력하여 가짜 리뷰 점수를 계산합니다. 모델은 지도 학습으로 기존에 알려진 가짜 리뷰를 학습하고, 비지도 학습으로 새로운 이상 패턴을 탐지합니다. 점수가 임계값을 넘으면 해당 리뷰는 '의심'으로 표시되고, 사용자에게 즉시 노출되지 않도록 필터링됩니다. 단, 오탐을 줄이기 위해 점수가 중간 정도인 리뷰는 추가 검증을 위해 큐에 넣고, 일정 시간 내에 사람이 검토하는 Human-in-the-Loop 방식을 적용합니다. 또한, 전체 시스템은 주기적으로 피드백을 받아 모델을 재학습시킵니다. 확장성을 위해 각 처리 단계는 수평 확장이 가능하며, Redis에 사용자 신뢰도 점수를 캐싱하여 빠른 조회를 지원합니다.

준비 팁

• 그래프 순회(다익스트라, A*)와 동적 프로그래밍에 중점을 둔 LeetCode 어려운 문제를 연습하세요. Meituan은 배달/물류 시나리오를 자주 사용합니다.
• 시스템 설계의 경우 승차 공유 또는 음식 배달 앱의 고규모 아키텍처를 공부하세요. 일관성, 가용성, 지연 시간 간의 트레이드오프를 논의할 준비를 하세요.
• 행동 답변을 Meituan의 핵심 가치(고객 우선, 장기적 영향 집중, 반복적 개선 수용)와 일치시키세요. 경험에서 구체적인 예를 사용하세요.
• 비즈니스 지표에 대해 논의할 준비를 하세요: 엔지니어링 결정이 전환율, 배달 시간, 사용자 유지에 어떻게 영향을 미치는지 이해하세요. 답변에 숫자와 KPI를 사용하세요.
• 타이머를 사용한 모의 면접: Meituan 면접은 빠르게 진행됩니다. 특히 코딩과 설계에서 시간 압박 아래에서 생각을 말하는 연습을 하세요.

자주 묻는 질문