배우는 모드와 만드는 모드 - AI 를 선생으로 쓸 때와 일꾼으로 쓸 때

이 장에서 배우는 것

앞 장에서 AI가 내놓은 답을 판단하려면 기초가 필요하다는 점을 살펴보았다. 이번에는 같은 AI를 쓰더라도 요청하는 방식에 따라 공부의 과정이 어떻게 달라지는지 알아본다. 답을 받아 작업을 끝내는 일과, 그 답을 이해해 다음 문제를 스스로 풀 수 있게 되는 일은 서로 연결되어 있지만 같은 목표는 아니다.

개발자의 일에는 둘 다 필요하다. 낯선 개념을 익힐 때는 생각할 기회를 남겨 두어야 하고, 이미 이해한 작업을 마무리할 때는 구현을 맡겨 시간을 줄일 수 있다. 중요한 것은 매번 혼자 코드를 쓰는 일이 아니라, 지금 무엇을 익히려는지와 무엇을 완성하려는지를 구분하는 일이다. 이 장에서는 그 구분을 학습 기록장으로 확인한다.

• 배우는 모드와 만드는 모드의 목적을 구분한다.
• 완성된 답을 요구하는 요청과 설명·이유·힌트를 요구하는 요청을 비교한다.
• 혼자 시도한 흔적과 자기 말로 다시 설명한 내용을 남긴다.
• 짧은 프로그램을 읽고 실행해 학습 기록의 비율과 점검 메시지를 확인한다.

문제 상황

작은 팀에서 공부 시간을 정리하는 도구를 만든다고 하자. 학생 민서는 날짜별 공부 시간을 합치는 부분을 맡았다. 아직 반복문에 익숙하지 않아 AI에게 “날짜별 시간을 합치는 코드를 전부 구현해 줘”라고 요청했다. 받은 코드는 실행되었고, 화면에 합계도 나타났다. 민서는 일이 끝났다고 생각했다.

다음 날 동료가 같은 날짜의 기록이 여러 개일 때 합계가 어떻게 달라지는지 물었다. 민서는 어느 줄에서 값을 더하는지 바로 찾지 못했다. 입력 자료의 이름을 바꾸자 오류가 났지만, 무엇을 고쳐야 할지도 설명하기 어려웠다. 전날 완성한 결과는 남아 있었으나, 그 결과를 다룰 지식은 충분히 남아 있지 않았던 것이다.

다른 학생 지우는 같은 일을 하면서 먼저 종이에 기록 두 개를 적었다. 이어 “같은 날짜가 다시 나오면 기존 합계에 더해야 한다”는 규칙을 자기 말로 써 보았다. 구현하다 막히자 다음과 같이 물었다.

같은 날짜가 두 번 나올 때 값을 덮어쓰는 것 같다. 내가 생각한 규칙은 기존 합계에 새 시간을 더하는 것이다. 완성 코드 대신, 어느 부분을 살펴봐야 하는지 힌트만 줘.

지우의 작업이 항상 더 빨리 끝나는 것은 아니다. 하지만 다음 날 합계가 어긋났을 때 확인할 지점은 더 분명하다. 실제 업무에서도 코드를 생성하는 시간만 줄여서는 충분하지 않다. 요구 사항이 바뀌거나 오류가 생겼을 때 결과를 읽고 수정하는 일이 이어지기 때문이다.

AI가 코드를 쓰는 환경에서는 개발자가 하는 일의 비중이 달라진다. 요청을 정리하고, 결과를 확인하고, 수정할 이유를 설명하는 일이 더 눈에 띈다. 따라서 공부할 때도 “결과가 나왔는가”와 “내가 무엇을 판단할 수 있게 되었는가”를 함께 확인해야 한다.

배우는 모드와 만드는 모드는 목적이 다르다

이 책에서 배우는 모드는 AI의 도움을 받으면서 자신의 이해를 늘리려는 사용 방식이다. 만드는 모드는 필요한 결과를 구현하고 확인하려는 사용 방식이다. 특정 제품의 버튼이나 설정을 뜻하지 않는다. 같은 대화 안에서도 목적에 따라 두 모드를 오갈 수 있다. 아래 요청문은 2026년 10월 기준 예시이며, 특정 AI 제품의 기능을 전제로 하지 않는다.

같은 문제에서도 요청의 목적에 따라 남는 일이 달라진다

