그동안 레벨 1과 레벨 2, 두 번의 방학을 지나 대망의 레벨 3가 시작됐다. 우테코의 레벨 3에서는 팀 프로젝트를 진행한다.

다만 이번 8기의 프로젝트 진행 방식은 이전 기수와 달랐다. 이전까지는 팀을 먼저 구성한 뒤 팀에서 진행할 프로젝트의 주제를 정했다면, 이번에는 정반대의 순서로 진행됐다.

모든 크루가 방학 동안 일상에서 마주한 크고 작은 불편함을 수집한다. 이후 2주 동안 그 불편함을 어떻게 해결할 수 있을지, 다른 사람도 같은 불편함을 겪고 있는지, 생각한 해결 방법을 서비스로 만들었을 때 실제 사용자가 있을지를 검증한다. 팀 빌딩은 그다음인 3주 차에 진행된다.

이번 회고에서는 이 2주 동안 하나의 불편함에서 출발해 서비스를 구상하고 검증하면서 배우고 느낀 점을 이야기해 보려고 한다.

1. 불편함부터 떠올려 보자

레벨 2 방학 기간에 사전 과제로 ‘불편 일기’를 작성했다.

불편 일기란 일상생활을 하면서 “이건 해결되면 좋겠는데?”라고 느낀 크고 작은 불편함을 기록하는 일기다.

나는 불편 일기를 쓰는 것부터 쉽지 않았다. 인간은 적응의 동물이라고 했던가. 분명 불편하다고 느낀 순간이 있었을 텐데, 막상 글로 적으려니 떠오르는 것이 없었다.

2주간의 방학 중 첫 일주일을 어영부영 보내고, 방학이 거의 끝나갈 무렵이 되어서야 부랴부랴 몰아 쓰기 시작했다. 그렇게 총 10개의 불편함을 적었지만, 그중 프로젝트 주제로 발전시킬 만한 것은 두 개 정도였다.

나는 그중 다음과 같은 불편함을 프로젝트 주제로 선택했다.

길거리에서 택시를 잡아 타면 목적지를 설명하는 과정이 불편하다.

2. 무엇을 해결하려 했는가

나는 택시를 타야 할 일이 생기면 카카오 T를 애용한다.

택시가 정차해 있는 곳까지 직접 찾아갈 필요가 없고, 무엇보다 목적지를 미리 설정할 수 있어 탑승한 뒤 말로 설명하지 않아도 된다는 점이 편하기 때문이다.

반대로 말하면 카카오 T를 사용하지 않고 택시를 타면 목적지를 전달하는 과정이 불편하고 번거로워진다.

최근 시간이 촉박해 택시를 타야 했던 날이 있었다. 그런데 그날따라 카카오 T로 택시가 배차되지 않았다. 마음은 급한데 택시는 잡히지 않아 발만 동동 구르던 중, 마침 눈앞으로 빈 택시가 지나가 오랜만에 직접 택시를 잡아 탔다.

그런데 생각하지 못한 문제를 마주했다.

목적지를 말씀드렸지만 기사님은 그곳이 어디인지 모르셨다. 우아한형제들, 제2판교테크노밸리 등 여러 표현으로 설명해 봤지만 돌아오는 답은 같았다.

결국 기사님이 사용하시던 지도 앱의 음성 검색으로 목적지를 검색했다. 하지만 당시 나는 안경을 쓰고 있지 않아 검색 결과가 잘 보이지 않았다. 화면에 나열된 장소가 내가 가려는 곳이 맞는지도 확신하기 어려웠다.

결국 내 휴대폰으로 정확한 주소를 검색해 기사님께 다시 말씀드려야 했다.

이때 한 가지 생각이 들었다.

길거리에서 잡은 택시에서도 카카오 T처럼 승객이 설정한 목적지를 기사님께 바로 전달할 수 있다면 편하지 않을까?

3. 승객만 편해서는 성립하지 않는 서비스

2주 동안 아이디어를 발전시키면서 가장 기억에 남은 단어는 ‘양면 서비스’다.

양면 서비스란 서로 다른 두 이용자 집단을 연결해 상호작용을 돕고, 그 과정에서 가치를 만드는 서비스를 말한다.

내가 생각한 해결 방법의 핵심은 승객의 휴대폰에서 설정한 목적지를 택시 기사에게 빠르게 전달하는 것이었다.

본격적으로 서비스를 만들기 전에 같은 불편함을 느끼는 사람이 있는지, 서비스로 제공했을 때 실제로 사용할 의향이 있는지를 알아보기 위해 여러 크루를 인터뷰했다. 인터뷰를 통해 승객 입장에서는 목적지를 말로 전달하는 과정에 분명한 불편함이 있다는 것을 확인했다.

이때까지만 해도 아이디어가 잘 발전하고 있다고 생각했다. 그러다 문득 한 가지 의문이 들었다.

그런데 이걸 기사님 휴대폰에는 어떻게 설치하지?

기사님께 서비스를 어떻게 설치하게 만들 수 있을지 아무리 고민해도 답이 나오지 않았다. 결국 무작정 코치룸을 찾아가 도움을 요청했다.

그때 돌아온 답은 생각보다 간단했다.

그렇다면 택시 기사님을 인터뷰해 봐라.

내가 생각한 서비스가 동작하려면 승객과 택시 기사 양쪽의 요구가 맞아야 했다. 택시 기사 역시 길거리에서 승객을 태웠을 때 목적지를 설정하는 과정이 불편하다고 느껴야 했다.

기사님이 목적지 설정 과정에 불편함을 느끼지 않는다면 굳이 새로운 앱을 설치할 이유가 없다. 기사님 휴대폰에 서비스가 설치되지 않으면 승객이 아무리 사용하고 싶어도 서비스는 동작할 수 없다.

승객의 수요만 확인해서는 부족했다.

4. 택시 기사에게 직접 물어보기

이번에는 현직 택시 기사를 어떻게 인터뷰할 수 있을지 고민하기 시작했다.

가장 먼저 떠올린 방법은 지역 택시 조합에 연락하는 것이었다. 택시 조합을 찾아가면 현직 택시 기사의 이야기를 들을 수 있을 것 같았다.

성남시 택시 조합에 전화를 걸었고, 여러 연결을 거쳐 성남시 택시 조합장님과 대화할 수 있었다.

조합장님과의 대화를 통해 승객과 기사의 소통 오류로 인한 불편함이 실제로 존재한다는 사실은 확인할 수 있었다. 하지만 동시에 예상하지 못했던 사실도 알게 됐다.

카카오 T의 영향력은 생각보다 훨씬 컸다. 일반적인 거리에서는 직접 택시를 잡는 승객이 많지 않아 내가 생각한 서비스의 효과가 크지 않을 수 있다는 의견을 들었다.

또한 목적지를 설정할 때 소통 오류가 자주 발생하는 대상은 주로 연령대가 높은 승객이라고 했다.

여기서 새로운 고민이 생겼다.

목적지 전달에 어려움을 겪는 사람이 주로 고령층이라면, IT를 활용한 해결 방법이 과연 적절할까?

고령층과 소통 오류가 발생하는 이유 중 하나는 주소를 검색하는 것과 같은 기존의 디지털 해결 방법을 사용하기 어렵기 때문이다. 그렇다면 또 다른 디지털 서비스를 제공하는 것이 문제를 제대로 해결할 수 있을지 의문이 들었다.

서비스의 대상 사용자를 좁혀야 할지, 아니면 아예 다른 주제로 넘어가야 할지 많은 고민을 했다.

그러던 중 생각하지 못했던 대상이 떠올랐다. 바로 공항이나 터미널에서 택시를 이용하는 승객이었다.

공항이나 터미널에서는 카카오 T를 호출하는 것보다 택시 승강장에서 대기 중인 택시에 탑승하는 것이 더 빠를 수 있다. 특히 공항에는 외국인 승객도 많으므로 언어 장벽으로 인한 소통 문제가 더욱 분명하게 나타날 것이라고 생각했다.

초기 서비스 대상을 택시 승강장에서 대기하는 기사와 승객으로 한정한다면 카카오 T로 인한 수요 문제를 피하면서 서비스의 대상도 구체화할 수 있을 것 같았다.

하지만 이것 역시 내 머릿속에서 만들어진 가설에 불과했다. 택시 기사에게 실제 수요가 있는지는 여전히 확인하지 못한 상태였다.

그래서 더 고민하는 대신 판교역으로 가서 직접 확인해 보기로 했다.

5. 판교역 인터뷰 이후

우테코 판교 캠퍼스에서 판교역으로 택시를 타고 이동하며 기사님 한 분을 인터뷰했다. 이후 판교역에 정차해 있던 택시 기사 세 분을 추가로 인터뷰했다.

총 네 번의 인터뷰를 통해 다음 내용을 확인하고자 했다.

1. 길거리에서 직접 택시를 잡아 타는 승객의 비율은 어느 정도인가?
2. 기사들은 목적지를 찾을 때 음성 검색을 사용하는가?
3. 음성 검색만으로 목적지 설정 문제를 충분히 해결할 수 있는가?
4. 기사들은 승객에게 목적지를 말로 전달받는 과정을 불편하게 느끼는가?

표본이 많지는 않았지만, 인터뷰 결과는 분명했다.

내가 생각한 서비스에 대한 택시 기사의 수요는 예상대로 절망적이었다.

호출 앱을 사용하지 않고 직접 택시를 잡는 승객은 하루 전체 승객의 10%도 되지 않는다는 답변을 들었다. 또한 인터뷰한 기사님들은 목적지 전달 과정에서 소통 오류가 발생하더라도 음성 검색으로 충분히 해결하고 있었다.

음성 검색이 잘되지 않더라도 도로명주소를 검색하면 바로 찾을 수 있기 때문에 크게 불편하지 않다고 했다.

무엇보다 인상적이었던 점은 기사님들이 승객에게 목적지를 말로 전달받는 것을 ‘불편함’이 아니라 업무 과정에서 발생하는 ‘당연한 일’로 받아들이고 있다는 것이었다.

내가 구상한 서비스를 짧게 설명했을 때도 반응은 비슷했다.

있으면 편리할 수는 있지만, 굳이 새로운 앱을 설치하면서까지 사용할 것 같지는 않다는 답변을 들었다.

실제 택시 기사들의 이야기를 들은 뒤, 이 아이디어를 우테코 팀 프로젝트로 이어가기는 어렵다는 결론을 내렸다.

우테코에서는 이번 프로젝트를 통해 ‘실제 사용자가 있는 서비스’를 만들어 볼 것을 권장한다. 그런데 승객에게 서비스를 제공하기 위해 반드시 참여해야 하는 택시 기사들이 현재의 방식을 불편하다고 인식하지 않고 있었다.

그렇다면 적어도 지금의 형태로는 해결이 필요한 문제가 아니라고 판단했다.

다만 승객 입장에서는 목적지 전달 과정의 불편함이 존재한다는 것을 확인했다. 팀 프로젝트로 선택할 만큼의 수요를 검증하지는 못했지만, 문제를 기술적으로 풀어 보는 경험 자체는 의미가 있을 것 같아 작은 사이드 프로젝트로 만들어 볼 생각이다.

6. 앉아서 고민하는 대신 행동하기

2주 동안 하나의 아이디어를 우테코 프로젝트로 이어갈지 말지를 두고 정말 많은 고민을 했다.

다른 크루들은 하나의 아이디어를 빠르게 검증하고, 결과가 좋든 나쁘든 다음 주제로 넘어가며 여러 가능성을 확인한 것 같았다. 나는 그렇게 하지 못했다는 점에서 아쉬움이 남는다.

하지만 하나의 주제를 붙잡고 최대한 깊게 고민해 본 경험을 후회하지는 않는다.

수요에 대한 확신이 없다는 이유로 곧바로 포기하고 다른 주제로 넘어갔다면, 캠퍼스를 벗어나 외부 사람에게 직접 연락하고 인터뷰하는 경험은 하지 못했을 것이다.

이번 경험을 통해 내 생각에 의심이 생겼을 때는 앉아서 계속 고민하는 것보다 무엇을 확인해야 하는지 정하고 빠르게 행동하는 편이 모호함을 해소하는 데 훨씬 도움이 된다는 것을 체감했다.

물론 두렵지 않았던 것은 아니다.

길거리에서 모르는 사람에게 말을 걸어야 했기 때문에 이상한 사람으로 보이지 않을까 걱정했다. 아무도 인터뷰에 응해 주지 않으면 어떡하나 하는 걱정도 있었다.

하지만 이상한 사람으로 보이면 어떻고, 아무도 인터뷰에 응해 주지 않으면 어떤가.

행동하기 전에 했던 걱정은 대부분 실제로 일어나지도 않은 일이었다. 일어나지 않은 일을 걱정하며 행동을 미루기만 해서는 결국 아무것도 해결되지 않았다.

나태했다면 나태했고, 안일했다면 안일했던 2주였다. 그럼에도 머릿속에서만 맴돌던 가설을 직접 현장에 가져가 확인해 봤다는 점에서 의미 있는 시간이었다.

결국 이번 2주 동안 내가 얻은 것은 성공적인 프로젝트 아이디어가 아니었다.

대신 고민만으로는 알 수 없는 것이 있고, 그것을 알아내는 가장 빠른 방법은 직접 행동하는 것이라는 사실을 배웠다.

launch 함수와 async 함수는 매개변수로 context, start, block을 가진다.

여기서 context 매개변수를 살펴보자

앞서 다뤘던 내용 중에서 “3-4. CoroutineDispatcher 사용해 코루틴 실행하기” 파트가 있었다. 이 파트에서는 context 자리에 CoroutineDispatcher 객체가 사용되었다.

이 외에도 context 매개변수에 CoroutineName 객체를 사용할 수도 있다.

이 둘이 context 인자로 사용될 수 있는 이유는 이 두 객체가 CoroutineContext 객체의 구성 요소이기 때문이다.

CoroutineContext는 코루틴을 실행하는 실행 환경을 설정하고 관리하는 인터페이스로 CoroutineDispatcher, CoroutineName, Job 등의 객체를 조합해 코루틴의 실행 환경을 설정한다.

즉, CoroutineContext 객체는 코루틴을 실행하고 관리하는데 핵심적인 역할을 하며, 코루틴의 실행과 관련된 모든 설정은 CoroutineContext 객체를 통해 이뤄진다.

6장에서 다루는 내용

• CoroutineContext의 구성 요소
• CoroutineContext 구성 방법
• CoroutineContext 구성 요소에 접근하기
• Coroutinecontext 구성 요소를 제거하는 방법

1. CoroutineContext의 구성 요소

CoroutineContext 객체는 CoroutineName, CoroutineDispatcher, Job, CoroutineExceptionHandler의 네 가지 주요한 구성 요소를 가지며, 이들 구성 요소는 다음과 같은 역할을 한다.

1. CoroutineName → 코루틴의 이름을 설정
2. CoroutineDispatcher → 코루틴을 스레드에 할당해 실행
3. Job → 코루틴의 추상체로 코루틴을 조작하는데 사용
4. CoroutineExceptionHandler → 코루틴에서 발생한 예외를 처리

이들 이외에도 다양한 구성요소가 있지만 주로 이 4가지 구성 요소를 사용해 코루틴을 실행시키기 때문에 이들을 중심으로 살펴본다.

2. CoroutineContext 구성하기

2-1. CoroutineContext가 구성 요소를 관리하는 방법

CoroutineContext 객체는 키-값 쌍으로 각 구성 요소를 관리한다.

• 각 구성 요소는 고유한 키를 가짐
• 키에 중복된 값은 허용되지 않음

CoroutineContext 객체는 각 구성 요소를 한 개씩만 가질 수 있음

2-2. CoroutineContext 구성

CoroutineContext 객체에 구성 요소를 추가하는 방법에 대해 살펴본다.

CoroutineContext 객체는 키-값 쌍으로 구성 요소를 관리하지만 키에 값을 직접 대입하는 방법을 사용하지 않는다.

대신 CoroutineContext 객체 간에 더하기 연산자를 통해 CoroutineContext 객체를 구성한다.

val coroutineContext: CoroutineContext = 
    newSingleThreadContext("MyThread1") + CorotineName("MyCoroutine")

• newSingleThreadContext(”MyThread1”) → CoroutineDispatcher 객체 생성
• CoroutineName(”MyCoroutine”) → CoroutineName 객체 생성

이렇게 만들어진 CoroutineContext 객체는 다음과 같은 형태가 된다.

만들어진 CoroutineContext 객체는 코루틴 빌더 함수의 context 인자로 넘겨 코루틴을 실행하는데 사용할 수 있다.

fun main() = runBlocking<Unit> {
    val coroutineContext: CoroutineContext = 
        newSingleThreadContext("MyThread") + CoroutineName("MyCoroutine")

    launch(context = coroutineContext) {
        println("[${Thread.currentThread().name}] 실행")
    }
}

// [MyThread @MyCoroutine#2] 실행

• 실행 결과를 통해 coroutineContext 객체의 구성 요소를 사용해 코루틴이 실행 되었음을 알 수 있다.

2-3. CoroutineContext 구성 요소 덮어씌우기

CoroutineContext 객체에 같은 구성 요소가 둘 이상 더해지면 나중에 추가된 구성 요소가 이전의 값을 덮어씌운다.

fun main() = runBlocking<Unit> {
    val coroutineContext: CoroutineContext = 
        newSingleThreadContext("MyThread") + CoroutineName("MyCoroutine")

    val newCoroutineContext: CoroutineContext = 
        coroutineContext + CoroutineName("NewCoroutine")

    launch(context = coroutineContext) {
        println("[${Thread.currentThread().name}] 실행")
    }
}

// [MyThread @NewCoroutine#2] 실행

• launch 코루틴이 사용하는 MyThread로 유지
• 코루틴의 이름은 NewCoroutine으로 변경됨

코루틴의 이름이 변경된 이유는 CoroutineContext 객체의 각 구성 요소는 고유한 키를 갖고 있으므로 만약 같은 구성 요소에 대해 여러 객체가 입력되면 가장 나중에 들어온 값이 앞의 값을 덮어씌우기 때문이다.

2-4. 여러 구성 요소로 이뤄진 CoroutineContext 합치기

여러 구성 요소로 이뤄진 CoroutineContext 객체 2개가 합쳐지고 2개의 CoroutineContext 객체에 동일한 키를 가진 구성 요소가 있다면 나중에 들어온 값이 선택된다.

이를 확인하기 위해 newSingleThreadContext() 함수로 2개의 CoroutineContext 객체를 만들어 두 객체를 합쳐보자

val coroutineContext1 = CoroutineName("MyCoroutine1") + newSingleThreadContext("MyThread1")
val coroutineContext1 = CoroutineName("MyCoroutine2") + newSingleThreadContext("MyThread2")
val combinedCoroutineContext = coroutineContext1 + coroutineContext2

• coroutineContext1에 coroutineContext2 객체가 더해지므로 coroutineContext1의 구성 요소가 coroutineContext2의 구성 요소로 덮어씌워짐

위의 예시에서는 두 CoroutineContext 객체가 동일한 구성 요소들을 갖고있었기 때문에 coroutineContext1의 구성 요소들이 coroutineContext2의 구성요소로 덮어씌워졌다.

만약 coroutineContext1이 coroutineContext2가 갖고있지 않은 구성요소를 갖고 있었다면 해당 구성 요소는 덮어씌워지지 않았을 것이다.

2-5. CoroutineContext에 Job 생성해 추가하기

Job 객체는 기본적으로 코루틴 빌더 함수를 통해 자동으로 생성된다.

하지만 Job() 함수를 직접 호출해 생성할 수도 있다.

val myJob = Job()
val coroutineContext: CoroutineContext = Dispatchers.IO + myJob

이 코드를 통해 생성된 coroutineContext는 다음과 같은 구조를 가진다.

다만 Job 객체를 직접 생성해 추가하면 코루틴의 구조화가 깨질 수 있다. 따라서 새로운 Job 객체를 생성해 CoroutineContext 객체에 추가하는 것은 주의가 필요하다.

이에 대해서는 7장. 구조화된 동시성에서 자세히 다룰 예정이다.

3. CoroutineContext 구성 요소에 접근하기

CoroutineContext 객체의 구성 요소에 접근하기 위해서는 각 구성 요소가 가진 고유한 키가 필요하다.

각 구성 요소의 키를 얻는 방법부터 알아보자

3-1. CoroutineContext 구성 요소의 키

CoroutineContext 구성 요소의 키는 CoroutineContext.Key 인터페이스를 구현해 만들 수 있다.

일반적으로 CoroutineContext 구성 요소는 자신의 내부에 키를 싱글톤 객체로 구현한다.

public data class CoroutineName.Element {
    public companion object Key: CoroutineContext.Key<CoroutineName>
    ...
}

CoroutineName 클래스 내부에 CoroutineContext.Key을 구현하는 Key 객체가 Companion Object로 선언되어 있는 것을 볼 수 있다.

이 Key를 사용하면 CoroutineContext에서 CoroutineName에 접근할 수 있다.

public interface Job: CoroutineContext.Element {
    public companion object Key: CoroutineContext.Key<Job>
}

Job 인터페이스의 내부에도 Key가 Companion Object로 선언된 것을 볼 수 있다.

이는 CoroutineDispatcher와 CoroutineExceptionHandler도 마찬가지다.

3-2. 키를 사용해 CoroutineContext 구성 요소에 접근하기

1. 싱글톤 키를 사용해 CoroutineContext 구성 요소에 접근하기

fun main() = runBlocking<Unit> {
    val coroutineContext = CoroutineName("MyCoroutine") + Dispatchers.IO
    val nameFromContext = coroutineContext[CoroutineName.Key]
    println(nameFromContext)
}

// CoroutineName(MyCoroutine)

이 코드에는 CoroutineName(”MyCoroutine”)과 Dispatchers.IO로 이뤄진 coroutineContext가 있다.

coroutineContext에 연산자 함수 get(대괄호 대체)의 인자로 CoroutineName.Key를 넘김으로써 coroutineContext를 구성하는 CoroutineName 객체만 가져올 수 있다.

2. 구성 요소 자체를 키로 사용해 구성 요소에 접근하기

CoroutineContext의 주요 구성 요소인 CoroutineName, Job, CoroutineDispatcher, CoroutineExceptionHandler 객체는 Companion Object로 CoroutineContext.Key를 갖고 있기 때문에 Key를 명시적으로 사용하지 않아도 구성 요소 자체를 키로 사용할 수 있다.

따라서 굳이 뒤에 “.Key”를 붙이지 않아도 구성 요소에 접근할 수 있다.

fun main() = runBlocking<Unit> {
    val coroutineContext = CoroutineName("MyCoroutine") + Dispatchers.IO
    val nameFromContext = coroutineContext[CoroutineName]
    println(nameFromContext)
}

// CoroutineName(MyCoroutine)

연산자 함수 get의 인자로 넘긴 인자의 “.Key”를 제거했지만 출력 결과는 동일한 것을 확인할 수 있다.

3. 구성 요소의 key 프로퍼티를 사용해 구성 요소에 접근하기

CoroutineContext 객체의 구성 요소들은 모두 key 프로퍼티를 가진다.

이 key 프로퍼티를 사용해 구성 요소에 접근할 수 있다.

fun main() = runBlocking<Unit> {
    val coroutineName: CoroutineName = CoroutineName("MyCoroutine")
    val dispatcher: CoroutineDispatcher = Dispatchers.IO
    val coroutineContext = coroutineName + dispatcher

    println(coroutineContext[coroutineName.key])
    println(coroutineContext[dispatcher.key])
}

// CoroutineName(MyCoroutine)
// Dispatchers.IO

coroutineContext를 구성하는데 사용된 coroutineName과 dispatcher 객체의 key 프로퍼티를 통해 CoroutineContext 객체의 구성 요소에 접근할 수 있음을 알 수 있다.

여기서 중요한 점은 구성 요소의 key 프로퍼티는 Companion Object로 선언된 Key와 동일한 객체를 가리킨다는 것이다.

coroutineName.key와 CoroutineName.Key는 동일한 대상을 가리킨다.

fun main() = runBlocking<Unit> {
    val coroutineName = CoroutineName("MyCoroutine")

    if (coroutineName.key === CoroutineName.Key)
        println("coroutineName.key와 CoroutineName.Key 동일합니다.")
}

// coroutineName.key와 CoroutineName.Key 동일합니다.

동일성 연산자를 통해 coroutineName.key와 CoroutineName.Key가 동일한 객체를 가리킴을 확인할 수 있다.

4. CoroutineContext 구성 요소 제거하기

CoroutineContext 객체는 구성 요소를 제거하기 위한 minusKey 함수를 제공한다.

구성 요소의 Key를 인자로 받아 해당 구성 요소를 제거한 CoroutineContext 객체를 반환한다.

4-1. minusKey 함수를 사용해 구성 요소 제거하기

val coroutineName = CoroutineName("MyCoroutine")
val dispatcher = Dispatchers.IO
val myJob = Job()
val coroutineContext: CoroutineContext = coroutineName + dispatcher + myJob

이 coroutineContext에서 CoroutineName 객체를 제거하기 위해서는 coroutineContext에 대해 minusKey 함수를 호출하고 coroutineName을 인자로 넘기면 된다.

이 경우 coroutineContextdptj CoroutineName만 제거돼 반환되며, 반환된 coroutineContext는 deletedCoroutineContext에 할당된다.

fun main() = runBlocking<Unit> {
    val coroutineName = CoroutineName("MyCoroutine")
    val dispatcher = Dispatchers.IO
    val myJob = Job()
    val coroutineContext: CoroutineContext = coroutineName + dispatcher + myJob

    val deletedCoroutineContext = coroutineContext.minusKey(CoroutineName)

    println(deletedCoroutineContext[CoroutineName])
    println(deletedCoroutineContext[CoroutineDispatcher])
    println(deletedCoroutineContext[Job])
}

// null
// Dispatchers.IO
// JobImple{Active}@65e2dbf3

코드의 출력 결과를 보면 coroutineDispatcher의 CoroutineName이 제거되 null이 출력되고 나머지는 정산적으로 출력되는 것을 확인할 수 있다.

4-2. minusKey 함수 사용시 주의할 점

minusKey를 호출한 CoroutineContext 객체는 유지되고, 구성 요소가 제거된 새로운 CoroutineContext 객체가 반환된다.

fun main() = runBlocking<Unit> {
    val coroutineName = CoroutineName("MyCoroutine")
    val dispatcher = Dispatchers.IO
    val myJob = Job()
    val coroutineContext: CoroutineContext = coroutineName + dispatcher + myJob

    val deletedCoroutineContext = coroutineContext.minusKey(CoroutineName)

    println(coroutineContext[CoroutineName])
    println(coroutineContext[CoroutineDispatcher])
    println(coroutineContext[Job])
}

// CoroutineName(MyCoroutine)
// Dispatchers.IO
// JobImple{Active}@65e2dbf3

코드의 실행 결과를 보면 minusKey 함수가 호출된 coroutineContext는 구성 요소가 제거되지 않기 때문에 CoroutineName 객체가 제거되지 않은 것을 확인할 수 있다.

5. 요약

1. CoroutineContext 객체는 코루틴의 실행 환경을 설정하고 관리하는 객체로 CoroutineDispatcher, CoroutineName, Job, CoroutineExceptionHandler 등의 객체를 조합해 코루틴 실행 환경을 정의한다.
2. CoroutineName 객체 → 코루틴의 이름 설정
3. CoroutineDispatcher 객체→ 코루틴을 스레드로 보내 실행
4. Job 객체 → 코루틴을 조작하는데 사용
5. CoroutineExceptionHandler → 코루틴의 예외를 처리
6. CoroutineContext 객체는 키-값 쌍으로 구성 요소를 관리하며, 동일한 객체에 대해 중복을 허용하지 않는다.
7. 더하기 연산자(+)를 통해 CoroutineContext의 구성 요소를 조합할 수 있다.
8. 동일한 키를 가진 구성 요소가 여러개 추가될 경우 나중에 추가된 구성 요소가 이전 값을 덮어씌운다.
9. 일반적으로 구성 요소의 Companion Object로 선언된 Key 프로퍼티를 사용해 키 값에 접근할 수 있다. 예를 들어 CoroutineName의 키 값은 CoroutineName.Key를 통해 접근할 수 있다.
10. 키를 연산자 함수 get과 사용해 CoroutineContext 객체를 구성하는 요소에 접근할 수 있다.
11. CoroutineName, CoroutineDispatcher, CoroutineExceptionHandler는 Companion Object인 Key를 통해 CoroutineContext.Key를 구현하기 때문에 그 자체를 키로 사용할 수 있다.
12. CoroutineContext 객체의 minusKey 함수를 사용하면 CoroutineContext 객체에서 특정 구성 요소를 제거한 객체를 반환받을 수 있다.

하지만 네트워크 통신과 같이 코루틴을 통해 비동기로 실행하는 작업의 경우 결과를 수신받아야 하는 경우가 많음

코루틴 라이브러리는 비동기 작업으로 부터 결과를 수신해야 하는 경우를 위해 async 코루틴 빌더를 제공함

launch 코루틴 빌더 함수 → 걀괏값이 없는 코루틴 객체인 Job을 반환

async 코루틴 빌더 함수 → 결괏값이 있는 코루틴 객체인 Deferred를 반환

