건설 견적을 위한 Voice AI: 50개 현장에서 얻은 개발자 교훈

건설 중소기업(SMB)을 위한 음성-견적(voice-to-quote) 기능을 구축하기 시작했을 때, 저에게는 세 가지 가정이 있었습니다. 그리고 그 세 가지 모두 틀렸습니다. 첫째, 저는 음성 전사(voice transcription) 문제가 해결되었다고 가정했습니다. 하지만 그렇지 않았습니다. 콘크리트 믹서와 공압 드릴이 품질 보증(QA) 엔지니어로 활동하는 현장에서는 더욱 그렇습니다. 둘째, 저는 견적 담당자들이 핸즈프리(hands-free) 입력을 원할 것이라고 가정했습니다. 일부는 그렇지만, 대부분은 다른 것을 원한다는 사실을 발견했습니다. 바로 AI가 현장 특유의 맥락(철근 배치, 자재 부족, 인력 가용성 등)을 이해하고 있다는 확신입니다. 마지막으로, 저는 어려운 부분이 자연어 처리(NLP)일 것이라고 가정했습니다. 그렇지 않았습니다. 진짜 어려운 부분은 UX 루프(UX loop)였습니다. 즉, 음성 캡처 → 의도 파악 → 견적 검증 → 마찰 없이 인간이 개입하여 수정할 수 있도록 하는 과정이었습니다. 프랑스 전역의 50개 이상의 현장에서 음성 입력을 처리한 결과, 실제로 작동하는 방식과 사용자를 잃게 만드는 요인이 무엇인지 정리해 드립니다.

아무도 말하지 않는 전사(Transcription) 문제
표준 음성-텍스트 변환(Speech-to-Text, STT) 엔진(Google Cloud Speech-to-Text, Azure, Whisper)은 깨끗한 오디오 환경에서 92~95%의 정확도를 보입니다. 하지만 건설 현장에서는 75%만 나와도 다행입니다. 왜 그럴까요?

배경 소음: 기본 소음 수준이 8595 dB에 달합니다(콘크리트 톱은 약 90 dB, 항타기(pile driver)는 약 95 dB). 대부분의 STT 엔진은 사무실 오디오(5060 dB)를 기반으로 학습되었습니다. 신호 대 잡음비(Signal-to-noise ratio)가 매우 가혹합니다.

업종 특화 용어: "Pose de vis à béton M12 sur chevilles"와 같은 표현은 일반적인 어휘집에 없습니다. 모델은 이를 "pose de vis à beton M-douze"로 듣게 되고, 결과적으로 견적 데이터베이스에서 404 오류를 마주하게 됩니다.

억양과 템포: 지역별 프랑스 억양, 프랑스 내 스페인어 사용 인력, 빠르게 나열되는 목록("dalle 40 cm, isolation 5 cm, membranes étanchéité") 등은 모두 정확도를 떨어뜨립니다.

해결책: 저희는 2단계 파이프라인을 구현했습니다.

1. Whisper를 통한 1차 전사(Coarse transcription): 오픈 소스이며, 개인정보 보호를 위해 기기 내(on-device)에서 실행되며, iPad에서 4초의 지연 시간(latency)을 가집니다.
2. 3,000개의 실제 현장 음성 샘플(건설 용어, 지역 억양, 전형적인 견적 흐름 포함)로 학습된 미세 조정(fine-tuned)된 의도 분류기(intent classifier)를 통한 후처리

이 2단계 과정은 Whisper가 놓친 부분의 약 85%를 잡아내며 신뢰도 점수(confidence score)를 추가합니다.

신뢰도(confidence)가 0.72 미만인 경우, 조용히 추측하는 대신 견적 담당자에게 확인을 요청합니다 ("콘크리트 40cm라고 말씀하셨나요, 아니면 45cm인가요?"). 이 방식은 더 느리게 느껴질 수 있지만, 견적 오류를 62% 줄여줍니다.

