나의 학습 경로 설계하기 - 지금 단계에서 다음 단계로

이 장에서 배우는 것

앞 장에서 포트폴리오에 자신이 맡은 일과 판단한 근거를 남겼다. 이제 그 기록을 다음 공부의 출발점으로 삼는다. 학습 경로는 앞으로 배울 기술을 모두 적어 놓은 목록이 아니다. 지금 할 수 있는 일, 아직 설명하기 어려운 일, 이번 주에 확인할 일을 연결한 계획이다. 처음부터 진로를 하나로 확정할 필요도 없다. 작은 작업을 해 보고 그 결과에 따라 다음 방향을 고르면 된다.

AI가 코드를 작성하는 환경에서는 개발자가 하는 일의 비중이 달라진다. 코드를 입력하는 시간뿐 아니라 요구를 정리하고, 결과를 읽고, 실행으로 확인하는 시간이 중요해진다. 따라서 공부 계획에도 결과물을 만드는 시간과 자신의 이해를 확인하는 시간이 함께 있어야 한다. 이 장에서는 가상의 자기 진단 답을 읽어 추천 학습 순서와 이번 주 할 일을 출력하는 작은 프로그램을 만든다.

• 자신의 신분과 실제 수행 능력을 구분해 다음 한 걸음을 고른다.
• 기초, 방법론, 프로젝트, 에이전트로 이어지는 순서를 학습 증거와 연결한다.
• 웹 백엔드, 데이터, AI 응용에서 공통으로 필요한 것과 함께 살필 것을 구분한다.
• 하루 공부에 배우는 모드와 만드는 모드를 섞고 확인 시간을 남긴다.
• 규칙으로 만든 추천을 실행하고 읽어 본 뒤 자신의 상황에 맞게 조정한다.

문제 상황

한 서비스 개발 팀에 합류한 사람이 학습 기록 기능을 맡았다고 하자. 사용자는 공부한 날짜와 시간을 입력하고, 서비스는 주간 합계를 보여 줘야 한다. 담당자는 AI의 도움으로 화면과 계산 코드를 빠르게 만들었다. 하지만 같은 기록이 두 번 들어오면 어떻게 처리하는지, 비어 있는 날짜를 어떻게 표시하는지 묻자 설명이 막힌다. 기능을 만들었다는 사실과 그 기능을 이해한다는 사실 사이에 틈이 생긴 것이다.

이 사람은 부족함을 느끼고 새 기술 강의를 여러 개 담는다. 데이터 분석도 궁금하고 AI 응용도 유망해 보인다. 그러나 이번 업무에서 가장 먼저 필요한 것은 새로운 도구의 이름을 아는 일이 아니다. 기록이 들어와 합계가 나오기까지의 과정을 설명하고, 조건이 달라져도 결과가 맞는지 확인하는 일이다. 학습 계획이 현재의 막힘과 연결되지 않으면 공부한 시간은 늘어도 업무의 어려움은 그대로 남는다.

개발 공부를 시작하려는 학생도 비슷한 상황을 겪는다. 강의를 끝냈으니 프로젝트를 해야 할 것 같고, 프로젝트를 만들었으니 자동으로 일하는 AI 도구를 써야 할 것 같다. 그런데 무엇을 기준으로 넘어가야 하는지는 분명하지 않다. 이때 필요한 질문은 “무엇을 많이 배웠나”보다 “무엇을 도움 없이 설명하고 확인할 수 있나”다.

이번 예제는 이 질문을 단순한 규칙으로 바꾼다. 코드를 따라갈 수 있는지, 완료 기준으로 결과를 검사할 수 있는지, 작은 작업을 끝내 본 적이 있는지를 가상의 답으로 받는다. 프로그램은 가장 먼저 비어 있는 항목을 찾아 다음 학습의 출발점으로 추천한다. 이 추천은 능력 평가나 진로 판정이 아니다. 계획을 구체적으로 이야기하기 위한 초안이다.

출발점은 신분이 아니라 확인한 행동이다

고등학생, 대학생, 국비 과정 수료생, 주니어는 생활 조건과 경험이 다르다. 주니어는 실무 경력이 비교적 짧은 개발자를 뜻한다. 다만 이 이름만으로 학습 순서를 정할 수는 없다. 대학생도 짧은 코드의 실행 순서를 따라가기 어려울 수 있고, 고등학생도 자신이 만든 도구의 실패 조건을 설명할 수 있다. 신분은 예제를 고르는 데 쓰고, 다음 학습 단계는 실제 행동의 증거로 고르는 편이 낫다.

