책에 포함된 노트딥러닝의 감각 — 신경망에서 파운데이션 모델까지, AI를 끝까지 이해하는 가장 현실적인 지도

추천 학습 경로

2026-05-01Views 8약 11분생성형 AI 활용

이 책을 다 읽고 나면 오히려 더 중요한 질문이 남습니다. 이제 무엇을, 어떤 순서로 공부해야 할까? 여기서 많은 사람이 다시 길을 잃습니다. 누군가는 선형대수부터 처음으로 돌아가고, 누군가는 곧바로 LLM API를 두드리며, 누군가는 논문 PDF를 잔뜩 내려받습니다. 문제는 이 셋이 모두 틀렸다는 것이 아니라, 자기 목적과 맞지 않는 순서로 시작하면 오래 못 간다는 데 있습니다.

딥러닝 학습은 하나의 등산로가 아닙니다. 정상은 비슷해 보여도, 어느 길로 올라가야 하는지는 출발점과 목적에 따라 달라집니다. 개발자는 제품으로 이어지는 길을 먼저 밟아야 하고, 연구 지향 독자는 원리와 재현의 경사를 더 깊게 올라가야 합니다. 창업자와 기획자는 모델 내부를 다 외우기보다, 무엇을 만들 수 있고 무엇은 아직 위험한지 판단하는 감각을 먼저 길러야 합니다. 좋은 로드맵은 많이 배우게 만드는 지도가 아니라, 중간에 포기하지 않게 만드는 지도입니다.¹²

학습 경로를 설계하는 기본 원칙

가장 먼저 버려야 할 생각은 이것입니다. "수학을 완전히 끝낸 다음에 AI를 시작해야 한다." 물론 선형대수, 미분, 확률은 중요합니다. 하지만 현실의 학습은 대개 그렇게 흘러가지 않습니다. 벡터를 배우고 나서 임베딩을 이해하고, 미분의 감각을 잡은 뒤 역전파를 다시 읽고, 확률 분포를 본 다음 언어 모델의 출력이 왜 그렇게 생겼는지 이해하게 됩니다. 즉 수학은 입장권이 아니라, 학습 중간중간 계속 보강하는 도구에 가깝습니다.¹

그래서 더 지속 가능한 방식은 목표 기반 학습입니다. 먼저 내가 어디에 도달하고 싶은지 정하고, 그 목표를 이루는 데 필요한 개념을 단계적으로 붙이는 것입니다. 예를 들어 문서 QA 시스템을 만들고 싶은 사람은 Python과 데이터 처리, API 호출, 임베딩, 검색, RAG, 평가를 우선순위로 두는 편이 낫습니다. 반대로 논문을 읽고 새 모델을 실험하고 싶은 사람은 수학과 구현의 깊이를 더 빨리 확보해야 합니다.²³

또 하나 중요한 원칙은, 어떤 경로든 작은 프로젝트가 중간마다 들어가야 한다는 점입니다. 머리로만 배운 개념은 빨리 흩어집니다. 분류기 하나, 임베딩 비교 실험 하나, 간단한 RAG 프로토타입 하나만 만들어 봐도 이해의 밀도가 확 달라집니다. 손으로 만든 작은 실패가, 머리로 읽은 열 개의 개념보다 오래 남습니다.²⁴

모든 독자에게 공통으로 필요한 바닥 공사

경로가 다르더라도, 완전히 건너뛸 수 없는 공통 바닥은 있습니다. 첫째는 Python과 데이터 감각입니다. CSV를 읽고, 텍스트를 다루고, 리스트와 딕셔너리, 함수와 파일 입출력을 다룰 수 있어야 이후의 모든 실습이 편해집니다. 둘째는 모델을 보는 기본 언어입니다. 데이터, 특성, 라벨, 손실, 일반화, 임베딩, 토큰, 추론 같은 단어가 자연스럽게 읽혀야 합니다. 셋째는 실험 환경입니다. 가상 환경을 만들고, 노트북으로 실험하고, 버전을 기록하고, 작은 코드를 반복 실행할 수 있어야 합니다. 앞선 부록에서 다룬 최소 수학과 실습 환경은 바로 이 바닥 공사를 위한 도구였습니다.

