Implementation of Git's Commit Message Classification Model Using GPT-Linked Source Change Data

Abstract

Git의 커밋 메시지는 프로젝트 진행 혹은 운영 과정에서 소스가 변경되는 이력을 관리한다. 이러한 이력 데이터를 활용하면 프로젝트 리스크와 프로젝트 현황을 파악할 수 있어 비용 절감과 시간 효율개선을 높일 수 있다. 이와 관련된 많은 연구가 진행되고 있고 이러한 연구 분야 중 커밋 메시지를 소프트웨어 유지관리의 유형으로 분류하는 연구가 있다. 발표된 연구 중 최대 분류 정확도는 95%로 보고되어 있다. 본 논문에서는 커밋 분류 모델을 이용한 솔루션 등의 활용을 목적으로 연구를 시작했고, 기존 연구 중 정확도가 가장 높은 모델이 JAVA 언어로 작성된 프로그램에만 적용할 수 있는 제약을 없애기 위한 연구를 수행하였다. 이를 위해 GPT를 이용해서 소스 변경 데이터를 자연어로 표준화하는 단계를 추가 설계하고 구현하였다. 본문은 Git에서 커밋 메시지와 소스 변경 데이터를 추출하고, GPT로 소스 변경 데이터를 표준화하는 과정과 디스틸버트(DistilBERT) 모델을 이용한 학습 과정을 설명한다. 검증 결과 91%의 정확도를 측정하였다. 제안하는 모델은 정확도를 확보하고 특정 프로그램에 종속되지 않고 분류할 수 있는 모델을 구현 및 검증하였다. 향후 Bard를 이용한 분류 모델 연구와 제안한 분류 모델을 이용해 프로젝트에 도움이 되는 관리 도구 모델에 관해 연구할 계획이다.

Git's commit messages manage the history of source changes during project progress or operation. By utilizing this historical data, project risks and project status can be identified, thereby reducing costs and improving time efficiency. A lot of research related to this is in progress, and among these research areas, there is research that classifies commit messages as a type of software maintenance. Among published studies, the maximum classification accuracy is reported to be 95%. In this paper, we began research with the purpose of utilizing solutions using the commit classification model, and conducted research to remove the limitation that the model with the highest accuracy among existing studies can only be applied to programs written in the JAVA language. To this end, we designed and implemented an additional step to standardize source change data into natural language using GPT. This text explains the process of extracting commit messages and source change data from Git, standardizing the source change data with GPT, and the learning process using the DistilBERT model. As a result of verification, an accuracy of 91% was measured. The proposed model was implemented and verified to ensure accuracy and to be able to classify without being dependent on a specific program. In the future, we plan to study a classification model using Bard and a management tool model helpful to the project using the proposed classification model.

I. Introduction

소스 버전 관리를 위한 SCM(Source Control Management)의 한 종류인 Git은 Linus Torvalds가 리눅스 커널 관리를 위해 개발한 시스템으로 현재는 프로젝트 개발 및 운영 환경에서 개발 및 유지보수 활동에 이용하고 있다. 이러한 Git은 여러 사용자가 수정하는 소스코드의 변경 내용과 이슈를 관리하면서 변경 사항을 저장하는데 커밋은 한 번의 변경 단위를 말한다[1-2]. 커밋은 개발 및 단위테스트 단계에서 신규 기능 및 테스트 코드가 순차적으로 저장되고, 프로젝트 운영 중에는 프로그램 개선이나 버그 수정과 같은 내용이 기록된다. 이로인해 저장된 커밋 이력과 프로젝트는 밀접한 관련이 있다. 다시 말해, 커밋 이력을 분석함으로써 프로젝트와 운영활동간 리스크를 줄이고 프로젝트 현황을 파악하며 비용 절감 및 시간 효율을 높일 수 있는데, 이에 관련하여 다양한 연구들이 진행되고 있다[3]. 본 논문에서는 많은 커밋 분석 연구 중 커밋 메시지를 유지보수 관리 행위의 유형 세 가지로 분류하는 모델을 연구하였고, 커밋 분류 모델을 이용한 솔루션 등의 활용을 목적으로 진행하였다[4]. 솔루션 활용을 위해서는 비용과 밀접하게 관련이 있어 정확도의 신뢰성이 필요하여 이전 연구에서는 정확도를 높이는 목적으로 기존 연구들의 장점들을 조합하여 정확도 높은 분류 모델을 구현하였다. 하지만 해당 모델의 프로세스 중 소스 변경 내용을 추출하는 부분은 JAVA언어 외에는 추출이 안 되기 때문에 결국은 JAVA로 작성된 프로젝트 외에는 분류할 수 없는 문제가 있다. 이를 해결하기 위해 소스 변경 내용을 추출하는 부분을 GPT로 대체함으로써 언어의 제약을 없애고 정확도를 높일 수 있는 모델을 구현하였다. 본 논문의 최종 목적인 깃 연계 프로젝트 지원 도구를 위해서는 프로젝트를 JAVA로 한정할 수 없기 때문에 언어의 제약을 없애는 개선 사항은 시스템 도입에 도움이 될 것이다.

