컴퓨터과학 — 세상이 어떻게 작동하는지 설명하고 예측하는 7 분야: 계산이론 · 네트워크 · 소프트웨어공학 · 알고리즘 · 운영체제 · 자료구조 · 프로그래밍언어 의 각자 다른 질문들

“컴퓨터과학은 *세상이 어떻게 작동하는지 설명하고 예측한다”* — 이 한 문장이 컴퓨터과학을 물리학·화학·생물학과 같은 자연과학 의 자리 에 놓는다. 우리가 만든 인공물(컴퓨터) 이지만, 그 인공물에서 *피해 갈 수 없는 법칙 들이 발견되었고, 그 법칙들을 연구하는 것이 컴퓨터과학이다. 자연과학이 *발견된 우주 를 다룬다면 컴퓨터과학은 발명된 우주 안에서 발견된 우주 를 다룬다.

이 글은 컴퓨터과학을 7 분야로 — 각자 다른 질문에 답하는 별개의 과학으로 — 풀어 본다. (1) 계산이론 “무엇이 컴퓨터로 풀 수 있고 풀 수 없나”, (2) 네트워크 “정보를 어떻게 전달할 것인가”, (3) 소프트웨어공학 “정보 처리를 어떻게 *조직 할 것인가”, (4) 알고리즘 *“정보를 어떻게 *처리 할 것인가”, (5) 운영체제 *“하드웨어를 어떻게 추상화하고 자원을 관리할 것인가”, (6) 자료구조 “정보를 어떻게 표현할 것인가”, (7) 프로그래밍언어 “인간의 의도를 컴퓨터가 실행할 수 있는 형태로 어떻게 번역할 것인가”.

7 분야는 독립적으로 발달했지만 결국 서로를 설명하지 않으면 작동하지 않는다. 그 상호 의존 까지가 본 글의 마지막 절.

TL;DR

컴퓨터과학 = 7 개의 별개 질문에 답하는 학문 집합.

분야	답하는 질문	핵심 발견	한국에서 마주친 적 있는 모습
계산이론	무엇이 불가능 한가	정지 문제, P vs NP	“AI 가 보안 코드를 완벽하게 검사할 수는 없습니다”
네트워크	전달 의 한계	CAP, Two Generals	카카오톡 데이터센터 화재 (2022-10) 의 본질
소프트웨어공학	조직화 의 비용	Brooks’ Law, Conway 의 법칙	“이번 분기엔 조직 개편 이 있으니 서비스도 쪼개야 한다”
알고리즘	처리 의 효율	NP-hard, 분할 정복	쿠팡 새벽배송 의 배송 경로 최적화 (TSP 의 친척)
운영체제	공유 의 공정성	스케줄링, 가상 메모리	“쿠버네티스 노드 가 한쪽 pod 에 CPU 다 빼앗김”
자료구조	표현 의 trade-off	트리·해시·그래프 의 비용 균형	NAVER 자동완성 의 trie, 인스타그램 피드 의 시간 인덱스 + 해시 결합
프로그래밍언어	번역 의 표현력	타입 시스템, 정합성 보장	“Kotlin 으로 마이그레이션 후 NPE 가 사라졌다”

모든 7 분야의 공통 깊은 진실: 공짜 점심은 없다. 한 가지를 얻으면 한 가지를 잃는다. trade-off 의 *체계화 가 컴퓨터과학의 본질. 이 관점으로 보면 *7 분야는 각자 다른 차원의 trade-off 를 발견·증명·관리하는 학문이다.

실무 함의: 어느 한 분야만 깊게 안다고 시스템이 작동하지 않는다. production 사고는 늘 7 분야의 *경계 에서 터진다. 데이터베이스가 죽었을 때 — *알고리즘 (인덱스 선택) / 자료구조 (B-tree fragment) / 운영체제 (page fault) / 네트워크 (replica sync) / 소프트웨어공학 (transaction boundary) 중 무엇이 원인인지 구분할 수 있어야 한다. 그래서 얕게 7 + 깊게 1 이 정공.

0. 들어가며 — 컴퓨터과학이 “과학” 인 이유

물리학자는 세상에 *있는 법칙* 을 발견한다. \(F = ma\). \(E = mc^2\). 이미 있는 우주 를 관찰해서 공식으로 압축.

컴퓨터과학자는 우리가 *만든 우주에서 피해 갈 수 없는 법칙* 을 발견한다. 모든 정렬 알고리즘은 비교 기반에선 \(\Omega(n \log n)\) 보다 빠를 수 없다. 분산 시스템은 *일관성·가용성·분할 허용성 셋 다 동시에 못 가진다 (CAP). 어떤 프로그램이 *정지하는지 를 일반적으로 결정 할 수 있는 알고리즘은 존재하지 않는다 (정지 문제). 우리가 만들었지만 *우리가 *바꿀 수 없는 한계* — 이게 컴퓨터과학의 발견이다.

“수학자는 가능성을 다룬다. 자연과학자는 현실을 다룬다. 컴퓨터과학자는 *우리가 만든 현실의 가능성과 한계 를 다룬다*.”

이 정의가 컴퓨터과학을 과학 이라 부를 수 있는 이유. “세상이 어떻게 작동하는지 설명하고 예측한다” — 세상 이 우리가 만든 디지털 세상일 뿐, 과학의 본질은 같다.

1. 계산이론 — 컴퓨터의 한계를 연구

“It is not yet decided whether life will be terminated by mechanical or by intellectual extinction, but if I had to bet, I would bet on the latter.” — Edsger Dijkstra

1-1. 답하는 질문

“무엇을 컴퓨터로 풀 수 있고, 무엇을 풀 수 없는가? 풀 수 있다면 얼마나 *비싸게 풀어야 하는가?”*

계산이론은 컴퓨터를 만들기도 전에 시작됐다. Alan Turing 의 1936 년 논문 “On Computable Numbers” — 컴퓨터가 발명되기 9 년 전 — 이 계산 자체의 정의 를 만들었다. 튜링 기계 라는 수학적 추상이 “무엇이 계산 가능한가” 의 기준 모델이 되었다.

1-2. 두 가지 거대 발견

(A) 정지 문제 (Halting Problem) — 풀 수 없는 문제가 존재한다.

“임의의 프로그램 P 와 입력 X 가 주어졌을 때, P(X) 가 *언젠가 멈출지 영원히 돌지를 항상 정확히 답하는 알고리즘은 존재하지 않는다“. *수학적으로 증명 되었다. 이건 “아직 못 찾았다” 가 아니라 “있을 수 없다”.

함의: 모든 정적 분석 도구 — type checker, 보안 분석, 자동 verifier — 근본적으로 불완전. 어떤 비결정적 영역이 남는다. 완벽한 자동화는 *불가능. 인간의 판단이 체계적으로 필요한 자리 가 있다.

