데이터 품질관리, CI/CD 검증, Telegram 알림 및 Rollback 구조

1. 배경 — "데이터가 코드다"

REINDEERS 플랫폼은 다국가·다통화 데이터를 실시간으로 처리한다. 그러나 시스템이 복잡해질수록 코드보다 더 위험한 것은 "데이터 불일치"였다. 6월 초, PO 테이블의 통화 코드 누락으로 결제 금액 계산 오류가 발생했다. 개발 로직에는 문제가 없었지만, 데이터 무결성이 깨져 있었다. 코드는 테스트를 통과했지만 데이터는 검증 대상에 포함되지 않았던 것이다.

이 사건을 계기로 REINDEERS는 데이터 품질관리(DQM, Data Quality Management)를 DevOps 파이프라인에 통합하기로 했다. 코드가 통과해야 하는 테스트가 있듯이, 데이터도 통과하지 못하면 배포되지 않는 구조를 만들겠다는 것이 핵심 원칙이었다. CI/CD 파이프라인에 데이터 검증 단계를 삽입하고, 실패 시 자동 차단과 Telegram 알림, 그리고 원격 Rollback까지 연결하는 전체 흐름을 설계했다.

2. 품질관리 체계의 원칙

모든 품질검증은 SQL 기반 선언형 규칙으로 정의된다. 코드를 수정할 필요 없이 규칙만 등록하면 즉시 적용된다.
검증은 CI/CD 파이프라인 단계에서 자동으로 실행된다. 수동 확인은 존재하지 않는다.
오류 발생 시 Telegram으로 실시간 보고된다. 운영자는 어디서든 모바일로 상황을 파악한다.
Telegram 명령을 통해 승인·롤백을 원격 수행할 수 있다. CLI나 서버 접속이 필요 없다.

이 네 가지 원칙이 적용되면서, "사람이 직접 확인하는 검증"은 사라졌다. 시스템이 데이터의 정합성을 자동으로 감시하고, 문제가 발생하면 사람에게 알리며, 사람의 한 줄 명령으로 즉시 복구가 실행되는 구조가 완성되었다.

3. Quality Schema — SQL 기반 검증 정의

모든 데이터 품질 규칙은 data_quality_check 테이블에 저장된다. 규칙은 SQL 구문으로 선언되며, 파이프라인에서 순차적으로 실행된다. 각 규칙은 대상 테이블, 검증 이름, 실행할 SQL, 심각도(severity)를 포함한다.

CREATE TABLE data_quality_check (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  table_name VARCHAR(128),
  check_name VARCHAR(128),
  check_sql TEXT,
  severity ENUM('INFO','WARN','ERROR') DEFAULT 'ERROR',
  last_run DATETIME,
  result TEXT
);

-- 실제 등록된 검증 규칙 예시
INSERT INTO data_quality_check (table_name, check_name, check_sql, severity) VALUES
('order_po', 'missing_currency',
 'SELECT COUNT(*) FROM order_po WHERE currency IS NULL', 'ERROR'),
('i18n_text', 'missing_language_key',
 'SELECT key_name FROM i18n_text GROUP BY key_name HAVING COUNT(DISTINCT lang_code) < 4', 'WARN'),
('currency_rate_norm', 'stale_rate',
 'SELECT COUNT(*) FROM currency_rate_norm WHERE effective_at < DATE_SUB(NOW(), INTERVAL 2 DAY)', 'ERROR');

새로운 검증을 추가할 때는 코드 변경이 필요 없다. 규칙을 테이블에 INSERT하면 파이프라인이 자동으로 인식해 다음 빌드부터 적용된다. 이 선언형 구조 덕분에 운영팀도 직접 규칙을 등록할 수 있고, 규칙 수가 늘어나도 실행 로직은 변하지 않는다. 현재 등록된 품질 규칙은 약 40개이며, 테이블 단위로 그룹화되어 관리된다.

4. CI/CD 파이프라인 통합 구조

CI/CD 파이프라인은 코드 빌드와 동일한 단계에서 데이터 검증을 수행한다. 파이프라인은 총 5단계로 구성된다.

