Golden Armada: 실행 단계에서 AI 네이티브 소프트웨어가 보여주는 모습

👉 소스 코드 및 시스템:

golden_armada
Programming-Paradigm-for-AI-Written-Software

👉 이전 기사 (문맥):

a vibe coding programming paradigm

소프트웨어가 더 이상 주로 작성되는 것이 아니라, AI 주도의 의사결정을 통해 실행된다면 어떤 일이 벌어질까요?

이 기사에서 저는 작동하는 시스템과 그것이 런타임 (runtime)에 실제로 무엇을 생성하는지 보여드리고자 합니다.

선언문은 없습니다. 이론적 확장도 없습니다.

오직 실행뿐입니다.

문맥: "바이브 코딩 (vibe coding)"에서 런타임 실체로

이전 기사에서 저는 바이브 코딩 (vibe coding)이라는 개념을 소개했습니다. 이는 AI가 주요 코드 생성기가 되고, 인간은 구현 (implementation)보다는 의도 명세 (intent specification)로 전환되는 프로그래밍 패러다임 (programming paradigm)입니다.

그 아이디어는 즉각적인 질문을 던집니다:

그러한 시스템이 실제로 실행될 때는 어떤 모습일까요?

Golden Armada는 실험적으로 그 질문에 답하기 위한 저의 시도입니다.

Golden Armada란 무엇인가?

Golden Armada는 다음과 같은 AI 네이티브 (AI-native) 워크플로 엔진입니다:

사용자가 구조화된 UI를 통해 동작을 트리거합니다.
LLM ("DeepAgent")이 실행 단계를 계획합니다.
엄격한 계약 시스템 (contract system)이 변이 (mutations)를 적용합니다.
모든 동작은 불변의 트레이스 (immutable trace)로 기록됩니다.

핵심 아이디어는 간단합니다:

시스템은 코드를 통해 이해되는 것이 아니라, 실행 트레이스 (execution traces)를 통해 이해됩니다.

아키텍처 개요

시스템은 엄격한 실행 파이프라인 (execution pipeline)을 따릅니다:

사용자 동작 (User Action)
   ↓
수집 계층 (Intake Layer)
...

주요 제약 사항:

모든 연산은 강력한 타입 (strongly typed)을 가집니다.
실행은 계획 (planning) 이후 결정론적 (deterministic)입니다.
상태 변경은 이벤트 기반 (event-based)입니다.
모든 것은 관찰 가능 (observable)합니다.

이는 의도적으로 전통적인 애플리케이션보다 실행 머신 (execution machine)에 가깝게 설계되었습니다.

왜 트레이스 (traces)가 코드보다 중요한가

전통적인 시스템에서 디버깅 (debugging)은 코드를 읽고 동작을 추론하는 것을 의미합니다.

Golden Armada에서 디버깅은 다음과 같습니다:

실행 트레이스 (execution traces)를 읽고 시스템 동작을 재구성하는 것입니다.

이는 이미 분산 시스템 (distributed systems)이 작동하는 방식에 더 가깝지만, AI 기반 의사결정 계층 (AI-driven decision layers)으로 확장된 형태입니다.

실제 실행 트레이스 (예시)

아래는 시스템에 의해 생성된 실제 트레이스입니다:

trace_id: ea7e24fc11dc43bdbfeacedbc628e9fd

[OK] Request received
...

👉 전체 로그는 여기서 확인 가능합니다:
https://github.com/evgeniykormin86-stack/golden_armada/tree/main/logs

이 트레이스가 보여주는 것

이 작은 예시에서도 다음과 같은 사항을 관찰할 수 있습니다:

시간이 어디에 소비되는지 (LLM 계획 (planning)이 지배적임)
결정론적 실행 (deterministic execution)이 계획을 어떻게 따르는지
작업 (operations)을 통해 워크플로 변이 (workflow mutation)가 어떻게 발생하는지
시스템이 감사 가능성 (auditability)을 어떻게 유지하는지

