< 문제점 >
* 헬스케어 중심 앱에 커머스 기능이 부재하여, 관련 상품 구매를 위해 앱 외부로 이탈하거나 별도 채널로 이동해야 하는 불편이 발생했습니다.
* 모바일 앱 환경에서 안정적으로 구동되는 하이브리드(WebView) 쇼핑몰 구조와, 앱 회원/혜택(디지털 화폐·쿠폰)과의 연동 요구가 동시에 존재해 설계 복잡도가 높았습니다.
* 무형 상품·기프티콘·선물하기 등 일반 배송 상품과 다른 판매/처리 프로세스가 필요했으며, 결제(간편/자동/무통장) 및 정산 데이터를 KB 내부 정산 시스템과 연계해야 했습니다.
* 웰니스/전문가 코칭 등 타 협력사 개발 영역과 인터페이스 연계가 필수였고, 프로젝트 중반 “외부 페이지 오픈 → 앱 내 노출”로 요구사항이 변경되며 일정/구조 리스크가 확대되었습니다.
* 공통 Swagger(REST API) 정의가 초기 전제(외부 오픈) 기준으로 진행되어 쇼핑몰 구현에 필요한 항목이 일부 누락되는 등 협력사 간 개발 기준 불일치가 발생했습니다.

< 프로젝트 목표 >
* KB 헬스케어 앱 내에서 자연스럽게 탐색–구매가 이어지는 하이브리드 쇼핑몰을 구축하여 앱 경험을 강화하고 이탈을 최소화합니다.
* 무형 상품/기프티콘 판매와 선물하기(회원·비회원) 기능을 포함한 확장 가능한 커머스 프로세스를 구현합니다.
* KB 헬스케어 회원 정보를 쇼핑몰 회원 체계로 연동하고, 디지털 화폐·쿠폰 등 혜택 적용 기반을 마련합니다.
* 결제(간편/자동/무통장)와 정산 데이터를 KB 내부 정산 관리 시스템으로 연동해 운영/정산 업무를 일원화합니다.
* 타 협력사 영역(웰니스/코칭 등)과의 화면·데이터 인터페이스를 안정적으로 연결하여 서비스 전체 흐름의 완성도를 확보합니다.

< 주안점 >
* 앱 내 노출(WebView 내장) 기준으로 정보 구조/전환 흐름/인증 연계를 재정의하여, 요구사항 변경에도 핵심 구매 플로우가 흔들리지 않도록 설계를 고도화했습니다.
* 무형 상품과 기프티콘의 주문·처리 특성을 반영해 상태값/정산 기준/고객 안내 정책을 분리 설계하고, 운영자가 관리 가능한 구조로 구현했습니다.
* 결제–정산–내부 시스템 연동 구간을 핵심 리스크로 보고, 데이터 정합성(매출/정산 기준)과 장애 대응(재처리/검증 가능 구조)에 초점을 맞췄습니다.
* 협력사 간 개발 기준 불일치(공통 Swagger 누락)를 빠르게 해소하기 위해 정례 회의와 이슈 트래킹을 운영하며, API 정의를 단기간에 정리해 병목을 최소화했습니다.
* 주 1회 개발 공유, 월 2회 테스트 공유 체계를 통해 변경 사항과 결함을 조기에 발견하고, 일정 리스크를 관리하면서 품질을 확보했습니다.

< 프로젝트 개요 >
KB 헬스케어 앱은 헬스케어 기능을 기본으로 제공하며, 앱 내에서 건강/웰니스 관련 상품을 구매할 수 있도록 커머스 기능(쇼핑몰)을 추가 구축한 프로젝트입니다.
헬스케어 영역(웰니스, 전문가 코칭 등)은 별도 협력사가 담당했으며, 저는 커머스 영역(하이브리드 쇼핑몰/상품·주문·배송/정산·선물하기 등) 구축과 타 영역 연계까지 포함해 프로젝트를 진행했습니다.

< 프로젝트 배경 및 필요성 >
기존 헬스케어 앱 사용자 경험을 유지하면서, 앱 내에서 자연스럽게 쇼핑이 이어지는 구조가 필요했습니다. 특히 일반 쇼핑몰과 달리 다음과 같은 요구가 핵심이었습니다.
* 헬스케어 앱 내 쇼핑몰 기능 추가(모바일 앱 중심)
* 앱에서 구동되는 하이브리드(WebView 기반) 쇼핑몰 필요
* 디지털 화폐 및 쿠폰 관리(혜택/포인트성 자산 포함)
* KB 계약사 고객의 앱/웹 및 혜택 연계
* 입점사 및 제휴사 운영을 위한 관리자 기능
* 상품/주문/배송 관리 기능
* 결제(간편/자동/무통장) 및 정산 관리
* 선물하기 기능(회원/비회원 선물, 비회원은 회원가입 유도)
* 타 협력사가 개발하는 웰니스/코칭 영역과 화면/데이터 인터페이스 연계
* 상품을 구독형으로 결제하여 매 월 자동 결제가 되고 자동으로 배송이 되는 시스템 구형

