이해의 아키텍처: 엔터프라이즈 레거시에서 구문을 넘어선 현대화

요약

엔터프라이즈 레거시 시스템의 현대화—구체적으로는 메인프레임 아키텍처를 클라우드 네이티브 환경으로 이전하는 작업은—결정적 변곡점에 도달했으며 2020년대 중반에. 수십 년 동안 금융 및 공공 부문은 역설적 패러다임 아래 운영되어 왔다. 현대화의 당위성은 생존의 문제인데, 그러한 이니셔티브의 실패율은 재앙적으로 높아 70%에서 80% 사이를 오간다. ¹ 최근 등장한 대규모 언어 모델(LLM)은 혁명을 약속하며, 매력적인 가능성으로 자동 코드 번역을 제시했다. 그러나 초기 도입 주기에서 드러난 것은 중대하고 체계적인 결함이 표준 생성형 AI 접근법에 있다. 복잡하고 단일체의 저장소에.

우리는 지금 새로운 범주의 엔지니어링 실패가 등장하는 것을 목격하고 있으며, 그 전형은 한 대형 은행이 상업용 코딩 어시스턴트를 사용해 30년치 COBOL을 Java로 재작성하려 한, 전설적이면서도 매우 현실적인 시나리오다. AI는 정교한 국소 번역기로 작동하며 구문을 완벽하게 변환했다. 그러나 그 결과 애플리케이션은 배포 직후 데이터베이스를 다운시켰다. 실패는 구문의 문제가 아니라 맥락의 문제였다. AI는 "Lost in the Middle" 증후군과 텍스트 기반 소프트웨어 이해에 묶여, 실행 블록보다 수천 줄 앞에 정의된 결정적 변수 의존성을 놓쳤다. ³

Veriprajna가 제시하는 본 백서는, 지배적인 "LLM 래퍼" 접근법—코드를 텍스트 토큰의 선형 수열로 취급하는—이 본질적으로 부적합하다고 주장한다 엔터프라이즈 현대화의 비선형 복잡성에. 소프트웨어는 텍스트가 아니다. 그것은 그래프다. 그것은 논리적 의존성, 데이터 흐름, 상태 변화로 이루어진 고도로 구조화된 시스템이며 다차원 위상 공간에 존재한다. ⁵

우리는 앞으로 나아갈 유일한 실행 가능한 길은 저장소 인식 지식 그래프 의 채택이라고 본다. 확률적 텍스트 예측에서 그래프 기반 결정론적 추론으로 전환함으로써, 수백만 줄의 코드에 걸쳐 변수 의존성을 매핑하고, "Lost in the Middle" 현상을 해소하며, 현대화를 위험한 도박에서 수학적으로 검증 가능한 엔지니어링 프로세스로 바꿀 수 있다. ⁷ 본 문서는 기술적 전환을 개략한다. 표면적 구문 번역에서 심층적·의미적 구조 변환으로.

1장: 레거시의 조용한 위기 인프라

1.1 현대화의 역설

현재의 디지털 경제에서 글로벌 상업의 인프라는 위태롭게 의존하고 있다 냉전 시기에 개발된 기술에. 놀랍고, 종종 인정되지 않는 현실은, 2025년에 세계 금융·의료·정부 시스템의 상당 다수가 레거시 코드베이스로 구동된다는 점이다—COBOL 같은 언어로 작성된 단일체 애플리케이션, PL/I, RPG는 주류 컴퓨터 과학 교육과정에서 오래전에 밀려났다. 이들 시스템은 단지 "오래된" 것이 아니다. 세계 경제의 기초 암반이며, 그런데도 놀라운 속도로 침식되고 있다.

통계는 이 의존성의 암울한 그림을 그린다. 포춘 500 기업에서 돌아가는 소프트웨어의 약 70%는 20년도 더 전에 개발되었다. ⁹ 은행 부문에서는 상황이 더욱 심각하다. 은행 시스템의 43%가 COBOL 위에 구축되어 있고, 이들 시스템은 전체 ATM 거래의 95%를 처리한다. ¹ 우리는 사실상 현대의, 즉시결제 경제를 인터넷보다 앞선 디지털 기반 위에서 운영하고 있다.

이 현상 유지를 지속하는 비용은 치솟고 있다. 기술 부채는 누적되어 미국에서만 추정 $1.52조에 이른다. ¹ 조직들은 "불을 켜 두는" 순환에 갇혀 있다. 연방 IT 예산의 80%가 운영·유지보수에 할당되어, 혁신에는 빈약한 20%만 남는다. ⁹ 이 자원 유출은 심각한 숙련 인력 부족으로 가중된다. 이 시스템을 작성한 세대의 개발자가 은퇴하면서, 유지에 필요한 조직 지식은 사라진다. ¹⁰

표 1: 레거시 시스템의 경제적 부담

지표	통계	출처
기술 부채 비용(미국)	$1.52조	1
연방 IT 유지보수 예산	총지출의 ~80%	9
은행 의존도	ATM 거래의 95% COBOL 기반	1

데이터 침해 확률	시스템 >10에서 3x 높음 년 이상	11
개발자 이탈	58%가 이직을 고려, 원인 레거시 스택	1

