FDAI 아키텍처

FDAI는 독립적인 에이전트로 구성됩니다. 각 에이전트는 한 가지 역할을 맡고, 스키마 검증을 거친 이벤트로만 다른 에이전트와 통신합니다. 따라서 하나의 구성 요소가 관찰, 판단, 승인, 실행, 감사를 모두 담당하지 않습니다. 컨트롤 플레인은 사용자 인터페이스 없이 동작하고, 콘솔은 읽기 전용으로 유지됩니다. 수정 사항은 pull request로 전달하고 승인은 채팅에서 처리합니다.

15개로 고정된 에이전트 조직은 이러한 책임 분담을 명확히 합니다. 각 에이전트는 컨트롤 플레인에서 타입이 정의된 객체와 수명 주기 역할을 담당합니다. 에이전트는 컨트롤 루프에 책임 주체를 더할 뿐입니다. 컨트롤 루프를 대신하거나 결정론적 안전성 검토를 건너뛰지 않습니다.

현재 구현 대상은 Azure입니다. 모든 클라우드 호출은 공급자 계약을 거치므로 코어는 Azure SDK를 직접 가져오지 않습니다. 따라서 다른 호스트로 옮기더라도 판단 로직을 다시 작성할 필요가 없습니다.

통제형 자동화 흐름

운영자의 자연어 의도가 통제된 작업으로 바뀌는 과정을 이해하려면 개념 보기를 먼저 살펴보세요. 언어 이해, 의미 컨텍스트, 정책 판단, 작업 선택, 실행, 피드백, 영구 저장소를 Azure 리소스 배치와 분리해 보여 줍니다.

번호가 있는 카드는 기본 흐름을 보여 줍니다. 아래 영역에서는 같은 개념을 공유 컨텍스트, 타입 기반 의미 체계, 결정론적 정책, 등록된 작업, 실행 대상, 측정된 결과, 영구 보존 근거로 확장합니다. 권한과 배포 경계를 확인하려면 이어서 참조 아키텍처를 살펴보세요.

참조 아키텍처

개별 이벤트를 추적하기 전에 참조 보기에서 시스템 범위, 권한 경계, 통제되는 의존성을 확인하세요. 사용자 인터페이스 없이 동작하는 컨트롤 플레인에는 타입 기반 이벤트 흐름과 15개 에이전트가 담당하는 제어 단계가 있습니다. 모델 공급자, 도구, 정책 및 조회 엔진, 지식, 근거, Azure 배포 기반은 이 내부 경계 밖에 둡니다. 배포 기반에는 AKS를 기본 런타임으로, Container Apps를 호환 프로필로 표시합니다.

Pantheon 통합 표시는 고정된 15개 에이전트 조직을 나타내며 16번째 에이전트가 아닙니다. T2만 품질 게이트를 사용하고 모든 티어는 공통 안전성 및 권한 검토를 거칩니다. 사람의 승인은 실행기를 직접 호출하지 않고 타입 기반 이벤트로 런타임에 돌아옵니다. OPA와 Rego는 결정론적 정책을 평가하고 IQL은 범위가 제한된 인벤토리 조회를 수행합니다. 단일 이벤트 흐름은 전체 구조 보기에서, 배포 및 리소스 수준 연결은 Azure 보기에서 확인하세요.

전체 구조

FDAI는 느슨하게 결합된 5개 계층으로 구성됩니다. 계층 간에는 타입 기반 이벤트, 버전으로 관리되는 계약, Git을 공유합니다. 하나의 프로세스나 하나의 자격 증명을 공유하지는 않습니다.

콘솔은 상태 저장소와 감사 저장소의 조회용 데이터만 읽습니다. 실행기 신원을 사용하지 않고 변경을 승인할 수 없으며, 리소스를 변경하는 Azure API도 호출하지 않습니다.

Azure 배포 토폴로지

배포 런타임에 맞는 보기를 선택하세요. 새 설치에서는 AKS를 기본으로 사용하며, Container Apps는 호환성 프로필로 유지됩니다. 두 런타임의 논리적 컨트롤 루프와 권한 경계는 같습니다.

AKS 배포

이 보기는 인증된 공개 콘솔과 postgres-flex를 사용하는 AKS 프로필입니다. Azure Static Web Apps는 클러스터 밖에서 브라우저 애플리케이션을 호스팅합니다. Azure API Management(APIM)는 HTTPS API 게이트웨이를 제공하며 Operator 요청과 /ingestion 요청을 각각의 AKS 서비스로 전달합니다.

다이어그램은 왼쪽의 인증된 접근 경로에서 가운데 AKS 런타임을 거쳐 오른쪽의 Azure 데이터 및 운영 서비스 순서로 읽습니다. 공통 의존 서비스는 주요 흐름 아래에 배치했습니다. API 접근 경계에는 예약 작업이 포함되지 않습니다. Event Hubs 연결선은 Core 전용 버스가 아니라 여러 서비스가 함께 사용하는 이벤트 전송 경로를 나타냅니다.

