네이버 Glace 인턴십 회고 : 개발 문화와 성장을 중심으로
안녕하세요. 저는 NAVER Glace CIC 인턴십을 거쳐 최종 입사하게 된 조상연이라고 합니다. 다사다난했던 2020년에 많은 위안과 도움을 얻었던 인턴 회고를 제가 적게 된다는 것에 감회가 새롭습니다. 조금이나마 NAVER Glace CIC란 조직, 입사 과정 등에 대하여 도움이 되길 바라는 마음으로 글을 시작해봅니다.
Table of Contents
1. NAVER Glace CIC
2. AI Burning Day
3. Internship
4. Conclusion
1. NAVER Glace CIC
네이버 Glace CIC (Company in Company)는 Global + Place의 줄임말로 장소와 관련된 서비스를 글로벌하게 제공하는 것에 목적이 있습니다. 여기서 Place는 단순한 장소를 넘어 온오프라인을 연결하는 예약, 방문한 장소의 리뷰 작성 및 사업자 관리까지 O2O 서비스 전반을 포함합니다.
저는 일본 맛집 서비스인 CONOMI를 개발하는 팀에서 인턴십을 진행하였습니다. 일본에선 LINE CONOMI 로 알려져 있고 영수증 리뷰, 메뉴별 평점 등 기존 일본 맛집 서비스와 차별화된 기능을 제공하는 것이 특징입니다.
2. AI Burning Day
이전 인턴분들이 하신 캠퍼스 핵데이와는 약간 다른 AI Burning Day란 해커톤을 통해 인턴십 기회를 얻을 수 있었습니다. AI Burning Day는 네이버의 여러 인공지능 API를 활용하여 웹/앱을 개발하는 해커톤이었습니다. 저는 개인팀으로 참가하여 OCR API를 활용한 다이내믹 자막 생성기와 온라인 에디터를 개발하였습니다. [Repository]
비디오 캡션 웹 표준이면서 위치와 스타일을 지정할 수 있는 WebVTT를 자동으로 생성하고, 이를 영상을 보며 실시간으로 수정할 수 있는 React 기반의 웹 에디터였습니다. 완성된 자막은 WebVTT 형식으로 다운로드받거나, Papago API를 활용하여 번역도 가능하도록 구현하였습니다. 이러한 기능들을 2박 3일이란 빠듯한 일정 속에서 개발하다 보니 배포를 하지 못하였는데 이 점이 가장 아쉬웠습니다. 지금까지 프로젝트를 하면 로컬 서버에서만 잘 작동시키고 만족했지만 진짜 시작은 배포 이후라는 걸 많이 느꼈던 해커톤이었습니다. 수상은 하지 못하였지만 많은 걸 배웠고 덕분에 인턴십 기회도 얻을 수 있었습니다. 이렇게 네이버는 역량을 직접 확인하고 채용의 기회까지 주는 해커톤을 캠퍼스 핵데이 뿐 아니라 여러 주제로 주최한다는 것을 알 수 있었습니다.
3. Internship
인턴십은 1차 기술 면접을 통과한 후 Glace CIC CONOMI 개발팀에서 시작하였습니다. 당시 네이버는 전사적으로 재택근무를 시행하고 있어 집에서 업무 기기를 수령해 진행했습니다. 집에서 하다 보니 초반엔 집중력이 떨어지는 문제도 있지만, 출퇴근에 시간을 낭비하지 않아도 된다는 장점도 컸습니다.
3.1. 인턴 프로젝트
8주간 진행할 프로젝트로 CONOMI 코스 짜기 프로젝트가 주어졌습니다. 코노미의 다양한 POI(Point of Interest) 를 활용하여 유저가 여러 POI를 선택하고 자신의 여행 일정에 맞게 편집할 수 있는 서비스입니다. 유저는 에디터에서 지도로 자신의 코스를 확인하고 드래그 앤드 드롭으로 POI를 이동하고 저장할 수 있습니다.
프로젝트 개발을 위해 제가 가진 역량을 보여줄 수 있도록 많은 자유를 주셨습니다. 물론 팀에서 사용하는 개발 스택을 어느 정도 사용해야 하겠지만 8주라는 기간 동안 만들어야 한다는 점 때문에 제가 익숙한 것과 타협이 필요했습니다. 그 결과 Typescript, GraphQL, MongoDB, Koa에 새로 학습하여 도전하고 익숙했던 웹 기반의 React로 개발 스택을 설정하였습니다. 당장 새로 배울 것이 많다 보니 효율적으로 학습하여 어떻게 프로젝트에 적용할지, Best Practices가 될 수 있는 좋은 코드와 구조는 무엇인지에 대한 고민이 많았습니다. 나름의 해답은 사내 GitHub이었습니다.
사내
GitHub을 최대한 활용하는 Glace의 효율적인 개발 문화
Glace CIC는 사내 GitHub 을 굉장히 잘 활용하고 온전히 개발에 집중할 수 있는 환경을 제공한다고 느꼈습니다. 타 회사에서 인턴을 해보면 사내 메신저, 슬랙, Jira, Wiki, Docs 등 커뮤니케이션 채널이 많아지고 그에 따른 오버헤드가 심해진다고 느꼈지만 여기선 최대한 GitHub 내에서 이슈와 Wiki를 활용하려 한다는 것을 알 수 있었습니다. 덕분에 문서화나 여러 논의 내용이 사내 GitHub에 온전히 남아있어 히스토리 찾고 보일러 플레이트 코드 얻는 것에 매우 유용했습니다. 특히 놀랐던 부분은 코드가 굉장히 깔끔하다는 것과 기술에 대한 심도 있는 논의가 이루어진다는 것이었습니다. 여러 방안을 두고 선택하는 과정에서 각 기술이 가지는 장단점과 현재 상황을 분석하여 선택의 기준을 명확히 하려는 느낌을 받았습니다.
3.2. 협업과 성장
초반엔 CONOMI 의 구조를 분석하고 프로젝트에 어떻게 적용할지 고민하고, 다양한 문서나 유튜브에 공개된 개발자 컨퍼런스 영상을 많이 참고하여 이해를 더했습니다. 그럼에도 해결되지 않는 질문은 팀 대화방을 통해 여쭈어보고 선배 개발자의 피드백을 바로 받을 수 있었습니다. 이러한 경험들은 새로 배워야 할 것들이 많은 상황에서도 빠르게 학습하여 적용할 수 있도록 하는 큰 힘이 되었습니다.
코드 리뷰를 통한 배움과 성장
선배 개발자분들께 받게 된 코드 리뷰는 지금까지 얼마나 이기적인 코드를 짜왔나 느낄 수 있었습니다. 나름 변수명, 함수명을 신경 써서 작명한다고 생각했지만 실제로 처음 보는 사람에게는 무슨 의미인지 알기 어려운 경우가 많았습니다. 통일성 있는 코드 스타일, 전달성 높은 네이밍, 오타 가능성을 고려한 변수 선언, 의존성 낮은 순수함수 등을 통해 이 코드가 다른 사람, 다른 컴퓨터, 다른 환경에서 얼마나 잘 이해되고 변화하는 요구사항에서 유연하게 대처할 수 있는지 생각하는 것 같았습니다.
PR(Pull Request), Commit 도 나뿐만 아니라 남을 위한 배려가 필요하다고 느꼈습니다. 제가 한 만큼을 PR로 생성하는 것이 아니라 코드 리뷰를 해줄 사람이 빠르게 좋은 리뷰를 해줄 수 있도록 적절한 코드로 나누어 PR 해야 함을 알게 되었습니다. 그 이후론 Issue에 맞게 브랜치를 생성하고 중간중간 얼마나 코드가 바뀌었는지 체크하였습니다. 이때 한 Issue에 너무 많은 코드 변화가 생긴다면 목적에 맞게 100 ~ 200줄 씩 나누어 PR를 생성할 수 있도록 노력했습니다.
3.3. 기술과 도구
인턴십을 통해 또 배운 점은 도구를 다루는 것과 기술을 다루는 것은 엄연한 차이가 있으며 그 차이가 좋은 프로그래머, 좋은 소프트웨어 엔지니어를 나눌 수 있는 기준이 될 수 있다는 것입니다. 세상에 이미 많은 도구가 있고 여러 기술이 담겨 있지만, 해당 도구를 사용함에 있어 그 기술을 이해함을 물론이고 만약 그런 도구가 없다면 만들 수 있는 기술이 있어야 한다는 것을 다시금 깨닫게 되었습니다. Express로 REST API를 만드는 건 누구나 할 수 있기 때문에 그 기반이 되는 HTTP와 네트워크에 대한 지식과 기술에 대한 이해가 있는지 더 중요하고 이는 어떤 문제가 발생했을 때 문제의 원인을 정확하고 논리적으로 파악할 수 있게 하는 원동력이 된다고 보았습니다.
이러한 고민이 가장 많이 담긴 부분이 여행 일정 자동화 기능입니다. 사용자의 편의를 위해 아이디어를 내어 직접 구상한 기능으로 유저가 여러 POI를 선택하면 일정에 맞추어 자동으로 분배해주는 기능입니다. 이때 각 POI 들의 거리별로 클러스터링하여 일정별로 나누어 주는 것을 처음에 구상했습니다. 이를 위한 알고리즘으로 Kmeans 와 DBSCAN을 떠올렸고, 둘 중 성능적으로 O(N)에 가깝고 클러스터 개수를 파라미터로 지정할 수 있는 Kmeans 알고리즘을 선택하였습니다. 그리고 Kmeans의 기본 거리 계산 공식을 하버사인 공식으로 교체하여 위경도로 유클리드 계산을 할 때 발생하는 오차를 최소화하였습니다.
다만 아쉬운 점이 2가지 있었는데, 첫 번째로 직선거리로 구한다는 한계입니다. 직선거리에 산이나 강 같은 장애물이 존재한다면 돌아가는 우회 경로를 어떻게 제공할 수 있을지 고민하였고 hexagon grid 방식을 찾아 조사했습니다. 두 번째는 조사해보니 순회 외판원 문제 (TSP) 로 위 기능을 구현할 수 있음을 알게 되었습니다. 순회 외판원 문제는 모든 도시들을 단 한 번만 방문하고 원래 시작점으로 돌아오는 최소 비용의 이동 순서를 구하는 것으로 주로 배달 경로 , 회로 기판 경로 최적화 등에 사용됩니다. 이번 프로젝트에서 여행 경로를 최적화하기 위해 활용 가능하지만, 멘토님과 논의한 결과 시간상 마무리 단계라 구현을 바꾸기는 힘들다고 판단하여 관련 논문 을 찾아 여러 방법을 조사하고 발표하는 것으로 보완했습니다.
4. Conclusion
인턴 과제에 대하여 많이 가지는 궁금증이 끝까지 완성을 다 못하면 안 좋지 않을까? 입니다. 당연히 완성하는 것도 중요하지만 더 중요한 건 본인이 사용한 기술을 얼마나 이해하고 있는지를 중점적으로 보는 것 같습니다. 오히려 너무 많은 걸 하게 되면 깊이가 얕아지게 되는 문제가 생기기 때문에 자신만의 필살기 미리 생각하셔서 그 기능에 많은 공을 들이시는 게 이후 발표나 면접에서도 더 좋을 것 같습니다. 제 경우에는 프론트, 마크업, 백엔드, DB까지 하다 보니 정작 필살기가 부족한 느낌이었습니다. 결론 내리자면 어느 정도 마무리를 하여 완성도를 보여주는 것은 중요하나 꼭 필수는 아니고 오히려 배우는 자세와 깊이 있는 필살기를 잘 만드는 것에 초점을 맞추는 게 좋을 것 같습니다.
8주간의 인턴십을 마무리하고 전환 면접을 거쳐 최종 합격을 하게 되었습니다. 현재는 Place 내 글로벌 사용자 리뷰를 잘 쌓고, 활용하기 위해 플레이스사용자&리뷰개발팀에 합류하여 새로운 기술을 학습하고 있습니다. 이렇게 보니 인턴십 때 무엇을 하는가 가 아니라 어떻게 하는 가에 더 초점을 맞출 수밖에 없는지 이해가 갔습니다. 인턴십을 통해 받은 가르침을 앞으로 더 발전 시켜 적용하려 노력하겠습니다. 제 긴 후기를 읽어주셔서 감사드리고, 더없이 소중한 경험을 하게 해주신 팀원분들, 멘토님께 감사드립니다.
