Part 10. 어디까지 우리가 해야 하는가 - Project Scope 설정

“공장은 우리가 만들어 드리겠습니다.”

 

지난 편에서 우리는 한 가지 질문을 던졌습니다.

“이 프로젝트, 정말 기술적으로 가능한가?”

 

Technical Feasibility를 검토한 결과, 다행히 답은 Yes였습니다.

 

무알콜 맥주 생산공정을 구성할 수 있었고, 필요한 설비와 유틸리티도 기술적으로 확보할 수 있었습니다.

 

이제 프로젝트를 진행할 수 있을 것 같았습니다. 그런데 계약서를 작성하려던 순간, 새로운 문제가 생겼습니다.

 

고객이 말했습니다.

“그럼 공장 전체를 만들어 주시는 거죠?”

 

순간 회의실이 조용해졌습니다.

 

공정 엔지니어 입장에서는 ‘공장을 만든다’는 말이 단순하지 않았습니다.

 

공정설계는 물론이고, 장비 선정과 구매, 배관설계, 전기와 계장, 건축, 소방, 유틸리티, 시공, 시운전, 성능시험, 운전원 교육까지 생각할 수 있는 업무가 너무 많았기 때문입니다. 그리고 더 중요한 질문이 하나 있었습니다.

“그중에서 어디까지가 우리의 일인가?”

 

바로 이 질문에 답하는 것이 Project Scope 설정입니다.

 

 

1. 프로젝트에서 가장 위험한 말, “그것도 해주시겠죠?”

 

엔지니어링 프로젝트에서 문제가 되는 것은 반드시 기술적으로 어려운 일이 아닙니다.

 

오히려 더 위험한 것은 누가 해야 하는지 명확하지 않은 일입니다.

 

예를 들어 고객이 다음과 같이 이야기했다고 가정해 보겠습니다.

“기존 공장에 무알콜 맥주 생산라인을 추가하고 싶습니다.”

 

처음 들으면 단순한 프로젝트처럼 보입니다. 하지만 조금만 구체적으로 들어가면 질문이 계속 생깁니다.

 

• 기존 배관은 어디까지 활용하는가?
• 신규 배관은 누가 설계하는가?
• 기존 탱크를 개조하는가?
• 신규 탱크를 설치하는가?
• 탱크까지의 배관은 누가 공급하는가?
• 전원은 기존 전기실에서 가져오는가?
• 전기실 증설이 필요한 경우 누가 하는가?
• PLC/DCS 프로그램 수정은 포함되는가?
• 기존 공장 Shutdown 작업도 포함되는가?
• 건축공사는 포함되는가?
• 소방공사는 포함되는가?
• 인허가 업무는 누가 담당하는가?
• 시운전은 어디까지 지원하는가?
• 성능보증시험까지 우리가 책임지는가?

이 질문에 명확한 답이 없다면 프로젝트는 이미 위험한 상태입니다.

 

왜냐하면 프로젝트가 시작된 이후에는 서로 다른 해석이 발생하기 때문입니다.

 

고객은 이렇게 생각할 수 있습니다.

“당연히 포함된 것 아닌가요?”

 

하지만 엔지니어링 회사는 이렇게 생각할 수 있습니다.

“그 업무는 계약 범위에 없는데요?”

 

이것이 바로 Scope Gap입니다.

 

 

2. Project Scope란 무엇인가?

 

Project Scope는 쉽게 말하면

“이번 프로젝트에서 우리가 실제로 수행해야 하는 일의 범위”

 

라고 생각하면 됩니다.

 

PMI에서도 프로젝트 Scope를 프로젝트의 목표를 달성하기 위해 수행해야 하는 작업과 결과물의 범위로 설명하고 있으며, Scope Statement와 WBS를 통해 이를 구체적으로 정의하고 관리하도록 설명합니다.

 

여기서 중요한 것은 “해야 하는 일”뿐만 아니라 “하지 않는 일”까지 정의하는 것입니다.

 

