Kwangmin Kim - 데이터 품질 관리

1 정의

정의: 데이터 품질 관리 (Data Quality Management)

데이터 품질 관리는 데이터의 정확성, 완전성, 일관성, 적시성을 체계적으로 측정하고 개선하는 활동이다.

범위: 프로파일링 → 도메인 규칙 진단 → 업무 규칙 진단 → 품질 점수 산출 → 클린징
목적: 데이터가 비즈니스 의사결정에 신뢰할 수 있는 수준으로 유지되도록 보장
참조: DAMA-DMBOK2 Chapter 13

데이터 품질 관리는 단발성 점검이 아니라 순환적 사이클이다. 현황을 파악하고, 규칙을 정의하고, 진단을 실행하고, 오류를 수정하고, 다시 현황을 파악하는 반복 과정이 핵심이다.

2 개념 및 원리

2.1 거버넌스 프레임워크 내 위치

데이터 품질 관리는 데이터 거버넌스의 실행 단계에 해당한다. 표준화(용어, 도메인, 코드)가 “데이터를 어떻게 정의할 것인가”를 다루고, 중요데이터 관리가 “데이터의 민감도”를 관리한다면, 품질 관리는 “데이터의 정확도”를 관리하는 활동이다. 표준 도메인 사전과 코드 체계가 먼저 갖춰져야 품질 규칙을 체계적으로 정의할 수 있으므로, 표준화는 품질 관리의 선행 조건이다.

2.2 품질 관리 사이클의 구성 요소

현황 파악(프로파일링) → 현실적 규칙 정의(도메인/업무 규칙)
    → 우선순위 기반 진단 → 품질 점수 산출 → 클린징 워크플로
    → 재프로파일링(사이클 반복)

각 단계는 독립적으로 수행할 수 없다. 프로파일링 없이 규칙부터 정의하면 현실과 동떨어진 기준이 만들어지고, 진단 없이 클린징을 시도하면 우선순위 없는 수정이 된다.

2.3 흔한 실패 패턴

품질 도구를 도입하고 처음으로 진단을 실행하면 거의 항상 충격적인 결과가 나온다. 오류율이 10%가 넘는 칼럼들이 수백 개이다. 팀 미팅에서 결과를 공유하면 “원래 그렇다”, “이 데이터는 원래 NULL이 많다”는 말이 나온다. 품질 개선 프로젝트는 시작도 전에 저항에 부딪힌다.

이 실패 패턴의 원인은 대부분 두 가지 중 하나이다.

첫 번째는 현황 파악 없이 규칙부터 정의한 경우이다. 실제 데이터의 분포를 모르는 상태에서 이상적인 규칙을 정의하면 오류가 폭발한다. 나이 칼럼에 “0 이상 100 이하, NOT NULL”을 적용했는데 실제로 120세 레코드와 NULL 2%가 있으면, 이 모든 것이 “오류”로 분류된다. 현실과 동떨어진 규칙이 만들어낸 허위 양성(false positive)이다.

두 번째는 너무 많은 것을 한 번에 바꾸려 한 경우이다. 우선순위 없이 모든 오류를 동시에 개선하려 하면 아무것도 개선되지 않는다. 리소스는 한정되어 있고, 모든 오류가 같은 비즈니스 임팩트를 가지지 않는다.

2.4 프로파일링 – 데이터의 현재 상태를 있는 그대로 파악한다

프로파일링은 판단하지 않는다. 현재 상태를 측정할 뿐이다. “이 칼럼에 NULL이 30%가 있다”는 프로파일링 결과이다. “이 칼럼에 NULL이 30%가 있는 것은 문제다”는 그 다음에 하는 판단이다. 이 두 단계를 혼용하면 프로파일링이 오류 리포트가 되고, 담당자들이 방어적이 된다.

비유하자면, 건강검진에서 혈압이 150이라는 측정 결과와 “고혈압이므로 치료가 필요하다”는 진단은 별개의 단계이다. 측정 결과를 먼저 공유하고, 그 수치가 문제인지 여부는 기준(규칙)을 정한 후에 판단해야 한다.

프로파일링에서 수집하는 정보는 다음과 같다.