5장에서 다루는 내용

• async-await을 사용해 코루틴으로부터 결괏값 수신하기
• awaitAll 함수를 사용해 복수의 코루틴으로부터 결괏값 수신
• withContext를 사용해 실행 중인 코루틴의 CoroutineContext 변경하기

1. async 사용해 결괏값 수신하기

1-1. async 사용해 Deferred 만들기

// async 빌더 함수 선언부
public fun <T> CoroutineScope.asycn(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> T
): Deferred<T>

• async 함수도 launch 함수와 마찬가지로 context 인자로 CoroutineDispatcher를 설정할 수 있음
• start 인자로 CoroutineStart.LAZY를 설정해 코루틴이 지연 시작되도록 할 수 있음
• 코루틴에서 실행할 코드를 작성하는 block 람다식을 가짐

launch 코루틴 빌더는 코루틴에서 결괏값이 반환되지 않기 때문에 Job 객체를 반환함

async 코루틴 빌더는 코루틴에서 결괏값을 담아 반환하기 위해 Deferred 타입의 객체를 반환함

Deferred 객체는 Job 객체와 마찬가지로 코루틴을 추상화한 객체이지만 코루틴으로부터 생성된 결괏값을 감싸는 기능을 추가로 가지며, 이 결괏값의 타입은 제네릭 타입인 T로 표현됨

Deferred 객체의 반환값 타입을 지정하기 위해선 Deferred에 명시적으로 타입을 설정하거나 async 블록의 반환값으로 반환할 결괏값을 설정하면 됨

val networkDeferred: Deferred<String> = async(Dispatchers.IO) {
    delay(1000L)
    return@async "Dummy Response"
}

1-2. await을 사용한 결괏값 수신

Deferred 객체 → 미래의 어느 시점에 결괏값이 반환될 수 있음을 표현하는 코루틴 객체임

코루틴이 실행 완료될 때 결괏값이 발생하므로 언제 결괏값이 반환될지 정확히 알 수 없으며, 결괏값이 필요한 경우 결괏값이 수신될 때까지 대기해야 함

Deferred 객체 → 결괏값의 수신을 위해 await 함수를 제공

await 함수는 await의 대상이 된 Deferred 코루틴이 실행 완료될 때까지 await 함수를 호출한 코루틴을 일시 중단, Deferred 코루틴이 실행 완료되면 결괏값을 반환하고 호출부의 코루틴을 재개함

코루틴의 실행이 완료될 때까지 대기한다는 점에서 Job 객체의 Join함수와 매우 유사하게 동작함

fun main() = runBlocking<Unit> {
    val networkDeferred: Deferred<String> = async(Dispatchers.IO) {
        delay(1000L)
        return@async "Dummy Response"
    }

    val result = networkDeferred.await()
    println(result)
}

networkDeferred.await()를 호출하면 networkDeferred 코루틴이 완료될 때까지 runBlocking 코루틴이 일시 중단됨

이후 networkDeferred 코루틴으로부터 “Dummy Response”가 반환되면 runBlocking 코루틴이 재개되며, “Dummy Response”는 result 변수에 할당됨

println(result)를 통해 “Dummy Response”가 출력됨

2. Deferred는 특수한 형태의 Job이다.

4장에서 모든 코루틴 빌더는 Job 객체를 생성한다고 언급했었다.

하지만 await 코루틴 빌더는 Deferred 객체를 반환한다.

그렇다고 await 코루틴 빌더가 특별한 코루틴 객체를 반환하는 것은 아니다.

Deferred 객체는 Job 객체의 특수한 형태로 Deferred 인터페이스는 Job 인터페이스의 서브타입으로 선언된 인터페이스다.

Deferred 객체는 코루틴으로부터 결괏값 수신을 위해 Job 객체에 몇 가지 기능.이 추가되었을 뿐, 여전히 Job 객체의 일종이다.

// Deferred 인터페이스의 선언부

public interface Deferred<out T>: Job {
    public suspend fun await(): T
    ...
}

Deferred 인터페이스가 Job 인터페이스의 서브 타입으로 선언되었기 때문에 Deferred 객체는 Job 객체의 모든 프로퍼티를 사용할 수 있다.

Join을 사용해 Deferred 객체가 완료될 때까지 호출부의 코루틴을 일시 중단할 수도 있도, Deferred 객체가 취소돼야 할 경우 cancel 함수를 호출해 취소할 수 도 있다.

isActive, isCancelled, isCompleted와 같은 상태 프로퍼티도 사용할 수 있다.

정리하자면 Deferred 객체는 결괏값을 받는 기능이 추가된 Job 객체이며, Job 객체의 모든 함수와 변수를 사용할 수 있다. (특수한 형태의 Job)

3. 복수의 코루틴으로부터 결괏값 수신하기

프로그램을 만들 때 여러 비동기 작업으로부터 결괏값을 반환받아 병합해야 하는 경우가 자주 생긴다.

3-1. await을 사용해 복수의 코루틴으로부터 결괏값 수신하기

콘서트 개최 시 관람객을 2개의 플래폼에서 모집하는 상황 → 각 플랫폼에 등록된 관람객을 조화한 후 병합해야 함

fun main() = runBlocking<Unit> {
    val startTime = System.currentTimeMillis()
    val participantDeferred1: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        return@async arrayOf("James", "Jason")
    }
    val participants1 = participantDeferred1.await()

    val participantDeferred2: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        return@async arrayOf("Jenny")
    }
    val participants2 = participantDeferred2.await()

    println("[${getElapsedTime(startTime)}] 참여자 목록: ${listOf(*participants1, *participants2)}")
}

// [지난 시간" 2018ms] 참여자 목록: [Jamse, Jason, Jenny]

• 별표(*)가 쓰인 이유 ➡️ 배열을 vararg 인자로 펼칠 때 필요

1. 시작시 startTime 변수에 시작 시간을 기록
2. participantDeferred1 코루틴을 통해 플랫폼1에서 등록한 관람객 목록을 가져옴
3. participantDeferred1.await()을 통해 플랫폼1의 서버로부터 결과가 수신될 때까지 대기
4. participantDeferred2 코루틴을 통해 플랫폼2에서 등록한 관람객 목록을 가져옴
5. participantDeferred2.await()을 통해 플랫폼2의 서버로부터 결과가 수실될 때까지 대기
6. 모든 작업을 마친 후 참여자 목록을 병합해 출력

코드의 실행결과를 통해 참여자 목록이 병합되고 각 서버를 호출하는데 1초씩 걸려 총 2초의 시간이 걸리는 것을 확인할 수 있음

서버 호출이 총 2초가 걸린 이유 → await을 호출하면 결괏값이 반환될 때까지 호출부의 코루틴이 일시 중단되기 때문

Dispatchers.IO를 사용해 백그라운드 스레드에서 코루틴을 실행하더라도 await를 호출하면 코루틴이 실행 완료될 때까지 runBlocking 코루틴이 일시 중단돼 대기하게 됨

따라서 participantDeferred1.await()가 participantDeferred2 코루틴이 생성되기 전에 호출되면 participantDeferred2 코루틴은 순차적으로 처리됨

두 작업은 동시에 독립적으로 실행될 수 있는 작업임에도 순차적으로 처리되는 건 비효율적임

이 문제를 해결하려면 await()의 호출 시점을 두 코루틴이 모두 생성된 이후로 변경하면 된다.

fun main() = runBlocking<Unit> {
    val participantDeferred1: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        return@async arrayOf("James", "Jason")
    }

    val participantDeferred2: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        return@async arrayOf("Jenny")
    }

    val participants1 = participantDeferred1.await()
    val participants2 = participantDeferred2.await()

    println("[${getElapsedTime(startTime)}] 참여자 목록: ${listOf(*participants1, *participants2)}")
}

// [지난 시간" 1018ms] 참여자 목록: [Jamse, Jason, Jenny]

participantDeferred1.await()가 호출되기 전에 participantDeferred2 코루틴이 실행되므로 두 코루틴이 동시에 실행됨

두 코루틴이 동시에 실행될 수 있도록하는 것은 코루틴의 성능 측면에서 매우 중요함

await의 호출 시점에 따라 코루틴이 순차적으로 처리될 수도 있고 동시에 처리될 수 있을을 유의해야 한다.

3-2. awaitAll 사용한 결괏값 수신

앞의 콘서트 관람객 예시에서는 관람객을 등록받는 플랫폼의 개수가 적었다. 만약 플랫폼의 개수가 100개로 늘어난다면 어떨까?

각 코루틴의 결과를 반환받기 위해 100개의 await()를 호출해야할까? 다행히도 그렇지 않다.

코루틴 라이브러리는 복수의 Deferred 객체로부터 결괏값을 수신하기 위한 awaitAll() 함수를 제공한다.

public suspend fun <T> awaitAll(vararg deferreds: Deferred<T>): List<T>

awaitAll 함수의 구현부를 보면 가변 인자로 Deferred 타입의 객체를 받아 인자로 받은 모든 Deferred 코루틴으로부터 결과가 수신될 때까지 호출부의 코루틴을 일시 중단한 후 결과가 모두 수신되면 Deferred 코루틴들로부터 수신한 결괏값들로 List를 만들어 반환하고 호출부의 코루틴을 재개한다.

participantDeferred1과 participantDeferred2의 예시에 awaitAll() 함수를 적용해보자

fun main() = runBlocking<Unit> {
    val startTime = System.currentTimeMillis()
    val participantDeferred1: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        arrayOf("James", "Jason")
    }

    val participantDeferred2: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        arrayOf("Jenny")
    }

    val results: List<Array<String>> = awaitAll(participantDeferred1, participantDeferred2)

    println("[${getElapsedTime(startTime)}] 참여자 목록: ${listOf(*results[0], *results[1])}")
}

// [지난 시간: 1013ms] 참여자 목록: [Jamse, Jason, Jenny]

runBlocking 코루틴에서 awaitAll() 함수가 호출되면 awaitAll() 함수의 인자로 전달된 코루틴들의 실행이 모두 완료될 때까지 runBlocking 코루틴이 일시 중단된다.

이후 인자로 전달된 코루틴들의 실행이 완료되면 결과들이 리스트로 만들어져 반화되고 runBlocking의 코루틴이 재개된다.

3-3. 컬렉션에 대해 awaitAll 사용하기

awaitAll 함수 → Collection 인터페이스에 대한 확장 함수로도 제공함

public suspend fun <T> Collection<Deferred<T>>.awaitAll(): List<T>

Collection<Deferred>에 대해 awaitAll() 함수를 호출하면 컬렉션에 속한 Deferred 객체들의 코루틴이 모두 완료돼 결괏값을 반환할 때까지 대기한다.

fun main() = runBlocking<Unit> {
    val startTime = System.CurrentTimeMillis()
    val participantDeferred1: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        arrayOf("James", "Jason")
    }

    val participantDeferred2: Deferred<Array<String>> = async(Dispatchers.IO) {
        delay(1000L)
        arrayOf("Jenny")
    }

    val results: List<Array<String>> = listof(participantDeferred1, participantDeferred2).awaitAll()

    println("[${getElapsedTime(startTime)}] 참여자 목록: ${listOf(*results[0], *results[1])}")
}

// [지난 시간: 1015ms] 참여자 목록: [Jamse, Jason, Jenny]

가변 인자를 받는 awaitAll() 함수를 사용한 것과 완전히 같게 동작한다.

4. withContext

4-1. withContext로 async-await 대체하기

public suspend fun <T> withContext(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T
): T

withContext 함수가 호출되면 함수의 인자로 설정된 CoroutineContext 객체를 사용해 block 람다식을 실행하고, 완료되면 그 결과를 반환한다.

withContext 함수를 호출한 코루틴은 인자로 받은 CoroutineContext 객체를 사용해 block 람다식을 실행하며, block 람다식을 모두 실행하면 다시 기존의 CoroutineContext 객체를 사용해 코루틴이 재개된다.

이 동작은 async-await 쌍을 연속적으로 실행했을 때의 동작과 매우 유사하다.

fun main() = runBlocking<Unit> {
    val networkDeferred: Deferred<String> = async(Dispatchers.IO) {
        delay(1000L)
        "Dummy Response"
    }

    val result = networkDeferred.await()
    println(result)
}

// Dummy Response

이 코드에서는 async 함수를 호출해 Deferred 객체를 만들고, 곧바로 Deferred 객체에 대해 await 함수를 호출한다.

이런 async 함수를 호출한 후 연속적으로 await 함수를 호출해 연속적으로 결괏값 수신을 대기하는 코드는 withContext 함수로 대체할 수 있다.

fun main() = runBlocking<Unit> {
    val result: String = withContext(Dispatchers.IO) {
        delay(1000L)
        return@withContext "Dummy Response"
    }

    println(result)
}

// Dummy Response

async-await 쌍이 withContext 함수로 대체되면 Deferred 객체가 생성되는 부분이 없어지고 “Dummy Response”가 결과로 바로 반환된다.

4-2. withContext의 동작 방식

withContext 함수는 async-await 쌍과 비슷하게 동작하는 것처럼 보이지만 내부적으로 보면 다르게 동작한다.

async-await 쌍은 새로운 코루틴을 생성해 작업을 처리하지만 withContext 함수는 실행 중이던 코루틴을 그대로 유지한 채로 코루틴의 실행 환경만 변경해 작업을 처리한다.

fun main() = runBlocking<Unit> {
    println("[${Thread.currentThread().name]] runBlocking 블록 실행")
    withContext(Dispatchers.IO) {
        println("[${Thread.currentThread().name]] withContext 블록 실행")
    }
}

/*
[main @coroutine#1] runBlocking 블록 실행
[DefaultDispatcher-worker-1 @coroutine#1] withContext 블록 실행
*/

코드의 실행 결과를 보면 runBlocking 함수의 block 람다를 실행하는 스레드와 withContext 함수의 block 람다식을 실행하는 스레드는 main과 DefaultDispatcher-worker-1 로 다르지만 코루틴은 coroutine#1으로 같은 것을 확인할 수 있다.

withContext 함수는 새로운 코루틴을 만드는 개신 기존의 코루틴에서 CoroutineContext 객체만 바꿔서 실행하는 것을 알 수 있다.

위의 예시에서는 CoroutineContext 객체가 Dispatchers.IO로 바뀌었기 때문에 백그라운드 스레드에서 실행됐다.

다만 CoroutineContext 객체에 대해 아직 다루지 않았기 때문에 “CoroutineContext가 변경됐다.”는 표현을 “코루틴을 실행시키는 CoroutineDispatcher 객체가 변경돼 코루틴의 실행 스레드가 변화한다.”라고 이해하는 것이 좋다. CoroutineContext 객체에 대해서는 추후에 다룰 예정이다.

withContext 함수가 호출되면 실행 중인 코루틴의 실행 환경이 withContext 함수의 context 인자 값으로 변경돼 실행되며, 이를 컨텍스트 스위칭(context switching)이라고 부른다.

context 인자로 coroutineDispatcher 객체가 넘어오면 코루틴은 해당 CoroutineDispatcher 객체를 사용해 다시 실행된다.

withContext 함수는 함수의 block 람다식이 실행되는 동안 코루틴의 실행 환경을 변경시킨다.

withContext 함수가 block 람다식을 벗어나면 다시 원래의 CoroutineContext 객체를 사용해 실행된다.

fun main() = runBlocking<Unit> {
    println("[${Thread.currentThread().name]] runBlocking 블록 실행")
    async(Dispatchers.IO) {
        println("[${Thread.currentThread().name]] withContext 블록 실행")
    }.await()
}

/*
[main @coroutine#1] runBlocking 블록 실행
[DefaultDispatcher-worker-1 @coroutine#2] withContext 블록 실행
*/

이 코드의 실행 결과를 보면 async 블록을 실행하는 코루틴은 coroutine#2로 runBlocking 블록을 실행하는 coroutine#1과 다른 것을 확인할 수 있다.

async-await 쌍을 사용하면 새로운 코루틴을 만들지만 await 함수가 호출돼 순차 처리 되기 때문에 동기적으로 실행된다.

4-3. withContext 사용 시 주의점

withContext 함수 → 새로운 코루틴을 만들지 않기 때문에 하나의 코루틴에서 withContext 함수가 여러 번 호출되면 순차적으로 실행됨 (withContext 여러개를 한 코루틴에서 호출하면 성능 문제가 발생할 수 있음)

fun main() = runBlocking<Unit> {
    val startTime = System.currentTimeMillis()
    val helloString = withContext(Dispatchers.IO) {
        delay(1000L)
        return@withContext "Hello"
    }
    val worldString = withContext(Dispatchers.IO) {
        delay(1000L)
        return@withContext "World"
    }

    println("[${getElapsedTime(startTime)} ${helloString} ${worldString}")
}

// [지난 시간: 2018ms] Hello World

“Hello” 문자열과 “World”문자열을 반환하는 두 코루틴이 순차 처리되어 총 2초의 실행 시간이 걸린 것을 확인할 수 있다.

위의 코드에선 runBlocking 함수에 의해 하나의 코루틴만 생성된다.

이후 withContext 함수를 사용해 코루틴을 유지한 채로 실행 스레드풀만 Dispatchers.IO로 변경된다.

따라서 1초 동안 대기한 후 문자열을 반환받는 두 작업이 한 코루틴에서 순차적으로 처리되어 총 2초 정도의 시간이 걸리는 것이다.

이는 withContext 함수가 새로운 코루틴을 생성하지 않기 때문에 생기는 문제다.

이 문제를 async-await 쌍으로 해결해보자

fun main() = runBlocking<Unit> {
    val startTime = System.currentTimeMillis()
    val helloDeferred = async(Dispatchers.IO) {
        delay(1000L)
        return@async "Hello"
    }
    val worldDeferred = async(Dispatchers.IO) {
        delay(1000L)
        return@async "World"
    }

    val results = awaitAll(helloDeferred, worldDeferred)

    println("[${getElapsedTime(startTime)}] ${results[0]} ${results[1]}")
}

// [지난 시간: 1013ms] Hello World

HelloDeferred와 WorldDeferred가 모두 실행된 뒤에 awaitAll 함수를 호출해 여러 async 코루틴의 결괏값을 반환받는다.

두 코루틴이 병렬로 처리된 후 한번에 결괏값을 반환받기 때문에 총 1초 정도의 시간이 걸린 것을 확인할 수 있다.

그림에서는 백그라운드 스레드가 2개 사용되었지만 코루틴은 스레드를 사용하지 않을 때는 스레드를 양보하기 때문에 백그라운드 스레드를 하나만 사용할 수도 있다.

withContext 함수를 사용하면 코드가 깔끔해지는 효과를 낼 수 있지만 잘못 사용하면 코루틴이 동기적으로 실행될 수 있어 사용시 주의가 필요하다.

4-추가 자료. withContext를 사용한 코루틴 스레드 전환

private val myDispatcher1 = newSingleThreadContext("MyThread1")
private val myDispatcher2 = newSingleThreadContext("MyThread2")

fun main() = runBlocking<Unit> {
    println("[${Thread.currentThread().name}] 코루틴 실행")
    withContext(myDispatcher1) {
        println("[${Thread.currentThread().name}] 코루틴 실행")
        withContext(myDispatcher2) {
            println("[${Thread.currentThread().name}] 코루틴 실행")
        }
        println("[${Thread.currentThread().name}] 코루틴 실행")
    }
    println("[${Thread.currentThread().name}] 코루틴 실행")
}

/*
[main @coroutine#1] 코루틴 실행
[MyThread1 @coroutine#1] 코루틴 실행
[MyThread2 @coroutine#1] 코루틴 실행
[MyThread1 @coroutine#1] 코루틴 실행
[main @coroutine#1] 코루틴 실행
*/

코드의 실행 결과를 보면 모든 코루틴이 @coroutine#1인데 스레드 풀만 Main, MyThread1, MyThread2로 변경되는 것을 볼 수 있다.

withContext 함수를 사용하면 CoroutineDispatcher 객체를 통해 코루틴이 실행되는데 사용되는 CoroutineDispatcher 객체를 자유롭게 바꿀 수 있다.

withContext 함수를 통해 변경된 CoroutineDispatcher 객체는 withContext 함수 블록 냅에서만 유효하다. withContext 블록을 벗어나면 다시 이전의 CoroutineDispatcher 객체를 사용하게 되며 스레드가 다시 전환된다.

5. 요약

1. async 함수를 사용해 코루틴을 실행하면 코루틴의 결과를 감싸는 Deferred 객체를 반환받는다.
2. Deferred 객체는 Job의 서브타입으로 Job 객체에 결괏값을 감싸는 기능이 추가된 객체다.
3. Deferred 객체에 대해 await 함수를 호출하면 결괏값을 반환받을 수 있다. await 함수를 호출한 코루틴은 Deferred 객체가 결괏값을 반환할 때까지 일시 중단 후 대기할 수 있다.
4. awaitAll 함수를 사용해 복수의 Deferred 코루틴이 결괏값을 반환할 때까지 대기할 수 있다.
5. awaitAll 함수는 컬렉션에 대한 확장 함수로도 제공된다.
6. withContext를 사용해 async-await 쌍을 대체할 수도 있다.
7. withContet 함수는 코루틴을 새로 생성하지 않는다. 코루틴의 실행 환경을 담는 CoroutineDispatcher 객체만 변경해 코루틴을 실행하므로 이를 활용해 코루틴이 실행되는 스레드를 변경할 수 있다.
8. withContext 함수는 코루틴을 새로 생성하지 않으므로 병렬로 실행되야 하는 복수의 작업을 withContext로 감싸 실행하면 순차적으로 실행된다. 이럴때는 async를 사용해 작업이 병렬로 실행될 수 있도록 해야한다.
9. withContext로 실행환경이 변경돼 실행되는 코루틴은 withContext의 작업을 모두 실행하면 다시 이전의 실행 환경으로 돌아온다.

코루틴 빌더는 코루틴을 만들고 코루틴을 추상화한 Job 객체를 생성

코루틴 빌더인 launch 함수를 호출하면 코투린이 만들어지고, Job 객체가 생성돼 반환

반환된 Job 객체는 코루틴의 상태를 추적하고 제어하는데 사용됨

fun main() = runBlocking<Unit> {
    val job: Job = launch(Dispatchers.IO) { //Job 객체 반환
        println("[${Thread.currentThread().name}] 실행")
    }
}

코루틴 → 일시 중단할 수 있는 작업

코루틴을 추상화한 Job 객체는 이에 대응해 코루틴을 제어할 수 있는 함수와 코루틴의 상태를 나타내는 상태 값들을 외부에 노출

4장에서 다루는 내용

• join, joinAll 함수를 사용한 코루틴 간 순차 처리
• CoroutineStart.LAZY를 사용한 코루틴 지연 시작
• 코루틴 실행 취소
• 코루틴의 상태

1. join을 사용한 코루틴 순차 처리

코루틴 간에는 순차 처리가 필요한 경우가 종종 발생

• 데이터베이스 박업을 순차적으로 처리
• 캐싱된 토큰 값이 업데이트된 이후에 네트워크 요청을 해야하는 상황

Job 객체는 순차 처리가 필요한 상황을 위해 join함수를 제공해 먼저 처리돼야 하는 코루틴의 실행이 완료될 때까지 호출부의 코루틴을 일시 중단하도록 만들 수 있음

1-1. 순차 처리가 안 될 경우의 문제

네트워크 요청 시 인증 토큰이 필요한 상황

• 인증 토큰이 업데이트 된 이후 네트워크 요청이 실행돼야 요청이 정상적으로 처리될 수 있음
• 인증 토큰이 업데이트 되기 이전에 요청이 실행되면 문제가 생길 수 있음

토큰 업데이트 작업과 네트워크 요청 작업에 순차 처리가 적용되지 않은 코드

fun main() = runBlocking<Unit> {
    val updateTokenJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 토큰 업데이트 시작")
        delay(100L)
        println("[${Thread.currentThread().name}] 토큰 업데이트 완료")
    }

    val networkCallJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 네트워크 요청")
    }
}

/*
[DefaultDispatcher-worker-2 @coroutine#2] 토큰 업데이트 시작
[DefaultDispatcher-worker-3 @coroutine#3] 네트워크 요청
[DefaultDispatcher-worker-2 @coroutine#2] 토큰 업데이트 완료
*/

• 토큰 업데이트 시작 이후 업데이트가 완료되기 전에 네트워크 요청이 발생하는 상황 가정
• 이 코드에서는 인증 토큰 업데이트 작업과 네트워크 요청 작업이 병렬로 실행
• 실제 네트워크 환경에서는 심각한 오류가 발생할 수 있음
  • 만료된 토큰으로 요청, Authorization 헤더 누락, 중복 토큰 갱신, 요청 실패 후 불필요한 재시도, 사용자 경험 문제, 데이터 불일치 등등…
• 이런 문제를 해결하려면 updateTokenJob이 모두 완료된 이후 networkCallJob이 실행되어야 함

1-2. join 함수 사용해 순차 처리하기

Job 객체의 조인 함수를 사용하면 코루틴 간에 순차 처리가 가능함

JobA 코루틴이 완료된 이후에 JobB 코루틴이 실행돼야 한다면 JobB 코루틴이 실행되기 전에 JobA 코루틴에 join 함수를 호출하면 됨

fun main() = runBlocking<Unit> {
    val updateTokenJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 토큰 업데이트 시작")
        delay(100L)
        println("[${Thread.currentThread().name}] 토큰 업데이트 완료")
    }

    updateTokenJob.join() // updateTokenJob이 완료될 때까지 runBlocking 코루틴 일시 중단

    val networkCallJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 네트워크 요청")
    }
}

/*
[DefaultDispatcher-worker-2 @coroutine#2] 토큰 업데이트 시작
[DefaultDispatcher-worker-2 @coroutine#2] 토큰 업데이트 완료
[DefaultDispatcher-worker-3 @coroutine#3] 네트워크 요청
*/

• Job 객체의 join 함수를 호출하면 join의 대상이 된 코루틴의 작업이 완료될 때까지 join을 호출한 코루틴이 일시 중단됨
• runBlocking 코루틴이 updateTokenJob.join()을 호출하면 runBlocking 코루틴은 updateTokenJob 코루틴이 완료될 때까지 일시 중단됨
• 이후 updateTokenJob의 작업이 모두 완료되면 runBlocking 코루틴이 재개돼 networkCallJob 코루틴을 실행함

“join 함수를 호출한 코루틴은 join의 대상이 된 코루틴이 완료될 때까지 일시 중단됨”

join 함수는 일시 중단이 가능한 지점(코루틴 등)에서만 호출할 수 있음

join 함수는 join을 호출한 코루틴만 일시 중단한다.

join 함수는 join함수를 호출한 코루틴을 제외하고 이미 실행중인 다른 코루틴을 일시 중단하지 않음

fun main() = runBlocking<Unit> {
    val updateTokenJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 토큰 업데이트 시작")
        delay(100L)
        println("[${Thread.currentThread().name}] 토큰 업데이트 완료")
    }

    val independentJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 독립적인 작업 실행")
    }

    updateTokenJob.join() // updateTokenJob이 완료될 때까지 runBlocking 코루틴 일시 중단

    val networkCallJob = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 네트워크 요청")
    }
}

/*
[DefaultDispatcher-worker-2 @coroutine#2] 토큰 업데이트 시작
[DefaultDispatcher-worker-2 @coroutine#2] 독립적인 작업 실행
[DefaultDispatcher-worker-2 @coroutine#2] 토큰 업데이트 완료
[DefaultDispatcher-worker-3 @coroutine#3] 네트워크 요청
*/

independentJob은 updateTokenJob.join()이 호출되더라도 updateTokenJob이 끝날 때까지 기다리지 않고 실행되는 것을 확인할 수 있음

2. joinAll을 사용한 코루틴 순차 처리

실제 개발 시에는 서로 독립적인 여러 코루틴을 병렬로 실행한 후 실행한 요청들이 모두 끝날 때까지 기다렸다가 다음 작업을 진행하는 것이 효율적

SNS에 이미지를 업로드 하는 경우

• 여러 이미지를 한번에 업로드 할 때
• 코루틴을 하나만 만들어 각 이미지를 순차적으로 변환하는 것 보다
• 변환할 이미지 개수만큼 코루틴을 생성해 병렬로 처리한 후 결과를 취함하는 것이 효율적

joinAll 함수는 복수의 코루틴 실행이 모두 끝날 때까지 호출부의 코루틴을 일시 중단

2-1. joinAll 함수

joinAll 함수의 내부 동작 → 가변 인자로 Job 타입의 객체를 받은 후 각 Job 객체에 대해 모두 join 함수를 호출

public suspend fun joinAll(vararg jobs: Job): Unit = jobs.forEach {
    it.join()
}

2-2. joinAll 함수 사용해 보기

fun main() = runBlocking<Unit> {
    val convertImageJob1: Job = launch(Dispatchers.Default) {
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name}] 이미지 1 변환 완료")
    }

    val convertImageJob2: Job = launch(Dispatchers.Default) {
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name}] 이미지 2 변환 완료")
    }

    joinAll(convertImageJob1, convertImageJob2)

    val uploadImageJob: Job = launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 이미지1, 2 업로드")
    }
}

