🚀
현재 '해봄'은 플레이스토어에서 만나볼 수 있어요!
동기
항상 장기 서비스를 운영하고 싶다는 생각을 해왔는데, 출시가 쉽지 않더라구요..
취업할 때가 오니 운영 중인 서비스가 없다는 사실에 불안감이 커지기도 했습니다🥲
그러던 중 인스타그램에서 '스위프'를 발견했어요!
스위프는 수익화를 목표로 6주 안에 출시까지 완료해야 하는 활동으로, '단기간'이라는 것이 가장 큰 매력이었어요.
그래서 저는 앱 개발자로, 친한 언니는 서버 개발자로 동반 참여하게 되었습니다!
앱 4기 팀빌딩 & 일정
먼저 스위프 노션에 자신을 어필하는 '프로필 카드'를 쓰게 됩니다.
노션 페이지를 자유롭게 꾸미면 돼요.
저는 협업 경험, 작업/소통 스타일, 프로젝트 경험을 포트폴리오 쓰듯이 작성했습니다.
팀빌딩 전에 미리 다른 참가자 분들의 프로필 카드를 꼼꼼히 읽고 함께 하고 싶은 분들을 메모장에 적었어요 ㅎㅎ
팀빌딩이 시작되면 슬랙으로 디엠을 보내 같이 하자고 말씀드리면 됩니다!
솔직히.. 전쟁터 같았네요 🔫
1:1 디엠을 주고 받으며 팀을 꾸리다 보니 바로 답장하기 힘든 경우도 많았고, 정말 정신이 없었어요 ㅠㅠ
그리고 저희 팀은 서버 개발자 한 분이 마지막까지 잘 안 구해졌어서 밤 12시까지 슬랙을 붙들고 있었던 것 같습니다.
이번 기수는 유독 앱 개발자 수가 적었어서, 한 팀에 앱 개발자가 최대 한 명만 배정되었어요.
그래서 저희 팀은 PM 2, PD 3, APP 1(ME!!), BE 3 총 9명으로 구성되었습니다.
2월 넷째 주에 시작해 4월 둘째 주에 출시하는 일정이었고,
4월 넷째 주가 데모데이입니다.
6주 동안 앱을 출시하고, 2주 동안 홍보로 사용자를 모으며 지표를 분석하거나 앱을 디벨롭합니다.
문제는 이 6주가 순 개발 기간이 아니라, 생판 처음 보는 사람들이 모여 자기소개 하고, 어떤 서비스를 만들지 고민하는 시간이 포함되어 있다는 점입니다.
그래서 집중 개발 기간은 사실상 2주 였던 것 같아요.
저는 다행히 손 빠른 서버 개발자 분들을 만나서, 기획/디자인이 완료되는 동안 구글 소셜 로그인, FCM 연동 개발을 진행할 수 있었습니다.
기획/디자인 안 나와도 개발할 수 있는 부분은 꼭 미리 하셔야 수월히 완성하실 수 있어요!!
저희 팀은 안정적인 출시를 위해 3월 넷째 주에 앱을 완성, 3월 다섯 째주에 QA를 진행했습니다.
그래서 4월 둘째 주에 바로 출시를 시작할 수 있었어요.
리젝 당하다 !!
저는 두 번째 플레이스토어 출시인데요,
리젝은 처음 당해봐서 재밌었습니다!! 사유도 재밌어요!!!
1. 구글 계정으로 2단계 계정이 걸린 계정을 제출함
2. 제공한 계정으로 로그인이 안 되니 심사 직원 분이 (아마) 본인 계정으로 소셜 로그인
3. 새로 가입되어 온보딩 과정을 거치는데, 온보딩 필수 단계인 '닉네임' 입력이 한글로 제한됨. 직원 분은 필리핀 사람이었기 때문에 한글을 입력하지 못해 온보딩 완료 못하고, 메인에 진입 못함 -> 앱 정상 이용 불가하다 판단
저는 설정에서 2단계 인증을 해제했지만, 구글 계정을 만드는 중 한 번이라도 휴대폰 인증을 하면 로그인된 기기에 2단계 인증이 되는 것 같아요.
꼭 가입 하실 때 깡통 계정으로 잘 만들어 제출하셔야 합니다! ㅠㅠ
온보딩 닉네임은 영문/숫자/특수문자 모두 비허용하고 오직 한글만 허용하는 정책이었는데요,
생각해보니 한글을 안 쓰면 이 앱을 이용 자체를 못한다는게 어색하게 느껴지더라구요!
PM/PD 분들께 리젝 사유 말씀드려서 닉네임에 영문도 허용하는 것으로 정책을 변경해 심사 재요청을 하니 출시 되었어요 히히
참고로 스위프는 플레스토어 개발자 법인 계정을 대여해줍니다.
그래서 플레이스토어 출시 과정 중 가장 까다로운 2주 비공개 테스트를 패스할 수 있어요.
앱 등록부터 리젝, 최종 출시까지 7일 만에 완료 되었답니다!!
그리고 플레이스토어 출시가 처음이라면 플레이스토어 해시키의 존재를 잘 모르실 수 있어요.
소셜 로그인을 위해 디벨로퍼 콘솔에 디버그키/릴리즈키 해시키를 넣듯이, 플레이스토어에서 다운 받은 앱에서 소셜 로그인이 정상적으로 동작하려면 플레이스토어 해시키를 꼭 포함해 빌드해야 합니다.
플레이스토어 콘솔에서 '테스트 및 출시 > 앱 무결성 > Play 앱 서명 > 설정'에서 찾으실 수 있어요.
다른 팀들은 이 문제로 리젝 당하기도 했답니다🥲
그래서 스위프 추천 하나요?
스위프에 참여하면 뤼이도 유료 구독권, 개발자 계정, 오프라인 공간 등의 혜택을 받을 수 있습니다.
저는 개발자 계정으로 서비스를 안정적으로 마켓에 올려둘 수 있는 점이 가장 큰 장점으로 느껴졌어요.
어느 팀플이나 마찬가지겠지만, 스위프는 더더욱 팀원이 중요합니다!
6주 만에 기획부터 출시까지 완료한다는 건 결코 쉬운 과제가 아니에요.
스위프 공식 페이지에도 이미 경험이 있는 상태에서 실 사용자를 만나고, 수익화를 이루는 한 단계 더 높은 경험을 원하는 사람을 대상으로 한다고 적혀 있는 만큼 어느정도의 전문성을 가진 분께 추천드립니다.
저희 팀은 팀원 각자의 경험과 스타일이 다르다보니 조율에 어려움이 있었고, 덕분에 개발 외적으로도 커뮤니케이션 능력을 많이 키웠어요😅
저는 오히려 혼자서 안드로이드 개발 하고, 출시까지 전담하니 실력은 빠르게 늘었어요😊
제대로 된 안드로이드 개발은 3명 이상의 팀 단위로만 경험해 봤어서, 혼자서 프로젝트 구조부터 고민하며 더욱 더 하나의 서비스를 만들어나가는데 깊이 있는 고민을 할 수 있는 계기가 되었습니다.
어떤 걸 배웠는지!
1. 에러 처리
레포지토리에서 서버 에러 코드를 읽어 커스텀 에러로 분기 처리해 내려주어, 뷰모델은 커스텀 에러에 적절한 액션을 취할 수 있었습니다.
예를 들어 '습관 삭제' 시에 '이미 삭제된 습관'이라는 서버 에러가 오면 '이미 삭제된 습관입니다' 에러 토스트를 노출하고 리스트를 새로고침했어요!
특히나 BadRequest, NotFound, Conflict는 커스텀 에러를 우선 처리하고, 그 외의 케이스에서는 서버 메시지를 토스트로 보여주었어요. (서버 에러 메시지가 한국어 평문이었습니다)
그 외 Unauthorized, Forbidden, ServerError, NetworkConnection, Unknown은 고정 문구를 보여주어 에러 상황에서 사용자 친화성을 챙기려고 노력했습니다.
2. 스로틀링
버튼을 클릭하면 습관 생성 화면이 열리는 구조였는데, 버튼을 연타하니 네비게이션 스택이 여러 개 쌓여서 습관 생성 화면을 닫아도 또 생성 화면이 쌓이는 문제점이 있었어요.
저는 UDF 스타일의 MVVM 패턴 + BaseViewModel을 사용 중이었어요.
그래서 가능한 BaseViewModel에 스로틀링 로직을 넣어 일괄적으로 문제를 해결하고 싶었습니다.
MVVM이기 때문에 유저 클릭이 바로 뷰모델 메소드 호출로 이어졌습니다. 그래서 클릭 이벤트가 들어오는 것 자체에 스로틀링을 걸기는 어렵다고 판단했어요.
대신 sideEffect를 send하는 것에 집중했습니다! 아래는 제 BaseViewModel 코드 일부인데요, 뷰모델에서 sendEffect를 호출하면 바로 effect가 send되는 구조입니다.
abstract class BaseViewModel<S : UiState, E : UiEffect>(
initialState: S,
) : ViewModel() {
private val _uiState = MutableStateFlow(initialState)
val uiState: StateFlow<S> = _uiState.asStateFlow()
private val _sideEffect = Channel<E>(Channel.BUFFERED)
val sideEffect: Flow<E> = _sideEffect.receiveAsFlow()
protected fun sendEffect(effect: E) {
viewModelScope.launch {
_sideEffect.send(effect)
}
}
여기에 스로틀링이 적용된 sendEffect를 추가했고, 네비게이션을 sendEffect하는 경우 모두 sendThrottledEffect를 적용해주었어요.
private val lastEffectTime = ConcurrentHashMap<String, Long>()
protected fun sendThrottledEffect(
effect: E,
throttleMillis: Long = 500L,
customKey: String? = null,
) {
val key = customKey ?: effect::class.qualifiedName ?: return
val now = SystemClock.elapsedRealtime()
if (now - (lastEffectTime[key] ?: 0L) < throttleMillis) return
lastEffectTime[key] = now
viewModelScope.launch {
_sideEffect.send(effect)
}
}
아주 적은 변경으로 (뷰모델의 sendEffect를 sendThrottledEffect로만 교체) 제가 겪은 문제는 잘 해결되었지만,
임시로 구멍을 틀어 막은 것 뿐이라는 들어요🤔
1. 터치 이벤트 자체를 처리하는 것이 아님
2. 중복 이벤트에 대해 중복 effect가 발생하지 않게만 할 수 있음
3. 연타로 API가 호출되는 상황이라면 결국 개별 메소드에서 수동으로 막아야 함
그래서 점진적으로 MVI 패턴으로 리팩토링해, 유저 이벤트 자체를 Flow로 받아 좀 더 근본적인 스로틀링을 적용하고 싶은 생각입니다.
결론
저희 팀 다사다난 했지만 결과가 진짜 잘 나왔어요!
캐릭터 너무 귀엽고, 앱 완성도가 꽤 높아요. (제가 개발함ㅎㅎ)
데모데이에는 일정이 있어 참석하지 못하지만 발표 장표, 시연 영상 너무 멋지게 잘 만들어 주셨더라구요!
발표를 직접 보지 못해 아쉽네요🥲
그래도 스위프에서 구글 드라이브에 사진을 올려주셔서 간접적으로라도 현장을 체험해볼 수 있었습니다 ㅎㅎ
제가 질문 드리면 새벽에도 바로 달려와 답변 주시고, 혼자 개발하기 어렵지 않냐고 틈틈이 신경 써주신 팀원 분들 감사합니다!
해봄은 지속적으로 디벨롭할 예정이니 많은 관심 부탁드려요 👽👽
'Collaboration' 카테고리의 다른 글
| [Github][Slack] PR 노티봇을 만들어보자! (feat. 깜냥이) (4) | 2025.06.04 |
|---|