MungGu Story

Swift Concurrency, Task와 GCD: QoS 우선순위 설정 사용 방법

applebuddy — Sat, 1 Nov 2025 19:42:46 +0900

iOS환경에서 비동기 작업을 관리하는 두 가지 핵심 기술이 있는데요. GCD(Grand Central Dispatch)와 Swift Concurrency의 작업단위인 Task입니다.

이들은 내부적으로 QoS(Quality of Service)라는 통일된 시스템을 사용하여 작업의 우선순위를 관리하는데요. 오늘은 이 QoS에 대해서 알아보겠습니다.

1. Task와 GCD의 우선순위 연관 관계

GCD와 Task 모두 QoS(Quality of Service)를 통해 시스템에 작업의 중요도를 알립니다. GCD의 DispatchQueue와 Swift Concurrency의 Task를 사용할때 시스템은 설정된 QoS 정보를 기반으로 스레드 풀에서 작업을 스케줄링하고, 필요한 CPU 및 리소스 할당을 결정합니다.

비동기 작업의 특징에 따라서 바로 동작해야하거나, 중요도가 후순위인 경우가 있을텐데, 이러한 작업 성격에 맞게 작업을 실행하고자 할때 사용할 수 있습니다.

기술	우선순위 설정 방식	내부 처리 원리
GCD (DispatchQueue)	qos 매개변수에 `DispatchQoS.QoSClass` (예: `.userInitiated`, `.background`)를 큐에 직접 지정합니다.	해당 QoS로 태그된 스레드에서 작업이 실행됩니다.
Task (Swift Concurrency)	`Task` 초기화 시 `priority` 매개변수로 TaskPriority (예: `.userInitiated`, `.background`)를 지정해서 사용합니다.	지정된 QoS를 기반으로 GCD의 스레드에서 작업을 실행합니다.

연관 관계: Task의 priority는 내부적으로 GCD의 QoS Class에 매핑되어 동일한 스케줄링 시스템을 사용합니다. 즉, 새로운 Task 시스템도 기존의 GCD 인프라를 활용하여 우선순위를 처리합니다.

Task, GCD DispatchQueue QoS 사용 예시

Task(priority: .medium) { // .default도 사용 가능하나, deprecated case로 .medium 으로 대체
  // do something
}

DispatchQueue.global(qos: .default).async {
  // do something
}

2. QoS (Quality of Service) Class 특징 및 사용 예시

QoS 클래스는 총 6가지가 있으며, 각각의 특징과 적절한 사용 예시는 다음과 같습니다.

QoS관련 Task 특이사항
- .userInteractive 옵션 deprecated
- .default 옵션 -> .medium 으로 rename
- .unspecified 옵션 deprecated -> 옵션 미지정 혹은 QoS 를 nil로 지정하는것을 권장합니다.
  - Task { ... } 처럼 옵션 미지정 시 기본으로 지정되는 옵션입니다. unstructured concurrency 방식으로 Task 중첩 등이 있을때 작업 취소 전파가 되지 않으니 사용에 유의해야합니다.

QoS Class	특징 및 중요도	CPU 스케줄링	사용 예시
`.userInteractive`	최고 중요도 작업에 사용합니다. 사용자가 즉각적인 반응을 기대하는 작업에 사용할 수 있는 QoS입니다.	높은 우선순위. 메인 스레드에 자주 사용됨.	애니메이션, 이벤트 처리, UI 새로고침, 사용자 입력에 대한 즉각적인 피드백.
`.userInitiated`	높은 중요도. 사용자가 결과를 즉시 기대하며, 결과를 기다리는 동안 UI가 차단될 수 있는 작업.	높은 우선순위. 사용자 인터페이스와 직접적으로 관련됨.	"저장" 버튼 클릭 후 데이터 저장, 문서 로딩, 사용자가 시작한 데이터 가져오기.
`.default`	중간 중요도. QoS가 명시적으로 지정되지 않은 대부분의 작업에 사용되는 기본값. (시스템이 적절히 조절)	`.userInitiated`와 `.utility` 사이의 우선순위를 가집니다.	우선순위를 명확히 설정하지 않을 때 사용. 대부분의 일반 비동기 작업.
`.utility`	중간/낮은 중요도. 시간이 걸릴 수 있지만 즉각적인 응답이 필요 없는 작업. 진행 표시줄 등을 제공함.	낮은 우선순위. 에너지 효율을 위해 설계됨.	긴 네트워크 요청, 데이터 다운로드, 이미지 필터링, 사용자에게 보이지 않는 백업.
`.background`	최저 중요도. 사용자에게 보이지 않으며 시간 제약이 거의 없는 작업. 리소스 경합을 피하기 위해 최저 우선순위로 실행됨.	가장 낮은 우선순위. 주로 I/O 및 유지보수 작업에 사용.	데이터베이스 정리, 로그 업로드, 사전 로드(Prefetching), 인덱싱.
`.unspecified`	시스템이 가장 적절한 QoS를 추론하도록 맡기는 경우. (주로 레거시 코드 호환성)	시스템 추론에 따름.	명확한 QoS가 필요 없거나 시스템에 맡길 때.

3. Task 및 GCD 사용 예시 코드

3-1. Task에서 QoS 사용 (iOS 13+ / Swift Concurrency)

Task를 생성할 때 priority 파라미터를 지정해서 사용합니다. priority 미지정 시, default로 .unspecified 옵션이 지정됩니다.

//   사용자에게 즉시 결과를 보여줘야 하는 중요한 작업
Task(priority: .userInitiated) {
    print("User Initiated Task: 데이터 로딩 시작")
    // 데이터를 서버에서 즉시 가져오는 비동기 함수 호출
    await loadImportantData() 
    print("User Initiated Task: 데이터 로딩 완료")
}

//   백그라운드에서 실행되어도 무방하며, 배터리 효율이 중요한 작업
Task(priority: .background) {
    print("Background Task: 로깅 및 정리 작업 시작")
    // 로그 파일 정리, 캐시 삭제 등 시간이 오래 걸려도 되는 작업
    await cleanUpLogs()
    print("Background Task: 로깅 및 정리 작업 완료")
}

3-2. GCD에서 QoS 사용 (Legacy 방식)

GCD 방식의 경우 DispatchQueue.global에 qos 파라미터를 사용하여 우선순위를 지정합니다.

// 중간 우선순위 작업 (예: 오래 걸리는 이미지 처리)
DispatchQueue.global(qos: .utility).async {
    print("Utility Queue: 이미지 프로세싱 시작")
    // ... 이미지 필터링 코드 ...

    // UI 업데이트는 thread-safe 하지 않으므로 반드시 .userInteractive (main) 큐에서 수행해야합니다.
    DispatchQueue.main.async { 
        print("Utility Queue: UI 업데이트 완료")
        // self.imageView.image = processedImage
    }
}

// 메인 스레드와 동일한 최고 우선순위 (시스템이 즉각 반응하도록 보장)
DispatchQueue.global(qos: .userInteractive).async {
    print("User Interactive Queue: 탭 이벤트 처리 시작")
    // 작은 계산을 빠르게 처리
}

요약

