네이버에서 진행하는 대표적인 개발자 컨퍼런스 DEVIEW를 다녀왔다.
처음에 컨퍼런스 존재 자체에 대해서도 모르다가 동료분들이 얘기해주셔서 선착순 신청 대열에 합류했다.
운이 좋게도 대상자가 되어 참가할 수 있었다.
쏘카, 네이버, 쿠팡 등 이벤트 부스를 비롯해 네 개의 세미나 장이 있었다.
그중 관심 있는 세미나를 골라 들었다. 아무래도 AI보다 자바스크립트, 웹, 검색 키워드에 관심이 더 간다.
참가한 세미나는 총 다섯 개로 아래와 같다.
- 자바스크립트 화이트박스 암호와 크롬 라인 메신저의 보안강화 - 안상환(LINE)
- 웨일 브라우저 오픈 소스 생존기 - 이형욱 (Naver Cloud)
- Noir : 메일 검색 서버를 반의 반으로 줄여준 신규 검색 엔진 제작기 - 이창현/신우진 (Naver Search)
- 런타임 데드 코드 분석 도구 Scavenger - 당신의 코드는 생각보다 많이 죽어있다 - 김태연/권오준 (Naver Platform Labs)
- 싸늘하다, 메신저에 경보가 날아와 꽂힌다 - 네이버 검색 SRE 시스템 개선 - 조문형/조영준 (Naver Search)
자바스크립트 화이트박스 암호와 크롬 라인 메신저의 보안강화 - 안상환(LINE)
첫 번째 보안 세미나는 굉장히 어려웠다. '화이트박스 암호'라는 개념도 생소했고, 내 기준으로 모르는 용어들이 정말 많아서 세미나 도중 따로 용어들을 검색해 보느라 매우 바빴다. (Curve25519 라는 단어는 태어나 처음 들어봤다)
자바스크립트 화이트박스 암호와 크롬 라인 메신저의 보안강화 - 안상환(LINE)
첫번째 세미나를 통해 겁을 먹고 두 번째 웨일 세미나를 시작했다.
서두에 크로미움 오픈소스에 대한 설명과 '브라우저 개발에 있어 오픈소스 활용을 필수다'라고 설명해 주셨다. 첫 번째 강의와 달리 알고 있는 부분들이 있어서 이해가 잘 되었다. '오픈소스 크로미움은 엄청 어려운 게 아니다'라 하시며 웹엔진에 해당하는 content 폴더를 잘 살펴보면 충분히 이해 가능한 부분이니 한번 훑어봐도 좋다는 팁을 주셨다.
세미나 중반부터는 실제 웨일 개발 & 운영을 어떻게 하시는지 말씀해주셨다.
오픈소스 버전이 지속 업데이트 됨에 따라 웨일 브라우저 이를 잘 따라가며 개발하기 위해서는 '리베이스'를 해야 한다고 했다.
오픈소스 버전업 속도를 따라가지 못하면 호환성, 보안 등이 취약해지기 때문에 브라우저 생존과 직결된다고 했다.
그래서 2020년부터 19주, 29주, 23주, 12주 등의 간격으로 배포를 해오다가 생존을 위해 8주 고정 리베이스 배포 프로젝트를 시작했다고 한다.
여기부터 우리 회사의 배포주기인 고정 2주 배포와 비슷하다고 느껴졌다. 이전에는 한 달 혹은 때때로 배포를 진행하다가 어느 순간부터 고정적인 배포 혹은 예상되는 배포 일정을 진행하는 방향으로 개선해 나갔기에 그렇다고 느꼈다.
리베이스의 과정에서 매번 많은 컨플릭트를 겪고 있고 그 컨플릭트로 병목이 발생하지 않도록 파일 단위로 관리한다고 했다.
깃헙 혹은 코드디플로이를 활용하면 병합을 진행할 때 컨플릭트별로 케이스가 생성하고 이를 여러 사람이 동시에 해결하는 프로세스라 병목은 덜한 것으로 보였다. 하지만 결국 같은 파일 내에 여러 컨플릭트가 발생하는 경우에는 그 파일 내에서 고려해야 되는 점들도 있기 때문에 여기서 파일 단위로 관리한다는 표현을 썼던 것 같다.
우리는 인텔리제이의 병합 기능을 활용해 즉시 컨플릭트를 잡고 있다. 이때 파일단위로 자동으로 컨플릭트를 잡게 되는데 대신 병목이 엄청나게 생긴다. 이게 소스가 방대해지고 작업자가 많을수록 불가능한 프로세스로 보인다. 컨플릭트 해결이 안 되겠다 싶으면 일단 한쪽으로 합하고 노션에 메모해 가며 작업하고 있다. 뭔가 프로세스 개선이 필요하다고 느꼈다.
컨플릭트 최소화를 위해 코딩룰을 정한다는 부분도 인상 깊었다. 좋은 코드의 기준 하나는 컨플릭트가 덜 나는 코드일 수도 있겠다는 생각을 하게 되었다.
매 PR 마다 15만여 개의 테스트케이스를 12대의 테스트봇을 활용해서 검증한다고 들었을 때 우리 회사도 하루빨리 이러한 안정성 작업이 필요하다고 느꼈다. 품질은 곧 지속 가능성을 의미한다. 구독형 플랫폼인 협업툴에 안정성 정말 중요한 것 같다.
이 밖에도 테스트에 진심인 장표가 많아서 진짜 이 정도는 되어야 브라우저를 만들겠구나 싶었다. 크롬과 달리 웨일은 한국유저 친화적으로 만들기 위해 더욱 심여을 기울이고 있다고 한다. 최근에 크롬보다 웨일이 메모리 측면에서도 더 가볍다고 느꼈는데 응원해주고 싶다.
Noir : 메일 검색 서버를 반의 반으로 줄여준 신규 검색 엔진 제작기 - 이창현/신우진 (Naver Search)
네이버 하면 검색이기에 이 세미나를 놓칠 수 없었다. 들어보니 검색엔진에 해당하는 '통합검색' 부분이 아니고 메일, 드라이브 등에 쓰이는 '개별 검색' 기능에 대한 이야기였다. 오히려 우리 서비스와 더 접점이 있을 것 같았다.
최초 <개별 역색인 볼륨> 방식으로 검색 시스템이 구축되어있었다고 한다. 그 시스템이 대용량 검색 시스템에는 정석인 시스템으로 알고 있었는데 그 부분이 단점이 많다는 식으로 이야기가 시작되다 보니 굉장히 흥미로웠다.
* 역색인 방식의 검색은 검색 대상은 콘텐츠가 등록될 때마다 콘텐츠의 키워드를 추출해 색인으로 만들어 저장하는 방식이다.
인상 깊었던 부분은 '평생 검색후보가 되지 않은 문서도 색인 필요'라는 부분이었다. 주로 검색하는 키워드가 검색되기 때문에 생각보다 검색하는 키워드들은 적을 수도 있다.
결국 이 모든 것의 해결점이 '풀스캔'이었다. 어쩌면 역색인 방식에서 풀스캔으로 검색을 시도한다고 하니 뭔가 회귀하는 것처럼 느껴지기도 했다. RDB에서 풀스캔이 느리기 때문에 인덱스(색인) 스캔을 활용하는 방향으로 튜닝으로 이뤄지다 보니 그렇게 느껴졌다. 그리고 여기에 아이디어는 io time을 줄이는 데 있었다. rdb로 치면 '저장된 데이터를 읽고, 풀스캔을 한다'라고 했을 때 '저장된 데이터를 읽는 부분'을 개선하는 아이디어였다. 얼마나 압축하길래 원본 데이터가 줄어드는 것이며 압축을 했으면 결국 읽고 디코드 하는 과정이 있는데 정말 빠를 것인가라는 의문점이 들긴 했지만 아이디어 자체가 좋았다. 스캔만 생각했지 읽는 부분을 개선할 생각은 못 해본 것 같다.
네이버메일 검색 기능을 평균 70ms => 40ms로 줄였다고 하니 좋은 방법이라고 보인다. 소개하기로는 성능 개선이 될뿐더러 검색서버를 100대 => 30대로 줄이고 색인서버 150대를 없애는 인프라적 성과를 냈다고 한다. 메일이 2,607만 개가 있는 해비유저를 중간에 보여줬는데 이거를 풀스캔 방식으로 검색을 몇 초로 끊어냈는지 궁금하다. (평균도 중요하지만 해비유저에 대한 값도 중요하니깐..)
또 좋았던 포인트는 타임아웃이 발생하는 경우에는 타임아웃까지 검색한 부분의 offset을 반환한다는 개념이었다. 보통 스캔을 하다 타임아웃이 되면 트랜잭션을 종료하고 타임아웃 익셉션을 내뱉거나 하는데 위 같은 경우에는 타임아웃될 때까지 offset과 결과를 받아놓고 연속으로 검색을 시도해 마저 결과 값을 구한다는 내용이었다. RDB로 구현하려면 조금 고민을 더 해야 될 것 같긴 한데 역시 아이디어가 좋았다.
이 부분을 네이버 메일, 네이버웍스에 도입해서 성과를 봤다고 한다. 어쩌면 검색을 위해 새로운 nosql 형태의 디비를 고민해 봐도 좋을 것 같다.
같이 온 회사 동료들과 점심을 먹으며 이런저런 이야기를 나눴다. 세미나가 다들 좋은 영감을 준 듯했다. 중간에는 부스도 들러서 굿즈들도 받았다. 점심을 조금 줄 서서 먹은 탓에 시간이 빠듯했어서 점심 바로 직후 있는 세미나 타임은 한 번 쉬고 네 번째 세미나를 들어갔다.
런타임 데드 코드 분석 도구 Scavenger - 당신의 코드는 생각보다 많이 죽어있다 - 김태연/권오준 (Naver Platform Labs)
데드코드라는 말을 처음 들었다. 하지만 설명을 들으니 바로 알 수 있었다. 실행되지 않는 코드, 실행되더라도 앱에 영향을 미치지 않는 코드가 바로 데드코드였다. 오랜 기간 동안 서비스가 피봇 되고 개발되다 보니 우리 서비스에도 데드코드가 굉장히 많다. 데드코드도 많고 데드타일(라이브러리 등)도 많아서 체감상으론 전체 코드의 10% 정도밖에 쓰이지 않는 것 같다. 그로 인해 컴파일, 배포 속도 등이 영향을 미치는데 이 세미나를 통해 데드코드를 잘 처리하는 방법을 얻었으면 좋겠다고 기대했다.
하지만 이번 세미나로 공개한 데드코드 분석도구 'Scavenger'는 스프링에서 활용가능한 도구로 보였다. 지속적으로 디벨롭해서 다양한 언어가 지원되게 한다고 했는데 아직 우리가 쓰기엔 쉽지 않겠다고 느껴졌다. 혹시 몰라 데드코드라는 키워드로 다른 라이브러리가 없나 찾아보는데 몇 개 좀 보이는 것 같아서 자바스크립트 환경에는 한 번 시도해 봐야겠다.
세미나 마지막에 깃헙의 프라이빗 상태를 퍼블릭으로 바꾸면서 세상에 오픈소스를 공개하는 퍼포먼스를 보였는데 굉장히 멋졌다. 네이버플랫폼랩스 팀 중 5분이 6개월 연구하여 개발해 내었고 현재는 80여 개의 네이버 서비스에 활용 중이라고 한다!
https://github.com/naver/scavenger
GitHub - naver/scavenger: a runtime dead code analysis tool
a runtime dead code analysis tool. Contribute to naver/scavenger development by creating an account on GitHub.
github.com
이런 건 깃헙 스타가 필요하다.ㅎㅎ
싸늘하다, 메신저에 경보가 날아와 꽂힌다 - 네이버 검색 SRE 시스템 개선 - 조문형/조영준 (Naver Search)
마지막 세미나는 모니터링 시스템에 대한 이야기였다. 요즘 부쩍 안정성에 대해 중요성을 인식하고 있어서 관심 가지고 들었다.
의존성을 줄이고 지표라벨링 작업을 더하고 빠른 알림 파이프라인을 구축했다고 한다. 실제로 개선된 모니터링 시스템으로 경보 발송까지 걸리는 시간을 3분에서 1분으로 줄였다고 한다.
이 신규 모니터링 서비스는 2022년 카타르 월드컵 조별 예선 최종전에 선보였고 보다 빠른 경보 확인을 통해 빠른 대응으로 트래픽을 잘 견뎌냈다고 한다. 트래픽이 늘어나면 그에 따라 컨테이너를 늘리는 방식으로 보이는데 만약 1~2분 늦게 인지가 된다면 그로 인해 이미 엄청난 행이 걸릴 수도 있었다고 한다. 정말 상상 못 할 엄청난 트래픽으로 보인다.
모든 세미나가 끝났다. 이런 컨퍼런스를 많이 경험하면 확실히 견문이 넓어지겠다고 느꼈다. 부족하다는 걸 새삼 느끼면서도 또 무언가를 연구하고 새로운 것을 선보이고 장애를 겪고 극복하고 이러한 과정들이 다 똑같구나 싶기도 했다. 오늘 얻은 몇 가지 좋은 포인트들은 꼭 새로운 작업을 할 때 녹여봐야겠다.
(하단에 세션별 ppt 링크가 있으니 한 번 보세요~)
https://deview.kr/2023/sessions
DEVIEW 2023
DEVIEW는 국내외 개발자들이 서로의 지식을 나누고, 탁월함을 추구하며, 함께 성장하는 컨퍼런스 입니다.
deview.kr
'Review' 카테고리의 다른 글
| [넷플릭스] 타다 : 대한민국 스타트업의 초상 (feat. 신박하다) (0) | 2022.03.02 |
|---|
