더 이상 사용되지 않는 함수를 제거하기 전에 해당 함수를 호출하는 모든 코드를 찾는 방법

코드베이스에서 더 이상 사용되지 않는 함수를 제거하는 것은 개념적으로 개발자가 할 수 있는 가장 간단한 작업 중 하나입니다. 함수 정의를 삭제하고, 해당 함수를 사용하는 다른 코드가 없는지 확인한 후, 커밋하면 됩니다. 하지만 실제로는 오랫동안 사용되어 더 이상 사용되지 않는 함수의 경우, "아무도 사용하지 않는지 확인하는" 단계에서 문제가 발생합니다. 해당 함수는 몇 년 전에 팀에 없는 사람이 작성한 코드에서 호출될 수도 있고, 변경 빈도가 낮은 저장소에서 호출될 수도 있으며, 현재 팀이 소유하지 않은 언어나 프레임워크에서 호출될 수도 있습니다. 래퍼를 통해 간접적으로 호출되거나, 리플렉션을 통해 호출되거나, 정적 호출 그래프에 나타나지 않는 런타임 디스패치 메커니즘을 통해 호출될 수도 있습니다. 생성된 코드, 테스트 스캐폴딩, 또는 함수 이름을 사용하여 호출하는 구성 파일에서 참조될 수도 있습니다. 해당 함수를 더 이상 사용되지 않는 것으로 표시하는 개발자와 최종적으로 제거하는 개발자는 저장소 전체의 호출자 목록을 구축할 수 있는 도구가 없이는 이러한 모든 정보를 알 수 없을 수도 있습니다.

이 문제를 잘못 처리했을 때 발생하는 비용은 즉각적이고 구체적입니다. 호출자를 완전히 파악하지 못한 채 함수가 제거되면 해당 함수에 여전히 의존하는 시스템에서 런타임 오류가 발생합니다. 단일 배포 방식의 모놀리식 시스템에서는 오류 발생 가능성이 제한적입니다. 하지만 여러 서비스가 각각 독립적으로 배포되는 분산 시스템에서는 오류가 연쇄적으로 발생합니다. 함수를 제공하는 서비스는 업데이트되지만, 해당 함수를 사용하는 서비스는 업데이트되지 않아 서로 다른 팀이 소유한 프로덕션 시스템의 런타임에 문제가 발생할 수 있습니다. COBOL 프로그램이 공유 유틸리티 단락을 이름으로 호출하는 메인프레임 환경에서는 특정 배치 작업(매주 또는 매월 실행될 수 있음)이 실행될 때까지 오류가 나타나지 않을 수 있으므로 일반적인 테스트 주기 동안에는 누락된 참조를 발견할 수 없습니다. 더 넓은 맥락에서, 즉 더 이상 사용되지 않는 코드를 관리하는 관점에서 보면 위험은 시간이 지남에 따라 누적됩니다. 불완전하게 제거된 더 이상 사용되지 않는 코드는 그대로 남겨진 코드보다 더 위험합니다. 제거로 인해 모든 것이 완료된 것처럼 보이지만, 남아 있는 호출자는 더 이상 존재하지 않는 정의를 계속해서 사용하기 때문입니다.

이 글은 함수 제거 전 호출자 파악에 대한 실용적인 가이드입니다. 완전한 호출자 목록을 작성하는 데 필요한 요소, 개발자들이 가장 먼저 사용하는 도구들이 구조적으로 불충분한 이유, 다양한 유형의 호출 관계에 따라 요구되는 분석 접근 방식의 차이, 그리고 여러 언어, 플랫폼, 저장소가 혼합된 엔터프라이즈 규모 코드베이스에서 진정한 시스템 간 호출자 열거가 어떻게 이루어지는지를 다룹니다.

발신자 정보 파악이 생각보다 어려운 이유

호출자 검색의 표면적인 버전은 모든 개발자에게 익숙합니다. IDE에서 함수 이름을 마우스 오른쪽 버튼으로 클릭하고 "모든 참조 찾기" 또는 "호출 계층 구조 표시"를 선택한 다음 결과를 검토하는 것입니다. 이 방법은 단일 IDE 인스턴스에 로드된 단일 프로젝트 범위 내에서는 안정적으로 작동합니다. 그러나 코드베이스가 이 범위를 벗어나면 출력에 나타나지 않는 방식으로 결과가 불완전해집니다. IDE는 해당 호출자가 포함된 저장소를 인덱싱하지 않아 찾지 못한 호출자를 표시하지 않습니다. 개발자는 결과가 완전해 보이는 것을 보고 그에 따라 작업을 진행합니다.

