1.1 역할 정의: 코드는 AI가 쓰고, 판정은 사람이 한다

화학공학자의 하루에는 계산이 흐른다. 단위를 환산하고, 물성을 조회하고, 수지식을 풀고, 실험 데이터를 피팅한다. 계산 하나하나는 어렵지 않지만 반복되고, 반복되는 계산은 실수를 부른다. 도구를 만들 줄 아는 공학자는 반복을 프로그램으로 바꾼다.

지금까지 도구 제작의 병목은 프로그래밍 문법이었다. 대형 언어 모델의 등장이 그 병목을 옮겼다. 자연어로 의도를 말하면 AI가 코드를 작성하고, 사람이 그 코드를 읽고 검증하는 작업 방식을 바이브코딩(vibe coding)이라 한다. 문법을 몰라도 코드가 생긴다. 그렇다면 새 병목은 무엇인가. 생긴 코드가 옳은지 판정하는 능력이다.

이 수업은 그 판정 능력을 역할 분담 형식으로 정의한다. AI가 코드를 쓰고, 학생은 ① 문제 분해 ② 생성 코드 읽기·설명 ③ 화학공학적 검증을 책임진다. 이를 이 수업의 역할 계약이라 한다. AI 코드 어시스턴트를 전제로 프로그래밍 입문 교육을 재설계한 미국 UCSD의 CS1-LLM 모델과 같은 노선이다. 코드를 짜는 기술이 아니라 코드를 부리는 기술을 배워야 한다.

이 계약에는 벌칙 조항이 있다. 자신이 제출한 코드를 설명하지 못하면 해당 이해 점수는 0점이다. 최종 시험의 구술 방어에서는 지목 질문 3개 중 2개 이상 설명에 실패하면 코드 이해 차원 전체가 0점으로 처리된다. 돌아가는 코드와 이해한 코드는 다르며, 이 수업이 점수를 주는 쪽은 후자다.

검증에 "화학공학적"이라는 수식어가 붙는 이유가 있다. 컴퓨터는 문법 오류를 잡아 주지만, 단위가 뒤집힌 계산과 날조된 물성값은 문법적으로 완벽한 코드 안에서 조용히 살아남는다. 그것을 잡는 것은 전공 지식이다. 단위가 맞는가, 알려진 값과 맞는가, 극한에서 물리적으로 말이 되는가. 이 세 질문을 검증 루틴 3종이라 하며 3장에서 정식으로 도입한다. 이 장에서는 형식을 눈에 익히는 것으로 충분하다.

1.2 AI 협업 사이클: 여섯 단계 한 바퀴

역할 계약을 매주 실행 가능한 절차로 서술한 것이 AI 협업 사이클이다. 이 책의 모든 예제와 실습은 이 여섯 단계 위에서 움직이며, 각 장은 지금 어느 단계를 훈련 중인지 표시한다.

위 사이클과 함께 이 책의 형식을 말하고 넘어가고자 한다. AI와의 대화는 코드 리스팅의 새로운 형식이므로, 세 단으로 고정해 싣는다. [프롬프트]는 사람이 쓴 요청을 다듬지 않고 그대로, [생성 코드]는 AI가 낸 코드를 점선 테두리로 (점선은 "아직 검증 전"이라는 뜻이다) , [검증]은 사람이 확인한 것과 고친 것을 담는다.

말로만 들은 사이클은 아직 손에 잡히지 않는다. 한 바퀴를 실제로 돌아 보자.

R = 8.314  # 기체상수 [Pa·m3/(mol·K)] — 출처: NIST CODATA

def molar_volume(T, P):
    """이상기체 몰 부피를 계산한다.

    T: 절대온도 [K]
    P: 압력 [Pa]
    반환: 몰 부피 [m3/mol]
    """
    if T <= 0:
        raise ValueError("절대온도는 0 K보다 커야 한다")
    return R * T / P

# 0 °C, 1 bar에서 확인 실행
V = molar_volume(273.15, 1.0e5)  # [K], [Pa]
print(f"몰 부피 = {V:.5f} m3/mol = {V * 1000:.1f} L/mol")

1.3 이 수업의 AI 활용 규칙

AI 사용 규칙은 평가마다 다르다. 금지·필수·허용의 세 종류로 나뉘며, 이를 AI 3-lane 규칙이라 한다. 표 1-1이 강의에서 AI를 활용하게 될 전체 구조다.

최종 시험이 AI 필수인데 시험1은 왜 AI를 금지하는가. 방향이 반대라서가 아니라 재는 것이 다르기 때문이다. 시험1은 AI가 꺼졌을 때 머리에 남는 능력(생성 코드의 출력 예측, 코드를 한국어로 설명하기(EiPE라 부르는 문항 유형으로, 5장에서 훈련한다), AI가 낸 오답의 채점·교정, 화공 계산의 의사코드 설계)을 따로 검증한다. AI 없이는 아무것도 못 하는 사람이 좋은 점수를 받긴 힘들다.

시험2와 최종 시험에서 AI 사용이 필수인 이유도 같은 논리다. 이 두 시험이 재는 것은 AI와 함께 제한 시간 안에 내는 실전 성과이므로, AI 없이 치르는 것은 측정 대상 밖의 행동이다. 과제에서의 AI활용은 허용이다. 위키 기록과 서브프로젝트에서 AI를 어떻게 썼는지가 오히려 학습의 일부가 될 것이다.

세 경우 모두에 공통 의무가 하나 있다. 모든 평가물에는 AI 사용내역을 첨부한다. 무엇을 물었고, 무엇을 받았고, 무엇을 고쳤는지를 적는다. (미첨부는 부정행위로 처리된다.) 아울러 프롬프트에 개인정보를 넣지 않는 것이 1주차 역할 계약에 포함된 규칙이다. 실습의 AI 접속은 교수가 운영하는 게이트웨이를 거치며, 데이터 흐름은 강의계획서에 고지되어 있다.

1.4 LLM은 무엇을 하는 기계인가

AI를 부리려면 내부를 전부 알 필요는 없다. 그러나 오답이 만들어지는 원리는 알아야 한다. 브레이크가 왜 밀리는지 모르는 운전자는 밀리는 순간 대응하지 못한다. 이 절에 필요한 개념은 셋뿐이다. 다음 토큰 예측, 확률적 출력, 그럴듯한 오답이다.

1.4.1 하찮은 예제: 열아홉 줄짜리 문장 생성기

출발점은 LLM이 아니라 작은 파이썬 프로그램이다. 아직 코드를 읽는 법을 배우지 않았어도 좋다. 지금은 실행하고 출력을 관찰하는 것으로 충분하며, 이 코드를 해부하는 법은 5장에서 배운다.

import random

# 아주 작은 말뭉치 — 문장 세 개가 전부다
text = ("증기압 은 온도 에 따라 커진다 . "
        "증기압 은 물질 마다 다르다 . "
        "온도 가 오르면 증기압 이 커진다 .")
words = text.split()

# 각 단어 뒤에 실제로 나왔던 단어를 전부 기록한다
table = {}
for w, nxt in zip(words, words[1:]):
    table.setdefault(w, []).append(nxt)

word = "증기압"          # 시작 단어
line = [word]
for _ in range(5):       # 다음 단어를 다섯 번 이어 붙인다
    word = random.choice(table[word])  # 자주 나온 단어일수록 잘 뽑힌다
    line.append(word)
print(" ".join(line))

실행할 때마다 다른 문장이 나온다. 어떤 실행에서는 「증기압 은 물질 마다 다르다 .」처럼 말이 되는 문장이, 다른 실행에서는 「증기압 이 커진다 . 온도 가」처럼 도중에 끊긴 문장이 나온다. 흥미로운 점은 이것이다. 이 프로그램은 증기압이 무엇인지 모른다. 아는 것은 "어떤 단어 뒤에 어떤 단어가 왔는가"라는 기록뿐인데도 출력은 제법 그럴듯하다.

1.4.2 다음 토큰 예측과 확률적 출력

이 장난감이 하는 일을 한 문장으로 줄이면 "지금까지의 단어열을 보고, 기록에 근거해 다음 단어를 확률적으로 뽑는다"가 된다. 사람이 쓴 방대한 텍스트로 이 일을 훨씬 정교하게 하도록 훈련된 프로그램을 대형 언어 모델(large language model, LLM)이라 한다. LLM이 텍스트를 다루는 최소 단위 조각을 토큰(token)이라 하며, 단어보다 잘게 쪼개지는 경우가 많다. LLM은 직전 한 단어가 아니라 수천 토큰의 문맥 전체를 반영하고, 빈도표 대신 거대한 수치 모델로 다음 토큰의 확률을 계산한다. 규모의 차이는 압도적이지만 산출의 본성은 같다. 다음 토큰을 예측해 이어 붙인다.

코드 1-2의 random.choice가 하는 일을 LLM도 한다. 후보 토큰마다 확률을 매긴 뒤 그 분포에서 하나를 뽑는다. 그래서 같은 프롬프트를 두 번 보내면 다른 답이 올 수 있다. 고장이 아니라 설계다.

실무적으로 생각해볼 것은 두 가지다. 재생성은 공짜 재시도가 아니라 새로운 검증 대상이다. 어제 좋은 코드를 생성한 프롬프트가 오늘 다른 코드를 생성한다. 그리고 "한 번 확인했다"는 "늘 옳다"의 근거가 되지 못하므로, 확인 절차 자체를 테스트 코드로 남겨 반복 실행해야 한다. 이 습관은 2장부터 보도록 하자.

1.4.3 그럴듯한 오답

LLM이 사실이 아닌 내용을 사실처럼 자신 있게 생성하는 현상을 환각(hallucination)이라 한다. 이 이름은 오해를 부른다. 환각은 모델이 가끔 빠지는 비정상 상태가 아니다. 모델은 답의 진위를 어디에서도 조회하지 않으며, 맞는 답과 틀린 답이 같은 기제(다음 토큰 예측)로 만들어진다. 코드 1-2가 증기압의 뜻을 모른 채 증기압 문장을 만들었음을 떠올려 보자.

따라서 출력이 유창하다는 사실은 내용이 옳다는 증거가 전혀 아니다. 화학공학 데이터에서 환각은 물성 날조로 나타난다. 존재하지 않는 Antoine 상수, 출처 없는 끓는점, 그럴듯한 임계 물성. 3장에서 실제 사례를 해부하고, 5주차 실습에서는 AI가 날조한 Antoine 상수를 직접 잡아낸다.

1.5 15주의 지도

이 수업은 네 국면으로 진행된다. 1~4주는 훅이다. 강의노트 정리기·플래시카드 생성기·스터디 플래너로 자신의 학습 OS를 조립한다. 시간제한이 없고, 결과는 등수 없이 통과/재도전 2단계로만 처리되는 저부담 구간이다. 5~7주는 근육이다. 코드 읽기·검증 훈련과 첫 화공 도구를 다루고 시험1(AI 금지 지필)을 치른다. 8~13주는 사다리다. 화공 도구를 매주 하나씩 실기 형식으로 만들고 시험을 치른다. 13~15주는 완성이다. 서브프로젝트 발표와 최종 실습 실기, 그리고 구술 방어이다.

도구 사다리는 아홉 계단이다. ① 강의노트 정리기, ② 플래시카드 생성기, ③ 스터디 플래너, ④ 단위환산 + 물성 조회기, ⑤ Antoine 증기압 계산기, ⑥ 이성분계 T-xy 다이어그램, ⑦ 물질수지 solver, ⑧ 배관 압력강하 계산기, ⑨ 공정 데이터 대시보드. 앞의 셋은 오늘 밤 다른 과목 공부에 바로 쓰는 도구이고, 뒤의 여섯은 화공양론·유체역학과 나란히 가는 전공 도구다. 도구는 1회성 과제가 아니라 재사용 자산이다. 9장의 T-xy 다이어그램은 8장의 증기압 함수를 그대로 가져다 쓰고, 서브프로젝트는 본인 산출물 2개 이상의 재사용을 요건으로 한다.

매주 실습은 최종 시험의 축소판이다. 5주차부터 타이머가 붙고, 제한 시간은 30분에서 45·60·75·90분을 거쳐 최종 시험의 120분까지 점증한다. 같은 형식을 15번 연습한 상태로 시험장에 들어가는 것이 이 설계의 목적이다.

최종 실습시험의 루브릭은 1주차인 지금 전체가 공개된다. 작동성 14점, 코드 이해 10점, 프롬프트 전략 8점, 발표 8점. 작동성에는 검증 증빙(단위·대조값·극한값의 README 기록)이 필수 항목으로 들어 있고, 프롬프트 전략은 전체 로그로 채점된다. 전문은 부록 E에 있다.

마지막 조각이 위키다. 15주 동안 배운 것·틀린 것·만든 것을 마크다운으로 누적하는 개인 지식 저장소를 이 수업에서는 위키(위키)라 한다. 노트에는 성장단계 태그 #seed → #growing → #evergreen을 붙이고, 5·10·15주의 마일스톤 3회에 걸쳐 각 2점씩 채점된다. 채점 기준은 누적성(주당 의미 있는 커밋 1개 이상, 몰아치기는 커밋 이력에서 드러나 감점된다), 개인화 깊이, 활용도다. 매 실습의 마지막 15분은 위키 시간이며, 그날 만든 것·막힌 것·틀린 것 1건을 기록해야 퇴실한다. 2~4주에 만드는 도구들이 위키를 직접 읽고 쓰므로, 도구를 쓸수록 위키가 자라는 구조다.

2.1 문제 분해: 일을 함수 크기로 쪼갠다

흩어진 강의노트를 위키 노트로 바꾸는 일을 통째로 보면 막막하다. 그런데 종이에 손으로 절차를 적어 보면 다섯 조각으로 갈라진다. ① 붙여넣은 텍스트를 읽어 들인다. ② 제목이 될 문장을 찾는다. ③ 본문을 마크다운 형식으로 바꾼다. ④ 태그를 붙인다. ⑤ 파일로 저장한다. 일부러 하찮아 보일 만큼 잘게 적었지만, 이 다섯 줄이 이번 주에 만들 프로그램의 설계도가 된다.

이렇게 큰 문제를 각각 따로 해결하고 따로 확인할 수 있는 작은 일들로 나누는 것을 문제 분해(problem decomposition)라 한다. 좋은 프로그램은 개별적으로 시험해 볼 수 있는 작은 부품들의 조립품이며, 부품 하나를 만들 때마다 곧바로 실행해 확인하는 것이 오류를 빨리 찾는 길이다. 위의 다섯 조각이 각각 프로그램의 부품 하나, 즉 함수 하나가 된다.

분해의 단위를 함수 크기로 잡는 이유는 확인 가능성 때문이다. "노트를 정리해 줘"라는 요청의 결과는 옳은지 그른지 판정할 방법이 마땅치 않다. 반면 "이 텍스트에서 제목이 될 첫 문장을 골라 줘"의 결과는 눈으로 1초 만에 판정된다. AI에게 시키는 일의 크기는 사람이 검증할 수 있는 크기여야 한다. 1장에서 정한 역할 분담(코드는 AI, 검증은 학생)이 여기서 처음 작동한다.

이 역할 분담을 작업 절차로 펼친 것이 1장에서 설명한 AI 협업 사이클이다. 이 블록은 이 교재의 고정 장치로, 15장까지 모든 예제와 실습에 같은 모습으로 반복된다.

이 순서는 AI를 전제로 프로그래밍 입문을 재설계한 대학 수업들(UCSD의 CS1-LLM 등)이 채택한 "분해 → 프롬프트 → 코드 읽기 → 테스트" 사이클에, 화학공학적 검증 단계 ⑥을 더한 것이다. 이번 장에서는 ①~⑤를 연습하고, ⑥은 3장에서 다룬다.

분해표에는 실용적인 쓸모가 하나 더 있다. 표의 각 행이 그대로 프롬프트 하나가 되므로, 분해표를 완성한 순간 AI에게 보낼 요청 목록도 완성된다. 이번 주 실습에서는 이 표를 README에 먼저 적고 나서 코드 생성을 시작하는데, 이 순서는 최종 시험에서도 같다. 2시간 실기에서 맨 먼저 할 일이 바로 문제를 분해표로 옮기는 것이다.

2.2 함수·변수·자료형: 생성 코드를 읽기 위한 최소 문법

사이클의 4단계 "생성 코드 읽기"를 하려면 문법이 필요하다. 다만 파이썬 전체가 아니라, AI가 낸 코드에 반드시 등장하는 세 가지(변수, 자료형, 함수)만 있으면 이번 주 코드는 전부 읽힌다.

2.2.1 변수와 값

값을 가리키는 이름을 변수(variable)라 한다. 이름에 값을 붙이는 문장이 할당이다.

note_title = "화공양론 3장 물질수지"   # 문자열 — 노트 제목
page_count = 17                         # 정수 — 노트 분량 [쪽]
water_bp = 100.0                        # 실수 — 물의 정상 끓는점 [°C]

세 줄을 하나씩 되짚어 보자. 첫 줄은 따옴표로 감싼 글자들, 즉 문자열(string)을 note_title이라는 이름에 할당한다. 둘째 줄은 정수 17을, 셋째 줄은 실수 100.0을 각각의 이름에 붙인다. 물리량을 담는 변수에는 이 교재 전체에서 단위를 주석으로 명기한다. 나중에 단위 검증의 대조 대상이 코드 안에 있어야 하기 때문이다.

2.2.2 자료형: 값에는 종류가 있다

값이 속한 종류를 자료형(data type)이라 한다. 위에서 만난 세 가지가 파이썬의 기본 자료형으로, 문자열은 str, 정수는 int, 소수점이 있는 수는 float에 속한다. 어느 형인지 헷갈리면 type()으로 물어보면 된다.

함정은 숫자처럼 보이는 문자열이다. "17"은 따옴표 안에 있으므로 수가 아니라 문자열이고, 계산에 쓰려면 변환해야 한다. 그리고 이 변환은 단위 표기가 섞이는 순간 실패한다. 실제로 실행해 보자.

>>> type("17")
<class 'str'>
>>> float("25.0")
25.0
>>> float("25.0 °C")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '25.0 °C'

마지막 에러는 이번 주 실습에서 실제로 만나게 된다. 강의노트는 문자열이고, 그 안의 "25.0 °C" 같은 표기는 사람 눈에만 숫자다. 에러 메시지의 마지막 줄에 원인이 그대로 적혀 있으므로, 에러가 나면 이 줄부터 읽는 습관을 들이자.

2.2.3 함수: 이름 붙인 작업 한 덩어리

문장 여러 개를 묶어 이름을 붙인 것을 함수(function)라 한다. §2.1의 분해표에서 쪼갠 "일 하나"가 코드에서는 함수 하나로 나타난다. 정의와 호출을 한 번에 보자.

def celsius_to_kelvin(temp_c):      # temp_c: 매개변수 [°C]
    """섭씨 온도를 켈빈 온도로 변환한다."""
    temp_k = temp_c + 273.15        # 식 (2.1) [K]
    return temp_k                   # 반환값 [K]

t_boil = celsius_to_kelvin(100.0)   # 100.0: 인자 [°C]
print(t_boil)                       # 373.15가 출력된다

여기서 쓴 변환식은 켈빈 온도와 섭씨 온도의 정의 관계다.

T_K = T_C + 273.15 (2.1)

T_K는 켈빈 온도[K], T_C는 섭씨 온도[°C]이고, 273.15는 두 눈금 사이의 정의된 오프셋이다. 코드로 돌아가면, def 줄의 괄호 안 이름 temp_c를 매개변수(parameter)라 하고, 호출할 때 괄호에 넣어 주는 값 100.0을 인자(argument)라 한다. 함수가 호출되면 인자가 매개변수라는 변수에 할당되고, 함수 몸통이 실행된 뒤 return 뒤의 값, 즉 반환값(return value)이 호출한 자리로 돌아온다. # 뒤의 설명글은 주석(comment)으로, 실행에는 관여하지 않지만 코드를 읽는 사람에게 단위와 의도를 알려 준다.

return이 없는 함수는 어떻게 될까. 화면에 print로 출력만 하는 함수도 문법상 유효하지만, 그 결과를 변수에 담으면 None이라는 특별한 값이 들어온다. None은 "반환값이 없음"을 나타내는 고유한 자료형의 값으로, 문자열 'None'과는 다르다. 출력된 숫자는 눈에만 보일 뿐 다음 계산에 쓸 수 없으므로, 계산 함수를 요청할 때는 반드시 "값을 반환하게" 요구해야 한다. 이것이 §2.3 프롬프트 4요소 중 '출력'이 존재하는 이유다.

2.3 함수 단위 프롬프트: 한 번에 부품 하나

문법을 갖췄으니 사이클의 3단계로 간다. 프롬프트의 품질은 결과 코드의 품질을 직접 결정하는데, 초보자의 프롬프트가 실패하는 가장 흔한 형태는 "너무 큰 요청"이다. 실제로 어떻게 실패하는지 먼저 보자.

print("=== 만능 온도 변환기 ===")
mode = input("1) C→F  2) F→C  3) C→K  4) K→C 선택: ")
if mode == "1":
    temp_f = float(input("섭씨 온도: ")) * 9 / 5 + 32   # [°F]
    print("화씨:", temp_f)
# … (이후 40여 줄: 화씨·랭킨 분기, 메뉴 반복 루프 생략)

고치는 방법은 요청을 분해표의 한 칸 크기로 줄이고, 네 가지를 명시하는 것이다. 무엇이 들어가고(입력), 무엇이 나오고(출력), 단위는 무엇이며(단위), 이상한 입력에는 어떻게 반응할지(예외). 이 입력·출력·단위·예외 4요소가 이 교재의 표준 프롬프트 패턴이다.

def celsius_to_kelvin(temp_c):
    """섭씨 온도[°C]를 켈빈 온도[K]로 변환한다."""
    ABS_ZERO_C = -273.15    # 절대영도 [°C], 정의값
    if temp_c < ABS_ZERO_C:
        raise ValueError("절대영도보다 낮은 온도: " + str(temp_c) + " °C")
    return temp_c + 273.15  # 켈빈 온도 [K]

2.4 테스트: 생성 코드를 믿지 않는 방법

코드 2-5는 그럴듯하다. 그러나 "그럴듯하다"는 느낌만으로는 판정이 되지 않는다. 사이클의 5단계는 답을 이미 아는 입력을 넣어 기계가 판정하게 만드는 것이고, 파이썬에서 가장 짧은 도구가 assert 문이다. assert 조건, "메시지"는 조건이 참이면 조용히 지나가고, 거짓이면 메시지와 함께 프로그램을 멈춘다.

# test_convert.py — 답을 아는 입력으로 생성 함수를 검증한다
from convert import celsius_to_kelvin

assert celsius_to_kelvin(0.0) == 273.15, "물의 어는점 대조 실패"      # [K]
assert celsius_to_kelvin(100.0) == 373.15, "물의 끓는점 대조 실패"    # [K]
assert celsius_to_kelvin(-273.15) == 0.0, "절대영도 대조 실패"        # [K]
print("테스트 3개 통과")

세 케이스의 선택에 논리가 있다. 어는점과 끓는점은 일반화학에서 이미 아는 대조값이고, 절대영도는 함수가 허용하는 가장 낮은 극한값이다. 테스트 케이스는 대개 아는 값과 극한값 두 곳에서 나온다.

순서도 중요하다. 예제 2.3-1의 풀이 전략에서 판정 기준(0 °C → 273.15 K)을 코드를 받기 전에 정해 둔 것을 눈여겨보라. 생성 코드를 먼저 보고 나서 기준을 정하면, 눈앞의 출력에 맞춰 기준이 끌려가는 일이 생긴다. 판정 기준은 AI가 아니라 사람이 정해야 하고, 그 형식이 바로 미리 적어 둔 테스트다.

이 테스트가 실제로 무엇을 잡아내는지 보자. 프롬프트에서 조건을 흐리면 AI는 자주 다음과 같은 코드를 내놓는다.

0.15 K는 사소해 보이지만, 증기압처럼 온도에 민감한 물성 계산의 입력으로 들어가면 오차가 증폭된다. 8장에서 이 함수를 실제로 재사용할 때 다시 확인하게 된다.

2.5 마크다운과 저장소 규율: .gitignore와 .env

이번 주 도구의 출력 형식이 마크다운이므로, 만들기 전에 형식부터 읽을 줄 알아야 한다. 몇 개의 기호만으로 문서 구조를 표시하는 텍스트 표기법을 마크다운(markdown)이라 한다. 위키의 모든 노트가 이 형식이고, 이 교재의 README·기록 과제도 전부 마크다운으로 쓴다.

정리기가 만들어 낼 노트 한 장의 목표 형태는 다음과 같다. 이 구조(핵심 정리 / 내가 틀렸던 것 / 타 과목 연결)는 위키 채점 기준의 3항과 같다.

# 물질수지 기초
#seed
## 오늘 배운 것
- **물질수지**: 축적 = 입력 - 출력 (반응이 없을 때)
- 정상상태에서는 축적 항이 0이다.
## 내가 틀렸던 것
- bypass 흐름을 recycle로 착각했다.
## 연결
- [[화공양론]] 3장 · [[유체역학]] 질량 보존

저장 규율이 하나 남았다. 1주차에 발급받은 게이트웨이 가상 키는 비밀값이다. 키를 코드나 노트에 적은 채 커밋하면 저장소 이력에 남고, 이력에 남은 비밀은 나중에 지우기가 어렵다. 그래서 비밀값은 .env라는 별도 파일에 두고, 그 파일 자체를 Git이 추적하지 못하게 막는다. 추적 제외 목록이 .gitignore 파일이다.

# .gitignore
.env             # 가상 키가 든 파일 — 커밋 금지
__pycache__/     # 파이썬이 만드는 캐시 폴더
*.pyc

커밋 전에 확인하는 습관 하나면 충분하다. git status 출력에 .env가 보이면 .gitignore가 작동하지 않는 것이니 멈추고 원인을 찾는다. 스타터 repo에는 이 .gitignore가 이미 들어 있다. 실습 마지막 단계에서 직접 확인한다.

def read_pasted_text():
    """붙여넣은 강의노트 텍스트를 문단 리스트로 돌려준다."""

def save_note(filename, markdown_text):
    """완성된 마크다운 노트를 wiki/ 폴더에 저장한다."""

