배경
#248과 같은 측정에서 나온 대량 보강분. 프론트가 "무엇을 보내고 무엇이 돌아오는가"를 문서에서 알 수 없는 상태다.
- input 필드 16% (42/259)
- 출력 type 필드 25% (159/648)
- input 타입 선언 68% (42/62), 출력 type 선언 73% (82/113)
문제의 성격: 정책 부재가 아니라 관행 불균질
"어떻게 쓰는지"는 이미 레포에 있다 — 주문 체크아웃 SDL(order-checkout.graphql)은 필드마다 의미는 물론 정책 결정 근거까지 적혀 있다. 문제는 그게 도메인별로 균질하게 적용되지 않은 것이다.
| 파일 |
필드 설명 커버리지 |
| user-search / user-notification |
100% |
| user-profile |
81% |
| product-home |
64% |
| user-order |
25% |
| seller-store |
16% (13/81) |
| seller-product |
14% (25/178) |
| seller-conversation |
12% (3/25) |
| seller-content |
11% (9/84) |
| seller-order |
4% (3/76) |
| seller-common |
0% (0/2) |
최근 figma 정합화로 손댄 구매자 화면은 촘촘하고, seller 계열은 사실상 무설명이다.
진행 방식
한 PR로 몰면 리뷰가 불가능하므로 도메인 단위로 쪼갠다. 권장 순서(효과 큰 순):
수행 조건
- 필드 이름으로 자명한 것(
id, createdAt)까지 억지로 채우지 않는다 — 비자명한 것(단위, 형식, null 의미, 정렬 기준, 계약상 상한)에 집중
- 커서·정렬·필터 관련 필드는 반드시 적는다 (불투명 토큰 규칙, 정렬 변경 시 무효 등)
.graphql 수정 후 yarn graphql:codegen
참고
선행 권장: #248(소형, enum·스칼라 인자). 완료 후 커버리지 게이트 임계치를 올리는 근거가 된다.
배경
#248과 같은 측정에서 나온 대량 보강분. 프론트가 "무엇을 보내고 무엇이 돌아오는가"를 문서에서 알 수 없는 상태다.
문제의 성격: 정책 부재가 아니라 관행 불균질
"어떻게 쓰는지"는 이미 레포에 있다 — 주문 체크아웃 SDL(
order-checkout.graphql)은 필드마다 의미는 물론 정책 결정 근거까지 적혀 있다. 문제는 그게 도메인별로 균질하게 적용되지 않은 것이다.최근 figma 정합화로 손댄 구매자 화면은 촘촘하고, seller 계열은 사실상 무설명이다.
진행 방식
한 PR로 몰면 리뷰가 불가능하므로 도메인 단위로 쪼갠다. 권장 순서(효과 큰 순):
수행 조건
id,createdAt)까지 억지로 채우지 않는다 — 비자명한 것(단위, 형식, null 의미, 정렬 기준, 계약상 상한)에 집중.graphql수정 후yarn graphql:codegen참고
선행 권장: #248(소형, enum·스칼라 인자). 완료 후 커버리지 게이트 임계치를 올리는 근거가 된다.