Part 27. 설계의 기준을 하나의 문서로 묶다 - Design Basis 확정

설계는 도면에서 시작하지 않는다

 

프로젝트가 시작되면 엔지니어들은 곧바로 PFD를 그리고, 장비를 선정하고, 배관 사이즈를 계산할 것처럼 보입니다.

 

하지만 실제 프로젝트에서는 그보다 먼저 해야 할 일이 있습니다.

 

바로 “무엇을 기준으로 설계할 것인가?”를 정하는 것입니다.

 

앞선 과정에서 우리는 하나씩 질문에 답해 왔습니다.

 

• 무엇을 만들 것인가?
• 얼마나 만들 것인가?
• 원료는 어떤 조건으로 들어오는가?
• 제품은 어떤 조건으로 나가는가?
• 공장은 하루에 몇 시간 운전하는가?
• 정상 운전 조건은 무엇인가?
• 설비는 어느 압력과 온도를 견뎌야 하는가?
• 어떤 Utility를 사용할 것인가?
• 어떤 재질을 사용할 것인가?
• 어떤 Code와 Standard를 적용할 것인가?

각 질문에 대한 답이 따로 존재한다면 아직 설계의 기준이 완성된 것은 아닙니다.

 

이제는 이 모든 내용을 하나의 문서로 묶어야 합니다.

 

그 문서가 바로 Design Basis입니다.

 

 

1. Design Basis는 무엇인가?

 

Design Basis는 말 그대로 설계의 근거가 되는 기준입니다.

 

프로젝트에서 엔지니어가 어떤 결정을 내렸을 때,

“왜 이렇게 설계했습니까?”

 

라는 질문을 받는다면 그 답의 출발점이 되는 문서라고 생각할 수 있습니다.

 

일반적인 Basis of Design 또는 Design Basis에는 프로젝트 목적과 범위, 생산능력, 원료와 제품 조건, 운전조건, Utility, Site Condition, 적용 Code 및 Standard, 안전 및 설계 철학, 재질 선정 기준 등의 내용이 포함될 수 있습니다.

 

쉽게 표현하면 다음과 같습니다.

 

Design Basis = 이 프로젝트에서 설계를 하기 위해 우리가 합의한 출발 조건과 설계 기준

 

여기서 중요한 것은 Design Basis가 모든 설계 결과를 담는 문서는 아니라는 점입니다.

 

예를 들어 Pump의 최종 Impeller 직경이나 Control Valve의 정확한 Cv 값, 배관 Isometric의 상세 치수까지 Design Basis에서 결정하는 것은 아닙니다.

 

Design Basis는 그보다 상위에서

“어떤 조건에서 설계할 것인가?”

 

를 결정합니다. 그리고 실제 계산과 상세 설계는 그 기준을 따라 진행됩니다.

 

 

2. 왜 하나의 문서로 묶어야 하는가?

 

여기서 조금 현실적인 상황을 생각해 보겠습니다.

 

Beer to Zero Project에서 생산량은 하루 100 ton으로 결정되었습니다.

 

Process Engineer는 이 값을 기준으로 Material Balance를 작성합니다.

 

그런데 Mechanical Engineer가 확인해 보니 설비의 Design Capacity는 120 ton/day를 기준으로 잡혀 있습니다.

 

Piping Engineer는 또 다른 문서를 보고 150 ton/day를 기준으로 배관을 계산하고 있습니다.

 

Utility Engineer는 최대 운전조건을 기준으로 Utility Load를 계산했는데, Process Engineer는 정상 운전조건을 사용했습니다.

 

각각의 계산만 보면 모두 그럴듯합니다. 하지만 프로젝트 전체를 놓고 보면 문제가 생깁니다.

 

서로 다른 기준으로 설계하고 있기 때문입니다.

 

이것이 Design Basis가 필요한 가장 중요한 이유 중 하나입니다.

 

설계 기준이 명확하지 않으면 각 Discipline이 각자의 경험과 판단을 바탕으로 설계를 시작하게 됩니다.

 

그러면 나중에 이런 문제가 발생합니다.

 

• Equipment Size가 서로 맞지 않음
• Utility Load가 계속 변경됨
• P&ID가 반복적으로 수정됨
• Piping Size가 변경됨
• Instrument Specification이 변경됨
• Vendor가 다른 조건으로 Equipment를 선정함
• Cost Estimate가 변경됨
• 결국 일정이 지연됨