/*
[DefaultDispatcher-worker-1 @coroutine#2] 이미지1 변환 완료
[DefaultDispatcher-worker-2 @coroutine#3] 이미지1 변환 완료
[DefaultDispatcher-worker-1 @coroutine#4] 이미지1, 2 업로드
*/

3. CoroutineStart.LAZY로 코루틴 지연 시작하기

launch 함수를 통한 코루틴 생성 → 사용할 수 있는 스레드가 있을 경우 곧바로 실행

코루틴을 미리 생성한 후 나중에 실행해야 할 수 있음

코루틴 라이브러리는 생성된 코루틴을 지연 시작(Lazy Start)할 수 있는 기능을 제공함

지연 시작이 적용된 코루틴은 생성 후 대기 상태에 놓이며, 실행을 요청하지 않으면 실행되지 않음

코루틴을 지연 시작하기 위해서는 launch 함수의 start 인자로 CoroutineStart.LAZY를 넘겨 옵션을 적용해야 함

val lazyJob: Job = launch(start = CoroutineStart.LAZY) { // 지연 코루틴
    ...
}

lazyJob.start() // 실행 요청

4. 코루틴 취소하기

코루틴 실행 도중 필요가 없어지면 즉시 취소해야 함 → 스레드를 점유해 성능 하락이 발생할 수 있음

코루틴 라이브러리의 Job 객체는 코루틴을 취소할 수 있는 cancel 함수를 제공함

4-1. cancel 사용해 Job 취소하기

fun main() = runBlocking<Unit> {
    val longJob: Job = launch(Dispatchers.Default) {
        repeat(10) { repeatTime -> 
            delay(1000L)
            println("반복횟수 ${repeatTime}")
        }
    }

    delay(3500L)

    longJob.cancel() // 코루틴 취소
}

• 총 10번의 로그를 찍는 코루틴(longJob)
• 3500 밀리초 뒤에 코루틴을 취소해 로그가 3번 까지 찍힘

4-2. cancelAndJoin을 사용한 순차 처리

cancel() 함수 → 코루틴을 즉시 취소하는 것이 아닌 Job 객체의 취소 확인용 플래그를 변경해 이 코루틴이 취소되어야 한다고 알리는 함수

cancel 함수를 호출한다고 해당 코루틴이 즉시 취소되는 것이 아님

취소에 대한 순차성 보장을 위해 Job 객체는 cancelAndJoin 함수를 제공

cancelAndJoin 함수를 사용하면 코루틴의 취소가 완료될 때까지 호출부의 코루틴이 일시 중단됨

fun main() = runBlocking<Unit> {
    val longJob : Job = launch(Dispatchers.Default) { 
        ...
    }

    longJob.cancelAndJoin()

    executeAfterJobCancelled()
}

• longJob 코루틴이 취소될 때까지 runBlocking 코루틴이 일시 중단됨

5. 코루틴의 취소 확인

cancel 함수 & cancelAndJoin 함수 → Job 객체 내부에 있는 취소 확인용 플래그를 바꾸기만 하며, 코루틴이 이 플래그를 확인하는 시점에 취소됨

코루틴이 취소를 확인하는 시점은 일반적으로 일시 중단 지점이나 코루틴이 실행을 대기하는 시점

fun main() = runBlocking<Unit> {
    val whileJob: Job = launch(Dispatchers.Default) {
        while(true) {
            println("작업 중")
        }
    }
    delay(100L)
    whileJob.cancel()
}

• whileJob 객체의 코루틴이 100밀리초 후에 취소도리 것 같지만 실제로는 취소되지 않음
• 코루틴 블록 내부에 콜틴의 취소를 확인할 수 있는 시점이 없기 때문임
• while 문에서 코드가 반복해 실행되고 있어 while문을 벗어날 수 없음
• while 문 내부에도 일시 중단 시점이 없어 일시 중단이 일어나지 않음

whileJob 코루틴은 코루틴의 취소를 확인할 수 있는 시점이 없어 취소가 요청됐음에도 계속해서 실행됨

이런 코루틴을 취소하는 방법들에 대해 알아본다.

5-1. delay를 사용한 취소 확인

delay 함수 → 일시 중단 함수 (suspend fun)

• 특정 시간만큼 호출부의 코루틴을 일시 중단

코루틴은 일시 중단 시점에 취소를 확인하기 때문에 while문 내부에 delay를 직접 선언하면 일시 중단 시점을 만들어 코루틴을 취소할 시점을 만들 수 있음

fun main() = runBlocking<Unit> {
    val whileJob: Job = launch(Dispatchers.Default) {
        while(true) {
            println("작업 중")
            delay(1L)
        }
    }
    delay(100L)
    whileJob.cancel()
}

이 방법은 while문이 반복될 때마다 작업을 강제로 1밀리초 동안 일시 중단시킨다는 점에서 효율적이지 않다.

5-2. yield를 사용한 취소 확인

yield → 양보

yield 함수가 호출되면 코루틴은 자신이 사용중이던 스레드의 사용을 중단하면서 작업을 일시 중단함

작업이 일시 중단되기 때문에 코루틴 취소를 확인할 수 있는 시간이 생김

fun main() = runBlocking<Unit> {
    val whileJob: Job = launch(Dispatchers.Default) {
        while(true) {
            println("작업 중")
            yield()
        }
    }
    delay(100L)
    whileJob.cancel()
}

yield() 함수도 while문이 한 번 돌 때마다 스레드 사용이 양보되면서 일시중단되는 문제가 있음

경량 스레드라고 해도 매번 일시 중단되는 것은 비효츌적임

5-3. CoroutineScope.isActive를 사용한 취소 확인

CoroutineScope.isActive → 코루틴이 활성화됐는지 확인할 수 있는 Boolean 타입의 파라미터

코루틴 취소가 요청되면 isActive 프로퍼티의 값이 false로 바뀜

• while문의 인자로 this.isActive를 넘기면 코루틴 취소 요청이 발생했을 때 while문이 취소되도록 만들 수 있음

fun main() = runBlocking<Unit> {
    val whileJob: Job = launch(Dispatchers.Default) {
        while(this.isActive) {
            println("작업 중")
        }
    }
    delay(100L)
    whileJob.cancel()
}

이 방법을 사용하면 코루틴이 잠시 멈추지도 않고 스레드 사용을 양보하지도 않으며 계속해서 작업을 이어갈 수 있어 효율적임

코루틴 내부의 작업이 일시 중단 지점 없이 계속된다면 명시적으로 코루틴이 취소됐는지 확인하는 코드를 넣어줌으로써 코루틴을 취소할 수 있도록 만들어줘야 함

그렇지 않으면 코루틴 취소가 동작하지 않을 수 있음

6. 코루틴의 상태와 Job의 상태 변수

코루틴은 총 6개의 상태를 가짐

• 생성(New)
  • 코루틴 빌더를 통해 코루틴을 생성하면 기본적으로 생성 상태에 놓이며 자동으로 실행 상태로 넘어감
  • 만약 실행 상태로 자동으로 넘어가지 않도록 하고 싶다면 코루틴 빌더의 start 인자로 CoroutineStart.Lazy를 넘겨 지연 코루틴을 만들면 됨
• 실행 중 (Active)
  • 코루틴이 생성되고 자동으로 진입하는 상태
  • 코루틴이 실행중일 때 뿐만 아니라 실행된 후애 일시 중단된 때도 실행중 상태로 간주함
• 실행 완료 중 → 구조화된 동시성 (7장에서 다룸)
• 실행 완료 (Completed)
  • 코루틴의 모든 코드가 실행 완료된 경우 실행 완료 상태로 넘어감
• 취소 중 (Canceling)
  • Job.cancel() 등으로 코루틴에 취소 요청이 발생했을 경우 취소 중 상태로 넘어감
  • 아직 취소된 상태가 아니기 때문에 코루틴은 계속해서 실행됨
• 취소 완료 (Cancelled)
  • 코루틴의 취소 확인 시점에 취소가 확인 된 경우 취소 완료 상태가 됨
  • 코루틴이 더 이상 실행되지 않음

Job 객체는 코루틴이 어떤 상태에 있는지 나타내는 상태 변수들을 외부로 공개

다만 Job 객체는 코루틴을 추상화한 객체이므로 노출하는 상태 변수들은 코루틴의 상태를 간접적으로만 나타냄

코루틴의 각 상태애서 Job 객체가 노출하는 상태 변수들의 상태 값

• isActive
  • 코루틴이 활성화돼 있는지의 여부
  • 활성화 → true / 비활성화 → false
  • 활성화 상태 = 코루틴이 실행된 후 취소가 요청되지 않았거나 실행이 완료되지 않은 상태라는 의미
  • 취소가 요청되었거나 실행이 완료된 상태 → 활성화되지 않은 것으로 봄
• isCancelled
  • 코루틴이 취소 요청됐는지 여부
  • 취소가 요청되는 즉시 true가 반환됨
  • isCancelled가 true여도 코루틴이 즉시 취소되는 것은 아님
• isCompleted
  • 코루틴 실행이 완료되었는지 여부
  • 코루틴의 모든 코드가 실행 완료 되거나 취소 완료되면 true를 반환
  • 코루틴이 실행중인 상태에서는 false를 반환

6-1. 생성 상태의 코루틴

코루틴이 생성만 되고 실행되지 않은 상태

생성 상태의 코루틴을 생성하려면 코루틴 빌더의 start 인자로 CoroutineStart.Lazy를 넘겨 지연 시작이 적용된 코루틴을 생성해야 함

fun main() = runBlocking<Unit> {
    val job: Job = launch(start = CoroutineStart.LAZY) {
        delay(1000L)
    }
    printJobState(job)
}

/*
Job State
isActive >> false
isCancelled >> false
isCompleted >> false
*/

• 코루틴 생성 후 실행되지 않았으므로 isActive가 false임
• 취소가 요청되지 않았으므로 isCancelled가 false임
• 코루틴 실행이 완료되지 않았으므로 isCompleted가 false임

6-2. 실행 중 상태의 코루틴

코루틴 빌더로 코루틴을 생성하면 CoroutineDispatcher에 의해 스레드로 보내져 실행됨

이때 코루틴이 실행되고 있는 상태를 ‘실행 중’ 상태라고 부름

fun main() = runBlocking<Unit> {
    val job: Job = launch {
        delay(1000L)
    }
    printJobState(job)
}

/*
Job State
isActive >> true
isCancelled >> false
isCompleted >> false
*/

• 코루틴이 실행된 후 취소되거나 완료되지 않았으므로 isActive가 true임
• 코루틴에 취소가 요청되지 않았으므로 isCancelled가 false임
• 코루틴이 실행 완료되지 않았으므로 isCompleted가 false임

6-3. 실행 완료 상태의 코루틴

실행 중인 코루틴이 모두 정상적으로 실행돼 실행 완료되면 코루틴은 실행 완료 상태로 변경됨

fun main() = runBlocking<Unit> {
    val job: Job = launch {
        delay(1000L)
    }
    delay(2000L)
    printJobState(job)
}

/*
Job State
isActive >> false
isCancelled >> false
isCompleted >> true
*/

• 코루틴이 실행 완료돼 활성화된 상태가 아니므로 isActive는 false임
• 취소가 요청되지 않고 정상적으로 실행 완료됐으므로 isCancelled는 false임
• 실행이 완료된 것이므로 isCompleted는 true임

6-4. 취소 중인 코루틴

취소가 요청됐으나 취소되지 않은 상태인 ‘취소 중’ 상태

단순히 취소 요청을 하면 코루틴은 곧바로 취소 중 상태에서 취소 완료 상태로 변환하므로 취소르르 확인할 수 있는 시점이 없는 코루틴을 생성하고 취소를 요청해야 취소 중 상태를 확인할 수 있음

fun main() = runBlocking<Unit> {
    val job: Job = launch(Dispatchers.Default) {
        while(true) {
            //
        }
    }
    job.cancel()
    printJobState(job)
}

/*
Job State
isActive >> false
isCancelled >> false
isCompleted >> true
*/

• 코루틴이 취소 요청됐으므로 화성화돼 있지 않다고 판단해 isActive가 false임
• 코루틴 취소가 요청 됐으므로 isCancelled는 true임
• 취소가 완료되지 않았으므로 isCompleted가 false임

여기서 중요한 점이 취소가 요청되면 실제로는 코드가 실행 중이더라도 코루틴이 활성화된 상태로 보지 않는다는 점임

6-5. 취소 완료된 코루틴

코루틴은 코루틴 취소가 요청되고 취소 요청이 확인되는 시점에 취소가 완료됨

fun main() = runBlocking<Unit> {
    val job: Job = launch {
        delay(5000L)
    }
    job.cancelAndJoin()
    printJobState(job)
}

/*
Job State
isActive >> false
isCancelled >> true
isCompleted >> true
*/

• 취소가 완료돼 코루틴이 활성화되어 있지 않으므로 isActive가 false임
• 취소 요청 후 취소가 완료되었으므로 isCancelled와 isCompleted가 true임

코루틴 라이브러리 1.7.2 버전을 기준으로 Job 구현체의 toString 함수를 통해 코루틴의 상태값이 toString 문자열에 포함되도록 만들어져있음

7. 요약

• runBlocking, launch 함수 → 코루틴 빌더 함수의 일종
• launch 함수를 호출하면 Job 객체가 만들어져 반환되며, Job 객체는 코루틴의 상태를 추적하고 제어하는데 사용됨
• Job 객체의 Join 함수를 호출하면 함수를 호출한 코루틴이 Job 객체의 실행이 완료될 때까지 일시 중단됨
• JoinAll 함수를 통해 여러개의 코루틴이 실행 완료될 때까지 대기할 수 있음
• Job 객체의 cancel 함수를 사용해 코루틴의 취소를 요청할 수 있음
• cancel 함수를 호출한다고 코루틴이 즉시 취소되는 것이 아닌 코루틴의 취소 플래그의 상태가 바뀌고, 취소가 확인될 때 취소됨
• cancel 함수를 호출하더라도 코루틴이 취소를 확인할 수 없는 상태에서는 계속해서 실행될 수 없음
• delay, yield 함수와 isActive 프로퍼티 등을 호라용해 코루틴이 취소를 확인할 수 있도록 만들 수 있음
• 코루틴은 생성, 실행 중, 실행 완료 중, 실행 완료, 취소 중, 취소 완료의 상태를 가짐
• Job 객체는 isActive, isCancelled, isCompleted 프로퍼티를 통해 코루틴의 상태를 나타냄
• isActive는 생성 상태일 때는 false, 코루틴이 실행되면 true로 바뀜, cancel 함수를 통해 취소 요청 또는 실행 완료시 false로 다시 바뀜
• isCancelled는 코루틴이 취소 중이거나 취소 완료되었을 때만 true가 됨
• isCompleted는 코루틴이 취소 완료되었거나 실행 완료되었을 때만 true가 됨

뭐 하다 실수를 했나?

안드로이드 트랙에선 4주간 우아한테크코스에서 정해준 미션을 수행한 이후, 미니 프로젝트를 시작했다.

미니 프로젝트는 지금까지 경험해왔던 우아한테크코스의 미션과 궤를 달리했다.

지금까지의 미션이 요구사항과 기능 구현 목록, 목표가 정해져 있었다면,

미니 프로젝트는 그 어떠한 것도 정해주지 않고 오롯이 크루들의 힘으로 해쳐나가야 하는 미션이었다.

문제 정의, 가설 수립/검증, 솔루션 설계, 플랫폼/기술 스택 결정 등 정말 많은 것을 코치의 도움 없이 해내야 했다.

지금까지의 활동과 다른 성격의 활동을 진행하면서 기존 미션에서 배우는 지식들과는 성격을 달리하는 지식을 많이 배웠다.

그중, 가장 기억에 남는 배움이 하나 있다. 그 배움은 "실수"와 "시행착오"에서 비롯되었다.

무슨 실수를 했나?

대제목에서 알 수 있듯이 문서화와 관련된 실수와 시행착오가 있었다.

우리 프로젝트 팀이 정의한 문제 상황은 다음과 같다.

"키보드 초보자의 입장에선 키보드를 구매하기 위해 알아야 할 정보가 너무 많고, 파편화되어 있다."

이 문제 상황에 대해 우리 팀이 내놓은 솔루션은

"어려운 키보드 용어를 쉽게 풀어서 설명하고, 여러 곳에 파편화되어 있는 정보들을 한 화면에서 확인할 수 있는 웹 서비스"였다.

문제 상황도 명확했고, 솔루션도 명확했다. 이때까지만 해도 아무 문제 없는 듯 보였다.

문제는 리뷰어의 피드백에 대해 팀원들과 의논하는 자리에서 발생했다.

미니 프로젝트에선 한 주마다 그 주의 의사 결정 과정과 결과를 배정된 리뷰어에게 공유한다.

이를 통해 리뷰어는 우리의 결정에서 생각해 봐야 할 점, 경계헤야할 점 등에 대해 피드백을 진행해준다.

이때 우리가 받았던 피드백 중 다음의 내용이 있었다.

여전히 취향의 상세한 내부를 더 파 봐야한다고 생각해요.
누구는 고급 축이 비싸서 안 고를 수도, 누구는 키캡이 너무 비싸서 안 고를 수도, 누구는 키보드 기판이 비싸서 안 고를 수도 있겠어요.

오히려 가설이 왜 이렇게 잘 맞나? 이게 맞나? 라고 생각해보면 좋겠어요. 지금 취향 선택에 대한 가설을 잘 세웠는가?

제 생각엔, 이런 가설이 검증됐다는 느낌이 강하게 들어요.
배고프면? -> 밥을 먹는다. 누가 굶어죽겠어? OK 밥 앱을 만들자.

해당 피드백은 우리가 진행한 설문조사의 결과에 대한 피드백이다.

우리가 진행한 설문 조사의 질문들 중 "키보드를 구매할 때, 단순한 입력 기능보다, 취향(타건감, 무게, 키 배열)을 더 중요하게 고려하시나요?"라는 내용이 있었다.

이 질문은 "너무 자명한 사실에 대해 확인하는 것 아니냐"는 점을 꼬집으면서도 우리에게 풀리지 않는 의문점을 남겼다.

취향을 더 깊게 파봐야 한다고? 왜지?

설문조사를 진행할 때 "키보드를 구매할 때 어떤 요소를 주로 고려하는가?"에 대해 수집했다면,

우리 서비스가 사용자에게 제공할 선택지를 더 세분화하고 사용자가 실제로 겪는 불편을 더 확실하게 확인할 수 있었을 것이다.

다만 우리가 의문점을 느끼는 부분은 "우리 서비스가 사용자의 취향 파악을 이렇게 깊게 할 이유가 있나?"였다.

우리 서비스가 제공하고자 하는 솔루션이 "사용자의 취향을 입력받고 그에 맞는 키보드의 특지을 사용자가 이해하기 쉬운 언어로 풀고, 여러 곳에 흩어져 있는 정보를 취합해 주자"였기 때문에

사용자의 취향을 입력받고 그 안에서 정보를 최대한 추출해 조건에 부합하는 목록을 생성하면 됐었다.

하지만 이 피드백의 성격은 우리가 생각하는 방향성과 많이 다르다고 느꼈다.

이 피드백에 대해 팀원들과 토론하는 데 꼬박 6시간을 할애했고, 결론이 나지 않았던 우리는 결국 리뷰어에게 연락을 취해 피드백의 의도를 물었다.

그때 받았던 답변은 이랬다.

제가 생각하기에는 진짜 만들고 싶은 게 뭔지 정의하는 게 더 중요해보여요

취향에 따라 키보드를 쉽게 선택할 수 있게 도와주는 앱 -> 너무 범용적이란 생각이 들어요. 취향은 굉장히 매니악한 분야라고 생각해서요

먼저 누가 타겟층인지도 잘 모르겟어요.

초보자들이 자신의 취향을 찾게끔 도와주는 앱인지?

초고수 매니악들이 내 취향을 알고 거기에 완전 맞춤형의 더 많은 선택지들을 알아서 찾아주는 것인지?

이 두 가지 타겟만 봐도 이미 너무 방향이 다르다고 생각해요

무엇을 해결할 것인가를 완전 좁혀서 생각해보면 좋겠어요

이 답변에서 미루어 보았을 때 우리 서비스의 타겟층, 문제 솔루션 등이 리뷰어에게 제대로 전달되지 않았다는 걸 알 수 있었다.

그래서 뭘 배웠나?

가장 크게 배운 점은 “팀 내부에서 자명하게 여겨지는 내용이라도 외부에 공유할 때는 우리의 의도와 해결 방안을 명확하게 전달해야 한다”는 것이다.

앞서 설명한 일련의 사건으로 인해 우리 팀은 그날 하루의 대부분을 리뷰어의 피드백 의도를 파악하고 답변을 준비하는 데 사용했다.

처음부터 우리가 해결하려는 문제와 제안한 솔루션을 명확하게 전달했다면 이처럼 많은 시간을 들이지 않았을 것이다.

의도가 충분히 전달되지 않아 같은 내용을 다시 설명해야 했고, 그 과정에서 불필요한 시간과 노력이 발생했다.

이런 문제가 또 발생하지 않도록 하려면 어떻게 해야할지 고민해봤다.

일단 문서화를 더 구체적이고 명확히 하는 것 부터 시작하려 한다.

미니 프로젝트를 진행하면서 중간 산출물과 문서화를 신경쓰려 했지만 잘 이뤄지지 않았다고 생각한다.

문서화를 더 구체적이고 명확하게 했다면 리뷰어에게 주간 보고를 올릴때 더 명확하게 우리의 의사를 전달할 수 있었을 것 같다.

이번 경험을 통해 명확한 문서화는 단순히 내용을 기록하는 것을 넘어, 의사소통 과정의 오해와 반복 작업을 줄이는 데에도 큰 영향을 미친다는 점을 체감했다.

• 코루틴 디스패처 객체의 역할
• 제한된 디스패처와 무제한 디스패처
• 제한된 디스패처 생성
• 코루틴 디스패처로 코루틴 실행하기
• 코루틴 라이브러리에 미리 정의된 디스패처의 종류와 사용처

3-1. CoroutineDispatcher란 무엇인가?

Dispatcher

• Dispatch → 보내다
• Dispatcher → 무언가를 보내는 주체

따라서 CoroutineDispatcher → 코루틴을 보내는 주체

CoroutineDispatcher는 코루틴을 스레드로 보냄

• 코루틴은 일시중단 가능한 “작업”이기 때문에 스레드가 있어야 실행할 수 있음
• 코루틴을 스레드로 보내는데 사용할 수 있는 스레드나 스레드 풀을 가짐
• 코루틴을 실행 요청한 스레드에서 코루틴이 실행되도록 만들 수 있음

3-1-1. CoroutineDispatcher의 동작 살펴보기

• 2개의 스레드로 구성된 스레드풀을 갖는 코루틴 디스패처 객체
• 실행돼야 하는 작업을 저장하는 작업 대기열을 가짐
• 새로운 코루틴 실행 요청이 들어오면 해당 작업을 작업 대기열에 적재
• 코루틴을 실행할 수 있는 스레드가 있으면 코루틴을 해당 스레드로 보내 실행시킴
• 사용 가능한 스레드가 없다면 사용 가능한 스레드가 생길 때까지 스레드에 작업을 보내지 않고 작업 대기열에서 대기
• 사용 가능한 스레드가 생기면 대기열에서 대기중인 코루틴을 스레드로 보냄

코루틴 디스패처 객체는 자신에게 실행 요청된 코루틴을 우선 작업 대기열에 적재한 후 사용할 수 있는 스레드가 생기면 스레드로 보내는 방식으로 동작

3-1-2. CoroutineDispatcher의 역할

코루틴 디스패처는 코루틴의 실행을 관리하는 주체

자신에게 실행 요청된 코루틴들을 작업 대기열에 적재하고 자신이 사용할 수 있는 스레드가 새로운 작업을 실행할 수 있는 상태라면 스레드로 코루틴을 보내 실행할 수 있게 만드는 역할

코루틴 디스패처는 코루틴 실행요청이 들어오면 일반적으로 작업 대기열에 적재한 후에 스레드로 보냄 하지만 실행 옵션에 따라 작업 대기열에 적재되지 않고 즉시 실행될 수도 있음 작업 대기열이 없는 코루틴 디스패처 구현체도 있으니 이는 매우 예외적인 경우임 이는 무제한 디스패처에서 별도로 다룸

3-2. 제한된 디스패처와 무제한 디스패처

코루틴 디스패처는 2가지 종류가 있음

• 제한된 디스패처 → 사용할 수 있는 스레드나 스레드풀이 제한된 디스패처
• 무제한 디스패처 → 사용할 수 있는 스레드나 스레드풀이 제한되지 않은 디스패처

일반적으로 코루틴 디스패처는 객체별로 어떤 작업을 처리할지 미리 역할을 부여하고 역할에 맞춰 실행을 요청하는 것이 효율적이기 때문에 대부분의 디스패처는 제한된 디스패처임

입출력 작업 → 입출력 작업용 콜틴 디스패처 객체에 실행을 요청 CPU 연산 작업 → CPU 연산 작업용 코루틴 디스패처 객체에 실행을 요청

무제한 디스패처라고 해서 코루틴이 아무 스레드에서나 실행되는 것은 아님

• 실행 요청된 코루틴이 이전 코드가 실행되던 스레드에서 계속해서 실행되도록 함
• 실행되는 스레드가 매번 달라질 수 있고 특정 스레드로 제한되어 있지 않기 때문에 무제한 디스패처라고 불림
• 11-3에서 자세히 다룰 예정

3-3. 제한된 디스패처 생성하기

코루틴 라이브러리에서 제공하는 제한된 디스패처 생성 함수를 다룸

3-3-1. 단일 스레드 디스페처

단일 스레드 디스패처 → 사용할 수 있는 스레드가 하나

newSingleThreadContext() 함수를 통해 만들 수 있음

• 이 함수는 문자열 타입의 name을 인자로 받음
• name → 디스패처에서 관리하는 스레드 이름
• 반환 타입은 CoroutineDispatcher임

val dispatcher : CoroutineDispatcher = newSingleThreadContext(name = "SingleThread")

이 함수를 통해 만들어진 디스패처는 작업 대기열과 스레드 하나로 구성된 스레드풀을 사용할 수 있음

이 스레드의 이름은 인자로 넘긴 “SingleThread”가 됨

3-3-2. 멀티 스레드 디스패처 만들기

코루틴 라이브러리의 newFixedThreadPoolContext() 함수를 통해 만들 수 있음

• 스레드의 개수 (nThreads)와 스레드의 이름 (name)을 매개변수로 받음
• 만들어지는 스레드들은 인자로 받은 name값 뒤에 ‘-1’부터 시작해 숫자가 하나씩 증가하는 형식으로 이름을 붙임
  • Thread-1, Thread-2…

val multiThreadDiapatcher: CoroutineDispatcher = newFixedThreadPoolContext(
    nThreads = 2,
    name = "MultiThread"
)

이 함수를 통해 만들어진 디스패처는 작업 대기열과 MultiThread-1, MultiThread-2라는 이름을 가진 스레드 2개가 존재함

이렇게 만들어진 디스패처는 newSingleThreadContext()로 만들어진 디스패처와 모습이 매우 흡사함

newSingleThreadContext()가 내부적으로 newFixedThreadPoolContext()를 사용하도록 구현되어 있기 때문임

public fun newSingleThreadContext(name: String): 
ClosableCoroutineDispatcher = 
    newFixedThreadPoolContext(1, name)

3-4. CoroutineDispatcher 사용해 코루틴 실행하기

3-4-1. launch의 파라미터로 CoroutineDispatcher 사용하기

1. 단일 스레드 디스패처 사용해 코루틴 실행하기

   launch함수를 사용해 만든 코루틴을 특정 코루틴 디스패처 객체에 실행 요청하기 위해서는 launch 함수의 context 인자로 코루틴 디스패처 객체를 넘기면 됨

    fun main() = runBlocking<Unit> {
        val dispathcer = newSingleThreadContext(name = "SingleThread")
        launch(context = dispatcher) {
            println("[${Thread.currentThread().name}] 실행")
        }
    }
   
    // [SingleThread @coroutine#2] 실행

   새로운 스레드의 이름을 SingleThread로 설정했으므로 launch 함수를 통해 생성된 코루틴이 실행되는 스레드가 SingleThread로 나옴

2. 멀티 스레드 디스패처를 사용해 코루틴 실행하기

   단일 스레드 디스패처를 사용하는 방식과 동일

   launch 함수의 context 인자로 multiThreadDispatcher를 넘기면 됨

    fun main() = runBlocking<Unit> {
        val dispathcer = newFixedThreadPoolContext(
            nThreads = 2,
            name = "SingleThread"
        )
        launch(context = dispatcher) {
            println("[${Thread.currentThread().name}] 실행")
        }
        launch(context = dispatcher) {
            println("[${Thread.currentThread().name}] 실행")
        }
    }

   단일 스레드 코루틴 디스패처와 마찬가지로 실행을 요청받은 코루틴을 작업 대기열에 적재하고 작업 가능한 스레드에 코루틴을 보내 실행

   다음 작업도 마찬가지로 작업 대기열에 적재 한 후 사용 가능한 스레드에 코루틴을 보내 실행함

   이 때 실행 환경에 따라 각 코루틴이 다른 속도로 처리될 수 있기 때문에 출력되는 스레드 이름이 같을 수 있음

