미션 수행 속도로 리팩토링하기: Red Hat AI 기반 '에이전트 메시' 접근법으로 실현하는 레거시 시스템 현대화

레거시 소프트웨어는 스스로 사라지지 않습니다. 레거시 소프트웨어는 프로덕션 환경에 남아 기술 부채를 축적하고 변화를 거부하며 서서히 리스크가 되어 갑니다. 이는 소프트웨어의 기능 때문이 아니라, 더 이상 지원할 수 없는 부분들 때문입니다.

이는 정부와 업계를 지원하는 선도적인 시스템 통합업체(SI)가 직면한 과제입니다. 미션 크리티컬 애플리케이션 포트폴리오 전반에서 SI와 항공우주 기업은 노후화된 Python 및 Java 코드베이스를 관리하고 있으며, 이를 현대적이고 보안 중심적이며 지원 가능한 기반인 Red Hat Enterprise Linux 10(RHEL 10)으로 전환해야 합니다.

목표는 단순한 소프트웨어 업그레이드가 아닙니다. 정부 데이터 센터, 전방 배치 미션 지역 또는 항공기 모바일 시스템이 의존하는 소프트웨어 제공 속도, AI 속도 및 보안 태세를 유지하는 것이 핵심입니다.

이것은 미국 연방정부에만 해당하는 이론적인 이야기가 아닙니다. 미국 General Services Administration(GSA)의 AI 거버넌스 프레임워크와 Department of War(DoW)는 이제 기관과 부서에 AI를 단순히 도입하는 것이 아니라 책임감 있는 AI를 운용화할 것을 요구하고 있습니다. 국방 및 미션 이해관계자에게 이 지침은 단순한 정책 점검 항목이 아닙니다. 이는 내부 에이전트에게 중요한 업무를 맡기기 전에 소프트웨어 팩토리를 제대로 구축하도록 하는 필수 기제입니다. 

최근 진행된 프로젝트에서 확정된 요구 사항 중 하나는 완전한 오프라인 호환성이었습니다. 국가 안보를 지원하는 환경은 설계상 인터넷 연결이 제한되는 경우가 많습니다. 외부 서비스(GitHub, 클라우드 API, 원격 패키지 레지스트리)에 대한 모든 의존성은 취약점이나 장애 지점이 될 수 있으며, 시스템의 규정 준수 상태를 근본적으로 훼손할 수 있습니다. 

수동으로 시스템을 현대화하는 작업은 기술적으로는 가능했지만, 엔지니어링 작업에 수년의 인력이 소요될 것으로 예상되어 대규모 환경에서 실행하기에는 무리가 있었습니다. 다른 대안은 아무런 조치도 취하지 않은 채 운영 리스크가 증가하는 노후화된 시스템을 계속 가동하는 것뿐이었습니다. 이에 따라 제 3의 길, 즉 에이전틱 자동화를 사용하여 엔지니어가 모든 단계를 수동으로 수행하는 대신 대규모 현대화 과정을 감독할 수 있는 더 효율적인 프로세스를 구축할 수 있는지 검토하게 되었습니다.

결과적으로 이는 가능했으며, 당사는 Red Hat AI와 Red Hat OpenShift AI를 사용하여 에이전틱 플랫폼을 구축했습니다.

대규모 레거시 현대화의 문제점

그린필드 기술 검증(POC)이 아닌 실제 프로덕션 코드를 이전하는 브라운필드 마이그레이션은 새로운 것을 구축하는 것과는 근본적으로 다릅니다. AI에게 프롬프트를 입력하는 것만으로는 작업을 완료할 수 없습니다.

레거시 코드베이스는 흔히 다음과 같은 특징을 가집니다.

