Intro

안녕하세요. 클라우드 AI 플랫폼(ASTRA)의 운영 업무를 담당하고 있는 AX플랫폼본부 “김현모, 오명환, 이창민” 입니다.

클라우드 AI 플랫폼은 KT의 여러 AI 서비스가 공통으로 사용하는 Microsoft Azure 기반 통합 플랫폼입니다.
모델 서빙, Agent 운영, Observability까지 하나의 기반 위에서 제공하며, 지원 중인 서비스는 대표적으로 마이K AI 에이전트와 사장이지 AI 에이전트가 있습니다.

저희 파트는 클라우드 AI 플랫폼을 구성하는 Azure 공통 리소스(Key Vault, APIM, AKS, Langfuse, LLM서빙 등)의 운영을 담당하고 있습니다.

BA, 모델서빙, Azure 리소스 관리, 보안조치, Agent 오픈 지원까지 업무 영역은 넓지만 인원은 소수입니다. 운영 특성상 24×7 대응을 해야 하기 때문에 운영 공백을 줄이는 것이 늘 저희의 목표였습니다.

문제는 전사 방향에 따라 AI 프로젝트가 계속 확장된다는 점이었습니다. 운영 범위가 늘어나는 속도를 인원이 따라갈 수 없다면, 남는 선택지는 하나였습니다. 사람이 반복해서 확인하던 작업을 시스템에 위임하는 것.

그래서 저희는 도구를 만들기 전에 모든 도구를 탑재할 공통 아키텍처를 먼저 설계하고, 그 위에 기능을 하나씩 얹는 방식으로 진행했습니다.

이 글에서는 최소 인원 운영 조직이 어떤 기준으로 자동화 대상을 골랐고, 어떤 아키텍처 원칙으로 도구 5종을 하나의 파이프라인에 태웠는지, 그리고 그 과정에서 마주친 네트워크/플랫폼 레벨의 장벽을 어떻게 구조로 우회했는지를 공유하고자 합니다.

Problems

자동화 방향 설계

먼저 무엇을 자동화할지 정해야 했습니다. 운영 자동화 방향을 정해야 정말 필요한 도구를 개발할 수 있기 때문입니다.

아키텍처 및 파이프라인을 설계하기 위해 아래와 같이 기준을 세 가지로 선별하였습니다.

무엇이 문제인가?

운영 자동화 방향을 결정하였으니, 이제 어떤 것을 개발해야할지 명확해졌습니다.

경험을 바탕으로 빠르게 공백을 파악할 수 있었고, 이를 5가지로 추려서 모듈 개발을 진행하고자 하였습니다.

다섯 가지 모두 성격이 같습니다.

주기적으로 조회해서, 사람이 볼 수 있게 정리해주면 되는 일입니다. 기술적으로 어려운 과제는 없었습니다.

자동화 아키텍처의 부재

다섯 개를 모듈을 각각 만들면 이렇게 됩니다.

소수 인원이 24×7을 커버하는 조직에서 관리 대상이 다섯 배가 되면, 초기 한두 달은 잘 돌다가 결국 아무도 들여다보지 않는 자동화가 됩니다.

정형화된 아키텍처 없이 난개발되는 것이 저희가 가장 경계한 시나리오였습니다.

로컬 스크립트의 한계

초기에 일부 도구는 개인 PC의 스케줄러로 먼저 만들어 돌려봤습니다. 빠르게 검증할 수 있다는 장점은 분명했지만, 운영에 붙이자 두 가지가 사람에게 의존한다는 사실이 드러났습니다.

의존 항목	실제로 발생한 문제
PATH·가상환경	대화형 셸에서 실행할 때와 스케줄러가 실행할 때 환경이 달라, "내 터미널에서는 되는데?!" 상황이 반복
PC의 전원·네트워크 상태	PC가 꺼져 있거나 네트워크가 끊긴 순간에 스케줄이 오면 그대로 실패

두 문제 모두 코드를 고쳐서 해결되지 않습니다. 실행 환경 자체를 고정해야 사라지는 종류의 문제였습니다.

Solutions

설계 원칙: 도구가 늘어도 관리 대상은 늘지 않게

저희가 세운 목표는 단순했습니다.

수십 개의 도구를 개발해도 운영 부담이 늘어나지 않는 구조를 만드는 것입니다.

그래서 다섯 도구가 공유할 파이프라인을 먼저 고정했습니다.

