모바일 앱·단말·백엔드·스토어 생태계

지하철에서 누른 예약 버튼은 좌석을 확보했을까

한빛도서관의 강좌에 자리가 하나 남아 있다. 이용자 두 명이 같은 안내를 본 뒤 통신이 끊긴 곳에서 예약 버튼을 누른다. 두 단말 모두 자신의 화면에서는 마지막 자리가 남아 있다고 기억한다. 화면을 즉시 ‘예약 완료’로 바꾸면 두 사람에게 같은 자리를 약속하게 된다.

모바일 서비스의 문제는 작은 화면에 웹사이트를 넣는 것으로 끝나지 않는다. 앱은 중단될 수 있고, 연결과 전원이 불안정하며, 사용자는 다른 단말에서도 같은 계정을 사용할 수 있다. 단말에 안전하게 남긴 요청, 서버가 받은 요청, 업무적으로 확정된 예약을 구별해야 한다.

이 절은 가상 도서관의 강좌 조회·관심 목록·예약 요청을 다룬다. 수치·사건·설계안은 자체 교육용이며 실제 앱 운영 결과가 아니다. 클라이언트·서버·API 계약의 입력·권한·상태효과·오류를 모바일의 중단과 동기화에 적용한다.

앞선 클라이언트·서버와 연결

클라이언트는 요청하고 서버는 공유 업무 상태를 판정·제공한다. 모바일에서는 단말의 로컬 저장·전송 상태와 서버의 업무 확정을 같은 성공으로 표시하지 않는다.

1. 모바일 생태계는 단말 밖의 책임도 포함한다

모바일 생태계는 단말 하드웨어·운영체제·앱·네트워크·백엔드·배포 채널과 정책이 함께 서비스의 기능·상태·권한·운영을 결정하는 환경이다. 앱 파일이 설치됐다는 사실은 이 전체 경로가 정상이라는 뜻이 아니다.

백엔드는 화면 뒤에서 계정·업무규칙·공유 데이터를 처리하는 서비스다. 앱은 이용자의 입력과 단말 기능을 다루지만 다른 이용자의 예약과 최종 정원을 혼자 판단할 수 없다. 단말이 주장한 계정·권한·예약 성공을 서버가 그대로 신뢰해서도 안 된다.

예를 들어 네트워크 연결 아이콘이 켜져 있어도 도서관 서버에 도달하지 못할 수 있다. 서버에 도달해도 인증이 만료됐거나 정원이 찼을 수 있다. ‘인터넷 있음’ 하나를 모든 기능의 성공 조건으로 쓰지 않는다.

2. 앱 구현 방식은 필요한 기능과 운영 부담으로 고른다

네이티브 앱은 운영체제의 앱 환경과 기능을 직접 활용하는 방식이다. 크로스플랫폼 앱은 여러 운영체제에서 코드나 화면 구현을 공유하는 접근이다. 공유하는 범위는 도구에 따라 다르며 기기 권한·백그라운드 동작까지 항상 같아지지는 않는다.

모바일 웹은 브라우저에서 사용한다. PWA는 웹 기술에 설치·캐시·일부 오프라인 같은 기능을 결합하는 접근이며 브라우저와 운영체제의 지원 조건을 확인해야 한다. 하이브리드 앱은 앱 안의 웹 화면과 네이티브 연결을 조합할 수 있다. 이 이름들은 품질 순위를 뜻하지 않는다.

한빛도서관이 강좌 조회와 예약만 제공한다면 접근 가능한 웹 서비스도 중요한 대안이다. 기기 기능·특정 오프라인 작업·배포 정책 때문에 앱이 필요한 경우에 그 이유를 추가한다. 앱 설치를 원치 않거나 지원 단말이 없는 이용자의 기본 업무 경로를 없애지 않는다.

선택표에는 장치 기능, 입력 방식, 읽기 접근성, 연결이 없는 때의 기능, 배포·지원 인력과 변경 빈도를 둔다. ‘코드 공유 90%’ 같은 개발 편의가 이용자 기능·권한·지원의 완성을 보장하지 않는다. 이 절은 특정 프레임워크나 시장점유율을 근거 없이 추천하지 않는다.

3. 앱의 실행과 사용자 업무의 수명은 다르다

운영체제는 메모리·전력·사용 상태에 따라 앱 실행을 제한하거나 종료할 수 있다. 화면 회전이나 화면 재생성, 사용자의 앱 전환도 일어난다. 따라서 예약 초안을 화면의 임시 변수에만 두면 앱이 다시 시작될 때 사라질 수 있다.

휘발성 상태는 실행 중 메모리에만 있는 상태이고, 영속 상태는 다시 실행해도 복원할 수 있도록 저장한 상태다. 입력 중인 화면 모양, 저장된 예약 초안, 서버의 확정 예약은 각각 다른 수명과 책임을 가진다. 모든 것을 같은 저장소에 넣는 대신 무엇을 복원해야 하는지부터 정한다.

OS의 백그라운드 작업 수단을 이용해 지속 작업을 예약할 수 있지만, 정해진 제약에서 수행되는 일과 정확한 시각의 무조건 실행은 다르다. Android의 WorkManager 설명은 영속 작업과 제약·재시도를, Apple의 공개 배경 실행 설명은 시스템이 주는 실행 시간과 만료 처리를 다룬다.¹ 예약 업무의 마감까지 서버 처리가 끝난다고 보장하려면 이와 별도의 업무 설계가 필요하다.

