프리 프로젝트를 진행하면서
일기처럼 매일 진행사항이나
오류 같은걸 작성하려 했지만
20일이 지나버렸고,
프리 프로젝트는 끝났다..
오늘 다른 분들의 회고를 들어보니
프리 프로젝트를 진행하면서
매일 블로깅 하시는 분들이 있다고 들었는데
진짜 대단하신거 같다.
주제
pre project는 모든 팀이
개발자에겐 신과도 같은
Stack Overflow를 클론 코딩하기로 하였다.
감히 신을 복제하다니!!
설계
코스에서도 약간 가이드 느낌으로
이번 프로젝트 기간 내에 달성할 수 있는 목표,
더 하면 좋은 목표, 도전적인 목표를 표로 정리해서 보여줬었는데,
팀장이었던 나는 팀원들의 역량과 원하는 부분을 파악해서,
Level 1이었던 "더 하면 좋은 목표"를 목표로 진행했다.
Stack Overflow도 게시판 기반의 간단한(?) 페이지이고,
그저 따라하는거였기 때문에
설계에 큰 시간은 들지 않았다.
사용자 정의서
다만 사용자 정의서를 작성할 때
생각보다 엄청 빨리 끝났었는데,
이후 다른 팀의 사용자 정의서를 구경할 일이 있어
살펴 봤더니 우리 팀의 것이 너무 초라해 보였다.
테이블 명세서
사용자 정의서를 바탕으로
프론트 팀은 화면 정의서를,
백엔드 팀은 테이블 명세서를 작성하고,
각 entity를 설계하였다.
api 명세서
이후 노션의 팀페이지에서 페이지를 하나 더 추가하여
표 형태의 api 명세서도 작성하였다.
api 명세서에는
url, parameter, method, header, request body,
response status, response body 및 비고란을 작성하였고,
서버를 배포하기 전까지는 프론트에서는 해당 api를 바탕으로
json으로 된 더미 데이터를 만들어 사용했었고,
백엔드는 해당 api를 바탕으로 Response entity를 설계하였다.
개발
중간 배포
설계 이후 본격적인 개발에 들어갔고,
팀원분들 덕분에 빠르게 기초적인 CRUD 기능을 탑재한
Controller를 만들어 ec2에 배포할 수 있었다.
그래서 프론트분들이 더 이상 더미 데이터를 사용하지 않았다.
후에 다른 팀들의 중간 발표에서 들어 알게되었는데,
다른 팀보다 배포가 훨씬 빨랐었다고 한다.
맡은 부분
security에 대해 더 공부하고 싶었고,
다행히(?) 다른 팀원분들이 좀 꺼려하셔서
security와 멤버, error handler에 대해 맡았었다.
기본 회원가입 & 로그인
우선 생각나는데로
사용자에게 정보를 입력받아 회원가입하는
기본적인 회원가입과 로그인 기능을 구현했고,
그 상태에서 로그인 할 때 JWT를 발급받아
header에 담아 response까지 하는 것까지는
엄청 순조롭게 잘되었었는데,
OAuth2
의식의 흐름으로 개발을 진행하다가
OAuth2인증의 흐름에 막혔었다.
나도 이미 회원가입 및 JWT 로그인 기능을 구현해 놓은 상태였고,
프론트 분들도 회원가입 및 로그인 기능을 구현했었는데,
유어 클래스에 있는 OAuth2 인증은
OAuth2 로그인만 지원하는 거였기에
회원가입이 필요가 없었던 것이었다!!
이미 구현해놨던 기능이 너무 아까워서
OAuth2 로그인 기능과 기존 회원가입 + JWT 로그인 기능을
합치기로 하였다.
oauth2 success handler를 수정해서
resource server에 인증된 사용자의 프로필을 요청해서
email을 우리 서버의 DB와 대조하여
존재할 시 Access와 Refresh JWT를 발급하여
로그인 이후 페이지로 redirect하고,
DB에 없을 시 해당 email을 redirect url의 파라미터로 추가하여
회원가입 페이지에 파라미터의 email이 채워진 채로
redirect하기로 하였다.
이 기능을 구현하기까지 꽤 많은 시간을 공들였었고,
그렇다 보니 성공했을 때의 이 성취감은
말로 설명 못 할 정도였다.
다른 팀원
다른 분들은 질문, 답변, 댓글 기능을 담당하셨는데,
생각보다 큰 오류 없이 잘 진행하셨고,
entity간의 mapping도 잘 되어
질문 상세 페이지에서 답변이나 댓글을 잘 가져왔었다.
Error
프로젝트를 진행하면서
가장 많이 봤던 에러는
막바지에 CORS 정책으로 인한 403였다.
이는 다른팀들도 마찬가지라고 생각이 되는데,
그도 그럴것이
처음 배포했을때의 경우
프론트 분들이 localhost에서 react app을 돌리시다 보니
에러가 안떴었고,
프론트분들이 배포를 하시자마자 바로 에러가 떴었다.
cors 설정을 따로 해줬다고 생각했는데,
코드를 살펴보니
@Bean
CorsConfigurationSource corsConfigurationSource() {
CorsConfiguration configuration = new CorsConfiguration();
configuration.setAllowedMethods(List.of("*"));
configuration.setAllowedMethods(Arrays.asList("GET","POST","PATCH","DELETE"));
...
}configuration.setAllowedMethods(List.of("*"));에서
setAllowedOrigins를 setAllowedMethods로 설정을 제대로 안하고 있었고,
제대로 바꾸고 나서 보니 GET 요청에서만 응답이 되길래
또 한참을 머리를 싸매다
configuration.setAllowedHeaders를 설정 안해주고 있었던 것이다.
그랬기에 header가 없이 사용되는 get 요청에 대해서는 cors에러가 안떴던 것..
막상 고칠 때는 별거 아닌게 많았는데,
이런거에 시간을 좀 꽤나 쏟을 때가 많다 보니
아직 미흡한 점이 많다고 생각이 된다...
Main을 앞두고
자랑아닌 자랑을 해보자면,
메인 프로젝트 기간보다 훨씬 짧은 프리 프로젝트를
좀 여유롭게 끝냈기 때문에
막판 cors 에러 때문에 발등에 불난건 안비밀
메인 때도 나름 1인분 이상은 할 수 있을거라는 자신감이 있고,
새로운 팀원들과 함께 또 활발한 소통 및 회의를 하면서
재밌는 프로젝트 기간이 되었으면 좋겠다.