(B) P vs NP — 효율적으로 풀 수 있는 문제와 그렇지 않은 문제의 경계.

P: 결정적 다항 시간 에 풀리는 문제 (입력 크기의 다항식만큼 시간)
NP: 해답이 주어지면 다항 시간 안에 *검증 할 수 있는 문제

세상의 거대한 미스터리: \(P = NP\) 인가, \(P \neq NP\) 인가? 2026 년 현재도 *미해결. 100 만 달러 Clay 상금이 걸려 있다. 대부분의 학자는 \(P \neq NP\) 라 추측하지만 증명 못 했다.

왜 중요한가: NP-complete 문제 (3SAT, TSP, knapsack, graph coloring 등) — 만약 하나라도 다항 시간에 풀리면 모든 NP-complete 문제가 풀린다. 그러면 암호화, 최적화, AI 학습 의 모든 토대 가 순식간에 무의미 해진다.

우리가 *공개키 암호 를 안전하다고 믿는 이유는 \(P \neq NP\) 가 (아마) 사실이라서. *수학적으로 증명되지 않은 가정 위에 인류의 디지털 신뢰가 쌓여 있다.

1-3. 대각선 논법 — 정지 문제 증명의 드라마

Turing 의 증명 방식이 미적이다. 반증을 가정 — “정지 문제를 해결하는 알고리즘 H 가 존재한다”. 이 H 를 이용해 역설적인 프로그램 D 를 만든다 — “H 가 D(D) 가 멈춘다고 답하면 D 는 영원히 돌고, 멈추지 않는다고 답하면 D 는 즉시 멈춘다”. D(D) 자체를 부른 순간 “멈춘다 → 안 멈춘다 → 멈춘다 → …” 의 무한 모순. 따라서 H 는 존재할 수 없다. Cantor 의 *대각선 논법 (1891) 을 프로그램에 적용 한 우아함. *수학 의 한 도구가 *반세기 후 컴퓨터과학 의 핵심 정리를 낳았다*.

1-4. 실무에서 만나는 모습

“이 문제는 NP-hard 입니다” 는 “포기하라” 가 아니라 “근사 해법(approximation) 또는 휴리스틱으로 가라” 의 신호. 외판원 문제(TSP)는 완전 정답 을 구하면 안 되지만 95% 정확한 답을 1초 안에 구할 수 있다. 실무 알고리즘 설계의 본질은 “이 문제가 P 인가 NP 인가” 를 먼저 판단 하는 것.

또한 분산 시스템의 *FLP impossibility result — 완전 비동기 시스템에서 *fault-tolerant consensus 는 불가능 하다는 1985 년 정리. 이 *불가능성 위에서 Paxos / Raft 같은 우회 가 만들어졌다. 불가능을 알아야 가능한 우회가 보인다.

📖 입문 한 권: Michael Sipser, Introduction to the Theory of Computation (한국어 번역 있음). 튜링 기계 → 정지 문제 → 복잡도 클래스 의 정공 교과서.

⚠️ 흔한 오해: “양자 컴퓨터 가 NP-hard 를 다항 시간에 풀 것이다”. 사실 — 양자 컴퓨터 (양자튜링기계) 도 *결정 가능 한 문제 의 범위 는 같다. 더 빠르게 풀 수 있는 특수한 NP 문제 가 있지만 (Shor 의 인수분해), NP-complete 문제 의 *일반적 다항 시간 해법 은 양자 도 풀지 못한다는 게 *현재의 추측**. *기계가 바뀌어도 *복잡도 클래스 의 본질 은 그대로*.

2. 네트워크 — 정보를 어떻게 전달할 것인가

“The network is the computer.” — John Gage (Sun Microsystems, 1984)

2-1. 답하는 질문

“두 지점 사이에 *정보 를 신뢰성 있게 / 효율적으로 / 보안 있게 전달하는 방법은 무엇인가?”*

네트워크는 물리 와 논리 가 만나는 분야. 전자기파, 광섬유, 위성 같은 물리 매체 위에 프로토콜 이라는 논리 약속이 쌓인다.

2-2. 거대 발견 3가지

(A) 패킷 스위칭 — Paul Baran 의 1960 년대 발명. 정보를 작은 조각(패킷) 으로 쪼개 각자 다른 길로 보낸 후 *수신측에서 재조립. 회선 교환(전화) 처럼 전용 통로 가 필요 없다. 부분 장애에 강함 — 한 라우터 죽어도 다른 경로로 우회. 인터넷의 기본 원리.

(B) 계층 모델 (OSI 7 layer / TCP/IP 4 layer) — 물리 → 데이터링크 → 네트워크 → 전송 → 세션 → 표현 → 응용. 각 계층은 바로 위·아래만 알면 됨. 한 layer 의 변경 (예: 광섬유 → 무선) 이 전체 다시 안 만들어도 됨. 추상화 가 네트워크의 진화 가능성 을 만들었다.

(C) Two Generals Problem — 완벽한 합의는 비동기 채널에서 불가능. 두 장군이 각자 다른 언덕 에서 동시 공격 을 약속해야 하는데 메시지가 도달했는지 확인 하려면 또 다른 메시지가 필요하고, 그 메시지가 도달했는지 확인하려면… 무한 회귀. 지금 우리가 사용하는 모든 TCP / TLS handshake 가 이 문제의 현실적 우회 (확률적 신뢰).

2-3. 카카오 SK C&C 화재 (2022-10-15) — 한 단일 데이터센터 의 함정

2022 년 10 월 판교 SK C&C 데이터센터 화재로 카카오 의 거의 모든 서비스 가 수십 시간 정지. 표면은 물리적 화재 이지만 컴퓨터과학적 진짜 원인 은 지리적 다중화 (geographic redundancy) 부재. CAP 정리 가 분단 (Partition) 은 불가피 라 말하는데, 그 분단 이 *데이터센터 전체 단위 로 일어날 수 있다* 는 가능성을 충분히 설계에 반영하지 않았다. 이후 모든 한국 기업의 이중 IDC / 멀티 클라우드 전환 의 출발점이 됐다. “분산 시스템 의 가장 비싼 수업료를 한 사회가 함께 냈다”.

2-4. CAP 정리 — 분산 시스템의 3 자 trade-off

Eric Brewer 의 2000 년 추측, 2002 년 정리. 분산 시스템에서:

C (Consistency): 모든 노드가 같은 시점에 같은 값을 본다
A (Availability): 모든 요청에 언젠가는 응답
P (Partition tolerance): 네트워크 단절 이 있어도 시스템이 동작

이 셋 동시에 만족 불가능. P 는 현실 (네트워크는 끊긴다) 이라 선택지 X. 남은 선택은 C vs A:

