오늘도 더 나은 코드를 작성하였습니까?

State Pattern(feat. kotlin)

hik14 — Thu, 21 May 2026 16:21:32 +0900

정의

State Pattern은 객체의 내부 상태에 따라 행동이 바뀌어야 할 때 사용하는 행동 디자인 패턴입니다. 객체가 마치 자신의 클래스를 바꾼 것처럼 보이게 만드는 게 핵심이다.

언제 사용하는지?

when이나 if-else로 상태를 분기하는 코드가 여러 메서드에 흩어져 있을 때가 가장 명확한 신호입니다. 예를 들어 결제 화면에서 PENDING, PROCESSING, SUCCESS, FAILED 상태마다 버튼 클릭, 화면 이탈, 재시도 동작이 다르다면 — 각 메서드마다 when (state) 분기가 반복됩니다. 상태가 하나 추가될 때마다 모든 메서드를 수정해야 하니 OCP(개방-폐쇄 원칙)를 위반하게 되고, 수정범위가 많아진다. "그냥 enum class XXXStatus로 충분하지 않나?" 싶을 수 있는데, 명확한 차이가 존재한다. enum + when 분기는 상태 값만 표현하지만, State 패턴은 상태 + 그 상태의 행동을 함께 캡슐화합니다. 각 상태마다 허용/금지되는 행동이 많고, 전이 규칙이 복잡할수록 State 패턴의 가치가 커집니다. 반대로 상태가 단순한 라벨 역할만 한다면 enum이 더 적절합니다.

트레이드오프

장점: 상태별 행동이 응집됨, 새 상태 추가가 OCP를 따름, 거대한 when 블록 제거
단점: 클래스가 늘어남, 상태 전이의 흐름을 따라가려면 여러 파일을 봐야 함 (특히 상태가 4~5개 이상일 때)

클래스 다이어그램

Context: 현재 상태를 들고 있는 객체. 외부에서 보는 인터페이스.
State (인터페이스): 상태별로 달라지는 행동을 정의 및 캡슐화.
ConcreteState: 각 상태의 구체적인 행동 구현. 필요하면 다음 상태로의 전이도 담당.

// ============================================================
// State 인터페이스
// ============================================================
sealed interface PaymentState {
    fun pay(context: PaymentContext)
    fun approve(context: PaymentContext)
    fun fail(context: PaymentContext, reason: String)
    fun retry(context: PaymentContext)
}

package org.example

// ============================================================
// ConcreteStates
// ============================================================

// 결제 대기
object IdleState : PaymentState {
    override fun pay(context: PaymentContext) {
        println("[${context.orderId}] 결제 요청 시작")
        context.transitionTo(ProcessingState)
    }
    override fun approve(context: PaymentContext) = reject("결제 시작 전입니다")
    override fun fail(context: PaymentContext, reason: String) = reject("결제 시작 전입니다")
    override fun retry(context: PaymentContext) = reject("재시도할 결제가 없습니다")
}

// 결제 처리 중 (PG사 응답 대기)
object ProcessingState : PaymentState {
    override fun pay(context: PaymentContext) = reject("이미 처리 중입니다 (중복 요청 차단)")

    override fun approve(context: PaymentContext) {
        println("[${context.orderId}] PG 승인 완료")
        context.transitionTo(SuccessState)
    }

    override fun fail(context: PaymentContext, reason: String) {
        println("[${context.orderId}] 결제 실패: $reason")
        context.transitionTo(FailedState)
    }

    override fun retry(context: PaymentContext) = reject("처리 중에는 재시도할 수 없습니다")
}

// 결제 실패
object FailedState : PaymentState {
    override fun pay(context: PaymentContext) = reject("실패 상태에서는 retry()로 재시도하세요")
    override fun approve(context: PaymentContext) = reject("실패한 결제는 승인할 수 없습니다")
    override fun fail(context: PaymentContext, reason: String) = reject("이미 실패 상태입니다")

    override fun retry(context: PaymentContext) {
        println("[${context.orderId}] 재시도 시작")
        context.transitionTo(ProcessingState)
    }
}

// 결제 성공 (종료 상태)
object SuccessState : PaymentState {
    override fun pay(context: PaymentContext)                   = reject("이미 완료된 결제입니다")
    override fun approve(context: PaymentContext)               = reject("이미 승인된 결제입니다")
    override fun fail(context: PaymentContext, reason: String)  = reject("이미 완료된 결제입니다")
    override fun retry(context: PaymentContext)                 = reject("완료된 결제는 재시도할 수 없습니다")
}

private fun reject(msg: String) {
    println("  ↳ 거부: $msg")
}

// ============================================================
// Context
// ============================================================
class PaymentContext(val orderId: String) {

    var state: PaymentState = IdleState
        private set

    fun transitionTo(next: PaymentState) {
        println("[$orderId] ${state::class.simpleName} → ${next::class.simpleName}")
        state = next
    }

    // 외부에서 호출하는 행동 — 모두 현재 state에 위임
    fun pay() = state.pay(this)
    fun approve() = state.approve(this)
    fun fail(reason: String) = state.fail(this, reason)
    fun retry() = state.retry(this)
}

fun main() {
    // 시나리오 1: 정상 흐름
    val payment1 = PaymentContext("ORDER-001")
    payment1.pay()       // Idle → Processing
    payment1.pay()       // 거부: 이미 처리 중 (중복 차단)
    payment1.approve()   // Processing → Success
    payment1.retry()     // 거부: 완료된 결제

    println()

    // 시나리오 2: 실패 후 재시도
    val payment2 = PaymentContext("ORDER-002")
    payment2.pay()                      // Idle → Processing
    payment2.fail("카드 한도 초과")      // Processing → Failed
    payment2.retry()                    // Failed → Processing
    payment2.approve()                  // Processing → Success
}

중복 결제 방지가 됨: ProcessingState.pay()가 reject로 처리하기 때문에, UI에서 사용자가 결제 버튼을 두 번 눌러도 두 번째 요청은 자연스럽게 차단됩니다. Context 쪽에 if (isProcessing) return 같은 플래그 체크를 흩어둘 필요가 없어요.

전이 규칙이 한 곳에 모임: "어떤 상태에서 어떤 액션이 허용되는가"가 각 State 객체의 메서드 구현으로 표현됩니다. 새 상태(예: CancelledState, RefundedState)를 추가할 때 기존 코드를 거의 건드리지 않습니다.

sealed interface + object 조합: 상태가 내부 데이터를 갖지 않으므로 object(싱글톤)로 충분합니다. 만약 실패 사유나 트랜잭션 ID 같은 상태별 데이터가 필요하다면 object 대신 data class로 바꾸고, sealed interface가 컴파일러의 when exhaustive 체크까지 받쳐줍니다.

안드로이드 개발에서 사용하는 캐싱 전략2

hik14 — Tue, 19 May 2026 17:26:52 +0900

Room Offline Cache

Room을 SSOT(Single Source of Truth)로 사용한다.

UI는 항상 Room에서만 읽고, 네트워크는 Room을 업데이트하는 용도로만 씁니다.

오프라인 자동 지원
로딩/에러와 데이터 표시 분리 가능
네트워크 실패해도 캐시된 화면 유지
화면 회전, 다른 화면에서 돌아와도 즉시 표시

@Entity(tableName = "orders")
data class OrderEntity(
    @PrimaryKey val id: String,
    val amount: Long,
    val status: String,
    val createdAt: Long,

    // --- 캐시 메타데이터 ---
    val cachedAt: Long,           // 캐시 시각
    val etag: String? = null,     // 서버 ETag (HTTP 304 활용)
    val isStale: Boolean = false  // 강제 새로고침 필요 플래그
)

@Dao
interface OrderDao {
    @Query("SELECT * FROM orders ORDER BY createdAt DESC")
    fun observeAll(): Flow<List<OrderEntity>>

    @Query("SELECT * FROM orders WHERE id = :id")
    fun observeById(id: String): Flow<OrderEntity?>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun upsertAll(orders: List<OrderEntity>)

    @Query("SELECT MAX(cachedAt) FROM orders")
    suspend fun lastCachedAt(): Long?

    @Query("DELETE FROM orders WHERE cachedAt < :threshold")
    suspend fun deleteOlderThan(threshold: Long)
}

여러가지 패턴들

패턴 A: Cache-First (캐시 우선)

"캐시가 신선하면 그냥 보여주고, 오래됐을 때만 새로 가져온다"

실행 순서

UI가 데이터를 요청한다
Room의 캐시를 확인한다
캐시의 cachedAt(저장 시각)을 본다
현재 시각과 비교해서 TTL(예: 5분) 이내면 → 캐시 그대로 반환, 끝
TTL이 지났으면 → 네트워크 호출 → Room 갱신 → 반환

특징

빠름 (대부분의 경우 네트워크 안 탐)
데이터가 5분 정도 오래돼도 괜찮은 화면에 적합
첫 진입 시에도 캐시가 있으면 네트워크 호출 없음

적합한 화면

상품 카테고리 목록 (자주 안 바뀜)
사용자 프로필
공지사항

부적합한 화면

실시간 잔액, 재고
결제 직전 화면

패턴 B: NetworkBoundResource (캐시 + 네트워크 동시 노출)

"캐시를 먼저 보여주고, 네트워크 결과는 로딩 상태와 함께 따로 알려준다"

실행 순서

UI가 데이터를 요청한다
즉시 캐시를 Loading(데이터 있음) 상태로 내보낸다 → 사용자는 일단 화면을 본다
동시에 캐시가 신선한지 판단한다(shouldFetch)
신선하지 않으면 네트워크 호출
- 성공: Room에 저장 → Flow가 자동으로 Success로 전환
- 실패: Error(이전 캐시 데이터 포함)로 내보냄 → 사용자는 여전히 화면을 봄
신선하면 그대로 Success 유지

특징

UI가 로딩/성공/에러 + 데이터를 한 번에 받는다
로딩 인디케이터를 띄우면서도 이전 데이터를 계속 보여줄 수 있음 (Pull-to-refresh UX)
에러가 나도 캐시는 살아있음

적합한 화면

피드, 타임라인
새로고침 가능한 리스트 화면
검색 결과

핵심 가치

"로딩 중에 화면이 비어 보이는 문제"를 해결합니다. 캐시가 있으면 그걸로 즉시 채우고, 진짜 데이터는 뒤에서 채워옵니다.

패턴 C: Cache-Then-Network / Stale-While-Revalidate (SWR)

"오래된 캐시라도 즉시 보여주고, 뒤에서 조용히 새로 가져온다"

실행 순서

