Benchmarking Coding Agents on New vs Legacy Codebases — Denys Linkov, Wisedocs

한 줄 핵심

레거시 다중 저장소를 모노레포로 리팩터링한 사례를 통해, 코딩 에이전트와 하네스는 크게 좋아졌지만 복잡한 코드베이스의 대규모 변경은 여전히 검증·가드레일·평가가 있어야만 안전하게 수행된다는 점을 보여준다.

시간별 요약

1. 0:01
   의료 청구서처럼 초대형 PDF를 처리하는 AI 파이프라인은 고객 증가 속도를 따라가지 못하고, 수정이 어렵고, 레거시 저장소가 많아 누구도 건드리기 싫은 상태가 되기 쉽다. 이런 상황에서 6개월 리팩터링이 필요한지 판단하는 것이 이번 발표의 출발점이다.
2. 2:01
   기술 부채는 단순한 나쁜 코드가 아니라, 기능 출시와 고객 확보로 얻는 ROI를 복잡성과 유지보수 비용이 잠식하는 문제로 봐야 한다. 최근 AI 엔지니어링 사례처럼 속도는 빨라졌지만, 제품 신뢰성과 코드 유지보수성은 자동으로 좋아지지 않기 때문에 평가 기준을 엄격하게 가져가야 한다.
3. 5:01
   초기 리팩터는 수작업과 제한된 도구로는 몇 시간에 걸쳐 진행됐고, 많은 수정과 개입이 필요했다. 반면 Sonnet 4.6과 Opus 4.8 같은 최신 모델은 더 적은 반복과 더 많은 도구 호출로 같은 작업을 훨씬 빠르게 처리해, 모델 성능과 하네스가 함께 좋아졌음을 보여준다.
4. 7:00
   에이전트 작업은 성공률 50%보다 90%~99% 수준의 신뢰성을 기준으로 설계해야 실제 생산성 향상으로 이어진다. 계획, 사양, 검증이 부실하면 긴 실행 시간 자체가 낭비가 되므로, 장시간 태스크일수록 정확한 요구사항과 종료 조건이 중요하다.
5. 10:02
   10개 이상의 저장소를 모노레포로 합친 뒤에는 개발 속도와 기여자 수가 모두 증가했고, 기존에는 몇 달 걸리던 기능도 일주일 이내에 배포할 수 있게 됐다. 다만 GPT 5.5 extra high 같은 최신 모델도 아직은 스캐폴딩만 만들고 실제 모델 구현과 검증을 놓칠 수 있어, 대규모 리팩터는 자동화만 믿기보다 인간 리뷰와 점진적 가드레일이 필요하다.

실무 인사이트

• 대규모 리팩터는 '지금 당장'의 생산성 손실만 보지 말고, 고객 요구 대응 속도·비용·기여자 진입장벽까지 포함한 총비용으로 판단해야 한다.
• 코딩 에이전트를 쓸수록 프롬프트보다 중요한 것은 검증 체계이며, 계획 모드·샌드박스·PR 리뷰 같은 가드레일이 성패를 좌우한다.
• 모노레포 전환은 코드 구조만 바꾸는 일이 아니라, 검색·빌드·배포·검증 흐름을 단순화해 에이전트 활용 가능성을 함께 높이는 선택이다.