Friday, August 9, 2019

디버그에선 멀쩡한데? Xcode 릴리즈 빌드에서 UI가 깨지는 현상, 원인과 해결법 총정리
  /   No comments   

"분명히 내 컴퓨터에서는 잘 됐는데..." iOS 개발자라면 한 번쯤은 이 말을 내뱉으며 깊은 좌절에 빠져본 경험이 있을 것입니다. 특히 UI 관련 작업에서 이런 현상은 빈번하게 발생합니다. 수십 번을 테스트하며 완벽하게 맞춰놓은 레이아웃, 아름답게 동작하던 애니메이션이 Xcode에서 'Run' 버튼을 눌러 시뮬레이터나 테스트 기기에서 실행할 때(디버그 빌드)는 완벽한데, 앱 스토어에 올리기 위해 아카이빙을 하거나(릴리즈 빌드) TestFlight로 배포했을 때 완전히 다른 모습으로 나타나는 현상 말입니다. 버튼이 사라지거나, 뷰의 위치가 엉뚱한 곳으로 가거나, 심지어는 앱이 크래시 나기도 합니다.

동일한 코드베이스를 가지고 빌드하는데 왜 이런 차이가 발생하는 것일까요? 유령이라도 곡할 노릇입니다. 많은 개발자들이 이 문제 앞에서 'Xcode 버그인가?' 혹은 'Swift 컴파일러가 이상한가?'와 같은 의심을 품지만, 대부분의 경우 이는 버그가 아닌 Xcode 빌드 시스템의 '의도된 동작' 때문에 발생합니다. 바로 디버그(Debug) 설정과 릴리즈(Release) 설정의 근본적인 차이, 특히 '최적화(Optimization)' 옵션의 차이에서 비롯되는 문제입니다.

이 글에서는 단순히 '이 설정을 바꾸면 해결됩니다'라는 단편적인 해답을 넘어, 왜 이런 문제가 발생하는지에 대한 근본적인 원인을 깊이 파고들어 체계적으로 이해하고, 어떤 상황에서 어떤 해결책을 적용해야 하는지에 대한 종합적인 접근법을 제시하고자 합니다. 이 글을 끝까지 읽고 나면, 앞으로 마주할 릴리즈 빌드 관련 UI 이슈에 대해 자신감을 갖고 대처할 수 있게 될 것입니다.

1. 모든 문제의 시작: 디버그(Debug) vs 릴리즈(Release) 빌드 설정의 본질적 차이

문제를 해결하기 위해 가장 먼저 해야 할 일은 '디버그'와 '릴리즈'가 단순히 이름만 다른 설정이 아님을 이해하는 것입니다. 이 둘은 Xcode가 코드를 컴파일하고 앱을 패키징하는 과정에서 완전히 다른 목표를 가집니다.

1.1. 디버그 빌드(Debug Build): 개발자의 편의가 최우선

디버그 빌드의 최우선 목표는 '빠른 개발 사이클'과 '효율적인 디버깅'입니다.

  • 빠른 컴파일 속도: 개발자는 코드를 수정한 후 결과를 즉시 확인하고 싶어 합니다. 이를 위해 디버그 빌드는 컴파일 속도를 저해하는 대부분의 최적화 과정을 생략합니다. 변경된 파일만 다시 컴파일하는 '증분 컴파일(Incremental Compilation)' 방식을 사용하여 빌드 시간을 최소화합니다.
  • 풍부한 디버깅 정보: 변수의 값을 추적하고, 코드의 특정 지점에서 실행을 멈추고(Breakpoint), 메모리 상태를 분석하는 등의 디버깅 작업을 원활하게 하기 위해, 디버그 빌드는 실행 파일 내에 방대한 양의 디버깅 심볼(dSYM)과 메타데이터를 포함합니다.
  • 런타임 검사: 배열의 인덱스가 범위를 벗어나는지, 강제 언래핑이 실패하는지 등 잠재적인 런타임 오류를 더 엄격하게 검사하여 개발 과정에서 빠르게 오류를 발견하도록 돕습니다.

결론적으로 디버그 빌드는 개발자의 편의를 위해 성능을 희생하는 설정입니다.

1.2. 릴리즈 빌드(Release Build): 사용자의 경험이 최우선