구분	요청 예시	독자가 할 일
배우는 모드: 설명	“이 반복문이 기록을 하나씩 처리하는 과정을 설명해 줘.”	설명과 실제 코드의 줄을 연결한다.
배우는 모드: 이유	“여기서 값을 새로 넣지 않고 기존 값에 더하는 이유는 무엇인가?”	다른 선택을 했을 때 결과가 어떻게 바뀌는지 생각한다.
배우는 모드: 힌트	“내가 합계를 구해 보았는데 값이 줄어든다. 정답 대신 확인할 지점 하나만 알려 줘.”	힌트를 바탕으로 직접 다음 시도를 한다.
만드는 모드: 구현	“날짜별 공부 시간을 합치는 함수를 구현해 줘.”	구현 결과를 읽고 실행해 요구와 맞는지 확인한다.

설명을 요청했다고 자동으로 배우는 것은 아니다. 긴 설명을 읽고 고개를 끄덕인 뒤 넘어가면, 완성 코드를 받아 두는 것과 비슷한 문제가 생길 수 있다. 반대로 구현을 맡겼더라도 코드를 읽고 작은 입력으로 동작을 확인하고 자기 말로 이유를 설명한다면 학습으로 이어질 수 있다. 요청 유형은 시작점을 보여 주며, 학습의 결과를 확정하지는 않는다.

Shen과 Tamkin의 연구를 소개한 Anthropic의 연구 설명에서는 새로운 Python 라이브러리를 배우는 개발자들이 AI 도움을 받은 경우, 직접 작성한 집단보다 과제 직후 평가 점수가 낮았고 디버깅 문항에서 가장 큰 차이가 나타났다고 보고한다. AI 사용자들의 요청 방식을 살핀 질적 분석에서는 코드를 통째로 맡긴 유형보다 개념을 묻거나 생성된 코드의 설명을 요청한 유형의 점수가 높았다. 다만 요청 방식별 차이가 인과관계를 입증한 것은 아니며, 이 결과만으로 장기적인 능력 저하나 모든 학습 상황의 효과를 판단할 수는 없다.

이 경향을 공부에 적용하면 주의할 점이 분명해진다. AI가 생각의 중간 과정을 모두 대신하면, 학습자는 그 과정을 연습할 기회를 덜 갖는다. 결과물을 얻는 데 성공했더라도 설명하거나 수정하는 연습은 남아 있을 수 있다. 따라서 도움의 양보다 도움을 받은 뒤 자신이 무엇을 할 수 있는지를 살피는 편이 낫다.

만드는 모드를 피할 필요는 없다. 이미 이해한 자료 정리를 구현하거나, 반복되는 출력 형식을 만드는 일에는 구현 요청이 도움이 된다. 다만 이번에 익힐 대상이 반복문이라면 반복문을 통째로 맡긴 뒤 실행만 하는 방식은 목표와 맞지 않을 수 있다. 도구를 고르기 전에 오늘의 학습 목표를 한 문장으로 쓰면 이 차이를 알아차리기 쉽다.

먼저 시도하고, 막힌 지점을 묻고, 다시 설명한다

먼저 혼자 시도한다는 말은 오래 버티라는 뜻이 아니다. 문제를 어떻게 이해했는지 흔적을 남기라는 뜻이다. 코드를 작성하기 어렵다면 입력과 예상 결과를 적어도 된다. “기록이 두 개면 각각의 시간을 더한다”처럼 처리 순서를 문장으로 써 보는 것도 시도다. 아무것도 떠오르지 않을 때는 문제에 나온 낯선 말과 이미 이해한 부분을 나누어 적을 수 있다.

그다음에는 막힌 지점을 좁혀 묻는다. “모르겠다”보다 “기록을 하나씩 꺼내는 것은 이해했지만 합계를 어디에 보관해야 하는지 모르겠다”가 자신의 상태를 더 잘 보여 준다. AI의 답이 너무 넓으면 도움의 범위를 다시 제한할 수 있다.

지금은 합계를 보관하는 변수의 역할만 알고 싶다. 완성 코드는 보여 주지 말고, 기록 두 개를 처리할 때 값이 어떻게 바뀌는지 설명해 줘.

힌트를 받았으면 바로 다음 질문을 보내기 전에 한 번 적용해 본다. 적용한 결과가 예상과 다르다면 그 차이를 다음 질문에 넣는다. 이 과정에서 AI의 설명도 확인 대상이다. 그럴듯한 설명이라도 실제 실행과 맞지 않을 수 있다.

