데이터 사전 발표: 필드 정의와 업무 의미를 설명하는 법

데이터 사전 발표는 모든 열을 스프레드시트처럼 화면에 펼쳐 놓는 자리가 아니라, 의미에 대한 의견 차이를 해결하는 자리입니다. 사람들이 이미 다르게 해석하는 업무 질문에서 시작하세요. 몇 개의 실제적인 예시 행으로 차이를 설명하고 정의에 합의한 다음, 누가 이를 관리하며 관련 보고서에 무엇이 바뀌는지 보여 주세요.

가상의 예약 서비스를 생각해 보겠습니다. 대시보드에는 “예약 3건 완료”라고 표시되지만 운영 책임자는 실제 서비스를 받은 고객이 1명이라고 말합니다. 어느 쪽도 숫자를 지어낸 것은 아닙니다. 대시보드는 취소와 노쇼를 포함한 종료 상태의 예약을 세고 있습니다. 하나의 이름 때문에 서로 다른 세 결과가 같은 것으로 보이는 것입니다. 아래의 기록, 역할, 변경 사항은 데이터 사전 검토를 설명하기 위한 가상 설정이며, 고객 데이터나 Presenti 도입 사례가 아닙니다.

팀이 정의를 정한 뒤에는 Presenti의 텍스트를 프레젠테이션으로 만드는 기능으로 승인된 설명을 편집 가능한 슬라이드 초안으로 옮길 수 있습니다. 기밀 데이터베이스 전체가 아니라 필요한 필드 정의와 예시 행을 입력하세요. 기준은 여전히 데이터 사전이며, 발표 자료는 의사결정에 필요한 부분을 대상 청중에 맞게 보여 주는 자료입니다.

의견이 갈린 업무 용어부터 다루세요

이 사례의 청중은 운영 책임자, 보고서 분석가, 예약 데이터 내보내기를 담당하는 엔지니어입니다. 다음 보고서 배포 전에 “완료된 예약”의 의미를 승인해야 합니다. 예약 시스템의 모든 필드를 소개받을 필요는 없습니다.

유용한 데이터 사전은 사람들이 쓰는 말과 확인할 수 있는 데이터를 연결합니다. USGS의 데이터 사전 안내는 이름, 정의, 데이터 형식, null 허용 여부, 참조 값, 업무 규칙 등을 사전에 담을 수 있다고 설명합니다. 이 회의에서는 그 정보가 구체적인 질문에 답해야 합니다. 이 행은 서비스가 제공됐다는 뜻인가요, 아니면 더 이상 진행되지 않을 예약이라는 뜻인가요?

첫 슬라이드에서 범위를 정하세요. “한 지점의 일별 예약 스냅샷이며 예약 1건당 1행”입니다. 이 예시의 스냅샷은 2026년 10월 9일 08:00 UTC에 만들어졌습니다. 오늘의 최신 상태가 아니라 그 시점의 상태를 담고 있습니다. 슬라이드에 기준 시각과 데이터 사전 버전을 표시하세요. 예약은 고객과 같지 않습니다. 한 고객이 여러 번 예약할 수 있습니다. 스냅샷 역시 모든 상태 변경의 이력이 아닙니다. 이 두 구분만으로도 정상적인 데이터를 그럴듯하게 잘못 사용하는 일을 막을 수 있습니다.

기존 대시보드 규칙에서는 completed, cancelled, no_show를 모두 종료 상태로 보므로 총 3건입니다. 제안된 완료 정의에 해당하는 것은 000271뿐입니다. 네 번째 행은 예정일이 지났다는 이유만으로 노쇼로 처리하면 안 됩니다. 이 추출본에서 그 결과는 아직 확정되지 않았습니다.

필드 형식과 업무상 의미를 구분하세요

형식은 값이 어떤 형태를 가질 수 있는지 설명하고, 정의는 그 값이 무엇을 뜻하는지 설명합니다. 날짜처럼 생겼다고 해서 예약 생성일인지, 서비스 예정일인지, 내보낸 날짜인지 알 수는 없습니다. 마찬가지로 숫자로 보이는 ID가 더하거나 반올림할 수 있는 수량인 것도 아닙니다.