이 데이터는 체계적 취약성을 나타낸다. 현대화의 당위성은 단순히 비용 절감이 아니라 생존의 문제다. 10년 이상 된 시스템은 통계적으로 세 배 더 보안 침해를 겪을 가능성이 높다. 현대 애플리케이션과 비교할 때. ¹¹ 규제 데이터 프라이버시와 실시간 보고 요건이 강화되면서(예: GDPR, DORA), 적응하지 못하는 레거시 시스템의 무능력은 최고 수준의 컴플라이언스 위험이 된다.

1.2 "은행 실패"의 해부

새로운 접근의 필요성을 이해하려면, 그 시나리오를 해부해야 한다. 그것이 AI 현대화 실패의 "페이션트 제로"가 된. 이 사례 연구는 Veriprajna 리더십이 언급한 것으로, 표준 AI가 실패하는 구체적 메커니즘을 보여 준다 엔터프라이즈 환경에서.

한 대형 금융기관이 핵심 거래 처리 시스템을 이전하는 프로젝트를 시작했다 IBM 메인프레임(COBOL/DB2)에서 클라우드 네이티브 Java 마이크로서비스 아키텍처로. 그 은행은 인기 있는 AI 코딩 어시스턴트를 사용했다—본질적으로 기반 모델 위의 래퍼—코드를 번역하기 위해.

AI는 고액 송금을 처리하는 COBOL 프로그램을 섭취했다. 그 프로그램에는 TRN-LIMIT라 부를 변수가 관련된 복잡한 COMPUTE 문이 들어 있었다. AI는 구문을 완벽하게 번역했다. COMPUTE 문을 Java BigDecimal 연산으로 변환했다. 코드는 컴파일되었다. 단위 테스트—같은 AI가 생성한, 기반은 국소 코드 블록—은 통과했다.

그러나 사용자 수용 테스트(UAT) 환경에 배포하자, 첫 거래가 데이터베이스 일관성 검사를 다운시켰다.

부검: 변수 TRN-LIMIT는 AI가 번역한 소스 파일에 정의되어 있지 않았다. 그것은 정의되어 있었다 COPYBOOK(공유 헤더 파일)에, 실행 사슬에서 수천 줄 앞에 포함된. 더 중요하게는, 그 COPYBOOK에는 REDEFINES 절이 있었다—COBOL 구문으로 같은 메모리 주소를 두 가지 다른 데이터 유형으로 해석하게 한다. 다음에 따라 완전히 다른 모듈에서 설정된 플래그에. AI는 텍스트 "청크" 위에서 동작하며 TRN-LIMIT를 단순 숫자 필드로 보았다. 그것은 보지 못했다 REDEFINES 절을, 그것이 즉시적인 컨텍스트 윈도우에 없는 다른 파일에 있었기 때문이다. 변수에 대해 표준 정의를 "환각"했다. 메인프레임 환경에서 그 메모리 주소는 팩 십진수를 담았고, Java 환경에서 AI는 그것을 표준 정수로 취급했다. 불일치로 Java 애플리케이션이 손상된 바이너리 데이터를 데이터베이스 컬럼에 기록했고, 참조 무결성 실패를 유발했다. ⁴

실패는 구문의 문제가 아니었다. Java 코드는 구문적으로 완벽했다. 실패는 맥락 맹목 의 문제였다. AI는 "시야" 밖에 있던 의존성을 놓쳤고, 파국적인 의미 분기로 이어졌다.

1.3 "리프트 앤 시프트" 대 리팩터링의 딜레마

현대화에 대한 업계의 실적은 처참하다. 도입 이전에도 생성형 AI의. 연구에 따르면 디지털 전환 및 레거시 현대화 프로젝트의 70%에서 80%가 목표를 달성하지 못한다. ²

전통적으로 조직들은 이분법적 선택에 직면해 왔다.

1.​ 재호스팅(리프트 앤 시프트): 컴파일된 애플리케이션을 클라우드의 에뮬레이터로 옮긴다. 이는 "스파게티 코드"와 부채를 보존하며, 호스팅 청구서만 바꾼다. 그것은 실패한다 클라우드의 민첩성을 열어 주지 못한다. ¹⁴

2.​ 재작성(리팩터): 현대 언어로 코드를 수동 재작성한다. 이는 천문학적으로 비싸고, 느리고, 위험하다. 문서 부재와 "빅 볼 오브 머드" 아키텍처 때문이다. 비즈니스 로직이 데이터 접근과 떼려야 뗄 수 없이 얽혀 있다. ¹⁰

생성형 AI는 "제3의 길"을 제공하기로 되어 있었다—자동 리팩터링. 그러나 "은행 실패"는 소프트웨어 위상에 대한 더 깊은 이해 없이 AI가 단지 결함 있는 코드의 생성을 가속할 뿐임을 증명한다.

2장: 확률적 번역의 실패

2.1 "래퍼" 경제와 그 한계

이 고위험 환경에 "LLM 래퍼"가 들어왔다. 즉각적 반응은 소프트웨어 컨설팅 시장이 GPT-4 출시에 보인 것으로, 도구의 확산이다. 그것들은 개발자와 기반 모델 사이의 얇은 소프트웨어 계층으로 작동한다. ¹⁵ 이들 도구는 약속한다 "코드와 대화"를, 개발자가 COBOL 단락을 붙여 넣고 Java 메서드를 돌려받게 한다.

