“AI R&D 실험은 됐는데 재현이 안 돼요” 원인부터 잡으세요

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

어제는 정확도 92%였는데 오늘 같은 코드를 실행하니 88%가 나옵니다. 담당자는 코드를 바꾸지 않았다고 하고, 서버도 그대로인데 결과만 달라졌다면 단순한 운이나 모델의 변덕으로 넘겨서는 안 됩니다. AI R&D 실험 재현성이 무너졌다는 신호이기 때문입니다.

재현 실패는 논문 작성 단계에서만 문제가 되는 것이 아닙니다. 정부과제 중간평가, 고객사 시연, 모델 검수, 특허 자료 작성처럼 결과의 근거를 설명해야 하는 순간마다 일정과 신뢰도를 동시에 흔듭니다. 아래 순서대로 범위를 좁히면 무작정 재학습하는 낭비를 줄일 수 있습니다.

같은 코드인데 결과가 달라지는 첫 번째 이유

랜덤 시드는 출발점일 뿐입니다

가장 먼저 확인할 항목은 난수입니다. 데이터 분할, 가중치 초기화, 배치 순서, 드롭아웃에는 난수가 개입하므로 Python, NumPy, 학습 프레임워크와 GPU 관련 시드를 각각 고정해야 합니다. 그러나 seed 값 하나만 입력했다고 재현성이 보장되지는 않습니다. 병렬 연산 순서나 비결정적 GPU 연산이 남아 있으면 동일한 장비에서도 값이 미세하게 달라질 수 있습니다.

작은 수치 차이는 학습이 반복되면서 확대될 수 있습니다. 분류 정확도만 보면 차이가 작아 보여도 특정 클래스의 재현율이나 임계값 근처의 예측은 크게 달라질 수 있죠. 따라서 시드를 고정한 뒤 동일 조건으로 최소 3회 실행하고, 최종 점수뿐 아니라 초기 손실값과 epoch별 지표까지 비교해야 원인이 난수인지 다른 조건인지 판단할 수 있습니다.

• 난수 고정: 언어, 라이브러리, 프레임워크, 데이터 로더의 시드를 모두 기록합니다.
• 결정론 모드: 사용 중인 프레임워크가 제공하는 deterministic 설정과 제한 사항을 확인합니다.
• 반복 검증: 같은 실행을 3회 이상 반복해 편차 범위와 최초로 달라지는 지점을 찾습니다.
• 평가 모드 확인: 검증 시 dropout과 batch normalization이 추론 상태로 전환됐는지 점검합니다.

실무 팁: 최종 정확도가 아니라 첫 번째 배치의 샘플 ID, 입력 해시, 초기 손실값을 함께 비교하면 문제 구간을 훨씬 빨리 찾을 수 있습니다.

데이터가 같다는 말부터 의심해야 합니다

파일 이름보다 데이터 지문을 남기세요

팀원이 모두 ‘같은 데이터’를 썼다고 말해도 실제 내용은 다를 수 있습니다. 원본 파일이 덮어써졌거나 라벨 수정본이 일부 서버에만 반영되고, 전처리 캐시가 이전 상태로 남는 일이 흔합니다. 특히 train.csv처럼 고정된 이름을 계속 사용하면 이름은 같지만 내용이 달라진 사실을 실험 기록에서 발견하기 어렵습니다.

해결 방법은 데이터셋에 버전과 지문을 부여하는 것입니다. 원본 파일의 해시, 전체 행 수, 클래스별 개수, 결측치 수, 중복 샘플 수를 실행 시점마다 자동으로 저장하세요. 이미지나 음성처럼 대용량 파일이 많다면 파일 목록과 각 파일의 크기·수정 시각·체크섬을 담은 manifest를 만들면 됩니다. 데이터 분할 결과도 seed만 기록하지 말고 학습·검증·테스트에 포함된 샘플 ID 목록을 별도 산출물로 보관해야 합니다.

