앱 MVP Android Activity Result API: 등록·실행·복원을 나누는 5가지 기준
Android 앱 MVP에서 카메라, 연락처 선택, 권한 요청, 다른 앱으로의 이동처럼 외부 화면을 열면 “돌아왔으니 처리 완료”라고 묶기 쉽습니다. 하지만 화면을 여는 시점, 시스템이 결과를 전달하는 시점, 앱이 다시 만들어지는 상황, 서버가 실제 업무를 끝낸 시점은 같은 사건이 아닙니다.
Android Developers는 기존 startActivityForResult()·onActivityResult()를 쓸 수는 있지만 AndroidX의 Activity Result API 사용을 강하게 권장합니다(C001). 이 API는 결과 callback 등록, 결과를 만드는 Activity 실행, 시스템이 전달한 결과 처리를 나눕니다(C002). 이 글은 특정 앱의 구현·보안·출시 결과를 보장하지 않습니다. 대신 외부 결과를 제품 상태로 바꾸기 전 무엇을 분리해 기록할지 정리합니다.
먼저 답: callback 수신은 사용자 업무 완료가 아닙니다
예를 들어 사진 선택 callback에서 URI를 받았더라도 업로드가 성공했다는 뜻은 아닙니다. 권한 요청 callback이 허용을 돌려줘도 해당 기능의 실제 동작·서버 저장·사용자 확인이 끝났다는 뜻은 아닙니다. 외부 Activity가 RESULT_OK를 돌려줘도 그 데이터가 현재 계정·현재 요청과 맞는지, 네트워크 작업이 성공했는지, 다음 화면으로 이동해도 되는지는 앱의 별도 업무 규칙입니다.
따라서 분석·QA·고객지원 기록에서는 적어도 ‘사용자 행동 시작’, ‘launcher 실행’, ‘외부 결과 수신’, ‘입력 검증’, ‘로컬 반영’, ‘서버 요청’, ‘서버 확정’, ‘사용자 완료 화면’을 한 이벤트로 합치지 않는 편이 안전합니다. 이 구분이 있어야 취소·재시도·화면 복원 때 어느 단계가 실패했는지 확인할 수 있습니다.
기준 1: 결과 callback은 조건부가 아니라 생성 시점에 등록합니다
외부 Activity를 쓰는 동안 메모리 부족 등으로 앱의 프로세스와 Activity가 파괴될 수 있습니다. 그래서 Android 문서는 결과 callback을 실행 코드와 분리하고, Activity가 생성될 때마다 등록해야 한다고 안내합니다(C002). 버튼을 눌렀을 때에만 등록하는 방식은 재생성 뒤 시스템 결과를 받을 callback이 없을 수 있다는 점을 검토해야 합니다.
제품 설계에서는 등록 자체를 ‘사용자가 요청을 시작했다’는 이벤트로 오해하지 마세요. 등록은 결과를 받을 통로를 준비하는 일이고, 실제 사용자 의도는 launch가 일어난 시점부터 별도 기록하는 편이 낫습니다. Compose와 View 기반 화면의 구현 방식이 달라도 이 경계는 유지합니다.
기준 2: 여러 launcher의 등록 순서와 업무 키를 함께 정합니다
사진 선택, 카메라 촬영, 권한 요청처럼 여러 launcher가 있으면 Android 문서는 매번 같은 순서로 registerForActivityResult()를 호출해야 inflight 결과가 올바른 callback에 전달된다고 설명합니다(C003). 이 규칙은 단순한 코드 정리 문제가 아니라, 화면 재생성 뒤 어떤 응답이 어떤 사용자 행동으로 돌아오는지를 지키는 조건입니다.
팀은 launcher 이름과 별도로 요청의 업무 키를 정하세요. 예컨대 “프로필 사진 변경”과 “문의 첨부”가 둘 다 파일 선택을 써도 결과를 어떤 계정·어느 화면·어느 임시 요청에 연결할지는 다를 수 있습니다. 업무 키는 제품이 정할 내용이므로 공식 문서에 없는 값을 임의로 신뢰하지 말고, 취소·계정 전환·중복 탭에서의 폐기 규칙까지 문서화하는 것이 좋습니다.
앱 MVP의 외부 연동 결과와 완료 기준을 함께 점검하기
기준 3: contract는 ‘무엇을 열지’와 ‘어떤 타입을 받을지’를 명시합니다
Activity Result API에서 contract는 결과를 만들기 위해 필요한 입력 타입과 결과 출력 타입을 정의합니다(C005). 기본 contract는 권한 요청, 사진 촬영, 콘텐츠 선택처럼 흔한 동작을 포함하며(C007), 특별한 입출력 규칙이 있을 때는 custom contract도 만들 수 있습니다(C005).
여기서 “generic contract가 더 유연하니 항상 낫다”거나 “custom contract가 더 안전하다”고 일반화할 수는 없습니다. 팀이 답해야 할 질문은 더 구체적입니다. 사용자가 시작하는 행동은 무엇인가, callback이 줄 수 있는 결과·취소·빈 값은 무엇인가, 결과를 어떤 도메인 모델로 검증할 것인가, 실패하면 다시 선택할지 다른 경로를 안내할지입니다. contract의 타입이 맞는다는 사실만으로 사용자 의도가 확인되거나 사업 데이터가 저장된 것은 아닙니다.
기준 4: launch와 callback 사이의 상태는 따로 저장·복원합니다
Android 문서는 launch()를 호출한 뒤 callback이 실행되기 전에도 앱이 파괴될 수 있으므로, 결과 처리에 필요한 추가 상태는 이 API와 별도로 저장·복원해야 한다고 설명합니다(C004). 즉 launcher가 살아난다고 해서 “어떤 사용자가 어떤 항목을 편집 중이었는지” 같은 제품 상태까지 자동으로 복원된다고 가정하면 안 됩니다.
출시 전에는 최소한 현재 계정 식별자, 편집 대상의 안정적인 ID, 요청 목적, 중복 실행 방지 키, 결과 수신 뒤 허용할 다음 상태를 분리해 보세요. 반대로 URI·토큰·민감한 입력처럼 보관 범위와 기간을 따로 검토해야 하는 값은 자동으로 복원 목록에 넣지 않는 편이 좋습니다. 실제 저장 위치·보존 기간·재인증 조건은 서비스의 보안과 개인정보 정책에 맞춰 결정해야 합니다.
기준 5: 결과 화면 테스트와 실제 업무 완료 테스트를 나눕니다
Android는 ActivityResultRegistry를 주입해 실제 외부 Activity를 열지 않고 결과 처리 경로를 테스트할 수 있는 방식을 설명합니다(C006). 이는 취소·성공·비정상 입력 같은 callback 분기를 빠르게 확인하는 데 유용합니다. 하지만 registry 테스트가 카메라 앱, 선택기, 권한 화면, 네트워크, 서버 검증까지 실제로 통과했다는 증거는 아닙니다.
그래서 QA는 두 층으로 나누는 편이 좋습니다. 첫째, contract와 callback이 기대한 도메인 상태로 바뀌는지 테스트합니다. 둘째, 실제 기기·외부 앱·권한 상태·계정 전환·네트워크 실패에서 사용자가 다시 시도하거나 취소할 수 있는지 검증합니다. 서버에 반영하는 흐름이라면 서버의 idempotency, 응답 검증, 완료 기록도 별도 테스트 대상입니다.
출시 전 확인표
구분 | 팀이 확인할 질문 | 완료로 보지 말아야 할 것 |
|---|---|---|
등록 | 재생성 때도 같은 callback과 순서로 등록되는가 | 버튼을 눌렀다는 사실 |
실행 | 어떤 사용자 행동·업무 키로 launch했는가 | 외부 화면이 열렸다는 사실 |
결과 | 계약의 출력·취소·빈 값을 검증하는가 | callback이 한 번 호출됐다는 사실 |
복원 | 추가 상태를 별도 저장·복원하는가 | launcher가 다시 만들어진 사실 |
완료 | 서버·로컬 반영과 사용자 완료 화면을 확인하는가 | 외부 Activity의 RESULT_OK |
관련 글: 앱 MVP 카메라 촬영은 촬영 요청과 파일 확인의 범위를 다룹니다. 이 글은 사진·권한·연락처 등 개별 입력 수단을 넘어서 외부 결과의 lifecycle과 업무 완료 경계를 다룹니다.
외부 화면 결과가 섞이지 않는 앱 MVP 흐름 설계 상담하기
자주 묻는 질문
Activity Result API callback이 오면 서버 처리도 끝난 건가요?
아닙니다. callback은 contract가 전달한 결과를 받는 지점입니다. 서버 요청·검증·저장·사용자 완료 화면은 서비스의 별도 처리와 확인이 필요합니다.
버튼을 누를 때만 registerForActivityResult()를 호출해도 되나요?
권장하지 않습니다. Android 문서는 앱이 재생성될 수 있으므로 callback을 Activity가 생성될 때마다 등록하라고 설명합니다. 실제 등록 위치는 화면 구조에 맞춰 검토하세요.
ActivityResultRegistry 테스트만 통과하면 외부 연동 QA도 끝난 건가요?
아닙니다. registry 주입은 callback 처리 로직 테스트에 도움을 주지만, 실제 기기·외부 앱·권한·네트워크와 서버 처리의 검증은 별도로 필요합니다.
여러 launcher는 하나로 합치는 편이 좋은가요?
항상 그렇지는 않습니다. Android 문서는 여러 launcher를 쓸 수 있다고 설명합니다. 사용자의 행동, 입출력 타입, 업무 키, 취소·재시도 정책을 기준으로 분리 여부를 정하세요.
공식 출처
Android Developers: Get a result from an activity (2026-09-21 확인)
Android Developers: ActivityResultContracts (2026-09-21 확인)
발행일: 2026-09-21 · 작성: 유인어스 정책자금·정부지원사업 인사이트