II. Preliminaries

1. Related works

1.1 Software Maintenance Type

다음 표 1 은 소프트웨어 유지관리의 유형 세 가지를 설명한다[4].

Table 1. Software Maintenance Type

소프트웨어 유지관리의 활동은 다음과 같다.

첫째, 코렉티브(Corrective)는 문제가 되는 기능의 버그를 교정 및 고치는 유지보수 활동 행위이다.

둘째, 퍼펙티브(Perfective)는 시스템의 보완하기 위해 개선하는 유지보수 활동 행위이다.

셋째, 어댑티브(Adaptive)는 기존 시스템에 신규 기능을 추가하는 개발 유지보수 행위이다.

본 논문에서는 커밋 메시지를 유지보수 활동 세 가지 형태로 분류하는 연구이다.

1.2 Commit Message Classification Model By Utilizing Source Code Change

다음 그림 1 은 소스 변경 데이터를 추출하여 커밋 메시지를 분류하는 모델의 프로세스이다.

Fig. 1. Classification Process Using Source Change

이 연구에서는 체인지디스틸러(ChangeDistiller)라는 소스 변경 추출 도구를 이용한다. 체인지디스틸러는 JAVA로 작성된 소스 코드의 변경 전 소스와 변경 후 소스를 입력하면 변경된 사항을 48의 크기인 배열로 제공해준다. 다음 표 2 는 체인지디스틸러가 제공하는 배열의 인덱스마다 뜻하는 소스 변경 타입 48가지 유형 중 일부이다[5-8].

Table 2. Source Change Type Index Description

제공한 배열에는 변경된 유형의 인덱스에 빈도수를 제공한다. 일반적인 커밋 메시지 분류 모델에 소스 변경 빈도 배열을 학습할 때 특징(Feautre)으로 같이 활용하였고 정확도(Accuracy) 76%로 보고하였다[9]. 본 논문에서는 제안하는 논문과 비교하기 위해 해당 모델을 직접 구현하여 같은 커밋 목록들을 대상으로 정확도를 비교한다.

1.3 Commit Message Classification By Utilizing DistilBERT

다음 그림 2 는 전이학습 모델인 구글(Google)의 디스틸 버트(DistilBERT)를 이용한 분류 모델이다.

Fig. 2. Classification Process Using DistilBERT Model

이 연구에서는 디스틸 버트 전이학습 모델을 사용해 커밋 메시지를 분류하였다. 디스틸 버트는 버트를 커스터마이징한 버트 모델로 버트보다 빠르고 가벼운 모델이다[10-11]. 많은 데이터를 학습하기에 적합하고 효과적으로 사용될 수 있다. 해당 모델은 입력값에 커밋 메시지만을 입력하여 유지관리 세 가지 유형으로 레이블 하여 지도 학습한 모델이다. 이 연구에서는 정확도 추출을 F1 점수로 평가하였고 평가된 점수는 87%로 보고하였다[12].

1.4 Commit Message Classification That Combines The Two Model.

다음 그림 3 은 1.2의 모델과 1.3 두 가지 모델의 특장점을 조합한 분류 모델의 프로세스이다.

Fig. 3. Proposed Classification Process

