2025 블레이버스 MVP 해커톤 후기 (feat. 챌린저상)

https://event-us.kr/blaybus/event/97293

2025 블레이버스 MVP 개발 해커톤 - 이벤터스

 

같은 동아리 친구에게 같이 하자고 권유받았는데 백엔드 직군 마감이라서 아쉽다고 생각하던 와중 알고보니 사전 팀을 짜서 참여하는 건 괜찮다고 해서 지원 마감일에 동아리 사람 4명이서 함께 나가게 되었다.

 

2월 9일 해커톤 OT 및 팀 빌딩, 2월 10일 ~ 2월 19일 개발 진행, 2월 20일 파이널데이로 진행되었다.

 

 

해커톤 OT (2/9)

이 해커톤은 초기 창업팀의 사업 아이디어를 기반으로 기획자가 아이디어를 더 발전시켜서 실제 동작하는 작은 MVP를 만드는 대회이다.

해커톤 OT 에는 이 해커톤을 주최한 블레이버스 서비스의 사용방법과 MVP 아이디어 2가지를 소개했다.

해커톤 참여자는 2가지 아이디어 중 하나를 선택해 서비스를 만들면 된다.

 

공개된 아이디어 2가지는 다음과 같았다.

 

1. 요양보호사와 사회복지기관 매칭 서비스

2. 헤어디자이너와 고객 간 화상 면담 플랫폼 (?)

 

OT에서는 큰 개요를 설명하고, 디테일한 요구사항은 아이디어 선택 이후에 정보를 제공해줬다.

우리 팀은 2대2로 의견이 갈렸지만, 2번이 상대적으로 쉽다보니 사람들이 몰릴 것 같다고 해서 1번으로 선택하게 되었다.

 

1번 아이디어는 큰 개요를 보면 사회복지사와 요양보호사간 매칭 시간도 길고, 매칭률도 높지 않아 불편한 문제를 해결하기 위한 아이디어로

 

복지기관에서 요양보호사 중 조건에 맞는 요양보호사에게 매칭 요청

→ 요양보호사의 매칭 승인

→ 매칭 승인한 요양보호사 중 최종 선택

→ 근무 조건 협의

→ 계약 체결

 

이라는 플로우로 매칭하는 과정이 기본 MVP 아이디어였다.

아이디어를 선택할 땐 이 정도일 줄은 몰랐지만.. MVP부터 단계가 복잡해서 기획하시는 분도, 개발하는 우리도 너무 힘들었다.

 

팀 빌딩은 해커톤 주최측에서 자동으로 해주었고, 기획자를 기본 팀장으로해서 팀원연락처를 공유하는 방식으로 진행되었다.

우리 팀은 최종적으로 기획자 1명, 디자이너 2명, 개발자 4명의 7인 팀으로 꾸려지게 되었다.

 

 

기획 & 디자인 (2/9 ~ 2/11)

일요일 저녁 첫 회의 이후 해커톤 종료때까지 매일 오후 7시반에 모여서 정기회의를 하기로 했다.

첫 정기회의 때 일정이 있어서 백엔트 팀원이 참석을 못했다.

그런데 기획자 분이 탈주를 걱정하셔서 최악의 경우 혼자해도 괜찮냐고 물어보셨는데, 프로젝트 첫 날에 바로 팀으로 왔다고 말해도 괜찮을까 싶어서 팀원이 올거라고 믿는다고 말했다 ㅋㅋㅋ

 

결국 해커톤 중간에 말씀드리긴 했는데, 나중에 들은 얘기지만 디자이너 한 분은 이 분 순진하시구나 생각하셨다고 하고, 기획자 분은 정기회의 때 개발 진행상황 물어볼 때마다 벌써 각자 팀원들끼리 이미 얘기가 다 되어있다고 해서 벌써 서로 연락을 다했다고..? 싶으셨던 적도 많으셨다고 ㅋㅋㅋ

 

 

2월 11일까지는 피그마에서 기획과 디자인 작업을 진행했다.

