병합 가능한 라이브러리 알아보기

♪ ♪

안녕하세요, Cyndy예요 언어 및 런타임 팀의 컴파일러 엔지니어죠 이 세션에서는 병합 가능 라이브러리를 다뤄요 정적 링커에 의해 동작하여 라이브러리를 구축하고 배포하는 새로운 모델이죠 병합 가능 라이브러리로 앱 빌드와 실행이 빨라지는 방법을 공유하고

병합 가능 라이브러리를 Xcode 15에서 활성화하는 법을 시현할게요 마지막으로 병합 가능 라이브러리 사용 시 고려 및 권장 사항에 관해 다루도록 하죠 시작하기 전에 정적, 동적 라이브러리를 간략하게 설명할게요 이를 통해 병합 가능 라이브러리의 장점을 살펴볼 수 있죠 정적 라이브러리는 오브젝트 파일 컬렉션이에요 빌드 때 정적 링커가 라이브러리에서 어떤 API를 사용할지 찾아서 코드를 앱 바이너리에 복사하죠

복사했기 때문에 빌드 후에는 라이브러리가 필요 없어요 정적 라이브러리 코드가 바뀌거나 더 많은 라이브러리가 사용되면 빌드 시간이 느려지죠 앱에 아카이브되거나 링크된 방식 때문인데 반복적 빌드와 디버깅을 느리게 하죠 동적 라이브러리를 사용하면 이를 방지할 수 있어요 동적 라이브러리는 통상 dylib이라고 부르죠 Xcode 프레임워크 타겟을 위한 바이너리 파일 타입이에요

프레임워크의 코드를 실행 파일에 복사하지 않죠 대신 정적 링커가 라이브러리의 설치 경로를 나중을 위해 앱 바이너리에 기록해요 Apple SDK에 없는 모든 프레임워크는 앱 번들에 임베딩해야 하죠 큰 차이점은 동적 라이브러리가 추가되거나 업데이트될 때 정적 링커가 코드를 복사하지 않아도 된다는 거예요 이를 통해 빌드가 빨라져요 하지만 앱이 런타임 때 사용되면 복잡도가 증가하죠 이때 동적 링커가 필요해요 앱을 실행했을 때 dyld라는 동적 링커가 프레임워크 의존성을 찾아서 로딩해야 하죠 해당 프레임워크가 의존하는 라이브러리도 포함해요

더 많이 사용될수록 메모리 사용량과 앱 실행 시간이 점차 증가하게 되죠 Apple SDK의 의존성까지 고려할 경우 앱이 수백 개의 프레임워크를 로딩할 수도 있어요 우리 플랫폼은 이를 수용하기 위해 시스템 라이브러리를 최적화했죠 하지만 앱에 임베딩되는 프레임워크에는 적용되지 않아요 다시 정리해 보면 정적, 동적 라이브러리를 선택하는 것에 있어 각각의 단점이 있죠

