||
마이리얼트립 Experience팀 김관주 님
여행 상품을 예약할 때, 마이리얼트립은 여러 외부 파트너사의 시스템과 실시간으로 연결됩니다. 파트너사마다 연결 방식이 제각각이라, 그 차이를 흡수해주는 어댑터 코드가 시스템 안에서 묵묵히 핵심 역할을 합니다. 그런데 이 코드들이 모두 곧 종료될 기존 시스템에 묶여 있었습니다. 새 시스템으로 옮겨야 하는데, 구조가 근본적으로 달라 단순 복사로는 불가능했습니다.
수작업으로 하면 1명이 9개월. 마이리얼트립 Experience팀의 김관주님은 이 문제를 전혀 다른 방식으로 접근했습니다. 수년간 검증된 레거시 코드 자체를 AI의 학습 자료로 삼은 것입니다.
이 글에서는 마이리얼트립 사내 기술 공유 세션인 ‘모두의AI’에서 김관주님이 발표한 내용을 바탕으로, AI를 활용한 대규모 시스템 이관 사례를 소개합니다.
왜 단순 포팅이 불가능했는가
2.0 시스템은 수년간 프로덕션에서 안정적으로 운영되어 온 검증된 코드베이스였습니다. 하지만 종료(deprecated) 예정이었고, 2.0과 3.0의 매니저가 달라 사업팀에서는 이중 관리 부담이 발생하고 있었습니다. 리소스는 계속 투입되는데 시스템은 곧 사라질 예정이라는 모순적인 상황이었습니다.
단순히 코드를 복사해서 옮기면 될 일 같지만, 그렇지 않았습니다. 2.0과 3.0은 구조, 상태머신(예약·취소 등 흐름을 관리하는 체계), 에러 처리 방식이 근본적으로 달랐습니다. 김관주님은 이렇게 설명했습니다.
“수작업으로 하면 한 명이 9개월 걸린다는 계산이 나왔습니다. 구조도 다르고, 상태머신도 완전히 다르고, 에러처리 체계도 완전히 달랐기 때문입니다.”
9개 연동사 어댑터 각각이 고유한 API 스펙과 비즈니스 로직을 갖고 있었고, 이를 새로운 아키텍처에 맞게 재설계해야 했습니다. 이관 대상은 연동에 필요한 전 영역의 코드에 걸쳐 있었습니다.
레거시 코드에서 지식을 꺼내다
김관주님이 주목한 건 역설적이게도 레거시 코드 그 자체였습니다. 수년간 운영되면서 축적된 비즈니스 로직(실제 서비스 운영 규칙), 하드코딩된 특수 규칙, 문서화되지 않은 암묵적 지식이 모두 2.0 코드베이스 안에 있었습니다.
“수년간 운영에서 검증된 코드베이스라는 SOT(Source of Truth)가 있었습니다. 문서화되지 않은 하드코딩 히스토리, 암묵적 비즈니스 로직이 모두 그 안에 있었습니다.”
접근법은 이랬습니다. 먼저 AI를 활용해 2.0 코드베이스에서 연동사별 API 스펙, 하드코딩된 특수 규칙, 암묵적 비즈니스 로직을 마크다운 문서로 추출했습니다. 코드 속에 흩어져 있던 지식을 체계적인 문서로 변환한 것입니다.
다음으로, 추출된 문서만으로 구현이 가능한지 검증할 수 있는 체크리스트를 만들었습니다. 이 체크리스트는 이후 AI가 생성한 코드의 품질을 판단하는 기준이 됩니다.
그리고 코드만으로는 파악할 수 없는 영역이 있었습니다. 운영 과정에서 쌓인 노하우, 코드에는 반영되지 않은 예외 상황 처리 같은 암묵지입니다. 이 부분은 팀 내 연동 전문가가 직접 보완했습니다.
레거시 코드를 SOT로 삼고, AI로 지식을 추출하고, 사람이 빈틈을 메우는 구조. 이것이 이번 이관의 핵심 설계였습니다.
하룻밤, 5만 라인
마크다운 가이드 문서가 완성되자 본격적인 코드 생성에 들어갔습니다. AI가 코드를 생성하고, 테스트를 돌리고, 실패하면 다시 수정하는 반복 루프를 설계했습니다. 테스트를 통과할 때까지 자동으로 반복하는 구조입니다.
“하룻밤 돌리니까 5만 라인짜리 코드 변경 제안서가 완성됐습니다. 다 AI가 짰습니다.”
9개 연동사에 필요한 전 영역의 코드가 자동으로 생성되었습니다. 1명이 9개월 걸릴 작업의 초안이 하룻밤 만에 나온 것입니다.
물론 AI가 생성한 코드를 그대로 배포한 건 아닙니다. 하지만 결과는 기대 이상이었습니다.
“5만 라인의 코드 변경 규모를 감안하면, QA에서 발견된 오류는 극소수였습니다.”
김관주님은 이 협업 구조를 이렇게 정리했습니다.
“AI가 빠른 속도로 기반을 만들고, 테스트를 통해 완료선을 친 다음, 정말 미세한 디테일의 오류는 사람