AX를 한다면서 DX 설계를 그대로 쓰는 회사가 많다

AX를 한다면서 DX 설계를 그대로 쓰는 회사가 많다.
근데 DB를 뜯어 고칠생각은 잘 하지 않는다.
왜?
리스크와 전환 비용이 크니까.

전통 DX는 정형 데이터 중심이다.
고객 테이블, 주문 테이블, 트랜잭션 로그.
사람이 SQL로 조회하기 좋은 구조다.
근데 LLM이 맥락을 이해하기엔 정보가 빠져있다.

AX 친화 스키마는 세 가지 컬럼 카테고리를 추가한다.
이 부분 때문에 고도의 AX 기술자가 필요하다.
(이 분야의 고수분들의 도움을 무!조!건 받는걸 추천한다.
스레드에 "RAG"라고 검색해도 눈에 띄는 실력자들 정~말 많다.)
1. 관계 테이블 = 온톨로지의 기반
엔티티 간 의미 관계를 명시한다.
"고객 A가 제품 B를 사용 중"이라는 사실을 LLM이 추론 없이 그대로 읽도록.
2. 지식 테이블 = RAG 코퍼스
FAQ, 매뉴얼, 정책을 청크 단위로 저장한다.
벡터 인덱스 붙일 준비를 미리 해둔다.
3. 벡터 컬럼 = 하이브리드 검색
각 텍스트 컬럼 옆에 임베딩 컬럼을 둔다.
SQL 필터와 벡터 유사도를 한 쿼리에서 묶을 수 있다.

이게 왜 중요하냐면,
정형 데이터가 0인 회사일수록 기회다.
이미 DX를 끝낸 회사는 기존 스키마를 뜯어고치는 비용이 크다.
하지만 처음부터 짜는 회사라면 AX 친화 스키마로 출발할 수 있다.
후발주자가 유리하다할 수 있는 드문 케이스다.

AI를 위에 얹는 게 아니라 밑에 깔아야 한다.
DB가 AI를 가정하지 않으면,
그 위에 올린 모든 자동화가 결국 데이터 변환 비용으로 새 나간다.
스키마부터 LLM이 읽기 좋게.
LLM을 위한 데이터 세팅.
그게 AX의 출발점이다.