질문에 대한 답변
Go의 링크는 프로그램의 진입점인 main.main과 모든 패키지 init 함수에서 시작하는 의존성 그래프를 생성하는 도달 가능성 분석 알고리즘을 통해 불필요한 코드 제거를 수행합니다. 호출 그래프를 탐색하며 정적으로 참조되는 모든 함수와 전역 변수를 표시한 후, 최종 바이너리를 작성하기 전에 표시되지 않은 기호를 버립니다. 이 과정은 보수적입니다. 함수의 주소가 취해져 인터페이스에 저장되거나, reflect.Value.Call에 전달되거나, 어셈블리 코드나 //go:linkname 지시어를 통해 참조되는 경우, 링크는 해당 함수가 런타임에 호출되지 않음을 증명할 수 없기 때문에 이를 유지해야 합니다. 또한, CGO로 내보낸 함수와 리플렉션 기반 디코딩을 위해 등록된 메서드(예: json.Unmarshal가 구체적인 타입으로 동적으로 분배되는 **interface{}**로의 디코딩)는 사실상 도달 불가능한 코드 경로의 유지 강제를 초래할 수 있습니다. 이 최적화는 기본적으로 활성화되어 있으며, 패키지 간에 작동하므로 외부 종속성의 사용하지 않는 코드가 애플리케이션의 도달 가능한 코드에서 참조가 없을 경우 제거될 수 있습니다.
생활 속 상황
하나의 플랫폼 팀은 포괄적인 관측 가능성 라이브러리를 도입한 후 CLI 툴의 크기가 47MB로 급증했음을 발견했습니다. 이 라이브러리는 여러 개의 텔레메트리 백엔드를 지원했지만(제이거, 집킨, 프로메테우스), 서비스는 오직 프로메테우스 메트릭만 내보냈습니다. 문제는 라이브러리의 단일 아키텍처 때문이었습니다. 패키지를 가져오면 모든 백엔드에 대한 전역 레지스트리를 초기화하여 카프카 클라이언트 및 gRPC 라이브러리와 같은 고비용 종속성을 끌어오기 때문에 실제로는 사용되지 않았습니다.
첫 번째 고려 해결책은 사용하지 않는 백엔드를 제거한 라이브러리의 포크를 수동으로 유지하는 것이었습니다. 이 방법은 죽은 코드 제거를 보장하지만, 수동 보안 패치 및 상위와의 병합 충돌 해결을 요구하기 때문에 받아들일 수 없는 유지 관리 부담을 유발했습니다.
두 번째로 시험한 접근 방법은 바이너리에 UPX 압축을 적용하여 크기를 13MB로 줄이는 것이었습니다. 그러나 이는 런타임 압축으로 인해 상당한 시작 지연을 초래하여 기업용 안티바이러스 스캐너에서 잘못된 긍정 피험자를 유발하여 생산 환경 배포에 적합하지 않았습니다.
세 번째 옵션은 디버그 정보와 기호 테이블을 제거하기 위해 **ldflags="-s -w"**를 사용하는 것이었습니다. 이렇게 하더라도 사용하지 않는 백엔드 구현이 바이너리에 남아 있어 기계 코드 부풀리기를 해결하지 못해 3MB의 감소만 얻었습니다.
팀은 문제가 있는 가져오기를 피하도록 코드를 재구성하기로 결정했습니다. 그들은 핵심 애플리케이션에서 최소한의 메트릭 인터페이스를 정의한 다음 구체적인 프로메테우스 구현을 main에만 가져오는 하위 패키지로 이동했습니다. 이렇게 하면 사용하지 않는 집킨 및 제이거 코드 경로가 main.main이나 init 함수에서 도달 가능한 기호로써 참조되지 않도록 보장되었습니다. 또한, 그들은 백엔드 생성자를 우발적으로 유지할 수 있는 reflect.Type 메서드 탐색이 없도록 감사했습니다. 이번 아키텍처 변경을 통해 Go의 링크가 공격적인 트리 쉐이킹을 수행할 수 있게 되었습니다.
그 결과는 외부 압축 없이 9MB로 감소되었고, CI 아티팩트 업로드 속도 향상 및 컨테이너 시작 시간이 단축되었으며, 패치를 하지 않고도 관측 가능성 라이브러리를 업그레이드할 수 있는 능력을 유지하게 되었습니다.
후보자들이 자주 간과하는 사항
이 진단에서 if false와 같은 컴파일 시 상수 거짓 조건으로 둘러싸인 코드 블록 내에서만 참조되는 함수가 링크에 의해 유지되는 이유는 무엇인가?
Go의 링크는 함수 내의 기본 블록 레벨이 아니라 기호 의존성 레벨에서 작동합니다. 컴파일러의 SSA(정적 단일 할당) 최적화 성정에서는 if false와 같은 죽은 분기를 제거할 수 있지만, 해당 분기를 포함한 함수 자체가 도달 가능하면, 그 함수가 직접 호출하고 있는 모든 함수(조건 논리를 통해서는 아님)가 개체 파일에서 참조 엣지를 생성합니다. 더 중요한 것은 패키지가 가져와지면 그 init 함수는 항상 도달 가능성 그래프의 루트로 간주됩니다. 따라서 init 함수에 의해 호출된 모든 함수는 애플리케이션에서 패키지의 공개 API가 사용되었는지에 관계없이 유지됩니다. 개발자들은 사용하지 않는 가져오기가 무해하다고 가정하지만, 이러한 가져오기가 무거운 초기화를 수행할 경우 바이너리를 크게 증가시킬 수 있습니다.
함수의 주소를 &fn으로 취하는 것이 직접적으로 호출하는 것과 비교해 죽은 코드 제거에 어떤 영향을 미치며, 이는 콜백 레지스트리에서 예상치 못한 바이너리 크기 증가를 초래할 수 있는 이유는 무엇인가?
함수의 주소가 취해져 패키지 초기화 시 전역 변수나 데이터 구조에 저장되는 경우(예: var defaultHandler = &unusedFunction), 링크는 unusedFunction을 도달 가능하게 표시해야 합니다. 그 이유는 할당이 링크가 동적 사용과 구별할 수 없는 정적 데이터 참조를 생성하기 때문입니다. 직접적인 함수 호출과 달리, 호출되는 함수가 도달 불가능해지면 제거할 수 있지만, 주소 취득은 바이너리의 데이터 섹션에 지속적인 참조를 만듭니다. 이는 패키지 레벨 map[string]func() 변수를 사용하는 플러그인 시스템이나 HTTP 핸들러 레지스트리를 구현하는 개발자를 놀라게 만드는 경우가 많습니다. 맵에 추가된 모든 함수는 맵이 결코 접근되지 않더라도 죽은 코드 제거를 견뎌야 합니다.
//go:linkname 지시어가 기호 유지에 미치는 영향은 표준 내보낸 함수와 어떻게 다르며, 내부 표준 라이브러리 함수에 대한 링크가 전체 패키지의 제거를 방지하는 이유는 무엇인가?
//go:linkname 지시어는 패키지 A가 패키지 B의 기호를 링크의 기호 이름을 사용하여 참조할 수 있도록 합니다. 빌드의 모든 패키지에서 //go:linkname 지시어의 대상이 되는 기호는 링크가 도달 가능성 그래프의 루트로 간주합니다. 이는 지시어가 패키지 경계를 넘어 홍보되지 않은 함수에 접근하기 위해 runtime 및 표준 라이브러리에서 자주 사용되기 때문입니다(예: runtime가 syscall 내부를 호출). 일반적으로 내보낸 함수는 main이나 init로부터 전이적 호출 경로가 있을 때만 유지됩니다. 반면 linkname 대상은 지시가 담긴 패키지가 애플리케이션에 의해 전혀 가져와지지 않더라도 생존합니다. 따라서 내부 표준 라이브러리 기호에 링크하는 사용자 코드는 링크가 없던 부분의 runtime 또는 syscall 패키지를 유지하게 되어 자의적으로 제거될 수 있습니다.