필요성

연산 프로퍼티의 중복되는 로직을 프로퍼티 래퍼에 한 번만 구현하고, 이 로직을 필요로 하는 프로퍼티들 자체에 연결하여 사용할 수 있게 하여 코드의 재사용성을 높일 수 있습니다.

정의하는 방법

struct, class, enum을 만들고 @propertyWrapper 를 맨 앞에 명시해주면 프로퍼티 래퍼를 정의할 수 있습니다.

그리고 반드시 wrappedValue라는 연산 프로퍼티를 구현하여야 합니다.

UserDefaults 예제를 통해 한 번 알아보겠습니다. 먼저 Property Wrapper 전의 코드 상태입니다.

class UserManager {
    static var usesTouchID: Bool {
        get { return UserDefaults.standard.bool(forKey: "usesTouchID") }
        set { UserDefaults.standard.set(newValue, forKey: "usesTouchID") }
    }

    static var myEmail: String {
        get { return UserDefaults.standard.string(forKey: "myEmail") }
        set { UserDefaults.standard.set(newValue, forKey: "myEmail") }
    }

    static var numberOfAccounts: Bool {
        get { return UserDefaults.standard.bool(forKey: "numberOfAccounts") }
        set { UserDefaults.standard.set(newValue, forKey: "numberOfAccounts") }
    }
}

첫째로, UserDefaults를 활용하여 값을 읽거나 쓸 때, 그 key 값으로 항상 String을 사용하고 있는 것을 확인할 수 있습니다.

둘째로, 값을 읽거나 쓸 때, 값의 타입과 관계없이 UserDefaults.standard까지는 동일하게 사용하고 있는 것 역시 확인할 수 있습니다.

마지막으로 가장 중요한건, 위 클래스의 세 연산 프로퍼티가 결국 공통적인 로직을 공유하고 있습니다.

위 세 가지 특징을 파악했으니, 이를 활용하여 Property Wrapper를 이용해서 개선해보도록 하겠습니다.

@propertyWrapper
struct UserDefault<T> {
    let key: String // key는 항상 String 타입let defaultValue: T 
    let defaultValue: T
    private let storage: UserDefaults

    var wrappedValue: T { // property wrapper를 사용하려면 반드시 이 이름으로 연산 프로퍼티를 구현하여야 함
        get {
            storage.object(forKey: key) as? T ?? defaultValue
        }
        set {
            storage.set(newValue, forKey: key)
        }
    }

    init(key: String, defaultValue: T, storage: UserDefaults = .standard) {
        self.key = key
        self.defaultValue = defaultValue
        self.storage = storage
    }
}

class UserManager {
    @UserDefault(key: "usesTouchID", defaultValue: false)
    static var usesTouchID: Bool

    @UserDefault(key: "myEmail", defaultValue: "")
    static var myEmail: String

    @UserDefault(key: "numberOfAccounts", defaultValue: 0)
    static var numberOfAccounts: Int
}

UserManager.usesTouchID = true // set
print(UserManager.usesTouchID) // get

UserManager.myEmail = "myEmail" // set
print(UserManager.myEmail) // get

UserManager.numberOfAccounts = 3 // set
print(UserManager.numberOfAccounts) // get

위 코드의 결과는 다음과 같습니다.

true myEmail 3

원하는대로 동작했음을 확인할 수 있습니다.

projectedValue

추가로 제공하고 싶은 정보가 있다면 어떤 타입이라도 projectedValue를 정의하여 사용할 수 있습니다. 이 값은 프로퍼티 래퍼로 감싼 프로퍼티 앞에 $를 붙여 접근할 수 있습니다.

예를 들어, 위의 예시에서 defaultValue 값을 알고는 있지만 UserManager 클래스를 통해 현재 설정되어 있는 defaultValue를 갖고 오고 싶다고 가정을 해보겠습니다. 현재 상태에서는 바로 defaultValue에 접근할 수 없습니다. 이 때, projectValue를 활용하면 쉽게 defaultValue를 얻어낼 수 있습니다.

@propertyWrapper
struct UserDefault<T> {
    let key: String // key는 항상 String 타입let defaultValue: T 
    let defaultValue: T
    private let storage: UserDefaults

    var wrappedValue: T { // property wrapper를 사용하려면 반드시 이 이름으로 연산 프로퍼티를 구현하여야 함
        get {
            storage.object(forKey: key) as? T ?? defaultValue
        }
        set {
            storage.set(newValue, forKey: key)
        }
    }

    var projectedValue: T { // 반드시 이 이름을 사용하여야 동작함
        defaultValue
    }

    init(key: String, defaultValue: T, storage: UserDefaults = .standard) {
        self.key = key
        self.defaultValue = defaultValue
        self.storage = storage
    }
}

class UserManager {
    @UserDefault(key: "usesTouchID", defaultValue: false)
    static var usesTouchID: Bool

    @UserDefault(key: "myEmail", defaultValue: "")
    static var myEmail: String

    @UserDefault(key: "numberOfAccounts", defaultValue: 0)
    static var numberOfAccounts: Int
}

print(UserManager.$usesTouchID) // projectedValue
print(UserManager.$myEmail) // projectedValue
print(UserManager.$numberOfAccounts) // projectedValue

