chore[issue-post]: add 주문서회고 내용

posts/blog/2412-order.mdx

@@ -16,17 +16,53 @@ description: 머스트잇 주문서 Vue2에서 Next 15로 마이그레이션하
 
 ### 성과 
 
-(작성중)
+![To-be FCP](/images/blog/24/to-be-fcp.webp)
+
+일단 마이그레이션 결과부터 말하자면, 상품 PDP에서 바로구매 버튼을 눌러 주문서에 진입하는 경우  
+**FCP가 1.44초에서 0.41초**로 70% 빨라졌으며, **LCP는 1.44초에서 0.7초** 즉 절반으로 줄어들었다. 
+**TTFB는 1.06초에서 0.15초로** 줄었다. 
 
 ### 발단
 
 **원래 주문서는 vue 기반의 nuxt**로 되어있었다. 
-본격적으로 시간과 인력을 할당받아하는 게 아니었고 프로젝트 중간중간 room이 생길때 팀 내부적으로 하기로 했었다. 
+팀에서는 오랫동안 주문서 진입이 느리다는 문제를 계속 인식하고 있었지만 우선순위에서 밀린 상태였다.
+그래서 주문서 렌더링 개선 및 리팩토링 프로젝트는 본격적으로 시간과 인력을 할당받아하는 게 아니었고, 
+여러 프로젝트 중간중간 room이 생길때 팀 내부적으로 하기로 했었다. 
 그렇기에 기술 스택을 유지하면서 리팩토링과 주문서 내 렌더링 개선, 버그만 수정하기로 했었다. 
 주문서는 복잡한 로직이 있고 결제가 엮여있는 이커머스의 핵심 기능이기에 팀에서도 잘 못 건드리고 있던 부분인데, 
 성능이 안 좋았고 개선의 여지가 많았다. 
 그래서 이런 코어이면서도 레거시인 코드를 리팩토링해보고 싶어서 팀 리드한테 먼저 하고 싶다고 말했고, 동료 팀원 한 명과 하게 되었다.
 
+### 작업 순서 
+
+주문서 개선 프로젝트는 아래의 순서로 진행되었다.
+
+** 1. 성능 측정, 문제 파악** 
+
+가장 먼저 라이트하우스, 개발자 도구로 주문서 진입 시의 성능을 측정했다.
+주문서 윗부분과 아랫 부분을 나눠 네트워크 요청을 보냄에도 눈에 띄게 느렸다.
+이 단계에서 파악한 문제로는 크게 렌더링 성능과 DX가 있었다. 
+
+첫번째 렌더링 성능 문제. props가 깊게 내려가고, Vue의 emit이 조상을 엄청 찾아간다.
+카드 할부 정보를 가져오는 내용과 결제를 위핸 써드파티 라이브러리들을 준비하는 아랫 부분이 특히 느렸다.
+prop을 자식에서 부모 컴포넌트로 올리는 부분들이 속도 저하의 원인인 것 같았다. 
+
+두번째로 DX 문제. 
+
+기존 주문서의 코드는 2023년 초에 Php에서 로직 그대로 옮겨온 것이었다고 한다.
+그 과정에서 더이상 안 쓰는 코드가 많이 남아있는 상태였다. 그리고 emit을 사용하는 부분들이 많아 코드를 추적하기 어려웠다.
+그래서 결제 모듈들과 통신하는 데이터와 주문서에서만 다루는 데이터들을 나눠 관리하도록 리팩토링 방향을 정했었다.
+
+**2. TC 작성** 
+
+**3. 테스트 코드 설계, 작성**
+
+**4. 이 단계에서 vue에서 개선하지말고 아예 next.js로 마이그레이션하기로** 결정이 내려졌다.
+php에서 vue로 마이그레이션하면서, 아예 다 보여주거나 안 보여주는 'All or nothing' 전략이 vue에 그대로 묻어있었다. 
+next의 suspense, streaming ssr을 활용하여 조금이라도 유저에게 주문서를 더 빨리 보여주기로 했다.
+
+**5. next.js 개발**
+
 ### 테스트 코드를 짠 이유
 
 주문서 코드를 건들기에 앞서 테스트 코드를 무조건 작성해야한다고 생각했다. 
@@ -42,9 +78,8 @@ description: 머스트잇 주문서 Vue2에서 Next 15로 마이그레이션하
 
 ### Playwright을 선택한 이유
 
-TC를 기반으로 Playwright 테스트 코드를 작성했다. 
-전 회사에서 Cypress로 e2e 테스트를 짰었는데 이번에 Playwright을 선택한 이유는 2가지였다.   
-
+TC를 기반으로 [Playwright의 Testing Philosophy](https://playwright.dev/docs/best-practices)를 참고해 테스트 코드를 작성했다. 
+전 회사에서는 Cypress로 e2e 테스트를 짰었는데 이번에 Playwright을 선택한 이유는 2가지였다.   
 
 1. Playwright은 **Google Chrome for Android, Mobile Safari 테스트를 지원**한다. 
 반면 [Cypress는 2024년 8월 기준 Safari를 지원하지 않았다](https://docs.cypress.io/guides/guides/launching-browsers#Unsupported-Browsers).
@@ -60,6 +95,8 @@ e2e 테스트를 구현하면서 ~~역시나 노가다~~라는 생각을 하긴
 테스트 코드를 다 작성한 이후엔 엔지니어링 리드의 제안으로, **'주문서에 E2E 테스트 끼얹기'**라는 제목의 간단한 발표를 했다. 
 e2e 테스트 코드를 작성한 이유와 테스팅 툴 선택과정, 자세한 적용법 등의 내용을 담았다.
 
+테스트코드가 주문서 페이지만 커버하기에 배포 속도가 길어지는거에 비해 효율이 나오지 않을 것 같아 CI/CD에 붙이진 않았다.
+
 테스트 코드를 다 작성해가던 타이밍에, 아예 Next.js로 주문서를 띄워서 
 주문서 **진입** 성능부터 개선하자는 팀 내부 의견이 컨펌되어 본격적으로 Next.js로 주문서를 마이그레이션하게 되었다. 
 너무너무너무 좋은 기회였다.