07 계산 도구 — pvcalc 와 DWSIM

뒷이야기 · 7 / 17단계 · 2026-08-04 ~ 10-03 · 갈래 계산 도구
이전 단계: 06 두뇌 관문 — omniroute · 9router · 사용량 절감 · 다음 단계: 08 사내 앱 — 차량관리와 ERP 시안

핵심 요약

한 줄 요약 — 계산기에서 제일 무서운 것은 「값은 나오는데 틀린 답」이다. 그래서 원문이 없으면 식을 추정해 채우지 않았고, 맞췄다고 말하는 것은 실물 계산서와 기계 대조로 못 박았다.

7단계 · 계산 도구

목적

두 가지 불편이 있었다.

• 압력용기 두께 계산은 어느 기준을 따르느냐에 따라 식 · 표 · 부수 규정이 다르다. 견적 · 사전 검토 · 상용 소프트웨어 결과의 교차검증에 쓸 계산기가 필요했다(README).
• 계산이 끝난 뒤가 사람 손이었다. 데이터시트 양식에는 화면 숫자를 손으로 옮겨 적었고, 견적 때 외형도는 CAD 로 다시 그렸다(9/23 · 9/25 커밋 메시지).

공정 시뮬레이터 DWSIM 은 따로 움직였다. 오픈소스(소스가 공개된 프로그램)라 쓸 수 있지만 화면이 영어였고, 쓰는 법을 직원이 매뉴얼로 익혀야 했다. 한국어로 말하면 Claude 가 돌려 주게 하는 것이 목표였다.

만든 순서

1 · 첫날 저녁 세 시간 — 엔진 두 벌과 일치 검사 (8/4)

2026-08-04 19:51에 첫 커밋(dc116c1)을 남기고, 22:57 다섯 번째 커밋까지 3시간 6분 동안 셸 · 경판 · 외압 · 노즐 보강 → 용접부 강도 → 볼트 플랜지 → 새들 지지 → 풍·지진 하중을 차례로 붙였다.

• 엔진을 두 벌 썼다. 계산식을 파이썬(pvcalc/)과 자바스크립트(web/pvcalc-core.js)에 각각 두었다. 웹 판은 서버 없이 브라우저에서 돌고, 파이썬 판은 손계산 대조에 쓴다. 두 엔진이 같은 값을 내는지는 사람이 보지 않고 기계가 대조한다(같은 입력 한 벌 = 벡터를 두 엔진에 넣어 비교).
• 숫자가 이렇게 자랐다. 손계산 대조 23 → 32 → 61 → 93 → 129건, 엔진 대조 106 → 199벡터, 파이썬 코드 702 → 1,890줄.
• 추정해서 채우지 않았다. 노즐 용접부 강도(UG-41)의 하중식은 상용 프로그램의 시연 보고서와 맞지 않았다(하중 W 가 약 10% 높게 나옴). 그래서 구현을 「참고값」으로 낮추고, 코드북에서 확인해야 할 항목 4개를 문서(comparison/UG41_verification.md)로 남겼다. 허브 있는 루즈형 플랜지, 새들 밖 보강링도 같은 이유로 뺐다.
• 남의 코드를 앵커로 잡았다. 참고로 본 오픈소스(calctoys)의 식을 가져오다가, 표준에 실린 공표값(앵커)과 비교해 오류 세 건을 찾았다. 새들 계수 K8 은 sin(2b)/4*b 로 적혀 있어 sin(2b)/(4b) 가 되어야 했고(그대로 두면 θ=120°에서 공표값보다 43% 작다), 플랜지 계수 두 곳은 옮겨 적다 틀린 기호가 들어 있었다.
• 배운 것. 식이 맞는지는 읽어서 알 수 없다. 공표된 숫자 하나를 6자리까지 재현하는지가 판정이다(플랜지 F=0.908920 · V=0.550103을 6자리, 새들 K1~K8 을 0.02% 이내).

2 · 플랫폼 탑재와 재료값 원칙 (8/5 13:48~14:05)

