Backoffice AI Agent 구축기 — RAG+MCP 기반 플레이스AI 특화 지식 검색 시스템
Confluence·GitHub·외부 문서에 흩어진 사내 자료를 키워드 검색으로는 용어 변형·약어·맥락 차이를 못 잡아 백오피스 운영자가 답을 찾는 데 시간이 든다.
Confluence·GitHub·외부 문서에 흩어진 사내 자료를 키워드 검색으로는 용어 변형·약어·맥락 차이를 못 잡아 백오피스 운영자가 답을 찾는 데 시간이 든다.
YARN 클러스터에 배포된 Trino 의 리소스 부족으로 쿼리 처리 성능 저하.
내비게이션의 도로 너비 분류가 부정확해 좁은 길에서 사용자 불편이 발생했고, 리포팅에만 의존하기 어려웠다.
네이버 플레이스는 Airflow로 수백 개 ETL 파이프라인을 운영하는데, Yarn 통신 장애처럼 한 원인으로 수십 개 Task가 동시에 실패하면 동일한 알림 메일이 폭탄처럼 쏟아졌다.
네이버 플레이스 데이터 팀은 로컬 개발과 Kubernetes 프로덕션 환경이 달라서 "로컬에선 되는데 배포하면 오류"가 자주 났고, 파이썬 가상환경 관리도 일관되지 않았다.
네이버 플레이스 리뷰 태깅이 분석 API와 강하게 결합돼 기준 변경 때마다 재호출이 필요했고 한 리뷰의 다중 이미지가 컬렉션에 반복 업데이트돼 부하가 컸다.
NAVER GLACE CIC AI 개발팀은 15개 이상의 AI 모델을 운영하며 모델 수 증가에 따른 운영 비용과 복잡한 태그 추출이라는 과제를 안고 있다.
한정된 GPU를 큰 모델 학습에 쓰려고 작은 모델들을 CPU 서빙으로 옮겼더니, 초기엔 처리량 10배 저하·응답 10배 지연이 발생했다.
네이버 예약·주문 팀이 GitHub Actions 도입 초기에 PR 린트 중복 실행, 불필요한 테스트 재실행 같은 비효율을 겪었다.
네이버 G플레이스 AI팀이 머신러닝 학습 데이터·모델 아티팩트를 보관하던 Ceph 스토리지에서 장애가 반복돼 안정적인 대안이 필요했다.