힌트대로 바꾸니 공부 시간이 20과 30인 기록의 합계가 50으로 나왔다. 그런데 기록이 없을 때는 무엇을 출력해야 하는지 아직 정하지 못했다. 두 상황의 차이를 설명해 줘.

마지막에는 대화를 잠시 보지 않고 자기 말로 다시 설명한다. AI의 문장을 조금 바꾸는 일이 아니라, 원인과 결과를 연결하는 일이다. 예를 들어 “합계를 반복문 밖에서 시작하는 이유는 기록을 하나 처리할 때마다 이전 합계를 유지해야 하기 때문이다”라고 말할 수 있다. 이어 기록 하나를 더 넣었을 때의 결과를 예상해 보면 설명이 실제 동작과 연결되는지 확인할 수 있다.

자기 말로 설명하지 못했다고 실패한 것은 아니다. 그것은 다음 질문의 위치를 알려 준다. “비율 계산은 따라 했지만 왜 전체 기록 수로 나누는지 설명하지 못했다”는 기록은, 막연히 “오늘 비율을 배웠다”는 기록보다 다음 공부에 도움이 된다.

이번 프로그램은 이런 습관을 간단히 점검한다. 각 학습 기록에는 질문 유형, 스스로 시도했는지, 다시 설명했는지를 저장한다. 질문 유형이 설명·이유·힌트이면 배우는 모드로 센다. 구현이면 만드는 모드로 센다. 예제의 기록 수와 비율은 모두 설명용 가상값이며, 연구 결과나 권장 기준이 아니다.

프로그램은 질문 유형만으로 공부의 질을 평가하지 않는다. 배우는 모드 비율과 함께 시도하지 않은 기록, 다시 설명하지 않은 기록의 개수를 보여 준다. 실제 학습 기록장이라면 시도한 내용과 다시 쓴 설명도 함께 남기는 편이 좋다. 여기서는 핵심 생각을 짧은 코드로 확인하기 위해 두 항목을 참·거짓으로만 기록한다.

완성 코드

다음 내용을 main.py라는 이름의 파일에 저장한다. 파이썬(Python) 3.12 이상에서 표준 기능만으로 실행되며, 외부 패키지나 인터넷 연결은 필요하지 않다. 입력을 기다리지 않고 준비된 가상 기록을 읽은 뒤 종료한다. 코드는 빈 줄을 포함해 51줄이다.

records = [
    {"유형": "설명", "시도": True, "재설명": True},
    {"유형": "힌트", "시도": True, "재설명": False},
    {"유형": "이유", "시도": True, "재설명": True},
    {"유형": "구현", "시도": False, "재설명": False},
    {"유형": "구현", "시도": True, "재설명": False},
    {"유형": "설명", "시도": False, "재설명": True},
]

learning_types = ["설명", "이유", "힌트"]
allowed_types = learning_types + ["구현"]


def summarize(items):
    total = len(items)
    learning_count = 0
    no_attempt_count = 0
    no_explanation_count = 0

    for item in items:
        if item["유형"] not in allowed_types:
            raise ValueError("질문 유형을 확인해야 한다.")
        if item["유형"] in learning_types:
            learning_count = learning_count + 1
        if not item["시도"]:
            no_attempt_count = no_attempt_count + 1
        if not item["재설명"]:
            no_explanation_count = no_explanation_count + 1

    if total == 0:
        print("기록이 없다. 학습 기록을 먼저 남긴다.")
        return

    learning_ratio = learning_count / total * 100
    print(f"전체 기록: {total}개")
    print(f"배우는 모드: {learning_count}개")
    print(f"배우는 모드 비율: {learning_ratio:.1f}%")
    print(f"스스로 시도하지 않은 기록: {no_attempt_count}개")
    print(f"다시 설명하지 않은 기록: {no_explanation_count}개")

    if no_attempt_count > 0:
        print("점검: 다음 질문 전에 내 예상이나 시도를 적는다.")
    if no_explanation_count > 0:
        print("점검: 답을 덮고 처리 이유를 내 말로 설명한다.")
    if no_attempt_count == 0 and no_explanation_count == 0:
        print("점검: 시도와 재설명을 남겼다. 설명이 맞는지 실행으로 확인한다.")

    print("이 비율은 요청 방식의 기록이며 이해도 점수가 아니다.")


summarize(records)

