레거시 현대화, 이제 '기존 코드의 이해'가 먼저 시작되었다. - Reverse Engineering부터 Code Graph까지 시장은 어디까지 왔나?

Archify는 구조도 도구, 변경은 Agentic Modernization 플랫폼이 맡는다. 문제은 코드 변환이 아니라 검증이다. - 기업이 AI로 기존 프로세스를 혁신하려면 그 밑에 깔린 레거시 시스템부터 손봐야… — AI 시대 SW 아키텍처, AI 네이티브

올해 2월 23일 월요일, 미국 증시에서 IBM 주가가 13% 빠졌다. 2000년 10월 이후 하루 낙폭으로는 가장 컸다. 발단은 앤트로픽이 낸 블로그 글이었다. 미국 ATM 거래의 약 95%가 아직 COBOL로 돌아가는데, 이 낡은 언어의 시스템을 현대화하지 못하는 까닭은 코드를 이해하는 데 드는 돈이 다시 짜는 돈보다 크기 때문이고, Claude Code가 그 '이해' 단계, 곧 의존 관계를 그리고 업무 흐름을 문서로 정리하고 위험을 찾아내는 일을 자동화할 수 있다는 내용이었다( devops.com 보도). 시장은 주가로 반응했지만 정작 현장의 CIO들이 궁금한 것은 주가가 아니다. 우리 회사의 20년 된 시스템을 AI가 정말 읽어낼 수 있는가, 읽어낸다면 고치는 일까지 맡겨도 되는가? 이 글은 그 두 질문에 대해 지금까지 공개된 사례와 연구가 무엇을 말해 주는지 따라가 본 기록이다.

IBM의 반박이 오히려 핵심이었다.

주가가 빠진 뒤 IBM은 가만히 있지 않았다. 롭 토머스 수석부사장은 COBOL 코드를 옮기는 일과 기업 시스템을 현대화하는 일은 다르다고 반박 했다. 정말 어려운 것은 데이터 구조를 바꾸는 일, 거래의 무결성을 지키는 일, 실행 환경을 교체하는 일, 그리고 새 시스템이 옛 시스템과 똑같이 동작한다는 것을 증명하는 일이라는 것이다. 코드를 읽고 번역하는 것은 그중 쉬운 쪽이라는 뜻이다.

IBM이 자기 사업을 지키려는 말이기도 해서 그대로 믿을 이유는 없다. 하지만 devops.com 은 두 쪽 주장이 모두 일리가 있다고 정리했다. AI가 낡은 코드를 이해하는 비용을 크게 낮춘다는 앤트로픽의 말도, 그것이 IBM 메인프레임 사업을 곧바로 위협할 만큼 일을 끝내 주지는 않는다는 IBM의 말도 맞다는 것이다. 이 기사의 나머지는 사실 이 두 주장 사이 어딘가에서 일어나는 일들이다.

'읽는 일'부터 시장이 붙었다

레거시 현대화는 크게 두 단계로 나뉜다. 먼저 낡은 시스템이 무엇을 하고 있는지 코드에서 거꾸로 알아내는 일이 있다. 업계에서는 이것을 역공학(Reverse Engineering)이라 부른다. 그다음에 그 이해를 바탕으로 새 구조로 다시 짓는 Forward Engineering이 온다. 인포시스는 자사 방식을 바로 이 두 단계로 설명한다. 흔히 '역공학으로 설계서를 만든다'고 말하는 첫 단계는 시장에서는 Reverse Engineering, 요즘은 에이전트가 읽을 수 있는 명세를 만든다는 뜻에서 Reverse Documentation Engineering이라고도 부른다.

이 첫 단계에서 요즘 개발자들 사이에 가장 화제가 된 도구가 Archify다. 다만 이름이 주는 인상과 실제 쓰임에는 차이가 있다. Archify는 tt-a1i라는 개발자가 만든 MIT 라이선스 오픈소스로, Cursor, Claude Code, Codex CLI, OpenCode 같은 AI 코딩 도구에 붙여 쓰는 '스킬'이다. 하는 일은 코드를 읽고 구조도를 그려 주는 것이다.

재미있는 것은 그리는 방식이다. 보통 AI에게 "이 시스템 구조도를 그려 줘"라고 시키면 그럴듯하지만 실제로는 없는 부품, 예컨대 코드 어디에도 없는 Kafka나 Redis를 그려 넣는 일이 생긴다. Archify는 AI에게 그림을 그리게 하지 않는다. 대신 구성요소와 연결선을 정해진 형식의 JSON으로 적게 하고, 그 항목 하나하나가 실제 소스에 근거가 있는지 대조한다. 근거를 못 대면 그림을 만들지 않고 어디가 문제인지 알려 준다. 검증을 통과한 데이터만 컴퓨터가 그림으로 바꾼다. Better Stack은 이 방식을 컴파일러에 비유했다. 에이전트는 코드를 읽는 앞단, JSON은 중간 표현, 그림 생성기는 뒷단이라는 것이다.

