Part 18. 설계의 출발점 - Design Basis란 무엇인가

프로젝트를 수주했습니다.

 

계약서에도 서명했고, 프로젝트의 Scope도 정했습니다.

 

비용과 일정도 어느 정도 확정되었습니다.

 

이제 엔지니어링 팀이 해야 할 일은 명확해 보입니다.

 

“그럼 설계를 시작하면 되는 것 아닌가?”

 

그런데 막상 엔지니어들이 모여 앉으면 첫 번째 질문부터 막힙니다.

“그래서 정확히 어떤 조건으로 설계하죠?”

 

• 생산량은 얼마인가?
• 원료의 조성은 어떻게 되는가?
• 제품의 품질은 어디까지 맞춰야 하는가?
• 정상 운전 조건은 무엇인가?
• 최대 운전 조건은?
• 설비의 설계압력과 설계온도는?
• Utility는 어디까지 제공되는가?
• 적용해야 할 Code와 Standard는 무엇인가?

그리고 가장 중요한 질문.

 

“우리가 지금 알고 있는 정보 중 확정된 것은 무엇이고, 아직 가정하고 있는 것은 무엇인가?”

 

바로 이 질문에 답하기 위해 필요한 것이 Design Basis입니다.

 

 

1. 설계는 도면을 그리는 것부터 시작하지 않는다

 

플랜트 엔지니어링을 처음 접하면 설계라고 하면 보통 이런 장면을 떠올립니다.

 

P&ID를 그리고, 장비를 선정하고, 배관을 연결하고, Pump를 계산하고, Instrument를 설치하는 것. 하지만 실제 프로젝트에서 설계는 그보다 훨씬 먼저 시작됩니다.

 

“무엇을 어떤 조건으로 만들어야 하는가?”를 정의하는 것이 먼저입니다.

 

예를 들어 Beer to Zero Project에서 하루 100,000L의 무알코올 맥주를 생산하는 공장을 설계한다고 가정해 보겠습니다.

 

“100,000L/day 생산”이라는 정보 하나만 가지고는 공장을 설계할 수 없습니다.

 

100,000L가

 

• 정상 생산량인지
• 최대 생산량인지
• 연간 평균 생산량인지
• 하루 24시간 기준인지
• 20시간 운전 기준인지

알 수 없기 때문입니다.

 

원료 역시 마찬가지입니다. 맥주의 Alcohol을 제거한다고 해도 원료의

 

• Alcohol 농도
• 온도
• 압력
• 유량
• 조성
• 불순물
• 점도

등을 알아야 실제 장비와 공정을 설계할 수 있습니다.

 

즉,

고객의 요구사항 → 설계 가능한 Engineering Parameter

 

로 변환하는 과정이 필요합니다.

 

그 결과물이 바로 Design Basis의 중요한 역할 중 하나입니다.

 

실제로 공정설계 분야에서는 Design Basis가 생산능력, 원료 및 제품 조건, Site 조건, Utility, 적용 Code, 설계 조건과 같은 주요 설계 입력값을 정리하고, 이를 바탕으로 이후의 설계를 진행하는 핵심 문서로 활용됩니다.

 

 

2. Design Basis란 무엇인가?

 

그렇다면 Design Basis는 정확히 무엇일까요?

 

간단하게 표현하면,

Design Basis란 플랜트의 설계와 엔지니어링을 수행하기 위해 필요한 조건, 기준, 가정, 제약사항을 정리한 설계의 기준 문서입니다.

 

여기서 중요한 단어가 있습니다.

 

Basis. 기초 또는 근거라는 뜻입니다. 즉, 엔지니어가 어떤 결정을 내렸을 때

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

 

라는 질문을 받으면,

 

그 판단의 출발점이 되는 것이 Design Basis입니다.

 

예를 들어 Pump의 용량을 결정했다고 생각해 보겠습니다.

 

Pump를 100 m³/h로 선정했습니다.

 

그러면 다음 질문이 나올 수 있습니다.

왜 100 m³/h입니까?

 

단순히 “엔지니어가 그렇게 정했습니다”라고 답할 수는 없습니다.

 

• 생산능력,
• Material Balance,
• 정상 운전 조건,
• Maximum Flow,
• Turndown,
• 배관 압력손실,
• 설비 여유율,
• 운전 철학

등을 근거로 설명해야 합니다.

 

결국 Design Basis는 이러한 설계 판단의 출발점과 근거를 문서화한 것이라고 볼 수 있습니다.

 

 