반면, 릴리즈 빌드의 목표는 명확합니다. '최고의 사용자 경험'을 제공하는 것입니다. 이는 곧 '가장 빠른 실행 속도'와 '가장 작은 앱 용량'을 의미합니다.

  • 공격적인 최적화: 릴리즈 빌드는 앱의 성능을 한계까지 끌어올리기 위해 컴파일러가 제공하는 모든 최적화 기술을 사용합니다. 코드를 재배열하고, 불필요한 함수 호출을 인라인(inlining) 처리하며, 사용되지 않는다고 '판단되는' 코드를 제거합니다.
  • 최소한의 바이너리 크기: 앱 스토어에서 다운로드하는 사용자를 위해 앱의 용량을 줄이는 것이 중요합니다. 릴리즈 빌드는 디버깅에 필요한 심볼 정보를 모두 제거(Strip)하고, 코드를 압축하여 바이너리 크기를 최소화합니다.
  • 디버깅 정보 제거: 'Dead Code Stripping'과 같은 기술을 사용하여 앱 실행에 직접적으로 필요하지 않은 코드를 과감하게 제거합니다.

바로 이 '공격적인 최적화' 과정이 디버그 빌드에서는 발생하지 않았던 예기치 않은 동작, 특히 UI가 깨지는 문제의 주된 원인이 됩니다. 컴파일러는 코드의 '의미'를 이해하는 것이 아니라, 정해진 '규칙'에 따라 코드를 기계어로 변환하고 최적화합니다. 이 과정에서 개발자의 '의도'와 컴파일러의 '판단' 사이에 불일치가 발생할 수 있습니다.

2. 주범을 찾아라: UI를 망가뜨리는 빌드 설정 삼총사

그렇다면 릴리즈 빌드의 어떤 설정들이 구체적으로 UI 문제의 원인이 될까요? 가장 의심해야 할 세 가지 핵심 설정은 다음과 같습니다. 이들은 Xcode 프로젝트의 'Build Settings' 탭에서 확인할 수 있습니다.

2.1. Swift 컴파일러 - 코드 생성 (Swift Compiler - Code Generation)

이 섹션의 설정들은 Swift 코드가 어떻게 컴파일될지를 결정하며, 가장 극적인 차이를 만들어내는 부분입니다.

컴파일 모드 (Compilation Mode)

이 설정은 디버그와 릴리즈 빌드 간의 가장 큰 차이점 중 하나이며, UI 문제의 가장 흔한 원인입니다.

  • 디버그 기본값: 증분 (Incremental)
    이 모드에서는 Swift 컴파일러가 마지막 빌드 이후 변경된 소스 파일만 다시 컴파일합니다. 이는 개발 중 빌드 시간을 극적으로 단축시켜주지만, 파일 간의 상호작용을 분석하여 최적화할 기회는 없습니다.
  • 릴리즈 기본값: 전체 모듈 (Whole Module)
    이 모드에서는 컴파일러가 프로젝트의 모든 Swift 파일을 하나의 큰 단위(모듈)로 간주하고 한 번에 컴파일합니다. 이로 인해 컴파일 시간은 훨씬 길어지지만, 컴파일러는 모듈 전체의 코드 흐름을 파악할 수 있게 됩니다. 이를 통해 파일 경계를 넘나드는 강력한 최적화가 가능해집니다. 예를 들어, A 파일에 있는 작은 함수를 B 파일에서 호출할 때, 함수 호출 오버헤드를 없애기 위해 A 파일의 함수 코드를 B 파일에 그대로 복사해 넣는 '크로스-파일 인라이닝(Cross-file Inlining)'과 같은 고수준 최적화를 수행합니다.

문제 발생 시나리오: '전체 모듈' 최적화는 매우 강력하지만, 때로는 개발자의 의도를 벗어나는 결과를 낳습니다. 예를 들어, 특정 순서대로 실행되어야 하는 UI 업데이트 코드들이 컴파일러의 판단에 따라 순서가 바뀌거나, 특정 조건에서만 호출될 것으로 보이는 레이아웃 관련 코드가 '불필요하다'고 판단되어 제거될 수 있습니다. 특히 복잡한 계산을 통해 뷰의 프레임(frame)을 설정하거나, 여러 단계에 걸쳐 UI를 구성하는 코드에서 이러한 문제가 발생하기 쉽습니다.

