본문 바로가기
Tech

Dead Code 분석도구 - Scavenger (Feat. DEVIEW 2023)

by Garam Kim 2023. 3. 27.
SMALL
 

[DEVIEW 2023] 첫 개발 컨퍼런스

Naver에서는 DEVIEW라는 컨퍼런스 행사를 매년 진행한다고 한다. 코로나가 시들시들해져가고, 오랜만에 오프라인 컨퍼런스를 개최한다고 하는데, 한번도 이런 개발 컨퍼런스는 가본적이 없었고 마

ramka-devstory.tistory.com

 

GitHub - naver/scavenger: a runtime dead code analysis tool

a runtime dead code analysis tool. Contribute to naver/scavenger development by creating an account on GitHub.

github.com

지난달 다녀온 DEVIEW에서 Dead Code 분석도구, Scavenger를 팀 내에서 관리중인 여러가지 서비스에 적용해보고자 샘플링을 진행했다. GitHub에 나온 가이드를 따라하면서 있었던 이슈들과 함께 진행하겠다.

 

기본적으로 Scavenger에서 제공되는 데이터베이스 환경은 H2MySQL인데, 라이센스 문제도 있기 때문에, MariaDB를 사용하였다.

 

사실 MariaDB가 결국 MySQL에서 나온 친구(?) 이기 때문에 전혀 문제가 안될 거라 생각 했지만, 기본적으로 Collector와 API 서버에 의존성부터 넣어줘야 했고, DDL 또한 약간의 차이가 있기에 새로운 프로퍼티를 생성하여 커스텀 작업이 추가적으로 필요했다.

 

기본적으로 해당 레포지토리에서 릴리즈 해준 jar 파일을 받아서 실행 시켜주어도 되지만, 개발환경 구축이 어렵지 않아서 직접 Intellij에 올려보기로 했다.

 

API, Collector 어플리케이션 준비

개발환경 세팅

내가 진행해본 바로는 그냥 최상위 settings.gradle.kts 에서 gradle reload 해주면 되는데, 그냥 하게 되면, scavenger-old-agent-java 부분에서 에러를 만날 수 있다. 프로젝트에 최소 Java 11을 사용하도록 설정했는데, old-agent 는 그것보다 낮은 버전을 쓰고 있었기 때문에, 해당하는 부분을 주석처리후에 reload 해주어야 한다.

old-agent 주석 처리

이렇게 해주면 환경은 완성된다.

 

수정해야할 패키지

3개의 패키지의 추가 및 수정작업 필요

위 패키지에 파일을 추가하거나 수정하는 작업이 추가적으로 필요하다. 아래에 나와있다.

 

Collector, API에 의존성 추가 및 config 파일 추가

Collector, API 패키지에 mariadb client 의존성 추가

 

Collector, API 에 정의한 새로운 yml

환경변수에 지정해서 jar 파일을 올리도록 가이드 하고 있지만, 개발환경도 구축했으니 config 파일을 아예 만들어서 적용하였다.

 

MySQL과 MariaDB의 미세한(?) DDL 차이

Schema Error

Collector가 처음 올라갈 때, 지정된 sql 파일을 읽어서 스키마를 생성해주는데 이 때, 두 DB간에 미세한 차이로 인해 에러가 발생한다. 그래서 기존에 sql파일외에 추가 DDL sql파일을 만들어주어 해당 sql 파일을 바라볼 수 있도록 세팅해주었다.

 

순서대로 MySQL과 MariaDB의 DDL 차이
db.changelog-master.yaml 파일에 mariadb context 추가

 

.conf 파일 생성

Client 접속
설정파일 생성

Collector와 API 어플리케이션을 정상적으로 실행하게 되면, 클라이언트 화면은 기본 제공포트는 8081이며, 포트번호와 함께 해당 화면으로 접근할 수 있으며, 다음과 같은 Dashboard 화면을 볼 수 있다. 워크스페이스 생성을 통해서 그룹을 만들어주고, 내부에 설정 파일 생성하기 버튼을 통해서 .conf 파일을 만들어준다.

 

설정 파일 만드는 화면

별표시가 있는 부분은 필수 입력 값인데, 내 생각엔 분석을 위한 class 파일을 확인해야하기 때문에 codeBase의 위치도 필수값이지 않나 싶다. 이 화면에서 만들어지는 .conf 파일은 가이드문서 내에서 정의한 프로퍼티별로 수동으로 입력가능하지만, api 키의 경우에는 Scavenger Client에서 만들어준 위와 같은 값을 사용해야 인증이 가능하다. 이외에 여러가지 옵션값들도 지정이 가능하다.

 

수집을 위한 SampleApplicatoin 준비

해당 어플리케이션의 conf 파일과 agent 파일을 등록해준다.


이제 수집하고자 하는  어플리케이션에 준비된 agent 파일과 conf 파일을 아래와 같이 환경변수 설정을 통해 같이 올려주면 된다.

 

성공..!

활용

Scavenger의 목적처럼 기본적으로 제공해주는 메서드 호출 기록을 통해서 사용되지 않고 있던 여러 레거시 코드들과 메서드들을 정리하여 빌드속도 개선 및 코드를 읽는데 원활한 환경을 만들어 줄 수 있을 것 같다. 적어도 6개월에서 1년 동안 수집한 다음에, 결과적으로는 DB에 기록하기 때문에, Kibana와 같은 오픈소스를 활용하여 통계를 낼 수도 있을 듯하고, 실제 이 서비스가 만들어진 목적인 '거대한 서비스를 새로운 아키텍처로 구성하기 위해서 필요한 부분만 가져다 쓰기위함' 을 잘 생각하여, 이와 같은 케이스에서 충분이 활용할 수 있을 것이라고 생각한다.

 

라이센스 문제만 없다면 굳이 커스텀 작업 없이 MySQL을 사용할 수 있을 듯 한데......

조금 더 검토해보고 해당 프로젝트에 실제로 기여하는 방법도 하나의 방법인듯 하다....!

LIST