예를 들어 Beer to Zero Project에서 다음과 같이 정의할 수 있습니다.

 

In Scope

 

• 공정 기본설계
• 상세설계
• 주요 공정장비 선정
• 신규 배관 설계
• 신규 계장 설계
• 장비 구매
• 배관 자재 구매
• 설치공사
• Pre-Commissioning
• Commissioning 지원
• Performance Test

 

Out of Scope

 

• 기존 생산라인의 전면 개조
• 공장 건축물 증축
• 기존 전기실 증설
• 제품 생산을 위한 원재료 구매
• 상업운전 이후 생산 운영
• 고객의 일반적인 공장 유지보수

이렇게 해야 비로소

“우리가 어디까지 책임지는가?”

 

가 명확해집니다.

 

 

3. Scope는 단순한 업무 목록이 아니다

 

여기서 한 가지 오해하기 쉬운 부분이 있습니다. Scope를 단순히 업무 목록으로 생각하면 안 됩니다.

 

예를 들어

“배관설계 포함”

 

이라고 적었다고 해보겠습니다.

 

그런데 이것만으로 충분할까요? 그렇지 않습니다. 배관설계의 범위에도 여러 가지가 있기 때문입니다.

 

• P&ID 작성
• Line List 작성
• Pipe Specification 작성
• 배관 Routing
• Stress Analysis
• Isometric Drawing
• MTO 작성
• Support Design
• 기존 배관 Tie-in 검토
• 현장 실측
• As-built 반영

어디까지 포함되는지에 따라 필요한 인력과 시간이 크게 달라집니다.

 

따라서 Scope는 단순히

“무엇을 한다.”

 

에서 끝나는 것이 아니라,

“무엇을, 어디까지, 어떤 기준으로, 누가, 어떤 결과물로 제공하는가.”

 

까지 구체화되어야 합니다.

 

 

4. Scope를 정의하는 가장 중요한 방법 - WBS

 

그렇다면 복잡한 프로젝트의 Scope를 어떻게 정리할까요? 대표적인 방법이 WBS(Work Breakdown Structure)입니다.

 

WBS는 프로젝트 전체 작업을 관리 가능한 단위로 계층적으로 분해하는 방법입니다. PMI는 WBS를 프로젝트의 전체 Scope를 정의하고, 이를 관리 가능한 작업 단위로 나누는 구조로 설명합니다.

 

Beer to Zero Project를 예로 들어보겠습니다.

 

Level 1

Beer to Zero Project

 

Level 2

• Engineering
• Procurement
• Construction
• Commissioning

 

Level 3

Engineering

• Process
• Mechanical
• Piping
• Electrical
• Instrument
• Civil

Procurement

• Process Equipment
• Piping Material
• Instrument
• Electrical Equipment

Construction

• Equipment Installation
• Piping Installation
• Electrical Installation
• Instrument Installation

Commissioning

• Pre-Commissioning
• Commissioning
• Performance Test

이렇게 프로젝트를 단계별로 쪼개면 중요한 것이 보이기 시작합니다. 바로 빠진 업무와 중복된 업무입니다.

 

 

5. “100%를 정의한다”는 것

 

WBS에서 중요한 개념 중 하나가 흔히 100% Rule이라고 불리는 원칙입니다.

 

쉽게 말하면,

프로젝트를 완성하기 위해 필요한 모든 작업을 빠짐없이 포함하되, 프로젝트 범위 밖의 작업은 포함하지 않는 것

 

입니다. 예를 들어 신규 탱크를 설치한다고 해보겠습니다.

 

단순하게 생각하면

Tank 구매 → Tank 설치

 

로 끝날 것 같습니다.

 

하지만 실제 프로젝트에서는 다음과 같은 업무가 필요할 수 있습니다.

 

Tank

