TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 31 READS

'돌아가는 코드'와 '좋은 코드'는 달라요 — 슬롭 코드를 측정하는 SlopCodeBench

'돌아가는 코드'와 '좋은 코드'는 달라요 — 슬롭 코드를 측정하는 SlopCodeBench
SOURCE IMAGE · HACKER NEWS
'돌아가는 코드'와 '좋은 코드'는 달라요 — 슬롭 코드를 측정하는 SlopCodeBench

AI가 짠 코드, 테스트만 통과하면 끝일까요

코딩 에이전트한테 기능 구현을 맡겨 본 분이라면 한 번쯤 겪어봤을 거예요. 테스트는 다 통과하는데 코드를 열어보면 한숨이 나오는 상황이요. 필요 없는 추상화 레이어가 세 겹쯤 쌓여 있고, 어디서도 안 쓰는 헬퍼 함수가 굴러다니고, try-catch가 온 사방에 도배돼 있는 코드. 이런 걸 요즘 영어권에서는 '슬롭(slop)'이라고 불러요. 원래는 돼지 여물통에 붓는 잔반을 뜻하는 말인데, AI가 대량으로 쏟아내는 저품질 결과물을 가리키는 말로 자리 잡았죠.

코딩 에이전트 도구를 만드는 HumanLayer 팀이 이 문제를 정면으로 다루는 벤치마크인 SlopCodeBench로 Anthropic의 새 모델 Opus 5를 평가한 글을 공개했어요. 이 팀은 '컨텍스트 엔지니어링'에 관한 자료를 꾸준히 내온 곳이라, 결과 못지않게 관점 자체가 흥미로운데요. 오늘은 그 얘기를 해볼게요.

기존 벤치마크의 사각지대

SWE-bench 같은 유명 코딩 벤치마크는 기본적으로 '문제를 풀었느냐'를 봐요. 실제 오픈소스 저장소의 이슈를 주고, 에이전트가 만든 패치가 테스트를 통과하면 성공으로 치는 방식이죠. 그런데 여기엔 함정이 있어요. 테스트 통과는 코드 품질의 하한선이지 상한선이 아니거든요. 실무 코드 리뷰에서 우리가 따지는 것들, 그러니까 '이 변경이 기존 코드 스타일과 어울리는가', '불필요하게 범위를 넓히지 않았는가', '나중에 유지보수할 사람이 이해할 수 있는가' 같은 건 전혀 측정이 안 돼요.

그래서 모델들의 벤치마크 점수는 계속 오르는데 현업 개발자들의 체감 품질은 그만큼 안 오르는 괴리가 생겨요. 슬롭 코드를 측정하는 벤치마크는 바로 이 틈을 겨냥한 거예요. 정답 여부만이 아니라 결과물이 얼마나 '사람이 짠 좋은 코드'에 가까운지, 과잉 구현이나 군더더기가 얼마나 섞여 있는지를 평가 축으로 삼는 거죠. 새 모델이 나올 때마다 이런 잣대로 검증해 보는 문화가 생기고 있다는 것 자체가 의미 있는 변화예요.

왜 에이전트는 슬롭을 만들까요

원인을 알면 대응도 보여요. 첫째, 모델은 '안전하게 많이' 쓰는 쪽으로 기울어요. 요구사항이 애매하면 사람은 질문을 하지만, 에이전트는 일단 온갖 경우를 다 처리하는 코드를 쏟아내는 경향이 있거든요. 둘째, 컨텍스트 문제예요. 프로젝트의 기존 구조나 컨벤션을 충분히 읽지 못한 상태에서 코드를 생성하면, 그 저장소의 결에 맞지 않는 '어디서 본 듯한 평균적인 코드'가 나와요.

HumanLayer 팀이 강조해 온 컨텍스트 엔지니어링이 바로 이 지점을 다루는 기술이에요. 이게 뭐냐면, 에이전트에게 어떤 정보를 어떤 순서와 형태로 보여줄지 설계하는 일이에요. 무작정 파일을 다 들이붓는 게 아니라, 계획을 먼저 세우게 하고, 관련 코드만 압축해서 보여주고, 작업을 잘게 쪼개는 식으로요. 같은 모델이라도 컨텍스트 설계에 따라 결과물 품질이 크게 달라진다는 게 이들의 핵심 주장이죠.

업계 흐름에서 보면

평가의 무게중심이 '능력'에서 '품질'로 옮겨가는 신호로 읽을 수 있어요. 사람 채용으로 치면, 알고리즘 문제 풀이만 보던 시대에서 코드 리뷰와 협업 능력을 보는 시대로 넘어가는 것과 비슷해요. 모델 회사들도 이제 단순 정답률이 아니라 '지시를 벗어나지 않는가', '필요 이상으로 손대지 않는가'를 내세우기 시작했고요.

한국 개발자에게는

당장 써먹을 수 있는 교훈이 있어요. 에이전트에게 일을 시킬 때 '구현해 줘' 한 줄로 끝내지 말고, 먼저 계획을 세우게 하고 그 계획을 사람이 검토한 뒤 구현시키는 것만으로도 슬롭이 눈에 띄게 줄어요. CLAUDE.md 같은 프로젝트 규칙 파일에 '기존 컨벤션을 따를 것', '요청 범위 밖의 코드는 건드리지 말 것'을 명시하는 것도 효과가 크고요. 팀에 AI 생성 코드가 늘고 있다면, 리뷰 기준을 '돌아가느냐'에서 '우리 코드베이스에 어울리느냐'로 명확히 세워두는 게 기술 부채를 막는 길이에요.

정리하면

테스트 통과율만으로는 코딩 에이전트를 평가할 수 없고, 이제는 코드의 '결'을 측정하려는 시도가 벤치마크로 구체화되고 있어요. 여러분 팀은 AI가 만든 코드를 어떤 기준으로 리뷰하고 계세요? 슬롭을 걸러내는 나만의 노하우가 있다면 공유해 주세요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/humanlayer/advanced-context-engineering-f...
SHARE
처리 중...