NAVER GLACE Dev Meetup 후기

지난 8월 21일에는 NAVER Glace 개발 조직의 Meet up 행사를 다녀왔습니다.

 

Glace 조직은 네이버의 플레이스 / 예약 / 호텔, 항공권 / 테이블 주문 / MY플레이스 / 일본 맛집 CONOMI / 스마트 플레이스 등의 서비스를 만들고 있는데요, 이번 행사에서는 사례와 업무 방식 발표 및 채용 상담이 진행되었습니다.

 

행사장에 들어가니 부서 별로 테이블을 나눠 채용 상담을 하고 계셨어요.

 

간식도 야무지게 챙겨왔습니다 :-)

 

행사 순서는 위와 같았습니다. 3시간 안에 알찬 내용을 접할 수 있었는데요, 자세한 내용을 살펴보겠습니다.

 

1. Glace CIC 소개

먼저 Glace 조직에 대한 설명을 해주셨어요. 아마 사진 속 발표자님이 Glace의 조직장..? 아무튼 대장(..?)이셨던 것 같아요.

 

Glace란, Global Place의 약자로, Place O2O를 해외로 확장 중이라고 합니다. 특히 일본 맛집 CONOMI의 경우 일본 앱스토어에서 1위를 차지했더라고요!

 

Glace 조직은 신기술을 적용하는 데에 아낌없는 지원을 하고 있었습니다. 하고자 하는 의지만 있으면 누구나 도전할 수 있는 환경인 것 같았어요.

 

Glace 조직의 구성원이 되기 위해서는 무엇보다도 커뮤니케이션 능력이 중요하다고 합니다. 미팅을 최소한으로 줄이고 Github과 코드로 업무를 진행하더라고요. 또, 신기술 적용과 개인의 발전을 중요시하기 때문에 Full Stack을 지향하고 있었습니다.

 

네이버답게 주도적이고 수평적인 문화는 기본입니다. 심지어 하루에 최소 몇 시간 이상 일해야 한다는 제약조차 없다고 해요!!!(왕 부럽...)

 

2. 플레이스에서 게으른 개발자가 부지런히 일하는 방법

다음으로 플레이스 개발팀의 윤영제님께서 '게으른 개발자가 부지런히 일하는 방법'에 대해 발표해주셨어요.

 

난 어려운 일을 게으른 사람에게 맡긴다. 그는 게으르기 때문에 일을 쉽게 처리하는 방법을 찾아낸다.

빌 게이츠가 했던 유명한 말이죠! 윤영제님께서는 이 말에 영감을 받아 네이버 플레이스가 어떻게 효율적으로 일하고 있는지 설명해주셨습니다.

 

플레이스에서는 반복적 업무를 최대한 자동화한다고 합니다. 특히 데브옵스 부분에 자동화를 많이 접목시켰다고 하네요. 개발자들의 워라밸은 중요하기 때문이죠 :)

 

모두에게 익숙할 네이버 플레이스 화면! 매번 쓰던 화면을 직접 만든 개발자를 만나게 되니 신기하더라고요. 윤영제님은 장소 검색하는 부분을 담당하고 계시대요.

 

• 개발 문화
  • 보고용 문서 작성 없음
  • 주간 보고도 깃헙 issue로
  • 미팅, 메신저보다는 깃헙 issue와 comment를 지향

 

맨 처음에 조직장님이 말씀하신 것처럼, 플레이스에서는 비효율적인 업무 프로세스를 없애고 대부분의 소통을 깃헙으로 해결하고 있었습니다.

 

• 리뷰 문화
  
  • 책임 분산
  • 코드 리뷰 >>> 테스트 코드
  • 휴가는 자가 결재로

코드 리뷰도 굉장히 활성화되어 있었는데요, 코드는 혼자의 책임이 아니라는 생각으로 책임을 분산시키기 위해 리뷰에 공을 들인다고 해요. 그리고 사실 코드를 함께 짜다보면 다른 사람이 짠 코드는 이해하기가 힘들잖아요. 하지만 리뷰를 하게 되면 서로 이해하기 쉬운 코드가 된다고 하네요! 그래서 플레이스는 테스트 코드보다 코드 리뷰가 에러를 줄여준다고 생각하고 있었습니다.

 