이 연구에서는 관련연구 1.2 분류 모델과 1.3 분류모델에서의 장점들을 조합한 모델이다. 1.2 연구에서는 학습시 체인지디스틸러를 이용해 JAVA 언어를 대상으로 소스변경 빈도 배열을 특징으로 이용하고 1.3 분류모델에서의 디스틸버트를 이용해 전이학습을 이용하였다. 다음 그림 4는 학습 시 레이블링한 데이터 일부이다.

Fig. 4. Labeled Data​​​​​​​

이 연구에서는 정확도를 F1점수로 평가하였고 95%로 보고하였다[13]. 본 논문에서는 해당 연구에서 JAVA 언어로 작성된 소스를 대상으로만 모델을 적용할 수 있는 문제를 개선하기 위해 GPT를 이용해 소스 변경 요약내용을 추출하여 언어제약을 없앨 수 있다.

III. The Proposed Scheme

1. System Configuration

다음 그림 5 는 본 논문에서 구성한 GPT를 이용한 분류모델의 시스템 구성도이다.

Fig. 5. System Configuration​​​​​​​

크롤러(Crawler) 서버는 Github에서 선정된 프로젝트를 클론(Clone)하고 프로젝트마다 커밋 정보를 추출하고, 추출한 커밋 정보는 커밋 ID, 커밋 메시지, 실제 소스의 변경 소스이다. GPT 연계 서버는 ChatGPT 서비스를 API로 연계한 서버이다. 해당 서버는 Spring Boot로 구성된 톰캣 WAS(Web Application Server) 이고 실제 소스 내용을 입력받아 ChatGPT 서비스에 API 통신을 하여 소스의 변경된 요약 정보를 응답받아 정보를 취합한다. 모델 학습 서버는 파이썬 서버로 구성했고 실질적인 모델 학습을 담당한다. 모델 학습 서버는 앞의 두 개의 서버를 거쳐 추출하고 취합하여 가공한 데이터를 이용하여 학습을 진행한다. Python으로 작성된 학습 서버는 AI 및 데이터 분석에 많이 활용되는 라이브러리르 이용해 개발하였다. numpy와 Pandas, simpletransformers 라이브러리를 이용해 데이터 전처리 및 학습과 검증을 수행하고, tensorboard, Seaborn등의 라이브러리를 이용해 학습 과정과 학습 결과를 선형차트로 표현했다.

2. Target Languages

분석 대상의 언어는 티오베(TIOBE) 지수에서 2023년 1월부터 9월까지 프로그래밍 언어 순위 1위를 유지하고 있는 파이썬과 지난 연구와의 비교를 위해 JAVA언어를 선정하였다. 다음 표 3 은 티오베 지수의 언어 별 월의 지수를 나타낸다[14].

Table 3. 2023 Year Language Usage Rate​​​​​​​

3. Target Projects

분석 대상 프로젝트는 다음 표 4 과 같다.

Table 4. Target Projects​​​​​​​

본 논문에서 프로젝트는 관련 연구 1.4 분류 모델에서 선택했던 JAVA 기반의 세 가지 프로젝트와 현재 프로그래밍 인기 순위가 가장 높은 파이썬으로 작성한 두 가지 프로젝트를 추가하였다. 다섯 개의 프로젝트는 Github 에서 공개된 오픈소스이다. 별점(Star)과 인용 수(Fork)는 프로젝트의 추천한 수와 프로젝트를 인용하고 커스터마이징한 점수를 나타내는데 프로젝트의 신뢰 높은 프로젝트임을 알 수 있는 지표이다. 본 논문에서 선정한 다섯 개의 프로젝트는 모두 10000명 이상의 개발자가 추천한 프로젝트이고 해당 프로젝트를 인용하는 개수도 1000개 이상부터 많게는 20000개의 인용한 프로젝트가 있다. 선정된 다섯 개의 프로젝트에서는 커밋 데이터 학습을 위해 프로젝트마다 500건씩 총 2500건의 데이터를 추출하였다.

4. System Process

다음 그림 6 은 구현 모델의 시스템 프로세스이다.

Fig. 6. Proposed Classification Process​​​​​​​

전체적인 프로세스는 데이터 추출, 데이터 레이블링, 데이터 전처리, 모델 학습, 모델 검증, 모델 수립의 순서로 진행된다. 단계에 대한 상세한 내용은 다음과 같다.

