언젠가부터 주위 동기들이 해커톤 (Hackaton) 에서 좋은 경험을 하고 오는 걸 보면서,
항상 나도 해보고 싶다는 마음은 있었지만 현생이 바쁘다는 이유로 단 한번도 도전해보지 않았었다.

핑계는...

길고 길었던 지옥의 사망년을 벗어난 기념으로, 지난 4월 세 개의 해커톤을 지원했고 운 좋게 두 개를 합격하였다.
이번 포스트에서는 그 중 NAVER CAMPUS HACKDAY 후기를 작성하고자 한다.

나머지 하나는 추후에 업로드 예정이다. ~~아마도…~~

2019 NAVER CAMPUS HACKDAY SUMMER

NAVER D2 - CAMPUS HACKDAY 행사 안내 https://d2.naver.com/news/5009947

GITHUB Page https://github.com/NAVER-CAMPUS-HACKDAY/common

깃헙 레포의 이슈에 있는 37개의 주제 중 희망하는 1~2개의 주제를 골라 지원서를 작성하고, 4월 13일에 온라인 코딩 테스트를 보았다.

코딩 테스트는 원하는 시간에 접속하여 제한시간 두 시간동안 3문제를 풀어야 했고, 문제 난이도는 그리 높은 편은 아니었던 것 같다. 제출하는 시간도 기록되었기 때문에 테스트 케이스를 적당히 확인하고 한 시간 조금 넘은 시점에 제출했다.

후담이지만 Google code jam의 ‘Round 1A 2019’ 도 같은 날에 진행되어서 스타벅스에 앉아서 하루죙일 정신없이 문제만 풀었다. 🤦🏻‍♀️

🎉 햅격~ 🎉

기대 안하고 있었지만 사실 기대하긴 했다. (ㅋㅋㅋㅋㅋㅋㅋㅋㅋ)

해커톤 중에서도 Naver hackday는 꼭 한번쯤 가보고 싶었던 행사였기 때문에 특히 좋았다. 기쁜 와중에 딱 날짜가 종설 프로젝트 중간 발표 날이라서 팀원들에게 미리 양해를 구했는데, 다행히 마음씨 좋은 우리 팀원분들은 너그럽게 이해해주셨다.

Before Hack-day

내가 수행하게 된 주제는 “컨테이너 기반 쇼핑 상품 정보 수신” 으로, 세 명이 한 팀을 이루고 멘토님 한 분이 함께 해주셨다.

[컨테이너 기반 쇼핑 상품 정보 수신]

https://github.com/NAVER-CAMPUS-HACKDAY/common/issues/7

상품정보 수집을 위하여 각 쇼핑몰에서 제공하는 상품정보 EP(Engine Page)를 주기적으로 수집하여 변경된 정보를 체크하고 서비스에 반영하고 있다. 해당 작업의 확장성 및 고가용성을 위하여 Kubernetes 등의 컨테이너 환경에서 Task Agent 들이 운용될 수 있도록 설계 및 구현이 필요하다.

해커톤 행사 당일에 주제 선정과 개발이 모두 이루어지는 다른 해커톤들과는 다르게 Naver Campus Hackday는 본인이 지원한 주제에 따라 팀이 꾸려지고, 사전에 멘토님의 가이드에 따라 팀끼리 개발을 어느정도 진행하기도 한다. ( → 해당 부분은 팀by팀 인 듯)

프로젝트에 대해서는 멘토님께 사전에 여쭤봤을 때, 구체적인 플로우는 공개할 수 없으나 내가 짠 코드는 무관하다고 답변을 주셔서 공식 Hackday github 이슈에 노출되어있는 프로젝트의 개괄적인 내용과 함께 느낀점만 간략하게 정리하고자 한다.

우리 팀의 경우 특히 인프라 구축이 필요한 주제였기 때문에 사전에 LINE과 Github을 통해 온라인 회의를 지속적으로 진행했다. 이를 통해 나는 아래와 같은 사전 준비를 하고서 Hackday에 참가하였다.

MQ(Message Queue), 데이터 처리 방법 등에 대한 이해
- MQ란 무엇이고, 프로젝트에 적합한 프로젝트는 무엇인가?
- 데이터 처리 방식 중 Batch와 Stream의 차이와 각각의 장단점은?
- 확장성과 고가용성을 고려하였을 때 적합한 데이터 저장 및 분석 방법은?
서버 운용 및 클러스터링 계획
- 사전에 할당받은 10개의 서버를 어떻게 운용할 것인가?
- 어떤 기술 스택을 사용할 것인가?
- 어떤식으로 Clustering할 것인가?
- 어떠한 플로우로 데이터를 처리하고, 어떻게 분석할 것인가? (설계)
  1
  2
  3
  Container Management : Kubernetes
  Message Queue : Kafka
  Database & Analytics Engine : Hbase + Spark