위 코드의 결과는 다음과 같습니다.

false

0

정상적으로 동작했음을 확인할 수 있습니다.

• 뷰에서 데이터를 읽으면 해당 뷰에 대한 종속성이 발생하게 됩니다. 다시 말해, 데이터가 변경될 때마다 변경된 값을 반영하기 위해 해당 뷰를 다시 그려야 합니다.
• 뷰 계층에서 읽은 모든 데이터마다 source of truth를 가지는데, source of truth는 뷰 계층 내 또는 외부(의 모델)에 있을 수 있습니다.
• 그러나 반드시 서로 일치해야 하는 하나의 데이터에 대해 여러 개의 source of truth가 존재하고, 이 중 하나라도 값이 바뀐다면, 나머 source of truth에 대해서도 모두 동일하게 관리를 해주어야 일치시켜야 합니다. 이는 매우 번거롭고 어려운 일입니다.
• 이처럼 중복으로 인해 발생하는 비정합성 등의 문제를 해결하려면 하나의 데이터에는 "단 하나의" source of truth만을 가지고 있는 것이 필요합니다.
• SwiftUI의 Data Flow는 앱의 데이터에 대한 Single Source Of Truth(SSOT)를 유지하는데 도움을 주는 다양한 기능들을 제공하여 위에서 언급한 문제를 해결하게 됩니다.

@State

• 프로퍼티를 @State 프로퍼티 래퍼로 감싸면, SwiftUI는 해당 프로퍼티가 언제 변경되는지 알 수 있습니다.
• @State 프로퍼티 래퍼로 감싼 프로퍼티를 private로 접근 제어하면, 해당 뷰만이 그 프로퍼티를 소유하고 관리하게 할 수 있습니다.
• @State 프로퍼티 래퍼로 감싼 프로퍼티가 변경되면, SwiftUI는 런타임에 해당 뷰와 그 자식 뷰들을 모두 재계산합니다.
• 모든 변경 사항은 항상 뷰 계층을 따라 전파됩니다.
• SwiftUI는 뷰를 비교하여 변경된 것만 다시 렌더링하기 때문에, 매우 효율적으로 뷰들의 변화를 반영할 수 있습니다.

@Binding

• @Binding 프로퍼티 래퍼를 통해 프로퍼티를 직접 소유하지 않고도 해당 프로퍼티의 source of truth에 대한 명시적인 의존성을 정의할 수 있습니다.
• Toggle, TextField, Slider와 같은 primitives view들은 binding을 필요로 합니다.
• binding으로 프로퍼티를 "직접 소유하지 않고 참조"하여 읽거나 쓸 수 있습니다. 이를 통해 별도로 source of truth를 또 만들지 않고 하나만 유지할 수 있습니다.

Publisher(External Changes)

• 뷰 계층 내부가 아닌 외부의 source로부터 이벤트를 받는 경우에는 Combine의 Publisher를 활용하게 됩니다.

ObservableObject(External Data)

• 데이터가 뷰 외부에 있을 때, SwiftUI는 해당 데이터의 변경에 어떻게 반응할 것인지에 대해 알아야 합니다.
• 먼저, 뷰 외부의 데이터가 ObservableObject 프로토콜을 준수하도록 함으로써, 데이터가 변경될 때마다 발생하는 objectWillChange 프로퍼티를 통해 액세스할 수 있는 Publisher가 있어야 합니다.
• 이후에 모델을 @ObservedObject 프로퍼티 래퍼로 감싸고, ObservedObject를 뷰의 이니셜라이저에 전달하면 됩니다.
• SwiftUI에서의 뷰는 value type(struct)이지만, reference type(class)을 사용할 때마다 @ObservedObject 프로퍼티 래퍼를 사용해야 합니다. 이렇게 하면 SwiftUI는 데이터가 언제 변경되는지 알고 뷰 계층을 최신 상태로 유지할 수 있습니다.

Environment

• .environment modifier 덕분에 ObservableObject를 환경에 추가할 수 있습니다. ######
• @EnvironemntObject 프로퍼티 래퍼를 사용하면 이러한 환경 객체들에 대한 종속성을 만들 수 있습니다.

Object Binding vs Environment

• @Binding으로 전체 앱을 빌드할 수는 있지만, 뷰에서 뷰로 모델을 전달하는 것은 번거로울 수 있습니다. ######
• EnvironmentObject는 계층 주변에 데이터를 간접적으로 전달하기에 편리합니다. 각 뷰에 객체를 직접 전달할 필요가 없어지기 때문입니다.

@State vs @ObservedObject

• @State은 로컬 뷰, value type, 관리되는 데이터에 적합합니다.
• @State는 SwiftUI에 의해 할당되고, 생성되고 관리됩니다.
• @State는 value type입니다. ######
• @ObservedObject는 데이터베이스와 같은 SwiftUI의 외부 데이터를 나타내기 위한 것입니다.
• @ObservedObject는 우리가 직접 관리하는 storage이며, 이미 가지고 있는 모델에 적합합니다.
• @ObservedObject는 SwiftUI가 아니라 우리가 직접 관리합니다.
• @ObservedObject는 reference type입니다.