4.1 Extract Data

4.1.1 Commit Basic Info Extraction

다음 그림 7 은 커밋 정보를 추출하기 위한 명령어이다.

Fig. 7. Git Log Command​​​​​​​

Git CLI(CommandLine Interface)는 많은 기능을 제공하는데 그 중 커밋의 정보를 추출하기 위해 git log 명령어를 사용하여 일괄 추출할 수 있다[15-16]. log 명령어는 옵션을 통해 원하는 형태로 출력이 가능한데 —name-only 명령어와 pretty 옵션을 통해 원하는 파싱 형태로 가공 했다. name-only 옵션은 변경된 소스 파일의 목록을 제공하고 pretty 옵션은 출력 포맷을 지정한다. 다음 그림 8 은 추출한 깃의 커밋 정보 세트의 예제이다.

Fig. 8. Commit Info Set Example​​​​​​​

(1)번은 커밋 ID이고, (2)번은 커밋을 수행한 작성자가 남긴 커밋 메시지이고 (3)번은 커밋에서 수정된 소스 파일의 목록을 보여준다. 커밋 하나마다 그림 8과 같이 하나의 세트로 정보를 출력한다. 본 논문에서는 이와 같은 형태로 프로젝트마다 500개의 커밋 정보 세트를 추출했다.

4.1.2 Source Change Extraction

다음 그림 9 는 소스 변경 내용을 추출하는 명령어이다.

Fig. 9. Command to extract source change​​​​​​​

diff 명령어는 2개의 인자를 받는데 첫 번째 인자로 커밋의 ID를, 두 번째 인자로 해당 커밋에 포함된 소스파일의 경로와 파일명을 입력한다. 추출된 소소의 샘플은 다음 그림 10 와 같다.

Fig. 10. Source Change Extraction​​​​​​​

(1)번 영역은 해당 파일에서 삭제된 부분을 표현한다. 마이너스 기호를 맨 앞에 붙이고 해당 소스내용을 보여준다. (2)번 영역은 추가된 소스 내용을 표현하는데 삭제 표현과 반대로 플러스 기호를 통해 소스의 추가를 표현한다.

4.2 Labeling

다음 표 5 는 수집한 데이터와 레이블링한 데이터를 정리한 CSV(Comma-Seperated Values)파일의 의 컬럼 정보이다.

Table 5. Target Projects​​​​​​​

1~3번의 컬럼은 추출한 커밋의 프로젝트명과 커밋 ID 그리고 커밋 메시지이다. 4~6의 컬럼은 분류하고자 하는 커밋 분류 유형 세 가지로 Corrective, Perfective, Adaptive를 1,0의 Boolean 값으로 표현하였다. 분류 유형은 관련 연구 1.1 Software Maintenance Type에서 자세히 설명하였다. 7번 컬럼은 실제로 11개의 컬럼으로 구성하였으며 각 컬럼에는 해당하는 커밋에서 실제 수정된 파일의 변경 내역이 로그로 저장되어 있다. 11개로 구성한 이유는 각 컬럼은 커밋에서 변경한 파일의 수만큼 구성할 수 있는데 수집한 커밋 목록에서의 가장 많은 파일수를 가진 커밋이 11개이기 때문에 11개의 컬럼을 구성하여 커밋 당 모든 파일의 변경된 내용을 저장하였다. 총 수집된 데이터 개수는 5개의 프로젝트에서 각각 300개의 커믿을 수집하여 총 1500건의 데이터를 수집하였고 해당 과정에서 업무 담당자들이 직접 커밋을 분류 및 검증을 하고 학습에 불필요한 커밋 정보는 삭제하였다. 학습에 불필요한 데이터 중 대표적인 예는 브랜치를 병합할 때 자동으로 생기는 커밋 메시지인 “Merge” 키워드로 시작하는 커밋 메시지가 있고, 커밋 내용 중 변경된 파일이 없는 것을 제거하였다. 해당 과정에서 남은 최종 데이터는 827건이다.

4.3 GPT-Linked Extraction

다음 그림 11 은 GPT를 연계한 소스 코드의 일부 내용이다.

Fig. 11. GPT-Linked Code​​​​​​​

