고쳐 달라고 말하기 - 증상·재현 방법·기대 결과

이 장에서 배우는 것

프로그램이 실행된다고 해서 원하는 일을 하고 있다는 뜻은 아니다. 앞 장에서 살펴본 오류 메시지가 나타나지 않아도 계산 결과가 틀릴 수 있다. 이때 AI에게 “안 돼요”라고만 말하면 AI는 무엇을 바꿔야 하는지 추측하게 된다. 추측한 수정이 우연히 맞을 수도 있지만, 원래 잘되던 부분까지 바꿀 수도 있다.

이 장에서는 고장을 설명하는 짧은 보고서를 쓰고, 고치기 전후의 결과를 나란히 확인한다. 목표는 AI에게 긴 설명을 보내는 일이 아니다. 내가 본 현상과 원하는 동작을 구별하고, 다른 사람도 같은 현상을 확인할 수 있을 만큼 구체적으로 전달하는 일이다.

• 증상·재현 방법·기대 결과를 세 줄로 작성한다.
• 문제를 계속 드러내는 가장 작은 입력을 찾는다.
• 같은 입력 묶음으로 수정 전후를 비교하고, 그대로 유지되어야 할 결과도 확인한다.
• 대화가 같은 자리를 맴돌 때 현재 상태를 정리해 새 대화로 옮긴다.

문제 상황

스터디에서 푼 연습 문제의 점수 평균을 계산한다고 하자. 점수는 이미 숫자로 준비되어 있다. 계산 규칙은 간단하다. 입력된 점수를 모두 더하고 입력한 점수의 개수로 나눈다. 여기서 0점은 빠진 기록이 아니라 실제 점수다. 따라서 평균에 포함해야 한다. 점수가 하나도 없으면 평균을 계산할 수 없으므로 “값 없음”으로 표시하기로 한다.

AI가 만든 프로그램에 80, 0, 100을 넣었더니 평균이 90으로 나왔다. 창이 멈추지도 않았고 빨간 오류 메시지도 없었다. 그러나 세 점수의 합은 180이고 점수는 세 개이므로 평균은 60이어야 한다. 프로그램이 중간에 0점을 빼 버린 것이다.

이런 잘못된 동작을 버그(bug)라고 부른다. 이번 문제는 실행을 막는 문법 오류가 아니라 계산 규칙을 잘못 옮긴 버그다. AI에게 다음과 같이 말하면 문제의 범위가 드러나지 않는다.

평균 계산이 이상하다. 알아서 고쳐 달라.

AI는 평균 표시 자릿수, 숫자 변환, 빈 입력 처리 중 무엇이 문제인지 알 수 없다. 심지어 0을 제외하는 것이 사용자의 의도라고 생각할 수도 있다. 고칠 근거는 AI가 아니라 프로그램의 목적과 내가 확인한 실행 결과에서 나와야 한다.

우리는 입력을 간단하게 줄이고, 기대하는 계산을 직접 적은 뒤, 두 함수의 결과를 비교하는 프로그램을 만든다. 함수는 이름을 붙여 두고 필요할 때 실행하는 코드 묶음이다. 완성 코드에는 잘못된 함수와 고친 함수가 함께 들어간다. 둘에 같은 입력을 주어 무엇이 달라졌는지 확인한다.

고장을 설명하는 세 줄

수정 요청의 중심은 증상, 재현 방법, 기대 결과다. 증상은 실제로 관찰한 일이다. 재현 방법은 다른 사람도 같은 현상을 다시 보게 하는 절차다. 기대 결과는 그 상황에서 프로그램이 해야 하는 일이다. 원인을 짐작하는 말과 관찰한 사실은 구별해야 한다.

증상: 점수 [0, 20]의 평균이 20.00으로 나온다.
재현 방법: 현재 평균 함수에 [0, 20]을 전달해 반환값을 확인한다.
기대 결과: 0점도 점수 하나이므로 (0 + 20) / 2인 10.00이 나와야 한다.

