AI 이상 탐지 데이터 분석 보고서

데이터 엔티티 관계도 (ERD)

eCross 로그 시스템의 계층적 구조와 논리적 인과 관계

Layer 1

EC_TRANSACTION

PK TRANSACTION_ID

— STATUS, PROCESS_TIME

1 : N

Layer 2

EC_PROCESS

PK PROCESS_ID

FK TRANSACTION_ID

— ADAPTER_TYPE, DEPEND_PROCESS_ID

1 : N

Layer 3

EC_MESSAGE

PK MESSAGE_ID

FK PROCESS_ID

— DIRECTION, DATA_SIZE

1 : 1

Layer 4

EC_MESSAGE_BODY

PK/FK MESSAGE_ID

— MESSAGE_IN / OUT / BODY (CLOB)

SQL 스키마 구조

ESB.SQL 기준 DDL 구조 정리 및 조인 쿼리 작성 시 확인 포인트

Table Count

Primary Key

Index (Defined)

Join Core Keys

TRANSACTION_ID / PROCESS_ID / MESSAGE_ID

핵심 관계

1) TRANSACTION
트랜잭션 단위 상위 엔터티

2) PROCESS
트랜잭션 하위 프로세스 단계

3) MESSAGE
프로세스 하위 메시지 단위

4) MESSAGE_BODY
메시지 원문(CLOB) 저장

EC_TRANSACTION_MONITORING

PK: (TRANSACTION_ID, PROCESS_HUB_ID, RETRY_COUNT)

컬럼	타입	설명
TRANSACTION_ID	VARCHAR2(80)	트랜잭션 아이디
INTERFACE_ID	VARCHAR2(30)	인터페이스 아이디
PROCESS_HUB_ID	VARCHAR2(20)	처리 허브 아이디
START_CHANNEL_ID / END_CHANNEL_ID	VARCHAR2(20)	시작/종료 채널 아이디
PROCESS_COUNT	NUMBER	프로세스 수
STATUS / RESPONSE_CODE	VARCHAR2(10)	처리 상태/응답 코드
RESPONSE_MESSAGE	VARCHAR2(500)	응답 메시지
INTERFACE_TYPE	VARCHAR2(10)	인터페이스 타입
CATEGORY_NAME	VARCHAR2(75)	카테고리 이름
START_TIME / END_TIME	TIMESTAMP	시작/종료 시간
PROCESS_TIME	NUMBER	처리 시간
RETRY_COUNT	NUMBER DEFAULT 0 NOT NULL	재시도 횟수

EC_PROCESS_MONITORING

PK: (TRANSACTION_ID, PROCESS_ID, RETRY_COUNT)

컬럼	타입	설명
TRANSACTION_ID	VARCHAR2(80)	트랜잭션 아이디
PROCESS_ID	VARCHAR2(36)	프로세스 아이디
DEPEND_PROCESS_ID	VARCHAR2(36)	의존 프로세스 아이디
PROCESS_HUB_ID	VARCHAR2(30)	처리 허브 채널 아이디
ADAPTER_TYPE / CHANNEL_ID	VARCHAR2(30) / VARCHAR2(20)	어댑터 종류 / 채널 아이디
STATUS / RESPONSE_CODE	VARCHAR2(10)	처리 상태/응답 코드
RESPONSE_MESSAGE	VARCHAR2(500)	응답 메시지
TOTAL_COUNT / SUCCESS_COUNT / ERROR_COUNT	NUMBER	전체/성공/실패 건수
START_TIME / END_TIME	TIMESTAMP	시작/종료 시간
RETRY_COUNT	NUMBER DEFAULT 0 NOT NULL	재시도 횟수

EC_MESSAGE_MONITORING

PK: (TRANSACTION_ID, PROCESS_ID, MESSAGE_ID)

