Why I Stopped Watching Coding Tutorials (And Read Textbooks Instead)

URL: https://www.youtube.com/watch?v=ILhH4dllAWM
채널: CodingKernel
발행일: 2026-09-27
영상 길이: 4분 32초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==짧은 튜토리얼과 AI 프롬프트는 지식을 조각내기 쉽다. 기술 교과서를 중심으로 전체 개념을 읽고, 관련 프로젝트로 적용하면 파편화된 지식을 연결된 시스템으로 바꿀 수 있다.==

• 유튜브 영상·짧은 강의·AI 질의는 빠른 입문에는 좋지만 개념의 전체 맥락을 보장하지 않는다.
• 영상 제작자는 “12부작 시리즈를 6화, 9화, 4화 순서로 띄엄띄엄 보는 것”에 비유한다.
• 교과서는 기초 개념을 계층과 역사 속에서 연결해 주지만, 교과서만 장시간 읽는 것도 좋은 방법은 아니다.
• 가장 좋은 조합은 매일 짧게 교과서를 읽고, 읽은 개념을 구현하는 프로젝트를 함께 진행하는 것이다.

1. 튜토리얼과 프롬프트가 만드는 파편화

1.1. 빠른 학습 콘텐츠의 장점과 한계

1. 기존 학습 방식

   1. 새로운 개념을 배울 때 유튜브 영상을 보거나, Udemy의 짧은 강의를 듣거나, 인터넷 자료를 검색했다.
   2. 여기에 AI에게 질문하고 필요한 부분만 프롬프트로 확인하는 방식을 더했다.
   3. 개별 질문에는 답을 얻을 수 있었고, 당장의 프로젝트를 진행하는 데도 도움이 됐다.
   4. 하지만 시간이 지나면 항상 무언가 빠져 있다는 느낌이 남았다.

2. 전체 그림의 부재

   1. 짧은 콘텐츠는 한 개념의 일부를 설명하는 데 최적화되어 있다.
   2. 왜 그 개념이 생겼는지, 이전 계층의 문제를 어떻게 해결했는지, 다음 계층에 어떤 영향을 주는지는 여러 콘텐츠에 흩어진다.
   3. AI는 질문한 범위 안에서 정확한 설명을 줄 수 있지만, 사용자가 무엇을 묻지 않았는지까지 자동으로 보장하지는 않는다.
   4. 그 결과 “TCP와 UDP의 차이”는 외워도 네트워크 전체에서 그 차이가 왜 중요한지는 설명하지 못할 수 있다.

1.2. 12부작 시리즈 비유

1. 비선형 시청

   1. 학습자가 어떤 날은 12부작 시리즈의 6화를 보고, 9화로 갔다가, 길을 잃어 4화로 돌아간다.
   2. 다시 10화나 12화를 보고도 이해가 안 되면 1화로 돌아간다.
   3. 각 에피소드는 재미있지만 학습 순서가 선형적이지 않기 때문에, 전체 줄거리를 제대로 이해하기 어렵다.
   4. 짧은 튜토리얼을 이어 붙이는 방식도 비슷하게 작동한다.

2. 파편 지식의 증상

   1. 특정 질문에 대한 답변은 할 수 있지만, 주변 개념을 더 깊게 물으면 설명이 끊긴다.
   2. 새 프로젝트에서 같은 개념이 다른 형태로 등장하면 기존의 암기한 답을 적용하지 못한다.
   3. 면접에서 후속 질문이 들어오는 순간 지식의 빈틈이 드러난다.
   4. 따라서 핵심은 더 많은 짧은 콘텐츠를 소비하는 것이 아니라, 개념 사이의 연결을 확보하는 것이다.

2. 교과서 중심 학습의 전환

2.1. 교과서는 ‘전체 그림’을 제공한다

