Supabase와 Vercel에서 직접 운영으로, 실제로 달라지는 것들

전담 인프라 엔지니어 없이도 작은 팀이 직접 서버를 운영할 수 있는 조건이 지금 만들어지고 있습니다.

요즘은 서비스를 만들 때 인프라부터 준비하는 경우가 많지 않습니다. 서버를 빌리고, 데이터베이스를 올리고, 배포 환경을 만드는 것부터 시작하지 않습니다. 코드를 짜서 GitHub에 올리면 배포되고, 테이블을 만들면 바로 데이터를 저장할 수 있습니다. Supabase나 Vercel 같은 서비스 덕분이고, Firebase나 Netlify, Railway 같은 서비스도 비슷한 역할을 합니다. 덕분에 인프라를 잘 모르는 사람도 제품을 만들어 빠르게 내놓을 수 있게 됐습니다.

그런데 그렇게 시작한 서비스도 어느 순간 다른 선택지를 고민하게 됩니다. 비용이 예상보다 커져서일 수도 있고, 서비스가 복잡해지면서 더 복잡한 배포 방식을 지원해야 하기 때문일 수도 있습니다. 반대로 직접 운영한다는 선택지가 있다는 것조차 크게 고민하지 않은 채 계속 쓰는 경우도 있습니다.

이 글에서는 그 과정을 한번 따라가 보려고 합니다. 처음에는 왜 Supabase나 Vercel 같은 서비스를 선택하는지, 서비스가 커지면서 무엇이 달라지는지, 직접 운영하는 쪽으로 옮기려 할 때 어디에서 막히는지. 그리고 그 과정에서 Alpacon을 어떻게 활용할 수 있는지도 함께 살펴보겠습니다.

처음에 Supabase와 Vercel을 고른 이유는 두 가지였습니다

첫 번째는 검증하기 전에는 큰 투자를 하기 어렵기 때문입니다. 이 제품이 정말 사람들이 쓸 제품인지 아직 모르는 상태에서 인프라에 먼저 돈과 시간을 쓰기는 어렵습니다. 개인 프로젝트든 회사에서 시작한 새로운 서비스든 마찬가지입니다. 무료 또는 적은 비용으로 먼저 만들어보고, 실제로 사람들이 쓰는지 확인하는 편이 훨씬 합리적입니다. Supabase와 Vercel이 이 구간에서 강한 것은 과금 구조 덕분입니다. 서버는 트래픽이 없어도 요금이 그대로 나가지만, 관리형 서비스는 무료 구간이 있고 그 위로는 쓴 만큼만 냅니다.

두 번째는 서비스를 시작하기 위해 알아야 할 것이 크게 줄었기 때문입니다. 예전에는 서비스를 인터넷에 올리려면 서버를 준비하고, 웹 서버를 설정하고, 데이터베이스를 띄우고, 배포 경로를 만들어야 했습니다. HTTPS를 붙이고 장애가 났을 때 대응하는 것까지 생각하면, 어느 정도 인프라를 아는 사람이 필요했습니다. 지금은 그 구조를 전부 알지 못해도 시작할 수 있습니다. 코드를 올리면 배포되고, 인증서도 자동으로 붙고, 데이터베이스 역시 관리 화면에서 몇 번 클릭하면 만들 수 있습니다.

처음부터 이런 서비스를 선택하는 것은 충분히 합리적인 결정입니다. 아직 제품이 될지도 모르는 단계에서 인프라부터 만드는 것은 오히려 순서가 뒤바뀐 일일 수 있습니다. 다만 두 번째 이유는 뒤에서 다시 중요해집니다. 시작할 때는 없어도 됐던 인프라 지식이, 직접 운영하려고 하는 순간 다시 필요해지기 때문입니다.

시간이 지나면 비용이 먼저 눈에 들어옵니다

서비스를 운영하다 보면 먼저 비용이 눈에 들어오기 시작합니다. 편의성은 해당 툴에 대한 숙련도가 높아질수록 더 높아집니다. 문제는 사용량과 함께 비용도 올라간다는 점입니다. 트래픽이 늘고 데이터가 쌓이면 청구액이 커지고, 운영하는 프로젝트가 여러 개라면 각각 비용이 발생합니다. 그러다 보면 처음으로 이런 질문을 하게 됩니다. 계속 이 방식으로 운영하는 게 맞을까?

