TL;DR

  • 복잡한 C 코드 30만 줄을 대상으로 한 연구에서 에이전트가 코드베이스별 리팩터링 플레이북을 반복적으로 구축해 전체 코드의 Code Health 10.0을 달성하는 접근법임.
  • 기존에는 전문가 5~6명이 12~18개월 투입될 작업을 에이전트가 3주, 실제 변환 작업 기준으로는 며칠 만에 수행함.
  • 플레이북은 동작 보존과 품질 향상이라는 제약 아래 에이전트가 직접 만들며, 실패한 변환은 버리고 효과가 있는 변환은 레시피로 기록함.
  • Action Parameter, Shared Index Range, Uniform Step Table 같은 코드베이스별 패턴이 일반적인 설계 지식을 구체적인 코드 문제에 연결함.
  • 이런 맥락화된 패턴은 반복 적용 가능한 매칭 규칙으로 작동해 대규모 에이전트 리팩터링을 예측 가능하고 기계적인 과정으로 만드는 첫 단계임.

대규모 재작성의 달라지는 경제성

  • 인공지능(AI)은 개발 도구의 범위를 넓히며, 에이전트 기반 코딩은 이전에는 경제적·실무적으로 어려웠던 대규모 기술 부채 개선 전략을 가능하게 함.
  • 기술 부채는 수십 년간 늘어 왔고 코딩 에이전트가 축적을 가속할 가능성이 있지만, 같은 에이전트가 해결책도 제공할 수 있음.
  • 복잡한 도메인의 Street Fighter III 코드베이스 C 코드 30만 줄을 개선한 에이전트 리팩터링 연구에서 이 접근법이 도출됨.
  • 핵심은 진화적 리팩터링으로, 에이전트가 코드베이스별 패턴을 직접 만들고 이를 플레이북에 축적함.
  • 패턴은 코드의 문제를 일반적인 설계 패턴과 리팩터링에 연결하는 매칭 규칙으로 작동함.
  • 플레이북이 확장될수록 에이전트가 대규모로 변환을 적용하는 능력도 커짐.
  • 기존 코드베이스를 대체 시스템이 준비될 때까지 수년간 유지해야 한다는 비용은 전면 재작성의 위험으로 지적돼 왔음.

Joel Spolsky는 재작성을 기업이 저지를 수 있는 “단 하나의 최악의 전략적 실수”라고 표현함.

  • 최근의 증거는 대체 시스템을 기다리는 기간이 이전보다 훨씬 짧아질 수 있음을 시사함.

전체 코드베이스를 리팩터링하는 데 걸리는 시간

  • 코드베이스가 구제 불가능하다고 여겨지면 기능 추가 비용이 커지고 버그가 늘어나며, 시스템이 사업을 뒷받침하지 못한다는 판단으로 재작성이 매력적인 선택지가 됨.
  • 대안은 대규모 리팩터링으로 기존 코드의 품질을 높이는 방식임. 전면 재작성보다 안전하지만, 새 프로젝트를 선호하는 엔지니어에게는 덜 매력적일 수 있음.
  • 대규모 리팩터링은 드문 전문 기술이며, 리팩터링과 기초적인 소프트웨어 설계 원칙에 관한 지식도 널리 보급돼 있지 않음.
  • C 코드 30만 줄 규모의 리팩터링에는 C 프로그래밍뿐 아니라 소프트웨어 설계, 테스트, 도메인 지식에 능숙한 5~6명이 12~18개월 일해야 한다는 추정임.
  • 연구에서는 에이전트가 같은 작업을 3주 만에 완료함. 다만 안전한 대규모 리팩터링 절차를 설계하는 선행 작업을 제외하면 실제 변환은 며칠 안에 이뤄짐.
  • 해당 연구는 Daniel Webb와 Markus Borg가 수행했으며, 여기서는 에이전트가 자체 플레이북을 구축해 작업을 완수한 방식에 초점을 둠.

