구글이 AI로 옮긴 C 코드 3,000줄 | 전환보다 검증이 길었어요

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

“AI가 옛날 코드를 새 언어로 옮겨 준다던데, 그럼 우리 시스템도 싸게 바꿀 수 있나요?”

요즘 상담에서 자주 듣는 질문이에요. 9월 27일 InfoQ가 전한 구글 사례는 이 질문에 꽤 구체적인 답을 줘요. 코드를 옮기는 일은 AI가 한 번에 해냈는데, “정말 똑같이 동작하나”를 확인하는 데 훨씬 많은 공이 들었어요. 기업 AI 도입 사례로 보면 이 순서가 핵심이에요.

---

1. 구글은 무엇을 옮겼나요

대상은 giflib이라는 GIF 이미지 처리 라이브러리예요. 코드는 약 3,000줄로 크지 않아요. 대신 위험한 자리에 있었어요. 사용자가 올린 이미지를, 그것도 격리 장치 없이 바로 읽는 경우가 많았거든요.

C 언어는 메모리를 사람이 직접 다뤄서, 실수 하나가 보안 구멍이 돼요. 구글 보안팀은 이 부분을 메모리 오류가 구조적으로 생기기 어려운 러스트(Rust)로 바꾸기로 했어요. 결과물은 giflib-rs라는 이름으로 공개했어요.

항목	내용
대상	giflib (GIF 이미지 처리 라이브러리)
규모	약 3,000줄
옮긴 방법	Gemini로 한 번에 번역 → 사람이 경계 부분 손질
확인 방법	차등 퍼징 6일·2억 회, 실제 GIF 3,000만 장 대조
결과	성능은 원래 수준, 공개 전 보안 결함 1건에 영향 없음

출처: InfoQ, 2026-09-27 보도 기준

2. AI는 어디까지 했고, 사람은 어디서 들어갔나요

과정은 세 단계였어요.

1. AI 번역 — Gemini에 C 코드 전체를 주고 한 번에 러스트로 옮기게 했어요.
2. 사람 손질 — 다른 코드와 맞닿는 경계, 즉 메모리를 누가 언제 풀어 주는지 같은 약속은 전문가가 직접 다듬었어요.
3. 자동 비교 반복 — 옛 코드와 새 코드에 같은 입력을 넣고 결과가 다르면 다시 고치는 고리를 돌렸어요.

눈여겨볼 건 2번이에요. InfoQ는 이 프로젝트가 AI 번역에는 사람의 지속적인 감독이 필요하다는 걸 보여 줬다고 정리했어요. 3,000줄짜리 작은 코드에서도 그랬어요.

3. “같다”는 건 무엇으로 확인했나요

여기서 쓴 방법이 차등 퍼징(differential fuzzing)이에요. 무작위에 가까운 입력을 끝없이 만들어 옛 코드와 새 코드에 동시에 넣고, 결과가 하나라도 다르면 잡아내는 방식이에요.

구글은 이걸 6일 동안 2억 회 돌려 동작이 어긋나지 않는 걸 확인했어요. 따로 실제 GIF 파일 3,000만 장 이상을 디코딩해 화면에 그려지는 결과가 비트 단위까지 같은지도 봤어요. 두 코드의 차이를 일부러 찾아내도록 설정한 AI 검토도 한 겹 더 붙였고요.

용어 한 줄 풀이 차등 테스트는 “정답표” 대신 옛 시스템을 정답으로 삼는 시험이에요. 옛 시스템이 돌아가고 있다면, 새 시스템이 같은 입력에 같은 답을 내는지만 보면 돼요. 레거시 전환에서 가장 믿을 만한 합격 기준이에요.

4. 성능과 보안은 어떻게 나왔나요

실행 속도는 원래 C 버전과 같은 수준이었어요. 오히려 좋아진 곳도 있어요. 예전엔 위험해서 따로 격리해 돌리던 처리를 그럴 필요가 없어지니, 가장 느린 1%의 응답(p99 지연)이 눈에 띄게 줄었다고 해요.

보안 쪽 결과가 더 흥미로워요. 외부 연구자가 찾아낸, 아직 고쳐지지 않았던 C 버전의 메모리 쓰기 결함(CVE-2026-26740)이 새 러스트 버전에는 처음부터 해당되지 않았어요. 결함이 공개되기 전에 이미 피해 간 셈이에요.

5. 지난주 GitHub 사례와 무엇이 다른가요

9월 중순엔 GitHub이 약 43만 줄을 AI 에이전트로 러스트로 옮긴 사례가 있었어요. 그 이야기는 AI로 43만 줄을 옮긴 GitHub, 레거시 전환 전 볼 5가지에서 다뤘어요. 두 사례는 결이 달라요.

	GitHub	구글
