SI 구축 비용 2026, 앱개발·요구사항·유지보수 견적 기준

SI 구축 비용 앱개발 요구사항 유지보수 견적 검토 회의 장면 — SI 견적은 개발자 월수보다 요구사항 확정, 검수 기준, 운영 이관 범위에서 크게 갈린다.

SI 구축 비용을 검색하는 순간은 대개 이미 견적서가 너무 넓거나 너무 싸게 보이는 때다.

앱개발, 관리자 화면, 외부 연동, 데이터 이관, 보안 검수, 유지보수 항목이 한 줄 총액으로 묶이면 비교가 거의 불가능하다.

따라서 먼저 해야 할 일은 업체 이름을 고르는 것이 아니라 산정 단위를 같은 표로 맞추는 것이다.

핵심 요약

신규 개발비, 개선 개발비, 운영관리비, 유지보수비를 한 줄 총액으로 섞으면 안 된다.
KOSA 2026년 적용 SW기술자 일평균임금은 414,762원이며 직무별 단가 차이가 크다.
KOSA 민간용 ITO 서비스 단가는 운영관리 132,221원, 개선관리 826,856원을 제시한다.
SI 구축 비용은 요구사항 freeze, 검수 조건, 변경 요청, 운영 이관 범위를 계약서에 넣을 때 줄어든다.

이 글이 필요한 사람

앱개발 또는 업무 시스템 개발 외주 견적을 받았지만 금액 산정 근거가 보이지 않는 담당자.
SI 업체가 제시한 투입공수와 기능 범위가 맞는지 내부 검토해야 하는 IT 관리자.
ERP, CRM, 쇼핑몰, 모바일 앱, 관리자 콘솔, 레거시 DB 연동을 한 프로젝트로 묶을지 판단하는 구매 담당자.
구축 후 유지보수와 개선 개발 비용이 총액에 숨어 있는지 확인해야 하는 대표나 CFO.
개인정보, 관리자 권한, 감사로그, 소스코드 인수 조건을 검수 기준으로 넣어야 하는 보안 담당자.

SI 구축 비용은 앱개발비와 운영비를 분리해야 보인다

SI 구축은 시스템 통합이라는 말 때문에 범위가 쉽게 넓어진다.

모바일 앱개발, 웹 관리자, ERP 연동, 결제, 배치, 데이터 이관, 권한 관리가 동시에 들어가면 견적 단위가 흔들린다.

신규 개발은 기능 요구와 검수 산출물로 보고, 운영관리는 장애 대응과 정기 작업과 개선 요청으로 따로 본다.

이 구분이 없으면 구축이 끝난 뒤에도 하자, 유지보수, 추가 개발, 운영 대행을 두고 분쟁이 남는다.

구분	비용 동인	필수 산출물	견적서 질문
신규 구축	화면, 인터페이스, 배치, 권한, DB, 외부 연동	요구사항정의서, 화면정의서, 인터페이스 명세, 테스트 결과	기능별 검수 기준이 있는가
개선 개발	변경 요청, 기존 코드 분석, 회귀 테스트	변경 요청서, 영향도 분석, 배포 기록	운영관리 단가와 섞이지 않았는가
운영관리	장애 대응, 모니터링, 정기 점검, 문의 처리	SLA, 장애 리포트, 점검표	월 정액 범위와 제외 작업은 무엇인가
유지보수	하자 보수, 패치, 버전 업그레이드, 보안 조치	하자 기준, 보안 패치 기록, 릴리스 노트	무상 보증과 유상 변경의 경계는 어디인가
보안 검수	권한, 로그, 개인정보, 취약점 조치	권한 매트릭스, 감사로그 샘플, 취약점 조치 확인	검수 실패 때 비용 책임은 누구인가

공식 숫자로 잡는 2026년 SI 견적 기준선

KOSA 공표 기준으로 2026년 적용 SW기술자 일평균임금은 414,762원이다.

같은 공표에서 IT기획자는 일 578,206원, IT컨설턴트는 일 522,340원, 업무분석가는 일 475,154원이다.

IT PM은 일 492,039원이고, IT아키텍트는 일 541,621원이다.

