12주가 아니라 계획 해시를 봐야 한다

결론부터. Shopify가 Shop 앱을 React Native에서 네이티브로 다시 짰고 12주가 걸렸다. 여기서 1인 개발자가 가져갈 것은 12주라는 숫자가 아니라 그들이 만든 검증 장치 두 개다.

먼저 숫자를 깎고 시작한다

콜드 스타트는 iOS 3,200ms → 2,466ms(23% 단축), Android 4,433ms → 2,233ms(50% 단축). 충돌 없이 유지되는 세션은 99.5% 이상에서 99.95% 이상으로, 충돌 세션이 10분의 1이 됐다. Android 릴리스 빌드는 293MB에서 184MB로 줄었다.

좋은 결과인데, 조건을 같이 봐야 한다.

• 핵심 엔지니어 6명이 붙었고 기능별 팀이 검증에 합류했다. "AI가 12주 만에 했다"가 아니라 전문가 여럿 + 에이전트가 12주다.
• 참조할 기존 구현이 있었다. 원문이 직접 말한다 — 에이전트는 참조할 기존 구현이 있을 때 특히 효과적이었다고.
• Shopify 자체 발표다. 실패한 시도는 여기 없다.

그리고 원문 스스로 선을 긋는다.

생성 코드가 기능 요구사항을 충족하더라도 중복, 아키텍처 이탈, 성능 문제를 만들 수 있다. 네이티브 전문성은 여전히 필수적이다.

(원문)

가져갈 것 1 — 계획 해시에 승인을 묶는다

이게 이 글에서 제일 값싸고 제일 좋은 아이디어다.

엔지니어는 구현 전에 요구사항과 계획을 검토하고, 계획 내용의 해시에 승인을 연결한다. 계획이 바뀌면 이전 승인이 무효화돼, 실제로 검토한 구현 계획에만 승인이 유효하도록 한다.

에이전트에게 큰 작업을 맡길 때 흔한 실패가 이거다. 계획을 보여주고 "좋아, 진행해"라고 했는데, 진행하면서 계획이 조용히 바뀐다. 그리고 결과를 볼 때쯤이면 내가 승인한 게 무엇이었는지 기억이 흐릿하다.

계획 텍스트를 해시로 고정하면 이 문제가 구조로 사라진다. 계획이 바뀌면 승인이 깨지고, 다시 물어야 한다.

이번 주에 스킬 파일은 습관을 바꾸지 권한을 못 막는다고 썼다. 이건 그 반대편의 좋은 예다. 말로 부탁하지 않고 구조로 강제한 것. 1인 개발자도 오늘 할 수 있다. 계획을 파일로 저장하고 해시를 찍어두는 데 몇 줄이면 된다.

가져갈 것 2 — 동작 동등성을 사람 눈으로 확인하지 않는다

Tardis라는 자체 도구로 두 앱을 비교했다. 이름 붙인 체크포인트마다 스크린샷과 그 구간의 이벤트를 캡처하고, 이벤트 이름·횟수·페이로드 필드를 대조한다. 타임스탬프나 페이지 UUID처럼 실행마다 자연스럽게 달라지는 값은 비교에서 제외하도록 지침을 뒀다.

핵심은 분석 이벤트까지 보존 대상으로 잡았다는 것이다. 화면이 똑같아 보여도 뒤에서 나가는 이벤트가 달라지면 추천 시스템이 조용히 망가진다. 사용자는 모르고, 대시보드는 며칠 뒤에 이상해진다.

나흘 전 글에서 에이전트가 자기가 쓴 테스트가 실제로 실패하는지 확인하지 않는다는 실험을 인용했다. Tardis는 그 문제의 해답 쪽이다. "됐다고 말했는지"가 아니라 "실행해서 같은 게 나오는지"를 본다.

혼자 만드는 사람이 Tardis를 만들 필요는 없다. 옮기기 전후로 같은 조작을 하고 로그를 diff 하는 스크립트 하나면 원리는 같다.

이 사례를 잘못 쓰는 법

"AI로 앱을 다시 짤 수 있다"로 읽으면 안 된다. 이건 정답지가 있는 작업이었다. 기존 앱이 화면·흐름·이벤트의 명세 역할을 했고, 에이전트는 그걸 보고 옮겼다.

신규 기능 개발에는 그 정답지가 없다. 마이그레이션과 재작성에서 나온 성공률을 백지 개발에 그대로 옮기면 틀린다. 이건 이 사례의 한계가 아니라 적용 범위의 문제다.

모르는 것

12주 동안 무엇이 실패했는지. 자체 발표라 그 부분이 없다. 그리고 계획 해시 승인이 실제로 몇 번이나 재승인을 유발했는지 — 그 빈도가 이 장치의 실효성을 말해줄 텐데 숫자가 없다.