프로젝트 데이터에 자연어로 묻는 두 가지 방식 — 자유 SQL 생성과 검증 질의

1. 현장 질문은 20~30개 범위로 수렴

요구는 무엇이든 답하는 챗봇처럼 들리지만, 현장에서 실제로 반복되는 질문은 범위가 좁다. 특정 CWP의 잔여 공수, 게이트를 넘지 못한 패키지 목록, 이번 주 마감인 펀치 현황, 특정 서브시스템의 진행률. 대개 이 범위 안에서 돈다.

여기서 방법이 갈린다. 모든 질문에 답하는 시스템과, 반복되는 20~30개에 정확히 답하는 시스템은 설계가 다르다.

2. 자유 SQL 생성 — 기업 데이터에서 측정된 한계

자연어를 SQL로 바꾸는 과제는 text-to-SQL로 불린다. 공개 벤치마크에서는 성적이 좋다. 2025년 5월 기준 BIRD dev에서 71.83%가 나왔고, 이후 리더보드 test 최고 성적은 81.95%(2025년 9월)까지 올라왔다. 같은 과제의 사람 성적 92.96%는 필요한 외부 지식이 함께 제공된 조건의 수치다.

실제 기업 데이터웨어하우스를 대상으로 만든 BEAVER에서는 숫자가 다르다. 최신 에이전트 방식(ReFoRCE + Claude 4.5 Sonnet)이 11.4%, 논문이 대표치로 제시한 GPT-5.2가 10.8%였다. 조건 차이는 다음과 같다.

같은 시험 안에서 조건만 바꿔도 숫자가 움직인다. 어떤 테이블을 봐야 하는지(스키마 링킹)를 힌트로 주면 18.9%, 조인 키와 컬럼 매핑까지 중간 단계 정보를 모두 주면 25.9%까지 올라간다. 모델을 바꿨을 때보다 구조 정보를 넣었을 때 정확도가 더 크게 움직였다.

Unifier의 BP 테이블, P6의 액티비티 구조, ERP의 원가 계정을 합치면 테이블 수백 개에 업무 약어 컬럼이 이어진다. 시스템 간 연결에는 외래키가 없다. 프로젝트번호·WBS·CWP 같은 업무 코드로 이어지는 암묵적 관계다. BEAVER가 재현한 조건과 성격이 같다. 다만 BEAVER는 소수 기업의 사설 DW 기반이고 EPC·조선 도메인이 포함됐다는 근거는 없다. 우리 현장의 실제 테이블 수와 조인 경로는 프로젝트마다 직접 세어봐야 한다.

3. 의미 계층을 거치면 틀리는 방식이 달라진다

미리 정의한 질의·지표 계층을 거치는 방식은 여러 제3자 측정에서 개선폭이 보고됐다.

정답률 평균보다 눈여겨볼 것은 틀릴 때의 동작이다. dbt Labs가 공개한 벤치마크(11문항)에서 시맨틱 레이어는 정의된 범위 안에서 100%, 범위 밖에서 0%였다. 범위 밖 질문에는 값을 지어내지 않고 답을 거부한다. 같은 문항에서 자유 생성 방식은 70~100%를 맞히지만, 범위라는 개념이 없어 어디서든 그럴듯한 오답을 낸다.

감사를 받는 프로젝트 데이터에서는 이 동작 차이가 크다. 기성 금액이나 게이트 판정에서 모른다고 답하면 담당자가 확인 절차를 밟는다. 틀린 숫자를 답하면 그대로 보고서에 올라간다.

구축 비용을 걱정하는 경우가 많은데, 위 개선폭을 낸 Cube의 시맨틱 레이어는 4KB 마크다운 한 장이었다. 데이터 구조를 새로 만드는 작업이 아니다.

4. 답과 함께 근거를 낸다

실사용에서는 검증이 되느냐가 또 하나의 조건이다. 집계 숫자만 답하면 담당자가 확인할 방법이 없다. 답변 항목에서 원본 BP 레코드나 3D 모델 객체로 바로 이동할 수 있어야 실무에서 쓴다.

데이터가 답을 뒷받침하지 못할 때 그 사실을 밝히는 것도 필요하다. 서브시스템 태그 160개 중 12개만 IWP에 연결돼 있다면, 그 12개 기준의 진척률과 함께 나머지는 이 경로로 판단할 수 없다는 것을 같이 내보내야 한다. 커버리지를 밝히지 않고 숫자 하나만 내보내면, 회의에서 그 숫자가 확정된 사실처럼 쓰인다.

오라클도 2026년 4월 Primavera Unifier에 AI 기능을 추가하면서 에이전트에 데이터 자동화 권한을 주되 감사추적을 남기는 구조를 발표 항목에 포함했다. 다만 릴리스 26 공식 문서 기준으로 탑재된 기능은 콘텐츠 추천, 기성 청구 보조, 요약, 태스크 어시스트 네 가지이고 자연어 질의는 포함되지 않는다. 클라우드 전용이며 지원 지역에 한국은 아직 없다. 자연어 질의 계층은 파트너나 구축사가 만들어야 한다.

5. 얹기 전에 정리할 3가지

1. 조인 키의 값 일치율을 실제로 재본다 — Unifier BP의 CWP 번호와 P6 액티비티 코드가 몇 %나 매칭되는지 숫자로 확인한다. 코드 체계 설계 자체는 마스터코드 표준화에서 다뤘다.
2. 자주 쓰는 조인 경로를 문서화한다 — 외래키가 없다면 더더욱 필요하다. 이 문서를 그대로 의미 계층의 초안으로 쓸 수 있다.
3. 컬럼 약어에 대한 업무 용어 사전을 만든다 — 약어 뜻을 모르면 사람도 그 테이블을 해석하지 못한다.

세 가지 모두 데이터 관리 작업이라 AI를 붙이지 않더라도 필요하다. 에이전트 구축과 같이 진행하면 정확도가 낮게 나왔을 때 원인이 데이터인지 설계인지 분리되지 않는다.

6. 정확도 측정은 고객 데이터로

벤더가 제시하는 정확도는 그쪽 데이터 기준이다. 이 기준은 당사에도 적용된다. 디티솔루션의 에이전트도 고객사 DB를 읽어서 답한다. 그래서 스키마 전체를 상대로 SQL을 자유 생성하는 방식 대신, 코드 체계와 조인 경로를 먼저 정리하고 검증된 질의에 질문을 연결하는 방식을 쓴다. 정확도 측정에도 당사 시연 데이터를 쓰지 않고 고객사의 실제 질문 목록을 쓴다.

절차는 이렇게 잡는다. 착수 시 현업이 실제로 던지는 질문 20~30개를 목록화하고, 그 목록의 정답률을 기준선으로 잡아 측정한다. 통과한 범위부터 운영에 올리고, 나머지는 범위 밖이라고 답하게 둔다.

국내 상황은 아직 그 앞 단계다. 대한상공회의소가 제조기업 504개사를 조사한 결과 82.3%가 AI를 경영에 활용하지 않는다고 답했고, 대기업 49.2% 대 중소기업 4.2%로 격차가 크다. AI 도입 일정을 잡기 전에 위 세 가지부터 확인하는 편이 낫다.