AI 데모는 됐는데 현장에서 안 되는 이유 — '재현성' 없이 굴리는 모델의 대가

데모에서는 그렇게 잘 됐는데, 막상 현장에 들고 들어가면 말을 안 듣는 AI. 현장 담당자 앞에서 시연하다가 식은땀을 흘려본 적, 저만 있는 건 아닐 겁니다. 그리고 그때마다 우리는 익숙한 변명을 꺼내 들었습니다. "데이터가 더 있어야 해요." "모델을 바꿔야겠네요."

 

7년차 현장 엔지니어로서, 제조 현장에서 AI를 굴려보며 깨달은 건 하나입니다. 데모가 깨지는 진짜 이유는 성능이 아니라 '재현성'인 경우가 훨씬 많다는 것. 같은 질문에 같은 답이 나오지 않는 시스템을 현장에 들일 수는 없습니

다.

 

"그때는 됐는데"의 정체

데모의 성공은 운이 좋은 한 번일 수 있습니다. 프롬프트 한 줄, 모델 버전, temperature 값, 컨텍스트에 들어간 문서 순서 — 이 중 하나만 바뀌어도 답은 달라집니다. 그런데 우리는 '됐던 그때'의 조건을 기록하지 않습니다. 그러니 안 됐을 때 어디서부터 손을 대야 할지 모르고, 고치다 보면 오히려 됐던 것마저 깨뜨립니다. 재현이 안 되는 시스템에서는 디버깅도, 책

내가 현장에서 지키는 재현성 3가지

1. 레시피를 고정한다.

모델 버전·temperature·프롬프트·참조 문서를 하나의 '레시피'로 묶고, 바꿀 때마다 버전을 올리고 변경 이유를 적습니다. "프롬프트 v1.3, 10월 15일에 예시 2개 추가" 같은 기록 하나가 나중에 몇 시간을 벌어줍니다.

2. 골든 세트를 만든다.

현장에서 실제로 나왔던 질문 20~50개를 모은 평가 셋입니다. 레시피를 바꿀 때마다 이 세트를 돌려봅니다. 점수가 아니라 "이전에 됐던 답이 여전히 나오는가"를 보는 겁니다. 이게 없으면 개선인지 퇴보인지조차 모릅니다.

3. 로그를 남긴다.

입력·출력·레시피 버전·시간을 기록합니다. 현장에서 "언제부터 안 됐죠?"라는 질문에 답할 수 있는 건 로그뿐이고, 이 질문에 답할 수 있어야 원인을 좁힐 수 있습니다.

재현성은 기술이 아니라 약속이다

현장팀에게 AI를 건넬 때 필요한 건 정확도 수치보다 "이렇게 하면 이렇게 나옵니다"라는 약속입니다. 재현성은 그 약속을 지킬 수 있게 해주는 최소 조건입니다. 정확도가 95%여도 매번 다른 답을 내면 현장은 안 쓰고, 정확도가 80%여도 매번 같은 방식으로 동작하면 현장은 씁니다. 신뢰는 일관성에서 옵니다.

그래서 뭘 하면 되나 — 지금 굴리고 있는 AI가 있다면, 오늘 당장 '됐던 그때'의 조건(모델·프롬프트·온도)을 적어두세요. 그 한 장의 기록이 다음 데모의 운명을 바꿉니다.

---

관련 글: 디지털트윈의 진짜 엔진은 3D가 아니라 '데이터 수집'이다 — 데이터 수집이 갖춰졌다면, 다음으로 챙겨야 할 것이 바로 이 재현성입니다.