naver-place

문제YARN 클러스터에 배포된 Trino 의 리소스 부족으로 쿼리 처리 성능 저하.

접근YARN Application 리소스 할당 + AM Container 고려 + RESERVED Resource 메커니즘 분석 + JVM Heap / query.max-memory 튜닝.

결과장비 증설 없이 클러스터 가용 메모리 약 40% 증가, Worker 메모리 98GB 할당 달성.

문제내비게이션의 도로 너비 분류가 부정확해 좁은 길에서 사용자 불편이 발생했고, 리포팅에만 의존하기 어려웠다.

접근수치지형도 폴리곤에 Voronoi Diagram을 적용해 medial axis 기반 너비를 측정하고, 거리뷰 이미지에는 SegFormer 의미 분할 모델로 픽셀 단위 도로 너비를 추정했다.

결과이미지 기반 모델의 레벨 2 탐지 정확도가 약 2배 향상됐고, 전체 도로의 96%에 거리뷰 데이터를 확보해 사전 감지가 가능해졌다.

문제네이버 플레이스는 Airflow로 수백 개 ETL 파이프라인을 운영하는데, Yarn 통신 장애처럼 한 원인으로 수십 개 Task가 동시에 실패하면 동일한 알림 메일이 폭탄처럼 쏟아졌다.

접근모든 Task에 `email_on_failure=False`를 프로그래밍 적용하고, `trigger_rule='all_done'`인 Alert Task를 DAG 끝에 두어 통합 메일 1건을 만든다. `dag_run.get_task_instances()`로 실패 Task를 모으고 로그 파일을 본문에 첨부한다.

결과DAG당 1건의 통합 메일로 노이즈가 줄었다. HTML `<details>` 태그로 로그를 접고 펼칠 수 있어, 관리자가 task_id와 log_url로 빠르게 원인을 좁힌다.

문제네이버 플레이스 데이터 팀은 로컬 개발과 Kubernetes 프로덕션 환경이 달라서 "로컬에선 되는데 배포하면 오류"가 자주 났고, 파이썬 가상환경 관리도 일관되지 않았다.

접근Docker Compose로 Redis 메시지 큐, PostgreSQL, Airflow 컴포넌트를 단일 YAML에서 함께 띄운다. 로컬은 LocalExecutor, 운영은 CeleryExecutor로 파일을 분리하고, PyCharm을 Docker Compose 인터프리터로 묶어 DAG를 디버깅한다.

결과로컬에서도 프로덕션과 동일한 이미지로 개발·테스트가 가능해졌다. 환경 불일치에서 오는 배포 사고가 줄고 팀 작업 흐름이 표준화됐다.

문제네이버 플레이스 리뷰 태깅이 분석 API와 강하게 결합돼 기준 변경 때마다 재호출이 필요했고 한 리뷰의 다중 이미지가 컬렉션에 반복 업데이트돼 부하가 컸다.

접근원본을 저장하는 rawtags, 비즈니스 로직을 적용한 tags, 20분 주기로 모아 쓰는 updatabletargets 컬렉션으로 단계를 나누고 Kafka Consumer를 역할별로 분리했다.

결과이미지 태깅 업데이트가 67% 압축됐고(10,274→3,425) 한국 이미지→리뷰 전파가 47% 줄었으며 운영자 입력 보존과 ML 재학습 파이프라인까지 가능해졌다.

문제한정된 GPU를 큰 모델 학습에 쓰려고 작은 모델들을 CPU 서빙으로 옮겼더니, 초기엔 처리량 10배 저하·응답 10배 지연이 발생했다.

접근PyTorch 스레드를 물리 코어 수에 맞춰 잡고, IPEX(Intel Extension for PyTorch)로 코어 피닝을 적용한다. Knowledge Distillation from A Stronger Teacher 기법으로 정확도를 유지하며 모델을 경량화한다.

결과음식 분류기 2.5→84 RPS(약 34배), 이미지 점수 측정기 2.1→62 RPS(약 30배)로 회복했다. 연 4억 원, GPU 30개를 절감했다.

문제네이버 예약·주문 팀이 GitHub Actions 도입 초기에 PR 린트 중복 실행, 불필요한 테스트 재실행 같은 비효율을 겪었다.

접근name·on·jobs·steps 같은 워크플로우 문법과 github.event·secrets.GITHUB_TOKEN 같은 Context를 활용해 자동화를 정리했다. Marketplace의 auto-approve·wait-for-green·create-comment 액션과 Self-hosted Runner를 도입하고 외부 액션은 클론해서 관리했다.

결과PR 자동 승인, 브랜치 현행화, 이슈 정리, 주간보고 생성을 자동화했다. Runner만 세팅돼 있으면 짧은 시간에 다양한 자동화를 붙일 수 있다.

문제네이버 G플레이스 AI팀이 머신러닝 학습 데이터·모델 아티팩트를 보관하던 Ceph 스토리지에서 장애가 반복돼 안정적인 대안이 필요했다.

접근MinIO를 4대 서버로 구성하고 드라이브·노드·IDC 레벨 장애를 시나리오 별로 검증했다. Erasure Coding 동작과 Scale Up/Out 영향을 실측하고, DR은 Airflow가 HDFS로 정기 백업하는 Backup & Recovery 방식으로 잡았다.

결과(N/2+1) 디스크 정상 시 쓰기 가능을 확인하고, 1TB 복구에 약 3시간이 걸리는 RTO/RPO 기준을 운영 매뉴얼로 정리했다.