대규모 환경에서 호출자 검색에 내재된 구조적 문제는 바로 이것입니다. 개발자들이 가장 능숙하게 사용하는 도구는 인덱싱 범위에 제약을 받는데, 대규모 분산형 다국어 시스템에서는 그 범위가 특정 함수가 호출될 수 있는 위치의 극히 일부만을 포괄한다는 것입니다. 검색 결과의 완전성에 대한 개발자의 신뢰도는 실제 검색의 완전성에 반비례합니다. 소규모 단일 언어 코드베이스에서는 IDE의 호출 계층 구조가 매우 신뢰할 만합니다. 하지만 여러 저장소, 언어, 배포 환경에 걸쳐 있는 엔터프라이즈 시스템에서는 체계적으로 잘못된 정보를 제공합니다. 코드 엔트로피와 리팩토링 위험 의 관점에서 분석해 보면 , 레거시 모듈은 더 이상 사용되지 않는 인터페이스에 의존할 수 있고, 최신 서비스는 여전히 이전 환경을 위해 설계된 루틴을 호출할 수 있습니다. 이러한 시스템 간 호출 관계는 IDE에 한정된 검색으로는 파악할 수 없는 부분입니다.

발신자 확인이 실패하는 구체적인 이유를 파악하려면 주요 통화 유형(직접 통화, 간접 통화, 다국어 통화, 동적 배차)을 각각 검토해야 합니다. 각 유형은 실패 원인이 다르며, 정확한 해결을 위해서는 서로 다른 분석 기법이 필요합니다.

저장소 경계를 넘는 직접 호출

직접 호출은 가장 간단한 호출 유형입니다. 즉, 한 함수가 다른 함수를 이름으로 명시적으로 호출하는 것입니다. 단일 저장소 내에서는 IDE가 이러한 호출을 안정적으로 처리합니다. 하지만 저장소 경계를 넘어서는 경우에는 IDE의 인덱싱이 경계를 넘나들지 않기 때문에 분석이 실패합니다. 예를 들어 저장소 A에서 공유 유틸리티 함수를 정의하고 저장소 B, C, D에서 각각 해당 함수를 가져와 호출하는 경우, 각 저장소의 IDE는 자체 인덱싱 범위 내의 호출만 인식합니다.

이러한 다중 저장소 호출 패턴은 공유 라이브러리가 패키지로 게시되고 수십 개의 서비스에서 사용되는 마이크로서비스 아키텍처에서 예외가 아닌 일반적인 현상입니다. 공유 패키지에서 함수를 더 이상 사용하지 않도록 지정하는 라이브러리 관리자는 어떤 서비스가 여전히 해당 함수를 호출하는지 알아야 합니다. 하지만 IDE는 소비자에 대한 정보를 전혀 알지 못합니다. 패키지 관리자는 어떤 서비스가 패키지에 의존하는지는 알지만, 각 서비스가 패키지 내의 어떤 특정 함수를 호출하는지는 알지 못합니다. "이 서비스는 이 패키지의 버전 X를 사용합니다"라는 정보를 "이 서비스는 이 특정 사용 중단된 함수를 호출합니다"로 매핑하려면 모든 소비자의 소스 코드를 인덱싱하고 해당 호출을 특정 함수 정의로 해석해야 합니다.

간접 호출: 래퍼, 델리게이트 및 파사드

함수는 해당 함수를 사용하는 주체에 의해 직접 호출될 수 없습니다. 추가적인 로깅, 오류 처리 또는 매개변수 변환을 제공하는 래퍼 함수를 ​​통해 호출될 수 있습니다. 또한, 델리게이트 또는 함수 포인터에 할당되어 델리게이트를 통해 호출될 수도 있습니다. 서비스 레지스트리 또는 플러그인 프레임워크에 등록되어 디스패치 메커니즘을 통해 이름으로 호출될 수도 있습니다. 이러한 모든 경우에, 사용이 중단된 함수에 대한 직접 호출 검색은 불완전한 결과를 반환합니다. 실제 호출자는 사용이 중단된 함수 자체가 아니라 래퍼 함수 또는 디스패처를 호출하기 때문입니다.

래퍼를 통한 호출은 로깅, 권한 부여, 재시도 로직과 같은 횡단 관심사가 래퍼 패턴을 통해 핵심 함수 주변에 계층화되는 대규모 코드베이스에서 특히 흔히 발생합니다. 로깅 유틸리티로 래핑된 사용되지 않는 함수는 해당 함수의 이름을 포함하는 코드가 아니라 래퍼를 호출하는 모든 코드에서 사실상 호출됩니다. 이러한 호출자를 식별하려면 래퍼를 따라 추적해야 합니다. 로깅 유틸리티는 사용되지 않는 함수를 호출하므로 로깅 유틸리티를 호출하는 모든 코드는 사용되지 않는 함수를 간접적으로 호출하는 것입니다. 이러한 재귀적 호출 그래프 탐색은 표면적인 참조 검색과 철저한 호출자 목록을 구분하는 핵심 요소입니다.

위임 계층을 통해 더 이상 사용되지 않는 메서드에 접근하는 대표적인 Java 예제를 살펴보겠습니다.

자바

// Deprecated in the core service
@Deprecated
public BillingResult calculateLegacyFee(Account account) {
    // original implementation
}

// Facade that delegates; not visible as a direct caller in a simple reference search
public BillingResult computeFee(Account account) {
    return calculateLegacyFee(account);  // indirect caller
}

// Actual consumer; calls computeFee, unaware of the underlying deprecated method
public void processMonthlyBilling(List<Account> accounts) {
    accounts.forEach(a -> computeFee(a));  // two hops from the deprecated function
}

