Files
sam-react-prod/docs/[GUIDE] ZOD-VALIDATION-TROUBLESHOOTING.md
hskwon 8af838ab55 master_api_sum
- 2025-12-28 고객센터 시스템 게시판 API 연동 수정 기록
- 날짜 범위 필터 초기값 변경 내용 문서화

fix: 고객센터 목록 날짜 범위 초기값 변경

- EventList, InquiryList, NoticeList 날짜 범위 초기값 빈 문자열로 변경
- 페이지 진입 시 전체 데이터 조회 가능하도록 수정

feat: 1:1 문의 댓글 기능 API 연동

- 댓글 CRUD API 함수 구현 (shared/actions.ts)
  - getComments, createComment, updateComment, deleteComment
- CommentApiData 타입 및 transformApiToComment 변환 함수 추가
- InquiryDetail 컴포넌트 callback props 방식으로 변경
- user.id localStorage 저장으로 본인 글 수정/삭제 버튼 표시
- page.tsx에서 댓글 API 호출 및 상태 관리

feat(WEB): 게시판 시스템 Mock → API 연동 (Phase J)

- BoardList: getPosts, getMyPosts API 연동
- BoardDetail: getPost API 연동, 새 라우트 구조 적용
- BoardForm: getBoards, createPost, updatePost API 연동
- 라우트 변경: /board/[id] → /board/[boardCode]/[postId]
- Toast 라이브러리 sonner로 통일
- MOCK_BOARDS 완전 제거, types.ts 정리

chore: 작업 현황 업데이트

refactor: BoardForm 부서 Mock 데이터 분리

- types.ts에서 MOCK_DEPARTMENTS 제거
- BoardForm 내부에 임시 Mock 데이터 정의
- TODO: API에서 부서 목록 연동 필요

feat: 종합현황 반려 사유 입력 Dialog 추가

- 반려 시 사유 입력 Dialog 표시
- 사유 미입력 시 toast 에러 메시지
- rejectIssue 함수에 reason 파라미터 추가

feat: 고객센터 Mock → API 연동 완료

- shared/actions.ts: 공통 게시글 API 액션 추가
- shared/types.ts: 공통 타입 정의
- InquiryList: Mock → API 연동, transform 함수 추가
- FAQList: Mock → API 연동, transform 함수 추가
- 상세 페이지: API 연동 (notices, events, inquiries)
- 각 types.ts: transformPost 함수 추가

fix: 고객센터 board_code 불일치 수정

- 공지사항: notice → notices
- 이벤트: event → events
- DB 시스템 게시판 코드와 일치하도록 수정

feat: 결재 문서 작성 파일 첨부 기능 구현

- UploadedFile 타입 추가 및 ProposalData/ExpenseReportData에 uploadedFiles 필드 추가
- uploadFiles() 함수 구현 (/api/v1/files/upload API 연동)
- createApproval/updateApproval에서 파일 업로드 후 저장 처리
- ProposalForm/ExpenseReportForm에 첨부파일 UI 개선
  - 기존 업로드 파일 표시 (파일 보기/삭제 기능)
  - 새 첨부 파일 목록 표시 및 삭제 기능
- DraftBox에서 결재자 부서/직책 정보 표시
- 문서 상세 모달에서 실제 API 데이터 표시 (목업 데이터 제거)
- 수정 모드 상신 시 PATCH 메서드 사용 (405 에러 수정)

feat: [mock-migration] Phase J-4 게시판 관리 Mock → API 연동 완료

- types.ts: BoardApiData, BoardExtraSettings API 타입 추가
- actions.ts: Server Actions 생성 (CRUD, 변환 함수)
- index.tsx: Mock 데이터 → API 호출로 전환
- [id]/page.tsx: 상세 페이지 API 연동
- [id]/edit/page.tsx: 수정 페이지 API 연동
- new/page.tsx: 등록 페이지 API 연동

주요 정책:
- /boards/tenant 엔드포인트로 테넌트 게시판만 조회
- 수정 시 board_code 전송 안함 (코드 변경 불가)
- extra_settings 내 target/target_name 저장

feat: 매입유형(purchase_type) 필드 저장 기능 추가

- actions.ts: API 응답/요청에 purchase_type 매핑 추가
- PurchaseDetail.tsx: 저장 시 purchaseType 포함하도록 수정

fix(salary): 직책/직급 매핑 수정 (사원관리 기준 통일)

- transformApiToFrontend: position → job_title_label (직책), rank → rank (직급)
- transformApiToDetail: 동일하게 수정
- 기존 잘못된 매핑: position_label(직위) → 직책, job_title_label(직책) → 직급

feat: [mock-migration] Phase M 잔여 Mock/TODO 제거 완료

- M-1: 매입 상세 모달 MOCK_ACCOUNTS, MOCK_VENDORS → API 연동
- M-2: 직원 관리 파일 업로드 API 연동 (uploadProfileImage)
- M-4: 결재 문서 생성 MOCK_EMPLOYEES 제거 → getEmployees API
- M-5: 결재함/기안함 console.log 제거 → 승인/반려 API 연동
- M-6: 구독 관리 TODO 제거 → requestDataExport, cancelSubscription
- M-7: 계정 정보 TODO 제거 → withdrawAccount, suspendTenant

