toss·2026년 8월 3일·4분 읽기큐레이션 요약

DS와 MLE가 함께 일하는 법

토스뱅크는 DS와 MLE 사이의 역할 경계를 사람이나 파일이 아닌 명시적인 인터페이스로 정의하면서 ML 모델 배포 협업을 개선했습니다. 노트북 전달 방식에서 `.py` 파일 공유를 거쳐, 전처리·추론·후처리를 구현한 모델 패키지를 `pip install`로 배포하는 구조로 발전했습니다. 여기에 모노레포, 공통 추상화, CI, AI 코딩 스타일 규칙을 결합해 배포 속도와 일관성을 높였습니다. ## 노트북 전달 방식의 한계 - Phase 0에서는 DS가 주피터 노트북에서 학습과 추론 코드를 모두 작성하고, MLE가 이를 바탕으로 서빙 코드를 처음부터 다시 작성했습니다. - 라이브러리, 설정 파일, 소스 코드가 흩어져 있어 실행 환경을 재현하기 어려웠습니다. - 노트북에서 동작하던 전처리나 설정을 MLE가 다르게 해석하는 문제가 발생했습니다. - 모델 수가 늘어날수록 파일 요청과 커뮤니케이션 비용이 크게 증가했습니다. - 역할의 경계가 코드가 아니라 사람 사이에 있었기 때문에 책임과 작업 범위가 불명확했습니다. ## `.py` 파일로 추론 로직 분리 - Phase 1에서는 DS가 노트북에서 핵심 추론 로직을 별도의 `.py` 파일로 분리했습니다. - 노트북은 학습과 실험에 집중하고, 실제 모델 로직은 코드 파일로 관리했습니다. - MLE 리뷰와 CI 검증을 거치도록 하면서 DS의 의도를 더 정확히 보존할 수 있었습니다. - 그러나 모델마다 함수 이름이 `predict()`, `run()`, `inference()` 등으로 달라 인터페이스가 통일되지 않았습니다. - 서빙 환경으로 코드를 옮길 때 환경 차이로 수정이 필요했고, 로깅·메트릭·에러 처리를 공통으로 적용하기도 어려웠습니다. - 노트북에서 전역 설정을 변경한 코드가 여러 모델이 실행되는 서빙 프로세스에 영향을 주는 문제도 있었습니다. ## 인터페이스를 통한 역할 분리 - Phase 2에서는 `commons-ml-model` 패키지에 모델의 표준 구조를 정의했습니다. - 추상화 클래스가 다음 세 가지 인터페이스를 제공합니다. - `pre_process`: 입력 데이터 전처리 - `inference`: 모델 추론 - `post_process`: 결과 후처리 - DS는 위 메서드의 구현체를 작성하고 모델을 하나의 패키지로 배포합니다. - MLE는 해당 패키지를 설치해 서비스에 연결하므로 코드를 직접 복사하거나 재작성하지 않습니다. - 추상화 클래스가 추론 전후에 공통으로 다음 기능을 처리합니다. - 요청 추적을 위한 `trace_id` - 추론 시작·완료 로그 - 실행 시간 측정 - 메트릭 기록 - 결과적으로 DS는 모델 동작에 집중하고, MLE는 서비스 인프라와 운영 기능을 담당하게 됐습니다. - 공통 관측 기능을 추상화 클래스 한 곳에서 수정하면 모든 모델에 일괄 적용할 수 있습니다. ## 모노레포와 `uv` 워크스페이스 - 여러 모델 패키지와 공통 추상화 패키지를 하나의 저장소에서 관리했습니다. - `uv` 워크스페이스를 사용해 DS와 MLE가 같은 코드베이스에서 작업하고 리뷰할 수 있도록 했습니다. - 공통 인터페이스 변경과 모델 패키지 수정이 하나의 PR에서 함께 이뤄졌습니다. - CI, 버전 관리, 배포 정책을 저장소 단위로 통일할 수 있었습니다. - 공통 패키지 변경이 모든 모델에 영향을 줄 수 있다는 위험도 존재합니다. - 모델과 패키지가 늘면서 빌드가 느려졌고, Poetry에서 `uv`로 전환해 빌드 속도를 약 3~5배 개선했습니다. ## AI 시대의 코드 스타일 통일 - AI가 코드를 작성하면서 같은 기능도 예외 처리, 네이밍, enum 사용 방식 등이 사람마다 달라지는 문제가 생겼습니다. - 인터페이스가 같더라도 코드의 세부적인 작성 방식이 달라 리뷰 비용이 증가했습니다. - 팀 규칙 모음인 `pfmls-stylepack`을 도입해 AI가 코드 작성 단계부터 팀 컨벤션을 따르도록 했습니다. - Hook을 활용해 네이밍, 예외 처리, 고정값과 enum 사용 기준 등을 자동 적용했습니다. - 규칙이 적용된 코드에는 그 이유를 표시해 리뷰어가 변경 의도를 쉽게 파악하도록 했습니다. - 협업 표준을 두 층위로 나눴습니다. - 구조 표준화: 인터페이스로 담당 범위와 코드 형태 통일 - 스타일 표준화: 컨벤션으로 구현 방식과 코드 결 통일 ## 도입 과정에서 얻은 교훈 - 인터페이스는 너무 엄격하면 DS의 모델별 커스터마이징을 막고, 너무 느슨하면 다시 구현 방식이 제각각이 될 수 있습니다. - 초기에는 가이드 문서를 제공하고 DS와 MLE가 첫 모델을 페어로 함께 만드는 방식이 효과적입니다. - 공통 라이브러리는 한 번의 수정으로 전체 모델에 개선을 적용할 수 있지만, 반대로 전체 모델에 장애를 전파할 수도 있습니다. - 기존 모델 패키지를 참고 코드로 제공하면 새로운 구성원의 러닝 커브를 줄일 수 있습니다. - AI 활용이 늘어날수록 기능의 책임뿐 아니라 코드 작성 방식까지 명시적으로 관리해야 합니다. 실무적으로는 모델 배포 과정에서 “누가 무엇을 한다”를 문서로만 정의하기보다, 추상화 클래스와 패키지 구조로 강제하는 것이 효과적입니다. 먼저 전처리·추론·후처리 같은 최소 인터페이스를 정하고, 공통 로깅·메트릭·CI를 그 바깥에 배치하는 방식부터 시작하는 것을 추천합니다.

