작년 하반기 카카오 2차 코테 문제인데, 그때는 못풀었던 것 같다. 해설이 궁금해서 찾아보니, 슬라이딩 윈도우를 가로세로로 각각 적용해서 푸는 문제라고 한다.

슬라이딩 윈도우의 개념만 알고 있었지, 이를 코드로 구현하는데는 자신이 없었던 지라 기본 개념을 코드로 옮기는 방법부터 문제 풀이까지 포스팅 해보려고 한다.

1. 슬라이딩 윈도우란?

슬라이딩 윈도우(Sliding Window)는 고정된 크기의 구간(window)을 한 칸씩 이동시키며 값을 계산하는 기법이다.

예를 들어 배열이 다음과 같다고 하자:

[4, 2, 7, 1, 5]

길이 k = 3인 구간을 본다면:

[4, 2, 7]
   [2, 7, 1]
      [7, 1, 5]

이처럼 창(window)을 오른쪽으로 이동시키며 계산한다.

왜 필요한가?

각 구간마다 min() 또는 max()를 구하면:

시간복잡도: O(n * k)

n과 k가 클 경우 비효율적이다.

deque 기반 슬라이딩 윈도우

슬라이딩 윈도우를 O(n)으로 줄이는 핵심 아이디어는 다음과 같다.

"쓸모 없는 값은 미리 제거한다"

슬라이딩 윈도우 핵심 코드 패턴

# 1. 큰 값 제거
while dq and arr[dq[-1]] >= arr[i]:
    dq.pop()

# 2. 현재 값 추가
dq.append(i)

# 3. 범위 밖 제거
if dq[0] <= i - k:
    dq.popleft()
# 4. 앞
if i >= k - 1:
    result.append(arr[dq[0]])

직관

deque는 항상 다음과 같은 상태를 유지한다:

앞 → 최소값
뒤 → 큰 값들

작은 값은 오래 살아남고, 큰 값은 제거된다.

예시

arr = [4, 2, 7, 1, 5], k=3
결과: [2, 1, 1]

과정:

2. 선인장 숨기기 문제

문제 요약

• m x n 격자
• 비가 떨어지는 순서가 주어짐
• h x w 크기의 직사각형을 놓는다
• 해당 영역에서 가장 먼저 비 맞는 시간 (최솟값)을 구한다
• 그 값이 가장 큰 위치를 찾는다

핵심 아이디어

직사각형 최소값을 빠르게 구하는 것이 핵심이다.

naive 접근

직사각형마다 전체 탐색 → O(n^3)

최적화 전략

1. 가로 슬라이딩 (w)
2. 세로 슬라이딩 (h)

2차원 문제를 1차원 두 번으로 나눈다.

Step 1: rain 배열 생성

rain[r][c] = 해당 칸에 비가 오는 시간

비가 오지 않는 칸은 INF

Step 2: 가로 슬라이딩

각 행에서 길이 w 구간의 최소값을 구한다.

예:

[1, INF, INF, INF, 8]
→ [1, INF, INF, 8]

결과를 row_min에 저장한다.

Step 3: 세로 슬라이딩

row_min을 기준으로 세로 h 구간의 최소값을 구한다.

핵심 직관

직사각형 최소값 = 각 행의 가로 최소값들 중 최소

따라서 가로 → 세로 순서로 계산하면 된다.

예제1

m=4, n=5, h=2, w=2

rain 배열

[1, INF, INF, INF, 8]
[INF, 5, INF, 3, INF]
[INF, INF, 6, 7, 4]
[INF, 2, INF, INF, INF]

가로 슬라이딩 결과

[1, INF, INF, 8]
[5, 5, 3, 3]
[INF, 6, 6, 4]
[2, 2, INF, INF]

세로 슬라이딩 결과

[1, 5, 3, 3]
[5, 5, 3, 3]
[2, 2, 6, 4]

최종 결과

가장 큰 값은 6

정답: [2, 2]

시간복잡도

가로: O(m * n)
세로: O(m * n)
총: O(m * n)

정답 코드

from collections import deque

def solution(m, n, h, w, drops):
    total = m * n
    INF = 999

    rain = [INF] * total

    # 2차원 배열을 1차원 배열로 변환
    for i in range(len(drops)):
        r, c = drops[i]
        rain[r * n + c] = i + 1
    print(rain)

    new_n = n - w + 1
    row_min = [0] * (m * new_n)

    # 가로 슬라이딩 윈도우 (row 기준)
    for r in range(m):
        dq = deque()

        for c in range(n):
            while dq and rain[r*n + dq[-1]] >= rain[r*n + c]:
                dq.pop()

            dq.append(c)

            if dq[0] <= c - w:
                dq.popleft()

            if c >= w - 1:
                row_min[r * new_n + (c - w + 1)] = rain[r*n + dq[0]]

    new_m = m - h + 1

    best_time = -1
    best_r = 0
    best_c = 0

    # 세로 슬라이딩 윈도우 (column 기준)
    for c in range(new_n):
        dq = deque()

        for r in range(m):
            val = row_min[r * new_n + c]

            while dq and row_min[dq[-1] * new_n + c] >= val:
                dq.pop()

            dq.append(r)

            if dq[0] <= r - h:
                dq.popleft()

            if r >= h - 1:
                cur = row_min[dq[0] * new_n + c]
                sr = r - h + 1

                if (cur > best_time or
                   (cur == best_time and (sr < best_r or (sr == best_r and c < best_c)))):

                    best_time = cur
                    best_r = sr
                    best_c = c

    return [best_r, best_c]

EAT-SSU 앱을 운영하면서 이상한 버그를 자주 만났다. 로컬에서는 아무 문제 없이 잘 돌아가는데, 배포하고 나면 간헐적으로 이상한 현상이 발생했다.

더 이상한 건, 에뮬레이터에서 기능 자체는 정상적으로 작동한다는 점이었다. 서버에는 데이터가 잘 저장되는데 사용자 화면에는 에러가 뜨거나, 갑자기 로그아웃되는 식이었다.

원인을 찾아보니 전부 Race Condition 때문이었다.

이 글에서는 실제로 겪었던 두 가지 사례와 해결 과정을 공유한다.

문제를 찾기 어려웠던 이유

두 문제 모두 비슷한 특징이 있었다.

• ✅ 기능 자체는 성공함
• ✅ 서버 에러도 아님
• ❌ 로컬 환경에서는 거의 재현 안 됨
• ❌ 실제 서비스 환경에서만 가끔 발생

결국 타이밍이 문제였고, 이건 동시성 문제라는 신호였다.

Race Condition이 뭔가?

여러 작업이 동시에 실행될 때, 실행 순서에 따라 결과가 달라지는 현상을 말한다.

쉽게 비유하자면:

두 명이 동시에 같은 은행 계좌에서 돈을 인출하려고 할 때,
누가 먼저 처리되느냐에 따라 잔액이 달라지는 상황

각 코드는 문제없는데, 동시에 실행되면 사고가 나는 것이다.

모바일 앱에서 자주 발생하는 이유

모바일 앱은 기본적으로 비동기 환경이다.

• 네트워크 요청은 여러 개가 동시에 날아가고
• Coroutine/Thread가 병렬로 실행되고
• UI 상태는 비동기 결과로 업데이트된다

이 과정에서 공유 자원이 생긴다:

• Access Token / Refresh Token
• UI 상태 (UiState)
• 로컬 저장소 (DataStore 등)

이 자원들에 동시 접근 + 순서 보장 없음이 겹치면 Race Condition이 발생한다.

Race Condition의 무서운 점

• 항상 발생하지 않는다 (간헐적)
• 로컬에서는 잘 안 보인다
• QA나 실제 사용자 환경에서만 가끔 나타난다
• 로그 없이는 원인 파악이 정말 어렵다

내가 겪은 두 문제도 정확히 이랬다.

사례 1: 토큰 재발급이 안되어서 하루마다 로그아웃되는 현상

문제 상황

EAT-SSU의 토큰 정책은 이렇다:

• Access Token: 1일
• Refresh Token: 7일

배포 후, 하루에 한 번씩 갑자기 로그아웃되는 현상이 간헐적으로 발생했다.

서버 문제도 아니고, 토큰 정책 오류도 아니었다. 추적해보니 토큰 재발급 로직의 동시성 문제였다.

어떻게 발생했나?

Access Token이 만료된 시점에 여러 API 요청이 동시에 날아가면:

1️⃣ 여러 요청이 동시에 401 응답을 받음
2️⃣ 각 요청이 같은 Refresh Token으로 재발급 요청
3️⃣ 첫 번째 요청이 Refresh Token을 사용해서 성공
4️⃣ 두 번째 요청은 이미 사용된 Refresh Token으로 시도
5️⃣ 서버에서 401 반환 → 강제 로그아웃

해결 방법

먼저 DEV 모드 환경의 토큰 만료 기간을 짧게 변경해달라고 요청한다.

Mutex로 동시성 제어

Refresh Token 재발급은 딱 한 번만 일어나야 한다

Mutex를 사용해서 해결했다:

• 첫 번째 401 요청만 재발급 수행
• 나머지 요청들은 Lock 대기
• 재발급 완료 후, 갱신된 토큰을 사용

구조 개선

동시성 해결과 함께 전체 인증 구조도 정리했다:

• TokenAuthenticator: 401 처리 전담
• TokenInterceptor: Authorization 헤더 주입만
• ReissueAndStoreTokenUseCase: 재발급 + 저장 로직 분리
• TokenEventBus: 로그아웃 이벤트 관리

로그아웃 시 원인도 명확히 알 수 있게 MISSING_REFRESH_TOKEN, REFRESH_TOKEN_EXPIRED 등을 로깅하도록 개선했다.