• 서비스 배치: Core Control Plane, Operator Service, Document Ingestion API, Document Processing Worker, 격리된 실행기를 각각 독립적인 Deployment로 실행합니다. Worker에는 ClamAV 사이드카가 포함됩니다. 예약 작업은 Container Apps Jobs가 아니라 CronJob으로 실행합니다.
• API 접근: 외부에 노출하는 API는 Kubernetes LoadBalancer Service를 사용하고 나머지는 ClusterIP를 사용합니다. API 서비스는 Entra 토큰을 검증합니다. APIM은 브라우저 게이트웨이이며 Kubernetes 관리 API가 아닙니다.
• 신원과 이미지: 네임스페이스별 ServiceAccount는 AKS Workload Identity를 통해 각각의 관리 ID와 페더레이션됩니다. Key Vault는 CSI 드라이버를 통해 서비스별 비밀 참조를 제공하고 Container Registry는 다이제스트로 고정된 이미지를 제공합니다. 격리된 실행기만 승인된 리소스 변경 역할을 보유할 수 있으며 런타임 선택만으로 실행이 활성화되지는 않습니다.
• 데이터와 이벤트: Event Hubs가 스키마가 검증된 서비스 이벤트를 전달하며 에이전트는 서로 직접 호출하지 않습니다. PostgreSQL은 서비스별 역할을 사용하고 Azure Storage는 문서와 이력을 보관합니다. 그룹 단위 연결선은 이 경로를 요약한 것이며 자격 증명 공유나 무제한 데이터 접근을 뜻하지 않습니다. 공통 의존 서비스와 운영 영역은 지원 서비스를 표시하며 ID, 이미지, 모델, 승인 및 관찰 데이터 연결을 모두 반복해서 그리지는 않습니다. Azure 제품은 해당 제품 아이콘을, Kubernetes Deployment, 노드 및 CronJob은 해당 Kubernetes 아이콘을 사용합니다.
• 네트워크 범위: AKS는 애플리케이션 VNet, 노드 서브넷 및 API Server VNet Integration을 사용하는 위임된 API 서버 서브넷으로 구성됩니다. 기본 프로필은 CIDR과 Entra RBAC로 공개 관리 접근을 제한합니다. 비공개 클러스터 접근, 서비스 비공개 엔드포인트, 피어링 및 비공개 DNS는 선택한 네트워크 프로필에 따라 달라지며 이 그림은 해당 기능이 활성화되었다는 의미가 아닙니다.

이 그림은 재사용 가능한 배포 구성을 설명하며 특정 테넌트의 리소스 목록이나 실시간 상태 보고서가 아닙니다. 모델 접근, 승인 채널, 진단 데이터 수집은 각각 별도로 구성하고 검증해야 합니다. 선택 사항인 postgres-aks 프로필은 PostgreSQL을 AKS 안에 배치하며 이 그림에는 표시하지 않습니다. 배치 및 준비 상태 요건은 런타임 배포 프로필을 참조하세요.

Container Apps 배포

Container Apps는 같은 5개 서비스, 컨트롤 루프, 권한 경계를 유지하는 호환 프로필입니다. 다음 절의 리소스 네트워크 흐름이 이 프로필의 배포 보기입니다. VNet에 통합된 Container Apps 환경의 5개 서비스, Azure 서비스로 이어지는 비공개 엔드포인트 경로, 전달 채널을 보여 줍니다.

이 보기는 특정 테넌트의 리소스 이름이 아니라 매개 변수화된 Terraform 배포를 나타냅니다. Azure OpenAI와 일부 비공개 엔드포인트는 선택 사항입니다. 사용자 App 역할과 권한 있는 실행기의 Managed Identity는 모든 프로필에서 분리됩니다.

Azure 리소스 네트워크 흐름

이 보기는 Container Apps의 사설망 참조 구성이며 앞에서 설명한 AKS 프로필과 구분됩니다.

현재 상태와 목표 상태의 연결을 Azure 리소스 수준에서 추적하려면 이 보기를 사용하세요. 비공개 Application Gateway, Container Apps 인프라, 비공개 엔드포인트 서브넷을 분리하고, 각 비공개 엔드포인트를 해당 관리형 서비스 백엔드에 연결합니다. 이 다이어그램은 FDAI Web Console 경로를 표시합니다. FDAI CLI는 동일한 Operator API를 사용하지만 다이어그램을 간결하게 유지하기 위해 이 보기에서는 생략합니다.

