toss·2025년 12월 8일원문

사업자 데이터 리터러시 높이기: BC Monthly Report 발행기 (새 탭에서 열림)

토스는 각 사업부별로 흩어져 있던 사업자(Business Customer, BC) 데이터를 통합하여 '단일 진실의 근원(SSOT)'인 데이터 마트를 구축하고, 이를 기반으로 전사적인 월간 리포트를 발행하여 비즈니스 의사결정 구조를 혁신했습니다. 이 과정에서 파편화된 지표 정의를 하나로 모으고 현업의 니즈를 반영한 결과, 전사 구성원들이 동일한 기준으로 사업 현황을 파악하고 데이터에 기반해 실질적인 액션 아이템을 도출할 수 있는 환경이 마련되었습니다. 이러한 여정은 단순한 데이터 정리를 넘어 토스 전반의 데이터 리터러시를 높이고 비즈니스 성장을 가속화하는 기폭제가 되었습니다. **단일 진실의 근원(SSOT)을 위한 데이터 마트 구축** * 쇼핑, 광고, 페이 등 각 사업부별로 분산되어 관리되던 사업자 데이터를 통합하여 전사적으로 공통된 언어를 사용하는 'BC 데이터 마트'를 설계했습니다. * 사업부별로 상이했던 매출과 비용 발생 기준을 표준화하기 위해 도메인 담당자들과의 소통을 거쳐 '토스에서 활동하는 사업자'에 대한 명확한 정의를 수립했습니다. * 이를 통해 "이번 달 매출을 발생시킨 사업자가 몇 명인가?"라는 기초적인 질문에 대해 전사가 동일한 숫자로 답변할 수 있는 기술적 기반을 마련했습니다. **통찰을 제공하는 Monthly BC Report 설계 및 자동화** * 데이터의 전파력을 높이기 위해 신규(New), 이탈(Churn), 유지(Retained) 트렌드와 매출 규모별 티어(Tier) 분석을 포함한 월간 리포트를 기획했습니다. * 단순 지표 나열이 아닌, 코호트 리텐션(Cohort Retention) 분석을 통해 플랫폼 만족도를 확인하고, 이탈 가맹점 리스트 등 실무자가 즉시 활용 가능한 로우 데이터(Raw Data)를 함께 제공했습니다. * 데이터 파이프라인은 Airflow를 통해 마트를 구축하고 Jenkins로 배치 작업을 수행하며, 최종적으로 태블로(Tableau)와 SQL을 연동해 매달 자동으로 업데이트되는 환경을 구현했습니다. **현업 피드백을 통한 리포트의 고도화와 데이터 리터러시 확산** * PO, 세일즈 팀장 등 실제 사용자의 니즈를 파악하기 위해 심층 인터뷰를 진행하고, 이를 바탕으로 '회원 가입' 단계 분석이나 도메인 간 활성화 순서 등 구체적인 지표를 리포트에 추가했습니다. * 리포트 발행 이후 사업자 데이터에 대한 전사적 관심이 급증하며, 이탈 가맹점 상세 분석이나 데일리 트래킹 등 후속 심화 분석 프로젝트로 이어지는 성과를 거두었습니다. * 고정된 포맷에 안주하지 않고 매달 현업의 피드백을 반영하여 지표를 개선함으로써, 조직 전체의 데이터 이해도와 활용 능력을 점진적으로 상향 평준화했습니다. 데이터 마트 구축과 리포트 발행은 끝이 아닌 시작이며, 현업과의 지속적인 피드백 루프를 통해 리포트를 ' 살아있는 문서'로 관리하는 것이 중요합니다. 조직 내 데이터 리터러시를 높이고 싶다면 표준화된 지표 정의부터 시작해 구성원들이 실제 업무에 바로 적용할 수 있는 액션 중심의 데이터를 제공하는 단계적 접근이 필요합니다.

sqldata-analysisdata-pipelineairflow+4

toss·2025년 12월 1일원문

토스 Next ML Challenge - 광고 클릭 예측(PCTR) ML 경진대회 출제 후기 (새 탭에서 열림)

토스는 실제 서비스 데이터를 기반으로 한 광고 클릭 예측(CTR) 모델 개발 대회인 'Toss Next ML Challenge'를 통해 우수 ML 인재를 발굴하고 현업의 기술적 난제를 공유했습니다. 약 2,600명의 참가자가 1,070만 건의 익명화된 데이터를 바탕으로 실시간 서빙이 가능한 고성능 모델을 설계했으며, 출제진의 의도를 뛰어넘는 창의적인 피처 엔지니어링과 모델링 기법들이 제시되었습니다. 이번 대회는 데이터 보안과 실무적 난이도 사이의 균형을 맞춘 문제 설계를 통해 참가자들에게 실질적인 ML 시스템 설계 경험을 제공하고 토스 ML 챕터의 비전을 알리는 계기가 되었습니다. **실무 기반의 문제 설계와 CTR 예측** - 토스 앱 내 디스플레이 광고의 노출 및 클릭 로그를 활용해 특정 조건에서의 클릭 확률을 예측하는 모델 설계를 과제로 제시했습니다. - 약 1,070만 건의 대규모 트레이닝 샘플과 성별, 연령, 광고 지면 ID 등 다양한 피처를 제공하여 데이터 규모 측면의 실무 환경을 재현했습니다. - 단순히 예측 정확도뿐만 아니라 실제 서비스 적용을 고려하여 '실시간 서빙 가능성(Inference 속도)'을 가점 사항으로 포함해 효율적인 모델 구조 설계를 유도했습니다. **데이터 익명화의 한계와 시퀀스 피처의 도입** - 외부 반출을 위한 데이터 익명화 과정에서 다수 테이블의 조인이 어려워짐에 따라, 여러 데이터를 직접 가공하여 하나의 정형 테이블 형태로 제공했습니다. - 문제 난이도가 지나치게 낮아지는 것을 방지하기 위해 가공되지 않은 '시퀀스(Sequence) 피처'를 의도적으로 포함하여 참가자들의 분석 역량을 시험했습니다. - 참가자들은 익명화된 피처의 의미를 알 수 없는 제약 속에서도 시계열 특성을 파악하고 이를 수십 개의 파생 변수로 변환하는 집요함을 보여주었습니다. **참가자들의 모델링 전략과 기술적 통계** - 본선 진출 30팀 모두가 LightGBM, XGBoost 등 Boosting Tree 계열의 모델을 핵심적으로 활용했으며, 딥러닝 모델은 선택적으로 병행되었습니다. - 한 팀은 실시간 서빙이라는 제약 조건 속에서도 260개의 모델을 앙상블하는 파격적인 시도로 성능 극대화를 꾀했습니다. - 단일 시퀀스 피처에서 토큰 개수, 전이 결속도 등 37개의 파생 변수를 생성하여 성능을 높인 사례는 도메인 지식 없이도 순수 데이터 분석만으로 실무 수준 이상의 통찰을 보여준 결과였습니다. **대회의 성과와 실무적 시사점** - 리더보드 상위권 팀들은 공통적으로 시퀀스 피처를 심도 있게 분석하고, 복합적인 모델 앙상블과 더불어 과적합 방지 및 서빙 효율성을 고려한 설계를 제출했습니다. - 오프라인 시상식과 네트워킹을 통해 현업 엔지니어와 참가자들이 기술적 아이디어를 교환하며 실제 비즈니스 문제 해결을 위한 커뮤니티를 형성했습니다. - 익명화된 데이터 환경에서도 창의적인 피처 엔지니어링이 모델 성능을 결정짓는 핵심 요소임을 재확인했으며, 이는 향후 유사한 ML 챌린지 설계의 기준이 될 것으로 보입니다.