3-4-2. 부모 코루틴의 CoroutineDispatcher를 사용해 자식 코루틴 실행하기

코루틴은 구조화를 제공해 콜틴 내부에서 새로운 코루틴을 실행할 수 있음

이 때 바깥쪽 코루틴을 부모 코루틴, 내부에서 실행되는 코루틴을 자식 코루틴이라고 함

구조화는 코루틴을 계층 관계로 만드는 것 뿐 아니라 부모 코루틴의 실행 환경을 자식 코루틴에 전달하는 데도 사용됨

만약 자식 코루틴에 코루틴 디스패처 객체가 설정되지 않았으면 부모 코루틴의 코루틴 디스패처 객체를 사용함

fun main() = runBlocking<Unit> {
    val dispathcer = newFixedThreadPoolContext(
        nThreads = 2,
        name = "SingleThread"
    )
    launch(context = dispatcher) { // 부모
        println("[${Thread.currentThread().name}] 부모 코루틴 실행")

        launch(context = dispatcher) { // 자식
            println("[${Thread.currentThread().name}] 자식 코루틴 실행")
        }

        launch(context = dispatcher) { // 자식
            println("[${Thread.currentThread().name}] 자식 코루틴 실행")
        }
    }
}

/*
[MultiThread-1 @coroutine#2] 부모 코루틴 실행
[MultiThread-2 @coroutine#3] 자식 코루틴 실행
[MultiThread-1 @coroutine#4] 자식 코루틴 실행
*/

가장 상단의 launch 함수로 생성되는 코루틴이 부모 코루틴이 됨

이 부모 코루틴은 전용 스레드가 2개인 코루틴 디스패처를 사용

부모 코루틴 launch 함수의 람다식 내부에서 2개의 launch 함수를 호출해2개의 코루틴을 추가로 생성하는데 이 때 생성되는 코루틴이 자식 코루틴임

이 자식 코루틴들에는 별도의 코루틴 디스패처가 설정되어 있지 않기 때문에 부모의 코루틴 디스패처를 사용함

부모 코루틴과 자식 코루틴이 동일한 코루틴 디스패처 객체를 사용하므로 스레드를 공유하는 것을 볼 수 있음

특정 코루틴 디스패처에서 여러 작업을 실행해야 한다면 부모 코루틴에 코루틴 디스패처 객체를 설정하고 그 아래 자식 코루틴을 여러개 생성하면 됨

3-5. 미리 정의된 CoroutineDispatcher

3-5-1. Dispatchers.IO

멀티 스레드 프로그래밍에서 가장 많이 사용되는 작업 → I/O 작업

• 네트워크 통신을 위한 HTTP 요청
• DB 작업

I/O 작업 여러 개를 동시에 수행하므로 이런 요청을 동시에 수행하기 위해서는 많은 스레드가 필요함

코루틴 라이브러리에서는 입출력 작업을 위해 미리 정의된 Dispatchers.IO를 제공함

Dispatchers.IO가 최대로 사용할 수 있는 스레드의 수 → JVM에서 사용할 수 있는 프로세서 수와 64 중 큰 값으로 설정되어 있음

Dispatchers.IO는 싱글톤 인스턴스이므로 launch 함수의 인자로 곧바로 넘겨줄 수 있음

fun main() = runBlocking<Unit> {
    launch(Dispatchers.IO) {
        println("[${Thread.currentThread().name}] 코루틴 실행")
    }
}

// [DefaultDispathcer-worker-1 @coroutine#2] 코루틴 실행

위 코드의 결과를 보면 코루틴이 실행된 스레드의 이름 앞에 DefaultDispatcher-worker가 붙은 것을 알 수 있음

DefaultDispatcher-worker가 붙은 스레드는 코루틴 라이브러리에서 제공하는 공유 스레드풀에 속한 스레드임

Dispatchers.IO는 공유 스레드풀의 스레드를 사용할 수 있도록 구현됐음

공유 스레드풀에 대해서는 추후 더 자세하게 다룰 예정

3-5-2. Dispatchers.Default

CPU 바운드 작업 → CPU 연산이 필요한 작업

ex) 대용량 데이터 처리

Dispatchers.Default → CPU 바운드 작업이 필요할 때 사용하는 CoroutineDispatcher

Dispatchers.Default도 그 자체로 싱글턴 인스턴스이므로 간단하게 호출할 수 있음

fun main() = runBlocking<Unit> {
    launch(Dispatchers.Default) {
        println("[${Thread.currentThread().name}] 코루틴 실행")
    }
}

// [DefaultDispatcher-worker-1 @coroutine#2] 코루틴 실행

입출력 작업과 CPU 바운드 작업

두 작업의 중요한 차이 → 실행됐을 때 스레드를 지속적으로 사용하는지 여부

일반적으로 입출력 작업은 작업(네트워크 요청, DB 조회 요청 등)을 실행한 후 결과를 반환받을 때까지 스레드를 사용하지 않음

CPU 바운드 작업은 작업을 하는 동안 스레드를 지속적으로 사용

이 차이로 인해 CPU 바운드 작업은 스레드 기반 작업을 사용했을 때와 코루틴을 사용했을 때 효율성에 차이가 발생함

입출력 작업에 코루틴을 사용 → 작업 실행 후 스레드가 대기하는 동안 해당 스레드에서 다른 작업을 동시에 실행할 수 있어 효츌적

CPU 바운드 작업에 코루틴 사용 → 스레드가 지속적으로 사용되기 때문에 스레드 기반 작업을 사용해 실행했을 때와 처리 속도에 차이가 거의 없음

3-5-3. limitedParallelism을 사용해 Dispatchers.Default 스레드 사용 제한하기

Dispatchers.Default를 사용해 무겁고 오래 걸리는 작업을 처리하면 특정 작업을 위해 Dispatchers.Default의 모든 스레드가 사용될 수 있으며, 특정 연산을 진행하는 동안 Dispatchers.Defualt를 사용하는 다른 작업이 실행되지 못할 수 있음

이를 방지하기 위해 코루틴 라이브러리는 Dispatchers.Default의 일부 스레드만 사용해 특정 연산을 실행할 수 있도록 하는 limitedParallelism 함수를 지원함

fun main() = runBlocking<Unit> {
    launch(Dispatchers.Default.limitedParallelism(2)) {
        repeat(10) {
            launch {
                println("[${Thread.currentThread().name}] 코루틴 실행")
            }
        }
    }
}

/*
[DefaultDispatcher-worker-2 @coroutine#3] 코루틴 실행
[DefaultDispatcher-worker-1 @coroutine#4] 코루틴 실행
[DefaultDispatcher-worker-2 @coroutine#5] 코루틴 실행
[DefaultDispatcher-worker-1 @coroutine#6] 코루틴 실행
.
.
.
[DefaultDispatcher-worker-2 @coroutine#11] 코루틴 실행
[DefaultDispatcher-worker-1 @coroutine#12] 코루틴 실행
*/

• Dispatchers.Default.limitedParallelism(2)를 통해 Dispatchers.Default의 여러 스레드 중 2개의 스레드만 사용해 10개의 코루틴을 실행

3-5-4. 공유 스레드풀을 사용하는 Dispatchers.IO와 Dispatchers.Default

Dispatchers.IO와 Dispatchers.Default를 사용한 코드에서 발견할 수 있는 공통점 → 코루틴을 실행한 스레드의 이름에 DefaultDispatcher-worker가 표시됨

Dispatchers.IO와 Dispatchers.Default는 코루틴 라이브러리의 공유 스레드풀을 사용한다는 것을 의미

코루틴 라이브러리는 스레드의 생성과 관리를 효율적으로 할 수 있도록 애플리케이션 레벨의 공유 스레드풀을 제공

이 공유 스레드풀에는 스레드를 무한으로 생성할 수 있음

코루틴 라이브러리는 공유 스레드풀에 스레드를 생성하고 사용할 수 있도록 하는 API를 제공

Dispatchers.IO와 Dispatchers.Default는 모두 위에서 언급한 API를 사용해 구현됐기 때문에 공유 스레드풀을 사용함

다만 공유 스레드풀에서 Dispatchers.IO와 Dispatchers.Default가 사용하는 스레드는 구분됨

newFixedThreadPoolContext 함수로 만들어지는 디스패처는 자신만 사용할 수 있는 전용 스레드풀을 생성하는 것과 다르게 Dispatchers.IO와 Dispatchers.Default는 공유 스레드풀의 스레드를 사용함

Dispatchers.IO의 limitedParallelism

Dispatchers.Default에 limitedParallelism 함수를 사용하면 스레드풀의 스레드 중 일부만 사용하도록 제한할 수 있음

하지만 Dispatchers.IO의 limitedParallelism은 조금 다르게 동작함

Dispatchers.IO의 limitedParallelism은 공유 스레드풀의 스레드로 구성된 새로운 스레드풀을 만들어내며, 스레드의 수를 제한 없이 만들 수 있음

fun main() = runBlocking<Unit> {
    launch(Dispatchers.IO.limitedParallelism(100)) {
        reapeat(200) {
                launch {
                    Thread.sleep(1000L)
                    println("[${Thread.currentThread().name}] 코루틴 실행")
                }
        }
    }
}

/*
[DefaultDispatcher-worker-60] 코투린 실행
[DefaultDispatcher-worker-74] 코투린 실행
[DefaultDispatcher-worker-68] 코투린 실행
.
.
.
[DefaultDispatcher-worker-85] 코투린 실행
[DefaultDispatcher-worker-49] 코투린 실행
[DefaultDispatcher-worker-98] 코투린 실행
*/

• Dispatchers.IO.limitedParallelism(100)를 통해 공유 스레드풀 상에서 100개의 스레드로 구성된 스레드풀을 만들어냄

Dispatchers.IO의 limitedParallelism함수는 공유 스레드풀 상에서 Dispatchers.IO나 Dispatchers.Default와 관계 없는 스레드로 구성된 스레드풀을 만들어냄

특정 작업이 다른 작업에 영향을 받지 않아야 해, 별도 스레드 풀에서 실행되는 것이 필요할 때 사용

다만 공유 스레드풀에서 새로운 스레드를 만들어내는 작업이라 비용이 비싼 작업이므로 남용하면 안됨

3-5-5. Dispatchers.Main

UI가 있는 애플리케이션에서 메인 스레드를 사용하기 위해 사용되는 특별한 CoroutineDispatcher 객체

코루틴 라이브러리 추가만으론 사용할 수 없고 별도의 라이브러리(ex. Android)를 추가해야 사용할 수 있음

UI 스레드(Main Thread)를 사용하는 라이브러리가 없는 상태로 Diapatchers.Main을 호출하면 IllegalStateException이 발생함

Dispatchers.Main의 구현체를 제공하는 라이브러리가 없어 생기는 오류임

3-6. 3장 요약

• CoroutineDispatcher 객체는 코루틴을 스레드로 보내 실행하는 객체로 코루틴을 작업 대기열에 적재한 후 사용이 가능한 스레드로 보내 실행
• 제한된 디스패처 → 사용할 수 있는 스레드가 특정 스레드 또는 스레드풀로 제한됨
• 무제한 디스패처 → 코루틴을 실행하는 데 사용할 수 있는 스레드가 제한되지 않음
• newSingleThreadContext와 newFixedThreadPoolContext 함수를 사용해 제한된 디스패처 객체를 생성할 수 있음
• launch 함수로 코루틴을 실행할 때 context 인자로 CoroutineDispatcher 객체를 넘기면 해단 CoroutineDispatcher 객첼르 사용해 코루틴이 실행됨
• 자식 코루틴은 기본적으로 부모 코루틴의 CoroutineDispatcher 객체를 상속받아 사용함
• 코루틴 라이브러리는 미리 정의된 Dispatchers.IO, Dispatchers.Default, Dispatchers.Main을 제공함
• Dispatchers.IO는 입출력 작업을 위한 디스패처 객체로, 네트워크 요청이나 파일 I/O등에 사용됨
• Dispatchers.Default는 CPU 바운드 작업을 위한 디스패처 객체로, 대용량 데이터 처리 등에 사용됨
• limitedParallelism() 함수를 사용해 특정 여산을 위해 사용되는 Dispatchers.Default의 스레드 수를 제한할 수 있음
• Dispatchers.Default와 Dispatchers.IO는 코루틴 라이브러리에서 제공하는 공유 스레드풀을 사용함
• Dispatchers.Main은 메인 스레드에서 실행되어야 하는 작업에 사용되는 디스패처로, 사용하기 위해서는 Dispatchers.Main의 구현체를 제공하는 라이브러리 의존성을 추가해야 함
• Diapatchers.Main은 일반적으로 UI가 있는 애플리케이션에서 UI를 업데이트하는 데 사용됨

• 멀티 스레드 프로그래밍이 어떻게 변화했는지
• 기존 멀티스레드 프로그래밍의 한계를 어떻게 극복했는지
  • JVM의 프로세스와 스레드에 대한 이해

1. JVM 프로세스와 스레드

일반적인 코틀린 어플리케이션 → main 함수를 통해 생성

• 어플리케이션 실행 시 JVM은 프로세스를 시작하고 메인 스레드를 생성해 main 함수 내부의 코드 실행

fun main() {
    println("Hello World!")
}

// 메인 스레드가 main 함수 내부의 println("Hello World!")를 실행 후 더 실행할 코드가 없으므로 종료

메인 스레드 → 프로세스의 시작과 끝은 함께 하는 매우 중요한 역할을 함

• 예외가 발생해 메인 스레드가 종료되면 프로세스도 함께 종료

fun main() {
    println("메인 스레드 시작")
    throw Exception("Dummy Exception")
    println("메인 스레드 종료")
}

// "메인 스레드 시작"은 출력되지만 메인 스레드에서 발생한 예외로 인해 프로세스가 종료돼
// "메인 스레드 종료"는 출력되지 않음

• JVM의 프로세스 → 기본적으로 메인 스레드를 단일 스레드로 해서 실행되어 메인 스레드가 종료되면 함께 종료되는 특징을 가짐

다만 메인 스레드가 항상 프로세스와 끝을 함께 하는 것은 아님 JVM의 프로세스는 사용자 스레드가 모두 종료될 때 종료되며, 메인 스레드는 사용자 스레드 중 하나임 만약 멀티 스레드 환경에서 사용자 스레드가 여러 개인 경우 메인 스레드에서 예외가 발생해 전파되더라도 프로세스는 강제 종료되지 않음 (추후 사용자 스레드와 데몬에서 자세히 다룰 예정)

2. 단일 스레드의 한계와 멀티 스레드 프로그래밍

스레드 하나만 사용하는 어플리케이션 → 단일 스레드 어플리케이션

• main 함수를 통해 애플리케이션을 실행하면 메인 스레드를 단일 스레드로 실행

단일 스레드에서 실행되는 어플리케이션은 치명적인 문제가 있음

2-1. 단일 스레드 어플리케이션의 한계

스레드 → 하나의 작업을 실행중일 때 다른 작업을 동시에 수행하지 못함

• 메인 스레드도 마찬가지
• 실행하는 작업이 오래 걸리면 해당 작업이 처리되는 동안 다른 작업을 수행하지 못함 → 응답성 문제 발생 가능

단일 스레드의 응답성 문제

1. 안드로이드 휴대폰에서 동작하는 어플

• 안드로이드 어플의 경우 UI를 그리는 작업과 사용자 상호작용 이벤트 처리를 메인 스레드에서 수행함

• 네트워크 요청 후 응답을 기다리는 작업, 복잡한 연산 작업 등 오래 걸리는 작업을 메인 스레드에서 처리하면 그 동안 UI를 그리는 작업을 할 수 없어 휴대폰이 멈추거나 버벅이는 원인이 됨

  • 실제론 일정 시간동안 응답이 없다면 ANR(Android Not Response)이 발생하나, 이는 다루지 않겠음

2. 서버 사이드 작업

• 클라이언트로 부터 오래 걸리는 작업 요청이 들어왔을 때 단일 스레드만 사용한다면 요청을 처리하는 속도가 늦어져 응답 속도가 늦어짐

*단일 스레드만 사용해 작업할 경우 → 해야 할 작업이 다른 작업에 의해 방해받거나 작업 속도가 느려질 수 있음 *

2-2. 멀티 스레드 프로그래밍을 통한 단일 스레드의 한계 극복

멀티 스레드 프로그래밍 → 스래드를 여러개 사용해 작업을 처리하는 프로그래밍 기법

• 프로세스 → 멀티 스레드 프로그래밍을 통해 여러개의 스레드로 작업을 실행
• 각각의 스레드가 한 번에 하나의 작업을 처리할 수 있으므로 여러 작업을 동시에 처리하는 것이 가능해짐

멀티 스레드를 통한 단일 스레드의 반응성 문제 해결

1. 안드로이드 휴대폰에서 동작하는 어플

• 메인 스레드 대신 별도의 스레드가 처리할 수 있도록 만들어 반응성 문제를 해결
• 오래 걸리는 작업을 백그라운드 스레드에서 처리하도록 만들면 메인 스레드는 오래 걸리는 작업을 처리하지 않아도 되기 때문에 UI가 멈추거나 사용자 입력을 받지 못하는 현상을 방지할 수 있음

2. 서버 사이드 작업

• 오래 걸리는 작업이 요총됐을 때 작업을 스레드 간에 독립적인 작은 작업으로 나눈 후 각 작업이 서로 다른 스레드에서 수행되도록 만들면 응답 속도를 높일 수 있음
• DB 3개를 조회하는 경우 각 스레드가 하나씩 조회한 후 결과를 병합하면 단일 스레드에 비해 빠르게 처리할 수 있음 (병렬 처리)

3. 코루틴이 등장하기 이전의 멀티 스레드 프로그래밍 (스레드, 스레드풀)

말티 스레드 프로그래밍 → 계속 변화해옴 (이전 방식의 한계 극복을 위해)

코루틴 → 멀티 스레드 프로그래밍의 한계를 극복하기 위해 등장

따라서 멀티 스레드 프로그래밍의 변천사를 추적하는 것이 좋음

3-1. Thread 클래스를 사용하는 방법과 한계

1. Thread 클래스를 사용해 스레드 다루기

class ExampleThread : Thread() {
    override fun run() {
        println("${Thread.currentThread().name} 새로운 스레드 시작")
        Thread.sleep(2000L)
        println("${Thread.currentThread().name} 새로운 스레드 종료")
    }
}
// [현재 작업중인 스레드 이름] 새로운 스레드 시작
// (2초 대기)
// [현재 작업중인 스레드 이름] 새로운 스레드 종료

fun main() {
    println("${Thread.currentThread().name} 메인 스레드 시작")
    ExampleThread().start()
    Thread.sleep(1000L)
    println("${Thread.currentThread().name} 메인 스레드 종료")
}

// 결과: 
// [main] 메인 스레드 시작
// [Thread-0] 새로운 스레드 시작
// [main] 메인 스레드 종료
// [Thread-1] 새로운 스레드 종료 

• 메인 스레드와 새로운 스레드의 로그가 섞여 있음

1. “[main] 메인 스레드 시작” 문구 출력
2. 새로운 스레드가 생성되고 “[Thread-0] 새로운 스레드 시작” 문구 출력
3. 1초 뒤 “[main] 메인 스레드 종료” 문구 출력
4. 다시 1초 뒤 “[Thread-0] 새로운 스레드 종료” 문구 출력

사용자 스레드와 데몬 스레드

아까 위에서 “JVM 프로세스는 일반적으로 메인 스레드와 함께 종료된다”라고 했었다. 하지만 Thread 클래스의 예시를 보면 메인 스레드가 먼저 종료되었음에도 Thread-0이 여전히 살아남아 작업을 이어갔다. 이는 메인 스레드와 Thread-0 둘 다 사용자 스레드이기 때문이다.

JVM은 스레드를 사용자 스레드와 데몬 스레드로 구분한다.

사용자 스레드 → 우선도가 높은 스레드

데몬 스레드 → 우선도가 낮은 스레드

JVM 프로세스가 종료되는 시점은 우선도가 높은 사용자 스레드가 모두 종료될 때이다.

단일 스레드 프로그래밍의 경우 메인 스레드만 사용자 스레드이기 때문에 메인 스레드가 종료될 때 JVM 프로세스도 종료되었다.

하지만 멀티 스레드를 사용하는 프로세스에서는 스레드 중 사용자 스레드가 모두 종료되는 시점에 프로세스가 종료된다.

Thread 클래스를 상속한 클래스로 생성한 스레드는 기본적으로 사용자 스레드로 생성된다. 따라서 위의 예시에서 생성된 Thread-0은 사용자 스레드로 생성된다.

사용자 스레드로 생성되었기 때문에 메인 스레드가 종료되었음에도 살아남아서 작업을 이어갔던 것이다.

만약 Thread 클래스를 통해 데몬 스레드를 생성하고 싶다면 isDeamon = true 속성을 적용해주면 된다.

ExampleThread().apply {
    isDeamon = true,
}.start()

위에서 작성했던 예시를 데몬 스레드로 생성하면 다음의 코드와 같이 작성할 수 있다.

fun main() {
    println("${Thread.currentThread().name} 메인 스레드 시작")

    ExampleThread().apply{
        isDeamon = true,
    }.start()

    Thread.sleep(1000L)
    println("${Thread.currentThread().name} 메인 스레드 종료")
}

Thread-0이 데몬 스레드로 생성되었기 때문에 메인 스레드가 종료되면 프로세스도 종료되어 Thread-0이 실행중에 강제로 종료된다.

데몬 스레드는 중요한 스레드가 아니기 때문에 강제 종료되더라도 프로세스가 정상 종료된다.

2. Thread 클래스를 직접 다루는 방법의 한계

1. Thread 클래스를 상속한 클래스를 인스턴스화 해 실행할 때마다 매번 새로운 스레드가 생성됨

• 스레드 → 생성비용이 비쌈
• 매번 새로운 스레드를 생성하는 것은 성능적으로 좋지 않음

2. 스레드 생성과 관리에 대한 책임이 개발자에게 있음

• 프로그램의 복잡성이 증가함
• 실수로 인해 오류나 메모리 누수를 발생시킬 가능성이 증가함

이런 문제들을 해결하려면 한 번 생성한 스레드를 간편하게 재사용할 수 있어야 하고, 스레드의 관리를 구축한 시스템에서 책임질 수 있도록 헤야함

이런 역할을 위해 Executor 프레임워크가 만들어졌음

3-2. Executor 프레임워크를 통해 스레드풀 사용하기

Executor 프레임워크 → 개발자의 스레드 관리 부담 문제 해결과 생성된 스레드 재사용성을 높이기 위해 등장

• 스레드 생성/관리를 위해 스레드풀 개념 도입
• 스레드풀 → 스레드의 집합

스레드풀을 관리하고 사용자로부터 요청받은 작업을 각 스레드에 할당하는 시스템을 더한 것이 Executor 프레임워크임

• 작업 처리를 위해 스레드풀을 미리 생성해 놓고 작업을 요청 받으면 쉬고 있는 스레드에 작업을 분배
• 각 스레드는 작업을 끝내더라도 스레드를 종료하지 않고 다음 작업이 들어오면 재사용됨

스레드풀에 속한 스레드의 생성과 관리 및 분배에 대한 책임을 Executor 프레임워크가 담당

• 개발자는 스레드 관리를 직접 하지 않고 아래의 작업만 수행하면 됨
  • 스레드풀에 속할 스레드의 개수 설정
  • 스레드풀을 관리하는 시스템에 작업을 제출

3-2-1. Executor 프레임워크 사용해 보기

Executor 프레임워크에서 사용자가 사용할 수 있는 함수는 크게 2가지임

1. 스레드풀을 생성하고 생성된 스레드풀을 관리하는 객체를 반환받는 함수 2. 스레드풀을 관리하는 객체에 작업을 제출하는 함수

fun main() {
    val startTime = System.currentTimeMillis()
    val executorService: ExecutorService = Executors.newFixedThreadPool(2)

    // 작업1 제출
    executorService.submit {
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업 1 시작")
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업 1 완료")
    }

    // 작업2 제출
    executorService.submit {
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업 2 시작")
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업 2 완료")
    }

    executorService.shutdown() // 제출된 작업이 모두 끝난 뒤에는 ExecutorService가 종료될 수 있도록 shutdown 함수를 호출
}

fun getElapsedTime(startTime: Long): String = 
    "지난 시간: ${System.currentTimeMiilis() - startTime}ms"

/*
[pool-1-thread-1][지난 시간: 4ms] 작업1 시작
[pool-2-thread-1][지난 시간: 4ms] 작업2 시작
[pool-1-thread-1][지난 시간: 1009ms] 작업1 완료
[pool-2-thread-1][지난 시간: 1009ms] 작업2 완료
*/

// 서로 다른 스레드에서 실행되기 때문에 출력 순서, 사용 스레드는 다를 수 있음

• 작업1과 작업2는 각각 서로 다른 스레드에서 실행됐음을 알 수 있음
• 종료 시간을 통해 두 작업이 병렬로 실행됐음을 알 수 있음

fun main() {
    val startTime = System.currentTimeMillis()
    val executorService: ExecutorService = Executors.newFixedThreadPool(2)

    // 작업1 제출
    executorService.submit {
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업1 시작")
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업1 완료")
    }

    // 작업2 제출
    executorService.submit {
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업2 시작")
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업2 완료")
    }

    // 작업3 제출
    executorService.submit {
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업3 시작")
        Thread.sleep(1000L)
        println("[${Thread.currentThread().name()}][${getElapsedTime(startTime)}] 작업3 완료")
    }

    executorService.shutdown() // 제출된 작업이 모두 끝난 뒤에는 ExecutorService가 종료될 수 있도록 shutdown 함수를 호출
}

fun getElapsedTime(startTime: Long): String = 
    "지난 시간: ${System.currentTimeMiilis() - startTime}ms"

/*
[pool-1-thread-1][지난 시간: 4ms] 작업1 시작
[pool-2-thread-1][지난 시간: 4ms] 작업2 시작
[pool-1-thread-1][지난 시간: 1009ms] 작업1 완료
[pool-2-thread-1][지난 시간: 1011ms] 작업2 완료
[pool-1-thread-1][지난 시간: 1012ms] 작업3 완료
[pool-1-thread-1][지난 시간: 2016ms] 작업3 완료
*/

• 작업3이 추가될 경우 작업1과 작업2는 동시에 실행되지만 작업 3은 1이 완료된 후에 실행되는 것을 알 수 있음
• 작업3이 실행 요청됐을 때 스레드풀에 있느 ㄴ스레드 2개가 이미 작업1과 작업2를 처리하는 중이었기 때문임

3-2-2. ExecutorService 내부 구조와 동작

• 작업이 제출되면 작업 대기열에 적재됨
• 작업 대기열에 들어간 작업은 스레드로 할당되기를 기다림
• 스레드풀에 쉬고있는 스레드가 있다면 작업을 할당함
• 모든 스레드에 작업이 할당되어 있을 때 새로운 작업이 작업 대기열에 들어오면 스레드의 작업이 끝날 때까지 작업 대기열에서 대기함

위의 일련의 동작을 개발자는 전혀 신경쓰지 않아도 됨

스레드를 분배하는 일은 ExecutorService 객체가 알아서 함

3-2-3. Executor 프레임워크의 의의와 한계

Executor 프레임워크는 개발자의 스레드 관리 부담을 해결하고 스레드 재사용을 편하게 할 수 있도록 만들었다는 점에서 혁신적임

하지만 스레드 블로킹이라는 문제가 존재함

스레드 블로킹

스레드가 아무것도 하지 못하고 사용될 수 없는 상태에 있는 것을 의미함

• 스레드는 비싼 자원이기 때문에 사용될 수 없는 상태에 놓이는 것이 반복되면 애플리케이션 성능 하락의 원인이 될 수 있음

스레드 블로킹을 발생시키는 원인

• 여러 스레드가 동기화 블록에 동시에 접근하는 경우 (Race-condition)
• Mutex 또는 Semaphore로 인해 공유되는 자워에 접근할 수 있는 스레드가 제한되는 경우

Executor 프레임워크에서 스레드 블로킹이 종종 발생함

• 작업의 결과를 전달받을 때는 Future객체를 통해 언제 올지 모르는 값을 기다려야 함
  • Future 객체의 get 함수를 호출한 스레드는 결과값을 반환받을 때까지 블로킹됨

3. 이후의 멀티 스레드 프로그래밍과 한계

Executor 프레임워크 이후에도 멀티 스레드 프로그래밍의 문제를 보완하기 위한 다양한 방법이 만들어졌음

• 기존 Future 객체의 스레드 블로킹을 줄이고 작업 체이닝 기능을 제공하는 CompletableFuture
• 결괏값을 데이터 스트림으로 처리해 스레드 블로킹을 방지하고 스레드풀을 손쉽게 전환할 수 있도록 한 RxJava

이 외에도 다양한 멀티 스레드 프로그래밍 방법이 등장했었음

다루지 않는 이유는 지금까지 다룬 내용들이 코루틴과 관련해서 알아야 할 중요하고 근본적인 한 가지 문제점을 갖는 녀석들이기 때문

아래에서는 이 “근본적인 문제점”을 다룸

4. 기존 멀티 스레드 프로그래밍의 한계와 코루틴