CP 시스템: 일관성 우선, 단절 시 응답 거부 (etcd, ZooKeeper)
AP 시스템: 가용성 우선, 단절 시 오래된 데이터 응답 (DynamoDB, Cassandra)

이 trade-off 는 피할 수 없다. “우리 DB 는 CAP 셋 다 만족합니다” 는 수학적으로 불가능 한 주장.

2-5. 실무

gRPC 의 retry 정책 — Two Generals 의 현실판. exactly-once 는 거의 불가능, at-least-once + idempotent 가 정공
DNS 의 캐시 TTL — CAP 의 AP 선택. 일관성보다 빠른 응답
마이크로서비스의 circuit breaker — 부분 장애 격리. 한 서비스 다운이 전체 다운으로 번지지 않게

📖 입문 한 권: Martin Kleppmann, Designing Data-Intensive Applications. 분산 시스템 의 실무 백서. 그리고 Computer Networks (Tanenbaum) 가 물리층 부터 응용층 의 정공.

⚠️ 흔한 오해: “HTTP/2 / HTTP/3 가 모든 걸 빠르게 한다”. 사실 — RTT (왕복 시간) 자체 는 광속의 한계. 서울-뉴욕 약 200ms — 어떤 프로토콜도 이 미만 못 만든다. 프로토콜 개선 = 한 번 의 RTT 안에 더 많이 욱여넣기. 서울 사용자 가 뉴욕 서버 와 통신 한다면 *CDN / edge / 한국 IDC 외에는 답이 없다*.

3. 소프트웨어공학 — 정보를 처리* 한다*

“Adding manpower to a late software project makes it later.” — Fred Brooks (1975)

3-1. 답하는 질문

“여러 사람이 *함께 만드는 복잡한 시스템 을 유지보수 가능한 형태 로 조직 하는 방법은 무엇인가?”*

알고리즘이 한 문제 를 푼다면, 소프트웨어공학은 그 알고리즘 100 개를 어떻게 함께 작동하게 만들고 *5 년 후의 *다른 개발자가 고칠 수 있는 형태로 유지 할까* 를 다룬다. 기술적 문제 보다 사회적·조직적 문제 의 비중이 크다.

3-2. 거대 발견 4 가지

(A) Brooks’ Law — Fred Brooks 의 1975 년 “The Mythical Man-Month”: “늦은 프로젝트에 사람을 더 투입하면 *더 늦어진다“. *추가된 사람을 가르치고 조율하는 비용 > 추가된 사람의 생산성. 인력 ≠ 생산성 이라는 반직관적 진실. 50 년이 지나도 근본적으로 옳다.

(B) Conway’s Law — Melvin Conway 의 1967 년: “시스템의 구조는 그것을 만든 조직의 *의사소통 구조 를 반영한다”. *모놀리스 회사는 모놀리스를 만들고, 팀이 N 개로 분리된 회사는 마이크로서비스 N 개를 만든다. 기술 결정 = 조직 결정.

(C) 추상화 — 모든 좋은 소프트웨어의 핵심. 복잡한 것을 *단순한 인터페이스 뒤에 숨김. 함수·클래스·모듈·서비스 가 모두 추상화의 단위. 추상화 잘못하면 누구도 손댈 수 없는 시스템 이 된다. 추상화 잘하면 부분만 바꿔도 전체가 *그대로 작동.

(D) 기술 부채 (Technical Debt) — Ward Cunningham 의 1992 년 메타포. 지금 빨리 가려고 *나중에 갚을 약속 으로 코드를 출시. *부채는 *이자가 붙는다 — 시간이 갈수록 수정 비용 증가. 모든 시스템은 기술 부채를 진다. 다만 의식적으로 관리하느냐 무의식적으로 누적하느냐 의 차이.

3-3. 패러다임 진화

구조적 프로그래밍 (1970s) — goto 금지, 순차/분기/반복
객체지향 프로그래밍 (1980s) — 데이터 + 행위 캡슐화
함수형 프로그래밍 (재발견 2010s) — 불변성 + 순수 함수
헥사고날 / 클린 아키텍처 (2010s) — 비즈니스 로직 ↔ 인프라 분리
MSA (2015~) — 서비스 단위 독립 배포

각 패러다임은 이전 패러다임의 한계 에 대응해 등장. “OOP 가 절대 정답” 이라 외쳤던 시기 → 상속 폭발 / 의존 지옥 → 함수형 재발견 → 조합 가능성. 역사적 진자.

3-4. OS/360 의 비극 — Brooks 가 책을 쓰게 된 이유

Fred Brooks 가 “The Mythical Man-Month” 를 쓴 건 IBM 에서 OS/360 프로젝트 관리 후. 수백 명이 투입됐는데 늦어질수록 사람을 더 투입 — Brooks’ Law 의 실시간 발견. 이 책은 “50 년이 지나도 *반드시 다시 읽어야 하는 유일한 컴퓨터 책”* 으로 평가받는다. 기술이 아니라 *인간 협업의 법칙 을 다루기 때문. 우리가 *마이크로서비스 / 모노레포 / DevOps 를 외쳐도 Brooks 가 1975 년에 본 풍경 이 2026 년에도 같은 모양으로 반복 된다.

3-5. 실무

코드 리뷰 — Brooks’ Law 의 현실판. 새 사람이 기존 코드를 이해하는 비용 측정 도구
모노레포 vs 폴리레포 — Conway’s Law 의 정면 충돌. 조직 구조 그대로 가는 게 정공
ArchUnit / Architecture Tests — 추상화 경계가 시간에 따라 *침식 되는 걸 컴파일러 수준으로 강제

📖 입문 한 권: Fred Brooks, The Mythical Man-Month. 50 년이 지나도 반드시 읽어야 할 책. 한국어 번역 맨먼스 미신 있음.

⚠️ 흔한 오해: “좋은 코드 = 깔끔한 코드”. 사실 — 좋은 코드 = *6 개월 후의 다른 사람 이 *고칠 수 있는 코드**. 지금 깔끔해 보여도 *추상화 가 너무 깊으면 신입이 못 따라간다. “가독성 = 평균 독자 수준” — *너무 똑똑한 코드 는 *부채. 단순 함 이 정공.

4. 알고리즘 — 정보를 어떻게 처리* 할 것인가*

“Premature optimization is the root of all evil.” — Donald Knuth (1974)

4-1. 답하는 질문

“같은 문제를 *더 빠르게 / 더 적은 메모리로 / 더 정확하게 푸는 방법은 무엇인가? 그 한계는 어디인가?”*

소프트웨어공학이 전체 시스템의 조직 을 다룬다면, 알고리즘은 한 함수 안의 *처리 순서 를 다룬다. Donald Knuth 의 “The Art of Computer Programming” (1968~) 이 알고리즘을 학문으로 체계화. 이 책 시리즈가 50 년이 지나도 완간되지 않은 것 이 알고리즘이라는 우주의 깊이 를 상징한다.

