Tri-Fort 구축기: 왜 우리는 순수 머신러닝을 포기하고 건설 지능 엔진을 구축했는가

서론

지난 몇 달 동안, 저는 케냐 건설 산업을 위해 설계된 AI 기반 건설 비용 추정 플랫폼인 Tri-Fort를 구축해 왔습니다.

처음에는 목표가 간단해 보였습니다:

과거 건설 데이터를 수집하고, 머신러닝 (Machine Learning) 모델을 학습시켜, AI가 프로젝트 비용을 예측하게 한다.

오늘날 AI 제품을 만드는 많은 창업자들과 마찬가지로, 저 또한 머신러닝 모델이 곧 제품이 될 것이라고 가정했습니다.

제 생각이 틀렸습니다.

건설 산업에 깊이 파고들수록, 가장 큰 과제는 모델 선택, 신경망 (Neural Networks), 또는 특징 공학 (Feature Engineering)이 아니라는 것을 깨달았습니다.

과제는 데이터였습니다.

그리고 그 깨달음은 Tri-Fort의 아키텍처를 근본적으로 변화시켰습니다.

이 글은 엔지니어링 여정, 실수, 발견, 그리고 우리가 ML 우선 (ML-first) 아키텍처에서 하이브리드 건설 지능 (Construction Intelligence) 플랫폼으로 어떻게 진화했는지를 기록합니다.

원래의 비전

Tri-Fort의 첫 번째 버전은 전통적인 머신러닝 파이프라인을 중심으로 설계되었습니다.

사용자는 다음 항목을 입력합니다:

• 위치
• 프로젝트 유형
• 연면적 (Built-up area)
• 층수
• 마감 수준
• 자재 선호도

그러면 시스템은 다음과 같이 작동합니다:

1. 특징 (Features) 생성
2. 이를 회귀 모델 (Regression model)에 입력
3. 추정 건설 비용 반환

아키텍처는 다음과 같은 모습이었습니다:

사용자 입력 (User Input)
     ↓
특징 공학 (Feature Engineering)
...

단순했습니다.

적어도 서류상으로는 말이죠.

아무도 말하지 않는 데이터 문제

대부분의 머신러닝 튜토리얼은 당신이 이미 깨끗한 데이터를 가지고 있다고 가정합니다.

건설 현장은 그렇게 돌아가지 않습니다.

우리가 접근할 수 있었던 데이터에는 다음이 포함되었습니다:

• 물량 산출서 (Bills of Quantities, BoQs)
• 작업 일정 (Work schedules)
• 비용 책자 (Cost books)
• 적산사 (Quantity Surveyor) 보고서
• 프로젝트 사양서 (Project specifications)
• 시장 조사 데이터셋 (Market research datasets)
• 과거 가격 문서
• 계약자 추정치 (Contractor estimates)

언뜻 보기에 이것은 노다지처럼 보였습니다.

하지만 현실은 혼돈 그 자체였습니다.

파일들은 다음과 같은 형태로 존재했습니다:

• PDFs
• 스캔된 PDF (Scanned PDFs)
• Excel 워크북 (Excel workbooks)
• OCR 출력물 (OCR outputs)
• 비용 일정표 (Cost schedules)
• 동일 프로젝트의 여러 개 수정본 (Multiple revisions of the same project)

동일한 프로젝트가 종종 세 가지 또는 네 가지 버전으로 존재했습니다.

예를 들어:

Kiambu Mall BoQ
Kiambu Mall Revised Boq
Kiambu Mall Perimeter Wall BoQ
...

사람에게 이것들은 명확히 연관되어 보입니다.

하지만 머신러닝 (Machine Learning) 파이프라인에게 이것들은 완전히 다른 프로젝트로 보입니다.

감사 (The Audit)

모델을 맹목적으로 학습시키는 대신, 우리는 데이터 발견 및 감사 (data discovery and audit) 파이프라인을 구축했습니다.

이 파이프라인은 다음을 수행했습니다:

• 파일 인벤토리 (File inventory)
• 프로젝트 그룹화 (Project grouping)
• 중복 탐지 (Duplicate detection)
• OCR 품질 평가 (OCR quality assessment)
• 비용 회수 분석 (Cost recovery analysis)
• 데이터셋 준비도 점수 산정 (Dataset readiness scoring)

우리가 발견한 결과는 놀라웠습니다.

수십 개의 문서와 수천 개의 추출된 행 중에서:

• 단 9개의 고유한 프로젝트만이 복구 가능했습니다.
• 단 2개의 프로젝트만이 실제 최종 비용에 대한 증거를 포함하고 있었습니다.
• 나머지 프로젝트들은 추정치 (estimates)였습니다.

이것은 결정적인 차이였습니다.

대부분의 데이터셋은 다음과 같은 내용을 포함하고 있었습니다:

Estimated Cost (추정 비용)

우리가 실제로 필요했던 것은 다음과 같았습니다:

Final Actual Cost (최종 실제 비용)

이 둘은 같은 것이 아닙니다.

추정치로 학습하는 것은 모델에게 추정치를 재현하도록 가르치는 것입니다.

그것은 모델에게 현실을 예측하도록 가르치는 것이 아닙니다.

배포를 중단했던 순간

어느 시점에는 플랫폼이 프로덕션 준비가 된 것처럼 보였습니다.

API가 작동했습니다.

인증 (Authentication)이 작동했습니다.

리포팅 (Reporting)이 작동했습니다.

인프라 (Infrastructure)가 테스트를 통과했습니다.

심지어 머신러닝 (ML) 파이프라인도 합성 검증 (synthetic validation)을 통과했습니다.

하지만 데이터 감사 (data audit)는 불편한 진실을 드러냈습니다.

모델은 현실로부터 배우고 있지 않았습니다.

모델은 다른 추정치들로부터 배우고 있었습니다.

그 시점에 제품을 출시했다면 지능의 환상을 만들어냈을 것입니다.

그래서 배포를 중단했습니다.

머신러닝 (Machine learning) 모델은 더 이상 우선순위가 아니었습니다.

데이터가 우선순위가 되었습니다.

더 나은 접근 방식의 발견

데이터를 감사하는 동안, 우리는 공식적인 적산 (Quantity Surveying) 비용 핸드북을 입수했습니다.

이것이 모든 것을 바꾸어 놓았습니다.

우리는 핸드북을 단순한 PDF로 취급하는 대신, 구조화된 지식 소스 (structured knowledge source)로 취급했습니다.

핸드북에는 다음 내용이 포함되어 있었습니다:

• 지역별 건설 요율 (Regional construction rates)
• 비용 벤치마크 (Cost benchmarks)
• 건물 분류 (Building classifications)
• 측정 표준 (Measurement standards)
• 비용 조정 계수 (Cost adjustment factors)
• 자재 가격 참조 (Material pricing references)

갑자기 우리는 작은 머신러닝 (ML) 데이터셋보다 훨씬 더 가치 있는 것을 갖게 되었습니다.

우리는 도메인 전문 지식 (domain expertise)을 갖게 된 것입니다.

핸드북을 지식 그래프 (Knowledge Graph)로 전환하기

다음 과제는 엔지니어링이었습니다.

정적인 핸드북을 어떻게 소프트웨어로 변환할 것인가?

우리는 핸드북 데이터를 구조화된 규칙 (structured rules)으로 변환하는 추출 파이프라인 (extraction pipeline)을 구축했습니다.

시스템은 다음 항목들을 식별합니다:

• 지역 (Regions)
• 요율표 (Rate schedules)
• 건물 등급 (Building classes)
• 건설 카테고리 (Construction categories)
• 비용 승수 (Cost multipliers)

이 정보들은 기계가 읽을 수 있는 규칙 그래프 (machine-readable rule graph)에 저장됩니다.

개념적으로는 다음과 같습니다:

Handbook PDF
      ↓
Extraction
...

애플리케이션 전반에 숫자를 하드코딩 (hardcoding)하는 대신, 이제 비용 엔진 (cost engine)은 구조화된 건설 지식을 바탕으로 추론 (reasoning)할 수 있습니다.

하이브리드 아키텍처 (Hybrid Architecture)

현재의 아키텍처는 더 이상 머신러닝 (machine learning)에만 전적으로 의존하지 않습니다.

대신 세 가지 지능 소스 (intelligence sources)를 결합합니다.

1. 핸드북 지능 (Handbook Intelligence)

공식 QS (Quantity Surveyor) 벤치마크 요율.

2. 과거 프로젝트 지능 (Historical Project Intelligence)

복구된 물량내역서 (BoQs) 및 프로젝트 데이터.

3. 사용자 기능 지능 (User Feature Intelligence)

견적기 (estimator)를 통해 수집된 입력값.

이제 아키텍처는 다음과 같은 모습입니다:

User Inputs
      ↓
Feature Engine
...

이 접근 방식은 순수 ML (pure ML)보다 훨씬 더 안정적입니다.

설명 가능성 (Explainability)이 중요한 이유