즉, 초기 기준의 작은 차이가 프로젝트 후반부의 큰 변경으로 이어질 수 있습니다.

 

따라서 Design Basis는 단순한 참고자료가 아니라 여러 Discipline이 같은 방향을 바라보게 만드는 공통 기준점이라고 볼 수 있습니다.

 

 

3. 지금까지 결정한 내용을 하나씩 모아보자

 

이제 Beer to Zero Project를 기준으로 생각해 보겠습니다.

 

앞선 Part 18부터 우리는 설계에 필요한 조건들을 하나씩 정리했습니다.

 

① Feed & Product Condition

먼저 무엇을 넣고 무엇을 생산할 것인지 결정했습니다.

 

원료의 조성, 유량, 압력, 온도와 제품의 사양 등이 여기에 해당합니다.

 

이 정보는 이후 Material Balance와 Process Design의 출발점이 됩니다.

 

② Design Capacity

그다음 공장이 얼마나 생산해야 하는지를 결정했습니다.

 

예를 들어,

Design Capacity = 100 ton/day

 

라고 결정했다면 이후 주요 설비와 공정은 이 생산능력을 만족하도록 설계되어야 합니다.

 

단순히 “100 ton/day를 생산한다”에서 끝나는 것이 아니라 Turndown, Design Margin, Operating Rate 등도 함께 고려해야 합니다.

 

③ Operating Philosophy

공장을 몇 시간 운전할 것인지, 연간 몇 일 운전할 것인지, Continuous Operation인지 Batch Operation인지 등을 결정했습니다.

 

이러한 조건은 생산량뿐만 아니라 설비의 운전 및 Maintenance Philosophy에도 영향을 줍니다.

 

④ Operating Condition

정상 운전에서 각 Stream이 어떤 압력과 온도를 가지는지도 정했습니다.

 

예를 들어 어떤 Process Line이

 

• Pressure: 5 barg
• Temperature: 40℃

에서 정상적으로 운전된다면 이것은 Operating Condition입니다.

 

하지만 여기서 끝나면 안 됩니다. 정상 운전조건과 실제 설비가 견뎌야 하는 조건은 다를 수 있기 때문입니다.

 

⑤ Design Pressure & Design Temperature

 

그래서 설비와 배관이 실제로 견뎌야 하는 Design Pressure와 Design Temperature를 별도로 결정했습니다.

 

정상 운전압력이 5 barg라고 해서 Design Pressure도 반드시 5 barg인 것은 아닙니다.

 

Start-up, Shutdown, Blocked-in, Utility Failure, Relief Scenario 등 예상 가능한 조건을 검토하여 더 높은 압력이나 온도가 발생할 수 있는지를 확인해야 합니다.

 

이러한 Design Pressure와 Temperature는 Equipment와 Piping의 기계적 설계에 직접 연결됩니다. 초기 단계에서 DP/DT를 결정하는 것이 중요하다는 점도 설계 자료에서 강조됩니다.

 

⑥ Utility Condition

공장은 Process만으로 움직이지 않습니다.

 

Steam, Cooling Water, Chilled Water, Nitrogen, Instrument Air, Plant Air, Electricity 등 다양한 Utility가 필요합니다.

 

따라서 각각의 공급 압력, 온도, 품질, 가용량 등을 정의해야 합니다.

 

예를 들어

Cooling Water Supply = 32℃

 

라는 단순한 숫자 하나만으로도 설계에 영향을 줄 수 있습니다.

 

Heat Exchanger의 열교환 면적, 냉각수 유량, Pump Capacity 등이 연결되기 때문입니다.

 

⑦ Material of Construction

그다음에는 설비와 배관을 어떤 재질로 만들 것인지 결정합니다.

 

Carbon Steel을 사용할 것인지, Stainless Steel을 사용할 것인지, 특정 부식성 유체에 적합한 재질을 사용할 것인지 결정해야 합니다.

 

이 역시 단순히 Mechanical Engineer 한 명이 결정하는 문제가 아닙니다.

 

Process 유체의 조성, 온도, 압력, 부식성, 운전조건과 연결되어 있기 때문입니다.

 

⑧ Code & Standard

 

마지막으로 중요한 것이 있습니다.

 

무슨 기준으로 설계할 것인가?

 