UI가 데이터를 요청한다
캐시를 즉시 내보낸다 (신선도 따지지 않음)
동시에 백그라운드에서 네트워크 호출
네트워크 성공 → Room 갱신 → Flow가 자동으로 새 데이터로 업데이트
네트워크 실패 → 조용히 무시 (이미 캐시는 보여주고 있으니까)

특징

가장 빠른 첫 화면 표시
사용자 입장에서는 "즉시 떴다가, 잠시 후 살짝 갱신되는" 경험
네트워크 에러를 UI에 노출하지 않음 (좋은 점이자 나쁜 점)

	패턴 B	패턴 C
캐시 신선도 체크	O	X (무조건 갱신)
로딩 상태 노출	O	X
에러 노출	O	X (조용히 실패)

적합한 화면

홈 피드, 대시보드
이미지 썸네일 리스트
자주 보지만 정확도가 절대적이지 않은 화면

부적합한 화면

사용자가 "새로고침했는데 안 됐다"는 걸 알아야 하는 화면
결제, 금액 표시

패턴 D: Network-First (네트워크 우선, 결제 도메인 권장)

"무조건 서버에서 최신 데이터를 받는다. 캐시는 fallback도 안 한다"

실행 순서

UI가 데이터를 요청한다 (예: 결제 진행 직전 주문 정보)
무조건 네트워크 호출
성공 → Room 갱신 → 반환
실패 → 캐시로 폴백하지 않고 그냥 에러 ("네트워크 필요" 화면 표시)

왜 캐시로 fallback하면 안 되는가

결제 화면에서 상품 가격이 캐시 시점(예: 5분 전)에는 10,000원이었는데, 지금은 12,000원으로 바뀌었다면?
캐시를 보여주고 결제 진행하면 → 사용자가 잘못된 금액을 승인하게 됨 → 분쟁/환불 사유
재고도 마찬가지: 캐시에는 "재고 있음"이었지만 지금은 품절일 수 있음

특징

가장 느린 패턴 (항상 네트워크 대기)
가장 정확한 패턴
오프라인이면 진행 불가 (의도된 동작)

적합한 시나리오

결제 직전 최종 확인 화면
잔액 조회
한도 확인
주문 생성 직전

패턴	첫 화면 표시	정확성	오프라인	대표 사용처
A. Cache-First	빠름	중간	가능	상품 카테고리, 프로필
B. NetworkBoundResource	빠름	높음	가능 (에러 노출)	피드, 리스트
C. SWR (Cache-Then-Network)	가장 빠름	낮음~중간	가능 (에러 숨김)	홈, 대시보드
D. Network-First	느림	가장 높음	불가	결제, 잔액

패턴 선택 의사결정 순서

이 데이터가 stale이면 사용자에게 실질적 피해(금전적/거래 분쟁)가 발생하는가?
- Yes → 패턴 D (Network-First)
- No → 다음 단계로
사용자가 새로고침 결과(성공/실패)를 명확히 알아야 하는가?
- Yes → 패턴 B (NetworkBoundResource)
- No → 다음 단계로
첫 화면을 즉시 보여주는 게 가장 중요한가? 약간 오래된 데이터도 OK인가?
- Yes → 패턴 C (SWR)
- No → 패턴 A (Cache-First)

결제 앱에서의 조합 예시

화면	패턴
홈 (최근 거래, 배너)	C - SWR
거래 내역 리스트	B - NetworkBoundResource
거래 상세 보기	A - Cache-First (5분 TTL)
잔액 표시	D - Network-First
결제 진행 화면	D - Network-First
상품 카테고리	A - Cache-First (1시간 TTL)
사용자 프로필	A - Cache-First

정리

캐시 패턴은 "어느 게 좋다"가 아니라 화면별 요구사항에 따라 다르게 적용하는 것입니다. 핵심은 두 가지 축:

속도 (캐시 즉시 노출) vs 정확성 (서버 우선)
에러 노출 (사용자에게 알림) vs 에러 숨김 (조용히 처리)

동작

12:00  캐시 저장  →  expiresAt = 12:05
12:03  요청        →  아직 12:05 안 됨   →  캐시 사용
12:06  요청        →  12:05 지났음        →  만료, 새로 가져옴

TTL 길이 선택 기준

데이터 종류권장	TTL
거의 안 바뀌는 메타데이터 (카테고리, 약관)	1시간 ~ 1일
가끔 바뀌는 정보 (프로필, 설정)	5~30분
자주 바뀌는 정보 (피드, 알림)	30초 ~ 5분
실시간 데이터 (잔액, 재고)	TTL 쓰지 않음 (Network-First)

2. TTI (Time-To-Idle) — 마지막 접근 기준

"자주 보는 데이터는 살려두고, 안 보는 데이터만 비움"

동작

12:00 캐시 저장

12:03 읽음 → 만료 카운터 리셋

12:08 읽음 → 만료 카운터 리셋

(10분지남)

12:18 10분간 안 읽힘 → 만료

적합한 데이터

메모리 캐시(LruCache, Caffeine)
자주 보는 항목은 계속 살려두고 싶을 때

	TTL	TTI
기준	저장 시각	마지막 접근 시각
자주 접근하면?	그래도 만료됨	계속 살아있음
신선도 보장	강함	약함

3. ETag / Last-Modified — 서버 검증 기반

"TTL 지나면 서버에 '바뀐 거 있어?'라고 물어봄"

동작

1. 캐시 만료 (TTL 지남)
2. 서버에 요청 보낼 때 헤더 추가:
   If-None-Match: "abc123"   ← 내가 가진 ETag
3. 서버 응답:
   - 304 Not Modified  →  본문 없음, "안 바뀜" → 캐시 그대로 사용
   - 200 OK            →  새 본문 + 새 ETag → 캐시 갱신

장점

안 바뀐 데이터는 본문 다운로드 안 함 → 트래픽 절약
TTL보다 정확함

적합한 데이터

큰 데이터 (이미지, 상세 정보)
변경 빈도가 낮지만 정확성도 필요한 경우

4. 이벤트 기반 무효화 — 능동적 만료 (안드로이드에서 개발자가 가장 많이 신경써야 하는 부분)

"특정 사건이 일어나면 캐시를 즉시 stale로 표시"

시간이 아니라 사건으로 만료시킵니다.

트리거 예시

이벤트	무효화 대상
사용자 로그아웃	사용자 관련 캐시 전부
주문 생성 완료	주문 리스트 캐시
결제 성공	잔액, 거래 내역 캐시
푸시 알림 수신	알림 관련 캐시
Pull-to-refresh	해당 화면 캐시
앱이 백그라운드 → 포그라운드	홈 화면 캐시

동작 방식 두 가지

A. 즉시 삭제

이벤트 발생 → dao.deleteAll() → 다음 요청 시 새로 가져옴

B. Stale 플래그만 세움

이벤트 발생 → dao.markAllStale() (isStale=true)
다음 요청 시 isStale 보고 새로 가져옴

*B 방식은 캐시를 즉시 비우지 않아 백그라운드 갱신 동안 이전 데이터를 보여줄 수 있습니다.

5. Stale-While-Revalidate (SWR)

"만료됐어도 일단 보여주고, 뒤에서 새로 가져온다"

엄밀히는 만료 정책이라기보다 만료된 데이터의 활용 정책입니다.

동작

캐시 상태: stale (TTL 지남)
요청 시
  1. 일단 stale 데이터를 즉시 반환  →  사용자는 화면을 본다
  2. 동시에 백그라운드에서 fetch
  3. fetch 결과로 캐시 갱신  →  Flow를 통해 UI 자동 업데이트

적합한 데이터

첫 화면 속도가 중요한 경우
약간 오래돼도 큰 문제 없는 경우

캐시 정책별 빈도·중요도·구현 주체 매트릭스

정책 코드 등장 빈도. 사용자 체감 중요도빠지면 생기는 일구현 주체

정책	코드 등장 빈도	사용자 체감 중요도	빠지면 생기는 일	구현 주체
LRU	매우 높음	낮음 (자동)	메모리 부족, OOM	라이브러리 (Coil/Glide, OkHttp, LruCache, Caffeine)
TTL	매우 높음	중간	데이터가 영원히 안 갱신됨	반반 (HTTP는 서버+OkHttp / Room 캐시는 개발자)
이벤트 기반	높음	매우 높음	즉각적인 버그, 클레임	개발자 (도메인 로직이라 자동화 불가)
ETag	중간	낮음	트래픽 증가	반반 (서버가 헤더 주면 OkHttp/Ktor가 자동 처리)
SWR	중간	중간	첫 화면 느림	개발자 (Repository에서 흐름 직접 설계)

안드로이드 개발에서 사용하는 캐싱 전략1

hik14 — Tue, 19 May 2026 16:22:27 +0900

Cache란?

캐시(Cache)는 자주 사용되는 데이터를 빠르게 접근할 수 있는 임시 저장 공간에 보관하는 기술입니다. 원본 데이터 소스(디스크, 네트워크, DB 등)보다 접근 속도가 빠른 곳(메모리 등)에 데이터를 두어 반복적인 요청의 응답 시간을 단축시킵니다. Android에서는 LruCache(메모리 캐시), OkHttp Cache(네트워크 응답 캐시), Room 등을 활용해 성능과 사용자 경험을 개선합니다.

in-memory cache

In-memory cache는 앱 프로세스의 RAM에 데이터를 보관하는 방식으로, 접근 속도가 매우 빠르지만 앱 종료나 OS의 메모리 회수 시 사라집니다. 용도에 따라 적절한 도구를 선택하는 것이 핵심입니다.

1. 이미지 캐싱 (Coil / Glide)

- 이미지는 크기가 크고 디코딩 비용이 비싸기 때문에 전용 라이브러리를 쓰는 것이 표준입니다. 두 라이브러리 모두 메모리 캐시 + 디스크 캐시 2단계를 자동으로 관리합니다.

Coil

// 기본 사용 - 캐시 자동 처리
AsyncImage(model = url, contentDescription = null)

// 전역 설정
val imageLoader = ImageLoader.Builder(context)
    .memoryCache {
        MemoryCache.Builder(context)
            .maxSizePercent(0.25)  // 가용 메모리의 25%
            .build()
    }
    .build()

// 캐시 정책 개별 제어
imageView.load(url) {
    memoryCachePolicy(CachePolicy.ENABLED)
    diskCachePolicy(CachePolicy.ENABLED)
}

Glide

Glide.with(context)
    .load(url)
    .diskCacheStrategy(DiskCacheStrategy.ALL)
    .skipMemoryCache(false)
    .into(imageView)

2. Coroutine / Flow 기반 패턴

