이 글은 어느 회사의 규칙을 그대로 옮겨 온 것이 아닙니다. 반도체·디스플레이 같은 제조(FAB) 현장의 데이터를 다루면서 오라클 ETL과 데이터마트 일을 오래 했고, 여러 프로젝트를 겪으며 저 나름대로 자리 잡은 원칙들을 정리한 글입니다. 꼭 맞는 정답이라기보다는 "이렇게 안 했다가 나중에 고생했던 경험"을 모아 둔 것에 가깝습니다.
오라클로 큰 데이터마트나 시스템끼리 데이터를 주고받는 인터페이스를 만들다 보면, 처음엔 별것 아닌 것 같던 이름 짓는 규칙 하나가 몇 달 뒤 관리할 때 얼마나 큰 차이를 만드는지 크게 느끼게 됩니다. SQL 문법을 알려 주는 글이나 정규화 이론을 설명하는 글은 많습니다. 하지만 "여러 시스템을 몇 년 동안 맡으면서 왜 이런 규칙을 지키게 됐는지"를 실제 경험 위주로 풀어 쓴 글은 비교적 적은 것 같아서 한번 정리해 봅니다.
돌이켜 보면 신입 때는 "이름이야 알아보기만 하면 되는 거 아닌가" 하고 가볍게 생각했습니다. 그런데 여러 시스템의 인터페이스를 오래 맡다 보니, 장애가 나거나 데이터가 꼬였을 때 원인을 빨리 찾아내는 힘의 상당 부분이 "스키마(테이블 구조)를 얼마나 예상 가능하게 만들어 두었는가"에서 나온다는 걸 알게 됐습니다. 멋진 성능 튜닝 기술보다 이런 기본 틀이 실제 업무에서는 훨씬 오래, 훨씬 자주 도움이 됐습니다.
이름 짓는 규칙 — 별것 아닌 것 같지만 나중에 후회하지 않으려고 지키는 것들
가장 먼저 자리 잡은 원칙은 "컬럼 이름에 줄임말을 쓰지 않는다"였습니다. 처음에는 타자 치기가 귀찮아서 EQP_NM, PRC_STEP처럼 줄여 쓴 이름을 자주 썼습니다. 그런데 몇 달 뒤 다른 담당자가 이 테이블들을 넘겨받았는데, EQP가 설비(Equipment)라는 뜻인지 다른 뜻인지 헷갈려 하는 걸 보고 생각이 바뀌었습니다. 그 뒤로는 이름이 좀 길어지더라도 EQUIPMENT_NAME, PROCESS_STEP처럼 줄이지 않고 다 쓰기로 했습니다. 처음 만드는 사람에게는 귀찮은 습관이지만, 이 구조를 처음 보는 사람은 따로 문서를 보지 않아도 뜻을 짐작할 수 있습니다. 그래서 길게 보면 훨씬 남는 장사였습니다.
두 번째는 이름 끝에 붙이는 글자(접미사) 규칙을 항상 똑같이 지키는 것이었습니다. 저는 컬럼이 어떤 성격인지에 따라 아래처럼 끝에 붙이는 글자를 습관처럼 정해 둡니다.
- _CD : 코드 값 (예: EQUIPMENT_STATUS_CD)
- _YN : Y 또는 N만 들어가는 표시 값 (예: USE_YN, DELETE_YN)
- _ID : 하나하나를 구별하는 번호 (예: LOT_ID, EQUIPMENT_ID)
- _DATE : 날짜나 시각 (예: PROCESS_START_DATE)
이 규칙이 왜 중요한지는 끝에 아무것도 안 붙은 컬럼을 만났을 때 뼈저리게 알게 됩니다. 예를 들어 STATUS라는 컬럼만 달랑 있으면, 이게 코드 값인지 글자인지, Y/N인지, 심지어 날짜 형태로 된 상태 기록인지 이름만 봐서는 전혀 알 수 없습니다. 반대로 STATUS_CD라고만 되어 있어도 "아, 이건 코드 테이블이랑 연결(조인)해서 봐야겠구나" 하고 바로 판단이 됩니다. 이 규칙 하나가 쿼리를 짜는 속도를 높이고 실수를 줄이는 데 생각보다 큰 역할을 했습니다.
세 번째는 테이블을 종류별로 묶어 주는 글자를 이름 앞이나 뒤에 붙이는 것입니다. 서로 관련 있는 테이블을 이름만 보고도 한눈에 묶어서 알아볼 수 있게 하려는 겁니다. 예를 들어 기준 정보를 담는 마스터 테이블은 _M, 그때그때 생기는 거래·작업 기록 테이블은 _T, 바뀐 내역을 쌓아 두는 이력 테이블은 _H처럼 종류를 확실히 나눕니다. 테이블이 수백 개가 넘는 큰 구조에서는 이런 규칙이 없으면, 특정 업무와 관련된 테이블을 찾는 데만 한참을 헤매게 됩니다.
테이블 구조를 만들면서 실제로 부딪혔던 문제들
이름 짓는 규칙만큼이나, 테이블 구조 자체를 만들면서 겪은 시행착오도 많았습니다.
1) 대체 키 없이 업무용 값만 기본키로 썼다가 고생한 일. 초기 프로젝트에서는 설비 코드나 랏(LOT) 번호처럼 업무에서 원래 쓰는 값(자연키)을 그대로 기본키로 썼습니다. 처음엔 아무 문제가 없었습니다. 그런데 나중에 조직이 바뀌면서 설비 코드 체계가 달라졌고, 이미 쌓여 있던 데이터의 기본키를 전부 옮기고 바꿔야 하는 큰 작업이 생겼습니다. 그 뒤로는 업무 규칙에 따라 바뀔 수 있는 값이라면 꼭 따로 대체 키(서러게이트 키, 시퀀스로 만든 ID)를 두고, 업무용 값은 중복만 막는 유니크 제약으로 관리하는 걸 기본 원칙으로 삼았습니다.
2) 이력 테이블을 나중에 붙이려다 고생한 일. 처음에는 "지금 상태만 알면 되겠지" 하고 생각해서, 마스터 테이블에 상태 컬럼 하나만 두고 바뀐 내역은 따로 남기지 않았습니다. 그런데 몇 달 뒤 "특정 날짜에 이 설비가 어떤 상태였는지 알고 싶다"는 분석 요청이 들어왔습니다. 하지만 예전 값은 이미 새 값으로 덮어써져서 되살릴 방법이 없었습니다. 그 뒤로는 상태 값이 바뀔 수 있는 테이블이라면 처음 설계할 때부터 이력 테이블(_H)을 같이 만들고, 트리거나 프로그램 쪽에서 값이 바뀔 때마다 기록이 남도록 기본 구조에 넣어 두었습니다.
3) 파티션을 나중에 적용하려다 겪은 부담. 데이터가 적을 때 파티션(큰 테이블을 날짜 등 기준으로 나눠 저장하는 방식) 없이 만들었던 로그성 테이블이 있었습니다. 데이터가 수억 건씩 쌓이자 조회 속도가 확 느려졌습니다. 이미 쌓인 데이터에 파티션을 새로 적용하려면 테이블을 다시 만드는 작업을 피할 수 없었고, 서비스에 영향을 최대한 덜 주면서 이 작업을 하느라 꽤 많은 시간을 썼습니다. 그 뒤로는 하루에 수십만 건 이상 쌓일 것 같은 테이블은 처음 설계할 때부터 날짜 기준으로 나누는 range 파티션을 기본으로 깔고 시작하는 걸 원칙으로 삼았습니다.
4) 코드 값의 뜻을 여기저기 글로만 적어 두었던 문제. 처음에는 EQUIPMENT_STATUS_CD 같은 코드 값의 뜻(예: 1=가동 중, 2=정지, 3=점검)을 프로그램 주석이나 문서에만 적어 두었습니다. 시간이 지나면서 코드 값의 뜻이 조금씩 바뀌거나 새 코드가 추가될 때마다, 문서 내용과 실제 데이터가 서로 안 맞는 일이 계속 생겼습니다. 그 뒤로는 반드시 공통 코드를 관리하는 테이블을 따로 두고, 코드 값과 코드 이름, 사용 여부를 DB 안에서 함께 관리하도록 구조를 바꿨습니다.
노하우 체크리스트 — 이렇게 안 했으면 나중에 고생했을 것들
여러 프로젝트를 거치면서 정리된 체크리스트를 나눠 보겠습니다.
컬럼 순서도 항상 같은 규칙으로 둔다. 구별용 번호(식별자) 컬럼은 맨 앞에, 업무 내용 컬럼은 가운데에, 만든 날짜·고친 날짜·만든 사람·고친 사람 같은 공통 관리용 컬럼은 맨 뒤에 두는 규칙을 모든 테이블에 똑같이 적용합니다. 이것만 지켜도 처음 보는 테이블의 구조를 알아보는 속도가 눈에 띄게 빨라집니다.
모든 테이블과 중요한 컬럼에 설명(COMMENT)을 달아 둔다. 오라클에서는 COMMENT ON TABLE, COMMENT ON COLUMN 명령으로 테이블과 컬럼에 설명을 붙일 수 있습니다. 이걸 습관으로 만들지 않으면 결국 따로 만든 문서에만 기대게 되고, 시간이 지나면서 문서 내용과 실제 테이블 구조가 서로 달라집니다. 그래서 데이터 사전(데이터 딕셔너리)만 조회해도 뜻을 알 수 있도록, 설명을 테이블 구조 자체에 남기는 걸 원칙으로 하고 있습니다.
예약어나 예약어와 헷갈리는 이름은 처음부터 쓰지 않는다. DATE, LEVEL, COMMENT처럼 오라클이 미리 정해 둔 단어(예약어)나 그와 비슷한 이름을 컬럼 이름으로 쓰면, 당장은 괜찮아 보여도 나중에 특정 버전이나 도구에서 생각지도 못한 오류가 나는 일을 몇 번 겪었습니다. 그 뒤로는 예약어 목록을 팀 규칙 문서에 적어 두고, 검토 단계에서 함께 확인합니다.
새 테이블을 만들 때는 꼭 체크리스트를 거친다. 대체 키가 필요한지, 이력 관리가 필요한지, 데이터가 얼마나 늘어날지와 그에 따라 파티션이 필요한지, 코드 컬럼을 공통 코드 테이블과 연결해야 하는지. 이 네 가지만이라도 설계 초기에 확인하는 걸 팀 규칙으로 만들어 두었더니, 나중에 구조를 통째로 뒤엎는 일이 크게 줄었습니다.
규칙 문서는 만들어 두는 것보다 검토 단계에서 실제로 지키게 하는 게 핵심이다. 규칙 문서를 아무리 잘 정리해 둬도, 새 테이블을 만들 때마다 그 문서를 찾아보고 지키는 사람은 생각보다 많지 않았습니다. 그래서 저희 팀은 새 테이블을 만들 때 간단한 체크리스트를 코드 리뷰(또는 테이블 생성문 DDL 리뷰) 과정에 넣었습니다. 사람의 기억에 기대지 않아도 규칙이 지켜지도록, 일하는 절차 자체에 규칙을 넣은 겁니다. 이렇게 바꾼 뒤로 규칙을 어기는 경우가 눈에 띄게 줄었습니다.
한마디로 정리하면, 이름 짓는 규칙과 테이블 구조 설계 원칙은 멋진 기술이 아닙니다. "나중에 이 일을 맡을 사람(대부분은 미래의 나 자신)을 덜 고생시키기 위한 최소한의 배려"에 가깝습니다. 지금은 귀찮게 느껴져도, 몇 달 또는 몇 년 뒤에 그 선택이 얼마나 큰 차이를 만드는지는 실제로 관리를 해 봐야 몸으로 느낄 수 있습니다.
규칙 하나하나는 별것 아닌 것처럼 보입니다. 하지만 이런 것들이 꾸준히 쌓여서, 시스템이 몇 년이 지나도 "누가 봐도 이해할 수 있는 구조"로 남을지, 아니면 담당자가 바뀔 때마다 처음부터 다시 파악해야 하는 구조로 남을지가 갈린다고 생각합니다. 다음 글에서는 이런 원칙들을 실제로 팀 규칙 문서로 어떻게 정리했는지, 그리고 검토 과정에 어떻게 넣었는지를 예시와 함께 더 자세히 다뤄 보겠습니다.