네이버 글레이스 Back-end, DE & ML 직군 소개 및 질의 응답

Published in

네이버 플레이스 개발 블로그

13 min readDec 2, 2020

2020년 11월 25일부터 11월 27일까지, 3일간 2020 DEVIEW 글레이스 온라인 부스를 ZOOM에서 진행하였습니다. 이번 부스는 플레이스 및 예약 서비스 개발자 분들을 패널로 모시고 진행자와 패널간의 토크쇼 형식으로 구성하였습니다. 첫째날인 25일에는 백엔드 개발자분들, 26일에는 프론트, 그리고 마지막 날에는 글레이스 개발 조직 총괄 리더님과 입사한 지 2년 미만인 주니어 개발자분들을 패널로 모셨습니다.

각 날의 세션은 크게 두 부분으로 구성하였습니다. 우선 패널분들이 각자 팀 소개와 사용하는 기술 스택을 발표해 주셨습니다. 사전에 부스 기획자들이 자체적으로 채용과 개발에 대해 많이 나올 법한 질문을 취합했는데, 발표를 듣고 나서 이에 대한 질의응답 시간을 가졌습니다. 이 글은 부스 세션의 형식을 빌려 우선 각 팀 소개부터 하고, 채용과 개발 관련 FAQ를 정리해 보겠습니다.

PART 1: 각 팀의 역할과 기술 스택 소개

1. 플레이스 사용자&리뷰 플랫폼 (2분 13초~)

플레이스 리뷰 및 사용자와 관련된 트랜잭션을 제공하는 플랫폼을 개발하는 조직입니다. 여기서 구축된 데이터를 활용하여 네이버 검색을 포함한 여러 서비스에 제공하고 있습니다. 네이버에 장소를 검색했을 때 보이는 리뷰들이 저희가 생산하고 제공하는 데이터입니다. 단순히 리뷰 데이터를 쓰기만 하는 것이 아니라 장소를 실제 방문한지 여부(Proof of Visit)도 검증합니다. 모은 데이터는 한국에만 국한되는 것이 아니라 일본을 비롯한 여러 나라에 제공하는 것을 목표로 합니다. 저희 플랫폼에서는 확장성과 안정성을 제공하려고 합니다.

Node.js 환경에서 위에서 개발하고 있습니다. API 개발에는 TypeScript와 Nest.js를 사용하고 있고 DB는 MongoDB를 사용합니다. 서비스가 빠르게 변화하는 특성상, 스키마 변경이 자유로워야 해서 NoSQL을 사용합니다. 축적한 데이터를 여러 서비스와 플랫폼에 실시간으로 제공하기 위해 Kafka를 메시징 시스템으로 활용하고 있습니다. 플랫폼 확장성을 위해 쿠버네티스(Kubernetes)를 사용하여 갑작스러운 데이터 요청량 증가에도 탄력 있게 대응하고 있습니다.

2. 플레이스 POI 개발 (5분 22초~)

저희 팀은 플레이스 POI(Point Of Interest)에 대한 모든 정보를 수집하고, 이를 검색과 같은 네이버 내 다른 서비스에 제공합니다. 네이버에서 발생하는 모든 지역성 질의에 대한 응답을 제공하고 있고, 네이버 지도 결과도 마찬가지입니다. 현재는 LINE과도 협력하여 글로벌 대응도 하고 있는데, ‘LINE CONOMI’라는 리뷰 서비스의 백엔드 연동도 대응하고 있습니다. POI 데이터 수급(이를 CP라고 지칭합니다) 후 적절한 ETL 작업도 진행합니다. 하나의 장소에 대한 검색 결과가 여러 개로 나가면 안 되기 때문에, 데이터 수급 결과에 대한 중복 체크 작업도 병행하고 있습니다.

저희도 역시 Node.js를 사용하고 있고, 배치 작업은 Python, Kotlin, Java를 사용하고 있습니다. 웹서버는 NGINX, 프로세스 매니저로는 PM2를 활용합니다. 관리자 도구 만드는 일이 있기 때문에 프론트 작업도 해야 하는데, 주로 react를 사용합니다. 팀의 핵심인 DB는 Postgresql을 사용하고, 서비스 노출 단의 DB는 MongoDB를 사용하며 둘 사이의 통신은 Kafka로 합니다. ElasticSearch를 사용해 API나 데이터를 제공하는 채널도 마련해 두고 있습니다. 빌드/배포는 Jenkins 기반의 사내 공통 플랫폼을 활용하고, NCC라는 네이버의 k8s 환경도 함께 사용하고 있습니다. 캐시 작업에는 주로 Redis 를 사용합니다.

