디지털 트윈에게 말을 걸다 — MCP 서버를 0→1로
자체 챗봇 대신 MCP 서버로 먼저 출시하며 AI 데모를 실제 제품으로 바꾼 설계와 운영의 기록.
“이 현장, 지난주 대비 3층 골조 진척이 어떻게 돼?”
건설 현장을 3D로 복원한 디지털 트윈 위에는 방대한 데이터가 쌓여 있습니다. 문제는, 그 데이터에 접근하려면 사람이 대시보드를 열고, 필터를 걸고, 여러 화면을 오가야 한다는 점이었죠. 저희 팀이 풀고 싶었던 질문은 단순했습니다. “이걸 그냥 말로 물어보면 안 될까?”
지난 몇 달간 저는 이 질문을 실제 제품으로 만드는 일을 맡았습니다. 그 과정에서 “AI 데모”와 “AI 제품” 사이의 거리를 온몸으로 배웠고, 그 이야기를 남겨봅니다.
1. 챗봇을 만들지 않기로 했다
처음 계획은 평범했습니다. 자연어로 묻고 답하는 챗봇 UI. 그런데 UI 개발 일정이 밀리기 시작했고, 저는 다른 질문을 던졌습니다. “꼭 우리 UI가 있어야 하나?”
마침 MCP(Model Context Protocol)가 떠오르고 있었습니다. MCP 서버로 만들면, 사용자는 이미 익숙한 범용 LLM 클라이언트에서 우리 디지털 트윈 데이터를 그대로 질의할 수 있습니다. 자체 UI를 기다릴 필요가 없어지는 거죠.
그래서 “MCP 서버 우선 출시”로 방향을 틀었습니다. 진입장벽(자체 UI, 회원가입, 학습)을 통째로 걷어내고, 핵심 가치(자연어로 디지털 트윈 질의)만 먼저 시장에 내놓는 전략이었습니다. 결과적으로 자체 UI 없이도 실사용 검증을 훨씬 앞당길 수 있었습니다.
배운 것: 제품의 형태(UI)와 제품의 가치(자연어 질의)는 다르다. 형태에 발목 잡히면 가치 검증이 늦어진다.
2. 아키텍처 — 하나의 LLM이 아니라 여러 에이전트
자연어 질문은 종류가 다릅니다. “이 요소가 시공됐어?” 같은 문서·의미 기반 질문(RAG) 이 있고, “3층 진척률 몇 %야?” 같은 정형 데이터 집계 질문(Text2SQL) 이 있죠.
그래서 단일 프롬프트 대신 LangGraph 기반 Multi-Agent 파이프라인을 짰습니다. 들어온 질문의 성격을 판단해 RAG 경로와 Text2SQL 경로로 라우팅하고, 결과를 종합해 답을 만드는 구조입니다.
3. 부딪힌 벽들, 그리고 넘은 방법
① retrieval precision 70%의 벽 — 모델이 아니라 출력을 바꿨다
Hybrid Search에 Re-ranking까지 붙였지만, retrieval precision은 목표 90%에 못 미치는 70% 부근에서 멈췄습니다. 흔한 반응은 “모델을 더 튜닝하자”입니다. 하지만 저는 문제를 다시 정의했습니다. 사용자를 괴롭히는 건 낮은 precision 숫자 자체가 아니라, 틀린 답을 확신에 차서 내놓는 경험이었으니까요.
그래서 모델을 붙잡는 대신 출력 설계를 바꿨습니다. 확신이 낮은 경우 단정하지 않고 “이것도 확인해보세요” 식의 추가 확인 정보(suggestion)를 함께 제시하도록. 정량 지표는 그대로여도, 사용자가 체감하는 오답 경험은 사라졌습니다.
배운 것: 지표를 올리는 것과 사용자 경험을 개선하는 것은 다른 문제다. 때론 모델이 아니라 출력이 답이다.
② Gemini 장애 — 감이 아니라 벤치마크로 결정했다
프로덕션에서 Gemini의 rate-limit과 간헐적 reliability 이슈가 반복됐습니다. “다른 모델로 바꿀까”는 쉬운 말이지만, 근거 없이 바꾸면 또 다른 문제를 만납니다.
저는 직접 벤치마크를 설계해 호출 패턴·실패율·지연·비용을 측정했고, 데이터를 근거로 Batch API로 전환했습니다. 결과는 만성 장애 해소 + LLM 호출 비용 약 50% 절감.
배운 것: 인프라 결정은 취향이 아니라 측정으로 한다. 벤치마크 한 번이 몇 달의 고생을 줄인다.
③ 응답이 느리다 — Text2SQL 15초 → 5초
초기 Text2SQL 경로는 쿼리 생성에 15초 가까이 걸렸습니다. 대화형 제품에서 15초는 사망 선고죠. 프롬프트·경로를 최적화해 약 5초(66% 단축) 까지 줄였습니다.
④ 대화가 기억을 잃는다 — DynamoDB로 최소 변경 영속화
세션이 끊기면 context가 날아가는 문제가 있었습니다. 큰 구조 변경 대신, 세션 상태를 DynamoDB에 영속화하는 최소 변경 설계로 풀었습니다. 작동하는 제품을 굴리면서 고치려면, 수술은 작을수록 좋습니다.
4. 데모와 제품 사이
이 프로젝트가 저에게 남긴 한 문장은 이겁니다.
“데모는 되는 걸 보여주는 것이고, 제품은 안 될 때도 버티는 것이다.”
노트북에서 한 번 잘 도는 파이프라인을 만드는 것과, 비용·지연·실패·기억까지 감당하며 실제 사용자 앞에 세우는 것은 완전히 다른 일이었습니다. 그 사이의 골짜기를 하나씩 메우는 게, 결국 AI 엔지니어링의 진짜 일이더군요.
다음 글에서는 LangGraph Multi-Agent 라우팅을 어떻게 설계했는지 더 깊이 다뤄보겠습니다.