4-1. 기존 멀티 스레드 프로그래밍의 한계

멀티 스레드 프로그래밍은 단점을 보완하며 발전해 왔음

하지만 기존 멀티 스레드 프로그래밍은 스레드 기반으로 작업한다는 한계가 있음

“멀티 스레드 프로그래밍이 단일 스레드 프로그래밍의 문제를 해결하기 위해 생겼다면서 스레드 기반 작업이 왜 한계인가?”

스레드는 생성과 전환 비용이 비쌈

• 스레드가 아무 작업도 하지 않고 대기하고 있다면 컴퓨터의 자원이 낭비됨
• 한 스레드가 다른 스레드의 작업의 결과를 받기 위해 대기하고 있다면 스레드 블로킹이 발생한 것
• 스레드 블로킹은 스레드라는 비싼 자원을 사용할 수 없게 만든 다는 점에서 성능에 매우 치명적인 영향을 줌

스레드 블로킹은 스레드 기반 작업을 하는 멀티 스레드 프로그래밍에서 피할 수 없는 문제임

• 간단한 작업에서는 콜백, 체이닝 등을 통해 이를 회피할 수는 있지만,
• 작업이 많아지고 작업 간의 종속성이 복잡해질수록 스레드 블로킹을 피하기 어렵고, 스레드의 성능을 제대로 발휘할 수 없을 수도 있음
• 실제 애플리케이션에선 작업간의 종속성이 복잡하고 네트워크 작업도 수없이 많기 때문에 스레드 블록킹의 발생은 필연적이라 할 수 있음

체이닝 함수

한 함수의 수행 결과를 다른 함수로 연결해 호출하는데 사용

• 함수가 실행 완료됐을 때 실행할 콜백 함수를 등록하는 느낌

fun main() {
    val startTime = System.currentTimeMillis()
    val excutor = Excutor.newFixedThreadPool(2)

    val completableFuture = CompletableFuture.supplyAsync({
        Thread.sleep(1000L)
        return@supplyAsync "결과"
    }, executor)

    completableFuture.thenAccept { result -> 
        println("[${getElapsedTime(startTime)}] $result 처리")
    }

    println("[${getElapsedTime(startTime)}] $result 처리")

    executor.shutdown()
}

/*
[지난 시간: 11ms] 다른 작업 실행
[지난 시간: 1008ms]
*/

2. 코루틴은 스레드 블로킹 문제를 어떻게 극복하는가?

작업 단위 코루틴을 통해 스레드 블로킹 문제를 해결

• 작업 단위 코루틴 → 스레드에서 작업 실행 도중 일시 중단할 수 있는 작업 단위
• 코루틴은 작업이 일시 중단되면 스레드 사용 권한을 양보
• 양보된 스레드는 다른 작업을 실행하는 데 사용할 수 있음
• 일시 중단된 코루틴 → 작업 재개 시점에 다시 스레드에 할당돼 실행

코루틴은 경량 스레드라고 불린다.

• 코루틴을 코루틴 스케쥴러에 넘기면 사용할 수 있는 스레드나 스레드풀에 해당 코루틴을 분배해 작업을 수행
• 코루틴은 실행 도중 중단될 수 있기 때문에 해당 코루틴이 사용중이던 스레드를 다른 코루틴에 양보하는 것이 가능하기 때문에 스레드 블로킹이 발생하지 않음

코루틴과 멀티 스레드 프로그래밍 비교

코루틴이 경량 스레드라고 불리는 이유 정리

• 코루틴은 스레드를 사용하고 있지 않을 때 스레드 사용 권한을 양보함
  • 스레드 사용 최적화
  • 스레드 블로킹 방지
• 코루틴은 스레드에 비해 생성과 전환 비용이 적게 들고, 스레드에 붙였다 땠다 할 수 있어 작업을 생성하고 전환하는 데 필요한 리소스와 시간이 매우 줄어듬

5. 1장 요약

1. JVM 상에서 실행되는 코틀린 애플리케이션 → 메인 스레드에서 실행
2. 단일 스레드는 한번에 하나의 작업만 수행할 수 있음 → 복잡한 작업이나 시간이 오래 걸리는 작업을 수행하면 응답성이 떨어질 수 있음
3. 멀티 스레드를 통해 2번의 문제를 해결할 수 있음
4. Thread 클래스를 상속해 스레드를 생성하고 관리할 수 있으나 생성된 스레드의 재사용이 어려워 리소스 낭비를 일으킴
5. Executor 프레임워크는 스레드풀을 통해 스레드의 생성과 관리를 최적화하고 스레드의 재사용성을 높임
6. 하지만 기존 멀티 스레드 프로그래밍 방식들은 스레드 블로킹이라는 문제를 근본적으로 해결하지 못했음
7. 스레드 블로킹 → 스레드가 작업을 기다리면서 리소스를 낭비하지만 아무 일도 하지 않는 상태
8. 코루틴은 스레드 블로킹 문재를 해결하기 위해 등장함
9. 코루틴은 스레드 사용 권한을 양보하고 작업을 일시 중단해 다른 작업이 스레드를 사용할 수 있도록 함
10. 일시 중단 후 재개된 코루틴은 재개 시점에 사용할 수 있는 스레드에 할당됨
11. 코루틴은 스레드에 비해 생성과 전환 비용이 적게 들고 스레드에 자유룝게 땠다 붙였다 할 수 있어 경량 스레드라고 불림
12. 코루틴을 통해 스레드 블로킹을 방지할 수 있어 애플리케이션의 응답성을 높일 수 있음

1달동안 뭐했니? (7주차 회고)

처음 벨로그를 개설할 때만 해도 "주마다 한번씩 회고록 써야지!"라며 당차게 시작했었는데...

빡빡한 일정, 올라가는 난이도, 점점 부족해지는 체력 등 이런저런 핑계를 대며

"미션할 시간도 없는데 회고록을 어떻게 써?"라고 스스로를 달래며 회피하다가

이대로는 안된다는 생각이 들어 간만에 끄적이게 된 회고록입니다.

성장했다고 생각하는 부분

다형성이 어떤 녀석인지 조금 알 것 같다.

대학교 4년동안 컴퓨터 공학 전공으로 대학을 다니며 수도 없이 들어왔던 interface, 상속.

언제, 어떻게, 왜 써야 하는지를 몰라 작업할 때 스스로 떠올려내 써 본 기억이 없는 친구입니다.

(마치 이름은 많이 들어봤는데 대화는 해본 적 없어 서먹서먹한 고등학교 동창같은 느낌...)

이 동창 녀석에 대해 이해하게 된 계기는 지난 6주차에 진행한 "칸반 보드 관리"미션에서

레아가 수업해준 다형성을 통한 조건문 줄이기 라이브 코딩의 도움이 컸습니다.

갓.레.아

동일한 관심사를 갖고 비슷한 역할을 하지만 내부에서 가져야 할 상태가 다른 녀석을 구현할 때

다형성을 사용하면 유용하다는 걸 수업을 통해 알 수 있었고,

테코톡 일정으로 남들보다 미션 진행이 뒤쳐져 있었던 저는

다른 크루들은 각자의 기준과 고민을 통해 요구사항을 구현하고 있을 때

조금 치사하지만 레아의 수업을 듣고 이 규칙들을 어떻게 구현할지 고민하는 시간을 건너 뛰었습니다.

하지만 수업에서 라이브 코딩으로 보여준 예시를 완전히 그대로 쓰는 건 의미가 없을 것 같아 구조를 조금 수정해서 제 코드에 적용했습니다.

interface TaskRules {
    val isDeletable: Boolean

    fun moveTo(targetStatus: TaskStatus): TaskRules

    val requireAssignee: Boolean
}

class Todo : TaskRules {
    override val isDeletable: Boolean = true

    override fun moveTo(targetStatus: TaskStatus): TaskRules {
        return when (targetStatus) {
            TaskStatus.TO_DO -> this
            TaskStatus.IN_PROGRESS -> InProgress()
            TaskStatus.REVIEW, TaskStatus.DONE -> throw IllegalStateException()
        }
    }

    override val requireAssignee: Boolean = false
}
.
.
.

이 구현체 까지는 별 차이가 없습니다.

라이브 코딩에선 이 규칙의 구현체가 task 객체를 들고 있었는데

"규칙이 task 객체를 들고 있다." 라는 문장에서 기시감을 느껴

저는 이 규칙들을 task 객체가 들고 있도록 구조를 변경했습니다.

data class KanbanTask(val data: TaskData, val status: TaskStatus) {
    private var taskRules: TaskRules = when (status) {
        TaskStatus.TO_DO -> Todo()
        TaskStatus.IN_PROGRESS -> InProgress()
        TaskStatus.REVIEW -> Review()
        TaskStatus.DONE -> Done()
    }

    val isDeletable get() = taskRules.isDeletable

    init {
        validateAssignee(taskRules, data)
    }