수집 항목	설명	활용
전체 행 수	테이블 레코드 수	기본 모수
NULL 건수/비율	비결측 현황	nullable 여부 판단
고유값(Distinct) 수	카디널리티 파악	코드 도메인 후보 식별
최솟값/최댓값	값 범위	RANGE 도메인 설계
평균값(숫자형)	중심 경향	이상치 기준 설정
최소/최대 길이	문자열 길이 분포	데이터 타입 적정성 확인
상위 빈도 값 목록	Top-N 값과 빈도	코드 도메인 허용 값 설정
데이터 패턴 분포	이메일, 전화번호 형식 등	REGEX 도메인 설계

프로파일링 결과는 도메인 규칙을 현실적으로 설계하는 기반이 된다. 예를 들어 나이 칼럼을 프로파일링했더니 최솟값이 0, 최댓값이 120, NULL이 2%라는 결과가 나왔다. 이제 도메인 규칙을 정의할 때 “0 이상 150 이하, NULL 허용”으로 현실에 기반한 규칙을 만들 수 있다. 이상적인 규칙을 먼저 정의했다면 120세 레코드와 NULL 2%가 모두 오류로 분류되었을 것이다. 현실을 반영한 규칙을 먼저 만들고, 이후 점진적으로 기준을 강화하는 것이 올바른 순서이다.

상위 빈도 값 분포는 코드 도메인 설계에 활용한다. STATUS 칼럼의 상위 빈도 값이 ACTIVE, INACTIVE, PENDING이고 전체의 99.8%를 차지한다면, 이 세 값이 코드 도메인의 허용 값이 되어야 한다. 나머지 0.2%에 무슨 값이 있는지 확인해서 유효하지 않은 값(오타, 레거시 값 등)과 실제 허용되어야 하는 값을 구분한다.

2.5 도메인 규칙과 업무 규칙

도메인 규칙은 단일 칼럼의 허용 값 범위를 정의한다. 칼럼에 매핑된 도메인 유형(RANGE, REGEX, CODE)에 따라 진단 쿼리가 자동 생성된다.

도메인 유형	검증 대상	예시
RANGE	숫자/날짜의 허용 범위	나이: 0 이상 150 이하
REGEX	문자열 패턴	이메일: `^[a-zA-Z0-9._%+-]+@...`
CODE	허용 코드 목록	성별: M, F

업무 규칙은 여러 칼럼 또는 여러 테이블 간의 관계를 검증한다. 이것은 메타데이터에서 자동으로 생성할 수 없다. 비즈니스 로직을 알아야 정의할 수 있다.

규칙 유형	예시	검증 대상
테이블 간 관계	주문 완료 상태의 주문에는 반드시 결제 정보가 있어야 한다	ORDER - PAYMENT 간
칼럼 간 대소 관계	출고 수량은 재고 수량을 초과할 수 없다	INVENTORY 내 두 칼럼
날짜 순서	반품 처리일은 주문일 이후여야 한다	단일 테이블 내 두 날짜
집계 일치	주문 상세의 합계 금액은 주문 헤더의 총 금액과 일치해야 한다	헤더-상세 간
참조 무결성	주문의 고객 ID는 고객 테이블에 존재해야 한다	FK 관계 검증

2.6 품질 점수 체계

진단 결과를 개별 규칙 단위로만 보면 전체 그림을 파악하기 어렵다. 품질 점수 체계를 도입하면 “우리 데이터 품질은 몇 점이다”라는 커뮤니케이션이 가능해진다.

칼럼 품질 점수 = 1 - (오류 건수 / 전체 건수)

테이블 품질 점수 = 도메인 규칙 점수 x 0.4
                 + 업무 규칙 점수 x 0.6
                 (가중치는 조직 방침에 따라 조정)

데이터 모델 품질 점수 = AVG(해당 모델 소속 테이블 품질 점수)

업무 규칙 가중치를 도메인 규칙보다 높게 설정한 이유는, 업무 규칙 위반이 비즈니스 임팩트가 더 크기 때문이다. “이메일 형식이 틀리다”(도메인 규칙)보다 “결제 없는 주문 완료”(업무 규칙)가 즉각적인 매출 영향이 있다.

3 왜 필요한가

3.1 부재 시 비용과 리스크

품질 관리 사이클이 없으면 다음과 같은 구체적 비용이 발생한다.

