창고에서 시작된 빛

1993년 12월, 일본 도쿠시마현의 한 화학회사 연구소에서 푸른빛이 켜졌다. 니치아화학공업이라는 시골 중소기업의 연구원 나카무라 슈지가 세계 최초로 고휘도 청색 LED를 상용화하는 데 성공한 순간이었다. 그의 연구 공간은 공장 냄새가 진동하는 소나무숲 안의 가건물이었고, 변변한 장비 하나 없어 실험 기기를 직접 용접해서 만들어야 했다. 대기업들이 수백억 엔을 쏟아붓고도 해내지 못한 일을, 이 시골 엔지니어는 혼자서 해냈다.

LED는 빛의 삼원색인 빨강, 초록, 파랑으로 구성된 발광다이오드다. 빨간색 LED는 1962년에, 초록색 LED는 1970년대 초에 실용화되었지만, 파란색만은 수십 년간 난공불락의 영역이었다. 이유는 물리학에 있다. 파란빛은 빨간빛이나 초록빛보다 파장이 짧고 에너지가 높다. 이런 고에너지 광자를 방출하려면 밴드갭이 넓은 반도체 재료가 필요한데, 그 조건을 충족하는 질화갈륨(GaN)은 고품질 결정을 만들기가 극도로 어려웠다. 조금만 결정이 불균일해도 빛 대신 열로 에너지가 유출되어 효율이 폭락했고, LED 작동에 필수적인 p형 반도체로의 도핑 역시 난제였다. 적색과 녹색에 쓰이는 재료들은 이런 문제가 상대적으로 덜했기에 빠르게 실용화된 반면, 청색은 재료 자체가 다루기 힘든 물질이었던 것이다. 최초의 LED를 발명한 사람조차 “청색 LED는 불가능하므로, LED는 가전제품의 전원 표시등 정도로밖에 못 쓸 것”이라 자조했을 정도였다.

당시 학계와 산업계의 주류는 셀렌화아연(ZnSe) 계열 화합물에 집중하고 있었다. 나카무라는 거기서 벗어나 질화갈륨(GaN)이라는 비주류 재료를 선택했다. 결함이 많아 LED 소재로 부적합하다는 것이 정설이었지만, 그는 독자적인 결정 성장 기술을 개발하며 정면돌파했다. 회사의 상사들은 그에게 다른 업무를 지시했고, 회의에도 나오지 않는 그를 못마땅하게 여겼다. 그러나 창업자 오가와 노부오의 묵묵한 후원이 그의 방패가 되어주었다.

이 이야기에서 주목할 것은 청색 LED 그 자체가 아니다. 우리가 일상에서 마주하는 것은 파란 불빛이 아니라, 그 파란빛이 빨강·초록과 결합하여 만들어낸 LCD 모니터, OLED 스마트폰, 그리고 LED 조명이다. 백색 LED 램프는 형광등의 10배, 백열등의 100배에 달하는 수명을 가지며, 와트당 발광 효율은 백열등 대비 20배에 이른다. 블루 LED는 보이지 않는 기반 기술이었고, 우리 눈앞에 펼쳐진 것은 그 위에 세워진 거대한 산업 생태계였다. 나카무라는 2014년 이 공로로 아카사키 이사무, 아마노 히로시와 함께 노벨 물리학상을 수상했다. 노벨위원회는 이 발명을 “혁명적”이라 칭하며, “21세기는 LED 램프가 밝혀줄 것”이라고 선언했다.

지금 AI 코딩의 세계에서도 비슷한 구도가 펼쳐지고 있다. 모두가 새로운 서비스를 만드는 데 AI 코딩을 활용하는 것에만 주목한다. 그러나 정작 이 기술이 가장 큰 폭발력을 발휘할 영역은 따로 있다. 블루 LED가 디스플레이와 조명 혁명의 숨은 열쇠였듯, AI 코딩의 진짜 무대는 수십 년간 쌓여온 레거시 시스템의 모더나이제이션이다.

차세대 프로젝트라는 이름의 반복되는 실패