물론 비용만 놓고 보면 바로 답이 나오지는 않습니다. 직접 서버를 빌려 운영해도 규모에 따라 비용 차이가 크지 않을 수 있습니다. 이전하는 데 들어가는 시간과 이후 운영에 들어갈 시간을 비용으로 계산하면 오히려 관리형 서비스를 계속 쓰는 쪽이 나을 수도 있습니다.

다만 규모가 커질수록 계산 방식은 조금 달라집니다. 직접 구축하는 데 들어가는 수고는 대부분 처음에 집중됩니다. 처음 며칠 또는 몇 주 동안 환경을 만들고 나면, 그 비용은 이후 운영 기간 전체에 나눠집니다. 1년 정도를 놓고 계산하면 처음에 크게 보였던 구축 비용이 생각보다 작아지기도 합니다. 클라우드나 서버 호스팅 업체에서 서비스를 운영하던 업체들이 사용량이 커지면서, 데이터센터를 고려하게 되는 것도 비슷한 이유입니다.

중요한 것은 비용이 다른 방식을 알아보기 시작하는 계기가 된다는 점입니다. 하지만 비용 하나만으로 이전 여부가 결정되는 경우는 많지 않습니다.

조금 더 지나면 소유권이 걸립니다

운영 기간이 길어지면 비용 외의 문제도 보이기 시작합니다. 데이터와 서버를 누가 가지고 있느냐입니다. 관리형 서비스를 쓰면 데이터와 실행 환경은 기본적으로 해당 서비스의 인프라 위에 있습니다. 대부분의 경우 이것 자체가 문제는 아니고, 오히려 직접 운영하는 것보다 훨씬 잘 관리되는 경우도 많습니다. 데이터도 내보낼 수 있고, 보안 업데이트나 장애 대응도 서비스 제공자가 대신 처리해줍니다.

하지만 직접 결정하기 어려운 부분도 있습니다. 데이터를 저장할 수 있는 지역에 제한이 있을 수 있고, 서비스의 요금제나 정책이 바뀌면 그 변화에 맞춰야 합니다. 내가 필요한 특정 버전이나 기능을 서비스가 제공하지 않는다면 다른 방법을 찾아야 합니다.

특히 기업 고객을 상대하기 시작하면 이야기가 조금 달라집니다. 고객이 데이터를 특정 지역이나 자기 회사 환경 안에 두기를 요구할 수 있습니다. 보안 검토 과정에서는 데이터가 어디에 저장되는지, 누가 접근할 수 있는지, 접근 기록이 남는지 등을 묻기도 합니다. 이때 직접 운영할 수 있다는 것은 단순히 서버 한 대를 가지고 있다는 의미가 아닙니다. 지금 당장 필요하지 않더라도, 필요해졌을 때 선택할 수 있느냐의 차이입니다.

비용과 소유권, 두 고민은 결국 같은 곳에서 막힙니다

비용 때문에 옮기려고 해도, 소유권 때문에 옮기려고 해도 막히는 지점은 비슷합니다. 지금까지 플랫폼이 대신해주던 일을 이제 직접 해야 하기 때문입니다. Supabase는 데이터베이스 운영을 맡아줬고, Vercel은 빌드와 배포, 인증서 관리를 대신했습니다. 서비스 자체에서 문제가 발생하면 그쪽에서 대응했습니다.

직접 운영하기 시작하면 이런 일이 모두 내 일이 됩니다. 배포 환경을 만들고 인증서를 관리해야 합니다. 데이터베이스를 백업해야 하고, 그 백업으로 실제 복구가 가능한지도 확인해야 합니다. 서버가 살아 있는지 지켜보고 문제가 생기면 알림도 받아야 합니다. 보안 업데이트도 해야 하고 장애가 나면 원인을 찾아야 합니다. 사람이 둘 이상이 되면 누가 어떤 서버에 접근할 수 있는지, 어느 수준까지 권한을 줄 것인지도 관리해야 합니다.

