네이버 지도
공간 지능
3D 공간 데이터를 사용자에게 제공해줌으로써 기억과 공간을 입체적으로 2D → 3D로 서비스를 확장시킨다.
현재 일본, 사우디에 3D를 통해 홍수를 시뮬레이션하는 등 여러 분야에서 활용하고 있다.
🧬 디지털 트윈 → AI, Cloud 기반 → 현실 세계와 연결
다양한 기능을 데모로 선보였다.
- 길찾기를 활성화중이라면 다른 어플을 사용하고 있더라도 푸쉬알림 및 다이나믹 아일랜드 알림으로 여기서 내려서 갈아타야 한다는 등 정보를 알림해준다.
- 전국 지하철을 디지털 트윈으로 모델링 한다면 지하철 내부에서도 이 기능이 잘 동작할것 같다.
- 길찾기 기능이 이제 VR 기반 3D 화살표를 통해 실내에서 정확하고 효율적인 동선으로 도착지를 안내하는 내비게이션 기능을 제공해준다.
- 네이버 지도 앱 홈에서 아래 하단바를 끌어올릴 경우 현재 위치의 주변 핫플레이스나 이슈 등을 영상 및 이미지 정보로 공유해준다.
네이버 페이
- 부동산탭에서 3D로 정보를 제공해준다. (체험해본 경험으로는 직방 같은 느낌이다.)
디지털 트윈
실내, 외부 공간을 데이터화하여 다양한 분야에 활용할 수 있다.
- 디지털 트윈을 하기 위해 다양한 장비를 제작하였다. (1784 사옥에 있는 루키를 비롯한 다양한 로봇)
- 비행기에도 고해상도 카메라를 부착하여 활용하고 있다.
- 도로의 정보를 3차원으로 수집하여 자율주행에 활용할 수 있다.
- 비주얼 로컬라이션 기술을 구현하였다.
- 로봇이 비전으로 인해 현재 자신의 위치를 정확하게 인지할 수 있다.
- 사진을 찍어서도 현재 위치를 인식할 수 있다. (밤에도 물론 잘 인식한다.)
- 박물관에서 관람할때 3D로 옛모습 그대로 몰입하여 감상할 수 있다.
- 공사 현장에서도 3D 데이터로 활용할 수 있다.
- 하드웨어 부분에서는 라이다 센서를 사용하지 않아 비용을 낮추었다.
🧬 세계 최초로 로봇 친화적인 건축물인 1784 사옥과 각 세종 데이터 센터를 건립 후 테스트배드로 시뮬레이션 및 기술 연구, 활용함으로써 특허 기술을 많이 확보하였다.
하이퍼 클로바
언어 모델의 능력
실질적인 도움을 주는 AI
한국의 정책 및 법률 분야에서 활용도가 높을 것 같다.
코드 인터프리터 기능
- 엑셀 파일 업로드 후 사용자의 프롬프트 요구사항의 답변으로 각종 요약 및 차트를 볼 수 있도록 파이썬 코드를 스스로 작성하여 실행하여 결과를 보여준다.
하이퍼클로바 x 이미지
- 청바지를 업로드 하면 바지의 이미지를 분석하여 실측 사이즈를 도출한다.
하이퍼클로바 x 오디오
- 사용자의 오디오를 분석하여 AI가 답변중 사용자가 이야기를 끊고 들어올때를 인식하여 경청한다.
(유머도 이해를 하는 것으로 발표 되었는데 구현이 된것인지 하드코딩으로 보여준 것인지 확실하진 않다.) - 침묵을 인식한다. 그리고 목소리 톤으로 사람의 감정을 인식하고 있는 것 같다.
🧬 나의 견해로는 네이버 쇼핑과 AI가 결합하면 사용자가 AI에게 상품 추천을 요구하고 답변을 받는 과정에서 기존에 인기 있었던 몇개의 상품들이 계속 추천될 것이고 상품의 양극화가 더 심해질 것 같다.
가치 중심의 광고
두 사용자가 같은 검색을 하더라도 이전에 검색했던 키워드를 기반으로 보여주는 광고가 달라진다. 이로 인해 광고 효율을 30% 향상시켰다.
네이버 플러스 스토어 (별도의 앱으로 출시 예정)
- 20대, 30대 등 다양한 연령대와 취향을 타겟팅하여 개인화된 쇼핑 경험을 제공하겠다.
- AI를 접목하여
출산이라는 키워드를 검색시 출산 준비에 관한 물품을 보여주는 데모 버전이 있었다. - 물품 리스트에 인기 있는 상품과 그 이유에 대해 상세히 설명해주는 데모였다.
Design System
디자인 시스템을 도입하게 된 이유
MSA 기반으로 사내 다양한 분야의 개발자들과 코드 공유가 잘 이루어지지 않아 비슷한 개발이 많았고 중복되는 코드도 생겨나갔다.
Server Driven UI
기존의 템플릿 및 컴포넌트 기반의 한계
| 개발 방식 | 장점 | 단점 | |
|---|---|---|---|
| 템플릿 | UI 표현은 적고, 데이터만 변경 | 생산성 | 확장성 |
| 컴포넌트 | UI 표현은 많고, 데이터와 함께 조립 | 확장성 | 생산성 |
템플릿과 컴포넌트 사이 어딘가의 Sweet Spot을 정의했다.
규모가 컴포넌트보단 크면서 템플릿보다는 작은 여러 컴포넌트의 반복된 조합으로 데이터를 기반으로 모듈을 구성한다.
디자인 시스템이 실패하는 이유
- 만드는 문제보다 적용하는 과정에서 많이 실패한다.
- 디자인과 개발간의 협업의 부족
모든 영역을 디자인 시스템으로 전환하려고 하지 않고 신규 서비스 개발에만 적용하였다.
잘 운영하기 위한 노력
- 점진적으로 도입하였고 운영에 초점을 맞췄다.
- 협업의 비용을 줄이기 위해 design to code 피그마 컴포넌트를 jsx코드로 제너레이터되는 플러그인을 만들어 활용하고 있다.
- 디자인 시스템을 만드는 팀과 적용하는 팀을 분리하여 적용하는 팀들을 위해 문서화를 하였다.
- 매번 디자인의 변경사항을 알려주기보다 주기적으로 시간을 정하여 변경된 디자인을 공유하여 협업의 비용을 낮췄다.
로깅을 통해 컴포넌트 사용률을 추적, 모니터링
정적으로는 빌드시 사용한 컴포넌트의 수를 모니터링하고, 동적으로는 사용자의 이벤트로 해당 컴포넌트의 사용여부를 로깅하여 어떤 컴포넌트가 많이 쓰이고 안쓰이는지, 어떠한 패턴으로 자주 사용되는지를 추적, 분석할 수 있도록 구현했는데 가장 인상적이였던 부분이였다.
네이버 검색에서 웹 성능 관리하는 방법
웹 성능이 중요한 이유
비즈니스 성공에 영향을 준다.
- LCP 성능 지표를 올려서 매출이 증가하였다는 사례가 있다.
- 속도 지연에 대한 스트레스는 수학 문제를 푸는 공포와 같다.
Web Vitals
LCP : 대표 지표로 선정 (From.네이버)
구글에서 제안하는 여러 지표가 있지만 LCP는 서버 응답, 클라이언트 모두 고려하는 지표로 사용자가 로딩 됐음을 가장 체감하는 지표이다.
화면에서 가장 큰 이미지, 텍스트 블록, 동영상이 렌더링 되는 시간이다.
쾌적한 사용자 환경을 제공하기 위한 기준
- 웹페이지에 접근한 100명 중 75명 이상의 LCP가 2.5초 이하가 되는것을 권장
로깅을 효율적으로 하기 위한 노력
- SendBeacon을 이용하여 로깅 유실률을 최소화 하였다.
- 캐시를 통해 네트워크를 타지 않고 렌더링이 되는 경우에는 렌더링이 매우 빠르기 때문에 로깅하지 않는다. (낮은 로깅 신뢰도)
- js로드 시점을 DomContentLoaded 이벤트 시점으로 하니 전체 400ms 정도 빠르게 로드되었다.
로깅 자동화
초기에는 로깅을 분석하기 위해 웹 성능 지표를 엑셀로 수기로 작성하다가 DB에 로깅 테이블 만들어서 batch 작업을 통해 자동화하였다.
다만, batch 사용으로 특정 시점에서만 변화를 감지할 수 있기 때문에 실시간으로 확인할 수 있도록 모니터링 시스템을 만들었다.
그 후에는 직접 들어가서 모니터링을 하지 않으면 변화 감지가 안되었기 때문에 성능 변화가 감지 되면 알림을 보내도록 하여 완전 자동화 하였다.
무한 스크롤 로깅 분석
사용자는 1.5초에 약 750px을 스크롤한다. 따라서 무한스크롤 경우 약 하단에서부터 750px지점의 오프셋에서 호출하면 부드럽게 사용이 가능하였다.
역설적이게도 무한 스크롤시 너무 빠르게 데이터를 호출했을 경우 클릭률이 오히려 낮아졌다.
기술 워크샵
어떤 어려움이 있었나, 어떻게 협업하였나
왜 디자인 시스템을 도입 하기로 이야기가 나왔나?
큰 비용이 필요한 방대한 작업이고 많은 개발자들이 제약적으로 사용해야 하는 단점이 있지만 확장성과 재사용성이 향상되어 추후 개발 비용을 현저히 낮출 수 있기 때문이었다.
도입 과정과 어려웠던 점
- 새로운 시스템으로의 전환은 큰 비용인데 사용자들이 체감하는 것은 없다. 이것을 상위 리더가 사업성의 문제로 승인을 해줄지 의문이였다.
- 공통 컴포넌트 전체를 통으로 버전 관리? (Sweet Spot)
- 장점: 의존적인 컴포넌트를 한번에 관리할 수 있다.
- ex) A 공통 컴포넌트는 B 공통 컴포넌트를 의존하고 있다.
- 장점: 의존적인 컴포넌트를 한번에 관리할 수 있다.
- 컴포넌트별로 버저닝을 따로?
- 공통 컴포넌트를 재료 상태로 제공하고(의존 관계를 만들지 않는다.) 사용하는 개발자가 조립하여 사용할 수 있도록 접근한 방법. 따라서 컴포넌트별로 개별 버전 관리가 가능하다.
figma to code 부분에서 디자이너분들이 협업을 해주셔야 하는데 설득과 러닝커브에서 어떻게 설득하였나
- 디자인 팀들을 만나 설득하였다. (희생 정신 필요함) (여전히 어려움 존재)
- 아직 피그마의 툴이 따라오지 못해서 디자이너와 개발자간의 어려움이 있는 것 같다.
- 개발의 Lint처럼 자동으로 속성들이 설정되도록 해주는 자동화 툴이 나오면 좀 더 수월하게 협업할 수 있을것 같다.
기술워크샵 소감
20명 남짓의 소규모 인원으로 대부분 네카라쿠베당토에서 오셨다.
지난 FEconf2024 컨퍼런스에서 "디자인 시스템을 도입하여 개발 비용을 획기적으로 단축시켰다” 라는 연사를 듣고 디자인 시스템을 작게라도 도입해보고 싶었고 어떤 과정과 어려움이 있는지 구체적인 디테일이 궁금해서 참가하였다.
수준 높은 질문과 답변 속에서 많은 디테일을 얻었고 무엇이 중요한지 알게 되었다. 또한, 듣기만 했을 뿐인데 한 발짝 더 성장한 것 같다. 너무 좋은 경험이였다.
