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

URL: https://www.youtube.com/watch?v=7vn4WpqNpck 날짜: 2026-08-09 채널: aiDotEngineer 발표자: Denys Linkov (Wisedocs CTO)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI 코딩 에이전트의 성능이 급격히 향상되고 있지만, ==레거시 코드베이스(10개 이상의 저장소로 구성된 복잡한 AI 파이프라인)를 지금 리팩토링하는 것이 옳은 결정인가, 아니면 더 강력한 모델이 나올 때까지 기다리는 것이 나은가?== 하는 질문에 답한다.

• Wisedocs는 10,000페이지가 넘는 PDF 의료 청구 서류를 처리하는 복잡한 애플리케이션을 운영 중
• 세 가지 위기: 고객 수요 대응이 느림, AI 파이프라인 업데이트가 너무 복잡함, 레거시 저장소를 아무도 건드리려 하지 않음
• 6개월에 걸친 모노레포(monorepo) 리팩토링을 직접 실행하고, 그 결과를 코딩 에이전트 벤치마크와 연결해 분석
• 결론: 코딩 에이전트가 빠르게 발전하고 있지만, 기술 부채(technical debt)가 비즈니스를 방해할 때는 지금 리팩토링하는 것이 가치 있다

---

1. Wisedocs의 사용 사례와 리팩토링 결정 배경

이 섹션에서는 발표자가 다니는 Wisedocs라는 회사의 사업적 맥락과 리팩토링을 결정하게 된 세 가지 이유를 설명한다.

1.1. Wisedocs가 다루는 문제의 복잡성

1. 의료 청구 서류 처리

   1. 초대형 PDF: Wisedocs는 10,000페이지가 넘는 복잡한 의료 청구 서류(PDF)를 처리한다
   2. 비디오보다 큰 파일: 일부 파일은 비디오 파일보다 용량이 크다고 언급
   3. 다중 ML 모델 파이프라인: 여러 머신러닝 모델로 구성된 파이프라인을 운영하며, 각 부분을 확장하는 것이 결코 간단하지 않음

2. 2025년의 위기 상황

   1. AI 파이프라인이 불타고 있음: 발표자는 "AI 파이프라인뿐만 아니라 파워포인트도 불타오르고 있다"며 위기감을 표현
   2. 사업 규모 확장 중 문제 발생: 고객이 너무 많이 늘어나고 있지만, 필요한 처리량(throughput)을 얻지 못하고 있음
   3. 기본 기술 개선 필요: 기저 기술을 개선해야 한다는 판단이 섬

1.2. 리팩토링을 결정한 세 가지 이유

1. 첫 번째 이유: 고객 수요 대응 속도 부족

   1. 고객 수요를 충족하기에는 조직이 너무 느리다고 판단
   2. 제품 개발과 배포 속도가 비즈니스 성장을 따라가지 못함

2. 두 번째 이유: AI 파이프라인의 복잡성

   1. 구축한 AI 파이프라인이 너무 복잡해서 업데이트하기 어려움
   2. 작은 변경도 여러 컴포넌트에 영향을 미치는 구조

3. 세 번째 이유: 레거시 코드베이스의 두려움

   1. 10개 이상의 저장소(repository)로 구성된 레거시 코드베이스
   2. 아무도 코드를 건드리고 싶어하지 않는 상태 — "즐거운 경험이 아니다"
   3. 이로 인해 6개월에 걸쳐 리팩토링하기로 결정

1.3. 이 강연의 핵심 질문

1. 리팩토링이 옳은 조치였는가?
   1. 발표자는 6개월간의 리팩토링이 옳은 결정이었는지 질문 던짐
   2. 이 질문에 답하기 위해 기술 부채, AI 에이전트 발전, 실제 리팩토링 과정, 그리고 결과를 단계적으로 분석

---

2. 기술 부채(Technical Debt)와 AI 시대의 개발 패러다임

이 섹션에서는 기술 부채의 본질과 AI 공학(AI engineering)이 등장하면서 달라진 개발 환경, 그리고 더 빠르게 배포하면서도 품질이 떨어지는 현상을 다룬다.

2.1. 기술 부채의 본짠

1. 모두가 나쁜 코드를 작성한다

   1. 발표자는 개발자라면 누구나 나쁜 코드를 작성한 경험이 있다고 주장
   2. 본인도 15년 전 Java에서 System.out.println으로 이미지를 화면에 출력하려 했던 실수를 회상
   3. 중요한 것은 의도적이든 아니든 기술 부채가 축적된다는 사실

