toss slash 24 참여 후기

지인 중 toss slash 24의 연사자가 계셨고, 감사히도 초청권을 주셔서 다녀오게 되었습니다. 우리나라의 금융 서비스 혁신을 선도하고 있는 toss 에서는 어떤 개발 과제들을 안고 있고 어떻게 해결해나가고 있는지 알아볼 수 있는 좋은 시간이었습니다. 올 해 표어(?)는 no limit이었는데요, 이에 맞게 각 세션에서 겪었던 어려움과 이를 극복해 나가는 과정을 소개하는 느낌을 받았습니다.

참석했던 세션 중 몇 가지를 정리해보도록 하겠습니다.

[Data] 기반 데이터가 부족해도 OK! 커머스 추천 시스템 제작기

토스 쇼핑 서비스의 추천 시스템 개발에 관련된 이야기입니다. 해당 시스템 개발 시, 서비스를 시작하여 데이터는 부족하나 고객에게 추천은 제공해야 하는 상황이었던 상황을 공유하며 해당 세션의 배경을 설명하였습니다.

당시 고려해야했던 것들은 빠르게 증가하는 고객 수 늘어나는 신규 상품들 잦은 서비스 변경 등이 있었고, 당시 데이터와 개발 기간이 부족한 상황이라 다음의 목표를 설정했다고 합니다.

cold-start 문제 완화
변화에 유연하게 대처
빠른 모델 적용
피드백 데이터 확보

Multi Armed Bandit적용

Multi Armed Bandit(MAB)란 기대 수익률을 알 수 없는 슬롯머신들을 동작시킬 때, 최적의 수익을 얻기 위해 탐색과 활용을 이용한 강화학습 알고리즘이라고 합니다.

토스 쇼핑에서는 유저 맞춤형 추천 및 새로운 취향을 확인하여 점점 더 유저의 구매를 유도할 수 있는 아이템을 제공하기 위한 목적이라고 생각됩니다.

처음에는 batch 성으로 톰슨 샘플링을 이용하여 간단하게 개인화를 했다고 합니다. 다만 이용자 수가 많아짐에 따라 속도가 느려지고 저장해야 하는 데이터가 많아졌고, 또한 기존 방식에서 구매 전환률은 고려되었으나 노출 규모가 고려되지 못했다고 합니다. (노출 규모가 크면 구매 전환률이 떨어질 수 밖에 없음) 따라서 lower confidence bound 를 통해 노출 규모를 고려하여 점수를 매겼다고 합니다. k means 로 cohort를 나누고 warm starter(데이터가 있는 사용자를 위한 첫 추천)를 위해 유저를 다시 쪼개고 학습하기를 반복했다고 합니다.

서빙 아키텍처

이용자 수가 많은 상황에서 빠른 반응성을 한정된 자원에서 제공해주어야 했다고 합니다. (많은 서비스가 고려하는 상황이 아닐까 합니다 ㅎㅎ)

이를 위해 추론을 두 가지 방식으로 제공했다고 합니다.

배치성 추론

하둡, spark 를 통해 학습 후 redis, phoenix에 저장해 실제로 서빙은 spring boot 을 이용했다고 합니다. 이 방식은 cohort별 추천을 제공하며, 빠른 응답시간과 안정성을 보장해줍니다.

실시간 추론

마찬가지로 하둡, spark를 통해 학습 후, mlflow에 모델을, toss의 feature store라는 곳에 feature를 저장하여 실시간으로 추론할 수 있도록 했습니다. 이 방식은 좀 더 세밀한 개인화 추천이 가능하고, 현재의 아키텍처로 100ms 의 응답을 보장한다고 합니다.

[Server] CPU Observability 높이는 Hyperthread 톺아보기

hyper-threading이 적용된 장비에서 성능이 떨어지는 문제가 있어서 원인을 분석하고자 했던 경험을 공유한 세션이었습니다.

Hyper-threading 이란, 인텔에서 하나의 core에 동시에 두 개 이상의 실행을 보장하는 방식입니다. CPU core가 2개면 동시에 4개의 작업을 처리하는 개념이라고 생각하시면 될 것 같습니다. 논리적 4개의 core겠네요.

일반적인 상황에서는 hyper-threading 이 무조건 좋다고 볼 수 있을 것 같습니다. Hyper-threading에서는 queue와 cache를 공유하기에 각각을 flush 할 때마다 지연이 발생합니다. cpu bound 가 많은 작업의 경우 hyper-threading이 비효율적이라고 합니다. 또한 보안을 위한 overhead 문제 또한 존재한다고 합니다.

실제로 hyper-threading이 어떤 경우에 효율적이고 비효율적인지를 확인하기 위해 성능 측정을 진행했습니다. 벤치 마킹을 위한 지표를 정해야했는데요, 단순 CPU Utilization은 정확한 정보가 아니라고 판단하여 Instruction 처리량을 확인하기로 했다고 합니다. 해당 처리량은 Linux-KI 및 Perf라는 도구를 활용했다고 합니다.

