AI 시대의 탑다운 학습과 생성 후 이해

요즘 낯선 기술을 배우는 순서가 바뀌었다. 예전에는 개념을 먼저 읽고 작은 예제를 따라 한 뒤 충분히 익숙해졌다고 느낄 때 결과물을 만들었다. 지금은 종종 정반대로 시작한다.

AI에게 먼저 작동하는 결과물을 만들어 달라고 한다. 익숙하지 않은 스택으로 구현된 기능일 수도 있고 처음 보는 아키텍처의 설계안일 수도 있다. 때로는 내가 파고들고 싶은 주제로 쓴 글 한 편이기도 하다. 완성본을 눈앞에 놓고 나면 그때부터 묻기 시작한다. 왜 이런 모양이 되었는지, 다른 선택지는 무엇이었는지, 어느 부분을 바꾸면 무너지는지.

학교에서 이랬다면 정답지부터 펼쳐본다고 혼났을 법한 순서다. 물론 AI가 내놓은 결과물은 검증된 정답지가 아니다. 그래서 먼저 보는 행위보다 그다음에 무엇을 하는가가 학습의 차이를 만든다고 생각한다.

결과물은 목적지이면서 지도다

새로운 기술을 밑에서부터 공부하면 필요한 개념을 차례로 쌓을 수 있다. 대신 지금 배우는 문법과 설정이 실제 결과물의 어디에 쓰이는지는 한동안 보이지 않는다. 나는 이 구간에서 자주 길을 잃었다. 열심히 읽고 있는데 무엇을 향해 가는지는 흐릿했다.

완성본을 먼저 만들면 적어도 목적지는 생긴다. 실행되는 코드와 화면, 모듈의 경계가 눈앞에 놓인다. 모르는 것도 막연한 덩어리에서 구체적인 질문으로 바뀐다. 이 계층은 왜 나뉘어 있는지, 트랜잭션의 경계는 왜 하필 여기인지, 같은 요구사항을 내가 아는 스택으로 풀면 어떤 모양이 되는지 묻게 된다.

처음부터 모든 기반 지식을 순서대로 훑는 대신 결과물에서 출발해 필요한 개념으로 내려간다. 위에서 전체 모양을 보고 아래의 원리를 찾아가는 탑다운 학습(top-down learning)이다. AI로 결과물을 먼저 생성하고 질문을 거듭하며 이해를 채운다는 점에서는 뒤에서 살펴볼 생성 후 이해(generation-then-comprehension)와도 맞닿아 있다.

실무에서 경계를 넘어가는 방법

요즘은 서버 코드나 데이터 작업처럼 익숙하지 않은 경계를 넘어갈 일이 있다. 이때 필요한 기술 전체를 먼저 공부한 뒤 일에 들어가려 하면 시작하는 데만 꽤 오래 걸린다. 대신 해결하려는 문제와 지켜야 할 제약을 AI에 설명하고 구현 가능한 초안을 먼저 만든다.

가령 백필(backfill) 전략을 검토한다면 결과물에서 질문을 거꾸로 꺼낸다. 데이터를 어떤 단위로 나누었는지, 중간에 실패한 작업을 다시 실행해도 같은 결과가 나오는지, 백필 도중 들어온 쓰기와 충돌하지 않는지 확인한다. AI가 그럴듯한 이유를 설명해도 기존 코드와 테스트가 같은 말을 하는지 다시 대조한다.

낯선 추상화는 내가 아는 개념에 대응시켜 보고 일부를 바꿨을 때 무엇이 깨지는지도 확인한다. 핵심 흐름은 빈 화면에서 다시 작성해 본다. 설명을 읽을 때는 다 이해한 것 같다가도 직접 다시 만들면 구멍이 꽤 정직하게 드러난다.

새로운 스택 전체를 능숙하게 다루는 것이 당장의 목표는 아니다. 지금 해결할 문제에 쓰인 원리와 그 선택이 만든 위험을 설명할 수 있는 곳까지 내려간다. 다음 문제에서 같은 개념을 만나면 더 적은 도움으로 접근하고 반복해서 마주치는 부분은 그때 기반 지식으로 굳힌다.

블로그도 먼저 한 편을 완성한다

글을 쓰는 과정도 비슷해졌다. 관심은 있지만 잘 모르는 주제나 오래 파고들고 싶은 개념을 고른 다음 자료와 질문을 모아 AI에게 초안 전체를 먼저 쓰게 한다. 목차만 받는 것이 아니라 처음부터 끝까지 이어지는 글을 일단 만든다.

그 초안은 게시물이 아니라 내가 공부할 첫 번째 완성본이다.