3.1 유창함은 옳음이 아니다: 환각의 세 얼굴

1장에서 LLM을 최소한으로 해부하며 세 가지를 확인했다. LLM은 다음 토큰을 확률적으로 예측해 이어 붙이고, 그래서 같은 프롬프트에도 다른 답을 내며, 맞는 답과 틀린 답이 같은 기제로 만들어진다. 마지막 사실이 이 장의 출발점이다. 출력이 유창하다는 것은 "그럴듯한 토큰을 잘 이었다"는 뜻일 뿐, 내용이 옳다는 증거가 아니다.

근거 없이 그럴듯하게 지어낸 출력을 환각(hallucination)이라 한다. 환각은 LLM의 고장이 아니라 정상 작동의 부산물이다. 모델은 "이 문맥 다음에 올 법한 문장"을 만들 뿐, 그 문장이 세계와 맞는지는 검사하지 않는다. 도입부의 카드가 정확히 그랬다. "물의 임계온도는 350 °C이다"는 물의 임계온도에 대한 문장으로서 형식이 완벽했고, 그래서 모델은 그것을 내놓았다. 값이 맞는지는 모델의 관심사가 아니었다.

화학공학 데이터에서 환각은 세 가지 얼굴로 나타난다. 이 셋을 구분해 두어야 어떤 검증이 어떤 오류를 잡는지 보인다.

3.1.1 물성 날조: 없는 값을 자신 있게 만든다

첫째 얼굴은 물성 날조다. 존재하지 않는 물성 상수, 출처 없는 끓는점, 그럴듯한 임계 물성을 모델이 지어낸다. 도입부 카드의 "350 °C"가 여기에 해당한다. 위험한 점은 날조된 값이 터무니없어 보이지 않는다는 것이다. 물의 임계온도가 3500 °C였다면 누구나 의심하겠지만, 350 °C는 참값 374 °C와 그리 멀지 않아 눈으로는 걸러지지 않는다. 그럴듯한 크기의 오답이 특히 걸러 내기 어렵다.

3.1.2 단위 오류: 개념은 맞고 단위가 틀린다

둘째 얼굴은 단위 오류다. 이 경우 모델은 옳은 개념을 쓰지만 단위·로그 밑·환산에서 미끄러진다. 압력을 mmHg로 계산해 놓고 bar라 이름 붙이거나, 상용로그(log₁₀)로 정의된 식을 자연로그(ln)로 계산하는 식이다. 결과는 자릿수가 통째로 어긋나기도 하지만, 때로는 크기가 비슷해 물성 날조보다 더 잘 숨는다. 이 얼굴을 잡는 검증이 뒤에 나올 단위 체크다.

3.1.3 자신만만한 오답: 어조는 정답 여부와 무관하다

셋째 얼굴은 앞의 둘을 더 위험하게 만드는 성질이다. LLM은 틀린 답도 맞는 답과 똑같이 확신에 찬 문장으로 내놓는다. 출력의 어조는 정답 여부와 아무 상관이 없다. 도입부 카드에는 "아마도"나 "확인 필요" 같은 표시가 없었고, 5주차에 만날 사례에서는 AI가 날조한 Antoine 상수 뒤에 "출처: NIST WebBook"이라는 가짜 출처까지 붙인다. 사람이라면 모르는 것 앞에서 머뭇거리지만, 모델의 문장은 아는 것과 모르는 것을 같은 톤으로 서술한다. 그래서 "AI가 확신하는가"는 판정 기준으로 삼기 어렵다. 판정은 어조가 아니라 대조에서 나와야 한다.

3.2 검증 루틴 3종: 역할 분담을 절차로

1주차의 역할 분담은 짧았다. 코드는 AI가 쓰고, 검증은 학생이 한다. 그런데 "검증한다"는 말은 그 자체로는 절차가 아니다. 무엇을, 어떤 순서로 확인하는지 정해져 있지 않으면 검증은 "한 번 훑어봤다"로 미끄러진다. 그래서 이 수업은 검증을 세 개의 고정된 질문으로 못 박는다. 단위가 맞는가, 아는 값과 맞는가, 극한에서 말이 되는가. 이 셋을 검증 루틴 3종이라 하고, 15장까지 모든 예제와 실습에서 같은 순서·같은 형식으로 반복한다.

⑤ 테스트와 ⑥ 화공 검증이 어떻게 다른지부터 갈라 두자. 테스트는 코드가 "내가 정한 대로 동작하는가"를 묻고, 화공 검증은 "그 대로가 물리적으로 옳은가"를 묻는다. 2장의 assert는 273.15를 기대값으로 넣어 273을 잡아냈지만, 기대값 자체를 273으로 잘못 정했다면 테스트는 조용히 통과한다. 테스트가 통과한 뒤에도 검증 루틴 3종이 남는 이유가 여기 있다.

3.2.1 단위 체크: 입력·출력 단위가 식과 맞는가

첫째 루틴은 단위 체크다. 함수에 들어가는 값과 나오는 값의 단위가 식이 요구하는 단위와 일치하는지 확인한다. 이 확인이 가능하려면 단위가 코드 안에 적혀 있어야 하므로, 이 교재는 물리량 변수마다 단위를 주석으로 남긴다. T = 373.15 # K처럼 적는다. 단위가 적혀 있지 않으면 검증하기 어렵다.

상관식을 다룰 때는 단위 체크가 네 항목으로 늘어난다. 상관식은 겉보기가 같아도 정의가 제각각이기 때문이다. 같은 Antoine 식이라도 어떤 자료는 로그 밑을 log₁₀으로, 어떤 자료는 ln으로 쓰고, 압력을 bar로 주기도 mmHg로 주기도 한다. 그래서 상관식의 상수를 받으면 로그 밑 · 압력 단위 · 온도 단위 · 유효범위 네 가지를 먼저 확인한다. 이 네 항목을 이 교재에서는 상관식 상수 표에 늘 함께 적는다.

3.2.2 대조값: 아는 값 한 점과 비교한다

둘째 루틴은 대조값 비교다. 계산 결과를 이미 알려진 참값 한 점과 맞대어 본다. 물이 1 atm에서 100 °C에 끓는다는 사실 하나만 있어도, 100 °C의 증기압 계산이 1.013 bar 근처로 나오는지 확인할 수 있다. 대조값이 하는 일은 물성 날조와 자신만만한 오답을 동시에 걸러 내는 것이다. AI의 어조가 아무리 확신에 차 있어도, 값이 참값과 어긋나면 그 답은 채택하지 않는다.

대조값은 어디서 얻는가. 두 곳을 이 장에서 소개하고, 코드로 조회하는 법은 5장에서 익힌다.

NIST Chemistry WebBook은 미국 국립표준기술원(NIST)이 운영하는 공개 물성 데이터베이스다. 웹 브라우저에서 물질을 찾아 상변화 데이터(phase change data)를 열면, 끓는점·임계 물성과 함께 Antoine 상수까지 출처가 명기된 채로 나온다. 조회 절차는 다음과 같다.

1. 브라우저에서 webbook.nist.gov/chemistry로 간다.
2. 이름이나 화학식으로 물질을 검색한다(예: water, H2O).
3. 물질 홈페이지에서 "Other data available"의 "Phase change data"를 연다.
4. 표에서 필요한 값을 읽고, 유효범위와 출처를 함께 적어 둔다.

CoolProp은 순수 유체의 열역학 물성을 계산해 주는 오픈소스 라이브러리다. NIST WebBook이 사람이 눈으로 찾는 웹 조회라면, CoolProp은 코드가 함수 호출로 값을 받아 오는 조회다. 자동화된 도구 안에서는 웹을 사람이 뒤질 수 없으므로, 5장부터는 물성값을 CoolProp으로 조회한다. 지금 기억할 것은 하나다. 물성값은 AI에게 묻지 않는다.

3.2.3 극한값 sanity: 극한에서 물리가 말이 되는가

셋째 루틴은 극한값 sanity다. 입력을 물리적 극단으로 밀어 넣고, 결과가 상식과 같은 방향인지 본다. 온도를 낮추면 증기압도 낮아져야 하고, 압력을 낮추면 끓는점도 내려가야 한다. 방향이 거꾸로면 대조값을 따질 것도 없이 코드가 틀린 것이다.

극한값 검사가 특히 날카롭게 걸리는 지점이 상관식의 유효범위 경계다. 경험식은 특정 온도·압력 구간의 데이터에 맞춰 만든 곡선이라, 그 구간을 벗어나 값을 구하면 오차가 급격히 커진다. 유효범위 밖에서 값을 구하는 일을 외삽(extrapolation)이라 한다. §3.3의 예제에서 이 외삽 오차를 숫자로 직접 본다.

3.3 물성 날조를 잡아내는 법: Antoine 상수 사례

세 루틴을 실제 물성에 걸어 보자. 소재는 증기압이다. 액체가 자신의 기체와 평형을 이루는 압력을 증기압(vapor pressure, p*)이라 하고, 온도가 오르면 증기압도 오른다. 증기압을 온도의 함수로 근사하는 대표적 경험식이 Antoine 식이다.

log₁₀ p* = A − B / (T + C) (3.1)

여기서 A, B, C는 물질마다 다른 상수이고, p*는 증기압, T는 온도다. 이 식의 물리적 의미와 유도는 8장에서 다룬다. 지금은 검증의 대상으로만 쓴다. 이 절에서 배울 것은 Antoine 식을 푸는 법이 아니라, AI가 이 식으로 낸 값을 어떻게 걸러 내는가다.

NIST WebBook에서 물의 상수를 조회하면 온도 구간별로 여러 벌이 나온다. 그중 두 벌을 표 3-1에 옮겼다. 표에 로그 밑·압력 단위·온도 단위·유효범위 네 항목이 모두 적혀 있음을 눈여겨보라. 이것이 §3.2.1에서 말한 상관식 상수 표의 형식이다.

def water_vapor_pressure(T, A, B, C):   # T: 온도 [K]
    """Antoine 식으로 증기압을 계산한다. 반환 단위 [bar]."""
    return 10 ** (A - B / (T + C))       # 식 (3.1), p* [bar]

# 표 3-1의 고온역(379-573 K) 상수를 373 K에 적용
p = water_vapor_pressure(373.0, 3.55959, 643.748, -198.043)
print(round(p, 3))                       # 0.759 가 출력된다

예제 3.3-1은 코드가 옳은데 입력이 틀린 경우였다. 이제 코드 자체가 틀리는 두 경우를 본다. 첫째는 물성 날조, 둘째는 단위·로그 밑 오류다. 두 사례 모두 검증 루틴이 없으면 지나쳤을 오류다.

def read_wiki_note(path):
    """위키 노트(.md) 한 편을 문자열로 읽어 온다."""

def save_deck_csv(filename, cards):
    """cards(리스트: (앞면, 뒷면) 튜플)를 Anki용 CSV로 저장한다."""

4.1 잊는 뇌, 꺼내는 뇌

시험을 망친 뒤 가장 흔한 진단은 "덜 읽어서"다. 그래서 다음 시험에는 더 여러 번 읽는다. 교육심리학의 진단은 방향이 반대다. 문제는 덜 읽은 것이 아니라 덜 꺼낸 것이다.

4.1.1 시험 효과: 꺼내는 행위가 기억을 만든다

기억에서 정보를 스스로 재구성해 꺼내는 행위를 인출(retrieval)이라 한다. 다시 읽기는 정보를 눈앞에 가져다 놓는 일이고, 인출은 눈앞에 없는 것을 머리에서 복원하는 일이다. 같은 내용을 다뤄도 뇌가 하는 일이 다르다.

인출 행위 자체가 그 기억을 강화하는 현상을 시험 효과(testing effect)라 하고, 시험 효과를 의도적으로 학습에 쓰는 전략을 인출연습(retrieval practice)이라 한다. 같은 시간을 쓴다면 다시 읽기보다 스스로 꺼내 보는 쪽이 장기 기억에 남는다는 것이 시험 효과 연구들의 공통 결론이다. 시험은 실력을 재는 장치이면서, 실력을 만드는 장치이기도 하다.

다시 읽기가 기대만큼 남지 않는 이유도 여기서 나온다. 세 번째 읽는 노트는 술술 넘어간다. 그 매끄러움은 "노트가 눈에 익었다"는 신호이지 "시험장에서 백지 위에 재구성할 수 있다"는 신호가 아니다. 익숙함을 이해로 착각하는 순간, 공부 시간과 성적이 따로 놀기 시작한다.

구체적인 장면으로 옮겨 보자. 3주차에 만든 플래시카드 한 장의 앞면에 "절대습도와 상대습도의 정의 차이는?"이 적혀 있다. 뒷면을 보기 전에 멈춰서 답을 말해 보는 그 몇 초에 학습이 일어난다. 답이 틀렸어도 좋다. 인출을 시도한 뒤에 본 정답은 그냥 읽은 정답보다 오래 남는다. 도구② 플래시카드 생성기는 처음부터 인출연습 장치로 설계된 것이다.

4.1.2 간격반복: '언제'의 설계

인출연습이 "어떻게"의 답이라면, 남은 질문은 "언제"다. 복습 사이의 간격을 점점 늘려 가며 인출을 반복하는 전략을 간격반복(spaced repetition)이라 한다.

논리는 이렇다. 방금 본 것을 다시 꺼내는 일은 쉽고, 쉬운 인출은 기억을 거의 바꾸지 못한다. 조금 잊힐 때까지 기다렸다가 꺼내면 인출은 힘들어지지만, 성공했을 때 기억이 훨씬 단단해진다. 학습에 오히려 유익한 이런 어려움을 바람직한 어려움(desirable difficulty)이라 한다. 몰아서 열 번 읽는 벼락치기가 시험 다음 날 증발하는 이유가, 뒤집으면 간격반복이 작동하는 이유다.

그렇다면 간격은 정확히 며칠이어야 하는가. 최적값은 자료의 난도와 사람에 따라 달라서, 하나의 정답 수열은 없다. 이 책은 출발 규칙으로 1일 → 3일 → 7일 → 14일을 채택한다. 복습에 성공할 때마다 다음 간격이 두 배 안팎으로 늘어난다는 구조가 본질이고, 수열의 값 자체는 조정 대상이다. 그래서 4.3절의 예제는 이 수열을 코드에 박아 넣지 않고 데이터로 분리한다. 나중에 본인 기록을 보고 값을 바꾸더라도 코드는 건드리지 않게 하기 위해서다.

한 가지는 분명히 해 두자. 간격반복은 이해를 대체하지 않는다. 이해한 것이 새 나가지 않게 막는 유지 장치로 보면 된다. 이해는 수업과 문제 풀이의 몫이고, 이 장의 도구는 그 뒤를 맡는다.

4.2 위키 구조화: 씨앗에서 상록수까지

인출연습은 카드에만 적용되는 원리가 아니다. 1주차부터 운영해 온 위키 노트에도 같은 원리를 심을 수 있다. 핵심 장치는 노트의 성장단계를 표시하는 세 개의 태그 #seed → #growing → #evergreen이다. 노트를 완성된 문서가 아니라 자라는 생물로 취급하는 이 관례를 이 수업의 위키 규약으로 채택한다.

승격 기준을 이렇게 박아 두는 이유는 승격 작업 자체가 인출연습이기 때문이다. #seed를 #growing으로 올리려면 원문을 덮고 내 말로 다시 써야 하고, 그것이 곧 인출이다. #growing을 #evergreen으로 올리려면 다른 노트·다른 과목과 연결해야 하는데, 연결은 나중에 그 지식을 꺼낼 인출 단서를 늘린다. 태그는 "이 노트에 어떤 학습 행위가 일어났는가"의 기록으로 쓴다.

채점과의 연결도 명확하다. 위키 채점 기준(마일스톤 3회, 주당 의미 있는 커밋)은 1장에 정리해 두었다. 마일스톤마다 evergreen 승격 수와 링크 밀도가 집계되며, 첫 집계인 마일스톤①이 바로 다음 주다.

도구가 위키를 읽으려면 사람만 알아보는 노트로는 부족하다. 노트 머리에 기계가 읽을 수 있는 형식으로 메타데이터를 적는 관례를 프런트매터(frontmatter)라 한다. 이 수업의 최소 규약은 세 필드다.

---
title: 이상기체
tags: [seed]
updated: 2026-09-27
---
# 이상기체
오늘 화공양론: PV = nRT가 잘 맞는 조건이 따로 있다. (내일 내 말로 다시 쓸 것)

구획선 --- 두 줄 사이가 프런트매터다. tags는 성장단계, updated는 마지막 수정일이다. 이 세 줄이 4.4절에서 도구들을 잇는 접착제가 된다.

4.3 파일 입출력과 JSON: 도구에 기억을 심는 법

지금까지 만든 도구에는 공통된 한계가 있다. 실행이 끝나면 전부 잊는다는 것이다. 변수에 담긴 값은 프로그램이 종료되는 순간 사라진다. 스터디 플래너는 "이 노트를 마지막으로 언제 복습했는가"를 다음 실행 때도 기억해야 하므로, 데이터를 프로그램 바깥에 남기는 수단이 필요하다. 프로그램이 꺼져도 데이터가 남는 성질을 영속성(persistence)이라 하고, 그 가장 기본적인 수단이 파일이다.

4.3.1 텍스트 파일 읽고 쓰기

파일을 열 때 받는 것은 파일 내용 자체가 아니라 파일로 통하는 손잡이다. 이 손잡이를 파일 핸들(file handle)이라 한다. 핸들을 통해 한 줄씩 읽고, 다 쓰면 닫는다. 최소 문형부터 보자.

fhand = open('wiki/이상기체.md', 'r', encoding='utf-8')  # 'r' = 읽기 모드
count = 0
for line in fhand:            # 파일 핸들을 순회하면 한 줄씩 나온다
    count = count + 1
fhand.close()                 # 다 썼으면 닫는다
print('줄 수:', count)

encoding='utf-8'은 이 책의 전 코드 공통 규약이다. 윈도우의 기본 인코딩은 UTF-8이 아닐 수 있어서, 이 인자를 빼면 한글 노트가 깨져 읽히는 사고가 실습실에서 자주 일어난다. AI가 생성한 코드에 이 인자가 빠져 있으면 추가를 요구하라.

없는 파일을 읽기 모드로 열면 어떻게 되는가. 직접 겪어 보는 편이 빠르다.