iOS Build Settings showing Compilation Mode for Debug and Release
그림1. 디버그(Incremental)와 릴리즈(Whole Module)로 다르게 설정된 컴파일 모드(Compilation Mode)

최적화 수준 (Optimization Level)

이 설정은 컴파일러가 얼마나 공격적으로 코드를 최적화할지 직접적으로 제어합니다.

  • 디버그 기본값: 최적화 없음 [-Onone]
    말 그대로 최적화를 수행하지 않습니다. 코드는 작성된 순서 그대로 기계어로 변환되며, 디버깅 시 코드와 실행 흐름이 정확히 일치합니다.
  • 릴리즈 기본값: 속도 최적화 [-O]
    실행 속도를 최우선으로 고려하여 최적화합니다. 불필요한 변수 할당을 제거하고, 루프를 재구성하며, 계산 순서를 변경하는 등 성능 향상을 위한 모든 수단을 동원합니다.
  • 대안: 크기 최적화 [-Osize]
    실행 속도보다는 최종 바이너리의 크기를 줄이는 데 초점을 맞춰 최적화합니다. 속도 최적화와 유사하지만, 코드 크기를 늘릴 수 있는 일부 최적화(예: 과도한 인라이닝)는 피합니다.

문제 발생 시나리오: [-O] 최적화는 코드의 실행 순서를 보장하지 않습니다. 예를 들어, 다음과 같은 코드가 있다고 가정해 봅시다. 


let label = UILabel()
label.text = "매우 긴 텍스트입니다..."
label.frame.size = label.intrinsicContentSize // 텍스트에 맞는 사이즈 계산
someView.addSubview(label)

// ... 잠시 후 ...
label.frame.origin.x = (someView.bounds.width - label.frame.width) / 2

개발자는 label.frame.size가 먼저 계산되고, 그 후에 계산된 width 값을 사용하여 x 좌표를 설정하기를 의도했습니다. 하지만 최적화 컴파일러는 이 코드 블록 전체를 분석한 후, '효율성'을 위해 연산 순서를 바꾸거나 일부 계산을 동시에 처리하려고 시도할 수 있습니다. 만약 origin.x를 계산하는 시점에 frame.width가 아직 이전 값(0)이라면, 레이아웃은 완전히 망가질 것입니다. 이는 실제로는 훨씬 더 복잡하고 미묘한 방식으로 발생하여 원인을 찾기 어렵게 만듭니다.

2.2. 빌드 옵션 (Build Options)

디버깅 정보 형식 (Debug Information Format)

  • 디버그 기본값: DWARF with dSYM File
    디버깅에 필요한 모든 정보를 포함하는 dSYM 파일을 생성하여, 크래시 리포트를 분석하거나 디버거를 붙였을 때 코드의 어느 부분에서 문제가 발생했는지 정확히 알려줍니다.
  • 릴리즈 기본값: DWARF
    dSYM 파일을 별도로 생성하지 않고, 디버깅 정보를 실행 파일 내에 포함시킵니다. 하지만 다른 설정(아래 '배포 후처리')에 의해 이 정보는 최종적으로 제거됩니다.

이 설정 자체가 직접적으로 UI를 깨뜨리는 경우는 드물지만, 릴리즈 빌드에서 문제가 발생했을 때 원인 분석을 어렵게 만드는 요인이 될 수 있습니다.

2.3. 배포 (Deployment)

배포 후처리 (Deployment Postprocessing)

  • 디버그 기본값: No
  • 릴리즈 기본값: Yes
    이 옵션이 Yes로 설정되면, 빌드 과정 마지막에 바이너리를 추가적으로 처리하여 최종 사용자에게 배포하기에 적합한 형태로 만듭니다.

스트립 스타일 (Strip Style) / 연결된 제품 스트립 (Strip Linked Product)

'배포 후처리'가 활성화되면 이 설정들이 동작합니다. 이들은 실행 파일에서 불필요한 심볼(함수나 변수 이름 등)을 제거하여 앱의 크기를 줄이는 역할을 합니다.

