중국 Xiaomi, AI에게 JDK 21 마이그레이션을 맡겨 작업 시간을 획기적으로 단축한 '제약 설계도'

AI에게 JDK 마이그레이션을 맡겼더니, 실행되지 않는 정기 작업(scheduled job) 부품의 등록 어노테이션을 주석 처리하여 ‘실행’시키고 있었습니다. 중국 Xiaomi 기술팀이 공개한 JDK 21 마이그레이션 실전기는 이러한 실패담에서 시작됩니다. 그리고 그 경험을 바탕으로 재구축된 절차를, 누구나 따라 할 수 있는 구체적인 단계로 작성했습니다.

본 기사는 Xiaomi의 공식 기술 계정인 'Xiaomi 기술'이 2026년 7월 10일에 공개한 글입니다. 대상은 '구 버전 JDK → JDK 21 + Spring Boot 3.5.3'이며, 마이그레이션 전후의 JDK 번호나 서비스 총수는 명시되어 있지 않습니다.

• 프로젝트당: 30개 이상의 파일 수정, 50개 이상의 의존성 추가/업데이트/삭제, 대량의 설정 및 시작 파라미터 변경
• 소요 시간: 인력 투입 시 1영업일 이상, 단순한 Vibe Coding을 사용해도 약 1영업일, 개선 후는 0.5~1.5시간
• 단일 대화로 마이그레이션 완료 비율: Vibe Coding은 0%, 개선 후는 70%(나머지 30%는 필요한 지점에서 사람이 개입)
• 병렬 처리 능력: 인력 투입 시 1인당 1프로젝트, 개선 후에는 1인이 5개 이상의 프로젝트를 모니터링
• 마이그레이션 후 (사내 다수 프로젝트의 실제 운영 환경 비교): CPU 사용률 평균 약 22.5% 감소, Heap 메모리 평균 약 23% 감소, P99 레이턴시 평균 18.1% 감소(최대 47% 감소, 548ms→288ms), 분당 GC 정지 시간은 1ms 미만

소스에서 언급된 실패 사례는 일본 현장에서도 자주 볼 수 있는 유형입니다.

• 컴파일이 통과되었다고 보고하고 시작했으나, 실행 시 오류가 지속적으로 발생하는 경우
• 정기 작업 부품의 초기화에 실패하자, 등록 어노테이션을 주석 처리하여 가동시킨 경우 (실제 기능은 작동하지 않음)
• Lombok 오류를 버전 다운으로 해결한 경우 (정답은 1.18.32 이상으로 업데이트하는 것)
• javax→jakarta로 일부만 치환하고, 오히려 JDK 표준인 javax.crypto까지 수정해버린 경우
• CMS의 GC 옵션에서 에러가 나자, GC 설정 자체를 삭제한 경우
• Spring Boot 의존성 교체 과정에서 로그 기반 시스템이 log4j2에서 Logback으로 바뀌어 버린 경우

결론은 '모델의 성능에 의존하는 것이 아니라, 시스템적인 제약(mechanism)으로 묶는 것'이었습니다. 이를 그들은 Harness Engineering이라고 부릅니다.

1. 암묵지를 AI가 처리할 수 있는 파일 형태로 추출하기

AGENTS.md<br>
(기술 스택, 빌드/시작 명령어, 자주 발생하는 함정)
, code_standard.md<br>
('thrift의 자동 생성된 .java는 건드리지 않는다', 'log4j:log4j는 제외' 등과 같은 규칙)
, security_base.md
을 매번 AI에게 읽히게 합니다.

2. 작업을 툴(Tool)로 만들기

의존성 트리 분석, JUnit 5/4를 사용한 결합 테스트, 코드 리뷰, PR 생성, GitLab 조작 등을 Skill 형태로 준비했습니다. MCP에서는 Maven 버전 조회와 Context7 (최신 공식 문서 가져오기)을 활용합니다. AI에게는 '어떤 것을 호출할지'만 판단하도록 합니다.

