• NexPay 앱 개요 및 목표

  → 빠른 시일 내 앱 개발 및 가능성 확보

• 기술 스택

  • Kotlin
  • Compose
  • Clean Architecture
  • MVI

2. AI 협업 개발 도입 배경

• 왜 Claude Code를 도입했는가?

  → 원래 Android Team은 Gemini를 사용할 목적이였다. (Android Studio안 기본 AI가 Gemini) Gemini 연동이 생각보다 가이드가 잘 되어있지 않고 MCP 연동이 제대로 되지 않았음.

• AI에게 기대했던 효과

  • 처음에는 “Figma MCP 연동 → 화면 개발 시간 단축”이 목적이였다.
  • 나머지는 기존에 사용하던 AI와 같이 물어보면서 작업을 하려고 생각하고 있었다.

3. Claude Code 도입 후

• Figma MCP 연동 → 화면 개발 시간 단축 + 각각의 Navigation 연결
• 비즈니스 로직 및 테스트 코드 개발 시간 단축

4. 개발 워크플로우

• 기술 선정 ( java + xml or kotlin + compose ) / 아키텍처 선정 ( Clean Architecture ) / 패턴 선정 ( MVVM or MVI )
• prompt 작성 → 검증 → 회의 → 채택
  • UI : Figma 디자인 → Compose UI / viewModel / UIState / UiEffect / UiEvent 자동 생성 파이프라인
  • 비즈니스 로직 : domain / data / remote / test API 연동 자동 생성 파이프라인
• Claude 계획 → 개발 → 검증 → Commit 사이클

5. 잘 된 점

• prompt 명령으로 화면 및 비즈니스 로직이 제대로 구현
• Commit Message 자동 생성으로 시간 절약
• 테스트/빌드 검증까지 포함한 자동화된 결과물

6. 어려웠던 점

• 초기 prompt 설계

  • UI

    • 아이콘 직접 넣을 생각 → 아이콘 생성 가능 확인 후 prompt 변경
    • figma 고정 dp 화면 찌그러짐 문제 → 반응형 레이아웃 리팩터링 규칙 추가 prompt 변경

  • 비즈니스 로직

    • domain / data / remote / test 생성 → viewModel 자동 연동 추가 ( 기존은 viewModel 변경 불가 )

    → 초기 설정에서 내가 원하는 prompt가 나올 때까지 반복적으로 테스트 진행이 필요

• Context 사용량 체크

  • standard / premium 모두 둘다 내가 Context를 어떻게 사용하고 있는지 정확한 체크가 힘듬.

7. 배운 점 / 노하우

• /context 또는 /insights 같은 명령어를 사용해서 행동 패턴을 분석해서 Context 개선하는 것이 좋습니다.
  • Context 관리 방법
    • /clear 항상 초기화 해준다.
    • /compact 만약 내용을 이어가야 한다면 압축을 해주면 된다.
    • /rename /resume → /clear 하기전 만약 저장해둬야 한다면 rename으로 정의하고 나중에 resume 으로 불러오면 된다.
• AI에게 명확한 지시를 내리는 방법
  • prompt 설계 방법 - 아직 미흡하지만
    • 명확한 규칙 ( 강제성을 주는것이 좋은 것 같다 )
    • 샘플 가이드 ( 샘플을 주면 잘 만들어 준다 )
• Command를 사용해라.. 기존은 파일을 바꾸면서 작업을 하던가 @해서 파일을 찾아서 작업하던가 했는데 Command 등록 후 업무 효율이 올라감
• Opus 모델을 사용해라… 돈이 쵝오…
  • Plan 모드는 당연 Opus로 사용하는 것이 좋습니다. ( 나오는 퀄리티가 다름 )
  • 실제 개발 단계에서도 Sonnet 보단 Opus가 정확한 추론과 이해하는 내용의 범위가 다르다고 느껴집니다.

8. Before & After 비교

• AI 도입 전후 개발 생산성 변화
• 코드 품질 및 일관성 상승
• git commit message 관리 깔끔

9. 향후 개선 방향

• 자동화 파이프라인 구축 ( UI → ViewModel → Domain → Data → Remote / Local → Test → Commit → Push )
• 커스텀 스킬 / 훅 / 커멘드 등 활용으로 반복 작업 최소화
• UI 및 Presentation 부분 테스트 코드 도입

1. Mock

   • 왜 Mock이 필요한가?

     → JUnit은 “테스트 실행”과 “결과 검증”을 담당하지만, 의존성(Dependencies)이 있는 코드를 직접 제어 못함

       class UserService(private val userRepository: UserRepository) {
           fun getUserName(id: String) : String {
               return userRepository.findById(id).name
           }
       }

     → 이 경우 UserRepository는 DB와 통신할 수 있고, 네트워크를 호출할 수 있다. 그럼 테스트 시 실제 DB연결이나 서버 호출이 일어날 수 있으므로 단위 테스트(Unit Test)의 목적(”하나의 로직만 검증”)에 어긋난다.

     → 그래서 “진짜 객체” 대신 “가짜(Mock) 객체”를 만들어서 외부 의존성을 대채한다.

   • Mockito / MockK

    |  | Mockito | MockK |
    | --- | --- | --- |
    | 주요 언어 | Java 기반  | Kotlin 전용 |
    | Mock 생성 | Mockito.mock() | mockk() |
    | 동작 설정 | when(…).thenReturn(…) | every {…} returns … |
    | 호출 검증 | verify(…) | verify {…} |
    | 특징 | 전통적인 Mocking 라이브러리 | 코루틴, suspend 함수, DSL 친화적 |
1. 그래서 우리팀은?
    - **JUnit4 vs JUnit5 : JUnit5를 사용할 예정입니다.**

        → 우리팀의 Unit Test 목적 순수 비즈니스 로직만 테스트 하기 위함 

        → 대부분 Kotlin 기반으로 MockK / 코루틴 테스트와 호환 목적

        → UI/Andorid 테스트 코드 작성 시 JUnit4를 사용해도 됩니다. (강제성 x) 

    - **Mockito vs MockK :  MockK를 사용 할 예정입니다.**

        → 우리 프로젝트는 Kotlin 기반 / Java 테스트가 필요할 경우 Mockito 사용 가능

그 이유는 Kotlin이 Java 기반 JVM 위에서 동작하며, 완벽한 대체 기능이 없기 때문이다.

🔒 AtomicReference란?

AtomicReference 는 락을 사용하지 않고(lock-free)

여러 스레드에서 동시에 안전하게 읽기/쓰기가 가능한 원자적 참조(Reference) 저장 객체이다.

✅ Kotlin에서 AtomicReference 를 사용하는 이유

1. Kotlin에는 완전한 대체품이 없음

Kotlin은 JVM 언어라 다음 Java concurrency primitives 를 그대로 사용한다.

• AtomicReference
• AtomicBoolean
• AtomicInteger
• AtomicLong

Kotlin 자체에는 이와 동일한 기능을 제공하는 클래스가 없다.

2. Lock-free라서 빠르고 경량

Mutex 또는 synchronized는 락(lock)을 걸기 때문에 성능 오버헤드가 있다.

반면 AtomicReference는:

• 락을 사용하지 않고도 thread-safe
• 읽기/쓰기가 매우 빠름

3. 여러 스레드/코루틴 환경에서도 안전

코루틴은 스레드를 옮겨가며 실행되므로

공유 데이터를 안전하게 관리해야 한다.

AtomicReference 없이는 다음 문제가 발생할 수 있다:

• 레이스 컨디션(race condition)
• 값 읽기와 쓰기 순서가 보장되지 않음
• 스레드 전환 중 데이터가 꼬임

4. 불변 패턴(Immutable state) 유지에 유리

암호화 관련 파라미터(passphrase, salt, IV)는:

• 한 번 생성되면 변경되면 안 되고
• 여러 스레드에서 읽히며
• 원자적으로 교체(CAS)되어야 함

AtomicReference는 이 패턴에 정확히 맞는다.

5. Base64 decode 실패 등에서 안정적으로 롤백 가능

파라미터 세팅 중 실패하면:

clear()  // 전부 null로 초기화

이 과정을 Atomic하게 처리할 수 있다는 장점도 있다.

🆚 AtomicReference 대체 옵션 비교

결론: AtomicReference가 가장 적합하고 효율적이다.

📌 CryptoParameterMemoryStore 에서 AtomicReference 를 쓰는 이유 요약

CryptoParameterMemoryStore 구조:

private val passphraseRef = AtomicReference<String?>(null)
private val saltRef = AtomicReference<ByteArray?>(null)
private val initializationVectorRef = AtomicReference<ByteArray?>(null)

필요한 특성이 모두 AtomicReference 에 들어있다:

• thread-safe
• lock-free
• 값의 원자적 교체
• null 허용
• 실패 시 rollback 가능
• 암호 파라미터처럼 민감한 데이터에 적합

즉, multiprocessing / coroutine 환경에서 가장 안전하고 빠른 방식이다.

📝 결론

Kotlin에서는 Java의 AtomicReference를 사용하는 것이 정상적이며, 특히 암호 파라미터처럼 thread-safe 하고 lock-free 메모리 저장이 필요할 때 AtomicReference가 가장 적합한 선택이다.

1. connect → startReader → send → (프레임 수신 콜백) → 모드 기준으로 계속/종료

2. 데이터는 STX(0x02) ~ ETX(0x03) + LRC(1byte) 프레이밍

3. 두 가지 수신 기준을 모두 지원:

• 길이 헤더 기반 (두 번째 바이트가 ‘I’ 이고, 3..6에 ASCII 4자리 길이)
• ETX 도발 기반 (길이 헤더가 없을 때)

4. LRC(XOR)은 STX 포함/제외 두 방식 모두 검증(벤더 사양 혼재 대응)

5. 매 프레임마다 ACK(0x06) 자동 전송(기존 Kovan 리더가 프레임마다 ACK 요구하는 패턴 대응)