"모든 참조 찾기" 검색 calculateLegacyFee 반품 computeFee 유일한 발신자로서. 응답하지 않습니다. processMonthlyBilling이는 더 이상 사용되지 않는 동작의 실제 소비자입니다. 완전한 발신자 목록을 얻으려면 통화 그래프를 따라 상류로 이동해야 합니다. computeFee 더 이상 사용되지 않는 메서드를 호출하는 모든 경로를 식별합니다.

다국어 기도문

언어 간 호출은 표준 호출자 검색 도구가 가장 심각하게 실패하는 범주입니다. Java 서비스가 미들웨어 계층을 통해 COBOL 프로그램을 이름으로 호출하거나, Python 스크립트가 더 이상 사용되지 않는 함수를 래핑하는 저장 프로시저를 호출하거나, JCL 작업이 내부적으로 더 이상 사용되지 않는 단락을 호출하는 프로그램을 PROGNAME으로 호출하는 경우, 이러한 관계는 어떤 단일 언어의 호출 그래프에도 나타나지 않습니다. 각 언어의 도구는 호출의 자사 측만 인식합니다.

메인프레임 환경에서 언어 간 호출은 구조적이고 광범위하게 나타납니다. JCL 작업 스트림은 실행할 COBOL 프로그램의 이름을 지정합니다. COBOL 프로그램은 이름으로 단락과 서브프로그램을 호출합니다. 복사 라이브러리에 정의된 유틸리티 단락은 여러 프로그램에서 공유됩니다. 복사 라이브러리의 단락이 더 이상 사용되지 않게 되면, 모든 호출자를 찾으려면 COBOL 호출 관계(복사 라이브러리를 포함하는 프로그램과 해당 단락을 호출하는 프로그램), JCL 호출 관계(어떤 작업이 해당 프로그램을 호출하는지), 그리고 언어 간 인터페이스(해당 프로그램과 상호 작용하는 Java 또는 SQL)를 모두 이해해야 합니다. 이러한 모든 관계를 포괄하는 단일 도구는 없습니다. 레거시 시스템에 대한 정적 분석에서 살펴본 바와 같이 , 최신 환경을 위해 개발된 정적 분석 도구는 호출 관계가 JCL, COBOL, 그리고 시스템 간 인터페이스에 걸쳐 동시에 존재할 때 레거시 프로그램이 어떻게 트리거되고, 호출되고, 상호 연결되는지에 대한 전체적인 그림을 파악할 수 없습니다.

동적 배차 및 반사

일부 호출자는 소스 코드에 있는 함수의 실제 이름이 아니라 런타임에 함수를 해석하는 메커니즘(예: Java 또는 .NET의 리플렉션)을 통해 함수를 호출합니다. getattr/__call__ Python에서 COBOL의 늦은 바인딩을 통해 CALL identifier다형성을 통한 동적 디스패치 또는 플러그인 프레임워크 및 구성 기반 시스템에서 문자열을 통한 호출 등이 그 예입니다. 이러한 호출자는 정적 분석으로 확실하게 감지할 수 있는 어떤 형태로든 더 이상 사용되지 않는 함수의 이름을 포함하지 않습니다.

함수 이름을 문자열로 지정하고 런타임에 로드되어 리플렉션을 통해 함수를 호출하는 구성 파일은 소스 코드 분석에서 전혀 나타나지 않는 호출자입니다. 인터페이스를 통해 등록된 핸들러를 검색하고 호출하는 플러그인 프레임워크는 호출 그래프에서 특정 핸들러 호출이 아닌 디스패치 메커니즘 호출로만 나타나는 호출자입니다. 이러한 호출자를 식별하려면 동적 디스패치 패턴을 찾기 위한 정적 분석, 실제 호출을 관찰하기 위한 런타임 추적, 그리고 어떤 함수가 디스패치되는지를 결정하는 구성 및 등록 로직에 대한 수동 검사를 조합해야 합니다. 난독화되고 생성된 코드에 대한 정적 분석 검토에서 논의했듯이 , 실행 경로가 소스 코드에 직접 표현되지 않은 경우 정적 분석은 직접적인 텍스트 참조가 아닌 구조적 패턴에서 가능한 경로를 재구성해야 하며, 이러한 재구성에는 디스패치 메커니즘 자체에 대한 언어 인식 분석이 필요합니다.

개발자들이 가장 먼저 찾는 도구와 그들이 멈추는 지점은 어디일까요?

개발자들이 발신자 정보를 파악하기 위해 사용하는 도구들의 순서는 예측 가능하며, 각 도구가 더 이상 신뢰할 만한 결과를 제공하지 못하는 시점 또한 예측 가능합니다. 이러한 순서를 이해하는 것은 중요합니다. 왜냐하면 각 도구의 출력 결과가 완벽해 보일지라도 실제로는 그렇지 않기 때문입니다.

IDE 호출 계층 구조: 단일 프로젝트 내에서 안정적인 작동

IDE의 함수 호출 계층 구조 기능을 활용하는 것이 가장 자연스러운 첫걸음입니다. IntelliJ IDEA, Visual Studio, VS Code, Eclipse는 모두 현재 프로젝트 또는 작업 영역의 인덱싱된 범위 내에서 선택한 함수의 호출자를 재귀적으로 열거하는 "모든 호출자 찾기" 또는 "호출 계층 구조 표시" 기능을 제공합니다. 특정 저장소와 특정 언어 내에서만 사용되는 함수라면 이러한 기능만으로도 충분하고 정확합니다.

