2025-08-13

1일 1아티클

토스 테크

Mock Server

상황

  • 서비스 내에서, 토스 서버와 파트너사의 서버 간 정보 교환이 필요
  • 서비스 개발 과정에서 문제 발생
    1. 파트너사 테스트 서버의 불안정
    2. 원하는 데이터 부족
    3. 다양한 시나리오 테스트 부족 → 개발, 풀질 검증(QA) 효율 감소

요구사항

  1. 기능적 요구사항
    • 유저, 제휴사, 퍼널(partner) 단위로 mock 사용 여부 설정
    • 동기 / 비동기 응답 방식 모두 지원
    • relay 서버 역할 수행
    • 유저가 쉽게 설정할 수 있어야 함
  2. 비기능적 요구사항
    • 기존 비즈니스 로직 변경 X
    • mock 서버에서 로직을 처리하기 위해 필요한 값은 커스텀 헤더로 전달
    • 토스 내 타 서비스에서도 mock 서버 연동이 쉽도록 유연한 구조 제공

설계 및 구현방법

  1. 커스텀 헤더 주입
    • 비즈니스 로직에 영향 X
    • 테스트의 유연한 제어 가능

      @Profile("dev") : 테스트 환경에서만 동작
      RestTemplate : header 추가
      WebClient : filter 추가

  2. 설정
    • DB 테이블에서 모든 설정값을 관리 → 유연성 확보

      제휴사 메타데이터, 퍼널별 mock 응답 데이터, 유저별 mock 응답 사용 여부 및 응답 지연 설정 정의하여 DB 테이블로 관리

  3. 예약(비동기 응답 지원)
    • 실제 제휴사처럼 콜백 응답을 지연하여 전송하는 기능

      With. @Scheduled

  4. mock 데이터 생성
    • 실제 제휴사 응답과 동일한 포맷으로 생성

      예약어 기반 mock 템플릿 정의, 예약어를 실제 원장 데이터로 치환, 매핑 처리

  5. Relay 서버 역할
    • mock 서버가 2가지 상황에 대한 relay 서버 역할을 수행해야 함

      유저가 mock 응답을 사용하지 않는 경우 : 직접 제휴사 호출하여 응답 relay
      제휴사에서 콜백 API를 호출 : api gateway의 routing rule을 실제 서버에서 mock 서버로 수정, mock 서버에서 콜백 API를 받고 나서 실제 서버 호출

  6. 메신저봇 연동
    • 팀원들이 mock 데이터 사용을 쉽게 하기 위한 작업

      팀내 메신저봇에 mock 서버 설정 및 설정 확인 기능 추가

  7. 유연한 연동 구조 제공
    • 토스 내 다양한 제휴사 연동 서비스들이 쉽게 통합 및 활용 가능하도록, 확장 가능하고 유연한 아키텍처 제공
    • 서비스 모듈마다 별도의 DataSource 사용하는 경우 고려

      모듈 구조 : 서비스별로 쉽게 연동할 수 있도록 모듈화된 설계 → 각 서비스에서는 전용 모듈만 추가하면 mock 서버 사용 가능
      class 기반 정의 방식으로 Multi DataSource 지원
      모듈별로 분리된 프로퍼티 설정 : 각 서비스마다 설정이 구분될 수 있도록 정의, 최종 프로퍼티 파일에서 각 서비스의 설정 파일을 import하여 모든 프로퍼티 통합 로딩

Relay Server : 클라이언트와 서버 사이에서 데이터를 전달하는 중개자 역할 (ex. SMTP, TURN, etc.)
Web Server : 클라이언트로부터 Request를 받아, 그에 맞는 정적 콘텐츠 Response로 제공 (Relay Server의 역할도 수행 가능)
relay-server-web-server

오늘 배운 것

  1. 백트래킹

내일 할 일

  1. 알고리즘 공부

참고자료

results matching ""

    No results matching ""