인테리어 견적 에이전트 · 2026

금액을 AI에게 계산시키지 않았다

인테리어 업체는 문의 한 건마다 공정을 나누고, 자재를 뽑고, 인건비를 계산합니다. 견적 하나에 한두 시간이 들고 그중 상당 부분이 매번 똑같은 산수입니다.

이 도구는 그 산수를 대신하고 사람에게는 판단만 남깁니다. 다만 견적서에서 숫자가 틀리면 치명적이므로, 무엇을 모델에게 맡기고 무엇을 맡기지 않을지가 이 프로젝트의 전부였습니다.

6단계

에이전트 파이프라인

진행 과정이 화면에 보임

0개

LLM이 만지는 숫자

물량·금액은 전부 코드

22개

계산 로직 테스트

모델은 무엇을 할지만 말하고, 숫자는 코드가 만든다

LLM 출력 스키마에 금액과 물량 필드를 아예 두지 않았습니다. 모델은 '어떤 공정이 필요한가'와 '무엇을 기준으로 재는가'만 정합니다.

예를 들어 32평 도배에 천장을 포함하면 41.6평이 됩니다. 이 곱셈을 모델에게 맡기면 조용히 틀린 숫자가 견적서에 실립니다. 모델은 기준만 내놓고 계산은 순수 TypeScript가 합니다.

산출 근거도 함께 남깁니다. 견적서에 '32평 × 천장 포함 1.3 = 41.6평'처럼 왜 이 물량인지가 표시되므로 업체가 검산할 수 있습니다.

// LLM이 내놓는 것
{ priceItemName: "실크 도배",
  basis: { kind: "areaWithCeiling" } }

// 코드가 만드는 것
32 × 1.3 = 41.6평 → 3,744,000원

경계를 스키마로 강제했다

45평 올수리 견적이 1,517만원으로 나왔습니다. 같은 규모의 참조 사례는 5,890만원이었는데도요.

원인은 문의에 '욕실·주방·도배'가 적혀 있지 않다고 빼버린 것이었습니다. 올수리는 그 자체로 전체 범위를 뜻하는데 말이죠. 명시적으로 제외한 항목만 빼도록 고쳐 3,539만원이 됐습니다.

숫자가 그럴듯해 보인다는 이유로 넘어가기 쉬운 종류의 오류였습니다. 참조 사례를 함께 보여주기로 한 이유이기도 합니다.

API 키 없이도 데모가 돌아가야 해서 규칙 기반 폴백을 만들었는데, 정규식이라 6단계가 한 프레임에 끝났습니다. '에이전트가 일하는 과정을 보여준다'는 이 데모의 핵심이 사라진 셈입니다.

실제 모델을 쓰면 단계마다 1~3초가 걸리므로 즉시 완료되는 쪽이 오히려 실제 동작을 잘못 보여줍니다. 지연을 넣되 화면에 '지연 재현'이라고 명시해 생각하는 시간인 척하지 않도록 했습니다.

역할

기획 · 설계 · 개발 · 배포

스택

Next.js 16 · Vercel AI SDK · Drizzle · Supabase · TypeScript