4-2. 복잡도 표기 — Big-O

알고리즘 효율의 공통 언어. 입력 크기 n 에 따른 처리 시간의 증가율:

O(…)	의미	예시
\(O(1)\)	상수	해시 테이블 lookup
\(O(\log n)\)	로그	이진 검색
\(O(n)\)	선형	배열 순회
\(O(n \log n)\)	선형 로그	정렬 (비교 기반 하한)
\(O(n^2)\)	제곱	단순 정렬, 행렬 곱
\(O(2^n)\)	지수	부분집합 생성
\(O(n!)\)	팩토리얼	순열 생성

\(n = 10^6\) (백만) 일 때:

\(O(n \log n) \approx 2 \times 10^7\) — 0.02 초
\(O(n^2) \approx 10^{12}\) — 17 분
\(O(2^n)\) — 우주의 나이 곱하기 우주의 나이

같은 문제 의 알고리즘 선택 하나로 현실적으로 풀리느냐 안 풀리느냐 가 결정된다.

4-3. 알고리즘 설계의 5 가지 큰 패러다임

(A) 분할 정복 (Divide and Conquer) — 큰 문제를 반으로 나눠 풀고 합침. 병합 정렬, 빠른 정렬, FFT.

(B) 동적 계획법 (DP) — 겹치는 부분 문제를 메모이제이션. 피보나치, 배낭, 편집 거리, 최단 경로.

(C) 탐욕 (Greedy) — 지금 순간 최선 을 반복. 최소 신장 트리(Kruskal/Prim), Huffman 코딩.

(D) 백트래킹 — 모든 선택지 시도 하며 막히면 되돌아감. N-Queen, 스도쿠.

(E) 분기 한정 (Branch and Bound) — 유망하지 않은 분기 가지치기. 최적화 문제.

“어떤 패러다임을 적용할까” 가 알고리즘 설계 의 제 1 결정. 이 다섯이 대부분의 문제를 분류 한다.

4-4. 정렬의 하한 — 우리가 더 빠르게 만들 수 없는 자리

비교 기반 정렬은 \(\Omega(n \log n)\) 이 *증명된 하한**. 더 빠르게 만들 수 없다. *결정 트리 모델로 수학적으로 증명. 비교 기반이 아닌 radix sort 같은 알고리즘은 \(O(n)\) 가능 — 단 비교 가능한 키 가 한정된 범위 라는 전제 가 필요.

“공짜 점심은 없다” 의 알고리즘 버전: *전제 없이 일반적인 더 빠른 정렬은 *수학적으로 불가능**.

4-5. 쿠팡 새벽 배송 — TSP 의 친척 이 매일 밤 돌아간다

외판원 문제 (TSP) 는 NP-hard 의 대표. 완벽한 답 은 100 도시만 돼도 우주의 나이가 걸린다. 그런데 쿠팡·마켓컬리·SSG 의 새벽 배송 라우팅 은 매일 수백·수천 도시 (배송지) 의 *최적 경로 를 몇 시간 안에 풀어야 한다. 답이 *완벽하지 않아도 OK — 5% 만 절약해도 연간 수십억 원**. *근사 알고리즘 (Christofides, Lin-Kernighan, 메타휴리스틱 simulated annealing) + 실시간 교통 데이터 의 조합이 NP-hard 와 *현실의 타협. 컴퓨터과학의 가장 비싸지만 실용적 인 적용 사례.

4-6. 실무

DB 인덱스 = B-tree 의 자료구조 + log n 탐색 알고리즘. 없으면 \(O(n)\) 풀스캔, 있으면 \(O(\log n)\). 100 만 row 의 차이가 *수십만 배**
그래프 최단 경로 — Dijkstra (양수 가중치) vs Bellman-Ford (음수) vs A* (휴리스틱). 문제의 모양에 따라 다른 알고리즘
ML 의 gradient descent — 지역 최적해 에 빠질 수 있는 탐욕적 알고리즘. 그 한계를 알고 다른 시드로 여러 번 돌리는 휴리스틱이 정공

📖 입문 한 권: CLRS (Introduction to Algorithms, Cormen·Leiserson·Rivest·Stein). 전 세계 학부 표준 교과서. 한국어 번역 있음. 너무 두꺼우면 Algorithm Design Manual (Skiena) 도 정공.

⚠️ 흔한 오해: “Big-O 만 보면 알고리즘 선택 끝”. 사실 — Big-O 는 *입력 크기 가 무한대 일 때 의 점근 분석. n=100 정도에선 *상수 인자, 캐시 지역성, 분기 예측 이 더 중요. quicksort 의 \(O(n^2)\) 최악 < merge sort 의 \(O(n \log n)\) 보다 quicksort 가 더 빠른 게 보통. 현실 의 상수 가 이론 의 차수 를 이긴다.

5. 운영체제 — 하드웨어를 추상화하고 자원을 관리

“Simplicity is prerequisite for reliability.” — Edsger Dijkstra

5-1. 답하는 질문

“여러 프로그램이 *같은 하드웨어를 공유 하면서 서로 방해하지 않고 / 공정하게 / 효율적으로 작동 할 수 있게 하는 방법은 무엇인가?”*

운영체제는 하드웨어와 사용자 프로그램 사이의 통역사. CPU·메모리·디스크·네트워크 카드 같은 희소 자원 을 수십 개의 동시 프로세스 에게 공정하게 분배. 없으면 *모든 프로그램이 직접 하드웨어를 만져야 함 — 충돌과 비효율의 지옥*.

5-2. 핵심 추상화 4 가지

(A) 프로세스 (Process) — 하나의 CPU 가 *여러 프로그램을 동시 실행 하는 것처럼 보이게. 실제로는 *수 ms 단위로 빠르게 전환 (context switch). 사용자에겐 각 프로그램이 자기 전용 CPU 를 가진 환상.

(B) 가상 메모리 (Virtual Memory) — 각 프로세스가 *자기 전용 4GB / 256TB 의 주소 공간 을 가진 것처럼 보이게. 실제로는 *실 RAM 은 더 작고 일부는 디스크에 있을 수도. 페이지 테이블 이 가상 주소 → 물리 주소 변환. 프로세스 간 메모리 격리 의 기반.

(C) 파일 시스템 (File System) — 디스크의 *섹터·트랙 같은 물리 구조를 숨기고 파일·디렉토리 라는 논리 만 보임. ext4, XFS, ZFS, NTFS 등 *수십 종. 각자 내결함성 / 성능 / 압축 등 다른 trade-off.

