AI VIDEO BRIEFING

AI 코딩 에이전트 리팩터링 사례 — 레거시 저장소 10개를 모노레포로 합친 6개월 기록

의료 청구 문서를 처리하는 AI 파이프라인 팀이 6년 묵은 저장소 10여 개를 모노레포로 합친 6개월 리팩터링을 공개했다. 같은 작업을 최신 모델로 다시 돌린 재실험 결과와 제로샷 시도의 실패까지 짚는다.

레거시 저장소 10개를 모노레포로: AI 에이전트와 함께한 6개월 리팩터링 결산 영상 대표 이미지

핵심 메시지

  • 고객 수요를 감당하지 못하는 처리 속도, 손대기 어려운 AI 파이프라인, 아무도 건드리기 싫어하는 10여 개 레거시 저장소가 대규모 리팩터링의 출발점이었다.
  • 2025년 초 모델로 3시간을 주고받으며 열 번의 중대한 실수를 냈던 작업이, 최신 모델에서는 한 번 더 반복하거나 사실상 한 번에 해결됐다.
  • 발표자는 같은 리팩터링을 지금 다시 한다면 5분의 1 시간이면 끝난다고 추정하면서도, 최신 모델의 제로샷 시도는 껍데기 코드 2,000줄만 남기고 실패했다고 밝혔다.
  • 모델 성능을 볼 때 성공률 50% 기준의 '작업 지속 시간' 그래프 대신 80~99% 기준으로 봐야 계획을 맡길지 판단할 수 있다.
  • 리팩터링 이후 배포 속도뿐 아니라 커밋에 참여하는 개발자 수가 늘었고, 새 코드베이스의 패턴이 사내 다른 저장소로 퍼졌다.

쉽게 이해하기

발표자가 일하는 회사는 1만 페이지가 넘는 PDF 형태의 의료 청구 서류를 처리한다. 일부 파일은 동영상보다 클 정도라 파이프라인의 각 구간을 늘리는 일 자체가 간단하지 않았다. 2025년 들어 고객이 늘면서 처리량이 따라가지 못했고, 여러 저장소에 흩어진 머신러닝 모델들을 손보는 일은 아무도 맡고 싶어 하지 않는 작업이 되어 있었다.

그는 기술 부채를 금융 부채에 비유한다. 기능을 빨리 내놓거나 고객을 확보해 얻는 이익이 있어야 부채를 질 이유가 생기는데, 코드베이스에 복잡도가 더해지는 속도가 그 이익을 금세 앞질러 버린다는 것이다. AI 도구 덕에 코드를 쓰고 고치는 속도는 분명히 빨라졌지만, 같은 기간 제품의 유지보수성과 신뢰성은 오히려 나빠졌다는 지적도 함께 내놓는다.

리팩터링은 사전 조사부터 시작됐다. 오케스트레이터 후보 다섯 개를 두 달에 걸쳐 17개 기준으로 비교하고, 세 명이 붙어 개념 검증을 만들었다. 발표자는 지금이라면 심층 리서치와 하위 에이전트를 붙여 이 과정을 90% 빠르게 끝낼 수 있다고 본다. 다만 20쪽짜리 리서치 보고서를 그럴듯하다는 이유로 믿었다가, 거기 적힌 기능이 실제 제품에 없다는 걸 뒤늦게 알게 되는 함정을 경계하라고 덧붙인다.

가장 인상적인 대목은 같은 코드 작업을 시점만 달리해 다시 돌려본 부분이다. 초기 모델은 세 시간 동안 대화를 주고받고도 중대한 실수를 열 개 냈고, 사람이 계속 끼어들어 코드를 고치고 지워야 했다. 최신 모델에서는 실행 비용이 조금 더 들었지만 하위 에이전트 호출, 계획 수립, 셸 명령, 검증 단계가 자동으로 끼어들면서 사람 손이 훨씬 덜 갔다.

그렇다고 전부 맡길 수 있는 단계는 아니다. 최신 모델에 저장소 이름을 주고 통째로 리팩터링을 시켰더니 10분 22초 만에 '완료'를 선언했지만, 실제로는 2,000줄 남짓의 뼈대만 만들고 모델 구현과 배포 명령은 손대지 않은 상태였다. 결론적으로 그는 이 리팩터링이 가치 있었다고 답한다. 파이프라인 소요 시간과 비용이 줄었고 더 큰 파일을 감당하게 됐으며, 몇 달 걸리던 기능을 일주일 안에 내보낼 수 있게 됐기 때문이다.

주요 인사이트

  • '모델이 몇 시간짜리 작업을 한다'는 그래프는 대개 성공률 50% 기준이다. 계획을 세우고 한 시간짜리 작업을 맡길지 정하려면 80~99% 기준으로 다시 읽어야 한다. 절반의 확률로 실패할 작업에 한 시간과 주의력을 함께 태우는 셈이기 때문이다.
  • 저장소를 합친 실익은 모델의 탐색 능력이 아니라 검증에 있었다. 발표자는 최신 모델이 여러 저장소를 오가며 파일을 찾는 데는 능숙하지만, 종단 간 테스트와 배포, 샌드박스 환경 구성은 여전히 하나로 합쳐 둘 때 훨씬 수월하다고 말한다.
  • AI로 빠르게 쌓은 코드도 결국 레거시처럼 변한다. 양은 많은데 품질이 낮고 무엇보다 사람이 내용을 이해하지 못하는 상태가 되면, 고객 요구에 맞춰 고치는 일이 오히려 더 어려워진다.
  • 이 리팩터링에서 PR 리뷰는 전부 사람이 했다. 개발자가 몇 명뿐인 상황에서 리뷰가 새 코드베이스의 맥락을 팀에 쌓는 통로 역할을 했기 때문이다.
  • 리팩터링의 효과는 속도 지표보다 참여자 수에서 더 뚜렷했다. 자기 전문 영역이 아니어도 스키마나 API를 고치러 들어오는 개발자가 늘면서, 지금은 사내 거의 모든 개발자가 새 저장소에 커밋한다.

자주 묻는 질문

지금 리팩터링을 하는 게 나은가, 모델이 더 좋아질 때까지 기다리는 게 나은가?

발표자는 자기 사례에서는 지금 한 것이 옳았다고 답한다. 모델과 도구가 좋아지면서 나중에 갚는 비용이 계속 싸지는 건 맞지만, 그사이 쌓인 코드를 사람이 이해하지 못하면 고객 요구에 맞춰 고치는 일 자체가 어려워지기 때문이다. 전면 리팩터링 대신 일부 구간만 떼어 정리하는 선택지도 함께 제시한다.

최신 모델에 리팩터링을 통째로 맡기면 되지 않나?

발표에서 실제로 시도했지만 실패했다. 모델은 10분 22초 만에 목표를 달성했다고 보고했으나, 확인해 보니 2,000줄 정도의 뼈대만 작성했고 모델 구현과 배포·부트스트랩 명령은 만들지 않은 상태였다. 발표자는 스스로 검증까지 해내는 단계에는 아직 이르지 못했다고 정리한다.

사전 조사에서 세운 요구사항은 얼마나 맞았나?

질의응답에서 17개 요구사항 가운데 15개가 맞았다고 답했다. 검증 절차는 리팩터링을 진행하면서 계속 바뀌었는데, 예를 들어 계획 모드는 작업을 시작할 무렵 막 등장한 기능이었지만 이후 개발 흐름에 포함시켰다고 밝혔다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식