근래 있었던 일들에 너무 빡이 쳐서 기록을 남긴다.

시작은 해외에서 아마도 그누군가가, bot을 돌려서 django로 만든 내 사이트에 가입자를 미치도록 증가시켰던 일로 부터 시작된다.

 

무료로 sendgrid의 메일 전송을 사용하는 나로서 이는 무척이나 불편한 일이었다.

한달에 100개 무료로 제공된다.

sendgrid, sendinblue, mailgun에 대한 계정을 연결해 뒀지만, php와는 달리 패키지로 import 하여 

내부 sendmail()에 연동되는 구조라 변경 할 때마다 코드 변경 및 재시작이 필요해서 자동으로 limit 도달시 변동이 안된다.

 

코드로 고민해서 만들 수 있는 부분이 있지만, 당장 시급한 것도 아니고 100명이 가입할 사이트도 아닌 사이트라

문제를 해결하는 것에 집중 하기로 했다.

 

일단 recaptcha 를 도입하기 로 한다.

cloudflare에서 제공하는 Turnstile를 사용하려 했다. 무료고 성능도 좋다고 해서 정보를 수집하면서

부족한 예제 및 낮은 사용성에 시간을 투자하여 만들기에 당장 해결해야 하는 개인 사정으로

google의 recaptcha v3를 도입하기로 했다.

이 또한 예제 및 국내 문서가 부족했다. 도입은 했는데 트래픽 기반으로 자동으로 분별하는 것이라 동작이 제대로 되는지 확인을 할 수 없었다. 물론 방법은 있겠지만, 개인 사정상으로 시간을 많이 쓸 수 없었다.

v2를 도입했다. 바로 해결했다.

 

중간에서 정리하자면, 이 모든 과정은

1. local에서 개발하고

2. 테스트 환경을 만들어 화면에서 잘 동작하는지 직접 테스트하고 

3. db를 상용으로 변경해서 다시 테스트해본다.

4. 그리고 문제가 없으면 github에 업로드 해서 기본 testing을 actions을 이용해 수행하고

5. github actions을 이용해 배포한다.

6. 상용 페이지에 적용 되는지 확인하고 테스트 한다.

7. gitlab에 다시 코드를 백업한다.

 

웬만하면 하나의 서비스를 개발하고 이러한 과정을 거친다.

 

이후 메일이 실제 존재하는 사용자인지 dns를 이용해 확인하는 과정을 거치고자 했다.

검색을 하고 확인한 결과 email-validator를 찾을 수 있었다.

원래 원했던 것은 nslookup 등을 이용해 실재 메일서버를 확인하고 

일련의 검증 과정을 거치는 작업을 하는 api를 찾고 싶었다.

무료는 없었기에 해당 패키지로 만족하기로 했다.

 

마지막으로 가입한 모든 사용자를 별도 독립적인 table에 누적하게 만들고

기존 메일 인증 테이블에 저장된 사용자들은 3일의 기간을 두고 인증을 하지 않을 경우

삭제하는 것으로 정책을 만들기로 했다.

관련된 코드들을 만들고 최종 삭제를 어떻게 할지 고민했다

django-cron이 존재하고 celerybeat를 이용하는 방법이 있었다

 

celery를 학습해 두고 도입하기 위해 몇가지 스니펫들을 만들어 두던 차였기에

celerybeat을 이용하기로 했다.

 

문제는 오라클 클라우드 무료 버전을 사용하고 있기 때문에 

과연....

docker-compose로 postgresql, redis, nginx, gunicorn을 수행하는데

celery와 celerybeat까지 돌아가는데 문제가 없을까 였다.

 

테스트가 종료된 코드들을 배포했을 때

 memory leak이 발생했다. 

docker-compose의 메모리를 변경해줘도 해결이 되지 않았다.

 

당장 서버를 유료로 넘어갈 생각이 없었고

swap 메모리를 충분히 잡아줬기 때문에 문제는 없을거라 생각했다.

