이 글은 특정 회사의 표준을 그대로 옮긴 게 아니라, 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) 서러게이트 키(대체키) 없이 자연키만으로 설계했다가 고생한 경험. 초창기 프로젝트에서는 설비 코드나 랏 번호 같은 업무상 자연키를 그대로 기본키로 썼습니다. 처음엔 문제가 없었는데, 나중에 설비 코드 체계가 조직 개편으로 바뀌면서 이미 쌓인 데이터의 기본키를 전부 마이그레이션해야 하는 대형 작업이 벌어졌습니다. 이후로는 업무 규칙이 바뀔 가능성이 있는 값은 반드시 별도의 서러게이트 키(시퀀스 기반 ID)를 두고, 자연키는 유니크 제약으로만 관리하는 방식을 기본 원칙으로 삼게 됐습니다. 2) 이력 테이블 설계를 나중에 추가하려다가 고생한 경험. 처음엔 "현재 상태만 있으면 되겠지"라고 생각해서 마스터 테이블에 상태 컬럼만 두고 이력은 따로 관리하지 않았습니다. 그런데 몇 달 뒤 "특정 시점에 이 설비 상태가 어땠는지 알고 싶다"는 분석 요구가 들어왔고, 이미 과거 이력은 덮어써져서 복구가 불가능했습니다. 이후부터는 상태값이 변경될 가능성이 있는 테이블은 설계 초기 단계부터 이력 테이블(_H 접미사)을 함께 만들고, 트리거나 애플리케이션 레벨에서 변경 시점마다 이력을 남기도록 기본 구조에 포함시켰습니다. 3) 파티셔닝을 나중에 적용하려다가 겪은 부담. 데이터가 적을 때 파티션 없이 설계했던 대용량 로그성 테이블이, 데이터가 수억 건 단위로 쌓이면서 조회 성능이 급격히 나빠진 적이 있었습니다. 이미 쌓인 데이터에 파티션을 새로 적용하려면 테이블 재구성 작업이 불가피했고, 서비스 영향을 최소화하면서 이 작업을 하느라 상당한 시간을 썼습니다. 이후로는 하루에 수십만 건 이상 쌓일 가능성이 있는 테이블은 설계 단계에서부터 날짜 기준 range 파티션을 기본으로 깔고 시작하는 걸 원칙으로 삼았습니다. 4) 코드성 데이터를 컬럼 안에 텍스트로 흩어놓았던 문제. 초반에는 EQUIPMENT_STATUS_CD 같은 코드값의 의미(예: 1=가동중, 2=정지, 3=점검)를 코드 안 주석이나 문서에만 적어뒀는데, 시간이 지나면서 코드값 의미가 조금씩 바뀌거나 새로운 코드가 추가될 때마다 문서와 실제 데이터가 어긋나는 일이 반복됐습니다. 이후로는 반드시 별도의 공통 코드 관리 테이블을 두고, 코드값과 코드명, 사용 여부를 DB 레벨에서 함께 관리하도록 구조를 바꿨습니다. 노하우 체크리스트 — 이렇게 안 했으면 나중에 고생했을 것들 여러 프로젝트를 거치며 정리된 체크리스트를 공유합니다. 컬럼 순서에도 일관된 규칙을 둔다. 식별자 컬럼을 맨 앞에, 업무 컬럼들을 중간에, 생성일시·수정일시·생성자·수정자 같은 공통 관리 컬럼을 맨 뒤에 배치하는 규칙을 모든 테이블에 동일하게 적용합니다. 이렇게만 해도 처음 보는 테이블의 구조를 파악하는 속도가 확연히 빨라집니다. 모든 테이블과 주요 컬럼에 코멘트(COMMENT)를 남긴다. 오라클은 COMMENT ON TABLE, COMMENT ON COLUMN 구문으로 테이블과 컬럼에 설명을 붙일 수 있는데, 이걸 습관화하지 않으면 결국 별도 문서에만 의존하게 되고 시간이 지나면서 문서와 실제 스키마가 어긋납니다. 데이터 딕셔너리 조회만으로 의미를 파악할 수 있도록 코멘트를 스키마 자체에 남기는 걸 원칙으로 삼고 있습니다. 예약어와 헷갈리는 이름은 애초에 피한다. DATE, LEVEL, COMMENT 같은 오라클 예약어나 그와 유사한 이름을 컬럼명으로 쓰면 당장은 문제없어 보여도, 이후 특정 버전이나 도구에서 예기치 못한 오류가 나는 경우를 몇 번 겪었습니다. 이후로는 예약어 목록을 팀 컨벤션 문서에 명시해두고 리뷰 단계에서 함께 체크합니다. 신규 테이블 설계 시 반드시 체크리스트를 거친다. 서러게이트 키 필요 여부, 이력 관리 필요 여부, 예상 데이터 증가량과 파티셔닝 필요 여부, 코드성 컬럼의 공통 코드 테이블 연계 여부까지, 이 네 가지만이라도 설계 초기에 확인하는 걸 팀 내 규칙으로 만들어두니 나중에 구조를 뒤엎는 일이 크게 줄었습니다. 컨벤션 문서는 만들어두는 것보다 실제로 리뷰 단계에서 강제하는 게 핵심입니다. 컨벤션 문서를 아무리 잘 정리해둬도, 신규 테이블이 추가될 때마다 그 문서를 찾아보고 지키는 사람은 생각보다 많지 않았습니다. 결국 저희 팀에서는 신규 테이블 생성 시 간단한 체크리스트를 코드 리뷰(또는 DDL 리뷰) 절차에 넣어서, 사람이 기억에 의존하지 않고도 규칙이 지켜지도록 프로세스 자체에 강제성을 부여했습니다. 이 변화 이후로 컨벤션 위반 사례가 눈에 띄게 줄었습니다.
정리하자면, 네이밍 컨벤션과 스키마 설계 원칙은 화려한 기술이 아니라 "미래의 담당자(대부분은 미래의 나 자신)를 덜 고생시키기 위한 최소한의 배려"에 가깝습니다. 당장은 번거롭게 느껴져도, 몇 달 혹은 몇 년 뒤에 그 선택이 얼마나 큰 차이를 만드는지는 실제로 유지보수를 해봐야 체감할 수 있습니다.
규칙 하나하나는 사소해 보이지만, 이런 것들이 꾸준히 쌓여서 결국 시스템이 몇 년이 지나도 "누가 봐도 이해할 수 있는 구조"로 남는지, 아니면 담당자가 바뀔 때마다 매번 처음부터 다시 파악해야 하는 구조로 남는지가 결국 갈린다고 생각합니다. 다음 글에서는 이런 원칙들을 실제로 어떻게 팀 컨벤션 문서로 정리하고, 리뷰 프로세스에 녹여냈는지를 예시와 함께 좀 더 구체적으로 다뤄보겠습니다.