기획 과정에서 궁금한 점을 정기 회의때 의논했는데, 이 기간 동안의 주요 의논점은 복지기관과 요양보호사의 매칭 과정이었다.

복지기관에서 먼저 제안을 하고 → 요양보호사가 제안을 수락하고 → 다시 수락한 요양보호사 대상으로 복지기관에서 선택한다는 플로우를 그대로 따라가려다보니 너무 번거롭게 느껴졌다.

 

그래서 최종 플로우는 복지기관의 제안은 조건에 맞는 모든 요양보호사에게 자동으로 선 제안을 하는 방식으로 하고, 이후에는 마치 알바 채용하듯이 요양보호사가 자신에게 들어온 제안을 보고 지원서를 넣으면 기관에서 승인하는 구조로 기획이 나왔다.

 

디자인은 이 때까지 요양보호사가 먼저 나오고, 이후에는 수~목요일 쯤에 걸쳐서 요양기관 관리자 화면과 기획이 나왔다.

 

 

최종 디자인은 이렇게 나왔다.

기획자 분도 물론 알고 계시긴 했지만.. 사실 개발 기간과 개발자 수에 비해 화면 수가 정말 많았다.

특히 회원가입할 때 입력해야 하는 정보가 많아서 프론트가 정말 고생했던 걸로 기억한다..

(맨 위에 한 줄이 다 회원가입 화면 플로우다..)

 

확정 디자인이 얼추 2월 10 ~ 11일 쯤에 나오기 시작했고 데모데이날을 제외하고 19일까지 개발이 완료되어야 했다보니 해커톤 막바지 들어서는 월화수목은 정말 밤을 새면서 5시 취침을 기본으로 코딩했다.

수요일~목요일 넘어가는 날은 2시간 자고 코딩했고..

엄마는 나중에 취업해서도 그렇게 일해야 할 거 같다고 개발자 하지 말라고 하셨다..ㅋㅋ

 

디자이너 두 분은 모두 직장 / 인턴을 다니시는 와중에 빠르게 디자인을 뽑아주셔야 했기 때문에 어떤 분은 연차까지 쓰시면서 밤새 열심히 만들어주셨다.

 

 

개발 (2/9 ~ 2/20)

개발환경 세팅

디자인 마무리는 2월 16일 쯤에 확정적으로 마무리 되었고, 그 이후로는 개발 중에 나온 피드백을 기반으로 사소한 수정만 이루어졌다.

개발 기간동안 디자이너와 기획자는 발표자료 제작, 데모데이 전시에 필요한 자료를 제작하셨다.

 

백엔드 팀원은 졸업 프로젝트 때문에 조금 합류를 늦게 해서 그 동안은 내가 인프라 구축과 프로젝트 세팅을 담당했다.

우선 디자인이 나오기 전에는 개발을 시작할 수가 없었기 때문에 2월 11일에는 AWS 계정을 만들고 CI/CD 를 구축했다.

다행히 큰소리 프로젝트를 하면서 전체 세팅을 다 해본지 얼마 안 되었다보니 금방할 수 있었다.

 

팀원이 깔끔하게 그려준 구성도

 

큰 아키텍처 구조는 위와 같다.

프론트가 버셀을 사용해서 배포했기 때문에 백엔드도 https 를 적용할 필요가 있어서 내가 사용하던 도메인을 이용해 https 적용까지 했다.

 

진짜 프로젝트였다면 개발서버와 운영서버를 분리했겠지만, 해커톤은 어차피 개발서버 결과물이 그대로 보여질 테니 따로 구분하지 않고 하나의 어플리케이션 실행환경만 준비했다.

 

2월 11일의 커밋 기록

 

 

 

프로젝트 세팅할 때 제일 힘들었던 점은 시작부터 시큐리티를 깔아두고 갔다보니 시큐리티 설정을 넘어서 스웨거를 연동하고 CORS 설정하는데 시간을 정말 많이 썼다.

아직도 CORS 관련해서 해결되지 않은 의문이 있는데, CorsConfigurationSource 과 UrlBasedCorsConfigurationSource 의 차이이다.