3. Design Basis와 Basis of Design은 같은 것일까?

 

실무에서 처음 접하면 조금 혼란스러운 부분이 있습니다.

 

• Design Basis
• Basis of Design, BoD
• Design Criteria
• Design Basis Memorandum, DBM

등 여러 표현이 사용되기 때문입니다.

 

여기서 중요한 것은 회사와 프로젝트에 따라 용어와 문서 체계가 조금씩 다를 수 있다는 점입니다.

 

어떤 프로젝트에서는 Design Basis와 Basis of Design을 거의 같은 의미로 사용합니다.

 

반면 어떤 조직에서는 Design Basis를 Owner가 요구하는 조건과 제약사항으로 보고, Basis of Design을 Engineering Contractor가 그 요구사항을 만족하기 위해 선택한 설계 방법과 기준으로 구분하기도 합니다.

 

또한 프로젝트 규모가 커지면 하나의 Design Basis 문서가 아니라

 

• Process Design Basis
• Mechanical Design Basis
• Piping Design Basis
• Electrical Design Basis
• Instrument Design Basis
• Civil Design Basis
• HSE Design Basis

등 Discipline별 문서로 나누어 관리하기도 합니다.

 

따라서 실무에서는 “Design Basis라는 이름의 문서가 정확히 무엇을 포함하는가?”를 프로젝트 문서 체계에서 먼저 확인하는 것이 중요합니다.

 

이 글에서는 이러한 여러 표현을 포괄하는 의미로 Design Basis라는 용어를 사용하겠습니다.

 

 

4. Design Basis에는 무엇이 들어가는가?

 

그렇다면 실제 Design Basis에는 어떤 내용이 들어갈까요?

 

프로젝트마다 다르지만 일반적인 플랜트 프로젝트라면 다음과 같은 내용을 생각할 수 있습니다.

 

① Project Objective

가장 먼저 프로젝트의 목적을 정의합니다. 예를 들어 Beer to Zero Project라면,

“기존 맥주 생산시설을 활용하여 무알코올 맥주를 생산할 수 있는 신규 공정을 구축한다.”

 

와 같은 프로젝트의 목적이 될 수 있습니다.

 

② Design Capacity

얼마나 생산할 것인지 정합니다. 예를 들어,

Product Capacity = 100,000L/day

 

라고 정했다면 여기서 끝이 아닙니다.

 

정상 생산량인지, 최대 생산량인지, 연간 운전시간은 얼마인지까지 정의해야 합니다.

 

Capacity는 이후

 

• Equipment Sizing
• Utility Consumption
• Pipe Sizing
• Storage Capacity
• Wastewater Capacity

등 수많은 설계 결과에 영향을 미칩니다.

 

③ Feed & Product Specification

무엇을 넣고 무엇을 만들어낼 것인지 정의합니다.

 

예를 들어 원료 맥주의

 

• Alcohol
• Sugar
• Water
• CO₂
• 기타 성분

등의 조건과 최종 제품의

 

• Alcohol Content
• CO₂ Content
• Taste
• Temperature
• Product Quality

등을 정의할 수 있습니다. 공정설계에서 Feed와 Product 조건은 이후 Material Balance와 Equipment Design의 중요한 입력값이 됩니다.

 

④ Operating Condition

공정이 실제로 어떤 조건에서 운전되는지 정의합니다. 예를 들어

 

• Operating Pressure
• Operating Temperature
• Normal Flow
• Maximum Flow
• Minimum Flow
• Start-up Condition
• Shutdown Condition

등입니다.

 

특히 여기서 중요한 것은 Normal Condition만 보는 것이 아니라 설계에 필요한 다양한 Operating Case를 정의하는 것입니다.

 

예를 들어 Pump를 선정할 때 Normal Flow만 보고 선정하면 안 됩니다. 정상 운전에서는 50 m³/h이지만 Maximum Case에서 70 m³/h가 필요하다면 Pump는 70 m³/h를 고려해야 할 수 있습니다. 반대로 Turndown이 필요한 공정이라면 최소 유량에서 안정적으로 운전할 수 있는지도 확인해야 합니다.

 

 

5. Design Condition과 Operating Condition은 다릅니다

 

여기서 엔지니어링에서 매우 중요한 개념이 하나 등장합니다.

 

Operating Condition과 Design Condition은 같은 것이 아닙니다.

 

예를 들어 어떤 Vessel의 정상 운전 조건이

5 barg / 80℃

 

라고 해보겠습니다.

 

