멋쟁이사자처럼 해커톤
8월 6일부터 8월 7일까지 “IT 기술을 활용하여 현대인의 건강 (wellness) 문제를 해결할 수 있는 서비스를 개발하시오.”라는 주제로 양재 AT센터에서 멋쟁이사자처럼 대학 연합해커톤이 진행되었다.
1. 프로젝트 진행
팀빌딩 ~ 주제 선정
팀빌딩은 기획/디자인 없이 프론트 운영진 + 백엔드 운영진 + 백엔드 아기사자 3명으로 5명이서 팀을 이루게 되었다. 기획, 디자인 팀원이 없다보니 이끌어가야하는 역할을 해야했고, 처음 프론트를 혼자 진행해야하는 부분이 걱정이 되었다.
팀원들에게 주제 선정부터 배포까지 모든 과정을 직접 해보자라고 말했다. 아기사자들 입장에서는 프로젝트가 처음이고 공부가 덜 된 상태에서 프로젝트를 해야했기 때문에 난이도를 낮추고 완성하는 것을 목표로 하자고 의견을 냈다. 그래서 상대적으로 구현하기 쉬운 게시글을 쓰고 조회하는 커뮤니티 방식이 채택되었다.
주제를 선정하는 과정에서는 다양한 주제가 나왔다. 낮잠서비스, 웨어러블 기기를 통한 운동인식 서비스, 의약품 검색을 도와주는 서비스, 헬스 자세 피드백 서비스 등등이 나왔다. 처음 해커톤 주제가 나올 때는 "웹 및 웹앱"이라는 제한사항이 있었고, 난이도 측면에서 커뮤니티 방식인 헬스 자세 피드백 서비스로 정해졌다.
커뮤니티 특성상 모바일로 접근하는 유저가 더 많을 것으로 판단했고, iOS 개발자를 희망하는 나로써 웹앱을 경험해보고 싶었기 때문에 웹앱으로 진행하면 어떻겠냐는 의견을 냈었다. 팀원들도 동의해서 "헬스 자세 피드백 서비스 - 웹앱"으로 주제가 정해졌다.
화면설계서, 기능명세서, api명세서, erd
시간이 없었기 때문에 백엔드 팀원 일부가 기능명세서와 erd를 작성해주면, 나머지 인원 + 내가 주도가 되어서 화면설계서를 피그마를 통해 작성했다. 웹앱이었기 때문에 무신사와 야놀자를 레퍼런스 잡아서 디자인을 진행했다.
개발 및 배포
협업은 notion, discord를 통해 진행했고, 프론트엔드 기술 스택은 React.js, tailwind를 주로 사용해서 진행했다. 배포는 vercel을 통해 진행했다.
2. 후기
항상 2명 ~ 3명 정도의 프론트엔드 팀원들과 협업을 진행했었다. 기술스택 선정부터 개발환경 세팅까지 해주는 팀원이 있었기 때문에 수동적인 입장에서 프로젝트를 진행했었다.
이번 프로젝트는 오로지 내가 처음부터 끝까지 맡아서 해야했다. api가 나왔는데 프론트엔드 개발이 완성되지 못하는 최악의 상황이 부담을 가지게 했다. 하지만 지금까지 진행했던 프로젝트들이 어떻게 진행되었는지 되돌아보며 개발환경 세팅, 라우팅, 컴포넌트 나누기, 전역 상태관리를 어떻게 해야할 지 등등 차근차근 개발을 진행하다보니 부담감은 자신감으로 바뀌게 되었고, 머리 속에서 다음에는 어떻게 진행해야할 지가 정리가 되었다.
백엔드에 프로젝트 경험이 적은 아기사자들이 있어서 api가 나오는데 조금 오래 걸렸다. 그래서 api가 나오기 전에 더미 데이터를 넣어놓고 ui를 완성시키고 나서, api가 나오면 수정하는 방향으로 개발을 진행했다.
vercel을 통해 배포하는 과정도 진행을 해보았다. vercel 회원가입을 진행하고, organization repository에 연결을 하게 되면 금액이 발생하기 때문에 fork한 repository와 연결해서 배포를 진행했다.
처음 vercel을 사용해보았는데 놀라울 정도로 편하게 배포가 가능했다. 환경변수부터, 도메인을 구매해서 변경하는 기능까지 쉽게 할 수 있었다.
❗️수많은 어려움들
혼자 프로젝트를 진행하다보니 어려운 일들이 참 많았다. 물어볼 선배도, 동료도 없이 혼자 구글링, gpt에게 물어보며 진행을 해야했다,,🥲
- 전역상태 관리에 대한 어려움
유저정보, 유저인증에 필요한 로그인할 때 받은 accessToken을 전역에서 사용하게 하는 부분이 어려웠다. 처음에는 props로 계속 전달해서 사용했는데, propsDrilling 같은 문제나 같은 코드의 반복이 느껴져서, 나중에는 AuthContext라는 컴포넌트를 빼서 import해서 사용하게 했다.
전역상태관리 라이브러리를 사용해도 되었는데, 처음에는 그냥 해보고 싶어서 라이브러리 사용없이 했는데 너무 까다롭고 복잡해졌다. 다음 프로젝트에는 zustand를 사용해볼 예정이다.
- api 연결할 때의 오류
개발과정에서 가장 많은 시간을 소비한 부분이다. 특히 오류가 많이 발생한 부분은 api연결을 해서 요청을 보내거나 응답을 받을 때, 속성 이름이 다르거나 headers의 Authorization을 추가 안했을 때였다.
이번 프로젝트에서 뼈저리게 느낀 부분이 프론트 개발을 진행할 때 erd를 참고하거나, 백엔드 팀원들과 소통을 하며 속성 이름, 변수명을 정해야한다는 걸 알았다.
- CORS 오류
사진을 보면 CORS 정책에 의해 요청이 차단된 것을 볼 수 있다. 이는 브라우저 보안 메커니즘으로, 다른 도메인 간의 요청을 제한하여 악의적인 스크립트가 외부 리소스에 접근하는 것을 방지하는 역할을 한다. api서버로 접속 자체가 차단되어 network 오류도 발생했다.
백엔드 팀원에게 localhost:5172 혹은 배포를 한 주소의 CORS 정책을 허용해달라고 요청해서 오류가 해결되었다.
- 카카오 로그인 구현할 때의 어려움
회원가입을 따로 두지 않고 카카오 소셜로그인을 프로젝트에 도입했다. 이번에도 카카오 소셜로그인을 처음 해보았다. 초반에 카카오 소셜 로그인의 로직을 이해하는데 오래 걸려서 구현과정도 오래걸렸다.
내가 이해한 카카오 소셜로그인의 흐름을 간략하게 정리하면
- 카카오 개발자 콘솔에 애플리케이션 등록을 해서 REST API 키와 리다이렉트 URI를 설정한다.
- 사용자가 카카오 로그인을 클릭하면, 카카오 인증 서버에 요청이 전송된다. 요청에는 client_id(앱키)와 redirect_uri(카카오 인증 후 리다이렉트될 url)이 포함된다.
- 사용자 인증이 성공하면, 설정한 redirect_uri로 인증 코드가 전달되고 이 코드를 서버로 보내 엑세스 토큰을 발급받는다.
- 엑세스 토큰을 사용해서 카카오 api에 사용자 정보를 가져와 반환을 해주면 프론트에서 이 정보를 사용한다.
로컬에서 해결하고 배포를 했었는데 그때도 오류가 발생했었다. 그때 오류가 발생했던 이유는 백엔드 서버가 http로 배포했는데 카카오는 보안상 이유로 https가 아닌 도메인에서는 로그인을 제한했기 때문이었다.
카카오 로그인을 구현할 때 만났던 오류들 중 하나인데, 애플리케이션 설정에서 리다이렉트 URI가 잘못되었을 때 발생했던 오류이다. 이와같이 오류를 만났을 때 리다이렉트 URI, client_id, https 배포 등을 수정하며 카카오 로그인을 구현했다.
- 배포, 오류 수정의 반복
어려웠던 부분이라기 보다는 프로젝트 진행을 하며 피할 수 없는 부분인 것 같다. 완성 후 배포를 하면, 로컬에서 되었던 기능들이 오류를 발생시키곤 했다.
가령 .env파일에 서버주소, 카카오 소셜로그인에 필요한 경로등을 저장해서 사용했었는데, Vercel에 배포할 때는 해당 변수를 환경 설정에 따로 추가하지 않으면 배포된 앱에서 찾을 수 없었다.
🌱 마지막으로
전체적으로 성장한 나를 발견할 수 있었다. 프로젝트가 끝나고 난 후에 나도 혼자 개발을 할 수 있게 되었구나, 1년 전까지만 해도 울면서 토스 로그인화면 클론코딩을 진행하고, div박스를 여러 개 만들어 css를 입히는 것도 힘들어 하던 내가 혼자 개발을 해냈다는 뿌듯함이 밀려왔던 경험이었다.
하지만 이번 프로젝트에서 부족 했었던 전역상태 관리하는 부분, 배포과정이 매끄럽지 않았던 부분은 다음 프로젝트에서 개선을 해야겠다고 다짐했다.
그리고 팀원들이 없었다면 프로젝트를 완성할 수 없을 것 같았다. 특히 해커톤 당일까지 카카오 로그인 오류가 발생하고, cors오류, api 연결이 안되는 문제들이 있었는데 끝까지 해보자는 팀원들이 있어서 너무 힘이 되었다.