아래까지 이어지는 인공지능

  • 반복되는 에이전트 작업에는 학습 과정이 포함되는 것이 바람직하며, 연구에서는 리팩터링 플레이북을 반복적으로 구축하는 절차를 설계함.
  • 플레이북은 에이전트가 직접 작성함. 도구는 기존 코드 스멜과 위치를 알려주되 해결책 선택은 에이전트에 맡김.
  • 에이전트는 여러 코드 변환을 시도하고 실패한 변환은 폐기하며, 살아남은 변환은 플레이북에 기록함.
  • 플레이북의 모든 레시피에는 두 가지 제약이 적용됨.
  • 동작 보존: 변환 전후의 동작을 보존해 코드 변경이 리팩터링으로 성립하도록 함.
  • 품질 향상: 코드 품질의 결정적 측정 기준인 10점 척도 Code Health를 높여야 함.
  • 피드백 루프를 갖춘 상태에서 에이전트가 이 제약 안에서 자유롭게 탐색하도록 함.
  • 며칠간의 집중적인 토큰 사용 뒤 작업이 완료됐으며, 코드 30만 줄의 Code Health가 10.0에 도달하고 게임도 계속 플레이 가능함.
  • 가장 주목할 만한 결과는 작업 성공 자체뿐 아니라 플레이북에서 발견된 새로운 코드베이스별 리팩터링임.

부수 효과로 나타난 에이전트의 혁신

  • 플레이북 초반에는 Extract Function, Introduce Guard Clauses 같은 익숙한 리팩터링이 포함됨.
  • 그 뒤에는 코드베이스에서 반복되는 변환 형태를 에이전트가 발견하고 이름을 붙인 새로운 패턴이 다수 등장함.
  • Action Parameter: 호출하는 함수만 주로 다른 중복 제어 구조를 다룸.
  • Shared Index Range: 시작 범위와 끝 범위만 다른 반복 루프를 다룸.
  • Uniform Step Table: 서로 다른 함수 호출을 균일한 테이블 기반 디스패치로 바꿈.
  • 처음에는 이런 좁은 범위의 레시피가 불필요해 보일 수 있지만, 일반 지식을 맥락화해 실제 코드 문제에 적용할 수 있게 하는 역할을 함.

일반 패턴에서 로컬 레시피로

  • Action Parameter는 코드 중복을 제거하기 위한 리팩터링이며, 적용 조건과 사용 시점에 관한 구체적인 제약과 지침을 포함함.
  • Street Fighter III의 두 함수는 X 좌표와 Y 좌표 가운데 어느 좌표 공간에서 동작하는지만 다르고 나머지 작업은 동일함. 이는 같은 지식을 두 번 표현한 중복임.
  • 이 문제는 에이전트가 만든 Action Parameter 패턴의 전제 조건에 부합함. 공통 동작을 공유 함수에 넣고 달라지는 동작을 매개변수화하면 두 함수는 각각 X 또는 Y 오프셋 계산을 전달하는 한 줄 호출로 바뀜.
  • 이 접근은 C 함수 포인터로 Strategy 패턴을 구현해 중복을 제거하는 방식과 연결됨.
  • 그러나 에이전트에게 “중복 제거에 Strategy를 적용하라”는 일반 지시만 주는 방식은 범위가 지나치게 넓음.
  • Action Parameter처럼 좁고 구체적인 코드베이스별 패턴은 특정 코드 문제를 일반 설계 패턴과 리팩터링에 기계적으로 연결할 수 있음.
  • 일반 리팩터링과 패턴은 기반을 제공함.
  • 코드베이스별 리팩터링은 당면한 문제에 맞게 일반 지식을 조정함.
  • 코드 변환 자체는 Strategy나 Extract Method처럼 일반적일 수 있으며, 혁신은 코드베이스별 패턴으로 일반 지식을 맥락화해 실제 적용 가능한 매칭 규칙으로 만드는 데 있음.
  • 에이전트는 이 레시피를 인식하고 대규모로 재사용할 수 있으며, 이는 에이전트 리팩터링을 예측 가능하고 기계적인 대규모 과정으로 발전시키는 첫 단계임.

속도가 새로운 전략을 가능하게 함

  • 소프트웨어 개발의 미래는 엔지니어링의 축소가 아니라 더 높은 추상화 수준에서의 엔지니어링이며, 코드베이스별 리팩터링 플레이북은 리팩터링 지식을 특화하고 진화시키는 접근법임.
  • 기계는 이런 특화 작업을 감당할 수 있으며, 에이전트의 속도가 이전에는 실무적으로 불가능했던 전략을 가능하게 함.
  • AI의 진정한 이점은 작업을 2~3배 또는 10배 빠르게 하는 데 그치지 않고, 속도가 열어 주는 전략적 선택지와 기회에 있음.
  • 복잡한 코드 30만 줄을 며칠 안에 리팩터링한다는 구상은 불과 몇 년 전만 해도 공상과학에 가까웠음.
  • 기술 부채를 줄이는 방법을 오랫동안 다뤄 온 관점에서 이는 경험한 첫 400배 작업이며, 기술 부채가 해결 가능한 문제가 될 미래를 엿보게 함.