[kakao X goorm] 9oormthonUNIV 3기 단풍톤, 첫 해커톤 후기!

프론트엔드 개발자로 처음으로 참여했던 해커톤이었다
구름톤 유니브에서 해커톤이었고 자율 팀빌딩 후 11.23~24 카카오 AI 캠퍼스에서 진행했다

AI 캠퍼스

카카오 판교 아지트
카카오프렌즈가 귀엽다. 판교로 취업하고 싶다.

아무튼 해커톤은 팀빌딩부터 데모부스 시연발표까지 나 포함 4명의 팀원과 으쌰으쌰 만들어간 대회여서 배운 것들이 많다
기획, 공용 컴포넌트 개발, axios 연결, 데모부스 준비와 운영 등 많은 걸 했고 기록하지 않으면 까먹을 거 같아서 후기를 적으려고 한다!

그래서 어떤 서비스?

일단 다른 팀들은 PM이 기획을 만들어오고 개발자와 디자이너가 PR해서 팀에 들어갔지만
우리는 PM, 디자이너 없이 팀빌딩이 끝나자마자 아이디어 디벨롭을 시작했기 때문에 첫 회의 전에 각자 어떤 서비스를 만들고 싶은지 생각해왔다
다 좋은 아이디어였지만, 현실적으로 구현하기 쉬운 수준이고, 가장 많은 추천을 받은 "멘토멘티"라는 주제의 서비스로 정했다

당신만의 성향 맞춤형 멘토링 플랫폼, 솜토링

기획, 구체화까지의 과정

한 팀원분의 아이디어로 금방 정해서 첫 회의 때는 아이디어에 살을 붙였다
팀원끼리 어색어색했지만 좋은 아이디어가 많이 나왔다
그러다가 내가 던진 mbti 검사 같은 성향 검사라는 말에 다들 공감 해줬다!
'솜토링'이라는 이름처럼 우리 서비스는 솜사탕이 주제인데 이런 가벼운 수준의 재미 요소라도 없으면 서비스 자체가 너무 딱딱해질 거 같았기 때문이다. 한 팀원분이 아이디어 브레인스토밍 과정에서 학습 성향을 판단하는 것 중에 VARK라는 차트가 있다는 걸 알려주셨는데 사각형 차트보단 오각형이 예뻐서 우리는 우리만의 알고리즘인 VARKI 차트를 이용하기로 했다. 그렇게 우리 서비스의 캐치프라이즈가 정해졌다

이제 클라이언트의 입장에서 어떤 기능이 필요할지 고민하는 2차 회의를 진행했다. 개발 가능 여부에 상관없이 아이디어를 마구 말해보라는 팀장님의 말에 덜어내지 않고 다다익선이라는 생각으로 모든 아이디어를 기록했다ㅎㅎ 다시 생각날지도 모르고 다음에 다른 곳에서도 사용할 수 있으니까!

아래는 그렇게 정해진** 핵심 기능**이다

1. VARKI 테스트 도입
 a. 나만의 학습 스타일에 딱 맞는 멘토 & 멘티와 연결
 b. 간단한 질문으로 학습 스타일 및 성향 파악
 c. 각 요소(V, A, R, K, I)별 가중치 기반 매칭
 d.  VARKI 데이터를 바탕으로 가장 유사한 멘토 추천.
2. 멘토멘티 평가 기준 = 솜사탕 게이지, 당도
 - 활동 횟수와 평가 점수에 따라 솜사탕 아바타의 크기와 모양이 변화
3. 평가하기
 - '당도'라는 이름의 시각적 차트로 멘토멘티의 신뢰도와 성과를 한눈에 확인
 - 당근마켓의 '온도 평가'처럼 체크 박스로 사용자의 좋고 아쉬운 점을 체크
- 이후 당도 게이지에 반영

그리고 위 기능을 바탕으로 초안을 그려보면서 어떤 스타일로 개발할지 구상해 봤다.

 

와이어 프레임

우린 디자이너가 안 계셔서 그냥 내가 했다!
피그마 할 줄 모르신대서 내가 그냥 과로했다!~