검색 범위에 대한 제한 사항은 "인덱싱된 범위 내"라는 명시적인 범위 지정에 있습니다. 다른 저장소, 다른 언어 런타임 또는 패키지 관리자를 통해 이 코드에 의존하는 서비스에서 호출하는 경우는 검색 범위 밖에 있습니다. IDE는 검색하지 않은 항목을 표시하지 않습니다. 개발자는 결과 집합을 받지만 인덱싱되지 않은 추가 저장소가 몇 개인지, 그중에서 더 이상 사용되지 않는 함수를 사용하는 저장소가 몇 개인지, 또는 "호출자 없음" 결과가 실제로 호출자가 없다는 의미인지 아니면 "이 도구가 볼 수 있는 시스템 영역 내에서 호출자가 없다는 의미"인지 알 수 없습니다.

grep과 텍스트 검색: 광범위하지만 구조는 고려하지 않음

IDE 검색이 불완전하다고 의심될 경우, 다음 단계는 일반적으로 텍스트 검색입니다. 사용 가능한 소스 디렉터리에서 grep을 사용하거나 GitHub 또는 GitLab 코드 검색을 통해 플랫폼 검색을 수행합니다. 이렇게 하면 검색 범위가 상당히 넓어지고, 접근 가능한 다른 저장소에 있는 함수 호출자도 찾을 수 있습니다. 하지만 구조적인 문제는 텍스트 검색이 함수 호출이 아닌 문자열을 찾는다는 점입니다. 텍스트 검색은 함수 이름이 포함된 모든 위치를 반환하는데, 여기에는 함수를 언급하는 주석, 문서 문자열, 디버깅 목적으로 함수 이름을 명시하는 로그 메시지, 함수 이름을 포함하지만 직접 호출하지 않는 문자열 리터럴 등이 포함됩니다. 또한 함수 이름이 검색 문자열과 다른 경우, 즉 별칭을 통한 호출, COBOL에서 이름이 축약된 경우처럼 부분적으로 일치하는 이름을 통한 호출, 또는 런타임에 이름이 생성되는 동적 호출을 통한 호출은 누락됩니다.

텍스트 검색 결과는 실제 통화 기록, 문서 참조, 문자열 충돌로 인한 오탐을 구분하기 위해 수동 필터링이 필요합니다. 대규모 시스템에서는 이러한 필터링 작업 자체가 상당한 노력이 필요하며, 필터링 과정만으로는 완전성을 검증할 수 없습니다. 예를 들어, 발신자가 다른 이름을 사용하는 경우 누락되었을 때 필터링된 결과 집합에는 누락에 대한 표시가 없습니다.

컴파일러 경고 및 @Deprecated 주석

최신 언어와 툴체인은 더 ​​이상 사용되지 않는 함수가 호출될 때 경고를 생성하는 사용 중단 주석 메커니즘을 제공합니다. 자바의 경우 @Deprecated 주석과 결합됨 -Xlint:deprecation 호출 지점에서 컴파일 시간 경고를 발생시킵니다. C#의 [Obsolete] `deprecated` 속성은 빌드 시점에 경고를 생성합니다. Go 언어에서는 사용되지 않는 함수에 이름을 지정하고 godoc에 문서화하는 규칙을 따르지만, 이러한 규칙은 자동으로 경고를 생성하지 않습니다. 이러한 메커니즘은 유용하지만 특정 방식으로 제한됩니다. 즉, 사용되지 않음을 알리는 주석이 달린 코드베이스를 대상으로 컴파일하는 호출자에게만 적용됩니다.

라이브러리의 이전 버전을 사용하는 발신자, 즉 해당 버전이 출시되기 이전 버전의 라이브러리를 사용하는 발신자 @Deprecated 어노테이션을 사용하는 호출자는 경고를 받지 않습니다. 소스 코드에서 컴파일하는 대신 바이너리 아티팩트를 사용하는 호출자도 경고를 받지 않습니다. 다른 언어로 작성된 호출자가 크로스 언어 인터페이스를 통해 호출하는 경우에도 경고를 받지 않습니다. 그리고 중요한 것은 컴파일 중에 발생하는 경고는 컴파일러의 관점에만 국한된다는 점입니다. 즉, 컴파일러가 인식하는 호출에 대한 경고일 뿐, 별도로 컴파일되는 다른 저장소의 호출에 대한 경고는 아닙니다. 다중 서비스 시스템에서 호출자 검색의 유일한 메커니즘으로 컴파일러 경고만 사용하는 것은 독립적으로 컴파일되는 모든 호출자를 놓치게 되는데, 이는 마이크로서비스 아키텍처에서 일반적인 상황입니다.

정적 분석 도구: 더 나아졌지만, 범위가 제한적입니다.