• Specification
• Vendor Selection
• Purchase
• Inspection
• Transportation
• Foundation
• Erection
• Piping Connection
• Instrument Installation
• Electrical Connection
• Insulation
• Leak Test
• Commissioning

여기에서 하나라도 빠지면 실제 프로젝트 단계에서 문제가 발생할 수 있습니다.

 

예를 들어 Tank 구매는 Scope에 들어 있는데 Foundation이 빠져 있다면, 장비는 도착했는데 설치할 곳이 없는 상황이 발생할 수도 있습니다.

 

그래서 Scope 설정의 핵심은

“우리가 해야 할 일을 많이 적는 것”이 아니라 “프로젝트 완성에 필요한 일을 빠짐없이 찾아내는 것”

 

입니다.

 

실제로 PMI에서도 WBS를 통해 프로젝트의 전체 Scope를 구조화하고, 각 작업에 책임과 비용·일정 등을 연결하는 것이 Scope 관리의 중요한 기반이라고 설명합니다.

 

 

6. 더 중요한 것은 Scope Boundary이다

 

그런데 엔지니어링 프로젝트에서 가장 어려운 부분은 업무를 찾는 것이 아닙니다.

 

경계를 정하는 것입니다.

 

특히 기존 공장을 활용하는 프로젝트에서는 더욱 그렇습니다.

 

Beer to Zero Project가 기존 맥주공장에 신규 무알콜 맥주 생산라인을 추가한다고 가정해 보겠습니다.

 

신규 설비와 기존 설비가 연결되는 지점이 발생합니다. 이때 질문이 생깁니다.

“기존 설비는 어디까지가 우리 Scope인가?”

 

예를 들어 Existing Tank → Tie-in Point → New Process라는 구조가 있다고 해보겠습니다.

 

그렇다면 다음 중 어디까지가 우리의 Scope일까요?

 

1. 신규 공정설비만
2. 신규 공정설비 + 신규 배관
3. 기존 Tank의 Outlet Nozzle부터 포함
4. 기존 Tank 내부 개조까지 포함
5. 기존 Tank 자체 교체까지 포함

이것을 명확하게 정하지 않으면 나중에 분쟁이 발생합니다.

 

따라서 프로젝트에서는 Battery Limit, Tie-in Point, Interface Point 같은 경계를 명확하게 설정해야 합니다.

 

앞서 Part 6에서 다뤘던 Battery Limit이 여기서 다시 중요한 역할을 합니다.

 

Part 6에서 우리는

“기존 공장과 신규 프로젝트의 물리적인 경계를 어디에 둘 것인가?”

 

를 고민했습니다. Part 10에서는 한 단계 더 나아가

“그 경계 안에서 누가 무엇을 책임질 것인가?”

 

를 정의하는 것입니다.

 

 

7. Scope Matrix를 만들어보자

 

실무에서는 이런 경계를 명확하게 하기 위해 Scope Matrix나 Responsibility Matrix를 활용할 수 있습니다.

 

예를 들어 다음과 같이 구성할 수 있습니다.

 

업무	고객	우리 회사	Vendor	비고
Process Design	승인	●
P&ID	검토/승인	●
Equipment Supply		●	제작
Equipment Foundation		●
Electrical Power	●			기존 전원 사용
Instrument		●	공급
Construction		●		EPC Scope
인허가	●	지원		최종 책임 고객
Commissioning	참여	●	지원
Plant Operation	●			계약 제외

 

이 표 하나가 상당히 중요합니다. 왜냐하면 프로젝트 구성원 모두가 같은 질문에 같은 답을 할 수 있게 만들어주기 때문입니다.

“이 업무는 누가 하는가?”

 

프로젝트에서 가장 위험한 것은 아무도 담당하지 않는 업무입니다.

 

그리고 그다음으로 위험한 것은

두 회사가 서로 자기 업무라고 생각하는 업무

 

입니다.

 

 

8. Scope는 Cost와 Schedule의 출발점이다

 

