벤치마크 점수는 사상 최고인데, 왜 코드는 '슬롭'일까

먼저 솔직하게 말씀드립니다. 이번 주제로 최근 30일치 커뮤니티 데이터를 훑어봤는데, “SlopCodeBench"라는 이름의 공개 벤치마크를 놓고 오간 이야기를 찾지 못했습니다. 레딧 검색 결과는 0건이었고, X 연동도 인증 문제로 막혀 있었습니다. 그래서 이 글은 특정 벤치마크의 측정 결과를 전하는 글이 아닙니다. 대신 그 이름이 왜 나왔는지를 다뤄보려 합니다. “점수는 오르는데 코드는 왜 슬롭이냐”는 질문 말입니다. 이 질문은 데이터가 없어도 충분히 뜨겁거든요.

‘슬롭’이라는 단어가 코드로 넘어왔습니다

원래 슬롭(slop)은 AI가 대량 생산한 저품질 텍스트와 이미지를 가리키는 말이었습니다. 문법은 멀쩡하고 문단 구성도 그럴듯한데 읽고 나면 아무것도 안 남는 글 말입니다. 이 단어가 작년부터 코드에도 붙기 시작했습니다.

슬롭 코드의 정의는 대충 이렇습니다. 컴파일됩니다. 테스트도 통과합니다. 리뷰어가 세 번째 파일쯤 열었을 때 뭔가 잘못됐다는 걸 깨닫습니다. 이미 있는 유틸 함수를 모르고 새로 만들었고 방어 코드가 필요 없는 자리에 try-catch가 붙어 있고 주석은 코드를 그대로 한 번 더 설명합니다. 개별 줄은 다 맞는데 전체가 남의 코드베이스에서 이식해온 것처럼 겉돕니다.

헷갈리면 안 되는 게 하나 있습니다. 슬롭은 “틀린 코드"가 아닙니다. 틀린 코드는 테스트가 잡습니다. 슬롭은 맞는 코드인데 그 자리에 있으면 안 되는 코드입니다.

벤치마크가 측정하는 건 ‘작동 여부’입니다

여기서 벤치마크와 현실의 간극이 생깁니다. SWE-bench 계열 벤치마크의 채점 방식을 보면 이유가 분명합니다. 실제 GitHub 이슈를 주고 모델이 패치를 만들면 원래 저장소의 테스트 스위트를 돌립니다. 통과하면 1점, 실패하면 0점입니다.

이 방식은 훌륭합니다. 객관적이고 자동으로 돌아갑니다. 점수를 속이기도 어렵고요. 문제는 이 채점표에 테스트가 통과하는 방식을 재는 칸이 없다는 겁니다. 500줄짜리 패치로 통과해도 1점이고 3줄로 통과해도 1점입니다. 기존 추상화를 재사용해도 1점, 완전히 새로운 추상화를 세 개 만들어도 1점입니다. 6개월 뒤 유지보수 담당자가 울어도 1점입니다.

Opus 5든 다른 최신 모델이든, 벤치마크에서 높은 점수를 받는다는 건 “이슈를 해결하는 패치를 만들 수 있다"는 뜻입니다. “그 코드베이스에 어울리는 패치를 만든다"는 뜻이 아닙니다. 둘은 상관관계가 높아도 같은 말이 아닙니다. 실무자가 체감하는 불만은 정확히 그 차이에서 나옵니다.

그래서 슬롭은 모델 문제가 아니라 컨텍스트 문제입니다

여기가 제일 자주 오해받는 부분입니다. 슬롭 코드를 모델의 능력 부족으로 설명하면 답이 안 나옵니다. 실제로는 모델이 알아야 할 걸 못 받은 상태인 경우가 훨씬 많습니다.

사람 신입 개발자를 생각해보면 쉽습니다. 첫 주에 온보딩 없이 티켓을 던져주면 어떻게 될까요. 똑똑한 사람이어도 이미 있는 헬퍼를 모르고 새로 짤 겁니다. 팀이 3년 전에 버린 패턴을 되살릴 겁니다. 나쁜 개발자라서가 아니라 맥락이 없어서입니다.