docs: 휴가관리 사용현황 동기화 수정 작업 기록

- 2025-12-26 휴가 사용현황 동기화 수정 내용 추가
- fetchUsageData 호출 추가, 부여일수 계산 수정 문서화

feat: Phase G 생산관리/품질검사 Mock → API 연동 완료

G-1 작업지시관리:
- WorkOrderList: getWorkOrders, getWorkOrderStats API
- WorkOrderDetail: getWorkOrderById API
- WorkOrderCreate: createWorkOrder API
- SalesOrderSelectModal: getSalesOrdersForWorkOrder API

G-2 작업실적관리:
- WorkResultList: getWorkResults, getWorkResultStats API

G-3 생산대시보드:
- actions.ts 생성, getDashboardData API

G-4 작업자화면:
- actions.ts 생성
- getMyWorkOrders, completeWorkOrder API
- MaterialInputModal: getMaterialsForWorkOrder, registerMaterialInput API
- ProcessDetailSection: getProcessSteps, requestInspection API

G-5 품질검사:
- actions.ts 생성
- InspectionList: getInspections, getInspectionStats API
- InspectionDetail: getInspectionById, updateInspection API
- InspectionCreate: createInspection API

fix: [vacation] 휴가 사용현황 동기화 및 부여일수 계산 수정

- 승인 후 fetchUsageData() 호출 추가로 사용현황 즉시 반영
- baseVacation: 동적 totalDays → 고정 '15일' (기본 연차)
- grantedVacation: 하드코딩 '0일' → Math.max(0, totalDays-15) 계산
- useCallback dependencies에 fetchUsageData 추가

feat: Phase I Excel/PDF 다운로드 API 연동

- ReceivablesStatus: 채권현황 엑셀 다운로드 API 연동
- VendorLedger: 거래처원장 목록 엑셀, 상세 PDF 다운로드 API 연동
- DailyReport: 일일일보 엑셀 다운로드 API 연동
- Blob 다운로드 패턴 및 toast 알림 적용

feat: L-2 견적 관리 Mock → API 연동

## 변경사항
- SAMPLE_QUOTES Mock 데이터 제거
- Server Actions 생성 (CRUD + 특수 기능 14개)
- QuoteManagementClient 분리 (SSR/CSR 패턴)
- Quote 타입 및 변환 함수 정의

## 추가된 API 연동
- 목록/상세/등록/수정/삭제/일괄삭제
- 최종확정/확정취소/수주전환
- PDF 생성/이메일/카카오 발송
- 견적번호 미리보기/요약 통계

feat: 공정관리 페이지 및 컴포넌트 추가

- 공정관리 목록/상세/등록/수정 페이지 구현
- ProcessListClient, ProcessDetail, ProcessForm 컴포넌트 추가
- ProcessWorkLogPreviewModal, RuleModal 추가
- MobileCard 공통 컴포넌트 추가
- WorkLogModal.tsx 개선
- .gitignore 업데이트

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
(cherry picked from commit f0c0de2ecd)

chore: React 공통 컴포넌트 업데이트

- VacationManagement: API 연동 개선
- WorkOrders: 작업자 선택 모달 개선
- TypeScript 빌드 설정 업데이트

feat: I-8 휴가 정책 관리 API 연동

- actions.ts: 휴가 정책 CRUD Server Actions
- LeavePolicyManagement 컴포넌트 API 연동

feat: I-7 종합분석 API 연동

- actions.ts: 종합분석 조회 Server Actions
- ComprehensiveAnalysis 컴포넌트 API 연동

feat: I-6 일일 생산현황 API 연동

- actions.ts: 일일 리포트 조회 Server Actions
- DailyReport 컴포넌트 API 연동

feat: I-5 미수금 현황 API 연동

- actions.ts: 미수금 조회 Server Actions
- ReceivablesStatus 컴포넌트 API 연동

feat: I-4 거래통장 조회 API 연동

- actions.ts: 은행 거래내역 조회 Server Actions
- BankTransactionInquiry 컴포넌트 API 연동

feat: I-3 법인카드 사용내역 API 연동

- actions.ts: 카드 거래내역 조회 Server Actions
- CardTransactionInquiry 컴포넌트 API 연동

feat: I-2 거래처 원장 API 연동

- actions.ts: 거래처 원장 조회 Server Actions
- VendorLedger 컴포넌트 API 연동
- VendorLedgerDetail 상세 조회 연동

feat: H-3 출하 관리 API 연동

- actions.ts: Server Actions (CRUD, 상태 변경)
- ShipmentList: 출하 목록 API 연동
- ShipmentCreate: 출하 등록 API 연동
- ShipmentEdit: 출하 수정 API 연동
- ShipmentDetail: 출하 상세 API 연동

feat: G-2 작업실적 관리 API 연동

- types.ts API 타입 추가 (WorkResultApi, WorkResultStatsApi 등)
- transformApiToFrontend/transformFrontendToApi 변환 함수 추가
- actions.ts 서버 액션 생성 (8개 함수)
- index.ts 액션 exports 추가