W3C의 표 형식 데이터 메타데이터 어휘는 열의 형식, 필수 값, 키와 제약 등을 기계가 읽을 수 있는 메타데이터로 표현하는 방법을 제공합니다. 이런 검증은 잘못된 형식이나 누락을 찾는 데 도움이 됩니다. 그러나 취소된 예약을 완료로 세어야 하는지까지 결정해 주지는 않습니다. 기술적 제약과 업무상 합의를 함께 관리하되, 둘을 같은 것으로 취급하지 마세요.

업무 담당자에게 설명할 때는 데이터베이스 용어를 모두 소개하기보다, 필드 옆에 예시 행 하나와 가능한 실수 하나를 보여 주세요. 000271 앞의 0은 왜 문자열이어야 하는지 바로 이해하게 해 줍니다. 서비스 예정일과 완료 타임스탬프의 차이는 시간대 규칙이 왜 필요한지 설명해 줍니다. 어려운 기술 주석으로 남겨 둘 필요가 없습니다.

누락과 값의 충돌을 명확히 설명하세요

네 행 중 세 행에 완료 시각이 없지만 상태는 서로 다릅니다. 취소 예약에는 없는 것이 정상입니다. 노쇼에도 다른 이유로 없는 것이 정상입니다. 결과 미확정 예약에서는 완료가 기록되지 않았다는 사실만 알 수 있습니다. 셋을 모두 “미완료”로 바꾸면 계산 하나는 편해질 수 있지만, 업무 처리에 필요한 차이가 사라집니다.

회의 중 다섯 번째 가상 레코드를 추가해 보세요. 이 레코드는 예외에 해당합니다. status는 completed인데 완료 타임스탬프가 없습니다. 운영 책임자는 서비스가 제공됐다는 사실을 알 수 있지만 분석가는 이 행만으로 시각을 추론할 수 없습니다. 제안된 규칙은 이를 정의 적용상의 예외로 분류해 조사하고, 완료 건수 옆에 제외된 예외 건수를 따로 표시하는 것입니다. 보고서 숫자를 맞추려고 원래 상태를 고쳐 쓰면 안 됩니다.

이는 중요한 선택이지만 보편적인 규칙은 아닙니다. 다른 회사는 상태 값만으로 완료를 인정할 수 있습니다. 그렇다면 그 정책과 타임스탬프가 필요한 조건을 문서화하세요. 위험한 것은 두 보고서 작성자가 서로 다른 정책을 쓰면서 그 차이를 드러내지 않는 것입니다.

다른 용어를 검토할 때는 왼쪽 항목을 재사용하되 오른쪽 내용은 전부 새로 정하세요. “활성 고객”, “해결된 티켓”, “인식한 매출”은 각각 포함 규칙과 승인 권한이 다릅니다. 이름만 바꿔 넣는 것으로 유효한 정의가 만들어지지는 않습니다.

의미, 데이터 연결, 변경 관리의 책임을 나누세요

담당자를 “데이터팀”이라고 적으면 세 질문이 가려지기 쉽습니다. 누가 의미를 승인하나요? 누가 원천 데이터 연결을 고치나요? 의미가 바뀌었다는 사실은 누가 보고서 사용자에게 알리나요? 가상의 예약팀에서는 다음과 같이 나눕니다.

• 운영 책임자: 서비스 제공 완료에 완료 타임스탬프가 필요한지 승인하고 업무 예외를 해결합니다.
• 예약 시스템 엔지니어: 상태와 타임스탬프가 내보내기 데이터에 반영되는 방식, 지연과 정정 동작을 확인합니다.
• 보고서 분석가: 사전 항목을 관리하고 영향을 받는 보고서와 승인 버전을 기록합니다.
• 대시보드 담당자: 이름과 계산식을 바꾼 뒤 업무 책임자가 검토할 수 있는 예시를 제시합니다.

이것은 사례의 책임 구분이지 네 개의 직무를 새로 만들라는 뜻이 아닙니다. 작은 팀에서는 역할을 겸할 수 있지만, 결정 기록에는 책임자의 이름과 연락 경로가 있어야 합니다. 엔지니어가 사업상 정의를 임의로 만들어서도 안 되고, 업무 책임자가 아무도 검증하지 않은 연결 관계를 승인해서도 안 됩니다.