기준선 영역은 enable_private_postgres=false일 때 postgresqlServer 비공개 엔드포인트를 추가하는 기본 사설망 프로필을 표시합니다. enable_private_postgres=true로 설정하면 이 경로 대신 PostgreSQL Flexible Server를 위임된 서브넷에 배치하고 엔드포인트를 생성하지 않습니다. 문서 경로는 인증된 Ingestion API와 영속적으로 처리하는 Processing Worker를 분리합니다. 두 서비스는 선택적인 Blob 및 DFS 비공개 엔드포인트와 ADLS Gen2 계정을 사용합니다. 기본 및 운영용 네임스페이스는 같은 Azure 리소스 및 비공개 링크 패턴을 사용하므로 하나의 Event Hubs 기호로 나타냅니다. 사례 이력 저장소는 문서로 설명하고, 동일한 Storage Account 및 비공개 엔드포인트 쌍을 반복하지 않습니다. 개발 운영 게이트웨이와 APIM은 각각의 기능별 프로필에 남아 있습니다.

같은 보기에는 의도한 게이트웨이, 모델 플랫폼, 관측성 및 전달 공급자 토폴로지도 겹쳐서 표시합니다. Terraform이 프로비저닝하지 않는 요소는 점선 윤곽과 “(계획)” 레이블로 구분합니다. 아래 표는 각 목표 상태 요소의 상태를 설명합니다.

목표 상태 요소	Terraform 상태	문서화 결정
애플리케이션 게이트웨이와 WAF 정책이 있는 비공개 애플리케이션 게이트웨이 서브넷	프로비저닝되지 않음	계획된 토폴로지로 그림에 유지합니다. 배포 가능한 경로로 취급하기 전에 Terraform 프로필을 추가합니다.
Microsoft Foundry 계정, 프로젝트 및 비공개 엔드포인트	명시적으로 선택하는 기능 프로필	그림에 유지합니다. 사용 가능 여부는 LLM 및 웹 검색 설정에 따라 달라집니다.
Azure Managed Grafana	프로비저닝되지 않음	계획된 관측성 토폴로지로 그림에 유지합니다.
이메일, Teams 및 Slack 승인 채널	이메일은 명시적 선택이고 Teams와 Slack은 배포 어댑터입니다.	공급자 선택지로 유지합니다. 각 배포에서 자격 증명, 콜백 신원 및 대체 경로 정책을 선택합니다.
GitHub, GitLab 및 Azure DevOps 전달 공급자	배포 어댑터	공급자 선택지로 유지합니다. 각 배포에서 Git 호스트와 검토 연결을 선택합니다.

모든 Terraform 리소스를 별도 노드로 표시할 필요는 없습니다. 네트워크 경계를 바꾸거나, 별도 데이터 경로를 만들거나, 사용자가 보는 전달 엔드포인트인 리소스만 직접 표시합니다. 해당 경로를 지원하기만 하는 리소스는 묶어서 표시하거나 문서로 설명합니다.

Terraform 리소스 또는 리소스 그룹	그림 처리	이유
운영용 Event Hubs 네임스페이스와 비공개 엔드포인트	Event Hubs에 집계	동일한 Event Hubs 및 비공개 링크 기호를 사용하며 노드 설명이 기본 및 운영용 토픽을 포괄합니다.
사례 이력 Blob 계정과 비공개 엔드포인트	문서로 유지	동일한 Storage Account 및 Blob 비공개 엔드포인트 기호를 사용하므로 쌍을 반복하면 새 상호 작용 패턴 없이 복잡도만 늘어납니다.
Container Apps 환경	집계로 유지	Container Apps 서브넷 경계와 앱/작업 노드가 호스팅 역할을 이미 전달합니다.
비공개 DNS 영역과 VNet 링크	비공개 엔드포인트 경로에 암시적으로 포함	각 영역과 링크를 그리면 워크로드 흐름을 바꾸지 않으면서 모든 비공개 엔드포인트를 중복 표시하게 됩니다.
작업 그룹, 메트릭 경보 및 진단 설정	App Insights 및 Logs에 집계	별도 워크로드 데이터 경로가 아니라 관측성 라우팅을 구현합니다.
Event Grid 실시간 인벤토리 토픽	이 비공개 프로필에서 제외	Terraform은 사설망 기능이 비활성화된 경우에만 이를 활성화합니다.

이 리소스를 위한 추가 노드는 필요하지 않습니다. 이들과 다른 지원 리소스는 아키텍처에서 누락된 것이 아니라 의도적으로 추상화한 것입니다.

Azure Resource Graph 조회와 관측 데이터 기록은 Azure 컨트롤 플레인 및 텔레메트리 계약을 사용하므로 비공개 데이터 플레인 경로 밖에 표시합니다. 이 Container Apps 참조 구성은 여전히 Application Gateway, WAF, Managed Grafana 또는 부하 분산 장치를 추가하지 않습니다.

검증된 5개 서비스 기준 구성과 후보 1개

