컴파일러부터 아카이빙까지 - ABI

Tabber·2026년 2월 1일

Swift

목록 보기

13/15

iOS 개발자라면,,한번쯤은 공부하고 싶던 부분인 컴파일 - 아카이빙 까지의 모든 과정을 공부해봐요.

목차는 다음과 같아요.

LLVM
ABI
Static vs Dynamic Linking
ODR
아카이빙, 앱 사이닝
Bitcode, App Thinning

오늘은 ABI에 대해 알아보아요.

ABI (Application Binary Interface) 를 쉽게 비유하자면, API 가 ‘소스 코드 수준’에서의 약속 이라면, ABI는 ‘이미 컴파일된 바이너리 수준’에서의 약속이에요.

ABI란 정확히 무엇인가요?

우리가 만든 앱은 혼자 돌아가지 않아요. iOS 운영체제에 내장된 라이브러리(Foundation, UIKit 등)와 끊임없이 소통해야 하죠. 이때 “데이터를 어떤 메모리 위치에 놓을지”, “함수를 호출할 때 파라미터를 어떤 순서로 전달할지”에 대한 엄격한 규칙이 필요한데, 이것이 바로 ABI 에요.

주요 포함 사항은 다음과 같아요.

함수 호출 규약 (Calling Convention) : 함수를 부를 때 인자값들을 레지스터에 넣을지, 스택에 넣을지 결정해요.
데이터 레이아웃 : 구조체의 변수들이 메모리에 어떤 순서로, 몇 바이트씩 떨어져서 저장될지 결정해요.
이름 관리 : SIL에서 봤던 그 복잡한 이름들을 어떻게 생성하고 해석할지에 대한 규칙이에요.

조금 더 자세히 알아볼게요.

함수의 ‘이름’ 그 이상 : Calling Convention (호출 규약)

ABI의 핵심 중 하나는 함수를 호출할 때 CPU 레지스터와 스택을 어떻게 나눠 쓸지에 대한 약속이에요. 이 규칙은 CPU의 성능을 최대로 끌어올리기 위함이에요. 메모리(RAM)에 접근하는 것 보다 레지스터를 쓰는게 훨씬 빠르기 때문이죠.

func calculate(a: Int, b: Int, c: Int) -> Int {
    return a + b + c
}

// ABI 약속 (x86_64 아키텍처 예시)
// 1. a는 %rdi 레지스터에 담아라
// 2. b는 %rsi 레지스터에 담아라
// 3. c는 %rdx 레지스터에 담아라
// 4. 결과값은 %rax에 담아서 돌려줘라

파라미터 전달 : 첫 번째 인자는 %rdi 레지스터에, 두 번째는 %rsi 에 넣는다는 식의 규칙이에요.
리턴값 처리 : 함수가 끝날 때 결과값을 어디에 두고 갈지도 약속되어 있어요.
Self의 위치 : Swift 메서드에서 self 는 보통 특정 레지스터에 고정적으로 담겨요.

이게 왜 중요하냐면, 만약 Swift와 C++이 서로 대화한다면 이 규칙이 서로 다르기 때문에 중간에 Bridge 역할을 하는 코드가 필요하게 돼요.

Swift ABI 문서에 따르면, Swift는 구조체나 Enum이 작을 경우 이를 여러 개의 레지스터에 나누어 담는 'Physical Lowering' 과정을 거쳐요.

또한, Enum이 비트 최적화를 통해 8바이트 안에 모든 정보를 담았다면, ABI는 이를 하나의 64비트 레지스터 (ex. %rdi ) 에 담아 보낼 수 있게 돼요. 만약 최적화 규칙이 ABI에 고정되어 있지 않다면, 컴파일러는 이 데이터를 레지스터에 어떻게 효율적으로 나눠 담을지 결정할 수 없어요.

Memory Layout (데이터의 생김새)

ABI는 구조체나 클래스가 메모리에 어떤 모습으로 누워있을지를 결정해요.

struct MixedData {
    var a: Int8   // 1 byte
    var b: Int    // 8 bytes (64-bit 시스템 기준)
    var c: Int8   // 1 byte
}

print(MemoryLayout<MixedData>.size)      // 실제 데이터 크기: 10 bytes
print(MemoryLayout<MixedData>.stride)    // 실제 차지하는 공간: 24 bytes (Padding 발생!)