AI머신러닝feature-engineeringxgboost+4

toss·2025년 12월 1일원문

토스인컴 세금 환급 서비스 : 빠른 속도에서 품질을 지키기 위한 E2E 자동화 여정 (새 탭에서 열림)

토스인컴은 빠른 배포 속도에 대응하기 위해 기존의 수동 검증과 복잡한 클래스 기반 POM(Page Object Model)에서 벗어나, 함수형 POM 중심의 자동화 시스템을 구축했습니다. 이를 통해 4시간 이상 소요되던 검증 시간을 20분(병렬 실행 시)으로 단축하고 테스트 성공률 100%를 달성하며, QA가 제품의 품질을 초기부터 설계하고 실행 속도를 높이는 핵심 동력으로 자리 잡았습니다. ### 클래스 기반 POM에서 함수형 POM으로의 전환 * **무상태(Stateless) 함수 설계**: 상태를 갖는 클래스 대신 `page` 객체를 입력받아 동작을 수행하고 다시 `page`를 반환하는 단순한 함수 구조를 채택했습니다. * **가독성 및 유지보수성 향상**: 테스트 코드를 '사람이 읽는 시나리오'처럼 작성할 수 있게 되었으며, 버튼 문구 등 UI 변경 시 수십 개의 파일 대신 POM 함수 한 곳만 수정하면 되도록 캡슐화했습니다. * **명확한 네이밍 컨벤션**: `goto`, `click`, `enter`, `verify` 등 동작 중심의 접두사를 사용하여 코드만 보고도 어떤 테스트 단계인지 직관적으로 이해할 수 있게 했습니다. ### 여정 중심의 단계 분리와 레고식 조립 * **사용자 여정 기반 설계**: 단순히 화면 단위로 나누지 않고, '로그인/약관', '공제 확인', '결제', '신고' 등 세금 환급의 4가지 핵심 단계로 파일을 분리해 관리합니다. * **독립적 모듈화**: 의료비, 신용카드, 인적공제 등 각 공제 항목을 독립된 함수로 만들어, 새로운 테스트 시나리오가 필요할 때 필요한 기능만 레고 블록처럼 조립해 빠르게 생성할 수 있습니다. ### 테스트 안정성을 높이는 기술적 전략 * **4단계 클릭 폴백(Robust Click)**: React 렌더링 타이밍 문제로 발생하는 클릭 실패를 방지하기 위해 'Enter 키 입력 → 일반 클릭 → Force 클릭 → JS 직접 실행' 순의 단계별 재시도 전략을 유틸리티화했습니다. * **최신 페이지 자동 감지**: 리다이렉트나 새 창 열림이 빈번한 환경에서 `getLatestNonScrapePage` 유틸을 통해 항상 유효한 최신 탭을 추적하고 `currentPage`를 갱신하여 페이지 닫힘 에러를 방지했습니다. * **네트워크 대기 최적화**: Playwright의 기본 `networkidle` 방식 대신, 타임아웃이 발생해도 테스트를 중단하지 않고 UI 앵커(텍스트, role 등)로 화면 준비를 판단하는 `waitForNetworkIdleSafely`를 구현했습니다. ### 자동화 도입이 가져온 성과 * **정량적 지표 개선**: 검증 시간 77% 감소, 테스트 커버리지 600% 증가, 코드 중복률 76% 감소 등 모든 지표에서 비약적인 발전을 이루었습니다. * **업무 문화의 변화**: 24시간 자동 검증 시스템을 통해 개발 완료 즉시 기능을 점검하고 결과를 슬랙으로 공유하며, QA는 단순 반복 검증이 아닌 세금 엔진의 금액 정합성 검증 및 성능 지표 분석 등 고부가가치 업무에 집중하게 되었습니다. **실전 팁** 가장 빈번하게 오류가 발생하는 구간(예: 로그인)부터 자동화를 시작하고, 추상화에 너무 매몰되기보다 누구나 읽고 고칠 수 있는 명료한 함수 구조를 유지하는 것이 중요합니다. 특히 페이지 전환이 일어날 때마다 최신 페이지 객체를 새로 할당하는 원칙만으로도 상당수의 자동화 실패를 예방할 수 있습니다.

TypeScripttest-automationplaywrightfunctional-programming+3

toss·2025년 11월 30일원문

토스의 브랜드 심볼을 찾아서 (새 탭에서 열림)

