네이버

스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기 (새 탭에서 열림)

네이버 스마트스토어센터는 비즈니스 성장에 따른 Oracle DBMS의 리소스 경합과 라이선스 비용 문제를 해결하기 위해 오픈소스인 MySQL로의 무중단 마이그레이션을 단행했습니다. 10년 이상의 레거시 시스템을 안정적으로 전환하기 위해 '이중 쓰기(Dual Write)' 전략을 채택했으며, 이를 통해 데이터 손실 없는 실시간 동기화와 즉각적인 롤백 가능성을 확보했습니다. 결과적으로 서비스 중단 없이 DB 환경을 성공적으로 전환하며 운영 효율성을 높였습니다. ### 이중 쓰기(Dual Write)를 통한 무중단 전환 전략 * **3단계 전환 프로세스**: 전환 전에는 Oracle을 메인으로 사용하며 MySQL에 백그라운드 쓰기를 수행하고, 데이터 마이그레이션 후에는 MySQL을 메인으로 전환하되 Oracle에 백그라운드 쓰기를 지속하여 정합성을 유지합니다. * **롤백 안정성 확보**: 신규 시스템 배포 후 치명적인 성능 저하나 장애가 발생하더라도, Oracle에 실시간으로 데이터가 쌓이고 있으므로 별도의 복구 작업 없이 즉시 이전 환경으로 복구가 가능합니다. ### JPA 환경에서의 기술적 대응 * **Proxy DataSource 활용**: `datasource-proxy` 라이브러리를 사용하여 Oracle에서 수행되는 쿼리를 가로챈 뒤 MySQL DataSource에서도 동일하게 실행하는 구조를 구축했습니다. * **트랜잭션 분리 및 동기화**: MySQL 쿼리 실패가 메인 트랜잭션(Oracle)에 영향을 주지 않도록 `TransactionSynchronizationManager`를 사용했습니다. Oracle 커밋이 성공한 시점(`afterCommit`)에 모아둔 MySQL 쿼리를 일괄 실행하여 정합성을 맞춥니다. * **엔티티 및 PK 전략 변경**: Oracle의 Sequence 전략을 MySQL의 Identity(Auto-increment)로 변경하고, `columnDefinition` 설정을 통해 Oracle의 VARCHAR2, CLOB 등을 MySQL의 TEXT, LONGTEXT 타입에 맞게 조정했습니다. ### MyBatis 기반의 중앙 집중형 이중 쓰기 구현 * **SqlSession Proxy 적용**: 수천 개의 비즈니스 로직을 수정하는 대신, MyBatis의 `SqlSession`을 프록시로 감싸 쓰기 작업(CUD)이 발생할 때 Oracle과 MySQL 쿼리를 동시에 호출하도록 구현했습니다. * **DBMS별 쿼리 매핑**: Oracle과 MySQL의 SQL 문법 차이를 해결하기 위해 별도의 MySQL용 쿼리 파일을 작성하고, 실행 시점에 Query ID에 접두사(예: `mysql.`)를 붙여 적절한 쿼리를 찾아 실행하는 방식을 사용했습니다. ### 데이터 정합성 검증 및 최종 전환 * **배치 기반 검증**: 두 DB 간의 레코드 카운트와 데이터 해시값을 주기적으로 비교하는 배치 프로그램을 운영하여 미세한 데이터 불일치를 식별하고 수정했습니다. * **기능 토글을 이용한 전환**: ZooKeeper 등을 활용한 설정 변경만으로 메인 DB(Read/Write 주체)를 즉시 교체할 수 있는 환경을 구성하여 배포 없이 안정적으로 전환을 완료했습니다. 이와 같은 전략은 대규모 레거시 시스템에서 DB를 교체해야 할 때, 코드 수정을 최소화하면서도 서비스 안정성을 최우선으로 고려하는 개발자들에게 실무적인 가이드라인을 제공합니다. 특히 트랜잭션 동기화와 프록시 패턴을 활용한 중앙 집중식 제어는 복잡한 시스템 마이그레이션의 위험 부담을 낮추는 핵심 기술 요소입니다.

네이버 통합검색 AIB 도입과 웹 성능 변화 분석 (새 탭에서 열림)

네이버 통합검색에 도입된 AI 브리핑(AIB)은 채팅 기반의 동적인 UI 특성으로 인해 기존의 핵심 웹 지표인 LCP(Largest Contentful Paint)를 지연시키는 결과를 초래했습니다. 분석 결과, 이는 서버 성능의 문제가 아니라 스트리밍 방식의 어절 단위 렌더링과 인터랙션을 위한 DOM 재구성 등 클라이언트 측의 구조적 특성이 LCP 측정 방식과 충돌하며 발생한 현상으로 확인되었습니다. 네이버는 이러한 UI 특성을 고려하여 LCP 위주의 단일 지표 관리에서 벗어나, TTFT(Time to First Token)와 같은 사용자 체감 성능에 특화된 새로운 측정 체계를 도입하여 성능 관리를 고도화할 계획입니다. **AIB 도입에 따른 성능 지표의 변화** * **LCP p95 지표 악화:** AIB 노출량이 증가함에 따라 통합검색의 LCP p95 값이 목표치인 2.5초를 상회하는 약 3.1초까지 상승하는 경향을 보였습니다. * **성능 분포의 변화:** AIB가 전체 LCP 분포의 꼬리(tail) 영역에 영향을 주면서, 'Good' 구간에 해당하는 사용자 비율이 감소하고 느린 구간의 사용자가 증가했습니다. * **렌더링 방식의 차이:** 구글의 AI Overview가 블록 단위로 렌더링하는 것과 달리, 네이버 AIB는 어절 단위의 점진적 노출과 적극적인 애니메이션을 사용하여 지표 측정에 더 큰 영향을 미쳤습니다. **채팅 UI에서 LCP 왜곡이 발생하는 기술적 원인** * **DOM 재구성 로직:** 텍스트 애니메이션이 끝난 후 하이라이트 기능을 위해 DOM 구조를 다시 변경하는 과정에서, 브라우저가 LCP 후보 영역의 렌더링 시점을 실제보다 늦게 기록하게 됩니다. * **어절 단위 렌더링의 한계:** 콘텐츠가 어절 단위로 쪼개져 렌더링되면 LCP 알고리즘이 '가장 큰 텍스트 블록'을 찾지 못하거나, 의미가 적은 작은 요소를 LCP로 잘못 선택하는 문제가 발생합니다. * **Chromium Paint Invalidation:** 스트리밍 방식으로 텍스트가 추가될 때마다 해당 레이어 전체에 페인트 무효화가 발생하며, 이로 인해 이미 화면에 그려진 요소의 `renderTime`이 프레임 단위로 계속 갱신되어 최종 측정값이 늦춰집니다. **네이버 통합검색의 성능 관리 개선 방향** * **독립적 성능 기준 수립:** AIB 영역을 제외한 일반 검색 결과의 LCP 'Good' 비율은 96%로 안정적이므로, AIB와 같은 특수 UI에는 별도의 성능 지표를 적용할 필요가 있습니다. * **TTFT(Time to First Token) 도입:** 사용자가 첫 번째 응답을 인지하는 시점을 측정하는 TTFT를 핵심 지표로 검토하여, 채팅 UI의 실제 체감 성능을 더 정확하게 반영하고자 합니다. * **지표 해석의 고도화:** 단순히 수치상의 LCP 최적화에 매몰되지 않고, UI의 특성과 사용자 경험을 더 잘 예측할 수 있도록 지표 분석 체계를 세분화하고 개선해 나갈 예정입니다. 현대적인 웹 환경에서는 스트리밍이나 동적 인터랙션이 강조되는 만큼, 기존의 정적 페이지 중심 지표인 LCP만으로 모든 성능을 대변하기 어렵습니다. 따라서 서비스의 UI 특성에 맞춰 TTFT와 같은 대안 지표를 함께 활용하고, 지표의 수치 너머에 있는 브라우저 렌더링 파이프라인의 동작 원리를 이해하는 것이 실질적인 사용자 경험 개선의 핵심입니다.

