✔️ Leveraging LLMs for Legacy Code Modernization: Challenges and Opportunities for LLM-Generated Documentation

논문 정보

제목	Leveraging LLMs for Legacy Code Modernization: Challenges and Opportunities for LLM-Generated Documentation
링크	https://arxiv.org/abs/2411.14971
인용수	9
발행일	2024년

 

I. 서론: 레거시 코드 현대화의 어려움과 LLM의 역할

1. 레거시 시스템의 문제점

레거시 시스템은 COBOL, MUMPS 또는 메인프레임 어셈블리와 같은 오래된 언어로 작성된 구식 컴퓨터 소프트웨어를 포함합니다. 이러한 시스템은 유지보수와 추가 개발을 어렵게 만듭니다.

미국 연방 정부의 경우, 레거시 시스템 중 상당 부분이 30년에서 60년 이상 되었으며, 이는 효율성, 유지보수, 인력 확보(staffing), 보안 측면에서 심각한 문제들을 야기합니다. 이러한 레거시 시스템의 현대화 작업은 수십 년간 지속되었지만, 여전히 해결하기 어려운 "난제(wicked problem)"로 남아있습니다.

 

2. LLM의 기대와 한계

코드 합성 및 번역에 대한 LLM 접근 방식의 출현으로, 인공지능이 소프트웨어 현대화의 효율성을 높이고 위험을 줄일 수 있을 것이라는 광범위한 낙관론이 존재합니다.

그러나 LLM의 코드 이해 능력이 레거시 언어에 충분히 성숙했는지 여부는 아직 불분명합니다. LLM은 깨끗한 코드와 주류 언어에서도 문서 생성, 코드 번역, 코드 합성 등 소프트웨어 이해 작업에서 많은 결함을 보여주었습니다. 특히 오류 허용 범위가 없는 중요 레거시 시스템의 경우, LLM 기반의 직접적인 코드 번역은 신뢰할 수 없습니다.

 

3. 문서화 생성의 중요성 (새로운 현대화 전략)

LLM 기반 코드 번역이 신뢰할 수 없는 경우에도, 문서화 생성(documentation generation) 또는 코드 요약은 강력한 현대화 전략으로 부상하고 있습니다. 자동으로 생성된 문서는 코드 이해를 촉진하여 번역, 리팩토링 및 유지보수를 용이하게 할 수 있습니다.

하지만 최근 발전된 문서화 생성 방법론들은 주로 C, Python, Java와 같은 주류 언어와 상대적으로 짧고 단순한 프로그램에 대해 훈련되고 평가되었습니다. 따라서 이러한 결과가 틈새 또는 구식 언어로 작성되었으며 극도의 복잡성을 보이는 레거시 소프트웨어에 유용하게 일반화될지 추론하기 어렵습니다.

 

4. 연구의 목표와 도전 과제

이 연구는 LLM 기반의 접근 방식을 사용하여 MUMPS 언어로 작성된 전자 건강 기록(EHR) 시스템과 IBM 메인프레임 어셈블리 언어 코드(ALC)로 작성된 오픈 소스 애플리케이션이라는 두 가지 실제 레거시 데이터셋에 대한 문서 생성 성능을 조사합니다.

이 연구는 두 가지 주요 즉각적인 과제에 직면합니다

1. 프롬프트 전략 부재: 줄 단위 코드 주석을 안정적으로 생성하기 위한 표준 프롬프트 전략이 없습니다. 기존의 단순 프롬프트 방식은 종종 불완전한 출력을 생성하거나 코드를 수정하는 원치 않는 작업을 수행했습니다.
2. 평가 메트릭 부재: 주석을 통한 코드 문서화의 품질을 측정하기 위해 널리 인정되는 평가 메트릭이 없습니다. 산업 적용을 위해 출력 품질을 검증하려면 수동적인 인간 전문가 평가가 필수적이지만, 이는 비용이 많이 듭니다. 따라서 대규모로 문서화 품질을 테스트하고 개발할 수 있는 자동화된 메트릭이 필요합니다.

이 연구는 이러한 문제를 해결하기 위해 주석 생성 및 평가 전략을 테스트하여, 주류 LLM이 레거시 코드 문서화를 지원하는 능력을 이해하기 위한 기준 결과를 제공하는 것을 목표로 합니다. 특히 다음 사항을 측정하고자 합니다:

• 새로운 프롬프트 전략과 인간 평가 루브릭의 성능을 평가합니다 (완결성, 가독성, 유용성, 환각 측정).
• 자동으로 계산 가능한 세 가지 유형의 메트릭(정적 코드 복잡도, LLM 런타임 비용, 참조 기반 메트릭)이 인간이 평가한 문서화 품질을 얼마나 잘 예측하거나 측정하는지 확인합니다.

