AI가 작성한 '예외'를 규칙으로 만들지 않은 경험

AI에게 운영 문서나 승인 문서를 작성하게 하면, 단순히 문서의 내용뿐만 아니라 경계를 어떻게 읽을지에 대한 해석까지 AI가 쓰게 된다. 그 해석이 검토 대상이 된 상황에서 시작한다.

어떤 검증을 실행하기 전에, AI 지원 세션이 승인 문서를 초안 작성했다. 거기에는 '이번 실행은 기존 제약의 대상에서 제외되어 처리될 수 있다'는 취지의 정리가 포함되어 있었다. 문구 자체는 일관성이 있고 읽으면 납득할 만하다. 하지만 이 정리를 영구적인 해석으로 채택하게 되면, 동종의 실행은 미래에도 제약을 거치지 않고 지나갈 수 있다는 독해를 허용하게 된다. 경계가 명시적인 변경 없이 느슨해진다.

인간 판단자인 필자는 그 정리를 영구적인 규칙으로는 채택하지 않았다. 대신, 해당 실행을 '일회성으로 명시적으로 승인되었으며 범위를 한정한 검증'으로 재규정했다. 일반 규칙은 변경하지 않았다. 게다가 이 예외를 다음 완화의 근거(선례)로 사용하려면 재검토가 필요하다는 조건을 기록에 남겼다. 어느 쪽의 처리 방식이든, 그 실행 자체는 이루어진다. 다른 점은 기록에 무엇이 남고, 그것이 다음에 어떤 근거가 되느냐이다.

이 글의 핵심은 AI의 제안이 거절되었다는 사실 그 자체가 아니다. 결과물뿐만 아니라 규칙의 해석 자체가 검토 대상이 된다는 점이다. 다시 읽어볼 때 던져야 할 질문은 간단하다. '이 독해를 영구화하면, 다음에 무엇을 허용하게 되는가?' 개별 실행은 무해해 보일지라도, 독해가 남으면 경계가 움직인다. 이는 새로운 원리 주장이라기보다는, 이 사례에서 얻은 교훈으로 작성한다.

1. 어떤 환경에 대한 이야기인가

이 기록은 혼자 운영하는 소규모 AI 지원 환경의 것이다. AI 코딩 에이전트를 사용하여 전체를 조정하는 세션과 개별 작업을 실행하는 세션에 역할을 분리하고 있다. 로컬에서는 정기/백그라운드 작업(job)이 움직이며, 공유 상태는 통제된 절차로만 변경한다.

이는 개인/소규모 환경에서의 운영 기록이며, 엔터프라이즈 규모의 분산 시스템 운영은 아니다. 제시할 수 있는 것은 판단 방법과 운영 규율의 실례일 뿐, 규모·처리량(throughput)·가용성의 실적이 아니다. 엔터프라이즈 환경으로의 일반화는 주장하지 않는다. 또한, 아래 사례들은 서로 독립적인 예시이며, 시간 순서대로 나열하지 않았다.

2. 경계 부족이 노출된 장면

같은 작업을 날짜를 바꿔 반복하는 작업을 한 번에 하나씩 개별 지시로 나누어 실행했더니, 중간의 1단계가 5시간 이상 아무도 감지하지 못한 채 멈춰 있었다. 개별 작업은 보통 수 초 미만으로 끝났기 때문에, 일반적인 처리 시간으로는 설명하기 어려웠다. 멈춘 기술적인 근본 원인은 아직도 밝혀지지 않았다. 노출된 것은 정지를 감지하는 메커니즘이 존재하지 않았다는 점(생존 모니터링의 결함)이었다.

