용어 엔진 설계는 끝났다. “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는 찍혀야 한다. 안 찍히면 설계를 갈아엎어야 한다. 여기서 감으로 계속하다가 터지면 나중에 다 꼬인다.