FE News 26년 1월 소식을 전해드립니다! (새 탭에서 열림)

2026년 1월 FE News는 프론트엔드 생태계의 핵심 축으로 자리 잡은 React Server Components(RSC)의 내부 동작 원리와 브라우저 환경에서 급격히 성장 중인 클라이언트 사이드 AI 기술을 집중적으로 조명합니다. 특히 프레임워크의 복잡한 데이터 흐름을 시각화하는 도구와 온디바이스 AI 추론 기술의 발전은 웹 개발자가 단순히 UI를 구현하는 것을 넘어 시스템 설계와 모델 최적화 영역까지 고민해야 함을 시사합니다. 결론적으로 표준화된 디자인 시스템과 AI의 결합이 마크업 자동화를 가속화하며 프론트엔드 개발 워크플로우에 근본적인 변화를 가져오고 있습니다. **React Server Components(RSC) 시각화와 디버깅** * Dan Abramov가 공개한 'RSC Explorer'는 RSC 프로토콜의 스트림 데이터를 단계별로 재생하고 분석할 수 있는 시각화 기능을 제공합니다. * 서버, 클라이언트, Flight, Preview 등 4가지 패널을 통해 데이터 흐름을 한눈에 파악할 수 있으며, 실제 React의 reader/writer를 사용하여 프로토콜과 동일한 출력 결과를 보여줍니다. * Suspense 스트리밍, Server Actions, Router refresh 등 프레임워크 내부의 복잡한 동작을 이해하고 디버깅하는 교육 자료로 활용 가치가 높습니다. **클라이언트 사이드 AI와 에이전트 기술의 부상** * AI 추론의 중심이 서버 호출에서 브라우저 내 로컬 실행으로 이동하고 있으며, WebGPU와 WebNN을 활용한 온디바이스 AI 구축 방법이 주요 화두로 떠올랐습니다. * Transformers.js를 이용해 100% 로컬 환경에서 ML 모델을 실행하거나, webMCP를 통해 웹 사이트 기능을 브라우저 에이전트가 직접 사용할 수 있는 도구로 정의하는 기술이 소개되었습니다. * Jeff Dean의 강연을 통해 AI가 단순한 기능 추가를 넘어 제품의 UX와 시스템 워크플로 전체를 바꾸는 핵심 동력임을 확인할 수 있습니다. **디자인 시스템 기반의 마크업 자동화 사례** * Figma Code Connect와 AI 인스트럭션을 결합하여 디자인 시스템의 토큰과 컴포넌트 구조를 학습시키고, 이를 통해 프론트엔드 마크업을 자동 생성하는 실무 경험을 공유합니다. * 디자인 시스템의 문서화와 표준화 수준이 높을수록 AI를 활용한 코드 생성의 효율이 극대화된다는 인사이트를 제공합니다. * 다만 복잡한 레이아웃이나 반응형 처리에 있어서는 여전히 사람의 개입이 필요하며, AI는 개발의 시작 단계에서 생산성을 높여주는 보조 도구로서 기능합니다. **AI 연구의 여정과 미래 가치 탐색** * DeepMind의 AlphaFold 개발 과정과 인공 일반 지능(AGI)을 향한 탐구 과정을 담은 다큐멘터리 'The Thinking Game'을 통해 AI 기술의 근본적인 발전 궤적을 조명합니다. * 이러한 흐름은 프론트엔드 엔지니어들에게 AI 기술을 제품에 어떻게 녹여낼 것인지에 대한 철학적인 고민과 기술적 영감을 동시에 제공합니다. 프론트엔드 개발자들은 이제 RSC의 내부 프로토콜을 깊이 있게 이해하고, WebGPU 기반의 클라이언트 사이드 AI를 제품에 통합하는 역량을 갖추어야 합니다. 특히 AI를 통한 개발 자동화의 혜택을 누리기 위해서는 사내 디자인 시스템의 표준화와 문서화를 높은 수준으로 유지하는 것이 무엇보다 중요합니다.

비용, 성능, 안정성을 목표로 한 지능형 로그 파이프라인 도입 (새 탭에서 열림)

