Managed hosting vs self hosting에는 인건비가 필요하다

작은 도구 20개는 대개 많은 연산 자원이 필요하지 않습니다. 하지만 인증서 만료, 조용한 백업 실패, 로그인을 깨뜨리는 의존성 업데이트, 아무에게도 도착하지 않는 경고가 생길 기회는 20개입니다. 월 서버 요금만 비교하면 잘못된 답이 나옵니다.

이 정도 규모에서는 직원 시간과 업무 중단에 가격을 붙였을 때 관리형 호스팅이 보통 더 저렴합니다. 도구들이 잘 관리되는 공통 플랫폼을 쓰고, 팀이 이미 운영하며, 통제권이나 데이터 위치 요건이 작업을 정당화한다면 셀프 호스팅이 이길 수도 있습니다. 두 가격표가 아니라 총비용 모델로 결정해야 합니다.

가상 머신이 아니라 운영되는 서비스를 비교한다

공정한 비교 단위는 사용자가 접속할 수 있고 누군가 복구할 수 있는 서비스입니다. 코드를 시작할 메모리만 있는 가상 머신이 아닙니다. 싼 서버 견적에는 배포 후 앱을 계속 쓰게 만드는 일이 빠져 있습니다.

두 선택지에 같은 서비스 경계를 정합니다. 런타임, 데이터베이스, 영구 파일, DNS, TLS 종료, 비밀값, 로그, 지표, 경고, 백업 저장소, 복구 절차, 배포, 롤백, 보안 업데이트, 장애 대응 소유자를 포함합니다. 관리형 요금제에 포함된 항목은 표시하고 고객에게 맡긴 항목은 셀프 호스팅 쪽에도 비용으로 넣습니다.

인프라 관리와 애플리케이션 책임은 다릅니다. 관리형 공급자는 호스트를 패치하고 고장 난 장비를 바꿀 수 있지만, 어제 스키마 마이그레이션이 열을 잃었는지 AI가 만든 권한 검사가 틀렸는지는 판단할 수 없습니다. 셀프 호스팅은 OS, 네트워크, DB, 모니터링까지 책임을 넓히며 앱 작업도 그대로 남습니다.

AWS 공동 책임 모델도 IaaS 고객이 게스트 OS, 패치, 애플리케이션 소프트웨어, 방화벽 구성을 관리한다고 설명합니다. 큰 공급자에게 가상 머신을 빌려도 앱이 관리형 서비스가 되지는 않습니다. 공급자는 아래의 물리 계층만 운영합니다.

책임 표부터 만드십시오. 모든 행에 담당자나 공급자와 약속된 대응을 씁니다. “자동”이라는 말은 자동화가 멈췄을 때 누가 알아차리는지 정해질 때까지 불완전합니다.

이 표는 완성된 관리형 서비스와 빈 서버를 비교하는 오류를 막습니다. DB 복구나 야간 대응을 고객에게 맡기는 요금제도 드러납니다.

업무 중단을 청구하는 비용 모델을 쓴다

쓸 만한 모델은 반복 현금 지출, 계획된 작업, 예상 밖 작업을 나눕니다. 낙관적인 월 금액 하나로 합치면 변동이 큰 부분이 사라집니다.

Annual cost = 12 x recurring monthly cash
            + planned engineering hours x loaded hourly rate
            + expected incident hours x loaded hourly rate
            + expected outage impact
            + one-time migration or platform work amortized over its useful life

현금 지출에는 연산, DB, 저장소, 백업, 외부 전송, 모니터링, 로그 보존, DNS, 유료 인증서, 지원을 넣습니다. 계획 작업에는 릴리스, 패치, 백업 점검, 복구 훈련, 접근 검토, 의존성 업데이트, 용량 변경, 문서화를 넣습니다. 장애 시간에는 진단, 수리, 복구, 소통, 재발 방지를 넣습니다.