리스크 유형	구체적 시나리오	비용/영향
의사결정 오류	매출 리포트에 중복 거래가 포함되어 실적이 15% 과대 계상	잘못된 투자 의사결정, 감사 지적
운영 장애	고객 주소 오류로 배송 실패율 상승	재배송 비용, 고객 이탈
규제 위반	금융 보고 데이터의 불일치로 감독기관 제재	과징금, 영업 제한
분석 신뢰 상실	대시보드 수치가 현업 체감과 불일치하여 데이터 불신 확산	데이터 기반 문화 후퇴
통합 실패	M&A 후 코드 체계 불일치로 고객 데이터 통합 불가	시스템 통합 지연, 추가 비용

3.2 규제 준수 관점

금융권의 경우 Basel III 규제 보고에 사용되는 데이터의 정확성은 법적 의무이다. 의료 분야에서 HIPAA는 환자 데이터의 완전성과 정확성을 요구한다. EU의 GDPR은 개인정보의 정확성 유지를 데이터 컨트롤러의 의무로 규정한다(Article 5(1)(d)). 품질 관리 체계가 없으면 이러한 규제 요건을 체계적으로 충족할 수 없다.

3.3 반복 오류의 누적 비용

한 번의 오류 수정은 비용이 크지 않다. 그러나 같은 유형의 오류가 매주 반복되면 클린징 비용이 누적되고, 담당자의 피로가 쌓이며, 결국 “고쳐봤자 다시 나온다”는 학습된 무력감이 조직에 퍼진다. 사이클 기반 품질 관리는 오류의 근본 원인을 추적하고 재발을 방지함으로써 이 누적 비용을 차단한다.

3.4 품질 성숙도 관점

품질 관리의 성숙도는 단계적으로 발전한다. 성숙도가 낮은 조직은 문제 발생 후 사후 수정(reactive)만 하고, 성숙도가 높은 조직은 오류를 사전에 방지(proactive)한다.

성숙도 단계	특징	품질 관리 방식
초기	품질 문제를 인식하지 못함	현업이 문제를 발견하면 임의 수정
반복적	주요 테이블에 대해 수동 점검	담당자 경험에 의존, 이직 시 지식 소멸
정의됨	도메인/업무 규칙이 문서화됨	정기 진단 실행, 품질 점수 산출
관리됨	자동화된 진단-클린징 사이클 운영	허용 오류율 기반 모니터링, 근본 원인 분석
최적화	예측적 품질 관리	오류 발생 패턴을 분석하여 사전 차단

대부분의 조직은 “반복적” 또는 “정의됨” 단계에 있다. 이 포스트에서 다루는 프로파일링-규칙-진단-클린징 사이클은 “정의됨”에서 “관리됨”으로 이행하기 위한 핵심 설계이다.

4 응용 분야

분야	품질 관리 활동	구체적 예시
금융	거래 데이터 정합성 진단	일일 마감 시 원장 잔액과 거래 합계의 일치 검증
의료	환자 데이터 완전성 관리	진료 기록 필수 항목(진단 코드, 처방 코드) NULL 비율 모니터링
제조	센서 데이터 이상치 탐지	온도 센서 값의 정상 범위 이탈 실시간 감지
공공	행정 데이터 코드 표준화	지역 코드 체계 통합, 부서 간 코드 갭 분석
유통	상품 마스터 정확성 관리	SKU 중복 탐지, 가격 정보 불일치 진단
통신	고객 정보 최신성 관리	해지 고객의 상태 코드 반영 지연 모니터링

각 분야에서 품질 관리의 핵심 규칙 유형은 다르다. 금융은 집계 일치(업무 규칙)가 핵심이고, 의료는 완전성(도메인 규칙의 NOT NULL)이 핵심이며, 제조는 범위 검증(RANGE 도메인)이 핵심이다. 조직이 속한 도메인에 따라 품질 관리의 우선순위가 달라진다.

4.1 품질 차원별 적용

DAMA DMBOK에서 정의하는 품질 차원은 분야에 따라 중요도가 다르다.

품질 차원	정의	중점 분야
정확성(Accuracy)	실제 값과의 일치도	금융(거래 금액), 의료(진단 코드)
완전성(Completeness)	필수 필드의 비결측률	의료(환자 기록), 공공(행정 데이터)
일관성(Consistency)	시스템 간 값 일치	유통(다채널 재고), 통신(고객 정보)
적시성(Timeliness)	데이터 최신성	금융(시세 데이터), 제조(센서 데이터)
유일성(Uniqueness)	중복 없음	유통(SKU), 공공(주민등록)
유효성(Validity)	정의된 형식 준수	전 분야(코드 값, 날짜 형식)