1. 읽게 된 계기

   1. 영상 제작자는 Martin Kleppmann의 《Designing Data-Intensive Applications》를 읽고, 컴퓨터 네트워크 교과서인 《Computer Networking: A Top-Down Approach》를 절반 정도 읽는 중이었다.
   2. 네트워킹이 학교에서 필수 과목이 아니라 선택 과목이었고, 당시에는 네트워킹보다 AI 선택 과목을 택했다.
   3. 여러 소프트웨어 엔지니어링 프로젝트를 진행하면서 네트워킹이 거의 모든 프로젝트에 조금씩 등장한다는 사실을 깨달았다.
   4. 작은 기능이든 큰 시스템이든 결국 네트워크를 만져야 하므로, 비어 있는 기초를 메우기 위해 교과서를 선택했다.

2. 교과서가 주는 연결

   1. 교과서는 개념을 단독 팁으로 제시하기보다 앞선 문제와 뒤따르는 해결책의 관계로 설명한다.
   2. 특정 프로토콜이 왜 만들어졌고, 어떤 한계 때문에 업그레이드되었는지 이해하게 한다.
   3. 단순히 “TCP는 신뢰성 있고 UDP는 빠르다”가 아니라, 애플리케이션 계층에서 전송 계층까지 흐름 속에서 판단할 수 있게 한다.
   4. 영상 제작자는 책을 절반만 읽은 시점에도 애플리케이션 계층부터 전송 계층까지의 질문에는 자신 있게 답할 수 있다고 말한다.

2.2. 교과서만 읽는 것도 답은 아니다

1. 장시간 몰입의 함정

   1. 교과서를 12~15시간 연속으로 읽는다고 자동으로 학습되는 것은 아니다.
   2. 영상 제작자는 자신을 방에 가두고 책만 읽으라고 말하지 않는다.
   3. 오히려 하루 몇 시간, 때로는 30분만 읽어도 꾸준히 이어 가는 편이 현실적이다.
   4. 읽은 뒤 개념을 프로젝트에 적용해야 추상적인 설명이 실제 구조와 연결된다.

2. 이론과 구현의 결합

   1. 책에서 읽은 개념과 관련된 프로젝트를 직접 코딩한다.
   2. 네트워크를 읽는다면 클라이언트·서버·프로토콜·전송 계층의 흐름을 관찰할 수 있는 작은 프로그램을 만든다.
   3. 구현 중 생기는 질문을 다시 책의 해당 장으로 가져가면 읽기와 실습이 서로 보강된다.
   4. 이론은 전체 그림을 제공하고, 프로젝트는 그 그림이 실제로 어떻게 작동하는지 확인하게 한다.

3. TCP와 UDP 면접 경험

3.1. 한 질문에 답했지만 전체를 몰랐다

1. 면접에서 드러난 공백

   1. 여러 회사의 면접을 준비하면서 네트워킹 질문이 반복해서 나온다는 사실을 알게 됐다.
   2. 한 대기업 면접에서 TCP와 UDP의 차이를 질문받았지만 당시에는 답하지 못했다.
   3. 그 질문에 답하지 못한 것이 불합격의 이유라고 생각했다.
   4. 이후 집에 돌아와 AI, 짧은 영상, 온라인 자료를 이용해 두 프로토콜의 기본 차이를 학습했다.

2. 패치식 학습의 한계

   1. 다음 면접에서 TCP와 UDP의 차이를 정확히 답할 수 있었다.
   2. 그러나 면접관이 추가 질문을 하자 주변 개념을 몰라 다시 막혔다.
   3. 네트워크에는 일반적으로 설명되는 여러 계층이 있고, TCP·UDP는 그중 전송 계층의 일부라는 맥락을 충분히 이해하지 못했다.
   4. 한 조각을 보수한 것이지, 시스템 전체를 이해한 것이 아니었다.

3.2. 책이 질문의 주변까지 연결한다

1. 응용 계층에서 전송 계층까지

   1. 《Computer Networking: A Top-Down Approach》를 읽으며 응용 계층에서 전송 계층으로 내려가는 흐름을 따라갔다.
   2. 프로토콜의 역할뿐 아니라 왜 그 프로토콜이 등장했는지, 어떤 문제를 해결했는지, 이후 어떤 개선이 필요했는지 이해하게 됐다.
   3. 그래서 특정 면접 질문 하나가 아니라, 그 질문을 둘러싼 전체 이야기를 설명할 수 있게 됐다.
   4. 면접에서 후속 질문이 들어와도 답변을 다른 개념과 연결할 수 있는 기반이 생겼다.