코드 리뷰는 개발자의 워라밸 측면에서도 중요한 요소입니다. 코드 리뷰를 많이 하게 되면 그 사람이 없어도 다른 사람이 이어서 업무를 진행할 수 있기 때문이죠 :)

 

• 개발 생산성 향상
  • 비슷한 페이지는 공통화, 재사용
  • 리팩토링

플레이스는 팀 인원이 아주 적은가봐요. 하지만 그에 비해 여러 업종을 빠르게 다뤄야 하기 때문에 업종 별로 비슷한 페이지를 공통화하고 재사용하면서 효율성을 높이고 있다고 합니다.

 

그런데 요즘은 업종이 너무 많이 늘어나고 바빠지면서 중복 코드가 많이 보이고, 빌드 결과를 보려면 시간이 너무 오래 걸린다고 해요. 그래리팩토링을 준비하고 있다고 합니다.

 

사실 당장 돌아가고 있는 서비스를 상대하기에도 바쁜데 무슨 리팩토링이야! 생산성이 떨어지는 거 아냐? 라고 생각하실 수도 있어요. 하지만 플레이스에서는 리팩토링은 더 빨리 달리기 위한 준비라고 생각하고 있더라고요. 정말 건강한 마인드 아닌가요...!!! 리스펙 합니다 T.T

 

심지어 조직장님도 리팩토링의 중요성을 이해하고 계셔서 순조롭게 진행 중이라고 합니다. 기간은 2개월 정도 예상하신대요.

 

플레이스에서는 node.js, GraphQL, 타입스크립트, Jest, React 등등...정말 요즘 핫하다는 기술들만 모아 개발하고 있었습니다.

 

그럼 이 많은 기술들을 어떤 기준으로 선택해서 적용하고 있는 걸까요?

 

• 기술 선택 기준
  • 기존보다 개선되는가
  • 성능이 좋은가
  • API 사용법이 편한가
  • 재미가 있는가
  • 구조가 잘 잡혀있는가
  • 레퍼런스가 많은가

 

위처럼 많은 조건을 다 따져보고 결정하신다고 합니다. 만약 새로운 걸 써보고 싶으면? 설명하지 않고 직접 자신이 해보고 괜찮을 경우 PR을 올려서 merge를 받는다고 합니다. 구성원의 열정과 주도성이 없다면 불가능한 일이죠. 정말 대단한 조직인 것 같아요.

 

저는 아직 이렇다 할 실력이 없는 위치이다 보니 사실 기술적인 내용은 그렇게 잘 알아듣진 못했습니다 ㅠㅠ 하지만 플레이스가 대충 이러저러하게 일하고 있구나~ 하고 분위기 파악 정도는 할 수 있었던 것 같아요!

 

2. DevOps in 플레이스

다음은 플레이스에서 DevOps를 맡고 있는 이강일님의 발표가 이어졌습니다. Git, 젠킨스, AWS 람다, 웍스(사내 메신저)를 사용하고 있다고 합니다. 특히 람다는 서버 구현 없이도 이벤트 핸들링을 쉽게 다룰 수 있다고 하네요.

 

Git 전략은 master - develop - test로 가져가고 있고 *이 표시되어 있는 항목은 PR 없이는 merge가 불가능하다고 해요. 시간 관계없이 배포가 이루어지는 바쁜 조직인만큼, 간단한 브랜치 전략을 채택하고 있었습니다.

 

master에서는 tag를 생성하는 것도 기록을 남기기 위해 release를 사용한다는데......사실 전 tag는 사용해본 적이 없어서 이 부분을 잘 이해하지 못했어요 ㅠㅠ '이번 배포는 XX님 코드도 같이 배포됩니다.' 와 같은 내용까지 다 release에 넣어서 기록을 남긴다고 해요.

 

앞서 말씀드렸듯 master는 꼭 리뷰를 받게 되어있어요. 코드 리뷰를 많이 장려하면서 리뷰어를 4명 정도로 유지했었는데, 프로덕션이 이미 나간 상태에서는 모든 개발자가 하나의 프로젝트만 진행하는 게 어려워서 2명으로 줄이는 등 탄력적으로 운영하고 있었습니다.

 

