싸피9기 공통 프로젝트 회고록

https://shrub-find-729.notion.site/DAMDA-40c77e946a484272812af82f99c3681d?pvs=4

DAMDA(모두의 타임캡슐 서비스)

 

공통프로젝트였던 DAMDA에 대한 프로젝트 회고록

 

처음으로 백엔드3, 프론트엔드3으로 나누면서 진행했던 프로젝트였다.

백엔드에서는 비전공자가 나 혼자였는데 솔직히 압박감이 너무 심했었다. 내가 1학기에 프로젝트 최우수를 받았다지만 전공자에게 내 백엔드 실력이 만족스러울까? 라는 걱정도 있었지만, 또 막상 한다면 1인분은 최소 해내기 때문에 지금 생각해보면 너무 터무니없는 걱정이었다. 나머지 5명이 정말 실력적으로 괴물들이었어서 진짜 많이 배우고 알아가면서 성장할 수 있었던 프로젝트라고 생각한다.

 

기획

7주의 프로젝트 기간이 주어지면서 1주일을 오로지 기획에 투자했었다.

진짜 다양한 아이디어들이 나왔지만 우리의 도메인은 웹디자인이었기 때문에 유저들의 감성을 자극하고, 디자인적으로 표현할 수 있는 아이이더를 뽑아야했다. 제일 많이 나왔던 건 SNS였지만 아무래도 어플을 만들어야 한다는 점이 큰 압박으로 다가왔기에 내가 제안했던 타임캡슐 아이디어가 채택이 됐다.

초반에 기획은 생각보다 더 볼륨이 컸다. 나는 개인적으로 현실을 중시하기 때문에 너무 큰 볼륨을 잡게 되면 압박감도 커져서 마무리 단계에 들어갈 수록 점점 프로젝트가 불안해진다고 생각이 들었다. 그래서 한계점에 대해 파악을 하는 부분이 필요했지만 제대로 파악하지 못하고 기획을 확정지었던 느낌이 없지않아 있었다.

 

설계

 

관통 프로젝트가 끝나고 1달이 지나면서 DB 설계에 대한 개념이 너무 없었던 상태였다.

그래서 초기 ERD를 전공자 둘이서 거의 끝내놓았으며, 나는 해당 ERD를 해석하면서 추가적인 아이디어를 주고, 나중에는 ERD를 수정하면서 프로젝트를 진행했었다. 이 당시에 ERD 설계에 많은 도움을 주지 못해서 굉장히 미안했지만 개의치 않아했던 팀원들에게 굉장히 고마웠다.

이번에는 요구사항 정의서와 인터페이스 명세서를 상세하게 작성했다.

요구사항 정의서를 기반으로 인터페이스 명세서를 뽑아내고, 프론트와 백엔드는 인터페이스 명세서를 보고 어떤 데이터가 필요한지, 어떤 식으로 반환해주는지 확인하면서 진행했다. 싸피에서 가장 만족스러운 부분은 프론트와 백엔드의 협업 과정을 알 수 있다는 점이라고 생각한다.

또한 지라와 깃랩을 사용하면서 브랜치 관리법을 알게 되었고 매일 스크럼과 지라를 통해서 어떤 작업을 하고 있는지 알 수 있었던 게 되게 편리했다.

 

개발

 

우선 스프링 시큐리티를 사용하기로 결정하면서 내가 스프링 시큐리티를 맡기로 했다. 거의 1주일 안으로 공부를 하고 프로젝트에 적용해야 했기에 상세하게 공부하지는 못하고 어떻게 적용할지를 주로 찾아봤던 것 같다.

스프링 시큐리티 사용하면서 편리했던 점이 API 요청 경로에 따라서 인증과 인가를 처리할 수 있다는 점이 좋았다. 또한 스프링 Oauth 라이브러리를 사용해서 소셜로그인 처리를 나름 간편하게 만들 수 있어서 좋았다. 근데 스프링 시큐리티는 진짜 너무 깊은 내용이라서 제대로 이해하면서 사용한다는 느낌이 전혀 들지 않았다. 나중에 시간을 내서 따로 공부해보고 싶은 부분이다.

이번에 리프레시 토큰을 도입하면서 ERD에 리프레시 토큰을 관리하기 위한 테이블을 추가했다. 처음에 로그인하면 클라이언트에게 액세스와 리프레시 토큰을 전부 주고, 액세스토큰이 만료됐을 경우 다시 리프레시 토큰을 요청하게 만들어서 DB에서 확인 후 액세스토큰을 재발급 해주는 방식으로 진행했다.

지금 생각해보면 내가 너무 로직을 어렵게 구상했다.

1. 클라이언트가 액세스 토큰 백으로 전송
2. 액세스 토큰 만료되면 클라이언트에게 에러 전송
3. 클라이언트는 리프레시 토큰 백으로 전송
4. 리프레시 토큰 테이블을 통해 유효기간 확인 후 액세스 재발급해서 클라이언트에게 전송
5. 클라이언트는 해당 액세스 토큰으로 기존 요청 재전송

이 로직이 진짜 복잡하게 짜여져있다. 지금 생각하면 프론트에게 너무 미안한 로직이다..(그래도 구현해냈다는 게 진짜 대단하다)

리프레시 토큰을 도입하면서 편리했던 점이 유저가 액세스 토큰이 만료됐어도 다시 로그인을 진행하지 않아도 된다는 점이 매력적이었다.(앞으로 리프레시 토큰을 도입하지 않을 이유는 없다고 생각한다)

개발하면서 가장 아쉬웠던 부분은 API를 테스트 할 때 따로 테스트 코드를 작성한 것이 아니라, postman을 통해서 수동 테스트를 진행했다는 점이다. 물론 직관적이라서 굉장히 유용했지만 백엔드에서 중요한 것은 테스트 코드를 작성하고 성공과 실패로 나누어서 관리하는 것이 중요하다고 생각했기에 이 부분은 아쉬웠다.