프로파일링은 이 6가지 차원을 측정하는 출발점이고, 도메인 규칙은 유효성과 완전성을, 업무 규칙은 정확성과 일관성을 주로 검증한다.

5 예시

5.1 Before: 프로파일링 없이 규칙을 정의한 경우

상황: 고객 테이블의 AGE 칼럼에 “0 이상 100 이하, NOT NULL” 규칙을 정의했다.

항목	결과
진단 오류 건수	48,230건 (전체 200만 건 중)
오류율	2.41%
담당자 반응	“120세 고객은 법인 고객 더미 데이터이다”, “NULL 2%는 간편가입 고객이다”
결과	규칙에 대한 불신, 품질 프로젝트 중단

5.2 After: 프로파일링 기반으로 규칙을 정의한 경우

상황: 프로파일링으로 최솟값 0, 최댓값 120, NULL 비율 2.1%를 확인한 후 “0 이상 150 이하, NULL 허용” 규칙을 정의했다.

항목	결과
진단 오류 건수	312건 (범위 이탈 이상값)
오류율	0.016%
담당자 반응	“312건은 실제 입력 오류이다, 수정 가능하다”
결과	2주 내 0건 달성, 다음 규칙 강화 단계로 이행

프로파일링 기반 접근의 핵심은 “현실에서 출발하여 이상으로 점진적으로 이동”하는 것이다. 이상에서 출발하면 현실과의 괴리가 저항을 만들고, 현실에서 출발하면 합의 가능한 개선이 된다.

5.3 Before/After: 품질 점수 도입 효과

Before: 품질 진단 결과를 규칙별 오류 건수 목록으로 보고한다. 경영진은 “그래서 좋은 건가 나쁜 건가?”라고 묻는다.

After: 테이블 품질 점수 92.3%, 전 분기 대비 +3.1%p로 보고한다. 경영진은 시스템별 점수 비교로 투자 우선순위를 판단한다.

6 코드/도구 예시

6.1 프로파일링 쿼리

단일 칼럼 프로파일링 쿼리의 기본 구조는 집계 함수들을 한 번의 쿼리로 실행하는 것이다.

-- 단일 칼럼 기본 프로파일링
SELECT
  COUNT(*)                                   AS row_count,
  COUNT(*) - COUNT(col_name)                 AS null_count,
  ROUND((COUNT(*) - COUNT(col_name)) * 100.0
        / NULLIF(COUNT(*), 0), 2)            AS null_rate,
  COUNT(DISTINCT col_name)                   AS distinct_count,
  MIN(col_name)                              AS min_value,
  MAX(col_name)                              AS max_value,
  MIN(LENGTH(CAST(col_name AS VARCHAR)))     AS min_length,
  MAX(LENGTH(CAST(col_name AS VARCHAR)))     AS max_length
FROM schema_name.table_name;

상위 빈도 값 목록은 별도 쿼리로 수집한다.

-- 상위 빈도 값 조회
SELECT col_name AS value, COUNT(*) AS frequency
FROM schema_name.table_name
WHERE col_name IS NOT NULL
GROUP BY col_name
ORDER BY COUNT(*) DESC
FETCH FIRST 20 ROWS ONLY;  -- Oracle 방식. MySQL은 LIMIT 20

6.2 대용량 테이블 샘플링

수억 건 이상의 테이블에 전체 스캔 쿼리를 실행하면 운영 서버에 심각한 부하가 생긴다.

DBMS	샘플링 구문	비고
Oracle	`SELECT * FROM table_name SAMPLE(1)`	1% 블록 샘플링
PostgreSQL	`SELECT * FROM table_name TABLESAMPLE SYSTEM(1)`	1% 페이지 샘플링
MySQL	`ORDER BY RAND() LIMIT N`	성능 비효율적, 대안 필요

샘플링 결과는 근사값이 된다. 저장되는 프로파일링 결과에 샘플링 여부와 샘플 비율을 기록해서 “이 숫자는 전체의 1% 샘플 기반 추정치”임을 알 수 있게 한다. 근사값이라도 NULL 비율이 30%인지 3%인지의 차이는 충분히 드러나므로, 규칙 설계의 기반으로 쓰기에 충분하다.