>>> open('없는파일.md', 'r', encoding='utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '없는파일.md'

프로그램이 그 자리에서 멈춘다. 에러 이름 FileNotFoundError를 기억해 두자. 실습에서 plan.json이 아직 없을 때 정확히 이 에러를 만나게 되고, 그때 "파일이 없으면 빈 계획으로 시작하라"는 예외 처리를 AI에게 요구하게 된다.

쓰기는 모드만 바꾸면 된다. 다만 쓰기 모드에는 함정이 있다.

fout = open('오늘의_복습.md', 'w', encoding='utf-8')  # 'w' = 새로 쓰기
fout.write('# 2026-09-28 복습 목록\n')                # \n = 줄바꿈 문자
fout.write('- 이상기체\n')
fout.close()                  # 닫아야 마지막 내용까지 디스크에 기록된다

'w' 모드는 파일이 이미 있으면 기존 내용을 전부 지우고 새로 시작한다. 매번 새로 만드는 "오늘의 복습 목록"에는 적합하지만, 쌓아 가야 하는 데이터에 쓰면 기존 내용을 잃는다. 끝에 덧붙이는 모드는 'a'다. 이 구분이 얼마나 중요한지는 아래 사례가 보여 준다.

4.3.2 JSON: 구조가 있는 기억

복습 이력은 줄글이 아니라 구조다. 노트마다 마지막 복습일과 진행 단계가 붙어 있어야 한다. 이런 데이터를 담는 파이썬 자료형이 딕셔너리(dictionary)다. 키(key)를 넣으면 값(value)이 나오는 자료형으로, plan['이상기체']처럼 대괄호 안에 키를 써서 값을 꺼낸다. 문법 해부는 5장의 몫이고, 지금은 읽을 수 있으면 충분하다.

딕셔너리와 리스트를 중첩해 만든 구조를 텍스트로 저장하고 교환하는 표준 형식을 JSON(JavaScript Object Notation)이라 한다. 이름과 달리 자바스크립트 전용이 아니며, 오늘날 프로그램 사이의 데이터 교환에서 사실상 표준으로 쓰인다. 파이썬 표준 라이브러리 json이 딕셔너리를 파일로, 파일을 다시 딕셔너리로 왕복시켜 준다.

import json

plan = {
    '이상기체':  {'last': '2026-09-27', 'stage': 0},   # 날짜 형식: 'YYYY-MM-DD'
    '습도 계산': {'last': '2026-09-21', 'stage': 2},   # stage: 0부터 시작하는 정수
}
with open('plan.json', 'w', encoding='utf-8') as f:
    json.dump(plan, f, ensure_ascii=False, indent=2)   # 사람도 읽을 수 있게 저장

with open('plan.json', encoding='utf-8') as f:
    plan2 = json.load(f)                                # 파일 → 딕셔너리 복원
print(plan2['습도 계산']['stage'])                       # 2

새 문형이 하나 등장했다. with open(...) as f: 블록은 블록이 끝나는 순간 파일을 자동으로 닫는다. close()를 잊는 실수를 구조적으로 차단하므로, 이후 모든 코드에서 이 문형을 기본으로 쓴다. ensure_ascii=False는 한글을 사람이 읽을 수 있는 그대로 저장하게 하는 옵션이다.

생성 코드에서 자주 마주치는 함정이 하나 있다. json.load에는 파일 핸들이 들어가야 하는데, 경로 문자열을 바로 넘기는 코드가 종종 생성된다. 결과는 이렇다.

>>> json.load('plan.json')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  ...
AttributeError: 'str' object has no attribute 'read'

에러 문구가 원인을 말해 주지 않는 전형적인 경우다. "문자열에는 read가 없다"는 말의 진짜 뜻은 "파일 핸들 자리에 문자열이 들어왔다"이다. 이 에러를 만나면 open()을 거쳤는지부터 확인하라.

from datetime import date, timedelta

INTERVALS = [1, 3, 7, 14]        # 복습 간격 (일) — 규칙은 데이터로 분리

def next_review(last, stage):
    """마지막 복습일(ISO 문자열)과 단계로 다음 복습일을 계산한다."""
    last_day = date.fromisoformat(last)     # 'YYYY-MM-DD' → date 객체
    idx = min(stage, len(INTERVALS) - 1)    # 단계 초과 시 마지막 간격 유지
    return last_day + timedelta(days=INTERVALS[idx])

def due_today(plan, today):
    """오늘 복습해야 할 노트 이름 목록을 돌려준다."""
    due = []
    for name in plan:                        # 딕셔너리 순회 = 키 순회
        item = plan[name]
        if next_review(item['last'], item['stage']) <= today:
            due.append(name)                 # 예정일이 지난 노트도 포함
    return due

>>> with open('plan.json', encoding='utf-8') as f:
...     plan = json.load(f)
...
>>> due_today(plan, date(2026, 9, 28))
['이상기체', '습도 계산']

4.4 학습 OS: 도구를 파이프라인으로 잇는다

도구가 셋이 되었다. 이제 이들을 하나의 시스템으로 묶는다. 한 도구의 출력 파일이 다음 도구의 입력이 되도록 연결한 사슬을 파이프라인(pipeline)이라 한다.

강의노트(텍스트 붙여넣기)
      │  도구① 강의노트 정리기
      ▼
wiki/*.md  (프런트매터: title, tags, updated)
      │                          │
      │  도구② 플래시카드 생성기   │  도구③ 스터디 플래너 ←── plan.json (복습 이력)
      ▼                          ▼
   Anki 덱                 오늘의_복습.md

이 파이프라인과 위키, 그리고 그것을 매일 굴리는 복습 습관 전체를 이 수업에서는 학습 OS라 부른다. 컴퓨터의 운영체제가 프로그램에게 저장과 메모리를 제공하듯, 학습 OS는 공부에게 저장(위키)·인출(플래시카드)·스케줄(플래너)을 제공한다. 시스템의 요점은 순환이다. 도구를 쓰면 위키가 자라고, 위키가 자라면 카드와 복습 목록이 저절로 늘어난다.

통합의 실체는 규약이다. 폴더 구조, 파일 이름, 프런트매터 필드, plan.json의 스키마가 도구 사이의 인터페이스다. 도구①이 tags 필드를 빼먹으면 도구③이 위키를 읽지 못한다. 그래서 규약은 README에 명문화하고, AI에게 연결 코드를 시킬 때마다 그 규약을 프롬프트에 그대로 붙여넣는다. 이것이 파이프라인 작업의 표준 프롬프트 패턴이다(요약 S 4-4).

파이프라인의 고장은 각 도구 안이 아니라 이음매에서 난다. 도구 셋이 각자 완벽히 돌아가도, 도구①이 쓰는 날짜 형식과 도구③이 기대하는 형식이 다르면 시스템 전체가 멈춘다. 그래서 통합 작업의 마지막은 언제나 이음매 검사다.

import json
from pathlib import Path

def check_seams(wiki_dir, plan_file):
    """wiki 노트와 복습 계획의 이음매를 검사한다."""
    with open(plan_file, encoding='utf-8') as f:
        plan = json.load(f)
    notes = []
    for p in Path(wiki_dir).glob('*.md'):   # wiki 폴더의 모든 노트
        notes.append(p.stem)                # p.stem = 확장자를 뺀 이름
    missing = []                            # wiki에 있는데 계획에 없음
    for name in notes:
        if name not in plan:
            missing.append(name)
    ghost = []                              # 계획에 있는데 wiki에 없음
    for name in plan:
        if name not in notes:
            ghost.append(name)
    return missing, ghost

5.1 코드를 말로 설명한다는 것: EiPE

1주차의 역할 분담을 다시 꺼내자. 코드는 AI가 쓰고, 학생은 문제 분해·생성 코드 읽기·화학공학적 검증을 책임진다. 이 분담에서 "읽기"는 채점 대상이다. 최종 시험 루브릭의 코드 이해 10점은 무작위 지목 설명 4점, "이 줄을 바꾸면?" 예측 3점, 한계·개선점 3점으로 구성되고, 지목 질문 3개 중 2개 이상 설명에 실패하면 이 차원 전체가 0점이다.

코드 한 조각의 목적과 동작을 자연어로 설명하는 훈련을 EiPE(Explain in Plain English)라 한다. 컴퓨팅 교육 연구에서 코드 이해도를 측정하는 표준 문항 유형으로 쓰여 왔고, 이 수업에서는 시험1의 서술 문항과 매주 구술의 공통 형식이다. 프로그래밍 초보자가 LLM이 생성한 코드를 올바르게 이해하는 비율이 32.5%에 그쳤다는 보고(arXiv 2504.19037)가 있다. 셋 중 둘은 돌아가는 코드를 설명하지 못한 채 제출한다는 뜻이다.

5.1.1 라인 낭독과 설명은 다르다

다음 함수를 보자. mmHg 단위의 압력을 bar로 바꾸는, AI가 생성했을 법한 네 줄짜리 코드다.

def mmhg_to_bar(p_mmhg):
    """mmHg 단위 압력을 bar로 환산한다."""
    p_pa = p_mmhg * 133.322   # 압력 [Pa], 1 mmHg = 133.322 Pa
    return p_pa / 1.0e5       # 압력 [bar], 1 bar = 1e5 Pa

이 코드에 대한 두 가지 설명을 비교해 보자.

나쁜 설명(라인 낭독): "p_mmhg에 133.322를 곱해서 p_pa에 넣고, p_pa를 1.0e5로 나눠서 반환한다."

좋은 설명(EiPE): "mmHg 단위의 압력을 받아 bar 단위로 바꿔 돌려주는 함수다. 중간에 Pa를 한 번 거쳐 두 단계로 환산한다. 음수 압력 같은 비물리적 입력은 걸러내지 않는다."

나쁜 설명은 코드를 소리 내어 읽었을 뿐이어서, 코드를 보지 않은 사람에게는 정보를 거의 주지 못한다. 좋은 설명은 코드 없이도 이 함수를 다시 만들 수 있을 만큼의 정보를 담는다. 무엇을 받아 무엇을 돌려주는지, 어떤 경로로 바꾸는지, 어떤 한계를 안고 있는지가 여기에 들어간다. 시험1의 EiPE 문항과 구술 평가의 지목 질문이 요구하는 것은 후자다.

좋은 설명에는 뼈대가 있다. 목적("무엇을 하는 함수인가"), 입력("무엇을, 어떤 단위로 받는가"), 처리("어떤 경로로 바꾸는가"), 출력("무엇을, 어떤 단위로 돌려주는가"), 한계("어떤 입력에서 무너지는가")의 다섯 요소다. 다섯 요소를 전부 갖추면 두세 문장이 된다. 이 공식은 장 끝의 요약에 S 5-1로 다시 나온다.

읽기가 쓰기보다 먼저인 이유는 이 수업의 구조 자체에 있다. 쓰기는 AI가 대신하지만, AI가 쓴 것이 맞는지 판정하는 읽기는 사람의 몫으로 남는다. 프로그래밍 문법을 다 배운 뒤에 읽기를 시작하지 않고, 읽기에 필요한 최소 문법(변수, 제어문, 함수)만을 이번 장에서 골라 배운다.

5.2 변수 읽기: 이름, 값, 그리고 단위

값을 가리키는 이름을 변수(variable)라 한다. 코드를 읽는 일은 결국 각 변수가 어느 시점에 어떤 값을 가리키는지 따라가는 일이다. 아래 네 줄을 보자.

p_mmhg = 800.0                 # 측정 압력 [mmHg]
PA_PER_MMHG = 133.322          # 환산계수 [Pa/mmHg]
p_pa = p_mmhg * PA_PER_MMHG    # 압력 [Pa]
p_bar = p_pa / 1.0e5           # 압력 [bar], 1 bar = 1e5 Pa
print(f"{p_bar:.4f} bar")      # 출력: 1.0666 bar

첫 줄은 p_mmhg라는 이름에 800.0이라는 값을 묶는다. 이런 문장을 할당(assignment)이라 한다. 둘째 줄의 PA_PER_MMHG는 환산계수를 담은 변수인데, 대문자 이름은 "이 값은 바꾸지 않겠다"는 관례적 신호다. 셋째 줄에서 곱셈이 일어나 새 변수 p_pa가 생기고, 넷째 줄에서 다시 p_bar가 생긴다.

실행 순서를 따라 변수의 값을 표로 적는 일을 상태 추적(tracing)이라 한다. 위 코드의 상태표는 다음과 같다.

화공 코드의 변수에는 프로그래밍 교재에 없는 규율이 하나 더 붙는다. 물리량 변수에는 반드시 단위 주석을 단다는 규율이다. p = 800.0이라고만 적힌 코드에서 800이 mmHg인지 kPa인지 psi인지는 코드 어디에도 없다. 단위가 주석에 있어야 검증 루틴의 첫 항목인 단위 체크가 가능해진다.

단위를 추적하면 코드가 틀린 것도 잡아낸다. 단위환산 교재의 고전적 실수 사례를 코드로 옮겨 보자.

p_mmhg = 800.0                    # 압력 [mmHg]
p_wrong = p_mmhg * 760.0 / 1.013  # 잘못된 환산: 단위가 [mmHg²/bar]가 된다
print(p_wrong)                    # 600197.4... — 비물리적 크기

환산계수 "1 atm = 760 mmHg = 1.013 bar"를 거꾸로 곱하면 값이 6.0×10⁵라는 터무니없는 크기가 되고, 단위는 mmHg²/bar라는 존재하지 않는 조합이 된다. 값을 보고 이상함을 느끼는 것이 극한값 감각이고, 단위를 적어 보고 오류를 확정하는 것이 단위 체크다. 3장에서 도입한 검증 루틴 3종이 코드 읽기에서 그대로 작동한다.

t_f = 212.0                # 온도 [°F]
t_c = (t_f - 32.0) * 5 / 9 # 온도 [°C]
t_k = t_c + 273.15         # 온도 [K]
print(f"{t_k} K")

5.3 제어문 읽기: 갈림길과 반복

지금까지의 코드는 위에서 아래로 한 번씩만 실행됐다. 그러나 실제 코드는 "이 조건이 참이면 이것을 하고, 아니면 저것을 하라", "이 목록의 항목마다 같은 일을 반복하라" 같은 문장으로 흐름을 바꾼다. 조건에 따라 실행 경로를 가르는 문장을 조건문(conditional statement)이라 하고, 같은 블록을 여러 번 실행시키는 문장을 반복문(loop)이라 한다.

화공 도구에서 조건문의 첫 임무는 유효범위 검사다. 물성 상관식의 상수에는 반드시 유효 온도범위가 붙어 있고, 범위 밖의 온도로 값을 구하는 일을 외삽(extrapolation)이라 한다. 외삽을 조용히 허용하는 코드는 위험하므로, 좋은 도구는 계산 전에 범위를 검사한다.

t = 298.15                    # 조회 온도 [K]
t_min, t_max = 379.0, 573.0   # 상수 유효범위 [K], NIST(Liu and Lindsay)
if t < t_min or t > t_max:
    print("경고: 유효범위 밖 — 외삽 결과는 신뢰할 수 없다")
else:
    print("유효범위 안")

if 다음의 t < t_min or t > t_max는 참 또는 거짓으로 계산되는 식이다. 참이면 바로 아래 들여쓰인 블록이 실행되고, 거짓이면 else 블록이 실행된다. 여기서는 298.15가 379보다 작으므로 조건이 참이 되어 경고가 출력된다. 들여쓰기가 곧 소속을 나타낸다. 어떤 줄이 어느 블록에 속하는지는 들여쓰기 깊이가 결정한다.

반복문은 같은 계산을 목록 전체에 적용한다. 여러 값을 순서대로 담는 자료형을 리스트(list)라 하며, 대괄호로 만든다.

pressures_psi = [10.0, 14.7, 30.0, 100.0]  # 압력 목록 [psi]
KPA_PER_PSI = 6.895                         # 환산계수 [kPa/psi]
for p in pressures_psi:
    print(f"{p:6.1f} psi = {p * KPA_PER_PSI:8.1f} kPa")

for p in pressures_psi:는 리스트의 항목을 하나씩 꺼내 p에 담고, 들여쓰인 블록을 항목 수만큼(여기서는 네 번) 실행한다. 둘째 항목 14.7 psi는 101.4 kPa로 환산되는데, 이는 1 atm(101.325 kPa)과 거의 같다. 표 하나를 출력했을 뿐인데 대조값 검증이 공짜로 따라온 셈이다.

실행 흐름을 읽는 요령은 "다음에 실행될 줄이 몇 번째 줄인가"를 계속 자문하는 것이다. 조건문에서는 어느 가지로 가는지, 반복문에서는 몇 바퀴째인지를 상태표 옆에 함께 적으면 된다. 흐름 추적은 유용하지만 코드가 길어지면 금세 벅차진다. 그때 필요한 것이 다음 절의 함수 단위 읽기다.

t = 320.0   # 조회 온도 [K]
# 물의 Antoine 상수 (log10, p*[bar], T[K]) — 표 5-2, NIST WebBook
if 273.0 <= t <= 303.0:
    a, b, c = 5.40221, 1838.675, -31.737
elif 304.0 <= t <= 333.0:
    a, b, c = 5.20389, 1733.926, -39.485
elif 334.0 <= t <= 363.0:
    a, b, c = 5.07680, 1659.793, -45.854
else:
    raise ValueError("유효범위 밖 온도")
p_bar = 10 ** (a - b / (t + c))   # 증기압 [bar]
print(f"{p_bar:.3f} bar")

표 5-2에는 이 교재의 상수 표기 의무 네 가지(로그 밑, 압력 단위, 온도 단위, 유효범위)가 전부 들어 있다. 넷 중 하나라도 빠진 상수 표는 쓰지 않는다. 마지막 행의 상수를 유효범위 아래인 373 K에 적용하면 0.76 bar가 나오는데, 물이 1 atm(1.013 bar)에서 끓는다는 상식과 25% 어긋난다. 외삽의 대가는 8장에서 정량적으로 다룬다.

5.4 함수 읽기: 입력·변환·출력의 계약

이름을 붙여 두고 필요할 때마다 불러 쓰는 코드 묶음을 함수(function)라 한다. 함수에 넘겨주는 값을 인자(argument), 함수가 돌려주는 값을 반환값(return value)이라 한다. 함수의 첫 줄(이름과 인자 목록)은 "무엇을 주면 무엇을 돌려주겠다"는 계약서이고, 함수 읽기는 이 계약서 읽기에서 시작한다.

def mmhg_to_bar(p_mmhg):이라는 첫 줄만 보고도 세 가지를 읽어낼 수 있다. mmHg를 bar로 바꾸는 일을 하고, 압력 하나를 받으며, 이름의 방향(mmhg→bar)이 환산 방향을 약속한다. 본문을 읽기 전에 계약부터 읽는 습관은 코드가 길어질수록 도움이 된다. 흐름 추적이 벅찬 큰 코드도 함수 단위로 끊으면 계약들의 연결로 읽힌다.

실제로 AI에게 함수를 시키고 그 결과를 읽어 보자. 프롬프트-응답 리스팅의 3단 형식은 2장에서 선언한 그대로다.

def psi_to_kpa(p_psi):
    """psi 단위 압력을 kPa로 환산한다."""
    KPA_PER_PSI = 6.895          # 환산계수 [kPa/psi]
    return p_psi * KPA_PER_PSI   # 압력 [kPa]

검증 코멘트가 짚은 대로, 생성된 함수는 계약을 지키지만 비물리적 입력에 침묵한다. "절대압이 음수면 ValueError를 일으켜 줘"라고 한 줄 더 요구하면 5.3절의 조건문이 함수 안으로 들어온다. 프롬프트 → 읽기 → 결함 발견 → 프롬프트 개선의 사이클이 한 바퀴 돈 것이다.

5.4.1 딕셔너리: 이름으로 값을 꺼내는 상자

물성 조회기는 밀도·끓는점처럼 여러 값을 한꺼번에 다룬다. 이름표(키)로 값을 꺼내는 자료형을 딕셔너리(dictionary)라 하며, 중괄호로 만든다.

props = {"T_boil_K": 373.12, "rho_kg_m3": 997.0}  # 물성 이름 → 값
print(props["T_boil_K"])   # 키로 조회: 373.12

리스트가 순서(0번째, 1번째)로 값을 꺼낸다면 딕셔너리는 이름으로 꺼낸다. props["rho_kg_m3"]처럼 키에 단위를 새겨 두는 것도 단위 주석 규율의 연장이다. 이 장에서 리스트와 딕셔너리는 여기까지만 필요하다. 항목을 담고, 꺼내고, 반복문으로 순회하는 수준이면 도구④를 읽고 만들 수 있다.

5.4.2 CoolProp: 물성을 조회하는 함수 라이브러리

물성값 자체를 AI에게 묻는 것은 위험하다는 사실을 3장에서 보았다. 대안은 검증된 물성 라이브러리를 코드로 조회하는 것이다. CoolProp은 순수 유체의 열역학 물성을 계산해 주는 오픈소스 라이브러리로, PropsSI 함수 하나로 대부분의 조회가 끝난다.

from CoolProp.CoolProp import PropsSI

def water_boiling_t(p_pa):
    """압력 p_pa[Pa]에서 물의 끓는점[K]을 반환한다."""
    return PropsSI("T", "P", p_pa, "Q", 0, "Water")  # 포화온도 [K]

t_b = water_boiling_t(101325.0)   # 1 atm = 101325 Pa
print(f"{t_b:.2f} K")             # 출력: 373.12 K

5.5 첫 타이머, 첫 공개 구술: 마음의 준비

이번 주 실습부터 두 가지가 바뀐다. 첫째, 과제에 30분의 제한시간이 걸린다. 둘째, 실습 마무리에 무작위로 지목된 학생이 자기 코드 한 부분을 모두 앞에서 1분간 설명한다. 1~4주의 실습이 시간 무제한에 페어 안에서만 설명하는 저부담 구간이었다면, 5주차는 시험 형식으로 넘어가는 첫 계단이다.

제한시간은 1장에서 안내한 대로 최종 시험의 120분까지 매주 조금씩 늘어난다. 처음부터 2시간짜리 압박을 주는 대신 시간 감각을 단계적으로 키우는 설계다. 30분 안에 도구④를 완성하지 못해도 성적에는 아무 일도 일어나지 않는다. 이번 주 결과는 등수 없이 통과/재도전의 2단계로만 처리되고, 재도전은 다음 실습 전까지 열려 있다.

공개 구술이 두려운 것은 정상이다. 다만 이 장치의 정체를 알면 부담이 줄어든다. 구술은 4장에서 배운 인출연습의 사회적 버전이다. 머릿속에 있다고 믿는 지식을 꺼내 보는 행위 자체가 기억을 강화하며, 설명하다 막히는 지점이 곧 공부할 지점이다. 지금 사람들 앞에서 막히는 데에는 아무 대가가 없지만, 최종 시험의 구술 방어에서 막히면 점수로 이어진다. 매주 반복되는 리허설이 그 부담을 미리 덜어 준다.

준비 방법은 단순하다. 실습 중 함수 하나를 완성할 때마다 소리 내지 않아도 좋으니 S 5-1의 순서(목적→입력→처리→출력→한계)로 속으로 한 번 설명해 본다. 퇴실 전 페어에게 1분 설명을 한 번 하고 나가면 그 주의 구술 리허설은 끝난 셈이다. 막히면 침묵하지 말고 "목적부터 다시 말하겠습니다"라고 처음으로 돌아가면 된다. 구조를 따라 말하는 훈련이다.

6.1 오류의 세 얼굴: 문법, 런타임, 의미

프로그램이 틀리는 방식은 크게 세 가지다. 셋은 드러나는 시점이 다르고, 파이썬이 도와주는 정도와 위험한 정도도 다르다. 채점의 첫 단계는 지금 눈앞의 오류가 셋 중 무엇인지 판별하는 일이다.

파이썬 문법 규칙을 어겨 실행이 아예 시작되지 못하는 오류를 문법 오류(syntax error)라 한다. 괄호 짝이 안 맞거나 if 뒤의 콜론을 빠뜨린 경우가 대표적이다. 파이썬은 프로그램을 시작하기 전에 멈춰 서서 위치를 알려 주므로, 셋 중 가장 값싸게 고칠 수 있다.

실행 도중 더 진행할 수 없는 상황을 만나 프로그램이 멈추는 오류를 런타임 오류(runtime error)라 한다. 0으로 나누거나, 정의한 적 없는 이름을 부르는 경우다. 이때 파이썬이 발생시키는 신호를 예외(exception)라 하며, 예외가 나면 파이썬은 무엇이 어디에서 잘못됐는지를 담은 보고서를 출력한다. 이 보고서를 읽는 법이 6.2절의 주제다.

프로그램이 끝까지 돌고 출력도 내놓지만, 의도한 것과 다른 일을 하는 오류를 의미 오류(semantic error)라 한다. 장 첫머리의 2.05 L가 정확히 이것이다. 파이썬은 오류를 알리지 않았다. 시킨 계산을 충실히 수행했을 뿐이고, 틀린 것은 계산의 설계였다.

앞의 두 오류는 시끄럽다. 파이썬이 실행을 멈추고 오류를 알리므로 존재를 놓칠 수 없다. 의미 오류는 조용하다. 멀쩡해 보이는 숫자가 보고서와 설계 계산 속으로 흘러 들어간다. 셋 중 화학공학자에게 가장 위험한 것은 의미 오류다.

AI 생성 코드에서 이 균형은 의미 오류 쪽으로 더 쏠린다. AI는 방대한 코드로 훈련되어 문법적으로는 매끈한 코드를 내놓는다. 실행이 되니 맞아 보이고, 맞아 보이니 검증을 건너뛰게 된다. 프로그래밍 입문자가 AI 생성 코드를 정확히 이해한 비율이 32.5%에 그쳤다는 조사(arXiv 2504.19037)를 5장에서 보았다. 읽지 못한 코드 속의 의미 오류는 잡아내기 어렵다.

3장의 환각 문제와도 이어진다. AI가 날조한 물성값이나 존재하지 않는 함수가 코드에 들어오면, 어떤 것은 시끄러운 런타임 오류로, 어떤 것은 조용한 의미 오류로 나타난다. 다음 사례는 시끄러운 쪽이다. 그래서 오히려 다행인 경우다.

6.2 트레이스백: 에러 메시지를 읽는 법

런타임 오류를 직접 만나 보자. 코드 6-1은 이상기체의 몰부피를 구하려는 함수인데, 안에 실수가 하나 심어져 있다.

R = 8.314  # J/(mol·K), 출처: NIST CODATA

def molar_volume(T, P):
    """이상기체 몰부피 [m^3/mol]. 입력: T[K], P[Pa]"""
    return R * T_kelvin / P

v = molar_volume(298.15, 101325.0)
print(v)

실행하면 계산 결과 대신 다음 보고서가 출력된다. 요약하지 않고 전문을 싣는다.

Traceback (most recent call last):
  File "molar_volume.py", line 7, in <module>
    v = molar_volume(298.15, 101325.0)
  File "molar_volume.py", line 5, in molar_volume
    return R * T_kelvin / P
NameError: name 'T_kelvin' is not defined

런타임 오류가 나면 파이썬은 예외의 이름, 문제가 일어난 줄, 그리고 그 줄에 도달하기까지의 함수 호출 경로를 담은 보고서를 출력한다. 이 보고서를 트레이스백(traceback)이라 한다. 첫 줄의 "most recent call last"가 읽기 방향을 알려 준다. 사고 현장인 가장 최근의 호출이 맨 아래에 있다.

그래서 트레이스백은 아래에서 위로 읽는다. 첫째, 마지막 줄을 본다. NameError가 병명이고, name 'T_kelvin' is not defined가 증상 설명이다. 둘째, 바로 위 블록에서 발병 위치를 확인한다. molar_volume.py의 5행, molar_volume 함수 안이다. 셋째, 더 위 블록으로 올라가면 그 함수를 누가 불렀는지가 나온다. 7행의 최상위 호출이다.

병명과 위치가 나왔으니 원인 진단은 짧다. 함수의 매개변수 이름은 T인데 본문에서는 T_kelvin이라는, 어디에서도 정의된 적 없는 이름을 썼다. T_kelvin을 T로 고치거나 매개변수 이름을 T_kelvin으로 바꾸면 해결된다. 파이썬 버전에 따라 문제 지점 아래에 ^ 기호가 추가로 표시되기도 하는데, 읽는 순서는 같다.

예외의 이름은 원인의 범주를 바로 좁혀 준다. 자주 만나는 여섯 가지를 표 6-2에 모았다. 시험1에서도, 앞으로의 모든 실습에서도 이 여섯이 마주칠 예외의 대부분을 차지한다.

이 중 ValueError는 화공 데이터 처리에서 유난히 자주 만난다. 센서 로그나 CSV에서 읽은 값에는 단위 문자가 붙어 있는 경우가 많기 때문이다. 대화형 셸에서 직접 재현해 보자.

>>> float('25 C')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '25 C'

'25 C'는 문자열로서는 멀쩡하지만 수로 변환될 수 없는 값이다. 형은 맞고 값이 문제이므로 TypeError가 아니라 ValueError다. 이 구분이 되면 교정 방향이 자동으로 나온다. 단위 문자를 떼어내는 전처리가 필요하다.

마지막 규칙 하나. 에러 메시지는 요약하거나 의역하지 말고 전문 그대로 다뤄라. 검색할 때도, AI에게 물을 때도, 위키에 기록할 때도 원문 문자열이 그대로 있어야 같은 오류를 겪은 다른 사람의 해법과 연결된다. 지면의 트레이스백을 전부 전문으로 싣는 이유가 이것이다.

6.3 오답의 채점: 검증 루틴을 채점 기준으로 바꾼다

3주차에 도입한 검증 루틴 3종(단위 체크, 대조값, 극한값)은 지금까지 자신의 코드를 지키는 방패였다. 이번 절에서는 같은 루틴을 AI의 풀이를 채점하는 잣대로 돌려세운다. 방패가 채점 기준표가 되는 셈이다.

채점은 네 단계 절차로 고정한다. 첫째, 실행하기 전에 수식과 단위를 손으로 추적한다. 각 변수에 단위를 붙여 보고 등호 양변의 단위가 맞는지 본다. 둘째, 대조값 1점을 정한다. 교과서나 NIST에서 이미 아는 값 하나를 고른다. 셋째, 극한값을 머리로 대입해 본다. 0, 음수, 아주 큰 값에서 물리적으로 말이 되는 답이 나오는 구조인가. 넷째, 판정문을 쓴다. 틀린 줄 번호, 원인, 교정 방향을 완결 문장으로 적는다.

시험1의 문항 유형 ③ "AI가 낸 오답을 채점·교정하라"가 요구하는 것이 정확히 이 절차다. 지필 시험이므로 실행 단계가 없다. 컴퓨터 없이 ①~④를 해내는 훈련이 이 절의 목표다. 장 첫머리의 사건으로 돌아가 실제로 채점해 보자.

def ideal_gas_volume(n, T, P):
    """이상기체 부피를 계산한다."""
    R = 8.314  # 기체상수
    V = n * R * T / P
    return V

# 25 °C, 1 atm에서 1 mol
volume = ideal_gas_volume(1.0, 25, 101325)
print(f"부피: {volume * 1000:.2f} L")

채점이 끝났으면 교정을 요구할 차례다. 원인을 이미 알고 있으므로 교정 프롬프트는 구체적으로 쓸 수 있다. "고쳐줘" 대신 무엇을 어떻게 고칠지를 지정한다.

R = 8.314  # 기체상수 [J/(mol·K)], 출처: NIST CODATA

def ideal_gas_volume(n, T_celsius, P_pa):
    """이상기체 부피 [m^3]. 입력: n[mol], T[°C], P[Pa]"""
    T_kelvin = T_celsius + 273.15  # 절대온도 변환 [K]
    if T_kelvin <= 0:
        raise ValueError("절대온도는 0 K보다 커야 한다")
    return n * R * T_kelvin / P_pa

v = ideal_gas_volume(1.0, 25.0, 101325.0)  # 25 °C, 1 atm
print(f"부피: {v * 1000:.1f} L")

6.4 디버깅 프롬프트 전략: 가설이 먼저다

채점으로 원인을 찾았다면 다음은 고치는 일이다. 이 일을 디버깅(debugging)이라 한다. 검증된 프로그래밍 교재들은 디버깅을 네 가지 활동으로 정리한다. 읽기(코드를 다시 읽고 의도와 대조), 실행(바꿔 가며 돌려 보기), 숙고(증상에서 원인을 추리), 후퇴(최근 변경을 되돌려 작동하던 버전으로 복귀)이다. 초보자의 흔한 함정은 이 중 하나에만 매달리는 것이다.

디버깅은 실험 과학처럼 진행해야 한다. 원인에 대한 가설을 최소 하나 세우고, 가설이 맞다면/틀리다면 무엇이 관찰될지를 정한 뒤, 그것을 확인하는 실험(실행)을 설계한다. 가설 없이 코드를 무작위로 바꿔 가며 되기를 비는 방식을 무작위 행보 프로그래밍(random walk programming)이라 부르는데, 오래 걸리기로 악명이 높다.

AI 시대의 무작위 행보는 "고쳐줘"의 무한 반복이다. AI는 매번 그럴듯한 수정본을 내놓기 때문에 진전처럼 느껴지지만, 원인 진단이 없으므로 수렴이 보장되지 않고 코드는 반복 수정으로 점점 읽기 어려워진다. 나쁜 예부터 지면에 올린다.

좋은 디버깅 프롬프트는 세 패턴으로 요약된다. 패턴 1은 진단 요구다. 에러 메시지 전문과 코드를 주되, 수리를 시키지 않고 진단만 시킨다. "고치지 말고, 원인 후보 3개와 각각을 확인할 방법을 말하라." 후보를 받으면 확인 실험은 직접 한다. 원인을 확정하는 주체가 자신이어야 다음 단계의 교정 프롬프트를 구체적으로 쓸 수 있다.

패턴 2는 기대–실제 병기다. 의미 오류에는 에러 메시지가 없으므로 증상을 수치로 만들어 줘야 한다. "기대값은 약 24.5 L(근거: 0 °C에서 22.4 L), 실제 출력은 2.05 L로 약 12배 작다. 이 배율 차이를 만들 수 있는 원인부터 짚어라." 기대와 실제의 차이 크기 자체가 강력한 진단 단서다.

패턴 3은 역할 전환이다. 문제를 남에게 소리 내어 설명하다가 스스로 답을 찾는 기법을 고무 오리 디버깅(rubber duck debugging)이라 한다. AI와 함께라면 방향을 뒤집을 수 있다. "이 코드를 한 줄씩, 각 줄에서 변수의 단위가 무엇인지와 함께 설명하라." 설명을 읽는 쪽이 되면 자신이 쓴 프롬프트의 가정과 코드의 실제 동작 사이의 틈이 보인다. 예제 6.3-1의 코드에 이 프롬프트를 걸면 "T에 25가 들어온다"는 설명 줄에서 단위가 비어 있음이 드러난다.

세 패턴 모두에 통하는 보조 기술이 하나 있다. 문제를 일으키는 가장 작은 코드와 입력으로 줄여서 묻는 것이다. 이렇게 줄인 사례를 최소 재현 예제(minimal reproducible example)라 한다. 500행짜리 파일 전체 대신 예외를 일으키는 함수 하나와 입력 한 줄로 줄이면, 줄이는 과정에서 원인이 먼저 드러나는 일도 흔하다.

마지막으로 경계할 것은, AI의 교정이 원인 제거가 아니라 증상 은폐일 수 있다는 점이다. 교정 코드를 받으면 반드시 차이를 읽고 "원인을 없앴는가, 신호를 껐는가"를 물어야 한다.

6.5 시험1 안내: AI 없이 남는 것을 잰다

다음 주 시험1은 20점, 오프라인 지필이며 AI는 전면 금지다. 범위는 1~6주 누적이다. 최종 시험이 AI를 필수로 쓰는 실기인데 왜 첫 시험은 정반대인가. 최종 시험에서 AI를 전면 사용하기 때문이다. AI 없이 남는 개인의 두뇌, 곧 코드 읽기·검증·의사코드 설계 능력은 반대 조건에서만 따로 잴 수 있다. 이 수업의 AI 활용 규칙(시험1 금지, 시험2·최종 시험 필수)은 이 논리 위에 서 있다.

문항 유형은 네 가지다. ① 생성 코드 출력 예측 ② EiPE(제시된 AI 생성 코드를 한국어로 목적·동작 설명) ③ "AI가 낸 오답을 채점·교정하라"(단위 오류·날조 물성 포함) ④ 화공 계산문제의 의사코드 설계이다. 각 유형은 이미 이 책 어딘가에서 훈련했다. 표 6-3이 그 지도다.

대비 전략은 별것이 아니다. 이번 주 실습의 모의 시험을 실전 조건 그대로 치르고, 틀린 문항의 원인을 분류해 남은 일주일의 복습 우선순위를 정하는 것이다. 그 절차가 아래 실습이다.

T = 25.0            # °C
T += 273.15         # K로 변환
print(int(T))

def filter_temps(temps, t_min, t_max):
    ok = []
    for t in temps:
        if t_min <= t <= t_max:
            ok.append(t)
    return ok

def kpa_to_pa(p_kpa):
    return p_kpa / 1000

7.1 여섯 장의 지도: 무엇이 쌓였는가

1장에서 정한 역할 분담을 떠올려 보자. 코드는 AI가 쓰고, 학생은 문제 분해와 생성 코드 읽기, 그리고 화학공학적 검증을 책임진다. 2장은 이 분담을 실행하는 순서, 즉 문제 분해→프롬프트→코드 읽기→테스트 사이클을 몸에 익혔고 그 첫 산출물이 도구① 강의노트 정리기였다. 3장은 그 반대편을 보였다. AI가 틀리는 방식(환각·단위 오류·물성 날조)을 실증하고, 검증 루틴 3종(단위 체크 · 대조값 · 극한값 sanity)을 도입했다.

4장은 간격반복과 인출연습이라는 학습과학 위에 도구③ 스터디 플래너를 얹어 학습 OS를 완성했다. 5장에서는 첫 화공 도구인 도구④ 단위환산 + 물성 조회기를 만들며, 생성 코드를 변수·제어문·함수 단위로 해부해 말로 설명하는 EiPE 훈련이 시작됐다. 6장은 그 읽기 능력을 채점자의 자리로 옮겼다. AI가 낸 틀린 화공 계산을 채점·교정했고, 모의 시험1로 이번 주를 리허설했다.

표 7-1은 여섯 장을 한 장으로 접은 지도다. 각 장이 남긴 개념과 도구, 그것이 기른 역량을 시험1의 문항 유형과 연결했다. 오른쪽 끝 열이 이 장의 주제다.

C1~C7은 이 수업이 역산 설계한 7대 역량의 번호다.

같은 지도를 AI 협업 사이클 위에 겹쳐 보면 시험1의 성격이 더 분명해진다. ③ 프롬프트와 ⑤ 테스트는 AI와 컴퓨터가 있어야 돌아가는 블록이므로 시험2와 최종 시험에서 검증한다. 시험1이 겨누는 것은 나머지 세 블록인 ② 분해 · ④ 생성 코드 읽기 · ⑥ 화공 검증이다.

7.2 시험1: 규정과 AI 금지의 논리

시험1은 20점이며, 7주차 실습 시간에 오프라인 지필로 치르고 AI 사용은 전면 금지된다. 범위는 1~6주 누적이다. 문항은 네 유형으로 고정되어 있다. ① 생성 코드 출력 예측, ② EiPE(제시된 AI 생성 코드를 한국어로 목적·동작 설명), ③ AI가 낸 오답을 채점·교정하라(단위 오류·날조 물성 포함), ④ 화공 계산문제의 의사코드 설계. 모든 평가물에 AI 사용내역을 첨부하는 1장의 의무는 시험1에도 그대로 적용된다.

AI 활용 규칙 세 종류 가운데 시험1은 유일한 금지에 해당한다. 시험2(20점, 12주, 90분 현장 실기)와 최종 시험(40점, 2시간 바이브코딩 + GitHub + 구술 방어)은 AI가 필수이고, 과제는 허용이다. 금지 종류가 존재하는 이유는 역설적으로 최종 시험에서 AI를 전면 사용하기 때문이다. AI가 코드를 다 써 주는 시험장에서 중요해지는 것은 생성된 코드를 읽어 내고, 결과가 물리적으로 말이 되는지 판정하고, 문제를 계산 가능한 절차로 쪼개는 개인의 능력이다. 시험1은 그 능력이 실제로 남아 있는지를, AI를 걷어낸 상태에서 따로 검증한다.

낯선 형식은 아니다. 6주차 실습에서 모의 시험1을 무채점으로 치렀고, 오답 리뷰로 자가 진단표를 만들었다. 이 장의 7.3절은 그 진단표 위에 올릴 유형별 처방이다.

7.3 문항 4유형 해부

네 유형을 하나씩 해부한다. 유형마다 실제 시험과 같은 형식의 예시 문항 하나와 모범 답안을 실었다. 예시는 전부 1~6주 범위의 코드와 화공 지식만 사용한다.

7.3.1 유형 ①: 생성 코드 출력 예측

출력 예측은 컴퓨터 없이 스스로 컴퓨터가 되어 보는 문항이다. 인터프리터의 규칙은 단순하다. 코드는 위에서 아래로 한 줄씩 처리되고, 함수가 호출되면 함수 몸통으로 들어갔다가 return에서 호출한 자리로 돌아온다. 이 규칙을 종이 위에서 그대로 따라가면 된다.

예시 문항. 다음 코드가 인쇄하는 출력 전체를 순서대로 쓰라.

def judge(err_pct):              # err_pct: 검증 오차 [%]
    if err_pct < 1:
        return "PASS"
    elif err_pct < 5:
        return "RECHECK"
    else:
        return "FAIL"

errs = [0, 1, 5, 3]              # 도구 4개의 검증 오차 [%]
n_pass = 0
for e in errs:
    r = judge(e)
    if r == "PASS":
        n_pass = n_pass + 1
    print(e, r)
print("passed:", n_pass)

머릿속 실행은 두 번째 반복쯤에서 흔들리기 쉽다. 코드를 한 줄씩 실행한 셈 치고 각 변수의 값 변화를 기록한 표를 트레이스 표(trace table)라 한다. 답안지 여백에 이렇게 그린다.

모범 답안. 출력은 다음 다섯 줄이다.

0 PASS
1 RECHECK
5 FAIL
3 RECHECK
passed: 1

함정은 경계값이다. e = 1에서 1 < 1은 거짓이므로 첫 분기를 통과하지 못하고 elif로 내려간다. e = 5도 같은 이유로 else까지 밀린다. 부등호가 <인지 <=인지를 확인하는 습관이 이 유형에서 큰 비중을 차지한다. 나머지는 출력 형식이다. print(e, r)은 두 값을 공백으로 잇고, 마지막 줄은 passed: 1처럼 문자열 뒤에 값이 붙는다.

7.3.2 유형 ②: EiPE, 코드를 말로 설명하기

코드를 말로 설명하기(Explain in Plain English, EiPE)는 코드를 몇 줄씩 번역하는 문항이 아니다. 코드 전체가 무엇을 하는 물건인지 한 단계 위에서 요약하는 문항이다. 5장에서 좋은 설명과 나쁜 설명의 차이를 봤다. 시험에서도 그 차이가 점수로 이어진다.

예시 문항. 다음 함수의 목적과 동작을 한국어 2~3문장으로 설명하라. 입력과 출력의 단위를 명시하라.

def mole_fractions(masses, mws):
    # masses: 성분별 질량 [g], mws: 성분별 몰질량 [g/mol]
    moles = []
    for i in range(len(masses)):
        moles.append(masses[i] / mws[i])   # [mol]
    total = sum(moles)                     # [mol]
    fracs = []
    for n in moles:
        fracs.append(n / total)            # 무차원
    return fracs

모범 답안(만점). "성분별 질량 리스트[g]와 몰질량 리스트[g/mol]를 받아 각 성분의 몰수를 구한 뒤, 전체 몰수에 대한 비율인 몰분율 리스트를 돌려주는 함수다. 반환값은 무차원이고, 합은 1이 되어야 한다."

0점 답안(실제 유형). "빈 리스트를 만들고, for문으로 masses[i]를 mws[i]로 나눠 moles에 넣고, sum으로 total을 만들고, 다시 for문을 돌아 나눈 값을 fracs에 넣어 반환한다."

두 답안 모두 사실만 적었지만, 뒤의 답안에는 이 함수가 몰분율을 계산한다는 목적이 없다. 줄 번역은 코드를 다시 읽어 주는 일에 가까워 이해의 증거로는 부족하다. 채점 기준은 세 가지다. 목적의 명명(몰분율), 입출력과 단위, 그리고 결과의 성질(합 = 1) 언급이다.

7.3.3 유형 ③: AI 오답 채점·교정

7.3.4 유형 ④: 화공 계산문제의 의사코드 설계

프로그래밍 언어의 문법 대신 사람이 읽는 자연어로 계산 절차를 단계별로 적은 것을 의사코드(pseudocode)라 한다. 유형 ④는 파이썬 문법을 묻지 않는다. 채점 대상은 절차의 완전성이다. 입력·처리·출력이 다 있는가, 예외와 검증이 설계 안에 들어 있는가.

예시 문항. 단위가 kPa, bar, atm으로 섞인 압력 측정값 목록을 받아 전부 kPa로 통일한 뒤, 최댓값과 그 위치를 보고하는 절차를 의사코드로 설계하라. 예외 처리와 검증 단계를 포함하라.

입력: (값, 단위) 쌍의 목록 P                # 예: (95.2, "kPa"), (1.30, "bar")
환산표 F를 정의한다: kPa→1, bar→100, atm→101.325   # kPa 기준
빈 목록 P_kpa를 만든다
P의 각 (v, u)에 대해 반복:
    u가 F에 없으면 → "미지 단위 u" 오류를 보고하고 중단     # 예외 처리
    P_kpa에 v × F[u]를 추가한다              # [kPa]
P_kpa가 비어 있으면 → "데이터 없음"을 보고하고 중단       # 극한(빈 입력)
최댓값 p_max와 위치 i_max를 첫 항목으로 놓고 순회하며 갱신한다
검증: 1 atm 입력이 101.325 kPa로 환산되는지 확인한다      # 대조값
출력: p_max [kPa], i_max

골격은 2장에서 이미 배웠다. 입력 → 처리 → 출력, 그리고 이 수업에서는 검증이 네 번째 고정 단계다. 위 답안에서 점수를 만드는 줄은 세 줄의 방어다. 미지 단위 중단, 빈 목록 처리, 대조값 확인이 그것이다. 물질수지 문제를 풀 때 "마지막에 답을 점검하라"가 절차의 정식 단계이듯이, 의사코드에서도 검증은 하나의 정식 단계다.

7.4 응시 전략: AI 없이 지필에서 이기는 법

7.4.1 시험 전: 인출로 대비한다

4장에서 배운 대로 다시 읽기보다 인출이 효과적이다. 요약본을 훑는 것보다 스스로 답을 꺼내 보는 인출연습(retrieval practice)이 기억을 만든다. 마침 그 도구를 직접 만들어 두었다. 도구② 플래시카드 생성기로 1~6장 위키 노트를 덱으로 바꿔 돌려 보는 것이 실질적인 대비가 된다.

출발점은 모의 시험1의 자가 진단표다. 네 유형 중 어디에서 점수를 잃었는지가 복습 순서를 정한다. 약한 유형은 AI에게 변형 문제를 만들게 해서 보충할 수 있다. 시험장 밖의 대비는 AI 활용 규칙의 허용에 해당한다. 단, 아래 리스팅처럼 답은 받지 않는 것이 요령이다.

7.4.2 시험장에서: 순서와 골격

답안지를 받으면 전 문항을 훑고 자신 있는 유형부터 처리한다. 막히는 문항은 표시하고 넘어간다. 네 유형은 서로 독립이라 순서를 바꿔도 잃는 것이 없다.

유형별 골격은 이미 7.3절에 있다. 출력 예측은 머릿속 실행을 믿지 말고 트레이스 표를 그린다. EiPE는 목적 한 문장을 먼저 쓴다. 목적이 서면 동작과 단위는 따라오고, 거꾸로 줄 번역부터 시작하면 목적 문장을 끝내 못 쓰는 답안이 된다. 채점·교정 문항은 검증 루틴의 순서 그대로 단위, 대조값, 극한값을 훑고, 하나 걸리면 오류 위치·근거·교정값의 3요소를 채운다. 의사코드는 입력→처리→출력→검증의 골격을 먼저 쓰고 살을 붙인다. 백지에서 첫 줄부터 완성하려 들면 시간이 부족해진다.

용어 정리

의사코드(pseudocode)

프로그래밍 언어의 문법 대신 자연어로 계산 절차를 단계별로 적은 표현. 채점 대상은 문법이 아니라 절차의 완전성이다.

트레이스 표(trace table)

코드를 한 줄씩 실행한 셈 치고 각 변수의 값 변화를 기록하는 표. 출력 예측 문항의 기본 도구다.

8.1 증기압: 액체에서 탈출하는 분자들

책상 위에 둔 컵의 물은 끓이지 않아도 며칠이면 줄어든다. 액체 속 분자들의 속도는 제각각이고, 표면 근처의 평균보다 빠른 분자는 이웃 분자가 붙잡는 인력을 이기고 기체로 빠져나간다. 온도가 오르면 이 빠른 분자의 비율이 늘어나므로 탈출도 잦아진다.

이번에는 컵 대신 밀폐 용기를 생각해 보자. 탈출한 분자는 용기 안에 갇혀 있다가 일부는 다시 액면으로 돌아온다. 시간이 지나면 나가는 속도와 돌아오는 속도가 같아지는 상태, 즉 동적 평형(dynamic equilibrium)에 도달한다. 이때 기체가 자신의 액체(또는 고체)와 공존하며 만드는 압력을 증기압(vapor pressure)이라 한다.

증기압은 물질과 온도에만 의존하고, 온도가 오르면 커진다. 물질마다 값이 다른 이유는 분자간 인력의 세기가 다르기 때문이다. 인력이 약한 물질일수록 같은 온도에서 더 많이 탈출하고, 증기압이 높다.

끓음은 이 그림의 특수한 경우다. 액체 내부에서 기포가 자라려면 기포 속 증기의 압력이 외부 압력을 밀어낼 만큼 커야 하므로, p*가 외부 압력과 같아지는 온도에서 액체 전체가 끓는다. 이 온도를 끓는점(boiling point)이라 하고, 외부 압력이 1 atm일 때의 끓는점을 정상 끓는점(normal boiling point)이라 한다. 20 °C의 물도 압력을 0.023 atm 아래로 낮추면 끓는다. 20 °C에서 물의 증기압이 그 값이기 때문이다.

화공 계산에서 증기압은 도처에 나타난다. 저장 탱크의 증발 손실, 용매 회수, 그리고 9장에서 만날 증류가 전부 증기압 곡선 위에서 움직인다. 이 곡선을 온도의 함수로 계산해 주는 것이 이번 주의 도구다.

8.2 Clausius-Clapeyron에서 Antoine으로

증기압이 온도에 따라 어떻게 변하는지는 열역학이 답을 준다. 액체-기체 평형에 열역학 법칙을 적용하면 Clausius-Clapeyron 식이 나오고, 몇 가지 근사를 거친 적분형은 다음과 같다.

ln(p*₂/p*₁) = (ΔH_vap/R)(1/T₁ − 1/T₂) (8.1)

유도는 3학년 열역학에서 만난다. 여기서는 형태에서 읽을 수 있는 것 하나만 가져가자. ln p*는 1/T에 대해 대략 직선이라는 점이다. 그래서 좁은 온도 구간의 증기압 데이터는 다음 꼴로 잘 맞춰진다.

ln p* = A − B/T (8.2)

이때 B는 물리 상수가 아니라 데이터를 맞추기 위한 곡선 맞춤 파라미터다. 실제 데이터는 넓은 구간에서 완전한 직선이 아니므로, 분모에 보정 상수 C를 하나 더 넣어 휘어짐을 흡수한 것이 Antoine 식(Antoine equation)이다.

log₁₀ p* = A − B/(T + C) (8.3)

식 (8.3)은 이론에서 유도된 법칙이 아니라 측정 데이터에 맞춘 경험식(empirical correlation)이다. 이 구별을 이 장 전체에서 계속 쓴다. 법칙은 적용 범위를 물리가 정하지만, 경험식의 적용 범위는 맞춤에 사용한 데이터가 정한다.

8.2.1 Antoine 상수를 읽는 법: 반드시 확인할 네 가지

상수 A, B, C는 물질마다, 그리고 온도 구간마다 다르다. 더 성가신 문제는 출처마다 표기 약속이 다르다는 점이다. NIST WebBook 자료를 정리한 LibreTexts 교재조차 "출처에 따라 온도 단위가 다르거나 log₁₀ 대신 ln을 쓰기도 한다"고 경고를 달아 둔다. 같은 물질의 상수라도 압력이 bar인 표와 mmHg인 표, 온도가 K인 표와 °C인 표가 섞여 돌아다닌다.

그래서 이 책은 Antoine 상수 표에 네 가지(로그 밑, 압력 단위, 온도 단위, 유효 온도범위)를 반드시 명기한다. 표 8-1은 NIST WebBook이 주는 물의 상수다. 같은 물인데 행이 여러 개인 이유가 보이는가? 각 행은 서로 다른 연구진이 서로 다른 온도 구간에서 측정한 데이터에 맞춘 결과이기 때문이다.

NIST 원본에는 이 밖에 두 행(293~343 K, 255.9~373 K)이 더 있다. 행끼리 범위가 겹치기도 하고, 뒤에서 보겠지만 어느 행도 덮지 않는 틈도 있다. 물성 데이터의 실제 모습이 이렇다. 교과서의 매끈한 표 한 줄보다는 출처와 범위가 제각각인 조각들의 모음에 가깝다.

def antoine_p_bar(T_K, A, B, C):
    """Antoine 식: log10(p*) = A - B/(T + C)
    T_K : 온도 [K]
    A, B, C : Antoine 상수 (log10, bar, K 기준 세트)
    반환 : 증기압 p* [bar]
    """
    return 10 ** (A - B / (T_K + C))

# 25 °C = 298.15 K → 273~303 K 행 (Bridgeman & Aldrich, NIST)
p_25 = antoine_p_bar(298.15, 5.40221, 1838.675, -31.737)   # bar
# 373 K → 344~373 K 행
p_100 = antoine_p_bar(373.0, 5.08354, 1663.125, -45.622)   # bar
print(f"25 °C: {p_25:.4f} bar / 373 K: {p_100:.3f} bar")

25 °C: 0.0317 bar / 373 K: 1.008 bar

8.3 유효범위와 외삽: 25% 오차의 해부

예제 8.2-1의 What-if를 실행했다면 373 K에서 0.759 bar를 얻었을 것이다. 장 도입의 0.76 bar가 바로 이것이다. 같은 식, 같은 온도, 같은 NIST 출처의 상수인데 결과가 25% 어긋난다. 379~573 K용 상수를 그 범위 밖인 373 K에 썼기 때문이다.

유효범위 안쪽 온도에서 상관식을 쓰는 일을 내삽(interpolation), 범위 밖으로 벗어나 쓰는 일을 외삽(extrapolation)이라 한다. Antoine 식은 데이터에 맞춘 경험식이므로, 데이터가 없는 구간에서는 아무것도 보증하지 않는다. 범위에서 겨우 6 K 벗어난 373 K에서 이미 25%가 깨졌다. 더 멀리 가면 어떻게 되는가? 같은 행으로 298.15 K를 계산하면 0.0013 bar가 나온다. 올바른 행의 계산값 0.0317 bar의 1/23이다.

이 함정은 문헌에도 그대로 기록되어 있다. LibreTexts 교재는 379~573 K 행으로 100 °C의 물 증기압을 계산해 0.76 bar를 얻고는, 실측 1.013 bar와 25.1% 어긋남을 표로 보여 주며 원인을 유효범위 밖 외삽으로 짚는다. 같은 자료에서 200 °C(473 K, 범위 안)의 계산값 16.53 bar는 실측 15.55 bar와 6.3% 차이였다. 표 8-2에 이 해부 결과를 모았다.

표의 마지막 행이 보여 주듯 범위 안이라고 오차가 0이 되지는 않는다. 상관식은 어디까지나 데이터의 근사이고, 범위 안에서는 오차가 몇 % 수준으로 관리되는 반면 범위 밖에서는 오차의 상한을 말하기 어려워진다.

표 8-1을 다시 보면 더 불편한 사실이 하나 있다. NIST가 주는 물의 행 일곱 개를 전부 모아도 373~379 K 구간을 덮는 행이 없다. 하필 정상 끓는점 373.17 K가 이 틈에 걸린다. 이런 경우의 정직한 태도는 "가장 가까운 행을 쓰되, 몇 K의 외삽이 있었고 오차가 커질 수 있음을 기록에 남긴다"이다. 예제 8.2-1에서 344~373 K 행으로 373 K를 계산한 것이 이 태도에 해당한다.

범위 검사를 함수 안에 넣어 두면 미래의 나와 팀원이 같은 함정에 빠지는 일을 코드가 막아 준다. AI에게 교정을 요구해 보자.

def antoine_p_bar(T_K, A, B, C, t_min, t_max):
    """유효범위 검사가 있는 Antoine 계산.
    T_K [K] 입력, p* [bar] 반환. t_min~t_max [K] = 상수의 유효범위."""
    if not (t_min <= T_K <= t_max):          # 범위 밖 = 외삽 → 거부
        raise ValueError(
            f"T = {T_K} K는 유효범위 {t_min}~{t_max} K 밖이다. "
            "다른 상수 행을 찾거나 출처를 다시 확인하라.")
    return 10 ** (A - B / (T_K + C))

8.4 matplotlib로 증기압 곡선 그리기

수치 하나는 한 점만 검증하지만, 곡선은 경향 전체를 한눈에 검증하게 해 준다. 기울기가 물리적 직관과 맞는 방향인지, 대조점이 곡선 위에 앉는지, 상수 행이 바뀌는 경계에서 곡선이 어긋나지는 않는지가 전부 그래프에서 보인다. 파이썬의 표준 시각화 라이브러리 matplotlib로 시작해 보자.

가장 작은 코드부터 그려 본다.

import numpy as np
import matplotlib.pyplot as plt

A, B, C = 5.08354, 1663.125, -45.622   # 물, 344~373 K 행 (NIST, log10·bar·K)
T = np.linspace(344, 373, 60)          # K — 유효범위 안에서만 생성
p = 10 ** (A - B / (T + C))            # bar

plt.plot(T, p)
plt.show()

곡선은 나왔다. 그런데 이 그림을 일주일 뒤에 다시 열면 가로축이 K인지 °C인지, 세로축이 bar인지 kPa인지 알 길이 없다. 축 라벨과 단위가 없으면 그 그래프는 검증하기 어렵다. 라벨을 달고, 대조점을 함께 찍고, 여러 상수 행을 겹쳐 넓은 온도 구간을 덮도록 개선을 요구해 보자.

rows = [                                   # 물 상수 (log10·bar·K, NIST WebBook)
    (273, 303, 5.40221, 1838.675, -31.737),
    (304, 333, 5.20389, 1733.926, -39.485),
    (334, 363, 5.0768,  1659.793, -45.854),
    (344, 373, 5.08354, 1663.125, -45.622),
]
for t_min, t_max, A, B, C in rows:
    T = np.linspace(t_min, t_max, 60)                    # K
    plt.semilogy(T, 10 ** (A - B / (T + C)), label=f"{t_min}~{t_max} K")

plt.scatter([373.17], [1.013], marker="x", color="k",    # NIST 끓는점 = 대조점
            zorder=3, label="NIST 정상 끓는점")
plt.xlabel("T (K)")
plt.ylabel("p* (bar)")
plt.legend(); plt.grid(True)
plt.savefig("water_vapor_pressure.png", dpi=150)

세로축을 로그로 그린 데는 이유가 있다. 식 (8.2)에서 ln p*가 1/T에 대략 직선이었으므로, 로그 축에서는 곡선이 완만해져 전 구간의 경향과 이탈점이 함께 보인다. 100 K 구간에서 증기압이 30배 넘게 변하므로 선형 축으로는 저온부가 바닥에 붙어 아무것도 읽을 수 없다.

실습 8: 도구⑤ Antoine 증기압 계산기 (45분)

9.1 혼합물의 기액평형과 이상용액

8장에서 다룬 것은 순수한 물질 하나였다. 물질이 하나면 이야기가 단순하다. 주어진 압력에서 끓는 온도는 하나로 정해지고, 그 온도는 Antoine 식으로 계산한 증기압이 외부 압력과 같아지는 지점이다. 액체와 증기가 함께 존재하며 더 이상 겉보기 변화가 없는 상태를 기액평형(vapor-liquid equilibrium, VLE)이라 한다.

혼합물이 되는 순간 변수가 하나 늘어난다. 온도와 압력만이 아니라 조성이 상태를 결정하기 때문이다. 액상에서 성분 A의 몰분율을 x_A, 기상에서의 몰분율을 y_A로 구분해 쓴다. 장 도입의 플라스크에서 액체는 x_벤젠 = 0.5인데 첫 기포는 y_벤젠 = 0.73이었다. 두 값이 다르다는 사실이 이 장 전체의 출발점이다.

9.1.1 분압과 라울의 법칙

기상이 이상기체처럼 거동하면, 성분 i가 전체 압력 P에 기여하는 몫을 분압(partial pressure) p_i라 하고 다음이 성립한다.

p_i = y_i P (9.1)

이제 액상 쪽을 보자. 액체 혼합물 위의 증기에서 각 성분이 얼마나 증발해 나오는가. 분자 수준에서 서로 밀고 당기는 힘이 비슷한 분자들의 혼합물을 이상용액(ideal solution)이라 한다. 구조나 작용기가 닮은 물질끼리 섞였을 때가 대표적이고, 둘 다 무극성이며 크기가 비슷한 벤젠-톨루엔이 교과서적인 예다. 벤젠 분자 입장에서는 이웃이 벤젠이든 톨루엔이든 받는 힘이 비슷하므로, 증발해 나가려는 경향은 순수 벤젠일 때와 같고 다만 표면을 차지한 비율만큼 줄어든다.

이 직관을 식으로 쓴 것이 라울의 법칙(Raoult's law)이다. 이상용액에서 성분 i의 분압은 그 성분의 액상 몰분율에 순수 증기압을 곱한 값이 된다.

p_i = x_i p*_i(T) (9.2)

여기서 p*_i(T)는 온도 T에서 순수한 성분 i의 증기압이고, 8장의 Antoine 식으로 계산하는 바로 그 양이다. 식 (9.1)과 식 (9.2)에서 분압을 소거하면 기상 조성과 액상 조성을 잇는 평형 관계를 얻는다.

y_i P = x_i p*_i(T) (9.3)

전체 압력은 분압의 합이므로, 이성분계(성분 A, B)에서 식 (9.2)를 더하면 전압이 나온다.

P = x_A p*_A(T) + (1 − x_A) p*_B(T) (9.4)

라울의 법칙은 언제 믿을 수 있는가. 두 성분의 분자 간 상호작용이 충분히 닮았을 때, 그리고 각 성분이 무시할 수 없는 양으로 존재할 때다. 에탄올-물처럼 수소결합이 강하게 개입하는 계는 이 가정에서 멀어진다. 이 장의 도구는 이상용액 가정 위에 서 있으므로, 어떤 물질 쌍에 적용할지 자체가 공학적 판단임을 기억해 두자.

9.1.2 Antoine 상수 준비: 8장 도구의 재사용

식 (9.3)의 p*_i(T)를 계산하려면 두 성분의 Antoine 상수가 필요하다. 이 장의 예제는 전부 벤젠-톨루엔 계를 쓰며, 상수는 표 9-1과 같다.

표 9-1 벤젠·톨루엔의 Antoine 상수: log₁₀(p*/bar) = A − B/(T/K + C) 형식

