[프로젝트 회고] 1차 프로젝트를 마치며

 약 6~7주 간 2022.01.09 ~ 2022.02.17 + (~ 2022.02.22) 팀 프로젝트를 진행했다. (기획부터 발표까지 다 포함) 개발하러 온 6명이서 기획부터 디자인, 설계, 개발, 발표까지 다 해야 돼서 힘들었고 빡빡한 일정이었다.

 

 프로젝트를 하는 동안 여러 일들이 있었고 힘들었다. 하지만 프로젝트를 무사히 마치고, 수상까지 하게 되며 유의미한 결과를 만들어 낸 것 같아 뿌듯하다.

 

 정신없이 개발하느라 중간중간 기록을 하지 못했다. 그리고 프로젝트 끝나고 힘들었던 점이나 아쉬웠던 점들이 망각되기 시작한다. 그래서 잊어버리기 전에 지난 6~7주 간의 프로젝트 과정을 돌아보고자 한다.

 

 

 

 

 

📢 프로젝트 소개

• 프로젝트 인원 : 6명 (프론트엔드 3명, 백엔드 3명 (백엔드 1명이 인프라도 함))
• 프로젝트 : 소셜 운동 모임 매칭 서비스
• 깃허브 링크 : 링크 내림
  
  
• 협업 : GitLab, Jira,  Notion, Mattermost, Webex, Discord
• 기술 스택
  • Frontend : React, Redux, Tailwind, Typescript
  • Backend : Spring Boot, Spring Cloud, JPA, MySQL, Websocket, Redis, Oauth2
  • Infra : AWS EC2, Docker, Jenkins, Nginx

 

 

 

 

 

👩🏻‍💻 나의 역할

• 백엔드 개발 (Spring Boot, JPA, MySQL, Feign Client)
• DB 설계/구축
• PPT 담당

 

 

 

 

 

🚩 프로젝트 과정

1. 기획

 우리 팀이 선택한 트랙이 웹디자인인 만큼 UX/UI적으로 보이는 것이 있어야 했고, 웹RTC를 선택한 다른 팀과는 다른 기술적 차별점을 줬어야 했다.

 

 처음 제대로 된 기획이 나왔다. 점점 구체화를 할수록 내가 대학에서 팀 프로젝트로 했던 기획과 유사해져 갔다. 팀원들도 포트폴리오가 겹칠 것을 우려했지만 나는 기술적으로 다른 차별점이 있다면 괜찮을 거라며 진행을 하고, 컨설턴트님께 컨펌을 받으러 갔다. 하지만 컨설턴트께서 겹치는 주제의 포트폴리오는 나중에 면접에 가면 불리해진다는 답변을 주셨다. 그리고 기술적 구현도나 개발량이 적다는 피드백을 받았다. 그래서 기획을 갈아엎고 다시 시작했다.

 

 그렇게 거의 2주차까지 기획을 하게 되었다. 기획을 빨리 해야 개발 기간을 많이 가져갈 수 있는데, 도무지 기획이 안 나와서 팀원들 모두 지쳐갔다. 기획이 이렇게 어려운 줄 몰랐다. 빨리 개발을 시작하고 싶은 마음이었다.

 

 첫번째 기획의 주제에서 방향성을 바꿔, 한 팀원의 개인적인 경험을 바탕으로 한 기획이 나왔다. 운동 모임 서비스이다. 개인들이 운동 모임을 할 수 있도록 중개해 주고, 팀을 꾸려 지속적으로 팀들 간 경기를 할 수 있도록 도와주며, 실시간 채팅, 자동 매칭, 팀 통계까지 지원하는 서비스이다.

 

 컨설턴트님께 프론트와 백으로도 기술의 구현도나 개발량이 많다는 조언도 받았다. (프론트+백 합이 100이라고 쳤을 때, 우리 프로젝트는 프론트 70, 백 70, 도합 140의 프로젝트였다😱 야근 필수요..)

 

 

 

 

 