토스가 오프라인 시장으로 확장하며 브랜드 인지도를 높이기 위해 사용자의 무의식 속에 자리 잡은 '진짜 얼굴'을 탐색한 과정을 다룹니다. UX 리서치를 통해 파란색 로고 자체보다 '흰 배경의 앱 아이콘' 형태와 '검정 영문 폰트'의 조합이 브랜드 정체성의 핵심임을 발견했습니다. 이를 통해 추상적인 브랜드 이미지를 구체적인 디자인 원칙으로 정립하여 오프라인 접점과 제품 디자인에 성공적으로 적용한 사례를 제시합니다. **오프라인 확장을 위한 브랜드 심볼의 재정의** * 온라인과 달리 맥락이 부족한 오프라인 환경(편의점 댕글러, POS 단말기 등)에서 사용자가 토스를 즉각적으로 인지할 수 있는 시각적 단서를 찾는 것이 과제였습니다. * 단순히 '어떤 로고가 예쁜가'를 넘어, 사용자가 낯선 환경에서도 토스를 토스로 인식하게 만드는 핵심 자산이 무엇인지 파악하기 위해 리서치를 시작했습니다. **심층 인터뷰를 통한 브랜드 이미지 탐색** * 브랜드에 대한 추상적인 인상을 명확한 언어로 표현할 수 있는 사용자를 선별하여 심층 인터뷰를 진행했습니다. * 사용자들이 느끼는 토스의 핵심은 시각적 요소가 아닌 '군더더기 없는 실용성'과 '편리한 경험'에 집중되어 있음을 확인했습니다. * 구체적인 시각적 심볼이 부족하다는 문제점을 발견하고, 이를 해결하기 위해 폰트, 컬러, 로고라는 세 가지 요소로 나누어 분석했습니다. **데이터로 찾아낸 세 가지 핵심 단서** * **폰트:** 사용자는 앱 내부의 국문 폰트보다 뉴스나 광고 등 외부 매체에서 자주 접한 '검정색 영문 toss'를 브랜드의 대표 폰트로 인지하고 있었습니다. * **컬러:** 사용자에게 각인된 토스의 컬러는 단일 '파란색'이 아니라, '흰 배경과 파란 로고'가 만나는 조합 그 자체였습니다. * **로고:** 로고를 직접 그려보게 한 결과, 사용자는 로고 단독 형태가 아니라 스마트폰 화면 속 '네모난 앱 아이콘(흰 바탕 + 파란 로고 + 사각 배경)' 구성을 브랜드의 얼굴로 기억하고 있었습니다. **리서치 인사이트의 실전 적용** * 리서치로 정의한 '진짜 심볼(앱 아이콘 형태 + 검정 영문 폰트 + 흰/파/검 조합)'을 실제 디자인에 반영했습니다. * **토스 10주년 캠페인:** 파란 배경 대신 사용자가 가장 토스답다고 느끼는 흰 바탕에 검정 글씨와 파란 로고 조합을 메인으로 사용했습니다. * **토스페이 결제 화면:** 전면 파란색 배경 시안을 걷어내고, 리서치로 검증된 시각적 공식을 적용하여 브랜드 인지도를 높였습니다. 브랜드 리서치는 추상적인 감각과 인식을 다루기에 결과물이 모호해질 위험이 있지만, 이를 구체적인 시각적 요소로 분해하여 분석함으로써 실질적인 프로덕트 개선과 일관된 브랜드 경험을 설계할 수 있습니다.

사용자 경험user-researchfintechbrand-identity+2

toss·2025년 11월 30일원문

레거시 결제 원장을 확장 가능한 시스템으로 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 결제 원장의 구조적 한계와 도메인 간 강한 결합을 해결하기 위해 MySQL 기반의 신규 원장 시스템을 구축했습니다. 데이터 불변성을 보장하는 INSERT-only 원칙과 이벤트 기반 아키텍처를 도입하여 복합 결제 지원 등 비즈니스 확장성을 확보했습니다. 이 과정에서 발생한 데이터 불일치와 타임아웃 문제를 해결하며 시스템의 자가 회복 능력을 강화하고 안정적인 운영 환경을 마련했습니다. ### 레거시 원장 시스템의 한계와 과제 - **데이터 구조의 불일치:** 결제수단별로 테이블 구조가 다르고, 동일한 성격의 데이터가 서로 다른 테이블에 저장되어 유지보수와 온보딩에 큰 비용이 발생했습니다. - **도메인 간 강한 결합:** 결제, 정산, 회계 등 여러 서비스가 하나의 원장 테이블과 컬럼을 공유하여, 작은 기능 수정 시에도 전사적인 영향도 분석이 필요했습니다. - **구조적 확장성 부족:** 결제와 결제수단이 1:1 관계로 묶여 있어, 더치페이나 복합 결제(카드+포인트)와 같은 현대적인 결제 시나리오를 지원할 수 없었습니다. ### 신규 원장 설계의 3가지 전략 - **데이터 불변성과 일관성:** 모든 승인 내역을 공통 테이블(`approve`)에 저장하고, 수정 대신 INSERT-only 방식을 채택하여 데이터의 정합성을 높이고 데드락을 방지했습니다. - **이벤트 기반의 도메인 분리:** 각 도메인이 직접 DB를 조회하는 대신 Kafka 이벤트를 구독하여 데이터를 처리하게 함으로써 도메인 간 의존성을 제거했습니다. - **결제와 승인 개념의 분리:** '결제'는 주문의 상태를, '승인'은 실제 결제수단의 실행을 의미하도록 분리하여 하나의 결제에 여러 승인 수단이 연결될 수 있는 유연한 구조를 만들었습니다. ### 무중단 마이그레이션 및 정합성 검증 - **비동기 점진적 적재:** 실서비스 장애를 방지하기 위해 기존 원장에 먼저 저장한 후, 신규 원장에는 별도의 ThreadPool을 통한 비동기 방식으로 데이터를 적재했습니다. - **검증 배치 운영:** 비동기 적재 중 발생할 수 있는 누락을 방지하기 위해, 매 5분마다 Read-Only DB를 기반으로 기존 원장과 신규 원장의 데이터를 비교하고 보정하는 배치를 실행했습니다. - **고성능 이관 작업:** 수억 건의 데이터 이관을 위해 Bulk Insert를 도입하고, 네트워크 지연 최소화를 위해 마이그레이션 서버를 DB와 동일한 가용 영역(AZ)에 배치했습니다. ### 운영 중 장애 대응과 시스템 고도화 - **쿼리 최적화:** 옵티마이저의 판단 오류로 발생한 풀 스캔(Full Scan) 문제를 인덱스 힌트(Index Hint) 추가와 롤백 시스템을 통해 빠르게 해결했습니다. - **타임아웃 및 정합성 관리:** MSA 구조에서 서버 간 타임아웃 설정을 일치시키고, 외부 원천사와의 상태 불일치를 해결하기 위한 망취소(Network Cancellation) 로직을 강화했습니다. - **이벤트 처리의 신뢰성:** 아웃박스(Outbox) 패턴과 로그 기반 복구를 통해 이벤트 누락을 방지하고, 헤더에 멱등키를 포함해 중복 이벤트 처리 문제를 해결했습니다. 신규 시스템으로의 전환은 단순한 DB 교체가 아니라 시스템의 지속 가능성을 확보하는 과정입니다. 초기 설계의 완벽함보다 중요한 것은 운영 중 발생하는 예외 상황에 시스템이 스스로 대응하고 회복할 수 있는 '자가 회복 구조'를 갖추는 것이며, 이를 위해 데이터 보정 배치와 로깅 시스템 같은 안전장치를 반드시 고려해야 합니다.

