Part 17. 프로젝트 수주 - 이제 진짜 시작이다 | Project Award & Kick-off

“Congratulations. We are pleased to award the project to your company.”

 

프로젝트 수주를 알리는 메일이 도착했습니다.

 

수개월 동안 준비했던 기술제안서가 통과됐고, 견적도 경쟁력을 인정받았습니다.

 

Technical Feasibility를 검토했고, Project Scope를 정의했고, Cost를 계산했고, Schedule을 만들었고, Risk를 검토했고, Technical Proposal과 Commercial Proposal까지 제출했습니다.

 

그리고 마침내 고객이 말합니다. “당신들에게 프로젝트를 맡기겠습니다.”

 

축하할 일입니다. 그런데 엔지니어 입장에서 보면 조금 다른 생각이 듭니다.

 

“이제 시작이네.”

 

바로 이 순간부터 우리가 제안서에서 했던 말들이 실제 프로젝트의 책임으로 바뀌기 때문입니다.

 

 

1. 프로젝트 수주는 끝이 아니라 시작이다

 

프로젝트를 처음 접하는 사람에게는 프로젝트 수주가 가장 중요한 순간처럼 보일 수 있습니다.

 

하지만 프로젝트를 수행하는 입장에서는 조금 다릅니다.

 

수주 전에는 우리가 고객에게 이렇게 이야기할 수 있습니다.

“이 정도 Scope로 수행할 수 있습니다.”

“이 정도 Cost가 예상됩니다.”

“약 18개월이면 가능합니다.”

“이 Process를 적용하면 요구 생산량을 만족할 수 있습니다.”

 

하지만 계약이 체결되면 이야기가 달라집니다.

 

이제는 “할 수 있습니다.”가 아니라 “하기로 했습니다.”가 됩니다.

 

이 차이가 상당히 큽니다.

 

수주 전의 Engineering은 Proposal Engineering에 가깝습니다.

 

프로젝트를 수주하기 위해 기술적인 가능성을 검토하고, 예상 Cost와 Schedule을 만들며, 고객에게 우리가 무엇을 제공할 수 있는지를 설명합니다.

 

반면 수주 이후에는 실제 설계가 시작됩니다.

 

Process Design을 확정하고, Equipment를 선정하고, Piping을 설계하고, Instrument를 구성하고, 구매를 진행하고, Construction을 준비하고, Commissioning과 Performance Test까지 수행해야 합니다.

 

즉,

Proposal이 약속이었다면, Contract는 그 약속을 실행해야 하는 기준이 됩니다.

 

 

 

2. 수주했다고 바로 설계부터 시작하면 될까?

 

여기서 초보 엔지니어들이 자주 하는 실수가 있습니다.

 

프로젝트를 수주했다는 소식을 들으면 바로 설계부터 시작하려고 합니다.

 

• “P&ID부터 그리면 되겠네요.”
• “Equipment Datasheet부터 만들겠습니다.”
• “Vendor RFQ부터 보내겠습니다.”

물론 실제로 Engineering을 빨리 시작해야 하는 경우도 있습니다.

 

하지만 그전에 반드시 확인해야 할 것이 있습니다.

 

“우리가 정확히 무엇을 계약했는가?”입니다.

 

계약이 체결됐다고 해서 모든 조건이 머릿속에서 사라지는 것은 아닙니다.

 

오히려 그때부터 계약서를 다시 봐야 합니다.

 

 

3. 계약서가 프로젝트의 기준이 된다

 

EPC 프로젝트에서는 계약문서가 매우 중요합니다.

 

대표적인 EPC/Turnkey 계약 체계인 FIDIC Silver Book에서도 General Conditions뿐 아니라 Contract Data, Special Provisions, Employer's Requirements 등이 계약의 중요한 구성요소로 다뤄집니다.

 

쉽게 말하면 프로젝트를 수행하면서 문제가 발생했을 때

“우리는 이렇게 알고 있었습니다.”

 

가 아니라

“계약상 어떻게 정의되어 있습니까?”

 

가 중요해집니다.

 

예를 들어보겠습니다. 고객이 다음과 같이 요구했다고 가정하겠습니다.

생산능력 : 100,000 ton/year
제품 순도 : 99.9%
Plant Completion : 18개월

 

그런데 Engineering을 진행하다 보니 생산능력을 만족하기 위해 추가 설비가 필요해졌습니다.

 

그렇다면 질문이 발생합니다.

 

그 추가 설비가 원래 계약 Scope에 포함되어 있었을까요? 또는 고객이 기존 Utility를 제공한다고 했는데 실제로 확인해 보니 Capacity가 부족할 수도 있습니다.

 

