SI SM 차이 5가지 | 우리 회사에 맞는 IT 계약은?
SI SM 차이가 헷갈리셨다면, 계약 정의부터 발주 순서·비용 산정·선택 기준까지 한 번에 정리했습니다. 우리 회사에 맞는 IT 유지보수 전략을 찾아보세요.
📍목차
IT 시스템을 새로 만들거나 기존 시스템을 운영해야 하는 자리에 앉으면 SI와 SM이라는 용어 앞에서 한 번쯤 멈칫하게 됩니다. 둘을 동시에 발주해야 할지, 구축이 끝난 뒤 따로 맺어야 할지, 비용은 어떻게 산정해야 할지 명확한 기준이 없으면 결정이 늦어지죠. 그 결과는 인수인계 공백, 과다 지출, 운영 장애로 돌아옵니다.
정리하면 SI(System Integration)는 시스템을 새로 구축하는 프로젝트성 계약이고, SM(System Management)은 구축이 끝난 시스템을 유지·운영하는 상시 계약입니다. 회사 규모와 시스템 안정성 단계에 따라 분리 발주, 통합 발주, 구독형 개발팀 중 무엇을 선택하느냐가 비용과 리스크를 동시에 잡는 핵심이에요.
이 글에서는 SI SM 차이를 정의·비교표·비용 산정 방식·발주 순서·선택 플로우차트 순으로 정리합니다. SM 뜻과 IT 업계에서 어떻게 쓰이는지부터, 두 계약을 분리할지 묶을지 판단하는 기준까지 한 번에 다루는데요. 끝까지 읽으면 우리 회사 상황에 맞는 계약 방식을 바로 결정할 수 있는 의사결정 기준이 손에 잡힙니다.
1. SI와 SM은 정확히 어떤 차이가 있을까?
SI/SM이란?
SI(System Integration, 시스템 통합)는 시스템을 새로 설계·구축해 오픈까지 책임지는 프로젝트형 계약이고, SM(System Management, 시스템 운영관리)은 운영 중인 시스템을 유지·개선·장애 대응하는 상시 운영 계약입니다. 계약 형태·목적·산출물·종료 시점이 모두 다르죠.
SI는 명확한 시작과 끝이 있는 일회성 프로젝트입니다. 요구사항 정의부터 분석·설계·개발·테스트·오픈까지 단계별로 진행되며, 검수가 완료되고 하자보수 기간이 끝나면 계약이 종료돼요. 반면 SM은 시스템이 오픈된 이후부터 운영 종료 시점까지 지속되는 상시 계약입니다. 월 단위 또는 연 단위로 갱신하면서 시스템이 안정적으로 돌아가도록 관리합니다.
SI와 SM의 차이를 항목별로 정리하면 다음과 같습니다.
참고로 국내 SW 시장 규모는 2023년 기준 19.3조 원(패키지SW·IT서비스 합계)으로 IT서비스 부문이 전년 대비 3.1% 성장했으며, 이 안에 SI·SM 사업이 대부분 포함됩니다.
1-1. SI 계약은 언제 끝나고 무엇을 산출물로 받게 될까?
SI 계약은 시스템 오픈 후 검수 완료와 하자보수 기간 종료 시점에 끝납니다. 보통 검수 후 3~6개월의 하자보수 기간을 두는 것이 일반적이에요.
이 기간에 발견된 결함은 추가 비용 없이 개발사가 수정해야 합니다. 발주사가 받게 되는 표준 산출물은 소스코드 일체, 데이터베이스 스키마, 화면 설계서·요구사항 정의서 같은 설계 문서, 운영 매뉴얼, 인수인계 문서로 구성됩니다. 산출물 항목과 인도 시점을 계약서에 명시하지 않으면 오픈 후 소스코드를 받지 못하는 분쟁이 반복적으로 발생하죠.
특히 저작권 귀속 조항을 빠뜨리면 발주사가 비용을 다 내고도 시스템 수정 권한을 갖지 못할 수 있어 주의가 필요합니다.
1-2. SM 계약은 단순 장애 대응만 포함되는 게 아닐까?
SM 계약은 장애 대응에 한정되지 않습니다. 일상 운영부터 성능 개선, 소규모 기능 추가까지 포함하는 경우가 많아요.
표준적인 SM 업무 범위는 장애 모니터링과 긴급 대응, 정기 패치·보안 업데이트, 사용자 문의 대응, 성능 튜닝, 월 단위 운영 리포트 작성으로 구성됩니다. 여기에 월 일정 공수(MM, Man-Month) 안에서 소규모 기능 추가나 개선 요청을 처리하는 조건이 붙기도 하죠.
다만 대규모 기능 개발이나 시스템 재구축은 SM 범위를 벗어나며, 별도 SI 프로젝트로 진행하는 것이 일반적입니다. 계약 시 어디까지가 SM이고 어디부터 추가 발주인지 경계선을 SLA(Service Level Agreement, 서비스 수준 협약) 문서로 명문화해야 운영 중 분쟁을 피할 수 있어요.
2. SI와 SM은 동시에 맺어야 할까, 끝나고 따로 맺어야 할까?
SI가 끝나자마자 다른 사업자에게 SM을 맡기면, 새 팀은 코드와 업무 규칙을 처음부터 배워야 합니다. 인수인계 기간은 보통 1~3개월 — 이 사이에 장애가 터지면 원인 파악부터 늦어져요. 반대로 통합 발주는 이 공백 자체가 없고, 운영비 경쟁력이 필요하거나 내부 조직을 키울 계획이 있다면 분리 발주나 단계적 전환이 현실적인 선택지가 됩니다.
발주 방식은 크게 세 가지입니다. 같은 사업자에게 구축과 운영을 한꺼번에 맡기는 통합 발주, 구축이 끝난 뒤 운영사를 따로 입찰하는 분리 발주, SI 사업자에게 일정 기간만 SM을 맡긴 뒤 내부 인력으로 이관하는 단계적 전환. 어떤 방식을 택하느냐에 따라 운영 공백의 길이와 총소유비용(TCO)이 달라집니다.
2-1. 통합 계약이 인수인계 리스크를 줄이는 이유는 뭘까?
SI를 수행한 인력이 그대로 SM에 투입되기 때문입니다. 구축 과정에서 쌓인 도메인 지식과 코드 맥락이 운영 단계로 자연스럽게 이어지죠.
분리 발주를 하면 새 SM 사업자가 코드와 업무 규칙을 처음부터 학습해야 합니다. 인수인계 기간은 보통 1~3개월이 걸리는데, 이 시기에는 장애가 발생해도 원인 파악이 늦어지고 핫픽스 대응이 지연돼요. 특히 결제·재고·정산처럼 비즈니스 로직이 복잡한 핵심 시스템일수록 인수인계 누락 한 줄이 수개월 뒤 대형 장애로 돌아옵니다.
통합 발주는 이 공백 자체를 만들지 않습니다. 오픈 직후 안정화 기간(보통 3~6개월)에 같은 팀이 운영을 이어받으므로, 장애 대응 평균 시간(MTTR)과 초기 결함 처리 속도가 분리 발주 대비 현저히 빠르죠.
2-2. 분리 계약이 더 유리한 상황은 어떤 경우일까?
분리 발주가 유리한 상황은 크게 세 가지입니다.
- 첫째, SAP·Salesforce처럼 널리 쓰이는 표준 제품 기반이라 운영할 수 있는 업체가 시장에 많은 경우.
- 둘째, 구축 단계에서 설계서·운영 매뉴얼·테스트 케이스가 체계적으로 정리된 경우.
- 셋째, 구축사 단가가 높아서 운영 단계에서는 다른 업체에 견적을 받아 비용을 낮춰야 하는 경우입니다.
반대로 자체 개발한 시스템이거나 복잡하게 커스터마이징된 ERP라면, 운영사를 바꿀 때 코드와 업무 규칙을 처음부터 파악해야 하는 시간과 비용이 단가 절감 효과보다 커질 수 있어요. 특정 사업자 없이는 시스템을 건드리기 어려운 상태(벤더 종속)가 될수록 통합 발주가 더 안전합니다.
👉 출시부터 후속 프로젝트까지 한 개발사와 함께한 사례 보러가기
3. SM 계약 비용은 보통 어떻게 산정할까?
SM 비용은 맨먼스(M/M) 단가 기반의 상주형, 월 정액제, 건당 과금형 3가지로 산정됩니다. 일반적으로 SI 구축 비용의 10~15%를 연간 SM 예산으로 책정하는 것이 업계 표준이에요.
세 가지 방식은 운영 부하·장애 빈도·내부 IT 인력 보유 여부에 따라 적합도가 갈립니다. 어떤 방식을 택하든 SLA(Service Level Agreement, 서비스 수준 합의서)와 장애 등급을 함께 정의해야 비용 산정의 근거가 명확해지죠. 아래 표로 세 가지 산정 방식의 구조와 적합 상황을 비교했습니다.
연간 SM 예산을 잡을 때는 SI 구축 비용의 10~15% 수준이 업계에서 통용되는 1차 기준선이에요. 다만 시스템의 사용자 수·장애 민감도·외부 연동 수가 많으면 20% 이상으로 올려 잡아야 운영 공백이 생기지 않습니다.
3-1. 맨먼스 단가는 직급별로 얼마나 차이가 날까?
SM 비용의 기준선이 되는 SW기술자 평균임금은 한국SW산업협회가 매년 공표합니다. 초급·중급·고급·특급 4단계로 구분되며, 직급이 한 단계 올라갈 때마다 단가가 유의미하게 뛰는 구조죠.
직급별 단가는 매년 조정되므로 견적을 받을 때는 최신 공표값을 기준으로 검증하는 것이 안전합니다. 2025년 적용 공표 기준으로 IT기획자 월평균임금은 약 1,005만 원, IT PM은 약 952만 원, 업무분석가는 약 1,112만 원 수준이며, 직무별로 일평균·시간평균임금도 함께 공표됩니다. 동일 인원이라도 직급 구성에 따라 월 비용이 크게 달라지므로, 견적서에는 반드시 직급별 투입 인원과 단가를 분리 명시하도록 요청하세요.
3-2. 장애 등급별 SLA는 어떻게 설계해야 할까?
SLA는 장애의 영향 범위에 따라 Severity 1~4로 분류하고, 등급별로 대응 시간과 복구 시간을 다르게 설계합니다. 등급이 모호하면 비용 산정 근거가 흔들리고 위약금 조항도 작동하지 않게 되죠.
대응 시간(인지·1차 회신까지)과 복구 시간(정상화까지)을 분리해 적어야 분쟁의 여지가 줄어듭니다. 위약금 조항은 보통 SLA 미달 시 월 운영비의 일정 비율을 차감하는 방식으로 설계하는데, SI SM 차이를 비용 측면에서 가장 크게 드러내는 항목이 바로 이 SLA 설계예요. 등급 정의·대응 시간·위약금 산식 세 가지가 계약서에 함께 들어가야 SM 비용이 단순 인건비 청구가 아닌 책임 기반 계약으로 작동합니다.
4. 프로젝트성 SI와 상주/비상주형 SM, 선택 기준은 뭘까?
한 번 만들고 끝나는 시스템은 SI 도급 계약, 지속적으로 기능을 추가·개선해야 하는 시스템은 SM 위임 계약이 맞습니다. 도급과 위임은 책임 범위와 R&R이 완전히 달라서 잘못 선택하면 분쟁의 원인이 됩니다.
SI SM 차이를 계약 형태로 좁혀 보면 결국 도급이냐 위임이냐의 선택입니다. 산출물이 명확하고 오픈 시점이 정해진 신규 구축은 프로젝트성 SI가 맞고, 운영 중 발생하는 변경 요청이 일상적이라면 SM이 적합한데요. 이 판단을 흐리면 계약은 도급인데 실제 업무는 위임처럼 흘러가 책임 소재가 모호해지는 일이 자주 생기죠.
아래 표로 판단 기준을 정리했습니다.
4-1. 도급과 위임은 책임 범위가 어떻게 다를까?
도급은 성과물 완성을 목적으로 하는 계약이고, 위임은 업무 처리 자체를 목적으로 하는 계약입니다.
민법 제664조는 도급을 "당사자 일방이 어느 일을 완성할 것을 약정하고 상대방이 그 일의 결과에 대하여 보수를 지급할 것을 약정함으로써 효력이 생긴다" 고 정의하는데요.
즉 수행사는 약속한 결과물을 만들어내야 보수를 받을 수 있고, 미완성이면 채무불이행 책임을 집니다.
반면 민법 제680조의 위임은 "당사자 일방이 상대방에 대하여 사무의 처리를 위탁하고 상대방이 이를 승낙함으로써 효력이 생긴다"고 규정합니다.
수임인은 결과를 보장하는 게 아니라 선량한 관리자의 주의의무(선관주의 의무)를 다하면 책임을 면하죠. SM에서 장애가 발생해도 수임인이 합리적인 운영 절차를 따랐다면 책임을 묻기 어려운 이유가 여기 있습니다.
이 차이를 모르고 SI 도급 계약서에 "운영 중 추가 요청 사항 포함"이라고 모호하게 적어두면, 발주사는 무한 변경을 기대하고 수행사는 완성 시점 이후 책임을 부정하면서 분쟁이 시작됩니다.
4-2. 내부 개발팀과 외주 SM 인력 사이 R&R은 어떻게 나눠야 할까?
내부 개발팀이 있다면 기술 방향은 내부에서 결정하고, 실제 구현은 SM 업체에 맡기는 방식이 일반적입니다. 내부는 시스템 방향성·기술 스택 선택·우선순위 결정을 맡고, 외주 SM 인력은 정해진 방향 안에서 개발·운영·장애 대응을 실행하는 구조죠.
이 경계를 흐리면 두 가지 문제가 생기는데요.
- 첫째, 외주 인력에게 아키텍처 결정권까지 위임하면 단기 편의 위주의 코드가 누적돼 기술 부채가 빠르게 쌓입니다.
- 둘째, 반대로 내부가 모든 결정을 쥐고 있으면서 의사결정이 늦어지면 SM 인력의 가동률이 떨어져 비용 낭비로 이어집니다.
역할 분담은 계약서에 한 줄 써두는 것보다, 실제로 어떻게 굴릴지를 구체적으로 정해두는 편이 훨씬 실효성이 높습니다. 예를 들어 "DB 구조 변경은 내부 담당자 승인 필수, 버그 긴급 수정은 SM 업체가 먼저 처리하고 사후 보고" 같은 식으로 상황별로 누가 결정하고 누가 실행하는지를 미리 끊어두는 거예요.
5. SI에서 SM으로 넘어갈 때 가장 자주 발생하는 함정은?
소스코드 인수인계 부실, 운영 매뉴얼 미비, 도메인 지식 단절 3가지가 SI에서 SM으로 넘어갈 때 가장 흔한 함정인데요. 이 세 가지가 누락되면 SM 사업자가 바뀐 첫 3개월 동안 장애 대응 시간이 평균 2~3배로 늘어납니다.
운영 전환기에 문제가 커지는 이유는 단순합니다. SI 단계에서 시스템을 만든 사람과 SM 단계에서 운영하는 사람이 다른데, 그 사이를 연결할 문서·코드·맥락이 부족하기 때문이죠. 특히 SI 사업자와 SM 사업자가 다른 경우, 인수인계 품질이 운영 안정성을 결정합니다. SI SM 차이를 이해하는 것만큼이나, 두 단계 사이의 전환 리스크를 관리하는 일이 중요한 이유예요.
대표적인 함정 5가지를 정리하면 아래와 같습니다.
5-1. 인수인계 체크리스트에 꼭 들어가야 할 항목은 뭘까?
인수인계는 받아야 할 항목을 하나씩 체크리스트로 정해두는 게 좋습니다. 코드만 받아서는 실제로 운영이 안 되거든요. 서버에 어떻게 올리는지(빌드·배포 환경), 실제 운영 데이터, 외부 서비스 연동 정보(결제 API, 알림 서비스 등)까지 한 세트로 넘겨받아야 새 운영사가 첫날부터 바로 대응할 수 있습니다.
최소한 아래 6개 카테고리는 체크리스트에 반드시 들어가야 합니다.
- 소스코드 일체: 저장소 접근 권한, 브랜치 전략, 빌드 스크립트, 의존성 버전 정보
- DB 스키마와 마이그레이션 이력: ERD, 인덱스 설계 의도, 과거 마이그레이션 스크립트
- 배포 파이프라인: CI/CD(빌드·배포 자동화 파이프라인) 설정, 배포 절차, 롤백 절차
- 계정·권한 인벤토리: 클라우드 콘솔, DB, 모니터링 도구, 외부 연동 키
- 외부 연동 정보: 결제·인증·푸시 등 외부 API(외부 시스템과 통신하는 인터페이스) 명세와 키 관리 방식
- 운영 이슈 이력: 과거 발생한 장애 목록, 원인, 조치 내역, 재발 방지책
이 6개를 SI 검수 단계에서 산출물로 확정해두면, SM 전환 시점의 분쟁 소지가 크게 줄어듭니다.
5-2. 운영 전환기에 옵저버 같은 PM 도구는 어떻게 활용할 수 있을까?
운영 전환기에는 인수인계 진행률을 실시간으로 볼 수 있어야 누락을 막을 수 있습니다. 옵저버 같은 IT 프로젝트 관리 도구를 활용하면 산출물·이슈·진행률을 한 화면에서 가시화할 수 있어요.
구체적으로 옵저버는 인수인계 단계에서 세 가지 역할을 합니다.
- 첫째, 산출물 체크리스트를 항목별로 관리해 어떤 문서가 인도됐고 어떤 게 누락됐는지 즉시 확인할 수 있습니다.
- 둘째, SI 사업자와 SM 사업자가 동일 화면에서 이슈를 주고받아 도메인 지식 전달 누락을 줄이는데요.
- 셋째, 전환 후 첫 1~3개월간 장애 대응 시간·해결률을 추적해 SLA 위반 여부를 객관적으로 판단할 수 있죠.
그릿지
6. SI·SM 대신 구독형 개발팀이 답이 되는 경우는 언제일까?
스타트업·중소기업처럼 시스템이 자주 바뀌고 SI와 SM을 명확히 나누기 어려운 회사라면, 그릿지 구독형 개발팀과 올인원 개발이 더 적합합니다. 월 단위 계약으로 구축과 운영을 동일 팀이 끊김 없이 처리하기 때문에 인수인계 공백 자체가 사라지죠.
전통적인 SI·SM 모델은 대규모 시스템을 한 번에 구축하고 오래 운영하는 환경에서 만들어진 구조예요. 그런데 요즘 스타트업이나 성장기 기업은 한 달에도 기능이 여러 번 바뀌고, 신규 모듈과 기존 운영이 동시에 진행되는 경우가 많습니다. 이런 환경에서는 SI 도급과 SM 위임을 칼같이 나누기보다, 월 단위로 인력 규모를 조정하는 구독형 모델이 의사결정 부담을 크게 줄여줍니다.
6-1. 구독형 개발팀은 SI·SM과 비용 구조가 어떻게 다를까?
가장 큰 차이는 프로젝트 단가가 아닌 필요한 만큼만 과금되는 구독이라는 점입니다. SI는 RFP 기반으로 전체 견적을 한 번에 산정하고, SM은 맨먼스(M/M, 1명이 1개월 일하는 공수 단위) 단가로 인력을 고정 배치하는데요. 구독형은 이 둘과 달리 월 단위로 필요한 인력 구성을 늘리거나 줄일 수 있습니다.
예산 예측 측면에서도 차이가 큽니다. SI는 변경 요청(Change Request)이 발생할 때마다 별도 견적이 붙고, SM은 상주 인력 수를 줄이기 어려워 운영비가 고정됩니다. 반면 구독형은 매월 청구되는 금액이 명확하고, 다음 달 인력 조정도 사전 협의로 가능하죠.
6-2. 올인원 개발은 어떤 단계의 회사에 잘 맞을까?
올인원 개발은 MVP(Minimum Viable Product, 최소 기능 제품)·초기 운영 단계의 회사 혹은 개발 전 단계를 일임하고자하는 니즈가 있는 회사에 가장 잘 맞습니다. AI 기반 개발 자동화로 구축 속도와 비용을 낮추면서, 테크리더의 코드 검수로 유지보수 가능한 품질을 동시에 확보하는 구조이기 때문이에요.
초기 스타트업은 보통 SI 견적이 부담스럽고, 그렇다고 SM 상주 인력을 둘 만한 규모도 아닙니다. 이 구간에서 올인원 개발은 구축 이후 그대로 운영·개선으로 이어질 수 있어서, SI에서 SM으로 넘어갈 때 발생하는 인수인계 공백이 처음부터 생기지 않습니다.
결국 중요한 건 '구축과 운영의 연결'입니다
SI는 시스템을 만드는 계약, SM은 운영을 책임지는 계약이지만 둘을 어떻게 잇느냐가 프로젝트의 성패를 가릅니다. 회사 단계와 시스템 변경 주기에 따라 발주 전략을 달리해야 하는데요. 인수인계 리스크가 가장 걱정된다면 같은 사업자에게 통합 발주하는 것이 안전하고, 비용 최적화가 우선이라면 SI 종료 후 SM을 별도로 입찰하는 방식도 검토해볼 수 있죠.
다만 스타트업·중소기업처럼 시스템이 분기마다 바뀌고 SI와 SM의 경계가 모호한 환경이라면, 전통적인 계약 분리 방식 자체가 맞지 않을 수 있습니다. 그릿지는 올인원 개발부터 구독형 개발팀과 옵저버를 통해 구축과 운영을 끊김 없이 이어가는 모델을 운영해왔는데요. 한 팀이 만들고 그대로 운영을 이어받기 때문에 인수인계 공백이 발생하지 않고, 프로젝트 진행 상황도 실시간으로 확인할 수 있어요.
SI와 SM 중 어떤 방식이 우리 회사에 맞는지, 혹은 구독형이 더 나은 선택지인지 함께 진단받아보세요.
자주 묻는 질문
Q1. SI 사업자가 그대로 SM까지 맡으면 가격 협상력이 떨어지지 않을까요?
SI 사업자가 SM을 연속 수주하면 발주사의 협상력은 분명 약해집니다. 시스템 내부 구조를 사업자만 알고 있어 교체 비용이 크기 때문인데요. 이를 방지하려면 SI 단계에서 산출물·소스코드·운영 매뉴얼 인수 조건을 명문화하고, SM은 3년 이내 단위로 재입찰 여지를 남겨두는 것이 안전합니다.
Q2. SM 계약에서 SLA 위반 시 위약금은 보통 어느 수준으로 설정하나요?
SM 계약의 SLA 위약금은 통상 월 운영비의 5~20% 범위에서 설정되는 경우가 많습니다. 장애 등급(긴급·중대·일반)과 응답시간·복구시간 기준을 명확히 나눠 차등 적용하는 방식이 일반적이죠. 단순 비율보다 핵심 업무 시스템 중단 시간을 기준으로 단계별 페널티를 두는 편이 실효성이 높습니다.
Q3. SI 종료 후 하자보수 기간과 SM 계약은 어떻게 구분되나요?
SI 하자보수는 구축 결함을 무상으로 고쳐주는 의무이고, SM은 운영·개선을 유상으로 맡기는 별개 계약입니다. 하자보수 기간은 통상 1년이며 범위는 검수 완료 시점의 산출물에 한정되는데요. 신규 기능 추가나 데이터 운영 업무는 하자가 아닌 SM 영역이므로 계약서에 양쪽 경계를 명시해 분쟁을 예방해야 합니다.
Q4. SM 계약을 1년 단위로 갱신하는 게 좋을까요, 다년 계약이 좋을까요?
SM 계약은 기본 1년 + 자동연장 조항을 두는 방식이 가장 안전합니다. 다년 계약은 단가 협상에 유리하지만 사업자 종속이 깊어지는 리스크가 있죠. 시스템 변경 주기가 빠른 스타트업·중소기업은 1년 단위로 성과 검토 후 갱신하고, 대규모 코어 시스템은 2~3년 계약에 중도해지 조항을 함께 두는 편이 균형 잡힌 선택입니다.
Q5. 내부에 운영 인력이 1~2명 있는데 SM을 외주로 맡길 필요가 있을까요?
내부 인력이 1~2명이라면 SM 외주 또는 하이브리드 구조를 권장합니다. 휴가·퇴사 시 시스템 운영이 즉시 중단될 수 있고, 야간·주말 장애 대응을 소수 인력으로 감당하기 어렵기 때문인데요. 내부 인력은 기획·도메인 지식 중심으로, 외주는 24/7 장애 대응과 기술 운영을 맡기는 분담 구조가 가장 효율적입니다.
Q6. SI 도중 SM 사업자를 미리 선정해두는 게 일반적인가요?
SI 후반부, 통상 검수 2~3개월 전부터 SM 사업자를 선정해두는 것이 일반적입니다. SM 사업자가 인수인계 단계부터 합류해야 운영 노하우와 소스코드 이해도가 확보되기 때문이죠. 같은 사업자가 SI·SM을 연속 수행한다면 별도 선정 절차는 생략되지만, 분리 발주 시에는 인수인계 기간을 최소 1개월 이상 계약에 포함해야 합니다.
참고 출처
