Part 14. 엔지니어가 견적을 만드는 방법 — Engineering Man-hour 산정

프로젝트 견적서를 받아보면 이상한 숫자가 하나 있습니다.
자재비도 아니고 장비비도 아닙니다.

Engineering Man-hour.

어떤 프로젝트는 수만 시간이 필요하고, 어떤 프로젝트는 수천 시간으로 끝납니다.

그런데 아직 설계도 제대로 시작하지도 않았는데, 엔지니어는 어떻게 필요한 시간을 알고 견적을 만들 수 있을까요?

이번 글에서는 Engineering Man-hour가 무엇인지, 어떻게 산정하는지, 그리고 왜 견적 단계에서 Man-hour를 잘못 잡으면 프로젝트 수익성이 무너질 수 있는지를 이야기해 보겠습니다.

 

 

 

1. 견적서를 만들라는 요청이 들어왔다

 

Beer to Zero Project의 기본 조건이 하나씩 정리되기 시작했습니다.

 

생산능력도 정했습니다. 어떤 제품을 만들 것인지도 결정했습니다. Site Condition도 확인했고, Battery Limit도 설정했습니다. Technical Feasibility를 검토했고, Scope도 정리했습니다. 이제 고객에게 제출할 견적서를 만들어야 합니다.

 

Project Manager가 각 Discipline 담당자에게 자료를 요청합니다.

“Process 쪽 Engineering Man-hour 얼마나 필요합니까?”

 

Process Engineer가 잠시 생각합니다. “음… 한 1,000시간?” 그런데 바로 다음 질문이 들어옵니다.

“왜 1,000시간이죠?”1

 

여기서부터 이야기가 달라집니다.

 

Engineering Man-hour는 단순히 “이 프로젝트가 어려워 보이니까 많이 잡자”라고 정하는 숫자가 아닙니다.

 

반대로 과거 프로젝트에서 1,000시간이 들었다고 해서 이번 프로젝트도 1,000시간이라고 할 수도 없습니다.

 

Engineering Man-hour는 프로젝트 Scope를 실제 Engineering Work로 변환한 결과입니다.

 

즉,

무엇을 설계해야 하는가? → 얼마나 많은 결과물을 만들어야 하는가? → 각각의 결과물을 만드는 데 얼마나 많은 시간이 필요한가?

 

를 계산해서 만든 숫자입니다.

 

 

2. Engineering Man-hour란 무엇인가?

 

Engineering Man-hour, 또는 Engineering Work-hour는 말 그대로 엔지니어링 업무에 필요한 작업시간을 의미합니다.

 

예를 들어 한 명의 엔지니어가 8시간 동안 설계 업무를 수행했다면 8 Man-hour입니다.

 

두 명이 각각 8시간을 일했다면 16 Man-hour입니다.

 

따라서, 1 Man-hour = 1명이 1시간 동안 수행하는 작업량이라고 이해하면 쉽습니다.

 

예를 들어 다음과 같이 계산할 수 있습니다.

 

인원	작업시간	Man-hour
1명	8시간	8 MH
2명	8시간	16 MH
4명	8시간	32 MH
2명	5일 × 8시간	80 MH

 

여기서 중요한 것은 Man-hour와 Calendar Time은 다르다는 것입니다.

 

80 Man-hour가 필요하다고 해서 반드시 10일이 걸리는 것은 아닙니다.

 

두 명이 동시에 작업하면 이론적으로 5일이 될 수 있습니다.

 

따라서 Man-hour는 프로젝트에 필요한 총작업량이고, Schedule은 그 작업량을 언제, 누가, 어떤 순서로 수행할 것인지를 나타내는 개념입니다.

 

이 차이는 Part 12에서 다뤘던 Project Schedule과도 연결됩니다.

 

 

3. 그런데 설계도 없는데 어떻게 시간을 계산할까?

 

여기가 Engineering Man-hour 산정에서 가장 어려운 부분입니다.

 

견적을 만드는 시점에는 아직 Detail Engineering이 끝나지 않았습니다.

 

