pfs›문서›2026-06-10 세션 — 견적 타입 순서: field_type 연동 진단 + 페이즈 A 지시문 + 두 경로 통합 보완
4.2 KB · 수정 2026-06-10 00:37
목차

2026-06-10 세션 — 견적 타입 순서: field_type 연동 진단 + 페이즈 A 지시문 + 두 경로 통합 보완

논의·대안

견적(estimate) 후속 보완 10건 중 1번(타입 rename + 타입 순서)의 스키마 구축 방향을 확정하는 세션. 운영·테스트 RDS를 SSM 경유로 재실측해 견적 도메인의 타입(type)·마진(margin)·단가(price) 관련 구조를 다시 파악했다.

초기 진단(이전 세션)은 "타입은 estimate_detail.type_name 문자열뿐, field_type 테이블과 FK 없음, display_order로 순서 완결, 스키마 변경 불필요"였다. 그러나 이번 재실측에서 그 진단이 일부 무효임이 드러났다: - estimate_detail에 field_type varchar(5) 컬럼이 실재한다(K/F div). 값이 코드(10/20/30)와 글자(K/F)로 혼재 저장돼 정합성이 깨져 있다. - common_code 그룹 FIELD_TYPE이 10=K·20=F·30=OT div 사전을 제공한다(display_order 보유). - field_type 테이블은 현장(field_no)별 타입 마스터로 PK type_no를 갖지만 타입 표시순서 컬럼이 없다. - estimate.field_no로 견적이 현장에 묶이고, field_type도 field_no별로 정의된다. 그러나 estimate_detail→field_type 확정 FK는 없다.

대안 검토: (가) estimate_detail에 type_order 컬럼 신설 vs (나) estimate_type 신규 테이블 vs field_type 테이블에 display_order 신설 + 견적 사용 타입을 field_type에 시드. 페페가 마지막 방향을 선택했다 — field_type을 견적과 연관지어 그쪽에 display_order를 만들고 나머지 프로세스를 거기로 연결.

데이터 정책 3건도 페페가 추천안으로 확정: div 정규화(K→10, F→20, 30 유지, 빈값→10 기본), 조합 단위는 (field_no, type_name, 정규화div)당 1행, display_order 초기값은 견적 등장 순서 보존(현장 내 최소 display_order 기준).

세션 후반, 페페가 핵심 보완을 제시했다: 지금까지 field type list 페이지와 견적서 화면이 타입을 별개로 생성해 왔는데, 앞으로 어느 쪽에서 만들어도 field_type 테이블을 단일 출처로 공유해야 한다. 코드 실측 결과 두 경로가 완전히 단절돼 있음을 확인했다(list 페이지는 field_type INSERT, 견적서는 estimate_detail.type_name 문자열만 + type-suggest API로 견적 distinct 로드).

결정

산출물·커밋

다음

  1. 다음 대화방에서 미결 결정 2건(공유 범위·upsert 시점) 확정.
  2. 페이즈 A 지시문을 "순서 컬럼 + 시드 + 견적서 타입 로드/upsert 경로 통합" 통합본으로 갱신.
  3. 코디에 전달 → 테스트 실행·검증(still_missing=0, 멱등 2회, 순서 연속성) → 운영 동일 적용 별도 승인.
  4. 페이즈 B(UI 10건 + 7번 마감재 숨김) 지시문 작성.

관계