그렇다고 Vessel의 Design Pressure가 반드시 5 barg인 것은 아닙니다.

 

비정상 상황이나 다른 설계 Case를 고려하여 더 높은 압력을 견딜 수 있도록 설계해야 할 수 있기 때문입니다.

 

즉, Operating Condition → 평상시에 어떻게 운전되는가?

Design Condition → 설비가 어떤 최악의 조건까지 고려하여 설계되어야 하는가?

 

라는 차이가 있습니다. 이 차이는 이후

 

• Equipment Design
• Piping Design
• PSV Sizing
• Material Selection
• Instrumentation
• Safety Design

으로 이어집니다.

따라서 Design Basis에는 단순히 “운전압력 5 barg”라고 적는 것보다 어떤 조건을 기준으로 설계할 것인지가 명확하게 정의되어야 합니다.

 

 

6. Site Condition도 설계의 일부입니다

 

공장은 공중에 떠 있는 설비가 아닙니다. 결국 특정 장소에 설치됩니다.

 

따라서 Site Condition 역시 Design Basis의 중요한 입력값입니다.

 

예를 들어

 

• Ambient Temperature
• Humidity
• Rainfall
• Wind
• Seismic Condition
• Elevation
• Soil Condition
• Available Utility
• Electrical Power
• Cooling Water
• Instrument Air
• Nitrogen

등이 설계에 영향을 줍니다.

 

같은 Pump라도 주변 온도가 20℃인 지역과 40℃인 지역에서 고려해야 할 조건이 다를 수 있습니다.

 

Cooling Water 역시

“Cooling Water가 있습니다.”

 

라고만 해서는 충분하지 않습니다.

 

공급 온도와 압력, Return 조건, 사용 가능 유량 등이 정의되어야 실제 설계에 사용할 수 있습니다.

 

즉,

Design Basis는 단순한 Process 조건만 모아 놓은 문서가 아닙니다.

 

플랜트 전체의 설계에 영향을 주는 조건을 하나의 기준으로 정리하는 것입니다.

 

 

7. Code와 Standard도 Design Basis에서 결정됩니다

 

플랜트 설계에서 엔지니어가 마음대로 설계할 수 있는 것은 많지 않습니다.

 

적용해야 하는 법규와 Code, Standard가 있기 때문입니다.

 

예를 들어 프로젝트의 성격에 따라

 

• ASME
• API
• NFPA
• IEC
• ISO
• KS
• 산업안전보건 관련 법규

등이 적용될 수 있습니다.

 

그리고 중요한 것은 단순히 “ASME를 적용한다”가 아닙니다.

 

어떤 Code의 어떤 Edition을 적용하는지, 어떤 Specification과 Client Standard를 적용하는지를 명확하게 해야 합니다.

 

왜냐하면 프로젝트 중간에 서로 다른 기준을 적용하면 문제가 발생하기 때문입니다.

 

Process Engineer는 한 기준으로 계산하고, Mechanical Engineer는 다른 기준으로 Equipment를 선정하고, Piping Engineer는 또 다른 기준으로 설계한다면, 각각의 계산은 맞더라도 전체 Plant Design에서는 충돌이 발생할 수 있습니다.

 

그래서 Design Basis는 여러 Discipline이 같은 기준을 바라보게 만드는 역할을 합니다.

 

 

8. Design Basis가 없으면 어떤 일이 생길까?

 

여기서 한 가지 가정을 해보겠습니다.

 

Beer to Zero Project의 설계를 시작했습니다. Process Engineer는 하루 생산량을 100,000L/day로 생각하고 있습니다. 그런데 Mechanical Engineer는 고객이 이야기했던 최대 생산량인 120,000L/day를 기준으로 Equipment를 검토합니다. Electrical Engineer는 정상 운전 조건을 기준으로 Utility Load를 계산합니다. 그리고 Instrument Engineer는 Maximum Flow를 기준으로 Control Valve를 선정합니다.

 

각각의 엔지니어가 틀렸다고 할 수 있을까요?

 

아닙니다. 각자의 기준에서는 모두 맞을 수 있습니다.

 

문제는 프로젝트 전체가 같은 기준으로 설계되고 있지 않다는 것입니다.

 

결과적으로 이런 문제가 발생할 수 있습니다.

 

Equipment 용량이 서로 맞지 않고, Pipe Size가 달라지고, Utility Load가 변경되고, Control Valve Size가 바뀌고, P&ID가 수정되고, 장비 구매 사양이 바뀌고, 결국 이미 완료한 설계를 다시 해야 합니다.

 