제공해주신 자료의 섹션 II, 배경(BACKGROUND)은 레거시 소프트웨어가 야기하는 경제적 및 기술적 문제와 LLM 기반 해결책의 전망, 그리고 특히 기계 지원 문서화 생성 및 그 품질 평가 방법의 부족에 대해 심층적으로 다룹니다.

다음은 해당 섹션의 핵심 내용에 대한 해석 및 요약입니다.

II. 배경 (BACKGROUND)

A. 레거시 소프트웨어 (Legacy Software)

레거시 소프트웨어는 경제적, 기술적으로 독특하고 심각한 문제들을 제기합니다.

• 정부 기관의 어려움: 정부 기관들은 보안 위험을 완화하고 납세자들에게 더 효율적이며 영향력 있는 서비스를 제공하기 위해 노후된 IT 시스템을 비용 효율적이고 민첩한 시스템으로 마이그레이션해야 합니다.
• 현대화 이니셔티브의 실패: 수십 년 동안 IT 인프라를 전면 개편하려고 시도했음에도 불구하고, 미국 연방 정부 기관들은 IT 현대화 이니셔티브에서 뒤처지고 있으며, IT 예산의 거의 80%를 운영 및 유지보수에 지출하고 있습니다 (민간 부문의 약 절반과 비교됨).
• 문서화 부족: 정부 회계 감사원(GAO)에 따르면, 현대화가 가장 시급했던 10개의 핵심 연방 IT 레거시 시스템 중 8개는 현대화를 위한 문서화된 계획이 없거나 불완전한 계획을 가지고 있었습니다.
• 시스템의 중요성 및 위험성: 이러한 레거시 시스템은 전시 대비, 댐 및 발전소 운영과 같은 중요한 임무를 지원하며, 민감한 납세자 및 학생 데이터를 호스팅합니다. 최근 미국 연방 항공국(FAA) 시스템 장애로 인해 1,300편의 항공편이 취소되고 10,000편 이상이 지연된 사례는 이러한 레거시 시스템의 치명적인 중요성을 부각합니다.
• 전통적인 현대화 방식의 어려움: 레거시 코드를 검증된 현대적 아날로그로 변환하는 전통적인 방식은 개발 비용이 많이 드는 복잡한 규칙 및 패턴 매칭 접근 방식을 포함합니다. 파서, 컴파일러 등 변환 프로젝트를 시작하는 데 필요한 도구만 개발하는 데에도 수년이 걸릴 수 있습니다. 일부 규칙 기반 변환 도구는 기능적 정확성에 대한 공식적인 보장을 제공하지만, 일반적으로 매우 좁은 사례와 도메인 특정 애플리케이션에만 적용 가능합니다.
• 문서화의 중요성: 레거시 시스템을 현대화하는 과정에서 문서화 부족은 번역된 코드의 유효성을 판단하기 어렵게 만드는 주요 과제입니다. 레거시 코드를 수동으로 번역하는 것은 시간이 많이 소요되고 오류가 발생하기 쉽습니다. 따라서 레거시 시스템의 현대화에는 문서화가 필수적입니다.

B. LLM 기반 코드 이해 (LLM-Based Code Understanding)

LLM은 주류 언어에서도 코드 번역 및 합성 작업에서 상당한 한계를 보여줍니다.

• 오류 발생률: LLM 기반 모델은 코드 관련 작업에서 간단한 버그와 부정확한 정보를 높은 비율로 도입하는 것으로 나타났습니다.
• 번역 신뢰도: 1,700개의 오픈 소스 코드 예제를 대상으로 한 최근 평가에서는, C, C++, Go, Java, Python 간의 LLM 번역이 단위 테스트를 통과한 코드를 생성한 비율이 최고 47.3%, 최저 2.1%에 불과했습니다.
• 인간 검토의 한계: 인간 검토자들조차도 이러한 오류의 상당 부분을 감지하지 못할 수 있습니다.
• 학습 데이터 편향: LLM의 코드 합성 성능은 작업이 과거 학습 데이터에서 벗어날 때 급격히 떨어지는데, 이는 희귀한 언어와 비정상적인 코딩 패턴을 포함하는 레거시 시스템의 맥락에서 특히 우려스러운 부분입니다.
• 연구 격차: 레거시 언어에 대한 LLM 기반 코드 이해를 평가하는 연구는 아직 초기 단계에 있으며 상당한 문헌적 격차가 존재합니다.

C. 문서화 생성 (Documentation Generation)

레거시 시스템 현대화의 유효성을 보장하려면 기존 코드에 대한 확고한 이해가 필요합니다. 전문가가 부재할 경우, 적절한 문서화가 기존 기능에 대한 통찰력을 제공합니다. 따라서 문서 생성은 소프트웨어 현대화의 중요한 하위 작업입니다.