문장마다 정말 이해한 내용인지 확인하고 인용한 근거를 원문에서 다시 읽는다. 내 경험과 맞지 않는 설명은 걷어내고 빠진 반례를 찾는다. AI가 매끈하게 이어놓은 문장도 내 입으로 설명할 수 없다면 다시 쓴다. 그러다 보면 처음 받은 글과 마지막에 남은 글은 제법 다른 모양이 된다.

이 글도 같은 방식으로 시작했다. 내가 해오던 학습 습관과 실무 사례를 먼저 꺼내놓고 AI로 초안을 완성했다. 그 뒤 문장을 다시 읽고 사실을 확인했다. 내 생각보다 앞서 나간 부분은 덜어냈고 내 언어가 아닌 문장은 바꿨다. AI를 썼다는 사실을 감출 이유는 없다. 오히려 어디까지가 생성이고 어디서부터 내 판단이 들어갔는지 스스로 구분하지 못하는 쪽이 더 불편하다.

내가 하던 순서에는 이미 이름이 있었다

새로워진 것은 탑다운 학습 자체가 아니라 이 방식을 혼자 실행할 수 있는 조건이다. 내가 하던 순서를 설명할 말을 찾다 보니 서로 맞닿은 세 가지 개념을 발견했다. 문제에서 출발하는 탑다운 학습, 완성된 풀이를 먼저 보는 완성 예제 학습, 생성된 결과를 뒤늦게 이해하는 생성 후 이해다. 비슷해 보이지만 같은 개념은 아니다.

문제에서 원리로 내려가는 재귀적 빈틈 채우기

Gabriel Petersson은 인터뷰에서 자신이 가장 빠르게 배운 방법을 탑다운 접근으로 설명했다. 실제 문제나 만들고 싶은 것에서 시작해 당장 필요한 지식을 찾고 그 설명에서 다시 모르는 부분을 발견하면 한 층 더 내려가는 방식이다. 정해진 교육 과정을 역순으로 읽는 것이 아니라 이해하지 못한 지점을 다음 질문의 출발점으로 삼는다.

그가 든 확산 모델(diffusion model) 학습 사례가 이 과정을 잘 보여준다. 먼저 AI에게 확산 모델의 전체 코드를 작성하게 하고 실행하면서 버그를 고친다. 그다음 코드를 위에서부터 읽다가 잔차 블록(residual block) 같은 낯선 모듈을 만나면 "이 모듈이 왜 학습을 돕는가"라고 묻는다. 설명에 경사 흐름(gradient flow)이 나오면 경사가 이 경로를 통과할 때와 그렇지 않을 때 무엇이 달라지는지 다시 묻는다. 행렬 곱셈과 선형대수가 필요해지면 그림과 중간 상태를 요청하며 그 원리까지 내려간다.

한 번의 좋은 설명을 받는 것으로 끝나지 않는다. 자신이 이해한 내용을 AI에 다시 설명하고 빠진 전제나 잘못 연결한 부분을 지적하게 한다. Petersson은 이 반복을 재귀적 빈틈 채우기(recursive gap filling)라고 표현했다(인터뷰 12분 10초부터). 학술적으로 정립된 교수법의 이름이라기보다 그가 자신의 학습 습관에 붙인 표현에 가깝다.

여기서 말하는 지름길은 기초를 생략하는 길이 아니다. 지금 문제에 필요한 기초가 무엇인지 먼저 알아낸 뒤 그곳으로 바로 내려가는 길이다. 덕분에 행렬 곱셈을 왜 배우는지도 모른 채 견디는 대신 눈앞의 모듈이 작동하는 이유를 설명하기 위해 선형대수를 찾게 된다.

완성 예제와 자기 설명

완성된 풀이를 먼저 보며 배우는 완성 예제 학습(worked-example learning)은 오래전부터 연구되어 왔다. 여기서 완성 예제는 정답만 적힌 답안이 아니다. 문제와 최종 답, 그 답에 도달하는 중간 단계가 함께 제시된 예제를 뜻한다.

초보자가 아무 안내 없이 문제를 풀면 정답으로 가는 방법을 찾는 데 작업 기억을 많이 쓴다. 반면 풀이 과정이 보이는 예제에서는 "어떻게 풀지"를 탐색하는 부담을 줄이고 각 단계가 어떤 원리로 이어지는지 살펴볼 여지가 생긴다. 여러 예제에서 표면적인 차이를 걷어내고 반복되는 구조를 발견하면 다음 문제에도 적용할 수 있는 스키마(schema)가 만들어진다는 설명이다(Alexander Renkl, 2014).

그렇다고 완성본을 오래 바라본 시간이 곧 학습량이 되지는 않는다. 완성 예제 연구에서 반복해서 등장하는 조건은 자기 설명(self-explanation)이다. 학습자가 풀이에 적히지 않은 이유를 자기 말로 보충하는 활동이다. "이 단계의 목적은 무엇인가", "어떤 원리가 적용됐는가", "앞 단계와 어떻게 연결되는가", "조건이 바뀌어도 같은 선택이 유효한가"를 설명해야 예제의 모양을 외우는 데서 벗어날 수 있다.

