AI 시스템은 폭발적으로 향상됩니다. 새로운 모델이 출시됩니다. 공급자 경로가 더 저렴해집니다. 프롬프트 패턴이 더 명확해집니다. 실패 모드가 명확해집니다. 전략적 질문은 그 이익이 다음에 어디로 가는가입니다. 저는 지난 몇 년 동안 제 스택을 정비해 왔으며, 하나의 지역 이익이 전체 포트폴리오를 업그레이드할 수 있도록 했습니다. 그 요구는 저를 공유 AI 기능 레이어, 워크플로우 제어 플레인, 그리고 로컬 개발, LAN 서비스, 그리고 프로덕션을 아우르는 호스트-네이티브 운영자 표면을 구축하도록 이끌었습니다. 이 기사에서 언급되는 이름들은 제가 그 시스템에 붙인 이름들입니다: AI Guard, Agent Gateway, 그리고 System Mesh. 이 기사는 그 스택 뒤에 있는 아키텍처에 관한 것입니다. 초점은 각 레이어가 해결하는 문제, 무엇이 진전되는지를 결정하는 프로모션 규칙, 그리고 개선이 지속될 수 있게 하는 운영 원칙에 있습니다.

진짜 목표: 전파

AI 중심 작업에서 가장 강력한 결과는 전파에서 나옵니다. 벤치마크 결과, 캐싱 승리, 재생 개선, 린트 규칙, 또는 배포 최적화가 모든 종속 프로젝트에 상속될 때 지속됩니다. 그 설계 제약은 무엇이 구축되는지를 바꿉니다. 공급자별 호출보다 안정적인 기능 표면을 선호합니다. 불투명한 프롬프트 체인보다 검사 가능한 워크플로우를 선호합니다. 배포, 롤백, 진단을 더 빠르게 만드는 운영자 계약을 선호합니다. 공유 플러그인, 공유 스킬, 공유 도구를 통해 확산되는 기반 개선을 선호합니다. 전파가 규칙이 되면 모델 선택은 더 큰 시스템 내의 하나의 변수로 변합니다.

작업 클래스별 모델 배치

내 모델 사용은 작업이 서로 다른 가치 밀도를 지니기 때문에 뉘앙스에 의존적입니다. 나는 심층 계획, 아키텍처 비판, 실패 분석 및 드리프트 방지에 프리미엄 추론 예산을 할당합니다. 출력 품질이 중요한 시스템 결정을 변경할 때 긴 응답 창을 수용합니다. 나는 강력한 CLI 실행 동작과 신뢰할 수 있는 도구 사용으로 장기 구현 작업에 코딩 네이티브 모델을 사용합니다. 그것은 처리량, 계획 품질 및 프로젝트 소유 기술이 가장 중요한 영역입니다. 워크플로가 벤치마크 압력 하에 입증된 후 반복되는 경계 작업을 더 저렴한 경로로 이동합니다. 그것은 결정론적 하네스, 재생 및 명확한 중지 조건이 상당한 절감을 실현하는 곳입니다. 지배 원칙은 작업 클래스별 배치입니다. 워크플로가 모델 결정을 소유합니다.

승격 규칙

내 승격 규칙은 명시적입니다:
  1. 비용 우선.
  2. 품질 바닥을 시행합니다.
  3. 비용과 품질이 한계 내에 있을 때 속도를 차지로 사용합니다.
더 저렴한 경로가 필요한 품질을 유지하면 승격됩니다. 비용과 품질이 이미 명확한 경우 더 빠른 경로가 중요합니다. 이 규칙은 공급자 이탈을 측정된 결과에 기반하도록 유지하고 새로운 드리프트를 방지합니다.
Diagram source
flowchart LR
  A["후보 경로"] --> B["벤치마크 코퍼스"]
  B --> C{"품질 >= 기준?"}
  C -->|아니오| D["실험실에 머무르기"]
  C -->|예| E{"비용 <= 현재 경로?"}
  E -->|아니오| F["프리미엄 또는 전문 사용을 위해 보존하기"]
  E -->|예| G["공유 기능 계층으로 승격"]
  G --> H["종속 워크플로우는 업그레이드를 상속받습니다"]
이것이 일시적인 AI 이득을 복합 인프라로 전환하는 메커니즘입니다.

Why I Built AI Guard

