Bun의 AI 기반 Rust 재작성: 백만 줄 마이그레이션을 위한 검증 플레이북

서론

헤드라인은 무시하기 어렵습니다: Bun이 동적 Claude Code 워크플로를 사용해 11일 만에 Zig에서 Rust로 주요 구현을 마이그레이션했다고 보도되었습니다. 공개된 기록에 따르면 수천 개의 커밋, 최대 64개의 Claude 에이전트, 약 780,000줄의 Rust 코드, 각 구현 단위당 두 명의 대립 검토자, 그리고 컴파일되지 않는 코드에서 테스트 슈트를 통과하고 출시할 수 있는 포트로의 발전 과정이 포함되어 있었습니다.

잘못된 교훈은 언어 재작성이 원클릭 작업이 되었다는 것입니다. 유용한 교훈은 구현 처리량과 검증 처리량이 이제 별개의 엔지니어링 문제라는 점입니다.

AI 에이전트는 인간 팀이 읽을 수 있는 속도보다 빠르게 코드를 생성할 수 있습니다. 그렇게 되면 기존의 풀 리퀘스트 검토는 더 이상 주요 안전 메커니즘 역할을 할 수 없습니다. 팀은 거대한 확률적 변경을 기계로 확인 가능한 증거로 뒷받침되는 작은 주장들로 변환하는 시스템이 필요합니다.

Bun의 이후 생산 보고서는 이를 특별히 구체적으로 만들었습니다. 팀은 19개의 알려진 회귀(모두 이후 수정됨), 11차례의 보안 검토, 파서 전반에 걸친 지속적인 커버리지 기반 퍼징, 그리고 총 약 780,000줄 중 unsafe 블록 내 약 27,000줄의 Rust 코드를 보고했습니다. 이러한 사실들은 마이그레이션 이야기를 약화시키지 않습니다. 이는 인상적인 데모가 끝난 후 진지한 마이그레이션 작업이 어떤 모습인지 보여줍니다.

이 가이드는 그 경험을 재사용 가능한 검증 플레이북으로 전환합니다. 목표는 Bun의 규모를 복사하는 것이 아닙니다. AI 코딩 에이전트가 팀이 책임감 있게 한 줄 한 줄 검사할 수 있는 것보다 더 많은 코드를 작성할 수 있는 모든 마이그레이션(언어 포팅, 프레임워크 교체, API 현대화, 데이터베이스 변환, 또는 저장소 전체 리팩터링)을 위한 방법을 제공하는 것입니다.

주요 시사점

• Bun의 재작성은 AI 에이전트가 구현 시간을 압축할 수 있음을 보여줍니다. 검증 시간이 제거될 수 있음을 보여주지는 않습니다.
• 이전 가능한 자산은 마이그레이션 시스템입니다: 문서화된 동작 계약, 리스크 맵, 소규모 파일럿, 격리된 작업자, 독립적 검토자, 결정론적 게이트, 그리고 복구 가능한 커밋.
• 컴파일러와 기존 테스트 스위트는 서로 다른 실패 클래스를 포착합니다. 둘 중 어느 것도 모든 교차 언어 의미론적 불일치, 릴리스 모드 차이, 성능 회귀, 또는 안전하지 않은 경계를 포착하지 못합니다.
• 대규모 diff는 증거 중심의 검토가 필요합니다. 인간은 생성된 모든 줄이 동등한 조사를 받는 척하기보다 계약, 리스크 핫스팟, 반례, 테스트 격차, 그리고 롤아웃 결정을 검사해야 합니다.
• 팀은 백만 줄 재작성을 시도하지 않고도 동일한 패턴을 채택할 수 있습니다: 에이전트가 한 번에 한 조각씩 동작을 증명하도록 요구하고, 측정된 결과 이후에만 더 넓은 자율성을 부여하세요.

Bun이 실제로 한 일과 헤드라인이 생략한 것

엔지니어링 기록은 대규모 코드 생성 이전에 시작되었습니다.

Jarred Sumner는 반복되는 Zig 패턴을 Rust에 매핑한 PORTING.md를 만드는 데 약 3시간을 보냈다고 합니다. 별도의 워크플로가 구조 필드를 분석하고, Rust 수명을 제안하고, 해당 선택 사항을 두 명의 대립 검토자에게 보내고, 결과를 LIFETIMES.tsv로 직렬화했습니다. 이러한 산출물도 수동으로 검토되었습니다.

첫 번째

implementation trial covered three files, not the entire repository. For each file:

1. One agent implemented the Rust version.
2. Two fresh agents reviewed behavioral equivalence and compliance with the migration documentation.
3. Another agent applied the approved fixes.

Only after this pilot did the work fan out across 1,448 Zig files.

The first large-scale run failed. Agents shared a workspace and used commands such as git stash, git stash pop, and git reset --hard. Their changes interfered with one another. The workflow was then changed to prohibit unsafe coordination commands and use four worktrees, each with 16 agents.

That detail matters more than the peak line-generation rate. Parallel coding is a distributed-systems problem. Shared state, conflicting writers, expensive global operations, ownership, and recovery all need explicit rules.

The generated code did not work immediately. Bun used compiler errors as a queue and advanced one crate at a time. At one point, around 16,000 compiler errors were assigned to agents. The loop used one fixer, two reviewers, and one application agent, while limiting how often expensive commands such as cargo check and Git operations could run.

This was not magical translation. It was staged convergence driven by deterministic feedback.

Anthropic’s dynamic-workflow announcement reported that 99.8% of the existing suite passed at the time of the initial write-up, while explicitly noting that the port was not yet in production. Bun’s later article covered the work that followed: security reviews, fuzzing, production regressions, semantic fixes, and reduction of unsafe code.

Read together, the sources describe two different milestones:

• Implementation-complete enough to merge
• Evidence-complete enough to run safely

Terms You Need to Know: Port, Oracle, Differential Testing, and Unsafe Surface

These definitions matter because a team cannot verify a migration until it agrees on what the evidence must prove. They also separate an agent’s confidence statement from an externally checkable result.

Port

A port reimplements software in a new language, runtime, platform, or framework while preserving a defined set of behaviors.

“Preserve behavior” needs a boundary. A port may preserve public APIs and outputs while intentionally changing internal architecture, performance characteristics, error messages, or unsupported edge cases.

Behavior Contract

