트라이포트 구축: 순수 머신러닝 포기, 건설 인텔리전스 엔진 개발 이유

출처: Dev.to

소개

지난 몇 달 동안 저는 케냐 건설 산업을 위해 설계된 AI 기반 건축 비용 추정 플랫폼인 Tri‑Fort를 구축하고 있습니다.
처음에는 목표가 간단해 보였습니다:

• 역사적 건축 데이터 수집, 머신러닝 모델 훈련, AI가 프로젝트 비용을 예측하도록 합니다.
  오늘날 많은 창업자들이 AI 제품을 만들 때와 같이, 저는 머신러닝 모델이 제품 자체가 될 것이라고 생각했습니다.
  저는 틀렸습니다.

건설 산업에 더 깊이 들어가면서, 모델 선택이나 신경망, 피처 엔지니어링이 아니라 데이터가 가장 큰 도전임이 깨달았습니다. 이 인식은 Tri‑Fort의 아키텍처를 근본적으로 바꾸었습니다.
이 문서는 ML‑first 아키텍처에서 하이브리드 건축 지능 플랫폼으로 진화하는 과정, 실수, 발견들을 기록합니다.

Tri‑Fort의 최초 버전은 전통적인 머신러닝 파이프라인을 중심으로 설계되었습니다. 사용자는 다음과 같이 입력합니다:

• 위치
• 프로젝트 유형
• 연면적
• 층 수
• 마감 수준
• 재료 선호도

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

• 특성 생성
• 회귀 모델에 피드
• 추정 건설 비용 반환

아키텍처는 다음과 같은 구조를 가졌습니다:

사용자 입력 → 기능 공학 → 머신러닝 모델 → 비용 예측

간단합니다. almeno 종이에 그려진 것처럼요.

대부분의 머신러닝 튜토리얼은 이미 깨끗한 데이터를 가정합니다. 건설 분야는 그렇지 않습니다. 우리가 접근할 수 있었던 데이터에는 다음과 같습니다:

• 양식 명세서 (BoQs)
• 작업 일정
• 비용 책
• 수량 조사관 보고서
• 프로젝트 사양
• 시장 조사 데이터셋
• 역사적 가격 문서
• 계약자 견적

처음에는 이 자료가 금광처럼 보였습니다. 실제로는 혼돈이었습니다. 파일은 다음과 같은 형식으로 존재했습니다:

• PDF 파일
• 스캔된 PDF 파일
• 엑셀 워크북
• OCR 출력
• 비용 일정
• 동일한 프로젝트의 여러 회차

같은 프로젝트는 보통 세 개나 네 개의 버전으로 존재합니다. 예를 들어:

• 키암부 몰 보Q
• 키암부 몰 수정된 보Q
• 키암부 몰 주변 벽 보Q
• 키암부 몰 2층 분양 보Q

인간에게는 이 문서들이 명확히 관련되어 있습니다. 머신러닝 파이프라인에서는 이들이 완전히 다른 프로젝트처럼 보입니다.

블라인드하게 모델을 훈련하기보다는 데이터 탐색 및 감사 파이프라인을 구축했습니다. 파이프라인은 다음과 같은 작업을 수행했습니다:

• 파일 인벤토리
• 프로젝트 그룹화
• 중복 탐지
• OCR 품질 평가
• 비용 회수 분석
• 데이터셋 준비도 점수

우리가 발견한 것은 놀라웠습니다. 수십 개의 문서와 수천 줄의 추출된 행들 중에서 복구 가능한 프로젝트 수는 9개에 불과했습니다. 실제 최종 비용의 증거를 제시한 프로젝트는 2개뿐이었습니다. 나머지 프로젝트들은 추정치였습니다.

이것은 중요한 구분점이었습니다. 대부분 데이터셋에는 추정 비용만 포함돼 있었고, 우리가 필요로 했던 것은 실제 최종 비용이었습니다. 이 두 개념은 동일하지 않습니다. 추정에 기반한 훈련은 모델이 추정치를 재현하도록 가르치며, 실제 세계를 예측하는 것은 가르치지 않습니다.

일시적으로 플랫폼은 생산 준비가 된 것처럼 보였습니다. API가 정상 작동했고, 인증도 잘 되었으며, 보고서와 인프라도 테스트에 합격했습니다. 심지어 머신러닝 파이프라인도 가상 검증을 통과했습니다. 하지만 데이터 감사는 불편한 진실을 드러냈습니다. 모델은 현실에서 학습하고 있지 않았으며, 다른 추정치들로부터 학습하고 있었습니다.

그 시점에 배포하면 지능의 환상이 만들어질 것이므로, 우리는 배포를 중단했습니다. 머신러닝 모델은 더 이상 우선순위가 아니었고, 데이터가 새로운 우선순위가 되었습니다.

데이터 감Во 중에 공식 수량 조사 비용 핸드북을 획득했습니다. 이 한 권이 모든 것을 바꾸었습니다. 핸드북을 PDF로 간주하는 대신, 구조화된 지식 원천으로 다루었습니다. 핸드북에는 다음과 같은 내용이 포함되어 있습니다:

• 지역별 건설 비용률
• 비용 벤치마크
• 건물 분류
• 측정 기준
• 비용 조정 인자
• 재료 가격 참조

갑자기 우리는 작은 ML 데이터셋보다 더 가치 있는 것을 가지게 되었습니다. 우리는 도메인 전문 지식을 가졌습니다.

다음 과제는 엔지니어링이었습니다. 정적 핸드북을 소프트웨어로 변환하려면 어떻게 해야 할까요? 우리는 핸드북 데이터를 구조화된 규칙으로 변환하는 추출 파이프라인을 구축했습니다. 시스템은 다음과 같은 요소를 식별합니다:

• 지역
• 요금 일정
• 건물 클래스
• 건설 카테고리
• 비용 배수기

이들은 머신‑읽기 가능한 규칙 그래프에 저장됩니다.

개념적으로:

핸드북 PDF → 추출 → 규칙 그래프 → 비용 지능 엔진

애플리케이션 전체에 하드코딩된 숫자 대신, 비용 엔진은 구조화된 건축 지식 기반으로 추론할 수 있습니다. 현재 아키텍처는 머신러닝에만 의존하지 않고, 세 가지 지능 원천을 결합합니다.

• 공식 QS 벤치마크 비용률
• 복구된 BoQs 및 프로젝트 데이터
• 추정자를 통해 수집한 입력값

아키텍처는 다음과 같은 구조를 가집니다:

사용자 입력 → 기능 엔진 → 핸드북 지능 → 역사적 비용 지능 → 비용 엔진 → 설명 가능한 추정

이 접근 방식은 순수 ML보다 훨씬 더 안정적입니다. 건설 프로젝트는 대량의 금액을 포함하므로 사용자는 블랙 박스를 신뢰하지 않습니다. 시스템이 “KES 18,400,000”이라고 말하면 다음 질문이 따라옵니다: 왜?

현대 AI 시스템은 이 문제에 자주 어려움을 겪지만, Tri‑Fort는 이제 추론 트레이스를 생성합니다. 예를 들어:

• 기본 요율: 54,000 KES/제곱미터
• 위치 조정: 나이로비 +20%
• 고급 마감 조정: +15%
• 두층 조정: +8%
• 역사적 수정: -2%

사용자는 추정값뿐만 아니라 그 근거도 볼 수 있습니다. 그 투명성이 신뢰를 생성합니다.

추정 엔진과 함께 플랫폼은 프로덕션 수준의 인프라가 필요했습니다. 스택에는 다음과 포함됩니다:

• FastAPI
• PostgreSQL
• 도메인 구동 아키텍처
• 백그라운드 작업 처리
• Next.js
• TypeScript
• 반응형 대시보드
• Docker Compose
• Caddy
• HTTPS 자동화
• 환경별 설정

모든 설정을 통해 VPS 배포에는 다음만 필요하다:

git pull
docker compose up -d --build

코드 변경 없음, 생산 전용 브랜치 없음, 수동 편집 없음.

만약 내일 이 프로젝트를 다시 시작할 수 있다면, 나는 세 가지 규칙을 따르겠다.

1. 데이터 크기를 절대 신뢰하지 마라.
2. 감사하라.
3. 천 줄은 다섯 개의 프로젝트를 나타낼 수 있다.

데이터가 부족할 때는 도메인 지식이 머신러닝을 능가한다. 경험 풍부한 수량 조사관들이 쓴 핸드북은 훈련이 부족한 모델을 능가할 수 있다.

사용자는 알고리즘이 아닌 답변에 관심이 있다. 누구도 AI를 사용하는 이유만으로 건축 견적가를 고용하지 않는다. 그들은 정확한 추정이 있기 때문에 고용한다.

장기 비전은 여전히 머신러닝이다. 하지만 현재 로드맵은 현실에 뿌리를 두고 있다. 다음 단계는 다음과 같은 데이터를 수집하는 데 집중한다:

• 최종 계정서
• 완료 증명서
• 계약자 영수증
• 변동 주문
• 실제 프로젝트 비용

데이터셋이 성장함에 따라 머신러닝은 더욱 중요해질 수 있습니다. 최종적으로 플랫폼은 진정한 하이브리드 시스템으로 진화할 것입니다:

도메인 지식
+ 역사적 프로젝트
+ 머신러닝
+ 인간 설명 가능성

그것이 미래다. AI가 전문성을 대체하는 것이 아니라, AI가 이를 증폭한다.

Tri‑Fort를 구축하면서 얻은 가장 큰 교훈은 성공적인 AI 제품이 모델에만 의존하지 않다는 것이다. 문제를 충분히 깊이 이해하여 모델이 답이 아니라는 것을 아는 데 있다. 건설 견적에서 지능은 다음과 같은 요소들의 결합에서 비롯된다:

• 엔지니어링
• 수량 조사
• 역사적 데이터
• 도메인 전문성
• 소프트웨어 아키텍처
• 머신러닝은 그 퍼즐의 한 조각일 뿐이다.

때로는 가장 현명한 엔지니어링 결정은 reliance on it을 피하는 것임을 아는 것이다.