DAN 24 CONFERENCE DAY1 후기

 

 

 

 

 

이번년도에 개발자 컨퍼런스에 모두 떨어져서 매우 슬펐는데, 기다리던 개발자 컨퍼런스 신청에 성공하여 드디어...! 다녀왔다! 

 

네이버 DAN 24

↓

https://dan.naver.com/24

DAN 24

 

 

 

네이버 컨퍼런스는 랜덤 추첨이었던 다른 컨퍼런스와 다르게 진행 날짜별로 선착순 신청을 받아서, 알림 설정까지 해두고 빠르게 티켓팅해서 갈수 있었다. 

작년보다 이번년도 컨퍼런스 신청이 왜이렇게 어려웠는지 🥲

 

 

신청전에 Day1과 Day2의 세션 내용을 보고 백엔드 직무에 관한 세션이 상대적으로 많았던 Day1에 지원했다. 

(백엔드 세션보다 AI, LLM 관련세션이 훨씬 많았다) 

 

오전에는 Keynote 세션으로, 네이버에서 추구하는 방향성에 대해서 공유해주시는 시간이었다. 

해당 세션은 발표 현장에서는 제한된 인원으로만 이루어지고, 다른 발표실에서 영상 생중계를 보거나 링크를 열어주셔서 원격으로 참여할 수 있었다. 

나는 원격으로 참여후 오후 세션 시작 시간에 맞춰서 컨퍼런스 장소로 이동했다. 

 

오픈 세션에서는 네이버에서 AI를 이용하여 지난 2년간 많은 투자를 했었는데, 앞으로 이를 활용하여 어떻게 수익성을 진행할 것인지에 대한 발표 내용이었다. 

 

키노트 세션에서는 네이버 트윈 xr, 디지털 트윈화, 공간지능 플랫폼 (도시 문제 시뮬레이션화에 사용가능)가 기억에 남았다. 

네이버의 창작자와 소비자 사이의 플랫폼으로서의 역할에 대한 발표도 좋았다. 

 

 

 

네이버 지도에서 DAN 24의 1층 로비 장면을 아주 찾아가기 쉽게 보여줬기 때문에 찾아가기도 쉬웠다! 

 

 

로비에는 다양한 체험 이벤트 존이 있었다. 

치지직, 네이버 페이, 하이버클로바x, 네이버 클라우드 등 다양한 네이버 서비스에 대한 부스가 있어서 다양한 체험을 할 수 있었다! 

 

행사부스에 참여하면 네이버 페이 앱에 NFT를 추가할 수 있었는데, 이게 너무 신기하고 예뻐서 모으는 재미가 있었다. (크흐bb)

 

 부스 7개를 모두 참여하면 룰렛을 참여할 수 있었다.

 

(치지직 부스에서는 항상 줄이 길어서 기다렸다가 참여할 수 있었는데,  

게임 스트리밍 virtual 환경과 캐릭터와 같이 사진찍는 체험이었고... 룰렛 돌릴려고 기다렸다가 사진찍는 순간에 동기가 나타나서 너무 부끄러웠다,,, 🤦‍♀️)

 

 

 

 

 

 

NFT는 이런식으로 추가가되는데 너무너무 예뻤다,, 모으는 재미,,, ✨

 

 

 

 

굿즈도 담요,리유저블 백과, 스티커, 뱃지, 초콜릿 등등 많았다! 

 

 

 

부스 7개 모두 참여하면 돌릴 수 있는 룰렛이었는데, 나는 초콜릿이 당첨됐다! 

 

 

세션도 백엔드, 프론트엔드, AI, LLM 등등 많은 세션이 준비되어 있어서 좋았는데, 

세션 중간에 원하는 세션으로 이동도 가능하도록 되어있어서 굉장히 좋았다! 

 

또, 세션 시작전에 DAN 24 공식 사이트에서 발표 자료를 공유해주셨는데 

이게 굉장히 좋았던게, 내용기록하랴, 사진찍으랴 발표를 놓치지 않으려고 아등바등 댔던 기억이 있어서 

덕분에 발표에 집중할 수 있었다. 👍

 

 

 

 

네이버 컨퍼런스를 다녀와서 예전 우아콘 참여와는 다른 새로운 면을 많이 발견했는데, 

우아콘때는 백엔드 개발자로서 다양한 내용을 들을 수 있었다면 이번엔 '백엔드 개발자에만 국한되어 있으면 개발자로서의 더 많은 가능성을 활용할 수 없겠다'라는 생각이 들었다. 

 

인공지능을 필요한 때에 적재적소에 활용할 수 없는 개발자로 지속된다면, 

어느순간 인공지능에 밀려나게 될 것이라는 것.

 

이번 컨퍼런스로, 인공지능의 근본을 개발하는 개발자가 되지는 않더라도, 

