하위 호환성

[섬네일|[Wii는 이전 기기인 게임큐브와의 하위 호환성을 갖추고 있어, 게임큐브용 디스크를 구동하고 컨트롤러와 메모리 카드를 사용할 수 있다.2011년 이후에 출시된 버전에서는 컨트롤러와 메모리 카드 슬롯이 제거되어 이 기능이 사실상 없어졌으나, 메인보드에는 여전히 해당 단자가 남아 있어 개조를 통해 다시 납땜하여 복구할 수 있다.]]

**과거 호환성**() 또는 **하위 호환성**(下位互換性)은 운영체제, 소프트웨어, 실제 제품 또는 테크놀로지가 오래된 레거시 시스템이나 그러한 시스템을 위해 설계된 입출력 데이터와 상호 작용할 수 있는 속성을 말한다.

하위 호환성을 허용하지 않는 방식으로 시스템을 수정하는 것을 때때로 하위 호환성을 "깨뜨린다"()고 표현한다. 이러한 단절은 대개 전환 비용과 같은 다양한 유형의 비용을 발생시킨다.

보완적인 개념으로는 상위 호환성이 있다. 상위 호환이 가능하도록 설계된 제품은 대개 미래의 표준 및 제품과의 호환성을 위한 기술 로드맵을 가지고 있다.

## 용도
### 하드웨어에서
하위 호환성과 상위 호환성을 모두 보여주는 간단한 예는 스테레오 FM 방송의 도입이다. 초기 FM 라디오는 하나의 신호로 하나의 오디오 채널만 표현하는 모노 방식이었다. 2채널 스테레오 FM 라디오가 도입되었을 때, 많은 청취자들은 모노 FM 수신기만 가지고 있었다. 스테레오 신호를 받는 모노 수신기를 위한 상위 호환성은 왼쪽과 오른쪽 오디오 채널의 합을 하나의 신호로 보내고 차이를 다른 신호로 보냄으로써 달성되었다. 이를 통해 모노 FM 수신기는 합 신호를 수신하여 해독하는 동시에, 오디오 채널 분리에만 필요한 차이 신호는 무시할 수 있게 되었다. 스테레오 FM 수신기는 모노 신호를 수신하여 두 번째 신호 없이도 해독할 수 있으며, 합과 차 신호를 모두 받으면 합 신호를 왼쪽과 오른쪽 채널로 분리할 수 있다. 하위 호환성에 대한 요구 사항이 없었다면 더 간단한 방법이 선택되었을 수도 있다.

완전한 하위 호환성은 컴퓨터 명령어 집합 구조에서 특히 중요하다. 가장 성공적인 두 사례는 IBM의 메인프레임 제품군인 360/370/390/Z시리즈와 인텔의 X86 마이크로프로세서 제품군이다.

IBM은 1964년에 첫 360 모델을 발표했으며, 수십 년 동안 32비트 레지스터/24비트 주소 체계에서 64비트 레지스터 및 주소 체계로 이행하며 시리즈를 계속 업데이트해 왔다.

인텔은 1978년에 첫 인텔 8086/8088 프로세서를 발표했으며, 역시 수십 년에 걸쳐 16비트에서 64비트로 이행했다. (8086/8088은 1974년의 8비트 인텔 8080 프로세서와 명령어 집합이 호환되지는 않았지만, 이전 모델을 위해 작성된 프로그램을 쉽게 기계적으로 번역(source-to-source compiler)할 수 있도록 설계되었다. 반면, 자일로그 Z80은 인텔 8080과 완전히 하위 호환되었다.)

완전한 하위 호환성을 갖춘 프로세서는 이전 모델과 동일한 바이너리 실행 소프트웨어 명령어를 처리할 수 있으므로, 새로운 응용 소프트웨어나 운영체제를 구입하지 않고도 최신 프로세서를 사용할 수 있다. 마찬가지로, 와이파이 디지털 통신 표준의 성공은 광범위한 상위 및 하위 호환성 덕분으로 평가받으며, 하위 호환성이 없던 다른 표준들보다 더 대중화되었다.

### 소프트웨어에서

소프트웨어 개발에서 하위 호환성은 API를 통해 기능을 호출할 때 어떠한 오류도 발생하지 않는 소프트웨어 조각 간의 상호 운용성에 대한 일반적인 개념이다. 기능을 호출하는 데 사용되는 API가 여러 버전에 걸쳐 안정적으로 유지될 때 해당 소프트웨어는 안정적인 것으로 간주된다.

운영체제에서 이전 버전의 실행 파일 및 기타 파일들이 평소와 같이 작동한다면 최신 버전으로의 업그레이드가 하위 호환성을 갖춘 것이라고 말한다.

컴파일러에서 하위 호환성은 최신 버전 언어용 컴파일러가 이전 버전에서 작동했던 프로그램의 소스 코드나 데이터를 수용할 수 있는 능력을 의미할 수 있다.

데이터 형식의 경우, 최신 버전의 프로그램이 이전 버전과 마찬가지로 오류 없이 데이터를 열 수 있을 때 하위 호환성이 있다고 말한다.

## 절충점