Task와 GCD를 사용할때 작업의 중요도에 맞는 적절한 QoS를 설정하는 것이 가장 중요합니다.
.userInteractive, .userInitiated는 꼭 필요한 곳(UI 관련)에만 사용하고, 장시간 소요되는 작업은 .utility나 .background를 사용하여 작업 중요도를 지정하고 시스템 리소스를 효율적으로 관리할 수 있습니다.

LeetCode DP 문제, House Robber Swift 알고리즘 풀이

applebuddy — Fri, 31 Oct 2025 09:17:07 +0900

문제 링크: LeetCode 198. House Robber
유형: Dynamic Programming (DP)

문제 요약

도둑이 일렬로 늘어선 집들을 털려고 합니다.
단, 인접한 두 집을 동시에 털 수는 없습니다.

각 집마다 돈의 양이 담긴 배열 nums가 주어졌을 때,
도둑이 털 수 있는 최대 금액을 반환해야합니다!

예시

Input: nums = [2,7,9,3,1]
Output: 12
// 2 + 9 + 1 = 12

접근 방법

이 문제는 전형적인 Dynamic Programming(DP) 문제입니다.
핵심은 현재 집을 털지, 건너뛸지 선택하는 것인데요. 이를 점화식으로 정리해서 해결할 수 있습니다.

점화식 정의

dp[i] = 0번째부터 i번째 집까지 털었을 때 얻을 수 있는 최대 금액입니다.

이때 점화식에 활용되는 2가지 케이스는 아래와 같아요.

i번째 집을 털지 않는다.
→ 이전까지의 최대 금액은 그대로 유지된다 → dp[i-1]
i번째 집을 턴다.
→ i-1번째는 털 수 없으므로, dp[i-2] + nums[i]

따라서 점화식은 다음과 같습니다.

dp[i] = max(dp[i-1], dp[i-2] + nums[i])

구현 코드 (Swift)

class Solution {
    /// DP 를 활용해서 문제를 해결합니다. 
    /// dp[i] = 0...i 까지의 집에서 얻을 수 있는 최댓값
    func rob(_ nums: [Int]) -> Int {
        // 1) 집이 단 한개면 그 집의 돈만 털면 됩니다.
        if nums.count == 1 {
            return nums[0]
        }

        // 2) 집이 두개면 둘 중 돈 더 많은 곳을 털면 됩니다.
        if nums.count == 2 {
            return nums.max()!
        }

        // 3) dp는 0~i번째 집까지 털었을대 얻을 수 있는 최대 금액이 들어갑니다.
        var dp = [Int](repeating: 0, count: nums.count)

        // 3-1) 0, 1번째 케이스 최댓값을 미리 넣고,
        dp[0] = nums[0]
        dp[1] = nums[...1].max()!

        // 3-2) 점화식 적용
        for i in 2..<nums.count {
            dp[i] = max(dp[i-1], nums[i] + dp[i-2])
        }

        return dp.last!
    }
}

예시 시뮬레이션

입력:

nums = [2, 7, 9, 3, 1]

i	nums[i]	dp[i] 계산식	dp[i] 값
0	2	-	2
1	7	max(2, 7)	7
2	9	max(7, 9+2=11)	11
3	3	max(11, 3+7=10)	11
4	1	max(11, 1+11=12)	12

최종 결과: 12

시간 및 공간 복잡도

구분	복잡도	설명
시간 복잡도	O(n)	모든 집을 한 번씩 탐색
공간 복잡도	O(n)	DP 배열 사용 (공간 최적화 시 O(1) 가능)

+ 공간 최적화 버전

dp[i]는 dp[i-1]과 dp[i-2]만 참조하므로,
배열 대신 두 변수로 관리할 수도 있습니다. 이렇게 되면 공간복잡도를 O(1) 상수복잡도로 처리할 수 있습니다.

func rob(_ nums: [Int]) -> Int {
    if nums.count == 1 { return nums[0] }

    var prev2 = nums[0]
    var prev1 = max(nums[0], nums[1])

    for i in 2..<nums.count {
        let current = max(prev1, prev2 + nums[i])
        prev2 = prev1
        prev1 = current
    }

    return prev1
}

✨ 마무리

이 문제는 DP의 핵심 개념을 명확하게 연습하기 좋은 대표 문제였습니다.
“현재 최적의 선택은 이전 두 상태의 최적해로부터 결정된다”는 원리를 잘 활용해야했습니다.

DP문제는 평소 풀지 않으면 점화식이 생각나더라도 풀기 어려운 경우가 있기때문에 꾸준한 연습이 필요합니다.
지금까지 릿코드의 House Robber DP swift 언어 기반 알고리즘 풀이였습니다. 감사합니다!

Swift Structured Concurrency, 비동기 작업 간 취소 전파 제어방법

applebuddy — Fri, 31 Oct 2025 00:31:10 +0900

Swift Concurrency의 핵심: Structured Concurrency로 안전한 비동기 작업 제어하기

Swift Concurrency를 활용하여 비동기 처리를 구현하고 계시다면, Structured Concurrency(구조화된 동시성) 형태로 작업을 구성하는 것이 강력하게 권장됩니다. 왜냐하면 이는 작업 간의 부모/자식 관계를 명시적으로 설정하여, 복잡한 비동기 작업을 예측 가능하고 유연하게 제어할 수 있게 하기 때문입니다.

오늘은 이 원칙의 가장 큰 장점인 '취소(Cancellation) 전파' 기능을, 중첩된 Task 작업이 있는 상황을 가정해서 코드 작성해보며 실험해보겠습니다.

playground 에서 emtpy project를 생성해서 swift concurrency 기반 코드 작성 및 테스트를 해보실 수 있습니다!

1. Unstructured Concurrency: 취소 신호가 멈추는 곳

Task { ... } 블록 내에서 새로운 Task { ... }를 생성하는 방식은 Unstructured Concurrency (비구조화된 동시성)의 대표적인 예입니다.

새로 생성된 Task는 바깥 Task의 컨텍스트(예: actor 컨텍스트)는 물려받을 수 있지만, 별도의 최상위 비동기 작업으로 간주됩니다. 이 때문에 부모 Task의 취소 신호가 자식 Task로 자동으로 전파되지 않습니다. 이 방식은 세부 비동기 작업의 생명 주기 제어가 어렵다는 명확한 단점을 가집니다.

실험 1: 취소 전파 실패 (Unstructured Task)

// outerTask와 innerTask는 별도의 최상위 비동기 작업으로 간주됩니다.
let outerTaskWithUnstructuredConcurrency = Task {
    // ⚠️ 이 innerTask는 outerTask와 독립적인 별도의 Task입니다.
    let innerTask = Task {
        for num in 1...5 {
            // Task.sleep은 취소 가능 지점입니다.
            try? await Task.sleep(for: .seconds(1))
            try Task.checkCancellation() 
            debugPrint("inner task \(num) 초 with unstructured concurrency")
        }
    }

    do {
        // innerTask의 완료를 기다립니다. (innerTask의 value를 await)
        try await innerTask.value 
    } catch is CancellationError {
        // 이 catch는 innerTask 내부의 오류가 아닌,
        // outerTask 내부에서 발생한 CancellationError만 잡습니다.
        debugPrint("inner task cancelled with unstructured concurrency") 
    }
}
// outerTask 취소 신호가 innerTask로 전달되지 않습니다.
outerTaskWithUnstructuredConcurrency.cancel()

