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를 그 바깥에 배치하는 방식부터 시작하는 것을 추천합니다.

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

model-serving머신러닝CI/CDPython+4

slack·2026년 5월 28일·4분 읽기큐레이션 요약

Slack AI: 멀티 클라우드로 가는 길

Slack AI는 초기 SageMaker 기반 운영에서 출발해 Amazon Bedrock으로 이전하며, 수동적인 GPU·용량 관리에서 관리형·다중 클라우드 오케스트레이션으로 발전했다. 이 과정의 목표는 단순히 최신 LLM을 도입하는 것이 아니라, GPU 부족과 지역 장애에도 견디면서 엔터프라이즈 수준의 보안·성능·신뢰성을 유지하는 것이었다. 특히 부하 테스트, 품질 비교, 점진적 트래픽 전환을 통해 고객 영향 없이 마이그레이션을 완료한 점이 핵심이다. ## SageMaker 기반 초기 아키텍처 - 2023년 초 Slack은 AWS SageMaker를 LLM 서빙의 출발점으로 선택했다. - SageMaker는 다음 요구사항을 충족했다. - 보안성과 FedRAMP 준수 - 모델 가용성과 제어권 - Escrow VPC를 활용한 제로 지식 환경 - Slack의 데이터는 외부에 노출되지 않았고, 모델 제공업체의 비공개 가중치에도 Slack이 접근할 수 없었다. - 글로벌 가용성을 위해 여러 AWS 리전에 컨테이너를 배포했다. - 운영팀은 리전 간 IAM 역할, 모델 엔드포인트 라우팅, 용량 계획, 자동 확장을 직접 관리해야 했다. ## 자체 운영에서 발생한 비용 - **확장 지연** - 인스턴스 초기화 시간이 길어 즉각적인 확장이 어려웠다. - **GPU 부족** - A100, H100 같은 고성능 NVIDIA GPU를 필요한 시점에 확보하기 어려웠다. - **과잉 프로비저닝** - 피크 시간대 SLA를 맞추기 위해 유휴 리소스를 미리 확보해야 했다. - 2024년 초에는 On-Demand Capacity Reservations와 cron 기반 사전 확장으로 문제를 완화했지만, 엔지니어링 리소스가 인프라 조정 업무에 과도하게 투입됐다. - 결국 Slack은 수동 조정이 아니라 자동화된 용량 확보가 필요하다고 판단했다. ## SageMaker의 모델 출시 지연 - AWS가 관리형 LLM 서비스인 Bedrock을 우선적으로 발전시키면서, SageMaker 기반 커스텀 서빙 환경은 최신 모델 도입에서 뒤처지기 시작했다. - Escrow VPC에서 Anthropic 모델을 호스팅하는 방식은 Bedrock보다 모델 업데이트와 최적화 적용이 수주에서 수개월 늦었다. - AI 기능 품질이 경쟁력과 직결되는 Slack에는 이러한 지연이 큰 문제가 됐다. ## Amazon Bedrock으로의 전환 - 2024년 중반 Slack은 FedRAMP Moderate 인증과 필요한 보안 수준을 갖춘 Bedrock으로 이전했다. - 전환의 주요 이점은 다음과 같다. - 개별 GPU 인스턴스와 엔드포인트를 직접 확장하지 않아도 되는 운영 단순화 - 최신 모델을 공개 직후 빠르게 사용 가능 - 사용 패턴에 따른 비용·용량 최적화 - 예측 가능하고 지연 시간에 민감한 채널 요약에는 **Provisioned Throughput(PT)**를 사용했다. - 간헐적이고 예약 실행되는 Recap 작업에는 **On-Demand(OD)**를 사용해 유휴 용량 비용을 줄였다. ## Model Unit 기반 용량 관리 - Bedrock의 용량은 GPU 인스턴스가 아니라 **Model Unit(MU)**로 측정된다. - 각 MU는 분당 토큰 수로 표현되는 일정한 처리량을 제공한다. - Slack은 하드웨어 세부사항 대신 필요한 토큰 처리량에 집중할 수 있게 됐다. - 마이그레이션 위험을 줄이기 위해 먼저 Provisioned Throughput 환경을 이전하고, On-Demand 환경은 후속 단계로 진행했다. ## 무중단 마이그레이션 전략 - **규정 준수 검토** - Legal, Security, FedRAMP 승인을 받은 뒤 운영 트래픽을 전환했다. - **용량 검증** - 다양한 트래픽 패턴에서 SageMaker와 동일한 성능을 내는 MU 수를 부하 테스트로 산정했다. - **품질 비교** - A/B 테스트와 평가 프레임워크로 모델 출력 품질과 지연 시간을 나란히 비교했다. - **점진적 롤아웃** - 기능 플래그를 사용해 트래픽을 단계적으로 이동했다. - 문제가 발생하면 즉시 이전 환경으로 롤백할 수 있도록 구성했다. - 대규모 부하 테스트와 shadow request를 통해 기존 환경과의 성능 패리티를 확인했고, 고객에게 영향을 주는 장애 없이 전환을 완료했다. ## Bedrock 도입 이후의 운영 개선 - 엔지니어들은 GPU 수명주기, 엔드포인트 관리, 용량 예약 대신 모델 성능과 기능 품질에 집중할 수 있게 됐다. - 최신 모델을 더 빨리 적용하면서 AI Search에 고도화된 추론 모델을 신속히 도입했고, 더 정교하고 맥락에 맞는 답변을 제공할 수 있었다. - 인프라 운영은 다음과 같이 단순화됐다. - Slack이 필요한 quota를 요청 - AWS가 MU를 프로비저닝 - Slack이 해당 용량으로 트래픽을 처리 - 수요가 발생한 뒤 대응하는 방식에서, 몇 주 앞을 내다보고 용량을 예약하는 전략적 예측 방식으로 전환했다. - Slack이 강조한 운영 원칙은 **먼저 측정하고, 점진적으로 이전하며, 지속적으로 모니터링하는 것**이다. ## 남은 효율성 문제 - Provisioned Throughput은 안정적이고 예측 가능한 워크로드에는 효과적이었지만 모든 트래픽에 최적은 아니었다. - 미국 동부·서부 지역의 업무 시작 시간처럼 특정 시간대에 AI 요약과 검색 요청이 급증하는 패턴을 처리하려면 높은 MU 기본 용량을 유지해야 했다. - 그 결과 피크 시간대 성능을 보장하는 대신, 사용량이 낮은 시간에는 일부 용량이 유휴 상태로 남는 과잉 프로비저닝 문제가 여전히 존재했다. ## 실용적인 결론 LLM 인프라를 확장할 때는 직접 GPU를 운영하는 것보다 관리형 서비스가 모델 접근성과 운영 효율을 크게 높일 수 있다. 다만 서비스 이전은 단순한 엔드포인트 교체가 아니라, 부하·품질·규정 준수 검증과 점진적 롤백 체계를 포함한 통제된 마이그레이션으로 진행해야 한다.

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