네이버의 통합 데이터 플랫폼 AIDA 내 로그 수집 시스템인 'Logiss'는 대규모 로그 파이프라인을 운영하며 겪었던 무중단 배포의 한계, 리소스 낭비, 로그 중요도 미분류 문제를 해결하기 위해 지능형 파이프라인을 도입했습니다. 핵심은 Storm의 멀티 토폴로지 구성을 통한 블루-그린 배포 구현과 실시간 트래픽 상태에 따라 처리 속도를 동적으로 조절하는 지능형 제어 알고리즘의 적용입니다. 이를 통해 서비스 중단 없는 배포는 물론, 인프라 비용을 약 40% 절감하고 장애 시 핵심 로그를 우선 처리하는 안정성까지 확보하며 성능과 비용의 최적점을 찾아냈습니다. **멀티 토폴로지와 블루-그린 배포를 통한 무중단 운영** * 기존 Traffic-Controller는 단일 토폴로지 구조로 인해 배포 시마다 데이터 처리가 3~8분간 중단되는 문제가 있었으나, 이를 해결하기 위해 멀티 토폴로지 기반의 블루-그린 배포 방식을 도입했습니다. * Storm 2.x의 `assign` 방식 대신 Kafka의 컨슈머 그룹 관리 기능을 활용하는 `subscribe` 방식으로 내부 로직을 커스텀 변경하여, 여러 토폴로지가 동일 파티션을 중복 소비하지 않도록 개선했습니다. * 이를 통해 트래픽이 몰리는 낮 시간대에도 중단 없이 안전하게 신규 기능을 배포하고 점진적인 트래픽 전환이 가능해졌습니다. **지능형 트래픽 제어를 통한 리소스 최적화** * 낮과 밤의 트래픽 차이가 5배 이상 발생하는 환경에서 피크 타임 기준으로 장비를 고정 할당하던 비효율을 제거하기 위해 '지능형 속도 제어' 알고리즘을 도입했습니다. * Kafka의 랙(lag) 발생량과 백엔드 시스템(OpenSearch 등)의 CPU 부하 상태를 실시간으로 감시하여, 시스템이 여유로울 때는 로그 처리 속도를 자동으로 높여 적체를 빠르게 해소합니다. * 유동적인 속도 조절 덕분에 기존 대비 투입 장비 리소스를 약 40% 절감하는 성과를 거두었으며, 갑작스러운 트래픽 유입에도 유연하게 대응할 수 있게 되었습니다. **로그 중요도 기반의 우선순위 처리** * 모든 로그를 동일한 속도로 처리하던 방식에서 벗어나, 비상 상황 발생 시 서비스 핵심 로그가 먼저 처리될 수 있도록 우선순위(High, Medium, Low) 개념을 도입했습니다. * 트래픽 지연이 발생하면 중요도가 낮은 로그의 처리 속도는 제한하고, 사업 및 서비스 운영에 필수적인 핵심 로그는 지연 없이 전송되도록 파이프라인 가용성을 확보했습니다. **저장소별 차등 샘플링을 통한 비용 절감** * 실시간 검색을 위한 OpenSearch와 장기 보관을 위한 랜딩 존(Landing Zone)에 데이터를 전송할 때, 각 저장소의 목적에 맞게 샘플링 비율을 다르게 설정할 수 있는 기능을 구현했습니다. * 모든 데이터를 무조건 100% 저장하는 대신, 분석 목적에 따라 일부 샘플링만으로 충분한 로그는 저장량을 줄여 인덱싱 부하를 낮추고 스토리지 비용을 효율적으로 관리할 수 있게 되었습니다. 대규모 로그 파이프라인 운영에서 비용 효율과 안정성은 상충하기 쉬운 가치이지만, 시스템의 상태를 실시간으로 파악하고 제어하는 '지능형' 로직을 통해 두 마리 토끼를 모두 잡을 수 있습니다. 특히 스트리밍 처리 프레임워크의 제약 사항을 직접 커스텀하여 비즈니스 요구사항에 맞춘 최적화 사례는 유사한 데이터 플랫폼을 운영하는 기술진에게 실무적인 통찰을 제공합니다.

[인턴십] 2026 NAVER AI CHALLENGE를 소개합니다. (새 탭에서 열림)

네이버는 현업 엔지니어와 함께 실무 AI 과제를 해결하며 기술적 성장을 도모할 수 있는 '2026 NAVER AI CHALLENGE' 인턴십 지원자를 모집합니다. 이번 프로그램은 아이디어 설계부터 검증까지 전 과정을 경험할 수 있는 기회로, 참가자들에게는 전용 좌석과 최신 장비 등 몰입도 높은 개발 환경이 제공됩니다. 학년이나 전공에 제한 없이 AI 프로젝트에 열정이 있는 학·석사 재학생이라면 누구나 지원할 수 있습니다. **인턴십 선발 및 운영 일정** * **지원 접수**: 2025년 12월 10일(수)부터 12월 16일(화) 오전 11시까지 진행됩니다. * **전형 절차**: 12월 중 서류 전형을 거쳐 2026년 1월 초 직무 인터뷰가 진행되며, 최종 합격자는 1월 3주 차에 발표됩니다. * **활동 기간**: 2026년 1월 19일(월)부터 2월 13일(금)까지 총 4주간 인턴십이 진행됩니다. **지원 자격 및 활동 혜택** * **대상**: 전공과 상관없이 네이버의 AI 프로젝트에 관심 있는 학사 및 석사 재학생은 누구나 지원 가능합니다. * **지원 사항**: 원활한 협업과 멘토링을 위해 인턴 전용 좌석이 제공되며, 프로젝트 활동비와 업무에 필요한 최신 OA 장비를 지원합니다. * **성장 기회**: 네이버 현업 엔지니어가 직접 멘토로 참여하여 기술적 방향성을 제시하고 실무 노하우를 공유합니다. **수행 과제 및 기술 스택** 지원자는 다음의 두 가지 AI 전문 과제 중 하나를 선택하여 프로젝트를 수행하게 됩니다. * **데이터 파이프라인 지능화**: AI 기반의 데이터 파이프라인 로그 분석을 통해 Data Asset을 자동으로 매핑하고, 엔드투엔드(End-to-End) Data Lineage를 구축하는 과제입니다. * **VLM 기반 품질 평가**: 시각-언어 모델(VLM)을 활용하여 사용자 경험 중심의 검색 및 추천 품질을 자동으로 평가하는 시스템을 개발합니다. 네이버의 실무 데이터를 직접 다루며 기술적 난제를 해결해보고 싶은 학생들에게 이번 인턴십은 매우 귀중한 경험이 될 것입니다. 특히 데이터 엔지니어링과 멀티모달 모델 활용에 관심이 있다면, 마감 기한인 12월 16일 오전까지 포트폴리오를 정비하여 지원해 보시길 추천합니다.

디자인시스템이 AI를 만났을 때: FE 개발 패러다임의 변화 (새 탭에서 열림)

