이식 (컴퓨팅)

소프트웨어 공학에서 이식(移植) 또는 포팅(porting)은 주어진 프로그램이 원래 설계된 컴퓨팅 플랫폼과 다른 환경(예: 다른 CPU, 운영체제, 또는 제3자 라이브러리)에서 실행될 수 있도록 소프트웨어를 조정하는 과정이다. 이 용어는 소프트웨어/하드웨어를 다른 환경에서 사용할 수 있도록 변경하는 경우에도 사용된다.^[1][2]

소프트웨어는 새로운 플랫폼으로 이식하는 비용이 처음부터 다시 작성하는 비용보다 훨씬 적을 때 이식 가능하다고 말한다. 소프트웨어 이식 비용이 구현 비용에 비해 낮을수록 이식성이 높다고 말한다. 이는 단일 "네이티브" 플랫폼 없이 처음부터 설계된 크로스 플랫폼 소프트웨어와는 구별된다.

어원

"포트"라는 용어는 라틴어 portāre에서 유래했으며, "운반하다"라는 의미이다.^[3] 코드가 특정 운영체제 또는 아키텍처와 호환되지 않을 때, 코드는 새 시스템으로 "운반"되어야 한다.

이 용어는 동일한 CPU 및 운영체제에서 더 적은 메모리로 실행되도록 소프트웨어를 조정하는 과정에는 일반적으로 적용되지 않는다.

소프트웨어 개발자들은 종종 자신들이 작성한 소프트웨어가 이식 가능하다고 주장하는데, 이는 새로운 환경에 맞게 조정하는 데 노력이 거의 필요하지 않다는 의미이다. 실제로 필요한 노력의 양은 원래 환경(소스 플랫폼)이 새 환경(대상 플랫폼)과 얼마나 다른지, 원래 작성자가 어떤 프로그래밍 언어 구성 요소 및 제3자 라이브러리 호출이 이식성이 없을 가능성이 있는지 아는 경험, 그리고 원래 작성자가 이식 가능한 구성 요소만 사용하는 데 투자한 노력의 양 등 여러 요인에 따라 달라진다(플랫폼 특정 구성 요소는 종종 더 저렴한 해결책을 제공한다).

역사

오늘날 데스크톱에서 사용되는 상당히 다른 CPU와 운영 체제의 수는 과거보다 훨씬 적다. X86 아키텍처의 지배로 인해 대부분의 데스크톱 소프트웨어는 다른 CPU로 이식되지 않는다. 같은 시장에서 운영 체제 선택은 사실상 마이크로소프트 윈도우, MacOS, 리눅스 세 가지로 줄었다. 그러나 임베디드 시스템 및 모바일 시장에서는 이식성이 여전히 중요한 문제이며, ARM이 널리 사용되는 대안이다.

ISO가 공포한 국제 표준은 컴퓨팅 환경의 세부 사항을 명시하여 서로 다른 표준 준수 플랫폼 간의 차이를 줄이는 데 도움을 줌으로써 이식을 크게 용이하게 한다. 이러한 표준에서 지정된 범위 내에서 소프트웨어를 작성하는 것은 실용적이지만 사소하지 않은 노력이다. 두 개의 표준 준수 플랫폼(예: POSIX.1) 간에 이러한 프로그램을 이식하는 것은 단순히 소스 코드를 로드하고 새 플랫폼에서 재컴파일하는 문제일 수 있지만, 실무자들은 미묘한 플랫폼 차이로 인해 다양한 사소한 수정이 필요하다는 것을 종종 발견한다. 대부분의 표준은 표준 해석의 차이가 플랫폼마다 약간의 변형으로 이어지는 "회색 영역"으로 인해 어려움을 겪는다.

또한 GNU 컴파일러 모음과 같이 다른 플랫폼에서 일관된 프로그래밍 언어를 제공하는 도구, 그리고 오토툴즈와 같이 환경의 사소한 변형을 자동으로 감지하고 컴파일 전에 소프트웨어를 그에 맞게 조정하는 도구 등 이식을 용이하게 하는 도구들이 계속해서 증가하고 있다.

일부 고급 프로그래밍 언어(예: 에펠, 에스테렐)의 컴파일러는 다른 고급 중간 언어(예: C)로 소스 코드를 출력하여 이식성을 확보하는데, 이 언어는 여러 플랫폼용 컴파일러가 일반적으로 사용 가능하다.

이식과 관련이 있지만 다른 두 가지 활동은 에뮬레이션과 크로스 컴파일이다.

컴파일러 이식

최신 컴파일러는 기계어로 직접 번역하는 대신, 컴파일러의 이식성을 높이고 설계 노력을 최소화하기 위해 기계 독립적인 중간 언어로 번역한다. 중간 언어는 모든 중간 언어로 작성된 프로그램을 실행할 수 있는 가상 머신을 정의한다(기계는 언어에 의해 정의되고 그 반대도 마찬가지이다).^[4] 중간 코드 명령어는 코드 생성기에 의해 동등한 기계어 시퀀스로 번역되어 실행 파일을 생성한다. 또한 인터프리터 또는 JIT를 가상 머신용으로 실제로 구현하여 기계어 생성을 건너뛸 수도 있다.^[5]