데이터베이스 설계Apache Kafka마이크로서비스mysql+4

toss·2025년 11월 27일원문

토스페이먼츠의 Open API 생태계 (새 탭에서 열림)

토스페이먼츠는 Open API를 단순한 통신 수단을 넘어 수십 년간 안정적으로 운영되어야 할 핵심 인프라로 정의합니다. 20만 개 이상의 가맹점이 사용하는 환경에서 개발자의 인지 부하를 줄이고 연동 신뢰성을 높이기 위해, 리소스 중심의 인터페이스 설계와 자동화된 생태계 구축을 최우선 과제로 삼고 있습니다. 이러한 철학은 기술적 완성도를 넘어 가맹점 개발자가 겪는 전반적인 경험(DX)의 질을 결정짓는 근간이 됩니다. ### 리소스 중심의 일관된 인터페이스 설계 * **직관적인 경로 규칙**: 가맹점이 URL 구조만 보고도 기능을 예측할 수 있도록 `버전/도메인/리소스 고유 ID` 순서의 일관된 경로 체계를 사용합니다. 특정 리소스 지정 외의 조건은 쿼리 파라미터나 JSON 필드로 분리하여 명확성을 높였습니다. * **중첩 객체를 활용한 모듈화**: 카드 정보나 현금영수증 내역처럼 여러 API에서 반복되는 데이터는 JSON의 계층 구조를 활용해 객체 형태로 모듈화합니다. 이는 데이터 중복을 줄이고 응답의 의미를 명확하게 전달하며, null 체크 등 가맹점의 코드 로직을 간소화합니다. * **도메인별 객체 재사용**: 승인, 조회, 취소 등 연관된 도메인의 API들이 동일한 응답 객체를 공유하도록 설계하여, 개발자가 새로운 API를 연동할 때 추가적인 학습 없이 결과를 예측할 수 있게 합니다. * **자연어 기반 데이터 표현**: 시스템 효율을 위한 코드 값(예: SC0010) 대신 "현대", "국민"과 같은 직관적인 한글 데이터를 제공합니다. 또한 `Accept-Language` 헤더에 따라 영문 등으로 응답을 자동 전환하는 로컬라이제이션(Localization)을 지원합니다. * **표준화된 오류 처리**: HTTP 상태 코드로 큰 틀의 성공/실패를 구분하고, 상세한 에러 코드와 메시지를 담은 표준 객체를 응답 바디에 포함하여 가맹점이 상황에 맞춰 유연하게 대응할 수 있도록 돕습니다. ### 비동기 처리를 위한 안정적인 웹훅 체계 * **이벤트 기반 처리**: 즉각적인 응답이 어려운 비동기 결제 상황에서 서버가 클라이언트에 처리 완료를 알리는 웹훅 인터페이스를 API와 함께 제공합니다. * **데이터 구조의 일관성**: 웹훅을 통해 전달되는 데이터 페이로드를 일반 API 응답과 동일한 리소스 객체 구조로 설계하여 가맹점의 파싱 로직 중복을 방지합니다. * **지수 백오프(Exponential Backoff) 재전송**: 네트워크 이슈나 가맹점 서버 장애로 인한 웹훅 전송 실패 시, 수신 서비스의 회복 시간을 고려하여 점진적으로 재시도 간격을 늘리는 전략을 사용합니다. * **자가 조치 도구 제공**: 개발자가 직접 웹훅 전송 내역을 조회하고 필요 시 수동으로 재전송할 수 있는 기능을 개발자 센터를 통해 지원하여 운영 편의성을 높였습니다. ### 개발자 경험(DX) 강화를 위한 문서 자동화 * **OAS 기반 실시간 동기화**: 수동 문서 작성의 한계를 극복하기 위해 OpenAPI Specification(OAS)과 Springdoc 라이브러리를 활용하여 서버 코드와 문서가 실시간으로 동기화되는 시스템을 구축했습니다. * **문서의 신뢰성 확보**: API 스펙이 변경될 때마다 연동 문서가 즉시 업데이트되므로, 가맹점 개발자는 항상 실제 동작하는 서버와 일치하는 최신 명세를 바탕으로 안심하고 개발할 수 있습니다. 토스페이먼츠의 사례처럼 좋은 Open API는 단순히 기능의 유무를 넘어, 개발자가 '설명 없이도 이해할 수 있는' 직관적인 구조와 자동화된 지원 환경을 갖추어야 합니다. 특히 리소스 중심 설계와 API-웹훅 간 데이터 일관성은 가맹점의 연동 비용을 획기적으로 낮추는 실용적인 전략이 될 수 있습니다.