문제 발생 시나리오: '데드 코드 스트리핑(Dead Code Stripping)'과 연계될 때 문제가 발생할 수 있습니다. 예를 들어, Objective-C 런타임의 동적인 특징을 활용하여 문자열 기반으로 특정 클래스나 메서드를 호출하는 경우(NSClassFromString 등), 컴파일러는 정적 분석 단계에서 해당 코드가 실제로 사용되는지 파악하지 못할 수 있습니다. 컴파일러가 이를 '사용되지 않는 코드(Dead Code)'로 판단하고 제거해버리면, 릴리즈 빌드에서는 해당 클래스나 메서드를 찾을 수 없어 크래시가 발생하거나 UI가 제대로 생성되지 않습니다.

3. 실전! 문제 해결을 위한 단계별 접근법

원인을 이해했으니 이제 실질적인 해결책을 찾아볼 차례입니다. 문제가 발생했을 때 무작정 모든 설정을 뒤지기보다는, 체계적인 단계를 따라 접근하는 것이 효율적입니다.

1단계: 릴리즈 설정으로 직접 디버깅하기

가장 먼저 해야 할 일은 릴리즈 빌드에서 발생하는 문제를 내 개발 환경에서 재현하는 것입니다. Xcode 상단의 Scheme 편집 메뉴를 통해 이를 설정할 수 있습니다.

  1. Xcode 메뉴에서 Product > Scheme > Edit Scheme... 으로 이동합니다. (단축키: Cmd + <)
  2. 왼쪽 목록에서 Run을 선택합니다.
  3. 오른쪽의 Info 탭에서 Build Configuration을 'Debug'에서 'Release'로 변경합니다.

이제 'Run' 버튼(Cmd + R)을 누르면 릴리즈 설정으로 앱이 빌드되고 시뮬레이터나 기기에 설치됩니다. 디버거가 연결된 상태이므로, 크래시가 발생한다면 어느 지점인지 대략적으로 파악할 수 있습니다.

주의: 최적화가 활성화된 상태이므로, 변수 값을 확인(po)하거나 브레이크포인트를 설정해도 예상과 다르게 동작할 수 있습니다. 코드가 인라인 처리되거나 순서가 바뀌어 브레이크포인트가 엉뚱한 곳에서 멈추거나, 변수가 이미 레지스터로 옮겨져 메모리에서 사라지는 등의 현상이 발생할 수 있습니다. 그럼에도 불구하고, 앱의 동작을 직접 관찰하고 로그를 확인하는 것만으로도 큰 단서를 얻을 수 있습니다.

2단계: 원인이 되는 빌드 설정 찾아내기 (이분 탐색)

릴리즈 설정으로 문제를 재현했다면, 이제 어떤 설정이 범인인지 찾아낼 차례입니다. 디버그 설정과 릴리즈 설정의 차이점을 하나씩 바꿔가며 테스트하는 것이 핵심입니다.

가장 효율적인 방법은 디버그 설정을 기반으로 시작하여, 릴리즈 설정의 값을 하나씩 적용해보는 것입니다.

  1. 프로젝트 설정의 'Build Settings'로 이동합니다.
  2. 먼저, 가장 유력한 용의자인 최적화 수준(Optimization Level)을 변경합니다. Debug 설정의 -Onone을 Release 설정인 -O로 바꿔봅니다. 그리고 다시 빌드하여 문제가 재현되는지 확인합니다.
    • 문제가 재현된다면, 범인은 '최적화 수준' 자체이거나 이와 관련된 다른 최적화 옵션일 가능성이 높습니다.
    • 문제가 재현되지 않는다면, '최적화 수준'은 그대로 두고 다음 용의자로 넘어갑니다.
  3. 그 다음 용의자는 컴파일 모드(Compilation Mode)입니다. Debug 설정의 'Incremental'을 Release 설정인 'Whole Module'로 바꿔봅니다. 그리고 다시 빌드하여 테스트합니다.
    • 많은 경우, 이 단계에서 문제가 재현됩니다. 이는 '전체 모듈 최적화' 과정에서 코드의 구조가 예기치 않게 변경되었음을 의미합니다.
  4. 이런 방식으로 'Dead Code Stripping' 관련 설정 등 릴리즈와 디버그 간에 차이가 나는 다른 설정들도 하나씩 변경하며 테스트합니다.

