부산 ICT 해커톤 회고

 

부산 범내골에 있는 부산상공회의소에서 ICT 공동해커톤이라는 대회에 참가하게 되었다.

 

팀원은 연구실에 같이 활동하고 있는 친구들과 참가하게 되었다.

 

나는 백엔드 개발을 맡게 되었고 프론트엔드, UI 디자인 퍼블리싱, 기획 이렇게 각 1명씩 맡아서 4명이 팀을 이루게 되었다.

 

각 역할에서 잘한다는 포지션으로 참가하기도 하였고, 각 포지션별로 1명씩 진행하다보니 문제가 발생했을때 어떻게 해결해 나갈지 미리 얘기해둔바는 없었다.

 

자신있다고 생각하는 포지션으로 계속 각자 공부를 해오던 차였고, 이번에 제대로 보여줄 수 있겠구나라는 생각을 하였다.

 

해커톤 시작앞에 나 ㅎㅎ

 

해커톤은 오후 13시부터 진행되었다.

 

각 팀별로 주제 아이디어를 돌아가면서 발표하였고, 진행 도중 음료수 교환권을 제출하며 수분을 보충하였다.

 

우리 팀의 주제는 부산 공유대학의 타 대학 강의를 들을 수 있도록 하기 위한 수업 리뷰 사이트였다.

 

BITS라는 부산의 대학들간의 공유대학 강의를 하는 큰 사업을 기점으로 하여 타 대학들 간의 강의 후기나, 선배들이 후기를 작성해두어 우리학교의 강의 후기들을 모아 선후배간 후기를 공유할 수 있도록 하는 사이트를 목표로 하는 주제이다.

 

 

작업하게된 것들

 

기존의 작년 창업동아리를 진행하면서 기본적인 수강 후기 작성에 관한 기능과 학생들에 관한 정보들을 관리하는 기능들은 만들어 두었으나, BITS 사업에 연결짓기 위해서는 타대학들 간의 테마가 변경가능하기 위해서 UI 리뉴얼과 타대학 강의정보들의 데이터들이 스위칭 가능하기 위한 데이터 모델 변경 및 도메인 수정이 필요한 상황이었다.

 

이렇게 된 김에 12월에 스프링을 시작하며 개발해둔 코드들이 단일 책임도 제대로 이루어지지 않았고, 계층 구조 간의 역할이 엉켜있었는데 문제들을 체크하고 리팩토링을 진행해야 겠다고 생각했다.

 

이 대회에서는 비즈니스 모델과 수익화에 대해서 멘토링을 받게되었었는데 이때 AI 모델을 도입해서 추가서비스를 하자는 계획도 나왔다.

게다가 나는 텍스트 필터링 AI, 프롬프트 AI를 접목시켜 강의 마다의 작성된 수강후기들의 키워드들을 추출하여 분석하고 강의마다 키워드별로 특징을 뽑아 차트에 보여줄 수 있도록 데이터를 선별하여 프롬프트 요청 응답을 작동하도록 하는 기능을 만들어야 했다. 또한, 수강 후기를 작성할때 욕설관련한 단어들을 작성하지 못하도록 텍스트 필터를 거칠 수 있도록 서버를 따로 구축해야했다. 하지만 시간이 부족할 것 같아서 추후 계획에 포함하여 ppt를 작성하였다.

 

기존의 API 서버에 통합해서 작성시키기에는 프롬프트는 텍스트 리소스가 많은 상황이었고, 따로 구축해서 디비도 따로 관리하는 것이 리소스가 분리도 되고 데이터 관리도 어떻게 보면 기존 도메인들에게 update 될일도 없어서 좋다고 생각했다.

 

 

첫째날~둘째날

낮에는, 오기전에 생각해두었던 리팩토링 내역과 문제점들을 todo로 빠르게 정리하고 리팩토링에 들어갔다.

 

리팩토링전 도메인들

 

카멜케이스, 스네이크 케이스가 준구난방하게 사용되어있고, 축약 네임도 존재한다. 필요없는 관계를 맺은 엔티티도 보였다. 필요없는 관계들을 제거하고 엔티티들을 명확히 다시 정의하였다.

 

리팩토링후 도메인들

 