//   출력 결과 (취소 신호를 무시하고 5초까지 완료)
// "inner task 1 초 with unstructured concurrency"
// ...
// "inner task 5 초 with unstructured concurrency"

2. Structured Concurrency: TaskGroup을 통한 안전한 제어

TaskGroup은 Swift Concurrency의 Structured Concurrency 개념 중 하나입니다. withTaskGroup이나 withThrowingTaskGroup을 사용하면 명시적인 부모-자식 관계가 형성되어, 부모 Task의 생명 주기가 자식 Task의 생명 주기와 강하게 연결됩니다.

실험 2: 취소 전파 성공 (Structured TaskGroup)

func sampleTaskGroup() async throws {
    // withThrowingTaskGroup: 이 블록 내의 모든 Task는 부모 Task의 자식이 됩니다.
    try await withThrowingTaskGroup(of: Void.self) { group in

        // group.addTask: 자식 Task를 생성하여 그룹에 추가합니다.
        group.addTask {
            for num in 1...5 {
                try await Task.sleep(for: .seconds(1))
                // 부모 Task가 취소되면 여기서 CancellationError가 발생합니다.
                try Task.checkCancellation() 
                debugPrint("inner task \(num) 초 with structured concurrency")
            }
        }

        // 부모 Task가 자식들의 완료를 기다리도록 보장합니다.
        for try await _ in group { } 
    }
}

let outerTaskWithStructuredConcurrency = Task {
    do {
        // sampleTaskGroup을 호출함으로써 부모 Task와 자식 TaskGroup 간의 관계가 형성됩니다.
        try await sampleTaskGroup() 

    } catch is CancellationError {
        // outerTask가 취소되면, sampleTaskGroup이 CancellationError를 던지고 이 곳에서 포착됩니다.
        debugPrint("inner task cancelled with structured concurrency")
    } catch {
        debugPrint("other error : \(error) with structured concurrency")
    }
}
// outerTask 취소 신호가 TaskGroup을 통해 innerTask로 전파됩니다.
outerTaskWithStructuredConcurrency.cancel()

//   출력 결과 (취소 신호 감지 후 즉시 종료)
// (1초 경과 로그 후)
// "inner task cancelled with structured concurrency"

결론 및 활용

지금까지 중첩 비동기 작업이 존재할때의 swift concurrency 사용예시를 몇가지 작성 및 실험해봤습니다. 한번 더 내용을 정리해보자면...

TaskGroup, async let, AsyncStream 등의 Structured Concurrency 도구들은 비동기 작업에 명확한 계층 구조를 부여하여 다음을 가능하게 합니다.

안전한 취소: 부모가 취소되면 관련된 모든 자식 작업이 자동으로 정리됩니다.
쉬운 에러 핸들링: 자식 Task에서 발생한 오류는 부모 Task로 명확하게 전달됩니다.

Swift Concurrency의 작업이 복잡해질 때, 단순 Task { ... } 대신 TaskGroup과 async let을 활용하는 것이 코드를 더 예측 가능하고 안정적으로 만드는 핵심 비결입니다.

iOS 개발, Cocoa Touch 개념 및 UIKit, Foundation과의 관계

applebuddy — Fri, 10 Oct 2025 01:18:02 +0900

안녕하세요, iOS 개발자 여러분~! 오늘은 iOS 앱의 근간을 이루는 핵심 계층으로, Cocoa Touch라는 개념이있는데요.
개발을 하다보면 자주 사용하게 되는 UIKit, Foundation 등의 프레임워크와도 연관이 깊습니다. 오늘은 이것들에 대해서 얘기해봐요.

Cocoa Touch: iOS 앱을 만드는 모든 것의 시작

가장 먼저, Cocoa Touch가 무엇인지부터 확실히 짚고 넘어가죠. 간단하게 말해, Cocoa Touch는 iOS 앱을 개발하는 데 필요한 대부분의 도구와 기술을 모아놓은 최상위 프레임워크, 최상위 계층입니다. 우리가 만드는 앱의 화면(UI), 사용자와의 상호작용, 데이터 관리 등 앱의 생명주기 전반을 관리하는 강력한 기반이 되는 개념입니다.

Mac OS 앱을 만들때에는 Cocoa 프레임워크를 사용하는데요. 터치 기반의 인터페이스에 맞게 변형 및 최적화 된 버전이 바로 Cocoa Touch 프레임워크입니다.

Cocoa Touch안에는 각자의 역할을 담당하는 여러 하위 프레임워크들이 유기적으로 얽혀서 동작하고 있습니다. Foundation, UIKit, MapKit 등 다양한 프레임워크들이 말이지요.

Cocoa Touch와 하위 프레임워크들의 관계

Cocoa Touch라는 개념 아래로 iOS개발에 사용되는 다양한 프레임워크들이 존재합니다. 대표적인 것들만 봐도 다음과 같습니다.

UIKit: 사용자 인터페이스(UI)를 만들고 관리하는 모든 것을 담당합니다. UIButton, UILabel, UIScrollView, UICollectionView 등... 화면에 보이는 거의 모든 요소가 UIKit에 속해있죠.
Foundation: 앱의 가장 기본적인 데이터와 서비스를 다룹니다. 문자열, 숫자, 날짜 같은 원시 데이터 타입을 관리하고, 파일 시스템, 네트워크 통신 같은 핵심 기능을 제공하죠. UI와는 직접적인 관련이 없는, 앱의 뼈대를 만드는 역할을 합니다. 예로 UIKit 내에도 Foundation을 import 하고 있습니다.
MapKit: 지도 기반 서비스를 구현할 때 사용합니다. 지도 표시, 경로 찾기, 위치 검색 등의 기능을 손쉽게 추가할 수 있게 도와줍니다.
CoreML & Vision: 머신러닝과 컴퓨터 비전 기능을 담당합니다. CPU, GPU를 적절히 활용하며 이미지 분석, 객체 탐지, 텍스트 인식 같은 고수준의 기능을 앱에 통합할 수 있게 해줍니다.

UIKit이나 MapKit 같은 프레임워크들이 사용자에게 직접 보이는 부분을 담당한다면, Foundation은 그 아래에서 묵묵히 앱의 중심을 잡아주는 역할을 합니다. CoreML이나 Vision 같은 고수준의 프레임워크들도 결국 Foundation이 제공하는 기본적인 데이터 처리 능력 위에서 동작하고 있습니다.

UIKit vs Foundation

iOS 개발자라면 import UIKit 코드를 하루에도 수십 번씩 작성할 겁니다. 그만큼 UIKit과 Foundation은 iOS 개발의 알파이자 오메가라고 할 수 있는데요. 이 둘의 관계를 명확히 이해하는 것이 매우 중요합니다.

UIKit: 앱의 UI와 밀접한 프레임워크

UIKit은 이름 그대로 User Interface Kit의 약자입니다. 앱의 화면을 구성하고 사용자와의 터치 이벤트를 처리하는 모든 책임을 집니다.