develop도 master처럼 리뷰를 꼭 거쳐야 하는데요, 변경 사항을 자동으로 merge 되도록 람다를 사용한다고 합니다. 역시 전 람다가 뭔지 잘 모르......(쭈굴) 내가 아는 건 Java의 람다뿐인데.... 역시 이런 곳을 오니까 공부할 게 많아져서 좋은 것 같아요.

 

test는 프로덕션과 유사한 환경을 구사해서 사용합니다. test 브랜치는 언제든지 덮어쓸 수 있고요.

 

코드가 master에 merge 되면 언제든지 배포할 수 있어야 해서, 도커 이미지를 미리 만들어 놓는대요. 도커 이미지도 보안 검수를 거치는데 자동화를 해놨기 때문에 2, 3분밖에 걸리지 않는대요. merge가 완료되면 code diff가 생성되고 배포를 준비합니다. 

 

반면에 test는 PR 없이도 merge가 가능하니까 보안 검수 없이 바로 배포합니다. 만약 내 코드를 test에 배포했는데 build fail이 날 경우엔 람다가 자동으로 체크해서 메시지를 보내준다고 합니다.

 

또, PR이 생성되면 merge 될 가능성이 있는 것이기 때문에, 테스트를 통과해야 하고 lint와 prettier도 체크한대요.

 

플레이스에서는 코드 리뷰가 필요할 경우엔 누구든 요청할 수 있도록 메신저를 사용하고 있는데요, 가끔 사람들이 리뷰를 잘 안 하게 된대요. 아무래도 귀차니즘...? 그래서 최대한 빨리 리뷰를 할 수 있도록 메신저로 요청하고, 리뷰하지 않은 목록을 주기적으로 알려준다고 합니다. 만약 코드를 merge 하다가 fail이 난다면 누군가가 호다닥 고쳐야 하니까 모두에게 메시지를 보내게 되어있어요.

 

이런 시스템을 적용하고 나니 리뷰가 많이 증가했다고 합니다. 리뷰 문화가 한 번에 자리 잡은 게 아니라, 노력과 시간을 투자한 결과였네요.

 

보통 PR을 생성한 순서대로 리뷰를 하지는 않습니다. 1번 PR 봤다가 3번 PR 보고..이렇게 왔다 갔다 할 수 있죠. 그리고 만약에 2번을 봤다고 해도 2-2가 생기거나 하면서 merge가 번거로워질 수 있어요.

 

이런 문제를 플레이스에서는 람다 펑션으로 해결했다고 합니다. 역시 자동화 덕후님들...!! 이강일님은 마지막으로 Let's be lazy! 를 외치며 발표를 마무리하셨습니다.

 

3. React Native를 활용한 Cross Platform 앱 개발 성공기

이번엔 네이버 CONOMI 개발자인 전병민님이 React Native에 대해 발표해주셨습니다. CONOMI는 일본 맛집 리뷰 서비스인데요, 실제 음식점에서 영수증을 촬영하면 리뷰를 쓸 수 있대요. 그럼 라인 포인트로 보상을 받을 수 있고요!

 

작년에 시작해서 1년 정도 개발을 진행하셨는데요, 처음에는 web으로 시작을 하셨대요. 근데 리뷰를 쓰는 서비스가 웹이면 아무래도 불편하잖아요ㅠㅠ 영수증도 일일이 찍어 올려야 하고...일본 시장도 웹보다는 앱이라서 이런 부분에 불편 사항이 많이 접수됐다고 해요.

 

그래서 모바일 앱을 만들어보자! 하고 알아봤더니...네이티브의 경우 러닝 커브가 굉장히 높아서 고민이 되셨다고 합니다. 이런 베테랑 개발자님도 이런 부분을 두려워하신다니 급 친밀감...하핫

 

일단 iOS와 안드로이드를 둘 다 짜기는 싫어서 크로스 플랫폼을 알아보았고, 웹뷰는 너무 오래 걸리고 네이티브처럼 보이질 않아서 패스하면서 최종적으로 RN을 선택하셨습니다.

 

아무래도 웹을 계속 해오셨던 분이니 RN에 쉽게 적응할 수 있으셨다고 해요. 앱인데도 불구하고 서로 분업이 가능해서, 마크업은 다른 분께 맡기고 컴포넌트에만 집중할 수 있었다고 합니다. 

 

