개발을개발로할태니

왜 UI 처리는 MainThread 에서 처리하는가?

태애니 — Wed, 20 Aug 2025 11:13:02 +0900

나는 이 질문에 대해서 딱히 생각해본적이 없었다..!

마치 그냥 밥 먹으면 이닦아야징 하는 것처럼 + 엄마가 자꾸 밥 먹으면 이닦으라 하듯이 알아서 XCode 에서 알려주니까(으휴ㅠ 으휴!)

공부하는 내용을 공유하는 시간이 있었는데, 이때 받은 질문 덕분에 어? 그러네.. 왜 밥 먹고 이 닦는 거지? 라는 생각이 그제야 든 것이다.

나는 생각해보다가
GUI 처리 - 렌더링이 필요하다 + 애니메이션도 있지... + GPU를 처리해야한다 이런 생각에
UI 처리 자체가 너무 무거워서..? 라고 생각했다.

아닌데요!!

완전 정반대였다.

UI 처리라는 것 자체는 무거운 처리가 아니다.
내가 생각하는 렌더링, 애니메이션 처리는 다른 곳에서 하고 있다.
Render Server라는 별도의 프로세스에서 처리된다는 것..

좀 더 정리를 해보자면..

화면에 어떤 UI가 진행될 때 이런 순서로 진행된다.

1. Main Thread: 작업 준비

메인 스레드는 UI 이벤트 처리, 레이아웃 계산, 그리고 레이어 트리(Layer Tree)를 업데이트함.

Layer Tree 업데이트: UIView의 frame, bounds, backgroundColor 같은 속성을 변경하면, 이 변경 사항들이 해당 뷰의 백킹 레이어인 CALayer에 반영됨.
Commit Transaction: 개발자가 애니메이션을 설정하거나 레이어의 속성을 변경하면, Core Animation은 이러한 변경 사항들을 트랜잭션으로 묶어준다. 이 트랜잭션이 렌더 서버로 전송되고, 이 과정을 커밋(commit) 이라고 한다. 보통 메인 스레드의 RunLoop 주기에 맞춰 자동으로 발생한다.

2. Render Server: 렌더링 지시

Render Server는 iOS 시스템의 중요한 부분으로, 앱과는 완전히 분리된 별도의 프로세스.

트랜잭션 수신: 렌더 서버는 앱의 메인 스레드로부터 커밋된 레이어 트리를 수신한다.
GPU 명령 변환: 렌더 서버는 수신한 레이어 데이터를 바탕으로 GPU가 이해할 수 있는 GPU 명령어(GPU Commands)를 생성해준다. 예를 들어, backgroundColor 속성은 GPU의 clear 명령으로, transform은 matrix multiplication 명령으로 변환된다.
GPU 전달: 이렇게 생성된 명령어는 Metal(또는 OpenGL ES)과 같은 그래픽 API를 통해 GPU로 전달.

3. GPU: 최종 렌더링

GPU는 렌더 서버가 넘겨준 명령어를 받아서 실제 렌더링 작업을 수행해준다.

레이어 렌더링: GPU는 각 CALayer를 개별적으로 렌더링해준다. bounds, backgroundColor, contents 같은 속성이 여기서 처리된다.
합성(Compositing): 렌더링된 각 레이어는 GPU의 하드웨어 합성기(hardware compositor)를 이용해 최종 이미지로 합쳐진다. 이 과정에서 transform, opacity, shadow 같은 속성이 적용된다.
화면 표시: 최종적으로 합성된 이미지는 화면의 프레임 버퍼에 쓰여지고, 디스플레이의 수직 동기화(V-Sync) 주기에 맞춰 화면에 보여준다.

결론적으로!!! UI 라는 것은 이런 것을 말한다
- UILabel에 텍스트 바꾸기 → 그냥 속성 값 세팅 정도
- 버튼 색상 바꾸기 → 속성 플래그만 변경
- “다음 프레임에 이 뷰 다시 그려야겠다~” 표시만 해두는 수준이 바로 UI 처리이고,

내가 생각 했던 실제 무거운 일(렌더링, 픽셀 그리기, GPU 처리)은 Core Animation이나 RenderThread가 뒤에서 하고 있었다.

그러고보니 MainThread 라는 말도 자주 쓰면서 정확한 정의를 몰랐다.

MainThread(메인 스레드)란?

MainThread는 앱에서 UI 이벤트와 화면 업데이트를 처리하는 주 스레드.
iOS, macOS, Android 등 대부분의 UI 프레임워크는 UI 관련 작업은 메인 스레드에서만 안전하게 수행할 수 있도록 설계되어 있다.

그러니까!! 제일 중요하고, 제일 무겁고 중요한 처리를 하는 곳이 아니라
애플리케이션에서 UI 이벤트 처리와 화면 업데이트를 담당 하고 있던 것.

역할
1. 사용자 입력 이벤트 처리 (터치, 제스처, 키 입력 등)
2. UI 요소(View, Label, Button 등) 속성 변경과 화면 갱신
3. RunLoop를 통해 이벤트, 타이머, UI 렌더링 스케줄 관리
특징
- UI 작업은 MainThread에서만 안전하게 수행 가능 (UIKit / SwiftUI / Android View 모두)
- MainThread에서 무거운 작업을 실행하면 앱 UI가 멈추거나 버벅임 발생
- 백그라운드 연산은 별도의 스레드에서 처리하고, 결과만 MainThread로 전달

~~엄마가...이 닦으라고...늘 알려줬었지요....~~

DispatchQueue.main.async {
    self.label.text = "바ㅏㅏ꾸자"
}

@MainActor
func updateUI() {
    label.text = "변경될 값"
}

Task {
    await updateUI()
}

그럼 RunLoop 는 뭐지?
- RunLoop는 스레드 내부에서 이벤트를 처리하고 스레드의 생명주기를 유지하는 구조체
- MainThread는 앱 시작 시 자동으로 생성되는 RunLoop를 갖고 있는 thread.

