네이버 플레이스 개발 블로그 - Medium 최신 글

최신 글

• Backoffice AI Agent 구축기 — RAG+MCP 기반 플레이스AI 특화 지식 검색 시스템

  Backoffice AI Agent 구축기 — RAG+MCP 기반 플레이스AI 특화 지식 검색 시스템 주제: 사내 백오피스 Agentic RAG 시스템 개발 키워드: RAG, MCP, Semantic Search, Hybrid Retrieval, RRF, LLM Reranker, Milvus, OpenSearch, Agentic Knowledge Search, Backoffice 핵심 성과: 응답 만족도 ×2, 응답 속도 1.4×, 토큰 66%↓, 툴 호출 49%↓ 안녕하세요, 플레이스 AI 플랫폼(이하 PAIP) 팀 MLOps 직무로 2개월간 인턴을 수행한 윤종석, 유서연입니다. PAIP 팀 MLOps 파트에서는 모델 학습·서빙·검색·데이터를 통합 운영하며, 최근에는 LLM 기반 RAG 시스템과 MCP 에이전트 기술을 실무에 도입하고 있습니다. 이번 인턴십에서는 Backoffice 전용 RAG+MCP 기반 의미검색 에이전트를 설계하고 구축하여, 팀 내부 문서의 탐색 효율을 높이는 시스템을 구현했습니다. 이 글에서는 프로젝트의 설계 과정, RAG+MCP 아키텍처 구현, 평가 및 운영 인사이트를 공유합니다. 업무 배경 — 왜 만들었나 업무를 하다 보면 실제 작업보다 필요한 문서를 찾는 데 더 많은 시간을 쓰는 경우가 많습니다. 문서는 Confluence·GitHub·외부 문서에 흩어져 저장되어 있고, 기존 검색은 단어 일치(Lexical Search) 위주라 표현이 조금만 달라져도 원하는 결과를 찾기 어렵습니다. 약어·사내용어·긴 회의록 문맥에는 특히 취약합니다. PAIP 팀은 모델·검색·서빙 등 공통 기술을 통합 운영하지만, 이 기술들이 서비스별로 독립적으로 적용되면서 기술 문서와 히스토리가 서비스 단위로 축적되고 있습니다. 그 결과 각각의 서비스마다 지식·맥락 공유가 어려운 구조적 한계가 있었습니다. 이를 해결하기 위해, 프로젝트의 목표를 다음과 같이 설정했습니다. 팀 내 기술·서비스 간 지식 격차 해소 및 정보 접근성 향상 OJT 및 협업 과정에서의 업무 효율 극대화 이를 위해 Semantic Search 기반의 RAG 구조로 문서의 의미를 이해해 관련 정보를 찾고, MCP를 통해 질의 의도를 해석해 최적의 답변을 찾아내는 Backoffice 전용 AI Agent를 구축했습니다. 초기 단계에서는 신규 입사자 온보딩(OJT)을 주요 시나리오로 설정하고, 실질적인 업무 효율 개선 효과를 검증하는 데 집중했습니다. 시스템 설계 — 어떤 기준으로 설계했나 이를 위해 검색할 데이터부터 검색 결과 최적화, 인터페이스, 그리고 신뢰성까지 고려해 시스템을 설계했습니다. 아래는 설계 단계에서 정의한 핵심 기준과 기술적 방향성입니다. ① 데이터 — 지속적으로 확장 가능한 구조 팀 내부 지식을 가장 잘 담고 있는 문서 플랫폼을 선별하여 데이터를 수집합니다. 수집 대상 데이터는 Github OSS, Attlasian Wikis, 외부 기술 문서(Milvus, Kserve 등)로 선정하였습니다. 서로 다른 형식과 주기로 갱신되는 데이터 소스 대상으로, 수집–정제–임베딩–적재 과정을 자동화하고 증분 처리하여 최신성을 유지합니다. 향후 새로운 문서 플랫폼이 추가되어도 모듈 단위로 확장할 수 있도록 설계합니다. 팀 내 기존 인프라 스택(OpenSearch, Milvus 등)을 활용하여 운영 효율을 확보합니다. ② 검색 — 의미기반 검색 RAG 최적화 RAG 시스템에서 “고품질 검색”을 정의하고, 이를 측정 가능한 평가 체계로 구축하여 실험적 최적화가 가능한 환경을 마련합니다. BEIR-SCIFACT 벤치마크와 LLM-as-a-Judge 평가 체계를 활용했습니다. 단일 검색 방식의 한계(문맥 이해 부족, 전문 용어 인식 부족)를 보완하기 위해 하이브리드 검색 전략을 채택합니다. LLM이 답변 생성에 필요한 충분한 문맥을 확보하기 위해, Pre-Retrieval/Retrieval/Post-Retrieval 단계 별 최적화 기법을 적용합니다. 검색 품질, 응답 속도, 운영 비용 간의 균형을 고려하여 최적화합니다. 20개 실험을 통해 Dense/

  2025년 11월 13일