기관 단위의 연구는 개인 PC 실험보다 데이터 관리 책임이 큽니다. 연구조직의 역할과 운영 맥락을 살펴볼 때는 한국과학기술연구원 관련 지식백과처럼 기관 정보가 명확한 자료를 참고하되, 실제 과제에서는 내부 데이터 관리 규정과 보안 등급을 우선 적용해야 합니다.

1. 원본 데이터를 읽기 전 파일 해시와 행 수를 저장합니다.
2. 전처리 후 클래스 분포, 결측치, 이상치 통계를 다시 계산합니다.
3. 분할된 샘플 ID를 세 개의 목록으로 고정해 보관합니다.
4. 증강 설정과 전처리 코드의 커밋 번호를 실험 ID에 연결합니다.
5. 캐시 생성 시 데이터 버전과 전처리 버전을 키에 포함합니다.

서버 환경 차이는 패키지 목록보다 깊습니다

드라이버와 하드웨어까지 실행 조건입니다

requirements.txt가 같으니 환경도 같다고 판단하기 쉽지만, AI R&D에서는 충분하지 않습니다. 운영체제, Python 빌드, CUDA와 cuDNN, GPU 드라이버, 프레임워크 빌드 옵션, GPU 모델이 연산 결과에 영향을 줄 수 있습니다. 버전 범위를 느슨하게 지정한 패키지는 설치 날짜에 따라 하위 의존성이 달라지므로 ‘어제 만든 환경’과 ‘오늘 만든 환경’조차 동일하지 않을 수 있습니다.

먼저 성공한 실험의 환경을 기준점으로 삼으세요. 패키지 버전을 정확히 고정하고 컨테이너 이미지의 태그뿐 아니라 변경되지 않는 digest도 기록합니다. 그다음 GPU 이름, 드라이버 버전, CUDA 런타임, CPU 명령어 집합과 운영체제 정보를 실행 로그에 자동 첨부합니다. 환경을 한꺼번에 교체하지 말고 데이터·코드·환경 중 하나만 바꾸는 방식으로 차이를 좁혀야 합니다.

• 컨테이너 이미지는 재사용 가능한 형태로 보관하고 digest를 기록합니다.
• 패키지 잠금 파일에는 직접 의존성과 하위 의존성을 함께 포함합니다.
• 학습 로그에 장비 식별 정보와 프레임워크 빌드 정보를 자동 삽입합니다.
• 비밀키나 개인정보는 환경 캡처 대상에서 제외하고 별도 보안 절차로 관리합니다.

환경 복제 비용이 부담스럽다면 모든 실험을 보존하려 하지 말고, 기준 모델과 의사결정에 사용된 핵심 실험부터 완전하게 동결하세요.

모델 파일만 남기면 실험은 복구되지 않습니다

한 번의 실행을 하나의 묶음으로 관리하세요

가중치 파일 하나만 전달받고 성능을 재현해 달라는 요청은 생각보다 자주 발생합니다. 하지만 모델은 어떤 데이터와 코드, 설정, 평가 기준으로 만들어졌는지가 함께 있어야 의미가 있습니다. 전처리기의 스케일 값, 토크나이저 버전, 클래스 인덱스 순서, 임계값이 빠지면 모델 파일이 정상이어도 결과는 달라집니다.

실험 번들에는 코드 커밋, 데이터 버전, 전체 설정, 환경 정보, 실행 명령, 모델 가중치, 평가 결과와 로그가 포함되어야 합니다. 설정값은 문서에 손으로 옮기기보다 실제 실행 프로그램이 읽은 최종 설정을 저장하세요. 기본값과 명령행 인자가 합쳐진 뒤의 값을 남겨야 ‘learning rate를 적지 않았는데 어떤 값이 적용됐는가’ 같은 논쟁을 막을 수 있습니다.

기술 성과는 재현 가능한 근거가 있어야 투자·사업화 검토에서도 설명력이 생깁니다. 기업과 기술의 연결 구조를 이해하는 참고 자료로 현대기술투자(주) 지식백과 정보를 살펴볼 수 있으며, 개별 AI R&D 성과는 이와 별개로 실험 이력과 검증 자료를 자체적으로 갖춰야 합니다.