동적 라이브러리는 빌드 시간에 영향을 적게 주지만 실행 시간이 길어질 수 있고 정적 라이브러리는 실행 시간에 영향을 적게 주지만 빌드 시간이 길어질 수 있어요 이런 문제 때문에 예전에는 앱에 제일 좋은 방법을 계산하도록 권장했죠 병합 가능 라이브러리에서는 그럴 필요가 없어요 병합 가능 라이브러리는 두 링크 전략의 장점을 취하죠 병합 가능 라이브러리로 성능과 개발을 최적화하는 방법을 알려드릴게요 실행 파일과 같은 바이너리 이미지가 있다고 하죠 바이너리가 의존하는 프레임워크는 정적 링커로 보내져요 이러한 의존성은 병합 가능 라이브러리가 될 수 있고 링크된 결괏값은 병합된 바이너리가 될 수 있죠 이러한 의존성은 어떻게 해야 병합 가능해질까요? 빌드된 방식으로 설명할 수 있어요 모든 동적 라이브러리는 병합 가능하게 빌드 될 수 있죠 정적 링커가 라이브러리를 생성할 때 메타데이터도 생성해요 메타데이터가 바이너리 안에 있어 전체 크기가 증가하죠 이를 통해 링커가 라이브러리가 링크 의존성으로 사용될 때 정적 라이브러리와 비슷하게 다뤄요 메타데이터가 있어 라이브러리의 사용자는 보통의 동적 라이브러리처럼 정적으로 링크하거나 병합할 수 있죠 병합된 바이너리 결괏값은 앱과 같은 실행 파일이나 프레임워크 같은 다른 동적 라이브러리가 될 수 있어요 병합은 정적 라이브러리가 링크되는 것과 비교할 수 있죠 최종적으로 남는 바이너리는 라이브러리의 세그먼트를 포함해요 결과 바이너리는 같은 파일 타입으로 남죠 병합은 Xcode 15의 새로운 기능이에요 새롭게 적용된 정적 링커로 가능해진 기능이죠 새로운 링커 옵션을 사용하면 돼요 일단, 병합할 라이브러리는 -make_mergeable로 빌드되죠 이를 통해 링커에 메타데이터를 기록하게 해요 다음으로 병합된 바이너리의 경우 링커에서 메타데이터와 라이브러리를 사용하여 최종 결괏값을 도출하며 -merge_library 또는 -merge_ framework 옵션을 사용해요 이런 세부 사항은 Xcode가 알아서 하죠 하지만 빌드 로그를 검토할 때 옵션이 적용되는 걸 볼 수 있어요 그렇다면 병합이 링크보다 나은 게 뭘까요? 병합 후의 크기를 고려해 보죠 먼저, 라이브러리와 메타데이터가 필요 없으므로 병합 후에는 삭제할 수 있어요 병합된 바이너리의 크기만 신경 쓰면 되는 거죠 병합할 때 링커가 모든 라이브러리에 걸친 스트링과 같은 콘텐츠의 복제를 취소할 수 있어요 예를 들어 중복되는 심벌 참조나 Objective-C 선택자 objc_msgsend 스텁을 삭제하죠 이를 통해 전체 앱 번들이 작아져요 최종 바이너리의 이미지 타입은 그대로죠 이미 지원되는 링커 최적화를 적용할 수 있다는 의미예요 이는 앱 실행에도 긍정적인 영향을 주죠 프레임워크가 적게 로딩되면 dyld와 커널이 앱을 실행할 때 해야 하는 작업을 줄여 주고 메모리 사용량을 줄여 사용자를 만족하게 해 줘요 하지만 코드를 라이브러리로 분리하는 게 효과적인 개발과 유지에 필수라는 걸 알고 있죠 병합 가능한 라이브러리로 둘 다 챙길 수 있어요 병합 가능한 라이브러리는 최소한의 코드와 설정 변경을 통해 이를 가능하게 해 주죠 새로운 프레임워크를 채택할 때도 잘 적용돼요 앞에 나온 동적 링킹 도표를 다시 보죠 임베딩된 프레임워크는 모두 병합 가능해지는데 링커가 메타데이터를 생성할 수 있기 때문이에요 다른 라이브러리 내용을 병합하는 프레임워크를 만들 수 있죠 그러면 임베딩할 프레임워크가 하나만 남아요 Dyld가 로딩해야 하는 라이브러리는 임베딩된 프레임워크들의 모든 세그먼트를 포함하고 있죠 이렇게 병합하면 대규모 의존성 체인을 단순화할 수 있어요 병합 가능 라이브러리의 능력을 살펴봤는데요 그럼 어떻게 활성화하는지 얘기해 볼게요 Xcode에서 라이브러리 병합을 활성화하는 방법이 2개 있는데 제일 간단한 자동 병합부터 시작하도록 하죠 이후에 다룰 수동 병합은 어떤 걸 병합할지 여러분이 제어하는 방법이에요 병합 가능 라이브러리가 디버깅 모드에서 최적화된 빌드 시간을 제공하는 원리를 설명해드리죠 이후에는 병합 가능 라이브러리를 디버깅하거나 심벌릭화할 때 발생하는 일을 공유할게요 자동 병합은 빌드 체계에 임베딩된 프레임워크 타겟인 직접 의존성을 모두 병합하게 하죠 앱 타겟에 특히 유용해요 보여 드리죠 Swift와 C++ Forest Project를 예로 사용할게요 4개의 프레임워크와 연결된 앱 타겟이 있군요 Apple SDK와 함께 제공되는 SwiftUI와 다른 3개인 ForestBuilder ForestUI와 Forest는 프로젝트에 빌드돼 있어요 자동 병합을 활성화하면 3개의 Forest 프레임워크가 병합 가능해지죠 SwiftUI는 시스템 라이브러리여서 그대로 남아 있어요 앱을 링크할 때 이러한 프레임워크가 앱 바이너리에 직접 병합되죠 그건 이 프레임워크들이 실행 때 필요하지 않으며 디스크에서 제거될 수 있다는 의미예요 이 기능을 Xcode에서 켜는 방법을 알아보죠

