자율컴퓨팅: MAPE-K 폐루프로 사람보다 먼저 반응하는 인프라

시스템 하나에 붙은 메트릭·로그·트레이스가 사람이 확인할 수 있는 속도를 이미 넘어선 지 오래다. 클라우드·컨테이너·데이터 플랫폼의 복잡도가 늘어날수록 사람이 알람을 보고 대응하는 방식은 한계에 부딪힌다. 자율컴퓨팅(Autonomous Computing)은 목표 상태와 정책을 기반으로 시스템이 스스로 감지·분석·계획·실행하는 폐루프 자동화 체계를 가리킨다. IBM의 Autonomic Computing 개념을 계승하면서 AIOps·GitOps·SRE 관행과 결합해 실무형 자가 운영 시스템으로 자리잡고 있다.

Autonomic과 Autonomous는 강조점이 다르다. Autonomic은 자기 구성·자기 치유·자기 최적화·자기 보호(self-*) 원칙을 강조하고, Autonomous는 운영 의사결정 자동화의 범위를 넓혀 실제 실행 자율성 수준을 높이는 쪽에 무게를 둔다. 자율성은 L0 수동, L1 권고, L2 반자동, L3 조건부 무인 실행, L4 완전 자율로 나뉘며, 안전장치와 거버넌스 강도에 따라 단계적으로 상향한다.

MAPE-K: 감지에서 실행까지 도는 폐루프

핵심 메커니즘은 목표 상태·정책 기반 제어다. 선언형 목표(SLO, 보안 정책, 비용 상한)와 제약(승인, 변경 창구)을 정의하면 정책 엔진이 이를 근거로 의사결정을 내린다. 관측→이상 감지/근본 원인 분석→행동 계획→오케스트레이션 실행→결과 학습으로 이어지는 순환 구조가 MAPE-K(Monitor-Analyze-Plan-Execute-Knowledge) 폐루프다.

⤢✕

관측성 파이프라인은 메트릭·로그·트레이스·이벤트를 표준 스키마로 정리하고 지연·유실을 견디도록 설계해야 한다. 데이터 품질과 적시성이 의사결정 정확도의 전제이며, 이상 탐지와 상관분석을 위한 피처 엔지니어링을 SLO 지표(가용성, 지연, 오류율)와 에러 버짓 모델에 연결한다.

정책 엔진과 실행기

정책/목표 상태 엔진은 Policy-as-Code(OPA/Rego, CEL)를 적용해 위반 시 자동 시정조치나 차단을 수행한다. 선언형 목표와 금지 규칙을 동시에 운용하고, 우선순위·충돌 해소 규칙, 변경 승인 지연·창구, 최대 변경률 같은 듀티 세이프티를 내장한다.

실행기·오케스트레이터는 Kubernetes 컨트롤러, 워크플로우 엔진(Argo, Airflow), 구성 관리(Ansible), 서버리스 함수(Lambda, Cloud Functions)를 조합한다. 트랜잭션성을 확보하기 위해 멱등 작업, 단계적 커밋, 롤백/재시도, 자원 락(Kubernetes resourceVersion 기반 낙관적 락 등)을 적용한다. 멱등성은 재시도 안전을 위해 자원 상태 확인→변경 적용→확증 단계로 설계하고, 동시성은 리소스 단위 락이나 낙관적 락으로 경합을 방지하며, 카나리·배치 같은 점진적 변경과 실패 시 자동 롤백·쿼런틴·알림 절차로 안정성을 확보한다.

지식 저장소와 안전장치

지식 저장소는 사건→조치→결과의 구조화된 러닝 루프를 축적해 휴먼 런북을 기계 실행형 플레이북으로 전환한다. 모델·정책 버전을 관리하고 오프라인 시뮬레이션·카나리 검증으로 배포 리스크를 줄인다.

보안·거버넌스 안전장치는 최소 권한, 승인 워크플로우, 변경 이력의 불변 저장소(감사), 정책 드리프트 탐지를 기본으로 갖춘다. 오탐·오조치에 대비한 페일세이프 경로(격리, 즉시 롤백)와 수동 개입 우선권도 반드시 남겨둬야 한다.

여러 영역에서 실제로 쓰는 방법

SRE·클라우드 운영에서는 노드·파드 헬스체크 실패 시 자동으로 재스케줄하거나 노드를 교체하고, SLO 위반이 예측되면 선제적으로 스케일링한다. 에러 버짓이 떨어지면 배포를 자동으로 스로틀하고, 고소음 경보는 자동으로 집계·중복 제거한다.

데이터베이스·데이터 플랫폼에서는 지표 기반으로 자동 인덱싱·Vacuum 튜닝을 하고, 핫파티션이 감지되면 샤딩·리밸런싱을 실행한다. 장애 시 자동 페일오버·리플레이를 수행하고 CDC 지연이 늘면 버퍼·스루풋을 조정한다.

시큐리티 운영에서는 EDR 경보 신뢰도가 임계값을 넘으면 엔드포인트를 격리하고 자격증명을 자동으로 회전한다. IaC 변조가 탐지되면 파이프라인을 차단하고 정책 위반 리소스의 드리프트를 자동으로 수정한다.

FinOps(비용 최적화)에서는 비업무 시간에 스케줄을 다운·오프하고, 예측 기반 권고를 자동 Rightsizing으로 전환한다. 스팟 중단이 예고되면 온디맨드로 자동 롤오버하고, 태그 기반으로 예산 초과를 차단한다.