이튿날 낮에 사내 플랫폼의 기술부 도구함에 올렸다(플랫폼 7626068, 13:53).

• 화면을 다시 짜지 않았다. 탭이 많은 화면을 플랫폼용으로 다시 만들면 사본이 갈라진다. 그래서 단독 실행판 web/index.html 한 장을 그대로 iframe(페이지 안에 다른 페이지를 끼워 보여 주는 틀)으로 끼웠다. (이 결정이 나중에 갈라짐 문제를 줄였지만 없애지는 못했다. 7번 기록.)
• 재료값은 사람이 넣는다. 허용응력 표(ASME Sec II-D)는 저작권 자료라 저장소에 값을 담지 않는다. AI 가 표를 옮겨 적어 넣는 것도 금지했다. 판 · 각주 · 두께 구간을 추적할 수 없어 조용히 틀린 값이 되기 때문이다. 사용자가 「재료 데이터 관리」 탭에 직접 넣고, 판 표기가 필수이며 모든 계산서 머리에 찍힌다. 데이터 범위 밖의 온도는 비슷하게 어림하지 않고 거부한다.
• 저장은 둘이다. 브라우저(localStorage), 그리고 플랫폼에서 열 때(?fb=1)만 부서 공유 저장(Firestore). 단독 실행판은 Firebase 를 아예 부르지 않아 오프라인에서도 돈다.
• 결과. 웹 화면 시험 73건(8d5f243) → 공유 저장 8건을 더해 81건(b756e63). 10/8 에 돌려 본 플랫폼 쪽 검증은 32건, 실패 0.

3 · 기준 × 아이템 · 오픈소스 조사 · 기준 정정 (8/5 14:05~14:49)

14:05에 화면 맨 위에서 기준을 고르게 했고, 14:42에는 아이템(압력용기 · 열교환기 · Condenser · 저장탱크 · 고압가스 저장탱크 · 특정설비)까지 고르게 해서 기준 7종 × 아이템 6종의 조합이 보이는 탭을 정하게 했다. API 650 은 ASME 의 하위가 아니라 따로 둔 기준이다(상압, 두께를 압력이 아니라 액체 무게로 정한다). 위험물안전관리법은 API 650 의 국내 대응이라 같이 넣었다.

14:49에는 남이 만든 것을 조사해 comparison/opensource_survey.md 로 남겼다(GitHub 검색 + 웹 검색, 8/5).

• 국내 기준(에너지공단 · KOSHA · KGS · 위험물법)의 계산 코드는 그날 조사에서 0건이었다. 원문을 구하는 길밖에 없었다.
• ASME 쪽은 부분 구현뿐이다. 그중 하나(ASME-PVDE)는 재료 3,000종 이상을 내장했다고 밝혔는데, 우리는 ASME 인증 업체라 그 데이터를 쓰면 저작권 문제가 인증 관계로 번질 수 있다고 봤다. 계산 논리만 참고하고 데이터는 쓰지 않기로 했다.
• API 650 은 쓸 만한 것이 없었고(검색된 것은 전부 별 0개 · 라이선스 없음), API 620 은 검색 결과가 없었다.
• KGS 기준 전문은 무료로 읽을 수 있지만, 공공데이터 라이선스(KOGL 4유형: 출처표시 · 상업적 이용 금지 · 변경금지)라 데이터 파일 자체를 도구에 넣는 것은 안 된다. 읽고 식을 구현하는 것은 별개로 봤다.

같은 커밋에서 기준 이름을 바로잡았다. 에너지공단 기준을 KS B 6750 으로 알고 화면 틀을 만들었는데, 실제로는 공단 자체 규격 체계(KEA CODE)였고 압력용기 제조는 Section IV(KPM)였다. 웹 · README · 시험에 반영했다.

• 배운 것. 기준 이름을 넘겨짚으면 엉뚱한 식을 찾게 된다. 이름은 원문 표지에서 확인한다.

