2020 네이버 플레이스 여름 인턴십 회고
0. 들어가며
안녕하세요. Glace CIC 플레이스서비스개발1팀에서 7, 8월 여름 인턴십을 한 마장홍선이라고 합니다. 두 달간 짧지만 굵게 꿈만 같은 시간을 보냈는데요 인턴 생활을 돌아보며 어떤 일들이 있었고 무엇을 느끼고 배웠는지 써보려고 합니다. 그럼 시작합니다😁
1. 인턴이 되기까지의 과정
저는 대학(원)생에게 참가자격이 주어지는 네이버 캠퍼스 핵데이를 통해서 인턴십에 참여했습니다.
네이버 캠퍼스 핵데이 지원 → 코딩테스트 → 캠퍼스 핵데이 → 우수 참가자 선정 → 인턴 면접 → 인턴십위와 같은 과정을 거쳤는데요, 핵데이도 좋은 경험이었고 많은 성장을 이루었다고 생각하는데 운이 좋게도 인턴십까지 할 수 있는 기회가 주어져서 4월부터 8월까지 네이버와 함께 값진 시간을 보냈습니다. 여담으로 대학생이라면 네이버 캠퍼스 핵데이에 지원해보는 것을 적극 추천합니다!
2. OT 및 부서 배치
1) 오리엔테이션
인턴십 첫 날 오전에 OT를 진행했습니다. OT 내용은 크게 보안 교육과 회사 생활 가이드 안내였습니다. 보안 교육은 기안84가 나오는 영상을 시청했는데 이 때 진짜로 네이버에 왔구나라고 실감을 했던 기억이 납니다.
Glace CIC 사무실은 그린팩토리에 있지 않고 서현역 근처의 퍼스트타워 건물에 있습니다. 그런데 회사 생활에 대한 가이드를 주실 때 그린팩토리 위주여서 구내식당, 사내 카페를 이용 못한다는 아쉬움이 컸습니다. 그래도 그린팩토리와 다르게 사무실이 역 근처에 있고 아침도 챙겨주고 부족할 것은 없어서 만족하며 출근했습니다.
2) 부서 배치
OT가 끝나고 멘토님이 오셔서 부서로의 이동을 도와주셨습니다. 제 자리가 마련되어 있었고 자리에는 맥북 프로와 보조 모니터가 준비되어 있었습니다. 인턴은 장비를 지원해주지 않을 수도 있단 생각에 개인 노트북을 챙겨 갔었는데 그럴 필요가 없었습니다.
첫 출근날 전까지 제가 배정될 부서가 어디인지 알려주지 않았습니다. 다만 핵데이에서의 멘토님과 관련된 부서에 배정될 확률이 높고 OT 안내 메일에서 Glace CIC 출근 인턴은 퍼스트타워에 오라는 안내를 받고 Glace CIC 조직에 속할 것이라는 것은 미리 알고 있었습니다. 그래서 Glace CIC가 어떤 조직인지 미리 조사하여 수많은 네이버 서비스 중에서 어떤 서비스를 만들고 있고 주로 어떤 기술 스택을 가지고 있는지 정도는 파악하고 갈 수 있었습니다.
3) 과제 선정
첫 날부터 과제가 주어졌습니다. 몇 가지의 선택지 중에 하나를 고르게 하였고 저는 그 중에 Redis 관리 도구를 선택하였습니다. 관심도 면에서 가장 원했던 과제는 아니었지만 두 달이라는 시간을 고려했을 때 현실적으로 도전할 만 하다고 생각하여 선택하였습니다.
3. 프로젝트 진행
1) 웹 풀스택 개발
개발은 웹 풀스택으로 web, api 모두 개발했습니다. 인턴을 하기 전까지는 백엔드 개발, 프론트엔드 개발, 인프라로 개발자의 역할을 나누어 생각했었는데 여기서는 딱히 경계를 두지 않는 것 같습니다. 좋은 개발자가 되려면 제한을 두지 않는 게 좋다고 생각하고 웹 풀스택 개발자를 지향하는 입장에서 옳은 방향이라고 생각합니다.
프론트엔드 개발을 주로 하시다가 백엔드 개발을 하기 위해서 부서를 옮기시기도 하고 풀스택 개발을 하시다가 데이터 엔지니어링 개발을 하기 위해서 부서를 옮기는 모습을 보고 “이게 ‘참 개발자’구나”라고 느꼈습니다.
2) 과제 수행을 위한 학습
멘토님께서 과제 수행을 하면서 typescript, react, graphql, apollo, koa, mongodb, elasticsearch를 공부하면 좋다는 얘기를 하셨습니다. 그런데 이 중에서 typescript 빼고 제가 제대로 사용해본 기술이 하나도 없었습니다. 제가 선택한 과제를 위해서는 redis도 공부해야 했습니다. 그래서 모두 공부할 수는 없겠다는 생각에 react, koa, redis를 새롭게 공부하고 추가로 global state를 위해서 redux를 학습했습니다.
다른 부서의 인턴을 보니까 학습한 내용에 대해서 주기적으로 공유하는 시간을 가지기도 한 것 같습니다. 저희 부서는 학습한 내용을 정리해서 발표하는 자리가 따로 있지는 않았습니다. (사실 중간에 멘토님께서 하고 싶냐고 물어 봤는데 부담스러워서 안하겠다고 했습니다.😂 했다면 분명 도움이 됐을 것입니다.) 대신 개인적으로 notion에 학습한 내용을 그때 그때 정리해 두었습니다.
3) 프로젝트 관리
프로그래머스라는 사이트에서 몇몇 개발 챌린지에 참여한 경험이 있습니다. 참여해본 사람이라면 알겠지만 개발 요청 사항이 꽤나 자세히 안내돼있습니다. 그런데 인턴 과제는 주어진 요청 사항이 놀라울 만큼 간단했습니다. 10줄 정도 되는 문장 두 개가 끝이었습니다. 세부적으로 개발에 필요한 사항은 알아서 찾고 구현해야 합니다. (물론 물어보면 친절하게 알려주십니다.) 그래서 프로젝트 진행에 있어서 갈피를 못 잡을 수도 있습니다. 인턴 초반부터 그런 느낌이 들어서 trello를 활용하여 프로젝트를 관리했습니다.
처음에는 master 브랜치에서 commit을 남기는 것으로만 코드의 버전를 관리했습니다. 그런데 다른 분들이 보기에 코드와 커밋 메시지만으로는 작업한 흐름을 한 눈에 보기 어렵기 때문에 issue와 PR 기능을 활용하라는 조언을 들었습니다. 이후로 개인적으로 프로젝트를 관리하는 목적으로 trello를 사용하였고 다른 팀원분들과 프로젝트 진행 상황을 공유하는 목적으로 github의 issue, PR 기능을 사용하였습니다.
4) 기술적 고민
<connection 관리 전략>
브라우저와 서버 간의 통신에 HTTP 프로토콜이 사용되고, redis client와 redis server간의 통신에는 RESP라는 프로토콜이 사용됩니다. RESP는 HTTP와 마찬가지로 TCP 프로토콜을 기반으로 하고 있습니다. HTTP와 RESP 모두 클라이언트와 서버 사이의 커넥션을 제공하는 TCP를 기반으로 하기 때문에 connection 관리 전략이 중요합니다. 그런데 HTTP는 요청 메시지의 헤더만으로 쉽게 관리할 수 있는 반면, RESP는 connection 관리 전략을 직접 구현해 줘야 합니다.
redis에서의 connection 관리 전략을 redis client와 redis server 입장에서 생각할 수 있습니다. redis server 입장에서는 redis.conf 설정으로 쉽게 구현할 수 있고 이에 따라서 redis client 입장에서는 굳이 connection 관리를 생각하지 않아도 될 수 있습니다. 하지만 redis server에 의존하는 것이라 redis client 입장에서도 connection 관리가 필요하다고 생각했습니다. 제가 생각한 redis client 입장에서의 connection 관리 전략은 다음 세 가지입니다.
- 하나의 http 요청마다 redis connection을 생성하고 요청을 처리한 후 connectioin을 삭제하는 방법
(HTTP/1.0에서의 단기 커넥션 방법과 비슷합니다.) - 처음으로 http 요청이 들어오면 특정 기간만큼 살아 있는 redis connection을 생성하고 이를 재활용하는 방법
(HTTP/1.1에서의 영속 커넥션 방법과 비슷합니다.)
+ redis 서버마다 한 개의 connection을 생성하여 여러 브라우저에서 같은 redis 서버에 요청을 보낼 경우 하나의 connection을 공유하는 방법 - 처음으로 http 요청이 들어오면 특정 기간만큼 살아 있는 redis connection을 생성하고 이를 재활용하는 방법
(HTTP/1.1에서의 영속 커넥션 방법과 비슷합니다.)
+ 브라우저와 redis 서버 당 한 개의 connection을 생성하여 여러 브라우저에서 같은 redis 서버에 요청을 보내더라도 각기 다른 connection을 사용하는 방법
저는 TCP Connection 비용을 없앤다는 이유와 함께 redis 설정 중 maxclients의 기본 설정이 10,000인 것을 참고하여 제일 합리적인 방법이라 생각한 세 번째 방법을 선택했습니다.
추가로, 세 번째 방법을 위해서는 client 식별을 어떻게 할 지에 대한 문제를 해결해야 합니다. 이를 위해서 cookie와 session을 활용했습니다. client를 browser라고 칭한 것도 이 때문입니다. 최종적으로 아래 로직을 따르는 REST API를 구현하였습니다.
5) 재택근무
코로나 바이러스로 인해서 인턴 기간의 반 정도는 재택근무를 했습니다. 그래서 팀원분들과 만나서 얘기하는 기회가 별로 없었고 식사라도 함께할 기회가 적었습니다. 인턴 기간 중 가장 아쉬운 점이라고 한다면 이 점을 꼽고 싶습니다. 하지만 지금 와서 생각해보니 개발 문화를 제대로 느낄 수 있는 기회였습니다.
재택근무 체제를 시행한 것이 국가나 상부의 지침 때문이 아니라 순수하게 코로나의 위험을 줄이기 위해서라고 느꼈습니다. 당연한 얘기인데 당연하게 생각할 수 있는 이유는 굳게 자리 잡은 개발 문화라고 생각합니다.
Glace CIC는 기본적으로 책임 근무제로 운영됩니다. 그래서 자유와 책임이 공존합니다. 누가 시키지 않아도 알아서 잘 하는 분위기를 가지고 있습니다. 원래 하던 대로 할 일 하고 공유하면 된다는 마인드로 코로나로 인한 재택근무를 대수롭지 않게 여기는 것 같았습니다. 소통 문제는 사내 커뮤니케이션 앱과 github로 활발히 이루어지고 있어 별 문제가 되지 않았습니다. 스스로 동기부여가 되는 개발자에게는 최고의 근무 환경이 아닐까 생각합니다.
저는 처음 재택근무를 할 때 제 자신을 믿지 못하고 조금 불안했었습니다. 하지만 그 분위기 속에 있으니 스스로 열심히 하고 있었습니다. 출퇴근 시간 2시간을 벌고 체력 소모를 줄일 수 있어서 퇴근 후에 부족한 공부를 할 수도 있었습니다.
4. 최종 발표
인턴 기간 동안 많은 성장을 이룬 것 같아 만족감을 느끼면서도 비전공자로서 cs 지식의 부족함을 느끼고 기술 스택에 있어서도 아직 배워야할 게 많다는 사실에 최종 발표를 준비하면서 자신감이 많이 떨어져 있었습니다. 최종 발표 불과 몇 시간 전까지만 하더라도 열등감에 사로잡힌 상태였습니다.
인턴 기간을 열심히 보냈고 후회 없이 마무리 하고 싶단 생각에 마음가짐을 바로 잡으려고 노력했습니다. 다른 사람과 비교하지 말자고 되뇌이고 인턴 시작 전보다 성장한 나를 보여주는 것이 중요하다고 마음을 다잡았습니다. 결국 발표할 때 굉장히 떠는 성격인데도 최종 발표에서 최대한 보여준 것 같아 끝까지 만족스럽게 끝낼 수 있었습니다.
5. 마치며
사무실 책상에 앉아 네이버에 왔다는 생각에 히죽거리던 게 엊그제 같은데 벌써 인턴이 끝나고 후기를 작성하고 있다니 감회가 새롭습니다. 가능성을 알아봐 주시고 핵데이에 참여할 수 있는 기회를 주셨던 핵데이 멘토님에게 감사드리고 인턴 생활을 잘 보내고 과제를 잘 끝낼 수 있도록 도와주신 팀원분들에게 감사드립니다. 앞으로도 더욱 발전하는 개발자가 되겠다고 다시 다짐하며 후기를 마치겠습니다. 긴 글 읽어주셔서 감사합니다!