컬럼	타입	설명
TRANSACTION_ID / PROCESS_ID / MESSAGE_ID	VARCHAR2(80/36/36)	트랜잭션/프로세스/메시지 식별자
MESSAGE_INDEX	INTEGER	메시지 인덱스
PROCESS_CHANNEL_ID	VARCHAR2(20)	처리 채널 아이디
DATA_TYPE / DATA_NAME	VARCHAR2(10) / VARCHAR2(1000)	데이터 타입/이름
DIRECTION	VARCHAR2(3)	메시지 방향
STATUS / RESPONSE_CODE	VARCHAR2(10)	처리 상태/응답 코드
RESPONSE_MESSAGE	VARCHAR2(500)	응답 메시지
DATA_SIZE	NUMBER	데이터 크기
SUCCESS_COUNT / ERROR_COUNT	NUMBER	성공/실패 건수
PROCESS_DT / START_TIME / END_TIME	TIMESTAMP	처리/시작/종료 시각

EC_MESSAGE_BODY

PK: (MESSAGE_ID)

컬럼	타입	설명
MESSAGE_ID	VARCHAR2(36)	메시지 아이디
MESSAGE_IN	CLOB	메시지 입력 BODY
MESSAGE_OUT	CLOB	메시지 출력 BODY
MESSAGE_BODY	CLOB	메시지 BODY

ESB.SQL TODO : INDEX 설정 제안

EC_MESSAGE_MONITORING의 TODO 위치에 아래 인덱스를 우선 검토하세요.

-- MESSAGE_BODY 조인 성능 보완
CREATE INDEX EC_MESSAGE_MONITORING_MESSAGE_ID_IDX
    ON EC_MESSAGE_MONITORING (MESSAGE_ID);

-- 오류/상태 + 시간 범위 조회 최적화
CREATE INDEX EC_MESSAGE_MONITORING_STATUS_START_TIME_IDX
    ON EC_MESSAGE_MONITORING (STATUS, START_TIME);

-- 채널 단위 모니터링 + 시간 범위 조회 최적화
CREATE INDEX EC_MESSAGE_MONITORING_CHANNEL_START_TIME_IDX
    ON EC_MESSAGE_MONITORING (PROCESS_CHANNEL_ID, START_TIME);

왜 필요한가

MESSAGE_ID 단독 인덱스: PK가 (TRANSACTION_ID, PROCESS_ID, MESSAGE_ID)라서 MESSAGE_ID만으로 조인할 때 비효율이 발생할 수 있습니다. MESSAGE_BODY와 조인 시 체감 차이가 큽니다.

STATUS + START_TIME: 장애/오류 조회는 상태 필터 + 최근 시간대 조건을 함께 사용하는 패턴이 많아 복합 인덱스가 유리합니다.

PROCESS_CHANNEL_ID + START_TIME: 채널별 트래픽/장애 모니터링의 대표 조회 패턴을 직접 커버합니다.

적용 전 체크

쓰기 부하 확인

인덱스가 늘어나면 INSERT/UPDATE 비용이 증가합니다. 로그 적재량이 큰 구간에서는 인덱스 수를 최소화하는 전략이 필요합니다.

실행계획 검증

EXPLAIN PLAN으로 실제 운영 쿼리가 해당 인덱스를 타는지 확인하고, 타지 않으면 컬럼 순서나 조건식을 조정하세요.

CLOB 인덱스 주의

MESSAGE_IN / MESSAGE_OUT / MESSAGE_BODY 같은 CLOB 컬럼은 일반 B-Tree 인덱스 대상이 아닙니다.

조인 관련 권장 TODO

TRANSACTION ↔ PROCESS 조인 시 TRANSACTION_ID + RETRY_COUNT 정합성 기준을 먼저 합의하기

PROCESS ↔ MESSAGE 조인 시 중복 방지를 위해 (TRANSACTION_ID, PROCESS_ID) 기준으로 1차 검증 쿼리 작성

MESSAGE ↔ MESSAGE_BODY 조인 전 MESSAGE_ID null/중복 점검 쿼리 상시화

시간 필터는 START_TIME 중심으로 통일하고, 기간 조건에서 인덱스 사용 여부 실행계획 확인

응답/상태 코드 분석 시 STATUS + RESPONSE_CODE 복합 분포를 함께 집계

조인 쿼리 스켈레톤