A behavior contract is an explicit list of properties the new implementation must preserve.

It may include:

• Inputs and outputs
• Error behavior
• Ordering
• Side effects
• Concurrency semantics
• Resource limits
• Supported platforms
• Performance budgets
• Observability requirements

Existing code contains behavior, but not every existing behavior is intentional. The contract separates requirements from historical accidents.

Test Oracle

A test oracle determines whether an output is correct.

A unit-test assertion is one oracle. A reference implementation, protocol specification, golden file, database invariant, or human-authored rule can also act as an oracle.

Anthropic’s guidance on long-running

과학적 코딩은 자율적인 작업이 참조 자료, 측정 가능한 목표, 또는 테스트 스위트를 필요로 한다는 점을 강조합니다. 그래야 에이전트가 자신이 진전을 이루고 있는지 판단할 수 있기 때문입니다.

차등 테스트

차등 테스트는 기존 구현과 새 구현에 동일한 입력을 보낸 후, 관찰 가능한 결과를 비교합니다.

이 방법은 기존 구현이 신뢰할 수 있지만 완전한 공식 명세가 존재하지 않을 때 특히 유용합니다. 결과가 일치한다고 해서 두 구현이 모두 올바르다는 것을 증명하지는 않지만, 불일치가 발생하면 정밀한 조사 순서를 생성합니다.

변형 테스트

변형 테스트는 정확한 예상 출력을 작성하기 어려운 경우, 여러 실행 간의 관계를 확인합니다.

예를 들면 다음과 같습니다:

• 값을 직렬화한 후 구문 분석하면 값이 보존되어야 합니다.
• 독립적인 입력을 재정렬해도 집합 값 결과가 변경되지 않아야 합니다.
• 멱등 마이그레이션을 두 번 실행해도 두 번째 실행 시 상태가 변경되지 않아야 합니다.
• 동일한 멱등성 키를 다시 시도해도 중복된 부작용이 발생하지 않아야 합니다.

안전하지 않은 표면

안전하지 않은 표면은 대상 언어의 일반적인 보증이 약화되거나 우회되는 코드입니다.

Rust에서 unsafe는 C 또는 C++ FFI 경계, 사용자 정의 할당자 내부, 또는 저수준 런타임 통합에 필요할 수 있습니다. 원시 개수는 판결이 아닙니다. 팀은 각 안전하지 않은 경계에 대한 소유권, 불변성, 테스트, 그리고 명시적인 계획이 필요합니다.

이스케이프 결함

이스케이프 결함은 이를 감지해야 했던 게이트를 통과한 후(병합, 카나리 배포, 릴리스 후보 테스트, 또는 프로덕션 롤아웃 이후) 발견된 마이그레이션 유발 버그입니다.

이스케이프 결함은 구현뿐만 아니라 검증 시스템에 대한 피드백입니다.

인과 관계 체인: 더 빠른 생성이 왜 더 강력한 검증을 필요로 하는가

에이전트 병렬 처리는 구현의 경제성을 변화시킵니다. 64명의 작업자가 동시에 파일을 번역하면 코드 생성 시간이 크게 단축될 수 있습니다. 의존성 그래프, 대상 언어의 의미론, 그리고 공유 테스트 환경은 사라지지 않습니다. 처리량은 단순히 병목 현상을 하류로 옮길 뿐입니다.

병목 현상 1: 통합

개별적으로는 합리적인 파일들이 함께 컴파일될 때 실패할 수 있습니다.

Bun의 약 16,000개 컴파일러 오류와 순환 크레이트 의존성은 로컬 번역과 전역 일관성 사이의 간극을 보여줍니다. 컴파일러는 타입, 소유권, 수명, 이름, 그리고 일부 제어 흐름 속성에 대해 훌륭한 결정론적 오라클입니다. 하지만 제품 동작에 대한 오라클은 아닙니다.

병목 현상 2: 의미론적 동등성

Bun은 언어 간에 코드가 거의 동일해 보였지만 다르게 동작하는 버그를 문서화했습니다.

예를 들면 다음과 같습니다:

• Rust debug_assert! 내부에 배치된 부작용이 릴리스 빌드에서 사라진 반면, 비슷한 Zig 어설션은 여전히 인수를 평가했습니다.
• 조급한 unwrap_or 표현식이 지연되어야 할 동작을 트리거했습니다.
• 구현 간에 바이트 슬라이스 및 경계 의미론이 달랐습니다.
• 홀수 길이의 UTF-16 입력이 충돌을 노출했습니다.

이것은 변환된 코드가 그럴듯해 보이기 때문에 피상적인 리뷰가 놓치는 정확히 그런 실패입니다.

병목 현상 3: 리뷰 상관 관계

동일한 모델이 동일한 컨텍스트와 가정을 사용하여 변경 사항을 작성하고 리뷰하면, 동일한 문제를 재현할 수 있습니다.

original mistake.

Anthropic의 Claude Code 모범 사례 문서는 새로운 리뷰어 컨텍스트를 사용할 것을 권장합니다. 리뷰어는 작성자의 추론 과정을 계승하지 않고 변경사항(diff)과 표준만을 확인합니다. 독립성이 정확성을 보장하지는 않지만, 공유 컨텍스트로 인한 편향을 줄여줍니다.

병목 4: 운영 증거

테스트가 통과하더라도 지연 시간이 두 배로 증가하거나, 메모리 사용량이 늘어나거나, 특정 운영체제 대상이 작동하지 않거나, 관찰 가능성이 사라질 수 있습니다.

변경 사항이 클수록 배포 후에야 팀이 위반된 요구사항을 발견할 가능성이 높아집니다. 이것이 바로 마이그레이션 계획에 카나리(canaries), 롤백, 텔레메트리 비교, 그리고 모든 누출 결함을 새로운 계약 규칙이나 테스트로 전환하는 프로세스가 포함되어야 하는 이유입니다.

인과적 결론은 간단합니다.

AI는 마이그레이션 비용을 없애지 않습니다. 비용을 타이핑에서 사양 정의, 테스트 하니스 설계, 증거 검토, 배포 제어로 이동시킬 뿐입니다.

이러한 변화를 무시하는 팀은 코드 생성을 빠르게 완료한 후, 재작성이 실제로 작동하는지 확인하는 데 몇 달을 소비할 수도 있습니다.

AI 기반 마이그레이션을 위한 검증 아키텍처

