나의 두 번째 앱 출시기 — SwiftUI + CoreData로 SoDoIt 만들기!

1인 개발로 SoDoIt(쏘두잇)이라는 투두 앱을 App Store에 출시하면서 마주친 트러블슈팅 4가지를 정리해 보았습니다!

---

목차

1. SoDoIt 소개
2. 기술 스택과 아키텍처
3. 트러블슈팅 1 — SwiftUI에서 CoreData 객체를 삭제하면 크래시가 난다
4. 트러블슈팅 2 — 위젯과 메인 앱의 데이터를 공유하기
5. 트러블슈팅 3 — Color(hex:)의 함정: Swift 연산자 우선순위
6. 회고 — v2에서 바꾸고 싶은 것들
7. 마치며

---

SoDoIt 소개

SoDoIt(쏘두잇) 은 오늘 할 일을 깔끔하게 관리하는 투두 앱입니다.

• 할 일 CRUD: 추가 · 편집 · 삭제 · 완료 토글
• 카테고리: 10가지 색상과 SF Symbol 아이콘 커스터마이징
• 필터·정렬: 스마트 필터(전체/오늘/예정/완료), 카테고리 필터, 다중 정렬
• 마감일 알림: UNUserNotificationCenter 로컬 푸시
• 통계: Swift Charts로 완료율·우선순위·주간 추이 시각화
• 홈 화면 위젯: Small / Medium 두 크기

App Store에 v1.0으로 출시했고, 전부 1인 개발 + Apple 공식 프레임워크만 사용했습니다! (외부 의존성 0)

---

기술 스택과 아키텍처

항목	선택	이유
UI 프레임워크	SwiftUI	선언형 패러다임에 익숙해지고 싶었음
데이터 저장	CoreData (NSPersistentContainer)	외부 의존성 없이 로컬 영속화
반응형 갱신	NSFetchedResultsController + @Observable	SwiftUI에 자연스럽게 데이터 변경 전파
아키텍처	MVVM + Repository	View / 비즈니스 로직 / 영속화 책임 분리
위젯	WidgetKit + App Group	메인 앱과 데이터 공유
폰트	Pretendard (런타임 등록)	한국어 가독성

View (SwiftUI)
  ↓ @Observable
ViewModel
  ↓ 의존성 주입
Repository (CoreData CRUD 캡슐화)
  ↓
CoreDataManager (NSPersistentContainer)

SwiftUI를 쓰다 보면 "데이터가 바뀌면 UI가 자동으로 다시 그려진다"가 자연스럽게 느껴지는데, CoreData NSManagedObject를 같이 사용하면 헷갈리는 부분이 많아지더라구요. 그래서 이 부분에 대해 작성해 보았습니다.

---

트러블슈팅 1 — SwiftUI에서 CoreData 객체를 삭제하면 크래시가 난다.

SwiftUI + CoreData를 처음 만지면 거의 무조건 겪는 함정이라고 생각하는 부분입니다. 이 부분은 한 번 제대로 이해해두면 비슷한 류의 문제는 다 풀 수 있습니다.

문제 1

카테고리 목록에서 카테고리를 스와이프로 삭제하면 앱이 그대로 꺼졌습니다. (ㅠㅠ)

Thread 1: EXC_BREAKPOINT (code=1, subcode=0x19744d754)

Xcode 콘솔에는 별다른 에러 메시지도 없이 그냥 트랩이 떨어집니다. 처음엔 "내가 뭘 잘못 입력했나?" 싶었는데 같은 코드가 다른 기기에선 멀쩡히 동작했어요. 재현은 100%였는데 디버거 멈추는 위치가 매번 달랐습니다.

코드 — 처음의 단순한 구조

struct CategoryListView: View {
    @State private var viewModel = CategoryListViewModel()

    var body: some View {
        List {
            ForEach(viewModel.categories) { category in
                CategoryRowView(category: category)
                    .swipeActions {
                        Button("삭제", role: .destructive) {
                            viewModel.delete(category)
                        }
                    }
            }
        }
    }
}