현재 상황별로 작게 시작할 수 있는 다음 행동

현재 상황	다음 한 걸음	확인할 증거	범위를 줄이는 기준
고등학생	짧은 학습 기록 코드를 읽고 입력을 바꿔 실행한다.	실행 전에 예상한 출력과 실제 출력의 차이를 설명한다.	화면 꾸미기보다 한 가지 계산을 다룬다.
대학생	수업에서 배운 개념을 작은 기능 하나에 연결한다.	왜 그 조건이나 자료 구조를 썼는지 설명한다.	여러 과목의 내용을 한 번에 넣지 않는다.
국비 과정 수료생	완료한 과제에서 기능 하나를 골라 다시 확인한다.	원래 요구와 실제 동작을 비교한 기록을 남긴다.	전체 결과물을 다시 만드는 대신 한 부분을 고른다.
주니어	최근 맡은 변경에서 확인이 부족했던 지점을 찾는다.	실패 조건과 변경의 영향을 짧게 설명한다.	실제 업무에서 이해하지 못한 한 흐름을 고른다.

자기 진단에서 “할 수 있다”는 답은 느낌보다 기록에 기대야 한다. “코드 읽기 가능”이라고 표시하려면 짧은 코드에서 값이 어떻게 달라지는지 설명한 예가 있어야 한다. “결과 검사 가능”이라면 정상 입력뿐 아니라 비어 있는 입력이나 경계에 걸린 입력도 확인한 기록이 있어야 한다. 여기서 경계란 허용 범위의 시작과 끝처럼 조건의 결과가 바뀌는 지점이다.

아직 증거가 없다면 “아니요”로 시작해도 된다. 이는 못한다는 확정 판정이 아니다. 이번 주에 무엇을 확인할지 정하는 표시다. 이미 할 수 있는 항목을 다시 공부할 필요가 생길 수도 있다. 프로젝트를 하다가 반복문의 실행 순서를 설명하지 못했다면, 필요한 기초로 돌아가 짧게 확인하면 된다.

진단 답은 주기적으로 바꾸되 일정만 보고 바꾸지 않는다. 한 주가 지났다는 이유로 모든 답을 “예”로 바꾸면 프로그램은 진전을 보여 주지만 실제 이해는 확인되지 않는다. 답을 바꿀 때는 “어떤 코드를 읽었고 무엇을 설명했는가”처럼 근거를 한 문장 남긴다. 이 기록이 앞 장에서 다룬 과정 중심 포트폴리오와 이어진다.

기초에서 에이전트까지, 넘어가는 근거를 세운다

이 장의 학습 순서는 기초, 방법론, 프로젝트, 에이전트다. 기초는 변수에 담긴 값과 조건·반복에 따른 실행을 따라가는 능력이다. 방법론은 일을 진행하는 방법으로, 여기서는 원하는 결과를 적고 그 기준에 따라 확인하는 습관을 뜻한다. 프로젝트는 목적이 있는 작은 작업을 시작부터 확인까지 끝내는 경험이다.

에이전트(agent)는 주어진 목표에 따라 여러 작업 단계를 수행하는 AI 시스템을 뜻한다. 코드 작성에 이어 실행이나 수정 같은 일을 수행하도록 구성할 수 있다. 어떤 도구를 쓸 수 있는지와 어디까지 자동으로 진행하는지는 환경에 따라 다르다. 여기서는 특정 제품의 기능을 배우는 단계가 아니라, 여러 단계를 맡기면서 사람이 확인 지점을 정하는 단계로 다룬다.

이 순서는 한 단계를 모두 외워야 다음 단계에 갈 수 있다는 뜻이 아니다. 작은 프로젝트를 하며 기초를 익힐 수도 있다. 다만 다음 작업에서 무엇을 스스로 판단해야 하는지는 알아야 한다. 기초가 필요한 순간에는 코드의 흐름을 읽고, 방법론이 필요한 순간에는 원하는 결과와 실제 결과를 비교한다. 프로젝트에서는 이 두 행동을 하나의 목적에 연결한다.