그 후, 반복 작업 전체를 동일한 절차를 기계적으로 흘려보내는 단일 결정적 실행 단위(스크립트)로 옮기고, 기계적으로 판별할 수 있는 중단 조건을 그 주변에 추가했다. 기계적으로 판별 가능한 것은 현장에서 멈추고, 판단이 필요한 의미론적 검증은 실행 후에 미루는 방식으로 분담했다. 범용적인 모니터링 시스템을 만든 것이 아니다. 이후 같은 범위의 작업은 한 번, 끝까지 완료했다. 하지만 이것은 n=1의 사실일 뿐이며, 원인을 해결한 증명도, 같은 정지가 일어나지 않을 것의 증명도 아니다. 정지를 감지하는 메커니즘의 결함 자체를 이 변경으로 일반적으로 해소한 것은 아니다. 이는 '정지 조건이 기능한 예'가 아니라, '기능하는 모니터링이 부족했음이 노출된 예'로 다루어야 한다.

다른 장면에서는 간이 자동 실행 수단만으로는 미검증 코드의 실행을 요구하는 작업을 완수하지 못하고 실패를 반복했다. 추가한 것은 새로운 실행 메커니즘이 아니라, 기존 수단의 주변 절차였다. 작업 내용을 사전에 문서화한 지시서를 전달하고, 실행 후에는 작업자의 자기 보고만으로 완료로 삼지 않고 독립적으로 확인하게 했다. '자기 보고만으로는 완료 판정하지 않는다'는 원칙은 이 경험에서 비롯되었다. 이 실패의 원인 역시 밝혀냈다고 주장하지 않는다.

3. 정지 조건이 실제로 기능한 장면

무인 실행되는 자동화 작업을 한 번만 수동으로 확인할 필요가 생겼다. AI 지원 계획에는 운영상의 전제 오류가 포함되어 있었다. 실행하자, 승인되지 않은 상태 변경이 필요한 지점에 도달했다. 사전에 정의된 정지 조건이 그곳에서 적용되었고, 워크플로우는 회피책을 조용히 취하지 않고 멈췄다. 상황과 선택지가 인간에게 제시되었고, 어떤 것을 택할지에 대한 판단은 인간에게 맡겨졌다. 승인을 받은 후에 작업이 재개되었고, 복구는 승인된 범위 내에 머물렀다. 정지 조건이 의미를 갖는 것은 '예상치 못한 일이 생기면 스스로 판단해서 계속하는 것'이 아니라, '승인된 범위를 벗어날 필요가 생긴 시점에서 멈추는 것'이라는 것이 사전에 결정되었기 때문이다.

같은 AI 지원 워크플로우 내에서, 계획상의 전제에는 오류가 있었지만, 실행 경계(execution boundary)가 그 오류를 봉쇄했다. 계획의 오류를 '제로'로 만드는 것과, 오류가 발생해도 영향이 승인 범위를 초과하지 않도록 하는 것은 별개이며, 여기서 기능한 것은 후자였다. 다만, 이는 1회 적용 사례에 불과하다. 중단되지 않았을 경우 어떤 일이 벌어졌는지도 알 수 없다.

4. 제약을 한 단계 완화했던 상황

병렬 실행(parallel execution)의 제약은 가장 보수적인 값(병렬 실행을 허용하지 않음)에서 시작했다. 완화하기 전에, 충족해야 할 여러 조건들이 사전에 정의되어 있었다. 실제 측정(실측)으로 그 모든 것을 확인한 후에야, 완화를 한 단계 진행했다. 한 단계에 국한된 이유는, 다음 단계에서는 다시 조건과 실측을 요구하기 위해서다. 판단 기록에는 확신도, 검토한 대안, 이 완화를 무효화할 조건, 그리고 다음 재검토 기일을 남겼다. 초반의 상황은 이 판단 과정 중에 발생했다.