2. 설계

 우리 프로젝트는 실시간성이 강하기 때문에 서비스를 모바일로 많이 이용할 것 같아, 웹앱으로 구동하기로 했다. 웹앱에 맞게 모든 설계를 했다.

 

 프론트를 맡게 된 팀원들은 피그마로 디자인 및 UX/UI 설계를 하고, 백엔드를 맡게 된 팀원들은 기능명세서 작성, 아키텍처 설계, ERD 설계, API 설계를 했다.

 

 

 

• 피그마

 다들 디자인과는 먼.. 공대 출신이지만, 꼼꼼하게 설계를 잘했다. 평소 토스 어플을 자주 쓰고 개인적으로 UX/UI가 직관적이고 깔끔하다고 생각하는데, 토스 어플을 참고하며 디자인과 UX/UI 설계를 했다. 페이지 수도 엄청 많다! 백엔드 설계하다가 지루해질 때쯤 중간에 나도 일부분(회원가입 페이지, 마이페이지 일부) 참여했다.컨설턴트님께 프론트는 이대로 개발만 시작하면 된다며, 프론트 설계가 훌륭하다는 평을 들었다.

 

 

근데 백엔드 설계는? 프론트에 비해서는 꼼꼼하지 못하다는 평을 들었다..

 

 백엔드에서 구조적으로 많은 시도를 했어야 했다. 백엔드 서버를 모놀리틱이 아니라 MSA 구조를 쓰게 되었고, CI/CD를 도입해야 됐다. 아무도 이전에 이런 구조로 프로젝트를 진행해 본 적이 없어서 특히 아키텍처 설계에 애를 먹었다. 

 

 

 

• 기능 명세서

Notion에 작성을 했다

 

UX/UI 설계를 보며 작성을 했다. 이때 프론트 팀과 기획을 한 팀원과 많이 소통을 했어야 했다. 큰 기능별로 Epic를 나눴으며, 화면과 컴포넌트, 세부 기능별로 항목을 나눠 작성했다.

 

 

 

• ERD

ERD Cloud에서 작성한 초기 설계 / 최종 ERD

 

 처음에는 ERD Cloud에서 설계를 했다. 설명도 넣을 수 있고, 협업 기능도 있어서 동시 편집도 가능하고 좋은데.. FK 제약조건을 설정하는 부분에서는 불편했다. 제대로 표시가 안된다. 그래서 나는 익숙한 MySQL Workbench로 갈아타서 여기서 설계를 했다. 어차피 나중에 DB 구축도 해야 하니까..

 

 1차로 ERD 설계한 거를 가지고 컨설턴트님께 갔을 때 Table들을 좀 더 쪼개라는 조언을 들었다. 자주 업데이트 되는 정보와 업데이트되지 않는 정보를 나눠서 저장하는 것이 좋다고 하셨고, 여러 곳에서 공용으로 가져다 쓰려던 Table은 굳이 통합하지 않고 나눠서 쓰는게 좋다라고 하셨다.

 

  ERD는 개발하면서 추가되는 부분이나 변경되는 부분이 생기면서 많이 바뀌었다. 이건 예상했지만 개발 과정에서 DB를 얼마나 변경하고 재구축했는지 모르겠다..

 

 

 

• 아키텍처 설계

아키텍처 설계 최종본

 

 Infra를 담당하는 다른 팀원이 설계를 했다. MSA로 설계를 하는데, 처음 해보는 거라 애를 먹으셨다고 했다. 이때 나는 개인적인 사정으로 참여를 못 했어서 아키텍처 구조에 대한 컨설턴트님의 조언을 못 들어 아쉬웠다. 그래서 개발 초반에 구조를 이해하는 데 애를 먹었다.

 

 MSA를 Spring Cloud(API Gateway, Eureka)를 활용하여 설계했다. 그리고 서비스를 큰 기능 단위로 분리하여 크게 6개의 마이크로 서비스로 나눴다. 배포를 위해 Genkins와 Docker를 활용하여 CI/CD를 구성했다.

 

 

 