• 아키텍처 노후화: 이전 시대의 엔지니어링 표준을 반영하는 가정, 프레임워크 및 인프라를 기반으로 설계된 시스템입니다.
• 제한적이거나 고르지 않은 테스트 범위: 코드베이스의 상당 부분은 자동화된 테스트가 표준으로 자리 잡기 전에 작성되었습니다.
• 암시적 동작 계약: 실제로는 존재하지만 공식적으로 문서화되거나 강제된 적이 없는 모듈과 서비스 간의 종속성입니다.
• 누적된 기술 부채: 점진적으로 프로덕션 시스템의 일부가 된 임시 해결책, 더 이상 사용되지 않는 라이브러리 및 호환성 수정 사항의 계층입니다.

국가 안보 임무에서 이를 잘못 처리할 경우 발생하는 위험은 결코 추상적이지 않습니다. 마이그레이션 실패는 단순히 애플리케이션을 중단시키는 데 그치지 않고, 워크플로우를 정지시키거나 임무를 지연시키며 국민을 보호하는 인프라에 보안 취약점을 초래할 수 있습니다.

이러한 환경에서는 클라우드 API를 통해 실행되는 대규모 범용 프론티어 모델을 선택지로 고려할 수 없습니다. 민감한 코드를 외부 엔드포인트로 전송할 수는 없습니다. 대규모 환경에서 예측할 수 없는 추론 동작을 용납할 수는 없습니다. 클라우드 프론티어 모델에 연결할 수 있다 하더라도, 요청이 방대한 파라미터 공간 전반에서 긴 추론 체인으로 확장될 때 발생하는 토큰 사용량과 컴퓨팅 오버헤드를 정당화하기는 어렵습니다. 수백만 줄의 코드가 포함된 시스템의 마이그레이션 규모에서는 이러한 요소가 레이턴시, 인프라 비용 그리고 운영 리스크 증가로 직결됩니다.

효율적인 소규모 모델이 적합한 도구인 이유

대부분의 AI 애플리케이션 환경에서는 사용 가능한 가장 큰 모델을 선택하려는 경향이 있습니다. 더 많은 파라미터, 더 넓은 컨텍스트, 더 나은 답변을 기대하기 때문입니다. 하지만 네트워크가 단절되고 미션 크리티컬하며 리소스가 제한된 환경에서는 이러한 논리가 빠르게 한계에 부딪힙니다. 대규모 프론티어 모델은 과도한 레이턴시, 예측할 수 없는 추론 루프 그리고 제어된 인프라에서 지원하기 어려운 막대한 GPU 메모리 요구 사항을 유발하는 경우가 많습니다.

소형 언어 모델(SLM)은 에이전틱 워크플로우에 매우 적합합니다. 이러한 시스템에는 단순히 모델의 규모뿐만 아니라 안정적이고 반복 가능한 실행과 낮은 레이턴시의 응답이 필요하기 때문입니다. 소규모 모델은 도구 호출, 오케스트레이션, 구조적 추론과 같은 자동화 태스크에 적합한 빠르고 결정론적인 동작을 구현할 수 있습니다. 또한 소규모 모델은 로컬에서 미세 조정하고 운영하기가 더 수월하여, 팀이 외부 엔드포인트에 의존하지 않고도 도메인별 에이전트 그룹을 배포할 수 있습니다. 즉, 모델이 하나의 도메인만 잘 "알고" 있는 경우에는 확률 분포가 더 명확해지며, 해당 모델은 동일한 답변을 더 일관되게 생성하는 경향을 보입니다.

그렇지만 테스트 결과에 따르면, 특히 대규모 소프트웨어 시스템을 이해해야 하는 코드 마이그레이션 태스크의 경우 모델 성능이 컨텍스트 길이 그리고 파라미터 수와 여전히 강한 상관관계를 보이는 것으로 나타났습니다. 초기 테스트에서 우수한 성능을 보인 모델은 Llama 4 변형 모델과 Claude 모델이었으며, 이는 주로 매우 큰 컨텍스트 창(>256K 토큰)과 강력한 추론 능력 덕분이었습니다. 반대로 Claude는 간단한 엔지니어링 태스크를 지나치게 복잡하게 처리하여 불필요하게 긴 추론 체인을 생성함으로써 토큰 사용량과 레이턴시를 증가시키는 경우가 있음을 발견했습니다. 대규모 마이그레이션 작업에서 이러한 동작은 빠르게 누적되어 상당한 컴퓨팅 비용을 초래합니다.