주요 개념:
- UIView & UIViewController: 화면에 보이는 모든 요소(버튼, 레이블, 이미지 뷰 등)는 UIView를 상속받습니다. 그리고 이 View들을 관리하고 생명주기를 제어하는 것이 바로 UIViewController입니다. iOS 개발의 가장 기본이 되는 MVC(Model-View-Controller) 패턴의 핵심이죠.
- UIWindow: 앱의 모든 View를 담는 최상위 컨테이너입니다. 기본적인 앱들은 최상위 window의 rootViewController를 지정해서 초기 앱을 보여줍니다.
- UIResponder: 터치, 흔들기 같은 사용자 이벤트를 받고 처리하는 객체입니다. UIView, UIViewController, UIApplication 등이 모두 UIResponder를 상속받아 이벤트 체인을 형성합니다.
- Auto Layout & Storyboard: 다양한 화면 크기에 대응하여 UI를 유연하게 배치하는 시스템(Auto Layout)과, UI를 시각적으로 디자인하고 화면 간의 전환을 설계하는 도구(Storyboard) 역시 UIKit의 중요한 개념입니다.

쉽게 말해, 사용자의 눈에 보이고 손으로 만지는 UI에 대한 기능들은 모두 UIKit과 밀접한 연관을 갖습니다.

Foundation: 앱의 뼈대 기반을 구성하는 프레임워크

Foundation은 앱의 기반, 즉 영어 뜻대로 토대(Foundation) 를 다지는 프레임워크입니다. UI와는 전혀 관련이 없는, 데이터 처리, 객체 관리, 운영체제 서비스 연동 등 앱의 핵심 로직을 담당합니다.

주요 개념:
- Value Types: String, Int, Double, Bool, Array, Dictionary 등 프로그래밍의 가장 기본이 되는 데이터 타입들을 제공합니다. (정확히는 Swift 표준 라이브러리와 긴밀하게 연결되며 실제로 String, Array등은 Objective-C 시절의 NSString, NSArray 등을 대체하고 보완합니다.)
- Reference Types (NSObject 기반): NSObject는 대부분의 Objective-C 클래스의 루트 클래스로, 객체의 생성과 소멸, 런타임 시스템과의 상호작용 등 객체 지향 프로그래밍의 근간을 이룹니다. NSDate, URLSession, FileManager 등 수많은 중요 클래스들이 NSObject를 기반으로 합니다.
- Data Persistence: UserDefaults를 이용한 간단한 데이터 저장, Codable 프로토콜을 통한 데이터 직렬화/역직렬화(JSON 파싱 등) 기능을 제공합니다.
- Concurrency: GCD(Grand Central Dispatch)와 OperationQueue를 통해 복잡한 비동기 처리와 멀티스레딩을 쉽게 구현할 수 있도록 돕습니다.

Foundation이 없다면, 우리는 데이터를 다루거나 네트워크 통신을 하는 기본적인 작업조차 매우 복잡하게 처리해야 할 겁니다. 그야말로 보이지 않는 곳에서 앱의 안정성과 성능을 책임지는 핵심 프레임워크라 할 수 있습니다.

UIKit과 Foundation 사이의 관계

UIKit.h 헤더 구성, Foundation.h를 import 하고 있습니다.

이 둘의 관계는 명확합니다. UIKit은 Foundation에 의존합니다.

import UIKit을 하면 내부적으로 import Foundation이 함께 이루어집니다. 왜냐하면 UIKit의 모든 클래스와 객체들은 결국 Foundation이 제공하는 기본적인 데이터 타입과 객체 모델 위에서 만들어지기 때문입니다.

예를 들어 볼까요?

UILabel에 텍스트를 표시하려면 Foundation의 String 데이터 타입이 필요합니다.
UIImageView에 인터넷의 url에 맞는 이미지를 띄우려면 Foundation의 URLSession으로 이미지 데이터를 다운로드해야 합니다.
사용자의 위치 정보를 MapKit 뷰에 표시하려면, 그 위치 좌표(위도, 경도)는 Foundation의 Double 타입으로 관리됩니다.

이처럼 UIKit은 Foundation이라는 튼튼한 기반 위에서 화려한 사용자 인터페이스를 그려내는 구조입니다. 개발자는 이 두 프레임워크의 역할을 명확히 이해하고, 각자의 역할에 맞는 코드를 작성해야 효율적이고 안정적인 앱을 만들 수 있습니다.

정리하며

오늘은 iOS 개발의 핵심인 Cocoa Touch와 그 생태계를 이루는 UIKit, Foundation 등의 프레임워크에 대해 알아보았습니다.

Cocoa Touch: iOS 앱 개발 환경의 최상위 프레임워크.
UIKit, MapKit, Vision, CoreML, Foundation 등: Cocoa Touch를 구성하는 하위 프레임워크들.
UIKit: 눈에 보이는 UI와 사용자 상호작용을 담당하는 프레임워크.
Foundation: 눈에 보이지 않는 데이터 처리와 핵심 로직을 담당하는 핵심 프레임워크.
UIKit과 Foundation 사이의 관계: UIKit은 Foundation이라는 기반 위에 세워져 있다.

궁금한 점이나, 의견이 있다면 언제든지 댓글 남겨주세요! 그럼 다음에도 유익한 정보로 찾아뵙겠습니다.
그럼 모두들 즐거운 코딩 하세요. 감사합니다!

iOS AppDelegate, 앱 초기설정 및 생애주기 관리 방법

applebuddy — Mon, 6 Oct 2025 01:04:34 +0900

iOS 앱 초기설정, AppDelegate 역할 및 생애주기 정리

iOS 앱의 루트 뷰 지정과 앱 딥링크 실행 외에도 핵심적으로 전반적인 생애주기를 관리할 수 있는 AppDelegate에서는 앱의 상태 변화에 따라 호출되는 다양한 메서드가 정의되어 있습니다.

iOS 13 이후 멀티 윈도우 개념이 생기면서 SceneDelegate가 추가되었지만, 그 이후에도 앱 전체 수준의 이벤트를 다루는 역할은 여전히 AppDelegate가 담당하고 있습니다.

아래 소개하는 생애주기 메서드들은 필수 구현이 아니며, 필요에 따라 선택적으로 정의해 사용할 수 있습니다. AppDelegate의 생애주기 메서드를 활용하면 앱의 원하는 시점에 맞게 다양한 동작을 수행할 수 있습니다.

willFinishLaunchingWithOptions

func application(
    _ application: UIApplication,
    willFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
) -> Bool {
    // do something
    return true
}

willFinishLaunchingWithOptions는 앱이 완전히 실행되기 직전에 호출됩니다.
이 시점은 UI가 표시되기 전 단계이기 때문에 UI 세팅보다는 초기 설정에 적합한 시점입니다.
앱의 설정값을 불러오거나, 의존성 주입 등 기본적인 세팅을 처리할 때 활용할 수 있습니다.
true를 반환해야 앱 실행이 이어지며, 실행 시 초기 1회만 호출됩니다.

didFinishLaunchingWithOptions

func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil
) -> Bool {
    return true
}

