사이드 프로젝트 1년, 운영 비용 중심으로 돌아본 기록
- 카테고리 없음
- 2025. 9. 1.
사이드 프로젝트를 지난 1년 동안 운영하면서 기술적으로 배운 것도 많았지만, 가장 크게 체감된 건 비용이었다.
회사라면 당연히 쓰던 서버나 DB도 개인 프로젝트에서는 모두 사비로 운영해야 했기 때문이다.
결국 "사용자가 불편하지 않으면서 비용을 어떻게 줄일 수 있을까"라는 고민을 하게 됐다.
많게는 월 4만 원까지 쓰다가, 지금은 거의 0원에 가깝게 운영하는 단계까지 왔다.
그 과정을 기록해두면 앞으로 비슷한 사이드 프로젝트를 시작하는 사람들에게 도움이 될 것 같다.
GPT 이전과 이후
이전에 사이드 프로젝트를 여러가지 했었지만, 사실 그동안은 서비스 배포까지 이어지지 못했다.
그 이유는 의외로 HTML, CSS였다.
백엔드 로직은 어떻게든 만들 수 있었지만, UI를 입히는 단계에서 매번 막혔다.
혼자 삽질하며 여러 번 시도했지만, 디자인 완성도가 너무 떨어져 결국 배포를 포기하곤 했다.
그러다 GPT가 등장하면서 상황이 달라졌다.
처음에는 성능이 기대 이하라 직접 HTML/CSS를 작성해 배포했지만, 시간이 지나면서 GPT가 만들어주는 코드가 점점 쓸 만해졌다.
2024년 중반쯤에는 CSS 전면 교체까지 맡길 수 있을 정도가 되었고, 이 덕분에 서비스 리뉴얼과 운영이 훨씬 수월해졌다.
예전 같았으면 “CSS 때문에 배포 못 했다”로 끝났을 프로젝트가, 이제는 실제로 사용자들이 접속하는 서비스가 된 것이다.
왜 파이썬으로 시작했을까
주력 언어는 Java Spring이지만, 이번 프로젝트는 Python으로 시작했다.
빠르게 프로토타입을 만들고 싶었고, 사이드 프로젝트 특성상 가볍고 빠른 프레임워크가 필요했기 때문이다.
- 2코어에 램이 2기가 밖에 되지 않기 때문에 Spring 이나 장고와 같이 무거운 프레임 워크는 제외했다.
처음엔 Flask로 시작했지만, 운영 중 FastAPI로 전환하면서 성능과 효율을 크게 개선할 수 있었다.
무작정 배포와 성능 문제
첫 배포는 AWS Lightsail에서 했다.
2코어, 2GB RAM, 60GB SSD에 MySQL까지 같은 사양으로
처음에는 충분해 보였지만, 데이터가 30만 건쯤 쌓이고 배치 작업이 늘면서 성능 문제가 터졌다.
insert/update가 잦다 보니 select 성능이 급격히 떨어졌고, select 1;만 실행해도 버벅거릴 정도였다.
결국 DB를 집에 있던 PC(8코어 16스레드, RAM 64GB, SSD 1TB)로 교체하면서 성능 문제를 해결했다.
이후 보안(?) 문제, 서버 전용으로 맥미니 (6코어 6쓰레드, RAM 32GB, SSD 512GB)로 교체 했다.
운영 중 바꿔나간 것들
- Flask → FastAPI
Gunicorn과 함께 써야 하는 Flask보다 FastAPI 단독 구동이 훨씬 효율적이었다.
메모리 사용량도 줄었고, 가벼운 서비스에 적합했다. - GPT와 리뉴얼
초반에는 GPT 성능이 기대 이하라 HTML/CSS를 직접 만들었지만, 2024년 중반쯤 성능이 크게 좋아졌다.
그래서 사이트 CSS를 전면 교체할 수 있었다. - 보안 문제와 맥미니 전환
집 PC DB 포트를 외부에 열어뒀는데, 실제로 다수의 IP에서 181회 이상 접근 시도가 있었다.
이걸 계기로 구조를 바꿨다.
Lightsail에는 Nginx만 두고, FastAPI와 DB는 맥미니로 옮겼다.
보안도 강화되고, 비용도 크게 줄일 수 있었다.
현재 상황
현재는 일일 평균 트래픽이 5천 정도 발생하고 있다.
이 덕분에 광고 수익이 어느 정도 생기면서, 맥미니 (30만원)를 서버로 도입할 때 들었던 초기 비용을 충분히 감당할 수 있었다.
운영은 Slack 알림으로 자동화해뒀기 때문에 큰 문제만 없으면 손이 거의 가지 않는다.
앞으로는 서비스에 조회수 기능을 추가하려고 한다.
Redis를 활용해 조회수를 기록하고, 사용자 반응을 더 정밀하게 확인할 수 있는 구조를 만들 계획이다.
정리
요즘은 TDD, DDD 같은 방법론이나 신기술 중심으로 개발을 많이 한다.
하지만 나는 직접 사비를 들여 운영해야 했기 때문에 화려한 기술보다 비용 중심으로 접근할 수밖에 없었다.
클라우드 대신 맥미니, 불필요한 기능보다 핵심만 남기는 최적화, 그리고 자동화를 통한 유지보수 최소화.
그 과정에서 자연스럽게 “운영 가능한 서비스”의 본질을 배울 수 있었다.
무엇보다 예전에는 “CSS 때문에 포기”했던 사이드 프로젝트가 이제는 사용자 트래픽과 광고 수익까지 만들어내는 서비스가 되었다.
비용 최적화, 성능 개선, 보안 강화, 그리고 작지만 수익화까지 전부 직접 부딪히며 배운 시간이었다.
앞으로 1편부터 8편까지는 이 과정을 더 구체적으로 풀어내 보려고 한다.
누군가 비슷한 사이드 프로젝트를 준비한다면, 내 경험이 작은 참고가 되면 좋겠다.
앞으로 다룰 이야기
- 1편 – 일주일 만에 배포
- 빠른 배포의 장점과 단점, 실제로 발생했던 문제들
- 2편 – 데이터베이스 커넥션의 중요성
- conn.close()를 제대로 하지 않아 커넥션이 누적됐고, 결국 MySQL이 차단하면서 서비스가 멈추는 장애
- 3편 – Flask → FastAPI 전환기
- 왜 프레임워크를 바꿨는지, 그 과정에서 배운 것들
- 4편 – Nginx 설정의 중요성
- 단순히 프록시라고만 생각했는데, 직접 운영해보니 느낀 점들
- 5편 – 검색엔진 최적화(SEO)의 중요성
- 방문자 0명에서 시작해 검색 노출을 늘려간 과정
- 6편 – 운영 중 DB 교체
- “운영 중에 DB를 갈아엎는다고?” 했던 무모한 선택과 결과
- 7편 – 사이트 리뉴얼 with GPT
- GPT와 함께한 리뉴얼, 그리고 그 과정에서 느낀 점
- 8편 – 운영 서버 및 DB 교체 with MacMini
- 맥미니로 서버와 DB를 바꾸며 얻은 비용 절감과 보안 강화
- 9편 - 인덱스와 유니크키의 중요성
- 운영중이던 서비스가 갑작스런 트래픽 증가로 cpu와 램 사용량 급증
- 10편 - AI가 변화함에 따라 변한 개발 방식
- 많은 AI들 중 나에게 맞는 AI는 어떤것일까
- 11편 - 데이터베이스 성능을 극한으로 최적화하는 과정에서 발견한것들
- pk, fk, uk, slog-log, general.log, binaray log
- 12편 - 개인 서비스를 운영한지 1년 6개월 회고
- 나도 모르게 성장했다
- 13편 - 갑작스런 서버 다운 문제는 데이터베이스
- 컬럼 하나 추가하려다 table metadata lock 걸려버렸다