6. ReceiveMode로 종료 조건을 제어:

• Continuous: 앱이 close() 할 때까지 계속
• StopAfterEndFrame: *E…(혹은 E…) 프레임 받으면 종료(가맹점 다운로드 용)
• StopAfterFirstFrame: 유효 프레임 1개 받자마자 종료(단건 응답용)

Public API 요약

• suspend fun connect(host, post)

  → 소켓 연결만 수행(블로킹 읽기, soTimeout=0). 스트림 래핑

• fun startReader()

  → IO dispatchers에서 수신루프 시작. (메인스레드에서 네트워크 호출 피하려고 UNDISPATCHED를 쓰지 않음 → NetworkOnMainThreadException 회피)

• suspend fun send(data: ByteArray)

  → byte를 서버에 전송

• fun setOnFrame(listener: (ByteArray) → Boolean)

  → 완성 프레임(STX..ETX..LRC 전체) 가 올 때마다 호출

  → 리스너가 false를 반환하면 “리스너 의사”로 루프를 끌낼 수 있음.

• fun setReceiveMode(mode)

  → 수신 종료 정책 지정 (Continuous / StopAfterEndFrame / StopAfterFirstFrame)

• suspend fun close()

  → reader 취소 - 스트림/소켓 닫기

단건 조회는 StopAfterFirstFrame, 가맹점 다운로드는 StopAfterEndFrame(서버가 *E…로 끝내줌), 스트리밍은 Continuous

수신 루프(프레이밍) 상세

while (isReaderRunning && isOpen()) {
    // 1바이트 블로킹 읽기 (IO 디스패처)
    localInputStream.read(singleByteBuffer)

    // STX를 기다렸다가, STX가 오면 프레임 버퍼 초기화+수집 시작
    // 'I' 포맷이면 3..6 ASCII 길이(예: "0123")를 파싱해 STX..ETX 길이를 알 수 있음
    // 길이를 알면 그 길이만큼 딱 모은 뒤 LRC 1바이트를 추가로 읽어서 "완성 프레임"
    // 길이를 못 알면, ETX를 만나면 LRC 1바이트 추가로 읽어서 "완성 프레임"
}

1. 길이 헤더 파싱

   → specFormatByte == ‘I’ 이고 바이트가 7개 이상 모이면 collected[3..6]을 ASCII 정수로 변환 - STX..ETX 길이로 해석. 그 길이만큼 모이면 LRC 1byte를 추가로 읽어 완성

2. ETX 기반

   → 길이를 못 얻은 경우 ETX 도착 시 LRC 1Byte를 추가로 읽어 완성

RLC 검증과 ACK

val etxIndex = fullFrameBytes.indexOf(ETX)
val readLrc   = fullFrameBytes.last() & 0xFF
val lrcInclStx = xor(fullFrame, from=0, to=etxIndex)   // STX 포함
val lrcExclStx = xor(fullFrame, from=1, to=etxIndex)   // STX 제외

val valid = readLrc == lrcInclStx || readLrc == lrcExclStx

1. 장비마다 LRC 정의가 STX 포함/제외 혼용되는 경우가 있어 둘다 허용

2. 유효/무효와 관계 없이 (프로토콜 요구에 맞춰) ACK(0x06)를 전송하도록 구현되어 있음

   (무효 LRC 시에도 계속 받을지 여부는 ReceiveMode에 따름)

종료 조건(ReceiveMode + isEndFrame)

• isEndFrame(payload)

  → payload[0] == ‘*’ && payload[1] == ‘E’ - 종료(예: *E0)

  → 또는 payload[0] == ‘E’ - 예비 종료 패턴

• StopAfterEndFrame 에서는 위 패턴을 받을 때까지 계속

• StopAfterFirstFrame 은 첫 유효 프레임에서 바로 종료

• Continuous 는 앱이 close() 할 때까지 종료하지 않음

startReader()가 따로 있는 이유는?

• connect() 는 소켓 연결만 담당
• startReader() 는 IO 디스패처에서 백그라운드 수신을 시작
• 이렇게 분리하면, 연결 직후 초기화/전송 타이밍을 제어하기 쉽고, 메인 스레드에서 수신 루프가 즉시 시작되며 네트워크를 건드리는 상황(=UNDISPATCHED)을 피할 수 있어서 NetworkOnMainThreadException을 막을 수 있다.

궁금한거

1. 이건 어떻게 사용되는거야?

private val supervisorJob = SupervisorJob()
private val ioCoroutineScope = CoroutineScope(Dispatchers.IO + supervisorJob)

→ 뭐가 만들어지나?

• SupervisorJob()
  • 이 스코프의 “부모 잡(Job)” 이다. 한 자식 코루틴이 실패해도 다른 자식들/스코프 전체가 같이 취소되지 않도록 한다.(일반 Job이면 한 자식의 예외가 스코프 전체로 전파되어 모두 취소됨)
• CoroutineScope(Dispatchers.IO + supervisroJob) 코루틴 컨텍스트를 합친 것
  • Dispatchers.IO: 네트워크/파일/IO 같은 블로킹 작업을 위한 백그라운드 스레드 풀 → StricMode의 “NetworkOnMainThread” 위반을 피함
  • supervisorJob: 위에서 말한 실패 고립(subpervion) 역할
• 이 스코프에서 launch{ … } 하면:
  • 작업은 항상 IO 스레드풀에서 돌아가고(메인 스레드 아님)
  • 어느 하나의 지식(예: 수신 루프)이 예외로 죽어도 다른 자식(예: 추후 보낼 heartbeat, 재시도 타이밍 등)은 유지된다.

요즘은 계속해서 개발 진행을 하고 있는데 재미있다! 하지만 가끔 블로그를 써야하는데 주제를 뭐로 할 지 항상 고민인 것 같다. 그래서 앞으로는 개발하면서 궁금하거나 개발한 건에 대해서 작성을 해볼 예정이다!!

문제는, 현재 프로젝트는 거의 모든 기능이 모듈화(Modularization) 되어 있어,

기존처럼 Activity/Fragment의 onResume, onPause, onDestroy에 직접 접근하기가 쉽지 않았다는 점이다.

특히 Compose 기반 화면에서는 Activity나 Fragment에 직접 의존하지 않고 UI를 그리기 때문에,

SDK의 생명주기(Lifecycle)를 정확하게 제어하는 것이 더 까다로워진다.

그래서 여러 사례와 문서를 찾아본 끝에, 가장 적합한 해결책을 찾았다.

바로 DefaultLifecycleObserver 를 활용하는 방식이다.

🧭 DefaultLifecycleObserver란?

DefaultLifecycleObserver는 Android Jetpack의 Lifecycle 라이브러리가 제공하는 인터페이스로,

Activity나 Fragment의 생명주기를 관찰할 수 있는 기능을 제공한다.

필요한 메서드만 override할 수 있고, 코틀린의 default method 덕분에 아주 간단하게 사용할 수 있다.

lifecycleObserver = object : DefaultLifecycleObserver {
    override fun onResume(owner: LifecycleOwner) {
        // SDK 재시작
    }

    override fun onPause(owner: LifecycleOwner) {
        // SDK 일시정지
    }

    override fun onDestroy(owner: LifecycleOwner) {
        // 자원 해제
    }
}

이렇게 등록만 해두면 Activity/Fragment 생명주기에 따라 자동으로 호출된다.

🔍 왜 DefaultLifecycleObserver가 필요했을까?

내가 직면했던 문제는 크게 두 가지였다.

1) 모듈 구조 때문에 Activity/Fragment 접근이 쉽지 않음

모듈화를 진행하다 보면:

• UI 모듈(Compose 화면)
• Feature 모듈
• SDK Wrapper 모듈

이 각각 분리되어,

Activity/Fragment의 lifecycle 함수에 직접 접근하기가 매우 어렵다.

하지만 외부 카메라 SDK는 대부분 이렇게 요구한다.

• activity.onResume() 시점 → 카메라 재시작
• activity.onPause() 시점 → 카메라 중지
• activity.onDestroy() 시점 → 자원 해제

이 흐름을 놓치면:

• 카메라가 멈추지 않아서 릭 발생
• 화면 이동 시 crash 발생
• 카메라 Preview가 블랙스크린으로 뜸
• 일부 기기에서 전면/후면 전환 오류 발생

즉, 정확한 lifecycle 제어는 필수였다.

DefaultLifecycleObserver를 사용하면,

Activity나 Fragment에 직접 접근하지 않아도

lifecycle만 넘겨 받아 안전하게 제어할 수 있다.

2) SDK 제어 코드를 ViewModel 또는 Controller로 분리하고 싶었음

Activity/Fragment에 카메라 SDK 호출 코드를 넣으면:

• 코드가 길어진다
• 테스트하기 어렵다
• UI와 로직이 강하게 결합된다

그래서 카메라 동작을 ViewModel도 아니고, UI도 아닌,

별도의 Controller 클래스로 분리하고 싶었다.

하지만 이 Controller에서 lifecycle 이벤트를 받기 위해서는

LifecycleOwner에 직접 붙을 필요가 있다.

이 역할을 정확하게 수행할 수 있는 것이

바로 DefaultLifecycleObserver다.

📌 마무리

외부 카메라 SDK를 Compose + 모듈 구조에서 안정적으로 사용하려면

Lifecycle 제어가 매우 중요하다.

그리고 그중에서 가장 깔끔하고 안전한 방식이 바로 DefaultLifecycleObserver다.

덕분에:

• SDK 코드 분리
• 모듈 의존성 감소
• UI/로직 결합도 해소
• 유지보수성 극대화
• lifecycle 버그 감소

라는 큰 장점을 얻을 수 있었다.

앞으로 외부 SDK(카메라, OCR, 센서, 결제기 등)를 다룰 때는

이 패턴을 적극적으로 활용하게 될 것 같다.