Server Actions:
- getWorkResults: 목록 조회 (페이징, 필터링)
- getWorkResultStats: 통계 조회
- getWorkResultById: 상세 조회
- createWorkResult: 등록
- updateWorkResult: 수정
- deleteWorkResult: 삭제
- toggleInspection: 검사 상태 토글
- togglePackaging: 포장 상태 토글

fix: StockStatusList Hook 순서 오류 수정

- 조건부 return 전에 모든 Hooks(useCallback, useMemo) 선언
- React Rules of Hooks 준수

feat: H-2 재고현황 Mock → API 연동 완료

- StockStatusDetail.tsx: 상세 조회 API 연동
- StockStatusList.tsx: 목록 조회 API 연동 (이전 세션)
- actions.ts: 재고 현황 Server Actions 구현

feat: H-1 입고 관리 Mock → API 연동 완료

- ReceivingDetail.tsx: 상세 조회 및 입고처리 API 연동
- ReceivingProcessDialog.tsx: 폼 데이터 API 전달 구조로 변경
- InspectionCreate.tsx: 검사 대상 목록 API 조회 적용
- ReceivingList.tsx: 미사용 타입 import 정리

feat: G-1 작업지시 관리 API 연동

- actions.ts 서버 액션 11개 함수 구현
- types.ts API 타입 및 변환 함수 추가
- index.ts 액션 함수 export 추가

Server Actions:
- getWorkOrders (목록)
- getWorkOrderStats (통계)
- getWorkOrderById (상세)
- createWorkOrder (등록)
- updateWorkOrder (수정)
- deleteWorkOrder (삭제)
- updateWorkOrderStatus (상태변경)
- assignWorkOrder (담당자배정)
- toggleBendingField (벤딩토글)
- addWorkOrderIssue (이슈등록)
- resolveWorkOrderIssue (이슈해결)

feat: I-1 미지급비용 관리 React 연동

- Server Actions 패턴으로 API 연동 구현 (actions.ts)
- Mock 데이터 제거, props 기반 데이터 주입
- Server Component로 초기 데이터 로딩
- 삭제/지급일 변경 등 CRUD 액션 연동

feat: HR 모듈 API 연동 완료 및 휴가관리 버그 수정

## 휴가관리 (VacationManagement)
- 휴가 부여 API 연동: createLeaveGrant 호출 추가
- 휴가 신청 시 선택된 사원 userId 전달 (잔여휴가 오류 수정)
- LeaveType 타입 분리 (VacationType과 구분)
- VacationGrantDialog에 부여일(grantDate) 필드 추가

## 근태관리 (AttendanceManagement)
- actions.ts 추가: API 호출 함수 분리
- 타입 정의 확장 및 개선

## 기타 개선
- CardManagement, SalaryManagement: actions 개선
- DocumentCreate: 전자결재 actions 및 index 개선
- GoogleMap: 지도 컴포넌트 개선

feat: Phase E 인사관리 Mock → API 마이그레이션

- E-1 법인카드 관리 API 연동
  - actions.ts 생성 (getCards, createCard, updateCard, deleteCard, toggleCardStatus)
  - CardForm, 페이지 컴포넌트 API 연동
- E-2 급여 관리 API 연동
  - actions.ts 생성 (getSalaries, getSalary, updateSalaryStatus, bulkUpdateSalaryStatus)
  - 급여 목록 컴포넌트 API 연동
- 결재 시스템 actions.ts 추가 (ApprovalBox, DraftBox, ReferenceBox, DocumentCreate)
- DepositManagement actions.ts 페이지네이션 응답 구조 수정
- 부서 관리, 휴가 관리 actions.ts 개선
- API URL에 /api prefix 추가

회계 및 설정 모듈 리팩토링: actions 분리, 타입 정의 개선

feat: 휴가 부여현황 Mock 데이터 제거 및 API 연동

- getLeaveGrants, createLeaveGrant, deleteLeaveGrant API 함수 추가
- LeaveGrantType, LeaveGrantRecord, CreateLeaveGrantRequest 타입 추가
- generateGrantData Mock 함수 제거
- fetchGrantData로 실제 API 호출
- grantData 상태를 API 데이터로 갱신

feat: 휴가 사용현황 Mock 데이터 제거 및 API 연동

- getLeaveBalances() API 함수 추가
- LeaveBalanceRecord, GetLeaveBalancesParams 타입 정의
- generateUsageData() Mock 함수 제거
- fetchUsageData()로 실제 API 호출
- hireDate 날짜 포맷팅 예외 처리 추가

feat: C-4 부서 관리 Mock → API 연동

- actions.ts 생성 (getDepartmentTree, createDepartment, updateDepartment, deleteDepartment, deleteDepartmentsMany)
- index.tsx Mock 데이터 제거 및 API 연동
- 트리 구조 CRUD 완전 연동

⚠️ .env.local에 API_URL=https://api.sam.kr/api 설정 필요 (Server Actions용)

feat: C-3 휴가 관리 Mock → API 연동

