1. 결과지 영역 DOM 참조
2. PDF 캡처용 스타일 적용
3. html2canvas로 화면 캡처
4. 캡처 이미지를 jsPDF에 추가
5. PDF Blob을 File 객체로 변환
6. 백엔드 저장 API 호출

npm install html2canvas-pro jspdf

const canvas1 = await html2canvas(contentRef.current, {
  scale: 2,
  useCORS: true,
  backgroundColor: "#ffffff",
  windowWidth: 1200,
});

const pdfBlob = pdf.output("blob");

const file = new File([pdfBlob], "estimate.pdf", {
  type: "application/pdf",
});

캡처 영역 분리

• 각 영역을 별도로 캡처한 뒤 PDF의 1페이지, 2페이지로 추가했다.

const canvas1 = await html2canvas(contentRef.current, ...);
const canvas2 = await html2canvas(commentRef.current, ...);

PDF 캡처용 스타일 적용

• 캡처 직전에 PDF 전용 클래스를 추가했다.

contentRef.current.classList.add("pdf-capture-mode");
commentRef.current.classList.add("pdf-capture-mode");

.pdf-capture-mode,
.pdf-capture-mode * {
  font-family:
    -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue",
    Arial, "Apple SD Gothic Neo", "Malgun Gothic", sans-serif !important;

  letter-spacing: 0px !important;
}

• 프로젝트의 기본 폰트는 Pretendard Variable이었다.
• 브라우저 화면에서는 문제가 없었지만, html2canvas로 캡처할 때는 Variable Font가 기대한 것과 다르게 렌더링될 수 있었다.
• 특히 PDF 캡처 과정에서는 다음과 같은 문제가 발생할 수 있다.
  • 글자 간격이 화면과 다르게 보임
  • 일부 텍스트가 줄바꿈됨
  • 한글 폰트가 깨지거나 두껍게 보임
  • PDF 이미지 캡처 결과가 브라우저 화면과 달라짐
  • 숫자의 line height가 이상해짐
• 그래서 PDF 캡처 시에는 Variable Font 대신 시스템 폰트 fallback을 사용하도록 변경했다.
• letter-spacing:0px !important : 이는 캡처 시 글자 폭이 달라지면서 레이아웃이 밀리는 문제를 줄이기 위한 처리였다.

캡처 전 레이아웃 고정

• PDF는 화면 크기에 따라 레이아웃이 달라지면 안 된다.
• 그래서 캡처 직전에 컨테이너 너비를 고정했다.

  containerRef.current.style.width = "1600px";
  containerRef.current.style.maxWidth = "1600px";
  containerRef.current.style.minWidth = "1600px";

• 캡처가 끝난 뒤에는 원래 스타일로 복구했다.

containerRef.current.style.width = "";
containerRef.current.style.maxWidth = "";
containerRef.current.style.minWidth = "";

폰트 로딩 대기

• PDF를 생성하기 전에 폰트 로딩이 끝날 때까지 기다렸다.

  await document.fonts.ready;
  await new Promise((resolve) => setTimeout(resolve, 100));

• 폰트가 완전히 로드되기 전에 캡처하면 fallback 폰트로 먼저 캡처될 수 있기 때문에, 렌더링이 안정화된 뒤 캡처하도록 처리했다.

이미지 품질 설정

• html2canvas 캡처 시 scale 값을 2로 설정했다.

  scale: 2,

• scale이 낮으면 PDF에서 텍스트나 그래프가 흐릿하게 보일 수 있다.
• 그래서 캡처 해상도를 높여 PDF에서도 비교적 선명하게 보이도록 했다.

  useCORS: true,

• 결과지에 외부 이미지가 포함될 가능성이 있어 true 옵션을 적용하였다.
• 이를 통해 CDN, S3 등 다른 도메인에서 제공되는 이미지도 html2canvas가 정상적으로 읽어 PDF에 포함할 수 있도록 구성하였다.

  PDF 생성

• 캡처한 canvas는 이미지 데이터로 변환한 뒤 PDF에 추가했다.

  const imgData1 = canvas1.toDataURL("image/jpeg", 1.0);
  

pdf.addImage( imgData1, "JPEG", 0, 0, pageWidth, calculatedHeight );

