zerovoids.dev
zerovoids.dev

Ø NEWS

코딩 에이전트 · 리팩터링

코딩 에이전트가 3주 만에 C 코드 30만 줄을 리팩터링했다

CodeScene은 코딩 에이전트가 디컴파일된 격투 게임 코드 30만 줄을 3주 만에 리팩터링했다고 밝혔다. 실무자들의 논쟁은 그 일이 일어났는지가 아니라, 프레임 단위 리플레이 검증이라는 이 사례만의 조건이 다른 코드베이스에도 적용되는지를 겨냥한다.

키워드ai-ml

오픈소스 디컴파일 프로젝트에서 가져온 스트리트파이터 III: 서드 스트라이크의 C 코드 30만 줄을, 코딩 에이전트가 3주 동안 726개 파일에 걸쳐 252,055줄을 고치며 2,903번 커밋했다. 토큰 비용은 약 4,000달러, CodeScene이 매기는 코드 건강도 점수는 5.6에서 10.0으로 올랐다. 이 작업을 지켜본 CodeScene 창업자이자 《Your Code as a Crime Scene》의 저자 애덤 토른힐은, 대규모 시스템을 30년 다룬 끝에 처음으로 "초인적인" AI 성능을 봤다고 적었다.

두 가지 안전장치

하나는 품질 신호였다. CodeHealth MCP 서버가 결정론적인 점수를 매겨, 에이전트가 그 점수를 최적화 목표로 삼고 각 변경이 도움이 됐는지 스스로 판단하게 했다. 다른 하나는 정확성이었다. 리플레이 트레이스 하네스가 롤백 상태 해시를 프레임 단위로 비교해, 매 변경 뒤에도 동작이 그대로인지 확인했다.

더 눈에 띄는 결과는 작업 중에 쌓인 것들이다. 정해진 변환 목록을 그대로 적용하는 대신, 에이전트는 22개 레시피와 82개의 보조 메모로 이루어진 리팩터링 플레이북을 스스로 만들었다. Extract Function이나 Guard Clauses 같은 익숙한 변환도 있었지만, 이 코드베이스 전용 레시피도 나왔다. Shared Index Range는 시작·끝 범위만 다른 반복 루프를 묶었고, Action Parameter는 호출하는 함수만 다른 중복 제어 구조를 처리했고, Uniform Step Table은 제각각인 호출을 테이블 기반 디스패치로 바꿨다. 코드 건강도를 오히려 떨어뜨린 실패한 시도들도 기록에 남았다.

모델 선택도 결과를 갈랐다. 팀은 대부분의 작업에 클로드 오퍼스를 썼고, 떠오르는 패턴을 포착하고 문서화하는 데는 오퍼스를 쓴 클로드 코드가 Sol을 쓴 코덱스보다 뚜렷이 나았다고 보고했다. 더 작은 모델로 돌린 파일은 어떤 지점에서 멈춰, 넘어서지 못하는 국소 최적점에 다다른 것처럼 보였다.

증명됐다는 쪽과 의심하는 쪽

링크드인의 반응은 엇갈렸는데, 쟁점은 일이 일어났는지가 아니라 그게 무엇을 보여주는지였다. 파올로 페로네는 읽어본 리팩터링 주장 대부분이 테스트 통과라는 사실에 기대는데, 격투 게임을 상대로 트레이스를 재생하는 쪽이 기준을 훨씬 높였다고 봤다. 옴다 리스폰스의 CTO 마츠 이레마크는 비슷한 작업을 직접 해봤다며, CodeScene의 MCP와 지금의 에이전트를 합치면 거의 반칙처럼 느껴진다고 적었다.

회의적인 쪽은 범위를 물었다. 테크 리드이자 컨설턴트인 콘라드 오트렘프스키는 병합이 됐는지, 거대한 머지 한 번이었는지 여러 번이었는지, 돈을 버는 프로덕션 코드가 아니라 오픈소스 실험이었는지를 물었다. 작업을 직접 한 두 엔지니어 중 하나이자 네오시의 CTO인 다니엘 웹은 포크의 메인 브랜치에 54개의 풀 리퀘스트로 병합됐다고 답했다. 오트렘프스키는 다시, 진짜 시험은 그라파나 같은 유명 오픈소스 프로젝트에 이 리팩터링을 제안하고 마스터에 병합되는 데까지 가야 완료로 칠 수 있다고 받아쳤다. 소프트웨어 아키텍트이자 연구자인 트레이시 배넌은 방법이 아니라 표현을 문제 삼아, 결과를 "완벽하다"고 부르는 건 꽤 대담한 표현이라고 지적했다. 데니스 발토르는 발견됐다는 레시피 자체에 의문을 제기했다. DRY는 코드가 똑같은 게 아니라 지식과 의도가 중복되는 걸 가리키는데, 범위만 다른 루프나 호출 함수만 다른 제어 구조로 정의한 레시피는 둘을 뭉뚱그릴 위험이 있다는 것이다. 아스코 뇜은 방법론 자체를 물었다. 클로드 코드와 코덱스는 각자의 모델에 맞춰 튜닝돼 있어 이 결과가 모델을 재는지 하네스를 재는지 가리기 어렵고, 비용도 같은 이유로 흔들린다고 봤다. 아키텍처는 여전히 측정되지 않아, 코드는 건강해 보여도 근본적인 문제가 나중에 드러날 수 있다고 덧붙였다.

저자들도 못 낸 답

질문은 저자들 쪽에서도 나왔다. 마크 부비에는 게임에서는 프레임레이트와 메모리 사용량, 입력 지연이 중요한데 비기능적 동작이 나아졌는지 물었고, 웹은 성능 전문가를 투입할 예정이라고 답했다. 미세한 프레임 타이밍 회귀를 하네스가 잡아냈는지를 묻자, 그는 확실한 답이 없을 수도 있다고 했다. 프리커밋 훅으로 돌아갔고, 일부 실패는 관찰되지 않은 채 고쳐졌기 때문이다. 디프 크기에 대해서는 더 직설적이었다. 코드에 익숙하지 않고 더는 줄마다 리뷰하지 않는다면 디프는 얼마나 커도 되는가 — 그는 주장 없이 질문만 남겼다.

리플레이 트레이스 하네스가 작동한 이유는 디컴파일된 게임이 프레임 단위로 결정론적인 재생을 제공하기 때문이다. 대부분의 레거시 시스템에는 이런 오라클이 없고, 애초에 그걸 리팩터링하는 일이 위험한 이유도 같다. 토른힐은 자동화된 테스트와 동등성 검사가 "반드시 필요한 안전장치"라고 적었는데, 그 부담은 건강하지 않은 코드베이스일수록 없을 가능성이 큰 바로 그것에 떨어진다. 팀의 선정 과정이 이를 보여준다. 웹은 자신이 작업했던 영국 정부(Gov.UK)의 해양 면허 코드베이스도 후보로 고려했지만, 이번 연구에 쓰기엔 너무 건강해서 제외하고 이 게임을 골랐다고 말했다.