(D) 시스템 콜 (System Call) — 사용자 프로그램과 커널의 경계. read, write, fork, mmap. 이 몇 십 개의 인터페이스 가 수억 개의 응용 프로그램과 수십 개의 OS 의 만남 을 가능케 함.

5-3. 스케줄링 — 공정성 vs 효율성 의 정치학

CPU 가 1 개이고 프로세스 100 개일 때 누구에게 얼마나 시간을 줄 것인가:

FCFS (먼저 온 순) — 단순. 짧은 작업이 긴 작업 뒤에서 굶음
Round Robin — 시간 균등 분할. 공정하지만 컨텍스트 스위치 비용
Multilevel Feedback Queue — 우선순위 동적 조정. Linux CFS 의 조상
Linux CFS (Completely Fair Scheduler) — “가장 적게 받은 프로세스” 우선. RB-tree 기반

공정의 정의 가 정치학과 닮았다. 짧은 작업 우선 이 공정인가, 대기 시간 평균 최소화 가 공정인가, 우선순위 높은 사용자 우선 이 공정인가. 정답이 없다 — trade-off.

5-4. 동시성 — 교착 / 경쟁 상태

여러 프로세스가 공유 자원에 접근 하면 발생하는 고전 문제:

Race Condition — 실행 순서에 따라 결과 달라짐
Deadlock — 서로의 자원을 기다리며 영원히 멈춤
Starvation — 우선순위 낮은 작업이 영원히 실행 안 됨

Edsger Dijkstra 의 1965 년 Semaphore 가 첫 해결책. 이후 Monitor, Mutex, Lock-free, Software Transactional Memory 까지 60 년의 진화. Go 의 goroutine + channel, Rust 의 ownership system 이 최근 진화의 정점.

5-5. Dijkstra 의 식사하는 철학자들** — 동시성 의 우화

Dijkstra 가 1965 년 강의 에서 만든 가르침. 5 명의 철학자가 원탁 에 둘러앉아 *밥과 생각만 번갈아 한다. 각자 옆 사람 과 포크 1 개를 공유. 밥 먹으려면 왼쪽 + 오른쪽 포크 둘 다 필요. 모두가 동시에 왼쪽 포크 를 들면 — 모두가 오른쪽 포크 를 기다리며 영원히 굶는다 (deadlock). 해결책 의 다양성 (포크 들기 순서 고정, 한 번에 N-1 명만 시도, 중재자 도입…) 이 동시성 의 모든 해법 의 *원형**. 60 년이 지나 *Go 의 channel, Rust 의 Send/Sync trait 까지 — 이 우화 의 변형.

5-6. 실무

Kubernetes 의 노드 = 가상 OS. Pod 가 *프로세스의 추상화. cgroup + namespace 가 *기존 Linux 의 격리 메커니즘 위에 *컨테이너 라는 새 추상화를 얹음
DB connection pool — 프로세스 / 스레드 의 트레이드오프 의 응용. 연결 비용 ↔ 메모리 비용
NUMA / CPU affinity 튜닝 — cache line / locality 를 의식한 스케줄링. 고성능 시스템 의 필수

📖 입문 한 권: Operating Systems: Three Easy Pieces (Remzi & Andrea Arpaci-Dusseau). 무료 PDF. 가상화 / 동시성 / 영속성 세 부분 구성이 우아함. 영문 원서지만 가독성 좋음.

⚠️ 흔한 오해: “멀티스레드 = 무조건 빠름”. 사실 — 동시성 ≠ 병렬성. CPU 가 1 코어 면 스레드 N 개 = 단순 시분할 + 컨텍스트 스위치 비용. I/O 바운드 작업 만 빠르다. CPU 바운드 작업 은 코어 수 = 한계. 스레드 더 만들면 *오히려 느려짐. Amdahl 의 법칙 — 직렬 부분 의 비율 이 병렬화 의 한계.

6. 자료구조 — 정보를 어떻게 표현* 할 것인가*

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” — Linus Torvalds

6-1. 답하는 질문

“같은 데이터 를 *다르게 저장 하면 처리 비용 이 어떻게 달라지는가? 조회·삽입·삭제·정렬 에서 어느 작업을 빠르게 / 어느 작업을 느리게 하는 게 우리 문제에 맞는 trade-off 인가?”*

알고리즘이 처리 *순서, 자료구조는 처리 *대상의 형태**. 같은 알고리즘 도 *자료구조 가 다르면 성능 이 *100 배 차이*.

6-2. 핵심 자료구조 7 종

자료구조	조회	삽입	삭제	강점
배열 (Array)	\(O(1)\)	\(O(n)\)	\(O(n)\)	고정 크기 + 캐시 친화
연결 리스트	\(O(n)\)	\(O(1)\)	\(O(1)\)	동적 크기 + 임의 삽입/삭제
스택 / 큐	\(O(n)\)	\(O(1)\)	\(O(1)\)	순서 의미 부여
해시 테이블	\(O(1)\) 평균	\(O(1)\)	\(O(1)\)	키 기반 즉시 lookup
트리 (BST, AVL, RB)	\(O(\log n)\)	\(O(\log n)\)	\(O(\log n)\)	정렬된 키 + 범위 검색
힙 (Heap)	\(O(1)\) (최소/최대)	\(O(\log n)\)	\(O(\log n)\)	우선순위
그래프 (Graph)	가변	가변	가변	관계 표현

공짜 점심은 없다: 해시 테이블이 모든 작업 \(O(1)\) — 하지만 순서 가 없음. 범위 검색 (“나이 20~30”) 불가능. 트리는 순서가 있는 대신 \(O(\log n)\). 조회 한 가지를 빠르게 만들면 다른 무언가가 느려진다.

6-3. 트리 — 세상의 위계 구조 를 닮은 추상

자연계의 모든 위계 는 트리. 분류학 (계-문-강-목-과-속-종), 파일 시스템 디렉토리, 조직도, HTML DOM, 컴파일러 의 AST. 데이터의 자연스러운 모양 이 트리인 경우가 압도적.

특수 트리들:

B-tree / B+-tree — DB 인덱스 의 사실상 표준. 디스크 I/O 최소화 위해 노드 당 다수 키
Trie — 문자열 prefix 검색. 자동완성 / 사전
Segment Tree — 구간 합 / 구간 최댓값 \(O(\log n)\)
Merkle Tree — 변경 감지. Git, Bitcoin, IPFS

6-4. 해시 — 충돌 의 우주

해시 테이블의 핵심: 해시 함수 가 *입력 → 작은 정수 (인덱스) 매핑. *서로 다른 입력이 같은 인덱스 로 가는 게 충돌. 충돌 처리 방식:

Open Addressing — 충돌 시 다음 빈 칸 으로
Chaining — 같은 인덱스에 연결 리스트 저장
Cuckoo Hashing — 두 개의 해시 함수 사용, 충돌 시 기존 entry 추방