    fun changeStatus(targetStatue: TaskStatus): KanbanTask {
        val nextRules = taskRules.moveTo(targetStatue)

        validateAssignee(nextRules, data)
        taskRules = nextRules

        return copy(status = targetStatue)
    }

이렇게 구조를 수정해도 괜찮을까? 라는 걱정도 있었지만 일단 해봤고 미션을 제출했습니다.

물론 엄청나게 많은 피드백을 받고, 고쳐야할 부분도 많았습니다.

그런데 리뷰어한테서

상태전이에 대한 규칙을 상태패턴으로 적용한 점이 좋았습니다 👍 덕분에 도메인과 UI로직이 잘 분리되어 있네요.

라는 피드백을 받았습니다.

... 정말 기분이 좋았습니다.

상태 전이 규칙 관련한 대부분의 코드가 레아의 라이브 코딩에서 따온 코드이긴 해도

스스로 고민하고 구조를 바꿔서 적용하기로 한 판단이 좋게 받아 들여졌다는 사실에 입가에 미소가 번졌습니다.

이렇게 얻은 다형성에 대한 자신감으로 다음 미션에도 다형성을 활용 했습니다.

영화 예매 미션에서 배운 점

다음 미션인 영화 예매 미션은 총 4단계로 구성되어 있었습니다.

1단계: 도메인 설계 2단계: view와 controller 구현 3단계: DB에 연결 4단계: Spring boot를 통한 REST API 구현

3, 4단계 마감이 얼마 남지 않았지만 아직 1, 2단계 병합도 안된 막막한 미션...

이 미션에는 여러 할인 정책, 좌석 별 가격에 대한 요구사항이 있었고,

얼핏보기에 interface-class 구조로 구현하기 좋아 보이는 녀석들 이었습니다.

그래서 저는 이 녀석들을 다형성으로 제작하자고 페어에게 적극 주장했고 페어가 이를 받아줘

해보고 싶은데로 코드를 작성 할 수 있었습니다. (고마워요 신밧드)

이렇게 그렇게 두 요구사항 모두 interface-class 구조로 구현하고 미션을 제출했습니다.

다형성도 너무 남발하면 좋지 않다

interface SeatGrade {
    val price: Money
}

class GradeS : SeatGrade {
    override val price: Money = Money(SeatPrice.PRICE_S)
}

class GradeA : SeatGrade {
    override val price: Money = Money(SeatPrice.PRICE_A)
}

class GradeB : SeatGrade {
    override val price: Money = Money(SeatPrice.PRICE_B)
}

이 코드는 저와 페어가 작성한 좌석별 금액에 대한 interface와 그 구현체입니다.

겉보기엔 깔끔하고 이뻐보였습니다. 하지만 리뷰어는 이 코드에 대해

interface - class 구조로 만들 필요가 있었을까요? 다른 구현의 선택지는 없을지 고민해보시면 좋겠어요.

라고 피드백을 받았습니다.

이 피드백을 읽고 "다형성을 쓰기엔 과한 부분"이라는 생각이 들었습니다.

의자의 등급은 가격을 들고만 있지, 그 가격으로 어떤 행위를 하는 녀석이 아니었습니다.

할인 정책의 경우 할인률을 갖고 입력 받은 가격에 할인을 "적용해주는" 행위를 들고 있기라도 하지

이 녀석은 상태만 들고 있는 녀석이라 interface-class로 구현하는게 과했다고 생각합니다.

OCP도 조금은 알 것 같다,,?!

Open Close Principle? 확장에는 열려있고 수정에는 닫혀있다?? 그게 뭔데;;;

라고 생각하며 OCP라는 게 있다~ 정도만 생각하고 있다가 정말 생각치 못하게 깨달음을 었었습니다.

controller를 구현하는 과정에서 생성된 예약들을 controller에서 들고 있었고,

저는 이게 정말 맘에 들지 않아 어떻게 수정할지 고민하다가 크루에게 도움을 청했습니다.

"이거 너무 맘에 안드는데 어떻게 생각하세요??"

그 크루도 controller에서 상태를 직접 들고 있는건 좋지 않다고 동의 해줬고 어떤 해결 방법이 있는지 힌트도 주었습니다.

그 힌트 중 domain에 대한 피드백도 있었습니다.

class PayCalculator(
    private val reservations: List<Reservation>,
) {
    private var totalPrice: Money = Money(0)
    private val timeDiscountPolicy = TimeDiscountPolicy()
    private val movieDayDiscountPolicy = MovieDayDiscountPolicy()
    private val cardDiscountPolicy = CardDiscountPolicy()
    private val cashDiscountPolicy = CashDiscountPolicy()

가격을 계산해 주는 객체에서 할인 정책들을 프로퍼티로 직접 들고 있었는데 이 부분을 짚어주며

유연하지 않다고 해주었습니다.

리뷰어에게도 같은 부분에 같은 리뷰를 받았었기 때문에 이를 어떻게 해결해야 할지 조언을 구했습니다.

크루가 해준 조언은 "외부에서 파라미터로 주입 받아라"였습니다.

이 말을 듣고 OCP에 대해 조금은 감을 잡은 것 같습니다.

OCP는 뭐다! 라고 명쾌하게 정의하지 못하지만 정책같은 것들을 객체에 직접 선언하여 고정 하지 말자 라는 건 알 것 같습니다.

class PayCalculator {
    fun calculateInitPrice(reservations: List<Reservation>): Money {
        var initPrice = Money(0)

        for (reservation in reservations) {
            val info = reservation.getReservationInfo()
            initPrice += info.price
        }

        return initPrice
    }

    fun calculateTimeDiscountedPrice(
        price: Money,
        reservations: List<Reservation>,
        discountPolicies: List<DiscountPolicy>,
    ): Money {
        var discountedPrice = price
        for (reservation in reservations) {
            for (discountPolicy in discountPolicies) {
                discountedPrice = discountPolicy.applyDiscount(discountedPrice, reservation)
            }
        }

        return discountedPrice
    }

피드백과 조언들을 반영한 코드입니다.

할인 정책은 같은 interface를 공유한다는 점을 이용해 정책들을 list 형태로 주입받아 적용하도록 코드를 수정했습니다.

하지만 여기서 걸리는 점은 list로 받으면 할인을 적용하는 순서가 list에 저장된 순서에 의해 결정된다는 것입니다.

이 문제에 대해선 아직 더 고민을 해봐야 할 것 같습니다.

아무튼 "확장에는 열려있고 변경에는 닫혀있다" 라는 문장이 코드에 어떻게 반영되는지

느낌을 알 것 같습니다. 한문장으로 정의하기엔 아직 깨달음이 부족합니다...

마무리

시골에서 올라와 바쁜 도시 생활에 차차 적응되면서도

한편으론 지치기도 하고 잘 해내고 있는지 의문이 들기도 하는 한달 이었습니다.

아직 공부해야할 것도 산더미고 해야할 일도 많고 신경써야 하는 것도 많아 정신이 없지만

레벨 1의 마지막을 잘 마무리 할 수 있기를 바라며

1달을 건너뛰고 쓰는 회고록을 마칩니다.

(회고 쓰면서 발견 했는데 PayCalculator에 오류가...)

크루 닉네임 투핸더입니다. 주말동안 야무지게 놀다가 일요일 밤 자기 전에 생각나서 끄적이는 회고록입니다. 일요일에 적다가 미션 제출 찐빠나서 월요일에 마무리했다.

이번 주엔 뭘 했지?

1. SS 연극
2. 안드로이드 트랙 미션 시작 (KanbanBoard Mission)
   • 첫 번째 PR 제출 및 피드백 반영
   • 두 번째 PR 제출
3. SS 워크샵 (학습 마인드셋, 단점 개선을 위한 단기적 실험 계획 세우기)

Keep

• 연극조 크루들 외에도 다른 안드로이드 트랙 크루들과도 이래저래 대화 나누면서 친해진 것 같아서 기분이 좋습니다.
• 학습 마인드셋 가져가기
  • “우테코에 가면 나보다 경험도 많고 개발적으로도, 사회인으로서도 나보다 성숙한 사람이 많을 텐데 그 사람들을 보면서 내 부족한 점을 파악하고 그 사람들의 행동으로 부터 배우자!” 라는 다짐을 우테코 시작 전부터 가지고 있었습니다. 모르는 것도 많고 개발자로써도, 사회인으로써도 부족한 점이 많지만 여러 크루들로부터 배우고 성장하겠습니다. 또한 우테코 생활에서 도움의 손길을 선뜻 내어주시는 여러 크루들에게 감사하다는 말을 전하고 싶습니다!!

Problem

• 과제 진행 과정에서 실수가 많다. (대부분 마음이 급해서 발생한 실수들인 것 같습니다…)
  • 레포를 로컬로 가져와서 브랜치의 현제 상태를 원격 저장소와 sync 시키고 나서 작업을 했어야 하는데 그냥 진행해서 원격 저장소에 push가 안되는 일이 있었습니다. 이 때도 크루에게 도움을 받아 문제를 해결하고 미션 결과물을 제출할 수 있었습니다.
  • 이번 미션의 2단계 미션을 집에서 진행하고 PR을 생성한 후 리뷰 요청을 남겼는데 slack 리뷰 요청에 대한 메세지가 남지 않아 뭔가 이상함을 느끼고 있었습니다. 이 때 slack에 한 크루로부터 개인 DM 하나가 날아왔습니다. 제가 생성한 PR을 보고 제 PR이 개인 브랜치가 아닌 main 브랜치로 생성되있는 점을 짚어주셔서 문제점을 파악하고 해결할 수 있었습니다.

Try

• 뭔가 일을 하기 전에 해야할 일을 정리하고 마음을 가다듬기
  • 마음만 급해서 확인해야 할 요소 또는 선행 과제를 체크하지 않고 일단 진행했다가 피를 많이 봤습니다. 우테코의 여러 피로 쓰인 규칙과 팁들이 왜 생긴 건지 직접 체감할 수 있었습니다…
  • 이제부턴 미션을 수행하기 전에 요구사항을 정독하고 체크리스트를 만들어 수행해야 할 일과 수행한 일을 관리해보려 합니다.

마무리하며

다른 사람들 보다 뒤쳐지진 않을까, 내가 잘 하고 있는 걸까, 돈 문제 등등 여러 걱정들 때문에 마음이 급해져 허둥대다가 끝난 한 주였습니다.

다음 주를 여유롭게 시작하고 싶어 주말에 과제를 해 놓고 브랜치 분리라던지 README 최신화 라던지 이래저래 빼먹고 머지시킬 브랜치도 틀리고 북치고 장구치고 하다가 새벽까지 문제 해결하고 늦게 자고 등등 많은 일들이 있었습니다.

그 와중에 제가 실수했다는 걸 저보다 빨리 캐치해 알려주신 안드로이드 크루에게 감사드립니다… (사람 여러번 살리셨습니다 아키….)

쥐뿔도 모르는 상태로 시작한 우테코에서 많은 분들의 도움을 받으며 하루하루 넘기고 있는 요즘입니다. 이러다 보면 언젠가 성장해있는 저를 만날 수 있겠죠? 화이팅 하겠습니다. 😌😌

2026-03-01에 작성한 회고록입니다.

안녕하세요! 저는 ‘투핸더’입니다.

우테코 레벨 1이 시작되고 한 주가 지났습니다.

지난 일주일간 어떤 걸 했고 뭘 느꼈는지 정리하고 공유하고자 합니다.

무엇을 했나?

• 우테코 OT

  • 여러 코치님들의 닉네임과 앞으로의 생활이 어떤 식으로 흘러갈지 알 수 있었습니다.

• 온보딩 미션 (연극, Gemini 웹앱 제작)

  • 다음 주에 연극을 하는데 저희 조는 메시지보단 “일단 웃기자!”라는 생각으로 준비했습니다.
  • 웹앱 4개를 만들었는데 개인적으로 퀄리티가 많이 아쉽습니다. 미션 요구사항을 체크하고 빠르게 구현에 들어갔어야 하는데 요구사항을 반복해서 읽느라 구현에 할애해도 아쉬운 시간을 만족스럽게 쓰지 못했습니다.

• README 작업 (프로젝트, 졸업 작품)

  • 프로젝트를 진행하면서 미루고 미루던 작업을 주말 동안 몰아서 하느라 죽을 맛이었습니다…
  • 졸업 작품
  • 팀 프로젝트

Keep

적어보려고 이것저것 떠올려 봤지만 뭔가 “나 이거 잘했다!” 라고 하기엔 당연한 것들인 거 같아서 이번엔 패스하겠습니다.

Problem

1. 까먹는다. 너무 잘..

우테코가 2월 24일 화요일에 시작돼 4일 동안 출근했고 이 짧은 시간 동안에도 생각보다 할 게 많았습니다.

웹앱도 만들어야 하고, 연극도 준비해야 하고, 책도 읽어야 하고…

이런저런 일들을 다른 사람들과 같이 하다 보니 그 과정에서 정말 많은 대화를 하게 되는데,

방금 대화하고 뒤돌아서면 얼마 지나지 않아 대부분의 내용을 까먹고 이후 작업을 할 때 여러 번 되물었던 것 같습니다.

물어봤던 걸 또 물어보고, 또 기억 안 나서 다시 물어보자니 시간을 뺏는 것 같아 죄송하고 참 난감한 상황을 마주했었습니다.

2. 요구사항을 정확히 파악하지 않는다.

우테코에서 미션을 진행하려면 LMS에서 미션을 확인한 다음 구현하는 형식으로 흘러가는 것 같습니다.

이번 주에 진행한 Gemini 웹앱 미션도 LMS에서 자세한 내용을 확인할 수 있었고, 제가 온 신경을 쏟은 부분은 구현 요구사항이었습니다.

하지만 우테코의 미션에는 구현 외에도 제출 이후에 해야 할 일들, 피드백 반영, 피드백에 대한 소감 등 해야 할 추가적인 일들이 있었고, 이를 뒤늦게 알아차려 시간이 얼마 남지 않았거나 시간이 지난 후에 작업을 부랴부랴 진행했습니다.

Try

1. 일단 적어두자. 이런거 저런거 다

2개의 Problem에 모두 적용할 수 있는 방법입니다.

간단한 토론, 공지사항, 미션 요구사항 등을 요약하고 기록해 놓으면 하루를 시작할 때 오늘 할 일을 정리 해놓거나 앞으로 해야 할 일들을 정리하는데 도움이 될 거라 생각합니다.

이를 실천하기 위해 26일 목요일부터 Daily Diary를 적고 있습니다.

하루를 시작할 때 1차적으로 TODO를 기록하고 일과를 진행하면서 틈틈히 체크하고 추가하면서 할 일을 관리하고 있습니다.

2. 미션 시작 전 요구사항을 정리한 문서를 만들기

본격적으로 미션을 수행하기 전에 LMS의 공지글을 정리하고 작업을 시작해보려 합니다.

아직 템플릿을 구체화하진 않았지만, 간단히 생각해보자면

1. 요구사항
2. TODO
3. 제출 체크리스트
4. 제출 후 해야할 일

이 정도를 작성해놓을 것 같습니다.

마무리하며

4일이라는 짧은 시간동안 우테코를 찍먹 해봤는데, 그 짧은 시간 동안 스스로 부족한 점, 고치면 좋을 점 등 성장할 수 있는 방법들을 몇 개 발견할 수 있었습니다.

첫 주 미션으로 “유연함의 힘”이라는 도서를 읽는 미션도 있었는데, 읽으면서 앞으로의 마인드 셋을 어떻게 잡아야 할지도 감이 오는 것 같습니다.

정말 많은 것들이 몰아쳐서 연극 조 크루들과는 대화를 많이 한 것 같은데 다른 크루들과는 크게 대화를 못해서 아쉽다는 생각도 듭니다.

하지만 한편으론 이름과 얼굴을 잘 기억하지 못하는 점 때문에 여러 크루와 왁왁 대화를 해도 내일 내가 그 크루의 닉네임을 기억할 수 있을까? 하는 걱정도 피어오릅니다.

먼저 다가가는 것은 자신 있지만 그러고 나서 투페이스 마냥 다음 날 닉네임을 기억하지 못하더라도 미워하지 말아 주세요…😂😂

앞으로 잘 부탁드립니다!!

공부를 계획만큼 하지 못했다…

처음 계획을 세울 당시에는 “분량이 많긴 해도 열심히 하면 4주 안에 할 수 있지 않을까?”하는 생각으로 계획을 세웠습니다.

하지만 언제나 그렇듯 현실은 계획대로 흘러가지 않았고, 계획을 세울 당시에 생각나지 않았던 일정, 생각하지 못한 변수 등 여러 요소들로 인해 처음 계획한 분량의 대략 70% 정도 학습을 진행했습니다.

계획은 못 지켰지만 얻은 건 많다!

일단 가장 큰 건 규칙적인 생활이 어느 정도 자리를 잡았다는 것입니다.

종강만 하면 놀지 못한 것이 아쉬워 밤늦게까지 게임을 하고 다음 날 점심은 돼서야 눈을 떴었는데

레벨 0을 진행하면서 이런 생활 습관에서 벗어나 아침에 침대에서 일어나 집안일을 하고 공부를 하는 등 부지런한 생활을 할 수 있는 기반이 만들어졌습니다.

한 주를 마무리하며 적는 회고록에서도 얻은 것이 있습니다.

해결해야 하는 일이 있거나 문제가 있을 때 이를 따로 기록해두지 않아 잊혀진 것들이 많았는데 회고록을 작성하면서 문제점들을 글로 작성하니 문제를 잊지 않고 개선하기 위해 노력을 할 수 있었습니다.

회고록을 작성하며 스스로를 돌아보고 돌아본 내용을 글로 적는 것이 어떻게 도움이 되는지 직접 느끼며 앞으로의 여정에서 방향을 잃지 않을 수 있는 이정표를 만들어갈 수 있겠다는 생각이 듭니다.

앞으로의 숙제

• 못 다한 공부 이어가기

  처음 계획 세운 공부를 마치지 못했지만 여기서 끝내지 않고 하루 30분이라도 시간을 내어 코틀린 공부를 이어 나갈 생각입니다. 물론 우테코 과정을 진행하다 보면 자연스레 공부하게 될 수도 있지만 처음 공부하는 것과 한 번 공부한 내용을 다시 다루는 것에는 큰 차이가 있을 거라 생각해 교재를 끝까지 정독하려 합니다.

• 계획을 지키지 못했을 때 실현 가능한 범위로 분할하기

  레벨 0을 진행하는 동안 계획을 지키지 못한 상황에서 저는 계획을 수정하기보다는 최초의 계획을 따라가기 위해 공부를 강행했습니다. 이렇게 해보니 의욕이 생기기보다는 공부해야 할 양에 짓눌려 의지도 떨어지고, 계획을 지키지 못할 현실이 보이니 점점 집중력도 떨어지는 것을 경험했습니다. 그래서 앞으로는 계획을 수행하는 데 차질이 생기면 현재 상황을 분석하고 대략적인 가용 시간을 작성해 실현 가능한 목표를 재구성하여 의지와 집중력이 떨어지지 않도록 계획을 수정하는 연습을 해보려 합니다.

입학을 하루 앞두고 한 특별한 경험

실제로 출근하기 전 버스 노선 점검과 이동 소요 시간 등을 확인하기 위해 사전 답사 차원으로 우아한 형제들 사옥을 다녀왔습니다.

직접 두 눈으로 보니 앞으로 이곳으로 출퇴근 한다는 사실이 실감났습니다.

사옥 앞에 저와 마찬가지로 사옥을 촬영하고 있는 사람들이 있었습니다.

같이 우테코를 진행하시는 분들이지 않을까 하여 먼저 다가가 말을 걸었습니다.

다행히 두 분 모두 8기 크루 분들이었고 간단한 스몰 토킹을 할 수 있었습니다.

(BE 정콩이님, FE 도넛님 만나서 정말 반가웠습니다!! ㅋㅋㅋㅋㅋ)

간단한 스몰 토킹 후 두 분께서 카페 가서 같이 공부하자고 먼저 권해주셔서 혼자 할 예정이었던 공부를 다른 사람과 함께 할 수 있어서 외롭지 않았습니다! ㅋㅋㅋㅋㅋㅋ

말주변이 없어 먼저 질문을 하지 못했지만 먼저 이런저런 것들을 질문해주시며 대화를 이끌어주셔서 즐겁게 답사를 진행할 수 있었습니다!! 😆😆

오늘의 경험이 정말 특별하고 즐거웠습니다. 앞으로 쌓아가야 할 인연들에 “내가 잘 할 수 있을까?” 하는 걱정이 있었지만 오늘 만난 소중한 인연 덕분에 걱정에서 기대로 변할 수 있었습니다.

아직 미숙하고 아는 것도 많이 없는 시골 출신 개발자 지망생이지만 소중한 인연으로 기억될 수 있도록 노력하겠습니다!

10개월의 여정 잘 부탁드립니다!!

어노테이션을 적용해 선언에 표지 남기기

• 어노테이션 적용 방법 → @와 어노테이션 이름을 선언 앞에 작성

@annotaionName
/*선언부*/

• 함수, 클래스 등 여러 코드 구성 요소에 어노테이션 적용 가능

• JUnit 프레임워크와 kotlin.test를 사용한다면 테스트 메서드 앞에 “@test”를 붙일 수 있음

import kotlin.test.*

class MyTest{
        @test // 어놑이션을 통해 JUnit 프레임워크에 이 메서드를 테스트로 호출하라고 지시
        fun testTrue() {
                assertTrue(1 + 1 == 2)
        }
} 

@Deprecated 어노테이션

• 주석이 달린 선언을 더 이상 사용하지 않음으로 표시

• 선언이 다른 선언에 의해 대체 되었거나 해당 기능을 더 이상 지원하지 않게 됐음

• 최대 3가지의 파라미터를 받음

    @Target(allowedTargets = [AnnotationTarget.CLASS, AnnotationTarget.FUNCTION, AnnotationTarget.PROPERTY, AnnotationTarget.ANNOTATION_CLASS, AnnotationTarget.CONSTRUCTOR, AnnotationTarget.PROPERTY_SETTER, AnnotationTarget.PROPERTY_GETTER, AnnotationTarget.TYPEALIAS])
    annotation class Deprecated(
        val message: String, 
        val replaceWith: ReplaceWith = ReplaceWith(""), 
        val level: DeprecationLevel = DeprecationLevel.WARNING
    )

  1. message → 사용 중단의 이유 설명 및 대체 API 사용을 권장하는 메시지
  2. replaceWith (선택적) → 더 이상 사용하지 않을 API를 대체할 코드 조각을 지정
  3. level → 점진적인 사용 중단
     • level의 단계
       1. WARNING(경고) → 사용자에게 경고를 보내지만 컴파일이나 런타임이 중단되진 않음
       2. ERROR(오류 )→ 이 선언을 사용하는 새로운 코드가 컴파일 되지 못하게 막음
       3. HIDDEN(숨김) → API가 컴파일된 코드가 남아 예전에 컴파일된 코드와의 이진 호환성을 유지

• @Deprecated 예시

@Deprecated ("Use RemoveAt(index) instead.", ReplaceWith("removeAt(index)"))
fun remove(index: Int) { /*...*/ }

• 이런 선언이 있는 경우 remove함수를 사용하면

어노테이션의 인자

• 기본 타입의 값
• 문자열 이넘
• 클래스 참조
• 다른 어노테이션 클래스
• 위 요소들의 배열

1. 클래스를 어노테이션 인자로 지정 → @MyAnnotation(MyClass::class)
2. 다른 어노테이션을 인자로 지정
   • @Deprecated의 replaceWith도 어노테이션임
   • 어노테이션 이름 앞에 @를 붙이지 않음
3. 배열을 인자로 지정
   • @RequestMapping(path = [”/foo”, “/bar”])의 형식
   • 각괄호를 사용하거나 arrayOf() 함수를 사용할 수 있음
   • 자바에 선언한 어노테이션 클래스를 사용하면 value 파라미터가 필요에 따라 자동으로 가변 길이 인자로 변환됨

어노테이션 인자 → 컴파일 시점에 알 수 있어야 함

• 임의의 프로퍼티를 인자로 지정할 수 없음
• 프로퍼티를 인자로 사용하려면 const로 선언해야 함
  • const 변경자 → 프로퍼티를 컴파일 시점 상수로 취급

    const val TEST_TIMEOUT = 10L

    class MyTest {
            @Test
            @Timeout(TEST_TIMEOUT)
            fun testMethod() {
                    //...
            }
    }

• const 변경자를 사용하지 않으면 “Only const val can be used in constant expression” 컴파일 오류가 발생함

어노테이션 타깃 (어노테이션이 참조할 수 있는 정확한 선언 지정)

• 한 선언을 컴파일한 결과가 여러 자바 선언과 대응하는 경우가 자주 있음
• 코틀린 선언과 대응하는 여러 자바 선언에 각각 어노테이션을 붙일 경우가 있음
  • 코틀린 프로퍼티 → 자바 필드, 게터 메서드, 세터 메서드 및 그 파라미터 선언과 대응
  • 주 생성자에서프로퍼티를 선언한 경우 접근자 메서드와 파라미터 외에 자바 생성자 파라미터와도 대등
• 어노테이션을 붙일 때 이런 요소 중 어느 요소에 어노테이션을 붙일지 표시해야 함

사용 지점 타깃 선언

• 어노테이션을 적용할 수 있는 요소의 종류 지정 (클래스, 함수, 속성, 표현식 등)
• @와 어노테이션 이름 사이에 타깃을 지정

@target:AnnotationName

@get:JvmName("obtainCertificate")
@set:JvmName("putCertificate")

• 자바에서 선언된 어노테이션 → 기본적으로 프로퍼티의 필드에 어노테이션을 선언함
• 코틀린 어노테이션 → 프로퍼티에 직접 적용할 수 있는 어노테이션을 만들 수 있음

사용 지점 타깃 목록

• property → 프로퍼티 전체 (자바에서 선언된 어노테이션에선 사용 불가)
• field → 프로퍼티에 의해 생성되는 필드
• get → 프로퍼티 게터
• set → 프로퍼티 세터
• reciver → 확장 함수나 프로퍼티의 수신 객체 파라미터
• param → 생성자 파라미터
• setparam → 세터 파라미터
• delegate → 위임 프로퍼티의 위인 인스턴스를 담아둔 필드
• file → 파일 안에 선언된 최상위 함수와 프로퍼티를 담아두는 클래스
  • package 선언보다 더 상위에 사용

@Suppress 어노테이션

• 어노테이션 인자로 클래스, 함수 선언, 타입, 임의의 식을 받음
• 컴파일 경고를 억제

// 안전하지 못한 캐스팅 경고 무시하는 로컬 변수 선언
fun test(list: List<*>) {
        @Suppress("UNCHECKED_CAST")
        val strings = list as List<String>
}

자바 API를 제어하는 어노테이션

• @JvmName → 코틀린 선언이 만들어내는 자바 필드나 메서드의 이름을 변경
• @JvmStatic → 객체 선언이나 동반 객체의 메서드에 적용하면 자바 정적 메서드로 노출됨
• @JvmOverloads → 디폴트 파라미터가 있는 함수에 대해 자도으로 오버로딩한 함수를 생성
• @JvmField → 대상 프로퍼티를 게터나 세터가 없는 public 자바 필드로 노출
• @JvmRecord → data class에 사용하여 자바 레코드 클래스를 선언할 수 있음

어노테이션을 활용해 Json 직렬화 제어

• 직렬화 → 객체를 저장 장치에 저장하거나 네트워크를 통해 전송하기 위해 텍스트나 이진 형식으로 변환
  • Json 형태로 주로 직렬화 함
  • 코틀린 객체를 직렬화하기 위한 kotlinx.serialization 라이브러리가 있음
  • Jackson, GSON 등 자바 객체를 직렬화하기 위한 라이브러리도 호환됨
• 역직렬화 → 텍스트나 이진 형식으로 저장된 데이터에서 원래의 객체로 변환

Person 클래스 직렬화, 역질렬화 예제

data class Person(val name: String, val age: Int)

fun main() {
    val person = Person("Alice", 29)
    // 직렬화
    println(serialize(person))
    // {"age" : 29, "name" : "Alice"}

    // 역직렬화
    val json = """{"name" : "Alice", "age" : 29}"""
    println(deserialize<Person>(json)) // Json 객체의 타입 정보를 명시해줘야 함
    // Person(name=Alice, age=29)
}

어노테이션을 통해 직렬화, 역직렬화 방법 제어

• Jkid 라이브러리 → 기본적으로 모든 프로퍼티를 직렬화하며 프로퍼티 이름을 키로 사용
  • 어노테이션을 통해 이런 동작을 변경할 수 있음

1. @JsonExclude → 직렬화, 역직렬화 시 무시할 프로퍼티 지정
2. @JsonName → 키/값 쌍의 키를 지정

data class Person(
        @JsonName("alias") val firstName: String,
        @JsonExclude val age: Int? = null
)

• @JsonExclude로 직렬화 대상에서 제외한 프로퍼티에는 반드시 기본값을 지정해야 함
  • 역직렬화로 인스턴스를 만들 때 필요

어노테이션 선언

• 어노테이션 클래스 → 선언이나 식과 관련 있는 메타데이터의 구조만 정의

  • 내부에 아무 코드도 들어있을 수 없음

  • @JsonExclude 예시

    annotation class JsonExclude

• 파라미터가 있는 어노테이션 → 클래스의 주 생성자에 파라미터를 선언

  • 일반적인 주 생성자 구문을 사용하면서 val로 선언

  • @JsonName 예시

    annotation class JsonName(val name: String)

자바 어노테이션 선언과 비교

public @interface JsonName {
        String value();
}

• 자바 어노테이션 → value() 라는 메서드가 있음
• 어떤 어노테이션을 적용할 떄 value를 제외한 모든 애트리뷰트에 이름을 명시해야 함

메타어노테이션 (어노테이션을 처리하는 방법 제어)

• 어노테이션 클래스에도 어노테이션을 붙일 수 있음

• 어노테이션 클래스에 적용할 수 있는 어노테이션 → 메타어노테이션

• 메타어노테이션은 컴파일러가 어노테이션을 처리하는 방법을 제어함

• @Target 메타어노테이션

  • 어노테이션을 적용할 수 있는 요소의 유형을 지정

  • @Target을 지정하지 않으면 모든 선언에 적용할 수 있는 어노테이션이 됨

    @Target(AnnotationTarget.PROPERTY)
    annotation class JsonExclude

  • AnnotationTarget → 어노테이션 적용 가능한 타깃이 정의된 이넘

      @Target(AnnotationTarget.CLASS, 
                      AnnotationTarget.FUNCTION,
              AnnotationTarget.TYPE_PARAMETER, 
              AnnotationTarget.VALUE_PARAMETER,
              AnnotationTarget.EXPRESSION)

  • 메타어노테이션을 직접 만들 수 있음

      @Target(AnnotationTarget.ANNOTATION_CLASS)
      annotation class BindingAnnotation
    
      @BindingAnnotation
      annotation class MyBinding

  • 대상을 PROPERTY로 지정한 어노테이션 → 자바에서 사용할 수 없음

    • AnotationTarget.FIELD를 두 번째 타깃으로 추가해야 함
    • 어노테이션을 코틀린 프로퍼티와 자바 필드에 적용할 수 있어짐

@Retention 어노테이션

• 정의한 어노테이션의 유지 수준 지정
  • 소스 수준
  • .class 파일 수준
  • 실행 시점에 리플렉션을 통한 접근 허용
• 자바 → .class 수준이 디폴트
  • 하지만 대부분의 어노테이션을 런타임에도 사용할 수 있어야 함
• 코틀린 → 디폴트로 RUNTIME으로 지정

어노테이션 파라미터로 클래스 사용

• 클래스 참조를 파라미터로 하는 어노테이션 클래스를 선언하여 클래스를 어노테이션 파라미터로 사용할 수 있음

interface Company {
        val name: String
}

data class CompanyImpl(override val name: String) : Company

data class Person(
        val name: String,
        @DeserializeInterface(CompanyImpl::class) val company: Company
)

• 역직렬화 과정에서 company 프로퍼티를 표현하는 Json을 읽으면 Json을 역직렬화 하면서 CompanyImpl의 인스턴스를 만들어 Person 인스턴스의 company 프로퍼티를 설정함

@DesirializeInterface 구현

annotation class DesirializeInterface(val targetClass: KClasee<out Any>)

• KClass 타입 → 코틀린 클래스에 대한 참조를 저장
  • KClass의 타입 파라미터 → 인스턴스가 가리키는 코틀린 타입을 지정
  • CompanyImpl::class의 타입 → KClass
    • KClass의 하위 타입

어노테이션 파라미터로 제네릭 파라미터 받기

• jkid → 기본 타입이 아닌 프로퍼티를 내포된 객체로 직렬화 함

• 이런 기본 동작을 변경하려면 직렬화하는 로직을 직접 제공하면 됨

• @CustomSerializer

  • 커스텀 직렬화 클래스에 대한 참조를 인자로 받음

    • ValueSerializer 인터페이스를 구현한 클래스

    • 직렬화, 역직렬화 제공

      interface ValueSerializer<T> {
            fun toJsonValue(value: T) : Any?
            fun fromJsonValue(jsonValue: Any?): T
      }

  • Person 클래스 적용 예제

      data class Person(
              val name: String,
              @CustomSerializer(DateSerializer::class) val birthDate: Date
      )

  • @CustomSerializer 구현

      annotation class CustomSerializer(
              val serializerClass: KClass<out ValueSerializer<*>>
      )

    • ValueSerializer → 제네릭 클래스 (타입 파라미터가 있음)

      • 어떤 파라미터가 쓰일지 알 수 없음 → 스타프로젝션 사용

        

• 변성 → 기저 타입이 같고 타입 인자가 다른 타입의 관계를 설명하는 개념
• 변성을 잘 활용하면 타입 안전성을 보장하는 API를 만들 수 있음

변성은 인자를 함수에 넘겨도 안전한지 판단하게 해줌

• 어떤 함수가 리스트의 원소를 추가하거나 변경한다면 타입 불일치가 생길 수 있어 Any 타입에 String 타입을 넘길 수 없음
  • 원소를 변경하거나 추가하지 않는다면 안전함
• 코틀린에선 리스트의 변경 가능성에 따라 적절한 인터페이스를 선택하면 안전성을 제어할 수 있음

클래스, 타입, 하위 타입

하위 타입

• A 타입이 필요한 곳에 B 타입을 넣어도 문제가 없다면 B는 A의 하위 타입임
  • Int는 Number의 하위 타입임
  • String은 Number의 하위 타입이 아님

상위 타입

• 하위 타입의 반대

하위 타입인지가 왜 중요한가?

• 컴파일러 → 변수 대입이나 함수 인자 전달 시 하위 타입 검사를 매번 수행

fun test(i: Int) {
    val n: Number = i

    fun f(s: String) { /*...*/ }
    f(i)
}

• Int는 Number의 하위 타입이어서 컴파일됨
• Int는 String의 하위 타입이 아님 → 함수 f의 호출은 컴파일되지 않음

어떤 인터페이스를 구현한하는 클래스의 타입은 그 인처페이스의 하위 타입임

• Int 클래스 → Number 클래스의 하위 클래스
  • Int 타입 → Number 타입의 하위 타입
• String 클래스 → CharSequence 클래스의 하위 클래스
  • String 타입 → CharSequence 타입의 하위 타입

널이 될 수 있는 타입의 하위 타입과 하위 클래스는 같지 않음

• 널이 될 수 있는 타입 → 널이 될 수 없는 타입의 하위 타입
• 하지만 두 타입은 같은 클래스에 속함
  • 널이 될 수 없는 값을 널이 될 수 있는 값에 저장할 수 있음
  • 그 반대는 안됨

val s: String = "abc"
val t: String? = s

무공변

• 서로 다른 두 타입 A, B에 대해 A가 B의 상위 타입도 하위 타입도 아닌 경우를 무공변이라고 함
• 자바에서는 모든 클래스가 무공변임

공변성

공변적인 클래스(인터페이스)

• 제네릭 클래스에 대해 A가 B의 하위 타입일 때 Class<A>가 Class<B>의 하위 타입인 경우

• “하위 타입 관계를 유지한다.”라고 함

• 제네릭 클래스가 타입 파라미터에 대해 공변적임을 표시 → out 키워드

    interface Producer<out T>{
            fun produce(): T
    }

• 클래스의 타입 파라미터를 공변적으로 만들면 파라미터 타입과 타입 인자가 정확히 일치하지 않아도 그 클래스의 인스턴스를 함수 인자나 반환값으로 사용할 수 있음

무공변 컬렉션 역할을 하는 클래스 예시

open class Animal {
    fun feed() { /*...*/ }
}

class Herd<T : Animal> { // 이 타입 파라미터를 공변으로 지정하지 않음
    val size: Int get() = /*...*/

    operator fun get(i: Int): T { /*...*/ }
}

fun feddAll(animals: Herb<Animal>) {
    for(i in 0..<animals.size){
        animals[i].feed()
    }
}

무공변 클래스 사용

• feedAll 함수에 cats를 넘기면 타입 불일치 오류가 발생함
  • Herb 클래스의 T 타입 파라미터에 대해 아무 변성도 지정하지 않았기 때문에 Cats는 Herb의 하위 클래스가 아님
  • 명시적 타입 캐스팅을 통해 해결은 가능하나 코드가 복잡해짐
• Herb 클래스는 List와 비슷한 API를 제공하며 데이터를 추가하거나 변경할 수 없음
  • Herb를 공변적인 클래스로 만들 수 있음

컬렉션 역할을 하는 공변적인 클래스

class Herd<out T : Animal> { // T는 공변적임
    /*...*/
}

fun takeCareOfCats(cats: Herb<Cat>) {
    for(i in 0 ..< cats.size) {
        cats[i].cleanLitter()
    }
    feddAll(cats) // 캐스팅을 할 필요 없음
}

모든 클래스를 공변적으로 만들면 안전한가?

• 공변적으로 만들면 안전하지 못한 클래스도 있음
• 타입 파라미터를 공변적으로 지정 → 클래스 내부에서 그 파라미터를 사용하는 방법을 제한
• 타입 안전성을 보장하려면 타입 파라미터는 항상 out 위치에 있어야 함
  • 클래스가 T 타입의 값을 생성할 수는 있으나 소비할 수는 없음

타입 파라미터를 사용할 수 있는 지점

• 인(in)과 아웃(out)으로 나뉨
• T라는 타입 파라미터를 사용하는 함수가 맴버로 있는 클래스
  • T가 함수의 반환 타입 → 아웃 위치 (T 타입의 값을 생성)
  • T가 함수의 파라미터 타입 → 인 위치 (T 타입의 값을 소비)

• 제네릭 타입 인자 앞에 out 키워드를 사용하면 클래스 안에서 T를 함수의 파라미터 타입으로 사용하지 못하도록 제한
  • T의 사용법을 제한하며 T로 인해 생기는 하위 타입 관계의 타입 안전성을 보장

out 키워드의 의미

• 하위 타입의 관계가 유지됨
• T를 아웃 위치에만 사용할 수 있음

List의 공변성

interface List<out T> : Collection<T> {
        operator fun get(index: Int): T
        /* ... */
}

• 코틀린 List는 읽기 전용 (원소 추가, 변경 불가) → List는 T에 대해서 공변적임

타입 파라미터를 다른 타입의 타입 인자로 사용

interface List<out T> : Collection<T> {
        fun subList(fromIndex: Int, toIndex: Int): List<T>
}

• List를 반환하는 subList 메서드

MutableList를 타입 파라미터 T에 대해 공변적일 수 없음

• T를 인자로 받아 그 타입의 값을 반환하는 메서드가 있기 때문

interface MutableList<T> : List<T>, MutableCollection<T> {
        override fun add(element: T): Boolean
}

• 공변적으로 선언할 경우 “Type parameter T is declared as ‘out’ but occurs in ‘in’ position”이라는 오류를 보고함

생서자 파라미터의 위치

• 생성자 파라미터는 인, 아웃 어느 쪽도 아님
• 타입 파라미터가 out이라 하더라고 그 타입을 생성자 파라미터 선언에 사용할 수 있음

class Herd<T: Animal>(vararg animals: T) { /* ... */ }

• 변성은 코드에서 위험할 여지가 있는 메서드를 호출할 수 없게 만듦
  • 클래스 인스턴스를 잘못 사용하는 일이 없게 방지
• 생성자는 인스턴스를 생성한 뒤에 호출할 수 있는 메서드가 아니므로 위험의 여지가 없음
• val이나 var 키워드를 생성자 파라미터에 사용하면 getter/setter를 정의하는 것과 같음
  • 읽기 전용 프로퍼티 → 아웃 위치
  • 변경 가능 프로퍼티 → 인/아웃 위치

class Herd<T: Animal>(val leadAnimal: T, vararg animals: T) { /*...*/ }

• leadAnimal이 변경 가능 프로퍼티 이므로 T를 out으로 표시할 수 없음

위치 규칙 → 외부에서 볼 수 있는 클래스 API에만 적용할 수 있음

• 비공개 메서드의 파라미터 → 인도 아니고 아웃도 아님
• 변성 규칙 → 클래스 내부 구현에는 적용되지 않음

class Herd<out T: Animal>(private val leadAnimal: T, vararg animals: T) { /*...*/ }

• leadAnimal 프로퍼티가 비공개이기 때문에 T를 공변적으로 선언해도 안전함

반공변성

• 반공변성 → 공변성의 반전
  • 반공변 클래스의 하위 타입 관계 → 타입 파라미터 상하위 관계와 반대

interface Comparator<in T> {
        fun compare(e1: T, e2: T): Int { /*...*/ }
}

• 이 인터페이스의 메서드 → T 타입의 값을 소비하기만 함
  • T 앞에 in이 붙어야 함
• 어떤 타입에 대해 Comparator를 구현하면 그 타입의 하위 타입에 속하는 모든 값을 비교할 수 있음

sealed class Fruit {
        abstract val weight: Int
}

data class Apple(override val weight: Int, val color: String): Fruit()

data class Orange(override val weight: Int, val juicy: Boolean): Fruit()

• 이 코드에 Comparator를 구현하면 모든 하위 타입을 비교할 수 있음

fun main() {
    val weightComparator = Comparator<Fruit> { a, b -> a.weight - b.weight}

    val fruits: List<Fruit> = listOf(Orange(180, true), 
                              Apple(100, "green")
                              )

    val apples: List<Apple> = listOf(Apple(50, "red"),        
                                Apple(120, "green"), 
                              Apple(155, "yellow")
                              )

    println(fruits.sortedWith(weightComparator))
    // [Apple(weight=100, color=green), Orange(weight=180, juicy=true)]
    println(apples.sortedWith(weightComparator))
    // [Apple(weight=50, color=red), Apple(weight=120, color=green), Apple(weight=155, color=yellow)]
}

• sortedWith 함수 → Comparator<String>을 요구
  • String보다 더 일반적인 타입을 비교할 수 있는 Comparator를 넘겨도 안전함
• 어떤 타입의 객체를 Comparator로 비교할 때 그 타입의 조상 타입을 비교할 수 있는 Comparator를 사용할 수 있음
  • Comparator<Any>가 Comparator<String>의 하위 타입이라는 뜻
  • 보통 Any는 String의 상위 타입임
  • 서로 다른 타입 인자에 대해 Comparator의 하위 타입 관계는 타입 인자의 하위 타입 관계와 반대

반공변성의 정의

• 타입 B가 타입 A의 하위 타입일 때 Class<A>가 Class<B>의 하위 타입인 관계가 성립하면 제네릭 클래스는 타입 인자 T에 대해 반공변임

in 키워드

• in 키워드가 붙은 타입이 클래스 내부의 메서드 안으로 전달돼 소비된다는 뜻
• 공변성과 마찬가지로 타입 파라미터의 사용을 제한하여 특정 하위 타입 관계에 도달할 수 있음
• in 키워드를 붙이면 그 타입 파라미터를 in 위치에서만 사용할 수 있음

공변성, 반공변성, 무공변성 요약

1. 공변성
   • 타입 인자의 하위 타입 관계가 제네릭 타입에서도 유지
   • T를 아웃 위치에서만 사용할 수 있음
2. 반공변성
   • 타입 인자의 하위 타입 관계가 제네릭 타입에서 반전됨
   • T를 인 위치에서만 사용할 수 있음
3. 무공변성
   • 하위 타입 관계가 성립하지 않음
   • T를 아무 위치에서나 사용할 수 있음

사용 지점 변성

• 클래스를 선언하면서 변성을 지정
  • 클래스를 사용하는 모든 장소에 변성 지정자가 영향을 끼침
• 자바에서는 타입 파라미터를 사용할 때 그 타입 파라미터가 상위/하위 타입 중 어떤 타입으로 대치할 수 있는지 명시해야 함

코틀린의 사용 지점 변성

• 특정 타입 파라미터가 나타나는 지점에서 변성을 정할 수 있음

• MutableList같은 상당수의 인터페이스 > 타입 파라미터로 지정된 타입을 소비하는 동시에 생산할 수 있음 (공변적이지도 반공변적이지도 않음)

  • 이런 인터페이스 안에서 한 변수가 함수 안에서 생성자와 소비자 중 단 한 가지 역할을 담당하는 경우가 있음

    fun <T> copyData(source: MutableList<T>,
                   destination: MutableList<T>) {
      for (item in source) {
          destination.add(item)
      }
    }

  • 두 컬렉션 모두 무공변 타입이지만 하나는 읽기만 하고 하나는 쓰기만 함

  • 이런 경우 두 컬렉션의 타입이 정확하게 일치하지 않아도 됨

  • 문자열 컬렉션에서 객체의 컬렉션으로 복사해도 문제 없음

  • 여러 리스트 타입에 대응하는 두 번째 제네릭 타입 파라미터를 도입할 수 있음

    fun <T: R, R> copyData(source: MutableList<T>,
                   destination: MutableList<R>) {
                   // 원본의 원소 타입 -> 대상 원소 타입의 하위 타입
      for (item in source) {
          destination.add(item)
      }
    }
    
    fun main() {
      val ints = mutableListOf(1, 2, 3)
      val anyItems = mutableListOf<Any>()
      copyData(ints, anyItems) // Int가 Any의 하위 타입이기 때문에 호출 가능
      println(anyItems)
      // [1, 2, 3]
    }

아웃-프로젝션 타입 파라미터를 사용

fun <T> copyData(source: MutableList<out T>,
                 destination: MutableList<T>) {
    for (item in source) {
        destination.add(item)
    }
}

• 타입 파라미터에 변성 변경자를 사용하여 간단하게 구현
• 변성 변경자를 사용하지 않은 경우 이런 경고가 출력됨

타입 프로젝션

• 타입 선언에 사용한 파라미터를 사용하는 위치라면 어디에나 변성 변경자를 붙일 수 있음
  • 파라미터 타입, 로컬 변수 타입, 함수 반환 타입 등등…
• 타입 변성에 사용한 파라미터를 사용하는 곳에 변성 변경자를 붙이면 타입 프로젝션이 일어남
  • 일반적인 MutableList가 아닌 MutableList를 프로젝션한(제약을 가한) 타입을 만듬

사용 지점 변성을 사용하면 타입 인자로 사용할 수 있는 타입의 범위가 넓어짐

스타 프로젝션

• 제네릭 타입 인자 정보가 없음을 표현
  • 원소 타입이 알려져 있지 않은 List → List<*>로 표현할 수 있음

MutableList<*> ≠ MutableList<Any?>

• Any? → 모든 타입의 원소를 담을 수 있음
• • → 정해진 구체적인 타입의 원소를 담을 수 있지만 그 원소의 타입을 정확히 모름
• 원소 타입을 모른다고 아무 타입이나 다 넣을 수 있는 건 아님

스타 프로젝션 → 아웃 프로젝션 타입으로 인식됨

• 어떤 리스트의 원소 타입을 모르더라도 안전하게 Any? 타입으로 꺼내올 수 있음
• 하지만 타입을 모르는 리스트에 아무 원소나 마음대로 넣을 수는 없음

스타 프로젝션을 사용하는 경우

1. 타입 파라미터를 시그니처에 언급하지 않는 경우
2. 데이터를 읽기는 하지만 구체적인 타입은 신경 쓰지 않는 경우

fun printFirst(list: List<*>) { // 모든 리스트를 인자로 받을 수 있음
    if (list.isNotEmpty()) { // isNoEmpty -> 제네릭 파라미터를 사용하지 않음
        println(list.first()) 
        // first -> Any? 타입을 반환함
    }
}

fun main() {
    printFirst(listOf("Sveta", "Seb", "Dima", "Roman"))
    // Sveta
}

• 제네릭 파라미터가 어떤 타입인지 굳이 알 필요 없을 때만 스타 프로젝션을 사용
  • 스타 프로젝션을 사용할 때는 값을 만들어내는 메서드만 호출 가능
  • 반환한 값의 타입은 신경 쓰지 않음

타입 별명

• 기존 타입에 다른 이름을 부여

typealias name = typeName

• 긴 제네릭 타입을 짧게 만들수 있음

typealias Combiner = (String, String, String, String) -> String
// 4개의 문자열을 받고 새로 조함한 문자열을 반환하는 함수형 타입 파라미터

val authorsCombiner: Combiner = { a, b, c, d -> "$a et al." }
// 변수 선언에 타입 별명 사용 가능

fun combineAuthors(combiner: Combiner) { // 함수 파라미터에 타입 별명 사용 가능
    println(combiner("Sveta", "Seb", "Dima", "Roman"))
}

fun main() {
    combineAuthors(authorsCombiner) // 타입 별명은 원래 타입으로 해소됨
    // Sveta et al.
    combineAuthors{ a, b, c, d -> "$d, $c & Co" } // 람다를 전달해도 됨
    // Roman, Dima & Co
}

• 타입 별명을 사용하면 코드의 가독성을 올릴 수 있지만 다는 개발자가 볼 때 타입 별명의 정의를 찾아봐야 한다는 단점도 있음
• 타입 별명이 타입 안전성을 추가해주진 않음
  • 컴파일시 원래 타입으로 치환되기 때문

• JVM의 제네릭스 → 타입 소거를 사용해 구현
  • 실행 시점에 제네릭 클래스의 인스턴스에 타입 인자 정보가 들어있지 않다는 의미
• 타입 소거는 어떤 영향을 미치는가?
• 함수를 inline으로 선언해 제약을 우회하는 방법
• 실체화된 타입 파라미터

실행 시점에 제네릭 클래스의 타입 정보를 찾을 때 한계:

타입 검사와 캐스팅

• 코틀린의 타입 인자 정보 → 런타임에 지워짐(자바와 동일)
  • 제네릭 클래스 인스턴스를 생성할 때 쓰인 타입 인자에 대한 정보를 유지하지 않음
  • List 객체를 만들고나면 그 객체를 List로만 볼 수 있음
  • 이 리스트가 어떤 타입의 원소를 저장하는지 실행 시점에는 알 수 없음

타입 소거로 생기는 한계

1. 타입 인자를 저장하지 않음 → 실행 시점에 타입 인자를 검사할 수 없음

   • ex) 어떤 리스트가 문자열로 이뤄진 리스트인지 실행 시점 에는 검사할 수 없음

   • 파라미터의 타입 인자에 따라 다른 동작을 수행할 수 없음

     fun readNumbersOrWords(): List<Any> {
           val input = readln()
           val words: List<String> = input.split(",")
           val numbers: List<Int> = words.mapNotNull{ it.toIntOrNull() }
           return numbers.ifEmpty { words }
     }
     
     fun printList(l: List<Any>) {
           when(l) {
               is List<String> -> println("Strings: $l")
               is List<Int> -> println("Integers: $l")
           }
           // when 식에서 Cannot check for an instance of erased type 오류 발생
     }
     
     fun main() {
           val list = readNumbersOrWords()
           printList(list)
     }

   • 실행 시점에서 어떤 값이 List임은 확실히 알수 있지만 그 리스트가 어떤 타입을 저장하는지 알 수 없음

   • 타입 인자를 저장하지 않기 때문에 애플리케이션의 전체 메모리 사용량이 줄어든다는 장점은 있음

   • 스타 프로젝션( * )을 사용하면 최소한 대상이 List 임은 확인할 수 있음 (추후 자세히 다룸)

     • 여전히 원소 타입은 알 수 없음

2. as나 as? 같은 캐스팅

   • 캐스팅에도 제네릭 타입을 사용할 수 있음

   • 기저 클래스는 같지만 타입 인자가 다른 타입으로 캐스팅을 해도 성공함

     • 캐스팅은 항상 성공

   • 이런 캐스팅은 컴파일러가 unchecked cast라는 경고를 해줌

     • 단순 경고일 뿐 컴파일은 진행됨

     fun printSum(c: Collection<*>) {
           val intList = c as? List<Int>
                   ?: throw IllegalArgumentException("List is expected")
           println(intList.sum())
     }
     
     fun main() {
           printSum(listOf(1, 2, 3))
           // 6
           printSum(setOf(1, 2, 3))
           // IllegalArgumentException: List is expected
           printSum(listOf("a", "b", "c"))
           // ClassCastException: String connot cast to Number
     }

   • 잘못된 타입의 원소가 들어있는 경우 ClassCastException이 발생

     • as ? 캐스트는 성공하지만 sum 함수에서 예외가 발생
     • sum은 Number 타입의 값에 대해서 작동
     • String을 Number로 사용하려 했기 때문에 ClassCastException이 발생

실행 시점에 타입 정보가 주어진 경우

• 이 경우 is 검사를 수행할 수 있음

fun printSum(c: Collection<Int>) { // 컴파일 시점에 원소 타입이 알려짐
    when(c) {
        is List<Int> -> println("List sum: ${c.sum()}")
        is Set<Int> -> println("Set sum: ${c.sum()}")
    }
}

fun main() {
    printSum(listOf(1, 2, 3))
    // List sum: 6
    printSum(setOf(3, 4, 5))
    // Set sum: 12
}

실체화된 타입 파라미터

• 인라인 함수의 타입 파라미터 → 실체화됨

  • 실행 시점에 인라인 함수의 실제 타입 인자를 알 수 있음

• reified 키워드를 통해 타입 파라미터를 실체화 시킬 수 있음

  • 일반 함수에 reified 키워드를 사용하면 경고 메시지가 나옴

    

inline fun <reified T> isA(value: Any) = value is T

fun main() {
    println(isA<String>("abc"))
    // true
    println(isA<String>(123))
    // false
}

filterIsInstance 예제

• 표준 라이브러리 함수로, 인자로 받은 컬렉션에서 지정한 타입의 원소만 모아서 리스트로 반환

fun main() {
    val items = listOf("one", 2, "three")
    println(items.filterIsInstance<String>())
    // [one, three]
}

• filterIsInstance 함수의 내부 (간소화 예시)

inline fun <reified T> Iterable<*>.filterIsInstance(): List<T> {
    val destination = mutableListOf<T>()
    for (element in this) {
        if(element is T) { // 각 원소가 인자로 지정한 클래스의 인스턴스인지 검사
            destination.add(element)
        }
    }
    return destination
}

inline 함수에서만 reified 키워드를 쓸 수 있는 이유

• inline 함수 → 함수를 호출한 모든 위치에 바이트 코드를 삽입
  • 컴파일러는 타입 인자로 쓰인 구체적인 클래스를 참조하는 바이트코드를 생성해 삽입할 수 있음
  • 만들어진 바이트 코드는 구체적인 타입을 사용하므로 타입 소거의 영향을 받지 않음

자바 코드에서 reified 키워드를 사용한 inline 함수를 호출할 수 없음

• 자바에서는 코틀린 inline 함수를 일반 함수처럼 호출 → 실제로 인라이닝 되지 않음
• 바이트코드를 직접 삽입하지 않기 때문에 구체적인 클래스를 참조하지 못함

클래스 참조를 실체화된 타입 파라미터로 대신해 java.lang.Class 파라미터 피하기

• java.lang.Class 타입 인자를 파라미터로 받는 API에 대한 코틀린 어댑터 구축 → 실체화된 파라미터를 자주 사용
  • JDK의 ServiceLoader가 있음
    • 어떤 추상 클래스나 인스턴스를 구현한 인스턴스를 반환
  • 실체화된 타입 파라미터를 통해 이런 API를 쉽게 호출 할 수 있음

ServiceLoader 사용 방법

val serviceImpl = ServiceLoader.load(Service::class.java)

• ::class.java 구문 → 코틀린 클래스에 대응하는 java.lang.Class 참조를 얻는 방법
• Service::class.java → Service.class라는 자바 코드와 완전히 같음

ServiceLoader에서 타입 파라미터 사용

val serviceImpl = loadService<Service>()

• 읽어 들일 서비스 클래스를 loadService 함수의 타입 인자로 지정

• loadService 함수

    inline fun <reified T> loadService(): ServiceLoader<T?>? {
        return ServiceLoader.load(T::class.java)
    }

안드로이드의 startActivity 함수 간단하게 만들기

inline fun <reified T : Activity> Context.startActivity() {
    val intent = Intent(this, T::class.java)
    startActivity(intent)
}

startActivity<DetailActivity>() // 액티비티를 표시하는 메서드를 호출

실체화된 타입 파라미터가 있는 접근자 정의

• 제네릭 타입에 대해 프로퍼티 접근자를 정의할 수 있음
  • 프로퍼티를 inline으로 표시
  • 타입 파라미터를 reified로 표시

inline val <reified T> T.cannonical: String
    get() = T::class.java.canonicalName

fun main() {
    println(listOf(1, 2, 3).cannonical)
    // java.util.List
    println(1.cannonical)
    // java.lang.Integer
}

실체화된 파라미터의 제약

• 실체화의 개념으로 인해 생기는 제약과 현제 코틀린이 실체화를 구현하는 방식에 의해 생기는 제약이 있음

1. 실체화된 타입 파라미터를 사용할 수 있는 경우
   • 타입 검사와 캐스팅 (is, !is, as, as?)
   • 코틀린 리플렉션 API (::class)
   • 코틀린 타입에 대응하는 java.lang.Class 얻기 (::class.java)
   • 다른 함수를 호출할 때 타입 인자로 사용
2. 실체화된 타입 파라미터의 제약
   • 타입 파라미터 클래스의 인스턴스 생성
   • 타입 파라미터의 동반 객체 메서드 호출
   • 실체화된 타입 파라미터를 요구하는 함수에 실체화되지 않은 타입 인자를 넘기기
   • 클래스, 프로퍼티, 인라인 함수가 아닌 함수의 타입 파라미터를 reified로 지정

클래스, 프로퍼티, 인라인 함수가 아닌 함수의 타입 파라미터를 reified로 지정

• 실체화된 타입 파라미터를 사용하는 함수 → 자신에게 전달되는 모든 람다를 인라이닝 함
  • 람다 내부에서 타입 파라미터를 사용하는 방식에 따라 람다를 인라이닝 할 수 없는 경우가 생기기도 함
  • 성능 문제로 람다를 인라이닝 하고 싶지 않을 수도 있음
  • noinline 변경자를 통해 인라이닝을 금지할 수 있음

val authors = listOf("Dmitry", "Svetlana")

• 컴파일러는 자동으로 author의 타입이 List임을 추론함

• 빈 리스트를 정의할 때는 타입 인자를 명시해줘야 함

val readers: MutableList<String> = mutableListOf() // 변수 타입 지정
val readers = mutableListOf<String>() // 함수 타입 지정

제네릭 타입과 함께 동작하는 함수와 프로퍼티

제네릭 함수 → 여러 타입에 대응 가능

• 타입 파라미터를 받음
• 호출 시 구체적인 타입을 인자로 넘겨야 함

컬렉션 함수 → 대부분 제네릭 함수

// slice함수 예시
fun <T> List<T>.slice(indices: IntRange) : List<T>

• 의 의미 (순서대로)
  1. 타입 파라미터 선언
  2. 수신객체의 타입 파라미터
  3. 반환 객체의 타입 파라미터

컬렉션 호출 시 타입 인자를 명시적으로 지정할 수 있으나 대부분 컴파일러가 추론할 수 있음

fun main() {
        val letters = ('a'..'z').toList()
        println(letters.slice<Char>(0..2))
        // [a, b, c]
        println(letters.slice(10..13))
        // [k, l, m, n]
}

filter 함수

// 함수 시그니처
fun <T> List<T>.filter(predicate: (T) -> Boolean): List<T>

fun main() {
        val authors = listOf("Sveta", "Seb", "Roman", "Dima")
        val readers = mutableListOf("Seb", "Hadi")
        println(readers.filter { it !in authors })
        // [Hadi]
}

• 람다 파라미터의 it 변수의 타입은 컴파일러에 의해 추론됨
  • filter의 수신 객체인 readers의 타입인 List로 부터 it의 타입이 String임을 추론

타입 파라미터를 사용할 수 있는 위치

• 클래스나 인터페이스 안에 정의된 메서드
• 최상위 함수
• 확장 함수
  • 수신 객체, 파라미터 타입

제네릭 확장 프로퍼티

• 제네릭 함수를 구현하는 구문으로 제네릭 확장 프로퍼티를 선언할 수 있음

// 모든 List 타입에 대한 확장 파라미터
val <T> List<T>.penultimate: T
        get() = this[size - 2]

fun main() {
        println(listOf(1, 2, 3, 4).penultimate) // 파라미터 타입이 Int로 추론됨
        //3
}

제네릭 클래스 선언

• 자바와 마찬가지로 홑화살괄호를 클래스나 인터페이스 이름 뒤에 작성
  • 타입 파라미터를 다른 일반 타입처럼 사용할 수 있음

interface List<T> {
    operator fun get(index: Int): T
    /* ... */
} 

제네릭 클래스의 확장 클래스

• 기반 타입의 제네릭 파라미터에 대해 타입 인자를 지정
  • 구체적인 타입을 넘기거나
  • 타입 파라미터로 받은 타입을 넘길 수 있음

// 구체적인 타입 지정
class StringList : List<T> {
        override fun get(index: Int): String = this[index]
        /* ... */
}

// 제네릭 타입 파라미터를 List의 타입 인자로 넘김
class ArrayList<T>: List<T> {
        override fun get(index: Int): T = this[index]
        /* ... */
}

1. StringList
   • String 타입의 원소만 저장 → String을 기반 타입으로 사용
   • 하위 클래스에서 함수를 오버라이드 하거나 사용하려면 타입 인자에 String을 명시해야 함
     • ex) get 함수의 반환 타입으로 String을 명시함
2. ArrayList
   • 자신만의 타입 파라미터를 정의하면서 기반 클래스의 타입 인자로 사용
     • ArrayList의 T와 List의 T는 같지 않음

• 클래스가 자신을 타입 인자로 참조할 수 있음

// Comparable 인터페이스 구현 예제
interface Comparable<T> {
        fun compareTo(other: T): Int
}

class String : Comparable<String> {
        override fun compareTo(other: String): Int = TODO()
}

타입 파라미터 제약

• 클래스나 함수에 사용할 수 있는 타입을 제한하는 기능
  • ex) 특정 함수에 대해 타입 파라미터로 숫자 타입 만을 허용하도록 정의할 수 있음