한국 IT 업계에서 ‘차세대 프로젝트’라는 단어만큼 희망과 좌절을 동시에 품은 용어도 드물다. 과거 IBM 메인프레임 위에 코볼로 구축된 금융 시스템을 유닉스 기반 오픈 시스템으로 전환하기 시작한 것이 벌써 20년이 넘었다. 그 사이 은행, 보험, 공공기관에서 수백억에서 수천억 원 규모의 차세대 프로젝트가 반복적으로 추진되었다. 그리고 그 상당수가 일정 지연, 예산 초과, 품질 미달이라는 삼중고에 시달렸다.

보스턴컨설팅그룹과 맥킨지의 연구에 따르면 디지털 전환 프로그램의 약 70%가 목표 달성에 실패한다. 이 숫자는 한국의 현실과도 정확히 일치한다. 국내 한 시중은행은 차세대 시스템 구축에 4년 6개월을 소요한 끝에 재사업까지 진행해야 했다. 한 대형 보험사의 차세대 사업은 착수 후 4년 이상의 긴 굴곡을 겪었다. 금융권뿐 아니라 공공기관의 대형 차세대 프로젝트에서도 유사한 난항이 반복되었다.

왜 이런 일이 반복되는 것일까. 구조적 원인은 명확하다. 첫째, 다단계 하청 구조다. 대형 SI 업체가 수주하면 자회사와 협력업체를 거쳐 실질적 개발자에게 도달하는 비용은 원래 금액의 30% 수준으로 쪼그라든다. 1000원어치의 수행 역량을 기대하면서 300원만 실제 개발자에게 전달되는 구조에서 품질을 기대하기는 어렵다. 둘째, 도메인 지식의 단절이다. 금융 현업을 모르는 IT 컨설턴트가 프로세스 분석도를 만들고, 그 분석도가 부실하다는 사실이 프로젝트 중반에야 드러난다. 그때부터 원청의 에이스 인력을 투입해 보완하지만, 이미 개발 일정은 극도로 압축되어 사람을 갈아 넣는 수순이 된다. 셋째, 핵심 인력의 부재다. 시스템 전체의 구조를 꿰뚫는 시니어 개발자는 이미 시장을 떠났거나 다른 곳으로 이동했다. 남은 것은 과거 시스템의 카피에 최신 기술의 옷을 입힌, 본질적으로는 달라지지 않은 시스템뿐이다.

그리고 이 셋째 문제는 시간이 갈수록 악화되고 있다. 20여 년 전 코볼에서 자바로 전환할 당시, 원래 시스템을 설계한 세대의 개발자들이 아직 현역이었다. 그들의 머릿속에는 시스템의 전체 지도가 있었고, 그 지도를 바탕으로 전환 작업을 지휘할 수 있었다. 그러나 지금은 상황이 다르다. 코볼 세대는 은퇴했거나 은퇴를 눈앞에 두고 있다. 자바로 전환된 시스템조차 이미 15년 이상 노후화되어 그 자체가 레거시가 되었지만, 이 자바 레거시의 전체 구조를 꿰뚫는 개발자마저 시장을 떠나고 있다. 코볼을 아는 사람이 사라지는 것이 문제가 아니다. 레거시 자바를 아는 사람이 사라지는 것이 진짜 문제다. 인력 절벽은 이미 시작되었다.

제안 당시에는 아주 밝은 미래가 그려진다. 선진화된 아키텍처, 최신 프레임워크, 클라우드 네이티브. 그러나 수백억 수천억을 들인 프로젝트에서 실제로 새로 작성된 코드가 전체의 상당 부분을 차지하는 경우는 드물다. 상당수는 과거 시스템의 이식이거나, 대충 맞춰 놓은 인터페이스에 불과하다. 20여 년 전 코볼에서 자바로의 전환이 만들어낸 레거시 위에, 다시 한 번 레거시의 레거시가 쌓이는 것이다. 차세대 프로젝트는 차세대가 되어서나 제대로 될 것이라는 자조 섞인 농담이 업계를 떠돈다.

그런데 여기서 질문을 바꿔보자. 이 반복되는 실패의 본질은 무엇인가. 기술의 한계인가, 사람의 한계인가. 나카무라가 블루 LED 개발에 착수했을 때, 대기업들은 이미 수백억 엔을 투자하고도 실패한 뒤였다. 문제는 돈이 아니었다. 접근 방식이었다. 주류가 선택한 셀렌화아연이라는 재료 자체에 한계가 있었고, 나카무라는 모두가 외면한 질화갈륨이라는 다른 길을 택했다. 차세대 프로젝트의 실패도 마찬가지다. 수천 명의 인력을 동원해 수작업으로 코드를 전환하는 방식 자체가, 셀렌화아연과 같은 한계를 내장한 접근법이었던 것이다.

