vonvon56 님의 블로그
2024 멋사 해커톤 회고 본문
첫 해커톤
멋사 활동하면서 웹개발을 거의 처음으로 배우고, 실제 프로덕트를 만들어 보았다.
REFERTO라는, 참고문헌 생성 및 관리 서비스에 백엔드(Django) 담당으로 참여했다.
깃허브 링크와 프로젝트 설명은 아래에!
https://github.com/vonvon56/referto-backend
GitHub - vonvon56/referto-backend: 2024년 서울대학교 멋쟁이사자처럼 해커톤 <referto> 프로젝트 백엔드 레
2024년 서울대학교 멋쟁이사자처럼 해커톤 <referto> 프로젝트 백엔드 레포지토리. Contribute to vonvon56/referto-backend development by creating an account on GitHub.
github.com
에러 핸들링
1. 구글 로그인 구현
Django로 소셜로그인을 구현하고 싶으면, 절대로 앱 이름을 account로 설정하지 말자!!!!!
이유는 settings.py에서 앱 이름을 등록하는데, 소셜로그인을 구현하는 데 쓰이는 allauth.account와 겹치기 때문이다.
그래서 하나의 앱을 2번 등록했다는 에러가 난다.
이 두 앱을 서로 다르게 인식시키기 위해 다양한 방법을 동원했었는데 결국 실패했다.
찾아보면 방법이 있긴 하겠지만 굳이 긁어 부스럼을 만들 이유가 없다...유저 앱 이름은 user로 하기로 하자.
이 에러가 도저히 해결되지 않고, 마이그레이션 때문에 사후 앱 이름 변경도 어려웠다.
그래서 아예 로컬 폴더를 새로 파서 user 앱부터 구현한 다음 기존 코드를 붙여넣을 수밖에 없었다.
네트워크를 잘 알았다면 이런 방법까지 동원하지 않았어도 되었을 것 같다는 생각도 들었다.
소셜 로그인의 정확한 매커니즘을 이해하지 못했기 때문에 기존 블로그 글들을 그대로 따라할 수밖에 없었고, 에러가 발생했을 때도 정확한 원인을 파악하기 어려웠던 것이다.
생각보다 유저를 추가하는 게 백엔드의 공수를 크게 늘리는 일이더라...그래도 서버가 호출에 제대로 반응할 땐 보람이 있었다. 결국 공부를 더 해야 해결될 일인 것 같다.
약간의 팁
GOOGLE_CALLBACK_URI = BASE_URL + 'api/user/google/callback/'처럼 써서 안 되면,
GOOGLE_CALLBACK_URI = 'http://127.0.0.1:8000/api/user/google/callback/'
처럼 BASE_URL까지 포함한 URI로 바꿔보자. 합치면서 뭔가 문제가 발생하는 경우도 있는 듯하다.
초보자들을 위한 장고 구글 로그인 구현 코드
https://github.com/vonvon56/referto-backend/commit/deb5625912cf5dd2460760312151f394542c67f8
많이 도움받은 글들 링크
[DRF] 구글 소셜로그인 (JWT)
DRF + jwt + 소셜로그인초기 환경 세팅dj-rest-auth는 업데이트가 중단된 django-rest-auth 대신 사용하는 패키지로, 회원가입과 로그인, 소셜로그인 기능을 제공해준다. 추가적으로 비밀번호 찾기/리셋,
velog.io
Django-Rest-Framework(DRF)로 소셜 로그인 API 구현해보기(Google, KaKao, Github)
SPA(react.js), Mobile App을 DRF(Django-Rest-Framework)와 연동하여 진행하는 프로젝트의 일환으로 소셜 로그인을 구현해 보았다.
medium.com
교훈
1. (어떤 프레임워크를 쓰건) 유저가 있는 앱이면 유저부터 제대로 개발하기. 나중에 유저를 끼워넣는 게 몇 배로 힘들다.
2. (장고 사용 시)유저 앱 이름 account로 두지 않기
2. openapi 연결
처음 해보는 거라 걱정도 있었는데 무난하게 해결됐다.
문제는 프롬프트 엔지니어링에서 약간 발생했는데, 한국어 논문을 입력받았을 때 자동으로 영어로 변환해버렸다.
처음에는 하나의 프롬프트에 '한국어 논문일 시 절대로 영어로 번역하지 마라'는 내용을 반복적으로 입력했었는데 오류를 완전히 없앨 순 없었다.
그래서 정규표현식을 써서 [가-힣]이 하나라도 발견되면 한국어 논문용 프롬프트, 없으면 영어 프롬프트를 사용하는 구조로 바꾸었다.
ai를 사용하는 특성상 지금도 오류가 전혀 없는 건 아니지만 그 전에 비해 확연히 개선되었다.
그 외에도 '제발 이렇게 하라고!!' 식으로 감정에 호소하면 오류가 줄어드는 양상도 보였다. 이건 프롬프트 엔지니어링 쪽을 좀 공부해봐야 할 듯하다.
3. Fly.io 배포
이번 해커톤 최대의 난관...
최종 배포에서 얼마나 큰 오류가 났었냐면
1. 유저들 계정이 실시간으로 서로 바뀌었다(너의 이름은처럼;;;;진짜 듣도 보도 못한 오류)
2. 파일 업로드가 잘 되었고 로그 찍어보면 정보가 문제없이 들어왔는데도 에러 창이 뜬다.
3. 로그인 후 일정 시간이 지나면 로그인 상태가 강제로 해제된다.
4. 이미 존재하는 계정이 로그인을 시도하면 약 10% 확률로 성공한다. admin 계정도 똑같은 에러가 발생했다.
많은 멘토님들이 한번씩 우리 테이블 방문해서 뭐가 문제인지 알아내려고 했으나 당일에는 원인을 찾지 못했고 그 다음날에야 알 수 있었다(땡스 투 Pj)
문제는 인메모리 데이터베이스인 SQLite와 Fly.io가 충돌했던 것이다.
(부정확할 수 있음 주의!)
내가 사용한 SQLite(인메모리 데이터베이스)는 말 그대로 서버의 메모리에 데이터를 저장한다고 한다. 즉 데이터베이스를 공유하지 않는 다른 서버에서 데이터에 접근하는 것은 불가능하다.
로컬에서 돌릴 때는 모든 데이터가 내 컴퓨터에만 있으니까 문제가 없었는데, Fly.io를 사용할 땐 재앙이다;;
Fly.io가 로드 밸런싱(서버 과부하를 방지하기 위해 작업을 고르게 분배하는 기술)을 위해 기본적으로 머신을 2대로 설정하기 때문이다...사용자의 요청이 2대의 서버 중 무작위로 정해진 하나로 간다는 거다.
그래서 머신1에 저장된 데이터를 머신2에서 접근할 수 없고, 그 반대도 마찬가지였다. 그래서 요청을 보낼 때마다 됐다 안 됐다 하던 것이다.
해결책은 크게 2가지
1. SQLite 같은 인메모리 데이터베이스 대신 PostgreSQL이나 MySQL 같은 공유 데이터베이스를 사용한다
-> 그래야 여러 대의 서버가 같은 db를 공유할 수 있다.
2. 싱글 머신 설정
-> 머신을 하나만 쓰기로 하면 인메모리 데이터베이스를 사용해도 문제없다.
감상
늦은 시간까지 같이 있어주고 늘 적극적으로 참여했던 우리 팀원들과
코드 일일이 까보면서 해결에 도움을 주신 모든 분들께 감사드립니다!!! 특히 새벽 4시까지 붙어서 aws 배포 알려주신 회장님 그저 빛 ㅠㅠ
+) 그리고 네트워크 공부도 해야겠다.