이러한 래퍼는 AI 도입의 진입 장벽을 낮추지만, 근본적으로 결함이 있다 대규모 시스템 재엔지니어링에 적용될 때. 래퍼는 전형적으로 Naïve RAG (검색 증강 생성)에 의존한다. 이 과정에서 시스템은 사용자 질의를 받아, 검색한다 벡터 데이터베이스에서 질의와 텍스트적으로 유사한 코드 스니펫을, 그리고 그것들을 공급한다 LLM에 컨텍스트로. ¹⁷

엔터프라이즈 맥락에서 이 접근의 한계는 심각하다.

1.​ 맥락 근시: 래퍼는 코드를 텍스트 세그먼트로 본다. 그것은 이해하지 못한다 변수 ACCOUNT-BALANCE가 SECTION-A에서 수정되면 결정 로직을 구동한다는 것을 5천 줄 떨어진 SECTION-Z에서.

2.​ 구문적 성공, 의미적 실패: 언급했듯이, LLM은 Java 코드를 생성할 수 있다 완벽하게 컴파일되지만 원본 COBOL의 정확한 런타임 동작을 재현하지 못하는 전역 상태 변화를 놓쳤기 때문이다. ⁴

Veriprajna는 "얇은 래퍼" 철학을 거부함으로써 차별화된다. 우리는 주장한다. 심층 AI 솔루션은 저장소의 _구조_를 이해해야 하며, 파일의 _텍스트_만이 아니다.

2.2 "Lost in the Middle" 증후군

표준 AI가 레거시 현대화에서 실패하는 이유를 이해하려면, 우리는 이해해야 한다 대규모 언어 모델의 인지 아키텍처를. 이들 모델은 기반한다 Transformer 아키텍처에, "어텐션 메커니즘"을 사용해 중요도를 가중한다 입력 텍스트의 서로 다른 부분에. ¹⁸

현대 LLM은 거대한 컨텍스트 윈도우(최대 100만 토큰)를 자랑하지만, 그 능력은 그 컨텍스트를 효과적으로 _사용_하는 것이 균일하지 않다. 실증 연구는 보여 주었다 "Lost in the Middle" 효과 로 알려진 현상을. 긴 정보 수열을 제시받으면, LLM은 U자형 성능 곡선을 보인다.

●​ 초두 편향: 그들은 매우 정확하다. 정보를 회상하는 데, 시작 부분의 프롬프트.

●​ 최신성 편향: 그들은 매우 정확하다. 정보를 회상하는 데, 프롬프트의 끝에서.

●​ 골짜기: 중간에 위치한 정보에 대해 성능이 크게 저하된다. ³

현대화 프로젝트에서 단일 COBOL 프로그램은 수천 줄일 수 있고, 그것은 카피북(의존성)을 참조할 수 있다. 그것들 자체도 수천 줄인. 만약 결정적 변수의 정의—예를 들어 MAX-TRANSACTION-LIMIT—가 이 한가운데에 나타나면 거대한 컨텍스트에서, AI는 통계적으로 그것을 놓칠 가능성이 높다. ²¹

AI가 변수 정의를 놓쳐도, 멈추지 않는다. 그것은 "환각"한다. 그것은 가정한다 변수의 기본 유형이나 값을, 사실이 아니라 확률에 기반해. 은행 시스템에서, 변수가 실제로는 팩 십진수인데 Integer라고 가정하면 반올림으로 이어질 수 있다 금융 데이터를 손상시키는 오류. ²²

표 2: 표준 LLM의 인지적 한계

현상	설명	현대화에 미치는 영향
Lost in the Middle	저하된 주의가 긴 프롬프트의 중앙에서.3	놓친 변수 정의가 큰 파일에 묻힌.
환각	그럴듯하지만 날조의 잘못된 사실.22	의존성을 발명하거나 컨텍스트 공백을 메울 로직.
초두/최신성 편향	시작/끝에 초점을 텍스트의.20	핵심 비즈니스를 무시하는 중간에 위치한 로직 프로시저의.
확률적 생성	확률적 텍스트 예측.	일관성 없는 코드 생성. 재실행하면 프롬프트가 다른 로직을 산출한다.

2.3 "단어 가방" 대 "논리의 트리"

표준 LLM과 벡터 RAG 시스템은 코드를 주로 토큰의 수열로 처리한다. 그들은 의미 유사성에 의존한다—질의의 단어가 문서의 단어와 맞는지 확인하며 벡터 공간에서. ¹⁷

그러나 코드는 자연어가 아니다. 자연어에서 "고양이가 매트 위에 앉았다"는 의미가 50페이지 앞의 문장과 대체로 독립적이다. 소프트웨어에서 x = y + 1은 영(0)의 의미를 갖는다. x와 y의 정의, 유형, 현재 상태를 알지 못하면. 이들 정의는 다른 파일, 다른 모듈에 있거나 부모로부터 상속될 수 있다 클래스. ⁵

"래퍼" AI가 "결제 로직을 리팩터하라" 같은 질의의 컨텍스트를 검색할 때, 그것은 "payment"라는 단어가 들어 있는 코드 청크 다섯 개를 가져올 수 있다. 그것은 놓칠 가능성이 높다. 청크 이름이 GlobalVarDef.cbl인, 결제 로직이 쓰는 세율을 정의하는 파일을. 그 파일은 결코 "payment"라는 단어를 언급하지 않기 때문이다.