• LLM의 유용성: LLM을 사용한 직접적인 코드 번역 또는 생성은 한계가 있지만, LLM의 코드 이해 능력은 복잡한 현대화 프로젝트를 수행하는 개발자에게 여전히 유용할 수 있으며, 문서화 생성이 그러한 작업 중 하나입니다. 문서화 생성은 인라인 주석, 상위 수준 주석 블록, 그리고 소스 코드로부터 요약을 생성하는 것을 포함합니다.
• 전통적인 방법: 수동 템플릿 기반 방법 및 정보 검색 기반 방법은 Java와 같은 고급 언어에 대해 자동 생성의 일정 수준을 달성할 수 있지만, 변수 이름, 객체 지향 구조, 그리고 대규모 코드 데이터베이스(예: GitHub)에 크게 의존합니다.
• 신경망 방법: 최근에는 LSTM, 심층 강화 학습, 그래프 신경망을 기반으로 하는 다양한 신경망 접근 방식이 개발되었습니다. 일부는 문서 생성을 기계 번역 문제로 다루지만, 다른 접근 방식은 추상 구문 트리(AST) 표현을 활용하여 명시적인 구문 정보를 통합합니다.
• 파운데이션 모델 (Foundation Models): 재사용 가능한 파운데이션 모델의 등장은 문서화 생성 문헌에서 세 번째 주요 방법론적 변화를 가져왔습니다.
• LLM 성능: LLM은 개발자가 작성한 원본 문서화와 비슷하거나 더 나은 품질의 문서를 생성하는 것으로 밝혀졌습니다. 특히 LLM이 생성한 함수 수준 코드 설명은 학생들의 설명보다 더 이해하기 쉽고 정확하다는 평가를 받았습니다. 이는 LLM이 비전문가에게 유익한 코드 문서를 만들 수 있음을 의미합니다.
• 연구 격차 해소: 그러나 기존 연구들은 주로 간단한 함수와 현대적인 언어(예: JavaScript, Java, PHP, Python)에 대한 LLM 성능을 평가했습니다. 본 연구는 이러한 연구 격차를 해소하기 위해 레거시 언어(MUMPS 및 ALC)로 작성된 실제의 복잡한 코드에 대한 문서 생성에 중점을 둡니다.

D. 문서화 평가 (Evaluating Documentation)

문서화 품질을 평가하는 것은 어렵고 다차원적인 문제이며, 대규모 데이터셋으로 확장 가능하도록 자동화하는 것은 특히 어렵다는 것이 입증되었습니다.

• 현재의 평가 방법: 연구자들은 주로 수동적인 인간 평가에 의존하며, 이는 저자마다 달라지는 임시적인 루브릭(ad-hoc rubrics)을 사용합니다. 때로는 ROUGE-N 또는 BLEU와 같은 참조 기반 메트릭과 결합하여 사용되지만, 이러한 참조 기반 메트릭은 인간 평가와 상관관계가 낮다는 것이 밝혀졌습니다.
• 자동 평가의 필요성: 문서화 품질을 평가하는 확립된 방법론이 없으며, 산업적 적용을 위해서는 LLM 생성 문서의 품질을 대규모로 테스트하고 개발할 수 있는 더 나은 자동화된 메트릭이 필요합니다.

제공해주신 자료의 섹션 III, 방법(METHODS)은 레거시 코드에 대한 대규모 언어 모델(LLM) 기반 주석 생성을 위해 연구진이 채택한 구체적인 방법론과 데이터셋, 그리고 생성된 주석의 품질을 평가하기 위한 평가 루브릭 및 자동화된 메트릭에 대해 설명합니다.

다음은 해당 섹션의 핵심 내용에 대한 해석 및 요약입니다.

III. 방법 (METHODS)

연구는 네 가지 LLM을 사용하여 데이터셋의 각 코드 라인에 대한 주석을 생성하고, 이후 인간 전문가들이 생성된 주석과 원본 주석을 품질 측면에서 검토하는 방식으로 진행되었습니다. 방법론은 주석 생성 전략과 평가 접근 방식이라는 두 가지 주요 영역에 중점을 둡니다.

 

A. 모델 및 생성 방법 (Models and Generation Method)

연구진은 LLM 기반 코드 현대화를 위한 오픈 소스 프레임워크인 Janus를 사용하여 라인 단위 주석 생성 방법을 구현했습니다. 라인 단위 주석은 레거시 시스템, 특히 IBM Z-시리즈 메인프레임에 구현된 레거시 시스템을 유지보수한 주제 전문가(SMEs)의 경험에 따라 저수준 로직의 모호성을 완화하는 데 중요하다고 판단되었습니다.

 

1. 청킹 전략 (Chunking strategy)