15개 에이전트는 Core 런타임 안에서 논리적 책임을 맡으며, 15개의 Azure 서비스를 뜻하지 않습니다. FDAI는 자체 이미지, Terraform 상태, 마이그레이션 브랜치, 상태 계약, 워크로드 신원을 가진 5개 서비스를 각각 독립적으로 배포하고 릴리스합니다. SD-10은 정식 전환 근거가 마련될 때까지 배포하지 않는 별도 패키지형 System Knowledge Service 후보를 추가합니다.

서비스	책임	실제 변경 권한
Core Control Plane	에이전트 런타임, 판단, 승인 연결, 감사 의도 기록 및 복구 조정	없음
Operator Service	인증된 조회, 대화, 변환 결과 및 통제된 요청 제출	없음
Document Ingestion API	인증된 업로드 수신 및 API가 담당하는 문서 상태 전환	없음
Document Processing Worker	영속적인 검사, 추출, 색인, 작업 점유 및 정합성 조정	없음
Isolated Executor	명령 검증, 대상 잠금, 공급자 변경, 롤백 시도 및 실행 증적	유일하게 보유 가능
System Knowledge Service 후보	릴리스에 결속된 FDAI 참조 검색 및 전용 Teams 멘션 봇	없음

이벤트 버스와 버전이 지정된 서비스 계약이 검증된 기준 구성을 연결합니다. 후보는 자체 카탈로그, Teams HTTPS 수신 경로 및 서비스 계약을 사용합니다. 어떤 서비스도 다른 서비스의 구현을 가져오거나 가변 작업 흐름 상태를 공유하지 않습니다.

5개 아키텍처 계층

계층	책임	주요 경계
사용자 인터페이스 없는 컨트롤 플레인	이벤트를 정규화하고, 판단 티어를 선택하고, 제안을 검증하고, 위험을 분류하고, 실행을 조정합니다.	UI 로직이 없고 클라우드 SDK를 직접 가져오지 않습니다.
작업 전달	승인된 작업을 수정 pull 요청이나 등록된 공급자 호출로 바꿉니다.	모든 작업이 안전성 계약과 롤백 참조를 그대로 유지합니다.
운영자 콘솔	상태, 근거, 감사 이력, 관찰 모드 결과, 승인 대기 항목을 보여 줍니다.	실행 권한이 없는 읽기 전용 자격 증명입니다.
사람 채널	ChatOps로 승인 요청과 운영 알림을 전달합니다.	승인자는 절대 실행자가 되지 않습니다.
규칙 카탈로그	규칙, 정책, 작업 유형, 프롬프트, 적용 전환 근거를 코드로 버전 관리합니다.	카탈로그 변경은 검토, 회귀 테스트, 관찰 모드 평가를 거칩니다.

각 계층은 독립적으로 실패하고 확장됩니다. 콘솔이 멈춰도 이벤트 처리는 계속됩니다. ChatOps가 멈추면 위험도가 높은 작업은 승인 없이 실행되지 않고 대기열에서 기다립니다.

하나의 이벤트가 시스템을 통과하는 방식

Azure 리소스 변경, SLO 소진 감지, 예약 작업, 운영자 요청 중 어디에서 시작하든 모든 이벤트는 같은 경로를 따릅니다.

전체 구조의 시스템 개요가 이 경로를 보여 줍니다.

1. 수집과 상관관계 분석: FDAI는 이벤트 스키마를 확인하고, 재시도를 안전하게 만드는 멱등성 키로 중복 이벤트를 제거한 뒤, 관련 신호를 하나의 인시던트로 묶습니다.
2. 판단할 수 있는 가장 낮은 티어 선택: T0(결정론적 규칙)는 반복되는 대다수를 처리하고, T1(비슷한 과거 사례의 경량 재사용)은 이미 알려진 패턴을 처리하며, T2(근거 기반 LLM 추론)는 새롭거나 모호한 사례만 맡습니다.
3. 위험을 분류하기 전에 먼저 검증: T2 제안은 서로 다른 모델의 합의, 근거 확인, 스키마, 정책, 보안, what-if 검사를 모두 통과해야 합니다. 그럴듯한 답변만으로는 부족합니다.
4. 자율성 상한 적용: 안전성 검토는 작업 위험도, 영향 범위, 시스템 상태, 정책을 함께 평가합니다. 결과는 자동 실행, 승인 필요, 거부 중 하나입니다.
5. 한 번 실행하고 모든 경로 기록: 실행기는 리소스별 잠금을 획득하고, 재시도해도 안전한 작업을 적용한 뒤 결과를 기록합니다. 거부, 시간 초과, 보류, 롤백, 미실행도 같은 방식으로 감사 기록에 남깁니다.

티어를 나누는 기준은 결정론 우선, 자율성 결정은 신뢰 수준을 참조하세요.

컨트롤 플레인 안의 에이전트 조직