이 구조를 지탱하는 설계 베이스는 다섯 가지입니다.

설계 베이스	이유
모든 도구를 Azure Function App 상시가동 환경에서 실행	개인 PC·개인 계정 세션에 의존하지 않음. 실행 환경이 배포 패키지로 고정
애플리케이션은 알림에 직접 개입하지 않고 로그만 남김	앱의 책임을 "탐지와 기록"으로 한정. 알림 조건 변경 시 코드 재배포 불필요
인증은 UMI(User-Assigned Managed Identity)로 통일	시크릿이 존재하지 않으니 보관·만료 관리 대상도 없음
적재·시각화 계층을 공유	새 도구가 늘어도 관측 설계 비용이 늘지 않음
대시보드뿐 아니라 Alert 시스템까지 구축	대시보드는 사람이 볼 때만 정보를 줌. 안 보고 있을 때 알려주는 것이 실질 가치

설계 베이스에 준수하며 설계된 아키텍처는 다음과 같습니다.

하나의 Function App에 여러 도구 태우기

Function App을 통한 실제 코드 구현은 Blueprint 결합 배포 방식으로 진행하였습니다.

도구마다 Function App을 만들면 결국 관리 대상이 늘어나고 그에 따라 비용도 늘어나기 때문에, 하나의 App에 여러 도구를 얹는 구조를 택한 것 입니다. 이런 구조는 관리 대상이 많지 않고 비용이 적게 든다는 장점이 있었지만, 물론 단점 또한 존재하였습니다.

결합 배포의 장벽은 모듈 충돌이었습니다. 각 프로젝트가 모두 config라는 이름의 모듈을 갖고 있어서, 같은 인터프리터에 올라가면 서로를 덮어쓸 여지가 있었습니다. 패키지를 네임스페이스로 분리한 뒤, 각자 독립적인 기능을 하게끔 설계하였습니다.

# 결합 배포 검증 — 두 프로젝트의 config가 서로 다른 객체여야 한다 assert sys.modules["config"] is not sys.modules["finops.config"]

설정 파일은

config/config.yaml
config/finops_config.yaml
config/lightsizing_config.yaml

처럼 모듈별로 나누고, 환경변수도 CERT_MONITOR_*, FINOPS_* , LIGHTSIZING_*접두어로 분리했습니다. 스케줄은 서로 겹치지 않게 시간을 띄웠습니다.

각 도구는 독립된 프로젝트 구조를 그대로 유지하고, 배포 시점에만 하나의 배포 묶음으로 결합합니다. 새 도구를 추가할 때도 기존 도구의 코드는 건드리지 않고, 새 도구의 Timer Trigger 등록만 추가하면 됩니다. 스케줄은 App Settings 환경변수를 참조하게 해서, 주기를 바꾸는 데 재배포가 필요 없도록 했습니다.

알림은 App이 직접 보내지 않는다

이 결정은 원래 계획이 아니었습니다.

처음에는 평범하게 스캔 → Slack Webhook 발송 구조로 만들었습니다.

배포 후 실행해보니 함수는 정상 수행 되었고 스캔 집계 로그도 멀쩡한데, Slack에만 아무것도 오지 않았습니다. 로그를 열어보니 재시도 3회 후 실패로 끝나 있었습니다.

