AI 이후의 교육, 그리고 인간의 자리 — 2부
이름을 모르고도 발견할 수 있다
AI 이후의 교육, 그리고 인간의 자리 — 2부
저는 고등학교 때부터 디자인을 공부했습니다. 디자인 계열 학교를 나왔고, 대학에 가서는 코딩에 푹 빠졌습니다. 하지만 프로그래밍을 체계적으로 교육받은 사람이라고 말하기는 어렵습니다. 대학 수업이 있기는 했지만, 대부분의 공부는 독학에 가까웠습니다.
제 학습 방식은 단순했습니다. 이해가 되지 않으면 끝까지 물고 늘어지는 것이었습니다.
처음 class라는 개념을 만났을 때도 그랬습니다. 레퍼런스 문서를 계속 읽고, 코드를 바꾸고, 다시 실행했습니다. 이해하지 못한 문장을 수없이 되짚었습니다. 누군가에게는 이미 기초 문법인 내용이 제게는 며칠씩 씨름해야 하는 문제였습니다.
그렇게 공부했고, 결국 개발을 직업으로 삼을 정도의 성과는 얻었습니다.
그런데 직장 생활을 하면서 재미있는 문제를 발견했습니다. 동료 개발자들과 이야기할 때, 제가 종종 알고 있는 개념의 이름을 몰랐던 것입니다.
개념은 있는데 이름이 없다
예를 들어 key-value 구조를 사용하면서도 그것이 Dictionary라는 이름으로 널리 불린다는 사실을 뒤늦게 접한 적이 있습니다. 객체의 내용을 저장하거나 전송하기 쉬운 형태로 바꾸고 다시 복원하는 작업을 하면서도 Serialization과 Deserialization이라는 용어에 익숙하지 않았습니다.
가장 설명하기 좋은 사례는 렌더링 최적화입니다.
개체가 많아지면 프로그램이 느려집니다. 직접 빌드해서 실행하고 성능을 관찰하다 보면 그 사실은 자연스럽게 알게 됩니다. 그렇다면 화면에 보이지도 않는 개체를 굳이 그릴 필요가 있을까요? 화면 밖에 있는 개체의 그리기를 생략해 보니 실제로 성능이 나아지는 경우가 있었습니다.
저는 문제를 관찰하고, 해결책을 떠올리고, 코드를 고치고, 결과를 확인했습니다. 그리고 나중에야 이런 접근이 Culling이라는 이름으로 체계화되어 있다는 사실을 알았습니다. 화면 밖 개체를 제외하는 방식은 그중에서도 시야 절두체를 활용하는 Frustum Culling과 연결됩니다.
물론 제가 그 분야의 모든 이론을 독립적으로 발견했다는 뜻은 아닙니다. 이미 존재하던 해결책의 일부를 제 문제에 맞춰 다시 찾아낸 것이죠.
여기서 흥미로웠던 것은 이름을 몰라도 문제를 해결할 수 있었고, 문제를 해결했다고 해서 곧바로 그 분야의 언어를 익힌 것은 아니었다는 점입니다.
지식을 배우는 순서가 반대였다
일반적인 교육에서는 이름과 정의를 먼저 배웁니다.
‘이런 구조를 Dictionary라고 한다.’
‘이러한 변환을 Serialization이라고 한다.’
‘화면에 그릴 필요가 없는 개체를 제외하는 기법을 Culling이라고 한다.’
이후에 적용 사례를 살펴보고 직접 구현합니다.
제 경우에는 그 순서가 달랐습니다. 문제가 생겼고, 해결 방법을 고민했고, 구현했습니다. 이름은 마지막에 도착했습니다.
이런 방식에는 장점과 단점이 모두 있습니다.
장점은 문제와 해결책 사이의 이유를 직접 경험한다는 것입니다. ‘왜 이런 기술이 필요한가’가 추상적인 설명이 아니라, 내가 겪은 느린 화면이나 작동하지 않는 코드에 연결됩니다.
단점은 굉장히 비효율적일 수 있다는 점입니다. 이미 수십 년 전에 정리된 해결책을 혼자 다시 찾아내느라 많은 시간을 소비할 수 있습니다. 더 좋은 방법이나 예외 상황을 놓치기도 쉽습니다. 그리고 저처럼 용어를 몰라 동료와 소통하거나 자료를 검색하는 데 어려움을 겪을 수도 있습니다.
저는 여기에서 AI 교육의 가능성을 봅니다.
AI가 있었다면 무엇이 달라졌을까
당시에 AI가 있었다면, 제가 화면 밖 개체의 그리기를 생략하는 방법을 떠올린 순간 이렇게 질문할 수도 있었을 것입니다.
“화면 밖 물체를 안 그리니까 빨라지는데, 보통 이런 걸 어떻게 처리하나요?”
AI는 그 방법에 이름이 있다는 사실을 알려주고, 비슷하지만 다른 최적화 기법을 소개해 주었을 것입니다. Frustum Culling과 Occlusion Culling이 어떻게 다른지, LOD는 무엇을 줄이는지, 어떤 상황에서는 GPU보다 CPU나 드로우 콜이 병목이 되는지까지 이야기를 확장할 수 있었겠죠.
제가 직접 발견한 현상에 인류가 축적해 온 지식을 연결해 주는 것입니다.
발견의 계기는 개인의 경험에서 나오고, 그 발견을 분류하고 확장하는 언어는 AI가 제공할 수 있습니다.
이 차이는 생각보다 큽니다. 독학의 장점인 집요한 탐구를 유지하면서도, 독학의 약점인 지식의 고립을 완화할 수 있기 때문입니다.
물론 AI가 처음부터 정답을 알려주면 학생이 스스로 탐색할 기회를 잃을 수도 있습니다. 그래서 중요한 것은 ‘얼마나 빨리 답을 주느냐’만이 아닐 것입니다. 학생이 어디까지 생각해 보았는지 확인하고, 필요한 순간에 기존의 지식과 연결해 주는 방식이 더 적합할 때도 있을 것입니다.
미래의 아이는 자신의 전공을 모를지도 모른다
이야기를 조금 확장해 보겠습니다.
어떤 아이가 게임을 만들고 싶어 한다고 가정해 봅시다. 캐릭터의 이동을 구현하면서 물리학을 접하고, 공격이 명중할 확률을 정하면서 수학을 배우고, 아이템 가격을 조절하면서 경제적 균형을 고민합니다. 다른 사람이 게임을 어떻게 받아들이는지 관찰하다 보면 심리학과 디자인의 문제도 만납니다.
하지만 이 아이에게 무엇을 공부했느냐고 물으면 이렇게 대답할지도 모릅니다.
“그냥 게임을 만들었는데요?”
그 말이 틀린 것은 아닙니다. 아이는 게임을 만들고 있었습니다. 다만 그 과정에서 여러 학문의 개념을 사용했을 뿐입니다.
여기에는 앞선 글에서 이야기한 ‘왜?’의 연쇄가 있습니다. 아이의 관심사는 하나인데, 해결해야 할 문제는 학문의 경계를 따라 움직이지 않습니다.
그렇다면 AI와 함께 자라는 아이들은 어떤 분야의 전문가가 되겠다고 결정하기 전에, 여러 분야의 사고방식부터 경험할 수도 있습니다. 인물의 이름과 개념의 이름은 알지만 그 개념이 어느 학과 소속인지는 모르는, 조금 낯선 학습자들이 등장할 가능성입니다.
다만 여러 개념을 접했다고 해서 곧바로 여러 분야의 전문가가 되는 것은 아닙니다. 개념을 한 번 적용하는 일과 그 개념의 원리·한계·예외를 깊게 이해하는 일은 다릅니다. 넓은 연결은 깊은 공부를 대신하는 것이 아니라, 깊이 공부할 이유와 방향을 제공하는 편에 가깝습니다.
디자인과 코딩을 함께 배웠다는 것
돌이켜 보면 저 역시 분야를 섞어 사용하며 이점을 얻었습니다. 디자인을 공부하다 개발자가 되었고, 두 영역을 함께 다룰 수 있다는 사실이 실무에서 도움이 되었습니다.
그 경험은 단순히 디자인 도구와 프로그래밍 언어를 둘 다 쓸 수 있었다는 뜻만은 아닙니다. 화면의 흐름을 구현의 관점에서 바라보거나, 기능의 구조를 사용자 경험의 관점에서 바라보는 일이 자연스러워졌다는 의미이기도 합니다.
AI와 함께 배우는 세대는 이런 경로를 훨씬 더 다양한 분야에서 경험할지도 모릅니다. 다만 그들의 능력이 어떻게 나타날지는 아직 알 수 없습니다. 가능성과 성취를 구분해서 보아야 합니다.
그럼에도 제가 기대하는 지점은 분명합니다.
기존 교육이 학문별로 나누어 놓은 지식을 배우는 데서 출발했다면, 새로운 학습은 개인의 문제를 해결하는 과정에서 학문의 이름을 뒤늦게 발견할 수 있습니다.
제게는 그 과정이 많은 시행착오와 시간의 대가를 요구했습니다. 미래의 아이들은 AI 덕분에 그 시행착오의 일부를 줄일 수 있을 것입니다.
하지만 여기서 새로운 문제가 나타납니다.
스스로 코드를 작성한 사람과 AI가 작성한 코드를 충분히 이해한 사람이 있다면, 우리는 둘 중 누구를 더 잘 배운 사람이라고 평가해야 할까요?
이전 글: 1부 — 왜?를 50번 물어볼 수 있는 아이들
다음 글: 3부 — AI가 과제를 대신한다면, 무엇을 평가해야 하는가?