6.3 도메인 규칙 진단 쿼리

DBMS별 정규식 함수가 다르다. 이 차이를 추상화 레이어에서 처리해야 한다.

DBMS	정규식 불일치 조건	비고
Oracle	`NOT REGEXP_LIKE(col, pattern)`	완전한 POSIX 정규식 지원
MySQL/MariaDB	`col NOT REGEXP pattern`
PostgreSQL	`col !~ pattern`
MS SQL Server	`PATINDEX` 활용	완전한 정규식 미지원

CODE 타입 도메인 진단은 코드 그룹의 현재 유효 코드 목록을 서브쿼리로 가져온다.

-- CODE 타입 도메인 진단
SELECT COUNT(*) AS error_count
FROM target_table
WHERE col NOT IN (
  SELECT code_key
  FROM TB_CODE_VALUE
  WHERE code_group_id = 'TARGET_CODE_GROUP'
    AND env_type = 'PROD'
    AND status = 'ACTIVE'
    AND (effective_from IS NULL OR effective_from <= CURRENT_DATE)
    AND (effective_to IS NULL OR effective_to >= CURRENT_DATE)
)
AND col IS NOT NULL;

이 쿼리에서 effective_from과 effective_to 조건이 중요하다. 코드 유효 기간 관리가 여기서 연결된다. 과거에 유효했지만 현재 폐기된 코드 값이 데이터에 남아있으면, 현재 기준으로는 오류이지만 당시 기준으로는 정상이었을 수 있다.

6.4 복수 칼럼 통합 진단 (성능 최적화)

칼럼별로 개별 쿼리를 실행하면 테이블에 칼럼이 100개일 때 100번의 테이블 스캔이 발생한다. 하나의 쿼리로 합치면 스캔 횟수를 1번으로 줄일 수 있다.

-- 복수 칼럼 통합 진단 (테이블 스캔 1회)
SELECT
  SUM(CASE WHEN age < 0 OR age > 150
           THEN 1 ELSE 0 END)                             AS age_error,
  SUM(CASE WHEN email NOT REGEXP '^[a-zA-Z0-9._%+-]+@...'
           THEN 1 ELSE 0 END)                             AS email_error,
  SUM(CASE WHEN gender NOT IN ('M', 'F') AND gender IS NOT NULL
           THEN 1 ELSE 0 END)                             AS gender_error,
  COUNT(*)                                                 AS total_count
FROM target_table;

진단 엔진이 대상 테이블의 모든 도메인 규칙을 모아서 CASE WHEN 조건을 동적으로 생성해서 단일 쿼리로 실행하는 것이 성능상 최적이다.

6.5 업무 규칙 진단 쿼리

업무 규칙의 진단 SQL은 두 가지 방식으로 작성한다. 오류 건수만 반환하면 진단 결과 요약에 사용하고, 오류 레코드를 반환하면 클린징 대상을 파악하는 데 사용한다.

-- 오류 건수 반환 방식
SELECT COUNT(*) AS error_count
FROM TB_ORDER o
WHERE o.ORDER_STATUS = 'COMPLETED'
  AND NOT EXISTS (
    SELECT 1 FROM TB_PAYMENT p
    WHERE p.ORDER_ID = o.ORDER_ID
      AND p.PAYMENT_STATUS = 'SUCCESS'
  );

-- 오류 레코드 반환 방식 (클린징 대상 파악용)
SELECT o.ORDER_ID, o.ORDER_STATUS, o.ORDER_DT
FROM TB_ORDER o
WHERE o.ORDER_STATUS = 'COMPLETED'
  AND NOT EXISTS (
    SELECT 1 FROM TB_PAYMENT p
    WHERE p.ORDER_ID = o.ORDER_ID
      AND p.PAYMENT_STATUS = 'SUCCESS'
  )
ORDER BY o.ORDER_DT DESC;

업무 규칙 SQL은 DA와 업무 담당자가 함께 작성해야 한다. DA가 SQL을 작성하고 업무 담당자가 비즈니스 로직의 정확성을 검증하는 방식이 현실적이다.

6.6 허용 오류율 설계

