영국이 건축 인허가를 반으로 줄인다는 뉴스, 진짜 신호는 딴 데 있어요
AI가 인허가 처리 시간을 절반으로 줄인다는 헤드라인 뒤에서, 실제로 시간을 줄인 건 모델이 아니라 구조화된 데이터와 명시적인 규칙이었어요.
영국이 건축 인허가를 반으로 줄인다는 뉴스, 진짜 신호는 딴 데 있어요
헤드라인 두 개가 붙어다니는데, 사실은 다른 도구예요

“영국이 AI로 건축 인허가 시간을 절반으로 줄인다.”
이 문장, 지난 몇 달간 링크드인이랑 트위터에서 열 번은 본 것 같아요. 저도 처음엔 “아, 드디어 규제 영역에도 제대로 된 AI가 붙었구나” 하고 넘겼습니다. 그런데 영국 정부 발표문과 MHCLG(주택·지역사회·지방정부부) 리포트를 직접 확인해 보니, 헤드라인이 전혀 다른 두 프로젝트를 하나로 뭉쳐 놓은 거였습니다.
하나는 Extract. i.AI 팀이 Google DeepMind의 Gemini 위에 만든 문서 디지털화 도구예요. 수십 년 된 인허가 PDF, 스캔 지도, 손글씨 메모를 구조화된 지리 좌표 데이터로 바꿔 줍니다. 2026년 봄부터 영국 전체 카운슬에 공개됐고, 지금은 실서비스로 운영 중이에요.
다른 하나는 APD(Augmented Planning Decisions). DeepMind와 Google Cloud, Faculty가 만든 별개의 알파 프로토타입으로, 실제 인허가 심사를 보조하는 도구입니다. 정책 조항 인용, 이의제기 요약, 초안 검토문 작성 같은 일을 해요. Barnet, Camden, Dorset 세 곳에서만 알파 테스트 중이고, 정확도나 오류율, 담당자 수동 개입 비율 같은 핵심 지표는 아직 공개되지 않았습니다.
“8주가 4주로 줄었다”는 그 숫자요? APD가 내건 목표입니다. 달성 결과가 아니에요. 정부 문서에도 2027년에 “성공할 경우” 전국 확대라고 명시돼 있습니다.
50%는 골이지, 지표가 아니에요

이 구분이 중요한 이유가 있습니다. 우리가 벤치마크로 삼는 숫자가 실측값이 아니라 정부가 제시한 목표치일 수 있기 때문이에요.
“카운슬당 연 255시간 절감”이라는 유명한 숫자도 같습니다. MHCLG가 20개 카운슬 시범에서 추정한 값이고, 정부 문서에도 expected라는 단서가 달려 있어요. 사후 감사로 확정된 배포 수치가 아닙니다. 전 카운슬에 공개했는데도 2026년 중반 기준 실제로 쓰는 곳은 약 50개뿐이었고, MHCLG도 “실서비스 수준까지 갈 길이 멀다”고 했습니다.
한국 AEC 빌더가 이 뉴스를 볼 때 첫 번째로 적용해야 할 필터는 이것입니다. “하겠다는 말”과 “했다는 말”은 다릅니다. 아직 누구도 처리 시간을 절반으로 줄이지 못했습니다. 그렇게 만들겠다고 예산이 붙은 단계예요.
가장 빠른 숫자는 AI가 만든 게 아니에요