필요할 때에 필요한 인공지능을 적용해서 구현하고자하는 방향에 도달할 수 있는 개발자로서의 준비를 해야겠다는 생각이 들었다. 

 

그렇다면, 인공지능을 활용할 수 있는 여러 서비스에 대해서도 많이 배워야겠다는 생각...! 

 

여러모로 많은 자극이 되었던 네이버 컨퍼런스-! 🌱

 

덕분에 즐겁게 다녀왔다! 💪

 

 

 

 

 

 

 

 

 

 

컨퍼런스에서 들었던 세션을 가볍게 정리했다! 

(지식이 짧아서 모르는 분야도 많았기 때문에 틀린 내용도 많을 것 같다,,,🥹)

↓

 

 

 

오픈 세션

duster ai

• 디지털 트윈화 시켜주는 AI 시스템
• 네이버 트윈 xr

공간지능 플랫폼

• 도시의 문제 시뮬레이션 화 가능

Session1) 홈피드

검색 홈에서 사용자에게 다양한 종류의 컨텐츠를 보여주어 개인화를 통해 제공

• Rank1 optimization
  • 기존 랭킹모드와 다른 랭크 모델을 사용
  • 랭커, 랭커 최적화를 통해 최종 모델 도출
  • 추천 풀에 인기 기반의 풀을 생성

검색 로그로 부터 주 키워드 추출

• 검색 로그 → 주요 키워드 추출(추출에 적합한 탐색형 - 시의성 키워드 설정 ⇒정보 키워드에 대해서는 문서 품질이 좋지 않기때문에 제외, 사용자별 키워드 선호도 부여, 키워드 노출 패널티 적용) → 홈피드에서 볼 수 있도록 설정 (TF-IDF, TSDAE ⇒ 문서 추천 기반으로 품질이 낮을 수 있어 UserFeedback을 활용)
• 지표 분석시 light 사용자 군 대상 지표 상승
• click to click

Session 1-1) 검색 SRE와 비상대응 시스템

1분 이내에 서비스 동작 변경을 위해 배포없이 서비스 설정 교체

• Google SRE workbook
• Spring cloud Config

원하는 컨피그 서버를 구성

• CDCM
  • 데이터 설정 서빙만 제공
  • 데이터 서빙을 통해 설정 데이터를 패치해오고 서버를 재배치
  • 전체 서비스 자체를 재배포 없이 변경 필요한 설정 배포만으로 서비스 설정 변경 가능

1. 기존 서비스의 설정 관련 방식을 먼저 변경
2. 하드코딩 되어있던 설정을 json데이터 형태로 재 정의
3. 서비스의 언어 구현에 상관 없이 데이터 설정이 가능해짐
4. cdcm 세부 설정과 무관하게 데이터 설정만 반영 가능

• cdcm은 독립적으로 구성되어있지만 json 데이터 기반으로 동작
• 설정은 json으로 관리하고 데이터 유효성은 json 스키마를 통해서만 구현
• json 데이터가 주어지면 json 스키마를 통해서 validation후 반영

+) 설정 변경이 필요할 때 빠르게 적용 가능

• → 단, 서비스 장애를 유발할 수도 있었음
• ⇒ web ui의 api를 통해서 데이터 변경이 가능하고, 데이터 write 변경이 일어날 경우 정책상 검증을 통한 후 반영할 수 있도록 구현
  • 웹 화면에 대한 별도 비용 절약가능 및, 데이터 방식을 일관성 있게 가져갈 수 있었음
  • 장치를 다시 빌드하고 배포하더라도 최소 15분 에서 20초로 축소 가능하였음
  • 서비스 중단을 최소화 하는 중요한 도구가 됨

Session 1-2) 검색 SRE와 비상대응 시스템

앞선 비상모드를 활용하여 적용한 사례 소개

• 통검 트래픽 폭증이 발생했거나 예상되면 자동 / 수동으로 비상모드를 통해 성능과 품질을 trade off
• 앞서 소개된 비상모드를 활용해서 순간적 가용량 확보가 가능

검색 품질 문제 발생

• 폭증이 발생하거나 예상되는 경우
  • ex) 선거일 등
• ⇒ 검색 트래픽을 활용

통검 가용량 지표만으로 활용은 안되는가?

• 통검 뿐 아니라 하단의 개별 검색 서비스도 보호하기 위한 목적

트래픽 탐지

• 가장 먼저 이벤트에 반응하면서 서비스의 이벤트를 나타내고있는 통검의 트래픽을 이용해서 비상모드를 발동하 고 있음

트래픽 폭증을 예상할 수 있는가?

• 모든 폭증을 예상하여, 잘못된 비상모드를 키는 것보다는 올바른 상황에서 동작하도록 하는것이 바람직 함
• 경험과 기록을 통해서 전국단위의 재난문자 발송시 트래픽이 폭발함을 파악
  • 트래픽의 폭등이 사람들의 생활 주기와 밀접하게 연관
  • 급격한 트래픽 폭증 또한 이벤트를 통한 사람의 반응으로 발생하기 때문에 예상 가능
  • 실제로 지진 시 트래픽을 보면 바로 파악이 가능할 정도의 스파이크 성 트래픽 발생

