모바일 앱 기능 런칭 삽질기
알림폰 서비스 런칭
"안드로이드만 되고 iOS는 안 된다고요?"
2023년 11월, 모바일PC폰 프로젝트 킥오프 미팅에서 받은 청천벽력 같은 소식이었다.
양쪽 OS 모두 배포할 계획이었는데, iOS 정책 때문에 안드로이드만 가능하다니.
그렇게 시작된 5개월간의 모바일 앱 기획은 내가 경험한 프로젝트 중 가장 많은 변수와 제약이 있었던 도전이었다.
freepik 무료 이미지 사용앱 기획의 어려움
프로젝트의 배경
2023년 11월, K사에서 새로운 부가서비스 기획 미션이 떨어졌다. 기존 PC폰 서비스(고객 전화 수신 시 PC 화면에 고객 정보가 팝업으로 뜨는 기능)를 모바일로 확장하는 것이었다.
시장 니즈 분석
미용실 사장님들의 니즈는 명확했다:
"매장에 계속 있을 수 없어요. 밖에 나갔을 때도 고객 전화를 받으면 누구인지 알고 싶어요."
"휴대폰으로 전화받을 때 고객 이름만 떠도 지난 시술 내역이 바로 떠오를 텐데..."
"타 CRM 프로그램은 모바일 알림이 되던데, 왜 우리는 안 돼요?"
경쟁사 분석 결과, 이미 유사 기능을 제공하는 CRM 서비스들이 있었다. 타사 프로그램 대비 경쟁력 강화가 시급했다.
iOS의 벽: 첫 번째 좌절
양쪽 OS 배포 계획의 좌초
처음 기획안을 작성할 때는 당연히 Android와 iOS 모두 지원하는 것으로 계획했다. 한국 스마트폰 시장에서 iOS 점유율이 약 30%인데, 이를 무시할 수 없었다.
더욱이 GA(Google Analytics) 데이터를 분석한 결과, CRM 앱 사용자의 60%가 iOS 유저였다. 일반 시장 점유율보다 훨씬 높은 비율이었다. 미용실 사장님들이 아이폰을 선호한다는 뜻이었다.
하지만 기술 검토 과정에서 충격적인 사실을 알게 되었다.
iOS의 엄격한 정책
iOS는 보안과 프라이버시 보호를 이유로 통화 관련 정보에 대한 접근을 극도로 제한하고 있었다:
통화 중 수신자 정보를 앱에서 읽을 수 없음
통화 기록에 대한 실시간 접근 불가
백그라운드에서 통화 이벤트 감지 불가
즉, 우리가 만들고자 하는 핵심 기능 자체가 iOS에서는 원천적으로 불가능했다.
사용자 반발 예상
팀 내부 회의에서 가장 큰 논란이 되었던 부분이었다.
"아이폰 사용자들이 항의하면 어떡하죠?" "부가서비스인데 일부 사용자만 쓸 수 있다는 게 말이 되나요?"
하지만 현실적으로 선택지가 없었다. iOS 정책을 바꿀 수는 없었고, 안드로이드 사용자들에게라도 제공하는 게 아예 출시하지 않는 것보다는 나았다.
결정: 안드로이드 우선 출시
결국 다음과 같이 전략을 수정했다:
1차로 안드로이드 버전만 출시
서비스 소개 시 "안드로이드 전용"임을 명확히 고지
iOS 정책 변경 시 빠르게 대응할 수 있도록 설계
안드로이드 버전 안정화 후 iOS 대안 기능 검토
안드로이드 버전 제약사항
OS 버전 파편화 문제
안드로이드로 결정했지만 문제는 계속되었다. 안드로이드는 버전별로 권한 정책이 달랐다.
기획서에 명시한 제약사항:
안드로이드 6.0.0 미만 버전은 지원 불가
이유: 권한 관리 시스템이 도입된 것이 6.0부터
당시(2023년) 기준으로 6.0 미만 버전 사용자는 약 5%였지만, 미용실 사장님들 중 오래된 기기를 사용하는 분들이 있을까 걱정되었다.
필수 권한의 복잡성
모바일PC폰 기능을 위해 필요한 권한들:
전화 권한: 수신자 식별
통화기록 권한: 수신자 정보 수집
알림 권한: 앱푸시 표시
배터리 최적화 끄기: 백그라운드 안정성
4개의 권한 중 하나라도 허용하지 않으면 기능이 작동하지 않는다. 하지만 사용자 입장에서 4개의 권한을 모두 허용하는 건 부담스러운 일이었다.
권한 요청 UX 설계의 어려움
권한을 요청하는 순서와 방식이 중요했다:
앱 설치 직후에 바로 권한을 요청하면 거부율이 높다
그렇다고 너무 늦게 요청하면 사용자가 불편을 느낀다
각 권한이 왜 필요한지 명확하게 설명해야 한다
기획 과정에서 보안 검토를 거쳐 접근권한 안내 방식을 대폭 수정했다. 더 투명하고 사용자 친화적으로 바꾸는 작업이었다.
freepik 무료 이미지 사용사용자 앱 연동의 기술적 챌린지
실시간 동기화의 복잡성
PC와 모바일의 데이터 동기화
모바일PC폰의 핵심은 PC CRM 시스템과 모바일 앱이 실시간으로 연동되어야 한다는 것이었다.
기획서에서 정의한 동작 구조:
mermaid code 사용이 전 과정이 전화벨이 울리는 몇 초 안에 완료되어야 했다. 조금이라도 지연되면 사용자는 "느리다"고 느낀다.
예외 케이스의 늪
기획을 진행하면서 생각지 못한 예외 케이스들이 계속 나왔다:
전화를 받은 상태에서의 처리 앱푸시가 뜨기 전에 전화를 받으면? 답: 늦더라도 수신 정보 제공 (통화 중에도 정보 확인 가능)
통화 도중 다른 전화가 오면? 첫 번째 통화 중에 두 번째 전화가 인입되면? 답: 새로운 콜 정보로 앱푸시 교체, 첫 번째는 부재중 처리
폰이 꺼져 있거나 잠금 상태일 때 폰 종료 상태: 앱푸시 알림 제공 안 함 잠금 화면: 백그라운드 활성화된 경우만 앱푸시 제공
네트워크 연결이 안 된 상태 WiFi도 데이터도 없으면? 답: 앱푸시 알림 제공 불가 (당연하지만 명시 필요)
이런 예외 케이스들을 모두 기획서에 정책으로 명시해야 했다. 개발팀과 QA팀에서 빠뜨리지 않고 테스트할 수 있도록.
백그라운드 실행의 난제
배터리 최적화와의 전쟁
가장 큰 기술적 챌린지는 안드로이드의 배터리 최적화 정책이었다.
안드로이드는 배터리 절약을 위해 백그라운드 앱을 자동으로 종료한다. 하지만 모바일PC폰은 백그라운드에서 항상 대기하고 있어야 한다.
배터리 사용량 제한 해제
기획서에서 가장 고민했던 부분:
배터리 최적화 끄기 설정을 필수로 해야 하나?
사용자에게 어떻게 설명하고 유도할 것인가?
최종 결정:
필수 권한에 포함시키되, 강제 랜딩은 하지 않음
별도 가이드 문서로 제공
이유: "권한 설정 유도가 너무 많으면 사용성 불편"
이게 나중에 문제가 되었다. 일부 사용자들이 이 설정을 하지 않아서 앱푸시가 안 뜨는 민원이 많이 들어왔다.
개인정보 보호 이슈
민감한 고객 정보 처리
앱푸시로 고객 정보를 보여줄 때 가장 조심해야 할 부분은 개인정보 보호였다.
기획서 ver 1.2에서 추가된 보안 정책:
앱푸시 클릭 시 랜딩되는 고객 상세 페이지에서는 주소와 생년월일 정보 제외
이유: 잠금 화면에서도 앱푸시가 보일 수 있어, 제3자가 볼 위험
하지만 이것도 문제였다. 미용실에서는 고객의 생년월일이 중요한 정보였다(생일 쿠폰 발송 등). 정보 보호와 업무 편의성 사이의 줄타기였다.
직급별 권한 설정
보안 검토를 거치며 추가된 기능:
원장님, 관리자, 디자이너, 스텝별로 다른 권한 부여
예: 스텝 계정은 고객 전화번호 마스킹 처리
PC폰 수신 목록 삭제 권한도 직급별로 설정
이를 모바일에도 동일하게 적용하는 게 생각보다 복잡했다.
앱 푸시 누적 기능
부재중 전화 관리
전화를 못 받았을 때도 나중에 확인할 수 있어야 했다.
기획한 기능:
미확인 앱푸시는 상단바에 누적 표시
펼치기 하면 리스트로 확인 가능
각 항목 클릭 시 [고객정보보기] [PC폰 목록 더보기] 버튼 제공
스와이프로 삭제 가능
이 기능 덕분에 부재중 전화도 놓치지 않고 나중에 확인할 수 있었다.
freepik 무료 이미지 사용부가서비스 정책 수립 과정
가격 정책의 고민
기존 PC폰 vs 모바일PC폰
K사는 이미 PC폰 서비스를 유료로 제공하고 있었다. 모바일PC폰을 어떻게 과금할 것인가가 큰 이슈였다.
검토한 옵션:
PC폰 사용자에게 무료 제공
별도 부가서비스로 추가 요금 부과
PC폰 가격을 인상하고 모바일 포함
최종 결정: 하이브리드 모델
PC폰 기존 사용자: 모바일PC폰 무료 제공
모바일PC폰만 사용하고 싶은 고객: 월 3,000원
이 정책이 합리적인 이유:
기존 고객에게 추가 부담 없음
모바일만 필요한 소규모 매장도 유입 가능
점진적으로 모바일 사용자 확대
부가서비스 신청 프로세스
ERP 시스템 전면 수정
모바일PC폰 부가서비스 추가를 위해 기존 ERP 시스템 여러 곳을 수정해야 했다:
빌링 시스템 기존 "이미지등록" 항목을 "모바일PC폰"으로 변경 월 3,000원 과금 정책 반영
부가서비스 관리 상담 신청 현황에 "모바일PC폰" 항목 추가 계약 신청 현황에 "모바일PC폰" 항목 추가
온라인 신청서 신규 가입 신청서에 "모바일PC폰" 선택 옵션 추가 서비스 할인 구분에 추가
이 모든 작업을 개발팀과 협의하면서 진행해야 했다.
사용 권한 설정의 복잡성
CRM 설정 페이지 추가
기획서 ver 1.4에서 추가된 기능:
설정 > 장비설정 > 모바일PC폰 사용여부
디폴트: 사용
옵션: 사용 / 미사용
설정 변경 시 앱 자동 로그아웃 → 재로그인 안내
왜 이런 설정이 필요했을까?
일부 매장에서는 모바일PC폰을 쓰고 싶지 않은 직원이 있을 수 있다. 예를 들어:
개인 휴대폰과 업무 경계를 명확히 하고 싶은 경우
배터리 소모를 최소화하고 싶은 경우
하지만 여기서 중요한 정책:
미사용으로 설정해도 요금은 계속 과금
이유: 서비스 자체를 해지하는 게 아니라 개인 설정이므로
이 부분이 나중에 CS 이슈가 되었다. "안 쓰는데 왜 과금되냐"는 문의가 많았다.
로그인 유지 정책 변경
사용 시간 설정 기능
기존 모바일 앱 정책
접속 후 12시간 경과 시 자동 로그아웃
하지만 모바일PC폰 사용자에게는 이게 문제였다. 밤에 로그아웃되면 다음날 아침 전화 받을 때 앱푸시가 안 뜬다.
신규 정책
개발 과정에서 추가된 정책으로, 설정 > 사용권한설정 > 사용시간설정 메뉴를 신설했다:
디폴트: 미사용 (기존과 동일하게 12시간 후 로그아웃)
사용 시: 설정 시간 동안 자동 로그아웃 안 됨
예: 00:00~23:59로 설정하면 하루 종일 로그인 유지
이 기능을 직급별로 설정할 수 있게 했다:
원장님, 관리자, 디자이너, 스텝 각각 설정 가능
다중 알림 통합
KH, 모바일명함 연동
기획 후반부에 추가된 기능으로, 모바일PC폰만이 아니라 다른 알림도 앱푸시로 제공하기로 했다:
KH 예약 알림 (연동 매장 대상)
모바일명함 예약접수 알림 (연동 매장 대상)
월 사용료 청구 알림 (원장님만)
각 알림별로 다른 아이콘과 문구:
모바일PC폰: � "CRM ○○○고객 전화가 왔어요~"
KH: ✂️ "KH 고객 예약이 왔어요~!"
모바일명함: ✅ "CRM 모바일명함 예약이 접수되었어요~!"
요금 청구: � "CRM 요금 청구서가 발행되었습니다"
이 모든 알림을 하나의 앱 설정에서 온/오프할 수 있게 했다.
PC폰 수신 목록 기능
통화 이력 관리
앱푸시만으로는 부족했다. 나중에 통화 이력을 확인할 수 있어야 했다.
기획한 기능:
매장 메뉴 > PC폰 목록
당일 기준 최대 31일 전까지 조회 가능
수신, 발신, 부재중 구분 표시
고객명, 전화번호로 검색 가능
직급별 권한에 따라 삭제 가능
이 페이지에서 리스트 클릭하면 해당 고객의 상세 정보 페이지로 이동한다.
5개월의 험난한 여정
반복적인 수정과 개선
초기 기획부터 최종 버전까지
2023년 11월 초안 작성부터 2024년 1월 최종 버전까지, 기획안은 끊임없이 수정되었다:
초안: 기본 모바일PC폰 기능만 포함
1차 수정: PC폰 수신 목록 추가
2차 수정: 보안 검토 반영, 대폭 수정 접근 권한 안내 방식 변경 개인정보 보호 정책 강화 상세 고객정보 페이지 정보 제한
3차 수정: 개발 회의 결과 반영 일부 기능 제외 및 추후 개선으로 분류 접근 권한 동의 철회 방식 수정 로그아웃 정책 수정
4차 수정: 추가 기능 구현 담당자 권한 설정 ERP, 어드민 부가서비스 영역 변경
5차 수정: 다중 알림 통합 KH 예약 알림 모바일명함 예약 알림 월 사용료 청구 알림
수정을 거듭할수록 기획안은 두꺼워졌고, 복잡도도 증가했다.
개발/QA 단계의 어려움
2024년 3월, 드디어 개발 완료 및 QA 진행
하지만 QA 과정에서 수많은 버그가 발견되었다:
특정 기기에서 앱푸시가 안 뜨는 문제
백그라운드에서 앱이 종료되는 문제
권한 허용 후에도 기능이 작동하지 않는 문제
누적 알림이 제대로 업데이트되지 않는 문제
각 버그를 재현하고, 원인을 파악하고, 수정 방향을 정의하는 과정이 반복되었다.
freepik 무료 이미지 사용런칭 후 피드백
2024년 4월, 정식 런칭
초기 사용자 피드백:
긍정적: "이제 밖에서도 고객 전화를 구분할 수 있어서 편해요"
부정적: "아이폰은 왜 안 되나요?", "배터리가 너무 빨리 닳아요"
특히 iOS 미지원에 대한 불만이 많았다. 기획 단계부터 예상했던 부분이지만, 실제로 민원이 들어오니 마음이 무거웠다.
초기 성과와 한계
런칭 후 3개월 성과:
기존 PC폰 사용자 중 약 60%만 모바일PC폰으로 전환 (목표: 80%)
CRM 서비스 모바일 전환 유도에는 기여했으나, 예상보다 낮은 전환율
목표 미달의 원인 분석
왜 80% 목표를 달성하지 못했을까?
권한 허용 과정의 복잡성: 4개 권한을 모두 허용해야 한다는 점이 진입 장벽
배터리 소모 우려: 백그라운드 실행에 대한 사용자 부담
iOS 미지원 불만: 아이폰 사용자들의 박탈감
충분하지 않은 사용성: 초기 버전의 미흡한 UX
이 결과를 바탕으로 Phase 2 개선 계획을 수립했다:
권한 요청 프로세스 간소화 방안 검토
배터리 최적화 개선
iOS 대안 기능 재검토
사용자 피드백 기반 UX 대폭 개선
목표를 달성하지 못한 것은 아쉬웠지만, 명확한 개선 방향을 찾을 수 있었다. 완벽한 첫 출시는 없다. 중요한 건 데이터를 기반으로 지속적으로 개선해나가는 것이다.
교훈과 반성
플랫폼 제약을 미리 파악하라
iOS 정책을 초기에 제대로 파악했다면 기획 방향을 다르게 잡을 수 있었을 것이다. 플랫폼별 기술 제약은 프로젝트 초기에 반드시 확인해야 한다.
권한 요청은 신중하게
4개의 권한을 요청하는 것이 사용자에게 큰 부담이었다. 좀 더 단계적으로, 필요한 시점에 요청하는 UX를 설계했다면 더 좋았을 것이다.
예외 케이스는 끝이 없다
"이 정도면 다 커버했겠지"라고 생각한 순간, 새로운 예외 케이스가 발견되었다. 기획자는 항상 "만약 ~라면?"을 끊임없이 질문해야 한다.
정책 변경의 어려움
한 번 정해진 정책(예: 미사용 설정해도 과금)을 바꾸는 것은 정말 어렵다. 초기 정책 설계가 얼마나 중요한지 뼈저리게 느꼈다.
다음 편: "데이터로 말하기: 영업팀과 협업하는 법"에서는 세일즈팀 시절부터 쌓아온 데이터 분석 경험과 PM으로서 영업팀과 어떻게 효과적으로 협업했는지 이야기해보겠습니다.