• Trino resource optimize on YARN

  안녕하세요, 플레이스데이터플랫폼 나호철입니다. 이번 글에서는 YARN 클러스터에 배포된 Trino 클러스터의 리소스 구성 및 리소스 관련 설정을 순차적으로 최적화하여 장비 증설 없이 쿼리를 처리하는데 사용되는 클러스터 가용 메모리를 약 40% 가량 증가시킨 과정에 대해 간략히 공유하려고 합니다. 저희 플레이스데이터플랫폼(aka. PDP) 팀은 플레이스의 다양한 서비스에서 생성되는 데이터들을 효율적으로 적재하고, 적재된 데이터를 빠르고 안정적으로 사용할 수 있도록 Place Data Lake House(aka. PDL)를 운영하고 있습니다. 이렇게 구축된 PDL의 데이터는 Iceberg 테이블로 적재되며, Kafka, HDFS, Tableau 대시보드, 이메일 등 사용자들이 필요한 사양에 맞춰 다양한 방식으로 전달되거나, 네이버의 다양한 서비스 및 통계 지표 산출에 직접 활용되고 있습니다. #네이버 히든 아카이브 PDL의 데이터는 BI, 통계지표에 활용되거나 네이버 이용자들에게 직접 서빙된다. 이 중에서 Iceberg 테이블을 사용자들이 직접 조회하고 서비스 또는 통계 등에 활용하는 경우가 가장 많은 편인데요, 사용자들이 Iceberg Table을 직접 조회할 수 있는 쿼리 엔진으로는 Hive와 Trino를 제공하고 있습니다. 특히 Trino는 Interactive Query에 특화된 강점을 가지고 있어 AdHoc 쿼리, BI 및 탐색적 데이터 분석 등을 위한 활용에 용이하기 때문에 사용량이 빠르게 증가하고 있는 추세입니다. 따라서 Trino의 사용량 증가를 대비한 Trino의 리소스 구성을 점검하고 최적화하는 과정이 필요해졌습니다. 장비 증설을 통한 리소스 증가를 고려하기 전에 Trino의 리소스 설정을 이해하고 기존 자원을 최대한 효율적으로 활용할 수 있는 최적화 방안을 우선적으로 모색하게 되었습니다. Trino를 위한 YARN cluster 구성 먼저 Trino가 어떻게 구성되고 배포되었는지를 함께 살펴보겠습니다. 저희 팀은 사내 Hadoop cluster에 전용 큐를 구축하고 그 위에 PDL을 구현하였습니다. Trino도 Hadoop Ecosystem에 포함하여 Impersonation 적용, Ranger를 활용한 Authentication 통합, Resource Management 등의 이점을 활용하기 위해서 YARN Service를 사용해 YARN Application 형태로 배포하기로 결정하였습니다. Trino는 Hive와 달리 빠른 데이터 쿼리 처리를 위해 필요할 때 YARN의 리소스를 할당받는 것이 아니라, Worker가 동작할 리소스를 항시 점유해야 하는 특성이 있습니다. 따라서 Trino가 클러스터 내에서 일정한 리소스를 안정적으로 사용할 수 있도록 확보하는 것이 중요합니다. 이러한 특성을 고려하여 운영 환경과 운영 환경의 1/15 수준의 개발 환경 두 개의 Trino를 위한 전용 Queue를 구축하였습니다. 이후 이어지는 Trino 리소스 설정 과정을 쉽게 설명하기 위해 구축된 Trino Cluster는 아래 그림과 같은 스펙으로 구축했다고 가정하고 설명하겠습니다. Trino Resource optimize on YARN YARN 클러스터에 Trino를Application 형태로 배포할 때, 리소스 최적화를 위해 YARN Application과 노드 리소스 할당 방식에 대한 기본 개념을 이해하는 것이 중요합니다. 이 단락에서는 Hadoop 데몬 프로세스를 고려한 Node resource 할당, AM Container와 Node의 resource를 고려한 resource 설정, RESERVED Resource에 대한 이해, 총 세 가지 측면에서 설명하겠습니다. Hadoop 데몬 프로세스를 고려한 Node resource 할당 YARN 클러스터의 각 노드에는 Node Manager, DataNode와 같은 Hadoop 데몬 프로세스가 동작하고 있습니다. 이러한 프로세스들은 클러스터 운영에 필수적이며, 안정적으로 작동해야 합니다. 따라서 데몬 프로세스가 YARN Application과 리소스 경합으로

  2024년 11월 26일