코드의 대항해 — LLM은 어떻게 레거시를 읽는가

나카무라가 질화갈륨이라는 다른 길을 택했듯, 레거시 모더나이제이션에도 근본적으로 다른 접근법이 필요하다. 그 접근법의 이름은 AI 코딩이다. 그러나 여기서 한 가지 명확히 해야 할 것이 있다. AI 코딩을 레거시 모더나이제이션에 적용하는 것은 단순한 일이 아니며, 섣부른 적용은 기존 차세대 프로젝트의 실패를 AI라는 이름으로 반복하는 것에 불과하다.

가장 흔한 오류는 레거시 코드를 그대로 LLM에 넣고 “이것을 최신 언어로 변환해줘”라고 요청하는 방식이다. 이것은 코볼 코드를 한 줄씩 자바로 번역하던 과거의 차세대 프로젝트와 본질적으로 다르지 않다. 기계적 번역의 결과물은 원본과 똑같이 이해할 수 없는 코드다. 변수명은 여전히 의미 없는 약어이고, 비즈니스 로직은 조건문 수백 개가 중첩된 구조 속에 그대로 묻혀 있다. 언어만 바뀌었을 뿐 레거시는 그대로인 것이다. 셀렌화아연에 더 많은 돈을 투자해도 청색 LED가 나오지 않았듯, 레거시 코드를 그대로 LLM에 밀어 넣는 방식으로는 진정한 모더나이제이션이 이루어지지 않는다.

그렇다면 무엇이 달라야 하는가. LLM의 가장 근본적인 제약부터 직시해야 한다. 현재 최고 수준의 LLM이 제공하는 컨텍스트 윈도우는 100만 토큰 수준이다. 언뜻 거대해 보이지만, 대형 금융기관의 코어 시스템을 생각해 보면 이야기가 달라진다. 국내 주요 은행의 코어뱅킹 시스템은 통상 수십만에서 수백만 줄에 달하는 자바 코드로 이루어져 있고, 여기에 데이터베이스 스키마, 배치 처리 로직, 대외 연계 인터페이스까지 더하면 전체 코드베이스의 규모는 상상을 초월한다. 이 모든 것을 한꺼번에 LLM의 컨텍스트에 밀어 넣는 것은 물리적으로 불가능하다. 그리고 이 제약은 트랜스포머 아키텍처가 유지되는 한 본질적으로 해소되기 어렵다. 토큰 수가 늘어나더라도 무한대가 될 수는 없기 때문이다.

여기서 발상의 전환이 필요하다. 인간 개발자가 대규모 시스템을 다룰 때를 떠올려 보자. 수백만 줄의 코드를 모두 읽고 이해한 뒤에 작업에 들어가는 개발자는 없다. 머릿속에 시스템의 큰 그림이 있고, 그 큰 그림에서 점차 세밀한 영역으로 내려가며 특정 모듈을 수정한다. 전체를 동시에 보는 것이 아니라, 지도를 보고 필요한 곳으로 이동하는 것이다. AI 에이전트도 같은 방식으로 작동할 수 있다.

핵심은 방대한 코드베이스를 그대로 메모리에 적재하는 것이 아니라, 그 구조를 계층적 지도로 만드는 것이다. 구체적으로는 두 가지 기술이 결합된다.

첫째, 벡터 데이터베이스를 활용한 코드 맵이다. 시스템의 전체 구조, 모듈 간 의존 관계, 클래스 계층, API 호출 관계 등을 벡터로 임베딩하여 저장한다. 예를 들어 대출 심사 모듈을 현대화한다고 하자. AI 에이전트는 먼저 벡터 데이터베이스에서 “대출 심사”와 관련된 모듈을 검색한다. 그러면 대출 심사 모듈뿐 아니라, 이 모듈과 연결된 신용평가 인터페이스, 담보 관리 모듈, 한도 계산 로직, 감사 로그 시스템 등 연관된 컴포넌트들의 관계 지도가 나온다. LLM은 이 지도를 보고 자신이 건드리는 코드가 시스템 전체에서 어떤 위치에 있는지, 수정 시 어떤 모듈에 영향을 미치는지를 파악한다.