• API 문서

 

 그동안 나는 프로젝트를 진행하면서 문서까지 쓰며 API 설계를 해본 적이 없었는데, 이번 프로젝트에서는 미리 기능별로 필요한 모든 API들을 정리하니 개발하는 데 유용했다. 각 서버 및 기능별 구현해야 할 API 분량을 알 수 있었고, 문서대로 Controller 구현에 바로 들어갈 수 있어서 좋았다.

 

 나는 서비스의 주요 기능 부분 API 설계를 맡았었다. 프로젝트가 진행됨에 따라 추가기능들을 내가 맡게 되면서 총 약 40개에 달하는 API 설계를 하게 되었다! 이것도 ERD처럼 개발하면서 계속 바뀌는 부분이었다.

 

 

 

 그 외에 시퀀스 다이어그램도 그릴 수 있었지만, 우리 팀이 기획을 늦게 해서 더 이상 개발 시작 시간을 늦출 수 없어서 그리지 않았다.

 

 

 

 

 

3. 개발

 드디어 개발 시작인 것인가..? 중간에 설연휴도 끼여있고, 바로 중간발표가 있어 나는 PPT를 만들었어야 해서 개발 시작일이 늦춰졌다. 1월 27일까지 PPT를 수정하느라 개발을 제대로 시작하지 못했다. 그렇게 나의 개발 기간은 3주 + (추가 2~3일)였다. 전체적으로 기획, 설계, 발표 준비 때문에 개발 기간이 줄어들고 있었다😭 그래도 최종적으로는 어찌어찌 내가 맡은 백엔드 서버 개발을 거의 다했다.

 

 

 

 우리 프로젝트의 기능을 크게 나누자면 다음과 같다.

• 회원 관리 / 인증
• 알림 기능
• 실시간 채팅
• 실시간 운동 모임 / 일반 운동 모임
• 팀 경기 / 팀 통계 / 팀 경기 자동 매칭

 

 

 백엔드에서 1차로 각각 회원 관리/인증/알림, 실시간 채팅, 실시간 운동 모임 & 일반 운동 모임을 맡아 개발하기로 했다. 일단 팀 관련 기능은 2차로 나눠서 개발하기로 했다. 나는 1차로 실시간 운동 모임과 운동 모임을 맡게 되었다. 그래서 실시간 지도 페이지를 만드는 프론트 1명과 운동 모임 페이지를 만드는 다른 프론트 1명과 협업을 하게 되었다. 

 

 결국 최종적으로는 나는 실시간 운동 모임, 운동 모임, 팀 경기 / 팀 경기 자동 매칭, 팀 통계 기능을 맡아 개발을 했다. 다른 백엔드 1명은 CI/CD와 Flutter, Firebase 구축 때문에 바쁘셨고, 다른 백엔드 1명은 실시간 채팅 기능 구현에 시간이 오래 걸리게 되었다.

 

 

 

 

 

내가 개발하면서 겪은 이슈나 기술적 특징이다. 

 

• Swagger

 내가 만든 서버 API를 연결할 프론트 개발자와 소통하기 위해 Swagger를 사용했다. 지난 프로젝트에서도 Swagger를 사용해본적이 있어서 쉽게 붙일 수 있을 줄 알았다.. 근데 아무리 해도 Swagger가 붙지 않았다. 이유는 Spring Boot의 버전이 Swagger와 맞지 않아서였다. 처음에 프로젝트를 생성할 때 Spring boot 3.0.2 버전으로 했다. 결국 Swagger를 쓰기 위해 더 늦기 전에 Springboot 2.7.8 버전으로 바꿨다.

 

 Swagger를 사용하니 프론트 개발하는 팀원과 어떤 형식으로 data를 주고받아야 하는지 소통하기 편했다. 그리고 Swagger에서 테스트를 해보기도 편했다.

 

Swagger Controller

 

 

 

