[Java|Spring|JSP] Koala 출석부 제작 후기 ..그리고 보완 방향!

[KAU 알고리즘 동아리 출석부] Koala-Attendance-Server 

깃허브 주소 https://github.com/kauKoala/Koala-Attendance-Server
웹 주소 https://koala-server-7djnmif25q-an.a.run.app/main

✍️ 소개

코알라 동아리에서 스터디를 운영할 때, 운영자들이 출석부를 작성하기 위해 카카오톡 창을 하나씩 확인해야 하는 불편함을 해소하고자 만든 출석부 자동화 서비스이다. 
한 달 간 거쳐서 프론트와 백을 담당해 만들게 되었고, 목표는 사실상 스터디 전 1월 초까지였으나 인턴,, 대회,, 지원,, 등등 여러 이슈로 목표 안에는 끝내지 못했다. 그래도 빨리 마무리 완료 !
 

✍️ 아키텍처

ERD
ERD는 아래와 같이 설계되어있다. 크게 스터디, 그 스터디가 진행되는 주(리스트 형태), 그 스터디에 참가하는 학생, 푼 문제/쓴 tistory 글 로 이루어져 있다.

사용 기술 및 배포 파이프라인
사용 기술은 Java Spring + JSP 라는 극악 조합(?)을 사용하였고 아마 매년 이용하지 않을까 싶어 DB는 저렴한 것들을 사용하게 되었다. 
추가로 서버와 Lambda 함수 모두 굳이 계속 가동시켜둘 필요가 없기 때문에 serverless 로 설계해서 더 비용이 저렴하게 나간다.  

 

💖결과

그래서 뭘 만들었는데!? 라고 한다면 아래 4가지 페이지로 설명할 수 있다. (프론트 디자인은 ..더이상 말하지 않겠다. 일단 여기선 중요하지 않다.!!!)
1. 메인 page
메인 페이지에서는 현재 운영 및 모집 중인 스터디를 알 수 있다. 이 때 학기 기준은 현재 년도 와 학기를 자동으로 가져온다. 아래와 같은 기준으로 학기 별로 페이지의 모든 부분들이 해당 학기별로 반영된다. 

• 1학기 - 3.1 ~ 6.20
• 여름방학 - 6.20 ~ 9.1
• 2학기 - 9.1 ~ 12.20
• 겨울학기 - 12.20 ~ 2.28)

main page

2. 등록 page
학생과 스터디를 등록할 수 있다. 학생의 백준 및 티스토리 이름은 각 플랫폼에서 가입 시 기입했던 이름을 적어주면 된다. 예를 들어 나의 경우에는 (전영서 / 20wjsdudtj / jeonyoungseo)로 등록해주었다.
스터디는 여러 스터디 시작주차들을 추가해준 후 이름과 소개를 넣어서 등록해주면 된다.

등록 page

3. 참가 page
학생들을 스터디에 추가하거나 뺄 수 있다. 코딩테스트 스터디를 하다가 갑자기 스터디를 기초로 옮기고 싶다고 하는 학생들은 기존 스터디에서 삭제 후 새로운 스터디에 추가 해주면 된다.
이 때 학생은 여러 명 선택 가능하고, 스터디는 한 개만 선택 가능하도록 짜여 있어 동시에 여러 학생들을 한 스터디에 넣을 수 있다.

참가 page

4. 출석부 조회 page
년도와 학기를 순차적으로 선택하면 학생 별, 주차 별 출석도 내역을 볼 수 있다. 각각 백준 / 티스토리 출석부를 의미하며 백준은 푼 갯수가, 티스토리는 포스팅 유무가 기입된다. '-' 로 표기된 내용은 아직 해당 history가 업데이트되지 않았음을 의미합니다. 
아래 사진은... 백준 쪽을 1주차 테스트를 아직 못 해봐서 ( 내 설계 가 늦은 탓..) 0으로 기입된 모습이다. 😅
티스토리는 '이번주에 푼 문제'가 기입되지만, 백준은 '지난 주 대비 이번주에 푼 문제'가 기입되는 아키텍처라 백준은 스터디 시작 전날 한 번 더 크롤링을 해두어야 한다는 차이가 있다.
우선 티스토리는 크롤링한 것들이 잘 반영되는 것을 볼 수 있었다.