규모	약 43만 줄	약 3,000줄
이유	코드베이스 정비	보안 위험 제거
나눈 방식	PR 128개로 쪼개 단계적 교체	한 번에 번역 후 반복 비교
합격 기준	기존 테스트 통과	옛 코드와 같은 출력

둘을 합쳐 보면 메시지는 같아요. AI는 옮기는 속도를 크게 줄였고, 검증은 줄이지 못했어요. 오히려 검증이 전체 일정의 중심이 됐어요.

6. 우리 회사 레거시 전환이라면 견적에서 무엇이 달라지나요

“AI가 옮겨 주니 전환 비용이 크게 줄겠다”고 보기 쉬운데, 줄어드는 칸과 남는 칸이 따로 있어요.

• 줄어드는 칸 — 코드를 한 줄씩 새로 쓰는 시간. AI가 초안을 빠르게 만들어요.
• 남는 칸 — 옛 시스템의 동작을 기록하는 일, 비교 시험 환경을 만드는 일, 경계 부분을 사람이 확인하는 일, 결과가 다를 때 원인을 찾는 일.

구글처럼 옛 코드를 옆에 두고 돌릴 수 있으면 비교가 쉬워요. 그런데 사내 시스템은 옛 코드가 어떻게 동작하는지 아는 사람이 이미 없는 경우가 많아요. 그러면 동작부터 기록해야 하고, 이 일은 AI가 대신 끝내 주지 않아요. 전환 대신 리뉴얼·재구축을 고민 중이라면 리뉴얼과 재구축, 비용은 어떻게 다를까요도 같이 보세요.

7. 전환을 맡길 때 검수에 넣을 4가지

구글 사례를 발주 문서로 옮기면 이렇게 돼요.

1. 정답을 무엇으로 삼을지 — 옛 시스템 출력인지, 기존 테스트인지, 새로 만든 시험표인지 먼저 정해요.
2. 실제 데이터로 얼마나 대조할지 — 구글은 실제 GIF 3,000만 장을 썼어요. 우리 회사라면 지난 몇 달치 실제 입력 몇 건으로 대조할지를 숫자로 적어요.
3. 사람이 직접 볼 구간 — 외부 시스템과 맞닿는 곳, 돈·개인정보를 다루는 곳은 AI 결과를 그대로 받지 않고 사람이 확인한다고 적어요.
4. 성능 기준 — “원래보다 느려지지 않을 것”처럼 비교 대상을 정해 둬요.

검수 절차 전체는 개발 외주 검수, 어떻게 해야 분쟁이 줄어들까요에 정리해 두었어요.

8. 자주 묻는 질문

AI로 레거시 코드를 옮기면 전환 비용이 절반이 되나요?

코드를 새로 쓰는 시간은 줄지만 전체가 절반이 된다고 보긴 어려워요. 구글 사례에서도 번역은 한 번에 끝났고, 사람 손질과 6일간의 비교 시험이 뒤따랐어요. 옛 시스템의 동작이 문서로 남아 있지 않다면 그 기록 작업이 오히려 가장 큰 칸이 될 수 있어요.

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

사내에 옛 시스템을 아는 사람이 있고 시험 환경을 직접 만들 수 있다면 AI 도구를 들여 내부에서 진행해 볼 만해요. 그렇지 않다면 동작 기록과 비교 시험까지 맡길 수 있는 곳에 외주하는 편이 안전해요. 비용 차이는 AI 직접 구축과 외주, 비용·기간은 어떻게 다를까요에서 비교했어요.

우리 시스템은 옛 코드가 계속 돌아가는데, 차등 테스트를 쓸 수 있나요?

오히려 가장 좋은 조건이에요. 운영 중인 옛 시스템에 들어가는 실제 입력을 모아 두면, 새 시스템에 같은 입력을 넣어 결과를 비교할 수 있어요. 다만 개인정보가 섞인 입력은 가린 뒤 써야 해요.

9. 정리하면

구글 사례가 보여 준 건 “AI가 코드를 옮길 수 있다”보다 “옮긴 걸 어떻게 믿을 수 있나”예요. 전환 견적을 받는다면 번역 방법보다 검증 방법을 먼저 물어보세요.

저희는 10년 넘게 50개 이상의 프로젝트를 해 왔고, 자체 SaaS 4종을 직접 운영하면서 오래된 코드를 새로 바꾸는 일을 여러 번 겪었어요. 롯데백화점 프로젝트에선 운영 환경에서 끊기던 화면을 다른 언어로 다시 구현해 해결한 적도 있어요. 오래된 시스템을 어디서부터 바꿔야 할지 고민이라면 검증 계획부터 같이 잡아 볼까요 →