번들에 대해
번들 및 패키지의 개념과 시스템에서의 사용방법을 소개합니다.
번들을 사용하면 MacOS와 iOS에서 소프트웨어를 편리하게 제공할 수 있습니다. 번들은 최종 사용자에게 간소화된 인터페이스를 제공하는 동시에 개발지원을 제공합니다. 이 장에서는 번들에 대해 소개하고 매크로 및 iOS에서 번들이 수행하는 역할에 대해 설명합니다.
번들과 패키지
번들과 패키지는 때때로 서로 바꿔서 언급되지만 실제로는 분명히 구분되는 개념입니다.
패키지는 Finder가 사용자에게 단일 파일인 것처럼 표시하는 디렉토리입니다.
번들은 실행 코드와 해당 코드에 사용되는 리소스를 포함하는 표준화된 계층 구조를 가진 디렉토리입니다.
패키지는 MacOS를 사용하기 쉽게 만드는 근본적인 추상화 중 하나를 제공합니다. 컴퓨터에서 볼 수 있는 애플리케이션이나 플러그인들은 사실 실제로는 디렉토리입니다. 패키지 디렉토리에는 애플리케이션이나 플러그인을 실행하는데 필요한 코드 및 리소스 파일이 들어 있습니다. 그러나 패키지 디렉토리와 상호 작용할 때 Finder는 이를 단일 파일처럼 처리합니다. 이러한 동작은 임시 사용자가 패키지의 내용에 부정적인 영향을 미칠 수 있는 변경을 방지합니다. 예를 들면 사용자가 애플리케이션이 제대로 실행되지 않도록 리소스 또는 코드 모듈을 다시 정렬하거나 삭제하지 못하도록 합니다.
알림
패키지는 기본적으로 내용이 가려져 있는(불투명) 파일로 처리되지만 사용자가 내용을 보고 수정할 수는 있습니다. 패키지를 오른쪽 클릭해보면 패키지 내용보기 명령이 있습니다. 이 명령을 선택하면 패키지 디렉토리의 최상위 수준으로 설정된 새 Finder 창이 표시됩니다. 사용자는 이 창을 사용하여 패키지의 디렉토리 구조를 탐색하고 일반 디렉토리 계층인 것처럼 변경할 수 있습니다.
패키지는 사용자 환경을 개선하기 위해 존재하는 반면, 번들은 개발자가 코드를 패키징하고 운영 체제가 해당 코드에 액세스하는 것을 돕기 위해서 설계되었습니다. 번들은 소프트웨어와 관련된 코드 및 리소스를 구성하기 위한 기본 구조를 정의합니다. 또한 이 구조의 존재는 지역화와 같은 중요한 기능을 용이하게 합니다. 번들의 정확한 구조는 애플리케이션, 프레임워크, 플러그인 중에서 어떤것을 생성하는지에 따라서 달라집니다. 또한 타겟 플랫폼 및 플러그인 유형과 같은 다른 요인에 의해서도 결정됩니다.
번들과 패키지가 서로 교환 가능한 것으로 간주되는 이유는 많은 유형의 번들이 동시에 패키지이기도 하기 때문입니다. 예를 들어 애플리케이션과 로드 가능한 번들은 대개 시스템에 의해 불투명 디렉토리로 처리되기 때문에 패키지입니다. 그러나 모든 번들이 패키지는 아니며 그 반대의 경우도 마찬가지입니다.
시스템이 번들과 패키지를 구분하는 방법
다음 조건 중 하나라도 충족되면 Finder는 디렉토리를 패키지로 간주합니다:
다음 파일 이름 확장자를 갖는 디렉토리: .app, .bundle, .framework, .plugin, .kex 등
일부 다른 애플리케이션에서 패키지 유형으로 주장하는 확장명을 갖는 디렉토리 문서 패키지를 참조하세요.
패키지 비트가 설정되어 있는 디렉토리
패키지를 지정하는 기본 방법은 패키지 디렉토리에 알려진 파일 이름 확장자를 지정하는 것입니다. 대부분의 경우 올바른 확장을 적용하는 템플릿을 제공하여 Xcode에서 이 문제를 해결합니다. 적절한 유형의 Xcode 프로젝트를 생성하기만 하면 됩니다.
대부분의 번들이 번들이면서 동시에 패키지입니다. 예를 들어 애플리케이션과 플러그인은 일반적으로 Finder에 의해 단일 파일로 표시됩니다. 그러나 일부 번들 유형에서는 그렇지 않습니다. 특히, 프레임워크는 링크 및 런타임 사용을 위해 단일 단위로 취급되는 번들 유형이지만, 프레임워크 디렉토리는 개발자가 헤더 파일과 포함된 다른 리소스를 볼 수 있게 되어있습니다.
번들 디스플레이 이름에 대해
디스플레이 이름을 사용하면 번들을 사용하는 클라이언트를 손상시키지 않고 Finder에서 번들 및 패키지가 표시되는 방식을 제어할 수 있습니다. 예를 들어 사용자가 파일 이름을 자유롭게 바꾸듯이 애플리케이션이나 프레임워크의 이름을 바꾸면 애플리케이션 또는 프레임워크를 이름으로 참조하는 관련 코드 모듈이 파손될 것입니다. 따라서, 번들에는 피상적인 이름이 존재합니다. 파일 시스템에서 번들 이름을 변경할수 있지만 Finder가 바꾸고 표시하는 문자열은 실제 번들 이름과는 다른 (디스플레이 이름이라고 하는) 별도의 문자열입니다.
번들의 장점
번들이 개발자에게 제공하는 장점은 다음과 같습니다:
번들은 파일 시스템의 디렉토리 계층이기 때문에 번들에는 파일만 포함됩니다. 따라서 다른 유형의 파일을 여는 경우와 마찬가지로 동일한 파일 기반 인터페이스를 사용하여 번들 리소스를 열 수 있습니다.
번들 디렉토리 구조를 사용하면 여러 지역화를 쉽게 지원할 수 있습니다. 새로운 지역화 리소스를 쉽게 추가하거나 원치 않는 리소스를 제거할 수 있습니다.
번들은 HFS, HFS+ 및 AFP와 같은 여러 포크 형식과 UFS, SMB 및 NFS와 같은 단일 포크 형식을 포함하여 다양한 형식의 볼륨에 저장될 수 있습니다.
사용자는 Finder에서 번들을 드래그하여 간단히 번들을 설치, 재배치 및 제거할 수 있습니다.
패키지이기도 하면서 따라서 불투명 파일로 취급되는 번들은 중요한 리소스의 제거, 수정 또는 이름 변경과 같은 우발적인 사용자 수정에 덜 취약합니다.
번들은 여러 개의 칩 아키텍처(PowerPC, Intel)와 다양한 주소 공간 요구 사항(32비트/64비트)을 지원할 수 있습니다. 또한 특수 실행 파일의 포함을 지원할 수 있습니다(예: 특정 벡터 명령 집합에 최적화된 라이브러리).
대부분의 실행 파일 코드는 번들로 제공될 수 있습니다. 애플리케이션, 프레임워크(공유 라이브러리) 및 플러그인은 모두 번들 모델을 지원합니다. 정적 라이브러리, 동적 라이브러리, 셸 스크립트 및 UNIX 명령줄 도구는 번들 구조를 사용하지 않습니다.
번들 응용 프로그램은 서버에서 직접 실행될 수 있습니다. 로컬 시스템에 특수 공유 라이브러리, 확장 및 리소스를 설치할 필요가 없습니다.
번들의 유형
모든 번들은 동일한 기본 기능을 지원하지만, 원하는 용도의 번들을 정의하고 생성하는 방식에는 차이가 있습니다:
애플리케이션 애플리케이션 번들은 실행 가능한 프로세스와 관련된 코드 및 리소스를 관리합니다. 이 번들의 정확한 구조는 대상 플랫폼(iOS 또는 MacOS)에 따라 다릅니다. 애플리케이션 번들 구조에 대한 자세한 내용은 애플리케이션 번들을 참조하세요.
프레임워크 프레임워크 번들은 헤더 파일과 같은 동적 공유 라이브러리 및 관련 리소스를 관리합니다. 애플리케이션은 하나 이상의 프레임워크에 연결하여 포함된 코드를 활용할 수 있습니다. 프레임워크 번들 구조에 대한 자세한 내용은 프레임워크 번들의 분석을 참조하세요.
플러그인 macOS는 다양한 시스템 기능을 위한 플러그인을 지원합니다. 플러그인은 응용 프로그램이 커스텀 코드 모듈을 동적으로 로드하는 방법입니다. 다음 목록은 주로 개발되는 플러그인 유형입니다.
커스텀 플러그인은 개발자의 목적을 위해 정의한 플러그인입니다. 로드 가능한 번들의 분석을 참조하세요.
Image Unit 플러그인은 Core Image 기술에 사용자 지정 이미지 처리 동작을 추가합니다. Image Unit Tutorial을 참조하세요.
Interface Builder 플러그인에는 Interface Builder의 라이브러리 창에 통합하고자 하는 사용자 지정 개체가 포함되어 있습니다.
Preference Pane 플러그인은 시스템 기본 설정 애플리케이션에 통합할 사용자 지정 기본 설정을 정의합니다. 기본 설정 창 프로그래밍 가이드를 참조하세요.
Quartz Composer 플러그인은 Quartz Composer 애플리케이션의 사용자 지정 패치를 정의합니다. Quartz Composer 커스텀 패치 프로그래밍 가이드를 참조하세요.
Quick Look 플러그인은 Quick Look을 사용하여 커스텀 문서 유형의 표시를 지원합니다. Quick Look 프로그래밍 가이드를 참조하세요.
Spotlight 플러그인은 사용자가 해당 문서를 검색할 수 있도록 커스텀 문서 유형의 색인을 지원합니다. 자세한 내용은 Spotlight Importer 프로그래밍 가이드를 참조하세요.
WebKit 플러그인은 일반적인 웹 브라우저에서 지원되는 콘텐츠 유형을 확장합니다.
위젯은 새로운 HTML 기반 응용프로그램을 대시보드에 추가합니다.
문서 포맷은 번들 구조를 활용하여 내용을 구성할 수 있지만, 문서는 일반적으로 가장 순수한 의미에서 번들로 간주되지 않습니다. 디렉토리로 구현되고 불투명 유형으로 처리되는 문서는 내부 형식에 관계없이 문서 패키지로 간주됩니다. 문서 패키지에 대한 자세한 내용은 문서 패키지를 참조하세요.
번들 만들기
대부분의 경우 번들이나 패키지를 수동으로 생성하지 않습니다. 새 Xcode 프로젝트를 작성하거나 기존 프로젝트에 대상을 추가할 때 Xcode는 필요할 때 필요한 번들 구조를 자동으로 작성합니다. 예를 들어 애플리케이션, 프레임워크 및 로드 가능한 번들 대상은 모두 관련된 번들 구조를 가집니다. 이러한 대상을 작성할 때 Xcode는 자동으로 해당 번들을 생성합니다.
알림
쉘 도구 및 정적 라이브러리와 같은 일부 Xcode 타겟에서는 번들이나 패키지가 생성되지 않습니다. 이는 정상이며 이러한 타겟 유형에 대한 번들을 생성할 필요가 없습니다. 해당 타겟에 대해 생성된 바이너리 파일은 그대로 사용됩니다.
Xcode 대신 파일 만들기를 사용하여 프로젝트를 작성할 경우 번들을 만들 수 있는 마술은 없습니다. 번들은 파일 시스템의 디렉토리일 뿐이며, 잘 정의된 구조와 특정 파일 이름 확장명이 번들 디렉토리 이름 끝에 추가됩니다. 최상위 번들 디렉토리를 제대로 생성하고 번들 내용만 적절하게 구성했다면 번들에 액세스하기 위한 프로그램 지원을 사용하여 해당 내용에 액세스할 수 있습니다. 번들 디렉토리 구조 방법에 대한 자세한 내용은 번들 구조를 참조하십시오.
Programmatic Support for Accessing Bundles
번들을 참조하거나 직접 번들로 제공되는 프로그램은 코코아 및 코어 파운데이션의 인터페이스를 활용하여 번들 컨텐츠에 액세스할 수 있습니다. 이러한 인터페이스를 사용하여 번들 리소스를 찾고, 번들 구성에 대한 정보를 가져오고, 실행 파일을 로드할 수 있습니다. Objective-C 애플리케이션에서는 NSBundle 클래스를 사용하여 번들 정보를 가져오고 관리합니다. C 기반 애플리케이션의 경우 CFBundleRef 불투명 유형과 관련된 기능을 사용하여 번들을 관리할 수 있습니다.
알림
다른 많은 Core Foundation 및 코코아 타입과 달리 NSBundle 및 CFBundleRef는 toll-free bridged 데이터 유형이 아니며 서로 바꿔 사용할 수 없습니다. 그러나 두 개체에서 번들 경로 정보를 추출한 후 이를 사용하여 다른 개체를 생성할 수 있습니다.
Cocoa 및 Core Foundation에서 프로그래밍적으로 번들에 액세스하는 방법에 대한 자세한 내용은 번들 컨텐츠 액세스를 참조하세요.
번들 사용 가이드라인
번들은 macOS와 iOS에서 소프트웨어의 기본 구성 메커니즘입니다. 번들 구조를 사용하여 실행 코드와 해당 코드를 지원하는 리소스를 한 장소에서 조직된 방식으로 그룹화할 수 있습니다. 다음 지침에서는 번들을 사용하는 방법에 대한 몇 가지 추가 조언을 제공합니다:
항상 Info.plist 파일을 번들에 포함하세요. 번들 유형에 권장되는 키를 포함해야 합니다. 이 파일에 포함할 수 있는 모든 키 목록은 런타임 구성 지침을 참조하세요.
애플리케이션을 실행하는데 반드시 필요한 리소스 파일이 있다면 애플리케이션 번들에 해당 파일을 포함하세요. 애플리케이션은 실행에 필요한 이미지, 문자열 파일, 지역화 리소스와 플러그인을 항상 포함해야 합니다. 중요하지 않은 리소스도 가급적이면 애플리케이션 번들에 포함되는 것이 좋지만 필요한 경우 번들 외부에 저장할 수도 있습니다. 애플리케이션 번들 구조에 대한 자세한 내용은 응용 프로그램 번들을 참조하세요.
번들에서 C++ 코드를 로드하려는 경우 로드할 기호를 Extern "C"로 표시하는 것이 좋습니다. NSBundle 또는 Core Foundation의 CFBundleRef 함수는 C++ Name mangling 컨벤션에 대해 알지 못하므로 기호를 이러한 방식으로 표시하면 나중에 식별하기가 훨씬 쉬워집니다.
NSBundle 클래스로 CFM(코드 조각 관리자) 코드를 로드하는 것은 불가능합니다. CFM 기반 코드를 로드해야 하는 경우 CFBundleRef 또는 CFPlugInRef Opaque(불투명) 타입의 함수를 사용해야 합니다. 이 기술을 사용하여 Mach-O 실행 파일에서 CFM 기반 플러그인을 로드할 수 있습니다.
Java 코드가 포함된 번들을 로드하려면 (CFBundleRef Opaque 타입과 연관된 함수와는 반대로) 항상 NSBundle 클래스를 사용해야 합니다.
Objective-C 코드가 포함된 번들을 로드할 때 NSBundle 클래스나 (macOS v10.5 이상에서) CFBundleRef opaque 타입 관련 함수를 사용할 수 있지만 각 방법은 동작에 차이가 있습니다. (프레임워크 또는 동적 공유 라이브러리와 달리) 코어 파운데이션 함수를 사용하여 플러그인이나 기타 로드 가능한 번들을 로드하는 경우 함수는 번들을 private하게 로드하고 즉시 기호를 바인딩하며, NSBundle을 사용하는 경우 번들은 전역적으로 로딩되고 해당 심볼은 느리게 바인딩됩니다. 또한 NSBundle 클래스를 사용하여 번들을 로딩하면 NSBundleDidLoadNotification
노티피케이션이 발송되지만 Core Foundation 함수를 사용하여 로드된 번들에서는 발송되지 않습니다.
Last updated