PR 전후의 구조를 비교해 무엇이 추가되고 빠지고 옮겨졌는지 보여 주는 기능도 있다. 개발자들의 반응은 뜨거웠다. Better Stack은 GitHub 스타가 3만 6,000개를 넘었다고 전했고, 한 교육업체 블로그는 8월 31일 하루에만 3,700개 넘게 늘었다고 적었다(이 수치는 홍보성 글이라 직접 확인하지는 못했다).

하지만 인기와 현장 검증은 다른 이야기다. 취재한 글 어디에도 어떤 기업이 이 도구로 시스템을 현대화했다는 사례나 구조도의 정확도를 잰 평가는 없었다. 이 도구를 소개한 글에 달린 한 독자 댓글이 문제를 정확히 짚는다. 형식과 기하를 검증했다고 해서 그 그림이 실제 시스템과 맞는다는 증명은 되지 않는다는 것이다. 요컨대 Archify는 현대화의 첫 단계인 '지금 구조를 눈으로 확인하는 일'을 돕는 도구이지, 개선 주제별로 에이전트를 나눠 시스템을 바꿔 주는 도구가 아니다. 그 일을 하겠다는 것은 다른 부류의 제품들이다.

코드를 '그래프'로 보는 회사들, 그런데 GNN은 보이지 않았다

AI가 큰 시스템을 다루는 데 가장 큰 걸림돌은 기억력이다. Blitzy의 엔지니어링 디렉터에 따르면 에이전트가 한 번에 다룰 수 있는 유효 분량은 20만30만 토큰, 코드로는 2만3만 줄 정도다. 1억 줄짜리 코드베이스에서는 에이전트가 중간 결과를 압축하다가 정보를 잃기 시작한다. 그래서 이 회사는 고객의 코드를 모듈, 파일, 함수, 클래스가 서로 연결된 지도, 곧 그래프로 만들어 Neo4j라는 그래프 데이터베이스에 넣고, 에이전트가 그 지도를 질의해 의존 관계를 따라가게 한다. 코드가 바뀌면 지도도 따라 갱신된다. 사람이 먼저 작업 계획을 승인한 뒤에야 코딩이 시작되고, 다른 에이전트들이 계획을 지키는지 감시한다(SiliconANGLE, 9월 28일). 이 회사는 올해 5월 2억 달러를 14억 달러 기업가치로 투자받았다. 다만 이 기사에는 고객사 이름이 나오지 않았고, 회사가 내세우는 코딩 벤치마크 점수(SWE-Bench Pro 84.95%)도 자체 인용 수치다.

시장에서 실제로 쓰는 말은 Code Knowledge Graph , 또는 그래프를 검색에 활용하는 GraphRAG이다. 학계에는 코드 그래프를 LLM과 맞추는 연구(GALLa 등)가 있지만 제품에 쓰인 사례는 확인하지 못했다. '없다'가 아니라 '이번 공개 검색으로는 찾지 못했다'는 뜻이다. 하지만 연구자들이나 ThoughtWork같은 테크 컨설팅 회사들은 GNN(Graph Neural Network)을 사용해서 코드명세 및 기존 코드 전환을 연구하고 있다.

이와 유사한 다른 갈래가 Moderne이다. 이 회사는 코드를 서식과 타입 정보, 빌드 설정까지 빠짐없이 담은 구조 모델(OpenRewrite의 Lossless Semantic Tree)로 바꿔 놓고, 에이전트가 이 위에서 미리 검증된 변환 규칙 3,500여 개를 도구처럼 불러 쓰게 한다. 올해 2월에는 Java와 JavaScript/TypeScript에 이어 Python을 지원 대상에 넣었다. 이 방식의 요점은 에이전트가 코드를 처음부터 새로 써 내지 않는다는 것이다. 한 대형 은행은 Java 21로 올려야 할 코드베이스가 1만 5,000개를 넘어 수작업으로는 5만 시간 넘게 걸릴 것으로 추산했다고 한다. 어디까지나 수작업 추정치이고, 이 방식으로 실제로 얼마나 줄었는지는 공개되지 않았다. 모든 설명이 회사 쪽 자료라는 점도 감안해야 한다.

AWS도 같은 방향이다. AWS는 Transform 서비스가 1년 만에 45억 줄, 이후 100억 줄이 넘는 코드를 처리했다고 밝혔고, 메인프레임 분석에서 지식 그래프를 만든다. 이 수치를 소개한 분석가는 독립 감사를 받은 숫자가 아니며, 소프트웨어 요금은 전체 프로그램 비용의 일부일 뿐이고, 검증 도구는 '완료된 것이 아니라 관리대상'이라고 선을 그었다.