그러면 또 질문이 발생합니다.

 

Utility Upgrade는 누구의 Scope일까요?

 

이처럼 프로젝트에서 발생하는 많은 문제는 결국 Scope와 Contract의 경계 에서 시작됩니다.

 

그래서 수주 직후 가장 먼저 해야 할 일 중 하나가 바로 Contract Review입니다.

 

 

4. Award와 Contract, 그리고 NTP는 무엇이 다를까?

 

여기서 한 가지 헷갈리는 개념이 있습니다.

 

바로 Award와 Contract 그리고 Notice to Proceed, NTP입니다.

 

쉽게 구분하면 다음과 같습니다.

 

단계	의미
Bid / Tender	프로젝트를 따내기 위해 제안
Award	고객이 우리 회사를 계약 대상자로 선정
Contract	실제 계약조건 확정 및 계약 체결
NTP	계약에 따라 실제 업무 착수를 공식적으로 지시
Engineering Start	본격적인 설계 수행

 

물론 실제 프로젝트에서는 회사와 계약 형태에 따라 이 과정이 겹치거나 순서가 달라질 수 있습니다.

 

특히 NTP는 중요한 개념입니다.

 

NTP는 말 그대로 Notice to Proceed, 즉 프로젝트를 실제로 수행하라는 공식적인 착수 지시입니다.

 

FIDIC의 EPC/Turnkey 계약에서도 Commencement Date는 계약상 정해진 절차에 따라 공사의 착수 기준이 됩니다.

 

실제 EPC 프로젝트에서도 초기 활동과 본격적인 실행을 구분하기 위해 NTP가 사용됩니다.

 

예를 들어 2026년 Technip Energies는 Commonwealth LNG 프로젝트에서 Full Notice to Proceed(FNTP)를 받은 뒤 초기 활동에서 프로젝트의 full execution으로 전환했다고 발표했습니다.

 

즉, NTP는 단순한 행정문서가 아닙니다. 프로젝트를 실제로 움직이기 시작하는 중요한 기준점입니다.

 

 

5. 이제 제안서가 Project Baseline으로 바뀐다

 

수주 전에는 우리가 만든 문서가 Proposal입니다.

 

하지만 프로젝트가 시작되면 그 자료들은 점점

 

Project Baseline으로 바뀌게 됩니다. 예를 들어 수주 당시 우리가 제시했던 것이 다음과 같다고 생각해 보겠습니다.

 

Scope

• Process Design
• Equipment Procurement
• Piping
• Electrical
• Instrumentation
• Construction Support
• Commissioning

Cost

• Engineering Cost
• Equipment Cost
• Material Cost
• Construction Cost
• Contingency

Schedule

• Basic Engineering
• Detailed Engineering
• Procurement
• Construction
• Commissioning

 

이제 이것들은 단순한 예상치가 아닙니다. 프로젝트를 관리하기 위한 기준이 됩니다.

 

예를 들어 Engineering Progress가 40%라고 한다면, 무엇을 기준으로 40%인가?라는 질문이 생깁니다.

 

또한 구매비가 예산보다 10% 증가했다면, 원래 Budget이 얼마였는가?를 확인해야 합니다.

 

공사가 한 달 지연됐다면, 원래 Schedule의 기준일은 언제였는가?를 확인해야 합니다.

 

결국 프로젝트를 관리하려면 Scope + Cost + Schedule이라는 세 가지 기준이 필요합니다.

 

그리고 이것이 우리가 앞선 Part에서 계속 이야기했던 이유입니다.

 

 

6. 수주 후 가장 먼저 해야 할 일

 

그렇다면 실제 프로젝트를 수주한 엔지니어는 무엇부터 해야 할까요?

 

저라면 크게 다섯 가지를 확인하겠습니다.

 

① Contract Review

계약서와 계약 부속문서를 다시 확인합니다.

 

특히 다음 항목을 봅니다.

 

• Contract Scope
• Battery Limit
• Exclusion
• Deliverables
• Performance Guarantee
• Completion Criteria
• Payment Milestone
• Schedule
• Liquidated Damages
• Warranty
• Change Order
• Client Responsibility

특히 중요한 것은 우리가 해야 하는 것과 하지 않아도 되는 것을 명확하게 구분하는 것입니다.

 

② Proposal과 Contract의 차이 확인

수주 전 제안서와 최종 계약서를 비교합니다.

 

왜냐하면 최종 협상 과정에서 내용이 바뀌었을 수 있기 때문입니다.

 