이렇게 써놓고 보면 별도의 담당자가 필요한 일처럼 보입니다. 실제로 그래서 많은 회사가 DevOps나 인프라 엔지니어를 채용해 왔습니다. 작은 팀 입장에서는 계산이 단순했습니다. 이 일을 맡을 사람이 있으면 직접 운영하고, 없으면 관리형 서비스에 남는다. 비용이 조금 아깝더라도, 데이터와 인프라를 더 직접 통제하고 싶더라도, 새로운 직무 하나를 통째로 떠안는 것보다는 관리형 서비스를 계속 쓰는 편이 쉬웠습니다. 결국 시작할 때는 몰라도 됐던 것이, 옮기려는 순간 다시 필요해진 셈입니다.

그런데 이 병목이 조금씩 달라지고 있습니다

최근에는 이 계산을 바꾸는 도구들이 생기고 있습니다.

첫 번째는 배포 도구입니다. Coolify나 Dokploy 같은 도구를 직접 서버에 설치하면, 관리 화면에서 Git 저장소를 연결하고 애플리케이션을 배포할 수 있습니다. 인증서를 붙이거나 데이터베이스를 실행하는 작업도 상당 부분 자동화할 수 있습니다. 쉽게 말하면 Vercel이 대신해주던 일부 일을 내 서버에서도 비슷한 방식으로 할 수 있게 만들어주는 도구입니다.

다만 이 도구를 쓴다고 해서 인프라를 아예 몰라도 되는 것은 아닙니다. 서버를 빌려서 접속하고 도구를 설치해야 하고, 도메인을 연결하려면 DNS도 설정해야 합니다. 컨테이너나 환경 변수 같은 개념도 어느 정도는 알아야 하고, 디스크가 가득 차거나 서비스가 뜨지 않을 때는 결국 서버에 들어가서 직접 확인해야 합니다. 반복되는 배포 작업은 줄었지만, 그 도구를 세팅하고 문제가 생겼을 때 대응하는 몫은 그대로 남습니다.

두 번째는 AI 에이전트입니다. 서버를 준비하고 필요한 패키지를 설치하거나, 배포 도구를 설정하고, 데이터베이스를 띄우고, 인증서를 연결하는 작업까지 상당 부분 맡길 수 있습니다. 장애가 발생했을 때도 로그를 읽고 원인을 좁히거나, 확인해야 할 항목을 정리하는 데 도움을 받을 수 있습니다.

배포 도구가 반복되는 운영 작업을 줄였다면, AI 에이전트는 그 도구와 서버를 다루는 데 필요했던 지식의 문턱까지 낮추고 있습니다. 둘이 겹치면서 앞에서 적었던 운영 업무 목록이 더 이상 반드시 한 사람의 채용 공고와 같지는 않게 됐습니다.

그렇다면 판단은 누가 하나요

여기서 자연스럽게 다음 질문이 생깁니다. 실행은 AI 에이전트가 한다고 해도, 그 작업이 맞는지는 누가 판단할까요?

인프라 담당자가 없는 작은 팀을 생각해보면 이 질문은 조금 다르게 봐야 합니다. 원래도 모든 상황을 정확하게 판단할 수 있었던 것은 아닙니다. 장애가 나면 서버를 잘 아는 지인에게 물어보기도 했고, 인터넷을 검색하면서 하나씩 확인하기도 했습니다. 아무도 원인을 모른 채 한동안 시행착오를 겪는 경우도 있었습니다. 그래서 단순히 "최종 판단은 사람이 해야 한다"라고 말하는 것으로는 문제가 해결되지 않습니다. 그 사람 자체가 없어서 시작된 이야기이기 때문입니다.

AI 에이전트가 바꾸는 부분은 판단에 필요한 재료를 만들어주는 것입니다. 무엇을 확인해야 하는지 알려주고, 확인한 결과를 정리해서 보여주며, 실행하려는 명령이 어떤 영향을 주는지도 설명할 수 있습니다. 예전에는 경험이 있는 사람만 알 수 있었던 정보가 어느 정도 정리된 형태로 나오기 시작한 것입니다. 그러면 전문가가 아니더라도 최소한 선택할 수 있는 상황이 만들어집니다. 예를 들어 "이 작업을 실행하면 기존 데이터가 삭제됩니다. 계속 진행할까요?"라는 질문에는 인프라 전문가가 아니어도 답할 수 있습니다.

