인프라 자동화의 취약성 문제

Source: Dev.to

Infrastructure automation은 우리의 시스템을 신뢰할 수 있고, 예측 가능하며, 스스로 복구하도록 만들기로 했습니다.
하지만 많은 팀에게는 다음과 같은 문제가 되었습니다:

• 취약함
• 디버깅이 어려움
• 변경이 위험함
• AI가 안전하게 추론하기 거의 불가능함

우리는 그 어느 때보다 자동화를 많이 진행했지만… 자동화 실수로 인한 장애는 계속 증가하고 있습니다. 이것이 취약성 문제입니다.

“취약한” 자동화란 무엇을 의미하는가?

취약한 시스템은:

• 예상 조건에서는 완벽하게 동작한다
• 조금이라도 예상치 못한 상황에서는 치명적으로 실패한다
• 왜 실패했는지에 대한 신호를 거의 제공하지 않는다

대부분의 현대 자동화는 문자열 기반 쉘 위에 구축됩니다:

systemctl status nginx | grep active

출력 형식, 로케일, systemctl의 정확한 문구, grep의 동작, 종료 코드 처리, 쉘의 상태 등에 의존합니다. 이 중 하나라도 바뀌면 자동화는 조용히 오작동합니다. 경쟁 상태, 부분 실패, 오래된 파일, 혼합된 init 시스템, 권한 변동, 클라우드 엣지 케이스 등을 추가하면 재앙이 됩니다.

전통적인 쉘이 문제의 근원인 이유

클래식 쉘(Bash, Zsh, Fish 등)은 다음을 위해 설계되었습니다:

• 인간
• 대화형 워크플로
• 작은 스크립트

하지만 다음을 위해 설계되지 않았습니다:

• 자율 에이전트
• 결정론적 자동화
• 타입이 지정된 시스템 제어
• 기계 추론
• 장기 오케스트레이션 로직

이들은 문자열, 종료 코드, 환경 변수, 암묵적 상태에 의존하므로 검증, 시뮬레이션, 감사, 수학적 추론이 어렵습니다—특히 대규모 AI에 대해서는 더욱 그렇습니다.

숨겨진 비용: 왜 AI + 쉘 자동화가 오늘날 위험한가

전형적인 “AI DevOps” 에이전트는 다음과 같이 동작합니다:

LLM → generate shell command → execute → parse output → guess what happened

이는 위험합니다 because:

• AI는 출력 구조에 대한 보장이 없다
• 오류 조건이 일관되지 않는다
• 부분 성공을 성공으로 오인한다
• 롤백 로직이 취약하다
• 보안 경계가 불분명하다

우리는 텍스트 파서를 통해 자율 시스템에 루트 접근 권한을 부여하고 있습니다—자동화라기보다 도박에 가깝습니다.

실제 아키텍처 문제

우리는 중요한 시스템 리소스를 텍스트 대신 타입이 지정된 객체로 다루지 않습니다. 파일, 서비스, 프로세스, 네트워크 인터페이스, 로그, 시크릿, 컨테이너, 클라우드 리소스는 다음을 통해 노출됩니다:

• 분리된 도구
• 인간이 포맷한 출력
• 일관되지 않은 의미 체계
• 일회성 명령 규칙

운영 체제에 대한 보편적이고 타입이 지정된 기계가 읽을 수 있는 제어 레이어가 없기 때문에, 모든 자동화 스택이 처음부터 다시 만들어집니다—그 품질은 형편없습니다.

비취약 모델은 어떻게 보이는가

안정적인 자동화 기반은 다음이 필요합니다:

• 타입이 지정된 리소스 (문자열이 아님)
• 통합 주소 지정
• 구조화된 JSON 출력
• 결정론적 동사
• 크로스 플랫폼 의미 체계
• 감사 친화적 동작
• AI 안전 제어 인터페이스

취약한 파이프라인 대신:

ps aux | grep nginx | awk '{print $2}'

다음과 같은 것이 필요합니다:

proc://nginx.status

임시 명령 체인 대신:

curl ... | jq ... | sed ... | grep ...

다음과 같은 선언적 API 호출이 필요합니다:

http://api.example.com/items.json(method="GET")

모든 결과는 구조화, 타입 지정, 예측 가능, 기계 검증 가능해야 합니다.

리소스 지향 쉘 개념

새로운 도구군이 등장하고 있습니다: 리소스 지향 쉘. OS를 “텍스트 명령 스트림”으로 보지 않고 “타입이 지정된 주소 가능한 리소스와 동사들의 그래프”로 봅니다.

예시 리소스 핸들:

• file://
• proc://
• svc://
• http://
• net://
• mq://
• secret://
• snapshot://
• config://

각 리소스는 명시적인 동사, 정의된 입력, 구조화된 출력, 예측 가능한 오류를 제공하여 자동화를:

• 보다 안전함
• 테스트 가능함
• 관측 가능함
• 재현 가능함
• AI 제어 가능함

취약성 vs. 회복성

이것이 장기적으로 중요한 이유

우리는 빠르게 다음을 향해 나아가고 있습니다:

• 자율 복구
• 스스로 복구되는 인프라
• AI 운영 플랫폼
• 무접촉 운영
• 에이전트 기반 클라우드 관리

이 모든 것은 불변성, 결정론, 기계 검증 가능한 동작을 요구합니다. 텍스트 기반 쉘 자동화는 안전하게 확장될 수 없습니다.

최종 생각

인프라 자동화의 취약성 문제는 도구 문제가 아니라 아키텍처 문제입니다. 우리는 자동화를 다음 위에 구축했습니다:

• 타입 대신 문자열
• 계약 대신 부수 효과
• 검증 대신 기대

리소스 지향 쉘은 그 실수를 근본적으로 바로잡는 방법입니다. AI가 일류 연산자가 되면서, 이 교정은 협상 불가능해집니다.