실수령 급여가 아니라 회사 부담을 포함한 시간당 비용을 쓰십시오. 창업자가 밤에 작업해도 0원이 아닙니다. 그 시간에 밀린 제품, 영업, 고객 업무의 가치를 사용합니다. 무료 노동은 셀프 호스팅 계산표가 거짓말하는 지점입니다.

장애를 정확히 예측하는 척하지 말고 조용한 해, 예상한 해, 나쁜 해를 만듭니다. 조용한 해에는 정기 패치와 작은 문제, 예상한 해에는 배포 실패, 복구 요청, 시끄러운 경고, 긴급 업데이트, 나쁜 해에는 장시간 복구나 유출된 자격 증명을 넣습니다. 깔끔한 한 숫자보다 범위가 낫습니다.

예시일 뿐 보편 기준은 아닙니다. 실제 배포 빈도, 당직 기록, 복구 요건, 내부 단가로 바꾸고 기록이 없다면 범위를 넓게 둔 뒤 3개월 후 검토합니다.

재사용 플랫폼의 고정비도 넣습니다. 초기 구축비를 앱 수와 사용 기간에 나눕니다. 첫 도구에 전부 부과하지도, 20개 모두에서 없애지도 마십시오.

도구 20개는 연산보다 운영 표면을 빨리 늘린다

작은 앱은 CPU와 메모리를 합칠 수 있지만, 도메인, 비밀값, 사용자, DB 스키마, 릴리스 주기, 의존성, 복구 목표는 각각 남습니다. 서버 한 대가 컨테이너 20개를 실행해도 운영 표면은 사라지지 않습니다.

앱당 6분짜리 수동 작업은 전체에서 2시간이 됩니다. 분기 점검이면 연 8시간입니다. 조율, 실패, 문서화를 더하면 사소한 일이 아닙니다.

통합은 현금 비용을 낮추고 장애 범위를 키웁니다. 커널 업데이트, 가득 찬 디스크, 잘못된 프록시, 잃어버린 자격 증명이 모두를 멈출 수 있습니다. 호스트를 나누면 공통 장애는 줄지만 요금과 패치가 늘어납니다. 관리형 플랫폼은 이 일을 여러 고객에게 분산합니다.

도구를 폐기 가능한 시제품, 재생 가능한 데이터를 가진 내부 도구, 공식 데이터를 가진 업무 도구, 외부 공개 서비스로 나눕니다. 각 등급에 표준 런타임, 백업, 모니터링, 복구 목표, 폐기 규칙을 둡니다.

도구마다 가상 머신을 주면 격리를 설명하기 쉽지만 패치, 에이전트, 인증서, 구성, 유휴 용량을 복제합니다. 충돌하는 의존성, 민감한 작업, 다른 복구 목표처럼 이유가 있을 때만 강한 격리를 쓰고 나머지는 컨테이너나 공통 플랫폼에 둡니다.

반대로 모든 앱과 DB를 문서 없는 compose 파일 하나에 넣는 것도 거짓 절약입니다. 자원 제한, 이름 있는 영구 볼륨, 상태 검사, 예측 가능한 라우팅, 데이터 소유자가 필요합니다. 그렇지 않으면 과도한 내보내기가 디스크를 채워 전체 장애를 만듭니다.

버려진 도구도 세십시오. AI 개발은 생성을 싸게 만들어 방치된 실험을 쌓습니다. 매달 소유자, 사용자, 최근 배포가 없는 서비스를 찾습니다. 쓰지 않는 서비스를 없애는 편이 몇 푼의 컨테이너 최적화보다 위험과 작업을 잘 줄입니다.

백업은 복원이 필요해질 때까지 싸 보인다

백업은 시험된 절차로 서비스에 되돌릴 수 있는 사본입니다. 예약 작업이 파일을 업로드했다는 사실은 명령이 실행됐다는 증거일 뿐입니다.

“영업일 하루 분량의 변경을 잃을 수 있고 4시간 안에 복구한다”처럼 손실과 시간을 평범한 말로 적습니다. 메시지를 전달하는 폼과 고객 공식 기록을 가진 CRM은 다른 허용치를 가집니다.

