백포팅

1. 개요

백포팅은 최신 버전의 소프트웨어에서 개발된 기능을 이전 버전의 소프트웨어에 적용하는 기술이다. 일반적으로 문제 식별, 수정 사항 확인, 백포팅 적용, 품질 관리 및 테스트, 패치 배포의 단계를 거친다. 백포팅은 폐쇄형 소프트웨어에서는 소스 코드 접근의 필요성 때문에 유일한 수정 방법이며, 오픈 소스 소프트웨어에서는 소프트웨어 배포자에 의해 생성되어 업스트림으로 전송되기도 한다. 백포팅은 윈도우 XP, 데비안, 우분투, 윈도우 95 등 다양한 운영 체제 및 소프트웨어에 적용된 사례가 있다.

2. 절차

백포팅 절차는 크게 다음 단계로 나눌 수 있다.

1. 백포팅을 통해 수정해야 할 구 버전 소프트웨어의 문제 식별
2. 문제를 해결한 (보통 최신) 코드 수정 사항 파악
3. 오래된 코드 상황에 맞게 수정 사항 적용 (적절한 백포팅)
4. 백포팅된 버전이 이전 기능을 유지하고 새로운 기능을 제대로 구현하는지 확인하는 품질 관리 수준 테스트

일반적으로 여러 개의 이러한 수정 사항은 패치 세트로 묶인다.

백포트는 소프트웨어의 핵심 소프트웨어 개발자 그룹에서 제공할 수 있다. 백포팅은 소프트웨어 소스 코드에 대한 접근이 필요하기 때문에, 이는 폐쇄형 소프트웨어에 대한 백포팅이 이루어지는 유일한 방법이며, 백포트는 일반적으로 소프트웨어의 구 버전 라인에 따라 바이너리 업그레이드에 통합된다. 오픈 소스 소프트웨어의 경우, 백포트는 때때로 소프트웨어 배포자에 의해 생성된 다음 업스트림 (즉, 해당 소프트웨어의 핵심 개발자에게 제출)으로 전송된다.

2.1. 문제 식별

백포팅의 가장 간단하고 일반적인 상황은 최신 버전의 소프트웨어에서 수정된 보안 취약점이다. 다음의 간단한 예를 통해 문제 식별 단계를 설명한다.

* 소프트웨어 v2.0에는 'is_unsecured' 텍스트를 'is_secured'로 변경하면 해결되는 보안 취약점이 있었다.
* 최신 버전의 코드베이스가 파생된 소프트웨어 v1.0에도 동일한 보안 취약점이 존재하지만, 해당 텍스트는 'is_notsecure'로 표시될 수 있다.

이 예시에서 소프트웨어 v1.0에 존재하는 'is_notsecure' 텍스트는 보안 취약점을 나타내는 문제점으로 식별될 수 있다. 즉, 이전 버전(v1.0)에서 수정해야 할 대상으로, 백포팅이 필요한 문제 상황임을 알 수 있다.

2.2. 수정 사항 확인

백포팅의 가장 간단하고 일반적인 상황은 최신 버전의 소프트웨어에서 수정된 보안 취약점이다. 다음의 간단한 예를 고려할 수 있다.

* 소프트웨어 v2.0에는 'is_unsecured' 텍스트를 'is_secured'로 변경하면 해결되는 보안 취약점이 있었다.
* 최신 버전의 코드베이스가 파생되는 소프트웨어 v1.0에도 동일한 보안 취약점이 존재하지만 텍스트가 'is_notsecure'로 표시될 수 있다.

소프트웨어 v2.0을 수정하는 수정 사항을 취하고 이를 소프트웨어 v1.0에 적용하도록 변경함으로써 수정 사항을 효과적으로 백포팅했다.

실제 상황에서 소프트웨어의 단일 측면에 대한 수정은 단순할 수도 있고(코드 몇 줄만 변경됨) 무겁고 대규모일 수도 있다(많은 수정이 코드의 여러 파일에 분산됨). 후자의 경우 백포팅은 지루하고 비효율적일 수 있으며 최신 버전을 선호하기 위해 이전 버전의 소프트웨어가 실제로 필요한 경우에만 수행해야 한다(예를 들어 최신 버전이 여전히 임무에서 사용할 수 없는 안정성 문제를 겪고 있는 경우).

백포팅 프로세스는 대략 다음 단계로 나눌 수 있다.

# 백포트로 수정해야 하는 이전 버전의 소프트웨어 문제 식별
# 코드의 어떤(보통 최근) 수정 사항이 문제를 해결했는지 확인
# 이전 코드 상황에 수정 사항 적용(적절한 백포팅)
# 하나 또는 여러 수준의 품질 관리 - 백포트된 버전이 이전 기능을 유지하는지 여부와 새 기능을 적절하게 구현하는지 테스트한다.

일반적으로 이러한 여러 수정 사항은 패치 세트에 번들로 제공된다.