유효범위 칸을 비워 두지 않고 "직접 확인하라"고 적은 데는 이유가 있다. 이 상수의 수록 출처(LibreTexts, NIST 인용)가 유효 온도범위를 함께 싣지 않았기 때문이다. 8장에서 유효범위 밖 외삽이 25% 오차를 만드는 것을 보았다. 범위가 명시되지 않은 상수는 범위를 찾아내는 것까지가 사용자의 일이며, 이번 실습의 첫 단계가 바로 그 확인 작업이다.

9.2 기포점과 이슬점: 반복을 없애는 발상

액체 혼합물을 일정한 압력에서 가열할 때 첫 기포가 생기는 조건을 기포점(bubble point)이라 한다. 반대로 증기 혼합물을 냉각할 때 첫 액체 방울이 맺히는 조건을 이슬점(dew point)이라 한다. 순수 물질이라면 둘은 같은 온도(끓는점)지만, 혼합물에서는 기포점과 이슬점이 서로 다른 온도가 된다. 장 도입의 반반 혼합물은 363 K에서 끓기 시작해 371 K이 되어서야 마지막 액체 방울이 사라진다.

9.2.1 온도가 주어지면 직접 계산이다

온도를 알고 압력을 구하는 문제는 반복이 필요 없다. 기포점에서는 액상 조성이 전체 조성과 같으므로(증기가 아직 거의 없다), 식 (9.4)에 대입만 하면 기포 압력이 나온다. 이슬점 쪽도 마찬가지다. 식 (9.3)을 x_i = y_iP/p*_i로 정리하고 액상 몰분율의 합이 1이라는 조건을 쓰면 다음을 얻는다.

