14. 소통 없는 커뮤니티는 앙꼬 없는 찐빵: 댓글 시스템 구축과 스팸 테러 방어전

👤 관리자

조회 수 94

들어가며: 내 웹사이트가 너무 '조용'하다?

관리자 전용 기능까지 완성하고 사이트 위장막을 거둬낸 뒤, 저는 며칠 동안 흐뭇하게 제 웹사이트를 들여다보았습니다. 지인들에게 링크를 보내주니 예쁜 사진들도 제법 올라오고, 제가 공들여 만든 30일 알고리즘에 따라 랭킹 보드 순위도 엎치락뒤치락 바뀌는 모습이 정말 신기했습니다.

그런데 화면을 멍하니 보다가 문득 아주 중요한 사실을 하나 깨달았습니다. 사이트가 너무 '조용'하다는 것이었죠. 유저들은 사진을 올리고 '추천(하트)' 버튼을 누를 수는 있었지만, 그 사진에 대해 "와, 이 사진 정말 예쁘네요!", "이 영상 출처가 어디인가요?" 같은 대화를 나눌 공간이 없었습니다. 소통이 없는 커뮤니티는 앙꼬 없는 찐빵이나 다름없습니다. 저는 곧바로 에디터(VS Code)를 켜고, 커뮤니티의 심장인 '댓글(Comment)' 기능 개발에 돌입했습니다.

1. 데이터베이스의 늪: 1대다(1:N) 관계 맺기

모든 웹사이트 핵심은 댓글과 추천

<모든 웹사이트 핵심 댓글과 추천>

댓글 기능을 만들려면 데이터베이스(DB) 설계부터 다시 해야 했습니다. 파이썬 백엔드(FastAPI)에서 제가 애용하는 SQLAlchemy를 꺼내 들었습니다.

게시글과 댓글의 관계는 전형적인 **'1대다(1:N) 관계'**입니다. 하나의 게시글(1) 아래에 수많은 댓글(N)이 달릴 수 있기 때문이죠. 이를 구현하기 위해 Comment라는 새로운 DB 모델(테이블)을 만들고, 그 안에 post_id라는 **외래키(ForeignKey)**를 심어주었습니다. "이 댓글은 5번 게시글에 속한 녀석이야!"라고 꼬리표를 달아주는 작업이었습니다. 처음엔 헷갈렸지만, 게시글을 삭제할 때 그 밑에 달린 댓글들도 한꺼번에 폭파되도록 cascade="all, delete-orphan" 옵션까지 깔끔하게 설정해 주니 제법 백엔드 개발자의 태가 나는 것 같았습니다.

2. 화면 깜빡임은 못 참지! 자바스크립트 비동기 통신(Fetch API) 도입

DB 세팅을 마치고 Jinja2 템플릿을 이용해 게시글 본문 밑에 댓글 입력창과 전송 버튼을 만들었습니다. 그런데 테스트로 댓글을 달아보니 큰 불만족이 생겼습니다. 댓글 전송 버튼을 누를 때마다 웹 브라우저 화면 전체가 하얗게 깜빡이며 페이지가 새로고침 되는 것이었습니다.

스마트폰으로 인스타그램이나 유튜브를 볼 때, 댓글을 단다고 화면 전체가 새로고침 되지는 않잖아요? 제 커뮤니티도 그런 세련된 느낌을 주고 싶었습니다.

그래서 HTML과 CSS의 영역을 넘어, 프론트엔드의 꽃이라 불리는 **자바스크립트(JavaScript)**를 건드리게 되었습니다. 화면 이동 없이 서버와 몰래 데이터를 주고받는 Fetch API (비동기 통신) 코드를 작성했습니다. 유저가 '댓글 작성'을 누르면 자바스크립트가 입력된 글자를 낚아채서 파이썬(FastAPI) 서버로 조용히 쏴주고, 서버가 "저장 완료!" 신호를 보내면 그 즉시 화면에 방금 쓴 댓글이 스르륵 나타나게 만들었죠. 화면 깜빡임 없이 물 흐르듯 작동하는 댓글창을 보니 그간의 체증이 싹 내려가는 기분이었습니다.

3. 평화로운 마을에 찾아온 불청객: 스팸 도배 공격

댓글 기능이 너무 마음에 들어서 혼자 "테스트1", "테스트2"를 미친 듯이 연타하며 놀고 있었습니다. 그런데 여기서 등골이 서늘해지는 문제를 발견했습니다.

버튼을 누르는 족족 댓글이 달린다는 것은, 만약 악의를 품은 누군가가 (혹은 매크로 봇이) 1초에 100번씩 전송 버튼을 누른다면 제 방구석 노트북 서버가 무의미한 댓글 데이터로 가득 차버리고, 결국 DB가 뻗어버릴 수 있다는 뜻이었습니다. 소통을 위해 열어둔 창문으로 쓰레기가 쏟아져 들어올 위기였죠.

4. 방패를 들어라: SlowAPI로 Rate Limit(속도 제한) 걸기

서버를 보호할 튼튼한 방패가 필요했습니다. 저는 FastAPI 환경에서 아주 쉽게 속도 제한을 걸 수 있는 **slowapi**라는 라이브러리를 찾아냈습니다.

Rate Limiting(속도 제한)이란?: 특정 IP 주소(유저)가 서버에 단시간 내에 너무 많은 요청을 보내지 못하도록 제한을 두는 보안 기술입니다.

저는 댓글 작성 API 라우터에 @limiter.limit("5/minute")라는 코드 한 줄을 살포시 얹었습니다. **"동일한 IP에서는 1분에 최대 5개의 댓글만 작성할 수 있다"**는 강력한 규칙을 서버에 박아버린 것입니다. 코드 적용 후 다시 미친 듯이 테스트 댓글을 연타해 보았습니다. 딱 5개가 작성된 직후, 서버는 단호하게 429 Too Many Requests(요청이 너무 많습니다) 에러를 뱉어내며 제 스팸 공격을 완벽하게 튕겨냈습니다. 제 방구석 서버가 스스로를 보호할 줄 아는 튼튼한 요새로 진화한 순간이었습니다.

마치며: 이제 진짜 '우리'의 공간이 되다

게시판과 랭킹이라는 '뼈대' 위에, 댓글이라는 '피와 살'이 붙고, 스팸 방어라는 '피부'까지 덮였습니다. 유저들이 사진을 보며 감상을 나누고, 안전한 환경에서 마음껏 활동할 수 있는 진짜 '커뮤니티'가 완성되었습니다.

나만의 웹사이트를 구상하며 도메인(inspeep.com)을 샀던 것이 엊그제 같은데, 어느덧 누군가와 함께 대화할 수 있는 '우리'의 공간으로 변해가는 과정을 보니 가슴이 벅차오릅니다.

이제 대망의 15편, 이 길고 길었던 [개발기] 시리즈의 마지막은 '세상에 내 웹사이트를 알리기 위한 구글 검색엔진 최적화(SEO)와 서치 콘솔 등록기', 그리고 지난 몇 달간의 눈물겨운 여정을 되돌아보는 **'최종 회고록'**으로 장식해 볼까 합니다. 마지막까지 지켜봐 주세요!

지난편 보러가기: 13. 완벽한 커뮤니티를 위한 관리자의 고군분투: OpenCV 썸네일과 에러 대처법

다음편 보러가기: 15. 세상에 내 웹사이트를 알리다: SEO 최적화와 구글 서치 콘솔, 그리고 최종 회고록