어떤 타입을 제네릭 타입의 상계(upper bound)로 정의

• 제네릭 타입을 인스턴스화할 때 사용하는 타입 인자는 반드시 그 상계 타입이거나 그 상계 타입의 하위 타입이어야 함

// 상계 지정 방법
fun <T : Number> List<T>.sum(): T

• 타입 파라미터 이름 뒤에 콜론( : )을 표시하고 그 뒤에 상계 타입 명시

fun main() {
        println(ListOf(1, 2, 3, 4).sum())
        // 10
}

• Number → 코틀린 표 준 라이브러리의 숫자 타입의 최상위 클래스
• 상계를 정하고 나면 T 타입의 값을 상계 타입으로 취급할 수 있음

fun <T:Number> oneHalf(value: T): Double {
        return value.toDouble() / 2.0
}

fun main() {
        println(oneHalf(3))
        // 1.5
}

두 값 비교 예제

fun <T: Comparable<T>> max(first: T, second: T): T {
        return if (first > second) first else second
}

fun main() {
        println(max("kotlin", "java"))
        //kotlin
}

• 비교할 수 없는 값을 입력하면 커파일 오류 발생

println(max("kotlin", 42))
// ERROR: Type parameter bound for T is not satisfied:
//         inferred type Any is not a subtype of Comparable<Any>

타입 파라미터에 둘 이상의 제약 선언

fun <T> ensureTrailingPeriod(seq: T) where T : CharSequence, T : Appendable { // 타입 파라미터 제약 목록
        if(!seq.endWith('.')) { // CharSequence 인터페이스의 확장 함수 호출
                seq.append(.) // Appendable 인터페이스에 정의된 메서드 호출
        }
}

fun main() {
        val helloWorld = StringBuilder("Hello World")
        ensureTrailingPeriod(helloWorld)
        println(helloWorld)
        //Hello World.
}

• StringBuilder → CharSequence와 Appendable을 모두 사용하는 클래스

널이 될 수 없는 타입 제한하기

• 상계를 정하지 않은 타입 파라미터 → Any? 타입으로 치환
• 널 가능성을 제한하려면 명시적으로 타입 상계를 지정해줘야 함

class Processor<T: Any> {
        fun process(value: T) {
                value.hashCode()
        }
}

• <T: Any> → T 타입이 항상 널이 될 수 없는 타입이 되도록 보장
• Any 타입 외에도 다른 널이 될 수 없는 타입을 사용해 상계를 정할 수 있음

자바와의 상호 운용

• 자바에서 어노테이션 @NotNull을 사용해 널값을 차단한 경우
  • <t : T & Any>와 같은 구문으로 절대로 널이 될 수 없는 값으로 표시할 수 있음

• 람다 안에서 return → 그 람다를 호출한 함수의 실행이 종료되고 반환됨
• return이 선언된 람다를 호출한 함수를 반환하게 만드는 return 문을 “비로컬 return”이라고 함

data class Person(val name: String, val age: Int)

val people = listOf(Person("Alice", 29), Person("Bob", 31))

fun lookForAlice(people: List<Person>) {
        people.forEach {
                if(it.name == "Alice"){
                        println("Found!")
                        return // 비로컬 return
                }
        }
        println("Alice is not found")
}

• return이 바깥 블록을 반환시키는 경우 → 인라인 함수에서만 가능

람다로부터 반환: 레이블을 사용한 return

• 람다식에도 로컬 return문을 쓸 수 있음

• 람다의 로컬 return → break와 비슷한 역할

  • 람다의 실행을 멈추고 람다를 호출한 함수의 실행을 이어감

• 로컬 return과 비로컬 return을 구분하는 방법 → 레이블 사용

    fun lookForAlice(people: List<Person>) {
            people.forEach label@{ // 람다 식 앞에 레이블 작성
                    if(it.name != "Alice") return@label // 리턴 식 뒤에 레이블 작성
                    println("Found Alice!") // return이 실행되지 않았을 경우 출력
            }
    }

  • 람다 식 앞에 레이블을 붙이고 return 키워드 뒤에 레이블을 추가

    • 람다 레이블 → 레이블 이름 뒤에 @
    • 리턴 레이블 → 리턴 키워드 뒤에 @와 레이블 이름

  • 람다를 인자로 밭은 함수의 이름을 사용해도 됨

      people.forEach {
              if(it.name != "Alice") return@forEach
              println("Found Alice!")
      } 

• 람다식에는 레이블 이름이 1개만 붙을 수 있음

this 식의 레이블

• 수신 객체 지정 람다 → this로 수신 객체 지정 (13장 내용)
• 수신 객체 지정 람다 앞에 레이블을 붙인 경우 this 뒤에 그 레이블을 붙여 수신객체를 지정할 수 있음

fun main() {
        println(StringBuilder().apply sb@{ // this@sb를 통해 이 람다의 수신 객체에 접근 가능
                listOf(1, 2, 3).apply {
                        this@sb.append(this.toString())
                }
        })
        // [1, 2, 3]
}

익명 함수 : 기본적으로 로컬 return

• 익명 함수 → 람다를 정의하는 또 다른 방법
  • 함수에 전달할 수 있는 코드 블록 작성 가능
• 익명 함수에서 return을 쓰면 기본적으로 로컬 return임
  • 레이블을 지정할 필요 없음

fun findForAlice(people: List<Person>) {
        people.forEach(fun (person) {
                if(person.name == "Alice") return
                println("${person.name} is not Alice")
        })
}

• 함수 이름 생략
• 파라미터 타입을 컴파일러가 추론해줌

people.filter (fun (person): Boolean {
        return person.age < 30
})

• 익명 함수에도 반환 타입을 지정할 수 있음

people.filter(fun (person) = person.age < 30)

• 식을 본문으로 사용할 수 있음
• 식을 본문으로 사용할 경우 반환 타입은 생략할 수 있음

return은 가장 가까운 fun 키워드를 반환시킴

• 람다 → 익명 클래스로 컴파일
  • 람다식마다 새로운 클래스가 생김
  • 람다가 변수를 캡처한 경우 호출할 때마다 새로운 객체가 생김
  • 같은 기능을 하는 코드를 직접 실행하는 것보다 효율성이 떨어짐

인라인 함수?

• inline 변경자를 통해 선언
• inline 변경자가 선언된 함수를 호출하면 컴파일러는 그 위치에 함수를 구현한 코드를 넣어줌

인라이닝 작동 방식

• 어떤 함수를 inline으로 선언하면 그 함수의 본문이 인라인됨
  • 인라인으로 선언한 함수를 호출하는 코드가 함수 본문을 번역한 바이트코드로 컴파일 됨
• 인라인 함수에 람다를 인자로 넘기면 람다의 본문도 함께 인라이닝 됨
  • 이 람다로 만들어진 바이트코드는 람다를 인자로 받은 함수의 일부분으로 간주되어 익명 클래스를 생성하지 않음
• 인라인 함수에 람다 대신 함수 타입의 변수를 넘길 수도 있음
  • 변수에 저장된 람다의 코드를 알 수 없어 람다 본문은 인라이닝 되지 않음
  • 일반적인 람다 호출과 같이 컴파일 됨

인라인 함수의 제약

• 람다를 사용하는 모든 함수를 인라이닝할 수는 없음
  • 함수 본문에서 파라미터로 받은 람다를 호출하면 인라이닝됨
  • 람다를 변수에 저장하고 그 변수를 호출하면 람다를 표현하는 객체가 존재해야 하기 때문에 인라이닝 할 수 없음

class FunctionStorage {
        var myStorageFunction((Int) -> Unit)? = null
        inline fun storerFunction(f: (Int) -> Unit) {
                myStorageFunction = f // 전달된 파라미터를 저장
        }
}

• 컴파일러는 Illegal usage of inline-parameter라는 메시지와 함께 인라이닝을 금지시킴

여러 람다 중 일부만 인라이닝 하기

• noinline 변경자를 파라미터 이름 앞에 붙여 인라이닝을 제한할 수 있음

inline fun foo(inline: () -> Unit, noinline NotInLined: () -> Unit) {
        /* ... */
}

컬렉션 연산 인라이닝

• 코틀린 표준 라이브러리의 컬렉션 함수 → 대부분 람다를 인자로 받음
  • 이 람다가 성능에 악형향을 끼치는가?

1. 람다 사용

    data class Person(val name: String, val age: Int)
   
    val people = listOf(Person("Alice", 29), Person("Bob", 31))
   
    fun main() {
            println(people.filter { it.age < 30 })
            // [Person(name=Alice, age=29)]
    }

2. 직접 기능 구현

    data class Person(val name: String, val age: Int)
   
    val people = listOf(Person("Alice", 29), Person("Bob", 31))
   
    fun main() {
            val result = mutableListOf<Person>()
            for (person in people) {
                    if(person.age > 30) result.add(person)
            }
            println(result)
            // [Person(name=Alice, age=29)]
    }

   • 1번 코드와 2번 코드의 바이트 코드는 거의 동일함
     • filter 함수 → 인라인 함수
     • filter 함수의 바이트코드는 전달된 람다 본문의 바이트코드와 함께 filter를 호출한 위치에 인라이닝 됨
   • 코틀힌 표준 라이브러리에서 제공하는 인라인 함수는 성능 걱정없이 사용해도 무관함

중간 리스트의 부가 비용

fun main() {
        println(
                people.filter { it.age > 30 }
                .map(Person::name)
        )
        // [Bob]
}

• filter와 map의 본문은 인라이닝됨
• 하지만 filter에서 걸러낸 결과를 저장하는 중간 리스트를 만듬
• map에서 이 중간 리스트를 읽어 최종 결과를 만들어냄

처리할 원소가 적다면 중간 리스트의 부가 비용이 크지 않다면 원소가 많아질수록 중간 리스트의 부가 비용을 고려해야 함

asSequence를 통한 부가 비용 감소

• asSequence를 통해 리스트 대신 시퀀스로 처리하면 중간 리스트로 인한 부가 비용을 줄일 수 있음
  • 각 중간 시퀀스는 람다를 필드에 저장하는 객체로 표현됨
  • 최종 연산은 중간 시퀀스에 있는 여러 람다를 연쇄 호출함
• 시퀀스 연산에서는 람다가 인라이닝 되지 않음
  • 크기가 작은 컬렉션은 일반 컬렉션 연산이 더 성능이 좋을 때도 있음
  • 시퀀스를 통해 성능을 향상시킬 수 있는 경우는 컬렉션의 크기가 큰 경우임

인라인 함수는 언제 선언하는가

인라인 키워드를 사용한다고 무조건 성능 개선 효과를 얻는 것은 아님

람다를 인자로 받는 함수만 성능이 좋아질 가능성이 있음

• 일반 함수 → 인라인 키워드를 사용해도 이익이 거의 없음
  • 일반 함수는 바이트코드에서 각 함수에 대한 구현이 딱 한번만 있으면 됨
  • 함수를 호출하는 부분에서 따로 중복이 발생하지 않음
• 코틀린 인라인 함수
  • 바이트코드에서 각 함수 호출 지점을 인라인 함수 본문으로 대치하여 코드 중복이 발생함
• 람다를 인자로 받는 인라인 함수
  • 인라이닝을 통해 없앨 수 있는 부가 비용이 많음
    • 함수 호출 비용을 줄일 수 있음
    • 람다를 표현하는 익명 클래스의 객체를 만들 필요 없음
  • 일반 람다에서는 사용할 수 없는 몇 가지 기능을 사용할 수 있음 (비로컬 return 등)

함수의 크기가 큰 경우 인라인이 비효율적일 수 있음

• 함수의 바이트코드를 모든 호출 지점에 복사해 넣으면 바이트 코드 전체의 크기가 커질 수 있음

자원 관리를 위해 인라인된 람다 사용

람다로 중복을 없앨 수 있는 일반적인 패턴 중 한가지 → 자원 관리

• 보통 try/finally문으로 자원 획득과 자원 해제를 제어

withLock

• Lock 인터페이스의 확장 함수

// 코틀린 라이브러리의 withLock 함수 정의
fun <T> Lock.withLock(action: () -> T): T {
        lock()
        try {
                return action()
        } finally {
                unlock()
        }
}

// withLock 사용 방법
val l: Lock = ReentrantLock()
l.withLock{
        // 락에 의해 보호되는 자원 사
}

use 함수

• 닫을 수 있는 자원(Closeable)에 대해 호출하는 확장 함수
• 람다를 호출하고 사용 후 자원을 확실하게 닫음
• use 함수는 인라인 함수임

import java.io.BufferedReader
import java.io.FileReader

fun readFirstLineFromfile(fileName: String): String {
        BufferReader(FileReader(fileReader)).use { br -> 
                return br.readLine()        
        }
}

useLines 함수

• File, Path 객체에 대해 정의돼 있음
• 람다가 문자열 시퀀스에 접근하게 해줌

import kotlin.io.path.Path
import kotlin.io.path.useLines

fun readFirstLineFromFile(fileName: String): String {
        Path(fileName).useLines {
                return it.first()
        }
}

코틀린에서는 try-with-resources를 사용하지 말라

• try-with-resources → 자바에서 Closeable 자원에 사용할 수 있는 구문

static String readFirstLineFromFile(String fileName) throw IOException {
        try(BufferfReader br = new BufferdReader(new FileReader(fileName))) {
                return br.readLine();
        }
}

• 이 기능을 코틀린에서 use 같은 함수를 통해 간단하게 구현할 수 있음

• 람다 or 함수 참조를 통해 함수를 값으로 표현할 수 있음
• 이를 통해 함수를 인자로 넘기거나 반환 받는 것이 가능

filter 함수도 고차 함수임

• 람다를 인자로 받기 때문

list.filter { it > 0 }

이제 고차 함수를 정의하는 방법을 알아본다. 고차 함수를 정의하려면 먼저 함수 타입을 알아야 함

함수 타입은 람다의 파라미터 타입과 반환 타입을 지정한다

람다를 로컬 변수에 대입

• 코틀린의 타입 추로으로 변수 타입을 지정하지 않아도 람다를 변수에 대입할 수 있음

val sum = { x: int, y: Int -> x + y } 
val action = { println(42) }

• 컴파일러 → sum과 action이 함수 타입임을 추론함

각 변수에 구체적인 타입 선언 추가

val sum: (Int, Int) -> Int = {x, y -> x + y}
val action: () -> Unit = { println(42) }

• 함수 파라미터의 타입을 괄호 안에 명시
• 그 뒤에 화살표를 추가
• 화살표 다음에 함수의 반환 타입을 지정
• Unit 타입 → 값을 반환하지 않는 함수 반환 타입에 쓰는 특별한 타입
  • 함수 타입을 선언할 때는 반환할 때는 반환 타입을 반드시 명시해야 하므로 Unit 타입을 명시해야 함
• 함수 타입을 명시한다면 람다 내부에는 타입을 생략해도 됨

함수 타입도 반환 타입을 null이 될 수 있는 타입으로 지정할 수 있음

var canReturnNull: (Int: Int) -> Int? = { x, y -> null }

함수 타입 자체를 null이 될 수 있는 타입으로 정의할 수 있음

• 힘수 타입을 괄호로 감싸고 그 뒤에 물음표를 붙여야 함

var funOrNull: ((Int, Int) -> Int)? = null

인자로 전달 받은 함수 호출

고차 함수를 어떻게 구현하는지 알아본다

간단한 고차 함수 정의

fun twoAndThree(operation: (Int, Int) -> Int) { // 함수 타입인 파라미터를 선언
        val result = operation(2, 3) // 함수 타입인 파라미터를 호출
        println("The result is $result")
}

fun main() { 
        twoAndThree { a, b -> a + b }
        // The result is 5
        twoAndThree { a, b -> a * b }
        // The result is 6
}