문제는 그 질문을 받을 기회가 있느냐입니다. 에이전트가 판단을 묻지 않고 그대로 실행한다면 사람이 개입할 기회가 없습니다. 반대로 중요한 순간에 실행을 멈추고 사람에게 확인한다면, 전문가가 아니더라도 위험한 작업을 막을 수 있습니다. 그래서 필요한 것은 모든 작업을 직접 판단해줄 사람이 아니라, 사람이 판단해야 할 순간에 멈출 수 있는 자리입니다.

그 자리가 특히 필요한 세 가지 순간

그렇다면 언제 멈춰야 할까요. 모든 명령을 하나씩 승인해야 한다면 에이전트를 사용하는 의미가 크게 줄어듭니다. 영향이 큰 작업만 구분할 필요가 있습니다.

1. 되돌리기 어려운 작업을 할 때. 코드는 변경 이력이 남기 때문에 문제가 생기면 이전 버전으로 되돌릴 수 있습니다. 하지만 서버에서는 명령이 실행되는 순간 환경이 바뀌고, 특히 데이터를 삭제하거나 외부로 내보내는 작업은 되돌리기 어렵습니다. 설정을 잘못 바꿨다면 다시 고칠 수 있지만, 백업 없이 삭제한 데이터는 그렇지 않습니다. 이런 작업은 실행되기 전에 한번 멈출 필요가 있습니다.
2. 작업이 끝났다고 판단할 때. 예를 들어 데이터베이스를 이전했다고 해보겠습니다. 덤프를 만들고 복원했고, 행 수도 비교했고, 관리 화면에서도 데이터가 정상적으로 보입니다. 그렇다고 반드시 이전이 끝난 것은 아닙니다. 사용자 계정 정보가 제대로 넘어왔는지, 파일이 누락되지 않았는지, 필요한 확장 기능도 함께 구성됐는지, 실제 애플리케이션이 이전과 동일하게 동작하는지 확인해야 합니다. 무엇을 확인해야 하는지는 서비스마다 다릅니다. 에이전트가 "작업 완료"라고 판단하는 것과 서비스가 실제로 정상적으로 이전된 것은 다른 문제입니다.
3. 조회하던 작업이 변경 작업으로 넘어갈 때. 장애 대응에서도 비슷합니다. 처음에는 로그와 지표를 읽으면서 원인을 찾고, 여기까지는 대부분 조회 작업입니다. 하지만 원인을 찾고 나면 서비스를 재시작하거나 설정을 변경하고, 문제가 되는 파일을 지우거나 이전 버전으로 되돌려야 할 수 있습니다. 로그를 읽는 것과 서비스를 재시작하는 것은 영향의 크기가 다릅니다.

이처럼 몇 가지 중요한 순간에만 사람이 개입할 수 있다면, 나머지 작업은 에이전트에게 상당 부분 맡길 수 있습니다.

실제로 맡기려면 필요한 다섯 가지

여기까지의 이야기를 정리하면 AI 에이전트에게 인프라 작업을 맡기기 위해서는 다섯 가지가 필요합니다.

1. 필요한 경우 실제 운영 환경에 접근할 수 있어야 합니다. 장애를 정확하게 진단하거나 문제를 해결하려면 서버 안을 직접 확인해야 하는 경우가 있습니다.
2. 작업에 필요한 권한만 주고 작업이 끝나면 회수할 수 있어야 합니다. 로그를 조회할 때 필요한 권한과 데이터베이스를 이전할 때 필요한 권한은 같지 않습니다.
3. 위험한 작업은 실행 전에 멈출 수 있어야 합니다. 모든 명령이 아니라 실제 영향이 큰 작업에 대해서만 사람이 개입할 수 있어야 합니다.
4. 여러 환경에 있는 서버를 같은 방식으로 다룰 수 있어야 합니다. 작은 팀이라고 해서 서버가 한곳에만 있는 것은 아닙니다. 클라우드와 별도로 빌린 서버, 사무실 장비가 섞여 있을 수 있습니다.
5. 작업의 목적과 실제 실행 내역이 함께 남아야 합니다. 시간이 지난 뒤에도 왜 접속했고 무엇을 실행했는지 확인할 수 있어야 합니다.