대괄호로 둘러싼 [0, 20]은 Python에서 여러 값을 순서대로 담는 리스트(list)다. 지금은 “점수 두 개가 들어 있는 묶음”으로 읽으면 충분하다. 반환값은 함수가 계산을 마치고 호출한 곳에 돌려주는 값이다. 화면에 무엇이 보였는지뿐 아니라 어떤 입력에 어떤 값이 돌아왔는지도 증상이 될 수 있다.

버그 보고 세 줄에 들어갈 정보

항목	적을 내용	이번 문제의 예
증상	실제로 나온 값이나 동작	[0, 20]의 평균이 20.00이다.
재현 방법	같은 현상을 만드는 입력과 절차	평균 함수에 [0, 20]을 전달한다.
기대 결과	원하는 값과 그 이유	0을 포함해 두 개로 나누므로 10.00이다.

세 줄은 글자 수 제한이 아니다. 실행 파일이나 오류가 발생한 위치가 필요하면 재현 방법에 덧붙인다. 다만 실행할 때마다 같게 나타나는 문제라면 “가끔 이상하다”라고 흐리게 적지 않는다. 반대로 한 번만 본 현상을 매번 일어난다고 단정하지도 않는다.

그다음에는 수정 범위를 정한다. 이번에는 평균 계산만 고치면 된다. 출력 모양을 새로 꾸미거나 입력 방식을 바꾸면 확인할 일이 늘어난다. 다음 문장을 세 줄 아래에 덧붙일 수 있다.

0을 평균에 포함하도록 계산 부분을 고쳐 달라. 빈 입력은 기존처럼 None을 반환하고, 함수 이름과 입력 방식은 유지해 달라. 바꾼 줄과 바꾼 이유도 설명해 달라.

None은 값이 없음을 나타내는 Python의 특별한 값이다. 이 예제에서는 점수가 하나도 없어 평균을 정하지 못했다는 뜻으로 쓴다. 점수의 평균이 0인 경우와는 구별한다. 빈 입력의 처리까지 명시하면 AI가 임의로 0을 돌려주도록 바꾸는 일을 줄일 수 있다.

재현 입력을 줄이고 같은 조건으로 비교한다

실제로 발견한 입력은 수십 개의 점수일 수 있다. 처음에는 그 입력을 보관해 두되, AI에게 설명할 때는 문제를 유지하는 작은 입력을 따로 찾는다. 입력이 작으면 사람이 직접 계산하기 쉽고, AI의 설명이 맞는지도 확인하기 쉽다.

[80, 0, 100]에서 80을 빼면 [0, 100]이 된다. 잘못된 함수는 100을 내놓고 올바른 평균은 50이므로 문제가 남아 있다. 숫자를 더 작게 바꾸어 [0, 20]으로 만들어도 같은 종류의 차이가 생긴다. 이제 합과 개수를 머릿속으로 확인할 수 있다.

여기서 0을 지워 [20]만 남기면 두 함수 모두 20을 내놓는다. 입력이 짧아졌지만 고장을 설명하지 못한다. 재현 입력을 줄인다는 말은 값을 무조건 적게 남기라는 뜻이 아니다. 확인하려는 잘못된 동작이 계속 나타나는 범위에서 줄이라는 뜻이다.

[0]도 이번 문제를 보여 주지 못한다. 우리가 살펴볼 잘못된 함수는 남은 점수가 없을 때 0을 반환하므로, 올바른 평균과 우연히 같아진다. 따라서 0 하나와 0이 아닌 수 하나가 필요하다. [0, 20]은 이 계산 문제를 드러내는 작은 입력이다. 다만 이 입력 하나가 모든 종류의 평균 계산 문제를 대표하는 것은 아니다.