컨테이너 기반 (Kubernetes)
- 어느 범위까지 컨테이너화할 것인가?
- Kubernetes Clustering은 어떻게 구성 할 것인가?
- Docker registry는 어떤식으로 사용할 것인가?

그 외에도 대용량 데이터 처리임을 고려하여 어떻게하면 속도와 공간 효율성을 확보할 수 있을 지에 대한 고민을 정말 많이 했다.

내가 알고 있는거라곤 ‘쿠버네티스’ 다섯 글자 뿐…
이때까지 이정도의 대용량 데이터 처리를 해본적이 없었고 MQ 나 Hadoop 사용 경험도 없었기 때문에 처음 접하는 것들이 대부분이었다. 책도 찾아 읽고 나름대로의 공부도 많이 해서 어느정도 설계까지는 했지만 막상 실제 인프라 구축은 막막하기만 했는데, 우리 팀에 데이터 마술사님(!)이 계셔서 초반 구축을 ~~알잘딱깔센~~ 해주셔서 🐶🍯 이었다.

Hackday 준비를 하면서 공부도 많이 됐지만 능력있고 열정있는 팀원님을 보면서 특히 많이 배웠다. 최고의 팀원 최고 bbb

D-day, Hack-day

Hackday 당일, 춘천으로 출발 전에 미리 모여 멘토님과 간단하게 점심 식사를 했다.
그린 팩토리 근처 식당에서 돈까스 먹었는데 굉장히 맷-집 이더라. JMTGR.

??: 좋아해요?

멘토님을 처음 뵙는 자리라 조금 긴장도 됐었는데 생각보다 편한 분위기로 얘기를 나누고 근처 카페에서 커피도 사주셔서 감사하게 먹고 그린팩토리로 향했다.

하지만 모든게 평화롭고 순조로운 가운데, 한가지 문제가 있었다.

팀원 분 중에 한 분이 몸이 아프셔서 당일 날 못 오신 것이다. 위에서 말했다 싶이 한 팀당 3명이 팀이었고, 대부분 세 명인 가운데 갑자기 우리팀만 둘이 되었다.

이 때 느낌왔다. 오늘 숙소 구경은 물건너 갔음을.

행사 진행 장소인 NAVER CONNECT ONE은 내부 사진 공개를 금하고 있기 때문에 시설 모습이 보이는 구체적인 사진들은 공개할 수 없다.

사실 나와 다른 팀원님은 커네트원이 두 번째 방문이라 구경은 제쳐두고 회의실에만 박혀있었어서 사진도 거의 안찍었다. 때 맞춰 나와 밥 먹고 당 떨어지면 간식 가져오는 거 외에는 회의실에 스스로를 감금했다.

왜냐고? 순조롭긴 개뿔 내가 해간거 하나도 안됐다. ~~tlqk~~

인프라 특 _ 이유없이 갑자기 안됨

루까 특 _ 이유없긴 사실상 본인 잘못임

도착하자 마자 마음이 급했던 우리 팀은 곧 바로 회의를 시작했다. 사전에 온라인 회의를 통해 설계를 논의하긴 했었지만 확정은 아니었고, 그 이후로 각자가 고민했던 부분과 그 결과로 설계한 구조를 서로 공유하고 멘토님께 피드백을 받았다.

결론만 얘기하자면, 나와 다른 팀원님의 디자인은 완전히 달랐다.

같은 문제를 접했고 사용할 인프라도 같이 정했음에도 불구하고, 생각하는 해결 방식이 다른 것이다. 이런 점이 사실 놀랍기도 하고 또 각 방법의 장단점이 분명해서 어떤 설계에 따라 구현할지 토의를 하면서 많은 고민이 되었다. 결국 일단은 내 설계대로 진행하기로 결론을 냈지만, 여기의 가장 큰 이슈는 Hackday 기간 안에 구현이 가능할지 였다.

✽ 프로젝트 내용은 공개 가능한 범위가 모호하여 일단 보류하고, 추후에 기회가 되는대로 짰던 코드와 함께 겪었던 문제점, 해결 과정, 느낀점 등을 따로 정리하려 한다.

‘혹시’하면 ‘역시’다.

서버들은 이유 없이 돌아가며 터지고,
Kubernetes는 갑자기 막혔고,
Hbase Cluster도 갑자기 터져 팀원님이 해결하고 계시는 와중에
우려 했던 Spark (Scalar) 멘붕까지 터/져/Ba/by 상태

새로운 도메인 지식 습득과 설계에 급급했던 나머지 나는 초반 인프라 구축 참여가 적었고 거기에 대한 이해도가 다소 부족했다. 그 중 Kafka는 비교적 많이 공부를 해갔지만 DB 쪽에는 신경을 많이 쓰지 못했더니,