이 아키텍처는 네 가지 계층(plane)으로 구성됩니다.

1. 계약 계층(Contract Plane)

계약 계층은 다음을 저장합니다.

• 공개 동작
• 호환성 약속
• 의도적 변경 사항
• 지원 플랫폼 매트릭스
• 성능 예산
• 보안 제약 조건
• 관찰 가능성 요구사항

인간이 이 계층을 유지 관리하며, 리포지토리가 버전 관리를 수행합니다.

2. 실행 계층(Execution Plane)

실행 계층은 격리된 구현 에이전트를 포함합니다.

각 에이전트는 다음을 받습니다.

• 하나의 마이그레이션 유닛
• 관련 소스 파일
• 승인된 계약
• 의미 맵(Semantic Map)
• 좁은 범위의 도구
• 대상 검사

에이전트는 계약이나 글로벌 테스트를 변경할 수 없습니다. 할당된 범위만 편집하고 커밋과 증거를 반환합니다.

3. 검증 계층(Verification Plane)

검증 계층은 구현과 독립적입니다.

다음을 수행할 수 있습니다.

• 후보 컴파일
• 대상 및 글로벌 테스트 실행
• 기존 버전과 신규 버전 간 차등 검사 실행
• 파서 및 프로토콜 경계 퍼징
• 보안 민감 코드 스캔
• 대표 워크로드 벤치마킹
• 새로운 리뷰어에게 반례 검색 요청

검증 에이전트는 테스트를 제안할 수 있지만, 판정 게이트 통과 여부는 결정론적 CI가 결정합니다.

4. 릴리스 계층(Release Plane)

릴리스 계층은 통합 및 프로덕션 노출을 제어합니다.

다음을 수행합니다.

• 의존성 순서에 따라 병합
• 재현 가능한 아티팩트 생성
• 불변 버전 또는 해시로 빌드 식별
• 가능한 경우 섀도 트래픽 실행
• 카나리를 점진적으로 확장
• 서비스 수준 지표 모니터링
• 테스트된 롤백 경로 유지

We0 AI는 이러한 계층 사이에 오케스트레이션 및 증거 계층으로 위치할 수 있습니다. 팀은 태스크를 사용하여 마이그레이션 조각을 할당하고, 작업 트리를 격리하고, 계약을 첨부하고, 테스트 출력을 수집하고, 작업 진행 전에 검토를 요구할 수 있습니다.

중요한 경계는 오케스트레이션이 증거를 조정한다는 점입니다. 에이전트의 성공 주장을 릴리스 허가로 전환하지 않습니다.

예제 시나리오: 결제 서비스를 Python에서 Go로 마이그레이션

120,000줄 규모의 Python 결제 서비스를 Go로 마이그레이션하는 경우를 가정해 보겠습니다. 비즈니스 목표는

tail latency and simplify deployment.

위험한 프롬프트의 예:

이 서비스를 Go로 다시 작성하고 모든 테스트를 통과시키세요.

해당 프롬프트는 트랜잭션 의미론, 오류 동작, 금전적 정밀성, 멱등성, 롤아웃을 정의하지 않은 상태로 남겨둡니다.

1단계: 계약서 작성

각 엔드포인트에 대해 팀은 다음을 기록합니다:

• 요청 및 응답 스키마
• 인증 규칙
• 멱등성 키 동작
• 통화 반올림
• 재시도 의미론
• 데이터베이스 트랜잭션
• 이벤트 순서
• 오류 코드
• 원격 측정 요구사항

또한 Python 특정 디버깅 헤더 제거와 같은 의도적인 변경 사항도 표시합니다. 팀은 지원되는 플랫폼 및 종속성 매트릭스를 정의한 다음 p95 및 p99 지연 시간 예산과 최대 메모리 상한을 설정합니다.

2단계: 세 가지 파일럿 조각 선택

팀은 다음을 선택합니다:

1. 순수 통화 형식 지정 모듈
2. 데이터베이스 부작용이 있는 멱등성 저장소
3. 읽기 전용 HTTP 엔드포인트

첫 번째는 기계적 번역을 테스트합니다. 두 번째는 트랜잭션 및 동시성을 테스트합니다. 세 번째는 HTTP 호환성을 테스트합니다.

각 조각은 하나의 구현 에이전트가 처리합니다. 새로운 검토자는 계약서, 이전 소스, 제안된 diff, 그리고 검증 명령만 받습니다.

3단계: 이전 서비스를 차등 오라클로 사용

정제된 과거 요청 코퍼스가 두 버전 모두에 대해 재생됩니다.

응답은 계약이 차이를 허용하는 경우에만 정규화된 후 비교됩니다. 쓰기 경로의 경우 두 구현 모두 일회용 데이터베이스 스냅샷에 대해 실행됩니다. 결과 행과 방출된 이벤트가 비교됩니다.

그런 다음 변형 테스트는 다음을 수행합니다:

• 동일한 멱등성 키 반복
• 무해한 JSON 키 순서 변경
• 재시도 타이밍 변형 도입
• 경계 통화 값 테스트

4단계: 새 서비스 섀도우 및 카나리

프로덕션 쓰기가 활성화되기 전에 Go 서비스는 쓰기가 비활성화되거나 격리된 싱크로 리디렉션된 섀도우 트래픽을 수신합니다.

팀은 다음을 비교합니다:

• 지연 시간 분포
• 오류 분류
• 종속성 호출
• 트레이스 형태
• 메모리 사용량
• 이벤트 동작

그런 다음 팀은 위험이 낮은 상점 코호트에서 1% 카나리 트래픽을 보냅니다.

확장에는 다음이 필요합니다:

• 설명할 수 없는 재정적 불일치 없음
• 오류율 동등성
• 합의된 예산 내의 지연 시간
• 성공적인 롤백 연습

구현은 여전히 빠르게 진행될 수 있습니다. 안전은 "서비스 다시 작성"을 관찰 가능한 주장으로 변환하는 데서 비롯됩니다.

이 예시는 또한 도메인 전문성이 왜 필수적인지 보여줍니다. 에이전트는 코드를 번역할 수 있지만, 결제 전문가는 중복 이벤트, 반올림 차이, 재시도 동작이 비즈니스 요구사항이라는 것을 알고 있습니다.

0단계: 마이그레이션 계약 및 중단 조건 정의