4 · 원문을 구한 뒤에만 구현 — KPM · API 650 · KGS (8/5 15:19~17:01)

원문을 구한 순서대로 채웠다. 8/5 하루는 8커밋, 13:48~17:01의 3시간 13분 안에 끝났다.

• API 650 변동설계점법(단마다 응력이 가장 큰 높이를 다시 찾아 두께를 구하는 방법)은 표준에 실린 공표 예제(Annex K.1)의 최하단 두께 37.15mm 를 그대로 재현했고, 이 값을 지키는 시험을 못 박았다(앵커).
• KPM 과 AC111 은 식의 뿌리가 같아도 일부러 다른 모듈(kec.py 354줄 · kgs.py 323줄)로 뒀다. 부식여유를 더하는 자리와 압력의 뜻이 달라서, 한 함수로 합치면 조용히 틀린 값이 나온다(5번 기록).
• 못 한 것은 화면에 적었다. KPM 과 AC111 의 외압은 차트를 읽어야 해서, AC111 층성동체는 입력이 11개라 따로 해야 해서 뺐다. 관판 · 평판도 아직 없다. 이 사실을 화면에 「미구현」으로 표시했다. 안 만든 부분을 만든 것처럼 보이게 하지 않는 것이 규칙이었다.

5 · 기준이 다르면 무엇이 다른가 — 쉬운 말

어느 기준을 쓰느냐는 발주처와 검사기관이 정한다. 국내 두 기준은 그 용기가 어느 법(고압가스 안전관리법 · 에너지이용합리화법)의 검사 대상이냐에 따라 갈린다. 아래 셋은 검사기관이 다르다.

먼저 알아 둘 것은 식이 거의 같다는 것이다. KPM 과 AC111 은 같은 계보(JIS B 8265 · KS 계열)의 식을 쓰고, 겉모양이 달라도 풀어 쓰면 ASME UG-27 과 같다(P·Di/(2σaη − 1.2P) = P·R/(σaη − 0.6P)). 그래서 차이는 식이 아니라 식에 들어가는 값과 부수 규정에 있다.

1. 허용응력과 이음효율을 어느 표에서 가져오나. 온도에 따른 재료 강도 값이 기준마다 조금 다르다. ASME 값을 국내 기준 식에 그대로 넣으면 식은 같아도 답이 틀린다.
2. 부식여유(녹으로 깎일 두께)를 더하는 자리. ASME 탭은 반지름에 미리 더하고, KPM 은 식 끝에 따로 더하고(… + α), KGS AC111 의 식에는 아예 없다(별도 취급).
3. 압력의 뜻. pvcalc 가 따른 KPM(「압력용기 제조기술 규격 2002」)은 최고사용압력, AC111 은 설계압력이라 적는다. 다만 사내 색인에 있는 에너지공단의 더 새 기준(열사용기자재 기준 2015, 압력용기 편 30.1.1)은 같은 식의 P 를 설계압력이라 적는다. 판마다 말이 다를 수 있으니 계산 전에 어느 판인지부터 확인한다.
4. 최소 두께. KPM 은 탄소강판 2.5mm 이상이고, ASME UG-16(b) 의 최소는 1.5mm 다(pvcalc 노즐 목 계산에 쓰는 값).
5. 같은 글자의 다른 뜻. KPM 의 α 는 부식여유(mm), AC111 층성동체의 α 는 온도 수정계수다.

같은 용기(안지름 2,000mm · 1.0MPa · 허용응력 138MPa · 부식여유 3mm)를 pvcalc 의 세 모듈에 넣어 봤다(2026-10-08, 허용응력은 설명용으로 셋에 같은 값을 넣었다).

ASME 에서 반지름을 부식여유 없이(1,000mm) 넣으면 10.278로 KPM 과 같아진다. 같은 용기가 입력 한 칸 차이로 0.02mm 달라지고, AC111 은 부식여유를 안 더해서 3mm 얇게 나온다. 이런 차이가 눈에 안 띄게 섞이는 것을 막으려고 기준마다 탭과 모듈을 따로 두고 계산서 머리에 기준 이름을 찍는다. 그리고 ASME 계산 결과를 국내 인허가에 그대로 낼 수 없다고 화면에 적었다.