예를 들어 Proposal에서는

“Cooling Water는 Client가 제공”

 

이라고 되어 있었는데, 최종 계약에서는

“Cooling Water Supply System shall be included in Contractor's Scope”

 

로 바뀌었다면 완전히 다른 프로젝트가 됩니다. 이런 변경사항을 놓치면 프로젝트가 시작되자마자 Cost와 Schedule에 문제가 발생할 수 있습니다.

 

③ Project Organization 구성

이제 실제 프로젝트를 수행할 조직이 필요합니다.

 

Project Manager를 중심으로

 

• Process
• Mechanical
• Piping
• Electrical
• Instrument
• Civil
• Procurement
• Construction
• QA/QC
• HSE
• Commissioning
• Commercial

등의 조직이 구성됩니다. 그리고 중요한 것이 하나 있습니다.

 

누가 무엇을 책임지는가?입니다.

 

프로젝트가 커질수록 개인의 능력보다 Responsibility와 Communication 구조가 중요해집니다.

 

 

7. 그리고 Project Kick-off Meeting

 

조직이 구성되면 본격적인 프로젝트의 첫 번째 회의가 시작됩니다.

 

바로 Project Kick-off Meeting, KOM입니다.

 

Kick-off Meeting은 단순히

“안녕하세요. 이번 프로젝트 잘 부탁드립니다.”

 

라고 인사하는 자리가 아닙니다.

 

프로젝트의 방향을 모두가 공유하는 자리입니다.

 

일반적으로 다음과 같은 내용들이 논의될 수 있습니다.

 

• Project Overview : 프로젝트의 목적과 전체 Scope를 공유합니다.
• Contract Scope : 우리가 해야 할 업무의 범위를 확인합니다.
• Project Schedule : Engineering부터 Procurement, Construction, Commissioning까지 전체 일정을 공유합니다.
• Deliverables : 어떤 문서를 언제 제출해야 하는지 확인합니다.
• Organization : Client와 Contractor의 담당자를 확인합니다.
• Communication : 문서 송부, 승인, 질의, 변경관리 등의 Communication Process를 정합니다.
• Engineering Philosophy : Process, Equipment, Piping, Instrument 등의 설계 방향을 공유합니다.
• Procurement Strategy : Long Lead Item과 주요 Vendor 선정 전략을 확인합니다.
• Risk : 수주 당시 확인했던 주요 Risk를 다시 검토합니다.

 

결국 Kick-off Meeting의 목적은 하나입니다.

“이 프로젝트를 어떻게 수행할 것인지 모두가 같은 그림을 보는 것.”

 

 

 

8. 수주 전에 했던 Risk Review를 다시 보는 이유

 

여기서 재미있는 부분이 하나 있습니다.

 

Part 13에서 우리는 Project Risk Review를 했습니다.

 

그런데 프로젝트를 수주하고 나면 다시 Risk를 봅니다.

 

왜일까요? 수주 전 Risk와 수주 후 Risk의 목적이 다르기 때문입니다.

 

수주 전에는

“이 프로젝트를 우리가 수행해도 되는가?”

 

를 판단합니다. 수주 후에는

“이 Risk를 어떻게 관리하면서 프로젝트를 수행할 것인가?”

 

를 고민합니다. 예를 들어 수주 전에는

“Long Lead Equipment의 납기가 Risk다.”

 

라고 판단했다면, 수주 후에는

“Vendor 선정은 언제까지 끝내고, PO는 언제 발행하며, 어떤 대체 Vendor를 확보할 것인가?”

 

까지 구체화해야 합니다.

 

Risk가 판단의 대상에서 관리의 대상으로 바뀌는 것입니다.

 

 

9. 이제 엔지니어의 말 한마디가 달라진다

 

프로젝트 수주 전에는 엔지니어가 이렇게 이야기합니다.

“검토해 보겠습니다.”

“가능할 것으로 판단됩니다.”

“견적 기준으로 약 18개월이 필요합니다.”

 

하지만 프로젝트가 시작되면 표현이 달라집니다.

“Contract Scope상 포함되어 있습니다.”

“Approved Design Basis 기준으로 진행하겠습니다.”

“해당 사항은 Schedule에 영향을 줄 수 있습니다.”

“Client Approval이 필요합니다.”

“이 변경은 Cost Impact가 발생합니다.”

 

왜 그럴까요? Engineering이 Contract와 연결되기 때문입니다.

 

그래서 프로젝트 엔지니어에게는 기술적인 지식만 필요한 것이 아닙니다.

 