Input Source 처리 (터치, 키 입력, 네트워크 이벤트 등)
Timer 처리
Deferred work 처리 (performSelector, DispatchQueue.main.async 작업)
UI 렌더링 요청 처리 (setNeedsDisplay, layout 업데이트)

RunLoop는

Modes: NSDefaultRunLoopMode, UITrackingRunLoopMode, NSRunLoopCommonModes
Mode에 따라 이벤트 큐가 다르게 처리되어, 스크롤 중 UI 업데이트, 타이머 등 충돌 방지한다.
RunLoop가 없으면 MainThread는 이벤트를 처리할 수 없고, 앱이 멈추게 되는 것이다.

RunLoop 관찰하려면??

개발자용: Instruments → Main Thread Activity 확인
UI가 버벅이면 MainThread가 블로킹 상태인지 확인 가능

[Apple Developer Academy @ POSTECH] 챌린지1 회고 - 질문하는 법

태애니 — Mon, 4 Aug 2025 22:40:06 +0900

챌린지 내용이 상세히 보이는 건 다 숨겼어요.

자세한 챌린지 과정은 적지 않았습니다.

https://education.apple.com

Education Community - Apple Education Community

Join the professional learning hub for educators using Apple technology. Learn new skills and connect with others for collaboration and inspiration.

education.apple.com

Challenged Based Learning,

한국에서 경험하기 어려운 이 교육 방식은 계속해서 의문점을 던지며 사고하게 한다.

"당신은 개발을 잘하는가?" 라는 질문을 들었을 때

당당히 "네" 라고 말할 수 있는 사람들이 마냥 부러웠다.

과거의 나는 개발을 잘하는 수많은 사람들과 나를 비교하며 스스로 주눅들곤 했다.

나에게 Question은 그런 존재였다.

나를 무너지게 하거나, 어거지로 일으켜서 달리게 하거나.

차리라 질문말고 그냥 뭔가를 시켜. 어떻게든 할테니까.

질문하는 사고방식이 꽉꽉 막혀있었던 나는 처음 CBL을 경험했던 파운데이션 세션에서 과정을 따라가지 못하고 왜 자꾸 물음표를 다는 거지? 하며 혼란스러워했다.

이상해.

첫날 세션을 하고 물음표 폭탄을 맞은 나는 머리가 터질 듯한 경험을 했었다.

그렇게 Foundation Program 을 마치고도 다시 내가 Developer Academy 로 찾아간건

아직 스스로에 대한 질문에 답을 하지 못해서가 아니였을까.

그리고, 좌절이 아니라 다시 Question 을 해볼 수 있는 힘이 생겨서가 아닐까?

"개발을 잘 한다는 것은, 어떤 것을 말하는 걸까요?"

개명 완ㅎ_ㅎ

Apple Developer Academy - Challenge 01

챌린지1은 CBL 자체를 경험하고 배울 수 있는 기간이였다.

랜덤으로 만들어진 팀은 운이 좋게 분위기가 참 좋았다.

모두 열정이 넘치고, 많은 발산을 통해 아이디어가 모여졌다.

그래서 더 열심히 했던 것 같다. 팀원들의 에너지가 나를 더 몰입하게 해줬다.

앱을 만들어도 되나, 만들지 않아도 된다는 조건이 주어졌고

우리 팀은 ‘어차피 나중에 주구장창 앱을 만들건데, Non-App으로 가자’로 의견이 모여졌다.

‘서로 돌보고 지지하는 아카데미를 만들자!’ 라는 Challenge 아래에서

수많은 팀에서 각양각색의 방법들이 나왔는데,

우리 팀은 ‘실패를 유쾌하게 받아들이는 아카데미를 만들자’ 로 수렴하고 다시 발산하는 과정을 거치게 됐다.

이 챌린지를 시작하면서, 정말 많은 사람들과 인터뷰를 했고

그들이 생각하는 ‘실패’는 정말 각양각색이라는 걸 알게 됐다.

나에게 ‘실패’는 어떤 것이였나.

나는 실패를 유쾌하게 받아들이지 못하는 사람이였다.

특히 내가 중요하다고 생각하는 것들에게는 더더욱 그랬다.

오히려 관심이 없거나 흥미가 없어서 실패해도 상관 없을 일에 도전했을 때 좋은 성과가 나타나는 일이 꽤 많았고

너무 많은 고민과 정성을 쏟았다 해서 그것들이 좋은 결과로 남겨지는 경우가 많지 않았다.

고민과, 불안은 질문이 아니다.

하지만 나는 매번 이렇게 물음표를 붙여왔다.

잘 할 수 있을까?

이 선택이 맞을까?

라는 수없는 생각 속에서 좋은 답을 찾은 적이 별로 없었다.

왜냐? 모두 의심을 기반으로 하는 생각에 물음표만 붙은 것들이다.

두려움과 불안만이 가득한 채로 누군가에게 긍정적인 답변이 듣고 싶어서 만들어낸 문장들일 뿐이다. ~~답정너~~

나를 앞으로 나아갈 수 없게 한다.

두렵게 만들고, 불안하게 만든다.

도전 조차 할 수 없게 만든다.

실패조차 할 수 없게 만드는 질문인 것이다.

다시 질문을 만들어보자.

이것을 잘 하기 위해서 내가 당장 해볼 수 있는 것은 무엇이지?

이 선택으로 인해서 내가 얻을 수 있는게 무엇일까?

정말 온전한 나의 GQ, 그리고 나를 움직이게 할 수 있는 질문들.

이번 챌린지를 하면서 나는 ‘실패’도 결국 도전의 결과물이고,

그것은 내가 다음번에 실패 하지 않고 도전하는 법 중 하나를 배우는 것이라는 걸 알았다.

나는 요즘도 '오실완~!'을 외치고 다닌다.

오늘 실패를 했다는 건, 나는 오늘 무언가를 도전했다는 뜻이니까.