이번에 PR을 올리던 중, 한 commit에 build 관련 변경과 feat 기능 구현이 섞여 있는 문제를 뒤늦게 발견했다. 이미 원격 저장소에 push까지 완료하고 PR까지 생성한 상태라 더 아쉬움이 컸다.

결국 팀장님께 상황을 설명드렸고, PR은 Decline 처리한 뒤 작업을 다시 정리하기로 결정했다.

다행히 커밋 수가 많지 않아 수정하는 데 오래 걸리진 않았다. 가장 최근 feat commit을 기준으로: • build 관련 파일 • feat 관련 파일

이렇게 나누어 커밋을 분리했고, 이 기회에 함께 기존 commit message도 전체적으로 정리했다.

정리된 상태로 다시 PR을 올렸고, 팀장님이 OK를 주셔서 develop 브랜치에 merge까지 완료!

git add -p 로 부분 스테이징하여 커밋 쪼개기

1. 변경확인

git status

git reset HEAD^

╭─ ~/Desktop/git/beaverpay-mobile-android/beaverpay-mobile-android feature/MTT-81-QR 
╰─❯ git reset HEAD^
리셋 뒤에 스테이징하지 않은 변경 사항:
M    app/src/main/java/com/bw/bp/navigation/AppNavGraph.kt
M    gradle/libs.versions.toml
M    presentation/src/main/java/com/bp/presentation/viewmodel/QRViewModel.kt
M    reader/build.gradle.kts
D    reader/src/main/java/com/bp/reader/ErrorCode.kt
M    ui/src/main/java/com/bp/ui/view/QRScreen.kt

1. 부분적으로 스테이징 (patch 모드)

git add -p

작업 내용
╭─ ~/Desktop/git/beaverpay-mobile-android/beaverpay-mobile-android feature/MTT-81-QR ⇣1⇡1 !5
╰─❯ git add -p reader/build.gradle.kts gradle/libs.versions.toml
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 35b8d49..f00be0a 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -25,6 +25,7 @@ navCompose = "2.9.5"
 # Navigation 적용 [-]

 # Room 적용 [+]
