앱 개발 지원 기기와 OS 범위를 정하는 출시 전 체크리스트
“아이폰과 안드로이드 모두 지원한다고 하면, 오래된 휴대폰에서도 다 되는 건가요?”
“태블릿에서도 켜지기만 하면 되는지, 별도 화면까지 만들어야 하는지 모르겠어요.”
“개발사는 테스트를 마쳤다는데, 출시 후 고객 기기에서 문제가 생기면 어떻게 하죠?”
앱의 기기와 운영체제 지원 범위는 주요 고객이 핵심 기능을 끝까지 사용할 수 있고, 출시 전에 그 조건을 검증할 수 있는 범위로 정해야 합니다. 플랫폼 이름만 적지 말고 최소 OS, 화면 대응 수준, 테스트 대상과 미지원 안내까지 한 묶음으로 합의하세요.
저는 크로플에서 웹과 앱 수탁 개발, 프로젝트 관리를 맡고 있습니다. 개발자로 시작해 게임과 앱 개발을 거쳐 온 13년 이상의 경험에서 중요하게 보는 것은 ‘지원한다’는 표현을 실제 검수 가능한 조건으로 바꾸는 일입니다.
어떤 고객의 기기부터 지원해야 하나요?
전체 시장에서 많이 쓰는 기기보다, 첫 출시에서 놓치면 안 되는 고객의 사용 환경을 먼저 확인해야 합니다. 고객 정보가 부족하다면 지원 범위를 확정하기 전에 확인할 가정부터 적어두세요.
같은 예약 앱이라도 개인 고객이 자신의 휴대폰으로 예약하는 서비스와 매장 직원이 지급받은 태블릿으로 예약을 관리하는 서비스는 출발점이 다릅니다. 전자는 다양한 개인 기기를 고려해야 하고, 후자는 실제 지급 기종과 운영 환경이 중요한 기준이 됩니다.
처음 기획서를 검토할 때 저는 다음 질문부터 확인합니다.
- 첫 출시의 핵심 사용자는 누구이며 개인 기기와 업무용 기기 중 무엇을 쓰는가?
- 기존 서비스가 있다면 접속 기기와 OS를 확인할 자료가 있는가?
- 출시 대상 고객에게 직접 확인한 기종과 OS가 있는가?
- 지원에서 빠지면 서비스를 이용할 수 없는 고객군은 누구인가?
기획 협의에서 ‘태블릿도 지원’이라는 요청을 받았을 때, 실제 사용 장면을 물어보니 고객은 이동 중 조회보다 책상 위에서 여러 항목을 한꺼번에 확인하려고 했습니다. 저는 단순히 화면이 열리는 조건과 넓은 화면에 맞춰 업무를 처리하는 조건을 나눠 정리했습니다. 이후 논의도 기기 이름을 추가하는 데서 벗어나, 어떤 화면을 어디까지 구현할지로 구체화됐습니다.
이처럼 지원 기기는 기종 목록보다 사용 장면에서 먼저 좁히는 편이 좋습니다. 아직 고객 데이터가 없다면 ‘확인된 사실’과 ‘출시 전 확인할 가정’을 구분해 개발사에 전달하세요.
최소 OS와 스토어 제출 기준은 어떻게 다른가요?
최소 OS는 앱을 설치하고 실행할 수 있는 운영체제의 하한이며, 스토어 제출에 필요한 SDK나 타깃 API 조건과는 구분해야 합니다. 제출 기준을 맞췄다는 사실만으로 오래된 기기의 동작까지 보장되지는 않습니다.
Android의 minSdk와 targetSdk는 역할이 다르고, iOS의 최소 배포 버전과 앱 제출에 요구되는 빌드 SDK 조건도 별개입니다. 따라서 ‘최신 기준으로 개발합니다’라는 설명만으로는 실제 지원 범위를 알기 어렵습니다.
기획 단계에서는 특정 버전 숫자를 먼저 고정하기보다, 다음 순서로 개발사와 확인하는 편을 권합니다.
- 주요 고객의 OS 범위를 확인합니다.
- 로그인, 결제, 지도, 카메라처럼 핵심 기능에 쓰는 SDK와 라이브러리의 지원 조건을 확인합니다.
- 후보 최소 OS에서 핵심 기능을 구현하고 유지할 수 있는지 검토합니다.
- 출시 예정 시점의 스토어 제출 요건을 별도로 확인합니다.
구형 OS를 포함할지 판단할 때는 설치 가능 여부와 기능 제공 범위도 나눠야 합니다. 특정 기능을 제공할 수 없다면 대체 흐름으로 핵심 업무를 마칠 수 있는지, 아니면 해당 OS를 지원 대상에서 제외해야 하는지 결정해야 합니다.
기획서에는 ‘iOS와 Android 지원’ 대신 플랫폼별 최소 OS, 핵심 기능의 예외 조건, 버전 확정일을 적으세요. 숫자가 미정이어도 결정 담당자와 확인 시점은 정할 수 있습니다.
태블릿과 폴더블은 어디까지 대응해야 하나요?
태블릿과 폴더블은 설치 허용 여부와 화면 대응 수준을 따로 정해야 합니다. 넓어진 화면에서 어떤 작업을 할 수 있어야 하는지까지 적어야 개발 범위가 분명해집니다.
화면 대응은 기기 이름만으로 정의하기보다 사용 가능한 창 크기와 크기 변경 상황을 기준으로 검토해야 합니다. ‘태블릿 지원’ 한 줄로는 휴대폰 화면을 넓게 보여줄지, 목록과 상세를 나란히 배치할지 알 수 없습니다.
저는 구현 브리프에 무엇을 만들지뿐 아니라 무엇을 만들지 않을지도 적습니다. 화면 대응에서는 다음처럼 경계를 설명할 수 있습니다.
- 휴대폰 세로 화면에서 핵심 업무를 완료할 수 있게 합니다.
- 태블릿에서는 화면 잘림 없이 조회와 입력을 제공하되 별도 다중 열 화면은 만들지 않습니다.
- 폴더블의 접힘과 펼침, 창 크기 변경 중 입력 상태를 어디까지 유지할지 정합니다.
- 가로 화면을 지원하거나 제한할지는 플랫폼 제약과 사용 장면을 확인해 결정합니다.
이 항목들은 모든 앱에 그대로 적용하는 정답이 아닙니다. 영상 감상과 현장 점검, 문서 작성은 필요한 화면 조건이 다르므로 제품에 맞게 선택해야 합니다.
‘반응형으로 해주세요’ 대신 화면이 바뀌었을 때 유지해야 할 작업과 달라져도 되는 배치를 적어보세요. 개발사와 같은 화면을 떠올리는 데 도움이 됩니다.
지원 범위를 어떻게 테스트와 검수로 연결하나요?
지원 조건마다 확인할 기기 환경과 사용자 시나리오를 연결해야 합니다. 설치와 실행만 확인하지 말고, 고객이 핵심 작업을 완료하는 지점까지 검수 범위를 정하세요.
에뮬레이터와 시뮬레이터를 활용하더라도 카메라, 알림, 성능처럼 실제 하드웨어와 실행 환경의 영향을 받는 항목은 실기기 검증을 별도로 계획할 필요가 있습니다. 다만 모든 기종을 시험했다는 식의 약속보다, 어떤 위험을 어떤 환경에서 확인할지 명시하는 편이 현실적입니다.
예를 들어 사진 첨부가 핵심인 앱이라면 카메라 실행만으로 검수를 끝내기 어렵습니다. 권한 거절 후 재시도, 촬영 후 앱 복귀, 업로드 실패 시 재시도까지 하나의 작업 흐름으로 적을 수 있습니다. 이때 어느 기기와 OS에서 확인할지도 함께 기록합니다.
개발사에 견적을 요청하거나 착수를 준비할 때는 아래 항목을 한 문서로 모아보세요.
- 첫 출시의 핵심 사용자와 필수 사용 장면이 정해져 있다.
- 플랫폼별 최소 OS가 확정됐거나 확정 담당자와 날짜가 있다.
- 핵심 SDK의 지원 조건과 기능 예외를 확인한다.
- 휴대폰, 태블릿, 폴더블의 포함 여부와 화면 대응 수준을 적었다.
- 대표 테스트 환경의 선정 이유와 실기기 확보 담당자가 있다.
- 핵심 시나리오별 통과 조건과 테스트 결과 기록 방식이 있다.
- 미지원 환경을 어디에서 어떻게 안내할지 정했다.
- 출시 후 새 OS와 지원 범위 변경을 검토할 담당자가 있다.
특히 지원 대상 목록과 실제 시험한 환경 목록은 구분해서 관리하세요. 고객지원 담당자가 문제를 받았을 때 어떤 조건을 약속했고 어디까지 확인했는지 추적할 수 있어야 합니다.
결론
앱 지원 범위는 ‘어떤 기기에서도 된다’는 선언보다, 주요 고객의 작업을 어떤 환경에서 검증할지 정한 약속이어야 합니다.
고객의 사용 환경을 확인하고, 최소 OS와 제출 요건을 나누고, 화면 대응 수준을 정한 뒤 테스트 조건으로 연결하세요. 지원 대상, 제공할 기능, 검증 방법이 한 문서에서 이어지면 출시 범위를 판단하기 쉬워집니다.
크로플에서 수탁 개발을 진행할 때도 구현 브리프와 검수 조건을 연결하는 데 무게를 둡니다. 기획서에 ‘iOS와 Android 지원’만 적혀 있다면, 우선 그 문장을 실제 확인 가능한 조건으로 풀어보는 것이 다음 행동입니다.
자주 묻는 질문
아직 고객의 기기 데이터를 모으지 못했다면 어떻게 하나요?
가설에 근거한 임시 지원 범위와 검증 계획을 함께 정하세요. 예상 고객에게 기종과 OS를 확인하고, 출시 전까지 무엇을 추가로 확인할지 담당자와 기한을 남기면 됩니다. 근거가 부족한 상태를 확정된 수요처럼 취급하지 않는 것이 중요합니다.
크로스플랫폼으로 개발하면 지원 범위를 따로 정하지 않아도 되나요?
크로스플랫폼을 선택해도 지원 기기와 OS, 화면 및 검수 조건은 따로 정해야 합니다. 코드 공유 방식에 대한 결정이 고객에게 제공할 동작과 품질 조건을 대신하지는 않습니다.
출시 후 최소 OS를 올릴 때는 무엇부터 정해야 하나요?
기존 사용자의 이용 상태와 업데이트 전환 방식을 먼저 정하세요. 구버전 앱의 이용 가능 범위, 서버 호환성, 안내 시점, 문의 대응을 함께 검토하고 변경 내용을 기록하는 방식이 좋습니다.
제 도움이 필요하시다면
앱 외주 개발을 준비하면서 지원 범위가 모호하다면, 핵심 사용 장면을 구현 조건과 검수 항목으로 정리하는 일을 도와드릴 수 있습니다.
크로플은 웹과 앱 수탁 개발 및 프로젝트 관리를 수행합니다. 초기 기획에서는 주요 사용자와 필수 기능을 바탕으로 지원 범위를 정리하고, 구현 브리프에 포함할 화면 조건과 제외 범위를 구체화하며, 테스트 시나리오와 완료 조건을 연결하는 도움을 드릴 수 있습니다.
이미 받은 제안서에 ‘모바일 전체 지원’처럼 넓은 표현만 있거나 태블릿 대응 수준을 두고 해석이 갈린다면, 현재 기획서와 예상 사용 환경을 함께 놓고 검토할 시점입니다.