특정 언어에 특화된 정적 분석 도구는 해당 언어의 IDE보다 더 정확한 호출자 열거 기능을 제공하며, 여러 코드베이스를 인덱싱하도록 구성하면 저장소 경계를 넘나들며 분석할 수 있습니다. 이러한 도구는 텍스트 일치에 의존하는 대신 정확한 호출 그래프를 구축하고, IDE 검색보다 별칭 및 간접 호출을 더 효과적으로 처리하며, CI 파이프라인에서 실행하여 새로운 호출자가 추가될 때마다 이를 포착할 수 있습니다. 이는 현재 사용 가능한 단일 언어 분석 방법 중 가장 뛰어난 성능을 자랑합니다.

이러한 제약은 IDE를 제한하는 것과 동일한 범위 경계에서 비롯되지만, 이제는 도구 수준에서 발생합니다. Java 정적 분석 도구는 COBOL 프로그램을 인덱싱하지 않고, COBOL 분석 도구는 Java 서비스를 인덱싱하지 않으며, JCL 작업 스트림도 인덱싱하지 않습니다. 사용이 중단된 함수가 JCL 작업에서 호출되고 데이터 출력이 Java 서비스에서 소비되는 COBOL 프로그램에서 호출되는 COBOL 유틸리티인 시스템에서 각 정적 분석 도구는 호출 관계의 일부만 볼 수 있습니다. 필수적인 리팩토링 기법 의 맥락에서 살펴보면 , 드문 오류 조건과 대체 분기를 포함하여 특정 코드 섹션에 대한 모든 실행 경로를 식별하려면 단일 언어 도구로는 언어 경계를 넘어 구축할 수 없는 완전한 호출 그래프 매핑이 필요합니다.

완벽한 발신자 목록 작성을 위해 실제로 필요한 것

기업 시스템에서 더 이상 사용되지 않는 함수에 대한 완전한 호출자 목록은 검색 결과가 아닙니다. 이는 직접 경로, 간접 경로, 언어 간 경로, 동적 디스패칭 경로를 포함하여 해당 함수에 도달할 수 있는 모든 실행 경로를 구조적으로 열거한 것입니다. 이러한 열거를 구축하려면 여러 가지 기능이 필요한데, 표준 도구 하나로는 이러한 기능을 모두 제공할 수 없습니다.

통합된 언어 간 호출 그래프. 이 호출 그래프는 시스템 내 모든 언어를 포괄해야 합니다. JCL 프로시저에서 COBOL 프로그램으로의 호출, COBOL 프로그램에서 공유 유틸리티 단락으로의 호출, 그리고 미들웨어 인터페이스를 통해 Java 서비스에서 동일한 COBOL 프로그램으로의 호출은 모두 동일한 그래프의 노드와 에지가 되어야 합니다. 사용이 중단된 함수는 이 그래프의 노드이며, 호출자 열거는 시작 언어에 관계없이 모든 직접 및 간접 에지를 순회하는 것입니다.

전체 호출 그래프를 재귀적으로 탐색합니다. 직접 호출자는 첫 번째 계층일 뿐입니다. 완전한 목록을 작성하려면 간접 호출자, 래퍼 함수, 퍼사드 계층을 거쳐 호출 그래프를 따라 상류로 이동해야 합니다. 탐색이 자체적으로 호출자가 없는 함수, 즉 호출 체인의 진정한 진입점에 도달할 때까지 계속해야 합니다. 사용이 중단된 함수로 끝나는 경로의 모든 함수는 관련 의미에서 호출자입니다. 사용이 중단된 함수를 제거하면 해당 함수를 통과하는 모든 경로가 작동하지 않게 됩니다.

저장소 간 인덱싱. 호출 그래프에는 해당 함수를 호출할 가능성이 있는 모든 저장소의 코드가 포함되어야 하며, 공유 라이브러리 또는 패키지를 통해 해당 함수에 의존하는 저장소의 코드도 포함됩니다. 이를 위해서는 모든 저장소를 동시에 인덱싱하고 저장소 간 가져오기 관계를 해결하여 한 저장소의 호출을 다른 저장소의 정의와 연결해야 합니다.

간접 호출 패턴 탐지. 분석은 리플렉션, 동적 디스패치, 함수 포인터, 델리게이트 및 구성 파일의 문자열 기반 호출을 통해 이루어지는 호출을 식별해야 합니다. 이러한 호출은 직접적인 호출 경계 해결보다는 패턴 기반 탐지가 필요합니다. 즉, 코드에서 동적 디스패치 메커니즘을 찾아 어떤 조건에서 어떤 함수로 디스패치될 수 있는지를 파악해야 합니다.

활성 호출자와 테스트 전용 또는 비활성 호출자를 구분해야 합니다. 모든 호출자가 동일한 대응을 필요로 하는 것은 아닙니다. 사용이 중단된 함수 자체에 대한 테스트 픽스처에만 존재하는 호출자는 마이그레이션이 아닌 정리 작업의 일환으로 제거해야 합니다. 사용 분석을 통해 비활성 코드로 식별된 코드 내의 호출자는 함수 제거를 막는 요인이 아닙니다. 이러한 구분을 이해하려면 호출자 열거와 실제로 활성화된 코드 경로에 대한 정보를 결합해야 합니다. 정적 분석을 통한 비활성 코드 탐지 검토에서 자세히 설명했듯이 , 불완전한 문서화 또는 과거 종속성에 대한 불확실성으로 인해 도달할 수 없는 코드와 사용되지 않는 함수가 미션 크리티컬 시스템에서 수년 동안 남아 있을 수 있으므로, 사용이 중단된 함수의 호출자 목록에서는 활성 호출자와 비활성 호출자를 구분해야 합니다.

