AI로 43만 줄을 옮긴 GitHub | 레거시 전환 전 볼 5가지

핵심 요약

• GitHub이 Copilot 여러 제품이 함께 쓰는 런타임을 TypeScript에서 Rust로 옮겼어요. 옮긴 코드는 약 43만 줄이고, 대부분을 AI 에이전트가 작성했어요.
• 한 번에 갈아엎지 않았어요. 약 14.5주 동안 PR 128개로 조금씩 바꿔 끼웠고, 바꿀 때마다 기존 E2E 테스트를 새 코드에 그대로 돌렸어요.
• 사람이 빠진 건 아니에요. 사람 메시지 2,639건 중 31%가 리뷰·테스트·CI 확인이었고, 17.4%는 AI의 설계 판단에 이의를 제기한 내용이었어요.
• 오래된 시스템의 전환·재구축을 앞둔 발주자가 이 사례에서 확인할 5가지를 정리했어요.

📰 2026년 9월 18일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

“AI로 옛날 코드를 새 언어로 옮기면 재구축이 금방 끝나지 않나요?”

요즘 리뉴얼 상담에서 자주 듣는 질문이에요. 마침 GitHub이 그 질문에 답이 될 만한 기록을 내놨어요. 9월 16일(현지 시간) GitHub 블로그에 올라온 글인데, 결론보다 어떻게 검증했는지가 훨씬 길게 적혀 있어요. 발주자에게 쓸모 있는 부분도 그쪽이에요.

---

1. GitHub은 무엇을 옮겼나요

옮긴 대상은 Copilot CLI·Copilot 앱·Copilot SDK가 공통으로 쓰는 에이전트 런타임이에요. 원래 Node.js 위의 TypeScript로 만들어져 있었어요.

문제는 무게였어요. 다른 언어 SDK가 이 런타임을 쓰려면 Node.js를 통째로 같이 띄워야 했고, 글쓴이는 클라이언트마다 최소 100MB 안팎의 메모리가 든다고 적었어요. 그래서 가볍고 다른 프로그램 안에 바로 넣을 수 있는 Rust로 옮기기로 했어요.

항목	발표 내용
옮긴 코드	TypeScript 약 43만 줄 (글쓴이 추정)
결과물	Rust 본코드 832,378줄 + 단위 테스트 468,689줄
기간	5월 초 시작 → 8월 21일 Rust 전환 완료 (약 14.5주)
나눈 단위	PR(코드 변경 묶음) 128개
그동안 배포	135회 (정식 35회 포함)
줄인 외부 패키지	npm 의존성 약 60개 제거

공식 외부 기준 — GitHub 블로그 “Migrating the GitHub Copilot runtime to Rust, using Copilot”(Stephen Toub, 2026년 9월 16일)을 기준으로 했어요. 성능은 “몇 자릿수 좋아졌다”고만 적혀 있고 구체 수치와 비용은 공개되지 않았어요.

2. 왜 한 번에 새로 만들지 않았을까요

레거시 전환이라고 하면 보통 새 시스템을 따로 만들고 어느 날 한꺼번에 바꾸는 장면을 떠올려요. GitHub은 그렇게 하지 않았어요.

PR 하나마다 기존 TypeScript 기능 하나를 Rust로 바꾸고, 옛 코드는 얇은 연결 코드만 남긴 채 지웠어요. 새 코드는 들어간 날부터 실제로 쓰였고, 메인 코드는 늘 배포 가능한 상태였어요. 그사이 다른 팀원들은 기능 개발을 멈추지 않았고요.

구분	한 번에 새로 만들기	조금씩 바꿔 끼우기 (GitHub 방식)
기존 서비스	전환일까지 두 벌을 유지	늘 하나만 운영
문제 발견 시점	오픈 직후 몰아서	바꿀 때마다 조금씩
다른 개발	멈추거나 두 번 반영	계속 진행
필요한 전제	새 시스템 설계서	기존 동작을 잡아 주는 테스트

마지막 줄이 핵심이에요. 조금씩 바꿔 끼우는 방식은 테스트가 있어야 성립해요. 고쳐 쓸지 새로 만들지 판단하는 기준은 홈페이지·시스템 리뉴얼, 고쳐 쓸까 새로 만들까에 따로 정리했어요.

3. “한 사람이 몇 달 만에”는 어떻게 읽어야 하나요