에이전트 활용에서도 같은 원칙이 이어진다. 맡긴 작업을 이해할 수 없으면 결과가 나와도 받아들일 근거가 부족하다. 먼저 작업 범위를 줄이고, 중간 결과를 읽을 위치와 실행으로 확인할 기준을 정한다. 예를 들어 학습 기록의 주간 합계를 수정하도록 맡겼다면 변경된 계산 부분을 읽고, 미리 정한 입력에서 합계가 맞는지 실행한다. 자동으로 수행하는 단계가 늘어날수록 사람의 확인 기준도 분명해져야 한다.

직무는 이 공통 순서에 함께 살필 질문을 더한다. 웹 백엔드(back-end)는 화면 뒤에서 요청을 처리하고 데이터를 관리하는 부분이다. 데이터 분야에서는 값의 의미와 정리 과정이 중요하다. AI 응용에서는 AI의 결과를 서비스의 목적과 연결하고 그 결과를 확인하는 일이 필요하다. 하나를 골랐다고 다른 분야의 기초를 모두 배제하는 것은 아니다.

관심 직무에 따라 공통 학습에 덧붙일 질문

관심 직무	함께 볼 것	작은 학습 도구의 예	확인할 질문
웹 백엔드	요청 처리, 데이터 저장, 입력 검사	학습 기록을 저장하고 주간 합계를 계산한다.	잘못된 입력과 중복 기록을 어떻게 처리하는가.
데이터	자료의 의미, 누락값, 집계 기준	학습 기록을 요일별로 모아 비교한다.	기록이 없는 날과 공부 시간이 없는 날을 구분하는가.
AI 응용	입력 구성, 결과 평가, 실패 시 처리	추천 학습 계획을 정해 둔 기준으로 검사한다.	그럴듯한 추천이 실제 시간과 목적에 맞는가.

관심 직무를 아직 정하지 못했다면 같은 학습 기록을 서로 다른 질문으로 다뤄 본다. 저장과 조회에 흥미가 있는지, 자료를 정리해 의미를 찾는 일이 즐거운지, 추천 결과의 타당성을 확인하는 일이 궁금한지 살핀다. 이 경험만으로 진로를 확정할 수는 없지만, 다음에 탐색할 작업을 고르는 근거는 된다.

하루 루틴에는 만들기와 확인을 함께 넣는다

배우는 모드는 이해를 목표로 하는 시간이다. 짧은 코드를 읽고, 실행 전에 결과를 예상하고, 설명이 막히는 부분을 질문한다. 만드는 모드는 정해 둔 결과를 내는 시간이다. 작은 기능을 구현하거나 AI에게 초안을 요청하고, 실행 가능한 결과로 연결한다. 같은 도구를 쓰더라도 그 시간의 목표에 따라 모드가 달라진다.

이 장에서는 하루에 쓸 수 있는 시간이 60분이라고 가정한다. 배우는 시간 25분, 만드는 시간 25분, 확인 시간 10분으로 나눈다. 이 숫자는 설명용 가상값이며 권장 비율이나 연구 결과가 아니다. 만드는 시간이 자주 늘어난다면 범위를 줄이고, 읽다가 계속 막힌다면 배우는 시간을 늘리는 식으로 조정한다. 전체 시간이 짧은 날에는 세 활동을 더 작게 하거나 날짜를 나누어도 된다.

마지막 확인 시간에는 오늘 만든 결과와 오늘 이해한 것을 따로 적는다. 기능은 실행되지만 설명이 어렵다면 이해할 항목이 남아 있다. 설명은 가능하지만 입력이 달라졌을 때 실패한다면 확인할 조건이 남아 있다. 둘 다 다음 날의 공부 재료다. 계획을 지켰는지뿐 아니라 어떤 근거가 새로 생겼는지를 살펴야 한다.

AI에게 요청할 때도 이번 시간의 목적을 밝힐 수 있다. 다음 요청은 특정 제품에 의존하지 않는 2026년 10월 기준 예시다. 답이 오면 제안된 순서를 읽고, 가능한 작업만 골라 실행하며, 결과를 자신의 기준과 비교한다.

지금은 배우는 모드다. 아래 학습 경로 추천 코드에서 추천 시작점을 고르는 조건을 설명해 달라. 먼저 내가 결과를 예상할 수 있도록 질문 하나를 주고, 내가 답한 뒤 실행 흐름을 설명해 달라.