비용은 사본 생성, 저장, 충분한 이력 보존, 복원 증명의 네 부분입니다. 마지막 부분이 보통 노동을 지배합니다. 훈련에는 깨끗한 대상, 자격 증명, 다운로드, DB 시작, 앱 검사, 복구 상태 판정이 필요합니다.

PostgreSQL 문서는 논리 객체와 데이터를 복구하는 pg_dump와, 기본 백업 및 WAL로 특정 시점을 복구하는 연속 보관을 구분합니다. WAL은 기본 백업까지 끊김 없이 있어야 합니다. 둘을 모두 “일일 백업”이라고 부르면 기능 차이가 숨겨집니다.

작은 DB는 하루 손실을 받아들일 수 있다면 암호화 dump로 충분할 수 있습니다. 호스트 밖에 여러 세대를 두고, 키 소유자를 기록하고, 실제로 복원합니다. 삭제 직전으로 돌아가야 한다면 그 기능이 있는 관리형 DB나 제대로 운영한 WAL 보관이 필요합니다.

service: inventory-tool
backup_object: inventory-tool/2026-07-12T020000Z.dump
restore_started: 09:14 UTC
restore_finished: 09:31 UTC
application_check: login, search, create and delete test record passed
recovery_point: 02:00 UTC
operator: initials

이 기록은 어떤 사본을 썼고 무엇을 검사했는지 증명합니다. 장애 때 사라질 수 있는 모니터링 안에만 두지 말고 운영 문서와 보관합니다.

관리형 백업도 보존 기간, 지역, 암호화, 내보내기, 삭제, 새 DB 생성인지 기존 DB 덮어쓰기인지 확인합니다. 업로드 파일과 비밀값 포함 여부도 봅니다. 공급자가 기계를 맡아도 정책 선택과 실제 복원 검증은 고객 몫입니다.

SSL과 모니터링은 소유자가 있는 자동화다

TLS 인증서는 무료여도 작업을 만듭니다. DNS, 챌린지, 프록시 재적재, 만료 경고가 모두 작동해야 합니다.

Let's Encrypt는 짧은 유효 기간이 자동화를 장려한다고 설명합니다. 타당하지만 “Let's Encrypt를 쓴다”는 절차가 아닙니다. ACME 클라이언트, 일정, 챌린지 종류, DNS 권한, 재적재 방식, 만료 경고, 실패 담당자를 적습니다.

도메인 20개를 수동 관리하는 것은 옳지 않습니다. 발급과 갱신을 자동화하고 호스트 밖에서 결과를 검사합니다. 외부 검사는 디스크에만 있고 프록시가 읽지 않은 인증서, DNS 오류, 죽은 서버도 찾습니다.

Prometheus 지침은 사용자 고통과 연결된 증상에 경고하고 행동할 수 없는 호출을 피하라고 합니다. CPU, 메모리, 컨테이너, DB, 프록시 경고를 복사하면 누가 막혔는지 설명하지 못하는 메시지가 쌓입니다.

외부 가용성, 오류율, 지연, 디스크 용량, 백업 최신성, 인증서 만료부터 시작합니다. 사람이 곧 행동해야 할 때만 호출하고 용량과 유지보수는 주간 대기열로 보냅니다. 모든 경고에 소유자, 짧은 진단 경로, 억제 방법이 필요합니다.

모니터를 모니터링하십시오. 검사 하나와 알림 경로를 호스트 장애 영역 밖에 둡니다. 관리형 플랫폼이 실제 앱 경로를 검사하는지, 알림이 대응 요건과 맞는지 확인합니다.

로그 보존도 비용입니다. 채팅으로 만든 도구는 과한 요청 로그, 경고, 반복 스택 트레이스를 쓸 수 있습니다. 용도에 따라 보존하고 비밀값과 개인정보를 거릅니다. 무제한 보존은 비싸고 위험하며 보존하지 않으면 첫 장애가 길어집니다.

업그레이드하면 생성 코드는 팀의 코드가 된다