### 이점
기업이 하위 호환성을 구현하는 데에는 몇 가지 동기가 있다. 하나는 제조사가 오래된 하드웨어에 대한 지원을 중단하기로 결정했을 때 사라질 수 있는 오래된 소프트웨어를 보존하는 데 사용될 수 있다는 점이다. 이러한 접근 방식의 대표적인 예는 비디오 게임으로, 오래된 소프트웨어 지원의 가치를 논할 때 자주 언급된다. 비디오 게임의 문화적 영향력은 지속적인 성공의 큰 부분이며, 일부는 하위 호환성을 무시하는 것이 이러한 타이틀들을 사라지게 할 것이라고 믿는다. 비록 현대에는 에뮬레이션 기술의 발전과 보존 노력 덕분에 많은 구형 컴퓨터, 휴대용 기기, 콘솔 게임을 원래의 하드웨어나 사양이 아닌 환경에서도 훨씬 쉽게 플레이할 수 있게 되었다. 또한 하위 호환성은 새로운 하드웨어의 판매 포인트로 작용하는데, 기존 사용자 층이 다음 세대 콘솔로 더 저렴하게 업그레이드할 수 있기 때문이다. 이는 또한 개발자들이 새로운 하드웨어로 전환하는 동안 사용자들이 이전 콘솔의 게임 라이브러리를 이용할 수 있게 함으로써, 새로운 시스템 출시 초기 단계의 타이틀 부족을 보완하는 데 도움이 된다. 오리지널 플레이스테이션(PS) 소프트웨어 디스크 및 주변 기기와의 하위 호환성은 플레이스테이션 2(PS2)가 시장 출시 초기 몇 달 동안 큰 인기를 끈 핵심 판매 포인트로 여겨진다. 더욱이 1990년대 중반의 연구에 따르면, 새 시스템을 구입한 후 이전 게임을 전혀 하지 않는 소비자들조차 하위 호환성을 매우 바람직한 기능으로 여기며, 실제로 사용 여부와 관계없이 기존 게임 컬렉션을 계속 플레이할 수 있다는 능력 자체에 가치를 두는 것으로 나타났다.

출시 당시에는 포함되지 않았으나, 마이크로소프트는 제품 수명 주기 도중 수년에 걸쳐 엑스박스 원에 일부 타이틀에 대한 하위 호환성을 서서히 통합했다. 플레이어들은 엑스박스에서 하위 호환 게임을 즐기는 데 10억 시간 이상을 보냈다. 이 기능의 성공과 구현의 큰 부분은 차세대 콘솔의 하드웨어가 강력하고 레거시 시스템과 충분히 유사하여 오래된 타이틀을 엑스박스 원에서 실행되도록 분해 및 재구성할 수 있었기 때문이다. 이 프로그램은 엑스박스 플레이어들에게 매우 큰 인기를 얻었으며, 고전 타이틀의 스튜디오 제작 리마스터라는 최근의 추세에 반하는 행보로서 콘솔 제조사 전략의 중요한 변화를 만들어냈다고 평가받는다. 플레이스테이션 5(PS5) 및 엑스박스 시리즈 X/S와 같은 현 세대 콘솔들도 이 기능을 지원한다.

### 비용
오래된 소프트웨어를 지원하는 데 드는 금전적 비용은 하위 호환성 사용의 큰 단점으로 꼽힌다. 하위 호환성과 관련된 비용으로는 레거시 시스템 지원을 위해 하드웨어가 필요한 경우의 더 큰 자재 명세서 비용, 제품의 복잡성 증가로 인한 출시 시기 지연, 기술적 장애 및 혁신 저해, 호환성에 대한 사용자들의 기대치 상승 등이 있다. 또한 개발자들이 잠재적 구매자 층이 더 넓은 구형 및 신형 시스템 모두와 호환되는 게임 개발을 선호하게 되어, 신형 시스템의 고급 기능을 활용하는 소프트웨어가 부족해질 위험도 있다. 이 때문에 여러 콘솔 제조사는 하드웨어 비용을 절감하고 차세대 하드웨어 출시 전 판매를 잠시 활성화하기 위해 콘솔 세대 말기에 하위 호환성 기능을 단계적으로 폐지하기도 했다. 이러한 접근 방식의 한 예는 플레이스테이션 3(PS3)로, 하드웨어 비용을 줄이고 판매량을 늘리기 위해 후기 모델에서 플레이스테이션 2(PS2) 게임과의 하위 호환성을 제거했다(이전 리비전에서 사용되던 내장 이모션 엔진 및 그래픽 신시사이저 하드웨어 칩 제거 포함).

그럼에도 불구하고 이러한 하드웨어 비용의 일부를 우회하는 것은 가능하다. 예를 들어 초기 PS2 시스템에는 오리지널 플레이스테이션(PS1) CPU의 코어가 이중 목적으로 I/O 프로세서에 통합되어 있었다. 이는 PS1 모드에서는 메인 CPU로 작동하고, PS2 모드에서는 클럭 속도를 높여 I/O 부하를 분산하는 역할을 수행했다. 후기 시스템에서는 원래의 I/O 코어가 파워PC 기반 코어로 교체되어 동일한 기능을 수행하면서 PS1 CPU 코어의 기능을 에뮬레이션했다. 그러나 이러한 접근 방식이 역효과를 낼 수도 있는데, 슈퍼 패미컴의 사례가 그러하다. 슈퍼 패미컴은 에뮬레이션 모드에서 6502 CPU와 소프트웨어 호환이 가능한 65C816의 특성상 오리지널 패밀리컴퓨터와의 하위 호환성을 쉽게 구현할 수 있다는 근거로 당시 인기 있던 다른 16비트 마이크로프로세서 대신 독특한 65C816 CPU를 선택했으나, 결과적으로 나머지 아키텍처가 설계된 후에는 호환성 구현이 불가능한 것으로 판명되었다.

## 같이 보기
* 버그 호환성: 알려진 결함을 유지하는 하위 호환성
* 호환성 모드
* 컴퓨터 호환성
* 구식화
* 다운그레이드 공격
* 에뮬레이터
* ReactOS
* 심 (컴퓨팅)
* 소프트웨어 회귀

## 각주

## 외부 링크
* 


분류:상호운용성