모든 AI 개발 아키텍처가 실패하는 생존 가능성 테스트

이 글은 harness 관련 기사인 The Harness is Half the Architecture를 바탕으로 작성되었습니다. 이 5요소 프레임워크는 TRIZ의 시스템 완전성 법칙 (Altshuller가 제안하고 Savransky와 Mann이 확장함)에서 가져왔으며, 여기서는 AI 보조 개발 (AI-assisted development)에 적용되었습니다.

진단 이면에 있는 법칙

이전 기사에서는 지배적인 에이전트 아키텍처(agent architecture)인 "에이전트 (Agent) = 모델 (Model) + 하네스 (Harness)"가 나머지 절반, 즉 독립적 검증 (independent verification), 선언된 의도 (declared intent), 조정 프로토콜 (coordination protocols), 그리고 제거 규율 (subtraction discipline)이 결여되어 있다고 주장했습니다. The Harness is Half the Architecture

해당 기사가 공백을 진단했다면, 이 기사는 아키텍처를 처방합니다. 이는 공학 시스템을 생존 가능하게 만드는 요소를 식별하기 위해 수백만 개의 특허를 분석한 프레임워크에서 도출된, 작동하는 시스템이 무엇을 필요로 하는지에 대한 구조적 법칙입니다.

작동하는 시스템은 다섯 가지 필수 요소를 가집니다. 어떤 요소라도 누락되면 시스템은 작동하지 않습니다. 어떤 요소라도 실패하면 시스템은 생존할 수 없습니다. 더 빠른 출시를 위해 필수 요소를 깎아낼 수는 없습니다. 오직 동일한 기능을 수행하는 다른 것으로 대체할 수 있을 뿐입니다. 이를 삭제하는 것은 생존 불가능한 시스템을 만들며, 이것이 현재의 에이전트 아키텍처 상태입니다.

이 다섯 가지 요소는 새로운 아이디어가 아닙니다. 이들은 공학 (TRIZ), 사이버네틱스 (Beer의 Viable System Model), 그리고 경제학 (Nalebuff와 Brandenburger의 value-net 모델)이라는 세 개의 서로 다른 분야에서 독립적으로 확인되었습니다. 서로 다른 데이터로 구축된 세 가지 프레임워크가 동일한 5부 구조에 도달했습니다. 이러한 수렴은 이 분해가 특정 학파의 어휘로 만들어진 인위적인 결과가 아니라 실제적이라는 증거입니다.

생존 가능한 시스템의 요소

이 5요소 템플릿은 아키텍처 (architecture)가 아닙니다. 이것은 완전성 법칙 (completeness law)입니다. 즉, 생존 가능한 시스템이 반드시 포함해야 하는 요소들에 대한 도메인 중립적인 청사진입니다. TRIZ는 이를 **법칙 (Law)**이라 부르고, Beer는 이를 **생존 시스템 모델 (Viable System Model)**이라 부르며, Nalebuff와 Brandenburger는 이를 **게임의 요소 (elements of a game)**라고 부릅니다. 항공 분야에서는 동일한 구조를 **엔벨로프 보호 (envelope protection)**라고 부르고, 원자력 분야에서는 **심층 방어 (defense in depth)**라고 부릅니다. 제어 이론 (control theory)에서는 이를 **폐루프 조절기 (closed-loop regulator)**라고 부릅니다. 그 어느 곳에서도 이를 아키텍처라고 부르지 않습니다.

Fly-by-wire, 원자로 인터록 (reactor interlocks), 거래 전 리스크 체크 (pre-trade risk checks), 또는 아래의 AI 개발 스택과 같은 구체적인 구현체는 **아키텍처 (architecture)**입니다. 즉, 5가지 요소를 인스턴스화 (instantiate)하는 하나의 방법입니다. 따라서 여기서의 주장은 "여기에 올바른 아키텍처가 있다"가 아니라, 더 강력하고 검증 가능한 주장입니다.

현재의 AI 개발 아키텍처는 불완전합니다. 왜냐하면 항공, 원자력, 트레이딩, 제어 시스템이 독립적으로 충족하고 있는 동일한 생존 청사진 (viability blueprint)을 기준으로 테스트했을 때, 5가지 필수 요소 중 2가지가 누락되어 있기 때문입니다.