이 단절은 _텍스트 검색_과 구조적 이해 사이의 근본적 간극을 나타낸다. 이 간극을 메우려면 코드를 문학으로 취급하기를 멈추고 취급을 시작해야 한다 그래프로. ²³

3장: 소프트웨어의 물리학 –

그래프로서의 코드

3.1 관계형 시스템으로서의 소프트웨어

Veriprajna에서 우리는 소프트웨어 저장소가 본질적으로 관계형 데이터베이스임을 인식한다 논리의 . 코드베이스 안의 모든 엔티티—변수, 함수, 클래스, 모듈, 데이터베이스 스키마—는 밀집된 관계의 그물에 존재한다.

●​ 포함: 파일은 클래스를 포함하고, 클래스는 메서드를 포함하고, 메서드는 포함한다 변수 선언을.

●​ 상속: 클래스 B는 클래스 A로부터 속성과 메서드를 상속한다.

●​ 호출: 메서드 X는 메서드 Y를 호출한다.

●​ 데이터 흐름: 변수 Z는 함수 Q가 수정하고 함수 R이 읽는다.

이들 관계는 애플리케이션의 "그라운드 트루스"를 구성한다. 그것들은 확률적이지 않다. 그것들은 결정론적이다. 메서드 X가 메서드 Y를 호출하면, 그것은 단단한 사실이지 통계적 가능성이 아니다. 표준 LLM은 확률 영역에서 동작한다. 레거시를 안전하게 현대화하려면 시스템을, 우리는 그들의 확률적 생성 능력을 결정론적 현실에 닻을 내려야 한다 코드 구조의. ⁷

3.2 추상 구문 트리(AST)

이 구조적 이해의 기초 단위는 추상 구문 트리(AST) 이다. 그 AST는 소스 코드의 추상적 구문 구조의 트리 표현이다. 원시 텍스트 문자열과 달리, AST는 언어의 계층과 문법 규칙을 포착한다. ²⁴

예를 들어, COBOL 문: COMPUTE INTEREST = PRINCIPAL * RATE 은 단지 다섯 단어가 아니다. AST에서 그것은 AssignmentNode이며 Target(Interest)과 Expression을 갖는다. Expression은 MultiplicationNode이며 LeftOperand(Principal)과 RightOperand(Rate)를 갖는다.26 레거시 코드를 AST로 파싱함으로써, 우리는 텍스트의 모호함을 넘어선다. 우리는 할 수 있다 프로그래밍적으로 모든 변수 사용, 모든 산술 연산, 모든 제어를 식별한다 흐름 분기를. 이는 "왕복" 엔지니어링을 가능하게 한다—코드를 AST로 변환하고 데이터 손실 없이 코드로 되돌리며—구조 분석이 정확함을 보장한다. ²⁷

표준 RAG에서 쓰이는 "텍스트 청킹"과 달리—파일을 맹목적으로 500토큰으로 자르는 곳에서 세그먼트로, 종종 함수를 반으로 쪼개며—AST 파싱은 논리적 경계를 존중한다 코드의. 함수는 논리의 이산 단위로 취급되며, 무작위 텍스트 구간이 아니다. ²³

3.3 호출 그래프와 의존성 행렬

AST가 단일 파일의 구조를 나타내는 반면, 호출 그래프는 신경계를 나타낸다 전체 애플리케이션의. 그것은 제어의 흐름을 시각화하며, 어떤 단락 또는 서브루틴이 다른 것을 호출하는지를 매핑한다. ²⁹

레거시 COBOL 시스템에서 호출 그래프는 동적 호출이나 GOTO 로직에 의해 종종 가려진다. 그것이 "스파게티 코드"를 만든다. 정적 텍스트 분석은 GOTO LABEL_X가 어디로 가는지 쉽게 해석하지 못한다 착지한다. LABEL_X가 동적으로 또는 조건부로 정의된 경우.

엄격한 호출 그래프를 구축함으로써, Veriprajna는 "죽은 코드"(결코 호출되지 않는 코드)와 "갓 클래스"(지나치게 강하게 결합된 모듈)를 식별한다. 이 분석은 결정적이다 모놀리스를 마이크로서비스로 분해하는 데. 완전한 호출 사슬을 모르면, 우리는 서비스를 안전하게 추출할 수 없다. "매달린 참조"를 남길 위험이 있고, 그것은 유발한다 런타임 실패를—서두 사례 연구에서 은행을 괴롭힌 바로 그 시나리오. ³¹

표 3: 구조 분석 대 텍스트 분석

기능	텍스트 분석(표준 AI)	구조 분석 (Veriprajna)
분석 단위	토큰 / 단어	노드(AST 요소)
컨텍스트 경계	임의 토큰 한도	논리적 범위 (함수/클래스)
의존성 해석	키워드 매칭	그래프 순회
GOTO 처리	텍스트 문자열로 취급	제어 흐름 에지를 매핑
정확도	확률적	결정론적

3.4 의존성 주입과 반전

현대 Java와 클라우드 네이티브 아키텍처는 의존성 주입(DI)에 크게 의존한다. 그리고 제어의 반전(IoC). 레거시 COBOL은 반대로 하드코딩된 의존성에 의존한다 그리고 전역 상태에. 하나에서 다른 것으로 옮기려면 그래프의 모든 의존성을 식별해야 한다 그리고 그것을 "반전"해야 한다.