다만 여기서 중요한 것은 균형입니다. Python만 오래 공부해도 안 되고, 수학만 오래 붙잡고 있어도 안 됩니다. 기초는 벽돌처럼 쌓는 것이지만, 학습 동기는 불꽃처럼 살아 있어야 합니다. 그래서 공통 바닥 공사는 길게 끌기보다, 작은 실습과 함께 빠르게 지나가는 편이 좋습니다.

입문자 경로: 이해와 실행을 같이 키우는 길

딥러닝에서 막혔던 입문자에게 가장 좋은 출발은 "완벽한 준비"가 아니라 "작은 이해의 반복"입니다. 먼저 AI, 머신러닝, 딥러닝, 생성형 AI가 어떻게 다른지 자기 말로 설명할 수 있어야 합니다. 그다음에는 Python 기초와 데이터 처리, 그리고 아주 간단한 모델 실습으로 넘어갑니다. 이때 목표는 성능이 아닙니다. 입력이 들어가고, 숫자가 바뀌고, 예측이 나오고, 손실이 줄어드는 흐름을 몸으로 익히는 것입니다.¹⁵

입문자에게 추천하는 순서는 대체로 이렇습니다. 먼저 Python과 데이터 다루기를 익힙니다. 그다음 지도학습의 기본 감각을 잡습니다. 이어서 신경망, 손실 함수, 경사하강법, 과적합과 일반화를 실습과 함께 다시 봅니다. 이 기반이 생기면 CNN, RNN, 트랜스포머를 "역사 순서"가 아니라 "표현이 어떻게 발전했는가"라는 관점으로 읽는 편이 좋습니다. 그다음에야 LLM, 임베딩, RAG, 파인튜닝 같은 현대 주제가 제자리를 찾습니다.¹⁵

입문자에게 특히 중요한 것은 수학을 병행하는 방식입니다. 선형대수는 벡터와 행렬의 의미를 이해하는 수준으로 먼저 잡고, 미분은 기울기와 업데이트의 감각을 이해하는 수준으로 시작하면 충분합니다. 확률도 분포와 확률적 예측을 읽는 정도면 초반에는 충분합니다. 이 세 가지를 한꺼번에 끝내려 하지 말고, 모델을 만나면서 조금씩 되돌아오는 편이 훨씬 오래 갑니다.¹

입문자 프로젝트는 작고 분명해야 합니다. 예를 들어 손글씨 숫자 분류기, 영화 리뷰 감성 분류기, 간단한 문장 유사도 비교기 같은 과제가 좋습니다. 중요한 것은 "멋진 데모"가 아니라 "왜 이 입력이 이렇게 바뀌는지 설명할 수 있는가"입니다. 프로젝트가 작을수록 개념은 더 선명해집니다.

개발자 경로: 이론 전부보다 실무 전이성이 우선이다

개발자에게 가장 위험한 함정은 두 가지입니다. 하나는 API만 쓰다가 내부 감각 없이 제품을 조립하는 것이고, 다른 하나는 이론을 전부 끝내겠다고 하다가 실무로 못 넘어가는 것입니다. 개발자 경로는 이 둘의 사이를 지나야 합니다.

실무 전이에 유리한 순서는 보통 이렇습니다. Python과 데이터 처리에 익숙해진 뒤, PyTorch나 Hugging Face로 기본 모델을 다뤄 봅니다. 그다음에는 사전학습 모델을 활용해 분류, 요약, 임베딩 추출 같은 작업을 수행합니다. 여기서 프롬프트 엔지니어링과 출력 구조화, 실패 케이스 확인을 익힙니다. 그다음 단계가 임베딩, 벡터 검색, RAG입니다. 마지막으로 평가, 비용 관리, 지연 시간, 모니터링, 배포를 공부해야 비로소 실무형 학습 경로가 완성됩니다.²³⁶

이 순서가 좋은 이유는 간단합니다. 오늘날 많은 AI 개발은 모델을 처음부터 학습시키는 일이 아니라, 이미 존재하는 모델을 어떤 시스템 안에 어떻게 연결할 것인가의 문제이기 때문입니다. 좋은 개발자는 모델 호출 코드만 쓰는 사람이 아니라, 어떤 모델을 선택할지, 응답 속도와 비용은 어떤지, 캐싱이 필요한지, 실패했을 때 폴백 모델이 필요한지, 로그는 어떻게 남길지까지 생각합니다.⁶