(1)번 영역은 GPT 3.5의 경우 총 토큰 수는 4096개로 제한되기 때문에 4096개 보다 토큰 수가 많은 경우 메시지를 4096개 토큰으로 나누어 모든 소스 코드를 분석할 수 있게 한다. 그리고 소스 코드를 입력받은 GPT가 소스 코드의 변경 내용을 요약한 결과를 응답받기 위해 소스 코드를 입력하기 전 Default_Question값으로 “Here is the source change using Git's diff command. Please explain the purpose of the content.”의 질문을 먼저 요청한다. (2)번 영역은 GPT API와 연동해서 소스 변경의 요약내용을 응답받을 수 있는 함수를 호출하는 부분이다. 사용하는 GPT 모델은 gpt-3.5-turbo를 사용하였고 openai 라이브러리를 활용해 GPT API를 호출하였다.

4.4 Data Pre-Processing

다음 그림 12 는 전처리 과정의 소스 코드이다.

Fig. 12. Pre-Processing Source Code​​​​​​​

디스틸버트 모델은 대량의 단어 임베딩에 대해 사전 학습이 되어 있는 모델을 제공한다. 따라서 데이터 대부분의 전처리 과정을 생략할 수 있는 장점이 있다. (1)번 과정에서 학습이 가능하도록 형 변환과 공백 및 Null인 데이터를 모두 제거한다. (2)번 과정에서 분류하고자 하는 세 가지 소프트웨어 유형 세 가지를 “labels” 라고 명명한 컬럼에 배열 형태로 입력한다. (3)번 과정에서 커밋 메시지와 커밋별 GPT로 추출한 11가지의 소스 변경 내용을 버트의 입력값 프로토콜에 맞게 데이터를 가공한다. 해당 과정에서는 입력 데이터가 12가지의 형태이므로 커밋 메시지와 11가지의 소스 변경 내용을 ‘[SEP]’ 이라는 구분자로 구분하여 디스틸 버트모델의 프로토콜에 맞게 변환한다[17-18]. (4)번 과정에서는 과적합(Overfitting)을 막기 위해 8:2 비율로 학습 데이터와 검증데이터로 먼저 분리하여 학습했던 데이터가 검증에 사용하지 않도록 한다.

4.5 Transfer Learning

모델 학습은 하이퍼 파라미터(Hyper Parameter)의 설정에 따라 결과가 다른데, 많은 반복적인 연구를 통해 본 연구 모델에 맞는 최적의 파라미터값을 도출하였다. 도출된 파라미터는 다음 표 6 와 같다.

Table 6. Hyper Parameter Config Values​​​​​​​

학습 시 에포크(epoch)수는 30회 설정을 넘어가면서 학습 정확도가 떨어짐을 확인할 수 있다. 학습률(learning rate)은 학습을 반복 시 파라미터 조정 빈도를 뜻하는데, BERT[14] 논문에서 BERT 모델을 이용할 때 학습률이 최적인 설정값을 5e-5, 4e-5, 3e-5, 2e-5라고 보고하고 있다. 본 논문에서는 4개의 설정값을 적용해본 후 가장 좋은 결과를 도출하는 2e-5 값을 설정한다. 배치 크기(batch size)의 경우는 BERT 논문에서 32값이 최적이라고 보고되었지만 본 논문의 연구에서는 8값까지 낮췄을 때 최적의 학습곡선을 그리는 결과를 확인하고 8값으로 설정한다. 학습은 총 827건의 데이터의 80%인 662개의 데이터로 학습하고 배치(Batch) 크기인 8로 나눈 1회의 에포크(Epoch)마다 83개의 스텝(Step)을 30회 진행하여 총2,490회의 반복(Iteration)을 통해 파라미터를 계속 변경한다. 다음 그림 13은 학습은 진행하는 모습이다.

Fig. 13. Learning Progress​​​​​​​

다음 그림 14 와 그림 15 는 학습 시 손실률과 학습률 그래프이다.

Fig. 14. Loss Rate

Fig. 15. Learning Rate

30회의 에포크 동안 학습이 계속될수록 손실률은 떨어져서 최종 학습 시에는 0.0020까지 떨어짐을 확인할 수 있다. 학습률은 2e-5까지 Y축으로 선형적으로 증가하며 학습하고 이후에는 0에 수렴하는 모습으로 학습이 정상적으로 이루어짐을 알 수 있다.