2. 지식의 안정성

   1. 짧은 영상에서 한 시간 동안 소비한 설명은 다른 자극이 들어오면 쉽게 사라질 수 있다.
   2. 반면 책을 45분 정도 천천히 읽으면 개념이 더 오래 남는다고 느꼈다.
   3. 스크롤 중심의 빠른 정보 소비에서 잠시 벗어나는 것 자체가 학습의 질을 높인다.
   4. 책이 항상 더 우월하다는 주장이 아니라, 전체 구조를 이해하는 데 적합한 매체를 의도적으로 선택하자는 주장이다.

4. 추천 도서 목록과 학습 경로

영상은 소프트웨어 엔지니어링에서 자주 마주치는 주제별로 대표 도서를 제시한다. 모든 책을 한 번에 읽으라는 뜻이 아니라, 자신의 약한 영역을 찾아 전체 개념을 연결하는 출발점으로 사용하라는 목록이다.

1. 시스템 설계: Martin Kleppmann, 《Designing Data-Intensive Applications》
2. 네트워킹: 《Computer Networking: A Top-Down Approach》
3. 알고리즘·자료구조: 《Introduction to Algorithms》
4. 운영체제: 《Operating Systems: Three Easy Pieces》
5. 컴파일러: 《Compilers: Principles, Techniques, and Tools》
6. 소프트웨어 엔지니어링 실천: 《The Pragmatic Programmer: From Journeyman to Master》
7. 컴퓨터 구조: 《Computer Organization & Design: The Hardware/Software Interface》
8. 객체지향 아키텍처: 《Design Patterns: Elements of Reusable Object-Oriented Software》
9. 프로그래밍 패러다임: 《Structure and Interpretation of Computer Programs》
10. 코드 품질·유지보수: 《Clean Code: A Handbook of Agile Software Craftsmanship》
11. 데이터베이스 내부 구조: 《Database Internals: A Deep Dive into How Distributed Data Systems Work》
12. AI 엔지니어링: 《AI Engineering: Building Applications with Foundation Models》

영상에서는 목록을 인터넷에서 찾아보거나 온라인판을 읽어도 충분하다고 말한다. 종이책이 필수는 아니다. 중요한 것은 책의 소유가 아니라, 특정 영역을 처음부터 끝까지 연결해 읽고 프로젝트로 확인하는 습관이다.

5. 실천 루틴

5.1. 하루 학습 루프

1. 자신의 프로젝트에서 자주 마주치지만 설명하지 못하는 주제를 하나 고른다.
2. 해당 분야의 표준 교과서 또는 깊이 있는 기술서를 정한다.
3. 하루 몇 시간 또는 최소 30분을 정해 해당 장을 순서대로 읽는다.
4. 읽은 개념을 사용하는 작고 구체적인 프로젝트를 만든다.
5. 구현 중 막힌 질문은 AI에게 묻되, 답을 그대로 붙이지 말고 책의 개념과 연결해 다시 설명한다.
6. 다음 날 책으로 돌아와 빈틈을 메우고, 프로젝트에서 동작을 확인한다.

5.2. AI를 배제하지 않고 위치를 바꾼다

1. AI는 빠른 개념 확인, 용어 설명, 예제 생성, 오류 탐색에 활용한다.
2. AI에게 “이것만 알려 줘”라고 물은 뒤 학습을 끝내지 말고, 그 답이 전체 구조에서 어디에 해당하는지 확인한다.
3. 면접 질문을 맞히는 데 필요한 단편 답변과, 후속 질문을 견디는 시스템 이해를 구분한다.
4. AI가 만든 코드는 학습 프로젝트의 최종 답이 아니라, 읽고 수정하고 반박할 대상이다.

주요 발언 모음

“짧은 콘텐츠를 이어 붙이는 것은 12부작 시리즈를 6화, 9화, 4화 순서로 보는 것과 비슷하다.”

