ab-testing

AttributedString 구조로 풀어낸 대규모 iOS 설정 시스템 (새 탭에서 열림)

LINE iOS 앱의 성장으로 인해 기존의 일체형 서비스 설정 시스템은 의존성 관리, 안정성, 개발 생산성 측면에서 한계에 봉착했습니다. 이를 해결하기 위해 LINE은 각 모듈이 독립적으로 설계를 정의하면서도 타입 안전성을 확보하고, 동시성 환경에서도 안전하게 작동하는 새로운 아키텍처로의 전환을 시도했습니다. 특히 Apple의 `AttributedString` 설계 방식을 벤치마킹하여 대규모 프로젝트에 적합한 확장성 있는 설정 관리 체계를 구축하고자 했습니다. **서비스 설정 시스템의 역할과 구조** * LINE은 2주마다 정기 배포를 진행하므로, 개별 서비스의 신규 기능 출시나 롤백을 앱 업데이트 없이 수행하기 위해 '서비스 설정' 시스템을 활용합니다. * 서버는 사용자의 지역, 기기, OS 버전 등에 따라 최적화된 설정값을 문자열 형태의 키-값 쌍(JSON)으로 클라이언트에 전달합니다. * 이 시스템은 기능 토글뿐만 아니라 A/B 테스트, 오류 수집 샘플링 비율 조정, UI 정책 결정 등 다양한 용도로 사용되며 현재 약 700개의 키가 운용되고 있습니다. **일체형 구조로 인한 순환 의존성 딜레마** * 과거에는 모든 설정 키를 단일 파일에서 관리했으나, 프로젝트 규모가 커지며 해당 파일이 7천 줄에 달하는 등 관리가 어려워졌습니다. * 설정 시스템이 특정 서비스 모듈의 전용 타입(예: 사진 품질 타입)을 반환하려 하면 모듈 간 순환 참조가 발생하여, 결국 타입 안전한 객체 대신 날것의 문자열을 노출하고 각 모듈에서 매번 파싱해야 하는 비효율이 발생했습니다. **불완전한 추상화와 구현 세부 사항의 노출** * 서버 규약에 따라 불리언 값을 "Y"/"N" 문자열로 처리해야 했고, 이를 위해 `decodeBoolIfPresent` 같은 비표준 메서드를 별도로 구현해야 했습니다. * 이 과정에서 표준 메서드와의 혼동으로 인한 버그가 잦았으며, 용도가 미묘하게 다른 기본값을 세 번이나 중복 정의해야 하는 설계 결함이 존재했습니다. * 이러한 복잡성은 신규 개발자에게 암기 위주의 온보딩 지식을 강요하여 생산성을 저하시켰습니다. **스레드 안전성 부재로 인한 런타임 오류** * 기존 시스템은 동시성을 고려하지 않고 설계되어, 여러 스레드에서 설정값을 읽는 과정에서 지연 평가 및 인스턴스 해제 타이밍이 겹치는 문제가 있었습니다. * 이로 인해 메모리 해제 후 사용(use-after-free) 오류가 발생하여 매일 수백 건의 크래시가 기록되는 등 앱 안정성에 심각한 영향을 미쳤습니다. **테스트 및 디버깅 효율성 저하** * 시스템 자체에 오버라이드 기능이 없어 QA 과정에서 설정값을 임시로 변경하려면 다수의 파일을 직접 수정해야 하는 번거로움이 있었습니다. * 싱글턴 구조의 의존성 때문에 각 모듈은 테스트를 위해 별도의 프로토콜과 테스트 대역을 각자 만들어 관리해야 했으며, 이는 실제 구현체와의 동작 괴리를 유발하는 원인이 되었습니다. **성장을 위한 설계의 재정립** * 대량의 키-값 쌍을 타입 안전하게 관리하면서도 각 모듈이 독립적으로 키를 정의할 수 있는 구조를 만들기 위해 Foundation의 `AttributedString` 설계를 참고했습니다. * 이는 개별 서비스가 자신의 도메인에 맞는 설계를 독립적으로 확장할 수 있게 하여, 거대해진 프로젝트 규모에 대응할 수 있는 유연한 기반을 마련하는 계기가 되었습니다.