3. 네이버 예약&주문 플랫폼 (10분 10초~)

다양한 업종(숙박, 식당, 공연/전시, 헤어샵, 병원 등)의 사업주분들이 예약을 손쉽게 관리할 수 있도록 지원하는 역할을 합니다. 최근에는 ‘스마트 주문’이라는 서비스를 오픈했습니다. 또한 BTS 팝업 스토어같이 인기가 많고, 단기간에 트래픽이 많이 몰리는 전시 상품이나, 스타벅스와 KFC 등의 프랜차이즈 브랜드 스마트 주문 서비스도 제공하고 있습니다. 저희의 가장 중요한 목표는 다양한 업종이나 주문 서비스를 각각 별도 개발하지 않고, 하나의 범용적이고 확장성을 갖춘 플랫폼을 개발하는 것입니다.

핵심적인 기술 스택을 설명해 드리면 다음과 같습니다. 초기에는 Java 기반의 Spring Boot으로 API 서버를 운영했는데 2년 전부터는 Kotlin을 점진적으로 도입하기 시작하여 현재는 약 40% 코드가 Kotlin으로 작성되어 있습니다. 메인 DB로 MySQL을 사용하고 있습니다. 예약 서비스 특성상 트랜잭션, 재고 관리, 오버 부킹 등을 막기 위해 관계형 DB를 선택했습니다. 또한 플랫폼 규모가 커지면서 데이터 양도 늘어남에 따라 조금 더 효율적인 검색 방법을 제공할 필요가 있어 ElasticSearch에 MySQL 데이터를 적재해서 서빙하고 있습니다. POI 개발팀처럼 Kafka를 통해 MySQL DB와 ElasticSearch 사이의 데이터를 동기화하고 있습니다. 네이버 캘린더 같은 외부 서비스에 예약 일정을 동기화하는 부분도 Kafka로 운영하고 있습니다.

4. Data Engineering & Machine Learning (14분 7초~)

저희 팀의 미션은 플레이스 안의, 그리고 플레이스에 연관된 모든 서비스에서 생성된 데이터를 한 곳에 잘 통합 하여 데이터 레이크(Data Lake, 뜻)화 한 뒤에, 이 데이터 레이크에서 의미 있는 데이터를 추출하여 서비스에 더 좋은 가치를 제공하는 것입니다. 팀의 전체적인 기술 스택은 아래와 같습니다.

Spark Streaming이나 Kafka는 Hadoop에 데이터 적재용으로 사용합니다. 데이터 작업은 정제작업을 필수로 몇 단계 거쳐야 하는데, 이런 작업은 Apache Airflow를 사용해 스케줄링하여 진행합니다. 이렇게 쌓아둔 데이터를 외부에서 가져갈 수 있게 두 가지 방법을 제공합니다. 하나는 SQL로 가져갈 수 있게 HIVE로 제공하고, 그리고 다른 하나는 일정 수준으로 정제를 거친 뒤 Kafka를 통해 프로듀싱하는 것입니다. 다른 팀과 마찬가지로 대부분의 인프라는 확장성을 위해 k8s 위에 구축되어 있습니다. 신규 솔루션 선택에 매우 개방적인 팀입니다!

(위) 제출된 가짜 영수증, (아래) ML 결과 좋은 리뷰 사진으로 분류된 것들

또한 팀 내에서 머신 러닝을 병행하고 있습니다. 비전(vision), NLP, 추천 등의 작업을 진행해 보고 있습니다. 일례를 소개해 보겠습니다. ‘네이버 MY플레이스’라는 서비스에서는 ‘영수증 체크인’이라는 기능이 있습니다. 사용자가 영수증을 제출해 장소를 방문했다는 인증을 하고 리뷰를 쓸 수 있는 기능인데, 위 그림의 첫 번째 줄 사진 두 장이 가짜 영수증으로 제출된 것입니다. 저희 팀에서는 이런 가짜 영수증을 실시간으로 탐지하고 차단하는 API를 개발했습니다. 또한 MY플레이스 서비스를 통해서 사용자들이 올려주신 리뷰 이미지 중에 질 좋은 것들이 많은데, 이를 사람이 일일이 검수하기에는 양이 너무 많아 불가능합니다. 그 때문에 머신 러닝을 통해 좋은 이미지를 자동으로 분류해 주고 있습니다. 위 그림에서 둘째 줄의 세 장이 좋은 이미지로 분류된 것들입니다.