이 과정을 통해 "아, 내 문제는 '전체 모듈 최적화'를 켰을 때만 발생하는구나!" 와 같이 문제의 원인이 되는 특정 설정을 정확히 식별할 수 있습니다.

3단계: 문제 해결을 위한 구체적인 액션 플랜

원인이 되는 설정을 찾았다면, 이제 해결책을 적용할 수 있습니다.

Case 1: '컴파일 모드'가 원인일 때

만약 '전체 모듈(Whole Module)' 최적화가 문제의 원인으로 밝혀졌다면, 가장 간단하지만 최후의 수단은 릴리즈 빌드의 컴파일 모드를 '증분(Incremental)'으로 바꾸는 것입니다. 이렇게 하면 문제는 해결되겠지만, '전체 모듈 최적화'가 가져다주는 성능 향상 효과를 포기해야 합니다. 이는 앱의 성능에 민감한 경우 상당한 손실이 될 수 있습니다.

따라서 더 나은 접근법은 문제가 되는 특정 코드에만 최적화를 비활성화하는 것입니다. Swift 5.1부터는 함수 단위로 최적화 수준을 제어할 수 있는 속성(Attribute)을 제공합니다.

UI 레이아웃을 계산하거나 뷰를 구성하는 복잡한 함수가 의심된다면, 해당 함수 선언부 바로 위에 @_optimize(none)을 추가해 보세요. 


@_optimize(none)
func setupComplexLayout() {
    // 이 함수 내의 코드는 컴파일러 최적화가 적용되지 않습니다.
    // 디버그 빌드에서와 거의 동일하게 동작할 것을 기대할 수 있습니다.
    let titleLabel = UILabel()
    // ... 복잡한 프레임 계산 및 뷰 추가 로직 ...
}

@_optimize(none)은 비공식적인(underscored) 속성이지만, 이러한 문제를 해결하는 데 매우 효과적이며 널리 사용되고 있습니다. 이 방법을 사용하면 앱 전체의 성능은 유지하면서 문제의 소지가 있는 부분만 안정적으로 실행시킬 수 있습니다.

Case 2: '최적화 수준'이 원인일 때

-O 최적화 자체가 문제라면, 이는 코드의 실행 순서나 타이밍에 의존하는 부분이 있다는 강력한 신호입니다. 이 경우, 코드 레벨에서 문제를 해결하는 것이 가장 바람직합니다.

  • 레이아웃 업데이트 시점 명시: 뷰의 프레임이나 제약 조건을 변경한 후에는 setNeedsLayout()과 layoutIfNeeded()를 적절히 사용하여 시스템에 레이아웃 업데이트가 필요함을 명시적으로 알리고, 필요하다면 즉시 동기적으로 레이아웃을 갱신하도록 강제해야 합니다.
  • 실행 순서 의존성 제거: 코드 블록이 특정 순서로 실행되어야만 한다면, 비동기 코드나 클로저 콜백 등을 사용하여 실행 순서를 명확하게 보장하는 로직으로 리팩토링하는 것을 고려해야 합니다.
  • volatile 키워드 고려(C/Objective-C): 만약 C 계열 코드와 혼용하고 있다면, 컴파일러 최적화로 인해 값이 변경될 수 있는 변수에 volatile 키워드를 사용하여 컴파일러가 해당 변수에 대한 메모리 접근을 최적화하지 않도록 강제할 수 있습니다.

최후의 수단으로, '컴파일 모드' 케이스와 마찬가지로 @_optimize(none)을 사용하여 문제가 되는 함수의 최적화를 끌 수 있습니다.

Case 3: '데드 코드 스트리핑'이 원인일 때

릴리즈 빌드에서만 특정 클래스나 라이브러리 기능을 찾을 수 없어 크래시가 발생한다면 이 경우를 의심해볼 수 있습니다.

  • 사용되지 않는 코드(Other Linker Flags): 빌드 설정의 'Other Linker Flags'에 -ObjC 플래그를 추가하면, Objective-C 클래스와 카테고리를 정적 라이브러리에 있더라도 모두 로드하여 스트리핑되는 것을 방지할 수 있습니다.
  • 명시적 참조 추가: 가장 확실한 방법은, 동적으로 참조되는 코드(클래스, 함수 등)를 코드 어딘가에서 명시적으로 한 번 참조해주는 것입니다. 컴파일러가 해당 코드가 사용된다고 인지하게 만들어 스트리핑 대상에서 제외시키는 원리입니다.