중간 코드의 사용은 컴파일러의 이식성을 향상시킨다. 왜냐하면 컴파일러 자체의 기계 종속 코드(인터프리터 또는 코드 생성기)만 대상 기계로 이식하면 되기 때문이다. 컴파일러의 나머지 부분은 중간 코드로 가져와서 이식된 코드 생성기 또는 인터프리터에 의해 추가로 처리될 수 있으므로 컴파일러 소프트웨어를 생성하거나 인터프리터에서 중간 코드를 직접 실행할 수 있다. 기계 독립적인 부분은 다른 기계(호스트 머신)에서 개발 및 테스트할 수 있다. 이는 설계 노력을 크게 줄이는데, 기계 독립적인 부분은 이식 가능한 중간 코드를 생성하기 위해 한 번만 개발하면 되기 때문이다.^[6]

인터프리터는 코드 생성기보다 덜 복잡하고 따라서 이식하기 쉽다. 왜냐하면 프로그램 코드에 대한 제한적인 시야(한 번에 하나의 명령만 볼 수 있으며, 최적화를 위해서는 시퀀스가 필요하다)로 인해 코드 최적화를 수행할 수 없기 때문이다. 일부 인터프리터는 기본 하드웨어의 명령어 집합에 대한 최소한의 가정만을 하기 때문에 이식하기 매우 쉽다. 결과적으로 가상 머신은 대상 CPU보다 훨씬 간단하다.^[7]

컴파일러 소스를 컴파일러가 번역해야 하는 프로그래밍 언어로 전적으로 작성하면, 컴파일러 부트스트랩으로 더 잘 알려진 다음 접근 방식을 대상 기계에서 실현할 수 있다.

1. 인터프리터를 이식한다. 이것은 대상에 이미 있는 어셈블러를 사용하여 어셈블리어로 코딩되어야 한다.
2. 코드 생성기 소스를 새 기계에 맞게 조정한다.
3. 코드 생성기 소스를 입력으로 사용하여 인터프리터로 조정된 소스를 실행한다. 이것은 코드 생성기용 기계어를 생성한다.

최적화 루틴을 코딩하는 어려운 부분은 대상의 어셈블리어 대신 고급 언어를 사용하여 수행된다.

BCPL 언어의 설계자들에 따르면, (BCPL의 경우) 해석된 코드는 기계어보다 더 압축적이며, 일반적으로 2대 1의 비율이다. 그러나 해석된 코드는 동일한 기계에서 컴파일된 코드보다 약 10배 느리게 실행된다.^[8]

자바 프로그래밍 언어의 설계자들은 해석된 코드의 압축성을 활용하려고 한다. 왜냐하면 자바 프로그램이 대상의 JVM에서 실행을 시작하기 전에 인터넷을 통해 전송되어야 할 수도 있기 때문이다.

비디오 게임의 이식

이식은 아케이드 게임, 비디오 게임 콘솔 또는 개인용 컴퓨터와 같은 한 플랫폼에서 실행되도록 설계된 비디오 게임을 약간의 차이를 두어 다른 플랫폼에서 실행되도록 변환하는 데 사용되는 용어이기도 하다.^[9] 비디오 게임 초기부터 1990년대까지 "포트"는 종종 "컨버전"으로 불렸으며, 다른 시스템의 한계로 인해 실제 포트가 아니라 게임의 재작업 버전인 경우가 많았다. 예를 들어, 그래픽 이미지가 추가된 텍스트 어드벤처 게임인 1982년 게임 더 호빗은 포트가 개발된 다양한 개인용 컴퓨터에서 그래픽 스타일이 상당히 달랐다.^[10] 그러나 21세기 많은 비디오 게임은 실제 이식 없이 하나 이상의 콘솔과 PC용 코드를 출력할 수 있는 소프트웨어(종종 C++로)를 사용하여 개발된다(대신 개별 구성 요소 라이브러리의 공통 이식에 의존한다).^[10]

성능이 떨어지는 하드웨어로 아케이드 게임을 가정용 시스템으로 이식하는 것은 어려웠다. 아타리 2600용 팩맨 이식 버전은 롬 공간 부족과 여러 유령이 화면에 나타날 때 깜박이는 효과를 일으키는 하드웨어 문제를 보완하기 위해 원본 게임의 시각적 특징 중 많은 부분을 생략했다. 일부 학자들은 아타리 2600 팩맨의 저조한 성능을 1983년 비디오 게임 위기의 원인 중 하나로 꼽는다.^[11]

