네이버 Glace 인턴을 거쳐 입사까지
안녕하세요. 저는 네이버 Glace CIC의 CONOMI개발 팀에서 8주간 인턴 후 최종 면접을 거쳐 신입 개발자로 입사하게 된 정현진이라고 합니다.
이 글에서는 인턴십 경험을 중점으로, 핵데이부터 최종 입사하기까지의 과정을 순서대로 적어 보려고 합니다. 정보가 필요하신 다른 분들께 도움이 되었으면 합니다 :)
0. 목차
이 글의 목차는 다음과 같습니다.
- 조직 소개
- 입사 과정
- 2020 네이버 캠퍼스 핵데이
- 네이버 인턴십
- 마치며
1. 조직 소개
본격적으로 글을 시작하기 전에 제가 인턴으로 근무했던 부서인 네이버 Glace의 CONOMI개발 팀에 대해 간단하게 소개해드리겠습니다.
Glace(글레이스)는 네이버의 사내 독립 기업인 CIC(Company-In-Company) 중 하나로 ‘Global’과 ‘Place’를 조합하여 만들어진 이름입니다. Glace에서는 지도, 예약 등 오프라인과 온라인을 연결하는 서비스인 네이버 플레이스를 개발하고 있으며, 일본을 시작으로 글로벌 진출에 도전하고 있습니다.
CONOMI개발 팀은 네이버 플레이스를 책임지는 Glace에서, 글로벌 플레이스 버전인 CONOMI(코노미)를 개발하고 있는 조직입니다. CONOMI는 일본 식당을 포함한 장소(플레이스)를 검색, 실제 방문 후 리뷰하는 서비스로 LINE과 협력하여 개발 중입니다.
Glace와 CONOMI개발 팀에 대해서 보다 자세하게 알고 싶으신 분들은 아래 네이버 다이어리 글들을 참고해 주세요.
- [그린팩토리에서 만난 사람들] 네이버 글레이스(Glace) CIC 개발 리더가 말하는 글레이스
- [그린팩토리에서 만난 사람들] 가장 로컬스러운 서비스로 글로벌 시장에 도전 중인 개발자들, CONOMI 개발자를 만나다
2. 입사 과정
핵데이에 지원한 후 입사하기까지 다음과 같은 과정을 거치게 됩니다.
핵데이 지원 -> 코딩 테스트 -> 핵데이 참가자 선정 -> 핵데이 과제 수행 -> 우수 참가자 선정 및 1차 면접 -> 인턴십 -> 최종 면접 -> 입사
글로 간단하게 적었는데도 상당히 단계가 많아 보이는데요. 실제로 4월 초에 핵데이에 지원해서 9월 말에 최종 면접 결과가 발표되었으니 6달에 걸쳐 진행되었던 긴 여정이었습니다.
3. 2020 네이버 캠퍼스 핵데이
네이버 캠퍼스 핵데이는 네이버에서 주최하는 대학(원)생 대상 해커톤 행사입니다. 네이버 현직 개발자가 멘토가 되어 해커톤에 같이 참여한다는 점이 핵데이만의 차별화된 장점이라고 할 수 있는데요. 또 우수 참가자로 선정될 경우 네이버 인턴십 면접에 참가할 수 있는 기회가 주어집니다.
핵데이에 대한 자세한 설명은 아래 링크를 참고해주세요.
지원서 작성
먼저 네이버에서 선정한 주제들이 담긴 github 저장소가 공개됩니다. 지원서를 작성할 땐 주어진 주제를 살펴보고 원하는 주제를 택한 뒤, 해당 주제를 자신이 얼마나 잘 수행할 수 있는지 나타내기 위해 본인의 기술역량과 경험을 작성하게 됩니다.
지원서를 작성할 땐 자신이 해당 분야에 흥미가 있고, 과제를 잘 수행할 수 있다는 것을 어필하는 것이 중요하다고 합니다. 또한 프로젝트별로 사용할 기술 스택이 나열되어 있는 만큼 충분히 자신 있는 기술 스택을 가진 주제를 선택하는 것도 중요하겠죠.
최근 진행한 2019년 핵데이 윈터와 2020년 핵데이 서머의 주제들은 아래 github에 공개되어 있습니다.
코딩 테스트
지원서 작성 후엔 코딩 테스트를 치르게 됩니다. 2020년의 경우 프로그래머스 플랫폼에서 11시부터 1시까지 2시간 동안 3문제를 푸는 형태로 진행되었습니다. 저는 3번이 어려워 총 두 문제를 풀었던 기억이 나네요.
핵데이 참가자는 면접은 따로 없이, 제출한 서류와 코딩 테스트를 종합 평가하여 선정됩니다. 다만 코딩 테스트는 참고용이므로 코딩 테스트 결과에 따라 합격과 불합격이 결정되지는 않는다고 합니다.
핵데이 과제 수행
핵데이 참가자로 선정된 후엔 본인이 개발할 주제에 따라 팀이 배정되고, 춘천에 있는 커넥트 원이라는 곳에서 1박2일 동안 같은 팀끼리 협업을 하며 해커톤 형식으로 과제를 수행하게 됩니다.
하지만 올해는 코로나 바이러스 때문에 1박2일의 해커톤 방식으로 진행하는 대신, 약 2주 동안 온라인으로 과제 수행 및 멘토링을 하며 개발 기간 막바지에 오프라인 미팅을 1회 갖는 방식으로 진행되었습니다. 커넥트 원에 가보지 못한 것이 아쉽기도 하지만, 더 긴 기간 동안 지속적인 개발과 멘토링을 통해 오히려 더 많은 것을 배울 수 있었던 기회였다는 생각도 듭니다.
핵데이는 기술적인 성장뿐만 아니라 팀원분들과 같이 개발하며 협업에 대해 많은 것을 배우고 생각해볼 수 있었던 기회였습니다. 또 멘토 님들과 대화를 나누며 네이버에서는 어떻게 일하는지, 신입 개발자가 되기 위해 무엇을 준비해야 하는지 등 현업 개발자의 귀중한 의견을 들을 수도 있었습니다.
많은 것을 얻어 갈 수 있는 기회이니 대학생분들께선 기회가 되면 핵데이에 꼭 참가하시면 좋을 것 같습니다!
핵데이 우수 참가자 선정 및 1차 면접
핵데이가 끝난 후 우수 참가자로 선정되어 인턴 면접을 볼 수 있는 기회를 받았습니다. 면접은 약 1시간 동안 2대1 면접으로 진행되었습니다. 면접 또한 코로나 바이러스 때문에 오프라인 면접이 아닌 ZOOM을 통한 화상 면접으로 진행되었습니다.
면접 내용은 보안상 자세히는 적지 못하지만, 핵데이 때 수행한 주제를 바탕으로 사용한 언어나 라이브러리 등에 대해 깊게 생각해봤는지에 대한 질문을 많이 받았습니다. 따라서 인턴 면접을 준비할 때는 핵데이 때 수행한 과제를 스스로 정리해보고, 또 네트워크, 운영체제와 같은 전공 지식이나 개발 언어 관련 지식 등을 잘 준비해 가면 좋을 것 같습니다.
또 저는 이 면접이 첫 기술 면접이었는데요, 머릿속으로 어렴풋이 알고 있다고 해서 그것을 말로 남들에게 설명하기는 쉽지 않다는 것을 깨달았습니다. 면접 준비를 하면서 자신이 확실히 이해하고 있는지 다시 점검하고, 말로 풀어서 설명하는 연습을 많이 해보는 것이 도움이 될 것 같습니다.
4. 네이버 인턴십
면접을 본 후 일주일 정도 지나 인턴 합격 소식을 듣게 되었습니다. 인턴십은 글 서두에 적은 것처럼 네이버 Glace의 CONOMI개발 팀에서 8주 동안 진행되었습니다.
실제로 입사하고 난 뒤 느꼈던 Glace의 가장 큰 차이점은 근무지가 그린팩토리가 아닌 서현역 퍼스트타워라는 것이었습니다. 이는 사람마다 장단점이 있겠지만 지하철을 타고 출퇴근하던 저에게는 사무실이 서현역에서 도보로 5분 거리였기 때문에 출퇴근이 용이해 큰 장점이 되었던 것 같습니다.
인턴 과제 소개
제가 맡은 과제는 CONOMI 앱에서 특정 사용자가 리뷰한 장소들을 지도 상에서 한눈에 볼 수 있게 나타내는 유저 맵 기능을 구현하는 과제였습니다.
위의 이미지는 제 휴대폰에서 실제로 앱이 구동되는 모습을 남겨본 것입니다. 사용자가 리뷰하면서 올린 이미지를 지도상의 가게 위치에 마커로 표시하고, 화면 하단부에는 가게의 상세 정보를 담은 캐러셀이 있으며, 마커와 캐러셀을 포함한 여러 요소들이 매끄럽게 상호작용하는 것에 중점을 두고 개발하였습니다.
개발에 사용한 주요 기술 스택은 React Native, TypeScript, GraphQL이고 필요한 NPM 모듈들을 그때그때 설치해서 사용했습니다. 저는 여기에 글을 쓰셨던 다른 인턴 분들과는 다르게 백엔드는 개발하지 않고 프런트엔드만 개발했다는 점이 특이했던 것 같습니다. 백엔드를 해보지 못해 아쉬운 마음도 있었지만 한 가지 분야에 집중해서 더 깊게 파고들 수 있다는 장점도 있었습니다.
기술 스택의 경우 기존 CONOMI개발 팀에서 사용하던 것과 동일한 기술 스택을 사용했습니다. 이때 ‘단순히 이러한 기술들이 사용되니까 따라 써야지’라는 생각보다, ‘기존에 사용하는 것을 따르지만 왜 쓰는지를 이해하고 사용하자’라는 생각으로 다른 분들께 질문도 하고, 스스로도 비슷한 기술들을 찾고 비교해가며 사용 이유를 이해하려고 했습니다. 동일한 기술 스택을 사용해서 코드 리뷰를 자세하게 받을 수 있다는 점 또한 큰 장점이었습니다.
개발 과정
1주 차 때는 기존 CONOMI 앱의 구조를 파악하고 React Native, GraphQL 등 접해보지 않았던 기술들을 공부했습니다. 공식 문서의 튜토리얼을 따라 해 보고, 인터넷에서 동영상 강의를 들으며 해당 기술들을 익히려고 했습니다. 또한 크로스 플랫폼 앱 개발 툴인 React Native의 장점을 살리기 위해선 Mac OS에서의 개발이 필수적인데 (iOS 앱을 Mac OS에서만 개발할 수 있습니다), 저는 Mac OS을 써본 적 자체가 처음이었기 때문에 Mac OS 환경을 익히는 데에도 시간이 꽤 걸렸던 것 같습니다.
참고로 인턴들에게도 무려 최신형 맥북 프로가 개발 기기로 지급되었습니다 😀
2주차부터 본격적으로 개발을 시작했습니다. 사실 제가 맡았던 유저 맵 기능은 CONOMI 앱에 이미 구현되어 있던 기능인데요. 덕분에 디자인이나 UX 등 기획적인 부분은 크게 신경 쓰지 않고 기존의 것을 사용하고 컴포넌트 기능 구현에만 집중할 수 있었습니다. 우선 기존 기능을 충실하게 구현하는 것을 일차 목표로 삼고 개발을 진행했고, 기존의 기능을 모두 잘 구현한 뒤 테스트 코드를 작성하고 성능 향상과 사용자 경험 개선을 시도했습니다.
개발 과정은 전체적으로 아래와 같이 진행되었습니다.
- 기능 개발이나 버그 수정 등의 이슈가 있으면 OSS(사내용 github)에 이슈를 작성하고 브랜치 생성
- 개발 진행
- 풀 리퀘스트를 올리고 코드 리뷰 후 해당 브랜치 merge
- 1–3번의 과정을 반복하는 동안 틈틈이 리팩토링
리팩토링은 주로 분리의 과정이었습니다. 재사용되는 로직은 함수로, 컴포넌트 로직은 React의 custom hooks로 분리하고, 또 로직이 아닌 컴포넌트들도 결합도를 고려하여 하나의 큰 컴포넌트를 여러 개의 작은 컴포넌트로 분리하기도 했습니다. 변수나 함수 이름을 의미를 더 잘 드러나게 바꾸는 것도 사소하지만 의미 있는 일이었습니다.
테스트 코드
기능 구현을 완료한 뒤, 테스트 코드를 작성했습니다. 저는 이전에 본격적으로 테스트 코드를 작성해본 적이 없었기 때문에 어찌 보면 새로운 시도이자 도전이었는데요. ‘인턴 때가 아니면 언제 해보겠어?’라는 생각도 있었고, 멘토님도 새로운 시도하는 것을 격려해 주셔서 도전해볼 수 있었던 것 같습니다.
테스트 주도 개발(TDD) 방법론에 의하면 테스트를 먼저 작성한 뒤 테스트에 따라 실제 개발을 진행해야 한다고 합니다. 하지만 앞서 말씀드렸던 대로 저는 테스트를 제대로 작성해본 적이 처음이었기 때문에 초기 개발이 끝난 후에 테스트를 작성하게 되었습니다. 이번 프로젝트는 코드 베이스가 그렇게 넓지 않았기 때문에 이런 방식으로도 테스트 작성이 가능했던 것 같습니다.
테스팅 프레임워크는 Jest와 React Native Testing Library를 사용했습니다. 좋은 테스트를 작성하기 위해 여러 시행착오를 거치고 다양한 개념들을 공부해가며 마지막에는 90%의 테스트 커버리지를 달성할 수 있었고, 테스트 작성 후 코드를 수정하는 과정을 통해 테스트의 장점 및 TDD가 생긴 이유 등을 직접 깨달을 수 있었습니다.
아래 글들은 테스트에 대해 공부할 때 많은 도움이 된 글들입니다.
- TOAST UI 블로그 — 테스트
- Kent.C.Dodds 블로그 — Static vs Unit vs Integration vs E2E Testing for Frontend Apps
- Kent.C.Dodds 블로그 — Testing Implementation Details
성능 향상 및 사용자 경험 개선 시도
성능 향상을 위한 다양한 시도들이 있었습니다. 우선 React 내부에서 최대한 빠른 성능을 끌어내기 위해 React의 렌더링 프로세스 등을 공부하고 함수 컴포넌트에서 불필요한 재렌더링을 줄이기 위한 함수들인 React.memo와 useCallback, useMemo 등 각종 메모이제이션 기법의 정확한 사용법을 익히고 적용했습니다.
최적화를 진행하며 컴포넌트별로 렌더링 횟수 모니터링을 한 결과 렌더링 횟수가 최적화 전과 비교했을 때 최대 50% 이상으로, 상당히 많이 줄어든 것을 확인할 수 있었습니다. 이 과정에서 아래 글들이 많이 도움이 되었습니다.
또한 React Native에서 제공하는 기본 컴포넌트의 성능에 문제가 있었던 경우도 있었으며, 그런 경우 해당 문제를 해결한 NPM 모듈을 사용하기도 했습니다. 예를 들어 React Native의 기본 <Image /> 컴포넌트는 성능이나 캐싱 관련해서 이슈가 있었는데, 이를 react-native-fast-image라는 모듈을 사용해 해결할 수 있었습니다. 여기서 단순히 특정 모듈을 사용하는 데 그치지 않고, 해당 모듈이 어떻게 문제를 해결했는지?까지 알아보면서 조금 더 넓은 지식을 얻을 수 있었습니다.
실패한 경험
물론 모든 성능 향상 시도가 성공했던 것은 아닙니다. 개발 도중 많은 수의 이미지를 동시에 서버에 요청해서 띄울 때, 랜덤하게 이미지 로드 속도가 저하되는 현상이 발생했습니다. 상당히 많은 시간을 투자해 문제를 해결하려고 했지만 네트워크 관련 문제로 밝혀져 제 프로젝트 내에서는 해결할 수 없다는 결론이 나왔었습니다.
하지만 이런 실패한 시도 또한 나름대로 의미가 있었습니다. 문제를 분석하는 과정에서 다양한 가능성을 열어 두고 이미지 로딩 최적화 방법, 캐시, 네트워크 등 여러 분야에 대해 알아보며, 당장 사용하진 않더라도 향후 유용할 새로운 지식들을 많이 얻을 수 있었습니다.
사용자 경험 개선
마지막으로, 사용자 경험 개선의 일환으로 마커 클러스터링 기법을 적용했습니다. 마커 클러스터링이란 가까운 거리에 있는 마커들을 하나의 마커로 묶어주는 것을 말합니다. 초기 개발 버전은 클러스터링 없이 모든 이미지가 마커로 띄워지는 형태였는데요, 이는 과도한 이미지가 필요한 정보를 가릴 수 있어 사용자 경험에도 좋지 않았고 위에서 말한 다수의 이미지를 동시 요청할 때의 성능 문제도 있어 클러스터링을 도입하게 되었습니다.
클러스터링을 적용할 때도 네이버, 카카오, 구글 등의 기존에 제공되고 있는 클러스터링 알고리즘을 분석해보고 여러 가지 옵션들을 고려한 뒤 제 상황에 적절한 라이브러리를 선택하여 알맞게 적용하려고 했습니다. 그 과정 속에서 단순히 라이브러리를 하나 선택해서 사용했다면 알지 못했을, ‘마커 클러스터링’이라는 주제에 대해 다양한 지식들을 얻을 수 있었습니다.
Github 활용
인턴 과제는 혼자 하는 프로젝트지만, 멘토를 포함한 다른 분들이 진행 상황을 파악하고 필요하면 참여할 수 있게 github을 활용하는 방법을 많이 배웠습니다. 이 글에서 github은 앞서 언급한 것처럼 사내용 github인 OSS를 말하지만 편의상 github으로 칭하겠습니다.
개발을 진행하는 동안 이슈, 풀 리퀘스트, 위키 등 github에 존재하는 다양한 기능들을 사용해서 다른 사람에게 내가 하고 있는 작업을 쉽게 공유하고자 했습니다. 특히 멘토님이 바쁜 와중에도 꾸준하게 제 풀 리퀘스트에 대해서 코드 리뷰를 해주셨는데, 코드 리뷰를 통해 제가 작성한 코드를 새로운 시각에서 살펴볼 수 있었고, 제가 부족했던 점을 보완하고 더 배울 거리를 찾을 수 있었습니다.
이는 실제로 현업 개발 프로세스와도 일치하는 부분으로, 개발을 완료하고 나서 풀 리퀘스트를 올리면 동료 개발자가 보고 코드 리뷰를 합니다. 그 뒤 코드 리뷰를 통해 수정할 부분이 있으면 수정한 후에 메인 브랜치로 merge 하게 됩니다.
이때 이러한 풀 리퀘스트를 제대로 활용하기 위해서는 일관된 브랜치 관리 방법이 필요한데요. 여러 가지 브랜치 전략을 공부한 후 제 프로젝트의 브랜치 전략은 git flow에서 release를 제외한, master/develop/feature/hotfix 브랜치로 이루어지는 구조를 택했습니다.
브랜치 전략에 대해서는 아래 글에서 도움을 받았습니다.
얻은 것과 느낀 점
우선 개발 실력과 지식이 많이 늘어났습니다 😀 개발하고, 리팩토링하고, 문제를 해결하는 과정에서 다양하고 많은 문서와 코드를 읽었으며, 코드 리뷰와 조언을 통해 제가 미처 생각해보지 못했던 부분까지 챙길 수 있었습니다.
또한 개발 태도에 대해서도 깨달은 점이 많았는데, 한 문장으로 요약하면 What보다는 Why, 즉 '왜?'를 생각하는 것이 중요하다는 것입니다. 앞의 내용에서도 많이 강조했던 부분인데요, 인턴 기간 동안 이런 태도를 가질 수 있도록 많이 피드백 받았고 앞으로도 그런 태도를 가지려 합니다.
또 제가 학습한 내용들을 OSS 이슈에 정리해서 다른 분들이 볼 수 있게 문서화를 많이 해두었는데, 글쓰기 실력도 쓰면 쓸수록 는다는 걸 느꼈습니다. 실제로 Glace에서도 내부적으로 공유 문화가 굉장히 활성화되어있어 인턴 기간 동안 많은 도움을 받았는데요. 개발자 집단의 좋은 문화 중 하나가 이렇게 자신의 지식을 공유하는 문화라고 생각하기 때문에 앞으로도 제가 얻은 유용한 지식이 있으면 정리해서 공유하는 습관을 가지려고 합니다.
개발 관련 지식 외에도, 옆에서 다른 팀원 분들이 일하는 것을 지켜보며 실제 개발 진행 시의 협업 과정이나 개발자들이 일하는 방식 등을 경험해볼 수 있었던 점이 좋았습니다. 출근을 하는 동안에는 팀원분들과 점심을 같이 먹으면서 이야기를 나누며 네이버와 Glace의 문화를 듣고 체험할 수도 있었습니다.
옆에서 지켜본 Glace의 문화는 자율과 책임이라는 단어로 설명할 수 있을 것 같습니다. 자율적으로 일을 수행하며 근무 장소와 시간 또한 주어진 일만 잘 해내면 아무 제약이 없기 때문에 다양한 장소와 시간대에서 근무를 하는 모습도 볼 수 있었습니다. 이렇게 자율적으로 근무하면서 코드 리뷰와 풀 리퀘스트로 진행 상황을 공유하고, 주 단위로 자신이 한 일을 간단하게 공유하는 제도를 가지고 있습니다. 이러한 제도를 통해 자신이 한 일을 누구나 볼 수 있게 공유하고 책임감 있게 개발을 해나가는 모습을 보고, ‘이게 네이버 개발자구나’라는 것을 느낄 수 있었습니다.
8주간의 인턴 기간만으로도 충분히 값진 경험이었습니다!
최종 면접
인턴십이 끝나고 약 3주 정도가 지난 후 최종 면접을 보게 되었습니다. 최종 면접 또한 화상 면접으로 약 1시간 동안 진행되었습니다. 최종 면접에서는 인턴 기간 때 한 프로젝트에 기반한 질문과 몇 가지 CS 지식을 물어보는 질문이 있었습니다. 면접관님들이 여러 가지 상황을 설정해서 질문을 하시면서 단순히 암기형 지식이 아니라 제대로 이해하고 있는지를 보려고 했던 것 같다는 느낌이 들었습니다.
최종 면접을 대비해 인턴 기간 동안 진행했던 프로젝트를 스스로 정리해보고, CS, JavaScript 등의 지식을 다시 살펴봤습니다. 하지만 최종 면접을 보면서 면접관님들이 던진 질문들을 잘 답변하지 못한 부분이 많았습니다. 면접이 끝나고 ‘역시 네이버 최종 면접은 어렵구나’ 하는 것을 느꼈고 ‘조금 더 준비를 했어야 하나?’ 등 아쉬움이 많이 남았던 것 같습니다.
면접 질문은 개개인별로 모두 다를 것이지만, 자신이 진행했던 프로젝트에 대해서 숙지를 하고 CS 지식 등은 단순히 외우기보다는 이해를 하고 있으면 좋을 것 같습니다. 대부분의 경우 질문에 대답하면 해당 질문에서 멈추는 것이 아니라 답변과 연관되어 더 깊은 질문이 들어올 텐데요, 이때 외운 지식이라면 답변하기가 어려울 것 같습니다.
또한 자신이 알고 있는 것을 정확히 말하는 능력이 필요해 보입니다. 이와 관련해서 위의 인턴 면접 부분에서 말씀드린, 말로 내가 아는 내용을 설명하는 연습은 꼭 해보시길 추천드립니다!
5. 마치며
최종 면접을 보고 1주일 정도가 지난 후 합격 소식을 들었습니다. 그 후 입사하기 전까지는 인턴 기간 동안 관심이 생긴 개발 관련 책들을 구매해서 읽어 보고, 고향에서 가족들과 시간을 많이 보내며 재충전하는 시간을 가졌습니다.
지금은 이제 막 입사해 신입 개발자로서의 커리어를 시작하게 되었는데요. 인턴 때 근무했던 CONOMI개발 팀에서 다시 근무하게 되었습니다. 해당 팀에서의 인턴 경험이 정말 좋은 기억으로 남았고 팀원분들도 모두 잘 대해 주셨기 때문에 신입 개발자로서의 생활도 많이 기대됩니다. 앞으로 꾸준히 발전하는 개발자가 되도록 노력하겠습니다.
여기까지 긴 글 읽어주셔서 감사합니다. 마지막으로 인턴 기간 동안 많은 도움을 주신 멘토님과 다른 팀원분들께 감사하다는 말씀을 드리면서 글을 마치겠습니다.