응용SW개발자는 일 378,250원, 시스템SW개발자는 일 284,888원, 정보보안전문가는 일 507,887원이다.

민간용 SW사업 대가산정 가이드의 2026년 ITO 서비스 단가는 운영관리 132,221원, 개선관리 826,856원으로 게시됐다.

스마트제조혁신 원가계산 가이드는 SW개발비를 기능점수 방식으로 보며, 이윤율은 25% 이내로 적용한다고 설명한다.

공식 기준	2026 숫자	SI 구축 비용 해석	실무 확인
SW기술자 전체 평균	일평균 414,762원	평균 단가는 기준선일 뿐이다	직무별 투입 비율을 따로 본다
IT기획자	일 578,206원	업무 범위와 투자 타당성 정리에 반영된다	초기 기획 산출물 포함 여부 확인
IT PM	일 492,039원	일정, 리스크, 품질 관리 비용이다	PM 투입률과 보고 주기를 명시
IT아키텍트	일 541,621원	연동 구조와 확장성 설계 비용이다	아키텍처 산출물과 리뷰 기준 확인
응용SW개발자	일 378,250원	앱개발과 업무 로직 구현의 기준선이다	화면·인터페이스·배치별 공수 비교
정보보안전문가	일 507,887원	권한, 로그, 개인정보 검수 비용이다	보안 산출물과 조치 확인 조건
ITO 운영관리	서비스 단가 132,221원	장애·정기 운영 비용 기준이다	구축비와 분리 계약
ITO 개선관리	서비스 단가 826,856원	개선 개발 단위 비용 기준이다	변경 요청 범위와 승인 절차
스마트제조 원가 가이드	이윤율 25% 이내	공공 지원사업 원가 검토 상한 참고다	견적서의 이윤·경비 분리

기능점수와 투입공수 중 무엇으로 볼지 먼저 정한다

기능점수 방식은 요구 기능이 비교적 명확하고 화면정의서와 기능요구서가 있는 프로젝트에 맞다.

투입공수 방식은 탐색형 PoC, 레거시 분석, AI 적용, 불확실한 인터페이스처럼 기능 단위가 아직 흔들릴 때 쓴다.

기업마당의 스마트제조 원가계산 가이드는 SW개발비를 SW사업 대가산정가이드의 기능점수 방식 기준으로 본다고 설명한다.

같은 문서는 화면정의서와 기능요구서에 명시되지 않은 기능의 FP를 인정하지 않는 취지로 범위를 제한한다.

이 조건이면 기능점수 방식을 우선 검토한다.

화면, 출력물, 인터페이스, 배치, 외부 연동, 데이터 이관 범위가 문서로 정리된 업무 시스템이다.

이 경우는 투입공수와 단계 계약이 낫다.

현행 시스템 분석이 먼저이고, 요구사항이 매주 바뀌며, 개발보다 업무 재설계가 더 큰 프로젝트다.

산정 방식	맞는 상황	위험 신호	계약 보완
기능점수	요구사항과 화면이 확정된 업무 시스템	기능 누락을 나중에 추가 요구로 처리	변경 요청 단가와 승인 절차
투입공수	분석과 설계 불확실성이 큰 초기 구축	사람 월수만 있고 산출물이 없음	역할별 산출물과 주간 검수
고정가	범위가 좁고 검수가 명확한 모듈	업무 owner가 없는 넓은 프로젝트	범위 제외와 하자 기준
시간재료	레거시 분석과 유지개선이 많은 경우	예산 상한이 없고 backlog가 흐림	월 cap과 우선순위 회의
운영관리 단가	장애 대응과 정기 점검 중심	개선 개발이 운영비에 포함됨	개선관리와 운영관리 분리

앱개발이 포함된 SI는 화면 수보다 연동 수가 더 위험하다

앱개발 견적은 화면 수로 시작하지만 실제 비용은 인증, 결제, 알림, 파일, 관리자, 레거시 인터페이스에서 열린다.

외부 연동이 3개를 넘으면 개발비보다 장애 재처리와 로그 추적과 책임 구분 비용이 커진다.