• 네이버 지도 내비게이션, 꽃길만 가자 — 좁은 길 탐지 모델

  네이버 지도 내비게이션, 꽃길만 가자 — 좁은 길 탐지 모델 1. INTRODUCTION 안녕하세요. NAVER Maps Directions의 김준태 입니다. 저희 팀은 네이버 지도에서 내비게이션, 대중교통 길찾기 서비스 개발을 중심으로 좋은 품질의 서비스를 제공하기 위해서 빅데이터 수집, 분석, 모델링(통계, DL) 등도 수행하고 있는데요. 이번에 소개드릴 내용은 내비게이션 품질 향상을 위한 좁은 도로 추출 모델에 관한 이야기 입니다. 2. 문제 저희 내비게이션 서비스는 최단거리, 과거와 실시간 교통정보 기반 소요시간 예측, 도로 품질 등 다양한 요소를 고려해서 최적의 길을 안내해 주고 있습니다. 따라서 데이터 품질이 서비스의 품질로 직결되기 때문에 정확한 label 분류는 중요한 문제 입니다. 오늘 주제인 도로 너비를 예시로 들어보겠습니다. 도로는 너비에 따라서 level을 부여할 수 있는데요. 다음과같이 크게 3개의 level이 있고 level 값이 클 수록 차량이 가기 어려운 도로라고 가정해 보겠습니다. level 0 도로level 1 도로level 2 도로 level 2 도로를 불필요하게 안내하지 않기 위해 정확한 label 분류가 되어야 합니다. 문제는 도로데이터는 일일히 사람이 확인하기에는 너무나 커서 전부 확인하기 어렵고 유저분들께 리포팅 받을 때만 처리한다면 지속적으로 안좋은 서비스 경험을 드릴 수 있기 때문에 사전에 감지해서 해결할 필요가 있었습니다. 따라서 좁은 도로를 탐지하는 모델을 개발했습니다. 3. 모델1: 수치지형도 도로 너비 기반 모델 첫번째 방식은 Maps Data 팀에서 여러 데이터들을 검토 및 test 해주시고 최종 제안해 주신 방법인 수치지형도 polygon 데이터로 부터 도로의 너비를 측정하는 방식입니다. 수치지형도란 측량 결과에 따라 지표면 상의 위치와 지형 등 다양한 공간정보를 일정한 축척에 따라 나타낸 것을 말하고 polygon data는 말 그대로 도로와 같은 공간 data를 다각형으로 표현한 것을 의미합니다. 따라서 수치지형도를 이용하면 보다 실제와 근접한 길이의 공간 polygon data를 얻을 수 있습니다. 3.1 도로 polygon 너비 추정 도로 너비를 구하기 위해서는 polygon내부의 중심점과 outline과의 거리로부터 추출해 볼 수 있는데요. 단순히 polygon의 centroid를 활용하면 될것 같지만 다음과 같은 문제가 발생합니다. Centroid of polygon 이렇게 조금이라도 휘어진 polygon이라면 중심점이 바깥쪽으로 잡히면서 해당 점을 기준으로는 전혀 다른 width가 구해질 수 있습니다. 위 예시에서는 실제보다 좁게 width가 구해지겠네요. 3.1.1 Voronoi Diagram Centroid 가 아닌, polygon medial axis 를 구해야 합니다. 팀에서 활용하고 있는 apache sedona(spark geometry lib) 에서는 해당 기능이 없어서, Voronoi Polygon 기능을 활용해 구현했습니다. Voronoi Diagram Voronoi Diagram 이란 쉽게 설명하면 위 그림처럼 점과 점을 연결한 선을 수직이등분 하는 선들로 구성되는 다각형입니다. 앞서 본 도로 polygon 처럼 휘어진 polygon의 꼭짓점을 기준으로 voronoi diagram을 그리면 다음과 같은 모습이 됩니다. 이후 해당 polygon 내부에 들어온 voronoi diagram edge들을 보면 다음 처럼 polygon(파란색)의 medial axis(빨간색)를 근사시킬 수 있습니다. 해당 방식을 통해 앞서본 polygon을 포함해서 medial axis를 구하고 해당 line을 구성하는 점을 구해보면 다음과 같습니다. 이런식으로 polygon 내부 후보군 point 들을 얻을 수 있고 좀더 point들을 확보하기 위해 다음 point들도 추가했습니다. polygon의 minimum boundary rectangle 의 각 대각선과 polygon이 intersection하는 line의 중점 두개 centroid 중 poly

  2024년 10월 2일