입력을 줄일 때는 한 번에 한 부분씩 바꾸고 실행 결과를 다시 본다. 값을 지운 뒤에도 증상이 남는지 확인하고, 남지 않으면 직전 입력으로 돌아간다. 값의 개수와 크기를 동시에 크게 바꾸면 어떤 변경 때문에 증상이 사라졌는지 놓치기 쉽다.

작은 입력으로 수정을 요청한 뒤에는 원래 입력도 다시 실행한다. 작은 예시만 맞추는 수정일 수 있기 때문이다. 예를 들어 [0, 20]일 때만 10을 반환하도록 조건을 추가해도 그 예시 하나는 통과한다. 원하는 것은 특정 답을 외운 코드가 아니라 “0도 개수에 포함한다”라는 규칙을 구현한 코드다.

고친 뒤에는 원래 잘되던 경우도 확인한다. 수정 때문에 다른 동작이 다시 잘못되는 일을 회귀(regression)라고 한다. 0이 없는 점수, 빈 입력, 0만 있는 점수를 함께 넣어 보면 이번 수정이 주변 동작을 건드렸는지 일부 확인할 수 있다.

이번 비교기는 입력 묶음을 한 번 정한 뒤 두 함수에 똑같이 전달한다. 두 반환값이 다를 때만 전후 값을 출력한다. 같게 나온 항목은 화면에서 생략하되, 마지막에 전체 비교 수와 차이 수를 적어 실행 범위를 알린다.

여기에는 한계가 있다. 두 함수가 같은 오답을 내놓아도 비교기는 차이를 표시하지 않는다. 따라서 “차이가 두 개다”는 관찰 결과이고, “두 개 모두 올바르게 고쳐졌다”는 별도의 판단이다. 우리는 달라진 두 입력의 평균을 직접 계산하고, 같게 나온 입력도 정한 규칙에 맞는지 살펴봐야 한다.

대화가 제자리를 돌 때 새로 시작한다

AI가 첫 수정에서 문제를 해결하지 못할 수 있다. 이때 “아직 안 된다”를 반복하기보다 수정한 코드를 실제로 실행한 결과를 보낸다. AI의 설명이 아니라 내 컴퓨터에서 관찰한 값이 다음 수정의 출발점이다.

수정한 함수를 실행했지만 [0, 20]이 여전히 20.00을 반환한다. 기대값은 10.00이다. 현재 코드에는 0을 거르는 조건이 남아 있다. 이 조건이 계산 개수에 미치는 영향을 확인해 달라.

수정 제안을 받을 때마다 현재 파일과 맞는지도 확인한다. AI가 지우라고 한 줄이 이미 없거나, 이전 버전의 함수 이름을 계속 사용한다면 대화 속 코드와 실제 파일이 어긋났을 수 있다. 이 상태에서 설명만 덧붙이면 서로 다른 코드를 두고 이야기하게 된다.

새 대화를 시작할 시점은 질문 횟수로 정하지 않는다. 같은 잘못된 수정이 되풀이되거나, 이미 취소한 요구를 다시 적용하거나, 현재 코드에 없는 줄을 계속 지적할 때가 신호다. 우선 실제로 실행한 파일과 명령이 맞는지 확인한다. 그다음 현재 코드와 세 줄 보고서를 새 대화에 옮긴다.

새 대화에 지난 대화 전체를 붙일 필요는 없다. 해결되지 않은 증상, 가장 작은 재현 입력, 기대 결과, 유지할 동작, 현재 실행하는 코드면 출발할 수 있다. 이미 시도한 방법이 있다면 무엇을 바꾸었고 어떤 결과였는지 짧게 덧붙인다.

현재 코드를 기준으로 평균 계산을 수정해 달라. 증상은 [0, 20]에서 20.00이 나오는 것이다. 기대값은 10.00이다. 0도 점수 개수에 포함하고, 빈 입력은 None을 유지해야 한다. 앞선 수정에서는 출력 형식만 바뀌어 증상이 남았다. 아래 코드는 지금 실행 중인 코드다.