어떻게 트래픽 폭증을 감지할 수 있는가?

• 담당자가 이벤트를 탐지하고 비상모드를 바로 발동하기에는 너무 빠른 순간에 발생
• 비상대응 시스템을 구축하여 10초 단위로 트래픽 데이터 평가하여 비상모드 탐지
  • 사람이 개입해야 하는 경우도 있음
    • 트래픽 진행이 점진적인 경우
    • 어느정도의 트래픽을 미리 예측할 수 있는 이벤트의 경우
    • 담당자가 바로 비상대응 모드를 킬 수 있도록 대시보드와 컨트롤 패널 활용
      • 실수로 발동하지 않도록 2차 인증 진행중
    • 발동 직후 발동 원인과 내용을 담당자에게 바로 발송하여 불필요한 커뮤니케이션 감축
  • 아직까지는 자동으로만 탐지 진행중

비상대응 시스템에 영향을 미친 SRE 시스템

• 검색 장비 (검색 SRE 시스템)
  • 통검, 통검 하단의 개별 서비스 등을 모니터링
• 통검 트래픽의 폭증을 모니터링 및 저장 하고 즉각적으로 경보 발송
  • CDCM등을 호출하는 등, 검색 SRE 시스템 뿐 아니라 여러 컴포넌트와 상호작용
• 미리 가공하거나, 수집 하는 등의 별도 파이프라인을 통해서 10초 주기 단위로 진행

신속성, 안정성

• 10초 주기 자동화 모드 발동
• 명확한 기준의 자동 발동 기준 , 2차 인증 등

부안 지진 사례

• 검색 SRE 시스템을 통해 트래픽 증가 및 시스템 파악
• 완료되는 시간 총 7분 정도 소요

비상모드가 활성화 되는 것 효과적이었는가?

• 비교 지표가 쉽지 않음
• 비상 모드 종료 전후를 통해서 간접 확인이 가능
• 동일 쿼리가 많이 들어오기 때문에 캐시 활용으로 인해 트래픽 전 후의 비교를 위해서 비상모드 효과 지표는 필요함

검색 뿐 아니라 서비스 담당자도 서비스 이상 감지 후 비상모드 발동

• 채팅방을 통해서 서비스별 장애 상화 한번 더 취합
• 비상상황 종료는 전사 단위의 모니터링 후 진행하기 때문에 30분 이상의 시간이 소요됨
  • 의사결정을 내리기까지 오래 소요됨
• ⇒ 이벤트의 규모와 영향도 파악을 위한 트래픽, 서비스 가용량, 사용자 품질 자동 수집을 통해서 빠른 의사결정에 도움을 줌
• 전사 비상대응 모니터링을 통해서 실시간 장애 상황 파악이 가능했음

Session 2) 네이버 페이 결제 시스템의 성장과 변화

2-1) 네이버 페이 결제 시스템

체크아웃 서비스

• 스프링 기반의 rpc를 이용해서 적용 되었었음
• 성능 기반
• 패키지 형태로 제공했기 때문에 이슈없이 제공이 가능했음
• → 마일리지 서비스가 네이버 페이 포인트가 됨

애플리케이션의 경우 stateless하기 때문에 확장이 가능하지만, DB의 경우 확장이 쉽지 않음

→ 플라즈마 프로젝트를 통해서 주문, 배송, 정산, 혜택등 다양한 분산 DB로 진행

단일 DB를 통한 서비스 확장은 단일 서비스의 한계에 직면할 수 밖에 없음

네이버 페이의 경우 read 트래픽이 증가하지 않고 동시성 전략

• 샤딩을 할 수 밖에 없었음

샤드키 설정

• 주문과 주문 데이터에는 상품에 대한 판매자 정보가 들어올 수 밖에 없음
• 구매자 샤드와, 판매자 샤드를 별도로 사용하기로 결정

분산 DB 전환

• 애플리케이션의 변경을 야기
• 비즈니스의 변화를 겪을 수 밖에 없음
  • 비즈니스 요구사항의 변경
  • 서비스를 다시 개선해서 제공할 수 밖에 없음
• 연속성 서비스가 제공해야 하는 경우 가장 안정적인 방식은 점진적 전환
  • 마틴 파울러의 stangler facade (점진적 변환)
  • 점진적으로 레거시에서 뉴 서버로 전환 및 롤백의 레이어 존재
  • 단일 DB → 샤딩 DB로 데이터 레벨에서 서로 복제 및 동기화
  • 먼저 단일 DB로 요청 후 문제가 없다면 샤딩 DB로 스위칭하여 다시 한번 더 검토