에이전트가 코드를 편집하기 전에 동일한 제품으로 간주되는 것이 무엇인지 결정합니다.

인벤토리:

• 공개 API
• CLI 동작
• 파일 형식
• 데이터베이스 영향
• 환경 변수
• 원격 측정
• 사용자에게 표시되는 오류 메시지
• 지원되는 플랫폼
• 성능 특성

각 속성을 다음 중 하나로 표시합니다:

• 유지
• 의도적으로 변경
• 사용 중단
• 알 수 없음

알 수 없음은 추측을 허용하지 않습니다. 이는 발견 작업이 됩니다.

이전 시스템을 실행하고, 이슈와 변경 로그를 검색하고, 프로덕션 트레이스를 검사하거나, 유지 관리자에게 문의하세요.

리팩토리 과정에서 이동 전용 커밋을 통해 Git 히스토리를 보존하여, 출처 추적을 의도적 요구사항으로 만들고 우연한 피해가 아니도록 했습니다.

하드 스톱 조건을 정의하세요. 다음과 같은 경우 팬아웃을 중단합니다:

• 파일럿 불일치율이 임계값을 초과하는 경우
• 작업자가 보호된 전역 테스트를 반복적으로 수정하는 경우
• 컴파일러 오류 큐가 닫히는 속도보다 빠르게 증가하는 경우
• 대상 성능이 예산을 충족하지 못하는 경우
• 롤백 아티팩트를 빌드할 수 없는 경우
• 증거가 불완전하거나 읽을 수 없는 경우

중단은 프로젝트를 매몰 비용 증가로부터 보호합니다.

계약은 실행과 별도로 통제되어야 합니다. 에이전트가 요구사항을 약화시켜 실패하는 테스트를 "수정"해서는 안 됩니다. 계약 변경에는 이전 동작이 왜 구식이거나 잘못되었는지 설명하는 인간 검토 수정안이 필요합니다.

1단계: 대규모 생성 전 의미 맵 구축

일반적이거나 미묘하거나 위험한 소스-대상 패턴에 대한 명시적 매핑을 생성하세요.

다음 영역을 포함합니다:

• 소유권 및 수명 규칙
• 널 가능성
• 예외 및 오류 처리
• 정수 오버플로
• 시간 계산
• 문자열 인코딩
• 동시성 기본 요소
• 할당자 소유권
• FFI
• 디버그 대 릴리스 동작
• 플랫폼별 코드

Bun의 PORTING.md와 LIFETIMES.tsv가 이 목적을 수행했습니다.

이들의 가치는 더 나은 프롬프트에만 국한되지 않았습니다. 수백 명의 작업자에게 공유된 의미 전략을 제공했습니다. 이러한 맵이 없으면 모든 에이전트가 자체 번역 방식을 발명하고, 불일치가 통합 문제가 됩니다.

독립적인 에이전트에게 맵을 공격하도록 요청하세요:

• 한 검토자에게는 소스 언어 의미를 제공
• 다른 검토자에게는 대상 언어 위험을 제공
• 세 번째 검토자에게는 대표적인 코드 예제를 제공
• 구체적인 반례를 요구

인간은 가장 위험도가 높은 규칙, 특히 메모리 소유권, 동시성, 안전 경계, 지속성, 릴리스 전용 동작과 관련된 규칙을 검사해야 합니다.

맵에 버전을 지정하세요. 새로 발견된 모든 불일치는 규칙을 업데이트하고, 영향을 받는 마이그레이션 단위를 식별하며, 대상 재검증을 트리거해야 합니다.

의미 맵은 시작 시 한 번 붙여넣는 프롬프트가 아니라, 살아있는 명세입니다.

2단계: 의도적으로 어려운 파일럿 설계

가장 쉬운 파일만 선택하지 마세요.

유용한 파일럿은 세 가지 형태를 포함합니다:

1. 간단하고 대표적인 단위
2. 의존성이 높은 단위
3. 의미적 핫스팟

Bun은 1,448개의 파일을 번역하기 전에 세 개의 파일을 사용하여 구현-검토-수정 루프를 검증했습니다. 정확한 숫자보다는 포함된 실패 모드의 범위가 더 중요합니다.

출력뿐만 아니라 파일럿 프로세스도 측정하세요:

• 작업자가 파일 소유권을 존중했는가?
• 커밋이 원자적이었는가?
• 검토자가 실제 결함을 발견했는가, 아니면 대부분 노이즈를 생성했는가?
• 수정자가 계약을 위반하지 않고 제안을 적용할 수 있었는가?
• 증거가 여전히 읽기 쉬웠는가?
• 각 수용된 단위가 얼마나 많은 컨텍스트와 컴퓨팅을 소비했는가?

의도적으로 결함을 심으세요. 미묘한 릴리스 모드 차이, 에지 케이스 픽스처 또는 성능 임계값을 추가하고 검증 시스템이 이를 감지하는지 확인하세요.

깨끗한 예제만 통과한 하네스는 아직 테스트되지 않았습니다.

팬아웃은 파일럿이 안정적이고 반복 가능한 증거를 생성할 때만 시작해야 합니다. 이후 프롬프트, 모델 또는 도구 정책이 크게 변경되면 작은 파일럿을 다시 실행하세요.

configuration은 프로덕션 코드이며 회귀 테스트가 필요합니다.

3단계: 격리, 소유권 및 원자적 커밋을 통한 확장

의존성 그래프에 따라 마이그레이션 유닛을 생성합니다.

파일 수준 분할은 편리하지만, 동작이 모듈을 넘나들 때는 잘못된 경계가 될 수 있습니다. 각 유닛에 하나의 작성자를 지정하고 소유권을 기계가 읽을 수 있도록 만듭니다. 작업자는 의존성을 읽을 수 있지만, 조정된 변경을 요청하지 않는 한 자신의 범위만 편집할 수 있습니다.

가능한 경우 별도의 작업 트리, 컨테이너 또는 임시 가상 머신을 사용합니다.

Bun의 공유 작업 공간 실패가 그 이유를 보여줍니다. 리프 작업자에게는 파괴적인 Git 명령과 비용이 많이 드는 전역 빌드 명령을 제한합니다. 코디네이터가 순서화된 통합을 수행하도록 합니다.

단기 자격 증명과 네트워크 허용 목록은 프롬프트 인젝션 또는 의존성 유출의 영향을 줄입니다. Anthropic의 샌드박싱 가이드는 파일 시스템 및 네트워크 경계를 보다 안전한 자율성의 기반으로 설명합니다.

