2020 Naver Hackday Review 네이버 핵데이 후기
- 2020년 5월 6일부터 28일까지 진행한 2020 Naver Hackday 네이버 핵데이 후기 입니다.
서류 지원
사실 핵데이 지원 자체는 이번이 처음이지만 시도로는 2번째(?)다.
처음 시도는 2019년 초에 회사를 다니면서 작성했었는데, 지원 해 본 사람은 알겠지만, 지원서에 문항이 정말 많다.
다른 어떤 지원서와 비교할 수 없을 정도로 문항수와 그 길이가 남다른 편인데, 나름 처음 지원 하는 거라고 힘을 주고 썼다가 마지막 제출 시간 1시간을 남겨두고 퇴근과 함께 쏟아진 잠에 깜빡 졸았다가 기간을 놓쳐버린 케이스다.
그래서, 이번에는 너무 힘을 주고 쓰기보다는 내용 전달에 집중해서 미사여구는 빼고 담백함을 위주로 담은 것 같다.
내가 한 것들을 최대한 이해하기 쉽게 실제 사례에 비추어 전달하는것에 초점을 맞추었고 기술 역량에는 공부한 내용과 적절히 섞어서 작성했더니 바로 다음 전형인 코딩테스트로 이어졌다.
코딩 테스트
서류를 합격하고, 바로 코딩테스트를 진행했는데 계속 코테를 봐 온 입장에서 문제 난이도는 그렇게 어렵지 않았다. 대부분의 분들도 그렇겠지만 3문제 중 2번까지는 쉬운 편이었고 3번문제는 갑자기 확 어려워지는 느낌이라서 100점을 맞지는 못 했지만, 다행히도 합격해서 네이버 핵데이를 할 수 있게 되었다.
여담이지만, 어떻게 뽑게 됐는지를 물어보았을 때, 모든 문제를 푼 사람도 좋지만, 최소한 2문제 이상을 푼 사람들은 서류를 보고 뽑았다고 이야기를 들었다.
다만 COVID-19의 영향으로 그렇게 가보고 싶었던 NAVER 춘천 연수원은 못 가보고 온라인 해커톤 방식으로 진행되었다. 춘천 구봉산을 놀러가면 그 옆에 펼쳐진 네이버 데이터센터가 정말 멋져보였고 언젠가 한번 방문 해 보고 싶다고 느낄 정도였는데 첫 핵데이에서 그것을 이루지 못해서 아쉬움이 이만저만이 아니었다.
네이버 웹툰 프로젝트
내가 참여한 프로젝트는 전체 총 15개의 다양한 법인에서 나온 프로젝트 중 네이버 웹툰에서 진행하는 네이버 웹툰 썸네일 저작 도구를 만드는 것이었다.
요구사항은 쉽게 말해서 온라인으로 편집 할 수 있는 포토샵을 만드는 것이었다.
나는 커리어를 Backend로 시작했다가 Frontend에서 적성을 찾아서 이쪽으로 깊이 공부하는 중이다보니 이런 프로젝트 위주로 보았고, 2지망으로도 플레이스 리뷰 실시간 Dashboard를 선택했었다. 운이 좋게도 1지망으로 선택한 것이 선정되어 프로젝트에 참여 할 수 있게 되었다.
팀 구성 및 회의
저번 핵데이까지는 한 팀에 3명씩이었는데 이번 핵데이는 온라인으로 진행되어서 그런지 한 팀에 5명씩 배정 된 것 같다. 우리팀의 멘토분들은 한 프로젝트에 5명은 다소 많다고 생각이 드셨는지 2, 3 명으로 나누어 같은 내용으로 프로젝트를 하자고 제안하셨고 나는 2명팀으로 배정되어 프로젝트를 진행하게 되었다.
초기 디자인
팀 구성을 마친 당일날 바로 어떤식으로 진행할지 회의를 했다.
운이 좋게도 함께 팀원으로 활동 해 주신 분이 오픈마인드로 여러가지를 시도해보자는 요청에도 OK 해주셔서 굉장히 좋았었다. 사실 이 단계에서 마음이 맞지 않으면 일이 축축 쳐지기 마련인데 당일에 바로 페이퍼 디자인까지 뽑을 수 있었던것은 합이 척척 맞았기 때문이 아니었을까.
Convention 맞추기
이 외에도 협업을 위해 코딩 컨벤션을 맞추기 위해 vscode의 prettier 설정을 서로 맞추었는데, .prettierrc 파일을 만들어 맞추자는 얘기도 나올 만큼 서로 협업의 중요성은 잘 알고 있었던 것 같다. 이 외에도 commit message 규칙을 만들어 작업 기록에 대한 중요성도 인지하고 있었고, 아마 이 프로젝트가 장기화 되었으면 더 가치를 빛낼 여러가지 것들을 하루만에 맞출 수 있었던 것 같다.
개발.. 개발..막혀도 Go!
처음에는 다양한 색상을 사용해 각 컴포넌트를 분리하는 작업을 CRA와 함께 레이아웃을 먼저 잡았다.
이후에는 store management나 typescript 등을 도입하여 프로젝트 생산성을 높일 수 있었다.
컴포넌트 단위로 구분해서 처음에 레이아웃을 잡아놓으니 이후에 개발을 할 때에도 issue를 각자 assign 해서 작업하니 gitflow 덕분에 충돌도 나지 않아서 빠른 개발을 할 수 있었던 것 같다.
mobx 가 문제를 일으키기 전 까지는
MobX의 이면.. Black Magic!
이 글을 쓴 이유라고 할 수도 있는 mobx의 저주에 대한 이야기이다.
실제로 PR에도 가장 comment가 많이 달린 issue이기도 하다.
개발을 하다보면 Magic 이라는 말에 쉽게 혹하곤 하는데 아무래도 Java Spring 처럼 A-Z 보다는 Ruby On Rails 처럼 Convention over Configuration 방식이 손이 덜 가고 API 콜만으로 완성되기 때문에 빠르게 개발해야되는 이번 프로젝트에서는 겁도없이 MobX를 사용하고자 했다. 왜냐하면 이전에 class component에서는 잘 써 왔고, 문제를 일으킨 적이 없이 잘 작동했기 때문이었다.
하지만, 이것이 재앙의 시작이 될 지는 아무도 몰랐다.
위의 버그들을 설명하기 위해서는 Redux의 불변성 법칙을 먼저 알고 가야 한다.
Redux의 상태는 읽기 전용이며, Reducer는 순수 함수를 유지하면서 상태의 불변성을 개발자가 만들어주어야 한다. 이외에도 객체는 상태로 할당하지 말아야하며 스토어는 하나만 써야한다는 법칙이 있지만, 불변성 을 유지하는것이 핵심인 상태 관리 라이브러리이다.
MobX에서는 Simple, scalable state management 이라는 소개로 이러한 설정들을 스스로 알아서 해주는 것에 초점을 맞춘 상태 관리 라이브러리이다.
하지만, 이번 프로젝트에서 MobX는 예상대로 동작하지 않았고, 그 이유는 Functional component기반의 React Hooks API 사용에서 비롯된다고 판단하였다.
예를들어 설명하면 Layer store 에는 각각의 이미지 객체가 배열에 들어가있는데, 새로운 레이어가 추가될 때 마다 배열의 제일 앞에 새 객체가 추가되는 식으로 구현을 했다. 하지만, Layer store를 구독하는 Component 들은 이런 배열이 바뀌는 것을 객체 전체의 데이터를 변경했고, shift되어 자연스럽게 구현될 것이라 생각 했던 것과 다르게 동작했다. 또한 class component를 hooks와 연동하며 발생한 문제도 자연스럽지 않은 흐름을 만드는 것에 한몫 한 것 같다. 그렇게 나는 너무나 소중한 4일을 날려버린 끝에 Redux로 library 를 변경하며 Mobx 와는 정을 떼게 된다.
결론은 MobX는 Magic은 Magic인데 Black Magic일 수도 있으니 제대로 알고 사용하자
이게 완성된다고?
4일이라는 귀중한 시간을 MobX 하나 때문에 날려버린건 정말 천추의 한이지만, Redux로 변경하고나서 부터는 프로젝트에 속도가 제대로 붙기 시작했다.
Redux는 MobX에 비해서 편리함과 사용성은 떨어지지만, 직관성 만큼은 Magic이라는 이름 아래 나에게는 빚좋은 개살구같던 MobX 보다 뛰어났다.
Zerocho Blog 발췌
각각의 상태는 컴포넌트를 렌더링하고, 컴포넌트에서 발생한 액션은 정의된 Reducer에 의해 상태로 반영된다.
MobX도 이와 같은 흐름을 비슷하게 갖고 있긴 하지만 코드에서는 이것이 많이 숨겨져 있는 편이다.
일단 4일의 번뇌를 넘고나니 머릿속에 그려져있던 그림은 실체화에 속도가 붙기 시작했고 결과물은 아래와 같이 나왔다.
프로젝트 회고
Frontend를 React Native로 처음 접하고 React를 배우고 써본 것이 이번이 처음인데, 언젠간 하겠지 하는 마음으로 미뤄두었던 기술 스택을 이번 기회에 React(with Hooks)를 하며 많은 것을 접했다.
2020년 6월이 되어서 개인 프로젝트와 과거의 코드들을 되돌아 보았는데, Styled Components 를 왜 쓰지 않았지 TSC를 왜쓰지 않았지 하는 의문 투성이인 코드들이 산재해 있었다. 과장 좀 보태서 HTML & CSS로만 작업하다가 React Native로 앱을 처음 접하게 되었던 과거가 생각 날 만큼 개인적으로는 엄청 성장한 시간이었다.
아쉬운 점
그럼에도 불구하고 아쉬운것은 어느 프로젝트나 마찬가지인데 대표적으로 2가지가 생각난다.
첫째로 성능 개선을 이루어보지 못 한 것.
React dev tools 를 켜고 re rendering 성능을 측정 해 보면 이미지를 추가할 때 서로 관련이 없는 Component 들도 re render되는 현상이 발견되는데, 비단 이런 상황 뿐 아니라 이미지 리사이징이나 로테이션에서도 똑같이 rerender 되는 현상이 발견된다. 이런 현상은 Redux에다가 객체를 넣고, 이를 불변성 유지를 위해 통째로 교체를 하기 떄문에 일어나는 현상인데, 이를 인지하고 있는 지금 다시 코드를 짠다면 특정 Flag로 변화를 알리거나 JSON type으로 데이터를 다루며 layers 전체를 교체하지 않고 특정 데이터만 수정하여 re render를 방지 할 수 있을 것 같다.
둘째, HTML Element로 image controll을 구현했지만 mouse Event 로 자연스럽게 하지 못 한 것
현재 마중그림은 이미지 리사이징이나 로테이션이 controller 에서 slider로 조절하는 방식으로 되어있는데, 일반적으로 포토샵이나 기타 이미지 편집툴에서는 image border쪽을 Mouse Event로 조절할 수 있게 되어있기 때문에 부자연스럽게 받아들여지는 UX가 만들어지게 되었다.
구현하는 방법은 이게 쉬워서 일단 이렇게 만들어 놨는데, 개발 기간이 막판에 쫄려서 쳐내지게 된 경우이다.
이게 더 아쉬운 이유는 Canvas 로 구현했다면 더 까다롭게 했었어야 했는데, 이런 단점을 HTML Element로 극복했으면서 십분 활용하지 못한 아쉬움이 매우 크다.
그래도 잘 한 것
프로젝트를 하며 코드 충돌을 방지하기 위해 GitHub을 잘 사용했다고 생각한다.
그리고 추가적으로 개발 일정 관리를 위해 GitHub Projects나 Issues를 적극 활용했는데, 소규모의 프로젝트에서 Trello나 Jira로 티켓을 만들어 하는 것 보다는 GitHub Projects를 사용하면 더 쉽고 편리하게 작업 할 수 있었던 것 같다.
한가지 아쉬웠던 점은 Github Actions를 만질 일도 있었는데, 이를 활용하면 코드가 merge 될 때마다 CI/CD 를 깃헙 페이지로 자동으로 배포되게 할 수 있었는데 권한 문제로 결국엔 적용하지 못했지만, 어떤식으로 돌아가는지 파악 할 수 있어서 다음 프로젝트에서 기회가 되는대로 적극 사용 할 예정이다.
그렇게 완성하게 된 인피니티 스톤 깃헙의 다양한 기능들이 마치 타노스의 그것을 보는 느낌이었다 ㅋㅋ
툴로써 완전해지지는 않겠지만, 그것으로 더욱 강력 해 지는 개발자가 되는 기분이다.
GitHub은 알면 알수록 공부할 게 많은 곳이지만, 역시 그럴 때마다 성장하게 되는 것 같다.
이번에는 특히 Container Presenter Pattern을 사용하려고 의식했는데 이는 마치 양 목장에서 디자인 패턴이라는 울타리를 쳐 두고 그 안에서 React를 자유롭게 다뤄 볼 수 있는 안전장치 역할을 했기 때문에 이러한 방식을 앞으로도 계속 사용 할 수 있을 것 같다.
참여 후기
사실 오늘 이 글을 쓰는 날에 인턴으로의 전환 면접에는 참석 할 수 없다는 통보를 받고 기분이 다운되어 있었지만, 생각 해 보면 이 프로젝트를 통해 성장한 내 자신이 그것보다 더 가치있었던 시간이었는데 나무를 너무 보다보면 숲을 놓친다는 것을 잊을 뻔했다.
네이버 핵데이는 학생때만 참여 할 수 있는 해커톤이지만 그 수준만큼은 학생 그 이상의 것을 얻어 갈 수 있는 행사이다. 온라인으로 지원되어 춘천 연수원에는 방문 해 보지 못했지만 그에 상응하는 다양한 온라인 지원과 음식(?)과 공간 지원을 받았기 때문에 한달동안 시간과 정신의 방에서 수련을 하다 돌아온 손오공의 느낌이 나기도 한다.
위 내용의 후기들은 슬라이드 쉐어에 더 잘 정리된 발표자료가 있다.
혹시 더 자세한 내용을 알고싶으신 분들은 발표자료를 참고 하시면 될 것 같다.
