온실 속 화초

30개 테이블 규모의 작은 서비스부터, 한 브랜드 전체의 운영을 떠받치는 플랫폼까지 만들고 운영하면서, 한 가지를 알게 됐습니다.

대학에서 배우는 방식은 온실 속 화초가 되기 딱 좋다는 것입니다.

실무가 교육과정 안에 있는 직업들

의대에서는 기초의학과 임상의학을 배운 뒤 병원에서 임상실습을 돕니다. 실제 환자를 만나 병력을 청취하고, 감별진단을 세우고, 그 판단을 검증받습니다. 약대생도 병원과 약국에서 실무실습을 거칩니다. 두 과정 모두 졸업 전에 실습을 이수하고 국가시험에 합격해야 면허를 받을 수 있습니다.

로스쿨 역시 판례와 사례로 법리를 익힌 뒤 모의재판과 실무수습에서 직접 쟁점을 분석하고 변론합니다. 교육과정을 마친 뒤에는 변호사시험을 통과해야 합니다.

의사, 약사, 변호사는 국가가 자격을 관리하는 전문직이므로 컴퓨터공학 교육과 조건이 다릅니다. 전문직 교육은 이론뿐 아니라 실제 또는 실제에 가까운 상황에서 판단하는 실무 훈련까지 정규 교육과정에 포함합니다.

컴퓨터공학 정규 교육에는 실무 훈련이 부족하다

컴퓨터공학 정규 교육에는 이론을 실제 시스템에 적용하는 훈련이 부족합니다. 학생들은 시스템 구조를 직접 설계하고 운영 결과를 확인하는 경험을 수업에서 충분히 얻지 못합니다. 많은 학생이 트래픽, 데이터 정합성, 장애 문제를 직접 다루고 설계 결정의 결과를 확인하는 훈련을 졸업 후에 시작합니다.

학생들은 인턴, 부트캠프, 사이드 프로젝트, 오픈소스, 입사 후 교육에서 실무를 따로 배웁니다. 정규 교육에 없는 실무 훈련을 제공하는 부트캠프와 각종 직무 교육 시장도 형성됐습니다.

”CS는 학문이지, 학원이 아니다”

반론도 있습니다.

“컴퓨터 과학은 개발 학원이 아니다. 학문을 배우는 곳이다.”

맞는 말입니다. CS는 학문이며 학위 과정 전체를 직업훈련으로 구성할 수는 없습니다. 그러나 많은 졸업생은 연구자가 아니라 엔지니어로 일합니다. 서비스를 만들고 회사의 비즈니스를 지탱하는 시스템을 구축하고 운영합니다.

컴퓨터 과학 이론을 가르치는 일은 필요하지만, 많은 학생이 엔지니어가 되는 만큼 배운 이론으로 실제 시스템을 판단하는 훈련도 교육과정에 포함해야 합니다. 지금은 그런 기회가 부족해 학생들이 졸업 후 개인의 시간과 비용을 들여 실무를 배웁니다.

여러 전문가가 검토하고 반박하며 수정한 교육과정이 있다면, 학생은 오류가 줄어든 내용을 더 짧은 시간에 배울 수 있습니다. 정규 교육과정 밖의 학습에는 통일된 검토 절차가 없으며, 교육 내용의 품질도 제공자마다 다릅니다. 학습자는 잘못된 내용을 직접 걸러내고 이미 알려진 시행착오를 반복하는 데 시간을 씁니다. 회사도 입사 후 같은 내용을 다시 가르치느라 시간과 비용을 씁니다. 소프트웨어가 대부분의 산업에 필수인 지금, 개인과 회사가 반복해서 치르는 이 비용은 사회 전체에도 적지 않은 부담일 것입니다.

현실의 시스템은 외워둔 것만으로 풀리지 않는다

