시리즈 · 404호 개발실
21회 · 404호 개발실 21 - 백화점
컷별 상황
의도 404호 개발실 21 백화점은 구글 백화점에서 지식을 헤매던 꼬북이 앞에 AI 코디네이터가 등장하는 4컷 웹툰입니다.
시리즈 · AI 시대의 학습
2회 · AI 시대의 학습 2 - 황금사과를 먹는 사람과 감상하는 사람
그렇다면 AI 시대에는 이 공부 방법이 여전히 통용되는 것일까요?
1부에서 공부의 과정은 필요성 인지 → 지식 습득 → 체득 → 응용이라고 정리했습니다. 이 원칙은 AI 시대에도 변하지 않는다고 생각합니다. 다만 AI로 인해 학습 과정은 두 가지 형태로 압축될 수 있습니다.
사실 이 현상은 이미 벌어지고 있습니다. 많은 사람이 자신도 모르게 두 번째 형태를 따라가고 있습니다. 답변을 받는 순간 공부가 끝났다고 생각하고, 코드를 실행해 보기도 전에 다음 질문으로 넘어갑니다. 필자는 이런 사용 방식이 사람을 도태시킨다고 생각합니다. 모든 사람은 첫 번째 방식을 택해야 하며, 교육 과정 역시 답을 전달하는 데서 멈추지 않고 원천 탐구·체득·응용으로 이어지는 방향을 취해야 합니다.
이 글에서 말하는 AI 시대 학습법은 AI 활용 학습을 통해 개발자 성장을 돕되, AI 학습법을 답변 복사로 끝내지 않고 지식 응용까지 이어 가는 방식입니다.
AI가 지식 습득을 빠르게 만든 것은 사실입니다. 하지만 속도가 빨라졌다는 말이 공부의 목적이 사라졌다는 뜻은 아닙니다. 오히려 질문은 더 단순해집니다.
그렇다면 AI 시대에는 이 공부 방법이 여전히 통용되는 것일까?
이 질문에 대한 필자의 답은 “그렇다. 다만 지식 습득의 입구가 달라졌다”입니다. 과거에는 필요한 지식에 도착하는 것 자체가 어려웠고, 이제는 도착한 지식을 정말 자기 것으로 만드는 일이 더 중요해졌습니다. 이 차이를 이해하기 위해 개발자의 학습을 하나의 백화점 이야기로 바꿔 보겠습니다.
과거의 지식 습득은 구글이라는 거대한 백화점에 들어가는 일과 비슷했습니다. 개발자는 멋진 신사로 변신하고 싶었습니다. 하지만 신사가 어떤 옷을 입어야 하는지, 옷의 카테고리가 무엇인지조차 정확히 몰랐습니다.
마음속에 떠오른 최종 이미지는 이랬습니다.
파란색 중절모, 금태안경, 모자와 완전히 같은 색의 파란 정장, 앞이 뾰족하고 광이 나는 검은 구두, 금색 커프스, 흰 와이셔츠, 작고 검은 나비넥타이, 윤기 나는 짙은 갈색 고목나무 지팡이.
문제는 ‘커프스’라는 단어를 모른다는 데 있었습니다. 중절모와 베레모의 차이도 몰랐고, 정장과 재킷을 어떤 검색어로 구분해야 하는지도 몰랐습니다. 개발자는 백화점의 1층부터 끝까지 돌아다니며 검색창에 아는 단어를 하나씩 넣었습니다.
하루 종일 찾아 헤맨 끝에 손에 넣은 결과는 이랬습니다.
검은 베레모, 안경은 못 찾음, 짙은 파란 정장, 검은 청바지, 흰색 반팔 티셔츠, 시계.
어떻게 보면 옷을 입기는 했습니다. 그러나 원하던 신사와는 거리가 멀었습니다. 이 결과를 개발자의 언어로 번역하면 더 선명합니다. 코드는 컴파일되지만 요구사항과 설계가 맞지 않아 언제나 오류가 납니다. 검색 결과에서 조각을 주워 붙였을 뿐, 무엇이 빠졌는지조차 설명할 수 없습니다.
구글이 나빴다는 뜻은 아닙니다. 백화점에는 상품이 많았지만, 손님이 원하는 상품의 이름과 진열 위치를 알아야 했습니다. 개발자가 필요한 지식의 이름을 모르는 순간 검색은 지식의 안내자가 아니라 거대한 진열장이 됩니다.
이제 같은 개발자가 AI 시대에 백화점을 찾았다고 생각해 봅시다. 이번에는 백화점 입구에 전문 코디네이터가 서 있습니다.
개발자가 조심스럽게 말합니다.
AI는 백화점 안에 있는 모든 옷 중에서 가장 유사하게 코디할 수 있는 상품을 찾아옵니다. 파란색 중절모, 금태안경, 파란 정장, 흰 와이셔츠, 검은 나비넥타이, 금색 커프스, 뾰족하고 광이 나는 검은 구두, 짙은 갈색 지팡이가 차례로 놓입니다. 개발자는 처음부터 완벽하게 원했던 조합은 아니었지만, 적어도 이제 자신이 무엇을 입었는지 설명할 수 있습니다. 그는 꽤 마음에 들어 하며 백화점을 나섭니다.
이 장면에서 AI가 한 일은 옷을 무작정 대신 사 준 것이 아닙니다. 개발자가 몰랐던 카테고리와 단어를 먼저 찾아 주고, 흩어진 상품을 하나의 의도에 맞게 연결해 준 것입니다. 개발 문제로 치면 “로그인이 안 돼요”라는 막연한 문장을 세션, JWT, 쿠키, CORS, CSRF, OAuth, 프록시, 만료 정책이라는 탐색 가능한 지도으로 바꾼 일입니다.
이 질문은 정답을 대신 내는 것이 아니라 개발자가 몰랐던 카테고리를 만들어 줍니다. 카테고리가 생기면 공식 문서를 찾을 수 있고, 문서에서 계약을 읽을 수 있고, 작은 실험으로 옷이 실제로 맞는지 확인할 수 있습니다. AI의 첫 번째 가치는 답변 문장보다 질문자가 몰랐던 단어를 발견하게 하는 데 있습니다.
이제 우리는 두 가지 선택지 앞에 서 있습니다.
첫 번째 개발자는 AI에게 집요하게 묻습니다.
이 코디를 제안한 이유를 모두 알려 주세요. 상품 종류, 스타일, 선택한 이유, 제품 특징, 가격까지 설명해 주세요.
AI는 각 옷의 이름과 역할을 설명하고, 어떤 조합이 서로 어울리는지, 어떤 상황에서는 바꿔야 하는지, 가격과 품질의 차이는 무엇인지 알려 줍니다. 물론 AI의 답변이 언제나 100% 정확한 것은 아닙니다. 하지만 개발자가 그 답변의 97% 근처까지 따라가며 원문을 확인하고 직접 입어 본다면, 이전보다 훨씬 빠르게 높은 수준에 도달할 수 있습니다. 이것이 AI를 이용해 원천을 깊숙이 탐구하는 초전문가의 방식입니다.
두 번째 개발자는 코디가 마음에 들었다는 말만 남기고 집으로 돌아갑니다. 텔레비전을 보다가 며칠 뒤 다시 백화점에 와서 말합니다.
이번에는 캐주얼 스타일로 추천해 주세요.
그는 오늘의 옷을 얻었지만, 왜 어울렸는지 알지 못합니다. 계절이 바뀌거나 장소가 달라지면 다시 코디네이터를 찾아야 합니다. 개발에서 AI가 만들어 준 코드를 복사해 실행만 하고 체득과 응용을 하지 않는 것도 똑같습니다. 잠깐은 빠르지만 버전이 바뀌거나 요구사항이 달라지면 다시 처음 질문으로 돌아갑니다.
기술적으로 보면 첫 번째 개발자는 AI에게 다음을 요청합니다.
이 루프가 지식 습득을 체득과 응용으로 연결합니다. 질문을 한 번 던지고 결과를 받는 것이 아니라, 결과를 다시 질문하고 실행하고 설명하는 과정입니다.
이 문제는 개인의 의지에만 맡길 일이 아닙니다. 교육 과정도 AI가 내놓은 답을 받아 적게 하는 방식에서 벗어나야 합니다. 필요성 인지에서 출발해 AI로 원천을 탐구하고, 손으로 체득하고, 다른 문제에 응용하도록 설계해야 합니다.
Microsoft Research의 2025년 지식 노동자 설문은 생성형 AI 사용에서 인지적 노력이 줄었다고 느끼는 상황과 비판적 검토의 관계를 조사했습니다. 이 연구는 AI가 사람의 사고력을 반드시 떨어뜨린다고 증명한 것이 아니라 자기보고 설문이라는 한계를 가집니다. 다만 AI를 사용할수록 검증을 덜 할 수 있다는 위험 신호를 보여 주므로, 학습자는 결과 검증을 의도적으로 설계해야 합니다. 학습 전략의 근거를 더 확인하려면 Dunlosky 연구진의 학습기법 검토와 retrieval practice 연구도 함께 읽을 만합니다.
테슬라의 머스크는 AI의 시대에 인류는 "AI 보다 뛰어난 사람이 되거나 스스로 AI 가 되거나" 라고 이야기 했습니다. 필자는 머스크의 생각이 맞다고 생각합니다. AI는 각종 지표에서 지구에서 가장 뛰어난 인간의 97% 를 달성했다고 합니다. 이는 일부 착시입니다. 지구에서 가장 뛰어난 각 분야의 전문가들의 모든 부분의 97%를 달성했다고 생각해야 합니다. 우리는 AI를 이용해 97%의 인간이 되어야 합니다. 아니면 머스크의 뉴럴링크 안테나를 머리에 박아버리게 되겠죠?
우리는 지금 손에 황금사과를 들고 있습니다. 이 사과를 먹을 것인지, 아니면 거실에 놔두고 계속 바라만 볼 것인지 선택해야 합니다. 명심해야 합니다. 황금사과도 썩습니다. 이 황급사과의 지식을 하루빨리 먹을지 예쁘다고 구경만 할지는 여러분에게 달려있습니다.
오늘 생성된 예제는 라이브러리 버전이 바뀌면 낡고, AI의 답변은 맥락이 사라지면 틀릴 수 있습니다. 그러나 AI가 내놓지 못하는 답변은 이제 인간도 내놓기 쉽지 않습니다. AI 시대에도 공부의 원칙은 변하지 않습니다. 그렇기에 이제 AI를 이용해 필요성을 인지하고, 지식을 습득하고, 체득하고, 응용해야 합니다. 달라진 것은 지식의 문 앞에 AI 코디네이터가 새로 생겼다는 사실 하나입니다.
시리즈 · AI 시대의 학습
1회 · AI 시대의 학습 1 - 지식은 어떻게 내 것이 되는가
필자는 개발자라는 직군은 평생을 공부해야 하는 운명을 가졌다고 생각합니다. 아니, 모든 사람들 특히 전문직군은 자신의 전문성의 신선함을 유지하기 위해 끊임없이 공부해야 합니다. 여기서 고민이 생깁니다. 공부란 무엇일까요? 나이가 먹어 갈수록 질문은 점점 단순해지는 듯합니다. 이런 질문에는 정답이 없으니, 이 글은 필자의 개인적인 생각으로 읽어 주시면 좋겠습니다. “그렇게도 생각할 수 있겠구나” 하는 정도로 편하게 봐 주셔도 충분합니다.
공부란 필요성 인지 → 지식 습득 → 체득 → 응용의 과정이다.
이 네 단계는 따로 떨어진 목록이 아니라 하나의 학습 사이클입니다. 먼저 왜 필요한지 알아야 공부가 시작되고, 지식을 얻은 다음에는 직접 해 보며 체득해야 합니다. 체득한 원리는 다른 문제와 플랫폼에 응용할 수 있습니다. 이 사이클이 반복되면 자주 다루는 언어와 기술에 주종목이 생기고, 주종목의 원리를 다른 언어와 플랫폼으로 옮기는 과정에서 풀스택 역량이 만들어집니다. 1부는 이 흐름을 차례대로 따라가고, 2부는 AI가 그 흐름의 어디를 압축하는지 살펴봅니다.
이 과정을 필자는 지식 체득이라고 부릅니다. 읽고 들은 내용을 직접 다시 만들고, 실패 원인을 설명할 수 있을 때 비로소 지식 체득이 일어납니다.
여기서 말하는 개발자 학습법은 자료를 많이 소비하는 요령이 아닙니다. 필요한 지식을 골라 자기 것으로 만들고, 다시 써먹을 수 있는 소화력으로 바꾸는 절차입니다.
공부의 첫 단계는 책을 펴는 행위가 아닙니다. “이걸 알아야 내 문제가 풀린다”는 필요성을 알아차리는 순간입니다. 필요성이 없으면 강의 목록을 저장하고 책을 사도 실제 학습은 시작되지 않습니다.
개발자는 문제를 만나면서 공부를 시작합니다. 서버가 배포되지 않거나, 데이터 모델이 꼬이거나, 화면과 API의 계약이 어긋날 때 비로소 어떤 지식이 필요한지 질문이 선명해집니다. 좋은 학습은 막연한 호기심을 없애는 것이 아니라, 해결해야 할 문제를 더 정확한 질문으로 바꾸는 데서 출발합니다. 공부의 갈증은 다양하겠지만 갈증없이는 한모금의 물도 마실수 없습니다.
필요성 인지는 학습의 방향뿐 아니라 깊이도 정합니다. “웹을 공부한다”는 너무 넓지만, “이번 주에는 인증 토큰의 생성·검증·만료를 직접 구현한다”는 실행 가능한 목표입니다. AI에게 질문할 때도 이 문장이 있으면 답변을 모으는 대신 학습 단위를 설계할 수 있습니다.
책을 읽거나, 공식 문서를 확인하거나, 강의와 동영상을 보는 것은 모두 지식 습득의 과정입니다. 다만 화면을 재생한 시간과 지식이 내 머릿속에 남은 시간은 같지 않습니다. 흘러들어온 지식은 흘러나가기 쉽습니다.
특히 개발자는 직접 찾아 읽는 과정을 건너뛰면 나중에 문제를 재현하지 못합니다. 검색 결과의 요약이나 영상의 설명은 출발점이지 계약서가 아닙니다. API 문서의 입력·출력 조건, 예외, 버전, 권한을 원문에서 확인해야 “왜 이 코드가 동작하는지”를 설명할 수 있습니다.
Dunlosky 연구진의 학습기법 검토는 연습 테스트와 분산 학습처럼 스스로 꺼내 보는 방식이 단순 재독보다 유용할 수 있다고 정리합니다. Karpicke와 Roediger의 retrieval practice 연구도 기억에서 답을 꺼내는 행위 자체가 장기 학습에 중요한 역할을 한다고 보고했습니다. 개발자식으로 번역하면 문서를 읽은 직후 탭을 닫고, 방금 본 API를 보지 않고 설명하거나 작은 코드를 다시 작성해 보는 일입니다.
지식을 습득했다면 반드시 체득 단계로 넘어가야 합니다. 체득은 “알고 있다”가 아니라 “처음부터 다시 만들 수 있고, 실패 원인을 좁힐 수 있다”는 상태입니다. 개발자에게 가장 좋은 체득 도구는 거대한 사이드 프로젝트가 아니라 작고 끝나는 미니 프로젝트입니다.
예를 들어 인증을 공부한다면 다음 정도면 충분합니다.
이 과정에서 화면은 단순해도 됩니다. 중요한 것은 서버를 직접 띄우고, 데이터 모델을 만들고, 요청을 보내고, 로그와 실패 응답을 읽는 것입니다. 코드를 복사해 실행만 했다면 아직 체득한 것이 아니라 관찰만 한 것입니다.
응용은 기존 코드를 다른 곳에 붙여 넣는 일이 아닙니다. 한 문제에서 얻은 원리를 새로운 제약에 맞게 다시 설계하는 일입니다. HTML로 웹 화면을 만들던 개발자가 모바일 앱을 추가하면서 Flutter를 접할 때, 단순히 문법을 새로 외우는 것이 아니라 상태·이벤트·네트워크·배포라는 구조를 새 플랫폼의 문법으로 옮기게 됩니다. 당연히 연관된 백엔드의 새로 생겨난 예외사항들이 끊임없이 괴롭힐 것입니다. 이 과정이 응용력이 확장되는 과정입니다.
체득이 있으면 플랫폼이 바뀌어도 질문이 달라집니다. “버튼을 어떻게 그리지?”에서 “상태가 어디에 있고, 이벤트가 어떤 경계를 넘어가며, 실패를 어떻게 복구하지?”로 관심이 이동합니다. 반대로 체득 없이 응용을 시도하면 프레임워크의 기본 예제를 조합하는 수준에서 멈추고, 작은 요구사항 변화에도 전체를 다시 검색하게 됩니다.
필자가 말한 필요성 인지 → 지식 습득 → 체득 → 응용의 사이클은 한 번 돌고 끝나지 않습니다. 개발자는 여러 프로젝트에서 이 과정을 반복하면서 자주 호출하는 언어와 기술을 발견합니다. 어떤 사람은 Java와 데이터 모델·쿼리 최적화에 강해지고, 어떤 사람은 JavaScript·TypeScript와 UI 상태·접근성에 강해지며, 또 다른 사람은 C++와 메시지 큐·분산 시스템을 주종목으로 삼습니다. 주종목은 처음부터 정하는 직함이 아니라 반복해서 해결한 문제의 흔적입니다.
언어는 단순한 문법 목록이 아닙니다. 하나의 언어를 오래 다루면 그 언어의 모듈링 방식, 예외 처리, 동시성, 스트림, 테스트 습관, 생태계의 설계 관례가 몸에 밴다는 뜻입니다. 반복된 체득이 쌓이면 “문법을 안다”를 넘어 “이 언어로 이 문제를 어떻게 설계하는지를 안다”는 수준에 도달합니다. 이것이 주종목의 실력입니다.
여기서 중요한 점은 주종목과 시야를 맞바꾸지 않는 것입니다. 한 분야를 깊게 파되, 다른 분야의 언어와 실행 환경을 조금씩 만져야 설계의 선택지를 비교할 수 있습니다. 미니 프로젝트를 여러 번 끝낸 사람은 “이 기능을 어디에 넣을까”뿐 아니라 “이 기능을 이 경계에 넣는 것이 맞나”를 묻게 됩니다.
주종목이 생겼다고 해서 다른 분야를 닫아 버리는 것은 아닙니다. 다양한 프로젝트를 반복하면 개인적인 지식의 양이 늘고, 분야를 가리지 않고 조금씩 찍먹한 체득이 생깁니다. 이때 한 언어와 주종목의 모듈링·아키텍처링은 극도로 발전하고, 디자인 패턴·아키텍처·스레딩·스트림 같은 핵심 코어 이해력이 설계에 자유롭게 응용됩니다.
핵심은 설계가 언어에 묶이지 않는 순간입니다. 아키텍처와 설계가 특정 언어의 문법에서 벗어나면, 다른 언어의 간단한 문법을 이용해 비슷한 패턴을 구현할 수 있습니다. HTML로 웹사이트를 만들던 개발자가 Flutter로 앱을 추가할 때도 마찬가지입니다. 문법은 갈아 끼우지만 상태, 이벤트, 데이터 경계, 오류 처리라는 설계의 뼈대는 옮겨 갑니다.
같은 설계가 언어별로 어떻게 대응되는지 확인해 보겠습니다. 예시는 소셜 로그인 provider입니다. SocialSession은 로그인 결과의 공통 계약이고, SocialContract<T>는 특정 provider가 반환할 세션 타입을 제한합니다. AuthProviderFactory<T>는 공통 로그인 흐름을 감싸고, Google 구현은 GoogleSession만 반환하도록 컴파일 단계에서 보장합니다.
Java에서는 T extends SocialSession과 인터페이스 구현으로 이 관계를 표현합니다.
TypeScript에서는 extends 제약과 구조적 타입을 사용합니다. 런타임에는 제네릭이 사라지지만, 컴파일할 때 Google provider가 GoogleSession을 반환하는지 검사합니다.
C#에서는 where T : ISocialSession 제약으로 같은 설계를 표현합니다.
세 언어의 문법은 다르지만 구조는 같습니다. 세션 계약, 제네릭 provider 계약, 공통 factory, Google 구현이라는 설계가 그대로 이동합니다. 이것이 주종목의 경험이 다른 언어로 전이되는 실제 모습입니다.
이 경험이 쌓이면 새로운 프레임워크, 언어, 컴파일 시스템을 접해도 완전히 낯선 세계처럼 느끼지 않게 됩니다. 처음부터 모든 것을 아는 것이 아니라, 이미 체득한 설계 원리를 새로운 환경에 번역할 수 있기 때문입니다.
국내에서 풀스택은 보통 프론트엔드와 백엔드를 함께 개발한다는 뜻으로 쓰입니다. 그 정의는 실무적으로 유용하지만, 더 무거운 의미의 풀스택은 언어 목록이 아니라 낯선 기술을 빠르게 응용 레벨까지 끌어올리는 전이 능력에 가깝습니다. 사실 풀스택 개발자라고 모든 기술을 모두 꿰다시피 외우는건 불가능 합니다.
필자는 풀스택 개발자를 “세상의 모든 기술을 아는 사람”이 아니라, 새로운 기술을 2주 안팎의 집중 실험으로 업무에 연결할 수 있는 숙련자라고 봅니다. 이 말은 모든 기술을 2주 만에 마스터한다는 뜻이 아닙니다. 공식 문서에서 핵심 계약을 찾고, 작은 실행 환경을 만들고, 실패를 기록하고, 기존 설계와 비교해 사용할 수 있다는 뜻입니다.
이런 수준은 단기간의 요령으로 생기지 않습니다. 필자는 빠르면 5년, 꾸준하지만 느린 속도로 가도 15년 정도면 비슷한 전이 능력에 도달할 수 있다고 믿습니다. 중요한 것은 연차를 채우는 일이 아니라, 그 시간 동안 필요성 인지부터 응용까지의 사이클을 실제 프로젝트에서 몇 번이나 제대로 반복했는가입니다.
이 전이 능력은 다음 회차에서 더 중요해집니다. AI는 지식 습득의 속도를 크게 높이지만, 체득과 응용까지 자동으로 대신해 주지는 않기 때문입니다.
개발자의 학습은 필요성 인지에서 시작해 지식 습득, 체득, 응용으로 이어집니다. 문서를 읽고 영상을 보는 것은 필요한 과정이지만, 작은 서버·화면·데이터 모델·테스트를 직접 끝내야 지식이 개인의 도구가 됩니다. 반복된 체득이 주종목을 만들고, 주종목의 원리를 다른 언어와 플랫폼으로 옮길 수 있을 때 풀스택 전이 능력이 생깁니다.
다음 2부에서는 이 구조가 AI 시대에 어떻게 압축되는지, AI를 답안 자동판매기가 아니라 원천 지식을 파고드는 학습 파트너로 쓰려면 어떤 질문과 검증 루프가 필요한지 살펴보겠습니다.
중국발 AI 모델을 둘러싼 증류 논란은 “작은 모델이 큰 모델처럼 답한다”는 현상을 어떻게 만들어 내는지 묻는 데서 시작한다. 증류는 원래 합법적인 모델 압축·전이 기법이지만, 교사 모델의 출력물을 대량으로 수집해 학생 모델을 만들면 API 약관과 데이터 권리 문제가 겹친다. 앞서 다룬 Kimi K3 증류 논란이 행위의 경계를 물었다면, 기존 AI 모델 증류 논의는 공개 모델 파생 사례를 보여 준다. 이번 글은 AI 증류기법이 실제 파이프라인에서 어떤 데이터와 코드로 구현되는지 살펴본다.
아래 API 수집 예시는 교사 모델 제공자의 허가, 계약, 개인정보 처리 근거가 있다는 전제의 연구용 예시다. 계정 우회, 비정상 자동화, 속도 제한 회피, 비공개 출력 탈취를 다루지 않는다. 합법적인 오픈 모델·자체 모델·허가된 API에서만 실행해야 한다.
Hinton, Vinyals, Dean이 2015년에 정리한 지식 증류(knowledge distillation)는 큰 교사(teacher) 네트워크의 지식을 작은 학생(student) 네트워크로 옮기는 방법이다. 교사는 정답 하나만 내놓는 것이 아니라 각 선택지에 대한 확률 분포, 즉 ‘soft target’을 제공한다. 학생은 정답 라벨과 교사의 분포를 함께 맞추며 일반화에 필요한 관계까지 배운다. 원 논문은 이 관점을 모델 압축의 출발점으로 만들었다.
LLM 증류에는 크게 두 경로가 있다. 모델의 가중치와 logits를 볼 수 있는 white-box 증류는 중간 표현·logits·attention을 직접 맞춘다. API만 쓸 수 있는 black-box 증류는 질문을 만들고 교사의 답변·선호·코드·추론 흔적을 저장해 학생을 지도한다. 2024년 LLM 증류 서베이는 이 둘을 구분하면서 API 기반 in-context, chain-of-thought, instruction-following 증류를 별도 범주로 정리한다.
| 구분 | 교사에서 보이는 신호 | 학생 학습 목표 | 장점 | 한계 |
|---|---|---|---|---|
| logits 증류 | 토큰별 logits·확률 | 온도 조절 KL divergence | 정보량이 많고 안정적 | 교사 가중치·logits 접근 필요 |
| feature 증류 | 중간층 표현·attention | 표현 정렬·feature loss | 내부 표현까지 전달 | 구조가 다른 모델에는 적용 어려움 |
| 응답 증류 | 텍스트 답변·선호·코드 | SFT·DPO·선호 최적화 | API만으로도 가능 | 교사의 오류·말투·편향을 함께 복제 |
| 추론 경로 증류 | 단계별 풀이·검증 결과 | reasoning SFT 또는 RL | 작은 모델의 문제 해결력 향상 | 경로가 진짜 사고를 그대로 뜻하지 않음 |
기본 손실은 다음처럼 쓸 수 있다. T는 temperature다. 온도를 높이면 교사의 확률 분포가 부드러워져 “정답 외에 어떤 오답을 덜 나쁘게 보는가”까지 학생이 읽을 수 있다.
API 증류에서는 logits 대신 답변을 학습한다. 이때 “증류 데이터가 많을수록 좋다”는 말은 틀렸다. 교사의 환각, 잘못된 계산, 거절 정책, 장황한 말투까지 복제할 수 있기 때문이다. 데이터의 출처, 검증 상태, 난이도, 중복, 개인정보를 관리하는 것이 모델 크기보다 먼저다.
증류 데이터 수집은 교사에게 질문을 던지고 답을 파일에 쌓는 일이 아니다. 나중에 같은 결과를 재현하고 삭제·감사를 수행할 수 있도록 요청과 응답의 계보(provenance)를 함께 저장해야 한다.
교사 모델의 서비스 약관이 학습 재사용을 허용하는지 먼저 확인한다. 사용자 입력을 재사용한다면 개인정보 제거·동의·보존기간도 별도 정책으로 정해야 한다. 같은 질문을 반복하면 비용은 늘고 데이터 다양성은 줄어든다. prompt의 언어·길이·분야·난이도를 균형 있게 샘플링하는 편이 낫다.
다음은 OpenAI 호환 API를 가정한 예시다. API 키는 환경변수로만 읽고, 요청 간 간격·재시도·원문 해시·메타데이터를 기록한다. 실제 엔드포인트와 응답 필드는 제공자 문서에 맞춰 바꿔야 한다.
이 코드는 대량 수집을 위한 우회기가 아니다. 실제 운영에서는 제공자의 공식 Batch API, 요청 한도, 데이터 보존 설정, 비용 상한을 사용해야 한다. 응답 원문이 민감할 수 있으므로 접근권한을 제한하고, 모델 학습이 끝난 뒤 원본을 보관할지 삭제할지 결정한다.
원시 JSONL은 곧바로 파인튜닝 데이터가 되지 않는다. 먼저 빈 답변·중복·너무 긴 샘플·개인정보·정답이 없는 샘플을 걸러낸다. 분야별 검증기(수식 실행, 코드 테스트, 분류 라벨 일치)를 통과한 샘플만 verified로 표시하고, 학습·검증·테스트 세트를 질문 ID 기준으로 분리한다.
여기서 중요한 것은 학생에게 교사의 모든 말투를 복사시키는 것이 아니라 목표 능력을 정의하는 일이다. 코드 모델이면 실행 가능한 테스트를 붙이고, 수학이면 정답 검산기를 붙이며, 고객지원이면 정책 문서와 거절 기준을 함께 넣는다. 교사 답변만 남기고 질문·검증 결과·라이선스 정보를 버리면 나중에 모델의 출처를 설명할 수 없다.
기초 모델은 “가장 큰 모델”보다 목표와 라이선스에 맞춰 고른다. 학생 모델의 토크나이저가 데이터의 언어와 코드 문법을 잘 표현하는지, 상업 이용·파생 모델·증류 허용 조건이 무엇인지, 컨텍스트 길이와 GPU 메모리가 충분한지 확인한다. 데이터와 모델 라이선스가 충돌하면 훈련이 성공해도 배포할 수 없다.
Hugging Face Transformers는 모델별 chat template을 제공한다. 역할 토큰을 임의로 붙이지 말고 apply_chat_template로 포맷해야 한다. Transformers 문서는 모델마다 [INST], <|user|> 같은 제어 토큰이 다르며 중복 special token이 성능을 해칠 수 있다고 설명한다. TRL SFTTrainer 문서는 dataset_text_field, max_length 등 학습 데이터 전처리 파라미터를 정의한다.
참고로 수집데이터로 학습을 수행시켜서 실제 가중치(weight)의 미세조정이 일어나는 곳이 trainer.train() 이 부분이다. 실제 학습에서는 전체 가중치를 갱신하는 대신 LoRA/PEFT로 시작하면 GPU 메모리와 실험 비용을 줄일 수 있다. 다만 LoRA 어댑터를 합쳐 배포할 때의 라이선스와 병합 절차를 별도로 확인해야 한다. 훈련 손실이 내려간다고 증류가 성공한 것은 아니다. 보지 못한 질문, 교사와 다른 표현, 안전 거절, 긴 문맥, 코드 실행 평가를 함께 비교해야 한다.
DA-KD: Difficulty-Aware Knowledge Distillation for Efficient Large Language Models는 ICML 2025 논문이다. 기존 방식이 샘플 난이도 차이를 무시해 쉬운 문제에도 같은 증류 비용을 쓰는 점을 지적하고, 난이도에 따라 증류 데이터셋을 동적으로 조정한다. 핵심 교훈은 데이터 수를 무작정 늘리는 것이 아니라 학생이 아직 못 푸는 샘플에 교사 예산을 집중해야 한다는 것이다.
Distilling the Implicit Multi-Branch Structure in LLMs’ Reasoning via Reinforcement Learning은 2025년 공개된 RLKD 연구다. 논문은 교사의 한 줄짜리 reasoning trace를 SFT로 따라 쓰게 하면 실제 문제 선택과 해결의 다중 분기 구조가 평평한 토큰 모방으로 붕괴할 수 있다고 본다. 그래서 Generative Structure Reward Model로 학생과 교사의 구조 정렬을 평가하고 RL로 최적화한다. 논문 결과는 연구진의 실험 설정 안에서 해석해야 하며, “RL 증류가 언제나 SFT보다 낫다”는 일반 법칙은 아니다.
두 연구는 서로 다른 병목을 짚는다. DA-KD는 어떤 데이터를 얼마만큼 호출할지의 비용 문제를, RLKD는 답변을 복사하는 것과 문제 해결 구조를 배우는 것의 차이를 다룬다. 기업이 증류 파이프라인을 만들 때도 데이터 선택과 학습 목표를 따로 설계해야 한다.
API 증류 비용은 요청 수만으로 계산하지 않는다. 입력 토큰, 출력 토큰, 캐시·배치 할인, 재시도, 검증용 교사 호출, 실패 요청까지 합산해야 한다.
스크린샷의 계산은 “샘플당 입력 500토큰·출력 1,000토큰”을 가정한다. 따라서 20만 건이면 입력 1억 토큰과 출력 2억 토큰이다. 이때 표에 사용한 Luna 예시 단가(입력 $1·출력 $6)를 적용하면 정가 API는 100×$1 + 200×$6 = $1,300(약 182만 원), Batch는 $650(약 91만 원)이다. 운영 여유를 3050% 더하면 Batch 기준 약 $845$975(약 118만~137만 원)으로 잡는다. 화면에 적힌 $220은 출력 토큰을 2천만 개로 잘못 넣은 계산이므로, 20만 건·출력 1,000토큰 가정에서는 $1,300이 맞다.
실제 가격은 모델·시점·제공자에 따라 달라진다. 2026년 7월 31일 공식 문서를 기준으로 같은 20만 건을 다시 계산하면 다음과 같다. 환산은 계산 편의를 위해 1달러=1,400원을 적용한 근사치이며, 환율·부가세·계정 할인은 반영하지 않았다.
| 모델·단가(입력/출력, 100만 토큰) | 일반 API | Batch(50%) |
|---|---|---|
| OpenAI GPT-5.6 Sol $5/$30 | $6,500(약 910만 원) | $3,250(약 455만 원) |
| OpenAI GPT-5.6 Terra $2/$12 | $2,600(약 364만 원) | $1,300(약 182만 원) |
| Gemini 3.5 Flash $1.50/$9 | $1,950(약 273만 원) | $975(약 137만 원) |
OpenAI는 모델 가격표에서 모델별 입력·출력 단가를, Batch API 문서에서 24시간 처리와 50% 할인을 안내한다. Gemini도 공식 가격표에서 Gemini 3.5 Flash의 표준·Batch 단가를 별도로 제시한다. 즉, 스크린샷의 $650은 특정 저가 교사 모델을 가정한 시나리오로는 유효하지만 모든 최신 모델의 실제 비용을 대표하지는 않는다.
실제 예산에는 실패 재시도 510%, 교사 재생성·다중 후보 1030%, LLM 판정·검증 1030%, 평가 세트 생성 35%가 추가된다. 예를 들어 Terra Batch $1,300에 재시도·검증을 40%로 가정하면 약 $1,820(약 255만 원)이다. 검증을 더 싼 모델로 분리하고, 쉬운 샘플을 사전 필터링하며, 캐시와 Batch를 적용하는 이유다. 이 수치는 공개 가격표와 가정한 토큰 수를 곱한 근사 예산일 뿐이며, 실제 청구액은 요청의 입력·출력·추론 토큰, 캐시 적중, 실패 요청, 환율과 세금에 따라 달라진다.
물론 사용수준의 품질로 파인튜닝을 하려면 어느정도의 토큰을 태워야 하는지는 정답이 없다. 위 계산예시의 2억토큰 정도는 그리 많은 양도 아니고 이정도로 충분히 튜닝된다고도 할 수 없다. 하지만 여러 논문의 말처럼 핵심 선별된 교사모델로 최소한의 토큰으로도 가능할 수 있지 않을까?
대형 회사가 증류 시도를 전부 차단하지 못하는 이유는 기술 하나의 실패가 아니라 관측의 비대칭 때문이다.
그래서 탐지는 단일 문장 워터마크보다 비정상적인 질의 분포, 계정 그래프, 요청 간격, 오류율, 출력 재사용 패턴, 모델 간 행동 유사성을 여러 신호로 묶는 방식에 가깝다. 이 신호들은 약관 집행과 보안 조치에는 도움이 되지만, 법정에서 증류를 자동 확정하는 증명서는 아니다. 제공자는 rate limit·계정 검증·출력 추적·계약상 학습 금지 조항을 함께 사용하고, 연구자와 사용자는 허가와 데이터 계보를 기록해야 한다.
AI 증류기법의 핵심은 SFTTrainer 한 줄이 아니다. 어떤 교사에게 어떤 질문을 했고, 그 답을 누가 검증했으며, 학생 모델이 무엇을 배웠는지 재현 가능한 데이터 계보를 만드는 일이다. 공개 모델의 허가된 출력, 자체 생성 데이터, 라이선스가 분명한 평가셋으로 증류하면 작은 모델의 비용·지연·온디바이스 배포를 크게 개선할 수 있다. 반대로 비공개 서비스의 출력을 우회 수집하고 출처를 숨기면, 같은 알고리즘도 산업적 신뢰를 무너뜨리는 복제가 된다.
앞으로의 경쟁은 “누가 더 많이 긁었나”보다 “누가 더 적은 교사 호출로, 더 검증 가능한 데이터로, 더 일반화되는 학생을 만들었나”로 이동할 가능성이 높다. 증류는 지능을 훔치는 마법도, 단순한 압축 버튼도 아니다. 허가·비용·데이터 품질·평가·감사를 함께 설계하는 하나의 시스템 공학 문제다.
시리즈 · 404호 개발실 웹툰 · 연재 중 30회 · 404호 개발실 30 - 조련 AI를 훈련하던 개발실의 조련사가 바뀌었습니다. <AI 코딩 조련의 역전 1.1> 컷별 상황 사슴이가 사파리 사육사와 카우보이를 섞...
