coupang-eng

문제쿠팡은 한국어·중국어 다국어 콘텐츠 처리와 대규모 LLM 학습·추론을 동시에 풀어야 했고, GPU 공급 부족과 디바이스 메모리 제약이 학습·서빙 양쪽에서 큰 병목이었다.

접근Qwen·LLaMA·T5 등 3B~20B 규모 오픈소스 모델을 골라 DeepSpeed Zero 로 모델 병렬화하고, 클라우드와 온프레미스를 묶은 다중 리전 GPU 클러스터를 구성했다. 실시간 추론은 NVIDIA Triton, 배치 추론은 Ray 와 vLLM 으로 운영하며 in-context learning·RAG·SFT·continued pre-training 을 함께 활용한다.

결과vLLM 도입으로 추론 처리량이 약 20배 늘었다. 이미지-텍스트 결합 모델로 임베딩 품질을 끌어올리고, 약한 라벨 자동 생성과 다중 카테고리 통합 분류기로 라벨 부족·운영 비용 문제를 함께 해결했다.

문제쿠팡은 ML 모델 개발부터 배포까지 시간이 길고 인프라 설정이 복잡하며 GPU 자원이 부족해 빠른 실험이 어려웠다.

접근관리형 Jupyter, 파이프라인 SDK, Feast 기반 피처 스토어, Seldon 모델 서빙, 분산 학습을 통합한 ML 플랫폼을 온프레미스와 AWS 하이브리드로 구축했다.

결과1년 동안 600개 이상의 ML 프로젝트에서 10만 건 이상의 워크플로를 실행했고 Ko-BERT 학습 속도가 10배 빨라졌으며 배포 기간이 수주에서 며칠로 줄었다.

문제쿠팡 내부에서 ML 모델을 운영에 올리기까지 수 주가 걸리고 GPU 활용도 떨어지며 팀마다 인프라가 중복됐다.

접근통합 ML 플랫폼을 만들어 관리형 Jupyter notebook, 파이프라인 SDK, 표준 Docker 이미지(TensorFlow/PyTorch)를 제공한다. Feast 기반 feature store, Kubernetes 분산 학습, Seldon 모델 서빙으로 학습부터 배포까지 연결한다.

결과연간 10만 건 이상의 워크플로우와 600개 넘는 ML 프로젝트가 플랫폼 위에서 돌아간다. BERT 학습은 A100 GPU 기준 10배 빨라지고 배포 기간은 수 주에서 수 일로 줄어든다.

문제텍스트 주소와 우편번호 기반의 배송 영역 관리로는 배송량 증가에 맞춘 세분화·시각화·통계가 어려웠다.

접근Uber의 H3 육각형 공간 색인을 도입해 한반도를 14레벨 6.3㎡ 해상도 육각형으로 분할하고, 압축과 polyfill로 다각형을 육각형 집합으로 변환해 저장한다.

결과지도 기반 직관 편집과 MECE한 영역 관리, 공간 기반 통계가 가능해져 배송 난이도 평가와 경로 추천 같은 고도 분석까지 확장한다.

문제텍스트 주소와 우편번호에 의존하던 배송 영역 관리로는 단일 우편번호 구역의 일일 수백 건 배송을 감당하기 어려웠다.

접근Uber H3 공간 색인을 도입해 한국 전역을 14레벨 6.3㎡ 육각형으로 분할하고, 압축 함수와 polyfill로 약 21억 개 육각형을 효율적으로 저장·변환했다.

결과우편번호와 독립된 공간 통계와 동적 구역 관리, 최적 경로 추천이 가능해져 배송 운영의 정밀도가 올랐다.

문제클라우드 사용량 급증으로 비용이 계속 늘었지만, 엔지니어링 팀은 효율적인 사용법을 모르고 재무팀은 비용을 추적하기 어려웠다.

접근인프라 엔지니어와 TPM이 모인 전담팀이 "덜 쓰기"와 "덜 지불하기"를 병행한다. 비-프로덕션 자동 종료, EC2 세대 업그레이드, EMR 스팟 인스턴스, EBS GP3 전환, S3 Intelligent-Tiering으로 50PB 이상을 이관했다.

결과2021년 온디맨드 기준 수백만 달러를 절감하고 클라우드 FinOps 문화와 모니터링 자동화로 확장한다.

문제엔지니어링 팀의 클라우드 지출이 통제되지 않고 재무·리더십이 비용을 추적하지 못하는 상황이 누적됐다.

접근중앙팀이 CloudWatch+Athena 대시보드로 분석 기반 의사결정을 도입하고, AMD/ARM 인스턴스 마이그레이션, EMR Instance Fleets, EBS GP3, S3 Intelligent-Tiering으로 50PB 이상을 이관했다.

결과2021년 온디맨드 기준 수백만 달러를 절감하고 FinOps 문화 정착과 자동화 확장을 계획한다.

문제쿠팡 풀필먼트 센터의 도크 슬롯이 한정되어 입고 트럭 수 예측 오차로 자원 낭비와 입고 지연이 발생했다.

접근약 80만 건 입고 데이터에 LightGBM을 적용하고 베이지안 최적화로 하이퍼파라미터를 튜닝했다. AWS SageMaker로 배포해 예약 시스템과 연동했다.

결과과소 예측률이 8.71%에서 2.53%로, 과다 예측률이 44.45%에서 5.04%로 줄었다. 입고일 변경 사례도 67.9% 감소했다.

문제풀필먼트 센터의 한정된 도크 자원을 효율적으로 쓰려면 입고 트럭 수를 정확히 예측해야 하는데, 벤더 직접 예측은 과다 44.45%, 과소 8.71%로 오차가 컸다.

접근2년치 80만 건 입고 데이터에 LightGBM을 학습시키고 베이지안 최적화로 튜닝했다. AWS SageMaker에 배포해 예약 시스템과 통합했다.

결과과소 예측률 2.53%, 과다 예측률 5.04%로 크게 개선했고 입고 일정 변경 사례를 67.9% 줄였다.

문제쿠팡 SCM 팀은 개발자, 비즈니스 분석가, 데이터 사이언티스트가 협업하며 데이터 접근과 시스템 구축에 비효율을 겪었다.

접근Redshift·Hive·Presto에 코드 없이 접근하는 no-code 데이터 빌더와, 드래그 앤 드롭 캔버스로 서비스 컴포넌트를 연결하는 low-code 서비스 빌더를 만들었다.

결과비개발자도 데이터 작업과 서비스를 직접 구축하게 되어 팀 간 커뮤니케이션 비용이 줄고 개발자는 핵심 알고리즘에 집중하게 됐다.