엣지·제조·통신에서는 진동·온도 이상 패턴이 감지되면 선제적 유지보수·부품 교체를 지시하고, RAN·네트워크 슬라이스 자원을 자동으로 재배치해 SLA 위반을 예방한다.

도입은 권고 모드에서 시작한다

서비스별 SLO·리스크 프로파일을 평가하고 자동화 적합도 매트릭스를 작성하는 것이 첫 단계다. 표준 관측성 스택(메트릭/로그/트레이스)을 구축하고 골든 시그널·SLI를 확정한 뒤, Policy-as-Code를 정립하고 승인·변경 창구·한도를 정해 시뮬레이션으로 검증한다. 수동 런북을 기계 실행형 플레이북으로 전환하며 멱등·롤백을 구현하고, 섀도우·권고 모드에서 시간·범위 제한 자동 실행을 거쳐 전면 적용까지 순차적으로 확대한다. 카나리와 오토 리미터, 사건 사후분석으로 검증·학습하며 지식 저장소를 계속 업데이트한다.

실무 예제: AWS EC2 자동 복구 Lambda

환경은 Python 3.11, boto3 1.34+이고, 트리거는 CloudWatch Events의 "EC2 Instance State-change Notification" 또는 상태 점검 실패 알람이다. 필요한 권한은 ec2:Describe*, ec2:RebootInstances, autoscaling:TerminateInstanceInAutoScalingGroup, ec2:CreateTags이며, 정책은 10분 내 1회 재부팅, 재시도 실패 시 ASG에서 교체하는 것으로 잡는다.

# file: lambda_function.py
import os
import json
import boto3

ec2 = boto3.client("ec2")
asg = boto3.client("autoscaling")

MAX_ATTEMPTS = int(os.getenv("MAX_ATTEMPTS", "1"))

def get_attempts(instance_id):
    resp = ec2.describe_tags(
        Filters=[{"Name": "resource-id", "Values": [instance_id]},
                 {"Name": "key", "Values": ["autoheal-attempts"]}]
    )
    if not resp.get("Tags"):
        return 0
    return int(resp["Tags"][0]["Value"])

def set_attempts(instance_id, n):
    ec2.create_tags(Resources=[instance_id],
                    Tags=[{"Key": "autoheal-attempts", "Value": str(n)}])

def handler(event, context):
    detail = event.get("detail", {})
    instance_id = detail.get("instance-id")
    state = detail.get("state") or detail.get("status") or ""
    if not instance_id:
        return {"status": "ignored"}

    attempts = get_attempts(instance_id)

    try:
        if attempts < MAX_ATTEMPTS and state in ("impaired", "stopped", "stopping"):
            ec2.reboot_instances(InstanceIds=[instance_id])
            set_attempts(instance_id, attempts + 1)
            return {"status": "rebooted", "instance": instance_id}
        # 교체 경로
        # ASG에 속한 인스턴스만 교체 수행
        asg_groups = asg.describe_auto_scaling_instances(InstanceIds=[instance_id]).get("AutoScalingInstances", [])
        if asg_groups:
            asg.terminate_instance_in_auto_scaling_group(
                InstanceId=instance_id, ShouldDecrementDesiredCapacity=False
            )
            set_attempts(instance_id, attempts + 1)
            return {"status": "replaced", "instance": instance_id}
        return {"status": "no-asg", "instance": instance_id}
    except Exception as e:
        # 페일세이프: 태그로 격리 표시, 추가 알림은 EventBridge/SES 연계
        ec2.create_tags(Resources=[instance_id], Tags=[{"Key": "autoheal-error", "Value": str(e)[:200]}])
        raise

CloudWatch 이벤트가 들어오면 재부팅할지 교체할지를 결정해 EC2·ASG API를 호출하는 흐름이다. 멱등 태그로 재시도 안전을 확보하고, 실패하면 격리 태그를 붙이고 알림을 보내며 재시도는 백오프를 적용하는 편이 좋다. no-autoheal=true 같은 서비스 태그로 예외를 처리하고, 변경 창구 시간 필터링을 추가하는 것도 권장되는 가드레일이다.

자동화가 아니라 반응 속도의 문제다

실제 도입 사례를 보면 MTTR이 30~~70% 줄고 인시던트 재발률이 20~~40% 감소하며, SLO 준수율은 5~~15%p 오르고 변경 실패율은 20~~50% 준다. 인프라 비용은 권고→자동 Rightsizing·스케줄링으로 10~~30% 절감되고, 경보 피로도는 중복 제거와 우선순위 재배치로 40~~80% 줄어든다. 예를 들어 월 EC2 비용이 200,000 USD인 환경에서 Rightsizing·스케줄링으로 15%를 절감하면 월 30,000 USD, 연 360,000 USD를 아끼는 셈이고, 여기에 경보 처리 자동화로 인력 1 FTE를 재배치하면 기회비용 절감까지 추가로 기대할 수 있다.

자율컴퓨팅은 목표 상태·정책 기반 폐루프 자동화로 운영 복잡도와 리스크를 구조적으로 줄이는 전략이다. 관측성 강화, Policy-as-Code, 멱등·롤백·락을 갖춘 실행기, 지식 루프 축적이 핵심 성공 요인이며, 권고 모드에서 제한적 자동 실행을 거쳐 가드레일 아래 전면 자동화로 넓혀가는 순서를 지키는 것이 안전한 도입의 전제다.