1. 실험 ID 발급: 사람이 읽을 수 있는 프로젝트명과 고유 식별자를 함께 사용합니다.
2. 설정 스냅샷: 프로그램이 실제 적용한 하이퍼파라미터를 JSON이나 YAML로 저장합니다.
3. 산출물 연결: 모델, 그래프, 평가표, 오류 로그를 같은 실험 ID 아래 묶습니다.
4. 대표 실행 지정: 최고 점수만 고르지 말고 선정 이유와 검증 조건을 기록합니다.
5. 복구 시험: 다른 담당자가 문서만 보고 실행해 같은 허용 범위의 결과를 얻는지 확인합니다.

재현 실패를 고치는 6단계 순서

문제가 발생했다면 최신 코드를 무작정 수정하기보다 성공 실행과 실패 실행을 두 열로 놓고 비교하세요. 아래 순서를 지키면 변수가 적은 곳부터 확인하게 되어 디버깅 시간이 줄어듭니다.

1. 모델 가중치와 입력 데이터의 해시가 같은지 확인합니다.
2. 평가 코드, 지표 계산 방식, 임계값이 같은지 비교합니다.
3. 샘플 분할과 배치 순서를 대조합니다.
4. 코드 커밋과 설정 스냅샷의 차이를 확인합니다.
5. 패키지, 드라이버, GPU 환경을 비교합니다.
6. 결정론 모드에서 최소 데이터로 다시 실행해 최초 분기 지점을 찾습니다.

연구 단계와 납품 단계는 서로 다른 답이 필요합니다

탐색 속도가 중요한 팀의 선택

아이디어를 빠르게 검증하는 초기 연구팀이라면 모든 실험을 완벽하게 보존하려다 탐색 속도를 잃을 수 있습니다. 이 경우 데이터 버전, 코드 커밋, 최종 설정, 핵심 지표 네 가지를 자동 기록하는 최소 구조부터 시작하세요. 성능이 기준선을 넘거나 의사결정에 쓰인 실험만 환경 이미지와 전체 산출물을 동결하면 관리 비용과 재현성을 균형 있게 맞출 수 있습니다.

반면 고객사 납품, 정부과제 검수, 규제 대응처럼 제3자가 결과를 확인해야 하는 팀은 더 엄격한 기준이 필요합니다. 실행 환경을 컨테이너로 고정하고 데이터 접근 권한, 모델 승인 이력, 평가 스크립트, 허용 오차까지 문서화하세요. 기술기업 사례를 파악하는 보조 자료로 (주)우리기술 지식백과 항목을 참고할 수 있지만, 실제 검수 기준은 계약서와 과제 협약서의 요구사항에 맞춰 별도로 설계해야 합니다.

• 빠른 탐색이 우선인 독자: 자동 실험 추적, 데이터 지문, 코드 커밋 연결부터 적용하고 대표 실험만 완전 보존하세요.
• 외부 검증이 필요한 독자: 환경 동결, 권한 이력, 평가 절차, 산출물 해시와 제3자 복구 시험까지 포함하세요.
• 공통 기준: ‘같은 결과’는 숫자가 완전히 일치한다는 뜻인지, 사전에 정한 허용 오차 안에 든다는 뜻인지 먼저 정의하세요.
• 복구 담당자는 원 실험자가 아닌 팀원으로 지정해 기록의 빈틈을 실제로 드러내세요.

지금 모델을 자유롭게 탐색하는 단계라면 가벼운 기록 자동화부터 선택하는 편이 현실적입니다. 이미 납품일이나 평가일이 잡힌 상태라면 새 실험을 늘리기보다 대표 모델 한 개를 다른 환경에서 복구하는 시험을 먼저 선택하세요. 두 독자에게 필요한 도구는 달라도, 다음 실행을 타인이 다시 만들 수 있어야 AI R&D 결과가 팀의 자산으로 남는다는 기준은 같습니다.