본문 바로가기
SAN's history/kernel360

[kernel360] 해커톤 회고

by san.d 2023. 11. 1.

boot-up 다음은 해커톤톤 

해커톤에서 제시한 목표는 다음과 같다. 

최소한의 기술적 완성도를 가진 결과물을 단시간에 만들어 봄으로써 자신의 기술적 실력을 파악하고, 빠른 학습에 대한 경험을 습득한다. 프로젝트를 진행하며 코드의 품질, 기술적 협업 등을 이해하는 것을 목표로 한다.

해커톤은 4일동안 진행되는데 안내사항에 

  • 기획적 완성도, 창의성보다 작더라도 하나의 프로젝트를 기술적으로 완성하는 것에 중점을 둔다.
  • 기능이 적게 포함되더라도 완성된 서비스를 구현할 수 있는 주제를 고안한다.

라고 되어있길래 뭘해야 4일 안에 완성할 수 있을까... 그리고 무엇보다 우리는 백엔드만 모여있고 프론트가 없는 상황인데... 라는 것을 고심하다가 작은 tistory 만들기라는 아이디어를 생각했다. 재미없어 보이긴 하지만  만약에 아이디어 채택이 되면 옛날에 스터디 방에서 나왔던 이야기인 좋아요 count수를 어떻게 처리할 것인가에 대해서 고민하려고 했었다. DB 설계나 redis를 끼는 것과 같은.... 아주 원대한 꿈이었던 것....  해커톤에 적용된 특이사항같지 않은 특이사항 boot-up과 마찬가지로 3일차부터는 팀원이 바 뀐 다

 

그리고 우와ㅏㅏ 대박 내 아이디어 채택됨 

ministory 소개

작은 tistory 만들기, ministory

나만의 게시글을 올릴 수 있는 게시글 사이트 만들기 

ministory 메인 기능

  • 나만의 페이지에 나만의 카테고리를 만들어 나만의 게시글을 작성할 수 있다. 
  • 댓글, 좋아요, 스크랩을 할 수 있다. 

ministory 저장소 

https://github.com/Kernel360/hackerthon1-ministory

 

GitHub - Kernel360/hackerthon1-ministory: 나만의 작은 블로그 - ministory

나만의 작은 블로그 - ministory. Contribute to Kernel360/hackerthon1-ministory development by creating an account on GitHub.

github.com

ministory의 기획 프로세스

1. 가장 메인이 되는 기능 추리기

2. 기능 명세서를 통해서 세부 기능까지 정리하기

3. 기능 명세서 기반으로 erd 작성하기 

4. 간단하게 화면 구성 요소 정하기 

5. 업무 분담하기 

6. 개발 시작!

ministory 기술 스택

  • frontend
    • thymeleaf
    • jquery
  • backend
    • java 11
    • Spring Boot 2.7.17
    • Spring Data JPA
  • database
    • MySQL

내가 ministory에서 한 일

  • 프로젝트 초기 셋팅 & entity 설정
    우리 팀원들은 모두 자바-스프링부트를 공부하고 있었기 때문에 기본적으로 자바-스프링부트를 사용하도록 했다. 또한 가장 많이 다뤄봤던 spring boot 2.7 버전을 사용하기로 했고 spring boot 3버전을 쓸 것도 아니고 자바 17버전부터 있는 기능을 아주 잘 쓰는 것도 아니기에 자바 11버전을 사용하기로 했다. entity가 많지 않기도 했고, 관계설정에 대한 합의는 모두 했기 때문에 한 사람이 빠르게 entity 설정까지 하는게 편하다고 생각해서 내가 맡기로 했으나ㅏㅏ.... 내 컴퓨터에서 dependency 이슈로 우리팀의 석희님이 먼저 entity 설정을 살짝 해주셨다. 그래서 집에가서 이슈 해결하고 entity 마무리해서 2일차부터 개발에 슉 들어갈 수 있었다. 감사합니다.. 우리팀 짱
  • Swagger 달기 

내가 만든 스웨거~

해커톤 특성상 시간이 많지 않기도 하고 한 도메인을 맡으면 그 도메인에 대해서 프론트, 백 모두 해결하기로 했기 때문에 처음에 기능 명세서를 다 같이 작성하면서 합의보지 않고 도메인 책임자가 알아서 하기로 했다. 그런데 이렇게 했을 때 계속 그 사람이 해당 도메인을 맡을지도 모르고 (특히나 우리는 너무나도 분명하게 팀원이 3일차면 바뀔 것이기 때문에...) 다른 사람 해당 기능을 가져다 쓸 수도 있고, 무엇보다 팀장으로서 일의 진행도가 잘 안보여서 (감시는 아니구..) 개발하고 어노테이션을 달아서 명세할 수 있는 스웨거를 패치해놓기로 했다.

위의 사진과 같이 작성한 api는 swagger 페이지에 등록되어서 확인할 수 있다. 