줄별 해설

프로그램의 자료와 처리 방법을 차례로 읽는다. 변수는 값에 붙인 이름이다. 이 코드에서는 records가 기록 묶음을 가리키고, learning_count가 배우는 모드로 분류한 기록의 개수를 가리킨다. 이름을 통해 어떤 값을 다루는지 알 수 있다.

코드의 각 줄이 자료를 준비하고 개수를 세고 결과를 출력하는 과정

줄	코드의 역할	읽을 때 확인할 점
1	records에 기록 목록을 넣기 시작한다.	대괄호는 여러 값을 순서대로 담는 목록인 리스트를 만든다.
2~7	학습 기록 여섯 개를 준비한다.	각 줄의 중괄호는 이름과 값을 짝지어 보관하는 딕셔너리다. 모든 기록에 같은 세 항목이 있다.
8	기록 목록을 닫는다.	마지막 기록 뒤의 쉼표는 허용되며 기록 하나를 더 만들지 않는다.
9, 12~13	자료와 함수 사이를 빈 줄로 나눈다.	빈 줄은 계산하지 않으며 읽기 쉽게 구분한다.
10	배우는 모드에 해당하는 유형을 정한다.	설명·이유·힌트를 하나의 목록으로 묶는다.
11	허용하는 유형 목록에 구현을 추가한다.	여기서 더하기 기호는 두 목록을 이어 붙인다.
14	summarize라는 함수를 정의한다.	함수는 이름을 붙여 두고 필요할 때 실행하는 처리 묶음이다. items는 전달받을 기록 목록의 이름이다.
15	전체 기록 수를 구한다.	len은 목록에 들어 있는 항목의 개수를 반환한다.
16	배우는 모드 개수를 0에서 시작한다.	아직 기록을 살펴보지 않았으므로 센 개수는 0이다.
17	시도하지 않은 기록의 개수를 준비한다.	배우는 모드 개수와 별도로 센다.
18	재설명하지 않은 기록의 개수를 준비한다.	질문 방식과 후속 행동을 구분한다.
19, 29	반복 처리 앞뒤를 빈 줄로 나눈다.	동작에는 영향을 주지 않는다.
20	기록을 하나씩 꺼내 item이라고 부른다.	들여쓴 줄들이 현재 기록에 대해 반복된다.
21	현재 질문 유형이 허용 목록에 없는지 확인한다.	not in은 목록에 포함되지 않았는지를 묻는다.
22	알 수 없는 유형이면 오류로 실행을 멈춘다.	raise는 오류를 발생시킨다. ValueError는 값이 기대한 조건과 맞지 않음을 알리는 오류다.
23	현재 유형이 배우는 모드에 해당하는지 확인한다.	in은 목록에 포함되는지를 묻는다.
24	배우는 모드 개수를 하나 늘린다.	오른쪽의 기존 값에 1을 더해 왼쪽 이름에 다시 저장한다.
25	시도 항목이 거짓인지 확인한다.	True와 False는 각각 참과 거짓이다. not은 참과 거짓을 뒤집는다.
26	시도하지 않은 기록을 하나 더 센다.	앞 조건이 맞을 때만 실행한다.
27	재설명 항목이 거짓인지 확인한다.	시도 여부와 독립적으로 확인한다.
28	재설명하지 않은 기록을 하나 더 센다.	한 기록이 시도와 재설명 두 집계에 모두 포함될 수도 있다.
30	전체 기록 수가 0인지 확인한다.	같은지를 비교할 때는 등호를 두 개 쓴다.
31	빈 목록에 대한 안내를 출력한다.	자료가 없는 상태를 비율 0%와 구분한다.
32	함수 실행을 여기서 끝낸다.	return으로 돌아가므로 아래 나눗셈은 실행하지 않는다.
33, 40, 47, 49~50	계산·출력·호출 부분을 빈 줄로 구분한다.	처리의 경계를 눈으로 찾기 쉽게 한다.
34	배우는 모드 비율을 계산한다.	해당 개수를 전체 개수로 나누고 100을 곱해 백분율로 바꾼다.
35	전체 기록 수를 출력한다.	문자열 앞의 f는 중괄호 안 값을 문장에 넣게 한다.
36	배우는 모드 개수를 출력한다.	비율과 함께 실제 개수도 볼 수 있다.
37	비율을 소수점 아래 한 자리로 출력한다.	:.1f는 표시할 자릿수다. 내부의 계산값을 바꾸지는 않는다.
38	시도하지 않은 기록 수를 출력한다.	질문 유형이 무엇이든 전체 기록에서 센 결과다.
39	재설명하지 않은 기록 수를 출력한다.	시도한 기록에도 재설명이 빠질 수 있다.
41~42	시도하지 않은 기록이 있으면 조언을 출력한다.	다음 질문 전에 예상이나 시도를 남기도록 안내한다.
43~44	재설명하지 않은 기록이 있으면 조언을 출력한다.	답을 보지 않고 이유를 설명하도록 안내한다.
45~46	두 누락 개수가 모두 0이면 다른 조언을 출력한다.	and는 두 조건이 모두 참이어야 한다는 뜻이다. 기록을 남겼어도 설명의 정확성은 확인해야 한다.
48	비율의 해석 범위를 알린다.	요청 방식의 비율을 이해도 점수로 읽지 않게 한다.
51	준비한 기록을 함수에 전달해 실행한다.	함수를 정의하는 것과 실제 실행하는 것은 별개의 일이다.