코드베이스를 LLM의 컨텍스트 창에 맞게 조각(청크)으로 분할하는 것이 출력 품질에 영향을 미칠 수 있습니다. 연구진은 탐욕적 청킹 알고리즘(greedy chunking algorithm)을 채택하여 논리적 구조 분할을 최소화하면서 가능한 한 많은 코드를 컨텍스트 창에 채웠습니다. 이 알고리즘은 각 서브루틴을 청크로 만들고, 청크 크기가 모델 컨텍스트 창의 절반(나머지 절반은 생성된 출력용)을 초과하지 않는 한 가장 작은 청크를 이웃 청크와 재귀적으로 병합합니다. 그 결과, 모델의 컨텍스트 창 크기에 따라 모델이 받는 입력 크기가 달라집니다.

 

2. 프롬프트 템플릿 (Prompt Template)

초기 실험에서 단순한 프롬프트 전략(LLM에게 모든 라인에 주석을 추가하도록 요청하는 것)은 LLM이 코드를 변경하거나 불완전한 출력을 생성하는 문제로 인해 비효율적인 것으로 나타났습니다. 특히 MUMPS는 한 줄에 여러 개의 논리적 구문이 포함되는 경우가 많았는데, LLM은 이를 여러 줄로 다시 작성하고 새로운 줄마다 주석을 생성하는 문제가 발생했습니다.

이 문제를 해결하기 위해 연구진은 새로운 프롬프트 전략을 고안했습니다

• 플레이스홀더 대체: 파일 내의 모든 인간이 작성한(그라운드 트루스) 주석을 고유 식별자(placeholder)로 대체했습니다 (예: <BLOCK_COMMENT [id]>, <INLINE_COMMENT [id]>).
• JSON 구조화 출력: LLM에게 각 ID와 연결된 주석을 JSON 형식의 구조화된 출력으로 생성하도록 요청했습니다.

이 전략은 LLM이 코드를 변경하는 것을 막고(코드 수정 방지), 고유 식별자를 사용하여 LLM의 환각(hallucination)을 줄이며, 구조화된 출력 요청을 통해 LLM이 입력과 지침을 넘어 임의로 작업할 가능성을 줄이고 후속 프로세스와의 통합을 간소화하는 이점을 제공했습니다.

 

3. 모델 및 매개변수 (Models & Parameters)

인간 평가에 필요한 시간 때문에 실험은 Claude 3.0 Sonnet, Llama 3, Mixtral, GPT-4의 네 가지 모델에 초점을 맞추었습니다. 비교의 일관성을 위해 모든 모델에 대해 온도(temperature) 값 0.7이 사용되었습니다.

모델이 입력의 모든 플레이스홀더에 대한 주석을 생성하지 못하는 경우(불완전한 출력), 모든 플레이스홀더에 대해 주석이 생성될 때까지 모델을 여러 번 실행(retries)했습니다. 이 재시도(retries)는 모델의 비용 및 실행 시간 측정에 포함되었습니다.

 

B. 데이터셋 (Datasets)

레거시 언어에는 현실적인 복잡성을 가진 벤치마크 데이터셋이 부족하기 때문에, 연구진은 실제 레거시 시스템을 대표하는 두 가지 데이터셋을 생성했습니다.

1. MUMPS 코퍼스

• 출처: WorldVistA의 MUMPS 구현인 VistA, 특히 미완료 기록 추적(Incomplete Records Tracking) 모듈을 사용했습니다.
• 특징: VistA는 재향군인 건강 관리국(VHA)의 EHR(전자 건강 기록) 시스템 모듈입니다. 미완료 기록 추적 모듈은 78개의 파일, 총 5,107 라인의 코드와 235개의 개발자 주석을 포함하며, 오래된 MUMPS 코드와 최신 MUMPS 코드에서 발견되는 많은 관례와 스타일을 대표하는 것으로 간주되었습니다.

2. ALC 코퍼스

• 출처: 오픈 소스 Walmart 코드베이스의 zFAM 리포지토리를 사용했습니다.
• 특징: zFAM은 z/OS 기반 파일 액세스 관리자이며, 13,344 라인의 코드와 7,097개의 개발자 주석을 포함하며, 실제 ALC 코드베이스의 복잡성과 프로그램 크기 특성을 가지고 있어 대표적인 샘플로 선정되었습니다.

C. 프롬프트 전략 평가 (Evaluating the Prompting Strategy)

LLM이 생성한 주석의 품질을 측정하고 예측하기 위해 다양한 메트릭이 사용되었습니다. 인간 평가 점수는 그라운드 트루스 주석 품질의 대용치로 간주되었습니다.

 

1. 인간 평가 (Human Evaluation):

