월요일 오전 7시 40분. 현장 반장이 태블릿에서 배관 슬리브 도면을 열었다. 파일명 끝에는 Rev.6이 붙어 있었다. 지난 금요일 설계팀이 승인한 것은 Rev.7이었다. 바뀐 위치는 180밀리미터 옆. 누구도 대단한 실수를 한 것은 아니었다. 최신본은 문서 시스템에 있었고, 승인 메일도 발송됐으며, 담당자들은 모두 바빴다. 문제는 정보가 존재했지만 작업까지 도달하지 않았다는 데 있었다.
AEC 현장에서 낯설지 않은 장면이다. 프로젝트는 대개 한 번의 거대한 판단으로 움직이지 않는다. 수백 명이 수천 개의 작은 결정을 넘겨받고, 확인하고, 승인하고, 다시 전달하면서 앞으로 나아간다. 그래서 리스크는 기술 난이도만으로 설명되지 않는다. 업무와 업무 사이의 틈, 다시 말해 핸드오프에서 자란다.
자동화가 중요한 이유도 여기에 있다. 좋은 자동화는 사람을 빼는 기술이 아니다. 해야 할 일이 빠지지 않고, 예외가 묻히지 않으며, 누가 무엇을 근거로 결정했는지 남게 만드는 프로젝트 통제 방식이다.
01 · Where risk begins프로젝트는 작업보다 핸드오프에서 흔들린다
설계자는 도면을 발행한다. 문서관리자는 상태를 확인한다. 시공팀은 작업 가능 여부를 판단한다. 구매팀은 자재 발주를 바꾼다. 공정 담당자는 후속 작업의 영향을 계산한다. 품질 담당자는 검사 항목을 조정한다. 설계변경 한 건이 끝나기까지 여러 조직과 시스템을 통과한다.
각 단계가 따로 보면 정상이어도 전체 흐름은 실패할 수 있다. 승인된 도면이 구매 시스템에 반영되지 않거나, 현장 지시가 최신 모델 객체와 연결되지 않거나, 부적합 조치가 완료됐지만 공식 기록의 상태가 그대로 남는 식이다. 이때 문제는 ‘데이터 부족’보다 상태 전환이 보이지 않는 것에 가깝다.
ISO 19650-1이 정보관리를 단순한 파일 저장이 아니라 교환, 기록, 버전 관리, 조직화를 포함하는 전 생애주기 프레임으로 다루는 이유도 같다.1 한국건설기술연구원의 해설 역시 효과적인 BIM 정보관리를 위해 책임, 권한, 업무 범위를 명확히 하고 책임 매트릭스에 반영해야 한다고 강조한다.2 도구보다 먼저 흐름과 책임이 정의돼야 한다는 뜻이다.
02 · Consistency over speed자동화의 진짜 목적은 속도가 아니라 편차를 줄이는 것이다
자동화 프로젝트를 시작하면 가장 먼저 등장하는 질문은 보통 “몇 시간을 줄일 수 있는가”다. 틀린 질문은 아니지만, AEC에서는 충분하지 않다. 처리시간이 빨라졌어도 잘못된 버전이 전달되거나, 예외 상황이 자동으로 통과하거나, 책임자가 불분명하다면 리스크는 오히려 더 빠르게 확산된다.
자동화의 첫 번째 성과는 생산성보다 일관성이다. 제출물이 들어오면 같은 기준으로 필수 항목을 검사하고, 정해진 책임자에게 배정하고, 기한을 부여하고, 지연 시 에스컬레이션하고, 최종 결정과 근거를 기록한다. 개인의 기억과 메일함에 의존하던 통제가 조직의 기본 동작으로 바뀐다.
여기서 중요한 점은 ‘모든 것을 자동으로 승인한다’가 아니다. 자동화는 사람이 판단해야 할 순간을 줄이는 것이 아니라, 판단할 가치가 있는 순간만 선명하게 남기는 일이다. 누락 없는 자료, 최신 상태, 관련 변경 이력, 예상 공정 영향이 함께 도착하면 엔지니어는 정보 수집보다 판단에 시간을 쓸 수 있다.
03 · Human in the right place자동화해야 할 것, AI가 도와야 할 것, 사람이 결정해야 할 것
AEC 업무를 한 덩어리로 보고 “AI로 자동화할 수 있는가”라고 묻으면 경계가 흐려진다. 더 현실적인 방법은 업무를 세 층으로 나누는 것이다.
규칙이 명확하고 결과가 결정적인 일은 자동 실행에 적합하다. 필수 필드 확인, 문서 상태 검증, 담당자 라우팅, 기한 알림, 승인 후 후속 작업 생성 같은 업무다. 반면 맥락을 읽고 가능성을 제시하는 일은 AI가 보조할 수 있다. 회의록에서 리스크 후보를 찾고, 유사한 RFI를 검색하고, 수백 건의 이슈를 공정 영향에 따라 정렬하는 식이다.
구조 안전, 설계 적합성, 계약 책임, 지급 판단처럼 결과에 책임이 따르는 결정은 사람이 남아야 한다. NIST AI RMF가 AI 위험관리를 모델 성능 하나가 아니라 설계·개발·사용·평가 전 과정의 거버넌스로 다루는 것도 이 경계가 기술만으로 정해지지 않기 때문이다.4
설계변경 한 건을 폐쇄 루프로 바꾸면
예를 들어 배관 샤프트 위치가 바뀌었다고 하자. 이메일 한 통으로 끝내면 각 팀이 알아서 해석해야 한다. 워크플로로 설계하면 변화가 연쇄적으로 번진다.
승인된 변경이 등록되면 관련 도면·모델 객체·변경 사유를 하나의 변경 레코드로 묶는다.
공정, 원가, 구매, 품질 담당자에게 영향 검토 작업을 자동 생성하고 기한을 부여한다.
AI는 과거 유사 변경과 연관된 RFI·클레임·납기 이슈를 찾아 검토자에게 제시한다.
각 책임자가 영향을 승인하거나 예외를 선언한다. 승인 전에는 현장 발행 상태로 바뀌지 않는다.
현장 조치와 사진, 검사 결과가 다시 변경 레코드에 연결되면 비로소 완료로 닫힌다.
04 · Design for failure완전 자동화보다 예외가 잘 보이는 자동화가 낫다
자동화가 실패하는 가장 위험한 방식은 멈추는 것이 아니다. 잘못된 상태로 조용히 계속 움직이는 것이다. 담당자가 바뀌었는데 이전 권한으로 승인 요청이 나가거나, 문서의 개정번호는 맞지만 발행 상태가 ‘작업용’인 경우처럼 시스템이 형식만 보고 통과시키는 순간이 있다.
따라서 좋은 워크플로는 정상 경로만 그리지 않는다. 입력이 불완전하면 어디에서 멈출지, 책임자가 부재하면 누구에게 넘길지, 두 시스템의 상태가 다르면 무엇을 공식으로 볼지, AI의 신뢰도가 낮으면 어떻게 표시할지까지 설계한다.
무엇이 업무를 시작시키는가? 누가 최종 책임자인가? 어떤 조건에서 사람에게 넘기는가? 완료됐다는 증거는 무엇인가? 이 네 가지가 답되지 않으면 자동화는 흐름이 아니라 단축키에 가깝다.
특히 안전 정보는 별도의 문서 묶음으로 남겨두기보다 프로젝트와 자산의 생애주기 동안 식별·공유·전달되는 구조로 관리해야 한다. 2025년에 발행된 ISO 19650-6도 보건·안전 정보를 초기부터 구조화하고 협업적으로 순환시키는 정보 사이클을 제시한다.3 자동화는 그 사이클을 유지하는 수단이어야지, 안전 판단을 대신하는 블랙박스가 되어서는 안 된다.
05 · Measure prevention시간 절감만 측정하면 잘못된 자동화를 만든다
‘월 500시간 절감’은 경영진에게 설명하기 쉽다. 하지만 프로젝트 리스크를 줄였는지는 말해주지 않는다. 자동화가 실제 통제력을 높였는지 확인하려면 흐름의 품질을 측정해야 한다.
승인·조치·검토가 약속된 시간 안에 끝나는가.
현장과 협력사가 공식 최신본을 놓친 횟수는 줄었는가.
정상 경로에서 벗어난 이슈가 발견되고 닫히기까지 얼마나 걸리는가.
같은 유형의 문제가 다시 나타나는 빈도와 비용은 줄었는가.
결정 당시의 문서, 버전, 승인자, 사유를 재구성할 수 있는가.
사용자가 우회하지 않고 실제 업무를 시스템 안에서 끝내는가.
자동화의 성과는 처리한 작업의 수보다 예방한 위험 사건과 빨라진 복구에 가깝다. 이 관점이 없으면 조직은 의미 없는 알림과 자동 보고서를 늘리면서도 프로젝트 통제력은 얻지 못한다.
06 · Start where it hurts첫 프로젝트는 작고, 아프고, 측정 가능해야 한다
처음부터 전사 플랫폼을 바꾸려 하지 않는 편이 좋다. 발생 빈도가 높고, 전달 단계가 많고, 오류 비용이 크며, 현재 상태를 측정할 수 있는 하나의 흐름을 고른다. RFI 배정, 설계변경 영향 검토, 자재 승인, 품질 부적합 조치, 인수인계 데이터 검증이 좋은 후보가 된다.
- 현재 흐름을 관찰한다. 공식 절차만이 아니라 실제로 사용되는 메일, 메신저, 엑셀, 구두 확인까지 본다.
- 완료 조건과 예외를 먼저 정의한다. “승인됨”이 누구에 의해 어떤 용도로 승인된 것인지 분명히 한다.
- 규칙 기반 자동화부터 적용한다. 데이터가 쌓이기 전에는 화려한 AI보다 라우팅, 검증, 상태 관리가 더 큰 효과를 낸다.
- AI는 비정형 정보의 입구에 둔다. 문서 분류, 요약, 유사 사례 검색부터 시작하고, 결과에는 근거를 붙인다.
- 전후 지표를 비교한다. 시간이 아니라 지연, 오류, 재작업, 예외 종료를 함께 본다.
자동화는 프로젝트를 ‘스스로 돌아가게’ 만드는 일이 아니다. 사람이 중요한 결정을 놓치지 않도록 흐름을 설계하는 일이다. 그 기반이 만들어지면 조직은 사후 대응에서 예방으로 이동할 수 있다.
그다음 질문이 남는다. 이 워크플로가 읽어야 할 데이터가 완벽하지 않다면 AI를 시작할 수 없는가. 답은 의외로 단순하다. 완벽하지 않아도 시작할 수 있다. 다만 어떤 결정에 어느 정도의 확실성이 필요한지는 먼저 알아야 한다.