프롬프트·모델·워크플로 로직을 하나의 AI 릴리스로 버전 관리하는 법

운영 AI의 릴리스 단위는 모델 엔드포인트나 프롬프트 한 줄이 아니라 실제 동작에 영향을 주는 전체 구성이다. 모델만 이전 버전으로 돌려도 새 프롬프트, 변경된 도구 스키마, 권한 규칙, 검색 설정이나 재시도 경로가 남아 있으면 서비스는 시험했던 상태로 돌아가지 않는다. 하나의 릴리스 ID 아래 해석이 끝난 구성과 평가 증거를 묶어야 무엇을 시험했고, 어떤 후보가 요청을 처리했으며, 어디로 복구할지를 빠르게 판단할 수 있다. 이 원칙은 생성형 도우미뿐 아니라 검색, 분류, 문서 처리와 도구 호출이 결합된 업무형 AI에도 적용할 수 있다.

AI 릴리스 하나에는 무엇을 포함해야 할까?

하나의 AI 릴리스에는 서비스의 동작, 권한, 위험, 비용, 지연 또는 관측성을 실질적으로 바꿀 수 있는 런타임 의존성을 포함해야 한다. NIST는 AI 수명주기 활동과 참여자의 상호의존성을 설명하고, 제3자 소프트웨어와 데이터를 포함한 구성요소 목록과 배포 전후의 문서화된 시험을 권고한다. Google Cloud도 운영 ML 시스템에 모델 코드뿐 아니라 구성, 자동화, 검증, 시험, 메타데이터 관리, 서비스 인프라와 모니터링이 포함된다고 설명한다. 따라서 모델 이름만 기록하는 방식은 실제 서비스 경계를 충분히 나타내지 못한다.

• 시스템·사용자 프롬프트와 템플릿 변수 처리 규칙
• 해석이 끝난 모델 식별자, 온도, 출력 한도와 그 밖의 유효 추론 매개변수
• 도구 스키마, 호출 권한, 승인 조건, 정책과 가드레일
• 검색·컨텍스트 설정, 데이터 참조, 라우팅과 기능 플래그
• 워크플로 코드, 재시도·핸드오프 로직, 입력·출력 스키마와 런타임 의존성
• 배포 판단에 쓰는 평가 데이터 세트, 채점기, 루브릭과 임계값의 버전

평가 데이터와 채점기는 보통 서비스 요청 경로에서 실행되지 않으므로 런타임 구성과 구분하되, 승격 판단을 바꾸는 보증 자산으로 같은 릴리스 기록에 연결한다. 외부 모델 제공업체나 제3자 라이브러리도 이름만 무조건 추가하지 말고 서비스 또는 판단에 실질적 영향을 줄 때 포함한다. 프롬프트, 모델 스냅샷, 유효 매개변수, 도구 계약, 권한, 정책, 검색 설정, 워크플로, 스키마, 의존성이나 환경 바인딩 가운데 하나라도 동작을 바꾸면 새 후보가 된다. 구성요소별 변경 이력은 유지하되 장애 때 이를 다시 조립하도록 맡겨서는 안 된다.

동작 스택을 릴리스 매니페스트로 어떻게 묶을까?

하나의 불변 매니페스트가 프롬프트, 모델과 매개변수, 도구, 권한, 정책, 검색 설정, 워크플로, 스키마, 런타임 의존성과 환경 바인딩의 실제 식별자를 묶어야 한다. MLflow 문서는 프롬프트 템플릿 버전은 불변이지만 별칭과 일부 연결된 모델 설정은 바뀔 수 있음을 보여준다. 또한 모델과 특정 프롬프트 버전 URL의 연계를 기록할 수 있다. OpenAI도 모델 스냅샷 사이에서 프롬프트 동작이 달라질 수 있으므로 버전을 고정하고 애플리케이션 평가를 수행하라고 권고한다. 따라서 production이나 latest 같은 별칭은 포인터일 뿐 릴리스 식별자가 아니다.

• 릴리스 ID, 생성 시각, 책임자, 대상 서비스, 상태와 이전 정상 릴리스
• 각 구성요소의 버전, 커밋, 아티팩트 다이제스트, 콘텐츠 해시 또는 서명된 참조
• 모델 매개변수와 도구 권한처럼 실제 요청에 적용되는 유효 설정
• 승인된 연결, 데이터·검색 참조, 기능 플래그, 라우팅 제약과 호환성 조건
• 평가 결과, 승인, 중지 조건, 롤백 책임자와 외부 작업 조치 절차의 링크