• Airflow Task failed Alert Mail 폭탄 회피하기

  안녕하세요? G플레이스데이터개발 나호철입니다. 제가 속해있는 G플레이스데이터개발팀은 아래와 같이 크게 3가지의 기능을 하는 Data Lakehouse를 운영하고 있습니다. PDL(Place Data Lakehouse) Architecture Glace CIC의 여러 서비스로부터 Protobuf로 schema가 정의된 데이터를 받아 HDFS에 적재하는 ETL Pipeline HDFS에 적재된 데이터를 ML, 어뷰저 탐지, 통계 지표 생성 등 다양한 목적으로 사용할 수 있도록 데이터를 조회할 수 있는 분산 쿼리엔진 제공 인사이트를 얻을 수 있도록 필요한 지표를 만들거나 레포팅 할 수 있는 BI 툴 제공 이번 글에서는 ETL Pipeline의 구성 요소 중 Airflow를 사용하면서 겪었던 문제 중 하나인 과도한 Task failed Alert mail 발송으로 인한 노이즈를 제거한 내용에 대해 이야기해 보려고 합니다. Airflow는 Task라고 불리는 최소 작업 단위를 단방향 그래프(DAG)로 구성한 배치 워크플로우를 작성하고 스케쥴링, 모니터링 할 수 있는 오픈소스 프레임워크입니다. 쉬운 사용성과 직관적인 인터페이스로 Data Pipeline을 구성하는데 있어 널리 사용되고 있는 뗄래야 떼어놓을 수 없는 핵심 컴포넌트인데요. 저희 G플레이스데이터개발팀도 다음과 같은 다양한 목적을 달성하기 위해 Airflow를 적극적으로 사용하고 있습니다. 데이터를 적재하는 ETL Pipeline 적재된 데이터 정합성 검증 데이터 백업 Hive External table 관리 Github 연동을 통한 Release/Workflow 자동화 각종 Sample data 생성 Pain point: 한 Dag에서 병행 수행되는 task들의 실패 횟수만큼 email이 발송되는 경우 Airflow에서는 이런 배치 워크플로우를 잘 관리할 수 있도록 DAG에 실패한 Task가 발생하는 경우 관리자에게 Alert mail을 발송할 수 있습니다. 깨진 창문 신드롬처럼 실패한 Task를 방치하지 않기 위해서 실패 알림을 Email로 받아보고, 재시도하거나 처리 상태를 변경하는 등의 대응을 신속히 수행하는 것은 Airflow 관리자 입장에서 매우 중요한데요. 한 가지 아쉬운 점이 있다면, 실패한 DAG가 아닌 Task 단위로 Alert mail이 발송되기 때문에 동일한(혹은 유사한) 문제로 인해 실패한 Task들의 Alert mail을 한 번에 수십 건씩 받는 경우가 생긴다는 것입니다. 저희 팀에서 운영 중인 ETL Pipeline은 DB 개수 * DB의 Table 개수 * 사용 용도 만큼 증가하고 있으며, 현재 수 백개의 ETL Pipeline을 운영하고 있습니다. 파이프라인마다 약간씩 다르긴 하지만 어찌 되었든 데이터를 전송받고, 처리해 적재하고, 적재된 데이터를 검증하는 로직은 유사하기 때문에 DB 기준으로 DAG를 구성하고, 그 DAG 안에서 for 문을 돌면서 데이터를 적재하는 Task를 동적으로 생성하는 다음과 같은 구조를 지니고 있습니다. 이렇게 동일한 기능을 하는 Task를 동적으로 생성하는 경우 한 개의 Task에서 문제가 발생하게 되면, 나머지 Task들도 역시 문제가 발생할 가능성이 매우 높고 Airflow는 실패한 모든 Task에 대해 Alert mail을 발송한다는 것입니다. 예를 들어, Yarn Cluster와 통신을 하는 Task가 Pipeline상에 존재하는 경우 동작 시점에 Yarn Cluster가 통신 불능인 상태가 된다면, 해당 Task는 모두 실패하여 Airflow 관리자는 동일한 에러에 대해 대한 수십 통의 Alert mail을 받게 될 것입니다. 실제로 실패한 Task에 대한 Alert mail을 받아보면 pipeline 개수만큼 발송되는 것을 볼 수 있습니다. 생각해 보면 동일한 Alert mail이 여러 번 발송된다는 것은 마냥 나쁜 것만은 아닙니다. 그만큼 해당 Task가 여러 군데에서 반복적으로 쓰이고 있고, 문제의 영향 범위가 크다는 것을 직접적으로 표현해 주고 있습니다. 하지만 그렇다고 해서 수십 통의 A

  2023년 12월 14일

• Airflow 환경 Docker compose로 containerization하기

  안녕하세요, G플레이스데이터개발 팀에 올 하반기 신입으로 합류하게 된 양은석입니다. 비전공자인 저에게는 데이터 엔지니어링(DE)이 생소하고 낯설게 느껴졌는데요, DE의 핵심 도구 중 하나인 Airflow를 이해하게 된 과정과 개발 환경 설정을 통해 팀 생산성에 기여한 경험, 그리고 그 결과를 공유드리고자 이 글을 작성하게 되었습니다. 왼쪽부터 기존 로컬 환경, 새로 구축한 도커 환경, 그리고 쿠버네티스 기반 프로덕션 환경을 도식화했습니다. 이번 과제의 중심 목표는 Airflow 환경을 Docker 기반으로 구축하고, 개발 및 디버깅이 가능하도록 IDE 환경을 설정하는 것입니다. 기존에는 개발 환경과 배포 환경에서 Airflow의 실행 방식이 서로 달라 환경 변수나 설정 값이 주입되는 방식에 차이가 있었고, 그 간극 때문에 “분명 내 로컬에서는 되는데 배포 했더니 문제가 발생하는” 상황을 마주할 위험이 존재했습니다. 뿐만 아니라 각각의 로컬 개발 환경이 Python 가상 환경 도구(e.g. Miniconda)로 관리되고 있었지만 종종 이격이 발생했으며 OS 차이에 따른 문제도 심심찮게 일어났습니다. 하지만 Docker 환경을 이용하면 Local 환경의 변경 영향을 없애고 항상 동일한 형상에서 멱등성있게 테스트를 수행 가능하며, requirements.txt와 같이 Python 환경에 수정 사항이 발생한 경우 변경점에 대해서만 격리된 환경에서 검증 가능합니다. 따라서 K8S로 배포 및 운영되는 프로덕션 환경과 유사하면서 서로 동일한 환경에서 개발 및 테스트가 가능하도록 Airflow를 컨테이너화하는 작업이 필요했습니다. 이제 Airflow가 어떻게 구성되어 있고, 왜 containerization을 위해 Docker compose를 사용하였으며, 개발 환경은 어떤 방식으로 설정했는지 차례대로 살펴보도록 하겠습니다. Apache Airflow Apache Airflow는 배치 단위의 작업을 스케줄링 및 모니터링할 수 있는 워크플로 개발 도구입니다. 저희 팀은 테라바이트 단위로 흐르는 Place data를 추출, 변환 및 적재하는 ETL pipeline을 효율적으로 운영하기 위하여 Airflow의 힘을 빌리고 있습니다. Airflow는 최소 작업 단위인 task가 서로 의존성을 가지고 DAG(Directed acyclic graph)를 구성하며 일정 시간마다, 혹은 특정 조건에 의해 트리거될 때마다 실행되는 방식으로 작동합니다. 시작점으로 Airflow의 컴포넌트를 가볍게 짚어보면서 컨테이너를 어떻게 구성할지 밑그림을 그려볼 수 있습니다. 먼저, Scheduler는 이름에서 유추할 수 있듯 DAG의 실행을 스케줄링 및 오케스트레이션하는 컴포넌트입니다. DAG들의 지휘관 역할을 하면서 Metadata database에 여러 정보나 실행 상태를 저장하고, 파이썬 파일 형태로 존재하는 DAG의 디렉토리를 바라보며 일정 시간마다 변경을 감지합니다. 다음으로 Executor는 Scheduler 내부에 존재하면서 task를 실제로 수행하는 Worker를 만들고 명령합니다. 마지막으로 Webserver는 UI를 통해 DAG가 잘 돌고 있는지 모니터링할 수 있도록 도와줍니다. 구성 요소 간의 연결 관계를 파악할 때는, 만약 그 요소가 존재하지 않는다면 무슨 일이 일어날 지 상상해보는 것이 도움이 됩니다. Airflow architecture overview 이 때 어떤 Executor를 선택하느냐에 따라 Worker는 쓰레드나 프로세스가 될 수도 있고, pod이 될 수도 있기 때문에 컨테이너의 구성 방식이 바뀝니다. 예를 들어 SequentialExecutor는 하나의 작업을 단일 프로세스에서 순차적으로 실행하므로, Scheduler와 Worker의 역할을 수행하는 단일 컨테이너로 충분합니다. 반면, CeleryExecutor는 Celery라는 분산 작업 큐 시스템을 이용하여 다수의 Worker가 작업을 병렬로 처리하므로 Worker가 독립 컨테이너로 존재해야 합니다. 엔지니어는 항상 트레이드오프를 고려해야 하기 때문에 개발 환경과 운

  2023년 12월 4일