개발자에게 추천하는 프로젝트는 문서 QA, 고객센터 요약기, 회의록 요약기, 사내 검색 도우미 같은 형태입니다. 이런 프로젝트는 프롬프트만으로는 한계가 빨리 드러납니다. 바로 그 지점이 중요합니다. 프롬프트가 조금만 바뀌어도 성능이 흔들린다면, 이제는 프롬프트 트릭을 더 쌓기보다 검색이나 데이터 구조를 봐야 합니다. 즉 학습 경로 안에 이미 설계 판단의 기준이 들어가 있어야 합니다.

예를 들어, 프롬프트만으로 사실성 문제를 해결하기 어렵다면 RAG를 검토할 시점입니다. 검색은 되는데 관련 문서가 자꾸 빗나간다면 임베딩 모델, 청킹 방식, 재랭킹을 봐야 합니다. 검색은 잘 되는데도 도메인 말투나 형식 적합성이 부족하다면 파인튜닝을 검토해야 합니다. 이처럼 개발자 경로는 "무엇을 더 배울까"보다 "어떤 한계를 만났을 때 다음 수단으로 넘어갈까"를 아는 길이어야 합니다.³⁷

연구 지향 경로: 깊이를 감당하는 사람의 루프

연구 지향 독자에게는 다른 종류의 인내가 필요합니다. 실무형 학습은 문제를 풀면 앞으로 나아가지만, 연구형 학습은 문제를 풀수록 질문이 늘어납니다. 그래서 연구 경로는 넓게 아는 것보다, 깊게 파고드는 루프를 만드는 것이 중요합니다.

이 경로에서는 선형대수, 확률, 최적화의 기초를 더 단단하게 잡아야 합니다. 단지 용어를 아는 수준이 아니라, 왜 이 손실 함수를 쓰는지, 왜 이 정규화가 학습 안정성에 영향을 주는지, 왜 특정 아키텍처가 병렬화와 성능에서 유리한지 설명할 수 있어야 합니다. 그다음에는 고전 모델을 훑기보다, CNN과 RNN, 트랜스포머의 핵심 아이디어를 직접 재구현해 보는 편이 좋습니다.¹⁸

연구형 학습의 핵심은 논문 읽기 → 재현 실험 → 오류 분석 → 다시 읽기의 반복입니다. 논문을 읽을 때는 결과 표만 보지 말고, 문제 설정, 데이터셋 가정, 평가 지표, 비교 기준을 함께 봐야 합니다. 재현 실험을 할 때는 같은 숫자가 안 나왔다고 바로 실패로 판단하지 말고, 데이터 전처리, 시드, 하이퍼파라미터, 학습 스케줄, 구현 세부 사항이 얼마나 큰 차이를 만드는지 경험해야 합니다. 바로 그 과정에서 연구 감각이 생깁니다.⁸

연구 지향 독자에게 추천하는 프로젝트는 "서비스 데모"보다 "재현과 분석"에 가까워야 합니다. 예를 들어 고전 CNN 한 편을 재구현하거나, 작은 트랜스포머를 직접 구현하거나, 공개된 벤치마크에서 오류 사례를 분류하는 식의 프로젝트가 더 좋습니다. 모델이 왜 틀렸는지, 어떤 데이터에서 취약한지, 성능 개선이 실제 개선인지 아니면 평가 편향인지 따지는 과정이 곧 학습입니다.

또한 이 경로에서는 벤치마크를 맹신하지 않는 태도도 중요합니다. 수치가 좋아 보이더라도 데이터 누수, 평가 편향, 과도한 튜닝의 가능성을 살펴봐야 합니다. 연구자는 모델을 잘 쓰는 사람인 동시에, 결과를 쉽게 믿지 않는 사람이어야 합니다.

창업자·기획자 경로: 무엇을 만들까보다 무엇을 운영할 수 있을까