백포트는 소프트웨어의 핵심 개발자 그룹에서 제공할 수 있다. 백포트는 소프트웨어 소스 코드에 액세스해야 하기 때문에 이것이 폐쇄형 소프트웨어에 대해 백포트를 수행하는 유일한 방법이다. 백포트는 일반적으로 소프트웨어의 이전 버전 라인을 따라 바이너리 업그레이드에 통합된다. 오픈 소스 소프트웨어의 경우 소프트웨어 배포자가 백포트를 생성하고 나중에 업스트림으로 전송하는 경우도 있다(즉, 문제가 발생한 소프트웨어의 핵심 개발자에게 제출).

2.3. 백포팅 적용

백포팅의 가장 간단하고 일반적인 예는 최신 버전의 소프트웨어에서 수정된 보안 취약점이다. 예를 들어 다음과 같다.

* 소프트웨어 v2.0에는 'is_unsecured' 텍스트를 'is_secured'로 변경하면 해결되는 보안 취약점이 있었다.
* 최신 버전의 코드베이스가 파생된 소프트웨어 v1.0에도 동일한 보안 취약점이 존재하지만 텍스트가 'is_notsecure'로 표시될 수 있다.

소프트웨어 v2.0을 수정하는 변경 사항을 가져와 소프트웨어 v1.0에 적용하도록 변경하면 효과적으로 수정 사항을 백포팅한 것이다.

실제 상황에서 소프트웨어 수정은 간단할 수도 있고(코드 몇 줄만 변경됨) 복잡하고 방대할 수도 있다(많은 수정이 코드의 여러 파일에 분산됨). 후자의 경우 백포팅은 지루하고 비효율적일 수 있으며, 최신 버전을 선호하기 위해 이전 버전의 소프트웨어가 실제로 필요한 경우에만 수행해야 한다(예를 들어 최신 버전이 여전히 안정성 문제로 인해 사용이 불가능한 경우).

백포팅 프로세스는 대략 다음 단계로 나눌 수 있다.

1. 백포트로 수정해야 하는 이전 버전의 소프트웨어 문제 식별
2. 코드의 어떤(보통 최근) 수정 사항이 문제를 해결했는지 확인
3. 이전 코드 상황에 수정 사항 적용(적절한 백포팅)
4. 하나 또는 여러 수준의 품질 관리 - 백포트된 버전이 이전 기능을 유지하는지 여부와 새 기능을 적절하게 구현하는지 테스트한다.

일반적으로 이러한 여러 수정 사항은 패치 세트에 번들로 제공된다.

백포트는 소프트웨어의 핵심 개발자 그룹에서 제공할 수 있다. 백포트는 소프트웨어의 소스 코드에 접근해야 하기 때문에 폐쇄형 소프트웨어에 대해 백포트를 수행하는 유일한 방법이다. 백포트는 일반적으로 소프트웨어의 이전 버전 라인을 따라 바이너리 업그레이드에 통합된다. 오픈 소스 소프트웨어의 경우 소프트웨어 배포자가 백포트를 생성하고 나중에 업스트림으로 전송하는 경우도 있다(즉, 문제가 발생한 소프트웨어의 핵심 개발자에게 제출).

2.4. 품질 관리 및 테스트

백포팅된 버전은 이전 기능을 유지하고 새로운 기능을 제대로 구현하는지 확인하기 위해 하나 또는 여러 수준의 품질 관리 테스트를 거친다. 일반적으로 여러 수정 사항은 패치 세트로 묶인다.

2.5. 패치 배포

일반적으로 이러한 여러 수정 사항은 패치 세트로 묶인다.

백포트는 소프트웨어의 핵심 개발자 그룹에서 제공할 수 있다. 백포트는 소프트웨어의 소스 코드에 접근해야 하기 때문에 이것이 클로즈드 소스 소프트웨어에 대해 백포트를 수행하는 유일한 방법이다. 백포트는 일반적으로 소프트웨어의 이전 버전 라인을 따라 바이너리 업그레이드에 통합된다. 오픈 소스 소프트웨어의 경우 소프트웨어 배포자가 백포트를 생성하고 나중에 업스트림으로 전송하는 경우도 있다(즉, 문제가 발생한 소프트웨어의 핵심 개발자에게 제출).

3. 적용 분야 및 사례

백포팅은 이전 버전의 소프트웨어에 새로운 기능을 추가하거나 문제를 해결하는 과정이다. 일반적으로 다음과 같은 단계로 진행된다.

* 백포트가 필요한 이전 버전 소프트웨어의 문제 식별
* 문제를 해결한 최신 버전의 코드 변경 사항 확인
* 이전 코드에 맞게 변경 사항 수정 및 적용 (백포트)
* 백포트된 버전이 이전 기능을 유지하고 새로운 기능을 올바르게 구현하는지 확인하기 위한 품질 관리 테스트

이러한 변경 사항들은 보통 패치 형태로 묶여 제공된다.

