모바일 애플리케이션을 위한 미들웨어 — 기초, 아키텍처 및 활용

미들웨어란?

미들웨어는 두 시스템 구성 요소 사이에 위치하여 데이터를 가로채고 처리한 후 대상 구성 요소로 전달하는 소프트웨어 계층입니다. 모바일 개발에서 미들웨어는 세 가지 주요 컨텍스트에서 사용됩니다: 상태 관리(Redux, Bloc), HTTP 통신(Ktor Client, Dio), 이벤트 처리(EventBus, NotificationCenter). 핵심 가치는 애플리케이션의 도메인 로직으로부터 횡단 관심사의 분리(로깅, 인증, 분석)입니다. 각 화면에 분석 호출을 추가하는 대신 미들웨어가 중앙에서 처리합니다.

Pipe and Filter 아키텍처

미들웨어는 Pipe and Filter 패턴을 구현합니다: 각 미들웨어 구성 요소가 데이터를 수신하여 처리하고 체인의 다음 링크로 전달합니다. 미들웨어 연결 순서가 처리 순서를 결정합니다 — 첫 번째 미들웨어는 원시 데이터를 수신하고, 마지막 미들웨어는 대상 핸들러에 전달합니다. JetBrains (2026)에 따르면, 이 아키텍처는 기존 코드를 변경하지 않고 미들웨어를 추가하거나 제거할 수 있어 테스트 및 실험적 모듈의 A/B 테스트를 간소화합니다.

Interceptor와의 차이점

미들웨어는 일반적인 패턴이고, Interceptor는 HTTP를 위한 특수 케이스입니다. 미들웨어는 모든 데이터 흐름(Redux의 actions, Bloc의 이벤트, Ktor의 HTTP 요청)에서 작동합니다. Interceptor는 항상 네트워크 계층에 바인딩되며 Request/Response만 처리합니다. 이 차이점을 이해하면 올바른 추상화를 선택하는 데 도움이 됩니다: 사용자 작업 로깅에는 미들웨어, 헤더 추가에는 Interceptor. 대규모 프로젝트에서는 두 패턴이 공존하는 경우가 많으며, 미들웨어가 상태를 관리하고 Interceptor가 HTTP 통신을 처리합니다.

상태 관리에서의 미들웨어

Redux 미들웨어는 reducer에 도달하기 전에 각 dispatch action을 가로챕니다. 이를 통해 actions 로깅, Redux Thunk 또는 Redux Saga를 통한 비동기 요청 실행, action 수정 또는 조건부 취소가 가능합니다. 각 미들웨어는 store(상태 접근), next(다음 미들웨어 또는 reducer 참조) 및 action을 수신하고, action을 전달할지, 수정할지, 차단할지 결정합니다.

Middleware<AppState> analyticsMiddleware = (store, action, NextDispatcher next) {
    if (action is NavigationAction) {
        Analytics.logEvent(action.screenName);
    }
    return next(action);
};

final store = Store<AppState>>(
    reducer,
    initialState,
    middleware: [analyticsMiddleware]
);

Flutter Redux용 Dart의 analyticsMiddleware 예제. 미들웨어는 모든 NavigationAction을 가로채서 화면 이름을 분석 시스템에 기록하고 next(action)을 호출하여 체인을 계속합니다. next가 호출되지 않으면 action이 reducer에 도달하지 않습니다 — 이를 통해 조건부 탐색을 구현하거나 원치 않는 actions을 차단할 수 있습니다. 배열의 미들웨어 순서가 처리 순서를 결정합니다.

비동기 미들웨어: Thunk 및 Saga

Redux Thunk는 action 객체뿐만 아니라 함수도 dispatch할 수 있는 미들웨어입니다. 함수는 dispatch와 getState를 수신하고, 비동기 작업(HTTP 클라이언트를 통한 API 요청, DB 읽기)을 수행하고 완료 시 일반 actions을 dispatch할 수 있습니다. 이는 Redux 애플리케이션에서 네트워크 요청의 표준 접근 방식입니다. Redux Saga는 더 복잡한 시나리오(요청 취소, 경쟁 조건, 병렬 작업, 사용자 입력 디바운스)를 위해 생성기(yield)를 사용합니다. Redux Saga (2026)에 따르면, Saga 코루틴은 중첩된 Thunk 콜백보다 테스트 및 디버그가 더 쉽습니다.

HTTP 클라이언트에서의 미들웨어

Ktor Client(JetBrains)는 파이프라인 미들웨어를 기반으로 HTTP 처리를 구축합니다. 요청의 각 단계(연결 설정, 헤더 전송, 응답 읽기)는 파이프라인의 개별 단계로 표시됩니다. 개발자는 client.install { }을 통해 플러그인(미들웨어)을 설치하여 처리 체인을 얻습니다. 설치 순서에 따라 Logging, Auth, ContentNegotiation, Caching 중 어떤 미들웨어가 먼저 데이터를 처리할지 결정됩니다.

val client = HttpClient {
    install(Logging) {
        level = LogLevel.BODY
    }
    install(Auth) {
        bearer {
            loadTokens { BearerTokens("access", "refresh") }
        }
    }
    install(ContentNegotiation) {
        json(Json { ignoreUnknownKeys = true })
    }
    install(HttpTimeout) {
        requestTimeoutMillis = 15000
    }
}

