JavaParser와 AST로 의존 관계 추출하기
일단 클로드 CLI에게 모든 걸 맡겨본다.
우선 멀티 모듈 프로젝트를 하나 만들었다.
순환 참조 탐지 로직이 담긴 모듈
Gradle 플러그인 모듈
샘플 프로젝트
이렇게 3가지 모듈이 담긴 프로젝트를 만든 다음 클로드의 자율 주행을 믿고 따라가보았다.
클로드의 빠른 구현 속도를 따라가기 위해 일단 코드의 디테일한 부분은 미루고 큰 방향만 파악했다.
구현 완료 → 소스 코드 및 클로드의 선택 근거 파악 시작.
플러그인을 Gradle Plugin Portal에 처음 배포하면 검토와 승인이 완료되기 전까지 다른 개발자가 Portal을 통해 내려받아 사용할 수 없다.
하지만 승인 전에도 publishToMavenLocal을 이용해 플러그인을 로컬 Maven 저장소에 배포하고, 내 프로젝트에 적용해 기능을 검증할 수 있었다.
플러그인을 적용해서 패키지 간 순환 참조를 확인해보니 아주 거대한 순환 참조가 생겨나고 있었다.
이 실타래들을 풀어나간 이야기는 다음 글에서 자세히 써보겠다.
이번 글에서는 클로드의 의사 결정 근거를 집중적으로 파헤쳐보기로 한다.
바이트코드를 분석하는 ArchUnit과 달리 컴파일 전의 소스코드로 분석한 이유는? 우선 빠르게 만들기 위해서.
결론부터 말하면, 프로젝트 전체의 컴파일 성공을 의존관계 분석의 선행 조건으로 삼을 필요가 없었기 때문이었다.
그저 빠르게 순환 참조 관계를 보여줄 수 있는 프로토타입을 만드는 것이 가장 우선순위였다.
하지만 막상 플러그인을 다 만들고 적용해보니 빠르게 만드는 것도 중요하지만 정확하게 만드는 것이 더 중요하다고 느꼈다.
ArchUnit에서는 잡았지만 플러그인에서는 못잡은 순환 참조가 있어서 (거짓 음성) 버그 패치를 하기도 했다.
그래서 일단 빠르게 만들어 적용해본 프로토타입의 정확도를 개선하는 작업이 이루어져야 할 것이다.
정확도를 개선하려면 현재 구현 방식보다는 ArchUnit처럼 컴파일된 바이트코드로 의존 방향분석을 하는 편이 더 낫겠다.
왜 프로토타입의 정확도가 떨어진다고 하는 것인지는 아래에서 설명해보겠다.
현재 구현 방식이 어떤지 좀 더 자세히 설명해보겠다.
JavaParser라는 라이브러리를 사용하면 구문 분석 트리(AST)를 만들수 있다.
ClassOrInterfaceDeclaration은 클래스 선언을 찾아주고, 그 내부에서 해당 클래스가 어떤 다른 클래스를 참조하는지 찾아낼 수 있다.