개인화와 실험을 위한 별도의 기술 스택을 사용하는 이유 | Spotify 엔지니어링 (새 탭에서 열림)

스포티파이는 개인화(Personalization)와 실험(Experimentation)을 서로 다른 기술 스택으로 분리하여 운영합니다. 개인화 시스템은 머신러닝(ML) 스택을 통해 구축하고, 이렇게 구축된 시스템의 성과와 가치는 실험 스택인 'Confidence' 플랫폼을 통해 검증하는 구조를 취합니다. 이러한 분리를 통해 스포티파이는 각 인프라의 전문성을 유지하면서도 기술적 부채를 방지하고 대규모 시스템을 효율적으로 확장하고 있습니다. ### 실험에서 개인화로의 진화와 컨텍스트 밴딧 * **A/B 테스트와 멀티 암드 밴딧(MAB):** 일반적인 A/B 테스트는 모든 사용자에게 평균적으로 가장 좋은 버전을 찾습니다. 반면, MAB는 실험 중에 성과가 좋은 그룹에 더 많은 트래픽을 동적으로 할당하여 효율성을 높입니다. * **컨텍스트 밴딧(Contextual Bandits):** 사용자 특성(나이, 위치, 과거 행동 등)에 따라 각기 다른 최적의 '대안(Arm)'을 제공합니다. 이는 더 이상 하나의 최고 버전을 찾는 것이 아니라, 개별 사용자에게 맞춤화된 경험을 제공하는 '개인화' 영역으로 진입함을 의미합니다. * **시스템으로서의 개인화:** 컨텍스트 밴딧이 도입되면 실험의 목적은 특정 버튼의 효과 측정이 아니라, "이 개인화 시스템이 기존 시스템보다 더 큰 가치를 창출하는가?"라는 시스템 평가로 전환됩니다. ### 기술 스택을 분리해야 하는 인프라적 이유 * **성능 및 지연 시간(Latency) 요구사항:** 개인화 모델(NN, LLM, 부스팅 모델 등)은 실시간 데이터 기반의 추론과 극도로 낮은 지연 시간을 요구합니다. 이를 위해 최적화된 ML 스택이 필요하며, 실험 도구가 이러한 성능 요구사항을 모두 수용하려 하면 시스템이 지나치게 비대해집니다. * **기술적 부채 방지:** 실험 스택과 ML 스택의 관심사를 혼합하면 시스템 간 결합도가 높아져 관리하기 어려운 기술적 부채가 발생합니다. 스포티파이는 이를 분리함으로써 각 플랫폼이 고유의 목적에 집중하게 합니다. * **복잡한 모델 지원:** ML 플랫폼은 대규모 피처 세트와 복잡한 알고리즘을 학습하고 서빙하는 데 특화되어 있어, 단순한 실험 도구보다 정교한 개인화 로직 구현에 유리합니다. ### 분리를 통한 평가 체계의 명확성 * **재귀적 평가의 필요성:** 컨텍스트 밴딧이나 추천 알고리즘 자체도 하나의 '기능'입니다. 따라서 새로운 알고리즘 버전이 기존 버전보다 나은지 확인하기 위해서는 별도의 A/B 테스트가 필요합니다. * **관심사 분리(Separation of Concerns):** ML 스택은 "어떻게 개인화할 것인가"를 담당하고, 실험 스택은 "이 개인화가 실제로 효과가 있는가"를 측정합니다. * **병렬 실험 가능:** 실험 플랫폼을 독립적으로 유지함으로써, 수천 개의 다른 실험들과 간섭 없이 개인화 모델의 성능을 동시에 테스트하고 확장할 수 있습니다. 성공적인 개인화 서비스를 구축하려면 개인화 알고리즘(컨텍스트 밴딧 등)을 실험의 도구가 아닌, **검증 대상이 되는 제품의 기능**으로 정의해야 합니다. 저지연 모델 서빙과 복잡한 피처 처리는 전용 ML 스택에 맡기고, 실험 플랫폼은 이를 객관적으로 비교·평가하는 역할에 집중하는 것이 기술적 유연성과 운영 효율성을 동시에 잡는 길입니다.