NLP 분야로는 리뷰 텍스트를 가지고 주제(테마)를 분류하는 작업을 하고 있습니다. 리뷰가 주어지고 특정 테마를 입력했을 때, 리뷰와 테마의 연관 관계를 자동으로 추천해 주는 모델을 개발했습니다. 위 그림은 질의에 따라 추천해 주는 리뷰 내용이 달라지는 것을 테스트한 것입니다. 자동 추천인 이유는 다음과 같습니다. ‘맛’을 테마로 학습 할 때 리뷰와 언어 사이의 관계도 같이 학습하기 때문에, 직접 ‘커피’를 테마로 학습 시키지는 않았지만, 나중에 ‘커피’라는 질의를 날려도 추천이 자동으로 이루어집니다. 이 외에 현재 진행하고 있는 작업으로 플레이스 사용자 개인화 추천 프로젝트가 있습니다.

PART 2: Q&A 정리

영상: 19분 45초 부터

새로운 기술 학습 방식 🔬

학습에 정도는 없는 것 같고, 들인 시간 만큼 결과가 나옵니다. 따라서 어떤 주제가 있으면 팀에서 항상 스터디를 엽니다. 혼자 공부하는 것보다 같이 토론을 하는 것이 효율이 높습니다. ML 같은 경우는 모두가 생소한 것이 많아서 다 같이 MOOC 플랫폼에서 강의를 듣고 전원이 강의 수강 확인서를 받았습니다. ML은 트렌드에 민감한 분야이기 때문에 계속 논문을 읽어야 합니다. 따라서 지금은 소규모로 논문 스터디를 진행하고 있습니다. (주윤상, DE&ML)
개인적 공부도 많이 하며, 이 경우 내용을 정리해서 팀이나 GLACE 조직 기술 공유 저장소 이슈로 올립니다. 또한 팀 내에서는 공부한 내용을 실제로 코드 작성, PR를 올려 다른 동료들이 코드 리뷰를 통해 함께 습득할 수 있도록 합니다. (전병민, BE)

면접 때 가장 중요한 것 🗣

신입이나 경력 면접에서 중요하게 보는 것이 조금 다를 텐데, 이와 무관하게 일단 개발에 대한 관심이 제일 중요한 것 같습니다. 관심이 많은 사람의 경우 면접 자리에서 즐겁게 이야기할 확률이 높은데 이런 경우 그 사람에 대해 인상이 좋게 남습니다. 복잡한 풀이를 잘 해내기보다는, 문제를 해결하기 위해 사고하는 과정을 즐기는 것이 더 중요하다고 생각합니다. 지식이 많든 적든 이 분야를 좋아하고 즐기는 사람을 선호합니다. (이상진, BE)
‘단순히 어떤 것을 했다. 어떤 기술 스택을 썼다.’ 보다는 목적과 이해가 분명한 분을 선호합니다. 질문도 그에 대한 것을 많이 하는 편입니다. 기술에 대한 이해를 바탕으로 한 답변을 기대합니다. (전병민, BE)

원격 근무 환경 🖥

계속 Github 엔터프라이즈 환경을 통해 개발 업무를 했기 때문에 코로나 시대라고 딱히 불편해진 것은 없습니다. 그래도 어려운 부분을 꼽자면, 타 직군과의 커뮤니케이션이 대면보다 효율이 떨어지는 면이 있습니다. 이제는 원격 근무에 적응이 되었고, 개발하기에는 원격 근무가 좋다고 생각합니다. (정상영, BE)
회사가 (집에서도 열심히 일하라고) 허먼 밀러 의자를 싸게 살 수 있게 해줘서, 그 의자를 사 놨더니 생활의 질이 좋아졌어요. (윤영제 — 세션 사회자)

조직 장점 🦸‍♀️🦸‍♂️