struct CategoryRowView: View {
    @ObservedObject var category: Category  // NSManagedObject

    var body: some View {
        Label(category.name, systemImage: category.iconName)
    }
}

CoreData 모델은 평범한 NSManagedObject 서브클래스입니다:

@objc(Category)
public class Category: NSManagedObject {}

extension Category {
    @NSManaged public var id: UUID           // ← non-optional!
    @NSManaged public var name: String       // ← non-optional!
    @NSManaged public var iconName: String   // ← non-optional!
    @NSManaged public var colorHex: String   // ← non-optional!
}

원인 찾기

EXC_BREAKPOINT subcode가 라이브러리 주소처럼 보여서 처음엔 외부 라이브러리 문제인 줄 알았는데, 외부 의존성이 없는 프로젝트라 그럴 리가 없었어요.

가설 1: @ObservedObject var category: Category가 KVO로 객체 변경을 감지하는데, 객체가 삭제되는 순간 KVO 발화 → SwiftUI 리렌더 → 삭제된 객체의 프로퍼티 접근 → 크래시?

이 가설을 확인하려면 KVO와 KVC가 무엇인지부터 짚어야 합니다.

KVO와 KVC — 왜 NSManagedObject에서 중요한가

• KVC (Key-Value Coding): 객체의 프로퍼티를 문자열 키로 동적 접근하는 메커니즘. [obj valueForKey:@"name"] 같은 Obj-C 코드가 그것.
• KVO (Key-Value Observing): 그 키 경로의 값이 바뀌면 알려주는 옵저버 메커니즘.

CoreData의 @NSManaged 프로퍼티는 컴파일 타임이 아니라 런타임에 KVC를 통해 값을 읽고 씁니다. 즉:

let name = category.name  // 컴파일러가 보기엔 일반 프로퍼티 접근
// ↓ 실제로는
[category valueForKey:@"name"]  // KVC 호출 → CoreData가 store에서 값 조회

그리고 SwiftUI의 @ObservedObject는 ObservableObject의 objectWillChange 퍼블리셔를 구독합니다. NSManagedObject는 iOS 14+에서 ObservableObject를 자동 채택하고, KVO 알림을 받으면 objectWillChange.send()를 호출합니다.

그래서 카테고리가 삭제되면 일어나는 일:

1. viewModel.delete(category) → 내부에서 context.delete(category) + save()
2. CoreData가 category를 deleted 상태로 마킹 (isDeleted = true)
3. 관계나 속성이 변경되며 KVO 알림 발화
4. @ObservedObject가 알림 수신 → SwiftUI에게 "이 뷰 다시 그려"
5. viewModel.categories 배열은 아직 갱신 전(NSFetchedResultsController.controllerDidChangeContent가 아직 호출 안 됨)
6. SwiftUI가 deleted Category로 body를 한 번 더 평가
7. category.name 접근 → KVC 호출 → deleted 객체라 nil 반환
8. Swift는 name을 String(non-optional)으로 선언했으므로 nil을 받을 수 없음
9. 런타임이 "non-optional에 nil 강제 캐스팅 시도"를 감지 → 트랩 → EXC_BREAKPOINT

여기서 핵심은 @NSManaged var name: String이 non-optional이라는 것입니다. 만약 String?이었다면 nil을 받아도 크래시 안 났을 거예요. CoreData 코드젠이 모델의 "Optional" 체크박스를 기준으로 옵셔널 여부를 결정하는데, 기본값이 non-optional로 되기 쉽습니다.

가설 2 — ForEach의 identity

위 가설로 뷰 본문에 가드를 추가했습니다:

struct CategoryRowView: View {
    @ObservedObject var category: Category

    var body: some View {
        if category.isDeleted || category.managedObjectContext == nil {
            EmptyView()
        } else {
            Label(category.name, systemImage: category.iconName)
        }
    }
}