-- 1) 트랜잭션-프로세스
SELECT t.TRANSACTION_ID, t.RETRY_COUNT, p.PROCESS_ID, p.STATUS
FROM EC_TRANSACTION_MONITORING t
JOIN EC_PROCESS_MONITORING p
  ON t.TRANSACTION_ID = p.TRANSACTION_ID
WHERE t.START_TIME BETWEEN :from_ts AND :to_ts;

-- 2) 프로세스-메시지
SELECT p.TRANSACTION_ID, p.PROCESS_ID, m.MESSAGE_ID, m.DIRECTION
FROM EC_PROCESS_MONITORING p
JOIN EC_MESSAGE_MONITORING m
  ON p.TRANSACTION_ID = m.TRANSACTION_ID
 AND p.PROCESS_ID = m.PROCESS_ID;

-- 3) 메시지-바디
SELECT m.MESSAGE_ID, m.DATA_TYPE, b.MESSAGE_BODY
FROM EC_MESSAGE_MONITORING m
LEFT JOIN EC_MESSAGE_BODY b
  ON m.MESSAGE_ID = b.MESSAGE_ID;

TIP

조인 쿼리를 운영에 올리기 전, 먼저 건수 검증 쿼리(COUNT, DISTINCT COUNT)로 키 정합성을 확인하면 중복/누락 이슈를 크게 줄일 수 있습니다.

Layer 1

EC_TRANSACTION_MONITORING

비즈니스 트랜잭션의 전체 수명 주기를 관리하는 최상위 마스터 데이터

SQL Schema

PKTRANSACTION_IDVARCHAR2(80)

—INTERFACE_IDVARCHAR2(30)

—STATUSVARCHAR2(10)

—PROCESS_TIMENUMBER

—START_TIMETIMESTAMP

—END_TIMETIMESTAMP

—RETRY_COUNTNUMBER

PROCESS_TIME 분포 시뮬레이션

시간대별 소요시간(ms) — 이상치는 ● 빨간 점

확인 사항

PROCESS_TIME이 평소 구간(대부분의 점)에서 벗어나는지 먼저 확인하세요. 갑자기 튀는 값은 시스템 지연이나 장애 신호일 수 있습니다.

STATUS가 S(성공)가 아닌 건은 우선 점검 대상으로 분류하세요. 실제 장애가 아니어도 재시도/일시 오류가 섞여 있을 수 있어 원인 분리가 중요합니다.

전처리 TIP

주기성 학습

START_TIME에서 시간대(0–23시)와 요일을 함께 보세요. 평일 업무시간과 야간/주말 패턴이 다르기 때문에, 시간 구간별 기준선을 따로 두면 오탐을 크게 줄일 수 있습니다.

로그 스케일링

처리시간은 긴 꼬리 분포를 가지는 경우가 많습니다. Log Scaling을 적용하면 극단값 영향이 줄어들어, 모델이 안정적으로 학습되고 비교도 쉬워집니다.

필드별 자주 등장하는 예시값

전체 트랜잭션 단위에서 고정적으로 반복되는 값 패턴

필드	의미	자주 등장하는 값
PROCESS_HUB_ID	처리 허브	HUB (기본 처리 허브)98.5482% DIRECT (허브 우회 처리)1.4515%
START_CHANNEL_ID	시작 채널	TSC (주 입력 채널)95.1464% SOL (대체 시작 채널)3.4441% HUB (내부 시작 경로)1.4083%
END_CHANNEL_ID	종료 채널	SOL (주 종료 채널)97.7446% HUB (내부 종료 경로)1.4742% TSC (역방향 종료)0.7778%
STATUS	최종 상태	S (성공)82.2672% F (실패)17.3169% P (처리중)0.3994%
RESPONSE_CODE	응답 코드	0000 (정상 처리)82.2672% 4801 (업무 오류 계열)16.3246% 4905 (추가 오류 코드)0.7792%
INTERFACE_TYPE	인터페이스 유형	NORMAL (일반 인터페이스)99.1858% SUB (구독형)0.7481% PUB (발행형)0.0659%
CATEGORY_NAME	카테고리 분류	DB2DB > 07.성능 테스트용 (주요 카테고리)91.4366% NONE (미분류)6.2371% TEST2 > TESTQQQ (테스트 그룹)1.3196%
RETRY_COUNT	재시도 횟수	0 (재시도 없음)100.0000%