코드

     return runBlocking {
            mutex.withLock {
                val currentAccessToken = getAccessTokenUseCase()
                val requestAuthHeader = response.request.header("Authorization")

                // 이미 다른 요청이 토큰을 재발급/저장한 경우, 저장된 토큰으로만 재시도
                if (!requestAuthHeader.isNullOrBlank() && requestAuthHeader != "Bearer $currentAccessToken") {
                    Timber.d("TokenAuthenticator → token already refreshed by another call; retrying with stored token")
                    return@withLock response.request.newBuilder()
                        .header("Authorization", "Bearer $currentAccessToken")
                        .build()
                }

                Timber.d("TokenAuthenticator → attempting token reissue")
                when (val result = reissueAndStoreTokenUseCase()) {
                    is ReissueAndStoreResult.Success -> response.request.newBuilder()
                        .header("Authorization", "Bearer ${result.accessToken}")
                        .build()

                    is ReissueAndStoreResult.MissingRefreshToken -> {
                        Timber.e("TokenAuthenticator → refreshToken is blank; forcing logout")
                        logoutUseCase()
                        TokenEventBus.notifyTokenExpired(LogoutReason.MISSING_REFRESH_TOKEN)
                        null
                    }

                    is ReissueAndStoreResult.RefreshInvalid -> {
                        Timber.e(
                            "TokenAuthenticator → refresh invalid: code=${result.responseCode}, message=${result.message}"
                        )
                        logoutUseCase()
                        TokenEventBus.notifyTokenExpired(LogoutReason.REFRESH_TOKEN_EXPIRED)
                        null
                    }

                    is ReissueAndStoreResult.TransientFailure -> {
                        Timber.w(
                            result.throwable,
                            "TokenAuthenticator → transient reissue failure: code=${result.responseCode}, message=${result.message}"
                        )
                        null
                    }
                }
            }

결과

• ✅ 간헐적 로그아웃 완전 제거
• ✅ 재발급 네트워크 요청 수 N → 1
• ✅ 코드 가독성과 유지보수성 향상

해당 PR: https://github.com/EAT-SSU/Android/pull/453

사례 2: 사진을 포함한 리뷰 작성 뒤 API 통신이 실패했다는 다이알로그. 그러나 실제 요청은 성공함 0_0

문제 상황

QA에서 이런 제보가 들어왔다:

"리뷰 작성이 성공했는데 네트워크 오류 다이얼로그가 떠요"

실제로 서버에는 리뷰가 잘 저장되어 있었다. 하지만 사용자는 에러를 보게 되니 서비스 신뢰도가 떨어지는 상황이었다.

원인 분석

리뷰 작성 플로우는 이렇게 작동했다:

1. postReview API 호출
2. saveS3 이미지 업로드
3. 두 작업 모두 비동기로 처리

문제는 두 작업 모두에서 UiState.Success를 설정하고 있었다는 점이었다.

코드

@HiltViewModel
class UploadReviewViewModel @Inject constructor(
    private val writeReviewUseCase: WriteReviewUseCase,
    private val getImageUrlUseCase: GetImageUrlUseCase,
) : ViewModel() {

    private val _uiState = MutableStateFlow<UiState<Unit>>(UiState.Init)
    val uiState = _uiState.asStateFlow()

    private val _uiEvent: MutableSharedFlow<UiEvent> = MutableSharedFlow()
    val uiEvent = _uiEvent.asSharedFlow()

    fun postReview(menuId: Long, reviewData: WriteReviewRequest) {
        viewModelScope.launch {
            _uiState.value = UiState.Loading
            val success = writeReviewUseCase(menuId, reviewData)

            if (!success) {
                _uiState.value = UiState.Error
                _uiEvent.emit(UiEvent.ShowToast("리뷰 작성에 실패하였습니다."))
                return@launch
            }

            _uiState.value = UiState.Success(Unit)
            _uiEvent.emit(UiEvent.ShowToast("리뷰가 작성되었습니다."))
        }
    }

    suspend fun saveS3(file: File): String? {
        _uiState.value = UiState.Loading
        val url = getImageUrlUseCase(file)

        if (url == null) {
            _uiState.value = UiState.Error
            _uiEvent.emit(UiEvent.ShowToast("이미지 업로드에 실패하였습니다."))
            return null
        }

      //  _uiState.value = UiState.Success(Unit)  여기를 삭제했더니 race condition을 막을 수 있었다 
        return url
    }
}

문제 발생 시나리오:

1️⃣ postReview 성공 → UiState.Success 설정
2️⃣ Activity가 성공으로 인식 → finish() 호출
3️⃣ ViewModelScope 종료
4️⃣ 아직 끝나지 않은 saveS3가 IOException 발생
5️⃣ 네트워크 오류로 오인 → 에러 다이얼로그 표시

기능은 성공했지만, 상태 관리 경쟁 때문에 사용자 경험이 망가진 것이다.

해결 방법: UI 성공 상태 단일화

해결 전략은 명확했다:

• UiState.Success를 단 한 곳에서만 관리
• 모든 비동기 작업이 완료된 후에만 성공 처리
• finish() 호출 시점 보장

즉, UI 상태는 전체 작업 흐름을 대표해야 한다는 원칙을 적용했다.

결과

• ✅ 잘못된 네트워크 오류 다이얼로그 제거
• ✅ 리뷰 작성 UX 정상화
• ✅ ViewModel 상태 흐름 단순화

해당 PR: https://github.com/EAT-SSU/Android/pull/414

두 사례의 공통점

두 문제 모두 이런 공통점이 있었다:

• 기능 로직 자체는 정상
• "동시에 실행될 수 있다"는 가정을 못함
• 네트워크, 인증, UI 상태 어디서든 발생 가능

Race Condition은 특정 기술의 문제가 아니라 설계의 문제였다.

배운 점

이번 경험을 통해 확실히 배운 게 있다:

1. 실제 서비스에서는 동시성 문제가 반드시 발생한다

• 로컬에서 괜찮다고 안심하면 안 됨
• 특히 인증, 상태 관리, 네트워크 경계에서 자주 발생

2. 해결의 핵심은 구조

• 단일 책임: 하나의 일만 하도록
• 단일 진입점: 한 곳에서만 관리
• 명시적인 동기화: Mutex 같은 도구 활용

3. "운 좋게 잘 되는 코드"는 언젠가 문제를 만든다

이번 리팩토링은 단순한 버그 수정이 아니라, EAT-SSU 전체를 더 견고하게 만드는 계기가 되었다.

배포 전 QA가 꼭 필요하다는 사실을 다시 한번 상기하며 마무리한다 윤소양 고마워요~ QA해주는 최고의 PM

오늘은 Hilt, 그리고 DI에 대해 탐구해보려 한다!

의존성 생성 책임 분리와 개방–폐쇄 원칙(OCP)의 연결

안드로이드 개발을 하다 보면 DI(Dependency Injection)를 “편해서 쓰는 도구” 정도로 받아들이기 쉽다. 하지만 실제로 DI는 단순한 편의 기능이 아니라, 변경에 강한 구조를 만들기 위한 설계 기법이다.

이 글에서는

• DI가 말하는 “의존성 생성 책임 분리”가 무엇인지
• 이것이 어떻게 개방–폐쇄 원칙(OCP) 과 연결되는지 안드로이드 ViewModel–Repository 구조를 예로 들어 정리해본다.

DI 없이 생기는 문제

DI를 사용하지 않고 ViewModel에서 Repository를 직접 생성한다고 가정해보자.

class ReviewViewModel : ViewModel() {

    private val repository = ReviewRepository(
        apiService,
        localDataSource
    )
}

이 구조에는 몇 가지 문제가 있다.

1. 생성 책임이 ViewModel에 있다

ViewModel은 본래 상태 관리와 UI 로직에 집중해야 하지만, Repository를 어떻게 생성하는지까지 알고 있다.

2. 생성 로직이 중복된다

여러 ViewModel에서 같은 Repository를 사용한다면, 각 ViewModel마다 동일한 생성 코드가 반복된다.

3. 변경에 매우 취약하다

만약 ReviewRepository 생성자에 파라미터가 하나 추가된다면 어떻게 될까?

class ReviewRepository(
    apiService: ApiService,
    localDataSource: LocalDataSource,
    logger: Logger
)

이 경우,

• ReviewRepository를 생성하는 모든 ViewModel을 수정해야 한다
• 변경의 영향 범위가 ViewModel 전체로 퍼진다

이 구조는 변경에 닫혀 있지 않다.

DI의 핵심: 의존성 생성 책임 분리

DI를 적용하면 ViewModel은 더 이상 Repository를 생성하지 않는다.

@HiltViewModel
class ReviewViewModel @Inject constructor(
    private val repository: ReviewRepository
) : ViewModel()

Repository는 별도의 Module에서 생성된다.

@Module
@InstallIn(SingletonComponent::class)
object RepositoryModule {

    @Provides
    fun provideReviewRepository(
        apiService: ApiService,
        localDataSource: LocalDataSource
    ): ReviewRepository {
        return ReviewRepository(apiService, localDataSource)
    }
}

여기서 중요한 변화는 단 하나다.

ViewModel은 Repository를 “어떻게 만드는지”를 더 이상 모른다

변경의 영향을 한 곳으로 모은다

이제 ReviewRepository 생성자가 변경되더라도,

fun provideReviewRepository(
    apiService: ApiService,
    localDataSource: LocalDataSource,
    logger: Logger
): ReviewRepository

• 수정해야 할 곳은 Module 하나뿐이다
• ViewModel 코드는 전혀 수정하지 않는다

즉,

• 변경은 발생하지만
• 변경의 영향은 한 곳에만 집중된다

이 지점에서 개방–폐쇄 원칙(OCP) 과 연결된다.

개방–폐쇄 원칙(OCP)과의 연결

개방–폐쇄 원칙은 다음과 같이 정의된다.

확장에는 열려 있고, 변경에는 닫혀 있어야 한다

DI 구조에서 이를 다시 해석하면 다음과 같다.

• Repository의 생성 방식이나 구현은 확장 가능
• Repository를 사용하는 ViewModel은 변경되지 않음

구성(configuration)은 바뀔 수 있지만, 사용 코드는 닫혀 있다

DI는 의존성 생성 책임을 분리함으로써 변경이 필요한 지점과 변경되지 않아야 할 지점을 명확히 나눈다.

이것이 DI가 OCP를 자연스럽게 만족시키는 이유다.

싱글톤은 핵심이 아니다

DI의 장점을 설명할 때 흔히 “객체를 하나만 만들어서 재사용한다”는 이야기가 나온다. 하지만 이는 부가적인 효과일 뿐, 핵심은 아니다.

• 싱글톤은 객체의 생명주기 관리 전략이다
• DI는 의존성을 외부에서 주입하는 설계 방식이다

DI를 사용하면서 싱글톤을 선택할 수는 있지만, DI의 본질은 재사용이 아니라 변경 관리에 있다.

정리

DI가 유지보수성을 높이는 이유는 단순하다.

• 의존성 생성 책임을 분리하고
• 변경의 영향을 한 곳으로 모으며
• 사용하는 코드를 변경 없이 확장할 수 있게 만들기 때문이다

이 구조는 자연스럽게 개방–폐쇄 원칙을 만족시킨다.

DI는 객체를 주입하는 기술이 아니라, 변경에 강한 구조를 만드는 설계 도구다.

사실 앞선 글과 이번 글은 안드로이드 프로그래밍 Next Step 3장을 읽다가 정리한 내용을 바탕으로 작성하였다. 앞선 글이 추가적으로 조사한 내용을 바탕으로 작성한 글이고 이 글이 3장의 내용을 정리한 것이다.

3장에서는 백그라운드 스레드를 주제로 다음 두 방식을 소개한다.

• HandlerThread
• AsyncTask

둘 다 “백그라운드 작업을 안전하게 처리하기 위한 시도”라는 공통점을 가진다.

HandlerThread: Looper가 붙은 백그라운드 스레드

HandlerThread는 이름 그대로 Thread를 상속받은 클래스다. 차이점은 단 하나, Looper가 자동으로 붙어 있다는 것이다.

앞에서 봤듯이,

• UI 스레드는 기본적으로 Looper가 있다
• 일반 Thread는 Looper가 없다

그래서 일반 Thread 안에서 Handler() 기본 생성자를 쓰면 문제가 생긴다. Handler는 반드시 Looper가 있는 스레드에 붙어야 하기 때문이다.

이 문제를 해결하기 위해 등장한 것이 HandlerThread다.

왜 HandlerThread가 필요했을까

일반 Thread의 특징은 단순하다.

• 시작하면 실행
• 작업이 끝나면 종료

하지만 이런 요구가 생긴다.

• 백그라운드에서
• 계속 살아 있으면서
• 요청이 들어올 때마다
• 순차적으로 처리하고 싶다

이건 사실상 UI 스레드와 동일한 구조다. 단지 UI가 없을 뿐이다.

그래서 안드로이드는

• Looper
• MessageQueue

를 가진 백그라운드 전용 스레드를 제공했고, 그게 HandlerThread다.

HandlerThread의 핵심 포인트

• 내부에 Looper가 있음
• MessageQueue 기반
• 작업을 순서대로 처리
• 직접 스레드 관리 필요

여기서 중요한 문장이 하나 있다.

스레드는 기본적으로 실행 순서를 보장하지 않는다.

즐겨찾기 버튼을 마구 클릭하면 생기는 문제

예를 들어 즐겨찾기 버튼을 빠르게 클릭한다고 해보자.

• 클릭할 때마다 Thread 생성
• 네트워크 요청 시작
• 완료 시점은 제각각

이 상태에서 스레드들이 서로 순서를 보장하지 않으면,

• 마지막 클릭이 먼저 끝날 수도 있고
• 이전 클릭이 나중에 반영될 수도 있다

이게 바로 레이스 컨디션이다.

그래서 필요한 게 큐(queue)다.

• 요청은 순서대로 쌓고
• 하나씩 처리

HandlerThread는 이 구조를 자연스럽게 제공한다.

HandlerThread의 한계

하지만 HandlerThread는 여전히 단점이 많다.

• Looper.loop()는 무한 루프라 직접 종료해야 함
• Looper.quit()는 다른 스레드에서 호출해야 함
• 생명주기 관리가 번거로움
• 실수하면 메모리 릭으로 직행

그래서 다음 단계로 등장한 것이 AsyncTask다.

AsyncTask: 안드로이드가 제공한 간편한 비동기 도구

AsyncTask는 Thread보다 안드로이드 개발자에게 친숙했다.

이유는 간단하다.

• 안드로이드 API
• 사용법이 쉬움
• UI 스레드와의 연결이 자동

즉, “스레드 + Handler + UI 전환”을 한 번에 감싸준 도구였다.

하지만 AsyncTask의 치명적인 문제

가장 큰 문제는 액티비티 생명주기를 따라가지 않는다는 점이다.

• Activity는 종료됨
• AsyncTask는 계속 실행 중
• Activity를 참조하고 있다면?
• → 메모리 누수

이 문제를 막기 위해 isCancelled()를 체크하고 onDestroy()에서 cancel을 호출하는 방식이 등장했지만,

이건 개발자에게 책임을 떠넘긴 설계에 가깝다.

AsyncTask의 또 다른 문제: 예외 처리

AsyncTask에서 예외 처리는 까다롭다.

• try-catch 범위가 불분명
• 에러 전달 구조가 명확하지 않음

이 문제를 해결하기 위해 RxJava가 주목받기 시작했다.

RxJava는

• onNext
• onError
• onComplete

처럼 에러를 구조적으로 다룰 수 있었기 때문이다.

AsyncTask의 문제 2: 실행 순서 보장 불가

AsyncTask는 병렬 실행이 가능하다. 하지만 병렬 실행은 항상 위험을 동반한다.

예를 들어,

• 개요 API
• 상세 API

이 두 개가 순서대로 실행되어야 한다면?

병렬 실행에서는

• 어떤 요청이 먼저 끝날지 보장할 수 없다
• 순서를 가정하는 순간 버그가 된다

이건 운의 영역이다.

그래서 이런 경우에는 차라리

• 병렬이 아니라
• 순차 실행이 더 안전하다

실행 순서를 조정하기 위해 CountDownLatch 같은 동기화 도구가 등장했지만, 코드는 점점 복잡해졌다.

그래서 결론은 Coroutine이다

여기까지의 흐름을 정리하면 명확하다.

• Thread: 너무 저수준
• HandlerThread: 관리가 어려움
• AsyncTask: 생명주기와 어긋남
• RxJava: 강력하지만 학습 비용 큼

그래서 안드로이드는 결국 Coroutine을 표준으로 선택했다.

Coroutine은

• Handler + Looper 위에서 동작하지만
• 생명주기와 자연스럽게 결합되고
• 순차 코드처럼 읽히며
• 취소와 예외 처리가 명확하다

viewModelScope.launch {
    val overview = loadOverview()
    val detail = loadDetail(overview.id)
    updateUi(detail)
}

이 코드는

• 순서를 보장하고
• UI 스레드를 안전하게 사용하며
• Activity 종료 시 자동으로 취소된다

마무리하며

HandlerThread와 AsyncTask는 안드로이드가 비동기 문제를 해결하기 위해 지나온 과정이다.

지금 우리가 Coroutine을 쓰는 이유는 단순히 “새로워서”가 아니다.

• 스레드 관리
• 생명주기
• 순서 보장
• 예외 처리

이 모든 문제를 현실적으로 가장 잘 해결한 도구이기 때문이다.

https://developer.android.com/guide/components/processes-and-threads

안드로이드 개발을 하다 보면 자연스럽게 이런 질문을 만나게 된다.

• 왜 UI 스레드를 막으면 안 될까?
• Handler와 Looper는 정확히 뭘 하는 걸까?
• Coroutine은 왜 더 안전하고 편한 방식일까?

이 글에서는 운영체제 관점과 안드로이드 내부 구조를 함께 엮어, 안드로이드의 실행 모델을 처음부터 끝까지 정리해본다.

1. 프로세스(Process): 앱의 실행 단위

운영체제에서 프로세스는 실행 중인 프로그램의 인스턴스다. 각 프로세스는 독립된 메모리 공간을 가지며, 다른 프로세스와 메모리를 직접 공유하지 않는다.

안드로이드에서도 동일하다.

• 앱이 실행되면 리눅스 프로세스 1개가 생성된다.
• 기본적으로 Activity, Service, BroadcastReceiver, ContentProvider는 모두 같은 프로세스에서 실행된다.

즉, 일반적인 안드로이드 앱은 “앱 하나 = 프로세스 하나” 구조를 가진다.

필요하다면 android:process 속성을 통해 컴포넌트를 분리할 수 있지만, 대부분의 앱에서는 사용하지 않는다.

2. 안드로이드 프로세스는 언제 종료될까

안드로이드는 메모리가 부족해지면 프로세스를 종료한다. 이때 기준은 “사용자에게 얼마나 중요한가”다.

• 화면에 보이는 Activity를 가진 프로세스는 우선순위가 높다.
• 백그라운드에만 있는 프로세스는 언제든 종료될 수 있다.

그래서 안드로이드 앱은 항상 프로세스가 죽고 다시 살아나는 상황을 전제로 설계해야 한다.

3. 스레드(Thread): 실행 흐름의 단위

프로세스 안에는 하나 이상의 스레드가 존재한다.

• 스레드는 프로세스의 메모리를 공유한다.
• 대신 동시성 문제(레이스 컨디션)가 발생할 수 있다.

안드로이드 앱이 시작되면 가장 먼저 생성되는 스레드가 있다.

4. 메인 스레드(UI 스레드)의 역할

안드로이드는 앱 시작 시 메인 스레드(Main Thread)를 하나 생성한다. 이 스레드는 흔히 UI 스레드라고도 불린다.

UI 스레드의 역할은 다음과 같다.

• 터치, 키 입력 같은 사용자 이벤트 처리
• 화면 그리기
• Activity / Fragment 생명주기 콜백 실행

즉, UI 스레드는 앱의 화면과 상호작용을 전담하는 핵심 스레드다.

5. 왜 UI 스레드를 막으면 안 되는가

UI 스레드는 이벤트를 하나씩 처리한다.

1. 버튼 클릭 이벤트 처리
2. 화면 상태 변경
3. 다시 그리기 요청 처리

이 과정 중 UI 스레드에서 오래 걸리는 작업을 수행하면 어떻게 될까?

• 이벤트가 처리되지 않는다.
• 화면이 갱신되지 않는다.
• 사용자는 앱이 멈췄다고 느낀다.

5초 이상 UI 스레드가 응답하지 않으면 안드로이드는 ANR(Application Not Responding)을 발생시킨다.

그래서 안드로이드에는 명확한 규칙이 있다.

1. UI 스레드를 블로킹하지 말 것
2. UI 변경은 반드시 UI 스레드에서만 할 것

6. 이벤트 루프와 Looper

여기서 자연스럽게 질문이 생긴다.

UI 스레드는 어떻게 앱이 종료될 때까지 계속 살아 있을까?

그 답이 이벤트 루프(Event Loop)다.

UI 스레드는 내부적으로 다음과 같은 구조를 가진다.

메시지가 올 때까지 대기
→ 메시지 하나 꺼내서 실행
→ 다시 대기

이 무한 루프를 담당하는 객체가 Looper다.

• Looper는 스레드에 하나만 존재한다.
• UI 스레드는 기본적으로 Looper를 가지고 있다.
• 일반 스레드는 Looper가 없다.

7. MessageQueue와 Handler

Looper 옆에는 항상 MessageQueue가 있다.

• MessageQueue에는 실행할 작업(Runnable, Message)이 쌓인다.
• Looper는 이 큐를 계속 감시하며 하나씩 실행한다.

그렇다면 누가 큐에 작업을 넣을까?

그 역할을 하는 것이 Handler다.

Handler는 특정 Looper(즉, 특정 스레드)에 연결되어 그 스레드의 MessageQueue에 작업을 전달한다.

Handler(Looper.getMainLooper()).post {
    textView.text = "hello"
}

이 코드는 “UI 스레드에서 이 코드를 실행해달라”는 요청이다.

8. 백그라운드 스레드와 UI 스레드 통신

네트워크, DB, 파일 IO 같은 작업은 반드시 UI 스레드가 아닌 백그라운드 스레드에서 수행해야 한다.

하지만 UI 업데이트는 UI 스레드에서만 가능하다.

그래서 일반적인 흐름은 다음과 같다.

1. 백그라운드 스레드에서 작업 수행
2. Handler를 통해 UI 스레드에 결과 전달
3. UI 스레드 Looper가 이를 실행

이 구조 덕분에 UI 스레드는 안전하게 유지된다.

9. HandlerThread: Looper를 가진 백그라운드 스레드

일반 Thread는 작업이 끝나면 종료된다. 하지만 계속 살아 있으면서 요청을 처리해야 하는 스레드도 필요하다.

이를 위해 제공되는 것이 HandlerThread다.

• Thread + Looper를 합친 구조
• 순차 처리 보장
• 시스템 컴포넌트나 레거시 코드에서 자주 사용

다만 코드 복잡도가 높고 생명주기 관리가 어렵다.

10. Coroutine: 더 높은 수준의 추상화

Coroutine은 Thread를 직접 다루지 않는다. 이미 존재하는 스레드 위에서 실행 흐름만 관리한다.

핵심은 Dispatcher다.

• Dispatchers.Main → UI 스레드
• Dispatchers.IO → IO 작업용 스레드 풀

withContext(Dispatchers.Main) {
    textView.text = "hello"
}

은 내부적으로 다음과 같다.

Handler(Looper.getMainLooper()).post {
    textView.text = "hello"
}

이처럼, Coroutine은 Handler + Looper 구조 위에서 동작하지만, 개발자는 이를 직접 신경 쓰지 않아도 된다.

11. 왜 Dispatchers.Main은 안전한가

Dispatchers.Main은 내부적으로

• UI 스레드의 Looper
• UI 스레드의 MessageQueue

에 작업을 등록한다.

즉, Handler를 직접 쓰는 것과 본질적으로 동일하지만 더 안전하고 가독성이 좋으며 취소와 생명주기 관리가 가능하다.

12. 정리

안드로이드의 실행 구조를 한 줄로 요약하면 다음과 같다.

• 프로세스는 앱의 실행 단위다.
• 스레드는 실행 흐름의 단위다.
• UI 스레드는 이벤트와 화면을 담당한다.
• Looper는 스레드의 이벤트 루프다.
• Handler는 특정 스레드에 작업을 전달하는 도구다.
• Coroutine은 이 모든 구조 위에 얹힌 고수준 추상화다.

이 흐름을 이해하면 왜 안드로이드가 이런 구조를 가지는지, 왜 Coroutine이 표준이 되었는지도 자연스럽게 이해할 수 있다.

공식 문서를 그대로 따라가면 금방 끝날 것 같았지만, 실제로는 디스크 용량, 메모리, 보안그룹, VPC 라우팅까지 연쇄적으로 문제가 발생했다.

이 글에서는

1. EC2 + RDS 환경에서 Redash를 처음부터 끝까지 구축하는 과정
2. 실제로 겪었던 트러블슈팅과 그로부터 얻은 교훈

을 정리한다.

1. Redash를 EC2에 직접 올린 이유

Redash는 데이터 분석과 대시보드를 위한 오픈소스 도구다. 팀에서는 다음 이유로 EC2 직접 설치 방식을 선택했다.

• 비용 통제 (사용량이 크지 않음)
• Docker 기반으로 비교적 단순한 설치
• 인프라 구조를 직접 이해하고 운영해보기 위함

다만, “생각보다 쉽다”는 기대와 달리 실제 구축 과정에서는 꽤 많은 인프라 요소를 고려해야 했다.

2. 아키텍처 개요

구성은 단순하다.

• EC2: Redash 서버 (Docker 컨테이너)
• RDS: 서비스 운영 DB (MySQL 또는 PostgreSQL)
• EC2와 RDS는 같은 VPC에 배치
• 보안그룹은 SG → SG 방식으로 연결

트래픽 흐름

• 브라우저 → EC2 퍼블릭 IP:80 → Nginx → Redash Server(5000)
• Redash Server → RDS:3306 (또는 5432)

3. EC2 인스턴스 준비

3-1. 인스턴스 타입

Redash는 생각보다 리소스를 많이 사용한다.

• 최소 권장: t3.small (2vCPU, 2GB RAM)
• 안정적: t3.medium (2vCPU, 4GB RAM)

t2.micro(1GB)로도 시도해봤지만, 메모리·디스크 모두 부족해 설치 단계에서 실패했다.

3-2. 디스크 용량

Root EBS 볼륨은 최소 20GB, 가능하면 30GB 이상을 권장한다.

• Docker 이미지 레이어
• Postgres, Redis 데이터
• Python 패키지 설치 과정에서의 임시 공간

8GB 환경에서는 설치 중 no space left on device 오류가 거의 확정적으로 발생한다.

3-3. 네트워크

• EC2는 퍼블릭 서브넷에 생성
• Route Table에 0.0.0.0/0 → Internet Gateway 라우트 존재 확인
• 퍼블릭 IPv4 또는 Elastic IP 할당 필수

4. 보안그룹 설정

Redash용 EC2 보안그룹 예시 (redash-group)

Inbound

• 22/TCP → 내 IP (SSH)
• 80/TCP → 내 IP 또는 0.0.0.0/0 (웹 UI)
• 5000/TCP → 내 IP (디버깅용, 선택)

Outbound

• All traffic → 0.0.0.0/0

중요한 점은 DB 포트(3306/5432)는 EC2 인바운드에 열 필요가 없다는 것이다. DB 포트는 RDS 보안그룹에서 제어해야 한다.

5. 스왑 메모리 설정

메모리가 2GB 이하라면 스왑을 설정해 두는 것이 안전하다.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

6. Docker 설치

sudo apt update
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable docker
sudo systemctl start docker

7. Redash 설치

공식 setup 스크립트를 그대로 사용했다.

git clone https://github.com/getredash/setup.git
cd setup
sudo ./setup.sh

설치 후 다음 컨테이너들이 떠 있어야 한다.

• redash-server
• redash-worker
• redash-scheduler
• redash-nginx
• redash-postgres
• redash-redis

EC2 내부 테스트:

curl http://localhost
curl http://localhost:5000

8. 브라우저 접속

• http://<EC2 퍼블릭 IP> (Nginx 경유)
• 또는 http://<EC2 퍼블릭 IP>:5000

관리자 계정 생성 화면이 나오면 정상이다.

9. RDS 보안그룹 설정

핵심은 IP가 아니라 보안그룹을 Source로 지정하는 것이다.

RDS 보안그룹 Inbound:

• 3306 (또는 5432)
• Source: redash-group

이렇게 하면 Redash EC2만 DB에 접근할 수 있다.

10. 트러블슈팅 회고

1) 디스크 부족 (no space left on device)

