쇼피파이가 화면 300개가 넘는 쇼핑 앱을 리액트 네이티브에서 스위프트·코틀린으로 다시 짜면서, 작업을 작은 체크포인트로 쪼개고 단계마다 행동 테스트와 시각 비교를 통과해야만 다음으로 넘어가는 내부 도구 Helix를 만들었다.
쇼피파이는 모바일 앱을 리액트 네이티브에서 다시 스위프트와 코틀린으로 옮기고 있다. Shop 앱은 이미 12주 만에 새로 짜서 내놨고, 이제 화면이 300개가 넘는 가장 큰 앱인 쇼피파이 앱 차례다. 이번엔 그 작업 대부분을 LLM에 맡기면서, Helix라는 내부 도구로 결과를 통제한다.
왜 통짜로 맡기지 않았나
대부분의 AI 코딩 도구는 정보를 최대한 모아 스펙과 작업 목록으로 만든 다음 한 번에 구현을 끝내고 결과가 맞기를 기대한다. 그러면 엔지니어 손에는 전부 테스트해야 할 거대한 코드 덩어리가 남는다. Helix는 반대로 간다. 첫 결과가 맞을 거라고 기대하지 않고, 작업을 잘게 쪼개 엔지니어에게서 배우면서 맞힌 단계부터 자동화 범위를 넓힌다.
엔지니어가 화면 하나를 지정하면 Helix는 리액트 네이티브 코드를 읽고 체크포인트 순서를 제안한다. 몇 분 안에 검토하고 승인할 수 있을 만큼 작은 단위다. 첫 체크포인트는 보통 화면 뼈대고, 두 번째는 일부러 작게 잡은 한 구역이다. 이후 체크포인트는 앞선 결정이 검토를 통과해야만 커진다.
게이트 1 — CLI로 행동부터 증명한다
Helix가 만든 CLI는 앱과 똑같은 화면 상태와 동작을 노출한다. 예를 들어 홈 화면이라면 분석 정보와 다른 화면으로 이동하는 동작이 그 대상이다. 에이전트는 참조 앱이 어떻게 동작하는지 분석해 그대로 복제하고, CLI 행동 테스트로 검증한다. 이 테스트 케이스는 서브에이전트가 참조 코드를 읽고 체크포인트마다 만들어내는데, 사용자 관점에서 기능을 서술하는 통합 테스트라 해피 패스 바깥의 예외 상황까지 파고들게 유도한다. 시뮬레이터가 필요 없는 만큼 루프가 빨라서, 에이전트는 스크린샷 한 장 찍기 전에 행동만으로 수십 번씩 반복할 수 있다.
게이트 2 — 제미나이가 UI를 대조한다
UI가 똑같은지는 말로 명세하기가 거의 불가능하다. 제목이 살짝 작다거나 구분선이 너무 진하다거나 아이콘이 미묘하게 어긋난 건 사람 눈엔 바로 보여도 프롬프트에는 거의 담기지 않는다. 두 UI 프레임워크가 바이트 단위로 같은 결과물을 내놓지 않으니 픽셀 diff도 통하지 않는다. 쇼피파이는 에이전트에게 시뮬레이터를 조작하도록 가르치는 과정에서, 현재 제미나이 모델이 이런 문제에 공간 감각이 꽤 좋다는 걸 발견했다. 여백과 패딩 차이 같은 UI 뉘앙스를 잡아내고 그 차이를 가늠할 수 있었다. 그래서 이걸 게이트로 만들었다. 오케스트레이터 역할을 하는 GPT가 구현 화면과 참조 화면을 같은 상태로 캡처해 제미나이에 넘기면, 제미나이는 까다로운 디자인 리뷰어가 되어 구조와 간격, 정렬을 각 스크린샷의 치수에 비례해 따진다.
게이트를 통과하지 못하면 에이전트는 그 피드백으로 구현을 고치고 다시 검사를 받는다. 몇 번이든 다시 시도할 수 있지만, 결과가 충분히 좋아 보인다는 이유로 검사를 건너뛸 수는 없다.