FDAI의 15개 에이전트는 컨트롤 루프에 책임 주체를 더하는 소유권 계층입니다. 15개의 별도 Azure 서비스도 아니고, 자유롭게 결정을 내리는 챗봇도 아닙니다. 각 에이전트는 하나의 임무, 자신이 소유하는 객체 유형, 구독하는 토픽, 제한된 권한을 가진 런타임 객체입니다.

모든 에이전트는 같은 Python 컨트롤 플레인 프로세스 안에서 실행되며 주입된 이벤트 버스로 통신합니다. 프로세스를 공유한다고 경계가 느슨해지지는 않습니다. 에이전트는 여전히 자신이 소유한 객체만 발행합니다. 나중에 별도 프로세스로 분리하더라도 토픽과 권한 모델은 그대로입니다.

15개 역할의 결합 방식

아키텍처 기능	에이전트	컨트롤 루프에서의 소유권
감지와 관찰	Huginn, Heimdall	Huginn은 정규화된 이벤트와 실시간 리소스 탐색 유입을 소유합니다. Heimdall은 이상 징후, 드리프트, 예측으로 발견된 문제를 소유합니다.
판단과 조정	Forseti, Odin	Forseti가 결정을 발행합니다. Odin은 Forseti가 결정을 확정하기 전에 영역 간 충돌을 정리합니다.
실행, 승인, 복구, 설명	Thor, Var, Vidar, Bragi	Thor는 유일한 권한 실행기입니다. Var는 사람 승인을 전달합니다. Vidar는 롤백을 소유합니다. Bragi는 운영자와의 대화를 옮깁니다.
근거와 지식 관리	Saga, Mimir, Norns, Muninn	Saga는 추가 전용 감사 기록을 소유합니다. Mimir는 규칙을 관리합니다. Norns는 아직 작동하지 않는 학습 후보를 제안합니다. Muninn은 상태 스냅샷과 맥락 색인을 소유합니다.
도메인 근거 공급	Njord, Freyr, Loki	비용, 용량, 카오스 전문 에이전트는 판단에 조언할 뿐 직접 실행하지 않습니다.

15개 역할은 상위 프로젝트에서 고정되므로, 포크가 서로 충돌하는 역할을 합치거나 권한 경계의 이름을 바꿀 수 없습니다. 포크는 공급자를 연결하고, 임계값을 조정하고, 선택적인 에이전트를 끄고, 카탈로그 항목을 추가할 수 있습니다. 다만 Saga와 Vidar는 필수 의존 항목이므로 감사와 롤백은 끌 수 없습니다.

런타임 데이터 흐름

위 표는 조직도입니다. 아래 다이어그램은 데이터 흐름, 즉 에이전트가 소유한 객체가 어디로 이동하는지를 보여 줍니다.

대화형 도해는 런타임 관점의 구조를 보여 줍니다. 에이전트는 각자 독립적으로 구독하고, 작업은 동시에 여러 곳으로 퍼질 수 있으며, 권위 있는 객체는 그것을 소유한 에이전트만 발행합니다. 게이트웨이와 워커는 이벤트를 중계할 뿐, 숨은 의사 결정자가 되지 않습니다.

이 흐름은 한 가지 간단한 규칙을 따릅니다. 정보는 여러 독자에게 퍼질 수 있지만, 권위 있는 객체 유형은 쓰는 주체가 딱 하나입니다. 여러 에이전트가 결정을 읽을 수 있지만 object.verdict는 Forseti만 발행합니다. 발행 측 레지스트리가 이 소유권을 검사합니다. 선언된 발행 주체가 토픽 소유자와 다르면 이벤트 버스 브리지가 해당 레코드를 dead-letter로 보냅니다. 발행 주체가 아예 없는 레코드는 경계를 더 엄격하게 관리할 수 있도록 따로 보고됩니다. 토픽 이름을 안다고 권한이 생기지는 않습니다.

단일 쓰기 주체 소유권

단일 쓰기 주체 소유권은 에이전트 역할을 문서 설명이 아니라 런타임이 강제할 수 있는 경계로 만듭니다.

객체 또는 토픽	단일 쓰기 주체	아키텍처적 효과
Event / object.event	Huginn	클라우드 어댑터가 정규화된 컨트롤 플레인 유입인 체할 수 없습니다.
Verdict / object.verdict	Forseti	전문 에이전트와 모델은 조언할 수 있지만 작업을 실행 가능하게 만들 수는 없습니다.
ArbitrationDecision	Odin	영역 간 트레이드오프에 결정론적 중재자가 하나만 존재합니다.
ActionRun / object.action-run	Thor	실행기만 변경 시도를 점유하고 결과를 보고할 수 있습니다.
Approval / object.approval	Var	실행기가 자기 승인을 지어낼 수 없습니다.
Rollback / object.rollback	Vidar	복구가 따로 테스트할 수 있는 별도 경로로 남습니다.
AuditEntry / object.audit-entry	Saga	최종 근거의 추가 전용 소유자가 하나입니다.
RuleCandidate / object.rule-candidate	Norns	학습은 아직 작동하지 않는 데이터를 제안할 뿐 카탈로그를 직접 고칠 수 없습니다.
Rule 및 Policy	Mimir	규칙을 켜고 끄는 일은 관리되는 카탈로그 작업으로 남습니다.