model-serving대규모 언어 모델gpuaws-bedrock+3

netflix·2026년 5월 1일원문

모델 서빙의 라우팅 현황 (새 탭에서 열림)

넷플릭스는 대규모 개인화 경험을 제공하기 위해 수백 개의 모델과 초당 100만 건의 요청을 처리하는 중앙 집중식 머신러닝(ML) 모델 서빙 플랫폼을 운영하고 있습니다. 이 플랫폼은 'Switchboard'라는 라우팅 계층을 통해 클라이언트 마이크로서비스와 복잡한 ML 모델 인프라를 분리하여, 클라이언트의 수정 없이도 새로운 모델을 신속하게 실험하고 배포할 수 있는 환경을 구축했습니다. 이를 통해 넷플릭스는 모델 추론뿐만 아니라 데이터 전처리 및 특징 추출을 포함한 전체 워크플로우를 표준화된 API로 추상화하여 혁신의 속도를 높이고 있습니다. ### 넷플릭스의 워크플로우 중심 모델 정의 * 넷플릭스에서 모델은 단순한 추론 함수(`score(features)`)를 넘어, 입력 데이터 변환, 특징(feature) 계산, 추론, 후처리를 모두 포함하는 독립적인 '워크플로우'로 정의됩니다. * 클라이언트는 사용자 ID나 국가와 같은 최소한의 컨텍스트만 제공하며, 모델 서빙 플랫폼이 필요한 데이터를 다른 마이크로서비스에서 가져와 직접 특징을 계산합니다. * 이러한 구조 덕분에 클라이언트는 모델의 내부 로직이나 데이터 의존성을 알 필요가 없으며, 모델의 아키텍처가 변하더라도 클라이언트 코드를 수정할 필요가 없습니다. ### 중앙 집중형 라우팅 엔진, Switchboard * 넷플릭스는 표준 API 게이트웨이나 서비스 메시가 제공하지 못하는 실험 플랫폼과의 통합, gRPC 지원, 도메인 특화 라우팅을 구현하기 위해 자체 프록시 서비스인 'Switchboard'를 개발했습니다. * Switchboard는 클라이언트 요청을 적절한 모델 인스턴스와 클러스터 샤드로 전달하는 역할을 수행하며, 초당 100만 건 이상의 요청을 처리하면서도 높은 가용성을 유지합니다. * 모델 배포 시 섀도 모드(Shadow mode), 카나리 배포(Canary), 롤백 등을 클라이언트 모르게 수행할 수 있어 안전한 운영이 가능합니다. ### 인프라 복잡성을 감추는 모델 샤딩 분리 * 모델은 트래픽 패턴, SLA, CPU/메모리 요구사항에 따라 여러 연산 클러스터 샤드(VIP 주소)에 분산 배치됩니다. * 서빙 플랫폼은 이러한 물리적 배치 상태를 클라이언트로부터 은폐하여, 인프라의 변경이나 모델의 샤드 이동이 클라이언트 서비스에 영향을 주지 않도록 설계되었습니다. * 이를 통해 ML 연구자는 인프라 제약 없이 자유롭게 실험을 설계하고 모델을 배포할 수 있습니다. ### 'Objective' 기반의 추상화 계층 * 플랫폼은 'Objective'라는 열거형(Enum) 단위를 통해 모든 요청을 관리하며, 이는 비즈니스 목적(예: 콘텐츠 추천, 결제 사기 탐지)을 나타냅니다. * Objective는 요청이 전달될 특정 서빙 클러스터와 모델 유형/버전을 결정하는 기준이 됩니다. * 또한, 각 Objective는 고유한 API 규격을 정의하여 서로 다른 도메인의 클라이언트가 동일한 방식으로 플랫폼과 통신할 수 있도록 표준화합니다. 성공적인 대규모 ML 시스템을 구축하려면 모델의 생명주기를 클라이언트 애플리케이션으로부터 완전히 격리해야 합니다. 넷플릭스의 사례처럼 워크플로우 단위의 모델 정의와 'Objective' 중심의 라우팅 추상화를 도입함으로써, 인프라의 복잡성을 관리하면서도 머신러닝 혁신의 속도를 극대화할 수 있습니다.

model-serving데이터베이스 설계머신러닝PostgreSQL+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 챌린지 설계의 기준이 될 것으로 보입니다.

model-servingAI머신러닝feature-engineering+4