• 모듈단위의 전환이 되기 때문에 롤백이 되어야 할 수 있음
  • 주문의 경우 완벽한 전환이 되었더라도, 외부 배송 시스템 문제가 야기될 수 있음
    • 롤백이 불가피
  • 쇼핑의 경우 사업자 데이터 제공시 세금신고시 문제가 발견될 수 있음
    • 롤백이 불가피
  • 데이터 복제의 CDC가 핵심
    • DB 밴더에서 제공하는 데이터 변경 이력을 감지하고 감지된 이력을 이중 DB에 복제, 카프카 커넥터에 띄워서 다른 목적으로 활용 등으로 사용됨
    • 제한적으로 사용할 수 없다면, (mongoDB나 mysql 의 데이터 변경을 파악할 수 있는데, 사용할 수 없었음) trigger를 적용해서 변화를 탐지하였음
      • 빈로그방식보다는 트래픽에 대한 부하가 심한 상황
    • 별도 테이블에 쓰도록 트리거를 생성하여 설정
      • 데이터의 pK를 저장하고 CDC는 pk의 데이터를 읽어와서 샤드DB에 복제하는 방식
    • 샤드키를 포함해서 구매자 DB의 특정 DB에 샤딩
  • 데이터 정합성은 어떻게 해결할 것인가?
    • 분산 DB의 CDC는 bin로그를 제공하기 때문에 판매자 DB에 데이터 복제하도록 구성
    • 구매자가 서로 다른 스토어에서 장바구니에 담아 결제했다면, 구매자 특정 샤드에 데이터가 존재하고, 판매자는 상품이 각각의 샤드에 나눠서 저장됨
      • 이때 order Item의 라인 형태는 여러개이지만,
      • 조인해야 하는데이터가 실제로는 1개밖에 없다면, 각각 샤드에 맞게끔 분리해서 보관
  • 양방향 순환 문제
    • new에서 write 된 데이터는 단일 DB에 복제 되어야 함
    • 변경된 데이터를 애플리케이션인지, CDC에서 발생된 것인지 알 지 못한다면 무한 cycle 발생 가능
      • 복제되는 모든 테이블에 column에 sync라는 컬럼을 추가하고 애플리케이션은 파라보지 않고 cdc만 이를 사용하도록 구성하여 cdc작업을 파악할 수 있도록 구성
  • 지연 이슈
    • 판매자의 경우라도 판매자가 본인의 발주 발송 주문 리스트를 가져올 때, 지연이 되는 데이터를 가져오고 해당 주문건의 데이터에 write를 할 때는 구매자에게 write하고 다시 판매자에게 내려올때 지연이 될 수 있는데, 페이지 상태의 경우 해당 주소를 통해 사이트 접속해서 페이지를 내려받을때 순간이고, 시간이 지나면 상태를 보장할 수 없음으로 문제를 해결
    • 이렇게도 해결이 불가능한 경우 dual write driver를 사용해서 문제를 해결함
      • 애플리케이션에 부담을 줄 수 밖에 없기 때문에 좋은 선택지는 아님
      1. 단일 DB 업데이트
      2. 트리거에 의해서 이력이 쌓인 기반으로 업데이트를 다시 select
      3. 구매자 DB에 업데이트 시도
         1. Insert와 업데이트가 아주 빠른시일내에 이뤄진다면 데이터가 없을 수 있어, 업데이트 된 데이터를 select 하고 다시 처리하도록 했음
      4. 단일 DB 최종 커밋후 구매자 DB commit
         • 샤딩 DB에서 커밋에 실패한다면 ?
           • 여전히 CDC가 있기 때문에 dual write 되더라도 한번 더 쓰기 작업을 수행
      • ⇒ 여전히 단일 DB가 필요함
• 샤딩을 했지만, broadCasting 쿼리를 날릴 수밖에 없음
  • 연관있는 두개의 데이터를 모두 주세요 등
  • ⇒ 부하 발생
    • 결국 단일 DB가 여전히 필요해짐
    • 특수 목적에 제공가능하도록 지속 제공
  • 지연 문제
    • 샤딩의 변경 사항이 지연 없이 단일 DB로 복제 되는가?
      • 여전히 dual write가 필요할 수 있음
• 점진적 전환할 때 필요한 사항
  • 소스 DB와 타겟 Db의 데이터 호환 필요 (양방향 복제)
  • 복제 지연 이슈
    • dual write
  • 샤딩 DB로 전환은 최종 해결책이 아님
    • 한번 더 고려해볼 것
    • 리드 트래픽만 많다면 READ DB scale out, masterialized View를 고려해볼 수 있음
    • 유저 / 파트너 관계가 있을때에 다중 샤딩 DB를 고려하자
      • 하나의 데이터를 여러 샤드가 봐야 한다면, 멀티로 단일 DB를 쓸 수밖에는 없음에 유의

2-2) EDA

최고 장점