AI Guard solves a recurring integration problem: projects need AI capabilities, providers and model routes change constantly, and raw per-project integrations create duplicated decision logic, duplicated failure handling, and duplicated spend.
I built AI Guard as the shared capability layer across my projects. Applications call stable capabilities such as structured generation, search, OCR, TTS, image generation, image analysis, and other specialized routes. AI Guard owns the provider-facing layer, cache behavior, pricing awareness, and route promotion.
That design does several useful things at once.
It gives every project one surface for AI work. It captures repeated equivalent requests so benchmark loops and production workloads can reuse prior results. It makes budgeting visible. It keeps route upgrades centralized while application code keeps the same contract.
The compounding effect is straightforward. I benchmark a candidate route once. If it clears the quality bar and improves the economics, I promote it inside AI Guard. Every workflow that depends on that capability inherits the upgrade.

왜 나는 Agent Gateway를 만들었는가

AI Guard는 기능 접근을 처리한다. 나는 버전 관리, 재생, 출판 제어가 있는 조합형 워크플로우를 위해 두 번째 계층이 필요했다. 나는 Agent Gateway를 그 워크플로우 제어 평면으로 만들었다. 프로젝트 저장소는 워크플로우 YAML을 소유한다. 게이트웨이는 검증, 초안 동기화, 불변 게시, 실행, 이벤트, 스냅샷, 재생 포인트, 검증 세트 및 단계 캐시를 처리한다. 이는 특정 운영 문제를 해결한다. 다단계 AI 체인은 중간에 실패하면 비용과 모호성이 누적된다. 불투명한 체인은 전체 재실행을 강제한다. 단계 경계가 있는 버전된 실행은 내가 개입할 정확한 위치를 제공한다. 내 엔진은 상태 기계 기반이다. 워크플로우가 특정 단계에서 끊어지면 나는 그 단계를 정제하고, 정확한 경계에서 재생하며, 이미 증명된 상류 작업을 보존한다. 그 루프는 AI 워크플로우의 경제성과 신뢰성 프로필을 바꾼다. 일반적인 경로는 다음과 같다:
  1. 프로젝트 소유 YAML에서 로컬로 워크플로우 프로토타입을 만든다.
  2. 실제 사례 세트와 비교해 검증한다.
  3. 프롬프트, 스키마, 변환 및 분기 규칙을 강화한다.
  4. 정확한 실패 경계에서 재생한다.
  5. 검증이 통과된 후 불변 버전을 게시합니다.
실험적 AI 체인이 검증 가능한 인프라로 변하는 방식입니다.

왜 나는 System Mesh를 만들었는가

포트폴리오의 형태가 명확해지자 내 인프라 계층이 바뀌었다. 나는 Coolify-관리형 Docker 레인을 기본 운영 모델로 오랜 기간 사용했다. 이는 경계가 빠르게 움직이던 초기 단계에 잘 맞았다. 서비스 그래프가 안정되면서 호스트-네이티브 처리가 가능한 서비스에 대해 더 빠르고 명확한 운영자 표면을 원했다. 나는 로컬 개발, LAN 서비스 호스트, 그리고 프로덕션에 걸쳐 하나의 계약을 원했다. 나는 에이전트나 운영자가 실제로 필요로 하는 신호를 드러내는 진단을 원했다. 나는 배포, 환경 렌더링, 라우팅, 롤백을 일류의 가독성 있는 운영으로 만들고 싶었다. 나는 그 목적을 위해 공유 서비스-관리 계약으로 System Mesh를 만들었고, 환경별 매니페스트, CLI, 스킬을 통해 이를 구현했다. 이 스택에서 dev은 로컬 런타임 운영을 소유하고, mint는 LAN 호스트를 소유하며, prod은 프로덕션을 소유한다. 공유 계약은 어휘를 정렬된 상태로 유지하면서 각 환경이 자체 정책을 적용하도록 한다. 이 변화는 약 3분에서 약 30초로 일반 배포 경로를 단축했다. 더 큰 승리는 아키텍처적이다. 호스트-네이티브 레인에 맞는 모든 서비스는 더 빠른 배포, 더 날카로운 진단, 그리고 보다 명시적인 운영 모델을 상속한다. 나는 종속성 프로파일이 정당화되는 경우에만 컨테이너를 사용한다. 무거운 시스템 종속성은 여전히 보존된 Docker 실행의 좋은 후보이다. 가이드 원칙은 서비스 제약에 따른 실행 모드 배치입니다.

Benchmark Labs와 저비용 결정론적 레인

