SI와 SM은 어떻게 다를까요 | 구축·운영 예산이 갈리는 5가지
SI는 시스템을 새로 짓는 일, SM은 지어진 시스템을 돌리는 일이에요. 유지관리요율은 정부 권고가 20%인데 공공 현장은 10% 미만이 41.4%였어요. SI업체와 SM 계약을 어떻게 나눠야 하는지 운영해본 개발사 기준으로 정리했어요.

핵심 요약 — SI(System Integration)는 시스템을 새로 짓는 일이고, SM(System Management)은 지어진 시스템을 계속 돌리는 일이에요. 예산 구조가 완전히 달라서, 구축비만 잡고 시작하면 오픈 다음 달부터 계획에 없던 비용이 붙어요. 유지관리요율은 정부 권고가 20% 이상인데 공공 현장 조사에서는 10% 미만을 적용한 기관이 41.4%로 가장 많았어요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.
“구축 견적은 받았는데, 오픈하고 나면 매달 얼마가 드는지는 아무도 안 알려주더라고요.” 시스템 발주를 준비하는 분들이 자주 하시는 말이에요. SI기업에서 받은 제안서에는 개발 범위와 일정이 촘촘히 적혀 있는데, 운영 이야기는 마지막 장에 한 줄로 끝나는 경우가 많거든요.
1. SI와 SM은 정확히 무엇이 다른가요

만드는 쪽이 SI, 돌리는 쪽이 SM이에요. SI는 신규 구축이나 차세대 전환처럼 없던 시스템을 만들어 넘기는 일이고, SM은 이미 돌아가는 시스템의 장애를 잡고 기능을 손보며 운영하는 일이에요.
건물에 비유하면 이해가 빨라요. SI는 설계도를 그리고 건물을 올리는 시공이고, SM은 준공 후 관리사무소예요. 시공사는 준공하면 떠나지만 관리사무소는 건물이 서 있는 동안 계속 있어야 하죠.
용어 정리 — SI: 흩어진 시스템과 데이터를 하나로 묶어 새로 구축하는 개발 작업이에요. SM: 구축이 끝난 시스템의 운영·유지관리를 맡는 계약이에요. SLA: 장애를 몇 시간 안에 처리할지처럼 서비스 수준을 숫자로 약속하는 조항이에요. 실무에선 “이번 건은 SI로 짓고 SM은 1년 뒤부터”처럼 나눠서 말해요.
2. 발주자 입장에서 이 구분이 왜 예산을 가를까요

예산을 세우는 단위가 다르기 때문이에요. SI는 한 번에 끝나는 프로젝트 예산이고, SM은 매년 반복되는 운영 예산이에요.
여기서 실수가 나와요. 올해 예산에 구축비만 올려두고 다음 해 운영비를 못 잡으면, 시스템은 만들어졌는데 손볼 사람이 없는 상태가 돼요. 그러면 급한 장애가 날 때마다 건별로 발주하게 되고, 결과적으로 연간 계약보다 돈이 더 나가요.
SI개발비용을 검토할 때 운영 3년치를 같이 그려보시길 권해요. 구축 단계에서 선택한 기술과 구조가 이후 운영비를 그대로 결정하거든요.
3. SM 비용은 어떤 방식으로 계산되나요

계산 방식은 크게 세 가지로 나뉘어요. 한국소프트웨어산업협회가 내는 SW사업 대가산정 가이드(2025년 개정판)가 이 방식들을 정리해두고 있어요.
공식 외부 기준 (SW사업 대가산정 가이드)
| 산정 방식 | 계산 구조 | 어떤 경우에 맞나요 |
|---|---|---|
| 요율제 | 구축비에 일정 비율을 곱해 연간 금액 산정 | 기능 변경이 적고 안정적으로 도는 시스템 |
| 투입공수 방식 | 상주·비상주 인력의 등급과 인원으로 산정 | 개선 요청이 꾸준히 들어오는 시스템 |
| 고정비·변동비 방식 | 기본 운영은 고정비, 추가 개발은 별도 정산 | 통합 운영유지관리처럼 범위가 넓은 사업 |
가이드는 요율제와 투입공수를 적용하는 통합운영유지관리사업, 고정비와 변동비를 나누는 사업을 각각 예시로 들고 있어요. 어느 쪽이 유리한지는 시스템 성격에 달렸어요. 기능이 자주 바뀌는데 요율제로 묶으면 개발사가 추가 요청을 받기 어려워지고, 변화가 거의 없는데 상주 인력을 두면 인건비만 나가요.
4. 유지관리요율은 몇 퍼센트가 적정할까요

정부 권고는 20% 이상이지만 현장은 그보다 낮아요. SW산업 실태조사(2018년 조사 기준)를 보면 공공 부문에서 평균 10% 미만 요율을 적용한 기관이 41.4%로 가장 많았고, 10~15% 미만이 53.3%였어요. 15~20% 미만은 4.3%, 20% 이상은 0.9%에 그쳤고요. 같은 조사에서 민간 부문 평균은 14.2%로 공공보다 4.0%포인트 높게 나왔어요.
숫자만 보면 낮을수록 좋아 보이지만 반대예요. 요율이 낮으면 개발사는 최소 인력만 붙일 수밖에 없고, 장애가 나도 대응이 느려져요. 요율을 깎는 대신 대응 범위를 줄이는 쪽이 서로에게 정직해요.
자사 실무 기준 예시 (프로젝트 성격에 따라 달라져요)
| 시스템 성격 | 연간 운영 예산 감각 | 함께 정해둘 것 |
|---|---|---|
| 사내 업무 시스템, 변경 적음 | 구축비의 10% 안팎 | 장애 대응 시간, 정기 점검 주기 |
| 고객이 쓰는 서비스, 개선 지속 | 구축비의 15% 안팎 | 월 개선 공수 한도, 배포 주기 |
| 실시간 처리·외부 연동 다수 | 구축비의 15% 이상 | 야간 대응 여부, 모니터링 범위 |
5. SI 업체와 SM 업체를 따로 두면 무엇이 달라질까요