Reset: 특정 과거 시점으로 돌아가기 Revert: "변경 커밋을 남기며" 특정 과거 시점으로 돌아가기

기본적으로 둘다 과거 시점으로 돌아가기 위해 사용하는 명령어지만, 엄연히 둘 간의 차이점이 있다. 알아보도록 하자!

Reset 이해하기

reset의 경우 과거로 돌아가는 방법에는 3가지가 있으며, 방법에 따라 변화가 달라진다.

명확한 이해를 위해 예시를 통해 자세히 살펴보자.

현재 HEAD가 Main Branch가 가리키고 있는 274aacc를 가리키고 있는 상황이다. 그 상태에서 Working Directory에서 코드를 추가로 작성하여 변경사항이 발생하였다. 이 때,

git reset --hard Da3de11

를 실행한다면 Working Directory 뿐만 아니라 Staging Area, Local Repository까지 Da3de11 시점으로 돌아가게 된다.

반면,

git reset (--mixed) Da3de11
(reset의 default값은 --mixed이므로 생략 가능)

의 경우에는 Working Directory만 변경되지 않고, 나머지는 모두 Da3de11 커밋 시점으로 돌아갈 것이다.

마지막으로,

git reset --soft Da3de11
(reset의 default값은 --mixed이므로 생략 가능)

의 경우에는 Local Repository만 Da3de11 커밋 시점으로 돌아갈 것이다.

결국 reset을 사용할 때는 다음을 고려하여 옵션을 결정하고 사용해야 한다.

• 코드 변경 상태 적용 여부
  • Working Directory만 변경 사항이 적용 되었는가?
  • Working Directory + Staging Area까지 변경 사항이 적용 되었는가?
  • Working Directory + Staging Area + Local Repository까지 변경 사항이 적용 되었는가?
• 개발자의 reset 목적
  • Working Directory, Staging Area, Local Repository 중에서 특정 시점으로 되돌릴 대상은 명확히 어디인가?

🤔 reset을 잘못했을 때, 어떻게 해야하지?

아래는 원래 HEAD가 90ac000 커밋을 가리키고 있었으나

git reset --hard 48ea1f3

을 통해 48ea1f3 커밋 시점으로 되돌아간 상태를 보여주고 있다.

option이 --hard이므로 Local Repository로부터 Working Directory까지 모두 48ea1f3 시점으로 변경된 상태이다. 근데 reset을 잘못하여 다시 원래대로 돌아가고 싶을 때 어떻게 해야할까?

당황스러운 마음으로 일단,

git log

를 입력해보지만, 이미 reset 되어 다시 원래대로 가고자 하는 commit은 전혀 보이지 않는다... 눈물을 머금고 코드를 다시 작성해야 할까?

아니다! 다시 복원할 수 있다. "git reflog"와 "git reset"을 활용하여 "reset을 다시 reset" 할 수 있다.

🤔 git reflog

• reference log
• git log와 달리 한번이라도 commit이 된 내용이라면 현재 저장소 tree에 일반적으로 보이지 않는 모든 commit들을 보여줌
• 따라서 git reflog를 통해 reset으로 인해 유실된 commit id를 먼저 찾고,

  git reset --hard (유실된 commit id)

  를 통해 다시 원래대로 돌아갈 수 있다.

reset의 특징을 다시 정리해보면...

• git reset --soft: Local Repo만 리셋
• git reset --mixed: Local Repo + Staing Area만 리셋
• git reset --hard: Working Directory까지 모두 리셋
• 잘못된 리셋의 복구도 리셋으로 가능
  • git reflog를 통해 먼저 유실된 commit id를 확인
  • git reset --hard (유실된 commit id)를 통해 복구

reset의 주의사항!

• 커밋의 시점을 변동하기 때문에, 협업 시 주의가 필요
  • reset했을 때 Local Repository가 변경되어 Remote Repository와 불일치하여 충돌 가능성이 다분

• 따라서 "remote repo에 push하기 전" 상황에서 사용하는 것이 가급적 좋으며, "remote repo를 혼자 사용하거나 팀원과 협의된 경우"에는

git push --force

로 해결도 가능

Revert 이해하기

revert의 경우 reset과 달리 option이 없고 변경 커밋을 남기며 과거 시점으로 돌아간다는 것이 핵심이다. reset과의 비교를 통해 알아보자.

위와 같은 상태에서 Da3de11 커밋 시점으로 돌아가고자 한다. 먼저, reset의 경우에는 HEAD를 돌아가고자 하는 커밋 시점을 가리키게 한다. 물론 이로 인해 유실된 commit id는 git reflog를 통해 확인할 수 있다.

다음으로 revert의 경우를 살펴보자. revert의 경우는 변경 커밋을 남기면서 돌아가고자 하는 시점의 커밋과 동일한 내용으로 만든다. 과거 시점 커밋의 내용과 동일하게 만들기 위해 가장 최근 시점의 커밋부터 차례대로 이를 상쇄하는 변경 커밋을 만들어간다고 이해하면 될 것이다. 따라서, 실행 결과는 과거 시점 커밋의 내용과 일치하지만 reset과 달리 HEAD는 미래 시점의 커밋을 가리키고 있다.

