오컴의 면도날 — 90% 비용 절감한 아마존의 선택

14세기 영국의 프란체스코회 수사 윌리엄 오컴은 이렇게 말했다. “필요 없이 존재를 늘려서는 안 된다(Entities should not be multiplied beyond necessity).” 이 한 문장이 이후 수백 년간 과학, 철학, 통계학의 사고방식을 지배했다. 동일한 현상을 설명하는 두 가설이 있다면, 더 적은 가정을 요구하는 쪽을 선택하라. 이것이 오컴의 면도날(Occam’s Razor)이다.

그런데 이 원칙을 가장 자주 위반하는 사람들이 있다. 바로 소프트웨어 개발자와 AI 엔지니어였다.

소프트웨어 설계: 미래를 위한 과잉 투자

소프트웨어 엔지니어링에서 오컴의 면도날은 YAGNI(You Aren’t Gonna Need It)라는 이름으로 다시 태어났다. 익스트림 프로그래밍(XP) 방법론에서 비롯된 이 원칙은 단호했다. 지금 필요하지 않은 기능은 만들지 마라. 나중에 필요할 ‘것 같은’ 기능도 만들지 마라.¹

그러나 현실의 엔지니어링 조직은 반대 방향으로 움직이는 경우가 많았다. 트래픽이 초당 100건인 서비스에 초당 100만 건을 감당하는 아키텍처를 설계했다. 사용자가 10명인 사내 도구에 마이크로서비스 아키텍처를 적용했다. “확장성을 고려해서”라는 말은 과잉 엔지니어링의 가장 흔한 변명이었다.

마이크로서비스는 이 현상의 대표적 사례였다. 넷플릭스와 아마존 같은 대규모 조직이 마이크로서비스로 성공을 거두자, 규모와 맥락이 완전히 다른 팀들까지 이 아키텍처를 도입했다. 서비스 간 통신 비용, 분산 트랜잭션 관리, 배포 파이프라인의 복잡도는 기하급수적으로 늘어났다. 모놀리스 하나면 충분한 문제를 수십 개의 서비스로 쪼개 놓고, 그 서비스들을 다시 조율하느라 원래 문제보다 더 많은 시간을 썼다.

2023년, 아이러니하게도 마이크로서비스의 본산이라 할 수 있는 아마존에서 반례가 나왔다. Amazon Prime Video 팀은 오디오/비디오 품질 모니터링 서비스의 아키텍처를 분산 마이크로서비스에서 단일 통합 서비스로 전환했고, 인프라 비용을 90% 절감했다.² 분산 구조에서 서비스 간 데이터를 주고받는 과정 자체가 병목이었던 것이다. 더 복잡한 설계가 더 나쁜 결과를 만든 전형적인 사례였다.

비슷한 시기에 데이터 통합 플랫폼 Segment도 마이크로서비스에서 모놀리스로 회귀했다. 수백 개의 목적지 통합을 각각 독립 서비스로 운영하다가, 운영 부담이 감당할 수 없는 수준에 이르렀기 때문이었다.³ 단순한 구조로 돌아가자 배포 속도와 안정성이 동시에 개선되었다.

추상화의 비용: 간접층이 쌓일수록

소프트웨어 설계의 또 다른 함정은 추상화의 남용이었다. “모든 문제는 간접층(indirection)을 하나 더 추가하면 해결할 수 있다”는 격언이 있지만, 데이비드 휠러가 이 말에 덧붙인 후반부는 덜 인용된다. “간접층이 너무 많다는 문제만 빼고.” 인터페이스, 팩토리, 어댑터, 미들웨어가 겹겹이 쌓이면 코드를 읽는 사람은 실제 로직에 도달하기 전에 추상화의 미로를 헤매게 되었다. 디버깅 시간은 늘어나고, 새로운 팀원의 온보딩은 느려졌다. 추상화는 복잡성을 숨기는 것이지 제거하는 것이 아니었다.

AI와 머신러닝: 복잡한 모델의 유혹

머신러닝에서 오컴의 면도날은 수학적으로 더 정밀하게 정의되었다. 편향-분산 트레이드오프(bias-variance tradeoff)가 바로 그것이었다. 단순한 모델은 편향이 높지만 분산이 낮아 새로운 데이터에 안정적으로 작동했다. 복잡한 모델은 편향이 낮지만 분산이 높아 훈련 데이터의 노이즈까지 학습하는 오버피팅(overfitting)에 빠지기 쉬웠다.⁴