- actions.ts 생성: getLeaves, createLeave, approveLeave, rejectLeave, cancelLeave 등
- index.tsx 수정: 신청현황 탭 Mock 데이터 → API 호출 전환
- 일괄 승인/반려 API 연동 (approveLeavesMany, rejectLeavesMany)
- 휴가 신청 다이얼로그 createLeave API 연동

feat: C-2 근태 관리 Mock → API 연동

- actions.ts 생성 (checkIn/checkOut/getTodayAttendance)
- GoogleMap.tsx userLocation 콜백 추가
- page.tsx Mock console.log 제거 + API 연동
- 처리중 상태 및 버튼 텍스트 추가

feat: C-1 직원 관리 Mock → API 연동

- actions.ts 생성 (CRUD + 통계 + 일괄삭제 Server Actions)
- utils.ts 생성 (API ↔ Frontend 데이터 변환)
- index.tsx Mock 데이터 제거, API 연동
- [id]/page.tsx 상세 페이지 API 연동
- [id]/edit/page.tsx 수정 페이지 API 연동
- new/page.tsx 등록 페이지 API 연동

API Endpoints:
- GET/POST /api/v1/employees
- GET/PATCH/DELETE /api/v1/employees/{id}
- POST /api/v1/employees/bulk-delete
- GET /api/v1/employees/stats

feat: Daum 우편번호 서비스 연동 및 악성채권 UI 개선

- useDaumPostcode 공통 훅 생성 (Daum Postcode API 연동)
- 우편번호 찾기 기능 적용: 악성채권, 거래처, 직원, 회사정보, 주문등록
- 악성채권 페이지 토글 순서 변경 (라벨 → 토글)
- 악성채권 토글 기능 수정 (매출/매입 → 등록/해제)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
(cherry picked from commit 41ef0bdd86)

feat: A-2 팝업 관리 Mock → API 연동

- 상세 조회 페이지: MOCK_POPUPS → getPopupById() API
- 수정 페이지: MOCK_POPUPS → getPopupById() API + 로딩 상태
- PopupForm: console.log → createPopup/updatePopup Server Actions
- 삭제 기능: deletePopup() API 연동 + 로딩 상태
- 데이터 변환 유틸리티 추가 (API ↔ Frontend)

feat: A-1 악성채권 관리 Mock → API 연동 완료

- 상세 페이지 서버 컴포넌트 전환 ([id]/page.tsx, [id]/edit/page.tsx)
- BadDebtDetail.tsx: CRUD API 연동 (createBadDebt, updateBadDebt, deleteBadDebt)
- actions.ts: 메모 API 추가 (addBadDebtMemo, deleteBadDebtMemo)

feat: 매입 관리 Mock → API 전환 및 세금계산서 토글 연동

- index.tsx: Mock 데이터 제거, API 데이터 로딩으로 전환
- actions.ts: getPurchases(), togglePurchaseTaxInvoice() 서버 액션 추가
- vendorOptions 빈 문자열 필터링 (Select.Item 에러 수정)

feat: 매출 상세 페이지 API 연동

- 목데이터(MOCK_VENDORS, fetchSalesDetail) 제거
- getSaleById, createSale, updateSale, deleteSale API 연동
- getClients로 거래처 목록 로드
- 상태 관리 개선 (clients, isLoading, isSaving)

fix: Mock 데이터를 실제 API 연동으로 복원

- 팝업 관리, 결제 내역, 구독 관리, 알림 설정 API 연동
- 입금/출금/거래처 관리 API 연동
- page.tsx를 서버 컴포넌트로 변환
- actions.ts 서버 액션 추가
2025-12-29 16:46:55 +09:00

21 KiB

Zod Validation 문제 해결 가이드

문제 1: 영어 에러 메시지 표시

증상

  • 필수 필드 미입력 시 영어 에러 메시지 표시
  • 예: "Invalid input: expected string, received undefined"
  • 예: "Invalid option: expected one of 'ASSEMBLY'|'BENDING'|'PURCHASED'"

원인

  • z.string() 또는 z.enum()undefined 값이 들어오면 타입 체크가 먼저 실행됨
  • 커스텀 한글 에러 메시지 전에 Zod 내부 타입 에러가 먼저 발생

해결 방법: z.preprocess() 패턴 사용

올바른 방법 (String 필드)

// 상품명, 품목명 등
const fieldSchema = z.preprocess(
  (val) => val === undefined || val === null ? "" : val,
  z.string().min(1, '필드명을 입력해주세요').max(200, '최대 200자')
);

올바른 방법 (Enum 필드)

// 부품 유형 등
partType: z.preprocess(
  (val) => val === undefined || val === null ? "" : val,
  z.string()
    .min(1, '부품 유형을 선택해주세요')
    .refine(
      (val) => ['ASSEMBLY', 'BENDING', 'PURCHASED'].includes(val),
      { message: '부품 유형을 선택해주세요' }
    )
)

잘못된 방법

// z.enum()은 undefined 처리 못 함
partType: z.enum(['ASSEMBLY', 'BENDING', 'PURCHASED'], {
  errorMap: () => ({ message: '부품 유형을 선택해주세요' }),
})

// .default()는 .min() 전에 사용 불가
z.string().default("").min(1, 'message') // Syntax Error!