코드 빌드: 소스 코드 컴파일 및 의존성 검증
단위 테스트: 함수 단위 로직 검증
데이터 품질 검증: data_quality_check 테이블의 모든 규칙 실행
통합 테스트: API 엔드포인트 및 서비스 간 연동 검증
배포: 모든 단계 통과 시에만 프로덕션 반영

3단계에서 severity='ERROR' 항목이 하나라도 발견되면 파이프라인이 즉시 중단된다. WARN 항목은 로그에 기록되지만 배포를 차단하지는 않는다. 실패 결과는 Telegram 알림으로 즉시 전송된다.

kind: pipeline
type: docker
name: data-quality-pipeline

trigger:
  event: [ push, custom ]

steps:
  - name: run-quality-check
    image: mysql:8
    environment:
      DB_HOST: reindeers-db
      DB_USER: root
      DB_PASS: $$DB_PASS
      TELEGRAM_TOKEN: $$TELEGRAM_TOKEN
      TELEGRAM_CHAT_ID: $$TELEGRAM_CHAT_ID
    commands:
      - echo "Running Data Quality Checks..."
      - mysql -h $DB_HOST -u $DB_USER -p$DB_PASS -D reindeers -e "
          SET @fail=0;
          CALL run_all_quality_checks(@fail);
          IF @fail > 0 THEN
            SELECT 'Data quality check failed';
            EXIT 1;
          ELSE
            SELECT 'All checks passed';
          END IF;"
      - python3 notify_telegram.py $?

run_all_quality_checks 프로시저는 data_quality_check 테이블을 순회하며 각 check_sql을 실행하고, 결과를 data_quality_log에 기록한다. ERROR 등급의 실패가 있으면 @fail 변수를 증가시켜 파이프라인을 중단한다.

5. Telegram Bot 알림 시스템

REINDEERS는 Slack 대신 Telegram을 운영 채널로 사용한다. Telegram의 장점은 Bot API를 통해 양방향 명령이 가능하다는 점이다. 알림을 받는 것에 그치지 않고, 운영자가 모바일이나 PC에서 직접 명령을 입력해 시스템에 즉시 개입할 수 있다.

import os, requests, sys

TOKEN = os.getenv("TELEGRAM_TOKEN")
CHAT_ID = os.getenv("TELEGRAM_CHAT_ID")
status = int(sys.argv[1])

if status != 0:
    msg = "*REINDEERS Data Quality Check Failed*\n" \
          "배포가 중단되었습니다.\n" \
          "원인: 데이터 정합성 오류 감지\n" \
          "명령: `/rollback` 으로 직전 버전 복원 가능"
else:
    msg = "Data Quality Passed.\n데이터 검증이 정상적으로 완료되었습니다."

requests.post(f"https://api.telegram.org/bot{TOKEN}/sendMessage",
              json={"chat_id": CHAT_ID, "text": msg, "parse_mode": "Markdown"})

알림은 심각도에 따라 메시지 형식이 달라진다. ERROR는 즉시 알림과 함께 배포 중단 안내가 포함되고, WARN은 요약 형태로 일일 1회 집계 보고된다. 5분 이내 동일한 오류가 반복되면 쿨다운 로직이 적용되어 알림 폭주를 방지한다.

6. Telegram 기반 Rollback 명령

Telegram Bot은 /rollback 명령을 통해 직전 안정 버전으로 시스템을 복원한다. 모든 명령은 Cloud Function으로 전달되어 데이터베이스와 배포 이력을 갱신한다. Rollback 과정은 완전 자동이지만, 명령 입력은 사람(운영자)의 승인 루프로 제한된다.

import os, pymysql, requests

def handle_rollback():
    conn = pymysql.connect(host=os.getenv("DB_HOST"),
                           user="root",
                           password=os.getenv("DB_PASS"),
                           database="reindeers")
    with conn.cursor() as c:
        c.execute("""SELECT version_id FROM release_history
                     WHERE status='STABLE'
                     ORDER BY deployed_at DESC LIMIT 1""")
        version = c.fetchone()[0]
        c.execute("""UPDATE release_history
                     SET status='ROLLED_BACK'
                     WHERE version_id=%s""", (version,))
        conn.commit()
    requests.post(
        f"https://api.telegram.org/bot{os.getenv('TELEGRAM_TOKEN')}/sendMessage",
        json={"chat_id": os.getenv("TELEGRAM_CHAT_ID"),
              "text": f"이전 안정 버전({version})으로 복원 완료."})