창업자나 기획자는 종종 "코드를 얼마나 직접 짜야 하나요?"를 먼저 묻습니다. 하지만 더 중요한 질문은 따로 있습니다. "이 기술로 무엇을 안정적으로 운영할 수 있나요?"입니다. 좋은 AI 제품은 신기한 데모보다, 실패했을 때 덜 위험한 시스템에서 시작합니다.

이 경로에서는 모델 내부를 전부 구현할 필요가 없습니다. 대신 문제 정의, 데이터 전략, 모델 또는 API 선택, 품질 평가, 비용 구조, 보안과 법무, 운영 리스크를 먼저 배워야 합니다. 특히 생성형 AI는 데모 단계에서는 모든 것이 쉬워 보이지만, 실제 서비스 단계에서는 환각, 최신성, 권한 관리, 저작권, 개인정보, 지연 시간, 비용 폭증 같은 문제가 한꺼번에 등장합니다. 그래서 창업자·기획자 경로는 기술을 "얼마나 깊게 이해하느냐"보다 "어디서 무너질 수 있는지 빨리 알아보느냐"가 더 중요합니다.²³

추천하는 학습 순서는 이렇습니다. 먼저 생성형 AI와 LLM이 무엇을 잘하고 못하는지 사용 경험으로 익힙니다. 그다음에는 프롬프트 설계와 출력 검증, 간단한 API 연결을 경험합니다. 이어서 임베딩과 검색, RAG와 파인튜닝의 차이를 이해합니다. 그 뒤에는 평가 체계, 비용 관리, 안전성, 개인정보와 저작권, 운영 리스크를 공부해야 합니다. 마지막으로 실제 업무 흐름에 붙는 작은 프로토타입을 만들어 봐야 합니다.²³

이 경로에서 좋은 프로젝트는 화려한 범용 챗봇이 아닙니다. 오히려 한정된 문제를 안정적으로 푸는 도구가 좋습니다. 예를 들어 사내 문서 검색 보조, 영업 제안서 초안 생성, 고객 문의 분류, 회의록 구조화 같은 작업은 효과를 측정하기도 쉽고, 실패 비용도 비교적 낮습니다. 기획자는 이 과정을 통해 "무엇이 가능한가"보다 "무엇이 지금 조직에서 먹히는가"를 배우게 됩니다.

프로젝트는 학습의 증거가 아니라 학습 그 자체다

많은 사람이 프로젝트를 포트폴리오용 결과물로만 생각합니다. 하지만 실제로 프로젝트의 더 큰 역할은 개념을 서로 연결하는 접착제라는 데 있습니다. 데이터가 왜 중요한지, 임베딩이 왜 필요한지, 평가를 왜 따로 해야 하는지, 배포 후 모니터링이 왜 필요한지는 프로젝트를 해 보면 한꺼번에 보입니다.

초급자에게는 작은 분류기나 검색기가 좋습니다. 개발자에게는 문서 QA나 요약 시스템이 좋습니다. 연구자에게는 재현 실험과 오류 분석이 좋습니다. 창업자와 기획자에게는 실제 업무 흐름에 붙는 프로토타입이 좋습니다. 프로젝트의 크기보다 더 중요한 것은, 그 프로젝트가 다음 질문을 자연스럽게 부르게 만드는가입니다.

예를 들어 분류기는 "왜 이 예측이 틀렸지?"라는 질문을 부릅니다. 검색기는 "왜 비슷한 문서가 안 나오지?"를 묻습니다. RAG 프로젝트는 "검색은 되는데 답이 왜 흔들리지?"를 드러냅니다. 이렇게 좋은 프로젝트는 정답을 확인하는 시험이 아니라, 다음 학습 단계를 스스로 호출하는 장치가 됩니다.

언제 방향을 바꿔야 하는가

좋은 로드맵은 단순히 다음 과목을 알려 주지 않습니다. 지금 방식이 한계에 닿았을 때 어디로 꺾어야 하는지도 알려 줍니다. 이 기준이 없으면 사람은 같은 자리에서 같은 실수만 반복하게 됩니다.