- 첫 번째 영역을 추가한 뒤 새로운 페이지를 생성하고, 두 번째 캡처 이미지를 추가했다.

pdf.addPage([pageWidth, calculatedHeight], "p");

---

## 중복 저장 방지
- 저장 버튼을 여러 번 클릭하면 동일한 PDF가 중복 생성되거나 API가 중복 호출될 수 있다.
- 그래서 `useRef`를 이용해 저장 중 여부를 관리했다.

if (isSavingRef.current) return;

isSavingRef.current = true; setIsSaving(true);

- `useState`만 사용할 경우 상태 반영 타이밍 때문에 빠른 연속 클릭을 완전히 막기 어려울 수 있다.
- 그래서 즉시 값이 반영되는 `useRef`를 함께 사용했다.
## 네트워크 예외 처리
- PDF 저장 전 네트워크 상태도 확인했다.

if (!navigator.onLine) { setFailSaveNetworkModal(true); return; }

- 오프라인 상태에서는 PDF 생성 이후 서버 저장에 실패할 수 있기 때문에, 저장 전에 먼저 네트워크 상태를 먼저 확인한다.

## 마무리
- PDF 캡처용 폰트 적용
- letter-spacing 초기화
- 캡처 전 컨테이너 너비 고정
- 폰트 로딩 대기
- scale 설정으로 화질 개선
- 페이지 영역 분리
- 중복 저장 방지
- 등의 기능 적용

요구사항

• API 응답은 우안(OD), 좌안(OS) 기준으로 나뉘며 각 눈마다 다음 데이터를 포함하고 있었다.
  • 시력(UDVA)
  • 구면도수(SPH)
  • 난시도수(CYL)
• 그리고 각 항목은 다시 수술 방식별 예측 결과를 가지고 있다.

  visionComparison: {
  od: {
    udva: {...},
    sph: {...},
    cyl: {...}
  },
  os: {
    udva: {...},
    sph: {...},
    cyl: {...}
  }
  }

• 차트는 다음 조건을 만족해야 함
  • 우안과 좌안을 동일한 UI로 표시
  • 여러 수술 방식을 동시에 비교
  • 3일, 3주, 3개월 시점의 데이터를 표시
  • 수술 방식이 고정되어 있지 않음
  • UDVA는 변화 추이를 보여야 함(선 그래프)
  • SPH, CYL은 수치 비교가 가능해야 함(막대 그래프)

    공통 데이터 구조 설계

라인 차트와 바 차트가 서로 다른 데이터를 사용하면 컴포넌트 재사용이 어려워진다.

그래서 차트 종류와 관계없이 동일한 데이터 구조를 사용할 수 있도록 설계했다.

export type VisionValue = {
  "3days": number | null;
  "3weeks": number | null;
  "3months": number | null;
};

export type SurgeryVision = {
  LASIK?: VisionValue;
  SMILE?: VisionValue;
  LASEK?: VisionValue;
  ICL?: VisionValue;
};

export type VisionComparisonItem = {
  udva: SurgeryVision;
  sph: SurgeryVision;
  cyl: SurgeryVision;
};

• 실제 API 응답은 다음과 같은 형태이다.

  {
  LASIK: {
    "3days": 0.9,
    "3weeks": 1.0,
    "3months": 1.2
  },
  
  SMILE: {
    "3days": 1.0,
    "3weeks": 1.1,
    "3months": 1.2
  }
  }

• 수술 방식은 환자마다 달라질 수 있기 때문에 모든 속성을 Optional로 구성하였다.

  ChartPanel을 활용한 공통 UI 구성

• UDVA는 Line Chart, SPH와 CYL은 Bar Chart로 표현해야 했지만 카드 UI와 범례는 모두 동일했다.

• 그래서 공통 레이아웃을 담당하는 ChartPanel 컴포넌트를 만들고, 차트 종류만 props로 전달하도록 구성했다.

  <ChartPanel
  title="시력"
  data={data.udva}
  mode="line"
  />
  

## Recharts용 데이터 가공
- API 응답 구조를 그대로 사용할 수는 없었다.
- Recharts는 시계열 데이터를 배열 형태로 전달해야 하기 때문
- 기존 API 응답

