[Kernel360] 해커톤 프로젝트 회고

해커톤 프로젝트

Boot-up 프로젝트가 끝나고 바로 해커톤 프로젝트가 시작되었습니다.

 

Kernel360에서의 해커톤 프로젝트는 4일간 최소한의 기술적 완성도를 가진 결과물을 단시간에 만들어 봄으로서 현재 자신의 실력을 파악하고, 빠른 학습에 대한 경험을 습득하는 과정이었는데, 프로젝트를 진행하면서 코드의 품질, 기술적 협업 등을 이해하는 것에 우선순위를 두었습니다.

 

해커톤 프로젝트는 Boot-up 프로젝트와 다르게 기술적으로 완성해야하는 프로젝트로 다음과 같은 필수사항이 있었습니다.

• 기능이 적게 포함되더라도 완성된 서비스를 구현할 수 있어야한다.
• 프로젝트를 주어진 시간내에 완성해야하며 기획적 완성도, 창의성보다 작더라도 프로젝트를 기술적으로 완성해야한다.

프로젝트를 기획하는 것이 목표였던 Boot-up 프로젝트와 다르게 팀원들과 당장 구현을 하는 것이 중요했기 때문에 팀원 개개인의 경험치와 사용할 수 있는 기술스택을 최대한 고려하여 선정해야 했습니다.

 

doitfor(1, 2일차 프로젝트)

GitHub - Kernel360/hackerthon1-doitfor: shortURL을 만들어주는 서비스입니다.

기술 스택

• java 11
• Thymeleaf
• Spring Boot 2.7.16
• Spring Data JPA
• MySQL 5.7
• Gradle

 

해커톤의 1, 2일차의 프로젝트로 긴 웹 주소(링크)를 짧게 줄여주는 서비스인 링크 단축 서비스를 구현했습니다.

실제로 지인들에게 링크를 공유할 때 사용했었던 서비스라 다른 주제보다 흥미있게 시작할 수 있었습니다.

링크 단축 서비스는 다음과 같은 절차를 통해 서비스를 제공한다고 정의했습니다.

1. 긴 주소를 화면에 입력한다.
2. 서버는 입력된 긴 주소를 해싱알고리즘을 통해 짧은 임의 문자열로 변환한다.
3. 이렇게 생성된 단축 주소와 긴 주소(원래주소)는 데이터 베이스에 저장된다.
4. 사용자에게 생성된 "https://<도메인>/<단축주소>" 형식의 단축 주소를 제공한다. 
5. 사용자가 도메인에 단축 주소를 입력하면, 우리 시스템의 서버로 접속한다.
6. 서버는 데이터베이스에서 원본 주소를 검색하고 사용자를 원래 주소로 리다이렉트한다.

단축 URI를 생성할 때 어떤 암호화 알고리즘을 선택하느냐에 따라 안정성과 기능성에 직접적인 영향을 주었기 때문에 프로젝트에서 가장 신중하게 고려해야할 사항이었습니다.

 

팀 내에서 수많은 고민 끝에 아래의 3가지의 대안을 도출해냈습니다.

 

스노우 플레이크 활용

스노우 플레이크를 활용하면 안전하고 고유한 단축URI를 생성할 수 있었으나 단 시간 내에 적용하기에는 러닝커브가 있음.

 

서버에서 UUID 값 생성

UUID를 생성하는 것은 빠르게 구현할 수 있었지만 문자열의 길이가 너무 길고, 문자열을 잘라서 사용하기에는 충돌 위험이 있음.

 

빠른 암호화 방식 사용

속도가 빠른 암호화 방식을 사용하면 짧은 문자열을 만들 수 있었으나, 일부 알고리즘은 자바에서 지원하지 않으며 이 알고리즘을 사용해도 되는지에 대한 판단을 할 수 없었음.

 

최종적으로 서버에서 UUID 값을 사용하여 유일키를 생성하는 방식으로 구현한 후 리팩토링을 통해 유일키의 길이를 줄이도록 결정했습니다.

 

해커톤 프로젝트에서는 Boot-up 프로젝트와 다르게 기능을 구현해야했기 때문에 커밋 컨벤션, 깃 브랜치전략 등 구현 레벨에서 정의해야하는 개발 컨벤션을 먼저 정의하고 시작했습니다.

 

Kernel Library(3, 4일차 프로젝트)

GitHub - Kernel360/hackerthon1-kernelLibrary: Kernel360의 작은 도서관입니다.reboot

기술 스택

• java 17
• Thymeleaf
• Spring Boot 3.1.4
• Spring Data JPA
• MySQL 5.8
• Gradle
• Google Books API

해커톤을 시작한지 3일째 되는날 팀이 변경되었고 새로운 프로젝트를 시작하게 되었습니다.

새로운 팀에서 먼저 작업해놨던 작업물을 인수인계받고 이어서 구현을 하는 식으로 나머지 작업이 진행되었는데 다행히도 이전 프로젝트와 유사한 기술 스택을 사용하고 있어서 기술적으로 러닝커브없이 바로 이어서 개발을 시작할 수 있었습니다.

 

담당한 기능

기존에 개발중이었던 API 구현 및  로그인 부분을 담당하게 되었습니다.  해커톤 프로젝트라는 성격상 단 기간에 완료해야했기 떄문에 주어진 일정에서 최대한 빠르게 구현해야했기 때문에 Servlet HTTP Session을 사용하여 단일서버에 세션 정보를 저장하는 방식으로 로그인 기능을 구현하기로 결정했고 기간내에 담당한 기능을 모두 완수할 수 있었습니다.

 

 

프로젝트 후기

Boot-up 프로젝트에 이어 해커톤 프로젝트까지 굉장히 빠듯한 일정이었지만 재밌었던 기간이었습니다.

해커톤 프로젝트는 마치 실무에서 다른 사람의 작업한 것을 인수인계 받아서 개발하는 것과 유사한 경험을 할 수 있었습니다.

데드라인이 정해져있어 급하게 개발 진행했지만 좋은 팀원분들과 함께 서로의 문제점을 보완하며 성공적으로 마무리할 수 있어서 더 만족스러웠습니다.

다음 E2E프로젝트에서는 해커톤 프로젝트보다 시간적 여유가 있기 때문에 조금 더 설계에 집중하고 기술적으로 고민하여 구현할 수 있도록 준비를 잘 해야할 것 같습니다ㅎㅎ.