• 아직 정하지 못한 것: KGS 인허가에서 AC111 자체 표를 쓸지, AC111 §3.2.4 가 조건부로 허용하는 ASME 재료값을 쓸지(comparison/KEC_KGS_notes.md의 남은 확인 사항 1번).

6 · 실물 계산서와 맞춰 보기 (9/1)

손계산이 맞는 것과 현장에서 쓴 계산서와 맞는 것은 다른 이야기다. 9/1 아침부터 오후까지(08:22 · 13:36 커밋) 실물 계산서 두 건과 맞춰 봤다.

• 외국 상용 프로그램 계산서(2022년 제작, 안전인증을 통과한 가스 분리용 압력용기 한 기). 동체 · 경판 · 직관부 5개 부재의 설계 두께가 전부 일치했다(차이 최대 0.006mm, 계산서 인쇄 반올림 0.01mm 이내). 노즐 한 곳의 보강 필요면적 · 확보면적 · 여유율도 일치했다.
• 국내 수계산서(에너지공단 KPM 계보, 자켓 반응기 한 기). 동체 · 경판 2종 · 맨홀 동체 · 맨홀 뚜껑판 5개 부재가 0.01mm 이내로 일치했다. KPM 모듈의 첫 실물 검증이었다.
• 버그를 한 건 잡았다. 노즐 호칭을 글자 "3"으로 주면 표 열쇠(숫자 3.0)와 맞지 않아 한 항목 계산을 조용히 건너뛰고, 필요 두께가 실제보다 약 6% 부풀어 나왔다. 숫자로 바꿔 받게 고쳤다.
• 계산서를 읽어야 보이는 것. 압력에는 부재 위치마다 물 높이(정수두)가 더해져 있다. 설계압 하나만 넣으면 어긋난다. 같은 스테인리스도 허용응력 선이 두 줄이고, 계산서가 어느 줄을 썼는지 맥락마다 다르다. 용기 최대 허용압력으로 보았던 값은 노즐 플랜지 등급이었다.
• 아직 없는 것. 탄소강에 부식여유가 있는 실물 케이스. 다음 프로젝트 계산서에서 구해야 한다. 이 계산서 두 건의 사본은 사내 PC 에 보관하고, 이 페이지에는 숫자를 싣지 않는다(고객 자료).

7 · 데이터시트 → 갈라짐 발견 → 외형도 (9/23~9/25)

데이터시트(9/23 14:33). 계산은 되는데 결과를 양식으로 뽑을 곳이 없었다. 새 탭에서 용기 정보를 넣고 「엑셀로 받기」를 누르면 1장 요약(항목 · 계산 · 근거 조항 · 주요 값 · PASS/FAIL)과 항목별 계산서 전문이 나온다. 원칙 둘을 지켰다. ① 돌린 것만 싣는다(안 돌린 항목을 빈칸으로 두면 검토자가 「이상 없음」으로 읽는다). ② 근거와 판정을 같이 싣는다. 동체와 경판을 계산하고 내보내 보니 3장 · 10KB 엑셀이 나왔다. 이 작업은 플랫폼 저장소에만 들어갔다.

갈라짐 발견(9/25, 22:47 커밋). 다음 기능을 얹기 전에 두 저장소를 대조하다가, 데이터시트가 배포본에만 있고 원본에는 없다는 것을 찾았다. 규칙(원본에서 고치고 복사)과 거꾸로였다. 원본으로 되가져왔고(39c8f41), 화면 시험에서 탭 목록 기대값도 낡아 있었다. 배포본에는 시험 도구(jsdom)가 없어서 이 시험이 거기서는 안 돌고 있었기 때문이다.

외형도(같은 밤 23:10, 23분 뒤). 견적 때 CAD 로 다시 그리던 외형도를 계산 탭의 치수로 뽑았다(web/pvcalc-dxf.js 385줄, 외부 부품 없음).