2. 기술 부채는 금융 부채처럼 복리로 작용한다

   1. 기술 부채는 예상치 못한 방식으로 복리(compound)된다
   2. 단순한 비유가 아니라 엄격하게 ROI 관점에서 접근해야 함
   3. 새 기능 추가나 고객 확보를 위해 기술 부채를 감수할 때, 그 ROI가 복잡성 증가보다 큰지 검증해야 함
   4. 그렇지 않으면 코드베이스 복잡성이 생성한 ROI를 금방 앞지르게 됨

2.2. AI 공학의 진보와 품질 저하 paradox

1. AI 코딩의 약진 사례

   1. Anthropic의 Spotify, Stripe 사례 연구를 인용
   2. 두 회사 모두 배송 속도(shipping velocity)와 리팩토링 능력에서 큰 진보를 보였다고 소개
   3. 이제 팀은 이전보다 훨씬 빠르게 코드를 작성하고 변경함

2. 빠른 배포 ≠ 더 나은 제품

   1. 발표자는 "지난 20년간 기술 제품이 더 나아졌다고 생각하는가?"라는 질문을 청중에게 던짐
   2. 스마트폰 등은 좋아졌지만, 전반적으로 고객 중심 제품 경험은 퇴화됐다고 주장
   3. 코드의 유지보수성과 신뢰성이 저하되고 있음
   4. 두 선도 기업의 가동 시간(uptime) 데이터를 흐릿하게 보여주며, 99.9%나 99.99% 신뢰성에 미치지 못함을 지적
   5. 결론: 더 빠르게 배포하지만, 코드와 제품 품질이 반드시 따라오는 것은 아님

---

3. Wisedocs의 5단계 리팩토링과 코딩 에이전트 벤치마크

이 섹션에서는 실제 리팩토링을 진행한 다섯 가지 작업과, 그 과정에서 다양한 AI 모델을 벤치마크한 결과를 상세히 설명한다.

3.1. 1단계: AI 파이프라인 오케스트레이터 평가

1. 평가 기간과 범위

   1. 약 2개월을 들여 AI 파이프라인용 오케스트레이터를 평가
   2. 5개의 오픈소스 프로젝트를 후보로 선정
   3. 17개의 평가 기준(criteria)을 직접 만들어 Confluence 문서에 정리
   4. Google/OpenAI의 딥리서치(deep research) 기능이 나오기 전이어서, 웹 검색을 통한 종합 분석이 아직 불가능했던 시점

2. 지금이라면 훨씬 빠르게 할 수 있다

   1. 발표자는 현재 도구로는 이 평가를 90% 더 빠르게 수행할 수 있다고 확신
   2. 에이전틱 워크플로우 구성: 딥리서치로 초기 조사 → 문제 진술(problem statements)과 매칭 → 각 기준/제품별 서브 에이전트 생성 → PoC(개념증명) 구축 및 평가
   3. 동시에 "AI 정신병(AI psychosis)" 경고: 20페이지짜리 딥리서치 보고서가 멋져 보여도 실제 제품에는 해당 기능이 없을 수 있음
   4. 따라서 동일한 품질 기준을 유지하면서도 속도를 높여야 함

3.2. 2단계: 초기 코드 커밋과 모델별 벤치마크

1. Temporal 실험과 o3 시절

   1. Temporal이라는 워크플로 엔진으로 PoC를 진행
   2. 레거시 코드베이스의 기능을 복제할 수 있는지 검증
   3. 당시 최신 모델이던 o3에 구현을 맡김
   4. Cursor에서 3시간가량의 대화 끝에 구현했지만, 10개의 주요 실수(major mistakes)를 저지름
   5. 이 시점의 코딩 에이전트는 아직 수동 개입과 안내, 코드 수동 편집/삭제가 필요한 수준이었음

2. 현대 모델로 재실험: Sonnet 4.6과 Opus 4.8

   1. 동일한 작업을 Sonnet 4.6과 Opus 4.8에 다시 실행
   2. Sonnet 4.6은 한 번의 추가 반복(additional iteration)으로 문제 해결
   3. Opus 4.8은 거의 원샷(oneshot)으로 동일한 문제 해결
   4. 모델과 하네스(harness) 모두 크게 발전했음을 확인