승인된 각 유닛은 다음을 포함하는 원자적 커밋을 생성해야 합니다.

• 소스 식별자
• 적용 가능한 계약 규칙
• 실행된 명령어
• 테스트 및 검사 결과
• 검토자 결과
• 승인된 예외

Git은 조정 및 복구 메커니즘이 됩니다.

Anthropic의 장기 실행 워크플로우 가이드는 의미 있는 커밋과 각 커밋 전 테스트를 권장합니다. 복구 가능한 히스토리가 긴 에이전트 실행이 하나의 불투명한 아티팩트가 되는 것을 방지하기 때문입니다.

분당 라인 수를 최적화하지 마십시오. 시간당 검증된 유닛 수를 최적화하십시오.

높은 생성 처리량과 증가하는 통합 대기열은 부정적인 진전입니다.

4단계: 컴파일러 오류 및 테스트를 증명이 아닌 대기열로 취급

컴파일러 출력은 구조화된 작업을 생성합니다.

소유권 유닛 또는 의존성 계층별로 오류를 그룹화하고, 중복된 연쇄 오류를 제거하며, 리프 증상보다 근본 원인을 먼저 수정합니다.

계약이 명시적으로 허용하지 않는 한 다음을 포함한 지름길을 금지합니다.

• 빈 스텁
• 무시된 결과
• 광범위한 allow 속성
• 비활성화된 어설션
• 플레이스홀더 구현
• 후보를 통과시키기 위해서만 변경된 테스트

테스트를 확장되는 범위로 실행합니다.

1. 변경된 모듈의 단위 테스트
2. 공개 경계에서의 계약 테스트
3. 의존성 간 통합 테스트
4. 크로스 플랫폼 스위트
5. 전체 회귀 테스트

실패한 출력을 아티팩트로 유지합니다. 히스토리 없는 최종 통과 실행은 작업자가 검사를 반복적으로 약화시켰는지 숨길 수 있습니다.

가능한 경우 테스트 작성과 구현을 분리합니다.

한 에이전트는 계약과 이전 구현에서 엣지 케이스를 도출하고, 다른 에이전트는 포트를 작성합니다. 승인된 호환성 테스트를 잠가 구현 작업자가 수정할 수 없도록 합니다. 새로운 검토자는 코드가 의도된 이유로 통과하는지 질문해야 합니다.

Bun의 프로덕션 회귀는 통과 스위트와 의미론적 완전성 간의 차이를 보여줍니다.

릴리스 전용 HMR 실패는 debug_assert! 내부의 부작용에서 비롯되었습니다. 홀수 길이 UTF-16 충돌은 다른 슬라이스 동작을 반영했습니다. 모든 탈출된 결함은 영구적인 회귀 테스트이자 새로운 의미론적 맵 규칙이 되어야 합니다.

5단계: 차등 테스트, 퍼징 및 성능 예산 추가

동일한 코퍼스에 대해 이전 및 새로운 구현을 실행합니다.

비교:

• 종료 코드

• 정규화된 출력

• 오류 카테고리

• 부작용

• 데이터베이스 상태

• 발생된 이벤트

• 추적

다음에 대한 경계값 생성기를 구축하세요:

• 빈 입력
• 최대 크기
• 잘못된 형식의 인코딩
• 유닉스 시간 기준 전후
• 동시 경쟁 상태
• 플랫폼별 경로
• 리소스 고갈

지속적으로 퍼저와 프로토콜 경계를 퍼징하세요.

Bun은 커버리지 기반 퍼저가 파서 코드를 약 1,000억 번 실행하고, 약 15개의 수정 풀 리퀘스트를 생성했다고 보고했습니다. 절대적인 숫자는 작업량에 따라 달라집니다. 전이 가능한 패턴은 크래시 발견을 재현 가능한 테스트, 에이전트 제안 수정, 인간 검토 풀 리퀘스트에 연결하는 것입니다.

사용자가 성능에 의존할 때, 성능은 동작의 일부입니다.

벤치마크:

• 콜드 스타트
• 처리량
• p50 지연 시간
• p95 지연 시간
• p99 지연 시간
• 최대 메모리
• 바이너리 크기
• 빌드 시간
• 대표 작업 부하 하에서의 CPU

평균 대신 분포를 비교하세요. 마이그레이션 전에 예산을 설정하여 팀이 리라이트에 많은 투자를 한 후에 성능 저하를 합리화하지 못하게 하세요.

장시간 테스트도 실행하세요. 메모리 누수, 디스크립터 누수, 큐 증가, 할당기 단편화, 드문 경쟁 상태는 표면화되는 데 몇 시간 또는 며칠이 걸릴 수 있습니다.

더 강력한 메모리 안전 보장을 제공하는 언어는 전체 버그 클래스를 제거할 수 있지만, 다른 할당, 스케줄링 또는 성능 동작을 도입할 수도 있습니다.

안전하지 않은 코드, FFI 및 보안 경계를 별도로 검토하세요

다음 각각을 별도의 검토 클래스로 취급하세요:

• unsafe 블록
• FFI 호출
• 원시 포인터
• 사용자 정의 할당기
• 암호화 경계
• 파서
• 역직렬화기
• 권한 검사
• 인증 로직
• 지속성 경계

소스 보고서 기준으로, Bun은 Rust 약 780,000줄 중 약 27,000줄이 unsafe 블록 내에 있으며, 그 중 상당 부분이 C 및 C++ 통합과 관련되어 있다고 설명했습니다.

해당 표면은 일반 코드 검토 이상이 필요합니다.

모든 안전하지 않은 경계 근처에 불변 조건 주석을 요구하세요:

• 무엇이 참이어야 하는가?
• 누가 불변 조건을 설정하는가?
• 포인터가 얼마나 오래 유효한가?
• 어떤 스레드가 값을 소유하는가?
• 어떤 테스트가 조건을 실행하는가?

반복되는 안전하지 않은 패턴을 검토된 래퍼 뒤에 그룹화하세요. 전체를 허영 지표로 처리하지 말고, 소유자별로 안전하지 않은 줄과 블록을 추적하세요.

다음을 사용하세요:

• 정적 분석
• 샌나타이저
• 의존성 감사
• 퍼징
• 수동 보안 검토

