[Today I Experience] SW 중심대학 공동해커톤 참가 후기

나의 해커톤 첫 참가

2021.02.04 ~ 2021.02.06 까지 SW 중심대학에서 주최한 해커톤이 진행되었다. 각 팀은 디자이너 1명, 개발자 4명 총 5명으로 이루어졌고 도합 39팀이 참여한 행사였다.

해커톤 OT는 1월 31일에 열렸다. 이 때부터 해커톤 시작 날인 2월 4일 2시까지 참가자들은 해커톤에서 개발하고자 하는 아이디어를 제시할 수 있었고, 그 아이디어가 마음에 드는 참가자는 해당 아이디어를 낸 사람의 팀원이 되는 방식으로 팀빌딩이 진행되었다. 나는 해커톤 뿐만 아니라 그 어떤 SW 행사에 참가한 경험이 없었고, 따라서 이번 해커톤에 가벼운 마음으로 협업 경험을 쌓자는 생각으로 참가했다.

아이디어 모집 기간 동안 정말 많은 아이디어가 등록됐다. 참가할 팀의 아이디어를 선택할 때, 참신한 아이디어가 몇 개 보였지만 내가 다루어보지 않은 스택을 필요로 하거나 기간 내에 구현하지 못할 거 같다는 생각에 해당 팀에 팀원 신청을 하지 못하는 상황에 맞닥뜨렸고, 내가 그나마 할 줄 아는 express.js 를 사용하는 팀으로 내 선택지는 좁혀졌다.
우여곡절 끝에 내가 선택한 팀의 아이디어는 “입력값으로 주어지는 문단을 토대로 질문 - 답변 세트들을 만들어주는 API를 이용한 암기 과목 효율 증대 사이트” 였다. 자세한 내용은 아래 유튜브 링크로 대체한다.
아이디어 “Ask Yourself” 소개 - https://youtu.be/PnPol_eAPdg

해커톤에서 경험한 것들..

2월 4일 5시부터 본격적인 개발이 시작되었다. 사실 2박 3일 내내 코딩만 하다보니 언제 어떤 생각을 했는지 기억이 흐릿하다… (진짜 눈부터 목, 어깨가 아파서 화면을 못보겠는 진귀한(?) 경험이었다) 하지만 분명 하드한 일정으로 코딩을 하면서 느낀 바가 있기에 최대한 기억을 살려 여기 남겨두고자 한다.

협업은 정말 어렵다!

해커톤을 하면서 가장 크게 느낀 점은 “협업은 절대 쉬운 일이 아니다” 라는 것이다. 일반적인 팀 프로젝트와 달리 짧은 시간 내에 구현을 완료해야하는 해커톤 특성상, 빠른 구현에 집중해야 했지만 그렇다고 프론트 - 백엔드 사이 원활한 소통을 위해 정해두어야 할 것들을 전부 스킵할 수는 없는 노릇이었다. 여기서 “빠르게 구현하기 위해 어느 정도까지 스킵해도 되는가?” 라는 딜레마에 빠졌다.
지금와서 생각해보면 시간이 걸리더라도 구현을 시작하기 전에 아이디어 구체화, 깃 커밋 컨벤션, PR 작성, REST API 규칙 등을 완벽하게 정해두었어야 했다. 팀원들은 이것들에 대해 자세히 의논할 생각이 없어보였고, 난 이런 상황에서 나서기 싫어하는 성격일 뿐만 아니라 해커톤 경험도 없어서 팀 분위기에 맞게 대충 이야기하고 넘어가버렸다. 기업에 왜 PM이 필요한지, 프로젝트 팀에 왜 경험 많은 리더가 필요한지 확실히 깨달을 수 있었다. 구현할 기능 디테일을 정확히 하지 않고 개발한 결과는… 당연하게도 시간 내 구현에 실패했다.

질문하는걸 망설이지 말자.

해커톤에는 참가자들의 개발을 도와줄 능력있는 여러 멘토분들이 계셨다. 나와 내 팀원은 DB 설계에서 난항을 겪었고, 이 부분이 결과적으로 개발이 늦어지게 된 이유 중 하나가 되었다. 슬랙 채널에서 여러 참가자들이 적극적으로 멘토분들에게 질문을 하는 걸 봤지만, 나는 우리팀이 겪고 있는 문제점을 멘토에게 질문함으로써 빠르게 해결할 시도를 하지 않았다. 꽤 많은 팀들이 멘토의 도움으로 빠르게 개발 진행을 이뤄낸 것을 보면 만약 그 때 내가 멘토분에게 질문을 했으면 어땠을까 하는 아쉬움이 남는다.
이렇게 적다보니 나의 소극적인 성격이 여러 문제를 일으키고 있다는 사실이 보인다. 어느 상황에서든 소극적인 성격이 도움이 되는 경우는 없는 것 같다. 어떻게 나를 변화시킬 수 있을지 진지한 고민이 필요하다.

다른 사람에게 자신있게 설명할 수 있을 정도로 공부하자!

팀 프로젝트의 각 팀원들은 알고 있는 내용도 다르고, 그 깊이도 다르다. 따라서 서로 의논을 할 때 의견에 차이가 있을 수 밖에 없다. 여기서 다른 팀원들을 논리적으로 설득하기 위해선 내가 알고 있는 지식에 대한 자신감이 있어야 함을 느꼈다. 특히 RDBMS의 erd를 설계할 때가 그랬다. 내가 제시한 방식이 더 나을 것 같다는 주장을 하면서도 왜 나의 방식이 더 나은지를 자신있게 설명하지 못했다. 아마 RDBMS에 대해 자세히 공부하지 않았기 때문일 것이다. 또한 간단한 테이블 + 복잡한 쿼리와 복잡한 테이블 + 간단한 쿼리 중 무엇이 더 나은 방법인지도 내가 제대로 알지 못했기에 내 생각을 자신있게 말할 수가 없었다. 앞으로 공부할 개념들은 반드시 남에게 술술 설명할 수 있을 정도까지 공부하고 넘어가야겠다는 생각이 들었다.

앞으로의 계획

해커톤에서 만족스런 결과를 내놓진 못했지만 그래도 배운 점이 아예 없다는 생각은 들지 않는다. 다른 SW 행사에 참가하여 팀 프로젝트를 하는 활동은 충분히 값진 경험이고, 기회가 생기면 꼭 참여할 생각이다.
요즈음 관심을 갖고 공부중인 node.js를 이번 방학에 깊이 공부할 것이다. “Node.js 교과서” 라는 책을 구매했고, 이 책을 한 번 훑으며 node.js에 대한 기본적인 지식을 다질 계획이다.

지금까지 이것저것 공부해보며 느낀 점은, 프로그래밍 실력과 CS지식을 동시에 늘릴 수 있는 방법은 흥미로운 토이 프로젝트를 만들어 가며 그때그때 필요한 지식을 공부하고 적용해보는 방법이라는 생각이 든다. 평소에 어떤 프로젝트를 만들어 볼까 라는 생각으로 내가 만들어보고 싶은 토이 프로젝트 주제를 고르고, 그 프로젝트를 만들면서 실력과 포트폴리오 두 마리 토끼를 잡는 방향으로 공부하고자 한다.