2024년 12월 15일 진행하는 9roomthon Deep Dive 해커톤에 참가하였고, 같은 팀원과의 회고가 끝난 시점에서 후기를 남겨두어야 방향성을 잊지 않을 것 같아 기록을 남기게 되었다.
참가 전 나의 실력
참가 당시 프로젝트는 ReactJS와 ExpressJS로 "오늘"이라는 게시판 성격의 소셜 네트워크/다이어리 모바일 웹을 개발하여 1번 프로젝트를 진행했었고, 이론으로는 ReactJS, Typescript까지 배운 상태였다.
주제 선정
이번 해커톤의 주제는 "하이퍼 로컬"로 작은 지역 내 사람을 대상 고객으로 삼은 서비스, 소지역 안에 있는 공동체나 커뮤니티를 대상으로 한 서비스를 말한다. 팀원이 각자 '하이퍼 로컬'에 맞는 주제 후보들을 몇가지 가져와 선정하였고, 우리의 주제는 소음 데이터를 수집하고 사용자에게 시각적으로 제공하는 지도 기반 플랫폼을 개발하는 것이 주요 컨텐츠였다.
각자가 이 주제에 선호한 이유는 다르겠지만, 개인적으로 "하이퍼 로컬"이라는 주제에 부합되면서 동시에 이전에 진행하였던 프로젝트 혹은 연습했던 코드들을 비추어봤을 때, 텍스트 관련 데이터들을 주로 다뤄봤지만, 음성을 입력값으로 받은 적이 없었기에 흥미가 있었다. 또한 이 주제를 통해 한층 더 성장할 수 있는 기회로 보았다.
프로젝트 준비 과정
팀으로서의 준비
기획 단계에서 주제로서 적합한 주제인지 근거 자료를 찾았고, 약 55명의 설문조사를 통해 주제의 신뢰성을 더했다. 또한 어떻게 해결할 것인지에 대한 방안을 찾고 신규 유저들을 어떻게 끌어올 것인지 등을 논의했다. 개발자로써는 각 와이어프레임 화면 상 데이터들이 어떻게 흘러 갈 것인지 데이터의 흐름과 데이터의 구조, 데이터들의 관계를 설정하는 데 주력을 다했다.
이전에 진행하였던 프로젝트에서의 인원들은 모두 Javascript로 풀스택을 지향했던 구성원이었기에 자체적으로 문제를 해결하는 과정이 많았고, 또 그 구성원의 주력은 프론트엔드였다. 때문에 이렇게 해커톤을 준비하면서 각자의 전문분야가 있는 구성원과의 프로젝트 진행은 처음이었기에 처음 듣는 용어, 혹은 상황들이 많았다.
용어 정리
IA(Information Architecture) 구조
IA 구조는 서비스의 전체 그림과 흐름을 결정하는 컨텐츠 구조도이다.
정보구조는 눈에 보이지 않지만, 사용자에게 언제 어떠한 방식으로 정보를 제공할지를 결정하기 때문에 와이어 프레임 단계에서 꼭 짚고 넘어가야 한다.
따라서 정보구조를 설계할 때는 사용자가 쉽게 이용할 수 있도록
서비스에 맞는 정보구조를 적용하는 것이 중요
참조자료 - 요즘IT
컴포넌트 아이콘 네이밍 규칙
디자인팀과 협업하는 경우 외부 인원들도 쉽게 이해할 수 있도록 아이콘의 파일명을 동일하게 사용.
ERD Cloud
처음으로 백엔드와 협업하면서 알게된 데이터 schema 작성 tool이다.
ERD Cloud란 온라인에서 ERD(Entity-Relationship-Diagram)을 쉽게 작성하고 관리할 수 있는 데이터베이스 설계도구이다.
Vercel
Vercel은 개발자들이 프론트엔드 애플리케이션을 빠르고 쉽게 배포할 수 있도록 도와주는 플랫폼으로, CI/CD 파이프라인을 지원하며 GitHub과의 연동도 간편합니다.
Ngrok
인터넷으로 터널을 만들어 로컬 개발 환경의 포트를 개방하고 애플리케이션의 외부 접근을 도와준다.
개인으로서의 준비
팀의 디자인 역할을 맡으신 분의 와이어 프레임을 보고 약 5일간 준비해야 할 로직을 빠르게 정리하였고, 핵심은 소리의 입력값을 받는 방법이었다. 당장에 생각나는 메소드들이 없었기 때문에 그러한 라이브러리가 있는지를 검색하였지만 소리의 입력을 받는 라이브러리는 내가 검색하였을 때는 존재하지 않았다. 검색 키워드를 달리 해보고, ChatGPT를 활용하여 Web API 중 MediaDevice의 AudioContext라는 메소드가 있었고 이를 활용하여 음성을 입력값으로 받도록 설정하여야만 했다.
이번 프로젝트 자체가 와이어 프레임상 상당히 API 의존적이었다. 음성을 받기 위해 Web Audio API를 사용하였고, 이 소음을 지도에 시각화하기 위해서는 카카오맵의 Open API를 사용해야 했으며, 유저가 현재 장소의 소음 정보를 등록하기 위해서 현재 위치를 불러올 수 있도록 Web API 중 Geolocation을 사용해야만 했다.
따라서 남은 5일간 카카오맵 API, Web Audio API, Geolocation을 가지고 공식문서를 보고 최대한 파악하는 시간을 가졌다.(핵심 로직을 구상해 와서 베끼지 말라는 것이 대회의 규정이었다.)
프로젝트 진행
팀 구성원이 기획자 1명, 디자이너 1명, 프론트 1명, 백엔드 2명이었고, 그 중 나의 역할은 프론트엔드였으며, 이 프로젝트 특성상 화면에서 처리해야 할 로직이 많았기 때문에 상당히 부담감을 가진 상태에서 진행되었다.
이 상황 속에서 나에게 주어진 18시간 30분을 최대한 활용해야 했지만, 체감상 5~6시간을 소음 측정 로직 구현에 할애하였다. 아직 Styled-component로 스타일링도 주지 못했고, 실전에 처음 쓰는 bundler인 vite와 typescript였기에 기초적인 type 설정 오류가 자주 발생하였다.
이에 따라 디자이너분이 열심히 만들어주셨지만 모든 것을 제한시간에 구현할 수 없겠다는 판단이 들었고, 이러한 판단이 틀린 것은 아닌지 대회에 주어진 2번의 멘토링 시간(1회당 20분) 중 1번을 소모하여 다시 한 번 확인을 거쳤다. 멘토링을 통해 머릿속으로 빠르게 MVP(Minimum vial Product)로 완성시키기 위한 핵심 로직만을 선별하여 정리하였다. 그리고 이를 팀원과 공유하여 빠르게 결정하였다.
결과는...
최우수팀으로 선정되었다!!
기획의 참신함과 그를 뒷받침한 기능 구현을 인정받았다.
다만 개선점도 분명한 것이 음성 측정의 정밀도가 떨어졌고, Web audio api의 MediaDevice의 audio를 true로 해서 각 기기의 마이크를 통해 소음을 측정하는 것이기에 하드웨어의 마이크 성능에 따라 차이가 발생될 수 있었다. 따라서 하드웨어의 연동이 이루어지면 좋겠다는 평가를 받았다.
그 이후
상대적으로 아이디어에 대해 좋은 평가를 받았기 때문에 팀 회고 시간에 이를 바탕으로 어플리케이션 출시까지 준비하자는 의견에 대부분 동의하였고, 나는 어제부터 화면단 영역을 하나씩 개선해나가고 있다. 어제는 소음 기준을 알려주는 모달창의 디자인이 figma와 달라서 이 부분을 figma의 수치대로 수정하였고, 유지보수성을 위해 CSS 파일과 UI 컴포넌트 파일을 분리하였다.
마지막으로 KPT를 활용한 회고를 정리하면서 글을 마치겠다.
회고 정리
팀
Keep(K)
-
각자가 맡은 R&R에 대한 전문성이 뛰어나다 생각하며,
진행과정이 체계적이라 생각됨.
이에 따라 명확한 목표 하에 문제 해결이 이루어진다 판단됨 -
중간중간 변경사항 및 문제를 실시간으로 공유함으로써 혼동이 잘 발생되지 않음
-
개인 작업이 끝나도 서로가 안되는 부분이 있다면 도움을 주려고 하는 자세
Problem(Bad)
- 팀적으로 부족하다고 느낀 부분보다는
Web Audio API에 대한 개인 지식 부족으로 인한 문제 상황이
더 많이 발생됐다고 생각됨. - 노트북의 Alt키 고장으로 인한 figma의 요소간 위치 파악 늦어짐
(화상키보드로 대체)
=> 팀의 문제보다는 각자가 개인 문제로 받아들이는 부분이 커서, 개인에 대한 회고 정리로 넘어감
개인
Keep(K)
계속 이어갔으면 하는 부분
-
어떻게든 프로젝트 목표에 맞는 핵심로직(Audio API, Geolocation 등)을
찾아냈다는 것 -
빠르게 핵심 로직을 파악하여 실시간으로 화면 수정
Problem(Bad)
개선이 필요하다고 생각되는 부분
-
음성 측정 정밀도를 높일 수 있는 지식 부족
-
처음 각 전문성이 있는 분들과 작업을 진행하니 모르는 용어가 많았음
(IA 구조, ERD Cloud tool 사용, 컴포넌트 기반 아이콘 네이밍 등) -
화면단 구성에 있어 부가적인 스플래쉬, 로딩, 라우팅 처리 등등에 대한 지식 부족
Try(T)
problem 의 해결책
당장 실행 가능한 것
- 인프런 및 Udemy에 관련 강좌가 없어
시중에 판매되고 있는 web api 관련 서적(Working with the Web Audio API) 구매 예정
- 화면단 기능에 대한 부분은 하루에 한가지 목표를 두고 개선중