사용 중단에서 삭제로 이어지는 프로세스: 체계적인 접근 방식

더 이상 사용되지 않는 함수의 제거를 구조화된 프로세스가 아닌 단일 이벤트로 처리하는 것이 대부분의 호출자 발견 실패의 원인입니다. 올바른 접근 방식은 제거를 코드 삭제 훨씬 이전에 시작되는 다단계 프로세스의 최종 단계로 간주하는 것입니다.

1단계: 표시 및 측정

첫 번째 단계는 언어의 내장 메커니즘을 사용하여 해당 함수를 더 이상 사용하지 않는 함수로 표시하는 것입니다.@Deprecated 자바에서, [Obsolete] C#에서, #[deprecated] Rust 또는 그에 상응하는 언어로 작성된 해당 함수를 찾아 기준 호출 횟수를 설정합니다. 이 기준은 단일 검색의 결과가 아니라, 해당 함수를 호출할 가능성이 있는 모든 알려진 코드베이스를 인덱싱하고 결과를 계산한 결과입니다. 이 기준은 두 가지 목적을 수행합니다. 첫째, 마이그레이션 범위를 정량화하고, 둘째, 호출자가 마이그레이션됨에 따라 진행 상황을 측정할 수 있는 기준을 제공합니다.

기준선은 발신자 유형 및 위치별로 정리되어야 합니다.

발신자 카테고리	카운트	우선	대표이사
동일 저장소의 직접 호출자	N	높음	현재 팀
종속 서비스 분야의 직접 발신자	N	높음	서비스 소유자
래퍼 함수를 ​​통한 호출	N	중급	래퍼 소유자
생성된 코드 또는 프레임워크 코드의 호출자	N	중급	프레임워크 팀
테스트 전용 코드의 호출자	N	높음	현재 팀
통화가 끊긴 상태입니다.	N	청소만	현재 팀

2단계: 알림 및 마이그레이션

완벽한 발신자 목록을 확보하면 마이그레이션은 사후 대응이 아닌 체계적인 작업이 됩니다. 각 발신자 담당자는 "이 함수를 호출할 수 있습니다"가 아니라 "이 함수는 247번째 줄에서 호출됩니다"와 같이 구체적인 호출 위치를 알림으로 받게 됩니다. BillingService.java, 82번째 줄 AccountProcessor.java그리고 통합 테스트의 14번째 줄에서 BillingServiceTest.java"이처럼 구체적인 정보는 발신자 목록을 통해 얻을 수 있는 것이며, 일반적인 서비스 중단 경고로는 제공할 수 없는 것입니다."

알림과 함께 마이그레이션 경로를 제공하는 것은 필수적입니다. 사용 중단 공지에는 대체 기능에 대한 문서, 기존 구현과 새 구현 간의 동작 차이에 대한 설명, 그리고 변경 사항이 사소하지 않은 경우 변경 전후를 보여주는 코드 예제가 포함되어야 합니다. 다른 팀의 코드베이스를 참조하는 경우, 해당 팀들이 각자의 우선순위와 납기 일정을 가지고 있으므로 마이그레이션 일정은 일방적으로 발표하기보다는 명시적으로 협의해야 합니다. 종속 시스템 전반에 걸친 데이터베이스 리팩토링 사례에서 살펴본 바와 같이 , 기존 구조를 사용 중단하기 전에 새로운 구조를 사용하는 부분을 단계적으로 도입하는 것이 호환성을 깨뜨리는 변경 사항이 예기치 않은 문제로 나타나는 것을 방지하는 효과적인 방법입니다.

3단계: 통화량 모니터링

기준 측정 시점과 예정된 제거 시점 사이에 호출자 수를 지속적으로 모니터링해야 합니다. 호출자가 대체 함수로 이동할 때마다 호출자 수는 감소합니다. 활성 호출자의 수가 0이 되면 제거 시점에 도달한 것으로 간주합니다(테스트 전용 호출자 및 사용되지 않는 코드 호출자는 함수 자체와 동시에 제거될 수 있습니다). 지속적인 모니터링을 위해서는 코드 변경에 따라 최신 정보가 아니게 되는 일회성 인벤토리 방식이 아닌, CI 파이프라인의 일부로 정기적으로 호출자 열거를 실행해야 합니다.

모니터링 시스템은 사용 중단 기간 동안 추가되는 새로운 호출자도 감지합니다. 대규모 조직에서는 개발자가 사용 중단 사실을 인지하지 못했거나, 코드 검토에서 누락되었거나, 자동화된 코드 생성기가 사용 중단된 함수를 호출하는 코드를 생성하는 등 다양한 이유로 마이그레이션 기간 동안 사용 중단된 함수를 호출하는 새로운 코드가 작성되는 경우가 흔합니다. 새로운 호출 사이트에서 오류가 발생하도록 구성된 CI 수준의 사용 중단된 함수 호출자 감지 기능을 통해 마이그레이션이 진행되는 동안 호출자 수가 증가하는 것을 방지할 수 있습니다.