프로젝트에서 이미 Swift와 C++ 앱 타겟을 클릭했고 빌드 설정 탭에 와 있어요 이제 MERGED_BINARY_TYPE 빌드 설정을 업데이트해야 하죠 필터링 텍스트 상자를 이용하여 검색할 수 있어요

'Create Merged Binary'는 제가 업데이트하려는 항목이죠 MERGED_BINARY_TYPE 설정에 매핑된 옵션이에요 설정을 클릭하고 값을 Automatic으로 바꿀게요 그럼 끝이에요

병합 가능 라이브러리 설정은 General Linking 설정에 있죠 'Linking - Mergeable Libraries'라는 전용 섹션에 편리하게 나타나 있어요 앱의 라이브러리 병합을 활성화하면 라이브러리의 세그먼트가 앱 바이너리에 직접 링크되죠 이는 정적 라이브러리와 비슷한 성능으로 이어지지만 병합 가능 라이브러리의 엑스포트는 앱에 보존돼 있어요 심벌을 엑스포트하는 앱에는 적용할 수 없으며 크기와 빌드 시간에 부정적인 영향을 주죠 -no_exported_symbols을 사용하여 이런 일을 방지할 수 있어요 Xcode에 적용하는 방법은 Other Linker Flags를 '-Wl, -no_exported_symbols'로 업데이트하는 거죠 만약 앱 확장 프로그램을 위한 진입점이 필요한 경우 이러한 심벌을 열거하는 엑스포트 목록으로 중점 관리하세요 역시 General Linking 설정에서 Exported Symbols File을 사용하여 설정할 수 있어요 이를 통해 정적 링커가 크기 최적화와 불필요한 코드 제거에 가장 효과적인 수단이 되죠 지금까지 자동 병합을 살펴봤는데 일부 프레임워크만 병합해야 하는 경우가 있을 수도 있어요 Xcode는 Manual Merging으로 이를 지원하죠 수동 병합은 병합할 라이브러리를 세세하게 지정하는 방식이에요 일부 의존성이 앱 번들에 남아 있어야 할 때 유용하죠 이는 주의 사항을 다룰 때 자세히 설명할게요 MERGED_BINARY_TYPE = manual을 모든 걸 포함하는 타겟에 설정하여 활성화할 수 있죠 최종 병합 결과물을 구성하는 라이브러리들은 MERGEABLE_LIBRARY를 YES로 설정하면 돼요 디스크에 남겨야 하는 라이브러리는 MERGEABLE_LIBRARY의 기본값을 NO로 유지하세요 Swift와 C++ Forest Project로 시현해 보도록 하죠 자동 병합과 관련된 변경 없이 새롭게 시작하고 있어요 아직도 4개의 프레임워크가 연결된 앱 타겟이 있죠 이번에는 테스트도 고려해야 해요 프로젝트에 XCTest 타겟과 지원 프레임워크가 있죠 테스트는 Forest 프레임워크에도 의존해요 프로젝트의 프레임워크 사이에 의존성이 전부 엮여 있죠 이 예시에서는 XCTest 타겟이 있지만 여러분의 프로젝트에도 비슷한 의존성 그래프를 만드는 앱 확장 프로그램 등의 타겟이 있을 수 있어요

병합 가능 라이브러리를 활용하기 위해 3개의 Forest 프레임워크에 대한 앱 의존성을 독립시킬게요

ForestKit이라는 프레임워크를 생성하여 필요한 라이브러리를 병합하고 테스트 의존성도 만족시킬게요

ForestKit은 그룹 라이브러리로 간주하는데 앱과 테스트가 의존하는 병합 가능 라이브러리를 포함하기 때문이죠

수동 모드를 활성화하면서 병합 가능하게 할 프레임워크를 명시적으로 지정할게요 이 경우는 ForestBuilder와 ForestUI, Forest죠

이 의존성들이 ForestKit으로 병합될 거예요 로딩해야 할 라이브러리를 줄여서 앱의 실행 시간과 번들 크기가 개선됐죠 Xcode에서 직접 해 볼게요