카페인에 취약한데 매일매일 두잔 이상 마시면서 카페인 할당량을 초과했다..그래도 많이 배웠다! 프로토타입, 프레임, 섹션, 플러그인 사용법!

그리고 프론트엔드 개발이라는 게 내부 사정은 상관없이 기능만 개발하는 게 아니라 클라이언트 눈에 보이는 페이지를 개발하는 게 일이니까 내가 하는 거에 불만은 없었다
그렇기 때문에 프엔 파트원 분께 적극적으로 의견을 구했던 거 같다. 디자인 따로 프론트 개발 따로 하는 건 오히려 서로를 힘들게 하는 태도가 아닐까 싶었기 때문이다

그렇게 함께 초안부터 와이어 프레임 수정까지, 우리가 미처 생각하지 못한 페이지나 버튼이 있어야 한다는 걸 알게 됐다. 그리고 나중에 세부 디자인하면서 알게 된 거지만 피그마라는 디자인 툴에서는 상수처럼 자주 쓰이는 버튼이나 글자를** 프레임이나 컴포넌트를 통해 정해줄 수 있다는 걸 알았다.
한 번의 클릭으로 수정할 수 있었기 때문에 **유지보수에 굉장히 유용하다고 느꼈다. 물론 처음엔 이걸 몰라서 와이어 프레임 만드는 이틀 정도는 너무너무 힘들었지만... 이제 이런 기능이 있다는 걸 알았으니 이후부터는 테마에 있는 걸 마구 사용할 수 있다!

UIUX에 대해서 배운 적은 없어서.. 무한 검색과 자주 사용하는 앱들을 참고해서 와프를 정리했다

그리고 이후에 만들어진 세부 디자인
할 게 너무 많아서 세부 디자인 페이지를 좀 늦게 드렸는데 그래서 프엔 개발이 늦어졌다... 중간에 피그마 사용법을 알아서 다행이지 몰랐다면 절대 완성 못 했을 거 같다

 

나누기!

이 정도 만들어진 걸로 페이지 분류가 될 거 같아서 난이도별로 개발을 맡기로 했다
나눠진 페이지 분배는 실력에 따라 다르겠지만 우리 프론트 개발팀은 리액트 실력이 비슷했기 때문에

1. 하나의 페이지에 대해 각자 얼마나 어렵다고 생각하는지 1~5의 난이도를 붙였다. 이때 서로 영향을 받지 않기 위해 공개하지 않는다
2. 다 적었으면 공개하고 평균을 낸다
3. 반복
4. 각자가 맡는 페이지의 난이도의 총합이 비슷하도록 분배한다
5. 다만 나는 디자인까지 맡았기 때문에 23페이지 정도 적게 받았다 ㅎㅎ~~

페이지 난이도 설정

이런 식으로 난이도를 설정했고 나는 1~2(카카오톡 로그인 페이지), 3, 6, 7, 10페이지를 담당했고 그 이후에 추가되는 페이지는 다른 팀원분이 컴포넌트 이용해서 구현해 주시는 걸로 했다

공용 컴포넌트 나누기

페이지들에 쓰이는 버튼, 프로필 등이 재사용 돼서 컴포넌트로 나눴다
일단 컴포넌트도 페이지처럼 난이도를 설정해서 분배했다

근데 ... 결론부터 말하자면 우리 팀은 초기 기획 단계보다 많~은 기능을 덜어냈다
그 원인을 좀 적어 보자면 난 컴포넌트 단계의 문제라고 생각한다.
나는 로고, 굿즈와 포스터 제작 및 발주, 세부 디자인을 동시에 만들고 개발까지 하느라 매우 힘들었고 다른 팀원분은 내 속도에 맞추느라 개발이 다소 늦어졌다... 공용 컴포넌트가 많아서 한 사람이 다 하기엔 힘들었겠지만은 스프린트를 요구하는 해커톤에서는 한 팀원이 공용 컴포넌트를 맡고 다른 팀원이 페이지 개발을 하고 있었어야 한다고 생각한다🥲