앱 종료 직전의 마지막 순간에 저장하기보다 사용자가 초안을 저장하는 의미 있는 경계에서 기록한다. 저장 실패는 사용자에게 알리고, 저장됐다는 문구는 실제 단말 보존 결과에 근거해야 한다. ‘단말 저장됨’이 ‘도서관에 접수됨’을 뜻하지 않도록 표시한다.

4. 오프라인 우선은 모든 쓰기를 단말에서 확정하는 것이 아니다

오프라인 우선은 네트워크가 없어도 핵심 기능의 일부를 수행하도록 자료·상태·복구를 설계하는 접근이다. Android의 공식 설명은 로컬·네트워크 자료원을 나누고, 읽기와 온라인 전용 쓰기·지연 쓰기의 요구가 다름을 구별한다.² 한빛도서관에서는 다음처럼 업무별 경계를 정한다.

화면이 읽는 일관된 자료원을 단말 저장소로 정할 수 있다. 그러나 그 저장소가 서버의 정원 배분 권한까지 소유하는 것은 아니다. 단말 자료에는 마지막 확정 상태와 아직 반영되지 않은 사용자의 의도를 따로 기록한다. 읽기 경로의 기준본과 공유 자원의 최종 판단 주체를 구별한다.

오래된 안내는 발행일·적용일·수신 시각이 다를 수 있다. 연결이 없어서 최신 정보를 확인하지 못했다면 그 사실을 표시한다. 마지막 자료의 접수기간이 지났거나 적용 여부가 불명확하면 예약 성공을 추정하지 않는다.

5. 재전송해도 같은 업무를 한 번만 반영하려면

한빛도서관의 자체 요청 MB-R1은 이용자·강좌·요청 식별자·내용을 연결한다. 앱은 요청을 단말의 보내기 대기 목록에 영속 저장한 뒤 전송한다. 서버는 인증과 입력·접수조건을 검토하고, 동일 요청의 재전송이면 이전 결과를 돌려주는 규칙을 둔다.

멱등성은 같은 요청을 반복했을 때 의도한 상태효과가 한 번 수행한 것과 같다는 성질이다. HTTP의 멱등 메서드와 자동 재시도 범위는 RFC9110이 구별한다.³ 예약 생성에 POST를 쓴다고 이 성질이 저절로 생기지는 않는다. 여기서는 업무 요청 ID와 저장 규칙으로 중복 효과를 제한하는 설계를 별도로 제시한다.

응답 미확인은 새 예약이 아니라 같은 요청의 확인으로 잇는다 · 상태 따라가기

계정·강좌·ID·내용을 묶어 단말에 저장한다. 모든 단계에서 단말·MB-R1·서버 원장의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

MB-R1은 계정·강좌·요청 ID·내용을 묶어 영속 보관한다. 서버는 권한·정원·마감을 판단하고 예약 및 요청 결과를 일관되게 기록한다. 결과가 도착하면 확정·거절을 표시하며, 응답 미확인은 실패로 확정하지 않는다. 같은 ID의 상태 조회와 필요 시 제한된 재시도·대사로 기존 의도를 이어 간다. 새 ID로 통신 재시도를 새 예약처럼 만들지 않는다.

이 예의 조건

• MB-R1은 계정·강좌·요청 ID·내용을 묶어 영속 보관한다. 서버는 권한·정원·마감을 판단하고 예약 및 요청 결과를 일관되게 기록한다. 결과가 도착하면 확정·거절을 표시하며, 응답 미확인은 실패로 확정하지 않는다. 같은 ID의 상태 조회와 필요 시 제한된 재시도·대사로 기존 의도를 이어 간다. 새 ID로 통신 재시도를 새 예약처럼 만들지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상예약 초안	원 설명사용자의 아직 미반영 의도 / 단말만으로 좌석 확정 금지
대상단말 저장·전송 대기	원 설명계정·강좌·요청 ID·내용 / 실제 보존 결과로 저장 표시
대상전송	원 설명연결 복구 뒤 요청 전달 / 발송은 업무 확정이 아님
대상서버의 일관된 처리	원 설명권한·정원·마감·동일 ID 확인 / 예약과 처리 결과 함께 기록
대상결과 확인?	원 설명응답 도착 여부
대상확정·거절 결과 반영	원 설명서버 실제 결과와 연결 / 단말 상태·다음 행동 표시
대상응답 미확인	원 설명성공·실패를 추정하지 않음 / 같은 의도와 ID 유지
대상동일 ID 상태 조회	원 설명필요 시 제한된 재시도·대사 / 새 예약 생성과 구별

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결예약 초안 → 단말 저장·전송 대기	원 라벨·방향영속 보존 / 정방향 / 실선
연결단말 저장·전송 대기 → 전송	원 라벨·방향대기 후 / 정방향 / 실선
연결전송 → 서버의 일관된 처리	원 라벨·방향요청 / 정방향 / 실선
연결서버의 일관된 처리 → 결과 확인?	원 라벨·방향처리 후 / 정방향 / 실선
연결결과 확인? → 확정·거절 결과 반영	원 라벨·방향확인 / 정방향 / 실선
연결결과 확인? → 응답 미확인	원 라벨·방향미확인 / 정방향 / 실선
연결응답 미확인 → 동일 ID 상태 조회	원 라벨·방향같은 ID / 정방향 / 실선
연결동일 ID 상태 조회 → 확정·거절 결과 반영	원 라벨·방향결과 확인 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
초안·영속 보관 계정·강좌·ID·내용을 묶어 단말에 저장한다.	값·보충 정보 단말·MB-R1: 초안→전송 대기 서버 원장: 아직 서버 확정 전	변화·이유 로컬 입력 저장이 전역 예약 완료는 아니다.
전송·서버 판정 연결 후 서버가 권한·정원·마감과 원자 기록을 처리한다.	값·보충 정보 단말·MB-R1: 같은 MB-R1 전송 서버 원장: 조건·예약·결과 기록	변화·이유 전송 성공을 실제 업무 확정과 구별한다.
응답 미확인 서버 결과를 못 받으면 단말은 미확인으로 관리한다.	값·보충 정보 단말·MB-R1: 결과 미확인 서버 원장: 이미 반영됐을 수 있음	변화·이유 새 ID로 통신 재시도를 새 예약처럼 만들지 않는다.
같은 ID 확인 같은 요청 상태를 조회하고 필요 시 제한 재시도·대사한다.	값·보충 정보 단말·MB-R1: 기존 의도 유지 서버 원장: 기존 결과 대조	변화·이유 확인한 확정·거절만 실제 결과로 반영한다.