이러한 이유로 현재 Meta Maverick을 로컬에서 실행 중이며, 대규모 모델의 GPU 메모리 요구 사항을 고려하여 Mistral 모델을 사용한 병렬 테스트도 함께 진행하고 있습니다. 또한 성능은 우수하지만 현재 환경에서 가용한 컴퓨팅 자원의 한계에 가깝게 도달하는 Llama 4 Scout에 대해서도 재평가를 진행하고 있습니다.

실용적인 해결 방법으로, 소규모 모델을 활용하는 동시에 상황에 따라 발생하는 컨텍스트 제한을 완화할 수 있도록 워크플로우를 리팩토링하는 하이브리드 모델 전략을 구현했습니다.

에이전트 하네스를 위한 현재 모델 선정 결과:

• mistralai/Devstral-Small-2-24B-Instruct: 코딩 에이전트용으로 지정된 모델입니다. 256K 토큰 컨텍스트를 지원하며 코딩 벤치마크에서 강력한 성능을 발휘하고, 소프트웨어 분석 그리고 리팩토링 태스크에 최적화되어 있습니다.
• mistralai/Ministral-3-14B-Reasoning: 비코딩(non-coding) 에이전트용으로 지정된 모델입니다. 256K 토큰 컨텍스트를 지원하며 마이그레이션 워크플로우 전반에서 구조화된 추론, 종속성 분석 그리고 오케스트레이션에 효과적입니다.

시스템은 에이전트 모델 외에도 지식 인덱싱과 검색에 특수 모델을 사용합니다.

• gpt-oss-120B: 코드베이스의 전역 구조를 나타내는 GraphRAG 지식 그래프를 빌드할 때 이 모델을 사용합니다.
• intfloat/e5-mistral-7B-instruct: GraphRAG 인덱싱과 벡터 검색에 사용하는 임베딩 모델입니다.

이는 단순한 절충안이 아닌 목적을 고려한 선택이었습니다. 이 결정은 사용 가능한 컴퓨팅 환경을 기반으로 한 목적에 맞는 엔지니어링 결정이었습니다. 우리가 겪는 컨텍스트 제한은 아키텍처 자체의 제약이 아니라 GPU 용량에 의해 결정되는 요소입니다. 인프라가 확장됨에 따라 에이전트 하네스와 모델 선택 전략도 그에 따라 확장할 수 있습니다.

에이전트 메쉬 아키텍처: OpenShift AI 기반의 에이전틱 '하네스 중의 하네스(harness of harnesses)'

이 플랫폼의 핵심은 에이전틱 하네스입니다. 이는 마이그레이션 워크플로우의 특정 부분을 각각 담당하는 여러 전문 AI 에이전트를 조율하는 모듈식 오케스트레이션 프레임워크입니다. 이 하네스는 OpenShift AI에서 실행되며, vLLM을 활용하여 효율적이고 대기 시간이 짧은 모델 추론을 지원합니다. 시간이 지남에 따라 이러한 패턴은 에이전트 메쉬로 진화합니다. 이는 복잡한 현대화 프로그램 전반에서 여러 에이전틱 워크플로우가 상호 운용되고 태스크를 조율하며 상태를 공유할 수 있는 '하네스 중의 하네스' 아키텍처를 의미합니다.

현재 아키텍처가 수행하는 작업은 다음과 같습니다.

Devstral 기반의 코딩 에이전트는 레거시 Python 2 또는 Java 소스 코드를 분석하고, 지원이 중단된 API를 식별하며, 리팩토링된 코드를 생성하고, 변경 전에 원래 동작을 캡처하는 특성화 테스트를 수행합니다. 이러한 에이전트는 단순히 구문을 변환하는 데 그치지 않고, 동작 의도를 보존하도록 작동합니다.