라이브러리 없이 직접 캐시 레이어를 만들 때 자주 쓰는 패턴. API 호출시에 사용한다.

class UserRepository {
    private val _users = MutableStateFlow<Map<String, User>>(emptyMap())
    val users: StateFlow<Map<String, User>> = _users.asStateFlow()

    suspend fun getUser(id: String): User {
        return _users.value[id] ?: api.fetchUser(id).also { user ->
            _users.update { it + (id to user) }
        }
    }
}

3. Paging3 - cachedIn

cachedIn(scope)의 scope가 캐시의 생명주기를 결정한다. 일반적으로 viewModelScope 캐싱한다.

Configuration Change 시 처음부터 다시 로드

사용자가 100번째 아이템까지 스크롤한 상태에서 화면을 회전할때 cachedIn 없다면

Activity가 재생성됨
Fragment/Activity/Compose가 다시 collectLatest로 구독
cold flow이므로 PagingSource가 처음부터 다시 실행
1페이지부터 다시 로드, 사용자는 맨 위로 돌아감

cachedIn(viewModelScope)로 사용

Activity가 재생성됨
ViewModel은 살아있고, 캐시된 PagingData도 메모리에 있음
새 구독자는 이미 로드된 100개 데이터를 그대로 받음

class ProductViewModel(repo: ProductRepository) : ViewModel() {
    val products: Flow<PagingData<Product>> = Pager(
        config = PagingConfig(pageSize = 20),
        pagingSourceFactory = { repo.getProductPagingSource() }
    ).flow
        .cachedIn(viewModelScope)  // ← 핵심
}

여러 구독자가 있으면 크래시

같은 Flow<PagingData>를 두 곳에서 구독하면 Paging3는 런타임 예외를 던집니다.

cachedIn은 내부적으로 SharedFlow 형태로 변환해서 여러 구독자가 같은 데이터를 공유할 수 있게 만들어줍니다.

// ⚠️ cachedIn 없이
viewModel.products.collectLatest { adapter1.submitData(it) }
viewModel.products.collectLatest { adapter2.submitData(it) }  //   크래시

viewModelScope에 캐싱했기 때문에 ViewModel이 살아있는 동안 PagingData가 메모리에 유지됩니다. ViewModel이 onCleared()로 사라지면 캐시도 함께 정리되어 메모리 누수가 없습니다.

DataStore(Sharedpreferences) cache

DataStore는 SharedPreferences의 후속으로, 작은 키-값 데이터를 비동기로 안전하게 저장하기 위한 라이브러리입니다.

캐시라고 부르긴 하지만 실제로는 영속 저장소이며, 그 특성을 이해해야 어떤 데이터를 둘지 결정할 수 있습니다.

특성	내용
저장 방식	파일 기반 (Preferences는 XML 유사, Proto는 바이너리)
접근	Flow 기반 비동기
트랜잭션	O (원자적 업데이트 보장)
크기 한계	전체 파일을 메모리에 로드 — 작아야 함
쿼리	불가 (전체 읽기만)
동시성	Coroutine

사용자 환경설정

val Context.settingsDataStore by preferencesDataStore("settings")

object SettingsKeys {
    val DARK_MODE = booleanPreferencesKey("dark_mode")
    val LANGUAGE = stringPreferencesKey("language")
    val FONT_SCALE = floatPreferencesKey("font_scale")
    val NOTIFICATION_ENABLED = booleanPreferencesKey("notification_enabled")
}

다크모드, 언어, 폰트 크기, 알림 on/off
화면별 UI 옵션상태 (탭 선택, 정렬 순서, 필터 옵션)

인증/세션 메타데이터

object AuthKeys {
    val ACCESS_TOKEN = stringPreferencesKey("access_token")
    val REFRESH_TOKEN = stringPreferencesKey("refresh_token")
    val TOKEN_EXPIRES_AT = longPreferencesKey("token_expires_at")
    val USER_ID = stringPreferencesKey("user_id")
}

토큰, 토큰 만료 시간, 로그인 상태
토큰은 EncryptedSharedPreferences 또는 Android Keystore로 암호화 저장 권장.다.

앱 상태 플래그

온보딩 완료 여부 (최초 앱실행)
튜토리얼 표시 여부
"이 메시지 다시 보지 않기" 플래그
마지막 앱 버전 (마이그레이션 트리거용)
첫 실행 여부

개발자가 알아야 하는 숫자1 - Latency Numbers (Android 개발)

hik14 — Mon, 18 May 2026 18:46:32 +0900

전력망 60Hz에서 시작

미국/한국 전력은 60Hz, 유럽은 50Hz
1930년대 아날로그 TV가 화면 새로 고침을 전력 주파수에 맞춤

* 60Hz => 1초에 60번 진동

인간 시각과 우연히 맞음

프레임률	인식
24 fps	영화 (모션 블러로 보정)
30 fps	가끔 끊김
60 fps	대부분 부드럽다고 인식
120 fps+	한계효용 급감

인간 시각 처리 한계가 60~80Hz 근처라, 60Hz가 "부드러움의 임계선"과 자연스럽게 맞았음.

1개의 프레임이 렌더링 되는 시간

1초 = 1,000 ms 이고 프레임은 1개의 화면

1,000 ms / 60 frames

=> 16.666... ms

안드로이드의 16.6ms — Project Butter (2012)

안드로이드에서 16.6ms가 공식적인 성능 목표가 된 건 2012년 Google I/O의 "Project Butter" 발표부터입니다. Android 4.1 Jelly Bean. 이전 Android는 프레임률이 들쭉날쭉했는데, Project Butter가 도입한 핵심 개념이:

(1) VSync 동기화

화면 새로 고침(60Hz)에 맞춰 정확히 16.6ms마다 한 프레임씩 그리도록 강제. 이전엔 GPU가 빨리 그리면 빨리 보내고, 늦으면 늦게 보내서 tearing(찢김) 발생했음.

(2) Triple Buffering

CPU, GPU, 디스플레이가 동시에 일할 수 있게 버퍼 3개를 돌림. 이걸로 16.6ms 예산을 빈틈없이 활용.

(3) Choreographer

// Android 내부에서 16.6ms 타이밍을 관리하는 클래스
Choreographer.getInstance().postFrameCallback { frameTimeNanos ->
    // 매 프레임 호출되는 콜백
}

Choreographer가 16.6ms마다 신호를 보내고, 그 안에 모든 그리기 작업이 끝나야 한 프레임이 정상적으로 송출됩니다. 못 끝내면 그 프레임은 버려지고(=프레임 드롭), => 사용자는 끊김으로 인식.

이제는 60fps만이 표준이 아님

요즘 폰들은 더 빠른 디스플레이를 사용

주사율	한 프레임(렌더링 시간)	사용 기기
60Hz	16.6 ms	일반 폰, 대부분의 디스플레이
90Hz	11.1 ms	OnePlus 7 Pro 이후 일부
120Hz	8.3 ms	iPhone Pro, Galaxy S 시리즈, ProMotion
144Hz	6.9 ms	게이밍 폰

120Hz가 점점 표준이 되고 있어서 예산이 절반으로 줄어드는 추세:

같은 코드가 60Hz 폰에선 부드럽고 120Hz 폰에선 끊겨 보일 수 있음
고급 폰일수록 성능 요구사항이 더 빡빡해짐

출발점: 60fps = 한 프레임 16.6ms

안드로이드 UI가 부드럽게 보이려면 메인 스레드가 16.6ms마다 한 프레임씩 그려내야 합니다. 이 시간을 넘기면 사용자에겐 즉시 jank(끊김)로 보일수 있다. (120fps 기기는 더 빡빡해서 8.3ms)

시스템이 7~14ms를 먼저 가져갑니다. 복잡한 레이아웃은 더 많은 시간을 소요할수도 있습니다.

메인 스레드 최적화는 두 가지 방법.

시스템 시간을 줄인다 → 레이아웃 단순화, 뷰 계층 평탄화, ConstraintLayout 활용
우리 코드 시간을 줄인다 → 비동기로 빼기, 데이터 미리 준비, 캐싱

실무에서 중요한것은 무엇일까?

작업	1번 비용	예산(3~8ms) 안 가능 횟수
메모리 접근 (HashMap get)	100 ns	30,000~80,000번
StateFlow value 읽기	~200 ns	15,000~40,000번
Room 단순 쿼리 (suspend)	~50-100 μs	30~160번
Room JOIN/@Relation	~300 μs	약 10~25번
SharedPreferences apply()	~수십 μs (메모리만)	수백 번
SharedPreferences commit()	10~50 ms	0번
DataStore 읽기 (캐시 hit, Flow collect)	~수십 μs	수백 번(DataStore는 한번 읽으면 메모리에 캐싱)
DataStore 읽기 (첫 호출, 디스크에서 로드)	~5-20 ms	0~1번 (첫 호출만 )
DataStore 쓰기 (edit { })	~5-20 ms	0번
이미지 디코딩 (큰 이미지)	10~100 ms	0번
큰 JSON 파싱	5~50 ms	0번
서버 API 호출	50ms+	0번
디스크 동기 I/O (큰 파일)	수십 ms	0번

"0번"으로 표시된 작업은 메인 스레드 금지

1. 서버 API 호출

표에서 가능 횟수가 0번인 작업들이 메인 스레드 절대 금지 목록입니다. Coroutine 또는 다른 Thread로 작업한다.

1번 비용이 우리 예산(3~8ms)을 이미 넘기거나 거의 다 소모해버려서, 한 번만 실행해도 프레임이 깨집니다.

//   NetworkOnMainThreadException
val response = okHttpClient.newCall(request).execute()

// ✅ 코루틴 + Dispatchers.IO
viewModelScope.launch {
    val response = withContext(Dispatchers.IO) {
        okHttpClient.newCall(request).execute()
    }
}

2. 이미지 디코딩 (10~100ms) → 우리 예산의 1~30배

Coil 또는 Glide 와 같은 라이브러리 사용하여 비동기 처리. 절대로 메인 스레드에서 처리하면 안됨.

View든 Compose든 라이브러리를 사용하여 안전하게 처리한다.

//   직접 디코딩 - 큰 이미지면 100ms+
val bitmap = BitmapFactory.decodeFile(path)
imageView.setImageBitmap(bitmap)

// ✅ Coil
AsyncImage(
    model = file,
    contentDescription = null
)

3. 큰 JSON 파싱 (5~50ms) → 우리 예산의 1~10배

// ✅ Retrofit + suspend (자동으로 IO에서 실행)
@GET("/posts")
suspend fun getPosts(): List<Post>

4. SharedPreferences.commit() (10~50ms) → 우리 예산의 1~10배

