지하 3층 기계실. 신호는 한 칸이었다가 사라졌다. 현장 책임자는 태블릿에서 배관 충돌 이슈를 열었다. 화면에는 AI가 만든 요약이 있었지만, 그것이 마지막 동기화 전 내용인지 알 수 없었다. 사진은 촬영됐는데 업로드됐는지 표시되지 않았고, ‘조치 완료’ 버튼은 눌렸지만 서버에 반영됐는지는 확인할 길이 없었다. 회의실에서는 잘 작동하던 제품이 철골과 콘크리트 사이에서 갑자기 불안한 추측 도구가 됐다.
건설 소프트웨어는 일반적인 업무용 웹 앱과 다른 환경에서 사용된다. 대형 모델과 도면, 성능이 제각각인 장치, 밝은 햇빛, 장갑, 먼지, 한 손 조작, 불안정한 연결이 기본 조건이다. 현장을 ‘나중에 최적화할 예외’로 보면 제품은 사무실 데모를 벗어나지 못한다.
그리고 더 중요한 사실이 있다. AEC에서 프런트엔드는 단순한 화면이 아니다. 사용자가 어떤 버전을 공식으로 믿고, AI의 제안과 승인된 결정을 구분하며, 작업을 멈추거나 계속할지를 판단하는 프로젝트 통제 장치다.
01 · The operating environment현장은 극단적인 환경이 아니라 실제 운영 환경이다
현장 사용자는 렌더링 엔진이나 프레임워크에 관심이 없다. 지금 보고 있는 도면이 최신 승인본인지, 자신의 검사 결과가 저장됐는지, 다음 행동이 무엇인지 알고 싶을 뿐이다. 화면이 3초 빨라져도 이 세 가지가 불명확하면 제품은 신뢰를 잃는다.
따라서 현장 제품의 요구사항은 기능 목록이 아니라 상황으로 써야 한다. “사용자는 도면을 볼 수 있다”가 아니라 “통신이 끊긴 지하에서 한 손으로 최신 캐시 도면을 열고, 승인 상태와 마지막 동기화 시점을 확인하며, 사진과 의견을 남길 수 있다”가 되어야 한다. 이렇게 쓰면 오프라인 저장, 상태 표시, 큰 터치 영역, 충돌 처리 같은 설계가 부가 기능이 아니라 핵심 요구로 올라온다.
02 · Performance is prioritization성능 최적화는 더 빨리 그리는 일이 아니라 덜 가져오는 일이다
BIM과 도면 뷰어의 흔한 목표는 전체 모델을 가능한 한 빨리 여는 것이다. 하지만 현장 작업자가 언제나 전체 모델을 필요로 하는 것은 아니다. 12층 동측 화장실의 검사 업무라면 현재 층, 해당 구역, 관련 공종, 검사 대상 객체, 최신 변경만 먼저 필요하다.
타일링, 컬링, LOD, 반복 객체 인스턴싱, 점진적 로딩은 그래픽 기법이면서 동시에 정보 우선순위 전략이다. 제품은 “무엇을 전부 보여줄까”보다 “사용자가 다음 30초 안에 어떤 결정을 해야 하는가”를 먼저 물어야 한다.
가장 큰 모델을 여는 속도가 아니라, 현재 작업에 필요한 최소한의 신뢰 가능한 맥락이 화면에 도착하는 시간으로 측정하라.
03 · Offline first, not offline later오프라인 퍼스트는 로컬 데이터를 공식 진실로 만든다는 뜻이 아니다
서비스 워커는 네트워크 요청을 가로채고 캐시된 응답을 제공할 수 있으며, Cache Storage는 도면·아이콘·애플리케이션 자산을 오프라인에 보관하는 데 사용된다.1 IndexedDB는 검사표, 이슈, 메타데이터처럼 구조화된 데이터를 브라우저에 저장하고 네트워크와 무관하게 조회할 수 있게 한다.2 기술적으로는 이미 충분한 도구가 있다.
문제는 개념이다. 일부 설계는 “로컬 데이터베이스를 Single Source of Truth로 삼는다”고 말한다. 사용 경험 측면에서는 로컬이 즉시 반응해야 하지만, 프로젝트 거버넌스 측면에서 공식 상태는 서버나 CDE의 승인 기록에 남아야 한다. 로컬 데이터는 작업 가능한 운영 복제본이다.
이 구분이 없으면 오프라인에서 변경한 ‘통과’ 상태와 서버에서 다른 책임자가 기록한 ‘재검사’ 상태가 자동 병합될 수 있다. 데이터 구조상 병합이 가능해도 의미와 권한은 충돌한다.
04 · Semantic conflict협업 충돌은 기술적 병합보다 의미와 권한의 문제다
실시간 협업 기술은 여러 사용자의 변경을 병합할 수 있다. 텍스트 편집이나 독립적인 주석처럼 연산이 충돌하지 않는 경우에는 매우 유용하다. 하지만 AEC의 중요한 상태는 단순한 글자가 아니다.
한 사용자는 검사 결과를 ‘통과’로 바꾸고, 다른 사용자는 같은 항목을 ‘재검사’로 지정할 수 있다. 설계자는 Rev.8을 발행했지만 현장 책임자는 오프라인 상태에서 Rev.7 기준 작업 완료를 기록할 수 있다. 권한이 없는 사용자가 연결이 끊긴 동안 승인 상태를 바꿀 수도 있다. 이것은 CRDT나 마지막 저장 우선 규칙만으로 해결할 수 없다.
시스템은 충돌을 세 종류로 구분할 필요가 있다. 단순 필드 충돌은 규칙으로 병합하고, 객체·버전 충돌은 사용자가 차이를 비교하게 하며, 승인·안전·계약 상태의 충돌은 자동 병합하지 않고 책임자에게 에스컬레이션해야 한다. 복구 가능한 제품은 충돌이 없는 제품이 아니라 충돌의 성격을 드러내는 제품이다.
05 · Interface as governance프런트엔드는 프로젝트 거버넌스를 시각화한다
좋은 현장 화면은 정보를 많이 보여주는 화면이 아니다. 지금 믿어도 되는 것과 아직 확인이 필요한 것을 구분해주는 화면이다. 최소한 다음 항목은 숨겨져서는 안 된다.
파일명이 아니라 공식 개정, 용도, 승인 범위를 명확히 표시한다.
온라인 여부, 마지막 동기화 시점, 미전송 변경 수, 재시도 상태를 보여준다.
요약·추천·예측을 승인된 지시처럼 보이게 만들지 않는다.
AI 결과에서 원문, 모델 객체, 문서 버전으로 즉시 이동할 수 있어야 한다.
누가 결정해야 하고, 사용자가 지금 무엇을 해야 하는지 한 화면에서 이해한다.
정상 경로를 우회하거나 작업을 중지해야 할 때 분명한 통로를 제공한다.
ISO 19650-4가 정보 교환의 과정과 의사결정 기준을 통해 프로젝트·자산 정보모델의 품질을 보장하려는 것도 화면 뒤에 있는 정보 상태와 책임이 중요하기 때문이다.4 프런트엔드는 그 상태를 사용자가 실제로 이해하고 행동할 수 있게 번역해야 한다.
06 · Designed for bodies현장 UX는 사람의 몸과 환경에서 시작한다
장갑을 낀 손, 흔들리는 발판, 햇빛 반사, 한 손 조작은 디자인 취향이 아니다. 안전과 데이터 품질에 직접 영향을 준다. 터치 영역이 작으면 사용자는 잘못된 상태를 누르고, 대비가 낮으면 경고를 놓치며, 입력 단계가 길면 사진을 메신저로 보내고 나중에 등록하겠다고 생각한다. ‘나중’은 종종 오지 않는다.
W3C의 WCAG 2.2 해설은 향상된 기준의 예로 44×44 CSS 픽셀 터치 영역을 제시하며, 한 손 사용이나 흔들리는 환경, 미세 동작이 어려운 사용자에게 큰 타깃이 도움이 된다고 설명한다.3 건설현장에서는 접근성 원칙이 곧 작업성 원칙이 된다.
현장 인터페이스는 버튼을 크게 만드는 데서 끝나지 않는다. 핵심 행동을 화면 하단의 엄지 영역에 두고, 위험한 변경은 분명히 확인시키며, 사진과 위치·시간·객체를 자동으로 묶고, 음성이나 빠른 선택으로 입력 부담을 줄여야 한다. 무엇보다 작업이 저장됐는지 사용자에게 확실히 알려야 한다.
07 · Close the loop현장은 데이터의 소비자가 아니라 새로운 증거의 생성자다
많은 AI 제품은 프로젝트 데이터를 읽고 답을 만드는 데서 멈춘다. 그러나 AEC에서 가치가 완성되는 지점은 답변 이후다. AI가 품질 위험을 찾아도 담당자에게 전달되지 않으면 소용이 없다. 담당자가 조치를 결정해도 현장에서 실행되지 않으면 소용이 없다. 실행됐어도 사진, 검사 결과, 실제 설치 상태가 다시 기록되지 않으면 다음 판단은 낡은 데이터 위에서 이루어진다.
예를 들어 AI가 사진과 이슈 기록에서 동일 구역의 누수 징후를 반복 감지했다고 하자. 시스템은 관련 도면, 최근 설계변경, 이전 부적합 기록을 함께 묶어 품질 책임자에게 보낸다. 책임자는 재검사를 지시하고, 현장 작업자는 오프라인에서도 체크리스트와 위치를 확인한다. 결과 사진과 측정값이 동기화되면 이슈가 닫히고, 같은 패턴을 탐지하는 다음 모델의 근거가 된다.
이 루프가 구축되면 AI의 정확도뿐 아니라 조직의 대응 능력도 향상된다. 어떤 경고가 무시됐는지, 어떤 추천이 실제 결함을 찾았는지, 조치 이후 문제가 재발했는지를 측정할 수 있다. 모델 평가와 프로젝트 성과가 분리되지 않는다.
08 · Test where work happens제품 수용 테스트는 회의실이 아니라 현장에서 해야 한다
현장 파일럿은 출시 직전의 확인 단계가 아니다. 제품 요구사항을 발견하는 연구다. 다음 상황을 실제로 시험해야 한다.
- 비행기 모드에서 도면, 작업 목록, 검사표를 열고 저장할 수 있는가.
- 낮은 사양의 장치에서 큰 프로젝트를 열어도 핵심 업무가 멈추지 않는가.
- 밝은 햇빛과 장갑, 한 손 사용에서 상태와 경고를 구분할 수 있는가.
- 같은 항목을 두 사용자가 오프라인에서 다르게 변경했을 때 충돌이 보이는가.
- 앱이 종료되거나 장치가 재시작돼도 미전송 작업을 복구할 수 있는가.
- 사용자가 AI 결과에서 원문과 공식 버전으로 돌아갈 수 있는가.
이 테스트를 통과하지 못하면 프레임워크를 바꾸는 것보다 정보의 범위, 동기화 전략, 상태 모델, 작업 흐름을 다시 설계해야 한다. React와 Vue 가운데 무엇을 골랐는지는 그다음 문제다.
09 · The real stackAEC AI의 진짜 스택은 네 개의 평면으로 구성된다
세 편의 논의를 한 구조로 정리하면 다음과 같다. Control Plane은 누가 언제 무엇을 하는지 정의하는 워크플로다. Context Plane은 정보가 무엇을 뜻하고 어떤 출처와 버전을 갖는지 관리한다. Execution Plane은 결정이 현장에서 실행되고 결과가 다시 기록되게 한다. 그리고 Assurance Plane은 세 층을 가로질러 권한, 승인, 검증, 보안, 감사 이력을 보장한다.
어느 하나만으로는 부족하다. 워크플로 없이 AI를 붙이면 책임 없는 추천이 늘어난다. 맥락 없는 자동화는 잘못된 데이터를 더 빨리 움직인다. 현장 실행이 없으면 시스템은 대시보드에 머문다. 보증 계층이 없으면 조직은 결과를 신뢰하거나 방어할 수 없다.
좋은 건설 소프트웨어는 완벽한 연결을 전제하지 않는다. 연결이 끊겨도 일할 수 있고, 다시 연결됐을 때 무엇이 달라졌는지 알 수 있으며, 충돌을 숨기지 않고, 사용자가 현재 정보의 신뢰도를 판단할 수 있게 한다. 그때 프런트엔드는 화면을 넘어 프로젝트 운영의 일부가 된다.