우리는 패러다임을 바꿔야 한다. "모듈 A가 데이터베이스 B에 대한 연결을 하드코딩한다"에서 "모듈 A가 데이터베이스 연결을 매개변수로 받는다"로. 이 아키텍처 전환은 불가능하다. AI가 애초에 의존성을 볼 수 없다면. 지식 그래프는 이들 의존성을 명시적으로 만들어, AI가 필요한 DI 보일러플레이트를 생성하게 한다 자동으로, 새 시스템이 모듈식이고 테스트 가능하도록 보장한다. ⁴

4장: Veriprajna 시맨틱 포지

4.1 저장소 인식 지식 그래프의 아키텍처

"Lost in the Middle" 증후군과 텍스트 기반 이전의 취약성에 대한 해법은 저장소 인식 지식 그래프 이다. 이것은 통합 그래프 데이터베이스로, 결합한다 코드의 정적 구조(AST, 호출 그래프)와 의미적 의미를 비즈니스 로직의(문서, 주석, 변수 의도). ⁵

Veriprajna는 독자적 파이프라인을 사용하며, 고급 연구에서 종종 불린다 "시맨틱 포지"로, 이 지능을 구축하기 위해. 이것은 일반 ETL 프로세스가 아니다. 그것은 레거시 현대화를 위한 목적 특화 엔진이다. ³³

4.2 1단계: Tree-sitter를 이용한 지능형 파싱

우리는 견고한 파서를 사용한다. 주로 Tree-sitter로, 레거시 코드베이스를 섭취하기 위해. 이 과정은 13개 이상의 언어를 지원한다. COBOL, JCL, PL/I, Java를 포함해. 파서는 생성한다 저장소의 모든 파일에 대한 AST를.

결정적으로, 우리는 시맨틱 청킹을 사용한다. 표준 RAG 파이프라인은 "나이브 분할"을 쓴다. 텍스트를 매 n 토큰마다 자른다. 이는 자주 함수 시그니처를 본문에서 끊거나 변수 정의를 사용처에서 끊어, 컨텍스트를 파괴한다. 시맨틱 청킹은 AST를 사용해 논리적 경계를 식별한다. 우리는 코드를 SECTION, PARAGRAPH, 또는 METHOD 단위로 청크한다. 그래프의 모든 노드가 완전하고 실행 가능한 논리 단위를 나타내도록 보장하며. ²³

4.3 2단계: 엔티티와 관계 추출

AST가 생성되면, 시맨틱 포지는 엔티티와 관계를 추출한다 그래프 데이터베이스를 채우기 위해(예: Neo4j, Memgraph).

●​ 엔티티: 클래스, 단락, 변수, 데이터베이스 테이블, API 엔드포인트.

●​ 관계:

○​ CALLS: 단락을 그것이 호출하는 서브루틴에 연결한다.

○​ UPDATES_TABLE: 논리 블록을 그것이 수정하는 DB2 테이블에 연결한다.

○​ IMPORTS_COPYBOOK: 소스 파일을 그 의존성에 연결한다.

○​ DEFINES_VARIABLE: 데이터 디비전을 그것이 생성하는 변수에 연결한다.

이 단계는 정적 텍스트를 동적 위상으로 변환한다. 이제 그래프를 질의할 수 있다. "CUSTOMER-ID 필드를 갱신하는 모든 단락을 보여 달라." 이 질의는 정확한 결과를 즉시 반환한다. grep이나 벡터 검색으로는 불가능한 위업이다. ¹⁴

4.4 3단계: 엔티티 해석과 병합

이것이 결정적 차별점이다. 표준 파서는 파일 A의 ACCT-NUM과 파일 B의 ACCT-NUM을 서로 다른 두 문자열로 본다. 우리 시스템은 심볼 해석을 수행한다. 그것은 둘 다 공유 카피북의 같은 항목을 가리킨다고 판정한다. 그것들을 병합한다 그래프의 단일 변수 노드로.

나아가, 우리는 교차 모달 병합을 수행한다. 코드베이스에 PDF가 포함되어 있으면 요구사항 문서가 "User API"를 기술하고, 코드에 클래스 이름이 UserAPI인 것이 있으면, 시스템은 임베딩을 계산해 같은 개념임을 인식한다. 그것은 문서 노드를 코드 노드와 병합한다. 이는 의도(문서)를 연결한다 구현(코드)과, AI에 "어떻게"와 함께 "왜"를 제공한다. ⁸

4.5 4단계: 추이적 폐포 계산

"은행 실패"는 전이 의존성 때문에 발생했다. A는 B에 의존하고, B는 C에 의존한다. AI는 A를 보았지만 C를 놓쳤다.

Veriprajna 지식 그래프는 추이적 폐포를 계산한다. 시스템이 분석할 때 모듈 A를, 직접 이웃에서 멈추지 않는다. 그래프를 깊이 순회한다(A -> B -> C) 모든 변수의 "진실의 뿌리"를 식별하기 위해. 이는 보장한다. AI가 생성할 때 모듈 A의 코드를, 모듈 C에서 올바른 정의를 가져오도록. 모듈 C가 다른 디렉터리나 저장소에 있더라도. ⁸

5장: 그래프 검색 증강 생성(GraphRAG)

5.1 벡터 RAG의 한계

벡터 검색 증강 생성(RAG)은 지식을 더하는 업계 표준이다 LLM에. 텍스트를 벡터(수치 표현)로 변환하고 유사한 벡터를 찾는다. FAQ 같은 비정형 텍스트 질의에는 뛰어나지만, 코드에는 불충분하다.