새 대화를 여는 것 자체가 해결책은 아니다. 같은 불분명한 설명을 옮기면 같은 추측이 반복될 수 있다. 새로 시작하는 목적은 현재 상태와 필요한 조건을 한곳에 모으는 데 있다. 현재 파일을 기준으로 변경 전후의 차이(diff)를 살펴보는 습관도 함께 필요하다. 차이 검토란 어떤 줄이 추가되고 삭제되었는지 읽어 수정 범위를 확인하는 일이다.

완성 코드

다음 코드를 main.py에 저장한다. 빈 줄을 포함해 59줄이며 외부 파일이나 추가 설치가 필요하지 않다. 첫 함수는 비교를 위해 버그를 의도적으로 남겼다. 둘째 함수는 합과 개수를 모두 원래 입력에서 구한다. 비교 대상은 숫자 목록이며, 문자열을 숫자로 바꾸는 기능은 이번 범위에 넣지 않는다.

def average_before(scores):
    if not scores:
        return None

    kept = []
    for score in scores:
        if score != 0:
            kept.append(score)

    if not kept:
        return 0.0
    return sum(kept) / len(kept)


def average_after(scores):
    if not scores:
        return None
    return sum(scores) / len(scores)


def show_value(value):
    if value is None:
        return "값 없음"
    return f"{value:.2f}"


def main():
    cases = [
        ("처음 발견한 입력", [80, 0, 100]),
        ("작게 줄인 입력", [0, 20]),
        ("0이 없는 입력", [10, 20]),
        ("0만 있는 입력", [0, 0]),
        ("빈 입력", []),
        ("음수가 섞인 입력", [-10, 0, 10]),
    ]
    changed = 0

    print("평균 계산 수정 전후 비교")
    for name, scores in cases:
        before = average_before(scores)
        after = average_after(scores)
        if before == after:
            continue

        changed += 1
        print(f"[{name}]")
        print(f"입력: {scores}")
        print(f"수정 전: {show_value(before)}")
        print(f"수정 후: {show_value(after)}")
        print()

    print(f"전체 비교: {len(cases)}개")
    print(f"결과 차이: {changed}개")
    print(f"같은 결과: {len(cases) - changed}개")
    print("차이가 올바른 수정인지는 기대 결과와 대조한다.")


if __name__ == "__main__":
    main()

줄별 해설

1줄의 def는 함수 정의를 시작한다. average_before는 수정 전 함수의 이름이고, 괄호 안 scores는 함수가 전달받은 점수 묶음을 부르는 이름이다. 이름 뒤의 콜론은 이어지는 들여쓴 코드가 이 함수의 내용임을 알린다.

2~3줄은 입력이 비었는지 확인한다. if는 조건이 맞을 때만 아래 코드를 실행한다. not scores는 이 코드에서 점수 묶음이 비어 있으면 참이 된다. return None을 만나면 함수는 값이 없다는 표시를 돌려주고 끝난다.

5줄은 kept라는 빈 리스트를 만든다. 6줄의 for는 점수를 하나씩 꺼내 score라는 이름으로 다룬다. 7줄의 !=는 서로 다른지 비교한다. 0과 다른 점수만 8줄에서 append로 kept의 끝에 추가한다. 이 네 줄이 0점을 빼 버리는 원인이다.

10~11줄은 남은 점수가 없으면 0.0을 반환한다. 그래서 [0, 0]은 수정 전에도 결과가 0이다. 12줄의 sum은 합을, len은 항목 개수를 구한다. /는 나눗셈이다. 합과 개수를 모두 kept에서 구하기 때문에 0을 제외한 평균이 된다.

15~18줄은 수정 후 함수다. 빈 입력 처리는 유지하고, 합과 개수를 scores에서 바로 구한다. [0, 20]이라면 합은 20이고 개수는 2다. 0은 합을 늘리지는 않지만 항목 개수에는 포함된다. 0을 거르는 과정을 없애는 것이 수정의 핵심이다.

