직무 · 프로젝트핵심 · 11분 읽기

IT 운영과 외주: RFI·RFP·SOW·SLA·인수인계

업무를 수행하는 모델과 서비스 운영의 책임을 구분하고, 요구·작업 범위·수준 측정·권한·지식 이전을 연결한다.

개념부터 찾아보기

정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.

IT 운영·외주 관리 SLA

이 노트에서 설명할 수 있게 되는 것

ITOps와 ITO, 인력 보강·프로젝트 외주·관리형 서비스의 차이를 설명한다.
요구 요청 문서와 작업 명세·서비스 수준의 목적을 구분한다.
공급자 변경에도 운영 지식과 접근 통제가 이어지는 인수 절차를 설계한다.

먼저 알면 좋은 개념협업 운영: WBS·RACI·의사결정·변경 관리

01운영 업무와 수행 모델을 구분하기

ITOps와 ITOITOps는 인프라·서비스를 운영하면서 모니터링, 장애, 패치, 백업, 용량과 변경을 관리하는 업무 영역이다.
- ITO는 IT 업무의 일부 또는 전체를 외부 공급자에게 맡기는 수행 모델이다.
- 같은 운영 업무를 내부 팀, 외부 공급자, 또는 두 조직이 나누어 수행할 수 있다.
- 따라서 ITO와 ITOps를 같은 약어의 변형으로 읽지 않는다.
HR·HRO·BPOHR은 채용·교육·평가 같은 인적자원 관리 기능이고 HRO는 그 기능을 외부에 맡기는 모델이다.
- BPO는 재무·고객지원 등 업무 의 외부 수행을 가리키는 더 넓은 표현으로 쓰인다.
- manpower는 투입 가능한 인력·역량을 뜻하는 일반 표현이며 그 자체가 계약 유형은 아니다.
- 운영 문서에서는 인원 수뿐 아니라 필요한 역할과 판단 권한을 명시한다.

02운영 업무를 맡기고 인계하는 단계

필요와 범위 정리대상 서비스·지원 시간·요구 역량과 포함/제외 업무를 정한다.
정보·제안·견적 검토필요에 맞게 ··RFQ를 사용해 수행 방안과 비용을 비교한다. 모든 사업이 동일한 순서를 쓰는 것은 아니다.
작업과 수준 합의에 산출물·일정·을, 에 서비스 수준·측정 조건·미달 시 처리를 명확히 한다.
접근과 운영 통제역할·기간에 맞는 접근권한, 작업 기록, 변경 승인과 사고 통보 경로를 운영한다.
상태와 성과 검토를 정한 시간 창과 분모로 측정하고 ·와 비교한다.
전환·종료 인계자료와 지식을 전달하고 새 담당자의 재현·복구 능력을 확인한다. 계정·키·장비·잔존 데이터의 회수·처리 근거도 남긴다.

03인력 보강·프로젝트 외주·관리형 서비스

수행 모델별 중심인력 보강은 기존 팀의 역량이나 인원을 보완하는 데 초점이 있다.
- 프로젝트 외주는 정해진 범위·일정·산출물과 을 중심으로 작업을 수행한다.
- 관리형 서비스는 합의한 운영 범위와 서비스 수준을 지속적으로 제공하는 데 초점이 있다.
- 실제 운영 방식은 계약과 역할 배분에 따라 달라지므로 명칭만으로 모든 책임을 알 수는 없다.
운영 책임의 배분예를 들어 같은 방화벽 관리 업무라도 변경안을 작성하는 사람, 업무 영향을 승인하는 사람, 실제 적용하는 사람, 야간 장애에 응답하는 조직이 다를 수 있다.
- 무엇을 맡겼는지 명확하지 않으면 설정은 바뀌었는데 관제와 서비스 소유자에게 전달되지 않는다.
- 업무 범위와 책임·에스컬레이션을 문서로 연결해야 한다.

04RFI·RFP·RFQ·SOW의 목적

요청 문서의 목적는 가능한 기술·공급 역량·비용 구조 등을 알아보기 위한 정보 요청이다.
- 는 해결해야 할 요구와 평가 관점을 제시하고 수행 제안을 받는 데 사용한다.
- RFQ는 정의된 품목이나 조건의 견적을 받는 데 초점이 있고, 는 실제 수행할 작업의 범위·산출물·일정·을 명확히 하는 작업 명세다.
- 기관과 사업에 따라 절차와 문서 명칭은 달라질 수 있다.
문서와 절차의 구분는 정보 수집, RFQ는 견적 요청, 는 작업 범위를 명세하는 문서다.
- 사용 순서와 선정 절차는 사업의 조달 방식과 요구에 따라 정한다.
- 정보 조사만으로 사업자가 자동 선정되지는 않고, 견적 요청과 작업 명세의 목적도 다르다.
- 참고 문서의 미국 조달 규정은 의 정보 수집 목적을 확인하기 위한 사례이며 국내 사업의 법적 절차를 대신하는 기준은 아니다.