인수인계 품질이 결과를 갈라요. 구축한 SI회사와 운영을 맡는 SM 조직이 다른 구조 자체는 흔하고, 공공에서는 오히려 기본에 가까워요.
문제는 넘겨받는 내용이에요. 소스코드만 받고 배포 절차나 설정값, 장애 이력이 안 넘어오면 새 담당자는 코드를 읽는 데만 몇 달을 써요. 그 기간에 장애가 나면 원인 파악이 늦어지고요.
운영사 Tip — 구축 계약서에 인계 산출물 목록을 항목으로 적어두세요. 저장소 접근 권한, 배포 매뉴얼, 서버·계정 정보 인계 절차, 최근 장애 이력과 조치 내역, 외부 연동 문서까지요. 계약 종료 시점에 요청하면 늦어요. 저희는 자체 SaaS 4종을 직접 운영하면서, 이 목록이 있는 프로젝트와 없는 프로젝트의 인계 기간이 몇 배씩 차이 나는 걸 봤어요.
6. 구축 계약에 운영을 미리 넣으려면 뭘 챙겨야 할까요

네 가지만 넣어두면 대부분 정리돼요.
- 안정화 기간 — 개발 완료일과 실제 오픈일 사이에 조정 기간을 명시해요. 이 구간이 비어 있으면 오픈 직후 문제를 누가 볼지가 애매해져요.
- 하자보수 범위와 기간 — 무상으로 고치는 범위와 유상 개선의 경계를 적어요. 구분이 없으면 사소한 요청마다 협의가 붙어요.
- SLA 기준 — 장애 등급별 대응 시간과 연락 체계를 숫자로 정해요.
- 인계 산출물 목록 — 5번에서 정리한 항목을 그대로 조항에 넣어요.
SI 프로젝트(SI project) 문서에서 이 네 가지가 빠져 있으면 운영 단계에서 협상력이 사라져요. 구축이 끝난 뒤에는 발주자 쪽에 남은 카드가 거의 없거든요.
7. 흔히 놓치는 지점은 어디일까요
세 가지를 자주 봐요.
첫째, 운영 인력을 사람 수로만 정하는 경우예요. 두 명이 상주한다는 조건보다 어떤 요청을 며칠 안에 처리하는지가 실제 만족도를 결정해요.
둘째, 기능 개선을 유지보수에 넣어달라고 요청하는 경우예요. 화면을 새로 만드는 일은 운영이 아니라 개발이에요. 이걸 섞으면 개발사는 최소한으로 반응하게 되고 관계가 나빠져요.
셋째, 클라우드 사용료를 운영비에서 빼놓는 경우예요. SM 계약 금액과 별개로 매달 나가는 인프라 비용이 있어요. SI업체 견적에는 보통 구축 기간분만 들어가 있으니 따로 확인하셔야 해요.
8. 자주 묻는 질문
SI와 SM은 계약을 따로 해야 하나요?
보통 따로 해요. SI는 결과물 완성을 목적으로 하는 도급 계약이고, SM은 기간 단위로 운영 인력과 대응 수준을 정하는 계약이라 성격이 달라요. 다만 구축 계약을 쓸 때 안정화 기간과 인수인계 범위를 미리 넣어두면 SM 계약으로 넘어갈 때 공백이 줄어들어요.
SM 비용은 매년 얼마를 잡아야 하나요?
구축비의 10~15% 선에서 시작하는 경우가 많아요. 정부는 유지관리요율 20% 이상을 권고하지만 실제 현장은 이보다 낮게 형성돼 있어요. 장애 대응 시간을 짧게 요구하거나 기능 개선을 계속 넣을 계획이면 요율이 올라가니, 대응 수준을 먼저 정하고 금액을 맞추는 순서가 좋아요.
SI업체와 SM업체가 다르면 문제가 되나요?
구조 자체가 문제는 아니지만 인수인계 품질에 따라 결과가 크게 갈려요. 소스코드와 배포 절차, 설정값, 장애 이력이 문서로 넘어가지 않으면 새 업체는 코드를 읽는 데만 몇 달을 써요. 구축 계약서에 인계 산출물 목록을 적어두면 이 위험이 줄어들어요.
9. 정리하며
SI와 SM을 나눠서 보면 예산 계획이 훨씬 단순해져요. 짓는 비용과 돌리는 비용을 각각 세우고, 구축 계약 안에 운영으로 넘어가는 다리를 미리 놓아두는 거예요.
방향이 아직 명확하지 않아도 괜찮아요. 어떤 시스템인지, 이후 몇 년을 쓸 계획인지만 정리돼 있으면 운영까지 포함한 그림을 함께 그려볼 수 있어요 →. 저희는 11년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요.
관련 글 — SI 개발 비용, 도급 구조부터 봐야 하는 이유 · 유지보수 비용은 얼마를 잡아야 할까요 · 롯데백화점 푸드홀 실시간 혼잡도 시스템 구축 사례