• 평가자: MUMPS 코퍼스에는 4명의 의료 IT 배경을 가진 전문가(총 16년 이상의 MUMPS 경험)가 참여했습니다. ALC 코퍼스에는 IBM Z-시리즈 메인프레임 및 레거시 코드 경험이 있는 5명의 전문가(일부는 수십 년 경력)가 참여했습니다.
• 루브릭: 이 전문가들(SMEs)은 환각(hallucination), 완결성(completeness), 가독성(readability), 유용성(usefulness)의 네 가지 범주에 걸쳐 4점 척도로 LLM의 출력을 평가하는 루브릭(표 II 참조)을 사용했습니다.
• 평가 데이터: MUMPS 데이터셋에서는 177개의 고유 원본 주석과 742개의 고유 LLM 생성 주석에 대해 총 3,093회의 평가가 이루어졌습니다. ALC 데이터셋에서는 127개의 원본 주석과 544개의 LLM 생성 주석에 대해 총 2,268회의 평가가 이루어졌습니다.

2. 코드 복잡도 정량화 (Quantifying Code Complexity):

• 공통 메트릭: 코드 복잡도를 정량화하기 위해 순환 복잡도(Cyclomatic Complexity), 할스테드 복잡도 측정(Halstead complexity measures), 그리고 복잡도에 반비례하는 유지보수 지수(Maintainability Index)와 같은 일반적인 복잡도 메트릭이 사용되었습니다.
• MUMPS 고유 메트릭 (Pain Points): MUMPS 데이터셋의 복잡성을 나타내기 위해 '페인 포인트(Pain Points)'의 유병률을 추가로 사용했습니다. 페인 포인트는 코드 이해나 흐름 파악을 어렵게 만드는 언어적 특징(예: 간접 참조(indirection), kill/goto, 간결한 라인, 지역 변수 등)을 의미하며, 이는 맞춤형 파서로 측정되었습니다.

3. 생성된 주석의 품질 평가 (Assessing Quality of Generated Comments):

LLM 생성 주석의 품질을 측정하기 위해 두 가지 유형의 자동화된 품질 메트릭이 사용되었습니다:

• 참조 기반 메트릭 (Reference-based Metrics): LLM 출력과 인간이 작성한 원본 주석(참조 텍스트) 간의 유사성을 계산합니다. ROUGE, CHRF, BLEU 및 코사인 유사도 점수가 사용되었습니다. 코사인 유사도를 위해 OpenAI의 임베딩 모델(text-embedding-3-small)을 사용하여 텍스트를 1,536차원 벡터로 변환했습니다.
• 가독성 메트릭 (Readability Metrics): 생성된 주석이 현대화 노력을 효과적으로 지원하기 위해 가독성이 있는지 측정하기 위해 Flesch Reading Ease 및 Gunning-Fog 메트릭이 사용되었습니다.

4. 주석 생성 비용 계산 (Calculating Cost of Comment Generation):

LLM 활용의 핵심 요소인 시간 및 금전적 비용을 파악하기 위해, 생성 작업 수행 중 금전적 비용, 재시도 횟수, 처리 시간, 실패한 생성 횟수 등의 비용 메트릭이 캡처되었습니다.

 

D. 가설 (Hypotheses)

연구진은 LLM 생성 문서화 품질을 자동화된 메트릭으로 정확하게 측정할 수 있는지 확인하기 위해 세 가지 가설을 설정했습니다:

• 가설 1: 레거시 소프트웨어에 대해 LLM이 생성한 주석은 환각이 없고, 완결성이 높고, 가독성이 있으며, 유용하다고 인간 평가자들에게 평가될 것이다. 이는 다음 두 가지 기준을 충족해야 합니다.
  • a) 인간이 작성한 주석과 비교하여 유사하거나 더 높은 품질
  • b) 평균적으로 10점 만점에 7점 이상의 높은 절대 점수.
• 가설 2: 소프트웨어 복잡도 및 주석 생성 비용에 대한 자동화된 측정 항목은 생성된 문서화 품질에 대한 인간 평가와 잘 상관되지 않을 것이다.
• 가설 3: 가독성 수준, CHRF, BLEU, ROUGE와 같은 생성된 문서화에 대한 자동화된 및 참조 기반 품질 메트릭은 문서화 품질에 대한 인간 평가와 강한 상관관계를 보이지 않을 것이다.

제공해주신 자료의 섹션 IV, 결과(RESULTS)는 연구에서 설정한 가설을 검증하기 위해 수행된 인간 평가 결과와 자동화된 복잡도 및 비용 메트릭, 그리고 품질 메트릭의 상관관계 분석 결과를 제시합니다.

다음은 해당 섹션의 핵심 내용에 대한 해석 및 요약입니다.

IV. 결과 (RESULTS)

A. 주석에 대한 인간 평가 (Human Evaluation of Comments)

1. 평가자 간 신뢰도 (Inter-rater Reliability)