그런데 일반적인 서버 접근 방식은 이 조건들과 잘 맞지 않는 경우가 있습니다. 서버를 만들면 SSH 키 같은 접속 수단을 받습니다. 그 키가 연결된 계정의 권한이 크다면, 접속한 사람이나 에이전트 역시 서버의 많은 부분을 조회하고 변경할 수 있습니다. 그리고 한번 전달한 키는 별도로 폐기하지 않는 한 작업이 끝난 뒤에도 계속 사용할 수 있습니다. 결국 키를 주지 않으면 일을 맡길 수 없고, 키를 주면 필요한 범위보다 너무 많이 열어주게 됩니다. 그 사이의 방법이 필요합니다.

Alpacon은 그 사이를 채웁니다

Alpacon은 전담 인프라 엔지니어가 없는 환경에서도 서버에 직접 손을 쓸 수 있게 하면서, 그 안에서 사람과 AI 에이전트가 실행하는 작업은 통제할 수 있도록 만드는 데 초점을 맞추고 있습니다. 앞에서 이야기한 다섯 가지를 기준으로 보면 조금 더 이해하기 쉽습니다.

로그를 확인하기 위한 작업과 데이터를 이전하기 위한 작업이 항상 같은 권한을 사용할 필요는 없습니다. 승인은 콘솔이나 Slack, 모바일 환경에서 처리할 수 있고, 요청을 보낸 쪽이 자기 요청을 직접 승인하지 못하도록 구성할 수도 있습니다. 앞에서 이야기했던 판단할 자리가 바로 이 부분입니다. 그리고 AI 에이전트의 대화 기록이 없어지거나 여러 도구를 거쳐 작업하더라도, 서버에서 실제로 어떤 실행이 있었는지는 별도의 기록으로 남길 수 있습니다.

다만 한 가지는 분명합니다. Alpacon을 통하지 않고 기존 계정이나 SSH 키로 직접 서버에 들어가는 경로가 따로 열려 있다면, 그 경로에서 발생한 작업까지 자동으로 통제되는 것은 아닙니다. 통제해야 할 실행이 있다면 접근 경로도 함께 정리해야 합니다.

실제 작은 팀의 인프라는 생각보다 깔끔하지 않습니다

작은 팀의 서버는 보통 한곳에 예쁘게 정리되어 있지 않습니다. 무료 크레딧이 남아서 어느 클라우드에 하나 올려놓기도 하고, 가격이 저렴해서 다른 업체의 서버를 빌리기도 합니다. 사무실에 남는 장비가 있어서 거기에 무언가를 돌리는 경우도 있습니다. 처음부터 그렇게 설계한 것이 아니라, 그때그때 필요한 선택을 하다 보니 그렇게 됩니다.

문제는 장애가 날 때입니다. 원인이 항상 한 서버 안에만 있는 것은 아닙니다. 앱이 느린 원인은 데이터베이스 서버의 디스크 부족일 수 있고, 디스크가 가득 찬 이유는 다른 서버에서 돌고 있는 야간 작업 때문일 수도 있습니다. 서버마다 접속 방법이 다르고 기록도 흩어져 있다면 이런 연결을 찾는 일이 어려워집니다. 반대로 여러 환경을 한곳에서 다룰 수 있다면 AI 에이전트도 더 넓은 범위를 함께 보면서, 여러 서버의 상태와 로그를 함께 확인하며 원인을 좁힐 수 있습니다.

그리고 여기에서 하나를 더 해두면 훨씬 좋습니다. 인프라 구조를 문서로 남기는 것입니다. 어떤 서버가 어떤 역할을 하는지, 어디에 어떤 서비스가 설치돼 있는지, 어느 애플리케이션이 어느 데이터베이스를 사용하는지 정도만 정리해도 에이전트가 움직이는 정확도가 크게 달라집니다. 매번 처음부터 환경을 추측할 필요가 없기 때문입니다. 이 문서는 사람에게도 중요합니다. AI 에이전트가 만든 인프라인데 정작 팀 안에서 아무도 그 구조를 이해하지 못하는 상황은 피해야 하고, 문서가 남아 있다면 이후 사람이 들어와도 구조를 파악하기 훨씬 쉽습니다.

