개발 기술 · 더 알아보기 · 직접 체험형

앱 알림을 누르면 해당 주문 화면은 어떻게 열릴까요?

알림에 연결된 주문 번호를 서버가 확인하고, 로그인과 열람 권한을 통과한 현재 주문을 앱에 보여주는 과정을 살펴봅니다.

알림과 주문 연결로그인·열람 권한복귀·현재 내용 조회
회원 A가 알림을 누르면 서버에서 로그인과 주문 열람 권한을 확인한 뒤 같은 주문 O-204의 현재 상세를 보여주는 과정.

작동으로 살펴보는 개발 과정

알림을 누른 뒤 같은 주문이 열리는지 확인하세요

준비된 알림을 눌러보세요. 서버의 확인과 같은 앱의 주문 상세를 나란히 볼 수 있습니다.

알림 선택 → 로그인·권한 확인 → 현재 주문 조회

시연만 크게 보기 ↗

앱과 서버를 연결하는 구현 과정

알림 선택 뒤에서 이어지는 앱과 서버

알림을 눌렀을 때 정확한 주문이 열리려면, 알림과 주문을 연결한 뒤 서버에서 현재 회원의 열람 권한과 주문 내용을 다시 확인해야 합니다. 알림에 쓰인 ‘배송 중’이라는 문장을 상세 화면에 복사하는 것만으로는 현재 주문 상태를 보여줄 수 없습니다.

데브크래프트는 알림을 구현할 때 알림 생성, 화면 이동, 로그인 복구, 주문 조회를 한 흐름으로 연결합니다. 아래 시연에서는 운영자가 배송 상태를 저장하면 회원 A의 알림함에 소식이 생깁니다. 같은 알림을 정상 로그인과 로그인 만료 상태에서 열고, 다른 회원 주문을 요청했을 때도 비교할 수 있습니다.

구현 과정 01

배송 상태와 알림의 주문 번호를 함께 저장합니다

운영자가 주문 O-204를 ‘배송 중’으로 바꾸면 서버는 주문 상태를 저장하고, 그 주문의 고객에게 보낼 알림을 만듭니다. 알림에는 받는 회원, 이동할 화면의 종류, 연결된 주문 번호를 둡니다. ‘주문 상품이 출발했어요’라는 문장은 고객에게 보여줄 안내이고, O-204는 어떤 주문을 열지 찾는 기준입니다.

시연에서는 실제 서버가 같은 데이터베이스 작업 안에서 주문 상태를 바꾸고 알림 N-1을 저장합니다. 처음에는 준비된 알림을 바로 눌러볼 수 있습니다. ‘추가 상황’의 ‘배송 중으로 저장’도 같은 작업을 실행하며, 반복해서 눌러도 이번 배송 소식의 알림을 하나 더 만들지 않습니다. 실제 서비스에서는 어떤 상태 변경마다 알림을 보낼지와 재처리 시 같은 소식을 중복 생성하지 않을 기준을 정합니다.

앱에서 연결하는 일

저장된 알림 목록을 읽어 제목과 주문 확인 버튼을 보여줍니다.

서버에서 구현하는 일

주문 상태와 알림의 대상 회원·화면 종류·주문 번호를 저장합니다.

요청 값과 구현 기준 자세히 보기
주문 O-204 : 배송 준비 중 → 배송 중
알림 N-1 : 받는 회원 A / 화면 ORDER / 주문 O-204
같은 배송 소식 재처리 : 기존 알림 N-1 유지
알림 N-1에 받는 회원 A와 화면 종류 ORDER, 주문 번호 O-204를 저장하고 상세 조회로 연결하는 과정.
알림 N-1에 받는 회원 A와 화면 종류 ORDER, 주문 번호 O-204를 저장하고 상세 조회로 연결하는 과정. 이미지를 눌러 크게 볼 수 있습니다.

구현 과정 02

알림을 선택하면 연결된 주문을 서버에 요청합니다

고객이 알림 N-1을 누르면 앱은 선택한 알림 번호를 서버에 보냅니다. 서버는 그 알림이 현재 회원의 것인지, 이동할 화면이 허용된 종류인지 확인한 뒤 연결된 주문 O-204를 찾습니다. 화면을 이동시키는 정보와 주문의 실제 내용을 나누어 다루는 구조입니다.

