프로젝트 개요
2025.03 — 2025.09
들어가며
기술적 해결책이 명확하더라도 실행이 어려운 경우가 있습니다. 여러 팀의 이해관계가 얽혀 있을 때입니다. 이 글은 마케팅 발송 모니터링 시스템의 안정성 문제를 해결하는 과정에서 기술 의사결정보다 더 많은 에너지를 쏟아야 했던 이해관계자 조율, 트레이드오프 합의, 데이터 거버넌스 정책 수립의 경험을 SBI 구조로 정리한 기록입니다.
아키텍처 관점의 상세 내용은 별도 포스팅에서 다루고 있습니다. 이 글은 그 프로젝트를 가능하게 한 사람과 합의의 과정에 집중합니다.
Situation — 분석용 플랫폼에 저당 잡힌 서비스 안정성
문제의 본질: 목적이 다른 시스템의 강결합
마케팅 운영팀이 발송 현황을 조회하는 어드민 시스템은 전사 분석용 플랫폼인 Hadoop(Hue)을 직접 바라보고 있었습니다. Hadoop은 대규모 데이터 분석을 위한 플랫폼으로, 고가용성과 실시간 응답을 보장하는 서비스용 DB가 아닙니다. 그런데 운영 도구가 이 플랫폼에 의존하고 있었습니다.
이 구조적 불일치는 두 가지 운영 리스크로 구체화되었습니다.
- 가용성 불일치: 데이터팀이 쉬는 주말에 Hadoop 장애가 발생하면, 마케팅 운영팀은 월요일까지 발송 현황을 전혀 확인할 수 없었습니다. 수십만 건의 발송이 정상적으로 처리되고 있는지 알 수 없는 채로 주말을 보내야 했습니다.
- 성능 오염: 데이터팀이 헤비한 분석 쿼리를 실행하면 어드민 응답 속도가 1초 이상으로 늘어지는 현상이 빈번했습니다. 분석 업무와 운영 업무가 같은 자원을 두고 경쟁하는 구조였습니다.
"Hadoop이 느려지면 마케팅 운영도 멈춘다. 두 시스템의 SLA가 같을 수 없는데, 같은 것처럼 묶여 있었다."
왜 쉽게 고치지 못했나
해결책 자체는 명확했습니다. 분석용(Hadoop)과 서비스 모니터링용 DB를 분리하면 됩니다. 그런데 이 변경은 단순한 기술 작업이 아니었습니다. 다음 이해관계자들의 합의가 모두 필요했습니다.
Behavior — 합의를 설계하고, 트레이드오프를 정책으로 만들다
1단계: 문제를 공유 언어로 번역하기
각 팀이 이 문제를 다르게 바라보고 있다는 점이 첫 번째 장벽이었습니다. 개발팀에게는 기술 부채 해소였지만, 마케팅 운영팀에게는 "지금 잘 쓰고 있는 것을 왜 바꾸냐"는 변화 저항이었고, DBA에게는 추가 운영 부담이었습니다.
각 팀의 관심사를 분리해서 대화했습니다. 운영팀에게는 "주말 장애 시 월요일까지 현황 파악 불가"라는 비즈니스 리스크를 수치로 제시했고, DBA에게는 Retention Policy로 관리 범위를 명확히 제한함으로써 운영 부담을 최소화하겠다는 방안을 함께 들고 갔습니다.
2단계: 핵심 트레이드오프 — Retention Policy 수립
가장 까다로운 논점은 데이터 보존 범위였습니다. 마케팅 로그는 TB 단위로 쌓이는 대용량 데이터입니다. 이를 전부 MySQL에 담는 것은 비용과 성능 양쪽에서 비현실적이었습니다.
DBA, 데이터팀, 현업 운영팀과 협의하여 다음 정책을 수립했습니다.
| 데이터 유형 | 저장소 | 보존 정책 | 근거 |
|---|---|---|---|
| 최근 5일 상세 로그 | MySQL | 5일 경과 시 자동 삭제 | 운영팀의 실시간 모니터링 수요는 대부분 최근 5일 이내에 집중 |
| 5일 이전 과거 데이터 | MySQL (통계 테이블) | 새벽 배치로 집계 후 보관 | 상세 로그 불필요, 집계 수치만으로 조회 목적 충족 |
| 전체 원본 로그 | Hadoop | 기존 정책 유지 | 분석 목적 데이터는 기존 파이프라인 그대로 유지 |
이 정책은 단순한 기술 결정이 아니었습니다. "운영팀이 실제로 언제 데이터를 조회하는가?"라는 질문에서 출발해 현업의 조회 패턴을 직접 확인한 뒤 도출한 결과였습니다. 5일이라는 기준은 임의적인 수치가 아니라 운영 팀의 실제 사용 패턴과 DBA의 용량 계획이 교차하는 지점에서 합의된 값입니다.
3단계: 이중 적재 파이프라인 설계 협의
데이터팀과의 협의에서는 "Hadoop 적재를 유지하되, 서비스 모니터링용 데이터는 별도 관리한다"는 원칙을 공유 기준점으로 삼았습니다. Hadoop을 대체하는 것이 아니라 역할을 명확히 분리하는 것임을 강조함으로써 데이터팀의 거버넌스 우려를 해소했습니다.
결과적으로 Kafka에서 발행된 이벤트가 Hadoop과 MySQL 양쪽으로 분기되는 이중 적재 구조가 채택되었고, 각 저장소는 자신의 목적에 최적화된 형태로 데이터를 수신하게 되었습니다.
Impact — Uptime 100%와 응답 속도 80% 개선
기술적 성과
- Uptime 100% 확보: 외부 분석 플랫폼의 장애 여부와 무관하게 마케팅 운영팀이 24/7 발송 현황을 모니터링할 수 있게 되었습니다. 주말 Hadoop 장애가 운영팀의 업무를 막는 일이 사라졌습니다.
- 응답 속도 80% 개선: 어드민 조회 응답이 0.5~1초에서 0.1~0.2초로 단축되었습니다. 분석 쿼리와 자원을 공유하지 않는 독립적인 DB에서 인덱스 최적화가 가능해진 결과입니다.
- 장애 전파 차단: 시스템 간 강결합이 해소되면서 Hadoop의 장애가 마케팅 운영으로 전파되는 경로 자체를 끊었습니다.
프로젝트 관리 관점의 성과
- 이해관계자 전원 합의 도출: DBA, 데이터팀, 현업 운영팀, 개발팀 네 팀 모두가 납득한 방향으로 프로젝트를 진행했습니다. 어느 한 팀에 일방적인 희생을 요구하지 않는 합의 구조를 만들었습니다.
- 재현 가능한 정책 수립: Retention Policy는 이 프로젝트에만 적용되는 임시 규칙이 아니라, 이후 유사한 데이터 파이프라인 설계 시 참조할 수 있는 거버넌스 기준이 되었습니다.
- 운영 피로도 감소: 긴급 주말 장애 대응을 위해 데이터팀과 운영팀이 소통해야 했던 불필요한 커뮤니케이션 비용이 제거되었습니다.
정리하며
이 프로젝트에서 배운 것은 기술적 정답이 곧 실행 가능한 해답은 아니라는 점입니다. 각 이해관계자의 관심사를 이해하고, 트레이드오프를 투명하게 공유하며, 누구도 불합리한 희생을 강요받지 않는 합의 구조를 설계하는 것이 프로젝트를 실제로 진전시키는 힘이었습니다.
기술 의사결정을 주도하면서 동시에 다자간 이해관계를 조율하는 경험은, 좋은 시스템이란 코드뿐 아니라 그것을 둘러싼 사람들의 합의 위에서 만들어진다는 것을 실감하게 해 주었습니다.