코드 한 줄 쓰기 전에 50명의 계약업체에게 콜드 콜을 돌린 이유: AI는 쉬운 부분이었습니다

저는 첫 번째 버전을 오후 한나절 만에 만들었습니다.

LLM (Large Language Model)에 직무 기술서를 던져 넣습니다. 가격을 물어봅니다. 숫자를 출력합니다.

그것은 쓸모가 없었습니다. 그리고 그것이 쓸모없었던 이유가 바로 이 포스트의 핵심입니다.

자신 있게 거짓말을 하는 오후의 프로토타입

순진한 빌드는 아름답게 작동합니다. "12x14 크기 침실 재도장" 비용을 산출하라고 요청하면, 매번 깔끔하고 자신감 넘치는 달러 금액을 내놓습니다.

문제는 그 금액이 허구라는 점입니다.

금액이 너무 높으면 계약업체는 일감을 놓칩니다. 너무 낮으면 그들은 자신의 주머니에서 손실을 메워야 합니다. 그리고 모델이 환각 (Hallucination)을 일으켜 내뱉은 숫자를 계약업체가 유료 고객에게 그대로 말하게 된다면, 그것은 도구가 아예 없는 것보다 더 나쁩니다. 왜냐하면 이제 그 추측에 적힌 이름은 제 이름이 아니라 _그들_의 이름이기 때문입니다.

그래서 저는 에디터를 닫고 전화를 걸기 시작했습니다.

50시간의 시장 조사보다 효과적인 50통의 전화

저는 약 50명의 수리공, 목수, 리모델링 업자들에게 콜드 콜 (Cold-call)을 하여 한 가지 질문을 던졌습니다: "이 사업을 운영하면서 실제로 무엇이 가장 싫으신가요?"

답변은 거의 만장일치였으며, 망치를 휘두르는 것과는 아무런 상관이 없었습니다. 그것은 바로 견적 산출 (Estimating) 이었습니다. 도시를 가로질러 운전하고, 모든 것을 측정하고, 개인 시간을 들여 상세한 견적서를 작성한 뒤, 고객이 단지 더 저렴한 가격만을 찾고 있다는 이유로 그 견적서의 절반 이상이 무용지물이 되는 것을 지켜보는 일 말입니다.

한 사람은 핵심을 짚었습니다. 그의 견적 중 최소 60%는 고객이 "항상 가장 저렴한 지인을 알고 있다"는 이유로 무산된다는 것이었습니다.

그것이 제품 전체의 프레임을 재설정했습니다. 과업은 결코 "숫자를 생성하는 것"이 아니었습니다. 어떤 도구든 숫자를 생성할 수 있습니다. 과업은 계약업체가 자신의 명성을 걸 수 있는 숫자를 생성하는 것이었습니다. 이를 신뢰 격차 (Trust gap) 라고 부르며, 이것이 실제로 중요한 유일한 문제였습니다.

엔지니어링 문제

비법(Secret sauce)은 모호하게 유지하겠습니다. 그 부분은 비즈니스니까요. 하지만 그 형태는 다음과 같습니다:

• 모델이 멋대로 날뛰지 못하도록 근거를 제공(Ground)해야 합니다. 작업 세부 정보, 사진, 외부 부동산 데이터가 모델이 추론해야 하는 확고한 컨텍스트(Context)로 입력됩니다.
• 확률적 계층(Probabilistic layer)을 결정론적 계층(Deterministic layer)으로 감싸야 합니다. LLM은 지저분한 인간의 설명을 파싱(Parsing)하는 데는 뛰어나지만, 산술 연산과 일관성 유지에는 정말 취약하므로 수학적 계산에 대해 결코 최종 결정권을 가져서는 안 됩니다.
• 시간이 지남에 따라 각 계약업체의 실제 가격 책정 방식을 학습하게 하세요. 그래야 결과값이 전국 평균이 아닌, 그들만의 수치로 수렴하게 됩니다.

모든 것을 해결해 준 멘탈 모델(Mental model)은 다음과 같습니다: LLM의 역할은 번역하고 해석하는 것입니다. 가격 결정은 모델이 환각(Hallucination)을 일으킬 수 없는 어딘가에서 이루어져야 합니다. 모델을 진실의 근원(Source of truth)으로 취급하는 것을 멈춘 날, 시스템 전체가 신뢰할 수 있게 되었습니다.

스택 (The stack)

저는 의도적으로 지루한 방식을 유지했습니다. 지루한 것이 확장(Scale)됩니다. 영리한 방식은 새벽 2시에 고장 납니다.

• Next.js (App Router), 프론트엔드와 백엔드를 한 곳에서 처리합니다. Server Actions를 사용하여 AI와 가격 책정 로직을 서버 측에 유지함으로써, 별도로 관리해야 할 API 서비스가 없도록 했습니다.
• TypeScript, 엄격 모드(Strict mode). AI 기능은 이미 충분한 비결정성(Nondeterminism)을 가지고 출시되기 때문입니다.
• 언어 계층을 위한 LLM 제공업체 (어떤 모델인지, 어떻게 프롬프팅하는지는 밝히지 않겠습니다).
• 모델이 면적을 추측하지 않도록 하는 제3자 부동산 데이터 API.
• 주택 소유자로부터 직접 결제를 받기 위한 Stripe.
• 관리형 Postgres 및 인증(Auth), 저는 혼자이며 직접 인프라를 운영하지 않기 때문입니다.

반전: 저는 견적기를 만들고 있었던 게 아니었습니다

저는 견적(Estimating)이 제품이라고 생각했습니다. 하지만 계약업체들은 그것이 시장 진입을 위한 쐐기(Wedge)일 뿐이라는 것을 가르쳐 주었습니다.

"영원히 삭제해도 되는 기능은 무엇인가요?"라는 동일한 질문이 계속해서 *같은 문제군(Cluster)*을 드러냈습니다: 미납금 추적, 업무 범위 확장(Scope-creep) 분쟁, 일정 충돌, 밤 10시에 날아오는 인보이스, 세금 시즌 전에 분실되는 영수증 등입니다. 오직 견적만 제공하는 도구였다면 무시하기 쉬웠을 것입니다.

그래서 빌드는 견적(estimate)이 수락된 이후에 발생하는 모든 과정으로 확장되었습니다. 대금 수납, 고객 포털, 캘린더를 준수하는 일정 관리, 자동 인보이스 발행, 그리고 3주 후에