기존의 User 정보는 유지

ClassReview : 강의 후기를 관리

Likes : 강의 후기의 좋아요

Lecture : 강의 고유 정보

LectureType : 교양 필수, 교양 선택, 전공 필수, 전공 선택

Professor : 교수

ClassList : 학기마다 개설된 강의 

ImageUrl : 이미지 링크 관리

UserClassList : 학기마다 해당 학생이 수강한 강의

Authority : 해당 계정이 학생인지 교수인지 관리

 

이후, 제일 문제였던 부분은 Controller 였다. 리팩토링전의 Controller 개발 상황은 정말 부끄러울 정도의 상태였다.

리팩토링 전 ReviewController

 

당시에는 돌아만 가면 된다는 생각에 JSON 모양을 만들어준다는 simple json 라이브러리를 사용하여 어떻게든 프론트가 원하는 응답 form을 맞추려고 하였다.

 

하지만 이렇게 개발해두었더니 가독성이 너무 최악이었다. 후에 강의 detail 페이지에서 필요한 데이터가 많다보니 수정시 너무 힘들었다.

(내가 짠 코드인데 분명히...)

 

게다가 Controller에서 데이터 인자값 form 처리들을 전부 하고있다보니 Controller의 코드 줄이 굉장히 많았고, Controller의 역할을 넘어선 상황이었다.

 

Review에 대한 DTO 작성

 

먼저, Controller에서 처리하는 데이터 form에 대해서 역할을 맡을 dto를 작성하였다. 프론트가 받고자 하는 데이터들은 정해져 있었기에 엔티티 코드에서 바로 dto 객체를 생성하여 반환하기 좋은 정적 팩토리 메서드 방식으로 처리하도록 하였다.

 

Service 전체 조회 메서드

 

또한 Service 코드에서 해당 팩토리 메서드로 바로 변환하여 리턴하는 식으로 처리하였고

 

리팩토링 후 Controller

 

이후 응답값을 바로 반환하는 Controller가 탄생하게 되었다.

 

 

또한 프론트가 원하던 응답 form을 맞추기 위해서 최종 반환은 status, server, data로 나누어서 반환하도록 하였다.

리팩토링 전 반환 class

 

 

리팩토링 후 반환 class

 

타입을 좀더 명확히 하였고, data 자리에 어떤 타입이 들어와도 사용되도록 허용하는 것에서 T 로 처리하였다.

 

다른 Class들에도 똑같은 문제점들이 있었기에 이러한 부분들을 체크하여 다시 코드를 작성하였다.

 

로그인 기능 개선

원래 로그인 후 token을 직접 util 방식으로 발급하도록 하였는데, 데이터베이스에도 따로 관리되고 있지 않아서 token이 유출되어 도용되었을 경우를 생각하지 않고 기능을 만들었었다.

 

기존의 학번과 비밀번호를 쿼리를 날려서 탐색하도록 작성한 메서드에 Spring Secutiry의 usernamepasswordToken 와 Security의 검증 아키텍처들을 활용해서 각 api들을 secured 되도록 하고, token을 통하여 로그인 상태에 대한 인증 관리도 security가 관리하도록 하고 싶었다.

 

 

작업 과정에서 UserDetailsService 로직이 수정되어야 하였고 loaduserByUsername 메소드를 오버라이딩하여 학번으로 인증되도록 다시 작성하였다.

참고하였던 Spring Secutiry 인증 인가 아키텍처

 

SecurityConfig를 작성하는데 많은 도움이 되었었고, 후에 무사히 도입할 수 있었다.

 

작업 후 느낀점과 알게된 점

 

클래스의 SOLID 법칙을 지켜서 작성해야 하는 이유에 대해서 명확히 다가오게 되었고, class 마다의 역할과 책임은 하나가 되어야 한다는 것에 대해서 Controller 로직을 수정하며 훨씬 절실히 와닿았다.

 

소프트웨어공학에서 배우던 이론들에 대해서 작업을 하며 메소드 간의 결합도도 생각하며 분리하여 작성하는데 도움이 되었고, 앞으로 개발을 위한 추가적인 공부에 동기를 증가시키는 좋은 경험이었다!

 

팀원들 명찰샷