Aionda

2026-03-02

생성형 AI 추천 흔들림 통제법

같은 질문에도 바뀌는 AI 추천을 반복 실행, seed·fingerprint로 측정·통제한다.

생성형 AI 추천 흔들림 통제법

같은 사진을 올리고 같은 질문을 던졌는데, AI가 추천을 바꿔버린다. 첫 답변은 “이쪽이 맞다”고 말하고, 다시 물으면 다른 기준을 들이민다. 이런 경험은 사용자가 “AI 추천을 믿어도 되나?”를 묻게 만든다. 생성형 AI의 추천은 설계상 흔들릴 수 있다. 다만 흔들림을 측정하고 통제하는 절차를 갖추면 활용 여지가 생긴다.

세 줄 요약

  • 핵심 이슈: 생성형 AI 추천은 기본적으로 비결정적이라, 같은 입력·같은 질문에도 결과가 달라질 수 있다(문서에 “non-deterministic by default”라고 명시돼 있다).
  • 왜 중요하나: 추천이 ‘정답’처럼 소비되면 구매/의료/채용 같은 의사결정에서 리스크가 커진다. 팀·조직 관점에서는 재현 가능한 QA와 책임 소재 정리가 어려워진다.
  • 독자는 뭘 하면 되나: 같은 프롬프트를 반복 실행해 변동 폭을 먼저 재고, 가능한 경우 seed 고정 + system_fingerprint 확인으로 재현성을 높인다. 추천에는 제약조건·근거·체크리스트를 붙여 검증 절차로 바꾼다.

현황

생성형 모델의 출력은 기본값 기준으로 요청마다 달라질 수 있다고 문서가 적는다. OpenAI 문서 표현 그대로면 **“Chat Completions are non-deterministic by default”**다. 이 점에서 “같은 프롬프트면 같은 답”이라는 사용자 기대와 제품 설계가 충돌한다.

흔들림은 기술적으로 **샘플링(확률적 디코딩)**에서 시작한다. temperature와 top_p는 무작위성을 조절하는 주요 손잡이다. 값이 높으면 더 많은 토큰 후보를 허용해 응답 분산이 커질 수 있고, 낮추면 분산이 줄어드는 방향으로 간다. 다만 같은 설정이라도 출력이 항상 고정되지는 않는다.

통제 수단도 문서에 언급돼 있다. seed 파라미터system_fingerprint를 함께 쓰면 재현 가능한 출력을 얻는 데 도움이 될 수 있다. 동시에 서버 측 구성 변경 같은 요인으로 결정성이 깨질 수 있다고도 적는다. 재현성은 한 번 설정하면 끝나는 속성이 아니라, 조건을 맞추면 좋아지고 환경이 바뀌면 다시 흔들릴 수 있는 품질이다.

대화형 시스템에서는 추천이 더 쉽게 흔들릴 수 있다. API 레퍼런스는 출력이 **messages(대화 메시지 목록)**에 의해 달라질 수 있다고 설명한다. 지시에는 우선순위가 있고, developer/system 역할 지시가 user보다 우선한다. ChatGPT 제품 차원에서는 Memory가 켜져 있으면 과거 대화에서 저장된 선호·정보가 다음 추천에 반영될 수 있다. Assistants의 Thread는 컨텍스트 윈도우를 넘으면 메시지를 “smartly truncate”한다고도 문서에 나온다. 같은 질문이라도 포함된 맥락이 달라지면 추천이 달라질 수 있다.

분석

사용자 입장에서 문제의 핵심은 “AI가 거짓말을 한다”로만 정리하기 어렵다. 추천에는 **기준(평가 함수)**이 필요하다. 그런데 생성형 AI의 추천은 기준이 암묵적인 경우가 많다. 이 암묵적 기준이 샘플링 변동, 컨텍스트 누적, 우선순위 지시, 메모리, 트렁케이션에 영향을 받는다. 단일 응답을 ‘정답’으로 쓰면, 추천은 정보가 아니라 불확실성이 섞인 의사결정이 된다.

개발자/조직 관점에서도 영향이 있다. 재현성이 낮으면 QA가 성립하기 어렵다. 같은 버그 리포트를 다시 실행해도 결과가 달라지면 수정 여부 판단이 지연될 수 있다. 그래서 신뢰를 “모델의 자신감”이 아니라 “실험 설계로 측정되는 안정성”으로 다루는 편이 낫다. 학술·의학 측정에서 쓰는 틀로는 반복 측정 안정성을 보는 test–retest reliability(예: Pearson 상관, ICC)나 평가자 합치도를 보는 Cohen’s kappa / Fleiss’ kappa / Krippendorff’s alpha 같은 지표가 있다. LLM 추천에 그대로 적용하기는 어렵지만, 접근은 비슷하다. 반복해서 재고, 일치도를 계산하고, 기준을 명시해야 한다.

