DB 스키마만으로 외주 시스템을 내재화한 리빌딩 여정

게시 2025/05/22 업데이트 2026/10/01

By August

조회 8 분 읽는 시간

외주 개발로 운영되던 시스템을 완전히 내재화했던 경험을 정리합니다. API 명세서나 코드 없이 DB 스키마와 일부 데이터만 존재하는 상태에서 시작한 프로젝트였습니다. 그래서 기존 구조를 그대로 옮기는 마이그레이션이 아니라, 스키마 재설계부터 서비스 안정화까지 다시 만드는 작업이 되었습니다.

프로젝트 배경

기존 시스템은 수년간 외주사에서 개발·운영되어 왔고, 다음과 같은 문제를 안고 있었습니다.

문서 부재: API 명세, 기능 흐름, ERD(테이블과 관계를 그린 개체-관계 다이어그램) 등 존재하지 않음
기능 불확실: 담당자 이탈로 업무 흐름이 단절됨
운영 불안정: 단일 서버 운영, 예외 처리 미흡, 장애 대응 부재

하지만 서비스는 여전히 핵심 업무와 밀접했고, 기술 내재화와 품질 향상을 위해 시스템 전면 재구축을 결정했습니다.

1단계: 데이터 리버스 엔지니어링

우리가 가진 건 DB 접속 권한과 일부 데이터 덤프뿐이었습니다. 그래서 첫 단계는 데이터에서 구조와 규칙을 거꾸로 읽어내는 리버스 엔지니어링이었습니다.

주요 작업

ERD 자동 생성 도구 활용 (ex. DBeaver, SchemaSpy)
데이터 패턴 분석: 테이블 간 참조, enum 유추, 날짜/금액 필드 탐색
SQL 로그 분석 (가능할 경우 외주 시스템의 DB접속 로그 확보)

직면한 이슈

암묵적 외래키 사용: FK 제약 조건 없이 조인되는 테이블.
중복/불필요한 컬럼: 동일한 의미의 컬럼이 다수 테이블에 흩어짐
이상한 명명 규칙: cd_01, val_03 등 직관성이 떨어지는 컬럼명

2단계: 스키마 전면 재설계

기존 테이블을 그대로 복사하지 않고 업무 도메인 중심의 설계로 전환했습니다.

리디자인 전략

도메인 중심 패키징 (DDD-lite):
- 회원, 상품, 계약, 정산 등 명확한 bounded context(용어와 규칙이 하나로 통하는 업무 경계)로 테이블 분리
공통 Entity 정리:
- BaseEntity, EnumType, AuditLog 등 재사용 가능한 구조화
정규화 vs 성능 최적화의 균형:
- 자주 조회되는 목록 테이블은 중복 허용한 비정규화 테이블로 분리

검증 방법

샘플 데이터를 기준으로 정합성 검증 SQL 작성
이전 시스템과의 동작 결과 비교 (조회 결과, 계산 값, 업무 처리 흐름 등)

3단계: 기능 복원 및 현대화

새 스키마를 바탕으로 실제 기능을 복원해야 했습니다. 코드가 없으므로 기능은 남은 데이터와 화면, 운영자의 설명에서 거꾸로 추론했습니다.

복원 방식

DB에 남은 이력 데이터로 유추한 프로세스 흐름
프론트 화면 캡처본/운영자 설명을 바탕으로 추론
RESTful API로 재설계: 기존 SOAP 또는 단일 페이지 POST 방식 제거

기술 스택 전환

Spring Boot 기반 백엔드
JPA + QueryDSL로 쿼리 추상화
Vue.js 기반 SPA(단일 페이지 애플리케이션) 프론트엔드 구성
Swagger + 테스트 시나리오로 명세 문서화

4단계: 테스트, 운영 전환, 정합성 확보

테스트 전략

데이터 정합성 비교 스크립트 작성
- 예: 특정 계약번호에 대한 이전/이후 정산 금액 비교
사용자 피드백 기반 QA
- 기능 단위별로 운영자가 직접 시나리오 수행

운영 안정화 조치

트랜잭션 재설계: 필요한 경우 @TransactionalEventListener로 후속 처리를 분리. 이 리스너는 트랜잭션 단계에 맞춰 호출되고 기본 단계는 AFTER_COMMIT이므로(Spring Javadoc), 후속 처리는 커밋 이후로 밀려납니다.
장애 대응 로깅 체계 도입: Filebeat + Elasticsearch + Kibana (로그 수집 체계 개선)
스케줄러/배치 튜닝: 작업 내역을 로그 단위로 트래킹 가능하게 구현

결과 및 회고

항목	내재화 이전	내재화 이후
운영 주체	외주	내부 개발팀
장애 대응	외주사 요청	실시간 대응
기능 변경	최소 1~2주	하루 내 반영 가능
문서화	없음	ERD, Swagger, 시나리오 테스트 완비

회고

코드가 없을 때는 데이터가 기능을 판단하는 근거였습니다. 이력 데이터와 값의 패턴에서 업무 규칙을 읽어냈습니다.
기존 구조를 그대로 포워딩하는 방식으로는 재설계할 수 없었습니다. 도메인을 이해하고 재해석해야 했습니다.
외주 시절 구조에 묶이지 않고 불필요한 부분을 삭제한 뒤 비즈니스 중심으로 구조를 재편했습니다.

마무리하며

이 프로젝트는 코드와 문서 없이 데이터만 남은 상태에서 시작했습니다. 그래도 스키마와 이력 데이터를 분석하고 도메인을 해석해서, 내부 팀이 운영하고 문서화된 시스템으로 다시 만들 수 있었습니다.

참고

Spring Framework Javadoc: TransactionalEventListener

Notes, Common

아키텍처와 마이그레이션