자신이 작성하는 Datasheet 하나, P&ID 하나, Calculation 하나, Technical Query 하나가 프로젝트의 Cost, Schedule, Quality와 연결될 수 있다는 사실을 이해해야 합니다.

 

 

10. 프로젝트는 이제 '설계'가 아니라 '실행'이 된다

 

이제부터 프로젝트는 본격적인 실행 단계로 들어갑니다.

 

흐름을 단순하게 표현하면 다음과 같습니다.

 

1. Project Award
2. Contract Finalization
3. Notice to Proceed
4. Project Kick-off
5. Project Baseline 설정
6. Engineering
7. Procurement
8. Construction
9. Commissioning
10. Performance Test
11. Handover

이제부터는 우리가 앞에서 만들었던 계획을 실제로 실행해야 합니다.

 

그리고 이 순간부터 프로젝트의 모든 활동은 서로 연결됩니다.

 

Process Engineer가 설계한 Process가 Equipment Datasheet가 되고, Mechanical Engineer가 Equipment를 구매하고, Piping Engineer가 배관을 연결하고, Instrument Engineer가 제어 시스템을 구성하고, Construction Team이 현장에서 설치하고, Commissioning Team이 실제로 운전합니다.

 

결국 프로젝트는 한 장의 P&ID에서 끝나는 일이 아닙니다.

 

하나의 설계가 수많은 엔지니어링 활동을 거쳐 실제 Plant로 만들어지는 과정입니다.

 

 

11. 그래서 수주 순간부터 프로젝트를 다르게 봐야 한다

 

프로젝트를 수주하면 흔히 이렇게 생각합니다.

“드디어 프로젝트를 따냈다.”

 

하지만 프로젝트를 수행하는 사람에게는 이렇게 생각하는 것이 더 정확합니다.

“이제 우리가 약속한 것을 증명해야 한다.”

 

수주 전에는 Proposal이 있었다면, 수주 후에는 Execution이 시작됩니다.

 

수주 전에는 Estimate가 있었다면, 수주 후에는 Budget이 필요합니다.

 

수주 전에는 Target Schedule이 있었다면, 수주 후에는 Baseline Schedule이 필요합니다.

 

수주 전에는 Risk Identification이 있었다면, 수주 후에는 Risk Management가 필요합니다.

 

그리고 수주 전에는 “이 프로젝트를 할 수 있는가?”를 고민했다면, 수주 후에는 “약속한 프로젝트를 어떻게 성공적으로 완성할 것인가?”를 고민해야 합니다.

 

 

12. Beer to Zero Project도 이제 진짜 시작이다

 

Beer to Zero Project도 지금까지 꽤 많은 과정을 거쳤습니다.

 

• 고객의 요구를 확인하고,
• Product Specification을 정하고,
• 생산능력을 결정하고,
• Site Condition을 검토하고,
• Battery Limit을 설정했습니다.
• 그리고 Feasibility를 검토하고,
• Process를 선정했습니다.
• PART 2에서는 한 단계 더 나아가
• Scope를 정하고,
• Cost를 계산하고,
• Schedule을 만들고,
• Risk를 검토했습니다.
• 그리고 Technical Proposal을 만들고,
• Commercial & Contract를 검토했습니다.

이제 고객이 말합니다.

“좋습니다. 이 프로젝트를 당신들에게 맡기겠습니다.”

 

그 순간, Beer to Zero Project는 더 이상 가상의 설계 검토가 아닙니다.

 

이제부터는 실제 프로젝트를 수행한다고 가정하고 움직여야 합니다.

 

우리가 제안했던 생산능력을 만족해야 하고, 계약한 Scope를 수행해야 하며, 약속한 Schedule을 지켜야 하고, Budget 안에서 프로젝트를 수행해야 합니다.

 

그리고 최종적으로는 “Beer를 만들 수 있는 Plant”를 실제로 만들어야 합니다.

 

 

마무리하며

 

프로젝트 수주는 엔지니어에게 상당히 기쁜 순간입니다.

 

하지만 프로젝트를 많이 경험할수록 알게 됩니다.

 

수주가 프로젝트의 성공을 의미하지는 않는다는 것을 말입니다.

 

수주는 단지 “이 프로젝트를 수행할 기회를 얻었다.”는 의미에 가깝습니다.

 

진짜 실력은 그다음부터 드러납니다.

 

계약을 이해하고, Scope를 관리하고, Engineering을 수행하고, Vendor를 관리하고, Construction을 수행하고, Commissioning을 완료하고, 결국 고객이 원하는 성능을 만족하는 Plant를 만들어내는 것. 그것이 Project Execution입니다.

 

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