10. 방구석 서버의 한계를 넘다: Render 백업부터 웹진형 게시판 개발까지

👤 관리자

조회 수 120

들어가며: 24시간 노트북 서버, 그 치명적인 불안감

지난 9편에서 클라우드플레어 터널과 <code>tmux</code>를 활용해 낡은 구형 노트북을 24시간 돌아가는 무중단 서버로 탈바꿈시키는 데 성공했습니다. 까만 터미널 창에서 조용히 돌아가고 있는 제 FastAPI 서버를 볼 때면 밥을 안 먹어도 배가 부른 기분이었죠.하

지만 며칠이 지나자 현실적인 불안감이 엄습하기 시작했습니다. "노트북 쿨러에 먼지가 껴서 청소를 해야 하면 어떡하지?", "윈도우 업데이트나 정전 때문에 노트북이 재부팅되어버리면 내 웹사이트는 그대로 죽어버리는 건가?"

그렇습니다. 방구석 물리 서버는 유지보수를 피할 수 없고, 제가 노트북 전원을 내리는 순간 제 커뮤니티를 방문한 유저들은 접속 불가 에러 창을 마주하게 될 것입니다. 이 치명적인 약점을 보완할 '플랜 B'가 절실했습니다.

1. 든든한 보험, 클라우드 플랫폼 'Render'와의 만남

저의 Render Dashboard이다. 무료라서 더 좋다.

<저의 Render Dashboard이다. 무료라서 더 좋다.>

이 불안감을 해소하기 위해 제가 선택한 해결책은 바로 **'Render(렌더)'**라는 클라우드 호스팅 서비스였습니다.

왜 하필 Render인가?: 렌더는 GitHub에 올려둔 제 웹사이트 코드를 자동으로 가져와서 무료로 서버를 배포해 주는 아주 고마운 플랫폼입니다.

</li></ul>

제 전략은 이렇습니다. 평소에는 속도도 빠르고 제한도 없는 제 '방구석 노트북 서버'가 메인으로 웹사이트를 쌩쌩하게 돌립니다. 그러다 제가 노트북 청소를 하거나 유지보수를 위해 잠시 서버를 꺼야 할 때, Render에 임시로 띄워둔 똑같은 복제 서버가 바통을 이어받아 웹사이트를 무중단으로 유지해 주는 것입니다.

실제로 깃허브(Git)를 통해 노트북의 코드를 Render에 연동하고 노트북 전원을 꺼보았을 때, 제 웹사이트가 죽지 않고 Render 서버를 통해 멀쩡히 접속되는 것을 확인하고는 정말 안도의 한숨을 내쉬었습니다. 이제 물리적 서버다운에 대한 공포에서 완전히 해방되었습니다.

2. Jinja2 템플릿으로 '웹진형 썸네일 게시판' 디자인하기

서버의 안정성을 확보했으니, 이제 본격적으로 유저들이 활동할 무대인 '게시판'을 예쁘게 꾸밀 차례였습니다.

제가 기획 중인 커뮤니티는 텍스트만 덜렁 있는 심심한 게시판과는 거리가 멉니다. 특히 인스타그램 등에서 가져온 미디어나 아이돌 사진 같은 이미지 데이터들이 주로 업로드될 공간이기 때문에, 글 제목만 나열된 리스트 형태보다는 사진이 한눈에 들어오는 '웹진(Webzine)' 형태의 썸네일 게시판이 필수적이었습니다.

이를 구현하기 위해 파이썬 FastAPI와 찰떡궁합을 자랑하는 Jinja2(진자2) 템플릿 엔진을 활용했습니다. HTML 코드 사이에 <code>{% for post in posts %}</code> 같은 Jinja2 문법을 섞어 쓰니, 데이터베이스에 저장된 게시글의 대표 이미지(썸네일)와 제목이 마치 예쁜 타일처럼 화면에 바둑판식으로 착착 배열되었습니다. CSS를 조금 만져서 마우스를 올렸을 때 사진이 살짝 커지는 애니메이션까지 넣고 나니, 이제야 정말 그럴싸한 상용 웹사이트의 태가 나기 시작했습니다.