1/P = y_A/p*_A + y_B/p*_B (9.5)

식 (9.4)는 기포 압력, 식 (9.5)는 이슬 압력을 대입 한 번으로 준다. 두 식의 생김새를 눈에 담아 두자. 기포 쪽은 증기압의 가중 산술평균, 이슬 쪽은 역수의 가중합이다. 뒤에서 AI가 이 둘을 뒤바꾸는 사고를 다룬다.

9.2.2 온도를 구하는 문제는 왜 성가신가

실무에서 더 흔한 질문은 반대 방향이다. "압력이 1 atm으로 고정돼 있을 때 이 혼합물은 몇 도에서 끓는가?" 이번에는 T가 미지수인데, T는 Antoine 식의 지수 안에 두 번 들어가 있어 식 (9.4)를 T에 대해 대수적으로 풀 수 없다. 고전적인 처방은 시행착오다. 온도를 추측하고, 그 온도에서 y_i를 계산해 합을 확인하고, 합이 1이 될 때까지 추측을 고친다.

9.2.3 문제를 뒤집으면 반복이 사라진다

시행착오가 필요했던 이유는 T를 미지수로 두었기 때문이다. 그렇다면 T를 미지수가 아니라 입력으로 만들면 된다. "조성 x가 주어졌을 때 끓는 온도 T를 찾아라" 대신 "온도 T가 주어졌을 때 그 온도에서 끓는 조성 x를 찾아라"라고 묻는 것이다. 식 (9.4)를 x_A에 대해 풀면 나눗셈 한 번짜리 공식이 나온다.

x_A(T) = (P − p*_B(T)) / (p*_A(T) − p*_B(T)) (9.6)

그 온도의 기상 조성도 식 (9.3)에서 바로 따라온다.

y_A(T) = x_A(T) p*_A(T) / P (9.7)

정말 맞는지 확인해 보자. T = 363 K를 식 (9.6)에 넣으면 x_벤젠 = (1.013 − 0.540)/(1.484 − 0.540) = 0.501이다. 예제 9.2-1에서 시행착오로 찾은 "x = 0.5의 기포점이 363 K"와 정확히 같은 사실을 이번에는 반복 없이 얻었다. 같은 문제의 두 표현인데 한쪽은 반복이 필요하고 다른 쪽은 대입 한 번으로 끝난다.

두 순수 끓는점 사이에서 T를 촘촘히 훑으며(이를 온도 스윕이라 부르자) 식 (9.6)·(9.7)을 계산하면, (x, T) 점들의 모음과 (y, T) 점들의 모음이 생긴다. 이 두 곡선이 바로 다음 절의 T-xy 다이어그램이다. 특정 조성의 기포점이 필요하면 곡선에서 보간으로 읽으면 되므로, 반복 계산은 끝까지 등장하지 않는다.

9.3 T-xy 다이어그램: 읽는 법과 그리는 법

고정된 압력에서 온도를 세로축에, 조성을 가로축에 놓고 기포점 곡선과 이슬점 곡선을 함께 그린 그림을 T-xy 다이어그램이라 한다. 가로축 하나에 액상 몰분율 x와 기상 몰분율 y를 같이 표시하기 때문에 붙은 이름이다. 이 그림 한 장에는 그 압력에서 그 혼합물이 보일 수 있는 모든 끓음·응축 거동이 들어 있다.

9.3.1 세 영역과 두 곡선

두 곡선은 그림을 세 영역으로 가른다. 아래쪽은 전부 액체인 영역, 위쪽은 전부 증기인 영역, 두 곡선 사이가 액체와 증기가 공존하는 기액평형 영역이다. 액체가 낮은 에너지 상태이므로 저온 쪽이 액체 영역인 것은 당연하다. 기포점들을 이은 아래 곡선을 포화 액체선(saturated liquid line), 이슬점들을 이은 위 곡선을 포화 증기선(saturated vapor line)이라 하며, 포화 증기선은 언제나 포화 액체선 위에 있다. 온도가 높을수록 증기 쪽이 유리하기 때문이다.

그림의 양 끝은 순수 물질이다. x = 1(순수 벤젠)에서 두 곡선은 벤젠의 끓는점 약 349 K에서 만나고, x = 0(순수 톨루엔)에서는 약 383 K에서 만난다. 순수 물질은 기포점과 이슬점이 같으므로 두 곡선이 한 점으로 모이는 것이다. 이 성질은 잠시 뒤 코드 검증의 극한값 체크로 그대로 쓰인다.

기액평형 영역 안의 한 점, 예컨대 전체 조성 0.5인 혼합물을 두 곡선 사이의 온도까지 가열한 상태를 보자. 이 점에서 수평선을 그으면(같은 온도에서 액체와 증기가 공존하므로) 포화 액체선과 만나는 점의 가로좌표가 액상 조성 x, 포화 증기선과 만나는 점의 가로좌표가 기상 조성 y다. 이 수평선을 tie line이라 부른다.

9.3.2 두 상의 양은 얼마인가: 지렛대 규칙

tie line은 조성만이 아니라 양도 알려 준다. 전체 조성을 z라 하면 벤젠에 대한 물질수지 x·n_액 + y·n_기 = z·n_전체에서 다음을 얻는다.

n_액/n_전체 = (z − y) / (x − y) (9.8)

전체 조성 점에서 각 곡선까지의 거리 비로 두 상의 양이 갈린다고 해서 지렛대 규칙(lever rule)이라 한다. 예를 들어 z = 0.5인 혼합물이 어느 온도에서 x ≈ 0.39, y ≈ 0.62로 갈라졌다면 액체 분율은 (0.5 − 0.62)/(0.39 − 0.62) ≈ 0.52, 대략 절반씩이다. 전체 조성 점이 어느 곡선에 가까울수록 그 상이 많다. 기포점 직후에는 점이 포화 액체선에 붙어 있으니 계는 거의 전부 액체다.

9.3.3 그리는 법: 온도 스윕 알고리즘

9.2.3절의 발상을 그대로 절차로 옮기면 T-xy 다이어그램 작도 알고리즘이 된다. 반복문은 있지만 수렴 판정은 없다. 모든 단계가 대입 계산이다.

1. 두 순수 성분의 끓는점을 구해 스윕 구간 [T_{낮은 끓는점}, T_{높은 끓는점}]을 정한다.
2. 구간을 잘게 나눈 온도 배열을 만든다.
3. 각 온도에서 두 성분의 증기압을 Antoine 식으로 계산한다.
4. 식 (9.6)으로 x, 식 (9.7)로 y를 계산한다.
5. (x, T)를 포화 액체선으로, (y, T)를 포화 증기선으로 그린다.

이 절차를 AI에게 시켜 도구⑥의 뼈대를 만들어 보자.

import numpy as np
import matplotlib.pyplot as plt
from vapor_pressure import antoine_p_bar  # 도구⑤(8장) 재사용

# Antoine 상수 (log10 / bar / K) — 출처: NIST WebBook
BENZENE = (4.60362, 1701.073, 20.806)
TOLUENE = (4.07827, 1343.943, -53.773)
P = 1.013  # bar (= 1 atm)

T = np.linspace(349.2, 383.8, 200)     # K, 두 순수 끓는점 사이
p_b = antoine_p_bar(T, *BENZENE)    # bar, 벤젠 증기압
p_t = antoine_p_bar(T, *TOLUENE)    # bar, 톨루엔 증기압

x = (P - p_t) / (p_b - p_t)            # 식 (9.6), 무차원
y = x * p_b / P                        # 식 (9.7), 무차원

plt.plot(x, T, label="포화 액체선 (기포점)")
plt.plot(y, T, label="포화 증기선 (이슬점)")
plt.xlabel("벤젠 몰분율 x, y")
plt.ylabel("온도 T [K]")
plt.title("벤젠-톨루엔 T-xy (P = 1.013 bar)")
plt.legend()
plt.grid(True)
plt.savefig("txy_benzene_toluene.png", dpi=150)

특정 조성의 기포점 온도가 숫자로 필요하면 곡선을 보간해 읽으면 된다. np.interp는 x 배열이 증가 순서일 때 동작하므로, 감소 순서인 배열은 뒤집어 넣는다.

# x = 0.5의 기포점 온도를 보간으로 조회 (x는 T 증가에 따라 감소하므로 뒤집는다)
T_bubble = np.interp(0.5, x[::-1], T[::-1])   # K
print(f"기포점 온도: {T_bubble:.1f} K")        # 363.0 K 부근이 나와야 한다

출력이 363.0 K 부근이면 예제 9.2-1과 교차 검증이 끝난 것이다. 시행착오 없이, solver 없이, 배열 두 개와 보간 한 줄로 같은 답에 도달했다.

9.4 AI와 함께 만들 때: 두 공식을 뒤바꾸는 AI

기액평형 계산을 AI에게 시킬 때 좋은 프롬프트와 나쁜 프롬프트의 차이는 9.3.3절에서 이미 드러났다. "T-xy 다이어그램 그려 줘"라고만 하면 AI가 알고리즘 선택(시행착오냐 스윕이냐), 단위, 상수 출처를 전부 스스로 정하고, 그 선택들 하나하나가 검증해야 할 짐이 된다. 식 번호·단위·함수 이름을 지정한 프롬프트는 검증할 것을 "문법이 맞는가" 수준으로 줄여 준다.

그래도 검증을 건너뛸 수는 없다. 기포점과 이슬점처럼 짝을 이루는 개념은 AI가 특히 자주 뒤섞는 지점이기 때문이다.

이 사례가 보여 주는 교훈은 3장의 원칙 그대로다. 실행되는 코드와 옳은 코드는 다르며, 그 간극을 메우는 것은 화공 지식으로 만든 테스트다. 기액평형 도구에서는 "이슬점 ≥ 기포점", "몰분율 합 = 1", "순수 극한에서 끓는점 일치" 세 가지가 언제나 쓸 수 있는 물리 테스트다.

10.1 시스템 경계와 흐름도 라벨링

물 1 L를 깔때기에 부어 플라스크로 흘려보낸다. 깔때기에 처음 물이 없었고 부은 1 L가 전부 빠져나갔다면, 깔때기에 남은 물은 얼마인가. 답은 0 L다. 이 답은 깔때기의 크기나 벽면의 기울기와 무관하다. 들어간 양과 나온 양만 알면 내부 구조를 몰라도 결론이 나온다.

이 하찮은 예제가 물질수지의 뼈대 전부다. 관심 영역을 정해 두고 그 안팎으로 드나드는 질량을 장부에 적는 계산을 물질수지(material balance)라 한다. 그리고 관심 영역을 둘러싸는 가상의 닫힌 면을 시스템 경계(system boundary)라 한다. 경계를 어디에 긋는가에 따라 같은 공정에서도 전혀 다른 식이 나오는데, 이 선택의 자유를 10.3절에서 재순환 문제를 푸는 데 그대로 쓴다.

경계를 그었으면 장부의 계정은 다섯 개다. 들어온 것, 나간 것, 안에서 생긴 것, 안에서 없어진 것, 그리고 그 결과로 쌓인 것이다. 이를 한 줄로 쓰면 일반 수지식을 얻는다.

축적 = 입력 − 출력 + 생성 − 소멸 (10.1)

생성과 소멸은 화학반응의 몫이다. 이 장에서는 반응이 없는 공정만 다루므로 두 항은 0이다. 여기에 조업 조건이 시간이 지나도 변하지 않는 상태, 곧 정상상태(steady state)를 가정하면 축적도 0이 되어 식은 가장 단순한 형태로 줄어든다.

입력 = 출력 (10.2)

10.1.1 흐름도 라벨링: 문제의 절반

서술형 문제를 받으면 식보다 그림이 먼저다. 문장 속에 흩어진 장치와 흐름을 종이 위의 흐름도로 옮기는 작업을 라벨링이라 부르며, 순서는 다음과 같다.

• 문제에 나온 공정마다 이름을 붙인다(혼합기 A, 분리기 B 순으로).
• 모든 스트림에 번호를 붙이고, 유량은 ṁ₁처럼 스트림 번호를 첨자로 단다.
• 주어진 값이든 미지수든 전부 흐름도에 적는다(단위를 반드시 포함한다).
• 부피 유량은 질량 유량과 구별되게 표시해 둔다.

마지막 항목이 함정이다. 질량과 달리 부피에는 대부분의 경우 보존 법칙이 없다. 부피 유량이 주어지면 밀도를 곱해 질량 유량으로 환산한 뒤에 수지식에 넣어야 하며, "부피 보존" 식을 세우면 그 시점에서 답이 틀어진다.

미지수를 세는 규칙도 여기서 정해진다. 성분이 C개인 스트림의 독립 미지수는 C개다. 질량분율 C−1개와 총유량 1개다. 분율의 합이 1이므로 마지막 분율은 나머지에서 자동으로 정해지지만, 총유량은 분율만으로는 알 수 없기 때문이다.

10.2 자유도 분석: 풀리는 문제인지 먼저 판정한다

식을 다 세우고 연립을 반쯤 풀고 나서야 "안 풀리는 문제였다"를 아는 것은 가장 늦은 발견이다. 계산을 시작하기 전에 미지수 개수와 독립 방정식 개수를 세어 비교하면 풀리는 문제인지 미리 알 수 있다. 이 차이를 자유도(degree of freedom, DOF)라 한다.

DOF = 미지수 개수 − 독립 방정식 개수 (10.3)

판정은 세 갈래다. 자유도가 0이면 미지수를 유한한 해로 결정할 수 있는 적정지정(well-defined) 문제다. 0보다 크면 정보가 모자라는 과소지정(underspecified), 0보다 작으면 정보가 남거나 서로 모순일 수 있는 과잉지정(overspecified)이다.

방정식으로 셀 수 있는 것은 성분별 수지만이 아니다. 분리 효율 같은 공정 사양, 조성 사이의 관계식, 문제 서술이 주는 추가 정보도 모두 방정식 한 건으로 친다. 단, 서로 독립일 때만 센다. "들어온 A의 60 %가 스트림 2로 간다"와 "A의 40 %가 스트림 3으로 간다"는 같은 정보의 앞뒷면이므로 한 건이다.

이 판정을 포함한 풀이 절차 전체가 화공양론 교재(Felder & Rousseau)가 정식화한 체계적 풀이 프로토콜이다. 순서는 흐름도 작성 → 라벨링 → 자유도 분석 → 풀이 계획 수립 → 계산이다. 이 다섯 단계는 그 자체로 하나의 알고리즘이며, 이 장의 제목에 있는 "알고리즘화"는 numpy 이전에 여기서 시작한다. 코드로 옮기는 것은 마지막 두 단계뿐이고, 앞의 세 단계는 사람의 몫으로 남는다.

10.2.1 다중 유닛 시스템의 자유도

장치가 여러 개면 유닛마다 자유도 분석을 한 뒤 합산한다. 그리고 두 장치 사이를 잇는 중간 스트림의 변수 개수를 합계에서 뺀다. 중간 스트림은 나가는 장치에서 한 번, 들어가는 장치에서 한 번, 두 번 세어졌기 때문이다. 이렇게 얻은 수가 시스템 전체의 자유도다.

자유도가 0으로 판정되면 풀이 계획은 기계적으로 나온다. 자유도가 0인 유닛(또는 유닛 조합)을 찾아 그 미지수를 먼저 계산하고, 계산된 값을 기지수로 바꿔 나머지 유닛의 자유도를 다시 센다. 어딘가가 새로 0이 되면 거기를 풀고, 구하려는 값이 전부 나올 때까지 반복한다.

10.3 재순환과 퍼지: 되돌아오는 흐름의 회계

분리가 한 번에 충분하지 않으면 덜 분리된 흐름을 공급 쪽으로 되돌려 다시 통과시킨다. 이렇게 공정 출구의 일부를 상류로 되돌리는 흐름을 재순환(recycle)이라 한다. 재순환이 붙으면 흐름도에 새 교차점이 두 개 생긴다. 스트림이 갈라지는 지점을 분기점(splitting point), 신선 공급과 재순환 흐름이 만나는 지점을 합류점(recombination point)이라 한다.

스트림 1 ──▶ [합류점] ──▶ ┌────────┐ ──▶ 스트림 2 (상부 생성물)
(신선 공급)      ▲   스트림 4 │ 분리기 │
                │            └────────┘
                │                 │ 스트림 3 (하부)
                │                 ▼
                └──────────── [분기점] ──▶ 스트림 6 (하부 생성물)
                  스트림 5 (재순환)
  

재순환 시스템의 회계 규칙은 세 가지다. 첫째, 분기점과 합류점도 자유도 분석에서는 하나의 공정으로 센다. 다른 어디에서도 세어지지 않는 미지수를 갖기 때문이다. 둘째, 분기점에서 갈라진 두 흐름은 조성이 같다. 이 조성 동일 조건이 방정식 1건이 되고, 분기비(얼마를 되돌리는가)가 주어지면 또 1건이 된다. 셋째, 합류점에서는 이런 추가 방정식이 나오지 않는다. 조성이 다른 두 흐름이 섞이므로 출구 조성은 수지를 풀어야 나온다.

둘째 규칙에는 함정이 하나 붙어 있다. 자유도 분석이 끝나기 전에는 갈라진 두 흐름의 조성을 같은 변수로 라벨링하지 마라. 같다고 적어 버리는 순간 그 정보를 이미 써 버린 것이라, 방정식 수를 셀 때 이중으로 세거나 빠뜨리기 쉽다. 미지수는 미지수대로 두고, 정보는 정보대로 세는 것이 안전하다.

풀이 계획에서는 10.1절의 경계 선택이 그대로 쓰인다. 경계를 시스템 전체에 그은 총괄수지(overall balance)를 세우면 재순환 스트림은 경계를 드나들지 않으므로 식에서 아예 사라진다. 재순환의 조성이 미지수일 때 이 요령 하나가 계산량을 크게 줄이며, 재순환 문제는 대개 총괄수지에서 출발하는 것이 좋다.

그림 10-1의 시스템(성분 2개)에 10.2절의 다중 유닛 절차를 적용해 보자. 합류점은 미지수 6 − 수지 2 = 4 DOF, 분리기는 미지수 6 − 수지 2 − 분리 사양 2 = 2 DOF, 분기점은 미지수 6 − 수지 2 − 조성 동일 1 − 분기비 1 = 2 DOF다. 신선 공급이 지정되면 합류점은 4가 아닌 2 DOF가 되고, 세 교차점의 합 2 + 2 + 2에서 중간 스트림 변수 6을 빼면 시스템 자유도는 0이다. 문제는 풀린다. 손으로 풀면 대입이 여러 겹이지만, 10.4절에서 행렬로 한 번에 처리한다.

10.3.1 퍼지: 루프의 배출구

재순환 루프에서 일부를 계 밖으로 뽑아 버리는 흐름을 퍼지(purge)라 한다. 반응 공정에서 원료에 섞여 들어온 비활성 성분은 반응으로도 분리로도 없어지지 않아 루프를 돌며 쌓이는데, 퍼지는 이 축적을 막는 배출구 역할을 한다. 수지 회계의 관점에서 퍼지는 분기점이 하나 늘어나는 것과 같다. 10.4절의 행렬에 행이 몇 줄 더해질 뿐, 새 이론은 필요 없다. 반응이 얽힌 퍼지의 정량 설계는 화공양론 수업의 몫으로 남긴다.

10.4 연립선형방정식의 행렬 표현과 numpy 풀이

수지식을 코드로 넘기기 전에 미지수 선택부터 손봐야 한다. (총유량, 분율) 쌍을 미지수로 쓰면 식마다 ṁ₂x_A2 같은 곱이 나타난다. 미지수끼리의 곱은 1차식이 아니므로, 이대로는 이 절의 도구를 쓸 수 없다.

해법은 미지수를 바꿔 잡는 것이다. 스트림 속 한 성분의 질량 유량을 통째로 하나의 미지수로 잡은 것을 성분 유량(component flow rate)이라 한다. 스트림 2의 A 성분 유량을 A₂라 쓰면 ṁ₂x_A2가 곱이 아니라 A₂ 하나가 되고, 무반응 물질수지는 전부 미지수의 덧셈과 상수배만 남는다. 이런 방정식을 선형(linear) 방정식이라 하며, 여러 개를 묶은 것이 연립선형방정식이다.

선형 연립방정식은 표준형이 있다. 계수만 뽑아 정사각 표로 모은 것을 계수 행렬(coefficient matrix) A, 미지수를 세로로 쌓은 것을 벡터 x, 우변 상수를 벡터 b라 하면 연립 전체가 한 줄이 된다.

Ax = b (10.4)

numpy가 푸는 것이 정확히 이 형태다. 작은 3원 연립으로 손을 먼저 풀어 보자.

import numpy as np

# 연립방정식 (Kreyszig, Advanced Engineering Mathematics 9판, 7.3절 예제)
#   x1 -  x2 +   x3 = 0
#       10*x2 + 25*x3 = 90
# 20*x1 + 10*x2        = 80
A = np.array([[ 1, -1,  1],
              [ 0, 10, 25],
              [20, 10,  0]])
