네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2024(10월)에서 발표되었던 세션을 공개합니다. 발표 내용Windows만 지원하던 기존 C++ 프로젝트를 Bazel을 활용하여 Android 및 iOS 타겟으로 포팅한 경험을 공유합니다.목차Bazel을 선택한 이유 Bazel을 활용한 모바일 포팅 과정 Bazel을 써보고 느낀 장단점 ◎ NAVER ENGINEERING DAY란?NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2024(10월)의 일부 세션을 공개합니다.

안녕하세요, 리디의 데이터사이언스 팀장 이유원입니다. 오늘은 리디의 데이터사이언스팀에서 사용하고 있는 머신러닝 파이프라인을 소개 드리려 합니다. 최근 MLOps(Machine Learning Operation)라는 이름으로 새로운 기술이 속속 발표되고 있는데요. 그만큼 머신러닝 기술이 다양한 산업군에 걸쳐 널리 사용되고 있는 것 같습니다.하지만 이렇게 다양한 MLOps 기술들이 세상에 태어나고 있는 데 반해, 아직은 모든 사람들의 입맛에 맞는 기능들을 탑재하고 있는 도구는 보기 힘든 것 같습니다. 어찌 보면, 아직은 MLOps 기술들의 춘추전국 시대라고 할 수 있겠네요. Matt Turck의 2021년 ML, AI 및 데이터에 대한 보고서만 봐도 MLOps에 필요한 각 부분을 위해 지금 이 순간에도 정말 수많은 기술이 개발되고 있음을 알 수 있습니다.리디에서도 머신러닝 기술이 쓰이는 곳이 많아짐에 따라 MLOps를 도입하기 위해 여러 도구들을 검토했습니다. 하지만, 회사의 요구사항에 맞게 커스터마이징 하기에는 개발 효율이 낮다는 결론에 도달했습니다.아직 덜 성숙한 새로운 기술을 도입해 커스터마이징 하는 대신, 데이터사이언스팀은 리디 서비스를 뒤에서 지원하고 있는 듬직한 데이터 처리 파이프라인과 다양한 모니터링 시스템, DevOps 기능들을 적극 활용해 안정성 높은 시스템을 만들어 보기로 했습니다. 유사한 사례로서, Facebook, Netflix, Uber 등 세계 유수의 회사들도 MLOps를 위해 내부 시스템을 구축해 사용하고 있습니다.잠깐! 리디에서는 머신러닝 기술을 어디에 활용하고 있나요?데이터사이언스팀에서 개발하고 있는 머신러닝 기술은 리디의 곳곳에서 충실히 임무를 수행하고 있습니다. 몇 가지만 살짝 알려드릴게요!마케팅: 사용자 세그멘테이션, 푸시 타게팅리디의 수많은 프로모션과 행사가 맞춤형으로 제공된다는 사실 알고 계셨나요? 마케팅 비용을 효율적으로 사용하려면 고객들의 취향을 잘 분석해 관심을 보일 것 같은 고객에게 집중하는 것이 매우 중요합니다. 리디에서는 서비스 이용 행태에 따라 고객들을 분류하고, 타게팅하고 있는데요. 여기에도 머신러닝 기술들을 활용하고 있습니다.어뷰징(abusing) 행위 감지리디에도 이벤트에 당첨되기 위해 댓글을 반복적으로 달거나, 포인트를 쌓기 위해 선물하기 기능을 악용하는 고객들이 있습니다. 데이터사이언스팀에서는 모든 고객이 건강한 리디를 즐길 수 있도록 여러 가지 어뷰징 행위를 감지하는 기술을 개발하고 있습니다. 대표적인 사례로 그래프 마이닝 기술과 시계열 분석 기술을 들 수 있답니다. 어뷰저들과의 쫓고 쫓기는 끝없는 싸움이죠!도서 추천리디의 장르별 페이지나 작품 상세 페이지에서 머신러닝 기술로 추천하는 도서들을 만나보신 적 있으신가요? 데이터사이언스팀에서는 리디 고객들이 서비스를 사용하면서 만든 수많은 로그들을 딥러닝 기술로 분석해 취향에 맞는 도서들을 추천하고 있습니다.콘텐츠 제작을 위한 연구바야흐로 AI가 그림도 그리는 시대가 되었습니다. 작화를 도와주는 조수 역할을 하는 AI. 생각만 해도