• JPA

 학부 프로젝트에서 Mybatis로 구현한 부분을 JPA로 전환하는 리팩토링을 수행하며 JPA를 써본 적이 있었다. 그래서 그때 하던 대로 이번에도 프로젝트에도 적용하려 했었다. 당시에는 Oracle DB를 썼고, 조인되는 객체들을 단방향으로 매핑을 했었다.

 

 하지만 조인으로 엮여있는 테이블들을 같이 INSERT, DELETE 하는 과정에서 문제가 발생했다. 자동증가된 ID 값을 알지 못하는 것이었다. Oracle에는 Squence가 있어서 자동증가된 ID 값을 알 수 있어서 단방향으로도 INSERT에 문제가 없었다. (Oracle에 익숙했던 나는 MySQL에 Squence가 없는 줄 몰랐다..)

 

 해결을 하기 위해 구글링을 한 결과 양방향으로 매핑을 하면 쿼리 한 번만으로 한 번에 INSERT를 수행할 수 있다고 했다. 기존 Entity를 뜯어고쳐 양방향으로 매핑을 하게 되었다. 하지만 양방향 DELETE 과정에서 문제가 발생하게 되었다. 양방향으로 매핑이 되어있어 순환 참조가 발생했다..😭 이거 해결하기 위해서 구글링을 엄청하며 JPA 관련 Annotation과 옵션들을 엄청 찾아봤다. 이전보다 JPA에 대해 더 공부를 하게 된 기회가 되었다.

 

 

 

• MySQL 이벤트 스케줄러

 게시글을 등록한 지 30분이 지나면 자동으로 삭제가 되게 해야 했었다. MySQL에서 이벤트 스케줄러를 써서 DB에서 주기적으로 자동으로 삭제를 수행하도록 했다. 이벤트 스케줄러를 처음 써봐서 스케줄러 문법을 이해하고 내가 원하는 이벤트를 만드는 데 애를 먹었다.

 

delimiter |
CREATE EVENT delete_live
    ON SCHEDULE
        EVERY 10 SECOND
	ON COMPLETION PRESERVE
    ENABLE
    COMMENT '등록 후 30분이 지나면 삭제'
	DO
	BEGIN
		delete m
        from live_member m join live l
        on m.live_id = l.live_id
		where TIMESTAMPDIFF(MINUTE , l.regist_time, now()) >= 30;
        
		delete from live
		where TIMESTAMPDIFF(MINUTE , regist_time, now()) >= 30;
	END 
| delimiter ;

 

 

 

• HTTPS

 프론트엔드에서 지도 API를 쓰는데 HTTPS로 통신해야 하기도 하고, 보안성을 위해 모든 API 호출을 HTTPS로 통일하기로 했다. 프론트엔드와 HTTPS로 통신할 수 있게, 백엔드 서버에서 SSL 인증서를 받아 별도로 설정해야 됐었다. 덕분에 SSL 인증서 발급 과정과 SSL이 적용되는 과정에 대해 공부하게 되었다.

 

 

 

• CORS

 프론트엔드 팀원이 내가 구현한 로컬 서버 API와 연결하던 중 CORS 에러가 났다고 알려줬다. 원인을 찾아보니 브라우저에서 보안적인 이유로 cross-origin(도메인 또는 포트번호가 다름)의 요청을 제한한다고 한다. 프론트엔드의 React 서버의 주소는 localhost:3000인데, 백엔드의 서버의 주소는 localhost:8080으로 둘의 서버의 포트번호가 달라서 발생한 일이었다. CORS를 해결하는 방법으로 백엔드의 스프링 서버에서 WebMvcConfigurer를 추가해야 한다. Allow-Origin을 설정하여 해결할 수 있었다.

 

 

 

• ELO 알고리즘

 비슷한 수준의 팀과 경기를 할 수 있도록 롤, 피파랭킹 등에서 많이 쓰는 MMR 시스템을 도입했다. MMR의 대표적인 알고리즘인 ELO 알고리즘을 써서 경기를 할 때마다 점수를 산정했다. 점수가 높은 팀을 만나서 이기면 많은 점수를 얻게 되고, 점수가 낮은 팀을 만나서 지면 많은 점수를 잃게 된다.

 

 경기 결과를 등록하면 정해진 수식에 맞게 계산해서 포인트를 증감하도록 했다. 시스템과 알고리즘을 이해하고 코드로 구현하는 것이 재미있었다. 또한 이와 연결시켜서 팀별 통계를 뽑는 기능 구현도 했다.

 