건설 프로젝트에는 막대한 금액이 투입됩니다.

사용자들은 블랙박스 (black boxes)를 신뢰하지 않습니다.

만약 시스템이 다음과 같이 말한다면:

KES 18,400,000

다음 질문은 이것입니다:

왜?

현대적인 AI 시스템들은 종종 이 문제로 어려움을 겪습니다.

Tri-Fort는 이제 추론 흔적 (reasoning traces)을 생성합니다.

예를 들어:

기본 요율: 54,000 KES/sqm
위치 조정: 나이로비 (Nairobi) +20%
고급 마감 조정: +15%
...

사용자는 견적뿐만 아니라 그 근거 (rationale)를 볼 수 있습니다.

그러한 투명성이 신뢰를 구축합니다.

인프라 엔지니어링 (Engineering the Infrastructure)

견적 엔진과 더불어, 플랫폼에는 프로덕션급 (production-grade) 인프라가 필요했습니다.

스택 구성은 다음과 같습니다:

백엔드 (Backend)

• FastAPI
• PostgreSQL
• 도메인 주도 설계 (Domain-driven architecture)
• 백그라운드 작업 처리 (Background task processing)

프론트엔드 (Frontend)

• Next.js
• TypeScript
• 반응형 대시보드 (Responsive dashboard)

인프라 (Infrastructure)

• Docker Compose
• Caddy
• HTTPS 자동화 (HTTPS automation)
• 환경 기반 설정 (Environment-driven configuration)

모든 설정이 완료되어 있어, VPS 배포 시 다음 과정만 필요합니다:

git pull
docker compose up -d --build

코드 변경 없음.

프로덕션 전용 브랜치 없음.

수동 편집 없음.

교훈 (Lessons Learned)

만약 내일 이 프로젝트를 다시 시작할 수 있다면, 저는 세 가지 규칙을 따를 것입니다.

규칙 1

데이터셋의 크기를 절대 신뢰하지 마십시오.

감사(Audit)하십시오.

천 개의 행(row)이 단 다섯 개의 프로젝트만을 나타낼 수도 있습니다.

규칙 2

데이터가 부족할 때는 도메인 지식 (Domain knowledge)이 머신러닝 (Machine learning)을 이깁니다.

숙련된 적산사 (Quantity Surveyors)가 작성한 핸드북이 제대로 학습되지 않은 모델보다 더 뛰어난 성능을 발휘할 수 있습니다.

규칙 3

사용자는 알고리즘이 아니라 정답에 관심을 가집니다.

아무도 건설 견적 시스템이 AI를 사용한다는 이유만으로 고용하지 않습니다.

그들은 견적 결과가 정확하기 때문에 고용합니다.

Tri-Fort의 향후 행보

장기적인 비전은 여전히 머신러닝입니다.

하지만 이제 로드맵은 현실에 기반을 두고 있습니다.

다음 단계는 다음 항목들을 수집하는 데 집중합니다:

• 최종 정산서 (Final accounts)
• 준공 증명서 (Completion certificates)
• 계약업체 인보이스 (Contractor invoices)
• 설계 변경 지시서 (Variation orders)
• 실제 프로젝트 비용 (Actual project costs)

데이터셋이 성장함에 따라 머신러닝의 중요성은 점점 더 커질 수 있습니다.

결국 플랫폼은 진정한 하이브리드 시스템으로 진화할 것입니다:

도메인 지식 (Domain Knowledge)
      +
과거 프로젝트 데이터 (Historical Projects)
...

그것이 미래입니다.

AI가 전문성을 대체하는 것이 아니라,

AI가 전문성을 증폭시키는 것입니다.

마치며

Tri-Fort를 구축하며 얻은 가장 큰 교훈은, 성공적인 AI 제품은 모델에 관한 것이 아닌 경우가 드물다는 점입니다.

성공적인 제품은 모델이 정답이 아닌 시점을 알 수 있을 정도로 문제를 깊이 이해하는 것에 관한 것입니다.

건설 견적의 경우, 지능은 다음 요소들의 조합에서 나옵니다:

• 엔지니어링 (Engineering)
• 적산 (Quantity surveying)
• 과거 데이터 (Historical data)
• 도메인 전문 지식 (Domain expertise)
• 소프트웨어 아키텍처 (Software architecture)

머신러닝은 그 퍼즐의 한 조각일 뿐입니다.

그리고 때로는 가장 현명한 엔지니어링 결정은 그것(머신러닝)에 의존하지 말아야 할 때를 아는 것입니다.