용어 엔진 설계는 끝났습니다. “VIP 고객"이 뭔지, “순매출"이 어떤 산식인지 정의된 상태입니다.

근데 여기서 막혔습니다.

사용자가 “지난달 VIP 고객 매출 알려줘"라고 치면, 시스템 안에서 무엇이 돌아가야 할까요.

어디서 답을 가져올 건지부터 정해야 합니다

답을 만들 수 있는 소스가 여러 개입니다. 그래프를 탈 수도 있습니다. SQL을 짜서 DW를 긁어올 수도 있고, 아예 벡터 검색으로 과거 질의를 가져올 수도 있습니다.

어디로 보내느냐에 따라 답이 달라집니다.

“VIP 고객 매출"을 SQL로 보내면 Vanna가 테이블을 조합해서 숫자를 뽑습니다. 그래프로 보내면 용어 정의와 관계부터 찾아옵니다. 세 군데 다 보내서 합치면 되지 않냐 싶습니다. 실제로 해보면… 바로 충돌이 납니다.

같은 “이탈률"인데 마케팅 보고서 수치와 CRM 대시보드 수치가 다릅니다. 기준이 다른 것입니다. 사람이야 맥락을 보고 골라내지만, 에이전트한테는 그냥 서로 다른 숫자 두 개입니다.

질문이 들어오면 누가 먼저 움직이나

질문이 들어오면 제일 먼저 Router에서 걸립니다. 용어 메타데이터의 term_type 을 보고 metric 이면 SQL 쪽, concept 면 그래프 쪽으로 넘기는데, 여기서 잘못 보내면 뒤는 전부 틀어집니다. 용어마다 타입이랑 연결 컬럼을 다 박아놨습니다. 그래서 그냥 읽고 분기하면 끝입니다.

…이게 없으면 어떻게 될까요. 결국 모델한테 “이거 SQL이야 그래프야?” 물어보게 됩니다. 몇 번 해보면 바로 느낌이 옵니다. 오래 못 갑니다.

제일 골치 아픈 건 Supervisor입니다.

여러 소스에서 답이 올라왔는데 숫자가 다를 때, 누구 말을 들을 건지를 정해야 합니다. 기준을 하나로 안 밀면 매번 싸웁니다. 마케팅이 “이탈률 12%“라고 하고 CRM이 “이탈률 8%“라고 하면, 산식이 다를 뿐 둘 다 틀린 건 아닙니다.

그래서 그냥 우선순위를 박아버렸습니다. 이름은 HoT(Hierarchy of Truth)라고 붙였습니다. 용어 엔진의 표준 정의가 이기고, SQL 실행 결과가 그 다음, 벡터 검색은 맨 뒤입니다. 이게 없으면 충돌 날 때마다 모델한테 “둘 중 뭐가 맞아?“를 물어봐야 합니다.

Graph DBA는 Cypher 쿼리를 날리기 전에 스키마를 한 번 더 검증하는 역할입니다. 미등록 용어로 쿼리를 짜면 실행 전에 거릅니다.

아직 모르는 것

제일 불안한 건 복합 질문입니다.

“VIP 고객의 최근 3개월 구매 패턴을 분석해줘” 같은 건 그래프도 타야 하고 SQL도 돌려야 합니다. Router가 term_type만 보고 분기하면 단일 질문은 대부분 맞을 것 같은데, 이런 게 들어오면 쪼개야 합니다. 어디서 자르고 어떤 순서로 보내는지. 설계상으로는 그려놨는데 실제로 돌려봐야 감이 잡힐 것 같습니다.

HoT도 걸립니다. 정의가 6개월 전 것이면 어쩔지 모르겠습니다. Staleness 감지를 넣어두긴 했는데 이건 나중 문제입니다.

Graph DBA는 반대로 너무 막을까봐 걱정입니다.

다음은 실제 DB에서 돌려봅니다

하위 모듈 설계는 일단 끝냈습니다. 이제 sql-tutorial DB 21테이블로 A/B 테스트를 돌립니다. EX(Execution Accuracy) +15%p는 찍혀야 합니다. 안 찍히면 설계를 갈아엎어야 합니다. 여기서 감으로 계속하다가 터지면 나중에 다 꼬입니다.