ASME, API, IEC, NFPA, ASTM과 같은 국제적인 Code와 Standard뿐만 아니라 국가 법규, 발주처 Specification, 회사 Engineering Standard 등이 설계에 영향을 줄 수 있습니다.

 

따라서 프로젝트에서는 적용되는 Code와 Standard뿐만 아니라 서로 충돌할 경우 어떤 기준을 우선 적용할 것인지도 명확하게 관리할 필요가 있습니다.

 

 

4. 이제 각각의 정보가 하나의 Design Basis가 된다

 

여기까지 왔다면 흩어져 있던 정보가 상당히 많아졌습니다.

 

이제 이것을 하나의 구조로 정리합니다.

 

일반적인 Design Basis의 구성은 프로젝트에 따라 달라질 수 있지만, 다음과 같은 구조로 생각하면 이해하기 쉽습니다.

 

구분	주요 내용
Project Overview	프로젝트 목적 및 배경
Scope of Work	설계 및 공사 범위
Plant Capacity	생산능력 및 Design Margin
Feed Condition	원료 조성, 유량, 압력, 온도
Product Condition	제품 사양 및 출구 조건
Operating Philosophy	운전시간, Availability, Turndown
Process Design Condition	주요 공정 조건
Design Pressure & Temperature	설비 및 배관 설계조건
Utility Condition	Steam, CW, N₂, Air, Power 등
Site Condition	온도, 습도, 고도, 지진, 풍속 등
Material Selection	주요 재질 및 부식 고려사항
Safety Philosophy	안전 및 보호 시스템의 기본 철학
Control Philosophy	제어 및 Shutdown의 기본 방향
Codes & Standards	적용 법규, Code, Standard
Battery Limit	Process 및 Utility Interface
Design Assumption	설계에 사용한 주요 가정
Exclusion	설계에서 제외되는 범위
Special Requirement	발주처 및 프로젝트 특수 요구사항

 

실제 프로젝트에서는 Process Design Basis와 각 Discipline Design Criteria를 별도의 문서로 관리하기도 하고, 하나의 Design Basis 또는 Design Basis Memorandum으로 통합하기도 합니다. 중요한 것은 문서의 이름보다 설계에 필요한 기준이 일관되게 정의되고 관리되는 것입니다.

 

 

5. Design Basis에서 특히 중요한 것은 '숫자'다

 

Design Basis를 작성할 때 단순히 설명만 나열해서는 부족합니다.

 

엔지니어링 문서에서 중요한 것은 결국 설계에 사용할 수 있는 구체적인 수치와 조건이기 때문입니다.

 

예를 들어 다음과 같이 작성하는 것과

Cooling Water가 공급된다.

 

다음과 같이 작성하는 것은 완전히 다릅니다.

Cooling Water Supply Pressure: 4 barg
Cooling Water Supply Temperature: 32℃
Cooling Water Return Temperature: 42℃

 

첫 번째는 정보입니다.

 

두 번째는 설계 조건입니다.

 

두 번째 조건이 있어야 Process Engineer는 Heat Balance를 계산할 수 있고, Mechanical Engineer는 Heat Exchanger를 설계할 수 있으며, Utility Engineer는 필요한 Cooling Water Load를 검토할 수 있습니다.

 

따라서 좋은 Design Basis는 단순히 많은 내용을 담은 문서가 아닙니다.

 

설계자가 실제로 사용할 수 있는 수준으로 조건을 구체화한 문서입니다.

 

 

6. Design Basis에는 '가정'도 반드시 남겨야 한다

 

초기 프로젝트에서는 모든 정보가 확정되어 있지 않습니다.

 

오히려 대부분의 프로젝트가 그렇습니다.

 

예를 들어 Client가 아직 최종 Feed Composition을 제공하지 않았다고 가정해 보겠습니다.

 

그렇다면 엔지니어는 프로젝트를 멈춰놓을 수 없습니다.

 

기존 Plant Data나 Client의 예상값을 이용해 임시 설계조건을 설정할 수 있습니다.

 

예를 들어,

Feed Composition은 Client Preliminary Data를 기준으로 한다.

 

라고 명시할 수 있습니다.

 

그리고 이후 실제 Data가 확보되면 해당 값을 다시 검토합니다.

 

여기서 중요한 것은 가정을 숨기지 않는 것입니다.

 

Design Basis에 다음과 같이 명확하게 남겨두는 것입니다.

 