• 업데이트 압축률 67%, 플레이스 리뷰 tagging 시스템 개선경험

  안녕하세요, 플레이스 리뷰플랫폼 개발팀 강준우입니다. 저희는 네이버 플레이스 서비스인 MY플레이스를 포함해, LINE PLACE, Y!Map 등으로부터 등록된 방문자리뷰를 저장 및 관리하는 플랫폼 팀입니다. 리뷰 각 항목엔 여러 부가정보를 함께 태깅하고 있는데요, 이번에 전체 태깅프로세스를 재설계해 업데이트 부하 67%를 줄이는 등의 개선을 이룰 수 있었습니다. (같은 팀 Sungwon Kim님과 협업했습니다.) 간단히, 저희 팀에서 담당하는 태깅이 어떤 것인지 알아보고 기존 태깅시스템은 어떤 방식을 가지고 있었고, 어떤 아쉬운 점이 있었는지 개선한 태깅시스템은 어떤 형태이며, 어떻게 각 지표가 개선되었는지 이번 글을 통해 공유하고자 합니다. 1. 태깅이란? 리뷰이미지: 음식이 중앙에 있는, 플레이팅이 멋진, ... 리뷰텍스트: 긍정적인 단어가 많은, 중국음식이 언급된, 서비스에 대한 평가가 있는 위와 같이 이미지, 텍스트 등 리뷰 각 항목을 분석한 결과를 태그라고 하고, 태그를 뽑아내 리뷰와 함께 저장하는 과정을 태깅이라고 부르고 있습니다. 예시로 제가 MY플레이스에 등록한 다음 리뷰는 아래와 같이 태깅되어있습니다. (실제 더 많은 항목들을 태깅하고 있지만, 공개 제약으로 인해 두 가지 예시만 담았습니다.) Original ReviewReview Image & Text Tagging (스키마 및 값은 이해를 돕기 위한 예시입니다) 태그는 다음과 같이 다양한 형태로 사용되고 있고, 모델이 발전하고 서비스가 점점 많아짐에 따라 그 용도 또한 늘어나는 중입니다. 태그 사용 예시 1. 플레이스 리뷰탭 메뉴필터 및 추천순 정렬태그 사용 예시 2. 플레이스 홈탭 노출 이미지 선별태그 사용 예시 3. 네이버앱 요즘여기판 주제태그별 리뷰 선별 2. 기존 태깅시스템 플레이스 내 AI 개발팀을 포함한 Naver AI팀들은 다양한 모델을 활용해 이미지/텍스트 분석을 담당해주시고 계시는데요. 저희 플레이스 리뷰플랫폼 개발팀에선 이러한 분석 API를 호출 후, 해당 분석값으로부터 태그를 추출해 저장합니다. 가장 단순한 방법으로는 리뷰 등록/수정 API 호출 시, 분석 API를 호출해 그 결과를 한꺼번에 리뷰와 함께 DB에 저장하기 가 있을 것입니다. 그러나 위 방식은 한 리뷰에 여러 이미지를 업로드한 유저의 경우, 리뷰가 등록되기까지 몇십개의 분석 결과를 기다려야 하므로 사용자 경험이 좋지 못할 것입니다. 그래서 기존의 태깅 구조는 다음과 같이 별도의 배치로 분리되어 있었습니다. 리뷰 등록/수정 API 호출 이후, Kafka Consumer를 통해 리뷰가 insert/update될 경우 비동기적으로 태깅이 이뤄지도록 함 기존 태깅 플로우 언뜻 보면 납득이 가는 분리일 텐데요, 점점 태깅이 고도화되며 다음 문제들이 발생했습니다. (1) 변화하는 비즈니스 로직에 취약한 구조 하나의 분석 API엔 태그 하나보다 많은 정보가 담겨있고, 저희는 그 중 서비스에서 유의미한 정보를 태그로 추출하고 있습니다. 다음은 리뷰이미지 내 음식인식 태그값 추출의 가상 예시입니다. 분석 API 응답으로부터의 태그값 추출 예시 분석 결과에선 3가지 음식이 탐지되지만, score 0.7 이상인 음식만 태깅한다 라는 비즈니스 로직에 따라 태그가 만들어집니다. 어느 날 음식태그 정확도가 떨어진다고 기획팀에서 판단해, threshold를 0.7에서 0.8로 올려달라는 요청을 했다고 가정해보겠습니다. 이전에 업로드된 모든 이미지들에 대해 소급해야 할 텐데, 기존 태깅시스템 상에선 기존 태깅 플로우 내 3~6 과정 위 과정을 리뷰DB 내 이미지 전체에 대해 반복해야 했습니다. 분석 API의 원본 응답값을 저장하고 있지 않아, 다시 처음부터 api를 호출해야 했고 이에 따른 비용이 낭비되곤 했습니다. 또한 5. 태그 추출에 해당하는 비즈니스 로직이 3~6 (분석~태깅) 전체와 커플링이 되어 있었는데, 보다 복잡한 태깅 적용을 위해선 비즈니스 로직을 분리할 필요가 있었습니다. 그 예시로 N차태깅이 있습니다. N차태깅: 태그 여러 개가 input이 되어 또다른 태그를 만드는 태

  2023년 11월 6일