디자인 시스템과 AI의 결합은 단순한 도구의 조합을 넘어 프론트엔드(FE) 개발의 마크업 작업 방식을 근본적으로 혁신하고 있습니다. 네이버파이낸셜은 체계적으로 구축된 디자인 시스템을 기반으로 AI를 활용해 마크업 과정을 자동화함으로써 반복적인 코딩 시간을 단축하고 개발 효율성을 극대화했습니다. 다만, AI가 생성한 결과물을 실무에 즉시 투입하기 위해서는 디자인 토큰의 정교한 관리와 개발자의 세밀한 조정 작업이 반드시 병행되어야 한다는 점을 시사합니다. **네이버파이낸셜 디자인시스템의 근간: 토큰과 컴포넌트** * 디자인 시스템의 핵심인 '디자인 토큰'을 통해 색상, 간격, 폰트 등의 시각적 요소를 정의하고 디자이너와 개발자가 동일한 언어를 사용하도록 환경을 구축했습니다. * 재사용 가능한 UI 컴포넌트 단위를 명확히 정의하여, AI가 일관성 있는 코드를 생성할 수 있는 구조적 토대를 마련했습니다. * 단순한 UI 라이브러리를 넘어, 디자인 시스템 자체가 AI가 학습하고 참조할 수 있는 '신뢰할 수 있는 단일 소스(Single Source of Truth)' 역할을 수행합니다. **AI 마크업 효율을 극대화하는 Code Connect와 인스트럭션** * Figma의 'Code Connect' 기능을 활용해 디자인 도구 내의 컴포넌트와 실제 리액트(React) 코드를 직접 연결하여 AI가 맥락에 맞는 코드를 제안하도록 설계했습니다. * 디자인 시스템의 고유한 규칙과 코딩 컨벤션을 담은 상세한 '인스트럭션(Instruction)'을 AI에게 제공함으로써, 범용적인 코드가 아닌 팀의 표준에 부합하는 결과물을 얻어냈습니다. * 이 과정을 통해 개발자는 빈 화면에서 시작하는 대신, AI가 생성한 초안을 바탕으로 비즈니스 로직 구현에 더 집중할 수 있게 되었습니다. **현실적인 개발 도입 과정에서의 한계와 극복** * AI가 존재하지 않는 컴포넌트를 만들어내거나 잘못된 속성을 사용하는 '할루시네이션(환각)' 현상이 여전히 발생하여 개발자의 검토 과정이 필수적입니다. * 복잡한 레이아웃이나 고도의 인터랙션이 포함된 화면의 경우, AI가 단번에 완벽한 마크업을 생성하기 어렵다는 점을 확인했습니다. * 마크업 자동화가 성공하기 위해서는 단순히 AI 툴을 쓰는 것을 넘어, 디자인 시스템의 코드 품질과 문서화 수준이 먼저 뒷받침되어야 함을 실증했습니다. **마크업 자동화 이후의 FE 개발자 역할 변화** * 과거에 직접 태그를 입력하고 스타일을 잡던 수동적인 마크업 작업의 비중이 줄어들고, 생성된 코드를 조립하고 검증하는 '오케스트레이터'로서의 역할이 강조됩니다. * 단순 반복 작업에서 벗어나 더 복잡한 비즈니스 문제 해결과 사용자 경험(UX) 고도화에 개발 자원을 투입할 수 있는 환경이 조성되었습니다. * 결과적으로 AI는 개발자의 대체제가 아니라, 디자인 시스템이라는 약속된 규칙 위에서 함께 협업하는 강력한 동료로서 기능하게 됩니다. 성공적인 AI 기반 개발 환경을 구축하려면 디자인 시스템을 단순한 가이드가 아니라 **AI가 읽을 수 있는 데이터 구조**로 정교화하는 선행 작업이 가장 중요합니다. AI에게 맡길 영역과 개발자가 직접 제어할 영역을 명확히 구분하고, 코드 리뷰 단계를 강화하여 코드 품질을 유지하는 전략이 권장됩니다.

LLM이지만 PDF는 읽고 싶어: 복잡한 PDF를 LLM이 이해하는 방법 (새 탭에서 열림)

네이버는 복잡한 구조의 PDF 문서를 LLM이 정확하게 이해할 수 있도록 돕는 전용 파서인 'PaLADIN'을 개발했습니다. PaLADIN은 표, 차트, 텍스트가 혼재된 문서의 레이아웃을 정밀하게 분석하여 LLM이 처리하기 최적화된 데이터 형식으로 변환하는 데 중점을 둡니다. 이를 통해 증권사 리포트 요약과 같은 전문적인 영역에서 데이터 추출의 정확도를 높이고 AI 서비스의 신뢰성을 확보했습니다. **PaLADIN의 아키텍처와 핵심 기술 스택** * **레이아웃 분석 (Doclayout-Yolo):** 문서 내의 텍스트 영역, 표, 차트 등 각 요소의 위치를 파악하는 'Element-Detector' 역할을 수행하여 문서의 구조를 정의합니다. * **표 및 차트 추출 모델:** 표 구조 분석을 위해 `nemoretriever-table-structure-v1`을 사용하며, 시각적 정보가 중요한 차트 해석에는 `google/gemma3-27b-it` 모델을 활용해 데이터를 추출합니다. * **고성능 OCR 결합:** 네이버의 파파고 OCR 기술을 통합하여 문서 내 텍스트 정보를 정확하게 디지털화하며, 수치와 문자가 섞인 복잡한 본문도 정밀하게 복원합니다. * **파이프라인 최적화:** NVIDIA의 `nv-ingest` 아키텍처를 기반으로 설계를 고도화하여 대량의 PDF 문서를 신속하게 처리할 수 있는 추론 속도를 확보했습니다. **성능 평가 및 서비스 적용 사례** * **정밀한 성능 검증:** 단순 텍스트 추출을 넘어 표 구조 복원 능력과 파싱 속도를 다각도로 측정했으며, 기존 파서 대비 우수한 정확도를 입증했습니다. * **증권사 리포트 요약 서비스:** 수치와 그래프가 많은 증권 리포트를 분석하는 'AIB 증권사 리포트' 서비스에 적용되어, LLM이 잘못된 정보를 생성하는 할루시네이션(환각) 현상을 최소화했습니다. * **LLM as a Judge:** 요약 결과의 품질을 평가하기 위해 LLM을 평가자로 활용하는 방식을 도입, 서비스 적용 시의 실효성을 객관적으로 검토했습니다. **향후 개선 방향** * **정밀도 고도화:** 표 내부의 미세한 셀 좌표 인식 오류를 개선하고, 다양한 형태의 차트에서 데이터를 더 정확하게 뽑아낼 수 있도록 모델을 개선할 예정입니다. * **한국어 최적화:** 국내 사용자 환경에 맞춰 한국어 특화 모델의 성능을 지속적으로 강화하여 문서 이해의 완성도를 높여갈 계획입니다. PDF 내의 비정형 데이터를 정형화된 구조로 변환하는 것은 RAG(검색 증강 생성) 시스템의 성능을 결정짓는 핵심 요소입니다. 복잡한 표나 차트가 포함된 전문 문서를 다루는 서비스를 구축한다면, 단순한 텍스트 추출기를 넘어 레이아웃 분석 모델이 통합된 PaLADIN과 같은 전문 파이프라인 도입을 고려해볼 수 있습니다.

VLOps: 이벤트 기반 MLO (새 탭에서 열림)

VLOps는 학습, 평가, 배포 과정을 Typed Message 단위로 정의하고 이를 감지해 자율적으로 실행하는 이벤트 기반 MLOps 시스템입니다. 기존 파이프라인 방식의 복잡성을 해결하고 시스템 간 느슨한 결합을 통해 클라우드 호환성과 기능 확장성을 극대화한 것이 특징입니다. 이를 통해 사용자는 내부의 복잡한 오케스트레이션 구조를 몰라도 메시지 발행만으로 효율적인 모델 관리 파이프라인을 구동할 수 있습니다. **이벤트 기반 MLOps의 핵심 구조** * 학습, 평가, 배포 등 MLOps의 각 단계를 Typed Message라는 독립적인 데이터 단위로 정의하여 관리합니다. * Event Sensor가 발행된 메시지를 실시간으로 감지하고, 정의된 로직에 따라 적절한 작업을 자율적으로 수행하는 구조를 가집니다. * 메시지 중심의 설계를 통해 각 시스템 간 의존성을 낮추는 느슨한 결합(Loose Coupling)을 실현하여, 특정 클라우드 환경에 종속되지 않는 호환성을 확보했습니다. **기존 파이프라인 방식과의 차별점** * Kubeflow와 같은 전통적인 파이프라인 도구와 달리, 전체 워크플로우에 대한 엄격한 버전 관리가 강제되지 않아 운영의 유연성이 높습니다. * 새로운 기능을 추가할 때 전체 시스템을 재설계할 필요 없이, 단순히 새로운 메시지 타입을 정의하고 추가하는 것만으로 기능을 확장할 수 있습니다. * 사용자는 복잡한 내부 인프라 로직을 이해할 필요 없이 표준화된 메시지만 발행하면 동일한 파이프라인 결과를 얻을 수 있어 개발 경험이 개선됩니다. **Omni-Evaluator와 대시보드를 통한 통합 관리** * Omni-Evaluator는 파편화된 다양한 모델 엔진과 벤치마크 도구들을 하나로 통합하여 일관된 평가 환경을 제공합니다. * VLOps Dashboard를 통해 전체 작업의 진행 상태를 실시간으로 모니터링하고 시각화된 결과 지표를 한눈에 파악할 수 있습니다. * 시스템에 의한 자동 트리거뿐만 아니라, 사용자가 필요 시 직접 이벤트를 발생시켜 특정 평가나 배포를 수행할 수 있는 사용자 주도적 제어 기능을 지원합니다. 모델의 규모가 커지고 복잡해지는 멀티모달 LLM 환경에서는 경직된 파이프라인보다 이벤트 기반의 비동기 아키텍처가 변화에 더 유연하게 대응할 수 있습니다. 인프라의 복잡도를 추상화하고 메시지 기반의 확장성을 확보하려는 조직에게 VLOps와 같은 접근 방식은 매우 실용적인 대안이 될 것입니다.