• Assumption
• Source
• Basis
• Limitation
• Confirmation Required

이렇게 하면 나중에 조건이 변경되더라도

“왜 처음에는 이렇게 설계했는가?”

 

를 추적할 수 있습니다. 즉, Design Basis는 확정된 숫자만 기록하는 문서가 아니라 설계에 사용된 가정과 그 근거를 추적할 수 있게 만드는 문서이기도 합니다.

 

 

7. Design Basis가 확정되면 무엇이 달라지는가?

 

이제 프로젝트의 중요한 순간이 찾아옵니다.

 

Design Basis가 작성되고 내부 검토가 끝났습니다. Process Engineer가 검토합니다. Mechanical Engineer가 검토합니다. Piping Engineer가 검토합니다. Electrical Engineer와 Instrument Engineer도 검토합니다. 그리고 Client와 협의가 끝났습니다.

 

마침내 문서에 Approved / Issued for Design이라는 의미의 상태가 부여됩니다.

 

이 순간부터 Design Basis는 단순한 초안이 아니라 설계의 기준선(Baseline) 역할을 하게 됩니다.

 

이제 엔지니어가 PFD를 작성할 때도, P&ID를 작성할 때도, Equipment Datasheet를 작성할 때도, Piping을 설계할 때도, Instrument를 선정할 때도, 기본적으로 이 기준을 참조하게 됩니다.

 

 

8. 그렇다고 Design Basis가 절대 바뀌지 않는 것은 아니다

 

여기서 한 가지 오해하면 안 되는 부분이 있습니다.

 

Design Basis가 확정되었다고 해서 영원히 변경할 수 없는 것은 아닙니다.

 

프로젝트를 진행하다 보면 새로운 정보가 들어옵니다.

 

Vendor가 기존 설계조건으로는 Equipment를 제작하기 어렵다고 할 수도 있습니다.

 

Client가 Product Specification을 변경할 수도 있습니다.

 

현장 조사 결과 기존에 알지 못했던 조건이 발견될 수도 있습니다.

 

또는 HAZOP 과정에서 새로운 안전 요구사항이 발생할 수도 있습니다.

 

이 경우 Design Basis를 무조건 고정해서 프로젝트를 진행하는 것이 오히려 위험합니다.

 

중요한 것은 변경을 통제하는 것입니다.

 

 

9. Design Basis와 Management of Change

 

예를 들어 처음에는 하루 100 ton 생산을 기준으로 설계했습니다.

 

그런데 Client가 생산량을 120 ton/day로 증가시키기로 결정했다고 가정해 보겠습니다.

 

단순히 Design Basis의 숫자 하나를 100에서 120으로 바꾸는 것으로 끝날까요?

 

그렇지 않습니다.

 

생산량이 증가하면

Capacity 증가 → Material Balance 변경 → Process Flow 변경 → Equipment Capacity 검토 → Pump 재검토 → Piping Hydraulic 재검토 → Utility Load 증가 → Electrical Load 증가 → Control Valve 및 Instrument 재검토 → Safety System 검토

 

와 같이 수많은 설계 항목이 영향을 받을 수 있습니다.

 

따라서 Design Basis의 변경은 곧 설계 기준의 변경입니다.

 

이 때문에 실제 프로젝트에서는 변경사항을 적절한 Change Control 또는 Management of Change(MOC) 절차를 통해 관리하는 것이 중요합니다.

 

Design Basis가 기준선이 되면 이후의 변경도 무엇이 바뀌었고, 왜 바뀌었으며, 어떤 설계에 영향을 주었는지를 추적할 수 있기 때문입니다.

 

 

10. 결국 Design Basis는 '프로젝트의 약속'이다

 

여기까지 오면 Design Basis를 조금 다른 관점에서 볼 수 있습니다.

 

Design Basis는 단순한 Engineering Document가 아닙니다.

 

그 안에는 프로젝트에 참여하는 사람들이 서로 합의한 내용이 들어 있습니다.

 

Client는 무엇을 요구하는지, EPC는 무엇을 설계해야 하는지, Process Engineer는 어떤 조건을 기준으로 계산하는지, Mechanical Engineer는 어떤 조건으로 설비를 설계하는지, Piping Engineer는 어떤 조건으로 배관을 설계하는지, Instrument Engineer는 어떤 조건으로 계기를 선정하는지,

 