• CPU 사용률은 낮은데 서비스는 터질 수 있습니다.
• 트랜잭션은 성공했는데 정합성은 깨져 있을 수 있습니다.
• 같은 코드를 배포해도 환경 차이로 미묘하게 다르게 동작할 수 있습니다.

비슷한 장애를 겪어본 경험이 있어야 하고, 시스템이 왜 그렇게 움직이는지도 알아야 합니다.

지식의 편린

물론 “왜 이런 구조가 됐는가”를 직접적으로 다루는 커리큘럼이 아예 없는 건 아닙니다. 하지만 여전히 많은 커리큘럼에서 배우는 건 대개 결과입니다.

그 결과가 나오기까지의 온갖 시행착오를 덜어내고 아주 예쁘게 정제된 지식의 편린이죠.

• HTTP는 배우지만, 왜 HTTP가 등장했고 지금 같은 형태가 됐는지는 깊게 다루지 않습니다.
• 관계형 모델 이론은 배우지만, 동시성을 확보하면서 정합성을 지키기 위해 왜 MVCC라는 구조가 필요해졌는지는 뒤로 밀립니다.
• 프로그래밍 언어를 배우지만, 런타임이 왜 지금 같은 구조를 갖게 됐는지는 잘 다루지 않습니다.
• Linked List는 삽입/삭제가 O(1)이라고 배우지만, Big-O만으로 실제 성능을 설명할 수 없다는 것을 배우지는 않습니다.

우리는 이런 지식의 편린만 쥔 채 현장에 투입됩니다.

싸움의 기록

오늘날 우리가 사용하는 컴퓨팅 시스템은 처음부터 아름답게 설계된 결과물이 아닙니다. 수십 년간 엔지니어들이 장애를 막고, 병목을 뚫고, 데이터를 지키고, 조금이라도 더 빠르게 만들려고 악착같이 싸워온 기록에 가깝습니다.

결과를 외우게 하는 책이 아니라, 그 싸움을 다시 겪게 하는 책을 쓰고 싶습니다. 의대생이 임상실습으로 환자를 직접 만나보고, 로스쿨 학생이 모의재판으로 사건을 직접 다뤄보는 것처럼요.

프로그래밍 언어, 운영체제, 네트워크, DBMS, 분산 시스템을 정리하려는 게 아닙니다. 기술이 태어날 수밖에 없었던 이유에서 시작해, 그 질문에 답하려고 어떤 해결책이 등장했는지 따라가려고 합니다.

책 한 권으로 실제 운영 경험을 대신할 수 있다는 말은 아닙니다. 하지만 기술이 태어난 문제와 제약을 다시 따라가며 스스로 해결책을 생각해보는 과정은, 판단의 근거를 훈련하는 보완책이 될 수 있습니다.

LLM이 다 짜주는 시대라서, 더

Agentic Coding을 외면한 채 개발하기는 점점 어려워지고 있습니다. 물론 보안이나 규제가 중요한 영역에서는 사용 범위가 제한되거나, LLM이 만든 코드에 더 엄격한 검토와 검증이 필요합니다. 하지만 그 밖의 영역에서는 쓰지 않을 이유가 없습니다.

코드 생성은 빨라졌지만

코드 생성 속도가 그대로 생산성으로 이어진다면 좋겠지만, 현실은 그렇지 않습니다.

LLM은 입력과 학습된 맥락을 바탕으로 다음 토큰을 예측하며 코드를 생성합니다. 이 방식으로 실제로 쓸 수 있는 코드를 만들기도 하지만, 모델이 그 결과물이 우리 시스템의 요구사항과 제약을 만족하는지 검증한 뒤 내놓는 것은 아닙니다.

LLM은 의미를 보존하지 않는다

예전에는 컴파일러의 등장으로 생산성이 크게 향상됐습니다. 컴파일러는 고수준 언어로 작성된 프로그램의 의미를 보존하면서 기계어로 변환하도록 설계됩니다.