또 다른 함정도 있다. “일관성”은 정확성과 별개다. 모델이 매번 똑같이 틀릴 수도 있다. 반대로, 상황에 따라 추천이 달라지는 것이 자연스러운 경우도 있다(사용자 선호가 바뀌거나, 이전 대화에서 조건이 추가됐거나, 메모리가 반영됐거나). 목표를 “무조건 동일 출력”으로 두기보다, 조건이 같을 때 얼마나 같은지조건이 바뀔 때 어떻게 바뀌는지를 나눠 검증하는 편이 낫다.

예를 들어 같은 사진을 두고 추천이 바뀔 때, 사용자는 “AI가 랜덤”이라고 느낄 수 있다. 하지만 실제로는 대화 중간에 “부드러운 걸 원한다” 같은 문장이 추가됐거나, 이전 대화에서 저장된 취향이 섞였거나, 답변이 근거를 생략한 채 결론만 달라져 사용자가 기준 변화를 놓쳤을 수도 있다.

실전 적용

사용자 관점의 요령은 단순하다. AI에게 “추천”만 시키지 말고 “추천을 검증 가능한 형태로 제출하라”고 요구한다. (1) 제약조건을 먼저 고정하고, (2) 근거를 구조화해 내게 하고, (3) 반복 실행으로 변동을 확인한다. 이 단계가 없으면 추천은 오해를 만들 수 있다.

개발자라면 제품에서 더 명시적으로 설계하는 편이 낫다. 재현성을 높이고 싶으면 seed를 쓰고, 환경 변화 탐지를 위해 system_fingerprint를 함께 기록한다(문서가 이 조합을 재현성 통제 수단으로 언급한다). temperature/top_p를 높여 출력 폭을 넓히면 추천 변동도 커질 수 있다는 점도 함께 받아들여야 한다. self-consistency 같은 반복 샘플링 기반 접근은 여러 번 생성한 뒤 일치하는 답을 고르는 전략이다(Wang et al., 2022). 추천을 단발로 내지 말고 내부적으로 여러 번 생성해 합의안을 만들면 사용자 체감 변동이 줄 수 있다. 다만 반복은 비용과 지연을 늘린다.

오늘 바로 할 일 체크리스트

  • 같은 입력/프롬프트를 여러 번 실행해 추천 결과가 얼마나 흔들리는지 기록하라(변동 폭을 모르면 신뢰도 논의도 어렵다).
  • 추천 요청에 “제약조건(예: 우선순위) + 근거 + 점검 체크리스트”를 템플릿으로 고정해, 결론만 바뀌는 답변을 줄이라.
  • 가능한 환경에서는 seed를 고정하고 system_fingerprint를 로그로 남겨, 재현 가능한 조건과 깨지는 조건을 구분하라.

FAQ

Q1. 왜 같은 프롬프트인데도 매번 답이 달라지나?
A1. 문서에 따르면 채팅 생성은 기본적으로 비결정적이다(“non-deterministic by default”). 여기에 temperature/top_p 같은 샘플링 파라미터가 무작위성을 키우거나 줄이고, 대화 messages 누적, developer/system 지시 우선순위, 메모리, 컨텍스트 트렁케이션이 겹치면 같은 질문처럼 보여도 모델이 실제로 받는 입력이 달라질 수 있다.

Q2. temperature/top_p를 낮추면 추천을 믿어도 되나?
A2. 분산이 줄어들 수는 있지만, 정답이 보장되지는 않는다. 일관성은 재현성과 관련이 있고, 정확성은 별도로 확인해야 한다. 낮춘 뒤에도 반복 테스트로 변동을 확인하고, 추천이 어떤 기준으로 나왔는지 근거/체크리스트로 검증하는 편이 낫다.

Q3. 완전히 똑같은 출력으로 고정할 수 있나?
A3. 문서 기준으로는 seed와 system_fingerprint로 재현 가능한 출력을 얻는 데 도움이 될 수 있지만, 서버 측 구성 변경 같은 이유로 결정성이 깨질 수 있다고 한다. “항상 동일”을 전제로 시스템을 짜기보다, 재현 가능한 조건을 기록하고 깨졌을 때 탐지·대응하는 쪽이 현실적이다.

결론

AI 추천의 일관성은 도덕성 문제라기보다 시스템 특성에 가깝다. 비결정성을 전제로 반복 테스트, 지시 템플릿, 근거 요구, seed/system_fingerprint 같은 재현성 장치를 묶으면 사용자가 추천을 다루는 조건을 더 분명히 만들 수 있다. 추천이 바뀌는 순간 중요한 것은, 그 이유가 조건 변화로 설명되는지, 아니면 결론만 바뀌는지다.

다음으로 읽기


참고 자료

공유하기:

업데이트 받기

주간 요약과 중요한 업데이트만 모아서 보내드려요.

오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.