실제로 옮겨 보니: 쉬운 일은 쉽고, 어려운 일은 여전히 어렵다.

가장 눈길을 끈 것은 올해 8월 공개된 독립 연구다. 브라질과 캐나다의 연구진이 20년 넘게 운영된 Visual Basic 6 기반 쇼핑몰 ERP에서 12개 기능을 골라 Claude Code(Opus 4.6)에게 .NET으로 옮기게 했다. 사람의 중간 개입 없이 기능마다 표준 지시문 하나로 한 번에 맡겼다. 결과를 업무 규칙 160개와 DB 연산 171개, 합쳐 331개 항목으로 맞춰 보니 70%가 원래와 같게 동작했다. 쉬운 기능은 92%, 중간은 81%였지만 복잡한 기능은 47%에 그쳤다.

비용은 12개 기능을 통틀어 50달러 남짓(기능당 평균 4달러 안팎)으로 놀랄 만큼 저렴했다. 흥미로운 것은 비용의 거의 전부(토큰의 99.6%)가 에이전트가 낡은 코드를 읽는 데 쓰였다는 점이다. 코드를 새로 쓰는 일보다 읽는 일이 돈이 든다. 앤트로픽이 '이해'를 먼저 꼽은 이유를 설명해 주는 대목이다.

어디서 틀렸는지도 눈여겨볼 만하다. 틀린 100건 가운데 42건은 인접 모듈, 곧 알림이나 불러오기, 보고서처럼 기능의 중심이 아닌 가장자리 로직을 빠뜨린 경우였다. 여러 파일에 흩어진 규칙이나 코드에 드러나지 않은 암묵적 규칙, 예컨대 숨은 설정값이나 동적으로 읽히는 전역 설정도 자주 빠졌다. 사람이 20년 동안 몸으로 알던 것이 코드 어디에도 적혀 있지 않은 곳에서 AI는 넘어졌다는 얘기다. 다만 한 조직, 두 모듈, 한 모델의 결과이고 평가를 시스템 유지보수 담당자가 직접 했다는 한계는 저자들도 인정했다.

반대 방향의 증거도 있다. 영국계 보험사 Bupa는 앱 개발 프레임워크 Xamarin의 지원이 2024년에 끝나자 앱을 네이티브 Swift와 Kotlin으로 옮겼다. 내부 예상 18개월이 약 7개월로 줄었고, 앱 평점은 3.7에서 4.7로 올랐다고 한다(MIT Technology Review Insights). 다만 이 인터뷰는 인포시스가 후원한 콘텐츠이고 수치는 양쪽의 자체 보고다. 이전 비율도 Bupa 쪽은 약 90%, 인포시스 쪽은 거의 100%로 말이 달랐다. Bupa의 CIO가 강조한 것은 오히려 기술이 아니라 사람이었다. 현대화는 기술 교체가 아니라 사업 전환으로 다뤄야 하고, 조직이 가진 제도적 지식을 지켜야 한다고 했다.

국내에서는 '산출물 작성'부터 시작하고 있다.

국내 IT서비스 업계도 움직이고 있다. 삼성SDS는 4월 금융권 고객 150명 안팎을 모은 세미나에서 자사 AI 에이전트 플랫폼 FabriX의 코드 변환 에이전트로 한 증권사의 C 언어 시스템을 Java로 바꾼 사례를 소개했다(ZDNet Korea). 디지털데일리 보도에 따르면 이 금융 프로젝트에서 자동 변환율 98.8%, 개발비 약 68% 절감이 보고됐다. LG CNS는 DevOn AIND를 26개 실제 프로젝트에 적용해 생산성이 평균 26.1% 올랐다고 밝혔고, 같은 기사는 범용 도구인 GitHub Copilot 등을 14.1%로 비교했다. 모두 기업 자신이 밝힌 수치라 독립적으로 검증된 것은 아니다. 또한 실제 현장에서는 대부분의 SI회사들이 Qwen 같은 Edge형 Foundation모델로 기존 코드들의 산출물 작성에 사용하고 있지만, 문제는 완전한 로직검증은 결국 사람이 해야 하는 상황을 벗어나지 못한다는 것이다. 국내 IT서비스 기업에는 수십 년 쌓인 요구사항 문서, 설계서, 인터페이스 명세, 테스트 케이스가 있고, 그 산출물이 AI 코딩의 효과를 가른다는 것이다. 외산 도구가 망 분리나 보안 규정, 한국어 요구사항 문서 앞에서 힘을 못 쓰는 사이, 현장에서 직접 쓰며 다듬은 도구가 자리를 잡았다는 분석이다. 다만 이런 도구가 자사 프로젝트 안에서만 쓰일지, 중견·중소기업까지 퍼질지는 아직 열려 있다. 그리고 일부 산출물의 역공학만으로는 실제 시스템의 개선이 한계가 있고, 이미 만들어진 명확한 프레임워크의 전환 같은 특수한 영역에서 AI가 매우 효과적으로 사용되었다 하더라고 결국 검증은 사람이 할수 밖에 없는 상황이다.

