겨울에 와플스튜디오에서 23.5기 루키로 토이프로젝트를 진행한 이후,
토이 프로젝트 팀원들 일부와 함께 다시 동아리에서 진행하는 해커톤인 와커톤 에 팀장/PM, UI/UX 디자인, 프론트엔드 개발 역할로 참여하게 되었다.
타임라인
- 팀빌딩 : ~2/15 (일)
- 주제 사전 발표 : 2/19 (목)
- 해커톤 당일 : 2/21 (토) 오후 3시 ~ 2/22 (일)
(실제 개발 진행 : 2/21(토) 오후 4시 ~ 2/22 오전 8시)
주제
오프라인에서 완성되는 경험
프로덕트 소개
오고있니 AreUComing
"기다림의 시간까지도 설렘으로"
- '위치 추적'이 아닌 상호 '위치 공유'로, 연인을 만나러 가는 경로를 실시간으로 시각화 🗺️
- 만나러 가는 길까지도 하나의 콘텐츠가 될 수 있게 💗
- 쌓인 만남의 기록들은 연인만의 새로운 이야기 ✍️
오프라인을 대체하지 않는, 오프라인에서의 만남을 오히려 촉진하는 서비스!
로그인 / 회원가입 / 파트너 연결 흐름
서비스를 이용하기 위해서는 로그인 및 회원가입이 필요하며,
회원가입 직후에는 자신이 초대 코드를 만들어 상대방에게 전달하거나,
상대방이 만든 초대 코드를 수락하는 식으로 파트너 연결을 하게 된다.
홈 화면
파트너 연결 이후에는 '위치 공유 시작' 버튼을 눌러 나의 위치 공유를 먼저 시작할 수 있다.
한 명이 위치 공유를 시작하면 타인에게 그 푸시 알람이 도착하여, 상호 위치 공유를 할지 말지 선택할 수 있다.
(*푸시 알람 기능은 FCM-Firebase Cloud Messaging을 이용했으며 안드로이드에 PWA 형식으로 웹을 설치했을때, 그리고 데스크탑에서 작용하는 것 확인)
위치 공유
홈의 '위치 공유' 버튼을 누르면 websocket 연결이 확립되고, '실시간 위치 보기'를 클릭해서 지도가 있는 위치 공유 페이지로 이동하면 그때부터 websocket 기반 실시간 위치 공유를 시작한다.
(여담으로 지도를 확대해 보면, 해커톤의 장소인 '성수 엘리스랩' 근방에서 팀원들이 열심히 뛰어다녔다는 것을 확인할 수 있다 😅)
'만남 기록' 버튼을 누르면 두 사람의 만남이 성사된 것으로 간주되어, 내가 이동한 거리 + 상대방이 이동한 거리를 합산한 '만남 이동 거리'와 만날때까지 걸린 시간이 계산 및 기록된다.
이 데이터는 '만남 회고' 탭에서 연인 간의 하나의 이야기 겸 콘텐츠처럼 향유할 수 있다.
만남 회고
- 스토리 탭 : 각각의 만남의 평균 시간과 평균 거리를 계산해서 대시보드 형태로 보여주며,
이번 달에 몇 번 만났는지 / 만남까지 총 걸린 시간과 이동 거리, 그리고 만남까지 걸린 최단 시간을 이야기 형태로 보여준다. - 목록 탭 : 모든 만남 목록을 피드 형식으로 보여준다.
- 지도 탭 : (지도 부분은 작동하는 것을 스크린샷 찍지 못해서, 아래에 피그마 스크린샷을 첨부했다.) 실제로는 시간 부족 이슈로, 모든 만남을 오버레이해서 하나의 지도로 보여주는 것까지만 구현했다.
KPT (Keep, Problem, Try)
Keep
사전 준비 워크플로우
약 이틀 간의 준비 시간을 알차게 활용할 수 있기 위해서는, 행사 이전 무엇을 어디까지 준비할 것인지에 대한 고민과 이에 따른 투두 정리가 필요할 것이라 생각했다. 따라서 다음과 같은 사전 준비 타임라인 설계를 했다.
첫 회의 :
- 회의 이전에 아이디에이션 및 아이디어 투표를 피그마의 FigJam을 이용해 미리 진행.
- 회의 때 아이디어 바탕으로 세부 기획서 작성.
두 번째 회의 :
- 회의 이전에 기획서를 바탕으로 UI 스케치 및 DB 스키마/엔드포인트 목록 작성
- 두 번째 회의 때 서로 피드백 및 수정사항 반영 + 업무분배
각 업무 간의 의존성을 고려한 효율적인 흐름이었기 때문에 만족한다.
styled-components의 도입
지금까지 계속 CSS Modules를 사용하다가,
CSS 파일을 페이지별로 적용할 시간이 없을 것 같아서 · 반복되는 컴포넌트 스타일이 대부분이고, 페이지 레이아웃의 경우도 반복되는 경우가 많다고 여겨서 처음으로 styled-components를 사용해 보았다.
예상대로 초기 세팅 시간을 들이고 나니 빠르게 UI를 구현할 수 있어서, 효과적인 프레임워크 세팅이라고 느꼈다.
작은 규모의 서비스에 맞는 깔끔한 파일 구조
이 블로그 링크 를 참고해서, 중급 정도의 파일 구조를 적용했다.
- pages 폴더 : 안에 페이지 컴포넌트, 그리고 해당 페이지에만 사용되는 파일들 (컴포넌트 / 훅)을 넣음
- components 폴더 : 여러 페이지에 걸쳐 사용할 수 있는 컴포넌트들의 경우 여기에 넣음
- hooks : 컴포넌트 폴더와 마찬가지로, 여러 페이지에 걸쳐서 사용되는 전역 hook를 저장할 수 있음
- assets : 전역 css 스타일 /폰트 파일 / 사진들
- context : 전역 변수 관련 파일들
- data : 프로그램에서 사용되는 정보(전역 constant, 테마 정보 등)
- utils : 여러 페이지에 걸쳐 사용되는 포맷팅 함수 등의 함수 파일들
초기 설정에도 간편했고 address alias 설정과 함께 이용하니 파일 경로를 바꾸어도 import를 바꾸는 등의 문제가 없어서, 다음에도 프로젝트 규모가 너무 크지 않은 경우 이런 파일 구조를 차용할 예정이다.
서비스의 완성도
서비스의 및 유저 페르소나가 명확하고 스토리텔링이 구체적이라고 느꼈다.
또한 서비스 이용 시나리오에 따른 UX 흐름이 유기적이라고 느껴서, 기능 구현 정도를 포함하여 서비스의 전반적인 완성도가 높아 만족스러웠다.
Problem / Try:
- 기능 선택과 집중이 부족했다.
해커톤이 처음이라서 그런지 약 16시간 미만 동안 얼마나 개발할 수 있는지 감이 잘 오지 않았다. 또한 프로젝트 완성도를 추구하며 해커톤이 끝나갈 무렵 사소한 포인트 디버깅을 하느라 발표자료를 늦게 제출하게 된 탓에 (...) 프로덕트 완성도 및 기획력에 비해 등수가 낮아졌을 수도 있겠다고 생각했다.
➡ '하면 된다'는 마인드보단, 현실적으로 개발 기간동안 할 수 있는 것들을 evaluate하고, 완벽한 프로덕트가 아닌 MVP를 만든다는 생각을 더 가지는 것이 필요하다. 핵심적인 기능들을 선정하고 그것을 잘 showcasing하는 것이 중요하다.
-
프로젝트와 관련해서 혼자 고민해보고, 고민 결과로 도출된 진행 방향이나 계획을 팀원들에게 공유하고 의견을 구하는 진행 방식은 익숙한 것 같다. 그러나 0에서 1을 만들기 위해 팀원들과 논의가 필요한 경우, 논의에 더 효과적으로 참여할 수 있게 하기 위한 소통 방식 i.e, human querying / prompting이 아직 덜 익숙한 것 같다. 이후 프로젝트등을 진행할때 이를 염두에 두어야겠다고 느꼈다.
-
PM뿐만이 아니라 다른 역할들도 맡았기 때문에, 특히 해커톤 진행 중은 프론트 개발 업무가 과중했기 때문에 각각의 팀원들의 프로젝트 진행 상황에 대해서 신경 쓰지 못했다. 그 과정에서 백엔드 개발자 분께서 본인의 업무 분담이 끝나서 프론트 쪽을 하고 있으셨는데, 그 부분이 프론트 개발자들에게 잘 전달되지 않는 등 더 효율적일 수 있던 부분이 아쉽게 느껴진다.
➡ 앞으로 여러 역할을 PM과 함께 병행해야 하는 상황이라면, 프로젝트 매니징 업무에 집중할 수 있도록 다른 역할들의 업무 부담을 조절하는 것이 필요하다.
➡ 프로젝트의 전체적인 흐름을 알지 못하면 비효율이 발생할 가능성이 높다. 효율적 진행을 위해 팀원 간 소통을 연결해주기 위해서는, 프로젝트가 전체적으로 어떻게 되어가는지 아는 것이 중요하다.
UI/UX 디자인
피그마로 UI 디자인을 처음 시도해보았다.
툴을 써본 적은 있지만, 피그마에 UI 스케치를 시도해보며 툴을 사용한 것은 처음이었기 때문에 사전 준비 과정에서 plugin, assets 사용, flexbox처럼 frame 사용하기 등 피그마 자체 사용법을 더 잘 알게 되었다.
Figma Make 이용:
디자인 경험이 있으신 다른 프론트엔드 담당 분께서 알려주신 덕에, Figma Make에 프로젝트에 대한 설명이 포함된 프롬프트를 넣으면 디자인과 함께 코드까지 통합적으로 나온다는 것을 알게 되었다.
UI를 고민하고 레퍼런스를 찾아볼 시간이 사실 충분하지 않았기 때문에, 최대한의 효율으로 UI 디자인을 내기 위해, Figma Make에서 나온 AI의 UI를 다른 Figma 파일에 복사 & 붙여넣기하여 AI스럽거나 어색한 부분을 수정하는 식으로 진행했다.
이 과정에서 AI가 한 디자인을 그대로 쓸 경우, gradient 사용이나 과도한 그림자, 투박한 색상 선정과 'boxes in boxes' 등의 요소들이 'AI스러움'을 자아내어 서비스의 질을 더 떨어져보이게 한다고 느꼈다.
AI 시대에서 프로덕트가 양산형이 되지 않을 수 있는 방법은, UI 디자인과 UX 라이팅에 고민을 들이는 것, 그럼으로써 authencity를 챙기는 방법이라고 생각한다.
로고 또한 gemini에 프롬프트를 넣어 나온 초안을 참고하여 직접 피그마로 만드는 방식으로 만들었다.
- ai 생성 로고 :
- 수정 후의 로고 :
ui와 로고들을 그려본 이후 디자인 전공을 하고 있는 팀원에게 검수를 받아서 완성도를 높였다.
사용 디자인 워크플로우 정리
- 기획서 작성 이후, Figma Make로 디자인 생성 - 레퍼런스로 활용
- 서비스 의도와 비슷한 UI 레퍼런스를 찾아보기
- 서비스의 컨셉이 무엇일지 고민하면서 primary color등 컨셉 포인트들을 잡기
- 1, 2, 3을 바탕으로 최종 UI를 만들기