여기서 반전이 하나 나옵니다.
영국 프로그램 전체를 훑어 보면 실제로 측정된 end-to-end 속도 향상은 단 하나뿐이에요. Lawful Development Certificate(합법 개발 증명서) 처리 시간이 기존 1시간 이상에서 약 30분으로 줄었다는 것. Barnet 카운슬 자체 리포트에 실린 수치로, 참고용(잠정)이라는 단서가 달려 있지만 어쨌든 실측이에요.
그리고 이 30분은 생성형 AI에서 나온 성과가 아닙니다. PlanX/BOPS라는 룰 기반 시스템이 만든 결과예요. 사람이 설계한 규칙 플로우로 돌아갑니다. 대규모 언어모델이 아니고, 결정론적이며, 문제가 생기면 책임 소재를 따질 수 있는 구조죠.
즉, 프로그램에서 가장 내세울 만한 숫자는 화려한 생성형 데모가 아니라 “잘 짠 규칙 엔진 + 구조화된 입력”이 만든 성과였습니다. 규제 업무에서 “결정이 투명하고 책임이 명확한 시스템”이 “보여 주기엔 인상적이지만 아직 검증되지 않은 생성형”을 앞선 사례예요.
우리한테 무엇을 시사하느냐. 세움터에 도면 PDF 올려놓고 인허가를 기다리는 한국 AEC 엔지니어에게 지금 당장 체감 가치를 주는 것은 GPT를 덧씌운 도구가 아니라, 국토부·지자체 시스템이 자동 검증할 수 있는 구조화된 제출물 포맷입니다.
Extract이 실제로 이긴 지점 — 모델이 아니라 데이터 레이어
그렇다면 Extract은 어떻게 봐야 할까요. 이건 분명히 성과를 냈고, 방식이 힌트를 줍니다.
숙련된 인허가 담당관이 스캔된 PDF에서 데이터를 뽑는 데 1~2시간 걸리던 일이, Extract에선 3분 안에 약 10펜스로 처리됩니다. 텍스트 필드 추출 정확도는 거의 100%, 날짜 94%. 지도 경계선 폴리곤 추적은 90%가 IoU 0.8 이상이에요. 파이프라인은 대규모 언어모델(LLM) 기반 텍스트 추출, OpenCV/SAM 비전 모델로 경계 폴리곤화, Ordnance Survey 좌표계에 맞춘 좌표 정합(지오리퍼런싱)으로 구성됩니다.
여기서 핵심은 기술 스택 이름이 아닙니다. 이 도구가 최종적으로 만들어 낸 결과물의 성격이에요.
Extract이 만든 건 “AI 답변”이 아니라 질의 가능한 구조화 데이터 계층입니다. 40년 된 스캔 지도가 SQL로 조회할 수 있는 폴리곤이 되었고, 그 위에 어떤 모델을 얹더라도 작동합니다. 내년에 Gemini보다 Claude가 더 잘하면 갈아탈 수 있어요. 데이터 계층은 남습니다.
진짜 진입장벽은 여기에서 생겨요. 모델은 몇 달 간격으로 평준화되고 가격도 빠르게 떨어집니다. 남는 가치는 각자의 분야 문서를 검색·검증 가능한 데이터로 바꿔 둔 구조물에 있죠. 싱가포르 CORENET X, 호주 Archistar도 같은 패턴입니다. 승부를 가른 건 더 큰 모델이 아니라, 해당 분야 문서를 검증 가능한 데이터로 전환해 놓았느냐였습니다.
RTPI가 하는 얘기 — 규제 도메인의 진짜 필터
영국 왕립도시계획협회(RTPI)가 이번 프로그램에 낸 가이던스는 흥미롭습니다. 지지하지만, 조건을 분명히 겁니다.
“AI는 계획가의 판단을 대체가 아니라 지원해야 한다.” 그래서 APD 역시 담당관이 AI가 제시한 모든 정책 인용을 직접 검증하도록 강제해요. 최종 결정은 사람의 몫입니다.
RTPI가 명시적으로 우려하는 지점은 다음과 같아요.
- 오래된 스캔에서 비롯된 부정확한 출력
- 책임 소재 문제(인공지능의 영향을 받은 결정이 사법심사에서 뒤집히면 누가 책임지는가)
- 저작권, 보안 위험
- “AI는 중립이 아니다”
- 주니어 플래너의 숙련 저하(업무 능력 약화)
- 하나의 국가 모델을 여러 카운슬에 일괄 확대하면, 그 모델의 결함이 시스템 전반으로 번질 수 있음
이걸 한국 상황에 옮기면, 어떤 공급사가 와서 “자율 인허가 검토 AI를 만들었다”고 데모할 때 던질 질문은 두 가지입니다. “틀렸을 때 누가 책임지나?” 그리고 “근거를 사람이 검증할 수 있도록 추적 기록을 남겨 주는가?” 이 둘을 넘지 못하면 규제 워크플로에 들어오기 어렵습니다. 이 질문만으로도 시장의 다수 데모가 걸러져요.
월요일 아침, 책상에서 할 일
그렇다면 한국 AEC 엔지니어·건축사무소 창업자가 이 뉴스에서 가져갈 실제 액션은 무엇일까요. 두 가지입니다.
첫 번째 — 지금 당장 제출물을 기계가 읽을 수 있도록 만드세요.
세움터에 도면을 일반 PDF(레이어 없는 형태)로 올리면 수동 검토 대기열에 앉습니다. 반면 국토부와 지자체 건축행정시스템은 점차 구조화된 메타데이터를 요구하는 쪽으로 움직이고 있어요. 도면 규격 통일, 레이어 네이밍 컨벤션, BIM 모델의 IFC 파일로 내보내기, 대지 조건·용도지역·건폐율 같은 값을 문서 본문이 아니라 구조화된 필드로 입력하는 것. 오늘 당장 AI 없이도 할 수 있고, 자동 검증 통과 속도가 실제로 빨라집니다. 영국의 30분짜리 LDC가 이를 증명했어요.
두 번째 — 자기 분야의 데이터 계층을 소유하세요.
작은 실무 사무소를 운영하며 “우리도 AI 붙여야지” 하면서 겉만 감싼 도구를 만들고 싶은 유혹이 있을 수 있어요. Extract이 남긴 진짜 교훈은 정반대예요. 값어치는 모델이 아니라, 비구조 문서를 질의·검증 가능한 데이터로 바꿔 둔 그 계층에서 나왔습니다.
구체적으로는 이렇습니다. 지난 5년치 우리 사무소 인허가 서류·시방서·도면·심사 의견을 구조화된 데이터베이스로 정리하세요. 조항별, 프로젝트 유형별, 지자체별로요. 그 위에 어떤 언어모델을 얹든 상관없습니다. 이 데이터가 우리 사무소의 진짜 자산이고, 2027년에 국토부가 무엇을 내놓든 이 자산의 가치는 변하지 않습니다.
기다리지 마세요. “AI 인허가 시스템”을 기다리는 사람은, 누군가 만들어 둔 데이터 계층 아래에서 API를 호출하게 될 겁니다. 지금부터 쌓아 둔 사람은 그 API를 제공하는 쪽에 서겠죠.