이 구조는 AI 에이전트만을 위한 것도 아닙니다. 팀원이 늘어나거나 외부 개발자와 함께 일하게 됐을 때도 그대로 사용할 수 있습니다. 필요한 사람에게 필요한 범위만 열어주고, 업무가 끝나면 접근 권한을 회수하는 방식입니다. 작은 팀에서는 SSH 키 하나를 함께 쓰는 것이 가장 간단해 보일 수 있지만, 사람이 늘어난 뒤에는 이야기가 달라집니다. 누가 어떤 키를 가지고 있는지, 어느 서버까지 접근할 수 있는지, 퇴사하거나 프로젝트가 끝난 사람의 키가 아직 살아 있는지 다시 확인해야 합니다. 접근 경로가 하나일 때 정리하는 것과, 여러 사람이 이미 키의 사본을 가지고 있는 상태에서 정리하는 것은 작업의 크기가 전혀 다릅니다.

그렇다면 언제 직접 운영하기 시작하면 될까요

제품이 실제로 될지 아직 모르는 단계라면 굳이 옮길 이유가 없습니다. 무료 구간을 활용하고, 인프라를 운영하는 데 사용할 시간을 제품을 만드는 데 쓰는 편이 낫습니다. 하지만 제품이 실제로 사용되기 시작하고 수익이나 지속적인 트래픽이 보이기 시작했다면 그때부터는 계산이 달라집니다. 비용도 비교해볼 수 있고, 데이터와 인프라를 어느 정도 직접 통제할 것인지도 고민할 수 있습니다.

예전에는 마지막에 항상 같은 조건이 남았습니다. 우리가 이 인프라를 직접 운영할 수 있는가. 그 조건이 지금 조금씩 달라지고 있습니다. 배포 도구가 반복되는 설정을 줄이고 있고, AI 에이전트가 인프라 지식의 문턱을 낮추고 있습니다.

그리고 다음과 같은 상황이 생기기 시작한다면 서버를 어디에 둘 것인지와 별개로 접근 권한과 실행 방식을 정리할 시점입니다.

• 나 외에 다른 사람도 서버에 접근하기 시작했을 때
• AI 에이전트가 사람이 계속 지켜보지 않는 상황에서도 작업하기 시작했을 때
• 다시 만들기 어려운 데이터나 실제 고객 데이터를 다루기 시작했을 때
• 고객의 보안 검토나 감사 과정에서 누가 서버와 데이터에 접근할 수 있는지 설명해야 할 때

결국 정해야 하는 것은 하나입니다

처음에 관리형 서비스를 선택하는 이유는 명확합니다. 아직 제품이 될지 모르기 때문에 인프라에 먼저 투자하기 어렵고, 인프라를 깊이 알지 않아도 서비스를 시작할 수 있기 때문입니다. 시간이 지나면 비용이 먼저 눈에 들어오고, 서비스가 더 커지면 데이터와 서버를 얼마나 직접 통제할 수 있는지도 중요해집니다.

그런데 직접 운영하려고 하면 결국 같은 문제를 만나게 됩니다. 시작할 때는 없어도 됐던 인프라 역량이, 직접 운영하려는 순간 다시 필요해진다는 것입니다. 이 병목은 조금씩 달라지고 있습니다. 배포 도구가 반복되는 설정을 가져가고, AI 에이전트가 지식의 문턱을 낮추고 있습니다.

그다음 남는 문제는 모든 작업을 사람이 직접 하는 것이 아니라, 어떤 작업을 맡기고 어느 순간 사람이 개입할 것인지 정하는 일입니다. 필요한 것은 항상 옆에서 서버를 지켜볼 사람이 아니라, 중요한 순간에 실행을 멈추고 사람이 판단할 수 있는 자리일지도 모릅니다. 그 구조를 만들어두면 작은 팀도 예전보다 훨씬 적은 운영 부담으로 직접 서버를 다루는 선택을 할 수 있습니다.