응답 미확인은 새 예약이 아니라 같은 요청의 확인으로 잇는다 · 상태 따라가기

계정·강좌·ID·내용을 묶어 단말에 저장한다. 모든 단계에서 단말·MB-R1·서버 원장의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

MB-R1은 계정·강좌·요청 ID·내용을 묶어 영속 보관한다. 서버는 권한·정원·마감을 판단하고 예약 및 요청 결과를 일관되게 기록한다. 결과가 도착하면 확정·거절을 표시하며, 응답 미확인은 실패로 확정하지 않는다. 같은 ID의 상태 조회와 필요 시 제한된 재시도·대사로 기존 의도를 이어 간다. 새 ID로 통신 재시도를 새 예약처럼 만들지 않는다.

이 예의 조건

• MB-R1은 계정·강좌·요청 ID·내용을 묶어 영속 보관한다. 서버는 권한·정원·마감을 판단하고 예약 및 요청 결과를 일관되게 기록한다. 결과가 도착하면 확정·거절을 표시하며, 응답 미확인은 실패로 확정하지 않는다. 같은 ID의 상태 조회와 필요 시 제한된 재시도·대사로 기존 의도를 이어 간다. 새 ID로 통신 재시도를 새 예약처럼 만들지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상예약 초안	원 설명사용자의 아직 미반영 의도 / 단말만으로 좌석 확정 금지
대상단말 저장·전송 대기	원 설명계정·강좌·요청 ID·내용 / 실제 보존 결과로 저장 표시
대상전송	원 설명연결 복구 뒤 요청 전달 / 발송은 업무 확정이 아님
대상서버의 일관된 처리	원 설명권한·정원·마감·동일 ID 확인 / 예약과 처리 결과 함께 기록
대상결과 확인?	원 설명응답 도착 여부
대상확정·거절 결과 반영	원 설명서버 실제 결과와 연결 / 단말 상태·다음 행동 표시
대상응답 미확인	원 설명성공·실패를 추정하지 않음 / 같은 의도와 ID 유지
대상동일 ID 상태 조회	원 설명필요 시 제한된 재시도·대사 / 새 예약 생성과 구별

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결예약 초안 → 단말 저장·전송 대기	원 라벨·방향영속 보존 / 정방향 / 실선
연결단말 저장·전송 대기 → 전송	원 라벨·방향대기 후 / 정방향 / 실선
연결전송 → 서버의 일관된 처리	원 라벨·방향요청 / 정방향 / 실선
연결서버의 일관된 처리 → 결과 확인?	원 라벨·방향처리 후 / 정방향 / 실선
연결결과 확인? → 확정·거절 결과 반영	원 라벨·방향확인 / 정방향 / 실선
연결결과 확인? → 응답 미확인	원 라벨·방향미확인 / 정방향 / 실선
연결응답 미확인 → 동일 ID 상태 조회	원 라벨·방향같은 ID / 정방향 / 실선
연결동일 ID 상태 조회 → 확정·거절 결과 반영	원 라벨·방향결과 확인 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
초안·영속 보관 계정·강좌·ID·내용을 묶어 단말에 저장한다.	값·보충 정보 단말·MB-R1: 초안→전송 대기 서버 원장: 아직 서버 확정 전	변화·이유 로컬 입력 저장이 전역 예약 완료는 아니다.
전송·서버 판정 연결 후 서버가 권한·정원·마감과 원자 기록을 처리한다.	값·보충 정보 단말·MB-R1: 같은 MB-R1 전송 서버 원장: 조건·예약·결과 기록	변화·이유 전송 성공을 실제 업무 확정과 구별한다.
응답 미확인 서버 결과를 못 받으면 단말은 미확인으로 관리한다.	값·보충 정보 단말·MB-R1: 결과 미확인 서버 원장: 이미 반영됐을 수 있음	변화·이유 새 ID로 통신 재시도를 새 예약처럼 만들지 않는다.
같은 ID 확인 같은 요청 상태를 조회하고 필요 시 제한 재시도·대사한다.	값·보충 정보 단말·MB-R1: 기존 의도 유지 서버 원장: 기존 결과 대조	변화·이유 확인한 확정·거절만 실제 결과로 반영한다.