• 결제 시스템과 같이 카드사 연동이 된 모듈은 확장이 불가능함
• 대량의 트래픽 발생시 트래픽을 카드사와 은행에 그대로 전달할 수 없음
• 이럴때 EDA가 최고의 솔루션이 될 수 있음
• throughput을 조절할 수 있음
  • 병렬작업 등을 통해 막힌 부분 효과적으로 풀 수 있음
• 시스템 각 모듈 별로의 원하는 성능을 끌어낼 수 있음
  • 네이버는 배송과 주문에 적용

단점

• EDA 방식의 경우 결국 비동기 이기 때문에, 짧은 지연 시간이라도 들쑥 날쑥 하기 때문에 어떻게 적용할 지 고민해야 함
• 메세지 유실의 경우, 중복 발생 등의 케이스에 대응이 필요
• 메세지 추적 가능 여부
  • 페이에서는 구축 했음

메세지 유실 방지 안전장치

• 최초의 메세지가 만들어진 상태를 수신하고, 5분 후 문제없이 처리되었는지 별도로 검증하는 장치를 둠
  • Order-Verifier
• 컨슈머가 정상적으로 동작하지 않는 경우 등 알림을 통해 확인
  • ex) n시간동안 최종 주문 상태가 만들어지지 않으면 주문 취소 처리 등

DLQ

• 메세지가 정상동작한다면, 사실 필요없음
  • EDA를 적용하더라도 문제가 발생할 수 있기 때문에 사용
• API가 일시적인 문제 등으로 메세지 처리가 불가능했다면, retry를 통해 해결 가능
  • 그럼에도 안된다면 빠르게 DLQ로 넘겨 뒤의 메세지 처리할 수 있도록 해야함
• 일시적인 문제로 소비하면 해결되는 문제도 있고, 아닌 문제도 있음
• 처리시 고려사항
  1. 순서 보장이 필요한가
     1. consumer가 주문처리번호와 같은 데이터를 redis에 넣고 해당 번호의 경우 DLQ로 넘겨 순차적인 순서 보장을 할 수 있도록 구현
  2. 순서보장이 상관 없는가
     1. DLQ에서 바로 처리 가능

이벤트 처리 지연 해소

• 파티션, 컨슈머 수 증가
  • 최대 수 확인
• topic 분리
  • 하나의 토픽에 여러 producer 등
    • producer 주체에 따라서 분리 가능
  • 긴 이벤트와 짧게 처리 가능 이벤트가 함께 있다면 분리해서 처리
• ex) 배송 상태
  • 발송, 집화, 배송중, 도착예정, 배송 완료
  • 무시가능한 상태
    • 배송중, 도착예정 ⇒ 비중요 상태
  • 연계 서비스의 delay 현상으로 빠른 처리가 불가능하다면, consumer가 중요한 상태에 집중하도록 구현
  • ⇒ 우선 순위 Queue를 활용해서 우선순위에 따른 처리가 가능하도록 할 수 있음

장애 시점 lag 소진

• EDA 장애 발생시 컨슈머 렉이 빠르게 증가
  • 비상시에는 이벤트 처리 타임아웃을 짧게 설정해서 lag 소진하도록 구성
    • 컨슈머가 이벤트 발생 시점을 활용해서 처리

2-3) 무중단 결제를 위한 다양한 시도

• 결제 최상유지를 위해 불필요한 작업은 비동기화
  • • 불필요한 연동은 제거
  • ex) 적립의 경우 결제와 관계 없이 비동기로 추후에 이루어져도 됨
  • 로직 변경도 심혈을 기울여서 롤백에 대한 대비를 함
    • 3주 ~ 1달의 거쳐 천천히 적용
    • v1, v2 등을 설정하여 해당 서버에서 작동하도록 구현
• 주문서 대기열
  • 스토어에 대한 대기열이 필요하고, 주문서에 한번 진입하면 뒤는 관계 없기 때문에 입구까지만 잘 설정함
    • 상품이 아닌 스토어 단위
    • 주문서를 떠나지 않는 경우
      • ⇒ 이미 상품이 품절되었는데도 지속적 주문 시도 하는 경우 상품 품절시 페이지 나가도록 설정
    • hat을 통해서 폴링 작업
      • 트래픽을 낮추기 위해서 폴링 단위를 점차적으로 길게
• 무중단 결제
• IDC 이중화를 통한 결제 안정성
  • stateless한 서버는 active-active
  • stateful한 서버는 active-stanby
    • 빠르게 failover할 수 있도록 구성

2-4) 결제에 특화된 SRE

• 결제 거래 패턴
  • 결제 완료 트래픽은 상당히 이전 주의 트래픽을 따라 변경점이 크게 없음
• 장애의 경우
  • 예외가 발생하지 않는 장애 상화도 있음
  • ⇒ 결제수치에 따라서 너무 많이 결제가 이루어지지 않으면 비상 상태 모드를 킬 수 있도록 구성