+playServicesCodeScanner = "16.1.0"
 roomKtx = "2.8.4"
 roomRuntime = "2.8.4"
 ksp = "2.2.20-2.0.4"
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? y
@@ -96,6 +97,7 @@ androidx-navigation-compose = { module = "androidx.navigation:navigation-compose
 # Retrfit 적용 [+]
 logging-interceptor = { module = "com.squareup.okhttp3:logging-interceptor", version.ref = "loggingInterceptor" }
 okhttp = { module = "com.squareup.okhttp3:okhttp", version.ref = "okhttp" }
+play-services-code-scanner = { module = "com.google.android.gms:play-services-code-scanner", version.ref = "playServicesCodeScanner" }
 retrofit = { module = "com.squareup.retrofit2:retrofit", version.ref = "retrofit" }
 # Retrfit 적용 [-]

(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? y

diff --git a/reader/build.gradle.kts b/reader/build.gradle.kts
index 683db27..a34c763 100644
--- a/reader/build.gradle.kts
+++ b/reader/build.gradle.kts
@@ -19,6 +19,7 @@ dependencies {

     // ML Kit Barcode Scanning (권장)
     implementation(libs.barcode.scanning)
+    implementation(libs.play.services.code.scanner)

     //Camera
     implementation(libs.androidx.camera.core)
(1/1) Stage this hunk [y,n,q,a,d,e,?]? y

╭─ ~/Desktop/git/beaverpay-mobile-android/beaverpay-mobile-android feature/MTT-81-QR ⇣1⇡1 +2 !3
╰─❯ git commit -m "build: QR Scanner lib 추가"
[feature/MTT-81-QR b81a6dd] build: QR Scanner lib 추가
 2 files changed, 3 insertions(+)

1. 이제 hunk 마다 질문받게 됨

Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?

1. 원하는 부분만 스테이징한 후

git commit -m "first commit message"

1. 남은 변경 다시 분할해서 커밋

git add -p
git commit -m "second commit message"

필요한 만큼 반복.

🎯 결론

약 2주간 Kotlin Multiplatform(KMP)을 적용하며 개발을 진행해봤지만,

여러 기술적 제약과 시간 압박으로 인해

👉 Android / iOS 분리 개발(2 Track) 전략으로 최종 결정했다.

KMP를 포기한 건 아니지만,

지금 시점에서 KMP를 채택하는 것보다 일정 안정성이 더 중요하다는 판단이었고,

팀장님도 이를 이해해주셔서 과감히 방향을 바꿀 수 있었다.

🧩 KMP 진행 중 겪은 주요 이슈 정리

1️⃣

제한된 라이브러리 + 잦은 Breaking Changes

• KMP는 아직도 빠르게 진화 중

• JetBrains의 잦은 업데이트로 인해

  → 기존 라이브러리들과 버전 호환성 문제 및

  → 예상치 못한 운영 이슈가 발생할 가능성이 높다고 판단

• Android 위주로만 한다면 괜찮지만

  정말로 cross-platform 개발을 하기엔 아직 리스크가 컸다.

2️⃣

정형화된 구조(Expect/Actual & SQLDelight)

KMP는 원하는 대로 “설계 자유도”가 높지 않다.

🔹 예시: SQLDelight

• DB 관련된 모든 코드를

  sqldelight 패키지 안에 넣어야 함

• 구조적 자유도가 낮고 모듈화가 제한됨

🔹 예시: Expect / Actual

• commonMain/androidMain/iosMain

  동일 패키지, 동일 네이밍

• 정해진 룰을 반드시 지켜야 해서

  처음엔 상당히 헷갈리고 생산성이 떨어짐

⚠️ 개발할 때마다 “이건 어디에 넣어야 하지?” 라고 찾아야 하는 상황이 반복됨 → 고민 시간 증가 → 유지보수 난이도 증가

3️⃣

iOS 빌드 문제

KMP를 도입한 가장 큰 목적은 iOS 공용 코드 재사용이었는데…

• iOS에서 공통 모듈 함수가 인식이 안 되거나
• 빌드는 되지만 런타임에서 함수 이름 변경 문제 발생
• KMP + Swift 연결 과정도 쉽지 않음

❗ 이슈 분석 시간이 길어지다 보니, 데드라인 안에 기능 개발을 끝낼 수 없다는 판단이 생겼다.

🧠 최종 판단

이런 문제들을 매번 해결하면서 개발을 진행하기에는

• 일정 압박
• 기능 요구 증가
• KMP 경험 부족
• 실서비스 안정성

이 네 가지 조건이 너무 부담이었다.

그래서 팀장님께 현재 상황을 솔직하게 공유했고,

Android 우선 개발 → iOS는 뒤에서 별도로 진행

이렇게 “Two Track 전략”으로 가기로 결정했다.

팀장님이 이해해주신 것도 너무 감사했고,

덕분에 과도한 리스크 없이 빠르게 방향을 잡을 수 있었다.

🔙 2주간의 회고

솔직히 말하면…

“2주 동안 난 뭘 한 거지…?” 라는 생각이 잠깐 스쳤다. 하지만 곧 생각이 바뀌었다.

✔ KMP라는 기술을 직접 체감해봤고

✔ 구조적 제약과 문제점을 몸으로 이해했고

✔ 앞으로 KMP를 언제 적용해야 하는지 기준을 세웠고

✔ 팀 방향성에 도움을 줄 판단을 내릴 수 있었다

이건 결코 헛된 시간이 아니었다.

오히려 더 튼튼한 Android 구조를 만들 수 있을 것 같은 자신감이 생겼다.

🔥 앞으로의 목표

Android 앱이 현재 회사의 핵심이다.

팀장님의 신뢰에 보답하기 위해

→ 더 완성도 높은 아키텍처

→ 더 안정적인 코드

→ 더 빠른 기능 구현

을 목표로 다시 Android 개발에 집중할 예정이다.

✨ 마무리

돌고 돌아 다시 Android 단독 개발로 돌아왔지만,

지식도 늘었고, 실전 감각도 좋아졌고,

앞으로 KMP를 적용할 때 실패 없이 할 수 있는 경험을 쌓은 셈이다.

이제 다시 Android 코드 쓰러 간다.

🔥 “다시 화이팅!”

→ Koin = 런타임(Dynamic) DI 컨테이너

→ Hilt/Dagger = 컴파일 타임(Code-Generated) DI 컨테이너

→ 즉, Koin은 코드를 생성하지 않고, 앱 실행 중에 Service Locator 방식 + DSL 모듈 등록으로 DI를 수행함

2. Koin의 기본 원리

1. Koin 시작

    startKoin{
        androidContext(this@BeaverPayApp)
      modules(
          appModule,
          presentersModule,
          domainModule,
          dataModule,
          localModule,
          remoteModule,
          payonModule
      )
    }

   → 이렇게 하면 KoinApplication 객체가 생성되며 내부에 Instance Registry가 만들어짐

1. 정의된 module 등록

    val dataModule = module {
        includes(localModule) // local Module 포함
        single<UserRepository> {
            UserRepositoryImpl(get()) // get() -> LocalUserDataSource
        }
        single<PayonCardReaderRepository> {
            PayonCardReaderRepositoryImpl(get())
        }
    }
   
    val domainModule = module {
        // UseCase
        factory { CheckUserUseCase(get()) }
        factory { InsertUserUseCase(get()) }
        factory { PayonCardReaderUseCase(get()) }
    }
   
    val presentersModule = module {
        viewModel { ReaderViewModel(get()) }
        viewModel { LoginViewModel(get(), get()) }
        viewModel { MainViewModel() }
    }

   → 모듈에 등록되면 Koin은 이를 Key-Value 형태로 저장함

   Key	Value
   UserRepository	정의된 Provider 함수
   ReaderViewModel	Provider 함수

2. DI 발생 (get(), Inject(), viewModel() 호출 순간)

    val repo: UserRepository = get()

   → 이 순간 Koin은 다음 절차를 수행

   ex)

    val dataModule = module {
            single<UserRepository> { UserRepositoryImpl(get()) }
    }
   
    /*
    * 1. single<UserRepository> → "UserRepository 타입이 필요할 때, 이걸 써라" 라는 정의
    * 2. {UserRepositoryImpl(get())} → "생성 시 LocalUserDataSource 같은 의존성을 get() 해서 넣어라"
    * 3. 즉, UserRepository가 필요한 클래스의 생성자에서 요청될 때,
    *    Koin이 알아서 UserRepositoryImpl 인스턴스를 만들어 넣습니다.
    * 4. class ReaderViewModel(private val userRepository: UserResposigory)을 호출할 때 
    *    Koin 내부에서 get()이 자동으로 실행되는 것이다.
    */

   → Koin의 DI 동작 흐름

    get<UserRepository>() 요청
                    **↓**
    Koin Registry에 등록된 UserRepository Provider 찾기
                    **↓**
    싱글톤? → 이미 instance 있으면 반환
                    ↓
    없으면 Provider 함수 실행
                    ↓
    UserRepositoryImpl(get()) 실행
                    ↓
    내부 get() 으로 의존성 탐색 반복
                    ↓
    UserRepositoryImpl 인스턴스 생성
                    ↓
    Registry에 캐싱(싱글톤이면)
                    ↓
    결과 반환

   : 런타임에 필요한 객체를 모듈에서 찾아 직접 생성 → 반환하는 방식

1. Koin의 DI 특징

   • 런타임 해결

     → Koin은 실행 중에 객체 그래프를 계산함

   • 코드 생성 없음

     → Hilt/Dagger처럼 코드가 자동 생성되지 않음.

     → 그래서 빌드가 빠르고 구조가 단순

   • DSL 중심

     → 모든 DI 설정은 module {} DSL로 구성

1. Hilt와 비교하면?

| **항목** | **Koin** | **Hilt** |
| --- | --- | --- |
| DI 방식 | 런타임 | 컴파일 타임 |
| 성능 | 느릴 수 있음(런타임 분석) | 빠름(코드 생성) |
| 안정성 | 런타임 오류 ↑ | 컴파일 오류로 조기 발견 |
| 코드량 | 적음 | 많음(Annotation 필요) |
| KMP 지원 | 🌟 좋음 | 없음 |
| 멀티 모듈 | 쉬움 | 복잡함 |
| 학습 난이도 | 쉬움 | 어려움 |

2. Compose에서 ViewModel 주입

   • Navigaton 내 :

       val viewModel: LoginViewModel = koinViewModel()

   • 뒤에서 Koin은 :

     • 현재 NavBackStackEntry Scope 확인
     • ViewModelFactory 생성
     • 모듈에서 LoginViewModel 정의 찾음
     • 필요 의존성 get() + 인스턴스 생성
     • Lifecycle에 바인딩

3. 왜 Koin이 KMP에 적합한가?

   • Koin:

     • Kotlin Multiplatform 공식 지원
     • IOS에서도 Kotlin 객체를 주입 가능
     • Annotation Processor(KSP/KAPT) 필요 없음

   • Hilt

     • Android Studio용 → KMP 지원 불가능
     • 코드 생성이 플랫폼 종속이라 IOS 미지원

     → 결국 KMP 프로젝트는 Hilt 대신 Koin 사용이 정답.

요약

→ Koin은 런타임 DI 컨테이너로, 등록된 module에서 객체를 찾아 직접 생성하여 의존성을 해결한다.

코드 생성 없이 DSL 기반이라 구조가 단순하고 KMP 지원이 매우 좋다.

우리 팀은 Android와 iOS 두 플랫폼의 앱을 동시에 개발하는 것을 목표로 하고 있었다. 초기 계획은 Android는 Kotlin 기반의 네이티브 코드(Native Code) 로 개발하고, iOS는 React Native 를 활용해 크로스 플랫폼으로 구현하는 방식이었다.

하지만 조사 과정에서 KMP(Kotlin Multiplatform) 과 CMP(Compose Multiplatform) 을 알게 되었다. Kotlin과 Compose만으로 iOS까지 개발이 가능하다는 점은, iOS 전문 인력이 없는 우리 팀에게 매우 매력적인 선택지였다. 새로운 프레임워크(RN)를 학습하는 대신, 이미 익숙한 Kotlin과 Compose를 그대로 사용할 수 있었기 때문이다.

이에 따라 팀은 KMP 기반 개발로 전환하기로 결정하였다. 그러나 예상치 못한 문제가 하나 있었다 — 지금까지 Android에서 의존성 주입(Dependency Injection)을 위해 사용하던 Hilt가 KMP 환경에서는 지원되지 않는다는 점이었다.

결국 우리는 Hilt → Koin으로의 전환을 결정하게 되었고, 이 과정을 통해 KMP 환경에 맞는 구조와 의존성 주입 방식으로 프로젝트를 새롭게 정비하게 되었다.

❌ 왜 Hilt(=Dagger)는 KMP에서 쓸 수 없나?

1. Hilt/Dagger는 KSP/Annotation Processing 기반

   → KMP의 commonMain은 annotation processor를 사용할 수 없음

   → 즉, 공유 코드에서 Hilt 사용 자체가 불가능함

2. IOS에서는 Hilt가 동장할 수 없음

   → Hilt는 안드로이드 프레임워크 의존

   → IOS Swift에서는 Hilt 객체를 생성할 수 없음

   → 그래서 KMP에서 IOS가 사용하는 DI 구조 자체가 깨짐

⭐️ KMP 공식 추천 DI = Koin

1. Koin이 KMP를 공식 지원하는 이유

   → 공통 모듈(commonMain)에서 DI가 된다.

   • UseCase, Repository, Network 모두 공유 가능

   • Android/IOS 양쪽에서 같은 DI 구성 사용

     → IOS에서도 Kotlin 객체를 DI로 받아 사용 가능

   • Swift에서 바로 Koin으로 resolve 가능

     → Annotation Processor 없음 (런타임 DI)

   • KMP 환경에서 가장 안정적으로 동작

→ 같은 타입의 의존성이 2개 이상 있을 경우 Hilt가 자동으로 분류를 못 해준다. 그래서 Hilt에게 해당 부분은 이거야 라고 이름표를 붙여주는 것 “Qualifier” 입니다. 현재는 Payon부분만 구현되어있어 이러한 에러가 발생하지 않았지만 추후 결제 수단이 추가 될 경우 해당 부분은 필수로 작업해야한다.

1. 구조 변경

1. core:data ReaderStrategy.kt -> core:domain ReaderStrategy.kt 코드 위치 변경
→ 인터페이스는 항상 상위 계층에 있어야 함
→ Clean Architecutre 원칙 : 상위 계층(domain)은 하위 계층(data, implementation)에 의존하지 않는다.
                                                     하위 계층이 상위 계청(interface)에 의존해야 한다.

1. 코드 추가/변경

core:data:Qualifier.kt

/**
 * Qualifier(이름표) Annotation 만들기
 */

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class PayonReaderQualifier

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class SamsungPayReaderQualifier

core:data:ReaderFactory.kt

class ReaderFactory @Inject constructor(
    @PayonReaderQualifier private val payonReader: ReaderStrategy,
    @SamsungPayRederQualifier private val samsungReader: ReaderStrategy
) {
    fun getReader(type: ReaderType): ReaderStrategy = when (type) {
        ReaderType.PAYON -> payonReader
        ReaderType.SAMSUNG_PAY -> samsungReader
    }
}

core:payon:ReaderBindModule.kt

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

    @Binds
    @PayonReaderQualifier
    abstract fun bindPayonReader(
        impl: PayonReader
    ): ReaderStrategy

}

1. 전체 흐름 요약

ViewModel → UseCase → Repository → ReaderFactory → ReaderStrategy(Payon or Samsung)

1. UseCase

class CardReaderUseCase @Inject constructor(
    private val repository: CardReaderRepository
) {
    suspend operator fun invoke(type: ReaderType, tag: Tag): Flow<CardResult> {
        return repository.readCard(type, tag)
    }
}

→ Hilt는 생성자에 있는 CardReadRepository를 자동으로 주입해 준다.

→ 여기서 Repository는 실제 구현체가 아닌 Interface Type

1. Hilt가 Repository 구현체를 찾는 방법

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

    @Provides
    @Singleton
    fun provideCardReaderRepository(
        dataSource: CardReaderDataSource
    ): CardReaderRepository = CardReaderRepositoryImpl(dataSource)

}

CardReaderRepository 타입이 필요하면, CardReaderRepositoryImpl(dataSource)를 생성해서 제공해

1. Repository → DataSource

class CardReaderRepositoryImpl @Inject constructor(
    private val dataSource: CardReaderDataSource
) : CardReaderRepository {
    override suspend fun readCard(type: ReaderType, tag: Tag): Flow<CardResult> {
        return dataSource.readCard(type, tag)
    }
}

→ Hilt는 RepositoryImpl 객체를 만들 때 자동으로 DataSource를 넣어준다.

1. DataSource → ReaderFactory

class CardReaderDataSource @Inject constructor(
    private val factory: ReaderFactory
) {
    suspend fun readCard(type: ReaderType, tag: Tag): Flow<CardResult> {
        val reader = factory.getReader(type)
        return reader.readCard(tag)
    }
}

→ DataSource을 만들 때 Hilt는 ReaderFactory를 넣어준다.

1. ReaderFactory → ReaderStrategy 구현체 선택

class ReaderFactory @Inject constructor(
    private val payonReader: ReaderStrategy,
    private val samsungReader: ReaderStrategy
) {
    fun getReader(type: ReaderType): ReaderStrategy = when (type) {
        ReaderType.PAYON -> payonReader
        ReaderType.SAMSUNG_PAY -> samsungReader
    }
}

interface ReaderStrategy {
    suspend fun readCard(tag: Tag): Flow<CardResult>
}

class ReaderFactory @Inject constructor(
    @PayonReaderQualifier private val payonReader: ReaderStrategy,
    @SamsungReaderQualifier private val samsungReader: ReaderStrategy
)