업무 규칙은 도메인 규칙보다 복잡하고, 현실에서 예외 케이스가 더 많다. 업무 규칙별로 허용 오류율( \(\text{error\_threshold}\) )을 설정한다.

규칙 예시	허용 오류율	근거
주문 완료 시 결제 정보 필수	0%	데이터 무결성에 직결
출고 수량 \(\leq\) 재고 수량	0.1%	동시성 이슈로 미세 초과 가능
고객 이메일 형식 검증	2%	레거시 데이터 존재, 즉각적 비즈니스 임팩트 낮음

오류율이 허용 오류율을 초과하면 FAIL, 이하이면 PASS, 경계에 있으면 WARNING으로 분류한다. 이 3단계 분류가 있어야 대시보드에서 즉시 주의가 필요한 항목과 모니터링만 하면 되는 항목을 구분할 수 있다.

6.7 모니터링 수치 해석

실제 운영 환경에서 관찰되는 수치를 해석해보면, 각 지표가 의미하는 바가 명확해진다.

지표	수치	해석
도메인 규칙 오류율	1.48% (145,746 / 9,860,837)	1천만 건 중 15만 건 위반. 칼럼 단위 오류이므로 절대 수는 크지만 비율은 낮다
업무 규칙 오류율	8.06% (2,311 / 28,690)	3만 건 검증 대상 중 2,300건 위반. 비율이 높고 비즈니스 임팩트가 크다
Schema 일치율	91%	개발 DB와 운영 DB의 테이블/칼럼 중 91% 일치. 9%는 배포 누락 또는 환경 차이
Code 일치율	83%	코드 갭이 스키마 갭보다 크다. 코드 배포 프로세스 점검이 필요하다

도메인 규칙 오류율이 업무 규칙 오류율보다 낮은 것이 일반적이다. 도메인 규칙은 단일 칼럼 기반이라 검증 대상이 수천만 건이고 칼럼 하나하나의 오류는 작게 나타난다. 업무 규칙은 여러 테이블 간 관계를 검증하므로 레코드 수는 적지만 비즈니스 임팩트가 더 크다.

6.8 클린징 워크플로

진단에서 오류가 발견되면 그 오류를 수정하는 것이 클린징이다. 클린징은 단순히 잘못된 데이터를 고치는 것이 아니라 거버넌스 프로세스를 따라야 한다. 임의로 데이터를 수정하면 수정 이력이 남지 않고, 같은 문제가 반복될 수 있고, 다른 시스템에 영향을 줄 수 있다.

[진단 결과] 오류 레코드 발견
    |
[변경 요청 자동 생성]
    - 현재 값: ORDER_STATUS = 'COMPLETED', PAYMENT = NULL
    - 제안 수정: ORDER_STATUS = 'PENDING_PAYMENT'
    - 수정 근거: 업무 규칙 BR-001 위반 (주문 완료 시 결제 정보 필수)
    |
[데이터 오너 승인]
    |
[변경 실행 + 이력 기록]
    |
[재진단으로 수정 확인]

이 흐름에서 핵심은 변경 요청이라는 중간 단계이다. 오류를 발견한 사람이 바로 수정하는 것이 아니라, 데이터 오너의 승인을 거쳐 수정한다. 이렇게 해야 수정 이력이 남고, 잘못된 수정을 방지할 수 있다.

6.9 반복 오류 방지

클린징이 효과적이려면 같은 오류가 반복되지 않아야 한다. 데이터를 수정해도 원인이 해결되지 않으면 다음 배치에서 또 같은 오류가 들어온다.

원인 유형	설명	해결 방법
입력 유효성 검증 부재	애플리케이션에서 잘못된 값이 그대로 DB에 저장	애플리케이션 입력 검증 로직 추가
ETL 변환 오류	소스 데이터는 정상인데 DW 적재 과정에서 변환 오류	ETL 로직 수정
도메인 규칙 자체의 문제	규칙이 너무 엄격하거나 현실 미반영	규칙 재정의

품질 진단 결과에서 같은 규칙 위반이 반복적으로 나타나면 원인 분류 분석을 수행해야 한다. 오류를 수정하는 것은 증상 치료이고, 원인을 제거하는 것이 근본 치료이다.

7 관련 주제

카테고리 내 연결

다른 카테고리 연결

데이터 파이프라인 설계