//1. 예상 승률 구하기
int Pme = teamMe.getPoint();
int Pop = teamOp.getPoint();

double Wme = 1.0 / (Math.pow(10, ((Pop - Pme) / 400)) + 1); //내 팀의 예상 승률
double Wop = 1.0 / (Math.pow(10, ((Pme - Pop) / 400)) + 1); //상대 팀의 예상 승률

//2. 점수 계산하기
int K = 30; //가중치
double W = 0; //경기 결과

//경기 결과 별 W
String resultMe = teamMatchResultMe.getResult();
String resultOp = teamMatchResultOp.getResult();

W = getW(W, resultMe);
Pme += (int)(K * (W - Wme));

W = getW(W, resultOp);
Pop += (int)(K * (W - Wop));

//3. 팀 객체에서 점수 정보 갱신하기
teamMe.setPoint(Pme);
teamOp.setPoint(Pop);

 

 

 

• 매칭

 ELO 알고리즘으로 계산된 팀의 점수를 바탕으로 매칭 조건에 맞는 비슷한 수준의 팀을 매칭시키는 기능을 구현했다. 까다로울 것 같아서 가장 마지막에 구현하게 되었다. 매칭 시스템 구현에 대해 많이 찾아봤는데, 주로 Redis를 사용하여 대기열을 구현한다고 했다.

 

 프로젝트 마감이 얼마 남지 않아서 MySQL DB에 '대기방'이라는 테이블을 만들어서 대기열을 만들었고, 대기열 내에서 사용자가 원하는 조건의 매칭이 될 때까지 계속 탐색하도록 했다. 대기열에 넣고, 대기열을 조회하고, 대기가 길어지면 조건을 완화하고, 매칭되면 대기열에서 삭제하고, 경기에 등록하고, 상대방 팀 정보 반환하게 하고.. 알고리즘적으로 신경을 많이 썼어야 했다.

 

 구현을 하긴 했지만 Redis가 아니라 RDB로 구현을 하게 되어서 찝찝했다. 나중에 시간이 나면 Redis로 바꿔보는 작업을 해보고 싶다.

 

 

 

 

• FCM 알림

 매칭이 완료되면 매칭이 된 사용자들에게 매칭된 상대방의 정보와 함께 매칭이 완료되었다는 알림을 보내주는 기능을 구현했다. 메시지의 형식에 맞게 다른 팀원이 구축한 FCM 서버로 Json 형식으로 알림을 보냈어야 했다.

 

 FCM이라는 객체를 만들어서 객체에 알림에 필요한 제목, 내용, 유저 토큰 리스트, data (String의 map)를 담아서 보내기로 했다. data에는 매칭된 유저들에게 보내줄 각각 다른 팀의 정보를 넣어야 했다. data를 String으로 변환하기 위해 Gson 라이브러리를 이용해 Json형식의 String으로 바꿨다.

 

 

 

• OpenFeign

 팀을 생성하면 채팅방이 만들어지도록 했어야 했다. 하지만 MSA 구조로 채팅 서버가 따로 나뉘어져 있어서 어떻게 채팅서버의 Service를 사용을 하는지 궁금했다. MSA 구조에서 다른 서버의 서비스 사용을 알아보다가 OpenFeign에 대해 알게 되었다.

 

 Feign Client 라이브러리를 이용해서 FeignClient interface를 만들어서 채팅 서버 RestController의 필요한 메소드들을 가져왔다. 그리고 Service에서 FeignClient interface를 불러 필요한 비즈니스 로직을 작성하여 채팅 서버의 api를 호출하도록 했다.

 