Layer 2

EC_PROCESS_MONITORING

트랜잭션 내부의 세부 작업 단위(어댑터 실행 등)를 기록하는 워크플로우 데이터

SQL Schema

PKPROCESS_IDVARCHAR2(36)

FKTRANSACTION_IDVARCHAR2(80)

—DEPEND_PROCESS_IDVARCHAR2(36)

—ADAPTER_TYPEVARCHAR2(30)

—SUCCESS_COUNTNUMBER

—ERROR_COUNTNUMBER

—START_TIMETIMESTAMP

—END_TIMETIMESTAMP

어댑터 구간별 평균 처리 시간

병목 구간은 ■ 주황색으로 강조

확인 사항

DEPEND_PROCESS_ID를 따라가며 "어느 단계에서" 지연이 시작됐는지 확인하세요. 선행 단계 지연이 뒤 단계 전체를 밀어낼 수 있습니다.

같은 ADAPTER_TYPE(DB.READER, DB.WRITER 등)에서 지연이 반복되면 코드 문제가 아니라 인프라/쿼리 병목일 가능성이 큽니다.

전처리 TIP

그래프 구조화 (DAG)

프로세스를 DAG(방향 비순환 그래프)로 보면 흐름이 한눈에 보입니다. 각 단계 소요시간을 간선 가중치로 두면, 병목이 생기는 경로를 빠르게 찾을 수 있습니다.

필드별 자주 등장하는 예시값

세부 프로세스 단계에서 반복되는 어댑터/채널/상태 패턴

필드	의미	자주 등장하는 값
PROCESS_HUB_ID	처리 허브	HUB (표준 허브 처리)98.5764% DIRECT (직접 처리)1.4226%
DEPEND_PROCESS_ID	선행 의존 프로세스	NONE (첫 단계)50.6738% IF_DB2DB_906_PR001 (선행 프로세스 예)1.4418% IF_DB2DB_905_PR001 (선행 프로세스 예)1.4295%
ADAPTER_TYPE	어댑터 종류	DB.READER (데이터 조회)47.2093% DB.WRITER (데이터 반영)46.8631% GATEWAY.INVOKER (게이트웨이 호출)1.6490%
CHANNEL_ID	처리 채널	SOL (출력 채널)50.2239% TSC (입력 채널)48.6683% HUB (내부 채널)1.1060%
STATUS	단계 상태	S (성공)83.6226% N (미실행/대기)16.2765% F (실패)0.0248%
RESPONSE_CODE	응답 코드	0000 (정상 처리)83.6489% 공백 (응답 코드 없음)16.3145% 4999 (기타 오류)0.0125%

Layer 3

EC_MESSAGE_MONITORING

프로세스 수행 시 발생하는 실제 데이터(메시지)의 물리적 흐름 기록

SQL Schema

PKMESSAGE_IDVARCHAR2(36)

FKPROCESS_IDVARCHAR2(36)

—DIRECTIONVARCHAR2(3)

—DATA_SIZENUMBER

—RESPONSE_CODEVARCHAR2(10)

—PROCESS_DTTIMESTAMP

DATA_SIZE 분포 — 이상 탐지

3-Sigma 범위 초과 데이터는 ● 이상 후보

확인 사항

RESPONSE_CODE가 0000(성공)인데 DATA_SIZE가 0이면, 실제 데이터가 비어 전송됐을 가능성을 의심하세요. "성공처럼 보이는 실패"를 잡는 포인트입니다.

평소보다 매우 큰 DATA_SIZE는 대량 요청/중복 전송/압축 실패 등과 연결될 수 있습니다. 급증 구간의 호출 주체를 함께 확인하세요.

전처리 TIP

Z-Score 활용

DATA_SIZE 평균과 표준편차로 Z-Score를 계산하면, 정상 범위를 벗어난 메시지를 자동으로 표시할 수 있습니다. 운영에서는 임계값(예: 3.0)을 서비스 특성에 맞게 조정하세요.

필드별 자주 등장하는 예시값

