Swift | ABI Stability - ABI 안정성

 

    오늘은 호랑이 담배피던 시절 얘기를 해보겠습니다

출처 : 한국저작권위원회

 

   Swift 5.0 이전의 환경은 버전이 바뀔 때마다 호환성 문제가 발생했습니다

  버전이 바뀔때마다 ABI도 함께 변경되는 바람에 개발자의 고생이 늘어났습니다

  버전만 달라졌는데 같은 코드도 실행이 되지 않는 대환장의 시대였던 것이죠

  그러면 대체 ABI가 뭐길래 선배 개발자분들이 고생을 하셨을까요?

⎮ Binary

    ABI를 이해하기 전에 Binary에 대해 알아야 합니다

   Binary는 0과 1로 이루어진 이진수 코드로 표현되는 데이터 또는 파일 형태를 의미합니다

 

    우리가 작성하는 코드는 Binary가 아닙니다

   우리가 코드(고수준 언어)를 작성하면, 컴파일러는 이 코드를 컴퓨터가 직접 실행할 수 있는 기계어(저수준 언어)로 바꿔줍니다

   컴파일은 소스 코드를 실행 가능한 바이너리 파일로 만드는 과정이고, 바이너리가 바로 이 결과물입니다

func sayHello() -> String {
    return "Hello"
}

 

   이러한 코드는, 다음과 같은 기계어로 변환됩니다

00000000: 11001111 11111010 11101101 11111110 00001100 00000000  ......
00000006: 00000000 00000001 00000000 00000000 00000000 00000000  ......
0000000c: 00000010 00000000 00000000 00000000 00100001 00000000  ....!.
00000012: 00000000 00000000 10010000 00001001 00000000 00000000  ......
00000018: 10000101 00000000 00100000 00000000 00000000 00000000  .. ...
0000001e: 00000000 00000000 00011001 00000000 00000000 00000000  ......
00000024: 01001000 00000000 00000000 00000000 01011111 01011111  H...__
0000002a: 01010000 01000001 01000111 01000101 01011010 01000101  PAGEZE
00000030: 01010010 01001111 00000000 00000000 00000000 00000000  RO....
00000036: 00000000 00000000 00000000 00000000 00000000 00000000  ......

 

   물론 바로 0과 1로 된 기계어로 바뀌는 것은 아니고, 중간 단계를 거치긴 합니다만 

  위의 결과물이 바로 Binary입니다

   (Swift 코드 → Intermediate Representation (IR) → 어셈블리 코드 → 기계어) 

 

⎮ ABI

    Binary를 이해했으니, ABI로 넘어가보겠습니다

 

    처음 ABI를 보고 '어? API 오타 아니야?' 하셨다면 제대로 보신거라고 할 수 있습니다

   둘다 인터페이스는 맞지만 적용되는 영역이 다릅니다

   API는 Application Programming Interface이고, ABI는 Application Binary Interface이기 때문입니다

 

    API는 소프트웨어 애플리케이션들이 서로 통신 및 상호작용할 수 있는 규칙(소스코드와 라이브러리, 프레임워크 간의 호출 방식 등)이고,

   ABI도 바이너리 수준의 규칙(함수 호출 방식, 메모리 레이아웃, 타입 표현 방식 등)입니다

 

    이를 비교해보면 다음과 같습니다

구 분	API	ABI
대 상	소스 코드	바이너리 코드
호환성	소스 코드 수준	바이너리 수준
독립성	프로그래밍 언어, 컴파일러, 운영체제 등에 독립적임	운영체제, 하드웨어 아키텍처, 컴파일러 등에 종속적
주요 목적	프로그램 간의 기능 공유 및 재사용	서로 다른 시스템에서 빌드된 바이너리 모듈 간의 호환성 보장

 

   ABI가 다루는 주요 규약은 다음과 같습니다

   1. 기계 아키텍처 사항
       - CPU 명령어, 런타임 메모리 레이아웃, 빅 엔디안/ 리틀 엔디안, 레지스터 등
   2. 함수 호출 규칙
       - 스택 메모리 구조나 인수의 푸시 순서 등
   3. 데이터 유형
       - 데이터 유형의 크기, 정렬 정책 등
   4. 동적 링킹
   5. 프로그램 로딩 등
 즉, ABI는 프로그램의 '기계어', '오브젝트 파일'들이 기계 수준에서 호환되도록 보장하는 것