AI 생성 소프트웨어를 배포하는 순간 운영자가 유지보수를 맡습니다. 생성 모델은 패키지를 패치하거나 런타임 업그레이드를 시험하거나 몇 달 뒤 사라진 간접 의존성을 설명하지 않습니다.

OS, 기본 이미지, 언어 런타임, 프레임워크, 패키지, DB, 프록시, 모니터링, 배포 도구를 계산합니다. 관리형 플랫폼이 호스트와 런타임을 줄여도 앱 의존성은 남습니다. 소스 내보내기는 탈출 경로이지 자동 운영이 아닙니다.

잠긴 의존성, 소수의 자동 테스트, 상태 endpoint, 명시적 DB 마이그레이션, 알려진 이전 릴리스를 표준 build 계약으로 둡니다. 없으면 업그레이드 때마다 생성 코드를 발굴해야 합니다.

정기 유지보수 시간을 잡고 낮은 위험 업데이트를 묶어 image를 다시 만들고 대표 도구에서 시험한 뒤 같은 등급으로 넓힙니다. 보안 수정은 빠른 경로를 씁니다. 지원 종료 런타임을 한 화면에 모읍니다.

스냅샷과 롤백은 복구를 빠르게 하지만 DB 계획을 대신하지 않습니다. 파괴적 마이그레이션 뒤 코드만 되돌리면 이전 코드가 새 스키마를 만납니다. 필드 추가, 두 상태를 지원하는 코드 배포, 데이터 이동, 나중 릴리스에서 이전 필드 삭제 순서를 사용합니다.

계획 모드는 생성 앱을 바꾸기 전에 범위, 데이터 변경, 구성 요소를 검토하게 합니다. Koder.ai는 계획, 배포, 호스팅, 사용자 도메인, 스냅샷, 롤백을 묶고 소스 내보내기를 출구로 둡니다. 어떤 호스팅도 배포한 동작의 책임을 없애지 않으므로 앱 유지보수 비용은 남습니다.

배포 명령이 성공했다고 업그레이드가 끝난 것은 아닙니다. 로그인, 읽기, 쓰기, 백그라운드 작업, 변경된 기능을 검사합니다. 목적 있는 다섯 검사가 주인 없는 초록색 테스트보다 낫습니다.

장애 대응 비용은 가장 나쁜 시간에 온다

장애 비용에는 중단이 포함됩니다. 내부 도구 하나가 재무 업무를 막고 20명을 기다리게 하거나 오류가 쉬운 스프레드시트로 돌아가게 할 수 있습니다. 공개 도구는 직접 매출이 없어도 지원 업무를 만듭니다.

한 셀프 호스팅 장애를 따라가 봅시다. 큰 내보내기 파일이 볼륨을 채우고 디스크 경고는 오래된 메일함으로 갑니다. 밤에 디스크가 가득 차 PostgreSQL과 다른 컨테이너가 쓰기를 멈춥니다. 아침에 공간을 비우고 재시작하자 불완전한 DB 파일이 보입니다. 야간 dump는 있지만 9개월 동안 복원하지 않았고 암호화 키는 떠난 계약자 소유였습니다.

서버 청구액은 거의 변하지 않습니다. 여러 계층 진단, 백업 불확실성, 직원 시간, 복구, 상태 안내, 후속 수정이 비쌉니다. 범위에 따라 관리형 호스팅이 디스크와 DB 문제 일부를 막을 수 있지만 나쁜 앱 내보내기나 사용자 연락까지 해결하지는 않습니다.

근무 외 경고 수신자, 응답 시간, DNS 변경, 복구, 비밀값 교체, 상태 안내 권한, 휴가 대체자를 정합니다. 답이 “개발자”라면 접근 권한, 문서, 유급 시간을 확인합니다.

20개 도구가 항상 24시간 당직을 요구하지는 않지만 명확한 서비스 시간이 필요합니다. 일부 내부 도구는 다음 영업일까지 기다려도 됩니다. 사용자에게 알리고 경고를 맞춥니다.