이 원칙은 정보 이론에서도 형식화되었다. 솔로모노프 귀납(Solomonoff induction)은 오컴의 면도날을 알고리즘 정보 이론의 언어로 번역한 것이었다. 어떤 데이터를 설명하는 가설이 여러 개 있을 때, 더 짧은 알고리즘적 기술(algorithmic description)을 가진 가설에 더 높은 사전 확률을 부여하라.⁵ 콜모고로프 복잡도(Kolmogorov complexity)라는 개념으로 ‘단순함’을 측정 가능하게 만든 것이다. 단순함은 직관이 아니라 수학적 원리였다.

그런데 2020년대 AI의 지배적 흐름은 이 원칙의 정면 반대 방향으로 달려갔다. 2020년 OpenAI의 Jared Kaplan 등이 발표한 스케일링 법칙(Scaling Laws) 논문은 모델 크기, 데이터양, 연산량을 키울수록 성능이 예측 가능하게 향상된다는 것을 보여주었다.⁶ 파라미터 수를 10배 늘리면 손실이 일정 비율로 줄어드는 멱법칙(power law) 관계가 관찰되었다. 이 발견은 “더 크게, 더 많이”라는 AI 업계의 군비 경쟁을 정당화했다.

그러나 스케일링 법칙에도 오컴의 면도날이 작동했다. 2022년 DeepMind의 Jordan Hoffmann 등이 발표한 Chinchilla 논문은 기존 대형 언어 모델들이 파라미터 수 대비 훈련 데이터가 심각하게 부족했음을 보여주었다.⁷ 2,800억 개 파라미터의 Gopher보다 700억 개 파라미터의 Chinchilla가 더 많은 데이터로 훈련했을 때 더 나은 성능을 냈다. MMLU 벤치마크에서 Chinchilla는 67.5%의 정확도를 기록하며 Gopher를 7% 이상 앞섰다. 모델을 키우는 것보다 주어진 연산 예산을 최적으로 배분하는 것이 더 중요했던 것이다. 더 작은 모델이 더 큰 모델을 이긴 순간이었다.

GPT-4를 쓸 것인가, 규칙 기반 시스템을 쓸 것인가

실무에서 마주치는 가장 흔한 오컴의 면도날 위반은 도구 선택에서 벌어졌다. 고객 문의를 분류하는 작업을 예로 들면, 키워드 매칭과 정규표현식 몇 줄로 90%의 정확도를 달성할 수 있는 경우에도, 팀은 종종 대형 언어 모델(LLM) 파이프라인을 구축하려 했다. API 비용, 레이턴시, 환각(hallucination) 가능성, 프롬프트 관리의 복잡도를 모두 감수하면서.

이는 특정 문제에만 해당하는 이야기가 아니었다. 산업 모니터링 분야의 비교 연구에 따르면, 규칙 기반 시스템은 도메인 지식이 명확한 환경에서 데이터 기반 모델과 동등하거나 그 이상의 성능을 보이면서도, 통합 및 유지보수 비용은 훨씬 낮았다.⁸ 하드코딩된 규칙 몇 줄이 PLC에서 바로 실행되는 반면, ML 모델은 데이터 수집 파이프라인, 모델 업데이트 메커니즘, 하드웨어 요구사항이라는 부가 비용을 수반했다.

Gerd Gigerenzer의 연구는 이 직관에 학문적 근거를 제공했다. 그의 저서 “Simple Heuristics That Make Us Smart”(1999)에서 제시된 ‘빠르고 검약한 휴리스틱(fast and frugal heuristics)‘은 정보의 일부만 사용하는 단순한 의사결정 규칙이 복잡한 통계 모델보다 예측 정확도가 높은 경우들을 체계적으로 보여주었다.⁹ 적은 정보가 체계적으로 더 나은 예측을 만들어내는 이 역설은 ‘적을수록 많다(less-is-more effect)‘로 명명되었다.

의사결정 비용: 선택지의 역설

오컴의 면도날은 기술 선택의 영역에서도 작동했다. 1952년 영국의 심리학자 William Edmund Hick은 자극-반응 실험을 통해 선택지의 수와 반응 시간 사이의 관계를 밝혀냈다. 선택지가 많아질수록 의사결정 시간은 로그 함수적으로 증가했다.¹⁰ 이것이 힉의 법칙(Hick’s Law)이었다.

프론트엔드 프레임워크를 고르는 상황을 생각해 보면 이 법칙의 힘을 실감할 수 있었다. React, Vue, Svelte, Angular, Solid, Qwik, Astro — 선택지는 계속 늘어났고, 각각의 장단점을 비교하는 시간도 함께 늘어났다. 기술 선택의 분석 마비(analysis paralysis)는 실제 개발 시간보다 더 많은 시간을 잡아먹기도 했다. 어떤 프레임워크를 선택하느냐보다 빨리 선택하고 구현을 시작하는 것이 프로젝트 성공에 더 큰 영향을 미치는 경우가 대부분이었다.