Bun의 11회 보안 검토 라운드는 지속적인 강화의 증거이지, 결함이 없었다는 증거가 아닙니다.

자동화된 보안 검토는 도메인 검토를 보완해야 하며, 특히 인증, 샌드박스 이스케이프, 비밀, 공급망 변경과 관련하여 중요합니다.

마이그레이션 메커니즘 자체를 검토하세요. 에이전트는 저장소 콘텐츠, 빌드 스크립트 및 도구 출력을 실행합니다. 손상된 의존성이나 소스 코드의 숨겨진 명령이 실행에 영향을 줄 수 있습니다.

파일 시스템 격리, 네트워크 제한, 범위가 지정된 토큰 및 변경 불가능한 CI 검사는 이 위험을 줄입니다.

단계별로 릴리스하고 필요하기 전에 롤백을 연습하세요

병합은 릴리스가 아닙니다.

알려진 커밋, 툴체인, 의존성 잠금 및 증명 매니페스트에서 버전 관리된 아티팩트를 빌드하세요. 이전 구현을 빌드 가능한 상태로 유지하세요.

이전 및 새 바이너리가 공존할 수 있다면 런타임 스위치 또는 라우팅 레이어를 추가하세요.

경로를 비가역적으로 대체하기보다는,

부작용을 격리할 수 있을 때 섀도우 실행으로 시작하십시오.

그런 다음 다음을 통해 카나리를 수행하십시오:

• 내부 사용자
• 위험도가 낮은 테넌트
• 플랫폼
• 리전
• 트래픽 비율

다음에 대한 자동 롤백 임계값을 정의하십시오:

• 정확성 불일치
• 충돌률
• 지연 시간
• 메모리
• 오류 범주
• 지원 신호

자동화된 임계값이 작동하지 않더라도 사람이 확장을 중단할 수 있는 능력을 유지해야 합니다.

롤백을 연습하십시오.

다음 사항을 확인하십시오:

• 이전 아티팩트가 성공적으로 시작되는지
• 스키마가 호환되는지
• 대기 중인 작업이 처리될 수 있는지
• 관찰 가능성 도구가 각 요청을 처리한 구현을 식별하는지
• 측정된 롤백 시간이 운영 목표를 충족하는지

한 번도 실행되지 않은 롤백 문서는 단지 가설에 불과합니다.

모든 장애가 발생한 후에는 계약, 의미 매핑, 테스트 코퍼스 및 위험 모델을 업데이트하십시오.

Bun의 알려진 19개 회귀는 반복되는 번역 위험을 드러내기 때문에 유용합니다. 마이그레이션은 생성된 diff가 병합될 때가 아니라 새 구현이 작동 가능하고 팀이 그로부터 학습했을 때 완료됩니다.

재사용 가능한 AI 마이그레이션 정책 및 증거 명세서

다음 YAML은 재사용 가능한 팀 아티팩트로 설계되었습니다. 명령, 임계값 및 소유자를 저장소에 맞게 조정하십시오.

We0 AI 또는 다른 오케스트레이션 시스템은 이 정책을 마이그레이션 작업에 첨부하고 검토 전에 증거 명세서를 요구할 수 있습니다.

ai_migration:
  name: payments-python-to-go
  contract: docs/MIGRATION_CONTRACT.md
  semantic_map: docs/PORTING_RULES.md
  old_reference: artifacts/payments-python@sha256:OLD
  new_candidate: artifacts/payments-go@sha256:NEW

  worker_policy:
    isolation: ephemeral_worktree
    one_writer_per_unit: true
    forbidden_commands:
      - "git reset --hard"
      - "git stash"
      - "git push --force"
    editable_paths: ["cmd/", "internal/", "tests/migration/"]
    protected_paths: ["tests/contracts/", "docs/MIGRATION_CONTRACT.md"]

  required_gates:
    compile: "go build ./..."
    unit: "go test ./..."
    contracts: "./scripts/run-contract-tests.sh"
    differential: "./scripts/compare-old-new.sh --corpus fixtures/replay"
    fuzz: "./scripts/fuzz.sh --hours 24 --unique-crashes 0"
    security: "./scripts/security-scan.sh --severity high"
    performance:
      p99_latency_regression_pct: 5
      peak_memory_regression_pct: 10
    platforms: [linux-amd64, linux-arm64]

  independent_review:
    fresh_context: true
    reviewers_per_unit: 2
    require_counterexample_search: true

  rollout:
    shadow_hours: 48
    canary_percentages: [1, 5, 20, 50, 100]
    rollback_artifact_required: true
    rollback_drill_required: true

  evidence_manifest:
    include:
      - contract_version
      - source_and_target_commits
      - changed_units
      - commands_and_exit_codes
      - differential_mismatches
      - fuzzing_summary
      - benchmark_distributions
      - unsafe_or_ffi_inventory
      - reviewer_findings
      - approved_exceptions
      - rollback_drill_result

이 정책은 구현 작업자가 계약 또는 승인된 계약 테스트를 편집하는 것을 의도적으로 방지합니다.

다음을 요구합니다:

• 참조 아티팩트
• 독립적인 검토
• 정량적 증거

성능 한계

• 롤아웃 증거
• 검증된 롤백 경로

예외는 가능하지만, 프롬프트 내에 숨겨서는 안 되며 문서화되고 승인되어야 합니다.

생성된 분량이 아닌 검증된 진행 상황을 측정하라

코드 줄 수, 에이전트 수, 경과 일수는 흥미로운 용량 지표입니다. 이들은 제품 성공을 측정하지 않습니다.

균형 잡힌 마이그레이션 성과표를 사용하십시오.

검증된 단위 처리량

다음 조건을 충족하는 마이그레이션 단위를 추적하십시오:

• 컴파일 성공
• 대상 계약 검사 통과
• 독립적인 검토 수령
• 회귀 없이 통합

단위 시간당 승인된 단위를 측정하십시오.

불일치 해소

발견된 차이점과 각각이 다음 중 어떤 상태인지 추적하십시오:

• 설명됨
• 수정됨
• 의도적으로 승인됨
• 아직 해결되지 않음

누출된 결함

잡아야 할 관문을 통과한 결함을 추적하십시오.

각 누출된 결함은 누락된 계약 규칙, 테스트, 오라클, 검토 단계 또는 롤아웃 임계값을 식별해야 합니다.