둘째, 마크다운 기반의 위키 형태 지식 트리다. 각 모듈의 비즈니스 로직, 데이터 흐름, 예외 처리 규칙 등 상세한 정보를 구조화된 문서로 정리한다. 25년 된 시스템에는 주석도 없고 명세서도 없는 경우가 대부분이다. 변수명은 약어로 가득하고, “왜 이 조건문이 여기에 있는지”는 퇴직한 개발자의 기억 속에만 남아 있다. 이런 암묵적 지식을 LLM이 코드를 분석하여 먼저 문서화하고, 그 문서를 트리 구조의 위키로 정리한다. 에이전트는 작업 중 필요할 때마다 이 위키를 참조하여 맥락을 확보한다.

이 두 가지가 결합되면, LLM의 컨텍스트 윈도우가 100만 토큰이든 1000만 토큰이든 상관없이, 사실상 무한한 크기의 코드베이스를 다룰 수 있게 된다. 마치 인간 개발자가 IDE에서 프로젝트 탐색기를 열고 필요한 파일로 이동하듯, AI 에이전트도 코드 맵을 탐색하며 작업하는 것이다. 전체를 한꺼번에 보여줄 필요가 없다. 메타 정보를 주입하고, 필요에 따라 상세 정보를 동적으로 불러오면 된다.

이런 접근법의 핵심은 AI가 코드의 표면이 아닌 의도를 읽는다는 점이다. 코드를 단순히 다른 언어로 기계적 번역하는 것이 아니라, LLM이 코드의 동작을 이해하고, 그 동작이 구현하는 비즈니스 규칙을 추출하며, 그 규칙을 현대적 패턴으로 재구성한다. 비즈니스 규칙을 먼저 추출한 뒤 그 규칙을 기반으로 새로운 코드를 생성하는 것이다. 코드 번역이 아니라 의미 재구성이다.

업계에서는 이미 이런 방향의 움직임이 시작되고 있다. 2026년 현재, 주요 AI 기업들은 레거시 코드 모더나이제이션을 핵심 엔터프라이즈 워크로드로 규정하고, 전용 도구와 파트너십을 잇달아 발표하고 있다. 코드 분석과 비즈니스 규칙 추출을 자동화하고, AI가 생성한 코드를 인간이 검증하는 협업 모델이 빠르게 자리 잡고 있다. 아직 수백만 줄 규모의 코어뱅킹 시스템을 통째로 모더나이제이션한 사례가 나온 것은 아니지만, 방향은 분명하다. 그리고 이 방향의 끝에서, 모더나이제이션은 일회성 프로젝트가 아니라 지속적인 프로세스로 진화할 것이다. AI 에이전트가 코드를 현대화한 뒤에도, 운영 과정에서 발생하는 사용자 피드백과 시스템 이상을 자동으로 감지하고, 코드 수정을 제안하며, 테스트와 배포까지 수행하는 자동 피드백 루프가 그 다음 단계다. 모더나이제이션이 끝나는 시점이 곧 지속적 개선이 시작되는 시점이 되는 것이다.

개발자라는 이름의 외과의

나카무라 슈지의 이야기로 돌아가 보자. 그가 청색 LED를 개발하겠다고 선언했을 때, 주변의 반응은 냉담했다. 대기업도 실패한 일을 시골 중소기업의 일개 연구원이 해내겠다는 것은 무모한 도전으로 보였다. 그에게는 최첨단 장비도 없었고, 대규모 연구팀도 없었다. 그에게 있었던 것은 문제를 바라보는 다른 시각과, 포기하지 않는 집요함이었다. 그는 회사의 명령을 무시하고 회의에도 참석하지 않으며 오직 실험에만 몰두했다. 주변에서 “실험의 신”이라 부를 정도로, 끊임없이 시도하고 실패하고 다시 시도했다. 그리고 마침내, 21세기에나 가능하다고 여겨지던 청색 LED를 1993년에 현실로 만들어냈다.

레거시 모더나이제이션에 도전하는 개발자에게 필요한 것도 이와 다르지 않다. 수십만 개의 파일이 얽힌 복잡한 시스템을 앞에 두고, 이것을 AI로 현대화하겠다고 선언하는 것은 지금 시점에서도 무모하게 들릴 수 있다. 컨텍스트 윈도우의 한계, 할루시네이션의 위험, 비즈니스 로직의 암묵적 복잡성. 장벽은 수없이 많다. 그러나 모두가 안 된다고 할 때 방법을 찾는 것이 개발자의 본질이다.

