데이터 관계 풀기: 전통적인 방법이 실패하는 이유와 알고리즘이 유일한 해결책

Source: Dev.to

문제 개요

당신은 레거시 시스템 마이그레이션 프로젝트—ERP 클라우드 마이그레이션, 새로운 데이터 웨어하우스로의 데이터 통합—를 맡게 되었습니다.

• 문서? 존재하지 않음.
• 10년 전에 구축된 시스템을 기억하는 사람은 아무도 없음.
• 원래 팀은 이미 떠났고, 남은 것은 프로덕션 데이터베이스라는 블랙 박스뿐.

데이터 사전을 찾으려 애쓰다 보니 사전이 존재하지 않음을 알게 됩니다. 이제 혼자서 파악해야 합니다:

• 고객 마스터 테이블은 어느 것인가?
• 주문은 제품과 어떻게 연결되는가?
• ref_ 접두사가 붙은 필드들은 도대체 무엇을 가리키는가?

일주일이 지나 50개 테이블의 관계를 간신히 매핑했습니다. 하지만 시스템에는 2,000개가 존재하고, 비즈니스 팀은 곧바로 실시간 가동을 요구하고 있습니다.

당신은 생각하게 됩니다: 2026년에 왜 아직도 데이터 관계를 이해하기 위해 원시적인 방법을 사용하고 있는가?

이것은 가상의 시나리오가 아니라 데이터 엔지니어링의 일상적인 현실입니다.
근본 원인은 기술이 아니라, 데이터 관계에 대한 우리의 이해가 여전히 수동적인 시대에 머물러 있기 때문입니다.

Source: …

핵심 문제: 조직 지식 상실

핵심 팀원이 떠나면 시스템 간의 암묵적인 연결도 함께 사라집니다—이는 기술 문제가 아니라 조직 지식이 사라지는 문제입니다.

전통적인 세 가지 해결책 (그리고 왜 부족한가)

1. 문서 탐색
   레거시 시스템에는 문서가 전혀 없거나, 10년 전식 문서만 존재합니다. 데이터 자체가 아니라 구식 종이 기억에 의존하고 있는 셈입니다.

2. 주제 전문가(SME)에게 문의
   SME가 재직 중일 때는 관계가 그들의 머리 속에만 존재합니다. 그들이 떠나면 조직적 기억 상실은 불가피합니다. 인간 기억은 신뢰할 수 없으며, 지식 전달은 고통스럽게 비효율적입니다.

3. 코드 역공학
   비즈니스 로직은 종종 저장 프로시저, ETL 스크립트, 혹은 애플리케이션 코드에 하드코딩되어 있어 테이블 스키마만으로는 추론할 수 없습니다.

이번에 매핑을 제대로 해도, 비즈니스가 변하면 어떻게 될까요?
모든 것을 다시 수동으로 매핑해야 할까요? 유지보수 비용이 기하급수적으로 상승합니다.

핵심 갈등: 데이터 관계는 비즈니스 요구에 따라 동적으로 진화하지만, 이를 파악하는 우리의 방법은 여전히 정적이고 수동적입니다.

왜 “필드 이름 추측”은 실패할 운명인가

전통적인 방법들의 핵심 가정은 필드 명명이 일관적이다는 것이다 (예: customer_id는 customer 테이블을 가리켜야 한다). 현실 세계는 이러한 규칙을 따르지 않는다:

• cust_ref, cust_id, 그리고 customer_no가 모두 같은 테이블을 참조할 수 있다.
• 같은 필드 이름이 시스템마다 전혀 다른 의미를 가질 수 있다.
• 많은 관계에 외래키 제약이 없거나, 제약이 비활성화되어 있다.
• 시스템이 시간이 지나면서 진화함에 따라 필드 명명은 혼란스러워진다.

정규식 매칭과 규칙 엔진을 사용해 추측하려 해도 정확도가 실용적인 수준에 도달하지 못한다. 왜일까?

왜냐하면 구문으로부터 의미를 추론하려 하고 있기 때문이다—그리고 데이터만이 의미를 진정으로 전달하는 매개체이다.

필드의 실제 의미는 이름에 있는 것이 아니라 실제로 저장된 값에 있다.

orders 테이블의 customer_ref와 customer 테이블의 cust_id가 연관되어 있는가?
값 범위를 비교해 보라—orders의 모든 customer_ref가 customer.cust_id에 존재한다면, 이름과 관계없이 그것은 실제 관계이다.

Source: …

알고리즘‑구동형: “이름 추측”에서 “콘텐츠 분석”으로

포함 관계(Containment Relationships): 마스터 테이블 식별

가장 일반적인 관계는 일대다입니다: 주문의 customer_id는 항상 고객 마스터 테이블의 부분집합입니다.

알고리즘(단순 버전):

1. orders 테이블에서 customer_id의 고유 집합을 계산 → Set A.
2. customer 테이블에서 id의 고유 집합을 계산 → Set B.
3. Set A 중 Set B에 존재하는 비율을 측정 → 포함 비율.

• 포함 비율 ≥ 90 % → 강한 관계.
• 포함 비율 = 100 % → 완전 포함, 자동 병합 가능.