~~오늘도 회식해서 지갑 아끼기 실패ㅎ~~

[watchOS] 애플워치 개발자 모드 설정 뜨게 하는 방법

태애니 — Sun, 13 Jul 2025 09:02:36 +0900

이걸로 한번에 된 분들이 계신다면 정말 축하드립니다!!

아주 쉬운 수순은 이 방법이라고 하는데, 이 이후에

애플워치에서 설정 > 개인정보 보호 및 보안 > 개발자 모드

까지만 설정하면 바로 연결이 된다고 한다.

그 이후에는 XCode 에 이 창을 보며 기다리기만 하면 된다.

이 방법은 모두에게 적용되지 않을 것이다.

아주 쉽게 애플워치에 개발자모드가 뜨는 사람들이 있는가하면,

나처럼 고생하는 사람도 분명 있을 것 같아서 기록해본다.

기존에 이미 아이폰으로 개발자모드를 쓰고 있었다던가 하는 이유인지 아직까지 잘 모르겠다,

아무튼!!!

내 방법이 백퍼 맞는 방법이 아니니까,

혹시 돌고돌고돌고 돌다가 이 글을 보고 계신 분이라면

내 방법으로 개발자모드 뜨는게 꼭 되시길 바라면서!!!

될지어다 될지어다

일단 애플 디벨로퍼 프로그램 없으신분..?

애플 디벨로퍼 프로그램부터 가입하세요. 개발자 계정 없으면 안됩니다.

~~연 129,000원입니다.~~

https://developer.apple.com/account

로그인 - Apple

idmsa.apple.com

1. 일단 깊게 숨을 쉬고 마음의 준비를 한다. ‍

2. iOS용 프로젝트에 target 을 설정하여 watch 용 프로젝트를 하나 판다.

watchOS 앱 프로젝트 파실줄 아시죠.....? 타겟 설정해서 iOS 프로젝트에 watchOS 앱 추가해주세요.

2. 아이폰에 iOS 앱을 일단 설치해본다.

3. 아이폰에서 Watch 앱을 켜보면 이렇게 워치에서 설치할 수 있는 앱이 나온다.

여기서 설치를 시도해보시고, 안된다면 다음 단계 (전 안됐어요)

이쯤 느꼈다.

그냥 엑스코드에서 다 날리고 다시 해야겠다는 것을...

인증서 꼬여도 걍 다 삭제하고 날리는게 제일 빨랐다.

아쉬운건 정확한 원인을 찾을 수 없다는 것인데.

그냥.. 시간 허비를 더 이상하고 싶지 않아서 걍 삭제 ㄱㄱㄱㄱ 함

window > Devices and Simulators 에 가서

3-1 시작. 기존 연결했던 아이폰 디바이스를 삭제해버린다.

3. 아이폰과 맥북을 유선으로 연결한다. (페어링으로 시도 했을 때 안됐었다.)

3. 아이폰은 Devices 에 아주 쉽게 설치가 될 것이다

4. 내 경우 바로 이때!!!! 아이폰이 추가가 되면서 애플워치도 같이 떴다.(뭐지? 왜 뜬거지? 근데 뜸..)

5. 아래 이미지처럼 개발자 모드를 켜라고 안내메세지가 뜬다.

Settings 에서 Privacy & Security 에 가서 개발자모드 켜달라고 뜸

떴다!

그러고 나서 테스트 해보면

아이폰의 Watch 앱에서 설치해도 되고,

바로 WatchApp 을 XCode 에서 빌드해도 설치가 된다.

왜 됐는지 모르겠지만ㅎ

몇년 전 우당탕탕 XCode와 밀당을 해보면서

뭔가 어딘가가 꼬여서겠거니 하며

막 해봤는데 운 좋게 설치 됨...b

이 방법이 도움이 되길 바라면서...!

[HealthKit] HKObserverQueryCompletionHandler

태애니 — Fri, 11 Jul 2025 10:13:47 +0900

https://delightpip.tistory.com/390

[HealthKit] enableBackgroundDelivery

HealthKit Capabilities Entitlementcom.apple.developer.healthkit.access 앱이 포그라운드/백그라운드 상태로 실행되면, HealthKit은 해당하는 HKObserverQuery의 핸들러를 즉시 실행시킨다. 백그라운드에서도 작동하려면

delightpip.tistory.com

백그라운드 전달에 사용되는 completion handle

typealias HKObserverQueryCompletionHandler = () -> Void

이 completion handler는 백그라운드 전달에 응답할 때 호출해야 하는 클로저를 정의한다.
앱이 백그라운드 전달을 등록한 경우, HealthKit은 새로운 데이터가 저장되었을 때 앱을 깨운다(wake).

앱은 백그라운드에서 깨어난 후, HKObserverQuery에 등록된 update handler가 호출됨.
이 때, update handler는 HKObserverQueryCompletionHandler라는 블록(클로저)을 함께 전달.
이 클로저는 데이터를 처리한 후에 반드시 호출!!!

항목	설명
정의	HKObserverQueryCompletionHandler = () -> Void
사용 시점	HKObserverQuery의 update handler 내부에서
해야 할 일	데이터를 모두 처리한 후 반드시 completionHandler() 호출

호출 안 하면	HealthKit이 점점 재시도 간격 증가 → 3회 실패 시 업데이트 중단
백그라운드 처리 유지 조건	매번 completionHandler를 정확히 호출해야 함

[HealthKit] enableBackgroundDelivery

태애니 — Wed, 9 Jul 2025 23:08:56 +0900

HealthKit Capabilities Entitlement

com.apple.developer.healthkit.access

앱이 포그라운드/백그라운드 상태로 실행되면, HealthKit은 해당하는 HKObserverQuery의 핸들러를 즉시 실행시킨다.