지금은 만드는 모드다. 이번 주에는 학습 기록의 합계 기능 하나를 만들겠다. 입력과 예상 출력을 먼저 정리하고 작은 코드 초안을 제안해 달라. 실행 결과는 내가 확인하고, 이해하지 못한 부분은 따로 질문하겠다.

요청을 잘 썼다는 이유만으로 답이 맞는 것은 아니다. 설명에 나온 조건이 실제 코드와 같은지 읽고, 예상 출력이 실행 결과와 맞는지 확인한다. AI의 제안은 학습을 시작하는 재료로 쓰되, 자신의 이해를 대신하는 증거로 쓰지 않는다.

완성 코드

다음 코드를 main.py라는 파일에 저장한다. 자기 진단 답은 키와 값을 짝지어 저장하는 사전(dict)에 들어 있다. True는 그렇다는 답, False는 아직 확인하지 못했다는 답이다. 예제 속 신분과 답, 시간과 분량은 모두 설명용 가상값이다. 프로그램은 외부 패키지나 네트워크를 사용하지 않으며, 같은 코드로 실행하면 같은 결과를 출력하고 끝난다.

answers = {
    "status": "대학생",
    "job": "웹 백엔드",
    "can_trace": True,
    "can_check": False,
    "finished_small": False,
}
stages = ["기초", "방법론", "프로젝트", "에이전트"]
tasks = {
    "기초": "짧은 코드의 값 변화를 적고 실행 결과와 비교한다.",
    "방법론": "학습 기록 합계의 완료 기준과 확인 예시를 적는다.",
    "프로젝트": "학습 기록 합계 기능 하나를 만들고 확인한다.",
    "에이전트": "작은 수정 하나를 맡기고 변경 내용과 실행 결과를 확인한다.",
}
status_hints = {
    "고등학생": "하루 학습 기록 하나로 시작한다.",
    "대학생": "수업에서 배운 개념 하나를 기능에 연결한다.",
    "국비 과정 수료생": "완료한 과제의 기능 하나를 다시 확인한다.",
    "주니어": "최근 맡은 변경의 실패 조건 하나를 정리한다.",
}
job_hints = {
    "웹 백엔드": "요청 처리, 데이터 저장, 입력 검사를 함께 본다.",
    "데이터": "자료의 의미, 누락값, 집계 기준을 함께 본다.",
    "AI 응용": "입력 구성, 결과 평가, 실패 시 처리를 함께 본다.",
}
if not answers["can_trace"]:
    start = 0
elif not answers["can_check"]:
    start = 1
elif not answers["finished_small"]:
    start = 2
else:
    start = 3
route = stages[start:]
first = route[0]
status_hint = status_hints.get(
    answers["status"], "현재 하는 작은 작업 하나를 고른다."
)
job_hint = job_hints.get(
    answers["job"], "관심 작업의 입력과 출력을 먼저 살핀다."
)
routine = [
    ("배우는 모드", 25, "코드를 읽고 결과를 예상한다."),
    ("만드는 모드", 25, "이번 주 작업의 작은 부분을 만든다."),
    ("확인", 10, "실행 결과를 비교하고 이해한 것을 적는다."),
]
print("학습 경로 추천")
print("상황:", answers["status"], "/", answers["job"])
print("추천 순서:", " → ".join(route))
print("이번 주 할 일:", tasks[first])
print("상황별 연결:", status_hint)
print("직무별 연결:", job_hint)
print("하루 루틴: 설명용 가상 시간")
for mode, minutes, action in routine:
    print(f"- {mode} {minutes}분: {action}")
print("다음 점검: 수행 근거가 생긴 항목만 답을 바꾼다.")

줄별 해설

