[회고][Django][DRF][RestAPI] 아이디어 '캐밋'을 구현하며

https://github.com/Casual-Meet/CaMeet-BackEnd

GitHub - Casual-Meet/CaMeet-BackEnd

[개발 기간]

8/3 ~ 8/22 (20일) 

[기술 스택]

• Python
• Django Rest Framework
• 프론트 서버와 통신을 위한 REST API를 준수함
• AWS EC2 배포 완료

[대표 기능]

• 소셜 로그인 (구글,카카오)
• JWT 토큰 기반 인증, 인가
• 이메일 인증 (학교 인증)
• DB 객체들 간 참조, 역참조 → 요청에 맞는 JSON 반환

---

[어려움, 난관]

1. REST API가 뭐죠?

개발 팀원이 정해지고 (프론트 2 + 백 3) 프론트서버는 리액트, 백서버는 장고로 구현을 하기로 했다.

기존 장고개발에서 템플릿(보이는 부분)을 장고 서버 내에서 제공을 하면서 하나의 서버에서만 구현만 하다가,

이번에 처음 REST API를 접하게 되었다. 

REST API :자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미하는 애플리케이션 프로그래밍 인터페이스.

 

API 명세서 일부

이번에 'HTTP 완벽가이드' 를 읽고 정리한 것이 서버 간 혹은 서버-클라이언트 통신 흐름을 이해하는데 정말 큰 도움이 되었다. 읽고 나서 스터디에서 발표까지 하니 내 것이 된 것만 같은 느낌!!이 들었다. 좋았다..

오케이 어떤 식으로 주고받는지 느낌 왔다 구현하러 가보자! 

---

2. JWT 토큰이 뭐죠?

 USER 부분의 구현 파트를 맡은 후, 호기롭게 말했다.

"요즘 소셜로그인 없는 웹사이트가 어디있어? 내가 소셜로그인 만들게"

그렇게 깊은 JWT토큰 기반 인증, 인가의 세계에 입문하게 되었다. 기존에 쿠키, 세션 기반 인증과는 달랐다.

- 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소(서버)가 필요 없다.
- 인증만을 위한 특정 서버에 트래픽이 몰릴 일이 없다.
→ 서버적으로 이득이네?

토큰 방식은 기존 쿠키, 세션 기반 인증방식을 보완했지만, 짧은 유효기간의 ACCESS TOKEN을 커버하기 위해 REFRESH TOKEN도 함께 발급이 되는데, 이 REFRESH TOKEN 간수를 잘해야 한다..! (탈취되면 보안 이슈)

한번 토큰 인증방식을 익혔으니 다음에 개발할 때도 잘 맞게 커스텀해서 구현할 수 있는 자신이 있다 :)

[JWT토큰 기반 인증, 인가 메커니즘]

1. 서버는 사용자가 로그인하면, 사용자 정보를 기반으로 토큰을 발급한다.
2. 토큰을 발급받은 사용자가 서버에 요청을 할 때마다, 헤더에 발급받은 JWT 토큰을 같이 넣고 전달한다.
3. 서버는 요청을 받을 때, 해당 토큰이 유효한지 검증하고, 인가(권한) 여부를 판단해서 작업을 처리한다.
4. 서버는 사용자에 대한 세션을 유지할 필요가 없다.(사용자가 로그인되어있는지 안되어있는지 몰라도 됨)
5. 사용자가 요청했을 때 토큰만 확인하면 세션 관리가 필요 없어서 자원과 비용을 절감할 수 있다.

소셜로그인 후 발급받은 JWT토큰

오케이 어떤 식으로 인증이 되는지 알았다!! 소셜로그인 구현하러 가보자!!

---

3. 소셜로그인, 이거 티키타카 히트다!

하찮지만 있을거 다 있는 소셜로그인 로직

아무것도 몰랐는데 이분 티스토리 공부하며 구현 완료했습니다. >> JWT토큰 기반 소셜로그인구현 참고 글

 

단순 복붙? 안 통한다.

원리를 이해하려고 진짜 머리 엄청 싸맸다. 코드랑 진짜 대판 싸웠더니 정이 많이 들었다..

소셜로그인 구현이 처음이라 맨땅에 헤딩하듯 처음부터 모든 것을 짜려고 하기에는 주어진 시간이 짧았기에

1. 기존에 다른 구현해둔 코드를 보고
2. 이해하고
3. 우리 서비스에 맞게 커스텀 한 뒤

적용할 계획이었다. 1번 잘 찾음. 2번, 3번 헬이었다. 

고생한 만큼 소셜로그인 구현 특집 글을 써보려 한다. 정성 들인 구글, 카카오 소셜로그인특집 COMING SOON..!

[할 일 생각나서 적어봄]

비즈니스 계정으로 전환을 통해 사용자의 특정 정보(카카오의 경우 이메일)를 선택 동의가 아닌 필수 동의로 받을 수 있더라. 베타 테스트 진행 후 계정 전환 신청 가자.

---

4. AWS EC2 배포요? 아마존의 컴퓨터 한 개(리눅스 기반 우분투 서버)를 다뤄보자

오케이 로컬에서 아주 잘 원하는 대로 돌아간다!! 협업에서 문제 발생

[프로젝트 진행 中]
백 : "프론트분들 저희 코드 마무리했습니다~~~"
프론트 : "혹시 로컬에서 코드 구현 마무리됐다면, 조속히 배포를 해주실 수 있나요?"
이유 : API 명세서에 적힌 Mock-up 데이터로 작업하기 << 배포된 서버에서 요청을 통해 받아오는 데이터로 작업하기
답변 : "오케이, 금방 해드릴게요!"