백그라운드에서도 작동하려면, 앱 실행 시점에 observer query를 등록해야 한다.
보통 AppDelegate나 SceneDelegate의 앱 초기화 지점에서 설정해야 백그라운드 전달이 제대로 작동한다
AppDelegate의 application(_:didFinishLaunchingWithOptions:)에서 설정<<<
쿼리가 등록되어 있지 않으면, HealthKit이 데이터를 보내도 앱이 무시하니까 주의
HKObserverQuery 안에서 제공되는 completionHandler()는 반드시 호출!! 그래야만 시스템에서 응답을 확인함.
completion handler를 호출하지 않으면, HealthKit은 앱을 다시 실행시키려 시도하되, 점점 지연 간격을 늘리는 backoff 알고리즘을 사용함
앱이 3번 연속 응답에 실패하면, HealthKit은 앱이 데이터를 받을 수 없다고 간주하고 더 이상 백그라운드 업데이트를 보내지 않는다.

private func setupBackgroundDelivery() {
        let query = HKObserverQuery(sampleType: daylightType, predicate: nil) { [weak self] _, completionHandler, error in
            if let error = error {
                DispatchQueue.main.async {
                    self?.addLog(eventType: .backgroundUpdate, message: "Background delivery error: \(error.localizedDescription)")
                }
            } else {
                DispatchQueue.main.async {
                    self?.addLog(eventType: .backgroundUpdate, message: "  Real background delivery triggered - app woken by HealthKit")
                    self?.fetchCurrentDaylight(isAppLaunch: false)
                }
            }
            completionHandler()
        }
        
        backgroundDeliveryQuery = query
        healthStore.execute(query)
        
        healthStore.enableBackgroundDelivery(for: daylightType, frequency: .immediate) { [weak self] success, error in
            DispatchQueue.main.async {
                if success {
                    self?.addLog(eventType: .manualUpdate, message: "Background delivery enabled successfully")
                } else {
                    self?.addLog(eventType: .manualUpdate, message: "Failed to enable background delivery: \(error?.localizedDescription ?? "Unknown error")")
                }
            }
        }
    }

HKObserverQueryCompletionHandler 참조

https://developer.apple.com/documentation/healthkit/hkobserverquerycompletionhandler

HKObserverQueryCompletionHandler | Apple Developer Documentation

The completion handler for background deliveries.

developer.apple.com

Executing Observer Queries

https://developer.apple.com/documentation/healthkit/executing-observer-queries

Executing Observer Queries | Apple Developer Documentation

Create and run observer queries.

developer.apple.com

[Foundation/Class] NotificationCenter

태애니 — Wed, 2 Jul 2025 00:10:13 +0900

NotificationCenter 란?

객체 간 느슨한 통신(loose coupling)을 가능하게 하는 event broadcast system
다수의 객체에 이벤트 상태변화를 알리는 방송이라고 생각하면 됨
단일 프로그램 내에서만 동작 (프로세스 간 통신은 DistributedNotificationCenter 사용)

Notification 이란?

NotificationCenter가 전달하는 단일 이벤트의 데이터 단위
앱 내부의 객체 간 메시지를 전달하는 역할로, 옵저버 패턴의 일부이다.

[!NOTE] Notification과 User Notification(UNNotification)은 다른 개념임.

NotificationCenter의 내부구조

swift

class NotificationCenter {
    private var observers: [NotificationName: [WeakObserver]] = [:]
    private let lock = NSLock() // 스레드 안전성
    
    // 실제 내부 구조 (단순화)
    private struct WeakObserver {
        weak var observer: AnyObject?
        let selector: Selector?
        let block: ((Notification) -> Void)?
        let queue: OperationQueue?
    }
}

Notification vs User Notification 비교

항목NotificationUser Notification (UNNotification)

소속 프레임워크	Foundation (NotificationCenter)	UserNotifications (UNUserNotificationCenter)
주요 클래스	Notification, NotificationCenter	UNNotification, UNUserNotificationCenter
이벤트 대상	앱 내부 객체 (코드)	사용자 (시스템 알림 UI)
발생 위치	앱 내부에서 직접 post	시스템이 푸시/로컬 알림을 표시할 때
용도	코드 간 통신 (모듈 간, VC ↔ VM 등)	사용자에게 알림을 보내고 응답 처리
인터넷 필요 여부	필요없음	로컬일 경우 필요없음, 원격일 경우 필요

swift