마케팅 문구 클릭률을 올리는 6가지 원칙 (새 탭에서 열림)

사용자를 기만하거나 불안을 자극하지 않는 토스의 엄격한 라이팅 원칙 속에서도 높은 클릭률과 전환율을 달성할 수 있는 구체적인 카피라이팅 전략을 제시합니다. 수백 번의 A/B 테스트를 통해 증명된 이 원칙들은 화려한 수식어보다 사용자의 심리적 장벽을 낮추고 행동의 명확성을 높이는 데 집중합니다. 결국 마케팅 성과는 자극적인 문구가 아니라, 사용자가 지금 당장 무엇을 해야 하고 무엇을 얻을 수 있는지 직관적으로 이해시키는 디테일에서 결정된다는 것이 핵심 결론입니다. ### 단 하나의 핵심 가치에 집중하기 * 여러 장점을 나열하기보다 사용자가 지금 당장 클릭해야 할 단 하나의 이유만 전달할 때 반응이 더 좋습니다. * 복잡한 혜택 설명(예: 신혼부부 지원금 등)을 모두 제거하고 '10문제 찍고 결과 보기'처럼 즉각적인 행동 하나에만 집중했을 때 노출과 클릭률이 10배 이상 상승했습니다. * 긴 설명은 문장을 복잡하게 만들 뿐이며, 구체적인 가치는 클릭 이후의 상세 페이지에서 경험하게 해도 충분합니다. ### 불확실한 대박보다 확실한 보상 약속하기 * 사용자는 '최대 혜택'이라는 막연한 기대보다 소액이라도 '무조건 받을 수 있다'는 확실성에 더 민감하게 반응합니다. * '최대 100만 원'보다 '최소 100원'을 강조했을 때 노출이 20배 더 잘 되었으며, '마음껏 받기'보다 '1장은 무조건 받기'가 더 높은 클릭률을 기록했습니다. * 지나치게 큰 금액은 오히려 광고라는 거부감을 주거나 조건이 까다로울 것이라는 인상을 줄 수 있으므로, 보상의 확실성을 강조하는 것이 유리합니다. ### 심리적 문턱을 낮추는 단어 선택 * 동일한 행동이라도 어떤 단어를 쓰느냐에 따라 사용자가 느끼는 심리적 무게가 달라집니다. * 절차와 서류가 떠오르는 '가입하기' 대신, 금방 끝날 것 같은 느낌을 주는 '준비하기'를 사용해 사용자의 부담을 줄일 수 있습니다. * 사용자가 행동을 완료하기까지 걸리는 시간을 짧게 명시하는 것도 효과적인 방법입니다. ### 정보의 성격과 출처 명시하기 * 혜택을 설명하기 전, 해당 정보가 어떤 성격인지(모음집인지, 신규 소식인지) 먼저 알려주면 신뢰도가 높아집니다. * 상품 하나를 제안하기보다 '대출 목록 모아보기'처럼 정보의 형태를 언급하거나, '새로 나온 혜택'임을 강조했을 때 클릭률이 최대 6배까지 높아졌습니다. * 사용자가 정보를 탐색하기 전에 기대치를 설정해 주는 것이 중요합니다. ### 조건과 행동의 구체적인 수치화 * 사용자는 자신이 수행해야 할 과업의 양을 정확히 알 때 행동에 나설 확률이 높습니다. * 단순히 '미션 도전'이라고 하기보다 '미션 4개', '빈칸 채우기'보다 '8칸 채우기'처럼 숫자를 명시했을 때 전환율이 최대 4배까지 상승했습니다. * 막연함은 고민을 낳고 고민은 이탈로 이어지므로, "얼마나 해야 하지?"라는 의문이 들지 않도록 목표를 명확히 제시해야 합니다. ### 일상의 직관적인 경험 연결 * 화면 속의 동작을 일상에서 자주 하는 익숙한 행동으로 묘사하면 별다른 설명 없이도 이해도를 높일 수 있습니다. * 퀴즈 서비스에서 단순히 '정답 보기'라고 하기보다 손가락으로 가볍게 선택하는 느낌의 '정답 찍기'라는 표현을 사용해 클릭률과 전환율을 모두 높였습니다. * 단어의 뉘앙스에 맞는 이모지(예: 도장 이모티콘)를 활용하면 시각적인 직관성을 더욱 보완할 수 있습니다. --- **실용적 제언** 성과가 나지 않는 마케팅 문구를 수정하고 싶다면, 미사여구를 더하기보다 사용자의 '심리적 비용'을 줄이는 방향으로 접근해보세요. "무엇을 얻는가"만큼이나 "내가 무엇을, 얼마나, 어떻게 해야 하는가"를 친절하고 구체적으로 알려주는 것이 토스가 증명한 가장 강력한 전환의 기술입니다.