//   메인 스레드 블로킹
prefs.edit().putString("key", value).commit()

// ✅ 비동기 디스크 쓰기 (메모리만 반영, 디스크는 백그라운드)
prefs.edit().putString("key", value).apply()

*commit()은 디스크 동기 쓰기라 10~50ms 걸리지만, apply()는 메모리만 건드리니까 수십μs(예산 안).

5. DataStore 쓰기 (5~20ms) → 우리 예산을 거의 다 먹음

//   DataStore는 컴파일 단에서 막혀있어서 메인 호출 자체가 불가
// suspend 함수만 제공
viewModelScope.launch {
    dataStore.edit { it[KEY] = value }
}

DataStore는 안전성을 위해 매 쓰기마다 디스크 sync 보장하니까 5~20ms => suspend로만 노출돼서 강제로 비동기

"30번 이상 가능"한 작업은 메인 스레드 OK

표에서 가능 횟수가 수백~수만 번인 작업들은 무조건 비동기로 뺄 필요 없어요. 모든 걸 코루틴으로 감싸는 게 능사가 아닙니다.

작업	가능 횟수	메인 스레드 판단
StateFlow value 읽기	15,000~40,000번	✅
HashMap/List get	30,000~80,000번	✅
SharedPreferences apply()	수백 번	✅
DataStore 읽기 (캐시 hit)	수백 번	✅ (다만 API는 suspend)
Room 단순 쿼리	30~160번	⚠️ 1~2번은 OK, 반복은 위험

ViewModel에서 StateFlow 값 읽어서 UI에 반영하는 정도는 메인 스레드 동기 처리로 충분합니다.

짧은 String 포맷팅, 작은 List map/filter도 마찬가지.

Room 단순 쿼리는 애매한 영역. 1번이면 50μs라 예산에 여유 있지만, 반복문에서 호출하면 금세 한도 넘어요. 그래서 Room은 무조건 suspend로 선언해서 컴파일러가 IO Dispatcher로 빼주게 하는 게 표준입니다.

RecyclerView 바인딩

onBindViewHolder는 한 프레임 안에 여러 번 호출됩니다. 그래서 표의 "3~8ms 예산"을 다시 바인딩 한 번당 1~2ms로 더 쪼개서 봐야 해요.

override fun onBindViewHolder(holder: ViewHolder, position: Int) {
    val item = items[position]
    
    //   동기 DB 조회 (50~100μs × 반복 = 위험)
    val detail = db.getDetail(item.id)
    
    //   이미지 메인 스레드 디코딩 (10~100ms = 즉사)
    holder.image.setImageBitmap(BitmapFactory.decodeFile(item.path))
    
    //   매번 SimpleDateFormat 생성 (각 ~수십 μs × N개)
    holder.date.text = SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(item.date)
}

private val dateFormatter = SimpleDateFormat("yyyy-MM-dd HH:mm:ss")  // 재사용

override fun onBindViewHolder(holder: ViewHolder, position: Int) {
    val item = items[position]  // 메모리 접근만 (100ns)
    
    holder.image.load(item.path)        // Coil이 백그라운드 처리
    holder.date.text = dateFormatter.format(item.date)  // 포맷터 재사용
    holder.title.text = item.title       // 단순 할당
}

콜드 스타트 — 16.6ms의 100~300배 예산

앱 시작은 1.5~2초 안에 첫 프레임이 그려져야 합니다.

1.5초면 약 90배, 2초면 약 120배, 5초(ANR 경고선)면 약 300배

표의 작업들이 누적되면, 한두 개는 OK지만 여러 개 쌓이면 1초 넘기는 경우가 많기 때문에 조심해야된다.

//   합치면 500ms+, 사용자는 빈 화면만 봄
class MyApp : Application() {
    override fun onCreate() {
        initFirebase()      // 100ms
        initAnalytics()     // 50ms
        initImageCache()    // 200ms (디스크 캐시 로드)
        initDatabase()      // 100ms (DB 파일 열기 ~ Room이라면 표의 "디스크 동기 I/O" 항목)
        initNetworking()    // 50ms
    }
}

해결: Jetpack App Startup으로 지연 초기화, Hilt @Singleton lazy 활용. "진짜 시작 시 필요한 것"과 "나중에 필요한 것"을 분리.

//   빈 화면 50~500ms (표에서 "서버 API 호출 50ms+")
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        viewModel.posts.observe(this) { /* API 응답 기다림 */ }
    }
}

Room 캐시(50~100μs)에서 즉시 보여주고, API는 백그라운드. 표 기준으로 보면 API 50ms 대신 Room 100μs로 500배 빠르게 첫 화면 표시.

// Repository
fun observePosts(): Flow<List<Post>> = flow {
    emitAll(postDao.observeAll())  // 즉시 emit (μs 단위)
}.onStart {
    refreshFromServer()  // 백그라운드 (ms 단위, 사용자는 모름)
}

한 줄 요약

메인 스레드 = 16.6ms 예산 = 우리 코드 3~8ms = 표의 "수십 번 이상" 작업만 자유롭게.

표 기준 0번 작업은 무조건 코루틴으로:

네트워크 → suspend + Retrofit
Room → suspend 또는 Flow
DataStore → suspend (API 자체가 강제)
이미지 디코딩 → Coil/Glide
JSON 파싱 → Retrofit이 IO에서
SharedPreferences → commit() 금지, apply() 사용
RecyclerView 바인딩 → 메모리 접근/단순 할당만

개발자가 알아야 하는 숫자1 - Latency Numbers

hik14 — Mon, 18 May 2026 16:10:52 +0900

작업	1993 (Norvig)	2009 (Jeff Dean)	2012 (SSD 시대)	2024 (NVMe 시대)
L1 캐시 참조	10 ns	0.5 ns	0.5 ns	0.5 ns
분기 예측 실패	—	5 ns	5 ns	3 ns
L2 캐시 참조	—	7 ns	7 ns	4 ns
Mutex lock/unlock	100 ns	25 ns	25 ns	17 ns
메인 메모리 참조	200 ns	100 ns	100 ns	80 ns
메모리 1MB 순차 읽기	5,000,000 ns (5,000 μs)	250,000 ns (250 μs)	250,000 ns (250 μs)	100,000 ns (100 μs)
1KB Zip 압축	—	3,000 ns (3 μs)	3,000 ns (3 μs)	2,000 ns (2 μs)
1Gbps로 1KB 전송	—	10,000 ns (10 μs)	10,000 ns (10 μs)	1,000 ns (1 μs, 10Gbps)
SSD 랜덤 읽기 (SATA)	없음	없음	150,000 ns (150 μs)	100,000 ns (100 μs)
SSD 랜덤 읽기 (NVMe)	없음	없음	없음	20,000 ns (20 μs)
SSD 1MB 순차 읽기	없음	없음	1,000,000 ns (1,000 μs)	50,000 ns (50 μs, NVMe)
같은 DtatCenter내 RTT	—	500,000 ns (500 μs)	500,000 ns (500 μs)	500,000 ns (500 μs)
HDD seek	10,000,000 ns (10,000 μs)	10,000,000 ns (10,000 μs)	10,000,000 ns (10,000 μs)	10,000,000 ns (10,000 μs)
HDD 1MB 순차 읽기	30,000,000 ns (30,000 μs)	20,000,000 ns (20,000 μs)	20,000,000 ns (20,000 μs)	20,000,000 ns (20,000 μs)
한국 ↔ 미국 RTT	200,000,000 ns (200,000 μs)	150,000,000 ns (150,000 μs)	150,000,000 ns (150,000 μs)	150,000,000 ns (150,000 μs)

중요하게 봐야할 것들

- 관통하는 통찰물리 한계 기반 숫자는 변하지 않는다 (빛의 속도, HDD 회전)

- 기술 기반 숫자만 격변한다 (SSD 등장으로 디스크 500배 빨라짐)

- 병목은 사라지지 않고 옮겨간다 (디스크에서 네트워크와 메모리로)

- 정확한 수치보다 자릿수(order of magnitude) 감각이 중요하다

- 표는 항상 만든 시점의 스냅샷 — 시간이 지나면 검증이 필요하다'

자릿수 감각 정리 및 무엇이 중요할까?

계층	단위	비유
L1 캐시	sub-ns	손에 들고 있음
메인 메모리	100 ns	책상 위
NVMe SSD	10~100 μs	같은 방 책장
SATA SSD	100 μs ~ 1 ms	옆방
HDD	10 ms	도서관 가서 찾기
같은 DataCenter 네트워크	500 μs	옆 사무실 전화
대륙 간 RTT	150 ms	해외로 편지

메모리 → NVMe SSD는 약 1,000배 차이입니다. 옛날엔 메모리 → HDD가 10만 배였으니, 격차가 100배 줄어든 것.

"RAM이 곧 디스크"라는 말이 어느 정도 농담이 아닌 시대.

Android 개발 관점에서 보면, Room에 로컬캐싱하는 이유.

모바일 NVMe(UFS 3.0~4.0)도 랜덤 읽기가 수십μs 수준이라, 네트워크 한 번 다녀오는 것(수십 ms)보다 1000배 빠르다.

*"Room은 디바이스 내부 SQLite를 호출하니까 수 ms 수준(전형적으로 1~10ms, 단순 쿼리는 그보다 빠름)에 끝납니다."

이게 "로컬 캐싱이 압도적으로 유리한" 물리적 근거입니다.

작업	시간	의미	1초 기준 환산	체감
메인 메모리 접근	100 ns	가장 빠른 "데이터 가져오기"의 기준점. 모든 비교의 출발점.	1초	손가락 한 번 튕기기
NVMe SSD 랜덤 읽기	20,000 ns (20μs)	로컬 저장소의 현실. 모바일 UFS도 비슷한 수준.	3분 20초	라면 끓이기
같은 DC 내 RTT	500,000 ns (500μs)	마이크로서비스, Redis, DB 같은 백엔드 통신의 기준선.	1시간 23분	영화 한 편
한 프레임 (60fps)	16,666,666 ns (16.6ms)	UI가 안 끊기게 만들 시간 예산.	1일 22시간	주말
모바일 ↔ 서버 RTT	50,000,000 ns (50ms)	앱 → 서버 호출의 현실. 무선이 추가되는 순간 자릿수가 바뀜.	5일 19시간	휴가 일주일
대륙 간 RTT	150,000,000 ns (150ms)	글로벌 서비스 설계의 물리적 한계.	17일 8시간	보름 넘게

실무에서 이게 왜 중요한가

1. 마이크로서비스 호출 한 번 = 메모리 접근 5,000번