P&ID도 완성되지 않았고, Equipment List도 확정되지 않았고, 배관 물량도 정확하게 나오지 않았습니다. 그런데 고객은 견적을 요구합니다. 그렇다면 엔지니어는 무엇을 기준으로 시간을 계산해야 할까요?

 

대표적인 방법은 크게 네 가지로 생각할 수 있습니다.

 

① 과거 프로젝트 실적

가장 현실적인 방법입니다.

 

과거에 유사한 프로젝트를 수행했다면 실제 투입된 Man-hour를 참고할 수 있습니다.

 

예를 들어 과거에 비슷한 규모의 공장에서 Process Engineering에 2,000 MH가 투입되었다면 이번 프로젝트의 기본값으로 활용할 수 있습니다.

 

다만 그대로 가져오면 안 됩니다.

 

프로젝트 규모가 다르고, Client의 요구사항도 다르고, 적용 Code도 다르고, Brownfield인지 Greenfield인지도 다르기 때문입니다.

 

따라서 과거 실적을 Reference Project로 사용하는 것입니다.

 

② Deliverable 기반 산정

 

보다 구체적인 방법입니다.

 

먼저 프로젝트에서 만들어야 할 Engineering Deliverable을 정리합니다.

 

예를 들어 Process Discipline이라면,

 

• Design Basis
• Process Description
• Heat & Material Balance
• Process Flow Diagram
• Piping & Instrumentation Diagram
• Equipment Datasheet
• Line List
• Valve List
• Utility Summary
• PSV Calculation
• Relief Load Summary
• Cause & Effect
• Operating Philosophy

등의 결과물이 필요할 수 있습니다.

 

그다음 각각의 Deliverable에 필요한 작업시간을 산정합니다.

 

예를 들어 개념적으로,

P&ID 10장 × 40 MH = 400 MH

Equipment Datasheet 20건 × 8 MH = 160 MH

PSV Calculation 10건 × 12 MH = 120 MH

 

와 같은 방식입니다. 이렇게 하면 단순히 “Process Engineering은 1,000시간입니다”가 아니라, 왜 1,000시간이 필요한지 설명할 수 있습니다.

 

 

4. Man-hour의 핵심은 Deliverable이다

 

여기서 중요한 개념이 하나 등장합니다.

 

Deliverable.

 

Engineering Project에서 실제로 돈을 받고 수행하는 것은 단순히 “엔지니어가 일하는 것”이 아닙니다.

 

결국 고객에게 전달되는 것은 문서와 도면, 계산서, 모델, 데이터입니다.

 

따라서 Engineering Man-hour를 산정할 때는 다음과 같은 구조로 생각하는 것이 좋습니다.

Scope → Deliverable → Quantity → Productivity → Man-hour

 

예를 들어 Pipe Engineering을 생각해 보겠습니다.

 

“배관 설계가 필요하다.”

 

이것만으로는 Man-hour를 계산하기 어렵습니다. 하지만 다음과 같이 바꾸면 이야기가 달라집니다.

Piping Scope
↓
3D Model 작성
↓
Piping GA Drawing
↓
Isometric Drawing
↓
MTO
↓
Pipe Support
↓
Stress Analysis
↓
관련 Deliverable 수량 산정

 

이제부터는 작업량을 계산할 수 있습니다.

 

즉, Engineering Man-hour는 사람을 세는 것이 아니라 일을 세는 것에서 시작합니다.

 

 

5. 모든 Engineering Man-hour가 같은 것은 아니다

여기서 또 하나의 함정이 있습니다.

 

같은 P&ID 한 장이라도 필요한 시간이 모두 같지는 않습니다.

 

예를 들어 단순한 Utility System의 P&ID와 복잡한 Process Gas System의 P&ID는 같은 한 장이라도 난이도가 다릅니다.

 

왜 그럴까요?

 

P&ID의 복잡성은 단순히 도면 크기로 결정되지 않기 때문입니다.

 

다음과 같은 요소가 영향을 줍니다.

 

• Equipment 수
• Line 수
• Valve 수
• Instrument 수
• Control Loop 수
• Interlock 수
• Safety Function
• Process Complexity
• Client Specification
• 적용 Code 및 Standard
• 기존 설비와의 Interface

