[QA] QA-13 결합도·계층 경계·순환 의존·중복 로직 점검

[yslee4601]

우선순위 P2 · 출시 전 전수 QA 13/13 · 상위 이슈 #252

배경

발표 후에도 이어질 코드다. 지금 계층이 새면 2차 React 전환에서 그대로 터진다.
graphify-out/ 에 이미 지식그래프가 있으니 이걸 근거로 본다.

볼 것

1. 계층 경계

   • Controller → Service → Mapper 방향이 지켜지는가. Controller가 Mapper를 직접 부르는 곳
   • View Controller가 REST Controller를 부르는 곳 (#84에서 정리한 원칙: 같은 Service를 공유한다)
   • DTO가 도메인 경계를 넘어 새는 곳

2. 순환 의존 — 패키지 간 사이클. graphify query 로 확인

3. 중복 로직 — 같은 계산·판정이 두 군데 이상 있는 곳. 특히 QA-12의 "엔진 단일성"과 짝

4. 프런트 구조

   • layout/default.html:47-63 의 screenId 조건부 스크립트 로딩 — 화면 추가 시 여기를 안 고치면 조용히 안 붙는다
   • 템플릿 인라인 <script> vs static/js 분리 기준이 없다. contract/detail.html 은 300줄 넘는 인라인 스크립트를 갖고 있다 (#246에서 이것 때문에 API 호출부를 놓칠 뻔했다)
   • api-client.js 를 안 거치고 fetch 를 직접 쓰는 곳
   • CSS 토큰을 안 쓰고 값을 박은 곳 (QA-04와 짝)

5. 테스트 편중 — 도메인별 테스트 수가 심하게 기울어 있다

   두꺼움	얇음
   validation 44 · base 20 · reconciliation 14 · cap 13 · journal 12	transaction 3 · schedule 4 · policy 4 · arbitrage 4 · contract 7

   transaction 이 가장 얇은데 FUN-065·031·033을 지고 있다. 위험도 대비 테스트가 가장 부족한 지점

6. 환경 의존 테스트 — 개행·경로·로케일·시간대에 따라 결과가 갈리는 테스트 ([QA] 출시 전 전수 검증 트래커 — 발표(8/24) 전 배포 직전 QA 13종 #252 참조: CRLF 이슈)

7. 죽은 코드 — 안 쓰이는 메시지 키·CSS 클래스·JS 함수·엔드포인트

통과 기준

• 계층 위반 목록이 있고, 각각 고칠지 남길지 판단이 붙었다
• 순환 의존 0건
• 같은 업무 판정이 두 곳에 있는 사례가 0건
• transaction·schedule 도메인 테스트 보강 계획이 후속 이슈로 있다
• 환경 의존 테스트가 0건 (어느 OS에서 받아도 빌드가 초록)
• 죽은 코드 목록이 있다

관련

#138 (업무 화면 공통 UI 컴포넌트 점진 통합)

---

공통 규칙 (모든 QA 이슈에 적용)

• 근거 없는 수정 금지 — 00_인덱스/근거대장.md를 먼저 읽고, 모든 수정 제안에 근거 ID(REG-xx / SRC-xx)를 붙인다. 못 붙이면 "근거 없음 — 확인 필요"로 남긴다.
• 발견을 3분류한다 — ① 문서가 틀림 ② 구현이 틀림 ③ 아직 구현 안 됨(문서 유효). ③을 ①로 오인해 지우면 설계 의도가 사라진다.
• 이 이슈에서 직접 고치는 것은 "명백한 오기·1줄짜리"까지. 판단이 필요한 것은 후속 이슈로 분리하고 여기에 링크한다.
• PR 하나가 커지지 않게 — 검사 결과를 먼저 이 이슈에 표로 남기고, 수정은 그다음에 올린다.

[yslee4601]

QA-13 결과 — 결합도·계층·순환·중복 (develop f12a2ddf, 정적 분석)

한 줄 요약: Controller→Mapper 0건·#84 원칙 준수·CSS 토큰·환경의존 테스트는 깨끗. 반면 패키지 사이클 7건(SCC 2덩어리) 과 한도 판정 2곳 구현이 남아 있고, 이슈 본문의 "transaction 테스트 3개"·"detail.html 300줄 인라인"은 낡은 서술이다.

통과 기준 대조

• 계층 위반 목록+판단 — Controller→Mapper 0건, View→REST 0건, DTO 누수 4건(판단 포함)
• 순환 의존 0건 — 7건: auth↔audit(+common), policy↔schedule, schedule↔contract(핵심), validation↔reconciliation, cap/arbitrage→validation 계열. 포트(validation.batch.contract) DIP는 정상이고, ValidationRunScheduleService.java:6-8·ExceptionCaseMapper.java:3·ResolvedCommissionPolicy.java:5·ShellAdvice.java:3 네 곳만 끊으면 schedule↔contract 빼고 전부 풀린다
• 업무 판정 두 곳 0건 — 한도 판정 사다리가 CapCalculatorImpl.java:223과 CapValidatorImpl.java:30 두 곳. 특히 limit=0일 때 사용률이 저장경로 0% vs 지급 사전검증 100%로 갈린다(MoneyUtil.java:81 vs CapValidatorImpl.java:38) — 규정 의도 확인 필요
• transaction·schedule 보강 후속 이슈 — 본문 표는 파일 수 착시(transaction 실제 95케이스, [QA] 출시 전 전수 검증 트래커 — 발표(8/24) 전 배포 직전 QA 13종 #252 코멘트대로). 실제 최약체는 arbitrage 10케이스(FUN-063 태그 0건). 후속 이슈 초안은 보고서 §6
• 환경 의존 0건 — CRLF 정규화·CSV 리터럴 \r\n·로케일/시간대/경로 의존 없음
• 죽은 코드 목록 — FgcErrorCode 4상수+메시지 키 4개(QA-07 승계, 재확증). role.*는 동적 조립이라 살아 있음

3분류

① 문서: 본문 "300줄 인라인"(현재 0건)·테스트 표(파일 수 기준) — 서술 갱신
② 구현(경미): 0-한도 사용률 분기 1건
③ 유효 부채: 사이클 7건, 판정 2곳, SCHE_002·AUTH_002 미연결, arbitrage 케이스 부족

시연 영향 없음 (전부 구조 발견, 런타임 변화 없음).
상세: qa-findings/qa-13-report.md (React 2차 위험도 표 포함)