스프링 빈의 타입이 후자일 때는 스웨거에서는 CORS 문제 없이 api 호출이 되었지만, 실제 프론트에서 호출시에는 CORS 정책에 의해 막혔고, 전자로 설정해야 스웨거와 프론트 둘 다 CORS 문제 없이 해결되었다.

이와 관련해서도 따로 찾아보고 글로 정리해봐야겠다.

 

회원 가입 구현 ( + SMS 인증 )

환경 세팅이 끝났다면 다음으로 제일 먼저 해야하는 작업은 서비스를 사용하는 유저 엔티티와 회원가입 api 를 만드는 것이다.

이 서비스에서는 요양보호사와 기관에 소속된 사회복지사 두가지 종류의 유저가 존재하는데, 두 유저의 회원가입 시 입력하는 내용이 달라 두 유저의 회원가입 API 를 분리했다.

일단 화면 기획상 요양보호사 기획이 먼저 마무리 되어 요양보호사 API 를 먼저 만들었다.

 

이번에는 회원가입 과정에서 전화번호 인증 시스템을 만들어야 해서 sms 인증도 처음으로 구현해봤다.

원래는 네이버 클라우드 플랫폼에서 무료로 할 수 있었는데, 24년부터였나 SMS 인증 기능을 기업회원에게만 적용하도록 바뀌어서 cool sms 라는 서비스를 이용했다.

여기는 회원가입시 300 원의 서비스 이용 금액을 제공한다.

 

근데 한 가지 마음에 안드는 건 분명 '단건 SMS' 는 20원인데, cool sms 사이트에서 단견 SMS를 테스트로 전송하면 50원이 차감된다... 직접 프로젝트에 적용한 api 를 호출해서 할 때는 20원씩 차감되는데 ㅠㅠ

혹시 cool sms 를 사용하실 분들은 사이트에서 테스트는 하지 마시길..

 

자격증 정보 입력

회원가입할 때, 요양보호사는 자격증 정보를 입력받아야 한다.

이때 자격증 요양보호사 자격증, 간호지원사 자격증, 사회복지사 자격증 총 3가지를 등록할 수 있고, 요양보호사 자격증은 필수이다.

 

처음 디자인 기획은 세 자격증의 입력 폼이 모두 다른 형태로 디자인이 나왔는데, 서로 다른 형태를 가진 자격증을 어떻게 저장할 지 고민이 많았다. 다행히 MVP 요구사항에서 자격증 번호 형식을 '이름, 급수, 번호' 형태로 통일할 수 있을 것 같아서 이를 기획자에게 건의했고, 건의가 받아들여져서 자격증 데이터 포맷을 하나로 통일할 수 있었다.

 

하지만 고민거리는 여전히 남아있었다.

포맷은 통일되었지만 요양보호사 자격증은 반드시 가져야 하고, 나머지 2가지 자격증은 선택적으로 보유할 수 있었다.

그렇다면 이 정보를 어떻게 저장해야 할 지 고민이었다.

 

나는 고민 끝에 멤버 엔티티 내에 3가지 자격증을 모두 저장하는 방법으로 구현하였다.

자격증 포맷을 통일했으니 테이블로 분리할 수도 있었으나 이렇게 저장한 이유는 다음과 같다.

 

1. 요양보호사  자격증이 필수인 점

자격증 포맷을 통일했다면 요양보호사 자격증도 자격증 테이블에 들어가야 한다.

그런데 요양보호사는 요양보호사 자격증을 필수로 가지고 있어야 하는데, 이를 외래키로 저장한다면 그 키에 해당하는 자격증이 요양보호사 자격증인지 알 수 없다. (다른 자격증의 외래키가 요양보호사 자격증 필드에 외래키로 들어갈 수 있다.)

 

그렇다고 포맷이 똑같은데 요양보호사 자격증만 별도의 테이블에 저장하는 것도 이상하다고 생각했고, 그렇다면 요양보호사 자격증은 요양보호사에 포함하면 좋겠다고 생각했다.

 

2. 자격증 번호는 마이페이지에서 유저 정보와 함께 수정되기만 하는 점

