1. 프로젝트 배경과 데이터 통합의 필요성
현대 기업 경영 환경에서 프로젝트 관리 시스템은 단순 업무 관리 도구를 넘어 기업 운영의 핵심 플랫폼으로 자리잡고 있습니다.
특히 대규모 조직에서는 프로젝트 진행 현황, 일정, 리소스, 관계 데이터 등을 기반으로 다양한 의사결정이 이루어집니다.
이 과정에서 가장 중요한 요소 중 하나가 바로 데이터의 신뢰성과 무결성입니다.
프로젝트 초기 가장 큰 과제는 여러 Legacy 시스템에 분산되어 존재하던 프로젝트 데이터를 하나의 중앙 집중식 Working System으로 통합하는 것이었습니다.
문제는 단순 데이터 이관 수준이 아니었습니다. 각 Legacy 시스템은 서로 다른 목적과 구조로 운영되고 있었으며, 사용하는 DBMS와 데이터 모델 역시 모두 달랐습니다.
또한 각 시스템에서는 매일 데이터 생성과 수정이 지속적으로 발생하고 있었습니다.
특히 프로젝트 관리 데이터 특성상 Activity와 Relationship 데이터가 매우 복잡하게 연결되어 있었습니다.
예를 들어 다음과 같은 문제가 존재했습니다.
- 시스템별 데이터 구조 불일치
- Activity 관계 모델 상이
- Key 체계 차이
- 삭제 데이터 처리 문제
- 변경 이력 추적 부재
- 데이터 정합성 보장 필요
일반적으로 데이터 통합 프로젝트에서는 CDC(Change Data Capture) 방식이 자주 사용됩니다.
즉, 변경된 데이터만 추적하여 대상 시스템으로 전달하는 방식입니다.
하지만 이번 프로젝트에서는 CDC 기반 접근이 적합하지 않았습니다. 그 이유는 원천 시스템 자체에서 변경 이력을 완벽하게 관리하지 않고 있었기 때문입니다.
또한 일부 예외 상황에서는 삭제 데이터나 변경 누락이 발생할 가능성도 존재했습니다.
특히 비즈니스 현장에서는 데이터의 100% 무결성을 매우 중요하게 요구했습니다.
결국 프로젝트에서는 “매일 전체 데이터를 다시 수집한다”는 Full-Load 기반 전략을 선택하게 되었습니다.
즉, 매일 Legacy 시스템의 전체 데이터를 ETL을 통해 수집하고, 기존 Working System 데이터와 비교하여 신규·변경 데이터를 반영하는 구조였습니다. 이는 상당히 과감한 접근이었습니다.
실제로 매일 처리해야 하는 데이터 규모는 다음과 같았습니다.
- 수십만 건의 Activity 데이터
- 천만 건 수준의 Relationship 데이터
- 수천만 건 단위 Full-Load 처리
결국 이 프로젝트의 핵심은 단순 데이터 이동이 아니라 “대규모 Full-Load 데이터를 어떻게 안정적이고 효율적으로 처리할 것인가”에 있었습니다.
2. Full-Load 기반 데이터 통합 전략
이번 프로젝트에서 가장 중요한 설계 철학 중 하나는 데이터 무결성을 절대적으로 보장하는 것이었습니다.
일반적인 CDC 방식은 효율성 측면에서는 장점이 있지만, 변경 누락이나 예외 상황 발생 시 데이터 정합성이 깨질 가능성이 존재합니다.
특히 프로젝트 관리 데이터는 관계 구조가 복잡하기 때문에 일부 데이터만 누락되어도 전체 연결 구조가 무너질 수 있었습니다.
따라서 프로젝트에서는 매일 전체 데이터를 다시 수집하는 Full-Load 전략을 채택했습니다.
즉, 원천 시스템의 Source Table 전체 데이터를 매일 ETL을 통해 가져오는 방식이었습니다. 물론 이 방식은 데이터량 측면에서 상당히 큰 부담을 가집니다.
매일 수십만 건의 Activity 데이터와 천만 건 이상의 Relationship 데이터를 처리해야 했기 때문입니다.
하지만 그만큼 얻을 수 있는 장점도 명확했습니다.
첫 번째는 데이터 정합성 보장입니다.
원천 시스템의 최종 상태를 그대로 다시 반영하기 때문에 변경 누락 가능성을 원천적으로 제거할 수 있었습니다.
두 번째는 삭제 데이터 대응이었습니다.
CDC 기반 구조에서는 삭제 데이터 추적이 어려운 경우가 많지만, Full-Load 구조에서는 현재 존재하지 않는 데이터를 쉽게 식별할 수 있었습니다.
세 번째는 운영 안정성이었습니다.
Legacy 시스템 자체의 변경 이력 관리 품질에 의존하지 않아도 되었기 때문입니다.
하지만 이러한 구조는 단순 DB 처리만으로 해결할 수 없는 수준의 대용량 데이터 처리 문제를 함께 가져왔습니다.
특히 다음과 같은 문제가 매우 컸습니다.
- 대량 데이터 비교 연산
- Upsert 처리 비용 증가
- Join 기반 표준화 처리
- 배치 시간 제한
- DB 부하 증가
실제 프로젝트에서는 새벽 시간 약 3시간 내에 전체 배치 처리를 완료해야 했습니다.
따라서 단순 쿼리 최적화 수준을 넘어 아키텍처 자체를 대량 데이터 처리에 최적화할 필요가 있었습니다.
결국 프로젝트에서는 다단계 파이프라인 기반 구조를 설계하여 단계별로 데이터를 분산 처리하는 전략을 선택했습니다.
3. Stage 1 ~ 2 : 수집과 정제 아키텍처
첫 번째 단계는 Ingestion(수집 단계)이었습니다.
프로젝트에서는 여러 Legacy 시스템으로부터 데이터를 수집해야 했는데, 각 시스템은 서로 다른 서버와 DBMS 환경에서 운영되고 있었습니다.
예를 들어 일부 시스템은 Oracle, 일부는 MSSQL, 일부는 MySQL 기반으로 운영되고 있었습니다. 처음에는 시스템별 Adapter를 직접 개발하는 방식도 검토했습니다.
하지만 Legacy 시스템이 추가될 때마다 신규 Adapter 개발이 필요했고, 유지보수 비용 역시 매우 커질 가능성이 있었습니다.
결국 이종 데이터 연계에 특화된 ETL 솔루션인 Informatica를 활용하기로 결정했습니다.
Informatica는 다양한 DBMS 연결과 데이터 수집 기능을 기본 제공하기 때문에 시스템별 연결 구조를 훨씬 효율적으로 구성할 수 있었습니다.
또한 Legacy 운영 시스템 부하 최소화 역시 매우 중요한 요구사항이었습니다. 실제 Legacy 시스템은 모두 운영 중인 업무 시스템이었기 때문에 ETL 작업으로 인해 성능 저하가 발생하면 안 되는 상황이었습니다.
이를 해결하기 위해 프로젝트에서는 Replica 기반 구조를 설계했습니다.
즉, Legacy 운영 DB 데이터를 그대로 Working System 내부 Replica DB로 복제한 뒤, 실제 정제 작업은 Replica DB를 대상으로 수행하는 방식이었습니다.
이 과정에서는 Truncate & Insert 기반 Full-Load 전략을 사용했습니다.
덕분에 운영 DB 부하를 최소화하면서도 최신 데이터를 안정적으로 확보할 수 있었습니다.
두 번째 단계는 Refinement(정제 단계)였습니다.
Legacy 시스템별 데이터는 모두 제각각의 구조를 가지고 있었습니다.
예를 들어 Activity 테이블 구조와 Relationship 구조가 시스템마다 모두 달랐습니다. 이 상태로는 통합 비교와 Upsert 처리가 불가능했기 때문에 표준화 작업이 반드시 필요했습니다.
프로젝트에서는 Activity와 Relationship 데이터를 공통 표준 모델로 정제하는 구조를 설계했습니다.
문제는 데이터량이었습니다. 매일 처리해야 하는 데이터는 수천만 건 규모였으며, 표준화 과정에서는 Join, 문자열 처리, 관계 계산 등이 대량으로 수행되어야 했습니다. 단순 쿼리 최적화만으로는 처리 시간을 맞추기 어려웠습니다.
결국 병렬 처리 구조를 도입했습니다.
Legacy 시스템 간 데이터 연관성이 없다는 점에 착안하여 시스템별 정제 작업을 병렬로 실행했습니다. 그 결과 전체 처리 시간을 절반 수준까지 줄일 수 있었습니다.
4. Stage 3 ~ 4 : 통합과 최종 적재
세 번째 단계는 Integration(통합 단계)이었습니다.
Stage 2에서 Legacy 시스템별로 정제된 Activity와 Relationship 데이터를 하나의 통합 모델로 병합하는 작업이었습니다.
이 단계에서는 단순 Merge 이상의 복잡성이 존재했습니다.
가장 큰 문제는 Key 중복 가능성이었습니다. 서로 다른 Legacy 시스템에서 동일한 Key 값을 사용할 가능성이 있었기 때문입니다.
이를 해결하기 위해 Origin System 기반 식별 체계를 함께 구성했습니다.
즉, 단순 PK만 사용하는 것이 아니라 “어떤 Legacy 시스템에서 생성된 데이터인가”를 함께 관리하도록 설계했습니다.
이를 통해 데이터 충돌 가능성을 제거하고 추적성을 확보할 수 있었습니다.
또한 모든 데이터에는 Origin System Tag를 추가했습니다.
이 구조 덕분에 이후 운영 과정에서도 특정 데이터가 어떤 원천 시스템에서 생성되었는지 쉽게 추적할 수 있었습니다.
네 번째 단계는 Transformation & Loading 단계였습니다.
이 단계의 핵심은 기존 Working DB 데이터와 신규 Full-Load 데이터를 효율적으로 비교하는 것이었습니다.
문제는 데이터량이었습니다. 수천만 건 데이터를 매일 전수 비교하는 것은 일반적인 비교 방식으로는 처리 시간이 지나치게 오래 걸릴 수 있었습니다.
이를 해결하기 위해 프로젝트에서는 Hash 기반 비교 전략을 사용했습니다.
각 Row 데이터를 기반으로 Hash 값을 생성하고, 동일 PK를 가진 기존 데이터와 Hash를 비교하는 방식이었습니다.
즉, 실제 데이터 전체를 비교하는 것이 아니라 Hash 값만 비교하여 변경 여부를 빠르게 판단했습니다.
이 구조를 통해 다음 데이터를 빠르게 식별할 수 있었습니다.
- 신규 Insert 대상
- Update 대상
- 변경 없는 데이터
또한 실제 Upsert 처리 역시 비동기 구조로 설계했습니다. 확인된 Insert 및 Update 대상 데이터는 Kafka를 통해 각 서비스의 임시 테이블로 전달되었습니다.
이후 각 서비스가 자체적으로 Upsert를 수행하여 최종 Working DB를 갱신하도록 구성했습니다.
이러한 Kafka 기반 비동기 구조는 시스템 간 결합도를 낮추고 장애 격리 효과까지 함께 제공했습니다.
5. 성능 최적화와 운영 안정성
이번 프로젝트의 가장 큰 목표 중 하나는 단순 데이터 처리 성공이 아니라 “매일 안정적으로 처리 가능한 구조”를 만드는 것이었습니다.
특히 대량 Full-Load 구조는 처리 성능과 운영 안정성 확보가 매우 중요했습니다.
프로젝트에서는 다음과 같은 최적화 전략을 적용했습니다.
- 병렬 처리 구조
- Hash 기반 비교
- 단계별 분산 처리
- Replica 기반 부하 분산
- Kafka 기반 비동기 처리
- Stage 기반 장애 격리
특히 Stage 기반 파이프라인 구조는 운영 안정성 측면에서 매우 효과적이었습니다.
각 단계마다 로그를 남기고 오류 발생 시 해당 시점 이후 처리를 중단하도록 설계했습니다.
즉, 잘못된 데이터가 최종 Working DB까지 전달되는 상황을 방지할 수 있었습니다.
또한 장애 발생 시 관리자에게 자동 이메일 알림을 발송하여 빠르게 대응할 수 있도록 구성했습니다.
이러한 구조 덕분에 운영 안정성과 데이터 신뢰성을 함께 확보할 수 있었습니다.
실제 프로젝트에서는 수백만~수천만 건 단위 데이터를 매일 안정적으로 처리할 수 있는 성능을 확보했습니다. 무엇보다 Full-Load 기반 구조에서도 운영 가능한 수준의 처리 속도를 확보했습니다는 점이 매우 의미 있었습니다.
또한 Kafka 기반 구조 덕분에 특정 서비스 장애가 전체 데이터 파이프라인 장애로 확산되는 것도 방지할 수 있었습니다.
결과적으로 프로젝트에서는 단순 ETL 시스템을 넘어 “대규모 데이터 통합 플랫폼” 수준의 안정성과 확장성을 확보할 수 있었습니다.
6. 마무리
이번 프로젝트는 단순 데이터 이관 프로젝트가 아니었습니다.
여러 Legacy 시스템에 흩어져 있던 대규모 프로젝트 관리 데이터를 하나의 중앙 집중식 플랫폼으로 통합하고, 이를 기반으로 안정적인 비즈니스 의사결정을 지원하기 위한 데이터 통합 아키텍처 구축 프로젝트였습니다.
특히 가장 큰 특징은 Full-Load 기반 구조를 실제 운영 가능한 수준으로 구현했다는 점이었습니다.
일반적으로 대량 Full-Load 구조는 비효율적이라고 평가받는 경우가 많지만, 프로젝트에서는 데이터 무결성을 최우선 가치로 두고 아키텍처 자체를 이에 맞게 최적화했습니다.
그 결과 다음과 같은 성과를 얻을 수 있었습니다.
- 데이터 정합성 확보
- 삭제 데이터 안정적 반영
- 운영 안정성 향상
- 대량 데이터 처리 성능 확보
- 장애 격리 구조 구축
- 확장 가능한 데이터 파이프라인 확보
무엇보다 의미 있었던 부분은 단순 기술 구현을 넘어 “비즈니스 신뢰성” 자체를 데이터 구조로 보장하려 했다는 점이었습니다.
프로젝트를 진행하며 데이터 통합은 단순히 정보를 옮기는 작업이 아니라, 기업 의사결정의 기반을 만드는 매우 중요한 영역이라는 점을 다시 한번 체감할 수 있었습니다.
또한 이번 경험을 통해 대량 데이터 처리 환경에서는 단순 쿼리 최적화 수준이 아니라 전체 데이터 흐름과 아키텍처 자체를 함께 설계해야 한다는 점 역시 깊이 경험할 수 있었습니다.
향후 유사한 대규모 데이터 통합 프로젝트를 수행하더라도 이번 경험은 매우 중요한 기준점이 될 것이라 생각합니다.
informalife