[Computer Terms] 00. 컴퓨터 용어 사전 개요와 읽는 법

이 컬렉션을 왜 만드는가

실무에서 마주치는 CS 용어는 대부분 한 문장짜리 정의만으로는 부족하다. “시간 복잡도가 O(n log n)이다"라는 문장을 이해하려면 그 정의가 어떤 문제(자원의 한계)를 풀기 위해 등장했는지, 다른 개념(공간 복잡도, 자료구조 선택)과 어떻게 이어지는지를 함께 알아야 실제 코드 리뷰나 설계 논의에서 판단 근거로 쓸 수 있다. Computer Terms 컬렉션은 이런 용어를 낱개로 나열하는 사전이 아니라, 알고리즘·자료구조·컴퓨터 구조·네트워크·운영체제·데이터베이스·분산시스템·동시성·캐싱·보안·웹/프로토콜·소프트웨어 설계·프로그래밍 언어론·개발 프로세스라는 14개 CS 대분류를 기준으로 빠진 영역 없이 채운 것을 목표로 한다.

챕터 구성과 필요성

컬렉션은 14개 갈래, 총 105챕터(이 개요 챕터 포함)로 구성된다. 알고리즘 갈래는 문제를 “어떻게 푸는가"와 “얼마나 잘 푸는가"를 다루고, 나머지 갈래는 “무엇으로 어떻게 만드는가"를 다룬다. 갈래를 나눈 이유는 실무에서 각 갈래가 서로 다른 판단 상황에서 쓰이기 때문이다. 알고리즘 갈래는 “이 코드가 왜 느린가"를 진단할 때, 그 외 갈래는 “이 시스템을 어떻게 구성해야 하는가"를 설계할 때 필요하다.

챕터 순서는 난이도가 아니라 의존 관계를 기준으로 정했다. 각 갈래는 기초 개념(예: 자료구조의 배열·연결리스트, 동시성의 레이스 컨디션·락)을 먼저 두고, 그 위에서만 이해되는 심화 주제(세그먼트 트리, ABA 문제 등)를 뒤에 배치했다. 갈래 사이의 순서도 마찬가지다 — 캐싱 갈래는 운영체제의 메모리 계층 개념을 전제로 운영체제 갈래 이후에, 분산시스템 갈래는 데이터베이스 갈래의 샤딩·복제를 전제로 그 다음에, 소프트웨어 설계 갈래의 디자인 패턴·리팩토링은 그 갈래 안의 결합도·응집도·SOLID를 전제로 마지막 순서에 둔다. 각 챕터 본문의 “이 장을 읽기 전에” 절에서 실제로 전제하는 선행 챕터를 명시하므로, 이 표의 순서를 따르지 않고 필요한 챕터만 골라 읽어도 그 절이 부족한 배경지식을 짚어준다.

처음부터 끝까지 순서대로 읽어야 하는 경우는 CS를 체계적으로 처음 배우거나, 면접·자격 검증처럼 전 영역을 고르게 점검해야 할 때다. 반대로 실무에서 당장 막힌 문제가 있다면(예: “레이스 컨디션이 뭔지 정확히 설명하고 싶다”) 표에서 해당 갈래·챕터만 찾아 “이 장을 읽기 전에” 절이 안내하는 선행 챕터만 골라 읽어도 충분하다 — 갈래 표는 순서대로 완주하는 커리큘럼이자, 필요한 부분만 찾아 쓰는 인덱스로 동시에 기능하도록 설계했다.

이 컬렉션이 다루지 않는 것

이 14개 갈래는 “실무 코드·시스템 설계 논의에서 바로 판단 근거로 쓰이는 용어"를 기준으로 골랐다. 그 결과 의도적으로 제외한 두 영역이 있다. 첫째, 이산수학·계산 복잡도 이론(NP-완전성 증명, 오토마타 이론, 형식 언어론 등) 같은 CS의 수학적 기초는 다루지 않는다. Teach Yourself CS는 오히려 수학을 프로그래밍·컴퓨터 구조와 나란히 놓인 9개 핵심 트랙 중 하나로 꼽으며 “아래 9개 과목을 모두, 대체로 제시된 순서로 공부하라"고 명시해 이 영역을 생략 가능한 것으로 보지 않는다. 이 컬렉션이 그와 별개로 수학을 빼는 이유는 TYCS의 판단이 틀려서가 아니라 스코프 자체가 다르기 때문이다 — TYCS는 “컴퓨터 과학을 체계적으로 독학하는 법"을 다루지만, 이 컬렉션은 “실무 코드·설계 논의에서 바로 쓰는 용어 사전"을 목표로 하며, 증명 중심 수학은 후자의 목표에 직접 기여하지 않는다. 둘째, AI·머신러닝(신경망 구조, 학습 알고리즘, 모델 서빙 등)도 다루지 않는다 — 그 자체로 별도 컬렉션이 필요할 만큼 범위가 넓고 빠르게 변하는 영역이라, 이 컬렉션의 스코프 밖에 둔다. 두 영역이 필요하다면 각각 이산수학/이론 전산학 교재나 TYCS의 Math for CS 트랙, 별도의 AI/ML 자료를 참고하길 권한다.

흔한 오개념

“이 컬렉션을 완독하면 시스템 설계 전문가가 된다” — 용어를 정확히 알고 판단 근거로 쓸 수 있게 되는 것과, 실제 트래픽·장애·비용 제약이 있는 프로덕션 시스템을 설계해본 경험은 다르다. 이 컬렉션은 “CAP 정리에서 CP·AP 중 무엇을 고를지” 같은 판단의 재료를 주는 것이지, 그 판단을 실전에서 반복하며 얻는 감각까지 대체하지는 못한다.

“용어를 안다는 것은 그 개념을 실무에 즉시 적용할 수 있다는 뜻이다” — 예를 들어 트랜잭션 격리 수준의 네 단계를 설명할 수 있는 것과, 실제 운영 중인 데이터베이스에서 어느 수준을 골라야 할지(성능과 이상 현상 사이의 트레이드오프를 그 서비스의 실제 요구사항에 맞춰 판단하는 것)는 별개의 능력이다. 이 컬렉션의 각 챕터가 “판단 기준”·“흔한 오개념” 절을 두는 이유가 이 간극을 좁히기 위해서지만, 완전히 없애지는 못한다.

이 컬렉션을 다 읽으면 할 수 있는 것

각 챕터는 정의를 암기시키는 대신, 그 용어가 실무 코드나 시스템 설계 논의에서 어떤 질문에 답하는 데 쓰이는지를 함께 다룬다. 컬렉션을 따라 읽으면 “이 알고리즘의 시간 복잡도를 정확히 표기하고 대안과 비교할 수 있다”, “트랜잭션이 깨지는 상황을 ACID 4속성 중 무엇이 실패했는지로 진단할 수 있다”, “결합도·응집도 기준으로 코드 리뷰에서 설계 문제를 구체적으로 지적할 수 있다”, “SQL 인젝션·XSS·CSRF가 각각 어떤 정상 메커니즘을 악용하는지 구분해 막을 수 있다”, “REST와 GraphQL 중 서비스 특성에 맞는 쪽을 근거를 갖고 선택할 수 있다”, “CAP 정리에서 CP와 AP 중 서비스 특성에 맞는 선택을 할 수 있다”, “락·세마포어·CAS 중 상황에 맞는 동시성 제어 도구를 고를 수 있다"처럼, 용어를 설명이 아니라 판단의 근거로 쓸 수 있게 되는 것을 목표로 한다.