이런 식으로 노션에 전체 공용 컴포넌트를 만들고 완료했으면 완료 탭으로 이동하게 했다. 나중에 알게됐지만 비슷한 툴로는 트렐로가 있다고 한다 🤔

본격적인 개발

첫 해커톤 개발이다 보니 2주도 안남은 시간 동안 얼마만큼의 개발을 할 수 있을지 몰랐다. 그래서 일단은 천천히 tailwind나 daisy에서 찾아보며 컴포넌트 개발부터 시작했다.

그렇게 4일 정도 컴포넌트 개발에 사용했고 남은 페이지는 아주 많았다 ㅎ.. 이때부터 나의 불안이 시작됐다...

그래도 페이지나 컴포넌트를 만드는 게 어렵진 않았다
잘 안되면 그냥 지피티 사용하면 되는 거니까!..근데 여기서 개발이 더뎌진 이유 두 번째. 우리는 효율적인 컴포넌트 설계를 몰랐고 일단 어떻게든 굴러가게 하자! 라는 마인드로 하다 보니 많은 사람들이 해커톤의 단점으로 꼽는 유지보수 불가라는 문제를 낳았다... 이런 것들을 전혀 생각하지 못하고 개발을 해서 설계가 매우 이상해졌다

navigate로 페이지 간 이동을 할 때, 버튼을 클릭할 때 모달을 띄웠는데 이때 state를 읽기 위해 props로 전달해 줬고 set 함수도 같이 전달해서 state를 관리했다.
즉 버튼을 컴포넌트로 만들어서 상태를 페이지로 전달하고 이 상태를 버튼한테도 전달하는데 이 과정에서 팀원분이 페이지 안의 페이지를 또 분리해 주셔서 메인페이지 - 하위페이지 - 버튼 이 모든 컴포넌트에 props를 적어줬다. 이 말은 모달을 사용할 때마다 모든 페이지, 모든 버튼에 이런 props drilling 과정을 써줘야 한다는 거다ㅋㅋㅋㅋ... 컴포넌트끼리 거치도록 결합을 해서 오히려 리액트로 비효율을 낳았다.

세 번째 아쉬운 점. 번들링 도구도 써주지 않고 오직 리액트로만 구현해서 시연할 때 모든 컴포넌트가 리렌더링 되면서 시간 지연이 있었다.. 왜그랬지..? 이런 것들을 전혀 생각하지 못하고 컴포넌트를 설계해서 나중엔 어떤 props가 어디 페이지에 연결되어 있는지도 어려워서 지피티에 질문하는 것도 애를 먹었다

구름톤 스터디 때 상태 관리 도구(Recoil이나 Redux)랑 번들링 도구(Vite)를 알게 되긴 했는데 .. 미리 공부해둘껄 ^^ㅜ 이미 개발은 시작됐고 시간도 얼마 안 남아서 조급했기 때문에 그냥 모든 페이지에 복잡한 props를 쓰며 연결했다

이때 현타가 정말 ...

axios 연결

백엔드와의 첫 연결! 어렵고 어렵고 어려웠다😂 일단 api가 덜 만들어져서 해커톤 전날까지 api 모킹만 하다가 해커톤 당일에 api 연결을 한 것도 네 번째 아쉬움이다.

프론트 팀원과는 디자인을 수정하고 계속 페이지를 같이 만들어갔기 때문에 따로 우리끼리 회의 진행을 많이 했다. 그러다 보니 우리들끼리는 어떤 앱인지 머릿속으로 그릴 수 있는 정도 였는데 백엔드 팀과는 아니었다. 우리가 생각한 앱과 백엔드가 생각한 앱은 달랐다. 그래서 만들어준 API들에는 필요없는 것도 있었고 필요한 게 없는 경우도 있었다.
중간 회의 때마다 보고 사항에 계속 완성되는 것들이 많길래 우리가 맞게 잘하는 줄 알았었다.