개수를 세는 세 조건은 각각 별도의 if로 시작한다. if는 조건이 참일 때 그 아래 들여쓴 코드를 실행한다. 질문이 설명 유형이고 시도와 재설명을 모두 하지 않았다면, 그 기록은 세 개의 집계에 모두 영향을 준다. 서로 다른 관찰 항목이므로 하나를 셌다고 나머지를 건너뛰지 않는다.

비율의 분모는 전체 기록 수다. 질문 유형이 설명·이유·힌트인 기록만 먼저 골라 낸 뒤 그 목록의 길이로 나누면, 자신이 골라 낸 기록 중 배우는 모드가 얼마나 되는지를 계산하게 된다. 우리가 궁금한 것은 모든 요청 중 배우는 모드가 차지하는 비중이므로 전체 기록을 기준으로 삼는다.

이 프로그램은 각 기록에 세 항목이 있고, 시도와 재설명 값은 True 또는 False라는 전제로 작성했다. 질문 유형의 오타는 직접 확인하지만 모든 입력 오류를 검사하지는 않는다. 실제 기록을 바꿔 넣을 때는 항목 이름과 값의 형태를 먼저 읽어 확인해야 한다.

실행 결과

파일이 있는 폴더에서 다음 명령을 실행한다.

python3 main.py

준비한 가상 기록을 그대로 사용하면 다음 결과가 나온다. 시간이나 난수를 사용하지 않으므로 같은 코드와 자료에서는 같은 결과가 나온다.

전체 기록: 6개
배우는 모드: 4개
배우는 모드 비율: 66.7%
스스로 시도하지 않은 기록: 2개
다시 설명하지 않은 기록: 3개
점검: 다음 질문 전에 내 예상이나 시도를 적는다.
점검: 답을 덮고 처리 이유를 내 말로 설명한다.
이 비율은 요청 방식의 기록이며 이해도 점수가 아니다.

출력은 코드와 별개로 손으로도 확인할 수 있다. 설명 두 개, 이유 한 개, 힌트 한 개를 합하면 배우는 모드는 네 개다. 이를 전체 여섯 개로 나누고 100을 곱한 뒤 소수점 아래 한 자리로 표시하면 66.7%다. 시도가 False인 줄은 두 개이고 재설명이 False인 줄은 세 개다.

이 확인은 작은 테스트다. 테스트는 예상한 동작과 실제 동작을 비교하는 일이다. AI가 코드를 만들었든 사람이 만들었든, 화면에 숫자가 나왔다는 이유만으로 계산이 맞다고 결론 내리지 않는다. 먼저 예상값을 구하고 출력과 비교한다.

자료가 없는 경우도 확인할 수 있다. 마지막 줄의 summarize(records)를 summarize([])로 바꾸어 실행하면 “기록이 없다. 학습 기록을 먼저 남긴다.”만 출력되어야 한다. 확인이 끝나면 원래 호출로 되돌린다. 질문 유형을 “설명하기”로 바꾸면 허용된 유형이 아니므로 오류로 멈추는지도 살펴볼 수 있다.

실무에서 자주 틀리는 것

요청 유형 하나를 이해도 전체로 해석한다

다음 코드는 실행되지만 판단의 근거가 부족하다. 설명을 요청한 사실만으로 설명을 이해했다고 말할 수는 없다. 잘못된 예와 수정 예는 각각 독립적으로 실행할 수 있는 짧은 코드다.

