FDAI 시작하기
FDAI(Forward Deployed AI)는 자율 클라우드 운영 컨트롤 플레인입니다. 반복적으로 발생하는 운영 이벤트 대부분을 규칙, 정책, 타입이 정의된 작업으로 처리합니다. 결정론적 경로에서 판단할 수 없는 모호한 사례에만 언어 모델을 사용합니다. 모든 자율 작업은 위험도 분류를 거치며, 안전 임계값을 넘는 작업은 사람의 승인을 기다립니다.
FDAI는 클라우드 안에서 동작하는 전문 에이전트 조직이라고 생각할 수 있습니다. 에이전트는 리소스 변경을 감지하고, 버전으로 관리되는 규칙 카탈로그에 따라 각 변경을 판단합니다. 안전한 작업 대부분은 직접 실행하고, 위험도가 높은 일부 작업만 운영자에게 검토를 요청합니다. 운영자는 승인 또는 거부 수준에서 시스템을 운영하므로 반복 작업 대신 의사 결정에 집중할 수 있습니다.
어떤 작업도 임의로 수행되지 않습니다. 모든 작업은 타입이 정의된 온톨로지 항목을 기반으로 생성되며, 각 항목에는 중단 조건, 롤백 경로, 영향 범위 제한, 감사 기록이 포함됩니다.
참조 구현은 Azure를 대상으로 합니다. 다른 클라우드 공급자를 추가할 때 핵심 구조를 다시 작성하지 않도록 클라우드 중립적인 연결 지점을 유지합니다. 현재 Azure 이외의 어댑터는 제공되지 않습니다.
무엇을 할 수 있나요?
섹션 제목: “무엇을 할 수 있나요?”FDAI는 하나의 이벤트 기반 코어에서 세 가지 운영 영역을 지원합니다. 각 영역은 고유한 규칙과 작업을 사용하면서 컨트롤 루프, 관측 기능, 감사 로그, 안전성 검토를 공유합니다.
변경 안전성
섹션 제목: “변경 안전성”제안된 모든 변경은 규칙 카탈로그의 정책 검사를 거칩니다. FDAI는 정책을 기계가 읽을 수 있는 규칙으로 표현한 policy-as-code를 기준으로 변경 후보를 예행 실행하고 영향 범위를 제한합니다. 그런 다음 조건을 충족한 등록 작업을 실행 경로로 전달하거나 사람의 승인을 요청합니다. 생성된 복구 pull request는 자동으로 병합하지 않습니다.
예시: IaC pull request가 public-egress NSG 규칙을 제안 -> 안전성 검토에서 고위험으로 판정 -> Teams에 승인 카드 도착 -> 승인자가 승인 선택 -> 통제된 전달 경로에서 검토된 작업을 적용하고 감사 기록 생성.
복원력
섹션 제목: “복원력”정기 DR 훈련, 데이터베이스 DR 훈련, 영향 범위가 제한된 카오스 실험을 지원합니다. 실행 주기, 영향 범위, 증적은 별도로 관리합니다. 스케줄러는 실행 주기를, 안전성 검토는 영향 범위를, 감사 로그는 증적을 담당합니다.
예시: 야간 작업에서 핵심 데이터베이스의 특정 시점 복원(PITR) 공백 발견 -> 에이전트가 훈련 시간 안에 대응하는 복원 훈련 예약 -> 복원이 RPO/RTO 목표 충족 -> 감사 기록 생성.
비용 거버넌스
섹션 제목: “비용 거버넌스”비용 이상을 감지하고 적정 리소스 규모를 제안합니다. 유휴 디스크 정리, 사용하지 않는 공용 IP 해제, 연결되지 않은 NIC 제거 같은 저위험 작업은 자동으로 실행할 수 있습니다.
예시: 비용 이상 탐지기가 과도하게 프로비저닝된 캐시 계층 감지 -> T0 규칙 일치 -> 2주 동안 관찰 모드에서 규칙의 정확성 검증 -> 적용 모드로 전환 -> 롤백 경로가 포함된 리소스 규모 조정 pull request 전달.
기존 환경과 연동
섹션 제목: “기존 환경과 연동”FDAI는 이벤트 기반으로 동작하고 클라우드 공급자 중립적인 추상화 계층을 사용하므로 기존 운영 환경에 연결할 수 있습니다:
- Azure 리소스: 구현된 대상입니다. 컴퓨트, 스토리지, 데이터베이스, 네트워킹, 신원, Kubernetes를 제공되는 규칙 카탈로그와 작업 온톨로지로 다룹니다.
- 이벤트 버스: Kafka 호환 스트림(Kafka 엔드포인트의 Event Hubs)이 리소스 변경 신호, Activity Log 이벤트, 발견된 문제를 컨트롤 루프로 전달합니다.
- policy-as-code: 룰은 클라우드 공급자 중립 스키마로 정규화되어 OPA와 Rego로 평가됩니다. 따라서 결정론적 경로는 기계가 읽을 수 있는 정책을 기반으로 동작합니다.
- 전달 채널: 작업은 수정 pull request로 전달할 수 있으며 런타임 승인 요청은 현재
Teams 또는 Console의
approve_hil도구로 처리합니다. Slack A1 승인은 계획 상태이며 아직 제공되지 않습니다. PR 기반 작업에서는 Git이 변경 기록과 롤백 참조를 보관합니다. - FDAI Console: 실행기의 특권 신원을 사용하지 않고도 운영 상태를 확인하고 질문하며, 결정을 검토하고 범위가 제한된 운영 요청을 제출할 수 있습니다.
어떻게 작동하나요?
섹션 제목: “어떻게 작동하나요?”세 개의 티어가 하나의 컨트롤 루프를 구성합니다. 트러스트 라우터는 이벤트를 판단할 수 있는 가장 낮은 티어를 선택합니다. 그런 다음 안전성 검토에서 결과 작업을 바로 실행할지 사람의 승인을 기다릴지 결정합니다.
- T0, 결정론적 규칙(목표 적용 범위 70-80%): 정답이 명확한 policy-as-code 판단입니다. 모델을 호출하지 않으며 모호함이 없습니다.
- T1, 경량 패턴 재사용(목표 15-20%): 감사 로그 이력을 바탕으로 패턴 일치, 임베딩 유사도, 소형 분류 모델을 사용합니다. 비용이 낮고 빠르며 감사할 수 있습니다.
- T2, 심층 추론(목표 5-10%): 서로 다른 모델 간 교차 검증, 결정론적 검증기, 근거 확인을 거치는 프런티어 모델입니다. 모델은 작업을 제안하고, 검증기가 실행 가능 여부를 판단합니다.
event -> event-ingest -> trust-router -> T0 | T1 | (T2 -> quality-gate) -> risk-gate -> auto | HIL | abstain -> executor -> delivery -> audit이 파이프라인에서 risk-gate는 안전성 검토입니다. 결과는 auto(자동 실행),
HIL(사람 승인 필요), abstain(검토 보류) 세 가지입니다.
이 백분율은 목표치입니다. 측정된 기준선이 마련되기 전까지 FDAI는 이 수치를 달성했다고 주장하지 않습니다 (goals-and-metrics-ko).
이 컨트롤 루프를 실제로 운영할 수 있도록 두 가지 구성 요소가 지원합니다.
- 타입 기반 작업 온톨로지. 설정 드리프트 수정, 서비스 재시작, DR 훈련 실행처럼
FDAI가 수행할 수 있는 모든 변경은 코드로 관리되는 카탈로그의
ActionType항목입니다. 규칙이 발동하거나 운영자가 작업을 요청하면 해당 타입의 안전 계약을 상속하는 구체적인 작업이 생성됩니다. concepts/ontology-driven-automation-ko.md를 참조하세요. - 에이전트 조직. 이름과 역할이 정해진 에이전트 집합이 컨트롤 루프를 담당합니다. 일부는 관찰하고, 각각의 담당 에이전트가 판단, 승인 전달, 실행, 감사 기록을 맡습니다. 문제가 발생하면 함께 해결하고 위험도가 높은 일부 사례만 운영자에게 알립니다. concepts/agents-and-self-healing-ko.md를 참조하세요.
FDAI 파일럿을 시작할 준비가 된 경우
섹션 제목: “FDAI 파일럿을 시작할 준비가 된 경우”광범위한 적용을 승인하기 전에 범위가 제한된 운영 영역 하나와 작업 유형 하나의 준비 상태를 평가합니다.
- 운영자가 드리프트, 비용 회귀, 정책 위반처럼 반복되는 클라우드 설정 이벤트를 승인하거나 롤백하는 데 실제 시간을 쓰고 있습니다.
- 선택한 이벤트 유형에 신뢰할 수 있고 기계가 읽을 수 있는 근거와 결정론적 정책이 있습니다. IaC는 효과적인 경로 중 하나지만 등록된 직접 API 및 도구 작업도 같은 타입 안전 계약을 사용할 수 있습니다.
- 자율성의 개선 효과를 측정할 기준선이 있거나 이를 만들 수 있습니다. FDAI는 같은 조건의 비교 측정 없이 개선 배율을 주장하지 않습니다.
- 규정 준수 체계에서 저위험 변경의 자동 실행을 허용합니다. 단, 모든 작업에 중단 조건, 롤백 경로, 영향 범위 제한, 감사 로그 기록이 있어야 합니다.
아직 적합하지 않은 경우
섹션 제목: “아직 적합하지 않은 경우”- 신뢰할 수 있는 근거나 결정론적 정책이 없는 환경: 컨트롤 루프가 추측 없이 선택한 이벤트와 작업을 검증할 수 없습니다. 모든 실행 경로에 IaC가 필수인 것은 아닙니다.
- 일회성이고 반복되지 않는 인시던트: FDAI의 이점은 반복되는 다수를 정리하는 데서 나옵니다. 새롭고 드문 사례는 사람이 계속 담당합니다.
- Azure 외 클라우드: 추상화는 중립적으로 설계되어 있지만, Azure 어댑터만 제공됩니다.
첫 번째 안전한 적용
섹션 제목: “첫 번째 안전한 적용”범위가 제한된 운영 영역 하나와 작업 유형 하나로 시작하세요. 첫 번째 적용의 목표는 첫날부터 자동화를 최대화하는 것이 아니라 검증 가능한 근거를 확보하는 것입니다.
- 범위를 정합니다. 리소스 그룹 수준의 범위를 선택하고, 책임 담당자를 지정하고, 범위 안에 들어갈 이벤트와 작업을 정리합니다.
- 준비 상태를 검사합니다. 컨트롤 루프를 시작하기 전에 배포 사전 검사를 완료하고 신원, 정책, 연결, 롤백과 관련된 차단 요소를 해결합니다.
- 기준선을 기록합니다. 이벤트 발생량, 판단 시간, 운영자 개입 횟수, 롤백 빈도를 목표와 메트릭 계약에 따라 측정합니다.
- 관찰 모드에서 확인합니다. FDAI가 실제 변경을 수행하지 않고 판단과 감사 기록만 생성하도록 합니다. 오탐, 승인 결정, 검증기 실패, 실제로 실행했을 작업을 검토합니다.
- 작업을 하나씩 적용 모드로 전환합니다. 고정된 시나리오, 롤백 예행연습, 정책 검사가 적용 기준을 충족한 작업에 대해서만 적용 모드를 활성화합니다. 나머지 작업은 모두 관찰 모드로 유지합니다.
예시: 비프로덕션 리소스 그룹 하나를 온보딩 -> 드리프트 수정 작업 하나를 2주 동안 관찰 -> 감사 기록 검토 -> 롤백 예행연습 -> 나머지 카탈로그는 관찰 모드로 유지하면서 해당 작업만 적용 모드로 전환.
적용 전에 확인할 근거
섹션 제목: “적용 전에 확인할 근거”다음 정보를 사용해 작업의 실행 준비 상태를 판단하세요. 배포에 성공했다는 사실만으로는 충분하지 않습니다.
| 근거 | 확인할 수 있는 내용 | 지원하는 결정 |
|---|---|---|
| 규칙 적용 범위와 판단 보류 빈도 | 결정론적 규칙이 추측 없이 의도한 사례를 처리하는지 | 관찰 모드 유지 또는 테스트 시나리오 확대 |
| 정책, 스키마, 가상 실행(what-if) 결과 | 제안된 모든 변경이 결정론적 검증기를 통과하는지 | 실행 차단 또는 적용 준비 계속 |
| 승인, 거부, 운영자 재정의 | 운영자 판단이 자동 결정과 여전히 다른 지점 | 임계값, 적용 범위 또는 규칙 조정 |
| 롤백 예행연습 | 선언된 복구 경로가 예상 시간 안에 이전 상태를 복원하는지 | 적용 허용 또는 차단 |
| 감사 기록의 완전성 | 이벤트부터 결과까지 모든 경로를 재구성할 수 있는지 | 근거 기록 수락 또는 릴리스 보류 |
여러분의 환경과 함께 성장
섹션 제목: “여러분의 환경과 함께 성장”- 첫째 날: T0 규칙이 관찰 모드로 이벤트를 처리합니다. 발견된 모든 문제가 감사 기록을 남기므로 FDAI가 무엇을 했을지 확인할 수 있습니다.
- 첫째 주: 관찰 지표로 어떤 작업이 적용 기준을 통과하는지 확인합니다. T1은 해결된 인시던트의 패턴을 재사용하기 시작하고, T2는 낮은 비중을 유지합니다.
- 첫째 달: 적용 모드로 전환된 작업이 롤백 경로와 함께 자동으로 실행됩니다. 발견 루프는 승인, 관찰 모드에서 발견된 드리프트, 운영자 재정의 같은 운영 신호를 바탕으로 카탈로그 갱신을 제안하기 시작합니다.
시작하기
섹션 제목: “시작하기”- 운영 모델 이해: 사이트 안정성 엔지니어링을 읽은 다음 FDAI SRE 기초와 결정론 우선 판단을 살펴보세요.
- 로컬 워크스테이션 준비: 로컬 개발 빠른 시작을 따라 Docker, 인증, 로컬 상태 및 전체 Console 스택을 구성하세요.
- Azure 환경 배포: 배포 사전 검사를 수행한 다음 배포 빠른 시작과 상세 배포와 온보딩 참고 자료를 사용하세요.
- 사람 검토 및 승인 절차 운영: 변경 승인과 감사 로그 읽기를 따라 해보세요.
- 도입 계획: 로드맵 단계 요약을 사용해 범위, 담당 체계, 관찰 모드 근거, 적용 전환 순서를 정하세요.