데이터 과학 및 분석 분야에서 7년간 일하면서 많은 테이블을 생성하고 조회해왔습니다. 그 과정에서 여러 번 “이 열은 무엇을 의미할까?” “테이블 A와 테이블 B에 같은 이름을 가진 두 개의 열이 있는데, 어느 것을 사용해야 하지?” “이 테이블의 세부 수준은 무엇인가?”와 같은 질문을 하곤 했습니다.
같은 어려움을 겪으신 적이 있다면, 이 글이 여러분께 도움이 될 것입니다!
이 글에서는 동료들이 고마워할 수 있는 테이블을 만드는 데 도움이 되는 다섯 가지 원칙을 공유하고자 합니다. 이 글은 데이터 과학자의 관점에서 작성되었으므로, 전통적인 데이터베이스 설계 모범 사례가 아닌 사용자 친화적인 테이블을 만들기 위한 전략에 중점을 두고 있습니다.
I. 단일 진실의 출처
각 중요한 데이터 포인트나 메트릭에 대해 단일 진실의 출처를 유지하는 것은 보고 및 분석에 매우 중요합니다. 여러 테이블에 반복된 논리가 있어서는 안 됩니다.
편리함을 위해 때때로 우리는 여러 테이블에서 동일한 메트릭을 계산합니다. 예를 들어, 총 상품 가치 (GMV) 계산이 고객 테이블, 월간 재무 보고서 테이블, 상인 테이블 등에 존재할 수 있습니다. 이러한 열은 이후의 테이블에서 더 많은 변형으로 참조됩니다. 시간이 지나면서 이들은 서로 다르게 될 수 있습니다. 모든 것이 잘 작동했지만, 어느 날 이해관계자가 “이 대시보드의 월간 GMV가 다른 것과 다른 이유는 무엇인가요? 데이터가 잘못된 것인가요?”라고 질문했습니다. 데이터 파이프라인의 여러 층을 파고들면서, 우리는 지난 분기에 GMV에 포함할 거래를 정리된 거래로만 제한하기로 합의했지만, 모든 테이블에서 이 변경을 잊어버린 것을 깨달았습니다… 이것은 이해관계자의 신뢰를 해치고, 복잡한 데이터 모델을 조사하고 유지하는 데 점점 더 많은 시간을 소비하게 됩니다.
그렇다면 이를 어떻게 해결할 수 있을까요? GMV 계산의 단일 버전을 전용 테이블에 유지하세요. 그런 다음 GMV 메트릭이 필요한 모든 다른 테이블은 자체 계산 로직을 만드는 대신 이 테이블을 사용해야 합니다.
하지 말아야 할 것들:
- 다른 테이블에서 동일한 계산의 여러 버전을 유지하지 마세요.
해야 할 것들:
- 각 주요 메트릭의 단일 버전을 유지하세요.
- 논리를 어디에나 중복시키기보다는, 하위 테이블에서 그 진실의 출처 테이블을 참조하세요.
II. 일관된 세분화
일관된 세분화는 데이터 처리 및 분석에서 매우 중요한 요소입니다. 세분화는 데이터를 특정 기준에 따라 나누는 것을 의미하며, 이를 통해 더 나은 인사이트를 얻을 수 있습니다. 일관된 세분화는 다음과 같은 이점을 제공합니다:
- 데이터의 일관성을 유지하여 신뢰성을 높입니다.
- 분석 결과가 보다 명확하고 이해하기 쉽게 만듭니다.
- 비교 가능성을 증대시켜 다양한 시나리오를 평가하는 데 유용합니다.
일관된 세분화를 달성하기 위해서는 다음과 같은 전략이 필요합니다:
- 세분화 기준을 명확히 정의합니다.
- 데이터 수집 및 처리 과정에서 동일한 기준을 적용합니다.
- 정기적으로 세분화 기준을 검토하고 업데이트합니다.
이러한 접근 방식을 통해 데이터 분석의 품질과 효율성을 높일 수 있습니다.
테이블이 일일 수준에 있다면, 일일 수준을 유지해야 합니다. 서로 다른 세분화 수준의 데이터를 하나의 테이블에 혼합하면 혼란과 데이터 무결성 문제가 발생할 수 있습니다.
여기 제가 경험한 실제 사례가 있습니다: 한 번은 운영 서비스 수준 계약(SLA) 성과를 보고하기 위해 테이블을 만들었습니다. 우리는 서로 다른 운영 작업 흐름에 대해 SLA를 정의했으며, SLA를 얼마나 자주 충족할 수 있는지 추적하고 싶었습니다. SLA는 두 가지 수준으로 정의되었습니다: 접점 수준(각 상호작용)과 케이스 수준(전체 프로세스)입니다. 하나의 케이스는 여러 사람에 의해 여러 번 처리될 수 있습니다. 우리는 각 접점이 특정 시간 제한 내에 완료되기를 원하며, 전체 케이스가 시간 범위 내에 해결되기를 원했습니다. 보고를 위해 BI 도구에 하나의 테이블을 덤프하는 것이 훨씬 더 쉬울 것이라고 생각하여, 두 가지 세분화 수준을 혼합한 테이블을 만들었습니다. sla_level이라는 열이 있었고, 두 개의 값 touchpoint와 case가 있었습니다. 사람들이 특정 SLA 수준을 필터링하여 필요한 메트릭을 얻기를 바랐습니다.
이것이 왜 문제가 되는 걸까요? 모든 사람이 제가 방금 설명한 맥락을 가지고 있는 것은 아닙니다. 그들은 종종 보고서에서 이 필터를 포함하지 않았고, 결과적으로 하나의 케이스가 케이스 수준과 접점 수준 모두에 나타나면서 이중 계산이 발생하게 되었습니다.
대신 무엇을 했어야 할까요? 접점 수준에 대한 테이블과 케이스 수준에 대한 테이블 두 개를 만들어야 했습니다. 각 테이블의 차이점을 문서화하여 명확히 설명하고, 다양한 사용 사례에 맞게 적절한 테이블만 사용해야 했습니다.
하지 말아야 할 것들:
- 서로 다른 데이터 세분화 수준을 가진 행이나 열을 동일한 테이블에 혼합하지 마세요. 이는 데이터 오용 및 잘못된 분석으로 이어질 수 있습니다.
해야 할 것들:
- 각 테이블에는 하나의 세분화 수준만 포함되도록 하세요.
III. 설명적인 명명 규칙
설명적인 명명 규칙은 코드의 가독성을 높이고 유지 관리를 용이하게 하는 중요한 원칙입니다. 이러한 규칙을 따르면 다른 개발자들이나 미래의 자신이 코드를 이해하기 쉽게 만들 수 있습니다.
1. 변수명
변수명은 그 변수의 용도나 의미를 명확히 전달해야 합니다. 예를 들어, 사용자 나이를 저장하는 변수를 ‘userAge’와 같이 명명하는 것이 좋습니다.
2. 함수명
함수명은 함수가 어떤 작업을 수행하는지를 나타내야 합니다. 예를 들어, ‘calculateTotal’이라는 이름은 해당 함수가 총계를 계산하는 기능을 수행함을 분명히 보여줍니다.
3. 클래스명
클래스명은 일반적으로 명사 형태로 작성하며, 각 클래스의 역할을 설명해야 합니다. 예를 들어, ‘UserProfile’이라는 클래스명은 사용자 프로필 관련 정보를 담고 있음을 나타냅니다.
4. 상수명
상수명은 대문자와 언더스코어를 사용하여 작성하는 것이 일반적입니다. 예를 들어, ‘MAX_CONNECTIONS’와 같이 명명하면 이 값이 변경되지 않음을 쉽게 인지할 수 있습니다.
5. 일관성 유지
가장 중요한 것은 명명 규칙에 일관성을 유지하는 것입니다. 프로젝트 전반에 걸쳐 동일한 규칙을 따름으로써 코드의 일관성과 가독성을 높일 수 있습니다.
이러한 설명적인 명명 규칙을 따르면, 코드의 이해도를 높이고 협업 시 혼란을 줄일 수 있습니다.
제가 인정해야 할 것은 txn_temp, tnx_temp_v2, tnx_subset_v3, txn_final이라는 임시 테이블을 만들었다는 것입니다 🙂 이러한 테이블은 탐색 코드에서 사용하는 것은 괜찮지만(과거를 돌아봤을 때 그 의미를 기억할 수 있다면요…) 동료들과 공유하거나 공식 데이터 파이프라인에서 사용할 경우에는 더 직관적인 이름을 붙여야 합니다. 예를 들어, txn_subset_v3는 refund_transactions와 같은 이름으로 바꾸어야 하며, 이는 무엇이 subset인지 명확하게 설명하고 transactions를 풀어 쓴 이름입니다.
같은 원칙이 열 이름에도 적용됩니다. 어제 저에게 이런 일이 발생했습니다 — 월별 생성된 케이스 수를 쿼리하고 있었고, SELECT DATE_TRUNC('month', created_at) AS created_month, COUNT(DISTINCT case_id) FROM cases GROUP BY 1 ORDER BY 1를 수행했습니다. 그러자 'created_at' does not exsits라는 오류가 발생했습니다… 자세히 살펴보니 타임스탬프 열의 이름이 created_date로 되어 있었고, 실제로는 datetime 유형이었습니다. 더 나쁜 것은 유사한 열의 이름이 다른 테이블에서는 created_at 또는 created_time 또는 created_date일 수 있다는 것입니다.
또 다른 예로는, 때때로 row_number() 윈도우 함수를 사용하여 테이블에서 파티션의 첫 번째 또는 마지막 발생을 쉽게 쿼리하기 위해 열을 추가하는 경우가 있습니다. 저는 사람들이 열 이름을 rn으로 남기는 경우를 여러 번 보았습니다. 음… 지금요? 실수번호? 등록 간호사? 비록 이것이 row_number를 의미한다고 알더라도, 여전히 기본 SQL 코드를 찾아봐야 파티션이 무엇인지, 어떤 순서로 되어 있는지를 이해할 수 있습니다. 따라서 이 열을 최종 테이블에 유지해야 한다면, row_num_by_customer_order_date_asc와 같이 설명적인 이름으로 바꾸어 주시기 바랍니다. 이 이름은 훨씬 길지만, 개인적으로는 길이가 길어도 짧고 혼란스러운 이름보다 더 낫다고 생각합니다.
테이블 간에 일관된 명명 규칙을 갖는 것도 도움이 됩니다. 예를 들어, 고객 수준의 모든 테이블은 customer_ 접두사를 사용하여 이름을 붙일 수 있습니다. 따라서 customer_demographics, customer_status, customer_signup_information 등이 있을 수 있습니다.
하지 말아야 할 것들:
- 이름이
xxx_temp,xxx_v1,xxx_final인 테이블. - 테이블 또는 열 이름의 비전통적/혼란스러운 약어.
- 같은 수준과 주제의 테이블이지만 매우 다르게 이름이 붙여진 경우 (예:
customer_demographics와status_of_customer).
해야 할 것들:
- 명확하고 설명적이며 직관적인 테이블 및 열 이름 — 길이가 긴 이름이 짧고 혼란스러운 이름보다 더 좋습니다.
- 테이블 간에 일관된 명명 규칙.
IV. 적절한 데이터 유형 및 형식
데이터를 효과적으로 저장하고 처리하기 위해서는 적절한 데이터 유형과 형식을 선택하는 것이 중요합니다. 데이터 유형은 데이터의 성격을 정의하며, 데이터 형식은 데이터가 표현되는 방식을 결정합니다.
1. 데이터 유형
- 정수형(Integer): 정수 값을 저장합니다. 예를 들어, 1, 2, 3 등이 있습니다.
- 실수형(Float): 소수점 이하를 포함한 실수 값을 저장합니다. 예를 들어, 1.5, 2.3 등이 있습니다.
- 문자형(String): 텍스트 데이터를 저장합니다. 예를 들어, “안녕하세요”와 같은 문자열이 포함됩니다.
- 불리언형(Boolean): 참(true) 또는 거짓(false)의 두 가지 상태만을 가집니다.
2. 데이터 형식
데이터 형식은 데이터가 저장되는 방식으로, 효율적인 데이터 관리를 위해 적절한 형식을 선택해야 합니다. 일반적으로 사용되는 데이터 형식은 다음과 같습니다.
- CSV(Comma-Separated Values): 데이터 값이 쉼표로 구분된 형식으로, 엑셀과 같은 프로그램에서 쉽게 열 수 있습니다.
- JSON(JavaScript Object Notation): 데이터 구조를 표현하기 위한 경량 형식으로, 다양한 프로그래밍 언어에서 쉽게 사용할 수 있습니다.
- XML(eXtensible Markup Language): 데이터의 구조와 내용을 기술하는 형식으로, 데이터의 계층적 구조를 표현합니다.
적절한 데이터 유형과 형식을 선택하는 것은 데이터의 정확성과 일관성을 유지하는 데 필수적입니다. 이를 통해 데이터 분석과 처리 과정이 보다 효율적으로 이루어질 수 있습니다.
직관적인 테이블에 관해서는 설명적인 테이블 및 열 이름뿐만 아니라 적절한 데이터 유형 및 형식도 중요합니다.
몇 가지 예를 들어보겠습니다:
- 고객의 위치, 거래의 상인 국가, 청구서 주소 국가 등과 같은 다양한 테이블에
country필드가 있다고 가정해 보겠습니다. 그러나 일부는 전체 국가 이름(United States)으로 되어 있고, 일부는 두 자리 국가 코드(US)로 되어 있으며, 일부는 소문자(us)로 되어 있습니다. 나중에 사기 탐지 모델을 구축할 때, 상인 국가와 고객의 청구서 주소 국가가 동일한지 확인하는 기능을 만들고자 하실 것입니다. 이상적으로는 간단한 조인으로 해결할 수 있지만, 이 경우 두 열의 모든 국가 값이 일관된지 확인해야 합니다. 결과적으로 많은 값을 정리하고 두 테이블을 조인하기 위해 국가 이름과 두 자리 국가 코드 매핑을 찾아야 합니다. 이는 매우 오류가 발생하기 쉬운 과정입니다. - 모두가 이진 열을 좋아합니다. 이진 열은 일반적인 세그먼트를 필터링할 때 매우 유용합니다. 그러나 저는 이진 열을
TRUE/FALSE와1/0형식으로 여기저기서 본 적이 있습니다. 더 나쁜 것은, 때때로1/0이 정수형이지만, 때때로 문자열 형식으로 되어 있습니다. 모든 값을TRUE/FALSE형식으로 일관되게 유지하는 것이 분명히 더 좋습니다. - 모든 금전적 가치 필드인
transaction_amount,delivery_fee, 또는product_price는 일관된 단위로 되어 있어야 합니다. 어떤 것은 달러로 되어 있고, 어떤 것은 센트로 되어 있다면, 이익을 100배로 계산하거나 이익이 나는 거래가 손실로 잘못 계산될 수 있습니다.
하지 말아야 할 것들 (DON’Ts):
- 유사한 열에 대해 서로 다른 데이터 유형이나 형식을 사용하지 마십시오.
해야 할 것들 (DOs):
- 적절한 데이터 유형을 사용하십시오. 예를 들어, 이진 열에 대해서는 항상
TRUE/FALSE불리언 값을 사용하고,xx_time열은 항상 날짜 및 시간 형식으로,xx_date열은 날짜 형식으로 유지하십시오. - 형식을 일관되게 유지하십시오. 예를 들어, 모든
country필드는 두 자리 국가 코드로, 모든 금전 관련 필드는 달러로 표기하십시오.
V. 완전한 문서화
완전한 문서화는 소프트웨어 개발 및 유지 관리의 중요한 부분입니다. 이에 대한 목적은 여러 측면에서 이해관계자들이 시스템을 이해하고, 사용할 수 있도록 돕는 것입니다. 문서화는 다음과 같은 요소를 포함해야 합니다:
- 시스템 아키텍처 설명
- 사용자 매뉴얼
- API 문서
- 유지 보수 가이드
각 요소는 명확하고 간결하게 작성되어야 하며, 사용자가 필요한 정보를 쉽게 찾을 수 있도록 구조화되어야 합니다. 또한, 문서화는 정기적으로 업데이트되어야 하며, 시스템 변경 사항이 반영되어야 합니다.
문서화의 중요성을 간과하지 말고, 프로젝트의 초기 단계부터 체계적으로 진행하는 것이 좋습니다.
마지막으로, 좋은 테이블은 항상 완전한 테이블 문서화가 따라옵니다. 좋은 문서는 테이블을 사용하는 모든 사람들이 그것의 목적을 이해하고 적절하게 사용할 수 있도록 보장합니다.
그런데 “완전한 테이블 문서화”를 만드는 것은 별도의 주제로, 그 자체로 글을 쓸 가치가 있을 것입니다. 하지만 제가 생각하는 핵심 요소는 다음과 같습니다:
- 테이블 설명: 이 테이블의 목적과 데이터 주제는 무엇인가요? 사람들이 이 테이블을 언제 사용해야 하나요? 테이블의 세부 수준은 어떤가요? 사용자가 염두에 두어야 할 주의 사항이 있나요?
- 열 문서화: 각 열의 데이터 유형과 의미. 열에 복잡한 계산 논리가 있는 경우, 그 논리를 설명하는 것도 중요합니다.
- 데이터 출처: 데이터는 어디에서 오는가요? 이상적인 상태에서는 데이터 사용자가 데이터 계보를 쉽게 탐색하여 상위 테이블과 열을 이해할 수 있어야 합니다. 이는 데이터 문제나 지표 변화에 대해 문제를 해결할 때 큰 도움이 됩니다.
- 빈도 및 최신성: 테이블은 얼마나 자주 업데이트되며, 마지막으로 언제 새로 고쳐졌나요?
하지 말아야 할 것들:
- 문서화가 없거나 정보가 불완전한 테이블을 생성하지 마세요;
- 테이블 논리를 업데이트할 때 문서를 오래된 상태로 유지하지 마세요.
해야 할 것들:
- 항상 완전하고 최신의 테이블 문서를 유지하세요.
이것이 데이터 동료들에게 친숙한 테이블을 만들기 위한 저의 다섯 가지 원칙입니다. 이를 따르시면 데이터 조사가 더 빨라지고, 분석이 쉬워지며, 모델이 더 정확해질 것입니다.
리스트에 추가하고 싶은 다른 사항이 있으신가요?
라인 및 막대 차트를 넘어서: 덜 일반적이지만 강력한 7가지 시각화 유형
데이터 스토리텔링 기술을 향상시키기 위한 창의적이고 통찰력 있는 시각화
towardsdatascience.com
기계 학습에서 데이터 유출의 7가지 일반적인 원인
데이터 유출을 방지하기 위한 데이터 전처리, 특성 공학 및 훈련-테스트 분할의 주요 단계
towardsdatascience.com
SQL 최적화 마스터하기: 기능적 쿼리에서 효율적인 쿼리로
매일 50시간의 Snowflake 쿼리 시간을 줄이는 데 도움이 된 6가지 간단하고 효과적인 SQL 팁
towardsdatascience.com