isDeleted는 NSManagedObject의 자체 프로퍼티라 deleted 상태에서도 안전합니다. 이 가드면 끝일 줄 알았는데…

여전히 크래시.

깊이 보니 또 다른 경로가 있었습니다. ForEach가 배열 diffing을 할 때 각 원소의 Identifiable.id를 평가합니다. Category는 이렇게 Identifiable에 conform되어 있었어요:

extension Category: Identifiable {
    // id는 @NSManaged var id: UUID 를 자동 사용
}

배열이 갱신되는 순간(viewModel.categories = newCategories) ForEach는 옛 배열과 새 배열의 id를 비교합니다. 그런데 옛 배열에는 deleted Category가 들어있고, 그 객체의 id(@NSManaged UUID)를 KVC로 읽으면 nil → 트랩.

이 크래시는 row의 body가 호출되기 전, ForEach 내부 diffing 단계에서 일어납니다. 그래서 body 가드가 닿지 못합니다.

해결책 — 두 장치를 동시에

1. ForEach의 identity를 objectID로 우회: NSManagedObjectID는 객체의 라이프사이클과 무관하게 항상 유효합니다 (메모리에서 사라질 때까지).
2. body 진입 가드 유지: KVO race로 인한 row 리렌더 시 안전망 역할.

struct CategoryListView: View {
    @State private var viewModel = CategoryListViewModel()

    var body: some View {
        List {
            // ✅ id: \.objectID 로 변경
            ForEach(viewModel.categories, id: \.objectID) { category in
                CategoryRowView(category: category)
                    .swipeActions {
                        Button("삭제", role: .destructive) {
                            viewModel.delete(category)
                        }
                    }
            }
        }
    }
}

struct CategoryRowView: View {
    @ObservedObject var category: Category

    var body: some View {
        // ✅ body 진입에서 deleted 상태 차단
        if category.isDeleted || category.managedObjectContext == nil {
            EmptyView()
        } else {
            Label(category.name, systemImage: category.iconName)
        }
    }
}

이 두 장치를 적용한 뒤로는 크래시가 단 한 번도 나지 않았습니다! 🎊

배운 점

• NSManagedObject는 일반 Swift 객체가 아닙니다. @NSManaged 프로퍼티는 KVC를 통해 동적으로 읽고 쓰므로, deleted 상태에서 접근하면 위험합니다.
• SwiftUI + CoreData는 라이프사이클 경계가 미묘합니다. @ObservedObject는 KVO를 구독하기 때문에 deleted 객체가 잠깐 뷰에 다시 들어올 수 있습니다.
• ForEach의 identity로 objectID를 쓰세요. Identifiable.id(@NSManaged UUID)는 객체 라이프사이클에 묶이지만, objectID는 항상 안전합니다.
• 모델의 String/UUID 프로퍼티를 Optional로 두는 것도 한 방법입니다. 다만 이미 짜인 코드를 전부 옵셔널로 바꾸는 건 큰 작업이라 이번 PR에서는 가드 전략으로 마무리했습니다.

💡 더 근본적인 해법: 모델의 name/colorHex 등을 Optional로 선언하고 wrappedName 같은 안전 언래핑 계산 프로퍼티로 노출하는 패턴. CLAUDE.md 가이드처럼 컨벤션을 미리 정해두면 같은 함정을 반복하지 않을 수 있습니다.

---

트러블슈팅 2 — 위젯과 메인 앱의 데이터를 공유하기

홈 화면 위젯을 추가하려고 보니 위젯에서 메인 앱의 CoreData를 직접 못 읽었습니다.

처음 시도 — 그냥 메인 앱과 똑같이

// SoDoItWidget 타깃의 Provider 안에서
let context = CoreDataManager.shared.viewContext
let request = TodoItem.fetchRequest()
let todos = try context.fetch(request)
// ❌ 컴파일은 되지만 실행하면 빈 결과
//    혹은 다른 sqlite 파일을 보고 있음