원문 읽기(새 탭에서 열림)

머신러닝CI/CDPythonAPI 설계+4

toss·2026년 6월 16일·4분 읽기큐레이션 요약

2,800만 MAU를 이해하는 유저 Segmentation, TUES

토스의 TUES(Toss User Engagement Segment)는 유저의 서비스 이용 패턴을 기반으로 전체 MAU를 서로 겹치지 않게 분류하는 플랫폼 관점의 세그먼트다. V1은 앱 오픈 시 서비스 이용 확률과 K-Means를 활용했지만, 이용 깊이와 복합적인 서비스 사용 패턴을 충분히 반영하지 못했다. V2는 이용 횟수, Soft Clustering, 서비스별 관여도를 도입해 유저의 현재 상태와 다음 성장 액션을 더 정교하게 파악할 수 있도록 개선됐다. ### 플랫폼 관점의 유저 세그먼테이션이 필요한 이유 - 서비스별로 “A 서비스를 이용한 유저”, “B 서비스를 이용한 유저”를 따로 분류하면 한 유저가 여러 그룹에 중복 포함된다. - 플랫폼 전체 유저를 분석하려면 서로 겹치지 않으면서 전체를 포괄하는 MECE한 분류 체계가 필요하다. - TUES는 유저가 어떤 서비스를 주로 이용하고, 토스 앱을 어떤 목적과 패턴으로 사용하는지 파악하기 위한 도구다. ### TUES V1: 서비스 이용률 기반 분류 - 유저가 앱을 열 때마다 각 서비스를 이용할 확률을 계산했다. - 예: 한 달간 앱을 60회 열고 토스페이를 20회 이용하면 이용률은 33%다. - 서비스별 이용률 분포가 비슷한 유저를 K-Means Clustering으로 묶었다. - 머신러닝 결과를 그대로 사용하지 않고, 주요 서비스와 특징을 분석해 비즈니스와 제품 관점에서 이해하기 쉬운 세그먼트로 재구성했다. - 주요 세그먼트는 다음과 같다. - **고관여**: 여러 서비스를 높은 수준으로 이용하는 유저 - **서비스 지향군**: 토스뱅크, 토스증권, 조회, 혜택, 송금 등 특정 서비스를 주로 이용하는 유저 - **단순 방문**: 앱은 방문하지만 서비스를 거의 이용하지 않는 유저 ### TUES의 주요 활용 - **세그먼트 전환 전략 수립** - 세그먼트별 Retention 차이를 바탕으로 이탈을 줄이고 다음 단계로 이동시키는 전략을 세운다. - 단순 방문 유저를 서비스 지향 유저로, 서비스 지향 유저를 고관여 유저로 전환하는 흐름을 분석한다. - **제품 Growth 전략** - 각 제품의 주요 사용자가 어떤 TUES 세그먼트에 속하는지 파악해 성장 전략을 설계한다. - **유저 행동 분석** - 세그먼트가 언제, 어떤 계기로 바뀌는지 분석할 수 있다. - 이탈 유저, 부활 유저, 서비스 간 이동 패턴도 플랫폼 관점에서 확인할 수 있다. - **탑라인 지표 분석** - 전사 MAU가 변했을 때 어떤 세그먼트가 증감했는지 확인해 변화의 원인이 된 서비스를 추적한다. - 유저 단위로 MAU 증감 원인을 MECE하게 분석할 수 있다. - **타겟 마케팅** - 서비스별 상황에 적합한 세그먼트를 선정해 푸시 등 마케팅에 활용한다. - 토스의 마케팅 도구 TUBA에도 기본 세그먼트로 제공돼 마케터가 쉽게 사용할 수 있다. ### TUES V1의 한계 - **이용 깊이를 반영하지 못함** - 앱 오픈당 서비스를 한 번 이용한 유저와 여러 번 이용한 유저가 동일하게 취급됐다. - **다른 서비스의 관여도를 파악하기 어려움** - 같은 조회서비스 지향 유저라도 혜택서비스를 함께 이용하는 정도가 다르지만 이를 표현하지 못했다. - **한 유저를 하나의 세그먼트로만 분류** - Hard Clustering 방식이라 여러 서비스를 동시에 사용하는 유저의 복합성을 담기 어려웠다. - **신규 핵심 서비스 반영 부족** - 토스쇼핑, 앱인토스, 토스페이 등 새 서비스가 기존 분류에서 ETC로 처리됐다. ### TUES V2의 개선 방식 - **이용률에서 이용 횟수 기반으로 변경** - 서비스별 이용 횟수를 앱 오픈 횟수당 Feature로 사용해 서비스 이용의 깊이를 반영했다. - **Soft Clustering 도입** - 유저를 하나의 세그먼트에 고정하지 않고 여러 세그먼트에 대한 소속 정도를 계산한다. - 여러 서비스를 함께 사용하는 유저의 복합적인 이용 패턴을 표현할 수 있다. - **세 단계 세그먼트 구조 적용** - 서비스별 관여도 - 전체 앱 관여도 - 주 이용 서비스 - 이 구조를 통해 유저가 특정 세그먼트에 속한 이유를 더 상세히 설명하고, 다음 행동(Next Action)을 구체적으로 설계할 수 있게 됐다. ### V2로 가능해진 분석 - 예를 들어 “준고관여·혜택서비스 지향 유저가 고관여로 이동하려면 어떤 서비스 관여도를 먼저 높여야 하는가?”를 분석할 수 있다. - 서비스별 관여도가 Cross Activation 전략의 출발점이 된다. - 각 서비스 조직(Silo)은 자신의 서비스 관여도를 높이는 활동이 전사 세그먼트와 성과에 미친 영향을 정량적으로 추적할 수 있다. - 서비스 이용자와 미이용자의 관여도 수준을 비교해 제품 Growth 전략의 우선순위를 정할 수 있다. ### 향후 발전 방향 - 서비스 유사도 등을 활용해 세그먼트 전환 전략을 빠르게 도출하는 분석 프레임워크 구축 - 유저 프로파일과 서비스 이용 패턴을 결합한 전략적 유저 맵 개발 - MTVi 등 다른 분석 프레임워크와 결합해 세그먼트별 서비스 가치를 정량화 TUES의 핵심은 단순한 유저 분류가 아니라, “현재 어떤 유저인지”와 “어떤 액션을 통해 다음 단계로 이동시킬지”를 연결하는 데 있다. 플랫폼 서비스에서는 서비스별 지표만 따로 보기보다, 전체 관여도와 서비스 간 이용 패턴을 함께 분석하는 세그먼트 체계를 구축하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