• 경판 7형식(2:1 타원 · 일반 타원 · 표준 접시 · 일반 접시 · 반구 · 원추 · 평판), 수평(새들)과 수직(스커트) 용기, 노즐 표(외경은 ASME B36.10), 치수선, A3 틀과 표제란. 표제란에는 「견적·사전검토용 — 제작 도면 아님」이 찍힌다.
• 파일은 DXF R12(AC1009)다. 이 규격은 코드페이지 파일이라 한글이 깨지므로 한글을 \U+XXXX 로 적어 파일 전체를 아스키로 만들었다.
• 보이는 입력이나 돌린 계산에서만 가져온다. 숨은 두께 칸의 기본값 12를 그림에 가져오던 것을 적대 검토(일부러 허점을 찾는 검토)에서 잡았다. 11건을 반영했다.
• 외형도는 치수가 틀려도 그림은 그럴듯하게 나온다. 그래서 시험(test_dxf.mjs, 58건)이 경판 깊이 식 · 전체 길이 · 노즐 위치를 숫자로 못 박고, DXF 가 CAD 에서 열리는 꼴인지(짝 맞는 코드/값 줄, EOF, 아스키)를 본다.
• 10/8 에 같은 엔진으로 예시 용기(안지름 2,000 · 길이 6,000 · 2:1 경판 · 노즐 둘)를 뽑아 보니 약 17KB(표제란 글자에 따라 17,101~17,236바이트), 선 50 · 폴리라인 8 · 글 29개, 전부 아스키, 전체 길이 7,028이었다(6,000 + 2×(500+14)).
• 한계. 실제 CAD(AutoCAD · ZWCAD)로 열어 본 기록은 9/25 기억 노트까지 없다(그 뒤 열어 봤는지는 확인 못 함). 첫 사용 때 열어 봐야 한다.

8 · 한 파일 원칙 — 계량 · 작업실 pv_calc (9/26~10/3)

원본 하나. 계산 엔진의 원본은 Pressure Vessel Calctoys 저장소 하나이고, 플랫폼의 tools/pvcalc 는 복사본이다. 10/8 에 두 폴더를 바이트로 비교하니 엔진 · 외형도 · 시험 파일은 전부 같았고, index.html 만 줄바꿈 방식(CRLF/LF)이 달랐다(내용은 같다).

조용히 안 돌던 시험(9/23 발견). 플랫폼 쪽에서 파이썬↔웹 엔진 대조(362벡터)가 통째로 안 돌고 있었다(Cannot set properties of undefined). 저장소 루트 설정("type": "module")이 이 폴더의 .js 를 다른 방식으로 읽게 만들어서 엔진이 빈 값으로 올라왔다. 폴더에 한 줄({"type":"commonjs"})을 두어 고쳤고, 그 뒤 362벡터 · 1,609번 대조가 0 실패로 돈다. 다시 죽으면 전체 시험(npm test)이 걸린다.

읽기 계량(9/26 17:15). 하루 읽기 5만 건을 새벽에 태운 날, 도구 화면 16개를 부모 계량기에 붙였는데 pvcalc 만 규칙 때문에 빠져 있었다. 살펴보니 pvcalc 는 구독이 없고, 플랫폼에서 열릴 때 재료 표 한 건을 한 번 읽는 것이 전부였다. 쉴 연결이 없으니 그 한 건만 부모에 센다. 시험 셋을 더했고, 구독이 생기면 경보가 울린다(화면 시험 201건).

작업실의 AI 가 같은 엔진을 부른다(10/3 12:44). 직원 작업실의 Claude 에게 "이 셸 두께 얼마"를 물으면 식을 기억으로 짜 맞출 수 있었다. 그래서 같은 엔진을 도구로 부르게 했다(pv_calc, 함수 39개 표).