에이전트 모듈은 핸들러를 직접 호출하기 위해 서로를 가져오지 않습니다. 자신이 소유한 객체를 발행하고 선언한 토픽을 구독하므로 런타임 구성이 위 권한 표와 항상 일치합니다.

ActionType 역할 바인딩

등록된 모든 ActionType은 작업 생애주기를 지정된 에이전트에 연결합니다.

initiator -> Forseti (judge) -> Thor (executor) -> Var (필요한 경우 approver)
                                            -> Saga (모든 terminal path의 auditor)
                                            -> Vidar (필요한 경우 compensation)

시작 주체는 작업마다 달라집니다. 반면 판단자, 실행자, 승인자, 감사자 역할은 상위 프로젝트에서 고정됩니다. 바인딩에는 롤백 계약, 비가역성 표시, 보상 작업도 함께 담깁니다. 덕분에 포크가 도메인 전문 에이전트에게 자기 승인을 허용하거나, 변경을 실행한 컴포넌트를 그 변경의 감사자로 지정하는 일을 막을 수 있습니다.

두 개의 포트와 하나의 권한 경로

모든 에이전트는 두 개의 포트를 노출합니다.

• 타입 기반 pub/sub 포트: 권위 있는 기계 경로입니다. 등록된 토픽, 스키마가 검증된 페이로드, 발행 주체 확인, 결정론 우선 컨트롤 루프를 사용합니다.
• 대화 포트: 운영자 질문과 에이전트 간 조회를 위한 제한된 자연어 경로입니다. Bragi가 질문을 전달하고 답변을 작성합니다. Bragi는 판단하지도, 실행하지도 않습니다.

두 포트는 상관관계 추적 정보만 공유합니다. 운영자가 Bragi에게 작업 수행을 요청하면 Bragi는 타입이 정의된 제안을 만들어 Huginn으로 보냅니다. 그래서 다른 이벤트와 똑같이 검증, 판단, 위험 평가, 승인, 실행, 감사를 다시 거칩니다. 대화는 권한을 설명할 수는 있지만 권한 자체가 될 수는 없습니다.

런타임 배치와 승격

런타임은 기존 컨트롤 루프 소비자 옆에서 에이전트 조직을 함께 실행하고 둘을 서로 비교합니다.

현재 구현 상태: 에이전트는 컨트롤 플레인과 함께 시작하며, 판단과 기록만 하고 실제 변경은 하지 않는 관찰 모드로 동작합니다. 역할 이름은 권한 계약을 설명할 뿐, 모든 에이전트가 실제 변경 권한을 받았다는 뜻은 아닙니다. 지속 저장 기반 안전 연결이 모두 갖춰질 때까지 적용 모드는 차단됩니다.

• 유입은 공유, 소비자는 분리: 두 경로는 서로 다른 소비자 그룹으로 같은 Kafka 토픽을 읽습니다. 따라서 에이전트는 기존 루프의 이벤트를 가로채지 않고 같이 관찰합니다.
• 기본값은 관찰 모드: Thor는 에이전트가 했을 법한 작업을 기록하지만 아무것도 변경할 수 없습니다. 두 경로를 비교하는 동안 같은 작업이 두 번 실행되지 않습니다. 유지보수 때문에 에이전트 런타임을 멈춰야 할 때만 FDAI_START_PANTHEON=0을 설정하세요.
• 적용은 별도 승격 절차: 적용 모드로 시작하려면 동작 중인 Thor 실행기, 지속 저장되는 작업 실행 기록, 지속 저장되는 Saga 감사 체인, 등록된 Vidar 롤백 실행기, 그리고 시작 준비 보고서의 배포 단계 권한 상한이 모두 필요합니다. 하나라도 없으면 시작이 중단됩니다.
• 장애 격리: 에이전트 런타임은 따로 감시됩니다. 이쪽이 실패해도 장애만 보고되고 기존 이벤트 소비자는 계속 동작합니다.

이 배치 덕분에 실행 권한을 옮기기 전에 단계별 결과와 에이전트 소유 결과를 비교할 수 있습니다. 구현을 단계적으로 승격하는 동안에도 아키텍처는 그대로 유지됩니다.

신뢰와 권한 경계

FDAI에서 권한 분리는 아키텍처 자체의 속성입니다. 나중에 간단한 UI 변경으로 무력화할 수 있는 관례가 아닙니다.