아래 그림은

git revert 274aacc...Da3de11

를 실행한 결과를 그림으로 보여준다.

revert의 특징을 다시 정리해보면...

• 과거 커밋 시점으로 돌아갈 때, reset과 달리 변경 이력을 남기며 돌아감
• 코드의 시점은 과거로 변하지만, 커밋은 미래 시점으로 변경
  • reset과 달리 충돌없이 Remote Repository Push가 가능
  • 협업시 가급적 reset이 아닌 revert가 권장됨

• 다만, revert도 잘못 사용하면 충돌이 일어날 수도 있음
  • e.g. 과거 시점의 특정 commit만 revert 하는 경우(권장하지 않음)

🤔 git commit --amend

• 가장 최근 커밋을 수정하는 편리한 방법
• 새 커밋을 별도로 생성하는 것이 아니라 기존의 최신 커밋을 수정함
• 사용 예시
  • commit의 message를 수정하고 싶을 때
    • git commit --amend 명령어 입력 후 message 수정 후 commit
  • commit된 file, code를 수정하고 싶을 때
    • git add 명령어를 통해 먼저 Staging Area를 변경
    • 그 이후에 git comit --amend 명령어 입력 후 다시 commit
• 주의할 점은 수정 전의 최신 커밋을 이미 remote repo에 push한 경우에는 git commit --amend로 커밋을 수정한 후에 push할 때 충돌이 발생함

그런데 돌아보니 단 한번도 "swift는 과연 어떤 과정을 거쳐 빌드가 되고 있는가?"에 대한 진지한 고민은 한 번도 해본 적이 없다는 것을 깨달았습니다. 그저 단축키만 무작정 눌러왔는데.. 별로 좋은 습관은 아니겠죠..? 그래서 한번 알아보았습니다!

기초개념: 컴파일? 링크? 빌드? 런?

먼저, 기본적인 개념부터 알아봐야겠죠? 정말 많이 들어봤을 위 개념들에 대해 매우 간단하게 먼저 살펴보죠!

컴파일러 컴파일러는 특정 프로그래밍 언어로 쓰여 있는 문서를 다른 프로그래밍 언어로 옮기는 언어 번역 프로그램을 말한다. -위키 백과

사람이 작성한 언어를 기계가 읽을 수 있도록 번역하는 것이 바로 컴파일입니다!

링크 컴파일러의 결과물인 목적(object)코드들을 최종 실행 가능한 실행파일 만들기 위해 연결 및 병합 해주는 작업 -위키 백과

컴파일시, 연관된 파일들을 엮어서 합쳐주는 과정입니다!

빌드 빌드는 소스코드 파일을 컴퓨터나 휴대폰에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 과정을 말하거나 그에 대한 결과물을 일컫는다. -위키 백과

빌드는 코드, 리소스 등을 하나로 합쳐 실행 가능한 파일을 만드는 과정입니다!

런(실행) 어떠한 제품을 실제 장치에서 실행시키는 프로세스이다. -위키 백과

빌드된 파일을 시뮬레이터나 실제 디바이스에서 실행시키는 과정입니다!

정리하면,

• 런(실행) 하기 위해서는 빌드된 파일이 있어야 하고,
• 빌드 안에는 컴파일 과정이 포함되어 있으며
• 컴파일 과정 안에 링크 과정이 포함되어 있습니다!

빌드 과정

이제부터는 우리의 주 관심인 빌드 과정을 큰 틀을 따라가면서 자세히 살펴봅시다!

많이 들어봤을 전처리기, 컴파일러, 어셈블러, 링커 등이 보입니다. 위 그림의 흐름을 따라가면서 swift의 빌드 과정을 살펴봅시다!

전처리기(preprocessor)

작성한 소스코드를 컴파일러에 제공할 수 있도록, 컴파일 전에 전처리를 먼저 실행합니다.

