사내 GPU에 소형 AI를 두고, 흩어진 생산·유통·품질 데이터를 사내망 브라우저에서 묻는다

데이터는 넘치는데, 답은 어디에도 없다

농축산은 데이터가 많은 산업이다. 매일 쌓이는 기록은 크게 넷이다.

• 생산 기록. 어느 농장에서 얼마가 생산됐는지
• 유통 내역. 어느 경로로 어디까지 유통됐는지
• 품질 보고서. 품질 검사에서 무엇이 걸렸는지
• 거래 데이터. 누구와 어떤 조건으로 거래했는지

문제는 양이 아니라 위치다. 이 기록들은 서로 다른 시스템과 문서에 나뉘어 있고, 하나의 질문에 답하려면 담당자가 그 출처들을 직접 오가며 짜맞춰야 한다.

일의 절반이 분석이 아니라 취합이다

지금 절차는 이렇다. 질문이 오면 화면 세 개를 띄운다. 생산 기록에서 숫자를 옮겨 적고, 유통 시스템에서 경로를 확인하고, 품질 보고서를 열어 한 줄을 찾는다. 담당자의 표현을 빌리면 일의 절반은 분석이 아니라 취합이다. 판단하는 시간보다 판단에 필요한 숫자를 모으는 시간이 더 길다. 한 번 답을 만들고 나면 다음 질문은 또 처음부터고, 출처가 흩어져 있는 한 이 수고는 매번 되풀이된다.

데이터가 부족한 게 아니다. 한 질문에 답하려면 매번 여러 시스템을 직접 오가야 한다는 게 문제였다.

그렇다고 흩어진 데이터를 외부 클라우드의 대형 AI에 태우는 흔한 방식은 첫 단추부터 끼울 수 없다. 사내 데이터를 외부로 내보내는 것 자체가 보안 정책상 막혀 있다. 데이터를 반출할 수 없으니 AI 활용의 폭이 좁아지고, AI를 포기하자니 취합의 수고가 그대로 남는다. 이 양자택일이 도입을 망설이게 한 진짜 이유였다.

여기에 하나가 더 얹힌다. 설령 방법이 있다 해도, 회사는 본계약 전에 우리 환경과 우리 데이터에서 실제로 쓸 만한지를 확인하고 싶었다. 새 도구를 들이는 결정은 한 번의 데모 인상이 아니라 검증된 근거 위에서 내려져야 했다.

데이터를 내보내지 말고, AI를 데이터 옆으로

Consilience가 제안한 발상은 한 문장이다. 데이터를 밖으로 내보내지 말고, AI를 데이터 옆으로 가져온다. 외부 클라우드 대신 고객사 내부 GPU 환경에 소형 언어모델(sLLM, 작은 규모의 LLM)을 배치한다. 데이터는 사내 경계를 벗어나지 않고, AI가 그 경계 안으로 들어와 일한다.

화면 세 개 대신, 한자리에서 묻는다

"품질 검사에서 이 항목이 걸린 판정 기준이 뭐지?"
→ 문서에 적힌 근거가 필요한 질문이다. 미리 인덱싱해 둔 사내 문서에서
   관련 문단을 먼저 찾고, 그 근거 위에서 답한다(RAG, 검색 증강 생성).
   문서 어디에 그렇게 쓰여 있는지가 답과 함께 온다.

"이 조건에 해당하는 생산량을 합치면 얼마지?"
→ 문서 검색만으로는 풀리지 않는다. 수치를 집계하거나 조건을 걸어
   조회해야 하는 질문은 Data-Agent가 사내 데이터에 직접 질의해 가져온다.

(두 질문 모두)
→ 질문도 답도 사내 GPU 위에서 처리된다. 데이터는 사내 경계를 벗어나지 않는다.

답이 두 갈래로 나뉘는 이유는 질문이 두 종류이기 때문이다. 문서에 적힌 근거가 필요한 질문은 RAG가 맡는다. 사내 문서를 미리 인덱싱해 두고, 질문이 들어오면 관련 문단을 찾아 그 위에서 답한다. 데이터에서 계산해야 하는 질문은 Data-Agent가 맡아 사내 데이터에 직접 질의한다. 두 종류의 답이 결합되어 돌아온다.

담당자가 예전에 화면을 옮겨 다니며 손으로 하던 취합이 이 자리에서 일어난다. 사람이 출처를 오가지 않고, 데이터는 사내에 그대로 있다.

무엇이 달라지나

정리하면 이렇다. 흩어진 출처를 사람이 오가는 대신 사내망 브라우저 한 곳에서 묻고, 데이터는 사내 경계 안에 둔 채 사내 GPU의 sLLM이 답한다. 도입 여부는 자기네 데이터로 돌려 본 점검 결과로 판단한다.