급하게 1월15일에 열심히 백준 2문제를 풀고 2주차를 1월 16일로 할당한 후 테스트해보았다. 1월 16일 00시로 lambda가 돌 수 있도록 설정하고 다음날 확인해보니, 내가 2문제 풀었다는 사실이 아주 잘 반영되었음을 확인할 수 있었다. 완뵥해 ✨ 

---

🏃 개선점들

역시 대부분의 코딩러들이 그러하듯, 설계 도중 아쉬운 부분들이 많았다. 구현이 늦어진 이유도 이러한데, 의식적으로 미리미리 '이런 일이 일어날 수 있을거야' 라고 생각하면서 짜는 것이 쉽지 않았다. 그래서 이번에 구현을 하게 되면서 어떤 점들이 아쉬웠는지 계속 적어보며 진행했다.
1. Null 체크
Java Spring에서는 Null 체크를 컴파일 시점에서 잡아주지 않기 때문에 예외들을 복잡하게 처리해주어야 한다. 이 과정은 어렵지 않지만 문제는 코드가 너무 더러워졌다는 것이다.

코드에도 수정 필요 !! 라고 써두었는데 Optional<>로 가져오는 객체를 .get()으로 꺼내는 이 과정이 코드 유지보수 측면에서 좋지 않은 것 같아 Null 체크 코드 부분을 좀 더 개선해볼 필요가 있다.
2. 추상화 - 비슷한 것은 모아버려
앞에 main 페이지에서 말한 것처럼 현재 년도/학기 부분은 모든 곳에서 다 쓰인다. 이 코드를 한 쪽에 몰아두고 호출하는 방식을 택했다.

물론 ! 좋은 설계 방식이지만, 비슷한 부분은 모아서 추상화하여 상위 계층으로 빼서 공통적으로 사용하는 설계 방식을 생각했으면 어땠을까 생각된다.
3. private / public
2번과 같은 맥락으로 private와 public을 사용할 때 특별한 의도 없이 구현하였다. public 남발.. 이후 이펙티브 자바에서 이런 내용을 접해보게 되었고, 접근 제어자에 대해 좀 더 이해하고 짜면 좋았겠다고 생각했다.
4. 병렬처리로 여러 처리를 한 번에
Lambda 함수로 백준/티스토리 별로, 여러 스터디들을 돌리게 되는 과정에서 타임어택이 생각보다 중요했다. (AWS lambda 함수는 최대 15분까지만 돌릴 수 있도록 제한이 주어져 있다.) 
따라서 백준 lambda 함수 결과를 api로 받아오는 것과, 그 정보를 이용해서 지난달 대비 이번주에 푼 백준 갯수 update하는 함수를 각각 비동기적으로 처리할 수 있도록 하면 어떨가 생각되었다.

호출 / 반환 하고 있는 로직

5. Transactional 처리
아주 부끄럽게도 @Transactional 에 대한 이해도가 아직 떨어진다.. 해당 프로젝트에도 Repository 속 몇 코드를 빼놓고서 적절한 @Transactional 처리를 잘 해보지 못했다.어떤 과정에서, 어떤 클래스 레벨에서 적절히 Transaction을 처리해 ACID를 지킬 수 있을지 생각해보면 좋을 것 같다.
6. TDD 실행
의도치 않은 쿼리 상의 오류를 맞이한 적이 있다. (0~1개의 데이터를 예상하여 Optional<Student> 객체를 사용했는데 2개의 데이터가 나온 이슈) Superkey에 대한 이해가 없이 설계했나 좌절하고 있었는데, 알고보니 테스트 이후 데이터들을 지워주지 않아서 이런 불상사를 맞이한 것이었다.. 그래서 특정 과정 상의 오류들을 잡기 위해 가짜 객체들을 만들고 TDD를 해보면 좀 더 구현이 빨라질 수 있겠다는 생각이 들어 이런 경우에는 TDD를 시도해보고 싶다.!

---

이 외에도 많다,, 웃기게도 JSP 짜는데도 내 프론트 설계가 아쉽더라 😂
시간이 많지 않기 때문에 남은 2달동안 이런 아쉬움들을 반영해서 이건 리팩토링 안해보면 후회막심 나 미쳐 싶은 것만 도전해 보고자 한다 ! 이론적인 학습과 리팩토링 구현과정은 합해서 남겨두도록 해야겠다 ✌