자격증 번호는 회원가입할 때 별도로 입력받는 폼이 존재하지만, 최초 회원가입 api 호출 시 request body 에 포함되어 들어온다.

그리고 이후 자격증을 추가할 때는 (삭제, 수정은 따로 없었지만 있었더라도) 마이페이지에서 다른 정보 변경과 함께 한번에 이루어지는 화면으로 구성되어 있었다.

 

이 외에 자격증 정보는 구체적인 번호 없이 자격증 이름으로만 요양보호사 조회시 함께 조회하는 느낌으로만 사용되었기 때문에, 자격증에 대한 정보를 별도 테이블에 나눌 필요성을 느끼지 못했다.

 

데이터베이스 시간에 배운 개념을 따라보자면, 자격증 엔티티는 일종의 요양보호사 엔티티에 의해 결정되는 약개체인 셈이다.

(요양보호사는 여러 개의 자격증을 가질 수 있기 때문에, 굳이 키를 정하자면 (요양보호사 ID, 자격증 이름) 이 키가 될 수 있을 것 같다)

지금 생각해보면 약개체라도 테이블로 분리가 가능하지 않았을까 싶기도하나, 요양보호사 정보를 조회할 때마다 매번 자격증 테이블과 조인을 걸어서 자격증 정보를 얻어와야 했다고 생각하면 지금처럼 한 게 더 좋은 방식인 것 같다고 생각한다.. 

 

 

프로필 이미지 업로드 기능

다음은 프로필 이미지업로드 / 수정 기능이 필요했다.

마이페이지 수정의 경우 우선순위가 낮다고 판단하여 구현 우선순위를 낮췄고 데모데이 때까지는 결국 개발하지 못했다.

그래도 프로필 이미지 업로드 기능은 회원가입시 필요해서 구현했다.

 

프로필 이미지는 이미지 업로드 api 를 따로 두고, 이미지 업로드 api를 호출해서 업로드를 마치면 업로드 한 이미지의 url 을 응답하고, 회원가입 api 를 호출할 때 응답받은 url 을 넘겨서 가입하는 방식으로 구현하였다.

 

이때 이미지 업로드에 이미지 파일 말고도, 회원가입하는 전화번호를 함께 넘기도록 api 를 설계했다.

단순히 이미지를 업로드하면, 업로드할 이미지의 이름을 정해야 하는데, 사용자가 악의적으로 이미지를 여러번 업로드하면 s3 버킷 공간이 의미없이 소모된다고 생각해서, 사용자의 전화번호를 해싱한 값을 이미지 파일 이름으로 사용하도록 했기 때문이다.

회원가입 과정에서는 아직 회원이 생성되기 전이므로 토큰과 같은 회원 식별정보가 없어 전화번호를 추가로 요청받도록 했다.

(그래서 어떤 SNS 사이트는 회원가입을 마무리한 이후에, 개인 설정하면서 이미지를 등록하도록 안내하는 이유도 이 때문이지 않을까 싶은 생각이 들었다.)  . 

 

 

요양보호사 로그인 구현

회원가입이 나누어져 있고, 요양보호사와 사회복지사의 데이터 저장 구조가 나누어져 있기 때문에, 로그인 API 도 나눠서 설계했다.

세오스 과제로 구현했을 때 이후로 스프링 시큐리티를 이용한 토큰 인증 로그인 구현을 처음해보았는데, 정말 많은 시행착오를 거쳤다.

 

로그인은 시큐리티 필터로 구현하기도 하고, 다른 API 만들듯이 구현하기도 하는 걸로 알고 있는데, 나는 기존의 API 만들듯이 구현하고, 시큐리티에서 로그인 api 를 허용해주었다

 

사실 로그인 자체는 괜찮았는데, 로그인이 시큐리티에 걸리지 않고 할 수 있게 시큐리티 설정하는 부분이 제일 까다로웠다.

이건 시큐리티를 여러번 다뤄보지 않으면 익숙해지지 않을 것 같다.