t2.micro + 8GB 환경에서 Docker 이미지 레이어 추출 중 실패.

원인

• Docker + DB + 라이브러리 합쳐 8GB 초과

해결

• EBS 30GB 확장
• 파일시스템 확장 후 재설치

교훈

• 디스크는 넉넉하게 잡는 게 결국 더 싸다

2) 컨테이너는 떠 있는데 접속이 안 됨

• docker ps 정상
• 브라우저 접속 불가

점검 순서

1. EC2 내부 curl localhost
2. 보안그룹 포트
3. 서브넷 Route Table
4. 퍼블릭 IP 여부

교훈

• 애플리케이션 문제인지, 네트워크 문제인지 계층별로 분리해서 봐야 한다

3) DB 포트를 EC2 SG에 열어둔 실수

• DB 연결 안 된다고 EC2 SG에 3306 개방

문제

• DB는 EC2가 아니라 RDS가 “받는 쪽”

정답

• RDS SG Inbound에 3306 → Source: redash-group

교훈

• 보안그룹은 “누가 누구에게 접근하는가”를 기준으로 봐야 한다

11. 마무리

Redash를 EC2 위에 직접 올리는 작업은 단순 설치를 넘어 인프라 전반을 이해해야 가능한 작업이었다.

이번 경험으로 정리된 핵심은 다음이다.

