AX LABS
← 블로그 에이전트 제품 설계

코드 migration은 수렴 설계다

병렬 agent보다 merge와 verifier가 먼저다

AX LABS 7분 읽기

코드 migration 과제를 시작하면 첫 질문은 대개 같다. 몇 개의 agent를 병렬로 돌릴 수 있느냐. 현장에서는 이 질문이 자주 빗나간다. 병렬 실행 자체는 이미 여러 제품과 프레임워크가 지원한다. 어려운 일은 agent가 만든 많은 변경을 한 코드베이스로 안전하게 수렴시키는 것이다.

2026년 현재 coding agent의 방향은 분명하다. OpenAI Codex는 worktree와 cloud environment를 전제로 병렬 agent를 다루고, OpenAI Agents SDK는 sandbox 실행, shell, apply patch를 harness의 기본 프리미티브로 끌어올렸다. GitHub Copilot coding agent는 background 작업 후 draft PR을 만들고, self-review와 보안 스캔을 PR 이전 흐름에 넣었다. Anthropic Claude Code는 subagents, hooks, MCP, plugins를 통해 팀 표준과 내부 도구를 묶는다. Google Jules도 임시 VM에서 작업하고 PR을 반환하는 async coding agent 흐름을 제시했다.

이 흐름이 말하는 것은 하나다. migration agent의 핵심은 모델이 아니라 실행·검증·병합을 통제하는 harness다.

shard는 속도 단위가 아니라 책임 단위다

대규모 migration을 파일 목록으로 쪼개면 실패한다. 파일은 변경 단위일 뿐 책임 단위가 아니다. shard는 dependency, ownership, 테스트 경계, 배포 위험을 기준으로 나눠야 한다.

좋은 shard는 agent에게 닫힌 작업면을 준다. 무엇을 바꿀지, 무엇을 건드리면 안 되는지, 어떤 contract를 유지해야 하는지가 명확하다. sandbox는 이 shard의 실행 공간이다. 각 agent는 독립된 checkout이나 worktree, container, VM에서 코드를 읽고 고친다. 중앙 repository를 직접 건드리지 않는다.

계층 역할 실패 신호
Planner migration rule과 dependency graph로 shard를 만든다 같은 파일·API를 여러 shard가 동시에 수정
Sandbox shard agent별 격리 실행 공간을 제공한다 로컬에서는 통과하지만 통합 시 깨짐
Patch queue 변경을 diff와 metadata로 보관한다 patch 의도와 영향 범위가 설명되지 않음
Merge arbiter 순서, 충돌, contract 위반을 판단한다 텍스트 conflict는 없는데 의미 conflict 발생
Test verifier baseline·unit·integration·migration-specific test를 재실행한다 테스트 통과가 실제 동작 보존을 설명하지 못함

migration agent는 코드를 생산하는 엔진이 아니라, 변경을 수렴시키는 운영 시스템이다.

patch merge는 git merge가 아니다

agent가 만든 변경은 commit이 아니라 주장이다. 이 patch가 왜 필요한가. 어떤 contract를 보존하는가. 어떤 테스트가 그 주장을 지지하는가. merge layer는 이 정보를 함께 받아야 한다.

단순 git merge는 텍스트 충돌만 본다. migration에서는 텍스트 충돌이 없는 실패가 더 위험하다. 한 shard가 공통 utility signature를 바꾸고, 다른 shard가 이전 signature를 전제로 compile되는 경우가 그렇다. merge는 깨끗하지만 제품은 깨진다.

따라서 patch merge에는 세 가지 판정이 필요하다.

  1. syntactic merge: diff가 적용되고 format·lint·compile을 통과한다.
  2. semantic merge: public API, schema, config, dependency contract가 유지된다.
  3. operational merge: 배포 순서, feature flag, rollback 경로가 맞다.

OpenAI Agents SDK가 apply patch 같은 파일 편집 프리미티브를 harness에 넣은 이유도 여기에 있다. agent에게 전체 파일 재작성을 맡기는 것보다, 최소 diff와 실행 로그를 남기는 편이 검토와 재현에 강하다.

verifier는 테스트 실행기가 아니라 판정자다

migration에서 test verifier를 CI wrapper로 만들면 병목이 그대로 남는다. verifier는 통과·실패만 알려주는 장치가 아니다. 어떤 실패가 migration rule 위반인지, 어떤 실패가 flaky인지, 어떤 실패가 기존 결함의 노출인지 분류해야 한다.

최근 연구도 같은 방향을 가리킨다. IBM Research의 AlphaTrans는 repository-level code translation에서 source code와 test code를 함께 번역하고 여러 단계의 validation을 둔다. 2025년 InfCode 논문은 code patch와 test patch를 함께 반복 개선하고, selector agent가 후보 patch를 고르는 구조를 제안했다. 요지는 단순하다. agent가 만든 테스트만 믿지 말고, verifier가 독립적으로 증거를 축적해야 한다.

AX LABS가 보는 verifier의 최소 구성은 네 가지다.

  • 기존 baseline test와 migration 전후 golden output 비교
  • shard별 contract test와 통합 contract test 분리
  • agent-generated test의 격리 저장과 신뢰도 표시
  • 실패 원인 분류와 human reviewer 에스컬레이션

Human-in-the-loop는 마지막 승인 도장으로 넣으면 늦다. reviewer는 verifier가 만든 증거 묶음을 보고 판단해야 한다. diff만 보는 review는 대규모 migration에서 지속되지 않는다.

참고와 다음 행동은 같이 설계한다

이 아키텍처의 결론은 선명하다. 병렬 agent 수를 늘리기 전에 shard 기준, patch metadata, merge arbiter, verifier 판정표를 먼저 설계해야 한다. 그 다음에 모델과 도구를 고른다. 순서를 바꾸면 PoC는 빨라지고 운영은 느려진다.

참고한 최근 12개월 내 1차 출처는 다음과 같다.

대규모 migration agent를 검토 중이라면 첫 산출물은 데모 영상이 아니다. shard map, patch schema, verifier rubric, escalation rule이다. 이 네 가지가 있어야 병렬 변경이 운영 코드로 수렴한다. AX LABS는 이 설계를 PoC 이후 운영 정착까지 한 사이클로 묶어 실행한다. AX Ops 방법론 →