당근마켓에서는 머신러닝 모델을 효과적으로 적용하기 위한 방법에 대해서도 노력하고 있어요. 특히 ML 파이프라인은 주기적인 배포, 빠른 실험, 지속적인 모델 개선을 위해 필수가 되는 경우가 많으므로, 더 많이 노력해야 하는 대상 중 하나예요. 이전 블로그 글(머신러닝 모델로 동네생활 신고 업무 자동화하기)에서도 언급했던 것처럼 머신러닝 파이프라인에 TFX(TensorFlow Extended)를 활용하고 있는데요, TFX를 활용하는 이유와 어떤 방식으로 더 잘 사용하려고 하는지를 공유해보려 해요. 당근마켓의 ML 프로젝트 당근마켓 내부에는 많은 ML 프로젝트가 존재해요. 여러 추천(랭킹) 모델 과 중고거래, 동네생활 신고 업무 자동화 모델과 함께 서비스 내부 곳곳에 머신러닝 모델이 들어있어요. 상세한 프로젝트에 대한 소개는 이 포스트의 범위를 넘어서니, 프로젝트 상세 내용에 더 관심있으시다면 아래 블로그 글들을 참고해주세요. * 당근마켓 AI의 데이터 활용 방법 * 머신러닝 모델로 동네생활 신고 업무 자동화하기 * 이미지 분류 모델 AutoML 파이프라인 * 또는 직접 머신러닝 블로그 포스트 목록을 확인해주세요! 위의 블로그 글 이외에도 상당히 많은 수의 머신러닝 모델을 프로덕션에 활용하고 있어요. 이전 블로그 글(Kubeflow 파이프라인 운용하기)에서 언급했던 것처럼 머신러닝 모델을 주기적으로 새로운 데이터로 학습하고, 개선하고, 배포하기 위해 Kubeflow를 많이 활용하는데요. 최근 1~2년 동안은 그 위에 TFX라는 기술과 같이 사용하고 있어요. 프로덕션용 머신러닝을 개발하기 좋은 TensorFlow와 함께 사용한다면 굉장히 편하게 머신러닝 모델 및 파이프라인 개발, 실험, 배포를 진행할 수 있어요. TFX (TENSORFLOW EXTENDED) TFX는 프로덕션 머신러닝 파이프라인을 위한 end-to-end 플랫폼이에요. 2019년에 완전히 오픈소스화 되었고, 컴포넌트 단위로 ML 워크플로우를 개발한 후 여러 환경(Apache Beam, Dataflow, Kubeflow, Airflow)등에서 실행가능해요. 물론 데이터 수집/변환, 학습, 배포 등을 위해 잘 작성된 컴포넌트도 같이 제공되어요. TFX Pipeline Image from https://www.tensorflow.org/tfx 당근마켓 ML 팀에서 특히 크게 느끼는 이점들을 아래처럼 설명드려볼게요. 기본 컴포넌트 TFX는 수많은 컴포넌트를 미리 제공해요. 데이터 수집만 살펴보아도 CSV 기반인 CsvExampleGen부터 Presto, BigQuery 에서 직접 데이터를 수집할 수 있는 PrestoExampleGen, BigQueryExampleGen도 제공하여 여러 데이터 소스를 컴포넌트 연결만으로 손쉽게 처리할 수 있어요. 대용량 데이터 가공도 간편하게 처리할 수 있어요. 데이터 변환을 담당하는 Transform 컴포넌트는 Apache Beam기반으로 작성되어 있기 때문에 GCP Dataflow에서 간단하게 분산 실행할 수 있어요. 그 외에도 많은 편리한 컴포넌트