이것이 중요한 이유는 "우리의 아키텍처가 더 낫다"라는 말은 "누가 그러는데?"라는 반문에 부딪히기 때문입니다. 하지만 "서로 관련 없는 7개의 도메인이 이미 충족하고 있지만, 당신의 아키텍처는 충족하지 못하는 생존 불변량 (viability invariant)이 있다"라는 말은 차원이 다른 주장입니다. 이는 반증 가능 (falsifiable)합니다. 누락된 두 요소가 존재함을 보여준다면 이 주장은 무너집니다. 하지만 아무도 그것을 보여주지 못했는데, 그 이유는 그 요소들이 존재하지 않기 때문입니다. 여기에는 OpenAI, Anthropic, LangChain에 의한 현재 AI 아키텍처의 비교도 포함됩니다.

완전한 AI 개발 시스템의 5요소

모든 작동하는 공학 시스템은 이 5가지 요소를 가지고 있습니다. AI 보조 개발을 위한 이 요소들을 살펴보겠습니다.

1. 도구 (The Tool) — 모델 (the model)

모델은 작동하는 도구입니다. 가치를 더하는 주요 활동입니다. 결과물(artifact)을 만들어내는 대상입니다. 코드, 인프라 템플릿, 문서, 테스트 등이 이에 해당합니다. 이것이 harness 기사의 초점이며, 업계가 가장 공격적으로 투자하는 부분입니다.

현재의 아키텍처에서는 모델이 곧 시스템으로 취급됩니다. 그 외의 모든 것은 "harness" — 즉, 주요 구성 요소를 위한 지원 인프라에 불과합니다. 하지만 법칙은 다르게 말합니다. 도구는 다섯 가지 요소 중 하나일 뿐입니다. 도구는 시스템이 아닙니다. 심지어 가장 중요한 요소도 아닙니다. 제어 장치(control unit)가 없는 작동하는 도구는 아무도 검증할 수 없는 출력을 만들어내는 기계일 뿐입니다. 엔진이 없는 작동하는 도구는 방향성 없이 돌아가는 기계입니다. 모델은 필수적입니다. 하지만 그것만으로는 충분하지 않습니다.

2. 엔진 (The Engine) — 선언된 의도

엔진은 추진력입니다. AI 지원 개발(AI-assisted development)에서 엔진은 명세 (specification) 입니다. 즉, 무엇이 올바른 것인지, 시스템이 무엇을 충족해야 하는지, 그리고 작업 뒤에 숨겨진 의도가 무엇인지를 인간이 작성하여 선언하는 것입니다.

명세가 없다면 생성(generation)은 동력을 얻지 못합니다. 모델은 출력을 만들어내지만, 그것이 무엇을 향하는 것일까요? 프롬프트(prompt)는 원시 명세(proto-specification)입니다. 그 안에 의도가 담겨 있기는 하지만, 일시적이고 모호하며 사용 후에는 버려집니다. 반면 명세는 내구성이 있고, 정밀하며, 버전이 관리되고, 기계적으로 검증 가능합니다. 이는 대화 중에 누군가에게 원하는 것을 한 번 말하는 것과, 양측이 참조할 수 있도록 계약서에 적어두는 것의 차이와 같습니다.

엔진은 구현(implementation)에 동력을 공급합니다. 명세는 생성을 주도합니다. 명세가 없다면 모델은 작동하지만 어디로도 나아가지 못합니다. 이는 "바이브 코딩 (vibe coding)"의 실패 모드와 같습니다. 생성 과정은 생산적인 것처럼 느껴지지만, 정의된 목표가 없기 때문에 출력이 정의된 타겟을 향해 수렴하지 않는 상태를 말합니다.

3. 변속기 (The Transmission) — 전달 및 계약

변속기는 엔진의 에너지를 도구의 출력으로 전달합니다. AI 지원 개발에서 변속기는 두 가지 계층을 가집니다.

전달 레일 (The delivery rail) — CI/CD, GitOps, 코드형 인프라 (Infrastructure as Code). 커밋(commit)부터 빌드(build)를 거쳐 배포(deploy)에 이르기까지 변경 사항을 이동시키는 메커니즘입니다. 이것은 대부분의 팀이 이미 갖추고 있으며, 잘 운영하고 있는 부분입니다. 빠르고 자동화되어 있으며 신뢰할 수 있습니다.

계약 계층 (The contract layer) — 에이전트 간의 기계 판독 가능한 계약 (contracts), 스키마 (schemas), 인터페이스 정의 (interface definitions), 그리고 구조화된 내보내기 (structured exports)입니다. 여러 에이전트가 공유 코드베이스에서 작업할 때, 에이전트 간의 전송은 공유 파일 시스템이 아닙니다. 그것은 각 에이전트의 출력이 반드시 충족해야 하는 선언된 제약 조건 (declared constraints)입니다. 공유 상태 (shared state)가 아닌 명세 (specifications)를 통한 조정입니다.