Load Factor (저장된 entry / 전체 슬롯) 가 0.7 넘어가면 성능 급락. 동적 리해싱 (resize) 이 필요.

해시 함수 의 품질 이 결정적: SHA-256 같은 암호학적 해시 와 프로그래밍 언어 의 hashCode() 같은 비암호학적 해시 는 목적이 완전히 다름. 잘못 쓰면 해시 충돌 공격 으로 전체 서비스 마비.

6-5. 그래프 — 관계 의 표현

점 (정점) + 선 (엣지). 모든 네트워크 적 사고가 그래프로 환원: 친구 관계, 도로망, 의존성 (DAG), 회로, 신경망.

표현 방식:

인접 행렬 — \(O(V^2)\) 공간. 밀집 그래프 에 좋음
인접 리스트 — \(O(V + E)\) 공간. 희소 그래프 에 좋음

알고리즘 풀:

DFS / BFS — 모든 정점 방문
Dijkstra / Bellman-Ford / A* — 최단 경로
Kruskal / Prim — 최소 신장 트리
PageRank — 그래프 위 *확률적 위치 — 구글의 출발점

6-6. NAVER 자동완성 — Trie 가 매일 수억 번 돌아간다

“파” 입력 → “파리바게뜨, 파스타, 파주 시청…“. NAVER / 다음 / Google 의 자동완성은 Trie (트라이) 자료구조 의 응용. 문자 트리 에서 prefix 매칭 이 O(입력 길이). 검색어가 수억 개 라도 입력 한 글자에 O(1)~O(k). 해시 테이블 로는 prefix 검색 불가능. 자료구조 선택 한 번 이 수억 명의 검색 경험 을 결정한다.

6-7. 실무

Redis 의 ZSET — 해시 + 스킵 리스트 조합. 키 기반 \(O(1)\) lookup + 정렬된 범위 \(O(\log n)\). *해시 트리의 *합성**
Neo4j 같은 그래프 DB — 관계 가 *1 등 시민. 친구의 친구 같은 쿼리가 조인 폭발 없이 자연스러움
DB 인덱스 선택 — 어떤 컬럼 / 어느 자료구조 (B-tree, hash, GIN, GIST) 가 *우리 쿼리 패턴 에 맞나. 인덱스 잘못 잡으면 *오히려 느려짐

📖 입문 한 권: Algorithms (Sedgewick & Wayne, Princeton). 코드 와 *시각화 가 매우 잘 짜인 입문. Coursera 무료 강의도 있음. CLRS 가 어렵게 느껴지면 이 책부터.

⚠️ 흔한 오해: “해시 가 무조건 트리보다 빠르다”. 사실 — 해시 는 *키 정확 일치 만 \(O(1)\). *범위 쿼리 (“나이 20~30”), 정렬된 순회, prefix 검색 은 해시로 불가능 또는 \(O(n)\). DB 인덱스 가 *주로 B-tree 인 이유 — *현실 의 쿼리 는 *범위/정렬 이 많다**.

7. 프로그래밍언어 — 인간 의 의도를 컴퓨터가 실행할 수 있는 형태로 번역

“A language that doesn’t affect the way you think about programming is not worth knowing.” — Alan Perlis

7-1. 답하는 질문

“인간 이 생각하는 *비형식적·맥락 의존적 의도 를, 컴퓨터 가 정확히 / 명료하게 / 안전하게 실행할 수 있는 형식적 문장 으로 어떻게 표현 할 것인가? 그 표현 의 한계와 가능성 은 무엇인가?”*

프로그래밍언어는 언어학 + 수학 + 컴퓨터과학 의 교차점. 자연어와 다르게 모든 문장 의 의미가 *명확 해야 함. 모호성 0.

7-2. 언어 의 4 가지 큰 패러다임

(A) 명령형 (Imperative) — 컴퓨터에게 *순서대로 시킨다. C, Pascal, Go. 기계의 모델 (메모리·레지스터) 에 가까움.

(B) 객체지향 (OO) — 데이터 + 행위 의 캡슐화. Java, C++, C#, Smalltalk. 복잡한 상태 의 *조직화.

(C) 함수형 (Functional) — 불변 + 순수 함수 의 합성. Haskell, Lisp, ML, Erlang. 수학적 우주. 부수 효과 가 *명시적.

(D) 선언형 (Declarative) — “무엇” 만 적고 *어떻게 는 시스템에 맡김. SQL, Prolog, HTML/CSS. *문제 의 *모델 만 표현.

어떤 언어 가 정답? 없다. 문제의 성격 에 맞는 언어 가 다르다. DB 쿼리는 SQL (선언형), 운영체제는 C (명령형), 컴파일러는 ML (함수형), GUI 는 OO 가 *역사적으로 잘 맞음.

7-3. 타입 시스템 — 실행 전에 실수* 를 잡는 시스템*

Static typing (Java, Rust, Haskell) vs Dynamic typing (Python, JS, Ruby) 의 대립:

Static — 컴파일 시 타입 체크. 실행 전 많은 버그 발견. 느린 prototyping
Dynamic — 런타임 타입 체크. 빠른 prototyping. 프로덕션 사고 위험

최근 트렌드 — Gradual typing (TypeScript, Python 의 type hint). 둘의 trade-off 를 *프로젝트 부분 별로 다르게 선택*.

타입 시스템의 깊은 진실: 타입 = 증명. Curry-Howard correspondence — 프로그램의 타입 = 정리, 프로그램 = 그 정리의 증명. 수학과 컴퓨터과학의 *놀라운 동형 사상. Haskell, Coq, Idris 같은 언어 가 이 원리 위에 정확성을 *수학적으로 증명할 수 있는 코드 를 만든다*.

7-4. 컴파일 vs 인터프리트

컴파일 언어: 소스 → 기계어 변환 후 실행 (C, Rust, Go). 빠른 실행 / 느린 개발 사이클
인터프리트 언어: 소스를 한 줄씩 해석 후 실행 (Python, Ruby, Bash). 느린 실행 / 빠른 개발
JIT (Just-In-Time): 런타임에 자주 쓰이는 부분만 컴파일 (Java JVM, V8 JS). 두 세계의 절충

하드웨어 가까울수록 컴파일, 사용자 가까울수록 인터프리트 가 경험칙.

7-5. 메모리 관리 — 언어의 영혼**

누가 메모리 해제 책임지는가:

수동 (C, C++) — 개발자가 직접 malloc / free. 최고 성능, 최대 위험 (use-after-free, leak)
가비지 컬렉터 (Java, Go, Python) — 런타임이 안 쓰는 메모리 자동 회수. 안전 + GC pause
소유권 시스템 (Rust) — 컴파일러 가 *수명 을 추적, 해제 시점을 자동 결정. GC 없이 안전. Rust 의 결정적 기여