SI 업체 견적서에서 인터페이스 연동을 한 줄로 적었다면 실패 큐, 재시도, 타임아웃, 수동 보정 화면을 따로 요구해야 한다.

이 조건이면 견적을 다시 쪼개야 한다.

모바일 앱, 관리자 웹, ERP, PG, 문자, 본인인증, 물류 인터페이스가 같은 일정 안에 묶여 있는 경우다.

유지보수와 개선 개발을 구축비에 넣으면 싸게 보인다

구축비에 12개월 유지보수가 포함됐다는 문장은 조심해서 봐야 한다.

무상 하자 보수, 장애 대응, 소규모 문구 수정, 기능 개선, 법령 변경 대응은 비용 성격이 서로 다르다.

KOSA의 민간용 서비스 단가도 운영관리와 개선관리를 서로 다른 단가로 제시한다.

따라서 SI 구축 비용 비교표에는 구축비, 하자 보증, 운영관리, 개선관리, 변경 요청 예비한도을 따로 둬야 한다.

항목	구축비에 섞이면 생기는 문제	분리 기준	검수 증거
하자 보수	개발 누락과 신규 요구가 뒤섞인다	명세 대비 결함만 무상	결함 티켓과 재현 절차
운영관리	장애 대응 시간이 개발팀 여유로 처리된다	SLA와 점검 주기 별도	장애 리포트와 점검표
개선 개발	작은 변경이 계속 무료 요구로 남는다	변경 요청서와 승인 단가	배포 기록과 영향도 분석
보안 패치	취약점 조치 책임이 흐려진다	심각도와 처리 기한 명시	취약점 조치 확인서
데이터 보정	마이그레이션 결함과 운영 실수가 섞인다	전환 검수와 운영 보정 분리	대조표와 승인 로그

보안 비용은 마지막 취약점 진단비가 아니다

SI 구축에서 보안 비용을 마지막 취약점 진단비로만 보면 늦다.

NIST SSDF는 보안 요구와 보안 검증을 개발 생명주기 안에 넣는 방식으로 설명한다.

OWASP ASVS는 인증, 세션, 접근통제, 검증, 오류 처리 같은 애플리케이션 보안 기준을 구조적으로 나눈다.

개인정보가 들어가는 앱개발이라면 관리자 권한, 마스킹, 다운로드 승인, 감사로그, 보관 기간을 요구사항 단계에서 잡아야 한다.

보안 항목	견적에 넣을 질문	빠질 때 비용	근거
접근통제	관리자와 운영자 권한을 역할별로 나눴는가	운영 중 권한 회수가 어렵다	OWASP ASVS 접근통제 기준
감사로그	개인정보 조회와 다운로드 로그를 남기는가	사고 조사와 분쟁 대응이 약해진다	ISMS-P와 내부 보안정책
시크릿 관리	인터페이스 키와 DB 비밀번호를 코드에 넣지 않는가	재발급과 장애 대응 비용이 생긴다	NIST SSDF
취약점 조치	검수 실패 때 재진단 비용 책임을 정했는가	오픈 지연과 추가 견적이 발생한다	ASVS와 보안 진단 범위
운영 이관	로그, 알림, 백업, 복구 테스트를 넘겨받는가	장애 때 SI 업체 의존이 남는다	운영 인수인계 체크리스트

실무 시나리오 1: 쇼핑몰 앱개발과 관리자 SI

회원, 상품, 주문, 결제, 배송, 쿠폰, 관리자 화면을 새로 만드는 쇼핑몰 앱개발 프로젝트를 가정하자.

이 조건이면 화면 수보다 결제, 물류, 재고, 정산, 개인정보 다운로드 연동을 먼저 쪼개야 한다.

요구사항이 확정됐다면 기능점수 방식으로 범위를 잡고, PG와 물류 인터페이스는 실패 재처리 화면을 별도 기능으로 둔다.

운영자는 오픈 전 주문 상태 전환, 환불, 부분 취소, 송장 정정, 개인정보 열람 로그를 실제 테스트 케이스로 확인해야 한다.

실무 시나리오 2: ERP 레거시 연동 SI

기존 ERP와 신규 영업 포털을 연결하는 프로젝트는 새 화면보다 데이터 정합성이 더 비싸다.

