6개월짜리 구축 프로젝트가 끝나고 시스템이 오픈했습니다. 박수와 회식. 그런데 다음 날부터 진짜 일이 시작됩니다.
오픈 3일째, 정산 화면이 가끔 멈춥니다. 발주사 담당자가 전화합니다. "이거 고쳐 주세요." 운영을 맡은 협력사 PM은 잠시 고민합니다 — 이건 우리가 무상으로 고쳐야 하나(하자), 비용을 청구해야 하나(유지보수), 아니면 원래 없던 걸 새로 해달라는 건가(추가개발)?
같은 "고쳐 주세요"인데, 답에 따라 누가 돈을 내는지, 며칠 안에 해야 하는지, 계약 위반인지가 전부 달라집니다. 구축이 "만드는 일"이라면, SM(System Management)은 만든 것이 살아있는 동안의 모든 일 — 장애를 끄고, 기능을 개선하고, 정기 점검하고, 그 모든 것을 계약과 보고로 통제하는 일입니다.
이 모듈은 구축이 끝난 그 다음 날부터의 세계 — SM의 업무 범위와, 한국 SI/SM 계약에서 끊임없이 분쟁이 나는 하자 / 유지보수 / 추가개발의 경계를 다룹니다.
- 1SM(운영·유지보수)의 업무 범위(장애대응·기능개선·정기점검·형상관리·운영보고)를 설명할 수 있다
- 2하자보수(무상·하자담보책임기간)와 유지보수(유상)와 추가개발의 차이를 기준으로 구분할 수 있다
- 3운영 SLA와 상주·비상주 인력 구조의 트레이드오프를 설명할 수 있다
- 4SI에서 SM으로 넘어가는 운영 이관에서 무엇을 확보해야 하는지 말할 수 있다
- 5SM 월간 운영보고에 어떤 항목이 왜 들어가는지 설계할 수 있다
SM은 무엇을 하는 일인가
구축이 끝난 곳에서 SM이 시작된다
구축(SI)은 "없던 시스템을 만들어 검수까지 통과시키는" 유한한 프로젝트입니다. 끝이 있습니다. 반면 SM(System Management, 운영·유지보수)은 끝이 없는 일 — 시스템이 서비스되는 동안 계속됩니다. 그래서 SM은 '프로젝트'가 아니라 '운영(operation)'이고, 보통 1년 단위 계약으로 갱신됩니다.
SM의 업무는 한 가지가 아니라 여러 갈래입니다. 발주사는 흔히 "운영해 주세요" 한마디로 묶지만, 실제로는 성격이 다른 일들의 묶음입니다.
| SM 업무 | 무엇을 하나 | 성격 |
|---|---|---|
| 장애대응 | 서비스 중단·오류를 정상화(인시던트 대응) | 비계획·즉시성, SLA로 시간 약속 |
| 기능개선·유지보수 | 운영 중 결함 수정·소규모 기능 변경 반영 | 계획+수시, 변경관리 절차 |
| 정기점검 | 백업·로그·자원·보안 패치 등 주기 점검 | 계획·예방, 장애를 미리 막는 일 |
| 형상관리 | 소스·설정·인프라 구성의 버전·이력 관리 | 운영의 '진실의 원천' 유지 |
| 운영보고 | SLA·장애·작업 실적을 정기 보고 | 계약·정산·의사소통 |
핵심 감각: SM은 "고장 나면 고치는 일"이 아니라, "고장이 덜 나게 하고, 나면 빠르게 끄고, 그 과정을 데이터로 증명하는 일" 입니다. 정기점검(예방)과 운영보고(증명)가 빠지면, SM은 그저 소방수가 됩니다.
하자보수 vs 유지보수 — 같은 "고쳐 주세요"의 다른 청구서
하자담보책임기간 안의 '결함'은 무상, 그 밖은 유상
한국 SI/SM 계약에서 가장 자주 다투는 지점입니다. 오픈 후 어떤 작업을 두고 발주사는 "이건 당연히 무상(하자)"이라 하고, 협력사는 "이건 유상(유지보수/추가개발)"이라 합니다. 경계를 정확히 잡아야 합니다.
- 하자보수는 계약상 하자담보책임기간(흔히 오픈/검수 후 6개월~1년, 계약마다 다름) 안에서, 원래 과업범위에 포함된 기능이 검수 시점 사양대로 동작하지 않는 결함을 무상으로 고치는 것입니다. "원래 맞아야 할 게 안 맞는다"가 핵심입니다.
- 유지보수는 보통 별도의 유상 SM 계약 아래, 운영 중 발생하는 결함 수정·소규모 기능 변경·환경 변화 대응을 비용(M/M)을 받고 수행하는 것입니다.
- **추가개발(추가구축)**은 원래 과업범위에 없던 새 기능·새 화면을 요구하는 것으로, 하자도 유지보수도 아닌 별도 견적·별도 계약 대상입니다.
분기의 한 문장: "이게 원래 사양(과업범위)에 있었고, 그대로 동작해야 했는가?" 그렇다면 (기간 내) 하자. 사양대로 동작은 하는데 더 바꾸고 싶다면 유지보수. 사양에 아예 없던 것이라면 추가개발.
| 구분 | 하자보수 | 유지보수 | 추가개발 |
|---|---|---|---|
| 대상 | 과업범위 기능의 결함(사양 불일치) | 운영 중 결함 수정·소규모 변경 | 과업범위 밖 신규 기능 |
| 비용 | 무상 | 유상(SM 계약 M/M) | 유상(별도 견적·계약) |
| 근거 | 하자담보책임(하자담보책임기간 내) | SM 운영 계약 | 신규 SOW(과업명세) |
| 판단 질문 | "원래 사양대로 됐어야 하는데 안 됐나?" | "되긴 되는데 운영상 손봐야 하나?" | "원래 없던 걸 새로 해달라는가?" |
| 예 | 합계가 1원 틀림, 검색이 누락됨 | 마감 배치 시간 조정, 로그 보강 | 쿠폰 기능 신설, 신규 결제수단 추가 |
이 표가 흐릿하면 분쟁이 납니다. 그래서 실무에서는 검수 시점의 과업범위 문서(요구사항정의서·SOW) 와 하자담보책임기간 을 계약서에서 못 박아 두고, 모든 작업 요청을 이 표에 비춰 분류한 뒤 처리합니다.
그림: "원래 사양대로 됐어야 했나"를 묻고, 기간 내면 무상 하자, 그 밖은 유상 유지보수·추가개발로 가른다.
들어온 요청을 무엇으로 처리할 것인가
직접 해보기 — 운영보고 표 만들기
발주사에 제출할 월간 운영보고의 목차를 직접 설계해 보세요. 좋은 운영보고는 "열심히 했다"가 아니라 '약속을 얼마나 지켰고, 어떤 리스크가 쌓이는가' 를 데이터로 보여줍니다. 아래 4개 영역에 각각 어떤 수치·항목을 넣을지 적어 보세요.
1. 서비스 수준(SLA) — 약속을 지켰는가?
2. 안정성(장애) — 무슨 일이 있었는가?
3. 작업 실적(변경·요청) — 무엇을 했는가?
4. 자원·리스크 — 앞으로 위험한가?
작성 후, "이 보고를 받은 발주사가 다음 달 SM 비용을 승인할 근거가 되는가?"를 스스로 점검해 보세요. 모범 항목은 ObserveBlock에 있습니다.
설계: SLA / 장애 / 작업 / 자원 4영역- 서비스 수준(SLA): 가용성(예 99.9%) 달성률, 장애 대응시간(응답·복구) SLA 준수율, 미준수 건과 사유
- 안정성(장애): 인시던트 총 건수, 우선순위별 분포(P1~P4), 평균 복구시간(MTTR), 재발/문제(Problem) 등록 현황
- 작업 실적(변경·요청): 처리한 변경(릴리스/패치) 건수와 결과, 서비스 요청 처리 건수·적체(backlog), 무상(하자) vs 유상 작업 구분 집계
- 자원·리스크: CPU·메모리·디스크·DB 사용률 추이, 용량 임계 도달 예측, 보안 패치 현황, 다음 달 위험 요소·개선 제안
- 핵심 감각: 네 영역이 각각 계약(SLA)·안정성(장애)·작업량(변경·요청)·여유(자원)에 대응한다 — 빠진 영역이 있으면 정산·재계약 협상에서 근거가 약해진다
- 무상/유상 구분 집계가 특히 중요: 하자로 처리한 건과 유상으로 처리한 건을 나눠 보고해야, 정산과 하자 종료(기간 만료) 시점에 분쟁이 줄어든다
현장에서 자주 보는 함정
증상: 하자담보책임기간 동안 발주사 현업이 "이것도 하자죠?"라며 사실상 새 기능을 무상으로 요구합니다. 운영 PM은 관계가 껄끄러워질까 봐 그냥 해주고, 인력은 정산되지 않는 일에 갈려 나갑니다. 기간이 끝날 무렵 누적된 추가개발이 전부 무상으로 처리돼 적자가 납니다.
원인: 하자 / 유지보수 / 추가개발의 경계가 문서로 합의되지 않았습니다. 과업범위(요구사항정의서·SOW)와 하자담보책임기간, 그리고 "범위 밖은 유상"이라는 원칙이 계약·산출물로 못 박혀 있지 않으면, 모든 요청이 무상 하자로 흘러갑니다.
해결 방향(이 트랙에서 깊어짐):
- 검수 시점의 과업범위 문서를 '진실의 원천'으로 고정 — 모든 요청을 이 문서에 비춰 하자/유상으로 분류.
- 들어온 모든 요청을 티켓으로 기록하고 하자 vs 유상 구분을 명시 → 월간 운영보고에 집계.
- 추가개발은 별도 견적·별도 일정으로 분리하고, 무상으로 처리할 수 없음을 초기에 정중히 합의.
- 하자담보책임기간 만료 전 점검회의로 미해결 하자를 정리하고, 이후는 유상 SM으로 전환됨을 명확히 한다.
경계를 긋는 것은 발주사를 적대하는 게 아니라, 정산 가능한 일과 그렇지 않은 일을 구분해 SM 사업을 지속 가능하게 만드는 일입니다.
운영 SLA와 인력 구조, 그리고 이관
얼마나 빨리·상시 대응하는가는 SLA와 인력 구조로 정해진다
SM 계약의 골격은 두 가지로 정해집니다. 얼마나 빨리·잘 대응할 것인가(SLA) 와 누가 어떻게 상주하는가(인력 구조) 입니다.
- 운영 SLA: 가용성(예: 월 99.9%), 장애 응답시간·복구시간(예: P1은 30분 내 응답, 4시간 내 복구), 서비스 요청 처리 기한 등을 수치로 약속하고, 달성률을 운영보고로 증명합니다. 미달 시 패널티(감액)나 개선계획 제출이 따르기도 합니다.
- 상주 vs 비상주(원격): 상주는 인력이 발주사 현장에 고정 배치되어 상시·즉시 대응하지만 인건비(M/M)가 큽니다. 비상주는 평소 원격으로 운영하고 필요 시 콜·방문하므로 비용은 낮지만 즉시성이 떨어집니다. 무엇을 택할지는 시스템 중요도·허용 장애시간(SLA)·예산 의 트레이드오프이지, 기술력의 우열이 아닙니다.
그리고 이 모든 것이 가능하려면, 구축팀이 만든 것을 운영팀이 이어받는 운영 이관(SI → SM) 이 제대로 되어 있어야 합니다. 이관에서 운영팀이 확보해야 할 것:
| 이관 항목 | 왜 필요한가 |
|---|---|
| 운영 매뉴얼·아키텍처 | 시스템이 어떻게 동작하는지 알아야 운영·장애대응 가능 |
| 형상(소스·빌드·설정·인프라) | 패치·복구의 기준이 되는 '현재 상태'를 정확히 알기 위해 |
| 장애 대응 절차·비상연락망 | 장애 시 누구에게·어떻게 에스컬레이션하는지 |
| 계정·권한·접근 정보 | 운영팀이 실제로 손댈 수 있어야 운영이 성립 |
| 미해결 이슈·알려진 결함 목록 | 인수받는 리스크를 알고 시작해야 첫 장애에 안 당함 |
이관이 부실하면 그 빚은 첫 장애에서 한꺼번에 청구됩니다 — 운영팀은 구축팀에 매번 물어야 하고, 그 사이 SLA는 깨집니다. 그래서 SM 계약 협상에서 이관 기간·이관 산출물·인수 확인을 명시하는 것이 운영팀을 지키는 첫 방어선입니다.
SM 계약의 골격은 세 가지로 읽힙니다. 얼마나 빨리·잘 대응하는가(SLA), 누가 어떻게 상주하는가(인력 구조), 그리고 이 둘을 가능케 하는 운영 이관입니다. 위 그림에서 SLA와 인력은 운영의 약속과 비용을 정하고, 아래쪽 이관은 그 약속을 지킬 밑천 — 매뉴얼·형상·권한·알려진 결함 — 을 운영팀 손에 쥐어 줍니다. 이관이 비면 첫 장애에서 그 빈자리가 한꺼번에 드러납니다.
SM 운영 담당·SM PM 자리에서 당신의 하루는 "직접 서버를 만지는 일"보다 "들어온 요청을 올바르게 분류하고, 약속(SLA)을 지키게 통제하며, 그 결과를 발주사에 증명하는 일" 로 채워집니다.
한국 SI/SM 현장에서 이 직무의 실력은 기술 깊이만으로 갈리지 않습니다. (1) "이건 하자인가 유상인가"를 과업범위 문서에 근거해 정확히, 그리고 관계를 해치지 않게 가려내는 능력, (2) 협력사(하도급) 운영 인력의 M/M와 SLA를 관리하며 정산 가능한 일과 무상으로 새는 일을 구분하는 능력, (3) 월간 운영보고로 운영의 성과와 리스크를 발주사 언어로 증명해 재계약과 증원의 근거를 만드는 능력 — 이 세 가지가 SM PM의 핵심 경쟁력입니다.
기술을 아는 SM 관리자는 협력사 엔지니어와 대등하게 장애 원인을 따지고, 발주사의 무리한 '무상 추가개발' 요구에 과업범위 문서로 선을 긋고, 정산·재계약 협상 테이블에서 데이터로 말합니다. SM은 '운영을 떠맡는 일'이 아니라, 운영을 통제 가능한 계약과 보고로 만드는 일입니다.
관련 모듈로 더 깊이:
- SI 프로젝트 생애주기 — 구축이 검수·운영전환을 거쳐 SM으로 넘어오는 앞 단계의 흐름
- 계약·과업범위·M/M·검수 — 하자/유상 구분과 SLA·M/M 정산의 바탕이 되는 계약·과업범위
- 서비스 수준 관리 — 운영 SLA의 RTO/RPO 목표를 측정·관리하는 법
다음 모듈에서는 이 SM 운영의 바탕이 되는 SI/SM 계약 자체 — 계약·과업범위(SOW)·M/M 산정·검수가 어떻게 맞물려 '일의 범위와 책임과 정산'을 정의하는지를 다룹니다.