본문

이 글은 2025 안드로이드 탐구 영역에 나온 문제 중 일부를 해석하는 글의 형태로 작성합니다. 문제 전체를 담지 않고, 중요한 해설을 작성합니다.

정정

24.12.11 해석에 오류가 있으며, 코드 검증 과정에서 오류를 확인하여 수정합니다.

댓글로 오류가 있다고 알려주신 Larry, 송준영님 감사합니다.

안드로이드 탐구 영역 후기 글

• 2025학년도 안드로이드 탐구영역 - link
• 2025학년도 안드로이드 탐구영역을 준비하며(경완님 작성) - link

어떤 문제일까?

코루틴 Exception 발생 시 예외 범위를 물어보는 질문에 대한 해석을 담는 글이다.

대략 적어보면

- 최상위 Job A는 viewModelScope.launch로 생성되고 내부에서 B, C를 생성한다.
- B에서는 coroutineScope 내에서 D, E를 생성한다.
- C에서는 withContext(Dispatchers.IO) 내에서 F를 생성한다.

모든 Job이 Finish 되었다고 가정

A-F까지 모두 Job이 리턴된다는 사실과 모든 Job이 동작 완료되었을 때를 가정한다.

이 부분에 대한 글은 이미 과거에도 작성했어서 링크를 추가해두겠다.

• Kotlin Coroutines의 Job 동작을 알아보자
• Kotlin Coroutines Exception 영향도 알아보기

이 두 개의 글을 이해한다면 사실 해석할 필요도 없지만, 새로운 마음으로 글을 적어본다.

이 글에서는

• 2025 안드로이드 탐구 영역에 나온 문제 일부를 정리한다.
• Job에 대한 이해가 필요하다.

문제의 해석

모든 실행에서 Job을 가지려면 launch {}를 통해 새로운 작업을 실행해야 한다는 점이다.

async는 DeffDeferred T를 리턴하기에 적절하지 않은 실행에 해당하기에 코드로 작성하면 아래와 같다.

// A의 실행
viewModelScope.launch {
    // B의 실행
    launch {
        coroutineScope {
            // D의 실행
            launch { }
            // E의 실행
            launch { }
        }
    }
    // C의 실행
    launch {
        withContext(Dispatchers.IO) {
            // F의 실행
            launch { }
        }
    }
}

이 문제를 해석할 때 주의할 점이 하나 있다.

Coroutine builder로 실행하는 경우 부모의 CoroutineContext는 하위(자식) 모두 상속받는 것이 아니라는 점이다. 코드를 추적하면 fold를 통해 합산한다.

단, Job은 상속받지 않는데 다음과 같은 이유로 제미나이의 설명이다.

만약 Job이 상속된다면, 부모 코루틴의 Job이 취소될 때 자식 코루틴도 함께 취소됩니다. 이는 각 코루틴의 생명주기를 개별적으로 관리하기 어렵게 만듭니다. 각 코루틴이 독립적인 Job을 가지도록 함으로써, 코루틴의 취소와 생명주기 관리를 더욱 유연하게 제어할 수 있습니다.

결국 필요한 것만 합산하고 치환할 수 있으며, Job은 예외로 상속받지 않는다.

함정도 찾아보자.

이 문제에는 2가지 함정이 있다. 바로 coroutineScope과 withContext(Dispatchers.IO)이다.

이 코드에서는 사실 아무런 의미가 없다. 어차피 launch {}를 통해 코드를 실행하기 때문에 blocking을 만드는 coroutineScope과 withContext(Dispatchers.IO) 코드의 사용은 의미가 없고 함정을 만들기 위한 코드 설명이라는 점이다.

• coroutineScope - link
• withContext - link

Job?

Job에는 크게 2개 있다.

그냥 Job - link과 SupervisorJob - link을 가진다.

이 둘은 딱 하나의 차이가 있는데, 하위 Job에서 발생하는 Exception 케이스로 인해 부모가 영향을 받는가 아닌가이다.

이전 글에서도 작성했지만 Kotlin Coroutines Exception 영향도 알아보기를 줄이기 위해서는 SupervisorJob을 활용하는 것이 적합하다.

다행히 android viewModelScope은 SupervisorJob을 기본으로 활용하고 있다.

Job은 라이프 사이클도 가지고 있는데 아래의 그림과 같다.

이 부분을 꼭 기억할 이유는 없지만 cancel/fail 처리 시 Cancelled 상태로 변경된다는 점이 중요한 부분이다.

이걸 알지 않더라도 코루틴에서는 exception 발생 시 runCatch만 잘 걸어도 문제가 없으며, 오류가 발생하더라도 재시도 가능하다는 점이 중요한 포인트 아닐까 싶다.

문제 해석 정정.

