[공모전] 2023 IT 창업 개발 동아리 멋쟁이 사자처럼 11기 해커톤 후기
개요
예선 일정: 2023.07.17 - 2023.08.17
본선 일정: 2023.08.18 14:00 - 2023.08.19 07:00
주제: 디지털 격차(이커머스∙소셜미디어∙공공서비스∙블록체인 온체인 서비스 등) 각 분야에서 발생하는 디지털 격차를 각 팀이 선택하여 이를 해소할 수 있는 서비스를 개발한다.
규모: 전국 61개 대학, 1600여명 대학생 참여
이번 행사는 특이하게 NFT 마켓플레이스 콘크릿과 연계하여 참가티켓과 수료증을 토큰으로 받는다!
심사위원과 심사기준
심사위원
멋쟁이사자처럼 대표 이두희, 위메이드 서일구 실장, 알토스벤처스 정해민 심사역, 소풍벤처스 최경희 파트너 등
심사기준
1. 독창성, 전달력, 기술성, 주제 적합도 => 각 항목 당 20점 만점으로 심사합니다.
2. 완성도, 사업성 => 두 항목은 30점 만점으로 심사합니다.
총 140점 만점입니다.
협찬사는 위메이드, 네이버 클라우드, 동아제약 등이 있었는데 해커톤 현장에서 다양한 부스와 이벤트를 제공해주셨고 지칠 때쯔음 즐기기 좋았다. 이벤트가 꽤나 쏠쏠해서 현장 분위기도 더 업되고 좋다고 느꼈다.🖤🧡
해커톤 총평
주제 발표를 해커톤 당일 한달 전인 2023.07.17에 하고, 개발 기간이 주어진다. 이렇게 기간이 주어지는 해커톤은 처음이라 정직하게(?) 딱 한달만 썼는데 당일날 우승 후보 팀들의 결과물을 보니 한달 전부터 꾸준히 개발을 지속하는 것이 훨씬 유리하다고 느껴졌다. 그리고 우승은 못했지만 참가하는 것만으로도 전국 대학생들의 개발에 대한 열망과 열기가 정말 큰 원동력으로 다가왔다. 진짜 대단한 사람들을 많이 봤고, 많은 걸 느꼈던 시간이었다. 다같이 한 자리에 모여서 아이템 개발을 하는 것 자체가 즐거웠고, 개발자 인생에서 꽤나 값진 경험이었다.
또 개인적으로 심신이 많이 지쳤던 시기라 평소 공모전을 참여할 때의 그 집중도와 몰입감을 많이 발휘하지 못한 것같아 정말 아쉬웠다.ㅠㅠㅠ 하지만 해커톤을 다녀와서 지칠 만큼 지친 몸과 정신을 많이 정화하고 왔다. 1600여명이 모여서 개발하는 그 열기와 우승팀들의 결과물들이 정말.. 많은 것을 깨닫게해주었기 때문이다. 이러한 변화를 기회삼아 다시 열심히, 제대로! 다가오는 인턴십을 해내리라고 마음먹은 계기였기도 해서 힘든 시기에 마음을 다 잡을 발판이 되었다. 멋사 최고 😭
해커톤 중 맡은 역할과 배운점 - (1) 기획과 Use Case 그리고 Flow Chart
초반에는 매주 2-3번씩 모여서 기획 회의를 하고 업무적으로 컨벤션도 정했다. 기획부터 개발까지의 프로젝트를 해본 사람이면 알겠지만 기획과 컨벤션을 초반에 잘 다져두는 것이 앞으로의 업무 진전도를 위해 정말 중요하다. 우리팀은 "디지털 격차"를 해소한다는 걸 생각하기가 정말 힘들었다. 이 과정을 겪으며 깨달은 점은 다음과 같다.
- 어려워 보이는/불가능해 보이는 구현이라도 일단 도전해보자. (업무 X 해커톤 O, 특히 멋쟁이사자처럼 해커톤이라면)
- 계획을 A to D 정도까지 세우는 것이 중요하다. 즉, 해커톤은 전략적으로 임해야한다!
- 기획 중후반 단계에서 Use-Case와 Flow-Chart를 작성하며 아이템을 구체화하자.
해커톤 중 맡은 역할과 배운점 - (2) ERD 설계
산학 프로젝트를 할 때 ERD 설계를 맡았었고, 그때 나름 꼼꼼하게 공부를 했었다. 그럼에도 불구하고 4 학년 선배에게 배우는 ERD 설계는 내가 설계했을 때의 문제점을 잘 파악할 수 있었기에 좋은 경험이었다. 다음과 같은 목차로 설계하였고, 최대한 기획 단계에서 만든 플로우 차트와 유즈케이스를 반영하였다.
- 개념적 설계
- 이 단계에서는 구현적인 면을 전혀 생각하지 않는 것이 핵심이다. 구현적으로 설계하게 되면 그건 DA가 하는 역할의 핵심을 벗어나는 것이다. 실무에서 DA는 개념적 설계 단계에서 백엔드적 구현 관점을 고려하지 않는다.
- 피드백 내용
개념적 설계 단계에서는 FK를 정의하지 않는다. FK는 관계형 DB에서 사용하는 것인데, 개념적 설계 단계에서는 SQL or Nosql을 정하는 것이 아니라 서비스를 제공하기 위해 어떻게 data들을 관리할지 설계하는 것이기 때문이다.
첫 번째 피드백과 이어지는 내용인데, DA는 Database를 설계하고 관리하는 사람이기에 서버적인 구현을 생각하지 않는다. 서버와 데이터베이스는 별개로 생각하고 설계한다.
정적인 컨텐츠는 Database에서 다루지 않는다. 정적 컨텐츠는 프론트 측에서 바로 화면에 뿌려주는 것이 DB에서 값을 꺼내오는 것보다 훨씬 효율적이기 때문이다. DB는 동적인 것을 처리한다.
게시판 database에서 무엇을 어떻게 관리하는지에 대한 세심함이 부족하다. 몇 번 열람되었는지, 언제 썼는지, 댓글과 대댓글을 어떻게 관리할 것인지 배울 수 있었다.
- 피드백 내용
- 이 단계에서는 구현적인 면을 전혀 생각하지 않는 것이 핵심이다. 구현적으로 설계하게 되면 그건 DA가 하는 역할의 핵심을 벗어나는 것이다. 실무에서 DA는 개념적 설계 단계에서 백엔드적 구현 관점을 고려하지 않는다.
- 논리적 설계
- 피터 첸 표기법을 활용한다.
- ERD 부하 계산 & 역정규화 → 비즈니스 모델에 대한 전체 부하를 계산해서 Table을 나누기 위해 전체 접근보다 예측 접근이 적기 때문에 DB 접근을 최소화하기 위해(서버의 가용성이 좋아진다.) 아예 분리해서 DB 접근을 줄이고 성능 높인다!
- 약한 개체 논리적 설계할 때는 둥근 사각형으로,,
- 논리적 스키마는 그 자체로 Domain이 된다.
해커톤 중 맡은 역할과 배운점 - (3) Spring 구현 | 테스트 코드 짜고, 요청 단위로 테스트하기
이전 프로젝트에서는 개발하기 급급해서 디자인 패턴, 스프링 강점 등을 전혀 활용하지 못했다. 이번에 이러한 패턴을 이해하고 개발을 진행하는 분들과 함께 프로젝트하면서 많이 배울 수 있었다.
- SOLID 원칙을 적용하며 인터페이스와 구현체를 분리한다.
- Controller에서는 DTO,Service 호출과 Exception 만을 담당한다.
- 메소드와 클래스는 하나의 목적만을 위해 생성한다.
- 도메인명의 Service보다는 도메인과 관련된 여러 기능을 세분화하여 Service를 만든다.
해커톤 중 맡은 역할과 배운점 - (4) Git Convention과 지라 협업
이번 프로젝트에서 처음으로 지라를 사용했다. 팀장님이 티켓을 발행하면 해당 티켓과 관련한 작업을 하고, 이와 관련한 Github Commit & PR을 날리는 것이 우리팀 백엔드의 규칙이었다.
해커톤 중 맡은 역할과 배운점 - (5) 인프라 | 도커와 EC2 조합으로 서버 배포하기
클라우드 / 인프라 쪽에 관심이 많아서 이걸 젤 열심히 했던 기억이 있다. 이건 하면서 재미도 있었고, 나중에 포스팅 하려고 단계별로 세세히 정리도 해두었다. 곧 게시할 예정..ㅎㅎㅎㅎ
포스팅에 다 적기 너무 많을 정도로 배운 양이 어마무시하다.. 멋사 해커톤 또 하고싶어서 졸업 미루고싶은 심정.. 내년에 4학년이니 또 할 수 있으려나? 아무튼!! 정말 뜻깊은, 깊이 배울 수 있었던 값진 경험이었다. 도커랑 ec2를 활용한 서버 배포도 진짜 하고싶었는데 팀원 분들이 하고싶은 거 해보라고 밀어주셔서!!ㅎㅎ 감사했다. 같이 모여서 성장하는 멋쟁이 사자처럼은 평생 잊을 수 없는 동아리 활동이다.