Ministral 기반의 비코딩 에이전트는 종속성 매핑, 마이그레이션 계획, 진행 상황 추적을 비롯한 광범위한 워크플로우 전반에서 추론 태스크를 수행합니다. 결정적 오케스트레이션 로직이 실행 흐름을 제어하므로, 에이전트는 마이그레이션, 검증, 차단된 항목과 후속 작업을 중심으로 태스크를 조율합니다.

사용자 정의 추적 관리 에이전트는 GitLab과의 통합을 처리하며, 폐쇄형(disconnected) 환경을 위해 완전히 교체할 수 있습니다. 이 구성 요소는 블랙박스가 아닌 완전히 검사 가능한 코드이므로 조직에서 하네스를 기존 개발과 거버넌스 시스템에 통합할 수 있습니다.

하네스 자체는 모듈화와 교체 가능성을 고려하여 설계되었으며, 맞춤형 에이전트를 OpenCode와 같은 오픈소스 에이전트와 결합합니다. 조직에서 시스템의 블랙박스 여부를 묻는다면, 솔직히 답변이 간단하지는 않습니다. LLM 추론 계층은 다른 신경망과 마찬가지로 본질적으로 불투명하기 때문입니다. 그러나 오케스트레이션 로직, 에이전트 코드, 출력물, 의사 결정 추적은 완전히 추적, 감사, 검사가 가능합니다. 이는 DoW 보안과 보증 요구 사항에 따라 운영되는 조직에 매우 중요한 요소입니다.

OpenShift AI 내에서 추론 엔진 역할을 하는 vLLM은 핵심적인 지원 요소입니다. 효율적인 추론은 단순한 성능 최적화가 아닙니다. GPU 리소스가 제한된 환경에서 멀티 에이전트 워크플로우를 실질적으로 가능하게 하는 핵심 요소입니다. vLLM의 최적화된 서빙을 통해 플랫폼은 단일 태스크로 컴퓨팅 리소스를 고갈시키지 않고 마이그레이션 워크플로우에 필요한 반복적이고 다단계의 추론 루프를 처리할 수 있습니다.

테스트, 보안 검토, 문서 생성 또는 배포 검증과 같은 인접 태스크를 위한 추가 에이전틱 하네스가 등장함에 따라, 이러한 하네스는 더 광범위한 에이전트 메쉬를 통해 상호 연결되어 전체 현대화 파이프라인에서 조율된 자동화를 실현할 수 있습니다.

마이그레이션 워크플로우 Python 우선, Java 차례

이 서비스의 초기 단계는 Python 2에서 Python 3로의 마이그레이션을 목표로 하며, 이는 실제 인도물이자 프레임워크의 유효성을 검증하는 단계이기도 합니다. Python 2는 2020년에 수명 주기가 종료되었으며, 여전히 Python 2 기반으로 구동되는 시스템은 패치가 적용되지 않은 취약점에 노출된 채 업스트림 지원 없이 운영 중입니다. 정부 및 엔터프라이즈 시스템에 있어 이는 단순한 이론적 위험이 아닙니다.

테스트를 통해 검증된 Red Hat의 가설은 외부 종속성의 복잡도에 비례하여 마이그레이션 비용이 증가한다는 것입니다. 더 이상 지원되지 않는 타사 패키지와 밀접하게 결합된 애플리케이션을 깔끔하게 마이그레이션하려면 훨씬 더 많은 에이전트 반복 작업이 필요합니다. 이러한 점은 모델 설계의 근거가 되었습니다. 즉, 흐름당 에이전틱 하위 태스크를 줄이고 반복당 범위를 좁혔으며, 각 단계 사이에 보다 결정론적인 검증 단계를 도입했습니다.

30일 목표: 테스트 커버리지 80%, GitLab 종속성 불필요, Python 2 및 Python 3 버전 간의 기능적 동등성 검증.

그림 1: OpenShift AI 기반의 코딩 에이전트, 비코딩 에이전트 그리고 툴을 활용한 에이전틱 소프트웨어 팩토리 워크플로우.

