AI 자동화 dry-run, 어디까지 확인하고 무엇을 남겨둘까

AI가 만든 변경안을 실행하기 전에 미리보기를 돌렸고 오류가 없었다. 이제 실제 업무도 성공한다고 봐도 될까? 미리보기는 그 기능이 검사한 범위에서 변경안을 확인한 결과다. 실제 저장, 후속 서비스 동작, 고객에게 보이는 결과까지 성공했다는 뜻은 아니다. 먼저 무엇을 실행하지 않았고 무엇을 실제 시스템에 물었는지 확인해야 한다.

이 글은 AI가 작성한 업무 변경안을 검토하는 담당자를 위한 글이다. Kubernetes와 Terraform의 공식 문서를 비교해 dry-run이라는 이름만으로 판단할 수 없는 이유를 설명한다. 두 제품을 직접 실행한 시험 보고서는 아니며, 뒤의 업무 사례와 점검표는 작성자의 적용 제안이다.

변경 문장 출력과 서버의 사전 검사는 다르다

화면에 “담당자 변경 예정”이라고 표시하는 기능은 변경 문구만 만들었을 수 있다. 로컬에서 자료형을 검사하는 기능, 현재 서버에 요청을 보내 검증받는 기능, 현재 자원과 설정을 비교해 변경 목록을 만드는 기능은 확인하는 대상이 다르다. 따라서 dry-run 버튼의 존재보다 요청 경로와 문서상 보장 범위를 읽어야 한다.

Kubernetes API의 dry-run 문서는 dryRun=All 요청이 admission 처리·검증·병합 충돌 검사 등의 단계를 거치되 저장하지 않는다고 설명한다. API가 설명하는 보장은 해당 dry-run 요청의 저장과 부작용을 막는 것이다. 이는 이름만 같은 다른 도구의 미리보기에도 자동 적용되는 보장이 아니다.

이 경로는 쓰기 권한 없이 운영 요청을 시험하는 우회로도 아니다. 같은 문서에 따르면 dry-run과 실제 요청의 인가 조건은 같다. 부작용을 일으키는 admission 처리를 안전하게 건너뛸 수 없는 경우 요청이 거절될 수 있다. 외부 webhook도 dry-run에 맞는 선언과 동작을 갖춰야 한다. 반환 객체의 일부 생성값은 실제 실행 때 달라질 수 있다.

계획에 표시된 변경과 실제 변경 결과를 나눈다

Terraform의 plan 문서는 기본적으로 원격 객체의 상태를 읽고 설정과 비교해 변경 동작을 제안한다고 설명한다. plan 자체는 제안한 변경을 적용하지 않는다. 다만 원격 상태를 읽을 수 있으므로 “미리보기니까 네트워크 접속도 없다”는 판단은 맞지 않는다.

문서에는 상태를 새로 읽지 않는 -refresh=false가 외부 변경을 놓쳐 불완전하거나 잘못된 계획을 만들 수 있다는 주의도 있다. 검토용 계획 뒤에 대상 시스템이 바뀌면 예상 효과가 달라질 수 있으므로, 적용할 최종 계획이 의도와 맞는지 다시 확인하도록 안내한다.

두 예에서 얻을 운영 판단은 간단하다. 미리보기 결과 옆에 검사한 대상·시점·설정과 실제로 수행하지 않은 단계를 함께 남긴다. “오류 없음”이라는 한 줄만 보관하면 나중에 실제 실행과 어떤 부분을 비교해야 하는지 알기 어렵다.

가상 사례: 담당자 변경 검사는 통과했지만 알림은 아직 모른다

다음은 실제 제품 기능이나 운영 사고가 아닌 설명용 가상 상황이다. AI가 업무 카드의 담당자를 지수에서 민호로 바꾸는 요청을 준비했다. 가상의 사전 검사 API는 카드 ID, 담당자 ID와 변경 권한을 확인하지만 저장과 알림 전송은 하지 않는다고 가정한다.