프로젝트를 다시 시작하여 자동 병합 관련 설정을 제거했죠 다른 프레임워크를 병합할 프레임워크 타겟을 생성할게요 이건 저의 그룹 라이브러리 ForestKit이죠 Targets 섹션의 아래를 누르면 돼요

템플릿 팝업 창의 macOS 탭으로 가서 필터링 텍스트 상자로 Framework 템플릿을 찾을게요

제품 이름을 ForestKit으로 설정하고 Finish를 클릭해요

이 프레임워크에서는 모든 라이브러리를 병합하는 대신 Forest Test Support 프레임워크는 제외할 거죠 하지만 의존성이 모두 엮여 있어서 일단은 모두 링크할게요 Link Binary with Libraries 빌드 단계를 업데이트하여 더하기 기호로 프레임워크를 추가하세요

라이브러리 팝업 창이 나타나면 Forest 프레임워크를 클릭하고 시프트와 아래 방향키를 눌러 다른 프레임워크를 선택할게요

다음은 이 타겟에 수동 병합을 활성화해야 하죠 이를 위해 Build Settings 탭으로 가서 다시 'Create Merged Binary' 항목을 찾고 있어요 필터링 텍스트 상자에 MERGE를 입력할게요

이번에는 'Manual' 값을 선택하죠 그룹 라이브러리 타겟의 모든 설정이 끝났어요 이제 빌드 설정으로 가서 어떤 라이브러리를 병합할지 프레임워크 타겟 별로 선택할 수 있죠 Targets 섹션에서 Forest 프레임워크부터 시작할게요 Build Settings 탭에서 Build Mergeable Library를 클릭하세요 이 옵션은 MERGEABLE_LIBRARY 빌드 설정에 매핑돼 있는데 이 값을 Yes로 바꾸도록 하죠

ForestUI와 Forest Builder도 같은 작업을 해요

병합된 ForestKit 프레임워크의 생성이 완료됐지만 의존 프로그램들을 업데이트해야 하죠 동적 라이브러리 대부분을 포함하는 프로젝트를 생성해서 앱과 테스트를 다른 것들이 아닌 ForestKit과 링크해야 해요 Swift와 C++ App Target을 클릭해 앱부터 수정할게요

다시 Build Phases 탭의 'Link Binary with Libraries'에서 불필요한 프레임워크를 제거하도록 하죠 Forest를 선택하고 시프트와 위 방향키를 눌러 ForestUI와 ForestBuilder를 선택하여 삭제하세요 마지막 단계는 테스트죠 XCTest 타겟을 클릭하고 Build Phases 탭의 'Link Binary with Libraries' 섹션으로 가세요

테이블에서 이름을 눌러 Forest 프레임워크를 삭제하도록 하죠

그리고 더하기 기호로 ForestKit을 추가할 거예요

팝업 창이 나타나면 ForestKit을 더블 클릭할게요

지금까지 수동 병합을 설정하는 방법을 보여드렸죠 Swift와 C++ Forest Project는 배포 모드로 작업 중이었어요 라이브러리를 통합하고 디스크에서 삭제하는 거죠 하지만 병합에 대한 빌드 시간 오버헤드가 있어 개발 비용이 올라갈 수 있는데 정적 라이브러리의 빌드 시간 문제와 비슷해요

Xcode의 반복 개발 지원을 위해 디버깅 모드에서 병합하지 않죠 빌드 체계가 링커에 라이브러리를 재엑스포트를 지시해요 재엑스포트는 링커 옵션이며 적용한 코드가 동적 라이브러리에 남아 있게 하고 다른 곳에 적용되면 그곳에도 나타나게 하죠 다시 말해 앱 확장 프로그램이나 테스트 같은 병합된 타겟에 의존하기만 하면 모든 라이브러리의 API에 접근할 수 있는 거죠 이는 동적 라이브러리의 빌드 시간 이점과 비슷한 결과로 이어지죠 실행 때 dyld가 재엑스포트 된 라이브러리 참조를 리다이렉트하고 병합된 바이너리에서 직접 오는 걸 기대하지 않아요 디버그 때 병합된 라이브러리가 디스크에 남는다는 의미죠