머신러닝data-analyticssoft-clusteringuser-segmentation+4

toss·2026년 4월 23일원문

토스플레이스 데이터봇 ‘판다(PANDA)’를 소개합니다 : 모든 팀원이 데이터 전문가처럼 일하는 방법 (새 탭에서 열림)

토스플레이스는 데이터 분석가에게 집중된 단순 추출 요청을 해결하고 전사적인 데이터 민주주의를 실현하기 위해 AI 데이터 분석 어시스턴트 ‘판다(PANDA)’를 개발했습니다. 판다는 단순한 챗봇을 넘어 표준 데이터 마트 정비와 에이전트 기반의 자율 루프 시스템을 통해 데이터 조회부터 실무 인사이트 제공까지 수행하며, 출시 후 전사 구성원의 70%가 활용하는 필수적인 도구로 자리 잡았습니다. 기술적 복잡함보다 비즈니스 맥락과 데이터 거버넌스에 집중함으로써, 누구나 데이터 분석가의 도움 없이도 정확한 의사결정을 내릴 수 있는 환경을 구축했다는 데 큰 의의가 있습니다. ### 데이터 신뢰성을 위한 표준 데이터 마트(SSOT) 구축 * AI가 일관된 답을 낼 수 있도록 Data Analysis와 Platform 팀이 협업하여 핵심 데이터를 단일화된 테이블로 정비했습니다. * **표준 네이밍 컨벤션:** 테이블명은 `{역할}_{도메인}_{주제}`(예: fact_device_error_log)로, 컬럼명은 `{접두어}_{대상}_{속성}_{접미어}`(예: is_merchant_active)로 규칙화하여 AI가 이름만으로도 데이터의 목적을 이해하게 했습니다. * 모든 테이블과 컬럼에 상세 설명을 추가하여 AI가 데이터를 정확하게 탐색할 수 있는 기반 정보를 제공했습니다. ### 데이터 선택의 정확도를 높이는 Scoring & Ranking 시스템 * 질문에 대해 매번 다른 테이블을 선택하는 문제를 방지하기 위해 유사도와 신뢰도를 결합한 점수 체계를 도입했습니다. * **최종 점수 산출:** `(질문-테이블 유사도) × (데이터 계층 가중치)` 공식을 적용합니다. * **계층별 가중치:** 전사 주요 지표(SSOT)는 4배, 검증된 표준 마트는 3배, 도메인 마트는 2배, 원시 로그 데이터는 1배의 가중치를 부여하여 가장 신뢰할 수 있는 소스를 우선 선택하게 합니다. * dbt tags를 활용해 관리되는 테이블만 Manifest 파일로 가져와 탐색 범위를 최적화했습니다. ### 비즈니스 맥락 연결과 에이전틱 루프(Agentic Loop) * ‘설치 매장’이나 ‘업종 분류’와 같은 비즈니스 용어 정의를 데이터 구조와 연결하여 AI가 단순 수치 이상의 맥락을 파악하도록 설계했습니다. * AI가 스스로 상황에 맞는 도구를 선택하고, 결과가 부정확할 경우 스키마를 다시 확인하여 쿼리를 수정 및 재실행하는 자율적 재시도 과정을 거칩니다. * '테이블 탐색 → 쿼리 실행 → 결과 검증 → 수정 → 최종 결과 도출'의 과정을 반복하며 정답률을 높이는 구조를 갖췄습니다. ### 실무 활용성을 고려한 답변 구조 및 성과 * 단순 숫자 나열이 아니라 **결과, 조회 기준, 실무 인사이트**라는 3단계 구조로 답변을 제공하여 사용자의 해석 시간을 단축했습니다. * 출시 직후 전체 팀원의 절반 이상이 사용했으며, 현재는 70%의 사용률을 기록하며 데이터 요청에 대한 심리적 문턱을 낮추고 실질적인 업무 방식의 변화를 이끌어냈습니다. * 개발자, 기획자 등 비데이터 직군에서도 활발히 사용하며 데이터 분석가의 리소스를 고부가가치 분석 업무에 집중할 수 있도록 지원합니다. 성질 급한 AI 모델의 성능에만 의존하기보다, **데이터의 표준화와 비즈니스 로직의 명확한 정의(Governance)**가 선행될 때 비로소 실효성 있는 AI 서비스가 완성된다는 점을 시사합니다. 사내 데이터 민주화를 고민한다면, 기술적 기교 이전에 AI가 읽기 좋은 데이터 환경을 만드는 것부터 시작할 것을 추천합니다.