애니메이션은 로티와 react-spring을 사용했는데, 리액트를 하던 사람은 쉽게 사용할 수 있다고 해서 관심이 가더라고요.

---

RN을 하면서 앱만의 요소를 구현하는 것이 상당히 힘들었다고 하셨습니다. UX적인 부분이나 런치 스크린, picker 같은 시스템 UI를 다루는 게 어려운가 봐요. refresh를 구현하려고 당겨서 나오는 걸 하나하나 작업하셨대요. push 메세지도 그랬고요.

 

또, 웹은 네트워크가 끊기면 사용자가 알아서 인터넷이 끊겼나 보다 하고 다시 연결하려고 하잖아요. 근데 모바일은 이거 다시 껐다 켜세요 라고 할 수가 없으니 T.T 에러 처리도 따로 해줘야 한다고 합니다.

 

사용자 입장에서는 간단한 기능이라고 생각했던 것들이, 사실 개발자들의 피땀으로 만들어진 것이라고 생각하니 눈물이 주륵....

 

무엇보다 제일 어려웠던 건 역시 스토어에 업로드하는 것이었다고 합니다. 웹은 그냥 호로로록 배포하면 끝이니까요...! 스토어 작업을 하면서 공부가 많이 되셨대요.

 

RN의 성능에 대한 말씀도 해주셨어요. 이 부분은 제가 RN에 무지하여(...) 대충 따라 적은 것들만 옮겨보겠습니다.

 

• 브릿지가 성능을 잡아먹는다는 얘기는 맞다. 싱글 thread로 돌아가기 때문에 비동기로 성능을 극대화시키려고 노력했다.
• CPU가 오래 걸리는 작업은 대기를 해야 해서 느릴 수밖에 없다. 그래서 base64로 인코딩하거나 cache 전략을 사용하는 대안이 있다.
• 스크롤 뷰의 경우 무한 스크롤은 성능 이슈가 있기 때문에 눈에 안 보이는 건 지워주는 처리를 직접 해야 하는데, RN에서 직접 컴포넌트로 제공하고 있어서 괜찮았다.
• hermes라는 게 새로 나와서 안드로이드 쪽 성능을 개선해주고 있다.
• RN이 버전을 업그레이드하면서 문제가 터지고 있지만 다양한 방법이 나와있으므로 괜찮다.

 

일본에는 처음 진출하는 거라 스타트업처럼 빨리 출시하고, 고치고, 배포하는 작업을 반복했대요. lean 하게 돌아갔기 때문에 정말 한 명이 모든 걸 다 한다고 합니다. 모르겠으면 코드 리뷰로 서로 도우면서 하고요.

 

개발자는 최초의 제품 사용자이기 때문에, 직접 써보고, 가서 먹고, 리뷰 남겨보고, 고치고, 논의하고, 써보고....를 반복하며 고객을 이해하는 팀이 되려고 노력하신다고 합니다. 덕분에 살도 많이 찌셨다고...ㅎㅎㅎ

 

결국 이런 눈물겨운 노력으로 일본 앱스토어 1위를 달성하셨습니다!

 

마지막으로 RN이 네이티브와 비교해 가지고 있는 장점을 정리해주셨어요. RN의 장점은 뭐니 뭐니 해도 역시 러닝 커브가 낮아서 바로 개발에 들어갈 수 있다는 점입니다. iOS 출시 후 2주 만에 안드로이드를 출시했는데, performance와 build, deployment, 스토어 처리로 2주가 걸린 것뿐, 실제로 개발 시간은 더 짧았다고 합니다.

 

4. 대혼란의 쉬는 시간

20분의 쉬는 시간 동안엔 이경일님께서 성능 테스트에 대한 발표를 해주셨어요.

 

사실 이 발표는 충분히 좋은 내용이었는데도 불구하고 행사 구성 때문에 너무너무 아쉬웠던 부분이었습니다.

 