최근 몇 년 동안 LINE 앱의 iOS 소스 트리는 지속적으로 성장해 수백 개의 모듈로 늘어났습니다. iOS 버전의 소스 코드는 2019년 말 기준으로 140만 줄을 넘어섰으며, 이러한 증가세는 멈출 기미가 보이지 않습니다. 그 결과 LINE iOS 버전의 빌드 시간이 크게 증가했습니다. 또한 프로젝트의 규모가 커지면서 로컬 환경에서는 문제 없이 실행되는 빌드가 CI에서는 실행되지 않거나 혹은 그 반대의 경우가 발생하는 것과 같은 재현 불가능한 문제점도 늘어났습니다. 그래서 저희는 잠시 한 발자국 뒤로 물러나 빌드 성능을 개선하고 문제의 재현 가능성을 높일 수 있는 방법에 대해 고민해 보았습니다.  의존성 관리 개선 저희 팀에서는 2012년 말에 의존성 관리 도구인 CocoaPods를 도입했습니다. CocoaPods는 프로젝트를 클린 빌드할 때마다 모든 pod 라이브러리를 다시 빌드해야 하므로 많은 시간이 소요되는 단점이 있지만(대부분의 라이브러리가 Objective-C로 구현되었다면 큰 문제가 아닐 수 있습니다), Xcode와 잘 연동되고 외부 라이브러리의 소스 코드를 마치 내 소스 코드처럼 보고 디버깅할 수 있는 훌륭한 오픈 소스 소프트웨어입니다. 이후 저희 팀과 프로젝트가 확대되었고, Swift의 시대가 도래했습니다. 저희 팀은 버전 1.0 시절부터 Swift를 사용했는데요. 처음 3년 동안엔 Swift 의존성을 사용하지 않고 버틸 수 있었습니다만, 결국 한계에 도달해서 어쩔 수 없이 Swift 의존성 관리 도구인 Carthage를 도입해 CocoaPods와 함께 사용했습니다. CocoaPods와는 달리, Carthage에는 설정이 거의 없었습니다. Carthage는 프레임워크처럼 의존성을 사전에 빌드만 해 줄 뿐, 프로젝트에 통합시키는 것은 개발자의 몫이었기 때문입니다.  의존성 빌드는 크게 두 가지 방법으로 진행할 수 있습니다. Carthage를 통해 사전에 빌드된 아티팩트(artifact)를 GitHub에서 다운로드하거나 로컬에서 빌드하는 것입니다. GitHub에서 임의의 바이너리 파일을 다운로드하는 것은 보안상 지양하고 있고, 앱 성능도 고려하여 저희는 모든 의존성을 정적 프레임워크로 빌드하는 방법을 선택했습니다. 이에 따라 개발자들은 모든 의존성을 본인의 로컬 작업 환경에서 빌드하게 되었습니다. Carthage는 보이지 않는 곳에서 Xcode를 실행시켜 모든 의존성을 팻(fat) 바이너리로 빌드하는데요. 이때 지원하는 모든 아키텍처에 대해 이 과정을 반복합니다. 만약 현재까지 iOS 10을 지원하고 있다면, 4개의 아키텍처를 위해 각 의존성을 총 4번 빌드해야 합니다. 또한 Xcode의 아카이브 액션은 자체 설계에 따라 항상 완전한, 클린 빌드를 하도록 되어 있습니다. 이런 이유로 빌드 작업은 꽤 오랜 시간이 걸렸습니다. 몇 개의 의존성을 업데이트하느냐에 따라 달라졌는데 대략 15분에서 20분 정도 소요되었습니다. 만약 모든 사람이 위와 같이 동일한 코드를 각각 반복적으로 빌드해야 한다면 엄청난 자원이 낭비될 텐데요. 다