월 몇만 원짜리 기술 스택으로 클라이언트 프로젝트를 운영하는 법 (stevehanov.ca)

한줄 요약

에이전시가 AWS 없이 VPS·Go·SQLite로 클라이언트 서비스를 안정 운영하는 실전 전략

---

IT 개발 에이전시에서 기술 스택 선택은 곧 수익성 결정이다. 클라이언트에게 청구하는 인프라 비용이 높을수록 수주 경쟁력은 떨어지고, 프로젝트 마진은 얇아진다. 반대로 기술 스택을 극도로 단순하게 유지하면 유지보수 공수가 줄고, 클라이언트 예산을 기능 개발에 집중할 수 있다.

문제는 업계 관행이다. 에이전시 대부분이 "제대로 된 서비스"라는 명목 아래 클라우드 관리형 서비스, 컨테이너 오케스트레이션, 외부 데이터베이스 서버를 기본값으로 쓴다. 그 결과 사용자가 열 명도 안 되는 MVP에 월 수십만 원짜리 인프라를 붙이는 일이 반복된다.

에이전시가 VPS를 선택해야 하는 이유는?

클라우드 대형 벤더의 콘솔은 처음부터 업셀링 구조로 설계되어 있다. 로드밸런서, 관리형 데이터베이스, NAT 게이트웨이를 하나씩 추가하다 보면 트래픽이 없는 상태에서도 고정 비용이 빠르게 불어난다.

에이전시 관점에서 VPS는 세 가지 이점이 뚜렷하다.

첫째, 비용 예측이 쉽다. 월 정액 요금이라 클라이언트 인프라 비용을 정확히 견적에 반영할 수 있다. 둘째, 장애 추적이 단순하다. 서버가 하나면 로그 위치도 하나고, 재시작 절차도 단순하다. 셋째, 초기 트래픽 규모에서는 성능이 오히려 더 나올 때가 많다. 네트워크 레이턴시 없이 로컬에서 모든 연산이 끝나기 때문이다.

DigitalOcean이나 Vultr 기준 월 7천~1만 5천 원짜리 인스턴스 하나로 일반적인 중소형 클라이언트 서비스를 충분히 감당한다. 서비스가 커지면 그때 스케일업하면 된다. 처음부터 엔터프라이즈 구조를 박을 필요가 없다.

백엔드 언어 선택이 운영 비용에 미치는 영향은?

에이전시에서 백엔드 언어를 고를 때 "개발자가 편한 언어"를 기본값으로 삼는 경우가 많다. 그런데 서버 사양이 낮을수록 언어 선택이 실제 운영 비용에 직접 영향을 준다.

Go는 에이전시 프로젝트에 잘 맞는 언어다. 컴파일하면 단일 실행 파일이 나온다. 별도 런타임 설치가 필요 없고, 라이브러리 의존성 충돌도 없다. 빌드 결과물을 서버에 복사하고 실행하면 끝이다. 배포 파이프라인이 단순해지면 클라이언트 서비스의 긴급 패치 시간도 줄어든다.

메모리 사용량도 효율적이다. 같은 사양의 VPS에서 Python 기반 서버보다 훨씬 많은 동시 요청을 처리한다. 서버 스펙을 한 단계 낮춰도 된다는 뜻이고, 그 차액은 곧 클라이언트의 절감 비용이 된다.

LLM과의 궁합도 좋다. 요즘처럼 AI 코딩 도구를 적극 활용하는 환경에서 Go는 코드 구조가 명시적이라 AI가 코드를 읽고 수정하기 쉽다. 에이전시 개발자가 AI 도구를 쓸 때 생산성 차이가 실제로 난다.

SQLite가 클라이언트 서비스에도 쓸 수 있는 데이터베이스인가?

"데이터베이스는 당연히 별도 서버"라는 인식이 강하지만, 실제로 대다수 중소형 서비스는 SQLite로 충분히 운영된다.

핵심은 WAL(Write-Ahead Logging) 모드 설정이다. 이 옵션을 켜면 읽기와 쓰기가 서로를 막지 않는다. 수천 명이 동시에 접속하는 서비스도 단일 SQLite 파일로 처리할 수 있다. NVMe 드라이브 위에서 돌리면 TCP 네트워크를 거치는 외부 DB보다 오히려 빠른 경우도 있다.

에이전시 입장에서 SQLite의 또 다른 장점은 백업 단순화다. 파일 하나를 복사하면 전체 데이터베이스 스냅샷이 완성된다. 클라이언트 서비스를 다른 서버로 이전할 때도 파일 하나만 옮기면 된다. 운영 복잡도가 낮을수록 에이전시가 유지보수 계약에서 쓰는 공수도 줄어든다.

물론 수백만 건의 동시 쓰기가 발생하거나 다중 서버 분산이 필수인 경우는 PostgreSQL이 적합하다. 하지만 그 수준에 도달하기 전까지는 SQLite가 빠르고, 저렴하고, 관리하기 쉬운 선택이다.

AI 기능을 붙일 때 API 비용을 어떻게 통제하나?

클라이언트가 AI 기능을 요구하는 프로젝트가 늘고 있다. 문제는 LLM API 비용이 예측하기 어렵다는 점이다. 배치 처리, 문서 요약, 데이터 분류처럼 대량 호출이 발생하는 기능은 API 비용이 빠르게 불어난다.

이런 태스크는 로컬 GPU에서 오픈소스 모델을 돌리는 게 장기적으로 유리하다. 초기 하드웨어 투자가 있지만, 반복 실행 비용이 없다. 프롬프트 로직에 버그가 있어서 전체 배치를 다시 돌려야 할 때도 추가 비용이 발생하지 않는다.

반면 사용자 대면 저지연 기능, 즉 챗봇이나 실시간 답변 생성에는 최신 클라우드 모델이 여전히 우위다. 이 경우 여러 LLM 제공사를 단일 API로 묶어주는 라우터 서비스를 쓰면 편하다. 한 제공사의 API가 불안정할 때 자동으로 다른 모델로 전환되어 서비스 중단 없이 운영할 수 있다. 클라이언트 서비스의 가용성을 유지하면서 특정 벤더에 종속되지 않는 구조를 만들 수 있다.