데이터베이스 선택도 마찬가지였다. PostgreSQL, MySQL, MongoDB, DynamoDB, CockroachDB, PlanetScale — 목록은 끝이 없었다. 그러나 대부분의 초기 프로젝트에서 PostgreSQL 하나면 충분했다. 관계형 데이터도, JSON 문서도, 전문 검색도, 지리 공간 쿼리도 처리할 수 있었다. “나중에 스케일링 문제가 생기면 어쩌지?”라는 걱정은 대부분 현실이 되지 않았다. 스케일링 문제가 생길 만큼 성공한 프로젝트는 그때 가서 마이그레이션할 자원도 갖고 있었다.

단순함이 답이 아닌 경우

여기까지 읽으면 “그러면 항상 단순한 쪽을 고르면 되는 것 아닌가”라는 결론에 도달하기 쉽다. 그러나 오컴의 면도날은 “가장 단순한 설명이 항상 옳다”고 말하지 않았다. “필요 없이 복잡성을 늘리지 마라”고 말했을 뿐이다. 핵심은 ‘필요 없이’라는 조건절에 있었다.

스케일링 법칙이 보여준 것처럼, AI에서는 실제로 복잡성을 늘려야만 해결할 수 있는 문제가 존재했다. 자연어 이해, 코드 생성, 다국어 번역 같은 과제에서 파라미터 수백억 개의 대형 모델은 규칙 기반 시스템이 도달할 수 없는 성능 수준을 보여주었다. 자율주행 자동차의 인지 시스템을 if-else 문으로 구현할 수 있다고 주장하는 사람은 없었다.

소프트웨어 아키텍처에서도 마찬가지였다. 넷플릭스의 마이크로서비스가 과잉 엔지니어링이 아닌 이유는, 수천 명의 엔지니어가 동시에 독립적으로 배포해야 하는 조직적 요구가 실재했기 때문이었다. 콘웨이의 법칙(Conway’s Law)에 따르면 시스템 구조는 조직 구조를 반영한다. 조직이 충분히 크고 복잡하다면, 아키텍처도 그에 맞게 복잡해져야 했다.

진짜 문제는 복잡성 자체가 아니라 정당화되지 않은 복잡성이었다. 10명이 쓰는 서비스에 쿠버네티스를 올리는 것, 분류 규칙 3개면 되는 문제에 딥러닝 파이프라인을 구축하는 것, 트래픽이 일주일에 한 번 오는 API에 분산 캐시를 도입하는 것. 이런 결정들이 오컴의 면도날을 위반하는 것이었다.

면도날을 드는 법

오컴의 면도날은 사고의 도구이지, 맹목적 규칙이 아니었다. 이를 실무에 적용하는 방식은 비교적 명확했다.

첫째, 현재의 요구사항에 맞는 가장 단순한 해결책에서 시작하라. 필요할 때 복잡성을 추가하는 것은 처음부터 복잡하게 만든 것을 나중에 단순화하는 것보다 항상 쉬웠다.

둘째, 복잡성을 추가할 때마다 그 비용을 명시적으로 계산하라. 새로운 서비스를 분리하면 네트워크 호출, 직렬화/역직렬화, 장애 전파 가능성이라는 비용이 따라왔다. 새로운 추상화 계층을 도입하면 인지 부하(cognitive load)가 증가했다. 이 비용이 그로 인해 얻는 이득보다 작은지 확인해야 했다.

셋째, “나중에 필요할 수도 있다”는 가장 위험한 정당화였다. YAGNI 원칙의 창시자 Ron Jeffries의 표현을 빌리면, 지금 구현하지 않으면 절대 필요 없는 기능에 드는 비용을 절약할 수 있었고, 정말 필요해질 때 더 많은 맥락을 가지고 더 나은 구현을 할 수 있었다.

결국 오컴의 면도날이 말하는 것은 이것이었다. 복잡성은 공짜가 아니다. 모든 추가 파라미터, 모든 추가 서비스, 모든 추가 추상화에는 눈에 보이지 않는 비용이 따라온다. 유지보수 비용, 인지 비용, 의사결정 비용. 그 비용을 지불할 명확한 이유가 있을 때만 복잡성을 받아들여야 했다.

단순함은 게으름이 아니었다. 정당화되지 않은 복잡성을 거부할 수 있는 용기였다.