b = np.array([0, 90, 80])

x = np.linalg.solve(A, b)   # 해 벡터
print(x)

[2. 4. 2.]

해가 나왔다. 그런데 이 해가 정말 방정식을 만족하는지 코드로 검증하려다 보면 첫 함정을 만난다.

print(A @ x)            # A와 x의 행렬곱 — b와 같아야 한다
print(A @ x == b)       # 원소별 비교
print(np.allclose(A @ x, b))  # 허용 오차 안에서의 비교

[2.66453526e-15 9.00000000e+01 8.00000000e+01]
[False  True  True]
True

첫 성분은 0이어야 하는데 2.7 × 10⁻¹⁵가 나왔고, 그래서 원소별 비교의 첫 칸이 False다. 컴퓨터의 실수 연산에는 이 정도의 오차가 항상 붙는다. 따라서 수치 해의 등호 검증에는 == 대신 허용 오차 안 비교인 np.allclose를 쓴다. 검증 루틴을 코드로 옮길 때의 표준 관례다.

import numpy as np

# 미지수 x = [A2, B2, A3, B3, A4, B4]  # 전부 kg/h (성분 유량)
A_mat = np.array([
    [0, 0, -0.5,  0,    1,    0  ],  # 합류점 A 수지: A4 - 0.5*A3 = 50
    [0, 0,  0,   -0.5,  0,    1  ],  # 합류점 B 수지: B4 - 0.5*B3 = 50
    [1, 0,  0,    0,   -0.6,  0  ],  # 분리 사양 A: A2 = 0.6*A4
    [0, 1,  0,    0,    0,   -0.5],  # 분리 사양 B: B2 = 0.5*B4
    [1, 0,  1,    0,   -1,    0  ],  # 분리기 A 수지: A2 + A3 = A4
    [0, 1,  0,    1,    0,   -1  ],  # 분리기 B 수지: B2 + B3 = B4
])
b = np.array([50, 50, 0, 0, 0, 0])   # kg/h (신선 공급의 성분 유량)

x = np.linalg.solve(A_mat, b)
print(x)

[37.5        33.33333333 25.         33.33333333 62.5        66.66666667]

A2, B2, A3, B3, A4, B4 = x
m2  = A2 + B2               # kg/h, 상부 생성물 총유량
xA2 = A2 / m2               # 상부 생성물의 A 질량분율
m6  = 0.5 * (A3 + B3)       # kg/h, 하부 생성물(스트림 3의 절반)
xA6 = 0.5 * A3 / m6         # 하부 생성물의 A 질량분율

print(m2, xA2)              # 70.83..., 0.529...
print(m6, xA6)              # 29.16..., 0.428...
print(m2 + m6)              # 100.0 — 총괄 질량 보존
print(np.allclose(A_mat @ x, b))  # True — 해가 방정식을 만족

실습 10: 도구⑦ 물질수지 solver (75분)

이번 실습은 75분 타이머로 진행하는 mini practical이며, 종료 후 공개 지목 구술이 있다. 학번별 파라미터 생성기가 배부한 재순환 공정 문제를 받아, 자유도 분석에서 검증 기록까지 한 번에 완주한다.

11.1 레이놀즈 수: 층류와 난류

수도꼭지를 아주 조금만 열면 물줄기가 유리 막대처럼 매끈하게 떨어진다. 조금 더 열면 어느 순간 물줄기가 흐트러지고 표면이 거칠어진다. 같은 물, 같은 꼭지인데 흐름의 상태가 다르다.

앞의 매끈한 흐름처럼 유체가 층을 이루어 가지런히 미끄러지는 상태를 층류(laminar flow)라 한다. 뒤의 거친 흐름처럼 크고 작은 소용돌이가 뒤섞이며 나아가는 상태를 난류(turbulent flow)라 한다. 배관 안에서도 같은 두 상태가 나타나는데, 마찰로 잃는 압력의 계산법이 상태에 따라 완전히 달라진다. 그래서 압력강하 계산의 첫 단계는 언제나 "지금 흐름이 어느 쪽인가"라는 판별이다.

판별 기준은 무차원수 하나로 요약된다. 관 내 흐름에서 레이놀즈 수(Reynolds number, Re)를 다음과 같이 정의한다.

Re = ρ·v·D / μ (11.1)

여기서 ρ는 유체 밀도[kg/m³], v는 평균 유속[m/s], D는 관 내경[m], μ는 점도[Pa·s]다. 분자 ρvD는 유체가 하던 대로 밀고 나가려는 관성의 크기에, 분모 μ는 흐트러짐을 눌러 가지런히 만들려는 점성의 크기에 대응한다. 관성이 이기면 난류, 점성이 이기면 층류다.

정의했으면 단위부터 검산해 보자(검증 루틴 1종인 단위 체크다). Pa·s = kg/(m·s)이므로 식 (11.1)의 단위는

(kg/m³) · (m/s) · (m) / (kg/(m·s)) = 1

분자와 분모가 남김없이 지워진다. Re는 단위가 없는 무차원수다. 계산 결과에 단위가 남는다면 식을 잘못 옮긴 것이다.

경계값은 어디인가. 관 내 흐름에서는 Re < 2320이면 층류로, Re > 2320이면 난류로 판정한다. 임계값으로 2100을 쓰는 문헌도 있다. 실제 전이는 칼로 자르듯 일어나지 않기 때문에 문헌마다 관례가 조금씩 다르다. 이 책은 2320 기준으로 통일하고, 코드에 판별을 넣을 때는 어느 값을 썼는지 주석으로 남긴다.

11.2 Darcy-Weisbach 식: 마찰로 잃는 압력

유체가 관 벽을 스치며 흐르면 벽에는 흐름을 거스르는 마찰력이 걸린다. 이 마찰을 이기느라 흐름 방향을 따라 압력이 조금씩 낮아지는데, 길이 L인 구간에서 잃는 압력을 압력강하(pressure drop) Δp라 한다. 펌프는 정확히 이 값만큼을 보충해야 하므로, 압력강하 계산이 그대로 펌프 사양 계산이 된다.

관 내 흐름의 압력강하는 Darcy-Weisbach 식으로 계산한다.

Δp = λ · (L/D) · ρv²/2 (11.2)

식을 한 항씩 해부해 보자. ρv²/2는 흐르는 유체의 운동에너지를 압력 단위로 나타낸 양으로, 동압(dynamic pressure)이라 부른다. 단위를 확인하면 (kg/m³)·(m²/s²) = kg/(m·s²) = Pa로, 정확히 압력이다. L/D는 관이 지름의 몇 배만큼 긴가를 나타내는 무차원 기하 인자다. 길수록 마찰 구간이 길어 손실이 커지고, 굵을수록 벽의 영향이 옅어져 손실이 작아진다.

남는 것은 λ 하나다. 벽 마찰의 세기를 담는 이 무차원 계수를 마찰계수(friction factor)라 하고, 식 (11.2) 규약의 것을 특히 Darcy 마찰계수(Darcy friction factor)라 부른다. 식 (11.2)의 다른 항은 전부 문제 조건에서 바로 나오므로, 이 장의 나머지는 사실상 λ를 구하는 이야기다.

그런데 문헌에는 마찰계수가 두 종류 있다. 벽 전단응력을 동압으로 나눈 비를 Fanning 마찰계수(Fanning friction factor) f_F라 하는데, 같은 물리를 다르게 정규화했을 뿐이라 두 계수는 정확히 4배 관계다.

λ = 4·f_F (11.3)

층류 마찰계수가 Darcy 규약에서 64/Re, Fanning 규약에서 16/Re로 적히는 것이 이 4배의 흔적이다. 어느 쪽도 틀린 규약이 아니지만, 둘을 섞어 쓰면 계산이 어긋난다. Fanning 값 f_F를 식 (11.2)에 넣으면 압력강하가 4배 작게 나오고, 그 값으로 고른 펌프는 4배 모자란다. 문헌·웹·AI 출력에서 마찰계수를 만나면 "층류식이 64/Re인가 16/Re인가"부터 확인한다. §11.4에서 AI가 정확히 이 지점에서 엇갈리는 사례를 본다.

11.3 마찰계수: Colebrook 식에서 Moody 선도까지

11.3.1 층류: 반복이 필요 없는 영역

층류(Re < 2320)의 마찰계수는 Poiseuille의 결과로 닫힌 식이 알려져 있다.

λ = 64 / Re (11.4)

식 (11.4)를 식 (11.2)에 대입하면 Δp = 32·μ·L·v/D²을 얻는다. 층류의 압력강하는 유속에 정비례하고, 밀도와 무관하며, 점도에 비례한다. 관성이 아니라 점성이 지배하는 영역답다.

11.3.2 난류: 조도가 등장한다

난류가 되면 사정이 복잡해진다. λ가 Re뿐 아니라 관 벽이 얼마나 거친가에도 의존하기 때문이다. 벽 요철의 대표 높이 ε[m]을 절대조도(absolute roughness), 그것을 관 지름으로 나눈 무차원비 ε/D를 상대조도(relative roughness)라 한다. 조도 값은 관의 재질과 상태에 따라 다르며 유체역학 교재나 제조사 자료의 표에서 조회한다(이 장의 문제에서는 조건으로 준다).

난류 마찰계수의 표준 관계식은 Colebrook-White 식(1937)이다.

λ = 1 / [ 2·log₁₀( 2.51/(Re·√λ) + 0.27·ε/D ) ]² (11.5)

식 (11.5)를 잘 보면 이상한 점이 있다. 구하려는 λ가 우변 안에도 들어 있다. 이렇게 미지수를 좌변에 홀로 남기도록 대수적으로 풀 수 없는 식을 암시적 식(implicit equation)이라 하고, 답은 반복 계산으로 얻는다. 방법은 10장의 연립방정식 풀이보다 오히려 단순하다. 적당한 초기값을 우변에 넣어 새 λ를 얻고, 그 값을 다시 우변에 넣는 일을 값이 더 변하지 않을 때까지 되풀이한다. 이를 고정점 반복(fixed-point iteration)이라 한다.

import math

Re = 1.11e5         # 무차원 (예제 11.1-1의 난류 조건)
rel_rough = 0.001   # 무차원 (상대조도 ε/D)

lam = 0.02          # 초기 추측값 — Moody 선도 세로축의 중간쯤
for i in range(6):
    rhs = 2.51 / (Re * math.sqrt(lam)) + 0.27 * rel_rough
    lam = 1.0 / (2 * math.log10(rhs))**2
    print(f"{i+1}회: lam = {lam:.6f}")

실행하면 네 번째 반복부터 소수 여섯째 자리까지 값이 멈춘다.

1회: lam = 0.022057
2회: lam = 0.021955
3회: lam = 0.021960
4회: lam = 0.021960
5회: lam = 0.021960
6회: lam = 0.021960

초기값이 아무 값이나 되는 것은 아니다. lam = 0.0으로 시작하면 √λ = 0으로 나누게 되어 다음 에러가 그대로 난다.

Traceback (most recent call last):
  File "colebrook.py", line 8, in <module>
    rhs = 2.51 / (Re * math.sqrt(lam)) + 0.27 * rel_rough
ZeroDivisionError: float division by zero

초기값은 물리적으로 그럴듯한 값이어야 한다. Moody 선도에서 난류 마찰계수는 대략 0.01~0.1 사이에 놓이므로, 그 중간인 0.02쯤이 안전한 출발점이다. 반복 계산의 초기값을 답이 있을 법한 범위에서 고르는 습관은 10장의 fsolve 초기 추측과 같은 원리다.

11.3.3 반복을 피하는 길: 명시적 근사식

매번 반복문을 돌리는 대신, 정확도를 조금 양보하고 한 번의 대입으로 끝나는 명시적 근사식(explicit approximation)을 쓸 수 있다. 매끈한 관(ε/D ≈ 0), 2320 < Re < 10⁵ 범위에서는 Blasius 식이 좋은 근사를 준다.

λ = 0.3164 · Re^−0.25 (11.6)

조도까지 포함해 Re > 2320 전 영역을 덮는 것은 Swamee-Jain 식(1976)이다.

λ = 0.25 / [ log₁₀( ε/(3.7·D) + 5.75/Re^0.9 ) ]² (11.7)

식 (11.7)의 ε/(3.7·D)는 식 (11.5)의 0.27·ε/D와 같은 항이다(1/3.7 ≈ 0.27). 문헌마다 표기가 다를 뿐이다. 그리고 두 식 모두 로그의 밑과 상수가 한 세트다. 8장의 Antoine 상수에서 본 것과 같은 함정으로, 식 (11.7)을 자연로그 ln으로 쓰는 문헌은 상수도 0.25 대신 1.325를 쓴다. 식을 옮기며 로그 밑을 바꾸면 상수도 함께 바뀌어야 한다.

도구⑧에는 어떤 식을 넣을까. 층류는 식 (11.4)로 확정이고, 난류는 식 (11.7)을 기본으로 쓰되 식 (11.5)를 반복으로 푼 값과 1% 이내로 일치하는지 대조한다. 예제 11.1-1의 난류 조건(Re = 1.11×10⁵, ε/D = 0.001)에서 식 (11.7)은 0.0221, 코드 11-1의 수렴값은 0.0220이다. 0.8% 차이로, 조도 값 자체의 불확실성보다 훨씬 작다.

11.3.4 Moody 선도: 식들의 지도

지금까지의 식을 전부 한 장의 그래프에 겹쳐 그린 것이 Moody 선도(Moody diagram, 1944)다. 가로축 Re, 세로축 λ를 모두 로그 눈금으로 잡고, 왼쪽에 층류 직선(64/Re)을, 오른쪽에 상대조도별 난류 곡선 가족을 그린다. 컴퓨터 이전 시대에는 이 선도에서 눈으로 λ를 읽었고, 지금도 계산값의 자릿수가 맞는지 한눈에 확인하는 지도로 쓴다.

로그-로그 그래프는 matplotlib에서 plt.plot 대신 plt.loglog를 쓰면 된다. 층류 직선만 먼저 그려 보자.

import numpy as np
import matplotlib.pyplot as plt

Re = np.linspace(500, 2320, 50)   # 층류 영역 (무차원)
plt.loglog(Re, 64 / Re)           # 두 축 모두 로그 눈금
plt.xlabel("Re")
plt.ylabel("Darcy friction factor")
plt.grid(True, which="both")
plt.show()

로그-로그 눈금에서 64/Re는 기울기 −1의 직선으로 나타난다. 난류 곡선 가족과 계산점 표시는 실습 11에서 직접 완성한다.

11.4 AI 협업: 마찰계수 함수와 4배 함정

도구⑧의 중심은 "Re와 상대조도를 받아 λ를 돌려주는 함수" 하나다. §11.2에서 규약이 두 가지임을 알았으므로, 프롬프트에 규약을 못 박는 것이 이번 장의 프롬프트 패턴이다.

import numpy as np

def darcy_friction_factor(Re, rel_rough=0.0):
    """Darcy 마찰계수를 반환한다 (Fanning의 4배 규약).

    Re        : 레이놀즈 수 (무차원)
    rel_rough : 상대조도 ε/D (무차원), 기본값 0 = 매끈한 관
    """
    if Re <= 0:
        raise ValueError("Re는 양수여야 한다")
    if Re < 2320:                    # 층류 (Poiseuille)
        return 64.0 / Re
    # 난류: Swamee-Jain 명시적 근사 (Re > 2320 전 영역)
    arg = rel_rough / 3.7 + 5.75 / Re**0.9
    return 0.25 / np.log10(arg)**2

검증을 마친 함수가 생겼으니 전체 계산을 조립하자. 물성과 조건을 대입하는 정도의 스크립트는 직접 쓴다. 무엇을 AI에게 시키고 무엇을 직접 할지 가르는 감각도 훈련의 일부다.

import numpy as np
from friction import darcy_friction_factor   # 코드 11-3 (검증 완료)

T = 298.15   # K (25 °C)
# 물의 밀도·점도 상관식 (T는 K 단위 크기, 출처: pycse/Polymath 8.8)
rho = 46.048 + 9.418*T - 0.0329*T**2 + 4.882e-5*T**3 - 2.895e-8*T**4  # kg/m^3
mu = np.exp(-10.547 + 541.69 / (T - 144.53))                          # Pa·s

D, L, v = 0.05, 100.0, 2.0   # m, m, m/s
eps = 0.05e-3                # m (절대조도 0.05 mm — mm→m 환산)

Re = rho * v * D / mu                      # 무차원
lam = darcy_friction_factor(Re, eps / D)   # 무차원
dp = lam * (L / D) * 0.5 * rho * v**2      # Pa
print(f"rho={rho:.1f} kg/m3, mu={mu:.2e} Pa.s, Re={Re:.2e}")
print(f"lam={lam:.4f}, dp={dp/1000:.1f} kPa")

rho=994.6 kg/m3, mu=8.93e-04 Pa.s, Re=1.11e+05
lam=0.0221, dp=88.0 kPa

동시수강 중인 유체역학 과목과의 관계를 짚어 두자. 유체역학 강의가 이 식들의 유도와 물리를 담당한다면, 이 장은 같은 식을 "계산 가능한 형태"로 옮겨 도구로 굳히는 쪽을 담당한다. 종이 위의 Moody 선도에서 눈으로 λ를 읽는 훈련과, 그 선도를 코드로 그려 계산점을 얹는 훈련은 같은 내용의 양면이다. 이론 수업에서 새 상관식을 만나면 도구⑧에 분기 하나로 추가해 보라(도구를 함수로 만들어 둔 이유가 그것이다).

import math

def pressure_drop(D_mm, L, v, rho, mu, eps_mm):
    """배관 압력강하 [Pa]를 반환한다."""
    D = D_mm                    # 관 내경
    Re = rho * v * D / mu       # 레이놀즈 수
    if Re < 2320:
        lam = 16.0 / Re         # 층류 마찰계수
    else:
        arg = eps_mm / (3.7 * D) + 5.75 / Re**0.9
        lam = 0.25 / math.log(arg)**2    # Swamee-Jain
    return lam * (L / D) * 0.5 * rho * v**2

12.1 표를 다루는 근육: pandas

5장부터 지금까지 만든 도구들은 입력이 숫자 몇 개였다. 온도 하나, 압력 하나, 조성 두어 개. 그러나 도입부의 보정 기록처럼 현장에서 만나는 데이터는 행 단위로 쌓이는 표다. 표를 다루는 파이썬의 표준 도구가 pandas 라이브러리다.

12.1.1 읽기: 파일에서 표로

도입부의 측정 기록을 지면과 동일하게 재현하기 위해, 데이터 파일부터 코드로 만들어 두자. 실제 현장에서는 계측 시스템이 이런 파일을 내보낸다. (이 데이터는 교재용으로 만든 가상 측정값이다.)

from pathlib import Path

csv_text = """run,session,dP_kPa,Q_m3h
1,am,2,1.19
2,am,4,1.72
3,am,6,2.06
4,am,8,2.43
5,am,10,2.67
6,am,14,3.19
7,pm,18,3.58
8,pm,22,4.01
9,pm,26,43.3
10,pm,30,4.64
11,pm,36,
12,pm,40,5.40
"""
Path("flow_calib.csv").write_text(csv_text, encoding="utf-8")

열 이름 dP_kPa(차압, kPa)와 Q_m3h(유량, m³/h)에 단위를 박아 넣었다. 여섯 달 뒤 파일만 열어 본 사람도 단위를 알 수 있다. 단위 체크 루틴의 데이터 버전이다. 이제 읽어 보자.

import pandas as pd

df = pd.read_csv("flow_calib.csv")  # CSV → 표
print(df.head())                    # 앞 5행만 표시

실행 결과는 다음과 같다.

   run session  dP_kPa  Q_m3h
0    1      am       2   1.19
1    2      am       4   1.72
2    3      am       6   2.06
3    4      am       8   2.43
4    5      am      10   2.67

지금 화면에 뜬 것처럼 행과 열로 이루어진 표를 담는 pandas의 자료구조를 데이터프레임(DataFrame)이라 한다. 행 하나가 측정 한 번, 열 하나가 변수 하나다. 리스트가 값의 나열이라면 데이터프레임은 이름표가 달린 열들의 묶음이고, 그 이름표로 열을 꺼내 쓴다.

12.1.2 점검 3연타: head·info·describe

head()가 보여 준 다섯 행이 전부가 아니다. 파일을 받으면 세 가지를 연달아 확인한다.

df.info()                        # 열별 자료형과 채워진 칸 수
print(df["Q_m3h"].describe())    # 유량 열의 통계 요약
print(df.isna().sum())           # 열별 결측 칸 개수

info()의 출력에서 자료형과 채워진 칸 수를 읽을 수 있다.

RangeIndex: 12 entries, 0 to 11
Data columns (total 4 columns):
 #   Column   Non-Null Count  Dtype
---  ------   --------------  -----
 0   run      12 non-null     int64
 1   session  12 non-null     str
 2   dP_kPa   12 non-null     int64
 3   Q_m3h    11 non-null     float64
…

Q_m3h 열만 11 non-null이다. 열두 행 중 한 칸이 비어 있다는 뜻이고, 이렇게 기록되지 않은 칸을 결측값(missing value)이라 한다. pandas는 결측을 NaN으로 표시하며, df.isna().sum()으로 열별 개수를 셀 수 있다.

이어서 describe()의 출력을 보자.

count    11.000000
mean      6.744545
std      12.189858
min       1.190000
25%       2.245000
50%       3.190000
75%       4.325000
max      43.300000

max 43.3이 눈에 걸린다. 75% 지점이 4.33인데 최댓값은 그 열 배다. 아직 아무것도 지우지 않는다. 지금은 표시만 해 두고, 처분은 12.3절에서 절차대로 결정한다.

12.1.3 선택과 집계

표 전체가 아니라 일부만 필요할 때가 더 많다. 대괄호에 열 이름을 넣으면 열 하나를 얻고, 조건식을 넣으면 조건을 만족하는 행만 남는다.

q = df["Q_m3h"]                   # 열 하나 선택 (m³/h)
high = df[df["dP_kPa"] > 20]      # 차압 20 kPa 초과 행만
print(len(high))                  # 몇 행이 남았는가
print(df.groupby("session")["Q_m3h"].mean())  # 세션별 평균 유량

df["dP_kPa"] > 20은 행마다 참/거짓을 매기고, 그 결과를 다시 대괄호에 넣으면 참인 행 다섯 개만 걸러진다. 마지막 줄처럼 데이터를 그룹으로 나눠 그룹별 요약 통계를 내는 조작을 집계(aggregation)라 한다. 출력은 다음과 같다.

session
am     2.210
pm    12.186
Name: Q_m3h, dtype: float64

도입부의 위화감이 숫자로 나타났다. 오전 평균 2.21, 오후 평균 12.19다. 설비가 오후에 다섯 배 힘차게 돈 것이 아니라, 43.3 한 점이 오후 평균을 끌어올렸다. 평균은 이상치 한 점에 이렇게 약하다.

이 정도 점검은 AI에게 통째로 맡겨도 된다. 다만 결과를 그대로 믿는 대신, 눈으로 센 값과 대조한다.

import pandas as pd

def summarize(path):
    """CSV 파일을 읽어 상태 요약을 출력하고 표를 반환한다."""
    df = pd.read_csv(path)
    print("크기:", df.shape)      # (행 수, 열 수)
    print(df.dtypes)              # 열별 자료형
    print(df.isna().sum())        # 열별 결측 개수
    print(df.describe())          # 숫자 열 통계 요약
    return df

df = summarize("flow_calib.csv")

12.2 최소자승 회귀: 가장 덜 틀리는 직선

12.2.1 잔차와 최소자승의 원리

측정점이 두 개면 자를 대고 이으면 된다. 그러나 열한 개의 점이 정확히 한 직선 위에 놓이는 일은 없다. 그렇다면 "가장 덜 틀리는" 직선은 무엇인가.

직선 y = ax + b를 그었을 때, i번째 측정값 y_i와 직선이 예측한 값의 차이를 잔차(residual)라 한다: r_i = y_i − (ax_i + b). 잔차를 그냥 더하면 양수와 음수가 상쇄되어 엉터리 직선도 합이 0에 가까울 수 있다. 그래서 잔차를 제곱해 더한 값을 기준으로 삼는다.

S(a, b) = Σ_i [y_i − (ax_i + b)]² (12.1)

식 (12.1)의 S를 최소로 만드는 a와 b를 택하는 방법을 최소자승법(method of least squares)이라 한다. 제곱은 두 가지 일을 한다. 부호를 없애고, 크게 벗어난 점에 제곱으로 커지는 벌점을 준다. 잔차 2의 벌점은 4지만 잔차 10의 벌점은 100이다. 이 두 번째 성질이 어떤 부작용을 일으키는지 12.3절에서 다시 만난다.

S를 a와 b로 각각 미분해 0으로 놓으면 닫힌 형태의 해가 나온다. 그 계산은 np.polyfit이 대신하므로, 사람이 할 일은 결과가 물리적으로 말이 되는지 검증하는 것이다.

12.2.2 np.polyfit으로 피팅하기

보정 대상 유량계의 사양서는 유량과 차압 사이에 다음 관계를 명시한다고 하자.

Q = k √(ΔP) (12.2)

√(ΔP)를 새 변수 x로 놓으면 식 (12.2)는 Q = kx가 되고, 원점을 지나는 직선이다. 곡선 관계를 직선으로 펴는 이런 변수 변환은 회귀의 기본 기술이다. 사양서의 설계값은 k = 0.85 m³ h⁻¹ kPa^−1/2이고, 우리 일은 측정 데이터로 이 값을 확인하는 것이다.

import numpy as np
import pandas as pd

def fit_calibration(df):
    """√ΔP에 대한 Q의 1차 피팅. (기울기, 절편, R²)를 반환한다."""
    d = df.dropna(subset=["Q_m3h"])       # 결측 행 제외
    x = np.sqrt(d["dP_kPa"].to_numpy())   # kPa^0.5
    y = d["Q_m3h"].to_numpy()             # m³/h
    k, b = np.polyfit(x, y, 1)            # 1차 피팅: [기울기, 절편]
    y_fit = np.polyval((k, b), x)         # 피팅 직선의 예측값
    ss_res = np.sum((y - y_fit) ** 2)     # 잔차 제곱합
    ss_tot = np.sum((y - np.mean(y)) ** 2)
    return k, b, 1 - ss_res / ss_tot

