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는 완성본을 만들어줄 수 있지만 그 결과를 이해하고 보장할 사람까지 만들어주지는 않습니다.

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

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