<div id="readability-page-1" class="page"><div>
 <hr>
 

<hr>
 개인 광고 영역


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

<h4>안드로이드 탐구 영역 후기 글</h4>
<ul>
 <li><a href="https://android-exam25.gdg.kr/">2025학년도 안드로이드 탐구영역 - link</a></li>
 <li><a href="https://medium.com/@lucas.kang/2025%ED%95%99%EB%85%84%EB%8F%84-%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%ED%83%90%EA%B5%AC%EC%98%81%EC%97%AD%EC%9D%84-%EC%A4%80%EB%B9%84%ED%95%98%EB%A9%B0-feabccc2b0cc">2025학년도 안드로이드 탐구영역을 준비하며(경완님 작성) - link</a></li>
</ul>

<h3>어떤 문제일까?</h3>

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

대략 적어보면

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

모든 Job이 Finish 되었다고 가정
</code></pre></div>

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

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

<ul>
 <li><a href="https://thdev.tech/kotlin/2019/04/08/Init-Coroutines-Job/">Kotlin Coroutines의 Job 동작을 알아보자</a></li>
 <li><a href="https://thdev.tech/kotlin/2019/04/30/Coroutines-Job-Exception/">Kotlin Coroutines Exception 영향도 알아보기</a></li>
</ul>

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

<h3>이 글에서는</h3>
<ul>
 <li>2025 안드로이드 탐구 영역에 나온 문제 일부를 정리한다.</li>
 <li>Job에 대한 이해가 필요하다.</li>
</ul>



<h2>문제의 해석</h2>

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

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

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

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

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

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

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

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



<h2>함정도 찾아보자.</h2>

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

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

<ul>
 <li><a href="https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/coroutine-scope.html">coroutineScope - link</a></li>
 <li><a href="https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/with-context.html">withContext - link</a></li>
</ul>



<h2>Job?</h2>

Job에는 크게 2개 있다.

그냥 <a href="https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-job/">Job - link</a>과 <a href="https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-supervisor-job.html">SupervisorJob - link</a>을 가진다.

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

이전 글에서도 작성했지만 <a href="https://thdev.tech/kotlin/2019/04/30/Coroutines-Job-Exception/">Kotlin Coroutines Exception 영향도 알아보기</a>를 줄이기 위해서는 SupervisorJob을 활용하는 것이 적합하다.

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

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

<img src="https://thdev.tech/images/posts/2024/Kotlin-Coroutines-Effect/sample_01.png" alt="sample_01">

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

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



<h2>문제의 해석은 끝났다.</h2>

위에서 적은 내용만 알면 사실문제 해석은 완료되었다.

문제에서 도출한 내용의 코드는 아래와 같은데,

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

여기에서 어떠한 위치에서 오류가 발생하더라도 서로 영향을 미치지 않아야 한다.

그러니 총 6개의 작업 중 하나의 <code>fail</code>이 난다면 5개의 작업만이 성공한 것이며, 그중 1개가 <code>fail</code>이 기에 실패한 케이스는 1개이라는 점이다.

F에서 exception이 발생하였다고 하더라도 C에는 영향을 미치지 않으며, A 역시 동작에 문제가 없다는 점이다.



<h2>그래도 궁금하잖아</h2>

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

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

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

정답은 간단하다.

<ul>
 <li>A는 영향받지 않는다.</li>
 <li>B는 D/E의 작업 실패에 대한 영향을 받는다.</li>
 <li>C는 B 또는 F의 작업에 영향받지 않는다.</li>
</ul>

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



<h2>간단한 원리</h2>

내부를 알아야 이 원리를 알 수 있는 건 아니다. 테스트해보고도 알 수 있긴 하다. 내부 코드 다 까보고 <code>SupervisorJob</code>을 알아야 하는 걸까? 거기에 가면 무슨 코드에 따라서 동작할까?

사실 더 깊이 갈 것도 없이 명확하게 아래와 같이 <code>childCancelled</code>란 코드를 바로 볼 수 있다.

Job과 딱 하나 다르다는 이야기다. 이를 활용하는 부분을 찾으려면 더 깊이 들어가 봐야겠지만 기본은 아래와 같다.

<div><pre><code>private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
 override fun childCancelled(cause: Throwable): Boolean = false
}
</code></pre></div>

D 작업에서 오류가 발생하였다면 D의 상위인 B Job에 통지가 간다. 이때 <code>childCancelled</code>의 정보를 무시할 것인지 결정하는 옵션에 따라 무시하거나, 예외 처리를 발생시키게 된다.

무시하면 통지 만 받는 것이며, 무시하지 않는다면 코드상 오류를 발생시키고, 상위로 또 전달한다.

Job을 상속받지 않는 것이지, 기본 cancelled 정보 전달 여부는 따른다는 것이다.

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

<div><pre><code>private val _parentHandle = atomic&lt;ChildHandle?&gt;(null)
internal var parentHandle: ChildHandle?
 get() = _parentHandle.value
 set(value) { _parentHandle.value = value }

override val parent: Job?
 get() = parentHandle?.parent
</code></pre></div>



<h2>마무리</h2>

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

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

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


 <hr>
 

<hr>
 </div></div>

꿈 많은 개발자가 되자 - Taehwan

이 글은 2025 안드로이드 탐구 영역에 나온 문제 중 일부를 해석하는 글의 형태로 작성합니다. 문제 전체를 담지 않고, 중요한 해설을 작성합니다.
안드로이드 탐구 영역 후기 글
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 { }
 }
 }
}
여기에서 어떠한 위치에서 오류가 발생하더라도 서로 영향을 미치지 않아야 한다.
그러니 총 6개의 작업 중 하나의 fail이 난다면 5개의 작업만이 성공한 것이며, 그중 1개가 fail이 기에 실패한 케이스는 1개이라는 점이다.
F에서 exception이 발생하였다고 하더라도 C에는 영향을 미치지 않으며, 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는 D/E의 작업 실패에 대한 영향을 받는다.
C는 B 또는 F의 작업에 영향받지 않는다.
이런 이유는 제미나이에서 설명한 Job의 예외 설명에서 충분히 잘 나온다.
간단한 원리
내부를 알아야 이 원리를 알 수 있는 건 아니다. 테스트해보고도 알 수 있긴 하다. 내부 코드 다 까보고 SupervisorJob을 알아야 하는 걸까? 거기에 가면 무슨 코드에 따라서 동작할까?
사실 더 깊이 갈 것도 없이 명확하게 아래와 같이 childCancelled란 코드를 바로 볼 수 있다.
Job과 딱 하나 다르다는 이야기다. 이를 활용하는 부분을 찾으려면 더 깊이 들어가 봐야겠지만 기본은 아래와 같다.
private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
 override fun childCancelled(cause: Throwable): Boolean = false
}
D 작업에서 오류가 발생하였다면 D의 상위인 B Job에 통지가 간다. 이때 childCancelled의 정보를 무시할 것인지 결정하는 옵션에 따라 무시하거나, 예외 처리를 발생시키게 된다.
무시하면 통지 만 받는 것이며, 무시하지 않는다면 코드상 오류를 발생시키고, 상위로 또 전달한다.
Job을 상속받지 않는 것이지, 기본 cancelled 정보 전달 여부는 따른다는 것이다.
지금 현재의 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의 중요성을 이해할 수 있는 간단한 문제입니다.

🤔 2025년도에도 개발자들은 코루틴 예외 처리 때문에 밤샘각? 😨 이 글 보면 완전 정복 가능(2025학년도 안드로이드 탐구영역 문제풀이)

댓글