df = pd.read_csv("flow_calib.csv")
k, b, r2 = fit_calibration(df)
print(f"k = {k:.3f}, b = {b:.3f}, R² = {r2:.3f}")

k = 3.019, b = -4.628, R² = 0.147

12.2.3 결정계수와 잔차 플롯

피팅이 데이터의 산포를 얼마나 설명하는지 요약하는 지표가 결정계수(coefficient of determination) R²다.

R² = 1 − SS_res / SS_tot (12.3)

SS_res는 잔차 제곱합, SS_tot은 평균 둘레의 총 제곱합이다. 직선이 산포를 전부 설명하면 SS_res = 0이 되어 R² = 1이고, 평균보다 나을 게 없으면 0에 가깝다. 예제 12.2-1의 0.147은 "이 직선은 데이터의 15%도 설명하지 못한다"는 뜻이다.

거꾸로 R²가 높다고 모델이 옳다는 보장도 없다. 잔차를 x에 대해 그렸을 때 아무 패턴이 없어야 하며, 잔차가 곡선을 그리면 직선 모델 자체가 틀렸다는 신호다. 숫자만으로는 감이 오지 않으니 그림을 그려 보자.

import matplotlib.pyplot as plt

d = df.dropna(subset=["Q_m3h"])
x = np.sqrt(d["dP_kPa"].to_numpy())   # kPa^0.5
y = d["Q_m3h"].to_numpy()             # m³/h
plt.plot(x, y, "o", label="측정값")
xs = np.linspace(0, 6.5)              # kPa^0.5
plt.plot(xs, np.polyval((k, b), xs), "-", label="피팅 직선")
plt.xlabel("√ΔP [kPa^0.5]")
plt.ylabel("Q [m³/h]")
plt.legend()
plt.show()

열 점이 한 직선 부근에 가지런히 모여 있고, 한 점만 하늘에 떠 있다. 피팅 직선은 그 점에 끌려 올라가 나머지 점 대부분의 위를 지나간다. 그림 한 장이 R² = 0.147의 사정을 전부 설명한다.

12.3 이상치: 지우기 전에 조사한다

12.3.1 세 가지 근원

나머지 데이터가 이루는 패턴에서 크게 벗어난 점을 이상치(outlier)라 한다. 이상치를 방치하면 예제 12.2-1처럼 결과 전체가 왜곡된다. 그런데 조사 없이 지우는 것도 같은 크기의 실수다. 어느 쪽인지 판단하려면 이상치가 어디서 오는지부터 알아야 한다.

첫째 근원은 기록과 입력의 실수다. 현장 기록지의 4.33이 전산 입력에서 43.3이 되는 식으로, 소수점 한 칸이 값을 열 배로 만든다. 둘째는 센서와 계측의 고장이다. 특정 시간대나 특정 장비의 값만 몰려서 튀면 이쪽을 의심한다.

셋째 근원인 진짜 물리 현상이 문제다. 예상 밖의 조건에서 실제로 일어난 일이 이상치로 보일 수 있고, 이것을 기계적으로 지우는 습관은 새로운 현상의 발견을 지우는 습관이다. 그래서 원칙은 하나로 고정한다. 지우기 전에 조사한다.

12.3.2 잔차로 후보 찾기

조사하려면 먼저 후보를 골라야 한다. describe()의 min/max 훑기와 그림(코드 12-8)이 1차 검사이고, 정량적 기준은 피팅의 잔차에서 나온다.

res = y - np.polyval((k, b), x)   # 잔차 (m³/h)
print(np.round(res, 2))
sigma = np.std(res)               # 잔차 표준편차
print("잔차 표준편차:", round(sigma, 2))
suspect = d[np.abs(res) > 3 * sigma]   # 3σ 초과 후보
print(suspect)

[ 1.55  0.31 -0.71 -1.48 -2.25 -3.48 -4.6  -5.52 32.53 -7.27 -9.07]
잔차 표준편차: 10.73
   run session  dP_kPa  Q_m3h
8    9      pm      26   43.3

잔차 크기가 잔차 표준편차의 3배를 넘는 점을 의심 후보로 본다. 이 책의 작업 규칙이다. run 9가 걸렸다. 그런데 숫자를 자세히 보면 아슬아슬하다. 후보의 잔차 32.53에 대해 경계값 3σ = 32.20으로, 겨우 넘었다.

왜 이렇게 아슬아슬한가. 이상치 자신이 표준편차 계산에 들어가 σ를 부풀렸기 때문이다. 극단적인 이상치일수록 자신을 가려 주는 경계를 스스로 키우므로, 기계적 규칙은 후보 선별까지만 쓰고 최종 판단은 조사에 맡긴다.

12.3.3 조사, 그리고 수정

이 장의 시나리오에서 run 9의 현장 기록지에는 4.33이 적혀 있었다고 하자. 전산 입력에서 소수점이 밀린 것으로, 근원 ①(입력 실수)로 확정되었다. 원인이 확정되었으므로 원본값으로 수정하는 것이 정당하다. 원인을 밝히지 못했다면 수정은 불가능하고, 제거하되 무엇을 왜 몇 건 지웠는지 README에 남긴다(시험의 검증 증빙과 같은 형식이다).

df_fix = df.copy()                     # 원본은 남겨 둔다
df_fix.loc[df_fix["run"] == 9, "Q_m3h"] = 4.33   # 기록지 원본값 (m³/h)
k2, b2, r2 = fit_calibration(df_fix)
print(f"k = {k2:.3f}, b = {b2:.4f}, R² = {r2:.4f}")

k = 0.852, b = -0.0069, R² = 0.9998

12.4 데이터 검증 습관: 루틴 3종의 데이터 버전

3장에서 도입한 검증 루틴 3종은 계산 결과만이 아니라 데이터 작업의 모든 단계에 적용된다. 단위 체크는 열 이름에 단위를 넣는 것(dP_kPa, Q_m3h)과 읽은 직후의 자료형 확인으로 나타난다. 단위 행 오염은 dtypes에서 걸렸다. 대조값 체크는 describe()의 min/max를 설비의 조업 상식과 대조하고, 피팅 계수를 사양서·문헌값과 대조하는 일이다. 극한값 체크는 절편의 물리적 의미(ΔP = 0이면 Q = 0)를 캐묻는 일이었다.

회귀식에도 유효범위가 있다. 이 장의 보정식은 ΔP = 2~40 kPa의 데이터로 만들어졌으므로 그 밖은 외삽이다. 8장에서 Antoine 상수를 유효 온도범위 밖으로 외삽했을 때 생긴 오차를 보았다. 같은 규칙이 데이터 피팅에 그대로 적용된다. 회귀식의 유효범위는 데이터의 범위다.

여기에 데이터 특유의 습관 하나를 더한다. 행을 없애거나 고치는 모든 처리의 앞뒤에서 행 수를 찍는 것이다.

n0 = len(df)
df2 = df.dropna(subset=["Q_m3h"])     # 결측 행 제외
print(f"결측 제외: {n0}행 → {len(df2)}행")   # 12행 → 11행

한 줄짜리 확인이지만, 12.3절의 AI 경고 사례에서 조용한 2행 손실을 잡아낸 것이 바로 이 습관이다. 정리하면 이 장의 검증 습관은 네 가지다. 읽은 직후 3연타, 열 이름에 단위, 처리 전후 행 수 비교, 피팅 후 검증 3종이다.

시험2는 이 사이클 전체를 90분 안에 도는 시험이다. 이제 그 규정과 전략으로 넘어가자.

13.1 공학 그래프의 문법

과학 계산의 목적은 숫자가 아니라 통찰이다. 계산이 쏟아 낸 수백 개의 숫자를 사람이 이해하려면 그림이 필요하고, 그래서 시각화는 해석의 시작 단계다. 그리고 그래프는 "이 온도에서 압력이 이만큼이다"라는 주장이고, 주장에는 근거가 붙어 있어야 한다.

공학 그래프가 갖춰야 할 최소 요건은 네 가지다. 첫째, 두 축에 물리량 이름과 단위를 적는다. 단위 없는 축은 검증 루틴 중 단위 체크를 원천적으로 불가능하게 만든다. 둘째, 곡선이 둘 이상이면 어느 선이 무엇인지 밝힌다. 여러 데이터 계열을 구분하는 이름표를 범례(legend)라 한다. 셋째, 데이터의 성격에 맞는 표현을 고른다. 측정한 데이터는 점(마커)으로, 모델이나 상관식은 선으로 그린다. 측정점 열두 개를 실선으로만 이어 버리면 측정하지 않은 중간값까지 측정한 것처럼 주장하는 셈이 된다. 넷째, 데이터의 분포에 맞는 축 스케일을 고른다.

넷째 요건이 낯설 수 있으니 8장의 증기압으로 확인해 보자. 물의 증기압은 NIST 상수의 유효범위인 379~573 K 사이에서 약 1 bar에서 약 70 bar까지, 70배 가까이 변한다. 이것을 눈금이 일정한 보통 축(선형축)에 그리면 고온부의 큰 값이 축 전체를 차지해 저온부 곡선은 바닥에 붙은 0처럼 보인다. 눈금 한 칸이 일정한 배수(10배)를 나타내는 축을 로그축(logarithmic axis)이라 한다. 로그축에서는 1 bar와 70 bar가 같은 비중으로 보이고, 저온부의 변화도 읽을 수 있다.

증기압에 로그축이 어울리는 것은 우연이 아니다. Antoine 식 자체가 log₁₀ p*를 온도의 함수로 쓰는 식이므로, 세로축을 로그로 잡으면 곡선이 완만하게 펴진다. 데이터를 만든 물리가 지수적이면 축도 로그로 잡는다. 이것이 스케일 선택의 원칙이다.

import numpy as np
import matplotlib.pyplot as plt

A, B, C = 3.55959, 643.748, -198.043
T = np.linspace(300, 600, 100)
p = 10**(A - B/(T + C))
plt.plot(T, p)
plt.show()

import numpy as np
import matplotlib.pyplot as plt

# NIST WebBook: 물, 유효범위 379~573 K
# log10(p*/bar) = A - B/(T + C)
A, B, C = 3.55959, 643.748, -198.043

T = np.linspace(379, 573, 100)      # 온도 [K] — 유효범위만
p = 10**(A - B/(T + C))             # 증기압 [bar]

plt.semilogy(T, p, label="물 (NIST 상수)")   # 세로축 로그
plt.xlabel("온도 T [K]")
plt.ylabel("증기압 p* [bar]")
plt.legend()
plt.grid(True)
plt.savefig("vapor_curve.png", dpi=150)

13.2 스크립트에서 대시보드로: Streamlit 최소한

13.2.1 일단 띄워 보기

먼저 손을 움직여 보자. 터미널에서 pip install streamlit으로 라이브러리를 설치한 뒤, 다음 다섯 줄을 app.py로 저장한다.

import streamlit as st

st.title("나의 첫 대시보드")               # 페이지 제목
T = st.slider("온도 [K]", 379, 573, 400)   # 슬라이더 (최소, 최대, 초기값)
st.write(f"선택한 온도: {T} K")            # 화면에 출력

실행은 python app.py가 아니라 streamlit run app.py다. 브라우저가 열리고, 슬라이더가 있는 웹 페이지가 나타난다. 슬라이더를 끌면 아래 숫자가 즉시 바뀐다. (아무것도 뜨지 않으면 터미널에 출력된 주소를 브라우저에 직접 입력해 보라.)

방금 만든 것에 이름을 붙이자. 데이터와 계산 결과를 한 화면에 모아 사용자가 직접 조작하며 보게 만든 것을 대시보드(dashboard)라 하고, 슬라이더·선택 상자처럼 사용자 입력을 받는 화면 요소를 위젯(widget)이라 한다. Streamlit은 파이썬 스크립트를 이런 웹 대시보드로 바꿔 주는 라이브러리다.

동작 원리는 하나만 알면 된다. 위젯 값이 바뀔 때마다 Streamlit은 스크립트 전체를 위에서 아래로 다시 실행한다. 새로운 프로그래밍 모델을 배우는 것이 아니라, 지금까지 쓰던 "위에서 아래로 흐르는 스크립트"가 위젯 값만 갱신된 채 반복 실행되는 것이다. 그래서 5장부터 만들어 온 함수들을 고치지 않고 그대로 가져다 쓸 수 있다.

13.2.2 화공 도구의 대시보드화

이제 8장의 증기압 계산기를 대시보드로 옮겨 보자. 핵심은 두 가지다. 계산 함수는 새로 짜지 않고 재사용하며, 위젯의 범위를 상수의 유효범위로 제한한다.

import numpy as np
import streamlit as st

# NIST WebBook: 물(379~573 K), log10(p*/bar) = A - B/(T + C)
A, B, C = 3.55959, 643.748, -198.043

st.title("증기압 대시보드 — 물")
T = st.slider("온도 [K]", 379, 573, 400)   # 유효범위로 제한 [K]
p = 10**(A - B/(T + C))                     # 증기압 [bar]
st.metric("증기압", f"{p:.2f} bar")         # 숫자 카드 표시

T_arr = np.linspace(379, 573, 100)          # 곡선용 온도 [K]
p_arr = 10**(A - B/(T_arr + C))             # 증기압 [bar]
st.line_chart({"p* [bar]": p_arr})

13.3 회귀에서 신경망으로: 모델·손실·학습

13.3.1 두 얼굴의 오차

12장에서 데이터에 직선과 다항식을 맞추는 회귀(regression)를 다뤘다. 그 작업을 세 부분으로 나눠 이름을 붙이면 기계학습 전체의 뼈대가 된다. 모양을 가진 함수(모델), 모델이 얼마나 틀렸는지 재는 함수, 그리고 틀림이 줄어들도록 모델의 매개변수(parameter)를 조정하는 절차(학습)다. 틀림을 재는 함수를 손실 함수(loss function)라 한다.

가장 기본적인 손실 지표는 평균절대오차(mean absolute error, MAE)다. 데이터 n개에 대해 다음과 같이 정의한다.

MAE = (1/n) Σ |y_i − ŷ_i|   (13.1)

여기서 y_i는 실제 값, ŷ_i는 모델의 예측값이다. MAE는 오차의 평균 크기를 그대로 알려 주고, 제곱을 쓰는 RMSE는 큰 오차를 더 무겁게 벌준다. 모델 성적을 눈으로 보려면 가로축에 실제 값, 세로축에 예측값을 찍는다. 이런 산점도를 패리티 플롯(parity plot)이라 하며, 완벽한 모델이라면 모든 점이 대각선 위에 놓인다.

성적의 기준선도 필요하다. 모든 입력에 대해 평균 하나만 답하는 상수 모델은 뜻밖에 유용한 기준선이다. 이보다 못한 모델은 아무것도 배우지 못한 것이다. 그런데 여기에 함정이 하나 있다. 지금까지처럼 갖고 있는 데이터 전부로 피팅하고 같은 데이터로 성적을 매기면, 그 성적은 무엇을 말해 주는가? 모델을 만드는 이유는 아직 보지 못한 데이터를 예측하기 위해서다. 그래서 데이터를 둘로 가른다. 모델을 맞추는 데 쓰는 부분을 훈련 데이터(training data), 성적을 매기기 위해 감춰 두는 부분을 시험 데이터(test data)라 한다. 학생이 시험 문제를 미리 보고 공부하면 점수가 실력을 말해 주지 않는 것과 같은 이치다.

import numpy as np

rng = np.random.default_rng(1)        # 재현 가능한 난수 시드
T = np.linspace(60, 100, 16)          # 반응 온도 [degC]
y = 20 + 1.5*T - 0.008*T**2           # 우리가 심은 참 관계 (2차) [%]
y = y + rng.normal(0, 1.0, T.size)    # 측정 잡음 [%p]

idx = rng.permutation(T.size)         # 순서를 무작위로 섞는다
train, test = idx[:12], idx[12:]      # 훈련 12점 / 시험 4점

for deg in [1, 2, 9]:
    coef = np.polyfit(T[train], y[train], deg)      # 훈련 데이터로만 피팅
    err_tr = np.polyval(coef, T[train]) - y[train]  # 훈련 오차 [%p]
    err_te = np.polyval(coef, T[test]) - y[test]    # 시험 오차 [%p]
    print(f"{deg}차: 훈련 MAE {np.mean(np.abs(err_tr)):.2f}, "
          f"시험 MAE {np.mean(np.abs(err_te)):.2f}")

1차: 훈련 MAE 1.19, 시험 MAE 0.87
2차: 훈련 MAE 0.52, 시험 MAE 0.45
9차: 훈련 MAE 0.23, 시험 MAE 2.71

실무 데이터에는 참 관계가 없으므로 결정계수(coefficient of determination, R²) 같은 지표로 판단을 보조한다. 화학공학의 실측 데이터에서는 R²가 0.9를 넘으면 대체로 훌륭한 수준이고, 0.95를 넘으면 오히려 과적합을 의심하라는 경험칙이 있다. 높은 점수가 항상 좋은 소식은 아니다.

13.3.2 신경망: 모양을 데이터가 정하는 함수

직선 모델의 매개변수는 기울기와 절편 2개다. 9차 다항식은 10개다. 이 수를 더 늘리면 무슨 일이 생기는가? 신경망(neural network)은 "입력의 가중합을 구하고 단순한 비선형 변환을 거치는" 작은 함수를 층층이 쌓아 만든, 매개변수가 대단히 많은 유연한 함수다. 다항식에서는 사람이 차수라는 모양을 골랐지만, 신경망은 모양 자체를 데이터가 정하게 한다.

그렇다고 새 수학이 등장하는 것은 아니다. 신경망의 학습도 손실 함수가 작아지는 방향으로 매개변수를 조금씩 반복 조정하는 절차이고, 성적은 시험 데이터의 MAE나 패리티 플롯으로 매긴다. 12장의 회귀에서 배운 모델–손실–학습의 3요소가 규모만 커진 채 그대로 있다. 1장에서 만난 대형 언어 모델도 다음 토큰을 예측하도록 이 절차로 훈련된 매우 큰 신경망이다. 학기 내내 함께 일한 AI가 사실은 이 절의 주제였던 셈이다.

유연함에는 대가가 따른다. 매개변수가 많을수록 과적합의 위험이 커지고, 필요한 데이터가 많아지고, 왜 그런 답이 나왔는지 해석하기 어려워진다. 그래서 신경망에서는 훈련/시험 분리를 반드시 지켜야 한다. 예제 13.3-1에서 9차 다항식이 보여 준 붕괴는, 매개변수가 수백만 개인 모델에서는 더 조용하고 더 그럴듯한 모습으로 일어난다.

13.4 칼럼: 화공 연구 현장의 기계학습, DFT와 MLIP

이 장에서 배운 3요소가 연구 현장에서 어떻게 쓰이는지 잠깐 엿보자. 새 촉매를 찾는 계산화학 연구에서는 반응물 분자가 촉매 표면에 얼마나 강하게 붙는지(흡착 에너지)가 성능을 가르는 핵심 물성이다. 이 값은 양자역학으로 분자와 재료의 에너지를 계산하는 밀도범함수이론(density functional theory, DFT)으로 구하는데, 계산 한 건에 많은 시간이 든다. 그래서 연구자들은 이미 수행된 대량의 DFT 결과를 훈련 데이터 삼아, 새 촉매 후보의 흡착 에너지를 곧바로 예측하는 기계학습 모델을 만든다. 이 분야에서는 실용적 의미가 있으려면 흡착 에너지의 MAE가 0.1~0.2 eV 수준이어야 한다는 목표가 통용된다. 모델의 성패를 가르는 잣대가 결국 시험 데이터의 MAE라는 점이 이 장의 예제와 같다.

한 걸음 더 나아간 도구도 있다. 원자들의 배치를 입력받아 에너지와 힘을 출력하도록 훈련된 신경망을 기계학습 포텐셜(machine-learned interatomic potential, MLIP)이라 한다. DFT의 정확도에 가까운 답을 훨씬 적은 비용으로 내는 것이 목표이며, 전지 소재나 촉매처럼 원자 수가 많은 시스템의 시뮬레이션에 쓰인다. 여기서도 뼈대는 모델–손실–학습 그대로이고, "훈련 범위 밖의 원자 배치에서는 믿을 수 없다"는 외삽 경고까지 Antoine 상수의 유효범위와 같은 논리로 따라온다. 13주차 이론 세션에서 담당 교수의 실제 연구 사례로 이 두 주제를 소개한다.

13.5 실습 13: 도구⑨ 공정 데이터 대시보드 + 서브프로젝트 스프린트

14.1 발표는 검증의 마지막 단계다

완성한 도구를 청중 앞에서 실행해 보이고 그 결과의 공학적 의미를 질문에 맞서 지키는 일을 기술 발표(technical presentation)라 한다. 발표를 잘 만든 도구에 붙이는 장식으로 보기 쉽다. 그러나 검증 루틴 3종이 "이 값이 나에게 말이 되는가"를 묻는 절차라면, 발표는 "이 값이 남에게도 말이 되는가"를 묻는 절차다.

절차의 마지막 칸에 검증을 두는 관례는 이 책에서 이미 두 번 보았다. 10장의 물질수지 풀이 절차는 흐름도 그리기에서 시작해 검산(check your work)으로 끝났고, 13장에서 소개한 ML 워크플로는 "문제를 정의한다"가 1단계였다. 문제 정의로 열고 검증으로 닫는 이 순서는 그 계산을 보고하는 3분에도 그대로 적용된다.

작동하는 프로그램을 실제로 실행해 결과가 나오는 과정을 보여 주는 것을 데모(demonstration, demo)라 한다. 그리고 청중이나 채점자의 질문에 근거를 들어 답하는 것을 구술 방어라 한다. 이 수업의 발표는 이 둘의 결합이다. 슬라이드 장식 기술은 채점 대상이 아니며, 루브릭이 재는 것은 구성(문제정의→데모→화공 해석)과 Q&A 방어뿐이다.

발표의 세 구간은 사이클의 축약이기도 하다. 문제정의 구간은 블록 ①을, 데모 구간은 블록 ③~⑤의 결과를, 화공 해석 구간은 블록 ⑥을 청중이 볼 수 있는 형태로 압축한다. 사이클을 성실히 돌린 프로젝트라면 발표 재료는 이미 repo 안에 있다.

14.2 3분 구성법: 문제정의 → 데모 → 화공 해석

14.2.1 시간 예산부터 세운다

발표 시간은 3분, 즉 180 s로 고정되어 있다. 배관을 설계할 때 압력강하 예산부터 세우듯, 발표도 시간 예산부터 세운다. 세 구간의 합은 다음을 만족해야 한다.

t_문제정의 + t_데모 + t_해석 = 180 s (14.1)

권장 출발점은 문제정의 40 s, 데모 80 s, 화공 해석 60 s다. 데모에 가장 큰 몫을 주는 이유가 있다. 문제정의와 해석은 말로 압축할 수 있지만, 프로그램의 실행에는 압축할 수 없는 물리적 시간(입력, 실행, 출력 확인)이 들기 때문이다. 이 배분은 출발점이고, 확정은 리허설 실측으로 한다. 대본을 소리 내어 읽고 구간별 시간을 재서, 20 s 이상 초과한 구간을 먼저 줄인다.

14.2.2 문제정의 구간: 청중이 궁금한 것은 폴더 구조가 아니다

첫 40 s의 임무는 "이 도구가 없으면 무엇이 귀찮거나 위험한가"를 한 문장으로 세우고, 도구의 입력과 출력을 선언하는 것이다. 화공양론 숙제 검산기라면 "recycle이 있는 물질수지는 손 검산에서 스트림 하나를 빼먹기 쉽다. 이 도구는 흐름도 텍스트를 받아 정합성 위반 스트림을 출력한다"가 전부다.

가장 흔한 실수는 파일 구조와 사용 라이브러리 소개로 시작하는 것이다. 그것은 README의 몫이고 첫 40 s의 몫은 아니다. 문제가 서지 않으면 그 도구가 왜 필요한지도 청중에게 전달되지 않는다.

14.2.3 데모 구간: 실행 1사이클 + 검증 1개

데모 80 s에 넣을 것은 두 가지다. 입력→실행→출력의 완결된 1사이클, 그리고 검증 루틴이 통과하는 순간 1개다. 예를 들어 T-xy 도구라면 조성 입력, 다이어그램 출력까지 보여 준 뒤, 순물질 극한(x=1)에서 곡선이 문헌 끓는점에 닿는 화면을 잡아 준다. 기능 다섯 개를 스치듯 훑는 것보다 한 사이클을 검증까지 완주하는 편이 루브릭 구성 5점에 직결된다.

데모 준비의 고전적 함정은 경로다. 본인 노트북의 작업 폴더에서는 돌던 코드가 발표용 환경에서 이렇게 죽는다.

FileNotFoundError: [Errno 2] No such file or directory: 'data.csv'

원인은 상대경로다. 스크립트를 어느 폴더에서 실행하느냐에 따라 'data.csv'가 가리키는 위치가 달라진다. 녹화 전에 데이터 경로를 스크립트 위치 기준으로 고정해 두면 실행 위치와 무관해진다.

from pathlib import Path

BASE = Path(__file__).resolve().parent   # 이 스크립트가 있는 폴더
DATA = BASE / "data.csv"                 # 실행 위치와 무관하게 고정된 경로

그래도 실패에는 대비한다. 실행 화면 캡처 2~3장을 예비 슬라이드로 준비해 두면, 라이브 실행이나 영상 재생이 죽어도 데모 구간의 서사는 이어 갈 수 있다. 백업이 있으면 장애가 나도 침착하게 대응할 수 있고, 그 침착함이 Q&A 3점으로 이어진다.

14.2.4 화공 해석 구간: 숫자를 상식과 문헌에 잇는다

마지막 60 s는 출력 수치의 공학적 의미를 말하는 시간이다. 여기서 하는 일은 8장에서 훈련한 것과 같다. Antoine 상관식으로 계산한 물의 증기압이 "물은 1 atm에서 100 °C에 끓는다"는 상식 대조값과 크게 어긋나면서 유효범위 밖 외삽이 드러났듯, 해석 구간은 데모의 숫자를 대조값·유효범위·한계와 연결한다. "계산이 끝났다"와 "결과를 믿을 수 있다" 사이의 거리를 메우는 것이 이 구간의 임무다.