이러한 전송 메커니즘은 현재 대부분의 아키텍처에 존재합니다. 제대로 작동합니다. 그것이 문제입니다. 제어 장치 (control unit)가 없는 빠르고 신뢰할 수 있는 전송은 검증되지 않은 (unverified) 변경 사항을 기계적 속도로 충실하게 전달할 뿐입니다. 검증 게이트 (verification gate)가 없는 CI/CD는 폭탄을 완벽한 신뢰성으로 배달하는 우편 서비스와 같습니다. 전송 시스템이 고장 난 것이 아닙니다. 그 위에 올라타야 할 제어 장치가 부재한 것입니다.

4. 제어 장치 (The Control Unit) — 독립적인 오라클 (independent oracle)

제어 장치는 명세 (specification)에 따라 출력을 측정하고, 결정론적인 판결 (deterministic verdict)을 내리며, 수정 사항을 생성 과정에 다시 피드백합니다. 이것이 현재 아키텍처에 결여된 요소입니다.

제어 장치는 자신의 출력을 검토하는 모델이 아닙니다. 자기 검증 (Self-verification)은 생성기의 사각지대 (blind spots)와 상관관계가 있습니다 — Huang et al. (ICLR 2024)은 자기 검증이 추론을 개선하기보다 오히려 저하시킨다는 것을 입증했습니다. 제어 장치는 생성기와 독립적이어야 하며, 검증하는 도구보다 더 높은 수준의 논리적 확실성 (higher level of logical certainty) 단계에서 작동해야 합니다. 시(poem)로 다리를 검증하지 않듯, 물리 법칙으로 다리를 검증합니다. 확률적인 출력을 또 다른 확률적인 시스템으로 검증하지 마십시오. 타입 체커 (type checker), 속성 기반 테스트 스위트 (property-based test suite), 계약 강제기 (contract enforcer), CEL 술어 평가기 (CEL predicate evaluator), Z3 증명 (Z3 proof) 등 모델의 실패 모드 (failure modes)와 상관관계가 없는 기계적이고 결정론적인 시스템으로 검증해야 합니다.

단순한 게이트가 아니라 양방향(bidirectional)입니다. 오라클(oracle)은 단순히 출력을 통과시키거나 실패시키는 것에 그치지 않습니다. 오라클은 생성(generation) 과정으로 수정 사항을 다시 피드백합니다 — 즉, 생성(generate) → 검증(verify) → 수정(fix) 루프를 형성합니다. 실패한 어설션(assertion)은 모델에게 무엇이 실패했는지와 왜 실패했는지를 알려주며, 다음 생성 시도가 명세(specification)를 따르도록 유도합니다. 제어 장치(control unit)는 도구를 지배하며, 단순히 출력을 검사하는 데 머물지 않습니다.

전송(transmission) 옆에 있는 것이 아니라, 전송 과정 위에서 작동합니다. 검증(verification)은 별도의 파이프라인이 아닙니다. 그것은 CI/CD 레일에 부착된 게이트입니다. 전송 경로를 통과하는 모든 변경 사항은 오라클을 거칩니다. 게이트를 제거하면 전송 시스템은 검증되지 않은 변경 사항을 그대로 전달하게 됩니다. 오라클은 레일을 타고 함께 달립니다.

5. 케이싱(The Casing) — 경계와 연속성

케이싱(casing)은 시스템과 환경 사이의 연결 고리입니다. AI 지원 개발에서 케이싱은 두 가지 측면을 가집니다.

경계(Boundaries) — Parnas 스타일의 정보 은닉(information hiding), 육각형 아키텍처(hexagonal architecture), 모듈 격리(module isolation)를 의미합니다. 각 컴포넌트 주변의 케이싱은 에이전트(agent)가 자신이 소유하지 않은 모듈로 경계를 넘어 침범하는 것을 방지합니다. 경계가 없다면 에이전트는 기회가 생기는 즉시 경계를 넘나들 것이며, 시스템은 독립적인 검증을 가능하게 하는 아키텍처적 무결성(architectural integrity)을 잃게 됩니다.

연속성(Continuity) — 시스템이 스스로의 불완전함을 가정하고, 지속적인 모니터링과 업데이트를 통해 이를 보완한다는 입장입니다. Vassilev의 NIST 증명 (2026년 6월 9일)은 이를 공식화했습니다: 어떤 유한한 규칙 집합도 보편적으로 견고할 수는 없습니다. 케이싱은 완결성을 주장함으로써가 아니라, 커버리지(coverage)를 지속적으로 확장하고 격차(gap)가 항상 존재할 것임을 인정함으로써 적대적이고 변화하는 환경으로부터 시스템을 보호합니다.

