이식 (컴퓨팅)
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
이식(컴퓨팅)은 서로 다른 환경의 컴퓨터에서 동일한 작업을 수행하기 위해 소프트웨어를 수정하는 과정을 의미한다. 초기 컴퓨터 시대에는 하드웨어 및 운영체제 차이로 인해 이식이 어려웠으나, 유닉스와 같은 이식성 높은 운영체제의 등장으로 개선되었다. 오늘날에는 x86 아키텍처의 지배력과 운영체제의 감소로 데스크톱 환경에서의 이식성은 줄었지만, 임베디드 시스템과 모바일 환경에서는 여전히 중요한 문제로 남아있다. 게임의 경우, 기술 발전과 시장 변화에 따라 다양한 플랫폼으로 이식되는 사례가 증가하고 있으며, 아케이드 게임의 이식은 원작 충실도가 중요하게 여겨진다. 이식 기술은 중간 코드, 인터프리터, 컴파일러 부트스트래핑 등을 활용하여 설계 노력을 줄이고 이식성을 높이는 방향으로 발전하고 있다.
더 읽어볼만한 페이지
- 상호운용성 - 크로스 플랫폼
크로스 플랫폼은 소프트웨어나 애플리케이션이 다양한 운영 체제, 하드웨어 플랫폼 또는 이들의 조합에서 동작할 수 있도록 하는 기술을 의미하며, 웹 애플리케이션 형태로 구현되거나 플랫폼 연동을 통해 하드웨어 경계를 넘어 콘텐츠를 즐길 수 있도록 한다. - 상호운용성 - 시스템 통합
시스템 통합은 오픈 시스템 환경에서 다양한 벤더의 제품을 조합하여 전체 시스템을 구축하는 서비스로, 정보 시스템 구축 아웃소싱과 함께 발전했지만 IT 환경 변화로 쇠퇴기에 접어들어 현재는 새로운 사업 모델을 모색하고 있으며, IT 컨설팅부터 유지 보수까지 다양한 단계를 거쳐 수직적, 스타, 수평적 통합 등 여러 통합 방법을 사용한다. - 소스 코드 - 헤더 파일
헤더 파일은 프로그래밍 언어에서 코드 재사용성, 모듈화, 컴파일 시간 단축에 기여하며 함수 프로토타입, 변수 선언 등을 포함하고 `#include` 지시어로 소스 코드에 포함되어 사용되는 파일이다. - 소스 코드 - 헝가리안 표기법
헝가리안 표기법은 변수 이름에 데이터 타입이나 목적을 나타내는 접두사를 붙이는 명명 규칙으로, 찰스 시모니가 고안하여 마이크로소프트에서 널리 사용되었으나, 코드 가독성 향상에 대한 유용성 논란과 함께 최신 IDE 환경에서는 불필요하다는 비판도 있다.
이식 (컴퓨팅) | |
---|---|
정의 | |
정의 | 소프트웨어를 다른 컴퓨팅 환경에서 실행할 수 있도록 적응시키는 과정 |
개요 | |
개념 | 포팅은 소프트웨어를 새로운 하드웨어, 운영 체제 또는 환경에서 실행할 수 있도록 수정하는 것을 의미한다. |
필요성 | 소프트웨어의 수명을 연장하고, 더 많은 사용자에게 접근성을 제공하며, 새로운 기술을 활용하기 위해 필요하다. |
과정 | 소스 코드 분석, 변경, 컴파일, 테스트 및 디버깅 과정을 포함한다. |
고려 사항 | |
하드웨어 | CPU 아키텍처, 메모리 관리, 주변 장치 등의 차이를 고려해야 한다. |
운영 체제 | 파일 시스템, 시스템 호출, 라이브러리 등의 차이를 고려해야 한다. |
컴파일러 | 언어 표준, 컴파일러 옵션, 링커 등의 차이를 고려해야 한다. |
라이브러리 | 표준 라이브러리, 그래픽 라이브러리, 네트워크 라이브러리 등의 호환성을 확인해야 한다. |
데이터 | 데이터 형식, 엔디안, 문자 인코딩 등의 차이를 고려해야 한다. |
기타 | 국제화 및 지역화, 성능, 보안 등의 요소를 고려해야 한다. |
난이도 | |
영향 요인 | 소스 코드의 복잡성, 사용된 기술, 대상 플랫폼의 차이 등에 따라 난이도가 결정된다. |
쉬운 경우 | 고급 언어로 작성되고, 표준 라이브러리를 사용하며, 플랫폼 간 차이가 적은 경우 포팅이 비교적 쉽다. |
어려운 경우 | 어셈블리어로 작성되고, 시스템 의존적인 코드를 포함하며, 플랫폼 간 차이가 큰 경우 포팅이 매우 어렵다. |
관련 기술 | |
크로스 컴파일러 | 다른 플랫폼용 실행 파일을 생성하는 컴파일러 |
가상 머신 | 플랫폼 독립적인 실행 환경을 제공 (예: 자바 가상 머신) |
에뮬레이터 | 다른 플랫폼의 환경을 모방하여 소프트웨어를 실행 |
소스 코드 변환 도구 | 자동으로 소스 코드를 다른 언어나 플랫폼에 맞게 변환 |
포팅 전략 | |
소스 코드 수정 | 소스 코드를 직접 수정하여 플랫폼 간 호환성을 확보 |
API 래퍼 | 플랫폼별 API를 추상화하여 공통 인터페이스를 제공 |
가상화 | 가상 머신 또는 컨테이너를 사용하여 소프트웨어를 격리하고 실행 |
장점 | |
재사용성 | 기존 소프트웨어를 새로운 환경에서 재사용 가능 |
확장성 | 더 많은 사용자 및 플랫폼에 접근 가능 |
비용 절감 | 새로운 소프트웨어 개발 비용 절감 |
단점 | |
시간 소요 | 복잡한 소프트웨어의 경우 포팅에 많은 시간과 노력이 필요 |
성능 저하 | 최적화되지 않은 포팅은 성능 저하를 초래할 수 있음 |
호환성 문제 | 완벽한 호환성을 보장하기 어려울 수 있음 |
예시 | |
운영 체제 포팅 | 리눅스를 임베디드 시스템으로 포팅 |
게임 포팅 | PC 게임을 콘솔 게임으로 포팅 |
응용 프로그램 포팅 | 웹 애플리케이션을 모바일 앱으로 포팅 |
참고 자료 | |
참고 문헌 | 포트란 이식성 관련 GNU 문서 |
2. 이식의 역사
컴퓨터 이식의 역사는 플랫폼 다양성과 밀접하게 관련되어 있다.
초창기에는 다양한 사상을 기반으로 한 여러 종류의 컴퓨터와 프로그래밍 언어가 다양한 제조 업체로부터 판매되었다. 옛날에는 IBM 등의 제조 업체가 메인 프레임 컴퓨터 시장에서 점차 IBM 호환 기기 제조 업체로 통합되었다. 오늘날 개인용 컴퓨터의 대부분은 윈도우 또는 매킨토시 시리즈로 수렴되어, 사용자는 자신이 사용하는 PC의 운영 체제만 고려하면 된다.
호환되는 컴퓨터에서는 운영 체제(OS)가 제공하는 응용 프로그래밍 인터페이스(API)와 장치 작동을 통해 하드웨어 제조 업체 및 기종의 차이가 숨겨진다. 따라서 하드웨어 사양 및 메모리 구성의 차이 등에 관계없이 동일한 소프트웨어를 사용할 수 있다. 이들은 OS가 제공하는 표준화된 환경에서 동작하므로, 제조 업체 및 모델의 차이는 문제가 되지 않는다.
그러나 윈도우와 매킨토시 시리즈처럼 호환성이 없는 컴퓨터에서는 일부 소프트웨어를 제외하고는 동일한 소프트웨어가 작동하지 않는다. 이는 OS가 제공하는 환경이 다르기 때문이다. OS에 따라 지원되는 주요 프로그래밍 언어가 다른 경우도 있으며, 특히 위젯 툴킷을 이용하는 GUI 애플리케이션 이식에는 각 언어를 사용하여 소프트웨어의 일부 또는 전부를 다시 작성해야 하는 경우도 있다.
과거에는 동작 환경이 다른 컴퓨터에서 동일한 작업을 수행하려면 완전히 다른 프로그램을 만들어야 했다. 하드웨어 구성의 차이를 보정하는 OS 및 드라이버가 없던 시대에는 같은 제조사의 컴퓨터라도 기종이 다르면 프로그램의 대부분을 수정해야 했다.
2010년대에는 모든 플랫폼에 대해 동시에 동일한 애플리케이션을 배포하는 것이 일반적이 되었다. 하지만 한계도 존재한다. 예를 들어 PC용 애플리케이션을 스마트폰이나 태블릿 기기용으로 그대로 이식하는 것은 해상도나 조작 체계(마우스 및 키보드 혹은 터치 스크린) 등의 차이로 인해 어렵거나 불가능하다.
2. 1. 초기 컴퓨터 환경
초창기 컴퓨터는 제조사별로 운영체제와 하드웨어가 달랐기 때문에 소프트웨어 이식은 매우 어려운 작업이었다.[3] 같은 제조사의 컴퓨터라도 기종이 다르면 프로그램의 대부분을 다시 만들어야 했다.1980년대 개인용 컴퓨터(PC) 보급 초기, 대한민국에서는 다양한 기종이 경쟁하면서 소프트웨어 이식 문제가 더욱 두드러졌다. 각 소프트웨어 제조사는 수익성을 고려하여 점유율이 낮은 기종에는 소프트웨어 이식을 포기하는 경우도 있었다. 그러나 수익성이 보장된다면, 성능이 낮은 PC용 소프트웨어를 개발하기 위해 많은 노력을 기울였다. 그 결과, 일본의 PC 시장은 1980년대 말에는 8비트 삼대장과 MSX 시리즈로 대표되는 몇몇 기종으로 과점화되는 경향을 보였다.
2. 2. 유닉스와 이식성 향상
1970년대 이후 정보 공학 분야에서는 다양한 컴퓨터 제조사에서 여러 종류의 컴퓨터를 출시했지만, 플랫폼마다 조작 방법이 크게 달라 어려움을 겪는 이용자들이 많았다. 이러한 상황에서 멀티 유저, 멀티태스킹을 지원하는 유닉스(UNIX)는 산학연 분야에서 널리 사용되었고, 다양한 컴퓨터에서 작동하는 유닉스 계열 운영 체제가 이식되었다.[3]또한, 가정용 PC에서도 동일한 운영 체제를 사용하고자 하는 사용자들의 요구에 따라, PC/AT 호환기에서 동작하는 리눅스(Linux)나 FreeBSD 등이 개발되었다. 특히 리눅스는 가정용 게임기, 휴대 기기, 과거의 컴퓨터 하드웨어 등에서도 동작하도록 개발되어, 엑스박스(Xbox)나 플레이스테이션에서도 실행할 수 있게 되었다.
2. 3. 현대의 이식 환경
오늘날 데스크톱 환경에서는 x86 아키텍처의 지배력이 강화되어, 대부분의 데스크톱 소프트웨어가 다른 CPU로 이식되지 않는다. 운영 체제 선택의 폭도 마이크로소프트 윈도우, macOS, 리눅스 세 가지로 좁혀졌다. 그러나 임베디드 시스템 및 모바일 시장에서는 이식성이 여전히 중요한 문제이며, ARM이 널리 사용되는 대안이다.ISO와 같은 국제 표준은 서로 다른 플랫폼 간의 차이를 줄여 이식을 용이하게 한다. 이러한 표준을 준수하는 POSIX.1과 같은 플랫폼 간에는 소스 코드를 가져와 새 플랫폼에서 다시 컴파일하는 것만으로 이식이 가능할 수 있다. 그러나 실제로는 플랫폼 간 미묘한 차이로 인해 수정이 필요한 경우가 많다.
GNU 컴파일러 모음이나 오토툴과 같이 이식을 돕는 도구들도 늘어나고 있다. 일부 고급 프로그래밍 언어(예: Eiffel, Esterel)는 다른 고급 중간 언어(예: C)의 소스 코드를 출력하여 이식성을 확보하기도 한다.
마이크로소프트 윈도우 8 이후에는 Windows 런타임 API가 탑재되어 PC와 태블릿 기기 간 윈도우 애플리케이션 이식이 쉬워졌다.[21][22]
3. 컴퓨터 게임 이식
컴퓨터 게임 이식은 특정 플랫폼용으로 개발된 게임을 다른 플랫폼에서 실행할 수 있도록 하는 과정이다.[9] 비디오 게임 초창기부터 1990년대까지는 "이식"을 "변환"이라고 불렀는데, 이는 서로 다른 시스템의 한계 때문에 게임을 완전히 똑같이 옮기는 것이 아니라 수정해야 하는 경우가 많았기 때문이다.
1980년대에는 소프트웨어 업체들이 수익성을 고려하여 점유율이 낮은 기종으로는 게임을 이식하지 않는 경우도 있었다. 당시 일본 PC 시장에서는 8비트 시대에 여러 회사들이 경쟁했지만, 결국 호환 MSX 시리즈가 시장을 장악하는 경향을 보였다.
정보기술 분야에서는 1970년대 이후 다양한 컴퓨터 제조사들이 여러 종류의 컴퓨터를 출시했지만, 플랫폼마다 조작 방식이 크게 달랐다. 유닉스는 여러 사용자가 함께 사용하는 환경을 고려하여 만들어졌기 때문에 다양한 컴퓨터에 이식될 수 있었고, 가정용 PC에서도 같은 운영체제를 사용하고 싶어하는 사람들의 요구에 따라 리눅스나 FreeBSD 등이 개발되었다. 특히 리눅스는 가정용 게임기와 휴대용 기기 등에도 이식되어 엑스박스와 플레이스테이션에서도 실행할 수 있게 되었다.
최근에는 컴퓨터 게임 프로그램 개발 규모가 커지면서, 여러 플랫폼에서 동일하게 동작하는 환경을 미리 구축하고 그 위에서 게임을 실행하는 방식이 사용되기도 한다. 게임 엔진은 게임 소프트웨어 개발을 쉽게 하기 위해 사용되지만, 다양한 플랫폼으로 이식되면서 게임 이식에 필요한 노력과 비용을 줄이는 데에도 기여하고 있다. PlayStation 4나 Xbox One처럼 x86 기반의 AMD APU를 채택한 콘솔이 등장하면서 PC 게임과의 상호 이식이 더욱 쉬워졌다.
3. 1. 이식의 유형
과거 게임 소프트웨어는 통상 한 종류의 게임기(게임 콘솔)에만 독점적으로 대응하여 개발, 판매되는 경우가 많았고, 이식이라고 하면 주로 (고성능) 아케이드 기기에서 (저성능) 가정용 게임기로의 이식을 가리키는 경우가 대부분이었다. 그러나, Xbox 360/PlayStation 3/Wii와 같은 고성능 콘솔이 등장할 무렵에는 처음부터 복수의 플랫폼에서 제품 판매를 전개하는 것을 염두에 두고 개발되는 경우도 많아졌다. 다른 기종에 동일한 내용의 게임 소프트웨어를 제공하기 위해서는 소프트웨어 개발 회사, 또는 외주나 라이선스 제공을 받은 다른 소프트웨어 개발 기업(서드 파티)에 의한 이식 작업이 필요하다. 이식의 패턴은 크게 다음 4가지로 나눌 수 있다.[9]# 과거의 게임 소프트웨어를 현행 기종용으로 이식하는 경우 (그래픽이나 사운드의 개선과 같은 리메이크가 이루어지는 경우도 있다)
# 비교적 최근의 소프트웨어를 더 널리 보급된 현행 기종으로 이식하는 경우
# 아케이드 게임 하드웨어에서 가정용 게임기로 이식하는 경우
# 동일 시기에 보급되는 복수의 가정용 게임기로 이식하는 것을 처음부터 전제로 만들어지는 경우
복수 기종으로의 이식은 '''멀티 플랫폼''' 대응(멀티 플랫폼 전개)이라고도 불리며, 경우에 따라서는 동시기에 발매하기 위해 병행하여 이식 작업이 이루어지는 경우도 있다.
과거 8비트 삼대장처럼 주요 플랫폼이 병행 진화 형태로 복수 존재하며 시장을 다투던 시대에는, 메이커의 개발진에게 여유가 있는 경우, 예를 들어 DAIVA처럼, 신제품 소프트웨어를 복수 기종용으로 병행 개발하여 거의 동시에 발매하는 경우도 종종 있었다. 또한, 규모가 크지 않은 기업에서도 레리쿠스처럼, 1기종용으로 선행 판매하고, 쇄도식으로 다음 기종용으로 이식 작업을 속행하여, 잇따라 다기종 전개하는 메이커도 보였다. 테그저처럼, 외주나 라이선스 제공으로 결과적으로 다기종 전개한 사례도 있다.
게임의 이식에서 독특한 문제가 되는 것은 조작 장치이다. 컨트롤러의 버튼 수나 그 배치, 아날로그식 입력의 유무 등은 기종마다 다르기 때문에, 위화감 없는 조작을 재현하기 위해 이식 대상에 맞춘 어레인지나 조정이 필요하게 되는 경우가 있다. 각 기종 간의 프레임 속도, 화면 해상도의 차이도 큰 문제가 될 수 있다. 이러한 이식 대상의 게임기 (컨슈머 게임)의 성능이나 사양상의 차이에 의한 게임 내용의 변경과 같은 것도, 과거에는 빈번하게 이루어졌다.
예를 들어, 8비트 컴퓨터 시대에는 아케이드판 『제비우스』의 이식 작품 『타이니 제비우스』처럼, 게임 규칙은 변경하지 않고 게임의 영상 면을 대폭 생략하거나, 패밀리 컴퓨터용 『그라디우스』처럼, 조작 기기 (입력 장치)의 차이에 의해 1개의 버튼에 복수의 기능을 할당하도록 사양 변경을 한 경우가 있다. 이러한 다운 그레이드적 개변은 PC 및 컨슈머 게임기의 기능이 아케이드 게임기에 미치지 못하는 시대에는 종종 있었다. 2000년대 무렵부터는, 1980~1990년대의 오래된 게임을 최신 기종에 이식하는 경우, 반대로 영상이나 음악의 업그레이드를 도모하는 경우도 있다.
또한 이식할 때 버그(비기로 인식되는 플레이어에게 유리한 것도 포함)의 수정이나, 게임 밸런스의 조정, 요소의 추가 등이 이루어지는 경우도 많다. 예를 들어 『아토믹 로보키드』에서는, 아케이드 게임판이 "적탄이나 보스와의 접촉이 즉시 미스, 잔기가 없어지면 게임 오버"였던 것이, PC 엔진으로의 어레인지 이식판 『아토믹 로보키드 스페셜』은 라이프제로 변경, "적탄이나 보스와의 접촉으로 라이프 감소, 라이프 부족으로 게임 오버"가 되었다. 이러한 경우에는, 게임 규칙의 변경 등도 있어, 원작을 바탕으로 다른 내용의 작품을 만들어내는 리메이크와의 구별이 모호하다. 이 외 발매 당시에는 그다지 문제시되지 않았던 표현이, 후년에 어떤 문제가 있다고 판단된 경우, 이식 시에 문제의 표현을 수정하는 경우가 있다.
플레이스테이션 등의 세대로부터 하드웨어의 성능 향상에 따라, 각 메이커는 타 기종으로부터의 완전 이식을 목표로 하고 있지만, 메이커에 따라 이식도는 제각각이며, 그 중에는 치명적인 버그를 포함한 이식 소프트나, 또는 실질적인 리메이크인 것도 존재한다. 또한 롬 카세트나 CD-ROM 등 기록 매체의 정보량 증가에 따라, 주가 되는 소프트웨어는 리메이크 작품이지만, 오리지널 모드라고 칭하며 원작의 충실한 이식판을 포함하고 있는 소프트웨어도 종종 보이며, 『스페이스 인베이더』나 『팩맨』 등 옛날의 유명 게임에서는 복수 모드를 가진 소프트웨어도 보인다.
3. 2. 이식의 문제점
조작 장치의 차이는 이식의 주요 문제점 중 하나이다. 컨트롤러의 버튼 수, 배치, 아날로그 입력 유무 등은 기종마다 다르기 때문에, 원작과 동일한 조작감을 재현하기 위해서는 이식되는 기기에 맞춘 조정이 필요하다.[9] 예를 들어, 패밀리 컴퓨터용 그라디우스는 조작 장치의 차이로 인해 아케이드 게임에서 3버튼(파워업, 공중 공격, 지상 공격)이던 것이 2버튼(파워업, 공중과 지상 공격)으로 변경되었다.[9]성능 차이 역시 중요한 문제이다. 각 기종 간의 프레임 속도, 화면 해상도의 차이는 게임 플레이 경험에 큰 영향을 줄 수 있다.[9] 예를 들어, 8비트 컴퓨터 시대에는 제비우스를 이식한 타이니 제비우스와 같이 게임 규칙은 변경하지 않고 영상 표현을 대폭 생략하는 경우가 있었다.[9]
이식 과정에서 버그 수정이나 밸런스 조정, 요소 추가 등이 이루어지기도 한다.[9] 예를 들어, 아토믹 로보키드는 아케이드 게임에서는 "적과의 접촉이 바로 실수"였지만, PC 엔진으로 이식된 아토믹 로보키드 스페셜에서는 "적과의 접촉 시 생명이 줄어들어 게임 오버"가 되는 방식으로 변경되었다.[9]
표현 문제도 발생할 수 있다. 원작에서는 문제가 없었던 표현이 이식 시점에 문제가 되어 수정되는 경우가 있다.[9]
3. 3. 아케이드 게임 이식의 특수성
아케이드 게임의 이식은 원작의 게임 플레이, 그래픽 등을 얼마나 충실하게 재현했는지가 중요하게 여겨지며, 이를 "아케이드 완벽", "아케이드 정확" 등의 용어로 표현한다.[10] 초기 아케이드 게임 이식은 가정용 콘솔이나 컴퓨터의 하드웨어 성능 제약으로 인해 어려움을 겪었다. 예를 들어, Atari 2600으로 이식된 팩맨은 ROM 공간 부족으로 인해 원작의 많은 시각적 요소가 생략되었고, 이는 1983년 비디오 게임 붕괴의 원인 중 하나로 언급되기도 한다.[11]하지만 1990년대에 가정용 콘솔의 성능이 향상되면서 아케이드와 동일한 수준의 이식이 가능해졌다. 특히 SNK의 네오 지오는 아케이드 기판과 가정용 콘솔의 사양이 동일하여 '아케이드 완벽' 이식을 실현했다.[10]
아케이드 게임 이식에서 어려운 부분은 다음과 같다.
- 조작 장치: 컨트롤러의 버튼 수, 배치, 아날로그 입력 유무 등이 기종마다 다르기 때문에 이식 시 조정이 필요하다.
- 하드웨어 성능: 프레임 속도, 화면 해상도 등에서 차이가 발생하여 게임 내용에 영향을 줄 수 있다.
이러한 문제점에도 불구하고, 아케이드 게임 이식은 꾸준히 이루어졌으며, 일부 코어 게이머들은 이식의 완성도에 대해 엄격한 평가를 내리기도 한다.
3. 4. 콘솔 게임의 PC 이식 문제
콘솔 게임을 PC로 이식하는 것은 종종 부정적인 인식을 받는데, 이는 PC의 성능을 충분히 활용하지 못하거나 최적화가 부족한 경우가 많기 때문이다.[9] 콘솔은 하드웨어 사양이 고정되어 있어 게임 개발 시 해당 사양에 맞춰 최적화되지만, PC는 하드웨어 성능이 계속 발전하기 때문에 이식된 게임이 PC의 성능을 제대로 활용하지 못하는 경우가 발생한다.하지만, PlayStation 4나 Xbox One처럼 x86 기반의 AMD APU를 채택한 콘솔이 등장하면서 PC 게임과의 상호 이식이 쉬워졌다.[9]
4. 이식 관련 기술
"포팅"이라는 용어는 "운반하다"를 의미하는 라틴어 ''portāre''에서 유래되었다.[3] 코드가 특정 운영 체제 또는 컴퓨터 아키텍처와 호환되지 않을 경우, 해당 코드를 새 시스템으로 "이동"해야 한다.
ISO에서 공포한 것과 같은 국제 표준은 서로 다른 표준을 준수하는 플랫폼 간의 차이를 줄이는 데 도움이 되는 방식으로 컴퓨팅 환경의 세부 사항을 지정하여 이식을 크게 용이하게 한다. 이러한 표준에서 지정한 경계 내에 있는 소프트웨어를 작성하는 것은 실질적인 노력이지만 쉽지 않다. 이러한 프로그램을 두 개의 표준 준수 플랫폼(예: POSIX.1) 간에 이식하는 것은 소스 코드를 로드하고 새 플랫폼에서 다시 컴파일하는 문제일 수 있지만, 실무자들은 미묘한 플랫폼 차이로 인해 다양한 사소한 수정이 필요하다는 것을 종종 발견한다.
다양한 플랫폼에서 일관된 프로그래밍 언어를 제공하는 GNU 컴파일러 모음과 환경의 사소한 변동을 감지하고 컴파일 전에 그에 따라 소프트웨어를 조정하는 오토툴과 같은 이식을 용이하게 하는 도구의 수가 계속 증가하고 있다.
일부 고급 프로그래밍 언어 (예: Eiffel, Esterel)의 컴파일러는 많은 플랫폼에서 일반적으로 사용할 수 있는 컴파일러가 있는 다른 고급 중간 언어 (예: C)의 소스 코드를 출력하여 이식성을 확보한다.
BCPL 언어의 설계자에 따르면, 해석된 코드(BCPL의 경우)는 기계어보다 더 작으며, 일반적으로 2:1의 비율을 보인다. 그러나 해석된 코드는 동일한 기계에서 컴파일된 코드보다 약 10배 느리게 실행된다.[8]
Java 프로그래밍 언어의 설계자는 해석된 코드의 간결성을 활용하려 한다. 이는 Java 프로그램이 대상의 Java 가상 머신 (JVM)에서 실행을 시작하기 전에 인터넷을 통해 전송해야 할 수 있기 때문이다.
플랫폼마다 소프트웨어를 기술하는 대신, 크로스 플랫폼 애플리케이션 프레임워크를 이용하여 이식성 및 유지 보수성을 높이는 기법이 채택되는 경우도 많다. 또한 이식성을 높이기 위해 플랫폼 및 프로세서 명령 집합을 추상화한 가상 머신이나 중간 표현이 이용되는 경우도 있다. 오라클(구 썬 마이크로시스템즈)의 Java는 플랫폼에 의존하지 않는 가상 실행 환경 (Java Runtime Environment, JRE)을 정의하고, 해당 가상 환경에서 동작하는 가상 머신 (Java VM) 및 크로스 플랫폼 클래스 라이브러리 (Java API)를 준비하여 JRE를 지원하는 환경이라면 한 번 작성한 애플리케이션 프로그램을 변경하지 않고 그대로 실행할 수 있는 생태계를 구축하여 일정 수준의 성공을 거두었다.
OpenGL이나 OpenCL 등과 같이 표준화된 API의 오픈 규격도 존재한다. 이러한 API를 지원하는 플랫폼 간에는 소프트웨어의 이식이 쉬워지지만, 실제 API의 구현인 장치 드라이버의 품질 및 규격 준수 수준은 개별 벤더에 따라 다르다.
4. 1. 이식성 컴파일러
현대의 컴파일러는 기계어로 직접 변환하는 대신, 기계 독립적인 중간 코드로 변환하여 컴파일러의 이식성을 높이고 설계 노력을 최소화한다. 중간 언어는 가상 머신을 정의하며, 이 가상 머신은 중간 언어로 작성된 모든 프로그램을 실행할 수 있다.[4] 중간 코드 명령어는 ''코드 생성기''에 의해 동등한 기계어 시퀀스로 변환되어 실행 가능한 코드를 생성한다. 또한 가상 머신용 인터프리터 또는 JIT를 실제로 구현하여 기계어 생성을 건너뛸 수도 있다.[5]중간 코드의 사용은 컴파일러의 이식성을 향상시키는데, 이는 컴파일러 자체의 기계 종속적인 코드(인터프리터 또는 코드 생성기)만 대상 기계로 이식하면 되기 때문이다. 컴파일러의 나머지 부분은 중간 코드로 가져와 이식된 코드 생성기 또는 인터프리터에 의해 추가로 처리되어 컴파일러 소프트웨어를 생성하거나 인터프리터에서 중간 코드를 직접 실행할 수 있다. 기계 독립적인 부분은 다른 기계(''호스트 머신'')에서 개발 및 소프트웨어 테스트할 수 있다. 이는 기계 독립적인 부분을 한 번만 개발하여 이식 가능한 중간 코드를 생성하면 되므로 설계 노력을 크게 줄여준다.[6]
인터프리터는 코드 생성기보다 덜 복잡하므로 이식하기가 더 쉽다. 인터프리터는 프로그램 코드에 대한 제한된 시야(한 번에 하나의 명령어만 보며, 최적화를 수행하기 위해서는 명령어 시퀀스가 필요함)로 인해 코드 최적화를 수행할 수 없기 때문이다. 일부 인터프리터는 기본 하드웨어의 명령어 집합에 대한 최소한의 가정만 하므로 이식하기가 매우 쉽다. 결과적으로 가상 머신은 대상 CPU보다 훨씬 더 간단하다.[7]
컴파일러가 번역하도록 설계된 프로그래밍 언어로 컴파일러 소스를 완전히 작성하면, ''컴파일러 부트스트래핑''을 대상 기계에서 실행할 수 있다.
# 인터프리터를 이식한다. 이는 대상에 이미 있는 어셈블리어를 사용하여 어셈블리 코드로 코딩해야 한다.
# 코드 생성기의 소스를 새로운 기계에 맞게 조정한다.
# 코드 생성기 소스를 입력으로 사용하여 인터프리터를 통해 조정된 소스를 실행한다. 그러면 코드 생성기에 대한 기계어가 생성된다.
최적화 루틴을 코딩하는 어려운 부분은 대상의 어셈블리 언어가 아닌 고수준 언어를 사용하여 수행된다.
4. 2. 에뮬레이션과 크로스 컴파일
에뮬레이션은 특정 플랫폼의 환경을 다른 플랫폼에서 그대로 따라하는 기술이다. 크로스 컴파일은 다른 플랫폼에서 실행될 코드를 만들어내는 컴파일 방식이다.여러 제조사에서 다양한 설계 사상을 바탕으로 컴퓨터를 출시했으며, 이러한 컴퓨터에서 동작하는 프로그램을 기술하기 위한 프로그래밍 언어도 매우 다양하다. 이식성은 OS 자체의 차이보다는 다음 요소들에 의해 좌우된다.
- 시스템 콜이나 명령 등의 차이 (예: 리눅스, GNU Hurd, FreeBSD, macOS, Plan 9 등 POSIX, 및 그 외)
- CPU 및 명령 집합(기계어)의 차이 (ARM, x86, x64)
- 확장 명령어
- 비트 길이 (8비트, 16비트, 32비트, 64비트, 128비트, 256비트 등)
- 네트워크 어댑터 및 스토리지
- 그래픽 카드 (GPU) 및 사운드 카드와 같은 주변기기의 장치 드라이버 지원 상황
- 이용 가능한 라이브러리의 차이
5. 이식성과 관련된 한국의 특수 상황
1980년대 한국에서는 다양한 PC 기종이 경쟁하면서 이식성 문제가 중요하게 부각되었다. 각 소프트웨어 제조사는 수익성을 고려하여 점유율이 낮은 기종에는 소프트웨어 이식을 하지 않는 경우도 있었다. 하지만 수익성이 보장된다면 성능이 낮은 PC용 소프트웨어라도 많은 노력을 들여 이식하는 경우가 많았다.
최근에는 모바일 게임 시장의 성장으로 모바일 플랫폼 간 이식, PC와 모바일 간 이식 기술이 중요해지고 있다.
참조
[1]
논문
A machine and configuration independent Fortran: Portable Fortran
1975-03
[2]
웹사이트
Portability Issues
https://www.gnu.org/[...]
[3]
웹사이트
port, v.2
http://www.oed.com/v[...]
Oxford University Press
2017-12-21
[4]
harvnb
[5]
harvnb
[6]
harvnb
[7]
harvnb
[8]
harvnb
[9]
서적
The Video Game Explosion: A History from PONG to Playstation and Beyond
Bloomsbury Academic
[10]
간행물
Port or conversion? An ontological framework for classifying game versions {{!}} DiGRA Conference 2019
2019
[11]
논문
Bridging the Gap: The Neo Geo, the Media Imaginary, and the Domestication of Arcade Games
2015
[12]
잡지
The CGW Computer Game Conference
http://www.cgwmuseum[...]
1984-10
[13]
잡지
64/128 Gallery
https://archive.org/[...]
1987-01
[14]
서적
The Addison-Wesley Book of Atari Software
https://archive.org/[...]
Addison-Wesley
[15]
뉴스
Beyond Castle Wolfenstein
https://archive.org/[...]
1985-05
[16]
잡지
Dispatches / Insights From the Strategy Game Design Front
http://www.cgwmuseum[...]
1984-12
[17]
웹사이트
The Game Collection
http://www.ozarksoft[...]
2017-10-04
[18]
잡지
The Evolution of Commodore Graphics
https://archive.org/[...]
1986-06
[19]
서적
"[[Ultimate History of Video Games]]"
"[[Three Rivers Press]]"
[20]
서적
The Ultimate History of Video Games
"[[Three Rivers Press]]"
[21]
웹사이트
特集:Windowsストアアプリ開発最新情報(Build 2014より):ユニバーサルWindowsアプリ開発の勧め (1/4) - @IT
https://atmarkit.itm[...]
[22]
웹사이트
'[Windows 10 Mobileで何が変わる? マイクロソフト高橋氏に聞く] iPhone、Androidからもアプリ移行を促すMSの本気 - ケータイ Watch'
https://k-tai.watch.[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com