쉬는 시간동안 발표 공간 바로 옆에서 채용 상담이 진행되었기 때문에 말소리에 발표에 집중할 수 없었고, 또 채용 설명과 발표 둘 다 관심 있는 사람은 어떻게 해야 할지 몰라 우왕좌왕하는 모습이 많이 보였습니다 T.T 발표 준비에 많은 노력을 들이셨을 텐데 그에 비한 효과가 나오지 않아서 정말 아쉬웠어요.

 

만약 쉬는 시간에 무언가를 병행해야 하는 상황이라면, 발표 장소를 따로 구분해야 할 필요가 있을 것 같습니다. Glace 행사 담당자님이 과연 이 글을 봐주실지는 모르겠지만...ㅠㅠ 제가 정말 너무 안타까워서 그렇습니다... 엉엉

 

결국 혼돈의 카오스였던 발표 자리를 떠나 채용 상담 부스로 가보았어요. 근데 뭔가...개발자님들도 저희도 너무 서로 뻘쭘하구...개발자님들이 괜히 먼산 쳐다보시고 그래서....말 걸기가 어렵더라고요. 그래서 많은 얘기를 나누지 못했습니다 ㅠㅠ 이 부분도 참 아쉽네요.

 

5. 네이버 여행 오픈하다 오픈소스 만든 이야기 (feat. GraphQL)

네이버 여행의 김한석 개발자님은 GraphQL을 소개해주셨어요. 저는 이름만 들어보고 잘 몰랐는데(심지어 어떻게 읽는지도 몰랐...) 쉽게 설명해주셔서 유익했던 세션이었습니다.

 

김한석님은 비교할 상품을 담고, 담은 상품을 선택해서 비교하기를 누르고, 서로 어떤 차이가 있는지 등등의 기능을 구현하면서 GraphQL을 도입하셨습니다.

 

REST는 http 메소드에 맞게 응답을 주고받는데, GraphQL은 post로 고정이 되어있대요. 그럼 각기 다른 요청을 어떻게 구분하는 걸까요? 바디를 다르게 보내면 됩니다. 정의가 각각 따로 되어있대요.

 

그래서 만약 총가격이 알고 싶다면 그 내용을 그대로 보내주면 된대요. 그냥 새로운 API 프로토콜이라고 생각하면 된다고 하셨습니다. 

---

Spring도 Controller를 정의해줘야 사용이 가능하죠? GraphQL에서 이와 같은 기능을 하는 게 type과 resolver라고 합니다. 항목을 type에 정의하고 resolver에도 추가해서 리턴하면 된대요.

 

혹은 resolver를 나눠서 위임할 수도 있는데, 이런 특징은 모듈화를 시켜서 유지보수가 쉬워지는 장점이 있다고 합니다.

 

type을 모듈화 하면 사진과 같은 tree구조가 형성됩니다. 그다음엔 resolver를 할당하고 return으로 위임하죠. 자신이 처리할 수 없는 건 그냥 넘기는 겁니다. 이렇게 책임 별로 나뉘기 때문에 유지 보수가 쉬워집니다. 뭔가를 고치고 싶으면 그냥 쭉쭉 따라 내려가기만 하면 된다는 거죠.

 

REST의 경우 뭔가를 추가하려면 최소한 API를 하나는 더 만들어야 하는데, 얘는 그냥 별도 추가 작업 없이 날려주기만 하면 된대요. 그럼 필요한 부분만 딱 얻어갈 수 있다고 하네요....대박이죠!!!!! 설명을 듣고 나니까 왜 요즘 핫한지 알겠더라구요. 저도 언젠간 꼭 한 번 써보고 싶네요.

 

하지만 단점도 있어요. 트리가 상품 하나당 하나씩 생성되기 때문에, 여러 상품을 불러오고 싶으면 여러 번 요청해야 한다는 거예요. REST였다면 그냥 join 해서 한 방에 불러올 텐데 말이죠.

 

근데 이걸 해결하기 위한 data loader가 나왔대요! 너무 길어서 그 과정은 생략하셨지만, 한 번만 써주면 마법 같은 과정을 통해 한 번에 불러올 수 있다고 합니다. data loader의 단점이라면 중복 코드가 많아진다는 건데, 이런 불편함을 없애고자 오픈소스를 만드시기도 했대요. 능력자...!

 

