상황 (Situation)

이마트앱 커머스 서비스(오더픽, 오더투홈, 와인그랩, 디지털그랩 + 결제)를 외주 솔루션 회사가 React(Next.js)로 재구축하겠다는 제안이 들어왔습니다. 이유는 "확장성". 기존 Vue 3 SPA는 유지한 채 하나의 앱 안에 두 프레임워크가 공존하는 구조가 됩니다.

이마트앱의 특수한 환경 제약:

  • 네이티브 앱 → 멀티웹뷰 → JSP(Spring MVC) → S3 CDN → Vue 번들 로드
  • 주 고객층 50대 → Chrome 44+, Safari 13+ 대응 필수
  • 외부 라이브러리 의존 지양 (대부분 자체 구현)
  • 네이티브 브릿지 79개 인터페이스

과제 (Task)

이 제안을 수락했을 때 발생할 수 있는 모든 기술적/비즈니스 리스크를 식별하고, "확장성" 주장에 대한 구조적 반론을 준비해야 했습니다.

리스크 분류별 이슈 건수
항목비교값 (건)
개발1111 건
인프라1212 건
안정성44 건
운영비용33 건

행동 (Action)

1단계: 서빙 아키텍처 역추적

AGENTS.md에 "Vite 빌드"라고 적혀있었지만, 실제 코드를 열어보니 완전히 달랐습니다:

  • JSP 프로젝트의 layoutSpaPage.jsp가 HTML 호스트
  • s3_front_resource.jsp의 ResourceVersionService가 S3 manifest.json을 파싱하여 hash된 Vue 번들 URL을 JSP 변수로 주입
  • inc_script.jsp가 서버 세션 정보를 window.* 전역변수로 주입
  • 빌드 도구는 Vite가 아닌 Vue CLI 5

이 구조를 이해하지 않으면 "React를 어떻게 호스팅할 것인가"라는 근본 질문에 답할 수 없습니다.

2단계: 4관점 병렬 분석 (Council 패턴)

3개의 분석 관점을 병렬로 실행했습니다:

  • 아키텍처 관점: 상태 공유, 라우팅 분기, 네이티브 브릿지, 인증 연속성
  • 현 비용 관점: 컴포넌트 포팅, API 래퍼, 테스트 이중화, 공수 추정
  • 리스크/UX 관점: 사용자 생명주기 단절, 장애 전파, 조직 비용

3단계: 30건 이슈 구조화

4개 대분류(개발 11 + 운영비용 3 + 안정성 4 + 인프라 12)로 정리했습니다. 각 이슈에:

  • 구체적 시나리오 (코드 경로 포함)
  • 심각도 (상/중)
  • 기존 아키텍처에서 왜 이것이 문제가 되는지

4단계: "확장성" 반론 설계

외주사가 말할 수 있는 6가지 주장에 대해 각각:

  • 주장의 실제 의미 (what they actually mean)
  • 이마트앱 환경에서의 반론 (왜 여기선 안 되는가)
  • 실전 대화 스크립트

5단계: 이해관계자별 번역

같은 30건을 두 버전으로 작성했습니다:

  • 개발팀용: 코드 경로, 컴포넌트명, 구체적 기술 시나리오
  • 기획팀용: "사용자 경험 분열", "외주 의존 속도 저하", "매출 직결 장애 통제권 상실"

외주사 제안 (React 공존)

장점

  • 벤더 내부 인력 활용 가능
  • Next.js 생태계

고려할 점

  • 30건 리스크
  • 상태공유 race condition
  • JSP 호스팅 선행 필요
  • 운영비용 무기한 전가

기존 Vue 3 유지

장점

  • 네이티브 브릿지 79개 안정 연동
  • JSP 서빙 검증 완료
  • 단일 운영 체계

고려할 점

  • 벤더 "확장성" 주장에 대한 논리적 반박 필요

결과 (Result)

  • Confluence wiki 2페이지 산출 (개발 버전 + 기획 버전)
  • 30건 이슈 식별 — Critical 17건, Medium 13건
  • 핵심 반론: "기술 선택은 만드는 사람이 아니라 운영하는 사람의 환경에 맞춰져야 합니다"
  • 의사결정 자료로 활용되었습니다
🔍

식별

30건 리스크 구조화

🎯

핵심 반론

운영 환경 기준 기술 선택

📄

산출물

개발/기획 2버전 문서

일반화 가능한 패턴

"확장성" 주장에 대한 구조 분석 프레임워크

외부 벤더가 다른 프레임워크를 주장할 때:

  1. 실제 동기 분해: "확장성"을 벤더 내부 사정(인력, 보일러플레이트, 라이브러리 의존 개발 방식)과 클라이언트 환경 적합성으로 분리합니다
  2. 환경 제약 맵핑: 브라우저 지원 범위, 기존 인프라(호스팅, 인증, 네이티브 브릿지), 운영 구조가 새 기술과 충돌하는 지점을 식별합니다
  3. 비용 전가 분석: "만드는 비용"과 "운영하는 비용"을 분리합니다. 벤더는 전자만 최적화하고, 후자는 클라이언트가 무기한 부담하게 됩니다

멀티웹뷰 환경에서의 프레임워크 공존 제약

멀티웹뷰(매 페이지마다 새 웹뷰)는 역설적으로 프레임워크 공존을 쉽게 만드는(런타임 충돌 없음) 동시에 어렵게 만듭니다:

  • 상태 공유 = localStorage/cookie만 가능 (인메모리 불가)
  • 동시 쓰기 race condition
  • PubSub 이벤트 타이밍 의존
  • 새 프레임워크를 호스팅하는 JSP 레이아웃 선행 필요

기술 스택

Vue 3.3, Vue CLI 5, Pinia, TypeScript 4.8, Spring MVC (JSP), AWS S3, Azure Pipelines