[Kernel360] Hackathon : ministory ~ Orury

개요

앞서 Boot-Up 과정에서는 기획을 중심으로 효율적으로 협업하는 방법에 대해서 배웠습니다. 이번에는 과정 중 다음으로 진행된 해커톤 프로젝트에 대해 소개하고자 합니다. 

 

해커톤 프로젝트도 이전에 진행한 프로젝트와 유사하게 3일 차에 팀을 바꾸고 새로운 팀원들과 진행하는 형태였습니다. 이번에는 팀원이 되어 4일이라는 기간동안 다른 두 팀에 속해서 실제로 개발과 코드 리뷰를 진행하면서 이전 프로젝트보다 배운 점이 많았습니다. 이틀 동안은 ministory라는 나만의 게시글 사이트를 이후 이틀 동안은 Orury라는 클라이밍 커뮤니티 서비스에서 기획과 개발을 진행했습니다. 

 

아래의 Notion과 Github 링크에서 프로젝트에 대한 더 자세한 문서와 결과물의 세부 내용들을 확인하실 수 있습니다.

 

ministory - 나만의 게시글 사이트

• ministory 팀 노션 : https://www.notion.so/ministory-0361f610b2b8491f9331654684ce35cf?pvs=4
• ministory 팀 Github : https://github.com/Kernel360/hackerthon1-ministory

Orury  - 클라이밍 커뮤니티 서비스

• Orury 팀 노션 : https://www.notion.so/d925d9e7c42f4738bee88bdd8eec71c6?pvs=4
• Orury 팀 Github : https://github.com/Kernel360/hackerthon1-Orury

본론

Kernel360 과정에 참여하기 전에는 혼자서 프로젝트를 경험하면서 기획을 어떤 식으로 진행하고 어떤 산출물이 필요한지에 대한 정확한 인지가 없었습니다. 이전에 Boot-Up을 진행하면서 팀장으로서 프로젝트를 진행하고 기획 과정에 대한 학습이 필요하다고 느꼈습니다. 따라서 이후 과정 중 진행될 프로젝트에 도움이 될 것이라 생각하여 이전에 협업을 통한 프로젝트 경험이 있는 팀원들이 속한 ministory 팀에 합류하였습니다. 

 

ministory

이전에 Boot-Up을 진행하면서 팀원들과 같은 방향으로 같은 지식으로 나아가고 있는지 확인하기 어려웠습니다. ministory 프로젝트를 진행하면서 분업을 하지 않고 함께 기능명세와 ERD를 작성하면서 팀원들이 함께 프로젝트를 진행하고 있다는 느낌을 받았습니다. 또한 개발에 들어가기에 앞서 와이어프레임을 간략하게 Figma를 사용하여 그려보면서 어떤 기능들이 포함되어야 할지에 대해 정확하게 이해를 할 수 있었습니다. 이러한 경험을 토대로 백엔드 개발자가 직접 화면에 대한 코드를 작성하지 않는다 해도 기획한 서비스에 대해 더 쉽게 파악할 수 있다고 깨닫게 되었습니다. 다음으로 앞서 작성한 명세와 ERD를 바탕으로 다음과 같은 기술 스택을 정했습니다. 모든 문서화 작업을 완료하고 팀 github 저장소에 바로 알아볼 수 있도록 readme를 수정했습니다.

• Frontend 
  • Thymeleaf - 저를 포함한 해당 스택을 경험해본 팀원들이 있었고 Backend의 개발 스택이 spring 이기 때문에 호환성이 높고 러닝커브가 낮다고 생각하여 선택
  • JQuery - 글쓰기 기능을 다른 마크다운 편집기능이 있는 템플릿을 사용해 개발하려면 필요한 스택. 글쓰기 기능을 처음부터 마크다운으로 하려고 찾아보고 선택
• Backend
  • JDK 11 - JDK 8 이상을 사용해보고자 선택
  • Spring Boot 2.7.12 - 2.xx 버전대에 있는 SpringBoot 중 가장 최신의 Stable 버전을 선택
  • Spring Data JPA - 쿼리를 직접 작성하지 않을 예정이었고 해당 스택에 대한 경험이 있기 때문에 팀원들과 상의 후 결정, 또한 Jpql이나 직접 쿼리를 작성하는 스택을 선택하면 러닝커브가 높을 수 있다고 판단하여 선택
• Database
  • MySQL 8.1.0 - 프로젝트 진행 시점에서의 제일 최신 Stable 버전을 선택 (23.10.25 기준으로 8.2.0인 새로운 stable release가 나왔다.)

이번 프로젝트 협업에서 개발을 실제로 진행하기 전에 통합된 Entity 설계를 통해 코드를 작성하기 수월했습니다. 한 사람이 모든 Entity를 작성하고 해당 코드를 팀원들이 함께 리뷰해서 개발을 시작하기 전에 모든 Entity 클래스를 완성했습니다. 이에 따라서 DB에서의 연관관계가 없어서 더 이상 개발을 진행하지 못한다거나 하는 문제가 없어서 개발 진행이 순조로웠습니다. 

 

이번 프로젝트에서는 다음 팀으로 넘어가기 전까지 저는 아래와 같은 기능들을 개발하고 실제로 화면 상에서 동작까지 하는 것을  보고 오프보딩을 하였습니다. 