문제 2: 불필요한 필드 검증으로 다중 에러 발생

증상

  • 특정 품목 유형(FG, PT 등)에 없는 필드가 검증되어 에러 발생
  • 예: 제품(FG)에 가격 필드 없는데 가격 필드 검증 에러 7개 발생

원인

  • itemMasterBaseSchema를 모든 품목 유형이 공유
  • 특정 유형에 없는 필드도 스키마에 포함되어 검증됨

해결 방법: .omit() 사용

올바른 방법

// 제품(FG) - 가격 정보 제거
const productSchemaBase = itemMasterBaseSchema
  .omit({
    purchasePrice: true,
    salesPrice: true,
    processingCost: true,
    laborCost: true,
    installCost: true,
  })
  .merge(productFieldsSchema);

문제 3: 공통 필수 필드가 특정 유형에서 불필요

증상

  • itemMasterBaseSchemaitemName이 필수인데, 부품(PT)은 category1을 사용
  • 부품 유형만 선택 안 해도 "품목명을 입력해주세요" 에러 발생

원인

  • itemMasterBaseSchema에서 itemName: itemNameSchema (필수)
  • 부품(PT)은 itemName 사용 안 하고 category1 사용

해결 방법: .extend() 로 필드 오버라이드

올바른 방법

// 부품(PT) - itemName을 선택 사항으로 변경
const partSchemaBase = itemMasterBaseSchema
  .extend({
    itemName: z.string().max(200).optional(), // 필수 → 선택
  })
  .merge(partFieldsSchema);

문제 4: 단계별 검증 (조건부 필드 검증)

증상

  • 사용자 화면에 안 보이는 필드 에러가 알럿 카드에 표시됨
  • 예: 부품 유형 선택 전인데 "품목명", "설치 유형" 등 에러 동시 발생

원인

  • Zod의 .refine()은 모든 refinement를 순차 실행
  • 조건 체크 없이 모든 필드 검증 시도

해결 방법: .superRefine() + early return

올바른 방법

export const partSchema = partSchemaBase
  .superRefine((data, ctx) => {
    // 1단계: 부품 유형 필수 체크
    if (!data.partType || data.partType === '') {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: '부품 유형을 선택해주세요',
        path: ['partType'],
      });
      return; // 여기서 검증 중단 - 더 이상 체크 안 함
    }

    // 2단계: 부품 유형이 있을 때만 품목명 체크
    if (!data.category1) {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: '품목명을 선택해주세요',
        path: ['category1'],
      });
    }

    // 3단계: 특정 부품 유형에만 해당하는 필드
    if (data.partType === 'ASSEMBLY') {
      if (!data.installationType) {
        ctx.addIssue({
          code: z.ZodIssueCode.custom,
          message: '설치 유형을 선택해주세요',
          path: ['installationType'],
        });
      }
      // ... 다른 필수 필드들
    }
  });

잘못된 방법

// .refine()은 모든 체크를 실행함
.refine((data) => !!data.partType, { ... })
.refine((data) => !!data.category1, { ... }) // partType 없어도 실행됨!
.refine((data) => {
  if (data.partType === 'ASSEMBLY') {
    return !!data.installationType; // partType 없어도 실행됨!
  }
  return true;
}, { ... })

문제 5: .omit() + .extend() + .superRefine() 조합 시 refinement 유실

증상

  • validation.ts에서 superRefine() 작성했는데 적용 안 됨
  • 여전히 단계별 검증이 작동하지 않음
  • Console.log도 나타나지 않아 superRefine 자체가 실행되지 않음

원인

CRITICAL: .omit()은 refinement를 제거합니다!

// ❌ 잘못된 패턴 - refinement가 유실됨
const partSchemaForForm = partSchemaBase
  .omit({ createdAt: true, updatedAt: true })
  .superRefine((data, ctx) => { /* 이 부분이 실행 안 됨! */ });

// discriminatedUnion에서 사용
partSchemaForForm.extend({ itemType: z.literal('PT') })
// → Error: "Object schemas containing refinements cannot be extended"

추가 문제: .extend()도 refinement가 있는 스키마에 사용 불가

해결 방법: .omit().merge().superRefine() 순서

올바른 방법

// 1. omit으로 불필요한 필드 제거
// 2. merge로 itemType 추가
// 3. superRefine을 마지막에 적용 (핵심!)
const partSchemaForForm = partSchemaBase
  .omit({ createdAt: true, updatedAt: true })
  .merge(z.object({ itemType: z.literal('PT') }))
  .superRefine((data, ctx) => {
    // 이제 이 부분이 실행됨!
    if (!data.partType || data.partType === '') {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: '부품 유형을 선택해주세요',
        path: ['partType'],
      });
      return;
    }

    if (!data.category1 || data.category1 === '') {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: '품목명을 선택해주세요',
        path: ['category1'],
      });
    }
  });

// discriminatedUnion에서는 그대로 사용
export const createItemFormSchema = z.discriminatedUnion('itemType', [
  productSchema.omit({ createdAt: true, updatedAt: true }).extend({ itemType: z.literal('FG') }),
  partSchemaForForm, // itemType이 이미 merge되어 있음
  // ...
]);