사용자의 목소리를 AI로 재현하다: LLM기반 Multi Agent UX플랫폼 개발기 (새 탭에서 열림)

네이버의 'NSona' 프로젝트는 LLM 기반의 멀티 에이전트 시스템을 통해 방대한 사용자 리서치 데이터를 실시간 협업 자원으로 전환하며, 서비스 기획과 실제 개발 사이의 간극을 혁신적으로 줄인 사례를 제시합니다. 디자이너, AI 리서처, 개발자가 협력하여 단순한 기술 구현을 넘어 사용자의 목소리를 생생하게 재현하는 페르소나 봇을 개발함으로써, AI가 도구를 넘어 협업의 주체가 될 수 있음을 증명했습니다. 이를 통해 팀은 사용자의 피드백을 실시간으로 서비스 개발 과정에 투영하고 의사결정의 효율성을 극대화하는 성과를 거두었습니다. **사용자 경험을 재현하는 페르소나 봇 "NSona"** * 기존 UX 리서치가 가진 일회성 데이터의 한계를 극복하고, 리서치 결과를 데일리 협업 과정에서 상시 활용할 수 있는 자산으로 전환하기 위해 기획되었습니다. * 사용자의 특성과 행동 양식을 학습한 페르소나 봇 'NSona'를 통해 기획자나 개발자가 언제든 사용자의 관점에서 서비스에 대한 의견을 물을 수 있는 환경을 구축했습니다. **에이전트 중심의 서비스 구조와 기술적 도전** * 단일 LLM 모델의 한계를 넘어, 특정 서비스 목적에 최적화된 'Agent 중심의 서비스 구조'를 설계하여 보다 정교한 사용자 재현을 시도했습니다. * Multi-Party 대화 시스템을 도입하여 여러 페르소나가 상호작용하며 복합적인 피드백을 제공할 수 있는 기술적 토대를 마련했습니다. * 일반적인 언어 모델 평가 지표 대신, 서비스의 맥락과 UX 요구사항을 반영한 'Service-specific' 평가 프로세스를 독자적으로 구축하여 모델의 품질을 관리했습니다. **AI 시대의 변화된 협업 방식과 R&R** * 전통적인 업무 경계를 허물고 디자이너는 프롬프트를 설계하며, 리서처는 로직을 에이전트 구조로 전환하고, 개발자는 AI를 비평의 대상으로 다루는 새로운 협업 모델을 실천했습니다. * 결과물의 완성도에만 집착하기보다 '어디서 시작점을 찍느냐'에 집중하며, AI를 개발 프로세스의 초기 단계부터 능동적인 파트너로 참여시켰습니다. * 이러한 과정은 직군 간의 선형적인 협업 구조를 유기적인 파장 형태의 협업 구조로 변화시키는 계기가 되었습니다. **사용자 중심 AI 개발을 위한 실무적 제언** 성공적인 AI 서비스를 위해서는 기술적 구현만큼이나 기획, 디자인, 엔지니어링 간의 유기적인 결합이 필수적입니다. NSona의 사례처럼 사용자의 목소리를 데이터 더미가 아닌 대화 가능한 실체로 변환하여 협업의 중심에 배치한다면, 보다 사용자의 니즈에 밀착된 서비스를 더 빠른 속도로 검증하고 개발할 수 있을 것입니다.

FE News 25년 12월 소식을 전해드립니다! (새 탭에서 열림)

2025년 12월 FE News는 LLM의 영향력 확대와 웹 표준 기술의 진화로 인해 급변하는 프런트엔드 생태계의 핵심 흐름을 짚어줍니다. React가 LLM 학습 데이터와의 피드백 루프를 통해 독점적 플랫폼으로 굳어지는 현상과 함께, 브라우저 표준 API의 발전이 프레임워크의 의존도를 낮추는 상반된 양상을 동시에 조명합니다. 또한, Wasm의 본질과 Vercel의 언어적 비전 등 기술적 깊이를 더하는 소식들을 다루고 있습니다. ### WebAssembly에 대한 오해와 진실 * Wasm은 이름과 달리 웹 전용 기술도, 어셈블리 언어도 아닙니다. * 실체는 가상 머신에서 실행되는 바이트코드이며, 성격상 JVM이나 .NET 바이트코드와 유사한 범용 실행 환경을 지향합니다. * 'WebAssembly'라는 명칭은 프로젝트 초기 펀딩을 위해 전략적으로 채택된 네이밍일 뿐입니다. ### LLM 피드백 루프와 React의 독주 * LLM 학습 데이터와 개발 도구(Replit, Bolt 등)가 React를 기본값으로 설정하면서 React가 사실상의 표준 플랫폼으로 자리 잡았습니다. * 새로운 프레임워크가 LLM 학습 데이터에 충분히 반영되기까지는 최소 12~18개월이 소요되며, 그 사이 React는 수천만 개의 사이트를 추가로 생성하며 격차를 벌립니다. * 이러한 자기 강화 루프로 인해 신규 프레임워크가 시장을 점유하기 극도로 어려워지는 'Dead framework theory' 현상이 나타나고 있습니다. ### 분산 시스템을 처리하는 언어로의 진화 * Vercel은 'use cache', 'use workflow' 등의 디렉티브를 통해 분산 시스템의 복잡성을 프로그래밍 언어 수준에서 해결하려는 비전을 제시합니다. * 직렬화 가능한 클로저, 대수적 효과, 점진적 계산이라는 세 가지 핵심 개념을 기반으로 단순한 라이브러리를 넘어선 새로운 언어 구조처럼 작동합니다. * 향후 프로그래밍 언어는 어셈블리와 동시성을 넘어 데이터 관리와 분산 환경의 복잡성을 네이티브로 다루는 방향으로 진화할 전망입니다. ### 프레임워크를 대체하는 네이티브 웹 플랫폼 * Shadow DOM, ES 모듈, Navigation API, View Transitions API 등 브라우저 표준 기능이 과거 프레임워크의 핵심 역할을 대체하기 시작했습니다. * 라우팅, 상태 관리, 컴포넌트 격리 등을 표준 API로 해결함으로써 무거운 번들과 복잡한 추상화 없이도 고성능 애플리케이션 구축이 가능해졌습니다. * 프레임워크는 이제 개발의 필수 요건이 아닌, 필요에 따라 선택하는 영역으로 이동하고 있습니다. ### 집단 지성 기반의 AI 의사결정 시스템: LLM Council * Andrej Karpathy가 개발한 이 시스템은 여러 AI 모델이 민주적으로 협업하여 복잡한 문제를 해결하는 새로운 패러다임을 제시합니다. * '독립적 의견 제시 → 상호 검토 및 순위 매김 → 의장 LLM의 최종 종합'이라는 3단계 프로세스를 통해 단일 모델의 한계를 극복합니다. * GPT-5.1, Claude 4.5 등 다양한 최신 모델의 강점을 결합하여 더 신뢰할 수 있는 답변을 도출하며, 로컬 환경에서 Python과 React 기반으로 간편하게 실행할 수 있습니다. 개발자는 특정 프레임워크의 숙련도에 안주하기보다, 브라우저 표준 기술의 진화를 주시하고 LLM이 주도하는 개발 환경 변화에 유연하게 대응하는 전략이 필요합니다. 웹 기술의 근본적인 변화를 이해하고 표준 API를 적극적으로 활용하는 능력이 더욱 중요해질 것입니다.