• 리소스는 넉넉하게 잡는 것이 결국 효율적이다
• 보안그룹은 SG → SG 구조로 설계한다
• 문제 발생 시 컨테이너 → EC2 내부 → 보안그룹 → VPC/라우팅 순서로 점검한다

이 과정을 한 번 겪고 나니, 이후 다른 사내 도구(Grafana, Metabase 등)를 올릴 때도 훨씬 수월해졌다

• Presentation: Android UI 모듈
• Domain: 순수 Kotlin 모듈
• Data: Android UI 모듈일 수도 있고 순수 Kotlin 모듈일 수도 있다.

Domain 모듈이 순수 Kotlin 모듈인 것은 다들 아는 사실일 것이다.

그런데, Data 모듈은 둘 다 될 수도 있다고 한다. 여기에 추가로 알 수 있는 사항은 Android 의존성 없이 JVM 기반으로 유지하면 테스트 환경이 가벼워지고, 순수한 비즈니스 로직만 다루도록 설계할 수 있다는 점이다.

나 역시 초기에는 Ktor를 사용해 네트워크 통신을 구현했기 때문에 Data 모듈을 Kotlin JVM 모듈로 구성했다. Ktor는 멀티플랫폼을 지원하고 Android 종속성이 없는 client-core, client-cio 엔진만 사용하면 JVM 환경에서도 문제 없이 동작한다.

그러나 Paging3를 도입하면서 상황이 달라졌다.

Paging3 도입 이전: Data 모듈은 순수 Kotlin JVM 모듈이어도 충분하다

Ktor 기반으로 Repository를 구성하던 시점에는 다음과 같은 구조가 가능했다.

• API 통신: Ktor client-core, cio 엔진 사용
• DTO 변환: Kotlin Serialization
• Repository, Datasource: Kotlin JVM 환경에서 모두 가능
• Domain으로 전달: Result, Model, Flow 등

이 경우 Data 모듈에는 Android 종속성이 전혀 없기 때문에 kotlin("jvm") 모듈로 구현해도 문제가 없다.

Paging3 도입 이후: Data 모듈은 Android 모듈이 될 수밖에 없다

하지만 무한 스크롤 기능을 위해 Paging3를 도입하면서 제약이 생긴다.

Paging3는 다음과 같이 세 개의 모듈로 나뉜다.

• paging-common (Android 의존성 없음)
• paging-runtime (Android 의존성 있음)
• paging-compose (UI 전용)

여기서 핵심은 Pager 클래스가 paging-runtime에 포함되어 있다는 점이다. Repository에서 Pager를 사용해 PagingData 스트림을 생성해야 하는데, 이 시점에서 Android 의존성이 필요해진다.

예시:

fun getCharacters(): Flow<PagingData<Character>> {
    return Pager(
        config = PagingConfig(pageSize = 20),
        pagingSourceFactory = { CharacterPagingSource(api) }
    ).flow
}

Pager는 내부적으로 AndroidX 라이브러리와 연동되어 있고, paging-runtime 또한 AAR(Android Archive) 형태로 배포된다. 따라서 다음과 같은 문제가 발생한다.

• JVM 모듈은 AAR 의존성을 받을 수 없다.
• pager-runtime 자체가 Android 모듈 전용이다.
• Kotlin JVM 모듈에서 Pager를 import할 수 없다.

즉, Repository에서 Pager를 생성하는 순간 Data 모듈은 반드시 Android 모듈이어야 한다.

왜 Pager를 Presentation이 아닌 Data 계층에서 생성해야 하는가

일부 개발자는 Pager 생성을 Presentation 계층에서 수행하여 Data 모듈을 순수 Kotlin 모듈로 유지할 수 있다고 생각할 수 있다. 그러나 이는 클린 아키텍처 관점에서 좋지 않은 설계다.

Pager는 다음 역할을 수행한다.

• 페이지네이션 로직 정의
• PagingSource 생성
• 네트워크 로드 관리

이 로직은 "UI 로직"이 아니라 "데이터 로딩 전략"에 속한다. 즉, Repository가 책임져야 하는 부분이다. Presentation 계층으로 Pager 로직을 밀어 넣으면 UI와 데이터 로직이 결합되어 아키텍처가 무너진다.

따라서 다음이 가장 자연스러운 구조다.

• Data: Pager 생성, PagingSource 제공
• Domain: PagingData 그대로 전달
• Presentation: collect, Paging Compose 사용

이 구조를 유지하려면 Data 모듈은 Android Library 모듈이어야 한다.

Data 모듈을 Android Library로 변경한 후의 장점

1. Repository가 Paging3를 자연스럽게 책임질 수 있다.
2. PagingSource, Pager, RemoteMediator 등을 모두 Data 계층에서 관리할 수 있다.
3. Presentation은 paging-compose만 사용하고 로직은 완전히 분리된다.
4. Domain은 paging-common에 포함된 PagingData, PagingSource를 문제 없이 사용할 수 있다.

즉, Paging3를 올바르게 사용하기 위해서는 Data 모듈이 Android 모듈로 변경되는 것이 불가피하며, 오히려 아키텍처 관점에서도 더 자연스러운 선택이다.

정리

• Ktor만 사용할 때는 Data 모듈을 JVM 기반으로 설계할 수 있었다.
• Paging3를 도입하면 Repository에서 Pager를 생성해야 한다.
• Pager는 Android 종속성을 가진 paging-runtime에 포함되어 있다.
• 따라서 Data 모듈은 Android Library 모듈로 전환되어야 한다.
• 이는 클린 아키텍처의 책임 분리를 지키는 측면에서도 더 적합하다.

이 변화는 단순히 모듈 타입을 변경하는 것 이상의 의미가 있다. Android 환경에서 멀티 모듈 아키텍처를 사용한다면, 기술 스택에 따라 모듈의 성격이 달라질 수 있고 개발자는 그 이유와 구조적 적합성을 이해해야 한다.

클린 아키텍처를 더 철저하게 지키기 위해 멀티 모듈 기반의 Android 프로젝트 구성을 선호한다. Data / Domain / Presentation으로 모듈을 분리하면, 각 모듈에서 사용할 수 있는 의존성이 제한되기 때문에 단일 모듈보다 아키텍처 규칙을 강하게 유지할 수 있다.

하지만 Paging3 라이브러리로 무한 스크롤을 구현하면서 다음과 같은 의문이 생겼다.

_paging 라이브러리는 androidx로 시작하는데, 그렇다면 Data, Domain처럼 JVM 기반 모듈에서는 사용할 수 없는 것이 아닌가? _

실제로 멀티 모듈 구조에서 다음과 같은 클린 아키텍쳐 의존성 방향을 사용한다면,

Presentation(안드로이드 모듈) → Data(안드로이드 or JVM 모듈) ← Domain(JVM 모듈)

Android 의존성을 포함한 라이브러리는 JVM 모듈에서 사용이 제한된다.

Paging3 분석

Paging3는 이러한 문제를 해결하기 위해 기능별로 분리된 세 가지 모듈을 제공한다.

• androidx.paging:paging-common
• androidx.paging:paging-runtime
• androidx.paging:paging-compose

아래는 각 모듈의 역할과 클린 아키텍처에서의 적용 방법이다.

1. androidx.paging:paging-common (Android 의존성 없음)

implementation "androidx.paging:paging-common:3.x.x"

• Android 종속성이 없는 멀티플랫폼용 모듈
• Domain 계층에서도 안전하게 사용할 수 있음
• UseCase에서 PagingData를 그대로 다룰 수 있음

주요 포함 클래스

• PagingData
• PagingSource
• PagingConfig
• LoadResult
• RemoteMediator

2. androidx.paging:paging-runtime (Android 의존성 포함)

implementation "androidx.paging:paging-runtime:3.x.x"

• Android 의존성을 포함하여 Data, Presentation 계층에서만 사용 가능
• Repository에서 Pager 인스턴스를 생성할 때 사용함
• PagingDataAdapter도 여기에 포함됨

주요 포함 클래스

• Pager
• PagingDataAdapter
• PagingSourceFactory
• cachedIn(viewModelScope)

3. androidx.paging:paging-compose (Jetpack Compose UI 관련)

implementation "androidx.paging:paging-compose:3.x.x"

• Compose UI에서 Paging을 사용할 때 필요한 모듈
• Presentation(UI) 계층에서만 사용해야 함

주요 포함 클래스

• LazyPagingItems
• collectAsLazyPagingItems()
• Paging 관련 Compose DSL

클린 아키텍처에서 Paging 3을 적용하는 방법

1. Repository에서 PagingData 제공 (Data Layer)

class MyRepository(private val apiService: MyApiService) {
    fun getPagedData(): Flow<PagingData<MyData>> {
        return Pager(
            config = PagingConfig(pageSize = 20),
            pagingSourceFactory = { MyPagingSource(apiService) }
        ).flow
    }
}

• Pager는 Android 의존성이 있으므로 Repository에서 생성해야 한다.
• Repository는 Flow 형태로 Presentation과 Domain에 데이터를 제공한다.

2. UseCase에서 PagingData를 그대로 전달 (Domain Layer)

class GetPagedDataUseCase(private val repository: MyRepository) {
    operator fun invoke(): Flow<PagingData<MyData>> {
        return repository.getPagedData()
    }
}

• UseCase에서는 PagingData를 변환하지 않고 그대로 전달할 수 있다.
• PagingData와 PagingSource는 Android 의존성이 없어 Domain 계층에서 사용 가능하다.

3. ViewModel에서 PagingData 소비 (Presentation Layer)

@HiltViewModel
class MyViewModel @Inject constructor(
    private val getPagedDataUseCase: GetPagedDataUseCase
) : ViewModel() {
    val pagingData: Flow<PagingData<MyData>> = getPagedDataUseCase()
        .cachedIn(viewModelScope)
}

• cachedIn(viewModelScope)는 Android 의존성이 있으므로 ViewModel에서 처리해야 한다.

정리

• PagingData, PagingSource, PagingConfig는 Android 의존성이 없기 때문에 Domain 계층에서도 사용할 수 있다.
• Pager, PagingDataAdapter, cachedIn() 등 Android 의존성이 있는 기능은 Repository 또는 Presentation 계층에서만 사용해야 한다.
• UseCase는 PagingData를 그대로 유지한 채 전달하는 구성이 가장 깔끔하다.

새길 프로젝트에서 AI 대화 연습 기능을 구현하면서, 기존 REST + TTS 방식 대신 OpenAI Realtime API(WebSocket)를 붙여 대화 사용자 발화 이후 AI의 응답 지연 속도를 11초대 → 3초 수준으로 줄였다. 이 글에서는 그 과정에서 사용한 구조와 안드로이드 코드 구성을 정리한다.

0. 이런 기능을 만들고 싶었다

AI 전화처럼 가상 대화하는 기능을 만들려고 한다.

1. 왜 Realtime API인가

처음에는 다음과 같은 구조였다.

1. 사용자가 말하기 종료
2. m4a 파일을 서버로 업로드 (Multipart)
3. 서버에서 STT + LLM 호출 → 텍스트 응답 생성
4. 응답 텍스트를 다시 TTS로 변환해 m4a 반환
5. 클라이언트에서 재생

이 과정에서

1. LLM 응답 생성 ≒ 8초
2. TTS 파일 생성 및 전송 ≒ 2초 정도 걸리면서, 한 턴의 대화가 10초 이상 딜레이가 발생했다. 대화 연습용 “전화” 인터랙션으로 쓰기엔 너무 느린 속도였다.

기존에도 OpenAI의 Assistants API을 활용해서 기능을 구현했었는데, OPEN AI에서 WebSocket으로 실시간 소통을 할 수 있는 API가 새로 나왔다고 해서 당장 써봤다