내부 지원 도우미의 후보 support-assistant-r18을 예로 들면, 프롬프트 p-42, 모델 스냅샷 m-2026-07과 매개변수, CRM 도구 스키마 t-9, 권한 정책 policy-12, 워크플로 커밋 wf-a71, 출력 스키마 reply-6과 의존성 잠금 파일을 묶는다. 릴리스 패킷에는 평가 모음 eval-23과 채점기 버전을 별도로 연결한다. 이전 support-assistant-r17은 새 선택형 마감일·에스컬레이션 필드와 호환되는지 확인한 뒤에만 롤백 대상으로 지정한다. 노출 비율과 배포 시각은 매니페스트를 수정하지 말고 연결된 승격 이벤트에 남긴다.

서비스 동작이나 그 동작을 승인하는 증거를 바꿀 수 있다면, 릴리스 기록 안에 해석이 끝난 식별자가 있어야 한다.

후보 승격은 어떤 증거로 결정해야 할까?

게이트는 승격할 바로 그 후보를 현재 릴리스와 비교해 계약, 업무 품질, 중요 구간, 안전, 권한, 도구 동작, 신뢰성, 지연과 비용을 함께 검토해야 한다. NIST는 문서화되고 반복 가능한 시험·평가·검증 방법과 개발 또는 배포의 진행 여부에 관한 명시적 판단을 제시한다. OpenAI의 평가 지침은 일반 모델 평가만으로 특정 업무의 모든 뉘앙스를 포착할 수 없으며, 실제 사례와 비용이 큰 경계 사례, 도메인 전문가 참여와 자동 채점기 감사를 권고한다. 한 개의 평균 점수로 중요한 실패를 덮어서는 안 된다.

릴리스 노트에는 행동상의 의도, 바뀐 의존성, 영향을 받는 업무와 인터페이스, 권한·관측성 변화, 비교 결과, 알려진 한계, 잔여 위험, 승격 책임자와 호환되는 복구 대상을 적는다. 평가 데이터 세트와 채점기, 루브릭, 임계값도 버전으로 남긴다. 게이트가 바뀌면 같은 후보를 두고도 결과 해석이 달라질 수 있기 때문이다. Google Cloud는 후보와 기준 모델, 중요 구간과 서비스 인터페이스의 비교를 권고한다. GitHub는 필수 검토자와 외부 검사를 강제하고 배포 시작자와 승인자를 분리할 수 있는 보호 기능을 문서화한다.

같은 후보를 운영 환경으로 어떻게 승격할까?

각 단계에서는 같은 해석 완료 후보를 승격하고, 동작·권한·맥락을 바꾸는 구성 수정이 생기면 새 릴리스 ID로 평가를 다시 연결해야 한다. 먼저 가능하다면 최근의 대표 요청을 그림자 또는 비실행 방식으로 재생하되 쓰기 도구와 그 밖의 중대한 부작용은 비활성화하거나 샌드박스에 격리한다. 이어 내부 사용자, 고정된 운영 코호트, 확대 노출, 전체 트래픽 순으로 진행한다. 각 단계의 코호트 규칙, 트래픽 할당, 관찰 시각, 비교 결과와 승격·보류·거부 결정을 배포 이벤트로 남긴다.

1. 쓰기 작업을 차단한 그림자 실행에서 현재 릴리스와 전체 추적을 비교한다.
2. 내부 운영팀에 후보를 노출하되 모든 외부 작업의 기존 승인 절차를 유지한다.
3. 고정 배정된 운영 코호트에서 업무, 안전, 도구, 신뢰성, 지연과 비용 신호를 비교한다.
4. 합의한 표본과 관찰 조건을 충족했을 때만 같은 후보의 노출을 확대한다.
5. 전체 트래픽으로 전환한 뒤에도 이전 정상 릴리스와 릴리스별 모니터링을 유지한다.

NIST는 배포 전 시험, 운영 중 모니터링과 실제 배포 조건에 가까운 환경에서의 동작 입증을 권고한다. OpenAI의 평가 지침도 외부 사용자 대상 릴리스에는 온라인 실험이 필요하다고 설명한다. Google Cloud는 스테이징, 스모크 시험, 소규모 실시간 카나리와 온라인 비교를 제시하지만 보편적인 트래픽 비율이나 관찰 기간은 정하지 않는다. 노출 규모, 필요한 표본과 시간은 서비스 위험, 요청량, 문제 감지 지연과 대응 역량에 맞춰 결정한다. 그림자 실행과 카나리는 실제 조건 전체나 희귀한 실패를 증명하지 못한다.