AI가 만든 코드는 그 자체로 완성 예제가 되지 않는다. 문제와 코드만 있고 선택의 이유와 중간 판단이 빠져 있을 수 있으며 코드가 틀릴 수도 있다. 실행 결과와 원문을 대조하고 설계 선택의 이유를 채워 넣어야 비로소 학습에 쓸 만한 예제가 된다.

도움을 조금씩 걷어내는 페이딩

완성 예제 학습에는 결과물을 먼저 받는 지금의 방식에 바로 가져올 만한 장치가 하나 더 있다. 페이딩(fading)은 제공된 풀이 단계를 조금씩 지워 학습자가 채울 몫을 늘리는 방법이다. 처음에는 전체 풀이를 보고 다음 예제에서는 한 단계를 직접 완성한다. 이후 빈칸을 늘려가다가 마지막에는 문제만 보고 스스로 해결한다.

이를 코드 학습에 옮기면 처음에는 AI가 만든 전체 구현을 읽되 다음에는 핵심 함수 하나를 비워 직접 작성해 볼 수 있다. 그다음에는 인터페이스와 테스트만 남기고 구현을 채운다. 마지막에는 같은 원리가 필요한 다른 요구사항을 AI 없이 풀어본다. 연구에서 이 방법의 효과는 주로 수학처럼 풀이 절차가 비교적 분명한 영역에서 확인됐기 때문에 소프트웨어 설계나 글쓰기에도 그대로 적용된다고 단정할 수는 없다. 다만 도움을 한 번에 끊지 않고 이해한 만큼 걷어낸다는 원리는 내 방식과 잘 맞았다.

내가 이 개념들을 실무와 글쓰기에 옮긴 흐름은 다음과 같다.

생성과 이해 사이에서 갈리는 지점

Anthropic은 2026년 낯선 파이썬 라이브러리 Trio를 배우는 소프트웨어 엔지니어 52명을 대상으로 무작위 대조 실험을 진행했다. 참가자는 모두 Python을 1년 넘게 정기적으로 사용했지만 Trio는 써본 적이 없었다. 절반은 GPT-4o 기반 코딩 도우미를 쓸 수 있었고 나머지 절반은 직접 코딩했다.

과제도 단순히 문법을 기억하는 문제로 만들지 않았다. 첫 번째 과제에서는 여러 함수가 실행되는 동안 1초마다 시간을 출력하며 Trio의 nursery와 동시 실행을 다뤘다. 두 번째 과제에서는 누락된 레코드의 오류를 처리하고 메모리 채널로 결과를 전달했다. 과제가 끝난 직후에는 AI 없이 디버깅, 코드 읽기, 개념 이해를 묻는 14개 문항의 퀴즈를 풀었다. AI가 대신하기 쉬운 문법 암기를 평가에서 덜어내고 생성된 코드를 감독하는 데 필요한 이해를 보려는 설계였다(Shen and Tamkin, 2026).

AI 사용 그룹은 직후 퀴즈에서 평균 50%를 받았고 직접 코딩한 그룹은 67%를 받았다. AI 사용 그룹이 과제를 약 2분 빨리 마쳤지만 이 시간 차이는 통계적으로 유의하지 않았다. 문항별로는 디버깅에서 가장 큰 차이가 났다. 연구진은 직접 코딩한 참가자가 Trio와 관련된 오류를 더 많이 만나고 스스로 해결한 경험이 영향을 주었을 가능성을 제시했다. 오류가 적다는 것이 학습 중에도 항상 좋은 소식은 아닐 수 있다는 대목이다.

화면 녹화를 분석한 연구진은 AI 사용 방식을 여섯 가지로 나눴다.

관찰된 패턴	참가자 수	AI를 사용한 방식
AI 위임	4명	구현 전체를 AI에 맡겼다. 가장 빨랐지만 이해도는 낮았다.
점진적 AI 의존	4명	처음에는 질문으로 시작했지만 뒤로 갈수록 코드 작성을 넘겼다.
반복적 AI 디버깅	4명	오류의 원인을 이해하기보다 AI에 수정과 검증을 반복해서 요청했다.
생성 후 이해	2명	코드를 먼저 생성한 뒤 후속 질문으로 자신의 이해를 확인했다.
코드 생성과 설명의 결합	3명	코드를 요청할 때 설명도 함께 요구하고 읽는 데 시간을 썼다.
개념 질의	7명	구현은 직접 하면서 AI에는 개념만 물었고 오류도 스스로 해결했다.