이것이 바로 초기 단계에서 Design Basis를 명확하게 잡아야 하는 이유입니다.

 

Design Basis가 이후 상세설계의 기준 역할을 하며, 불명확한 기준은 설계 변경과 Discipline 간 불일치로 이어질 수 있다는 점은 여러 플랜트 설계 자료에서도 강조됩니다.

 

 

9. 사실 Design Basis의 핵심은 '정보'가 아니라 '가정'입니다

 

여기서 한 단계 더 들어가 보겠습니다. 초기 프로젝트에서 모든 정보가 확정되어 있을까요?

 

그렇지 않습니다. 오히려 프로젝트 초기에는 모르는 것이 많습니다.

 

원료의 정확한 조성이 아직 확정되지 않았을 수도 있고, Utility Capacity를 고객이 아직 확인하지 못했을 수도 있고, Vendor Equipment Data가 아직 나오지 않았을 수도 있습니다.

 

그렇다면 설계를 시작할 수 없는 것일까요?

 

그렇지 않습니다. 엔지니어는 합리적인 가정을 설정하고 설계를 진행합니다.

 

예를 들어,

“Feed의 Water Content는 현재 제공된 분석자료를 기준으로 한다.”

“Cooling Water Supply Temperature는 32℃를 기준으로 한다.”

“Equipment Sizing에는 10%의 Design Margin을 적용한다.”

 

와 같이 설계의 전제조건을 명시합니다.

 

그리고 중요한 것은 이것입니다.

 

가정을 숨기면 안 됩니다. 가정은 틀릴 수 있습니다.

 

하지만 어떤 가정을 했는지 알고 있다면 나중에 새로운 정보가 들어왔을 때 그 영향도를 추적할 수 있습니다.

 

반대로 가정을 문서화하지 않으면, 나중에 설계가 왜 그렇게 되었는지 아무도 알 수 없습니다.

 

좋은 Design Basis는 확정된 정보와 가정된 정보를 구분해서 보여주는 문서이기도 합니다.

 

 

10. Design Basis는 한 번 작성하고 끝나는 문서가 아닙니다

 

초기 Design Basis를 작성했다고 해서 프로젝트가 끝날 때까지 그대로 유지되는 것은 아닙니다.

 

오히려 프로젝트가 진행되면서 계속 업데이트될 수 있습니다.

 

예를 들어 처음에는

Production Capacity = 100,000 L/day

 

였는데 고객 요구사항이 변경되어

Production Capacity = 120,000 L/day

 

가 될 수 있습니다. 그러면 단순히 숫자 하나만 바뀌는 것이 아닙니다. Capacity가 증가하면

 

• Material Balance
• Equipment Size
• Pipe Size
• Utility Load
• Electrical Load
• Wastewater
• Storage Capacity
• Building Space

등에 연쇄적으로 영향을 줄 수 있습니다. 따라서 Design Basis가 변경되었다면 그 변경이 다른 설계 결과에 어떤 영향을 미치는지 확인하는 과정도 필요합니다. 즉,

Design Basis는 설계의 시작점이면서 프로젝트 전체에서 관리해야 하는 살아 있는 기준입니다.

 

실제 엔지니어링에서도 초기 기준은 프로젝트가 진행되면서 변경·보완될 수 있으며, 변경된 기준을 관련 엔지니어들이 공유하도록 관리하는 것이 중요하다고 설명합니다.

 

 

11. Design Basis는 결국 '엔지니어들의 공통 언어'입니다

 

프로젝트에는 수많은 사람이 참여합니다.

 

• Process Engineer,
• Mechanical Engineer,
• Piping Engineer,
• Electrical Engineer,
• Instrument Engineer,
• Civil Engineer,
• HSE Engineer,
• Construction Engineer,
• Procurement Engineer.

서로 다른 분야의 사람들이 하나의 Plant를 만들어야 합니다.

 

이때 필요한 것이 공통의 기준입니다.

 

Process Engineer가 말하는 100 m³/h와

 

Mechanical Engineer가 말하는 100 m³/h가

 

같은 조건을 의미해야 합니다. Design Basis는 바로 이 역할을 합니다.

“우리는 이 프로젝트를 이런 조건과 기준을 가지고 설계한다.”

 

라는 프로젝트 전체의 약속인 것입니다.

 

그래서 Design Basis는 단순한 문서가 아닙니다. Engineering Team이 공유하는 하나의 언어에 가깝습니다.

 

 

12. Beer to Zero Project의 Design Basis를 만들어보자

 

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

 

