SMS 감지 후 텔레그램 포워딩 안드로이드 앱 초기 구조 완성
목차
새로운 프로젝트를 시작했다. SMS 메시지를 자동으로 감지해서 텔레그램으로 포워딩하는 안드로이드 앱이다. 실시간 알림이 중요한 환경에서 SMS를 놓치지 않으면서도 특정 메시지만 선별해서 메신저로 받고 싶은 요구가 있었다. 이 커밋은 그 프로젝트의 초기 뼈대를 잡은 작업이다.
초기 버전의 철학: 스코핑이 가장 중요하다
"초기 버전"이라는 표현을 썼다는 게 중요하다. 이게 단순한 라벨이 아니라 명확한 스코핑 결정을 반영한다.
많은 팀에서 초기 프로젝트를 시작할 때 가장 흔한 실수는 과도한 범위 확대다. 예를 들어 SMS 포워더라는 기본 요구에서 시작해서 "그럼 이메일도 지원하고, 카톡도 받고, 필터링 UI도 고급으로 만들고, 통계도 보여주고…" 같은 식으로 확장되는 경우를 봐왔다. 결국 초기 버전을 완성하는 데 반년이 걸리고, 피드백을 받으려던 시점이 훨씬 뒤로 밀린다.
이번엔 다르게 했다. MVP(최소 기능 제품)에 집중했다:
- SMS 감지 후 텔레그램 포워딩: 핵심 기능만
- 사용자 설정 저장: 토큰, 필터 같은 최소 옵션만
- 기본 UI: 켜고 끄고, 토큰 입력하고 끝
파일 구조에서 본 초기 결정들
| 파일 | 역할 | 초기 버전에서의 선택 |
|---|---|---|
.gitignore |
버전 관리 제외 | API 키, 토큰, 로컬 설정을 제외하는 것부터 보안 고려 |
README.md |
최소 문서화 | 초기엔 간단했겠지만 설정 방법, 권한 요구사항 정도는 포함 |
build.gradle.kts |
빌드 설정 | 텔레그램 라이브러리, SMS 수신 관련 기본 의존성만 |
AndroidManifest.xml |
앱 구성 선언 | READ_SMS, INTERNET, RECEIVE_SMS 권한 정도가 핵심 |
MainActivity.kt |
진입점 UI | 토큰 입력, 포워딩 온/오프 토글 정도 |
Prefs.kt |
설정 저장소 | SharedPreferences로 간단하게 (나중에 Room이나 DataStore로 마이그레이션 가능) |
이 파일 구성에서 주목할 점은 선택과 집중이다. 예를 들어 Prefs.kt를 보면, 안드로이드에서 설정을 저장하는 방법은 여러 개다:
- SharedPreferences (단순, 빠름)
- Encrypted SharedPreferences (보안이 필요할 때)
- Room 데이터베이스 (복잡한 스키마가 필요할 때)
- DataStore (최신, Kotlin 친화적)
초기 버전에서는 SharedPreferences를 선택했을 가능성이 높다. 이건 "지금 당장 필요한 것"과 "나중에 개선할 것"을 명확히 했다는 뜻이다.
팀 관점에서의 회고
이런 식으로 초기 버전을 구성했을 때 얻는 이점들:
1. 피드백 사이클 단축
프로토타입을 빨리 완성하고 사용자나 팀에게 보여줄 수 있다. "이 정도면 충분한가, 뭐가 더 필요한가" 같은 피드백을 받으면 방향을 조정할 수 있다.
2. 코드 리뷰와 온보딩이 쉬워진다
파일 수가 적고, 각 파일이 단순하면 새로운 팀원이 코드를 이해하기 쉽다. "이게 뭘 하는 앱인가?" 물었을 때 5분 안에 설명할 수 있다.
3. 기술 부채를 의도적으로 관리한다
SharedPreferences로 시작한다는 건 "나중에 더 나은 저장소로 마이그레이션할 예정"이라는 선언과 같다. 문제는 그렇게 표시하지 않으면 팀이 영원히 모른다는 거다.
// Prefs.kt 초기 버전의 패턴
object Prefs {
fun saveTelegramToken(context: Context, token: String) {
// TODO: 나중에 암호화된 저장소로 마이그레이션 고려
context.getSharedPreferences("app_prefs", Context.MODE_PRIVATE)
.edit().putString("tg_token", token).apply()
}
}
이런 식으로 TODO를 남기거나, PR에서 "기술 부채"를 명시하는 게 중요하다.
다음 단계를 염두에 둔 설계
초기 버전이지만 다음을 생각했을 것 같다:
- SMS 수신 리스너는 BroadcastReceiver로 (백그라운드 처리 필수)
- 텔레그램 API 호출은 별도 스레드/코루틴 (메인 스레드 블로킹 금지)
- 사용자 설정은 분리된 Prefs.kt로 (나중에 교체 가능한 인터페이스)
이런 결정들이 "초기 버전"이 단순하면서도 확장 가능하게 만든다. 훨씬 나중에 배경 동기화를 추가하거나, WorkManager로 재시도 로직을 넣거나, 필터 규칙을 복잡하게 확장할 때도 기본 구조를 안 건드려도 된다.
이 커밋을 통해 배운 건, 새로운 프로젝트는 스코핑이 코딩보다 중요하다는 거다. 멋진 기능보다 "지금 꼭 필요한 것"을 먼저 명확히 하고, 나머지는 의도적으로 미루기. 그게 초기 버전을 빨리 마치고, 팀이 함께 평가하고, 방향을 정정할 수 있게 만든다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.