FUN편log 프로젝트 2주차 회고

목차

• 시작하며
• 1회차 멘토링
• 칸반 보드 작성
• 2회차 멘토링
• 마치며

 

---

시작하며

 

저번 1 주차 멘토링을 완료하고, 백엔드 담당인 나와 Front-end 담당인 분들은 그다지 접해보지 못했던 개념인 OAuth를 다루기 위해 여러 자료를 수집했다.

 

하지만 수집한 자료들을 바탕으로 인프런 강의 및 유튜브 영상을 보면서 스터디해도 뭔가 프로젝트에 적용했을 때 어떤 식으로 진행되는지에 대한 감이 잘 잡히지 않았다.

 

그 와중에 'Front-end와 연계하는 시나리오를 그려보면 좀 감이 오지 않을까?'라는 생각을 가지고 Front-end 분들과 플로우 차트(FlowChart)를 그려봤다.

 

플로우차트1 - 로그인 성공

플로우차트2 - 로그인 실패 1

플로우차트3 - 로그인 실패2

Front-end분의 의문에서 시작된 플로우차트4

 

그런데 이렇게까지 했는데도 '로그인 진행 중인 경우에 토큰 값은 어떡하지?'라는 의문이 사라지지가 않았고, 이에 대하여 팀원들과 회의하여 예상되는 시나리오 중 가장 그럴듯한 시나리오대로 진행된다고 가정하고 DB 명세서 및 API 명세서부터 함께 작성하고 멘토링을 받기로 했다.

 

OAuth를 적용했을 때 Front-end와 연계해서 어떤 순서로 데이터를 주고받을지에 대한 감이 오지 않은 상태였기 때문에 사실상 DB 명세서 내부의 User 테이블에서 갖고 있어야 하는 데이터나 API 명세서에서 로그인/회원가입을 할 때 어떤 데이터를 주고받아야 할지가 애매했다.

 

---

 

1회차 멘토링

 

멘토링이 시작되고 멘토님으로부터 지난주 멘토링이 종료된 직후부터 현재까지 어떤 활동을 했는지에 대해 OAuth학습 및 지난 멘토링 때 받은 과제를 수행했다고 답변을 드렸다.

 

지난 멘토링때 받은 과제는

 

1. UI 명세서 초안 작성하기
2. DB 명세서 초안 작성하기
3. API 명세서 초안 작성하기

 

로, 전체적으로 다 같이 작성하나 UI는 Front 담당자님의 진행으로 함께 진행하고 DB 명세서 및 API 명세서는 우리 팀 유일 백엔드 담당자인 나의 진행으로 진행해보라는 것이었다.

 

UI 명세서는 사실 와이어 프레임이 엄청 완성도있게 작성되었기 때문에, 거의 기능 명세서의 내용과 동일해서 기능 명세서와 와이어 프레임을 리마인드 하는 느낌으로 발표를 진행했고, 발표 후 수정 점은 없었다.

 

기능 명세서와 비교하여 UI 명세서에서 추가된 점이라면 기능 명세서는 기능에 대한 것들만 작성되었다면, UI 명세서에는 오버레이라던가 리스트의 위치, 별점 등의 컴포넌트의 위치정보가 추가되었다.

 

이후에는 DB 명세서와 API 명세서를 어떻게 설계했고, 어떤 시나리오를 예상해서 만들었는지에 대한 발표를 진행했다.

 

발표 이후에 DB 명세서와 API 명세서에 대해 받은 피드백은 아래와 같았다.

 

 DB 명세서 

1. User 테이블의 oauth_id 컬럼 삭제 : oauth_id는 인증을 위해 주고받는 데이터이지 저장해야 하는 데이터가 아님
2. User 테이블의 닉네임 컬럼 삭제 : 위와 동일

 

 API 명세서 

1. 로그인 API에서 Response Body에 닉네임, oauth 제거 : 닉네임, oauth와 같은 유저 정보는 헤더를 통해 전달하기 때문
2. 회원가입 시 로그인 시도 후 없는 유저임을 Back-end에서 Front-end로 보내주면서 에러 코드 추가하기 : 로그인 요청을 처리하지 않았기 때문

 

피드백과 동시에 OAuth로 로그인하는 과정 및 로그인 이후에 유저 활동에 의해 진행되는 시나리오에 대해 애매했던 부분에 대한 멘토링을 받았다.

 

일반적으로 OAuth로 로그인 이후부터 서비스를 이용하기까지 과정은 아래와 같다고 한다.

 

1. 유저가 회원가입을 위해 UI를 작성하여 Front에서 Back으로 회원 정보가 넘어온다.
   • 이때 Front의 요청 Header에 Bearer Token이 함께 넘어온다.
2. Back에서는 Front로부터 받은 Bearer Token이 유효한지 구글에 검사 요청을 보낸다.
   
   • Bearer Token이 유효할 시 구글의 응답과 함께 넘어온 email을 db에 저장 후 Front에 회원가입 완료 응답을 보낸다.
   • Bearer Token이 유효하지 않을 시 즉시 Front에 4xx의 에러 코드의 응답을 보낸다.
3. 회원가입이 완료되면 다시 UI를 통해 로그인을 시도한다. (이건 우리 프로젝트에서 이렇게 진행하려고 한다.)
4. 이후에 로그인 시도 및 로그인 권한이 필요한 여러 요청을 Front에서 Back으로 보낼 때, Request Header에 회원가입 때와 동일하게 해당 유저의 Bearer Token을 보낸다.
5. Back에서는 항상 Bearer Token이 넘어오면 구글에 유효성 검사 요청을 보내게 될 것이고, 만약 유효하지 않으면 요청 처리가 이루어지지 않을 것이다.

 