Scope를 결정하는 것이 중요한 또 하나의 이유가 있습니다.

 

바로 Cost와 Schedule이 Scope에서 나오기 때문입니다.

 

예를 들어 고객이 처음에는

“무알콜 맥주 생산라인을 설치해 주세요.”

 

라고 했다고 해보겠습니다.

 

우리 회사가 이것을

Engineering + Procurement

 

까지만 생각했다면 프로젝트 비용은 그 기준으로 산정될 것입니다.

 

그런데 계약 이후 고객이

“시공도 당연히 포함이죠?”

 

라고 한다면 어떻게 될까요?

 

시공비가 추가됩니다. 그리고

“시운전도 해주시죠?”

 

라고 하면 Commissioning 인력이 필요합니다.

“성능보증시험도 해주세요.”

 

라고 하면 Performance Test를 위한 설계와 시험계획, 인력과 시간이 추가됩니다.

 

결국 처음에 생각했던 프로젝트와 실제 프로젝트의 크기가 달라집니다.

 

그래서 Scope가 흔들리면 Cost와 Schedule도 함께 흔들립니다.

 

PMI 역시 Scope를 WBS로 구조화하는 것이 비용, 일정, 자원, 조달, 품질 및 변경관리의 기반이 된다고 설명합니다.

 

 

9. Scope Creep - 프로젝트가 조용히 커지는 순간

 

Scope 관리에서 자주 등장하는 표현이 있습니다.

 

Scope Creep입니다. 쉽게 말하면,

계약 당시 정의했던 Scope가 공식적인 변경 절차 없이 조금씩 늘어나는 현상

 

입니다. 처음에는 아주 작은 요청으로 시작합니다.

“이것도 같이 검토해 주세요.”

 

그리고 며칠 뒤,

“이 부분도 도면에 반영해 주세요.”

 

그리고 다시,

“이 설비도 기존 설비와 연결해 주세요.”

 

처음에는 별것 아닌 것처럼 보입니다.

 

하지만 이런 요청이 쌓이면 결국 프로젝트 전체의 비용과 일정에 영향을 줍니다.

 

특히 엔지니어링 프로젝트에서는 작은 설계 변경 → 도면 변경 → 장비 변경 → 구매 변경 → 시공 변경 → 시운전 변경으로 이어질 수 있습니다. 따라서 Scope 변경은 단순한 “업무 추가”가 아닙니다.

 

Cost, Schedule, Resource, Risk를 함께 변경시키는 프로젝트 변경입니다.

 

그래서 Scope Baseline을 정하고, 이후 변경은 공식적인 Change Control 절차를 통해 관리하는 것이 중요합니다. PMI 역시 승인된 Scope Baseline을 이후 의사결정과 변경관리의 기준으로 활용할 것을 강조합니다.

 

 

10. 결국 Scope란 “경계선을 긋는 일”이다

 

프로젝트를 시작할 때 엔지니어는 보통 무엇을 할 수 있는지를 생각합니다.

 

하지만 프로젝트 매니저와 계약 담당자는 한 가지를 더 생각해야 합니다.

“우리가 무엇을 하지 않을 것인가?”

 

이것이 Scope의 본질입니다.

 

프로젝트의 Scope는 In Scope와 Out of Scope 사이에 경계선을 긋는 일입니다.

 

그리고 그 경계선이 명확해야

 

• Cost를 계산할 수 있고
• Schedule을 만들 수 있고
• Resource를 배정할 수 있고
• Risk를 평가할 수 있고
• 계약을 관리할 수 있습니다.

반대로 경계가 불명확하면 프로젝트가 시작된 뒤 계속해서 질문이 생깁니다.

“이것도 우리 업무인가요?”

“이 비용은 누가 부담하나요?”

“이 일정 지연은 누구 책임인가요?”

“이 변경은 추가 비용을 받아야 하나요?”

 

