기술 지원
문서
로그인
문의하기
- 애플리케이션은 일반적으로 특정 Linux 배포판에서 작동하도록 테스트 및 보장되지만 다른 배포판에서도 작동할 수 있습니다.
- 커널 버전, 라이브러리 및 시스템 호출은 배포판 간의 바이너리 호환성에 영향을 미치는 주요 요소입니다.
- 운영 체제의 ABI(애플리케이션 바이너리 인터페이스)의 차이도 호환성 문제의 빈번한 원인입니다.
바이너리 호환성은 종종 간과되는 필수적인 기술 개념이지만 프로그램을 다양한 플랫폼에 배포하는 데 중요한 역할을 합니다. 하지만 다양한 Linux 배포판이 존재하기 때문에 Linux 개발자에게는 상당한 도전 과제입니다.
이 글에서는 바이너리 호환성이란 무엇인지 자세히 살펴보고 다양한 맥락에서 바이너리 호환성을 살펴봅니다. 또한 Linux 배포판에서 바이너리 호환성이 구체적으로 무엇을 의미하는지에 대해서도 논의할 것입니다.
바이너리 호환성이란 무엇인가요?
우선 개발에서 '바이너리'라는 용어는 컴파일된 실행 코드를 의미합니다. 기본적으로 개발자는 C 또는 C++와 같은 고급 프로그래밍 언어로 코드를 작성한 다음 컴파일러를 통해 소스 코드를 실행하여 기계가 읽을 수 있는 실행 코드를 생성합니다. 결과 파일을 바이너리라고 합니다.
바이너리는 특정 컴퓨팅 환경에 맞게 컴파일되므로, 예를 들어 Linux OS용으로 컴파일된 바이너리는 Windows OS에서 실행할 수 없습니다. 사소한 환경 차이는 바이너리 호환성을 방해하지 않을 수 있지만, 큰 차이는 실행 실패를 초래할 수 있습니다.
한 환경에서 바이너리로 컴파일된 소스 코드가 다른 환경에서도 완벽하게 실행된다면 두 컴퓨팅 환경은 바이너리 호환성이 있는 것입니다. 즉, 개발자가 다른 환경에서 코드를 성공적으로 실행하기 위해 코드를 다시 컴파일할 필요가 없습니다.
바이너리 호환성이 중요한 이유는 무엇인가요?
바이너리 호환성의 중요성은 두 가지 관점에서 살펴볼 수 있습니다. 하나의 특정 목적을 위해 소프트웨어를 개발하는 경우 환경 변화에 대응하기 위해 대규모 코드베이스를 다시 컴파일할 필요를 피하고 싶을 것입니다.
다른 관점에서 보면 특정 운영 체제에서 테스트된 상용 소프트웨어를 사용하고 있을 수 있으며, 해당 운영 체제의 변형(예: 다른 Linux 배포판)에서 작동하거나 작동하지 않을 수도 있습니다. 코드를 다시 컴파일할 수 없으며, 사용 중인 환경이 공급업체가 프로그램을 테스트하는 데 사용한 환경과 다를 수 있습니다.
재컴파일 문제
재컴파일은 경우에 따라 실행 가능한 솔루션이지만, 여러 환경에 맞춰야 하는 복잡한 애플리케이션을 다룰 때는 실용적이지 않을 수 있습니다. 이러한 시나리오에서 반복적인 재컴파일은 시간이 많이 걸리고 어려울 수 있으며, 전문 기술이 필요한 경우가 많습니다.
다른 환경에서 바이너리 호환성이 부족한 경우 몇 가지 문제가 발생할 수 있습니다. 이러한 문제에는 다른 위치에 있는 파일이나 약간 다른 라이브러리가 포함될 수 있습니다. 따라서 새 환경에서 새 바이너리가 올바르게 작동하도록 하려면 상당한 시간과 노력, 전문 지식이 필요합니다.
특히 기본 아키텍처나 플랫폼이 변경된 경우 재컴파일을 하면 원래 버전에는 없던 새로운 버그나 오류가 발생할 수도 있습니다. 또한 재컴파일은 특히 자체 개발한 맞춤형 소프트웨어 솔루션을 사용하는 조직의 경우 비용이 많이 들 수 있습니다.
바이너리 호환성으로 재컴파일 필요성 제거
대체 환경이 바이너리 호환이 가능하다는 것을 알면 자체 개발했든 공급업체에서 제공했든 컴파일된 실행 파일이 대상 환경에서 원활하게 작동할 것이라는 확신을 가질 수 있습니다. 종속 코드에 대한 수정 없이 소프트웨어 업데이트를 가능하게 함으로써 재컴파일의 필요성을 줄여줍니다. 따라서 귀중한 시간과 리소스를 절약하고 소프트웨어 업데이트 프로세스를 간소화할 수 있습니다.
그러나 다양한 상황에서 바이너리 호환성에 대한 우려가 제기될 수 있습니다. 예를 들어, 새 버전의 운영 체제가 출시되면 기존 애플리케이션이 계속 원활하게 작동할 수 있는지, 즉 OS가 바이너리 호환이 가능한지에 대한 의문이 생깁니다.
마찬가지로 조직에서 선호하는 OS가 단종 단계에 이르렀다고 가정해 보겠습니다, CentOS 8. 이 경우, 대체 바이너리 호환 가능한 대체 바이너리 호환 OS 재컴파일이나 애플리케이션 전환의 필요성을 피하기 위해 사용할 수 있는 대체 바이너리 호환 OS를 확보하는 것이 중요합니다. 따라서 조직의 OS 전략을 검토할 때 바이너리 호환성을 고려하는 것이 필수적입니다.
Linux에서 바이너리 호환성 이야기
Linux는 무료로 제공되는 오픈 소스 운영 체제로, 배포판 또는 "배포판"으로 알려진 여러 가지 버전이 있습니다. 각 Linux 배포판은 종종 특정 용도로 사용됩니다. 예를 들어 우분투는 데스크톱용으로 널리 사용되고, AlmaLinux와 Red Hat Enterprise Linux(RHEL)는 기업용이며 안정성과 보안으로 유명하며, 칼리 Linux는 사이버 보안 전문가를 위해 맞춤화되어 있습니다.
각 배포판에는 고유한 기능과 구성이 포함되어 있기 때문에 개발자에게 호환성 문제가 발생할 수 있습니다. 한 배포판용으로 설계된 소프트웨어가 다른 배포판에서 원활하게 실행되려면 추가 수정이나 구성이 필요할 수 있습니다. 커널 버전, 라이브러리, 시스템 호출 등 몇 가지 주요 요소가 한 시스템용으로 컴파일된 바이너리가 다른 시스템에서 성공적으로 실행될 수 있는지 여부에 영향을 줍니다.
Linux 배포판마다 환경이 크게 달라서 한 배포판에서 실행되는 패키지가 다른 배포판에서 작동하지 않을 수 있습니다. 잘 알려진 Linux 배포판인 우분투에서 애플리케이션을 만들었다고 가정해 보겠습니다. 하지만 Red Hat Enterprise Linux나 Fedora와 같은 다른 배포판에서 애플리케이션을 실행하려는 경우 시스템 라이브러리 또는 기타 종속성 부족으로 인해 어려움을 겪을 수 있습니다.
운영 체제의 차이점 ABI (애플리케이션 바이너리 인터페이스)의 차이도 호환성 문제의 빈번한 원인입니다. ABI는 시스템의 다양한 구성 요소가 상호 작용하는 방식을 지정하며, ABI를 변경하면 다른 버전의 운영 체제에서 컴파일된 소프트웨어를 실행하려고 할 때 호환성 문제가 발생할 수 있습니다. 이러한 비호환성은 소프트웨어 개발자에게 심각한 장애물이 될 수 있으며, 다양한 배포판에서 애플리케이션을 운영하는 데 제한을 줄 수 있습니다.
많은 Linux 배포판은 바이너리 호환성을 목표로 하지만 모든 배포판에서 바이너리 호환성이 보장되는 것은 아닙니다. 그러나 일부 Linux 배포판은 특정 에코시스템 내에서 바이너리 호환성을 보장하며, 수수료 할인 또는 무료와 같은 다른 혜택도 함께 제공합니다. 예를 들어, AlmaLinux 및 Rocky Linux는 RHEL의 바이너리 호환성을 대체하도록 설계된 무료 오픈 소스 배포판입니다. 이러한 호환성은 RHEL용으로 구축된 애플리케이션이 이러한 대체 배포판에서 작동할 가능성이 높다는 것을 의미하며, 소프트웨어의 접근성을 확장하고 더 많은 사용자에게 도달 범위를 넓힐 수 있습니다. 이 요소는 다양한 Linux 배포판에서 애플리케이션의 이식성 및 접근성에 영향을 미칠 수 있으므로 매우 중요합니다. 이 문제를 극복하기 위해 개발자는 Linux 바이너리 호환성을 고려해야 합니다.
Linux 바이너리 호환성의 두 가지 측면
Linux 배포판의 바이너리 호환성은 두 가지 주요 방향에서 중요하다는 점에 유의하는 것이 중요합니다. 첫 번째 방향은 서로 다른 두 배포판 간의 바이너리 호환성과 관련이 있습니다. 예를 들어 Ubuntu는 본질적으로 데비안에서 파생되었지만 Ubuntu에 적용된 변경 사항으로 인해 데비안용으로 제작된 패키지가 반드시 Ubuntu에서 작동하지 않을 수 있습니다.
이와는 대조적으로, CentOS와 Oracle Linux는 모두 RHEL과 애플리케이션 바이너리 호환이 가능합니다. 즉, 애플리케이션이 RHEL용으로 개발되고 인증된 경우 CentOS 및 Oracle Linux에서도 작동할 준비가 된 것입니다.
하지만 Linux 배포판은 Linux 커널 및 기타 여러 구성 요소를 공유하기 때문에 두 배포판이 바이너리 호환성이 부족하더라도 특정 패키지는 두 배포판 모두에서 작동할 수 있습니다.
고려해야 할 또 다른 요소는 한 배포 버전에서 다음 버전으로의 바이너리 호환성입니다. 일반적으로 일반적인 Linux 배포판의 버전 9는 버전 8과 바이너리 호환성을 유지할 것으로 예상됩니다. 그러나 어느 시점에서 배포판에 향상된 기능을 통합하기 위해 바이너리 호환성이 손상될 수 있습니다.
애플리케이션 호환성을 확인하려면 공급업체 또는 커뮤니티에서 제공하는 릴리스 지침을 참조하는 것이 좋습니다. 이 지침은 애플리케이션 호환성 검토가 필요한지 또는 업그레이드할 버전이 바이너리 호환이 가능한지 여부에 대해 필요한 보증을 제공합니다. 후자의 경우 운영 체제를 업그레이드해도 애플리케이션의 정상적인 기능에 지장을 주지 않습니다.
사례 연구: 알마리눅스와 RHEL의 이야기
애플리케이션은 일반적으로 특정 Linux 배포판에서만 작동하도록 테스트되고 보장됩니다. 상용 소프트웨어 공급업체는 높은 가격대가 책정된 Red Hat Enterprise Linux(RHEL) 또는 Oracle Linux와 같은 엔터프라이즈급 Linux 배포판에 집중하는 경향이 있습니다. 개발자는 Linux 배포판에 상당한 금액을 지불할 의향이 있는 사람들이 소프트웨어에 대해서도 비용을 지불할 가능성이 높다고 가정하여 상용 배포판에서 소프트웨어를 테스트하고 인증할 수 있습니다.
그러나 일부 조직에서는 비용이나 종속성 등 다양한 이유로 엔터프라이즈 Linux 배포판을 채택하고 싶지 않을 수 있습니다. 이러한 경우 AlmaLinux와 같이 잘 알려진 예를 포함하여 바이너리 호환 Linux 배포판이 유용합니다. 이러한 배포판은 엔터프라이즈급 Linux 배포판과의 바이너리 호환성을 제공하여 사용자가 비용을 지불하지 않고도 이러한 배포판용으로 설계된 애플리케이션을 실행할 수 있도록 하는 것을 목표로 합니다.
처음에 AlmaLinux는 1:1 바이너리 호환성을 목표로 RHEL과 거의 동일한 클론으로 포지셔닝했습니다. 즉, RHEL용으로 컴파일된 애플리케이션은 별도의 수정 없이 AlmaLinux에서 원활하게 실행될 수 있었습니다. 그러나 다음과 같이 상황이 바뀌었습니다. Red Hat이 변경하면서 환경이 바뀌었습니다. 이로 인해 AlmaLinux는 전략을 재평가해야 했습니다. 바이너리 호환성을 유지하는 것이 여전히 우선 순위로 남아 있었지만, 초점은 ABI 호환성으로 옮겨졌습니다. ABI 호환성은 애플리케이션이 수정 없이 실행될 수 있도록 보장하지만 동일한 소스 코드 또는 패키지 관리를 보장하지는 않습니다.
또 다른 예로 Red Hat에서 출시한 무료 배포판인 CentOS는 엔터프라이즈 중심의 모기업과 완벽한 바이너리 호환성을 약속합니다. 즉, 엔터프라이즈 애플리케이션이 RHEL용으로 개발되었다면 CentOS에서도 실행될 수 있습니다. 하지만 2020년 12월, Red Hat은 RHEL의 수명 종료 의 수명을 종료한다고 발표하면서 많은 사용자가 우려를 표했습니다. 이를 해결하기 위해 TuxCare 는 CentOS의 수명을 의 수명을 최소 4년 더 연장하여 새로운 취약점에 대한 보안 패치를 제공하기로 했습니다.
바이너리 호환성은 도움이 되지만, 있다고 가정하지 마세요.
포함된 패키지의 변경 가능 범위를 제한하더라도 Linux 배포판의 바이너리 호환성을 유지하는 것은 여러 면에서 그 자체로 가치 있는 목표입니다.
반면에 Linux 배포판은 일반적으로 바이너리 호환이 되지 않습니다. Linux 배포판의 복잡성을 고려할 때 바이너리 호환성은 자체 코드를 구축하든 공급업체에서 구입하든 관계없이 반드시 알고 있어야 하는 사항입니다.
그럼에도 불구하고 일부 배포판은 바이너리 호환이 가능하므로 기업용 배포판보다 비용을 절약하고 싶거나 다른 배포판으로 전환해야 하는 경우 선택의 폭이 넓습니다.
마무리
바이너리 호환성은 개발자가 수정 없이 다양한 플랫폼에서 작동할 수 있는 소프트웨어를 만들 수 있기 때문에 소프트웨어 개발에 필수적입니다. 이 기능은 개발자가 더 많은 사용자층이 소프트웨어를 사용할 수 있도록 하는 데 큰 도움이 됩니다. 그러나 다양한 아키텍처와 운영 체제를 다루는 Linux에서는 바이너리 호환성을 달성하는 것이 어려울 수 있습니다.
그 결과 개발자는 각 Linux 배포판마다 애플리케이션의 버전을 따로 만들어야 했습니다. 이 프로세스는 시간이 많이 걸리고 비효율적이며, 사용자가 애플리케이션을 실행할 특정 배포판을 선택해야 하므로 애플리케이션의 접근성이 제한됩니다.