따라서 실제 견적에서는 단순한 “도면 1장 = 몇 MH”보다 프로젝트 특성에 따른 Productivity Factor를 적용할 수 있습니다.

 

예를 들어 기준 생산성이 40 MH라고 할 때,

Base Man-hour = 40 MH
Complexity Factor = 1.2
Client Factor = 1.1

 

이라면,

40 × 1.2 × 1.1 = 52.8 MH

 

와 같이 조정할 수 있습니다.

 

물론 실제 Factor의 값은 회사의 Historical Data와 Estimating Procedure에 따라 달라져야 합니다.

 

중요한 것은 숫자 자체보다 숫자가 만들어지는 논리입니다.

 

 

6. 그래서 과거 실적 데이터가 중요하다

 

Engineering Man-hour 견적에서 가장 가치 있는 자료 중 하나가 바로 Historical Data입니다.

 

과거 프로젝트에서 실제로 몇 시간이 투입되었는지 기록해 두면 다음 프로젝트의 견적 정확도를 높일 수 있습니다.

 

예를 들어 과거 프로젝트에서 다음과 같은 데이터가 축적되었다고 생각해 보겠습니다.

DeliverableQuantityActual MHMH/Unit

Deliverable	Quantity	Actual MH	MH/Unit
PFD	10	120	12
P&ID	30	1,200	40
Equipment Datasheet	40	320	8
Line List	500	250	0.5
PSV Calculation	20	240	12

 

이 자료가 쌓이면 다음 프로젝트에서는 단순한 감이 아니라 실적 기반 견적이 가능해집니다.

 

예를 들어 새로운 프로젝트에서 P&ID가 40장 필요하다면,

 

과거 실적이 40 MH/장이라면,

40 × 40 = 1,600 MH

 

라는 기본값을 만들 수 있습니다.

 

이것이 Engineering Estimation의 기본적인 사고방식입니다.

 

AACE International 역시 Cost Estimating에서 과거 프로젝트의 비용 및 생산성 자료, 노동시간 데이터와 같은 Historical Data를 중요한 추정 자료로 다루고 있습니다.

 

 

7. 하지만 여기서 끝나면 안 된다

 

문제는 실제 Engineering 업무가 Deliverable만 만드는 일이 아니라는 것입니다.

 

예를 들어 P&ID 한 장을 만드는 데 40 MH가 필요하다고 가정해 보겠습니다.

 

그런데 실제 프로젝트에서는 다음과 같은 일이 발생합니다.

 

1. P&ID 작성
2. Process Engineer 내부 검토
3. Piping Engineer와 Interface 협의
4. Instrument Engineer와 Control 관련 협의
5. Electrical Engineer와 전원 및 Signal Interface 확인
6. Equipment Vendor Data 확인
7. Client Comment 수령
8. Revision
9. HAZOP 수행
10. HAZOP 결과 반영
11. 최종 승인

이 과정에서 실제 투입되는 시간은 단순한 Drawing Production Time만으로 설명할 수 없습니다.

 

따라서 Engineering Man-hour에는 적절한 범위 내에서 다음과 같은 업무도 고려해야 합니다.

 

• Interdisciplinary Coordination
• Internal Review
• Client Review
• Vendor Coordination
• Technical Meeting
• HAZOP / Safety Review
• Design Change
• Document Revision
• Engineering Management
• Project Support

특히 Client Review와 Revision Cycle은 초기 견적에서 놓치기 쉬운 항목입니다.

 

 

8. Engineering Man-hour를 망가뜨리는 가장 무서운 것 — Scope Change

 

Beer to Zero Project에서 가장 위험한 상황을 하나 만들어보겠습니다.

 

계약 당시에는 다음과 같이 합의했습니다.

“기존 공장의 Utility를 활용하고 신규 Process Area만 Engineering 한다.”

 

그런데 프로젝트가 시작되고 고객이 이야기합니다.

“기존 Utility Header도 검토해 주세요.”

 

좋습니다. 그런데 검토하다 보니 기존 배관의 Capacity가 부족합니다.

 

