25GB 바이너리, 과연 괜찮을까?
대규모 코드베이스를 정적 링크 방식으로 빌드하면서 바이너리 크기가 기하급수적으로 증가하는 현상에 대한 문제 제기
LTO (Link Time Optimization), Dead Code Elimination과 같은 기술을 활용하여 바이너리 크기를 줄이는 방안 제시 및 -mcmodel=large 옵션의 동작 방식에 대한 논의
일부 개발자는 대규모 바이너리 문제를 인지하지 못하는 현실을 지적하며, 규모에 맞는 기술 선택의 중요성을 강조
대규모 바이너리 문제의 근본 원인
대규모 바이너리는 정적 링크 방식과 디버그 심볼을 포함하는 경우에 주로 발생한다. 구체적으로, 모든 코드를 하나의 실행 파일에 포함시키면서 코드 중복, 불필요한 코드까지 포함되는 경우가 많다. 따라서, 빌드 프로세스 최적화를 통해 바이너리 크기를 줄이는 것이 중요하다.
바이너리 크기 최적화를 위한 기술적 접근
바이너리 크기를 줄이기 위해 LTO (Link Time Optimization)를 활용하여 링킹 단계에서 Dead Code Elimination을 수행하는 것이 효과적이다. 반면, `-mcmodel=large` 옵션은 상대적인 `CALL` 명령어를 절대적인 `JMP`로 변경하는 방식으로 동작하지만, 실제 어셈블리 코드에서는 다른 방식으로 최적화될 수 있다. 결과적으로, 빌드 설정과 컴파일러 옵션의 이해가 중요하다.
실제 서비스 적용 가이드
대규모 바이너리 문제를 해결하기 위해 마이크로서비스 아키텍처로의 전환을 고려해 볼 수 있다. 구체적으로, 하나의 거대한 애플리케이션을 여러 개의 작은 서비스로 분리하여 각 서비스의 독립적인 배포와 확장성을 확보할 수 있다. 따라서, 코드베이스 분할과 서비스 간 통신 설계를 신중하게 고려해야 한다.