→ 보통 각각 @Named 또는 @Qualifier로 구분해야 한다.

→ 현재는 Payon만 있어서 오류가 나지 않지만 SamsungPay까지 있으면 에러가 발생할 것이다.

1. ReaderStrategy(전략 객체) 실행

class PayonReader @Inject constructor(
    private val nfcAdapter: PayonNfcAdapter,
    private val api: RetrofitPayonApi
) : ReaderStrategy {

    override suspend fun readCard(tag: Tag): Flow<CardResult> = flow {
        ...
    }
}

→ Hilt는 PayonReader를 만들 때 필요한 의존성을 넣어준다.

1. 최종 결과 Flow 반환

ReaderStrategy → DataSource → Repository → UseCase → ViewModel → UI

🧩 전체 DI 구성도

ViewModel
    ↑
CardReaderUseCase  (Hilt inject)
    ↑
CardReaderRepository (Interface)
    ↑
CardReaderRepositoryImpl  (Hilt @Provides binds)
    ↑
CardReaderDataSource  (Hilt inject)
    ↑
ReaderFactory  (Hilt inject)
    ↑
ReaderStrategy 구현체 2개 (payonReader, samsungReader)

class PayonReader @Inject constructor(
    private val nfcAdapter: PayonNfcAdapter,
    private val payonApiService: RetrofitPayonApi
) : ReaderStrategy {

    companion object {
        // Payon SDK 접근
        const val clientType = "****"
        const val osVer = "**
        const val osName = ""****"
        const val appId = ""*********"
        const val validKey = ""*************"
        const val envCode = ""****"
        const val deviceId = ""*************"
    }

    override suspend fun readCard(tag: Tag): Flow<CardResult> = flow {

        emit(CardResult.Loading(true))

        val result = runCatching {

            // 인증 요청 + 실패 처리
            val auth = safeAuthRequest()

            // keySeed 생성 및 salt, vi, passphrase 생성
            TagCryptoConverter().extractCryptoParamsFromKeySeed(auth.key)

            // cid 추출
            val cid = nfcAdapter.getMifareCid(tag) ?: throw CardException.CidError("CID is null")

            // sector0 key 요청 데이터 만들기
            val sector0KeyRequestData = TagCryptoConverter().encryptMifareCid(cid)

            // sector0 key 요청 + 실패 처리
            val sector0Key = sector0KeyRequest(auth.trId ?: "", sector0KeyRequestData)

            // certifyCode 추출
            val certifyCode = nfcAdapter.getCertifyCode(tag, sector0Key) ?: throw CardException.CertifyCodeError("CertifyCode is null")

            // sector12 key 요청 데이터 만들기
            val sector12KeyRequestData = TagCryptoConverter().encryptCertifyCode(sector0KeyRequestData.payonCard.chipSerialNumber, certifyCode)

            // sector12 key 요청 + 실패 처리
            val sector12Key = sector12KeyRequest(auth.trId ?: "", sector12KeyRequestData)

            // encrypt card data 추출
            val encCardData = nfcAdapter.getEncCardData(tag, sector12Key) ?: throw CardException.CidError("Enc Card Data is null")

            CardResult.Success(CardData(encCardData,byteArrayOf(),byteArrayOf()))

        }.getOrElse { exception ->
            handleCardException(exception)
        }

        emit(CardResult.Loading(false))
        emit(result)
    }

    /**
     * 인증 요청 (예외 → CardException.NetworkError)
     */
    private suspend fun safeAuthRequest(): PayonAuthResponse {

        val response = payonApiService.auth(
            clientType = clientType,
            osVer = osVer,
            osName = osName,
            appId = appId,
            validKey = validKey,
            envCode = envCode,
            deviceId = deviceId
        )

        if (!response.isSuccessful) {
            val error = parseError(response)
            throw CardException.NetworkError(
                code = error?.code ?: response.code().toString(),
                message = error?.message ?: "Unknown server error"
            )
        }

        return response.body() ?: throw CardException.AuthError("Auth body null")

    }

    /**
     * Sector0Key 요청 (예외 → CardException.NetworkError)
     */
    private suspend fun sector0KeyRequest(transactionId: String, sector0KeyRequestData: SectorKeyDataRequest): String {

        val response = payonApiService.getSector0Key(
            clientType = clientType,
            osVer = osVer,
            osName = osName,
            appId = appId,
            validKey = validKey,
            envCode = envCode,
            deviceId = deviceId,
            trId = transactionId,
            body = sector0KeyRequestData
        )

        if (!response.isSuccessful) {
            val error = parseError(response)
            throw CardException.NetworkError(
                code = error?.code ?: response.code().toString(),
                message = error?.message ?: "Unknown server error"
            )
        }

        return TagCryptoConverter().decryptSector0Key(response.body()?.payonCard?.sector0KeyA ?: "")
    }

    /**
     * Sector0Key 요청 (예외 → CardException.NetworkError)
     */
    private suspend fun sector12KeyRequest(transactionId: String, sector12KeyRequestData: SectorKeyDataRequest): String {

        val response = payonApiService.getSector12Key(
            clientType = clientType,
            osVer = osVer,
            osName = osName,
            appId = appId,
            validKey = validKey,
            envCode = envCode,
            deviceId = deviceId,
            trId = transactionId,
            body = sector12KeyRequestData
        )

        if (!response.isSuccessful) {
            val error = parseError(response)
            throw CardException.NetworkError(
                code = error?.code ?: response.code().toString(),
                message = error?.message ?: "Unknown server error"
            )
        }

        return TagCryptoConverter().decryptSector12Key(response.body()?.payonCard?.sector12KeyA ?: "")
    }

}

class PayonNfcAdapter @Inject constructor(
    private val context: Context
) {
    private val nfcAdapter: NfcAdapter = NfcAdapter.getDefaultAdapter(context)

    fun getMifareCid(tag: Tag): ByteArray? {

        val mifare = MifareClassic.get(tag)

        return try {
            if(!mifare.isConnected){
                mifare.connect()
            }
            var id = mifare.tag.id
            if(id.isEmpty()){
                id = mifare.readBlock(0)
            }
            id
        } catch (e: Exception) {
            Timber.d("getMifareCid Exception : $e")
            null
        } finally {
            try {
                mifare.close()
            } catch (e: Exception) {
                Timber.d("mifare close Exception : $e")
            }
        }

    }

    fun getCertifyCode(tag: Tag, sector0Key: String): ByteArray?{

        val mifare = MifareClassic.get(tag)

        return try {
            if(!mifare.isConnected){
                mifare.connect()
            }

            val authenticateSector0 = mifare.authenticateSectorWithKeyA(0, Util().hexToByte(sector0Key))
            Timber.d("authenticateSector0 : $authenticateSector0")
            var certifyCode: ByteArray? = null
            if(authenticateSector0){
                certifyCode = mifare.readBlock(2)
                Timber.d("certifyCode : $certifyCode")
            }
            certifyCode

        } catch (e: Exception) {
            Timber.d("getCertifyCode Exception : $e")
            null
        } finally {
            try {
                mifare.close()
            } catch (e: Exception) {
                Timber.d("mifare close Exception : $e")
            }
        }
    }

    fun getEncCardData(tag: Tag, sector12Key: String): ByteArray?{

        val mifare = MifareClassic.get(tag)

        return try {

            if(!mifare.isConnected){
                mifare.connect()
            }

            val authenticateSector12 = mifare.authenticateSectorWithKeyA(12, Util().hexToByte(sector12Key))
            Timber.d("authenticateSector12 : $authenticateSector12")

            var encCardData: ByteArray? = null
            if(authenticateSector12){
                encCardData = mifare.readBlock( 48)
                Timber.d("encCardData : $encCardData")
            }
            encCardData

        } catch (e: Exception) {
            Timber.d("getEncCardData Exception : $e")
            null
        } finally {
            try {
                mifare.close()
            } catch (e: Exception) {
                Timber.d("mifare close Exception : $e")
            }
        }
    }

}

class TagCryptoConverter {

    companion object {
        private var keySeed: ByteArray?= null
        private var passphrase: String?= null
        private var salt: ByteArray?= null
        private var iv: ByteArray?= null
    }

    fun extractCryptoParamsFromKeySeed(key: String?){
        try {
            keySeed = Base64.decode(key, Base64.NO_WRAP)
            keySeed?.let { seed ->
                passphrase = CipherUtil.getPassphraseFromKeySeed(seed)
                salt = CipherUtil.getSaltFromKeySeed(seed)
                iv = CipherUtil.getIvFromKeySeed(seed)
            }
        } catch (e: Exception){
            CardException.TagCryptoError(
                message = "extractCryptoParamsFromKeySeed Error : ${e.message}"
            )
        }
    }

    fun encryptMifareCid(
        cid: ByteArray
    ): SectorKeyDataRequest {

        try {
            val encryptCid = CipherUtil.encrypt(Util().bytesToHex(cid).toByteArray(), passphrase, salt, iv)
            val base64Encoder = Base64.encodeToString(encryptCid, Base64.NO_WRAP)
            Timber.d("encryptMifareCid : $base64Encoder")

            return SectorKeyDataRequest(SectorPayonData(base64Encoder,null),"K1")
        } catch (e: Exception){
            throw CardException.TagCryptoError(
                message = "encryptMifareCid Error : ${e.message}"
            )
        }
    }

    fun decryptSector0Key(
        encryptSector0Key: String
    ): String {
        try {
            val base64Sector0Key = Base64.decode(encryptSector0Key, Base64.NO_WRAP)
            val sector0Key = String(CipherUtil.decrypt(base64Sector0Key, passphrase!!, salt, iv), StandardCharsets.UTF_8)

            return sector0Key
        } catch (e: Exception){
            throw CardException.TagCryptoError(
                message = "decryptSector0Key Error : ${e.message}"
            )
        }
    }