자유로운 업무 분위기, 자기 주도적인 개발 환경이 갖추어져 있습니다. 주위에 좋은 개발자가 많기 때문에 같이 일하는 것만으로도 많이 성장하게 됩니다. (전병민, BE)
공유하는 문화가 참 좋아요. 인터넷에서 쉽게 찾을 수 있는 단편적인 지식이 아니라, 본인이 직접 해보고 깊이 있게 생각해 본 것들을 공유해 주시기 때문에 도움이 많이 됩니다. 이런 부분이 쌓이다 보니까 나중에 입사하신 분들에게도 많은 도움이 됩니다. 기술 스택을 먼저 도입해 본 경우도 공유가 되어 있어서 후에 적용할 때 편합니다. (정상영, BE)
팀원 간에 신뢰 관계가 잘 형성되어 있어서 어떤 사람이 새롭게 무언가 진행하고 싶다고 하면 서로 믿어 주면서 진행해 보라고 등을 떠밀어 주는 점이 좋습니다. (주윤상, BE)
네이버의 문화(자율과 책임)가 있는데, GLACE도 이를 잘 따라가고 있습니다. 시간과 장소를 위에서 간섭하지 않고, 개발에 집중할 수 있게 하여주는 문화가 장점입니다. 예전에 다른 곳에서는 프로젝트를 진행해야 하는데 주위가 너무 산만해서 노트북 들고 산속에 들어가고 싶었는데, 여기 조직에서는 그런 것들이 해결되어 좋습니다. (이상진, BE)

기술 스택 선정 방식 🔍

Kotlin을 도입할 때, 팀 내에 공감대 형성과 안정성 확보가 중요해서 검증 과정을 거치기 위한 시간이 필요했습니다. 그래서 기본 지식을 팀 내에 공유하고, 테스트 코드부터 작성하여 ‘실제로 적용한다면 이렇게 될 것이다’라고 맛보기를 했습니다. 그런 과정을 거쳐 현재는 모든 분이 Kotlin을 편하게 사용하고 있습니다. 새로운 기술이 필요하거나, 좋은 기술이 있을 때 그것에 대해서 찬찬히 검증해 나갈 수 있도록 팀의 분위기가 형성되어 있어야 하는 것 같아요. (정상영, BE)
상영 님 말씀처럼 신기술 도입 시 공감대 형성이 중요해서 일단 파일럿 형식으로 조금만 적용해 봅니다. 그 후 지표를 뽑아서 비교해 본 후에 선택합니다. 초반에는 프로젝트가 MEAN 스택을 사용중 이어서 JavaScript를 메인으로 사용하고 있었는데, 사실 이 언어가 모든 것의 해결책은 될 수 없었습니다. 따라서 중간에 Python을 도입하여 전환했습니다. 최근에는 API로 제공하는 부분을 배치로도 돌려야 해서 서로 다른 언어로 중복 개발을 해야 하는 상황이 발생했습니다. 처음에는 이를 Java로 통일할까 했는데, 그보다는 조금 더 모던한 Kotlin 베이스로 회귀하려고 고민하고 있습니다. 신입분들도 기술 스택 선정시 자유롭게 의견을 개진을 할 수 있는 분위기입니다. (이상진, BE)

같이 일 하고 싶은 사람 🙋

면접에서 중요하게 보는 포인트랑 비슷한데, 개발 좋아하고 적극적인 분과 일을 하고 싶습니다. 성장 욕구도 있다면 더 좋습니다. 개발하면서 기술을 잘 공유하고, 그로 인해 동료와 함께 성장하고자 하는 욕구가 있는 분을 환영합니다. (전병민, BE)
‘개발은 잘하는데 인성이 안 좋은 사람 vs. 인성은 좋은데 개발 못 하는 사람’, 이렇게 놓고 보면 저는 좋은 인성을 가진 사람을 선호합니다. (주윤상, DE&ML)
개선에 대한 욕구가 높으신 분과 같이 일하고 싶습니다. 개발이라는 것이 한번 개발하고 끝이 아니라 계속 발전시키고 운영해야 하기 때문입니다. 낡아가는 기존 코드를 끊임없이 개선하고자 하는 욕구가 있는 분들을 환영합니다. (정상영, BE)
논리적인 사람이면 좋겠어요. 개발 문제 해결을 하려면 감성을 중시하고 이해관계에 얽매이는 것보다는 논리적으로 사고하는게 중요하기 때문입니다. 그리고 제너럴 한 개발자를 좋아합니다. 특정 분야의 전문가도 물론 같이 일하면 편하겠지만, 여러 군데 다방면으로 좋아하는 분들이 있습니다. 모든 지식에 대해 두루두루 관심을 표현하고 좋아하는 사람. 그런 사람들과 같이 일할 때 재밌었던 기억이 많습니다. (이상진, BE)

다음 글에서는 FE 개발자 분들의 이야기를 들어 보겠사오니, 다음 편도 기대해 주세요! (바로가기)

채용 지원은? 👉 https://recruit.navercorp.com
문의 메일은? 📮 dl_glace_dev_recruit@navercorp.com