우리 서비스에는 kakao api를 이용한 카카오 로그인 기능이 있었는데 이 기능이 말썽이었다. 잘은 모르지만 수정 할때마다 로그인이 안 됐다. 우리는 로그인 이후에 정보를 읽어와서 화면에 보여줘야 했는데 시작부터 막히니 axios연결을 할 수조차 없었다.

일단 로그인은 주요 기능이 아니니 하드 코딩으로 인증 토큰을 매 페이지마다 설정했다. 그만큼 시연때 뭐라도 보여주고 싶은 마음이 간절했다...

다행히 요청 상태가 대부분 200, 302, 304 등으로 정상적으로 처리된 것처럼 보여서 시연 때는 잘 넘어갔다
그치만 액세스 토큰을 하드코딩 했다는 점 ...

나중에 알게 된 건데 모킹에는 MSW을 이용할 수 있다고 한다
msw 이용해서 혼자 api 연결 연습을 해봐야겠다

아무튼 이 이후는 우리가 해야하는 작업들만 남기 때문에 axios를 import해두고 서버와 연결만 되면 axios작업이 끝나게끔 코드를 적어뒀다. 근데 이것 조차도 어려웠다. axios연결을 다들 어색해해서 부딪히면서 해보려 했는데 잘 안됐다.

밤을 샜고 고치려고 노력했지만 결국 우리는 로그인을 구현하지 못했다.. 하나만 문제인 줄 알았는데 여기저기가 고장나있던 코드였다. 결국 axios도 연결하지 못한 채 인증 토큰을 다 지우고 깃허브에 올려서 마무리 했다.

결국 문제는...

우리는 결국 서비스를 완성시키지 못했는데, 결국 문제는
소통의 부재, 설계 구멍인 거 같다.

첫 번째 소통의 부재는 특히나 백엔드와 프론트 사이의 소통이다. 우리가 필요한 정보와 백엔드가 전달해주는 정보의 차이가 많았다. 어떤 기능에 대한 API를 줄거라고 예상했는데 다른 API를 주는 경우라던지..?!

그리고 이 서비스에 대해서 나는 머릿속에서 동작하는 정도로 잘 이해했는데, 이걸 피그마에 자세히 표현했어야 했다. 피그마 페이지를 보면 알겠지만 다른 서비스에 비해 페이지 수가 다소 적다 😅

프로토타입 연결도 매끄럽지 않고 내 머릿속에서만 동작하게 해서 필요한 API에 대해 팀간에 차이가 있던 것 같다. 다들 헷갈리는게 있으면 나에게 물어보고 내가 PM 마냥 대답해주는 식으로 설명했었는데 이걸 물어보지 않아도 피그마만 봐도 알 수 있게끔 했어야 했다. 비록 학교 + 개발 때문에 바쁘긴 했어도 나의 부족함을 많이 체감했다.. 피그마 툴 사용법에 대해서 더 이해하고 있어야겠다고 느꼈다

회의 조차도 모든 인원이 함께하는 것이 아니라, 백엔드는 백엔드 끼리 프론트는 프론트끼리만 진행했기 때문에 이런 일이 발생한 걸까 싶다
실제로 중간 보고 때 굿즈 제작 때문에 개발을 많이 못해서 개발 보고는 할 게 없는 상황에서 대충 그럴 듯한 말로 카톡에 써서 보낸 적이 있다..😂 기록으로만 읽으면 즉각적인 피드백도 어렵고, 읽기 귀찮아 하는 사람도 있어서 그런 것 같다

이렇게 나처럼 회피를 못하도록 다음부터는 무조건! 모든 회의에! 모든 팀원이! 함께하고 점검 시간에는 모든 사람에게 피드백을 받으면 나아질테지만 사실 다들 바쁘니 쉽지 않겠을 거 같긴 하다...

충분히 열심히 한 거 같아서 더 후회하고 싶진 않지만 굳이 이유를 생각해보자면? 사전에 효율적으로 해놨으면 어땠을까 라는 생각도 든다