didFinishLaunchingWithOptions는 앱 실행 준비를 모두 마치고, 첫 화면이 표시되기 직전에 호출됩니다.
앱 전반에서 필요한 Logger, Firebase Crashlytics, APNS Push 등의 초기 설정 작업을 이 시점에 수행합니다.
보통 rootViewController 초기화도 이 단계에서 이뤄집니다.
true를 반환하면 다음 단계로 실행이 이어지며, 미구현 시 기본적으로 true가 반환됩니다.
실행 시 초기 1회만 호출됩니다.

applicationDidBecomeActive

func applicationDidBecomeActive(_ application: UIApplication) {
    // do something
}

앱이 사용자와 상호작용 가능한 상태가 되면 호출됩니다.
백그라운드에 있다가 포어그라운드로 돌아와 상호작용할 준비가 되면 실행되며,
앱 실행 초기에 didFinishLaunchingWithOptions 이후에도 이어서 호출됩니다.

다른 앱의 음악을 듣다가 본 앱으로 복귀했을 때 오디오 세팅을 조정하거나,
일시정지된 애니메이션을 재개하는 등 앱 활성화 이후 처리 로직에 활용됩니다.

applicationWillResignActive

func applicationWillResignActive(_ application: UIApplication) {
    // 앱이 활성 상태를 잃기 직전에 호출됩니다.
    // 홈 버튼 누름, 알림창 등장, 전화 수신 등으로 일시 중단되기 전 단계입니다.
}

포어그라운드에서 active → inactive 상태로 전환되기 직전에 호출됩니다.
전화가 오거나, 알림창이 뜨거나, 홈 화면으로 이동하는 등 일시적인 중단 상황에서 실행됩니다.

이 시점에는 불필요한 작업을 잠시 중단하거나, 데이터 저장 및 정리 등 일시중단 전 처리를 수행하기에 적합합니다.

applicationDidEnterBackground

func applicationDidEnterBackground(_ application: UIApplication) {
    // 앱이 백그라운드로 진입했을 때 호출됩니다.
    // 데이터 저장이나 네트워크 세션 종료 등의 작업을 수행합니다.
}

didEnterBackground는 사용자가 홈 화면으로 이동하거나,
다른 앱으로 전환해 앱이 백그라운드 상태가 되었을 때 호출됩니다.
이 시점에 백그라운드에서 필요한 작업이나, 사용자 데이터 저장, 세션 종료 등을 처리할 수 있습니다.

applicationWillTerminate

func applicationWillTerminate(_ application: UIApplication) {
    // 앱이 완전히 종료되기 직전 호출됩니다.
    // 단, 백그라운드 상태에서 시스템이 앱을 강제 종료할 경우엔 호출되지 않습니다.
}

willTerminate는 앱이 정상적으로 종료되기 직전 호출됩니다.
앱이 강제로 종료될 때는 호출되지 않으며, 종료 전 필요한 작업을 수행할 수 있는 마지막 단계입니다.
예를 들어, 앱 종료 직전에 저장해야 하는 데이터나 로그 처리를 담당할 수 있습니다.

앱 실행 후 바로 종료 시 호출 순서

앱을 실행했다가 바로 종료하면 일반적으로 아래 순서대로 메서드들이 호출됩니다.
메서드 이름만 봐도, 흐름이 자연스럽게 이어지는 것을 확인할 수 있습니다.

// 앱 실행 및 종료 시의 일반적인 호출 순서
willFinishLaunchingWithOptions
→ didFinishLaunchingWithOptions
→ applicationDidBecomeActive
→ applicationWillResignActive
→ applicationDidEnterBackground
→ applicationWillTerminate

앱 실행 후, 바로 홈화면으로 복귀 시 호출 메서드 예시

앱 실행 후, 홈화면 복귀 시 호출되는 AppDelegate 생애주기메서드 예시입니다.

iOS13 이후 추가된 SceneDelegate

iOS 13 이후 아이패드 등에서 멀티 윈도우 개념이 도입되면서 SceneDelegate가 추가되었습니다.
이에 따라 일부 역할이 SceneDelegate로 분리되었지만,
앱 전반적인 관리는 여전히 AppDelegate가 담당합니다.

멀티 윈도우 기능이 필요하지 않은 일반적인 앱에서는
SceneDelegate 없이 AppDelegate만으로도 충분히 서비스 개발이 가능합니다.

마무리

오늘은 앱의 전반적인 생애주기를 관리하는 AppDelegate의 역할과 주요 메서드들을 정리해봤습니다.
앱이 실행되고 종료되는 전체 흐름을 이해하면,
상태 변화에 따라 어떤 시점에 어떤 처리를 해야 하는지 명확하게 판단할 수 있습니다.

다음에는 SceneDelegate 중심으로 화면 단위 생애주기에 대해 정리해보겠습니다. 감사합니다!

iOS26 개발, 시뮬레이터 테스트 위한 Xcode26 설치 방법

applebuddy — Fri, 26 Sep 2025 00:33:18 +0900

안녕하세요. 개발자 멍구입니다.

Liquid Glass 디자인이 적용되는 iOS26, 이제 개발자에게는 추가로 테스트 및 대응해야하는 영역인데요.

오늘은 iOS26 테스트를 위한 환경 설정 과정을 가볍게 기록 및 공유할게요.

macOS 버전 및 Xcode 버전 확인

먼저, iOS26 테스트를 위해서는 iOS26 시뮬레이터를 지원하는 Xcode 26.0 release 버전을 다운로드해야합니다.

Xcode 26.0 release 버전을 설치하기 위해서는 macOS 15.6 이상 버전이 필요하기 때문에, 그 미만 macOS 버전이라면, 업데이트를 해주어야 합니다.

Xcode26 설치를 위한 macOS 버전 15.6 이상 업데이트 하기

좌상단 애플 로고를 클릭 후, 이 Mac에 관하여... 를 클릭하시면 현재 macOS 버전을 알 수 있어요. 저는 15.5였는데, Xcode 26 설치를 위해서 15.7로 업데이트 했습니다.

좌상단 애플로고 클릭 > 시스템 설정 > 일반 > 소프트웨어 업데이트 를 클릭하시면, 업데이트 가능한 버전을 확인 가능합니다.

macOS 버전 15.6 이상 업데이트 후 Xcode26, iOS26 시뮬레이터 설치

그렇게 macOS 15.5 -> 15.7로 업데이트 후, Xcode 26.0.1 release 버전을 설치했어요. 저는 M1 칩이 있는 맥북이라서 Apple silicon 버전으로 받았습니다. 기존 Xcode 대비 아이콘이 변경되었네요.

Xcode 26을 실행하시면, iOS 26 개발 tool 설치가 가능하고, 여기에서 iOS 26 simluator 를 설치가능해요. 설치 이후에는 iOS 26의 iPhone Air 같은 기종을 시뮬레이터로 선택해서 개발하실 수 있으니 참고하세요.

iOS26 시뮬레이터 아이콘도 변경되었네요. 전체적으로 기존보다 심플하고, 확연히 개성있는 모습을 보여주는 것 같아요.