이 셋의 차이가 현대 언어 선택 의 가장 큰 분기점.

Rust 의 소유권 이 어떻게 컴파일 타임에 사용 후 해제 (use-after-free) 를 막는지 한 줄로 보면:

let s1 = String::from("hello");
let s2 = s1;             // s1 의 소유권이 s2 로 이동
println!("{}", s1);      // 컴파일 에러! s1 은 더 이상 유효하지 않음

C 라면 *런타임에 사고, Java 라면 GC 가 알아서, Rust 는 컴파일러 가 *못 컴파일 시킴. *세 패러다임 의 *철학적 차이 가 한 예제 에 응축*.

7-6. Tony Hoare 의 10 억 달러 실수 — null 이 짊어진 비용

Tony Hoare 가 2009 년 한 학회 에서 공개 사과. “1965 년 ALGOL W 에 *null 참조 를 도입한 것 — 나의 10 억 달러짜리 실수“. 이후 *수십 년 동안 NullPointerException 으로 일어난 모든 사고 의 *지구 총 비용**. *Kotlin 의 nullable 타입 (String?), Rust 의 Option<T>, Swift 의 옵셔널 — Hoare 의 사과 를 *언어 차원에서 보상한 결과. 한국에서 Java → Kotlin 전환 이후 NPE 가 사라졌다 는 보고가 흔한 이유. 언어 의 한 결정 이 *수십 년 의 비용 을 만든다*.

7-7. 실무

Spring Boot 의 DI 컨테이너 — 언어의 모자란 표현력 (메타프로그래밍) 을 프레임워크 가 보완
Kotlin null safety — 위의 Hoare 의 10 억 달러 실수 가 일상에서 사라지는 모습
DSL (도메인 특화 언어) — 특정 문제 에만 *최적화 된 작은 언어 만들기. SQL, Regex, Terraform HCL

📖 입문 한 권: Crafting Interpreters (Robert Nystrom, 무료 온라인). 직접 인터프리터 / 컴파일러 를 만들면서 언어 의 본질을 익힘. 또는 Structure and Interpretation of Computer Programs (SICP) — 좀 더 추상적이지만 프로그래밍 의 깊이.

⚠️ 흔한 오해: “동적 타입 = 자유, 정적 타입 = 답답”. 사실 — 동적 타입 의 *자유 는 런타임 의 *비용** 으로 갚는다. 1 만 줄 넘는 프로젝트 에서 동적 언어 (Python, JS) 가 정적 언어 (TS, Kotlin) 보다 유지보수 비용 이 *2~3 배. MyPy, TypeScript 같은 점진적 타입 의 등장 은 *이 비용 의 *지각된 결과**.

8. 7 분야의 상호 의존 — 어느 하나만 보면 불완전

각 분야 가 독립 해 보이지만, production 사고 는 반드시 두 분야의 경계 에서 터진다. 몇 가지 예:

사고 양상	표면	진짜 원인	보아야 할 분야
DB 쿼리 느림	“SQL 느려요”	B-tree depth 증가 + page fault	자료구조 + 운영체제
마이크로서비스 장애 전파	“전체 다운”	retry storm + thundering herd	네트워크 + 알고리즘 + SE
메모리 누수	“OOM 죽음”	캐시의 reference 가 GC 못 회수	프로그래밍언어 + 자료구조
동시성 race	“가끔 데이터 깨짐”	TCP 비순서 + happens-before 미정의	네트워크 + 운영체제 + 언어
ML 학습 발산	“loss = NaN”	float overflow + 알고리즘 의 numerical instability	알고리즘 + 자료구조 + 언어
K8s 배포 실패	“pod CrashLoop”	volumeClaimTemplates immutable	운영체제 (file system) + SE 컨벤션

“한 분야의 전문가” 가 다른 분야 를 모르면 *진짜 원인 까지 도달 못 한다. *깊은 전문성 + 7 분야 의 *공통 어휘** 가 *시니어 의 정의.

9. 공통 깊은 진실 — 7 분야 가 결국 답하는 같은 질문

이 글의 결론에 다다른다. 7 분야 의 표면이 달라 보여도 *밑바닥의 같은 진실 을 다른 각도에서 본다*:

9-1. trade-off 의 체계화

공짜 점심은 없다. 모든 분야의 모든 발견 은 무엇을 얻고 무엇을 잃는지 의 수학적·실용적 정리.

🩺 실제 사고: 2017 년 AWS S3 장애 — us-east-1 의 *한 컨트롤 시스템 의 작업 도중 전체 region 영향. CAP 의 P (분단 허용성) 를 *내부 시스템에도 적용하지 않은 결과. *Amazon 도 *완전한 격리 를 만들지 못한다. 우리가 잊지 말아야 할 가르침.

분야	핵심 trade-off	정리 이름
계산이론	시간 ↔ 공간 / 정확도 ↔ 다항 시간	P vs NP, 정지 문제, Rice 정리
네트워크	일관성 ↔ 가용성 ↔ 분단 허용	CAP 정리, FLP 정리
소프트웨어공학	추상화 ↔ 디버깅 / 속도 ↔ 유지보수	Brooks’ Law, Conway’s Law
알고리즘	시간 ↔ 공간 / 정확도 ↔ 단순함	정렬 \(\Omega(n \log n)\) 하한, NP-hardness
운영체제	격리 ↔ 효율 / 공정성 ↔ 응답성	Amdahl’s Law, 우선순위 역전
자료구조	조회 ↔ 수정 / 메모리 ↔ 속도	Cache-Oblivious 한계
프로그래밍언어	표현력 ↔ 안전성 / 추상 ↔ 성능	Curry-Howard 동형, Rice 정리

“trade-off 가 있다는 사실 자체” 를 *수학적으로 증명 하는 게 컴퓨터과학의 핵심 작업. *“이걸 *동시에 만족할 수 없다” 의 증명 (CAP, FLP, P vs NP, Halting) 이 분야의 정점.

9-2. 추상화의 층층 쌓기

   사용자 화면 (오늘 우리가 산다)
        ↑
   React / Vue / Spring Boot          ← 응용 프레임워크
        ↑
   TypeScript / Java / Python         ← 프로그래밍 언어
        ↑
   HTTP / GraphQL / SQL                ← 표준 프로토콜
        ↑
   TCP / UDP / TLS                     ← 전송 계층
        ↑
   IP 패킷                              ← 네트워크 계층
        ↑
   POSIX / system call                  ← 운영체제 인터페이스
        ↑
   커널 (가상 메모리 / 스케줄러)      ← 운영체제
        ↑
   어셈블리 / 명령어 집합 (ISA)        ← CPU 명세
        ↑
   마이크로아키텍처 (캐시 / 파이프라인) ← CPU 내부
        ↑
   논리 게이트 (AND / OR / NOT)        ← 디지털 회로
        ↑
   트랜지스터                            ← 반도체
        ↑
   양자역학 (전자의 흐름)               ← 물리 세계 (출발점)