결국 Scope가 불명확한 프로젝트는 계약이 끝난 뒤에도 계속해서 계약을 다시 쓰는 프로젝트가 될 수 있습니다.

 

 

11. Beer to Zero Project의 Scope를 정의해 보자

 

이제 우리의 프로젝트로 돌아와 보겠습니다. 고객의 요구사항은 다음과 같았습니다.

“기존 맥주공장을 활용하여 무알콜 맥주 생산이 가능한 신규 생산라인을 구축한다.”

 

우리는 앞선 Part에서

 

• 고객 요구사항을 정의했고
• Product Specification을 설정했고
• Production Capacity를 결정했고
• Site Condition을 검토했고
• Battery Limit을 설정했고
• Feasibility를 검토했습니다.

이제 이것을 실제 프로젝트 업무로 바꿔야 합니다. 따라서 우리의 초기 Scope는 다음과 같이 정의할 수 있습니다.

 

Engineering

• Process Design
• Mechanical Design
• Piping Design
• Electrical Design
• Instrumentation Design
• Civil/Structural Design
• Engineering Documents

Procurement

• Process Equipment
• Tank
• Pump
• Heat Exchanger
• Piping Material
• Instrument
• Electrical Equipment

Construction

• Equipment Installation
• Piping Installation
• Electrical Installation
• Instrument Installation
• Insulation
• Painting

Commissioning

• Pre-Commissioning
• Commissioning
• Performance Test
• Operator Training

그리고 동시에 다음과 같은 항목은 Out of Scope로 정의할 수 있습니다.

 

• 기존 생산설비의 전면 교체
• 기존 공장의 일반 유지보수
• 제품 원료 구매
• 상업운전 이후 생산 운영
• 고객사의 기존 생산공정 개선

이제야 비로소 프로젝트의 크기가 보이기 시작합니다.

 

 

12. Scope를 정해야 비로소 “프로젝트”가 된다

 

프로젝트 초기에 많은 사람들이 설계부터 시작하려고 합니다.

 

하지만 실제로는 그보다 먼저 해야 할 일이 있습니다. 우리가 무엇을 해야 하는지를 정의하는 것입니다. 그리고 그 결과가 Scope입니다. Scope는 단순한 계약서의 한 페이지가 아닙니다.

 

그 안에는 프로젝트의

• Cost
• Schedule
• Resource
• Procurement
• Construction
• Risk

가 모두 연결되어 있습니다.

 

그래서 Project Scope를 정의하는 일은 결국

“이 프로젝트의 크기와 책임의 경계를 결정하는 일”

 

이라고 할 수 있습니다. 그리고 한 가지 중요한 질문이 남았습니다.

“좋습니다. 우리가 해야 할 일은 정했습니다. 그렇다면 이 일을 하는 데 도대체 얼마가 필요할까요?”

 

이제 프로젝트의 범위가 정해졌으니, 다음 단계에서는 그 범위를 숫자로 바꿔야 합니다.

 

다음 편에서는 Project Cost Estimation을 통해 프로젝트에 필요한 비용을 계산해 보겠습니다.

 

 

Beer to Zero Project 연재 순서

 

PART 2. 프로젝트를 수주하다 — 설계하기 전에 계약부터

 

• Part 9. 우리가 이 프로젝트를 할 수 있는가 - Technical Feasibility
• Part 10. 어디까지 우리가 해야 하는가 - Project Scope 설정
• Part 11. 프로젝트에는 얼마가 필요한가 - Project Cost Estimation
• Part 12. 언제까지 만들어야 하는가 - Project Schedule
• Part 13. 무엇이 프로젝트를 망칠 수 있는가 - Project Risk Review
• Part 14. 엔지니어가 견적을 만드는 방법 - Engineering Man-hour
• Part 15. 기술제안서에는 무엇을 담는가 - Technical Proposal
• Part 16. 결국 계약이 필요하다 - Commercial & Contract
• Part 17. 프로젝트 수주 - 이제 진짜 시작이다