    fun encryptCertifyCode(
        base64Cid: String,
        certifyCode: ByteArray
    ): SectorKeyDataRequest{
        try {
            val encryptCertifyCode = CipherUtil.encrypt(Util().bytesToHex(certifyCode).toByteArray(), passphrase!!, salt, iv)
            val base64Encoder = Base64.encodeToString(encryptCertifyCode, Base64.NO_WRAP)

            return SectorKeyDataRequest(SectorPayonData(base64Cid,base64Encoder),"K1")
        } catch (e: Exception){
            throw CardException.TagCryptoError(
                message = "encryptCertifyCode Error : ${e.message}"
            )
        }
    }

    fun decryptSector12Key(
        encryptSector12Key: String
    ): String {
        try {
            val base64Sector12Key = Base64.decode(encryptSector12Key, Base64.NO_WRAP)
            val sector12Key = String(CipherUtil.decrypt(base64Sector12Key, passphrase!!, salt, iv), StandardCharsets.UTF_8)

            return sector12Key
        } catch (e: Exception){
            throw CardException.TagCryptoError(
                message = "decryptSector0Key Error : ${e.message}"
            )
        }
    }
}

/**
 * 공통 에러 처리 → CardResult.Error 변환
 */
fun handleCardException(exception: Throwable): CardResult.Error {
    return when (exception) {
        is CardException.NetworkError ->
            CardResult.Error(
                code = exception.code,
                message = exception.message ?: "Network error",
                throwable = exception
            )

        is CardException.AuthError ->
            CardResult.Error(
                code = "AUTH_ERROR",
                message = exception.message ?: "Auth error",
                throwable = exception
            )

        is CardException.CidError ->
            CardResult.Error(
                code = "CID_ERROR",
                message = exception.message ?: "CID read fail",
                throwable = exception
            )

        is CardException.CertifyCodeError ->
            CardResult.Error(
                code = "CERTIFY_CODE_ERROR",
                message = exception.message ?: "Certify Code read fail",
                throwable = exception
            )

        is CardException.EncCardDataError ->
            CardResult.Error(
                code = "ENC_CARD_DATA_ERROR",
                message = exception.message ?: "Enc Card Data read fail",
                throwable = exception
            )

        else ->
            CardResult.Error(
                code = "UNKNOWN",
                message = exception.message ?: "Unknown error",
                throwable = exception
            )
    }
}

sealed class CardException(message: String) : Exception(message) {
    class NetworkError(val code: String, message: String) : CardException(message)
    class AuthError(message: String) : CardException(message)
    class CidError(message: String) : CardException(message)
    class CertifyCodeError(message: String) : CardException(message)
    class EncCardDataError(message: String) : CardException(message)
    class TagCryptoError(message: String) : CardException(message)
    class UnknownError(message: String) : CardException(message)
}

1. 코드를 작성하면서 생각한 것 → 확장성을 생각한 공통 cardData, errorData 정의
2. 중복코드 제거 목표

feature/reader/viewmodel/ReaderViewModel.kt

 cardReaderUseCase(ReaderType.PAYON, tag).collect { result ->
      when(result){
          is CardResult.Loading -> {
              _uiEvent.emit(UiEvent.Loading(result.isLoading))
          }
          is CardResult.Success -> {
              _uiEvent.emit(
                  UiEvent.ShowDialog(
                      "카드인식 성공",
                      "Card : ${Util().bytesToHex(result.data.track2Data)}"
                  )
              )
          }
          is CardResult.Error -> {
              _uiEvent.emit(UiEvent.ShowDialog(result.code, result.message))
          }
      }
  }

core/domain/usecase

class CardReaderUseCase @Inject constructor(
    private val repository: CardReaderRepository
) {
    suspend operator fun invoke(type: ReaderType, tag: Tag): Flow<CardResult> {
        return repository.readCard(type, tag)
    }
}

core/domain/repository

interface CardReaderRepository {
    suspend fun readCard(type: ReaderType, tag: Tag): Flow<CardResult>
}

enum class ReaderType {
    PAYON,
    SAMSUNG_PAY
}

core/data/repository

class CardReaderRepositoryImpl @Inject constructor(
    private val dataSource: CardReaderDataSource
) : CardReaderRepository {
    override suspend fun readCard(type: ReaderType, tag: Tag): Flow<CardResult> {
        return dataSource.readCard(type, tag)
    }
}

core/data/source

class CardReaderDataSource @Inject constructor(
    private val factory: ReaderFactory
) {
    suspend fun readCard(type: ReaderType, tag: Tag): Flow<CardResult> {
        val reader = factory.getReader(type)
        return reader.readCard(tag)
    }
}

core/data/source/reader

interface ReaderStrategy {
    suspend fun readCard(tag: Tag): Flow<CardResult>
}

class ReaderFactory @Inject constructor(
    private val payonReader: ReaderStrategy,
    private val samsungReader: ReaderStrategy
) {
    fun getReader(type: ReaderType): ReaderStrategy = when (type) {
        ReaderType.PAYON -> payonReader
        ReaderType.SAMSUNG_PAY -> samsungReader
    }
}

core/data/di

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

    @Provides
    @Singleton
    fun provideCardReaderRepository(
        dataSource: CardReaderDataSource
    ): CardReaderRepository = CardReaderRepositoryImpl(dataSource)

}

1. payon 결제를 추가하면서 제일 먼저 생각한 것 → 확장성(추후 결제 로직)
2. 흐름

viewModel → useCase 호출 → repository 호출 → dataSource 호출 → readerFactory에서 type에 따라 payon or samsungPay reader 선택

1. 추가된 구조

추가된 구조
core/common
    - util/Util.kt (byte→String / String→byte 등 공통으로 쓰는 함수 정리)
    - NFCEventBus (NFC Tag 값 전달 → 다른 모듈에서 알 수 있는 방법 flow로 처리)
core/network
    → 전체적인 network 관리를 여기서 할 예정
core/payon
    → payon sector 접근 및 network통신 처리 (NFC를 읽는 기능은 MainActivity 공통으로 처리)
feature/reader
    → nfc 읽는 화면

@AndroidEntryPoint
class MainActivity : ComponentActivity() {

    private val nfcAdapter by lazy { NfcAdapter.getDefaultAdapter(this) }
    val currentRouteFlow = MutableStateFlow<String?>(null)
    val currentReadTypeFlow = MutableStateFlow<String?>(null)

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            val appState = rememberBeaverAppState()
            val navController = appState.navController
            BeaverPaySampleTheme {
                NavGraph(appState)
            }

            // NavRoute 변경 감지
            val navBackStack by navController.currentBackStackEntryAsState()

            LaunchedEffect(navBackStack) {
                val destination = navBackStack?.destination
                val args = navBackStack?.arguments

                val route = destination?.route
                val readType = args?.getString("readType")

                Timber.e("🔥 route changed = $route, readType = $readType")

                currentRouteFlow.value = route
                currentReadTypeFlow.value = readType
            }

        }

        // 📌 여기서 routeFlow 변화 감지하고 NFC on/off 처리
        lifecycleScope.launch {
            currentReadTypeFlow.collect { type ->
                Timber.e("🔄 routeFlow collect → $type")

                if (type == "payon") {
                    enableReaderMode()
                } else {
                    disableReaderMode()
                }
            }
        }
    }

    override fun onResume() {
        super.onResume()
    }

    override fun onPause() {
        super.onPause()
    }

    fun enableReaderMode() {
        Timber.e("🔵 enableReaderMode() 실행")
        nfcAdapter?.enableReaderMode(
            this,
            { tag ->
                Timber.e("ReaderMode Tag detected: ${tag.id.joinToString { "%02X".format(it) }}")
                NFCEventBus.onTagDetected(tag)
            },
            NfcAdapter.FLAG_READER_NFC_A or
                    NfcAdapter.FLAG_READER_NFC_B or
                    NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK,
            null
        )
    }

    fun disableReaderMode() {
        Timber.e("🟥 disableReaderMode() 실행")
        nfcAdapter?.disableReaderMode(this)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)

        Timber.e("🔥 onNewIntent 호출, ACTION = ${intent.action}")

        if (intent.action == NfcAdapter.ACTION_TECH_DISCOVERED ||
            intent.action == NfcAdapter.ACTION_NDEF_DISCOVERED ||
            intent.action == NfcAdapter.ACTION_TAG_DISCOVERED
        ) {
            val tag = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
                intent.getParcelableExtra(NfcAdapter.EXTRA_TAG, Tag::class.java)
            } else {
                @Suppress("DEPRECATION")
                intent.getParcelableExtra<Tag>(NfcAdapter.EXTRA_TAG)
            }

            if (tag == null) {
                Timber.d("Tag is NULL")
                return
            }

            Timber.e("✅ Tag detected! techList = ${tag.techList.joinToString()}")

            NFCEventBus.onTagDetected(tag)
        }
    }
}

object NFCEventBus {
    private val _nfcFlow = MutableSharedFlow<Tag>()
    val nfcFlow = _nfcFlow

    private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

    fun onTagDetected(tag: Tag) {
        scope.launch {
            _nfcFlow.emit(tag)
        }
    }
}

@HiltViewModel
class ReaderViewModel @Inject constructor(
    val cardReaderUseCase: CardReaderUseCase
) : ViewModel() {

    private val _tagInfo = MutableStateFlow("")
    val tagInfo = _tagInfo

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

    init {
        viewModelScope.launch {
            NFCEventBus.nfcFlow.collect { tag ->
                val id = tag.id.joinToString("") { "%02X".format(it) }
                _tagInfo.value = "Tag ID: $id"

                cardReaderUseCase(ReaderType.PAYON, tag).collect { result ->
                    when(result){
                        is CardResult.Loading -> {
                            _uiEvent.emit(UiEvent.Loading(result.isLoading))
                        }
                        is CardResult.Success -> {
                            _uiEvent.emit(
                                UiEvent.ShowDialog(
                                    "카드인식 성공",
                                    "Card : ${Util().bytesToHex(result.data.track2Data)}"
                                )
                            )
                        }
                        is CardResult.Error -> {
                            _uiEvent.emit(UiEvent.ShowDialog(result.code, result.message))
                        }
                    }
                }

            }
        }
    }
}

