회의실에 건축가, 소방 엔지니어, 시공사, 시설관리자가 모였다. 안건은 ‘문’의 공통 정의였다. 건축가는 벽에 삽입된 요소를 떠올렸고, 소방 엔지니어는 방화구획의 일부를 봤다. 시공사는 납기가 긴 패키지로, 시설관리자는 점검과 교체가 필요한 자산으로 이해했다. 네 사람의 말은 모두 맞았다. 문제는 두 시간이 지나도록 “방화 성능 값이 빠진 문은 어디인가”라는 원래 질문에 아무도 답하지 못했다는 데 있었다.
AEC 조직은 데이터가 준비되지 않았기 때문에 AI를 시작할 수 없다고 자주 말한다. 그래서 명명 규칙을 통일하고, 분류체계를 정비하고, 온톨로지를 만들고, 모든 시스템을 지식 그래프로 연결하려 한다. 이 작업은 필요할 수 있다. 다만 필요하다는 사실과 먼저 해야 한다는 사실은 다르다.
데이터 준비도를 조직 전체의 단일 등급으로 보면 프로젝트는 오래 ‘준비 중’에 머문다. 더 유용한 질문은 이것이다. 이 데이터는 지금 개선하려는 결정에 충분한가?
01 · The calm box fallacy아키텍처 다이어그램의 ‘평온한 상자’
전형적인 AI 아키텍처 그림을 떠올려보자. 왼쪽에는 Revit, IFC, Excel, 문서관리 시스템, ERP처럼 현실의 복잡한 상자가 놓인다. 가운데에는 모든 중복과 모호성을 정리한 거대한 지식 그래프가 있다. 오른쪽에는 반짝이는 AI 아이콘이 기다린다.
그림 속 중앙 상자는 늘 평온하다. ‘L1’, ‘Level 01’, ‘1F’, ‘FFL +4500’이 같은 층인지 누군가 이미 해결했다. ‘AHU-03’과 ‘Air Handling Unit 3’이 같은 장비인지도 알고 있다. 승인이라는 단어가 설계 승인인지, 발주자 승인인지, 시공용 발행인지도 구분한다.
그러나 그 평온함은 공짜가 아니다. 누군가는 정의하고, 매핑하고, 예외를 합의하고, 원천 스키마가 바뀔 때마다 유지해야 한다. 데이터의 모호성이 사라지는 것이 아니라 매핑 규칙과 거버넌스 회의로 이동한다. 그래프가 틀렸을 때는 오히려 잘못된 의미가 조직 전체에 일관되게 퍼질 수 있다.
02 · Ready enough당신의 데이터는 이미 시작할 만큼 구조화되어 있다
AEC 데이터는 흔히 생각하는 것보다 많은 맥락을 이미 품고 있다. BIM 객체에는 형상과 속성이 있고, 문서에는 작성자와 상태와 개정 이력이 있으며, 이슈에는 담당자와 기한이 있고, 공정에는 선후 관계가 있다. 서로 완벽히 연결되지 않았을 뿐 ‘무의미한 원시 데이터’는 아니다.
Speckle의 공식 문서는 파일 대신 객체를 기본 단위로 다루고, 프로젝트–모델–버전–객체의 구조와 증분 전송을 제공한다고 설명한다.1 모델을 전송할 때마다 새 버전이 생성되고, 시간·출처 애플리케이션·보낸 사람 같은 메타데이터가 붙어 변경 비교와 추적이 가능하다.2 이것은 완성된 온톨로지는 아니지만 질문을 시작하기에는 충분한 구조다.
중요한 전환은 “데이터가 궁극적으로 무엇이어야 하는가”보다 “이번 질문에 어떤 표현이 가장 적합한가”를 묻는 것이다. 대량 집계는 컬럼형 테이블이 빠를 수 있고, 애플리케이션 흐름은 JSON과 객체 API가 편할 수 있다. 관계를 여러 단계 따라가야 한다면 그래프 투영이 유리하다. 표현 방식이 질문을 따라가면 데이터 모델을 영구적으로 확정하기 전에 가치를 시험할 수 있다.
03 · Question first형식화는 시작 조건이 아니라 학습 결과가 될 수 있다
기존 방식은 의미를 먼저 완벽하게 인코딩한 뒤 추론을 시작했다. 현대 AI가 열어준 가능성은 순서를 뒤집는 데 있다. 모델은 서로 다른 스키마를 살펴보고, 이름과 설명의 패턴을 비교하고, ‘L1’과 ‘First Floor’가 같은 층일 가능성을 제시할 수 있다. 처음부터 맞을 필요는 없다. 틀리는 지점을 기록할 수 있으면 된다.
예를 들어 “모든 설비실 가운데 필수 장비 속성이 빠진 공간을 찾아라”라는 질문을 먼저 던진다. AI와 규칙이 현재 데이터에서 설비실 후보를 모으고, 누락 속성을 표시한다. 검토자가 잘못 분류된 공간을 고치면 그 오류는 다음 단계의 자산이 된다. 반복적으로 같은 혼동이 발생하는 속성만 관리형 식별자나 매핑 규칙으로 승격한다.
이 접근은 데이터 거버넌스를 가볍게 보자는 말이 아니다. 반대로 거버넌스의 우선순위를 실제 실패가 드러낸 곳에 집중하자는 뜻이다. 모든 문을 정의하는 회의보다, 방화문 속성 누락을 반복해서 발생시키는 세 가지 명명 패턴을 먼저 해결하는 편이 프로젝트에 더 유용하다.
04 · Progressive formalization모든 질문에 같은 수준의 의미적 확실성이 필요하지 않다
AI가 회의록을 요약하는 일과, 방화구획 적합성을 판정하는 일은 같은 데이터 준비도를 요구하지 않는다. 전자는 원문 링크와 인간 검토가 있으면 불완전한 분류도 유용할 수 있다. 후자는 객체 식별, 적용 기준, 모델 버전, 판단 규칙이 재현 가능해야 한다.
따라서 데이터 준비도를 ‘완료/미완료’로 나누기보다 의미적 확실성의 사다리로 보는 편이 낫다.
1단계: 탐색적 추론
검색, 요약, 문서 분류, 관련 자료 추천, 잠재 이슈 발견이 여기에 속한다. 결과는 확률적일 수 있고, 사용자는 원문과 근거를 확인한다. 이 단계에서는 완벽한 공통 분류체계보다 빠른 피드백이 중요하다.
2단계: 반복 업무 검증
정기 보고, 제출물 검사, 속성 누락 확인, 승인 라우팅처럼 같은 질문을 반복해야 하는 업무다. 필수 속성, 상태 코드, 관리형 식별자, 검증 스키마가 필요해진다. buildingSMART의 IDS는 IFC 모델에 어떤 객체·분류·속성·값이 포함되어야 하는지를 사람이 읽고 기계가 검증할 수 있는 형태로 정의한다.3 모든 건설 개념을 거대한 온톨로지로 만들지 않고도 업무에 필요한 요구사항을 결정적으로 형식화할 수 있는 좋은 예다.
3단계: 고위험 결정론적 의미
안전, 규제, 계약, 장기 자산관리처럼 결과를 재현하고 방어해야 하는 업무다. 여러 시스템을 넘는 지속적인 객체 식별, 출처, 버전, 관계의 시간 변화가 중요해진다. 이때 온톨로지와 지식 그래프의 비용은 충분히 정당화될 수 있다.
05 · Earn the graph지식 그래프가 비용을 벌어들이는 순간
그래프를 써야 할 이유는 “AEC 데이터에는 관계가 많다”가 아니다. 모든 업무 데이터에는 관계가 있다. 그래프가 유력해지는 것은 관계 구조 자체가 질문의 핵심일 때다.
공간–방화구획–문–설비–점검 기록처럼 여러 단계를 반복해서 따라가야 한다.
설계 객체가 조달 품목, 설치 자산, 유지관리 대상과 장기간 같은 정체성을 유지해야 한다.
같은 입력에 같은 결과가 나와야 하고, 어떤 관계를 따라 결론에 도달했는지 설명해야 한다.
결과가 승인, 책임, 준수 여부의 근거가 되어 변경 이력과 출처를 방어해야 한다.
반대로 한 번의 수량 집계, 단순 속성 누락 검사, 프로젝트 내부 검색처럼 질문이 단순하고 수명이 짧다면 테이블, 객체 API, 검색 인덱스, 필요 시 생성하는 그래프 투영으로 충분할 수 있다. 영구 모델은 영구 가치가 있을 때 만든다.
06 · Ambiguity moves형식화는 모호성을 없애지 않는다. 위치를 바꾼다
온톨로지가 완성되면 어려운 일이 끝난다고 생각하기 쉽다. 실제로는 어려운 일이 다른 주소로 이사한다. 원천 시스템의 불일치는 매핑 테이블의 분쟁이 되고, 서로 다른 분류는 동등성 규칙의 논쟁이 된다. “승인됨”이라는 상태는 설계 승인, 발주자 승인, 시공용 승인 중 무엇인지 다시 정의해야 한다.
이 과정이 무의미하다는 뜻은 아니다. 모호성을 어디에서 누가 책임질지 명확해진다는 점에서 진전이다. 다만 형식화가 자동으로 진실을 만든다고 믿으면 안 된다. 그래프도 프로젝트의 한 해석이며, 원천과 버전, 결정권자를 함께 관리해야 한다.
ISO 19650이 정보 요구사항, 책임, 전달 계획, 공통데이터환경을 하나의 관리 프로세스로 다루는 이유도 데이터 모델만으로 협업 문제가 해결되지 않기 때문이다.4
07 · Semantic debt의미 부채는 없애는 것이 아니라 가치에 따라 갚는다
소프트웨어에는 기술 부채가 있듯 AEC 데이터에는 의미 부채가 있다. 같은 장비가 세 이름으로 불리고, 공간 코드가 단계마다 바뀌고, 모델 객체와 현장 자산이 느슨하게 연결된다. 모든 부채를 한 번에 갚는 프로젝트는 대개 끝나지 않는다.
대신 AI 활용 과정에서 의미 부채를 계측할 수 있다. 어떤 질문에서 매핑이 자주 틀리는지, 어떤 속성이 승인 지연을 만드는지, 어떤 객체의 동일성 판단이 반복적으로 사람의 개입을 요구하는지 기록한다. 빈도와 오류 비용이 높은 항목부터 규칙, 표준 용어, 식별자, 그래프로 승격한다.
Formalize by consequence, not by ambition. 형식화는 얼마나 거대한 모델을 만들고 싶은지가 아니라, 잘못된 답이 어떤 결과를 만드는지에 따라 결정한다.
이 관점은 AI 프로젝트를 ‘준비도 프로그램’에서 ‘학습 시스템’으로 바꾼다. 질문을 실행하고, 불확실성을 관찰하고, 필요한 의미만 강화한다. 데이터는 어느 날 갑자기 완벽해지는 것이 아니라 사용을 통해 점점 신뢰할 수 있게 된다.
08 · A practical start실무에서는 질문 하나로 시작한다
좋은 첫 질문은 가치가 분명하고, 현재 데이터로 어느 정도 시도할 수 있으며, 틀렸을 때 사람이 검토할 수 있어야 한다. 예를 들면 “이번 발행본에서 방화 성능 속성이 누락된 문과 그 문이 속한 구획을 찾아라”가 될 수 있다.
- 도면, IFC, 제출물, 이슈 기록 가운데 답에 필요한 원천을 연결한다.
- AI와 규칙으로 후보를 만들고 각 결과에 원문, 객체 ID, 버전을 붙인다.
- 소방 엔지니어가 오탐과 누락을 검토하고 오류 유형을 분류한다.
- 반복되는 오류만 IDS, 관리형 용어, 관계 규칙으로 형식화한다.
- 다음 발행본에서 정확도와 검토시간, 누락 감소를 비교한다.
이 방식은 처음부터 완전한 지식 그래프를 약속하지 않는다. 대신 어느 관계가 실제로 중요하고, 어떤 추론이 결정적이어야 하며, 어디에 유지비를 써야 하는지를 증명한다. 필요성이 충분히 드러나면 그때 그래프를 구축하면 된다. 더 작게 시작했기 때문에 오히려 더 정확한 그래프를 만들 수 있다.
그러나 데이터가 정확히 해석되고 AI가 좋은 제안을 만들었다고 해서 일이 끝나는 것은 아니다. 현장에서 열리지 않거나, 최신 승인본인지 알 수 없거나, 변경 결과가 다시 시스템으로 돌아오지 않는다면 그것은 지능이 아니라 데모다.