위 내용으로 알 수 있는 사실은 그래서 영향도가 어디까지 전파될까이다.

// A의 실행
viewModelScope.launch {
    // B의 실행
    launch {
        coroutineScope {
            // D의 실행
            launch { }
            // E의 실행
            launch { }
        }
    }
    // C의 실행
    launch {
        withContext(Dispatchers.IO) {
            // F의 실행
            launch { }
        }
    }
}

이 코드는 어디에서 오류가 나든 viewModelScope.launch {}인 A가 종료된다.

그렇기에 문제에 나온 답변은 정답이 없을 수 있다.

그래도 궁금하잖아

그럼 위 코드에서 일부의 작업을 Job()로 다시 변경하면 영향은 어떻게 달라질까?

앞서 적었던 코드에 B의 작업에 Job()으로 치환하면 어떤 일이 벌어질까?

// A의 실행
CoroutinesScope(SupervisorJob()).launch {
    // B의 실행
    launch(Job()) { // Job으로 변경
        // D의 실행
        launch { throw Exception("exception") }
        // E의 실행
        launch { }
    }
    // C의 실행
    launch {
        // F의 실행
        launch { }
    }
}

간단하다.

• A는 구조화가 깨진 B의 영향을 받지 않으며, C 내부에서 발생한 오류 역시 영향받지 않는다.
• B는 새로운 Job을 생성하였기에 A와 무관하며 D/E의 작업 실패에 대한 영향 받는다.
• C는 F에서 발생하는 오류에 영향받지 않는다.
• C는 새로운 Job을 생성한 B에서 발생한 오류에 대한 영향 받지 않는다.

이런 이유는 제미나이에서 설명한 Job의 예외 설명에서 충분히 잘 나온다.

Job 대신 사용할 수 있는 안전한 방법은

supervisorScope을 사용하는 방법이 있으니 참고하여 사용하시길

// A의 실행
CoroutinesScope(SupervisorJob()).launch {
    // B의 실행
    supervisorScope {
        launch { // Job으로 변경
            // D의 실행
            launch { throw Exception("exception") }
            // E의 실행
            launch { }
        }
    }
    // C의 실행
    launch {
        // F의 실행
        launch { }
    }
}

간단한 원리 정정 포함

내부 코드랑 무관하게 아래와 같다.

val a = viewModelScope.launch {
    // 여기서 오류가 나거나
}

val b = viewModelScope.launch {
    // 여기서 오류가 나거나
}

위와 같이 a/b의 최상위 viewModelScope에 대한 launch {}를 실행할 때는 a/b 중 어느 곳에서 exception이 발생하더라도 서로 영향 받지 않는다.

이전에 오류를 범한 이유는 아래와 같은 내부 코드를 참고하였기 때문이다.

당연하게도 launch의 상위 viewModelScope.launch {}를 부모로 가지고 있었을거라고 착각한 부분이다.

private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
    override fun childCancelled(cause: Throwable): Boolean = false
}

지금 현재의 Job과 Parent Job을 모두 가지고 소통한다는 점을 알 수 있다.

private val _parentHandle = atomic<ChildHandle?>(null)
internal var parentHandle: ChildHandle?
    get() = _parentHandle.value
    set(value) { _parentHandle.value = value }

override val parent: Job?
    get() = parentHandle?.parent

마무리

간단하게 2025 안드로이드 탐구영역의 Exception 전파에 대해 정리하였다.

이 문제를 알 수 있는 것은

• Job은 cancel/fail 발생 시 현재 상태를 Cancelled 처리한다.
• Job은 하위 context에 전달되지 않지만 Parent.job은 하위 Job에서도 별도로 관리한다.
• SupervisorJob과 Job을 중간에 혼용해서 사용하는 경우에는 Job 부분은 모두 종료 처리한다.
• launch로 실행할 경우 return 결과는 Job이 된다.

Job과 SupervisorJob의 중요성을 이해할 수 있는 간단한 문제입니다.

정정하면서

AI에게 질문을 다 남겨보았는데 서로 다른 답변을 준다.

AI의 응답이 100% 답은 아니겠지만 일부 맞다고 가정하고 이야기했고, 내가 알고 있던 내용을 전달하면서 오류가 생겼다. 적당히 알뜰하게 사용하면 유용한 도구임은 맞다.

결국 코드 검증을 통해 잘못되었다는 걸 발견하고 나서 수정은 했지만 재미있는 문제임은 맞다.

실제 개발할때는 이렇게 사용하더라도 runCatch를 항상 달고 사용하니 크게 문제를 느끼지 못했었다.

코루틴 예외 전파에 대한 영상 추가

우테코 크루 오둥이님의 코루틴 예외 처리 영상을 추가합니다.