인간의 주의력

인간이 다음 작업에 소비한 시간을 측정하십시오:

• 계약 정의
• 모호성 해결
• 고위험 코드 검토
• 불일치 조사
• 배포 운영

AI는 구현 시간을 줄이면서 사양 품질을 향상시킬 수 있습니다. 이는 자동화 실패가 아닌 좋은 절충입니다.

컴퓨팅 및 도구 비용

승인된 단위당 총 모델, 컴퓨팅 및 도구 비용을 측정하십시오.

동적 워크플로우는 일반 세션보다 더 많은 토큰을 소비할 수 있습니다. 병렬 처리는 더 큰 검증 백로그를 만들지 않으면서 가치 있는 작업의 대기 시간을 줄일 때 정당화됩니다.

마이그레이션 후 유지보수성

다음을 추적하십시오:

• 시작 시간
• 빌드 속도
• 변경 실패율
• 검토 지연 시간
• 결함 밀도
• 안전하지 않은 모듈의 소유권
• 디버깅 용이성
• 운영 문서의 품질

빠르게 전환되었지만 팀에 불투명한 포트는 부채를 제거한 것이 아니라 이동시킨 것입니다.

팀이 수백만 줄의 재작성 없이 시작하는 방법

실시간 참조 구현이 있는 경계가 명확한 마이그레이션을 선택하십시오. 예:

• 하나의 SDK 버전 변경
• 하나의 프레임워크 하위 시스템
• 하나의 CLI 명령
• 하나의 서비스 엔드포인트

한 페이지 분량의 동작 계약과 세 가지 위험 중심의 파일럿 사례를 작성하십시오.

구현과 검토를 위해 별도의 에이전트 작업을 사용하여 컨텍스트가 독립적으로 유지되도록 하십시오.

구현 전:

1. 승인 검사를 고정하십시오.
2. 구현자에게 산문 주장이 아닌 커밋과 증거를 반환하도록 요구하십시오.
3. 검토자에게 반례를 찾고 누락된 테스트를 식별하도록 요청하십시오.
4. 모델 외부의 CI에서 검사를 실행하십시오.
5. 파일럿이 성공한 후에만 다음 종속성 레이어로 확장하십시오.

완전한 실행 기록을 유지하십시오:

• 프롬프트
• 모델
• 도구 범위
• 소스 커밋
• 대상 커밋
• 변경된 경로
• 검사
• 실패
• 검토자 발견사항
• 예외
• 비용
• 최종 결정

이 기록을 통해 팀은 에이전트가 본 내용을 추측하지 않고 하네스 버전을 비교하고 결함을 조사할 수 있습니다.

간단한 채택 규칙을 사용하십시오:

자율성은 획득되어야 합니다.

검증된 단위를 반복적으로 생산하는 워크플로우는 더 넓은 파일 범위 또는 더 긴 무인 실행 시간을 받을 수 있습니다. 자동으로 배포 권한을 받지는 않습니다.

능력, 증거 및 권한은 분리되어 유지됩니다.

한계: Bun 사례가 증명하지 못하는 것

Bun은 특이한 프로젝트입니다.

그 창시자는

다음은 입력 내용을 자연스럽고 정확한 한국어로 번역한 결과입니다.

migration, had deep knowledge of the codebase, and held direct architectural authority. The old implementation had a large test suite, Rust provided strong compiler feedback, and the project could use substantial parallel compute.

대부분의 팀은 이러한 모든 이점을 공유하지 못할 것입니다.

이 사례는 또한 Anthropic을 통해 발표되었으며, 원본 기사에 따르면 이 작업은 사전 출시된 Claude Fable 5 모델을 사용했다고 합니다. 이는 가치 있는 1차 증거이지만, 독립적인 벤더 비교는 아닙니다.

인간 팀이 얼마나 시간이 필요했을지에 대한 주장은 반사실적(counterfactual) 추정치입니다. 팀은 단 한 번의 성공적인 마이그레이션만으로 조달 결정을 내려서는 안 됩니다.

보고된 19건의 회귀(regression)는 알려진 회귀일 뿐이며, 전체 개수를 보장하지 않습니다. 퍼징(fuzzing) 실행과 보안 검토 라운드는 결함이 없음을 의미하는 것이 아니라 노력의 정도를 측정합니다.

가장 확실하게 방어할 수 있는 결론은 다음과 같이 신중합니다:

강력한 결정론적 피드백과 전문가 조정이 결합될 때 대규모 AI 기반 마이그레이션이 가능하지만, 코드 생성이 완료된 후에도 그 위험은 여전히 엔지니어링 문제로 남아 있습니다.

이 결론은 여전히 의미가 있습니다. 팀은 구현 규모와 동일한 수준의 사양 정의, 검증, 통제된 출시에 대한 예산을 편성한다면, 이전에 비용으로 인해 지연되었던 현대화 프로젝트를 시도할 수 있습니다.

실용적인 마이그레이션 체크리스트

• 보존, 변경, 폐기 및 알 수 없는 동작을 정의하십시오.
• 플랫폼, 성능, 원격 측정, 오류 및 부작용 계약을 목록화하십시오.
• 위험한 소스-대상 패턴에 대한 의미론적 맵을 구축하십시오.
• 구현 작업자로부터 계약 및 승인된 테스트를 보호하십시오.
• 저장소 전체로 확장하기 전에 어려운 파일럿 유닛을 실행하십시오.
• 작성자를 격리하고 파괴적인 Git 및 네트워크 작업을 제한하십시오.
• 명령어, 출력 및 계약 참조가 포함된 원자적 커밋을 요구하십시오.
• 고위험 유닛에 대해 새로운 컨텍스트의 적대적 검토자를 사용하십시오.
• 컴파일러, 단위, 계약, 통합 및 크로스-플랫폼 게이트를 실행하십시오.
• 대표적인 코퍼스(corpora)에서 이전 구현과 새 구현을 비교하십시오.
• 메타모픽(metamorphic), 퍼즈(fuzz), 새니타이저(sanitizer) 및 성능 검사를 추가하십시오.
• unsafe, FFI, 인증, 파서 및 지속성 경계를 목록화하십시오.
• 재현 가능한 롤백 아티팩트를 보존하고 롤백 훈련을 실행하십시오.
• 자동 중지 임계값과 함께 섀도우(shadow) 및 카나리(canary) 단계를 통해 출시하십시오.
• 발견된 모든 결함을 계약 또는 검증 개선 사항으로 전환하십시오.
• 검증된 유닛, 불일치, 인간의 개입, 비용 및 유지보수성을 측정하십시오.

