컴퓨터 과학을 왜 알아야 하는가

CS는 면접 문제가 아니라 개발자의 기본 체력이다

많은 개발자가 컴퓨터 과학, 줄여서 CS를 처음 만나는 순간은 면접 준비일 때가 많다. 스택과 큐, 프로세스와 스레드, TCP와 UDP, 정규화와 인덱스 같은 단어를 외우고 문제를 푼다. 하지만 실무에 들어가면 CS는 훨씬 현실적인 모습으로 다시 나타난다.

서비스가 갑자기 느려진다. 같은 코드인데 어떤 서버에서만 장애가 난다. 데이터베이스 쿼리는 맞는데 응답 시간이 10초를 넘는다. 배포 후 메모리 사용량이 계속 증가한다. 특정 시간대에만 API 타임아웃이 발생한다. 이런 문제는 프레임워크 문서만 읽어서 해결하기 어렵다. 원인은 코드 한 줄이 아니라 메모리, CPU, 네트워크, 파일 시스템, 데이터 구조, 데이터베이스 잠금 같은 여러 층에 걸쳐 있기 때문이다.

CS는 이 층들을 이해하는 언어다. 컴퓨터가 데이터를 어떻게 표현하는지, 프로그램이 CPU에서 어떻게 실행되는지, 운영체제가 메모리를 어떻게 나누고 보호하는지, 네트워크는 왜 지연되고 끊기는지, 데이터베이스는 왜 인덱스를 써도 느릴 수 있는지 설명해 준다. 개발자가 CS를 알아야 하는 이유는 모든 이론을 외우기 위해서가 아니다. 문제를 만났을 때 어디를 의심해야 하는지, 어떤 선택이 비용을 만드는지 판단하기 위해서다.

AI 생성 이미지

프레임워크 사용법과 원리는 다르다

프레임워크 사용법은 "어떻게 쓰는가"에 가깝다. 예를 들어 웹 프레임워크에서 라우터를 등록하고, ORM으로 데이터를 조회하고, 캐시 라이브러리를 붙이는 방법은 사용법이다. 문서를 따라 하면 어느 정도 결과를 만들 수 있다.

반면 CS 원리는 "왜 그렇게 동작하는가"를 다룬다. ORM에서 findAll()을 호출했을 때 실제로 어떤 SQL이 실행되는지, 그 SQL이 인덱스를 타는지, 결과가 메모리에 얼마나 올라오는지, 네트워크 왕복이 몇 번 발생하는지 이해하는 것이 원리다.

예를 들어 게시글 목록 API를 만든다고 하자. 프레임워크 사용법만 보면 컨트롤러를 만들고, 서비스에서 게시글을 조회하고, JSON으로 응답하면 된다. 하지만 사용자가 늘어나면 다음 문제가 나타날 수 있다.

• 페이지 하나를 그리기 위해 게시글 20개와 작성자 정보를 각각 따로 조회한다.

• 쿼리 수가 게시글 개수에 비례해 증가한다.

• 데이터베이스 연결 풀이 가득 차고 API 응답이 늦어진다.

• 애플리케이션 서버 CPU 사용률은 낮은데 전체 서비스는 느리다.

이때 필요한 지식은 단순히 "이 ORM의 옵션 이름이 무엇인가"가 아니다. 자료구조 관점에서는 중복 조회를 줄이는 방법을 생각해야 하고, 데이터베이스 관점에서는 조인과 인덱스를 봐야 하며, 네트워크 관점에서는 왕복 횟수를 줄여야 한다. 운영체제 관점에서는 스레드가 I/O 대기 상태에 묶여 있는지도 볼 수 있다.

프레임워크는 생산성을 높여 준다. 하지만 프레임워크는 컴퓨터 위에서 동작한다. 추상화가 편리함을 주지만, 비용이 사라지는 것은 아니다. CS는 그 비용이 어디에서 생기는지 보게 해 준다.

버그와 장애는 여러 층에서 발생한다

실무의 문제는 대개 한 층에만 머물지 않는다. 코드에는 문제가 없어 보이지만 운영체제 설정 때문에 장애가 나기도 하고, 데이터베이스 설계가 네트워크 병목을 만들기도 한다. 몇 가지 흔한 상황을 보자.

첫째, 성능 저하는 자료구조 선택에서 시작될 수 있다. 사용자 ID로 데이터를 자주 찾는데 매번 배열 전체를 순회한다면 데이터가 적을 때는 문제가 없다. 하지만 데이터가 수십만 건이 되면 검색 시간이 눈에 띄게 늘어난다. 이때 해시 테이블을 쓰면 평균적으로 훨씬 빠르게 찾을 수 있다. 자료구조는 단순한 시험 문제가 아니라 데이터가 커졌을 때 시스템의 반응 속도를 바꾸는 선택이다.