디버깅 얘기가 나왔으니 병합 라이브러리에 포함될 수 있는 심벌을 살펴볼게요 정수 값을 받아들여 제곱 값을 반환하는 함수가 있죠 이건 빌드될 코드예요 하지만 머신은 이 코드를 실행하지 않죠 대신 이 코드는 여러 변환을 거쳐요 코드의 버그를 찾아야 할 때까지는 괜찮죠 그래서 Xcode가 심벌릭화를 지원하는 거예요 심벌릭화는 머신의 지시를 원래 소스 코드와 다시 연관 짓는 프로세스죠 크래시 로그를 이해하거나 코드의 프로파일링과 디버깅에 유용해요 병합된 바이너리에서는 어떻게 작용할까요?

병합을 활성화하면 소스 위치 정보가 기존 라이브러리에 보존되어 있어요 그 의미는 디버깅 경험이 똑같이 유지된다는 거죠 하지만 스택 트레이스와 같은 라이브러리 정보가 표시됐을 때 병합된 바이너리로의 경로를 나타낼 거예요 이 정보는 Instruments의 크래시 로그와 디버거에 나타나게 되죠 이제 여러분의 프로젝트가 병합 가능 라이브러리를 채택하는 방법을 알아볼게요 대개는 Xcode 설정 몇 번이면 활성화할 수 있지만 몇 가지 요소를 알아두어야 하죠 고려하면 좋은 5개의 주제를 다룰게요 병합 가능한 라이브러리에 있는 기존의 의존성들을 처리하는 방법부터 시작한 뒤 자동 링킹을 정의하고 병합 가능 라이브러리와의 연관성을 알아보고 dlopen이나 번들 인터페이스 같은 런타임 룩업 API를 사용할 때 제약 사항에 관해 다룰게요 병합은 Xcode 15의 정적 링커를 이용하므로 이전 버전과의 주요 차이점을 언급하도록 하죠 마지막 고려 사항은 다른 개발자들에게 프레임워크를 배포하는 것에 관심 있는 분들을 위한 거예요

라이브러리 의존성과 관련하여 dyld 작업 도표를 다시 보죠 병합 가능한 라이브러리에 의존하는 게 있는데 다른 실행 파일처럼 병합돼 있지 않은 경우 병합된 프레임워크에 의존하도록 업데이트해야 해요 병합 가능한 것들은 디스크에서 제거되기 때문이죠 앱이 자동 링킹에 의존할 때도 이런 문제가 발생해요 자동 링킹은 기본적으로 활성화돼 있는 컴파일러 옵션이죠 컴파일러가 소스 코드에서 모듈 임포트를 발견하면 프레임워크 의존성을 감지하여 링커에게 전달해요 만약 병합 가능 라이브러리에서 모듈을 임포트 한다면 동적 링킹 문제를 유발할 수 있죠 하지만 자동 링킹을 비활성화할 필요는 없어요 이전처럼 병합된 프레임워크에 링크해서 해결할 수 있죠

통상적인 방법은 'Link Binary with Libraries' 빌드 단계에 병합된 프레임워크를 추가하고 남아 있는 병합 가능 프레임워크를 제거하는 거예요 아니면 dyld가 앱에 필요한 프레임워크를 로딩하지 못하죠

개발자 대부분은 dlopen과 같은 동적 링킹 API가 필요 없어요 만약 필요하다면 입력 경로가 병합된 프레임워크 타겟을 가리켜야 하죠

비슷한 사례로 라이브러리 병합에 리소스 룩업이 영향받을 수 있는데 런타임에서 기대하는 것 때문이에요 Swift에서 bundle은 런타임이 프레임워크 번들을 로딩하는 API죠 Objective-C에 해당하는 API는 NSBundle의 bundleForClass예요 이러한 API를 사용하여 번들의 구조를 고려하지 않고 프레임워크의 리소스와 작업할 수 있죠

