AI가 30년치 COBOL을 완벽하게 번역했다. 그런데 데이터베이스가 무너졌다.
화요일 밤이었고, 나는 도무지 말이 안 되는 스택 트레이스를 응시하고 있었다.
우리는 한 금융 서비스 팀과 함께 핵심 트랜잭션 모듈을 COBOL에서 Java로 마이그레이션하려 하고 있었다. AI는 자기 역할을 해냈다 — 적어도 우리는 그렇게 생각했다. 생성된 Java 코드는 깔끔하고 구조가 잘 잡혀 있었으며, 단 하나의 오류도 없이 컴파일되었다. 단위 테스트도 통과했다. 통화에 참여한 모두가 조심스럽게 낙관하고 있었다. 그런 다음 그들은 그것을 테스트 환경에 배포했고, 첫 번째 전신 송금이 데이터베이스를 손상시켰다.
버그는 Java에 있지 않았다. Java는 문법적으로 완벽했다. 버그는 AI가 결코 보지 못한 것에 있었다.
한 변수 TRN-LIMIT — 이 변수는 AI가 번역한 소스 파일이 아니라 실행 체인에서 수천 줄 앞에 포함된 COPYBOOK에 정의되어 있었고, REDEFINES 절을 담고 있었다. 이것은 완전히 다른 모듈에서 설정된 플래그에 따라 동일한 메모리 주소가 두 개의 서로 다른 데이터 타입으로 해석되는 COBOL 구문이다. AI는 TRN-LIMIT을 단순한 숫자 필드로 보았다. 하지만 아니었다. 그것은 실행 시점의 컨텍스트에 따라 정수로 위장한 팩 십진수였다. AI는 표준 정의를 환각했고, Java 애플리케이션은 손상된 이진 데이터를 데이터베이스 컬럼에 기록했다.
그날 밤, 회의실에 팀과 앉아 무엇이 잘못되었는지 하나하나 뜯어보면서, 나는 Veriprajna에서 우리가 만든 모든 것을 재편하게 될 무언가를 깨달았다: AI는 멍청해서 실패한 것이 아니었다. 눈이 멀었기 때문에 실패한 것이었다.
아무도 이야기하고 싶어 하지 않는 1조 5,200억 달러짜리 문제
2025년 글로벌 경제의 불편한 현실은 이렇다: 은행 시스템의 43%가 여전히 COBOL 위에서 돌아가고, 이 시스템들은 모든 ATM 거래의 95%를 처리한다. 포춘 500대 기업을 돌리는 소프트웨어? 그중 대략 70%가 20년도 더 전에 작성되었다. 미국만 놓고 봐도 기술 부채는 약 1조 5,200억 달러로 부풀어 올랐다.
그리고 이 코드를 작성한 사람들은 은퇴하고 있다. "언젠가 은퇴할지도 모른다"가 아니라 — 그들은 지금 떠나고 있으며, 수십 년의 조직적 지식을 함께 가지고 간다. 한편 연방 IT 예산의 80%는 레거시 시스템을 살려두는 데 쓰이고, 새로운 무언가에 쓸 수 있는 것은 겨우 20%밖에 남지 않는다.
나는 자신들의 현대화 상황을 무너져 가는 기초 위에 선 집처럼 묘사하는 CTO들과 마주 앉아 본 적이 있다: 고쳐야 한다는 것을 알고, 기다릴수록 더 나빠진다는 것을 알지만, 시도한 모든 업체가 실제로 문제를 해결하지는 못한 채 비용만 더 늘려 놓았다는 것이다.
숫자가 이를 뒷받침한다. 레거시 현대화 프로젝트의 70%에서 80%가 목표를 달성하지 못한다. 이것은 생성형 AI가 등장하기 이전에도 사실이었다.
왜 모두가 GPT가 이것을 고칠 수 있다고 생각했을까?
이해한다. 정말로 그렇다. GPT-4가 출시되자 소프트웨어 컨설팅 시장은 과열되었다. 갑자기 모든 회사가 "COBOL 마이그레이션 액셀러레이터"를 갖게 되었는데 — 뚜껑을 열어보면 그것은 파운데이션 모델을 감싼 얇은 래퍼에 불과했다. COBOL 문단을 붙여 넣으면 Java 메서드를 돌려받는다. 마법이다.
공동창업자와 나는 이 도구들을 평가하는 데 몇 주를 보냈다. 우리는 고객 환경의 실제 레거시 코드를 그것들에 넣고 출력을 확인했다. 문법은 거의 항상 맞았다. 코드는 컴파일되었다. 그러고 나서 그것은 진단하기 극도로 어려운 방식으로 실패하곤 했는데, 코드의 형태가 옳아 보였기 때문이다. 심지어 의미가 틀렸을 때조차도 말이다.
가장 위험한 버그는 시스템을 다운시키는 버그가 아니다. 그것은 아무도 알아차리기 전 6개월 동안 데이터를 조용히 손상시키는 버그다.
문제는 아키텍처적이며, 그것은 대규모 언어 모델이 정보를 처리하는 방식으로 귀결된다. LLM은 입력의 서로 다른 부분의 중요도를 저울질하기 위해 어텐션 메커니즘을 사용한다. 최신 모델은 최대 100만 토큰의 컨텍스트 윈도우를 자랑한다. 하지만 연구는 "중간에서 길을 잃는(Lost in the Middle)" 효과라 불리는 현상을 입증했다: LLM은 U자형 성능 곡선을 보이며, 프롬프트의 시작과 끝에 있는 정보는 잘 회상하지만 중간에 있는 것에 대해서는 성능이 크게 저하된다.
현대화 프로젝트에서 단일 COBOL 프로그램은 수천 줄에 달할 수 있고, 그 자체로 수천 줄에 달하는 카피북을 참조한다. 만약 MAX-TRANSACTION-LIMIT의 정의가 그 방대한 컨텍스트의 중간에 자리 잡고 있다면, AI가 그것을 놓칠 확률이 통계적으로 높다. 그리고 무언가를 놓쳤을 때 AI는 멈춰 서서 묻지 않는다. 환각한다. 그럴듯한 정의를 지어내고 넘어간다.
코드를 텍스트처럼 다루면 무슨 일이 벌어질까?
이것은 내가 "AI 래퍼" 생태계 전체가 저지르고 있다고 보는 핵심적 실수이며, 초창기에 잠재 투자자와 계속 벌였던 논쟁이기도 하다. 그는 우리의 접근법 — 코드 저장소의 지식 그래프를 구축하는 것 — 을 보고 말했다. "그냥 더 큰 컨텍스트 윈도우를 쓰면 되지 않나요? GPT-5가 이걸 해결할 겁니다."
나는 노트북에 COBOL 프로그램을 띄웠다. "ACCOUNT-BALANCE의 정의를 찾아보세요," 내가 말했다.
그는 파일을 검색했다. 찾지 못했다. 그 파일에 없었기 때문이다. 그것은 카피북 안에 있었고, 47번 줄의 문장을 통해 포함되었으며, 그 카피북 자체는 완전히 다른 팀이 관리하는 공유 데이터 디비전을 참조하고 있었다.
"이제 당신이 LLM이라고 상상해 보세요," 내가 말했다. "당신은 '결제 처리'와 관련된 코드에 대해 벡터 유사도 검색을 하고 있습니다. 'payment'라는 단어가 언급된 다섯 개의 청크를 찾을 겁니다. 하지만 GlobalVarDef.cbl이라는 파일은 완전히 놓칠 겁니다 — 그 파일은 결제 로직이 사용하는 세율을 정의하지만, 어디에서도 'payment'라는 단어를 언급하지 않기 때문입니다."
표준 검색 증강 생성, 즉 RAG — 대부분의 AI 코딩 도구가 LLM에 지식을 더하기 위해 사용하는 기법 — 은 텍스트 유사성에 기반해 컨텍스트를 검색한다. 그것은 코드를 벡터로 변환하고 유사한 벡터를 찾는다. 이것은 FAQ 챗봇에는 훌륭하게 작동한다. 코드에는 치명적으로 불충분하다.
코드는 자연어가 아니다. "고양이가 매트 위에 앉았다"는 당신이 50페이지 전에 무엇을 읽었든 대체로 같은 것을 의미한다. 하지만 x = y + 1은 아무것도 의미하지 않는다 — 당신이 x와 y의 정의, 타입, 현재 상태를 알지 못하는 한 말이다 — 이것들은 다른 파일, 다른 모듈에 정의되어 있거나 부모 클래스로부터 상속되었을 수 있다.
나는 이 구조적 문제에 대해 우리 연구의 인터랙티브 버전에서 깊이 있게 다뤘다. 짧게 말하자면: 소프트웨어는 텍스트가 아니다. 소프트웨어는 그래프다.
우리가 더 나은 래퍼 만들기를 그만둔 밤
한 순간이 있었다 — 나는 그것을 또렷이 기억한다 — 우리 팀이 아키텍처를 두고 논쟁하던 때였다. 우리에게는 두 갈래 길이 있었다. 첫 번째 길: 더 똑똑한 RAG 파이프라인을 구축한다. 더 나은 청킹, 더 나은 임베딩, 더 나은 프롬프트. 충분히 잘 작동할 때까지 래퍼 접근법을 반복 개선한다. 두 번째 길: 텍스트 기반 패러다임을 완전히 내던지고 코드를 실제 그 자체 — 논리의 관계형 시스템 — 로 다룬다.
첫 번째 길이 더 빨랐다. 첫 번째 길은 투자자들이 이해하는 것이었다. 첫 번째 길에는 이미 시장 수요를 입증하고 있는 열두 개의 경쟁자가 있었다.
리드 엔지니어가 화이트보드를 꺼내 COBOL 프로그램을 그래프로 그렸다. 변수, 함수, 카피북, 데이터베이스 테이블을 위한 노드. 그리고 CALLS, READS, UPDATES_TABLE, IMPORTS_COPYBOOK를 위한 엣지. 그런 다음 그녀는 종속성 사슬을 추적했다: 모듈 A가 모듈 B를 호출하고, B는 변수 X를 수정하며, X는 완전히 다른 디렉터리에 있는 모듈 C에 의해 읽힌다.
"벡터 검색에게 그 사슬을 찾아보라고 해봐," 그녀가 말했다.
아무도 찾을 수 없었다.
그날 밤 우리는 지금 우리가 저장소 인식 지식 그래프(Repository-Aware Knowledge Graph)라고 부르는 것을 구축하기로 다짐했다 — 코드의 정적 구조(추상 구문 트리, 호출 그래프)와 비즈니스 로직의 의미론적 의미(문서, 주석, 변수 의도)를 결합한 통합 그래프 데이터베이스다. 우리는 더 나은 번역기를 만들려는 것이 아니었다. 우리는 지도를 만들려 하고 있었다.
30년치 COBOL을 어떻게 지도로 바꿀 것인가?
이 과정은 네 단계로 이루어지며, 구현 세부사항은 생략하겠다 — 그것들은 우리의 전체 기술 심층 분석에서 찾을 수 있다. 하지만 개념은 중요한데, 왜 이 접근법이 래퍼가 실패하는 곳에서 작동하는지를 설명해 주기 때문이다.
첫째, 우리는 코드를 텍스트가 아니라 구조적으로 파싱한다. 표준 RAG 파이프라인은 "순진한 분할"을 사용한다 — 500 토큰마다 파일을 잘라내는데, 이는 종종 함수 시그니처를 그 본문에서 떼어놓는다. 우리는 Tree-sitter 같은 파서를 사용해 추상 구문 트리를 생성하며, 이는 코드의 논리적 경계를 존중한다. 함수는 무작위 텍스트 구간이 아니라 완전한 논리 단위로 취급된다.
둘째, 우리는 엔티티와 관계를 추출한다. 클래스, 문단, 변수, 데이터베이스 테이블, API 엔드포인트 — 이것들이 노드가 된다. 그들 사이의 엣지 — CALLS, UPDATES_TABLE, DEFINES_VARIABLE — 는 결합 조직이 된다. 이제 우리는 그래프에 질의할 수 있다: "CUSTOMER-ID 필드를 업데이트하는 모든 문단을 보여줘." 정확한 결과가, 즉시. grep으로 그걸 해보라.
셋째 — 그리고 여기서부터 흥미로워진다 — 우리는 저장소 전체에 걸쳐 심볼을 해석한다. 표준 파서는 파일 A의 ACCT-NUM과 파일 B의 ACCT-NUM을 서로 다른 두 개의 문자열로 본다. 우리 시스템은 둘 다 공유 카피북의 동일한 항목을 가리킨다고 판단하고 이들을 하나의 노드로 병합한다. 우리는 또한 문서와 코드를 병합한다: PDF 요구사항 문서가 "User API"를 설명하고 코드에 UserAPI라는 이름의 클래스가 있다면, 시스템은 의도와 구현을 연결한다.
넷째, 우리는 이행적 폐쇄를 계산한다. 그 은행 장애를 기억하는가? A가 B에 의존하고, B가 C에 의존하는데, AI는 A를 보았지만 C를 놓쳤다. 우리 그래프는 깊이 순회한다 — A에서 B로, B에서 C로 — 모든 변수의 근원 정의를 식별하기 위해서다. AI가 모듈 A에 대한 코드를 생성할 때, 모듈 C가 완전히 다른 디렉터리나 저장소에 있더라도 모듈 C로부터 올바른 정의를 가져온다.
왜 표준 RAG는 코드 마이그레이션에서 실패하는가?
사람들은 늘 이에 반발한다. "RAG는 코드에도 잘 작동해요," 그들은 말할 것이다. "그냥 더 나은 임베딩을 쓰세요."
벡터 유사도 검색이 완전히 무너지는 세 가지 시나리오를 들려주겠다:
한 개발자가 Account를 Acct로 이름을 바꾼다. 로직은 동일한데도 의미론적 유사도는 떨어진다. FNC-001이라는 이름의 함수는 이자 계산을 수행하지만 주석이 전혀 없다 — "이자 계산"을 검색해도 결코 그것을 찾지 못할 것이다. 그리고 가장 흔한 실패: 벡터 RAG는 "payment"를 언급하는 단위 테스트와 UI 주석을 검색해 오지만, 변수 이름이 질의어와 일치하지 않기 때문에 핵심 비즈니스 로직은 놓친다.
그래프 기반 검색은 "어떤 텍스트가 비슷해 보이는가?"를 묻지 않는다. 그것은 "무엇이 논리적으로 연결되어 있는가?"를 묻는다 — 그리고 그 구분이 바로 컴파일되는 코드와 실제로 작동하는 코드의 차이다.
우리가 GraphRAG라고 부르는 것은 유사성이 아니라 구조에 기반해 작동한다. 누군가 "결제 로직을 리팩터링해줘"라고 요청하면, 시스템은 벡터 검색을 사용해 진입점 — 예를 들어 ProcessPayment 문단 — 을 찾는다. 하지만 그런 다음, 멈추는 대신 그래프의 엣지를 순회한다. CALLS 엣지를 통해 서브루틴을, READS 엣지를 통해 변수 정의를, INCLUDES 엣지를 통해 카피북을 끌어온다. 이렇게 연결된 조각들은 텍스트상으로는 다를 수 있지만 논리적으로는 분리할 수 없다.
연구에 따르면 GraphRAG는 다중 홉 추론 — 여러 단계로 떨어져 있는 사실들을 연결하는 것 — 에서 벡터 RAG를 크게 능가한다. 소프트웨어에서 거의 모든 심각한 버그는 다중 홉 추론의 실패다. 내가 모듈 A의 이자율 로직을 바꾸면, 모듈 Z의 어떤 보고 화면이 깨지는가? 벡터 RAG는 이것에 답할 수 없다. 그래프는 답할 수 있는데, 그것들을 연결하는 함수 호출 사슬을 순회하기 때문이다.
GOTO 문제 (또는: 왜 COBOL은 AI가 루프를 환각하게 만드는가)
우리를 거의 무너뜨릴 뻔한 한 가지 구체적인 기술적 난제에 대해 이야기하고 싶다. 이 일이 사람들이 생각하는 것보다 훨씬 더 어려운 이유를 잘 보여주기 때문이다.
COBOL에는 GOTO 문이 있다. Java에는 없다. GOTO는 프로그램 실행이 어디로든 점프하게 해준다 — 앞으로, 뒤로, 다른 블록의 한가운데로. 그것은 모든 컴퓨터 과학 교수가 경고하는 "스파게티 코드"를 만든다. GOTO를 번역하는 것은 문법 문제가 아니다. 그것은 위상(topology) 문제다.
우리는 세 가지 서로 다른 상용 AI 도구가 GOTO를 많이 사용하는 COBOL 모듈을 번역하려 시도하는 것을 지켜봤다. 하나는 프로덕션에서 StackOverflowError를 일으켰을 재귀 함수 호출을 생성했다. 다른 하나는 종료 조건이 없는 while(true) 루프를 만들어냈다. 세 번째 — 내가 개인적으로 가장 좋아하는 것 — 은 그저 원본 코드에 존재하지 않는 제어 흐름을 지어냈다. 그럴듯해 보였다. 완전히 틀렸다.
우리의 접근법: GOTO 목적지를 제어 흐름 그래프의 엣지로 매핑한다. 그런 다음 그래프에 패턴 인식을 적용한다. 앞선 레이블로 되돌아가 점프하는 GOTO? 그것은 루프다. 블록을 건너뛰는 GOTO? 그것은 조건문이다. 종료 문단으로 가는 GOTO? 그것은 반환문이다. 그래프 구조의 안내를 받는 AI는 이 점프들을 while 루프, if/else 블록, 또는 break/continue 문으로 리팩터링한다.
그래프가 없으면 AI는 추측하고 있다. 그래프가 있으면 그것은 엔지니어링하고 있다.
챗봇과 에이전트의 차이
우리는 챗봇을 만들지 않는다. 이 점을 분명히 해두어야 하는데, 시장이 당신의 "코드베이스와 채팅"하게 해주는 도구들로 넘쳐나지만 그것들은 같은 것이 아니기 때문이다.
챗봇은 당신의 질문을 받아 GPT-4에 보내고, 돌아오는 것은 무엇이든 반환한다. 출력이 틀리면 당신이 수동으로 디버깅한다. 그것이 시장의 모든 AI 래퍼의 작업 방식이다.
우리가 배포하는 것은 계획하고, 실행하고, 스스로 교정하는 자율 에이전트다. 에이전트는 대상 COBOL 파일의 AST를 분석하고, 종속성을 식별하고, 지식 그래프에 질의하고, Java 코드를 생성한 다음, 샌드박스에서 그것을 컴파일한다. 컴파일러가 오류 — "변수를 찾을 수 없음" — 를 던지면, 에이전트는 그 오류를 읽고, 누락된 종속성을 그래프에 질의하고, 다시 생성한다. 그런 다음 원본 COBOL 실행 트레이스에서 파생된 단위 테스트를 실행해 동작의 동등성을 검증한다.
이 컴파일-수정 루프는 검증 부담을 사람에게서 시스템으로 옮긴다. 하지만 — 그리고 이것은 규제 산업에서 엄청나게 중요한데 — 지식 그래프는 완전한 해석 가능성을 제공한다. 개발자는 AI가 모든 결정을 내린 이유를 정확히 볼 수 있다: "AI는 com.bank.logic을 가져왔는데, COPYBOOK-X에 대한 종속성을 발견했기 때문이다." "그냥 나를 믿어, 나는 AI야"가 아니다. 대신: 이 로직에 대한 인용 사슬이 여기 있다.
은행업에서는 모든 코드 한 줄이 감사 가능해야 한다. "아마도" 맞았을 블랙박스를 배포할 수는 없다. 자기 작업을 보여줄 수 있는 시스템이 필요하다.
죽은 코드는 어떤가?
나를 놀라게 한 한 가지: 레거시 시스템은 아무도 더 이상 사용하지 않는 코드로 가득 차 있다. 오래된 프로모션, 단종된 제품, 1997년의 디버그 루틴. 텍스트 기반 AI는 주어진 모든 것을 마이그레이션한다 — 활성 코드와 죽은 코드를 구분하지 못한다.
우리의 호출 그래프는 도달 불가능한 노드 — 들어오는 엣지가 없는, 즉 아무것도 호출하지 않는 문단이나 파일 — 를 식별한다. 우리는 이 죽은 코드를 마이그레이션이 시작되기 전에 삭제하도록 표시한다. 우리 경험상 이는 일반적으로 코드베이스를 20~30% 줄인다. 그것은 사소한 최적화가 아니다. 그것은 작업의 4분의 1과 공격 표면의 4분의 1을 제거하는 것이다.
"더 큰 컨텍스트 윈도우가 이걸 해결하지 않을까?"
나는 여전히 이 질문을 끊임없이 받는다. GPT-5나 Claude 4가 1,000만 토큰을 처리할 수 있다면 "중간에서 길을 잃는" 문제가 사라진다는 가정이다.
그렇지 않을 것이다. 그 이유는 이렇다.
어텐션 저하가 개선되더라도 — 그리고 그럴 것이다 — 당신은 여전히 텍스트 검색을 하고 있는 것이다. 당신은 여전히 논리적 연결을 순회하는 대신 유사한 문자열을 검색하고 있다. 당신이 번역하는 파일과 키워드가 하나도 겹치지 않는 파일에 필요한 변수가 정의되어 있다면, 100만 토큰 컨텍스트 윈도우는 도움이 되지 않는다. 문제는 윈도우의 크기가 아니다. 문제는 윈도우가 잘못된 것을 보고 있다는 것이다.
내가 듣는 또 다른 반론: "지식 그래프는 구축하는 데 비용이 많이 든다." 그렇다. 저장소 전체를 파싱하고, 심볼을 해석하고, 이행적 폐쇄를 계산하는 것 — 그것은 상당한 초기 투자다. 하지만 대안을 고려해 보라. 대규모 COBOL 시스템의 수동 마이그레이션은 수천만 달러가 들고 수년이 걸린다. 래퍼 기반 AI 마이그레이션은 초기 비용은 덜 들지만, 값비싼 사람의 디버깅을 요구하는 환각 유발 버그를 꾸준히 만들어낸다. 그래프 기반 접근법은 설정 비용은 더 높지만 재작업 비용은 극적으로 더 낮다. 맥킨지 데이터는 GenAI가 코딩 작업을 50% 줄일 수 있음을 시사하지만, 이는 올바르게 배포되었을 때만 그렇다. 우리는 표준 AI 도구 대비 개발자 생산성이 2배에서 3배 향상되는 것을 보았는데, 특히 개발자들이 변수가 어디에 정의되어 있는지 찾느라 몇 시간을 쓰는 일을 멈추기 때문이다.
지도가 곧 자산이다
내가 처음에 이해했더라면 좋았을 것은 이것이다: 지식 그래프는 단지 마이그레이션을 위한 도구가 아니다. 그것은 영구적인 자산이다.
일단 당신의 코드베이스가 그래프로 존재하게 되면, 그것은 당신 시스템의 살아있는 표현으로 남는다. 새로운 Java 코드가 진화함에 따라 그래프도 갱신된다. 당신은 항상 최신 상태인 자동화된 문서를 얻는다. 당신은 아키텍처 드리프트 탐지를 얻는다 — 새 코드가 당신이 정의한 모듈성 규칙을 위반하면 시스템이 경고한다. 당신은 필요할 때마다 영향 분석을 얻는다: "이 메서드를 바꾸면 무엇이 깨지는가?"
현대화는 일회성 이벤트가 아니다. 그것은 라이프사이클이다. 그것을 — 시작일과 종료일이 있는 — 프로젝트로 취급하는 조직은 5년 후 새로운 세대의 기술 부채에 빠져 출발했던 자리로 되돌아가는 조직이다.
코드는 텍스트가 아니다
내가 계속 되돌아가는 교훈 — 그 화요일 밤 스택 트레이스를 응시하며 얻은 그 교훈 — 은 속을 만큼 단순하다: 코드는 텍스트가 아니며, 그것을 텍스트로 취급하는 도구는 옳아 보이지만 잘못 작동하는 결과를 낳을 것이다.
"AI 래퍼" 경제 전체는 범주 오류 위에 세워져 있다. 그것은 LLM이 언어 처리에 비범하므로 코드 처리에도 비범할 것이라고 가정한다. 하지만 코드는 언어가 아니다. 코드는 그래프다 — 여러 차원에서 동시에 존재하는, 종속성, 데이터 흐름, 상태 변화의 조밀하고 상호 연결된 시스템이다. 텍스트 기반 도구로 그것을 현대화하려는 것은 지도 없이 거리 이름 목록만 가지고 도시를 항해하려는 것과 같다. 당신은 "중간에서 길을 잃을" 것이다.
우리는 지도를 만들었다. 그리고 그것은 작동한다 — 우리가 파운데이션 모델을 만드는 팀들보다 더 똑똑해서가 아니라, 우리가 다른 질문을 던졌기 때문이다. 그들은 물었다: "어떻게 하면 AI가 텍스트를 더 잘 이해하게 만들까?" 우리는 물었다: "문제가 애초에 텍스트가 아니라면 어떨까?"
레거시 현대화의 미래는 더 큰 언어 모델이 아니다. 그것은 소프트웨어를 소프트웨어가 실제로 작동하는 방식 그대로 — 문자열이 아니라 구조로 — 이해하는 시스템이다.
그것이 우리가 Veriprajna에서 건 베팅이다. 매일 또 다른 조직이 자신들의 AI 생성 Java가 아름답게 컴파일되고 처참하게 실패한다는 것을 발견한다. 매일 문법적 번역과 의미론적 이해 사이의 간극은 무시하기에 더 비싸진다. 그 간극을 좁히는 조직은 자신들의 코드를 현대화하는 데 그치지 않을 것이다. 그들은 마침내 그것을 이해하게 될 것이다 — 그들 중 다수는 처음으로.