• 매크로를 실제 정의로 바꿈(e.g. #define)
• 파일 간의 참조 관계(종속성)를 파악(e.g. #include)
• 컴파일 조건문을 파악(e.g. #if~, #if else, #endif)

그러나, swift 컴파일러에는 전처리기가 없습니다!

• 그래서, swift에서는 매크로를 사용할 수 없음..

🤔 하지만, swift에서도 파일 간의 참조 관계(종속성)나 컴파일 조건문은 분명 존재하는데, 이를 어떻게 처리하고 있는걸까요..?

• llbuild(하위 레벨 빌드 시스템)을 통해 종속성을 해결함
  • llbuild(low-level build system): 빌드 시스템을 구축하기 위한 라이브러리 세트

• 컴파일 조건문은 아래 그림과 같이 프로젝트의 Build Settings에서 flag를 설정하여 사용 가능
• Active Compliation Conditions에 RELEASE를 추가하여 DEBUG 모드냐 RELEASE 모드냐에 따라 코드가 다르게 동작하게 할 수 있음
  #if RELEASE print("RELEASE에서만 할 코드") #elseif DEBUG print("DEBUG에서만 할 코드") #endif

• Other Swift Flags에 원하는 flag를 추가하여 사용 가능

  • 단, -D라는 prefix를 반드시 붙여주어야 함

  #if FLAG1 print("앱 타켓에서만 할 코드") #endif

컴파일러(Complier)

소스코드에 대한 정보를 수집하는 symbol table을 작성 및 관리하며, 아직 고수준 언어를 저수준 언어인 어셈블리어로 변환합니다.

그리고, swift의 컴파일 과정은 아래 그림과 같이 LLVM을 거쳐서 실행됩니다.

🤔 LLVM이란?(약자가 아닌 프로젝트명입니다!)

• 프로그램을 컴파일, 링크, 런타임 등의 상황에서 프로그램의 작성 언어에 상관없이 최적화를 쉽게 구현할 수 있도록 구성되어 있는 컴파일러이자 툴킷
• 중간 표현(Intermediate Representation, IR), 이진(binary) 코드를 구성, 최적화 및 생성하는데 사용되는 라이브러리

본격적으로 swift의 컴파일 과정을 한번 살펴봅시다!

• 프론트엔드
  • 소스코드 => swift AST
  • swift AST => swift IL(SIL)
  • swift IL => LLVM IR
• LLVM IR => 백엔드
• 백엔드(LLVM)
  • LLVM IR => 어셈블리어
  • 어셈블리어 => 기계어

즉, swift는 총 2번의 최적화 과정을 거칩니다!

• 프론트엔드: swift AST => SIL
• 백엔드: LLVM IR => 기계어

🤔 SIL(Swift Intermediate Language)이란?

• swift의 소스 코드를 실행 가능한 바이너리 코드로 바꿀 때, 다른 컴파일러(LLVM)가 취급하기 쉬운 중간 표현(IR)로 변환한 코드(* LLVM IR과 다름!)
• swift를 분석하고 최적화하는데 적합하게 변환된 코드 참고: [번역] SIL(Swift Intermediate Language), 일단 시작해보기까지

1. 프론트엔드

• 두 가지 컴파일러를 지원
  • Swift Compiler: swift 용
  • Clang: C languagues 용
    • 소스 코드에 대한 정보를 수집하는 symbol table를 생성
    • 소스 코드를 분석 및 최적화하고, 이를 LLVM이 어셈블리어로 번역해 줄 중간 언어인 LLVM IR을 생성

2. 백엔드(LLVM)

• 프론트엔드로부터 넘겨받은 LLVM IR을 어셈블리어로 변환하고, 어셈블러가 이를 기계어로 변환
• 이 때, 비트코드를 생성하는 것으로 설정하면 비트코드로도 변환
  • LLVM 어셈블러인 llvm-as가 LLVM IR을 LLVM 비트코드로 변환
  • 아래 그림처럼 설정이 가능하고, Yes로 설정하지 않으면 비트코드 파일은 생성되지 않고 기계어만 생성됨

🤔 비트코드(bitcode, .bc)란?

• IR(Intermediate Representation) 종류 중 하나
• LLVM에 의해 컴파일된, 소스코드와 기계어의 중간단계로 어떤 아키텍처(디바이스)에서도 실행되기를 준비하는 중간단계

어셈블러

사람이 읽고 해석할 수 있는 어셈블리 코드를 재배치가능한(relocatable) 기계어로 변환합니다. 이 때, Mach-O(Mach Object file format) 파일을 생성합니다.

• 컴파일 과정에서 언급한 백엔드(LLVM)의 어셈블러가 어셈블리어를 기계어로 변환합니다!

• 🤔 기계어란?

  • CPU에서 직접 실행할 수 있는 명령들의 집합을 나타내는 이진 언어

• 🤔 Mach-O(Mach Object file format)란?

  • 의미가 있는 data chunks로 그룹화된 바이너리 바이트 스트림으로 구성됨
  • Darwin 기반 OS(iOS, MacOS, ...)에서 쓰이는 특정한 바이너리 파일 포맷
  • chunks에는 바이트 순서, CPU 타입, chunks 크기 등과 같은 메타 데이터가 포함됨

• 🤔 재배치가능한 파일이란?

  • 실행가능한 파일이나 공유 오브젝트 파일을 생성하기 위해 다른 오브젝트 파일들과 링킹할 수 있는 코드와 데이터를 갖는 파일
  • 아직 실행가능하진 않지만, 실행가능한 오브젝트 파일을 만들기 위해 재배치가능한 다른 오브젝트 파일들과 링크가 가능

• 🤔 실행파일이란?

  • 바이너리 코드와 데이터를 가지고 있으며, 메모리로 직접 로드되어 실행될 수 있음

링커

Darwin 기반 OS에서 실행할 수 있는 단일 Mach-O 실행 파일을 만들기 위해 다양한 오브젝트 파일들과 라이브러리들을 병합합니다.

• input: 오브젝트 파일(어셈블러의 결과물) + 라이브러리 파일(동적, 정적)
• 어셈블러와의 공통점: 둘 다 Mach-O 파일을 output으로 생성
• 어셈블러와의 차이점: 어셈블러의 Mach-O 파일들은 불완전한 파일
  • 어셈블러: 재배치가능한 오브젝트 파일을 생성
    • 다른 오브젝트 파일들이나 라이브러리들을 참조하는 부분들이 누락된 상태
  • 링커: 아래 그림처럼 프로젝트의 Build Settings의 Linking에서 지정한 타입의 파일을 생성
    • 컴파일 과정에서 생성된 symbol table을 활용하여 여러 오브젝트 파일들과 라이브러리들에 대한 참조를 확인하고, 이들을 연결시켜 줌

• archive를 통해 앱을 업로드하는 과정에 링킹이 포함되어 있음
  • Enable Bitcode No 설정: 최종 컴파일 결과인 실행 가능한 바이너리 파일 자체를 업로드
    • 앱이 실행될 수 있는 모든 환경(다양한 아키텍쳐, 디바이스)에 대한 바이너리를 생성하여 하나의 파일로! => "fat binary"
  • Enable Bitcode Yes 설정: fat binary를 만들지 않고, 비트코드를 업로드
    • 앱 스토어는 업로드된 비트코드를 가지고 각 환경별 최적의 바이너리를 생성(앱 시닝)

비트코드의 장점

• 비트코드는 컴파일된 프로그램의 중간 표현(IR), 따라서 다양한 방식으로 다시 컴파일을 시도할 수 있음
  • 애플은 애플 서버에 제출된 비트코드를 다시 컴파일하여 사용자에게 맞는 최적의 바이너리 파일을 제공할 수 있음
• 애플은 비트코드로 인해 새로운 CPU에 대한 지원을 앱 스토어의 백엔드에 쉽게 추가가 가능해짐
  • 최신 아키텍쳐로 컴파일하는 방법을 비트코드에 표시하여 이에 맞게 컴파일되게 할 수 있음

비트코드, 단점은 없을까?

crash report를 디버깅하고자 할 때(e.g. Firebase Crashlytics), 비트코드를 사용하면 "unsymbolicated crash from missing dSYMs" 에러가 발생하는 경우가 있음

• 개발자가 archive시 생성된 바이너리에 포함된 dSYM 파일과, 앱 스토어에서 비트코드로 생성한 바이너리에 포함된 dSYM 파일이 불일치하여 나타나는 현상
• 해결방법은 앱 스토어에 가서 dSYM 파일을 다운로드 받아, 업로드하여 사용

• 🤔 dSYM(debug symbol file)이란?
  • 컴파일러가 소스코드를 기계어로 변환할때 생성되고, 역할은 기계어를 다시 소스코드 라인으로 매핑하는 정보를 가진 파일
  • Xcode의 build setting에서 Debug Information Format의 설정에 따라 Debug Symbol을 최종 바이너리에 포함시킬지, 별도의 파일로 추출되도록 할 지 설정할 수 있음

앱 시닝(App Thinning)

서로 다른 각 디바이스에서 필요한 내용만을 선택하여 앱 번들로 만들고 전달하는 과정입니다!

위 그림처럼 범용 앱(universal app) 하나를 업로드 하면, 앱 스토어에서 슬라이스가 발생하게 됩니다!

앱 스토어가 디바이스의 특성을 보고, 아래 그림처럼 필요한 것만 조합해서 별도의 IPA를 만듭니다.

• 🤔 IPA란?
  • iOS App Store Package의 줄임말로, 패키징이 끝난 압축파일
  • 애플 모바일 스마트기기의 운영체제인 iOS에서 사용하는 앱의 설치 파일 - Xcode에서 앱을 만들면 .app 파일이 되는데, 이 파일을 .zip 형식으로 압축해 확장자만 .ipa로 바꾸는 방식을 사용

깃(Git)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다. 또는 이러한 명령어를 가리킨다. 소프트웨어 개발에서 소스 코드 관리에 주로 사용되지만 어떠한 집합의 파일의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다. 기하학적 불변 이론을 바탕으로 설계됐고, 분산 버전 관리 시스템으로서 빠른 수행 속도에 중점을 두고 있는 것이 특징이며 데이터 무결성, 분산, 비선형 워크플로를 지원한다. -위키백과

소프트웨어 구성관리(SCM, Software Configuration Management)

소프트웨어 공학에서 소프트웨어 구성 관리(software configuration management, SCM, S/W CM)는 더 범위가 큰 구성 관리의 학문간 분야의 일부인, 소프트웨어의 변경사항을 추적하고 통제하는 작업이다. SCM 행위에는 버전 관리, 베이스라인 확립이 포함된다. 무언가 잘못되는 경우 SCM은 변경사항과 변경한 사람을 특정할 수 있다. 구성이 잘 된 경우 SCM은 수많은 호스트에 걸쳐 이를 복제(replicate)하는 방법을 결정한다. -위키백과

우리는 바로 "Git"을 통해 소프트웨어 구성관리를 하고 있다고 생각하면 될 것 같습니다!!!

버전 관리 시스템(VCS, Version Control System)

파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전으로 꺼내올 수 있는 시스템

버전 관리 시스템에는 CVCS vs DVCS가 존재

CVCS(중앙집중식 VCS, Cenral Version Control System)

장점

• 운영/관리가 직관적
• 관리자가 모든 작업에 대해 실시간 체크 가능

단점

• 커밋시 바로 중앙 히스토리에 반영
• 자신만의 작업 히스토리는 존재하지 않음
• 규모가 커질수록 매우 느려짐. why?
  • 버전 관리 관련 연산을 "중앙서버"에서 모두 처리
  • 델타(Delta) 방식으로 데이터를 관리

🤔 델타 방식

• 프로젝트 내의 각 파일의 변경사항을 시간순으로 계속 쌓아가며 파일들의 집합을 관리하는 방식
• 파일의 생성부터 변경사항들을 계속 따라가야 하고, 버전을 가져올 때 변경사항들을 계산하여 가져와야 해서, 커밋이 많아질수록 속도가 느려짐
  • 버전 5를 가져오려면 파일의 생성을 기준으로, 모든 델타들을 계산하여 가져와야하기 때문에 커밋이 쌓일수록 느려질 수 밖에 없음

DVCS(분산형 VCS, Distribution Version Control System)

장점

• 코드의 분산관리로 인해 중앙서버 데이터가 유실되어도 복구 가능
• 자신만의 작업공간이 별도로 있기 때문에, 네트워크가 연결되어있지 않아도 커밋 등 버전 관리가 가능
• 규모가 커지더라도 속도가 빠름
  • 버전 관리를 위한 대부분의 연산이 "로컬"에서 이루어짐
  • 스냅샷(Snapshot) + 델타 방식으로 데이터를 관리

🤔 스냅샷

• 파일을 하나씩 별도로 보며 차이점(즉, 델타)만 따로 관리하지 않고, 프로젝트 전체를 스냅샷 형태로 관리
• 매 순간마다 프로젝트 전체를 사진으로 찍어서 관리하는 것과 같은 형태
• 버전이 변경되면 변경된 버전의 스냅샷을 하나 만들어 놓고 그 스냅샷을 가리키는 레퍼런스를 저장
• 효율을 위해, 변경되지 않은 파일은 새로 저장을 하는 것이 아니라 이미 저장되어 있는 파일에 링크만 걸어줌

• 매 버전마다 스냅샷을 만들고 저장하면 많은 용량을 차지하고 느려지지 않을까? => No!!!
  • 마지막 커밋의 스냅샷만 통째로 저장하고 나머지 커밋에 대해서는 스냅샷과 스냅샷이 차이를 기록한 "델타"만을 저장하기 때문임 (스냅샷 + 델타로 데이터 관리)

• 버전별로 전체 스냅샷을 모두 저장하지 않아도 마지막 스냅샷을 기준으로 특정 시점의 스냅샷을 만들 수 있어, 저장소의 크기도 자연스럽게 줄어듦

Git의 중요 5대 개념

1. 파일상태
2. 작업공간
3. 커밋
4. 브랜치
5. HEAD

git의 대부분의 기능은 위 5가지 개념을 활용하는 과정

git init: Git 시작을 위한 초기화

• CLI에 git init 명령어 입력시, .git 폴더가 생성됨
• git은 코드 변화에 대한 히스토리 및 상태를 .git 폴더에서 관리
  • .git 폴더 삭제시, 관리하던 모든 이력이 삭제됨
    • 따라서, 작업했던 프로젝트 파일이 있더라도 git 관리가 불가능
  • 커밋, 로그, 데이터 등을 git 내부적으로 Refs, Blob, Tree 시스템을 통해 관리

git add: Working Directory to Staging Area

Working Directory

Untrackted

• 아직 git에 의해 한번도 관리되지 않은 상태
• 즉, git add 명령어로 아직 한번도 Staging Area에 진입하지 않은 상태

Tracked

• git add 명령어를 통해 Staging Area에 진입하여 git에 의한 관리가 시작된 상태

Modified

• "Tracked" 상태의 파일이 수정된 상태

Staging Area

• Git Index라고도 함
• 워킹 디렉토리의 변경사항을 바로 로컬 저장소에 기록(커밋)하는 것이 아니라, 여기에 먼저 기록하는 과정을 거침
  • 다음 커밋의 스냅샷을 위한 밑바탕
  • 작업 과정에서의 중간 산출물을 적절하게 선택하여 커밋을 할 수 있음
• 병합 충돌(merge conflict)가 일어났을 때, 임시 상태의 데이터를 관리
  • Staging Area가 없다면 메모리 상에서 이를 관리해야 함

git commit: Staging Area to Local Repository

commit

• 의미있는 변화에 대한 히스토리
• Staging Area에 Index된 코드의 변화를 커밋을 통해 히스토리화
• root commit을 제외한 커밋들은 parent commit을 가짐
• 현재 커밋의 이전 커밋이 parent commit
• 부모 커밋에 변화가 발생하면, 부모 커밋의 자식 커밋도 변화
  • 이러한 현상은 연쇄적으로 발생하기 때문에, 특정 커밋에 변화가 발생하면 이후의 모든 커밋에 변화가 발생
  • 따라서, 특정 커밋을 변화하고자 시키고자 하는 경우에는 주의가 필요(특히, 협업시 주의 요망)
• 변화된 값과 커밋 정보를 기반으로 SHA-1 알고리즘 해싱을 하여 commit id를 생성

커밋 정보(log)에는 어떠한 정보들이 있을까?

• 작성자, 작성일자
• 커밋 메세지
• 커밋 ID(hash)
• 변경이력
• parent commit
• Etc.

commit은 매우 중요하다!!!

• 프로젝트가 커지면 커밋의 수도 매우 늘어나므로, 프로젝트의 관리를 수월하게 하기 위해서는 commit을 "잘" 해야함
  • 커밋 메세지는 항상 자세히 기재
  • 커밋 단위에 신경쓰기
    • 작업의 중간물을 저장하는 차원에서 커밋X
    • 여러 기능을 묶어서 커밋X
    • 정상 동작을 보장하는 경우에만 커밋O
  • [참고]: [규칙적인 Commit 메세지로 개발팀 협업하기] (https://xtring-dev.tistory.com/entry/Git-규칙적인-Commit-메세지로-개발팀-협업하기-👾)

commit id

• git 무결성을 위한 체크썸
• 160bit_로 구성: _40자리 * 16진수(4bit)
• SHA-1 알고리즘으로 만들어진 hash 값을 사용하기 때문에 중복값이 없어 commit의 순서를 기억할 수 있고, 이로 인해 온/오프라인 어떤 환경에서도 commit이 가능
• 일반적으로 8~10자로도 프로젝트 내에서 고유성을 유지하기에 충분하기 때문에, git에서는 기본값으로 7자리의 짧은 형태를 사용

git push/fetch, pull: Local Repository <=> Remote Repository

push

• 로컬 저장소에 커밋된 내용(HEAD가 가리키는 커밋)을 원격 저장소로 보내는 명령어

fetch

• 원격 저장소의 최신 내용을 로컬 저장소로 가져오지만, 병합하지는 않는 명령어

pull

• 원격 저장소의 최신 내용을 로컬 저장소로 가져오면서 병합까지 하는 명령어(fetch + merge)

Git의 BRANCH와 HEAD

BRANCH

• 독립적인 작업공간을 생성하는 개념
• 여러 브랜치를 생성하여 하나의 프로젝트를 여러 갈래로 나누어서 독립적으로 관리할 수 있음
• 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능
• 브랜치는 항상 생성된 해당 브랜치의 가장 마지막 커밋을 가리킴

HEAD

• 특정 커밋을 가리키는 특수한 포인터
• HEAD에 따라 워킹 디렉토리의 파일도 변경됨
• git checkout 명령어를 통해 HEAD 포인터를 변경하여 작업 공간을 전환함
  • 다른 브랜치로 옮겨 로컬 브랜치를 변경할 수 있음
  • 해당 브랜치에서 최신 커밋이 아닌 과거의 커밋을 가리킬 수 있음
• 새로운 커밋이 생성된 경우 새로운 커밋을 가리킴
• HEAD의 변경은 git 내부에서 log로 관리
• 일반적으로 브랜치를 가리키지만, 다른 커밋을 가리키게 할 수 있음(Detached HEAD)
  • 과거 시점의 코드를 확인하고자 할 때
  • 과거 시점에서 브랜치를 생성해야 할 때

git merge: 3-way vs Fast-forward

3-way merge

• 새로운 브랜치 생성 이후, 메인 브랜치에서 커밋이 발생하여 Fast-forward merge가 불가능한 상황에 진행

• base commit: 브랜치가 생성되는 기점이 되는 commit
• base commit(274aacc)과 각 브랜치의 commit(0f039ae, E7ac282)을 비교하여 병합
  • 3가지 commit을 비교하여 auto-merge 시도 이후, 해결되지 않는 부분에 대해서는 conflict가 발생

• 3-way merge의 예시

• 3-way merge의 경우, merge의 결과인 merge commit(92a84bb)이 생성됨

Fast-forward merge

• 메인 브랜치에서 분기한 이후, 메인 브랜치에서는 변경 사항이 없는 경우 진행되는 머지

• 구조적으로 conflict는 발생하지 않음
• 3-way와 달리 merge의 결과인 merge commit이 생기지는 않으며, 단지 메인 브랜치의 포인터가 분기한 브랜치의 최신 커밋으로 이동
  • merge에 대한 히스토리가 남지 않기 때문에 이러한 형태의 병합을 선호하지 않는 경우도 있다고 함

git rebase

rebase: 다시 베이스를 만든다!

• 말 그대로 base commit을 변경함
• rebase시, base commit이 변경되어 그 이후의 커밋들이 모두 변경되므로 협업시 주의가 필요
• rebase를 한 이후에는 자동으로 merge됨

• rebase가 불필요한 경우에는 할 필요 없음
  • 아래의 경우는 바로 merge(Fast-forward)하면 됨

🤔 끝내기 전, 짤막한 팁!!!

1. 유닉스 시스템에서 파일명 앞에 .을 붙이면 "숨김파일 처리"가 됩니다.
2. Blob이란? Binary large object를 의미합니다. 큰 객체를 바이너리 형태로 저장한다는 의미로, 주로 멀티미디어 데이터가 이에 해당됩니다.
3. github의 private repository의 경우, 일반적으로 commit 작업 이력이 잔디에 표시되지 않습니다... 따라서, 필요한 경우 별도의 설정이 필요합니다. [참고]: [private 저장소의 작업 내역 github 잔디에 표시하기] (https://codedragon.tistory.com/8745)