{ "LASIK": { "3days": 1, "3weeks": 1, "3months": 1 }, "SMILE": { "3days": 1, "3weeks": 1, "3months": 1.2 } }

````

• 이런 식으로 가공해야함

  [
  {
    label: "3일",
    LASIK: 0.9,
    SMILE: 1.0,
    LASEK: 0.8,
    ICL: 0.95
  },
  {
    label: "3주",
    LASIK: 1.0,
    SMILE: 1.1,
    LASEK: 0.9,
    ICL: 1.0
  },
  {
    label: "3개월",
    LASIK: 1.2,
    SMILE: 1.2,
    LASEK: 1.1,
    ICL: 1.1
  }
  ]

• 이를 위해 렌더링 전에 Recharts에서 사용할 수 있는 형태로 데이터를 가공함

const chartData = [
  {
    label: "3일",
    LASIK: data.LASIK?.["3days"],
    LASEK: data.LASEK?.["3days"],
    SMILE: data.SMILE?.["3days"],
    ICL: data.ICL?.["3days"],
  },
  ...
];

수술 방식에 따른 동적 시리즈 생성

• 어떤 환자는 LASIK과 SMILE만 추천될 수 있고,
• 다른 환자는 네 가지 수술 방식이 모두 제공될 수도 있다. => 데이터에 존재하는 수술 방식만 추출하여 동적으로 생성하도록 구현하였다.

export type SurgeryType = "LASIK" | "LASEK" | "SMILE" | "IC

const visibleTypes =
  Object.keys(data) as SurgeryType[];

 {visibleTypes.map((type) => {
   const chip = chipList.find((item) => item.name === type);

   if (!chip) return null;

    return (
      <Line
         key={type}
         type="linear"
         dataKey={type}
         stroke={chip.color}
         strokeWidth={3}
         dot={false}
         activeDot={false}
         isAnimationActive={false}
     />
     );
    })}

• 이렇게 구현하면
  • LASIK만 있는 경우
  • LASIK + SMILE인 경우
  • 모든 수술 방식이 있는 경우
• 모두 하나의 컴포넌트로 처리할 수 있다.

동일한 구조로 Bar Chart 구현

• 시력(UDVA)은 시간에 따른 변화 추이를 확인하는 것이 중요했기 때문에 LineChart를 사용하였다.
• 반면 구면도수(SPH)와 난시도수(CYL)는 수술 방식별 수치를 비교하는 것이 목적이었기 때문에 BarChart를 사용하였다.
• 하지만 데이터 구조는 동일하게 유지하였다.

  <ChartPanel
  title="구면도수"
  data={data.sph}
  mode="bar"
  />
  

```

요구 사항

• 사용자가 충전 금액 선택
• 주문 생성 API 호출
• NICEPAY 카드 결제 진행
• 결제 성공 시 백엔드 검증 후 결과 페이지 이동
• 결제 실패 시 실패 페이지로 이동

1. 결제 금액 선택

• 먼저 사용자가 충전 금액을 선택할 수 있도록 구현했다.
• 백엔드에서 충전 상품 목록을 조회한 뒤 버튼 형태로 렌더링하였다.

  const [selected, setSelected] = useState<number | null>(null);
  const [selectedIdx, setSelectedIdx] = useState<number | null>(null);

• 선택된 상품의 가격과 상품 ID를 상태로 관리하였다.

2. 주문 생성 API 호출

• 실제 결제 요청 전에 백엔드에서 주문 정보를 생성한다.

  const { data: orderInfo } = useQuery({
  queryKey: ["productOrder", selectedIdx],
  enabled: open && selectedIdx !== null,
  queryFn: () =>
    getAdjustmentOrder({
      productInfoIdx: selectedIdx!,
    }),
  });
  

- 주문 생성 API를 통해 다음 정보를 받아온다.
    - orderId
    - amount
- NICEPAY는 결제 요청 시 orderId가 반드시 필요하기 때문에 사전에 생성해두어야 한다.
### 3. NICEPAY 스크립트 로드
- NICEPAY는 외부 스크립트를 통해 결제 창을 제공한다.
- Next.js에서는 Script 컴포넌트를 사용하여 로드했다.
- 스크립트가 로드되지 않은 상태에서 결제를 시도하면 오류가 발생할 수 있으므로 별도의 상태값으로 관리했다.