< 프로젝트 진행 과정 >
1) 요구사항 정의 및 협의
2) 현행 시스템 분석을 통해 개선 필요 기능 도출
3) 운영자 실무 기준으로 불필요한 프로세스 제거 및 개선 포인트 정리
4) 디자인 제작 및 컨펌
5) 주요 사용자 흐름(UI Flow) 재정립
6) 핵심 전환 구간 중심의 UI/UX 개선
7) 단계별 디자인 시안 공유 및 컨펌 진행
8) 개발 진행
9) 이지옵스 솔루션 기반 신규 시스템 구축
* 주 1회 개발 진행사항 공유 회의를 통해 일정·이슈 관리
10) 테스트 진행
11) 기능별·시나리오별 테스트 진행
* 월 2회 테스트 공유 회의를 통해 오류 디버깅 반영 공유
12) 프로젝트 감사
* 쇼핑몰 영역은 프로젝트 외부 감사를 최종 통과

정기적인 커뮤니케이션을 통해 진행 상황을 투명하게 공유하고,
이슈 발생 시 즉각적인 협의가 가능하도록 운영하였습니다.

< 구축 범위 및 핵심 기능>
이번 커머스 구축은 “앱 내 쇼핑 경험”과 “정산/운영의 연결”이 핵심이었습니다.

1) KB 헬스케어 앱 내 하이브리드 쇼핑몰 구축
* 앱 WebView 기반으로 쇼핑몰을 내장하여, 앱 이탈 없이 상품 탐색–구매까지 연결

2) 무형 상품 판매 프로세스 구축
* 배송이 없는 상품(서비스/이용권 성격 등)에 맞춘 주문 상태/사용 처리 흐름 설계 및 구현

3) 기프티콘 상품 판매 프로세스 구축
* 기프티콘 특성(발급/전달/사용)에 맞춘 상품 등록 및 판매 흐름 구현

4) 정산 데이터 연동
* 매출/정산 데이터를 KB 헬스케어 내부 정산 관리 시스템으로 연동하여, 운영자가 동일한 기준으로 정산을 관리할 수 있도록 구성

5) 회원 연동
* KB 헬스케어 회원 정보를 연동받아 쇼핑몰 회원으로 구현(로그인/구매/혜택 적용 연계)

6) 선물하기 기능
* 회원/비회원 모두 선물 가능하도록 구현
* 비회원은 수신 과정에서 회원가입을 유도하여 자연스러운 전환 구조를 확보

7) 구독형 상품 기능
* 상품 첫 결제 시, 결제한 카드 정보를 저장 및 해당 카드로 매월 결제됨을 고객에게 안내
* 매월 첫 결제한 일자에 자동 결제되는 프로세스 구성

< 기술적 이슈 및 해결 방안 >
이슈 1)
“외부 페이지 오픈”에서 “앱 내 노출”로 요구사항 변경
* 초기에는 “쇼핑몰 클릭 시 새 페이지 노출(외부 오픈)” 형태로 정의되어 개발이 진행되었습니다.
* 프로젝트 중반에 “앱 내부에서 쇼핑몰이 노출되는 형태(WebView 내장)”로 요구사항이 변경되면서, 쇼핑몰 제작 완료 목표가 1월에서 3월로 조정되는 등 일정과 구조 변경이 발생했습니다.

해결
* 기존 구현 방향을 전면 재검토하고, 앱 내 노출 구조를 기준으로 라우팅/화면 전환/인증 연계를 재정의했습니다.
* 변경 범위를 기능 단위로 쪼개 영향도(인증, 결제, 딥링크, 화면 히스토리 등)를 정리한 뒤, 우선순위를 재설정하여 핵심 구매 플로우부터 안정적으로 전환했습니다.
* 결과적으로 요구사항 변경 이후에도 기능 누락 없이 앱 내 쇼핑 경험을 완성했습니다.

이슈 2)
공통 Swagger(REST API) 정의에 쇼핑몰 요구가 반영되지 않은 상태로 진행
* 공통 API 스웨거가 “쇼핑몰이 외부에서 열린다”는 초기 전제 하에 개발되어, 쇼핑몰 구현에 필요한 인증/회원/연동 관점의 정의가 일부 누락된 상태였습니다.

해결
* 스웨거 담당 협력사와 빠르게 실무 회의를 진행해, 쇼핑몰에서 필요한 API 목록과 필수 파라미터/응답 구조를 재정리했습니다.
* 단기간 내 스웨거 정의를 보완하고, 이를 기반으로 쇼핑몰 구현에 즉시 적용하여 개발 병목을 해소했습니다.
* 공통 API 기준이 명확해지면서 커머스–헬스케어 타 영역 간 인터페이스 연계도 안정적으로 진행할 수 있었습니다.

< 프로젝트 성과 및 임팩트 >
* 앱 이탈 없는 구매 흐름 확보: 앱 내 하이브리드 구조로 탐색–결제–선물까지 일관된 UX 구성
* 판매 가능 상품군 확장: 무형 상품 및 기프티콘 판매 프로세스 구축으로 커머스 확장성 확보
* 운영/정산 일원화: 매출·정산 데이터를 KB 내부 정산 시스템과 연동해 운영 효율 향상
* 회원 연동 기반 개인화/혜택 적용 기반 마련: KB 회원 정보를 쇼핑몰 회원으로 구현해 마케팅/혜택 확장 가능
* 협력사 병렬 개발 리스크 대응: 스웨거/요구사항 변경 이슈를 회의체 기반으로 빠르게 정리해 개발 병목 최소화