• Introduction to NAVER Place AI Development Team

  This is a link to the Korean version Hello. My name is Yun Sang Ju, and I’m in charge of the AI development team at GLACE (Global Place) CIC (Company-In-Company), which is one of NAVER’s CICs. I would like to introduce the AI development team of the Service Organization, discussing our mission and how we apply AI technology to real services. I will continue with the explanation following the table of contents below. Services provided by NAVER GLACE CIC The mission of NAVER GLACE CIC AI development team and AI products under development/operation Key considerations for operating service AI products Services Provided by NAVER GLACE CIC “GLACE” is a combination of the words “Global” and “Place.” NAVER refers to the process of connecting offline services such as restaurants, guesthouses, and hair salons to online platforms as “Place.” The reason for adding “Global” is that our organization aspires to expand not only in Korea but also in Japan and other countries. The image below represents the direction pursued by NAVER GLACE CIC, and we are operating various O2O (Online to Offline) services in both Korea and Japan. Korea In Korea, we provide a variety of O2O services such as NAVER PLACE, Reservations, and MY PLACE. NAVER Place offers rich, detailed information of millions of business and various points of interest across Korea, including reviews from users who have visited said places. At the time of writing, NAVER Place has accumulated over 350 million reviews and continues to grow. Additionally, we offer the SmartPlace tool, which allows Business Owners to easily manage their places. Through SmartPlace, Business Owners can manage their NAVER PLACE detailed pages and receive various statistical information that benefits their businesses. Japan In Japan, we operate a similar O2O service called LINE PLACE, which is tailored to the Japanese userbase. One of LINE Place’s most well received features is the menu review, giving users the agency to write reviews in more detai

  2023년 9월 8일

• ML gpu model server 성능을 유지하며 cpu server로 전환한 경험 공유

  Intro 안녕하세요, G플레이스AI개발팀 박상준, 이주영, 민준호입니다. 저희 팀에서는 한국, 일본 등의 지역기반서비스를 사용하시는 유저분들께 새롭고 더 개선된 가치를 제공하기 위해 여러가지 AI 모델을 서비스에 활용하고 있는데요. 여기서 그치지 않고 더욱 훌륭한 서비스 경험을 제공하기 위한 large model train, 그리고 더 다양한 모델 활용을 목표하고 있습니다. 한정된 gpu 자원 속에서 이러한 목표를 달성하기 위해 기존에 운영하던 비교적 작은 모델들을 cpu serving으로 전환할 필요가 있었습니다. 이번에 소개드릴 내용은 성능 하락 없이 이전과 동일한 서비스 퀄리티를 유지하면서 기존 model server들을 gpu에서 cpu로 전환하여 연간 약 4억원의 비용절감 효과를 볼 수 있었던 작업에 대한 경험입니다. 문제 정의 1 — 서비스 아키텍처 cpu server 전환 경험을 말씀드리기 전에 내용의 이해도를 돕기 위해 저희 서비스 아키텍처를 최대한 간략화하여 소개해 드리겠습니다. 이해를 돕기 위해 최대한 간소화 한 service architecture입니다 기본적으로 input을 model이 forward시킬 수 있는 형태로의 전처리 및 inference 결과를 client가 이해할 수 있는 형태로 후처리 하는 CPU intensive한 작업은 App Server(FastAPI)에서 수행하고, Model Server(TorchServe)는 순수하게 inference만을 수행하는 구조를 가지고 있습니다. 안정적인 서비스 운영을 위해 아래 동작이 충분한 처리량과 적절한 latency로 수행되어야 합니다. client는 traefik gateway를 통해 app server로 요청 app server는 input을 resize, transform 등을 거쳐 torch tensor로 preprocess 후 model server로 요청 model server는 inference 수행 후 app server로 feature를 반환 app server는 feature를 사람이 이해하기 용이한 형태로 변환 postprocess 후 client에게 반환 2 — 처리량과 latency 측정 아래는 G플레이스AI개발팀에서 실제로 운영중이던 이미지 점수 측정 모델을 cpu로 배포한 뒤 단순비교한 결과입니다. cpu가 비교적 저렴한 자원이기 때문에 pod를 3배 늘려서 비교했음에도 10배 낮은 rps와 10배 느린 response time을 확인할 수 있습니다. cpu가 gpu보다 inference 성능이 안 좋은 것은 이제는 상식이기 때문에 놀라운 결과는 아니었지만, 매우 곤란한 상황임은 분명했습니다. 한정된 자원 안에서의 성능 유지를 목표하여 추가 scale out은 고려하지 않았기 때문에 대략 10~20배의 성능 향상이 필요했습니다. 3 — 애로사항 : 처리량 측면에서 쉽고 효과적이지만 추가 자원이 들어가는 scale in, out을 제외하고, 8core, 3replica를 고정해두었을 때, torchserve framework 사용자들이라면 당연하게도 torchserve의 worker를 늘리는 방안을 생각할 것입니다. worker가 늘어나는만큼 memory usage가 선형적으로 증가한다는 점을 빼면, gpu server에서 실제로 효과적으로 작용하기 때문입니다. 하지만 실제로 적용을 해보고나면 당황스러울 정도로 처리량과 latency 지표가 오히려 악화돼버리는 현상을 마주할 수 있습니다. Type Name # reqs # fails | Avg Min Max Med | req/s failures/s --------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|----------- POST /predictions/image-scoring 37 0(0.00%) | 9031 4043 28985 8200 | 1.00

  2023년 7월 13일