여기서 의미를 보존한다가 매우 중요합니다. 고급 언어로 작성한 코드의 의미가 그대로 보존되면서 기계어로 변환되기 때문에 우리는 컴파일러가 만든 어셈블리를 매번 한 줄씩 검증하지 않아도 됩니다.

LLM은 다릅니다. 자연어에는 형식 언어와 같은 엄밀한 의미가 정의되어 있지 않고, 모델에도 그 요구사항의 의도와 제약을 코드에 빠짐없이 보존한다는 계약이 없습니다. 그래서 그럴듯하게 동작하는 코드에서도 일부 의도가 빠지거나 미묘하게 잘못된 구현이 나올 수 있습니다.

이제 병목은 코드 작성이 아닙니다. LLM이 쏟아낸 코드가 옳은지 사람이 판단하고 검증하는 과정입니다. 그 코드가 맞는지, 왜 맞는지, 어디서 깨질 수 있는지를 가려내는 판단력이 더 중요해졌습니다.

결국 의미를 사람이 검증해야 한다

문제는 이 판단과 검증이라는 게 쉽게 할 수 있는 일이 아니라는 겁니다. HTTP 헤더가 해결하려는 제약과 현재 명세를 이해하면, AI가 짜준 헤더 처리에서 빠진 예외와 경계를 더 정확히 찾아낼 수 있습니다. MVCC 기반 격리 수준이 무엇을 막고 무엇을 허용하는지 알면, 각 트랜잭션은 성공했지만 애플리케이션의 정합성은 깨지는 상황을 더 쉽게 의심할 수 있습니다.

기술이 태어난 배경을 안다고 코드의 정확성이 저절로 보장되는 것은 아닙니다. 하지만 어떤 문제를 해결하려고 그런 선택을 했고, 그 대가로 무엇을 포기했는지 알면 어디를 의심해야 할지 판단할 수 있습니다. AI가 코드를 대신 만드는 만큼, 사람은 그 코드에서 문제를 찾아낼 수 있어야 합니다.

Bottom-Up CS

A Bottom-Up Approach

《Computer Networking: A Top-Down Approach》라는 유명한 책이 있습니다. 전공자라면 한 번쯤 들어봤을 법합니다.

이 책이 애플리케이션 계층에서 시작해 전송, 네트워크, 링크, 물리 계층 순으로 위에서 아래로 내려간다면, 제가 집필하는 책은 문제와 제약에서 출발해 해결책과 추상 개념을 하나씩 쌓아 올립니다. 그 출발점은 인류가 계산을 도구에 맡기기 시작한 가장 밑바닥입니다.

왜 계산을 해야만했고, 왜 사람의 계산만으로는 부족했으며, 그때마다 어떤 해결책이 등장했는지를 따라갑니다. 완성된 개념을 먼저 외우는 대신, 문제가 주어지고 그 개념이 필요해지는 과정을 다룰 예정입니다.

아마 이 책을 쓰기 위해 자료를 찾고, 이들을 서로 연결하고, 다시 정리하는 과정은 저에게도 굉장히 많은 공부가 될 겁니다. (사실 이 목적도 큽니다 ㅎㅎ)

집필 방식

완성된 원고를 한 번에 출간하는 대신, 웹툰처럼 매주 하나의 주제를 공개하고 계속 고쳐 나가려 합니다. 매주 공개한 글은 독립된 연재분으로 끝나지 않습니다.

상단의 책 메뉴에서 볼 수 있듯, 글에서 다룬 개념을 노드로 만들고 기존 개념과 연결해 그래프형 지식 베이스로 확장합니다.

이렇게 확장되는 그래프형 지식 베이스 자체가 《Bottom-Up CS》라는 디지털 책입니다. 고정된 목차를 처음부터 끝까지 읽는 방식에서 벗어나, 독자가 관심 있는 개념에서 시작해 연결된 지식을 따라갈 수 있게 만들려 합니다.

Bottom-Up CS 연재를 시작합니다.