4. 예방이 최선이다: 견고한 UI 코드를 위한 제언

문제가 터진 후 해결하는 것도 중요하지만, 처음부터 이런 문제가 발생할 가능성을 줄이는 것이 더 좋습니다. 릴리즈 빌드 최적화에 더 강건한 UI 코드를 작성하기 위한 몇 가지 습관을 소개합니다.

  1. Auto Layout을 적극적으로 사용하라: 뷰의 프레임을 직접 계산(CGRect)하는 방식은 컴파일러 최적화에 취약할 수 있습니다. 반면, Auto Layout은 '관계'와 '규칙'을 정의하는 선언적인 방식입니다. "이 버튼은 항상 컨테이너의 중앙에 위치한다"와 같은 제약 조건은 컴파일러가 임의로 해석하거나 순서를 바꿀 여지가 훨씬 적습니다. Auto Layout 시스템이 내부적으로 최적의 레이아웃 계산을 수행하므로, 실행 순서에 따른 타이밍 문제에서 훨씬 자유로워집니다.
  2. UI 생명주기를 존중하라: 뷰의 초기화(init) 시점에서 다른 뷰의 크기나 위치에 의존하는 복잡한 프레임 계산을 수행하지 마세요. 이 시점에는 다른 뷰들이 아직 레이아웃되지 않았을 수 있습니다. UI 구성 및 초기 위치 설정은 viewDidLoad()에서, 뷰의 크기와 관련된 레이아웃 조정은 viewWillLayoutSubviews()나 viewDidLayoutSubviews()에서 수행하는 것이 원칙입니다.
  3. `DispatchQueue.main.asyncAfter`를 레이아웃 꼼수로 사용하지 마라: 레이아웃이 깨질 때 "아주 잠깐" 뒤에 실행하면 해결되는 경우가 있습니다. DispatchQueue.main.asyncAfter(deadline: .now() + 0.01) { ... } 와 같은 코드는 최악의 안티패턴입니다. 이는 근본적인 타이밍 문제를 덮어둘 뿐이며, 디바이스의 성능이나 시스템 부하에 따라 언제든 다시 깨질 수 있는 시한폭탄과도 같습니다.
  4. 주기적으로 릴리즈 빌드를 테스트하라: 개발 막바지에 이르러서야 릴리즈 빌드를 처음 테스트하는 습관을 버려야 합니다. 개발 중간중간 주기적으로 TestFlight 등을 통해 릴리즈 빌드를 테스트하는 문화를 정착시키면, 문제가 발생하더라도 훨씬 작은 코드 변경 범위 내에서 원인을 찾을 수 있어 디버깅 비용을 크게 줄일 수 있습니다.

결론: 단순한 버그가 아닌, 이해해야 할 시스템의 특성

디버그와 릴리즈 빌드 간의 UI 불일치는 Xcode나 Swift의 버그가 아니라, '성능'이라는 목표를 달성하기 위한 컴파일러 최적화의 자연스러운 결과물인 경우가 대부분입니다. 이 문제를 마주했을 때 우리는 좌절하기보다는, 컴파일러가 내 코드를 어떻게 바라보고 해석하는지를 이해할 수 있는 좋은 기회로 삼아야 합니다.

핵심은 체계적인 접근입니다. 첫째, 릴리즈 설정으로 문제를 재현한다. 둘째, 빌드 설정을 하나씩 변경하며 원인이 되는 설정을 고립시킨다. 셋째, 해당 설정의 특성을 이해하고 그에 맞는 해결책(전체 설정 변경, 부분적 최적화 비활성화, 코드 리팩토링)을 적용한다. 이 과정을 통해 우리는 단순히 눈앞의 문제를 해결하는 것을 넘어, 더 견고하고 예측 가능하며 성능 좋은 코드를 작성하는 개발자로 성장할 수 있을 것입니다. 이제 "내 컴퓨터에선 잘 됐는데"라는 말 대신, "어떤 환경에서도 잘 동작합니다"라고 자신 있게 말할 수 있기를 바랍니다.


0 개의 댓글:

Post a Comment