나는 랩을 사용해 승격을 얻는 것을 결정한다. 랩은 벤치마크 코퍼스, 스코어링 규칙, 챌린저 세트, 그리고 통과 기준을 소유한다. 이는 탐색적 작업과 운영 경로를 분리할 수 있는 깔끔한 방법을 제공한다. 프리미엄 추론 모델은 고가치 계획 및 아키텍처에 대해 계속 사용 가능하다. 저비용 경로는 작업이 제한적이고 워크플로우가 읽기 쉽고 결과를 평가할 수 있을 때 인수한다. 번역 유지보수는 좋은 예시다. 나는 제한된 에이전트 흐름을 실행해 i18n JSON을 크롤링하고, 누락되거나 약한 번역을 감지하며, 제한된 단계 예산 안에서 파일을 패치한다. 이 작업은 강력한 처리량과 주요 비용 절감으로 인해 저비용 OSS 클래스 경로에서 실행될 수 있다. 워크플로우는 벤치마크되고 재생 가능하며 스코어링이 쉽다. 랩은 시장이 빠르게 움직이도록 하면서 프로덕션 코드는 검증된 증거를 기반으로 움직인다.

기초 수준 복합

가장 큰 장기 이득은 기초에서 나타난다. 나는 프로젝트 기술을 사용해 에이전트가 로컬 시스템, 생산 시스템, 그리고 공유 서비스를 즉시 컨텍스트와 함께 운영할 수 있도록 한다. 나는 런타임 실패가 정적으로 방지되어야 할 패턴을 드러낼 때, 그 방어책을 한 번 인코딩해 포트폴리오가 상속받도록 리닝을 지속성 메커니즘으로 사용한다. 나는 또한 반복되는 애플리케이션 형태를 넘어 60개가 넘는 플러그인을 공유 기초로 유지한다. Auth, SEO, 이메일, 워크플로우 통합, 그리고 운영자 인체공학은 중앙에서 개선되고 그 다음에 외부로 전파된다. 여기서 이론이 일상 업무에서 눈에 보이게 된다. 회귀가 덜 발생한다. 더 많은 수리가 사전 배포된다. 속도가 상승한다는 것은 이전 교훈이 설치된 상태를 유지하기 때문이다.

AI가 해석한 운영 원칙

저는 AI가 이 글에서 설명된 접근 방식에서 운영 원칙을 추출하도록 지시했습니다:
  • 포트폴리오 전체에 전파되도록 구축하세요. 모든 개선은 얼마나 많은 워크플로우가 이를 상속받는지에 따라 평가되어야 합니다.
  • 모델 선택을 워크플로우 배치로 취급하세요. 작업 클래스와 가치 밀도에 따라 모델을 할당하세요.
  • 엄격한 품질 하한선을 가진 비용 우선 승격 규칙을 시행하세요. 승격은 품질 동등성 또는 개선을 요구합니다.
  • 기능을 안정적인 계층 뒤에 유지하세요. 경로 변동은 안정적인 애플리케이션 계약을 통해 기능 계층에서 흡수됩니다.
  • 워크플로우를 검사 가능하고 재생 가능하게 유지하세요. 결정적 진행 및 되감기 경계는 핵심 프로덕션 기능입니다.
  • 벤치마크 랩을 승격 게이트로 사용하세요. 시장 출시 주기는 평가를 위한 입력 스트림입니다.
  • 입증된 후에는 제한된 반복 작업을 저비용 결정적 레인으로 이동하세요. 프리미엄 추론 예산을 높은 레버리지 결정을 위해 보존하세요.
  • 반복되는 실패를 공유 보호 장치로 인코딩하세요. Lint 규칙, 기술 및 공유 플러그인 업데이트는 사고를 지속 가능한 예방으로 전환합니다.
  • 명시적 연산자 계약을 선호합니다. 호스트-네이티브 서비스 계약은 명확한 배포/롤백/증명 루프를 통해 운영 엔트로피를 줄입니다.
  • 계약에 따라 선택성을 보존합니다. 아키텍처를 준비하여 파레토 프런티어가 이동함에 따라 더 나은 경로를 흡수하도록 합니다.

마감

워크플로우 질문에 대한 나의 답은 건축적이다. 나는 전파를 위해 구축하고, 프로모션을 위해 벤치마크하며, 모든 프로젝트가 상속할 수 있는 공유 레이어에 승리 패턴을 보관한다. 이것이 AI 시장에서 일시적인 개선이 소프트웨어 운영에서 지속 가능한 이익이 되는 방식이다. 이것이 작업이 복합되는 방식이다.