(하지만 프로젝트할 때 시큐리티는 최초 세팅 이후로 건들 일이 거의 없어서 또 까먹게 되는 부분이 아쉽다..)

 

 

요양보호사 / 사회복지사 API 구현

이후로는 API 구현에 본격적으로 들어갔다.

요양보호사 경력서 등록 API, 일자리 신청서 등록 API (이 일자리 신청서와 사회복지사가 올리는 모집 공고 내용을 기반으로 매칭이 이루어진다) 을 개발하고, 팀원이 사회복지사 회원가입, 로그인, 어르신 등록 API 구현을 마친 이후에 나는 공고 등록 (매칭 신청) API 를 개발했다.

공고를 등록하면 그때까지 일자리 신청서를 등록한 요양보호사들과 매칭이 이루어지는데, 구체적인 알고리즘을 기확자와 협의하면서 기준을 잡아나가는 것이 어려웠다.

 

케어항목, 요일, 시간, 급여 등 여러 항목에 대해 우선순위 기준을 따라 차근차근 비교해나가는 방식으로 매칭을 진행했는데, 코사인 유사도라든가.. 다른 방법들을 더 고민할 시간이 부족했던 게 아쉬운 포인트인 것 같다.

 

매칭 이후에는 요양보호사의 일자리 지원, 사회복지사의 최종 승인, 채팅을 통한 근무 조건 협의 이후 최종 계약되는 프로세스를 거친다.

 

채팅은 시간이 부족해 프론트와 백엔드 모두 구현을 다 하지 못했고, 데모데이에서 그 부분은 디자인 설명으로 대신했다.

 

최종 ERD

 

 

전반적인 후기

빠르게 결과물을 만드는 것이 목적이다보니 코드리뷰와 같은 절차는 생략하고 각자 구현하고, 테스트하고, 머지하는 방식으로 진행했다. (구현 과정에서 고민되는 포인트는 카톡으로 직접 논의하고 작업했다.)

하지만 빠르게 하는데 집중하다보니 너무 체계없이 진행했던 것 같다.

 

적어도 필요한 API 리스트를 뽑고, 그 리스트에 대해 명시적으로 분배한 뒤, 진행상황을 서로 공유하면서 했으면 좋았겠다는 생각이 들었다. (그래서 프로젝트 막바지에는 이 API 구현했어? 를 서로 여러번 물어봤다 ㅋㅋ)

 

그리고 이렇게 2명이서 만든 API가  40개 조금 넘게 나왔다.

단순히 API 작업만 한다면 금방 하겠지만, 프로젝트 ci/cd 세팅, https 적용, 배포와 같은 인프라 세팅, ERD 설계, 기획 요구사항 이해 후 구현과 같은 부분을 전반적으로 고려하면 10일 이라는 시간안에 하기에는 정말 빠듯한 시간이었다.

 

그래서 데모데이 발표하는 주에는 매일 새벽 5시에 자면서 하루종일 개발만 했고, 데모데이 전날에는 아침 8시까지 코딩하고 2시간 자고나서 PT 받고 점심먹고 데모데이가서 뒷풀이까지 하고왔다.

그 날은 잠을 정말 많이 잤던 것 같다.

 

그래도 이렇게 고생한만큼 챌린저 상이라는 일종의.. 3등상? 느낌의 상을 받게 되어서 뿌듯했고, 상금 10만원으로 다같이 고기도 먹고 재미있는 추억을 만들어서 좋았다

 

또 내가 지금까지 쌓은 개발 실력으로 어디까지 구현할 수 있는지 단기 퍼포먼스를 체크하기에 좋은 기회였던 것 같다.

그리고 이번 기회에 완전 초기 개발환경부터 배포까지 전체 사이클을 구현하면서 sms 인증, 시큐리티 세팅과 같이 익숙하지 않은 부분에 대한 경험도 채워나가고 프-백-디-기 전반적으로 협업하는 과정도 느껴볼 수 있어서 좋았다.

 

다음에도 해커톤을 나갈 수 있다면 또 나가봐야지 (그래도 한동안은 안 나갈 듯.. 너무 힘들었다)