들어가며 — 왜 지금 카맥의 회고가 화제인가
2026년의 Hacker News와 GeekNews에는 오래된 소스 코드와 개발 회고가 새삼 화제에 오르는 흐름이 있습니다. AI가 코드를 빠르게 쏟아내는 시대일수록, 역설적으로 "잘 만든다는 것은 무엇인가"라는 근본 질문이 다시 주목받기 때문입니다. 그 한가운데 존 카맥(John Carmack)의 회고가 다시 회자됩니다.
카맥은 id Software에서 Wolfenstein 3D, Doom, Quake를 만든 프로그래머로, 게임 엔진과 그래픽 프로그래밍의 역사에서 손꼽히는 인물입니다. 그는 자신의 개발 과정을 비교적 솔직하게 공개해 온 것으로도 유명합니다. 특히 Quake 개발은 그가 여러 인터뷰와 공개 글에서 "야심이 현실과 부딪힌 시기"로 회고한 바 있습니다.
이 글은 카맥 개인의 전기가 아닙니다. 그의 공개된 회고를 단서로 삼아, 모든 엔지니어링 팀이 마주하는 보편적 교훈 — 기술적 과욕, 스코프 관리, 안정적 기반의 선택, 작은 팀의 의사결정 — 을 풀어내려는 시도입니다.
왜 하필 2026년에 이런 회고가 다시 주목받을까요. AI 코딩 에이전트가 코드 생산의 병목을 거의 없애 버린 지금, 많은 팀이 "이제 더 많은 것을 더 빠르게 시도할 수 있다"는 흥분에 빠져 있습니다. 그런데 바로 그 흥분이 카맥이 경고한 함정 — 한 번에 너무 많은 것을 시도하는 것 — 으로 직행하는 길이기도 합니다. 코드를 빠르게 만들 수 있게 됐다는 것이 여러 큰 위험을 동시에 감당할 수 있게 됐다는 뜻은 아닙니다. 오히려 생산 속도가 빨라질수록, 무엇을 시도하지 않을지 결정하는 절제가 더 중요해집니다. 30년 전의 회고가 지금 새삼 읽히는 이유가 여기 있습니다.
**중요: 이 글은 카맥과 id Software에 관한 공개된 보도와 그가 직접 밝힌 회고를 바탕으로 합니다. 당사자의 입을 빌린 가상 대사는 일절 만들지 않으며, 구체적 사실 인용은 신중히 다룹니다. 일화의 세부는 출처에 따라 다를 수 있습니다.**
사실 배경 — Quake 개발이 남긴 것
먼저 공개적으로 알려진 사실 관계를 정리합니다.
id Software는 Doom의 성공 이후 Quake를 만들었습니다. Quake는 1996년 출시된, 진정한 의미의 실시간 3D 폴리곤 렌더링과 멀티플레이어 네트워킹을 결합한 게임으로 평가받습니다. 기술적으로 Quake는 당시로서 매우 야심적인 목표를 여러 개 동시에 추구했습니다.
널리 알려진 사실들을 정리하면 다음과 같습니다.
- Quake는 Doom의 2.5D 방식을 넘어 완전한 3D 월드를 목표로 했습니다.
- 카맥은 BSP 트리, 사전 계산된 가시성(PVS), 라이트맵 같은 기술로 실시간 3D 렌더링 성능 문제를 풀었습니다.
- Quake는 인터넷 멀티플레이어와 클라이언트-서버 모델로 온라인 게임의 방향을 제시했습니다.
- QuakeC라는 게임 로직용 스크립트 언어를 도입해 모드 제작 생태계를 열었습니다.
동시에, Quake 개발은 id Software에 큰 부담과 갈등을 남긴 시기로도 회고됩니다. 게임의 디자인 방향이 개발 도중 바뀌었고, 초기 구상과 최종 결과물 사이에 상당한 간극이 있었다는 점은 여러 자료에서 공통적으로 언급됩니다. 이 시기를 거치며 핵심 인력 일부가 회사를 떠나기도 했습니다.
카맥 자신은 후일 여러 인터뷰와 글에서, 당시의 야심이 너무 컸고 한 번에 너무 많은 새로운 것을 시도했다는 취지의 회고를 남겼습니다. 이 글이 다루려는 교훈은 바로 이 지점, "한 번에 너무 많은 것을 시도하는 것의 위험"입니다.
한 가지 분명히 해 둘 것은, 이 글이 Quake를 "실패작"으로 그리려는 것이 결코 아니라는 점입니다. Quake는 상업적으로도 기술적으로도 큰 성공이었고, 온라인 멀티플레이어 게임과 모드 문화의 토대를 놓았습니다. 회고가 주목하는 것은 결과의 성공 여부가 아니라 그 과정의 비용입니다. 같은 성공에 이르는 데 더 적은 고통이 가능했는가, 무엇이 그 고통을 키웠는가 — 이것이 교훈의 초점입니다. 성공한 프로젝트의 과정을 정직하게 돌아보는 것이야말로 가장 값진 회고입니다.
교훈 1 — 한 번에 하나의 큰 위험만
위험의 곱셈
엔지니어링 프로젝트에서 새로운 것을 시도하는 것은 위험을 동반합니다. 그리고 여러 새로운 것을 동시에 시도하면, 위험은 더해지는 것이 아니라 곱해집니다.
한 번에 하나의 큰 모험 (권장)
+------------------+------------------+
| 검증된 기반 | 새로운 시도 1개 |
| (안정) | (위험) |
+------------------+------------------+
위험 = 1 (관리 가능)
한 번에 여러 큰 모험 (위험)
+----------+----------+----------+----------+
| 새 렌더링 | 새 네트워크| 새 언어 | 새 디자인 |
| (위험) | (위험) | (위험) | (위험) |
+----------+----------+----------+----------+
위험 = 곱셈 (어디서 터졌는지조차 알기 어려움)
Quake가 동시에 추구한 것을 떠올려 봅시다. 완전한 3D 렌더링(새로움), 인터넷 멀티플레이어(새로움), 스크립트 언어(새로움), 그리고 변화하는 게임 디자인(불확정). 각각이 그 자체로 어려운 도전인데, 이것들이 동시에 진행됐습니다.
이때 문제가 생기면 원인을 분리하기가 매우 어렵습니다. 성능이 안 나올 때 그것이 렌더링 탓인지, 네트워크 탓인지, 스크립트 탓인지, 아니면 이 셋의 상호작용 탓인지 가려내기 힘듭니다. 위험이 곱해지면 디버깅도 곱해집니다.
보편적 적용
이 교훈은 게임을 넘어 모든 엔지니어링에 적용됩니다.
- 새 프로그래밍 언어를 처음 도입하면서, 동시에 새 아키텍처를 시도하고, 동시에 새 인프라로 옮기지 마라.
- 한 릴리스에 새로운 데이터베이스, 새로운 큐 시스템, 새로운 배포 방식을 한꺼번에 넣지 마라.
- 검증되지 않은 기술을 여러 개 동시에 쌓으면, 문제 발생 시 원인 격리가 불가능해진다.
이 원칙을 어겼을 때 가장 먼저 무너지는 것은 디버깅 능력입니다. 다음 그림이 그 이유를 보여 줍니다.
새로움이 1개일 때 (격리 가능)
문제 발생 -> 용의자 1명 -> 빠른 진단
새로움이 4개일 때 (격리 불가)
문제 발생 -> 용의자 4명 + 그들의 상호작용 6쌍
-> 총 10가지 가능성 -> 진단 마비
용의자가 늘어나면 단순히 더해지는 것이 아니라, 그들 사이의 상호작용까지 의심해야 합니다. 네 개의 새로움은 네 개의 단독 용의자에 더해 여섯 쌍의 상호작용 용의자를 만듭니다. 이것이 위험이 곱해진다는 말의 구체적 의미입니다.
원칙은 단순합니다. "한 번에 큰 모험은 하나만." 나머지는 검증된, 지루한, 안정적인 선택으로 채우는 것입니다. 그래야 모험이 실패해도 그 실패를 명확히 식별하고 대응할 수 있습니다.
위험 예산이라는 사고법
이 원칙을 더 실용적으로 다루는 방법은 "위험 예산(risk budget)"으로 생각하는 것입니다. 한 프로젝트가 감당할 수 있는 새로움의 총량에는 한계가 있다고 보고, 그 예산을 의식적으로 배분하는 것입니다.
프로젝트의 위험 예산 (예: 100점)
+--------------------------------------+
| 핵심 차별화 모험 1개 : 60점 | <- 여기에 집중
| 지원 영역의 작은 새로움 : 20점 |
| 나머지는 전부 검증된 것 : 0점 |
| 여유분 (예상 못한 위험) : 20점 | <- 반드시 남겨둘 것
+--------------------------------------+
합계 100점 (초과 금지)
이 사고법의 핵심은 두 가지입니다. 첫째, 예산이 유한하다는 인식입니다. 새로운 것을 하나 더 추가할 때마다 다른 곳에서 위험을 빼야 합니다. 둘째, 여유분을 남기는 것입니다. 모든 위험 예산을 계획된 모험에 다 쓰면, 예상 못한 위험(의존성 문제, 인력 이탈, 요구사항 변경)이 터졌을 때 흡수할 여력이 없습니다.
Quake를 이 틀로 보면, 위험 예산을 여러 큰 모험에 동시에 배분했고 여유분이 거의 없었던 셈입니다. 그래서 디자인 변경이라는 추가 위험이 닥쳤을 때 그것을 흡수할 여력이 부족했습니다. 이것은 비난이 아니라, 산업의 경계를 밀어붙이는 프로젝트가 흔히 치르는 대가입니다.
물론 "위험 예산 100점"이라는 숫자는 비유일 뿐, 실제로 위험을 정밀하게 정량화할 수 있다는 뜻은 아닙니다. 이 사고법의 가치는 정확한 계산에 있지 않고, "우리가 지금 몇 개의 큰 모험을 동시에 하고 있는가"를 의식적으로 세어 보게 만드는 데 있습니다. 많은 팀이 무너지는 이유는 위험을 잘못 계산해서가 아니라, 자기가 몇 개의 위험을 짊어졌는지조차 세어 본 적이 없어서입니다.
교훈 2 — 안정적 기반을 택하는 가치
지루한 기술의 미덕
카맥의 작업에서 일관된 특징 하나는, 화려한 부분과 지루한 부분을 구분하고 지루한 부분을 견고하게 다졌다는 점입니다. 그는 종종 검증된 알고리즘과 자료구조 위에서 혁신을 쌓았습니다. BSP 트리는 그가 발명한 것이 아니라 기존 컴퓨터 그래픽스 문헌에서 가져와 게임에 응용한 것입니다.
여기서 보편적 교훈이 나옵니다. 혁신은 모든 층에서 동시에 일어날 필요가 없습니다. 오히려 잘 작동하는 프로젝트는 대부분의 층을 지루하고 검증된 것으로 채우고, 정말로 차별화가 필요한 한두 층에만 혁신을 집중합니다.
층 전략
----------- ---------------------------
핵심 차별화 혁신 (위험을 감수할 가치)
지원 시스템 검증된 패턴 (지루함이 미덕)
인프라/기반 가장 안정적 선택 (절대 모험 금지)
기반이 흔들리면 그 위의 모든 것이 흔들립니다. 그래서 가장 아래층일수록 가장 보수적으로, 가장 검증된 것을 택해야 합니다. 모험은 위쪽, 사용자가 가치를 느끼는 차별화 지점에 아껴 둡니다.
"지루함이 미덕"의 현대적 해석
이 원칙은 2026년에도 유효합니다. 오늘날 "지루한 기술을 택하라(choose boring technology)"는 조언이 널리 회자되는 이유가 바로 이것입니다. 새 기술은 매혹적이지만, 검증되지 않은 새 기술을 핵심 기반에 깔면 그 위험이 모든 곳으로 전파됩니다.
특히 AI가 코드를 빠르게 생성해 주는 시대에는 이 원칙이 더 중요해집니다. 코드를 빠르게 만들 수 있다는 것이, 검증되지 않은 여러 기술을 한꺼번에 쌓아도 된다는 뜻은 아니기 때문입니다. 생성 속도가 빨라질수록, 무엇을 안정적 기반으로 고정할지에 대한 판단이 오히려 더 결정적입니다.
혁신은 조합에서도 나온다
여기서 흔한 오해를 짚고 넘어가야 합니다. "지루한 기술을 택하라"가 "혁신하지 말라"는 뜻이 아니라는 점입니다. 카맥이 BSP 트리를 발명하지 않았다는 사실은 그의 작업이 덜 혁신적이라는 뜻이 아닙니다. 오히려 그는 기존의 검증된 기법들을 게임이라는 새 맥락에서 조합하고 응용하는 데서 혁신을 만들었습니다.
혁신의 두 종류
발명형 혁신 조합형 혁신
------------------- -------------------------
완전히 새로운 것을 만듦 검증된 것들을 새롭게 결합
위험이 매우 큼 위험이 상대적으로 낮음
드물게 성공 자주 성공
예: 새 알고리즘 발명 예: 기존 알고리즘의 영리한 응용
대부분의 성공적 제품 혁신은 발명형이 아니라 조합형입니다. 검증된 부품들을 안정적으로 쓰면서, 그것들을 결합하는 방식에서 차별화를 만드는 것입니다. 이렇게 하면 위험 예산을 아끼면서도 혁신할 수 있습니다. "지루한 기술 위의 영리한 조합"이야말로 안정성과 혁신을 동시에 잡는 길입니다.
이 관점은 도구 선택의 부담을 크게 덜어 줍니다. 모든 층에서 최신 기술을 좇아야 한다는 압박에서 벗어나, "어디서 검증된 것을 쓰고 어디서 영리하게 조합할 것인가"라는 더 생산적인 질문으로 옮겨 가기 때문입니다. 가장 새것을 가장 많이 쓰는 팀이 아니라, 새것과 검증된 것을 가장 영리하게 배치하는 팀이 이깁니다.
교훈 3 — 스코프 관리와 기술부채
변하는 스코프의 위험
Quake 개발 회고에서 반복적으로 언급되는 또 하나의 주제는, 게임 디자인의 방향이 개발 도중 바뀌었다는 점입니다. 초기에는 더 야심적인 RPG적 요소가 구상됐지만, 기술적 현실과 일정 압박 속에서 최종 형태로 수렴했다는 서술이 여러 자료에 공통적으로 나옵니다.
스코프가 개발 도중 흔들리는 것은 모든 프로젝트의 고전적 함정입니다. 특히 위험한 조합은 "야심적 스코프 + 흔들리는 스코프 + 빡빡한 일정"입니다. 이 셋이 겹치면 팀은 끝없이 움직이는 목표를 쫓으며 소진됩니다.
스코프 위험의 삼각형
야심적 스코프
/\
/ \
/ \
/ \
흔들리는 ----- 빡빡한
스코프 일정
세 변이 모두 길면 -> 번아웃과 품질 붕괴
기술부채는 의식적 결정이어야 한다
야심적 프로젝트에서 기술부채는 불가피합니다. 일정과 야심 사이에서 무언가는 미뤄지고, 임시방편이 들어가고, "나중에 고치자"가 쌓입니다. 문제는 부채 자체가 아니라 그 부채가 무의식적으로 쌓이는 것입니다.
건강한 팀과 그렇지 않은 팀의 차이는 부채의 유무가 아니라 부채의 가시성입니다.
나쁜 기술부채 건강한 기술부채
------------------- -------------------------
무의식적으로 쌓임 의식적으로 선택됨
어디 있는지 모름 목록으로 추적됨
갚을 계획 없음 갚을 시점이 정해짐
복리로 불어남 이자가 관리됨
카맥의 회고가 주는 교훈을 일반화하면 이렇습니다. 야심을 줄이라는 것이 아니라, 야심에 따르는 부채를 의식하고 추적하고 통제하라는 것입니다. 어디를 깎았는지 알면 나중에 복구할 수 있지만, 모르게 깎으면 그것이 어느 날 시스템을 무너뜨립니다.
스코프 크리프의 조기 신호
스코프가 위험하게 흔들리고 있다는 것은 보통 일정이 폭발하기 한참 전에 신호를 보냅니다. 이 신호를 일찍 알아채면 대응할 시간이 생깁니다.
조기 신호 의미
------------------------- -------------------------
"이왕 하는 김에" 빈발 스코프가 슬금슬금 늘고 있음
데모가 계속 미뤄짐 핵심 경로가 불확실함
"거의 다 됐다"가 반복됨 90% 신드롬, 마지막 10%가 안 끝남
추정이 매번 크게 빗나감 문제를 충분히 이해하지 못함
핵심 인력이 야근을 일상화 인간적 비용이 이미 청구되는 중
이 신호 중 가장 위험한 것은 마지막입니다. 일정과 스코프의 불일치는 결국 사람의 야근과 번아웃으로 흡수되기 때문에, "팀이 지쳐 보인다"는 것은 종종 스코프 문제의 가장 정직한 지표입니다. 대시보드의 숫자보다 사람의 표정이 먼저 말해 줍니다.
대응은 단순하지만 어렵습니다. 스코프를 줄이거나, 일정을 늘리거나, 야심을 낮추는 것입니다. 셋 중 무엇도 공짜가 아니고, 셋 다 거부하면 남는 것은 사람을 갈아 넣는 길뿐입니다. 건강한 팀은 이 셋 중 하나를 일찍, 의식적으로 선택합니다.
교훈 4 — 작은 팀의 의사결정과 인간적 비용
작은 팀의 양날
id Software는 작은 팀이었습니다. 작은 팀은 빠른 의사결정, 높은 응집력, 적은 의사소통 오버헤드라는 강점을 가집니다. 카맥 같은 한두 명의 핵심 인력이 기술 방향을 강하게 끌고 갈 수 있었던 것도 작은 팀이기에 가능했습니다.
그러나 작은 팀에는 그림자도 있습니다. 핵심 인력에 대한 의존도가 높고, 소수의 갈등이 팀 전체를 흔들며, 한 명의 번아웃이 프로젝트를 위협합니다. Quake 개발기에 핵심 인력 일부가 회사를 떠난 것은, 기술적 야심과 인간적 비용이 분리되지 않는다는 점을 보여줍니다.
작은 팀의 강점 작은 팀의 위험
------------------- -------------------------
빠른 의사결정 핵심 인력 의존
높은 응집력 소수의 갈등이 치명적
적은 오버헤드 번아웃에 취약
강한 방향성 버스 팩터 낮음
기술 결정은 사람 결정이다
여기서 가장 중요한 일반 교훈이 나옵니다. 기술적 과욕은 순수하게 기술 문제로 끝나지 않습니다. 그것은 사람들에게 일정 압박, 야근, 좌절, 갈등으로 전가됩니다. 너무 야심적인 스코프는 결국 사람을 갈아 넣는 것으로 메워지고, 그 비용은 핵심 인력의 이탈로 청구됩니다.
그래서 야심과 현실의 균형을 맞추는 일은 단지 일정 관리가 아니라 사람 관리입니다. 어떤 기술을 시도할지 결정할 때, "이것이 팀에게 어떤 인간적 비용을 요구하는가"를 함께 묻지 않으면, 기술적으로 성공하고도 팀을 잃을 수 있습니다.
강한 의견과 갈등의 관리
작은 팀의 또 다른 특징은, 강한 의견을 가진 소수가 부딪힐 때 그 마찰이 곧바로 팀 전체의 문제가 된다는 것입니다. 큰 조직에서는 의견 충돌이 여러 층위에 분산되고 완충되지만, 서너 명의 핵심으로 굴러가는 팀에서는 두 사람의 불화가 곧 회사의 위기입니다.
기술적 야심이 큰 팀일수록 강한 의견을 가진 사람들이 모입니다. 이것은 장점이자 위험입니다. 강한 의견은 좋은 결정을 낳지만, 그 의견들이 충돌할 때 조율할 메커니즘이 없으면 팀이 쪼개집니다. 그래서 작은 팀일수록 "의견 불일치를 어떻게 다룰 것인가"에 대한 명시적 합의 — 누가 어떤 영역의 최종 결정권을 갖는지, 합의가 안 될 때 어떻게 진행하는지 — 가 중요합니다. 기술 방향만큼이나 갈등 해소 방식도 설계의 대상입니다.
흥미롭게도 이 문제에 대한 가장 흔한 해독제는 거창한 프로세스가 아니라 기록입니다. "왜 이 결정을 내렸는가"를 짧게라도 남겨 두면, 나중에 같은 논쟁이 반복되는 것을 막고, 결정에 동의하지 않았던 사람도 그 맥락을 이해하게 됩니다. 작은 팀은 속도를 위해 기록을 생략하고 싶어하지만, 핵심 결정의 기록은 오히려 갈등을 줄이고 속도를 높이는 투자입니다.
교훈 5 — 완성과 출시의 규율
출시는 야심의 시험대다
id Software가 회자되는 또 하나의 이유는, 그들이 야심적이면서도 실제로 출시했다는 점입니다. Doom과 Quake는 구상으로 끝나지 않고 세상에 나왔습니다. 무한히 야심을 키우다 출시하지 못하는 프로젝트와, 야심을 현실에서 멈추고 출시하는 프로젝트의 차이는 결정적입니다.
출시하지 못하는 야심 출시하는 야심
------------------- -------------------------
"조금만 더 완벽하게" "이 정도면 출시, 나머지는 다음에"
스코프 무한 확장 스코프를 의식적으로 동결
영원한 90% 명확한 출시 기준
세상의 피드백 없음 세상이 검증해 줌
출시에는 야심을 멈추는 규율이 필요합니다. 어디까지가 이번 버전이고 어디부터가 다음 버전인지를 긋는 결정 말입니다. 이 선을 긋지 못하면 스코프는 무한히 늘어나고, 제품은 영원히 출시되지 않습니다. 역설적으로, 야심을 실현하는 가장 확실한 방법은 야심의 일부를 다음으로 미루는 절제입니다.
반복이 한 번의 완벽을 이긴다
여기서 또 하나의 교훈이 나옵니다. 한 번에 완벽한 것을 만들려는 야심보다, 빠르게 출시하고 반복하는 야심이 대개 더 강합니다. Doom에서 Quake로, Quake에서 다음 세대로 이어진 발전은 한 번의 완벽이 아니라 출시와 학습의 반복에서 나왔습니다.
이것은 위험 예산과도 연결됩니다. 모든 야심을 한 버전에 몰아넣으면 위험이 곱해지지만, 야심을 여러 버전에 나눠 담으면 각 버전의 위험이 관리 가능해지고, 매 출시마다 세상의 피드백으로 다음 야심을 교정할 수 있습니다. 큰 도약 하나보다 여러 번의 견고한 걸음이 더 멀리 갑니다.
현대 사례로 옮겨 보기 — 스타트업의 재현
이 교훈들이 30년 전 게임 회사만의 이야기가 아니라는 것을, 흔한 현대 스타트업 시나리오로 보여 드리겠습니다. 가상의 사례입니다.
어느 시리즈 A 스타트업이 야심찬 v2 재작성을 결정합니다. 그들은 한 번에 다음을 모두 바꾸기로 합니다.
v2에서 동시에 시도한 새로움 (위험 곱셈)
+----------------------------------------------+
| 1. 모놀리스 -> 마이크로서비스 (새 아키텍처) |
| 2. REST -> GraphQL (새 API 패러다임) |
| 3. 처음 쓰는 새 언어 (팀 경험 없음) |
| 4. 새 클라우드로 이전 (새 인프라) |
| 5. 새 디자인 시스템 (변화하는 스코프) |
+----------------------------------------------+
결과는 카맥의 회고와 구조적으로 닮습니다. 일정은 계속 밀리고, 어디서 문제가 터지는지 격리하기 어렵고(다섯 가지 새로움의 상호작용), 야근이 쌓이고, 핵심 엔지니어 둘이 번아웃으로 떠납니다. 기술적 야심이 인간적 비용으로 청구되는 동일한 패턴입니다.
위험 예산 사고법을 적용했다면 어땠을까요. "이번 v2의 핵심 차별화는 무엇인가"를 먼저 묻고, 거기에만 큰 모험을 배정했을 것입니다. 예를 들어 마이크로서비스 전환이 정말 핵심이라면 그것 하나만 하고, 나머지(언어, API, 인프라, 디자인)는 검증된 기존 선택을 유지하는 것입니다. 그러면 문제가 터져도 "마이크로서비스 탓"으로 격리할 수 있고, 여유 예산으로 예상 못한 위험을 흡수할 수 있습니다.
이 사례의 교훈은 명확합니다. 재작성의 유혹은 "이왕 다시 만드는 김에 전부 최신으로"라는 욕심을 부추기지만, 그 욕심이야말로 위험을 곱하는 가장 흔한 경로입니다.
성공적인 재작성은 대개 한 번에 하나씩, 점진적으로, 매 단계 검증하며 진행됩니다. 한 번에 모든 것을 바꾸는 빅뱅 재작성이 실패하는 통계적 이유가 바로 여기에 있습니다. 위험을 한꺼번에 떠안는 대신, 한 조각씩 교체하며 매 단계 안정성을 확인하는 팀이 결국 더 빨리, 더 안전하게 목적지에 도착합니다.
실무 적용 — 야심을 다루는 체크리스트
카맥의 회고에서 끌어낸 교훈을 실무 체크리스트로 정리합니다.
[ 위험 격리 ]
[ ] 이번 프로젝트에서 "한 번에 하나의 큰 모험" 원칙을 지키는가?
[ ] 검증되지 않은 기술을 몇 개나 동시에 쌓고 있는가?
[ ] 문제 발생 시 원인을 격리할 수 있도록 새로움을 분리했는가?
[ 기반 선택 ]
[ ] 가장 아래층(인프라/기반)은 가장 검증된 것을 택했는가?
[ ] 혁신을 핵심 차별화 지점에만 집중했는가?
[ ] "지루한 기술"을 택할 수 있는 곳에서 택했는가?
[ 스코프와 부채 ]
[ ] 스코프가 명확히 정의되고 변경이 통제되는가?
[ ] 의식적으로 진 기술부채를 목록으로 추적하는가?
[ ] 갚을 시점과 책임자가 정해진 부채인가?
[ 사람 ]
[ ] 이 야심이 팀에게 요구하는 인간적 비용을 평가했는가?
[ ] 핵심 인력 의존(버스 팩터)을 줄일 방법이 있는가?
[ ] 번아웃 신호를 모니터링하는 체계가 있는가?
[ 출시 규율 ]
[ ] 이번 버전의 스코프 경계(무엇이 다음으로 미뤄지는가)가 명확한가?
[ ] 명확한 출시 기준이 정의되어 있는가? (90% 신드롬 방지)
[ ] 야심을 여러 반복(버전)에 나눠 담았는가?
이 체크리스트의 핵심은 야심을 포기하라는 것이 아닙니다. 야심을 의식적으로, 분리해서, 사람을 고려하며 추구하라는 것입니다.
자주 나오는 질문
**Q1. 그러면 야심적인 프로젝트는 하지 말라는 건가요?**
정반대입니다. id Software가 야심적이지 않았다면 Doom도 Quake도 없었을 것입니다. 교훈은 "야심을 버려라"가 아니라 "야심을 한 곳에 집중하고 나머지를 안정시켜라"입니다. 큰 모험 하나에 위험 예산을 몰아주면, 그 모험은 오히려 더 성공할 가능성이 높아집니다. 사방에 분산된 야심이 위험한 것입니다.
**Q2. 무엇이 "핵심 차별화"인지 어떻게 정하나요?**
"이것이 없으면 우리 제품이 존재할 이유가 없는가"를 물어보십시오. Quake의 경우 실시간 3D가 그것이었습니다. 그 질문에 "예"인 영역에만 큰 모험을 배정하고, "아니오"인 영역(빌드 도구, 배포 방식, 보조 라이브러리)은 가장 지루하고 검증된 선택을 하는 것입니다.
**Q3. 기술부채는 무조건 나쁜 것 아닌가요?**
아닙니다. 의도적으로 진 부채는 합리적 전략일 수 있습니다. 문제는 무의식적 부채와, 갚을 계획 없는 부채입니다. 야심적 일정을 맞추기 위해 "여기는 일단 임시방편, 출시 후 2주 내 리팩터링"이라고 명시적으로 결정하고 기록한다면, 그것은 건강한 부채입니다. 부채 자체가 아니라 부채의 가시성과 상환 계획이 관건입니다.
**Q4. 작은 팀의 버스 팩터 문제는 어떻게 줄이나요?**
핵심 영역을 의도적으로 두 명 이상이 만지게 하고(페어링, 순환), "왜 이렇게 만들었나"를 문서로 남기는 것이 기본입니다. 작은 팀일수록 속도를 위해 한 사람에게 집중시키고 싶은 유혹이 크지만, 그 사람이 떠나는 순간의 비용이 평소 분산 비용보다 훨씬 큽니다.
**Q5. AI가 코드를 빠르게 짜 주는 지금도 이 교훈이 유효한가요?**
오히려 더 유효합니다. AI는 코드 생산 속도를 높여 주지만, "여러 새로운 것을 동시에 시도할 때 원인을 격리하기 어렵다"는 문제는 코드 생산 속도와 무관합니다. 빠르게 많이 만들 수 있다는 것이 여러 큰 모험을 동시에 감당할 수 있다는 뜻은 아닙니다. 위험의 곱셈은 AI 시대에도 그대로입니다. 더 나아가, AI가 코드를 쉽게 만들어 주는 만큼 "이왕이면 전부 새로 하자"는 유혹은 더 커집니다. 그래서 절제의 필요성은 줄어드는 것이 아니라 오히려 커집니다.
**Q6. 이 교훈들을 한 문장으로 줄이면?**
"야심은 한 곳에 집중하고, 나머지는 지루하게, 부채는 보이게, 사람은 돌보며, 멈춰서 출시하라." 이 한 문장이 다섯 교훈의 압축입니다.
함정과 비판적 시각
카맥의 회고에서 교훈을 끌어낼 때 주의할 점들도 정리합니다.
1. **사후 합리화의 위험**: 회고는 결과를 알고 난 뒤의 서술입니다. "그때 너무 야심적이었다"는 평가는 결과적으로 어려웠기 때문에 나온 것일 수 있고, 성공했다면 같은 선택이 "대담한 비전"으로 칭송됐을 수 있습니다. 회고에서 교훈을 끌어낼 때는 생존 편향과 사후 확신 편향을 경계해야 합니다.
2. **야심의 가치 절하 위험**: "한 번에 하나만"을 과도하게 적용하면 보수주의로 빠집니다. id Software가 위험을 감수했기에 Doom과 Quake가 산업을 바꿨다는 점도 사실입니다. 모든 모험을 줄이면 평범함만 남습니다. 교훈은 "모험하지 마라"가 아니라 "모험을 관리하라"입니다.
3. **맥락의 차이**: 1990년대 게임 개발과 오늘날의 소프트웨어 개발은 도구, 팀 규모, 시장이 모두 다릅니다. 한 천재 프로그래머가 엔진을 짜던 시대의 교훈을 현대 팀에 그대로 옮기기는 어렵습니다. 보편적 부분(위험 격리, 스코프 관리)과 시대 특수적 부분을 구분해야 합니다.
4. **영웅 서사의 함정**: 카맥 같은 인물을 중심에 둔 서사는 "한 명의 천재"라는 영웅 신화를 강화하기 쉽습니다. 실제 제품은 디자이너, 아티스트, 다른 프로그래머들의 집합적 노력이며, 회고의 한 사람의 시점만으로 전체를 재구성하면 왜곡이 생깁니다.
5. **출처의 한계**: 같은 사건도 당사자마다 기억과 해석이 다릅니다. 이 글이 인용하는 "공통적으로 언급되는" 사실들조차 완전한 합의는 아닐 수 있습니다. 단일 회고를 절대적 진실로 받아들이지 않는 태도가 필요합니다.
6. **성공이 교훈을 정당화하지 않음**: Quake가 결국 성공했다는 사실은, 그 과정의 선택들이 옳았다는 증거가 아닙니다. 성공한 프로젝트의 모든 결정을 사후에 정당화하는 "성공 후광 효과"를 경계해야 합니다. 어쩌면 더 적은 고통으로 같은 성공에 이를 수 있었을지도 모릅니다.
7. **단순화의 위험**: "한 번에 하나만", "위험 예산" 같은 깔끔한 프레임은 기억하기 쉽지만, 현실의 의사결정은 그렇게 단순하지 않습니다. 어떤 모험이 "하나"인지조차 모호하고, 위험은 정량화하기 어렵습니다. 이 프레임들은 사고의 출발점이지 공식이 아닙니다.
이 비판들은 교훈의 가치를 부정하지 않습니다. 오히려 교훈을 더 정확하게 적용하기 위한 안전장치입니다. 핵심은 회고에서 보편적 원리를 추출하되, 그 원리를 자기 맥락에서 다시 검증하는 것입니다. 좋은 회고는 답을 주는 것이 아니라 더 나은 질문을 주며, 그 질문을 자기 프로젝트에 던지는 순간 비로소 교훈이 살아납니다.
마치며 — 야심을 관리하는 법
카맥의 Quake 회고가 오늘날에도 회자되는 이유는, 그것이 단순한 옛날이야기가 아니라 모든 야심적 프로젝트가 반복적으로 마주하는 구조를 보여 주기 때문입니다.
정리하면 다음과 같습니다.
1. 한 번에 큰 모험은 하나만. 여러 새로움을 동시에 쌓으면 위험이 곱해지고 원인 격리가 불가능해집니다.
2. 안정적 기반을 택하라. 혁신은 핵심 차별화 지점에 아끼고, 나머지는 지루하고 검증된 것으로 채우십시오.
3. 스코프를 통제하고 부채를 가시화하라. 야심에 따르는 부채를 의식적으로 추적하면 복구할 수 있습니다.
4. 기술 결정은 사람 결정이다. 야심의 인간적 비용을 평가하지 않으면 기술적으로 성공하고도 팀을 잃습니다.
5. 출시와 반복의 규율을 가져라. 야심을 여러 버전에 나눠 담고 멈춰서 출시할 줄 알아야 야심이 현실이 됩니다.
6. 회고에서 교훈을 끌어내되, 생존 편향과 영웅 서사를 경계하며 자기 맥락에서 다시 검증하십시오.
AI가 코드를 빠르게 생성하는 2026년, 무언가를 만드는 속도는 빨라졌지만 무엇을 만들지, 어떤 위험을 감수할지, 그 비용을 누가 치를지에 대한 판단은 여전히 사람의 몫입니다. 카맥의 회고가 주는 가장 깊은 교훈은 어쩌면 이것입니다. 위대한 기술은 야심에서 나오지만, 지속 가능한 팀은 그 야심을 관리하는 절제에서 나온다.
이 교훈이 특별히 울림을 갖는 이유는, 그것이 천재의 비범한 깨달음이 아니라 누구나 겪는 평범한 함정에 관한 것이기 때문입니다. 우리 대부분은 카맥처럼 게임 엔진을 발명하지는 않지만, "이왕 하는 김에 전부 새로 하자"는 유혹, 스코프가 슬금슬금 늘어나는 경험, 야심이 팀의 야근으로 청구되는 순간은 거의 모두가 겪습니다. 그래서 30년 전 한 게임 회사의 회고가 오늘 우리의 스프린트 회고처럼 읽힙니다.
결국 엔지니어링의 성숙은 야심의 크기가 아니라 야심을 다루는 방식에서 드러납니다. 큰 꿈을 꾸되, 그 꿈을 한 곳에 집중하고, 나머지를 안정시키고, 사람을 돌보고, 멈춰서 출시할 줄 아는 것. 이것이 카맥의 회고가 30년을 건너 우리에게 건네는 조용한 조언입니다.
다음 프로젝트를 시작하기 전에, 딱 하나만 세어 보십시오. "지금 우리가 동시에 짊어진 큰 모험이 몇 개인가." 그 숫자가 하나보다 크다면, 줄일 수 있는 것이 무엇인지 묻는 것에서 건강한 엔지니어링이 시작됩니다.
위대한 것을 만들고 싶다는 마음과, 그것을 지속 가능하게 만들고 싶다는 마음은 충돌하지 않습니다. 둘을 잇는 다리가 바로 절제입니다.
다시 한번 강조합니다. 이 글은 공개된 보도와 회고를 바탕으로 한 일반적 교훈의 정리이며, 특정 인물의 입을 빌린 가상 대사는 포함하지 않습니다.
참고 자료
- [Hacker News](https://news.ycombinator.com/)
- [GeekNews — 게임 엔진과 개발 회고 관련 논의](https://news.hada.io/)
- [id Software 공식 사이트](https://www.idsoftware.com/)
- [Masters of Doom (David Kushner) — id Software 역사 기록](https://en.wikipedia.org/wiki/Masters_of_Doom)
- [Quake (video game) — 개발 배경 개요](https://en.wikipedia.org/wiki/Quake_(video_game))
- [Fabien Sanglard — Quake 엔진 코드 분석](https://fabiensanglard.net/quakeSource/)
- [Choose Boring Technology (Dan McKinley)](https://boringtechnology.club/)
- [The Mythical Man-Month (Fred Brooks) — 스코프와 팀 규모의 고전](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)
현재 단락 (1/206)
2026년의 Hacker News와 GeekNews에는 오래된 소스 코드와 개발 회고가 새삼 화제에 오르는 흐름이 있습니다. AI가 코드를 빠르게 쏟아내는 시대일수록, 역설적으로 ...