서버는 요청 ID만 보고 다른 계정의 결과를 반환하지 않도록 계정과 요청 범위를 묶는다. 같은 ID에 다른 내용이 오면 조용히 새 요청으로 실행하지 않고 충돌을 알린다. 요청 결과 기록과 실제 예약 저장은 하나의 일관된 처리 경계에 묶어야 한다. 기록만 남고 예약은 없거나, 예약은 생겼는데 기록이 없어 재실행되는 틈을 피한다.

응답이 끊겼다고 예약 실패가 확정되는 것은 아니다. 서버가 저장한 직후 응답만 잃을 수 있다. 같은 본문으로 새 ID를 만들어 반복하면 다른 요청으로 처리될 수 있으므로 결과를 조회하고 기존 의도를 이어 간다. 사용자가 정말 새 예약을 원한 경우와 통신 재시도를 구별한다.

네트워크 일시 오류는 제한된 횟수·대기 간격으로 재시도할 수 있지만 잘못된 입력·권한 거절·마감된 강좌는 그대로 반복하지 않는다. 지수적으로 간격을 늘리면 동시 재시도의 부담을 줄일 수 있으나 최대 대기와 사용자에게 보여 줄 상태가 필요하다. 영원히 돌아가는 큐를 복구 설계라고 부르지 않는다.

6. 두 단말의 충돌은 어떤 업무인가에 따라 다르게 해결한다

MB-C1에서 두 단말은 ‘잔여 1’인 상태의 판본 7을 보았다. 두 이용자가 연결이 없는 동안 요청 A·B를 저장한다. 서버는 A를 처리할 때 정원을 확인하고 예약과 잔여 0·판본 8을 함께 반영했다고 가정한다. 이후 B는 정원 부족 결과를 받는다. 어느 요청이 먼저 처리되는지는 사전에 정한 서비스의 접수·배분 규칙에 따르며, 이 예가 법정 선착순 기준을 만든 것은 아니다.

단말 시계가 더 늦다는 이유로 B를 채택해 A를 덮어쓰면 이미 확정한 권리와 공지 결과를 깨뜨린다. ‘마지막 쓰기 승리’는 일부 개인 설정에 쓸 수 있지만 정원·재고·금액 등 보존해야 할 업무조건의 일반 해법이 아니다. 기기 시계 오차와 사용자의 재수정도 고려해야 한다.

낙관적 동시성 제어는 읽은 판본과 갱신 시점의 판본을 비교해 사이에 변경이 있으면 재검토하게 하는 방식이다. 실제 좌석 배분에는 판본 비교만이 아니라 정원·중복 예약을 지키는 서버의 일관된 저장이 필요하다. 화면이 판본 7을 보았다는 사실이 그 판본의 잔여 자리를 계속 보장하지는 않는다.

관심 메모와 공유 좌석에는 다른 전략을 둔다. 메모를 양쪽에서 바꿨다면 두 버전을 보존하고 사용자가 선택·병합하게 할 수 있다. 삭제한 관심 목록이 늦게 온 옛 자료로 되살아나지 않게 삭제 사실도 동기화한다. 모든 충돌을 사용자에게 넘기지도, 모든 값을 시간순으로 덮지도 않는다.

7. 기기 권한·계정 권한·배포 서명을 나눈다

카메라 접근 허용은 단말의 특정 기능 사용 권한이다. 이것으로 다른 이용자의 예약을 읽을 권한을 얻는 것은 아니다. 계정의 서비스 권한은 서버가 대상과 동작마다 확인한다. 앱에 숨겨 넣은 공통 비밀값이나 버튼 비활성화만으로 권한을 강제하지 않는다.

인증 토큰은 해당 플랫폼의 보호 저장 기능과 수명·철회 정책을 고려해 관리한다. 로그·오류 보고에 토큰과 원문 개인정보를 그대로 남기지 않는다. 로그아웃 때 단말 캐시·전송 대기·푸시 연결이 다음 계정으로 넘어가는지도 확인한다. 민감한 처리는 갱신된 권한을 확인한 뒤 수행한다.

푸시 알림은 상태가 바뀌었음을 알리는 경로로 쓸 수 있다. 알림이 누락되거나 늦게 오거나 여러 번 올 수 있으므로 예약 원장은 알림 메시지가 아니라 서버의 실제 상태로 조회한다. 잠금 화면에 불필요한 개인정보를 표시하지 않는다. 알림 수신을 사용자가 내용을 읽거나 예약이 유효함을 인정한 증거로 바꾸지 않는다.

