[SI이야기][산출물] SOW란 무엇인가(정의, 내용)

SOW라는 약어를 들었을 때 머리에 떠오르는 산출물이 있다면 이 포스팅을 읽지 않아도 된다. 하지만 SOW라는 약어를 들었을 때 '네?'라는 물음표가 머리에 먼저 떠오른다면 이번 기회에 SOW란 무엇인지 알아두면 좋을 것 같다. 이건 SOW를 작성하는 사람이든 아니든 알면 좋은 것이다. 물론 SOW도 계약서처럼 개발자들은 볼 일이 없는 문서일 수도 있지만... 역으로 뭔지도 모르는데 문서가 하나 날아오면서 '이 부분 작성해서 주세요'하는 상황도 발생하니 일단 알아두면 좋다.

 

1. SOW란 무엇인가?

출처 : 지형 공간정보체계 용어사전 (네이버 지식백과)

SOW는 'Statement of Work'라고 한다. 한국말로는 작업명세서, 과업명세서라고도 한다. 뭔지 알고 보면 글자 그대로 직관적인 이름이지만 뭔지 모르고 보면 알 수 없는 단어가 SOW, 작업명세서, 과업명세서... 아닐까 싶다. 그래서 더 쉽게 설명하자면 고객의 RFP를 보고, 수행사가 제안을 하고, 둘이 만나서 협상한 결과를 정리한 문서가 SOW라고 보면 된다.

 

 

2. 누가 작성하는가?

 

SOW는 수행사가 작성한다. 이번 과업에 대해 이해한 내용, 수행 범위, 수행 방법 등에 대해서 차례대로 기술하는 것이다. 제안서는 PPT였다면 SOW는 워드 문서로 작성한다. 고객사가 워드를 사용한다면 워드 파일로, 한글 파일을 사용한다면 한글 파일로 작성한다. 고객사에서 양식을 주는 경우도 있고, 알아서 하라고 하는 경우도 있다. 대체로 프로젝트 수행 경험이 많은 회사(수행사)라면 항상 사용하는 양식이 있기 마련이다. 고객사 이름/CI로고만 교체하고 기본 문구는 동일하게 유지하는 템플릿 같은 양식이 있다. 설령 회사에서 관리하는 게 없어도 경험 많은 선배들(특히 PM이나 사업관리)은 보관하고 있는 양식이 있다. 그런 양식을 만날 기회가 생기면 잘 챙겨두도록 하자.

 

혹시나 수행사에서 누가 작성하냐고 묻는다면 SOW도 프로젝트 규모에 따라서 작성 할 게 많기 때문에 PM/사업관리의 경험에 따라 다르다고 답하는 것이 맞을 것 같다. 큰 목차나 구역을 만드는 건 PMO(PM, 사업관리 등)가 해주고 각 구역별 담당자를 정해서 작성해 오라고 하는 경우도 있다. 특히 정식 제안서가 없었다거나 협상이 없는 프로젝트였다면 (예 : 수의계약) PMO가 단독으로 작성하기 어려워서 협력업체까지 내려서 작성해 달라고 하는 경우도 더러 발생한다. 변명같이 들릴 수 있지만, 이건 사실 갑질이라고 보긴 어렵고 PMO가 세부 내용을 쓰기 어려운 걸 넘어서 책임소지가 애매해져서 넘기는 경우도 있으니 이런 요청을 덜컥 받았을 때 화나는 일이 없었으면 좋겠다.

 

SOW는 수행사가 작성하는만큼 나중에 수행사 측에서 고객사에게 하겠다고 약속한 서류나 마찬가지가 되기 때문에 협력업체의 영역을 마음대로 써서 나중에 골치 아픈 것보다 처음부터 같이 써서 준비하는 게 나을 때가 많다. SOW로 골치 아픈 경험은 SI 프로젝트를 했던 사람들이라면 다 갖고 있을 정도로 잘 써야 하는 서류다. 참고로 슈르딩의 회사에서는 법무팀과 리스크 부서의 검토를 반드시 거치고 나가는 서류로 되어 있다. 두 부서에서 확인하는 것은 하나밖에 없다. '프로젝트가 오버런이 발생할 리스크가 있는가?'

 

 

3. 무엇을 작성해야 하는가?

 

워드 파일을 열어서 산출물 공통 내용을 만들고 난 이후(표지, 제개정이력 등)에는 목차를 만들어야 한다. 당연하다. 워드 파일은 일단 목차가 있어야 한다. (물론, 워드 파일에서 넘버링(numbering)을 다 하고 목차를 삽입해도 된다. 목차를 넣는 걸 잊지만 말자.)

 