위젯에서 fetchedObjects가 항상 0개로 나왔습니다. 메인 앱에는 분명 할 일이 있는데도요...

원인

위젯 Extension은 메인 앱과 분리된 별개의 프로세스입니다. 같은 코드를 빌드해서 같은 클래스를 호출해도, 실제 동작하는 컨텍스트는 다릅니다:

• 메인 앱: App.app/Library/Application Support/SoDoIt.sqlite 같은 경로에 데이터 저장
• 위젯 Extension: 자기만의 sandbox에 별도의 sqlite를 만듦
• 둘은 서로의 파일 시스템에 접근 불가

CoreDataManager.shared는 각 프로세스에서 따로 인스턴스가 생성되며, 서로 다른 sqlite 파일을 봅니다.

해결책 — App Group + 공유 UserDefaults

Apple이 제공하는 정식 해법은 App Group입니다. 두 타깃을 같은 App Group에 묶으면 그 그룹용 공유 컨테이너에 접근할 수 있습니다.

1단계: Xcode에서 App Group 활성화

메인 앱 + 위젯 Extension 두 타깃 모두에 group.sso.SoDoIt 같은 그룹 ID 추가. Entitlements 파일에 자동으로 들어갑니다.

2단계: 위젯용 데이터 모델 정의 (Codable)

CoreData NSManagedObject는 직렬화·역직렬화에 적합하지 않으니, 위젯 전용 가벼운 struct를 만들었습니다.

struct WidgetTodoItem: Identifiable, Codable {
    let id: UUID
    let title: String
    let priority: Int16
    let dueDate: Date?
    let categoryName: String?
    let categoryColorHex: String?
}

3단계: 메인 앱에서 쓰기

enum AppGroup {
    static let identifier = "group.sso.SoDoIt"
    static let sharedDefaults = UserDefaults(suiteName: identifier)
    static let todosKey = "widget.todos"
}

final class WidgetDataManager {
    static let shared = WidgetDataManager()

    func updateWidgetData() {
        let context = CoreDataManager.shared.viewContext
        let request = TodoItem.fetchRequest()
        // 위젯에 보여줄 적당량만 (오늘 / 다가오는 마감일 위주)
        request.fetchLimit = 5

        do {
            let todos = try context.fetch(request)
            let snapshot = todos.map { todo in
                WidgetTodoItem(
                    id: todo.id,
                    title: todo.title,
                    priority: todo.priority,
                    dueDate: todo.dueDate,
                    categoryName: todo.category?.name,
                    categoryColorHex: todo.category?.colorHex
                )
            }
            let data = try JSONEncoder().encode(snapshot)
            AppGroup.sharedDefaults?.set(data, forKey: AppGroup.todosKey)

            // 위젯에게 "지금 새 데이터 있어, 즉시 갱신해" 신호
            WidgetCenter.shared.reloadTimelines(ofKind: "TodoListWidget")
        } catch {
            print("위젯 데이터 갱신 실패: \(error)")
        }
    }
}

CRUD 직후마다 WidgetDataManager.shared.updateWidgetData()를 호출했습니다.

4단계: 위젯에서 읽기

struct TodoWidgetProvider: TimelineProvider {
    func getSnapshot(in context: Context,
                     completion: @escaping (TodoWidgetEntry) -> Void) {
        let todos = loadTodos()
        completion(TodoWidgetEntry(date: Date(), todos: todos))
    }

    func getTimeline(in context: Context,
                     completion: @escaping (Timeline<TodoWidgetEntry>) -> Void) {
        let todos = loadTodos()
        let entry = TodoWidgetEntry(date: Date(), todos: todos)
        // 30분마다 자체 갱신 (앱이 꺼져 있어도)
        let next = Date().addingTimeInterval(60 * 30)
        completion(Timeline(entries: [entry], policy: .after(next)))
    }

    private func loadTodos() -> [WidgetTodoItem] {
        guard let data = AppGroup.sharedDefaults?.data(forKey: AppGroup.todosKey)
        else { return [] }
        return (try? JSONDecoder().decode([WidgetTodoItem].self, from: data)) ?? []
    }
}

