Ch.24 마무리¶
앞에서 전체 키워드를 하나의 서비스에 매핑하고, AI 활용 전략을 종합했다. 이제 강의 전체를 마무리한다.
돌아보기¶
Ch.1에서 이런 이야기를 했다.
그리고 "위키피디아 히틀러 게임"을 이야기했다. 아무 랜덤 페이지에서 출발해도 링크를 따라가면 결국 원하는 곳에 도달한다. CS도 마찬가지다. 어떤 키워드에서 출발하든, 연결을 따라가면 결국 관련 개념에 도달한다. 이 연결을 "연관어 학습법"이라고 불렀다.
24챕터를 거치면서 키워드가 쌓였다. 얼마나 쌓였는지 한번 세어보자.
| Part | 범위 | 주요 키워드 수 |
|---|---|---|
| Part 1 | Ch.1~6 기초 체력 | 약 70개 |
| Part 2 | Ch.7~9 AI와 CS | 약 15개 |
| Part 3 | Ch.10~12 자료구조/알고리즘 | 약 20개 |
| Part 4 | Ch.13~16 DB | 약 25개 |
| Part 5 | Ch.17~19 캐시/성능 | 약 20개 |
| Part 6 | Ch.20~22 설계/아키텍처 | 약 25개 |
| Part 7 | Ch.23~24 보안/마무리 | 약 10개 |
대략 180개가 넘는다. (재등장 키워드 제외, 새 키워드만 세었을 때.) 이 숫자가 중요한 건 아니다. 중요한 건 이 키워드들이 서로 연결되어 있다는 거다.
System Call(Ch.2)은 모든 I/O의 기반이다. 이게 File Descriptor(Ch.2)로 연결되고, Socket(Ch.6)으로 연결되고, Connection Pool(Ch.6)로 연결된다. Connection Pool은 Semaphore(Ch.5)와 같은 원리이고, Slow Query(Ch.16)가 Connection을 점유하면 Pool이 고갈된다. Slow Query는 Index(Ch.11, Ch.14) 미설정 때문이고, Index는 B-Tree(Ch.11) 위에서 동작한다.
하나의 키워드에서 출발하면 줄줄이 딸려 나온다. 이게 연관어 그래프다.
Ch.1에서 이 그래프가 "앞으로 만들어갈 것"이었다. 지금은 "이미 만들어진 것"이다.
이 강의의 진짜 목표¶
키워드를 180개 외우는 게 목표였던 적은 한 번도 없다.
Ch.1에서 "암기와 이해는 다르다"고 했다. 외운 지식은 컨텍스트가 바뀌면 적용할 수 없다. "프로세스와 스레드의 차이가 뭔가요?"에 대해 외운 답변을 하면 꼬리 질문에서 무너진다. 이해한 사람은 꼬리 질문이 자연스럽게 이어진다. Memory Layout, Stack/Heap 공유, Context Switch 비용, GIL까지.
이 강의의 진짜 목표는 키워드 간의 연결을 만드는 거였다.
"서버가 느리다"는 하나의 증상이다. 이 증상에서 CPU Bound / I/O Bound(Ch.3)로 분기하고, I/O Bound면 Connection Pool(Ch.6), Index(Ch.14), N+1(Ch.13), Slow Query(Ch.16)를 순서대로 의심한다. 이 순서가 자연스럽게 나오려면, 키워드 간의 연결이 머릿속에 있어야 한다.
그 연결을 만드는 과정이 24챕터였다.
이 강의에서 다루지 못한 것들¶
24챕터가 CS의 전부는 아니다. 시간과 범위의 제약으로 다루지 못한 주제들이 있다.
| 주제 | 한 줄 설명 | 이 강의에서의 접점 |
|---|---|---|
| Message Queue (Kafka, RabbitMQ) | 서비스 간 비동기 통신 | Ch.6 TCP, Ch.22 분산 시스템의 확장 |
| gRPC / HTTP/2 | 다중화 프로토콜 기반 RPC | Ch.6 Connection Multiplexing 맛보기 |
| GraphQL | 쿼리 기반 API | Ch.13 ORM, Ch.16 쿼리 최적화와 연결 |
| 분산 트랜잭션 (Saga, 2PC) | 여러 서비스에 걸친 트랜잭션 | Ch.15 Transaction, Ch.22 분산 시스템의 확장 |
| Observability (Prometheus, Grafana, Jaeger) | 분산 시스템 모니터링과 트레이싱 | Ch.19 Bottleneck 식별의 확장 |
| Event-Driven Architecture | 이벤트 기반 느슨한 결합 | Ch.20 관심사의 분리, Ch.22 분산 시스템의 확장 |
| 컴파일러 / 인터프리터 | 소스 코드가 실행되기까지의 과정 | Ch.2 Bytecode, Ch.3 GIL |
| 수학적 기초 (이산수학, 확률/통계) | 알고리즘 분석의 기반 | Ch.10~12 시간/공간 복잡도, Ch.19 Amdahl's Law |
다루지 못한 주제가 꽤 많다. 하지만 핵심은 이거다.
기초가 있으면 새로운 키워드도 기존 그래프에 연결할 수 있다.
Message Queue를 처음 접한다고 치자. Ch.6에서 TCP Connection을 배웠고, Ch.22에서 분산 시스템을 배웠다. "서비스 A가 서비스 B에게 직접 TCP로 요청하면 결합이 강하다 -> 중간에 Queue를 놓으면 느슨해진다 -> 이건 Ch.20의 DIP(의존성 역전)와 같은 원리다." 이런 연결이 가능하다.
gRPC를 처음 접한다고 치자. Ch.6에서 "HTTP/1.1에서는 하나의 Connection으로 하나의 요청-응답만 처리한다. HTTP/2에서는 Multiplexing으로 하나의 Connection에 여러 요청을 동시에 보낼 수 있다"는 걸 맛보기로 봤다. gRPC는 HTTP/2 위에서 동작한다. Connection Pool(Ch.6)의 필요성이 줄어드는 방향이다. 기존 키워드에 새 키워드가 연결된다.
분산 트랜잭션을 처음 접한다고 치자. Ch.15에서 ACID와 Transaction을 배웠다. 하나의 DB에서는 Transaction으로 정합성을 보장하지만, 여러 서비스에 걸친 작업에서는 하나의 Transaction으로 묶을 수 없다. Saga 패턴은 각 서비스의 로컬 Transaction을 체인으로 연결하고, 실패 시 보상 트랜잭션(Compensation)을 실행한다. 이건 Ch.5의 Deadlock 방지 전략(Lock Ordering)과 비슷한 사고 구조다.
열 개를 얕게 외우면 열한 번째가 나올 때 또 외워야 한다. 하나를 깊이 이해하면 그걸 차용한 열 개를 쉽게 이해할 수 있다. Ch.1에서 했던 이야기가 여기서 다시 증명된다.
WORD size 에피소드, 다시 한번¶
Ch.1에서 이런 에피소드를 이야기했다.
2010년, 5명의 개발자가 몇 주 동안 디버깅한 문제를 전화 한 통으로 해결한 빡빡이 상병. "아키텍처가 달라졌으면 WORD size부터 확인해봐야 하는 거 아니에요?"
5명이 몇 주를 뒤진 이유는 실력이 없어서가 아니었다. WORD size라는 키워드를 몰랐기 때문이었다. 키워드를 모르면 "아키텍처가 바뀌면 데이터 정렬도 바뀐다"는 연결이 떠오르지 않는다. 떠오르지 않으면 검색할 수도 없고, 의심할 수도 없다.
24챕터를 거친 지금, 이 에피소드가 다르게 보이지 않는가?
빡빡이 상병이 한 건 대단한 게 아니다. 그냥 "아키텍처"라는 단어에서 "WORD size"라는 키워드로 연결한 거다. 연관어 그래프에서 한 칸 이동한 것뿐이다. 하지만 그 한 칸이 5명의 몇 주를 하루로 바꿨다.
이 강의에서 180개 넘는 키워드를 다뤘다. 그 키워드들이 서로 연결된 그래프를 머릿속에 가지고 있으면, 운영 환경에서 문제가 생겼을 때 "어디부터 봐야 하는가"가 보인다. 그게 Computational Thinking이고, 그게 이 강의가 말하고 싶었던 전부다.
앞으로¶
이 강의가 끝이 아니다. 시작이다.
180개의 키워드는 씨앗이다. 실무에서 문제를 만날 때마다 새 키워드가 추가되고, 기존 키워드와 연결된다. "이건 Ch.6에서 봤던 Connection Pool 고갈이랑 같은 패턴이네" 하는 순간이 올 거다. 그때 그래프가 한 칸 더 커진다.
새로운 기술이 나와도 마찬가지다. Kubernetes, Kafka, gRPC, GraphQL. 이름은 새롭지만, 그 밑에 깔린 CS는 바뀌지 않는다. TCP 위에서 동작하고, Process/Thread로 실행되고, Memory를 사용하고, I/O를 한다. 기초가 있으면 새로운 기술도 기존 그래프에 연결할 수 있다.
Ch.1에서 이런 말을 했다.
사실 그 밥에 그 나물은 아니지만, 그런 자신감을 가지라는 얘기였다. 24챕터를 거친 지금, 좀 더 가까워졌길 바란다.
면접 Q&A (이 챕터로 답할 수 있는 단골 질문)¶
이 강의의 핵심 메시지를 한 줄로 말하면 뭔가요?
"키워드를 모르면 검색도 못 하고 AI도 엉뚱한 답을 준다"이다. CS를 외우는 게 아니라 키워드 그래프를 만드는 거다. WORD size 에피소드처럼, 키워드 하나가 떠오르느냐 마느냐가 5명의 몇 주를 하루로 바꾼다. 24챕터 동안 약 180개의 키워드를 서로 연결하면서, 운영 환경에서 문제가 생겼을 때 "어디부터 봐야 하는가"가 자동으로 떠오르는 그래프를 머릿속에 만드는 게 목표였다.
서버가 느려요. 어디부터 봐야 하나요?
먼저 CPU Bound인지 I/O Bound인지부터 분리한다(Ch.3). I/O Bound면 Connection Pool 상태(Ch.6), DB 쪽으로 가서 Slow Query와 Index(Ch.14, Ch.16), N+1(Ch.13)을 순서대로 의심한다. CPU Bound면 Python에서는 GIL 때문에 멀티스레드가 안 먹히니 ProcessPool이나 외부 워커로 빼는 걸 본다(Ch.3). 캐시를 먼저 붙이는 건 마지막이다. 인덱스를 안 걸어놓고 Redis부터 설치하는 게 가장 흔한 실수다(Ch.14, Ch.17).
AI에게 코드를 시킬 때 CS 키워드가 왜 중요한가요?
프롬프트에 들어가는 키워드가 AI의 검색 방향을 결정하기 때문이다(Ch.7, Ch.8). "성능 최적화 해줘"라고 하면 Redis를 설치하는 답이 나오지만, "이 쿼리에 Covering Index를 적용해줘"라고 하면 정확한 답이 나온다. 같은 문제라도 "system call이 많아 보이는데 줄여줘"와 "느려요 빠르게 해줘"는 결과가 완전히 다르다. 그리고 AI가 만든 코드를 CS 관점에서 검증할 줄 알아야 한다(Ch.9). 불필요한 추상화, 과도한 Mocking, 성능 미고려 같은 패턴을 잡아낼 수 있어야 운영에서 안 터진다.
Connection Pool 고갈은 왜 발생하고 어떻게 해결하나요?
Slow Query 하나가 Connection을 오래 점유하면 다른 요청이 풀에서 Connection을 못 받아 대기하고, 결국 타임아웃으로 줄줄이 실패한다(Ch.16). Connection Pool은 본질적으로 Semaphore와 같은 동시성 제어 구조다(Ch.5, Ch.6). 해결은 Slow Query 자체를 잡는 게 우선이다. EXPLAIN으로 QEP를 보고 Index를 적절히 건다(Ch.11, Ch.14). 풀 사이즈를 키우는 건 임시방편이고, 근본 원인은 거의 항상 쿼리 쪽이다.
Kubernetes나 Kafka 같은 새 기술이 나와도 CS 기초가 의미가 있나요?
이름이 새로워도 그 밑에 깔린 CS는 바뀌지 않는다. Kubernetes는 결국 Linux namespace와 cgroup 위에서 동작하고(Ch.22), Kafka는 TCP 위에서 메시지를 주고받는다(Ch.6). 기초가 있으면 새 기술도 기존 그래프에 연결할 수 있다. 예를 들어 Message Queue를 처음 봐도 "TCP 직접 연결은 결합이 강하다 -> 중간에 Queue를 두면 느슨해진다 -> Ch.20의 DIP와 같은 원리다"로 자연스럽게 연결된다. 열 개를 얕게 외우면 열한 번째가 또 외워야 하는 거지만, 하나를 깊이 이해하면 그걸 차용한 열 개가 쉽게 따라온다.
이 강의 다음에는 뭘 공부하면 좋나요?
이 강의에서 다루지 못한 주제들이 있다. Message Queue, gRPC/HTTP/2, GraphQL, 분산 트랜잭션(Saga, 2PC), Observability, Event-Driven Architecture, 컴파일러/인터프리터, 이산수학/확률통계 같은 것들이다. 각각 이 강의의 어느 챕터에 연결되는지 본문 표에 정리되어 있다. 새로 공부할 때 "이건 기존에 배운 어떤 키워드의 확장인가"를 먼저 묻는 습관이 중요하다. 그래야 그래프가 계속 커진다.
키워드만 외우면 면접에서 통하나요?
안 통한다. Ch.1에서 외운 답변 vs 이해한 답변의 차이를 봤다. "프로세스와 스레드의 차이"를 외워서 답하면 꼬리 질문에서 무너진다. Memory Layout, Stack/Heap, Context Switch 비용, GIL로 연결이 안 되기 때문이다. 면접관은 키워드를 아는지가 아니라 키워드 사이를 자유롭게 이동하는지를 본다. 이 강의가 키워드 간의 연결에 집착했던 이유다. 외우는 게 아니다. 연결하는 거다.
마지막¶
Ch.1의 마지막 문장을 다시 한번 쓴다.
외우는 게 아니다. 연결하는 거다.
CS를 외우지 마라. 연결하라.