사실 내가 패치한 스웨거 라이브러리는 이제 그러니까 버린,,, 업데이트 안해주고 방치시킨 라이브러리인데 왜 때문인지 관리해주는 3버전이 적용이 잘 안되어서 그냥 2버전으로 임시조치했다. .. 하라는대로 했는데 왜 안 나오냐고.......;;;;;;;;;;

  • 좋아요, 스크랩 관련 API 구현 
    easy...... 왜냐면 캐시 (redis) 도입이라는 원대한 꿈을 버렸기 때문.....ㅋ
  • 게시글 Post 후 게시글로 redirect & 게시글 페이지에 댓글과 좋아요, 스크랩 버튼 달기 
    와 진짜 내가 제일 좋아하는 언니 너무 보고싶었음.... 언니 프론트 어케 해.....???? 프론트 진짜 너무 어려웠다..... 그나마 이건 석희님이 editor.md 라이브러리 패치 다 해주시고, 거기 편집기에 글 작성해서 post 요청 쏘는 것까지 구현해주신 후라 라이브러리는 건드릴게 없었지만 그냥 html 화면 구성하고, 좋아요 스크랩 댓글을 등록하는 api 연결하고  좋아요나 스크랩, 댓글을 달았을 때 화면을 어떻게 reload 해야 조회수에는 변동이 없을지 고민하느라 머리 깨지는 줄 알았다. 잘 모르면서 프론트까지 같이 하다보니까 어디까지가 백엔드에서 처리해줬어야 하고 어디부터 프론트가 처리해줘야하는 일인지 구별이 안돼서 애먹었다. 결국은 사실 걍 야매로 백엔드에서 다 처리하게 해버림. 너무 야매로 처리해서 누가 내 코드 읽으면 도대체 이 api는 왜 있었어야 했냐고 물어볼 듯...ㅋㅋㅋ......
    파이널.....프론트엔드 개발자느님들 제발 데려와주세요......
    허접하지만 그래두.... 내가 만든 ..... html 페이지.......

\아 이쁘다~ 내 눈에는 이쁘다

ㅋㅋㅋㅋ생성일 timestamp 냅다 박은거 킹받.....

회고

[ 팀장 ]

팀장.... 꽤 많이 해봤다고 생각했는데 이번에 나의 능력 부족을 확실히 느꼈다. 팀이 중간에 한번 바뀌었었으니까 1, 2일차 팀을 전팀 3, 4일차 팀을 후팀이라고 하자. 전팀을 진행할 때는 도메인을 나눠서 맡겨만 놓고 세부 사항에 대해서 알아서 task를 나눠서 이슈 생성하고 pr을 날리도록 했다. 하지만 해커톤 특성상 짧은 시간 안에 구현해야하는 것들이 많은데 '너무 큰 덩어리로 일을 줘버리지 않았나', '스스로 스케줄 관리하는게 힘들지 않았을까' 하는 후회가 2일차 마지막에 들었다. 그래서 후팀을 리드할 때는 스프린트 주기를 훨씬 짧게 끊어서 2-3시간 마다 해야할 작은 feature를 부여하고 완료되었는지 확인해서 지금 어떤 기능이 완성되었는지, 진행도가 어떻게 되어가고 있는지 더 체감이 잘 될 수 있도록 의도했다. 그리고 팀원들도 이렇게 하면 기여를 하고 있다는 성취감이 더 많이 들 것 같았다. 그랬나요????ㅋㅋㅋ 이걸 안 물어봤네~

 

그리고 인수인계를 하고 새로운 팀원들에게 새로운 task를 부여하려고 할 때, 각 도메인 별의 실제 기능 구현도가 잘 안보여서 앞으로 해야할 일에 대해서 정리를 하는데 약간 어려웠다. 전 팀분들이 나름 구두로도, pr로도 잘 남겨주셨는데 내가 기능을 하나하나 확인한게 아니다보니 리팩터링이 필요한 기능인지, 아니면 완전 완료되서 신경안써도 되는 기능인지, 명세에 적진 않았지만 편의를 위해 만들어 놓은 기능이 따로 있는지를 빠르게 파악하기 힘들었달까??

 

그래서 앞으로 만약에 팀장이 되면 스프린트 주기를 총 프로젝트 시간 고려해서 현명하게 가져가서 팀원들이 적당한 성취감과 목표를 가질 수 있도록 하고, 진행 상황이 보이는 협업툴(github issue, project, pr 메세지)를 100% 활용하도록 독려를 해야겠다는 생각을 했다.

 

[ 개발자 ]

그동안 졸업 프로젝트 한 걸로 기술 우려먹으면서 버텨왔는데 JPA와 spring boot 요청 처리 흐름을 좀 똑바로 공부해야겠다는 생각이 들었다. 그리고 프론트 로직을 몰라도 너무 모르고 있다는 것을 깨달았다. 

흠 개발자로서의 회고는 반성밖과 후회 후회 후회, 멍청한 나에 대한 탄식탄식탄식 밖에 없어서....... 쩝
TODO List 로 다음 프로젝트에는 달성한 목표에 대한 회고를 할 수 있도록 하자. 

  • JPA 알고 쓰기
  • spring boot 요청 흐름 알고 쓰기
  • 레디스 공부하기 + 적용하기 
  • 외부 api에 요청 보내보기

 

 

 

회고 끝~~~ 이제 프로젝트 하러 갑니다......... ^0^....룰루 랄라

 

'SAN's history > kernel360' 카테고리의 다른 글

[kernel360] E2E Project 회고  (0) 2024.04.04
[kernel360] boot-up 회고  (1) 2023.11.01

댓글