월요일 오전 9시, 결제사 SDK가 바뀌면서 앱 내 승인 흐름이 세 갈래로 갈라졌다. QA는 “재현 조건이 매번 다르다”고 했고, PM은 수요일까지 베타를 다시 올려야 했다.
팀이 먼저 한 일은 UI를 고치는 일이 아니라 상태 이름을 통일하는 것이었다. Kotlin의 sealed class를 중심으로 승인, 거절, 재시도를 다시 정의했고, 그 다음부터 버그 리포트는 놀랄 만큼 짧아졌다.
이번 주에 실제로 한 일
월 09:10
상태 이름부터 다시 붙였다
“실패”, “재시도 가능”, “재인증 필요”를 코드와 QA 시트에 같은 용어로 적기 시작했다. 그 순간부터 회의 시간이 줄었다.
화 14:30
화면별 예외를 use case로 끌어올렸다
프래그먼트마다 흩어져 있던 분기를 하나의 흐름으로 묶으니, 어떤 화면이 어떤 규칙을 어겼는지 바로 보였다.
목 18:40
QA가 시나리오 중심으로 회귀를 돌렸다
버튼 탭 순서와 상태 전이만 체크해도 핵심 리스크를 빠르게 덮을 수 있었다.
“Kotlin이 특별해서가 아니라, 상태를 코드로 고정했기 때문에 사람들이 같은 문제를 같은 말로 볼 수 있었다.”
사업 현장에서 왜 통했나
이 앱은 하루 평균 결제 성공률을 숫자로만 보는 서비스가 아니었다. 고객센터, 제휴사 운영팀, QA가 함께 움직여야 했다. Kotlin은 그 협업 언어를 코드에서 먼저 정리하게 해 줬다.
특히 null 처리와 분기 표현이 과감히 드러나기 때문에 “빠뜨린 경우”를 찾는 회의가 줄었다. 출시 직전 팀이 원하는 건 새로운 추상화가 아니라 빠른 공통 이해인데, 그 지점에서 효과가 컸다.
현장에서 남긴 기준
- 상태 이름은 QA 시트와 코드에서 동일하게 쓴다.
- 화면에서 예외를 처리하지 말고 도메인 계층으로 끌어올린다.
- 릴리즈 주간에는 새로운 패턴 도입보다 읽기 쉬운 분기 정리가 우선이다.
이 글의 포인트
- Kotlin은 앱 팀의 문법 취향보다 상태 정리에 더 큰 효과를 낸다.
- 출시 직전에는 짧은 코드보다 합의된 용어가 더 중요하다.
- 안드로이드 프로젝트일수록 도메인 상태를 타입으로 잠가 두는 습관이 운영 비용을 줄인다.