- 서비스 A가 서비스 B를 HTTP로 호출하면, 같은 DC 안이라도 최소 500μs는 깔립니다. 메모리에서 읽는 것보다 5,000배-6000배 느리다.

- "필요 없는 마이크로서비스 분리는 성능 재앙"

2. N+1 쿼리 문제 (서버, 로컬DB)

첫번째, 1번의 쿼리 100개의 게시글 가져오기

두번째, 100번의 쿼리 100개의 게시글의 각 작성자 가져오기.

// 1번째 쿼리: 게시글 100개 가져오기
val posts = postDao.getAllPosts() // SELECT * FROM Post LIMIT 100

// 그 다음 작성자 정보를 가져온다
posts.forEach { post ->
    // 2번째, 3번째, ..., 101번째 쿼리: 매번 작성자 조회
    val author = userDao.getUserById(post.userId) // SELECT * FROM User WHERE id = ?
    println("${post.title} by ${author.name}")
}

JOIN 쿼리가 조금 무거운 작업이라도 한 번이면 끝날 일.

서버(백앤드)

환경: 앱 서버 ↔ DB 서버가 같은 데이터센터에 있고, 둘 사이는 내부망 네트워크로 통신.

기준 시간: DB 쿼리 1번 ≈ 0.5 ms (DataCenter 내 RTT 500μs + 쿼리 처리 약간)

방식	총 쿼리 수	시간	체감
N+1번 쿼리	1 + 100 = 101번	약 50 ms	느리다고 인식 시작
JOIN 1번	1번	약 0.7 ms	즉각적

약 70배 더 걸림.

안드로이드 로컬 (Room)

환경: 앱 안에서 SQLite를 직접 호출. 네트워크 없음, 디바이스 내부 파일 접근만.

기준 시간: Room 단순 쿼리 1번 ≈ 50~100 μs (네트워크 없음, 디스크 접근 + 소프트웨어 스택)

방식	총 쿼리 수	시간	체감
N+1	1 + 100 = 101번	약 5-10 ms	위험 (프레임의 절반 이상)
JOIN(@Relation) 1번	1번	약 0.3 ms	여유 있음

약 20~30배 더 걸림.

3. 캐싱 판단의 기준선

"이 데이터를 Redis에 캐싱할 가치가 있나?"의 답이 여기서 나옵니다. Redis도 결국 네트워크(같은 DC RTT)호출이라 500μs 소요된다 그래서 **단순 메모리 캐시(앱 프로세스 내 HashMap)**가 Redis보다 압도적으로 빠릅니다. 다만 여러 서버가 공유해야 한다면 Redis로 가야한다

4. 모바일 앱(android native)에서는?

Android에서 서버 API 한 번 호출하면 보통 50ms 이상 깔립니다. (무선 구간 + 인터넷 구간 + 서버 처리가 다 포함)

반면 Room은 디바이스 내부 SQLite를 호출하니까 수 ms 수준(전형적으로 1~10ms, 단순 쿼리는 그보다 빠름)에 끝납니다. 무선도, 인터넷도, 서버 부하도 없이 그냥 UFS에서 파일 읽고 객체로 매핑하면 끝이니까요. 같은 데이터를 가져오는 데 자릿수가 한 단계 다른 비용이 들어갑니다. 이게 Single Source of Truth 패턴(네트워크는 백그라운드에서 Room에 동기화, UI는 Room만 본다)이 모던 안드로이드 아키텍처의 표준이 된 정량적 근거입니다.

도메인 주도 설계 (Domain Driven Design - DDD)의 이벤트 스토밍 개념정리2

hik14 — Mon, 18 May 2026 00:55:52 +0900

왜 이벤트 스토밍을 하는가

1. 도메인 전문가 및 기획, 개발자, QA의 언어 간극을 좁히기 위해

가장 큰 이유입니다. 보통 PM/기획자/현업 담당자가 들고 오는 요구사항 문서는 "사용자가 결제를 하면 주문이 처리된다" 같은 추상적인 문장이에요. 개발자는 이걸 받아서 머릿속으로 "그럼 이건 어떻게 분기하지?", "실패하면?", "동시 요청이면?" 같은 질문을 혼자 만들어내며 구현합니다. 결과적으로 개발자가 비즈니스를 추측하는 코드가 만들어지고, 나중에 "이거 그렇게 동작하면 안 되는데?" 하고 충돌이 발생한다.

이벤트 스토밍은 이 사람들을 한 방에 모아놓고, 벽에 포스트잇을 같이 붙이면서 "결제 요청됨 다음에 뭐가 발생해요?", "그때 PG사가 응답을 안 주면요?" 같은 질문을 그 자리에서 즉시 해결합니다. 추측 대신 합의.

2. 숨겨진 복잡성을 미리 드러내기 위해

요구사항 문서에는 "결제 처리" 한 줄로 끝나지만, 막상 이벤트 스토밍을 하면 빨간 Hotspot이 10개씩 붙습니다. "중복 결제 어떻게 막죠?", "타임아웃 처리는?", "PG사 장애 시 재시도는?" — 이 질문들이 개발 시작 전에 발견되는 게 핵심이에요. 코드를 다 짠 다음에 발견되면 비용이 100배가 됩니다.

3. 시스템 경계(Bounded Context)를 식별하기 위해

벽에 포스트잇을 다 붙이고 나면, 자연스럽게 "여기는 결제 영역", "여기는 주문 영역", "여기는 배송 영역" 처럼 응집된 덩어리가 보입니다. 이 덩어리들이 바로 Bounded Context이고, 마이크로서비스 분리나 모듈 경계의 근거가 됩니다. 추측이 아니라 도메인 자체의 모양을 따라가는 거죠.

4. 빠르고 저렴하다

UML이나 시퀀스 다이어그램을 그리려면 도구 띄우고 박스 위치 잡고 정렬하느라 시간이 가는데, 이벤트 스토밍은 포스트잇과 벽만 있으면 됩니다(요즘은 Miro/FigJam). 반나절~하루 안에 한 도메인이 정리되고, 틀렸으면 떼고 다시 붙이면 끝입니다. 진입 장벽이 낮아서 비개발자도 참여할 수 있어요.

결과물은 무엇인가

1. 도메인 이벤트 카탈로그

가장 직접적인 산출물입니다. 그 도메인에서 실제로 발생하는 모든 사건의 목록이에요. "결제 요청됨", "PG사 응답 수신됨", "결제 완료됨", "주문 확정됨"... 이 목록은 그대로 코드의 sealed class나 이벤트 타입 정의로 옮겨갑니다.

kotlin

sealed class PaymentEvent {
    data class PaymentRequested(val orderId: String, val amount: Long) : PaymentEvent()
    data class PgResponseReceived(val result: PgResult) : PaymentEvent()
    data class PaymentCompleted(val transactionId: String) : PaymentEvent()
    data class PaymentFailed(val reason: String) : PaymentEvent()
}

2. Aggregate 식별과 책임 분배

"이 Command를 받아서 이 Event를 발생시키는 책임자가 누구인가"가 명확해집니다. 결제 Aggregate, 주문 Aggregate, 배송 Aggregate처럼요. 이게 그대로 도메인 모델의 클래스 구조가 됩니다. Android 코드에서는 Repository 또는 UseCase의 경계와 연결된다.

3. Bounded Context 경계

큰 워크샵에서는 색깔이나 영역으로 "여기서부터 여기까지는 결제 컨텍스트", "이 너머는 주문 컨텍스트" 식으로 묶입니다. 이 경계가:

모듈 분리 기준 (:feature-payment, :feature-order)
팀 분담 기준
API/이벤트 계약의 경계

4. Hotspot 목록 (미결정 사항 리스트)

빨간 포스트잇들이 그대로 백로그/이슈 트래커로 옮겨갑니다. "PG사 장애 시 재시도 정책 결정 필요", "중복 결제 방지 메커니즘 설계 필요" — 이게 다음 스프린트의 기술 부채 또는 설계 과제가 되죠. 워크샵에서 답이 안 나온 게 부끄러운 게 아니라, 답이 없는 곳을 명시적으로 찍어둔 게 가치입니다.

5. Read Model 명세 (UI 요구사항)

각 Read Model 포스트잇은 그대로 화면 명세가 됩니다. "결제 화면에는 이런 정보가 필요하다", "결제 결과 화면에는 저런 정보가 필요하다" — 이건 UI 디자인과 ViewModel의 StateFlow 구조에 직접 반영돼요.

6. 유비쿼터스 언어 (Ubiquitous Language)

워크샵에서 합의된 단어들 — "결제 요청"인가 "결제 시도"인가, "주문 확정"인가 "주문 완료"인가 — 이게 코드, API, 문서, 회의에서 하나의 통일된 단어로 정착합니다. 더 이상 "기획자는 '결제 시도'라 부르고 백엔드는 'paymentAttempt'이라 부르고 앱은 'PayRequest'라 부르는" 카오스가 없어진다.

정리

이벤트 스토밍은 "사람들 간의 이해 차이"라는 가장 비싼 비용을 미리 지불해서, 나중에 발생할 더 큰 비용을 막는 활동이에요. 산출물은 멋진 다이어그램 한 장이 아니라:

코드 구조의 뼈대 (Event, Aggregate, Context)
미결정 사항의 명시적 목록 (Hotspot)
모두가 같은 단어를 쓰게 만든 사전 (유비쿼터스 언어)

도메인 주도 설계 (Domain Driven Design - DDD)의 이벤트 스토밍 개념정리1

hik14 — Sun, 17 May 2026 19:21:05 +0900

이벤트 스토밍 (Event Storming)

이벤트 스토밍은 Alberto Brandolini가 2013년에 고안한 워크숍 기반의 도메인 모델링 기법입니다. 복잡한 비즈니스 도메인을 빠르게 탐색하고 이해하기 위해 개발자, 도메인 전문가, 기획자, QA 등이 제품에 생산에 참여하는 사람들이 한자리에 모여 포스트잇으로 시스템의 흐름을 시각화하는 협업 방법론이죠.

핵심 아이디어

소프트웨어 시스템을 "도메인에서 일어나는 사건(Event)들의 흐름"으로 바라보는 것이 핵심입니다. 데이터베이스 테이블이나 클래스 다이어그램부터 시작하는 전통적인 방식과 달리, "무슨 일이 일어나는가?"라는 질문에서 출발합니다.

주요 구성 요소 (색상별 포스트잇)

워크숍에서는 보통 색깔별로 의미를 구분합니다.