●​ 변수 이름 변경: 개발자가 Account를 Acct로 바꾸면, 의미 유사성은 떨어진다. 로직이 동일하더라도.

●​ 로직 대 키워드: "이자 계산"을 검색하면 실제 수학을 놓칠 수 있다. 만약 함수 이름이 FNC-001이고 주석이 없으면.

●​ 파편화된 컨텍스트: 벡터 RAG는 코사인 유사도에 기반해 "청크"를 검색한다. 그것은 단위 테스트와 UI 주석을 가져올 수 있지만, 핵심 비즈니스 로직을 놓친다. 왜냐하면 변수 이름이 질의 단어와 맞지 않기 때문이다. ³⁶

5.2 GraphRAG의 이점

GraphRAG는 지식 그래프의 구조 위에서 동작하며, 텍스트 유사성만이 아니다.

1.​ 앵커 식별: 사용자가 "결제 로직을 리팩터하라"고 물으면, 시스템은 사용한다 벡터 검색을 진입점을 찾기 위해(예: ProcessPayment 단락).

2.​ 그래프 순회(확장): 거기서 멈추지 않고, GraphRAG는 그래프를 순회한다 에지를. 그것은 끌어들인다.

○​ CALLS 에지를 서브루틴을 찾기 위해.

○​ READS 에지를 변수 정의를 찾기 위해.

○​ INCLUDES 에지를 카피북을 찾기 위해.

3.​ 컨텍스트 구성: 이들 연결된 조각—텍스트적으로는 다를 수 있지만 논리적으로는 분리 불가능한—이 일관된 프롬프트로 조립된다.

이 관련성 확장은 LLM이 자족적이고 실행 가능한 슬라이스를 받도록 보장한다 논리의. 그것은 계산의 _텍스트_만이 아니라, 그 _기계 장치_를 이해한다. ³⁶

5.3 멀티홉 추론

연구는 GraphRAG가 벡터 RAG를 크게 능가함을 보여 준다. 작업에서 요구되는 "멀티홉 추론"—여러 단계로 떨어진 사실을 연결하는. 소프트웨어에서, 거의 모든 버그는 멀티홉 추론의 실패다(예: A가 B를 호출하고, B가 X를 바꾸고, C가 X를 읽는다. 만약 A가 바뀌면, C가 깨지는가?).

GraphRAG는 AI가 복잡한 영향 분석 질문에 답하게 한다. "이자를 바꾸면 모듈 A의 금리 로직이, 모듈 Z의 어떤 보고 화면이 영향을 받는가?" 벡터 RAG는 이에 답할 수 없다. 모듈 A와 모듈 Z는 텍스트 유사성을 공유하지 않기 때문이다. 그들은 연결되어 있다 함수 호출의 사슬로만. 그래프는 이 사슬을 순회해 확정적 답을 제공한다. ³⁸

표 4: 벡터 RAG 대 GraphRAG

기능	벡터 RAG	GraphRAG
검색 키	유사도(코사인 거리)	관계(그래프 에지)
컨텍스트 품질	높은 재현율, 낮은 정밀도 (노이즈)	높은 정밀도, 연결된 컨텍스트

멀티홉 추론	빈약(간접 링크를 놓침)	우수(순회한다 사슬을)
환각 위험	높음(빠진 것을 추측한다 링크를)	낮음(검색된 링크는 명시적이다)
최적 사용 사례	비정형 텍스트(FAQ)	구조화 시스템(코드, 생물학)

6장: 이전을 엔지니어링하다 – 기술 심층 분석

6.1 "전역 변수" 함정 해결

COBOL의 가장 위험한 측면 중 하나는 전역 변수의 사용이다. 정의되는 곳은 DATA DIVISION이며 프로그램 전반의 다양한 PERFORM 문이 수정한다. Java에서 모범 관행은 캡슐화를 지시한다. 메서드는 숨은 상태에 의존해서는 안 된다.

해법: Veriprajna의 에이전트는 그래프에서 데이터 흐름 분석을 수행한다. 우리는 수명 주기를 추적한다. 모든 변수의.

●​ 단락 CALC-TAX가 GROSS-INCOME을 읽으면, 그래프는 GROSS-INCOME을 식별한다 입력 의존성 으로.

●​ Java 메서드 calcTax()를 생성할 때, AI는 명시적으로 BigDecimal을 추가한다 grossIncome을 메서드 시그니처에.

●​ 그런 다음 메서드의 _호출자_를 갱신해 올바른 값을 전달하게 한다.

이 자동 리팩터링은 "암묵적 전역 상태"에서 "명시적 매개변수 전달"로 사례 연구에서 은행을 괴롭힌 부작용 버그를 방지한다. ⁴

6.2 GOTO 스파게티의 해체

COBOL 이전에서 가장 혹독한 장애물 중 하나는 GOTO 문이다. GOTO는 허용한다 프로그램 실행이 어디든 점프하게, 비선형 제어 흐름을 만들며 그것은 극히 혐오된다 현대 구조화 프로그래밍에. ⁴⁰ Java에는 GOTO 문이 없다.

GOTO 로직을 번역하려면 구문 번역 이상이 필요하다. 그것은 요구한다 제어 흐름 평탄화 .