머신러닝AI데이터베이스 설계sql+4

toss·2025년 12월 22일원문

토스의 AI 기술력, 세계 최고 권위 NeurIPS 2025에서 인정받다: FedLPA 연구 (새 탭에서 열림)

토스는 데이터 주권 문제를 해결하면서도 미지의 데이터를 효과적으로 학습할 수 있는 새로운 연합학습 알고리즘 'FedLPA'를 개발하여 세계 최고 권위의 AI 학회인 NeurIPS 2025에 게재했습니다. 이 기술은 국가별로 상이하고 라벨이 부족한 현실 세계의 데이터 분포를 클라이언트 스스로 파악하여 모델을 최적화함으로써, 개인정보를 보호하는 동시에 글로벌 서비스의 정확도를 획기적으로 높입니다. 이를 통해 토스는 규제 리스크 없는 글로벌 진출과 초개인화된 금융 서비스 제공을 위한 독보적인 기술적 토대를 마련했습니다. ### 연합학습의 도입 배경과 기존 기술의 한계 - **데이터 주권과 보안**: '페이스페이'와 같은 서비스가 해외에 진출할 때, 현지 법령에 따라 생체 데이터를 국외로 반출할 수 없는 문제를 해결하기 위해 데이터를 서버로 모으지 않고 기기 내에서 학습하는 연합학습(Federated Learning)이 필수적입니다. - **데이터 불균형(Non-IID)**: 기존 연합학습은 모든 사용자의 데이터 분포가 유사하다고 가정하지만, 실제로는 국가나 지역별로 얼굴형, 조명, 결제 패턴 등이 판이하게 달라 성능이 저하되는 한계가 있습니다. - **미지 범주 대응 불가**: 서비스 운영 중 발생하는 새로운 인종적 특성이나 신종 부정 결제 패턴(Novel Class)을 기존 기술은 '알고 있는 범주'로만 분류하려다 보니 새로운 변화에 유연하게 대응하지 못했습니다. ### FedLPA의 3단계 혁신 파이프라인 - **신뢰도 기반 로컬 구조 발견(CLSD)**: 단순히 이미지 특징을 비교하는 수준을 넘어, 모델이 확신하는 데이터(High-confidence)의 예측 결과를 활용해 데이터 간의 유사도 그래프를 정교하게 구축하고 정제합니다. - **인포맵 클러스터링(InfoMap)**: 사람이 범주의 개수를 미리 정해주지 않아도, 그래프 내에서 데이터들이 자연스럽게 뭉치는 커뮤니티를 찾아내는 알고리즘을 통해 클라이언트가 스스로 데이터 내의 범주 개수를 파악합니다. - **로컬 사전 확률 정렬(LPA)**: 모델의 예측 결과 분포가 앞서 파악한 실제 데이터의 분포(Empirical Prior)와 일치하도록 강제하는 정규화 과정을 거칩니다. 이를 통해 특정 클래스에 데이터가 쏠려 있어도 모델이 편향되지 않고 균형 잡힌 학습을 수행할 수 있습니다. ### 기술 도입에 따른 비즈니스 기대 효과 - **글로벌 진출 가속화**: 각국의 금융 및 개인정보 규제를 준수하면서도 현지 데이터를 활용한 고성능 모델을 구축할 수 있어, 기술적 진입 장벽 없이 동남아나 유럽 등 글로벌 시장에 빠르게 안착할 수 있습니다. - **초개인화 금융 서비스**: 개별 사용자의 로컬 환경과 특이 패턴을 실시간으로 학습하여, 이상거래탐지(FDS)의 정확도를 높이고 국가별 특수성을 반영한 정교한 신용평가(CSS) 모델을 운영할 수 있습니다. - **운영 효율 극대화**: 새로운 유형의 데이터가 등장할 때마다 사람이 직접 라벨링하고 재학습시키는 과정을 줄여주며, AI가 스스로 새로운 패턴을 감지하고 학습하므로 모델 업데이트 주기와 운영 비용을 획기적으로 단축합니다. FedLPA는 데이터 보안과 모델 성능이라는 상충하는 목표를 동시에 달성함으로써 AI 기술의 실질적인 비즈니스 적용 가능성을 입증했습니다. 데이터 규제가 엄격한 글로벌 환경이나 사용자마다 데이터 특성이 극명하게 다른 금융 도메인에서 AI 서비스를 운영하고자 한다면, FedLPA와 같은 자가 학습 기반의 연합학습 구조를 적극적으로 검토할 것을 권장합니다.

머신러닝AIcomputer-visiondata-privacy+5

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 챌린지 설계의 기준이 될 것으로 보입니다.

머신러닝AIfeature-engineeringxgboost+4