경계	존재 이유	적용되는 동작
판단과 실행	변경을 제안하거나 판단한 주체가 직접 적용하지 않도록 합니다.	Forseti가 판단하고 Thor가 승인된 작업을 실행합니다.
승인과 실행	권한 있는 실행기는 자신의 작업을 승인할 수 없습니다.	Var가 별도로 권한이 부여된 채널로 승인을 전달합니다.
콘솔과 컨트롤 플레인	브라우저 세션은 변경 권한을 가질 수 없습니다.	콘솔은 조회용 데이터와 근거만 읽습니다.
모델 제안과 실행 자격	그럴듯한 모델 답변은 근거가 아닙니다.	결정론적 검증이 T2 제안의 진행 가능 여부를 결정합니다.
관찰과 적용	새 기능은 리소스를 변경하기 전에 동작을 검증해야 합니다.	새 작업은 먼저 관찰하고 감사하며, 적용 모드 전환은 별도로 결정합니다.
재생과 재실행	조사 과정에서 운영 변경이 다시 실행되지 않도록 합니다.	감사 재생은 작업을 다시 실행하지 않고 판단 과정만 재구성합니다.

에이전트 조직은 이러한 역할을 각 에이전트에 할당하며, 어느 에이전트도 컨트롤 루프를 건너뛸 수 없습니다. 대화로 들어온 요청도 다른 요청과 똑같은 이벤트, 검증, 위험 평가, 감사 경로를 다시 거칩니다.

코드와 데이터 경계

리포지토리는 런타임 시스템과 같은 의존 방향을 따릅니다.

• core/에는 판단과 조율 로직이 들어 있습니다. Azure SDK나 UI 컴포넌트가 아니라 공유 계약에만 의존합니다.
• shared/는 버전이 관리되는 이벤트, 작업, 규칙, 워크플로, 공급자 계약을 정의합니다. 코어를 가져오지 않습니다.
• delivery/는 계약 뒤에서 영속화, Azure 접근, GitOps, 알림, ChatOps, 조회 API를 구현합니다.
• rule-catalog/ 및 policies/에는 관리 대상 데이터가 들어 있습니다. 규칙이나 작업 유형을 추가할 때 컨트롤 루프를 다시 쓸 필요가 없습니다.
• 컴포지션 루트는 검증된 설정을 읽고 실제 공급자를 선택해 시작 시점에 주입합니다.

전체 의존 관계 지도는 Project Structure를 참조하세요.

Azure 구현

첫 번째 구현은 이식 가능한 각 계약을 작은 Azure 리소스 집합에 매핑합니다. 공급자별 호출은 어댑터 안에만 두므로, 리소스를 바꿔도 판단 로직은 수정할 필요가 없습니다. AKS는 신규 설치의 기본 런타임이며 Container Apps는 호환 프로필로 유지됩니다.

이식 가능한 요소	계약	AKS(기본)	Container Apps(호환)
이벤트 스트림	Kafka wire 프로토콜	Kafka 엔드포인트를 통한 Event Hubs	Kafka 엔드포인트를 통한 Event Hubs
코어 런타임	OCI 이미지와 이식 가능한 매니페스트	사용자 노드 풀의 Kubernetes Deployment	Azure Container Apps
예약 작업	작업 또는 cron 계약	Kubernetes CronJob	Container Apps Jobs
상태, 감사, T1 벡터	PostgreSQL과 pgvector	Azure Database for PostgreSQL Flexible Server	Azure Database for PostgreSQL Flexible Server
시크릿	환경 변수 또는 마운트된 시크릿	CSI 드라이버가 마운트하는 Key Vault 참조	Container Apps가 주입하는 Key Vault 참조
워크로드 자격 증명	OIDC 토큰	사용자 할당 Managed Identity와 연합된 AKS Workload Identity	사용자 할당 Managed Identity
인벤토리	리소스 그래프 계약	Azure Resource Graph와 Activity Log 변화량	Azure Resource Graph와 Activity Log 변화량
관측	OpenTelemetry 호환 신호	Log Analytics와 Application Insights	Log Analytics와 Application Insights
콘솔	정적 읽기 전용 앱	Azure Static Web Apps	Azure Static Web Apps
콘솔 조회 API	HTTP 조회 계약	API Management 뒤의 Operator Service	자체 읽기 전용 자격 증명을 가진 Container App
문서 수집	업로드와 분할 계약	Data Lake Storage를 사용하는 Ingestion API와 Processing Worker	Data Lake Storage를 사용하는 Container Apps
사람 승인	타입이 정의된 승인 메시지	Teams 봇과 Adaptive Cards	Teams 봇과 Adaptive Cards

AKS에서는 서비스마다 복제본 하한과 상한을 설정하며 하한은 1 이상입니다. Container Apps에서 코어는 최소 복제본 1개, 최대 3개로 상시 실행됩니다. 0개까지 줄이려면 자격 증명 없이 동작하는 Kafka 지연 기반 스케일 규칙이 필요합니다. 그 규칙 없이 0으로 내리면 들어오는 이벤트가 앱을 깨우지 못하므로 최소값을 1로 유지합니다. 예약 작업과 정적 서비스는 0까지 줄일 수 있습니다. 전체 공급자 목록은 CSP-neutrality 계약를 참조하세요.