대부분의 경우 hyper-threading이 좋은 것을 확인했으나, 일부 자원 경합으로 인하여 같은 작업에 대해 cycle이 더 증가하는 것을 확인 할 수 있었다고 합니다. 병목 지점을 확인하기 위해서 CPU performance counter 라는 지표를 활용하였고, 이는 perf라는 도구로 확인할 수 있다고 합니다.

내용이 어려워서 대부분은 이해를 못했으나, 결론은 대부분은 hyper-threading 은 성능 증가를 보여주나, 사용중인 워크로드를 고려하여 적용해야한다는 것을 확인했습니다. 성능 확인을 위한 여러 도구 또한 알 수 있었습니다.

[Data] 전천후 데이터 분석을 위한 DW 설계 및 운영하기

DW(Data warehouse)를 사용하는 사람들에게 데이터 이해도를 높이고 사용성을 높이고자 고민하고 적용했던 내용에 대한 세션입니다. 저도 같은 고민을 했었기 때문에 가장 잘 이해했던 세션이었습니다.

우선 자주 인입되는 질문을 몇가지 패턴으로 유형화했습니다. (유저 방문 시기, 데이터의 수집 기간, 유저 유형 등) 기존 테이블들의 문제점을 분석했는데요, 테이블 & 컬럼 naming convention이 없었어서 테이블이 일관되게 보이지 않았고, 이벤트 타입 별로 특수하게 집계해야하는 지표를 담아내지 못하였으며, 복귀/기존 유저를 집계할 수 있는 정보가 없었다고 합니다.

이를 해결하기 위해 다음 방식을 적용했다고 합니다.

table naming rule 설정: m_{event_type}_{ukey - aggregation 기준 column}_{range - daily, weekly, monthly}
silver layer(raw data)의 데이터를 gold layer에 daily로 테이블을 만들어 특수한 지표들까지 aggregate해서 넣어줌
detail table을 만들어 복귀 / 기존 유저를 구분할 수 있도록 만듬

추가로 해당 테이블을 효율적으로 만들기 위하여 작업 병렬도를 높이고, backfill을 쉽게 할 수 있도록 dag(airflow) 를 구성했으며, 테이블 생성 로직을 재활용할 수 있도록 공통된 로직으로 테이블을 만들어 해당 테이블을 이용할 수 있도록 처리하였다고 합니다.

이를 통해 데이터를 조금 더 쉽게 이용할 수 있어졌다고 합니다.

[Special] 팀에 Winning Mentality를 불어넣는 리더십 스킬

2년차에 작은 파트이지만 해당 파트를 리딩(?)해야한다는 책임이 주어지고, 그때부터 리더십에 대해 고민을 많이 하게 되었습니다. 단순히 내가 리드를 할 때 어떻게 할 것인가부터, 지금 리딩을 하시는 분들의 생각도 파악하고 싶었고 이 세션을 듣게 되었습니다.

이 세션에서 팀은, 공동 목표를 함께 이루어 변화를 만드는 관계로 정의 했습니다. 그리고 팀을 이루기 위해서는 신뢰와 협력, 이해가 뒷받침 되어야 한다고 했습니다.

팀원의 신뢰를 쌓기 위해서는 팀원의 감정을 존중해주고, 또한 리더 스스로 신뢰 받는 사람이 되어야 하며, 멤버 간의 신뢰를 만들어야 한다고 합니다.
협력을 높이기 위해서는 팀원 특성별로 나누어 팀을 보완할 수 있도록 설정해야한다고 합니다.
이해를 높이기 위해서는 불만과 갈등을 넘기지 않고 함께 불편해하여 이를 해소할 수 있는 ground rule 을 만들어야 한다고 합니다.

이러한 것들을 기반으로 팀이 구성이 되었을 때, winning mentality를 갖기 위해서는 팀원 각각이 자율적으로 목표를 찾고 초과 성과를 내는 과정을 반복해야 한다고 합니다. 목표 수립은 눈에 보이는 것뿐만이 아닌 개인의 숨겨진 삶의 목표를 발굴하고 이를 달성할 수 있는 플랫폼으로써의 팀을 활용할 수 있도록 독려할 수 있습니다. 초과 성과는 단순 비즈니스적 목표 뿐만이 아닌, 팀 존속에 필요한 모든 행위에서 압도적 결과가 나온 것도 포함할 수 있습니다. 이러한 winning mentality 를 심어주기 위해서는 초과 성과자와 초과 성과의 배경과 방식을 공유해 다른 사람에게 긍정적인 영향을 주어야 한다고 합니다.

리더는 이러한 팀이 잘 굴러갈 수 있도록 기술적인 방해 요소를 제거해나가는 역할을 한다고 합니다.

개인적으로는 토스 내부인이 아니기 때문에 토스를 잘 알지는 않지만, 외부인의 시선에서 토스와 가장 잘 맞는 culture fit의 팀을 구성하기 위한 설명이 아닐까 하는 생각이 있습니다. 끝없는 목표와 장애물, 그리고 이를 극복하는 모습을 보여주는 회사에서 가장 이상적인 팀이 아닐까 생각이 되었습니다.

dev-writeup-2024 / september

[09-19] <toss>no limit</toss> #11