오늘은 iOS26 iOS 개발 테스트를 위해서...! macOS 15.6이상 업데이트 후, Xcode26 설치 및 iOS26 simulator 를 통해 iOS26 개발 테스트가 가능한 환경을 준비하는 과정을 가볍게 알아봤습니다.

iOS26 부터는 앱 시스템 디자인이 전체적으로 변경된게 많으니, 기존에 문제없던 곳에서도 많은 버그나 레이아웃 이슈가 발생할 수 있는데요. 또 아이폰 유저들은 업데이트가 빠른 편이니. voc 발생할 수 있는 부분인 것 같아요.

그렇기에 현업이나, 사이드프로젝트 하는 분들은 관심 갖고 유지보수하시면 좋을 것 같습니다.

지금까지 iOS26 시뮬레이터로 iOS 개발 준비하는 방법이었어요. 감사합니다!

App Store Connect 애플 개발자 계정 비밀번호 변경하는 방법

applebuddy — Sat, 6 Sep 2025 00:11:44 +0900

안녕하세요. 개발자 멍구입니다~!

여러분들은 App Store Connect의 애플 개발자 계정 많이 사용하시나요? 애플 개발자 프로그램을 등록해서 iOS앱 심사를 내고, 배포 및 런칭할 일이 있다면, 사용하게 되는 계정인데요.

오늘은 App Store Connect의 애플 개발자 계정 비밀번호 변경방법 간단하게 기록해봅니다.

App Store Connect 개발자 계정은 애플 공식 홈페이지와도 연동되는 계정입니다. apple 공시 홈페이지 하단을 보시면, 계정 섹션 하단에 Apple 계정 관리 메뉴가 있어요. 여기를 들어갑니다.

Apple (대한민국)

Apple이 제시하는 혁신적인 세상을 만나고, iPhone, iPad, Apple Watch, Mac, Apple TV 등을 구입하는 것은 물론, 액세서리, 엔터테인먼트, 전문가 기기 지원에 대해서도 살펴볼 수 있습니다.

www.apple.com

Apple 계정 관리 페이지의 로그인 및 보안 > 암호 메뉴를 보시면, 최근 비밀번호 업데이트 일자와 함께 클릭 후 비밀번호 변경이 가능합니다.

비밀번호 변경 페이지에서 현재 암호와 새 암호를 입력해서 쉽게 비밀번호 변경이 가능했습니다. 변경된 비밀번호는 공식 apple 홈페이지 및 App Store Connect 계정 로그인으로 사용할 수 있습니다.

오늘은 간단하게 App Store Connect 애플 개발자 계정 비밀번호 변경하는 방법을 기록해봤습니다. 모두 주기적으로 애플 계정, 개발자 계정 비밀번호 관리하시면서, 안전한 계정 관리 되시길 바랍니다~

iOS Xcode16 WebKit, nw_proxy_config_t 컴파일 에러 수정방법 feat. chatGPT

applebuddy — Sun, 15 Jun 2025 09:13:08 +0900

안녕하세요, 개발자 멍구입니다!
오랜만에 사이드 프로젝트를 만지다가 Xcode 16.4로 업데이트한 이후, 컴파일 에러가 발생했어요.
예전에 Xcode 15를 사용할 때 겪었던 비슷한 에러가 또 발생해서, 이전에 제가 작성했던 블로그 글을 참고해보기로 했습니다.

사이드프로젝트 컴파일 에러 발생
Could not build Objective-C module 'WebKit', No type or protocol named 'nw_proxy_config_t'

지겨워요 Webkit 관련 이슈인데요. tuist 등의 외부 라이브러리 의존성과 연관이 있는 것 같아요. tuist, TCA 기반의 프로젝트에서만 경험했던 컴파일 에러입니다. 근원지는 WKWebsiteDataStore.h 입니다. 왜 아냐면, 이미 이걸 작년에도 경험해봤거든요. ㅠㅠ

WKWebsiteDataStore.h는 WebKit 프레임워크의 헤더 파일로,
WKWebsiteDataStore 클래스의 인터페이스를 정의합니다. 이 클래스는 웹 콘텐츠(웹페이지 등)가 사용하는 데이터 저장소를 관리
하는 역할을 해요. WKWebView와도 연관이 깊은 놈이라고 볼 수 있겠어요.

WebKit 이슈의 근원지, WKWebsiteDataStore.h 수정 시도

iOS Xcode 15.2, module 'WebKit' build 이슈 해결방법

안녕하세요~ iOS앱을 개발하다가 문제가 생겼던 멍구입니다! 오늘은 Xcode 15.2 버전을 통해 앱을 개발하면서 자주 발생했던 'WebKit' module build 이슈 해결방법을 간략하게 소개하려 합니다! 'WebKit'

0urtrees.tistory.com

// WKWebsiteDataStore.h
"__IPHONE_OS_VERSION_MAX_ALLOWED >= 170000"  에서 170000 -> 180000로 변경시도

이 이슈를 Xcode 15.2에서도 경험했던 터라, 그때 작성했던 위 블로그 포스팅을 참고해서 수정해보기 시도를 했으나, 실패했습니다. 골치아파요. 그래서 chatGPT에게 도움을 요청했습니다...!

chatGPT에게 WKWebsiteDataStore.h 수정 요청

WKWebsiteDataStore.h에서 nw_proxy_config_t 타입을 인식 못함 → No type or protocol named 'nw_proxy_config_t' 에러 발생

Could not build Objective-C module 'WebKit', No type or protocol named 'nw_proxy_config_t' 관련 컴파일에러가 발생해서 컴파일 에러 내용과 함께 해당 에러가 발생하는 WKWebsiteDataStore.h 파일을 수정해달라고 chatGPT에게 요청했습니다.

그렇게 우리의 chatGPT는 nw_proxy_config_t를 인식하지 못하니, 이걸 NSArray로 바꾸라고 해서 그렇게 수정했습니다. 파일 내용 vi 편집기로 일괄 수정!
그렇게 수정 후 tuist clean > tuist fetch > tuist generate > build 시도...!

그렇게 프로젝트 빌드가 되네요...

이 방법은 Xcode를 업데이트 하거나, 변경하면 다시 별도 처리가 필요한 단편적인 방법이라, 정해는 아닙니다. 그래도 당장 사이드프로젝트 빌드 및 개발 진행을 할 수 있었습니다. ㅠㅠ tuist, TCA 등의 외부라이브러리 의존이 많다보니 이런 저런 예기치 못한 문제들이 더 발생하는 것 같아요. 이 또한 좋은 경험이라 생각하며... 이만 포스팅 마치겠습니다.

이 이슈 관련 더 좋은 해결방안이 있다면 공유 부탁드려요. 수정된 WKWebsiteDataStore.h 코드 내용 공유와 함께 포스팅 마칠게요. 감사합니다.

수정한 WKWebsiteDataStore.h 파일 코드

/*
 * Copyright (C) 2014-2017 Apple Inc. All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY APPLE INC. AND ITS CONTRIBUTORS 'AS IS'
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR ITS CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
 * THE POSSIBILITY OF SUCH DAMAGE.
 */

#import <WebKit/WKFoundation.h>
#import <WebKit/WKWebsiteDataRecord.h>