이제 필드 이름에 신경 쓰지 않아도 됩니다. 알고리즘이 Table A의 Field X가 Table B의 Field Y의 부분집합임을 알려주고 관계를 자동으로 구축합니다.

동등 관계(Identical Entities): 같은 대상을 위한 다른 라벨 찾기

두 테이블이 정확히 같은 엔터티를 저장하지만 필드 이름이 완전히 다를 때가 있습니다. 예시:

알고리즘은 양방향 포함 비율을 확인하고 거의 완벽한 겹침을 감지하여 자동으로 연결합니다.

결과: 명명 규칙이 달라도 시스템 간 통합이 쉬워집니다.

계층 패턴: 차원 모델링 간소화

일부 관계는 직접적인 것이 아니라 계층적입니다. 예시:

• 부서 코드: 01.01.003
• 팀 코드: 01.01.003.001

코드 구조를 분석함으로써 알고리즘은 계층적 종속성을 찾아내고 차원 모델링을 간소화합니다—예전에는 수동 검증이 필요했지만 이제는 완전 자동화됩니다.

관계 정량화: “직감”에서 확실한 지표로

전통적인 방법은 정량화가 불가능합니다: 두 테이블이 관련 있다고 생각하지만 얼마나 강하게 연결되는지는 말할 수 없습니다.

Arisyn은 네 차원 평가 프레임워크를 도입합니다:

1. 마스터 테이블의 고유 레코드 수.
2. 포함된 테이블의 고유 레코드 수.
3. 동시 발생 빈도(값이 함께 나타나는 횟수).
4. 포함 비율(포함된 값이 마스터에 존재하는 비율).

이 메트릭은 막연한 직감을 구체적이고 비교 가능한 수치로 전환하여, 어떤 관계를 신뢰하고, 리팩터링하고, 폐기할지에 대한 데이터 기반 결정을 가능하게 합니다.

요점

추측을 멈추세요.
측정을 시작하세요.

metadata‑centric에서 data‑centric 분석으로 전환함으로써, 가장 복잡한 레거시 환경에서도 데이터 관계를 자동으로 발견하고, 검증하며, 유지할 수 있습니다. 이는 새로운 엔지니어의 온보딩 시간을 크게 단축시킬 뿐만 아니라, 비즈니스 변화의 불가피한 변동에도 데이터 아키텍처를 미래에도 견고하게 만들어 줍니다.

세션 비율 (핵심 지표)

관계는 더 이상 주관적인 “직감”이 아니라 객관적이고 가중된 메트릭입니다.

엔지니어링 팀에게 이는 자동화 규칙을 의미합니다:

• ≥ 90 % 비율을 가진 관계는 데이터 그래프에 자동으로 추가됩니다.
• 비율이 낮은 관계는 수동 검토를 위해 표시됩니다.

Arisyn은 클라우드 네이티브 아키텍처 위에 구축되어 고동시성, 저지연 실시간 컴퓨팅을 지원하며, 관계 탐지를 몇 분 안에 완료합니다.

데이터 엔지니어 관점에서의 가치

“이게 정말 수작업보다 나은가?”

데이터 엔지니어에게는 그 혜택이 부인할 수 없습니다:

• 효율성 – 몇 주/몇 달에서 몇 분/몇 시간으로, 획기적인 도약.
• 정확성 – 데이터 내용에 기반한 객관적인 판단으로, 인간의 기억 오류와 누락을 제거.
• 유지보수성 – 데이터 변경에 대한 자동 증분 업데이트 – 수동 동기화가 필요 없음.
• 확장성 – 10개의 테이블에서 2,000개로 확장해도 알고리즘 복잡도는 관리 가능하며, 볼륨이 선형적으로 증가함에 따라 수작업은 실행 불가능해짐.

가장 중요한 점은, 몇몇 전문가에 의존하던 병목 모델에서 재현 가능한 알고리즘을 갖춘 엔지니어링 모델로 전환한다는 것입니다. 데이터 역량이 더 이상 시니어 팀원의 “비밀 소스”가 아니라, 확장 가능하고 표준화된 인프라가 됩니다.

결론

데이터 관계 탐지는 새로운 문제는 아니지만, 우리는 20 년 동안 어려운 방법으로 해결해 왔습니다.

기술 진화는 기존 도구를 더 빠르게 만드는 것에서 오지 않으며, 패러다임 전환에서 비롯됩니다.
마차에서 증기 기관으로 이동하는 것처럼, 더 좋은 말에 관한 것이 아니라 완전히 새로운 동력원에 관한 것입니다.

알고리즘 기반 데이터 관계 탐지는 근본적으로 인간 경험에 기반한 데이터 이해에서 데이터와 알고리즘에 기반한 이해로의 전환입니다. 이는 단순한 효율성 향상이 아니라 조직 역량의 진화입니다.

데이터 관계를 블랙 박스에서 화이트 박스로, 암묵적에서 명시적으로, 정량화 불가능에서 측정 가능으로 전환할 때, 데이터는 부담이 아니라 진정한 자산이 됩니다.

데이터 엔지니어링은 아직도 긴 여정이 남아 있지만, 이 중요한 단계에서 우리는 마침내 수동 시대를 떠나고 있습니다.