그리고 각 Discipline이 어디까지 책임지는지가 연결되어 있습니다.

 

따라서 Design Basis는 프로젝트 구성원 사이의 기술적 약속이라고 볼 수 있습니다.

 

 

11. Beer to Zero Project의 Design Basis가 완성되었다

 

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

 

처음에는 단순히 Client의 요청 하나였습니다.

“맥주를 만들어 주세요.”

 

그 한마디에서 프로젝트가 시작되었습니다.

 

그리고 우리는 하나씩 질문했습니다.

 

• 무엇을 생산할 것인가?
• 얼마나 생산할 것인가?
• 원료는 무엇인가?
• 제품의 품질은 어떻게 되는가?
• 공장은 몇 시간 운전하는가?
• 정상 운전조건은 무엇인가?
• 설비는 어느 압력과 온도를 견뎌야 하는가?
• 어떤 Utility가 필요한가?
• 어떤 재질을 사용할 것인가?
• 어떤 Code와 Standard를 적용할 것인가?

그리고 이제 그 모든 답이 하나의 문서에 담겼습니다.

 

Design Basis.

 

이제부터 엔지니어는 더 이상 빈 종이에서 설계를 시작하지 않습니다.

 

설계의 출발점이 생겼습니다. 그리고 이 순간부터 프로젝트는 다음 단계로 넘어갈 수 있습니다.

 

 

12. Design Basis 다음에는 무엇이 시작되는가?

 

Design Basis가 완성되었다는 것은 설계가 끝났다는 뜻이 아닙니다.

 

오히려 반대입니다. 이제 진짜 설계가 시작됩니다.

 

Design Basis를 바탕으로 Material Balance를 확정하고, PFD를 작성하고, 주요 Equipment를 선정하고, Piping을 설계하고, P&ID를 구체화하고, Instrument와 Control System을 정의하고, Electrical, Civil, Mechanical Engineering을 진행하게 됩니다.

 

그리고 각각의 결과물은 다시 Design Basis와 비교됩니다.

“우리가 처음 정한 기준을 만족하고 있는가?”

 

이 질문이 반복되면서 하나의 Plant가 구체적인 형태를 갖추게 됩니다.

 

 

설계에는 출발점이 필요하다

 

좋은 설계는 좋은 계산에서만 시작되지 않습니다. 좋은 기준에서 시작됩니다.

 

아무리 훌륭한 Engineer라도 서로 다른 조건을 기준으로 설계한다면 좋은 Plant를 만들기 어렵습니다.

 

반대로 프로젝트의 조건과 가정, 설계 기준이 명확하게 정리되어 있다면 여러 Discipline이 동시에 움직이더라도 하나의 방향으로 설계를 진행할 수 있습니다.

 

그래서 Design Basis는 단순한 문서가 아닙니다.

 

프로젝트가 무엇을 만들 것인지 정의하고, 어떤 조건에서 운전하며, 어떤 기준으로 설계할 것인지를 하나의 언어로 정리한 문서입니다.

 

Beer to Zero Project에서 이제 그 기준이 완성되었습니다.

 

그리고 다음 단계부터는 이 기준을 가지고 실제 Plant를 하나씩 그려나가게 됩니다.

 

설계의 기준이 정해졌다면, 이제 그 기준을 실제 공정으로 바꿀 차례입니다.

 

 

Beer to Zero Project 연재 순서

 

PART 3. Design Basis — 우리가 무엇을 설계하는가

 

• Part 18. 설계의 출발점 - Design Basis란 무엇인가
• Part 19. 무엇을 넣고 무엇을 만들 것인가 - Feed & Product Condition
• Part 20. 하루 100톤을 만들려면 - Design Capacity 결정
• Part 21. 몇 시간 동안 공장을 돌릴 것인가 - Operating Philosophy
• Part 22. 몇 도와 몇 압력에서 운전할 것인가 - Operating Condition
• Part 23. 설비는 얼마나 견뎌야 하는가 - Design Pressure & Temperature
• Part 24. 공장을 움직이는 에너지는 어디서 오는가 - Utility Condition
• Part 25. 무엇으로 설비를 만들 것인가 - Material of Construction
• Part 26. 어떤 기준으로 설계할 것인가 - Code & Standard
• Part 27. 설계의 기준을 하나의 문서로 묶다 - Design Basis 확정