그러자 고객이 다시 요청합니다.

“Utility Header 증설안도 검토해 주세요.”

 

그리고 결국,

 

• Existing P&ID 검토
• Site Survey
• Hydraulic Calculation
• New Tie-in 검토
• Piping Modification
• Structural Review
• Electrical Load 검토
• Instrument Modification

까지 범위가 확대됩니다.

 

처음에는 작은 요청 하나였습니다.

 

하지만 Engineering Man-hour는 계속 증가합니다.

 

이것이 바로 Scope Creep입니다. 그래서 Part 10에서 이야기했던 Project Scope와 Part 14의 Engineering Man-hour가 연결됩니다. Scope가 명확하지 않으면 Man-hour도 정확하게 산정할 수 없습니다.

 

AACE의 Cost Estimate Classification System 역시 비용 견적의 품질과 정확성은 프로젝트 정의 및 Scope Deliverable의 성숙도와 밀접하게 연결된다고 설명합니다.

 

 

9. Brownfield Project가 어려운 이유

 

특히 기존 공장을 개조하는 Brownfield Project에서는 Engineering Man-hour를 보수적으로 접근할 필요가 있습니다.

 

Greenfield라면 비교적 명확합니다. 새로운 공장을 설계하면 됩니다.

 

하지만 Brownfield에서는 기존 설비가 존재합니다. 그리고 그 기존 설비의 정보가 항상 완벽하지 않습니다.

 

도면에는 존재하지 않는 배관이 현장에 있을 수도 있고, 도면과 실제 Valve 위치가 다를 수도 있고, 과거 Modification이 최신 도면에 반영되지 않았을 수도 있습니다.

 

결국 현장에 가서 확인해야 합니다. 그러면 Engineering 업무가 추가됩니다.

Existing Drawing Review
→ Site Survey
→ Field Verification
→ Existing Model Update
→ Tie-in Study
→ Modification Design
→ Construction Support

 

따라서 동일한 생산능력의 프로젝트라도 Greenfield와 Brownfield의 Engineering Man-hour가 동일할 수 없습니다.

 

특히 기존 설비와 신규 설비의 Interface가 많을수록 Engineering Coordination과 Rework 가능성이 증가합니다.

 

 

10. Vendor Data도 Man-hour를 움직인다

 

Engineering 프로젝트에서는 Vendor가 제공하는 데이터도 중요합니다.

 

예를 들어 Pump를 하나 설치한다고 해보겠습니다.

 

초기에는 Pump Datasheet만 있으면 충분해 보입니다. 하지만 실제 프로젝트에서는 Vendor에서 다음과 같은 자료가 들어옵니다.

 

• Datasheet
• GA Drawing
• Performance Curve
• Motor Data
• Nozzle Data
• Foundation Data
• Weight Data
• Instrument Data
• Material Information

Engineering에서는 이 자료를 받아 검토해야 합니다.

 

그리고 Vendor Data가 늦게 들어오면 기존 Engineering 결과물을 다시 수정해야 할 수 있습니다.

 

예를 들어 Pump의 Nozzle Orientation이 변경되면, Pump만 바뀌는 것이 아닙니다.

 

Piping이 바뀌고, Support가 바뀌고, Equipment Layout이 바뀌고, Stress Analysis가 다시 필요할 수도 있습니다.

 

결국 하나의 Vendor Change가 여러 Discipline의 Rework Man-hour로 연결됩니다.

 

따라서 견적 단계에서 Vendor Package의 수량과 중요도, 예상 Review Cycle을 고려하는 것이 중요합니다.

 

 

11. 결국 Engineering Man-hour는 이렇게 계산한다

 

실무적인 관점에서 보면 Engineering Man-hour 산정은 다음과 같은 구조로 정리할 수 있습니다.

 

Step 1. Scope를 정의한다

먼저 무엇을 해야 하는지 명확하게 합니다.

New Plant인가?
Brownfield인가?
FEED인가?
Detail Engineering인가?
EPC 전체인가?

 

 

Step 2. Discipline을 나눈다

일반적인 프로젝트라면 다음과 같이 나눌 수 있습니다.

 

