💡 핵심 인사이트
데이터 역엔지니어링은 10년 전에 구축되어 설계 도면(ERD)은 불타 없어지고 오직 기계적인 '물리적 DB(오라클, MySQL)'만 덩그러니 남아있는 끔찍한 레거시 시스템에 침투하여, 그 껍데기(테이블 구조)를 분해하고 역추적하여 인간이 이해할 수 있는 아름다운 '개념적 ERD 도면'을 다시 그려내는 리버스(거꾸로) 복원 작업입니다.

Ⅰ. 역엔지니어링이 필요한 처참한 현실

집을 지을 때는 도면 ➔ 시멘트 공사 순으로 갑니다 (순공학, Forward Engineering). 하지만 현업 IT 부서에 입사해 보면 참담한 광경이 펼쳐집니다.

• 도면의 실종: 10년 전에 퇴사한 개발자가 짠 사내 ERP 시스템의 DB가 있습니다. 그런데 어떤 테이블이 부모이고 어떤 게 자식인지 그려놓은 ER 다이어그램이나 명세서 문서가 단 한 장도 없습니다.
• 블랙박스화: 심지어 외래 키(FK) 제약조건도 안 걸어놓고 앱단에서 꼼수로 조인해 쓰고 있어서, 테이블들끼리 무슨 관계인지 전혀 알 길이 없습니다.
• 이 상황에서 "DB 서버 클라우드로 이관해!"라는 명령이 떨어지면? 엔지니어는 시스템을 통째로 날려 먹을 공포에 휩싸입니다. 이때 구원 투수로 투입되는 기법이 바로 '데이터 역엔지니어링'입니다.

Ⅱ. 역엔지니어링의 3단계 복원 프로세스

ERwin이나 DA# 같은 자동화 CASE 툴(Tool)을 켜고 DB의 주소를 찔러 넣어(리버스 엔지니어링 버튼 클릭) 역산을 시작합니다.

1단계: 물리적 모델 추출 (DB ➔ 표)

• 툴이 실제 운영 중인 Oracle/MySQL 데이터베이스의 시스템 카탈로그(데이터 딕셔너리)를 긁어옵니다.
• CREATE TABLE 문법 속에 흩어져 있던 컬럼 이름, 데이터 타입, 설정된 PK/FK 제약조건들을 추출하여 눈에 보이는 표(물리 모델)로 화면에 뿌려줍니다.

2단계: 논리적 모델 복원 (표 ➔ 숨겨진 관계 파악)

• 가장 고통스럽고 인간의 뇌가 필요한 단계입니다.
• 개발자가 FK를 안 걸어놨기 때문에 툴이 선을 제대로 이어주지 못합니다.
• DBA는 수만 건의 실제 데이터 덤프를 까보고 쿼리 로그를 뒤져가며, "아! A 테이블의 dept_id와 B 테이블의 d_code가 이름은 다르지만 사실 같은 부서 코드를 의미하고, 둘이 1:N 관계로 물려 돌아가는구나!"라는 숨겨진 함수적 종속성과 비즈니스 로직(연결선)을 역으로 추리하여 끊어진 논리적 선(관계)을 이어나갑니다.

3단계: 개념적 모델(ERD) 완성 (논리 ➔ 스케치)

• 복원된 깐깐한 테이블 뼈대들을 뭉뚱그려, 비개발자(사장님)도 이해할 수 있는 큼직한 네모(개체)와 마름모(관계)로 추상화시킨 최종 ER 다이어그램(개념 스키마) 도면을 완성해 냅니다.

Ⅲ. 역엔지니어링의 목적

왜 이 미친 노가다를 할까요?

• 시스템 차세대 마이그레이션: 낡은 오라클 DB를 버리고 AWS 클라우드 DB로 이사 가기 위해, 현재 집의 구조를 100% 파악해야 부수고 똑같이 새로 지을 수 있기 때문입니다.
• 데이터 거버넌스 확립: 썩어가는 테이블 구조를 눈으로 파악(가시성 확보)하여, 쓸데없는 중복 데이터를 쳐내고 마스터 데이터(MDM)를 구축하는 기초 공사로 삼기 위함입니다.

📢 섹션 요약 비유: 데이터 역엔지니어링은 외계인이 남기고 간 **'추락한 UFO 구조 역추적(리버스 엔지니어링)'**입니다. 설계도 한 장 없이 덩그러니 놓인 비행 접시(물리적 DB)를 공학자들이 렌치로 일일이 분해하면서, "이 파이프는 엔진과 연결된 걸 보니 연료관(외래 키)이군!" 하고 구조를 짐작한 뒤, 마침내 화이트보드에 '외계인 UFO의 3D 완벽 설계 도면(개념적 ERD)'을 인간의 손으로 다시 그려내어, 우리 기술로 새로운 UFO(차세대 시스템)를 찍어낼 수 있게 만드는 고도의 해체/복원 작업입니다.