Rollback은 release_history 테이블에서 가장 최근의 STABLE 버전을 조회하고, 해당 버전으로 서비스를 되돌린 후 상태를 ROLLED_BACK으로 갱신한다. 실행 결과는 즉시 Telegram으로 보고된다. 자동화와 통제의 균형이 유지되는 것이 핵심이다. 시스템이 스스로 판단하는 것이 아니라, 사람이 판단하고 시스템이 실행하는 구조다.

7. 품질 로그 및 추세 관리

모든 검증 결과는 data_quality_log 테이블에 기록된다. 각 항목은 실행시간, 결과(PASS/FAIL), 메시지를 포함하며 매일 기준 데이터를 집계해 품질 트렌드를 산출한다.

CREATE TABLE data_quality_log (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  check_name VARCHAR(128),
  result ENUM('PASS','FAIL'),
  message TEXT,
  executed_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

품질지표는 Telegram 명령어 /quality로 요청할 수 있다. Bot은 최근 7일간의 통계(성공률, 실패 항목 수, 경고 건수)를 텍스트 형태로 반환한다. 주간 품질 추이가 하락하면 자동으로 알림이 발생하고, 어떤 테이블의 어떤 규칙에서 실패가 증가했는지까지 포함된 상세 보고서가 생성된다. 이 데이터는 월간 운영 리포트의 기초 자료로도 활용된다.

8. 배포 전 자동화된 테스트 항목

CI/CD 파이프라인에서 데이터 검증 외에도 배포 전 수행되는 자동화 테스트는 다음과 같다.

스키마 일관성 검사: Primary와 Secondary DB 간 테이블 구조가 동일한지 DDL 비교
환율 신선도 검사: 최신 환율 데이터가 24시간 이내인지 확인
i18n 완전성 검사: 모든 키가 4개 언어를 갖추고 있는지 확인
API 엔드포인트 헬스 체크: 주요 API가 200 응답을 반환하는지 확인
MQ 큐 잔량 검사: Dead Letter Queue에 미처리 메시지가 일정 수 이상 쌓여 있지 않은지 확인

이 항목 중 하나라도 실패하면 배포가 차단되고 Telegram으로 알림이 발송된다. 개발자는 실패 원인을 확인하고 수정한 후 다시 파이프라인을 실행하거나, 운영자가 /force-deploy 명령으로 특정 검사를 건너뛸 수 있다. 단, 이 명령은 감사 로그에 기록되며, 사후 검토 대상이 된다.

9. 운영 정책 — 승인 루프를 갖춘 자동화

REINDEERS의 운영철학은 단순하다. "자동화하되, 승인 루프를 반드시 포함한다." 모든 복구는 시스템이 수행하지만, 명령은 운영자만 입력할 수 있다. 이 방식은 보안성과 기민함을 동시에 보장한다.

실제 운영에서는 QA나 DevOps 담당자가 Telegram을 통해 /rollback, /status, /quality 명령을 실행하며 시스템 상태를 실시간으로 제어한다. 명령 실행 이력은 모두 ops_command_log에 기록되어 누가 언제 어떤 명령을 내렸는지 추적이 가능하다.

10. 결론 — 데이터 품질이 배포의 기준이 되다

REINDEERS의 6월은 "데이터 검증 자동화"라는 한 문장으로 요약된다. 이제 코드가 통과해야 하는 테스트처럼, 데이터도 통과하지 못하면 시스템은 배포되지 않는다. Telegram이 모든 품질 정보의 실시간 통제 허브로 자리 잡았다.

데이터는 코드의 일부이며, 품질은 감시가 아니라 구조다. 선언형 SQL 규칙, CI/CD 통합, 자동 알림, 원격 롤백으로 이어지는 이 파이프라인은 REINDEERS가 4개국에서 25,000건 이상의 트랜잭션을 안정적으로 처리할 수 있는 가장 확실한 기술적 기반이 되었다.

Blog

Search This Blog