1.​ 그래프 분석: 우리는 GOTO 목적지를 제어 흐름 그래프의 에지로 매핑한다 (CFG).

2.​ 패턴 인식: 그래프는 패턴을 식별한다.

○​ 이전 레이블로 되돌아가는 GOTO는 루프 로 식별된다.

○​ 블록을 건너뛰는 GOTO는 조건문(if/else)으로 식별된다.

○​ 종료 단락으로의 GOTO는 반환 이다.

3.​ 재구조화: AI는 그래프의 안내를 받아 이들 점프를 while 루프로 리팩터한다. do-while 루프, 또는 Java의 break/continue 문으로.

GOTO가 만드는 "루프"를 시각화할 그래프 없이, 텍스트 기반 LLM은 종종 재귀 함수 호출을 생성해 StackOverflowError로 이어지거나, 단순히 환각한다 존재하지 않는 논리 흐름을. ⁴

6.3 "죽은 코드" 처리

레거시 시스템은 더 이상 쓰이지 않는 코드로 가득하다—옛 프로모션, 폐기된 제품, 디버그 루틴. 이 코드를 이전하는 것은 돈 낭비이며 보안 공격면을 더한다. 텍스트 기반 AI는 주어진 모든 것을 이전한다. 활성과 죽은 것을 구별하지 못한다 코드를.

해법: 호출 그래프는 도달 불가 노드를 식별한다—들어오는 것이 없는 단락이나 파일 에지(호출자 없음). Veriprajna 시스템은 이 "죽은 코드"를 삭제로 표시한다. 그 전에 이전이 시작되기. 이는 전형적으로 코드베이스 크기를 20-30% 줄이며, 상당한 비용 절감과 더 깨끗한 최종 아키텍처로 이어진다.31

7장: 에이전틱 미래 – 심층 AI 대 얕은 래퍼

7.1 챗봇을 넘어: 에이전틱 워크플로

Veriprajna는 "챗봇"을 배포하지 않는다. 우리는 자율 AI 에이전트를 배포한다. 에이전트는 계획하고, 실행하고, 피드백에 기반해 행동을 교정할 수 있는 시스템이다. ²

얕은 래퍼 워크플로:

1.​ 사용자: "이 코드를 변환해."

2.​ 래퍼: 텍스트를 GPT-4로 보낸다.

3.​ 출력: Java 코드를 반환한다.

4.​ 결과: 코드가 컴파일되거나 실행되지 못한다. 개발자가 수동으로 디버그한다.

Veriprajna 심층 에이전트 워크플로:

1.​ 계획: 에이전트는 대상 COBOL 파일의 AST를 분석한다. 그것은 식별한다 의존성을 지식 그래프에 질의한다.

2.​ 검색: 이전에 필요한 GraphRAG 컨텍스트를 가져온다.

3.​ 생성: "스키마틱-제약 디코더"를 사용해 Java 코드를 생성한다. 그것이 Java 구문 규칙과 타입 안전성을 강제한다. ⁷

4.​ 검증(루프): 에이전트는 샌드박스에서 생성된 Java 코드를 _컴파일_한다.

5.​ 자기 교정: 컴파일러가 오류를 던지면(예: "Variable not found"), 에이전트는 오류를 읽고, 빠진 의존성을 그래프에 질의하고, 코드를 재생성한다.

6.​ 유효성 검사: 단위 테스트를 실행한다(원본 COBOL 트레이스에서 생성) 보장하기 위해 출력이 입력 동작과 일치하도록.

이 컴파일-수정 루프는 검증 부담을 인간에서 AI로 옮기며, 극적으로 리팩터링 비용을 줄인다. ⁴²

7.2 휴먼인더루프 감독

에이전트는 실행에서는 자율적이지만, 전략에서는 감독된다. 지식 그래프는 해석 가능성을 제공한다. "블랙박스" 신경망과 달리, 그래프는 개발자가 보게 한다 정확히 왜 AI가 결정을 내렸는지를. "AI가 com.bank.logic를 가져온 이유는 그것이 발견했기 때문이다 COPYBOOK-X에 대한 의존성을."

이 투명성은 규제 산업에 필수적이다. 은행처럼, 모든 코드 줄이 반드시 감사 가능해야 한다. 우리는 "믿어라, 나는 AI다"에서 "이 로직의 인용 사슬이 여기 있다"로 옮긴다. ⁴³

8장: 결론과 전략적 전망

8.1 저장소 인식의 ROI

맥킨지 데이터는 GenAI가 코딩 작업을 50% 줄일 수 있다고 시사한다. 다만 배포될 때만 올바르게. ¹⁴ Veriprajna의 그래프 기반 접근의 투자수익률(ROI)은 구동된다 재작업의 제거에 의해.

●​ 수동 이전: 높은 비용, 높은 위험, 느린 출시 시간.

●​ 래퍼 AI: 중간 비용("환각" 디버깅으로 인해), 높은 위험(숨은 버그), 중간 출시 시간.

●​ 저장소-그래프 AI: 낮은 비용(자동화), 낮은 위험(결정론적 검증), 빠른 출시 시간.

"컨텍스트 전환" 오버헤드를 제거함으로써—개발자가 몇 시간씩 찾는 곳에서 변수가 정의된 곳을—Veriprajna는 개발자 생산성을 2x에서 3x로 높인다. 비교하면 표준 AI 도구에. ²

