한 줄 고쳐달랬는데 300줄이 돌아왔다
AI 코딩 도구를 쓰다 보면 이런 일, 한 번쯤 겪어보셨을 거예요. 조건문 하나만 고쳐달라고 했는데 헬퍼 함수 세 개, 커스텀 에러 클래스, 로깅 코드에 친절한 주석까지 붙은 diff가 돌아오는 거요. 동작은 하는데, 리뷰하는 사람은 한숨부터 나오죠.
Parsimony는 바로 이 문제, AI 모델이 필요 이상으로 코드를 얼마나 덧붙이는지를 재는 오픈소스 벤치마크예요. 이름에도 그 뜻이 담겨 있어요. parsimony는 '절약', '간결함'이라는 뜻이에요. 과학에서는 같은 현상을 설명한다면 더 단순한 쪽을 택하라는 원칙(오컴의 면도날과 비슷한 개념)을 가리킬 때도 써요.
기존 벤치마크가 놓친 부분
코딩 AI를 평가하는 대표 벤치마크로는 HumanEval이나 SWE-bench가 있어요. 둘 다 기본적으로 테스트를 통과했는지를 봐요. 정답을 맞혔는지만 확인하고, 얼마나 깔끔하게 맞혔는지는 따지지 않아요.
수학 시험에 비유하면 이래요. 답은 맞았는데 풀이가 열 장인 답안지와 반 장인 답안지가 같은 점수를 받는 거예요. 시험이라면 상관없겠지만 코드는 다르잖아요. 그 열 장을 누군가 계속 읽고 고치고 관리해야 하니까요.
Parsimony는 여기에 '얼마나 적게 바꿨는가'라는 기준을 하나 더하려는 시도예요. 어떤 과제를 쓰는지, 어떤 지표로 재는지, 모델별 결과는 어떤지는 프로젝트 사이트에서 직접 확인해보세요. 보통 이런 측정에서는 추가된 줄 수, 손댄 파일 수, 새로 만든 함수나 추상화 수, 사람이 작성한 최소 정답과 비교한 diff 크기 같은 걸 봐요.
코드가 많으면 왜 문제일까
동작하면 된 거 아니냐 싶을 수도 있어요. 그런데 코드가 많으면 생각보다 비용이 커요.
먼저 리뷰 비용이 늘어요. 코드는 쓰는 시간보다 읽는 시간이 훨씬 길거든요. 20줄짜리 diff는 꼼꼼히 보지만, 300줄짜리 diff 앞에서는 집중력이 떨어져서 진짜 버그를 놓치기 쉬워요.
다음은 유지보수 부채예요. 아무도 호출하지 않는 방어 코드나 쓰이지 않는 옵션 파라미터는 몇 달 뒤 '이거 지워도 되나?' 하는 불안을 남겨요. 코드 한 줄 한 줄이 자산이 아니라 관리해야 할 부채라는 말이 괜히 있는 게 아니에요.
마지막으로 버그가 숨을 자리가 늘어나요. 코드가 많을수록 보안 취약점이나 엣지 케이스 버그가 끼어들 공간도 넓어지거든요. 실제로 GitClear의 분석에서도 AI 도구가 퍼진 뒤로 복사해 붙인 중복 코드는 늘고, 리팩터링으로 정리되는 코드 비율은 줄어드는 경향이 나타났어요.
AI는 왜 이렇게 많이 쓸까
몇 가지 이유가 겹쳐 있어요. 모델은 완성도 있어 보이는 답을 선호하도록 학습되다 보니 방어 코드를 과하게 넣는 경향이 있어요. 코드베이스 전체 맥락을 모르면 이미 있는 유틸 함수를 두고 비슷한 함수를 새로 만들기도 해요. 여기에 도움이 되고 싶어 하는 성향까지 더해져서, 요청하지 않은 개선까지 슬쩍 끼워 넣는 거예요.
업계 흐름에서의 의미
Claude Code, Codex, Cursor 같은 코딩 에이전트 경쟁은 지금까지 주로 정답률 경쟁이었어요. 그런데 상위 모델들의 정답률이 비슷해질수록 실무에서는 정답이 같다면 diff가 작은 쪽이 더 좋은 도구예요. Parsimony 같은 벤치마크는 정확도와 간결함을 함께 보자고 제안하는 셈이에요.
물론 짧다고 무조건 좋은 건 아니에요. 꼭 필요한 에러 처리까지 빼먹으면 간결한 게 아니라 부실한 거니까요. 정확성은 지키면서 군살만 빼는 균형을 이 벤치마크가 어떻게 잡는지 앞으로 지켜볼 만해요.
당장 써먹을 실무 팁
벤치마크 결과를 기다리지 않아도 팀에서 바로 해볼 수 있는 것들이 있어요. 먼저 프롬프트에 '요청한 부분만 최소한으로 수정하고, 새 파일이나 새 추상화는 만들지 말 것'처럼 범위를 분명히 적어보세요. 이런 규칙을 CLAUDE.md나 AGENTS.md 같은 프로젝트 규칙 파일에 넣어두면 매번 말하지 않아도 돼요. knip이나 vulture처럼 안 쓰는 코드를 찾아주는 정적 분석 도구를 CI에 붙여두면 군살이 쌓이는 것도 막을 수 있어요. 모델을 고를 때는 정답률과 함께 평균 diff 크기도 보는 습관을 들여보세요.
마무리
한 줄 정리: 좋은 코드는 동작하는 코드 중에서도 가장 적게 바꾼 코드인 경우가 많아요.
AI가 만든 코드를 리뷰할 때 가장 자주 지우는 건 뭔가요? 과한 예외 처리인가요, 불필요한 추상화인가요?
🔗 출처: Hacker News