결과와 배운 점

• 변경 즉시 위젯 반영: WidgetCenter.reloadTimelines가 트리거되면 위젯이 거의 실시간으로 갱신됩니다.
• 앱 미실행 상태에서도 30분마다 자체 갱신: TimelineProvider의 policy를 .after(next)로 두면 시스템이 알아서 깨워줍니다.
• 결합도 분리: 위젯이 메인 앱의 CoreData 스키마에 직접 의존하지 않게 됩니다. 향후 모델이 바뀌어도 WidgetTodoItem 변환 단계에서 흡수 가능.
• 위젯은 별개의 프로세스라는 사실을 늘 기억하세요. 메인 앱의 singleton, 인메모리 캐시, 의존성 주입 컨테이너 — 어느 것도 위젯 프로세스에는 안 보입니다.

💡 더 무거운 데이터를 공유한다면 NSPersistentContainer의 store URL을 App Group 컨테이너 경로로 설정해 CoreData 자체를 공유하는 방식도 있습니다. 다만 동시 쓰기 동기화가 까다로워서, 위젯용 가벼운 snapshot 패턴이 더 안전한 선택이라고 봅니다.

---

트러블슈팅 3 — Color(hex:)의 함정: Swift 연산자 우선순위

카테고리에 색상을 입히려고 hex string → SwiftUI Color 변환 함수를 만들었는데, 카테고리들이 죄다 비슷한 톤으로 보였습니다. 빨강은 검은빛 도는 회녹색, 파랑은 핑크빛 마젠타로 렌더링되는 식이었어요.

처음 코드

extension Color {
    init?(hex: String) {
        var hexString = hex.trimmingCharacters(in: .whitespacesAndNewlines)
        if hexString.hasPrefix("#") { hexString.removeFirst() }

        guard hexString.count == 6,
              let hexNumber = UInt64(hexString, radix: 16) else {
            return nil
        }

        let r = Double(hexNumber & 0xFF0000 >> 16) / 255.0  // ⚠️
        let g = Double((hexNumber & 0x00FF00) >> 8) / 255.0
        let b = Double(hexNumber & 0x0000FF) / 255.0

        self.init(red: r, green: g, blue: b)
    }
}

언뜻 보면 멀쩡합니다. 빨강 채널은 0xFF0000으로 마스킹하고 16비트 오른쪽 시프트, 녹색은 8비트 시프트, 파랑은 그대로. 교과서적이죠.

원인 — Swift 연산자 우선순위

문제는 빨강 라인의 괄호입니다. Swift에서:

• >> (BitwiseShiftPrecedence): 우선순위 높음
• & (MultiplicationPrecedence): 우선순위 낮음

그래서 hexNumber & 0xFF0000 >> 16은 다음과 같이 평가됩니다:

hexNumber & (0xFF0000 >> 16)
= hexNumber & 0xFF   // ← 파랑 바이트를 추출!

즉 빨강 채널이 파랑 바이트의 값을 갖게 됩니다. 결과적으로 모든 색상이 R == B인 변종으로 렌더링되어 색상환의 다양성이 사라집니다.

예를 들어 시스템 빨강 #FF3B30을 통과시키면:

• r = 0x30 / 255 = 0.188 (파랑 바이트!)
• g = 0x3B / 255 = 0.231
• b = 0x30 / 255 = 0.188

→ 우중충한 다크 그레이가 됩니다. 빨강이 아니죠.

녹색·파랑 라인이 멀쩡한 이유는 둘 다 명시적 괄호 (hexNumber & 0x00FF00) >> 8 형태로 되어 있어서입니다. 빨강 라인만 괄호가 빠진 게 함정이었어요.

수정

괄호 하나 추가하면 끝납니다. (허무하지만 시원했어요....!!ㅎㅎ)