8.2 지속적 현대화를 통한 미래 대비

현대화는 일회성 사건이 아니다. 그것은 수명 주기다. 코드베이스가 변환되면 지식 그래프로, 그것은 살아있는 자산으로 남는다. 새 Java 코드가 진화하면서, 그래프는 실시간으로 갱신된다. 이는 가능하게 한다.

●​ 자동 문서화: AI는 최신 문서를 생성할 수 있다 새 시스템을 위해 그래프를 읽어. ⁴⁴

●​ 아키텍처 드리프트 탐지: 시스템은 새 코드가 위반하면 아키텍트에게 알릴 수 있다 그래프에 정의된 모듈성 규칙을. ⁴⁵

8.3 구조적 전환

"은행 실패"의 교훈은 분명하다. 코드는 텍스트가 아니다. 그것은 복잡하고 상호 연결된 논리 시스템이다. 텍스트만 이해하는 도구로 그것을 현대화하려는 것은 비슷하다 지도 없이 거리 이름 목록만으로 도시를 탐색하려는 것과. 당신은 "Lost in the Middle"에 빠질 것이다.

Veriprajna는 지도를 제공한다. 저장소 인식 지식 그래프를 구축함으로써, 우리는 제공한다 AI에 레거시 시스템의 복잡성을 헤쳐 나가는 데 필요한 구조적 지능을 제공한다. 우리는 의존성을 매핑하고, 매듭을 풀고, 작동하는 현대화를 전달한다 구문만이 아니라, 현실에서.

우리는 코드를 쓰기만 하지 않는다. 이해를 엔지니어링한다. 이것이 차이다 챗봇과 솔루션 제공자 사이의. 이것이 엔터프라이즈 현대화의 미래다.

Veriprajna. 심층 솔루션을 위한 심층 AI.

참고문헌

1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders, 2025년 12월 10일 열람, https://www.pragmaticcoders.com/resources/legacy-code-stats

2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy, 2025년 12월 10일 열람, https://softprodigy.com/ai-driven-legacy-app-modernization/

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, 2025년 12월 10일 열람, https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs, 2025년 12월 10일 열람, https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation, 2025년 12월 10일 열람, https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

6. Structural-Semantic Code Graph (SSCG) - Emergent Mind, 2025년 12월 10일 열람, https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate, 2025년 12월 10일 열람, https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv, 열람 2025년 12월 10일, https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, 2025년 12월 10일 열람, https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help, 2025년 12월 10일 열람, https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix, 2025년 12월 10일 열람, https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions, 2025년 12월 10일 열람, https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz, 2025년 12월 10일 열람, https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, 2025년 12월 10일 열람, https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs, 2025년 12월 10일 열람, https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome, 2025년 12월 10일 열람, https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch, 2025년 12월 10일 열람, https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium, 2025년 12월 10일 열람, https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

19. A practical guide to the Claude code context window size - eesel AI, 열람 2025년 12월 10일, https://www.eesel.ai/blog/claude-code-context-window-size

20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct, 2025년 12월 10일 열람, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

21. Why Language Models Are “Lost in the Middle” - Towards AI, 2025년 12월 10일 열람, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind, 2025년 12월 10일 열람, https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers, 2025년 12월 10일 열람, https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

24. AST-Based Source Code Migration Through Symbols Replacement, 2025년 12월 10일 열람, https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

25. BMSD 2011, 2025년 12월 10일 열람, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

26. Abstract Syntax Tree Creation - Compiler Design - Meegle, 2025년 12월 10일 열람, https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium, 2025년 12월 10일 열람, https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

28. Daily Papers - Hugging Face, 2025년 12월 10일 열람, https://huggingface.co/papers?q=outlier%20chunk%20handling

29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp, 2025년 12월 10일 열람, https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, 2025년 12월 10일 열람, https://ieeexplore.ieee.org/document/9138056/

31. Enhancing Neural Code Representation with Additional Context - arXiv, 열람 2025년 12월 10일, https://arxiv.org/html/2510.12082v1

32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, 2025년 12월 10일 열람, https://www.ijcai.org/proceedings/2025/0848.pdf

33. Code Graph: From Visualization to Integration - FalkorDB, 12월 열람 10일, 2025년, https://www.falkordb.com/blog/code-graph/

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, 2025년 12월 10일 열람, https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv, 2025년 12월 10일 열람, https://arxiv.org/html/2511.07584

36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph, 열람 2025년 12월 10일, https://memgraph.com/blog/rag-vs-graphrag

37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype, 2025년 12월 10일 열람, https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

38. Navigating the Nuances of GraphRAG vs. RAG - foojay, 2025년 12월 10일 열람, https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket, 2025년 12월 10일 열람, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

40. Why not GOTO Statement? [closed] - Stack Overflow, 2025년 12월 10일 열람, https://stackoverflow.com/questions/19766205/why-not-goto-statement

41. Alternative to a goto statement in Java - Stack Overflow, 2025년 12월 10일 열람, https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers, 2025년 12월 10일 열람, https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

43. Legacy IT Modernization with AI | MITRE, 2025년 12월 10일 열람, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, 2025년 12월 10일 열람, https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

45. The AI revolution in application modernization: from manual burden to strategic advantage, 2025년 12월 10일 열람, https://vfunction.com/blog/ai-app-modernization-strategy/