1. Compose에서 RouteFlow 변화를 감지하여 NFC ON/OFF 처리 담당

   → 현재는 reader/payon 일 경우 enable, 나머지일 경우 disable

2. NFC 인식 시 NewIntent에서 Tag 값을 *MutableSharedFlow*로 가지고 있음

3. ViewModel에서 collect해서 Tag값을 feature/reader 모듈로 가져올 수 있음

🔥 emit vs collect

→ 즉, 테스트의 품질을 수치로 시각화 해주는 도구이다.

🧩 Jacoco로 할 수 있는 것들

🔍 왜 사용하나?

⚙️ 측정 방식

Jacoco 적용 코드

JacocoPlugin.kt

import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.api.tasks.testing.Test
import org.gradle.kotlin.dsl.configure
import org.gradle.kotlin.dsl.register
import org.gradle.kotlin.dsl.withType
import org.gradle.testing.jacoco.plugins.JacocoPluginExtension
import org.gradle.testing.jacoco.tasks.JacocoReport

/*=======================================================================================
 *                                                                                      *
 *              Copyright(c) 2025, Beaverworks Inc., All rights reserved.               *
 *                                                                                      *
 *      Unauthorized copying of this file, via any medium is strictly prohibited        *
 *      Proprietary and confidential.                                                   *
 *                                                                                      *
========================================================================================*/

class JacocoPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        target.plugins.apply("jacoco")

        target.extensions.configure<JacocoPluginExtension> {
            toolVersion = "0.8.10"
        }

        target.tasks.withType<Test>().configureEach {
            finalizedBy("jacocoTestReport")
        }

        target.tasks.register<JacocoReport>("jacocoTestReport") {
            dependsOn(target.tasks.withType<Test>())

            // ✅ 커버리지 제외 파일 패턴
            val fileFilter = listOf(
                "**/R.class",
                "**/R$*.class",
                "**/BuildConfig.*",
                "**/Manifest*.*",
                "**/*Test*.*",
                "android/**/*.*",
                "**/*Module*.*",
                "**/*Database*.*",
                "**/*Dao*.*"
            )

            // ✅ 클래스 파일 경로 (AGP 8 대응)
            val kotlinDebug = target.layout.buildDirectory.dir("tmp/kotlin-classes/debug").get().asFile
            val javacDebug = target.layout.buildDirectory.dir("intermediates/javac/debug/classes").get().asFile

            classDirectories.setFrom(
                target.files(
                    target.fileTree(kotlinDebug) { exclude(fileFilter) },
                    target.fileTree(javacDebug) { exclude(fileFilter) }
                )
            )

            // ✅ 소스 디렉토리
            sourceDirectories.setFrom(
                target.files("src/main/java", "src/main/kotlin")
            )

            // ✅ 실행 데이터 (exec 파일 경로)
            executionData.setFrom(
                target.fileTree(target.layout.buildDirectory.asFile) {
                    include(
                        "jacoco/testDebugUnitTest.exec",
                        "outputs/unit_test_code_coverage/debugUnitTest/testDebugUnitTest.exec",
                        "**/*.ec"
                    )
                }
            )

            // ✅ 리포트 옵션
            reports {
                html.required.set(true)
                xml.required.set(true)
                csv.required.set(false)

                html.outputLocation.set(target.layout.buildDirectory.dir("reports/jacoco/html"))
                xml.outputLocation.set(target.layout.buildDirectory.file("reports/jacoco/jacoco.xml"))
            }

            // ✅ 파일 존재 여부 체크 (없을 경우 SKIP)
            onlyIf {
                val hasClass = classDirectories.files.any { it.exists() }
                val hasExec = executionData.files.any { it.exists() }
                if (!hasClass) println("⚠️ [JaCoCo] No class files found for ${target.path}")
                if (!hasExec) println("⚠️ [JaCoCo] No execution data found for ${target.path}")
                hasClass && hasExec
            }

            doLast {
                println("✅ Jacoco report → ${target.layout.buildDirectory.dir("reports/jacoco/html").get().asFile}")
            }
        }
    }
}

동작 결과

🧩 요약 — 현재 커버리지 현황

🔍 2️⃣ 왜 0%가 나왔을까?

🧠 3️⃣ 진짜 의미 있는 커버리지

→ 즉, “앱 로직 핵심부는 모두 커버되고 있다”는 뜻이다.

→ dao/db/di 이 세 가지는 대부분의 프로젝트에서 커버리지 제외 대상(fileFilter) 으로 지정했다.

🔹 현재 상황 • 샘플 프로젝트의 구조 및 기능이 Clean Architecture 기반으로 안정화됨 • 모듈화(core, feature, domain, data, testing)와 DI(Hilt), DB(Room) 적용 완료 • Test Code 적용 완료

🔹 남은 과제 • 테스트 코드 작성이 아직 익숙하지 않음 → 추후 점진적으로 보완 예정 • 기능별 시퀀스 다이어그램 작성을 통해 전체 데이터 및 흐름 정리 예정 • 차세대 개발 준비 단계로, 설계 검증 및 보완 중

🔹 앞으로의 방향 • “지금은 기초를 단단히 쌓는 단계” → 이후 유지보수와 확장이 쉬운 구조를 위해, 설계 품질 확보에 집중 • 모든 기능의 동작 플로우를 다이어그램으로 정리 후 → 본격적인 기능 단위 개발(Feature 단위 진입) 예정 • 실제 개발(코딩) 단계로 넘어가기 전 완벽한 기반 확보 목표

💪 마무리 다짐

“아직 테스트나 자동화는 어렵지만, 구조를 내 것으로 만들고 나면 분명히 편해질 거야. 지금은 단단한 기초를 쌓는 시간, 아자아자!”

1. TTD(Test-Driven Development) 란?

→ TDD는 켄트 벡(Kent Back) 이 고안한 소프트웨어 개발 방법론으로, “테스트 주도 개발” 이라는 이름 그대로 테스트를 먼저 작성하고 이를 기반으로 코드를 작성하는 방식이다. TDD는 다음과 같은 반복적인 과정을 통해 이루어진다.

• Red: 실패하는 테스트 작성
  • 먼저 작성한 테스트 케이스가 실패하도록 설계한다. 이는 구현되지 않은 기능을 명확히 정의하는 단계이다.
• Green: 테스트를 통과하는 최소한의 코드 작성
  • 테스트가 성공하도록 간단하게 코드를 구현한다. 이 단계에서는 최소한의 구현에 집중한다.
• Refactor: 코드 개선
  • 테스트가 통과한 후, 코드를 리팩터링하여 가동성과 유지보수성을 개선한다. 이때 테스트가 다시 실패하지 않도록 주의한다.

2. TDD의 기대 효과

• 버그 감소: 테세트를 기반으로 코드를 작성하기 때문에 코드의 안정성이 높아진다.
• 리팩터링 안정성: 코드 변경 시 테스트가 올바르게 동작하는지 보장
• 명확한 설계: 테스트 작성 과정에서 인터페이스와 로직이 자연스럽게 설계된다.

3. 어디까지 테스트를 진행할 것인지?

• 아직 정해지진 않았지만 우리팀은 비즈니스 로직까지만 테스트 코드를 진행하면 좋을 것 같다.

4. 테스트 코트 작성 방식

core:data:source / LocalUserDataSourceTest

package com.bw.data.local.source

import com.bw.data.local.dao.FakeUserDao
import com.bw.core.data.local.db.UserDatabase
import com.bw.core.data.local.entity.UserEntity
import com.bw.core.data.local.source.LocalUserDataSource
import junit.framework.TestCase
import kotlinx.coroutines.flow.first
import kotlinx.coroutines.flow.toList
import kotlinx.coroutines.test.runTest
import org.junit.Before
import org.junit.Test
import kotlin.test.assertEquals

class LocalUserDataSourceTest {

    private lateinit var dataSource: LocalUserDataSource

    @Before
    fun setup(){
        // Room DB 대신 Fake DAO 사용
        val fakeDao = FakeUserDao()
        dataSource = LocalUserDataSource(fakeDao)
    }

    @Test
    fun insert_and_get_user() = runTest {
        val user = UserEntity(user_phone = "01012345678", user_name = "홍길동")
        dataSource.insertUser(user)

        val count = dataSource.getUserByPhoneAndName("01012345678", "홍길동").first()
        TestCase.assertEquals(1, count)

        val users = dataSource.getAllUsers()

        // ✅ 성공 로그 출력
        println("✅ LocalUserDataSourceTest success → user not found, count: $count / users : ${users.toList()}")

    }

}

core:data:source / UserRepositoryImplTest

package com.bw.data.local.repository

import com.bw.core.data.repository.UserRepositoryImpl
import com.bw.core.domain.model.User
import com.bw.data.local.source.FakeLocalUserDataSource
import junit.framework.TestCase.assertEquals
import kotlinx.coroutines.flow.first
import kotlinx.coroutines.flow.toList
import kotlinx.coroutines.test.runTest
import org.junit.Test

class UserRepositoryImplTest {

    private val repository = UserRepositoryImpl(FakeLocalUserDataSource())

    @Test
    fun insert_and_fetch_user_success() = runTest {
        val user = User(phone = "01012345678", name = "홍길동")
        repository.insertUser(user)

        val count = repository.getUserByPhoneAndName("01012345678", "홍길동").first()
        assertEquals(1, count)

        val users = repository.getAllUsers()

        // ✅ 성공 로그 출력
        println("✅ UserRepositoryImplTest success → user not found, count: $count / users : ${users.toList()}")
    }
}

core:domain:usecase / CheckUserUseCaseTest

package com.bw.domain.usecase