프롬프트를 계속 고쳐도 사실성 문제가 해결되지 않는다면, 이제는 모델의 말솜씨보다 외부 지식 연결을 먼저 봐야 합니다. 이때는 RAG를 배울 타이밍입니다. RAG를 붙였는데도 검색 문서가 자꾸 엇나간다면, 청킹, 메타데이터, 임베딩 모델, 하이브리드 검색, 재랭킹을 배워야 합니다. 검색은 꽤 괜찮은데 도메인 말투, 출력 형식, 특정 업무 절차를 잘 따르지 못한다면 파인튜닝이나 어댑터 학습을 검토할 차례입니다. 반대로 파인튜닝을 고민하고 있는데 데이터가 적고 자주 바뀌며 최신성이 중요하다면, 먼저 RAG가 더 나은 선택일 수 있습니다.⁷⁹

또 다른 전환 신호도 있습니다. 실험은 잘 되는데 서비스로 올라가면 비용이 감당 안 된다면, 이제 모델 연구보다 추론 최적화와 캐싱, 경량화, 제공 방식 선택을 배워야 합니다. 모델 성능은 괜찮은데 운영 사고가 반복된다면, 평가와 안전성, 관측 가능성, 권한 관리가 다음 과목이 됩니다. 학습은 늘 앞으로만 가는 직선이 아니라, 문제를 만나며 꺾이는 곡선입니다.

3개월, 6개월, 12개월을 어떻게 봐야 할까

많은 로드맵이 월 단위 계획을 제시합니다. 이런 계획은 출발점으로는 유용하지만, 절대 시간표처럼 받아들이면 오히려 독이 됩니다. 같은 3개월이라도 매일 30분 하는 사람과 주말마다 8시간 몰입하는 사람은 완전히 다른 경로를 걷게 됩니다. 중요한 것은 달력이 아니라 밀도입니다.

대신 이렇게 생각하면 좋습니다. 첫 3개월은 공통 바닥을 만들고 작은 프로젝트를 해 보는 시기입니다. 6개월쯤 되면 자기 경로가 조금씩 갈라져야 합니다. 개발자는 RAG와 배포 쪽으로, 연구자는 재현과 논문 해석 쪽으로, 창업자·기획자는 문제 정의와 운영 판단 쪽으로 무게가 이동합니다. 12개월쯤 되면 "무엇을 공부했다"보다 "무엇을 만들었고, 어떤 한계를 직접 겪어 봤는가"가 더 중요해집니다.³⁶

그러니 학습 기간을 남과 비교할 필요는 없습니다. 더 중요한 것은 지금 내가 어느 단계의 질문을 하고 있는가입니다. 아직도 "벡터가 뭐지?"를 묻는다면 바닥을 다지는 단계입니다. "왜 검색 성능이 이 정도에서 멈추지?"를 묻는다면 시스템 설계 단계로 올라온 것입니다. "이 벤치마크 개선이 진짜 개선인가?"를 묻는다면 연구의 문턱에 와 있는 것입니다.

결국 좋은 경로는 나를 더 오래 가게 만든다

이 책의 마지막 부록에서 꼭 남기고 싶은 말은 하나입니다. 좋은 학습 경로는 가장 빠른 길이 아닙니다. 가장 화려한 길도 아닙니다. 계속 걸을 수 있는 길입니다.

입문자는 개념과 작은 실습을 함께 붙여야 오래 갑니다. 개발자는 제품으로 이어지는 기술 스택을 단계적으로 밟아야 오래 갑니다. 연구 지향 독자는 수학, 구현, 논문, 오류 분석의 루프를 견뎌야 오래 갑니다. 창업자와 기획자는 기술 자체보다 문제 적합성, 데이터, 비용, 리스크를 먼저 볼 때 오래 갑니다.

같은 딥러닝을 공부해도, 모두가 같은 순서로 배울 필요는 없습니다. 오히려 다르게 배워야 합니다. 그래야 딥러닝이 따로 놀지 않고, 모델과 시스템과 제품의 언어가 하나의 지도로 이어집니다.

이제 다음 공부를 고를 때는 이렇게 물어보면 됩니다. 나는 무엇이 되고 싶은가? 그리고 지금 내 한계를 넘기려면, 다음에 무엇을 배워야 하는가? 그 질문에 스스로 답할 수 있다면, 이미 좋은 로드맵의 절반은 손에 들어온 셈입니다.