* 빅 엔디안: 메모리에 데이터를 저장할 때 큰 값(byte)를 먼저 저장하는 것
* 리틀 엔디안: 메모리에 데이터를 저장할 때 작은 값(byte)을 먼저 저장하는 것
* 동적 링킹: 실행 파일을 만들 때 프로그램에서 사용하는 모든 라이브러리 모듈의 주소만을 가지고 있다가, 런타임에 실행 파일과 라이브러리가 메모리에 위치될 때 해당 모듈의 주소로부터 필요한 것을 연결하는 방식

   길게 작성했지만 쉽게 말하자면

  ABI는 컴파일된 바이너리끼리 어떻게 통신할 것인지에 대한 방법을 정해놓은 것입니다

 

함수의 이름을 어떻게 이름짓는지 ($s4main5greety...)
String을 메모리에 어떻게 배치하는지
함수 호출 시 인자를 어디 레지스터에 넣는지
리턴 값은 어디서 꺼내가는지
.
.
.

 

   이를 통해 ABI는 프로그램의 기계어와 오브젝트 파일들이 호환되도록 보장해줍니다

 

⎮ ABI Stability(feat. Swift 5.0)

    사실 지금은 Swift 5버전을 사용하다가 Swift 6로 변경해도 큰 문제가 발생하지는 않지만,

   이전에는 그렇지 않았습니다 

 

    ABI가 안정화 된 것은 Swift 5.0부터이고, 

    이전 버전에서는 버전마다 컴파일된 바이너리끼리의 규칙이 달라졌기 때문이죠

 

   Swift 버전 4의 규칙과 Swift 버전 5의 규칙이 다르면 어떻게 될까요?

   Swift 4로 빌드된 프레임워크를 Swift 5로 만든 앱에서 사용하려고 하면,

  링크 에러 또는 크래시가 발생했습니다

 

   ABI가 다르다는 것은 단순히 함수 호출 방법이 달라지는 것 뿐만 아니라

  내부적으로 함수의 이름을 어떻게 짓는지에 대한 규칙도 다른 것이라서

  이전 버전에서 작성한 함수를 올바르게 연결하지 못하거나 잘못된 주소를 참조하는 등의 문제를 발생시켰습니다

 

   가장 큰 문제는, ABI가 안정화되어 있지 않아서

  Swift 런타임과 표준 라이브러리를 앱 내부에 매번 포함해야했습니다

  그 결과 앱의 크기가 커지는 효율적인 상황이 생겨버린 것이죠

 

    이를 보완하기 위해 Swift 5부터는 ABI가 고정(안정화)되었습니다

   ABI가 고정되었다는 말은 Swift 런타임과 표준 라이브러리를 운영체제가 담당한다는 말과 동일합니다

   이제부터는 개발자가 별도의 Swift 런타임 파일을 앱에 포함하지 않아도

   시스템이 동일한 ABI 규칙에 따라 알아서 처리해주는 구조가 된 것입니다

 

   따라서, Swift 5에서 다음 버전인 Swift 6로 버전업이 되더라도 큰 호환성 문제 없이 안정적으로 이전할 수 있게 되었습니다

⎮ 결론

   ABI는 바이너리 규칙, Swift 5 이전 버전은 이 규칙이 달라서 에러가 많이 발생했고 개발 리소스가 많이 들었습니다

  개발자는 별도의 Swift 런타임 파일을 앱에 포함해줘야했고, 용량도 커졌습니다

 

  Swift 5부터 ABI가 안정화되면서 시스템이 Swift 런타임과 표준 라이브러리를 담당하게 되어 이 문제가 해결되었습니다

 

⎮ reference

   Base: SeSAC 내부 비공개 강의 자료

 

http://www.ktword.co.kr/test/view/view.php?m_temp1=3563

ABI

 

https://velog.io/@wansook0316/ABI-Stability

ABI Stability

 

https://gitminam.com/ios/abistability/

[Swift] ABI stability란?