Domain Event (주황색): "과거형"으로 표현되는 사건. 예: "주문이 생성됨", "결제가 완료됨", "PG사 응답이 수신됨"
Command (파란색): 이벤트를 발생시키는 행동/명령. 예: "주문 생성하기", "결제 요청하기"
Actor (노란색): 명령을 수행하는 주체 (사용자, 외부 시스템)
Aggregate (연보라색): 명령을 받아 이벤트를 발생시키는 도메인 객체
Hotspot/Issue (빨간색): 의문점, 충돌 지점, 결정이 필요한 사항
Policy (초록색): "이벤트가 발생하면 → 자동으로 명령 실행"의 규칙
Read Model (연한 노랑): 사용자가 의사결정을 위해 보는 화면/데이터

흐름은 보통 이렇게 연결 Actor → Command → Aggregate → Domain Event → Policy → (다음 Command)

1 사이클 안에서는 사용자가 의도(Command)를 보내고, Aggregate가 비즈니스 규칙을 확인한 뒤 사실(Event)을 발생시킵니다. 여기까지가 한 단위

연속된 사이클은 Policy가 다리 역할을 합니다. "이런 Event가 발생하면 → 자동으로 저런 Command를 실행한다"는 규칙이 Policy이고, 이게 사이클과 사이클을 이어준다. 사용자가 매번 명령을 내리지 않아도 시스템이 자동으로 다음 단계를 진행할 수 있게 됩니다.

HOTSPOT이 추가된 이벤트 스토밍

Hotspot이 추가된 이벤트 스토밍

1. "중복 결제 방지는?" (Command 위)
사용자가 결제 버튼을 빠르게 두 번 누르거나 네트워크 재전송으로 같은 Command가 두 번 들어왔을 때 어떻게 막을 것인지 — Idempotency Key 같은 결정이 필요한 지점이에요.

2. "미결제 상태 DB 저장? in-memory?" (Event 옆)
이건 실제로 고민하셨던 주제와 직접 닿아있는 의문이죠. "결제 요청됨" 상태를 Room에 영속화할지, Flow로만 흘려보낼지의 결정 포인트입니다.

3. "PG사 장애 시 재시도 정책?" (Policy 위)
Policy 자체가 실패할 수 있는 외부 호출을 트리거하기 때문에, 그 실패를 어떻게 다룰지가 핫스팟이 됩니다.

4. "타임아웃 발생 시 처리 방법?" (Aggregate-Event 사이)
Aggregate가 PG사 응답을 기다리는 동안 시간이 초과되면 결제 상태를 어떻게 둘지 — "결제 실패됨" Event를 만들지, "결제 보류됨"으로 둘지의 결정.

*Hotspot의 진짜 가치는 워크샵 끝에 빨간 포스트잇이 어디 몰려있는지 보는 것. 빨간 게 많이 붙은 영역은 도메인 전문가도 명확한 답을 못 가진 곳, 즉 시스템에서 가장 위험하고 가장 깊이 설계해야 할 부분 위 그림에서도 Policy~Cycle 2 구간에 핫스팟이 몰려있다. 외부 시스템(PG사)과의 통신이 가장 불확실성이 높다는 뜻이고, 이게 실제 결제 도메인의 본질적인 어려움을 반영합니다.

READ MODEL이 추가된 이벤트 스토밍

읽기 모델(Read Model)은 사용자가 어떤 행동(커맨드)을 하기 전에 의사결정을 내릴 수 있도록 돕는 정보의 덩어리를 의미합니다.

단순한 '화면 디자인'과의 차이점

이벤트 스토밍에서 이를 단순한 UI 스케치라고 부르지 않고 굳이 '읽기 모델'이라는 용어를 쓰는 이유는 기술적인 데이터 구조(CQRS 패턴)와 연결되기 때문입니다.

명령(Command)을 위한 데이터: 데이터를 저장하고 수정할 때 필요한 데이터 구조 (예: 정규화된 DB 테이블)
조회(Query)를 위한 데이터: 사용자가 화면에서 오직 '조회'만 하기 위해 여러 테이블을 조합하거나 미리 가공해 둔 데이터 구조 (예: 역정규화된 조회용 데이터)

즉, 이벤트 스토밍에서의 읽기 모델은 "사용자가 커맨드를 유발하기 위해 시스템으로부터 요구하는 최적화된 데이터 뷰(View)"라고 이해하시면 설계 관점에서 가장 완벽합니다.

Android 개발 관점에서 Read Model은 UI State 와 거의 1:1 매핑됩니다.

결제 화면 → PaymentScreenState (StateFlow로 관찰)
결제 결과 화면 → PaymentResultState

그리고 여기서 흥미로운 점은, Event를 어디서 가져와서 Read Model을 만들 것인가가 바로 in-memory vs DB-first 결정과 직결된다. Read Model을 Room에서 쿼리해서 만들면 DB-first SSOT 패턴이 되고, 메모리에 보관된 Event Stream에서 직접 파생시키면 in-memory CQRS가 되는 거죠. 이벤트 스토밍에서 Read Model 포스트잇 옆에 빨간 Hotspot을 붙여 "이 Read Model은 어디서 파생되어야 하는가?"를 표시해두면, 워크샵에서 바로 그 결정을 논의할 수 있다.

도메인 주도 설계 (Domain Driven Design - DDD)의 기초 개념정리2

hik14 — Tue, 12 May 2026 03:27:41 +0900

전술적 설계 (Tactical Design)

1. Entity (엔티티)

- 고유한 식별자(ID)로 구별되는 객체입니다. 속성이 바뀌어도 같은 것으로 취급됩니다.

핵심 특징:

ID가 같으면 같은 객체로 간주
시간에 따라 상태가 변함 (가변)
생명주기를 가짐 (생성 → 변경 → 삭제)

class User(
    val id: UserId,           // 식별자
    var name: String,          // 바뀔 수 있는 속성
    var email: Email
) {
    override fun equals(other: Any?): Boolean {
        if (other !is User) return false
        return this.id == other.id   // ID로만 동등성 판단
    }
    
    override fun hashCode(): Int = id.hashCode()
}

2. Value Object (값 객체)

- 식별자 없이 값 자체로 동등성이 판단되는 불변 객체입니다.

핵심 특징:

모든 속성이 같으면 같은 객체
불변(Immutable) — 한번 만들면 못 바꿈, 바꾸려면 새로 생성
ID 없음
생명주기 없음

data class Money(
    val amount: BigDecimal,
    val currency: Currency
) {
    operator fun plus(other: Money): Money {
        require(currency == other.currency) { "통화가 달라요" }
        return Money(amount + other.amount, currency)  // 새 객체 반환
    }
}

data class Address(
    val zipCode: String,
    val street: String,
    val city: String
)

*도메인 모델링에서는 가능한 한 Value Object를 많이 쓰는 게 좋다. 원시 타입(String, Int)을 그대로 쓰지 말고 의미를 담은 Value Object로 감싸서 의미를 전달한다.

// 나쁨 - 그냥 String
fun sendEmail(email: String)

// 좋음 - Email Value Object  
@JvmInline value class Email(val value: String) {
    init { require(value.contains("@")) }
}
fun sendEmail(email: Email)

Aggregate (애그리거트)

- 함께 변경되어야 하는 엔티티·값 객체의 묶음이며, 트랜잭션과 일관성의 단위입니다.

핵심 특징:

외부에서는 Aggregate Root를 통해서만 접근
1개의Root Entity를 가짐
내부 객체에 직접 접근 금지
하나의 트랜잭션에서 변경되는 단위
불변식(invariant)을 보장하는 책임

// Aggregate Root
class Order(
    val id: OrderId,
    private val items: MutableList<OrderItem> = mutableListOf(),  // 내부 엔티티
    private var status: OrderStatus = OrderStatus.DRAFT,
    val shippingAddress: Address                                   // 값 객체
) {
    // 외부는 Order를 통해서만 OrderItem 조작 가능
    fun addItem(product: Product, quantity: Int) {
        require(status == OrderStatus.DRAFT) { "확정된 주문은 수정 불가" }
        require(items.size < 100) { "한 주문에 100개 초과 불가" }
        items.add(OrderItem(product.id, quantity, product.price))
    }
    
    fun totalAmount(): Money = items
        .map { it.subtotal() }
        .reduce { acc, money -> acc + money }
    
    fun confirm() {
        require(items.isNotEmpty()) { "빈 주문은 확정 불가" }
        status = OrderStatus.CONFIRMED
    }
    
    // 외부에 노출할 땐 읽기 전용
    fun items(): List<OrderItem> = items.toList()
}

// Aggregate 내부 엔티티 (외부에서 직접 생성/접근 X)
class OrderItem(
    val productId: ProductId,
    var quantity: Int,
    val unitPrice: Money
) {
    fun subtotal(): Money = unitPrice * quantity
}

*Aggregate 설계 원칙

작게 유지: 큰 애그리거트는 동시성·성능 문제를 일으킴
ID로 다른 애그리거트 참조: Order가 User 객체를 직접 들고 있지 말고 userId: UserId로 참조
한 트랜잭션엔 하나의 애그리거트만 변경: 여러 애그리거트를 한 번에 바꿔야 한다면 도메인 이벤트로 비동기 처리

4. Repository (리포지토리)

- 애그리거트를 저장하고 조회하는 추상화입니다. 도메인 입장에서는 컬렉션처럼 보이고, 실제 DB 구현은 인프라 계층에 숨깁니다.

// 도메인 계층 - 인터페이스만 정의
interface OrderRepository {
    fun findById(id: OrderId): Order?
    fun save(order: Order)
    fun findByUserId(userId: UserId): List<Order>
}

// 인프라 계층 - 실제 구현 (Room, Retrofit 등)
class OrderRepositoryImpl(
    private val orderDao: OrderDao,
    private val mapper: OrderMapper
) : OrderRepository {
    override fun findById(id: OrderId): Order? {
        return orderDao.findById(id.value)?.let { mapper.toDomain(it) }
    }
    
    override fun save(order: Order) {
        orderDao.insertOrUpdate(mapper.toEntity(order))
    }
    
    override fun findByUserId(userId: UserId): List<Order> {
        return orderDao.findByUserId(userId.value).map { mapper.toDomain(it) }
    }
}

중요 원칙:

애그리거트 단위로만 조작: OrderItemRepository 같은 건 만들지 않음. Order를 통해 접근
인터페이스는 도메인 계층, 구현체는 인프라 계층: 의존성 역전(DIP)
컬렉션처럼 설계: findAll(), save(), remove() 같은 메서드. SQL 냄새 풍기지 않게

안드로이드의 Repository 패턴과 비슷하지만 DDD의 Repository는 반드시 애그리거트만 다룬다는 점이 다릅니다.

안드로이드 Repository는 보통 DTO나 단순 모델까지 다 다루죠.