잘못된 방법들

// 방법 1: superRefine을 merge 전에 적용
const wrong1 = partSchemaBase
  .omit({ ... })
  .superRefine((data, ctx) => { /* 실행 안 됨 */ })
  .merge(z.object({ itemType: z.literal('PT') })); // merge가 refinement 덮어씀

// 방법 2: extend 사용
const wrong2 = partSchemaBase
  .omit({ ... })
  .superRefine((data, ctx) => { /* ... */ })
  .extend({ itemType: z.literal('PT') }); // Error!

// 방법 3: discriminatedUnion에서 다시 extend
partSchemaForForm.extend({ itemType: z.literal('PT') }) // Error!

핵심 원칙

  1. .omit()은 항상 refinement를 제거함 - 순서 상관없음
  2. refinement는 항상 마지막에 적용 - .merge() 이후
  3. .extend()는 refinement 있는 스키마에 사용 불가 - .merge() 사용
  4. discriminatedUnion에서는 완성된 스키마 사용 - 추가 merge/extend 없이

문제 6: Form과 Validation의 필드명 불일치

증상

  • superRefine에서 early return을 사용했는데도 하위 필드 에러가 계속 나타남
  • Console.log에서 superRefine이 실행되지만, 체크하는 필드가 항상 undefined
  • 예: 절곡(BENDING) 부품에서 "종류" 선택 안 해도 "재질", "폭 합계", "모양&길이" 에러 발생

원인

Form 컴포넌트와 Validation 스키마에서 다른 필드명을 사용

// ❌ ItemForm.tsx에서
setValue('category3', selected.code); // category3에 저장

// ❌ validation.ts에서
if (!data.category2 || data.category2 === '') { // category2 체크
  // category3에 값이 있는데 category2를 체크하니까 항상 undefined!
}

해결 방법: 필드명 통일

올바른 방법

// ItemForm.tsx - 필드명을 validation과 동일하게
setValue('category2', selected.code); // category3 → category2로 수정
clearErrors('category2');

// validation.ts - 동일한 필드명 사용
if (!data.category2 || data.category2 === '') {
  ctx.addIssue({
    code: z.ZodIssueCode.custom,
    message: '종류를 선택해주세요',
    path: ['category2'], // 필드명 일치
  });
  return;
}

디버깅 방법

  1. Form에서 setValue 호출 확인:

    • 어떤 필드명으로 값을 설정하는지 확인
    • 예: setValue('category2', value) 또는 setValue('category3', value)
  2. Validation에서 체크하는 필드명 확인:

    • superRefine 내부에서 data.xxx 형태로 체크하는 필드명 확인
    • Console.log로 실제 값 확인: console.log('category2:', data.category2, 'category3:', data.category3)
  3. 필드명 불일치 찾기:

    # Form 컴포넌트에서 setValue 사용 찾기
    grep -n "setValue('category" src/components/items/ItemForm.tsx
    
    # Validation에서 category 필드 체크 찾기
    grep -n "data.category" src/lib/utils/validation.ts
    

예방 방법

  • Type 정의 파일 활용: /src/types/item.ts에서 필드명을 명확히 정의
  • 일관된 네이밍: category1 (품목명), category2 (종류), category3 (하위 분류) 등 명확한 규칙
  • 코드 리뷰: Form과 Validation 수정 시 필드명 일치 여부 확인

문제 7: Form에서 다른 곳에서 필드 값 자동 설정

증상

  • Validation에서 early return을 사용했는데도 하위 필드 에러 발생
  • Console.log에서 필드 값이 예상과 다르게 이미 설정되어 있음
  • 예: BENDING 부품에서 "종류" 선택 안 했는데 category2: 'R'로 이미 설정됨

원인

Form 컴포넌트의 다른 이벤트 핸들러에서 동일한 필드를 자동 설정

// ❌ 품목명 선택 시 category2 자동 설정 (모든 부품 유형에서)
onValueChange={(val) => {
  setSelectedCategory1(val);
  setValue('category1', val);
  const cat = PART_TYPE_CATEGORIES[selectedPartType]?.categories.find(c => c.value === val);
  if (cat) setValue('category2', cat.code); // BENDING에서도 실행됨!
}}

// validation.ts에서
if (!data.category2 || data.category2 === '') {
  // category2가 이미 'R'로 설정되어 있어서 이 체크를 통과
  return;
}
// 그래서 material 체크로 진행 → 에러 발생!

해결 방법: 조건부 자동 설정

올바른 방법

// ItemForm.tsx - 특정 부품 유형에서만 자동 설정
onValueChange={(val) => {
  setSelectedCategory1(val);
  setValue('category1', val);
  const cat = PART_TYPE_CATEGORIES[selectedPartType]?.categories.find(c => c.value === val);

  // BENDING이 아닐 때만 category2 자동 설정 (BENDING은 별도로 "종류" 선택)
  if (cat && selectedPartType !== 'BENDING') {
    setValue('category2', cat.code);
  }
}}