메시지 통신 단위에서 확인되는 방향/타입/에러 코드 패턴

필드	의미	자주 등장하는 값
DIRECTION	메시지 흐름 방향	OUT (송신)61.4159% IN (수신)34.4442% 공백 (미기록)4.1399%
DATA_TYPE	페이로드 형태	LIST (배열형 데이터)61.0907% MAP (객체형 데이터)33.2816% FILE (파일형 데이터)4.1393% BYTE (바이너리 데이터)1.4546%
STATUS	메시지 처리 결과	S (성공)99.9712% F (실패)0.0282%
RESPONSE_CODE	응답 코드	공백 (응답 코드 없음)95.8325% 0000 (정상 처리)4.1315% 4104 (DB.DELETE 오류)0.0085% 9999 (수신 상태 없음)0.0018%
MESSAGE_INDEX	메시지 순번	1 (첫 메시지)94.3349% 공백 (순번 미기록)4.1399% 2 (두 번째 메시지)0.0652%

Layer 4

EC_MESSAGE_BODY

실제 송수신된 비정형 데이터 전문(Payload)을 보관하는 최종 단계

SQL Schema

PK/FKMESSAGE_IDVARCHAR2(36)

—MESSAGE_INCLOB

—MESSAGE_OUTCLOB

—MESSAGE_BODYCLOB

AutoEncoder 재구성 손실 비율

Reconstruction Loss 기준 정상/이상 분류

확인 사항

어제까지 있던 키가 오늘 빠지거나, 갑자기 새 키가 추가되면 스키마 변경 가능성이 큽니다. 배포 이력과 함께 확인하면 원인 파악이 빨라집니다.

필드 값이 기대 범위를 벗어나는지 확인하세요. 예를 들어 음수 수량, 비정상 코드, null 급증은 비즈니스 오류 신호일 수 있습니다.

전처리 TIP

Flattening

중첩 JSON을 먼저 평면 테이블(컬럼형)로 펼치면 분석이 매우 쉬워집니다. 그 다음 범주형은 인코딩하고 수치형은 정규화해 모델 입력 품질을 맞추세요.

AutoEncoder

정상 데이터로 AutoEncoder를 학습하면, 낯선 패턴에서 재구성 오차가 커집니다. 이 오차를 기준으로 "내용 이상"을 점수화해 우선순위 점검 목록을 만들 수 있습니다.

필드별 자주 등장하는 예시값

페이로드 전문에서 확인되는 null 패턴과 JSON 본문 형태

필드	의미	자주 등장하는 값
MESSAGE_IN	수신 원문	[NULL] (원문 없음)99.8290% {} (빈 객체)0.0488% {"EC_DATA":[{"$RESULT":"SUCCESS",...}]} (성공 응답 구조)0.0244%
MESSAGE_OUT	송신 원문	[NULL] (원문 없음)99.8290% {"EC_DATA":[{"$RESULT":"SUCCESS",...}]} (성공 응답 구조)0.0305% {} (빈 객체)0.0244%
MESSAGE_BODY	JSON 문자열 Payload	[{"USER_NO":100001,"COUNTRY":"SAMPLE_COUNTRY_A",...,"GENDER":"SAMPLE_GENDER"}]

Analysis Report

MESSAGE_BODY JSON 파싱 결과 보고서

EC_MESSAGE_BODY의 MESSAGE_BODY를 JSON으로 파싱해 스키마 종류, 필드 타입, 예시값을 집계한 결과입니다.

객체 스키마 종류

32개

특수 Payload 종류

3개

총 분리 파일 수

35개

객체 레코드 수

132,977

스키마 선택 (32개)

선택 스키마 상세

필드	타입 분포	예시값

선택 스키마 요약

비객체 Payload

string_payloads: 245건 (base64/해시 문자열 포함)

null_payloads: 2건

non_object_array_payloads: 17건 (예: [])

해석 가이드

주요 정상 패턴

사용자 프로필 계열 스키마(schema_01/02/05/08)가 대부분을 차지합니다.

주의 대상

빈 객체, 단일 키("1"), 타입 혼합(QUANTITY) 및 특수 payload는 스키마 드리프트 후보입니다.