첫 줄의 answers = {는 자기 진단 답을 담을 사전을 만든다. 이어지는 status와 job은 현재 상황과 관심 직무를 글자로 저장한다. can_trace는 코드의 값 변화를 따라갈 수 있는지, can_check는 기준을 세워 결과를 검사할 수 있는지, finished_small은 작은 작업을 끝내 본 적이 있는지를 저장한다. 닫는 중괄호는 답의 묶음이 끝났다는 표시다.

stages 줄은 학습 순서를 목록(list)으로 만든다. 목록은 여러 값을 순서대로 담는 자료다. 첫 항목인 기초의 위치 번호는 0이고, 이어지는 항목은 1, 2, 3이다. 사람에게 출력할 때는 이 번호 대신 단계 이름을 보여 준다.

tasks = {부터 다음 닫는 중괄호까지는 각 단계의 이번 주 할 일을 저장한다. 기초 줄은 읽은 내용과 실행 결과를 비교하게 한다. 방법론 줄은 완료 기준과 확인 예시를 적게 한다. 프로젝트 줄은 기능 하나를 끝내게 한다. 에이전트 줄은 맡긴 수정의 내용과 결과를 확인하게 한다. 네 문장은 각각 하나의 단계 이름에 연결된다.

status_hints의 네 줄은 신분에 맞는 작업의 출발 소재를 저장한다. job_hints의 세 줄은 관심 직무에 따라 함께 살필 내용을 저장한다. 두 사전은 추천 시작점을 정하지 않는다. 같은 단계에 있더라도 자신과 가까운 작업으로 공부할 수 있도록 안내를 덧붙인다.

if not answers["can_trace"]:는 코드 읽기 답이 False인지 살핀다. not은 참과 거짓을 뒤집는다. 이 조건이 맞으면 start = 0이 실행되어 기초부터 시작한다. 다음 elif는 앞 조건이 맞지 않을 때 다음 조건을 확인한다. 검사 근거가 없으면 start = 1, 작은 작업을 끝낸 근거가 없으면 start = 2가 된다. 앞의 모든 조건을 통과하면 else 아래에서 start = 3이 되어 에이전트 활용을 추천한다.

들여쓰기한 줄은 해당 조건에 속한다. 이번 답에서는 can_trace가 True이므로 첫 조건을 지나간다. can_check가 False이므로 두 번째 조건이 맞아 start에 1이 들어간다. 이후 조건은 실행하지 않는다. 따라서 finished_small도 False이지만 이번 추천의 시작점은 방법론이다. 먼저 필요한 항목 하나를 고르는 규칙이기 때문이다.

route = stages[start:]는 정한 위치부터 목록의 끝까지 가져온다. 이런 표기를 슬라이싱(slicing)이라고 한다. start가 1이면 방법론, 프로젝트, 에이전트가 남는다. first = route[0]은 그중 첫 항목을 가져온다. 뒤에서 이번 주 할 일을 고를 때 이 값을 쓴다.

status_hint를 만드는 세 줄은 get으로 상황별 안내를 찾는다. get은 사전에 이름이 있으면 그 값을 가져오고, 없으면 두 번째 인수로 준 기본 문장을 가져온다. 인수는 어떤 기능을 호출할 때 전달하는 값이다. job_hint를 만드는 세 줄도 같은 방식이다. 아직 직무를 정하지 않았거나 다른 글자를 적었을 때도 기본 안내가 나온다.

routine = [부터 닫는 대괄호까지는 하루 활동을 순서대로 저장한다. 각 괄호는 모드 이름, 분 수, 행동을 함께 묶는다. 이런 묶음을 튜플(tuple)이라고 한다. 여기서는 세 값을 하나의 활동으로 취급하기 위해 쓴다. 시간의 숫자는 실제 진단 결과로 계산한 값이 아니라 예제를 위한 고정값이다.

이어지는 print 줄은 제목과 상황을 출력한다. " → ".join(route)는 추천 목록의 항목 사이에 화살표를 넣어 한 문장으로 합친다. tasks[first]는 추천 시작점에 연결된 이번 주 할 일을 찾는다. 다음 두 print는 상황별 안내와 직무별 안내를 출력하고, 그다음 줄은 하루 루틴을 소개한다.

for mode, minutes, action in routine:는 활동 묶음을 하나씩 꺼내 세 변수에 나누어 담는다. 들여쓰기한 print는 각 활동을 한 줄로 출력한다. 문자열 앞의 f는 중괄호 안에 있는 변수의 값을 문장에 넣겠다는 표시다. 반복이 끝나면 마지막 print가 진단 답을 바꾸는 기준을 안내한다.

실행 결과

macOS나 Linux의 터미널에서 파일이 있는 폴더로 이동한 뒤 다음 명령을 실행한다. 터미널은 글자로 명령을 입력하고 결과를 보는 도구다. 실행 환경은 Python 3.12 이상이다.

python3 main.py

예상 출력은 다음과 같다. 코드 읽기에는 근거가 있고 결과 검사에는 아직 근거가 없다는 가상 답에 따라 방법론부터 추천한다.

학습 경로 추천
상황: 대학생 / 웹 백엔드
추천 순서: 방법론 → 프로젝트 → 에이전트
이번 주 할 일: 학습 기록 합계의 완료 기준과 확인 예시를 적는다.
상황별 연결: 수업에서 배운 개념 하나를 기능에 연결한다.
직무별 연결: 요청 처리, 데이터 저장, 입력 검사를 함께 본다.
하루 루틴: 설명용 가상 시간
- 배우는 모드 25분: 코드를 읽고 결과를 예상한다.
- 만드는 모드 25분: 이번 주 작업의 작은 부분을 만든다.
- 확인 10분: 실행 결과를 비교하고 이해한 것을 적는다.
다음 점검: 수행 근거가 생긴 항목만 답을 바꾼다.

실행 결과가 이 출력과 같은지 확인한 뒤 can_trace만 False로 바꿔 다시 실행해 본다. 예상 시작점은 기초다. 다른 답이 그대로여도 가장 앞선 조건이 맞기 때문이다. 이렇게 한 항목씩 바꾸어 예상과 실제 결과를 비교하면 AI가 제안한 코드도 규칙에 맞게 움직이는지 확인할 수 있다. 실행이 끝났다는 사실만으로 추천이 적절하다고 결론 내리지 않는다.

실무에서 자주 틀리는 것

신분만 보고 시작점을 고른다

다음 코드는 실행되지만 주니어라는 이유만으로 에이전트부터 시작한다. 실제로 코드를 읽고 검사할 수 있는지 확인하지 않는다. 신분을 수행 능력의 증거로 대신 쓴 것이 문제다.

status = "주니어"
start = 3 if status == "주니어" else 0
print(start)

고친 코드는 행동의 근거를 차례로 확인한다. 신분은 사례를 고르는 안내에 쓰고, 시작점은 가장 먼저 확인되지 않은 능력으로 정한다.

can_trace = True
can_check = False
finished_small = True
if not can_trace:
    start = 0
elif not can_check:
    start = 1
elif not finished_small:
    start = 2
else:
    start = 3
print(start)

출력된 추천을 최종 판정으로 취급한다

다음 코드는 에이전트 단계가 추천되었다는 사실을 모든 작업을 맡겨도 된다는 판단으로 바꾼다. 세 가지 자기 진단 답만으로 작업의 난이도나 영향을 알 수는 없다.

stage = "에이전트"
if stage == "에이전트":
    print("이번 작업의 모든 변경을 맡긴다.")

고친 코드는 추천을 작은 시도의 출발점으로 쓴다. 범위를 좁히고 결과를 확인하는 행동이 안내에 남아 있다. 실제 작업에서는 맡길 수정의 내용과 완료 기준도 따로 정한다.

stage = "에이전트"
if stage == "에이전트":
    print("작은 수정 하나를 맡긴다.")
    print("변경 내용을 읽고 정한 입력으로 실행한다.")

공부 시간을 늘리며 확인 시간을 없앤다

다음 계획은 읽기와 만들기로 하루 시간을 모두 채운다. 결과가 예상과 맞는지, 자신이 무엇을 이해했는지 확인할 시간이 없다. 새로운 진단 답을 뒷받침할 기록도 남기기 어렵다.

learn = 30
build = 30
check = 0
print("하루 합계:", learn + build + check)

고친 계획은 확인 시간을 포함한다. 아래 숫자 역시 설명용 가상값이다. 핵심은 특정 비율을 지키는 일이 아니라 확인 활동을 계획에 넣는 일이다.

learn = 25
build = 25
check = 10
print("하루 합계:", learn + build + check)
print("마지막에는 예상과 실행 결과를 비교한다.")

한눈에 보기

학습 경로를 고르고 수정할 때 사용할 기준

고를 것	판단 근거	이번 주 행동	다음 점검
학습 시작점	가장 먼저 설명하거나 확인하지 못한 항목	그 항목을 확인할 작은 작업 하나를 한다.	새로운 수행 근거가 생겼는가.
작업 소재	학교생활, 수업, 과제, 현재 업무	가까운 상황의 입력과 출력을 고른다.	범위가 한 주 안에 다룰 만큼 작은가.
관심 직무	해 보고 싶은 작업과 확인할 질문	공통 기초에 직무의 질문을 덧붙인다.	어떤 작업에 흥미가 있었는가.
하루 루틴	사용 가능한 시간과 현재의 막힘	배우기, 만들기, 확인을 함께 배치한다.	결과물과 이해가 함께 남았는가.
에이전트 활용	맡길 범위와 결과를 판단할 기준	작은 작업을 맡기고 변경과 실행을 확인한다.	받아들인 결과의 이유를 설명할 수 있는가.

이번 프로그램은 입력된 답을 정해 둔 규칙에 연결한다. 관심사, 건강 상태, 사용할 수 있는 시간, 주변의 도움까지 판단하지는 않는다. 추천이 생활 조건과 맞지 않으면 작업의 크기와 소재를 조정한다. 다만 어렵다는 이유로 확인 기준을 없애기보다, 확인할 수 있을 만큼 작업을 작게 만드는 편이 낫다.

연습 문제

1. 완성 코드에서 can_trace를 False로 바꾸고 나머지 답은 그대로 둔다. 실행 전에 추천 순서와 이번 주 할 일을 적고, 실행 결과와 비교한다.
2. 세 가지 능력 답을 모두 True로 바꾼다. 추천 시작점은 무엇인가. 이 결과만으로 큰 작업을 모두 맡겨도 되는지 이유를 적는다.
3. status를 “고등학생”, job을 “데이터”로 바꾸되 세 가지 능력 답은 원래대로 둔다. 바뀌는 출력과 바뀌지 않는 출력을 구분한다.
4. 이번 주에 자신이 확인할 항목 하나를 고른다. 시작할 작업, 완료 기준, 하루의 세 활동, 다음 진단에서 답을 바꿀 근거를 각각 한 문장으로 적는다.

정답과 해설

1. 추천 순서는 “기초 → 방법론 → 프로젝트 → 에이전트”다. 이번 주 할 일은 “짧은 코드의 값 변화를 적고 실행 결과와 비교한다.”다. 첫 조건이 맞아 start가 0이 되므로 뒤의 조건은 실행하지 않는다. 실행 결과가 예상과 다르다면 바꾼 파일을 저장했는지와 실제 실행한 파일이 같은지부터 확인한다.
2. 추천 시작점은 에이전트다. 앞의 세 조건이 모두 맞지 않아 else가 실행된다. 그러나 답이 모두 True라는 사실은 특정 작업의 범위와 영향을 이해한다는 보장이 아니다. 작은 작업을 정하고 변경 내용을 읽으며 실행 결과를 확인할 기준이 여전히 필요하다.
3. 상황 줄은 “고등학생 / 데이터”로 바뀐다. 상황별 연결은 “하루 학습 기록 하나로 시작한다.”, 직무별 연결은 “자료의 의미, 누락값, 집계 기준을 함께 본다.”로 바뀐다. 추천 순서와 이번 주 할 일, 하루 루틴은 그대로다. 시작점을 정하는 조건이 신분과 직무를 읽지 않기 때문이다.
4. 한 가지 답은 다음과 같다. 작업은 학습 시간 목록의 합계를 계산하는 짧은 코드를 읽는 것이다. 완료 기준은 두 입력의 결과를 실행 전에 예상하고 실제 결과와 비교해 차이를 설명하는 것이다. 하루에는 값을 따라가며 배우고, 입력을 바꾸어 작은 결과를 만들고, 마지막에 예상과 실행을 비교한다. 다음 진단에서는 이 기록을 근거로 코드 읽기 답을 바꾼다. 다른 작업을 골라도 행동과 확인 근거가 연결되어 있다면 적절하다.

책을 끝낸 시점에 배울 목록이 모두 확정될 필요는 없다. 지금 설명할 수 있는 것과 아직 확인할 것을 구분하고, 이번 주의 작은 작업을 정하면 된다. 작업을 해 본 결과는 다음 계획의 입력이 된다. AI에게 맡길 수 있는 일이 늘어나는 환경에서도 그 결과를 읽고, 실행하고, 받아들일 이유를 설명하는 공부는 계속 이어진다.