※ 일반적으로 SOW는 State of Work가 아니라 Statement of Work의 약어로 사용된다.
계약 기반 IT 서비스, SI 프로젝트, 아웃소싱, 클라우드 운영계약 등에서 핵심 문서로 활용된다.

1. 서비스 수준 관리를 위한 작업명세서, SOW의 개요

1.1 SOW(Statement of Work)의 정의

SOW(Statement of Work)는 계약에 근거하여 수행될 업무 범위, 산출물, 일정, 품질 기준, 책임, 검수 기준 등을 명확히 기술한 공식 문서이다.

즉,

“무엇을, 어디까지, 어떤 기준으로, 누가 책임지고 수행하는가”를 명문화한 실행 중심 계약 문서

특히 IT 서비스 관리 및 아웃소싱 환경에서는 SOW가 SLA의 기반 문서가 된다.

1.2 SOW의 필요성

SOW는 다음과 같은 목적을 가진다.

특히 SI·공공 프로젝트에서는 분쟁 예방 문서로서의 기능이 매우 중요하다.

1.3 SOW / SLA / SLM의 관계

• SOW : 무엇을 수행할 것인가 (Work 범위 정의)
• SLA : 어느 수준으로 제공할 것인가 (Service Level 정의)
• SLM : SLA를 관리·측정·개선하는 활동 (관리 프로세스)

관계 구조도

2. SOW의 구성 및 구성항목

2.1 SOW의 구성도

2.2 SOW 구성요소 및 사례 

2.3 관점별 SOW의 역할

① 서비스 사용자(발주사) 측면

② 서비스 제공자(수행사) 측면

3. SOW 작성 시 고려사항

3.1 핵심 고려 요소

3.2 실무적 체크리스트

• 업무 범위와 요구사항 명세서(RS) 일치 여부
• 산출물 형식까지 명시했는가?
• SLA와 KPI가 정량화되어 있는가?
• 장애 범위 정의가 명확한가?
• 클라우드 사업자 책임 구분이 명확한가?
• 보안/개인정보 보호 조항이 포함되어 있는가?
• 분쟁 발생 시 기준 문장으로 사용 가능한가?

4. SOW의 전략적 중요성 (MSA·클라우드 환경 관점)

특히 다음과 같은 환경에서 SOW는 더욱 중요하다.

• MSA 기반 분산 서비스 구조
• AWS/Azure/Naver Cloud 혼합 환경
• DevOps 기반 지속 배포 환경
• 24×7 글로벌 서비스 운영

이 경우 SOW에는 다음이 반드시 포함되어야 한다.

• 서비스별 책임 경계 (Gateway / Auth / Batch 등)
• 클라우드 장애 시 책임 범위
• 데이터 백업 및 복구 기준 (RPO / RTO)
• 보안 사고 대응 체계
• 로그 보관 정책

5. 결론

SOW는 단순한 계약 부속 문서가 아니라,

프로젝트 통제의 기준 문서이며, 서비스 품질 관리의 출발점이다.

특히 SI·공공·클라우드·MSA 환경에서는 SOW → SLA → SLM의 구조를 체계적으로 설계해야 안정적인 운영이 가능하다.

6. 참고 문헌

1. Project Management Institute, PMBOK Guide
2. AXELOS, ITIL Service Design
3. International Organization for Standardization, ISO/IEC 20000 (IT Service Management)
4. 대한민국 기획재정부, 공공사업 계약지침
5. 한국정보화진흥원(NIA), 정보시스템 구축·운영 표준 가이드