언제 중지하고 무엇을 롤백해야 할까?

안전·정책 위반, 승인되지 않은 도구 동작, 중요한 계약 실패나 심각한 신뢰성 장애가 확인되면 노출을 중지하고, 나머지 회귀에는 서비스별로 미리 합의한 판단 기준을 적용해야 한다. 모호한 신호는 즉시 롤백하기보다 노출을 멈추고 조사할 수 있지만 담당자와 결정 상태는 명시한다. NIST는 배포를 진행 또는 보류할 위험 판단으로 다루며 운영 중에도 위험을 계속 관리하도록 제시한다. 수치 기준과 관찰 기간은 서비스의 영향도와 감지 능력을 반영해야 하므로 다른 팀의 값을 그대로 가져오지 않는다.

• 노출 전에 하드 스톱, 조사형 보류 조건, 판단 책임자와 연락 경로를 확정한다.
• 이전 정상 번들의 스키마, 상태 변경, 공급자 가용성, 도구 계약, 라우팅과 마이그레이션 호환성을 검사한다.
• 복구 명령뿐 아니라 정상 트래픽, 권한, 추적과 주요 업무 결과가 돌아왔는지 검증한다.
• 영향받은 요청과 외부 작업 ID는 릴리스 태그가 붙은 추적에서 별도로 식별한다.
• 격리, 대사, 정정, 통지 또는 보상 조치는 승인된 별도 런북에 따라 수행한다.

롤백은 한 구성요소만 되돌리는 작업이 아니라 호환성이 확인된 정상 릴리스 전체로 이후 트래픽을 복구하는 작업이다. Google Cloud는 이전 서비스 버전을 빠르고 안전하게 복구할 수 있는지 미리 시험하고 이전 버전을 배포 메타데이터와 함께 추적하도록 권고한다. 그러나 구성 롤백은 이후 요청의 라우팅을 바꿀 뿐 이미 전송한 메시지, 데이터 쓰기, 승인이나 외부 시스템 작업을 되돌리지 않는다. 도구 호출과 작업 ID를 추적한 뒤 해당 시스템의 권한 있는 절차로 격리·대사·정정해야 하며, 민감하거나 규제된 업무는 조직의 적격 전문가에게 판단을 맡겨야 한다.

나중에 재구성 가능한 릴리스 기록은 무엇일까?

재구성 가능한 기록은 어떤 후보가 어떤 근거와 승인으로 어느 요청을 처리했는지 연결해 보여줘야 한다. Google Cloud는 구성요소와 파이프라인 버전, 실행 시각, 실행 주체, 매개변수, 산출물, 평가 결과와 이전 모델 포인터의 기록을 권고한다. OpenAI Agents SDK 추적은 워크플로 계층, 생성, 도구 호출, 핸드오프, 가드레일, 작업, 턴, 타임스탬프와 메타데이터를 수집하면서 민감한 모델·도구 입력과 출력은 제외할 수 있다. 애플리케이션 추적 ID와 제공업체 요청 ID도 함께 남기면 시스템 경계를 넘는 장애 분석에 도움이 된다.

• 불변 후보 매니페스트와 구성요소 식별자, 매개변수, 환경 바인딩
• 호환성 검사, 평가 자산 버전, 결과, 제한사항, 승인과 예외
• 코호트 규칙, 트래픽 할당, 배포·승격·중지·롤백 이벤트
• 릴리스 ID가 연결된 추적, 요청 식별자, 발견사항과 최종 결정
• 보존하지 않은 민감 페이로드의 범위와 적용된 정보 처리 정책

모든 프롬프트, 도구 입력, 모델 출력과 고객 페이로드를 무조건 보존할 필요는 없다. 식별자와 관리되는 증거를 남기되 민감정보의 수집·접근·보존은 조직 정책에 따른다. 이 기록이 제공하는 것은 구성과 의사결정의 재현성이지, 확률적 모델이나 호스팅 서비스의 출력을 바이트 단위로 똑같이 재생한다는 보장이 아니다. 시작점은 불변 후보, 버전이 지정된 평가 증거, 단계별 결정과 호환되는 복구 대상을 식별하는 가장 작은 릴리스 패킷이면 충분하다. 민감정보, 중대한 권한, 규제 업무나 외부 작업 조치가 바뀐다면 보안·개인정보·법무·기록·위험·업무 분야의 적격 담당자에게 별도 판단을 요청한다.