초기 이식작들은 컴퓨터가 크게 달랐기 때문에 상당한 게임 플레이 품질 문제를 겪었다.^[12] 리처드 개리엇은 1984년 오리진스 게임 페어에서 오리진 시스템즈가 애플 II용 비디오 게임을 먼저 개발한 다음 코모도어 64와 아타리 8비트 제품군으로 이식했다고 밝혔다. 후자 기기들의 스프라이트 및 기타 정교한 기능들 때문에 애플로의 이식이 "훨씬 더 어렵고, 심지어 불가능할 수도 있었기 때문"이라고 설명했다.^[13] 리뷰들은 애플의 "구린 사운드와 흑백-녹색-보라색 그래픽"을 유지하는 "애플 전환병"으로 고통받는 이식작들에 대해 불평했다.^[14][15][16] 개리엇의 발언 이후, 댄 번튼이 "청중의 아타리 및 코모도어 사용자 여러분, 애플 재작성에 만족하십니까?"라고 묻자 청중은 "아니요!"라고 외쳤다. 개리엇은 "[그렇지 않으면] 애플 버전은 결코 완성되지 않을 것입니다. 퍼블리셔의 관점에서 그것은 돈이 되지 않습니다"라고 답했다.^[13]

다른 곳에서는 다르게 작업했다. 예를 들어 오자크 소프트스케이프는 가장 발전된 컴퓨터용으로 개발하는 것을 선호했기 때문에 M.U.L.E.를 아타리용으로 먼저 작성했고, 이식 과정에서 필요한 경우 기능을 제거하거나 변경했다. 이러한 정책이 항상 실현 가능했던 것은 아니었다. 번튼은 "M.U.L.E.는 애플용으로 만들 수 없다"고 밝혔으며,^[12] 더 세븐 시티즈 오브 골드의 아타리 버전이 아닌 버전들은 열등했다고 말했다.^[17] 컴퓨트!의 가제트는 1986년에 아타리에서 코모도어로 이식할 때 원본이 보통 더 우수하다고 썼다. 이 잡지는 1983년 후반에 개발자들이 코모도어용으로 새로운 소프트웨어를 만들기 시작하면서 후자의 게임 품질이 향상되었다고 밝혔다.^[18]

아케이드 게임 이식에서 "아케이드 퍼펙트" 또는 "아케이드 정확"이라는 용어는 이식된 버전의 게임 플레이, 그래픽 및 기타 자산이 아케이드 버전과 얼마나 가깝게 일치하는지를 설명하는 데 자주 사용되었다. 1980년대 초의 많은 아케이드 포트들은 가정용 콘솔과 컴퓨터가 아케이드 게임의 정교한 하드웨어를 갖추지 못했기 때문에 아케이드 퍼펙트와는 거리가 멀었지만, 게임은 여전히 게임 플레이를 근사화할 수 있었다. 특히 스페이스 인베이더는 아타리 VCS에서 차이점에도 불구하고 콘솔의 킬러 앱이 되었으며,^[19] 이후 팩맨 포트는 아케이드 버전과의 불일치로 악명이 높았다.^[20] 아케이드 시스템의 성능을 가정용 콘솔이 따라잡기 시작하면서 1990년대부터 아케이드 정확 게임이 더욱 보편화되었다. 특히 SNK에서 출시된 네오지오 시스템은 다중 게임 아케이드 시스템으로 소개되었으며, 동일한 사양의 가정용 콘솔로도 제공되었다. 이를 통해 아케이드 퍼펙트 게임을 집에서 플레이할 수 있게 되었다.^[10]

"콘솔 포트"는 원래 또는 주로 콘솔용으로 제작된 게임이 개인용 컴퓨터에서 플레이할 수 있는 버전으로 만들어지는 것을 의미한다. 콘솔에서 PC로 게임을 이식하는 과정은 다른 유형의 포트보다 더 회의적으로 여겨지는 경우가 많은데, 이는 일부 PC가 콘솔 출시 당시에도 더 강력한 하드웨어를 가지고 있었음에도 불구하고 이를 충분히 활용하지 못하며, 부분적으로는 콘솔 하드웨어가 각 세대 동안 고정되어 있는 반면 새로운 PC는 끊임없이 더 강력해지기 때문이다. 오늘날에는 대체로 유사하지만, 통합 메모리 사용과 콘솔의 더 작은 OS와 같은 일부 아키텍처적 차이점은 여전히 존재한다. 다른 반대 의견은 게임패드, 좁은 FoV를 동반하는 TFUI, 고정된 체크포인트, 공식 서버 또는 P2P로 제한된 온라인, 미흡하거나 없는 모드 지원, 그리고 일반적으로 콘솔 개발자들이 외부 API와 구성 가능성 대신 내부 하드 코딩과 기본값에 더 많이 의존하는 것과 같은 콘솔에 일반적으로 사용되는 사용자 인터페이스 차이에서 비롯된다. 이 모든 것은 "게으른" PC 포트를 피하기 위해 비용이 많이 드는 심층적인 재설계를 요구할 수 있다.^[21]

같이 보기

• 소프트웨어 이식성
• 크로스 플랫폼 소프트웨어
• Write once, compile anywhere
• 프로그램 변환
• 시스템 품질 속성 목록
• 언어 바인딩
• 소스 대 소스 컴파일러
• 콘솔 에뮬레이터
• 소스 포트
• 포슐립