IV. Validation

1. Model Validation

해당 과정에서는 학습 데이터로 사용하지 않은 미리 분리 해뒀던 20%의 검증데이터로 모델검증을 진행한다. 다중 레이블 분류 검증에 많이 이용하는 F1 점수를 계산하기 위해 정밀도(Percision)과 재현율(Recall)을 먼저 계산하고 F1 점수를 계산하였다. 다음 표 7 는 제안 모델의 검증 결과이다.

Table 7. Model Validation Results​​​​​​​

검증 결과의 Percision은 정밀도를 나타내는데 91%의 정밀도 결과를 얻었다. Recall은 재현율로 92%를 기록했다. F1-Score는 F1 점수이다. 정밀도와 재현율의 평균으로 계산된다. F1 점수가 높은 분류 모델이 좋다고 평가할 수 있으며 제안 모델의 검증 결과는 F1 점수인 91%의 결과를 보여준다.

2. Model Evaluation

다음 표 8 은 모델 검증 결과와 다른 모델과 제안 모델의 정확도를 비교한 표이다.

Table 8. Compare Model Results​​​​​​​

이전에 연구했던 JAVA 언어 대상으로만 가능한 J. H. Choi의 디스틸버트와 소스 코드 변경 내용을 함께 학습한 모델보다는 4% 낮은 점수를 기록했다. 비록 F1 점수가 떨어지긴 했지만 제안한 모델은 JAVA가 아닌 다른 언어로 작성된 프로젝트도 제약 없이 분류할 수 있음을 보였다. 그리고 앞서 커밋 메시지를 분류했던 연구들과 비교해보면 M. U. Sarwar의 연구인 디스틸버트만 이용했던 모델보다 4% 정확도 향상이 있으며, 소스 변경 유형 빈도를 이용한 S. Levin의 모델보다 15% 정확도 향상을 나타냈다. 마지막으로, Mauczka의 연구와의 비교에서는 41% 향상된 결과를 보여준다[19-20]. 이는 제안하는 모델이 다양한 비교 연구들과 비교하여 대부분 높은 정확도 향상을 확인할 수 있으며, 다른 언어로 작성된 프로젝트에 대한 분류에서도 그 타당성을 입증할 수 있다.

V. Conclusions

본 논문은 커밋 메시지를 더 정확히 분류하기 위해서 소스 변경 데이터를 같이 활용하였다. 이전 연구에서는 커밋 메시지 분류 모델에 JAVA 언어로 작성된 프로그램만 소스 변경 데이터를 추출할 수 있는 문제가 있었다. 본 연구에서는 이전 연구의 단점인 언어제약을 없애기 위해 생성형 AI인 GPT 모델로 소스 변경 데이터를 자연어로 표준화시키는 전처리 단계를 추가하여 언어제약을 없앴고 모델의 검증을 위해 JAVA로 작성된 프로그램 외에도 Python으로 작성된 프로그램들을 추가 대상으로 데이터를 수집하여 모델을 학습하였고 모델의 점수를 91%까지 도출하였다. 다른 연구들과 비교 시 이전 연구에서 획득했던 모델점수보다 4% 낮은 평가를 기록하였지만 특정 프로그램 언어에 종속되지 않고 분류할 수 있는 모델을 제안 및 검증하였다. 하지만 비교한 논문의 경우 분류 성능이 크게 다를 수 있고, 각 모델은 서로 다른 맥락에서의 분석인 부분과 다른 데이터 세트로 테스트한 차이점이 있고, 모델 구현에 대한 정확한 재현이 어렵기 때문에 실증적 분석이 어렵다. 이로 인해 도출한 비교 결과가 편향된 결과일 가능성이 있다[21]. 추후 구현이 가능한 모델들을 최대한 유사하게 구현하여 동일 데이터 샘플로 학습시킨 실증적 비교가 필요하다. 또한, GPT 모델과 유사한 생성형 AI 모델인 구글의 바드(Bard) 모델을 이용해서 정확도의 차이를 연구하고 더 나아가 제안하는 분류 모델을 이용해 프로젝트에 도움이 되는 관리 도구 모델에 관해 연구할 예정이다.