3. 에이전트 상호작용 방식의 변화

   1. 과거 o3는 특정 카테고리에서 상당한 도구 호출(tool call)이 없었음
   2. Sonnet 4.6과 Opus에서는 서브 에이전트(sub-agents), 플랜 호출(plan calls), 다양한 셸 명령, 검증 단계가 등장
   3. 실행 비용은 조금 더 들었지만 수동 개입이 훨씬 줄어듦
   4. 동일한 리팩토링 작업을 지금 다시 한다면 약 1/5 시간에 완료할 수 있다고 추정

3.3. 3단계: 모노레포 구조로의 전환

1. 10개 저장소 → 1개 모노레포

   1. 10개의 분산된 저장소를 하나의 모노레포(monorepo)로 통합
   2. 새 기능을 기존 구조 위가 아닌 통합된 구조 위에 쌓기로 결정

2. 개발 생산성의 극적 변화

   1. 이전 저장소는 6년 이상 운영되며 진행 속도가 매우 느렸음
   2. 일부는 기술 부채 때문이고, 일부는 AI 코딩 도구 부재 때문
   3. 재구축 후 첫 6개월 만에 기존 기능을 따라잡았고, 그 곡선의 가파름이 매우 컸음
   4. 기능을 계속 추가하면서도 속도가 늦춰지지 않음

3. 개발자 참여도 상승

   1. 커밋(commit)량과 개발자 참여가 로그 그래프로 가시적으로 증가
   2. 리팩토링/복제 단계에서는 초기에 커밋이 많았지만, 제품 기능 추가 단계로 넘어가면서도 속도 유지
   3. 거의 모든 개발자가 새 모노레포에 기여함 — 자신의 전문 분야가 아니더라도 스키마, API 호출, 스택의 다른 부분을 수정해야 하기 때문
   4. 개발자들이 "이 코드베이스에서 일하고 싶다"고 말할 정도로 깨끗해짐

3.4. 4단계: 최신 LLM의 제로샷 리팩토링 실험

1. GPT-5.5 extra high를 이용한 제로샷 시도

   1. 발표자는 "최신 LLM이 이 문제를 제로샷으로 해결할 수 있는가?"라는 질문을 던짐
   2. GPT-5.5 extra high에 저장소 이름과 내부 모델 및 구성 요소 정보를 주고 리팩토링 목표를 제시
   3. 모델은 10분 22초 만에 목표를 완료했다고 보고
   4. 그러나 생성된 코드는 단 2,000줄에 불과해 의심을 삼

2. 제로샷 결과의 한계

   1. 자세히 살펴보니 모델은 실제 모델 구현 없이 스캐폴딩(scaffolding)만 대량으로 생성
   2. Raiser deployment나 bootstrap 명령 등 핵심 부분이 누락됨
   3. 결론: 아직 모델이 자기 검증(self-validate)을 통해 대규모 리팩토링을 원샷으로 완료할 수 있는 단계는 아님
   4. 하지만 6개월 내에는 Stripe 사례처럼 상당한 리팩토링을 꾸준히 수행할 수 있게 될 것으로 전망

---

4. 리팩토링의 비즈니스 가치와 미래 전망

이 섹션에서는 리팩토링이 가져온 실제 성과, 그리고 기술 부채와 AI 에이전트 발전 사이의 트레이드오프를 종합적으로 정리한다.

4.1. 리팩토링의 실제 성과

1. 비즈니스 목표 달성

   1. 10개 이상의 저장소에서 축적된 패턴을 정리해 고객 요구사항과 수요에 맞춤
   2. 처음에는 시간이 걸렸지만 궁극적으로 비즈니스 목표를 달성

2. 성능 및 비용 개선

   1. 파이프라인 처리 시간 단축
   2. 운영 비용 감소
   3. 더 큰 파일 지원 가능

3. 배송 속도의 비약적 향상

   1. 과거에는 수 개월이 걸리던 기능을 일주일 이내에 출시할 수 있게 됨
   2. 모노레포 정리와 코드 품질 개선이 직접적인 생산성 향상으로 연결됨

4. 개발자 경험 개선

   1. 개발자들이 코드베이스에서 일하고 싶어함
   2. 새로 도입한 패턴이 회사 내 다른 저장소로 확산됨
   3. 전문 분야가 아닌 개발자도 기여할 수 있는 환경 조성