API 설계jsonrest-apideveloper-experience+4

toss·2025년 11월 26일원문

누구나 리서치 하는 시대, UX리서처의 생존법 (새 탭에서 열림)

AI와 비전문가도 리서치를 수행할 수 있는 시대에 UX 리서처의 진정한 역할은 단순히 데이터를 수집하는 기술적 숙련도를 넘어, 제품의 방향성을 설정하고 팀의 시야를 하나로 모으는 'UX 리더십'에 있습니다. 리서처는 제품 개발의 각 단계에서 사용자의 본질적인 문제를 정의하고, 복잡한 비즈니스 맥락 속에서 팀이 길을 잃지 않도록 돕는 나침반 역할을 수행해야 합니다. ## 아이디어 단계: 사용자 중심의 '퍼즐 테두리' 맞추기 - 기획 초기 단계에서 팀의 관점을 '우리가 무엇을 만들 수 있는가'에서 '유저의 어떤 문제를 해결할 것인가'로 전환시킵니다. - 비즈니스 지표(재방문율, 체류시간 등)에만 매몰될 경우 발생할 수 있는 UX 저해 요소들을 사용자 관점의 가치 정의를 통해 방어합니다. - **사례(AI 시그널):** 단순한 정보 요약 기능을 넘어, 유저가 시장 변화의 이유를 빠르게 파악하여 투자 판단을 돕는다는 '북극성(핵심 가치)'을 설정해 제품의 윤곽을 잡았습니다. ## 개선 단계: 사용자 목표 중심의 구조화와 기준 수립 - 흩어져 있는 피드백과 문제점들을 나열하기보다, 사용자가 해당 기능을 통해 달성하려는 최종 '목표'를 먼저 정의합니다. - 목표 달성을 가로막는 방해 요인을 파악하고, 팀 전체가 동의할 수 있는 '서비스를 잘 쓴다는 것'에 대한 합의된 기준을 만듭니다. - **사례(증시 캘린더):** 단순한 일정 나열을 넘어 '인지-이해-준비'라는 3단계 사용자 여정을 설정함으로써, UI 수정을 넘어 투자자가 시장을 스스로 판단하게 돕는 도구로 제품을 고도화했습니다. ## 성장 및 정체 단계: 제품의 정체성과 환경적 맥락 재정의 - 제품의 성장이 정체되었을 때, 기능적 결함이 아닌 '제품의 정체성'과 '사용 환경(맥락)'의 불일치를 분석합니다. - 데이터, 인터뷰, 시장 트렌드를 입체적으로 결합하여 제품이 시장 내에서 차지해야 할 최적의 위치를 다시 찾습니다. - **사례(토스증권 PC):** 모바일의 '심플함'이 깊이 있는 분석이 필요한 PC 환경에서는 오히려 한계가 될 수 있음을 발견하고, PC라는 맥락에 맞는 새로운 가치와 제품의 지향점을 재정립했습니다. ## 리서처를 위한 실용적 제언 UX 리서처는 인터뷰를 잘하는 '기술적 장인'에 머물기보다, 제품과 산업 전체를 조망하는 넓은 시야를 갖추어야 합니다. 특히 팀원들의 흩어진 생각을 구조화하고, 의사결정의 근거가 되는 기준을 마련하여 **실질적으로 팀을 움직이게 만드는 'UX 리더십'**을 발휘하는 것이 AI 시대 리서처의 핵심 경쟁력입니다.

AI사용자 경험data-analysisusability-testing+3

toss·2025년 11월 19일원문

LTV를 넘어 서비스의 가치를 측정하는 새로운 지표, MTVi (새 탭에서 열림)

토스는 기존 LTV(LifeTime Value) 지표가 가진 긴 측정 주기와 증분 측정의 어려움을 해결하기 위해 MTVi(Mid term Value - incremental)라는 새로운 지표를 도입했습니다. MTVi는 유저가 특정 서비스를 처음 경험했을 때 향후 1년간 발생하는 재무적 순증 가치를 정의하며, 이를 통해 서비스가 플랫폼 전체에 기여하는 진정한 가치를 정량화합니다. 결과적으로 토스는 서비스별 투자 효율을 판단하고 전사적인 의사결정의 우선순위를 정하는 공통의 언어로 이 지표를 활용하고 있습니다. **기존 LTV 지표의 한계와 새로운 지표의 필요성** * LTV는 보통 3~5년의 긴 기간을 전제로 하기에, 빠른 실험과 개선을 반복하는 서비스 사일로의 의사결정 속도를 따라가지 못합니다. * 투자 회수 주기가 너무 길어 마케팅 비용(CAC) 집행의 적절성을 단기적으로 판단하기 어렵습니다. * 유저 전체의 평균 가치만을 보여줄 뿐, 특정 서비스 이용으로 인해 '추가로' 발생한 증분(Incremental) 가치를 분리해내지 못한다는 맹점이 있습니다. **MTVi의 정의와 산출 로직** * MTVi는 유저가 서비스를 새롭게 경험함으로써 발생하는 '향후 1년간의 순증 재무 가치'를 의미합니다. * A/B 테스트가 어려운 환경을 극복하기 위해 인과추론 방법론인 DID(Difference-in-Difference, 이중차분법) 추정법을 사용합니다. * 특정 월에 서비스를 처음 쓴 그룹(NAU)과 쓰지 않은 그룹(NEVER)을 비교하되, 유저 특성(연령, 활동 규모 등)에 따른 왜곡을 방지하기 위해 세그먼트 단위로 나누어 정밀하게 측정합니다. * 이를 통해 서비스가 없었더라도 발생했을 '자연 성장'분을 제거하고, 해당 서비스로 인해 유도된 순수한 가치 변화만을 남깁니다. **플랫폼 관점에서의 가치 구성** * MTVi는 '서비스 자체의 직접 손익'에 '해당 서비스로 인해 발생한 플랫폼 내 타 서비스로의 전이 가치'를 더해 계산합니다. * 예를 들어 '만보기'처럼 유저에게 혜택을 퍼주어 직접 손익은 마이너스인 서비스라도, 유저를 앱에 더 자주 머물게 하여 다른 금융 서비스 이용을 이끌어낸다면 MTVi는 플러스가 될 수 있습니다. * 이러한 관점은 마이데이터나 송금 등 플랫폼의 기초가 되는 서비스들의 재무적 가치를 증명하는 근거가 됩니다. **데이터 기반 의사결정의 변화** * "유저당 1년간 평균 N원의 가치를 만든다"는 명확한 숫자를 통해 모든 팀이 동일한 기준으로 소통하게 되었습니다. * 마케팅비나 운영비 등의 투자 판단 시, 고객 획득 비용(CAC)이 MTVi를 넘지 않도록 설정하는 등 정량적인 투자 효율 가이드를 제공합니다. * 여러 서비스 중 어떤 것에 먼저 자원을 투입해야 할지 우선순위를 정하는 데 있어 객관적인 지표로 기능합니다. 플랫폼 비즈니스에서 각 서비스가 독립적인 수익을 내지 않더라도 전체 생태계에 기여하는 바를 측정하는 것은 매우 중요합니다. 토스의 MTVi 사례처럼 단순한 매출 합계가 아닌 인과관계에 기반한 '증분 가치'를 측정할 때, 비로소 서비스의 진정한 가치를 이해하고 지속 가능한 성장을 위한 자원 배분이 가능해집니다.