설치된 미들웨어 플러그인이 있는 Ktor Client 구성. Logging — 요청 및 응답 본문 기록. Auth — 리프레시 지원과 함께 Bearer 토큰 자동 추가. ContentNegotiation — JSON 직렬화/역직렬화. HttpTimeout — 타임아웃 설정. 각 플러그인은 독립적이며, 테스트 환경에서는 요청 코드를 변경하지 않고 클라이언트 구성을 교체하여 Auth를 비활성화할 수 있습니다.

Flutter의 Dio Interceptor

Dio는 Flutter에서 널리 사용되는 HTTP 클라이언트로, Interceptor를 미들웨어로 사용합니다. Interceptor는 전송 전에 RequestOptions를, 수신 후에 Response를 가로채며, 여러 인터셉터의 체인을 지원합니다. Dio Interceptor는 Dart/Flutter의 OkHttp Interceptor와 유사합니다. Dio (2026)에 따르면, RetryInterceptor와 LogInterceptor는 Flutter 프로젝트에서 가장 많이 사용되는 미들웨어입니다.

Bloc 아키텍처에서의 미들웨어

Bloc에는 별도 구성 요소로서의 내장 미들웨어가 없지만, 패턴은 BlocObserver(애플리케이션의 각 블록에서 이벤트를 수신하는 전역 옵저버)를 통해 구현됩니다. BlocObserver.onEvent는 각 이벤트 처리 전에, onTransition는 각 상태 전환 시, onError는 각 예외 시 호출됩니다. 이는 분석, 로깅, 크래시 리포팅 및 성능 모니터링을 위한 완전한 미들웨어입니다.

class AppBlocObserver extends BlocObserver {
    @override
    void onEvent(Bloc bloc, Object? event) {
        Crashlytics.log("${bloc.runtimeType}: $event");
        super.onEvent(bloc, event);
    }

    @override
    void onTransition(Bloc bloc, Transition transition) {
        Analytics.log(transition.eventName());
        super.onTransition(bloc, transition);
    }

    @override
    void onError(Bloc bloc, Object error, StackTrace stackTrace) {
        Crashlytics.recordError(error, stackTrace);
        super.onError(bloc, error, stackTrace);
    }
}

BlocOverrides.runZoned(() {
    runApp(MyApp());
}, blocObserver: AppBlocObserver());

Dart의 Bloc을 위한 AppBlocObserver 예제. onEvent는 각 이벤트를 Crashlytics에 기록하고, onTransition는 이벤트를 분석에 전송하며, onError는 예외를 크래시 리포트에 기록합니다. BlocOverrides.runZoned를 통한 연결은 코드를 변경하지 않고 모든 블록에 대해 옵저버를 전역으로 만듭니다. 테스트에서 비활성화하려면 빈 옵저버를 전달하거나 BlocOverrides를 재정의하지 않으면 됩니다.

미들웨어 적용 시기와 방법

미들웨어는 효과적입니다. 많은 구성 요소에 영향을 미치는 작업(로깅, 인증, 분석, 캐싱, 성능 모니터링)에 적합합니다. 동일한 로직이 애플리케이션의 여러 부분에서 반복되는 경우(각 요청에 토큰 추가, 각 사용자 작업 기록, 각 화면 전환 분석) 미들웨어를 사용합니다. Dio (2026)에 따르면, 미들웨어를 통한 중앙 집중식 처리는 각 구성 요소에서 개별적으로 코드를 중복하는 것보다 버그를 25% 줄입니다.

• 남용하지 마세요 — 과도한 미들웨어는 디버깅을 복잡하게 하고 추가 호출로 인해 성능을 저하시킵니다
• 순서가 중요합니다 — 첫 번째 미들웨어는 원래 형태로 데이터를 수신하고, 마지막 미들웨어는 모든 수정 후 수신합니다
• 비동기 작업 — 기본 UI 스레드를 차단하지 않고 무거운 호출을 비동기 미들웨어로 오프로드합니다
• 테스트 용이성 — 각 미들웨어는 모크 환경을 통해 격리되어 테스트되어야 합니다
• 체인 문서화 — 프로젝트에서 어떤 미들웨어가 어떤 순서로 연결되어 있는지 명확히 설명하세요

미들웨어 사용 시 흔한 실수

가장 흔한 실수는 잘못된 미들웨어 순서로, 첫 번째 인터셉터가 두 번째가 추가하는 데이터를 기대하는 경우입니다. 두 번째로 흔한 실수는 메인 스레드에서 미들웨어의 차단 작업(파일 쓰기, 동기 HTTP 호출, 암호화)입니다. 세 번째는 예외 처리 부재로, 미들웨어가 예외를 던지면 전체 체인이 끊어져 action이 reducer에 도달하지 않거나 요청이 전송되지 않습니다. 항상 미들웨어 로직을 try-catch로 래핑하고 체인을 끊지 않고 Crashlytics 또는 Sentry에 오류를 기록하세요. 코드 리뷰 중에 정기적으로 미들웨어 체인을 확인하여 아키텍처 저하를 방지하세요.