4.2. 리팩토링 시점에 대한 종합 판단

1. 반대 의견: 더 기다릴 수도 있었다

   1. 모델과 하네스가 기하급수적으로 발전하고 있음
   2. 도구 호출, 샌드박스, 모니터링 프레임워크 등 인프라가 많아지고 있음
   3. 따라서 기술 부채를 감수하고 나중에 리팩토링하는 것이 점점 쉬워지고 있음

2. 지금 리팩토링해야 하는 이유

   1. AI 네이티브 방식으로 빠르게 코드를 쌓으면 전통적인 레거시 코드처럼 변질될 위험
   2. 저품질이나 저성능 코드가 많아지고, 사람들이 실제로 어떤 일이 일어나는지 이해하지 못함
   3. 코드베이스 문제를 수정하거나 고객 요구사항에 맞춰 조정하는 것이 훨씬 어려워짐
   4. 따라서 전면 리팩토링이든 부분적 리팩토링이든 적절한 가드레일이 필요

3. 발표자의 최종 결론

   1. 리팩토링은 가치 있었다
   2. 비즈니스 목표를 달성한 뒤 재정비하여 가속화할 수 있었음
   3. 때로는 잠시 멈춰 모노레포를 구축하고 다시 전진하는 것이 필요
   4. AI 전달 시스템(AI delivery system)은 레이어드 접근법으로 격리할 수 있지만, 많은 구성 요소를 동시에 고려해야 함

---

5. Q&A: 리팩토링과 AI 에이전트 운영의 실무 질문

이 섹션에서는 발표 후 청중 질문에 대한 답변을 담고 있다.

5.1. 저장소 구조와 모노레포 선택

1. 질문: 여러 저장소를 모노레포로 옮겼는가?
   1. 답변: 예, 10개의 저장소를 하나의 모노레포로 통합
   2. 현재 모델은 여러 저장소를 더 잘 탐색할 수 있지만, 종단 간(end-to-end) 테스트·검증·배포는 여전히 여러 저장소에서 어려움
   3. 샌드박스 환경에서 전체 AI 팩토리를 실행하려 할 때도 여러 저장소를 클론하고 설정하는 데 시간이 더 걸림

5.2. 요구사항 검증과 가드레일

1. 질문: 기능과 요구사항을 정의한 뒤 다시 검증하고 변경했는가? 가드레일 프레임워크는?

   1. 답변: 17개 요구사항 중 15개를 처음부터 올바르게 설정
   2. AI 엔지니어링 검증 프로세스는 시간이 지나며 진화
   3. 처음에는 Cursor에 plan mode가 없었고, Cloud code에 막 도입된 시점이었으나 개발 생명주기에 채택

2. 질문: PR 리뷰는 사람이 했는가, AI가 했는가?

   1. 답변: 리팩토링 기간 동안 모든 PR 리뷰는 사람이 수행
   2. 로컬에서 AI를 활용해 "이 코드를 리뷰하고 품질을 확인하라"는 스킬을 실행
   3. AI 리뷰는 점점 더 자율적으로 발전 중이지만, 당시에는 사람의 PR 리뷰가 리팩토링 맥락을 공유하는 데 매우 효과적
   4. 새 저장소에서 일하는 개발자가 소수여서 맥락 전달이 중요했음

5.3. 6개월 후의 변화 전망

1. 질문: 6개월 후 가장 달라질 요인은 무엇인가?
   1. 답변: 모델에 맡길 수 있는 작업의 복잡도가 크게 달라질 것
   2. 더 많은 회사가 리팩토링을 위한 스캐폴딩(템플릿, 평가 기준, 검증 프로세스 등)을 갖추게 될 것
   3. 연구 → PoC → 코드 품질 검증 → 숨겨진 가정(hidden assumptions) 확인(예: 오픈소스 라이브러리의 특정 기능이 실제는 베타 단계) 같은 전 단계가 훨씬 빨라질 것
   4. 기존의 "이 파일을 요구사항에 맞게 다시 작성하라"는 표준 리팩토링보다 훨씬 많은 맥락을 AI가 처리할 수 있게 될 것

---

주요 발언 모음

"It's not just my AI pipeline that's on fire, but also my PowerPoint." — 발표 시작며 2025년 Wisedocs의 위기 상황을 표현