음성에서 의도(Intent)로: 진정한 NLP의 과제
텍스트를 확보하고 나면, 자재 유형, 수량, 단위, 표면적, 접근 난이도 등과 같은 구조화된 데이터(structured data)를 추출해야 합니다. 바로 이 지점에서 대부분의 팀이 실패합니다. "On va mettre de l'isolant 10 cm, difficile d'accès, les gars doivent passer par l'escalade"와 같은 문구는 의미론적으로는 풍부하지만 구문론적으로는 느슨합니다. 정규 표현식(regex)으로는 이를 처리할 수 없습니다. 단순한 의도 분류기(intent classifier)는 해당 도메인의 전문 용어(jargon) 때문에 어려움을 겪습니다.

효과적인 방법:

• 하이브리드 접근 방식: 측정 가능한 수량과 자재를 추출하기 위해 spaCy를 통한 개체명 인식 (NER, Named Entity Recognition) + 건설 특화 사전 사용
• 임베딩(embeddings, 예: sentence-transformers)을 사용하여 과거 견적 데이터와 의미적 유사도 검색(Semantic similarity search) 수행. 이를 통해 명시적인 규칙 없이도 "접근 어려움 → 인건비 20% 할증"과 같은 맥락을 포착할 수 있습니다.
• 신뢰도가 낮을 때 명확한 질문을 던지는 폴백 대화 시스템(fallback dialogue system)

예시: 음성 입력 → "단열재 작업 어려움, 경사지 구역"
NER 추출: [자재: 단열재], [난이도: 높음], [조건: 경사지]
임베딩 검색을 통해 경사지 작업이 포함된 유사한 과거 작업 사례를 찾음
시스템이 권장 인건비 배수(1.25x)를 미리 채우고 견적 담당자에게 확인을 요청함
이 방식은 인간을 루프 안에 유지(human in the loop)하면서 수동 데이터 입력을 약 70% 줄여줍니다.

검증 루프: AI를 맹목적으로 신뢰하는 것이 왜 일감을 잃게 만드는가
모든 음성 AI 견적 도구가 저지르는 실수는 다음과 같습니다. 견적을 생성한 뒤 이를 기정사실(fait accompli)로서 사용자에게 제시하는 것입니다. 여러분의 견적 담당자들은 숙련된 기술자들입니다. 그들은 AI가 생성한 숫자가 어떻게 도출되었는지 이해하지 못하면 그 숫자를 의심할 것입니다. 그리고 마땅히 그래야 합니다. "AI는 8시간이라고 했지만, 나는 이 팀이 이런 유형의 벽에서는 6시간이면 끝낸다는 것을 안다"와 같은 불일치는 시스템 전체에 대한 불신을 만듭니다.

효과적인 방법:
AI를 신탁(oracle)이 아닌 보조자(assistant)로 설계하십시오.

추론 과정을 보여주십시오: "120 m² 콘크리트 벽 + 접근 어려움 (이전 작업 유사도 = 0.89) + 유사 작업에 대한 귀하의 팀의 시간당 8 m² 작업 속도를 바탕으로, 16시간으로 예상합니다." 사용자가 쉽게 수정할 수 있도록 하십시오: 단 한 번의 탭으로 어떤 매개변수(parameter)든 조정할 수 있습니다. 음성 명령: "시간을 12시간으로 변경해줘." 시스템은 200 ms 이내에 견적을 업데이트합니다. 수정 사항으로부터 학습하십시오: 만약 견적 담당자가 이 벽 유형에 대해 노동 시간을 지속적으로 16시간에서 12시간으로 변경한다면, 모델은 향후 유사한 작업을 위해 승수(multiplier)를 재학습합니다. 우리는 Anodos에서 이를 구현했으며, 그 결과 견적 수정 사이클이 34회에서 12회로 단축되었습니다. 견적 담당자들은 통제권을 갖고 있다고 느꼈습니다. 견적은 더 빠르고 정확해졌습니다.