3. 마이그레이션 Skill에 금지 사항 명시하기

업무 로직 변경, 리팩토링, 기능 추가/삭제, I/F 입출력 변경을 금지하고, '필요한 호환성 수정만'이라고 명확히 기재합니다.

4. 5단계로 고정화하기

(1) Maven 플러그인 업데이트 (compiler 3.12.1+, surefire 3.2.5+) → (2) POM 의존성 정리 (javax 계열 제거 후 jakarta로 변경) → (3) JVM 인자 정리 (CMS/PermGen 삭제 및 --add-opens 또는 G1/ZGC 추가) → (4) 코드 호환성 수정 (JUnit 4→5 포함) → (5) 모듈 단위로 mvn clean compile과 mvn test를 실행. 실패하면 이전 단계로 돌아갑니다.

5. 경험을 회수하기

작업 완료 후 jdk-upgrade-lessons가 가동되어, 블로커(blocker), 숨겨진 함정(hidden trap), 설정 누락, 의존성 충돌, 코드 마이그레이션 5가지 관점에서 되짚어봅니다. 이 결과를 바탕으로 다음 버전의 Skill을 생성합니다.

소스에서는 이곳이 가장 효과적이었다고 강조합니다. 마이그레이션 전에, AI에게 주요 기능에 대한 결합 테스트를 작성하게 합니다. 조건은 다음과 같습니다.

• 각 테스트에 @Timeout을 붙일 것
• Spring Context를 실제로 로드하여, Mocking으로 인한 가짜 합격을 방지할 것
• 합격/불합격 여부와 실패 이유를 구조화하여 출력할 것

마이그레이션 후에는 동일한 테스트를 재실행하며, '컴파일만 통과되었다'는 것으로 완료를 인정하지 않습니다. 마지막에는 사람이 코드 리뷰를 통해 품질을 확인합니다.

• '완료'의 정의를 컴파일 성공이 아닌, 테스트 통과를 조건으로 한다.
• 금지 사항을 작성하지 않으면 AI가 '곁다리 최적화'를 시작하며 범위가 계속 넓어진다.
• 지식을 한 파일에 몰아넣지 않는다.
  SKILL.md

를 진입점으로 삼고, maven/dependency/jvm/code 참조 파일은 필요한 경우에만 읽게 한다. (덧붙이자면, Windows 환경에서는 AI가 Unix 스타일의 셸 구문을 사용하려는 경향이 있어 PowerShell용 규칙까지 준비했다.

Java 8/11 Spring Boot 모놀리스를 보유한 현장일수록 이 방식이 효과적이다. 첫 번째 건은 사람이 동행하며, 그 과정에서 발견된 함정을 lessons에 기록한다. 두 번째 건부터는 '혼자서 여러 프로젝트를 관리하는' 체제로 전환된다. 갑자기 모든 서비스로 확장하기보다, 로그 기반이나 GC 설정 같은 '사내 약속'을 먼저 문서화하는 것이 지름길이다. 마이그레이션 원본 버전이나 서비스 수는 소스에 기재되어 있지 않으므로, 자체적으로 추산할 때는 우리 회사 기준으로 측정해야 한다.

• 샤오미 기술(WeChat 공식 계정) "Vibe Coding에서 Harness Engineering으로: JDK 업그레이드 중 통제 가능한 진화적 AI 엔지니어링 실천" — 2026-07-10 공개 (샤오미 기술 공식 Weibo 공지 2026-07-10 18:18)

https://www.sina.cn/news/detail/5319196412220064.html - 동 기사 전문 전재 (저자 표기: 샤오미 기술) — 53AI, 2026-09-06 게재

https://www.53ai.com/news/LargeLanguageModel/2026090670138.html - 동 기사 전문 전재 (비교표 및 실패 사례, 도구 목록 포함) — 기술棧(jishuzhan.net), 2026-08-01 게재