// UserNotification을 이용해 알림을 하면서, 처리 후 내부 Notification으로 전달하는 예시
// 푸시 알림 후 앱 내부에서 이벤트를 처리하는 예시임
// 사용자가 알림을 탭했을 때 → 앱 내부에 Notification 전달
func userNotificationCenter(_: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {
    NotificationCenter.default.post(name: .didTapReminderNotification, object: nil, userInfo: response.notification.request.content.userInfo)
}

GQ1. NotificationCenter의 처리 과정

1. 관찰자 등록 (addObserver)

옵저버 객체는 특정 Notification.Name에 대해 알림을 수신하겠다고 등록

2. 알림 게시 (post)

알림 이름, 옵셔널한 발신자(sender), userInfo를 포함한 알림을 게시

3. 알림 전달

등록된 모든 observer에게 동기적으로 알림이 전달 옵저버는 등록 시 설정한 selector/closure를 통해 콜백을 받음

swift

// 셀렉터 기반 등록
NotificationCenter.default.addObserver(
    self,
    selector: #selector(handleKeyboardWillShow),
    name: UIResponder.keyboardWillShowNotification,
    object: nil
)

// 클로저 기반 등록
let observer = NotificationCenter.default.addObserver(
    forName: .customEvent,
    object: nil,
    queue: .main
) { [weak self] notification in
    self?.handleCustomEvent(notification)
}

처리 순서 상세

등록 단계: 옵저버가 특정 알림 이름에 대해 콜백 등록
발송 단계: post 메서드 호출 시 해당 알림 이름의 모든 옵저버 검색
전달 단계: 등록된 순서대로 각 옵저버의 콜백 실행 (동기적)
완료 단계: 모든 옵저버 처리 완료 후 post 메서드 반환

Observer Pattern

옵저버 패턴은 한 객체의 상태 변화를 감지 후, 다른 객체들이 자동으로 반응하도록 연결하는 패턴

어떤 일이 발생했을 때, 관심있는 객체들에게 자동으로 알려주는 구조

변화가 발생하면 자동으로 반응하게 하는 시스템
여러 객체가 한 이벤트에 대해 동시에 반응한다 (1:N)

옵저버 패턴 구현 예시

// Subject의 상태가 바뀔 때마다, 모든 Observer가 자동으로 반응함
protocol Observer {
    func update(value: Int)
}

class Subject {
    private var observers = [Observer]()
    private var value = 0

    func addObserver(_ observer: Observer) {
        observers.append(observer)
    }

    func changeValue(to newValue: Int) {
        value = newValue
        notifyObservers()
    }

    private func notifyObservers() {
        observers.forEach { $0.update(value: value) }
    }
}

NotificationCenter로 보는 옵저버 패턴

NotificationCenter 자체가 Subject
ViewController, ViewModel = Observer
Notification = Event

swift

NotificationCenter.default.addObserver(self, selector: #selector(...), name: .eventHappened, object: nil)

옵저버 패턴의 장점

느슨한 결합: 주체와 반응하는 객체가 서로 모른 채로 동작
유연성: 여러 객체가 같은 이벤트에 반응 가능 (1:N 구조)
확장성: 옵저버를 자유롭게 추가/제거 가능

옵저버 패턴의 단점

순환 참조 위험: 클로저 내부에서 self를 강하게 참조할 경우 → 해결방안 [weak self] 사용
메모리 누수 가능성: 옵저버 제거 누락 시 → deinit에서 removeObserver 호출 처리
디버깅 어려움: 이벤트 흐름 추적이 복잡 → 네이밍 전략, 구조화 필요

GQ2. NotificationCenter의 메모리 관리

중요한 수정사항

iOS 9+ 부터는 셀렉터 기반 옵저버도 자동으로 해제된다.

// iOS 9+ 에서는 자동 해제됨
NotificationCenter.default.addObserver(self, selector: #selector(handle), name: .custom, object: nil)

// deinit에서 수동 제거 불필요 (하지만 명시적으로 하는 것이 좋음)
deinit {
    NotificationCenter.default.removeObserver(self) // 권장사항
}

클로저 기반 옵저버 관리

class ViewController: UIViewController {
    private var observers: [NSObjectProtocol] = []
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // 순환 참조 위험
        let badObserver = NotificationCenter.default.addObserver(
            forName: .dataUpdate,
            object: nil,
            queue: .main
        ) { notification in
            self.handleUpdate() // strong reference cycle!
        }
        
        // 안전한 방법
        let safeObserver = NotificationCenter.default.addObserver(
            forName: .dataUpdate,
            object: nil,
            queue: .main
        ) { [weak self] notification in
            self?.handleUpdate() // weak reference
        }
        
        observers.append(safeObserver)
    }
    
    deinit {
        // 클로저 기반은 명시적 제거 필요
        observers.forEach { NotificationCenter.default.removeObserver($0) }
    }
}

메모리 관리 베스트 프랙티스

항상 [weak self] 사용: 클로저 기반 옵저버에서 순환 참조 방지
토큰 저장: 클로저 기반 옵저버의 반환 토큰을 저장하여 수동 해제 가능하게 함
명시적 해제: deinit에서 명시적으로 옵저버 제거
적절한 생명주기: 옵저버의 등록/해제 시점을 명확히 함

스레드 안전성

class ThreadSafeExample {
    func postFromBackground() {
        DispatchQueue.global().async {
            // 백그라운드에서 알림 발송 - 안전함
            NotificationCenter.default.post(name: .backgroundTask, object: nil)
        }
    }
    
    func observeWithSpecificQueue() {
        // 특정 큐에서 옵저버 실행
        NotificationCenter.default.addObserver(
            forName: .customEvent,
            object: nil,
            queue: .main // UI 업데이트용
        ) { notification in
            // 항상 메인 큐에서 실행됨
            print("현재 스레드: \(Thread.current)")
        }
        
        NotificationCenter.default.addObserver(
            forName: .heavyTask,
            object: nil,
            queue: OperationQueue() // 백그라운드 큐
        ) { notification in
            // 백그라운드에서 무거운 작업 처리
        }
    }
}

GQ3. NotificationCenter를 어떻게 관리해야 하는가?

주요 기능 + 적절한 활용 시점

1. 여러 객체가 한 이벤트에 반응할 때

// 로그인 이벤트 → 여러 화면이 동시에 업데이트
extension Notification.Name {
    static let userDidLogin = Notification.Name("userDidLogin")
}

class UserManager {
    func login(user: User) {
        authenticateUser(user)
        
        // 여러 화면에 로그인 완료 알림
        NotificationCenter.default.post(
            name: .userDidLogin,
            object: user,
            userInfo: ["loginTime": Date()]
        )
    }
}

2. 이벤트 소스를 모를 때

누가 이벤트를 발생시켰는지 확인할 필요 없이, 이벤트 발생 여부만 알면 됨

3. 시스템 이벤트 처리

// 키보드 이벤트 - 시스템에서 직접 발송
NotificationCenter.default.addObserver(
    forName: UIResponder.keyboardWillShowNotification,
    object: nil,
    queue: .main
) { [weak self] notification in
    if let keyboardFrame = notification.userInfo?[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect {
        self?.adjustUI(for: keyboardFrame.height)
    }
}

4. 깊은 뷰 계층에서의 전역 이벤트

// 5단계 깊이의 뷰 구조에서 최하단 → 최상단 통신
struct DeepNestedComponent: View {
    var body: some View {
        Button("전역 새로고침") {
            // @Binding으로 5단계 전달하기엔 너무 복잡
            NotificationCenter.default.post(name: .globalRefresh, object: nil)
        }
    }
}

언제 사용하지 말아야 하는가?

NotificationCenter 사용하지 말아야 하는 경우

단순한 1:1 통신

// 대신 protocol/delegate 사용
protocol DataSource {
    func fetchData() -> [Item]
}

2. SwiftUI에서 상태 관리

// 대신 @StateObject, @ObservableObject 사용
@StateObject var viewModel = ViewModel()

3. 직접적인 부모-자식 관계

struct ParentView: View {
    @State private var data = ""
    
    var body: some View {
        ChildView(data: $data) // 직접 전달
    }
}

실제 코드 예시

SwiftUI에서의 사용

struct ContentView: View {
    @State private var message = ""
    @State private var isKeyboardVisible = false
    
    var body: some View {
        VStack {
            Text(message)
            TextField("입력", text: .constant(""))
        }
        .padding(.bottom, isKeyboardVisible ? 250 : 0)
        .onReceive(NotificationCenter.default.publisher(for: .messageUpdate)) { notification in
            if let newMessage = notification.object as? String {
                message = newMessage
            }
        }
        .onReceive(NotificationCenter.default.publisher(for: UIResponder.keyboardWillShowNotification)) { _ in
            isKeyboardVisible = true
        }
        .onReceive(NotificationCenter.default.publisher(for: UIResponder.keyboardWillHideNotification)) { _ in
            isKeyboardVisible = false
        }
    }
}

커스텀 Notification Name 정의

extension Notification.Name {
    static let userDidLogin = Notification.Name("userDidLogin")
    static let dataDidUpdate = Notification.Name("dataDidUpdate")
    static let networkStatusChanged = Notification.Name("networkStatusChanged")
    static let messageUpdate = Notification.Name("messageUpdate")
    static let globalRefresh = Notification.Name("globalRefresh")
}

타입 안전한 NotificationCenter 래퍼

protocol TypedNotification {
    associatedtype Payload
    static var name: NSNotification.Name { get }
}

struct UserLoginNotification: TypedNotification {
    typealias Payload = User
    static let name = NSNotification.Name("user.login")
}

extension NotificationCenter {
    func post<T: TypedNotification>(_ type: T.Type, payload: T.Payload) {
        post(name: T.name, object: payload)
    }
    
    func observe<T: TypedNotification>(
        _ type: T.Type,
        queue: OperationQueue? = .main,
        handler: @escaping (T.Payload) -> Void
    ) -> NSObjectProtocol {
        return addObserver(forName: T.name, object: nil, queue: queue) { notification in
            guard let payload = notification.object as? T.Payload else { return }
            handler(payload)
        }
    }
}

// 타입 안전한 사용
NotificationCenter.default.post(UserLoginNotification.self, payload: user)
NotificationCenter.default.observe(UserLoginNotification.self) { user in
    print("사용자 로그인: \(user.name)")
}

성능 고려사항

최적화 팁

class OptimizedNotificationManager {
    // 효율적 방식 : 한 번 등록하고 조건부 처리
    func setupOptimizedObserver() {
        NotificationCenter.default.addObserver(
            forName: .frequentEvent,
            object: nil,
            queue: nil
        ) { [weak self] notification in
            guard let self = self,
                  self.shouldHandle(notification) else { return }
            self.handleNotification(notification)
        }
    }
    
    // 비효율적: 자주 등록/해제
    func inefficientPattern() {
        let observer = NotificationCenter.default.addObserver(/*...*/)
        // 짧은 시간 후
        NotificationCenter.default.removeObserver(observer)
    }
    
    // 효율적: 필요한 데이터만 전달
    func optimizedPosting() {
        NotificationCenter.default.post(
            name: .dataUpdate,
            object: nil,
            userInfo: ["id": dataId] // 최소한의 식별자만
        )
    }
}

디버깅 도구

// 디버깅용 NotificationCenter 모니터링
class NotificationDebugger {
    static func enableGlobalMonitoring() {
        NotificationCenter.default.addObserver(
            forName: nil, // 모든 알림 감지
            object: nil,
            queue: nil
        ) { notification in
            print("   알림: \(notification.name)")
            print("   발신자: \(notification.object ?? "nil")")
            print("   정보: \(notification.userInfo ?? [:])")
            print("   스레드: \(Thread.current)")
            print("---")
        }
    }
}

// 사용법
#if DEBUG
NotificationDebugger.enableGlobalMonitoring()
#endif

블로그에 글 안쓰고 뭘 했냐면은

태애니 — Fri, 27 Jun 2025 22:41:49 +0900

사실.. 비공개 글은 쫌 있다....

뭔가.. 근데 그걸 공개 못한 이유는

그렇게 써둔 글들이 다 내 머릿속에 있는가..? 이게 공부가 맞나..?하는 회의감이 들어서였다.

진짜임ㅎㅎㅎㅎ

개발 문서는 진짜 넓다.

자고 일어나면 바뀌어 있는 것도 있다.

근데 여전히 깊게 못들어가고 겉에서 둥둥 떠있다는 느낌밖에 들지않는다.

깊은 확신이 들지 않았다.

결국 블로그에 안쓰고 메모장에 휘갈기며...

그리고 Swift 딥다이브 스터디를 하는 중인데

내가 중점적으로 보는 것은 이거다.

그래서 그 개발자는 왜 이런걸 개발했는데??

뭐가 불편해서 이렇게 개선했는데?

그러니까 여기에 무슨 철학적인 생각이 들어간건데??

CS 라기보다는 거의 진짜 무슨.. 언어처럼 생각하고 접근하고 있는데

생각보다... 이렇게 공부하니 재밌는 것 같기도 하고

근데 비유하면서 들어가다보니 이게 진짜 찰떡 비유가 맞나.. 잘못 비유한 거 아닌가 싶을 때도 있어서

좀 더 스스로 잘 판단해보려고 한다. GPT한테도 물어보고...

또 멘토링도 해보고 해야할 듯..

블로그에는 어떻게 풀어 쓸지 모르겠어서 ~_~

비공개글 좀 써둔 것도... 아마 공개는 안할 것 같고(~~진짜 일기장처럼 쓰네 지금 나..~~)

6월 30일, 내 라이프 저니 돌아보고 나서

좀더 내 시간을 효율적으로 쓰는 방법을 좀 더 정리후

블로그도 그렇게 방향을 바꿔나갈 예정..!!

더 재미있게, 깊게, 효율적이게 공부하는 법을 한번 고민해와볼게요...! 빠이!

7월에 진짜로 돌 아 오 겠 음!

한달만에 블로그 글쓰기 창 앞에 앉아서

태애니 — Fri, 27 Jun 2025 22:20:27 +0900

생각해보니 나는 꽤 초심자의 행운이 컸던 사람이다.

어릴 때부터 무언가를 금방 배우고, 꽤 잘 따라하고, 쉽게 무언가를 했다.

학교다닐 때도 그랬던 것 같고..

컴퓨터, 인터넷? 하면 쇼핑이나 할 줄 알았던 내가

9개월만에 갑자기 웹개발자로 스카웃이 됐고

그러다 또 앱개발자로 업무를 전환하며 이직이 됐고,

또 다시 스카웃제의를 받으며 웹개발자가 됐다.

나는 타고났다는 말을 되게 좋아했다.

노력을 안했는데 잘 하는 사람처럼 보이는 걸 내심 좋아했다.

그런데 나름 잘 채우고 있던 초심자의 행운은 이제 만료 된건지..

그냥... 이래저래 힘든일이 갑자기 크게 크게 생기고

정신적으로, 체력적으로, 건강 자체에 무리가 가더니 모든게 폭파됐다.

하나하나 삐걱삐걱 거리더니,

어느 순간부터는 작은 것 하나 조차 시작하기가 머뭇거려졌다.

내가 이걸 할 수 있을까?

생각에 생각에 생각만 하다가 결국 포기한다.

나는 근데 해봤자 안될 것 같아.

아니야, 그냥 이거 안할래.

그게 반복되면서 나는 또 회피했다.

"난 그거 관심 없어서 안한거야."

삐걱거리는 걸 남들한테 보여주기 싫어서 그렇게 도망가고 도망가다보니까, 진짜 더이상 도망갈 곳이 없더라.

그리고 괜시리 아닌 척하고 있는 내가 진짜.. 없어보여서...

너무 서론이 어두워서....ㅎㅎㅎㅎㅋㅋㅋ

아니 그래서 지금 하고 싶은 말은,

요즘의 내 태도다!!

저 안해봤어요! 그거는 잘 못해요! 그래서 님들은 어떻게 함? 을 되게 많이 물어보고 다닌다.

이 사람은 이런 방법을 썼다고 한다.

저 사람은 저런 방법을 썼다고 한다.

일단 따라해본다.

맞는게 아니면 오, 실패! 이러고 다시 다른 방법을 찾아본다.

더이상 전에는 어쩌구 저쩌구 안하고, 지금이라도 방법을 찾고 어떻게 하는지 캐묻는게 훨 효율적이니까!

이렇게 인정하면 다시 금방 새살이 차오르더라.

이건 진짜임.

실패를 하다보면 실패를 버티는 근육이 생긴다. 이건 진짜 맞는 것 같다. 이번 2025년에 진짜 크게 교체된 내 생각의 문장.

나는 아마 운이 좋게(좋았던 걸까 ) 실패를 잘 빗겨나가고, 또 나름 실패가 아니라고 애써 모르는척 해왔지만

당장 내 눈앞에 근육 하나 없고 종이인형 같은 나는... 알도 좀 배기고, 근육통도 생기고 애써 도망다녔지만 현실에 좀더 얻어터져야한다고 생각한다.

그와 동시에 괜찮다고 다독거리는 방법도 배워나가는 중.

너무 자신을 몰아세우지 말 것.. 그래봤자 두배로 아플 뿐.

지금 이 글을 쓰는 것도 그냥, 나중에 멘탈근육짱짱이 될 예정이라서

그 때 이 글을 보면서 하핫ㅋ 하며 웃어보려고 써본다!

더 이상 힘들었던 과거 이야기도 이제 그만 곱씹고 싶고,

다시 무너진 가치관이나 생각도 고쳐먹으면서

멋진 내가 되고 싶은 마음.

2019년 김태인은 2024년 김태인 보다 훨 멋졌네..ㅜ 몰라몰라 2025년부터 더 멋져지면 됨!

흑역사 작성 완

[문법/키워드] Computed Property / Extension

태애니 — Wed, 21 May 2025 00:39:40 +0900

1. Computed Property (계산 속성)

속성처럼 보이지만, 내부적으로 계산해서 값을 반환함.

보통 다른 속성을 기반으로 동작

get, set 블럭 사용 가능.

저장공간을 갖지 않음 (값을 "가지고 있는" 게 아니라 "계산"함)

읽기 전용도 가능, 읽기/쓰기 모두 가능.

struct 안에 있는 값을 활용하여 어떤 계산식을 통해 값을 리턴시켜줌.

struct Circle {
    var radius: Double
    
    // 계산 속성 (읽기 전용)
    var area: Double {
        return .pi * radius * radius
    }
    
    // 계산 속성 (읽기 & 쓰기)
    var diameter: Double {
        get {
            return radius * 2
        }
        set {
            radius = newValue / 2
        }
    }
}

var c = Circle(radius: 5)
print(c.area)     // 78.54...
print(c.diameter) // 10.0

c.diameter = 20
print(c.radius)   // 10.0

예시

1. 날짜 데이터를 자유롭게 포맷하고 싶어.

Date() 값만 들어오면 자동으로 yyyy년 mm월 dd일로 바꾸고 싶어.

2. 숫자가 들어오면 어떤 공식이나 계산으로 값을 받고 싶어.

3. 값을 display 용으로 보여주고 싶어. (struct 값이 바뀌지는 않지만 보여줄 때만 바꾸고 싶을 때)

2. Method (메서드)

특정 기능이나 동작을 수행하는 함수

파라미터를 받아서 연산을 수행하는 데 주로 사용

mutating 키워드를 통해 값 변경 가능 (struct, enum에서만 필요)

struct, enum에서는 내부 값을 변경할 수 없으나, mutating 을 이용해 self 값 또는 내부 속성을 바꿀 수 있다.

struct BankAccount {
    var balance: Double

    mutating func deposit(_ amount: Double) {
        balance += amount
    }

    mutating func withdraw(_ amount: Double) {
        balance -= amount
    }
    
    func isRich(threshold: Double) -> Bool {
        return balance > threshold
    }
}

var account = BankAccount(balance: 1000)
account.deposit(500)
account.withdraw(200)
print(account.balance) // 1300
print(account.isRich(threshold: 1000)) // true

3. Extension

기존 타입(내가 만든 struct/class뿐 아니라 Swift 내장 타입들까지)에 기능을 추가.

원래 코드를 수정하지 않고도 기능 추가 가능

코드 분리 및 모듈화 가능

실무에서 정말 자주 씀 (UIKit 커스터마이징, 공통 기능 분리 등)

확장 가능한 요소

method (메서드)
computed property
initializer
subscript
protocol 준수

extension String {
    var isEmail: Bool {
        return self.contains("@") && self.contains(".")
    }

    func repeated(count: Int) -> String {
        return String(repeating: self, count: count)
    }
}

let email = "test@example.com"
print(email.isEmail) // true
print("hi ".repeated(count: 3)) // hi hi hi

[문법/키워드] mutating, Associated Value (연관 값)

태애니 — Tue, 20 May 2025 23:09:14 +0900

1. mutating

mutating 키워드는 구조체(struct)나 열거형(enum)에서 인스턴스 자신의 속성을 변경하고자 할 때 사용한다.

클래스(class)는 참조 타입이라서 메서드 내에서 속성 수정이 자유롭지만,
구조체/열거형은 값 타입이라 기본적으로 메서드 내에서 속성 변경이 금지됩니다.
이를 허용하기 위해 mutating 키워드를 사용합니다.

struct Counter {
    var count = 0

    mutating func increment() {
        count += 1
    }
}

var c = Counter()
c.increment()
print(c.count) // 1

2. Associated Value (연관값)

열거형(enum) 에서 각 case에 값을 함께 저장하고 싶을 때 사용. 마치 case가 값과 함께 동작하는 것처럼 만들어줌.

enum NetworkResult {
    case success(data: String)
    case failure(errorCode: Int, message: String)
}

let result = NetworkResult.failure(errorCode: 404, message: "Not Found")

switch result {
case .success(let data):
    print("성공: \(data)")
case .failure(let code, let message):
    print("실패: \(code) - \(message)")
}

// 실패: 404 - Not Found

enum LoginState {
    case loggedOut
    case loggingIn(username: String)
    case loggedIn(userID: Int, nickname: String)
}

let state = LoginState.loggedIn(userID: 122, nickname: "taenee")

switch state {
case .loggedOut:
    print("로그아웃 상태입니다.")
case .loggingIn(let username):
    print("\(username)님 로그인 중...")
case .loggedIn(let id, let name):
    print("\(name)(\(id))님 로그인되었습니다.")
}

// taenee(122)님 로그인되었습니다.

개발을개발로할태니

왜 UI 처리는 MainThread 에서 처리하는가?

1. Main Thread: 작업 준비

2. Render Server: 렌더링 지시

3. GPU: 최종 렌더링

MainThread(메인 스레드)란?

[Apple Developer Academy @ POSTECH] 챌린지1 회고 - 질문하는 법

Apple Developer Academy - Challenge 01

[watchOS] 애플워치 개발자 모드 설정 뜨게 하는 방법

이 방법은 모두에게 적용되지 않을 것이다.

일단 애플 디벨로퍼 프로그램 없으신분..?

[HealthKit] HKObserverQueryCompletionHandler

[HealthKit] enableBackgroundDelivery

HealthKit Capabilities Entitlement

[Foundation/Class] NotificationCenter

NotificationCenter 란?

Notification 이란?

NotificationCenter의 내부구조

Notification vs User Notification 비교

GQ1. NotificationCenter의 처리 과정

1. 관찰자 등록 (addObserver)

2. 알림 게시 (post)

3. 알림 전달

처리 순서 상세

Observer Pattern

옵저버 패턴은 한 객체의 상태 변화를 감지 후, 다른 객체들이 자동으로 반응하도록 연결하는 패턴

옵저버 패턴 구현 예시

NotificationCenter로 보는 옵저버 패턴

옵저버 패턴의 장점

옵저버 패턴의 단점

GQ2. NotificationCenter의 메모리 관리

중요한 수정사항

클로저 기반 옵저버 관리

메모리 관리 베스트 프랙티스

스레드 안전성

GQ3. NotificationCenter를 어떻게 관리해야 하는가?

주요 기능 + 적절한 활용 시점

1. 여러 객체가 한 이벤트에 반응할 때

2. 이벤트 소스를 모를 때

3. 시스템 이벤트 처리

4. 깊은 뷰 계층에서의 전역 이벤트

언제 사용하지 말아야 하는가?

NotificationCenter 사용하지 말아야 하는 경우

실제 코드 예시

SwiftUI에서의 사용

커스텀 Notification Name 정의

타입 안전한 NotificationCenter 래퍼

성능 고려사항

최적화 팁

디버깅 도구

최신 기능 (iOS 15+)

AsyncSequence 활용

블로그에 글 안쓰고 뭘 했냐면은

한달만에 블로그 글쓰기 창 앞에 앉아서

[문법/키워드] Computed Property / Extension

1. Computed Property (계산 속성)

2. Method (메서드)

확장 가능한 요소

[문법/키워드] mutating, Associated Value (연관 값)

1. mutating

2. Associated Value (연관값)