question_type = "설명"
if question_type == "설명":
    print("내용을 이해했다.")

고친 코드는 관찰한 사실까지만 말한다. 이해 여부는 다시 설명하고 실행 결과를 예측하는 활동으로 따로 확인한다.

question_type = "설명"
if question_type == "설명":
    print("설명을 요청했다. 내 말로 다시 설명해 확인한다.")

요청 이름을 바꾸는 것만으로 학습이 나아지는 것은 아니다. 기록장을 점수판처럼 쓰면 실제 행동보다 보기 좋은 유형을 선택하게 될 수 있다.

시도하지 않은 기록을 셀 때 문자열로 비교한다

False와 “False”는 서로 다른 값이다. 앞의 것은 거짓을 뜻하고, 뒤의 것은 글자다. 아래 코드는 실행되지만 조건이 맞지 않아 필요한 메시지를 출력하지 않는다.

item = {"시도": False}
if item["시도"] == "False":
    print("시도할 내용을 먼저 적는다.")

예제의 자료처럼 참·거짓 값으로 기록했다면 다음과 같이 확인한다.

item = {"시도": False}
if not item["시도"]:
    print("시도할 내용을 먼저 적는다.")

이는 읽을 때도 구분해야 하는 부분이다. 따옴표가 있는지 살피고, 자료를 저장한 방식과 조건을 비교하는 방식이 맞는지 확인한다.

기록이 없는데 비율을 계산한다

다음 코드는 문법은 맞지만 실행하면 0으로 나누는 오류가 난다. 이 예는 의도적으로 실패 상황을 보여 준다.

total = 0
learning_count = 0
learning_ratio = learning_count / total * 100
print(learning_ratio)

전체 개수를 먼저 확인하면 자료가 없는 상태를 올바르게 안내할 수 있다.

total = 0
learning_count = 0
if total == 0:
    print("기록이 없어 비율을 계산하지 않는다.")
else:
    learning_ratio = learning_count / total * 100
    print(learning_ratio)

기록 없음과 배우는 모드 0%는 다르다. 후자는 기록이 있으나 배우는 모드가 하나도 없는 상태다. 두 상태를 같은 숫자로 덮으면 기록의 의미가 흐려진다.

다시 설명한 흔적을 곧바로 정확한 이해로 간주한다

재설명 항목이 참이어도 설명에 오류가 있을 수 있다. 다음 코드는 기록이 남았다는 사실을 이해가 확인되었다는 결론으로 바꾼다.

explained_again = True
if explained_again:
    print("이해 확인을 마쳤다.")

고친 코드는 다음 확인 행동을 안내한다.

explained_again = True
if explained_again:
    print("내 설명으로 결과를 예상하고 실제 실행과 비교한다.")

예를 들어 “설명 요청 하나를 추가하면 비율은 항상 올라간다”라고 말했다면, 기존 기록이 모두 배우는 모드인 경우를 생각해 본다. 이때는 이미 100%이므로 추가해도 비율이 같다. 자기 설명은 확인의 출발점이며, 실행과 작은 사례가 그 설명을 다듬는 데 도움을 준다.

한눈에 보기

요청 전후의 행동으로 배우는 모드와 만드는 모드를 선택한다

상황	요청 방식	남길 흔적	확인 방법
개념이 낯설다.	설명해 줘.	이해한 부분과 남은 질문	설명과 코드의 동작을 연결한다.
처리 이유가 불분명하다.	왜 그런가.	선택의 이유를 자기 말로 쓴 문장	다른 선택의 결과를 예상한다.
직접 시도하다 막혔다.	힌트만 줘.	시도한 내용과 막힌 지점	힌트를 적용하고 결과를 비교한다.
이해한 작업을 완성하려 한다.	구현해 줘.	요구 사항과 맡긴 범위	결과를 읽고 실행해 확인한다.
학습 기록을 돌아본다.	비율과 누락 항목을 살핀다.	다음에 바꿀 행동 하나	비율을 이해도 점수로 해석하지 않는다.

기록장의 목적은 배우는 모드 비율을 최대한 높이는 것이 아니다. 자신의 목표와 실제 행동이 맞는지 알아차리는 데 있다. 구현 요청이 많은 날에도 결과를 읽고 판단하는 연습을 했을 수 있고, 설명 요청이 많은 날에도 설명을 그대로 옮기기만 했을 수 있다. 숫자와 함께 시도와 재설명의 내용을 읽어야 한다.

