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의 업무와 경계를 다뤘지만, 그 업무에 얼마가 책정되는가는 다른 힘이 정합니다. 한국 SM 대가는 관행적으로 '구축비의 N%(유지보수요율)'로 산정되는데, 이 요율 구조를 모르면 SM 현장의 만성 증상들이 이해되지 않습니다.
- 요율은 눌리고, 예방부터 잘립니다: 대가산정 가이드가 권고하는 요율과 실제 계약 요율 사이에는 상당한 격차가 있고, 한 번 정해진 운영비는 몇 년씩 동결되기 일쑤입니다. 운영비가 줄면 SM사는 인력을 줄이는데, 장애대응은 줄일 수 없으니 정기점검·용량관리·형상 정리 같은 예방 업무부터 잘려 나갑니다. 예방이 줄면 장애가 늘고, 장애가 늘면 "SM사가 무능하다"는 평가와 함께 요율은 더 눌립니다 — 악순환의 입구가 기술이 아니라 대가 구조에 있는 것입니다.
- 안정 운영의 역설: 예방이 잘 될수록 장애가 없고, 장애가 없으면 발주사 눈에 SM은 '노는 인력'으로 보입니다. 재계약 테이블에서 "장애도 없는데 왜 이 인원이 필요합니까"라는 질문이 나오는 순간, 잘한 운영이 감액의 근거가 됩니다. 방어선은 운영보고에 '안 터진 장애'를 보이게 만드는 것 — 점검 건수, 임계 도달 전 사전 조치 건수, 용량 추이와 예측을 정례 항목으로 넣어 예방의 실적을 데이터로 남기는 것입니다.
- '운영 개선 과제'라는 이름의 무상 개발: 상주 인력은 운영 M/M로 계약됐는데, 발주사가 "운영하면서 이것도 좀 개선해 주세요"라며 사실상의 개발 과제를 계속 부여하면 운영과 개발의 경계가 M/M 안에서 뭉개집니다. 티켓 집계에서 운영성 작업과 개선성 작업의 비율을 나눠 보고해야, "운영 인력의 40%가 개선 과제에 쓰이고 있다"는 협상 근거가 생깁니다(계약·과업범위·M/M·검수).
- '무상 유지보수 1년' 조항: 하자담보책임과 별개로 계약서에 '무상 유지보수 N개월'을 넣자는 요구가 있습니다. 하자(결함 보수)와 유지보수(운영 서비스)를 한 단어로 뭉갠 조항이라, 서명하는 순간 사실상 무상 SM 기간이 생깁니다. 제안 단계 가격 경쟁에서 이 조항을 받으면 그 원가는 구축 견적 어딘가에 숨어 있어야 하는데, 대개 숨겨지지 않고 수행사의 적자가 됩니다.
규모별로는 공공이 요율 가이드와 감사 덕에 숫자의 형식은 지켜지는 대신 '과업 외 요구'로 새고, 민간 중소는 요율 개념 없이 "월 얼마"로 뭉뚱그려져 업무 범위 자체가 무정형이 됩니다. 어느 쪽이든 SM PM의 방어선은 같습니다 — 대가에 상응하는 업무 목록을 문서로 유지하고, 대가가 줄면 목록도 함께 줄이는 것입니다.
상황: 운영 3년 차 재계약 협상에서 발주사 구매팀이 운영비 15% 감액을 요구했습니다 — "작년에 큰 장애도 없었는데 이 인원이 왜 필요합니까." SM사는 물량 유지를 위해 수용했고, 상주 4명이 3명이 됐습니다. 줄어든 자리는 정기점검·용량관리 담당이었고, 그 업무는 "남는 시간에 나눠서"로 정리됐습니다. 8개월 뒤, 월 마감일에 DB 서버 디스크가 임계를 넘어 DB가 정지했고 복구에 4시간이 걸렸습니다(P1). 확인해 보니 월간보고의 자원 사용률 페이지는 6개월째 숫자만 바뀐 복사본이었고, 용량 추이 분석은 담당자가 빠진 달부터 실측이 끊겨 있었습니다. 발주사는 "왜 예측을 못 했느냐"고 물었고, SM PM은 "그 인력을 줄이지 않으셨습니까"라고 답했지만 — 감액 때 어떤 업무가 줄어드는지 합의한 문서가 없어 그 말은 변명으로만 들렸습니다.
원인: 감액이 업무 범위 조정 없이 이뤄졌기 때문입니다. 인력 25% 감축은 사실상 서비스 축소인데, 계약서상 업무 범위는 그대로였으므로 축소는 '보이지 않는 곳' — 예방 업무 — 에서 일어났습니다. 여기에 안정 운영의 역설이 겹칩니다. 지난 2년간 장애가 없었던 것은 바로 그 용량관리 담당이 임계 도달 전에 증설을 걸어 왔기 때문인데, 그 실적이 어디에도 기록되지 않아 발주사 눈에는 '없어도 되는 인력'으로 보였습니다.
진단: 두 가지를 대조합니다. 첫째, 감액 전후의 실제 수행 업무 목록 — 점검 이력, 용량 실측 기록이 언제부터 끊겼는지 시점을 특정합니다. 둘째, 월간보고의 자원 페이지가 실측인지 복사본인지 — 원본 모니터링 데이터와 보고서 수치를 대조하면 드러납니다. 장애 시점이 아니라 데이터가 끊긴 시점이 사고의 진짜 시작점이라는 것을 시간선으로 보여야, 인력 감축과 사고의 인과가 성립합니다.
해결: 사후에는 위 시간선으로 사고 보고서를 쓰되, 책임 공방보다 감액-업무축소-사고의 구조를 발주사 의사결정권자에게 보이는 데 집중합니다(구매팀이 아니라 시스템 오너에게). 구조적 재발 방지는 두 가지입니다 — (1) 감액을 수용할 때는 반드시 업무 목록(서비스 카탈로그)을 함께 개정해 "이 금액에서는 용량관리가 분기 1회로 줄어듭니다"를 발주사가 알고 선택하게 만들 것, 감액은 거부하지 못해도 그 대가의 명문화는 요구할 수 있습니다. (2) 운영보고에 예방 실적(점검 건수·사전 조치 건수·임계 예측)을 정례 항목으로 넣어 '안 터진 장애'를 평소에 보이게 할 것 — 예방의 가치는 사고가 나기 전에만 팔 수 있습니다. 사고가 난 뒤에는 그 가치를 아무리 설명해도, 그것은 실적이 아니라 변명이 됩니다.
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 산정·검수가 어떻게 맞물려 '일의 범위와 책임과 정산'을 정의하는지를 다룹니다.