extension Color {
    init?(hex: String) {
        var hexString = hex.trimmingCharacters(in: .whitespacesAndNewlines)
        if hexString.hasPrefix("#") { hexString.removeFirst() }

        guard hexString.count == 6,
              let hexNumber = UInt64(hexString, radix: 16) else {
            return nil
        }

        let r = Double((hexNumber & 0xFF0000) >> 16) / 255.0  // ✅
        let g = Double((hexNumber & 0x00FF00) >> 8) / 255.0
        let b = Double(hexNumber & 0x0000FF) / 255.0

        self.init(red: r, green: g, blue: b)
    }
}

배운 점

• 비트 연산은 항상 괄호를 넉넉히 사용하기. 연산자 우선순위를 외우는 것보다 안전합니다.
• 버그는 "10개 색상이 다 비슷하다"는 시각적 단서로 시작했습니다. 사용자 입장의 단서 → 코드의 가설 → 한 줄 수정. 이 과정을 거치면 실력이 늡니다.
• 유닛 테스트로 색상 변환을 검증하기. 5분이면 작성할 수 있고, 다시 같은 오류에 안 빠질 수 있습니다.

func test_Color_hexParsing() {
    let red = Color(hex: "#FF3B30")
    XCTAssertNotNil(red)
    // UIColor로 변환해서 r, g, b 채널을 직접 검증
    // ...
}

---

회고 — v2에서 바꾸고 싶은 것들

1. NSManagedObject의 String/UUID 프로퍼티를 Optional로

이번 PR에선 가드 두 장치로 막았지만, 근본적으로 name: String? + wrappedName: String 패턴이 더 안전합니다. CLAUDE.md 가이드에도 명시되어 있는데 정작 모델에 적용을 안 했어요. v2 마이그레이션 시점에 같이 처리할 예정.

2. CoreData 마이그레이션 시뮬레이션

App Store에 출시한 후 모델을 바꾸면 사용자 데이터가 날아갈 수 있습니다. 라이트웨이트 마이그레이션이 자동으로 동작하긴 하지만, 출시 전에 의도적으로 마이그레이션을 한번 돌려보는 검증 단계를 두는 게 좋겠다는 생각.

3. 위젯 데이터를 CoreData 공유로 전환?

지금은 JSON 직렬화 방식인데, 데이터가 커지면 비효율적입니다. NSPersistentContainer의 store URL을 App Group 컨테이너로 설정해 CoreData 자체를 공유하는 방식도 검토해볼 만합니다. 다만 동시 쓰기 동기화가 까다로워서 신중히.

4. Snapshot 테스트

UI 회귀를 잡으려면 스냅샷 테스트가 필수인데 이번 출시엔 못 넣었습니다. point-free의 swift-snapshot-testing을 다음 버전에 추가할 계획.

---

마치며

가장 크게 배운 건 "신호를 의심하는 법"이었습니다.

처음에는 EXC_BREAKPOINT를 보면 "어딘가 코드가 잘못됐겠지" 정도로 막연하게 봤어요. 그런데 그 신호 뒤엔 KVO·KVC·NSManagedObject 라이프사이클·SwiftUI 트랜잭션 같은 여러 레이어의 상호작용이 있었습니다. 신입은 그 레이어 모두를 깊이 알 수 없지만, "이 함정은 X와 Y의 경계에서 일어났겠구나" 라는 감각만 길러도 같은 류의 문제는 빠르게 해결할 수 있더라고요.

투두 앱은 흔하지만, 혼자서 처음부터 끝까지 만들고 App Store까지 올린 경험은 흔하지 않습니다. 신입 개발자라면 한 번쯤 자기 이름이 박힌 앱을 출시해보길 강력 추천합니다. 튜토리얼만으로는 절대 배울 수 없는 게 너무 많아요.

레포 및 출시 정보

• App Store: 검색 "쏘두잇"
• GitHub: haansohee/SoDoIt
• 개인정보 처리방침 / 지원 페이지: haansohee.github.io/SoDoIt