앱 서명은 배포물의 출처·변경 검증에 쓰는 근거이지 업무규칙·서버 권한의 무결점 인증이 아니다. 스토어 심사도 특정 배포의 플랫폼 정책 확인이며 전체 법적 적합성과 운영 보안을 대신하지 않는다. Apple 지침은 데이터 수집·이용 공개와 개인정보 보호의 요구를 별도로 둔다.⁴ 구체 정책은 배포 지역·채널·시점별로 다시 확인한다.

8. 앱과 서버는 같은 순간에 갱신되지 않는다

서버를 갱신해도 모든 단말의 앱이 즉시 새로 설치되지는 않는다. 어떤 이용자는 오래 접속하지 않았거나 업데이트가 실패했을 수 있다. 따라서 배포물의 서명·버전, 서버가 허용하는 기능·계약, 실제 사용하는 단말의 지원 상태를 운영 정보로 연결한다.

한빛도서관은 지원 범위를 명시하고 안전하게 해석할 수 없는 구판의 예약 쓰기를 차단한다. 이유와 업데이트 경로를 알리고 이미 작성한 초안의 보존·정리 방법을 제공한다. 필드 이름을 그대로 두고 ‘예약 완료’의 의미를 ‘단말 저장’으로 바꾸는 식의 조용한 계약 변경은 하지 않는다. 이 사례는 구형 경로를 무기한 유지하는 호환층 설계가 아니다.

변경은 작은 대상군에서 크래시·권한·저장·동기화·업무 결과를 확인한 뒤 확대한다. 다운로드율과 실제 실행 판본, 업무 성공률을 분리한다. 새 배포를 중단해도 이미 설치된 앱이나 잘못 확정된 예약이 사라지는 것은 아니므로 원장 대사·안내·정정이 필요하다.

9. 따라 계산 MB-S1: 100개 요청의 상태를 대사한다

다음은 서로 다른 요청 100개의 한 시점 상태다. 각 요청은 하나의 행에만 들어간다. 수치는 도서관의 실제 기록이 아니다.

전송한 것은 80개이므로 전송률 80%다. 서버의 최종 결과를 확인한 것은 70개로 전체 70%, 전송 집단에서는 70/80=87.5%다. 확정 예약 60개를 전체 성공으로 따로 센다. 응답 미확인 10개를 실패나 성공에 임의로 넣지 않는다.

같은 요청 ID로 대조한 결과 미확인 10개 중 6개 확정·4개 거절을 확인했다고 하자. 최종 결과 확인은 80개, 확정 66개·거절 14개·미전송 20개가 된다. 상태를 알아낸 것이지 이 대조로 새 예약 6개를 만든 것은 아니다. 전송 대기 20개는 여전히 남는다.

별도 예에서 고유 요청 50개에 대한 실제 전송 시도가 65번이고 재전송 15번이 모두 동일 요청 ID였다고 하자. 중복효과 방지 규칙이 정상 작동했다면 업무 요청은 50개다. 65개의 예약으로 세지 않으며, 전송 65번의 자원 부담과 고유 50개 업무 결과를 별도로 보고한다.

10. 완성 설계안 MB-G1

MB-G1은 공개 안내 읽기·관심 목록·예약 요청을 제공한다. 마지막 안내와 갱신시각은 단말에 보관하되 정원 확정은 서버가 맡는다. 단말 저장·전송 대기·서버 처리 중·확정·거절·미확인을 구분하고 각각 이용자가 할 수 있는 다음 행동을 표시한다.

화면은 단말의 일관된 상태를 읽고, 동기화 담당은 영속 대기 목록과 서버 결과를 조정한다. 서버는 계정·강좌·요청 ID·내용을 묶어 검증하고 예약·중복방지 결과·정원 갱신을 일관되게 반영한다. 응답 미확인은 조회·제한 재시도로 해결하며 마감·권한 오류는 사용자 확인으로 돌린다.

앱 담당은 저장·복원·망 전환·알림을, 서버 담당은 정원·권한·중복·상태조회를, 운영 담당은 미처리·지원 판본·고객 안내를 맡는다. 로그인 변경·프로세스 종료·저장공간 부족·응답 소실·동일 좌석 동시 요청을 시험하도록 계획한다. 산출물은 상태표·API 계약·자료 보존/삭제표·지원 판본표·미처리 대사표다.

로컬 성공 화면을 최종 예약으로 쓰는 안과, 모든 오류를 새 ID로 재전송하는 안은 기각한다. 지원되지 않는 앱의 위험한 쓰기, 계정 간 캐시 혼합, 중복 예약이 확인되면 해당 기능을 중단하고 서버의 실제 예약을 기준으로 정정한다. 자동화의 완료를 앱 설치나 요청 발송으로 판정하지 않는다.

11. 자체 10점 문제와 완성 답안

오프라인 우선 모바일에서 단말 상태와 업무 확정을 구별하고 MB-S1의 동기화 결과를 해석하시오.

MB-S1의 네 배타적 집단을 합산한 뒤 전송 80·결과 확인 70·확정 60을 서로 다른 지표로 쓴다. 미확인 10의 대사는 신규 예약 생성과 구별한다.

10점 자체 연습의 구성과 완성 답안

구성: 정의와 책임 → 네 상태 → 분모 → 응답 소실의 처리 순서로 답한다. 다음은 자체 교육용 답안이며 공식 기출·채점표가 아니다.