문서	중심 질문	구분할 내용
	어떤 역량과 방식이 가능한가?	정보 수집과 계약 체결
	요구를 어떻게 수행할 것인가?	제안과 승인된 실행 범위
RFQ	주어진 조건의 가격은 얼마인가?	견적 조건·포함/제외 항목
	누가 무엇을 어디까지 언제 넘기는가?	산출물·검수·변경 조건

05SOW에 범위와 인수 기준을 연결하기

작업 범위와 산출물는 “서버 운영 지원” 같은 넓은 표현을 실제 결과물로 바꾼다.
- 지원 대상 서비스와 시간, 포함·제외 업무, 담당 역할, 보고 주기, 작업 산출물, 검토와 을 명시한다.
- 운영 구성도와 소스, 설정, 자동화 코드, 문서의 인계 범위도 정해야 시스템이 특정 수행자에게만 의존하는 상황을 줄일 수 있다.
추가 요구와 긴급 작업추가 요구는 기존 범위에 포함되는지, 일정·비용·보안·가용성에 어떤 영향을 주는지 검토한 뒤 합의한다.
- 장애 중 긴급 조치와 기능 확대 요청도 성격이 다르므로 기록을 구분한다.
- 문서의 목적은 명칭만 외우는 것이 아니라 구현·운영 담당자가 같은 경계와 완료 조건을 이해하도록 하는 것이다.

06SLI·SLO·SLA와 측정 조건

··는 서비스 상태를 수량으로 표현하는 지표이고 는 그 지표에 대한 목표다.
- 는 고객과 제공자 사이의 서비스 수준 약정이며, 미달 시 보고·개선·보상 등 어떤 결과가 따르는지도 포함할 수 있다.
- “가용성 99.9%”만 적으면 어떤 서비스, 시간 창, 관측 지점과 제외 조건인지 알 수 없어 서로 다른 계산 결과가 나올 수 있다.
가용성 계산과 시간 경계시간 기반 가용성과 요청 성공 비율은 서로 다른 측정 방식이다.
- 30일 전체 43,200분을 분모로 하고 제외 시간이 없으며 중단 43.2분인 가상의 시간 기반 예에서는 1−43.2/43,200=99.9%다.
- 이 값을 요청 성공률로 바꿔 해석하지 않는다.
- 장애 접수 응답 시간과 실제 복구 시간도 구분하고, 목표를 계산하는 원본 자료와 누락 처리 방법을 함께 정한다.

원리 심화

07서비스 수준을 측정 계약과 책임 경계로 구체화하기

지표의 계약서비스 범위·측정 위치·성공 기준·집계 창·제외 조건·자료 출처를 먼저 정한다. 같은 99.9%라도 시간 기준인지 요청 기준인지에 따라 의미가 다르다.
요청 기준 평가 대상인 유효 요청 중 성공한 요청의 비율을 사용할 수 있다. 사용자 오류·timeout·재시도·부분 성공을 분자와 분모에 어떻게 넣는지 명시해야 비교가 가능하다.
시간 기준 대상 시간 중 사용 가능한 시간의 비율로 정의할 수도 있다. 부분 기능 장애·지역별 장애·계획된 작업 시간의 처리 규칙이 있어야 측정 결과가 일치한다.
목표와 조치는 목표이고 에는 수준을 충족하거나 놓쳤을 때의 합의된 처리가 포함된다. 서비스 크레딧 등 계약상 처리는 실제 계약 문구로 확인한다.
반응 시간과 복구 시간접수 확인·분석 착수·우회 제공·완전 복구는 다른 시점이다. 접수 확인을 빨리 했다는 이유만으로 장애 복구 목표를 달성했다고 계산하지 않는다.
관측 자료의 공유공급자와 고객이 서로 다른 위치에서 측정하면 결과가 달라질 수 있다. 기준 데이터와 이견 발생 시 확인 절차를 운영 계약에 연결한다.

예제로 추적

0899.9% 목표의 허용 실패를 시간과 요청으로 계산하기

가상 계약 조건30일·24시간 서비스를 대상으로 제외 시간 없이 시간 기준 가용성 목표 99.9%를 가정한다. 실제 공급자의 약관이나 보상 기준을 인용한 예가 아니다.
전체 시간 계산30×24×60=43,200분이다. 허용되는 비가용 비율은 0.1%이므로 43,200×0.001=43.2분, 즉 43분 12초다.
누적 장애 비교가상 중단이 10분·15분·20분이면 합계 45분으로 허용 43.2분을 넘는다. 장애 한 건씩만 비교하면 월간 누적 목표를 놓칠 수 있다.
요청 기준과 비교요청 기준으로 성공률 99.9%와 유효 요청 100,000건을 가정하면 실패 허용은 100건이다. 시간 43.2분을 요청 100건과 직접 바꿔 계산할 수는 없다.
트래픽 분포의 영향요청이 몰리는 1분과 아무 요청이 없는 1분은 요청 기반 실패량이 다르다. 지표가 실제 사용자 영향을 어느 정도 나타내는지 함께 검토한다.
결과와 후속 조치·제외 조건·원천 기록으로 결과를 재현하고 합의한 후속 조치를 적용한다. 예제 수치로 특정 계약의 위반이나 보상을 판단하지 않는다.

