복잡계 실패론, AI 에이전트 운영의 기본 교과서

1998년 문서가 2026년 AI에 다시 읽히는 이유

Richard Cook의 How Complex Systems Fail은 1998년에 쓰인 짧은 문서지만, AI 에이전트 운영을 설명하는 데 놀라울 정도로 잘 맞는다. 핵심은 복잡한 시스템의 실패가 단일 원인에서 나오지 않는다는 것이다. 사고는 이미 약해진 방어선, 과도한 압력, 불완전한 관찰, 인간의 보정, 기술적 우연이 겹치며 발생한다. AI 제품에서도 마찬가지다. 모델이 틀렸다는 말만으로는 충분하지 않다.

AI 에이전트는 모델, 도구, 권한, 데이터, UI, 승인자, 배포 파이프라인, 비용 제한이 엮인 복잡계다. Google SRE Book은 신뢰성을 소프트웨어 엔지니어링 문제로 다룬다. NIST AI Risk Management Framework는 AI 위험을 측정과 거버넌스의 반복 루프로 본다. OpenAI Preparedness Framework와 Anthropic Responsible Scaling Policy도 고위험 역량을 단일 점수가 아니라 절차와 임계값으로 관리한다.

AI 사고는 대부분 여러 방어선의 작은 구멍에서 시작된다

에이전트가 잘못된 파일을 삭제했다면 원인은 "모델이 멍청해서"가 아닐 수 있다. 작업 디렉터리가 헷갈렸고, 도구 권한이 넓었고, 미리보기 단계가 없었고, 테스트가 느려 생략됐고, 사용자는 반복 승인에 지쳐 있었을 수 있다. 각각은 작은 문제지만 동시에 겹치면 사고가 된다. 복잡계 실패론은 이런 조합을 정상 운영의 그림자로 본다.

AI 안전 테스트, 이제 테스트 환경부터 위험하다는 평가 환경도 공격면이라고 봤다. GitHub Actions 장애, AI 개발망의 단일 실패점는 자동화된 개발망의 의존성이 장애를 키운다고 분석했다. Docker Sandboxes, 코딩 에이전트 격리를 제품으로 꺼내다는 격리가 제품 요구가 된다고 봤다. 모두 복잡계 관점에서는 같은 메시지다. 실패는 한 곳에서 터지지만 여러 곳에서 준비된다.

한국 기업의 AI 도입은 운영 설계가 먼저다

한국 시장에서는 AI 도입을 PoC 속도로 판단하는 경우가 많다. 한 달 안에 챗봇을 붙이고, 두 달 안에 사내 문서 검색을 만들고, 다음 분기에 영업 자동화를 붙이는 식이다. 빠른 실험 자체는 필요하다. 문제는 실험 단계의 느슨한 권한과 임시 연결이 운영으로 그대로 넘어갈 때 생긴다. 복잡계에서는 임시 우회가 시간이 지나면 정상 경로가 된다.

에이전트 운영에 필요한 최소 장치는 명확하다. 도구별 최소 권한, 세션별 로그, 실패 시 중단 버튼, 느슨하지 않은 비밀값 관리, 비용과 호출량 제한, 사람이 이해할 수 있는 변경 요약이 있어야 한다. 여기에 사후 회고 문화가 붙어야 한다. AI가 만든 사고를 개인 실수로만 처리하면 다음 사고의 조건은 그대로 남는다.

경쟁력은 실패하지 않는 것이 아니라 빨리 회복하는 것이다

AI 제품 경쟁에서 "절대 실수하지 않는다"는 약속은 믿기 어렵다. 더 현실적인 경쟁력은 사고가 작게 끝나고, 빨리 발견되며, 원인이 다음 설계에 반영되는 것이다. 엔터프라이즈 고객은 모델 벤치마크만 보지 않는다. 감사 로그, 롤백, 관리자 정책, 권한 분리, 데이터 보존 정책을 본다. 복잡계 관점은 이 요구를 제품 설계 언어로 바꿔준다.

국내 개발자에게도 시사점이 있다. 에이전트에게 작업을 맡길 때 "잘해줘"보다 "어디까지 해도 되는지, 실패하면 무엇을 남길지, 어떤 명령으로 검증할지"를 먼저 정해야 한다. 팀장은 AI 성과를 데모 수가 아니라 반복 가능한 운영 루프로 평가해야 한다. 복잡계는 실패를 완전히 제거할 수 없다고 말한다. 대신 실패가 재앙으로 커지지 않도록 방어선을 여러 겹으로 두라고 말한다.

자주 묻는 질문

Q1: 복잡계 실패론은 AI 기술 문서가 아닌데 왜 중요하죠?

A: AI 에이전트가 여러 도구와 사람, 조직 절차를 통과하기 때문이다. 이런 시스템은 전통적인 복잡계 안전 원칙의 영향을 받는다.

Q2: 모델을 더 좋은 것으로 바꾸면 해결되지 않나요?

A: 일부 오류는 줄어든다. 그러나 권한, 로그, 승인, 배포 압력이 그대로라면 다른 형태의 사고가 반복될 수 있다.

Q3: 작은 팀도 SRE식 운영이 필요한가요?

A: 필요한 만큼만 적용하면 된다. 최소 권한, 빠른 검증, 롤백, 로그 네 가지는 작은 팀에도 현실적인 출발점이다.

Q4: AI 안전 평가는 어디서 시작해야 하나요?

A: 모델 점수보다 실제 워크플로를 먼저 그려야 한다. 입력, 도구 호출, 권한, 출력 적용, 실패 시 중단 경로를 확인한다.

Q5: 사고 회고에서 가장 피해야 할 태도는 무엇인가요?

A: 한 사람이나 한 모델만 원인으로 지목하고 끝내는 태도다. 방어선이 왜 동시에 약해졌는지 봐야 개선이 남는다.