2장 프롬프트로 함수 만들기

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/ 폴더에 저장한다."""