‘AI로 54만 줄의 코드를 2주 만에 이전했다’는 이야기를 듣고, 현업 엔지니어들이 가장 먼저 의심했던 부분입니다. 중국에서 화제가 된 이 사례는 후속 기사에서 ‘2주’라는 기간 동안 어떤 과정을 거쳤는지와 AI를 구체적으로 제약한 규칙까지 공개하고 있습니다. 숫자 자체보다도 그 절차 자체가 가져갈 가치가 더 큽니다.
케이스 규모 (소스에 명시된 수치만)
- 대상: 가동 기간 10년, 약 54만 줄의 PHP로 작성된 이커머스 핵심 시스템(상품 목록, 가격, 검색 등). 미국 및 캐나다 사이트를 지원함.
- 상태: 문서화 부족, 단위 테스트(Unit Test), 통합 테스트(Integration Test), 회귀 테스트(Regression Test) 모두 전무.
- 인력 구성: Java에 능숙한 베테랑 4명. Cursor Ultra를 9개 계정으로 사용했으며, 2주간의 도구 비용은 약 1,800달러.
- 기간: 코어 시스템 이전 및 주요 동작 일치화/기본 검증에 2주가 소요됨. 이후 단계적 출시(Staged Release), 모니터링, 세부 수정 작업에 추가로 1주여가 소요됨.
- 결과: PHP 약 54만 줄이 Java 약 22만 줄로 축소. 커밋은 첫 주에 300회 이상(일 평균 약 45회), 둘째 주에는 500회 이상(일 평균 70회 초과).
- 실전 적용: A/B 테스트 결과 주문 수 차이는 -0.8%, 매출 차이는 -0.6%를 기록함. 미국 사이트는 100% 전환, 캐나다는 80%가 적용됨. 롤백(Rollback)이나 P0 등급 장애는 발생하지 않았습니다.
‘2주’라는 기간은 어디까지나 코드의 주요 부분 이전에 걸린 시간입니다. 이 경계를 저자 자신이 명확히 구분하여 서술했다는 점이 신뢰할 수 있는 이유 중 하나입니다.
절차 1: ‘설계 의도 이해’가 아닌 ‘현재 동작 재현’을 목표로 삼기
전환점은 문제 정의 방식을 바꾼 것이었습니다. “왜 이렇게 설계했는지”를 이해하려고 노력하는 것을 멈추고, 대신 “입력이 무엇이고, 무엇을 반환해야 하며, 어떤 항목이 일치해야 하는가”를 기준으로 삼았습니다.
첫 주는 ‘일단 작동하게 만드는’ 주였습니다. 약한 타입 지정의 Map으로 데이터를 주고받던 방식을 Java의 DTO(타입이 지정된 데이터 클래스)로 대체하고, ES 검색, 필터링, 캐싱, 가격 표시 로직을 AI를 이용해 일괄 변환했습니다. 아울러 Redis나 Feign(HTTP API 호출 공통 컴포넌트)도 정비했습니다. 둘째 주는 ‘정확하게 작동하게 만드는’ 주였으며, 차이점 해소, 긴 함수의 분할, PHP 원본 코드와의 대응 주석 추가, 성능 개선 작업을 진행했습니다.
절차 2: 동일한 입력을 PHP와 Java에 보내 두 번 비교하기
테스트가 없는 상태에서의 검증은, 동일한 요청을 신규 시스템과 구형 시스템 양쪽에 전송하여 반환된 내용을 항목별로 대조하는 방식이었습니다.
다만, 그대로 비교하면 캐시 차이 때문에 화면에 차이점이 가득하게 나타납니다. 그래서 비교를 두 번으로 나누어 진행했습니다.
- 첫 번째에서만 차이가 나고, 캐시를 통하지 않은 두 번째에서는 사라진 것: 캐시의 차이이므로 버그가 아님.
- 두 번 모두 차이가 난 것: 업무 로직의 차이이므로 반드시 수정해야 함.
- 두 번째에서 처음 나타난 것: 캐시가 하위 계층의 문제를 숨기고 있었음.
여기에 더해, `
AI는 차이점을 감지했지만, 오히려 역방향으로 수정하여 화면에 에러가 나타나지 않게 되었습니다. 이는 5% 단계적 출시 중에 발견되었으며, 수정하는 데 10분이 걸렸습니다. 상품 수가 PHP보다 적은 경우였습니다. AI와 사람 모두 검색 조건은 올바르다고 판단했지만, 실제로는 응답을 구성하는 단계에서 일부가 누락되어 있었습니다. 이 경험을 통해 '진입점뿐만 아니라 마지막에 값을 할당하는 줄까지 추적한다'는 규칙이 생겼습니다.
- AI가 확인 없이 빌드를 실행하여 조사 중인 상태를 지워버렸습니다. 이후로는 환경에 영향을 주는 작업은 반드시 사람이 확인하도록 했습니다.
사람이 가져야 할 판단
리스크의 높이에 따라 AI에게 맡기는 정도를 3단계로 나누고 있습니다. 핵심 부분은 사람이 주도하고 AI는 보조하며, 중요한 부분은 AI가 구현하고 사람이 엄격하게 리뷰하며, 주변 부분은 AI의 재량을 넓혀주는 방식입니다. 어느 단계에서든 AI에게 먼저 계획(수정할 파일, 절차, 리스크, 영향 범위)을 세우게 하고, 사람이 승인한 후에 실행하도록 했습니다. 배포는 운영 환경과 병행하여 결과를 비교하는 검증부터 시작하고, 소량의 단계적 출시, 분할 전환, 전면 전환 순서로 진행하고 있습니다. 롤백은 단위 시간(분 단위)으로 되돌릴 수 있도록 준비했습니다.
저자는 따라 할 수 있는 전제 조건으로 '경험자 4명', '도구에 대한 투자', '연결 지점이 비교적 명확한 모듈 구성', '업무 부서의 협력'을 언급하며, '2주'라는 숫자만 가지고 경영 판단을 내리지 않도록 당부합니다.
오래된 Java나 PHP 시스템을 보유한 현장에서도, 먼저 비교 명령어와 규칙 파일 두 가지를 준비하는 것부터 시작할 수 있습니다.
출처
Discussion