FAQ

Bun이 Rust로 다시 작성한 것은 무엇입니까?

Bun은 이전에 Zig로 작성되었던 주요 구현을 Rust로 마이그레이션했습니다. 공개된 설명에 따르면 약 78만 줄의 Rust 코드와 고도로 병렬화된 AI 지원 워크플로우가 사용되었으며, 이후 광범위한 테스트, 보안 검토, 퍼징 및 프로덕션 강화가 이어졌습니다.

AI가 인간의 검토 없이 Bun의 Rust 재작성을 완료했습니까?

아닙니다. 인간이 작성한 마이그레이션 규칙, 수동 아티팩트 검토, 격리된 워크플로우, 컴파일러 피드백, 독립적인 에이전트 검토자, 보안 검토, 퍼징 및 프로덕션 출시 제어가 모두 중요한 역할을 했습니다. 이 사례는 무인 코드 변환보다는 AI 가속 엔지니어링으로 이해하는 것이 더 적절합니다.

왜 기존 테스트만으로는 충분하지 않습니까?

언어 마이그레이션?

기존 테스트는 보통 관찰된 동작의 일부만을 다룹니다. 릴리스 전용 의미론, 플랫폼 차이, 성능 저하, 안전하지 않은 경계, 원격 분석 변경 또는 테스트 스위트에 포함되지 않은 경계 사례를 놓칠 수 있습니다.

코드 마이그레이션에서 차등 테스트란 무엇인가?

차등 테스트는 동일한 입력으로 이전 구현과 새 구현을 실행하고 관찰 가능한 출력과 부작용을 비교합니다. 이는 이전 시스템이 신뢰할 수 있지만 완전한 공식 명세가 존재하지 않을 때 특히 유용합니다.

구현 검토 에이전트와 리뷰 에이전트가 별도의 컨텍스트를 사용해야 하는 이유는 무엇인가?

새로운 리뷰어는 작성 에이전트의 가정과 추론 오류를 물려받을 가능성이 낮습니다. 리뷰어는 변경을 생성한 구현 경로를 방어하는 대신 계약, 차이(diff), 증거 및 반례에 집중할 수 있습니다.

팀은 마이그레이션 중 unsafe Rust 코드를 어떻게 검토해야 하는가?

모든 unsafe 블록 또는 FFI 경계에는 명명된 소유자, 문서화된 불변 조건, 대상 테스트, 포인터 유효성, 수명 및 스레드 소유권에 대한 명확한 설명이 있어야 합니다. 정적 분석, 샌타이저, 퍼징, 의존성 검토 및 수동 보안 검토는 일반 코드 검토와 별도로 적용되어야 합니다.

AI 지원 마이그레이션이 추적해야 할 지표는 무엇인가?

검증된 단위 처리량, 불일치 종료, 누출된 결함, 인간의 주의, 컴퓨팅 비용, 출시 상태 및 마이그레이션 후 유지보수성을 추적하세요. 생성된 라인 수와 에이전트 수는 용량 지표일 뿐 정확성의 증거가 아닙니다.

소규모 팀이 수십 개의 에이전트를 실행하지 않고 이 플레이북을 사용할 수 있는가?

네. 하나의 제한된 구성 요소, 서면 행동 계약, 세 가지 위험 중심 파일럿, 분리된 구현 및 검토 컨텍스트, 결정론적 CI 게이트, 그리고 테스트된 롤백 경로로 시작하세요. 반복적으로 검증 가능한 결과를 생성한 후에만 워크플로를 확장하세요.

관련 도구

• Bun: 모든 것이 포함된 JavaScript 및 TypeScript 툴킷으로, 이 플레이북의 주요 사례 연구는 Rust 마이그레이션에서 제공됩니다.
• Rust: 강력한 컴파일 타임 안전성 보장과 명시적인 unsafe 경계를 제공하는 시스템 프로그래밍 언어입니다.
• Claude Code: Anthropic의 에이전틱 코딩 환경으로, 원본 자료에서 설명하는 동적 워크플로에 사용됩니다.
• GitHub Actions: 결정론적 컴파일, 테스트, 보안, 벤치마크 및 증거 게이트에 적합한 CI/CD 플랫폼입니다.
• cargo-fuzz: libFuzzer 기반의 Rust 프로젝트를 위한 표준 퍼징 도구입니다.
• Miri: unsafe 코드에서 특정 형태의 정의되지 않은 동작을 감지할 수 있는 Rust 인터프리터입니다.

관련 링크

• Bun: Rust로 Bun 다시 작성하기: Bun의 공식 엔지니어링 계정으로, 재작성, 프로덕션 강화, 퍼징 및 알려진 회귀에 대해 설명합니다.
• Bun 소스 저장소: Rust 구현, 이슈, 테스트 및 마이그레이션 기록이 포함된 공식 Bun 저장소입니다.
• Anthropic: 동적 워크플로 소개

요약

Bun의 Rust 재작성은 AI 코딩 에이전트가 구현 시간을 획기적으로 단축시킬 수 있음을 증명했지만, 동시에 검증이 일급(first-class) 엔지니어링 시스템이 되어야 하는 이유도 보여주었습니다. 계약(Contracts), 의미론적 맵(Semantic Maps), 격리된 워커(Isolated Workers), 독립적인 검토(Independent Review), 차등 테스트(Differential Testing), 퍼징(Fuzzing), 성능 예산(Performance Budgets), 단계적 롤아웃(Staged Rollout)은 생성된 코드를 신뢰할 수 있는 마이그레이션 증거로 전환시키는 요소들입니다.

실용적인 교훈은 에이전트 수나 코드 줄 수를 따라 하는 것이 아닙니다. 마이그레이션을 경계가 명확한 주장들로 나누고, 각 주장에 대해 결정적인 증명을 요구하며, 워크플로우가 반복적으로 신뢰할 수 있는 결과를 생성한 후에만 자율성을 확장하는 것입니다.

대규모 AI 지원 재작성은 생성된 코드가 병합되었을 때가 아니라, 새 시스템이 검증되고, 운영 가능하며, 복구 가능하고, 이해되었을 때 비로소 완료됩니다.