• 설치 파일이 사이트가 내는 같은 엔진 파일을 받아 온다. 저장소에 사본을 만들지 않는다.
• 사람이 정하는 값(허용응력 · 이음효율 · 부식여유 · 개스킷 값 · 풍압 · 지진계수 등)이 빠지면 값을 지어내지 않고 이름을 대며 거절한다. 엔진에는 이음효율 1 · 부식여유 0 같은 기본값이 있어서, 빠져도 조용히 채워 버리기 때문이다.
• 결과 첫 줄에 「예비 계산 — 사람 검토 필요」, 근거 조항, 단위, 엔진 판과 해시(sha256 — 파일 내용으로 만든 지문. 한 글자만 바뀌어도 달라진다)를 붙인다.
• 시험: 파이썬 벡터 362개를 도구 길로 되돌려 엔진과 같은지(1,246건). 엔진에 새 함수가 생기면 표에 없다고 실패한다. 작업실 시험이 46 → 58개가 됐고, 10/8 에 돌려 보니 58개 전부 통과다.

9 · DWSIM — 한글판과 로컬 MCP (8/4~8/5)

DWSIM 은 오픈소스 공정 시뮬레이터다(GPL v3). 저장소 첫 커밋은 8/4 19:53으로 pvcalc 첫 커밋과 1분 53초 차이였다.

• 한글판(19:53). 화면 문자열 4,479개를 85개 파일로 번역했다. 소스 수정은 세 곳이다. 시작할 때 영어로 못박던 것을 풀고, 실행 중 메시지도 한글이 되게 하고, 빌드 뒤 설정의 기본 언어를 바꿨다. 함정 둘이 있었다. Windows 에서는 설정 파일의 언어 값을 읽지 않고, 프로그램에 든 기계번역 부품이 정식 번역을 덮어쓴다(그 부품은 꺼야 한다).
• AI 연동은 「내 PC 에서 도는 MCP 프로그램 하나」로 정했다(22:16). 중앙 서버를 버린 근거는 코드에 있었다. 계산 설정(SolverMode 등)이 프로그램 전체에서 하나만 있는 전역 값이라 동시에 두 요청이 오면 서로 덮어쓴다. 파일을 여는 함수는 서버 쪽 경로를 읽는다. Claude 데스크톱의 MCP 는 내 PC 의 자식 프로세스라 남의 Claude 가 붙을 수 없다. 사람마다 자기 PC 에 하나씩 두면 이 문제가 처음부터 없다.
• 버전 조사(8/5 06:19). 공개 소스는 9.0.5 가 최신이었다(windows 브랜치 HEAD 도 9.0.5.0). MCP 서버와 AI 도우미는 후원자 판(Patreon) 바이너리에만 있었다. 번역 문장은 이미 후원자 판 영어 화면에서 뽑은 것이라, 공식 소스가 열리면 거의 그대로 들어맞는다.
• 후원자 판을 직접 돌려 도구 27개를 확보했다(08:06). 도구 이름은 dwsim_<영역>_<동작> 꼴이고(flowsheet 7 · unitop 5 · graphic 5 · thermo 4 · stream 4 · solve 2), 목록 원본을 mcp/patreon-tools-raw.jsonl 에 남겼다. 한글판(9.0.5)에 이 프로그램을 얹으려던 시도는 v10.1 전용 부품이 필요해서 실패했고, 08:14에 「혼합 불가」로 못 박았다.
• 그날의 검증 시나리오를 10/8 에 다시 돌렸다. 물-에탄올 질량비 50:50, 1기압, NRTL 모델(액체 혼합물의 기액평형을 계산하는 물성 모델). 85°C 에서 액상 58.0% · 증기 42.0%, 증기의 에탄올 48.4mol%(원료 28.1%)가 나와 8/5 기록과 같았다. 같은 시료를 80°C 로 넣으면 전부 액체였다. 8/5 에 적어 둔 함정도 그대로였다. 흐름 양(mass_flow_kg_s)을 시료를 만들 때 넣으면 무시되고(1 kg/s 기본값), 조건을 한 번 더 넣어야 반영된다.