모든 작업에 적용되는 안전장치

작업 유형을 완전하게 정의하려면 다음 7개 보호장치를 모두 선언해야 합니다.

• 중단 조건: 실행을 멈추는 측정 가능한 신호입니다.
• 롤백 경로: 이전 상태를 복원하거나 안전하게 다음 단계로 진행하기 위해 검증된 방법입니다.
• 영향 범위 제한: 작업이 영향을 줄 수 있는 최대 범위, 배치 크기, 동시 실행 수, 처리 속도입니다.
• Dry-run receipt: 정확한 대상과 개정 버전에 대해 성공한 what-if 결과입니다.
• 논리 대상 잠금: 실제 변경이 확정될 때까지 유지하는 잠금입니다.
• 멱등성 키: 재시도에서도 중복 실행을 막는 안정적인 키입니다.
• 2단계 감사: 실제 변경 전 의도를 기록하고, 실행 및 독립적인 결과 관찰 후 최종 종결 기록을 남깁니다.

감사 저장소처럼 필수적인 의존 항목을 사용할 수 없으면 FDAI는 자율성 수준을 관찰 모드로 낮추거나 작업을 검토 대기 상태로 둡니다. 필수 안전장치를 우회해 실행을 허용하지 않습니다.

예시: 구성 드리프트

네트워크 접근 범위를 정책에서 허용한 수준보다 넓히는 리소스 변경을 예로 들어 보겠습니다.

1. Azure가 Kafka 호환 이벤트 버스로 리소스 변경 이벤트를 보냅니다.
2. 이벤트 수집기가 페이로드를 정규화하고 인벤토리 컨텍스트를 추가한 뒤 리소스의 상관관계 키를 찾습니다.
3. T0가 버전으로 관리되는 네트워크 규칙을 찾아 타입 기반 수정 작업을 제안합니다.
4. what-if가 정확한 변경 내용을 확인하고, 안전성 검토는 영향 범위상 승인이 필요하다고 판단합니다.
5. ChatOps가 규칙, 근거, 영향 범위, 중단 조건, 롤백 참조가 담긴 승인 카드를 보냅니다.
6. 승인 후 실행기는 콘솔에서 리소스를 직접 바꾸는 대신 수정 pull request를 엽니다.
7. 전달, 승인, 최종 결과가 추가 전용 감사 기록에서 연결되고 콘솔에 읽기 전용 근거로 표시됩니다.

거부, 반려, 시간 초과, 롤백도 같은 경로를 따릅니다. 마지막 단계만 달라집니다.

장애 격리

장애	시스템 대응
콘솔을 사용할 수 없음	코어 처리, Git 전달, ChatOps가 계속 동작합니다.
ChatOps를 사용할 수 없음	승인이 필요한 작업은 대기열에 남으며 자동 실행되지 않습니다.
이벤트 백로그가 늘어남	백프레셔가 동시성을 제한하고 재시도 또는 dead-letter 처리를 위해 작업을 보관합니다.
감사나 핵심 공급자를 사용할 수 없음	자율성이 관찰 모드로 낮춰지거나 작업이 보류됩니다.
중복 전달	멱등성 키와 리소스 잠금이 두 번째 변경을 막습니다.
T2 모델의 의견이 갈림	상반된 근거를 보관하고 사례를 사람 검토로 보냅니다.
롤백 검증 실패	인시던트가 열린 상태로 유지되고 복구가 타입 기반 파이프라인을 통해 에스컬레이션됩니다.
Forseti를 사용할 수 없음	새 에이전트 결정이 발행되지 않고 작업은 검토 대기로 보관됩니다.
Thor를 사용할 수 없음	감지, 판단, 감사는 계속되지만 아무것도 변경되지 않습니다.
Var를 사용할 수 없음	승인이 필요한 작업은 대기열에 남고 시간 초과는 감사된 미실행으로 처리됩니다.
Saga나 Vidar를 사용할 수 없음	감사와 롤백은 필수 의존 항목이므로 적용 모드 시작과 변경이 차단됩니다.
에이전트 런타임 실패	장애를 기록하고 기존 주 소비자는 계속 동작합니다.

다음 단계

알아볼 내용	문서
수준별로 판단 방식을 고르는 기준	결정론 우선
작업이 자동 실행, 승인 필요, 거부로 나뉘는 기준	신뢰 수준
타입이 정의된 작업과 워크플로의 위치	에이전트 기반 자동화
각 에이전트가 책임을 나누는 방식	에이전트와 자가 복구
Azure 리소스를 안전하게 준비하는 방법	배포 사전 점검
운영자가 인시던트에 대응하는 방법	SRE 런북