- 기간
- 2026.01 ~ 2026.06
- 기술
배경
- 요구
- 아파트 단지 내 영화관 예매를 입주민이 쓰던 커뮤니티 앱 안에서 완결
- 앱 추가 설치
- 영화 한 편 보려고 앱을 하나 더 깔게 하면 이탈 확정
제약
- 실행 환경이 우리 것이 아님
- 상대 앱 웹뷰 안에서 동작
- 인증 = 상대 플랫폼
- 예매 · 결제 = 우리
- 착수 시점 상대 앱 부재
- 붙여볼 대상이 없음
- 비입주민 진입 차단
- 웹뷰 진입 전에 막아야 함
기능
연동 규격두 회사가 같은 문서를 보고 붙이도록
- 앱은 웹뷰 컨테이너와 복귀 처리, 웹이 인증 · 예매 · 결제를 담당하는 것으로 경계 정의
- 요구사항 정의서와 API 규격을 작성해 양측이 같은 기준을 참조
인증 경계입주민 확인을 웹뷰 밖에서 끝냄
- 세션 코드를 앱이 발급받아 웹에 전달, 입주민 확인은 서버 간 호출로 처리
- 입주민 식별 정보가 웹뷰 URL 에 남지 않도록 설계
- 입주민으로 확인되지 않으면 웹뷰 진입 전에 차단
비회원 예매가입 없이 동 · 호수로 식별
- 회원가입 절차 없이 예매부터 결제까지 완결되는 흐름 정의
검증 환경상대 앱이 없는 상태에서 붙여보기
- 파트너 앱을 대신할 목 호스트 앱 구현
- 목 서버 3종(상대 플랫폼 · 우리 서버 · 예매 웹) 구현
- 입주민 · 비입주민 테스트 계정과 시나리오 정리
예매 웹 재사용기존 웹을 그대로 태움
결정
상대 앱에 네이티브로 이식경험 일관 / 상대 개발 일정에 종속
전용 앱 신규 개발경험 통제 / 설치 유도 실패 시 무의미
기존 예매 웹을 상대 앱 웹뷰에채택
근거
- 실제 결정 = 경계를 어디에 둘 것인가
- 앱은 웹뷰 컨테이너와 복귀만 / 인증·예매·결제는 전부 웹
- 상대 앱 배포 주기 통제 불가
- 앱에 로직을 두면 규칙 변경마다 상대사 릴리스 대기
- 예매는 상영 일정에 묶임
- 그 지연을 감당할 수 없음
득실
얻은 것
상대사 릴리스와 무관한 배포 주기 / 예매 로직 한 벌
포기한 것
웹뷰 내 네이티브 수준의 반응 속도와 제스처
결과
- 상대사 일정과 무관하게 진행
- 상대 앱 없이도 연동 전 구간을 로컬에서 재현
- 설치 · 가입 없이 예매 완결
- 쓰던 앱 안에서 그대로 끝남
- 예매 로직 한 벌만 유지
- 기존 예매 웹을 그대로 재사용
- 식별 정보가 URL 에 미노출
- 입주민 확인은 서버 간 호출로
회고
초기 규격은 본인인증 필요 여부를 앱이 판단 → 같은 판단을 양쪽이 나눠 갖는 구조. 이후 웹 단독 판단으로 정리. 경계 기준은 화면·기능이 아니라 판단의 주체다.
자료
화면 캡처는 공개 범위를 고려해 포트폴리오에만 담았습니다. 요청하시면 개별 전달드립니다 — nuyoi7@gmail.com