• 회원 추가 및 회원 리스트 확인 : 화면을 통해 회원의 정보를 받고 DB에 등록하여 확인할 수 있도록 했습니다. 추가 기능 및 회원가입 페이지 / 회원 목록 조회 페이지를 만들어 이후 팀원들이 화면과 백엔드 Server 사이에 연동하는 예시를 남겼습니다.
• 댓글 / 대댓글 기능 구현 : 저희 프로젝트에는 게시글에 달린 댓글과 댓글에 달린 댓글 두 종류의 댓글을 기획했고 이에 대한 백엔드 로직(댓글 / 대댓글 추가 / 수정 / 댓글 목록 조회)을 구현하였습니다. 이 또한 임시 화면을 Thymeleaf를 통해 설계하고 주석으로 to do를 남겨 이후 온보딩하게 되는 다른 팀원들이 확인하고 구현할 수 있도록 기록을 남겼습니다.

또한 이전에 개인 프로젝트를 진행할 당시에 코드 리뷰를 받으며 얻은 긍정적인 학습 경험을 나누고자 팀에 있는 동안 최대한 자세하게 코드리뷰를 진행하였습니다. 주석으로 남긴 글도 확인하며 제 의견을 남겼고 동료들에게 더 나은 학습 경험이 될 수 있도록 고민하여 리뷰를 남겼습니다. 코드 리뷰는 단순히 받는 사람뿐만 아니라 동료의 코드를 보면서 얻는 것도 크다고 생각하기 때문에 리뷰하는 과정 속에서 실제로 이전에는 생각해보지 못했던 이슈들을 고민하면서 성장했습니다. 

 

다음 링크에서 제가 다른 팀원의 PR에 남긴 리뷰를 통해서 어떤 식으로 코드 리뷰를 진행했는지 확인할 수 있습니다!

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

 

Orury

ministory에서 경험했던 협업을 토대로 남은 이틀 동안 많은 기능들을 개발할 수 있을거라 생각했던 저는 Orury에서 새로운 팀원들과 함께할 개발을 기대하며 온보딩 하였습니다. 기대와는 다르게 DB 설계에서부터 많은 문제점들이 있었고 화면 개발도 진행되지 않은 상태라는 것을 깨닫고 "시간이 정말 남지 않았다"라는 부담을 갖고 시작했습니다. 제가 새로 만난 팀의 ERD는 이러한 상태였습니다.

음.. 곤란하네..요!

 

• 모든 도메인 (테이블)의 id가 bigint가 아닌 varchar로 되어 있어서 게시글이 많아진다면 인덱스의 성능 이슈가 생길 수도 있는 우려가 있었습니다. bigint와 varchar는 Java에서 각각 Long과 String으로 변환되고 인덱스 성능을 고려한다면 이는 상대적으로 조회와 join에 오래 걸리는 String(varchar)의 형태는 피해야한다고 생각했습니다. 또한 pk의 유일성을 보장하기 위해 다른 parse 메서드를 구현해야하기 때문에 기능 구현이 불필요하게 복잡해진다고 느꼈습니다.
• 삭제된 게시글 / 게시글 테이블이 각각 존재하는 점은 저 또한 경험해본 적이 없었기 때문에 쉽게 의견을 피력하지는 못했지만 boolean isDeleted와 같은 column으로 처리하면 어떨까라는 생각을 해보았습니다.

위와 같은 이유로 온보딩을 하고나서 제일 중점적으로 진행했던 것은 기능 개발이 필요한 도메인에서의 id 타입 수정이었습니다.  또한 로그인과 회원가입과 같은 구현되어 있었고 와이어프레임도 있었지만 해당하는 모든 코드를 작성한 팀원이 오프보딩을 통해 다른 팀으로 옮겨가자 더 이상 진행이 불가한 상태였습니다. 이 때 당시 저는 Spring Security를 경험해보지 못한 상태였기 때문에 일단 해당하는 기능들을 모두 주석처리 해놓고 진행하였습니다. 앞서 진행했던 ministory 프로젝트와 어느 정도 주제가 겹치는 점, 그리고 개발을 바로 할 수 있는 팀원들이 거의 없었던 관계로 남은 기간동안 기존의 기능 설계에 있던 모든 개발을 하기에는 시간이 부족했습니다. 따라서 주어진 시간 안에 완성을 하지는 못했지만 이번 프로젝트에서는 저는 다음과 같은 일들을 진행했습니다. 

• 회원 객체 수정 및 회원가입 : 앞서 프로젝트에 제가 담당했었던 부분과 유사하고 직접 ERD와 회원 객체의 내부 필드를 수정하면서 왜 id를 Long이나 Integer로 하는지에 대해서 다시 생각해보게 되었습니다.
• 게시글 / 댓글 객체 수정 : ERD를 수정하게 되면서 변경된 컬럼들이 존재했는데 이 부분을 수정하면서 객체간의 연관관계를 다시 공부가 필요하다고 느끼게 되었습니다.

비록 기능 대부분이 미구현으로 남아있고 앞으로 갈길이 멀다고 느껴졌지만 저에게 새로운 주제들에 대해서 생각해보게 해주는 계기가 되었습니다. JPA의 구현체인 Hibernate는 생성 전략에 따라 어떤 식으로 테이블과 컬럼 명을 지정하는지, ERD 설계를 하면서 어떤 점들을 고려해야 이후에 수정하는 일이 없을지, ERD 설계가 왜 중요한지에 대해서 다시 한번 생각해보고 이후 프로젝트 진행에 참고할 수 있도록 해야겠다고 느꼈습니다.