하나의 앱에 담아야 할 것이 많았습니다
1minute은 HRV 측정과 심리검사, 결과 확인, 콘텐츠, AI 생활 가이드를 하나의 앱에서 연결하는 서비스입니다. 온보딩부터 측정·콘텐츠·AI·관리자 기능까지 작업 축이 나뉘어 있었고, 같은 요청도 앱 화면만 고치면 끝나는지 서버와 운영 정책까지 바뀌는지에 따라 일정이 달라졌습니다.
저는 고객 요구를 화면 흐름과 기능 명세로 옮기고, WBS에서 작업과 담당 범위를 확인하며 고객사·협업사·디자인·개발팀 사이의 진행 상황을 정리했습니다. 측정 근거나 상담 정책처럼 고객의 판단이 필요한 부분은 개발팀이 임의로 정하지 않도록 되돌려 물었습니다. 앱 구현은 각 개발 담당자가 맡았고, 저는 무엇을 이번 버전에 넣고 어떤 조건에서 검수할지를 맞추는 역할이었습니다.
스토어에 공개된 1minute 화면
MVP 개발과 내부 QA를 병행하면서 고객 테스트와 스토어 제출을 준비했습니다. 이 시점부터는 요청을 모두 같은 ‘수정사항’으로 볼 수 없었습니다. 심사·테스트를 막는 문제와 다음 버전의 편의 개선을 구분해야 제출 범위가 흔들리지 않았습니다.
요청 14개를 같은 우선순위로 놓지 않았습니다
3월 3일 고객과 합의한 내용을 심사 전 반영 14건과 후속 고도화 2건으로 나눠 공유했습니다. 14건에는 HRV 측정 화면의 안내·표현, Android 측정 중 화면이 꺼지는 문제, 콘텐츠 재생 영역, 2차 비밀번호 재인증 조건 등이 들어갔습니다. 예를 들어 재인증은 단순한 문구 변경이 아니라 앱이 백그라운드에서 돌아온 뒤 3분이 지났는지, 프로세스가 다시 시작됐는지에 따라 동작이 달라지는 작업이었습니다.
반면 PIN 입력 후 자동 이동과 닉네임 금칙어 차단은 필요성을 인정하되 심사 제출의 선행 조건에서는 분리했습니다. 회의 직후 고객과 개발팀에 같은 목록·일정·제외 항목을 보내, 나중에 ‘요청했으니 이번에 들어가는 것 아니었나’라는 기대 차이가 생기지 않도록 했습니다. 당시 공유한 개발 반영 완료일과 심사 제출일은 목표 일정이었고, 실제 승인까지의 일정과는 구분했습니다.
- 진단 화면과 안내 6건
- Android 안정화 2건
- 콘텐츠·화면 3건
- 보안·설정 3건
- 2차 비밀번호 입력 후 자동 이동
- 닉네임 금칙어 입력 차단
3월 3일 정리한 합의 항목을 범주별로 다시 묶었습니다. 개발·QA·심사 제출 일정은 목표일로 공유했습니다.
범위를 나누는 일은 우선순위표를 만드는 데서 끝나지 않았습니다. 고객 테스트에서 다시 나온 항목은 기존 합의사항인지 새로운 요청인지 확인하고, 구현 상태와 디자인·에셋 준비 여부를 함께 봤습니다. 같은 이름의 작업이라도 어느 화면과 플랫폼까지 적용할지 정해져야 개발 일정과 검수 기준을 설명할 수 있었습니다.
심사 의견을 ‘답변할 질문’과 ‘바꿔야 할 제품’으로 나눴습니다
첫 심사부터 개인정보 표시, 구독 정보, 건강 점수 산출 방식에 대한 보완 요청이 있었습니다. 이어 Apple은 PHQ-9 등 설문 결과가 표준 점수인지 별도 해석을 더한 것인지, 우울·불안 점수가 독자 알고리즘인지 물었습니다. 이 질문에는 화면 문구만 고쳐서는 답할 수 없었습니다. 고객과 협업사에 실제 산출 근거와 사용자에게 노출되는 해석 범위를 요청하고, 확인된 내용으로 심사 답변을 정리했습니다.
AI 기능은 더 까다로웠습니다. ‘AI counselor’가 상담·치료를 제공하는 것처럼 보일 수 있다는 지적과 함께, 자해나 급성 정신적 고통을 표현한 사용자에게 어떻게 반응하는지, 진단·치료 요청은 어떻게 제한하는지, 데이터를 어떻게 처리하는지까지 설명해야 했습니다. 저는 답변 가능한 안전장치와 아직 근거가 부족한 부분을 나눠 고객에게 공유했습니다. 자료를 보완해 재제출하되 같은 문제가 계속된다면 AI 기능 축소나 이번 버전에서의 제외까지 선택지로 올렸습니다.
이후에도 반려가 이어져 Apple App Review 담당자와 직접 확인했습니다. 그때 알게 된 핵심은 ‘웰니스 앱’이라는 설명이나 ‘AI 웰니스 가이드’라는 이름보다, 실제로 화면에 표시되는 심박수·HRV 수치와 AI의 응답이 중요하다는 점이었습니다. 심사 쟁점을 문구 수정만으로 좁히지 않고, 필요하면 수치 표현·기능 범위까지 다시 검토하도록 고객과 개발팀에 전달했습니다.
- 첫 제출 이후 개인정보·구독 정보와 건강 측정·점수 설명 보완 요청
- 설문 산식과 AI 기능의 목적·안전장치 질의에 자료를 모아 재제출
- 재반려 뒤 App Review 담당자에게 실제 판단 기준을 확인
- iOS 심사 승인 및 스토어 등록 상태 확인
- 01질문 해석설문·HRV 산식인지, AI 기능의 안전성인지 구분
- 02근거 확보고객·협업사 자료와 실제 화면·동작을 대조
- 03대응 선택설명 보완, 화면 수정, 기능 범위 재검토를 분리
여러 차례의 보완과 심사를 거쳐 iOS 앱 심사가 승인됐습니다. 현재 1minute은 App Store와 Google Play에서 확인할 수 있습니다.
‘이름만 바꾸는 일’도 적용 범위부터 확인했습니다
스토어 등록 뒤 고객은 MWS-S를 PWS로 바꾸고 HRV 측정 중 카메라 화면을 다시 보이게 해달라고 요청했습니다. 두 항목은 추가 고도화 목록에도 있었고 계약 전 선반영 여부를 협의해야 했습니다. 특히 명칭 변경은 앱 한 화면의 글자만 바꾸는지, 결과지·관리자·알림·API 식별자까지 바꾸는지에 따라 작업 범위가 크게 달라졌습니다. 저는 이 차이를 먼저 짚고 협업사와 대응 방향을 맞췄습니다.
이후 1.0.0 업데이트에서는 사용자에게 보이는 MWS/MWS-S 문구를 PWS로 바꾸고 HRV 카메라 프리뷰를 반영했습니다. 내부 API와 라우트 식별자는 호환성을 위해 유지했습니다. ‘명칭 변경 완료’라고만 쓰면 보이지 않는 곳까지 모두 교체한 것처럼 들리기에, 고객에게도 적용 범위를 나눠 공유했습니다.
추가 고도화에서 검사 결과를 더 자세히 보여달라는 요청에는 필요한 필드, 점수 산식, 계산 예시와 고위험 판단 기준을 확인 항목으로 돌렸습니다. 정책과 데이터가 정해지지 않은 상태에서 화면만 먼저 그려도 재작업이 생길 수 있기 때문입니다.
진행 상황을 공유할 때도 코드 반영, 통합 QA, 운영 배포를 같은 ‘완료’로 묶지 않았습니다. 고객이 지금 확인할 수 있는 상태와 다음 단계에 필요한 조건을 따로 적는 것이 PM으로서 제가 지키려 한 기준입니다.