교육용 측정 모델	전체 분모	99.9%의 허용 실패
시간 기준, 30일	43,200분	43.2분
요청 기준	100,000건	100건
시간 예제 관측	10+15+20분 중단	45분으로 예제 목표 초과

09접근권한과 공급자 운영 기록

외부자 접근권한외부 수행자가 필요로 하는 자산·계정·기간을 역할에 맞게 제한한다.
- 개인별 계정, 다중 요소 인증, 승인된 관리 경로, 작업 기록을 사용하면 누가 어떤 작업을 했는지 추적할 수 있다.
- 공급자라는 이유만으로 모든 관리 권한을 주거나 공유 계정의 비밀번호만 전달하면 책임과 권한 회수가 어려워진다.
변경·종료 시 회수인력 변경과 계약 종료는 권한의 상태 전환이다.
- 접근 승인 → 사용·검토 → 역할 변경 → 회수까지 연결하고, VPN·토큰·키·인증서·장비·자료를 목록으로 관리한다.
- 비밀값은 일반 인계 문서에 직접 적기보다 승인된 저장 위치와 접근·교체 절차를 전달한다.
- 장애와 보안사건에 대해 어느 역할에게 언제 통보하고 누가 대응 결정을 내리는지도 정한다.

10Transition과 종료 인계

TransitionTransition은 기존 수행자로부터 새 수행자에게 업무를 이전하는 과정이다.
- 종료 시 내부 팀이나 다른 공급자에게 다시 넘기는 전환도 처음부터 계획한다.
- 단순 파일 전달로 끝내지 않고 새 담당자가 정상 상태를 확인하고, 반복 운영 작업과 복구 절차를 수행하며, 모니터링과 연락 경로를 사용할 수 있는지 확인한다.
인계 자료와 종료 비용인계 묶음에는 , 자산·계정 목록, 소스·설정 버전, 설치·변경·백업·복원 절차, 모니터링·경보, 알려진 문제, 데이터 내보내기 방식, 지원과 라이선스 조건을 포함한다.
- 잔존 데이터 처리와 접근 회수의 완료 근거도 남긴다.
- 낮은 단가만 비교하지 않고 지식 이전·유지보수·재작업·종료 지원에 필요한 비용과 책임을 함께 보는 것이 운영 관점이다.

검증·예외

11외주 운영에서 책임 공백과 인계 실패 찾기

경계에서 끊긴 소유권네트워크·OS·애플리케이션·공급자 서비스 사이의 장애를 누가 처음 분석하고 누가 최종 조정하는지 정한다. 각 공급자가 자기 구간만 정상이라고 말해도 종단 서비스는 실패할 수 있다.
산출물과 작업량작업 시간 투입, 산출물 제출, 인수 시험 통과를 서로 다른 상태로 추적한다. 의 결과물과 서비스 수준의 반복 운영 책임을 구분한다.
변경 작업의 범위일상 운영·긴급 장애·기능 변경의 분류와 승인·비용·시간 계산 방식을 확인한다. 일시적인 긴급 대응이 영구적인 범위 확장으로 남지 않게 기록한다.
인계의 재현성설정 백업·복구 자료·연락망을 받는 것에 더해 새 담당자가 실제 절차를 재현할 수 있는지 확인한다. 문서 인계와 운영 능력 이전은 같지 않다.
종료 시 접근 회수계정뿐 아니라 API 키·공유 비밀·원격 접속 경로·백업 사본의 처리까지 목록화한다. 새 운영 주체의 정상 접근을 검증하면서 기존 권한을 회수한다.
잠금과 종속성데이터 내보내기 형식, 설정·스크립트 사용 권한, 종료 지원·지식 이전 조건을 미리 확인한다. 공급자 변경 시 필요한 비용과 재검증 범위가 늦게 드러나지 않도록 한다.

READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

공식 가이드

Google SRE Workbook — SLO를 실제 지표로 만들기

A Worked Example의 구조도·표와 Example Document를 본문의 가용성 계산에 연결해 읽는다.

읽으면서 확인할 것

요청 기반 가용성, 지연, 파이프라인 신선도 중 사용자에게 필요한 지표를 선택하고 분자·분모를 정의한다.
측정 위치와 시간 창이 달라질 때 결과가 달라지는 이유를 설명한다. 이 학습 사례를 특정 계약 문구로 대체하지 않는다.

학습 확인

이해했는지 확인하기

본인이 수행한 범위와 팀의 전체 결과를 구분한다.
주장·기준·산출물에 실제 근거와 책임 주체를 연결한다.
미검증 내용과 예시를 완료된 경력으로 표현하지 않는다.