이미 존재했던 이론
모든 MOAD 결함은 2026년 체계적인 탐지가 이루어지기 수십 년 전에 이미 해결책이 알려져 있었습니다. 결함이 지속된 이유는 아무도 더 나은 방법을 몰라서가 아닙니다. 아는 것과 탐지하는 것은 다르기 때문입니다.
MOAD-0001: O(N²) list.contains
Donald Knuth, 1973. The Art of Computer Programming, Volume 3: Sorting and Searching. 해시 테이블을 이용한 O(1) 조회가 1973년에 완전히 명세화되었으며, 분석 결과도 함께 제시되었습니다. O(N) 선형 탐색과 O(1) 해시 조회의 차이는 문서화되고 형식화되었으며 널리 인용되었습니다. Java는 1.0(1996)에서 HashSet을 제공했고, Python은 2.4(2004)에서 set을 일급 타입으로 도입했습니다. 이 해결책은 모든 생태계에서 기본 관용구가 되기 30년 전에 이미 존재했습니다.
Richard Hamming, 1986. Bell Labs 강의 (나중에 The Art of Doing Science and Engineering, 1997로 출판). Hamming은 알고리즘 복잡도, 정확성과 효율성의 차이, 그리고 소규모에서는 동작하지만 대규모에서는 실패하는 시스템을 구축하는 위험을 명확히 가르쳤다. 그는 이를 '오늘 볼 수 있는 문제가 아니라 내일 직면할 문제를 위한 설계'라고 불렀다.
MOAD-0002: 공유 전역 상태 결합
David Parnas, 1972. 'On the Criteria To Be Used in Decomposing Systems into Modules.' CACM, 1972년 12월. Parnas는 모듈을 정보 은닉 원칙에 따라 분해해야 한다고 주장했다. 각 모듈은 자신의 상태를 소유하며, 공유되는 가변 전역 변수는 없어야 한다. 이는 Intertangle 수정의 직접적인 이론적 선행자이다. Parnas는 명확히 밝혔다: 전역 공유 상태는 테스트로 드러나지 않는 보이지 않는 결합을 생성한다.
MOAD-0003: ThreadLocal Identity Leak
Java 1.2, 1998. ThreadLocal은 Java 표준 라이브러리 클래스로 제공되었다. 스레드 풀과 ThreadLocal이 공존하는 순간, 누수의 메커니즘이 존재하게 되었다. 결함은 구조적이다: 수명 주기가 작업 단위가 아니라 스레드인 캐리어. Java EE 생명주기 초기에부터 문서에서 이에 대해 경고했다.
MOAD-0004: Logged Credentials
RFC 1945, 1996. HTTP/1.0은 Authorization 헤더를 정의했다. 자격 증명 로깅 결함은 Authorization 헤더가 존재한 날부터 가능해졌다. OWASP는 2001년에 설립되었으며, 첫 가이드에서 자격 증명 로깅을 취약점 클래스로 문서화했다. 패턴: Authorization 헤더 → 로그 미들웨어 → 디스크에 평문 자격 증명. 최초의 HTTP 인증 명세부터 알 수 있었다.
MOAD-0005: Thundering Herd / Cache Stampede
Unix 커널, 1993. 'thundering herd problem' — 공유 이벤트 발생 시 N개의 프로세스가 동시에 깨어나는 현상 — 은 1990년대 초 Unix 커널 개발 논의에서 등장했습니다. Doug Schmidt의 Reactor 패턴(1994)과 Half-Sync/Half-Async(1995) 연구는 인프라 수준의 동기화 문제를 다루었습니다. 캐시 스탬피드 변형(N개의 스레드가 캐시 미스 시 동일한 값을 계산하는 현상)은 2001년 분산 시스템 문헌에 기록되었습니다. [BLOCK_TYPE knowable/theory_exists]
--- [BLOCK_TYPE knowable/theory_exists]
이론: 완성. 탐지 도구: 부재. '알 수 있음'과 '탐지됨' 사이의 격차는 결함에 따라 28년에서 54년까지 존재합니다.
알 수 있음의 격차(The Knowability Gap) [BLOCK_TYPE knowable/knowable_question]
타임라인은 모든 MOAD 결함이 체계적인 탐지보다 최소 28년 전에 이미 알려진 해결책을 가지고 있었음을 보여줍니다. 가장 짧은 격차(MOAD-0003)는 28년이며, 가장 긴 격차(MOAD-0002)는 54년입니다. [BLOCK_TYPE knowable/knowable_question]
이것은 무지(ignorance)에 관한 이야기가 아닙니다. Knuth, Parnas, Hamming — 이들은 컴퓨터 과학에서 가장 많이 인용되는 저자들입니다. 그들의 연구는 대학에서 교재로 사용되었습니다. 그들의 어휘(Big O, information hiding, algorithmic complexity)는 표준 커리큘럼이 되었습니다.
코드가 곪는 이유: 다섯 가지 조건
결함은 우연히 지속되지 않습니다. 다섯 가지 구조적 조건이 동시에 존재할 때 곪는 환경이 만들어집니다. 그중 하나라도 제거하면 탐지가 가능해집니다.
조건 1: 올바른 출력
목록과 집합은 멤버십 질문에 대해 동일하게 답합니다. list.contains(x)와 set.contains(x)는 동일한 boolean을 반환합니다. ThreadLocal이 오래된 identity를 가지고 있어도 여전히 an identity를 가지고 있습니다 — 단지 잘못된 요청에 속할 뿐입니다. 기록된 자격 증명은 올바르게 기록됩니다 — 자격 증명이 오류 없이 로그 파일에 도달합니다. 결함은 오작동이 아닙니다. 비용 또는 보안 결과에서만 오작동입니다. 출력 결과를 확인하는 테스트는 통과합니다. 비용 또는 보안 결과를 확인하는 테스트: 대부분 작성되지 않았습니다.
Condition 2: CI에 복잡도 테스트 없음
Dijkstra는 '테스트는 결함의 존재를 보여줄 뿐, 결함의 부재를 보여주지는 않는다'라고 말했습니다. Hamming은 이를 확장했습니다: 우리가 테스트하는 결함이 우리가 발견하는 결함입니다. 2026년 CI 파이프라인은 다음을 테스트합니다: 정확성, 타입 안전성, API 계약, 기능적 동작. 다음은 테스트하지 않습니다: 연산당 알고리즘 복잡도, 호출당 메모리 증가, authorization-header 정리, 스레드 identity 생명주기.
실행되는 테스트가 없습니다. 실패하는 테스트가 없습니다. 파이프라인은 녹색입니다. 결함은 보이지 않습니다.
Condition 3: Small-N 기원
코드는 개발 환경에서 작성되고 리뷰됩니다. 개발 그래프는 50개의 노드를 가집니다. 개발 요청 부하는 10개의 동시 스레드를 가집니다. 개발 캐시 미스율은 낮습니다 (warm cache, 적은 키). N=50에서 O(N²) 비용은 2,500 연산입니다. 보이지 않습니다. N=50,000에서 비용은 2,500,000,000 연산입니다. 1초 빌드 대신 17분 빌드.
코드를 작성한 작성자는 N=50,000을 본 적이 없습니다. 이를 승인한 리뷰어도 N=50,000을 본 적이 없습니다. 결함은 작성 당시의 규모에서는 보이지 않았습니다.
Condition 4: 컨텍스트 없이 복제 전파
올바른 알고리즘은 교훈적이다. 튜토리얼은 올바른 예제로 가르친다. 문서는 동작하는 코드를 보여준다. 동일한 Tarjan SCC 골격 — visited = [], 내부 if n not in visited — 이 GHC, Maven, Python pip, Cargo, TypeScript 컴파일러, Kotlin 컴파일러, Scala 컴파일러, javac에 모두 등장한다. 팀은 다르고, 언어는 다르고, 시대도 다르다. 그러나 같은 화석이 남아 있다. 원저자의 N=50은 코드와 함께 전파되지 않는다. 전파되는 것은 올바른 출력뿐이다. 남겨지는 것은 성능 가정이다.
조건 5: 고정된 코드 주위로 규모가 성장한다
코드는 퇴화하지 않는다. 인프라는 확장된다. 2003년에 200개 패키지를 위해 작성된 의존성 해결기는 2024년에 50,000개 패키지에서 실행된다. 아무도 이를 다시 작성하지 않는다 — 동작하기 때문이다. 아무도 프로파일링하지 않는다 — CI가 녹색이기 때문이다. O(N²) 비용을 치명적으로 만드는 N은 점진적으로, 보이지 않게, 프로덕션 규모에서 도래한다. 그때쯤이면 원저자는 이미 떠났다. 코드는 의존성이 되어 있다. 아무도 동작하는 의존성을 건드리지 않는다.
진단: 다섯 가지 조건
다섯 가지 조건: 올바른 출력, 복잡도 테스트 부재, 작은 N의 기원, 맥락 없는 복사, 고정된 코드 주위로 규모가 성장.
모든 MOAD에서 이 다섯 조건이 동시에 존재했다. 이는 우연이 아니라, 퇴적 결함 클래스의 구조적 특징이다.
해밍이 말한 것
1986년 벨 연구소에서 리처드 해밍이 진행한 강의(1997년 《The Art of Doing Science and Engineering》로 출간)에는 MOAD 결함 패턴을 직접적으로 설명하는 듯한 경고가 담겨 있습니다. 그는 MOAD를 설명한 것이 아니라, 국지적으로는 올바른 결정들이 결국 전역적으로 비용이 커지는 공학 시스템의 구조적 경향을 설명한 것입니다.
해밍의 복잡성 관련 발언: “컴퓨팅의 목적은 통찰이지 숫자가 아니다. 그러나 올바른 복잡도의 알고리즘이 있어야 숫자가 나올 수 있다. N=100에서 동작하는 O(N²) 알고리즘은 은퇴하기 전에 N=1,000,000에서는 동작하지 않을 것이다.”
해밍의 복제 관련 발언: “위대한 엔지니어는 단순히 해결책을 복제하지 않는다. 그들은 왜 그 해결책이 작동하는지, 어떤 조건에서 성립하는지, 그리고 무엇이 그것을 깨뜨릴지를 이해한다. 조건 없이 복제된 해결책은 시한폭탄이다.”
해밍의 테스트 관련 발언: “측정한 것을 테스트하는 것은 중요한 것을 측정하는 것과 같지 않다. 우리는 테스트하기로 선택한 속성에 대해 정교한 테스트 스위트를 구축한다. 선택하지 않은 속성은 테스트하지 않은 채로 남겨둔다. 테스트하지 않은 것이 바로 운영 환경에서 우리를 놀라게 한다.”
Hamming on scale: '프로젝트 첫해에 저지르는 오류는 10년째에도 여전히 수정하고 있는 오류다. 초기 가정은 굳어진다. 프로젝트는 그 가정을 중심으로 확장된다. 아무도 기반을 다시 작성하지 않는다.'
경고와 운영화 사이의 간극
Hamming의 경고는 옳았다. 그것은 가르쳐졌고, 인용되었으며, 교육과정에 포함되었다. 그러나 경고는 탐지기가 아니다. Hamming은 결함의 형태를 설명했을 뿐, CI에서 실행되어 O(N²) 핫 패스, ThreadLocal 식별자 누수, 또는 자격증명 로깅을 플래그하는 도구를 만들지는 않았다. '알 수 있는 것'과 '탐지 가능한 것' 사이의 간극은 이론과 자동화된 인프라로서의 운영화 사이의 간극이다.
MOAD가 존재하는 이유는 이 분야가 정확성 인프라는 구축했지만, 동일한 수준의 성능 또는 보안 인프라는 구축하지 않았기 때문이다. 단위 테스트: 1970년대부터 표준. 속성 기반 테스트: 1990년대부터 표준. CI에서의 알고리즘 복잡도 벤치마크: 2026년에도 여전히 실험적이다.
경고의 운영화
Hamming은 복잡성의 굳어짐, 테스트되지 않은 속성, 조건 없이 복사된 솔루션, 그리고 규모가 초기 가정을 짓누르는 현상에 대해 경고했다. 그는 우리에게 어휘를 주었다. 그러나 탐지기는 주지 않았다.
MOAD 파이프라인은 그 간극을 메운다: 스캔 → 티켓 → 패치 → 단위 테스트 → 공개 → PR → 업스트림 병합. 이것이 운영화된 Hamming이다. 단순한 경고가 아니라, 자동화된 탐지와 수정 파이프라인이다.
The Fester Signature
A MOAD-class defect has a recognizable signature. All five conditions present simultaneously. All five are checkable before writing a single scan:
1. Correct output? Run the standard test suite. If it passes, the defect is a performance or security property, not a correctness one. This means standard CI will not catch it.
2. 복잡도 테스트 없음? CI 설정을 확인하세요. 벤치마크 단계가 있는가? 알고리즘 동작(단순한 wall time이 아닌)을 이전 커밋과 비교하는가? 없다면: 조건 존재.
3. Small-N 기원? git blame과 최초 커밋을 확인하세요. 최초 구현 당시 데이터셋 크기는 얼마였는가? 현재 프로덕션 부하보다 100배 이상 작은가? 그렇다면: 조건 존재.
4. 복제 전파? 코드베이스 전체와 생태계 전반에서 패턴을 검색하세요. 동일한 구조적 패턴이 공통 조상 없이 N≥3개의 독립적인 코드베이스에 나타나는가? 그렇다면: 화석이 전파된 것임. 각 복제본: 새로운 fester site.
5. 규모 증가? 프로덕션 메트릭을 확인하세요. 최초 배포 당시 N 대비 현재 N은 얼마인가? 성장률이 지속되는가? 어떤 N에서 결함이 운영상 치명적이 되는가?
다섯 가지 모두 확인되고 검증되었다면: MOAD-class 결함이 존재한다. 수정은 항상 한 줄 또는 한 메서드 치환으로 이루어진다. 발견이 어려운 부분이고, 수정은 쉬운 부분이다.
이것이 Hamming이 말한 바이다: 엔지니어링은 수정에 관한 것이 아니다. 일단 보면 수정은 간단하다. 엔지니어링은 그것을 볼 수 있게 해주는 시스템을 구축하는 것이다.
시그니처 적용하기
MOAD fester 시그니처: 올바른 출력 + 복잡도 테스트 없음 + Small-N 기원 + 복제 전파 + 규모 증가.
이 시그니처는 다섯 가지 MOAD 결함에 국한되지 않습니다. 정확성 테스트만이 유일한 자동화된 품질 게이트인 모든 시스템에서 지속되는 결함 클래스를 설명합니다.