21~24줄은 값을 출력할 문자열로 바꾼다. is None은 값이 없는 표시인지를 확인한다. 24줄에서 f로 시작하는 문자열은 중괄호 안의 값을 글에 끼워 넣는다. :.2f는 숫자를 소수점 아래 두 자리까지 표시하라는 뜻이다. 계산 규칙을 바꾸는 부분은 아니다.

27줄은 비교 작업을 담는 main 함수를 정의한다. 28~35줄은 이름과 입력을 한 쌍씩 묶어 cases에 담는다. 소괄호 안의 두 항목은 한 쌍으로 다루며, 바깥 대괄호는 이런 쌍 여섯 개를 순서대로 담는다. 36줄의 changed는 차이가 난 항목 수를 세는 변수다. 변수는 값에 붙여 두는 이름이라고 생각하면 된다.

38줄은 제목을 출력한다. 39줄은 각 쌍에서 이름과 점수 목록을 꺼내 name과 scores에 넣는다. 40~41줄은 같은 scores를 두 함수에 전달하고 반환값을 각각 보관한다. 두 함수 모두 전달받은 목록 자체를 변경하지 않으므로 같은 입력을 나란히 비교할 수 있다.

42줄의 ==는 두 값이 같은지 비교한다. 같으면 43줄의 continue가 현재 항목의 나머지 처리를 건너뛰고 다음 항목으로 넘어간다. 숫자를 화면용 문자열로 바꾸기 전에 비교한다는 점도 살펴본다. 표시 자릿수가 같다는 이유로 계산 결과까지 같다고 판단하지 않는다.

45줄의 += 1은 기존 수에 1을 더해 다시 저장한다. 46~49줄은 차이가 난 항목의 이름, 입력, 수정 전 값, 수정 후 값을 출력한다. 48~49줄에서는 show_value 함수를 호출해 표시 형식을 맞춘다. 50줄의 빈 print()는 빈 줄 하나를 출력한다.

52~55줄은 전체 비교 수와 결과를 요약한다. 같게 나온 수는 전체 수에서 차이 수를 빼서 구한다. 마지막 문장은 이 프로그램이 두 함수의 차이를 보여 줄 뿐, 정답 여부를 스스로 판정하지는 않는다는 점을 알린다.

58~59줄은 이 파일을 직접 실행했을 때 main 함수를 호출하는 시작 부분이다. 지금은 main.py의 실행을 시작하는 관례적인 두 줄로 읽으면 된다. 4, 9, 13~14, 19~20, 25~26, 37, 44, 51, 56~57줄은 읽기 쉽게 나눈 빈 줄이다. Python은 이 빈 줄에서 별도의 작업을 하지 않는다.

실행 결과

main.py가 들어 있는 폴더에서 터미널에 다음 명령을 입력한다.

python3 main.py

예상 출력은 다음과 같다. 프로그램은 입력을 기다리지 않고 비교를 마친 뒤 끝난다.

평균 계산 수정 전후 비교
[처음 발견한 입력]
입력: [80, 0, 100]
수정 전: 90.00
수정 후: 60.00

[작게 줄인 입력]
입력: [0, 20]
수정 전: 20.00
수정 후: 10.00

전체 비교: 6개
결과 차이: 2개
같은 결과: 4개
차이가 올바른 수정인지는 기대 결과와 대조한다.

처음 발견한 입력의 기대값은 180을 3으로 나눈 60이다. 작게 줄인 입력의 기대값은 20을 2로 나눈 10이다. 두 항목의 수정 후 결과는 이 계산과 일치한다. 출력만 보고 넘어가지 말고 코드에서도 두 함수에 같은 목록을 전달했는지 확인한다.

