AI에게 문장의 단어 하나를 고르게 맡겼다면 결과 문장만 저장해서는 재현하기 어렵습니다. 어떤 모델에 어떤 입력과 설정을 보냈고, 당시 서버와 외부 자료가 무엇이었는지 함께 남겨야 같은 판단을 다시 검증할 수 있습니다.
언어모델 단어 선택 재현의 단위부터 정하기
언어모델은 문장을 한 번에 고르는 것이 아니라 토큰(token, 모델이 처리하는 텍스트 단위)을 순서대로 생성합니다. 앞에서 선택된 토큰이 뒤의 후보에 영향을 주므로, 한 단어가 달라지면 이후 문장 전체가 달라질 수 있습니다.
따라서 재현의 대상은 “결과 문장”이 아니라 “하나의 실행”입니다. 실행에는 입력, 지시의 우선순위, 모델 버전, 생성 방식, 외부 맥락, 응답 상태가 묶여 있어야 합니다.
모델 스냅샷(model snapshot)은 특정 시점의 모델 버전을 뜻합니다. 같은 서비스 이름을 계속 사용해도 내부 스냅샷이나 서버 구성이 바뀌면 단어 선택의 확률 분포가 달라질 수 있으므로, 별칭보다 고정 버전 식별자를 우선 기록해야 합니다.
OpenAI는 스냅샷 사이에서 프롬프트 작동 방식이 바뀔 수 있다고 설명하며, 일관성을 위해 고정 모델 버전과 평가를 권장합니다. 이 원칙은 특정 회사에만 한정된 사용법이 아니라, 버전이 공개되는 모든 언어모델을 다룰 때 적용할 수 있는 운영 기준입니다.
재현성은 두 수준으로 나누어 판단하는 것이 좋습니다. 같은 단어와 같은 문장이 다시 나오는지 보는 엄격한 재현과, 같은 기준에 따라 후보를 고르는지 확인하는 기능적 재현은 서로 다른 목표입니다.
언어모델 요청에 함께 남길 입력과 생성 설정
가장 먼저 원문 요청을 보존해야 합니다. 사용자가 입력한 문장뿐 아니라 시스템 지시, 개발자 지시, 예시 대화, 앞선 assistant 응답, 변수에 삽입된 값까지 실제 전송 순서 그대로 저장해야 합니다.
메시지 역할은 내용만큼 중요합니다. 같은 문장이라도 시스템이나 developer 역할에 놓였는지 user 역할에 놓였는지에 따라 지시의 우선순위가 달라질 수 있으므로, 텍스트만 이어 붙여 저장하면 원래 실행을 복원할 수 없습니다.
| 기록 대상 | 남길 형태 | 빠뜨리면 생기는 문제 |
|---|---|---|
| 모델 식별자 | 공급자가 반환한 전체 문자열 | 다른 버전으로 재실행될 수 있음 |
| 메시지 입력 | 역할, 순서, 원문, 변수값 | 지시 우선순위가 달라짐 |
| 생성 설정 | seed, temperature, top_p, 출력 한도 | 후보 선택 분포가 변함 |
| 출력 형식 | 일반 텍스트, 구조화 형식, 중지 조건 | 종료 지점과 문장 형태가 달라짐 |
| 도구 호출 | 도구 이름, 인자, 반환 결과 | 모델이 본 맥락이 달라짐 |
| 외부 자료 | 문서 원문 또는 식별 가능한 버전 | 검색 결과가 바뀔 수 있음 |
| 응답 메타데이터 | 모델 버전, 지문, 종료 사유, 사용량 | 차이의 원인을 추적하기 어려움 |
seed(시드)는 샘플링에 쓰이는 무작위성의 시작값입니다. 같은 시드만 적는 것으로는 부족하고, 프롬프트와 다른 요청 매개변수도 동일해야 하며, 공급자가 제공하는 백엔드 지문도 함께 비교해야 합니다.
temperature는 후보 선택의 무작위성을 조절하는 값이고, top_p는 누적 확률 범위 안에서 후보를 제한하는 방식입니다. 둘 중 하나만 바꿨다고 생각해도 실제 요청에는 다른 기본값이 들어갈 수 있으므로, 사용자가 지정한 값과 지정하지 않은 상태를 모두 기록하는 편이 안전합니다.
출력 토큰 한도와 중지 조건도 단어 선택에 영향을 줍니다. 응답이 길어지다 중간에 끊겼는지, 특정 문자열을 만나 정상 종료했는지에 따라 다음 실행의 문맥이 달라질 수 있기 때문입니다.
구조화 출력이나 함수 호출을 사용했다면 스키마와 도구 정의도 보관해야 합니다. 모델이 선택한 단어만 저장하면 같은 단어가 어떤 필드 제약이나 함수 인자 형식 안에서 선택되었는지 확인할 수 없습니다.
실행 환경과 응답 증거를 함께 보존하기
요청 본문이 같아도 실행 환경이 다르면 결과가 달라질 수 있습니다. 사용하는 API 버전, SDK(개발용 소프트웨어 도구 모음) 버전, 요청을 만드는 코드, 직렬화 방식, 문자 인코딩을 실행 기록에 연결해 두어야 합니다.
특히 자동화 코드에서는 기본값을 믿지 않는 습관이 필요합니다. 코드에 없는 값은 나중에 라이브러리나 서버의 기본값이 바뀌었을 때 재현을 방해하므로, 최종적으로 전송된 요청을 저장하는 방식이 더 확실합니다.
외부 자료를 참고하는 작업은 입력의 경계를 넓게 잡아야 합니다. 검색 결과, 검색 시점, 문서의 원문, 파일 식별자, 데이터베이스 조회 조건처럼 모델이 실제로 읽은 자료를 보존해야 하며, 단순히 “웹 검색 사용”이라고 적는 것만으로는 부족합니다.
도구가 현재 시각, 위치, 사용자 계정, 재고, 환율처럼 변하는 정보를 반환했다면 반환값 자체를 저장해야 합니다. 같은 도구를 다시 호출하면 같은 질문에도 다른 값이 돌아올 수 있으므로, 도구 호출 성공 여부와 오류 응답도 실행의 일부로 취급합니다.
Gemini API는 생성 설정에 seed를 받을 수 있습니다. Gemini 응답처럼 공급자가 제공하는 modelVersion, responseId, usageMetadata, finishReason은 결과와 함께 보존할 가치가 있습니다.
OpenAI 계열에서는 모델 식별자와 응답의 시스템 지문, 요청 식별자처럼 나중에 서버 측 차이를 추적할 수 있는 값을 함께 남기는 방식이 유용합니다.
응답 원문은 가공 전 상태로 저장해야 합니다. 애플리케이션이 공백을 정리하거나 줄바꿈을 바꾸거나 JSON 필드를 재배열한 뒤의 값만 남기면, 모델이 실제로 선택한 토큰과 후처리 결과를 구별하기 어렵습니다.
재현 로그에는 개인정보와 비밀키가 섞이지 않도록 별도 처리가 필요합니다. API 키 자체는 저장하지 말고, 민감한 입력은 접근 권한을 제한한 보관소에 원문 해시나 참조 식별자와 함께 관리하여 추적성과 보호를 함께 확보해야 합니다.
실험을 반복할 때는 평가 세트(eval, 동일한 입력과 기준으로 결과를 비교하는 테스트 묶음)를 고정합니다. 단어 선택 결과만 비교하지 말고, 후보 적합성, 금칙어 준수, 문맥 보존처럼 사전에 정한 판정 기준을 함께 기록해야 모델 버전이나 프롬프트 변경의 영향을 분리할 수 있습니다.
Gemini처럼 latest 별칭이 새 릴리스로 바뀔 수 있는 체계에서는 실행 시점에 실제 사용된 모델 버전을 응답에서 확인해야 합니다. 고정 모델을 사용했더라도 공급자의 변경 공지와 폐기 일정을 함께 살펴야 장기간의 재실행 계획을 세울 수 있습니다.
결국 좋은 기록은 “무엇을 남길까”보다 “나중에 다른 사람이 같은 요청을 만들 수 있는가”로 판단합니다. 입력 파일, 프롬프트 템플릿, 설정 객체, 도구 반환값, 응답 원문이 하나의 실행 식별자에 연결되어 있다면 원인 분석과 품질 비교가 훨씬 쉬워집니다.
자주 묻는 질문 FAQ
Q1) seed만 저장하면 같은 단어를 다시 얻을 수 있나요?
그렇지 않습니다. seed는 샘플링 시작값일 뿐이므로 모델 버전, 전체 메시지, 생성 설정, 외부 자료가 함께 같아야 비교가 가능합니다. 공급자가 결정성을 보장하지 않는 경우에는 같은 결과가 아니라 같은 조건에서 비슷한 판단이 나오는지를 평가해야 합니다.
Q2) 대화형 AI 화면에서 사용한 경우 무엇을 남겨야 하나요?
가능하다면 대화 원문, 첨부 파일, 선택한 모델 이름, 적용된 지시문, 도구 사용 여부, 결과를 그대로 저장합니다. 화면에 보이지 않는 기본 설정이나 내부 버전이 있다면 결과와 함께 표시된 메타데이터도 보존하는 편이 좋습니다. 나중에 API로 옮길 때는 화면의 대화와 API 요청을 같은 것으로 간주하지 말고 별도 실행으로 기록해야 합니다.
Q3) 모델이 업데이트되면 과거 결과를 어떻게 재현하나요?
당시 사용한 고정 모델 식별자와 원본 입력, 요청 설정, 외부 자료, 응답 메타데이터를 기준으로 재실행합니다. 원래 버전을 더 이상 사용할 수 없다면 결과가 완전히 같다고 주장하기보다 새 버전의 결과와 차이를 평가합니다. 변경 전후 평가 세트를 같은 조건으로 실행하면 단어 선택 기준이 어떻게 달라졌는지 확인할 수 있습니다.