직접적인 통계를 구하기는 어렵지만, 상식적으로 생각해 봐도 세상에 존재하는 소프트웨어 중 새로 작성되는 코드보다 이미 운영 중인 레거시 코드가 압도적으로 많다. 은행, 보험, 통신, 제조, 공공 시스템의 심장부에는 10년, 20년, 때로는 30년 이상 된 코드가 여전히 돌아가고 있다. 이 코드들은 매일 수백만 건의 거래를 처리하고, 수천만 명의 시민 데이터를 관리하며, 국가 인프라의 근간을 이루고 있다. 이 시스템들을 문제없이 현대화하는 것은, 어쩌면 새로운 서비스를 만드는 것보다 훨씬 더 높은 수준의 역량을 요구하는 일이다.

의사가 수술로 사람의 생명을 살리듯, 개발자는 시스템을 수술한다. 차이가 있다면, 의사의 수술대 위에는 한 명의 환자가 있지만, 개발자의 수술대 위에는 수백만 명이 의존하는 시스템이 놓여 있다는 것이다. 금융 시스템의 코어가 멈추면 경제가 멈춘다. 공공 시스템이 오작동하면 시민의 삶이 흔들린다. 이 시스템들의 숨통을 틔우고, 과거의 영광을 되살리며, 다시 힘차게 뛰는 심장을 만들어주는 것. 그것이 개발자가 할 수 있는 가장 가치 있는 일이다.

AI 코딩은 이 수술에 투입되는 새로운 도구다. 과거에는 수천 명의 인력이 몇 년에 걸쳐 수행해야 했던 코드 분석, 의존성 파악, 비즈니스 로직 추출, 테스트 케이스 생성, 코드 변환 작업을 AI가 가속화한다. 그러나 도구가 아무리 날카로워도, 그 도구를 쥐는 손이 어디를 절개하고 어디를 봉합해야 하는지 알지 못한다면 수술은 실패한다. 벡터 데이터베이스로 코드 맵을 구축하고, 마크다운 위키로 지식 트리를 정리하며, 에이전트가 E2E(End-to-End)로 문제를 풀 수 있도록 파이프라인을 설계하는 것. 이 모든 것은 최신 트렌드와 과거의 기법을 총동원하여 시스템을 고쳐나가는 개발자의 역량에 달려 있다.

나카무라 슈지는 노벨상 수상 후 자신의 원동력이 무엇이었는지 묻는 질문에 “분노”라고 답했다. 회사의 상사들이 매번 “아직 퇴사하지 않았느냐”고 물을 때마다, 그 분노가 실험실로 향하는 발걸음을 멈추지 않게 했다고 말했다. 레거시 모더나이제이션에 도전하는 개발자에게도 비슷한 감정이 있을 것이다. 수십 년간 반복된 차세대 프로젝트의 실패를 바라보며, 수천억 원이 낭비되는 것을 지켜보며, 그리고 더 나은 방법이 분명히 있다는 확신을 품으며. 모두가 불가능하다고 말할 때, 바로 그 지점에서 돌파구를 찾는 사람이 나카무라였고, 바로 그런 개발자가 지금 필요하다.

블루 LED가 없었다면 우리는 아직도 브라운관 모니터 앞에서 일하고 있었을 것이다. 형광등의 깜박임 아래에서 생활했을 것이다. 지금 손에 들고 있는 스마트폰도 존재하지 않았을 것이다. 하나의 기반 기술이 열어젖힌 세계는 그토록 광대했다. AI 코딩이 레거시 모더나이제이션이라는 난제를 풀어낸다면, 그 파급력 역시 그에 못지않을 것이다. 수십 년간 기술 부채에 짓눌려 있던 시스템들이 현대화되고, 그 위에서 새로운 서비스들이 피어나며, 궁극적으로 그 시스템에 의존하는 수많은 사람들의 삶이 나아진다. 이 모든 것은 결국 사람을 위한 일이다. 그리고 이 수술을 해낼 수 있는 개발자를 찾지 못한다면, 우리는 영원히 레거시의 레거시를 반복하게 될 것이다.

참고 자료