시연에서는 앱이 알림 번호를 보내고 서버가 목적지를 해석합니다. 서비스에 따라 앱이 화면 종류와 주문 번호를 먼저 받아 이동할 수도 있습니다. 어느 구조를 택해도 알림의 번호나 주소를 알고 있다는 이유만으로 주문 내용을 보여주면 안 됩니다.

앱에서 연결하는 일

선택한 알림 번호를 유지하고 조회 중 상태를 표시합니다.

서버에서 구현하는 일

현재 회원의 알림을 찾고 허용된 주문 상세 화면으로 연결합니다.

요청 값과 구현 기준 자세히 보기
POST /api/open
{ notificationId: "N-1" }

서버가 찾은 이동 대상 : ORDER / O-204

구현 과정 03

주문을 조회할 때 로그인과 열람 권한을 확인합니다

서버는 로그인 정보에서 현재 회원을 확인하고, 해당 회원이 O-204를 볼 수 있는지 검사합니다. 시연에서는 주문 소유자가 회원 A인지 확인한 뒤 주문 번호·상품·수량·현재 배송 상태를 반환합니다. 앱이 요청 본문에 ‘회원 A’라고 적은 값으로 권한을 결정하지 않습니다.

‘다른 회원 주문 요청’을 누르면 같은 회원 A가 다른 주문 번호를 요청합니다. 서버는 열람을 거절하고 주문 내용을 보내지 않습니다. 상세 화면을 숨기는 처리만으로 끝내지 않고, 거절 응답에 다른 회원의 상품·수량 같은 내용이 들어 있지 않은지도 확인합니다. 알림으로 들어온 경우와 주문 목록에서 직접 연 경우에 같은 조회 규칙을 적용합니다.

앱에서 연결하는 일

허용된 응답은 주문 상세로 표시하고, 거절 응답은 내용 없이 안내합니다.

서버에서 구현하는 일

확인된 로그인 회원과 주문 소유자를 비교하고 허용된 데이터만 조회합니다.

요청 값과 구현 기준 자세히 보기
현재 회원 A + 주문 O-204의 소유자 A → 200 / 주문 내용
현재 회원 A + 다른 회원의 주문 → 403 / 주문 내용 없음

구현 과정 04

로그인이 만료되면 선택한 알림을 보존합니다

알림을 누를 때 로그인이 만료돼 있으면 서버는 주문 내용 대신 로그인 필요 응답을 보냅니다. 앱은 사용자가 선택한 알림 번호를 잠시 보존하고 로그인 화면을 보여줍니다. 로그인 뒤에는 선택한 알림을 다시 서버에 요청해 원래 보려던 주문으로 이어갑니다.

시연에서 ‘로그인 만료로 바꾸기’를 누르고 같은 알림을 열어보세요. ‘회원 A로 로그인하고 계속’을 누르면 서버의 로그인 상태를 바꾼 뒤 N-1을 다시 요청합니다. 실제 서비스에서는 비밀번호·간편 로그인 등 해당 서비스의 인증 절차를 연결합니다. 로그인 후 회원이 달라졌다면 보존한 목적지도 새 회원의 권한으로 다시 확인해야 합니다.

이동을 기억하는 범위는 앱이 살아 있는 동안인지, 앱이 종료된 뒤 다시 실행돼도 이어갈 것인지 정합니다. 보존한 값은 허용된 화면 종류와 식별자로 제한하고, 임의의 외부 주소로 이동하게 만들지 않습니다.

앱에서 연결하는 일

로그인 필요 응답을 받으면 알림 번호를 보존하고, 로그인 뒤 같은 대상을 재요청합니다.

서버에서 구현하는 일

복구된 로그인 회원으로 목적지와 주문 권한을 다시 검사합니다.

요청 값과 구현 기준 자세히 보기
알림 N-1 선택 → 로그인 만료 401
선택한 N-1 보존 → 로그인
N-1 재요청 → 현재 회원 권한 재확인 → O-204 조회
로그인이 만료되면 선택한 알림 N-1을 보존하고 로그인 뒤 권한을 다시 확인해 주문 O-204로 돌아가는 과정.
로그인이 만료되면 선택한 알림 N-1을 보존하고 로그인 뒤 권한을 다시 확인해 주문 O-204로 돌아가는 과정. 이미지를 눌러 크게 볼 수 있습니다.