이로 인해 발생하는 지연은 그렇게 고민이 되지 않았다.

 

해당 서버에 있는 container, image, volume, network를 모두 삭제했다.

그리고 다시 코드를 배포하고 하나씩 서비스를 확인했다.

celery와 celerybeat은 컨테이너 안에서 수동으로 동작 시키고 확인했다.

 

문제가 없는 상황까지 도달했고

마지막으로 자동 배포를 하면서 이 또한 문제가 발생하지 않는 것을 확인했다.

 

이제 한숨을 놓고 친구에게 연락을 했다.

그동안 참여하던 google의 머신러닝 챌린지의 마지막 코스인

캐글의 순위에 도달하는 과정을 친구랑 팀으로 진행하고 있었기 때문이다.

 

"이제 나도 참여할 수 있을거 같다 집안과 내 개인 사정과 더불어 코드를 짜야했던 내 사정을 이해해줘서 고맙다"

5일간 별별일이 있었던 나의 상황이 콜라 한병을 다 마신듯 시원하게 느껴졌다가...

 

생각이 났다.

 

소셜 로그인이 현재 버그이다....

 

다시 코드를 짜면서 이틀을 보냈다. 문제의 원인은 uuid4()로 만든 임시 username 발급과 table에 할당한 username의

길이로 인한 문제였다.

stage로 돌리는 상용 서버에서는 당연히 원인을 출력하지 않았고

dev로 돌리는 local 서버에서 테스트 환경을 다시 다 갖추고 나서, naver 이후 kakao 테스트에서 제공한 

한줄의 log 정보를 바탕으로 힌트를 잡아 원초적인 문제를 해결할 수 있었다.

 

별거 아닌 코드 몇줄인데 환경 구축에서 추적하기 까지 이틀이 걸렸다

 

이 과정에서 발견한 버그로 admin의 site를 만들고 메뉴의 정렬을 직접 설정하게 되면

이후 추가되는 메뉴들로 문제가 발생할 수 있고

지역화 (번역) 기능을 넣었을 때 문제가 발생할 수 있다는 것이었다.

 

* 지역화는 서버에서 하는게 아니라 db에 관련된 지역화 컨텐츠들을 넣어두고 프론트에서 하는게 제일 안전하다.

 

admin.py를 수정했고, profile의 form과 template에도 버그가 확인되어 수정했다.

 

오픈소스를 만들고 app이라 해봐야 5개 남짓이지만

그동안 만든 테이블과 기능들을 생각하면

웬만한 서비스 하나 만들고 남을 정도는 된다.

때문에 관리가 그만큼 힘들고 시간이 지난 코드는 추적이 어렵다는 것이다.

강의를 해보려고 포트폴리오겸 만든 프로젝트인데 너무 커지고 지저분해져서 고민 중이다.

 

오늘 모든걸 클리어 하고 내일 부터는 이번 달 말까지 제출해야 하는 케글 머신러닝에 합류해야 한다.

사전 학습할것도 너무 밀려 있는 상황이라 욱신 거린다.

 

fastapi도 만져야 하고... 이건 일주일이면 웬만큼 건딜고 같은데...

vue도 해야하고

DRF 기반 쇼핑몰도 빨리 시작해야 하는데...

머신러닝이 들러붙어서 머리가 지끈 거린다.

 

fastapi랑 DRF 강의 사 둔거 리뷰겸 한번 훓고 나면 일단 취업부터 시작해 볼 생각이다.

 

할일에 쌓여 정작 먹고살일이 점점 너무 멀어져가서 

현실과 동떨어진 사람이 되어가고 있는것 같아서 안되겠다는 생각이다.

 

취업을 시작하면서 프리도 시작할 생각이다.

 

그 누군가의 어뷰징으로 시작되어 터질듯 코딩한 근래의 사건이 정리되어

다시 산처럼 쌓인 "할일들"로 돌아가게 된 오늘의 기록이다.