• 빠르게 영향점을 차단하고 복구할 수 있도록 구성
• 원천 시스템의 circuit breaker를 통해서 처리 응답을 빠르게 분석하고 breaker를 걸 수 있도록 설정
• 장애 점검을 통해 지속적으로 모니터링 동기화 구성
• 결제 SRE 활동
  • 서비스 품질 내 외부 목표에 따라서 매트릭 정보를 잘 모으고 문제가 되는 부분을 유심히 관찰, 분석할 수 있도록 설정
  • SLO 설정을 점차 높게 설정 등

Session 3) 데이터 기반으로 지속적 성장이 가능한 네이버 검색 FE 시스템 구축

템플릿 기반은 확장성이 부족,

component기반은 복잡성 증가

• 적정 수준의 UI 블록화 중요

Flexible Rendering

• 제약된 환경에서 자유롭게 변경
  • 모듈내에서는 자유롭게 가능

developer experience

• meta analyzer를 통해서 프로젝트를 Meta 포맷으로 변환

Session 4) 네이버 검색에서 웹 성능 관리하는 방법

• 웹 성능이 중요한 이유
  • 비즈니스 성공에 영향
  • 안정적인 서비스 운영
• 웹 성능 측정 방식
  • 과거 성능 측정 방식
    • load 이벤트 수신
    • -) 사용자 체감 성능과 차이가 있음
      • 리소스를 load 이벤트 뒤에 로드
        • 렌덩링 전에 로딩 이벤트 발생 가능
  • 새로운 성능 측정 방식
    • web vitals
      • 사용자 체감 성능 CORE 지표
        • LCP
          • Largest Contentful Paint
          • 사용자 인터렉션에 따라서 측정됨
          • LCP score
            • 몇 ms에 들어와야 하는가
            • 구글은 웹 페이지 접근자 100명중 75명 이상 LCP가 2.5초 이하가 되는 것을 권장
        • INP
        • CLS
• 네이버 검색 웹 성능 가이드라인
  • 대표 지표
    • LCP로 설정
      • 수치화 가능, 비교 가능, 임계값 설정 가능
      • 서버 응답 시간과 클라이언트 렌더링 시간에 모두 영향
      • 지표 변화에 따른 문제점 분석이 가능
  • 황금 지표
    • 구글보다 조금더 타이트하게 전체 검색 사용자 95% 2.5초, 검색 영역 단위 75% 2.5초 이하
• 성능 지표 수집
  • 수집 방식
    • google web vitals library
  • 수집 빈도
    • 언제, 어떻게 수집하는가
    • 성능이 측정될때마다 혹은 마지막에 한번 전송
      • 마지막에 한번 전송하는 것으로 선택
        • ⇒ 매번 전송하면 리소스를 많이 사용하고, 어떤 값이 정확한 값인지 판단하기 어렵기 때문 (가공하는데 리소스 사용됨)
        • visibility change event 발생 시점에 한번 전송
    • SendBeacon을 이용해 전송
      • 유실률을 최소화
      • 아티클이 있음
• 수집 데이터 노이즈 제거
  • 수집 데이터 필터링
    • navigation type 에 따른 필터링
      • bfcache 동작시 성능 지표가 매우 빠름
      • ⇒ backforward cache를 저장하는게 맞을까 하는 의문
        • 렌더링 속도가 매우 빠르기 때문
        • ⇒ 성능 지표 로깅 대상에서 제외함
    • 브라우저에 따른 필터링
      • 활성화 상태가 아닌 경우 성능이 느림
        • 20~50배 정도
• 성능 모니터링
  • 성능 리포트
    • 성능 변화 감지
      • 장기간 데이터 저장소에서 위키에 저장해서 수동으로 매주 매월 작성
        • 자동화 하기 위해서 네이버 검색 웹 성능 데이터 베이스를 만들고 배치 형식으로 데이터를 insert하도록 수정
        • 단, 리포트 발행 시점에만 성능 변화를 감지할 수 있게되었음
  • 성능 대시보드 페이지 구성
    • 실시간 데이터, 분단위 구성을 진행
    • 무조건적으로 DB를 쓰지는 않고, 실험적인 데이터는 object storage에 오브젝트 형식으로 넣고 대시보드에서 가져오도록 설정
  • 더 빠르게 자동으로 감지하기 위해서 사용자가 들어올때마다 trigger를 설정하고 임계치 접근시에 알람메일을 발송해서 모니터링 하도록 구성