data-analyticscausal-inferencedifference-in-differenceunit-economics+4

toss·2025년 11월 13일원문

100년 가는 프론트엔드 코드, SDK (새 탭에서 열림)

토스페이먼츠는 결제 연동의 복잡성을 해결하기 위해 SDK를 제공하고 있으며, 최근 V1의 한계를 극복하고 안정성과 확장성을 극대화한 V2 SDK를 구축했습니다. 가맹점의 다양한 런타임 환경과 예측 불가능한 요구사항에 대응하기 위해 단순한 기능 구현을 넘어 체계적인 아키텍처와 모니터링 시스템을 도입했습니다. 결과적으로 개발자에게는 쉬운 연동 경험을, 비즈니스에는 견고한 신뢰성을 제공하는 결제 생태계를 완성했습니다. **SDK 개발의 특수성과 V1의 한계** * **환경의 의존성:** SDK는 가맹점의 코드 내에서 실행되므로, 가맹점의 호출 빈도나 네트워크 상태에 직접적인 영향을 받습니다. 일례로 사용량 분석을 위해 추가한 로그 코드가 특정 가맹점의 잦은 호출과 맞물려 네트워크 병목 현상을 일으키고 서비스 전체를 다운시키는 사례가 발생했습니다. * **런타임 예측 불가능성:** 가맹점에서 잘못된 데이터 타입(예: String 대신 Number)을 전달할 경우 `startsWith` 같은 표준 메서드에서 에러가 발생하는 등, 일반적인 프론트엔드 개발보다 훨씬 방어적인 코딩이 요구됩니다. * **커뮤니케이션의 접점:** SDK는 단순히 API를 호출하는 도구가 아니라 가맹점 개발자와 만나는 기술적 창구이며, 가맹점의 수많은 커스텀 요구사항을 수용해야 하는 복잡성을 안고 있습니다. **안정성 확보를 위한 테스트와 모니터링** * **촘촘한 테스트 체계:** 로직 검증을 위한 300개 이상의 단위 테스트와 다양한 유즈케이스를 반영한 500개 이상의 E2E 통합 테스트를 통해 코드 수준의 안정성을 확보했습니다. * **Global Trace ID:** 프론트엔드부터 백엔드까지 결제 전 과정을 하나의 식별자로 추적하는 체계를 도입하여, 장애 발생 시 시스템 레이어 전체를 쉽게 파악할 수 있도록 했습니다. * **모니터링 CLI:** 배포 전후의 결제 성공률을 가맹점 및 런타임 환경(OS, 브라우저, 웹뷰 등)별로 비교 분석하는 자체 도구를 개발했습니다. 이를 통해 특정 환경에서 발생하는 결제 중단 현상을 실시간으로 탐지하고 즉각 대응합니다. **확장성을 위한 레이어드 아키텍처** * **조립 가능한 구조:** 특정 가맹점만을 위한 예외 처리가 `if`문으로 산재되어 코드 복잡도가 올라가는 문제를 해결하기 위해, 기능을 레고 블록처럼 독립적으로 구성했습니다. * **3계층 분리:** "변경의 원인"을 기준으로 코드의 경계를 명확히 나누어 관리합니다. * **Public Interface Layer:** 가맹점과 약속한 인터페이스를 검증하고 도메인 언어로 번역하는 역할 * **Domain Layer:** 핵심 비즈니스 로직과 결제 정책을 담당하는 중심부 * **External Service Layer:** 서버 API나 Web API 등 외부 의존성과의 통신을 담당하는 계층 * **관심사 격리:** 이러한 계층화를 통해 가맹점별 커스텀 요구사항이 추가되더라도 기존의 핵심 로직에 영향을 주지 않고 특정 블록만 교체하거나 확장할 수 있는 유연성을 확보했습니다. 성공적인 SDK 개발을 위해서는 단순히 편리한 기능을 제공하는 것을 넘어, 타사의 코드 환경에서도 견고하게 동작할 수 있는 방어적인 설계와 문제 발생 시 즉시 원인을 파악할 수 있는 관측성(Observability) 확보가 필수적입니다. 가맹점별 특이 케이스를 코드 전반에 흩뿌리기보다는, 명확한 레이어 구분을 통해 비즈니스 로직과 커스텀 로직을 분리하는 설계 원칙을 권장합니다.

옵저버빌리티TypeScriptsoftware-architectureelasticsearch+3

toss·2025년 11월 6일원문

토스에서 가장 안 좋은 경험 만들기 (새 탭에서 열림)