• MUMPS 데이터셋: 인간 평가자들 사이에서 중간에서 양호한 수준의 평가자 간 신뢰도(ICC: Intraclass Correlation)가 관찰되었습니다. ICC 값은 환각(0.73), 가독성(0.65), 완결성(0.89), 유용성(0.85)에서 나타났습니다.
• ALC 데이터셋: 반면, ALC 데이터셋에서는 나쁜 수준의 평가자 간 신뢰도가 관찰되었습니다. 이는 현대화의 어려움을 강조하며, 즉 주석 품질을 측정하는 것이 어렵고, 심지어 경험이 풍부한 전문가들(SMEs)조차도 유용하고 읽기 쉬운 주석이 무엇인지에 대해 의견 차이를 가질 수 있음을 시사합니다.

2. LLM 생성 주석 품질

• MUMPS 데이터셋: LLM이 생성한 주석은 ALC용 주석보다 상당히 높은 평균 점수를 받았습니다. LLM이 생성한 주석은 원본(인간 작성) 주석(그라운드 트루스)과 비교하여 상대적으로 긍정적인 평가를 받았습니다.
  • 가독성: 모든 모델이 MUMPS에서 가독성 측면에서 그라운드 트루스보다 눈에 띄게 더 나은 성능을 보였습니다. 이는 실제 인간이 작성한 주석이 종종 부족하고 불분명하다는 점을 고려할 때 놀라운 결과는 아닐 수 있습니다.
  • 절대 점수: 절대 점수 측면에서, LLM은 MUMPS에 대해 높은 점수(10점 만점에 8점 이상)를 달성하여 읽기 쉽고 환각 없는 문서화를 생성했습니다. 완전성(Completeness) 측면에서도 Claude와 GPT-4 Turbo는 7점 이상을 달성하며 적절한 성능을 보였습니다. 그러나 유용성(Usefulness) 평가는 Claude Sonnet만이 10점 만점에 7점 이상을 달성했습니다.
• ALC 데이터셋: ALC 데이터셋에서는 전반적으로 LLM 생성 주석의 품질이 낮게 평가되었습니다. 오직 가독성 측면에서만 Llama3와 GPT-4 Turbo가 7점/10점 이상의 점수를 받았습니다.
• 환각 (Hallucination): LLM이 사실적으로 부정확한 주석을 생성하는 경향이 측정되었지만, GPT-4 Turbo는 MUMPS 코드에 대해 10점 만점에 9.1점이라는 높은 사실성(factualness) 평균 점수를 달성했습니다.

3. 가설 1 검증

• 가설 1(a) (인간 작성 주석과의 비교): 실험에 사용된 네 가지 LLM 모두에 대해 ALC와 MUMPS 모두에서 가설 1(a)가 확인되었습니다. LLM이 생성한 주석은 인간이 작성한 주석과 비교했을 때 환각이 없고, 완결성이 높고, 가독성이 있으며, (일부 예외를 제외하고) 비슷하게 유용하다는 평가를 받았습니다.
• 가설 1(b) (높은 절대 점수): 가설 1(b)는 MUMPS에 대해서만 확인되었고, ALC에 대해서는 확인되지 않았습니다. 절대 점수 기준으로 볼 때, ALC에 대한 LLM 생성 주석은 거의 모든 면에서 낮은 평가를 받았습니다.
• 성능 격차의 원인: 이러한 성능 격차는 ALC 언어의 복잡성 때문일 수 있으며, SMEs가 고품질 ALC 주석의 정의에 대해 어려움을 겪었다는 사실로 더욱 악화됩니다. ALC는 현대 프로그래밍 언어 구성과 구조적, 구문적으로 크게 다르지만, MUMPS는 현대 언어 구성과 더 유사한 정렬을 보입니다.

4. 컨텍스트 창 크기와의 관계

모델의 컨텍스트 창 크기와 성능 사이에는 관계가 관찰되지 않았습니다. 연구진은 컨텍스트가 전체 서브루틴 및 모듈에 대한 코드 요약과 같은 더 높은 수준의 소프트웨어 문서화에서 더 중요한 역할을 할 것으로 예상합니다.

B. 복잡도 및 비용 메트릭 (Complexity and Cost Metrics)

LLM 기반 주석 생성 기술을 새로운 실제 애플리케이션에 적용하기 위해서는 자동화된 메트릭의 도움이 필수적입니다. 그러나 연구 결과는 자동화된 복잡도 및 비용 메트릭이 주석 품질에 대한 인간 평가와 낮은 상관관계를 보인다는 것을 시사합니다.