둘째, 장애는 운영체제와 연결된다. 파일을 열고 닫지 않는 코드가 반복되면 파일 디스크립터가 고갈될 수 있다. 메모리를 계속 참조하는 객체가 남아 있으면 가비지 컬렉션이 있어도 메모리 사용량이 증가한다. 요청마다 스레드를 과도하게 만들면 문맥 교환 비용이 커져 CPU가 실제 작업보다 스레드 전환에 시간을 쓸 수 있다. 이런 문제는 "코드는 정상"처럼 보이지만 운영체제 자원 관점에서는 비정상이다.

셋째, 네트워크는 빠른 함수 호출이 아니다. 같은 데이터센터 안에서도 네트워크 호출은 메모리 접근보다 훨씬 느리고 실패할 수 있다. 타임아웃, 재시도, 패킷 손실, DNS 지연, TLS 핸드셰이크 같은 요소가 응답 시간을 만든다. 로컬 함수처럼 원격 API를 여러 번 호출하면 작은 지연이 쌓여 큰 지연이 된다.

넷째, 데이터베이스 문제는 저장소 구조와 동시성에서 온다. 인덱스가 없으면 데이터베이스는 많은 행을 훑어야 한다. 인덱스가 있어도 조건이 맞지 않으면 제대로 사용되지 않는다. 동시에 여러 요청이 같은 데이터를 수정하면 잠금이 걸리고, 트랜잭션 격리 수준에 따라 읽는 값이 달라질 수 있다. 데이터베이스는 단순한 저장 공간이 아니라 성능과 일관성 사이에서 균형을 잡는 시스템이다.

이처럼 버그, 장애, 성능 저하는 하드웨어·운영체제·네트워크·데이터 구조와 연결된다. 개발자가 CS를 안다는 것은 모든 내부 구현을 세부적으로 암기한다는 뜻이 아니다. 문제가 발생했을 때 "이 현상은 어느 층의 비용인가?"라고 질문할 수 있다는 뜻이다.

이 책에서 볼 CS 지도

이 책은 CS를 독립된 암기 과목으로 다루지 않는다. 개발자가 시스템을 이해하고 설계할 때 자주 마주치는 흐름을 따라간다.

이 영역들은 서로 떨어져 있지 않다. 예를 들어 API 서버가 느릴 때 자료구조만의 문제일 수도 있지만, 데이터베이스 인덱스 문제일 수도 있고, 네트워크 재시도 폭증일 수도 있으며, 스레드 풀이 고갈된 운영체제 자원 문제일 수도 있다. 좋은 개발자는 한 가지 원인에 바로 뛰어들지 않는다. 증상을 보고 가능한 원인 범위를 좁힌다.

그래서 이 책의 목표는 각 주제를 깊이 파고드는 백과사전이 되는 것이 아니다. 실무 개발자가 시스템을 읽는 데 필요한 핵심 개념을 연결하는 것이다. 각 장은 "이 개념이 왜 필요한가"에서 시작해, 실제 코드와 장애 상황에서 어떻게 드러나는지 설명한다.

외우기보다 판단 기준으로 사용하라

CS를 공부할 때 가장 흔한 실수는 용어를 외우는 데서 멈추는 것이다. 시간 복잡도 표를 외우고, TCP의 특징을 외우고, 트랜잭션의 ACID를 외울 수 있다. 하지만 실무에서 더 중요한 질문은 따로 있다.

• 이 데이터는 얼마나 커질 수 있는가?

• 이 작업은 CPU를 많이 쓰는가, I/O를 기다리는가?

• 이 호출은 몇 번의 네트워크 왕복을 만드는가?

• 이 저장 방식은 읽기에 유리한가, 쓰기에 유리한가?

• 장애가 나면 재시도해도 안전한가?

• 성능을 높이려면 캐시, 인덱스, 비동기 처리 중 무엇이 먼저인가?

이 질문에 답하려면 개념을 판단 기준으로 바꿔야 한다. 예를 들어 시간 복잡도는 알고리즘 시험을 위한 기호가 아니라 데이터가 커질 때 코드가 얼마나 빨리 느려지는지 예측하는 도구다. 트랜잭션은 데이터베이스 용어가 아니라 결제, 주문, 재고처럼 중간에 실패하면 안 되는 작업을 어떻게 묶을지 판단하는 기준이다. 암호화와 해시는 보안 시험 단어가 아니라 비밀번호 저장과 토큰 검증에서 절대 혼동하면 안 되는 도구다.