장애 뒤 영구 수정 비용을 올바른 선택지에 넣습니다. 반복 디스크 청소, 인증서 수리, 모니터 유지보수는 셀프 쪽이고 공급자의 반복 배포 실패나 느린 지원은 관리형 쪽입니다.

셀프 호스팅은 공통 플랫폼과 이유가 있을 때 이긴다

이미 관리되는 플랫폼, 남는 운영 역량, 관리형 제품이 경제적으로 충족하지 못하는 요건이 있으면 더 저렴할 수 있습니다. 가상 머신 한 대가 싸다는 이유만으로는 부족합니다.

신뢰할 수 있는 계획에는 표준 템플릿, 자동 배포, 중앙 비밀값, 외부 모니터링, 자동 TLS, 분리된 백업 저장소, 검증된 복구, 패치 소유자, 자원 제한, 문서화된 폐기 절차가 있습니다. 도구마다 새 서버 그림이 필요하면 공통 플랫폼의 고정비가 회수되지 않습니다.

데이터 거주, 네트워크 격리, 특수 런타임, 예측 가능한 고사용량, 기존 규정 경계는 통제권 비용을 정당화할 수 있습니다. 금액이나 필수 조건을 붙이십시오. “통제를 선호한다”는 말은 청구서와 비교할 수 없습니다.

작은 팀, 들쭉날쭉한 사용량, 잦은 생성과 삭제, 운영 담당자 부재에는 관리형이 더 나은 기본값입니다. 한도, 백업, 로그, 지역, 도메인, 롤백, 내보내기, 지원 응답을 확인합니다.

self_hosting_saving = managed_annual_cash - self_hosted_annual_cash
hours_available = self_hosting_saving / loaded_hourly_rate

연 6,000달러를 절약하고 시간당 비용이 100달러면 연 60시간, 월 5시간으로 20개 도구의 패치, 모니터링, 백업, 복구 훈련, 실패, 장애를 처리해야 합니다. 이 계산은 승자를 정하지 않지만 불가능한 계획을 보여 줍니다.

장애 시간을 두 배로 만들고 두 번째 운영자를 넣거나 도구 3개에 시점 복구를 요구해 봅니다. 작은 가정으로 답이 뒤집히면 안정적인 비용 우위를 주장하지 말고 위험 허용도와 통제 요건으로 고릅니다.

90일 운영 시험으로 결정한다

가장 방어하기 쉬운 선택은 자체 포트폴리오에서 측정한 작업을 씁니다. 대표 그룹을 90일 운영하고 모든 현금과 직원 작업을 기록한 뒤 20개로 투영합니다.

폐기 가능한 시제품, DB가 있는 내부 도구, 외부 공개 앱을 포함합니다. 변경 배포, 인증서 갱신, 깨끗한 환경 복원, 릴리스 롤백, 비밀값 교체, 경고 발생, 도구 폐기를 수행합니다. 조용한 가동 시간만 재면 비교할 일을 놓칩니다.

활동과 대기를 나눕니다. 다운로드 중 다른 일을 할 수 있지만 15분 중단에도 문맥 전환 비용이 있습니다. 두 선택지에 같은 규칙을 적용합니다.

90일째 반복 작업을 연간으로 바꾸고, 일회성 설정을 분리하고, 세 장애 사례를 비교합니다. DNS 복구, 지역 배치, 지원 에스컬레이션처럼 시험하지 않은 책임은 “알 수 없음”으로 표시합니다.

대부분의 팀에서 연산 비용은 가장 작은 쟁점이 됩니다. 추가 현금이 남은 책임에 쓰는 시간보다 더 많은 직원 시간을 사면 관리형이 이깁니다. 재사용 플랫폼이 손익분기 시간 아래로 일을 유지하고 통제권에 분명한 목적이 있으면 셀프 호스팅이 이깁니다.

복구, 패치, 경고, 장애 옆에 담당자 이름이 쓰이기 전에는 싸 보이는 계획을 승인하지 마십시오. 서버는 상품입니다. 믿을 수 있는 소유권이 부족한 자원입니다.