글쓴이는 에이전트가 없던 시절이면 개발팀이 1～2년 걸렸을 일을 주로 개발자 한 명이 몇 달 만에 끝냈다고 적었어요. 이 문장만 떼어 보면 AI에게 맡기면 끝나는 일처럼 들려요.

그런데 같은 글에 사람이 한 일도 숫자로 나와 있어요.

• 사람 메시지 2,639건 중 31.0% 가 리뷰·테스트·CI 확인이었어요.
• 17.4% 는 AI가 내린 기술·설계 판단에 이의를 제기한 내용이었어요.
• 에이전트가 한 일은 코드를 고친 것보다 읽고 찾은 쪽이 10배 많았어요.

글쓴이는 자기 역할을 “일을 맡기고 기다리는 사람”이 아니라 “제어 루프를 돌리는 사람” 이라고 표현했어요. 결과를 보고, 설계를 따지고, 품질 관문을 지키는 일이요. 줄어든 건 옮겨 적는 손이고, 판정하는 눈은 그대로 필요했어요.

4. 첫째, 기존 테스트가 합격 기준이 되나요

GitHub은 전환 내내 기존 E2E 테스트(사용자가 쓰는 흐름을 처음부터 끝까지 돌려 보는 시험)를 새 Rust 코드에 그대로 돌렸어요. 옛 코드가 통과하던 시험을 새 코드도 통과해야 한다는 규칙이에요.

한 번은 AI가 기능 일부를 빠뜨리면서 그 기능의 테스트까지 지운 일이 있었어요. 그 뒤로 “E2E 테스트는 명시적인 동의 없이 바꾸지 않는다”는 규칙이 생겼어요.

발주자가 챙길 질문은 두 가지예요.

1. 우리 시스템에 지금 동작을 잡아 주는 테스트가 있나요? 없다면 전환 전에 그것부터 만들어야 해요.
2. 테스트를 고치거나 지울 때 누구 승인을 받나요? 합격 기준을 옮기는 사람이 자기 답안을 채점하면 안 되니까요.

운영사 Tip — 자체 SaaS를 오래 운영하다 보면 “코드는 바꿨는데 예전과 똑같이 동작하나?”가 가장 증명하기 어려워요. 견적서에 전환 전 동작 기록(테스트) 작성이 따로 잡혀 있는지 보세요. 이 항목이 없으면 검수 부담이 발주자에게 넘어와요.

5. 둘째, 바꾸는 순서를 가장자리부터 잡았나요

GitHub은 다른 기능에 덜 엮인 작은 부분부터 옮겼어요. 순수 계산 함수, 셸 유틸리티, 파일 처리 같은 곳에서 옮기고 시험하는 방식을 먼저 굳힌 뒤 핵심 쪽으로 들어갔어요. 실제로 7월 후반과 8월 후반으로 갈수록 PR 하나의 변경 규모가 커졌어요.

발주자 입장에선 이 순서가 곧 위험을 나누는 계획이에요. 전환 제안을 받으면 이렇게 물어보세요.

• 첫 단계로 옮길 범위는 어디이고, 거기서 무엇을 확인하나요?
• 결제·회원·정산처럼 멈추면 안 되는 부분은 몇 번째 단계인가요?
• 데이터 구조도 같이 바뀌나요?

마지막 질문이 “예”라면 코드 전환과 별도로 봐야 해요. 이유는 데이터 이관은 왜 따로 견적을 받아야 할까요에 적어 뒀어요.

6. 셋째, 회귀 결함은 누가 어떻게 찾나요

GitHub도 결함이 없지는 않았어요. 9월 14일까지 전환 때문에 생긴 알려진 회귀 결함 수십 건을 추적해 모두 고쳤다고 밝혔어요. 대부분은 동작이 틀린 문제였고 성능 문제는 일부였어요. 가장 많이 나온 유형은 종료 처리·실행 순서·동시 실행처럼 평소엔 잘 안 드러나는 곳이었어요.

글쓴이가 쓴 문장이 이 부분을 잘 요약해요. “코드를 옮기는 건 쉽다. 맞게 만드는 게 어렵다.”

AI가 만든 코드에서 결함이 나오면 책임과 수정 범위를 어떻게 나눌지도 계약 단계에서 정해 두는 게 좋아요. AI가 보낸 코드, 누가 확인하나요에서 계약서에 넣을 항목을 다뤘어요.

7. 넷째와 다섯째, 견적에서 무엇이 줄고 무엇이 남나요

GitHub은 비용을 공개하지 않았어요. 그래서 금액 대신 항목으로 보는 게 맞아요. 사례에 적힌 작업을 견적 항목으로 옮기면 이렇게 나뉘어요.