구현 과정 05

오래된 알림을 눌러도 현재 주문을 다시 읽습니다

알림이 만들어진 뒤 주문 상태는 다시 바뀔 수 있습니다. ‘배송 중’ 알림을 나중에 눌렀을 때 이미 배송이 끝났다면 상세 화면에는 현재 저장된 처리 결과를 보여줘야 합니다. 알림 문구는 소식이 발생한 시점의 안내로 두고, 상세 화면은 서버에서 새로 읽은 주문을 기준으로 표시합니다.

시연의 ‘배송 완료로 변경’을 누르면 주문 상태만 바뀌고 이전 알림 제목은 유지됩니다. 같은 알림을 다시 열거나 ‘현재 내용 다시 조회’를 누르면 화면에 남아 있는 값을 재사용하지 않고 서버에 저장된 현재 상태를 가져옵니다. 주문이 삭제됐거나 계정의 열람 권한이 바뀌었다면 내용을 비우고 확인할 수 없다고 안내할 조건도 정합니다. 실패했을 때 직전에 보던 다른 주문의 내용이 남아 있지 않게 만드는 일도 포함됩니다.

앱에서 연결하는 일

목적지 주문 번호로 새로 받은 내용을 표시하고 실패 시 이전 상세 내용을 비웁니다.

서버에서 구현하는 일

조회할 때마다 현재 상태와 접근 가능 여부를 확인합니다.

요청 값과 구현 기준 자세히 보기
알림 제목 : 소식이 발생한 시점의 안내
상세 화면 : GET /api/order?id=O-204 로 다시 읽은 현재 값
조회 거절 : 이전 주문 내용 제거 후 안내

구현 과정 06

알림함 이동과 실기기 푸시 검수를 나누어 확인합니다

이 시연에서 실제로 확인하는 범위는 알림 기록 저장, 앱 알림함 조회, 로그인 복구, 주문 권한 검사와 상세 조회입니다. 휴대전화의 잠금화면에 푸시를 보내는 단계와 푸시를 눌러 꺼져 있던 앱을 여는 단계는 기기·운영체제와 연결해 별도로 구현하고 검수합니다.

개발 범위를 정할 때는 알림함에서 열기, 앱이 켜진 상태에서 푸시 열기, 앱이 종료된 상태에서 푸시 열기, 로그인 만료 후 복귀를 구분해 확인합니다. Android에서는 알림에서 상세로 들어온 뒤 뒤로 가기 경로도 설계합니다. iPhone과 Android의 실제 기기에서 같은 주문이 열리는지는 각 환경에서 확인해야 합니다.

개발사에는 ‘알림을 누르면 주문 상세로 이동’이라는 문장과 함께, 어떤 주문 번호를 전달하고 어디에서 권한을 확인하며 로그인 뒤 어디로 돌아올지 설명해달라고 요청해보세요. 앱 화면, 서버 조회, 실제 기기 진입까지 어디까지 이번 범위에 들어가는지 구체적으로 비교할 수 있습니다.

앱에서 연결하는 일

알림 진입 경로와 뒤로 가기, 로그인 후 복귀 화면을 이어줍니다.

서버에서 구현하는 일

진입 경로가 달라도 같은 목적지·열람 권한·현재 주문 조회 규칙을 적용합니다.

요청 값과 구현 기준 자세히 보기
알림함에서 열기 / 앱 실행 중 푸시 / 종료 후 푸시
로그인 유효 / 만료 후 복귀 / 다른 회원 로그인
정상 주문 / 열람 불가 / 삭제된 주문
처리 원리의 참고 자료

Android Developers · 알림에서 화면 열기 · 알림으로 연 화면과 뒤로 가기 경로를 함께 설계

OWASP · 요청마다 열람 권한 확인 · 조회 경로와 무관하게 각 요청에서 서버 권한 검사

알림과 상세 화면의 연결 범위를 함께 정리하세요

어떤 소식을 누구에게 알리고, 누르면 어느 화면으로 이어질지 알려 주세요. 로그인 복구와 상세 조회까지 필요한 개발 범위를 함께 나눕니다.

30분 무료 상담 신청
앱이 만들어지는 방식으로 돌아가기