토스에서 광고와 혜택 서비스를 담당하는 디자이너는 비즈니스 목표 달성과 사용자 경험(UX) 개선이 상충하는 과제가 아니라, 치열한 고민을 통해 찾아내야 할 ‘교집합’이라고 주장합니다. 필자는 광고라는 피할 수 없는 비즈니스 조건을 수용하되, 사용자가 느끼는 불쾌함을 최소화하고 오히려 가치 있는 경험으로 전환하는 전략을 통해 실질적인 성과를 이끌어냈습니다. 결과적으로 사용자의 신뢰를 지키는 방식이 비즈니스 임팩트를 극대화하는 가장 확실한 길임을 증명하며, 서비스의 수익성과 활성도를 동시에 잡는 결론에 도달했습니다. **사용자의 불쾌감을 줄이는 예측 가능성과 배치** * **예측 가능한 광고 경험:** 광고가 예고 없이 튀어나올 때 발생하는 사용자의 거부감을 줄이기 위해 '광고 보고'라는 문구나 광고 길이를 미리 명시했습니다. 이는 클릭률 저하 우려와 달리 부정적인 피드백을 유의미하게 감소시켰고, 광고를 수용할 사용자만 선택하게 함으로써 광고 효율을 유지했습니다. * **동선을 방해하지 않는 위치 선정:** 계좌 내역 등 사용자의 핵심 정보 탐색 동선에 광고를 배치해 혼란을 주던 방식을 폐기했습니다. 정보를 오인하지 않도록 광고 영역을 분리 배치한 결과, 매출 타격 없이 사용자의 신뢰와 지표를 동시에 회복할 수 있었습니다. **광고를 혜택과 재미로 인식하게 만드는 전략** * **맥락에 맞는 광고 제공:** 광고주가 직접 집행할 수 있는 B2B 광고 플랫폼을 구축하여 광고의 양을 늘리고, 유저 개개인에게 필요한 순간(예: 자동차 보험 만료 시점)에 맞춰 광고를 노출해 광고가 '혜택'처럼 느껴지게 설계했습니다. * **인터랙티브한 재미 요소 도입:** 광고를 단순 이미지 노출이 아닌 퀴즈, 게임, 휴대폰 움직임에 반응하는 인터랙션 등 재미있는 콘텐츠로 변모시키기 위해 팀 내부에서 정기적인 아이데이션을 진행하고 이를 실제 제품에 반영했습니다. **적절한 보상 설계를 통한 비즈니스 모델 전환** * **사용자가 체감하는 보상의 가치 탐색:** 1년 이상의 실험을 통해 현금, 기프티콘, 일확천금형 복권 등 다양한 보상 체계를 테스트하며 사용자가 광고 시청의 '노동 강도'를 기꺼이 수용할 만한 지점을 찾아냈습니다. * **만보기 복권의 성공 사례:** 광고 시청 시 100만 원 당첨 기회를 주는 '복권' 형태의 보상을 만보기 서비스에 도입하여, 적자 서비스를 수익 창출 서비스로 전환했습니다. 이는 유저 활동성과 만족도를 동시에 높여 구글로부터 게임 외 서비스 중 광고 임팩트가 가장 큰 사례로 인정받기도 했습니다. 비즈니스와 사용자 경험 사이에서 고민하는 조직이라면, 단순히 광고를 숨기거나 강요하기보다 사용자의 신뢰를 지키는 '투명성'과 적절한 '보상'의 지점을 찾는 실험을 반복해야 합니다. 광고가 사용자의 목적을 방해하는 요소가 아니라, 그 자체로 재미나 이득을 줄 수 있는 보완재로 기능하게 할 때 비즈니스는 지속 가능한 성장을 이룰 수 있습니다.

사용자 경험프로덕트 디자인a-b-testinggamification+3

toss·2025년 11월 3일원문

토스플레이스 사일로 QA로 일한다는 것 (새 탭에서 열림)