MB-S1에서 구별하는 경계	최초 요청 수	업무 의미
단말 저장·미전송	20	접수되지 않은 의도
전송 후 응답 미확인	10	서버 결과를 아직 모름
서버 거절 결과 확인	10	이유와 다음 행동 표시
서버 확정 결과 확인	60	실제 예약 결과와 연결

전송·서버 판정·결과 확인과 동일 ID 복구를 따라 읽는다. 로컬 상태·네트워크 전달·업무 원장·앱의 결과 확인은 같은 완료가 아니다.

완성 답안

모바일 생태계는 단말·운영체제·앱·네트워크·백엔드·배포 정책이 함께 기능과 운영을 결정하는 환경이다. 오프라인 우선은 일부 핵심 기능을 단말에서 유지하는 접근이며 공유 좌석을 단말이 확정하는 방식은 아니다. 공개 안내·초안을 보존하고 예약은 서버의 정원·권한·접수조건으로 판단한다.

MB-S1은 100개 중 전송 80개, 최종 결과 확인 70개, 예약 확정 60개다. 결과 확인은 전체 70%·전송 집단 87.5%이며 응답 미확인 10개와 미전송 20개를 구별한다. 재조회에서 6개 확정·4개 거절을 확인한 뒤에는 확정 66·거절 14·미전송 20이다.

응답 소실이 업무 실패를 뜻하지 않으므로 같은 요청 ID와 내용으로 상태를 대사한다. 서버는 요청 결과와 실제 정원 변경을 일관되게 기록하고 재전송의 중복효과를 제한한다. 앱 종료·권한 만료·지원 판본·푸시 누락도 다루며 단말 저장·전송·업무 완료를 같은 성공으로 표시하지 않는다.

12. 자체 25점 문제와 완성 설계 답안

연결이 불안정한 도서관 모바일 예약 서비스 MB-G1을 설계하시오. 상태·동기화·충돌·보안·배포와 운영을 포함하시오.

단말 종료와 응답 소실 뒤에도 같은 사용자 의도·계정·강좌·요청 ID·내용이 이어지는 경계를 설계한다. 공유 좌석의 최종 판단을 단말 시계로 옮기지 않는다.

25점 자체 연습의 설계 과정과 완성 답안

목차: 업무 경계 → 자료·요청 흐름 → 실패·권한 → 변경·완료 근거.

MB-G1의 구성	연결할 책임·조건
앱 로컬 상태	계정 귀속·기기 권한·영속 초안·실제 결과 표시
동기화 큐	동일 ID·동일 내용·중복 제한·제한 재시도·결과 대사
서버 API·원장	서비스 권한·정원·마감·일관된 예약과 요청 결과

요청은 큐에서 서버로, 실제 결과는 앱 상태로 돌아온다. 미확인 분기와 같은 ID 조회를 재사용하며 두 방향을 무조건 같은 성공으로 합치지 않는다.

완성 설계 답안

MB-G1은 공개 강좌 읽기와 관심 목록, 예약 요청을 제공한다. 단말은 안내와 갱신시각·초안·미반영 의도를 영속 보관하고 화면에 저장·대기·확정·거절·미확인을 구별한다. 예약 확정과 정원 원장은 서버가 소유하며 연결이 없을 때 잔여 좌석을 보장하지 않는다. 별도 웹 접근 경로도 검토해 앱 설치가 기본 이용의 불필요한 장벽이 되지 않게 한다.

단말은 계정·강좌·요청 ID·내용을 보내기 목록에 저장한다. 서버는 권한·정원·마감과 동일 ID의 내용 일치를 확인하고 실제 예약과 처리 결과를 하나의 일관된 경계로 남긴다. 응답이 끊기면 새 요청으로 만들지 않고 동일 ID로 결과를 조회한다. 일시 오류만 제한적으로 재시도하고 입력·권한·마감 오류는 재확인 대상으로 표시한다.

마지막 좌석에 대한 두 요청은 서버의 배분 규칙과 일관된 정원 갱신으로 처리한다. 개인 설정에 가능한 시간순 병합을 정원 배분에 그대로 적용하지 않는다. 단말 시계나 오래된 판본을 최종 권한으로 쓰지 않으며, 관심 목록의 삭제와 계정 전환 시 남는 사본도 동기화한다.

기기 권한과 서비스 계정 권한을 분리한다. 토큰·캐시·대기 목록·로그를 보호하고 푸시는 상태 재조회의 신호로 사용한다. 앱 서명·스토어 심사는 서버 권한이나 개인정보 준수를 대신하지 않는다. 지원 판본을 명시하고 해석할 수 없는 구판의 위험한 쓰기는 업데이트 안내와 함께 중단한다. 미저장 의도를 조용히 폐기하거나 의미가 다른 완료값을 반환하지 않는다.

앱·서버·운영 담당자는 프로세스 종료·저장실패·망 전환·동시예약·응답 소실·권한 만료·알림 누락을 대조한다. MB-S1처럼 고유 요청별 최종 결과와 미전송·미확인을 합쳐 전체를 맞춘다. 크래시 없는 실행, 전송률, 예약 확정률을 별도로 관찰하고 중복·계정 혼합이 있으면 기능을 중단해 원장과 이용자 안내를 정정한다.