연습 문제

1. “반복문으로 공부 시간을 합치는 코드를 만들어 줘”라는 요청을 배우는 모드의 요청으로 바꿔 본다. 자신이 먼저 해 본 일과 막힌 지점을 포함하고, 도움의 범위를 제한한다.
2. 완성 코드의 가상 기록에 유형이 “힌트”, 시도가 True, 재설명이 True인 기록 하나를 추가한다. 실행 전에 전체 기록 수, 배우는 모드 수, 비율, 두 누락 개수를 예상한다.
3. 기록이 두 개이고 모두 “구현” 유형이며, 두 기록 모두 시도와 재설명이 True라고 하자. 배우는 모드 비율과 점검 메시지를 예상하고, 이 결과로 두 사람이 아무것도 배우지 않았다고 말할 수 있는지 설명한다.
4. 자신이 최근 AI에게 묻고 싶었던 질문 하나를 고른다. 혼자 시도한 내용과 도움을 받은 뒤 자기 말로 다시 설명할 내용을 각각 한 문장으로 적는다. 이어 자신의 설명을 확인할 작은 입력과 예상 결과를 정한다.

정답과 해설

첫 번째 문제. 다음과 같이 바꿀 수 있다. 핵심은 설명이라는 단어를 넣는 데 그치지 않고, 현재 이해와 막힌 위치를 드러내는 것이다.

공부 시간이 20과 30이면 합계가 50이어야 한다고 적어 보았다. 기록을 하나씩 읽는다는 뜻은 이해했지만, 이전 합계를 어디에 보관하는지 모르겠다. 완성 코드 대신 합계를 보관하는 변수의 역할을 설명하고 다음 시도에 필요한 힌트 하나만 줘.

이 요청 뒤에는 힌트를 적용하는 자신의 시도가 이어져야 한다. 실제로 시도하지 않았다면 시도했다고 쓰지 않는다. 대신 “아직 코드는 못 썼지만 입력과 예상 결과를 적었다”처럼 현재 상태를 정확히 말한다.

두 번째 문제. 전체 기록은 일곱 개, 배우는 모드는 다섯 개가 된다. 다섯을 일곱로 나누고 100을 곱하면 출력 비율은 71.4%다. 추가한 기록은 시도와 재설명이 모두 참이므로 시도하지 않은 기록 두 개와 재설명하지 않은 기록 세 개는 그대로다. 따라서 두 점검 메시지도 그대로 나온다.

비율만 보면 배우는 모드 비중이 늘었지만, 기존에 남아 있던 누락이 해결된 것은 아니다. 새 기록을 추가하는 일과 이전 기록에서 부족한 설명을 보충하는 일은 서로 다른 행동이다.

세 번째 문제. 배우는 모드는 0개이므로 비율은 0.0%다. 시도하지 않은 기록과 재설명하지 않은 기록은 모두 0개다. 따라서 “점검: 시도와 재설명을 남겼다. 설명이 맞는지 실행으로 확인한다.”가 출력된다. 마지막의 이해도 점수가 아니라는 안내도 출력된다.

이 자료만으로 아무것도 배우지 않았다고 말할 수는 없다. 구현을 요청하기 전에 무엇을 시도했는지, 받은 코드의 어떤 부분을 다시 설명했는지 프로그램은 알지 못한다. 같은 이유로 두 항목이 참이라는 사실만으로 충분히 이해했다고 말할 수도 없다.

네 번째 문제. 답은 자신의 질문에 따라 달라진다. 이번 프로그램을 대상으로 한다면 시도는 “설명 두 개와 힌트 한 개면 배우는 모드가 세 개라고 손으로 세었다”가 될 수 있다. 재설명은 “배우는 모드 비율은 전체 요청 중 설명·이유·힌트 요청이 차지하는 비중이다”가 될 수 있다.

확인할 입력으로 설명 한 개와 구현 한 개를 정하면 예상 비율은 50.0%다. 이 결과가 나오는지 실행하고, 계산에 사용한 코드의 줄을 찾아 연결한다. 다음 장에서는 이런 연결을 더 차분하게 연습한다. 남이 쓴 코드가 어떤 순서로 값을 바꾸는지 따라가면서, 받은 결과를 자신의 판단으로 다룰 수 있게 한다.