배포에 배자도 몰랐을 때는 금방 될 줄 알았다.

알고 보니 프론트서버(정적인 페이지)의 배포의 경우 정말 5~10분 이면 배포가 완료되지만, 서버 배포의 경우는 달랐다.

공부가 필요한 상황이었고, 여러 가지를 고려해서 AWS를 선택했다.

 

백 팀원들과 합쳐서 3일 정도 삽질 끝에 배포에 성공했다.

(삽질할 땐 많이 힘들지만, 해내고 나서는 성취감이 엄청나다.. 이게 코딩의 맛인가? 나 코딩 좋아하네?)

아직 http! https는 곧 적용예정

배포 과정도 나름 정리된 레퍼런스들을 많이 참고했지만 어김없이 발생하는 수만 가지 에러들~ 오히려 해결하면서 더 많이 알게 되었다. 이 부분도 마주쳤던 에러들과, 나름의 배포 과정을 글로 정리해볼 생각이다. COMING SOON..!!

 

윈도우로 작업을 하면서, 아마존의 리눅스 기반 우분투 서버에 접속하는 과정에서 와 맥을 이래서 쓰나? 싶었던 적이 몇 번 있었다. 나중에 맥을 한번... ㅎㅎ

[EC2 프리티어 이슈 인가?] (해결 완료)

배포를 하고나서 코드를 돌려보는데 다른 단순한 요청은 잘 진행이 되지만, 소셜로그인을 진행하는데 있어서 정말 심각하게 느렸다. 결국엔 원하는 회원정보는 DB에 잘 담겼지만, 소셜로그인 과정이 진행될 때는 요청 처리속도가 현저하게 느려진다는것을 캐치했다(결국 504 Time out 에러 반환). 로컬에서는 실행에 문제가 없어서 코드 이슈는 아닌것같다고 판단했고 결국 서버문제인데, 주변 서버전문가에게 조만간 물어보고 해결할 예정이다!

 

▶서버의 게이트웨이 이슈였다. uwsgi → gunicorn 으로 갈아타니 자연스레 해결되었다.

추가적으로 HTTPS 설정도 달아놓아서 캐밋의 백서버는 어느정도 구현이 1차 목표한 만큼 진행이 되었다.

이제 next level로 가자~~

---

[ ERD ]

---

[ 캐밋's Next Level ]

1. 베타 테스트

실제 대학생들을 대상으로 베타테스터를 모집해서 서비스를 실험해볼 예정이다. 기획적으로나 개발적으로 초창기라고 생각하기 때문에 많은 피드백을 듣고 수용해서 적용해 나가는 캐밋팀이 될 것이다.

2. 서버 업그레이드 

배포의 경험을 위한 단계 - 프리티어라도 OK 좋아. 근데 실제로 사용함에 무리가 있다고 판단되어, 팀원과 회의 후에 실제 베타 서비스 기간에는 비용을 지불하고 더 좋은 서버를 구축하려 한다.

3. 기능 추가

기획에서 나온 후기, 댓글 관련 기능을 추가할 예정이다. 

+ 리워드 시스템

---

[ 좋았던 점, 아쉬웠던 점 ]

[좋았던 점]

• 이번 프로젝트에 임했던 컨셉 키워드를 하나 정하라면 나는 '도전'이라고 말하고 싶다. JWT토큰 인증방식을 도입한 소셜로그인, 이메일 인증, REST API 설계 하나하나 정말 중요한 개념이고 처음이라 공부하면서 개발하는 거라 잘 될까?라는 의구심도 있었지만, 좋은 팀원들과 함께해 결국엔 해냈다. 같이 머리 맞대고 개발한 상민이랑 지훈이에게 정말 고맙다.
• 할 수 있다는 자신감을 키워준 프로젝트 캐밋, 좋은 사람들과 함께 할 수 있어서 좋았고 2학기 때 더 큰 그림을 그리기 위해 모두 열정 그대로 가져갔으면 좋겠다 :)
• 내 머릿속에 있는 아이디어를 구현한다는 것은 정말 재미있는 일이구나 싶다.

[아쉬웠던 점]

• 프로젝트 중간중간에 직면했던 어려움을 정리하고 어떤 식으로 풀어나갔는지를 따로 정리를 해두어야 하는 활동을 하려고 생각은 하는데 막상 그 문제에 다이브를 하고 있는 상황에 빠지면 이게 잘 안된다. 좀 어떻게든 노션에 정리해두긴 하는데 다음에는 더욱더 능동적이고 적극적으로 정리해두어야겠다.
• →  이번에 시간을 내서 1.소셜로그인 2.배포 관련 포스팅을 할 예정이다. 포스팅에 회고하면서 구체적으로 잘 정리해서 아쉬움을 승화시킬 예정.
• 프론트쪽의 인력이 많이 부족한 상황도 인지했고 그래서 부담을 주고 싶지 않은 마음에? 백에서 프론트쪽으로 많은 소통을 하려 하지 않았던 것 같다. 중반에는 이로 인해서 소통의 문제가 발생했지만, 후반에 그래도 진행상황에 대해 서로 어떻게든 소통하려는 의지를 잡고 어떻게든 이겨냈었다.
• →  다음에는 부담을 주지 않는 선에서 소통을 건네봐야지

공부를 하면 할수록 더 나은 개발자가 되고 싶다는 마음이 올라온다. 겸손하게 정진하자!!

캐밋의 마스코트 캐밋이