@FeignClient(name = "chat", url = "https://")
public interface ChattingServiceClient {

    @PostMapping("/GatheringChatRoom")
    String createGatheringChatRoom(@RequestBody Map<String, Object> map);

    @PostMapping("/TeamChatRoom")
    @Headers(value = "Content-Type: application/json")
    String createTeamChatRoom(@RequestBody Map<String, Object> map);
}

 

 

 

 

 

• Builder 패턴

 

 

 

 

그 외

• 에자일, 스크럼 & Jira

 소프트웨어 개발 방법론에서 들어보기만 한 에자일, 스크럼 방식으로 처음 프로젝트를 진행하게 되었다. 그리고 프로젝트 계획과 진행 상황을 관리하기 위해 Jira를 썼다. 1주일 단위로 계획을 세워서 이슈를 생성하고 스프린트를 진행했다. 나는 이번 프로젝트에서 처음 Jira를 쓰게 되었다. 처음에는 Jira를 쓰는 게 익숙하지 않았고 귀찮았지만, 해야 할 일을 생성하고 진행 상황을 관리할 수 있어서 편리했다.

 

 

 

• 해킹

 우리 팀은 해킹을 2번이나 당했다! 유추하기 쉬운 서버 url과 계정 ID와 패스워드 사용이 문제였다. 처음 해킹을 당했을 때는 DB가 초기화되 있었고, 해커가 비트코인을 내놓으라고 했다. 결국 AWS와 연결된 모든 계정과 비밀번호를 초기화를 시켜줬다.

 

 하지만 서버가 또 털렸다.. 심지어 발표 당일 새벽에😭 당장 몇 시간 후에 프로젝트 결과 발표할 때 실시간으로 시연해야 하는데 서버가 터져서 안 돌아가고, 우리의 멘탈도 터지고 난리가 났었다.

 

 서버 복구와 해킹 대응을 위해 CI/CD 하는 팀원이 고생을 했다. 오히려 해킹당해서 이를 위해 대응을 했던 게 어필 포인트가 될 수 있다는 조언을 들었고, 진출한 전국 발표회에서 어떻게 해킹에 대응했는지를 기술 포인트 중 하나로 이야기를 하게 되었다.

 

 

 

 

 

4. 발표

 우리 팀은 프로젝트 기간 동안 중간발표, 최종 발표, 전국 발표회 총 3번의 발표를 했다. 중간 발표 때는 기획과 설계한 내용들 위주로 발표했고, 최종 발표와 전국 발표회에서는 기획 배경, UCC와 함께 개발 기술과 시연을 위주로 발표를 하게 되었다.

 

 기획 배경을 우리 서비스의 주요 기능과 연결 지어서 간결하게 전달하려고 했고, UCC에서도 우리의 서비스가 필요한 이유를 보여줬다. 그리고 우리 프로젝트가 다른 팀의 프로젝트와 차별점을 줄 수 있는 부분은 기술이라고 생각해서 기술을 설명하는 부분의 비중을 많이 줬다.

 

 최종 발표 당일 새벽에 해킹을 당했기 때문에 실시간 시연이 불가능하여 로컬에서 각각의 기능들을 개별적으로 영상으로 남겨 시연을 하게 되었다.. 전국 발표회를 위해 서버를 복구하여 라이브 시연을 할 수 있게 유지보수를 진행했고, 발표에서는 다른 부분을 더 줄이고 기술을 설명하는 부분을 더 늘리게 되었다.

 

 발표 준비를 위해서 팀원들이 고생을 정말 많이 했다. 발표자와 시연자는 시나리오를 짜서 계속 연습을 했고, 나는 PPT 계속 보완하고, CI/CD 하는 팀원은 서버 계속 보고 있고.. 컨설턴트님과 코치님들께서도 계속 발표 피드백을 주셨다. 덕분에 점점 발전시킬 수 있었고 발표날은 최고의 상태로 발표하게 되었다.

 

 

 

 

 

 🎉 결과

 최종적으로 반 1등으로 우수 프로젝트에 선정이 되어 수상하게 되었다😀 최종 발표에서 해킹을 당한 탓에 영상으로 시연을 하게 되어서 수상이 어려울 수도 있겠다는 생각이 들었는데, 프로젝트 기술 부분을 좋게 봐주셔서 반에서 순위권 안에 들어 전국 발표회에 진출하게 되었다. 우리 프로젝트를 전국의 여러 사람들 앞에서 발표하는 좋은 경험도 하게 되었다.

 

 

 

 

 