우리는 추상화의 100 층 빌딩 *맨 꼭대기 에 살고 있다. 아래층을 *모르고도 살 수 있게 *건축 한 게 컴퓨터과학의 진짜 업적. 추상화가 깨지는 자리 — leaky abstraction (Joel Spolsky) — 가 production 사고의 자리.

🩺 실제 사고: 2024 년 CrowdStrike 의 전세계 Windows 블루스크린 사태 — 커널 모드 드라이버 의 한 잘못된 업데이트 가 Microsoft 의 모든 추상화 위에서 동시 무너짐. 수백만 PC 가 동시에 정지. *Joel Spolsky 의 *모든 추상화 는 *결국 새어 나간다** 의 거대한 사례.

9-3. 형식과 의미 의 영원한 거리**

인간 의 *의도 는 자연어, 컴퓨터의 실행 은 형식. 둘 사이 *번역의 손실 은 영원히 0 이 되지 않는다. 프로그래밍언어, 명세, 테스트, 코드 리뷰, AI assistant 까지 — 모두 이 거리를 좁히는 도구. 완전 폐색은 불가능 (정지 문제 가 이를 증명).

🩺 실제 사고: 1996 년 Ariane 5 로켓 폭발. 원인은 *32 비트 부동 소수점 → 16 비트 정수 변환 의 *오버플로**. Ada 코드 한 줄 — 형식적으로 옳지만 *명세 (의미) 와 다른 환경에서 재사용. 5 억 달러 + 위성 손실. 한 정수 변환 의 *의미 누락 이 우주 발사 의 실패 가 됐다*.

9-4. 우리는 자연 처럼 발견된 세계* 를 다루지만 그 세계는 *우리가 만들었다**

이 역설 이 컴퓨터과학의 가장 아름다운 모순. 튜링이 1936 년에 발견한 정지 문제 의 불가해성은 2026 년의 GPT 도, 100 년 후의 양자 컴퓨터 도 깨지 못한다. 우리가 만들었지만 우리가 *벗어날 수 없다. 이게 컴퓨터과학이 진짜 *과학 인 이유*.

💡 깊은 함의: AI 가 모든 코드를 자동 생성 할 수 있게 돼도 — 정지 문제 의 한계 때문에 모든 코드의 정확성을 *완전히 자동 검증 할 수는 없다. *인간 의 판단이 *체계적으로 필요한 자리 가 영원히 남는다*. *컴퓨터과학 의 발견 이 *우리 직업 의 *마지막 안전망** 인 셈.

10. 학습 로드맵 — 얕게 7 + 깊게 1 의 실천

너무 큰 영역을 한 번에 정복 하려 들면 좌절한다. 순서가 있다:

10-1. 권장 학습 순서 (3 년 이상)

시기	집중	책 한 권
1 단계	알고리즘 + 자료구조 (둘은 같이 학습)	Sedgewick Algorithms 또는 CLRS
2 단계	운영체제 (OS 의 추상화 가 모든 다른 분야 의 기초)	OS: Three Easy Pieces
3 단계	네트워크 (HTTP / TCP / DNS — 우리가 매일 마주치는 것)	Tanenbaum Computer Networks
4 단계	소프트웨어공학 (조직 의 패턴 — 책 보다 경험* 으로)	Brooks Mythical Man-Month + 실무
5 단계	프로그래밍언어 패러다임 (다른 패러다임 3 개 이상 익히기)	Crafting Interpreters + SICP
6 단계	계산이론 (가장 추상적, 가장 마지막)	Sipser
7 단계	깊이 1 선택 (평생 한 분야 를 깊게)	(개인 선택)

10-2. 각 분야 의 최소 어휘 만이라도** — 한 줄 정리

NP-hard 가 들리면 “근사 / 휴리스틱 으로 가야 한다” 즉시 떠올림
CAP 가 들리면 “P 는 불가피, C 와 A 중 선택” 즉시 떠올림
Brooks’ Law 가 들리면 “늦은 프로젝트에 사람을 더 넣지 마” 즉시 떠올림
Big-O 가 들리면 “입력 크기에 따른 시간 증가율” 즉시 떠올림
page fault 가 들리면 “가상 메모리 의 디스크 폴백” 즉시 떠올림
B-tree 가 들리면 “디스크 친화적 정렬된 검색” 즉시 떠올림
type system 이 들리면 “실행 전 버그 잡기” 즉시 떠올림

이 공통 어휘 만이라도 7 분야 다 가지면 — production 사고 의 *진짜 원인 까지 도달 할 수 있는 시니어 의 자격.

마무리 — “세상의 법칙을 발견하는 자” 라는 정체성

“세상이 어떻게 작동하는지 *설명하고 예측하는 것”* — 이 정의가 컴퓨터과학 의 7 분야 를 *통합 한다. 각자 다른 질문 에 답하지만 결국 우리가 만든 디지털 우주 의 *불변하는 법칙 을 발견. *trade-off 의 체계화, 추상화의 쌓기, 형식과 의미의 거리 — 셋이 모든 분야의 깊은 공통 진실.

이 7 분야 의 어느 하나에 인생을 걸어도 한 평생 부족하다. 다만 다른 6 분야와 공통의 어휘 를 가지지 못한 전문성 은 production 의 진짜 문제 앞에 무력해진다. 깊게 1 + 얕게 7 — 이게 시니어 의 본질.

우리가 코딩 한다 할 때 — 알고리즘 (4) 을 자료구조 (6) 위에 짜서, 프로그래밍언어 (7) 로 표현하고, 운영체제 (5) 위에서 실행되며, 네트워크 (2) 로 통신하고, 소프트웨어공학 (3) 의 조직으로 협업하며, 계산이론 (1) 의 한계 안에서 살아간다. 한 줄 코드를 짤 때마다 7 분야 가 동시에 등장한다. 이걸 의식하면 시니어, 의식하지 못하면 영원한 주니어.

“컴퓨터과학자는 *발견된 우주 안에서 또 다른 우주를 발견 한다”* — 자연과학자가 우주의 법칙을 발견하듯 우리는 우리가 만든 우주의 법칙 을 발견한다. 이 발견 의 7 가지 다른 각도가 바로 이 글의 7 절. 그 어느 하나도 과학 의 자리 에서 빠질 수 없다.

“세상이 어떻게 작동하는지 설명하고 예측하는 것” — 이 한 문장이 우리 직업 의 자부심 의 근거. 코드 한 줄 의 뒤에 *100 년의 발견 이 있다. 그 발견을 *알고 짜는 것 이 컴퓨터과학자 의 정체성이다.