견적 항목	AI로 줄어들 여지	사례에서 사람이 맡은 일
코드 옮겨 적기	큼	결과 확인
반복되는 리뷰·수정	있음 (AI가 리뷰·재수정 반복)	최종 승인
테스트 기준 만들기	작음	기준 정하기·변경 승인
설계 판단	작음	이의 제기·결정
회귀 결함 추적	일부	원인 판정·재발 규칙 추가

넷째로 확인할 건 견적서가 이 표의 아래쪽을 비워 두지 않았는지예요. “AI로 빠르게”만 적혀 있고 테스트·검수 항목이 없다면 속도만 사고 검증은 떠안는 셈이에요. 검수 절차는 개발 외주 검수 체크리스트를 참고하세요.

다섯째는 개발에 AI를 쓰는 일과 사내 AI 에이전트를 들이는 일을 섞지 않는 것이에요. 국내에서도 4월 삼성SDS가 금융권 대상 행사에서 생성형 AI로 레거시 코드를 현대화하는 방안을 소개했을 만큼(지디넷코리아 보도) 관심이 커졌는데, AI 에이전트 도입이라는 말 아래 두 가지가 자주 한데 묶여요. 개발사가 AI로 코드를 옮기는 건 개발 방식의 문제이고, 사내 AI 에이전트는 우리 조직이 매일 운영할 도구예요. 필요한 준비물도 달라요.

전환 범위가 아직 흐릿해도 괜찮아요. 지금 시스템에서 멈추면 안 되는 기능과 테스트가 있는 부분부터 같이 적어 보면 순서가 잡혀요. 레거시 전환 범위부터 함께 따져볼게요 →

저희는 10년 이상 50개가 넘는 프로젝트를 만들어 왔고, 자체 SaaS 4종을 지금도 직접 운영하고 있어요. 롯데·캐논 같은 곳과 함께한 구축부터 오래 쓴 시스템을 고쳐 가는 일까지 겪어 봤기에, 옮기는 속도보다 옮긴 뒤에도 똑같이 도는지를 먼저 따져요.

8. 자주 묻는 질문

AI로 레거시 코드를 옮기면 개발 비용이 얼마나 줄어드나요?

GitHub은 이번 전환에 든 비용을 공개하지 않았어요. 사례에서 확인되는 건 코드를 옮겨 적는 시간이 크게 줄었다는 점이에요. 기존 동작을 테스트로 고정하는 일, 회귀 결함을 찾는 일, 사람이 설계를 따지는 일은 그대로 남았어요. 테스트가 거의 없는 시스템이라면 전환 전에 테스트를 만드는 비용이 오히려 더 붙을 수 있어요.

테스트 코드가 거의 없는 오래된 시스템도 AI로 전환할 수 있나요?

가능은 해요. 다만 순서가 달라져요. 지금 시스템이 어떻게 동작하는지를 먼저 테스트로 기록하고, 그 테스트를 새 코드의 합격 기준으로 삼아야 해요. 기준 없이 AI가 옮긴 코드는 겉보기엔 돌아가도 어디가 달라졌는지 확인할 방법이 없어요.

AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

사내에 테스트 기준을 세우고 AI가 만든 변경을 검토할 개발자가 있다면 AI 코딩 도구를 내부에 들이는 방법이 있어요. 그런 사람이 없다면 AI를 쓰는 개발사에 맡기되, 테스트 코드와 리뷰 기록을 산출물로 받기로 계약에 적는 편이 안전해요. 사내 AI 에이전트를 업무에 붙이는 일과는 준비물이 달라서 따로 판단하는 게 좋아요.

9. 마무리

GitHub 사례에서 남는 건 “AI가 43만 줄을 옮겼다”가 아니에요. 기존 테스트를 기준으로 삼고, 조금씩 바꿔 끼우고, 사람이 판정을 놓지 않았기에 43만 줄을 옮길 수 있었다는 거예요.

전환을 검토 중이라면 먼저 한 줄만 적어 보세요. “지금 시스템이 제대로 돈다는 걸 무엇으로 증명할 수 있나?” 그 답이 전환 계획의 출발점이 돼요.

함께 보면 좋은 글

• AI로 만든 시제품, 서비스로 올리면 비용이 얼마나 더 들까요
• 홈페이지·시스템 리뉴얼, 고쳐 쓸까 새로 만들까
• AI가 보낸 코드, 누가 확인하나요