WARNING slack.webhook failed (attempt 1/3): SSLError(SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol'))

여기서 조사 방향을 가른 것은 에러의 종류였습니다.

애러의 종류 : UNEXPECTED_EOF_WHILE_READING
의미하는 것 : TLS 핸드셰이크 도중 연결이 강제로 끊김 — 중간 장비가 세션을 리셋할 때의 전형적 패턴

해당 오류 덕에 인증서 설정이 아니라 네트워크 경로를 봐야 한다는 판단이 섰고, 확인해보니 근거가 맞아떨어졌습니다.

결론적으로 중앙 방화벽의 egress 정책이었고, 보안 정책상 Function App에서 외부로 Webhook을 직접 호출하는 경로 자체가 허용되지 않는다는 결론에 도달했습니다.

여기서 방화벽 예외를 신청하는 대신 알림 주체를 옮기기로 했습니다. 애플리케이션은 탐지 결과를 로그로만 남기고, 그 로그를 읽어 조건을 판단하고 통보하는 일은 Grafana가 맡는 구조입니다.

구분	앱이 직접 발송	Grafana Alerting 경유 (채택)
필요한 네트워크	외부 도메인 egress 허용	불필요 (기존 검증된 인프라 내에서 완결)
알림 조건 변경	코드 수정 + 재배포	Grafana UI에서 즉시 반영
알림 채널 추가	채널별 구현 추가	Contact Point 추가
시각화	별도 작업 필요	동일 데이터로 대시보드가 함께 구성됨

사내에 Grafana → Slack 연동 표준 가이드가 이미 있어 별도 협의 없이 진행할 수 있었고, 결과적으로 개발 기간도 단축됐습니다. 제약 때문에 바꾼 구조였지만, 알림 임계값 하나 바꾸는 데 배포가 필요 없어진 것은 그 자체로 얻은 이득이었습니다.

알림 채널은 운영팀 전용 Slack App(ASTRA-cert-monitor)을 별도로 만들고, 발송에 필요한 최소 스코프만 부여했습니다. 이후 Grafana Contact Point에 연결하고 Alert Rule로 조건을 정의하면 리포트가 자동 발송됩니다.

로그가 곧 인터페이스가 됩니다

알림 판단을 Grafana에 맡긴 순간, 각 도구가 남기는 로그는 단순한 기록이 아니라 다음 계층이 소비하는 API 스펙이 됩니다. 그래서 다섯 도구가 같은 규약을 따르도록 고정했습니다.

각 실행은 고유 run_id를 갖고, 두 종류의 이벤트를 남깁니다.

이벤트	내용
`AZURE_*_SUMMARY`	실행 1건당 1개 — 총 건수, 총 예상 금액, 실패 건수, 소요 시간
`AZURE_*_RECORD`	탐지 항목 1건당 1개 — 리소스 식별 정보, 실측치, 판단 사유, 포털 딥링크

레코드 필드도 도구 간에 최대한 맞췄습니다.

run_id, kind resource_name, resource_group, subscription_id, subscription_name detail, reason, portal_url pricing_source # retail_api / sku_table / unknown

pricing_source는 조금 특별한 필드입니다. 가격 API 조회에 실패하면 내부 SKU 테이블로 폴백하는데, 화면에 숫자만 뜨면 그게 실제 조회값인지 추정값인지 알 수 없습니다. 추정치의 신뢰도를 사람이 판단할 수 있도록 출처를 함께 남깁니다.

안전장치를 만들었습니다

운영 자동화에서 가장 무서운것은 자동화가 무언가를 바꿔버리는 것입니다. 그래서 다섯 도구 전부에 다음 원칙을 먼저 넣고 기능을 붙였습니다.

모든 Azure 호출은 허용 목록을 통과해야 실행됩니다.

def read_only_call(op_name, fn, args, kwargs): if op_name not in READ_ONLY_ALLOWLIST: raise ReadOnlyViolation(f"허용되지 않은 호출: {op_name}") return fn(args, **kwargs) ... #함수 허용 목록 READ_ONLY_ALLOWLIST= ( "list", "get", "show", "check", "query", "read", "head", )

"변경하는 코드를 짜지 않는다"가 아니라 “변경하는 코드를 짜도 실행되지 않는다"로 만드는 것이 목적이었습니다.

인증서 만료일을 보려면 Key Vault를 조회해야 하는데, 여기서 실수하면 개인키를 다루게 됩니다. get_certificate(), download, secrets 클라이언트를 코드에서 아예 사용하지 않고 정책 메타데이터만 조회하도록 했습니다. 권한이 나중에 넓어져도 코드가 시크릿을 읽을 경로 자체가 없습니다.

이 원칙들 덕분에 애플리케이션이 오작동해도 운영 환경에는 영향이 없습니다. 권한 자체가 최소화되어 있어, 로직에 버그가 있어도 실제로 가능한 동작은 "조회"로 한정됩니다.

도구별 탐지 대상

#	도구	탐지 대상
1	인증서 만료 탐지	Key Vault / App Gateway / APIM / App Service / Front Door 5종
2	저사용 자원 다운사이징	Container App · VM/VMSS · App Service Plan · PostgreSQL · AI Search 등 6종
3	미사용 자원 탐지	고아 디스크 · 미할당 Public IP · 정지 VM · 빈 LB · 미연결 NSG · 오래된 스냅샷 6종
4	리소스 의존성 분석	APIM·AppGW·AKS·ACA·PE·NSG·Key Vault 참조관계
5	리소스 변경이력 추적	Azure Resource Graph 변경 이력

도구 1. 인증서 만료 탐지

인증서는 Key Vault에만 존재하지 않습니다. Application Gateway, APIM, App Service, Front Door 등 여러 Azure 리소스에서 인증서를 직접 참조하거나 연결해 사용합니다.

따라서 Azure 알림만으로는 전체 인증서 상태를 확인하기 어렵고, 특정 리소스에 연결된 인증서가 누락될 수 있습니다.

이 도구는 다음 5종 리소스를 대상으로 인증서 만료 현황을 전수 점검합니다.

대상	점검 목적
Key Vault	인증서 원본 및 정책 메타데이터 확인
Application Gateway	Listener에 연결된 인증서 만료 위험 확인
APIM	Custom domain 인증서 만료 위험 확인
App Service	바인딩된 인증서 만료 위험 확인
Front Door	프런트엔드 도메인 인증서 만료 위험 확인

운영 관점에서는 다음 효과가 있습니다.

구분	효과
장애 예방	만료 D-90/60/30/14/7/3/0 등 단계별 사전 감지
보안성	개인키·시크릿 값이 아니라 인증서 정책·만료일 등 메타데이터 중심 조회
확장성	Key Vault 외 AppGW/APIM/App Service/Front Door까지 같은 리포트에 통합

즉, 이 도구는 단순 알림 스크립트가 아니라 구독 분리 환경에서 인증서 운영 공백을 메우는 기본 점검 레이어입니다.

도구 2. 저사용 자원 다운사이징

저사용 자원 다운사이징 도구는 “쓰고는 있지만 과도하게 큰 자원”을 찾습니다.

미사용 자원은 정리해도 영향이 없지만, 사용 중인 자원을 잘못 줄이면 즉시 장애입니다. 그래서 이 도구에서 가장 공들인 부분은 추천 로직이 아니라 오탐 방어 로직였습니다.

오탐 방어 로직	내용
PostgreSQL 메모리 가드	메모리 사용률이 임계값(20%) 이상이면 CPU와 무관하게 다운사이징 금지.
스파이크 오탐 방지	p95 사용률이 임계값 이상이면 평균 사용률이 낮아도 “안전” 판정에서 제외.한 달에 하루 이틀 바쁜 것은 정상 처리.
미검증 SKU 추천 금지	검증된 다운사이징 경로에 없는 SKU는 “수동 검토 필요”로만 표기

특히 PostgreSQL은 CPU만 낮다고 줄일 수 없습니다. shared buffers, cache 등으로 인해 메모리가 실질 병목인 경우가 있고, 인스턴스 크기를 줄이면 메모리도 함께 줄어들기 때문입니다.

if mem_avg_percent >= POSTGRES_MEM_SAFETY_PERCENT: return Recommendation( recommended_sku="(다운사이징 금지)", safe_to_downsize=False, caution="메모리 사용률이 안전 임계값 이상입니다. CPU와 무관하게 금지합니다.", )

도구 3. 미사용 자원 탐지

미사용 자원 탐지 도구의 핵심은 운영자가 놓치기 쉬운 비용 누수 항목을 유형별로 자동 식별하고, 예상 절감액까지 함께 제시하는 것입니다.

이 도구는 다음 6종을 우선 탐지 대상으로 정의했습니다.

유형	판단 기준	운영상 의미
고아 Managed Disk	소유 리소스 없음 + Unattached 상태	삭제된 VM의 디스크가 남아 비용 발생 가능
미할당 Public IP	IP 구성 없음 + NAT Gateway 미연결	사용하지 않는 공인 IP 비용 발생 가능
정지 VM	Deallocated 상태	VM은 꺼져 있어도 디스크·고정 IP 비용은 계속 발생
빈 Load Balancer	백엔드 풀이 없거나 멤버 0개	트래픽 처리 대상이 없는 로드밸런서
미연결 NSG	서브넷·NIC 어디에도 미연결	직접 과금은 없지만 정리 대상
오래된 스냅샷	기준일 이상 장기 보관	백업성 잔존 데이터로 비용 누적 가능

단순히 “정리 대상이 있습니다”라고 보여주는 데서 끝내지 않고, Azure Retail Price API 기반으로 예상 월 비용을 계산해 리포트 상단에 총 절감 가능 금액을 표시합니다.

가격 조회가 실패하면 내부 SKU 테이블 기반 추정치로 폴백하고, pricing_source 필드로 산정 출처를 남겨 숫자의 신뢰도를 구분할 수 있게 했습니다.

도구 4. 리소스 의존성 분석

리소스 의존성 분석 도구는 리소스 간 참조관계를 그래프로 구성해, 변경·삭제 작업 전 영향 범위를 파악하기 위한 도구입니다. 현재 리소스 인벤토리 10,239건과 의존성 관계 11,953건을 기반으로 영향도를 분석합니다.

리소스 간 참조관계를 그래프로 엮어 변경·삭제 시 영향 범위를 위험도(HIGH/MIDDLE/LOW)로 산정합니다.

운영 관점에서는 다음 효과가 있습니다.

구분	효과
변경 전 영향도 확인	삭제·변경 대상 리소스가 다른 리소스에 어떻게 연결되어 있는지 확인
판단 근거 제공	Risk Level뿐 아니라 근거 목록을 함께 제공
장애 예방	참조관계 누락으로 인한 변경 사고 가능성 감소
확장성	신규 리소스 타입을 수집기에 추가해 그래프 범위 확장 가능

도구 5. 변경이력 추적

변경이력 추적 도구는 Azure Resource Graph의 변경 이력을 수집해 Log Analytics에 누적 적재하고, 장애 발생 시 “누가·언제·무엇을 바꿨는지”를 확인하기 위한 RCA 지원 도구입니다.

Azure Resource Graph의 변경 이력은 보관 기간이 제한적이므로, 운영 관점에서는 필요한 변경 이력을 별도 저장소에 누적하는 것이 중요합니다. 이 도구는 변경 내역을 주기적으로 수집해 Log Analytics에 적재하고 Grafana에서 조회할 수 있게 구성했습니다.

특기할 부분은 변경 로그를 사건 단위로 재구성한 것입니다. 리소스 하나를 한 번 저장해도 변경된 속성 수만큼 로그 행이 생성될 수 있습니다. 실제로 리소스 1건 저장에 속성 96개가 동시에 변경된 사례가 확인되었습니다. 이를 그대로 보여주면 화면에는 96줄이 나오지만, 운영자가 알고 싶은 “어떤 사건이 있었는가”는 오히려 파악하기 어렵습니다.

따라서 리소스, 상관ID, 시간 버킷을 기준으로 묶어 사건 단위 한 줄 요약으로 보여주도록 개선했습니다.

Result

대시보드까지 구현하는게 완결점

이번 작업의 완결점은 수집한 데이터를 사람이 확인하고 판단할 수 있는 화면으로 제공하는 것이었습니다.

대시보드는 도구별 영역(Row)을 나눠 소유하고, 각 Row를 요약 지표 → 분석 패널 → 상세 목록 순서로 구성했습니다. 상단에는 대시보드 전체에 적용되는 전역 필터를 배치했습니다.

구독
리소스그룹
도구별 검색어

이 구조를 사용하면 운영자는 화면을 이동하지 않고도 같은 기준으로 인증서, 미사용 자원, 저사용 자원, 의존성, 변경 이력을 조회할 수 있습니다. 알림은 대시보드 조회와 분리해 Alert Rule과 Contact Point를 구성하고 Slack으로 전달합니다.

Grafana 구현할 때 확인한 세 가지

필터가 선택한 값대로 동작하는지 확인합니다.
화면에서 구독이나 리소스그룹을 선택했다고 해서 모든 패널이 자동으로 같은 조건으로 조회되는 것은 아닙니다.
화면의 선택 상태만 보지 말고, 실제 조회 결과가 선택한 구독과 리소스그룹에 맞게 바뀌는지 확인해야 합니다.
구독에 따라 리소스그룹 목록이 바뀌는 구조라면, 하위 목록도 함께 확인합니다.
화면에 사용할 수 있는 데이터인지 먼저 확인합니다.
데이터에 특정 항목이나 필드가 있다는 것만으로 충분하지 않습니다.
실제로 값이 채워져 있는지, 대부분 0이나 빈 값은 아닌지 먼저 확인해야 합니다. 예를 들어 저사용 자원에서 절감액을 보여주려고 해도 실제 절감액이 제대로 계산되지 않는다면 해당 패널은 운영에 도움이 되지 않습니다.
이 경우처럼 실제 값이 확인된 CPU·MEM 사용량과 안전 여부를 중심으로 화면을 구성하는 것이 더 적절합니다.
한 개를 선택했을 때와 전체를 선택했을 때를 모두 확인합니다.
구독이나 리소스그룹을 하나만 선택한 경우에는 해당 항목만 표시되는지, 전체를 선택한 경우에는 전체 대상이 정상적으로 표시되는지 각각 확인합니다. 요약 숫자와 상세 목록도 같은 기준으로 바뀌어야 합니다.
이 검증이 끝나야 대시보드를 실제 운영자가 결과를 확인하고 후속 조치를 판단하는 화면으로 사용할 수 있습니다.

실측 결과

저사용 자원 스캔 (PRD 구독, 2026-09-07)

유형	건수	판독 결과
VM	55건	CPU 사용률 0~9% (p95)
PostgreSQL	17건	CPU 평균 5%, MEM 평균 20~30%
Azure Container Apps	9건	CPU 평균 0%, MEM 평균 0~9%

80건 이상의 저사용 자원을 리소스 종류별로 서로 다른 판독 알고리즘을 통해 한 화면에서 확인할 수 있게 됐습니다.

여기서 눈여겨볼 것은 PostgreSQL 17건입니다. CPU 평균이 5%로 매우 낮아 단순 지표만 보면 전부 다운사이징 후보입니다.

하지만 메모리 평균이 20~30%이므로 앞서 설명한 안전 가드에 걸려 전부 "금지" 판정을 받습니다. 가드가 없었다면 17건 모두 잘못된 추천이 나갔을 항목입니다.

그 외 도구 스캔 결과

항목	값
인증서 점검	만료일·통신 여부 정상 출력
리소스 인벤토리	10,239건
의존성 관계(엣지)	11,953건
미사용 자원 후보	128건
미사용 자원 월 절감액	₩1,209,866 (연 1,452만원)

절감액 지표는 산정 로직 보완 후 수치가 변경될 수 있습니다. 모든 항목은 Azure CLI로 교차 검증했으며, 실제 정리 여부는 소유자 확인 후 사람이 판단합니다. 도구는 탐지하고 보고할 뿐 아무것도 바꾸지 않습니다.

보안을 위해 최소권한으로 구현

자동화 다섯 개를 붙이는 전 과정에서 쓰기 권한은 한 건도 요청하지 않았습니다.

다섯 도구가 같은 UMI를 재사용하도록 설계해, 도구가 추가될 때마다 권한을 신청하는 구조를 피했습니다.

Lesson

이번 작업의 결과물은 도구 5개가 아니라 도구를 계속 붙일 수 있는 틀이었습니다.

새 도구는 탐지 로직만 작성하면 기존 실행 환경·로그 저장소·대시보드에 그대로 편입됩니다.
알림 규칙은 코드가 아니라 Grafana에 있으므로, 조건 변경에 재배포가 필요 없습니다.
도구가 늘어도 운영 대상(Function App 1 / Log Analytics 1 / 대시보드 1)은 그대로입니다.

돌아보면 특별한 기술을 쓰지 않았습니다. 보안성 검토, RBAC 선정, Managed Identity, Functions, Log Analytics, Grafana, 공개 가격 API가 전부입니다.

비슷한 환경에서 개발하신다면, 다음 네 가지는 먼저 정하고 가시길 권합니다.

개발보다 파이프라인을 먼저 정하기. 첫 도구 개발이 조금 느려지지만, 두 번째 도구 부터 속도가 확연히 달라집니다.
알림을 앱에서 분리하기. 앱은 로그만 남기고 판단은 관측 플랫폼에 맡기면, 조건 변경에 배포가 필요 없습니다.
모니터링 지표를 "실행 여부"가 아니라 "성공 여부"로 잡기. 자동화는 조용히 실패합니다. 로그가 쌓인다고 해서 데이터가 최신이라는 뜻은 아닙니다.
안전 가드는 꼭 설정하기. 프로그램이 위험한 행동을 하지 못하게 제약사항을 먼저 걸고 개발하는것이 안전합니다.

긴 글 읽어주셔서 감사합니다.

클라우드 AI 플랫폼: 수 많은 운영 리스크를 하나의 파이프라인으로 - 자동화 아키텍쳐 구축기