• Process
• Piping
• Mechanical
• Civil / Structural
• Electrical
• Instrumentation & Control
• HSE
• Procurement
• Project Management
• Document Control

프로젝트 성격에 따라 Discipline 구성은 달라질 수 있습니다.

 

Step 3. Deliverable을 정의한다

각 Discipline에서 필요한 결과물을 정리합니다.

 

예를 들어 Process라면,

PFD
P&ID
H&MB
Datasheet
Line List
PSV Calculation
Utility Summary
Operating Philosophy

 

등입니다.

 

Step 4. Quantity를 계산한다

몇 장인지, 몇 건인지, 몇 개의 Equipment인지 계산합니다.

P&ID = 20장
Datasheet = 30건
PSV = 10건

 

처럼 작업량을 수량화합니다.

 

Step 5. Unit Man-hour를 적용한다

Historical Data 또는 회사의 Estimating Norm을 활용합니다.

P&ID = 40 MH/장
Datasheet = 8 MH/건
PSV = 12 MH/건

 

등입니다.

 

Step 6. Complexity와 Project Factor를 적용한다

프로젝트 특성에 따라 조정합니다.

Brownfield
Client Specification
Fast Track
High Safety Requirement
Multi-discipline Interface
Vendor Package Complexity

 

등이 대표적인 영향 요소입니다.

 

Step 7. Review와 Coordination을 반영한다

마지막으로 Engineering Review, Client Comment, Coordination, Management 등의 업무를 적절히 반영합니다.

 

이렇게 해서 최종 Engineering Man-hour가 만들어집니다.

 

 

12. Beer to Zero Project의 Engineering Man-hour

 

이제 다시 Beer to Zero Project로 돌아가 보겠습니다.

 

우리가 지금까지 정의한 프로젝트를 기준으로 Process Engineering을 가정해 보겠습니다.

 

예를 들어 다음과 같이 견적을 만들 수 있습니다.

 

Process Deliverable	Quantity	Unit MH	Total MH
Design Basis	1	40	40
Heat & Material Balance	1	80	80
PFD	5	20	100
P&ID	20	40	800
Equipment Datasheet	25	8	200
Line List	300	0.5	150
PSV Calculation	10	12	120
Utility Summary	1	40	40
Operating Philosophy	1	60	60
HAZOP Support	1	120	120
Engineering Coordination	-	-	200
Total			1,910 MH

 

이제야 비로소

“Process Engineering에 약 1,900 MH가 필요합니다.”

 

라고 이야기할 수 있습니다.

 

그리고 이 숫자는 단순한 감이 아니라 Scope → Deliverable → Quantity → Productivity를 거쳐 만들어진 숫자입니다.

 

물론 위의 MH 값은 Beer to Zero Project를 설명하기 위한 예시일 뿐이며, 실제 견적에서는 회사의 Historical Data와 Project 조건을 기준으로 산정해야 합니다.

 

 

13. 그런데 견적과 실제가 다르면 어떻게 할까?

 

여기서 아주 중요한 문제가 남습니다.

 

견적에서는 1,910 MH였습니다. 그런데 프로젝트가 끝나고 보니 실제 투입시간이 2,400 MH였습니다.

 

그렇다면 누가 잘못한 것일까요? 반드시 견적 담당자가 잘못했다고 볼 수는 없습니다.

 

왜냐하면 견적은 미래에 발생할 작업량을 예측하는 행위이기 때문입니다.

 

실제 프로젝트에서는 예상하지 못한 변수들이 발생합니다.

 

• Client Comment 증가
• Scope Change
• Vendor Data 지연
• Site Condition 변경
• Design Change
• 추가 Review
• Interface 증가
• Schedule Compression

따라서 좋은 견적은 단순히 숫자를 하나 제시하는 것이 아닙니다.

 

어떤 Scope와 어떤 가정을 기반으로 이 숫자가 만들어졌는지를 설명할 수 있어야 합니다.

 

AACE International은 이를 Basis of Estimate(BOE)의 중요한 역할로 설명합니다. BOE에는 Scope, 방법론, Deliverable, Assumption, Exclusion, Risk 등을 명확히 기록해 견적의 근거를 이해할 수 있도록 하는 것이 중요합니다.

 

 