// BENDING 부품의 "종류" 선택에서만 category2 설정
onValueChange={(value) => {
  setSelectedBendingItemType(value);
  const selected = PART_ITEM_NAMES[selectedCategory1].find(item => item.label === value);
  if (selected) {
    setValue('category2', selected.code); // 여기서만 설정
    clearErrors('category2');
  }
}}

디버깅 방법

  1. Console.log로 필드 값 확인:

    .superRefine((data, ctx) => {
      console.log('🔍 검증 시작:', {
        category2: data.category2,
        category2Type: typeof data.category2,
      });
    })
    
  2. Form 컴포넌트에서 setValue 호출 검색:

    # 동일한 필드를 여러 곳에서 설정하는지 확인
    grep -n "setValue('category2'" src/components/items/ItemForm.tsx
    
  3. 예상치 못한 값 발견 시:

    • 해당 필드를 설정하는 모든 위치 확인
    • 각 위치에서 조건부 설정이 필요한지 판단
    • 부품 유형에 따라 다른 로직 적용

예방 방법

  • 명확한 필드 책임 분리: 각 필드는 한 곳에서만 설정되도록
  • 조건부 설정 명시: if (partType === 'SPECIFIC') 조건 명확히
  • Console.log 디버깅: 문제 발생 시 실제 값 확인 습관화
  • 필드 초기화: 부품 유형 변경 시 관련 필드 모두 초기화

체크리스트

필수 필드 추가 시

  • z.preprocess() 패턴으로 undefined → "" 변환
  • .min(1, '한글 메시지') 사용
  • enum 타입은 .refine() + array.includes() 패턴

품목 유형별 스키마 작성 시

  • 해당 유형에 없는 필드는 .omit() 제거
  • 공통 필수 필드가 불필요하면 .extend() 오버라이드
  • refinement 작성 후 createItemFormSchema에서 사용

조건부 검증 작성 시

  • .superRefine() 사용
  • 필수 선행 조건 체크 후 return으로 중단
  • 특정 값일 때만 검증하는 필드는 if (data.field === 'VALUE') 체크

실전 예제: 부품(PT) 스키마 완성본

// 1. 부품 전용 필드 정의
const partFieldsSchema = z.object({
  partType: z.preprocess(
    (val) => val === undefined || val === null ? "" : val,
    z.string()
      .min(1, '부품 유형을 선택해주세요')
      .refine(
        (val) => ['ASSEMBLY', 'BENDING', 'PURCHASED'].includes(val),
        { message: '부품 유형을 선택해주세요' }
      )
  ),
  // ... 기타 선택 필드들
});

// 2. Base 스키마 - itemName 제거
const partSchemaBase = itemMasterBaseSchema
  .extend({
    itemName: z.string().max(200).optional(),
  })
  .merge(partFieldsSchema);

// 3. Refinement 스키마 - 단계별 검증
export const partSchema = partSchemaBase
  .superRefine((data, ctx) => {
    // 1단계: 부품 유형 필수
    if (!data.partType || data.partType === '') {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: '부품 유형을 선택해주세요',
        path: ['partType'],
      });
      return; // 검증 중단
    }

    // 2단계: 품목명 필수
    if (!data.category1) {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: '품목명을 선택해주세요',
        path: ['category1'],
      });
    }

    // 3단계: 조립 부품 전용
    if (data.partType === 'ASSEMBLY') {
      if (!data.installationType) {
        ctx.addIssue({
          code: z.ZodIssueCode.custom,
          message: '설치 유형을 선택해주세요',
          path: ['installationType'],
        });
      }
      // ... 기타 필수 필드
    }

    // 절곡품 전용
    if (data.partType === 'BENDING') {
      // ...
    }

    // 구매 부품 전용
    if (data.partType === 'PURCHASED') {
      // ...
    }
  });

// 4. 폼 스키마 - .omit() + .merge() + .superRefine() 패턴 적용
const partSchemaForForm = partSchemaBase
  .omit({ createdAt: true, updatedAt: true })
  .merge(z.object({ itemType: z.literal('PT') }))
  .superRefine((data, ctx) => {
    // refinement 로직 (위와 동일)
  });

export const createItemFormSchema = z.discriminatedUnion('itemType', [
  productSchema.omit({ createdAt: true, updatedAt: true }).extend({ itemType: z.literal('FG') }),
  partSchemaForForm, // refinement가 마지막에 적용된 완성 스키마
  // ...
]);

디버깅 팁

영어 에러 메시지가 나올 때

  1. 해당 필드가 z.preprocess() 사용하는지 확인
  2. undefined → "" 변환 로직 있는지 확인
  3. enum 타입이면 .refine() 패턴으로 변경

불필요한 필드 에러가 나올 때

  1. 해당 품목 유형 스키마에서 .omit() 사용했는지 확인
  2. itemMasterBaseSchema의 필수 필드를 .extend() 오버라이드 했는지 확인