토스플레이스의 QA 팀은 기능 조직으로서의 전문성을 유지함과 동시에 제품 개발 단위인 '사일로(Silo)'에 겸직 형태로 참여하여 제품의 초기 기획 단계부터 배포까지 전 과정을 함께합니다. 이러한 구조적 변화를 통해 QA는 단순한 검수자가 아닌 제품의 히스토리를 깊이 이해하고 리스크를 선제적으로 관리하는 전략적 파트너로 자리 잡았습니다. 결과적으로 품질 관리가 배포를 지연시킨다는 편견을 깨고, 빠른 배포와 높은 품질을 동시에 달성하며 팀 전체의 신뢰를 얻는 성과를 거두었습니다. **사일로 겸직 구조를 통한 품질 관리의 내재화** * QA 매니저는 제품 초기 셋업 단계부터 참여하여 OKR 설계 및 요구사항 정의 과정에서 발생할 수 있는 잠재적 리스크를 사전에 식별합니다. * 제품의 제작 의도와 히스토리를 명확히 파악함으로써 보다 정교한 테스트 범위 산정과 테스트 케이스 설계가 가능해집니다. * 사일로 내부에서 작은 단위의 프로세스 실험을 자유롭게 수행하고, 성과가 검증된 방식은 팀 전체로 확산하는 유연한 운영 방식을 채택하고 있습니다. **협업 효율을 높이는 디자인 및 스펙 리뷰 체계** * '스펙 리뷰 → QnA 세션 → 변경 사항 정리'로 이어지는 흐름을 도입하여 개발 및 QA 과정에서 발생하는 이해관계자 간의 정보 간극을 최소화했습니다. * 디자인 툴(데우스)과 사내 메신저 스레드를 활용해 산재된 변경 내용을 한곳에 모아 관리함으로써 투명성을 높였습니다. * 개발 착수 전 모든 직군이 동일한 이해도를 가질 수 있도록 디자인 픽스 시점에 별도의 리뷰 미팅을 진행합니다. **라이브 모니터링과 품질 책임의 공유** * 릴리즈 이후 QA 혼자 검증하는 한계를 극복하기 위해 모든 팀원이 함께 확인해야 할 '주요 체크리스트'를 도입했습니다. * 개발 외 직군도 직접 제품 상태를 점검하게 함으로써 품질은 QA만의 책임이 아닌 팀 전체의 책임이라는 문화를 형성했습니다. * 이를 통해 최종 스펙을 재검증하고 실환경에서 발생할 수 있는 문제를 조기에 발견하는 환경을 구축했습니다. **개발 효율을 극대화하는 Sanity 테스트 및 백로그 관리** * QA 시작 기준을 명확히 하기 위해 개발 시작 전 'Sanity 테스트' 기준을 수립하고, 정상 시나리오(Happy Case)에 대한 검증을 기본 원칙으로 세웠습니다. * 사내 메신저의 'Send to Notion' 기능을 활용해 대화 중 나오는 아이디어나 작은 이슈들이 누락되지 않도록 즉시 백로그 데이터베이스에 기록합니다. * 이슈의 우선순위를 사용자 경험과 배포 긴급도에 따라 분류하여, 효율적인 리소스 배분과 체계적인 이슈 추적을 실천하고 있습니다. **커뮤니케이션 중심의 도구 최적화 (Jira에서 리스트/캔버스로)** * 소통 채널의 파편화를 막기 위해 기존의 Jira 중심 업무 방식에서 사내 메신저 기반의 '리스트/캔버스' 기능으로 전환을 시도했습니다. * 담당자 지정 및 템플릿 커스터마이징을 통해 이슈 관리와 소통을 한곳에 통합하여 맥락 공유에 드는 리소스를 대폭 줄였습니다. * 도구 자체의 기능보다는 팀의 실제 소통 방식에 가장 적합한 도구를 선택하는 유연함을 발휘하여 업무 속도를 높였습니다. 토스플레이스의 사례는 QA가 제품의 끝단이 아닌 시작점부터 결합될 때 조직의 생산성이 어떻게 극대화될 수 있는지를 잘 보여줍니다. 품질 관리 프로세스를 고정된 틀에 가두지 않고 각 팀의 특성에 맞게 유연하게 설계하고 개선해 나가는 '자율성'과 '실험 정신'은 제품의 신뢰도를 높이고자 하는 모든 IT 조직에 실질적인 영감을 제공합니다.

데이터베이스 설계jiranotionquality-assurance+4

toss·2025년 10월 30일원문

토스 피플 : 데이터를 ‘이해하는’ 구조를 설계합니다 (새 탭에서 열림)

데이터의 품질은 사후 수습이 아닌 생성 단계의 초기 설계에서 결정되며, 특히 AI 시대에는 사람뿐만 아니라 기계도 데이터의 맥락을 완벽히 이해할 수 있는 의미 기반의 구조 설계가 필수적입니다. 토스는 이를 위해 데이터의 생성부터 활용까지 전 과정을 관리하는 'End-to-End 데이터 거버넌스'를 지향하며, 개발 속도를 저해하지 않으면서도 품질을 높이는 유연한 설계 표준을 구축하고 있습니다. 결과적으로 데이터 아키텍처는 단순한 규칙 강제가 아니라 비즈니스의 빠른 변화 속에서 데이터의 정합성을 유지하고 AI와 사람이 신뢰할 수 있는 기반을 만드는 핵심적인 역할을 수행합니다. **데이터 설계의 본질과 품질 관리의 전환** * 데이터의 품질은 분석 단계에서의 정제가 아니라, 데이터가 처음 만들어지는 순간의 설계(Design)에 의해 결정됩니다. * 서비스가 빠르게 변하는 플랫폼 환경에서는 데이터 수습에 에너지를 쏟는 사후 대응보다, 데이터가 생성되는 흐름부터 구조적으로 정리하는 사전 설계가 중요합니다. * '속도'와 '품질'은 대립하는 가치가 아니며, 설계 시 미래의 변화 가능성을 고려한 유연한 기준선을 마련함으로써 두 가치 사이의 균형을 잡아야 합니다. **AI가 이해할 수 있는 의미 중심의 데이터 구조** * 현대의 데이터 아키텍처는 사람뿐만 아니라 AI가 질문하고 분석하는 시대를 대비하여 기계가 읽을 수 있는(Machine-readable) 형태로 진화해야 합니다. * 단순한 메타데이터 관리를 넘어, 데이터 간의 의미 관계를 명확히 하는 '의미 기반 표준 사전'과 '온톨로지(Ontology)'를 도입하여 AI가 맥락을 놓치지 않도록 설계합니다. * 데이터 간의 연결 고리를 명확히 설계함으로써 AI가 스스로 의미를 추론하며 발생할 수 있는 해석 오류를 줄이고 데이터의 신뢰성을 극대화합니다. **실천적인 데이터 거버넌스와 아키텍트의 역할** * 효과적인 거버넌스는 규칙을 강제하는 것이 아니라, "표준을 따르는 것이 오히려 더 편하다"고 느낄 수 있도록 자연스러운 프로세스를 설계하는 것입니다. * 비즈니스의 빠른 사이클 속에서 모든 것을 완벽하게 설계하기보다, 현재 맥락에 맞으면서도 나중에 무리 없이 정리할 수 있는 '확장성 있는 여지'를 남겨두는 전략이 필요합니다. * 데이터 아키텍트는 거창한 담론에서 시작하는 것이 아니라, 작은 구조 하나를 더 낫게 만들고 싶어 하는 데이터 엔지니어와 분석가 모두가 도달할 수 있는 전문 영역입니다. 데이터 아키텍처는 단순히 테이블 명세서를 관리하는 일이 아니라 비즈니스의 복잡도를 구조로 풀어내는 일입니다. 고품질의 데이터를 유지하면서도 개발 속도를 잃지 않으려면, 초기 설계 단계에서부터 AI와 협업할 수 있는 표준 체계를 구축하고 이를 조직 내에서 자연스럽게 수용할 수 있는 '실현 가능한 거버넌스 모델'을 고민해 보는 것이 좋습니다.

data-governancedata-architecturedata-modelingmetadata+4