Docker 기반 웹 푸시 알림 시스템 - 5

실제 로직 gif

PWA 웹 푸시 시스템 구축 최종 정리

1. 프로젝트 개요

이번 프로젝트의 목표는 PWA 웹 푸시 기능을 Docker 기반 구축하는 것이 목표였다.

단순히 기능 구현이 아니라,

• 실제 운영 서버 적용
• Docker 기반 배포 환경 반영
• Oracle 10g 사용 환경 고려
• 기존 통합 로그인 시스템과의 분리

를 기준으로 설계를 진행했다.

---

2. 기술 스택

최종 운영 환경은 다음과 같다.

[Backend]
- Spring Boot 3.5.9
- Java 17
- Spring Data JDBC
- Oracle 10g

[Infra]
- Docker (Rocky Linux)

[Frontend]
- PWA
- Service Worker
- Web Push API

[Push 인증]
- VAPID Key 기반 인증

특이사항:

• 로컬 / 운영 동일 버전 DB 사용
• Oracle 10g 사용으로 최신 기능 제약 존재
• ojdbc6 → ojdbc11 버전으로 수정

---

3. 초기 설계 vs 현실 설계

[초기 목적 및 설계]

• 사용자 테이블과 푸시 구독 정보 연계
• 통합로그인 시스템과 직접 연결
• redis를 사용한 대량 발송 로직 처리

[현실적 제약]

• 통합로그인 시스템 연동 시 라이선스 및 구조 변경 이슈
• 브라우저 Service Worker를 활용해야하므로, endpoint 기준 관리 필요
• memory Queue만으로도 충분하여 추후 확장 예정

---

4. 최종 적용 구조

푸시 구독 정보를 독립적으로 관리하여 아래와 같은 특징을 갖는다.

• endpoint 기준 관리
• 중복 구독 방지 로직 적용
• 만료 구독 자동 삭제 처리

---

5. PWA 구성 요소

5-1. Service Worker 등록

navigator.serviceWorker.register('/sw.js')

5-2. VAPID 키 기반 구독 생성

const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: vapidPublicKey
});

5-3. 서버 저장 처리

• endpoint
• p256_key
• auth_key
• bros_type
• os_type

DB 저장

---

6. 모바일 이슈 및 정책 정리

• PC Chrome
  - 정상 동작
• Android Chrome, iOS Safari
  - 홈 화면에 추가 후 실행 시 정상 동작
• 네이버 / 카카오 인앱 브라우저
  - Push API 미지원

▶ 모바일은 브라우저 실행 상태가 아니라, 반드시 "설치형 PWA 상태"여야 동작한다는 점이 핵심이었다.

---

7. 운영 환경 구성

• Docker 기반 컨테이너 운영(프록시 네트워크 구성)
• Nginx Reverse Proxy 구성
• HTTPS 필수 적용
• VAPID Key 운영 서버 기준 발급 및 관리

---

8. 현재 완료 단계 정리

• PWA 적용 완료
• 웹 푸시 구독 및 발송 기능 구현
• 모바일 정책 대응 가이드 적용
• 별도 구족 테이블 관리 구조 완성
• 확장 가능한 구조 유지 및 모듈화

---

9. 향후 개선 방향

1. 사내 통합 로그인 시스템 연동 (endpoint + ID 기반 푸시 관리)
2. 사용자 기반 푸시 타겟팅
3. 구독 상태 모니터링 대시보드
4. 장애 대응 자동화

---

10. 마무리

이번 프로젝트는 처음부터 "완성형 아키텍처"를 목표로 하지 않았다.

대신 Agile(애자일) 방식의 점진적 확정 전략을 선택했다.

 

애자일의 핵심은 다음과 같다.

• 처음부터 모든 것을 설계하지 않는다.
• 작게 만들고 빠르게 검증한다.
• 현실 제약 안에서 동작 가능한 결과물을 우선 제공한다.
• 이후 점진적으로 개선한다.

이번 PWA 기반 웹 푸시 시스템 역시 동일한 접근이었다.

초기 설계 단계에서는 사용자 테이블과 직접 연동되는 구조, 권한 기반 발송 제어, 통합 로그인 기반 사용자 식별 구조까지 고려했다.

그러나 실제 환경에서는 다음과 같은 현실적 제약이 존재했다.

• 사내 통합 로그인 시스템 연동 필요
• 라이선스 및 정책 이슈
• 조직 간 협의 절차
• 기존 시스템 영향도 검토

이러한 상황에서 이상적인 구조를 고집했다면 프로젝트는 시작조차 어려웠을 가능성이 높다.

그래서 선택한 방향은 명확했다.

“현실적으로 구현 가능한 최소 기능부터 완성한다.”

 

그 결과 현재 단계에서는:

• PWA 기반 웹 푸시 구조 확립
• 모바일 정책 대응 구조 정리
• 별도 구독 테이블 기반 독립 구조 완성
• 운영 환경(Docker + HTTPS) 안정화

즉, 기능적으로는 독립 운영 가능한 1차 버전이 완성된 상태다.

향후 통합로그인 시스템이 도입되어 사용자 식별 기반 푸시 관리 구조로 확장될 경우, 이 프로젝트는 단순 기능 개선이 아닌 사내 인증 체계와 연결되는 대외비 성격의 프로젝트로 전환될 가능성이 높다.

이는 블로그에는 공개하기 어려운 영역으로 판단되어 기록은 여기까지 작성할 예정이다.

---