• 성능 분석 및 개선 사례
  • 사용자 패턴에 의한 성능 변화
    • 배포가 아닌, 사용자의 패턴에 의해서도 성능 변화가 많이 발생하는 것을 확인하게 됨
      • LCP가 좋은 영역이 많이 노출되면 LCP가 개선된 것 으로 지표가 집계됨
    • 일시적으로 검색 트래픽이 급증
      • 비교적으로 LCP 가 좋지 않은 영역이 노출되지 않았기 때문
  • 네이버 검색의 특수 상황
    • 검색 결과가 매우 다양하고 LCP 영역이 동일하지 않음
    • 개선 포인트
      • 전체 검색 결과 개선 vs 특정 검색 결과 개선
        • 전체 검색 결과 개선하기로 결정
        • 네이버 검색 렌더링을 도식화후 문제 파악
          1. load 이벤트 이후의 과정에서 많은 시간이 소요됨을 파악했음
             • load 이후에 javascript를 호출하는데, laod 시간이 많이 소요되는 경우
          2. 사용성 이슈
             • 로드 이벤트가 늦어지면 가져오지 못하는 것으로 보임
          • ⇒ Javascript 로드 시점을 DCL로 변경
            • 레거시로 인해 변경에 따른 영향도를 알기는 어려웠음
            • ⇒ ABT 와 성능 로그, 에러 로그 기반으로 영향도를 파악
            • 성능 지표 개선 후에 비즈니스 지표까지 개선되었음
• LCP로 측정하기 어려운 성능
  • 측정 불가
    • 화면 밖 성능 측정이 불가
      • 무한 스크롤 성능 측정 불가
  • 서치 피드 성능
    • 무한 스크롤 형태의 검색
    • RUM(real user monitoring)성능을 측정할 수 없을까?
  • 서치 피드 노출 과정
    • 로딩 영역 렌더링
    • DOM 렌더링
    • 이미지 렌더링
  • 이미지 렌더링이 오래 걸리게 된다면?
    • 로딩 영역을 오래 보게 됨
    • DOM 렌더링 이후에 이미지가 로딩되지 않으면 무슨 이미지인지 확인이 불가능
    • 렌더링 도식화 후 어떤 파트가 사용자 체감 성능 지표와 가장 밀접한지 판단
      • FUPP (첫번째 이미지가 로드되는 시점까지) ⇒ 첫 블록
        • 피드 사용자 체감 성능 지표
      • 이미지 로드 타이밍
        • 이미지가 어느 시점에 사용자에게 보여졌는가
      • 지표
        • late
        • viewport
          • 15%
        • early
          • 75%
        • stanby
          • 10%
  • 서치 피드 성능
    • 최적화된 서치 피드 호출 시점
      • 너무 빠르게 호출하면 사용성은 증가하지만, 서버 부하가 높아짐
      • 너무 느리게 호출하면 서버 부하는 낮아지지만, 사용성 역시 낮아짐
      • ⇒ 화면 하단으로 부터 1000px 떨어지면 호출하도록 설정
  • 호출 위치가 100px 마다 서버 호출량 5% 증감, 도달률 2% 증감 함을 알아낼 수 있었음
    • +) 소비지표도 함께 검사
      • 너무 빠르게 호출하는 경우도 소비지표 감소
        • 서치 피드 소비를 원하지 않은 사용자까지 도달하기 때문
      • 너무 느리게 호출하는 경우도 소비지표 감소
        • 사용성 감소

Session 5) 클립 크리에이터와 네이버 유저를 연결하기: 숏폼 컨텐츠 개인화 추천

• 클립 서비스 형상
  • UI, UX에 맞는 추천 시스템
  • 연초 대비 600% 이상 성장
• 숏폼 클립
  • 흥미로운 클립으로 연속적으로 추천 방식
  • 재미 / 간단한 정보 위주의 컨텐츠
  • 연속적 탐색 사용 패턴
  • 신규 크리에이터 (cold start item과 연관)
  • 기존 네이버 유저에게 새로운 컨텐츠 포맷 추천 (cold start user와 연관)
• 시스템 구성
  • two stage recommender system
    1. candidate Retrieval
    2. Ranker
• 실시간 클립 시청 이력 기반 개인화 추천
  • 빠르게 컨텐츠 탐색
    1. 유저 컨텍스트 탐색
       • 배치 파이프 라인에서 모델링 진행
         • 피쳐 스토어에 올려두고 진행
       • 클립의 메타데이터와 조인하여 사용자 타겟을 파악 가능
    2. Retrieval
       • CF-based
       • 키워드 카테고리에서 최신 컨텐츠를 통계 기반으로 서치
    3. Ranker
       • retrieved 된 후보에 대해서 key value 기반으로 데이터 모델링
       • ⇒ neuralinker architecture
    4. Context Fetch (유저)
       • 사용자 선호도를 실시간 로깅해서 전반적 모델링
       • 재생 수 대비 재생시간 등 종합적으로 모델링
    • 숏폼 뷰어 하단으로 내려갈 수록 실시간 short-term preference 기반 모델의 중요도가 높아짐
  • 실시간 시청 이력 반영 주기를 단축
    • 기존에 추천된 10개를 모두 시청 / 스킵한 이후에 실시간 시청 이력이 반영된 추천 목록을 다시 받을 수 있었음
    • 4개로 변경하여 implicit feedback을 고려
    • ⇒ 연동 구조만 바꾸었음에도 탐색수, 재생시간 증가
  • 로그 stream 연동시에 트래픽 상황에 따라 수초 가량의 지연 발생 가능
    • 클라이언트 → 로깅 서버 → 실시간 서빙 db 연동 → API에서 조회하여 활용
    • ⇒ 클라이언트에서 시청 이력을 status로 관리해서 API에 파라미터로 전송하도록 변경해 연동 지연 없이 (0초) 실시간 시청 이력을 추천에 활용
  • Explicit negative feedback (realtime)
    • 관심없는 채널과 비슷한 내용을 클립 채널로 확대하여 rank down
    • 컨텐츠 노출 기준도 조절
    • ⇒ 이탈률 감소에 기여
  • Future works
    • 특정 클립 추천 이후 여러 step에 거친 피드백을 고려
      • mid-term / long-term reward를 타켓으로 ranker 최적화 (RL-based)