핀터레스트 검색 (새 탭에서 열림)

핀터레스트(Pinterest)는 검색 결과의 관련성을 측정하기 위해 기존의 고비용 휴먼 레이블링(Human Labeling) 방식 대신 미세 조정된 대규모 언어 모델(LLM)을 도입했습니다. 이를 통해 관련성 평가의 비용과 시간을 대폭 절감하는 동시에, 측정 가능한 최소 탐지 효과(MDE)를 1.5%에서 0.25% 이하로 낮추어 정밀한 A/B 테스트 분석이 가능해졌습니다. 결과적으로 핀터레스트는 LLM의 확장성을 활용해 더욱 정교한 샘플링 설계를 구현하고 검색 품질을 지속적으로 개선할 수 있는 기반을 마련했습니다. ### 미세 조정된 LLM 기반의 관련성 예측 모델링 * **모델 구조 및 학습**: 다국어 지원이 가능한 오픈소스 LLM(XLM-RoBERTa-large 등)을 교차 인코더(Cross-encoder) 구조로 활용하여 쿼리와 핀(Pin) 사이의 의미론적 관련성을 5단계(L1~L5)로 분류하도록 미세 조정했습니다. * **풍부한 특징량(Features) 활용**: 관련성 평가의 정확도를 높이기 위해 핀의 제목과 설명뿐만 아니라 BLIP 이미지 캡션, 링크된 페이지의 제목, 사용자가 저장한 보드 이름, 그리고 해당 핀에 대해 높은 참여도를 보인 쿼리 토큰 등을 텍스트 특징으로 사용합니다. * **효율성과 성능의 균형**: Llama-3-8B 모델이 정확도는 소폭 높았으나, 추론 비용과 속도를 고려하여 30분 내에 15만 건의 데이터를 처리할 수 있는 XLM-RoBERTa-large를 최종 모델로 선택했습니다. ### 계층화된 샘플링(Stratified Sampling)을 통한 측정 민감도 개선 * **샘플링 설계의 진화**: 과거에는 휴먼 레이블링의 비용 문제로 단순 무작위 샘플링(SRS)을 사용했으나, LLM 도입 후에는 쿼리의 인기도와 관심사(Interest)를 기준으로 한 계층화된 샘플링을 도입했습니다. * **분산 감소 및 MDE 최적화**: 쿼리 간의 변동성을 통제하는 계층화된 샘플링과 표본 크기 확대를 통해 MDE를 0.25% 이하로 크게 줄였으며, 이는 실험 시스템의 민감도를 6배 이상 향상시킨 결과로 이어졌습니다. * **이질적 처치 효과(Heterogeneous Treatment Effects) 측정**: 인기도나 특정 주제별로 샘플을 나누어 분석함으로써, 전체 평균 지표에 가려질 수 있는 특정 세그먼트의 검색 품질 변화를 정밀하게 파악합니다. ### 온라인 A/B 테스트와 실험 지표 산출 방식 * **페어링된 쿼리 샘플링**: 대조군(Control)과 실험군(Treatment)에서 동일하게 발생한 쿼리를 페어링하여 샘플링함으로써 쿼리 간의 차이로 인한 변동성을 차단합니다. * **sDCG@K 지표 활용**: 관련성 레이블을 기반으로 sDCG(Scaled Discounted Cumulative Gain)를 계산합니다. 이때 관련성이 높은 문서(L5)가 무한히 공급된다고 가정하는 sDCG 방식을 사용하여 상위 25개 결과의 품질을 측정합니다. * **휴먼 레이블과의 정렬성 검증**: 검증 결과 LLM 레이블과 휴먼 레이블의 완전 일치율은 73.7%에 달하며, 1점 이내 오차 범위까지 포함하면 91.7%의 높은 일치 수준을 보여 모델의 신뢰성을 확보했습니다. 성공적인 검색 시스템 운영을 위해서는 정밀한 측정 도구가 필수적입니다. 핀터레스트의 사례처럼 LLM을 활용해 관련성 평가를 자동화하면, 기존의 비용 한계를 극복하고 더 큰 표본과 정교한 통계적 설계를 통해 미세한 순위 모델의 개선 사항까지도 정확하게 포착할 수 있습니다.