이후 30/60/90일 로드맵은 Java 25로의 전환을 목표로 OpenJDK 및 Corretto 버전(7, 8, 11, 17, 21)을 대상으로 하는 Java 마이그레이션에 중점을 둡니다. 마이그레이션 경로는 타겟 환경이 RHEL 8인지 또는 RHEL 9/10인지에 따라 달라집니다. 이 기능은 마법의 버튼이나 모든 상황에 적용되는 만능 솔루션이 아님을 분명히 밝힙니다. 에이전틱 프레임워크는 시작점일 뿐입니다. 프레임워크 내의 각 에이전트는 마이그레이션 워크플로우의 특정 태스크를 위해 전용으로 구축되었으며, 바로 이러한 특징 덕분에 처음부터 다시 구축할 필요 없이 Java로 확장할 수 있습니다.

실제로 중요한 지표 측정: Brownfield KPI

많은 에이전틱 및 기존 소프트웨어 개발 KPI는 그린필드(greenfield) 개발을 기반으로 설계되었습니다. 이러한 지표는 사용자가 아키텍처를 파악하고 있고, 문서에 접근할 수 있으며, 새로운 것을 구축하고 있다고 가정합니다. 또한 개발 속도에 중점을 둡니다.

브라운필드 레거시 마이그레이션에서 정확성이 결여된 속도는 성공이 아닙니다. 이는 오히려 AI 속도로 기술 부채를 양산하는 결과를 초래합니다.

이번 프로젝트를 위해 정의한 KPI 프레임워크는 다음 세 가지 질문을 중심으로 계층화되어 있습니다.

정상적으로 작동하는가? 기능적 동등성 비율(Functional equivalence rate), 통합 테스트 통과율(Integration test pass rate), 변경 실패율(Change failure rate)로 평가합니다. 이들은 진행 여부를 결정하는 go/no-go 메트릭입니다. 리팩토링된 코드가 동일한 입력에 대해 원본과 동일한 출력을 생성하지 못한다면 다른 어떤 지표도 의미가 없습니다.

어떻게 작동하는지 이해하고 있는가? 개발자 수용률(Developer acceptance rate), 테스트 커버리지 증감(Test coverage delta), 마이그레이션 완료율(Migration completion rate)로 평가합니다. 코드가 실행된다고 해서 마이그레이션이 완료된 것은 아닙니다. 해당 코드를 담당할 개발자가 이를 읽고 신뢰하며 유지 관리할 수 있는 상태가 되어야 마이그레이션이 완료된 것으로 간주합니다.

팀이 장기적으로 운영 및 관리할 수 있는가? 개발자 신뢰도 점수(Developer confidence score), 첫 기여까지 걸리는 시간(Time-to-first-contribution), 개발자 생산성 향상(Developer capacity gain)으로 평가합니다. 궁극적인 투자수익률(ROI) 지표는 작업당 토큰 비용이 아닙니다. 중요한 것은 엔지니어링 팀이 반복적인 마이그레이션 작업에서 시간을 확보하여 더 가치 있는 미션 기여에 집중할 수 있도록 하는 것입니다.

속도 지표(처리량, 반복 대기 시간, 분당 에이전트 작업 등)는 시스템 최적화를 위한 엔지니어링 대시보드에 포함됩니다. 이러한 지표는 성공의 척도로서 프로그램 검토 단계에서 다뤄지지 않습니다.

Red Hat AI 및 OpenShift AI가 제공하는 가능성

이를 실제로 지원할 수 있는 플랫폼이 없다면 이 모든 과정이 제대로 작동할 수 없습니다. OpenShift AI는 여기에 설명된 모든 기능을 위한 기반 계층을 제공합니다.