10 · 직원 배포 세트와 검증 리포트 (8/5 08:26~08:39)

• 원클릭 설치(08:26). 설치 파일 하나를 두 번 누르면 ① 인터넷에서 받은 파일의 차단 표시를 푼다(안 풀면 MCP 프로그램이 곧바로 죽는다) ② Claude 데스크톱 설정에 등록한다(기존 설정과 다른 MCP 서버는 그대로 두고 백업 파일을 남긴다) ③ 서버가 실제로 응답하는지 확인한다.
• 용량 줄이기(08:36). 후원자 판 1,665MB 에서 화면용 자산(extenders 660MB · 문서 · 파이썬 패키지 등)을 빼 687MB, 압축해서 239MB 로 만들었다. 뺀 뒤에도 계산 결과가 같은지 압축 해제본에서 다시 확인했고, 설치 파일도 실제로 돌려 통과했다(압축 해제 36초). 설명서 PDF 4종(「먼저 읽어주세요」 안내문 포함)도 같이 묶었다. 배포용 폴더의 zip 은 250,377,571바이트(약 239MiB)다.
• 「오픈소스인데 믿을 수 있나」(08:39). 안내문에 DWSIM 개발팀의 공식 자동 검증 리포트(2026-05-03) 요약을 넣어, 발주처나 상급자 질문에 직원이 바로 인용하게 했다. 표지는 「72 테스트 · 316 검사 전부 통과」인데, 본문을 직접 세어 보니 테스트 71블록 · 검사 315개, 실패 0이었다. 표지와 본문이 1씩 다르다(본문 번호가 T02 부터 시작한다). 안내문 표의 합도 315다. 문헌값(NIST · Gmehling 등)과 견준 7건의 오차는 0.00~1.16%로, 그중 물 포화온도 0.00% · 에탄올-물 공비점 +0.03% · 프로판 증기압 +1.16% · 해수 밀도 +0.08% 네 건을 본문에서 확인했다.
• 안내문의 약속 셋. 계산 결과는 담당 엔지니어가 검증한다(프로그램이 검증됐다는 것과 내가 넣은 조건·모델이 맞다는 것은 다르다) · 사외로 전달하지 않는다(밖으로 넘기면 GPL 의 소스 공개 의무가 생긴다) · 회사 Claude 계정으로만 쓴다.
• 확인 못 한 것. 후원자 판 프로그램을 사내 직원에게 나눠도 되는지의 약관 원문은 확인하지 못했다(안내문은 GPL v3 로 사내 사용은 자유라고 적었다). 저자에게 v10 소스를 문의하는 메일은 초안(미발송)으로 남아 있고, 그 뒤 발송했는지는 확인하지 못했다.

💡 설명

• ASME VIII-1: 미국 기계학회의 압력용기 규격(제8편 제1부). 회사는 ASME 인증 업체다.
• KEA CODE · KPM: 한국에너지공단의 자체 규격 체계. 그중 압력용기 제조가 Section IV(KPM)다.
• KGS AC111: 한국가스안전공사의 「고압가스용 저장탱크 및 압력용기 제조 기준」. 무료로 읽을 수 있다.
• 허용응력: 재료가 견딜 수 있다고 정한 응력의 한도. 온도가 오르면 낮아지고, 기준마다 표가 다르며 저작권 자료라 도구에 담지 않는다.
• 이음효율: 용접 이음부가 모재만큼 튼튼하다고 보는 정도(1이 최대). 두께 계산식에 곱해진다.
• 부식여유(CA): 녹이나 침식으로 깎일 것을 미리 더해 두는 두께.
• 정수두: 용기 안 액체의 무게 때문에 아래쪽일수록 더 걸리는 압력.
• 앵커 테스트: 표준에 실린 공표 숫자를 재현하는지로 식이 맞는지 판정하는 시험.
• 벡터 대조: 같은 입력 한 벌을 파이썬과 웹 엔진에 넣어 같은 값이 나오는지 기계로 비교하는 것.
• DXF R12: CAD 가 읽는 도면 교환 파일 형식의 오래된 판(AutoCAD R12 때 판). 오래돼서 거의 모든 CAD 가 연다.
• MCP: AI 가 바깥 도구를 부르는 약속. 여기서는 Claude 가 DWSIM 을 부르는 통로다.
• GPL v3: 소스를 쓰고 고칠 자유를 주되, 남에게 넘길 때 소스를 공개하라는 오픈소스 약속.