백포트는 주로 소프트웨어의 핵심 개발자 그룹이 담당한다. 백포트를 위해서는 소프트웨어의 소스 코드에 접근해야 하며, 이는 폐쇄형 소스 소프트웨어의 경우 백포팅을 수행할 수 있는 유일한 방법이다. 백포트는 보통 소프트웨어의 이전 버전에 대한 바이너리업그레이드에 포함된다. 오픈 소스 소프트웨어에서는 소프트웨어 배포자가 백포트를 생성하고, 이를 업스트림, 즉 해당 소프트웨어의 핵심 개발자에게 전달하는 경우도 있다.

3.1. 운영 체제

윈도우 XP 서비스 팩 3이 출시되었을 때 윈도우 비스타의 많은 기능이 윈도우 XP로 백포트되었다. 따라서 원래 비스타를 최소 요구 사항으로 하는 응용 프로그램(주로 게임)이 XP SP3에서 실행되는 것이 가능해졌다. 데비안 프로젝트는 2010년 9월부터 일부 데비안 리눅스 소프트웨어 패키지에 대한 공식 백포팅 서비스를 제공하고 있다. 우분투 리눅스도 백포트를 지원하지만, 우분투 백포트는 캐노니컬로부터 전혀 지원을 받지 않으며 전적으로 커뮤니티에서 관리된다. 2024년, 유튜버 MattKC는 .NET 프레임워크를 공식적으로 지원하지 않는 윈도우 95에 .NET 프레임워크 버전 2.0 및 3.5를 백포팅했다.

3.2. 기타

백포팅의 가장 간단하고 일반적인 상황은 최신 버전의 소프트웨어에서 보안 취약점을 수정한 경우이다. 예를 들면 다음과 같다.

* 소프트웨어 v2.0에는 'is_unsecured' 텍스트를 'is_secured'로 변경하여 해결되는 보안 취약점이 있었다.
* 최신 버전의 코드베이스를 기반으로 하는 소프트웨어 v1.0에도 동일한 보안 취약점이 존재하지만, 텍스트는 'is_notsecure'로 표시될 수 있다.

소프트웨어 v2.0의 수정 사항을 소프트웨어 v1.0에 적용하도록 변경하면, 효과적으로 수정 사항을 백포트한 것이다.

실제 상황에서 소프트웨어 수정은 코드 몇 줄만 변경하는 단순한 경우도 있지만, 코드의 여러 파일에 걸쳐 많은 수정이 필요한 복잡하고 대규모인 경우도 있다. 후자의 경우 백포팅은 지루하고 비효율적일 수 있으며, 최신 버전 대신 이전 버전의 소프트웨어가 정말로 필요한 경우에만 수행해야 한다. (예: 최신 버전이 여전히 안정성 문제로 인해 매우 중요한 작업에 사용이 불가능한 경우)

윈도우 XP 서비스 팩 3 출시와 함께 윈도우 비스타의 많은 기능이 윈도우 XP로 백포트되었다. 따라서 원래 비스타를 최소 요구 사항으로 하는 응용 프로그램(주로 게임)이 XP SP3를 최소 요구 사항으로 실행될 수 있게 되었다. 2010년 9월부터 데비안 프로젝트는 일부 데비안 리눅스 소프트웨어 패키지에 대한 공식 백포팅 서비스를 제공하고 있으며, 우분투 리눅스도 백포트를 지원한다. 2024년, 유튜버 MattKC는 프레임워크를 공식적으로 지원하지 않는 윈도우 95에 .NET Framework 버전 2.0 및 3.5를 백포팅했다.

4. 한계

백포팅의 가장 단순하고 일반적인 예는 소프트웨어의 새 버전에서 보안 취약점을 수정한 경우이다. 예를 들어 다음과 같다.

* 어떤 소프트웨어 v2.0에는 텍스트 "is_unsecured"를 "is_secured"로 변경하여 수정되는 보안 취약점이 있었다.
* 이 소프트웨어 v1.0에도 동일한 보안 취약점이 존재한다. 이는 새 버전에도 동일한 코드 기반이 사용되기 때문이다. 그러나 텍스트는 "is_notsecure"로 약간 변경되어 있다.

소프트웨어 v2.0을 수정하는 변경을 가하고, 소프트웨어 v1.0에도 적용할 수 있도록 변경함으로써 수정을 효과적으로 백포팅했다.

실제 상황에서 소프트웨어의 한 부분에서 이루어진 변경은 몇 줄의 코드만 변경된 단순한 것부터, 코드의 여러 파일에 걸쳐 많은 변경이 있는 크고 대규모인 것까지 다양하다. 대규모인 경우, 백포팅은 번거롭고 비효율적이 되기 쉬우며, 구버전의 소프트웨어가 정말 필요한 경우에만 실행해야 한다. 예를 들어 새 버전이 아직 미션 크리티컬한 사용을 방해하는 견고성 문제를 안고 있는 경우가 있다.