서문
내가 구현하는 제품은 항상 최선의 결과이다.
단, 내가 아는 한에서.
그렇다.
내가 아는 범위에서는 내가 만드는 모든 제품은 내 최선의 제품이다.
하지만 그러면 내 우물에 갇히는 꼴이다.
그래서 컨퍼런스를 계속 정리해갈 예정!
토스
토스ㅣSLASH 24 - 기반 데이터가 부족해도 OK! 커머스 추천 시스템 제작기
-
문제상황
토스 공동 구매 서비스를 시작한 뒤, 추천 시스템을 만들어야하는데 고객의 유의미한 피드백이 담긴 데이터가 부족했음
첫 추천시스템은 콜드스타트 해소, 서비스 변화 대응, 빠른 실험/개선, 장기적 피드백 확보라는 네 가지 요구사항을 만족해야했음. -
첫 추천모델
첫 추천 모델로 MAB 모델을 사용함. 고객을 연령/성별 등으로 코호트 분류 후 멀티 암드 밴딧 알고리즘을 통해 각 코호트별로 추천 상품을 노출하고 피드백(클릭/결제 등)을 반영.
보다 정교한 개인화 추천을 위해 유저 임베딩 모델을 학습하고, 이를 기반으로 다시 코호트를 세분화했음. -
유저 임베딩 모델
투타워(tow-tower) 구조를 사용하여 학습 효율과 확장성을 확보했음.
유저 측에는 클릭/결제 등 행동 데이터, 아이템 측에는 메타데이터와 텍스트/이미지 임베딩 등을 결합하여 학습했음.
포지티브/네거티브 샘플을 뽑을 때 믹스 랜덤 샘플링 기법을 도입하여 특정 상품에 대한 편향을 줄였음. -
서빙 구조(머신러닝 엔지니어링) - 배치, 리얼타임 인퍼런스
Spark, Airflow 등으로 일정 주기에 맞춰 대용량 데이터를 학습/처리한 후, 코호트별 추천 결과를 저장소에 배치 형태로 적재하였음.
사용자가 접속하면, 어떤 코호트인지 확인해 미리 준비해둔 추천 결과를 꺼내줌(빠른 응답)
다만 코호트 단위의 추천이여서 완전 개인화는 X
사용자 접속 시점에 사용자의 최신 행동 데이터를 즉시 피처 스토어에서 불러와, Onnx Runtime으로 모델 추론을 진행하고 스코어를 계산함. -
결과 및 의의
위 과정을 통해 콜드스타트 문제를 완화하면서도 빠른 속도의 추천 서비스를 구현하였음.
배치와 리얼타임 인퍼런스를 혼합해, 대규모 트래픽을 커버하면서도 개인화 수준을 높였음.
실제 A/B 테스트에서 CTR/CVR 등 주요 지표가 유의미하게 개선되었다.
토스ㅣSLASH 24 - 리플레이 검증으로 새로운 금융 시스템 안전하게 도입하기
-
토스증권 원장 차세대 프로젝트
기존 원장(레거시 시스템)을 코틀린 기반 MSA 원장으로 전환하는 대규모 프로젝트를 진행.
API 스펙, DB 스키마, 주요 로직을 최대한 동일하게 ㄷ유지해 기존 서버가 새 원장을 자연스럽게 사용하도록 유도.
기능마다 직접 테스트 코드를 작성하기에는 인력이 부족하고, 통합 테스트 준비에도 비용이 많이 들기에 테스트를 자동화 하기로 결정. -
Read Verifier
게이트웨이 서버를 거치는 모든 요청/응답을 카프카로 발행하여 새로운 원장에 동일 요청을 보내 응답을 비교하였음.
조회 API이므로 트랜잭션이 복잡하지 않아 비동기 방식으로 구현 가능하였음.
ADMIN 화면을 통해 API별 Verifier 사용 여부, 트래픽 비율 등을 실시간 조정해 운영 환경에서도 안전하고 정확하게 검증하였음.
주기적 리포트로 실제 환경에서 발생하는 다양한 케이스를 빠르게 포착하고 수정하였음. -
Write Verifier
요청을 기존 원장에 보내기 전, 차세대 원장에서 먼저 처리하였고 처리 과정에서 발생한 쿼리를 모니터링(p6spy,antlr로 파싱).
커밋 대신 트랜잭션 롤백을 사용하여 DB를 원상태로 복구하고, 처리 결과를 Redis에 임시 저장.
이후 기존 원장의 실제 처리 결과(DB 상태)와 차세대 원장이 예상했던 결과를 비교함.
DB를 복제하지 않고 단일 DB에서 트랜잭션 롤백 방식을 택해, 1,000개 이상의 테이블을 관리해야 하는 부담을 줄였음.
사용자에게 영향이 없도록 개발 환경에서만 사용했고, 프로젝트 소스 코드에 변경이 없도록 라이브러리 형태로 제공했음.
데이터 변동 결과를 실시간 리포트로 확인하여, 높은 안정성과 QA 효율을 가져감. -
토스뱅크 대출 서비스: 10년 후 시점까지 검증
토스뱅크 대출은 최대 10년까지 유지될 수 있는 장기 서비스임.
상품 약정 시, 기준금리 변동 등 앞으로 수년간 정기적으로 일어날 이벤트에 대한 처리를 정확하게 보장해야함.
단순 종단간 테스트나 DB날짜 조정 방식만으로는 미래 시점을 검증하기 어려움 -
미래로 직접 가보기
대출 시스템이 모놀리식이라 한 번의 설정으로 전체 로직(실시간 거래, 배치 등)을 일관되게 테스트 가능.
독립된 테스트 환경(쿠버네티스 파드 & 독립 DB)을 만들어, 시간 관련 로직을 원하는 시점(ex.2034년)으로 바꿔서 실행.
실시간 거래와 배치 거래를 실제 운영 순서 그대로 반복 실행 후 결과를 DB로 검증
시간을 변경할 때는 프레임워크 레벨에서 자바 Calendar 대신 Redis 등에서 관리하는 시뮬레이션 시점을 가져다 쓰도록 수정함. -
예시: 기준금리 변경 검증
- 테스트용 파드 & DB를 새로 복제/할당
- 시뮬레이션 시작일(2024년 1월 1일)로 시간 설정 후 대출 실행.
- 기준금리 변동일까지 시간을 이동(2024년 4월 1일)
- 변동된 기준금리와 가상금리가 정상적으로 적용됐는지 DB 쿼리 결과로 확인.
- 이 과정을 수 차례 반복하여 가상금리는 변동 없고 기준금리는 주기대로 반영되는지 장기적 시나리오를 미리 검증.
- 결과 및 의의
장기적으로 유지되어야 하거나 대규모 전환이 필요한 시스템에서, 실제 운영 트래픽 혹은 장기 시나리오를 자동으로 재연/검증함으로써, QA 효율과 서비스 안정성을 동시에 확보한 구체적인 방안을 보여줌.
카카오
네이버
배민
당근
쿠팡