• 콜드 스타트 클립 추천
  • user-side KPI
  • creator-side KPI
  • ⇒ Contextual Bandit 알고리즘
    • 크리에이터 기반의 서비스 제공 및 정량 지표화 하여 트래킹 중
• 검색 이력 기반 개인화 추천
  • 클립의 시청이력으로 발견된 콜드 스타터가 많음
    • 인기 클립과 같은 인기 추천목록이 추천되는데, 관심사가 아닌 추천이 제공되게 됨
    • 이런 사용자들에게는 네이버 서비스 내의 다른 사용 로그를 활용해서 추천 가능
    • ⇒ 검색 이력을 활용하도록 구성
• 검색어, 클립 매칭을 위한 메타데이터 구축
  • 클립으로 부터 entity를 추출 하고 연관도를 scoring
  • 추가로 한번더 형태소 분석을 통해 인덱싱
    • query-document score 지표 구성
  • 순서
    1. 사용사 실시간 검색 이력 조회
    2. 질의 형태소 분석
    3. index 조회 (retriever)
    4. Ranking
       • 클립의 최신성, 질의-클립 유사도, 재생품질 점수를 종합적 고려를 통해 ranking
  • 키워드만 매칭하면 연관성이 떨어지는 저품질 케이스 발생
    • 쿼리 카테고리 스코어를 활용해서 검색어에 대한 문서 카테고리를 진행하고 카테고리 스코어를 활용해서 normalize 해서 스코어 계산
    • ⇒ 최종 랭킹 단계에서활용됨
• 검색 이력 기반 추천 적용 및 ABT 결과
  • 최근 12시간 내의 실시간 검색 이력을 사용하여 추천
  • light 유저의 유의미한 지표 상승은 없었고, 전체 유저 대상으로는 떨어짐
  • 사유
    • 클립 추천에 부적합한 질의
      • ⇒ 탐색형 질의 선별 필요
    • 검색어에 국한된 결과만 추천
      • ⇒ 확장된 관심사 캐치 필요
    • 사용자의 컨텍스트를 모름
      • ⇒ 사용자의 컨텍스트를 파악하여 개인화 필요
• LLM을 활용한 유저 관심사 기반 추천 (w/ HCX)
  • 검색어로부터 관심사 키워드를 추출
    • ex) 남미여행
      • 여행과 관련된 다양하고 풍부한 컨텐츠 추천
    • NPMI (통계 기반의 특정 질의와 같이 많이 검색된 질의들을 나열 )
    • Word2Vec (의미적으로 유사한 질의들을 나열)
    • ⇒ 그 키워드가 의미하는 관심사에 대한 확장, breakdown을 위해 LLM을 사용
  • HCX를 사용한 관심사 키워드 추출 !
    • 컨텍스트 파악을 위해 한시간동안의 질의를 중점으로 진행하고 만료 기간을 3일 정도로 짧게 설정하여 오래된 관심사 밖의 내용은 지울 수 있도록 구성
    • HCX활용의 한계 및 보완을 위한 NET(Named Entity Tagger) 활용
    • 탐색형 질의 선별
      • 부적절한 질의 필터링
      • 질의의 entropy, topic, intent 데이터 활용
  • 대용량 데이터 처리
    • entity 추출
      • 분산 캐시로 NET 사전, 패키지 파일을 클러스터의 모든 노드에 배포
      • excutor로 처리 후 파티션 수로 concurrence를 조절하여 두 interface 작업 병렬적 처리
        • 파티션수로 concurrence 조절
          • spark-submit 때 설정한 executor를 모두 활용할 수 있어 병렬 처리가 용이
        • batch_size 조절
      • ⇒ 할당받은 GPU를 최대한 활용
  • Future Works
    • 시각적인 부분에 대한 이해도를 추가하여 추천 피드를 개선할 수 있음