13. 자기교정

조건 변경과 해설

미확인 10개가 모두 거절로 확인되면? 확정 60·거절 20·미전송 20이다. 결과 확인율은 80%이지만 확정률 60%는 그대로다. 재조회 자체가 예약을 증가시키지 않는다.

같은 요청 ID로 다른 강좌를 보내면? 서버는 기존 결과를 무조건 돌려주거나 두 번째 강좌를 예약하지 않는다. 계정·내용의 불일치를 알리고 실제로 새로운 사용자 의도인지 확인해 별도 요청으로 처리한다.

로그아웃 중 미전송 요청이 남아 있으면? 다른 계정으로 자동 전송하지 않는다. 원 계정의 초안과 상태를 보호하고 취소·보존·재인증 규칙에 따라 처리한다. 단말에 남아 있다는 사실을 권한 지속으로 해석하지 않는다.

독립 확인: 요청 확인율은 늘었는데 좌석은 늘지 않았다

MB-S1의 최초 100개 요청에서 미확인 10개를 동일 ID로 조회하여 3개 확정·7개 거절을 확인했다. 이어 미전송 20개 중 5개를 전송하고 2개 확정·3개 거절을 확인했다. 그 밖에는 변동이 없다. 전송률·최종 결과 확인율·예약 확정률과 배타적 상태 수를 계산한다. 앱이 응답을 못 받은 기존 요청에 새 ID를 부여하면 왜 이 대사를 깨뜨릴 수 있는가?

변경 조건의 완전한 풀이와 오답 교정

첫 대사 뒤 확정 63·거절 17·미전송 20이다. 미전송 중 5개의 결과를 반영하면 확정 65·거절 20·미전송 15·미확인 0으로 합계 100이다. 전송은 85/100=85%, 결과 확인도 85%, 예약 확정은 65%다. 확정 65/전송 85≈76.47%는 전송 집단의 조건부 확정 비율이다. 첫 조회에서 늘어난 확정 3개는 이미 있던 결과를 알아낸 것이며 조회가 좌석을 새로 배정한 것은 아니다. 기존 요청에 새 ID를 쓰면 서버가 새로운 의도로 구별하여 중복효과가 생길 수 있고, 고유 요청 100과 전송 시도 횟수도 섞인다. 같은 ID·내용·계정 범위로 확인하고 원장·결과 기록의 일관된 경계를 지킨다.

답안을 닫고 메모 병합과 마지막 좌석 배분의 다른 규칙, 로그아웃 뒤 큐의 계정 귀속, 푸시 수신과 현재 예약 원장의 관계를 말한다.

2026-10-05 Android 오프라인 우선 공식 문서와 RFC9110 §9.2.2를 직접 대조했다. 읽는 기준본과 최종 업무권한을 구별하며, 예약 POST의 중복효과 방지는 본문의 별도 설계 조건이다.

근거와 적용 범위

모든 도서관 상황·정수·도식·문제·답안은 자체 교육용이다. 실제 앱 구현·출시·계정 처리·독립 검토를 수행하지 않았다.

회독의 핵심

단말은 중단되고 연결은 끊길 수 있다. 저장된 의도와 확정된 업무를 나누고, 재전송·충돌·권한·지원 판본·사용자 안내를 실제 상태로 연결한다. 모바일 품질은 화면이 뜨는 순간뿐 아니라 실패 뒤에도 사용자가 자신의 업무를 이해하고 이어갈 수 있는지에 있다.

추가 상태 연습: 같은 의도를 시간순서와 분모로 추적한다

아래 세 문제는 기존 MB-R1·MB-S1과 구별하는 자체 조건이다. 실제 단말·OS·HTTP 클라이언트·예약 서버를 실행한 기록이 아니다. 원장 확인과 화면의 확인 상태를 구분한 뒤, 주어진 사건만 반영한다.

문제 1 — 재전송 간격을 늘리면 마감도 함께 늘어날까

같은 계정·강좌·내용·요청 ID R1의 중복효과 방지 계약이 별도로 확인됐다고 가정한다. 첫 전송은 t=0초이며 결과 조회는 계속 미확인이다. 응용이 정한 다음 전송 전 대기는 차례로 2·4·8초이고, 전송·조회 소요는 0으로 근사한다. 새 전송은 t≤10초에만 허용하고 그 뒤에도 결과 조회는 허용한다. 권한 거절·내용 오류·단말 중단은 없다. 전송 시각, 허용된 시도 횟수와 고유 업무 요청 수를 구하라. 마감 뒤 응답이 없다는 이유로 화면을 거절 또는 확정으로 바꿀 수 있는가?

간격의 누적과 업무 결과를 분리하는 풀이

누적 전송 시각은 0, 2, 6, 14초다. t≤10 조건에서는 0·2·6의 세 시도만 허용되며 14초 전송은 하지 않는다. 새 사용자 의도가 없고 같은 R1을 유지했으므로 고유 업무 요청은 하나다. 세 번 전송했다는 사실은 세 예약이나 한 확정의 증거가 아니다. 이 시간표는 응용의 가정이며 OS가 백그라운드에서 정확한 시각을 보장한다는 설명도 아니다.