SOW에는 다음의 내용이 있어야 한다.

---

1) 프로젝트 개요

 

이번에 계약하는 프로젝트가 무엇인지에 대한 개요 문구가 있으면 된다. 아래는 샘플이다.

 

"본 작업 명세서 (SOW)는 20xx년 x월 xx4일부터 20xx년 x월 xx일까지 수행되는 (고객사)(이하 “갑”이라 한다)의 예쁘고 화려한 시스템 구축 프로젝트 (이하 본 ‘프로젝트’)에 대한 (수행사)(이하 “을”이라 한다)의 업무 범위를 정하고, 본 프로젝트를 위하여 “을”이 수행할 서비스의 내용, “갑”과 “을”의 책임, 프로젝트 범위, 산출물, 추진 일정, 프로젝트 일반 사항 등이 기술되어 있다."

 

더 자세한 개요성 문구를 써도 좋다. 아주 간단한 예시니 응용해서 글짓기를 해보는 걸 추천한다. ^^

 

 

2.1) 프로젝트 목적 및 범위

제안서를 썼다면 프로젝트의 목적 및 범위는 매우 작성하기가 쉽다.

 

목적은 "~하는 ~어떤 시스템 구축"으로 끝나는 문장 하나를 쓰면 된다. 혹시 구축이 아닌 컨설팅 프로젝트라면 "~을 위한 어떤 컨설팅"이라고 해도 좋다. 컨설팅은 보통 후속의 시스템 구축을 위해 하는 경우가 많으니 이후 시스템 구축을 위한 사전 컨설팅 정도로 써도 될 것 같다. 글짓기는 예쁘게 하면 된다. ^^ 고객의 워딩(wording)을 최대한 활용하는 것이 핵심이다.

 

범위는 제안을 했다면 PPT로 작성한 업무 범위 장표를 갖다가 붙여넣으면 된다. 만약 그렇게 작성된 게 없다면 새로 그리는 것도 방법이고(PPT로 작성해서 붙여 넣는 것은 미운 짓이 아니다), 굳이 PPT가 필요 없다면 장대한 표를 삽입해서 영역벼로 구분해서 쪼로록 정리해도 된다. 중요한 것은 프로젝트의 범위를 설명하는 내용이 들어가면 된다. PPT도 싫고, 표도 싫어요, 하면 글로 써도 된다. 어느 쪽이든 범위를 잘 작성하면 된다.

 

 

2.2) 프로젝트 진행 계획 / 프로젝트 기간 / 프로젝트 일정

 

제목은 자유롭게 골라도 된다. 중요한 것은 프로젝트 수행 일정을 넣어야한다는 사실이다. 언제부터 언제까지만 작성하는 것이 아니다. 전체 일정을 그려야 한다. 이때 그린 일정표가 WBS랑도 맞아야 하고, 이 WBS는 실제 투입인력의 계약과도 다 맞아야 한다. 분석, 설계, 개발, 테스트, 이행 등 단계별로 언제부터 언제까지 어떤 타스크를 하는지 잘 그려서 넣도록 하자. 세부 타스크까지는 WBS에 있으면 되니 중요한 일정만 넣도록 하자. 이때 이 일정에는 보고 일정, 오픈 일정까지 다 포함이 되어야 한다. PPT로 그려서 넣는 걸 추천한다. (이때 그린 PPT는 저장해서 계속 활용하도록 하자. 일정 PPT는 두고두고 필요하게 된다.)

 

 

3) 서비스 제공 범위 / 수행 범위

 

제목은 역시나 프로젝트에 적절한 걸로 잘 쓰면 된다.

이 3)번 영역은 이제 하위를 프로젝트에 맞춰서 잘 쪼개서 작성해야 한다. 

전체 수행범위를 명시하고 구역 별로 쪼개서 하위 목차를 잡아서 쓰면 된다. 큰 프로젝트는 RFP에 이미 고객들이 쪼개놓은 범위가 있으니 잘 옮겨서 정리하면 된다.

 

예를 들면 이런 식이다.

 

(은행 차세대인 경우)

3.1) 목표 시스템 구성도 

3.2) 계정계 부문

      - 수신, 여신, 카드, 외환 등에 영역별 대상 업무 작성 

3.3) 정보계 부문

      - OLAP, DW 등 영역별 대상 업무 작성

3.4) 인프라 부문

3.5) 기타

 

 

4) 산출물

 

이 프로젝트에서 어떤 산출물을 만들 것이고 언제 제출할 것인지를 명시하는 것이다. 

4.1) 관리 산출물

4.2) 개발 산출물 

두 영역으로 나눠서 목록을 작성하면 된다. 아래 표를 참고해서 내용을 쓰면 될 것 같다. 

