버튼 라벨 ≠ 파라미터명, 이관 단계에서 끝내는 통일 규칙
버튼 라벨 ≠ 파라미터명, 이관 단계에서 끝내는 통일 규칙 서론 이름이 다르면 의도가 흐려지고, 이관에서는 시간이 새어 나간다. UI 라벨–플로우–API–정책을 한 규칙으로 묶어 전달 개발 이관 단계에서 가장 많이 발생하는 문제가 버튼 라벨과 API 파라미터명이 다른 경우 입니다. 이 글은 이관 시점에 네이밍 통일 을 확정하고, 문서 간 크로스 링크 로 추적성을 확보하는 방법을 정리했습니다. 아래 체크리스트를 적용하면 QA 지연을 줄이고 재작업을 예방할 수 있습니다. 📚 목차 왜 통일 규칙이 필요한가 네이밍 원칙: 라벨·파라미터·응답·코드 식별자 규칙: 화면ID·요소ID·이벤트 매핑 테이블 작성법(예시 포함) 개발 이관 패키지 구성(8종) 정렬·링크 기준: 화면→플로우→API→정책 샘플 JSON·에러 코드 표준 사례: 라벨≠파라미터 불일치 해결 이관 체크리스트 결론 FAQ 본론 1) 왜 통일 규칙이 필요한가 명칭 불일치가 버그와 QA 지연으로 확대 동일 개념을 다른 이름으로 부르면 테스트 케이스 설계와 로그 분석이 어려워집니다. 코드 리뷰에서 의미 해석 시간이 증가합니다. CS 문구와 사용자 가이드에도 혼선이 생깁니다. 2) 네이밍 원칙: 라벨·파라미터·응답·코드 표준 용어를 중심으로 라벨과 필드를 일치 표준 용어 : 용어 사전에 한글 명칭/영문 키/설명을 등록...