“교과서를 읽고 관련 프로젝트를 코딩하는 것이 두 세계의 가장 좋은 조합이다.”

“TCP와 UDP의 차이는 맞혔지만, 더 깊이 들어가면 주변을 몰랐다.”

“때로는 45분 앉아 책을 읽는 편이 한 시간 동안 AI나 유튜브를 소비하는 것보다 훨씬 오래 남는다.”

결론 및 시사점

1. 튜토리얼은 빠른 시작에 유용하지만 커리큘럼 전체를 대신하지 못한다.
2. 기술 분야의 기초를 제대로 이해하려면 장의 순서와 개념의 계층을 따라 읽어야 한다.
3. 교과서를 읽는 시간은 짧아도 된다. 지속적인 30~45분 루틴이 장시간 몰입보다 현실적이다.
4. 책에서 배운 개념은 관련 프로젝트로 구현해야 지식이 살아 있는 구조가 된다.
5. 면접에서 단편 질문에 답하는 것보다 후속 질문을 개념 간 연결로 설명하는 능력이 중요하다.
6. AI는 학습을 대체하는 정답 생성기가 아니라, 전체 그림을 이해하기 위한 보조 도구로 배치해야 한다.
7. 자신의 약한 영역을 네트워킹·운영체제·컴파일러처럼 주제로 나누고 대표 도서를 선택한다.
8. 책을 읽은 뒤 “이 개념이 실제 시스템에서 어디에 쓰이는가?”를 프로젝트로 검증한다.
9. 학습의 진척도는 본 콘텐츠를 몇 개 소비했는지가 아니라, 시스템 전체를 설명할 수 있는가로 판단한다.
10. 빠른 정보 소비를 잠시 멈추고 깊이 읽는 시간 자체가 현대 개발자의 경쟁력이 될 수 있다.

핵심 요약 (20줄)

1. 짧은 코딩 튜토리얼과 AI 프롬프트는 빠르지만 지식을 파편화할 수 있다.
2. 영상 제작자는 이 방식을 12부작 시리즈를 무작위 순서로 보는 일에 비유한다.
3. 개별 질문의 답을 알아도 전체 시스템의 맥락을 모르면 후속 질문에서 막힌다.
4. 교과서는 개념의 앞뒤 관계와 역사적 이유를 연결해 준다.
5. 제작자는 《Designing Data-Intensive Applications》와 네트워킹 교과서를 읽고 있다.
6. 학교에서 네트워킹을 선택하지 않았지만 여러 프로젝트에서 네트워크를 계속 만났다.
7. 면접에서 TCP와 UDP의 차이를 묻는 질문에 답하지 못한 경험이 전환점이 됐다.
8. AI와 짧은 영상으로 답을 외운 뒤 다음 면접에서는 기본 질문을 맞혔다.
9. 하지만 추가 질문을 받자 네트워킹 전체를 모른다는 사실이 드러났다.
10. 교과서를 읽은 뒤에는 응용 계층부터 전송 계층까지의 흐름을 설명할 수 있게 됐다.
11. 책은 프로토콜이 왜 생겼고 왜 개선됐는지를 연결해 준다.
12. 교과서만 하루 15시간 읽으라는 뜻은 아니다.
13. 하루 몇 시간 또는 30분씩 꾸준히 읽는 것이 현실적인 방법이다.
14. 읽은 개념과 관련된 프로젝트를 함께 코딩해야 이론이 실제 구조와 연결된다.
15. AI는 용어 확인과 예제 생성에 쓰되 전체 그림을 대신 맡기지 않는다.
16. 45분의 깊은 독서는 한 시간의 빠른 AI·영상 소비보다 오래 남을 수 있다.
17. 영상은 시스템 설계, 네트워킹, 알고리즘, 운영체제 등 핵심 도서를 추천한다.
18. 온라인판으로 읽어도 되며 종이책 소유는 필수가 아니다.
19. 핵심은 자신의 약한 영역을 골라 한 권의 구조를 끝까지 따라가는 것이다.
20. 좋은 개발 학습은 책으로 전체를 보고 프로젝트로 적용하며 AI로 빈틈을 확인하는 루프다.