Compatibility ko KR

호환성

ASF는 .NET 플랫폼에서 실행되는 C# 애플리케이션입니다. 즉, ASF는 CPU에서 실행되는 **기계어(machine code)**로 직접 컴파일되는 것이 아니라, 실행을 위해 CIL 호환 런타임이 필요한 **CIL**로 컴파일됩니다.

이 방식은 엄청난 장점을 가지고 있는데, CIL이 플랫폼에 독립적이기 때문에 ASF가 Windows, Linux, macOS를 비롯한 다양한 OS에서 네이티브로 실행될 수 있습니다. 에뮬레이션이 필요 없을 뿐만 아니라, CPU SSE 명령어와 같은 플랫폼 및 하드웨어 관련 최적화도 모두 지원됩니다. 이 덕분에 ASF는 완벽한 호환성과 신뢰성을 유지하면서도 뛰어난 성능과 최적화를 달성할 수 있습니다.

즉, ASF는 특정 OS를 요구하지 않습니다. 필요한 것은 해당 OS 자체가 아니라 정상 작동하는 런타임이기 때문입니다. 해당 런타임이 ASF 코드를 제대로 실행하기만 한다면, 기반 OS가 Windows, Linux, macOS, BSD, 소니 플레이스테이션 4, 닌텐도 Wii, 심지어 여러분의 토스터이든 상관없습니다 – .NET이 존재하는 한, 그에 대응하는 **ASF**도 존재합니다(generic 버전으로).

다만, ASF를 어디서 실행하든 관계없이, 대상 플랫폼에 **.NET 필수 구성 요소**가 설치되어 있는지 반드시 확인해야 합니다. 이는 런타임이 제대로 동작하는 데 필요한 저수준(low-level) 라이브러리이며, ASF가 애초에 작동하기 위한 핵심 요소입니다. 아마 그 중 일부(혹은 전부)는 이미 설치되어 있을 가능성이 높습니다.

---

ASF 패키징

ASF는 크게 2가지 형태로 제공됩니다 – generic 패키지와 OS별(OS-specific) 패키지입니다. 기능적으로 두 패키지는 완전히 동일하며, 둘 다 자동 업데이트가 가능합니다. 유일한 차이점은 ASF generic 패키지가 이를 구동할 OS별(OS-specific) 런타임을 함께 포함하는지 여부입니다.

---

일반

Generic 패키지는 특정 머신 전용 코드를 포함하지 않는, 플랫폼에 구애받지 않는(platform-agnostic) 빌드입니다. 이 구성을 사용하려면 여러분의 OS에 적절한 버전의 .NET 런타임이 이미 설치되어 있어야 합니다. 의존성을 최신 상태로 유지하는 게 얼마나 번거로운지는 다들 아실 텐데, 이 패키지는 주로 .NET을 이미 사용 중인 사용자를 위한 것입니다. 이미 설치된 것을 활용할 수 있다면 굳이 ASF만을 위해 별도의 런타임을 중복 설치하고 싶지 않은 분들을 위한 옵션입니다. 또한 Generic 패키지를 사용하면 정상 작동하는 .NET 런타임을 구할 수 있는 한 ASF를 어디서든 실행할 수 있으며, 이는 해당 OS용 ASF 빌드가 존재하는지 여부와는 무관합니다.

단순히 ASF가 작동하기만 하면 되고 .NET의 기술적인 세부사항까지 파고들고 싶지 않은 일반 사용자, 혹은 고급 사용자라 하더라도 generic 버전 사용은 권장하지 않습니다. 다시 말해, 이게 무엇인지 이해하고 계신다면 사용하셔도 되지만, 그렇지 않다면 아래에서 설명하는 OS별(OS-specific) 패키지를 사용하시는 편이 훨씬 낫습니다.

---

OS 특화

OS별(OS-specific) 패키지는 generic 패키지에 포함된 managed 코드 외에도, 해당 플랫폼 전용 native 코드를 함께 포함합니다. 다시 말해, OS별(OS-specific) 패키지는 적절한 .NET 런타임을 이미 내장하고 있어서, 번거로운 설치 과정을 완전히 건너뛰고 바로 ASF를 실행할 수 있습니다. OS별 패키지는 이름에서 짐작할 수 있듯이 OS마다 별도의 버전이 필요합니다 – 예를 들어 Windows는 PE32+ 형식의 ArchiSteamFarm.exe 바이너리가 필요하고, Linux는 Unix ELF 형식의 ArchiSteamFarm 바이너리로 작동합니다. 아시다시피 이 두 형식은 서로 호환되지 않습니다.

현재 ASF는 다음과 같은 OS별 버전으로 제공됩니다:

• linux-arm은 glibc 2.35/musl 1.2.3 이상을 사용하는 32비트 ARM 기반(ARMv7+) GNU/Linux OS에서 작동합니다. 이 버전은 Raspberry Pi 2(및 이후 모델)와 같은 플랫폼을 지원하며, Raspberry Pi 0 & 1에 탑재된 ARMv6와 같은 구형 ARM 아키텍처에서는 작동하지 않습니다. 또한 필요한 GNU/Linux 환경을 구현하지 않은 OS(예: Android)에서도 작동하지 않습니다.
• linux-arm64는 glibc 2.27/musl 1.2.3 이상을 사용하는 64비트 ARM 기반(ARMv8+) GNU/Linux OS에서 작동합니다. 이 버전은 Raspberry Pi 3(및 이후 모델)와 같은 플랫폼을 지원하며, 필요한 64비트 라이브러리를 사용할 수 없는 32비트 OS(예: 32비트 Raspberry Pi OS)에서는 작동하지 않습니다. 또한 필요한 GNU/Linux 환경을 구현하지 않은 OS(예: Android)에서도 작동하지 않습니다.
• linux-x64는 glibc 2.27/musl 1.2.3 이상을 사용하는 64비트 GNU/Linux OS에서 작동합니다.
• osx-arm64는 macOS 버전 13 이상의 64비트 ARM 기반(Apple silicon) OS에서 작동합니다.
• osx-x64는 macOS 버전 15 이상의 64비트 OS에서 작동합니다.
• win-arm64는 최신 상태의 버전 10, 11 이상의 64비트 ARM 기반(ARMv8+) Windows OS에서 작동합니다.
• win-x64는 최신 상태의 버전 10, 11, Server 2016 이상의 64비트 Windows OS에서 작동합니다.

물론, 사용 중인 OS-아키텍처 조합에 맞는 OS별 패키지가 없더라도, 직접 적절한 .NET 런타임을 설치하고 generic ASF 버전을 실행하실 수 있습니다. 이것이 바로 generic 버전이 존재하는 주된 이유이기도 합니다. Generic ASF 빌드는 플랫폼에 구애받지 않으며, 정상 작동하는 .NET 런타임이 있는 모든 플랫폼에서 실행됩니다. 여기서 중요한 점은, ASF가 필요로 하는 것은 특정 OS나 아키텍처가 아니라 .NET 런타임이라는 것입니다. 예를 들어 32비트 Windows를 사용 중이라면, 전용 win-x86 ASF 버전이 없더라도 win-x86 버전의 .NET SDK를 설치하고 generic ASF를 문제없이 실행할 수 있습니다. 존재하는 모든 OS-아키텍처 조합을 전부 지원할 수는 없기 때문에, 어딘가에는 선을 그을 수밖에 없습니다. x86이 바로 그 대표적인 예시로, 최소 2004년부터 이미 구식(obsolete) 아키텍처가 되었습니다.

.NET 10.0이 지원하는 전체 플랫폼 및 OS 목록은 **릴리스 노트**를 참고하세요.

---

런타임 요구사항

OS별(OS-specific) 패키지를 사용 중이라면 런타임 요구사항을 걱정할 필요가 없습니다. ASF는 항상 필요한 최신 런타임을 함께 제공하며, **.NET 필수 구성 요소**가 설치되어 있고 최신 상태이기만 하면 정상적으로 작동합니다. 다시 말해, .NET 런타임이나 SDK를 별도로 설치할 필요가 없습니다. OS별 빌드는 오직 네이티브 OS 의존성(필수 구성 요소)만을 필요로 할 뿐, 그 외에는 아무것도 필요하지 않기 때문입니다.

하지만 generic ASF 패키지를 실행하려는 경우에는, 사용 중인 .NET 런타임이 ASF가 요구하는 플랫폼을 지원하는지 반드시 확인해야 합니다.

ASF는 프로그램으로서 현재 .NET 10.0(net10.0)을 타겟으로 하고 있지만, 향후 더 최신 플랫폼을 타겟으로 할 수도 있습니다. net10.0은 10.0.100 SDK(10.0.0 런타임)부터 지원되지만, ASF는 컴파일 시점의 최신 런타임을 선호할 수 있으므로, 사용 중인 컴퓨터에 최신 SDK(또는 최소한 최신 런타임)가 준비되어 있는지 확인하시는 것이 좋습니다. 컴파일 당시 명시된 최소 지원 버전보다 런타임이 낮을 경우, generic ASF 버전은 실행을 거부할 수 있습니다.

확실하지 않다면, GitHub에서 ASF 릴리스를 컴파일하고 배포할 때 저희 continuous integration이 사용하는 것을 확인해보세요. 모든 빌드에서 .NET 검증 단계의 일부로 dotnet --info 출력을 확인할 수 있습니다.