API와 ABI, 20년 전에도 같았을까?

Colin Watson은 API를 라이브러리의 소스 코드 인터페이스로 정의하며, `fopen`과 같은 C 표준 라이브러리 함수의 예시를 들었다. 이는 함수 시그니처, 인자, 반환 값, 그리고 사용 방식에 대한 명확한 정의를 포함한다고 설명한다. 개발자는 이 API 명세를 기반으로 코드를 작성하게 된다.

ABI는 컴파일된 코드가 라이브러리와 상호작용하는 방식을 규정한다. 여기에는 바이트 순서(Byte Order), 포인터 크기(Pointer Size), 스택에서의 인자 전달 방식(Argument Passing Convention) 등 저수준(Low-level) 정보가 포함된다. ABI 호환성이 깨지면 기존 바이너리가 작동하지 않으므로, 라이브러리 버전 관리에서 매우 중요하다.

ABI 변경은 소스 코드 수정 없이 재컴파일만으로 해결될 수 있는 경우가 많다. 예를 들어, 구조체 끝에 멤버를 추가하거나 새로운 함수를 추가하는 것은 ABI 호환성을 유지하면서 인터페이스를 확장하는 방법이다. 반면 API가 비호환적으로 변경되면, 라이브러리 사용자는 소스 코드 자체를 수정해야 하는 부담을 안게 된다.

라이브러리의 ABI가 역호환성을 깨뜨리며 변경될 경우, 해당 라이브러리의 소네임(Soname)이 변경되어야 한다. 이는 패키지 관리 시스템(예: Debian의 dpkg)이 의존성을 정확히 추적하고 관리하는 데 필수적이다. 호환 가능한 ABI 변경의 경우에도, 변경 이력을 추적하여 의존성 관리의 투명성을 확보하는 것이 중요하다고 언급된다.

Lobsters 커뮤니티에서는 2004년의 오래된 이메일 스레드를 공유한 이유에 대한 질문이 있었다. 이에 대해 다른 사용자는 API는 잘 알지만 ABI의 중요성이나 불안정성으로 인한 문제점은 잘 몰랐던 배경에서 흥미를 느꼈다고 답했다. 이는 ABI의 개념과 중요성이 여전히 개발자들에게는 명확히 인지되지 않을 수 있음을 시사한다.