제미나이 성능 저하 이슈

사람들이 실제로 뭐라고 하나

먼저 신고된 것부터 봅니다. 2026년 4월 이후 구글 AI 개발자 포럼에 쌓인 글을 기계적으로 확인 가능한 것과 그렇지 않은 것으로 갈라 보면 이렇게 됩니다.

위 두 줄은 고칠 수 있는 문제입니다. 아래 세 줄이 이 조각이 다루려는 것입니다 — 확실히 느껴지는데 숫자가 안 붙는 쪽. 여기서부터는 “정말 나빠졌나”를 묻지 않고, 무엇이 그 느낌을 만드는가를 하나씩 셉니다. 첫 번째가 제일 뜻밖입니다 — 가장 유명한 “AI가 나빠졌다”는 증거부터가 그것을 잰 게 아니었습니다.

① 가장 많이 인용된 증거가 잰 것

2023년, 스탠퍼드와 버클리 연구진이 “같은 이름의 모델이 몇 달 사이에 달라진다”는 논문을 냈습니다. 가장 널리 퍼진 숫자가 이것입니다 — 소수 판별 정확도가 3월 84%에서 6월 51%로 떨어졌다. 기사 제목이 되기에 완벽한 숫자였습니다.

그런데 프린스턴의 아르빈드 나라야난과 사야시 카푸어가 시험지를 열어 봤습니다. 문제는 500개, 전부 “이 수가 소수입니까?” 형식이었고 — 500개가 전부 소수였습니다. 3월 모델은 거의 항상 “소수”라고 답했고, 6월 모델은 거의 항상 “합성수”라고 답했습니다. 그러니 이 시험지에서 3월 모델이 이기는 것은 당연합니다. 실력과 무관합니다.

두 사람이 합성수 500개로 같은 시험을 다시 치자 그림이 뒤집혔습니다. 위 판에서 “전부 합성수”를 눌러 보세요 — 같은 두 모델의 등수가 바뀝니다. 논문이 보인 것은 행동이 바뀌었다는 사실이고, 많은 기사가 그것을 능력이 떨어졌다로 옮겼습니다. 둘은 같은 말이 아닙니다.

② 이름은 그대로인데 뒤가 바뀐다

이건 추측이 아니라 회사가 문서에 적어 둔 것입니다. 제미나이 API 문서는 별칭과 고정 이름을 구분합니다. gemini-flash-latest 같은 별칭에 대해 문서는 이렇게 적습니다 — 새 판이 나올 때마다 그 뒤의 모델이 갈아 끼워진다(hot-swap).

여기서 중요한 것은 이것이 부정이 아니라는 점입니다. 별칭은 원래 그러라고 있는 물건이고, 문서에 그렇게 적혀 있습니다. 다만 대부분의 사람은 별칭을 쓰고, 문서를 안 읽습니다. 그 사람에게 세상은 이렇게 보입니다 — 어제 되던 게 오늘 안 된다.

“조용한 강등”은 성격이 다릅니다. 이건 문서에 없고, 개발자 포럼의 신고로 존재합니다. 2026년 4월 이후 구글 AI 개발자 포럼에 올라온 글들 가운데 기계적으로 확인 가능한 항목은 무한 로딩, 빈 화면, 그리고 할당량 초과 시 더 약한 등급으로 조용히 내려가는데 오류 표시가 없다는 것이었습니다. 나머지 — 추론이 나빠졌다, 환각이 늘었다 — 는 숫자가 붙어 있지 않습니다. 그게 이 조각이 다루려는 바로 그 틈입니다.

③ 한 사람은 회귀를 알아볼 수 없다

순위표에서 한 칸 차이는 보통 10–40 Elo입니다. 30 Elo를 승률로 바꾸면 54.3% 대 45.7% — 열 번 붙어 다섯 번과 네 번입니다. 한 번 물어봐서는 절대 못 느낍니다.

그걸 통계로 말하려면 831번을 나란히 비교해야 합니다(유의수준 5%, 검정력 80%). 하루에 스무 번씩 물어도 42일입니다. 아무도 그렇게 안 합니다. 그래서 “나는 오히려 좋아졌던데”와 “확실히 나빠졌다”가 동시에 참일 수 있습니다 — 둘 다 표본이 없기 때문입니다.

위 판 아래쪽에서 그 승률의 동전을 실제로 던지고 있습니다. 보고 있으면 한 가지가 더 보입니다 — 계속 들여다보면 우연히 한 번은 문턱을 넘습니다. 그 순간을 붙잡아 “봐, 증명됐다”고 하면 틀립니다. 몇 번 볼지를 미리 정해 놓아야 합니다.