한계를 말하는 것을 두려워할 이유가 없다. 최종 시험 루브릭의 코드 이해 10점 중 3점이 "한계·개선점"에 걸려 있다. 자기 도구의 유효범위를 먼저 밝히면 그 3점을 스스로 확보할 수 있다. 감추면 같은 내용을 질문으로 되돌려 받게 된다.

# 3분 발표 시간 예산 — 단위: 초(s)
budget = {"문제정의": 40, "데모": 80, "화공 해석": 60}

total = sum(budget.values())              # s
assert total == 180, f"합계 {total} s — 180 s에 맞춰라"

for part, t in budget.items():
    print(f"{part}: {t} s ({t / 180:.0%})")   # 구간별 비중 출력

14.3 청중 질문 네 유형과 방어

14.3.1 질문은 네 유형뿐이다

발표 뒤의 2분은 준비한 정도가 그대로 드러나는 시간이다. 다행히 기술 발표에 들어오는 질문은 대부분 네 유형으로 정리되고, 각 유형은 최종 시험 루브릭의 특정 배점과 일대일로 대응한다. 유형을 알면 방어를 미리 준비할 수 있다.

표의 오른쪽 열에서 보듯, 모든 답은 가리킬 수 있는 근거(코드의 줄, README의 절, 커밋 이력, 문헌값)로 끝난다. "그럴 겁니다"로 끝나는 답은 방어가 되기 어렵다. 근거가 없으면 "확인하지 못했다, 한계로 기록하겠다"가 정답이며, 이는 한계·개선형 답변으로 부분 점수를 지킨다.

14.3.2 "설명 불능 = 0점" 규정의 재확인

1주차 역할 계약을 다시 꺼낸다. AI가 코드를 쓰는 대신, 학생은 문제 분해·생성 코드 읽기·화학공학적 검증을 책임지며, "설명 못 하면 이해 점수 0점"이다. 최종 시험 루브릭은 이것을 조작적으로 정의해 두었다. 코드 이해 10점 차원에서 지목 질문 3개 중 2개 이상 설명에 실패하면 이 차원은 0점이다. 9점도 5점도 아닌 0점인 이유는, 설명하지 못하는 코드를 부분적으로 이해한 코드로 보기 어렵기 때문이다.

이 규정 앞에서 발표회는 안전한 실패 기회다. 오늘 Q&A에서 막힌 질문은 시험 전에 미리 발견한 구멍인 셈이다. 막힌 자리를 위키에 기록하는 것이 이번 주 위키 과제의 두 번째 항목인 이유다.

14.3.3 예상 질문은 AI로 미리 생성한다

방어 준비에서 AI의 쓸모는 대본 작성이 아니라 모의 청중 역할이다. 본인 코드를 주고 질문을 시켜 보자.

14.4 프로젝트 완성 체크리스트

14.4.1 채점자는 README부터 연다

발표가 3분이라면 채점은 그 몇 배의 시간 동안 repo 위에서 이루어진다. 채점자가 처음 여는 문서는 README고, 루브릭 작동성 14점의 첫 5점이 "README대로 실행"이다. 다른 컴퓨터에서 README의 지시만 따라 같은 결과가 나오는 성질을 재현성(reproducibility)이라 한다. 재현성은 문서의 품질로 결정된다.

이 수업의 README에 반드시 있어야 할 절은 네 개다. 첫째, 실행법이다. 설치와 실행 커맨드를 복사해 붙일 수 있는 형태로 적는다. 둘째, 검증 증빙이다. 단위 체크·대조값·극한값 3종의 기록으로, 루브릭이 필수 항목으로 정해 둔 부분이다. 셋째, 재사용 도구다. 서브프로젝트 공통 요건인 "본인의 사다리 산출물 2개 이상 재사용"을 어느 도구로 충족했는지 명시한다. 넷째, AI 사용내역 선언문이다. 모든 평가물에 1쪽 첨부가 의무이며 미첨부는 부정행위로 처리된다.

표 14-2는 사람이 눈으로 훑는 용도지만, 앞의 네 항목은 기계로도 점검할 수 있다. 점검을 스크립트로 만들어 두면 최종 시험 당일 종료 직전에도 30초 만에 돌릴 수 있다.

# README 완성도 점검기 — 시험3 루브릭 "작동성" 대비
from pathlib import Path

REQUIRED = {                       # 점검 항목: README에 있어야 할 표제
    "실행법":     "## 실행법",
    "검증 증빙":  "## 검증",
    "재사용 도구": "## 재사용",
    "AI 선언문":  "## AI 사용내역",
}

def check_readme(repo_dir):
    """repo_dir의 README.md에서 필수 절 유무를 점검한다."""
    text = Path(repo_dir, "README.md").read_text(encoding="utf-8")
    return {name: (head in text) for name, head in REQUIRED.items()}

for name, ok in check_readme(".").items():   # 프로젝트 repo에서 실행
    print(f"{name}: {'통과' if ok else '누락'}")

14.4.2 최종 시험 규정 브리핑

발표회가 끝나면 남은 것은 15주차 최종 시험(40점)뿐이므로, 운영 규정을 여기서 마지막으로 확인한다. 주제는 당일 공개되며 전원 동일 구조에 학번별 파라미터가 배정된다. 시작 시 빈 repo 첫 커밋이 의무고, 30분마다 스냅샷 커밋을 남기며, 2시간 내 커밋 5회 이상을 채워야 한다. 종료 즉시 업로드하면 결과물은 동결된다. 사후 수정분은 채점에서 제외된다.

당일 장애에 대비한 비상 프로토콜은 강의계획서와 부록 E에 명문화되어 있고, 15장에서 유형별 대응으로 다시 다룬다. 여기서 할 일은 30분 스냅샷 커밋을 규정대로 남겨 두는 것이다. 그러면 장애가 나도 그때까지의 작업이 부분 채점으로 인정된다. 30분 커밋은 규정이기 이전에 보험인 셈이다.

14.5 실습 14: 서브프로젝트 발표회 (120분)

15.1 최종 시험 규정: 조문과 이유

시험 규정을 처음 읽으면 통제 장치의 목록으로 보인다. 그러나 조문 하나하나는 학생의 점수를 지키도록 설계되어 있다. 빈 repo 첫 커밋은 시작 시각의 증거가 되고, 30분 스냅샷은 장애가 나도 그때까지의 작업을 인정받게 한다. 규정을 이유와 함께 읽어 두면 시험장에서 규정 때문에 당황할 일이 없다.

표 15-1은 최종 시험 규정 전체를 조문과 이유의 쌍으로 정리한 것이다.

15.1.1 당일 주제와 학번별 파라미터

주제는 당일 공개된다. 전원이 같은 구조의 문제를 받되 물질계, 조업조건, 데이터 시드는 학번별 파라미터로 달라진다. 옆 사람의 코드를 그대로 가져오면 실행은 되지만 답이 틀리는 구조다. 그래서 시험장에서 유일하게 쓸모 있는 외부 자료는 남의 코드가 아니라 본인의 도구 사다리와 위키다.

1주차에 배포된 규정이 예시하는 주제 유형은 세 가지다. 학번별 이성분계의 기포점/이슬점 계산기와 T-xy 작도(NIST 대조 검증 포함), 학번별 recycle 공정의 물질수지 정합성 검사와 흐름 시각화, 그리고 학번별 실험 데이터 회귀와 이상치 자동 탐지 리포트 생성기. 각각 9장, 10장, 12~13장의 도구가 코어 부품이다. 어느 유형이 나와도 이미 한 번 만들어 본 것의 변형이다.

15.1.2 커밋 규정과 커밋 포렌식

채점자는 코드만 읽지 않는다. 커밋 이력에서 작업의 시간 구조를 읽는다. 이를 커밋 포렌식(commit forensics)이라 한다. 커밋 이력이 어떻게 읽히는지, 두 제출물의 로그를 나란히 놓고 보자.

# 제출물 ㄱ
9f3a1c2 14:00 시험 시작 (빈 커밋)
5b7e881 14:12 계획: PLAN.md — 함수 3개로 분해
02c9df4 14:31 스냅샷: antoine 함수 + 대표값 1건 확인
77aa310 15:02 스냅샷: 기포점 이분법, x=1 극한 검증 통과
c4d19e7 15:29 스냅샷: T-xy 작도 초안, README에 검증 기록
e8b02f5 15:55 최종: 예외 처리 + AI 사용내역 선언문

# 제출물 ㄴ
a11f9c0 15:58 완성 (파일 12개, +512줄)

제출물 ㄱ은 커밋 6회, 30분 간격 스냅샷, 메시지마다 그 시점의 작업이 드러난다. 제출물 ㄴ은 커밋 1회뿐이다. 커밋 5회 규정 위반이면서, 첫 커밋이 곧 완성본이라 자동으로 플래그가 붙는 유형이다. 플래그는 곧바로 부정행위 판정이 아니라 구술 평가에서의 소명 대상이지만, 지목 구술에서 본인 코드를 설명하지 못하면 소명의 길이 없다.

스냅샷 커밋의 다른 얼굴은 보험이다. 노트북이 죽거나 네트워크가 끊겨도, 마지막 스냅샷까지의 작업은 부분 채점(partial credit)의 근거로 인정된다. 30분마다 커밋하라는 조문은 감시가 아니라 학생 쪽의 안전장치다.

15.2 루브릭 해부: 40점은 어디서 오고 어디서 사라지는가

루브릭은 1주차에 전문이 배포되었다. 15주 내내 같은 표였으므로 암기가 아니라 해석이 남은 과제다. 표 15-2에 전문을 다시 싣는다.

15.2.1 작동성 14점: 채점자는 README만 읽는다

"README대로 실행 5점"의 의미를 정확히 새겨야 한다. 채점자는 저자가 아니다. 자동 스모크 테스트 하네스가 README에 적힌 실행 방법을 문자 그대로 따라 돌린다. README에 없는 암묵지(특정 폴더에서 실행해야 한다든가, 파라미터 파일을 먼저 옮겨야 한다든가)는 실행 실패로 기록된다. 실행이 안 되면 핵심 기능 6점을 증명할 길도 함께 사라진다.

검증 증빙이 필수 항목이라는 조건도 여기 걸려 있다. 단위 체크, 대조값, 극한값의 확인 결과가 README에 기록되어 있지 않으면 작동성 차원에서 만점이 불가능하다. 코드가 돌아간다는 사실과 결과가 옳다는 증거는 별개이고, 이 수업은 증거 쪽에 점수를 준다.

15.2.2 코드 이해 10점: 0점 게이트가 있는 유일한 차원

구술 평가에서 채점자가 repo의 아무 줄이나 지목해 설명을 요구한다. 세 번 지목해서 두 번 이상 설명하지 못하면 이 차원 전체가 0점이다. 이 조작적 정의는 1주차부터 공지된 것으로, "돌아가는데 설명 못 함"을 걸러 내는 이 수업의 마지막 관문이다. "이 줄을 바꾸면 출력이 어떻게 되는가"라는 예측 3점은 시험1의 출력 예측 문항과 같은 유형이다. AI 없이 남긴 개인 두뇌를 여기서 다시 쓴다.

15.2.3 프롬프트 전략 8점: 시험 중의 습관이 그대로 채점된다

이 차원의 채점 원본은 학생이 제출하는 파일이 아니라 게이트웨이 서버측 로그다. 시험이 끝난 뒤 잘 꾸민 기록으로 만회할 수 없고, 시험 중에 실제로 어떻게 물었는가가 전부다. 문제를 함수 단위로 분해해 요청하고, 생성 결과의 결함을 짚어 개선을 요구한 흔적이 4점을 만든다. 에러 메시지를 붙여 원인을 좁혀 간 대화가 2점, 대조값을 확인하는 질문이 2점이다. 14주 동안의 습관이 있다면 따로 준비할 것이 없는 차원이다.

15.2.4 발표 8점, 그리고 배점이 말하는 전략

구술 평가는 시험주간에 1인 3분 데모와 지목 구술 2분으로 진행된다. 3분 구성은 14장에서 훈련한 문제정의→데모→화공 해석 그대로다. 발표 5점에 Q&A 3점이다. 서브프로젝트 발표회가 이 형식의 리허설이었다.

배점 구조를 계산해 보면 전략이 나온다. 가상의 두 제출물을 루브릭으로 채점한 결과가 표 15-3이다.

기능을 더 많이 완성한 쪽의 총점이 15점 낮다. 이해를 포기한 채 기능만 늘리는 전략은 코드 이해 게이트 하나로 점수를 잃는다. 반대로 기능이 3분의 2뿐이어도 검증 증빙과 설명이 갖춰지면 30점대가 나온다. 이 산술이 다음 절의 시간 배분 전략을 결정한다.

15.3 2시간의 전략: 작동 우선, 증빙은 중간에

최종 시험은 AI 협업 사이클 여섯 블록 전체를 2시간 안에 한 바퀴 돌리는 시험이다. 매주 실습에서 블록 하나씩을 키웠다면, 오늘은 여섯 개를 이어 붙인다.

15.3.1 시간 배분 모델

표 15-4는 120분의 기본 배분이다. 절대 규칙이 아니라 기준선이며, 기준선이 있어야 이탈을 감지할 수 있다.

이 시간표를 따르면 커밋은 저절로 7회 안팎이 된다. 규정 최소치 5회는 목표라기보다 부산물이다. 최종 push를 1:55에 두는 이유도 단순하다. 2:00 정각의 push는 네트워크 지연 하나로 동결 시한을 넘길 수 있다.

구간마다 논리가 있다. 계획 구간의 15분은 코드를 한 줄도 만들지 않는 시간이지만, PLAN.md의 함수 단위 분해가 그대로 프롬프트 전략 4점의 첫 증거가 된다. 코어 구간 45분의 원칙은 작동 우선이다. 뼈대를 먼저 세우고 실행 가능한 상태를 유지하며 조금씩 키운다. 프로그래밍 교재들이 점진적 개발(incremental development)이라 부르는 이 습관은 5장에서 도입했고, 시간 압박 아래에서 진가를 발휘한다. 한 번에 조금만 바꾸면 버그가 생겨도 방금 바꾼 곳만 의심하면 되기 때문이다.

검증 구간을 코어 직후, 확장 이전에 두는 배치가 이 모델의 핵심 설계다. 검증 증빙은 작동성 14점의 필수 항목이면서 프롬프트 전략의 검증 습관 2점과도 연결된다. 기능을 다 만든 뒤 검증하겠다는 계획은 15주 내내 본 실패 패턴이다. 확장이 늦어지면 증빙이 통째로 사라진다. 코어가 돌아가는 즉시 대조값 1점을 확보해 README에 적고 커밋하라. 그 순간부터 무슨 일이 생겨도 "검증된 코어"까지는 인정받는다.

15.3.2 첫 15분: 예제로 보는 분해

def bubble_T(x1, P, ant1, ant2, T_low, T_high):
    """이분법으로 기포점 온도를 구한다. P는 kPa, T는 K."""
    def f(T):                       # f(T) = x1*p1* + x2*p2* - P
        p1 = antoine(T, *ant1)      # 성분 1 증기압 [kPa]
        p2 = antoine(T, *ant2)      # 성분 2 증기압 [kPa]
        return x1 * p1 + (1 - x1) * p2 - P
    for _ in range(60):             # 60회 반복이면 구간 폭이 충분히 줄어든다
        T_mid = (T_low + T_high) / 2
        if f(T_low) * f(T_mid) <= 0:   # 부호가 바뀌는 쪽 절반을 남긴다
            T_high = T_mid
        else:
            T_low = T_mid
    return T_mid                    # 기포점 [K]

15.4 비상 프로토콜: 막힘과 장애

비상은 두 종류다. 내 코드가 막히는 것과 인프라가 무너지는 것이다. 대응 원칙이 다르므로 나눠 다룬다.

15.4.1 코드가 막혔을 때: 디버깅 triage

디버깅은 실험 과학처럼 진행한다. 증상을 보고 가설을 하나 세우고, 그 가설을 배제할 수 있는 테스트를 하나 실행한다. 가설 없이 코드를 이리저리 바꿔 보는 것을 무작위 수정(random walk programming)이라 하는데, 시간이 무한할 때조차 느린 방법이고, 시험장에서는 시간을 가장 많이 잃는 경로다.

에러 메시지가 있다면 절반은 온 것이다. 메시지 전문을 그대로 AI에 붙여넣고 원인 후보 3개와 각각의 확인 방법을 요구하라. 11주차 디버깅 실습에서 연습한 패턴이며, 이 대화 자체가 디버깅 프롬프트 2점의 증거로 로그에 남는다.

한 버그에는 타임박스(timebox)를 건다. 15분을 넘기면 두 갈래 중 하나를 고른다. 하나는 후퇴(retreating)다. 마지막으로 작동하던 스냅샷 커밋으로 되돌아가 거기서 다시 쌓는다. 30분 스냅샷 규정의 세 번째 기능이 여기 있다. 후퇴 지점이 항상 30분 이내 거리에 존재한다. 다른 하나는 우회다. 그 기능을 축소하거나 제외하고 README의 한계 항목에 기록한다. 한계·개선점 3점은 이때 오히려 확보된다.

말로 푸는 방법도 있다. 문제를 남에게(상대가 없으면 오리 인형에게라도) 소리 내어 설명하다가 스스로 답을 발견하는 현상은 고무 오리 디버깅(rubber duck debugging)이라는 이름이 붙을 만큼 흔하다. 시험장에서 오리의 자리는 AI가 대신한다. "지금 상황을 설명할 테니 내 가정 중 틀린 것을 찾아 줘"라고 쓰는 순간, 설명하는 행위 자체가 구술 평가 리허설이 된다.

15.4.2 인프라가 무너졌을 때

강의계획서에 명문화된 비상 프로토콜은 다섯 겹이다. 예비 API 제공자 1개가 게이트웨이에 상시 등록되어 있고, 시험은 유선랜 전산실습실에서 치르며, 예비 노트북 2~3대가 준비되고, 30분 스냅샷 커밋이 부분 채점의 근거가 되며, 전면 장애 시에는 업로드가 24시간 연장되고 발표만 당일 진행된다. 학생이 외울 것은 프로토콜의 존재보다 자기 행동 수칙이다.

장애가 의심되면 먼저 손을 들어 감독에게 알린다. 장애 시각이 기록되어야 구제의 기준점이 생긴다. 그리고 커밋을 멈추지 않는다. Git은 로컬 저장소이므로 네트워크가 죽어도 커밋은 계속 쌓을 수 있고, push만 복구 후에 몰아서 하면 이력의 시각은 그대로 보존된다. API가 죽어 AI를 못 쓰는 상황이라면, 그때부터는 시험1에서 검증한 개인 두뇌(코드 읽기와 의사코드)로 버티는 구간이다.

표 15-5는 비상 유형별 첫 행동을 요약한 것이다.

15.5 수업 이후의 학습 OS

종강하면 수업은 끝나지만 repo는 남는다. 도구 사다리 아홉 개, 15주치 위키, 그리고 게이트웨이 로그에 찍힌 수백 번의 프롬프트가 이 학기의 물증이다. 마지막 절은 그 물증을 자산으로 바꾸는 이야기다.

15.5.1 15주의 회고: 무엇이 몸에 남았는가

1주차에 역산했던 7대 역량을 되짚어 보자. 문제 분해(C1)와 생성 코드 읽기(C2)는 도구가 바뀌어도 그대로 쓰이는 근육이다. Git 규율(C3)은 어느 연구실, 어느 회사에서든 협업의 공용어다. 화공 문제의 계산 가능화(C4)는 3학년 전공에서 곧바로 이자가 붙는다. 검증 루틴 3종(C5)과 시간 압박 하 완주(C6)는 오늘 최종 시험이 측정한 것이고, 학습 OS 운영(C7)은 측정이 끝나도 계속 돌아간다.

이 책이 15주 내내 연습시킨 태도를 요약하는 문장을 마지막으로 적는다. 목표는 프로그램을 작동시키는 것만이 아니라 작동시키는 방법을 배우는 것이다(Downey, Think Python). 최종 시험의 40점은 그 방법이 몸에 남았는지를 측정하는 눈금이다.

15.5.2 위키와 도구의 유지·확장

위키의 성장단계 태그(#seed → #growing → #evergreen)는 학기와 함께 끝나지 않는다. 다음 학기 전공 노트를 같은 구조로 이어 가라. 정리기와 플래시카드 생성기가 이미 그 구조를 읽고 쓰도록 만들어져 있으므로, 새 과목의 노트를 넣는 순간 2~4주에 조립한 파이프라인이 다시 돌기 시작한다. 방학 중에는 주 1회 의미 커밋 정도의 낮은 리듬이면 충분하다. 리듬이 끊긴 위키는 몰아서 복구되지 않는다는 것을 마일스톤 채점이 15주 동안 보여 주었다.

도구 사다리는 3학년 과목의 부품 창고가 된다. 분리공정에서 McCabe-Thiele 작도를 만나면 도구⑤⑥이 그대로 하부 구조다. 서브프로젝트 주제 풀의 1번이 그 예고편이었다. 재사용의 손동작은 한 줄이다.

# 3학년 분리공정 과제 — 2학년 때 만든 도구⑤를 부품으로 재사용
from tools.antoine import antoine          # 도구⑤ (8장), log10·kPa·K 규약
p_star = antoine(T, A, B, C)               # T[K] 입력 → p*[kPa]

import 한 줄이 가볍게 보이지만, 이 한 줄이 성립하려면 함수에 단위 규약이 문서화되어 있고 검증 기록이 남아 있어야 한다. 15주 동안 README와 주석에 단위를 적게 한 규칙이 미래의 자신에게 지불한 보험료였던 셈이다.

15.5.3 검증 루틴은 코드 밖으로 나간다

단위 체크, 대조값, 극한값은 코드 검증법이기 이전에 공학 계산 일반의 검증법이다. 물질수지를 손으로 풀 때 나가는 유량이 들어오는 유량보다 크면 어딘가 틀린 것이고, 실험 데이터의 피팅 결과는 알려진 문헌값 한 점과 대조해야 하며, 극한 조건에서 말이 되는지는 보고서의 어느 수치에든 물을 수 있다. AI가 쓴 보고서 초안부터 논문 요약과 설계 계산까지, 앞으로 마주칠 모든 생성물에 같은 세 질문을 던지면 된다. 이 수업이 남기려 한 습관이 이것이다.

AI 도구는 바뀐다. 이 책이 다룬 모델과 게이트웨이도 몇 년 안에 다른 이름으로 대체될 것이다. 그러나 문제를 분해하고, 생성물을 읽고, 화학공학의 물리로 검증하는 사이클은 도구의 이름과 무관하게 남는다. 사이클을 가진 사람에게 새 도구는 부품 교체에 가깝다.

용어 정리

커밋 포렌식 (commit forensics)

커밋 이력의 시간 구조로 작업 과정을 판독하는 채점 기법. 첫 커밋이 완성본인 repo는 자동 플래그 대상이다.

부분 채점 (partial credit)

장애 등으로 미완성인 제출물에서 완료가 입증된 부분까지 점수를 인정하는 채점. 30분 스냅샷 커밋이 그 근거가 된다.

무작위 수정 (random walk programming)

가설 없이 코드를 이리저리 바꿔 보며 우연한 성공을 기다리는 디버깅 안티패턴.

타임박스 (timebox)

한 문제에 쓸 시간의 상한을 미리 정해 두는 시간 관리 기법. 이 수업 기준은 버그당 15분이다.

후퇴 (retreating)

마지막으로 작동하던 버전으로 되돌아가 거기서 다시 쌓는 디버깅 전략. 스냅샷 커밋이 후퇴 지점을 제공한다.

고무 오리 디버깅 (rubber duck debugging)

문제를 소리 내어 설명하는 행위 자체로 원인을 발견하는 기법. 설명 상대는 사람, 인형, AI 무엇이든 된다.

참고문헌·출처

본 교재의 집필에는 아래 오픈 라이선스 공개 자료를 구조·사실 근거 코퍼스로 참조하였다. 각 항목의 라이선스는 수집 시점(2026-07-16, KST)에 원 사이트·저장소에서 직접 확인한 것이다.

프로그래밍 교재 코퍼스

• Downey, Allen B. Think Python: How to Think Like a Computer Scientist, 2nd ed. Green Tea Press. greenteapress.com/wp/think-python-2e · CC BY-NC 3.0 Unported
• Severance, Charles R. Python for Everybody: Exploring Data in Python 3. py4e.com · CC BY 4.0(사이트) / CC BY-NC-SA 3.0(도서 본문)
• Sweigart, Al. Automate the Boring Stuff with Python, 3rd ed. automatetheboringstuff.com · CC BY-NC-SA 3.0
• DeNero, John. Composing Programs. composingprograms.com · CC BY-NC-SA 3.0

화학공학 교재 코퍼스

• Introduction to Chemical Engineering Processes. Wikibooks. en.wikibooks.org · CC BY-SA 3.0
• Engineering LibreTexts 교재군(eng.libretexts.org): Foundations of Chemical and Biological Engineering I; Distillation Science; Phase Relations in Reservoir Engineering; Fluid Mechanics (Bar-Meir); Slurry Transport (Miedema) · 페이지별 CC BY 4.0 · CC BY-NC-SA 4.0 · GNU FDL 1.3 (각 페이지 명기 기준)
• NIST Chemistry WebBook, NIST Standard Reference Database 69. webbook.nist.gov · 미국 연방정부 표준참조데이터(공공 접근); 물성 대조값의 1차 출처

계산공학·ML 코퍼스

• Kitchin, John R. pycse: Python Computations in Science and Engineering. github.com/jkitchin/pycse · 저장소 GPL-2.0 / 북 챕터 GNU FDL 1.3
• Ulissi, Zachary W. CMU 06-325: Machine Learning for Chemical Engineers (Fall 2022 강의자료). github.com/ulissigroup/F22-06-325 · CC BY 4.0
• Kitchin, John R. CMU 06-642: Data Science and Machine Learning in Chemical Engineering (Spring 2026 공개 강의자료). github.com/jkitchin/s26-06642 · 명시 라이선스 없음(저자 공개 게시); 구조 참조에 한정 사용
• Fangohr, Hans. Introduction to Python for Computational Science and Engineering. github.com/fangohr · CC BY-NC 4.0

판권 고지