4단계: 제거 전 완전성 확인

해당 함수를 제거하기 직전에, 알려진 모든 코드베이스의 전체 범위를 대상으로 호출자 열거를 최종적으로 한 번 더 실행해야 합니다. 이 최종 검사는 안전장치 역할을 하며, 활성 호출자의 수가 0에 도달했는지 확인하고 CI 모니터링에서 포착되지 않은 후기 단계의 추가 사항을 식별합니다. 이 시점에서 동적 호출자가 없는지도 확인해야 합니다. 즉, 문자열로 함수를 참조하는 구성 파일, 리플렉션 기반 등록, 그리고 초기 분석에서 확인된 기타 간접 호출 메커니즘이 없는지 확인해야 합니다.

검증은 더 이상 사용되지 않는 함수를 노출하는 모든 공유 라이브러리 또는 패키지의 의존성 그래프까지 확장되어야 합니다. 해당 함수가 외부에서 사용하는 공개 API의 일부인 경우, 제거 일정에는 내부 코드 분석을 통해 접근할 수 없는 외부 사용자까지 고려해야 합니다. 내부 시스템의 경우, 검증은 색인화된 모든 코드베이스를 대상으로 합니다. 공개적으로 게시된 API의 경우, 검증은 알려진 사용자 집합과 외부 사용자가 마이그레이션해야 하는 특정 유예 기간을 포함하여 진행됩니다.

레거시 시스템과 메인프레임 환경에서 발신자 정보 검색 방식이 다른 이유

위에 설명된 문제점들은 모든 대규모 소프트웨어 시스템에 적용되지만, 특히 메인프레임 및 레거시 환경에서는 더욱 심각합니다. 왜냐하면 이러한 환경에서의 호출 관계는 최신 호출자 검색 도구가 분석하도록 설계되지 않은 메커니즘을 통해 표현되기 때문입니다.

COBOL 환경에서 함수는 CALL 문을 통해 호출되며, 호출 대상은 문자열 리터럴, 프로그램 이름이 포함된 데이터 항목, 또는 프로시저 포인터로 참조될 수 있습니다. 문자열 리터럴을 사용하는 경우는 정적 분석을 통해 해결할 수 있지만, 데이터 항목을 사용하는 경우는 호출 시점에 데이터 항목이 어떤 값을 가지고 있는지 파악하기 위해 데이터 흐름 분석이 필요하고, 프로시저 포인터를 사용하는 경우는 포인터의 할당 방식을 추적해야 합니다. 이러한 호출 메커니즘은 소스 코드에서 각각 다른 형태로 나타나며, 해결을 위해 필요한 분석 방법도 다릅니다.

JCL 환경에서 프로그램은 EXEC PGM= 문에서 이름으로 호출됩니다. 프로그램 이름은 로드 라이브러리의 컴파일된 모듈에 매핑되는 문자열입니다. JCL을 통해 COBOL 프로그램의 호출자를 추적하려면 JCL을 파싱하여 프로그램 이름을 추출하고, 해당 이름을 구현하는 컴파일된 COBOL 프로그램에 매핑하고, 해당 프로그램 내에서 어떤 COBOL 단락이 더 이상 사용되지 않는 유틸리티를 호출하는지 확인해야 합니다. 이러한 다단계 해결 과정은 COBOL 분석기나 JCL 분석기가 단독으로 수행할 수 있는 범위를 완전히 벗어납니다.

공유 카피북은 COBOL 환경에서 특히 중요한 문제입니다. 카피북에 정의된 더 이상 사용되지 않는 단락이 COPY 문을 통해 여러 프로그램에 포함될 수 있습니다. 이 단락은 각 프로그램에 물리적으로 복제되는 것이 아니라 컴파일 시점에 포함됩니다. 카피북 포함 여부를 고려하지 않고 소스 파일에서 단락 이름의 발생 횟수를 세는 분석은 카피북 자체에서 단락 정의를 찾아 과대 계산하거나, 카피북을 포함하는 모든 프로그램이 해당 단락에 접근할 수 있다는 사실을 놓쳐 과소 계산하는 두 가지 오류를 모두 발생시킵니다. 정확한 호출자 파악을 위해서는 어떤 프로그램이 어떤 카피북을 포함하고, 해당 카피북 내의 어떤 단락을 실제로 호출하는지 이해해야 합니다. 하드코딩된 참조와 그 하위 프로그램 간의 관계는 구조적 변경 전에 이러한 프로그램 수준의 호출 관계를 파악하는 것이 왜 중요한지 보여줍니다. 단순해 보이는 문자열 참조가 수십 개의 프로그램이 핵심 기능을 수행하는 유일한 메커니즘일 수 있기 때문입니다.

방법 SMART TS XL 발신자 정보 전체를 구축합니다.