앞의 세 패턴은 평균 퀴즈 점수가 40% 미만이었고 뒤의 세 패턴은 65% 이상이었다. 특히 AI 위임과 생성 후 이해는 출발 장면이 거의 같다. 둘 다 AI가 코드를 먼저 만든다. 갈림길은 생성 직후에 생겼다. 한쪽은 작동하는 코드를 얻은 시점에 멈췄고 다른 쪽은 그때부터 자신의 이해를 점검했다.

여기서 수치를 읽을 때는 조심해야 한다. 여섯 패턴은 사전에 설계한 실험군이 아니라 AI 사용 그룹의 화면 기록을 보고 사후에 분류한 관찰 범주다. 생성 후 이해에 해당한 참가자도 두 명뿐이다. 연구진 역시 특정 사용 패턴이 높은 점수를 만들었다는 인과관계를 주장하지 않았다. 이 연구는 모든 AI 학습을 판정하는 결론보다 같은 도구를 써도 인지적 관여의 정도가 달라질 수 있다는 작은 실험에 가깝다.

또 하나 눈에 들어온 결과가 있다. AI가 만든 코드를 직접 타이핑한 참가자와 그대로 붙여 넣은 참가자 사이에는 이해도에서 뚜렷한 차이가 없었다. 손으로 옮겨 적는 시간보다 그 코드에 관해 어떤 생각을 했는지가 더 중요했다. 글도 마찬가지다. AI 초안의 어미와 단어만 내 문체로 바꾸는 일은 소화라기보다 필사에 가깝다. 전제를 확인하고 문단의 순서를 바꾸며 내 경험과 맞지 않는 문장을 버릴 때 비로소 내 판단이 들어간다.

내가 여기서 얻은 것은 이 방식의 증명이 아니다. 내가 해오던 순서와 닮은 관찰 범주 하나를 찾았을 뿐이다. 구현을 통째로 넘기고 다음 일로 이동한 사람과 생성된 코드를 붙잡고 질문한 사람은 겉으로 같은 결과물을 얻는다. 하지만 그 결과물 없이 다시 문제를 만났을 때 둘의 출발점은 달라진다.

내 것으로 만들기 위한 몇 가지 확인

완성본을 학습의 출발점으로 쓰려면 마지막에 스스로 확인해야 할 것이 있다.

• 결과물이 왜 이런 구조가 되었는지 설명할 수 있는가.
• 다른 선택지와 지금 선택의 대가를 말할 수 있는가.
• 일부를 바꾸거나 망가뜨렸을 때 직접 원인을 찾을 수 있는가.
• AI 없이 핵심 부분을 다시 만들거나 자기 언어로 설명할 수 있는가.
• 사실과 출처, 실행 결과를 독립적으로 확인했는가.

여기에 답하지 못하면 결과물을 보유하고 있을 뿐 그 안의 지식까지 가진 것은 아니다. 다시 질문하고 지우고 만들어봐야 한다.

이 번거로운 과정을 거칠 거라면 처음부터 직접 만드는 것과 무엇이 다르냐는 생각도 들 수 있다. 차이는 탐색 비용에 있다. AI는 가능한 결과물과 질문의 지도를 빠르게 펼쳐준다. 나는 그 지도 위에서 지금 필요한 경로를 고르고 이해가 필요한 곳에 시간을 더 쓴다. 모든 길을 처음부터 걸어보지 않고도 멀리 갈 수 있지만 내가 실제로 지나온 길은 설명할 수 있게 만드는 방식이다.

결과를 보장할 사람

AI 덕분에 예전에는 쉽게 손대지 못했던 기술과 주제를 훨씬 짧은 시간 안에 탐색하게 됐다. 학습 속도를 높였다기보다 학습의 시작 비용을 크게 낮췄다는 표현이 더 정확하다. 일단 작동하는 무언가가 생기면 호기심은 질문이 되고 질문은 다시 공부할 경로가 된다.

그 속도가 내 실력이 되려면 소화하는 시간이 뒤따라야 한다. 생성 비용이 싸졌다고 해서 검증 비용까지 사라지는 것은 아니다. AI가 만든 코드에서 장애가 나면 “AI가 작성했습니다”라고 사용자에게 설명할 수 없다. 글의 내용이 틀렸을 때도 초안을 누가 썼는지는 독자에게 별 도움이 되지 않는다.

AI는 완성본을 만들어줄 수 있지만 그 결과를 이해하고 보장할 사람까지 만들어주지는 않는다.

결과에 내 이름을 붙이는 순간 설명과 검증의 책임도 함께 온다. 내가 온전히 이해하지 못한 결과물을 어떻게 보장할 수 있겠는가. 그래서 결과물을 먼저 만드는 학습에서 완성은 끝이 아니다.

완성본이 생긴 순간부터 공부가 시작된다.