• GitHub Actions를 활용한 개발 효율화

  Intro 안녕하세요. 스마트플레이스서비스개발 1팀의 오정석입니다. 네이버 예약·주문 팀에서는 올해 초부터 본격적으로 GitHub Actions를 활용해 개발 효율화를 꾀하고 있습니다. 초기에는 GitHub Actions를 단순히 예약·주문 리포지토리에 PR Lint test 실행을 목적으로 도입되었습니다. 이 과정에서 Runner 머신 구축 뿐 아니라 PR에 커밋이 추가될 때마다 테스트가 중복 실행된다거나, PR 본문이 바뀌어도 린트 테스트가 실행되는 등 개선이 필요한 부분이 존재했습니다. 이 같은 개선점을 수정하던 중 Lint test 외에도 개발 효율성을 높여줄 만 한 다양한 Action들을 찾게 되었고 도입을 검토해보게 되었습니다. 약 6개월 동안 적용해본 Action들과 작성한 workflow들을 예시로 도입 과정과 장점들을 공유드리고자 합니다. GitHub Actions GitHub Action 구조 GitHub Actions란 GitHub에서 제공하는 CI/CD 플랫폼입니다. 특정 리포지토리에 트리거 이벤트가 발생할 경우 GitHub Action Runner에서 워크플로우 파일에 작성해 둔 일련의 작업들을 실행하는 구조입니다. 워크플로우 실행환경을 가리키는 GitHub Action Runner의 경우 GitHub에서 자체 제공하는 가상머신인 GitHub-hosted Runner와 직접 사용자가 환경을 구성하는 Self-hosted Runner가 있습니다. 과도한 워크플로우들이 실행되는 머신이 아닐 경우 GitHub-hosted Runner는 무료(GitHub Actions 요금 정보)로 사용이 가능하기 때문에 간편한 도입을 위해서는 GitHub-hosted Runner를 사용하는 것이 좋습니다. 하지만 사내 리포지토리에 GitHub Actions를 도입하는 경우 Github-hosted Runner 머신에 사내 코드가 노출되는 보안적인 문제를 가지고 있기 때문에 Self-hosted Runner를 구축해서 사용해야 합니다. GitHub Actions는 기존 CI/CD 도구들과 비교했을 때 GitHub 플랫폼 하나에서 모든 CI/CD 과정을 해결할 수 있다는 장점을 가지고 있습니다. Runner 머신 구축 이후, 리포지토리 .github/workflows 디렉토리에 워크플로우 YAML 파일을 작성하기만 하면 별도의 설치, 세팅 없이도 간편하게 기능을 사용할 수 있습니다. Workflow 워크플로우 구문에 대해 간단하게 설명드리려 합니다. GitHub Actions로 어떤 작업들을 만들어낼 수 있을지 구상하기 위해서는 workflow 구문을 자유롭게 활용할 수 있어야 합니다. name # Lint test 워크플로우 이름 예시 name: 'lint-on-pr' 작성하고 있는 workflow의 명칭을 지정할 수 있습니다. name 속성을 생략할 경우 리포지토리 “Actions” 탭에서 워크플로우 파일 상대경로로 표시되기 때문에 지정해서 사용하는 것이 좋습니다. on on: push # 단일 트리거 이벤트 : 커밋 푸쉬 이벤트 발생 시 워크플로우 실행 on: [push, fork] # 다중 트리거 이벤트 on 구문을 통해 워크플로우를 실행할 트리거 이벤트를 명시할 수 있습니다. # 명시된 브랜치 목록들을 base branch로 하는 PR이 [생성, 재생성, head 브랜치 동기화, draft PR 리뷰 준비 완료] 이벤트 발생 시 워크플로우 동작 on: pull_request: branches: - main - develop - feature/* - release/* - hotfix/* types: [opened, reopened, synchronize, ready_for_review] # 해당 타입들은 github webhook payload 타입 목록을 따릅니다 on 구문은 단순한 트리거 이벤트 지원은 물론 워크플로우 실행 시기를 좀 더 세밀하게 제어하기 위해 옵션들을 적절히 제공하고 있습니다. 위 코드는 네이버 예약·주문 리포지토리 Lint test 워크플로우의 on 구문입니다. 이처럼 on.<event

  2023년 6월 7일

