1959년 모스크바의 정렬 문제에서 2026년 Amazon 장애까지 — Tony Hoare가 남긴 것들

1959년 모스크바, 26세 청년의 문제

1959년, 스물여섯 살의 영국 청년 토니 호어(Tony Hoare)는 모스크바 국립대학교에 있었다. 콜모고로프 연구실에서 러시아어-영어 기계번역을 연구하던 그에게 하나의 실무적 문제가 주어졌다. 러시아어 단어를 사전 순서로 정렬해야 했다.

당시 알려진 방법은 버블소트(bubble sort)였다. 호어는 이것이 “obviously rather slow”하다고 느꼈다. 그래서 다른 방법을 생각하기 시작했다. 아이디어는 단순했다. 기준 원소(pivot)를 하나 잡고, 그보다 작은 것은 왼쪽에, 큰 것은 오른쪽에 놓은 뒤, 양쪽을 같은 방식으로 다시 정렬한다. 재귀적으로.

이것이 퀵소트(Quicksort)의 탄생이었다.

문제는 당시의 프로그래밍 언어가 재귀를 지원하지 않았다는 점이다. 호어가 사용하던 Elliott Brothers의 Mercury Autocode에는 재귀 호출이라는 개념 자체가 없었다. 퀵소트는 머릿속에서만 존재하는 알고리즘이었다. 1961년, ALGOL 60이 재귀를 지원하면서 비로소 코드로 구현할 수 있었다. 아이디어가 2년을 기다린 셈이다.

6펜스 내기와 알고리즘의 경제학

호어가 Elliott Brothers에 입사한 뒤의 일화가 전해진다. 그는 상사에게 “기존보다 더 빠른 정렬 알고리즘이 있다”고 주장했다. 상사의 반응은 간단했다.

“I bet you sixpence you don’t!”

호어는 증명했고, 6펜스를 받았다.

6펜스는 당시 기준으로도 작은 돈이었다. 하지만 퀵소트가 세계에 가져다 준 경제적 가치는 측정이 불가능할 정도로 크다. 숫자로 보면 이렇다.

100만 개의 데이터를 정렬할 때, 버블소트의 O(n²)는 약 1조 번의 연산이 필요하다. 퀵소트의 O(n log n)은 약 2천만 번이면 된다. 5만 배의 차이다. 10억 개로 올라가면 차이는 3,300만 배가 된다.

Unix의 qsort(), C++의 std::sort, Java의 Arrays.sort — 이 모든 것의 기반이 퀵소트다. 67년간 전 세계 수백만 대의 서버에서 매일 수조 번 실행되어 왔다. 비유하자면, 서울에서 부산까지 매번 걸어가던 세계에 KTX를 놓아준 것이다. 그것도 모든 컴퓨터에 동시에.

그 대가는 6펜스였다.

”단순함이 곧 신뢰성이다”

1980년, 호어는 튜링상을 수상했다. 그의 수상 강연에서 나온 격언은 소프트웨어 엔지니어링의 고전이 되었다.

“소프트웨어 설계에는 두 가지 방법이 있다. 하나는 결함이 명백히 없을 정도로 단순하게 만드는 것이고, 다른 하나는 명백한 결함이 없을 정도로 복잡하게 만드는 것이다.”

이 문장의 핵심은 ‘명백히’와 ‘명백한’의 위치 차이에 있다. 전자는 구조 자체가 단순해서 결함이 존재할 수 없음이 자명한 상태다. 후자는 복잡하지만 아직 결함이 발견되지 않은 상태다. 둘의 차이는 근본적이다. 하나는 증명이고, 다른 하나는 희망이다.

호어는 여기서 멈추지 않았다.

“신뢰성의 대가는 극도의 단순성을 추구하는 것이다. 이것은 매우 부유한 사람들이 가장 지불하기 어려워하는 대가다.”

대규모 시스템을 운영하는 조직일수록 단순함을 선택하기 어렵다는 역설. 예산이 충분하기에 복잡한 해결책을 선택하고, 복잡성이 쌓이면 더 많은 예산을 투입하는 악순환. 호어는 이미 40년 전에 이 패턴을 정확히 짚었다.

그리고 그의 또 다른 관찰:

“Inside every large program is a small program struggling to get out.”

모든 거대한 프로그램 안에는 빠져나오려 발버둥 치는 작은 프로그램이 있다. 복잡성은 본질이 아니라 축적물이라는 뜻이다.

CSP와 Hoare Logic — 현대 프로그래밍 언어에 남긴 유산

호어의 기여는 퀵소트에 그치지 않았다.

**CSP(Communicating Sequential Processes)**는 1978년에 발표된 동시성 프로그래밍 모델이다. 핵심 아이디어는 간단하다. 프로세스들이 공유 메모리 대신 메시지를 주고받으며 통신한다. 이 개념은 수십 년 뒤 프로그래밍 언어들의 근간이 되었다.