import com.bw.core.domain.model.User
import com.bw.core.domain.usecase.CheckUserUseCase
import com.bw.core.testing.repository.FakeUserRepository
import junit.framework.TestCase.assertEquals
import kotlinx.coroutines.flow.first
import kotlinx.coroutines.test.runTest
import org.junit.Before
import org.junit.Test

class CheckUserUseCaseTest {

    private lateinit var fakeUserRepository: FakeUserRepository
    private lateinit var checkUserUseCase: CheckUserUseCase

    @Before
    fun setup(){
        fakeUserRepository = FakeUserRepository()
        checkUserUseCase = CheckUserUseCase(fakeUserRepository)
    }

    // ✅ 성공 로그 출력
    @Test
    fun `when user exists then return count 1`() = runTest { // User가 존재할 경우 -> 1을 반환
        // given (준비)
        val user = User(phone = "01012345678", name = "홍길동")
        fakeUserRepository.insertUser(user)

        // when (실행)
        val count = checkUserUseCase("01012345678", "홍길동").first()

        // then (검증)
        assertEquals(1, count)
        println("✅ CheckUserUseCaseTest success → user count: $count")
    }

    @Test
    fun `when user does not exist then return count 0`() = runTest { // User가 존재하지 않을 경우 -> 0을 반환
        // given
        fakeUserRepository.insertUser(User(phone = "01099999999", name = "이순신"))

        // when
        val count = checkUserUseCase("01012345678", "홍길동").first()

        // then
        assertEquals(0, count)
        println("✅ CheckUserUseCaseTest success → user not found, count: $count")
    }

}

feature:login:ui / LoginViewModelTest

package com.bw.feature.login.ui

import app.cash.turbine.test
import com.bw.core.domain.model.User
import com.bw.core.domain.usecase.CheckUserUseCase
import com.bw.core.domain.usecase.InsertUserUseCase
import com.bw.core.testing.repository.FakeUserRepository
import com.bw.core.ui.event.UiEvent
import kotlinx.coroutines.ExperimentalCoroutinesApi
import kotlinx.coroutines.test.runTest
import org.junit.Before
import org.junit.Test
import kotlin.test.assertEquals

@OptIn(ExperimentalCoroutinesApi::class)
class LoginViewModelTest {

    private lateinit var viewModel: LoginViewModel
    private lateinit var fakeRepository: FakeUserRepository

    @Before
    fun setup() {

        fakeRepository = FakeUserRepository()

        val fakeCheckUserUseCase = CheckUserUseCase(fakeRepository)
        val fakeInsertUserUseCase = InsertUserUseCase(fakeRepository)

        viewModel = LoginViewModel(fakeInsertUserUseCase,fakeCheckUserUseCase)
    }

    @Test
    fun `전화번호 미입력시 토스트 이벤트 발생`() = runTest {
        viewModel.updatePhone("")
        viewModel.updateName("홍길동")

        viewModel.uiEvent.test {
            viewModel.signIn()
            val event = awaitItem() as UiEvent.ShowToast
            assertEquals("전화번호를 입력해주세요.", event.message)
            println("💡 event.message = $event")
            println("✅ 전화번호 미입력 테스트 성공")
        }
    }

    @Test
    fun `전화번호 자릿수 오류시 토스트 이벤트 발생`() = runTest {
        viewModel.updatePhone("0101234")
        viewModel.updateName("홍길동")

        viewModel.uiEvent.test {
            viewModel.signIn()
            val event = awaitItem() as UiEvent.ShowToast
            assertEquals("휴대폰 자릿수를 확인해주세요.", event.message)
            println("💡 event.message = $event")
            println("✅ 전화번호 자릿수 오류 테스트 성공")
        }
    }

    @Test
    fun `이름 미입력시 토스트 이벤트 발생`() = runTest {
        viewModel.updatePhone("01012345678")
        viewModel.updateName("")

        viewModel.uiEvent.test {
            viewModel.signIn()
            val event = awaitItem() as UiEvent.ShowToast
            assertEquals("이름을 입력해주세요.", event.message)
            println("💡 event.message = $event")
            println("✅ 이름 미입력 테스트 성공")
        }
    }

    @Test
    fun `존재하지 않는 유저면 다이얼로그 이벤트 발생`() = runTest {
        viewModel.updatePhone("01000000000")
        viewModel.updateName("없는사람")

        viewModel.uiEvent.test {
            viewModel.signIn()
            val event = awaitItem() as UiEvent.ShowDialog
            assertEquals("로그인 실패", event.title)
            println("💡 event.message = $event")
            println("✅ 존재하지 않는 유저 테스트 성공: ${event.message}")
        }
    }

    @Test
    fun `존재하는 유저면 Navigate 이벤트 발생`() = runTest {
        fakeRepository.insertUser(User(0,"01012345678", "홍길동"))
        viewModel.updatePhone("01012345678")
        viewModel.updateName("홍길동")

        viewModel.uiEvent.test {
            viewModel.signIn()
            val event = awaitItem()
            assert(event is UiEvent.Navigate)
            println("💡 event.message = $event")
            println("✅ 로그인 성공 테스트 성공 (Navigate 이벤트 발생)")
        }
    }

}

샘플 프로젝트에서 모듈화를 진행하면서 모듈 수가 8개로 늘어났습니다. 각 모듈마다 build.gradle.kts 파일을 따로 관리해야 했는데, 이 파일들을 각각 수정하고 버전을 맞추는 과정이 점점 번거로워졌습니다.

특히, 공통 라이브러리 의존성을 모든 모듈에 중복으로 작성해야 한다는 점이 가장 큰 문제였습니다. 어떤 모듈에 어떤 라이브러리가 포함되어 있는지 한눈에 파악하기 어렵고, 버전이 달라지는 경우 모든 파일을 일일이 수정해야 하는 비효율이 발생했습니다.

이러한 문제를 해결하기 위해 공통 설정을 한 곳에서 집중적으로 관리하고, 모듈에서는 필요한 플러그인만 간단히 선언하도록 하기 위해 Gradle Convention Plugin을 도입하게 되었습니다.

1. build-logic/build.gradle.kts

   plugins {
    `kotlin-dsl`   // ✅ 반드시 필요
    kotlin("jvm") version "1.9.10"              // Kotlin JVM 플러그인 (버전은 프로젝트에 맞게 지정)
    id("java-gradle-plugin")                   // Gradle 플러그인 개발 플러그인
   }
   

dependencies { implementation(gradleApi()) // ✅ Gradle의 Project, Plugin, Extension 등 인식 가능 implementation(localGroovy()) // ✅ Groovy DSL 접근용

compileOnly(libs.android.gradlePlugin)     // Android Gradle Plugin API (AGP) 의존성
compileOnly(libs.kotlin.gradlePlugin)      // Kotlin Gradle Plugin API 의존성

implementation(libs.hilt.gradlePlugin)        // Hilt Gradle Plugin API 의존성 (필요 시)
implementation(libs.ksp.gradlePlugin)         // KSP Gradle Plugin API 의존성 (필요 시)

}

gradlePlugin { plugins { register("androidApplication") { id = "beaver.android.application" implementationClass = "AndroidApplicationConventionPlugin" } register("androidLibrary") { id = "beaver.android.library" implementationClass = "AndroidLibraryConventionPlugin" } register("androidApplicationCompose") { id = "beaver.android.application.compose" implementationClass = "AndroidApplicationComposeConventionPlugin" } register("androidLibraryCompose") { id = "beaver.android.library.compose" implementationClass = "AndroidLibraryComposeConventionPlugin" } register("hilt") { id = "beaver.android.hilt" implementationClass = "HiltConventionPlugin" } register("room") { id = "beaver.android.room" implementationClass = "RoomConventionPlugin" } } }

```

요즘은 하루하루 시간이 잘 가는 것 같다. 내가 적용하고 싶었던 기술들을 도입하면서 거기서 더 필요한 기능들을 찾게 되고 그것들을 배워가는 것이 너무 즐겁다.

이제 마지막 테스트 코드 작성을 하면 본 차세대 프로젝트를 시작하기 위한 준비는 끝이다!

남은 준비까지 화이팅!

샘플 프로젝트를 모듈 단위로 분리하는 작업을 드디어 완료했다. 작업을 진행할 때는 Google의 Now in Android 프로젝트를 참고했으며, Git에 정리된 모듈화 관련 문서들도 계속 참고하면서 진행했다. 중간중간 ChatGPT에도 여러 번 물어보며 방향을 잡았다.

작업을 하면서 정말 많은 고민을 했다. 어떤 파일을 공통 모듈로 둘지, DI는 어디에 두는 게 맞을지, 그리고 각 파일이 어떤 레이어에 속해야 할지 등 세세한 부분 하나하나가 쉽지 않았다.

지금은 기본적인 모듈 구조를 완성했지만, 아직도 내가 설계한 구조가 완전히 올바른지 확신은 없다. 앞으로도 계속 고민하고, 필요할 때마다 구조를 다듬어가며 지속적으로 업데이트할 예정이다.

간단한 설명

모듈화 후 Project Structure

차세대 프로젝트를 시작하기 전에 프로젝트의 뼈대를 잡는 샘플 프로젝트 개발을 맡게 되었다.

나는 나름대로 아키텍처 원칙을 지키며 레이어를 나누고 모듈화를 고려해 개발했다고 생각했다. 구조를 설계하면서 꽤 오랜 시간 고민도 했고, 각 역할에 맞게 분리했다고 자부했다.

하지만 팀장님이 생각하는 “모듈화”와 내가 생각했던 “모듈화”는 완전히 다른 방향이었다. ChatGPT에게 물어보면서도, 내가 만든 프로젝트가 사실상 Single Module Project였다는 걸 깨닫게 되었다..ㅠㅠ

즉, 아키텍처는 잘 지켰지만 물리적인 모듈 분리가 전혀 이루어지지 않은 상태였던 것이다. 그래서 이제는 이 프로젝트를 진짜 모듈화된 구조로 재설계하기로 마음먹었다.