웹툰 창작 생태계 보호를 위한 연구 (새 탭에서 열림)

네이버웹툰은 창작 생태계를 위협하는 콘텐츠 불법 유출과 생성형 AI의 무단 저작권 학습에 대응하기 위해 AI 기반의 보호 기술을 연구하고 실무에 도입하고 있습니다. 특히 독자적인 워터마킹 기술인 'TOONRADAR'와 학습 방지 기술인 'IMPASTO'를 통해 창작자의 권리를 보호하고 플랫폼의 신뢰성을 유지하는 데 주력하고 있습니다. 이러한 기술적 대응은 단순한 차단을 넘어 불법 유출자의 사후 추적과 AI 모델의 악의적 모방을 원천적으로 방지함으로써 지속 가능한 창작 환경을 조성하는 것을 목표로 합니다. **AI 기반 워터마킹을 통한 불법 유출 추적** * **사후 추적 시스템**: DRM-free 환경에서도 저작권을 보호할 수 있도록 육안으로 식별이 불가능한 미세 신호를 콘텐츠에 삽입하여 유출 경로를 추적합니다. * **기술적 요구 사항**: 사용자의 시청 경험을 해치지 않는 '비가시성', 이미지 압축이나 편집 공격에도 신호가 유지되는 '강인성', 그리고 충분한 정보를 담을 수 있는 '삽입량'을 동시에 확보했습니다. * **네트워크 구조**: 삽입기(Embedder), 공격 레이어(Attack Layer), 추출기(Extractor)로 구성된 AI 모델을 구축했습니다. 특히 미분 가능한 네트워크 레이어로 구현된 공격 레이어를 통해 다양한 이미지 변형 공격에 대응하도록 학습되었습니다. * **성능 지표**: PSNR 46dB 이상의 높은 화질 유지 성능을 달성했으며, 10종 이상의 강도 높은 공격(Level 5) 상황에서도 1% 미만의 낮은 오류율로 워터마크를 추출하는 데 성공했습니다. **생성형 AI 무단 학습 방지 기술 (IMPASTO)** * **보호 왜곡(Protective Perturbation)**: 이미지에 미세한 변형을 가해 생성형 AI 모델이 해당 이미지를 학습할 때 스타일이나 콘텐츠를 제대로 모방하지 못하도록 방해합니다. * **학습 방해 원리**: 디퓨전 모델의 노이즈 제거 과정을 교란하거나 잠재 표현(Latent code) 간의 거리를 조절하여, 무단 학습(LoRA, Dreambooth 등) 결과물이 원작의 의도와 다르게 나오도록 유도합니다. * **차별화된 연구 방향**: 기존의 학습 방지 도구들이 가졌던 시각적 품질 저하(화질 열화) 문제를 해결하고, 실제 창작 환경에서 빠르게 적용할 수 있도록 처리 속도를 개선하는 데 초점을 맞추고 있습니다. **유해 콘텐츠 차단 및 플랫폼 건전성 확보 (XPIDER)** * **자동 탐지 및 차단**: UGC 공간에 업로드되는 선정적·폭력적 콘텐츠를 실시간으로 탐지하여 플랫폼의 대외 신뢰도를 높입니다. * **도메인 특화 모델**: 일반적인 실사 이미지와는 다른 웹툰 특유의 만화 도메인 데이터를 학습하여 검수 정확도를 극대화하고 운영 리소스를 절감하고 있습니다. 웹툰 창작자는 자신의 작품이 무단으로 유출되거나 AI 학습에 악용되는 것을 방지하기 위해, 플랫폼에서 제공하는 보호 기술을 적극적으로 활용할 필요가 있습니다. 특히 TOONRADAR와 같은 기술은 이미 실무에서 강력한 억제력을 발휘하고 있으므로, 기술적 보안이 강화된 공식 플랫폼을 통해 콘텐츠를 발행하는 것이 창작 생태계 보호의 첫걸음이 될 것입니다.

Iceberg Low-Latency Queries with Materialized Views (feat. 실시간 거래 리포트) (새 탭에서 열림)