④ 게시판은 실제보다 부풀어 보인다

기계가 둘 더 있습니다. 둘 다 모델 바깥에 있습니다.

하나 — 만족한 사람은 글을 안 씁니다. 잘 되면 그냥 씁니다. 불만인 사람이 글 쓸 확률이 만족한 사람의 스무 배라면, 실제 불만이 열에 하나여도 게시판에서는 열에 일곱으로 보입니다. 위 판에서 글 쓸 사람을 매번 실제로 뽑고 있는데, 쌓일수록 그 값에 붙습니다.

둘 — 내 기준선이 올라갑니다. 처음엔 놀라웠던 것이 반년 뒤엔 당연해집니다. 답의 품질 분포를 한 글자도 안 건드리고 만족 문턱만 0.3σ 올리면 불만율이 15.9%에서 24.2%로 오릅니다. 모델은 그대로인데 불만이 1.5배입니다.

⑤ 그래서 무엇을 먼저 의심하나 — 다섯 갈래

여기까지가 “왜 그렇게 느껴지나”였습니다. 이제 내 경우엔 무엇이었나를 가릅니다. 아래는 위 판 넷을 순서로 세운 것입니다 — “아니오”로 빠지는 자리가 곧 원인이고, 다섯을 다 지나야 비로소 회귀를 의심할 값이 생깁니다.

이 다섯을 통과한 신고는 다른 신고와 성질이 다릅니다 — 재현되고, 남의 계정에서도 나고, 고정 이름에서도 나고, 시험지가 쏠리지 않았고, 표본이 있습니다. 게시판에 올라오는 글의 대부분은 두 번째 칸에서 갈립니다.

⑥ 풀고 있는 식 — 네 줄

네 줄 모두 모델을 건드리지 않습니다. 그런데 넷 다 “나빠졌다”를 만들어 냅니다. 이게 이 조각의 요지입니다 — 체감 저하의 상당 부분은 모델 바깥에서 생깁니다. 그리고 바로 그 이유로, 진짜 회귀가 섞여 있어도 구별이 안 됩니다.

⑦ 요청 하나가 지나는 길 — 돌려 본다

“모델이 나빠졌다”고 할 때, 사람들은 가중치를 떠올립니다. 그런데 내 질문이 답으로 바뀌기까지 지나는 층은 여럿이고, 가중치는 그중 하나입니다. 나머지 층은 모델을 그대로 둔 채 언제든 바뀔 수 있습니다.

표의 “볼 수 있나” 칸은 일반 사용자 기준입니다. API로 고정 이름을 부르면 첫 줄은 해당하지 않습니다. 강등 항목은 회사 발표가 아니라 개발자 포럼 신고가 근거입니다 — 그래서 표에 “신고 기준”이라고 적었습니다.

⑧ 그래서 무엇을 하면 되나

이 조각의 결론은 “착각이니 신경 쓰지 마라”가 아닙니다. 착각과 진짜를 가르는 방법이 있다는 쪽입니다. 셋뿐입니다.

하나 — 고정 이름을 부른다. 날짜나 판 번호가 박힌 이름을 쓰면 뒤가 안 바뀝니다. 별칭은 편하지만, 편한 대가로 ‘언제 바뀌었는지 모른다’를 삽니다.

둘 — 내 과제로 시험지를 만들어 둔다. 남의 벤치마크가 아니라 내가 실제로 시키는 일 20~30개를 적어 두고 답을 저장해 둡니다. ①판이 보여 준 것처럼 시험지를 잘못 만들면 없는 하락이 보이니, 정답이 한쪽으로 쏠리지 않게 섞습니다.

셋 — 한 번으로 판정하지 않는다. ③판의 숫자가 그 이유입니다 — 순위표 한 칸 차이를 개인이 확인하려면 수백 번이 필요합니다. 한 번 나쁜 답을 받았을 때 옳은 결론은 “모델이 나빠졌다”가 아니라 “다시 물어보자”입니다. 그런데 같은 답이 스무 번 나쁘면 그때는 세어 볼 값이 있습니다.

⑨ 이 조각이 딛고 선 자료 넷

위 계산은 전부 제가 화면에서 푼 것이고, 사실 관계는 아래 넷에서 왔습니다. 제목과 한 줄 요지, 그리고 링크만 옮깁니다 — 원문은 눌러서 보세요.

넷 중 셋은 1차 자료(논문·공식 문서·원 글타래)이고, 반론 한 편만 2차입니다. 기사에서 옮긴 숫자는 하나도 쓰지 않았습니다 — ①판이 보인 것이 정확히 “기사로 옮겨지며 뜻이 바뀌는” 사례이기 때문입니다.