iOS 12까지는 프레임워크의 바이너리가 있어야 런타임이 번들을 발견할 수 있었지만 프로세스가 실행될 때에는 병합 가능 프레임워크 안에 바이너리가 없을 거예요 좋은 소식이에요 이런 경우에 룩업을 활성화하도록 iOS 12에 훅을 추가했죠 만약 번들 룩업 지원에 의존한다면 최소 배포 버전을 iOS 12 이후로 업데이트해야 병합 가능 라이브러리를 이용할 수 있다는 의미예요 근데 이런 API에 의존하지 않으면 -no_merged_libraries_hook의 새로운 링커 옵션으로 지원을 비활성화할 수 있죠 그러면 앱의 배포 버전을 업데이트하지 않아도 돼요 번들 리소스를 포함하지 않는 프레임워크를 병합한다면 번들 훅도 필요하지 않죠 만약 이런 경우라면 이 옵션을 추가하여 실행 시간을 개선할 수 있어요 이번 세션을 통해 새로운 링커 옵션을 언급했죠 이런 옵션은 새로 적용된 링커와 작동해요 하지만 툴체인을 들여다보면 2개의 정적 링크가 눈에 띌 텐데요 하위 호환성을 위해 오래된 링커를 지원하고 있죠 더욱 눈에 띄는 건 링커가 armv7k를 위해 빌드할 수 있지만 새로운 링커는 그럴 수 없어요 마지막으로 armv7k 구조를 지원했던 건 watchOS 8이죠 만약 watchOS 8 이전 버전으로 배포하지 않아도 된다면 watchOS 9로 배포 버전을 올려 새 링커를 사용하세요 병합 가능 라이브러리를 빌드하고 사용하는 법을 다뤘는데 병합 가능 라이브러리를 배포하여 다른 사람이 쓰게 하고 싶다면 Swift Package Manager나 Xcode에서 XCFramework를 생성하면 돼요 메타데이터를 포함한 프레임워크를 배포용으로 빌드할 수 있죠 다른 개발자가 프레임워크 사용 때 병합 여부를 결정할 수 있어요 병합 가능 메타데이터는 dylib 크기의 2배 정도 되죠 앱 크기에는 영향이 없는데 앱을 빌드한 뒤에 메타데이터를 병합 가능 라이브러리와 삭제하기 때문이에요 그러지 않으면 메타데이터를 제거하여 앱에 임베딩할 때 커지는 걸 방지하죠 병합 가능 라이브러리의 미묘한 차이를 설명했어요 이제 권장 사항을 공유해 드리죠 병합 바이너리의 의존성 설정은 매끄러운 채택의 핵심이에요 어떤 링크 의존성이든 필요한 작업이죠 스크립트 단계에서 바이너리를 기대하는 툴에 라이브러리를 제공하는 경우 특히 중요해요 정적 링커는 직접적인 의존성만 병합하죠 따라서 병합 가능 라이브러리를 더 포함하려면 명시적인 링크 의존성으로 설정해야 해요 병합 설정이 Xcode 빌드 체계에 지시하여 프레임워크의 바이너리를 디스크에서 삭제하도록 하죠 만약 의도한 게 아니라면 부작용을 유발하므로 Xcode 타겟 수준에서 활성화하는 걸 권장해요 마지막으로 생산성을 극대화하면서 성능을 최적화하기 위해 병합 가능한 정적 라이브러리를 동적 라이브러리로 업데이트하는 걸 고려하세요 병합 가능 라이브러리는 편의성과 유연성을 제공해요 자동 및 수동 작업 흐름 사이에서 구조를 바꾸고 여러분이 원할 때 병합 가능 라이브러리를 추가하고 필요한 것들은 디스크에 남길 수 있죠 이러한 유연성은 점진적인 채택과 프로파일링에 유용해요 병합 가능 라이브러리는 프레임워크와 실행 가능 타겟에 적용했을 때 용량, 빌드, 런타임을 개선하죠 자동 설정을 이용하여 직접적인 프레임워크 의존성을 빌드 체계에서 병합하게 할 수 있어요 하지만 어떤 의존성을 병합할지 선택해야 한다면 수동 모드를 이용할 수 있죠 끝으로 병합 가능 라이브러리를 위해 프로젝트를 업데이트한다면 라이브러리의 모든 의존성이 삭제되는 라이브러리가 아닌 병합된 라이브러리에 의존하도록 하세요 병합 가능 라이브러리에 관한 문서가 필요하면 '병합 가능 라이브러리 사용을 위한 프로젝트 설정'을 검토하세요 정적, 동적 링킹을 더 알아보고 싶다면 '빠르게 링크하기: 빌드와 실행 시간 개선하기' 세션을 보세요 여러분의 프로젝트에 병합 가능 라이브러리가 어떻게 쓰일지 기대되네요 함께해 주셔서 감사해요