• 낮은 상관관계: 제시된 다양한 복잡도 및 비용 메트릭은 환각, 완결성, 가독성 또는 유용성에 대한 인간 평가와 통계적으로 유의미한(p < 0.05) 상관관계를 거의 보이지 않았습니다.
• 유일한 유의미한 상관관계: 유의미한 상관관계의 절댓값은 모두 0.25 미만이었습니다. 유일하게 주목할 만한 상관관계는 처리 시간과 유용성 사이의 역상관관계(-0.33)였습니다. 이는 LLM이 주석 생성에 더 많은 시간을 할애할수록 주석의 유용성이 떨어지는 경향이 있음을 시사합니다 (약한 상관관계이지만).
• 가설 2 검증: 정적 복잡도와 런타임 비용 모두에 대한 자동화된 메트릭이 LLM이 생성한 주석 품질에 대한 인간 평가와 낮은 상관관계를 보였으므로, 가설 2는 ALC와 MUMPS 모두에서 확인되었습니다. 이러한 낮은 상관관계는 ALC에서 관찰된 SME 의견의 가변성뿐만 아니라, 레거시 어셈블리 명령어를 인간에게 유용하게 요약하는 데 내재된 어려움을 반영할 수 있습니다.

C. 품질 메트릭 (Quality Metrics)

자동화된 품질 메트릭(예: 가독성)과 참조 기반 메트릭(예: BLEU, ROUGE)은 인간 평가 품질과 잘 상관되지 않는 것으로 나타났습니다.

• 낮은 상관관계: 통계적으로 유의미한 상관관계 중 0.25보다 큰 Pearson 상관계수를 달성한 것은 소수에 불과했습니다.
• 가장 높은 상관관계: 가장 높은 상관관계는 코사인 유사도 점수와 유용성 사이였으며, 상관계수는 0.34에 불과했습니다. 이 유사성 메트릭이 네 가지 인간 평가 범주에서 가장 강력한 성능을 보여 향후 참조 기반 품질 메트릭으로서 가장 흥미로운 전망을 제시합니다.
• 가독성 메트릭: Flesch 및 Gunning-Fog 가독성 측정 기준으로 복잡도가 높은 주석은 완결성이 약간 더 높은 경향이 있었지만(0.17 및 0.20), 환각도 유사하게 증가하는 경향을 보였습니다(0.24 및 0.26).
• 가설 3 검증: 이러한 모든 상관관계의 규모가 작기 때문에, 자동화된 및 참조 기반 품질 메트릭은 주석의 실제 품질(인간 전문가가 평가한)을 예측하는 데 부족함을 보였으므로, 가설 3은 ALC와 MUMPS 모두에서 확인되었습니다.

 

제공해주신 자료의 **섹션 V, 논의 및 결론(DISCUSSION AND CONCLUSION)**은 레거시 코드 현대화에서 LLM 활용의 실질적인 의미와 한계를 종합하고, 향후 연구 방향을 제시합니다.

다음은 해당 섹션의 핵심 내용에 대한 해석 및 요약입니다.

V. 논의 및 결론 (DISCUSSION)

A. 레거시 현대화의 어려움과 LLM의 잠재력

레거시 코드 현대화는 모든 조직이 성공적으로 수행하기 매우 어려운 작업이며, 예산을 맞추기 힘든 것으로 악명이 높습니다. LLM 기반 소프트웨어 이해에 대한 연구가 증가함에 따라, 향후 몇 년 동안 현대화를 가속화할 수 있는 빠른 진전이 기대됩니다.

이 연구는 문서화 생성, 특히 라인 단위 주석 생성이 광범위한 현대화 라이프사이클(번역, 리팩토링, 재작성, 재배포 등)에서 작은 역할을 담당하고 있음을 인식합니다. 조직과 개발자는 자동화된 문서화와 같은 생성형 LLM 구성 요소를 포함하는 현대화 워크플로우에 신뢰와 자원을 투자할지 여부를 결정하기 위해 증거가 필요합니다.

1. 연구 결과의 낙관적 해석:

• 문서화 품질: MUMPS와 메인프레임 어셈블리와 같은 오래되고 틈새 시장 언어는 LLM 훈련을 위한 공개 데이터가 상대적으로 적음에도 불구하고, LLM은 인간 개발자가 작성한 주석과 비슷한 품질의 주석을 생성할 수 있음을 발견했습니다 (가설 1(a) 확인).
• 언어별 성능 차이: LLM의 MUMPS 주석 생성은 전반적으로 잘 수행되었지만, ALC용 주석 작성은 인간과 기계 모두에게 어려운 일임이 밝혀졌습니다 (가설 1(b)에 따라 ALC에서는 높은 절대 점수 달성 실패). 이러한 성능 차이는 ALC의 구조와 흐름이 현대 언어와 크게 다르지만, MUMPS는 현대 언어 구성과 더 유사한 구조적 정렬을 보이기 때문일 수 있습니다.

2. 자동화된 평가 메트릭의 한계:

• 코드 복잡도 및 비용 메트릭: 완전히 자동으로 측정할 수 있는 코드 복잡도 메트릭이나 LLM 런타임 비용 메트릭은 주석 품질에 대한 인간 평가의 네 가지 차원(환각, 완결성, 가독성, 유용성) 중 어느 것과도 강한 상관관계를 보이지 않았습니다 (가설 2 확인). 이러한 상관관계는 특히 ALC 코드에서 약했습니다.
• 품질 메트릭: 가독성 수준, BLEU, ROUGE와 같은 자동화된 및 참조 기반 품질 메트릭 역시 인간 평가와 강한 상관관계를 보이지 않았습니다 (가설 3 확인). 다만, ALC 코드에서도 유의미한 상관관계를 보이는 몇 가지 메트릭은 있었습니다.
  • 개발자들의 인식: 개발자들은 LLM 기반 주석 생성 도구가 "코드가 무엇을 하는지"만 설명하는 데 그치고, **"왜 그렇게 작동하는지"**와 같은 가장 가치 있는 측면에서는 제대로 수행하지 못할 것을 우려한다는 점이 다른 연구에서 지적되었습니다. 또한, 그들은 BLEU, ROUGE와 같은 n-gram 기반 성능 메트릭에 대해 특히 회의적이었습니다.

3. 실무적 과제:

• 벤치마크 부족: 문서화 생성 분야에서 좋은 벤치마크 데이터셋의 부족이 자주 인용되는 문제이며, 성능이 데이터셋마다 크게 달라지기 때문에 한 벤치마크의 결과가 새로운 코드베이스에 제대로 일반화되지 않을 가능성이 높습니다.
• 확립된 평가 방법론의 부재: 문서화 품질을 평가하기 위한 확립된 방법론이 없으며, 연구자들은 여전히 임시적인 루브릭을 사용한 수동 인간 평가에 주로 의존합니다.

B. 향후 연구 (Future Work)

1. 미세 조정(Fine-Tuning): 현재 연구에서 사용된 기본 파운데이션 모델(out-of-the-box foundation models)은 불완전한 출력이나 코드 변형 문제를 해결하는 데 효과적이었지만, 주석 품질을 개선할 수 있는 많은 길이 남아있습니다. 산업계에서는 이미 COBOL과 같은 언어에 대한 도메인별 미세 조정의 이점을 입증하고 있으며, 특히 어려운 코드 현대화 사례에 대한 성능 향상을 위해 미세 조정(parameter-efficient fine tuning 포함)을 조사할 필요가 있습니다.
2. 데이터셋 확장: 현실적으로 복잡한 레거시 언어 코드를 가진 오픈 소스 저장소가 흔치 않기 때문에, 미세 조정을 위한 현실적인 레거시 코드 접근이 장벽입니다. 따라서 더 광범위한 레거시 코드 벤치마크에 대한 테스트 방법을 계속 시도하는 것이 중요합니다.
3. 청킹 전략 연구: 연구에서 사용된 탐욕적 청킹 전략(greedy chunking strategy) 외에도, 소스 코드 관련 작업에 가장 적합한 청킹 전략이 무엇인지에 대한 증거가 거의 발표되지 않았으므로, 향후 대체 청킹 전략을 연구할 예정입니다.
4. 평가 메트릭 개선: 연구 결과는 LLM이 생성한 문서화 품질을 평가하기 위한 좋은 자동 또는 반자동 메트릭이 부족하다는 점을 다시 한번 강조합니다. 현재까지 생성된 문서의 정확성에 대한 신뢰를 제공하는 유일한 방법은 인간 전문가가 시스템 출력을 많은 시간 들여 읽고 확인하는 것입니다. 기계 학습을 기반으로 하는 대체 메트릭을 모색하려는 노력이 시작되었지만, 특히 레거시 시스템 현대화 영역에서는 추가적인 조사가 절실히 필요합니다.

비유적 요약:

LLM이 레거시 코드를 문서화하는 것은 마치 오래된 언어로 쓰인 고문서(레거시 코드)를 초심자 통역사(LLM)에게 맡기는 것과 같습니다. MUMPS와 같이 비교적 현대 언어와 유사점이 많은 고문서의 경우, 통역사는 읽기 쉽고 사실에 가까운 주석을 잘 만들었으며, 이는 경험 많은 학자(인간 전문가)가 쓴 주석만큼이나 유용하다고 평가받았습니다. 하지만 ALC처럼 구조가 매우 독특하고 복잡한 고문서의 경우, 통역사가 만든 주석은 품질이 떨어졌고, 심지어 학자들 사이에서도 "좋은 통역"이 무엇인지에 대한 의견이 일치하지 않았습니다. 더 큰 문제는, 자동 점수표(복잡도, BLEU 등)로는 이 통역의 실제 유용성이나 정확도를 전혀 예측할 수 없었기 때문에, 이 통역이 실제로 쓸모 있는지 확인하려면 여전히 가장 비용이 많이 드는 전문가의 수동 검토를 거쳐야 한다는 점입니다.