화면에 개별 결과가 나오지 않은 네 항목도 의미가 있다. [10, 20]은 두 함수 모두 15, [0, 0]은 모두 0, 빈 입력은 모두 None, [-10, 0, 10]은 모두 0을 반환한다. 이 네 경우에서는 수정 전후 결과가 유지되었다. 다만 음수가 섞인 예시는 합이 0이어서 잘못된 나눗셈도 같은 결과를 낸다. 결과가 같다는 사실만으로 계산 과정까지 올바르다고 결론 내리면 안 된다.

마지막으로 변경한 줄을 검토한다. 고친 함수는 0을 걸러 새 목록을 만드는 부분을 없애고, 원래 목록의 합과 개수를 사용한다. 빈 입력 처리는 그대로다. 실행 결과와 변경한 코드가 같은 이유를 가리킬 때 수정 내용을 더 분명하게 이해할 수 있다.

실무에서 자주 틀리는 것

합에서만 0을 빼면 된다고 생각한다

0을 더해도 합은 같으므로 문제가 없다고 생각하기 쉽다. 그러나 아래 틀린 코드는 점수 개수까지 줄인다. 코드를 따로 실행하면 result에 20.0이 저장된다. 화면 출력은 없지만 계산 규칙은 틀렸다.

틀린 코드다.

scores = [0, 20]
kept = [score for score in scores if score != 0]
result = sum(kept) / len(kept)

대괄호 안에서 조건에 맞는 값만 모으는 표현도 새 목록을 만드는 방법이다. 표현이 짧아져도 0을 제외하는 문제는 그대로다. 아래처럼 입력 전체의 개수를 사용하면 result는 10.0이 된다. 이 짧은 예시는 입력이 비어 있지 않다고 정해 둔 경우다.

고친 코드다.

scores = [0, 20]
result = sum(scores) / len(scores)

수정 전후에 서로 다른 입력을 넣는다

수정 전에는 0이 있는 점수를 넣고 수정 후에는 0이 없는 점수를 넣으면 차이의 원인을 가릴 수 없다. 함수가 바뀐 영향과 입력이 바뀐 영향이 섞이기 때문이다. 아래 예시는 두 함수의 결과를 직접 비교하는 조건으로 적절하지 않다.

틀린 코드다.

before_scores = [0, 20]
after_scores = [10, 20]

같은 입력 내용으로 맞춘 코드다.

before_scores = [0, 20]
after_scores = [0, 20]

완성 코드에서는 이 실수를 줄이기 위해 scores 하나를 두 함수에 전달한다. 비교 중 한 함수가 입력 목록을 직접 바꾼다면 별도 복사가 필요할 수 있지만, 이번 두 함수는 목록을 읽기만 한다.

보고한 입력만 남기고 기존 확인 항목을 지운다

문제를 설명할 때는 작은 입력 하나가 유용하다. 그러나 수정 후 확인에서도 그 입력만 남기면 다른 동작이 바뀌었는지 보기 어렵다. 다음 코드는 재현에는 쓸 수 있지만 이번 수정의 확인 묶음으로는 부족하다.

틀린 코드다.

cases = [
    ("작게 줄인 입력", [0, 20]),
]

기존에 지켜야 할 동작도 남긴 코드다.

cases = [
    ("작게 줄인 입력", [0, 20]),
    ("0이 없는 입력", [10, 20]),
    ("0만 있는 입력", [0, 0]),
    ("빈 입력", []),
]

입력을 줄이는 작업과 확인 범위를 줄이는 작업은 목적이 다르다. 전자는 원인을 설명하기 쉽게 하고, 후자는 확인할 수 있는 동작 자체를 줄인다. 작은 재현 입력을 얻었더라도 원래 입력과 주변 확인 항목을 보관한다.

한눈에 보기

수정 요청부터 확인까지 남겨야 할 근거