모든 CS 이론을 같은 깊이로 공부할 필요는 없다. 커널 개발자에게 필요한 지식과 웹 백엔드 개발자에게 필요한 지식은 다르다. 프론트엔드 개발자는 브라우저, 네트워크, 렌더링, 비동기 처리의 비중이 크고, 데이터 엔지니어는 저장소, 분산 처리, 일관성, 장애 복구의 비중이 크다. 중요한 것은 자신의 업무에서 자주 만나는 비용과 실패 지점을 설명할 수 있는 수준까지 이해하는 것이다.

좋은 설계는 보이지 않는 비용을 줄인다

설계는 코드 구조만의 문제가 아니다. 좋은 설계는 컴퓨터가 실제로 지불하는 비용을 고려한다. 메모리를 얼마나 쓰는지, 네트워크 호출이 얼마나 많은지, 데이터베이스에 어떤 부하를 주는지, 장애가 났을 때 어디까지 영향을 미치는지 생각한다.

예를 들어 단순한 기능 추가라도 다음과 같은 판단이 필요하다.

• 목록 화면에 필요한 데이터를 한 번에 가져올 것인가, 여러 API로 나눌 것인가?

• 자주 조회되는 값을 매번 계산할 것인가, 캐시할 것인가?

• 사용자 요청을 동기적으로 처리할 것인가, 메시지 큐에 넣고 비동기로 처리할 것인가?

• 하나의 큰 테이블에 저장할 것인가, 조회 패턴에 맞춰 나눌 것인가?

• 장애가 발생했을 때 실패를 사용자에게 바로 알릴 것인가, 재시도할 것인가?

이 질문에는 항상 정답이 하나만 있는 것은 아니다. 캐시는 빠르지만 오래된 데이터를 보여줄 수 있다. 비동기 처리는 응답을 빠르게 만들지만 처리 순서와 실패 복구가 어려워진다. 인덱스는 조회를 빠르게 하지만 쓰기 비용과 저장 공간을 늘린다. 분산 시스템은 확장성을 주지만 네트워크 실패와 데이터 불일치를 함께 가져온다.

CS는 이런 trade-off, 즉 한쪽을 얻으면 다른 쪽 비용이 생기는 관계를 이해하게 해 준다. 개발자의 일은 무조건 빠른 것, 무조건 최신 기술, 무조건 복잡한 구조를 고르는 것이 아니다. 현재 문제의 크기, 팀의 운영 능력, 장애 허용 범위, 데이터의 중요도를 보고 적절한 선택을 하는 것이다.

이 책을 읽는 방법

이 책의 각 장은 독립적으로 읽을 수 있지만, 전체 흐름은 하나의 시스템을 아래에서 위로 올라가며 이해하도록 구성되어 있다. 먼저 컴퓨터가 데이터를 표현하고 실행하는 방식을 본다. 그다음 자료구조와 알고리즘으로 코드 안의 선택을 이해한다. 운영체제와 메모리, 파일 시스템을 통해 프로그램이 자원을 사용하는 방식을 살핀다. 이후 네트워크, 웹, 데이터베이스, 트랜잭션, 분산 시스템으로 여러 컴퓨터가 함께 동작할 때 생기는 문제를 다룬다. 마지막에는 보안, 컴파일러, 성능 분석을 거쳐 실무 설계로 연결한다.

읽을 때 모든 세부 내용을 한 번에 외우려 하지 않아도 된다. 대신 각 장을 읽고 다음 세 가지 질문에 답해 보자.

1. 이 개념은 어떤 비용을 설명하는가?

2. 이 개념을 모르면 어떤 버그나 장애를 놓칠 수 있는가?

3. 실제 설계에서 어떤 선택 기준으로 사용할 수 있는가?

이 질문에 답할 수 있다면 CS는 더 이상 면접용 지식이 아니다. 코드를 더 정확히 읽고, 장애를 더 빨리 좁히고, 설계를 더 설득력 있게 설명하는 도구가 된다. 개발자의 실력은 문법과 라이브러리 사용법만으로 결정되지 않는다. 보이지 않는 실행 과정을 상상하고, 시스템의 비용을 예측하고, 상황에 맞는 선택을 할 수 있을 때 한 단계 성장한다.

이 책은 그 판단력을 만드는 데 필요한 기본 지도를 제공한다.