15장 최종 실기: 2시간의 전략

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 무엇이든 된다.