할 일	남길 내용	판단할 때 주의할 점
증상 쓰기	입력과 실제 결과	추측한 원인을 사실처럼 적지 않는다.
재현 방법 쓰기	현재 코드에서 실행할 절차	실제로 실행한 파일을 기준으로 한다.
기대 결과 쓰기	원하는 값과 계산 근거	0점과 값 없음을 구별한다.
입력 줄이기	증상이 유지되는 작은 입력	줄인 뒤에도 문제가 남는지 실행한다.
수정 확인하기	같은 입력의 전후 결과와 코드 차이	같은 결과가 같은 정답을 뜻하지는 않는다.
새 대화 시작하기	현재 코드와 세 줄 보고서	대화 횟수보다 현재 상태의 혼선을 본다.

수정 요청을 잘 쓴다는 것은 AI가 이해할 법한 표현을 길게 늘어놓는 일이 아니다. 관찰한 현상을 다시 만들 수 있게 설명하고, 원하는 결과의 근거를 적는 일이다. AI의 답을 받은 뒤에도 실행과 비교를 맡아서 하는 사람은 사용자다.

연습 문제

1. 잘못된 평균 함수에 [0, 30]을 넣었더니 30.00이 나왔다. 증상·재현 방법·기대 결과를 세 줄로 작성하라.
2. [40, 0, 80, 120]에서 문제를 계속 보여 주는 입력을 두 값으로 줄여라. [0]만 남기면 왜 이번 버그를 보여 주지 못하는지도 설명하라.
3. 완성 코드의 입력 묶음 끝에 ("추가 입력", [0, 40])을 추가하라. 추가로 출력될 수정 전후 값과 마지막 집계 수를 먼저 예상한 뒤 실행해 비교하라.
4. AI가 현재 코드에 없는 kept라는 이름을 지우라고 반복한다. 새 대화를 시작할 때 전달할 내용을 작성하고, 새 대화를 열기 전에 확인할 일 한 가지를 적어라.

정답과 해설

1. 다음처럼 작성할 수 있다. 기대 결과에는 숫자뿐 아니라 왜 그 값인지도 적는다.

   증상: [0, 30]의 평균이 30.00으로 나온다.
   재현 방법: 현재 평균 함수에 [0, 30]을 전달한다.
   기대 결과: 두 점수의 합 30을 개수 2로 나눈 15.00이 나와야 한다.

2. [0, 80]을 남길 수 있다. 수정 전에는 80, 수정 후에는 40이므로 차이가 유지된다. [0, 40]이나 [0, 120]도 가능하다. [0]만 남기면 잘못된 함수의 kept가 비어 0.0을 반환하고, 고친 함수도 0을 1로 나누어 0.0을 반환한다. 같은 버그가 코드에 남아 있어도 이 입력의 결과에서는 드러나지 않는다.

3. 추가 항목은 수정 전 40.00, 수정 후 20.00이다. 전체 비교는 7개, 결과 차이는 3개, 같은 결과는 4개가 된다. 추가된 입력에서도 0이 개수에 포함되는지 확인한다. 예상한 값과 실행값이 다르면 입력을 넣은 위치와 실제 실행한 파일부터 살펴본다.

4. 먼저 저장한 현재 main.py와 실제 실행한 파일이 같은지 확인한다. 그다음 새 대화에는 지금 실행하는 함수 전체, 작은 재현 입력, 실제 결과, 기대 결과, 유지할 빈 입력 규칙을 전달한다. 예를 들어 다음처럼 시작할 수 있다.

   현재 실행하는 코드는 아래와 같다. [0, 20]에서 실제 반환값은 20.0이고 기대값은 10.0이다. 0을 점수 개수에 포함해야 한다. 빈 입력은 None을 유지해야 한다. 이전 대화에서는 현재 코드에 없는 kept를 수정하라는 제안이 반복되었다. 이 코드의 계산을 기준으로 수정하고 바뀐 줄을 설명해 달라.

   대화를 옮긴 뒤에도 새 코드를 실행하고 변경 부분을 읽는다. 기대값과 자동으로 대조하는 구체적인 검사 방법은 다음 장에서 다룬다.