5. Domain Service (도메인 서비스)

- 특정 엔티티나 값 객체에 자연스럽게 속하지 않는 도메인 로직을 담는 곳입니다.

언제 쓰나?

여러 애그리거트를 협력시켜야 할 때
어느 한 객체에 책임을 두기 어색할 때
외부 시스템과 협력해야 하는 도메인 로직

// 두 계좌 사이 송금 - Account 하나에 두기 어색함
class TransferService(
    private val accountRepository: AccountRepository
) {
    fun transfer(fromId: AccountId, toId: AccountId, amount: Money) {
        val from = accountRepository.findById(fromId) ?: error("계좌 없음")
        val to = accountRepository.findById(toId) ?: error("계좌 없음")
        
        from.withdraw(amount)   // 도메인 로직은 여전히 Account 안에
        to.deposit(amount)
        
        accountRepository.save(from)
        accountRepository.save(to)
    }
}

주의: 도메인 서비스로 도망치는 게 너무 쉬워서 남발하면 빈혈 도메인 모델(Anemic Domain Model) 이 됩니다. 엔티티는 데이터만 들고 서비스가 모든 로직을 갖는 안티패턴이에요. 먼저 엔티티/값 객체에 책임을 두려고 시도하고, 정말 어색할 때만 도메인 서비스로 빼야 합니다.

6. Domain Event (도메인 이벤트)

- 도메인에서 의미 있는 일이 일어났음을 알리는 객체입니다. 과거형으로 이름 짓습니다.

sealed class DomainEvent {
    abstract val occurredAt: Instant
}

data class OrderPlaced(
    val orderId: OrderId,
    val userId: UserId,
    val totalAmount: Money,
    override val occurredAt: Instant = Instant.now()
) : DomainEvent()

data class PaymentCompleted(
    val orderId: OrderId,
    val paymentId: PaymentId,
    override val occurredAt: Instant = Instant.now()
) : DomainEvent()

왜 쓰나?

애그리거트 간 결합도 낮춤: Order가 Payment를 직접 호출하지 않고, "주문됨" 이벤트만 발행. 결제 모듈이 이벤트를 구독해서 알아서 처리.
컨텍스트 간 통합: 주문 컨텍스트의 이벤트를 배송·알림 컨텍스트가 구독.
이벤트 소싱(Event Sourcing)의 기반: 상태가 아닌 이벤트의 흐름으로 시스템을 구성.

class Order(/* ... */) {
    private val events = mutableListOf<DomainEvent>()
    
    fun confirm() {
        require(items.isNotEmpty())
        status = OrderStatus.CONFIRMED
        events.add(OrderPlaced(id, userId, totalAmount()))  // 이벤트 발생
    }
    
    fun pullEvents(): List<DomainEvent> {
        val pulled = events.toList()
        events.clear()
        return pulled
    }
}

안드로이드로 비유하면 LiveData/Flow로 상태 변화를 알리는 것과 발상이 비슷해요. 다만 도메인 이벤트는 비즈니스 사실의 기록이라는 점에서 의미가 더 무겁습니다.

7. Factory (팩토리)

- 복잡한 애그리거트 생성 로직을 캡슐화하는 객체입니다.

언제 쓰나?

생성 자체에 복잡한 규칙이 있을 때
여러 객체를 조합해야 할 때
다양한 형태로 생성될 수 있을 때

class OrderFactory(
    private val pricingPolicy: PricingPolicy,
    private val discountService: DiscountService
) {
    fun createFromCart(cart: Cart, user: User): Order {
        require(cart.items.isNotEmpty()) { "빈 장바구니로 주문 불가" }
        
        val orderItems = cart.items.map { cartItem ->
            val price = pricingPolicy.calculate(cartItem.product, user)
            val discounted = discountService.applyDiscount(price, user)
            OrderItem(cartItem.product.id, cartItem.quantity, discounted)
        }
        
        return Order(
            id = OrderId.generate(),
            userId = user.id,
            items = orderItems.toMutableList(),
            shippingAddress = user.defaultAddress
        )
    }
}

팁: 생성 로직이 단순하면 굳이 Factory를 만들지 말고 생성자나 정적 팩토리 메서드로 충분합니다.

class Order private constructor(...) {
    companion object {
        fun create(userId: UserId, items: List<OrderItem>): Order {
            require(items.isNotEmpty())
            return Order(OrderId.generate(), userId, items.toMutableList())
        }
    }
}

DDD 개념안드로이드 일반적 위치

Entity, Value Object	domain/model/ 안의 클래스
Aggregate	동일하게 domain/model/
Repository (인터페이스)	domain/repository/
Repository (구현체)	data/repository/
Domain Service	domain/service/ 또는 UseCase로 흡수되기도 함
Domain Event	Flow/Channel로 발행하거나 EventBus 활용
Factory	domain/factory/ 또는 companion object

도메인 주도 설계 (Domain Driven Design - DDD)의 기초 개념정리1.

hik14 — Mon, 11 May 2026 01:45:00 +0900

정의

도메인 주도 설계(DDD)는 소프트웨어를 그것이 다루는 업무 분야(도메인)에 맞춰 모델링하는 설계 방식입니다. 특정 기술이나 원칙이 아니라 사고하는 방법에 가까우며, 복잡한 업무 분야를 다루는 프로젝트에서 핵심을 놓치지 않도록 돕는 접근입니다. 핵심은 도메인 전문가와 개발자가 같은 용어(유비쿼터스 언어)로 소통해 이해의 차이에서 오는 오해를 없애고, 비즈니스 문제를 제대로 풀어내는 소프트웨어를 만드는 것입니다. 코드가 곧 비즈니스 지도가 되게 함으로써, 요구사항 변화에 유연하게 대응하고 소프트웨어의 유지보수성을 극대화하는 설계 철학입니다.

전략적 설계 (Strategic Design)

Problem Space (문제 공간)

비즈니스 자체를 이해하는 영역입니다. "우리가 어떤 문제를 해결하려는 거지?"

1. 도메인(Domain)과 서브도메인(Subdomain)

도메인은 비즈니스 영역 전체를 뜻합니다. 쿠팡이라면 "이커머스" 전체가 도메인이다.. 하지만 도메인 전체를 한 번에 다루기엔 너무 크기 때문에 서브 도메인으로 쪼갠다. 쿠팡 도메인이라면 상품 카탈로그, 주문, 결제, 배송, 리뷰, 회원, 검색, 추천 등으로 나눌 수 있다.

서브 도메인의 분류

Core Subdomain (핵심 서브도메인)

비즈니스의 경쟁력이 나오는 영역. 회사가 살아남는 이유 그 자체.
가장 똑똑한 개발자, 가장 많은 리소스, 가장 정교한 모델링이 들어가야 합니다.
절대 외주 주거나 패키지 사서 쓰면 안 되는 영역.
예: 쿠팡의 "물류·배송 최적화", 토스의 "송금·인증", 넷플릭스의 "추천 알고리즘".

Supporting Subdomain (지원 서브도메인)

핵심을 받쳐주지만, 그 자체로 차별화 포인트는 아닌 영역.
우리 비즈니스에 맞게 자체 개발은 해야 하지만, Core만큼 공들일 필요는 없음.
단순한 CRUD에 가까울 수 있고, 주니어가 맡아도 되는 영역.
예: 쿠팡의 "리뷰 시스템", "쿠폰 관리".

Generic Subdomain (일반 서브도메인)

어느 회사나 똑같이 필요한 범용 영역.
직접 만들지 말고 외부 솔루션·SaaS·오픈소스로 해결하는 게 합리적.
직접 만들면 시간 낭비.
예: 인증/로그인 → Auth0·Firebase Auth, 결제 게이트웨이 → 토스페이먼츠, 이메일 발송 → SendGrid.

이 분류가 중요한 이유는 "어디에 자원을 집중할지" 정하는 의사결정 도구이기 때문입니다. Core에는 베스트 인력을, Generic에는 SaaS를. 안드로이드 앱으로 비유하면 비즈니스 핵심 화면은 직접 정성껏 만들고, 로그인은 Firebase Auth 붙이고, 푸시는 FCM 쓰는 것

2. Domain Experts (도메인 전문가)

해당 비즈니스를 가장 잘 아는 사람. 개발자가 아닌 현업 담당자를 의미합니다. 보험 도메인이면 보험 설계사, 물류면 창고 관리자, 의료면 의사. 이들의 머릿속에 있는 암묵지를 끌어내는 게 도메인 분석의 출발점.

3. Knowledge Discovery (지식 수집)

도메인 전문가의 머릿속에 있는 비즈니스 지식을 발굴하는 활동. 인터뷰, 워크샵, 도메인 문서 분석, 실제 업무 관찰 등으로 이루어진다. 개발자가 일방적으로 듣는 게 아니라, 질문하고 모델로 그려보고 다시 검증받는 협력 과정.

4. Event Storming (이벤트 스토밍)

Knowledge Discovery의 대표적 기법. 큰 벽에 포스트잇을 붙여가며 도메인을 시각화하는 워크샵.

이벤트스토밍 과정에서 자연스럽게 바운디드 컨텍스트의 경계가 드러납니다. 이벤트의 흐름이 끊기는 지점, 용어가 달라지는 지점이 컨텍스트 경계가 된다.

5. Communication & Ubiquitous Language (소통과 유비쿼터스 언어)

도메인 전문가와 개발자가 같은 단어로 대화하기로 합의한 언어. 번역하지 않는 것이 핵심입니다.

흔한 안티패턴:

현업: "고객이 장바구니에 담은 상품"
개발자: "User의 Cart 엔티티 안에 있는 ProductItem"
회의에서는 매번 머릿속으로 번역 → 오해와 버그의 원천

유비쿼터스 언어를 쓰면:

회의에서도, 코드에서도, 문서에서도 모두 똑같이 "장바구니"와 "상품"을 사용
클래스명 Cart, 메서드명 addProduct() — 코드가 곧 도메인 언어
Kotlin으로 보면: class Cart { fun addProduct(product: Product) } 이런 식으로 비즈니스 용어가 그대로 코드에 드러남

*주의할 점은 유비쿼터스 언어가 컨텍스트별로 다르다는 것. 주문 컨텍스트의 "상품"과 배송 컨텍스트의 "상품"은 다른 모델일 수 있습니다. 그래서 다음에 나오는 바운디드 컨텍스트가 필요해집니다.

Solution Space (해결 공간)

문제를 어떻게 시스템 구조로 풀어낼지를 다루는 영역

1. Bounded Context (바운디드 컨텍스트)

하나의 모델과 하나의 유비쿼터스 언어가 일관되게 통하는 경계입니다. DDD의 가장 중요한 개념