이 케이싱(casing)에는 감산 규율 (subtraction discipline) 또한 포함됩니다. 이는 시스템에 속해야 하는 것과 시스템을 희석시키는 것 사이의 경계입니다. 범위 관리(Scope management). 명명된 본질(Named essence). 축적(accumulation)이 비대화(bloat)로 변하는 것을 방지하는 힘입니다. 이것은 필수적인 요소를 깎아내는 것이 아닙니다 (법칙은 그것을 금지합니다). 시스템의 일관성을 유지하기 위해 범위와 기능을 다듬는 것입니다. 즉, 브레이크 시스템을 제거하는 것(생존 불가능)과 제품의 정체성을 흐리는 기능을 제거하는 것(이상성(ideality)의 증가) 사이의 차이입니다.

실제로 이것은 '아니오'라고 말할 수 있는 능력이며, 2026년에는 디자인 선호도의 문제가 아니라 생존 비용의 문제입니다. 에이전트가 10줄짜리 문제를 해결하기 위해 만 줄의 코드를 추가하는 에이전트 비대화(Agentic bloat)는 추론 비용(inference bills)이 급증하는 주요 원인입니다. 생성된 모든 불필요한 줄은 소모되는 토큰이며, 공격 표면(surface area)의 확장이며, 검증 부하(verification load)의 증가입니다. 감산이 없는 케이싱은 무한히 축적되는 시스템이며, 그 축적에 대한 비용은 매달 추론 인보이스(inference invoice)로 청구됩니다. 감산 규율은 비용 곡선을 꺾는 요소입니다. 적게 생성하고, 적게 검증하며, 적게 유지보수하고, 적게 공격받게 합니다.

법칙을 이용한 진단

현재의 "모델 + 하네스 (Model + Harness)" 아키텍처를 이 다섯 가지 요소에 대조해 보십시오:

quadrantChart
    title Current AI-Dev Architecture Completeness
    x-axis Absent --> Present
...

quadrantChart
    title Current AI-Dev Architecture Completeness
    x-axis Absent --> Present
...

강력하며 존재함 (Strong and Present):

• 도구 (Tool, 모델) — 막대한 투자가 이루어지고 있으며, 빠르게 개선되고 있고, 업계의 중심입니다.
• 전송 (Transmission, CI/CD) — 성숙하고, 빠르며, 신뢰할 수 있습니다. 대부분의 팀이 이를 보유하고 있습니다.

강력하지만 부재함 (Strong and Absent):

• 제어 유닛 (Control Unit, 독립적 검증) — 시스템에 강력히 필요하지만 완전히 부재합니다. 검증이 아닌 자기 검증(self-verification)으로 대체되어 있습니다. 가장 결정적으로 누락된 요소입니다.

약하며 부재함 (Weak and Absent):

• 케이싱 (Casing) (경계 + 연속성) — 이해도가 낮고 부재합니다. 에이전트를 위한 강제된 모듈 경계(module boundaries)가 없으며, 지속적인 모니터링 태세(continuous-monitor stance)도 없고, 차감 규율(subtraction discipline)도 없습니다. 업계는 아직 이 요소가 존재해야 할 필요성을 인식하지 못하고 있습니다.

약하지만 존재함 (Weak and Present):

• 엔진 (Engine) (의도/사양) — 프롬프트(prompts)와 AGENTS.md 파일 형태로 존재하지만, 일시적이며 기계적으로 검증할 수 없습니다. 실제 엔진이 아닌 프로토-엔진(proto-engine) 수준입니다.

다이어그램은 다음을 참조하십시오: https://gist.github.com/sufield/3d511936af9f80914f7e8622e0e0b1cb

법칙에 따르면: 어떤 요소라도 누락되면 시스템은 작동하지 않습니다. 현재의 아키텍처는 강력한 도구와 빠른 전송 수단, 그리고 약한 엔진을 가지고 있지만 — 제어 장치(control unit)와 케이싱(casing)은 없습니다. 법칙의 정의에 따라, 이는 불완전한 시스템입니다. 출력(output)을 만들어내기는 하지만, 그 출력이 올바른지 검증할 수 없습니다. 시간이 흐름에 따라 아키텍처의 무결성(architectural integrity)을 유지할 수 없습니다. 무엇이 속해 있는 것인지, 무엇이 희석되는 것인지 구분할 수 없습니다.