14장 엔지니어의 발표법

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분)