중요한 변화는 다음과 같습니다:

런타임 (runtime)이 이해를 위한 주요 인터페이스가 됩니다.

실패 사례 (마찬가지로 중요함)

모든 실행이 성공하는 것은 아닙니다.

예시:

[ERR] Node not found: split

이 트레이스는 다음을 보여줍니다:

LLM이 작업을 올바르게 계획했으나
워크플로 상태 (workflow state)가 예상과 일치하지 않았으며
실행 중에 시스템이 결정론적으로 실패했음을 보여줍니다.

이 점이 중요합니다:

AI 계획 (planning)이 시스템의 유효성 (validity)과 동일한 것은 아닙니다.

시스템의 설계 철학

Golden Armada는 네 가지 제약 사항을 중심으로 구축되었습니다:

AI는 중복 비용 (duplication cost)을 변화시킵니다. 핵심 로직을 다시 쓰는 대신, 새로운 "기술 (skills)"을 생성함으로써 새로운 동작을 도입할 수 있습니다.
그래프 복잡성 (Graph complexity)은 의도적으로 제한됩니다. 지수적인 추론 복잡성 (exponential reasoning complexity)을 피하기 위해 워크플로 깊이를 제한합니다.
계약 (Contracts)이 암시적 구조를 대체합니다. 구성 요소 간의 모든 통신은 엄격하게 타입이 지정되고 검증됩니다.
관찰 가능성 (Observability)은 일급 기능 (first-class feature)입니다. 추적 가능 (traceable)하지 않다면, 시스템 내에 존재하지 않는 것과 같습니다.

이 시스템이 "아닌" 것

오해를 피하기 위해 명시합니다:

자율 에이전트 시스템 (autonomous agent system)이 아닙니다.
프로덕션 준비가 된 인프라 (production-ready infrastructure)가 아닙니다.
소프트웨어 엔지니어링의 대체재가 아닙니다.
완전히 자기 진화하는 시스템 (fully self-evolving system)이 아닙니다.

이 시스템은:

완전한 관찰 가능성 (full observability)을 갖춘 AI 주도 워크플로우 (AI-driven workflows)를 위한 실험적 실행 환경 (experimental execution environment).

이것이 중요한 이유 (핵심 통찰)

오늘날 대부분의 AI 시스템이 실패하는 이유는 출력을 생성하지 못해서가 아니라, 다음과 같은 이유 때문입니다:

내부 의사결정 과정 (internal decision process)을 관찰하거나 재현할 수 없기 때문입니다.

Golden Armada는 다른 방향을 탐구합니다:

지능을 구현하기에 앞서, 실행을 먼저 관찰 가능하게 만드는 것 (make execution observable first, intelligent second).

한계점 (정직한 분석을 위해 중요)

현재의 한계점은 다음과 같습니다:

워크플로우 (workflows) 규모의 제한
비결정론적 (non-deterministic) LLM 계획 (planning)
트레이스 (trace) 볼륨의 급격한 증가
디버깅 (debugging)에 여전히 인간의 해석이 필요함
기능 확장 시 시스템 복잡도 증가

이는 현재 단계에서 예상되는 부분입니다.

향 향후 방향

이 실험의 다음 단계에는 다음이 포함됩니다:

트레이스 (traces)로부터의 자동 테스트 생성
실패 클러스터링 (failure clustering) 및 패턴 탐지
트레이스 기반 디버깅 (trace-based debugging) UI
실행 이력 (execution history)을 통한 회귀 테스트 (regression testing)
관찰된 실패를 기반으로 한 컨트랙트 (contract) 진화

맺음말

Golden Armada는 정답이 아닙니다.

그것은 질문입니다:

코드가 아닌 실행 (execution)이 주요 산출물 (artifact)이 될 때, 소프트웨어는 무엇이 되는가?

우리는 아직 초기 단계에 있지만, 런타임 동작 (runtime behavior)으로부터 의미 있는 구조가 나타나는 것을 이미 관찰할 수 있습니다.