뭔가 이전까지는 로그인이 진행 중인 상황일 때 어떻게 세션을 유지하는 건지에 대한 궁금증이 존재했었는데, 위 과정에 대한 멘토링을 들으면서 어느 정도 이해가 된 것 같다.

 

---

 

칸반 보드 작성

 

멘토링을 받고 어느 정도 Back-end에서 해야 하는 일들이 머릿속에서 마치 퍼즐이 맞춰지는 것처럼 정리가 되는 느낌이었다. 

 

2주 1회차 멘토링에서 받은 과제는 Github에 Front, Back각각 저장소를 만들고, 칸반 보드를 만들어오는 것이었다.

 

나와 Front 분들은 멘토링이 진행된 화요일에는 일단 해야 할 일이나 멘토링에서 어떤 일이 있었는지를 회의록에 적고, 다음날인 수요일에 리프레쉬한 상태로 다시 시간을 잡고 모여서 함께 진행하기로 했다.

 

 

수요일이 되고 다시 디스코드에서 만난 우리는 일단 저장소부터 만들었다.

 

저장소를 만드는 작업을 진행할 때에 우리는 모두 Github를 처음 사용하는 것이 아니었지만, 능숙한 것도 아닌 눈치였기 때문에 서로 화면을 공유하면서 기존에 저장소를 어떻게 만들었고, 이번엔 어떻게 할지 의견을 공유하면서 만드는 시간이었다.

 

프로젝트 생성

 

저장소 생성을 마친 뒤, 칸반 보드를 만들려고 하는데 칸반보드를 만들 수 있는 곳은 많이 있었지만 우리 팀은 일괄적으로 Github Projects를 사용해서 만들기로 했다.

 

Back-end 담당자로써 칸반보드 초안을 작성하면서 수행해야 하는 작업을 아래와 같이 크게 5가지로 나누어 작성했고, 이에 대해서는 다음날에 진행될 멘토링을 받으며 수정하기로 했다.

 

1. Spring 프로젝트 초기 세팅
2. Entity 클래스 구성을 JPA에 맞게 구성
3. Front-Back API 구현
4. access-token 검증 기능 구현
5. CI/CD 세팅

 

---

 

2회차 멘토링

 

카우치 코딩 멘토링 과정 중 이번 2주차 2회차 멘토링에서 처음으로 Back-end, Front-end 멘토님과 대면하게 되었다.

 

처음 대면하는 것이기도 하고, 그동안 멘토님들은 기획 멘토님께 브리핑을 받거나 디스코드에 제출한 과제 및 질문을 통해서만 FollowUp을 진행하셨기 때문에 간략하게 지금까지 프로젝트를 어떻게 진행했는지 브리핑이 진행되었다.

 

이후에는 각 멘토님 별 담당 인원에 대한 실력 체크를 위한 간단한 질문을 받은 후에 작성한 칸반 보드에 대한 피드백을 받게 되었다.

 

전반적으로 내가 작성한 Back-end 칸반보드에 대한 피드백은 아래와 같았다.

 

1. Front-Back API 구현 아이템의 범위가 크기 때문에 해당 항목을 완료하기 위해 들이는 시간이 다른 아이템보다 월등하게 길 것이다.
2. access-token 검증 기능 구현 아이템이 사실 로그인 및 회원가입 기능 구현과 비슷한데, 로그인이나 회원가입 기능 구현은 Front-Back API에 들어있는 내용이다.
3. 협업하는 것을 항상 가정하고 칸반 보드를 작성하면 좋다.
4. 맨먼스를 생각하여 너무 큰 일은 가급적 쪼개서 별도의 아이템으로 두자
   • Front-Back API 구현 항목에 대한 피드백

 

피드백을 받은 뒤에는 잡담 + 질문 답변을 받는 시간을 가지며 멘토님에게 익숙해져 가는(?) 그러한(?) 시간을 가졌다.

 

이 과정에서 원래 이전 기수의 Back-end 분들은 배포 툴로 Heroku를 사용했으나, 해당 툴이 전면 유료화되는 바람에 이전 기수분들의 프로젝트가 배포 중단되는 현상을 지켜보셨던 멘토님의 특단 조치로 Heroku에서 Qoddi로 배포 툴을 변경하기로 했다는 소식과, 전반적으로 배포를 먼저 CI/CD를 통해 자동화한 후에 본격적인 개발에 들어갈 것이라는 소식을 듣게 되었다.

 

배포를 먼저 진행하는 이유는 일단 자동화해두면 자동으로 배포가 될 것이고, 그렇게 되면 Front-end 분들이 테스트하기 좋은 환경이 되기 때문이다.

 

---

마치며

 

멘토링을 마치면서 멘토님께서 아래의 다섯 가지 과제를 내주셨다.

 

1. 칸반 보드 수정하기
2. API 명세서 수정하기 - Get요청에는 Request Body를 사용할 수 없는 것
3. DB 명세서 수정하기 - Front에 키워드 번호가 아닌 키워드 자체를 넘겨주고, 키워드 내용은 DB에 보관하도록 수정
4. Spring Project 초기 세팅하기
   • 의존성 추가 : Web, JPA, PostgreSQL, Lombok, Security, devTools
   • application.properties 수정하기 : DataSource, Jpa 관련
5. 배포 연습하기 - Qoddi

감사합니다!!