Stress 업무를 처음 배울 때 중요한 단위계 중 하나는 압력 (Pressure)입니다.
1. 압력의 종류
압력이란 어떤 힘을 그 힘이 작용하는 면적으로 나눈 값입니다. 예를 들면 1N의 힘으로 면적 1m2에 힘을 가할 때 받는 압력을 1 N/m2로 나타낼 수 있습니다. 설계업무 진행시 다양한 압력 단위를 사용합니다.
우리가 설계와 해석에서 마주하는 압력의 종류는 크게 세 가지로 분류할 수 있습니다.
(1) 대기압 (Atmospheric Pressure, ATM) : 지구를 둘러싼 대기가 누르는 압력입니다.
지구 대기의 압력은 ATM = 14.6 psi = 1.01325 bar 입니다.
(2) 절대압력 (absulate pressure, bar A) : 진공에서 측정된 압력으로 우주 공간이나 완벽한 밀폐계 내부의 상태를
나타날 때 적합합니다.
(3) 게이지압력 (gauge pressure, bar G): 우리가 일성적으로 사용하는 계측기가 나타내는 압력입니다.
대기압이 존재하는 곳에서 측정하기 때문에 대기압을 제외한 압력 즉, 대기압을 0으로 기준으로 측정된 압력)이며,
수식으로는 bar G = bar A - ATM 나타낼 수 있습니다.
2. bar G vs. bar A
프로젝트의 Line List에서 흥미로운 부분을 발견했습니다. Design Condition을 확인하는데 운전 압력(Operating Pressure, OPE. P)은 bar A로, 설계 압력(Design Pressure, DES. P)은 bar G로 혼용되어 표기되어 있었던 것입니다.
Line List에서 Design Condition에 Operating Pressure(OPE. P)가 bar A, Design Pressure(DES. P)는 bar G로 표기되어 있어서 "왜 압력 단위를 통일하지 않았지? 대기압 차이가 있는데..."라는 의문이 생겨서 Process 담당자에게 물어보았더니 돌아온 대답은 예상외로 단순했습니다.
"오래전부터 그렇게 사용해 왔는데, 정확히 왜 구분해서 적기 시작했는지는 잘 모르겠습니다."
관행적으로 이어져 온 데이터 시트의 양식. 아마도 아주 오래전, 현장의 직관적인 구분을 위해 운전 상태는 물리적 절대치(bar A)로, 기기 자체의 설계 마진은 계측기 기준(bar G)으로 이원화할 필요성이 있었을 것이라 짐작해 볼 뿐이었습니다. 실제로 다른 어떤 공사에서는 깔끔하게 bar G 하나로만 통일하여 사용하는 경우도 많기 때문입니다.
발전 공사의 배관 응력 해석을 진행할 때, 발주처의 특별한 언급이 없다면 우리는 OPE. P와 DES. P를 각각의 Load Case에 반영합니다. 과거에는 관행적으로 해석 프로그램 입력 시 기준을 맞추기 위해 bar G를 기준으로 삼고, bar A로 표기된 값은 대기압만큼을 빼서 입력하곤 했습니다. 현장과 데이터 사이의 미세한 갭을 엔지니어의 경험적 판단으로 보정했던 셈입니다.
그러나 최근 진행되는 프로젝트에서는 접근 방식이 달라졌습니다. Design Condition이 출력되는 일반 ISO와 Stress ISO 간의 데이터 완벽한 일치가 무엇보다 중요해졌기 때문입니다. 도면 간의 불일치로 인한 혼선을 방지하기 위해, 이제는 생략이나 임의 보정 없이 데이터 시트에 명시된 bar A와 bar G 값을 그대로 프로그램에 입력하고 있습니다.
3. Caesar2에서 Pressure 입력 기준
배관응력해석 Software인 Caesar2에서 Pressure는 어떤 기준으로 입력할까요?
Pressure 입력란에 F1을 치면 아래와 같이 Help가 나옵니다. Highlight 된 문장을 보시면 입력 기준이 bar G인 것을 알 수 있습니다.
만일 Pressure가 대기압이라면 Caesar2에서는 0 (bar G 입력, 대기압 반영됨)으로 입력해야 합니다.
예전에 대기압 조건에서 응력 해석 시 "0 이면 진공이니까 대기압인 1.01325 bar를 입력" 하여 잘못된 해석 결과로 Report를 작성한 적이 있었습니다. 다행히 온도 조건이 낮아서 무사히(?) 넘어갔습니다만, 다시는 이런 실수를 하지 말자라는 생각이 들어서 글을 올리게 되었습니다.
우리는 매일 수많은 데이터와 도면을 다룹니다. 그 안에는 오래 시간 굳어진 '관행'이라는 이름의 유산들이 남아있습니다. 기술이 발전하고 시스템이 고도화될수록, 과거의 직관적 구분이 현재에는 불필요한 번거로움이나 데이터 불일치의 리스크가 되기도 합니다.
이번 의문과 프로세스 담당자와의 대화를 통해 다시금 깨닫습니다. 엔지니어란 단순히 주어진 숫자를 프로그램에 대입하는 사람이 아니라, 그 숫자가 가진 배경에 끊임없이 질문을 던지는 사람이어야 한다는 것을 말입니다.
비록 '오래전부터 그래왔다.'는 모호한 답변으로 시작되었지만, 결국 도면 간의 일치성을 위해 압력을 정의하는 과정 속에서 우리는 한 단계 더 정밀한 설계가 되지 않을까 하는 생각이 듭니다. 익숙함에 순응하지 않고 늘 '왜?'를 생각할 때 비로소 나의 실력이 더 향상될 것으로 믿습니다.
감사합니다.