• vLLM을 사용한 모델 서빙: 에이전트 하네스를 구동하는 코딩 및 추론 모델을 위해 효율적이고 확장 가능한 추론 기능을 제공합니다.
• 모델 사용자 정의 워크플로우: 리소스가 제한된 환경에서 실행해야 하는 모델을 위한 미세 조정(fine-tuning), LoRA 및 양자화를 지원합니다.
• 비연결 클러스터 지원: 이 플랫폼은 인터넷 연결이 불가능한 환경에서도 실행되도록 설계되었으며, 이는 이 분야의 필수 요구 사항입니다.
• 감사 로깅 및 관측성: 미션 이해관계자가 필요로 하는 추적 가능성과 설명 가능성이 별도 추가 방식이 아닌 플랫폼 자체에 내장되어 제공됩니다.
• 컨테이너화된 모듈식 아키텍처: 에이전트는 시스템 통합업체, 항공우주 기업, 연방 정부가 이미 사용 중인 기존 OpenShift 인프라를 통해 컨테이너화 및 교체가 가능하며 원활하게 배포할 수 있습니다.

그림 2:  Red Hat AI를 활용한 에이전트 구축 구성 요소 및 역량

RHEL 10을 대상 런타임 환경으로 추가한 것은 단순히 우연이 아닙니다. RHEL 10은 보안 강화, 최신 Python 및 Java에 대한 업데이트된 런타임 지원, 그리고 정부 시스템에 필요한 운영 안정성을 제공합니다. RHEL 10으로의 마이그레이션은 단순히 소프트웨어 라이프사이클에 따른 결정이 아니라, 보안 및 미션 준비 상태를 위한 전략적 결정입니다.

더 큰 관점에서의 패턴: 미션 영역 전반의 에이전트 메쉬

이러한 협력 사례는 국방 산업 기반, 연방 정부, 더 나아가 산업 전반에서 반복될 것으로 예상되는 전형적인 예시입니다. 기존의 레거시 소프트웨어 자산은 방대합니다. 이를 수동으로 마이그레이션하기 위한 엔지니어링 리소스는 문제 해결에 필요한 규모만큼 충분하지 않습니다. 또한 지원되지 않는 소프트웨어를 실행할 때 허용되는 보안 유예 기간이 끝나가고 있습니다.

OpenShift AI와 같은 플랫폼 기반의 에이전틱 AI는 숙련된 엔지니어링 팀이 미션 크리티컬 환경에서 요구되는 엄격함과 추적성을 보장하면서, 수동으로는 수년이 걸릴 코드베이스 마이그레이션을 아주 짧은 시간 안에 감독하고 완수할 수 있게 하는 역량 강화의 핵심 요소입니다.

이 모델에서 에이전틱 하네스는 전문화된 에이전트를 조정하여 개별적인 현대화 태스크를 수행합니다. 이러한 하네스가 인접 기능(예: 테스트, 보안 검토, 배포 검증)으로 확장됨에 따라 에이전트 메시(agent mesh), 즉 대규모 소프트웨어 자산 전반에서 복잡한 엔지니어링 워크플로우를 조정하는 '하네스 간의 하네스(harness-of-harnesses)' 아키텍처를 형성하기 시작합니다.

에이전트는 반복적인 작업을 수행합니다. 엔지니어는 아키텍처 설계, 감독, 에이전트 평가 및 예외 처리를 담당합니다. 이러한 분업 방식이 바로 이 모델의 핵심입니다.

소규모 모델. 효율적인 추론. 모듈식 에이전트. 오프라인 환경에서의 운영. 미션 지향적인 시스템 현대화. 이것이 우리가 지향하는 모델입니다.

맺음말

프론티어 모델은 탁월한 추론 엔진입니다. 목적에 맞게 구축된 에이전틱 플랫폼은 미션 수행을 위한 도구입니다.

정부 기관의 경우, 이것은 단순히 최신 AI 트렌드를 도입하는 문제가 아닙니다. 중요한 시스템의 보안과 현대성을 유지하고 미션 수행을 지원하는 데 필요한 인프라와 AI 역량을 확보하는 것이 핵심입니다.

Red Hat은 Red Hat AI를 통해 이를 실현하고 있습니다.

자세히 알아보기

• Red Hat AI
• Red Hat OpenShift AI