모순 없는 데이터·정책: 한 번에 정리하는 7단계
모순 없는 데이터·정책: 한 번에 정리하는 7단계
서론
정의되지 않은 규칙은 모순을 낳고, 모순은 일정 지연을 낳는다.
제가 얼마 전에 IT 신규 서비스 프로젝트를 잘 완료하고 보니, 데이터와 정책을 초기에 정리하면 문제와 재작업이 크게 줄었습니다. 그래서 이 글을 작성합니다. 아래 7단계만 따라도 화면–API–정책 사이의 불일치를 빠르게 잡아낼 수 있습니다.
본론
1) 용어·코드 일관화
- 용어 사전: 서비스 핵심 용어, 정의, 예시, 금지 유의어.
- 코드 테이블: 상태/유형 값과 라벨(예:
ORDER_STATUS=PAID/REFUND_REQUESTED). - 규칙: API 응답 키, 화면 라벨, RD 문구가 동일해야 합니다.
2) 데이터 사전 정리
- 필드: 이름, 타입, 길이, 제약(필수/유일), 기본값, 예시값.
- 검증: 정규식, 최소/최대, 포맷(예:
YYYY-MM-DD). - 민감 정보: 암호화/마스킹/보존 기간을 명시.
3) 정책 정의서 작성
- 정책 문장: “항상/반드시/예외”를 포함해 모호성을 제거.
- 경계값: 수량·금액·시간의 최소/최대, 라운딩 규칙.
- 예: “쿠폰은 주문 금액 1만원 이상에서만 사용. 예외: 첫 구매 이벤트.”
4) 화면–API–정책 매핑
- 화면 요소 옆에 요소ID와 관련 API 엔드포인트를 표시.
- 응답 필드에 매칭되는 라벨/에러 메시지 문구를 명시.
- 예:
BTN-APPLY-COUPON↔POST /v1/coupons/apply↔ “잔여 수량 0이면 비활성”.
5) 엣지 케이스 검증
- 빈 상태: 데이터 없음, 네트워크 단절, 권한 없음.
- 오류: 타임아웃, 중복 요청, 순서 오류, 환불 실패.
- 권한: 비회원/회원/관리자별 접근과 버튼 상태.
- 경계: 0/최대값, 소수점, 타임존, 유효기간 임박.
6) 자동 검증 규칙 적용
- DB 제약: NOT NULL, UNIQUE, CHECK, FK.
- 서버 검증: 스키마 밸리데이션, 비즈니스 규칙 검사.
- 클라이언트: 입력 마스크, 길이 제한, 즉시 피드백.
- 로그: 실패 케이스 이벤트와 에러 코드 표준화.
7) 최종 점검표·아카이브
문서·코드·테스트 간 추적성을 유지
- 추적성: RD ID ↔ 화면ID ↔ API ↔ TC ID 매트릭스.
- 체크리스트: 용어/코드 일치, 경계값 명시, 에러 문구, 비활성 조건, 롤백 기준.
- 아카이브: 버전, 날짜, 변경 이유, 승인자 기록.
결론
모순 없는 데이터·정책은 용어부터 검증 규칙까지 한 구조로 연결할 때 가능합니다. 위의 7단계를 프로젝트 초기에 적용하면 요구 변경과 QA 지연을 크게 줄일 수 있습니다. 문서 간 링크와 자동 검증을 습관화해 정합성을 지속적으로 유지하세요.
FAQ
Q 데이터 사전과 정책서는 뭐가 다른가요?
A 데이터 사전은 필드 정의와 제약, 정책서는 업무 규칙과 예외입니다. 두 문서를 매핑하면 모순을 줄일 수 있습니다.
Q 화면 라벨과 API 필드명이 다릅니다. 어떻게 하나요?
A 용어 사전에 표준 명칭을 정하고, API 스펙과 화면 설계에서 동일하게 수정합니다. 추적성 매트릭스에 반영하세요.
Q 경계값을 빠뜨리지 않으려면?
A 금액·수량·시간·길이·포맷 5가지를 기준으로 최소/최대를 표로 작성해 QA TC와 연결하세요.
Q 자동 검증은 어디까지 필요한가요?
A 사용자 입력과 핵심 정책은 클라이언트·서버·DB 3단계에서 모두 체크하는 것을 권장합니다.
Q 문서 업데이트가 자주 늦어집니다. 해결 방법은?
A 변경 이력을 간단한 표로 강제하고, 화면ID/요구사항ID를 이슈 트래커 템플릿에 필수 항목으로 넣어 자동 추적하세요.