NexPay 앱 개요 및 목표 → 빠른 시일 내 앱 개발 및 가능성 확보 기술 스택KotlinComposeClean ArchitectureMVI왜 Claude Code를 도입했는가? → 원래 Android Team은 Gemini를 사용할 목적이였다. (Androi

JUnit을 사용한 이유→ 안드로이드 테스트의 기본 테스트 프레임 워크Android 테스트 방법Local Unit Test (JVM Test) → 빠르고 가벼우며, 비즈니스 로직 / ViewModel / UseCase / Mapper 등의 순수 Kotlin 코드 테스

Kotlin 프로젝트에서도 AtomicReference 가 자주 등장하는데,그 이유는 Kotlin이 Java 기반 JVM 위에서 동작하며, 완벽한 대체 기능이 없기 때문이다.AtomicReference 는 락을 사용하지 않고(lock-free)여러 스레드에서 동시에 안

connect → startReader → send → (프레임 수신 콜백) → 모드 기준으로 계속/종료데이터는 STX(0x02) ~ ETX(0x03) + LRC(1byte) 프레이밍두 가지 수신 기준을 모두 지원:길이 헤더 기반 (두 번째 바이트가 ‘I’ 이고, 3.

최근 카메라 인식 기능을 개발하면서 외부 카메라 SDK를 사용해야 하는 일이 생겼다. 문제는, 현재 프로젝트는 거의 모든 기능이 모듈화(Modularization) 되어 있어, 기존처럼 Activity/Fragment의 onResume, onPause, onDest

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

2주간의 KMP 개발기 & 회고 🎯 결론 약 2주간 Kotlin Multiplatform(KMP)을 적용하며 개발을 진행해봤지만, 여러 기술적 제약과 시간 압박으로 인해 👉 Android / iOS 분리 개발(2 Track) 전략으로 최종 결정했다. KMP

1. Koin이 의존성 주입을 하는 방식 → Koin = 런타임(Dynamic) DI 컨테이너 → Hilt/Dagger = 컴파일 타임(Code-Generated) DI 컨테이너 → 즉, Koin은 코드를 생성하지 않고, 앱 실행 중에 Service Locator

🚀 우리 팀의 기술 선택 여정 ❌ 왜 Hilt(=Dagger)는 KMP에서 쓸 수 없나? Hilt/Dagger는 KSP/Annotation Processing 기반 → KMP의 commonMain은 annotation processor를 사용할 수 없음

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

코드를 작성하고 있는 중 Hilt는 어떻게 동작을 하는지 갑자기 엄청난 궁금증이 생겼다. 그래서 현재 코드를 가지고 어떻게 Hilt가 동작하는지 알아보자. 전체 흐름 요약 ViewModel → UseCase → Repository → ReaderFactory → R

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

Payon Module 호출 전 Flow payon 결제를 추가하면서 제일 먼저 생각한 것 → 확장성(추후 결제 로직) 흐름 > viewModel → useCase 호출 → repository 호출 → dataSource 호출 → readerFactory에서 typ

추가된 구조Compose에서 RouteFlow 변화를 감지하여 NFC ON/OFF 처리 담당 → 현재는 reader/payon 일 경우 enable, 나머지일 경우 disableNFC 인식 시 NewIntent에서 Tag 값을 \*MutableSharedFlow\*로

→ 테스트 코드가 실제로 애플리케이션 코드의 어느 부분까지 실행되었는지를 측정하는 도구→ 즉, 테스트의 품질을 수치로 시각화 해주는 도구이다.🧩 Jacoco로 할 수 있는 것들🔍 왜 사용하나?⚙️ 측정 방식JacocoPlugin.kt🔍 2️⃣ 왜 0%가 나왔을까?

🧱 프로젝트 회고 및 다음 단계 준비 요약 🔹 현재 상황 • 샘플 프로젝트의 구조 및 기능이 Clean Architecture 기반으로 안정화됨 • 모듈화(core, feature, domain, data, testing)와 DI(Hilt), DB(Room)

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

샘플 프로젝트에서 모듈화를 진행하면서 모듈 수가 8개로 늘어났습니다.각 모듈마다 build.gradle.kts 파일을 따로 관리해야 했는데,이 파일들을 각각 수정하고 버전을 맞추는 과정이 점점 번거로워졌습니다.특히, 공통 라이브러리 의존성을 모든 모듈에 중복으로 작성해

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

차세대 프로젝트를 시작하기 전에 프로젝트의 뼈대를 잡는 샘플 프로젝트 개발을 맡게 되었다.나는 나름대로 아키텍처 원칙을 지키며 레이어를 나누고 모듈화를 고려해 개발했다고 생각했다.구조를 설계하면서 꽤 오랜 시간 고민도 했고, 각 역할에 맞게 분리했다고 자부했다.하지만