3. 데이터 폭발을 막아라: 게시판 페이지네이션(Pagination) 완벽 구현

썸네일 게시판을 완성하고 기쁜 마음으로 테스트 게시글과 사진을 마구 올리기 시작했습니다. 그런데 글이 20개, 30개를 넘어가자 웹사이트 로딩 속도가 눈에 띄게 느려지기 시작했습니다. 한 화면에 수십 장의 고화질 썸네일 사진을 한 번에 불러오려니 노트북 서버가 헉헉대기 시작한 것입니다.

이래서 모든 웹사이트 게시판 맨 밑에는 '1, 2, 3, 4...' 하고 쪽수를 나누는 **페이지네이션(Pagination)**이 있는 거였군요!

수학적 뇌를 풀가동할 시간이었습니다. 전체 게시글 수를 구하고, 한 페이지당 보여줄 글의 개수(예: 12개)로 나누어 총 몇 페이지가 필요한지 계산하는 로직을 짰습니다. FastAPI 백엔드에서 <code>limit</code>과 <code>offset</code> 속성을 이용해 딱 그 페이지에 필요한 데이터만 DB에서 잘라오도록 만들고, 앞서 배운 Jinja2를 활용해 화면 하단에 이전/다음 버튼과 숫자 페이징 바를 완벽하게 구현해 냈습니다.

4. 커뮤니티의 꽃, SQLAlchemy로 추천수와 조회수 카운트하기

게시판의 외형을 갖췄으니, 이제 유저들의 흥미를 유발할 커뮤니티의 핵심 조미료를 칠 차례입니다. 바로 '조회수'와 '추천(좋아요)' 기능입니다.

이 기능은 파이썬에서 데이터베이스를 쉽게 다루게 해주는 ORM 도구인 **SQLAlchemy(알케미)**를 적극 활용했습니다.

조회수: 유저가 게시글 본문 주소로 접속(GET 요청)할 때마다 해당 글의 <code>view_count</code> 컬럼의 숫자를 +1씩 업데이트하도록 코드를 짰습니다.

</li><li>

추천 기능: 하트 모양 버튼을 만들고, 버튼을 누르면 <code>recommend_count</code>가 올라가도록 설계했습니다. 중복 추천을 막기 위해 로그인한 유저의 정보와 게시글 번호를 매칭하는 별도의 DB 테이블도 하나 더 생성하는 등 생각보다 고려할 조건이 많았습니다.

</li></ul>

단순히 숫자를 올리는 것에 그치지 않습니다. 이렇게 쌓인 추천수와 조회수 데이터는, 훗날 제가 야심 차게 기획 중인 **'명예의 전당(랭킹 보드)'**을 띄우기 위한 가장 중요한 밑거름이 될 것입니다.

마치며: 진짜 '개발자'가 되어가는 기분

이번 작업은 정말 시간 가는 줄 모르고 푹 빠져서 진행했습니다. 워드프레스라는 완성된 툴 안에서 남이 만들어둔 테마와 플러그인을 가져다 쓰던 과거와 달리, 썸네일의 크기부터 페이지를 넘기는 방식, 추천 버튼의 로직까지 오롯이 제 손으로 직접 설계하고 구현해 냈으니까요.

Render를 통한 서버 이중화, 웹진형 디자인, 그리고 SQLAlchemy를 활용한 세밀한 데이터베이스 컨트롤까지. 하루하루 성장하며 제 웹사이트가 생명을 얻어가는 모습을 보니 묘한 카타르시스마저 느껴집니다.

다음 포스팅에서는 이 게시판을 더욱 안전하고 체계적으로 관리하기 위한 관리자(Admin) 페이지 구축과 권한 설정, 그리고 잘못 올라간 게시글을 통제하는 기능 등에 대해 다뤄보겠습니다. 초보 개발자의 끝없는 도전기를 지켜봐 주세요!

지난편 보러가기: 9. 기본부터 다시 하기: 마음을 비우고 FastAPI 서버와 Cloudflare 터널을 뚫다

다음편 보러가기: 11. 항상 만들고 나면 조금씩 아쉽다: 계속되는 다듬기