네이버의 실시간 거래 리포트 시스템은 대규모 데이터를 다양한 조건으로 빠르게 조회하기 위해 Apache Iceberg와 StarRocks의 Materialized View를 핵심 기술로 활용합니다. 단순히 데이터를 적재하는 수준을 넘어, 데이터의 최신성(Freshness)과 저지연(Low-Latency) 응답 속도, 그리고 시스템 확장성을 동시에 확보하는 것이 이번 기술 여정의 핵심 결론입니다. 이를 통해 복잡한 다차원 필터링이 필요한 비즈니스 환경에서도 사용자에게 즉각적인 분석 결과를 제공하는 데이터 레이크하우스 아키텍처를 구현했습니다. **실시간 거래 리포트의 기술적 도전 과제** * 대규모로 발생하는 거래 데이터를 실시간에 가깝게 수집하면서도, 사용자가 원하는 다양한 검색 조건에 즉각 응답해야 하는 성능적 요구사항이 있었습니다. * 데이터의 양이 방대해짐에 따라 기존의 단순 조회 방식으로는 응답 속도가 저하되는 문제가 발생했으며, 데이터의 신선도와 쿼리 성능 사이의 트레이드오프를 해결해야 했습니다. * 다차원 필터링과 집계 연산이 빈번한 리포트 특성상, 인덱싱 최적화와 리소스 효율성을 동시에 고려한 설계가 필요했습니다. **Iceberg와 StarRocks를 활용한 저지연 쿼리 전략** * **Apache Iceberg 기반 데이터 관리**: 데이터 레이크의 스토리지 포맷으로 Iceberg를 채택하여 ACID 트랜잭션을 보장하고, 대규모 데이터셋에 대한 효율적인 스키마 진화와 파티션 관리를 수행합니다. * **StarRocks의 구체화 뷰(Materialized View) 도입**: Iceberg에 저장된 원본 데이터를 직접 조회하는 대신, StarRocks의 Materialized View를 활용해 자주 사용되는 쿼리 결과를 미리 연산하여 저장함으로써 조회 속도를 비약적으로 향상시켰습니다. * **증분 업데이트 및 동기화**: 실시간으로 유입되는 데이터를 Materialized View에 효율적으로 반영하기 위해 Spark와 StarRocks 간의 연동 최적화를 진행하여 데이터의 최신성을 유지합니다. **아키텍처 구성 요소 및 운영 최적화** * **Spark**: 대용량 거래 데이터의 가공 및 Iceberg 테이블로의 수집을 담당하는 컴퓨팅 엔진으로 활용됩니다. * **StarRocks**: 고성능 OLAP 엔진으로서 Iceberg 외부에 위치하며, Materialized View를 통해 복잡한 조인(Join)과 집계(Aggregation) 쿼리를 가속화합니다. * **확장성 확보**: 데이터 노드와 컴퓨팅 리소스를 분리하여 운영함으로써 트래픽 증가에 유연하게 대응할 수 있는 구조를 설계했습니다. 대용량 실시간 분석 시스템을 구축할 때 Apache Iceberg만으로는 쿼리 성능의 한계가 있을 수 있으므로, StarRocks와 같은 고성능 OLAP 엔진의 구체화 뷰를 결합하는 레이크하우스 전략이 효과적입니다. 특히 데이터의 최신성이 중요한 금융 및 거래 리포트 분야에서 이와 같은 기술 조합은 인프라 비용을 절감하면서도 사용자 경험을 극대화할 수 있는 강력한 대안이 됩니다.

경험이 쌓일수록 똑똑해지는 네이버 통합검색 LLM Devops Agent (새 탭에서 열림)

네이버 통합검색은 서비스 복잡도가 급증함에 따라 발생하는 장애 대응의 한계를 극복하기 위해 LLM 기반의 DevOps 에이전트를 도입했습니다. 이 에이전트는 단순히 장애 알람을 전달하는 수준을 넘어, 시스템 메트릭과 로그를 스스로 분석하고 최적의 조치 방안을 추천하며 경험을 통해 지속적으로 진화합니다. 결과적으로 복잡한 검색 인프라 운영의 효율성을 극대화하고 장애 복구 시간(MTTR)을 단축하는 것을 목표로 합니다. **기존 장애 대응 프로세스의 한계** * 네이버 검색은 수많은 마이크로서비스가 복잡하게 얽혀 있어, 장애 발생 시 원인을 파악하기 위해 확인해야 할 메트릭과 로그의 양이 방대합니다. * 기존의 룰 기반(Rule-based) 시스템은 정해진 규칙 외의 변칙적인 장애 상황에 유연하게 대응하기 어렵고, 운영자의 숙련도에 따라 대응 속도 차이가 크게 발생했습니다. * 장애 상황마다 산재한 데이터를 수동으로 취합하고 분석하는 과정에서 발생하는 인지적 부하와 시간 지연이 주요 해결 과제로 대두되었습니다. **Devops Agent의 구조적 진화 (v1에서 v2로)** * **v1 설계 및 한계:** 초기 버전은 기본적인 데이터 수집과 리포팅 자동화에 집중했으나, 다양한 인프라 환경에서 발생하는 복합적인 컨텍스트를 LLM이 완벽히 이해하고 추론하기에는 한계가 있었습니다. * **v2 구조 개선:** v1의 한계를 극복하기 위해 Agentic Workflow를 강화하여, 에이전트가 상황에 따라 필요한 도구(Tools)를 스스로 선택하고 분석 단계를 세분화하여 실행하도록 재설계했습니다. * **SW Stack 고도화:** 최신 LLM 프레임워크와 네이버의 인프라 데이터를 효율적으로 결합하여, 실시간으로 변화하는 시스템 상태를 에이전트가 즉각적으로 파악할 수 있는 기반을 마련했습니다. **시스템 동작과 이상 탐지 메커니즘** * **Trigger Queue:** 모든 장애 징후와 알람을 큐(Queue) 시스템으로 관리하여 분석의 우선순위를 정하고, 누락 없는 대응이 가능하도록 설계했습니다. * **이상 탐지(Anomaly Detection):** 단순 임계치 기반 알람이 아니라, 통계적 모델과 AI를 활용해 평상시 패턴에서 벗어나는 이상 현상을 정교하게 포착합니다. * **평가 체계:** 에이전트가 내놓은 분석 결과와 추천 액션의 정확도를 지속적으로 평가하며, 실제 엔지니어의 피드백을 학습 데이터로 환류시켜 분석 품질을 높입니다. **지속 가능한 DevOps를 위한 향후 과제** * **컨텍스트 확대:** 장애 당시의 로그뿐만 아니라 배포 이력, 설정 변경 내역 등 더 넓은 범위의 데이터를 연동하여 분석의 정확도를 높이고 있습니다. * **액션 추천 및 자동화:** 장애 원인 분석을 넘어 "특정 서버 그룹의 트래픽을 차단하라"와 같이 구체적인 실행 코드를 생성하거나 직접 조치하는 단계로 확장 중입니다. * **지속 가능한 학습:** 새로운 유형의 장애가 발생할 때마다 이를 지식화하여 에이전트가 다음번 유사 사례에서 더 똑똑하게 대응할 수 있는 선순환 구조를 구축하고 있습니다. 이 시스템은 인프라 운영자가 반복적인 데이터 취합 업무에서 벗어나 의사결정과 문제 해결에만 집중할 수 있는 환경을 제공합니다. LLM 에이전트의 도입은 단순한 도구 활용을 넘어, 대규모 시스템 운영 노하우를 데이터화하고 지능화된 자동화로 전환하는 중요한 기술적 이정표가 될 것입니다.

[DAN25] 기술세션 영상이 모두 공개되었습니다. (새 탭에서 열림)