Go 언어의 goroutine과 channel은 CSP를 직접 계승한 것이다. Go 커뮤니티의 격언 “Don’t communicate by sharing memory; share memory by communicating”은 호어의 CSP 철학을 한 문장으로 압축한 것에 다름 아니다. Erlang의 actor model, Rust의 futures, Clojure의 core.async — 모두 호어가 뿌린 씨앗에서 자란 나무들이다.

Hoare Logic(호어 논리)는 프로그램의 정확성을 수학적으로 증명하는 체계다. 전제 조건(precondition), 프로그램, 후행 조건(postcondition)으로 구성된 이른바 “호어 삼중쌍(Hoare triple)“은 형식 검증(formal verification)의 기초가 되었다.

{P} C {Q}

“조건 P가 참인 상태에서 프로그램 C를 실행하면, 조건 Q가 참이 된다.”

이 단순한 형식이 Dafny, Lean, F*, Frama-C 같은 현대 검증 도구들의 이론적 토대다. 호어가 1969년에 제안한 이 체계가, 57년이 지난 2026년에 가장 절실하게 필요해지고 있다는 사실은 후반부에서 다시 이야기하겠다.

”구현이 너무 쉬웠기에 유혹을 거절할 수 없었습니다”

호어의 위대함 중 하나는 자신의 실수를 인정하는 용기였다.

2009년, QCon 런던에서 호어는 이렇게 고백했다.

“나는 이것을 나의 10억 달러짜리 실수라고 부릅니다. 1965년에 null 참조를 발명한 것입니다. 당시 나는 객체 지향 언어(ALGOL W)의 참조를 위한 타입 시스템을 설계하고 있었습니다. 목표는 컴파일러가 자동으로 확인하여 모든 참조의 사용이 절대적으로 안전하도록 보장하는 것이었습니다. 그러나 null 참조를 넣는 유혹을 거절할 수 없었습니다. 구현이 너무 쉬웠기 때문입니다.”

“구현이 너무 쉬웠기 때문에.” 이 한 문장에 소프트웨어 역사의 핵심 교훈이 담겨 있다.

null 참조는 이후 60년간 셀 수 없는 NullPointerException, segfault, 시스템 장애의 원인이 되었다. 호어 자신의 추산으로 “10억 달러”였지만, 실제 피해액은 그보다 훨씬 클 것이다.

하지만 그의 고백은 변화를 만들었다. 현대 프로그래밍 언어들은 호어의 실수로부터 배웠다.

Rust: Option<T>으로 null을 완전히 제거했다. 값이 없을 수 있는 경우를 타입 시스템이 강제로 처리하게 한다.
Kotlin: 변수는 기본적으로 non-nullable이다. null이 가능한 타입은 String?처럼 명시적으로 opt-in해야 한다.
Swift: Optional, guard let, if let 패턴으로 null 안전성을 보장한다.
TypeScript: strictNullChecks 옵션으로 null/undefined를 타입 레벨에서 관리한다.

호어가 1965년에 저지른 실수를 2009년에 공개적으로 인정했고, 그 인정이 프로그래밍 언어 설계의 방향을 바꿨다. 실수를 숨기는 것이 아니라 직시하는 것이 진정한 발전을 만든다는 증거다.

2026년 3월, Amazon — 같은 유혹의 반복

2026년 3월, Amazon에서 연쇄적인 장애가 발생했다.

3월 2일, AI가 기여한 코드로 인한 장애가 발생했다. 결과는 12만 건의 주문 손실과 160만 건의 에러. 3월 5일에는 6시간짜리 대규모 장애가 이어졌다. 체크아웃, 로그인, 가격 표시까지 마비되었다. 그리고 이미 2025년 12월에는 Amazon의 자율 AI 코딩 도구인 Kiro가 AWS 환경 전체를 삭제한 뒤 재생성하는 사고를 일으켜 13시간 장애를 초래한 바 있다.

Amazon의 대응은 시니어 엔지니어의 사인오프를 의무화하는 것이었다. 그런데 동시에 Amazon은 AI 코드 사용률 80% 목표를 유지하고, 3만 명 규모의 구조조정을 진행하고 있었다. AI 코드의 감시를 강화하면서 AI 코드 사용을 확대한다. 이 모순은 지금 기술 산업 전체의 축소판이다.

호어가 1965년에 한 말을 다시 읽어보자.

“구현이 너무 쉬웠기 때문에 유혹을 거절할 수 없었습니다.”

그리고 2026년의 현실:

“AI가 너무 쉽게 코드를 생성하기 때문에 유혹을 거절할 수 없다.”

60년의 간격을 두고 같은 패턴이 반복되고 있다. 단기 편의성이 장기 안전성을 이기는 유혹. 호어는 이 유혹의 구조를 누구보다 잘 알고 있었다. 자기 자신이 한 번 당해봤으니까.

바이브코딩 시대의 데이터

감이 아닌 숫자로 보자.

CodeRabbit의 분석에 따르면, AI가 생성한 코드는 인간이 작성한 코드보다 1.7배 더 많은 이슈를 발생시킨다. Veracode의 보고서는 AI 생성 코드의 45%가 보안 검사에 실패한다고 밝혔다. METR의 연구는 더 놀랍다. 경험 있는 개발자조차 AI를 사용하면 19% 느려진다는 결과가 나왔다. 도구가 생산성을 높여줄 것이라는 직관과 정반대다.

