Situation
이마트앱 근거리 배송 2.0 프로젝트에서 수행사가 자사 솔루션 기반 React(Next.js)로 개발하겠다고 당일 아침 통보했습니다. 내부팀 현행 스택은 Vue.js였기 때문에, 동일 앱 내에서 두 프레임워크가 혼재되는 상황이 발생했습니다.
Problem
홈/쇼핑메모에서 4개 서비스의 상품 카드를 교차 사용하고 있었기 때문에 React로 이중 구현이 필요했습니다. hooks/ecommerce, hooks/product 등 공유 로직 10개 이상의 파일이 서비스 간 의존 관계를 갖고 있었고, Pinia store 4개 영역(장바구니, 단골점포, 인증, 상품)의 상태 공유가 불가능해지는 문제가 있었습니다. 네이티브 인터페이스(앱 브릿지) 7종을 양쪽 프레임워크에서 이중 관리해야 하는 부담도 존재했습니다.
여기서 핵심 제약은 "의견"으로 반대하면 정치적 갈등이 되기 때문에, "팩트"만으로 의사결정 근거를 제공해야 한다는 점이었습니다.
Approach
감정적 반대가 아닌 **기술적 사실(팩트)**만 문서화하는 원칙을 수립했습니다. 실제 코드 기반으로 교차 의존 현황을 분석했고(grep, dependency graph), 30건의 이슈를 4개 대분류(개발/운영비용/안정성/인프라)로 구조화했습니다. 기술 문서와 비개발자용 요약 문서를 이원화하는 전략을 취했습니다.
Implementation
당일 16:00까지 완료 (통보 후 ~6시간)
기술 이슈 팩트 문서: 30건 도출
| 항목 | 비교 | 값 (건) |
|---|---|---|
| 개발 | 11 건 | |
| 인프라 | 12 건 | |
| 안정성 | 4 건 | |
| 운영 비용 | 3 건 |
개발 영역에서 11건이 도출되었으며, 상품 카드 이중 구현, 공유 로직 복제, 결제 플로우 단절 등이 포함되었습니다. 운영 비용 영역은 3건으로 이중 유지보수, 배포 파이프라인 복잡도, 장애 진단 난이도가 해당되었습니다. 안정성 영역 4건에는 상태 동기화 실패, 네이티브 브릿지 이중 관리, 번들 사이즈 증가가 있었고, 인프라 영역이 12건으로 빌드 파이프라인, CDN 캐시, 모니터링, CI/CD 분리 이슈가 포함되었습니다.
심각도 기준으로 Critical/High가 17건, Medium이 13건이었습니다.
비개발자용 서비스 영향 문서
비즈니스 리스크 3가지(사용자 경험 분열, 외주 의존 속도 저하, 장애 통제권 이슈)를 정리하고, 비용 영향 비교표(현재 vs 전환 후)를 작성했습니다.
4단계 대응 플로우
- 팩트 정리
- 수행사 검토 요청
- 가능/불가능 분류
- 경영진 의사결정
Result
객관적 근거 자료 채택
경영진 의사결정용 공식 문서로 활용
수행사 공식 전달
항목별 가능/불가능 회신 요청의 기반
기술적 판단 기준 확립
독립 지면이면 React 무방, 기존 서비스와 섞이면 통일 필수
내부팀 역할 확정
2명 전업 투입(가이드 및 코드 품질 모니터링)
Learnings
기술적 의사결정에서 "의견 vs 팩트"의 차이는 결정적이었습니다. 팩트만 놓으면 정치 없이 결론이 나왔습니다. 교차 의존 분석은 코드 grep만으로 6시간 내 완료할 수 있었는데, 이는 평소 아키텍처를 파악하고 있어야 가능한 속도였습니다.
비개발자용 문서를 별도로 만드는 비용은 크지 않았으나 효과는 3배였습니다. 기획과 경영진까지 한번에 전달할 수 있었기 때문입니다. 결국 당일 대응 능력은 기존 코드베이스 이해도와 문서화 속도의 곱이며, 평소 아키텍처 파악이 핵심 자산이라는 점을 확인했습니다.