Alignment (정렬): Int64는 8바이트 단위로 시작하는 주소에 배치해야 CPU가 빨리 읽어요. ABI는 데이터 사이에 Padding(빈 공간)을 얼마나 넣을지 규칙을 정해요.
배치 순서: Swift는 기본적으로 우리가 선언한 순서대로 메모리에 배치하지만, 성능을 위해 최적화할 수도 있어요. 이 배치가 바뀌면 다른 라이브러리에서 데이터를 읽을 때 엉뚱한 값을 읽게 돼요

Name Mangling (이름 짓기 규칙)

아까 SIL에서 본 @$s8ViewTypeAAO... 같은 이름이 기억나시나요? 이것도 ABI의 영역이에요.

식별자 고유화: Swift는 오버로딩을 지원하므로, 컴파일러는 함수 이름에 파라미터 타입, 모듈명 등을 섞어 고유한 문자열을 만들어요.
복원(Demangling): 우리가 크래시 로그(Symbolication)를 볼 때 읽을 수 없는 문자들이 다시 함수 이름으로 바뀌는 것은, 이 Mangling 규칙이 ABI로 고정되어 있어서 도구가 역으로 해석할 수 있기 때문이에요.

Resilience (탄력성/복원력)

이게 가장 마법 같은 부분이에요. 라이브러리가 업데이트되어 프로퍼티가 추가되어도, 그 라이브러리를 쓰는 앱을 다시 컴파일하지 않아도 되는 기능이에요.

Fragile Base Class 문제 해결: 과거 C++이나 Objective-C는 클래스에 변수가 하나 추가되면 메모리 레이아웃이 싹 바뀌어서 앱이 깨졌어요.
Swift의 해결책: Swift는 변수의 위치를 '고정 수치(Offset)'로 기록하지 않고, 실행 시점에 "이 변수는 어디에 있지?"라고 물어보고 찾는 간접 접근(Indirection) 방식을 써요. 이 "어디에 물어볼지"에 대한 약속도 ABI에 포함돼요.

Swift 5 이전의 고충 : ABI Instability

Swift 4까지는 이 ABI가 버전마다 계속 바뀌었어요. 이게 왜 문제였을까요?

Swift 런타임 내장 (App Size 폭발) : iOS OS가 앱이 사용하는 Swift ABI를 이해하지 못했기 때문에, 앱을 만들 때마다 그 버전에 맞는 Swift Runtime Library를 앱 패키지 안에 통째로 집어 넣어야 했어요. (앱 용량이 기본 5~10MB씩 더 컸던 이유에요.)
버전 불일치 : Swift 4로 만든 라이브러리는 Swift 4.2 프로젝트에서 바로 쓸 수 없었어요. 컴파일러 버전이 다르면 바이너리 수준에서 대화가 안 됐기 때문이에요.

Swift 5의 혁명 : ABI Stability

2019년 Swift 5가 발표되면서 드디어 ABI가 고정되었습니다. Apple은 “앞으로 나올 모든 iOS 버전은 Swift 5의 바이너리 규약을 따를게!” 라고 선언한 것이죠.

이로 인해 얻은 이점

OS 내장 런타임 : 이제 모든 아이폰 (iOS 13이상)에는 Swift런타임이 기본 설치되어 있어요. 우리 앱 안에 런타임을 넣을 필요가 없어져서, 앱 용량이 줄어들고 실행속도가 빨라졌어요.
하위 호환성 : Swift 5로 빌드된 앱은 미래에 나올 Swift 6, 7 환경에서도 재컴파일 없이 그대로 실행될 수 있어요.

ABI Stability vs Module Stability

여기서 헷갈리기 쉬운 개념이 하나 더 있어요.

ABI Stability : 런타임의 약속이에요. 내 앱 (Swift 5)이 OS (Swift 6) 위에서 잘 돌아가게 해줘요.
Module Stability : 빌드 시점의 약속이에요. 내가 만든 프레임워크를 다른 개발자가 더 높은 버전의 Xcode에서 import 할 수 있게 해줘요. (이건 .swiftinterface 라는 파일을 통해 해결해요.)

ABI와 PWT의 관계

이전에 알아본 PWT. PWT는 함수 주소록이라고 했죠. ABI가 안정화되었다는 것은 “PWT의 구조가 바뀌지 않는다”는 약속도 포함돼요.

만약 ABI가 바뀌어서 “PWT의 3번째 칸은 이제 함수 주소가 아니라 타입 크기를 넣기로 했어!”라고 해버리면 기존 앱들은 3번째 칸에서 주소를 찾으려다 엉뚱한 곳을 찌르고 크래시가 날 거에요. ABI Stability 는 이런 ‘메모리상의 지도’를 영구히 고정한 것이에요.