벤치마크 점수와 현장의 온도차
요즘 새 AI 모델이 나오면 꼭 따라붙는 숫자가 있죠. SWE-bench Verified 몇 퍼센트. 이게 뭐냐면, 깃허브의 유명 오픈소스 프로젝트(장고, 사이킷런, sympy 같은)에서 실제 있었던 이슈를 가져와서, AI에게 '이 버그 고쳐봐'라고 시킨 뒤 기존 테스트가 통과하는지 채점하는 벤치마크예요. 최근 상위 모델들은 이 점수가 상당히 높아져서, 숫자만 보면 '이제 AI가 개발자 대신 이슈 다 처리해주겠네' 싶을 정도예요.
그런데 실제로 회사에서 AI 코딩 에이전트를 써 보신 분들은 체감이 다르다고 하세요. 오픈소스 라이브러리를 만질 때는 잘하는데, 우리 회사 내부 코드로 들어오면 갑자기 헤매기 시작한다는 거죠. Specific이라는 회사가 공개한 Real-SWE는 정확히 이 간극을 재기 위한 벤치마크예요. 공개 깃허브 저장소가 아니라, 실제 기업이 운영 중인 비공개 코드베이스에서 AI 모델의 성능을 측정하는 게 핵심이에요.
왜 공개 저장소 벤치마크는 한계가 있을까
첫 번째 문제는 오염(contamination)이에요. SWE-bench에 들어 있는 저장소들은 전부 공개 깃허브에 있고, 대형 언어 모델은 대부분 깃허브 공개 코드를 학습 데이터로 씁니다. 그러니까 모델이 문제를 '푸는' 게 아니라 학습 중에 봤던 수정 커밋을 '기억해내는' 것일 가능성을 완전히 배제하기 어려워요. 시험 문제가 교과서에 그대로 실려 있는 상황과 비슷하죠.
두 번째 문제는 코드의 성격이에요. 벤치마크에 들어가는 오픈소스 프로젝트들은 문서화가 잘 돼 있고, 테스트 커버리지가 높고, 코드 컨벤션이 일관되고, 커뮤니티가 리뷰를 거친 코드예요. 반면 실제 기업 코드는 어떤가요? 10년 된 레거시 모듈, 회사에서만 쓰는 내부 프레임워크, 주석은 있는데 코드랑 안 맞는 문서, 테스트는 절반만 있고, 같은 기능이 세 곳에 복붙되어 있는 그런 코드요. AI가 진짜로 쓸모 있으려면 바로 이런 환경에서 잘해야 하는데, 기존 벤치마크는 이걸 거의 측정하지 못했어요.
Real-SWE는 어떻게 다르게 접근하나
Real-SWE의 접근은 단순하면서도 실행하기는 어려운 방식이에요. 실제 기업들과 협력해서 그 회사의 비공개 저장소에서 실제 발생한 작업(이슈, 티켓, 기능 요청)을 가져오고, 그 코드베이스 안에서 AI 에이전트를 돌려서 결과를 평가하는 거예요. 학습 데이터에 들어갔을 리 없는 코드니까 오염 문제가 원천적으로 사라지고, 코드의 성격도 진짜 현장 그대로죠.
물론 트레이드오프도 있어요. 비공개 코드라서 문제 세트를 외부에 공개할 수 없으니, 다른 연구자가 똑같이 재현해 보기 어렵다는 점이에요. 벤치마크의 생명은 재현성과 투명성인데, 그걸 일부 포기하는 대신 현실성을 얻은 셈이죠. 그래서 이런 벤치마크는 '절대 점수'보다는 모델 간 상대 비교와 공개 벤치마크 대비 얼마나 떨어지는지를 보는 용도로 읽는 게 맞아요. 일반적으로 이런 종류의 실측에서는 공개 벤치마크에서 잘하던 모델들도 점수가 눈에 띄게 낮아지고, 모델 간 순위가 뒤바뀌는 경우도 생겨요. 결국 '우리 회사 코드에서 진짜 잘하는 모델'은 리더보드 1위와 다를 수 있다는 얘기예요.
업계 흐름 속에서 보면
코딩 벤치마크의 역사는 계속 '더 현실에 가깝게'로 움직여 왔어요. 처음엔 HumanEval처럼 함수 하나 짜는 문제였다가, SWE-bench가 실제 저장소 단위 이슈 해결로 올렸고, SWE-bench Verified는 사람이 검수해서 애매한 문제를 걸러냈어요. 이후 Scale AI의 SWE-bench Pro는 상업용 비공개 저장소 일부를 포함시켰고, Terminal-Bench 같은 건 터미널 환경에서 에이전트가 실제로 명령을 실행하는 능력을 봐요. Real-SWE는 이 흐름의 가장 끝, '완전히 비공개인 기업 코드'까지 간 시도라고 보시면 돼요.
이건 벤치마크 회사만의 관심사가 아니에요. AI 코딩 도구를 파는 회사들 입장에서도 '우리 도구가 진짜 기업 코드에서 얼마나 잘하나'를 증명해야 계약이 되니까, 앞으로 이런 종류의 사설 평가가 점점 늘어날 거예요.
한국 개발자에게 주는 시사점
한국 기업 코드베이스는 Real-SWE가 지적하는 '현실'의 극단에 가까운 경우가 많아요. 전자정부 프레임워크 기반의 대형 SI 프로젝트, 스프링 레거시에 회사 자체 공통 모듈이 얹힌 구조, 한글 주석과 영어 변수명이 섞인 코드, 테스트 없이 운영으로 나가는 배포. 이런 환경에서 AI 에이전트가 얼마나 도움이 될지는 공개 벤치마크 점수로는 전혀 알 수 없어요.
그래서 실무적으로 드리고 싶은 제안은 이거예요. AI 코딩 도구를 도입하기 전에, 우리 회사 코드로 작은 자체 벤치마크를 만들어 보세요. 최근 6개월간 해결한 이슈 중 20~30개를 골라서, AI 에이전트에게 풀게 하고 기존 테스트나 리뷰 기준으로 채점하는 거예요. 거창할 필요 없어요. 이렇게 해 보면 어떤 모델이, 어떤 종류의 작업에서, 어느 정도 신뢰할 수 있는지가 리더보드보다 훨씬 정확하게 보여요. Real-SWE가 하는 일을 사내 규모로 축소해서 하는 셈이죠.
또 하나, AI가 우리 코드에서 헤매는 이유를 관찰해 보면 코드베이스의 문제가 드러나기도 해요. 문서와 코드가 안 맞거나, 모듈 경계가 불분명하거나, 테스트가 없어서 검증이 안 되는 지점들이요. AI를 잘 쓰기 위한 준비가 결국 코드베이스 건강을 좋게 만드는 일과 같더라고요.
마무리
한 줄 정리: 공개 벤치마크 점수는 AI 코딩 능력의 상한선을 보여주고, Real-SWE 같은 비공개 기업 코드 평가는 현실의 하한선을 보여줘요. 도입 결정은 하한선을 보고 해야 하고요.
여러분 회사 코드에서 AI 코딩 도구는 얼마나 잘 작동하나요? 오픈소스 만질 때와 사내 코드 만질 때 체감 차이가 있으셨는지, 그 차이는 주로 어디서 왔다고 느끼셨는지 이야기 나눠 봐요.
🔗 출처: Hacker News