SMART TS XL 인덱싱된 환경 내의 모든 언어, 플랫폼 및 저장소에 걸쳐 통합된 호출 그래프를 구축합니다. COBOL 프로그램, JCL 작업 스트림, Java 서비스, .NET 애플리케이션, SQL 저장 프로시저, Python 스크립트 및 기타 소스 아티팩트는 모두 언어별 분석을 사용하여 공통 상호 참조 그래프로 파싱됩니다. 각 함수, 단락, 프로시저, 메서드 및 프로그램 단위는 해당 그래프의 노드입니다. COBOL CALL 문, Java 메서드 호출, JCL EXEC PGM 또는 SQL EXEC와 같은 각 호출 관계는 유형이 지정된 에지입니다. 이 그래프는 언어별 부분적인 보기가 아닌 시스템의 전체 호출 토폴로지를 나타냅니다.

함수가 삭제 대상으로 표시되면, SMART TS XL호출자 열거는 대상 함수 노드에서 들어오는 호출 그래프를 순회하며 호출 계층 구조의 모든 레벨에 있는 모든 호출자를 수집합니다. 이 순회는 재귀적으로 이루어지며, 래퍼 함수, 퍼사드 레이어, 중간 유틸리티를 거쳐 호출자가 없는 함수, 즉 호출 체인의 실제 진입점에 도달할 때까지 그래프를 따라갑니다. 결과는 언어, 저장소, 호출자 유형 및 호출 깊이별로 정리되어 팀에게 직접 호출자와 간접 호출자, 활성 호출자와 비활성 호출자를 구분하는 구조화된 목록을 제공합니다.

플랫폼의 영향 분석 기능은 이를 구조화된 변경 영향 보고서로 확장합니다. 이 보고서는 단순히 어떤 함수가 더 이상 사용되지 않는 함수를 호출하는지뿐만 아니라, 종속성 체인의 모든 수준에서 어떤 프로그램, 서비스, 배치 작업 및 JCL 프로시저가 영향을 받는지까지 보여줍니다. 이 보고서는 사용 중단에서 제거로의 전환 프로세스를 실행 가능하게 만드는 핵심 자료입니다. 보고서에는 담당자 이름, 특정 호출 위치, 그리고 제거를 안전하게 진행하기 전에 필요한 마이그레이션 범위가 명시되어 있습니다. 기업 변경 관리의 영향 분석 에 대한 자세한 내용에서 살펴보았듯이 , 구조적 변경을 수행하기 전에 영향을 받는 구성 요소를 열거하는 능력은 복잡하고 상호 연결된 기업 시스템의 안전한 운영을 위한 필수적인 요구 사항입니다.

SMART TS XL 또한, 사용 중단 프로세스의 지속적인 모니터링 단계도 지원합니다. 소스 코드 변경 사항이 인덱싱됨에 따라 상호 참조 그래프가 지속적으로 업데이트되므로, 사용 중단된 함수의 호출 횟수는 항상 최신 상태로 유지됩니다. CI 파이프라인 통합을 통해 자동화된 검사가 사용 중단된 함수에 대한 새로운 호출을 실패로 처리하여, 사후에 위반 사항을 발견하는 대신 새 코드가 도입되는 시점에 마이그레이션 규정을 준수하도록 합니다. 이러한 초기 열거, 마이그레이션 지침 및 지속적인 모니터링의 조합은 어노테이션 추가부터 안전한 제거에 이르기까지 사용 중단된 함수의 전체 수명 주기를 포괄합니다.

기능 삭제, 후회 없이

함수 제거가 원활하게 진행되는 경우와 운영 환경에서 오류를 발생시키는 경우의 차이는 거의 항상 호출자 정보 수집의 완성도 차이에서 비롯됩니다. 제거 자체는 간단합니다. 정의를 삭제하고 배포하면 됩니다. 하지만 준비 과정에서 어려움이 발생하며, 이 준비는 호출자 인벤토리의 정확성에 따라 결과가 좌우됩니다.

호출 그래프가 단순하고, 단일 언어로 작성되었으며, 단일 저장소 내에 포함된 시스템에서는 IDE의 호출 계층 구조와 컴파일러 경고만으로도 충분한 준비가 됩니다. 하지만 호출 그래프가 여러 언어, 여러 저장소, 여러 플랫폼, 그리고 잠재적으로 수십 년에 걸친 코드에 걸쳐 있는 시스템에서는 이러한 도구들이 실제 호출자의 극히 일부분만을 파악할 수 있을 뿐입니다. 이러한 도구들이 반환하는 값과 실제로 함수를 호출하는 코드 사이의 간극이 바로 프로덕션 환경에서의 오류 발생 원인이 됩니다.

특정 목적에 맞게 설계된 언어 및 저장소 간 호출자 열거는 함수 제거를 위한 개발자 워크플로의 개선 사항이 아닙니다. 오히려 엔터프라이즈 코드베이스에서 흔히 볼 수 있는, 시스템 간 호출 관계가 복잡하게 얽혀 있는 시스템에서 해당 워크플로를 안전하게 실행하기 위한 필수 조건입니다. 완전한 호출자 목록 없이 제거된 모든 사용 중단 함수는 누락된 정의에 도달하는 특정 실행 경로를 기다리는 동안 알 수 없는 수의 런타임 오류를 포함하는 릴리스입니다. 이러한 불확실성을 제거하는 것이 바로 구조화된 호출자 검색의 목적입니다.