14. 그래서 엔지니어에게 견적은 숫자가 아니다

 

Engineering Man-hour 견적을 처음 접하면 이런 생각을 하기 쉽습니다.

“이 프로젝트는 10,000시간입니다.”

 

하지만 경험이 쌓인 엔지니어는 조금 다르게 생각합니다.

“왜 10,000시간이지?”

 

그리고 그다음 질문을 합니다.

“어떤 Scope를 기준으로 했지?”
“Deliverable은 몇 개인가?”
“과거 어떤 프로젝트와 비교했지?”
“Brownfield Factor는 반영했나?”
“Client Review는 몇 회인가?”
“Vendor Data는 언제 들어오나?”
“Inter-discipline Coordination은 포함했나?”
“Scope Exclusion은 무엇인가?”

 

이 질문에 답할 수 있어야 합니다.

 

결국 좋은 Man-hour Estimate는 숫자가 정확한 견적이 아니라, 숫자의 근거가 명확한 견적입니다.

 

 

15. 프로젝트를 수주하기 위해서는 시간을 알아야 한다

 

Beer to Zero Project는 이제 계약 직전까지 왔습니다.

 

우리는 이미 Scope를 정했습니다. Cost를 계산했습니다. Schedule도 만들었습니다. Risk도 검토했습니다. 그리고 이제 Engineering Man-hour를 계산했습니다.

 

왜 이렇게까지 해야 할까요? 간단합니다.

 

프로젝트의 가장 중요한 자원 중 하나가 사람이기 때문입니다.

 

Engineering 회사가 프로젝트를 수행하면서 실제로 사용하는 것은 결국 사람의 시간입니다.

 

Engineer 한 명이 1년 동안 일할 수 있는 시간은 무한하지 않습니다.

 

따라서 프로젝트에서 필요한 Man-hour를 정확하게 예측하지 못하면, 사람이 부족해지고, Schedule이 밀리고, Overtime이 증가하고, 외주가 발생하고, Rework가 증가하고, 결국 Project Margin이 줄어듭니다.

 

처음 견적서에서는 아주 작은 숫자 차이였던 것이, 프로젝트가 끝날 때는 회사의 수익과 손실을 결정하는 숫자가 될 수 있습니다.

 

 

엔지니어는 도면만 그리는 사람이 아니다

 

프로젝트를 시작하기 전에는 아직 아무것도 만들어지지 않았습니다.

 

하지만 엔지니어는 이미 계산해야 합니다.

 

얼마나 많은 설계가 필요한지, 얼마나 많은 사람이 필요한지, 얼마나 많은 시간이 필요한지, 그리고 그 시간이 프로젝트 비용으로 얼마가 되는지를 계산해야 합니다.

 

Engineering Man-hour는 그래서 단순한 작업시간이 아닙니다.

 

프로젝트 Scope를 사람의 시간으로 변환한 숫자입니다.

 

그리고 그 숫자가 다시 Project Cost와 Schedule로 연결됩니다.

Scope → Deliverable → Man-hour → Cost → Schedule

 

결국 엔지니어가 만드는 첫 번째 설계는 P&ID가 아닐지도 모릅니다.

 

프로젝트가 실제로 수행 가능한지를 숫자로 설계하는 것.

 

그것이 견적 단계에서 엔지니어가 하는 첫 번째 Engineering일 수 있습니다.

 

Beer to Zero Project도 이제 계약을 앞두고 있습니다.

 

하지만 계약서에 사인을 한다고 프로젝트의 위험이 끝나는 것은 아닙니다.

 

오히려 그때부터 진짜 문제가 시작됩니다.

 

“우리는 이 프로젝트를 어떤 조직으로, 어떤 순서로, 어떤 방식으로 실행할 것인가?”

 

다음 이야기에서는 프로젝트를 실제로 움직이기 위한 또 하나의 중요한 질문을 다뤄보겠습니다.

 

 

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. 프로젝트 수주 - 이제 진짜 시작이다