이렇게 새로운 기술을 사용하게 되면, Java 같은 안정된 생태계에 비해 내가 기여할 수 있는 기회가 많이 때문에 많이 도전해보면 좋겠다는 조언을 해주셨어요 :)

 

6. Spring Boot 기반의 네이버 예약 서버에 Kotlin 적용하기

마지막 발표는 Spring Boot에 Kotlin을 적용한 정상영님의 이야기였습니다.

 

코틀린은 JVM, 안드로이드, 브라우저, Native 환경에서 동작하는데 주로 JVM과 안드로이드에서 사용하고 있다고 해요. 정적 타입이면서 타입 추론이 가능하고, 객체 지향이면서 함수형 프로그래밍이 가능한 특징을 가지고 있습니다.

 

사실 요즘 Kotlin이 급부상하는 건 알았지만, Java를 대체하려는 시도까지 이어지고 있는지는 몰랐거든요. 근데 예제 코드를 보니까 왜 그런지 알겠더라고요.

 

첫 번째 장점은 간결성입니다. 위의 사진을 보시면 왼쪽이 Java고 오른쪽에 Kotlin이에요. 네, 왜 Kotlin인지 한 방에 이해가 가시죠? 저도 정말 충격받았어요!!!

 

Kotiln의 문법에 대해 많은 설명을 해주셨는데, 이 부분은 검색하면 나오는 부분이니 일단 생략하고 넘어갈게요 :)

 

Null 체크도 한 번 하면 문제없이 계속 돌아가고요, Java와의 상호 운용성이 좋아서 Java에서 Kotlin을 호출하거나 Kotlin에서 Java를 호출할 수 있다고 합니다! 쪼렙 입장에서는 정말 신기했어요 ㅠㅠ!!!

 

또, JetBrain이 만든 언어기 때문에 IDE 지원이 잘 된다는 것도 장점입니다. 완벽하진 않지만 Java를 Kotlin으로 변환시켜주는 기능도 있고요!

 

코루틴이라고 해서, 비동기 프로그래밍을 쉽게 할 수 있는 기능도 있다고 합니다.

 

네이버 예약의 서버는 Spring Boot와 Java가 83%, Kotlin이 16%로 이루어져 있다고 합니다. 따라서 이미 상당 부분 존재하는 Java 코드를 한 번에 바꾸는 건 쉽지 않은 일이겠죠? 그래서 테스트 코드를 먼저 Kotlin으로 변환한 뒤, 다른 팀원들도 적응할 시간을 가지면서 차차 변환했다고 합니다.

 

또, Kotlin은 lombok에 접근할 수 없어서 delombok 작업을 하셨다고 합니다. Java와 Kotlin이 함께 있으면 Kotlin이 먼저 컴파일되기 때문에 lombok이 생성한 코드를 사용할 수가 없게 되거든요 ㅠㅠ

 

또 다른 이슈로는 queryDSL이 있다고 하는데 일단 queryDSL이 뭔지 몰랐던 무지랭이라...대충 써보자면 언젠가 한 번은 Kotlin으로 작성한 entity class의 query type이 생성되지 않는 이슈가 발생했대요. Java의 annotation이 처리를 하지 못하기 때문이라고 합니다.

 

코딩 스타일은 공식 코딩 컨벤션을 따르는 걸 원칙으로 했는데, 이게 완벽하지는 않다고 합니다. lint는 klint를 사용하고, intelliJ의 추천을 최대한 참고하는 편이라고 하셨어요!

 

7. 네트워킹

마지막으로는 피자, 치킨, 맥주와 함께 자유로운 네트워킹 시간을 가졌습니다.

 

저는 Spring 개발자라 그런지 Kotlin 발표에 감명을 받아서 정상영님이 계신 테이블에서 네트워킹을 진행했어요. 실제로 대화해보니까 더 갓갓 개발자이신 것 같아서 부러웠고 자극도 많이 됐습니다. 언젠가 꼭 한 번 제 프로젝트에 Kotlin을 적용해보겠어요..!!!

 

아직 실력이 모자라서 기술에 대해 깊게 이해하기는 힘들었지만, 단어라도 하나 주워들으면 공부가 많이 되는 것 같아요. 이렇게 좋은 행사를 기획해주신 Glace 관계자분들께 감사의 인사를 전합니다 :)