"We're adding too many customers. We're not getting the throughput we need and we need to improve our underlying technology." — 세 가지 위기: 고객 증가, 처리량 부족, 기저 기술 개선 필요

"If we introduce additional complexity into our codebase, we can very quickly outrun the ROI we've generated." — 기술 부채가 ROI를 앞지르는 위험

"Even though we're shipping faster and faster, the code quality and the product quality has not necessarily gone up." — 빠른 배포와 품질 저하의 paradox

"It took 3 hours of back and forth chatting within Cursor but it made 10 major mistakes." — o3 시절의 코딩 에이전트 실험 결과

"Sonnet 4.6 with one additional iteration was able to solve the task and with Opus it was basically able to oneshot this problem." — 최신 모델로 재실행한 벤치마크 결과

"It completed its goal in 10 minutes and 22 seconds. Now it only wrote 2,000 lines of code which was a little bit fishy... it actually just implemented a bunch of scaffolding and didn't implement the models." — GPT-5.5 extra high 제로샷 실험의 한계

"So features that would take multiple months in under a week." — 리팩토링 후 배송 속도의 향상

"Sometimes it's good to pause, build a monorepo, and forge ahead." — 발표자의 핵심 조언

---

핵심 데이터 & 수치

• 10,000페이지 이상: Wisedocs가 처리하는 의료 청구 PDF 서류의 페이지 수
• 10개 이상의 저장소: 리팩토링 전 Wisedocs의 분산된 레거시 저장소 수
• 6개월: 리팩토링에 소요된 기간
• 2개월: AI 파이프라인 오케스트레이터 평가에 소요된 기간
• 5개: 평가한 오픈소스 오케스트레이터 프로젝트 수
• 17개: 오케스트레이터 평가 기준 수
• 3명: PoC를 수행한 팀 규모
• 90%: 현재 도구로 오케스트레이터 평가를 더 빠르게 수행할 수 있다는 발표자의 추정
• 3시간: o3를 사용한 초기 리팩토링 실험 소요 시간
• 10개: o3가 저지른 주요 실수 수
• 1/5: 최신 모델로 동일한 작업을 수행할 경우 예상 소요 시간 비율
• 10분 22초: GPT-5.5 extra high의 제로샷 리팩토링 완료 보고 시간
• 2,000줄: GPT-5.5 extra high가 작성한 코드 라인 수(대부분 스캐폴딩)
• 15/17: 처음부터 올바르게 설정한 리팩토링 요구사항 비율

---

결론 및 시사점

1. AI 코딩 에이전트는 빠르게 발전하고 있지만, 아직 자율적으로 대규모 레거시 리팩토링을 완벽히 수행할 수 있는 단계는 아니다.

   • o3에서 Sonnet 4.6/Opus 4.8로 진화하면서 실수가 줄고 원샷 능력이 향상됐지만, GPT-5.5 extra high조차 핵심 구현 없이 스캐폴딩만 생성하는 한계를 보였다.

2. 기술 부채는 비즈니스 확장을 직접 방해하는 리스크다.

   • Wisedocs는 고객 수요, 처리량, 레거시 코드 문제로 인해 6개월간의 대대적인 리팩토링을 결정했다.
   • 기술 부채를 금융 부채처럼 ROI 관점에서 관리해야 한다.

3. 모노레포 전환은 개발자 생산성과 참여도를 동시에 높인다.

   • 10개 저장소를 하나로 통합한 결과, 배포 속도는 수 개월에서 일주일 이하로 단축되고, 개발자들이 기꺼이 기여하는 코드베이스가 되었다.

4. 빠른 AI 네이티브 개발도 적절한 가드레일 없이는 새로운 레거시를 만들 수 있다.

   • AI로 빠르게 쌓은 코드도 저품질이면 이해하기 어려운 레거시가 될 수 있다.
   • 요구사항 정의, plan mode, 사람 중심 PR 리뷰, 숨겨진 가정 검증 등 다양한 가드레일이 필요하다.

5. 리팩토링 시점은 비즈니스 가치와 트레이드오프를 따져 결정해야 한다.

   • 모델이 더 좋아질 것을 기대하며 미루는 것도 합리적이지만, 비즈니스가 막힐 때는 멈춰서 정리하고 다시 나아가는 것이 더 나을 수 있다.
   • 때로는 "pause, build a monorepo, and forge ahead"가 정답이다.