• MinIO 도입기— HA 이해 및 DR 전략 구성

  네이버 G플레이스AI개발 팀에서는 ML 학습과 모델 서빙 과정에서 필요한 데이터 아카이빙을 위한 스토리지로 MinIO를 운영하고 있습니다. MinIO 도입을 위한 실험과, 백업/복구 시스템 구축 내용을 공유합니다. 업무 진행 배경 1 — 중요도 높은 데이터 아카이빙 G플레이스AI개발 팀에서는 AI 모델 학습부터 모델 서빙까지 머신러닝 과제의 전체 프로세스에서 필요한 학습 및 테스트 데이터, 모델 아티팩트 등을 모두 ceph 저장소에 저장하고 있었습니다. 용도별로 버킷을 분리하고, 데이터가 필요한 K8s Pod에 Ceph bucket을 file system 형태(cephfs)로 마운트해 데이터에 접근하였습니다. cephfs의 사용성에 맞지 않게 사용하는 세션(pod) 수가 과도하게 많아져 Cephfs의 장애를 유발하였고, 모델 서빙 환경에서 필요한 파일에 접근하지 못해 서비스 장애로 이어지는 이슈가 있었습니다. 데이터 유실을 허용할 수 없는 수준의 중요도가 높은 데이터에 대한 관리가 필요한 상황이었습니다. 이러한 데이터는 아카이빙을 진행하고, 데이터가 필요한 시점에 데이터를 받아오는 방식으로 접근 방식을 변경하기로 결정하습니다. 이를 위해, 데이터 아카이빙을 위한 스토리지를 결정하고, 해당 스토리지의 장애 상황에 대한 강건성을 파악하고, 데이터 유실 상황에 대한 대비가 필요했습니다. 2 — 중요도 높은 데이터 정의 학습 관련 데이터셋(Train, Valid, Test): dvc Model lineage: mlflow artifact storage 서빙 관련 데이터셋(Model Weight): mlflow model registry CI/CD 관련 데이터셋(testset for Continuous Testing): s3 3 — MinIO를 활용한 분산 S3 Object Storage 구축 G플레이스AI개발 팀에서는 머신러닝 과제의 전체 프로세스에서 아카이빙이 필요한 데이터를 정의하고, 이를 관리하기 위한 툴을 도입하는 과정에 있었습니다. 데이터 접근 인터페이스를 공통적으로 맞추고자 공통된 스토리지를 결정하고자 하였습니다. dvc, mlflow 툴에서 공통으로 지원하는 프로토콜을 고려하였습니다. 또한 팀원들이 동시 접근가능하고, 확장성이 높은 Object Storage를 사용하기로 결정하였습니다. 이전에 팀 내에서 구축했던 경험이 있는 Distributed MinIO 서버를 구성하여 테스트를 진행하였습니다. Naver k8s platform n2c에 Distributed MinIO 서버를 구축하였고, cephrbd pvc를 statefulset pod에서 마운트해 구축하였습니다. 문제 정의 중요 데이터를 MinIO 스토리지에 저장하고, k8s 환경에서 MinIO 스토리지를 운영하기로 결정한 상황 스토리지 운영에서 발생 가능한 장애 상황 대비를 위한, MinIO 스토리지의 HA, Failover 이해의 필요성 최악의 상황은 데이터 유실이며, 이를 방지하기 위한 백업의 필요성 문제 해결 원칙 4가지 1 — 대비하고자 하는 장애 레벨 정의 장애 레벨: 1. 드라이브 장애 2. 노드 장애 3. IDC 레벨 장애 k8s 환경에서 MinIO 스토리지를 운영하면서 발생할 수 있는 장애 레벨을 정의하고, 각 장애 상황에 따른 대응 방법을 메뉴얼화하고자 하였습니다. 특히 스토리지 운영에서 발생할 수 있는 드라이브 장애 / 노드 장애 상황 시나리오에 대해 고민하고 대비하고자 하였습니다. 클러스터 레벨에서의 장애는 MinIO를 구축할 때 연계한 사내 외장 블록 스토리지 Cephrbd 및 백업 대상 스토리지 hdfs의 데이터 IDC 이중화를 고려하고 싶었습니다. 2 — 데이터 유실 최소화 최악의 상황은 데이터 유실이며, 데이터 유실을 최소화하는 방안을 고민하였습니다. MinIO 자체 Failover 기능을 이용하는 방법과, 데이터 센터 레벨에서 장애 상황에 대비해 Disaster Recovery 플랜을 실행하는 방법을 고려하였습니다. 특히 데이터에 접근하는 서비스의 특성을 고려해 서비스 영향성을 정의하고, 이에 따라 데이터 유실을 방지하고

  2023년 4월 6일

이 블로그의 주제