검사가 통과했다면 그 시점에 그 API가 확인한 조건이 맞았다고 말할 수 있다. 민호에게 실제 알림이 전달됐거나, 이후 연결된 일정 시스템도 갱신됐다고 말할 수는 없다. 실제 실행 전 다른 사람이 카드를 종료할 수도 있다. 담당자 변경 자체가 저장돼도 알림 단계가 별도로 실패할 수 있다.

확인 단계	가상 사례에서 얻는 근거	아직 남은 확인
변경안 표시	카드와 담당자를 어떤 값으로 바꿀지 읽을 수 있음	대상 식별이 맞는지, 서버가 값을 허용하는지
서버 사전 검사	해당 시점의 ID·권한·상태 규칙을 통과함	실제 실행 때도 같은 상태인지, 저장이 됐는지
실제 저장	반환된 카드 ID로 저장 결과를 조회할 수 있음	변경 필드와 보존할 필드가 의도대로인지
후속 업무	알림·일정 갱신의 개별 결과를 확인함	수신·소비까지 필요한 업무라면 그 확인

이 표는 네 단계를 모든 제품이 제공한다는 뜻이 아니다. 사용하는 도구가 서버 검사를 제공하지 않는다면 그 부분은 미검증으로 남긴다. AI에게 검사 결과처럼 보이는 설명을 쓰게 해 빈칸을 채우지 않는다.

검사 통과를 실행 승인으로 바꾸지 않는다

사전 검사가 성공해도 바꾸려는 내용 자체가 사용자의 의도와 다를 수 있다. 작성자가 제안하는 확인 순서는 대상 ID와 변경 필드를 먼저 읽고, 검사에 사용한 상태와 설정을 확인한 뒤, 허용된 변경만 실제 실행에 넘기는 것이다. 변경안이 달라지면 기존 검사 결과를 새 요청의 결과로 재사용하지 않는다.

예를 들어 “담당자만 변경”하려던 요청에 완료 상태 해제까지 추가됐다면, 같은 카드라는 이유로 통과 결과를 그대로 붙일 수 없다. 반대로 단순한 미리보기 문구 수정이 실제 변경 내용에 영향을 주지 않았다면 무엇이 같고 달라졌는지 대조하면 된다. 필요한 것은 무조건 검사를 반복하는 절차가 아니라 검사한 변경과 실행할 변경을 맞추는 일이다.

실행 뒤에는 응답만 보지 말고 대상 ID를 통해 실제 값을 확인한다. 관측하지 않은 후속 효과는 미확인으로 남긴다. 저장은 됐으나 알림을 확인하지 못했다면 “담당자 저장 확인, 알림 미확인”처럼 범위를 적어야 다음 행동도 정확해진다.

자주 묻는 질문

dry-run은 언제나 부작용이 없나요?

도구의 계약과 실제 경로를 확인해야 한다. Kubernetes API의 문서상 보장을 다른 제품이나 자체 스크립트에 옮길 수 없다. 특히 미리보기 전에 실행하는 준비 코드가 별도 쓰기나 전송을 하는지도 확인할 대상이다.

미리보기에서 변경 없음이 나오면 원하는 상태라는 뜻인가요?

비교한 범위에서 차이를 찾지 못했다는 뜻부터 확인한다. 잘못된 계정이나 오래된 상태를 비교했다면 독자가 의도한 대상의 상태를 확인한 것이 아니다. 대상과 관측 시점, 제외한 자원을 함께 읽는다.

실행 직전에 다시 읽으면 동시 변경도 막을 수 있나요?

다시 읽기와 쓰기 사이에도 다른 변경이 들어갈 수 있다. 읽은 상태에서만 갱신하도록 서버가 조건을 검사하는 방식은 오래된 승인과 If-Match 조건부 갱신에서 이어서 설명한다.

입력 자체가 잘못된 경우는 AI JSON의 형식·근거·권한 검증부터 확인할 수 있다. 실제 실행의 일부 단계만 끝났다면 부분 성공 뒤 재개와 보상을 나누는 방법으로 넘어가 완료된 결과를 보존한다.