이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
LLM 기반 서비스를 만들 때 비결정성 관리에서 가장 먼저 쓰는 방법은 temperature를 0 또는 낮은 값으로 고정하는 것입니다. 분류나 추출처럼 일관된 출력이 필요한 태스크에서는 이것만으로도 재현성이 크게 높아집니다. 그 다음으로는 system prompt에 출력 형식을 명시적으로 지정합니다. JSON 스키마나 예시를 직접 넣으면 파싱 오류 빈도가 줄어듭니다. 학교 프로젝트에서 텍스트 분류 파이프라인을 만들 때 같은 입력에 대해 10회 호출 결과를 비교해 출력 변동 폭을 측정했고, temperature·seed·format 지정의 조합으로 변동 폭을 85% 줄였습니다. 완전한 결정성이 필요한 경우는 LLM을 분류기로 쓰지 않고 임베딩 + 코사인 유사도 방식으로 대체하는 것도 방법이라고 생각합니다.
비결정성은 피하기보다 측정하고 허용 범위를 설계하는 것이 현실적이라는 것을 그 경험에서 배웠습니다.
PyTorch로 분류 모델을 학습할 때 재현성이 깨지는 원인을 처음으로 체계적으로 추적한 경험이 있습니다. torch.manual_seed만 고정했는데 결과가 매번 달라졌고, 원인을 찾아보니 numpy와 random 모듈까지 함께 고정해야 한다는 걸 알게 됐습니다.
GPU 환경에서는 여기서 한 단계 더 나아가야 했습니다. torch.backends.cudnn.deterministic=True와 benchmark=False를 함께 설정하자 동일한 시드로 실행한 두 번의 학습이 거의 같은 loss curve를 보였습니다. 단, 학습 속도가 약 10~15% 느려지는 트레이드오프가 있었습니다. 그 이후로 실험 단계에 따라 결정성 수준을 다르게 적용했습니다.
탐색 단계에서는 속도를 위해 비결정성을 허용하고, 최종 성능 검증에서만 완전 결정 모드로 돌리는 방식이었습니다. 결과 평가 기준으로는 동일 시드로 5회 실행 시 accuracy 편차가 0.3% 이내인지를 기준으로 삼았습니다. 환경 버전 차이도 재현성을 깨는 요인이어서 requirements.txt에 패키지 버전을 고정하고 공유하는 습관이 그 과정에서 생겼습니다.
비결정성을 아예 제거하려 하기보다 허용 범위를 단계별로 명확히 정의하는 방향이 실용적이라는 판단도 그때 만들어졌습니다.
팀 프로젝트에서 ML 실험 재현성을 팀 공통 프로세스로 만드는 작업을 맡았습니다. 팀원마다 시드 설정 방식이 달라 누군가의 로컬에서는 재현되는데 다른 환경에서는 결과가 다른 경우가 반복됐습니다. 원인 추적에 매번 시간을 쓰다 보니 이걸 구조적으로 해결해야 한다는 결론이 나왔습니다. 해결책은 시드 초기화 코드를 utils 파일에 모아 모든 학습 스크립트가 공통으로 불러오게 하고, Docker 이미지를 팀 공용으로 고정하는 것이었습니다. 분산 학습 환경에서는 추가 문제가 있었는데, DataLoader의 Worker 개수에 따라 데이터 셔플 순서가 달라지는 현상이었습니다.
worker_init_fn에 시드를 주입하는 방식으로 해결했습니다. 협업 과정에서 어려웠던 점은 팀원마다 재현성에 두는 중요도가 달랐다는 것입니다. 공통 설정을 강제하기보다 왜 필요한지를 실제 사례로 보여주는 것이 설득에 효과적이었습니다. 결과적으로 팀 내 재현 오류 발생이 0건으로 줄었고, 코드 리뷰 체크리스트에 시드 설정 확인 항목이 자연스럽게 들어갔습니다.
시드 고정은 개인 습관이 아니라 팀 약속으로 만들어야 작동한다는 것을 그 경험에서 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 AI 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.