#if __has_include(<Network/proxy_config.h>)
#import <Network/Network.h>
#endif

NS_ASSUME_NONNULL_BEGIN

@class WKHTTPCookieStore;

WK_SWIFT_UI_ACTOR
WK_EXTERN API_AVAILABLE(macos(10.11), ios(9.0))
@interface WKWebsiteDataStore : NSObject <NSSecureCoding>

+ (WKWebsiteDataStore *)defaultDataStore;
+ (WKWebsiteDataStore *)nonPersistentDataStore;

- (instancetype)new NS_UNAVAILABLE;
- (instancetype)init NS_UNAVAILABLE;

@property (nonatomic, readonly, getter=isPersistent) BOOL persistent;
+ (NSSet<NSString *> *)allWebsiteDataTypes;

- (void)fetchDataRecordsOfTypes:(NSSet<NSString *> *)dataTypes completionHandler:(WK_SWIFT_UI_ACTOR void (^)(NSArray<WKWebsiteDataRecord *> *))completionHandler WK_SWIFT_ASYNC_NAME(dataRecords(ofTypes:));

- (void)removeDataOfTypes:(NSSet<NSString *> *)dataTypes forDataRecords:(NSArray<WKWebsiteDataRecord *> *)dataRecords completionHandler:(WK_SWIFT_UI_ACTOR void (^)(void))completionHandler;

- (void)removeDataOfTypes:(NSSet<NSString *> *)dataTypes modifiedSince:(NSDate *)date completionHandler:(WK_SWIFT_UI_ACTOR void (^)(void))completionHandler;

@property (nonatomic, readonly) WKHTTPCookieStore *httpCookieStore API_AVAILABLE(macos(10.13), ios(11.0));
@property (nonatomic, readonly, nullable) NSUUID *identifier API_AVAILABLE(macos(14.0), ios(17.0));

+ (WKWebsiteDataStore *)dataStoreForIdentifier:(NSUUID *)identifier API_AVAILABLE(macos(14.0), ios(17.0));

+ (void)removeDataStoreForIdentifier:(NSUUID *)identifier completionHandler:(WK_SWIFT_UI_ACTOR void(^)(NSError * _Nullable))completionHandler API_AVAILABLE(macos(14.0), ios(17.0));

+ (void)fetchAllDataStoreIdentifiers:(WK_SWIFT_UI_ACTOR void(^)(NSArray<NSUUID *> *))completionHandler WK_SWIFT_ASYNC_NAME(getter:allDataStoreIdentifiers()) API_AVAILABLE(macos(14.0), ios(17.0));

#if ((TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 140000) \
    || ((TARGET_OS_IOS || TARGET_OS_MACCATALYST) && __IPHONE_OS_VERSION_MAX_ALLOWED >= 180000) \
    || (TARGET_OS_WATCH && __WATCH_OS_VERSION_MAX_ALLOWED >= 100000) \
    || (TARGET_OS_TV && __TV_OS_VERSION_MAX_ALLOWED >= 170000) \
    || (defined(TARGET_OS_VISION) && TARGET_OS_VISION))

@property (nullable, nonatomic, copy) NSArray *proxyConfigurations NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(14.0), ios(17.0));
#endif

@end

NS_ASSUME_NONNULL_END

LeetCode swift, Letter Combinations of a Phone Number 문제풀이

applebuddy — Sat, 14 Jun 2025 19:56:34 +0900

안녕하세요~ 개발자 멍구입니다.
오늘은 LeetCode의 Letter Combinations of a Phone Number 를 풀어보았어요. 바로 보겠습니다!

릿코드 Letter Combinations of a Phone Number 문제 설명

해당 문제는 2~9의 키패드에 입력가능한 문자가 정의되어있는데요. 특정 digits 가 주어졌을때 해당 digits로 입력 가능한 모든 문자 케이스를 반환하는 문제였습니다. 이때 반환하는 케이스는 문자열 배열 형태로 반환하고, 반환되는 문자열의 순서는 신경 안써도 됩니다.

바로 문제 풀어보겠습니다. 보시기 전에, 안푸셨다면 먼저 릿코드에서 해당 문제를 직접 풀어보시고 보시길 추천드립니다!

릿코드 swift 문제 풀이 시작

문제 풀어볼게요. 3행에서는 digits 입력값이 비었을때의 케이스를 미리 필터링해줍니다. 이때에는 입력가능한 문자가 없으므로 빈 배열을 반환합니다.

5~16행) 이어서 2 ~ 9의 키패드로 입력가능한 문자들을 digitToLetters에 정의했어요.

17~19행) 정답을 넣을 res 배열, digits 길이를 digitsLen에 담아두고, Character 배열의 digitArray도 담아놓습니다. 이렇게 미리 담아놓는 이유가 뭘까요?

swift의 String는 일반 배열처럼 간단하게 첨자접근을 하기 어렵습니다. 또한 String 에서 제공하는 인덱스로 접근하는 경우 시간복잡도가 O(N)입니다. 그리고 String count 를 통해 문자열 길이를 반환받을 시에도 시간복잡도가 O(N)입니다. -> 그렇기 때문에 이런 연산이 많아지는 경우에는 미리 해당 결과를 초반에 한번 받아두고 사용하는 것이 더 좋습니다!

backtract 이라는 메서드를 정의했습니다. DFS로 돌리는 메서드입니다.

21행) backtrack 메서드를 정의합니다. dfs로 활용되며, solution 메서드 내에 중첩 메서드로 정의했습니다.

22 ~ 25행) "23" 과같은 digits 입력을 받았을때 입력 가능한 문자는 전부 digits 입력 길이와 같은 길이가 됩니다. 따라서 digitsLen과 현재 순회하는 index가 같아지게 될때 (현재 입력된 문자 길이가 digits 길이와 같아지면) 정답으로 쌓아놓습니다.

27 ~30행)
이 다음 체크해야하는 digitNumber를 반환받습니다. Character 타입에서는 swift 5.1 부터 asciiValue 라는 프로퍼티를 제공합니다. '1' Character 의 asciiValue 에서 48을 빼면, 1 이라는 값을 얻을 수 있습니다.

digitNumber로 입력가능한 모든 케이스를 순회하는 모습입니다. 2를 방문한다면, 'a', 'b', 'c'를 추가한 문자열 케이스를 방문하게 됩니다! 그렇게 dfs를 순회하면서 입력가능한 모든 문자열을 res에 쌓게 됩니다. 입력으로 주어진 digits 를 순차적으로 방문하는 케이스이므로 이 이상 복잡한 로직을 필요로 하지 않았어요.

문제풀이 끝, 결과를 보겠습니다.

LeetCode swift 문제풀이 후 제출 결과

Beats 100.00%가 나오네요. 이번 문제의 핵심은 모든 2~9의 키패드로 입력 가능한 모든 케이스를 dfs 등의 순회로 찾을 수 있느냐가 될 것 같고, 그에 따른 기저조건 (더이상 방문할 필요가 없는 케이스를 필터링) 설정도 중요합니다.

추가로 swift 언어로 풀게 된다면, 유니코드 호환이 가능한 swift 문자열의 원리를 감안하고 count, 첨자접근 방식을 고려해볼 수 있었던 문제였습니다.