팀네이버의 컨퍼런스 DAN25에서 발표된 35개의 기술 세션 영상이 모두 공개되었으며, 그중 오프라인 현장에서 가장 큰 호응을 얻었던 5가지 핵심 세션의 상세 내용이 공유되었습니다. 이번 컨퍼런스는 AI 에이전트, 소버린 AI, AX 전략 등 네이버의 미래 비전과 실제 서비스 적용 사례를 중심으로 사용자 경험의 혁신 과정을 다루고 있습니다. 대규모 트래픽 처리부터 LLM의 서비스 최적화까지, 네이버의 기술적 고민과 해결책을 담은 실전 노하우를 온라인을 통해 확인할 수 있습니다. **LLM 기반 사용자 메모리 구축 및 실시간 반영** * 사용자의 파편화된 서비스 이용 기록을 '간접적인 대화'로 간주하여 개인화된 메모리를 구축하는 '네이버 PersonA' 프로젝트를 소개합니다. * 대규모 언어모델(LLM)의 추론 능력을 활용해 사용자에게 적절한 시점에 의미 있는 제안을 전달하는 시스템을 구현했습니다. * 실시간 로그를 대규모 사용자 환경에 안정적으로 반영하기 위한 기술적 대안과 AI 에이전트로 진화하기 위한 단계별 로드맵을 다룹니다. **랭킹 기반 플레이스 트렌드 분석 시스템** * 실시간 사용자 데이터를 분석하여 '지금 뜨는 장소'를 포착하기 위해 '급등'과 '지속'의 균형을 맞춘 랭킹 알고리즘을 적용했습니다. * 단순한 인기 순위를 넘어 텍스트 마이닝과 LLM을 결합하여 특정 장소가 주목받는 구체적인 이유를 키워드로 추출하는 과정을 공유합니다. **검색 서비스 특화 LLM 및 AI 브리핑** * 수십억 건의 질문과 답을 처리하는 검색 환경에 최적화하기 위해 범용 LLM 대신 검색 로그 기반의 특화 모델을 개발한 사례입니다. * 다양한 데이터 조합 실험과 최적화 레시피를 통해 범용 성능을 유지하면서도 검색 맞춤 기능을 강화한 기술적 노하우를 설명합니다. * 신뢰성을 높이는 'AuthGR' 기술과 전통적 검색 과정을 통합해 제시하는 'AI briefing'을 통해 검색 품질 개선 방향을 제시합니다. **추천-CRM 통합 모델과 실시간 개인화 UX** * 네이버 웹툰/시리즈 환경에서 관리 복잡성을 줄이기 위해 개별적으로 운영되던 추천 모델과 CRM 모델을 하나의 통합 프레임워크로 설계했습니다. * 배치(Batch) 기반 시스템에서 API 기반 실시간 추론 아키텍처로 전환하여 모델 간 일관성을 확보하고 사용자 경험을 고도화했습니다. **초대규모 로그 파이프라인 'Logiss' 운영 전략** * 초당 수백만 건, 하루 수백억 건에 달하는 전사 로그를 처리하기 위해 Storm과 Kafka 기반의 멀티 토폴로지를 적용하여 무중단 배포 환경을 구축했습니다. * 지능형 파이프라인을 도입해 피크 시간대의 트래픽을 분산시키고, 장애 발생 시 로그 우선순위에 따른 차등 처리로 시스템 안정성을 확보했습니다. * 샘플링 기능을 활용한 저장소 효율화 등 비용과 성능, 안정성을 동시에 잡은 대규모 데이터 인프라 관리 기법을 공유합니다. 네이버의 최신 기술 트렌드와 대규모 시스템 운영 노하우를 깊이 있게 이해하고 싶다면, DAN25 홈페이지나 네이버 TV 채널에 공개된 세션 풀 영상을 참고하시길 권장합니다. 특히 LLM을 실제 서비스 아키텍처에 어떻게 녹여낼지 고민하는 개발자나 데이터 엔지니어에게 실질적인 기술적 영감을 제공할 것입니다.

@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기 (새 탭에서 열림)

웹 애플리케이션에서 하나의 HTTP 요청 내에 발생하는 중복된 API 호출은 성능 저하와 리소스 낭비를 초래하며, 이를 해결하기 위해 요청 범위(Request Scope) 내에서 결과를 캐싱하는 `@RequestCache` 커스텀 애너테이션을 개발했습니다. 이 기능은 Spring의 `RequestAttribute`를 활용해 요청별로 독립적인 캐시 공간을 보장하며, 요청 종료 시 자동으로 메모리가 정리되는 효율적인 생명주기 관리 구조를 가집니다. 이를 통해 복잡한 파라미터 전달이나 부적절한 TTL 설정 문제를 해결하고 시스템의 전반적인 응답 속도를 개선할 수 있습니다. ### 파라미터 전달 및 범용 캐시의 한계 * **응답 객체 전달 방식의 복잡성**: 데이터를 실제 사용하는 말단 서비스까지 객체를 넘기기 위해 중간 계층의 모든 메서드 시그니처를 수정해야 하며, 이는 코드 가독성을 떨어뜨리고 관리를 어렵게 만듭니다. * **전략 패턴의 유연성 저하**: 공통 인터페이스를 사용하는 경우, 특정 구현체에서만 필요한 데이터를 파라미터에 포함해야 하므로 인터페이스의 범용성이 훼손됩니다. * **TTL(Time To Live) 설정의 딜레마**: Redis나 로컬 캐시 사용 시 TTL이 너무 짧으면 동일 요청 내 중복 호출을 막지 못하고, 너무 길면 서로 다른 요청 간에 의도치 않은 데이터 공유가 발생하여 데이터 정합성 문제가 생길 수 있습니다. ### @RequestCache의 특징과 동작 원리 * **RequestAttribute 기반 저장소**: 내부적으로 `ThreadLocal`을 사용하는 `RequestAttribute`에 데이터를 저장하여, 스레드 간 격리를 보장하고 각 HTTP 요청마다 독립적인 캐시 인스턴스를 유지합니다. * **자동 생명주기 관리**: 캐시의 수명이 HTTP 요청의 생명주기와 일치하므로 별도의 만료 시간을 계산할 필요가 없으며, 요청 완료 시 Spring의 `FrameworkServlet`에 의해 자동으로 정리되어 메모리 누수를 방지합니다. * **AOP 기반의 간편한 적용**: 비즈니스 로직을 수정할 필요 없이 캐싱이 필요한 메서드에 `@RequestCache` 애너테이션을 선언하는 것만으로 손쉽게 중복 호출을 제거할 수 있습니다. ### @RequestScope와 프록시 메커니즘 * **프록시 패턴 활용**: `@RequestScope`로 선언된 빈은 Spring 컨테이너에 프록시 객체로 등록되며, 실제 메서드 호출 시점에 현재 요청에 해당하는 실제 인스턴스를 찾아 호출을 위임합니다. * **상태 저장 방식**: `AbstractRequestAttributesScope` 클래스를 통해 실제 객체가 `RequestAttributes` 내에 저장되며, 이를 통해 동일 요청 내에서는 같은 인스턴스를 공유하게 됩니다. 동일 요청 내에서 외부 API 호출이 잦거나 복잡한 연산이 반복되는 서비스라면, 전역 캐시를 도입하기 전 `@RequestCache`와 같은 요청 범위 캐싱을 통해 코드 순수성을 유지하면서도 성능을 최적화할 것을 권장합니다.