아직 합의되지 않은 범위는 승인 대상에서 제외하세요. 이 팀은 노쇼 수수료를 해당 보고서의 매출에 넣을지 결정하지 않았습니다. 예약 정의가 명확해졌다고 매출 인식, 환불, 세금 처리까지 해결된 것처럼 보여서는 안 됩니다. 이는 서로 다른 원천 기록과 결정 책임자가 필요한 별개의 용어입니다.

정의 변경이 과거 비교에 미치는 영향을 보여 주세요

제안된 v2.0은 “종료된 예약”과 “완료된 예약”을 구분합니다. 기존 대시보드의 “완료”라는 이름은 더 넓은 종료 규칙을 가리켰습니다. 이름이나 계산식 중 하나만 바꾸면 사용자는 여전히 서로 다른 숫자를 비교하게 됩니다.

3에서 1로 줄었다고 서비스 성과가 나빠진 것은 아닙니다. 기록은 같고 정의가 달라졌습니다. 버전 변경 시점을 가로지르는 시계열 차트보다 먼저 이 차이를 설명하세요.

가상 도입안에서는 2026년 11월 2일에 시작하는 보고 주부터 v2.0을 적용한다고 제안합니다. v1.0 사전과 내보낸 보고서는 보존합니다. 보관된 스냅샷에 필요한 필드가 있으면 v2.0 기준으로 다시 계산한 과거 데이터를 별도로 만들고 버전을 표시하세요. 필요한 필드가 없으면 시계열을 분리하고 기준이 바뀐 지점을 밝힙니다. 현재 상태의 추출본으로 과거의 모든 보고 기준 시점을 신뢰성 있게 재현할 수는 없습니다.

변경 기록에는 이전 규칙, 새 규칙, 적용 보고 기간, 승인자, 영향받는 보고서, 과거 데이터 처리 방식을 적어야 합니다. 원천 데이터 내보내기 자체가 바뀌는지, 보고서의 해석만 바뀌는지도 설명하세요. 이 사례에서는 내보내기는 그대로이고 업무 정의, 대시보드 이름, 계산식이 함께 바뀝니다. 이 구분이 있어야 엔지니어가 의미에 대한 결정을 스키마 이전 작업으로 오해하지 않고 작업량을 산정할 수 있습니다.

정의에 관한 결정을 5장으로 발표하세요

업무 검토에는 근거가 되는 데이터 사전이 필요하지만, 사전 전체를 화면에 띄울 필요는 없습니다. 이 사례는 다음 5장으로 구성할 수 있습니다.

1. “종료된 예약 3건이 서비스 제공 3건은 아닙니다.” 문제가 된 대시보드 이름과 운영팀의 질문을 나란히 놓습니다.
2. “같은 네 행에서 두 집계가 나옵니다.” 작은 기록 표로 completed, cancelled, no_show, 결과 미확정 booked를 구분합니다.
3. “완료의 의미를 이렇게 승인해 주세요.” 포함 조건, 예외, 시간 기준에 집중해 필드·용어 정의 카드를 보여 줍니다.
4. “v2.0은 사건이 아니라 비교 기준을 바꿉니다.” 3건에서 1건으로 바뀌는 이유, 적용 기간, 과거 재계산의 한계를 설명합니다.
5. “정의를 승인하고 보고서 변경 담당자를 정합니다.” 의사결정, 데이터 연결, 보고서 책임자를 밝히고 매출 문제는 이번 승인에서 제외합니다.

전체 데이터 사전과 변경 기록은 발표 자료에 첨부해 회의 후에도 승인된 세부 사항을 찾을 수 있게 하세요. 메모로 슬라이드 초안을 만들 때는 필드 식별자를 정확히 유지하고, “가상”이라는 표시를 남기며, 제목을 줄이더라도 종료와 완료의 차이가 사라지지 않도록 합니다. 메모를 슬라이드로 바꾼다고 데이터베이스 자동 스캔이나 카탈로그 동기화가 이뤄지는 것은 아닙니다.

이 회의에서 제안할 결과는 구체적입니다. 완료를 서비스 제공이 기록되고 완료 시각이 있는 예약으로 승인하고, 종료는 별도 묶음으로 유지하며, 기준 변경 지점이나 별도 재계산 이력을 명시한 v2.0 보고서 정의를 배포하는 것입니다. 이렇게 해야 서로 다르게 읽는 용어집이 아니라 실제로 구현할 수 있는 합의가 남습니다.