같은 시드로도 AI 결과가 달라지는 이유
시드를 고정해도 모델 실행의 모든 조건이 같아지는 것은 아니다. PyTorch의 난수 상태와 결정적 알고리즘, 수치 계산의 경계를 살피고 팀에서 AI 결과를 비교하고 인수하는 기준을 정한다.
GPT Image 2로 생성한 개념 이미지이며 실제 실험 장면이 아니다.
모델 비교 결과를 받은 동료가 같은 입력과 시드로 다시 실행했는데 값이 조금 달라졌다고 하자. 담당자는 시드를 적었으니 재현에 필요한 정보를 충분히 넘겼다고 생각한다. 동료는 숫자가 다르니 실험을 믿기 어렵다고 느낀다. 이 가상의 상황에서 두 사람에게 먼저 필요한 것은 시드를 다시 고르는 일이 아니라, 무엇이 같아야 같은 실험인지 합의하는 일이다.
AI 업무에서는 재현이라는 말을 여러 뜻으로 쓴다. 오류가 났던 계산을 다시 만들고 싶을 때도 있고, 다른 장비에서도 비슷한 품질이 나오는지 확인하고 싶을 때도 있다. 두 목적에 같은 합격 기준을 적용하면 작은 수치 차이를 장애로 처리하거나, 중요한 품질 저하를 대수롭지 않은 흔들림으로 넘길 수 있다.
시드는 이 문제를 줄이는 유용한 설정이다. 다만 모델, 실행 코드, 입력, 난수의 현재 상태, 수치 계산 환경을 대신 기록해 주지는 않는다. 여기서는 로컬 PyTorch 모델 실험을 중심으로 그 범위를 살핀다. 원격 AI 서비스의 내부 동작을 검증한 글이나, GPU 실험 결과를 보고하는 글은 아니다.
시드는 난수열의 출발점을 정한다
시드를 고정한다는 것은 난수를 없앤다는 뜻이 아니다. 같은 조건에서 같은 난수열을 다시 시작하도록 초기 상태를 정하는 일이다. PyTorch의 재현성 문서는 프로그램 시작 시 torch.manual_seed()를 같은 값으로 설정하고 다른 비결정성 원인을 제거하면, 같은 환경에서 실행할 때 같은 난수열을 얻을 수 있다고 설명한다.[1]
여기서 주의할 것은 실행 순서다. 난수를 사용하는 연산을 한 번 호출하면 생성기의 상태가 진행한다. 프로그램을 처음부터 다시 실행하는 것과, 이미 실행 중인 프로그램에서 같은 함수를 한 번 더 호출하는 것은 다르다. 중간에 난수를 소비하는 연산이 추가됐다면 뒤의 계산에 전달되는 값도 달라질 수 있다. 같은 시드가 적힌 두 기록만으로 호출 직전 상태까지 같았다고 판단할 수는 없다.
torch.manual_seed()가 생성기 객체를 반환한다는 API 설명도 조심해서 읽어야 한다. 2026년 11월 5일에 확인한 공식 저장소의 torch/random.py에서는 이 호출이 내부 함수를 거쳐 기본 생성기의 manual_seed를 반환한다. 매번 독립된 새 생성기를 만든다는 뜻으로 읽으면 안 된다.[2] 특정 작업에 별도의 생성기를 넘기는 프로그램이라면, 그 객체를 새로 초기화했는지 이전 호출에서 사용한 상태를 이어받았는지도 기록할 필요가 있다.
난수의 주체가 하나라는 보장도 없다. 전처리는 Python이나 NumPy를 쓰고 모델 계산은 PyTorch를 쓸 수 있다. PyTorch 문서는 다른 라이브러리의 난수와 NumPy의 별도 Generator 객체를 각각 관리해야 한다고 설명한다.[1] 팀에서 시드 값을 하나의 설정 항목으로 모으더라도, 그 값이 실제로 어느 생성기에 적용됐는지 확인해야 한다.
따라서 결과가 달라졌을 때 시드 번호부터 바꾸면 원인을 찾기 어렵다. 먼저 입력이 같았는지, 동일한 연산 순서로 실행했는지, 같은 생성기 상태에서 출발했는지를 비교하는 편이 낫다. 우연히 비슷한 결과를 얻는 일과 이전 실행을 재현하는 일은 목적이 다르다.
같은 난수 다음에도 계산의 차이가 남는다
난수 입력을 통제한 뒤에도 계산 경로가 달라질 수 있다. torch.use_deterministic_algorithms(True)는 지원되는 연산에서 결정적 알고리즘을 사용하도록 하고, 결정적 대안이 없는 것으로 알려진 연산에는 오류를 낸다. 공식 API 문서가 말하는 결정성은 같은 입력을 같은 소프트웨어와 하드웨어에서 실행하는 범위다. 이 설정 하나만으로 애플리케이션 전체의 재현성이 확보되는 것은 아니라고도 명시한다.[3]
오류 대신 경고만 내도록 설정할 수 있다는 점도 중요하다. warn_only=True는 실행이 멈추지 않게 할 수 있지만, 결정적 구현이 없는 연산을 결정적으로 바꾸지는 않는다.[3] 검사를 통과시키려고 이 옵션을 바꿨다면 실행 조건도 달라졌다고 기록해야 한다. 로그에 경고가 남았는데 보고서에는 결정성 검사를 통과했다고 적으면, 다음 작업자는 실제 보장 범위를 알 수 없다.
수치 계산의 동일성도 별도 문제다. 부동소수점은 표현할 수 있는 정밀도가 유한하므로, 연산을 묶고 누적하는 순서에 따라 결과가 달라질 수 있다. PyTorch의 수치 정확도 문서는 수학적으로 같은 계산이라도 비트 단위의 결과가 같다고 보장하지 않는다. 배치 전체를 계산한 뒤 한 항목을 꺼내는 경우와 그 항목만 따로 계산하는 경우도 비트 단위 일치를 보장하지 않는다.[4]
이 때문에 모델 비교 기록에는 시드 외에 배치 크기와 수치 자료형, 라이브러리 버전, 장치, 실제 실행 설정이 필요하다. 장비를 교체한 뒤 값이 달라졌다면, 이전 계산을 그대로 반복한 것인지 새로운 환경에서 결과의 적합성을 평가하는 것인지부터 구분해야 한다. 문서는 PyTorch 릴리스·커밋·플랫폼을 넘나드는 완전한 재현과 CPU·GPU 간 동일 결과를 보장하지 않는다.[1]
결정적 알고리즘을 사용하는 데에는 성능 비용이 따를 수도 있다.[3] 하지만 비용의 크기는 실제 업무에서 측정할 문제다. 디버깅용 실행에는 엄격한 통제가 유용하고, 운영용 실행에는 처리 시간과 품질을 함께 살펴야 한다. 이 글은 특정 설정을 켰을 때 얼마나 느려지는지 측정하지 않았으며, 모든 모델에 같은 설정 묶음을 권하지 않는다.
결과를 보기 전에 비교 기준을 정한다
팀이 먼저 정해야 할 것은 재현이라는 말의 합격 조건이다. 아래 표는 필자가 제안하는 비교 구분이다. PyTorch가 지정한 평가 표준이나 보편적인 허용오차가 아니다.
| 비교 목적 | 확인할 대상 | 이 결과만으로 판단할 수 없는 것 |
|---|---|---|
| 저장된 산출물을 그대로 인수하기 | 파일 바이트와 해시 | 같은 계산으로 다시 생성되는지 |
| 특정 실행의 계산 결과를 다시 얻기 | 고정된 입력·환경·난수 상태와 출력 배열 | 다른 장비에서도 같은 결과가 나오는지 |
| 수치 차이를 허용하며 비교하기 | 사전에 정한 오차 지표와 허용 범위 | 업무에서 중요한 오류가 없는지 |
| 업무 품질을 유지하며 환경을 바꾸기 | 고정한 사례별 품질 기준과 실패 사례 | 모든 출력의 비트 단위 동일성 |
파일 해시가 다르다는 이유만으로 모델 출력이 달라졌다고 결론 내려서는 안 된다. 저장 형식이나 메타데이터가 달라졌을 수 있다. 반대로 평균 오차가 작다는 이유만으로 업무상 안전한 결과라고 판단해서도 안 된다. 평균에 묻힌 한 항목이 최종 분류나 검토 대상의 순서를 바꿀 수 있다. 무엇을 비교하는지에 따라 원시 배열, 저장 파일, 최종 업무 판정을 따로 확인해야 한다.
허용오차는 결과를 본 뒤 적당히 정하는 값이 아니다. 결과가 마음에 들 때까지 범위를 넓히면 검사가 그 결과를 승인하는 형식으로 바뀐다. 오차를 정하기 어려운 업무라면 처음부터 정밀한 숫자를 꾸며 쓰기보다, 어떤 차이가 실제 사용 결정을 바꾸는지 사례로 정리하는 편이 낫다.
가령 가상의 문의 분류 모델을 다른 장비로 옮긴다고 하자. 담당자는 이전에 검토한 입력 묶음과 기대 분류, 사람이 확인해야 하는 경계 사례를 보존한다. 새 환경에서는 수치 차이와 최종 분류 변화를 함께 기록한다. 원래 사람이 확인하던 사례가 자동 처리로 바뀌었다면 평균 점수가 비슷해도 그 변화를 검토한다. 이것은 운영 평가를 설계하기 위한 예시이며, 특정 모델에서 관측한 결과가 아니다.
동료가 다시 확인할 수 있는 기록을 남긴다
실행을 넘길 때에는 시드 하나보다 짧은 재현 기록이 도움이 된다. 모델과 코드의 정확한 버전, 입력 파일, 실행 환경, 난수 초기화 방법, 출력, 비교 기준을 한 실행에 대응시킨다. 모든 환경 정보를 무작정 쌓기보다는 그 비교에서 고정한 조건과 실제로 바꾼 조건이 드러나야 한다.
다음 작업자는 우선 같은 환경에서 기준 실행을 다시 확인한다. 그다음 장치나 패키지 등 바꾸려는 조건을 분리한다. 여러 조건을 동시에 바꿨다면 그 사실도 남긴다. 원인을 한 변수로 설명할 수 없는 비교를 단일 설정의 효과처럼 보고하지 않는 것이 중요하다.
한 시드에서 같은 결과를 얻었다면 그 실행쌍의 재현 근거는 생긴다. 그러나 모델이나 학습 방법의 우수성을 판단하려면 질문이 달라진다. 특정 난수열에서 우연히 좋았던 결과인지 살피려면 여러 조건의 결과가 필요하다. 고정 시드는 비교를 시작하기 위한 통제 수단이고, 모델의 일반적인 품질을 입증하는 표본 전체는 아니다.
이 관점은 LoRA 모델을 인수할 때 남겨야 할 구성 정보와 이어진다. 그 글이 어떤 모델을 전달했는지 묻는다면, 여기서는 같은 모델을 어떤 상태와 환경에서 실행했고 어디까지 같음을 확인했는지 묻는다. 동료가 같은 결과를 얻지 못했을 때에도 첫 차이를 추적할 수 있어야 재현 기록이 제 역할을 한다.
시드를 기록하는 습관은 유지할 만하다. 여기에 무엇을 고정했고 무엇을 비교했는지 한 문장을 더 남겨 보자. 같은 숫자를 입력했다는 기록이, 다른 사람이 검토할 수 있는 실험의 조건으로 바뀐다.
공식 문서와 소스는 2026년 11월 5일에 확인했다. 문서는 PyTorch 2.15 기준이며, 구현 근거는 확인 당시 기본 브랜치의 고정 커밋이다. 본문의 팀 운영 절차는 필자의 제안이다.