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

게시 2025/05/22

By August

조회 7 분읽는 시간

외주 개발 시스템을 DB 스키마 기반으로 완전 내재화한 이야기

외주 개발로 운영되던 시스템을 완전히 내재화했던 경험을 공유합니다. 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로 비동기 분리
장애 대응 로깅 체계 도입: Filebeat + Elasticsearch + Kibana
스케줄러/배치 튜닝: 작업 내역을 로그 단위로 트래킹 가능하게 구현

결과 및 회고

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

회고

“데이터는 거짓말하지 않는다” — 코드가 없을 때, 데이터가 진실의 근거가 됩니다.
완전한 이해 없이는 재설계도 없다 — 단순히 포워딩하는 구조가 아니라, 도메인을 이해하고 재해석해야 했습니다.
과감한 삭제와 재설계가 품질을 만든다 — 외주 관성에 묶이지 않고 비즈니스 중심으로 구조를 재편한 것이 핵심이었습니다.

마무리하며

외주 개발 시스템의 내재화는 단순한 이관이 아닌, 디지털 자산을 회복하는 과정입니다. 데이터만 있더라도, 충분한 분석과 도메인 해석을 통해 품질 높은 시스템으로 다시 태어날 수 있습니다. 앞으로 유사한 상황을 마주하게 될 분들에게 이 경험이 도움이 되길 바랍니다.

Notes, Common