실제 환경의 지연 시간 제약(Latency Constraints)
현장의 WiFi는 불안정합니다. 셀룰러 데이터는 더 느립니다. 자연스러운 느낌을 주려면 Voice AI가 왕복 지연 시간(round-trip latency) 500 ms 미만으로 작동해야 하며, 그렇지 않으면 사용자는 다시 타이핑을 선택하게 될 것입니다. 온디바이스 전사(On-device transcription, iPad에서 약 150 MB로 양자화된 Whisper 사용)를 사용하면 문장당 34초 정도가 소요됩니다. 이는 수용 가능한 수준입니다. 사용자는 음성 전사에 약간의 시간이 걸릴 것을 예상하기 때문입니다. 의도 추출(Intent extraction) + 견적 생성(백엔드 LLM 또는 미세 조정된 분류기(fine-tuned classifier) 호출)은 양호한 네트워크에서는 12초, 3G 환경에서는 5~8초를 추가합니다. 만약 8초를 초과한다면, 프로세스를 분리하십시오. "처리 중..."을 표시하면서 견적 생성을 시작하고, 신뢰도 점수(confidence score)를 실시간으로 스트리밍하여 전달하십시오.

전문가 팁: 빈번한 쿼리를 캐싱(Cache)하십시오. 만약 견적의 30%가 "콘크리트 벽 + 표준 접근"이라면, 결정 트리(decision tree)를 오프라인에서 미리 계산하고 온디바이스에서 보간(interpolate)만 수행하십시오. 그러면 해당 쿼리에 대한 백엔드 지연 시간을 300 ms 미만으로 낮출 수 있습니다.

한 가지 더: 개인정보 보호 및 규정 준수(Privacy and Compliance)
프랑스에서 음성 녹음은 개인 데이터입니다. GDPR이 적용됩니다. 만약 온디바이스에서 전사하고 오디오를 즉시 삭제한다면(구조화된 추출 데이터만 유지), 대부분 문제가 없습니다. 하지만 오디오를 클라우드 API로 전송하고 이를 로그에 남긴다면, 명시적 동의 + 보관 제한 + 삭제 권리 보장이 필요합니다. 우리는 Whisper를 로컬에서 실행하고, 추출 후 오디오를 삭제하며, 원본 오디오를 API로 절대 보내지 않습니다. 법무팀도 만족했고, 사용자들도 만족했습니다.

그리고 제3자 데이터 처리업체(third-party data processors)가 얽힌 복잡한 문제도 피할 수 있습니다. 건설 견적을 위한 Voice AI 개발을 마무리하며, 다음과 같은 원칙을 지킨다면 성공할 수 있습니다:

• 전사(transcription) 결과에 노이즈가 있음을 인정하고, 신뢰도 가중치(confidence-weighted)가 적용된 UI를 구축할 것
• 의도 추출(intent extraction)을 도메인 특화 문제로 취급할 것 (도메인 데이터 사용)
• 인간이 루프 안에 있음을 명시적으로 보여줄 것 (추론 과정을 보여주고, 쉽게 수정할 수 있도록 허용)
• 개인정보를 존중할 것 (가능한 경우 온디바이스(on-device) 방식 사용)
• 지연 시간(latency)을 공격적으로 최적화할 것 (3~5초는 자연스럽게 느껴지지만, 10초 이상은 고장 난 것처럼 느껴짐)

기술은 이미 준비되어 있습니다. 채택 곡선(adoption curve)이 가파른 이유는 대부분의 팀이 잘못된 사용자 경험(UX)을 구축하기 때문입니다. 즉, 사용자가 아닌 AI를 우선하여 구축합니다. 이 우선순위를 뒤집는다면, 견적사들은 왜 음성 입력을 사용해야 하는지 묻는 대신, 음성 입력 속도를 더 높여달라고 요청하게 될 것입니다.

Anodos의 창립자인 Olivier Ebrahim은 현장의 WiFi 문제, 지역별 프랑스 억양, 그리고 Voice AI를 받아들이기 시작한 건설 중소기업(SMB)들의 아름다운 혼돈과 씨름하며 시간을 보냅니다. 만약 여러분이 소음이 많은 도메인에서 음성 인터페이스를 구축해 본 경험이 있다면, 어떤 점이 놀라웠는지 듣고 싶습니다.