OpenAI Realtime API는 WebSocket을 통해 음성·텍스트를 저지연으로 주고받는 인터페이스를 제공한다. 이걸 이용하면 음성 종료 후 서버 응답까지의 체감 딜레이를 3초 정도까지 줄일 수 있다.

2. 전체 구조 개요

이번 구현은 “모바일에서 직접 OpenAI에 WebSocket으로 붙되, 인증은 백엔드에서 처리”하는 구조다.

1. 백엔드

   • OpenAI Realtime Session 생성 REST API 호출
   • 응답으로 내려오는 client_secret.value(ephemeral key)를 모바일에 내려줌 (OpenAI Platform)

2. 안드로이드

   • GET /realtime/token 같은 엔드포인트로 client_secret 요청
   • 이 토큰을 Authorization 헤더에 넣고 wss://api.openai.com/v1/realtime?...로 WebSocket 연결
   • 마이크 입력을 WebSocket으로 보내고, 서버에서 오는 오디오를 받아 재생

레이어 별로 보면 Saegil-Android PR 구조랑 비슷하게 나뉜다.

• data: RealTimeService, RealTimeServiceImpl, RealTimeRepositoryImpl
• domain: RealTimeRepository, StartRealtimeChatUseCase, EndRealtimeChatUseCase, GetRealTimeTokenUsecase
• presentation: AiConversationViewModel, AiConversationScreen 등

3. 백엔드에서 client_secret 발급받기

Realtime API는 바로 API 키를 클라이언트에 노출하지 않고, 짧은 수명의 “client_secret(=ephemeral key)”를 발급해 사용하는 방식을 권장한다. (OpenAI Platform)

백엔드에서는 대략 다음 흐름으로 동작한다.

1. 서버에서 OpenAI Realtime Session API 호출

POST https://api.openai.com/v1/realtime/sessions
Authorization: Bearer {SERVER_SIDE_OPENAI_API_KEY}
Content-Type: application/json

{
  "model": "gpt-4o-realtime-preview-2024-12-17",
  "voice": "alloy"
}

2. 응답에서 client_secret.value를 꺼냄

{
  "id": "session_...",
  "client_secret": {
    "value": "ek_1234567890...",
    "expires_at": 1738015688
  }
}

3. 이 value를 모바일에 내려주는 간단한 API 구현

// 예시 응답
{
  "clientSecret": "ek_1234567890..."
}

Saegil PR에서는 이 응답을 GetRealTimeApiTokenResponse 같은 DTO로 파싱하고, AssistantServiceImpl / RealTimeRepositoryImpl에서 사용하도록 분리해뒀다.

4. 안드로이드: 토큰 가져오기(REST)

안드로이드 쪽에서는 먼저 Retrofit으로 토큰을 받아오는 부분을 만든다. (패키지 구조는 data/domain/presentation 그대로 유지)

// data/remote/AssistantService.kt
interface AssistantService {
    @GET("/realtime/token")
    suspend fun getRealTimeToken(): GetRealTimeApiTokenResponse
}

// data/model/GetRealTimeApiTokenResponse.kt
data class GetRealTimeApiTokenResponse(
    @SerializedName("clientSecret")
    val clientSecret: String
)

// data/repository/RealTimeRepositoryImpl.kt
class RealTimeRepositoryImpl(
    private val assistantService: AssistantService,
    private val realTimeService: RealTimeService
) : RealTimeRepository {

    override suspend fun startRealtimeChat(): Result<Unit> {
        return runCatching {
            val tokenResponse = assistantService.getRealTimeToken()
            realTimeService.connect(tokenResponse.clientSecret)
        }
    }

    override suspend fun endRealtimeChat(): Result<Unit> {
        return runCatching {
            realTimeService.disconnect()
        }
    }
}

domain 레이어에서는 StartRealtimeChatUseCase, EndRealtimeChatUseCase, GetRealTimeTokenUsecase 등으로 감싸 ViewModel에서 호출하기 쉽게 정리한다.

5. 안드로이드: WebSocket 연결하기

OpenAI Realtime WebSocket 엔드포인트는 대략 다음과 같은 형태다. (OpenAI Platform)

wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview-2024-12-17

여기에 아까 받은 client_secret를 Authorization 헤더에 실어 연결한다.

5-1. OkHttp WebSocket 예시

Saegil-Android에서는 Ktor/멀티모듈을 쓰고 있지만, 블로그에서는 OkHttp 기반 예시로 정리해보자.

class RealTimeServiceImpl(
    private val okHttpClient: OkHttpClient
) : RealTimeService {

    private var webSocket: WebSocket? = null

    override fun connect(clientSecret: String) {
        val request = Request.Builder()
            .url("wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview-2024-12-17")
            .addHeader("Authorization", "Bearer $clientSecret")
            .build()

        webSocket = okHttpClient.newWebSocket(request, object : WebSocketListener() {

            override fun onOpen(webSocket: WebSocket, response: Response) {
                // 연결 성공
            }

            override fun onMessage(webSocket: WebSocket, text: String) {
                // JSON 이벤트 처리 (텍스트 응답 등)
            }

            override fun onMessage(webSocket: WebSocket, bytes: ByteString) {
                // 바이너리 프레임 처리 (오디오 응답 등)
            }

            override fun onFailure(
                webSocket: WebSocket,
                t: Throwable,
                response: Response?
            ) {
                // 에러 처리
            }

            override fun onClosed(
                webSocket: WebSocket,
                code: Int,
                reason: String
            ) {
                // 종료 처리
            }
        })
    }

    override fun disconnect() {
        webSocket?.close(1000, "user closed")
        webSocket = null
    }
}

PR에서는 이 WebSocket을 직접 쓰는 대신, RealTimeService 인터페이스로 감싸고, 상위 계층에는 콜백/Flow 형태로 이벤트를 올려주는 구조를 사용했다.

6. 음성 입력 보내기

음성 통화 느낌을 내려면, 마이크에서 입력을 받아 Realtime API로 보내야 한다.

1. AudioRecord로 PCM 데이터 수집
2. 적당한 크기(예: 20~40ms 단위)의 버퍼로 잘라 WebSocket 바이너리 프레임으로 전송
3. 녹음이 끝났다는 이벤트도 Realtime API 프로토콜에 맞게 JSON으로 보내야 한다

예시 코드 흐름은 다음과 같다.

fun sendAudioStream() {
    val minBufferSize = AudioRecord.getMinBufferSize(
        SAMPLE_RATE,
        CHANNEL_CONFIG,
        AUDIO_FORMAT
    )

    val audioRecord = AudioRecord(
        MediaRecorder.AudioSource.MIC,
        SAMPLE_RATE,
        CHANNEL_CONFIG,
        AUDIO_FORMAT,
        minBufferSize
    )

    val buffer = ByteArray(minBufferSize)

    audioRecord.startRecording()

    while (isRecording) {
        val read = audioRecord.read(buffer, 0, buffer.size)
        if (read > 0) {
            // 이 부분에서 OpenAI Realtime 프로토콜에 맞게 래핑 후 전송
            webSocket?.send(ByteString.of(buffer, 0, read))
        }
    }

    audioRecord.stop()
    audioRecord.release()
}

실제 PR에서는 OpenAI의 이벤트 규격에 맞는 JSON을 보내고, 오디오 프레임을 특정 이벤트 타입에 맞춰서 전송하는 로직이 들어간다. 이 부분은 Realtime API 공식 문서의 이벤트 포맷을 참고해 구현하면 된다. (OpenAI Platform)

7. 음성 응답 재생하기

서버에서 오는 오디오는 WebSocket의 onMessage(bytes: ByteString)에서 받는다. 바로 재생하면 버퍼가 꼬이거나, 여러 응답이 겹쳐서 들리기 쉬우므로 Saegil-Android에서는 “재생 큐”를 두고 한 번에 하나씩 재생하는 구조로 풀었다.

대략적인 흐름은 다음과 같다.

1. BlockingQueue<ByteArray> 혹은 Channel<ByteArray>로 오디오 조각을 쌓는다
2. 별도의 재생 쓰레드 / 코루틴에서 큐를 소비하면서 AudioTrack으로 재생
3. 끊김을 줄이기 위해 재생 버퍼 사이에 약간의 sleep 또는 버퍼 사이즈 조절

class AudioPlayer {

    private val audioTrack = AudioTrack(
        AudioAttributes.Builder()
            .setUsage(AudioAttributes.USAGE_VOICE_COMMUNICATION)
            .setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
            .build(),
        AudioFormat.Builder()
            .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
            .setSampleRate(SAMPLE_RATE)
            .setChannelMask(AudioFormat.CHANNEL_OUT_MONO)
            .build(),
        BUFFER_SIZE,
        AudioTrack.MODE_STREAM,
        AudioManager.AUDIO_SESSION_ID_GENERATE
    )

    private val scope = CoroutineScope(Dispatchers.IO + SupervisorJob())
    private val queue = Channel<ByteArray>(Channel.UNLIMITED)

    init {
        scope.launch {
            audioTrack.play()
            for (chunk in queue) {
                audioTrack.write(chunk, 0, chunk.size)
            }
        }
    }

    fun enqueue(bytes: ByteArray) {
        scope.launch {
            queue.send(bytes)
        }
    }

    fun stop() {
        scope.cancel()
        audioTrack.stop()
        audioTrack.release()
    }
}

WebSocket 쪽에서는 onMessage(bytes: ByteString)에서 audioPlayer.enqueue(bytes.toByteArray())를 호출하는 식으로 연결하면 된다.

8. ViewModel과 UI에서의 사용

presentation 레이어에서는 크게 두 가지를 관리한다.

1. 통화 상태

   • 연결 중인지
   • 상대가 말하고 있는지
   • 내가 말하고 있는지

2. 에러/로딩 상태

   • 토큰 요청 실패
   • WebSocket 연결 실패
   • 네트워크 끊김

예시 ViewModel 흐름:

@HiltViewModel
class AiConversationViewModel @Inject constructor(
    private val startRealtimeChatUseCase: StartRealtimeChatUseCase,
    private val endRealtimeChatUseCase: EndRealtimeChatUseCase,
) : ViewModel() {

    private val _uiState = MutableStateFlow(AiConversationUiState())
    val uiState = _uiState.asStateFlow()

    fun startCall() {
        viewModelScope.launch {
            _uiState.update { it.copy(isConnecting = true) }

            startRealtimeChatUseCase()
                .onSuccess {
                    _uiState.update { it.copy(isConnecting = false, isTalking = true) }
                }
                .onFailure { e ->
                    _uiState.update {
                        it.copy(isConnecting = false, errorMessage = e.message ?: "연결 실패")
                    }
                }
        }
    }

    fun endCall() {
        viewModelScope.launch {
            endRealtimeChatUseCase()
            _uiState.update { it.copy(isTalking = false) }
        }
    }
}

Compose 화면(AiConversationScreen)에서는 이 uiState를 구독하며 통화 버튼, 타이머, 파형 애니메이션 등을 표시한다.

9. REST 대비 체감 성능 개선

실제 프로젝트에서 REST + TTS 방식과 Realtime WebSocket 방식의 속도를 비교했을 때:

• 기존 방식: 음성 종료 후 응답 재생까지 약 10~11초
• Realtime WebSocket: 음성 종료 후 응답 재생까지 약 3초

대략 70% 이상의 딜레이를 줄일 수 있었고, 전화 대화처럼 “말하면 곧바로 답이 오는” 느낌에 훨씬 가까워졌다.

10. 정리 및 도입 시 팁

정리하면, Android에서 OpenAI Realtime API(WebSocket)를 붙일 때 핵심은 세 가지다.

1. 백엔드에서 client_secret(ephemeral key)을 발급해주는 얇은 API를 만든다.
2. 안드로이드에서는 이 토큰을 사용해 WebSocket을 열고, 마이크·스피커 처리는 AudioRecord/AudioTrack으로 관리한다.
3. WebSocket 이벤트를 ViewModel로 올리고, UI는 단순히 상태와 이벤트만 구독하도록 분리한다.

도입할 때 생각해 볼 포인트:

• 토큰 만료(기본 30분) 시 재발급/재연결 전략 (OpenAI Platform)
• 네트워크 끊김/재연결 처리
• 녹음 권한, 블루투스/이어폰 오디오 라우팅
• 벤치마크(프레임 타이밍, 지연 시간)로 실제 성능 측정

구현 PR

안드로이드 스튜디오의 에뮬레이터에서 로컬에서 실행 중인 Spring Boot 서버로 REST API 요청을 보낼려고 한다. 하지만 안드로이드 스튜디오 에뮬레이터에서 localhost 또는 127.0.0.1 로 요청을 보내면 실패한다. 이유와 해결 방법을 정리한다.

1. 안드로이드 에뮬레이터에서 localhost가 동작하지 않는 이유

에뮬레이터에서 다음 주소로 요청하면:

http://localhost:9000
http://127.0.0.1:9000

에뮬레이터 내부에서는 이것을 본인(에뮬레이터 디바이스 자체) 로 해석한다. Mac 또는 개발 PC의 Spring Boot 서버가 아닌, 디바이스 내부를 바라본다는 뜻이다.

따라서 아래와 같은 오류가 발생한다.

Failed to connect to localhost/127.0.0.1:9000

에뮬레이터는 개발 PC를 직접 인식하지 못하기 때문에 다른 접근 방식이 필요하다.

2. 에뮬레이터에서 PC의 로컬 서버에 접근하는 공식 주소

에뮬레이터가 개발 PC의 localhost로 접속하기 위해 제공되는 특별 주소가 있다.

10.0.2.2

Android Emulator에서 이 주소는 개발 PC의 localhost를 의미한다. 따라서 Retrofit 또는 OkHttp의 baseUrl을 다음과 같이 변경해야 한다.

http://10.0.2.2:9000/

포트 번호는 개발 PC에서 Spring Boot가 실행 중인 포트를 그대로 사용하면 된다.

3. Retrofit 설정 예시

Retrofit.Builder()
    .baseUrl("http://10.0.2.2:9000/")
    .addConverterFactory(GsonConverterFactory.create())
    .build()

이렇게 수정하면 에뮬레이터에서 로컬 서버로 정상적으로 API 요청이 전송된다.

4. 정리

안드로이드 에뮬레이터의 localhost는 PC가 아닌 에뮬레이터 자신의 주소이므로 동작하지 않는다. 반드시 10.0.2.2 를 사용해야 한다.

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/opt/homebrew/var/mysql/mysql.sock' (2)

내부 서버는 실행 중이라고 표기되지만 실제로는 소켓 파일이 존재하지 않아 접속이 불가능한 상태였다. 초기화 실패, 데이터 디렉토리 충돌, 라이브러리 경로 오류까지 다양한 원인이 겹쳐 문제 해결이 예상보다 오래 걸렸다. 본 글에서는 문제 발생 원인과 해결 과정을 정리한다.

1. 문제 상황

Homebrew로 MySQL 설치 후 접속을 시도했다.

mysql -u root

그러나 다음 오류가 발생했다.

Can't connect to local MySQL server through socket '/opt/homebrew/var/mysql/mysql.sock' (2)

이 문제는 MySQL 서버가 실제로 실행 중인지 여부와, 서버가 사용하는 소켓 파일의 위치가 일치하지 않아 발생한 것이었다.

2. MySQL 9.x 설치 실패

MySQL 9.x 설치 과정에서 의존성(protobuf) 버전 충돌이 발생했고, 서버 초기화도 실패했다. 특히 mysqld 실행 시 다음과 같은 라이브러리 로딩 오류가 출력되었다.

Library not loaded: /opt/homebrew/opt/protobuf/lib/libprotobuf-lite.29.2.0.dylib

Homebrew의 rolling 업데이트 특성 상 의존성 버전이 바뀌면서 MySQL이 필요로 하는 버전과 맞지 않는 상황이었다.

3. MySQL 8.4로 재설치

문제를 해결하기 위해 MySQL을 완전히 제거하고 8.4 버전으로 재설치했다.

1. 기존 MySQL 정지

   brew services stop mysql

2. 데이터 디렉토리 삭제

   sudo rm -rf /opt/homebrew/var/mysql

3. MySQL 8.4 설치

   brew install mysql@8.4

4. 데이터베이스 초기화

   /opt/homebrew/opt/mysql@8.4/bin/mysqld --initialize-insecure \
     --user=yujin \
     --basedir=/opt/homebrew/opt/mysql@8.4 \
     --datadir=/opt/homebrew/var/mysql

5. 서비스 시작

   brew services start mysql@8.4

여기까지는 모든 과정이 정상적으로 완료되었다.

4. 그러나 여전히 접속 불가

brew services info mysql@8.4 명령어 결과, 서비스는 Running 상태로 표시되었다.

Running: ✔
PID: 893

하지만 소켓 파일이 생성되지 않아 접속은 여전히 불가능했다. 이는 MySQL 서버가 /opt/homebrew/.../mysql.sock 대신 다른 위치에 소켓을 생성하고 있었기 때문이다.

5. 실제 소켓 파일 위치 확인

다음 명령으로 소켓 위치를 검색했다.

sudo find / -name "mysql.sock*" 2>/dev/null

출력 결과는 다음과 같았다.

/System/Volumes/Data/private/tmp/mysql.sock
/System/Volumes/Data/private/tmp/mysql.sock.lock

즉 MySQL 서버가 소켓을 /tmp/mysql.sock 에 생성하고 있었던 것이다. 이는 macOS의 보안 구조 및 Homebrew MySQL 8.4의 기본 설정 때문에 흔히 발생하는 동작이다.

6. 임시 해결

소켓 경로를 직접 지정해 접속하면 문제가 해결된다.

mysql -u root -S /tmp/mysql.sock

그러나 이 방법은 매번 -S 옵션을 붙여야 하기 때문에 근본적인 해결은 아니다.

7. 영구 해결: my.cnf 수정

MySQL 서버와 클라이언트가 동일한 소켓 경로를 사용하도록 my.cnf 파일을 수정했다.

sudo nano /opt/homebrew/etc/my.cnf

아래 설정을 작성했다.

[client]
socket = /opt/homebrew/var/mysql/mysql.sock

[mysqld]
socket = /opt/homebrew/var/mysql/mysql.sock
pid-file = /opt/homebrew/var/mysql/mysql.pid
datadir = /opt/homebrew/var/mysql

작성 후 MySQL을 재시작했다.

brew services restart mysql@8.4

소켓 파일 생성 여부 확인:

ls -al /opt/homebrew/var/mysql | grep sock

소켓 파일이 정상 생성된 것을 확인한 뒤 다시 접속했다.

mysql -u root

문제 없이 접속되었다.

8. 정리

본 문제는 다음 두 가지 요인이 겹쳐 발생했다.

1. Homebrew MySQL 설치 및 초기화 실패
2. MySQL 서버가 /tmp/mysql.sock 경로를 사용하지만, 클라이언트는 /opt/homebrew/var/mysql/mysql.sock 을 찾는 설정 불일치

해결 방법은 다음과 같다.

• 정확한 소켓 파일 위치를 찾는다.
• 필요하다면 my.cnf를 생성하여 서버와 클라이언트의 소켓 경로를 강제로 통일한다.
• 이후 MySQL을 재시작한다.

URL Shortener 프로젝트를 만들다가 예상치 못한 상황을 마주했다. 프론트엔드 대시보드에서 전체 URL 목록을 불러오기 위해 /urls 엔드포인트를 호출했는데, 계속 404가 떨어지는 문제가 발생했다.

{
  "detail": "Short URL not found"
}

문제는 프론트엔드가 아니라 서버 라우터 쪽에 있었다.

1. 증상

Swagger와 curl에서도 동일하게 /urls가 404를 반환했다.

curl https://url-shorter.onrender.com/urls
# → {"detail": "Short URL not found"}

FastAPI log에서도 /urls 요청이 들어갔는데, 내부에서는 완전히 다른 라우트가 실행되고 있었다.

2. 원인 파악

결론부터 말하면 아래 라우트가 문제였다.

@app.get("/{code}")
def redirect(code: str):
    ...

FastAPI는 라우트를 정의된 순서대로 검사한다. /{code}는 어떤 문자열이든 모두 매칭되기 때문에 아래처럼 동작한다.

GET /urls → code = "urls" 로 매칭됨

그 결과 FastAPI는 /urls를 정적 라우트로 처리하지 않고, 동적 라우트로 인식한다.

즉, "/urls"가 아닌 "/{code}"가 실행되고 있었던 것.

그래서 DB에서 "urls"라는 short code를 찾다가 없어서 404("Short URL not found")가 내려온 것이다.

이 상황은 URL Shortener처럼 단일 동적 엔드포인트가 있는 서비스에서 쉽게 발생한다.

3. 해결 방법 – 라우트 순서 재정렬

정적인 라우트를 동적 라우트보다 앞에 놓아야 한다.

잘못된 순서:

@app.get("/{code}")    # 동적
@app.get("/urls")      # 정적 (가려짐)

올바른 순서:

@app.get("/urls")               # 가장 먼저
@app.get("/stats/{code}")       # 부분 동적
@app.get("/{code}")             # 마지막

FastAPI는 선언 순서가 곧 우선순위이다. 정적 → 부분 동적 → 완전 동적 순으로 정리하면 충돌이 없다.

4. 왜 이런 방식으로 동작하는가

FastAPI의 라우팅은 Starlette 라우터를 기반으로 한다. Starlette는 URL 매칭을 다음 기준으로 처리한다.

1. 정적 경로(예: /urls, /health)
2. 부분 동적 경로(예: /stats/{code})
3. 완전 동적 경로(예: /{code})
4. 와일드카드 (/{path:path})

문제는 “우선순위”가 아니라 코드 선언 순서가 우선 적용된다는 점이다. 동적 경로를 맨 위에 선언하면 정적 경로보다 먼저 검사되어 그대로 가로채 버린다.

5. 실제 수정 후 결과

라우트 순서를 다시 정렬한 뒤에는 다음과 같이 정상적으로 응답이 내려왔다.

GET /urls → 정상 200  
GET /stats/abc123 → 정상 200  
GET /xyz789 → redirect 정상 작동

정리된 구조는 아래와 같다.

@app.get("/urls")
def list_urls(): ...

@app.get("/stats/{code}")
def stats(code: str): ...

@app.get("/{code}")
def redirect(code: str): ...

6. 마무리

이번 문제는 URL Shortener에서 특히 자주 발생하는 라우트 충돌 이슈였다. 프레임워크의 라우팅 매칭 원리를 정확히 알고 있어야 해결할 수 있으며, 동적 라우트가 하나라도 포함되는 프로젝트라면 라우팅 순서를 항상 신경 써야 한다.

개발 과정에서 흔히 겪을 수 있는 오류이지만, 이 원리를 잘 이해해두면 FastAPI 구조 설계가 훨씬 깔끔해진다.

정리해보면, 다음과 같은 증상이 있었다.

• 페이지는 열리지만 “Stats not found”가 표시된다.
• 네트워크 탭에서 API 호출을 보면 /stats/undefined로 요청이 나간다.
• Vercel 로그에서는 /stats/[code] 라우트가 정상적으로 호출되지만, 실제 코드 값이 전달되지 않는다.
• 콘솔에서 다음 오류를 확인할 수 있었다:

Error: Route "/stats/[code]" used `params.code`. 
`params` is a Promise and must be unwrapped with `await` or `React.use()`

이 문제의 근본 원인은 Next.js App Router의 params 전달 방식 때문이다.

문제 원인: params가 Promise로 넘어온다

Next.js 13 이후 App Router를 사용할 경우, 서버 컴포넌트에서 dynamic route의 params가 가끔 Promise 형태로 전달된다. 로컬 환경에서는 Promise가 아닌 일반 객체처럼 보이기 때문에 문제를 알아채기 어렵다.

기존에 사용했던 코드:

export default async function StatsPage({ params }) {
  const { code } = params;   // 여기서 문제 발생
}

배포 후 콘솔을 찍어보면 다음과 같이 나온다.

params = Promise { { code: 'qSmO2J' }, ... }

즉, 구조분해 할당으로 바로 값에 접근할 수 없기 때문에 code가 undefined가 되고, API 요청 역시 /stats/undefined로 나가게 된다.

해결 방법: params를 await로 언래핑

문제 해결은 간단하다. params 자체가 Promise이므로, 먼저 기다린 뒤 값을 꺼내야 한다.

수정된 코드:

export default async function StatsPage({ params }: { params: Promise<{ code: string }> }) {
  const { code } = await params;

  const res = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/stats/${code}`, {
    cache: "no-store",
  });

  if (!res.ok) {
    return <div>Stats not found for {code}</div>;
  }

  const data = await res.json();

  return <StatsView code={code} data={data} />;
}

이렇게 수정한 뒤 다시 배포하니 문제는 바로 해결되었다. 더 이상 undefined가 전달되지 않고, API에서 받은 통계 정보가 정상적으로 렌더링된다.

추가로 배운 점

1. App Router 기반에서 서버 컴포넌트의 dynamic params는 항상 Promise일 수 있다고 가정하는 것이 안전하다.
2. 로컬 개발 환경과 Vercel 배포 환경이 완전히 동일하지 않을 수 있으니, params나 searchParams를 사용할 때는 콘솔로 형태를 확인하는 습관이 중요하다.
3. 클라이언트 컴포넌트에서는 이런 문제가 발생하지 않지만, 서버 컴포넌트에서는 비동기 전달 이슈가 자주 등장할 수 있다.
4. 이번 이슈는 Next.js 이슈 트래커에서도 언급될 정도로 흔히 발생하며, 버전에 따라 동작이 달라질 가능성이 있다.

마무리

처음에는 API URL 문제나 환경 변수 설정 오류를 의심했지만, 원인은 Next.js가 넘겨주는 params의 형태였다. 문제가 조금 돌아가는 듯 보였지만, 배포 환경에서 콘솔을 찍어보고 값을 직접 확인하면서 원인을 정확히 잡을 수 있었다.

동일한 구조로 Dynamic Route를 사용하는 경우라면, 서버 컴포넌트에서 await params를 적용하는 것만으로도 비슷한 문제를 예방할 수 있다.

1. 민트책 - 유선배 SQL개발자(SQLD) 과외노트

개념서인데 문제도 꽤 많고 문제 해설도 유튜브에 잘 되어있어서 입문자도 보기 좋을듯!

2. 노랭이 - SQL 자격검정 실전문제

소위 말하는 노랭이는 무려 시험 출제 기관에서 기출로 낸 문제집이니 적중률이 높다! 시험장에서 몇몇 문제는 똑같은것도 봤슨.. 하지만... 무턱대로 노랭이를 폈다간 공부의지를 잃을수도 있으니 주의..

노랭이는 인터넷에서 노랭이해설.txt를 구해서 봤다 왜냐면... 내가 도서관에서 빌린 노랭이에 답지가 없었다... 답지에 답만 있는지 해설도 있는진 모르겠으나 저 해설이 꽤 도움이 되었다!

두 책 선정이유는 유명해서도 있지만 이유는 학교 도서관에 있어서이다.. 참고로 23년도에 시험이 개정되어서 개정된걸로 봐야하지만 나는 그냥 전 걸로 봤다

3. Oracel - Human Resources 데이터로 쿼리 연습하기

freesql이라고 이미 구비된 데이터베이스에 쿼리 날려서 연습할 수 있는 사이트이다. 내 기억으로는 민트책이랑 노랭이 예시가 저 Oracel에서 무료로 제공하는 Human Resources 데이터에 쿼리를 날려서 이렇게 저렇게 조회하는 문제들이라서 저걸로 실제 해보면 좋다! 무작정 외우는 것보다 훨씬 훨씬 도움된다

그 이유는 코딩은 같은 결과물이더라도 다른 방법의 코드가 존재하며, 선지 4개 중에 출력이 다른 것을 고르시오 와 같은 문제도 나오기 때문!!

원트 이야기

사실 ... 현장실습을 하던 24-2학기때 시험을 봤었는데... 통과를 못했었다 당시 너무 바빴?고 자만감이 커서 공부를 거의 안하고 봤다 돈아까운줄 모르고... 뗴잉

그때는 아마 개념 한번도 안돌고 기출도 한번도 안돌고 그냥 요약집만 보고 갔었다

이트 이야기

지금은! 개념도 한번 돌고 기출도 한번 돌아서 가기로~

계획을 다 지켰는지는 기억이 안난다.. 약 열흘을 잡고 하루에 한시간씩 공부했다

그럼 이젠 sql 안녕~

문제의 시작: OutOfMemoryError 발생

안드로이드 앱에서 200MB가 넘는 대용량 TXT 파일을 읽어와 특정 GPS 정보만 파싱하는 로직을 만들었다. 그런데 파일을 선택하자마자 앱이 강제 종료되는 사건이 발생하였다. 로그를 확인해보니, java.lang.OutOfMemoryError가 문제였다.

200MB 파일을 한 번에 메모리에 올리려다 보니 앱에 할당된 메모리 한계를 초과하여 발생한 오류였다.

첫 번째 시도: Flow를 사용한 메모리 누적

OutOfMemoryError를 해결하기 위해 Flow와 collect를 사용한 스트림 처리 방식을 도입했다. 파싱된 데이터를 Flow로 방출하고, collect 블록에서 리스트에 하나씩 추가하는 방식이었다.

// FilePickerViewModel.kt (문제의 코드)
    fun readTextFromFileUri(uri: Uri?) {
           viewModelScope.launch {
            try {
                _parsedContent.value = emptyList() // 초기화
                val resultList = mutableListOf<String>()
                readFileAndParse(uri).collect { parsedLine ->
                    resultList.add(parsedLine)
                    _parsedContent.value = resultList.toList() // UI에 업데이트
                }
                Timber.d("File parsing completed.")
                Timber.d("Parsed content: ${_parsedContent.value}")
            } catch (e: Exception) {
                e.printStackTrace()
                _parsedContent.value = listOf("파일을 읽는 중 오류가 발생했습니다: ${e.message}")
            }
        }
    }

하지만 이 방식은 근본적인 문제를 해결하지 못했다. resultList는 메모리에 모든 파싱 데이터를 누적시켰고, resultList.toList()는 매번 새로운 리스트 객체를 생성하며 메모리를 더 많이 사용했다.

/**
 * Returns a [List] containing all elements.
 */
public fun <T> Iterable<T>.toList(): List<T> {
    if (this is Collection) {
        return when (size) {
            0 -> emptyList()
            1 -> listOf(if (this is List) get(0) else iterator().next())
            else -> this.toMutableList()
        }
    }
    return this.toMutableList().optimizeReadOnlyList()
}

toList()는 어떤 경우든 기존의 리스트를 변경하지 않고, 모든 요소를 복사하여 새로운 리스트를 생성한다.

결국 수십만 개의 라인을 처리하다가 다시 OutOfMemoryError가 발생한 거다.

운이 좋아 메모리가 널널하다면 파싱은 잘된다... 하지만 운이 나빠 메모리가 부족하다면 앱이 터진다. 이는 백퍼 QA에서 뚜까뚜까 맞을 앱이다.

Flow를 사용하더라도 collect 블록 안에서 모든 데이터를 메모리에 쌓는 건 OutOfMemoryError의 지름길이다.

두 번째 문제: UI 상태 업데이트 지연

메모리 문제를 해결하는 과정에서 또 다른 문제가 발견됐다. 파일을 선택하면 화면이 즉시 업데이트되지 않고, 잠시 동안 검은 화면이 나타났다.

_앱 화면 -> 파일 선택기 -> 파일 선택기에서 한참 있다가 -> 검은 화면에서 한참 있다가 -> 앱 화면으로 돌아온다 _내가 뷰모델에서 설정한 UiState가 전혀 반영되고 있지 않았다.

난 바보다. 파일 파싱을 메인 스레드에서 하고 앉아 있었던 것이다. UIstate 자체는 viewModelScope의 메인 스레드에서 업데이트하는게 맞지만, 실제 파일 읽기 작업 또한 메인 스레드에서 하고 있어버리니 메인스레드가 막혀 버린 것이다.

그래서 급하게 flow에 Dispatchers.IO를 달아준다.

// FilePickerViewModel.kt (문제의 코드)
private fun readFileAndParse(uri: Uri): Flow<GpsData> = flow {
    withContext(Dispatchers.IO) { /* ... */ } // ❌ 이 부분이 문제!
}

하지만... 이는 반쪽짜리 해결책이었다.

Flow 빌더 내부에 withContext(Dispatchers.IO)를 사용하면 emit이 IO 스레드에서 발생하고 collect는 메인 스레드에서 발생하여 Flow의 컨텍스트 보존 규칙을 위반하는 오류가 발생한 것이다.

최종 해결책: flowOn을 사용한 올바른 스레드 분리

withContext 대신 flowOn 연산자를 사용해 문제를 해결했다. flowOn은 Flow의 업스트림(파일 읽기/파싱) 실행 컨텍스트를 백그라운드 스레드로 전환해 준다.

// FilePickerViewModel.kt (최종 해결책)
    fun readTextFromFileUri(uri: Uri?) {
       viewModelScope.launch {
            _state.value = UiState.Loading
            try {
                // Flow의 실행 컨텍스트를 IO 스레드로 전환
                val resultList = mutableListOf<GpsData>()
                readFileAndParse(uri)
                    .flowOn(Dispatchers.IO)
                    .onStart { _state.value = UiState.Loading }
                    .collect { gpsData ->
                        resultList.add(gpsData)
                        _state.value = UiState.Success(FilePickerState(resultList.toList()))
                        Timber.d("Parsed items: ${resultList.size}")
                    }
            } catch (e: Exception) {
                e.printStackTrace()
                _state.value = UiState.Error("파일을 읽는 중 오류가 발생했습니다: ${e.message}")
            }
        }
    }

아직도 미해결

테스트를 해보던 중.. 아직도 OOM이 터지는것을 알게되었다.. 사실 알고 싶지 않았다.

그래서 코드를 gemini한테 주고 문제점을 알려달라고 했더니, distinct가 문제라고 했다. distinct()가 전체 파일을 메모리에 로드하기 때문에 터지는 것으로 파악했다.

public fun <T> Sequence<T>.distinct(): Sequence<T> {
    return this.distinctBy { it }
}

결론

• 메모리 누적 문제: Flow를 사용하더라도 collect 내부에서 모든 데이터를 메모리에 누적하면 OutOfMemoryError가 발생한다.

• UI 블로킹 문제: 파일 읽기/쓰기 같은 I/O 작업은 flowOn(Dispatchers.IO)를 사용해 백그라운드 스레드로 분리해야 한다.
• UI 상태 관리: Flow의 onStart 연산자를 사용해 로딩 상태를 먼저 발행하고, collect 블록에서 데이터가 들어올 때마다 UI 상태를 업데이트하여 사용자에게 즉각적인 피드백을 제공해야 한다.

RadioButton 처럼 하나만 클릭되는 버튼들을 커스텀으로 제작하는 중 마주한 오류가 있다. 분명히 클릭 로그는 찍히는데, UI상으로 변화가 없다..!

이는 컴포넌트의 최상단이 Box가 아닌 Surface로 지정해서 생긴 문제였다. 좀 더 자세히 알아보자.

Surface의 내부 최적화에 따른 recomposition 누락

Compose의 Surface는 내부적으로 색상, elevation, 클릭 효과 등을 처리하면서 최적화를 수행한다. 이 과정에서 상태 변화가 있더라도 UI에 변화가 없다고 판단되면 draw를 생략하여 화면이 갱신되지 않을 수 있다.

Surface와 Box의 차이

Compose에서 Surface와 Box는 모두 UI를 구성하는 레이아웃 요소지만, 내부 작동 방식과 recomposition 최적화 처리에서 큰 차이를 보인다. 이번 사례에서 Surface는 상태 변화에 따라 UI가 눈에 보이게 변하지 않았으며, 그 이유는 아래와 같다.

Surface는 내부적으로 머티리얼 레이어 계층, 색상, 그림자, 클릭 등을 종합적으로 처리한다. 이 과정에서 재조합 최적화가 발생하여, 상태 변화가 시각적으로 드러나지 않을 수 있다.

반면, Box는 단순한 컨테이너로 동작하므로 상태 변화가 곧바로 시각적 변화로 이어진다.

Surface의 내부 동작

Surface는 단순한 박스가 아니라 다음과 같은 기능을 자동으로 포함한다.

결과적으로

• 많은 처리를 Compose 내부 composition scope에 위임한다.
• 상태 변경에 따른 색상 변화가 명확하지 않으면 Compose는 “변화 없음”으로 판단하여 재조합을 생략하거나 draw 단계를 건너뛴다.

Box의 내부 동작

Box는 단순한 layout container로, 다음과 같은 특징이 있다.

• 배경색, border, 클릭 등을 모두 개발자가 수동으로 제어해야 한다.
• 상태가 변경되면 Compose는 모든 Modifier를 다시 적용하고 draw 단계도 무조건 실행한다.

실제 발생한 현상

Surface(
  color = if (isSelected) X else Y,
  border = ...
)

이 경우, color, border, shape, tonalElevation 등이 종합적으로 처리된다. 이 중 draw layer가 동일하다고 판단되면 Compose는 화면을 다시 그리지 않는다. 따라서 로그는 나오지만 실제 화면에는 아무런 변화도 보이지 않게 된다.

실험으로 확인하는 방법

Surface(
    color = if (isSelected) Color.Red else Color.Blue, // 확실한 색상 차이
    border = BorderStroke(2.dp, Color.Magenta), // 극단적인 변화
    modifier = Modifier.clickable { onSelect() }
) {
    Text(text = "테스트", modifier = Modifier.padding(20.dp))
}

이렇게 설정했음에도 UI가 변하지 않는다면, 이는 Surface 내부의 최적화 때문이라고 볼 수 있다.

결론: Surface vs Box

Surface는 복잡한 머티리얼 레이어를 제공하므로, 간단한 상태 기반 UI 커스터마이징에는 Box와 Modifier 조합이 더 안정적이다.

특히 색상이나 border로만 상태를 표현하는 경우, Surface의 내부 최적화로 인해 오히려 recomposition 누락 문제가 발생할 수 있다.

마무리

UI 컴포넌트를 만들 때는 Surface 말고 Box를 사용하자!!!! 리컴포지션 해야한다!!!

결론: Surface는 상태 변화가 있어도 재조합을 생략하는 경우가 많기 때문에, 상태 기반 UI 컴포넌트에는 적합하지 않다.

Handler Looper Message MessageQueue

Handler는 메인 Looper와 연결되어 메인스레드에서 Message를 처리하는 중심 역할을 한다.

UI 스레드

• UI 업데이트는 단일스레드
• 메인스레드 = UI스레드
• UI 뿐만 아니라 서비스, 리시버, Application도 UI 스레드에서

루퍼

• Looper는 TLS(Thread local storage)에 저장되고 꺼내진다
• Looper는 각각의 MessageQueue를 가진 다

메시지와 메시지큐

• 메시지큐는 메시지가 실행 타임스탬프순으로 삽입되고 링크로 연결되어 실행시간이 빠른것부터 순차적으로 꺼내어진다

핸들러

• 핸들러는 메시지를 메시지큐에 넣는 기능 / 메시지큐에서 꺼내 처리하는 기능
• 핸들러와 루퍼는 연결되어있음
• 핸들러 생성자 종류가 있다.
  1. 기본 생성자 -> 기본 스레드 -> 메인 루퍼
  2. 백그라운드 스레드 -> 기본 생성자 못씀. 그 스레드에서 쓸 루퍼를 따로 준비해아함
• 핸들러는 UI 갱신을 위해서 씀
  1. 백그라운드 스레드에서의 UI 업데이트
  2. 메인스레드에서 다음 작업 예약
  3. 반복 UI 갱신
  4. 시간 제한
• 실행 시점을 보장하지는 않음. 앞선 작업이 오래걸리면 밀림. 단일스레드라서

ANR

• ANR (Application Not Responding) 어느 동작이 메인스레드를 너무 오랜시간동안 점유하고 있다
• ANR 앱과 무관하게 기기의 사양에 따라 발생할 수도 있..음.
• 명시하지 않으면 1분

한때 안드로이드에 대해 우매함의 봉우리에 있었던 적이 있었다. 당시는 23년이었던걸로 기억한다. 이제는 겸손함을 겸비해 아직도 내가 부족하고, 깊이 있게 알지 못한다는 사실을 안다.

안드로이드 직무로 인턴 근무도 하게 되었고, 좀더 깊이 있는 지식이 있으면 좋을 시기라 생각되어... 안드로이드 딥다이브를 시작한다!

엄재웅님의 매니페스트 안드로이드 인터뷰 책을 볼까 하다가, 그래도 실물 책을 가지고 있는게 있어서 이 책으로 진행해보려고 한다. 이 책은 안드로이드 고수 정00에게 추천받은 책이다. 책은 17년도에 출간되어서 코루틴, 컴포즈 등 최신 기술 이야기는 없지만 근본적인 이야기로 구성되어 있다.

그리고 무엇보다도 책이 얇다!! 책이 얇다는 것은 빨리 끝낼 수 있어 성취감을 크게 느낄 수 있고 또 출퇴근 짬을 통해서도 볼 수 있다는 의미다~

아무튼 시작~

다시금 안드로이드 지식 빈곤기를 맞이한 미래의 나를 위해서, 모르는 내용 위주로 기록해보려고 한다!

• Context가 Acvtiviy, Service, Application의 상위클래스임
• 하드웨어 제어나 빠른 속도가 필요한 것은 JNI을 연결해서 네이티브 C/C++코드를 사용
• 타겟sdk를 지정하지 않으면 minsdk와 동일하게 된다
• 타겟sdk 14이상일때 앱 아이콘에 기본 패딩이 들어감
• 허니콤부터는 AsyncTask가 병렬실행에서 순차 실행으로 바뀌었다. 닉값 못하네;
• 메인스레드에서 네트워크 통신하면 에러 발생함
• 명시적 인텐트로 서비스 시작 startService나 bindService를 쓸 때 명시적 인텐트를 써야한다. 암시적은 예외 발생
• 낮은 버전에서 안되는 코드에 크래시 발생을 막기 위해서 버전에 따른 분기처리를 한다
• SharedPreference에서 apply는 비동기고 commit은 동기 반영이다

• Activity
• Service
• BroadcastReceiver
• ContentProvider

이 중 Service는 화면이 없는 컴포넌트다. 사용자와 직접 상호작용하지 않지만, 앱의 “뒤에서 돌아가야 하는 작업”을 담당한다.

이 글에서는 “무슨 일이 있어도 BLE 통신이 살아 있어야 한다”라는 실제 개발 요구사항을 통해 Service, 특히 Foreground Service가 왜 필요했는지를 정리해본다.

개발 요구사항: 무슨 일이 있어도 BLE 통신이 살아있게 해주세요

Service를 처음 제대로 다뤄본 계기는 스타트업 인턴 시절 받은 첫 번째 과제였다.

요구사항은 대략 다음과 같았다.

해외 전시회에서 회사의 전기자전거용 속도계를 시연해야 한다. 실제 전기자전거를 해외로 가져갈 수 없으니, 안드로이드 앱에서 전기자전거 신호를 흉내 내어 BLE 통신을 보내는 앱을 만들어라.

단, 부스 운영 중에는 앱이 백그라운드로 가도 절대 꺼지면 안 된다.

처음 들었을 때는 다소 추상적인 요구처럼 들렸지만, 이를 개발 용어로 정리하면 훨씬 명확해진다.

요구사항을 개발 용어로 풀어보면

위 요구사항을 정리하면 다음과 같다.

기기를 잠그거나 앱이 포커싱되지 않은 상태에서도 BLE subscriber에게 notification이 계속 전달되어야 한다.

여기서 중요한 포인트는 두 가지다.

1. BLE notification

• 앱이 임베디드 장비(자전거 속도계 프로토타입)에게 주기적으로 신호를 보내는 행위
• BLE GATT 통신에서의 Notify

2. 포커싱이 없는 상태

• Activity 기준으로 onStop() 상태
• 즉, 화면에 보이지 않는 상태
• onDestroy()만 아니라면 계속 BLE 통신이 유지되어야 함

이 시점에서 Activity만으로는 요구사항을 만족할 수 없다는 것이 분명해진다.

왜 Activity로는 안 되는가

Activity는 사용자 인터페이스를 담당하는 컴포넌트다.

• 화면이 가려지면 onStop()
• 시스템 상황에 따라 언제든 종료될 수 있음
• 백그라운드 장시간 작업에 부적합

즉, “좀비처럼 살아 있어야 하는 작업”을 Activity에 두는 것은 구조적으로 잘못된 선택이다.

이때 등장하는 컴포넌트가 바로 Service다.

Service란 무엇인가

Service는 다음과 같은 특징을 가진다.

• 화면이 없음
• 백그라운드에서 작업 수행 가능
• Activity와 독립적인 생명주기

하지만 여기서 한 가지 더 중요한 사실이 있다.

일반 Service는 백그라운드에서 오래 살아남지 못한다.

안드로이드는 배터리와 리소스를 보호하기 위해 백그라운드에서 오래 실행되는 작업을 적극적으로 종료한다.

그래서 BLE처럼 “지속적이고 중요한 작업”에는 Foreground Service가 필요하다.

좀비처럼 살아있게 하기: Foreground Service

Foreground Service는 사용자에게 명시적으로 알리고, 시스템에게도 중요하다고 선언하는 Service다.

• 알림(Notification)을 반드시 표시해야 함
• 시스템이 쉽게 종료하지 않음
• BLE, 음악 재생, 위치 추적 등에 사용됨

이를 위해 사용되는 핵심 API가 startForeground()다.

Foreground Service 구현

BLE 통신을 담당하는 Service는 다음과 같이 구현했다.

class BluetoothService(
    context: Context,
) : Service() {

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(1, notification)

        return START_STICKY
    }
}

핵심 포인트 정리

• startForeground() → 이 Service를 Foreground Service로 승격
• Notification 필수 → 사용자에게 “이 작업이 실행 중”임을 알림
• START_STICKY → 시스템이 Service를 종료하더라도 가능한 한 다시 재시작

이 설정 덕분에,

• 화면이 꺼져도
• 앱이 백그라운드에 있어도
• 포커싱이 없어도

BLE 통신은 계속 유지될 수 있었다.

Manifest 등록도 필수

Foreground Service는 Manifest에도 명시해야 한다.

<service
    android:name=".bluetooth.BluetoothService"
    android:foregroundServiceType="dataSync" />

• foregroundServiceType → 서비스의 목적을 시스템에 명시
• BLE 통신은 dataSync 유형에 해당

이 설정이 없으면 Android 9(API 28) 이상에서 정상 동작하지 않는다.

정리하며

이 경험을 통해 Service를 이렇게 정리하게 되었다.

• Activity는 화면을 위한 컴포넌트다.
• 백그라운드에서 “계속 살아 있어야 하는 작업”은 Service의 책임이다.
• 단순 Service로는 부족하고, 사용자와 시스템 모두에게 중요함을 알리는 Foreground Service가 필요할 때가 있다.

Service는 단순히 “백그라운드 작업용” 컴포넌트가 아니라, 안드로이드 시스템과 협상하는 방식에 가깝다.

BLE 통신 요구사항 하나를 만족시키기 위해 Service, Foreground Service, 생명주기를 함께 고민했던 경험은 이후 안드로이드 구조를 이해하는 데 큰 도움이 되었다.

작성한 코드

[BluetoothService 전체 코드] (https://github.com/HI-JIN2/virtual-bicycle-with-ble/blob/master/app/src/main/java/com/eddy/nrf/bluetooth/BluetoothService.kt)

먼저, 의존성 주입(Dependency Injection, DI)에 대해 설명하겠다. 의존성 주입은 여러 컴포넌트 간 의존성이 강한 개발 환경에서 클래스 간 결합도를 낮춰주는 멋진 도구다.

객체를 생성할 때는 자연스럽게 클래스 간 의존성이 생긴다. 예를 들어, A 객체를 만들기 위해 B 객체가 필요하다면, A 객체를 생성하는 시점에 불필요하게 B 객체까지 알아야 하는 상황이 발생한다. 이런 식으로 의존 관계가 꼬리를 물고 이어진다.

// main.kt

fun main() {
    val b = B()
    val a = A(b)
}

class A(val b: B) {
    // 어쩌구 저쩌구
}

class B {
    // 어쩌구 저쩌구
}

이때 A 클래스에 의존성 주입을 적용하면, main에서 B를 몰라도 되는 아름다운 일이 생긴다. 정리하자면, 불필요한 의존 관계를 줄이기 위해 의존성 주입을 쓰는 것이다.

// main.kt

fun main() {
    val a = A()
}

class A @Inject constructor(val b: B) {
    // 어쩌구 저쩌구
}

class B {
    // 어쩌구 저쩌구
}

의존성 주입을 위해 안드로이드에서는 주로 Hilt라는 라이브러리를 사용한다.

방법 1

오늘 이야기할 주제는 바로 "UseCaseModule을 꼭 만들어야 할까?" 이다.

미리 정답을 말하자면, 아니다.

의존성 주입을 하려면 보통 아래처럼 @Binds를 이용한 모듈 클래스를 만들고, 빌드 시점에 필요한 의존성들을 한 번에 생성한다.

@Module
@InstallIn(SingletonComponent::class)
abstract class DataModule {

    @Binds
    internal abstract fun bindsUserRepository(
        oauthRepositoryImpl: UserRepositoryImpl,
    ): UserRepository
}

이렇게 세팅해두면, 아래처럼 @Inject constructor로 바로 꺼내 쓸 수 있다.

class GetUserInfoUseCase @Inject constructor(
    private val repo: UserRepository
) {
    suspend operator fun invoke(): Result<User> {
        return repo.getUser()
    }
}

@Inject는 Hilt에 포함된 어노테이션이지만, domain 계층에서는 안드로이드 라이브러리에 대한 의존성이 없어야 한다. 그렇다면 어떻게 해야 할까?

implementation("javax.inject:javax.inject:1")

이렇게 하면 된다. 필요한 건 @Inject뿐이므로, 불필요하게 Hilt 전체를 끌어오지 않아도 된다.

방법 2

다른 방법으로는 UseCase 전용 모듈을 만드는 방식이 있다.

@Module
@InstallIn(SingletonComponent::class)
object UseCaseModule {

    @Provides
    @Singleton
    fun provideGetUserInfoUseCase(
        repo: UserRepository
    ): GetUserInfoUseCase = GetUserInfoUseCase(repo)
}

이렇게 하면 아래과 도메인 모듈에서@Inject 없이도 사용할 수 있지만… UseCase를 하나 추가할 때마다 provide 함수를 또 작성해야 한다는 점이 개인적으로는 마음에 들지 않는다.

class GetUserInfoUseCase(
    private val repo: UserRepository
) {
    suspend operator fun invoke(): Result<User> {
        return repo.getUser()
    }
}

그래서 필자는 방법 1. @Inject 의존성만 추가하는 방식으로 결정했다!