이 조건이면 DB 테이블 수, 배치 수, 인터페이스 수, 마이그레이션 리허설 횟수를 견적 단위로 둬야 한다.

현행 데이터 품질이 낮으면 개발 공수보다 대조표, 보정 규칙, rollback plan, 업무 owner 승인 시간이 늘어난다.

따라서 1차 계약은 분석과 설계 산출물 중심으로 끊고, 개발 계약은 확정된 인터페이스 목록 뒤에 체결하는 편이 안전하다.

실무 시나리오 3: 운영관리까지 맡기는 장기 SI 계약

구축 업체가 운영관리까지 맡는 계약은 초기 총액이 낮아 보일 수 있다.

이 조건이면 KOSA의 운영관리 단가와 개선관리 단가를 기준으로 장애 대응과 개선 개발을 분리해 본다.

월 정액에 개선 개발이 포함됐다는 표현은 변경 요청 한도, 우선순위 회의, 초과 단가, 배포 책임을 반드시 붙여야 한다.

보류해야 하는 경우도 분명하다.

요구사항 owner가 없고, 검수 기준이 없으며, 운영 로그와 소스코드 인수 조건이 계약서에 없는 프로젝트다.

SI 견적서에서 반드시 요구할 산출물

요구사항정의서에는 화면, 인터페이스, 배치, 데이터, 권한, 비기능 요구를 따로 적는다.
화면정의서에는 입력값, 오류 메시지, 권한별 노출, 검수 기준을 같이 둔다.
인터페이스 명세에는 인증 방식, timeout, retry, idempotency, 오류 코드, 재처리 owner를 적는다.
데이터 이관 계획에는 테이블 목록, 샘플 대조, 전환 리허설, rollback 조건을 넣는다.
테스트 계획에는 단위, 통합, 인수, 성능, 보안, 마이그레이션 검증을 분리한다.
운영 이관 문서에는 배포 절차, 모니터링, 백업, 복구, 계정 회수, 연락망을 넣는다.
유지보수 계약에는 하자 보수, 운영관리, 개선관리, 초과 변경 요청 단가를 구분한다.
소스코드, 빌드 스크립트, 배포 권한, 라이선스 목록, 보안 취약점 조치 결과를 인수 조건에 넣는다.

실무 스켈레톤: SI 구축 비용 범위 YAML

아래 YAML은 견적 요청 전에 범위를 고정하기 위한 검토용 스켈레톤이다.

# si-scope-estimate.yaml
# 목적: SI 구축 비용을 기능, 인력, 일정, 보안, 유지보수로 쪼개 견적 비교 단위를 맞춘다.
# 실제 금액은 KOSA 공표 임금, SW사업 대가산정 가이드, 발주 범위, 계약 조건으로 재산정한다.

project:
  primary_keyword: si_implementation_estimate
  service_type: new_build_or_enhancement
  target_systems:
    - customer_portal
    - admin_console
    - mobile_app_or_external_channel
    - erp_or_legacy_integration
  estimate_basis:
    function_point: required_if_scope_measurable
    man_month: allowed_for_planning_and_uncertain_scope
    maintenance_operation: separate_from_new_development

kosa_reference_values_2026:
  sw_engineer_daily_average_krw: 414762
  it_planner_daily_krw: 578206
  it_consultant_daily_krw: 522340
  business_analyst_daily_krw: 475154
  it_pm_daily_krw: 492039
  it_architect_daily_krw: 541621
  application_developer_daily_krw: 378250
  system_developer_daily_krw: 284888
  security_specialist_daily_krw: 507887
  ito_operation_service_unit_krw: 132221
  ito_improvement_service_unit_krw: 826856
  smart_factory_profit_cap_percent: 25

estimate_buckets:
  requirements_analysis: must_have
  ui_ux_and_screen_definition: must_have
  application_development: must_have
  integration_and_data_migration: must_have
  security_review_and_privacy: must_have
  test_and_acceptance: must_have
  deployment_and_stabilization: must_have
  maintenance_operation: separate_contract
  change_request_reserve: separate_limit