왜 필요한가? 시스템이 커지면 같은 단어가 다른 의미를 갖게 됩니다.

예시 — 이커머스에서 "상품(Product)"이라는 단어:

카탈로그 컨텍스트: 이름, 설명, 카테고리, 이미지, 가격 — "고객에게 보여주는 상품 정보"
재고 컨텍스트: SKU, 창고 위치, 수량 — "물리적으로 관리되는 단위"
주문 컨텍스트: 상품 ID, 주문 시점 가격, 수량 — "주문에 담긴 스냅샷"
배송 컨텍스트: 무게, 부피, 포장 단위 — "운반 가능한 형태"

같은 "상품"인데 컨텍스트마다 모델이 완전히 다르다. 이걸 하나의 거대한 Product 클래스로 합치려고 하면 필드가 50개 넘는 괴물이 된다. 그래서 컨텍스트별로 경계를 긋고 각자의 모델을 갖게 한다.

*서브도메인과의 차이:

서브도메인 = Problem Space, 비즈니스 영역의 구분
바운디드 컨텍스트 = Solution Space, 모델/코드의 경계

이상적으로는 1:1이지만 현실에서는 어긋나는 경우도 많습니다.

2. Context Map (컨텍스트 맵)

여러 바운디드 컨텍스트가 서로 어떤 관계로 연결되는지 그린 지도. 단순한 시스템 구조도가 아니라 팀 간 관계와 협력 방식까지 표현하는 게 특징입니다. (콘웨이의 법칙 => "소프트웨어 구조는 팀의 조직도와 똑같이 만들어진다")

3. 컨텍스트 간 통합 패턴

두 컨텍스트가 만났을 때 어떻게 연결할지에 대한 카탈로그입니다.

Partnership (파트너십)

두 팀이 운명 공동체. 함께 성공하거나 함께 실패.
양쪽이 긴밀하게 협력해서 인터페이스를 같이 진화시킴.
예: 주문팀과 결제팀이 새 결제 방식을 같이 만들 때.

Shared Kernel (공유 커널)

두 컨텍스트가 모델의 일부를 공유.
공유된 부분은 양쪽 팀의 합의 없이 절대 변경 불가.
강결합이라 신중하게 써야 함. 보통 핵심 도메인 객체나 공유 라이브러리.
예: "Money", "Address" 같은 값 객체.

Customer-Supplier (고객-공급자)

한쪽이 공급자(Upstream), 다른 쪽이 고객(Downstream).
고객이 요구사항을 내면 공급자가 일정에 반영해줌. 협상 가능한 관계.
예: 주문(고객)이 결제(공급자)에게 "이런 응답 필드가 필요해요" 요청 → 결제팀이 다음 스프린트에 반영.

Conformist (순응자)

다운스트림이 업스트림 모델을 그대로 따라감. 협상력 없음.
외부 시스템이나 사내 다른 팀이 우리 요청을 안 받아줄 때.
예: 외부 PG사 API 모델을 그대로 우리 도메인에 받아들이는 경우.

Anti-Corruption Layer / ACL (부패 방지 계층)

외부 모델이 우리 도메인을 오염시키지 못하도록 번역 계층을 둠.
외부의 이상한 모델·용어가 우리 코드에 스며드는 걸 막음.
DDD에서 매우 자주 쓰이는 패턴.
예: 레거시 시스템과 통신할 때, 레거시의 USR_INFO_TBL_DTO를 우리 도메인의 Customer로 변환해주는 어댑터 레이어.
안드로이드로 비유하면 Repository 패턴에서 외부 API 응답 DTO를 도메인 모델로 매핑하는 매퍼 클래스가 ACL의 역할에 가까워요.

Open Host Service (개방 호스트 서비스)

여러 다운스트림이 사용할 수 있도록 잘 정의된 프로토콜·API를 공개.
공급자가 일관된 API를 제공해서 각 고객별로 커스텀하지 않음.
예: 사내 공통 인증 서비스, 결제 게이트웨이.

Published Language (공표된 언어)

Open Host Service와 짝을 이룸. 모두가 따르는 표준 데이터 형식.
예: REST API의 JSON 스키마, ProtoBuf 정의, 산업 표준(HL7, FHIR 등).

Separate Ways (각자의 길)

통합하지 말고 그냥 분리해서 가자.
통합 비용이 가치보다 클 때의 의식적 선택.
예: 영업팀과 인사팀 시스템처럼 사실상 접점이 없는 경우.

Big Ball of Mud (거대한 진흙 공)

경계가 없는 혼돈 상태. 의도된 패턴이 아니라 현재 상태를 직시하는 라벨.
컨텍스트 맵에 굳이 표시하는 이유: "이 영역은 진흙공이니 ACL 두고 격리하자" 같은 결정을 위해.

Compose UI 성능 최적화 하기

hik14 — Wed, 29 Apr 2026 23:44:45 +0900

참조영상

https://www.youtube.com/watch?v=ahXLwg2JYpc

1. 언제 성능을 최적화 할 것인가? 성급한 최적화를 하지 말라!

Compose는 이미 기본적으로 꽤 효율적이기 때문에, 앱을 만들고 실제로 성능 문제가 관찰될 때 최적화하라고 합니다.

성능 최적화는 측정 → 분석 → 개선 → 재검증의 반복이다.

"가장 적은 코딩 노력을 들여 사용자에게 가장 부드러운 경험을 제공하는 지점"을 찾는 것이 진정한 의미의 최적화입니다.

조기 최적화를 경계하라 (Avoid Premature Optimization)

"조기 최적화는 만악의 근원"이라는 유명한 격언처럼, 성능 문제가 확인되지 않은 상태에서 복잡한 최적화 기법을 적용하는 것은 피해야 합니다.

유지보수성 우선: 과도한 최적화는 코드를 읽기 어렵게 만들고 버그를 유발합니다. 먼저 깨끗하고 동작하는 코드를 작성한 뒤, 병목 지점이 발견되었을 때만 정밀 타격을 가해야 합니다.
Tools, not Rules: "모든 리스트에는 반드시 이 기법을 써야 한다"는 규칙보다는, 현재 상황에서 도구(Layout Inspector, Profiler 등)가 가리키는 문제를 해결하는 데 집중하세요

추측하지 말고 측정하라 (Measure, Don't Guess)

최적화에서 가장 위험한 것은 "이 코드가 느릴 것 같다"는 직감에 의존하는 것

벤치마킹 도구 활용: Android에서는 Macrobenchmark를 통해 실제 사용자가 느끼는 앱 시작 시간이나 스크롤 성능(Jank)을 수치화
비용 확인: 최적화도 시간이라는 비용이 듭니다. 측정을 통해 성능 저하가 미미한 수준이라면, 코드의 가독성을 희생하며 최적화하지 않는 것이 더 나은 전략일 수 있습니다

*성능 테스트는 반드시 R8이 활성화된 릴리스 모드에서 진행해야 정확한 결과를 얻을 수 있다.

2. 상태 읽기 지연 (Defer Reading State)

* Compose UI 렌더링 단계 이해하기

Compose는 한 프레임을 그리기 위해 다음 단계를 단방향(UDF) 으로 거칩니다.

컴포지션 (Composition) — 무엇을 그릴지 결정
- @Composable 함수를 실행해서 UI 트리(레이아웃 노드)를 생성
레이아웃 (Layout) — 어디에 배치할지 결정
- 측정(measure) → 자체 크기 결정 → 자식 배치(placement) 순서로 트리를 한 번만 순회 (선형 시간)
그리기 (Drawing) — 어떻게 렌더링할지 결정
- 트리를 위→아래로 순회하며 캔버스에 픽셀을 그림

상태 읽기(state read) 추적

Compose는 어느 단계에서 어떤 state를 읽었는지를 자동으로 추적해서, 그 state가 변경되면 필요한 단계만 재실행합니다.

// 컴포지션에서 state 읽음 → 매 스크롤마다 리컴포지션
Modifier.offset(
    with(LocalDensity.current) { 
        (listState.firstVisibleItemScrollOffset / 2).toDp() 
    }
)

// 레이아웃 단계에서 state 읽음 → 리컴포지션 스킵
Modifier.offset {
    IntOffset(0, listState.firstVisibleItemScrollOffset / 2)
}

3. Stability(안정성) — Compose가 스킵을 결정하는 방식

리컴포지션을 건너뛸지 말지를 결정하는 가장 중요한 개념입니다.

Compose는 컴포저블의 파라미터가 stable(안정적) 이라고 판단되면, 입력값이 같을 때 해당 컴포저블을 스킵합니다.

Stable의 조건

- 두 인스턴스의 equals() 결과가 항상 일관됨

- public property가 변하면 컴포지션에 알림 (예: MutableState)

- 모든 public property도 stable

자동으로 stable한 타입: 원시 타입(Int, Boolean 등), String, 함수 타입(람다), MutableState 등.

Unstable한 대표 케이스:

var 프로퍼티를 가진 클래스
List, Set, Map 같은 인터페이스 (구현체가 mutable일 수 있어서 컴파일러가 보장 못함)
다른 모듈의 클래스 (컴파일러가 검증 못함)

*Data Class로 val(값)으로 원시타입을 이용하여 상태를 정의한다.

data class UserUiState(
    val id: Int,
    val name: String,
    val isLoggedIn: Boolean,
    val score: Double
)

4. Stability를 다루는 방법

@Stable / @Immutable 어노테이션: 개발자가 컴파일러에게 "이건 안정적이다"라고 알려주는 약속.
data class라도 unstable일 수 있음: 내부에 List<T> 같은 unstable 타입이 있으면 전체가 unstable.

data class TodoUiState(
    val title: String,
    val items: List<String>   // val이지만 List는 unstable!
)

해결책

Kotlin의 List, Set, Map 대신 Kotlinx Immutable Collections (ImmutableList, PersistentList)를 사용 또는 wrapper 클래스를 만들어 @Immutable 처리

옵션 1: Kotlinx Immutable Collections 사용 (권장)

import kotlinx.collections.immutable.ImmutableList

data class TodoUiState(
    val title: String,
    val items: ImmutableList<String>   // ✅ stable
)

옵션 2: @Immutable 어노테이션으로 약속

@Immutable
data class TodoUiState(
    val title: String,
    val items: List<String>   // 개발자가 "절대 변경 안 한다"고 약속
)

Compose Compiler Metrics로 어떤 클래스/함수가 unstable로 판정됐는지 리포트 생성 가능. 컴파일러 옵션으로 활성화하면 어떤 컴포저블이 스킵되지 못하는지 정확히 진단할 수 있습니다.