AI 에이전트도 똑같습니다. 다른 점이라면 사람은 옆자리에 물어보는데 모델은 안 물어봅니다. 그리고 사람은 하루에 한 번 실수하지만 모델은 10분에 한 번 커밋합니다. 같은 원인이 훨씬 빨리 쌓이는 겁니다.

실무에서 효과를 본 대응은 대부분 컨텍스트 쪽입니다. 프로젝트 규약을 CLAUDE.md 같은 파일에 적어둡니다. 에이전트가 코드를 짜기 전에 관련 파일부터 읽게 합니다. “이미 비슷한 함수가 있는지 먼저 찾아라"라고 대놓고 시킵니다. 이 정도만 해도 체감 품질이 확 달라집니다. 모델을 바꿔서가 아니라 입력을 바꿔서 얻는 개선입니다.

그런데 리뷰 비용이 새로운 병목입니다

다만 컨텍스트 엔지니어링만으로 다 해결되지는 않습니다. 밑바닥에서 하나가 더 바뀌었습니다.

예전에는 코드를 쓰는 게 느리고 읽는 게 빨랐습니다. 지금은 뒤집혔습니다. 생성은 거의 공짜인데 검토 속도는 그대로입니다. 하루에 2000줄이 올라오는데 사람이 꼼꼼히 읽을 수 있는 건 여전히 몇백 줄입니다. 이 격차가 슬롭이 코드베이스에 남는 진짜 통로입니다. 슬롭이 갑자기 늘어난 게 아니라 걸러낼 여력이 줄어든 겁니다.

여기서 좀 불편한 이야기를 하나 더 하자면, 리뷰어의 기준선도 같이 내려갑니다. 매일 그럴듯한 코드를 대량으로 보다 보면 “그럴듯함"이 통과 기준이 됩니다. 예전 같으면 걸렸을 게 안 걸립니다. 게을러진 탓이 아닙니다. 매일 보는 게 달라지면 눈금도 따라 움직입니다.

‘슬롭 벤치마크’를 만든다면 뭘 재야 할까

그러니 이런 걸 재는 벤치마크가 있으면 좋겠다는 발상은 말이 됩니다. 실제로 만든다면 뭐가 들어가야 할까요.

패치가 최소 필요 변경량보다 얼마나 부풀었는지. 새로 만든 함수가 이미 있던 함수와 얼마나 겹치는지. 이름 짓는 방식과 패턴이 기존 코드와 얼마나 맞아떨어지는지. 6개월 뒤 이 코드를 손볼 때 어디까지 건드려야 하는지. 그리고 사람 리뷰어가 이 패치를 승인하기까지 얼마나 걸리는지.

문제는 이게 다 자동 채점이 어렵다는 겁니다. 테스트 통과 여부는 기계가 0/1로 판정하지만 “이 코드가 이 코드베이스에 어울리는가"는 기계가 답을 못 냅니다. LLM에게 채점을 맡기면 LLM 취향에 맞는 코드가 고득점하고, 사람에게 맡기면 확장이 안 됩니다. 벤치마크가 여기까지 못 온 데는 이유가 있습니다. 정말 어려운 문제거든요.

점수와 체감이 갈리는 자리

벤치마크 점수와 실무 체감이 벌어지는 건 모델이 정체돼서가 아닙니다. 측정 대상과 불만 대상이 다를 뿐입니다. 벤치마크는 “돌아가는가"를 재고 실무자는 “이 코드랑 6개월을 같이 살 수 있는가"를 봅니다.

당분간 쓸 만한 개선은 모델 교체보다 컨텍스트 설계 쪽에서 나올 겁니다. 규약을 문서로 남기고 에이전트가 코드를 쓰기 전에 그걸 읽게 만드는 일. 리뷰 단위를 사람이 감당할 만한 크기로 자르는 일. 재미없지만 효과는 확실합니다.

질문 하나만 남기겠습니다. 지금 여러분 팀에 AI가 만든 PR이 올라온다면, 그걸 제대로 읽을 시간은 있습니까? 그 답이 없으면 모델을 아무리 바꿔도 코드베이스는 같은 방향으로 갑니다.