함정과 배운 것

• 「값은 나오는데 틀린 답」이 제일 위험하다. 원문이 없으면 구현하지 않고, 부분 구현은 화면에 「미구현」으로 적고, 재료값은 사람이 넣게 한다.
• 남의 코드는 공표값 앵커로 확인한다. 참고한 오픈소스에서 오류 세 건이 나왔다.
• 문서의 숫자는 뒤처진다. pvcalc README 한 파일에 엔진 대조 「362 벡터」와 「199 벡터 · 1081 비교」가 같이 있고, 화면 시험은 문서 185건 · 실제 201건이며, 손계산 대조는 문서와 커밋 메시지가 225건인데 직접 세면 226줄이다(원인은 확인 못 함). DWSIM 리포트는 표지 72/316 · 본문 71/315다. 숫자는 코드와 출력에서 센다.
• 같은 코드가 두 곳이면 갈라진다. 원본 ↔ 배포본이 이틀 동안 갈라졌고, 시험이 한쪽에서만 돌아서 못 잡았다. 복사할 때는 양쪽 시험을 돌린다.
• 시험이 통째로 안 도는 것은 소리가 안 난다. 플랫폼의 엔진 대조가 한동안 안 돌았다. 시험이 「돌았다」는 사실도 확인해야 한다.
• 같은 글자가 다른 뜻이다. 기준마다 α, P 의 뜻이 다르고, 같은 에너지공단 기준도 판(2002 규격 · 2015 고시)에 따라 P 를 다르게 적는다. 합치면 조용히 틀린다.
• 외형도는 틀려도 그럴듯하다. 그림은 눈으로 검증이 안 되므로 치수를 숫자로 못 박는다.
• 파이썬 한글 출력(Windows). 검증 스크립트를 한글 환경 기본 설정으로 돌리면 출력 단계에서 죽는다. PYTHONIOENCODING=utf-8 을 붙인다.
• DWSIM 설치. 인터넷에서 받은 파일의 차단을 풀지 않으면 MCP 프로그램이 곧바로 죽는다. 후원자 판 부품은 한글판(9.0.5)에 섞을 수 없다. API 응답과 오류 메시지는 영어다(프로그램이 영어로 못박았다). 한글은 AI 쪽에서 처리한다.

출처

커밋(pvcalc 원본): dc116c1 · 49a9fb4 · 08538ec · 59d1830 · 75d83eb · 8d5f243 · b756e63 · f05b18b · 659f49a · bbedbe6 · 311e2e5 · 6fa64c2 · 94d2936 · 78e1554 · c853424 · 39c8f41 · 1840dc8 · e14fb1d. 커밋(플랫폼): 7626068 · 06fe4ad · f3884a3 · 340ac0c · 3764d3a. 커밋(DWSIM): 1821b73 · 3f47744 · 57f8fd2 · eb5fa61 · 5fef87a · 4a05910 · 399c086 · 62d4432.
문서: pvcalc README.md · CLAUDE.md · comparison/opensource_survey.md · comparison/KEC_KGS_notes.md · comparison/ 의 실물 계산서 대조 문서, DWSIM CLAUDE.md · mcp/dist/README.md · 직원 안내문 「먼저 읽어주세요」 · 공식 검증 리포트.
기억 노트: pvcalc-workstream · pressure-vessel-codes. 글쓴이 crazy4eu(cwkim83). 숫자마다 근거는 checks.md.

← 06 두뇌 관문 — omniroute · 9router · 사용량 절감 · 08 사내 앱 — 차량관리와 ERP 시안 →