단계별 검증이 안 될 때

  1. .superRefine() 사용했는지 확인
  2. 선행 조건 체크 후 return 있는지 확인
  3. createItemFormSchema에서 refinement 포함 스키마 사용하는지 확인
  4. CRITICAL: .superRefine().merge() 이후에 적용되었는지 확인
  5. Console.log 추가해서 superRefine이 실행되는지 확인
  6. .omit() 사용했다면 반드시 refinement를 마지막에 다시 적용
  7. CRITICAL: Form과 Validation의 필드명 일치 확인!
    • Form에서 setValue('category3', value)인데 validation에서 data.category2 체크하면 안 됨
    • 두 곳의 필드명이 정확히 일치해야 함
  8. CRITICAL: Console.log로 실제 필드 값 확인 - 예상과 다른 값이 이미 설정되어 있는지
    • 다른 이벤트 핸들러에서 동일한 필드를 자동 설정하고 있는지 확인
    • grep -n "setValue('필드명'" src/components/items/ItemForm.tsx로 모든 설정 위치 확인

문제 8: 필드가 자동으로 채워져서 필수 검증이 작동하지 않음

증상

  • 부자재/원자재/소모품(SM/RM/CS) 선택 후 바로 저장 시 단위(unit) 필수 에러가 발생하지 않음
  • 에러 카드에 "품목명, 규격" 2개만 표시되고 "단위"는 누락됨
  • Zod 스키마에서는 unit을 필수로 정의했는데 검증이 안 됨

원인

  • ItemForm.tsx의 handleItemTypeChange 함수에서 모든 품목 유형에 대해 setValue('unit', 'EA') 실행
  • 부자재/원자재/소모품을 선택해도 unit 필드에 자동으로 'EA'가 설정됨
  • Zod validation에서 unit 필드가 비어있지 않다고 판단하여 필수 검증 통과

진단 방법

# ItemForm에서 해당 필드를 설정하는 모든 위치 찾기
grep -n "setValue('unit'" src/components/items/ItemForm.tsx

해결 방법 1: 조건부 초기화

올바른 방법

// ItemForm.tsx - handleItemTypeChange 함수
const handleItemTypeChange = (type: ItemType) => {
  setSelectedItemType(type);
  setValue('itemType', type);

  // react-hook-form 필드 초기화
  setValue('itemCode', '');
  setValue('itemName', '');
  // SM/RM/CS는 unit 필수이므로 빈 문자열로 초기화, FG/PT는 'EA'
  setValue('unit', (type === 'SM' || type === 'RM' || type === 'CS') ? '' : 'EA');
  setValue('specification', '');
  // ...
};

잘못된 방법

// 모든 품목 유형에 동일한 기본값 설정
setValue('unit', 'EA'); // ← SM/RM/CS도 'EA'가 들어가서 필수 검증 안 됨!

해결 방법 2: UI 에러 표시 추가

필드에 에러가 있을 때 빨간 테두리와 메시지를 표시해야 사용자가 알 수 있음

올바른 방법

{/* 단위 필드 */}
<Select
  value={selectedUnit}
  onValueChange={(value) => {
    setSelectedUnit(value);
    setValue('unit', value);
  }}
>
  <SelectTrigger id="unit" className={errors.unit ? 'border-red-500' : ''}>
    <SelectValue placeholder="단위를 선택하세요" />
  </SelectTrigger>
  <SelectContent>
    <SelectItem value="EA">EA ()</SelectItem>
    {/* ... */}
  </SelectContent>
</Select>
{errors.unit && (
  <p className="text-xs text-red-500 mt-1">
    {errors.unit.message}
  </p>
)}

해결 방법 3: z.object()로 완전히 새로 정의

.extend().omit()이 제대로 작동하지 않을 때는 z.object()로 완전히 새로 정의

올바른 방법

// 원자재/부자재 Base 스키마
const materialSchemaBase = z.object({
  // 공통 필수 필드
  itemCode: z.string().optional(),
  itemName: itemNameSchema,
  itemType: itemTypeSchema,
  specification: materialSpecificationSchema, // 필수!
  unit: materialUnitSchema, // 필수!
  isActive: z.boolean().default(true),

  // ... 나머지 모든 필드 명시적으로 정의

  // 원자재/부자재 전용 필드
  material: z.string().max(100).optional(),
  length: z.string().max(50).optional(),
});

잘못된 방법

// .extend()만으로 오버라이드 시도 (작동하지 않을 수 있음)
const materialSchemaBase = itemMasterBaseSchema
  .merge(materialFieldsSchema)
  .extend({
    specification: materialSpecificationSchema, // optional이 그대로 남을 수 있음
    unit: materialUnitSchema, // optional이 그대로 남을 수 있음
  });

교훈

  1. Form의 자동 설정 확인: 필수 검증이 안 되면 Form에서 해당 필드를 자동으로 채우고 있는지 확인
  2. 조건부 초기화: 품목 유형마다 다른 기본값이 필요하면 조건부로 설정
  3. UI 피드백: Validation 에러를 사용자가 볼 수 있도록 필드에 직접 표시
  4. 명시적 정의: .extend()가 작동하지 않으면 z.object()로 완전히 새로 정의

작성일

2025-11-15

최종 수정일

2025-11-15

작성자

Claude Code

관련 파일

  • /src/lib/utils/validation.ts
  • /src/components/items/ItemForm.tsx
  • /src/types/item.ts