• 인자로 받은 함수를 호출하는 방법은 일반 함수를 호출하는 구문과 같음

파라미터 이름과 함수 타입

• 함수 타입에서 파라미터 이름을 지정할 수 있음

  fun twoAndThree(operation: (operandA: Int, operandB: Int) -> Int) { // 함수 타입인 파라미터를 선언
        val result = operation(2, 3) // 함수 타입인 파라미터를 호출
        println("The result is $result")
  }
  fun main() { 
        twoAndThree { operandA, operandB -> operandA + operandB } // API에서 지정한 이름을 람다에 사용할 수 있음
        // The result is 5
        twoAndThree { alpha, beta -> alpha + beta } // 그냥 원하는 이름도 사용할 수 있음
        // The result is 5
  }

filter 함수 구현 예제

예제를 단순하게 유지하기 위해 String에 대한 filter를 구현

fun String.filter(predicate: (Char) -> Boolean): String { 
        return buildString { 
                for (char in this@filter) { //입력 문자열 이터레이션
                        if (predicate(char)) append(char) // predicte 파라미터로 전달받은 함수를 호출
                }
        }
}

fun main() { 
        println("ab1c".filter { it in 'a' .. 'z' })
        ///abc
}

• filter 함수 → 문자열의 각 문자가 술어를 만족하는지 검사
• 술어를 만족하는 문자는 StringBuilder의 append를 사용해 결과를 만들고 반환
• 레이블이 붙은 this → 10.6절에서 자세히 다룸

자바에서 코틀린 함수 타입 사용

• SAM 변환을 통해 코틀린 람다를 자바 메서드에 옮길 수 있음
• 함수 타입을 사용하는 코틀린 코드를 자바에서 쉽게 호출할 수 있음’
• 자바 람다는 자동으로 코틀린 함수 타입으로 변환됨

/* 코틀린 선언*/
fun processTheAnswer(f: (Int) -> Int) {
        println(42)
}

/* 자바 호출 */
processTheAnswer(number -> number + 1);

자바에서 코틀린 함수 타입 호출시 수신 객체를 명시해줘야 함

import kotlin.collections.CollectionsKt;

/ *... */
public static void main(String[] arg) {
        List<String> strings = new ArrayList();
        strings.add("42");
        CollectionsKt.forEach(strings, s -> { // 코틀린 표준 라이브러리 함수 호출 가능
                System.out.println(s);
                return Unit.INSTANCE; // Unit 타입의 값을 명시적으로 반환해야 함
        });
}

• Unit을 반환하는 함수나 람다를 호출할 때는 Unit 타입의 값을 명시적으로 반환해줘야 함
  • Unit 타입에는 값이 존재하기 때문
• 값이 존재하기 때문에 Unit 타입을 반환하는 코틀린 함수에 void 타입 자바 람다를 넘길 수 없음

함수 타입의 자세한 동작 방식

• 함수 타입의 변수 → FunctionN 인터페이스를 구현
  • 인자의 개수에 따라 FunctionN의 N값이 바뀜
• 각 인터페이스에는 invoke라는 유일한 메서드가 있음
  • 이 메서드를 호출하면 함수가 호출됨
  • invoke에 대해선 13장에 자세히 다룸

interface Function1<P1, out R>{
        operator fun invoke(p1: P1): R
}

• 함수 타입의 변수 → 함수에 대응하는 FunctionN 인터페이스를 구현하는 클래스의 인스턴스
  • invoke 메서드에는 람다 본문이 들어감

fun processTheAnswer(f: Function1<Int, Int>) {
        println(f.invoke(42))
}

• FunctionN 인터페이스 → 컴파일러가 생성한 합성 타입으로 코틀린 표준 라이브러리에서 이들의 정의를 찾을 수 없음
  • 컴파일러가 필요할 때 이런 함수를 생성
  • 파라미터의 개수 제한 없이 파라미터를 사용하는 함수에 대한 인터페이스를 사용할 수 있음

함수 타입의 파라미터 기본값 지정과 null 이 될 수 있는 타입

함수 타입에 기본값 지정

함수 타입의 파라미터에 대한 기본값으로 람다식을 지정해놓으면 호출할 때마다 람다를 넘겨주지 않아도 되고 필요 시 람다를 넘겨 원하는 기능을 추가할 수 있음

fun <T> Collection<T>.joinToString(
        separator: String = ",",
        prefix: String,
        postfix: String,
        transform: (T) -> String = { it.toString() } // 함수 타입 파라미터를 선언하면서 람다를 기본값으로 지정
): String {
        val result = StringBuilder(prefix)

        for((index, element) in this.withIndex()) {
                if(index > 0) result.append(separator)
                result.append(transform(element)) // transform 파라미터에 대한 인자로 받은 함수 호출
        }

        result.append(postfix)
        return result.toString()
}

fun main() {
        val letters = listOf("Alpha", "Beta")
        println(letters.joinToString()) //transform 기본 함수 사용
        // Alpha, Beta
        println(letters.joinToString { it.lowercase() }) // 람다를 인자로 전달
        // alpha, beta
        println(letters.joinToString(seperator="! ", postfix="! ", transform={ it.uppercase() }))
        // 이름 붙은 인자 구문을 사용해 람다를 포함하는 여러 인자를 전달
        // ALPHA! BETA!
}

• 함수 타입에 대한 기본값 선언도 = 뒤에 람다를 넣으면 됨

null이 될 수 있는 함수 타입

• null이 될 수 있는 함수 타입으로 하수를 받으면 그 함수를 직접 호출할 수 없음
  • null 여부를 명시적으로 검사하면 호출은 할 수 있음
  • invoke를 사용하여 간결하게 해결할 수도 있음
• 함수 타입 → invoke 메서드를 구현하는 인터페이스
  • 일반 메서드처럼 invoke도 안전한 호출을 사용할 수 있음

fun <T> Collection<T>.joinToString(
        separator: String= ", ",
        prefix: String="",
        postfix: String = "",
        transform: ((T) -> String)? = null
): String {
        val result = StringBuilder(prefix)

        for((index, element) in this.withIndex()) {
                if (index > 0) result.append(separator)
                val str = transform?.invoke(element) ?: element.toString()
                result.append(str)
        }

        result.append(postfix)
        return result.toString()
}

함수를 함수에서 반환

프로그램 상태나 다른 조건에 따라 달라질 수 있는 로직이 있다면 함수를 반환하는 기능이 유용함

함수를 반환하는 함수

enum class Delivery { STANDARD, EXPEDITED }

class Order(val itemCount: Int)

fun getShppingCostCalculator(delivery: Delivery): (Order) -> Double { // 함수를 반환하는 함수 선언
        if(delivery == Delivery.EXPEDITED) {
                return { order -> 6 + 2.1 * order.itemCount } // 함수에서 람다를 반환
        }
        return { order -> 1.2 * order.itemCount } // 함수에서 람다를 반환
}

fun main() {
        val calculator = getShippingCostCalculator(Delivery.EXPEDITED) // 함수를 반환받아 저장
        println("Shipping costs ${calculator(Order(3))}") // 반환받은 함수 호출
        // Shipping costs 12.3
}

• 함수에서 함수를 반한하려면 반환 타입으로 함수 타입을 지정해줘야 함
  • getShppingCostCalculator는 Order 객체를 받아 Double 타입을 반환하는 함수를 반환함
• 함수를 반환하려면 return식에 람다, 맴버 참조, 함수 타입의 값을 계산하는 식을 넣으면 됨

함수를 반환하는 함수를 UI 코드에서 사용하기

data class Person(
    val firstName: String,
    val lastName: String,
    val phoneNumber: String?
)

class ContactListFilters {
    var prefix:String = ""
    var onlyWithPhoneNumber: Boolean = false

    fun getPrediction(): (Person) -> Boolean { // 함수를 반환하는 함수 정의
        val startWithPrefix = { p: Person ->
            p.firstName.startsWith(prefix) || p.lastName.startsWith(prefix)
        }
        if(!onlyWithPhoneNumber) {
            return startWithPrefix // 함수 타입의 변수 반환
        }
        return { startWithPrefix(it) && it.phoneNumber != null } // 람다를 반환
    }
}

fun main() {
    val contact = listOf(
        Person("Dmitry", "Jemerov", "123-4567"),
        Person("Svetlana", "Isakova", null)
    )
    val contactListFilters = ContactListFilters()
    with (contactListFilters) {
        prefix = "Dm"
        onlyWithPhoneNumber = true
    }

    println(
        contact.filter(contactListFilters.getPrediction()) // 반환한 함수를 filter에 인자로 넘김
    )
    // [Person(firstName=Dmitry, lastName=Jemerov, phoneNumber=123-4567)]
}

• getPredicate 메서드 → filter 함수에 인자로 넘길 수 있는 함수를 반환함

람다를 통한 코드 재사용성 높이기

람다식 → 재사용성을 높이는 훌륭한 도구

• 반복적으로 사용되는 코드를 람다로 추출해 함수에 인자로 넘기면 코드를 재사용 하면서 코드 중복을 제거할 수 있음

웹 사이트 방문 기록 분석 예시

데이터 정의

data class SiteVisit(
    val path: String,
    val duration: Double,
    val os: OS
)

enum class OS { WINDOW, LINUX, MAC, IOS, ANDROID }

val log = listOf(
    SiteVisit("/", 34.0, OS.WINDOW),
    SiteVisit("/", 22.0, OS.MAC),
    SiteVisit("/login", 12.0, OS.WINDOW),
    SiteVisit("/signup", 8.0, OS.IOS),
    SiteVisit("/", 16.3, OS.ANDROID)
)

1. 사이트 방문을 하드 코딩한 필터

    val averageWindowsDuration = log
        .filter { it.os == OS.WINDOW }
        .map(SiteVisit::duration)
        .average()
   
    fun main() {
        println(averageWindowsDuration)
        //23.0
    }

2. 일반 함수를 통해 코드 중복 제거

    fun List<SiteVisit>.averageDurationFor(os: OS) =
        filter { it.os == os }.map(SiteVisit::duration).average()
   
    fun main() {
        println(log.averageDurationFor(OS.WINDOW))
        // 23.0
        println(log.averageDurationFor(OS.MAC))
        // 22.0
    }

   • OS를 파라미터로 뽑아내 코드 중복을 해결

3. 하드 코딩된 필터를 로컬 함수로 정의하기

fun main() {
    val averageMobileDuration = log
        .filter { it.os in setOf(OS.IOS, OS.ANDROID) }
        .map(SiteVisit::duration)
        .average()
    println(averageMobileDuration)
    //12.15
}

4. 고차 함수를 사용해 중복 제거하기

fun List<SiteVisit>.averageDurationFor(predicate: (SiteVisit) -> Boolean) =
    filter(predicate).map(SiteVisit::duration).average()

fun main() {
    println(
        log.averageDurationFor { it.os in setOf(OS.ANDROID, OS.IOS) }
    )
    // 12.15
    println(
        log.averageDurationFor { it.os == OS.IOS && it.path == "/signup" }
    )
    // 8.0
}

• 중복되는 코드를 고차 함수로 뽑아냄으로써 코드 중복을 제거할 수 있음
• 뿐 만 아니라 함수 타입을 사용하면 필요한 조건을 파라미터로 뽑아낼 수 있음
  • 복잡한 로직을 간단하게 구현 가능

위임 프로퍼티의 기본 문법과 내부 동작

import java.lang.reflect.Type

class Delegate(){
    operator fun getValue(/*...*/) { /*...*/ } // getter를 구현하는 로직

    operator fun setValue(/*...*/, value: Type) { /*...*/ } // setter를 구현하는 로직

    operator fun provideDelegate(/*...*/): Delegate { /*...*/ } // 위임 객체 생성, 제공
}

class Foo {
    var p : Type by Delegate() // by 키워드 : 프로퍼티와 위임 객체를 연결
}

fun main() {
    val foo = Foo() // provideDelegate 호출
    val oldValue = foo.p // delegate.getValue 호출
    foo.p = newValue // delegate.setValue 호출
}

• 관례에 따라 Delegate 클래스는 getValue와 setValue를 제공해야 함
• 변경 가능한 프로퍼티만 setValue응 사용
• provideDelegate 함수는 선택적으로 구현
  • 최초 생성시 검증 로직
  • 위임이 인스턴스화 되는 방식 변경
• foo.p → Delegate 타입의 위임 프로퍼티 객체에 있는 메서드를 호출

by lazy()를 사용한 지연 초기화

• 객체의 일부분을 초기화하지 않고 나중에 필요할 때 초기화하는 패턴
  • 초기화 과정에서 자원을 많이 사용하거나 객체를 사용할 때마다 꼭 초기화 하지 않아도 되는 프로퍼티에 사용할 수 있음

뒷받침하는 프로퍼티를 사용해 지연 초기화 구현

class Email { /*...*/ }

fun loadEmails(person: Person): List<Email> {
    println("${person.name}의 이메일을 가져옴")
    return listOf(/*...*/)
}

class Person(val name: String) {
    private var _emails: List<Email>? = null // 데이터를 저장하고 emails의 위임 객체 역할을 하는 프로퍼티

    val emails: List<Email>
        get() {
            if(_emails == null) {
                _emails = loadEmails(this) // 최초 접근시 이메일을 가져옴
            }
            return _emails!! // 저장해놓은 데이터가 있으면 그 데이터를 반환
        }
}

fun main() {
    val p = Person("Alice")
    p.emails // 최초로 emails에 접근할 때만 이메일을 가져옴
    // Alice의 이메일을 가져옴
    p.emails
}

• 뒷바침하는 프로퍼티를 사용

  • 외부로는 읽기 전용 프로퍼티를 제공하고 내부에는 가변 프로퍼티를 사용
  • 데이터 캡슐화 강화, 가변 데이터의 안전한 관리, 읽기 전용 API 제공

• _emails → 값을 저장, null이 될 수 있는 타입

• emails → _emails에 대한 읽기 연산을 제공, null이 될 수 없는 타입

• 뒷바침하는 프로퍼티의 이름은 관례를 따름

  • 비공개 프로퍼티 앞에 언더바( _ )를 붙임
  • 공개 프로퍼티는 아무것도 붙이지 않음

• 뒷받침하는 프로퍼티 사용의 단점

  1. 코드가 복잡함
  2. 스레드 안전한 구현이 아님
     • loadEmails 함수에 여러 스레드에서 동시 접근할 경우 일관성이 망가질 수 있음
  • 이 문제들을 위임 프로퍼티를 사용해 해결할 수 있음

위임 프로퍼티를 통한 지연 초기화 구현

• 위임 프로퍼티를 사용하면 간결하게 구현할 수 있음
  • 데이터를 저장할 때 쓰이는 뒷파침하는 프로퍼티와 값이 오직 한 번만 초기화됨을 보장하는 게터 로직을 함께 캡슐화해줌

class Person(val name: String) {
        val emails by lazy { loadEmails(this) }
}

• lazy 함수
  • 코틀린 관례에 맞는 시그니처의 getValue 메서드가 들어있는 객체를 반환함
  • by 키워드를 함께 사용해 위임 프로퍼티를 만들 수 있음
  • 인자 → 값을 초기화 할 때 호출할 람다임
  • 기본적으로 thread-safe한 함수임
  • 필요하면 동기화 락을 lazy 함수에 전달할 수 있음
  • 다중 스레드 환경에서 사용하지 않을 프로퍼티를 위해 동기화를 생략할 수도 있음

위임 프로퍼티 구현

observable 예시

• observable : 어떤 객체를 UI에 표시하는 경우 객체가 바뀌면 자동으로 UI도 바뀌는 프로그램

1. 위임 프로퍼티 없이 구현

fun interface Observer {
        fun onChange(name: String, oldValue: Any?, newValue: Any?)
}

open class Observable {
        val observers = mutableList<Observer>()
        fun notifyObservers(propName: String, oldValue: Any?, newValue: Any?) {
                for(obs in observers){
                        obs.onChange(propName, oldValue, newValue)
                }
        }
}

• Observable 클래스 → Observer 리스트 관리
• NotifyObservers → 등록된 모든 Observer의 onChange 함수를 통해 프로퍼티의 이전 값과 새 값을 전달
• Observers → onChage에 대한 구현만 제공하면 됨

class Person(val name: String, age: Int, salary: Int): Observable() {
        var age: Int = age
                set(newValue){
                        val oldValue = field // 뒷받침하는 프로퍼티에 접근할 때 field 식별자를 사용
                        field = newValue
                        notifyObservers("age", oldValue, newValue)
                }

        var salary: Int = salary
                set(newValue){
                        val oldValue = field
                        field = newValue
                        notifyObservers("salary", oldValue, newValue)
                }
}

fun main() {
        val p = Person("seb", 28, 1000) 
        p.observers += Observer {propName, OldValue, newValue -> 
                // 함수형 인터페이스에 대한 간편한 구문을 사용해
                // 옵저버를 생성하고 이를 등록하여 프로퍼티의 변경을 기다림
                println(                                             
                    """
                    Property $propName changed from $oldValue to $newValue!
                    """.trimIndent()
                )
        } 
        p.age = 29
        // Property age changed from 28 to 29
        p.salary = 1500
        // Property salary changed from 1000 to 1500
}

• Field 키워드를 사용해 age, salary 프로퍼티를 뒷받침하는 필드에 접근
• Setter코드의 중복이 많음

2. 도우미 클래스를 통해 프로퍼티 변경 통지 구현

class ObservableProperty(
        val propName: String,
        var propValue: Int,
        val observable: Observable
) {
        fun getValue(): Int = propValue
        fun setValue(newValue: Int) {
                val oldValue = propName
                propValue = newValue
                observable.notyiObservers(propName, oldValue, newValue)
        }
}

class Person(val name: String, age: Int, salary: Int): Observable() {
        val _age = observableProperty("age", age, this)
        var age: Int
                get() = _age.getValue()
                set(newValue) {
                        _age.setValue(newValue)
                }
        val _salary = ObservableProperty("salary", salary, this)
        var salary: Int
                get() = _salary.getValue()
                set(newValue) {
                        _salary.setValue(newValue)
                }
}

• 프로퍼티 값을 저장하고 그 값이 바뀌면 자동으로 변경을 통지
• 중복을 상당 부분 제거했으나 아직 각각의 프로퍼티마다 ObservableProperty를 만들고 작업을 위임하는 코드가 중복됨
• 코틀린 위임 프로퍼티 기능ㅇ로 이런 중복 조차 없앨 수 있음

3. 프로퍼티 위임 객체

import kotiln.reflect.KProperty 

class ObservableProperty(var propValue: Int, val observable: Obvservable) { 
        operator fun getValue(thisRef: Any?, prop: KProperty<*>): Int = propValue
        operator fun setValue(thisRef: Any?, prop: KProperty<*>, newValue: Int) { 
                val oldValue = propValue
                propValue = newValue
                observable.notifyObservers(prop.name, oldValue, newValue)
        }
}

• 코틀린 관례에 사용하는 다른 함수처럼 getValue, setValue 함수에도 operator 변경자가 붙음
• GetValue와 setValue는 파라미터 2개를 받음
  • ThisRef → 설정하거나 읽을 프로퍼티가 들어있는 인스턴스
  • Prop → 프로퍼티를 표현하는 객체
    • KProperty 타입의 객체를 사용하여 프로퍼티를 표현
• KProperty 인자를 통해 프로퍼티 이름을 전달받으므로 주 생성자에서는 name 프로퍼티를 없앰

class Person(val name: String, age: Int, salary: Int): Observable() { 
        var age by ObservableProperty(age, this)
        var salary by ObservableProperty(salary, this)
}

• By 키워드를 사용하여 위임 객체를 지정
  • Getter/setter를 직접 지저하는 등의 작업을 컴파일러가 자동으로 해줌

4. Delegates.observable을 사용해 프로퍼티 변경 통지 구현하기

• ObservableProperty 클래스를 직접 구현하는 대신 표준 라이브러리 기능 활용하기
• 앞에서 구현한 Observable 클래스오는 연결되어 있지 않음

import kotiln..properties.Delegates

class Person(val name: String, age: Int, salary: Int): Observable() { 
        private val onChange = { 
        property: KProperty<*>, 
        oldValue: Any?, 
        newValue: Any? -> notifyObservers(property.name, oldValue, newValue)
        }

        var age by Delegates.observable(age, onChange)
        var salary by Delegates.observable(salary, onChange)
}

• 프로퍼티 값의 변경을 통지받을 때 쓰일 람다를 Delegates 라이브러리 클래스에 넘겨야 함
• By의 오른쪽에 있는 식 → 꼭 새 인스턴스를 만들 필요는 없음
  • 함수 호출, 다른 프로퍼티, 다른 식 등도 올 수 있음
  • 다만 결과 객체는 컴파일러가 호출할 수 있는 올바른 타입의 getValue와 setValue를 반드시 제공해야 함

프로퍼티 위임은 완전히 제네릭하여 모든 타입에 사용할 수 있음

위임 프로퍼티의 동작 방식

위임 프로퍼티 클래스 예시

class C { 
        var prop: Type by MyDelegate()
}

val c = C()

• MyDelegate 클래스의 인스턴스 → 감춰진 프로퍼티에 저장됨
  • 라는 이름으로 부름
• 프로퍼티 표현 → KProperty 타입의 객체를 사용
  • 라는 이름으로 부름

컴파일러는 다음의 코드를 생성

class C { 
        private val <delegate> = MyDelegate()

        var prop: Type
                get() = <delegate>.getValue(this, <property>)
                set(value: Type) = <delegate>.setValue(this, <property>, value)
}

• 프로퍼티 값이 저장될 장소를 바꿀 수 있음 (맵, db 테이블, 웹 쿠키 등)
• 프로퍼티를 읽거나 쓸 때 실행할 작업을 변경할 수 있음

맵에 위임해서 동적으로 애트리뷰트 접근

자신의 프로퍼티를 동적으로 정의할 수 있는 객체를 만들 때 위임 ㅍ로퍼티를 활용하는 경우가 자주 있음

• C++에선 그런 객체를 확장 가능한 객체(expando object)라고 부름
• 속성을 모두 맴에 저장하되 특별한 처리가 필요한 정보에 접근하도록 프로퍼티를 제공할 수 있음

class Person { 
        private val _attributes = mutableMap<String, String>()

        fun setAttributes(attrName: String, value: String) {
                _attributes[attrName] = value
        }

        var name: String
                get() = _attributes["name"]!!
                set(value) { 
                        _attributes["name"] = value
                }
}

fun main() { 
        val p = Person()
        val data = mapOf("name" to "Seb", "company" to "JetBrains")
        for((attrName, value) in data)
                p.setAttribute(attrName, value)
        println(p.name)
        // Seb
        p.name = "Sebastian"
        println(p.name)
        // Sebastian    
}

• 추가 데이터를 객체에 읽어 들이기 위해 일반적인 API를 사용
• 한 프로퍼티를 처리하기 위해 구체적인 API를 제공

값을 맵에 저장하는 위임 프로퍼티 사용

By 키워드 뒤에 맵을 직접 넣음

class Person {
        private val _attributes = mutableMapOf<String, String>()

        fun setAttribute(attrName: String, value: String) {
                _attribute[attrName] = value
        }

        var name: String by _attributes // 위임 프로퍼티로 맵 사용
}

• 코드가 작동하는 이유 → 표준 라이브러리가 Map과 MutableMap 인터페이스에 getValue와 setValue 확장 함수를 제공하기 때문
• P.name → _attribute.getValue(p, prop)을 호출
• _attribute.getValue(p, prop)는 -attributes[prop.name]을 통해 구현

실전 프레임워크가 위임 프로퍼티를 활용하는 방법

• 객체 프롶티를 저장하거나 병경하는 방법을 바꿔 프레임워크 개발에 활용

위임 프로퍼티를 사용해 데이터베이스 칼럼에 접근

• User라는 데이터베이스 테이블이 있음
  • Name이라는 문자열 타입의 칼럼
  • Age라는 정수 타입의 칼럼
• User와 Users라는 클래스를 정의해 데이터베이스에 있는 모든 사용자 엔티티를 User클래스로 가져오고 저장할 수 있음

object Users: IdTable() { // 데이터베이스 테이블
        val name = varchar("name", length = 50).index() // 테이블 칼럼
        val age = integer("age")
}

class User(id: EntityID): Entity(id) { // 각 테이블에 들어있는 구체적인 엔티티
        var name: String by Users.name // 데잍베이스에 저장된 사용자의 이름 값
        var age: Int by Users.age
}

• Users 객체 → 데잍베이스 테이블을 표현
  • 데이터베이스는 전체에 단 하나만 존재하는 테이블을 표현하므로 싱글턴 객체로 선언
  • 객체의 프로퍼티는 칼럼을 표현
• User의 상위 클래스인 Entity 클래스 → 데이터베이스 칼럼을 엔티티의 속성값으로 연결해주는 매핑
  • 데이터베이스에서 가져온 name, age가 있음
  • User의 프로퍼티에 접근할 때 자동으로 Entity 클래스에 정의된 데이터베이스 매핑으로부터 필요한 값을 가져옴
  • 객체를 변경하면 객체가 변경됨(dirty) 상태로 변하고 나중에 데이터베이스에 적절히 변경을 반영해줌

데이터베이스 접근 분석

• Users의 칼럼 타입을 명시적으로 지정한 모습

object Users: IdTable() {
        val name: Column<String> = varchar("name", 50).index()
        val age: Column<Int> = integer("age")
}

• 프레임워크는 Column 클래스 안에 getValue, setValue 메서드를 정의

  • 코틀린 위임 객체에 관례에 따른 시그니처 요구 사항을 충족

    operator fun <T> Column<T>.getValue(o: Entity, desc: KProperty<*>): T { 
          // 데이터베이스에서 칼럼 값 가져오기
    }
    
    operator fun <T> Column<T>.setValue(o: Entity, desc: KProperty<*>, value: T) { 
          // 데이터베이스의 값 변경하기
    }

Column 프로퍼티를 위임 프로퍼티에 대한 위임 객체로 사용할 수 있음

• User.age += 1 → user.ageDelegate.setValue(user.Delegate.getValue()+1)와 비슷한 코드로 변환됨
• GetValue/setValue → 데이터베이스에서 데이터를 가져오고 기록하는 작업을 처리

사용 방법

fun main() {
        val p = Point(10, 20)
        val (x, y) = p // p의 여러 컴포넌트로 초기화
        println(x)
        // 10
        println(y)
        // 20
}

• 일반 변수 선언과 비슷해 보이지만 = 왼쪽에 여러 변수를 괄호로 묶음
• 구조 분해 선언은 관례를 사용함 → componenN 이라는 함수를 호출

• data 클래스의 주 생성자에 들어있는 프로퍼티 → 컴파일러가 자동으로 componentN 함수를 만들어줌

class Person(val x: Int, val y: Int) {
        operator fun component1() = x
        operator fun component2() = y
}

예시

data class NameComponent(val name: String, val extension: String)

fun splitFilename(fullName: String): NameComponent {
    val (name, extension) = fullName.split('.', limit = 2)
    return NameComponent(name, extension)
}

fun main() {
    val (name, ext) = splitFilename("example.txt")
    println(name)
    // example
    println(ext)
    // txt
}

• componentN을 무한히 선언할 수는 없음
  • 코틀린 표준 라이브러리에서는 맨 앞의 다섯 원소에 대한 componentN을 제공

구조 분해 선언과 루프

• 변수 선언이 들어갈 수 있는 모든 곳에 구조 분해 선언을 사용할 수 있음

fun printEntries(map: Map<String, String>) {
    for((key, value) in map) {
        println("$key -> $value")
    }
}

fun main() {
    val map = mapOf("Oracle" to "Java", "JetBrains" to "Kotlin")
    printEntries(map)
    // Oracle -> Java
    // JetBrains -> Kotlin
}

• 위 예제는 2가지의 관례를 사용함

  1. 이터레이션 관례
     • 코틀린 표준 라이브러리 → map에 대한 확장함수로 iteration이 들어있음
     • 맵 항목에 대한 이터레이터를 반환
  2. 구조 분해 선언
     • 코틀린 라이브러리 → map.Entry에 대한 확장함수로 component1, component2를 제공

• 람다가 data class나 map 같은 복합적인 파라미터로 받을 때도 구조 분해 선언을 쓸 수 있음

map.forEach { (key, value) ->
        println("$key -> $value")
}

_ 문자를 사용해 구조 분해 값 무시

• 컴포넌트가 여럿 있는 객체에 대한 구조 분해 선언 중 일부 필요하지 않은 컴포넌트를 무시

data class Person(
    val firstName: String,
    val lastName: String,
    val age: Int,
    val city: String
)

fun introducePerson(p: Person) {
    val (firstName, _, age) = p
    println("This is $firstName, aged $age")
}

fun main() {
    val me = Person("yoo", "wuseon", 26, "ganwondo")
    introducePerson(me)
    // This is yoo, aged 26
}

코틀린 구조 분해의 한계

• 구조 분해 연산의 결과 → 인자의 위치에 따라 결정됨
  • 코드를 리펙터링 할 때 클래스 프로퍼티의 순서를 바꾸면 미묘한 문제가 발생할 수 있음
  • 이 문제를 해결하기 위해 이름 기반 구조 분해가 개발되고 있는 중임