Java로 Consumer와 Producer를 구현하긴 했는데 막상 데이터를 어떻게 다뤄야 되는지를 모르겠는 거다.

다른 팀원님이 DB 문제를 해결하고 계시는 동안 혼자 Consumer 모듈에 Spark를 적용해보려니 눈앞이 캄캄했다. 밤새 Spark가 대체 뭐며 어떻게 적용해야 하는지를 찾아봐도 참고하라고 주신 Scalar 코드를 봐도 좀 처럼 각이 안나왔다.
이 때 사실 팀원분이 데이터 처리 경험이 나보다 많다는 이유로 나는 너무 안일하게 준비한게 아닌가라는 반성을 많이 했다.

예상했던 대로 그 좋은 숙소는 주인 없는 밤을 보내게 되었다. 🛏

다음 날 점심 식사 후, 최종 결과물을 멘토님께 공유하고 피드백을 받았다.

처음에는 팀 프로젝트였지만 진행하다보니 계획했던 결과를 내기에는 부족함이 있어 결국 팀원 각자 나름의 구현 결과물을 내게 되었다.
(각자의 설계를 기반으로 하되, 각자가 처한 상황에 따라 스펙을 조금씩 바꾸었다)

밤새 구현한 걸 몇 번이고 뒤집어 엎어 최종적으로 계획 했던 동작은 구현하긴 했지만 ‘대용량 데이터 처리’와 ‘컨테이너 환경’에 대한 아쉬움은 어쩔 수 없었다. 이렇게 아쉬움을 한 가득 안고 Campus Hackday는 마무리 되었지만, 또 배워가는 것도 한 가득이라 여러모로 의미가 큰 행사였다.

After ..

Hackday를 다녀와서 가장 먼저 한 일은 잠 🥱 이다. 즈질 체력…;;

그러고나서 까먹기 전에 부족했던 점과 배운 점을 정리하면서
멘토님께 피드백 받은 부분과 스스로 아쉬웠던 부분은 인프라가 아직 남아있을 때 공부하면서 보완해보고자 했다.

~~사람이 안하던 짓을 하면...~~

생각했던 것보다 서버 회수 시기가 앞당겨져서 아쉽기는 했지만, 아쉬운대로 로컬에 최대한 동일한 테스트 환경을 구축해서 Code Refactoring / Test 와 정리한 내용 바탕의 문서 작성을 마치고 팀 Github에 Issue와 PR을 올림으로써 Hackday 프로젝트를 마무리 지었다.

느낀점

Naver Campus Hackday와 다른 해커톤과의 차이점은 실무에 어느정도 직접적인 연관이 있는 문제들을 접하고 그 중 본인이 관심있는 주제를 정할 수 있다는 점이고, 1박 2일 행사 기간 외에도 문제에 대해 좀 더 깊게 고민하고 개발할 수 있는 시간이 있다는 것이다.

그리고 또 다른 큰 차이점은 ‘경쟁이나 시험이 아니다’ 라는 것이다.
다른 팀과의 내용 공유가 따로 없어 어떤 걸 어떻게 해결하셨는지 정말 궁금하긴 했지만, 대신에 비교도 없고 경쟁도 없다.

물론 우수참가자에게는 네이버 인턴 면접기회를 준다는 혜택이 분명 존재하지만, 멘토님도 여러 차례 강조하셨던 것 처럼 정해진 답을 찾는다기보다 실제 실무에서의 문제를 접하고 해결하는 경험을 할 수 있는 기회이다. 경쟁이 아닌 또래의 열정적이고 실력있는 분들을 만나 많이 배우고 자극을 받을 수 있는 점이나, 현업의 네이버 개발자님의 멘토링과 피드백을 받을 수 있는 점 모두 다른 곳에서 경험 할 수 없는 귀한 경험인 것 같다.

끝나고 가장 아쉬웠던 점 중 하나는 사전에 좀 더 많은 시간을 투자해서 당일에는 좀 더 활발한 네트워킹과 구체적인 피드백 (+ 코드 리뷰) 을 받을 수 있었으면 더 좋지 않았을까 하는 것이다.

‘Hackathon’ 이라고 생각하고 ‘Hackday’ 를 충분히 즐기지 못했던게 아쉽긴하지만,
근래 조금은 지쳤던 나에게 좋은 자극 이 되었음에는 틀림 없다.

혹시나 Naver Campus Hackday 참가를 희망하거나 이미 합격하신 분이 이 글을 읽는다면 조금의 도움이 되시길 바라며 글을 마친다.

아디다디도스! 👋🏻

2019 NAVER CAMPUS HACKDAY SUMMER 후기