해당 문제는 LeetCode study plan에서 풀었습니다. 종종 해당 페이지에 있는 문제를 풀어보려고해요. 지금까지 Letter Combinations of a Phone Number swift 풀이였습니다. 더 좋은 아이디어나 질문이 있다면 언제든 댓글 주세요. 감사합니다~! ☺️

개발자 경력 관련 고민, F-Lab 커리어 관련 멘토 Q&A 참여후기

applebuddy — Fri, 13 Jun 2025 01:05:17 +0900

안녕하세요~ 개발자 멍구입니다.

요즘 개발자 시장, 특히 주니어나 커리어 전환을 고려하는 분들에게 참 혼란스러운 시기죠. AI로 인한 변화, 채용 트렌드의 급변, 실무 능력과 이력서 준비 등 수많은 고민들이 쏟아지고 있어요.

그런 상황에서 오늘 F-Lab에서 진행된 Fitz 멘토님의 "무엇이든 물어보세요" 세션이 진행되었습니다. 무료로 열렸던 행사여서 취업, 이직 고민 있는 지인들께도 공유드리면서 참여해봤어요.

무려 2시간 동안 쉼 없이 질의응답이 진행되었는데요. 개발자 커리어에 대한 실제적인 조언들이 오갔던 시간이었습니다.
몇가지 기억나는 질문에 대한 Fitz 멘토님의 답변을 정리했어요. 커리어에 고민이 많으신 분들께 조금이라도 도움이 되었으면 합니다.

물경력 5년, 이직은 가능할까요?

Q. 물경력으로 5년 채웠는데, 어떻게 취업 방향을 잡고 발전해야 할지 모르겠어요.

A. 물경력이라 해도 분명한 장점이 있습니다. 실무에 노출된 만큼 완전 신입보다는 기술 습득 속도가 빠를 수 있어요. 다만, 다시 시작한다는 마음으로 1~2년 정도는 집중적으로 학습하고 포트폴리오를 채우는 걸 추천드립니다.

처음부터 다시 준비한다기보다, 기존의 경험 위에 제대로 된 기반을 쌓는 전략이 중요합니다.

개발자가 꼭 읽어야 할 책은?

Q. 기술력을 쌓기 위해 어떤 책부터 읽으면 좋을까요?

A. 아래 책들을 추천드립니다:

『객체지향의 사실과 오해』 – 객체지향 개념을 직관적으로 이해할 수 있어요.
『가상 면접 사례로 배우는 대규모 시스템 설계 기초』 – 기술 면접 대비에도 좋습니다.
『한 장 보고서의 정석』 – 문서나 이력서 작성 능력을 높여주는 필수템입니다.

코딩 테스트, 꼭 잘해야 하나요?

Q. 코딩테스트 준비가 부족해서 걱정이에요. 꼭 잘해야 갈 수 있는 곳이 많을까요?

A. 물론, 코테를 보는 회사는 많지만, 과제 전형을 택하는 회사도 많아졌어요. 즉, 다양한 루트를 고려해보세요. 코테 준비는 하루 30분씩이라도 꾸준히 해보는 걸 권장합니다. 꾸준히, 실행하는 작은 습관이 결국 실력을 만듭니다.

빅테크 도전? 불황기에는 어디든 가는게 나을까요?

Q. 빅테크를 도전해보고 싶은데, 불황기인 지금 도전하는 건 무모한 걸까요?

A. 최근에도 토스 등 일부 빅테크는 주니어 채용을 활발히 하고 있어요. 조건만 맞는다면 도전해볼 만합니다. 하지만, 지금 내 상황에 맞는 전략도 중요합니다.

내가 꾸준히 학습하고 있는가?
좋은 동료, 커뮤니티와의 교류가 가능한 환경인가?

이런 요소들이 더 큰 성장의 발판이 될 수 있으므로, 이런 환경 조성을 할 수 있도록 합시다.

이력서는 어떻게 써야 눈에 띌까?

Q. 이력서에서 첫인상이 정말 중요하다던데, 가장 중요한 포인트는 뭘까요?

A. 첫 장에 '이력서'가 아니라 '제안서'처럼 구성하세요. 간결하고 눈에 띄는 요약, 키워드 중심의 문장, 직관적인 레이아웃이 핵심입니다.

평균 7초 안에 1차 판단이 된다고 하니, 첫인상을 사로잡는 게 관건이에요.

이력서/자소서/경력기술서 분량은?

A. 너무 짧으면 정보가 부족하고, 너무 길면 읽기 싫어집니다. 가장 좋은 전략은:

앞부분에 요약 및 주요 경력, 그리고 임팩트 있는 자기 어필을 담기
필요하면 몇 장 분량이 돼도 괜찮지만, 핵심은 ‘내용의 밀도’입니다

그리고 중요한 한 마디:

완벽한 이력서는 없습니다. 지금의 나를 솔직하면서도 매력적으로 표현하는 것이 더 중요해요.

이력서에 사진, 꼭 넣어야 할까?

Q. 이력서에 사진을 넣을까요 말까요? 어떤 사진이 좋을지도 고민돼요.

A. 정답은 없지만, 자신을 충분히 어필할 수 있는 이미지 1~2장을 첨부하는 것도 괜찮습니다. 단, 너무 강조하진 마세요. 핵심은 여전히 내용입니다.

커뮤니케이션 능력 키우는 법

A. 개발자에게도 커뮤니케이션은 필수 역량입니다.

멘토링을 해보거나
자신있게 무대뽀로 설명해보는 습관
동료들과 자주 이야기 나누며 피드백 받기

이런 활동들이 생각 정리력, 전달력, 협업 능력등의 전반적인 커뮤니케이션 능력을 빠르게 키워줍니다.
+ SBI(Situation, Behavior, Impact) 상황/행동/임팩트 기반으로 대화하는 습관을 가지고, 평소 회의나 커뮤니케이션 간에 주위를 환기시킨 후 대화해보는 습관도 가지면 좋습니다.

피츠 멘토님의 마지막 한 마디

“자유롭게, 내 생각을 공유하세요. 꼭 정답일 필요는 없어요. 표현하고 나누는 것 자체가 성장의 시작입니다.”

알고리즘 스터디, 진짜 도움 될까?

A. 네! 심지어 참여자도 많지 않아서, 깊은 교류와 집중 학습이 가능합니다. 알고리즘 스터디를 주도하고 계신 f-lab 멘토님 제이슨님과도 가까워질 수 있고요. 좋은 사람들과의 연결은 또 다른 기회로 이어집니다.

마무리하며

이번 세션을 통해 많은 분들이 위로와 자극을 동시에 받았던 것 같아요. 불확실한 시대에 개발자로 살아남는 건 쉽지 않지만, 꾸준한 학습과 열린 태도, 그리고 나를 어필할 수 있는 전략이 있다면 길은 분명히 있다고 생각해요.

저도 오늘 얻은 인사이트들을 바탕으로 다시 한번 방향을 정리해보려 합니다. 이 글이 여러분의 커리어에도 작은 나침반이 되길 바랍니다!