AI 개발 · 기본
AI 시대의 개발 공부 - 무엇을 배우고 어떻게 익힐까
AI 가 코드를 쓰는 시대, 개발자의 하루는 어떻게 달라졌나
직업이 사라지는 것이 아니라 일의 비중이 바뀐다는 관점, 예전 하루(타이핑 중심)와 지금 하루(요구 정리·맡기기·읽기·검증·판단)의 비교, 신입·주니어·시니어가 AI 와 일할 때 맡는 몫의 차이, 체감 속도와 실제 결과가 다를 수 있다는 점(수치 없이 경향만), 예시 프로그램은 가상의 하루 작업 목록을 '사람이 판단'과 'AI 에게 맡김'으로 분류해 시간 비중 표를 출력한다
개발자KR · 원고 갱신
이 장에서 배우는 것
개발자가 하는 일을 떠올리면 키보드로 코드를 입력하는 모습이 먼저 생각난다. 코드란 컴퓨터가 수행할 일을 적어 놓은 지시문이다. 화면에 글자가 빠르게 늘어나면 개발도 빠르게 진행되는 것처럼 보인다. 그런데 코드가 많이 생겼다는 사실과 필요한 일이 잘 끝났다는 사실은 다르다. 공부 시간을 기록하는 프로그램이 길게 완성되었더라도 기록이 사라지거나 합계가 틀리면 사용자는 그 프로그램을 믿고 쓰기 어렵다.
인공지능(AI)이 코드 초안을 만드는 일을 도울 수 있게 되면서 개발자의 하루를 바라보는 기준도 달라지고 있다. 이 장에서는 직업 전체가 사라진다고 단정하는 대신, 그 안에 들어 있는 일의 비중이 바뀐다는 관점으로 살펴본다. 직접 작성하는 시간뿐 아니라 요구를 정리하고, 일을 맡기고, 결과를 읽고, 실행해서 확인하고, 사용할지 판단하는 시간을 함께 본다. 아래의 작업 방식은 2026년 10월 기준 예시다. 특정 제품의 기능이나 성능을 전제로 하지 않는다.
- 코드를 작성하는 일과 개발 결과에 책임지는 일을 구분한다.
- 직접 작성하는 하루와 AI의 도움을 받는 하루를 작업의 흐름으로 비교한다.
- 신입·주니어·시니어가 AI와 일할 때 확인하고 판단하는 범위의 차이를 설명한다.
- 체감 속도와 실제 완료 속도가 다를 수 있는 이유를 찾는다.
- 가상의 하루 작업을 분류하는 Python 프로그램을 읽고 실행해 시간 비중을 확인한다.
문제 상황
개발 공부를 시작한 지민은 하루에 무엇을 공부했는지 기록하는 작은 도구를 만들려고 한다. 날짜, 공부한 주제, 공부 시간을 입력하면 그날의 합계를 보여 주면 된다. 지민은 AI에게 “학습 기록장을 만들어 달라”고 요청한다. 잠시 뒤 입력 화면과 합계 계산 코드가 포함된 답을 받는다. 혼자 처음부터 작성할 때보다 눈앞에 결과가 빨리 나타난다.
하지만 코드를 실행해 보니 지민이 생각하지 못한 질문이 생긴다. 공부 시간은 분으로 입력하는가, 시간으로 입력하는가. 같은 날짜에 여러 기록을 남길 수 있는가. 잘못 입력한 음수를 어떻게 처리하는가. 프로그램을 종료하면 기록이 남아야 하는가. AI의 답은 이 질문들에 어떤 선택을 했지만, 그 선택이 지민의 목적에 맞는지는 별개의 문제다.
지민은 답을 다시 요청하고, 수정된 코드를 읽고, 같은 날짜의 기록을 두 번 입력해 본다. 처음에는 없던 오류가 수정 과정에서 생기기도 한다. 눈에 보이는 코드 작성 시간은 줄었지만, 요청을 다듬고 결과를 확인하는 시간이 늘어난다. 여기서 필요한 질문은 “AI가 얼마나 빨리 썼는가”만이 아니다. “내가 원하는 결과를 얻기 위해 어떤 일을 했는가”도 함께 물어야 한다.
학습 기록장 초안을 만들어 달라. 공부 시간은 분 단위로 입력하며, 같은 날짜에 여러 기록을 남길 수 있어야 한다. 먼저 네가 이해한 동작을 설명하고, 내가 확인할 입력 예시를 제시해 달라.
이 요청문도 일을 끝내 주는 보증서는 아니다. 설명이 목적에 맞는지 읽고, 실행 결과를 확인해야 한다. 다만 “만들어 달라”는 한마디에 숨어 있던 선택을 드러내는 데 도움이 된다. 이 장에서는 학습 기록장 자체를 구현하지 않는다. 지민이 그 도구를 만들면서 보내는 가상의 하루를 분류해, 개발에 어떤 종류의 시간이 들어가는지 살펴본다.
코드 작성에서 작업 전체로 시선을 넓힌다
개발은 필요한 동작을 정하고, 그것을 코드로 표현하고, 실제로 원하는 대로 움직이는지 확인하는 일이다. 타이핑은 그 과정의 일부다. AI의 도움을 받기 전에도 요구를 이해하거나 오류를 찾는 일은 있었다. 따라서 예전의 개발자는 입력만 했고 지금의 개발자는 생각만 한다는 식으로 나누면 실제 일을 잘못 이해하게 된다. 비교할 것은 업무의 존재 여부보다 시간과 주의가 어디에 더 많이 쓰이는가다.
| 작업 | 직접 작성할 때 | AI의 도움을 받을 때 |
|---|---|---|
| 요구 정리 | 만들면서 빠진 조건을 발견하기도 한다 | 맡기기 전에 조건을 말로 드러내는 일이 중요해진다 |
| 코드 작성 | 작성자가 지시문을 직접 구성한다 | 초안을 받아 필요한 부분을 고친다 |
| 읽기 | 자신이 쓴 코드와 참고한 코드를 읽는다 | 자신이 쓰지 않은 코드의 선택까지 파악한다 |
| 확인 | 실행하며 예상과 결과를 비교한다 | 생성된 설명과 코드가 서로 맞는지도 확인한다 |
| 판단 | 목적에 맞게 완성되었는지 결정한다 | 받은 결과를 채택하거나 수정하거나 버린다 |
AI에게 맡기기 쉬운 작업에는 반복되는 코드의 초안 작성, 이미 정한 형식에 맞춘 정리, 수정 후보 제시 등이 있다. 그러나 맡길 수 있다는 말은 확인이 필요 없다는 뜻이 아니다. 지민이 “공부 시간은 분 단위다”라고 정했다면 AI가 계산 코드를 제안할 수 있다. 그 코드가 실제로 분을 더하는지, 다른 곳에서는 시간을 시간 단위로 취급하지 않는지는 사람이 확인해야 한다.
일을 맡기는 과정에도 사람의 판단이 들어간다. 무엇을 맡길지 정하고, 필요한 정보를 제공하고, 답을 받아들일지 결정하기 때문이다. 반대로 사람이 판단하는 작업에서도 AI의 도움을 받을 수 있다. 확인할 입력 후보를 제안받거나 어려운 코드의 설명을 요청할 수 있다. 중요한 경계는 누가 키보드를 눌렀는가보다 누가 결과를 확인하고 다음 행동을 결정하는가에 있다.
그림의 두 흐름은 실제 직무의 모든 일을 담은 시간표가 아니다. 코드 작성에 눈길이 쏠리기 쉬운 상황을 비교하기 위한 그림이다. AI를 쓰더라도 직접 작성하는 구간은 남을 수 있다. 어떤 날은 요구가 자주 바뀌고, 어떤 날은 이미 있는 코드를 오래 읽어야 한다. 매일 같은 비중으로 일할 것이라고 기대할 필요는 없다.
이 변화는 공부를 시작하는 사람에게도 의미가 있다. 코드를 처음부터 혼자 길게 쓰는 능력만으로 개발 공부를 설명하기 어려워진다. 원하는 동작을 말로 설명하고, 짧은 코드를 읽고, 실행 결과가 기대와 같은지 살피는 활동도 공부에 포함된다. 직접 작성하는 연습은 이런 활동을 이해하는 데 도움을 준다. 입력을 빠르게 대신하는 도구가 생겨도 컴퓨터가 실제로 어떤 지시를 수행하는지 알아야 결과를 판단할 수 있다.
경험에 따라 맡는 판단의 범위가 달라진다
신입, 주니어, 시니어는 경험과 책임 범위를 설명할 때 쓰는 표현이다. 조직마다 기준이 다르며, 직함만으로 능력이나 권한을 알 수는 없다. 여기서는 신입을 업무 흐름을 익히는 사람, 주니어를 정해진 범위의 작업을 수행하는 사람, 시니어를 여러 작업의 연결과 선택의 영향을 함께 살피는 사람으로 생각한다.
| 역할 | AI에 맡기는 예 | 사람이 맡는 몫 | 확인할 질문 |
|---|---|---|---|
| 신입 | 짧은 코드 설명과 작성 초안 | 동작을 따라 읽고 모르는 부분을 드러낸다 | 이 입력이 왜 이 결과가 되는가 |
| 주니어 | 정해진 기능의 구현 후보 | 요구와 맞는지 확인하고 맡은 범위의 수정을 끝낸다 | 주어진 조건을 빠뜨리지 않았는가 |
| 시니어 | 여러 구현 방향의 비교 자료 | 주변 작업에 미치는 영향과 선택의 비용을 판단한다 | 이 선택을 함께 유지할 수 있는가 |
신입이 AI에게 코드 설명을 받았다면 그 설명을 외우는 데서 멈추지 않아야 한다. 학습 기록 두 개를 넣었을 때 합계가 어떻게 만들어지는지 직접 따라가 본다. 설명 속 단어를 이해하지 못하면 이해하지 못한 부분을 표시한다. 질문을 구체화하는 일이 신입의 중요한 몫이다. 맡은 범위를 넘어서는 판단은 함께 일하는 사람에게 확인한다.
주니어는 답이 그럴듯한지를 넘어 맡은 작업을 끝낼 수 있는지를 살핀다. 지민의 기록장에서 같은 날짜의 기록을 여러 번 남겨야 한다면, 새 기록이 이전 기록을 덮어쓰지 않는지 확인한다. AI가 제안한 수정이 입력과 합계에 어떤 영향을 주는지도 읽는다. 자신이 맡은 기능을 설명하고 그 기능의 결과를 확인할 수 있어야 한다.
시니어는 한 기능이 주변 작업과 어떤 관계를 맺는지 더 넓게 본다. 기록 저장 방식이 달라지면 다른 사람이 만든 화면도 바뀌는가. 지금 선택한 방식으로 이후 수정이 가능한가. AI가 제안한 여러 후보 중 어느 것이 현재 목적에 맞는가. 여기서 경험은 답을 빠르게 고르는 데만 쓰이지 않는다. 답을 고르기 전에 어떤 질문을 해야 하는지 알아차리는 데도 쓰인다.
역할이 달라도 공통으로 남는 일은 확인이다. 신입은 작은 입력과 출력부터 확인하고, 경험이 쌓이면 더 넓은 영향을 확인한다. AI가 자신 있게 설명했다고 해서 확인 범위가 사라지지는 않는다. 처음 공부하는 독자는 모든 판단을 한꺼번에 맡으려 하기보다, 짧은 코드 하나의 결과를 자신의 말로 설명하는 데서 출발할 수 있다.
빠르게 보이는 일과 끝난 일은 다를 수 있다
답이 빨리 나타나면 작업도 빨라졌다고 느끼기 쉽다. 이 체감은 이해할 만하다. 빈 화면 앞에서 첫 문장을 고민하던 시간이 줄어들기 때문이다. 하지만 실제 결과를 비교하려면 요청을 준비하는 시간, 받은 코드를 읽는 시간, 실행하는 시간, 잘못된 부분을 다시 고치는 시간까지 함께 봐야 한다.
조건이 분명하고 결과를 쉽게 확인할 수 있는 작업에서는 초안이 빨리 생기는 도움이 완료까지 이어질 수 있다. 조건이 모호하거나 주변 코드와의 관계를 파악하기 어려운 작업에서는 확인과 재작업이 늘어날 수 있다. 그러므로 AI 사용 여부만으로 모든 작업의 속도를 같은 방향으로 예상하기 어렵다. 이는 특정 도구의 우열에 관한 이야기가 아니라 작업의 성격과 확인 비용에 관한 이야기다.
완료 기준도 비교에 영향을 준다. “코드가 화면에 나타났다”를 완료로 삼으면 매우 빠르게 끝난 것처럼 보인다. “정해 둔 입력을 받아 예상 결과를 내고, 읽어 보았을 때 의도와 맞는다”를 기준으로 삼으면 그 뒤의 시간이 포함된다. 두 방식을 비교할 때는 같은 범위의 일을 같은 완료 기준으로 보아야 한다.
이제 하루 작업 목록을 두 범주로 분류해 보자. 프로그램에서 “사람이 판단”은 요구를 정하거나 결과를 확인하는 작업을 뜻한다. “AI에게 맡김”은 정해 둔 조건에 따라 초안이나 수정 후보를 받는 작업을 뜻한다. 실제 작업은 서로 섞일 수 있지만, 여기서는 한 작업에 대표 범주 하나를 붙인다.
예제의 모든 시간은 설명용 가상값이다. AI의 처리 시간이나 개발자의 생산성을 측정한 값이 아니다. “AI에게 맡김”에 적힌 시간 역시 AI만 작동한 시간을 뜻하지 않는다. 해당 작업 구간에 배정한 시간이다. 기다리면서 다른 일을 하는 상황은 제외하고, 작업들이 순서대로 이어지는 하루라고 가정한다. 이 구분으로 누가 더 많은 노동을 했는지 계산할 수는 없지만, 무엇에 시간을 배정했는지는 확인할 수 있다.
완성 코드
다음 코드를 main.py라는 이름으로 저장한다. Python은 코드를 위에서 아래로 읽으며 실행하는 프로그래밍 언어다. 이 프로그램은 외부 서비스에 접속하지 않고, 미리 적어 둔 작업 목록만 계산한다. 빈 줄을 포함해 44줄이며, 입력을 기다리지 않고 바로 끝난다.
tasks = [
("요구 정리", 60, "사람이 판단"),
("맡길 범위 정하기", 20, "사람이 판단"),
("코드 초안 받기", 60, "AI에게 맡김"),
("반복 부분 정리 받기", 40, "AI에게 맡김"),
("코드 읽기", 50, "사람이 판단"),
("실행 결과 확인", 60, "사람이 판단"),
("수정 후보 받기", 40, "AI에게 맡김"),
("최종 선택", 30, "사람이 판단"),
]
categories = ["사람이 판단", "AI에게 맡김"]
totals = {"사람이 판단": 0, "AI에게 맡김": 0}
day_minutes = 0
for name, minutes, category in tasks:
if category not in totals:
raise ValueError("알 수 없는 분류: " + category)
if minutes <= 0:
raise ValueError("작업 시간은 양수여야 한다.")
totals[category] = totals[category] + minutes
day_minutes = day_minutes + minutes
if day_minutes == 0:
raise ValueError("작업 목록이 비어 있다.")
print("가상의 하루 작업 목록")
print("시간은 설명용 가상값이며 단위는 분이다.")
print("작업 | 분 | 분류")
for name, minutes, category in tasks:
print(f"{name} | {minutes} | {category}")
print()
print("시간 비중 표")
print("분류 | 분 | 비중")
for category in categories:
minutes = totals[category]
percent = minutes / day_minutes * 100
print(f"{category} | {minutes} | {percent:.1f}%")
print(f"합계 | {day_minutes} | 100.0%")
print()
print("확인: 두 분류의 시간을 합하면 전체 시간과 같아야 한다.")
print(f"분류 합계: {sum(totals.values())}분")
프로그램은 작업 이름을 보고 스스로 분류하지 않는다. 사람이 각 작업에 붙인 분류를 읽어 합산한다. 이 선택은 의도적이다. “코드 읽기”라는 이름만으로 누가 어떤 책임을 맡았는지 알아낼 수 없기 때문이다. 이 예제에서 드러내려는 생각도 분류를 자동으로 결정하는 기술보다 분류 기준을 먼저 정하는 태도다.
줄별 해설
줄 번호는 위 코드의 첫 줄부터 빈 줄까지 포함해 센다. 먼저 자료를 준비하고, 다음으로 합계를 계산한 뒤, 마지막으로 표를 출력한다. 처음에는 기호를 모두 외우기보다 각 줄이 준비·계산·출력 중 어느 일을 하는지 따라가면 된다.
| 줄 | 코드의 역할 | 읽는 방법 |
|---|---|---|
| 1 | 작업 목록을 시작한다 | tasks라는 이름에 여러 작업을 담는다. 대괄호는 목록의 시작이다. |
| 2 | 요구 정리를 등록한다 | 괄호 안에 이름, 분 단위 시간, 분류를 차례로 적는다. |
| 3 | 맡길 범위 정하기를 등록한다 | 일을 맡기는 범위를 정하는 시간은 사람이 판단하는 시간으로 둔다. |
| 4 | 코드 초안 받기를 등록한다 | 초안 작업 구간을 AI에게 맡기는 범주에 넣는다. |
| 5 | 반복 부분 정리 받기를 등록한다 | 정리 작업에도 가상의 시간을 배정한다. |
| 6 | 코드 읽기를 등록한다 | 받은 결과를 이해하는 시간을 따로 남긴다. |
| 7 | 실행 결과 확인을 등록한다 | 실제로 실행하고 결과를 살피는 시간을 포함한다. |
| 8 | 수정 후보 받기를 등록한다 | 수정안을 받는 구간을 별도 작업으로 적는다. |
| 9 | 최종 선택을 등록한다 | 결과를 채택할지 결정하는 시간이다. |
| 10 | 작업 목록을 닫는다 | 닫는 대괄호가 목록의 끝을 나타낸다. |
| 11, 15, 23, 26, 32, 41 | 부분 사이를 나눈다 | 빈 줄은 실행할 지시가 없으며 읽기 쉽게 구간을 나눈다. |
| 12 | 출력 순서를 정한다 | 두 분류를 이 목록에 적힌 순서대로 출력한다. |
| 13 | 분류별 합계를 준비한다 | 중괄호 안의 사전은 이름에 값을 연결하는 자료다. 두 합계는 0에서 시작한다. |
| 14 | 전체 시간을 준비한다 | day_minutes에 전체 작업 시간을 쌓는다. |
| 16 | 작업을 하나씩 꺼낸다 | 반복할 때마다 이름, 시간, 분류가 각각의 이름에 들어간다. |
| 17 | 모르는 분류인지 확인한다 | 분류가 합계 사전에 없으면 다음 줄을 실행한다. |
| 18 | 분류 오류로 실행을 멈춘다 | raise는 오류를 알리고 중단한다. ValueError는 값이 조건에 맞지 않음을 나타낸다. |
| 19 | 시간이 양수인지 확인한다 | 0 이하라면 유효한 작업 시간으로 받아들이지 않는다. |
| 20 | 시간 오류로 실행을 멈춘다 | 왜 멈추었는지 설명하는 문장을 함께 남긴다. |
| 21 | 해당 분류의 시간을 늘린다 | 기존 합계에 현재 작업 시간을 더해 다시 저장한다. |
| 22 | 전체 시간을 늘린다 | 분류와 관계없이 모든 작업 시간을 더한다. |
| 24 | 전체 시간이 0인지 확인한다 | 작업이 하나도 없으면 합계가 처음 값인 0으로 남는다. |
| 25 | 빈 목록으로 실행을 멈춘다 | 뒤에서 비중을 계산할 때 0으로 나누는 상황을 막는다. |
| 27 | 목록 제목을 출력한다 | print는 괄호 안의 값을 화면에 보여 준다. |
| 28 | 시간의 성격을 밝힌다 | 출력만 보아도 가상값과 단위를 알 수 있게 한다. |
| 29 | 목록의 열 이름을 출력한다 | 세로선은 항목을 구분하는 글자다. |
| 30 | 출력할 작업을 하나씩 꺼낸다 | 앞서 합산한 것과 같은 작업 목록을 다시 읽는다. |
| 31 | 작업 한 줄을 출력한다 | f가 붙은 문자열은 중괄호 위치에 각 값을 넣는다. |
| 33 | 빈 줄을 출력한다 | 작업 목록과 비중 표를 화면에서 구분한다. |
| 34 | 비중 표의 제목을 출력한다 | 다음 출력이 합산 결과임을 알린다. |
| 35 | 비중 표의 열 이름을 출력한다 | 분류, 시간, 비중을 차례로 표시한다. |
| 36 | 두 분류를 차례로 꺼낸다 | 12줄에서 정한 순서를 사용한다. |
| 37 | 현재 분류의 합계를 꺼낸다 | 분류 이름으로 사전에 저장된 시간을 찾는다. |
| 38 | 전체 시간에 대한 비중을 계산한다 | 분류 시간을 전체 시간으로 나누고 100을 곱한다. |
| 39 | 분류별 결과를 출력한다 | :.1f는 비중을 소수점 아래 한 자리로 표시한다. |
| 40 | 전체 합계를 출력한다 | 들여쓰기가 끝났으므로 반복이 끝난 뒤 한 번 실행한다. |
| 42 | 빈 줄을 출력한다 | 표와 확인 안내 사이를 띄운다. |
| 43 | 합계 확인 방법을 출력한다 | 분류별 시간의 합과 전체 시간을 비교하도록 안내한다. |
| 44 | 분류 합계를 출력한다 | values는 사전의 값들을 꺼내고 sum은 그 값들을 더한다. |
들여쓰기는 지시가 어느 부분에 속하는지 나타낸다. 17~22줄은 작업을 하나씩 꺼내는 반복 안에 있다. 그중 18줄은 분류가 잘못되었을 때만 실행하고, 20줄은 시간이 잘못되었을 때만 실행한다. 아래쪽에서는 37~39줄이 분류마다 반복된다. 40줄은 왼쪽으로 돌아와 있으므로 합계 줄이 두 번 나오지 않는다.
이 프로그램은 사람이 붙인 분류가 업무상 타당한지까지 검사하지 않는다. “최종 선택”을 AI에게 맡김으로 바꾸어도 허용된 분류이므로 계산은 진행된다. 실행에 성공했다는 사실과 분류 기준이 적절하다는 사실은 구분해야 한다. 코드는 계산 규칙을 수행하고, 그 규칙이 목적에 맞는지는 독자가 읽고 판단한다.
실행 결과
명령을 입력하는 창인 터미널에서 main.py가 있는 폴더로 이동한 뒤 다음 명령을 실행한다. Python 3.12 이상이 설치되어 있다고 가정한다.
python3 main.py
예상 출력은 다음과 같다. 시간이나 난수를 사용하지 않으므로 같은 코드로 실행하면 같은 내용이 나온다.
가상의 하루 작업 목록
시간은 설명용 가상값이며 단위는 분이다.
작업 | 분 | 분류
요구 정리 | 60 | 사람이 판단
맡길 범위 정하기 | 20 | 사람이 판단
코드 초안 받기 | 60 | AI에게 맡김
반복 부분 정리 받기 | 40 | AI에게 맡김
코드 읽기 | 50 | 사람이 판단
실행 결과 확인 | 60 | 사람이 판단
수정 후보 받기 | 40 | AI에게 맡김
최종 선택 | 30 | 사람이 판단
시간 비중 표
분류 | 분 | 비중
사람이 판단 | 220 | 61.1%
AI에게 맡김 | 140 | 38.9%
합계 | 360 | 100.0%
확인: 두 분류의 시간을 합하면 전체 시간과 같아야 한다.
분류 합계: 360분
읽기로도 계산을 확인할 수 있다. 사람이 판단하는 작업은 60, 20, 50, 60, 30분이므로 합계가 220분이다. AI에게 맡기는 작업은 60, 40, 40분이므로 140분이다. 두 값을 합하면 전체 시간인 360분과 같다. 각각을 전체 시간으로 나눈 뒤 백분율로 표시하면 출력된 비중이 된다.
이 표만으로 AI를 사용해 시간이 얼마나 줄었는지는 알 수 없다. 비교할 다른 하루가 없고, 작업 결과의 품질도 기록하지 않았기 때문이다. 표가 보여 주는 것은 설정한 하루의 시간 배분이다. AI에게 맡긴 시간이 전체의 일부라는 사실을 곧바로 절약한 시간으로 해석하면 안 된다. 반대로 사람이 판단한 시간이 많다는 이유로 AI의 도움이 없었다고 결론 내릴 수도 없다.
실무에서 자주 틀리는 것
작업 개수를 시간 비중으로 착각한다
아래는 따로 실행할 수 있는 짧은 비교 예제다. 작업이 몇 개인지 세어 비중을 구하면 각 작업의 길이가 같다고 취급하게 된다. 잘못된 코드에서 사람 작업 한 개와 AI 작업 한 개는 같은 비중으로 나오지만, 배정한 시간은 다르다.
human_times = [60]
ai_times = [20]
percent = len(human_times) / (len(human_times) + len(ai_times)) * 100
print(f"{percent:.1f}%")
고친 코드는 작업의 수를 세는 len 대신 시간을 더하는 sum을 사용한다. 위 코드는 50.0%를, 아래 코드는 75.0%를 출력한다. 무엇의 비중인지 정한 뒤 그에 맞는 값을 계산해야 한다.
human_times = [60]
ai_times = [20]
percent = sum(human_times) / (sum(human_times) + sum(ai_times)) * 100
print(f"{percent:.1f}%")
분류가 다르면 모두 AI 작업으로 넣는다
분류 이름에 오타가 있을 때 “사람이 판단”이 아니라는 이유만으로 AI 작업에 넣으면 잘못된 자료가 정상 결과처럼 보인다. 다음 코드는 오타가 난 분류도 AI 시간으로 더한다.
category = "사람이 판다"
minutes = 20
human_minutes = 0
ai_minutes = 0
if category == "사람이 판단":
human_minutes = human_minutes + minutes
else:
ai_minutes = ai_minutes + minutes
print(human_minutes, ai_minutes)
고친 코드는 두 분류를 각각 확인하고, 둘 다 아니면 오류로 알린다. 아래 코드를 그대로 실행하면 오타 때문에 의도적으로 멈춘다. 분류를 “사람이 판단”으로 고치면 20과 0을 출력한다. 오류를 숨기지 않는 편이 자료를 바로잡는 데 도움이 된다.
category = "사람이 판다"
minutes = 20
human_minutes = 0
ai_minutes = 0
if category == "사람이 판단":
human_minutes = human_minutes + minutes
elif category == "AI에게 맡김":
ai_minutes = ai_minutes + minutes
else:
raise ValueError("분류를 확인해야 한다.")
print(human_minutes, ai_minutes)
전체 시간 대신 한쪽 시간을 분모로 쓴다
비중을 구할 때 나누는 기준이 되는 값, 곧 분모를 확인해야 한다. 다음 코드는 사람 시간을 AI 시간으로 나눈다. 두 시간의 상대적인 크기는 계산하지만 전체 하루에서 차지하는 비중을 계산하지는 않는다.
human_minutes = 220
ai_minutes = 140
percent = human_minutes / ai_minutes * 100
print(f"{percent:.1f}%")
고친 코드는 두 범주의 합을 분모로 사용한다. 전체에 대한 비중을 묻는다면 전체가 무엇인지 코드에서도 드러나야 한다.
human_minutes = 220
ai_minutes = 140
day_minutes = human_minutes + ai_minutes
percent = human_minutes / day_minutes * 100
print(f"{percent:.1f}%")
빈 작업 목록을 정상적인 하루처럼 계산한다
작업이 없을 때 전체 시간은 0이다. 다음 코드는 0으로 나누려 하므로 계산 중에 오류가 발생한다. 자료가 왜 비어 있는지 알려 주지 않아 원인을 찾기도 어렵다.
human_minutes = 0
day_minutes = 0
percent = human_minutes / day_minutes * 100
print(f"{percent:.1f}%")
고친 코드는 계산 전에 조건을 확인한다. 이 짧은 예제를 실행하면 의도한 안내와 함께 멈춘다. 완성 코드도 빈 목록을 비중 표로 표시하지 않는 선택을 했다. 빈 목록을 어떻게 다룰지는 목적에 따라 정하되, 0으로 나누는 계산을 그대로 진행해서는 안 된다.
human_minutes = 0
day_minutes = 0
if day_minutes == 0:
raise ValueError("작업을 등록한 뒤 계산해야 한다.")
percent = human_minutes / day_minutes * 100
print(f"{percent:.1f}%")
한눈에 보기
| 살펴볼 대상 | 핵심 생각 | 작게 해 볼 행동 |
|---|---|---|
| 개발자의 일 | 작성 외에도 요구 정리·읽기·검증·판단이 들어 있다 | 작업 목록에 확인 시간을 따로 적는다 |
| AI에게 맡기는 일 | 초안을 받아도 채택 여부는 확인해야 한다 | 받은 코드의 입력과 출력을 따라 읽는다 |
| 경험에 따른 역할 | 경험이 쌓이면 판단하는 범위가 넓어진다 | 자신이 확인할 수 있는 범위와 모르는 부분을 말한다 |
| 속도의 비교 | 초안 생성과 작업 완료는 다른 시점이다 | 읽기와 수정 시간까지 같은 기준으로 비교한다 |
| 예제의 시간 비중 | 가정한 배분을 보여 주며 생산성 향상을 증명하지 않는다 | 분류 합계와 전체 시간이 같은지 확인한다 |
개발 공부를 시작할 때는 결과를 빨리 얻는 경험과 결과를 이해하는 경험을 함께 쌓을 수 있다. AI가 짧은 코드를 만들어 주면 실행해 보고, 출력 중 한 줄이 어디에서 만들어졌는지 찾아본다. 이해하지 못한 부분은 질문하고, 설명을 받으면 코드와 맞는지 다시 읽는다. 이런 행동을 하루의 작업으로 인정하면 공부의 목표도 타이핑 양에서 조금 더 넓어진다.
개발자의 역할을 타이핑에만 묶어 두지 않으면, AI가 코드를 만드는 상황에서도 자신이 배워야 할 일을 찾을 수 있다. 다음 장에서는 이 변화와 연결해 교육과정의 관심이 지식 목록에서 실제로 해낼 수 있는 역량으로 이동하는 방향을 살펴본다.
연습 문제
- 완성 코드에서 “코드 읽기”를 50분에서 80분으로 바꾼다. 실행하기 전에 사람이 판단하는 시간, 전체 시간, 두 분류의 비중을 예상한다. 실행 후 예상과 비교한다.
- “AI에게 맡김”의 비중이 줄어들면 AI의 도움이 줄었다고 결론 내려도 되는가. 첫 번째 문제의 변경을 이용해 이유를 설명한다.
- 작업 목록에 “학습 목표 다시 정하기”를 30분으로 추가한다. 어느 분류에 넣을지 이유를 먼저 적는다. 원래 코드의 값에서 출발해 실행하고 합계를 확인한다.
- AI에게 초안을 받은 직후 작업이 끝났다고 생각한 학생이 있다. 같은 완료 기준으로 하루를 비교하려면 어떤 작업 시간을 더 기록해야 하는지 세 가지 이상 적는다.
정답과 해설
사람이 판단하는 시간은 30분 늘어나 250분이 되고, AI에게 맡긴 시간은 140분으로 유지된다. 전체 시간은 390분이다. 소수점 아래 한 자리로 표시하면 사람 비중은 64.1%, AI 비중은 35.9%다. 변경한 작업의 분류에만 시간이 더해졌는지와 두 분류의 합이 전체 시간과 같은지를 확인한다.
그렇게 결론 내릴 수 없다. AI에게 맡긴 시간은 그대로인데 사람이 읽는 시간이 늘어 전체 시간과 비중이 바뀌었다. 도움의 정도를 판단하려면 같은 목적의 결과를 얻었는지, 확인과 수정에 어떤 차이가 있었는지도 살펴야 한다. 이 표에는 그런 정보가 없다.
이 장의 기준에서는 “사람이 판단”이 적절하다. 무엇을 공부할지 선택하는 작업이기 때문이다. AI에게 후보를 물어볼 수 있어도 목표를 채택하는 판단은 남는다. 원래 목록에 30분을 추가하면 사람 시간은 250분, AI 시간은 140분, 전체 시간은 390분이다. 비중은 각각 64.1%, 35.9%다. 첫 번째 문제의 변경을 함께 적용했다면 다른 결과가 나오므로 출발한 목록도 확인해야 한다.
요청을 준비하는 시간, 받은 코드를 읽는 시간, 실행하고 예상 결과와 비교하는 시간, 잘못된 부분을 수정하고 다시 확인하는 시간, 최종 채택을 결정하는 시간 등을 기록할 수 있다. 작성 방식이 달라도 같은 동작을 확인한 상태를 완료로 삼아야 비교가 의미를 갖는다. 빠르게 나타난 초안은 그 과정의 한 시점이다.
READER FEEDBACK
질문·의견
내용에 관한 질문이나 더 나은 설명을 위한 의견을 남겨 주세요. 오탈자는 위의 제보 양식이 더 빨리 반영됩니다. 이 댓글은 원래 게시글과 같은 자리에 쌓입니다.
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.