구분	단계	산출물명	제출시점	주요 내용	비고

모든 열을 다 쓸 필요는 없다. 예를 들면 주요 내용이나 비고는 없어도 되는 열이다. 단계, 산출물명, 제출시점 정도는 필수로 생각하고 작성하도록 하자.

 

 

5) 역할과 책임

 

수행사가 일부러 넣는 영역이다. 필요에 따라서 SOW에 넣지 않아도 되는 부분이다. 이걸 왜 쓰냐... 하면 역할과 책임이 R&R이기 때문이다. '이건 고객사가 하는 거고, 수행사는 여기까지만 하는 거야'라고 SOW에 박아 넣기 위해서 쓰는 것이다. 혹시나 나중에 고객사가 '힘들어서 못해'라고 드러눕는 상황이 발생할 때 쓰거나, 시스템의 퀄리티가 나쁜데 그게 고객이 테스트를 안 해줘서 그런 경우 그 책임이 명확하게 명시되어 있는 경우 프로젝트 퀄리티나 지연에 따른 책임이 줄어드는 마법이 생길 수 있다. 고객이 아무것도 해주지 않아도 알아서 잘할 수 있는 프로젝트라면 굳이 넣지 않아도 된다. ^^

 

 

 6) 검수 조건

 

이 영역 역시 검수 조건이 수행사에게 유리하게 작용해야하는 경우 작성하는 것이 좋다. 대체로 검수 조건은 SI에서는 명확해서 이슈가 없지만, AI 사업으로 넘어가면서 검수조건이 모호해지는 상황이 발생하고 있다. 인공지능 모델을 만들었는데 정확도 100%가 아니면 검수를 안 해주는 고객이 나타난다거나 하는 경우 말이다. (믿거나 말거나 존재하는 고객님이다) 이런 경우 검수 조건을 열심히 적는데 정확도 몇%를 적으라는 것은 아니고, 수행사가 검수 요청을 했을 때 고객님이 답 없이 깔고 뭉개고 5일이 지나면 검수한 걸로 간주할 거야. 이런 내용이다. ^^ 그 외에 수행사에게 유리한 방식이 있다면 화려한 솜씨로 글을 써보는 것을 추천한다. 공격적으로 쓰면 고객이 무조건 반려하니(고객도 꼼꼼하게 검토한답니다) 애매모호하고 예쁘게 잘 써보도록 하자.

---

그 외에 목차가 쭉쭉 늘어날 수 있다. 방법론이 있다면 방법론을 쓸 수도 있고, 프로젝트 조직도가 들어갈 수도 있다. 제안서에 쓴 내용을 발췌해서 넣는거니 누군가가 욕심해서 쓰면 쭉쭉 들어갈 수 있는 것이 SOW다. 

 

중요한 것은 SOW의 양이 아니다. 그 안에 내용이 우리(수행사)에게 유리한가?에 대한 고민이다. 충분히 꼼꼼하게 썼는가, 충분히 보수적으로 썼는가에 대해 내부적으로 치열하게 고민해야 한다. 업무 범위에 위의 예시를 보고 "수신" 이렇게 쓰면 큰일 난다는 뜻이다. 수신 업무에서 어디서부터 어디까지를 할 건지를 명시해야 한다. 거기에 명시되어 있지 않은 걸 고객이 요청할 경우 SOW를 들고 싸울 수 있도록 대비할 수 있도록 말이다. 퉁쳐서 쓰면 SOW를 쓰는 그 시점에는 간편해서 좋을 수 있지만, 영원히 프로젝트를 끝내지 못하고 나오지 못할 수도 있다. '에이 설마~'라고 생각한다면 다시 생각하도록 하자. 슈과장도 이상한 고객을 볼만큼 봤다고 생각했는데 매해 상식 밖의 고객을 새로 만나고 있다. (심지어 랭킹이 갱신됨) ('검토해 보겠다'를 '수용'으로 해석하는 고객까지 만났으니 SOW를 잘못 쓰면 어떻게 될지 상상이 되지 않는가!? ^^)

 

SOW는 개발자에게는 사실 생소한 문서일 수 있다. PMO들끼리 쓰고 끝나는 경우가 많기 때문이다. (그래서 사실 실무자들 간의 싸움은 요구사항정의서에서 일어난다. 이 산출물은 다음에 다루기로 하겠다.) SOW가 뭔지 모르는 오늘은 일단 뭔지 아는 걸로 스스로의 역량을 한 단계 업그레이드 하도록 하자. SOW를 만났을 때 당황하지 않는다면 일단 반 성공한거다!

 

2023.03.02 01:00