시스템 만들고 나서 드는 진짜 비용

시스템을 만들고 나서 한 달쯤 지나면, 대부분의 대표님들이 비슷한 말을 합니다.

"개발은 끝났는데… 왜 아직도 돈이 나가지?"

처음 예산을 잡을 때는 개발비만 봤습니다. 견적서에 찍힌 숫자, 계약서에 서명한 금액. 그게 '시스템 비용'이라고 생각했습니다. 그런데 오픈하고 나서 청구서가 계속 옵니다. 서버 비용, 유지보수 계약, 직원 교육, 데이터 이전, 추가 기능 요청. 어느 순간 "이거 처음 예산의 두 배는 쓴 것 같은데?"라는 생각이 드는 시점이 옵니다.

이게 착각이 아닙니다. 시스템의 진짜 비용은 구축 이후에 시작됩니다.

개발비는 빙산의 일각입니다

업계에서 통용되는 추산에 따르면, 소프트웨어 시스템의 총소유비용(TCO, Total Cost of Ownership) 중 초기 개발·구축비가 차지하는 비중은 평균 30~40%에 불과합니다. 나머지 60~70%는 운영 기간 동안 분산되어 나갑니다. 5년을 쓰는 시스템이라면, 개발에 5,000만 원을 썼을 때 운영비로 7,000만~1억 원이 추가로 나간다는 뜻입니다.

패션·유통 브랜드 입장에서 이 숫자가 특히 위험한 이유가 있습니다. 시즌마다 SKU 구성이 바뀌고, 매장이 늘거나 줄고, 프로모션 구조가 달라집니다. 시스템은 그 변화를 따라가야 하고, 따라가는 데는 항상 비용이 붙습니다.

구체적으로 어떤 항목들이 숨어 있는지 하나씩 짚어보겠습니다.

운영 기간에 발생하는 비용 4가지

1. 인프라·호스팅 비용 — 매달 나가는 고정비

클라우드 서버, DB 라이선스, 보안 인증서, 백업 스토리지. 이 항목들은 시스템을 켜두는 것만으로도 과금됩니다. 규모에 따라 다르지만, 연매출 50억~100억 원대 브랜드가 운영하는 커스텀 시스템 기준으로 월 50만~200만 원 수준의 인프라 비용이 발생하는 경우가 일반적입니다. 5년이면 3,000만~1억 2,000만 원입니다. 처음 견적서에는 없던 숫자입니다.

2. 유지보수·버그 대응 비용 — 예측 불가능한 변동비

오픈 직후 6개월은 특히 조심해야 합니다. 실제 사용자가 쓰기 시작하면 개발 단계에서 발견하지 못했던 오류들이 나옵니다. 시즌 마감 직전에 발주 모듈이 오작동하거나, 재고 수치가 맞지 않거나, 특정 조건에서 정산이 틀리는 경우. 이런 긴급 대응은 통상 개발비의 10~20%가 추가로 나갑니다.

유지보수 계약을 맺은 경우에도 '계약 범위 밖' 이슈는 별도 청구됩니다. 계약서를 꼼꼼히 읽지 않으면 이 경계가 어디인지 알기 어렵습니다.

3. 기능 추가·변경 비용 — 비즈니스가 바뀌면 시스템도 바뀌어야 합니다

이 항목이 가장 과소평가됩니다. 시스템을 만들 때는 현재의 프로세스를 기준으로 설계합니다. 그런데 1년 후 매장이 5개 더 생기거나, 온라인 채널을 새로 열거나, 브랜드를 하나 더 추가하면 — 시스템은 그 변화를 수용하지 못합니다.

"조금만 수정하면 되지 않나요?"라는 질문을 많이 받습니다. 현실은 다릅니다. 초기 설계가 확장성을 고려하지 않았다면, '조금'이 수천만 원짜리 재개발로 이어지는 경우가 적지 않습니다. 특히 패션 브랜드처럼 시즌 구조, 가격 정책, 프로모션 로직이 복잡한 업종일수록 이 리스크가 큽니다.

4. 내부 운영 인력 비용 — 가장 잘 보이지 않는 비용

시스템이 생기면 그것을 관리하는 사람이 필요합니다. 전담 IT 인력이 없는 경우, 운영팀장이나 물류 담당자가 시스템 관련 문의를 처리하고, 데이터를 정리하고, 오류를 보고하는 역할을 떠안게 됩니다. 이 시간이 주당 5~10시간이라면, 연간으로 환산했을 때 해당 직원 인건비의 10~25%가 사실상 시스템 운영에 쓰이는 셈입니다.

이 비용은 어떤 청구서에도 나오지 않습니다. 그래서 더 위험합니다.

그렇다면 어떻게 판단해야 하는가

시스템 도입을 검토할 때 물어봐야 할 질문이 바뀌어야 합니다.

"개발비가 얼마인가요?"가 아니라,

이 질문에 제대로 답할 수 있는 파트너라면, 적어도 다음 세 가지를 구체적으로 제시할 수 있어야 합니다.

① 인프라 비용 구조 — 클라우드 사용량 기준인지, 고정 요금인지. 트래픽이 늘면 비용이 어떻게 변하는지.

② 유지보수 범위의 명확한 정의 — 버그 수정, 법적 요건 변경 대응, 보안 패치가 포함되는지. 기능 변경은 어떤 기준으로 별도 청구되는지.

③ 확장 시나리오별 예상 비용 — 매장 10개 추가, 브랜드 1개 추가, 채널 확장 시 추가 개발 범위와 비용 추정.

이 세 가지를 명확히 설명하지 못하는 파트너와 계약하면, 나중에 나오는 청구서가 항상 '예상 밖'이 됩니다.

비싼 시스템이 꼭 나쁜 건 아닙니다 — 기준이 잘못된 게 문제입니다

초기 개발비가 낮은 시스템이 5년 TCO 기준으로 더 비싸게 나오는 경우는 생각보다 많습니다. 유지보수 비용이 높거나, 확장할 때마다 재개발이 필요하거나, 내부 운영 부담이 크면 — 처음에 아꼈던 비용이 운영 기간 동안 몇 배로 돌아옵니다.

반대로, 초기 비용이 다소 높더라도 운영 비용이 예측 가능하고, 변경 비용이 합리적이고, 내부 운영 부담이 낮은 시스템은 장기적으로 훨씬 효율적입니다.

패션·유통 브랜드처럼 시즌마다 조건이 바뀌는 업종에서는 특히 그렇습니다. 시스템이 비즈니스 속도를 따라오지 못하면, 결국 사람이 그 갭을 엑셀로 메웁니다. 그리고 그 엑셀을 관리하는 사람의 시간이 또 다른 비용이 됩니다.

시스템의 진짜 비용을 알고 나서 계약하는 것과, 오픈하고 나서 하나씩 알게 되는 것 사이에는 — 수천만 원의 차이가 있습니다. → 문의하기