또 API설계나 컴포넌트 설계를 처음 해봐서 생긴 문제라고 생각한다. 어떤 설계해야 할지를 고민하지 않고 무작정 만들었기 때문에 모든 코드의 유지보수가 어려웠고 효율을 위해 만든 컴포넌트지만 오히려 비효율을 낳는 부분이 너무 많았다. 재사용을 위해 만들었는데 해야할 것들이 너무 많았고 전달해야할 props도 마찬가지였다.

앞으로는?

근데 사실 이렇게 다같이 밤을 새서 개발도 해보고, 몇 개월동안 만들 것을 1주 만에 만드는 것도 처음이라 재밌었다!

좋은 결과는 아니었지만 팀 내 분위기도 좋았다! 난 사실 잠이 중요한 사람이라 밤새면 귀도 잘 안들리고 예민해지는데 다들 둥글둥글하게 말해주는 것도 다행이었다
앞으로는 밤새도 해커톤 마인드를 장착할 수 있는 사람이 되길...

후기

우리가 기획하려던 서비스가 다소 난이도가 높은 기능이 많았는데 이 기능을 구현하진 못했어도 어느정도 시도도 해봤던 것에 나도 만족한다

사실 나 혼자 이 서비스를 만들었다면 중도 포기 했을거다. 팀으로 함께하니까 서비스에 더 애정이 생기고 데모 부스를 위한 포스터랑 굿즈도 만들고! 시간이 더 있었다면 유지보수를 하고 더 기능을 추가하고 싶을 정도로 좋았다.

깨달은 점이 너무나도 많았고 나보다 개발 경험이 많은 팀원들과 함께해서 너무 다행히도, 크게 불안하거나 밤샘이 힘들지 않았다! 그리고 이번에 배운 것들로 다음에 경험할 팀프로젝트에서 적용해볼 것들이 생겼다는게 진심으로 행복했다!

아 그리고 우리 팀 발표 피피티랑 시연 및 발표는 내가 했는데 밤새고 너무 싱싱미역 상태라 첫 발표는 개망했지만.. 두 번째 발표는

진심

백 번정도 연습해서 잘한 거 같다. 다른 건 몰라도 난 발표에 구멍이 있으면 너무 후회스럽고 잠을 못잤는데, 백 번정도 연습하면 만족스럽게 할 수 있다는 걸 알았다. (광기)

멘토 님이 서비스 기획에 대한 피드백도 주셨는데 충분히 이해되는 말들이었다

멘토링 서비스는 항상 고민을 해야한다고 한다
"멘티는 넘치는데 멘토에 대한 보상은 어떻게 줄 것인가?" **
심지어 우리 서비스는 VARKI 차트를 이용해서 성향 검사를 통해 **좁은 멘토의 판을 한 번 더 걸렀기 때문에 실제 서비스로 시연하려면 이 부분을 계속 생각해보라고 하셨다

우리는 서비스를 더 개발하진 않을 거지만 앞으로의 기획에서는 이렇게 해야한다~는 점을 오래오래 알려주셔서 좋았다 칭찬도 많이 해주신 덕분에 본선 진출이라는 말도 안되는 꿈을 잠시 꿨다 😅

사실 개발 능력이 크게 발전했던 대회라기 보다는 나의 부족함을 깨달았고, 어떤 점을 노력해야하는지, 새로운 기술들을 열정적으로 알아볼 수 있는 시간이었다.
그리고 해커톤으로의 첫 발걸음을 내딘 대회라 맛보기로 아주 재밌었다!

첫 해커톤 회고 끝!!

데모 부스를 위한 굿즈!

서영언니랑 나랑 둘다 발표여서 발표 앞두고 서영 효환이랑 맘 불편하게 빨리빨리 찍은 사진..!! ㅎㅎ
그래도 찍길 너무 잘했다~ 🖤

암튼 다들 수고 많았다!!

다음 날 몸살 기운이 좀 있긴 했지만/,,

해커톤은 좀 쉬었다가! 기회가 되면 또 참여해봐야지 👍👍👍

회고 끝 ~ 🍀