📖 배운 점 / 느낀 점

 지금까지 여러 프로젝트를 진행했지만 이번 프로젝트가 가장 기억에 남을 것 같다. 팀원들이랑 단기간에 정말 많은 것들을 했다. 매일 점심마다 같이 운동도 하고, 프로젝트 막바지에는 밤늦게까지 카페에서 작업도 하고, UCC도 찍고, 발표 준비도 하고, 수상도 하게 되고.. 결국 포트폴리오로 쓸만한 부분도 나온 것 같고, 개발 외적으로도 느낀 점들도 많다.

 

 

• 포기하지 않고 열심히 하면 된다

 우리가 구현해야 될 분량이 많았어서 다 구현할 수 있을까 생각도 들었지만, 다들 프로젝트 완성이라는 목표를 가지고 열심히 하니 결국 완성을 할 수 있었다. 프로젝트 막바지에는 저녁마다 24시간 카페에 가서 늦은 시간까지 작업을 했다. 심지어 발표 당일에는 밤을 세서 6시까지 작업하다가 다시 통학하고.. 해킹을 당해서 서버가 나갔을 때는 다들 멘탈이 나가고 밤을 세서 체력도 바닥났지만, 멘탈 붙잡고 되는 거라도 한 팀원들한테도 고마웠다. 그리고 최종 발표 이후 바닥난 체력에도 불구하고 전국 발표회를 위해서 프로젝트를 더 연장시켜서 유지보수에도 참여하고, 발표 연습에도 같이 참여를 한 팀원들에게도 고마웠다. 우리 팀이 수상을 한 것은 포기하지 않고 열심히 한 결과라고 생각한다.

 

 

 

• 성장하고 있다

 개발하면서 중간에 막히는 부분도 있었지만 문제를 해결하기 위해 고민하고 찾아보는 과정에서 나 스스로도 성장하고 있다는 게 느껴졌다. 아직은 부족하지만 이전보다 더 구조를 고민하며 코드를 짜려고 했고, JPA 개념도 더 익히게 되었고, MSA 등 새롭게 적용하는 부분들도 있어서 배워가는 것이 많았다.

 

 

 

• 리팩토링 하고 싶다

 그럼에도 불구하고 코드와 구조가 마음에 들지 않는 부분이 존재한다.. 특히 개발 후반으로 갈수록 기능이 돌아가게 하는 것에 급해서 깔끔한 코드와 구조에서 멀어져 갔다. 바꾸고 싶은 부분들이 존재하지만 먼저 개발한 부분과 연결되어 있어서 고치기가 힘들기도 했다. 처음부터 설계를 잘하거나 아키텍처나 클린 코드에 대한 것을 더 공부해서 깔끔하게 구조와 코드를 짜도록 해야겠다는 생각이 들었다. 

 

 

 

 

 

📖 아쉬운 점

• 테스트 코드

 테스트 코드를 작성하면서 개발을 진행하고 싶었는데, 결국 못했다. 일단 TDD와 테스트 코드 작성에 익숙하지 않은 것이 문제였다. 3주라는 짧은 개발 기간에 많은 분량을 개발해야 하는 상황에서 테스트 코드 작성에 시간을 쏟을 여유가 없었다. 테스트 코드 작성보다는 빠르게 로컬 환경에서 자체적으로 API 테스트를 하게 되었다. 결국 평상시에 공부를 하고, 테스트 코드를 작성하는 습관을 들여야 함을 깨닫게 되었다..

 

• Redis 사용