go_live_gate:
  block_if_no_requirements_owner: true
  block_if_acceptance_criteria_missing: true
  block_if_security_log_scope_missing: true
  block_if_maintenance_sla_mixed_with_build_estimate: true

핵심은 금액을 먼저 맞히는 것이 아니라 업체별 견적서가 같은 범위를 보고 있는지 확인하는 것이다.

간단한 견적 누락 점검 스크립트

아래 Python 예시는 실제 가격 계산기가 아니라 견적 누락 항목을 찾는 검토용 스켈레톤이다.

# si_estimate_review.py
# 견적 비교용 스켈레톤이다.
# 사람 단가와 기능점수는 공식 공표값과 실제 계약 조건으로 교체한다.

from dataclasses import dataclass

@dataclass
class SIEstimate:
    screens: int
    external_integrations: int
    data_migration_tables: int
    personal_data: bool
    batch_jobs: int
    test_cases: int
    acceptance_criteria: bool
    maintenance_months_included: int
    change_request_reserve_ratio: float


def review(quote: SIEstimate) -> list[str]:
    risks = []
    if estimate.screens > 40 and estimate.acceptance_criteria is False:
        risks.append('screen_count_without_acceptance_criteria')
    if estimate.external_integrations >= 3:
        risks.append('integration_failure_queue_and_owner_needed')
    if estimate.data_migration_tables >= 10:
        risks.append('migration_reconciliation_plan_needed')
    if estimate.personal_data:
        risks.append('privacy_log_retention_and_masking_needed')
    if estimate.test_cases < estimate.screens * 2:
        risks.append('test_scope_probably_underestimated')
    if estimate.maintenance_months_included > 0:
        risks.append('build_estimate_and_operation_estimate_mixed')
    if estimate.change_request_reserve_ratio < 0.1:
        risks.append('change_request_buffer_too_low')
    return risks


sample = SIEstimate(
    screens=55,
    external_integrations=4,
    data_migration_tables=14,
    personal_data=True,
    batch_jobs=8,
    test_cases=70,
    acceptance_criteria=False,
    maintenance_months_included=12,
    change_request_reserve_ratio=0.05,
)
print(review(sample))

출력된 risk는 견적 금액을 낮추는 항목이 아니라 계약서에 추가해야 할 질문이다.

인수 검수 JSON 템플릿

아래 JSON은 SI 구축 완료 시 대금 지급 전 확인할 검수 게이트 예시다.

{
  "si_acceptance_gate": {
    "requirements": ["screen_definition", "interface_contract", "data_dictionary", "non_functional_requirement"],
    "security": ["admin_rbac", "personal_data_masking", "audit_log", "secret_management"],
    "test": ["unit_test", "integration_test", "migration_reconciliation", "rollback_test"],
    "operation": ["monitoring_dashboard", "incident_owner", "backup_restore_test", "maintenance_sla"],
    "payment_hold": ["critical_defect_open", "acceptance_criteria_missing", "source_code_delivery_missing"]
  }
}

검수 기준은 개발 완료 뒤에 만들면 늦다.

계약 전부터 보안, 테스트, 운영 이관, source delivery 조건을 같은 표에 올려야 SI 구축 비용 분쟁이 줄어든다.

낮은 SI 견적에서 자주 빠지는 항목

낮은 견적은 개발 능력이 좋아서가 아니라 산출물과 책임 범위가 빠져서 낮아 보일 때가 많다.

누락 항목	처음에는 싸게 보이는 이유	실제 영향	판단
업무분석	개발자가 바로 만들면 빠르다	요구사항 변경이 모두 분쟁이 된다	업무 owner와 승인 절차 필요
테스트 자동화	초기 견적에서 줄이기 쉽다	배포 때 회귀 결함이 반복된다	핵심 흐름만이라도 포함
보안 설계	취약점 진단만 넣으면 충분해 보인다	권한과 로그 구조를 나중에 고친다	요구사항 단계에 포함
운영 이관	개발 완료 산출물처럼 보이지 않는다	장애 때 내부 대응이 막힌다	런북과 복구 테스트 요구
변경 요청 예산	고정가를 낮게 보이게 한다	작은 수정마다 추가 견적이 난다	월 cap과 승인 단가 설정