마감은 이미 처리됐을 수 있는 R1의 실제 결과를 지우지 않는다. ‘미확인·결과 확인 필요’를 유지하고 계약이 허용한 같은 ID 조회로 확인한다. 새 ID를 만들거나 전송 종료를 예약 실패로 표시하지 않는다. RFC의 메서드 이름만으로 임의의 POST 반복을 허용하지 않으며, 이 문제는 명시한 업무 중복 제한·마감·조회 계약에서만 시간표를 계산한다.³

문제 2 — 취소 알림 뒤에 늦은 확정 알림이 오면

같은 계정의 예약 R9에 대해 판본 8의 ‘취소됨’ 알림 뒤에 판본 6의 ‘확정됨’ 알림이 도착했다. 두 알림은 상태 변경을 알려 주는 신호이며 업무 원장이 아니다. 별도 인증된 상태 조회에서 현재 서버 판본 8·취소됨을 확인했고 그 뒤 다른 변경은 없다. 나중에 도착한 알림이 최신 상태라는 규칙을 적용할 수 있는가? 화면의 최종 상태와 다음 중복 알림의 처리 원칙을 적어라.

수신 순서와 원장의 판본을 구별하는 풀이

수신이 늦은 판본 6이 더 최신인 것은 아니다. 현재 상태 조회의 판본 8·취소됨을 반영하고, 판본 6 알림으로 확정 상태를 되살리지 않는다. 대상 계정·예약 ID와 현재 판본을 함께 연결하며 ‘알림 두 번’이나 ‘확정이라는 글자’는 현재 예약 유효성의 증거로 쓰지 않는다.

후속 중복·오래된 알림은 필요하면 같은 대상의 조회를 깨우는 신호로 다룬다. 다른 계정의 캐시에 섞거나 낮은 판본으로 확정 결과를 덮지 않는다. 판본만 높다고 임의 알림 본문을 신뢰하는 설계도 답이 아니다. 여기서는 인증된 현재 상태 조회가 이미 확인됐다는 조건이 핵심이다. 실제 푸시 전달·권한·취소 API의 실행 검증과는 별개다.

문제 3 — 일부만 대사됐으면 미확인을 어디에 남길까

MB-S1의 최초 100개 고유 요청을 사용한다. 기존 미확인 10개 중 8개의 결과를 조회하여 5개 확정·3개 거절을 확인했고 2개는 여전히 미확인이다. 기존 미전송 20개 중 12개를 전송하여 7개 확정·3개 거절을 확인했으며 2개는 미확인이다. 다른 요청·취소·내용 변경·새 ID·중복효과는 없다. 네 배타적 상태와 전송률·결과 확인율·확정률을 구하라. 전송 집단의 확인율과, 그 집단에서 확정 수가 될 수 있는 범위도 구분하라.

미확인 집단을 없애지 않고 전체를 맞추는 풀이

확정은 60+5+7=72, 거절은 10+3+3=16, 미확인은 2+2=4, 미전송은 20−12=8이다. 합계 100이며 전송은 92개, 결과 확인은 88개다. 전체 기준 전송률 92%·결과 확인율 88%·확정률 72%이고, 전송 집단의 확인율은 88/92≈95.65%다. 95.65%를 전체 예약 성공률로 바꾸지 않는다.

현재 자료에서 전송 92개 중 확정 수의 가능한 범위는 72~76개다. 미확인 4개가 전부 거절이거나 미확정이면 72, 전부 확정이면 76이며 실제 위치는 추가 확인 전에는 모른다. 미전송 8개를 이 범위에 더하거나 미확인 4개를 실패로 강제 분류하지 않는다. 같은 ID 조회는 이미 있던 결과를 알아내는 일이며, 미전송 12개를 실제 보내는 일과 상태 효과가 다르다.

Footnotes

1. Android Developers, Task scheduling / WorkManager, https://developer.android.com/develop/background-work/background-tasks/persistent ; Apple, Advances in App Background Execution, WWDC2019 session707의 작업 만료·사용자 알림 설명, https://developer.apple.com/videos/play/wwdc2019/707/ . 과거 발표는 실행 수명 구별에만 사용하며 현재 OS의 정확한 시간 한도·모든 API 지원을 확정하지 않는다. ↩

2. Android Developers, Build an offline-first app, 읽기·로컬/네트워크 자료원·쓰기 전략·충돌 처리의 명시 범위. https://developer.android.com/topic/architecture/data-layer/offline-first . 2026-09-20 확인. 본문의 좌석 배분·상태표·요청 ID 설계는 별도 자체 사례이며 원문 코드·그림을 복제하지 않았다. ↩

3. IETF, RFC9110 HTTP Semantics (2022), §9.2.2의 멱등성과 재시도. https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2 . 예약의 저장 경계·업무 ID는 이 사례의 추가 설계이지 POST 자체에 규격이 보장하는 성질이 아니다. ↩ ↩²

4. Apple, App Review Guidelines, §5.1.1 Data Collection and Storage. https://developer.apple.com/app-store/review/guidelines/ . 2026-09-20 확인한 개인정보 공개·보호 범위만 사용한다. 모든 지역의 결제·배포 정책이나 법률 적용을 전수 감수한 것은 아니다. ↩