그리하여 설정했던 선례 방지(precedent prevention) 조건은 다음과 같다. 예외적인 완화가 다음 완화의 전례로 사용되는 경우, 자동으로 확장하지 않고 재검토한다. 이는 1회 한정된 예외가 인지되지 않은 채 방침이 되는 것을 막기 위한 설계 조건이다. 이 조건이 실제로 발동한 사례는 없다. 설계로 작성되어 있었다는 사실만을 언급한다. 여기서 말하는 '한 단계의 완화'는 여러 동시 실행을 허용하는 것이 아니라, 우선 단일 작업 실행을 허용하는 수준까지였다. 더 큰 완화에도 적용될 수 있는지는 미실증이다.

5. 인간과 AI의 역할

인간(필자)이 담당한 것은 방향 설정, 승인 경계 설정, 그리고 한정적인 완화에 대한 최종 판단이었다. 최소한 한 건은 AI가 제시한 경계를 완화하는 해석을 채택하지 않았다. AI 지원 세션이 맡은 것은 문서나 계획의 초안 작성, 제한된 범위 작업 실행, 증거 수집, 검증 및 검토였다. 3절에서 언급했듯이, 계획상의 오류는 AI 측에 있었다.

이는 'AI가 위험하니 인간이 옳다'라는 이야기가 아니다. AI는 해석을 포함하는 문서를 작성한다. 따라서 최종적인 권한은 인간에게 남겨두고, 해석을 재검토하는 절차를 운영에 통합했다는 의미이다.

6. 아직 증명되지 않은 것들

• 5시간 초과 정지 및 실행 수단 실패의 기술적 근본 원인은 여전히 불분명하다.
• 각 사례는 n=1이다. 중단 조건 적용은 1회, 완화는 1단계, runner 이관 후 완료는 1회다.
• 선례 방지 조건은 설계로만 존재했을 뿐, 발동한 사례가 없다.
• 개별 설계의 상세 작성자가 인간인지 AI 지원 세션인지는 현존하는 기록으로는 분리할 수 없다. '인간이 모두 설계했다'거나 'AI가 자율적으로 최종 판단했다'고 주장하지 않는다.

7. 이 사례에서 남긴 6가지 운영 규칙

single writer, 승인 게이트(approval gate), 보수적인 기본값(conservative default value) 각각은 새로운 발명이 아니다. 가치가 있다면, 제약을 어떻게 선택했는지, 무엇이 실패로 인해 결함을 드러냈는지, 언제 실측이 완화를 정당화했는지, 어디서 인간이 AI의 해석을 재검토했는지라는 구성 방식에 있다.

• 최초 권한은 작게 한다. 새로운 권한은 가장 제한적인 값부터 시작한다. 의사결정 속도가 중요한 환경에서는 마찰이 될 수 있다. -
• 공유 상태 변경 주체를 한정한다. 작성자를 하나로 좁힌다. 높은 처리량(throughput)이 필요한 환경에서는, 단일 변경 주체가 제약이 될 수 있다. -
• 반복 처리는 가능하다면 결정적인 runner에 맡긴다. 기계적으로 판별 가능한 중단 조건을 주변에 배치한다. 확인한 것은 1사례뿐이다. -
• worker의 자체 보고를 유일한 완료 증거로 삼지 않는다. 독립적으로 사후 검증한다. 검증 수고는 늘어나며, 모든 작업에 같은 깊이로 적용할 수는 없다. -
• 완화는 한 단계씩, 실측 후에 진행한다. 사전 조건・실측・무효화 조건을 세트로 기록한다. 다단계 동시 완화로의 일반화는 미실증이다. -
• 예외를 다음 예외의 전례로 삼지 않는다. 예외는 범위를 제한한 승인으로 취급하고, 전례로 사용하려면 재검토한다. 예외가 드문 환경에서는 절차 자체가 너무 무거울 수도 있다.

어떤 규칙에도 해당하지 않는 상황이 존재한다. 그럼에도 불구하고, AI가 작성한 문서를 읽을 때의 질문은 변하지 않는다. 이 해석을 영구 규칙으로 삼는다면, 다음에 무엇을 허용하게 될까. 예외를 인정할 때야말로 그 질문에 되돌아가야 한다.

논의 (Discussion)