CIO가 지금 챙길 것들

이상의 사례를 가로질러 보면 CIO가 서둘러 정해야 할 일은 크게 세 가지로 모인다. 이는 취재에서 확인한 사실에 바탕을 둔 필자의 정리다.

첫째, 고치기 전에 '똑같이 동작한다'는 것을 확인할 방법부터 만들어야 한다. 앞의 연구에서 복잡한 기능의 일치율이 47%였고, Reverse Documentation 연구 Reversa는 ATM 시스템을 COBOL에서 Go로 옮기는 탐색적 사례에서 517개 주장과 10개의 미해결 구멍을 정리하고 53개 동등성 시나리오까지 만들었지만 최종 검증과 전환은 끝내지 못했다. AWS Transform을 평가한 분석가도 규제 대상 데이터나 실거래를 옮기기 전에 독립된 인수 관문을 두라고 권했다. 새 시스템을 짓는 속도보다 '같다'를 증명하는 장치가 먼저다.

둘째, 낡은 시스템을 읽은 결과를 맹신하지 말아야 한다. 구조도든 명세든 AI가 만든 것은 '출발점'이고, 숨은 규칙은 그 시스템을 오래 운영한 사람이 채워 줘야 한다. Reversa가 AI가 뽑은 주장마다 신뢰도를 매기고 사람이 확인할 구멍을 따로 남겨 두는 것도 같은 맥락이다. 이 일을 맡을 사람들이 퇴직하기 전에 시작해야 한다는 조언도 AWS 분석가의 글에 있었다.

셋째, 벤더가 내놓는 숫자는 걸러서 읽어야 한다. 이번에 인용한 성과 수치 대부분은 벤더나 후원 콘텐츠의 자체 보고다. 판단의 근거는 내 시스템 일부로 직접 돌려 본 파일럿 결과여야 한다. 분석 결과를 다른 도구로 옮길 수 있는지, 코드가 어디서 처리되는지도 계약 전에 확인할 대목이다.

앞으로 어떻게 될까?

아래는 지금까지의 사실에서 이끌어 낸 필자의 전망이다.

가장 먼저 값이 싸지는 것은 '역공학을 통한 기존 코드의 이해'다. 구조도, 명세, 의존 관계 분석처럼 읽고 정리하는 일은 이미 도구가 쏟아지고 있고, 앞의 연구에서 보듯 비용도 얼마 들지 않는다. 다만 그 결과가 얼마나 정확한지 가리는 독립적인 지표는 아직 거의 없다.

그다음 경쟁은 '누가 더 빨리 바꾸는가'가 아니라 ' 누가 더 확실하게 같다고 증명하는가? '로 옮겨 갈 가능성이 크다. IBM의 반박, 47%라는 숫자, 끝내 전환을 마치지 못한 연구 사례가 모두 같은 곳을 가리킨다.

변환 방식은 섞일 것으로 본다. 반복적이고 규칙이 분명한 변경은 Moderne처럼 미리 검증된 변환 규칙으로 처리하고, 해석이 필요한 부분만 에이전트가 맡는 구성 이다. 에이전트의 기억 한계가 사라지지 않는 한, 코드를 그래프나 구조 모델로 바꿔 두는 계층은 에이전트 플랫폼의 기본 부품이 될 가능성이 높다. 그 이름이 GNN일지, 그래프 데이터베이스일지는 실제 상용 제품들이 시장에 더 출시되고 나서야 할수 있을 것이다.

마지막으로, 한국 기업에는 과거 반복되는 차세대시스템으로 빅뱅방식의 전면 재구축을 선호하는 기이한 상황이 있었다. 그리고 지난 십여년은 더이상 빅뱅을 할수 없는 규모로 커진 이후에 언제부터인가 레가시 정보시스템의 자산들을 방치하고 있다는 생각이 든다. 이런 상황에서 그동안 쌓은 프로젝트 산출물이 자산이 될 수 있다 . 물론 현행화는 여전히 안되어 있더라도 이것은 분명 낡은 시스템을 AI가 읽게 만드는 데 필요한 데이터들이 이미 있다는 뜻이다. 그 재료를 얼마나 정리해 두었는지가 레거시 현대화를 통한 AI로 촉발된 새로운 정보시스템의 역할로 발전하는 AX의 속도를 좌우할 것이다.

관련 태그: #AI 시대 SW 아키텍처 #AI 네이티브 #기술부채 #AI Software Architecture #AI SW 아키텍처 #AI-native architecture #SW아키텍트 #Legacy Modernization #Agentic Modernization

본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)