앞선 PART 2에서 우리는 프로젝트를 수주했습니다.

 

이제 진짜 설계를 시작해야 합니다.

 

그렇다면 가장 먼저 해야 할 일은 무엇일까요? P&ID를 그리는 것일까요? Equipment를 선정하는 것일까요?

 

아닙니다. 먼저 다음 질문에 답해야 합니다.

 

Project

• 무엇을 만들 것인가?
• 왜 만드는가?
• 어디까지 우리가 설계하는가?

Production

• 얼마를 생산하는가?
• 몇 시간 운전하는가?
• 정상/최대/최소 생산량은 얼마인가?

Feed

• 무엇을 원료로 사용하는가?
• 원료의 조성은?
• 유량, 온도, 압력은?

Product

• 어떤 제품을 만들어야 하는가?
• 품질 기준은?
• 생산 후 어떤 조건으로 전달하는가?

Process

• 어떤 공정을 사용하는가?
• 정상 운전 조건은?
• Start-up과 Shutdown 조건은?

Site

• 공장은 어디에 설치하는가?
• 주변 환경 조건은?
• 기존 설비와 어떻게 연결되는가?

Utility

• 전기는 어디까지 제공되는가?
• Cooling Water는?
• Steam은?
• Instrument Air는?
• Nitrogen은?

Design

• 어떤 Code와 Standard를 적용하는가?
• 설비의 Design Margin은?
• Redundancy는 어떻게 할 것인가?
• 어떤 설계 철학을 적용할 것인가?

이 질문들에 대한 답을 하나씩 정리하다 보면,

 

우리가 무엇을 설계해야 하는지가 조금씩 선명해집니다.

 

그리고 그것을 하나의 문서로 정리한 것이 바로 Design Basis입니다.

 

 

13. 결국 설계란 '기준을 정하는 일'에서 시작됩니다

 

엔지니어링을 하다 보면 이런 말을 자주 듣습니다.

“설계는 계산하는 거 아닌가요?”

 

물론 계산은 중요합니다. 하지만 계산보다 먼저 필요한 것이 있습니다.

 

무엇을 기준으로 계산할 것인가?

 

예를 들어 Pump의 Head를 계산하려면 Flow가 필요하고,

 

Flow를 정하려면 Process Requirement가 필요하며,

 

Process Requirement를 정하려면 Production Capacity와 Operating Condition이 필요합니다.

 

그리고 그 모든 조건의 근거가 어디에 있는지를 확인해야 합니다.

 

결국 하나의 설계 결과는 수많은 전제조건 위에 만들어집니다.

 

그래서 엔지니어링에서 중요한 것은 단순히 “계산 결과가 얼마인가?”가 아니라, “왜 그 숫자를 사용했는가?”입니다.

 

그리고 그 질문에 답하기 위한 출발점이 Design Basis입니다.

 

 

이제 우리는 '무엇을 설계할 것인가'를 정의했다

 

Beer to Zero Project는 이제 새로운 단계로 들어왔습니다.

 

PART 1에서는 고객의 요구사항을 정의했습니다.

 

PART 2에서는 그 프로젝트를 실제로 수행하기 위한 Scope, Cost, Schedule, Risk를 검토하고 결국 계약을 체결했습니다.

 

그리고 이제 PART 3입니다.

 

Design Basis.

 

계약이 끝났다고 바로 설계가 시작되는 것은 아닙니다. 설계를 하기 위해서는 먼저,

“우리는 무엇을 어떤 조건과 기준으로 설계할 것인가?”

 

를 정의해야 합니다. 그것이 Design Basis입니다.

 

Design Basis가 잘 만들어지면 이후의 PFD, Material Balance, Equipment Sizing, P&ID, Piping, Instrumentation, Electrical Design 등 수많은 Engineering 결과물이 같은 방향으로 움직일 수 있습니다.

 

반대로 이 기준이 불명확하면 설계가 진행될수록 문제가 커집니다.

 

그래서 저는 Design Basis를 이렇게 표현하고 싶습니다.

Design Basis는 설계의 첫 번째 계산서가 아니라, 모든 계산이 시작될 수 있도록 만들어 주는 '설계의 약속'입니다.

 

이제 기준이 정해졌습니다. 그렇다면 다음 질문이 남습니다.

 

“이 기준을 가지고 실제로 어떤 공정을 설계할 것인가?”

 

다음 편부터는 이 Design Basis를 하나씩 채워가면서 Beer to Zero 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 확정