오픈소스 커뮤니티의 반응은 더 직설적이다. Redox OS, Gentoo, NetBSD, postmarketOS는 AI 생성 코드를 아예 금지하는 정책을 채택했다. Debian은 “결정하지 않기로 결정”이라는 묘한 입장을 취했다. Hacker News에서는 “AI 생성 댓글 금지” 게시물이 2,748포인트로 1위에 올랐다.

Tailwind CSS의 사례는 AI 시대의 역설을 잘 보여준다. AI 코딩 도구들이 직접 코드를 생성하면서 공식 문서를 참조하는 트래픽이 40% 하락했고, 수익은 80% 급감했다. AI가 학습한 지식의 원천 자체가 경제적으로 지속 불가능해지는 구조적 문제다.

이 모든 데이터가 가리키는 방향은 하나다. “쉬우니까”라는 이유로 검증 없이 코드를 받아들이면, 그 대가는 반드시 돌아온다. 호어가 null로 10억 달러를 지불한 것처럼.

AI 시대에 Hoare의 유산이 더 중요해지는 이유

역설적이게도, AI가 코드를 대량 생산하는 시대에 호어의 형식 검증 철학이 그 어느 때보다 절실해지고 있다.

Martin Kleppmann은 **“Vericoding”**이라는 개념을 제안했다. AI가 코드를 생성하고, 형식 검증 도구가 그 코드의 정확성을 수학적으로 증명하는 방식이다. 인간이 해야 할 일은 “무엇을 원하는지”를 명세(specification)로 작성하는 것뿐이다.

이것은 호어가 1969년에 제안한 Hoare Logic의 현대적 실현이다. {P} C {Q} — 전제 조건과 후행 조건을 명시하면, 프로그램의 정확성을 자동으로 검증할 수 있다.

실제로 2025~2026년 사이에 AI와 형식 검증의 융합은 빠르게 진행되고 있다. Dafny를 이용한 자동 검증률은 68%에서 96%로 올라갔다. AI가 코드를 생성하는 속도와, 형식 검증이 코드를 검증하는 엄밀함이 결합되면, 호어가 꿈꿨던 “결함이 명백히 없는” 소프트웨어에 한 걸음 더 다가갈 수 있다.

호어의 격언을 다시 빌리자면:

바이브코딩 = “명백한 결함이 없을 정도로 복잡하게” 만드는 것
Vericoding = “결함이 명백히 없을 정도로 단순하게” 만드는 것

AI가 코드를 쓰는 시대에, 인간의 역할은 코드를 타이핑하는 것이 아니라 무엇이 올바른지를 정의하는 것으로 이동한다. 이것이야말로 호어가 반세기 동안 주장해온 바로 그것이다.

추모: “그는 옳았다, 다만 너무 일찍 태어났을 뿐”

2026년 3월 5일, 토니 호어가 91세의 나이로 세상을 떠났다.

Hacker News에 올라온 한 댓글이 그의 삶을 가장 잘 요약한다.

“He was right, just too early.”

호어는 옳았다. 단순성이 곧 신뢰성이라고 했을 때, 업계는 기능을 더 넣느라 바빴다. 형식 검증이 필요하다고 했을 때, 업계는 테스트 커버리지만 올리면 된다고 했다. null이 실수였다고 고백했을 때, 세상은 이미 NullPointerException 위에 쌓아올린 시스템으로 돌아가고 있었다.

그는 옳았다. 다만 세상이 그의 말을 이해하기까지 수십 년이 걸렸을 뿐이다.

호어와 다익스트라(Dijkstra)의 우정은 전설적이다. 다익스트라가 임종을 앞두고 서류를 정리할 때, 선배 교수가 수십 년간 쌓인 서신들을 어떻게 할지 물었다. 다익스트라의 답은 이랬다.

“Tony와의 편지만 보관하고, 나머지는 다 버려라.”

그 교수 자신의 편지도 포함해서. 두 사람이 평생에 걸쳐 나눈 지적 대화의 무게가 어떤 것이었는지를 말해주는 일화다.

호어는 92세 가까이까지 “pinpoint sharp”한 기억력을 유지했다고 한다. 캠브리지 Arts Picturehouse에서 몰래 영화를 보던 노학자. 60년 전 자신의 실수를 수만 명 앞에서 고백하는 용기를 가진 사람. 알고리즘 하나로 전 세계 컴퓨터의 속도를 바꾼 사람.

“Inside every large program is a small program struggling to get out.”

AI가 점점 더 크고 복잡한 코드를 쏟아내는 이 시대에, 호어의 이 마지막 격언은 경고이자 나침반이다. 복잡함 속에서 단순함을 찾아내는 것. 쉬운 것에 유혹되지 않고 올바른 것을 선택하는 것. 그것이 Tony Hoare가 우리에게 남긴 유산이다.

도구는 강력해졌다. 하지만 도구를 다루는 판단력은 여전히 인간의 몫이다.

Tony Hoare, 1934–2026. Rest in peace.