우리가 진짜 문제를 풀고 있었을까? — POPM 과정이 남긴 질문 (새 탭에서 열림)

카카오의 POPM 교육 과정은 단순한 지식 전달을 넘어, 파편화된 실무 개념을 구조적으로 정리하고 이를 반복 가능한 '문제 해결 루프'로 연결하는 데 집중했습니다. 제품 전략이 팀의 일상적인 실행 지침이 되도록 돕는 이 과정은, 단순한 기능 배포가 아닌 '진짜 문제를 해결하고 있는가'라는 본질적인 질문을 실무에 던지게 합니다. 이를 통해 참가자들은 가설 검증과 지표 분석을 바탕으로 한 데이터 중심의 의사결정 체계를 실무에 직접 이식하는 성과를 거두었습니다. **전략적 사고와 지표의 재발견** * 전략을 거창한 구호가 아닌, 실무 현장에서 팀원들이 판단을 내릴 수 있게 돕는 '판단 기준'으로 재정의하고 MECE, MVP 등의 개념을 맥락에 맞게 재구성했습니다. * 지표를 단순한 데이터가 아니라 제품의 문제를 드러내는 '언어'로 인식하며, 퍼널·리텐션·코호트·LTV 등의 지표가 문제 정의와 어떻게 연결되는지 체득했습니다. * '내가 해석하는 지표가 우리 제품의 본질과 맞는가'라는 관점의 전환을 통해 데이터 해석의 정교함을 높였습니다. **실험 설계와 UX의 본질적 접근** * 실험의 성공 여부보다 '실패한 실험을 해석하는 루틴'을 중시하며, MASS 조건(측정 가능성, 기인 가능성, 민감도, 단기 확인)을 통한 구체적인 실험 체크리스트를 활용합니다. * UX 디자인을 단순한 심미적 요소가 아닌 '사용자 맥락에 기반한 설계'로 정의하고, 카카오 내부 서비스의 실제 사례를 통해 적합한 설계를 스스로 질문하게 유도했습니다. * 작게 시작하는 실험의 중요성을 강조하여 실무에서 즉시 가설을 검증해 볼 수 있는 자신감을 배양했습니다. **실무로 이어지는 실행 구조 설계** * '문제 정의 → 가설 → 지표 → 검증 → 회고'로 이어지는 루틴을 확립하여, 릴리스가 끝이 아닌 학습과 다음 우선순위 설정의 시작이 되도록 변화시켰습니다. * 과제 시작 전 '문제 정의, 기대 행동, 확인 지표'를 명문화하는 템플릿을 도입하고, 사용자 스토리 방식을 통해 팀 전체가 업무의 목적을 공유하도록 했습니다. * 주간 또는 격주 단위로 지표 확인 및 인사이트 공유 시간을 고정하여, 실행이 일시적인 이벤트가 아닌 조직의 습관으로 자리 잡게 했습니다. 프로덕트 매니저는 단순히 기능을 배포하는 것에 만족하지 말고, 배포 이후의 지표 변화가 당초 정의한 문제를 실제로 해결했는지 확인하는 '루프 기반 실행' 구조를 조직 내에 안착시켜야 합니다. "지금 우리가 하고 있는 이 일이 정말 문제 해결을 위한 실행인가?"라는 질문을 끊임없이 던지는 것이 제품 성장의 핵심입니다.